Anatomy of a Model-Based Engineering Environment
Many Engineers are often confused by the new concepts in Model-Based Systems Engineering, SysML etc. Several occurrences of change have caused the disruptions that provoke this confusion. Namely the emergence of SysML and tue subsequent capabilities that allow Engineering to be done entirely in a Digital Space.
This article will serve to provide an explanation of the pieces of the pieces of a MBEE (Model-Based Engineering Environment) for Systems Engineering.
Digital Twin Controller - choreographs the behavior of the underlying threads and pipelines to provide the digital twin.
Digital Thread Manager - defines the connections between pipelines to formalize them into digital threads.
Digital Pipelines - automated connection and processing of different aspects of the analysis of the Digital Models.
Digital Models - These are the models built to compose different aspects of the Digital Twin.
[M] denotes that models are used to define these layers.
Invariants of Engineering
To define an environment for engineering, we can create a foundation by looking at the invariants of engineering itself. What things do not change for every engineering process in any industry (or, say most)? What is the same about building a car and an airplane and a spacecraft?
In engineering, functions form the core abstraction by which we understand and shape systems. A function can describe a piece of code, an assembly step, a design task and a hardware artefact.
Each function maps measurable inputs to outputs—serving as the mechanism through which requirements are fulfilled. At the root of every engineering effort is a desire, which expresses itself as a top-level requirement. From this starting point, we begin constructing a system of functions to meet that goal.
Crucially, functions do not just fulfill requirements—they generate new ones. The output of one function may satisfy a requirement, but its inputs become new requirements that must also be met. This cascading chain of functional dependencies creates a graph of functions and requirements, a structure that grows and deepens as the design progresses.
In this network, certain variables—like mass, power, or cost—are required by multiple functions. These shared resources are managed through budgets, which act as coupling constraints across the system. Budgets ensure that the collective demands of all functions do not exceed the available supply.
A design is said to "close" when all individual requirements have been fulfilled, and all shared budgets are fulfilled. At that point, the system is internally consistent, feasible, and traceable—from the original desire down through every function and resource it depends on.
This leads to a graph that connects all parameters and variables of our system:
This graph is an example of a spacecraft design and exemplifies the coupled nature of all subsystems and requirements. This functional graph with traced requirements and budget constraints becomes the invariant backbone of engineering reasoning. It captures not just what the system is or does—but why it must be that way.
Architecture as Organization of Interfaces
In the context of model based engineering, architecture can be thought of as an organization of interfaces. What is behind the interfaces is usually not of concern for the architecture since it is a specific technology or solution. However what kind of interfaces and how they relate to one another - those are the important questions for the architecture.