Data Capture
A critical part of any simulation is data output; it is the basis for any engineering analysis of the modeled system. Capturing and using this data presents additional difficulties in a Distributed MBD project.
Choice of Outputs
In an engineering simulation, the data needed for analysis changes during the project lifecycle. Early in the project, the focus might be on feasibility, while later in the project the focus will be on refining the design. The choice of outputs also changes depending on the reason for running a simulation. The data needs of an engineer optimizing booster parameters will be very different from those of an engineer optimizing the coverage of an on-board sensor.
In a project within one organization, this churn can be difficult, but is typically managed at a low level by the engineers working on the project. Engineers working side-by-side will informally decide what is needed from each other’s subsystems and feed it to an output.
This low-level, informal interaction is impeded, or maybe even impossible, when the participating engineers are working in different groups.
Don’t Modify Components from Other Organizations
When working on a Distributed MBD project, it can be tempting for the team that is integrating components to perform surgery on a contributed component to capture an output that is needed but not explicitly provided. Do not do this.
Typically, the engineers that originally built the component won’t like this. In general, modifying another engineer’s work is an encroachment on professional etiquette. More specifically, they are responsible for the component and its outputs, and they lose control, but not responsibility, of the component when others modify it. Most engineers are team players, so when this occurs they will understand why it was done. However, there is the occasional engineer that is highly possessive and will elevate the issue.
Larger problems occur when things go sideways. When the simulation is not working as expected, diagnosing the problem will require coordination between the different organizations. Because the involved engineers are not routinely working side-by-side, the diagnostic effort will typically require email and phone calls, and maybe even travel, between the different organizations. This effort can require leadership and personnel skills that most managers would rather avoid. These difficulties can be significantly compounded by the ready-made excuse "My component was fine until you changed it". It is best to simply remove this variable from the equation.
Coordinating Outputs
My experience indicates that the best way to manage the outputs on a Distributed MBD project is to implement a process to coordinate this:
- It must have a mechanism to precisely define what outputs are needed, and
- It must have a mechanism to rapidly implement the needed changes without impacting the rest of the project
SystemBlend™
SystemBlend™ implements the concept of "auxiliary outputs". These are ordinary parts of the component interface specification, except that they are not an input to another component. These outputs are captured by the simulation, and can optionally be disabled so that the data is not recorded.
If the team decides that all components implementing a particular ICD should have an auxiliary output, they can add it at the system level with the SystemDesigner application:
- If the output should be specified at the system level, the output can be added in SystemDesigner. This would be propagated to ComponentGuide where the new output would be added.
- If an engineer running the simulation needs a specific output from a component, he or she can directly contact the engineer implementing the component to request it. This workflow does not require updates at the system level.
Regardless of which workflow is used, any updates can be implemented without interrupting any other work, due to SystemBlend’s publishing and versioning facility.
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