Distributed MBD Project Lifecycle, Part 9: Naming Collisions

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

Naming Collisions

The most difficult problem when receiving Simulink components developed by outside organizations is naming collisions, because the architecture of the Matlab/Simulink ecosystem has very poor name scoping.

The most obvious example of this is the Matlab workspace. Simulink developers tend to create initialization scripts that place variables in the Matlab base workspace, and then reference those variables from the Simulink models. Clearly, if one organization creates a simulation component that initializes a variable named "V0", and a different organization creates a component that initializes a variable named "V0", then there will be a conflict when trying to bring these components into a single simulation.

To a Simulink developer, variables in the Matlab workspace are effectively ‘global’ variables. There are many articles and book chapters describing the evils of global variables, so I won’t go into that here except to say you really don’t want any global variables.

Simulink Masks

The Simulink block mask is an excellent mechanism to provide name scoping. Variables defined in a block’s mask are scoped to that block and its subsystem blocks.

Unfortunately, exploiting this feature is more complicated than using variables in the base workspace, so Simulink developers never (or almost never) use it exclusively, leaving the possibility of naming collisions between components.

Bus Names

In Simulink, non-virtual buses are always defined in the base workspace. This presents opportunities for naming collisions between buses, because Matlab’s base workspace is basically a global namespace.

Evolution

This problem can be magnified as your project grows and evolves. Consider a component that is updated during the development of your simulation, and the definition of a variable is changed. For example, one version of the component has a data structure named "initialConditions", and in the later version of the component the same data structure has the same name, but has been refactored to a different layout.

Sometimes, a later version of a component supplants all of its earlier versions, in which case there will not be a naming collision. However, there are situations where different versions of a component will be integrated into the same simulation. For example, a team might want to compare the performance of an upgraded component with the older version of the component, presenting an opportunity for a naming collision.

Component Copies

There are situations in which your team will need more than one copy of a single component integrated into your simulation. For example, an aircraft might have multiple identical hydraulic pumps. In a high-fidelity simulation, each copy of the pump component will have different parameters, perhaps to model manufacturing differences.

If the parameters in a component are not properly scoped, the different copies of the component will have naming collisions.

SystemBlend™

SystemBlend™ has a design and architecture that addresses these issues in a unique fashion.

Buses

Buses in component interfaces are defined at the system level in the SystemDesigner desktop application, which ensures uniqueness of bus names. Uniqueness is ensured as your project matures and evolves by SystemBlend’s versioning and publishing facility.

System-Level Parameters

System-level parameters are also defined in SystemDesigner, ensuring uniqueness within and between updates to your simulation.

Component-Level Parameters

Component-level parameters are defined in ComponentGuide, and uniqueness is ensured in a different fashion. Parameters in Simulink models and parameters in Matlab initialization scripts are handled separately:

For modeling, SystemBlend™ ensures uniqueness of component-level parameters in Simulink by exploiting masks. To support this:
- ComponentGuide automatically generates a skeletal Simulink block with the component’s parameters in the mask.
- ComponentGuide automatically generates customized Simulink blocks to streamline access to the mask variables, making masks very easy to use.
- The customized documentation generated by the ComponentGuide application describes each mask parameters and each custom block in detail.
For initialization scripts, SystemBlend™ exploits the name scoping within Matlab functions. To support this:
- ComponentGuide automatically generates skeletal initialization scripts.
- These functions are passed a Matlab struct containing the component’s parameters.
- The comments in the initialization script describe in detail how to access the parameters.
- The customized documentation generated by ComponentGuide describes each parameter in detail, and describes how to access the parameters in initialization scripts.

Components might define non-virtual buses for use internally, which can create a naming collision with other components. I’ve never encountered this problem in practice, simply because the bus names created by different organizations have been different. Nonetheless, this is still a possibility. Blend Dynamics, LLC is exploring techniques to address this.

Other Articles in this Series:

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