Part 1 of this series discussed the challenges and organizational impact of adopting Model-Based Design.
Part 3 looks at the software development process and tool migration plan (requirements and the design phase) when implementing Model-Based Design.
Plan for change
The introduction of Model-Based Design should align with a required process change, which may be the adoption of standards such as AUTOSAR, ISO 26262, and DO-178C, or the development of disruptive technologies such as hybrid electric vehicles, wind power systems, or a continuous improvement initiative.
Identify the problem you are trying to solve
Before embarking on the transition to Model-Based Design, it is necessary to have a thorough understanding of the inefficiency and waste in the current process and organization. Metrics need to be established to set goals and quantify inefficiency to determine the focus areas, specific strategies, and tools to adopt.
Often, detailed metrics of the current process and organization are limited. In such cases industry metrics serve as a good starting point to identify the key areas to focus on improving. A number of references are available that document typical industry metrics [Refs. 2,3, and 4].
One study indicates that a major source of delay reported across all industries is getting the specification right and verifying the design. Another cites that 60% of the defects are introduced in the specification while 55% of these defects are not detected until the testing phase resulting in inefficient design and requirements debugging by test and calibration engineers. The relative cost of fixing errors late in a development process is documented in [Ref. 2]. There are also often overlooked metrics about process inefficiencies such as the amount of time calibration engineers spend debugging controller software.
In summary, focusing process improvements on eliminating defects and waste will achieve the highest return on investment.
Choose a project with the appropriate level of complexity and technology
What projects are the best candidates for initially deploying Model-Based Design? Projects which require minimal changes are not very good candidates since there isn’t much opportunity to demonstrate savings. An engine controller being carried over to the next model year with minor calibration changes wouldn’t motivate migration to modeling, but a project with significant new feature content such as a new hybrid powertrain controller would.
If a project is critical to the success of a company, a back up design is occasionally developed using traditional processes and methods. This serves to mitigate the risk and provide valuable metrics for both process and tooling. Most organizations, however, either chose a project that is slightly less risky or one where Model-Based Design presents the only way to meet the project schedule.
A typical embedded system spans multiple domains. It is important that components of the selected project can be clearly represented in the modeling domains available in Model-Based Design. For example, control algorithms expressed in a signal flow diagram are best implemented in modeling tools such as Simulink. Algorithms involving complex logic, supervisory control and flow charts for fault management and state machines are best represented using tools such as Stateflow. Components with close ties to hardware such as the operating system and device drivers are better suited for low level languages such as C. Where a component doesn’t fit, co-simulation can often be performed to allow for a complete system wide simulation for verification and validation.
Mitigate risk with a phased approach
An important initial consideration is how to incorporate Model-Based Design tools to address objectives while minimizing risk to a program. Production organizations rarely have the luxury of halting development while major process changes are put in place. Questions often arise such as how will development time be affected, will the technology address our application needs, is the code efficient enough, etc.
These concerns are best addressed through a phased approach to adopting Model-Based Design. This involves breaking the deployment of Model-Based Design into phases and optimizing the process with the experience gained from the completion of each phase thereby reducing exposure and minimizing risk. Care must be taken to account for the learning curve when planning and drawing conclusions on the potential efficiency gains of the initial project.
The phased approach shown in the figure below begins with the development of an initial migration plan that is used for subsequent execution of carefully scaled deployments first of a single component and finally a full application. Full application deployment is followed by a phase of process optimization and expanded rollout, after which maintenance and upgrades will continue as part of on-going improvement.
Each phase should have clearly defined objectives, metrics, milestones and include post assessment and migration plan refinements. The activities in each phase encompass both modeling and the application of process improvements. Refinement of the tools and processes for Model-Based Design is an on going activity. New capabilities, recognition of additional opportunities for eliminating manual activities as well as revision of design standards and techniques, continue to provide the opportunity for efficiency and quality gains.
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.