Search Results

The process of developing new functions and software for powertrain embedded control units (ECUs) is undergoing a sea change. One of the reasons is the pressure to meet regulatory requirements (e.g. emissions, fuel economy) in addition to managing the normal growth in software complexity. Traditionally, the vehicle manufacturer (OEM) would write new specifications and hand them over to the software supplier (Tier1). This process required a substantial review and testing process at the OEM to ensure that the requirements were interpreted and implemented as indented. Today, a number of parties are involved in creating specifications (including the software supplier and 3rd party engineering companies), thus making the verification task even more complex.

Over the last two decades, adoption of model-based techniques for the development of ECU software has resulted in major gains in productivity across the automotive industry. However, the fact remains that the majority of the ECU software today is still hand-written using the “C” programming language. Further, the need to shorten the development time, reduce costs and increase the quality of the ECU software has driven companies to adopt virtual (PC-based) simulation techniques rather than rely on expensive in-vehicle and dynamometer set-ups. This has lead to a situation where the two development philosophies (models and hand-written code) need to be properly integrated in order to fully capitalize on the advantages of PC-based techniques. For the complete ECU system to be simulated, typically, automatically generated C-code from other tools must be integrated as well.

This manuscript describes a method for verifying the correctness of embedded software systems modeled and implemented with rapid prototyping and automatic code generation tools. By reusing the prototyping system as a reference, an automated means of comparing the target implementation to the validated model functionality is derived. The comparison ensures that the integer code generated and compiled for a specific production target corresponds and behaves identically to the function model developed in a rapid-prototyping environment.

Bringing a new automotive electronic control unit (ECU) to market is a multi-phase process. Generally speaking, the phases are engineering analysis, rapid prototyping, software implementation, test and calibration. A variety of engineering staff and tools are used as the ECU progresses through the development process. However, the use of different tools may require non-value-added steps to translate data and results from one process phase to another. This lack of integration introduces the potential for errors, adds delay and costs to projects, and makes it difficult to trace the behavior of the final product back to the original requirements. Model-Based Design addresses many of the integration problems through use of executable specification models and automatic code generation. However, connecting the design effectively to the prototype vehicle provides additional integration challenges since it requires specialized hardware interfaces and target-specific software device drivers.

The diagnostic communication interface of electronic control units (ECU) has to be supported by the OEM during the whole life cycle of the vehicle. It is the only external access possible in the late product phases. The process chain comprises the diagnostics and test of ECU functions in engineering and road test, the production of vehicles as well as maintaining and retrofitting functions in the dealership. More and more OEMs are introducing diagnostic solutions which support the whole process chain, while in the past different phases of the vehicle life cycle had been covered by different partial solutions which often haven't been compatible with each other. Thus the co-operation with suppliers had unnecessary difficulties. Beside other activities to link the different phases more closely, one remedy is to use accepted standards developed by ISO (e.g. Keyword Protocol 2000 according to ISO 14230 or 15765), SAE or the ASAM Association (e.g. ASAM MCD).