Without the proper tools, components built by other groups (and even within your own group) might not comply with their ICDs. This is caused by one or both of these issues:
- Imprecise ICDs
- ICD Noncompliance
This article describes the first topic: Imprecise ICDs.
Imprecise ICDs
In my past experience with distributed MBD projects, we would have difficulty defining ICDs. This occurred on every project in which I participated. Although I encountered errors in almost every part of ICDs, the most common issues were
- Units
- Timing
- Multiplicity
- Connectivity
Units
Without the proper tools to address the units on each signal, two components can appear to connect just fine while the simulation doesn’t run correctly. Usually, the simulation results will be obviously incorrect, but the cause might not be obvious. Like any simulation error, there are many possible causes and tracking down the culprit can be difficult.
I’ve encountered this issue in many different ways:
- On some projects, the units were simply overlooked in the ICD. This would occur on the first iteration of the ICDs at the beginning of the project, and inevitably one of the groups would ask about units. The group developing the ICDs would promptly update all of the ICDs to include units and re-issue them, and all subsequent ICDs would include units. Nonetheless, it cost us an iteration.
- I worked in a group providing Independent Verification and Validation (IV&V) for an aerospace project in which the prime contractor was a large, well-known corporation. As part of the IV&V, we were tasked with reviewing some of the prime contractor’s procedures, including their ICDs. I was surprised to see that most of their ICDs did not include units.
- Engineers have left off critical angular information because "Radians are unitless", which is quite correct. Regardless, all angular signals, including radians, should have units to prevent confusion with degrees or microradians. Also, angular rates and accelerations should include the angle unit e.g., using rad/sec instead of sec-1 clarifies and emphasizes that the signal is rotational velocity and not some other information such as sample rate.
- I learned this lesson the hard way on a satellite project early in my career. There was a mismatch between guidance and control in the flight software that we launched. I forget the exact details, but one side was interpreting a signal as the thruster force, and the other side was interpreting the same signal as the spacecraft acceleration. I had to take responsibility for this because I was in charge of the simulation to validate the spacecraft software. It didn’t ruin my career only because I was extremely lucky: Due to the nature of the mission and the way the guidance system used the acceleration, this turned out to be a minor deviation from the optimal operation. The mission was quite successful and nobody cared much. Nonetheless, it was a hard lesson to learn.
- Perhaps the most spectacular example of this was NASA’s Mars Climate Orbiter that failed due to a units mismatch during planetary capture.
Simulink has addressed this issue quite well. Simulink has included units information in its signal definition for a long time, and in recent releases the units are being checked. Exploiting this feature requires a little more work, but use it anyway. This feature will trap and diagnose units errors early, and can save your team from many debugging sessions.
Where possible, your team should apply ‘pseudo-units’ to signals that don’t have any engineering units, to add clarity. For example, if an integer is counting the number of times a subsystem has been cycled, it is helpful to apply a units of ‘counts’. The digital output of a sensor could be in ‘least-significant bits’ or LSBs, but more information is conveyed if instead the units are something like ‘.023 mm’ or ‘152.1 Pascal’. Applying ‘pseudo-units’ can interfere with units checking facilities like what is included with Simulink, so this might not apply to all situations.
Timing
This issue has similarities to the Units issue:
- It is easy to overlook timing in the initial iteration of a project, but it is usually resolved after a few iterations.
- Errors in timing usually result in obviously incorrect results, but can be difficult to diagnose.
However, I haven’t encountered this issue as often in my career, simply because engineers seem to be more aware of the need for timing information.
Although I’ve never seen it used, Simulink provides facilities to address this. Inports and Outports can have a timing specification applied to them. By applying this specification to the Inports and Outports in each component’s top-level diagram, Simulink will trap timing mismatches between components.
Multiplicity
A fully specified ICD will include multiplicity to indicate the number of other components connected to a signal. There are many possibilities, including:
- 1-to-1. Exactly one component generates the signal, and exactly one component receives the signal. This is the most common situation.
- 1-to-N. Exactly one component generates the signal, and a specific number of components receive the signal. For example, one engine controller drives exactly 6 cylinders.
- 1-to-Many. Exactly one component generates the signal, and the number of components receiving the signal is not known until integration. For example, one battle manager controls whatever launchers are available.
- N-to-1. A specific number of components generate the signal, and one component receives the signal. For example, exactly four wheel sensors provide data to the ABS subsystem.
- Many-to-1. The number of components generating the signal is not known until integration, and all of the signals are received by exactly one component. For example, a battle manager will want input from whatever radars happen to be available.
- Many-to-N. The number of components generating the signal is not known until integration, and a specific number of components receive the signals. For example, multiple on-board radars provide data to 3 redundant autonomous controllers.
Obviously, there are other combinations of ()-to-(), but you get the idea.
In Simulink, the N-to-() combinations are handled with fixed-sized arrays. Simulink does not have good support for the various Many-to-() combinations, because Simulink does not have good support for variable-sized arrays. SystemBlend™ overcomes this in a simple, unique fashion described below.
Another aspect of multiplicity is fanout: If a signal is sent to multiple destinations, will it be the same signal to all destinations or different for each destination? For example, an engine controller will send different a signal to each cylinder, but a hydraulic pump will send the same pressure to all valves.
The multiplicity of connections is system-level information as opposed to component-level information. However, this should be included in the ICDs because it impacts how the component is implemented.
Connectivity
For this article, I’ll define ‘connectivity’ to mean information that specifies which components can connect to which.
Consider the combination of a gyro, a filter, and an attitude controller. In the intended configuration, the gyro feeds its output to a filter, and the output of the filter goes to the attitude controller. The gyro and the filter both output angular information, and the controller takes in angular information. Without connectivity information and a mechanism to ensure correctness, the gyro could be connected directly to the controller.
This is system-level information that is not easily conveyed in ICDs, but is important for the proper operation of the overall simulation. A good system-level tool will include mechanisms to specify this information and to ensure compliance.
SystemBlend™
Units and Timing
The SystemBlend™ application suite is built on top of Simulink, and uses the Simulink facilities described above to ensure units and timing are properly implemented in a simulation. This is done in three steps:
- Timing and units information is specified in the SystemDesigner application,
- The block generation step in the ComponentGuide application puts these mechanisms in place, and
- ComponentGuide’s verification step ensures these mechanisms remain in place.
Multiplicity
For most combinations of multiplicity, SystemBlend™ uses Simulink’s ordinary connectivity facilities. For the Many-to-() combinations, SystemBlend™ automatically implements a mechanism that is very easy to understand and use by an ordinary Simulink user. A lot goes on behind the scenes to make this happen, but the final result is a simple interface that a simulation engineer will immediately understand. This is further supported by the port-by-port descriptions in the customized user’s guide that is automatically generated for each component by ComponentGuide.
Each connection’s fanout is specified in SystemDesigner’s graphical design pane. This information is used in ComponentGuide to generate the appropriate interfaces for each connection. Finally, this information is used in the IntegrationMaster application to ensure each component’s connectivity is satisfied.
Connectivity
As I mentioned above, connectivity is not actually part of an ICD specification, but is nonetheless important for proper integration.
Connectivity is specified by simply drawing it in SystemDesigner, which generates an intuitive presentation of the system-level connectivity. This connectivity information is used in ComponentGuide to implement the appropriate interfaces, and IntegrationMaster uses it to ensure each component is correctly connected.
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