Model-Based Structures, let's call them MBS, are essential elements of digital transformation. MBS are intelligent configurations of data (i.e., data constructs whose structures have meaning above and beyond the constituent data items) that define a product, service or asset that can be relied upon for decisions, fostering deeper understanding, speeding comprehension and advancing or improving the enterprise’s product and/or service offerings.
At this point in my exploration of digital transformation, we need to address the presentation of information models, i.e., model-based structures, required for innovative designs and key decisions throughout a product’s lifecycle. Digital twins aside, we have thus far focused on flows of information—gathering, verifying and tracking it through the many phases of the product development lifecycle, from end to end, and through the extended enterprise.
If the construct of an MBS or the means of extraction of meaningful data is incomplete, or insufficiently communicated, then achieving the promised benefits of digital transformation—with or without Product Lifecycle Management (PLM)—will be difficult at best. Quite simply, MBS are that important. They are essential elements of digital transformation.
These information models are best put to work in PLM environments, which means looking at the MBS’s vital role. Simply put, PLM is indispensable in ensuring that everyone on a product or project team (no matter how widely the team is dispersed) can access and have confidence in any data item and model they need in readily usable formats as soon as the need is recognized. This means that PLM solutions are critical to defining and maintaining MBS.
There are, of course, countless types of MBS. Entire books have been written about them, and solution providers expound on them in marketing material and the trade media. Unfortunately, the descriptions and explanations in these postings and articles focus on how each provider wants its potential customers to understand its offerings; hence a tight focus on how the provider sees its products and which models it feels are most important.
What’s missing from these accounts is that the benefits of MBS or any new technique or technology will be proportionate to the difficulties of using whatever is being replaced—wasted time and errors, among many others. The gains could be 2 or 3 times the cost or just a few percentage points larger.
In this article, I want to offer some insights for managers and users, whether they are implementing MBS, encountering them for the first time or just struggling with an unfamiliar task. CIMdata is, after all, in the business of management consulting, education and research; we are neither a software developer nor a manufacturer.
In addition, I wish to clarify two terms that arise in nearly all discussions of model-based anything that are commonly misused. They are:
“Structure” (the “S” in MBS) determines how models are built and used in enterprises no matter where the enterprise is in its digital transformation. Structure here refers to how models are built with their intended users’ needs and what those users need to know about the MBS itself, i.e., its metadata.
“Extraction” is a specific view of a subset of the data requested in business units that have implemented the Bill of Information (BOI) to manage their bills of material (BOMs); “extract” extends far beyond “access.” The BOI is the subject of my article, “The Bill of Information is Vital to Digital Transformation.”
By eliminating confusion about “structure” and “extraction” MBS can deliver promised value sooner.
The Many Dimensions of Model-Based Structures
Business units and organizations implement more MBS every day, so they cannot be overlooked, if only for competitive reasons.
There are many different kinds of models. One way to sort and understand them is by “dimension,” meaning models that range from zero dimension (0D) to 4D and beyond. Each is best suited for a particular set of tasks, analyses and decisions. To clarify:
- 0D models are common in thermodynamics and combustion, which normally need no spatial resolution; 0D models are usually more diagnostic than predictive, showing “what is” rather than “what will be.”
- 1D models are typically used to display behaviors or consequences attributable to a single cause, such as pressure, temperature or corrosion.
- 2D models are used when attributes or behaviors vary across a tabular space where a third dimension would be irrelevant—in electromagnetics, for example.
- 3D models are used for static representations of the vast majority of physical objects, assets and services in every day, intuitively understood space—left, right; front to back, plus up and down.
- 4D models are dynamic rather than static representations of objects, assets and services, adding a fourth spatial dimension to represent changes over time.
- Models of 5D and beyond represent change caused by combinations of factors such as in engine wear and tear, weather forecasting, security threats and volcanoes. Because of their huge number of interconnected calculations, models 5D and up usually require supercomputers to compute and/or understand.
Same Old, Same Old
As with any complex toolset or newly implemented technology, it’s “same old, same old” when problems emerge. The model structure shortcomings in defining and managing model-based structures that CIMdata clients most often complain about are:
- Unspecified product, system or asset baseline architectures, which make the impacts of change harder to understand.
- Iffy integration of toolsets, even within a provider’s own offerings.
- Lack of capabilities to simplify design reuse; libraries of parts, for instance.
- Lack of mutually understood vocabularies and terminologies, which hamper communication across the enterprise, with suppliers and with those that have different backgrounds, thereby making model interoperability difficult.
- Ineffectively managed change processes and/or no configuration management to ensure that the model is complete and accurate.
- Too many model-based standards, many of which overlap, to understand and determine which are the best ones to deploy.
Compounding all of these issues is that users face broader ranges of tasks and less time to get them done. Under the pressures of competition, customer demands, budget constraints, skill mismatches and shortages, anything that shortens time-to-value should not be overlooked—easier comprehension included.
Developing Truly Useful Model-Based Structures
Developing any Model-Based Structure is a three-stage process. It starts with defining the intended model—usually what the developers see as the users’ needs, tasks, intentions and accustomed formats, plus the needed information. Stage 2 defines and gathers the data that will make up each unique model. Stage 3 defines the management of this data and allowable changes and access. These needs are why the model creator’s assumptions should be part of the model. And each stage has ample room for error, so caution and communication are essential.
For truly useful MBS, it is not enough to have compelling graphics with dramatic images with relevant, well-chosen data from all phases of the development of the product, system or asset. If an MBS only lays out a problem, it falls short. The problem’s solution, or at least its outlines and data pointers, should be included. Aside from a pair of structures—digital models and the associated physical object—their functionality and the data that moves between them, the MBS should also show:
- the object’s function and role in the physical world,
- analysis to support the conclusions presented in the MBS, and
- alternatives.
In addition to addressing (or “solving”) whatever problem or object, a MBS represents the viewpoints and perspectives that should be included to meet the diverse needs of managers, operators, and other users, whether or not they have technical backgrounds.
The truly useful MBS should also show:
- How the object (product, asset, whatever) fits into the expressed goals of the organization (i.e., strategic business and profit plans).
- The object’s intended and anticipated use(s) and, again, alternatives, if any.
- External data/information flows not addressed elsewhere in the MBS.
- A description of the object’s immediate physical environment, before and after implementation and its associated connections.
Still confusing are all the “model-based” descriptions. Several industry standards are in use, but none have gained universal acceptance. As a result, each solution provider follows the standard that best reflects how it sees its capabilities
And since the “MB” terminology itself is confusing, I’d like to clarify it with a glossary (previously reported here):
Model-Based Definition (MBD) starts with 3D CAD models that provide specifications for a component or assembly without additional 2D engineering drawings. These specifications include geometric dimensioning and tolerancing (GD&T), Bills of Information (BOIs) and their bills of materials (BOMs) subsets, technical data packages (TDPs), engineering configurations, design intent, etc. Collectively known as product manufacturing information (PMI), these data sets, metadata and linked repositories contain the information to manufacture and inspect the product. Model-Based Definitions are also known as digital product definitions.
Model-Based Design (also MBD) is a mathematical and visual method of addressing problems in designing complex control, signal processing, embedded software and communication systems. In Model-Based Design, models are developed in simulation tools for rapid prototyping, software testing, verification, predictive analysis and archiving. Model-Based Design is also a communication framework representing shape, behavioral and contextual information throughout the design process and development cycle.
Model-Based Engineering (MBE) is the use of models as the authoritative definition of a product or system’s baseline technical details. Intended to be shared by everyone involved in a project, these models are integrated across full lifecycles and span all technical disciplines.
Model-Based Systems Engineering (MBSE) is a methodology to support system requirements, analysis, verification and validation activities from conceptual design, throughout development and on into later lifecycle phases and even virtual testing of prototypes. Like other components of MBx, engineers use these simulations to exchange information.
Model-Based Enterprise (also MBE) refers to an organizational environment that leverages the model as a dynamic artifact in product development and decision-making. The Model-Based Enterprise focuses on managing lifecycle feedback to create follow-on products and their iterations and variants. Also often heard is Model-Based Extended Enterprise, or MBEE.
All terms in this glossary represent a specific type of MBS.
CONCLUSION
Well-constructed MBS ensure that the benefits of digital transformation are achieved as designers, decision-makers and everyone else will not have to struggle to make sense of model structures or data extractions from them. The structures’ information and metadata will be readily understandable so users can go straight to their tasks. Poorly constructed MBS can chip away at the benefits of digital transformation just when they are most needed.
If you have read this far, it’s probably time for you to look at how your models and their structures are actually built, what they are, and what they are used for; start by asking your users.