Distributed Model-Based Design is a subset of the broader and well-understood concept of Model-Based Design. The distinguishing feature is that it incorporates contributions from different groups. These can be different departments in a corporation, or they can be different companies.
I have worked on several distributed Model-Based Design projects and learned that they have certain common characteristics.
The Structure of a Distributed Model-Based Design Project
In my experience, a simulation project with multiple groups has a particular structure. There is one central group that ‘sponsors’ the project, and this group commissions other groups to develop and provide subsystem models. The sponsoring group then integrates the contributions into a working simulation.
What does “Different Groups” mean?
In the context of integrating simulations, “Different Groups” is “2 or more engineering groups that don’t have continuous collaboration”. Truly continuous collaboration can occur only when the team members are physically co-located within in an office.
The most common example of infrequent collaboration is groups from different managerial domains, such as different departments in a large corporation, different government agencies, or different companies. Examples include an OEM and its suppliers, the DoD and its contractors, a DoD prime contractor and its subcontractors, and a company’s system engineering group and its groups developing subsystems.
This definition also includes an emerging office structure. During the COVID 19 pandemic, individual engineers within a single department are being physically separated as teams roll out the virtual office. This hinders the continuous collaboration that naturally occurs in the traditional office setting.
Notice that this definition does not include non-technical groups such as HR, IT, or administration. These are groups are separate and their collaboration is vital, but their contributions are not subsystem models.
This definition is important in the world of simulations because communication is the key to success when bringing engineers together, and when communication is not continuous, then clarity is the key to communication.
What does “Contribution” mean?
When integrating simulations, a contribution is a subsystem model that must be integrated into a larger simulation. This distinction is important because subsystem models will not integrate into the larger simulation if they do not match their specified interfaces precisely.
Notice this is separate from other contributions, such as engineering direction or advice, schedules, or administrative input. These types of ‘soft’ inputs are just as critical for project success, but are not software contributions, and so are not as demanding in the details.
Legacy Models
A common motivation behind a distributed Model-Based Design is a desire to re-use existing subsystem models, or legacy models. When one group needs to simulate a system and another group has a subsystem model already developed, treating it as a distributed project can be a valid solution.
Next
In my next blog post, I will discuss the difficulties with distributed Model-Based Design.