Contact Us

The MBSE Horizon: Advances and Challenges over the next few years

This article has been brought to you by Project Performance International as part of the PPI SyEN Newsletter. For the complete newsletter and past editions, please click here

Abstract

The most significant development on the MBSE horizon is the forthcoming submission of the SysML v2 proposal which diverges SysML from its origins as a Profile of UML. While this is a welcome and necessary development, language is only one of the critical aspects of MBSE; there is still additional work to be done in terms of methodology, organizational capability, practitioners’ competence, and tool functionality and usability. This article explores the need for the new direction of SysML v2 and provides views of leading figures in the industry concerning their thoughts about where MBSE is and should be heading.

Introduction

It seems hard to believe that the Systems Engineering Domain Special Interest Group (SE DSIG), a joint venture between the Object Management Group (OMG), and the International Council on Systems Engineering (INCOSE), turned eighteen years old in 2019. Its charter was established at the OMG technical meeting in Danvers on July 9th, 2001.

Eighteen plus years seems long enough for us to consider this a mature endeavour.

While the SE DSIG can’t claim to be the founders of Model-Based Systems Engineering (MBSE), it could be argued that they are responsible for much of its modern form and direction, through the development of the Systems Modeling Language (SysML) used by the majority of modern MBSE practitioners. Eighteen plus years seems long enough for us to consider this a mature endeavour (1), so this is an appropriate opportunity to reflect on where we are with MBSE, SysML, where we are heading, and what are the strengths, weaknesses, opportunities and threats it faces as an approach to Systems Engineering (SE).

SysML v2

While the SE DSIG received its charter in 2001, it wasn’t until six years later that SysML v1 was adopted in September 2007. Subsequently, there have been six revisions with the latest, version v1.6, adopted in December 2019. So far, they have all been minor revisions focusing on missing or inconsistent aspects of the specification, documentation errors, a few simplifications (2), and other semantic and syntax changes driven by practical usage of the language.

many of the semantics of UML are sufficiently abstract that they are readily transferable to SE

SysML v1 was defined as an extension (in UML terms, a Profile) of the OMG’s software modelling language, the Unified Modeling Language (UML) v2 (3), the first version of which was adopted in July 2005. The use of a Profile to extend UML for SysML has both advantages and disadvantages. One of the advantages is that many of the semantics of UML are sufficiently abstract that they are readily transferable to SE. Actually, before SysML, many practitioners, including myself, were engaged in MBSE with UML. One of the disadvantages of using UML as the foundation is that the development of SysML is then coupled, for some aspects tightly, to the semantics and occasionally ambiguities and peculiarities of the underlying UML. It has not been uncommon for the SysML revision process to be dependent or even restricted by the need to first enhance the UML specification. Additionally, as the use of SysML has become further widespread and more mature, systems modelling practitioners, tool vendors and methodologist have all identified new requirements to enhance the language.

There is frequent discussion about whether the underlying Object-Oriented paradigm of UML is appropriate to meet the needs of SE. While it may be possible to evolve the UML metamodel in order to address the requirements of SE, there is a danger that by doing so, SysML could add unnecessary (4) and confusing semantics or syntax, which may hamper the users of UML. With these drivers in mind, plus the overarching objective of increasing the adoption of MBSE by enhancing; precision and expressiveness, consistency and integration between language concepts, and usability by model developers and consumers, the OMG issued a Request for Proposal (RFP) for SysML v2 in December 2017.

The SysML v2 RFP includes the requirement that submissions should “include both a SysML profile of UML and a SysML metamodel, and a mapping between them. In addition, submitters have the option to specify additional features that include model interchange and formal semantics.” This separation allows the new SysML v2 metamodel to be more compact, better aligned, and evolve independently from the UML metamodel which underpins SysML v1. The inclusion of an additional UML profile should ensure that the language is backwards compatible (as far as can be possible) and that it can be implemented within UML v2 based tools. The latter is an issue that was an initial concern for tool vendors when the move to an independent metamodel was first suggested.

In June 2018 a second RFP for ‘SysML v2 API and Services’ was issued to “enable interoperability between SysML modeling tools and other model-based engineering tools”, something which had long been a criticism and potential barrier to adoption of MBSE with SysML v1.

