For Connected and Autonomous Vehicles, MBD Doesn’t Cut It without MBSE


Design teams across all major industries struggle with managing the ever-increasing complexity of modern products. In response, many have pursued the model-based systems engineering (MBSE) methodology which originated in Aerospace & Defense. While MBSE has been part of the industry discussion for several years, the emergence of MBSE tools and applications is relatively recent. OEMs and Tier 1s should take care not to mistake MBSE for the model-based definition (MBD) methodologies they may be familiar with. Overlooking what MBSE offers – and settling for MBD only – prevents organizations from leveraging the full value of MBD and MBSE, particularly when integrated via a PLM platform, that they require for connected and autonomous vehicles.

Let’s first clarify the differences of MBSE and MBD:

MBSE is a systems engineering methodology that replaces paper documentation of a system design and architecture with digital models. MBSE models represent a high-level abstraction of a system. The related tools and applications (ex: SysML authoring solutions) simulate system behavior before committing to or designing detailed implementation of the mechanical, electronic, electrical, and software domains.

MBD is a mechanical engineering methodology that replaces the paper documentation of a mechanical design with digital models. MBD tools and applications map items to existing MCAD/ECAD assemblies and encompass capabilities such as 3D visualization, domain-specific requirements management, multi-BoM integration, and hierarchical BoM structures.

The challenge comes from the fact that MBD without a connection to MBSE lacks the knowledge of the underlying system architecture and behavior. That, in turn, makes implementation of changes to the related assemblies/parts in manufacturing difficult because there is no feedback on the impact on the system behavior defined in MBSE. This is also open to misinterpretations by the simple fact that the term “model-based” terminology has different meanings when used in MBD vs MBSE. It’s not enough to agree to have a model instead of a piece of paper. It is essential to understand that MBD and MBSE models represent different abstractions of a design and that selective use of either as the only representation of the “truth” is fundamentally flawed.

In the absence of integration between MBD and MBSE, organizations developed alternative MBD-driven strategies to manage local BOM related changes in the context of a broader system. Some manage change by defining items that change rapidly as “attributes” to the MCAD/ECAD assemblies. This allows some level of change and configuration management to be applied but only to a specific level of the assembly. Some create vehicle partitioning systems (VPSs) as a workaround to show how systems are integrated. Partitioning is based on spatial relationships (e.g., the engine compartment firewall). Each spatial assembly is then integrated through the VPS to form higher-level assemblies, sometimes up to the entire vehicle. And some rely on a definition of functional assemblies linked by a functional BoM with all the math and non-math vehicle data related to achieving that function.

What these MBD centered change management approaches miss is the “true” system-level awareness of the change impact across different disciplines. A change to one assembly potentially affects behavioral aspects of the system implemented in another domain. While there are ways to make MBD work for a specific situation, the value of MBSE and MBD integrated via the same PLM platform is that it provides a holistic and integrated system-level view of the system architecture and behavior—at any level of a design abstraction. That view includes structural and behavioral relationships between the requirements, functions, logical/physical parts, interfaces, software and other relevant vehicle design elements. It is extremely relevant to all decisions and changes made throughout the product lifecycle —spanning all phases of design, manufacture, and maintenance.

So, ultimately the choice is yours. While relying on MBD alone, without connecting it to MBSE, and ultimately a PLM platform, may have worked in the past—it simply will not allow you to be ready to meet tomorrow’s most complex design and manufacturing challenges.

To continue the conversation, we invite you to attend Pawel Chadzynski’s sessions on Systems Engineering and MBSE & PLM during Aras’ annual Community Event, ACE 2018 March 20-22 in Indianapolis, Indiana. Visit our ACE 2018 website for full event details.

2 thoughts on “For Connected and Autonomous Vehicles, MBD Doesn’t Cut It without MBSE

  1. krueger-jens

    Hi Pavel, thank you for pointing out the importance of MBSE for Connected / Autonomous drive. I fully agree and am looking forward to your ACE presentation and Aras’ solutions in this space. I just wonder about your Definition of MBD as a “mechanical Engineering methodology”. In my understanding, MBSE is more of a subset of MBD / MBE. This is based on the Incose definitions cited e.g. in Best regards, Jens

    • Pawel Chadzynski Post author

      Hi Jens,

      Great point! Meaning of MBD tends to vary a bit even though there is an INCOSE definition as you pointed out. But there are other definitions of it as well ( which associate it with the 3D visualization of mechanical assemblies. INCOSE one is certainly more authoritative however the latter one is how it is often understood by the manufacturing teams. That is the spirit in which I used it. See you at ACE!


Leave a Reply