In a traditional ECU design process, engineers gather requirements from a number of sources such as customer expectations, government regulations, and corporate strategic directions. These requirements are then combined to create a paper specification that is distributed to a design team. The design team produces a detailed design by iterating through a series of potential design concepts that are prototyped in hardware, checked against the requirements, and then modified if needed. When an acceptable design is achieved, it is given to another group to implement. Last, another team performs verification and validation testing. Because testing is the last phase in the process, errors are found late and are expensive to fix, forcing a management decision to fix or ship.
In contrast, Model-Based Design begins with the creation of an executable specification from the requirements. At the heart of the executable specification is an executable model, which can be used and elaborated throughout the process. The executable specification can also include inputs and expected outputs, the application environment, and links to requirements. Executable specifications unambiguously communicate the design goals and allow feasibility analysis of the requirements.
The models from the executable specification can be used as the starting point for the design. Unlike with the traditional process, engineers can perform design iterations on a model of the system rather than relying on physical prototypes. Moreover, design teams can systematically explore and optimize the design using Model-Based Design. For example, with bit-accurate simulations of components, design and requirement flaws can be identified and corrected before implementation. The inputs and acceptance criteria created as part of the executable specification can be reused at this stage to ensure that the design meets the requirements. Using these tests and the design model, engineers can also analyze how thoroughly they have exercised the design via model coverage analysis using criteria such as MC/DC analysis. If the tests do not exercise the design completely, the design team can determine if additional tests are needed or if parts of the design are not necessary to satisfy the requirements.
After the model has been elaborated during the design stage, it can be used to automatically create the implementation. For example, C and HDL code can be generated for either a software application or digital hardware implementation, respectively. Generating the implementation automatically from the model removes manual errors from the process. Moreover, since the target for the implementation is not specified until later in the process, much of the design work can be reused when a new target is selected. Also, because the implementation process is automated, it is repeatable and not dependent on the availability of specific individuals. Finally, the implementation is tested using the tests developed in the prior stages. Hence, throughout the process engineers test and verify that the requirements are met.
As a byproduct, Model-Based Design reduces the traditional dependency on physical prototypes and moves much of the testing further upstream in the process so that test to verify hardware or integration requirements are performed on hardware, while algorithm debugging and analysis are done upfront on the model.
ABOUT THE AUTHOR
Jon Friedman is the automotive industry marketing manager at The MathWorks Inc. Before joining The MathWorks, Friedman worked for Ford Motor Company in positions ranging from software development research at the Ford Research Laboratory to leading the electrical launch team at plants across North America.