As ECU strategies are most often designed, developed and owned by the ECU manufacturer, Automotive OEMs need a method of implementing control strategy independent of the ECU supplier to enable problems found in calibration and testing work to be overcome more rapidly.

Automotive OEMs face pressure to deliver development programs on time with ever increasing control strategy complexity due to higher customer expectations and tightening legislation. “Vehicle manufacturers and ECU suppliers have widely identified controller strategy development as a means of differentiating themselves from the competition. In order to keep pace with the competition a streamlined development process is necessary” (Rolfsmeier et al, 2003). “Manufacturers and Suppliers are constantly searching for means to reduce both time-to-market and development cost. As a kind of solution to satisfy these requirements Rapid-control prototyping has established itself as viable technology” (Shin et al, 2003).

Tools for the purpose are available, however, the increasing requirements in this area have created a need for this functionality to be available within or to coexist seamlessly with calibration tools using the same physical link to access the target ECU, and needing to operate concurrently. Despite a requirement existing to date, the integration of the stimulation of parameters with standard features found in calibration tools has been limited to implementations that have had no real time capability, that is loop times and latency have been unacceptable with general operation being non deterministic. This limitation is prohibitive to the requirement to use standards based protocols to robustly run control strategy externally from the ECU whilst retaining the functionality available to a calibration engineer by the calibration tool. This has now been changed with the introduction of the MCS400DR and MCS400ADR. Voorburg (2002) shows that there is focus on the anticipated time savings that can be achieved in the programming, verification and testing phases of the software development process. The Software Development process that is outlined does not illustrate the process of software delivery to the Automotive OEM by the ECU supplier and outline the calibration process. It needs to be recognised that due to the way that software is delivered and subsequently calibrated many unanticipated interactions will be encountered. By use of RCP in this area, the Automotive OEM can communicate requirements for software changes to the ECU vendor. The new requirements can potentially be validated solutions. The impact of these can at the same time be tested and engineers working on other systems impacted by these changes can compensate accordingly.

Kleinknecht Gredi calibration software can also access parameters and variables available in both the ECU and the RPM as well as other ECUs and data acquisition equipment that is connected. Use of the supplied blockset also enables data type handling of allowing engineers to work in physical units easily; the generated description file will also have the display model and limits correctly defined.

References

Lemon, K., Dmuchowski, T., Emaus, B., (2000) Introduction to CAN Calibration Protocol, SAE Technical Paper 2000-01-0389, Warrendale, Society of Automotive Engineers. Rolfsmeier, A., Richert, J., Leinfellner, R., (2003) A New Calibration System for ECU Development, SAE Technical Paper 2003-01-131, Warrendale, Society of Automotive Engineers. Shin, M., Lee, W., Sunwoo, M., (2003) Implementation-Conscious Rapid Control Prototyping Platform for Advanced Model-Based Engine Control, SAE Technical Paper 2003-01-0355, Warrendale, Society of Automotive Engineers. Voorburg, F., (2002) Rapid Application Development for Embedded Systems Using CAN Calibration Protocol, SAE Technical Paper 2002-01-1170, Warrendale, Society of Automotive Engineers.