- Trade studies. In exploring different product configurations, your team might want to determine whether an additional subsystem helps. If your team is designing an autonomous vehicle, they might want to add a model of new class of sensor to determine its impact on the overall system. If your team is building a spacecraft, they might want to try adding an additional actuator to determine whether it improves pointing.
- System-of-Systems design. By definition, a System-of-Systems (SoS) is composed of parts that have a degree of autonomy and are not necessarily designed together, but are being brought together to form a greater whole. In an SoS MBD project, it is common to add a system model to the simulation to determine effectiveness and feasibility of the addition. This can be either a model of a system that already exists, or can be a model of a new system to be added to the SoS. If your team is building a missile interceptor system, they might want to explore the value of a sea-based radar. If your team is building a roadway model, they might want to explore some different traffic management strategies.
(The number of subsystem models can also increase by splitting existing subsystems, which I will cover in a later post in this series. This is also distinct from adding multiple instances of a single model, which I will also cover in a later post.)
Adding a subsystem model to an MBD project is always challenging because it usually requires modifications to multiple other subsystem models. A new subsystem will typically require information that might not be readily available from the other subsystems, and to take advantage of the new subsystem, other subsystems should be able to process its outputs.
If your MDB project is distributed across multiple managerial domains, adding a component will often require support from multiple groups, which adds an additional degree of complexity:
- Managers of other groups might insist on formal interaction with your group, instead of the informal communication between engineers within the same group,
- Engineers can be reluctant to request tasks, even simple tasks, from developers in another group,
- Developers need to understand the needs of other engineers working on the project, and this can be difficult when engineers are in different groups,
- You won’t have direct managerial control over developers in other groups, and
- Your interactions with engineers in other groups will not be as continuous and informal as with engineers in your own group.
To reduce these difficulties, you need precisely defined boundaries for each group, which is best done with exacting ICDs, and you also need a mechanism to ensure the ICDs are met. In my experience:
- Textual ICDs can be incomplete, and can be misinterpreted surprisingly often, and
- Because textual ICDs can be misinterpreted, a component delivered to your group might not properly integrate into the overall simulation, requiring you to request alterations from another group.
SystemBlend™
The SystemBlend application suite streamlines and automates updates to a distributed MBD project. Your group uses the SystemDesigner application to precisely define the simulation architecture, including which components are included and the interfaces between the components. The ComponentGuide application guides each group in the implementation to ensure the ICDs are correctly implemented. The IntegrationMaster application gives you automated integration of components from other groups, so that new and updated components are added in minutes, instead of days or weeks.
Also, the publishing and versioning facilities in SystemBlend ensure the entire distributed team remains productive, even while updates to components and to the design are underway.
Other Articles in this Series:
- Part 1: Project Launch
- Part 2: Updating Components
- Part 3: Adding Components
- Part 4: Splitting Components
- Part 5: Replacing Components
- Part 6: Component Delivery
- Part 7: Imprecise ICDs
- Part 8: Misinterpreted ICDs
- Part 9: Naming Collisions
- Part 10: Simulation Parameters
- Part 11: Simulator Configuration
- Part 12: Location Independence
- Part 13: Shared Parameters
- Part 14: Data Capture
- Part 15: Architecture Updates
- Part 16: Deprecating Components
- Part 17: Project End-of-Life
Note: This post has been updated with links to other posts in the series