A sense of fashion: Modeling style

Chances are if you have read 5 or 6 of these posts you could identify another of my posts based on the style (1) of writing. In the same way you can often identify who created a model based on how things are composed.(2) Modeling guidelines are the equivalent to the office dress code of professional attire, (3) intended to act as a baseline while still allowing individual variation as needed. A good modeling style allows users to quickly understand the functional components of your model.

Ah the 80’s and the Parachute Pants

Enter the MAAB

The MAAB Style Guidelines are the “basic tuxedo” for the Simulink / Stateflow / MATLAB modeling. If you follow them you will be welcome at any party. (4) (5)

The next level of modeling style is the use of modeling patterns.(6) This is where your organization defines its style. Modeling patterns cover common operations or algorithms unique to your project. These can be saved as library blocks or documented as a best practice.

What isn’t style?

The dividing line between style guideline and implementation can be understood with one question:

Does conformance to the style guideline impact the functional correctness of the algorithm?

I highlight the word correctness for an important reason. There are times when style guidelines will result in slightly less efficient implementations e.g., you trade off understand-ability and maintainability for efficiency; and this is okay.(6) However, if the guidelines impacts the correctness of the algorithm then it should be noted and ignored.


  1. I like to think of the style as a hybrid of Terry Pratchett footnotes, Mark Twain wry humor, and Theodore Sturgeon “twist endings” (with his empathy). The pacing is of my own design.
  2. This extends beyond individuals; my first job had very formal requirements on indentation, formatting of C code. The approach I learned then influences my coding “style” to this day. I can also recognize people who went through the same training program just by looking at their code.
  3. As of this writing, with many people working from home, the concept of a dress code has changed somewhat, such as the “professional attire + hidden cozy slippers.”
  4. In this case “party” means your co-workers; follow them and then they have a consistent way of understanding what you are modeling.
  5. Like a tuxedo, the MAAB guidelines are what are on the “outside” they do not dictate what your algorithm is and how it functions.
  6. In reality this happens only infrequently; most of the style guidelines were written with efficiency and clarity in mind.

My Model-Based Design Bookshelf

While I write this blog there are a number of sources I draw on as reference; I wanted to take a chance to acquaint you with them.(1)

The Standards

The standards down into three categories

  1. Modeling Standards: For the Model-Based Design community (Simulink) this points to the MAAB Style guidelines (2)
  2. Coding Standards: There are two things I look to here:

Model-Based Design “documents”

Safety critical document (4)

Verification processes


  1. Beyond introducing you to these documents, it gives me an easy place to keep all this information to point my customers to…
  2. The 5 years I spent working on versions 2 and 3 is some of the work I am most proud of.
  3. A couple of notes; first the joke about conformance can make you MISRA-able has been done many many many times. Second, with modern automatic code generators it is fairly straight forward to be MISRA compliant. Third, if you look in the dedication section of the MISRA-C-2012 you can see my name.
  4. I remembered the song “Safety dance” but I had forgotten how odd the video was, it seems like a mishmash of the movie Willow and praise of Morris dancing.
  5. Ok, the repeating was a cheap re-use joke

Mega fauna models

Recent studies (1) suggest one reason for the waves of death of mega fauna can be attributed to the arrival of humans into the ecosystem. Large animals that could thrive in competition with each other quickly succumb to the fast moving ape with a mind. The COVID-19 event is a trigger for multiple changes in how we develop software; to paraphrase, the apes are coming for the mega models with the tools the monolith provided.

What is a “large model”?

I have written before about how to measure the size of a model. Today I want to focus on what it means to be a “right-sized” (2) model and what it takes to realize it in practice. First off, going smaller does not directly correlate with less work; doing something well in a small space is harder. (3) (4) Second, clarity should, rarely (5) be sacrificed for size. With those thoughts, we will tackle “right-sized.”(6)

I am working from the following axioms driven by COVID

  • Fewer “informal” review points(7)
  • Greater reliance on Simulation based verification(8)
  • Use of coverage metrics in reviews
  • Use of specification documents in reviews

The primary purpose of having a “right sized” model is to facilitate the verification and validation processes applied to the model. To that end, anything that makes the review of the model easier or more complete should be pursued.

  • Aim for 30~ 45 minutes: An online review of a model (or portion of a model) should take between 30 and 45 minutes.(9)
  • Provide automation results: The reviewers should never have to check that the interface, style, or test requirements are met.
  • Define the acceptance criteria: What are you trying to get out of the review and what do you need to provide to get it?

Lean mean, computational machine

So now that we have our “right sized” model, what happens?

  • Pros
    • Faster design cycles
    • Fewer bugs
    • Simplified revision / maintenance
    • Higher test / requirement coverage
  • Cons
    • Possible increase in required memory
    • Possible increase in execution time

To Recap

In a previous blog I wrote about how to measure the size of a model. Today we focused on what we do with that information; e.g. setting the “right size” which is going to be a function of

  • The complexity of what you are developing
  • The experience level of your development team
  • The maturity level of your development environment.

Highly complex systems will push you toward smaller models while experienced teams and mature environments will support larger models. In the end this will be a balancing act.

A wonderful example of static equilibrium


  1. When I was growing up, the main hypothesis was that mega fauna extinction events were tied to large scale natural disasters. I was going to write this blog post suggesting that the death of large models could be attributed to the natural disaster of the COVID crisis. Since this is not the case, I thought I would share this information and take a different tack.
  2. Even with the section title including “large model” I want to move away from the idea of “large” and “small” models; rather I want to talk about the idea of a “good fit”
  3. For instance, the sentence you just read. The original draft of it was 2 times as long to say the same thing. It is easy to explain things in 1,000 words, but getting the same thing across in 100 can be a pleasurable feat.
  4. Informally I would estimate 5~10% of all models is “bloat”; e.g. functionality that could be eliminated through revision.
  5. It’s unfortunate I needed to write the word “rarely” there. I wanted to write never but I must bow to the fact that there are some instances when the algorithm can only be realized in a way that is unclear to most people. Note as a best practice when this happens, the portion of the code should be extracted into its own function so it can be treated as a black box for the end user.
  6. The observant among you will notice that I chose “right-sized” to denote the active nature of the work.
  7. We will cover how to have “informal” meetings in later posts, but the “quick questions” that developers use to break through problems are more difficult when working remotely.
  8. This is an overdue trend; the ease of “going to the X to test” means that people often will do that instead of paying the up-front cost of developing the Simulation based test environment. In the medium run, the SBTE pays back on the investment.
  9. In longer online meetings, it is hard for people to remain focused on the topic; without the “in person” awareness of this, it can be hard to maintain the correct tempo of the review.