In December 2007 a SysML Submissions Team (SST) was formed to respond to the first, and then subsequently, the second RFP. The team, jointly lead by Sandy Friedenthal and Ed Seidewitz, comprising a diverse team of end-users, tool vendors, academics, and governmental representatives, with over one hundred members from over sixty organizations. These submissions are being driven by the RFP requirements and user needs, and the team has adopted an “agile collaborative approach” to its development. The planned enhancements in SysML v2 can be categorised by the following themes:

  • Usage Focused Modeling – A paradigm shift to make the language more precise and intuitive to use through the greater emphasis of ‘usages’, e.g. more can be done with Internal Block Diagrams (IBD) rather than the current focus on type definitions with Block Definition Diagrams (BDD). These changes will, in turn, support other language requirements such as variant specification and configurations, individuals & snapshots (5) and improved analysis and verification.
  • A new metamodel not constrained by UML. This meta-model will be grounded in formal semantics. It will be minimalist (less than one hundred elements compared to UML which has over two hundred elements) and is based on the Kernel Modeling Language (KerML).
  • A new textual representation based on the Action Language for fUML (Alf), which provides a powerful and concise alternative to the graphical representations.
  • Robust visualizations based on flexible view and viewpoint specifications, and
  • Standardized API access to the model, which can be summarized by the following ‘Logical Architecture for a SysML v2 System Modeling Environment’ proposed by the SST.

Figure 1 ‘Logical Architecture for a SysML v2 System Modeling Environment’

View from the front line

“What are the current strengths, weaknesses, opportunities and threats, facing MBSE?”

To better understand the current position and future direction of MBSE with SysML, I asked some of the authors and practitioners in the field a broad question – “What are the current strengths, weaknesses, opportunities and threats, facing MBSE?” The following sections summaries some of their responses that were provided, together with my own thoughts. A list of the contributors is provided in the acknowledgements section.

Strengths

“MBSE is a viable approach to engineering complex systems”

With respect to strengths, the consensus is that the size of the community, the increasing number of books and conference papers, plus the growing demand for training and consultancy all suggest that the approach has a burgeoning and robust foundation. The increased adoption by industry (although perhaps not at the rate some of us would like!) also suggests that MBSE with SysML is firmly embedded within the overall SE culture (6). As Rick Steiner of Skygazer Consulting, an MBSE and SysML author, instructor at UC San Diego Extension and OMG contributor put it – “[there is] a growing awareness that MBSE is in fact a viable approach to engineering complex systems. This is being expressed as increasing enrolment in SysML and MBSE courses, as well as an increasing number and extent of organizational MBSE related initiatives in defence, government, and industry.” 

Tim Weilkiens, of OOSE Innovative Informatik eG, an MBSE & SysML author, lecturer and OMG contributor further elaborated by writing – “I think the strengths of MBSE are pretty clear and identified in many publications. It can be summarized under the term mastering complexity: No one can really believe that we can master complex systems with Word, PowerPoint, and Excel. In the past, our systems were less complex, and the market environment and system architectures were more stable. The engineering organization including its processes covered inherently the system architecture. So, there was no big need for specifying the system level explicitly.” It is perhaps most telling that Tim can answer the question by initially directing us to the existing body of knowledge in the “many publications”.

Weaknesses

The views on apparent weaknesses were quite diverse, and only one of the commentators directly identified SysML v1 as a problem. The reason for this could be because as the SysML v2 process is ongoing, many people may consider it ‘fixed’. Alternatively, it could be that the majority of practitioners and implementations are not yet mature enough for the limitations of the language to be a visible problem.

“SE organizational maturity must be suitably advanced before MBSE can be successfully deployed”

When considering weaknesses, Raphaël Faudou of Samares Engineering pointed to the lack of a generic shared MBSE process – “There are several approaches, but none is generic enough to be considered as a good starting point shared by the whole community. So, we see most industrial companies defining their own method and customizing MBSE tools to support it.” Rick Steiner noted that SE maturity was sometimes an issue – “SE organizational maturity must be suitably advanced before MBSE can be successfully deployed. Discovering a low level of SE maturity can be both difficult and traumatic for an engineering organization.” He also highlighted that the management obsession of harvesting ‘low hanging fruit’ often drives expectation – “Finding specific areas where MBSE deployment can add immediate, irrefutable value requires considerable effort and cooperation across organizational stovepipes in an engineering organization.” This view resonates with my experience. It is not unusual for organizations relatively new to MBSE to expect measurable returns within very short timeframes or to want to introduce advanced techniques such a variant modelling from day one. This challenge is not surprising when it is noted that there is very little material published on how to transition from document-based to model-based systems engineering.

