At last year’s Sysarch conference, model-based systems engineering expert Jon Holt sat down with High Tech Institute’s Ger Schoeber to discuss the MBSE training. “In five years, all systems engineering will be model based,” according to Holt, currently the technical director of Incose UK.
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 five years, all systems engineering will be model based.'
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.”
'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.'
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.”
Where does one start with MBSE? Holt points out it’s important to answer the why question. “If you can’t answer that, don’t do the work. It depends on the context. You have to ask what it is you’re looking to improve? What is it you’re setting out to do in the first place? It might have all kinds of emphasis, something commercial or things like quality attributes, a better product that’s safer, more reliable, more maintainable. Or look at security. You can steal a car by using a mobile phone, it’s crazy. The requirement to prevent that didn’t exist five or ten years ago. Now it’s becoming a standard demand from customers. There are no 100 percent autonomous vehicles yet, but we have driver assist, communication with road signs and collision avoidance to stop us from drifting between lanes. These are standard features, not optional extras in a modern car.”
Holy grail?
Is there a danger that MBSE is considered too much as a holy grail? Schoeber: “What worries me a bit is if we look at MBSE and all the tooling that comes with it, that we trust the tools too much. You have to make sure not to lose your common sense.” Holt shares Schoeber’s concern: “To think critically and question things is one of the systems engineer’s skills. We have to keep on asking why. You can’t bypass that.”
It’s also about managing people’s expectations, finds Holt. “Like any solution, MBSE isn’t a silver bullet. It’s not going to cure all our ills in one single shot. You have to know what you’re hoping to achieve, and very importantly, how you’re going to measure what you’ve achieved. Part of the problem is that people oversell the tools.”
According to Holt, the level of maturity in MBSE varies enormously between different organizations and industries. “Certainly in the UK. Traditionally, model-based systems engineering was always the domain of military, aerospace and later, rail. But now, if you look at the current roadmaps of automotive, they’re having a good time.”
Different industries also deal with different time schedules. Consumer electronics developments are shorter than infrastructure projects. Longer developments aren’t more relaxed per se, Schoeber points out. “The European Space Agency in Noordwijk has been using SysML for over 10 years. At ESA, a lot of countries work together to get satellites produced. You only have one chance for a successful launch. But on the other hand, they sometimes have to make tough choices when running out of time after 10 years of development. Then they have to decide: take the risk to skip some testing and verification phases to meet the launch window, or accept a huge amount of cost that comes with a year of delay?”
In the high-tech industry, Schoeber sees a playing field with many heroes, the creative and proactive people who take the lead in developments. “Look at ASML. That’s a hero-based company. But with a market share of almost 90 percent and enormously complex systems, they feel the need to do some processing and modeling in a more formal way. Otherwise, they won’t survive the next ten years.”
Are models replacing the heroes? Holt: “I think there’s always a need for heroes, but you won’t need anywhere near as many if you have a good approach in place. Often the heroes are there because things haven’t been done properly and they need to fight fires all the time. A lot of those things could be avoided. Space is a really good example. Until you fire your rocket into the sky, you don’t know what’s going to happen. You can put mechanisms in place to minimize the risk, but you can’t mitigate everything. Yes, you do need heroes, but we shouldn’t be relying on heroes for everything.”
Schoeber: “Most important is to use common sense. Systems engineers have to be brave enough to stand up and take responsibility. Because that’s what really makes a hero.” Holt: “It’s not so much that they have to meet the letter of their contracts, but rather the underlying intent.”
This article is written by René Raaijmakers, tech editor of Bits&Chips.
