systems engineering

Lost in Translation – How MBSE is Evolving to address Today’s Complexity Challenges

Menu

Mission complexity is growing faster than our ability to handle it. As traditional methods are coming under pressure, the evolution of model-based systems engineering promises help. David Long, President of the systems engineering company Vitech, explains how.

David_Long“Any organization involved in systems engineering will recognize four things”, says David Long, President of the MBSE company Vitech that became part of Zuken last year: “Firstly, mission complexity is growing faster than our ability to handle it. Secondly, we’re managing the pieces of problems rather than architectures. That’s resulting in systems that are overly complex, hard to test, and expensive. Thirdly, knowledge is lost within projects, specifically at the lifecycle boundaries, when signing off on a design and handing over to production, thus increasing the risk of discovered-late and expensive-to-fix problems. And lastly, knowledge is lost between projects. We just don’t seem to learn from our experiences.”

“We have exceeded the capabilities of the siloed world”

In other words, we have exceeded the capabilities of the siloed world that we built to solve engineering problems. In addition, there are more silos today than ever before. It’s no longer just hardware, software, and mechanical engineers contributing to an overall solution. It’s customers, supply chain experts, biologists, functional safety experts. And it’s different environments and players in an increasingly connected world. “The silos we’ve built up cause us to ignore some critical concerns”, summarizes David. “This is the reason why systems engineering exists and therefore that’s why systems engineering itself is trying to evolve.”

A translator operating above the hardware, mechanical and software silos

As a methodology, systems engineering has been developed and refined for several decades to keep pace with the technical challenges associated with complex systems. Be that ‘system’ a standalone product or, increasingly, a product that interacts with others. “Systems engineering problems are trans-disciplinary. Systems engineers must get the best out of each of the disciplines involved”, says David.

The fundamental role of a systems engineer has therefore always been that of a translator. For instance, in the not-so-distant past, when systems were predominantly electro-mechanical, with perhaps some code in a microprocessor, the systems engineer would operate above the hardware, mechanical and software silos to help align the understanding (of all parties) of both the problem and the solution. Communication between all parties was historical via documents and drawings. “We would work from fuzzy first concepts, through detailed design and through into manufacturing operations and test. And some great things were achieved. Presently, the industry is taking its next evolutionary step as we go ‘model-based’, and place greater emphasis on communications and interactions of a system’s components.”

Moving away from documents – enter UML and SysML

In the 1990s, as systems evolved from electro-mechanical to ‘software-intensive’ systems, system complexity increased and so did the communication challenges between systems and software engineers. To address both challenges, some engineers experimented with applying the unified modeling language (UML) to systems. However, UML was not intended to operate beyond the bounds of software. So while communication had improved between software and systems engineers, the hardware and mechanical engineers experienced no benefits.

The solution was to develop something more encompassing but, at the same time, ‘smaller and simpler’ than UML; and so was born the system modeling language, SysML, to overcome UML’s software-centric restrictions. It is a diagram-centric approach that relies on a set of nine standard diagram types, seven of which are used in UML. Plus two additions for requirements and parametric specifications, the latter being used for performance and quantitative analyses. So, is SysML all we need? Not quite, says David.

David is ready to acknowledge that there is value in SysML as a communication mechanism, between those trained in the notation. But what about everyone else? He cautions: “We should never lose sight of the fact that systems engineering is a trans-disciplinary journey.”

But just what do we need to make a system description more explicit, coherent and consistent? David has a clear answer: “Rather than drawing diagrams, we should focus on creating explicit (i.e., not open to interpretation) information models to capture, analyze and communicate the knowledge required to engineer a system.”

The Vitech approach – more than a diagram

This is precisely the approach taken by Vitech with its GENESYS product. Rather than using diagrams, as most SysML-based solutions do, GENESYS uses comprehensive technical data packages’. These contain detailed descriptions of all system elements across any number of hierarchies.

For example, a data package contains interface definitions, incoming and outgoing signals, required functionality, design constraints, associated requirements, and test requirements. Stored in a database, the information held in these packages can be accessed and extracted in a variety of formats to suit the information requirements of a heterogeneous community of stakeholders, with the most obvious and conventional representation being the traditional ’diagram’, as used in SysML-based approaches.

Picture6-1
The Vitech Approach: comprehensive technical data packages stored in a central database enable extraction of information to suit individual users’s requirements

In addition, the system model can be simulated using the parameters held in the data packages to ensure the components of systems interact in the desired way. And here lies the true value of Vitech’s MBSE approach. “By connecting architecture and analysis, we can enhance the performance of a system. Be that an organizational model or a complex machine – before committing to detailed design. In addition, it allows us to connect ‘as planned’, ‘as designed’ and ‘as tested’ in a true V-model approach.”

Setting out for a digital journey

However, as anybody who witnessed earlier paradigms (such as Product Lifecycle Management) mature from idea to mainstream adoption will be aware, the industry still has a long way to go to reach mainstream adoption of MBSE. “Currently we are seeing a growing interest in sectors such as automotive, medical devices or ’Silicon Valley’ types of new applications driven by companies like Apple, Google or SpaceX”, says David. “But we will be seeing rapid progress as the industry is going through the digital transformation.”

“There is a degree of fear and uncertainty in the engineering community about model-based systems engineering, and many see it as scary”, summarizes David. “Well, it is scary if you think you have to embrace a whole new language, and that we must change the way you do everything. But it becomes less scary if we see it as an evolutionary journey to better represent knowledge. “

Richard Warrilow
Richard Warrilow
Richard Warrilow is a Technical Author with Declaration Limited. He is a qualified electronics engineer and worked for GEC Marconi Avionics (now BAE SYSTEMS) during the 1990s on two high-profile fly-by-wire programmes before moving into technical journalism and, latterly, establishing Declaration in 2001. Richard still works closely with companies active in the aerospace sector and has written articles on subject matters ranging from the certification of programmable electronic components intended for use in aerospace applications through to systems for the in-flight refuelling of military aircraft.