Considering the current tools and languages, Tim Weilkiens was critical – “The MBSE tools are still at the level of the 90’s. The usability is a nightmare and basic features common in other engineering disciplines are rarely available. Another weakness is probably the language SysML, but with SysML v2 we are on a very good way.” Similar sentiments about the languages were expressed by Dave Banham of BlackBerry QNX and an OMG contributor – “[MBSE languages] are all flawed by being niche (limited ecosystem), lacking in expressiveness, divergent in interpretation/use, and generally have no or limited means of validating the model with formal verification of properties or at best model execution.” As suggested by Tim Weilkiens, some of these issues may be addressed by SysML v2. However, Dave Banham further went on to suggest what could be done to improve tooling – “[the OMG] needs to enforce a tool certification program for vendors to be able to use the modelling language brand name. It’s that lack of enforcement that has allowed vendor solutions to drift.” Returning to perceived weaknesses,

“Too few people are familiar with systems thinking, abstractions, and modeling theory”

Tim Weilkiens also discussed educational requirements for successful MBSE: “Too few people are familiar with systems thinking, abstractions, and modeling (not SysML/UML, but metamodels and other modeling theory)”. This is perhaps particularly evident within the SysML v2 SST which, while including over one hundred members, the majority of its intellectual effort is provided by little over twenty key contributors.

Opportunities

“Well-positioned to also realize great benefit from MBSE”

Thinking about the opportunities ahead, Rick Steiner highlighted that it was no longer just the SE technical processes (7) such as ‘Stakeholder Needs and Requirements Definition’ or ‘Architecture Definition’ that were taking advantage of MBSE; “speciality engineering (Reliability, Safety, Availability) are well-positioned to also realize great benefit from MBSE, if properly emphasized during program development.” An illustration is the RFP for “Safety and Reliability for UML” issued by the OMG in 2017 to define a UML Profile for this purpose. Tim Weilkiens looked at the opportunities from the perspective of the System of Interest (SOI) – “[in the future] engineers can do engineering again instead of copy & paste tasks, reading thousands of textual requirements, managing traceability matrices, etc. When engineers do real engineering again, they will build great systems again.” Dave Wood of Harris Corporation pointed to the Department of Defence (DOD) ‘Digital Engineering Strategy’ as a driver for opportunities with MBSE – “Now we are seeing RFPs (requests) that require an MBSE model. Like industry changed after WWII and the space race (and the WWW) I think this mandate by the DOD will accelerate MBSE adoption in Systems Engineering and bring all sorts of unexpected changes: SysML/XMI libraries of common parts we can all use for free (thank you OMG), Architectural Patterns (like Christopher Alexander), Machine Learning algorithms that analyze system architecture, ‘Digital twins’ that track the life of each aircraft and ship, and a seamless integration of engineering even better JPL’s OpenMBEE.” Dave’s outlook is possibly the most optimistic of those given, but if only one of his predictions comes true, it is undoubtedly an exciting time to be involved in MBSE.

Threats

Several of the commentators highlighted that while SysML v2 provided a great opportunity to increase the benefits and usability of MBSE, it also presented significant risk. Even with successful adoption of the standard, we are still reliant on usable and compliant implementations from tool vendors. Tim Weilkiens echoed these thoughts, and it is also significant to consider Raphaël Faudou’s insight – “Taking a long time to get SysML 2.0 and fragmentation of SysML 2.0 are threats for me. If there are too many actors willing to achieve a too large scope, there might be nothing before 5 years, which could lead to deception in the SysML community and movement in large industrial companies to other none-SysML tools (Capella, Simulink, and Modelica) to implement their MBSE method.”

