In this video I briefly cover how to solicit information from the users of a new process. As I have written about in the past, buy-in from end users is what determines the success or failure of the process.
Tag: #Process Establishment
Model-Based Design foundational concepts
In previous blog posts, I have gone into some depth on testing, architecture and data management for models. With this post, I will cover how these three activities for the foundation of any Model-Based Design process.
Foundations and core competencies
At later stages in the adoption of Model-Based Design 
processes task-specific groups will emerge (development, verification, and systems.) However, at the start of the Model-BAsed Design process users from all groups need to determine the “common language” that will be used to develop their project (1).
Architecture and data sure, but why testing?
The identification of architecture and data as foundational concepts is generally well understood.
Combined they define how people will develop the model through interfaces and clear communication. So why testing in the trinity? It returns to the core concept of Model-Based Design that models are at the center of the development process. To ensure that the model can be used consistently through the development process they need to be “locked down”(2) with test cases.
Driven by this objective, the testing environment is designed at the start of the development process. The requirements of the test environment should be addressed within the architectural and data infrastructure. The good news is that best practices for the three “legs”(2) of the MBD stool are already in the well defined; it is a matter of honing them to your specific project and environment.
Final thoughts
This post is not intended to be technical; rather it is to remind us as we develop new processes to start out with the “best path forward” from the start. In the section about the validation project, I will discuss the next round of tools that are commonly adopted.
Footnotes
(1) I may start using this graphic as my tag for MBD adoption. Crawl = investigate. Walk = initial. Run = validated. Flying = optimizing.
(2) Tests cases are elaborated as the model is developed. The “lock down” is achieved through the use of a continuous build and test server.
(3) The metaphor of a tripod or stool can be overused. But, to push it one last time, this is your stepping stool to the next round of MBD tools and processes. Build it well and it forms a strong foundation.
When do I….
Switching things up from my normal written blog posts I am offering this video blog. I will return to the Model-Based Design adoption timeline topic with my next post.
Model-Based Design: Driving factors
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
- Controls engineer (CE) use the requirements document and writes the initial code in C
- CE hands the code to the test engineer (TE) who creates a test harness and validates the behavior of the unit under test (UUT)
- TE hands the code off to the Software Engineer (SE) who optimizes its behavior for production
- 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.