- Updates that are entirely contained within the component, and
- Updates that require a change to the interface.
Obviously, these categories apply to any MBD project. If you are managing a distributed project, these categories take on additional significance, and there is heightened need to differentiate between them.
Updates Within a Component
This type of update requires little of your managerial input, because each engineer is mostly working within his or her own ‘sandbox’. This is true whether you project is within one group or is distributed.
For projects within one group, you can assign a subsystem to the appropriate engineers, and these sandboxes are informally defined. Uncertainty in the boundaries between components is handled implicitly and informally by your engineers because they are co-located. The responsible engineers work mostly within their own part of the development, but if they need updates outside of their components (as described below), this can usually be handled informally.
In projects distributed across multiple groups, this segregation of responsibilities takes on added significance. Without managerial control over other groups, providing detailed guidance can be tricky. Addressing this requires a precisely defined sandbox:
- Clear boundaries ensure that the various subsystem developers know their responsibilities, greatly reducing your need to intervene.
- Compartmentalization ensures the different groups do not interfere with each other.
- The clear definition makes it clear to each developer when to request changes in other subsystems.
Updates Involving a Change to the Interface
In a project within a single group, simple changes across the interfaces between components are typically handled informally between your engineers. More complicated updates might need your input, but the difficulty is significantly reduced because you have full managerial control.
Without the proper tools, this type of update can be very challenging in a distributed project. It will require negotiation between the groups, which will typically require your input. It can even have contractual or political ramifications. Well-defined interfaces are critical:
- Communication between groups is less informal, and is not continuous. Without clear boundaries, errors at the interface will not be detected until much later during integration, or even during test.
- If the interfaces are not well defined, functionality at or near the interfaces could be duplicated or skipped.
- Ensuring compliance with negotiated interfaces also ensures that changes across the interfaces are solved at the source and do not result in recurring effort.
- I’ve worked on a few distributed MBD projects in which the engineers delivered components that did not match the needed interfaces, and the engineers integrating the simulation agreed to modify other delivered components to accomodate the alteration. For integrating the simulation one time, this is okay. However, MBD projects evolve and so require that the simulation be integrated again each time it is updated, so these deviations from the design would result in an recurring effort.
- When the engineers responsibe for integration modify components, debugging is much trickier. These changes introduced undertainty in the source of the bugs, which could in turn result in tensions between engineers.
In a distributed project, the need to identify errors early is critical. Errors identified during or after integration can be very challenging because different managerial domains are involved, and it often involves unproductive finger-pointing. To address this, not only do you need to define the interfaces, but you also need to ensure that the components comply with those interfaces.
Identifying the Two Types of Updates
At first glance, this might seem to be a trivial issue: Either it involves the interface or it doesn’t. However, this can actually be a significant source of difficulty in a distributed project. As described above, if the interfaces between components are not fully and unambiguously defined, it might not be clear whether a change affects the interface and whether an update requires action by another group.
Even if the interfaces are perfectly defined, you still need a mechanism to ensure the components comply with the interfaces. Engineers are human; they make mistakes. Even a team of conscientious, skilled engineers can misinterpret documents or misunderstand your intent. You need a way to ensure engineers properly implement the interfaces, to avoid downstream problems during integration.
This is not a major factor for a small project, but it becomes a driving issue in distributed projects. Any mistake in the interfaces will result in significant integration difficulties downstream.
SystemBlend™
The SystemBlend™ application suite addresses these issues in a unique way, by separating the design functionality from the implementation functionality:
- SystemDesigner: You and your engineers use the SystemDesigner application to define the components. It ensures that component interfaces and boundaries are accurately and completely defined.
- ComponentGuide: The groups implementing the subsystem models use the ComponentGuide to guide them as they implement the components. It generates an exact implementation of the interfaces, allows the engineers to work in whatever fashion they need, and ensures components comply with the interface.
- IntegrationMaster: Your engineers who are integrating the simulation use the IntegrationMaster application for team drag-and-drop integration. It is not involved in defining interfaces or ensuring compliance, but this is where you will gain the huge payoff. Because the interfaces are completely defined, and because the components are guaranteed to match the definitions, you can be sure that integration will be smooth and quick. In my previous experience, integration took days or weeks, but with IntegrationMaster the integration is just minutes.
SystemBlend™ provides interface definition, interface compliance, and separation of functionality without requiring you to learn a new simulation environment. It works on top of Simulink, protecting your investment in your models, tools, training, procedures, and engineers.
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