The Hidden Gem in MBSE

SysML vs OPM?

Designing a system is challenging, especially when the system is complex or involves novel technologies. Whether you’re sharing your design with colleagues or test-running a use case, at some point, you’ll need to transform the ideas in your mind into a tangible model. Although SysML is the most prevalent modelling language in Model-Based Systems Engineering (MBSE), its steep learning curve and complexity can often result in the train of thoughts being lost before they can be captured into a model.

In this article, I will introduce you to an alternative — Object Process Methodology (OPM) — and explain why it is the ideal modelling language for use during conceptual design and more.

The Hidden Gem — OPM

Object Process Methodology is first developed by Prof. Dov Dori from the Technion — Israel Institute of Technology in 1995 ¹, and it has soon garnered recognition from INCOSE as one of the six leading MBSE methodologies. OPM is standardised into the ISO 19450:2024 specification ² and used by worldwide organisations such as NASA, Airbus and MIT.

So what makes OPM stand out? What sets it apart from SysML, an extremely comprehensive and capable modelling language in its own right? Here are the three pivotal features of OPM that I believe make it the prime choice for an MBSE methodology.

Feature 1: Dual Modality

OPM expresses any model facts using two modalities — graphical and textual. For every piece of information that is added to the model via the diagram, an equivalent sentence will be created. While graphical modelling may be natural to system engineers, it can become a barrier for stakeholders or customers who have no knowledge of the modelling language. In this case, the textual representation of the system model is very appealing.

Moreover, since the text is constructed deterministically using the Object Process Language (OPL) specification ³, it can be easily understood and parsed by machines. This opens up immense potential, allowing the system model to be used for automated tasks, generating executable code, running simulations or defining database schemas.

Feature 2: Minimal Ontology

OPM is founded on a minimal universal ontology. Think of ontology as the alphabet of a language. By using a smaller ontology, OPM reduces the cognitive load on both the modeller and the reader, ensuring that models remain comprehensible without sacrificing fidelity and rigour. As the name suggests, OPM revolves around objects and processes exclusively. Using only a few types of links, the intricate relationships between objects and processes can be represented comprehensively, enabling straightforward modelling of any system or phenomenon. 

Diagrams similar to the one above are common during brainstorming session. However, they may introduce undesirable ambiguities due to the lack of a formally defined syntax. What do the dashed boundary or arrow signify? Why is an ellipse used instead of a rectangle? In contrast, OPM provides a mathematically grounded syntax definition. Coupled with its minimal ontology, this ensures that ideas can be captured on the fly without any misinterpretation. 

Feature 3: Concurrent Modelling of Structure and Behaviour

While SysML represents a system by describing its structural and behavioural aspects separately using the different diagram types such as Activity Diagram and Block Definition Diagram, OPM concurrently expresses both the form and function of the system in the same type of diagram throughout the model.

The complexity of the model is managed through various levels of abstraction. Any object or process can be refined into a lower-level diagram, where the same modelling method applies to elaborate the details. This allows the modeller to focus on the use case of a component while simultaneously exposing the relevant architectural design in the same diagram.

More Than Just Conceptual Design

Despite its numerous features and advantages, OPM extends its benefits far beyond conceptual modelling. In one of our use cases, we developed an OPM model capable of orchestrating Multidisciplinary Design Optimization (MDO) of a system.

The same OPM model also facilitates requirements management, validation and verification, simulation, and testing. Additionally, it supports business intelligence by synchronising key design and performance metrics to an external dashboard. The dual modality of OPM ensures that all stakeholders can easily understand the system, bridging the gap between designers, engineers, and business executives.

To learn more about how we implement MDO using MBSE and OPM, check out our previous article here!

Conclusions

Modelling a system can sometimes be more challenging than designing it. Despite the advances in MBSE, choosing the wrong tool can hinder effective system development and cause innovative ideas to go to waste.

The standardised API and textual notation introduced in SysML v2 highlight the industry’s recognition of the importance of these features. Nonetheless, the three major characteristics of OPM explored in this article — dual modality, minimal ontology, and the concurrent modelling of structure and behaviour — continue to set it apart by enabling intuitive and holistic system modelling that fosters a truly inclusive system development experience among diverse stakeholders.

Enrol into our latest microcourse on Object Process Methodology, where we provide everything you need to know to effectively model with OPM, including a student license! Check out the course syllabus here.

---

¹  Dori, D. (1995). Object-process Analysis: Maintaining the Balance Between System Structure and Behaviour. Journal of Logic and Computation, 5(2), pp.227–249. doi:https://doi.org/10.1093/logcom/5.2.227.

² ISO 19450:2024 Automation systems and integration — Object-Process Methodology

³ ISO 19450 Annex A — Extended Backus-Naur Form (EBNF) Object Process Language (OPL) Specification

? Firlej, M. and Hellens, D. (1991). Knowledge Elicitation. Prentice Hall.

? Dori, D. (2016). Model-Based Systems Engineering with OPM and SysML. New York, Ny Springer.