Model based systems engineering’s role in today’s markets

You’re looking at a lens cap on the surface of Venus. Back in the early 1980s, when the Russians were still launching probes to Venus, they launched this probe with the goal of taking pictures and testing the Venusian soil content.

Given the planet’s pressure, temperature and acidic atmosphere, the probe had less than 30 minutes to get the job done.

This picture from the surface of Venus is just one example of seeing a problem after it happens, not before.

After the Venera 14 probe landed on Venus, it popped its lens cap, started taking pictures and tested the soil. What makes this picture interesting is where the lens cap landed. You can see the lens cap happened to land directly underneath the place the soil sampler would test, so the Venera tested the lens cap instead. When it sent back a message that there were advanced polymer molecules on the surface of Venus, the controllers slewed the camera to take this picture. 

This story exemplifies a number of things. One is that the Laws of Murphy are universal. You may know these laws as anything that can go wrong will go wrong, toast always falls buttered side down or any line you stand in will be the slowest. 

Back here on Earth, universities are taking the laws of Murphy seriously. At Aston University in the U.K., for example, researchers have tested the laws, including the assertion that toast always falls buttered side down. Working with the Daily Telegraph, Aston University enlisted 1,000 students in the U.K. to do 20 samples each of toast falling off the side of their plates. 

The results showed that the toast falls buttered side down 62.3 percent of the time. I know what you’re thinking; the butter added weight on one side and caused it to land face down. So they ran the test again, this time with the letter ‘B’ on one side. The results stood at 62.3 percent. 

This is not random. Toast is actually pre-disposed to fall buttered side down. You’re not paranoid: the universe is indeed out to get you. 

Murphy’s Laws are alive and well in almost all industries, especially in today’s complex products.

Need proof? According to the National Highway Traffic Administration (NHTSA), there were more than 63 million recalls in the automotive industry in 2014, including the GM ignition key and the Takata air bags. The NHTSA estimates that each recall cost roughly $100 each, resulting in a financial blow totaling $5.5 billion and hundreds of lives. 

The issue here is that we can see problems after they happen, not before. But what if these companies had seen the problems coming and did something about it? Or, what if they had at least considered the risks and designed their systems to avoid problems rather than figure out how to pay after they discovered the problem? 

After I reported one such problem in a staff meeting, the program manager put it to me this way: “Sampson, why don’t you give me something where I can see the problem coming?” It’s like driving a car looking through the rearview mirror: I can see the problem after I’ve run over it. 

This is exactly what model based systems engineering is about. It evaluates the many different possible impacts on a problem and architect solutions that avoid these problems. 

So why didn’t these organizations invest in model based systems engineering? 

It comes down to how to justify an investment in something that may happen versus something we’re already spending money on. That’s why we get pushback from management and accountants who ask questions of who’s going to pay for all of the upfront model based systems engineering work. They want to know how much money you’re currently spending that won’t have to be spent in the future. 

When these types of events happen, everyone wants to put it behind them, and that makes it difficult to learn the lessons. But what if someone documented one of these experiences so we had evidence that management and accountants could see? 

Thus, the allegory of the humidifier. 

This concludes part one of our series on why businesses need model based systems engineering. In part two, Mark Sampson details how a lack of a systems engineering plan wreaked havoc on a company. 

Tell us: What do you think is the most frustrating problem with seeing issues after they happen and not before? 

About the author
Mark Sampson is a product manager/evangelist on the System Driven Product Development Team. He is responsible for integrating systems engineering and requirements within the product lifecycle management (PLM) business at Siemens. His work with this integration helps customers enable systems engineering and its requirements to participate and influence all aspects of product development.