A common misconception around adopting Model-Based Design is the degree to which things are “new“. For most software / engineering groups adopting Model-Based Design is an exercise that consists of three main activities
- Redefining the development workflow Model-Based Design allows you to perform multiple operations earlier in the development cycle than traditional C based development workflows.
- Refactoring existing processes: Model-Based Design allows automation of some development tasks and processes.
- Re-targeting process tools: The tools used by the existing processes will change to reflect the automation and simulation tools that Model-Based Design provides.
While Model-Based Design adds in additional processes; it has been my experience that customers have used 70% or more of their existing processes for items 1 and 2. Further, the automation gain from MBD simplifies many of their existing processes.
Redefining the development workflow
Model-Based Design has been used in conjunction with multiple design workflows, most commonly I reference a “double V feedback” workflow. Regardless of the development workflow that you follow the key development concept is the movement of simulation-based design and verification into the front end of development.
One of the key arguments in favor of Model-Based Design is the ability to simulate models early in the development process to improve the design of the system through system analysis; or as we said back in my automotive days “models, not metal.”
In the same way that early
implementation of functional and system level design reduces development time the ability to test models early in the development process both reduces development time and improves the likelihood of detecting bugs early in the process.
Refactoring existing processes
Following the same principals from redefining the development workflow refactoring existing processes considers three things
- Is the existing process still required?
- Can the existing process be automated?
- Are there new processes requirements or opportunities?
Is the existing process still required
By moving to Model-Based Design there are some processes that are no longer required, due to automation within the tool. For example in model-based design processes that include a code generation step a manual code review process are generally not required.
Can the existing process be automated
New methods for automating processes routinely are created; even without moving to a Model-Based Design workflow a yearly review of processes that could be automated is a good best practice. MBD workflows tend to have high levels of automation due to their built-in integration with automation tools such as Jenkins (continuous integration) or Rational Doors (requirements management)(2).
Are there new processes requirements or opportunities
Transitioning to Model-Based Design workflow will introduce new process. This happens for three primary reasons. Firs, the movement to MBD was driven by out side standards and the standard (such as DO-178C) requires a process to be performed. Second the transition allows for a new process that will improve the final product, such as design based simulation. The final reason new processes are adopted is in support of the interface between existing and new project development tasks and objects.
Re-targeting tools used by processes
The tools used by the existing processes will change to reflect the the automation and simulation tools that Model-Based Design provides. This blog will goes into more detail in “The role of supporting tools in Model-Based Design” and “Model-Based Design Building Blocks” posts (3).
Footnotes
(1) In just a casual search I found over 50 graphical representations of the “software design V.” As with all things make sure there is clarity around what you are talking.
(2) While both Doors and Jenkins are solid tools in their categories the selection of them is not an endorsement for that role.
(3) Currently these two sections are still a work in progress. More detail will be filled in as this blog continues developing.