Rick Steiner thought there were at least four different threats to the discipline as a whole:

  • SE Maturity – “Organizations that attempt to deploy MBSE tools and training without sufficient SE maturity (processes, culture, support) inevitably fail to provide value, and then blame MBSE for their SE shortcomings.” There is certainly a lot of anecdotal evidence of this occurring historically with UML for software development.
  • A lack of understanding concerning what MBSE is – “There is a perception that MBSE is “only for software” and doesn’t apply to non-software systems. This is pervasive in the mechanical engineering community but can show up elsewhere.” This is possibly a manifestation of the ‘not invented here’ anti-pattern (Brown et al. 1998).

“A failure to recognize the limitations of document-based approaches”

  • A failure to recognize the limitations of document-based approaches, particular concerning scale and complexity – “If the systems being developed are not particularly complex, organizations often make do using MS Office, requirements management tools, and traditional document-based SE. It is tempting to try to “scale up” these techniques as systems inevitably become more complex, rather than invest in the culture shift and retraining required for MBSE.” This is illustrated by the different rates of adoption of SE across different industries as they reach their ‘tipping point’ at different times.

“Government organizations will have to change the acquisition model before MBSE becomes meaningful”

  • A general cautions attitude and reluctance to change – “Complex system developers with a history of successful projects that relied on detailed customer-provided requirement specifications (such as in defence projects) often see no need to change their SE processes. Their system acquisition customers in government organizations will have to change the acquisition model before MBSE becomes meaningful. Note that this is beginning to happen in many cases, but every supplier must have appropriate incentive and accountability before multi-level MBSE can be effective.” Hopefully, the DOD’s ‘Digital Engineering Strategy’ will contribute to this.

Returning to one of the topics raised by Raphaël Faudou, we need to be mindful that SysML isn’t the only language in town. For users of the Capella tool (from the Eclipse Foundation), the chosen language is a Domain-Specific Language (DSL) with many overlapping concepts with SysML v1. The tool also embeds the Arcadia Method, so in that sense, the Capella language can’t be thought of as a general-purpose modelling language (8) in the same way as SysML which is not tied to any one approach. With the arrival of SysML v2 it is not known if the Capella DSL will evolve in a similar fashion or whether it will result in a larger divergence between the two. The threat to MBSE could therefore be that the choice of languages and perceived inability to switch makes the take-up look even more onerous than it is now. The lack of a diagram interchange standard currently makes tool migration very difficult even if they both use the same language, which is something many users are hoping the SysML v2 API approach will facilitate.

The use of languages such as Simulink, with its foundations in control theory, or Modelica, which while aimed at cyber-physical systems is firmly grounded in multi-physics simulation and physical-system modelling, both play important roles in an overall Model-Based Engineering (MBE) approach. The question is though; “Do you need multiple languages, and if so, which language is best suited to which purpose?” The challenge, as always, is tool-interoperability. If a key aim of MBSE is to provide ‘a single source of truth’ then having multiple tools, using different languages, and which are not connected, will only ever provided ‘multiple sources of half-truths’ at best. Something which is only marginally better than traditional document-based approaches.

Finally, another language which could be described as being in competition with SysML is the Object-Process Methodology (OPM) specified as the International Standards Organisation, Publicly Available Standard (ISO/PAS) 19450. Perhaps the formal standards-based and general-purpose nature of OPM makes it the closest rival to SysML. Like Capella, and as its name suggests, OPM has a built-in methodology. Being tied to a methodology is not necessarily a disadvantage, but it does mean that users have less freedom when transitioning from a document-based approach with an existing SE process. On the flip side, for organisations without a well-defined SE process, it provides one more thing they need, straight out of the box. The biggest difference between SysML and OPM is their underling paradigms – while SysML v1, is based on the Object-Oriented approach of UML reusing the concepts of Structure and Behaviour and adding the concepts of Requirements and Parametrics, OPM is based around the generalised concept of Things which are then specialised into Objects and Processes and may appear on the same view. OPM has a smaller meta-model than UML v2, precise semantics and a textual notation, all things planned to be improved or included in SysML v2. However, the current version of OPM lacks the concept of Parametrics used for engineering analysis, it is currently only supported by a small number of tools and has limited literature. There is no doubt that OPM is a capable and powerful language, the challenge for SysML v2 then is to adopt those features that OPM it does better than SysML v1.

Summary and Conclusions

