Distributed MBD Project Lifecycle, Part 4: Splitting Components

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

In any but the simplest MBD project, the team will need to split subsystem models as the project progresses. Depending on the particular situation, this will be either fairly easy or rather challenging, as I discuss below.

There are many reasons to split a subsystem model, but the most common are:

Complexity management, and
Split the subsystem’s digital controller from its mechanical implementation.

In addition to these topics, I’ll present a strategy for splitting a subsystem in a way that minimizes your risk.

Complexity Management

This is by far the most common reason for splitting a subsystem model, and it is usually the easiest to manage. Typically, the initial split will not introduce any functional differences, so it is more manageable than the other types of split.

Knowing when to split a model for this reason is a matter of engineering judgement, and is beyond the scope of this article. Many articles and books have been written on this topic in the more general field of software development. For information that is specific to MBD, I recommend you look into Model Engineering Solutions. They have excellent tools and training for this purpose.

Split the Digital Controller from the Mechanical Implementation

In some of the distributed MBD projects I have worked on, we started with simplistic subsystem models and added fidelity from there. For projects that led to production of a product, these simplistic models would need to be split so that the controls group could participate.

For example, a satellite project I supported in the early ‘90s was started with a ‘magical’ attitude control system. We needed to maintain sun-pointing, and the attitude control system consisted of simply adjusting the spacecraft’s attitude quaternion to maintain pointing. There was no control law and no models of actuators. As the project evolved, we added models of actuators, but the control law was still ‘magical’: it would issue commands based on idealized attitude knowledge. Eventually, to support the final design, we needed to split the digital controller model from the actuator and sensor models so that we could explore control strategies and later generate embedded code.

This type of split is sometimes the impetus for the project to grow from one group to multiple groups. For example, in an automotive system simulation, it probably makes sense to split the engine model and invite the embedded systems group to work on the engine controller.

Strategy: Cellular Mitosis

There is a strategy to split a simulation component that minimizes your technical risks. In a nutshell, you want to maintain the functionality and the interfaces through the split while isolating the churn from the rest of the system, before returning to functional improvements to the system.

Consider a generic subsystem that you want to split:

Encapsulate the subsystem to isolate the changes:

With the subsystem isolated, your team can make changes as needed without affecting other subsystems.

Your team works on splitting the subsystem within the encapsulating block. Because it is isolated from the other subsystems, they can tweak the internal structure as needed to achieve the split, and experiment with different strategies. Because the encapsulating block has the same interface, they can test changes to the internals in the context of the overall simulation.

No Split Buses

If you are lucky, your team won’t need to split any buses:

Your team can work within the encapsulating block as needed to explore different configurations, while testing as needed. Once the result is satisfactory, the encapsulation can be lifted without effecting other subsystems:

Split Buses

There will often be a need to split one or more of the buses when a subsystem is split. This is a more complicated case:

In this situation, it is helpful to introduce some temporary blocks to re-combine the buses:

With this setup, your team can experiment with different configurations until the desired result is achieved, while testing inside the larger simulation. By isolating the churn from the other components, your team will have a good understanding of what changes are required in other components before the update is finalized.

Once the desired result is achieved, your team can delete the temporary blocks and introduce the final configuration into the larger simulation:

Because of the isolation, your team will not need to alter other components until this final step.

SystemBlend™

The SystemBlend™ application suite was built to support and assist these types of system updates, especially when the update involves inviting another team, or affects the interfaces of other teams. The suite separates system design from subsystem implementation, so that the different groups negotiate the changes at the system level before beginning implementation. SystemBlend’s versioning and publishing facility ensures your team will be productive before, during, and after the updates.

Other Articles in this Series:

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

Distributed MBD Project Lifecycle, Part 4: Splitting Components

Complexity Management

Split the Digital Controller from the Mechanical Implementation

Strategy: Cellular Mitosis

SystemBlend™

Request More Information

Ready To Get Started?

Blend Dynamics, LLC