Month: August 2020

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.

Enter the MAAB

What isn’t style?

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.

Footnote

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.

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

Model-Based Design “documents”

Safety critical document (4)

Verification processes

Footnotes

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

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)

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.

Lean mean, computational machine

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

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

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.

Footnotes

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.