Chasing a single source of truth

With his black outfit, Jon Holt is more likely to be recognized as a magician than a system engineer. Actually, he’s both.

Let’s start with the magic. This is the stuff he uses to inspire. As a professional magician, he performs at music festivals and various science and technology events, using magic, mind reading and sometimes escapology to explain engineering principles. “We do things that are based on mathematics, science and memory techniques. I try, for instance, to explain to people how important visualization is, as a design concept.” He smiles: “There’s a selfish aspect. I enjoy it as well. Give me an opportunity to show off and I’ll take it.”

Jon Holt: “Give me an opportunity to show off and I’ll take it.”

Holt has also written a rhyming storybook based on systems engineering, aimed at children from ages seven to eleven. As the technical director of the International Council on Systems Engineering (Incose) in the UK, he works to raise that awareness together with professional bodies aimed at families with children. “It’s important that we don’t just think about where we are but also about the next generation of all engineers.”

Holt encounters a lot of misconceptions about engineering. “The term is very badly understood. Many people still think I fix things that are broken. Well, not quite. Engineering is seen as boring or not interesting. For me, that couldn’t be further from the truth. Look at the incredible systems we work on. Children can’t be separated from their mobile phones now. I’d like to get people to appreciate the engineering in that phone.”

Incose has identified Holt as one of the 25 most-influential systems engineers in the last 25 years. He’s internationally recognized as an expert in the field of model-based systems engineering (MBSE) and has authored 17 books on the subject. He’s also a professor of systems engineering at Cranfield University.

In Holt’s career, MBSE has played a central role. At last year’s Bits&Chips Sysarch conference in Eindhoven, he stated that all systems engineering would be model based in 2025. “If you go back 10 years plus, I’d spend all my time arguing with people if modeling is a good idea. At conferences, people would throw things at me because they didn’t want to model,” he recollects. But this has changed. “Now, the question is no longer: should we model? But rather: how do we model effectively and efficiently?”

Holt sees the shift in his work with large multinational organizations that have twenty-year-long product life cycles. “They want to shorten those cycles. Quality is obviously a concern, but their main driver for employing MBSE is to improve the efficiency of their processes. The human side of things comes into play as well. Companies want to make sure their staff has the appropriate skills and apply MBSE to that.”

Four changes in complexity

To explain complexity, Jon Holt compares the old Triumph Herald car he owned in the seventies with his most recent car. “The basic need is still getting from A to B, the human-machine interface is still a steering wheel, a gear shift and three pedals. But the complexity of these systems has changed over the last few decades.” He describes the change in four specific ways.
“The first way it has changed has to do with the system elements. They were 95 percent mechanical. Probably slightly under 5 percent was electric. In terms of the interfaces, the Triumph had mechanical interfaces and electric to mechanical. Very few were electric interfaces. Now we’ve also got electrics and software. With these elements come networking and communication protocols. We’ve got far more complexity.”
Next are the constraints. “The only safety measures in the old car were the seat belts in the front, and you didn’t even have to wear them – that was optional. There were no seat belts in the back. In terms of crash protection, the car was made of very thick metal. You just had to make sure that it was thicker than whatever you were going to crash into. That was safety back in the 60s and 70s. Today, you wouldn’t get in a car without wearing seatbelts. A modern vehicle has airbags, antilock brakes, and it will stop you from crashing into something else and from veering into another lane. The complexity has gone up. Not only because of the constraints, but because of the source of all those constraints like standards and legislation. All those best-practice models didn’t exist in the 70s.”
Third, is connectivity. “In my Triumph, the main type of connectivity to the outside world was me. Now the car is actually part of a wider system of systems. It connects to the cloud, to road signs, to the UK and European road networks, and talks with other cars. That comes with a whole new level of interfaces. I’ve got an app to tell me where my electric scooter is at all times.”
The fourth wave is the shift in complexity. “In my old car, the complexity was in the internal combustion engine. The complexity has shifted to the software. The mechanical complexity of a motor in a modern electric vehicle is very, very low, whereas the software complexity is very, very high. The software does all the control and it takes care of all the connectivity. Over the last few decades, the complexity has increased beyond recognition.”

Connecting engineers

Apart from that, working model based might also be the key to connect engineers. Here, we touch on the ambitions of Ger Schoeber, the chairman of Incose Netherlands, who we invited to sit down with us during the interview. Schoeber recently joined Lightyear as group lead systems engineering. He’s also responsible for systems and software training at High Tech Institute. In his past years as Incose chairman, he worked on bridging the gap between the engineering worlds of infrastructure and high tech.

Painting these two very different worlds in black and white, Schoeber says: “Engineers in public projects deal with contractors, subcontractors and contracts. Their focus is paperwork and processes, and the system comes second.” On the other hand, the high-tech industry is commercially driven. “There, the focus is time to market. Otherwise, they can’t compete and certainly won’t conquer the world. That’s why the approach is pragmatic and focused on the system, the product.”

Schoeber’s roots are in high-tech, but as Incose chairman, he observes that the Dutch chapter members typically work in infrastructure projects, building railways, roads and tunnel systems. “We have a big high-tech industry, but not many engineers know Incose.” The opportunity, according to Schoeber: “I’m sure that both worlds can learn a lot from each other.”

Single source of truth

