With this video, I summarize the approach I take to selecting the type of projects I work on. I call it the 20-60-20 rule and it represents the balance I strike between learning new material, deepening my understanding of the material and teaching others.
These blog posts have focused on the adoption of Model-Based Design. The choice of the word “adoption” was intentional. When I visit a customer I tell them the following.
“80% of what I will recommend is generic best practices, common
across all Model-Based Design. The next 10% is a selection of common
patterns in use relevant to your industry and regulatory needs.
The last 10% is the unique part of your development; your intellectual property”
Why do I say this? Model-Based Design, from an architecture, data, and V&V perspective is now a mature field. In a mature field, time should be spent on developing the IP aspects of design, not infrastructural components. To that end, there is a significant body of best practices available for companies to reference. (See the reference page for a small subset.)
As this blog has spoken about on a number of occasions adoption is a process. To succeed there are 5 key activities that need to be performed
Success often comes from knowing when to ask for outside help, either from other groups within your company who have already blazed a trail or from outside support groups (such as training and consulting.) Utilizing support early in the adoption process enables a faster rate of adoption with fewer implementation issues.
Very few projects start off with a clean slate; the majority have some body of existing text-based code (C/C++/Asembler) which needs to be either translated or wrapped into the Model-Based Design environment. For the cases where translation is the desired path, the objective should be the translation of the essence (e.g. requirements) not the content.
First, every programing language has unique constructs which may or may not be directly replicable in other languages. Because of this, a common failure mode is to try and directly replicate coding patterns in the MBD environment.
Second, when you translate the based on the requirements you have the opportunity to improve upon the existing code.
It is common with text-based algorithms to implement basic functions such as table look ups, integrators, etcetera. While in some edge cases the text-based implementation is more efficient this is less common with the growing maturity of Model-Based Design tools.
Further, the small efficiency gains from the existing implementation are frequently less important than the clarity found by using built in blocks.
In text based languages truth tables and state machines are implemented as either a series of if/then/else or switch/case statements. Within MBD environment both truth tables and state machines have direct implementations.
The final note, there are some areas where text based modeling makes the most sense. Generally, this is in the area of long complex equations. While they can be rendered in block form they are more easily read in text form. With that in mind, I recommend using MATLAB blocks for longer equations.
The image above, the Pythagorean theorem, is relatively simple. Yet even it would be more easily read as
C = sqrt(A^2 + B^2)
When translation occurs it is important that the new implementation is validated against the behavior of the existing code. Failure to do so can result in larger system level errors.
In my translation example, I used the simple phrase “I have the cutest cat in the world” I submit the following images to back that claim up
In a recent customer conversation, I was asked if there was a mapping of Model-Based Design (MBD) constructs to the concepts of “smells” found in Martin Fowler Clean Code. Fowler’s book was written targeting the Java, however, many of the concepts have direct mapping onto other programming languages. Maping onto other object-oriented text-based languages are easily seen. Hence the question of how OO smells could be mapped onto MBD.
Note: I am reviewing this in the context of developing embedded code using Simulink and Embedded Coder. The Clean Code was written with object-oriented user interfacing code (e.g. web pages, spreadsheets,…)
Fowler’s book defines 7 primary sources of smells:
For some of the smells, there is a direct and easy mapping.
Comments: Models are, to an extent, self-documenting. Additional documentation should be added as needed. Fowler’s recommendation on keeping comments concise and up-to-date are directly mappable.
Environment: The smells in this section deal with automation of the build and test steps. There is a direct mapping for these smells and the recommendations for automation are standard for MBD environments
Naming conventions: For information on naming conventions (from and earlier MathWorks blog I wrote): A few thought on Naming Conventions
Tests: The smells for tests are standard recommendations for testing. Earlier blog posts on testing can provide the mapping onto these smells.
Of the 7 smells, I want to spend more time looking at both the “Functions” and “General” groupings.
Fowler has 4 smells related to functions, of the 4 MBD conforms to 1.5 of them.
The general
category includes 36 different code smells; I have subcategorized them into N themes
The concepts put forth in the book “Clean Code” represent a useful set of guidelines for understanding coding best practices. To the extent that models map onto code the concepts behind “Clean Code” apply. However, MBD abstracts many concepts behind coding into a higher level language, placing the clarity and encapsulation of the actual code into the hands of the code generation tool.
Late in my conversation with the customer, I realized that I was talking to someone from Denmark about smells. I regret that I did not take the opportunity to make a reference to Hamlet. (Something is rotten in the state of Denmark)
.I drive a vehicle with an all drive-by wire setup. Drive-by wire brake, throttle, and PRNDL (the shifting mechanism for those of you not in the Auto Industry (Park, Reverse…) While as a controls engineer, and an environmentalist, I like both the performance increase and the weight savings to fuel savings that this brings it raises the question, what do you do when the system fails?
The first rule of safety critical software (and a break in a vehicle is safety critical) is to fail in a safe fashion. There are several modes in which a brake can fail, from worst to best
First, what is a partial failure? A partial failure is when part of, but not all of, a redundant system sends back data that is not in alignment with the other parts. Standard protocols for drive by wire brakes is to have 3 redundant sensors to determine
Of the four scenarios, the first is the most dangerous and poses an interesting question “what is the fail safe behavior?” Hard braking could result in a rear end collision. Failure to brake could result in running into someone. Of course, this problem is no different from the one found in traditional fully mechanical/hydraulic systems. For an overview of what to do if this happens, take a look at this article.
So what does it mean to “fail friendly?” In a fail friendly scenario, the objective is for the system to maintain the maximum functionality without putting the user or the device in danger. In the example of the brake failure, with an all electronic version, the vehicle could allow driving at speeds up to 5 mph. This mode allows the driver to safely move the vehicle off of roads into a safe parking location.
The way in which systems fail directly impact the end users experience of the product. Providing the secondary fail friendly mode results in a more positive user experience.
While traceability plays a key role in the software development process for many groups it presents as a high impact burden. Modern software tools can simplify the traceability process however it all begins with the requirements.
The objective of traceability is to ensure that requirements are met in the final product. 
This is achieved by the creation of traceability “check-ins” at each stage of the development process. A check-in serves two purposes. First, they ensure that the design process does not “drift” too far from the requirements. Second, they provide formal documentation of adherence to the defined development processes.
Check-ins should be an automated processes
where information is cross checked between the current state of the models and the requirements. If the requirements are written in a testable format than the check in consists of running the tests and a human verification of the test result. If they are not written in a testable format or the complexity is such that automated testing is not possible then a manual review is required.
The primary deliverable of the check-in is a traceability report. It documents that at each step in the process the model and related artifacts were validated against the requirements.
Traceability is one of the core activities of a safety critical software design process. Implementation of automated requirements tracing is greatly simplified in a Model-Based Design environment that includes simulation capabilities.
