Distributed MBD Project Lifecycle, Part 5: Replacing Components

This is the fifth in a series of posts discussing the lifecycle of MBD projects that are distributed across multiple managerial domains.

In some MBD projects, there will be a need to replace a subsystem model. Reasons for this include:

Trade studies.
Upgrade an initial subsystem model to a mature subsystem model.
Management decides to switch components.

Trade Study

A system-level engineer might want to compare two different subsystems in order to determine the best product configuration. Examples include:

Compare hydraulic controllers from two different vendors.
Compare different gyro concepts on a spacecraft.

An effective way to compare the efficacy of different subsystems is to create different instances of the same simulation, with a different subsystem implementation in each instance:

Setting up this experiment can be tricky, especially if the different models are supplied by different organizations (such as competing suppliers).

The Good News: Similar Information

The good news here is that the interfaces of the two different subsystems will be conveying very similar information, because they are performing similar functions. However, it might be in a different format. For example, I once compared two integrating gyros. One gyro output the angular rotation since the last reading. The other gyro output a series of pulses, with one pulse for every 10 microradians of rotation¹. Because these are virtually the same information, I was able to wrap the gyros so that the wrapper simply output the angular rotation, with negligible loss of accuracy.

This situation is best managed by encapsulating the candidate models in impedance-matching wrappers, as described in my post on model re-use. Such a wrapper can match units, coordinate transformations, and formatting.

In the best-case scenario (from a simulation POV), the competing subsystems will be built specifically for your product, and the product designers have specified that the two candidates will have identical interfaces.

The Bad News: Not Identical Information

This technique can be tricky when comparing different off-the-shelf solutions. Although the primary information used by the different candidates will be similar and can be handled as described above, there are often mismatches in the ancillary parts of the interfaces.

For example, one subsystem model might need a binary "enable" signal, while another model needs binary "start" and "stop" pulses.

This issue can become quite significant when dealing with safety-critical subsystems. Such subsystems will have guards against unsafe conditions, and the implementation of these guards can vary widely. This can be especially pronounced in the startup sequences.

In these cases, you will need to customize other components for each candidate. This will have a couple of drawbacks:

The comparisons will no longer be one-to-one. You can usually keep the two experiments sufficiently similar to provide a valid comparison, but this introduces the possibility of unidentified differences.
Maintaining the two different simulations presents development challenges. If the two different simulations evolve with your project, the possibility for drift between them grows.

Nonetheless, this is still the best way to compare candidate subsystems.

Industry Standards

If you are extremely lucky, you’ll benefit from industry standards. Two competing off-the-shelf candidates that have been built to the same industry-defined interfaces might be very compatible, making a one-to-one comparison quite straight-forward. Unfortunately, this is not the case for most engineering subsystems.

Be careful. Just because your candidate subsystems conform to an industry-defined interface does not necessarily mean they will be compatible. Some industry interface standards, such as CAN Bus or 802.11, only define signal form and data format, but do not specify what data or information crosses the interface. Conformance to these standards does not guarantee full interoperability between components.

Upgrading to a Mature Subsystem Model

In my previous post on launching a Distributed MBD project, I described how some Distributed MBD projects are launched with the intention of incorporating an existing, mature subsystem model at some point later in the project. In my previous post on subsystem model reuse, I described how the fidelity of subsystem models should approximately match the fidelity of the overall simulation. When starting a simulation from scratch with the intent to later incorporate a mature model, it is helpful to create a simple, low-fidelity placeholder to use until it can be replaced by the mature model.

This type of replacement is quite unlike a trade study replacement:

You are not trying to create a simulation that can support two different models,
You will not need to maintain two different but similar simulations, and
You plan to discard the placeholder model and keep the mature model.

Basically, this replacement can be viewed as part of the overall maturation of the simulation. As such, it makes sense to directly update the rest of the simulation as needed to support the new model. This one-time update will become part of your main software development branch.

Component Change

Engineering development can be very dynamic. As the team learns more about the product under development, some early decisions will be re-visited and changed. Sometimes these updates mean a subsystem is changed, perhaps to use a component from a different vendor.

Sometimes the decision to switch a component is based on a trade study performed by your team, as described above. In this case, you will have a ready-made starting point to support the new component. Simply discard the studies of the de-selected components, and you’re ready to go.

However, engineering decisions can be based on non-technical factors, such as schedule, availability, or cost. In these cases, the decision might come from outside or your team, but you still need to update your simulation to accommodate the change. In a distributed MBD project, this might require support from other groups. There are two considerations here:

If the vendor of the de-selected component is supplying the subsystem model, you will need to re-assign ownership of it, perhaps to the new vendor.
If the interfaces to the new subsystem model change, other components in the simulation will also require updates. This might involve additional groups.

As with any engineering development, coordinating groups that you don’t manage can be tricky. Fortunately, SystemBlend™ can streamline this.

SystemBlend™

SystemBlend’s precision interface control can be particularly useful when your updates involve other groups, such as:

A trade study in which the models are being provided by other companies or other departments within your corporation. You can use SystemBlend™ to specify an interface for each candidate model, and then task the other organizations with matching their model to your interface (this is best done with an impedance-matching wrapper).
A component swap that involves other groups. SystemBlend™ will guide you when specifying what changes are needed in your simulation.

Iteration

Most likely, you will need a few iterations on the interface to get the details right. SystemBlend’s publishing and versioning facility streamlines this type of iterative development, while keeping your overall team productive during the iteration.

System-Level Update

Just updating a component’s interface definition is not sufficient; any changes to one component’s interface will require updates to components connected to it. With SystemBlend™, you not only specify component interfaces, but you also specify connectivity between components. As you iterate on the interface, this connectivity information is an inherent part of design graphics, so it becomes a direct, unambiguous, and intuitive guide to updating other components as needed to support each iteration.

Other Articles in this Series:

Footnotes:

¹ I don’t remember the exact value of the quanta, but it was small.

Note: This post has been updated with links to other posts in the series