When my then girlfriend and I moved into a tiny two-bedroom apartment in Long Beach, California, we started to learn a lot about each other’s routines and behaviors. We quickly found out that she absolutely could not stand an unlidded toilet seat, and I, an unmade bed. I made my bed every morning, or as soon as possible after if I was running late. I could not tell why I disliked it so much, maybe the unsightly clutter of bed sheets and pillows, or maybe the thought of slipping back into that mess at the end of the day. Eventually, it took a real leader of men to explain to me what I had subconsciously attempted to do all along.
On May 17th 2014, Adm. William H. McRaven, ninth commander of U.S. Special Operations Command, delivered a Commencement speech at the University of Texas, Austin. Adm. McRaven encouraged the graduates to change the world through the 10 life lessons from his time in Basic SEAL training. One of which was about a simple routine: make your bed every morning.
“It was a simple task — mundane at best. But every morning we were required to make our bed to perfection. It seemed a little ridiculous at the time, particularly in light of the fact that we were aspiring to be real warriors, tough battle-hardened SEALs, but the wisdom of this simple act has been proven to me many times over.
If you make your bed every morning you will have accomplished the first task of the day. It will give you a small sense of pride, and it will encourage you to do another task and another and another. By the end of the day, that one task completed will have turned into many tasks completed. Making your bed will also reinforce the fact that little things in life matter. If you cannot do the little things right, you will never do the big things right.
And, if by chance you have a miserable day, you will come home to a bed that is made — that you made — and a made bed gives you encouragement that tomorrow will be better.
If you want to change the world, start off by making your bed.”
I seek to change the (Systems Engineering) world, therefore, I will thrive on doing even the little tasks right. And, I will start off by always describing my functions correctly.
Many true practitioners of model-based systems engineering (MBSE) will find that the system definition language (SDL) can only be useful as long as its parts of speech are meaningfully created. Lucky us, the simplified engineering metamodel (or the DoDAF schema if you are really into capability architecture development) already provides the necessary means to a successful system design end. All we have to do is simply fill in the vocabulary “blanks”. Trivial. Or is it? With the same available tools, what sets successful MBSE practitioners apart is the willingness to complete the mundane “first task of the day” and to “do the little things right”.
“First of the day” can be literal, but does not have to. It can be when you open up the model in the morning. It can be the starting point of your involvement in a brand-new modeling project. Even more radically, it can be your do-over moment when you hit the proverbial wall of the writer’s block. Writing function descriptions may sound like an over-specialization of such modeling philosophy. But for the sake of argument, let us examine how it fits in the concept of starting your MBSE day.
What makes the task of writing up a description (of a component, a function, or an item) seem trivial and mundane is the obviousness of such content in our own heads. We know exactly what the function does because we created it. The task becomes a chore when we have to do the extra work for others’ sake. Writing up a description can sometimes be disruptive to our train of thought, especially function description. When you are “getting in the zone” with your EFFBD, the last thing you want to do is take your mind off the loop-exit logic to describe the five functions you have just created. But, have the courage to complete that first task of the EFFBD day. You will be glad you did.
The first reason to take good care of your function description is the ability to recall and understand your own modeling rationales. Have you ever revisited a week-old functional flow and tell yourself, “Can this be better if I change this one thing”? How many times have you tinkered with an EFFBD consisting of five, ten, or twenty functions? The older the model is and the more functions there are, the more likely you will experience a drift in your modeling logic over time. “Is this function still what I meant for it to be?” This is where your very-detailed descriptions come to the rescue. A small task done right today will help you complete an even bigger task tomorrow: perfecting (or more practically, improving) your entire model consistently. It will give you a sense of pride in your modeling methodology: “I understand all of my logic, and I can clearly recall it days after.”
The second reason to pay attention to your function description is to avoid self-deception. Understanding what your function does not do is as important if not more than understanding what it does. Confusion and misunderstanding leads to dysfunctions in the design process. Even worse, it could lead to unintended capabilities in the final product. Though correctly naming a function is critical, a name can only be so lengthy and so meaningful. The function description continues to clarify its meaning, including the underlying one. Reading such understanding in writing will help you re-examine what you have originally envisioned in your brain. You will be able to answer, “Is the function still doing what you have hoped?”
The third reason to invest time in your function description is to understand the items the function consumes and produces. As a function has inputs, outputs, and triggers in the metamodel, a complete understanding of what the functions do will lead to correct selections of their inputs/outputs. Take the primary flight display of a modern aircraft for example. There are hundreds of ARINC-429 labels consumed by the Flight Display System Application (FDSA). Each label works independently or in conjunction with other labels to drive a specific display widget. Define each display function in detail and you will be able to 1) associate them accurately to commercial off-the-shelf (COTS) inputs or 2) identify gaps between the design needs and current technology.
The benefits of good function descriptions do not stop at accurate inputs and outputs. Good item definitions will lead to good physical link definitions. Good physical link definitions will lead to a solid system interface design. One complete small task of describing your functions leads to many bigger tasks completed in building the metamodel.
What are other “little things” we can do right to succeed in MBSE? Naming your function in a meaningful way is a frequently overlooked idea, but it is important nonetheless. The language in systems engineering matters. For example, I never start a function name with “support” or “provide”, and rarely use “perform”. When I teach systems architecture, I often tell my students the following:
- “Unless you are referring to the function of a parent providing for her children, no other names of engineering functions should start with “provide”.
- “Unless you are modeling the function of table legs supporting the table weight, no other names of engineering functions should start with “support”.
- “Unless you are creating the function of a dancer performing on stage, no other names of engineering functions should start with “perform”.
Those are just tongue-in-cheek examples. Nevertheless, the problem with these so-often “convenient” verbs for a function name is they are grossly generic and vague. Does “Provide Bank Angle Indicator” mean the function will display a static graphical representation of the bank angle? Or, will it move the bank angle indicator dynamically as the aircraft turns? Or, will it simply make the display interface available for bank angle data? A system modeler might be tempted into naming functions generically, especially when it seems difficult to express their ideas in writing. However, this poor engineering practice can allow confusion and misunderstanding to fester in the design process.
It is worth mentioning that I rarely allow “perform” in a function name, but not never. When naming a high-level function as a collection point or a root function of an integrated behavior, “perform” is acceptable. You are indeed purposely making such parent function all-encompassing at the given level of system behaviors. Any other usage of “perform” in an attempt to name real system functions will trivialize them the same way “provide” and “support” does.
Along with accurate function descriptions, meaningful function names will eliminate the modeler’s self-deception. The name alone should be specific enough for the reader to understand what a function does exactly, and more importantly, what it does not do. The function description will then further explain and expand on how the function accomplishes its goals. A good name and a good description force you to take the time to think through and understand the nature of your intended logic inside and out. Only then can your model truly become the authoritative source of truth in the system design.
A good MBSE practitioner delivers a high-quality final product, but a great practitioner knows all the small tasks needed to do so consistently. With the help of a robust schema, we can start anywhere in the model and will be able to embrace and exercise this design philosophy. Start your MBSE day off by completing the first task right, no matter how mundane. Then pay attention to the little things in your model which will build up to affect the success of the entire design. And, if by chance, you have a miserable day reviewing “it shall support” requirements, you will come home to a meaningful system view that is more than just a pretty picture.