MBSE is a common denominator, Schoeber and Holt agree. It can help high-tech to make even better products. The techniques that high-tech and civil engineers apply to develop systems and deliver them successfully must improve to cope with the added demands and complexity. The most common way is to apply model-based techniques. Holt puts it in very simple terms: “Traditionally, engineering relied very heavily on documents. For design, for understanding the requirements and so on. That worked very well for many decades. A perfectly good, solid approach. But as the complexity starts to increase, if all the knowledge, data and information associated with a system is split across multiple documents – and we’re talking thousands – just maintaining consistency is very, very complex.”

Ger Schoeber: “Most important is not the model, but to use common sense.’

In a model-based approach, all knowledge and information relevant to the system are kept in one place and kept consistent. “In that way, we have what’s often referred to as a single source of truth,” says Holt. “We can maintain that single source, and if done properly, that guarantees that the documents based on this single source of truth will be consistent. So rather than distributing everything throughout thousands of different documents, we’re bringing it all together in a single source of truth. For anything we want to know about the system, we interrogate the model. That’s where the information resides.”

Elaborating: “People say: a model can never be complete. Well, it doesn’t have to be. It has to be as complete as necessary to deliver our system. It can never contain all the information of the system. There’s got to be things missing, but that doesn’t mean it’s wrong. We focus on the relevant information to develop that system. It’s got to be useful and has to benefit what we do. If it doesn’t, then forget about it.”

Brontosaurus of complexity

To explain the impact of complexity on systems engineering, Jon Holt uses the brontosaurus theory problem. This theory is an analogy that states that the magnitude and complexity are directly proportional to the thickness of the animal. “At the beginning of a project, you look into the smiling face of the brontosaurus,” clarifies Holt. “The complexity is low, it’s thin at that point. You look at your requirements and think: yeah, that makes sense. You smile because it’s simple and the brontosaurus smiles back at you. You live in a very happy, if somewhat naive world.”
But then systems engineers come in with their cost, time and resource estimates. They start to apply their systems engineering principles. “They start modeling, identifying stakeholders, creating scenarios and while heading down the neck of the brontosaurus, the complexity goes up. When someone is showing you diagrams as big as a wall, you know you’ve arrived in the belly of the brontosaurus. Because although the diagram is very clever, nobody can understand it. And you’ve got people using all kinds of different methodologies and tools. Or even worse, using the same tool but slightly different versions that aren’t remotely compatible with one another.” Holt, from his experience: “All contractors leave at this point. Life is getting a bit too tricky for them. It looks like it’s the end of the world.”
But there’s a solution. “The problem is complex. It’s difficult to understand and almost impossible to communicate to all the different stakeholders. It’s very frustrating because as a systems engineer, you say: hang on, I’ve done this thing right, I’ve applied these principles, yet, I’m in the belly of the brontosaurus.” Then something interesting happens, says Holt. “Because if you continue to apply your techniques, the complexity is going down and down and down, to the tail of the brontosaurus – and this is our goal. And at the tail of the brontosaurus, you’ve got a concise, elegant solution.”

Holt’s message: when you look at any kind of real problem, as soon as you start to apply systems engineering and modeling, it gets more complex before it’s going to result in an optimal solution.

The model and its views

The basic function of a model in MBSE is to communicate. It has to enable the system engineer to discuss the system in development with all its stakeholders, the financial department, the customer, the boss, the engineering team or some standards organization that wants to see if the system applies to all safety regulations.

For all those different stakeholders, there are so-called “views” (of the model). They’re the basic units in a model. Each of them is a collection of information with all the information a specific stakeholder needs to know about the system in development. Holt: “First of all, it has to be a valid view. If you can’t identify one of your stakeholders who would be interested in looking at that, then don’t do it.” Second, the stakeholder should benefit from looking at this particular view. “If you can’t answer that, it’s not relevant. It’s not a view.”

“If you imagine the model as a big amorphous blob of information, each view is like opening a tiny window into that model,” Holt continues. “We’ve got to make sure we open up enough of these windows to give us an understanding of the model as a whole. Because of the many stakeholders, we have to make sure that all views are consistent. Otherwise, it’s not a model.” He uses SysML as a modeling language, but in fact, you can use any language. It’s about doing it properly, to end up with a consistent model.

Holt uses models as a basis for the contract, for instance. “When companies in different sectors, like aerospace, power or the nuclear industry, put out a tender, they put out their specifications for the bids coming. What they actually do is putting out a set of views, which they submit as the technical part of their tender.”

The advantages are clear: “The model is becoming part of the contract. If four people bid for the tenders, they’ll have completed bids for the same set of views. For the customer, it’s far simpler to compare them than text-based descriptions, for example. The other advantage is that the set of views – the submitted model – actually then becomes a contract. Contractors will have to deliver on clear information.”

The high-level set of views in the conceptual level later become almost like the acceptance criteria for whatever is delivered. “This can be applied to infrastructure, as well as to more high-tech and commercial industries.”

Schoeber points out that the system architect or systems engineer plays an important role as the translator of the views in SysML to stakeholders without a technical background.

Appetite

Automotive is a good example of an industry that has developed a big appetite for MBSE, says Holt. “It started five years ago. The complexity has changed as time has passed. Compare an old car from 30, 40 years ago to a modern car and look at the complexity of the system elements, connectivity or the safety constraints. We’re seeing that the complexity has changed beyond all recognition. The techniques that we could apply to what was perceived as a modern motor car twenty years ago just aren’t good enough now. They aren’t rigorous enough to apply to a modern vehicle that’s part of a wider system of systems. MBSE gives automotive a competitive edge. If they don’t apply it, their competitors will produce better and more reliable products.”