Misinterpreted ICDs
Even if your team is very diligent when authoring textual ICDs, you will almost certainly encounter a situation in which another group will misinterpret your team’s work.
When I think about the various ICD misinterpretations made in my past experience, the only commonality is that all of them were quite unexpected. This is because written language is not well suited to the computer-grade precision needed for defining systems. A few examples will illustrate the variety of misinterpretations:
- I once wrote an interface definition for a discrete-event simulation. For some reason I don’t remember, I described the interface as "variable timing" instead of "discrete event". I received a confusing email from the engineer implementing the interfaces, and we had a phone call that was just as confusing for a few minutes. I finally realized that "variable timing" could be interpreted as "fixed timing during the run, but timing changes from run to run". The other engineer had assumed the alternate definition (without realizing it) and was trying to implement it as a strange discrete-time simulation.
- Interface documentation can specify MKS (meters/kilograms/seconds) in the introductory paragraphs, and also specify all angular units are radians, and then not specify units on individual signals. Only the most diligent engineer will read and understand that. Typically, an engineer will scan the introductory paragraphs and see "MKS", and might not see the angular specification. (By the way, it is best practice to always specify units separately on each signal.)
- Several times I’ve encountered coordinate frame issues in spacecraft simulations, particularly in velocities and accelerations. To a computer, a velocity is just three floating-point numbers. All engineers understand that a velocity is a vector, which is the first derivative of position of a point, relative to some coordinate frame. But like any vector, to express it in a computer requires the three coordinates, which don’t have any meaning unless the reference frame is specified. In other words, the floating-point triplet specifies the motion of a point relative to one frame, expressed in some (possibly different) frame. For example, a vector in an interface can be "The speed of the center of mass of the spacecraft in the earth-centered inertial (ECI) frame, expressed in spacecraft coordinates": The point is the center of mass, and the two coordinates frames are ECI and spacecraft coordinates. This distinction is critical to properly interpret gyros and accelerometers that are fixed to the spacecraft.
I have not found a sure-fire way to avoid misinterpretation in textual interface definitions, simply because these errors have been both varied and unexpected. If you are writing textual ICDs, the best you can do is to view the document from the reader’s point of view.
SystemBlend™
SystemBlend™ addresses most of these issues to accelerate your distributed MBD project:
- The timing specification in SystemBlend™ is unambiguous and not open to misinterpretation.
- The units specification in SystemBlend™ is unambiguous, and if you are using a later version of Simulink, these units will be enforced.
Other than units, SystemBlend™ does not have a direct way to ensure proper engineering interpretation of interfaces, such as coordinate frames. However, your engineers can attach notes to almost any design element in the application suite, to provide a textual description of the intended use.
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