Architecture Update
Depending on the system or systems being modeled, there might be a need to update the top-level architecture of an MBD project:
- If the MBD project is a follow-on to an existing project, such as analyzing a variant of an existing product, then there is probably no need for a significant re-design at the architecture level during the life of the project:
- If the MBD project is being built from scratch, such as a proof-of-concept for a new product, then the simulation will start simple, and evolve:
- Some projects need to be built for rapid, extensive changes at the architectural level using a library of components:
Without the proper tools, these architectural-level changes can be quite difficult to manage in a Distributed MBD project. It requires both coordination between different contributing groups, and the precision required for component interconnectivity. This combination can be quite challenging for the project manager. The effort to build a highly reconfigurable simulation (the third bullet point above) with components from different groups can be prohibitively difficult.
Signal Details
Although this discussion has been about high-level design, the low-level definitions of the signals between the components must also be considered:
- In an MBD project within one group, these details are typically worked out informally between the engineers that are working side-by-side.
- In a Distributed MBD project, the low-level definitions must be managed at the top level, because these details are part of the interface between components from different groups. Managing these details, and ensuring all groups properly implement these details, can be very time-consuming without the proper tools.
Obviously, these considerations apply only to signals between components. Signals that are entirely within a component are not part of the interface, and can be managed internally by the groups building the separate components.
SystemBlend™
SystemBlend’s design makes architectural-level changes quite easy. The drag-and-drop integration in the IntegrationMaster application makes it very easy to build, modify, and save different configurations of a simulation:
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