One thing I have learned in my career as a systems engineer is I still have aha moments. And when students of mine have aha moments, I am equally gratified. I recently taught a class on model-based systems engineering that includes hands-on MBSE exercises in a tool environment. In the class, we looked at general systems engineering concepts like requirements, behavior (as in functional control, functional sequencing, and triggering), and architectural analysis. We also discussed the importance of integrating systems engineering in layers and across systems engineering domains.
The way my class works, I explain a concept, then release the students to go work in an onsite lab to model a design using the concept they have just learned. In this case, I had asked the students to build an Enhanced Functional Flow Block Diagram (EFFBD), to model behavior which could then be verified using the integrated discrete event simulator in Vitech’s GENESYS product.
Example of an EFFBD diagram
This allows engineers to see graphically as well as textually the execution of their models. One student carefully built a model, thinking he had followed all the appropriate steps. But time after time when he ran the simulator, he got an error where a function didn’t execute because it didn’t receive a triggering message. Curiously, he seemed both annoyed and, if not happy exactly, intrigued. I could tell he was having an aha moment—I could almost see the light spread across his face as a new idea dawned on him.
When I asked him about it, he told me that in the design environment at his place of work, “This [error] wouldn’t have been found.” He would have had no clue that they had designed something incorrectly. His aha moment was the realization of the benefits of an integrated, model-based systems engineering environment. In such an environment, standard views have real meaning. They reflect the engineering and aren’t static boxes and lines or disconnected Word-published diagrams.
They are not, in other words, what I call “pretty picture” views, i.e., text-only artifacts many of us continue to use.
We also discussed how to recognize a problem using model-based systems engineering, and how much more easily problems can be seen using such a tool, because the engineering view is a live rendering of the engineering data, and significantly more than a pretty picture.
“An ugly drawing or view,” I told the class, “probably means the engineering behind the view is ugly.” Maybe not ugly, but not totally right. Using Vitech’s STRATA methodology, our GENESYS tool, and a bit of systems engineering expertise, systems engineers can see problems in the design, make changes in a single location within the model, and in so doing automatically update every engineering view and report artifact to ensure they consistently reflect the current design. Before sharing updated views, engineers can also re-test the design using the integrated discrete simulator to build confidence that the design is correct.
My student found his aha moment simulating behavior, but I’ve personally had aha moments while modeling. I clearly recall building a functional string—some know them as scenarios or threads—when I noticed I needed a triggering message for my functionality to execute. One would think that’s a minor change, and indeed, creating the triggering message in the model was easy. However, this question led to another question: Where was the message generated?
In searching for the function to generate the message, I discovered it didn’t exist. My inability to find a source or generating function led to the development of an additional behavior. In addition, the message analysis led to an interface analysis, because the message had to be serviced by an interface. The additional work could have been considered annoying or a distraction, but it was actually imperative for good design. Think of the alternatives. If the design had progressed along the design life cycle and the missing message wasn’t found until a first-build prototype was completed, the cost to addressing the missing message then would have been significant. Finding errors early in a design isn’t glamorous, but that’s the life of an engineer.
In 2004, NASA Johnson Space Center released a paper, Error Cost Escalation Through the Project Life Cycle. The paper details the escalating costs of finding errors, inconsistencies, or incompleteness, and how the later a design change is required, the more it costs. Vitech’s chief methodologist and first president Jim Long is quoted as saying, “Once you pick a problem, the amount of systems engineering you must do is fixed.” The question is when you will do it and how much it will cost. Using our methodology and tools facilitates finding issues during the early stages of design.
Other ways to find ahas are through the use of automated tools. I use standard reports daily—automated design completeness and consistency checks, and hierarchy and traceability views—to identify work I need to perform to mature my models and designs. Much like my engineer, I also use the discrete event simulator to understand the emergent properties of my design that I probably wouldn’t have seen using spreadsheets, drawings, and word-processed documents. I don’t want you to think I don’t use MS Office to communicate—I absolutely do, but I use a model-based systems engineering methodology and integrated tools to create better, more complete, more consistent designs. As I do so, even after 30 years of practice, I still experience a few ahas along the way.
Try applying our methodology and our tools. You may experience a few ahas of your own.
