In the 6 months of writing this blog, I have received multiple requests for more information about the MAAB style guidelines.  The requests are for information on the rationale behind the rules and explanation of specific rules; I will address both in this post.

History of the M.A.A.B. style guidelines

The MathWorks Automotive Advisory Board (MAAB) was originally established to coordinate feature requests from several key customers in the automotive industry. The inaugural meeting in July 1998 involved Ford, Daimler-Benz, and Toyota.

The MAAB is an independent board that develops guidelines for using MATLAB®, Simulink®, Stateflow® and Embedded Coder®.  MAAB meetings now involve many of the major automotive OEMs and suppliers, and focus on the usage and enhancements of MathWorks controls, simulation, and code generation products including Simulink, Stateflow, and Embedded Coder.

By the time of the version 3.0 release, the M.A.A.B. style guidelines were in use across multiple industries having outgrown their automotive origin to become the reference for aerospace, medical and industrial automation industries.

My involvement with the M.A.A.B. style guidelines

Back in 2005 when I joined The MathWorks my first task was to update the M.A.A.B. version 1.0 to version 2.0; the update was released in April of 2007.  With a span of 9 years between the initial release and version 2.0, there were significant updates to both The MathWorks tools and the accepted user workflows.  With a few minor updates between version 2.0; version 3.0 was released in August of 2012.  Like the previous update, the version 2.0 to 3.0 enabled new workflows and addressed new tools and functions in the Simulink, Stateflow, and MATLAB models for MBD development workflows.

Across both releases, I helped guide the debate between those and wrote these guidelines.  Providing both the technical background from The MathWorks perspective and experience gain from working across multiple industries.

Understanding the guidelines

The M.A.A.B. guidelines working group had four primary objectives in mind when they were working.  With that in mind, guidelines should

1. Improve model clarity
2. Prevent unsafe modeling patterns
3. Have minimal impact on the end user
4. Be useable across companies

Model clarity

Model-Based Design was seen as a method for clearly communicating design intentions. Examples of these rules include

• na_0004: Simulink model appearance
• db_0043: Simulink font and font size
• db_0042: Port block in Simulink models

By following common design patterns users can quickly and easily understand the models.

Prevention of unsafe modeling patterns

Within any modeling domain, it is possible to create design patterns that can result in unsafe behavior.  The two most common examples of this are divide by zero behaviors and “hard” floating point comparisons (e.g. FloatVar == 1)

Minimize impact on end users

The MAAB working group recognized that rules that place a high burden on engineers will be ignored or subverted.  In part to address this The MathWorks created the Model Advisor tool which automatically checks models for compliance with the MAAB style guidelines (other, custom, checks can be added)

Support use across multiple companies

The final point and one that often introduces confusion is the fact that the guidelines were written to support workflows for companies with different design patterns and workflows.  Because of this there are multiple checks that state “Please select either pattern A or pattern B”  (See NA_0005)

 

Final thoughts

The M.A.A.B. style guideline is intended to be a living document.  End users should take it and modify it to fit their specific needs.  By its nature, it is a conservative document; intended to meet the needs of multiple companies.  For more information on how to utilize modeling guidelines the following paper SAE paper or the summary technical article on The MathWorks site.