Part 2of this series looks at strategy for change, including migrating legacy code into models.
Part 3looks at the software development process and tool migration plan
(requirements and the design phase) when implementing Model-Based
When transitioning to Model-Based Design for embedded systems development, it is essential to consider an overall plan spanning people, development processes, and tools. A common sense approach when beginning any process improvement activity is to first identify the problem to be solved and then develop a plan to implement the solution.
When transitioning to Model-Based Design, performing the transition in an iterative manner—do, learn, adjust, and repeat—has been shown to be most effective. The end goal is a development process where the model is the design, verification is done throughout the development process using simulation, and the implementation of the entire application onto target hardware is highly automated.
But faced with design and organizational complexity, time, quality, and cost pressures, for developers the transition is akin to changing a flat tire while moving down the highway. Choosing the right first steps is key to a successful transition. This series of articles presents a set of practical strategies for determining the first steps when deploying Model-Based Design and code generation in production development processes.
A growing number of embedded systems development organizations, including automotive, are seeking to adopt Model-Based Design to take advantage of benefits such as enhanced ability to deal with complexity, reduced time-to-market, reduced cost, and improved quality. Many organizations have taken the first step by building models for early stage design analysis or rapid prototyping of control algorithms. The next challenge is determining how to effectively incorporate Model-Based Design into their production development processes. Building an effective migration plan requires consideration of the impact Model-Based Design has on organization, process, tools, testing, and design.
This series presents a set of considerations and strategies for adopting Model-Based Design for embedded software development. A key component of the strategies to be outlined is a phased roll-out, which spans the first production deployment to a highly optimized integration of people, processes, and tools that delivers on the potential of Model-Based Design. Common challenges will be presented as well as current industry best practices to address them.
The series is structured into 3 main sections:
Organizational challenges and impact
Strategy for change
Process and tool migration plan
In the organizational challenges and impact section we answer the questions:
What does Model-Based Design mean to the people in my organization?
Do I need new skills? Are there new kinds of work being performed?
Should my people be organized differently to take full advantage of Model-Based Design?
How will the inputs and outputs to my embedded systems development organization change when I adopt Model-Based Design?
In the strategy for change section we explore the optimal approach to a migration to Model-Based Design. A phased approach where carefully constructed criteria are established for selecting the first project, including considerations related to:
What problem am I trying to solve?
What project should I start with?
What Return-on-Investment (ROI) is needed to prove the value of Model-Based Design?
How can risk be mitigated during the migration?
How can a large legacy code base be effectively migrated?
After the initial project, what’s next?
In the process and tool migration plan section we examine many of the important details that need attention during the transition. Each phase of the development process (requirements, design, implementation, verification, and validation, etc.) is analyzed in some detail and specific recommendations are made for the initial project and the expanding, optimized roll-out of Model Based Design.
We have found it critical to ensure that requirements are well defined and validated and then integrated to your models via trace. Integrity has leading RM capabilities and a great integration to Mathworks software that supports trace to model elements and even trace through to generated artifacts.
A variety of targets are available from MathWorks, processor manufacturers, and other tool providers (here is a list from MathWorks: http://www.mathworks.com/products/rtwembedded/supportedio.html). These typically include I/O drivers, scheduler and startup code to deploy generated code onto embedded hardware. They often also provide processor-specific code to accelerate math operations. This approach is very good for getting a system up and running quickly. In the cases where target support isn’t already available for a specific processor, open APIs in Simulink and consulting services are available to build a target quickly.
Many production organizations, on the other hand, take a different approach. They generate standard, processor independent C code that can be integrated with existing source code (including optimized math routines), and also be reused across different processor families.
Do other readers have best practices for integrating generated code with processor targets to share?
I see a problem with MBD in terms that not all hardware providers deliver toolboxes with drivers and startup code to actually start working. One has to use generic C code and not targeted code (for the specific architecture) and this lowers performances.
How does MathWorks attack this problem in terms of collaboration with silicon providers?
From my point of view things have to be moving like this:
- Drivers and startup code have to be provided and easy put to work in the modeling environment so that hardware in the loop can be made possible
- Use dedicated compilers(usually hardware providers deliver also compilers) and allow defining complex instructions (for instance if my architecture knows to make multiply and accumulate that the instruction has to be mapped somehow into the code)
This should be made simple somehow, without reading 1k pages of useless materials and hacking into matlab.
Tools for Model-Based Design have been in use for a long time. Also, there is already a wealth of knowledge in how to get started with Model-Based Design for simulation or prototyping. However, as the use of Model-Based Design moves from research into product development, and from using a small set of tools in individual groups to deploying a tool chain across a large organization, many new questions emerge. For example, how should engineering resources be allocated to obtain the time savings in debugging (ie, finding and fixing errors earlier in the development process), how should the use of modeling, simulation, code generation, and verification tools be optimized, and etc. Also, how should Model-Based Design be rolled out in phases (small steps first)? We will attempt to address these questions in subsequent posts in this series. We welcome you to go through them and let us know your thoughts.
What do other readers think? Is deploying Model-Based Design across large organizations something you would like some guidance on?
The author has complicated an interesting topic by unnecessary explanations.
Model Based Engineering has existed for decades, for software development with adoption procedures well defined and tested. The only difference between application development and embedded systems development is that the later requires special hardware. Hardware simulation has also existed for many years with organizations and embedded systems engineers quite use to it.
New modelling software now exists that integrates the modelling practice and the virtual hardware, through automated code generation.
Getting a modelling and simulation system to an organization is not as complicated as described. The virtual development environment is just another tool in the developer’s tool box. The ROI is in terms of time saved in debugging.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.