- The lead engineer produces a design that doesn’t include engineering units, and the developers must either negotiate the units amongst themselves, or they must go back to the lead engineer for clarification:
- A model developer produces a byzantine initialization script that the analysts must spend time learning in order to use it:
- A subsystem model developer does not follow the design, requiring the simulation integrator to either modify the model or go back to the developer:
- A modeling error in a component might not manifest until it is running in the integrated simulation:
These are problems for any MBD project, but they are vastly magnified in a distributed project:
- Re-negotiating a design between different companies is far more difficult than within a single team.
- Learning a script written by an engineer in another company is much more frustrating than learning a script from a colleague that sits in the next cubicle over.
- Learning a script written by an engineer in a different company is far more time consuming than learning a script written by a coworker in the same office.
Because these problems span different managerial domains, any or all of them can become political, which will frustrate everybody involved.
SystemBlend addresses this in two ways: Automate the details, and resolve higher-level issues at the source of the problem.
Automate the Details
The graphical nature of SystemBlend guides developers through the details, ensuring the low-level details are properly handled wherever they are encountered.
SystemDesigner ensures the low-level details are complete in the design. For example:
- It ensures interface details, such a data types, timing, and engineering units, are supplied in the design.
- It ensures the interfaces between the components are compatible.
- It ensures connectivity between the subsystem models is fully defined.
- It ensures appropriate parameters are applied to each model, and it ensures global constants are properly initialized.
By automating these details, SystemDesigner eliminates these low-level problems and others.
ComponentGuide ensures the low-level details are complete in the model implementation. For example:
- It ensures each model complies with the interface specifications.
- It ensures model parameters are properly initialized.
- It ensures model parameters are in a well-defined, easily discoverable location.
- It ensures the initialization scripts run without input from the operator.
By automating these aspects of development, SystemBlend eliminates the back-and-forth to work out the low-level details. This is a major time-saver in a distributed MBD project: you no longer waste time negotiating details across multiple different managerial domains, your simulation integrator no longer requires extensive support from the model developers, and your simulation operators no longer need to learn arcane scripts.
Resolve Higher-Level Issues at the Source
Automating the low-level details frees up the team to focus on the hard engineering problems, such as:
- Ensuring the simulation design matches the engineering goals,
- Properly modeling the subsystems, and
- Upgrading the design as the simulation project evolves.
The workflow in SystemBlend ensures that issues at these higher levels are resolved at the source, instead of allowing them to flow downstream. Examples include:
-
Errors in the simulation design can be discovered either by the groups that are using ComponentGuide to develop subsystem models or by the group that is integrating the simulation using IntegrationMaster. Either way, the workflow in SystemBlend ensures that the issues are resolved at the design level, in SystemDesigner.
Modeling errors in a subsystem model can be discovered by the engineers integrating the simulation in IntegrationMaster. The workflow in SystemBlend ensures that the issue is resolved by the group that developed the subsystem model.
As the simulation project evolves, the SystemBlend workflow ensures the updates to the design are made at the source, in SystemDesigner.
Updates to subsystem models, that don’t require system-level modifications, are handled at the model level using ComponentGuide and not downstream during integration.
By ensuring higher-level problems are resolved at the source, the problems are resolved once, instead of repeatedly every time the simulation is updated.