Model-Based Systems Engineering (MBSE) is here to stay, and while continued increased adoption may see a reduction in document-based approaches, it will never wholly supersede them. In the same way that driving has not eliminated walking and television has not killed radio, there will always be low risk or low complexity projects where the flexibility and informality of a document-based approach is sufficient. Conversely, there are a growing number of engineering projects which are reaching their ‘tipping point’ in terms of what can be achieved through scaling legacy approaches.

SysML v1 has served the community well over the past twelve years, but we are starting to outgrow it. SysML v2 provides an opportunity to define an enhanced language that not only meets the growing demands of the most advanced organizations (by introducing the ability to perform tasks such as variant modelling and better engineering analysis such as reliability, availability, maintainability, and safety modelling) but also, by making the language more intuitive (from an SE practitioner’s perspective) and by increasing the accessibility and usability for less mature organizations and users.

A new version of the language introduces risks as well as benefits. How will practitioners, especially those who are well versed (possibly even certified) with SysML v1, adapt to SysML v2? What will be the commercial impact on organizations that provide tools, training, and methodologies aligned to SysML v1? These questions have yet to be answered. The language used is only one aspect of MBSE, as our commentators have described, successful MBSE requires competent practitioners, appropriate methods, and usable and compliant tools. Perhaps then, the forthcoming arrival of SysML v2 is not the announcement of a new era in MBSE just yet, but rather a call for educators, methodologists and tool vendors to step up to the plate.

Footnotes

(1) That said, ‘immaturity of the discipline’ is still used as an explanation for failure in software projects.

(2) The way SysML ports changed between v1.2 and v1.3, while arguably simpler and progressive, left many users confused.

(3) Named so because it ‘unified’ concepts from the three authors, Rumbaugh, Jacobson, and Booch (colloquially known as the Three Amigos) existing modelling approaches: Rumbaugh’s Object-Modeling Technique (OMT); the eponymous Booch Method; and Jacobson’s Object-Oriented Software Engineering (OOSE).

(4) One of the criticisms often levelled at UML is that since its first official adoption in 1997, more and more semantics have been added such that it has become ‘bloated’ with many concepts of little use to the average software modeller.

(5) Whereas Blocks can be thought of as constraining all instances in all contexts at all times, individuals constrain instances to subsets of those contexts, and snapshots constrain individuals to specific time periods.

(6) Although we shouldn’t be complacent. At the recent INCOSE UK Annual SE Conference (Leeds, UK, November 2019) a speaker reported that “MBSE is not on the horizon for the UK Ministry of Defence (MOD)” (Kemp, et al, 2019).

(7) As defined by the INCOSE Systems Engineering Handbook 4th Edition (Walden et al. 2015).

(8) We shouldn’t confuse the fact that SysML is built on ‘four pillars’; Requirements, Structure, Behaviour and Parametrics, with it having an embed approach. The language simply defines valid models, not what should be built and in what order.

Acronyms

Alf – Action Language for fUML

DOD – Department of Defense (United States of America)

DSIG – Domain Special Interest Group

DSL – Domain-Specific Language

fUML – Foundational Subset for Executable UML

INCOSE – International Council on Systems Engineering

ISO – International Standards Organization

KerML – Kernel Modeling Language

MBE – Model-Based Engineering

MBSE – Model-Based Systems Engineering

MOD – [UK] Ministry of Defence

OMG – Object Management Group

OMT – Object-Modeling Technique

OOSE – Object-Oriented Software Engineering

OPM – Object-Process Methodology

PAS – Publicly Available Standard

SE – Systems Engineering

SOI – System of Interest

SysML – Systems Modeling Language

UML – Unified Modeling Language

Acknowledgements

My thanks go to the following people for their published works and individual insights which contributed to this article:

References

PPI Logo

This article has been brought to you by Project Performance International (PPI) 

systems engineering training for project success …

PPI SyEN is an independent free newsletter containing informative reading for the technical project professional, with scores of news and other items summarizing developments in the field, including related industry, month by month. This newsletter and a newsletter archive are also available at https://www.ppi-int.com/syen-newsletter/

The views expressed in externally authored articles are those of the author(s), and not necessarily those of PPI or its professional staff. 

Share This

Why Us

We help you design
the life you want.

This is a call to action, It details why the user should contact you.

work, office, team

Return To Top ↑