Prototyping an ECU for a vehicle imposes quite a few challenges to the manager and the engineer. The manager must look at reducing the development time, effort and costs. The development must go through an evolutionary prototyping' lifecycle in which an iterative fine tuning is necessary. If the whole process is handled manually, it can result in consumption of more resources and escalation of costs.

ECU development process
An automated, rapid-prototyping approach is warranted, where the engineer can quickly go through the various stages of the prototype evolution, with minimal human interaction.

Pathway Technologies helps you achieve this.
Prototyping an ECU for a vehicle imposes quite a few challenges to the manager and the engineer. The manager must look at reducing the development time, effort and costs. The development must go through an evolutionary prototyping' lifecycle in which an iterative fine tuning is necessary. If the whole process is handled manually, it can result in consumption of more resources and escalation of costs.

ECU development process

An automated, rapid-prototyping approach is warranted, where the engineer can quickly go through the various stages of the prototype evolution, with minimal human interaction. Pathway Technologies helps you achieve this.

ECU prototyping in the automotive sector is targeted (at the first stage) at a test vehicle, where, if need be, the vehicle can be broken down and under-the-hood wires can be tapped. The vehicle will already have ECUs for various purposes, communicating on the CAN bus (the in-vehicle-network). The actual CAN protocol used may be the base CAN, an industry standard variation such as CanOpen or SAE J1939 etc., or could be a customized version of CAN (in the future we'll also support time triggered protocols such as TTCAN, TTP etc). The vehicle would have sensor and other data, some of which would be available on the CAN bus while rest would be available direct (not on CAN). The vehicle may also have certain control algorithms in place. Some of these could be proprietary.

The existing vehicle architecture would impose certain requirements and/or constraints on the prototype. The block diagram gives a broad outline of the prototype lifecycle.

Based on the requirements, the following need to be designed:

1. Hardware - board, Interface electronics, diagnostic
2. Sensors
3. Control system
4. Software - drivers, RTOS, embedded code

Once the design has been implemented, the result is the ECU with the embedded code. This must be deployed on the test vehicle before it can be tested on a fleet. The various ECU sub-systems may need changes and fine tuning. For this, instead of manually changing code, the whole system is modeled. Also in-situ monitoring and logging of the various signals and parameters is possible using the Opensim family of products from Pathway. So from changes in the control algorithm to generation and redeployment of embedded code takes much less time and effort than before. The evolutionary prototype development lifecycle is now be labeled as the 'evolutionary rapid-prototype lifecycle model'.