Part 1 of this series discusses the challenges and organizational impact of adopting Model-Based Design.
Part 2 looks at an overall strategy for adoption of Model-Based Design.
Part 3 begins discussion of a migration plan to Model-Based Design covering requirements and the design phase.
Implementation is the process of translating the design to embedded software that can be executed on production hardware. In Model-Based Design the translation from design to embedded software is automated through code generation which significantly reduces translation errors [Ref. 11] and effectively eliminates coding time. Development focus can shift to the creation of intellectual property (i.e. design models) vital to a company’s competitive advantage and profitability.
Edit the model not the code
Treat the model as the single source or “truth” of the design and resist the temptation to modify the generated code directly. Instead make the change to the model and regenerate code to avoid waste and synchronization issues. In traditional processes this is no different than treating the C code as the source and refraining from making changes at the assembly level. Verification efforts resulting from a change can be reduced by assuring your design is partitioned into reasonable size model reference components.
Automate the code integration and build
A production code generator such as Real-Time Workshop Embedded Coder generates target-independent ANSI C/C++ code. If you have an existing build process, the first step in adopting code generation is to treat the code as hand code and integrate it into the existing process. Leverage tool features to automate the process of exporting code to your build environment.
If you don’t have an existing build process or would like to further automate the build process, take advantage ofIDE link product and Target Support Package to develop a fully automated application build and download to the target from within the modeling environment. This allows developers to focus on their designs and quickly iterate and verify on the actual target.
Minimize customizations to reduce maintenance
A production code generator such as Real-Time Workshop Embedded Coder provides many built in configuration capabilities to achieve common embedded software requirements in the areas of code style, interface definition, data definition, and file formatting. If the built-in capabilities are not sufficient, extensive customizations can be developed to address less common embedded software requirements.
Extensive customizations beyond the normal built-in configuration capabilities require much more effort to develop and maintain and can potentially increase the effort required to upgrade to new releases. Use built-in configuration methods whenever possible to simplify the modeling and code generation environment.
In addition, instead of integrating existing legacy functions, where equivalent modeling blocks are available use an intrinsic block which often provides more functionality and similar efficiency. The built-in lookup table block for example, provides support for a variety of look-up algorithms and data types, and has had a number of improvements over the years to generate highly efficient code. In summary, spend time developing models instead of support infrastructure.
Verification and validation phase
With Model-Based Design, models and simulation are used to verify and validate designs early and continuously through out the development process. The software and system integration test activity of the verification and validation (V&V) phase takes place at the end of development cycle.
In general, the primary objectives of V&V are to ensure that design meets requirements (design verification) and the implementation meets requirements (code verification). Using Model-Based Design, the design is represented by a model and these activities are accomplished by demonstrating that the model meets requirements and the code generated (implementation) from the model meets requirements as shown below.
Verification and validation workflow in Model-Based Design
The software integration activity typically consists of integrating and validating the software generated from the models and legacy software. Processor-in-the-loop (PIL) testing is one of the methods to perform software integration testing. The system integration activity generally involves the use of hardware-in-the-loop (HIL) testing and testing on the production hardware.
Skepticism is a useful attitude when evaluating claims of transformational approaches to engineering development. I have wandered down a number of what turned out to be blind alleys in my career. However, based both on my personal experience and those of multiple companies that have adopted Model Based Design, I can assure you that the hype in this case is fully justified.
During my career at Caterpillar Inc, I lead a group that was responsible for machine and engine control system development and was charged with the responsibility of improving both the process and tools used for controls development. After considering a number of development methods to improve our capability to develop control systems I selected Model Based Design and the MathWorks toolset. Our initial efforts were focused on Rapid Prototyping. In these applications we achieved a 70% reduction in the time to first working prototype. Based on this success we began a move to utilize automatic code generation in production applications. This was not, for us, a quick transition but rather occurred in stages over a period of time. The ultimate result was a complete adoption of automatic code generation for all machine and engine applications across the corporation. Savings exceeding 50% were achieved on large complex applications.
This success has been achieved by many companies of different sizes and with widely varying applications. The MathWorks website ( www.mathworks.com) contains many case studies that testify to the advantages that have been realized.
While I encourage you to retain your skepticism when encountering claims of transformational development approaches, I encourage you to give Model Based Design consideration. The rewards will exceed your expectations.
Best Wishes for future success,
I have heard this same story for the last thirty years. Promises, Promises, but nothing useful.
If you believe this approach will really work, hold a contest. Use a simple set of requirements for a basic system. Have a group of engineers use their methods, you use your fancy tools.
When either side gets a finished design you stop. If the design meets the requirements it wins. Then you let the others finish to see how much longer it takes. You compare the % of requirements implemented correctly on the first version, count the number of errors/mistakes/screw ups and then you do a comparision chart.
When your tools can create a working system with maintainable code, meets requirements, gets the job done faster with less resources, then you have a practical approach.
Stop wasteing everyones time telling us it can be done, DO IT, then I will be interested. Otherwise it is just another worthless academic exercise.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.