The decision to adopt a new process should be viewed from two directions, what drives and what prevents companies from embracing new methodologies. This week we will look at the driving factors

Driving Factors

There is rarely a single driving factor, rather it is a combination of the three primary factors, increasing feature complexity, shorter development cycles and cost reduction, and certification requirements.

Increasing feature complexity:

The complexity of modern control algorithms has grown in two respects; the first is simply the size of the system.  As more parts of the system come under active control the size of the system increases.  (For example, the washing machine I purchased this past month has a more complex control algorithm  and a more powerful embedded control unit  (ECU) then the whole of the car I owned in 1988)

Next, the complexity of the control algorithms has increased.  While Transfer Functions, PID, State Machines and Table Lookups still compromise a large percentage of control algorithms more advanced features require more advanced control methodologies such as adaptive controllers, neural networks, or highly nonlinear system control.

Both aspects of complexity mean that it is more difficult to both develop and to verify the control algorithm.

Shorter development cycles and cost reduction

A primary factor in adopting any new process is the hope that it can either shorten the development cycle or reduce the costs of development.  I will address how Model-Based Design can do both of these in the “How” section of this post.

Certification requirements

For engineers working in a safety critical development environment the such as the DO178-C or ISO 26262 or ISE 61508, mandated processes require high levels of testing and traceability between artifacts.  Because of this automation of those processes is highly desirable.

The Mandate

In a small percentage of cases, Model-Based Design is adopted not because the company decided that this is the correct course but because an outside agency mandates that a development methodology will be followed.  The benefits of adopting Model-Based Design are still present in this case however the internal motivation may suffer.  This topic will be covered in later blog posts about motivating staff.

How Model-Based Design addresses these factors

Let’s address complexity first, the following images show a  simple PI controller in Simulink and the code generated by Embedded Coder (TM)

To a controls engineer, the image on the left is immediately understandable, while the generated code, while highly readable, would require some time to understand.  So the first argument in favor of MBD is

1.) Let people work in the domain they trained in:  This produces results in higher quality work, faster development times and more satisfied employees.

With respect to the size of control algorithms, models have a clear advantage of traditional C code development.  Both C and MBD allow users to decompose large systems into smaller components (functions in C and referenced models for MBD) however the sub-component in MBD (a model) is itself a simulatable and testable unit without the need to hand create a test harness.  By way of contrast, every function written in C will need a unique hand written test harness.  This leads to the second argument in favor of MBD.

2.) Enable simplified testing and verification workflows through the use of models:  

This simplified workflow will allow for the detection of design errors and incorrect requirement earlier in the development cycle.  An excellent paper from NASA gives an overview of the costs and risks associated with detecting errors later in the development lifecycle.

The use of model centered workflows, where the model is the primary artifact throughout the development process, enables the reduction in handoff errors.  Imagine a traditional development process

1. Controls engineer (CE) use the requirements document and writes the initial code in C
2. CE hands the code to the test engineer (TE) who creates a test harness and validates the behavior of the unit under test (UUT)
3. TE hands the code off to the Software Engineer (SE) who optimizes its behavior for production
4. SE hands it back to the TE to make sure it still passes tests

If at any stage there is an error potential 3 unlinked items would need to be updated, the code, the testing harness and the requirements.

In contrast with a model centered approach all three people (CE, TE and SE) are using the same artifact, the model, to develop test and deploy.  There are no handoffs.  Further, since the requirements can be linked to the model and the test of the model when the requirements change the model will capture and reflect those changes. leads to the third argument in favor of MBD.

3.) Prevent errors resulting from handoffs by using a single source of truth, the model

Every translation from one format to another introduces the possibility of errors being introduced into the process.  The use of models eliminates this possibility by removing the translations stages.

 

Next week’s blog

In next week’s blog I will examine the preventative factors and how Model-Based Design addresses them.