Terminology. Terminology. Terminology.

One of the base challenges that this industry faces is terminology. This space, software supporting engineering and development, is literally overrun with existing technology and concepts of how to use them. So when a software provider comes up with something new, something they don’t want the industry to see as merely an enhancement but a new-to-the-world offering, they put a new term on it and announce it with great fanfare. Or, as can often be the case, an existing ‘hot’ term is coopted to means something else. Ultimately, it can all be pretty confusing.

Now, let’s talk about Model-Based initiatives. Right now, they’re pretty popular. But is everyone talking about the same thing? Well… no really. You see, Model-Based can mean dramatically different things. In this post, we’ll take a deeper look at those definitions and how they differ.

• Model-Based Definitions (MBD) and Model-Based Enterprise (MBE) for Mechanical Hardware: The MBD terms refer to the release of an annotated 3D model created by Mechanical Computer Aided (MCAD) software by engineering as documentation instead of 2D drawings. The MBE term refers to the use of a 3D model by downstream departments like manufacturing, procurement, and service instead of a 2D drawing. For more, check out our reference entries on Model-Based Definition and Model-Based Enterprise.
• Model-Based Development for On-Product Software: This kind of application always interacts with some kind of hardware. So while development of this software involves a UML model, there are two sides to it: the control and the plant side. The control side is the software. The plant side is essentially the software. These UML models, which look and act like diagrams, can be used to generate software code. But it is generally used as part of the Model-in-the-Loop, Hardware-in-the-Loop and other simulation / emulation / testing configurations. For more, check out our reference entry on Model-Based Development.
• Model-Based System Engineering (MBSE) for Systems Design: Developing a system for a product can be incredibly difficult. You need to iterate and perform trade studies early on to find the right architecture for the system. Furthermore, that is why you need a central single source of truth for the system that all engineering departments, mechanical, electrical and software, can coordinate their activities. Those are two of the main functions of an MBSE model. It looks much like a diagram or UML model, perhaps using SysML, except it is often connected to requirements. For more on that, check our our reference entry on Model-Based System Engineering.
• Data Model for IoT-enabled Products: As more and more products are getting connected in the IoT, development is getting more complex. Part of making that easier is to develop a data model (and test it with emulation) before you actually make the product and instrument it with sensors. That data model simply represents what data you will be collecting and how those inputs can be combined (and perhaps transformed) to make measureable KPIs. Those are the KPIs that you monitor for anomalies.
• Models for Electrical Printed Circuit Boards (PCBs): The term Model-Based is used frequently here, but applying the concept here raises questions. You have a diagram that represents the functionals aspect of the PCB. You have the layout showing which components on the PCB are connected to which, but how they are placed on the board. You have a 3D model of the PCB with associated layers. All of these are critical to the definition of the PCB.
• Models for Electrical Systems on Chip (SoCs): Likewise, Model-Based hasn’t necessarily made its way here quite yet, but it is applicable. Engineers often start with a UML diagram, or something similar. They can either convert that to a software program written in code like VHDL or something else. Chip manufacturers then take that and convert it into their IP to manufacture the chips.

So your company is moving forward with a Model-Based initiative? Which one… or which ones…? Interestingly, some of these overlap in terms of scope. So as you progress, you should be aware of that.

Overall, all of these efforts can yield tremendous value. But as an organization, it makes sense to be keenly aware of which initiatives you are pursing and how they will interact.

Remember, not all Model-Based efforts are the same.