All can be measured by the standard of the capybara.
from Unit of Measure by Sandra Beasley
Everyone is lesser than or greater than the capybara.
Everything is taller or shorter than the capybara….
What is our job as Systems Engineers? One Chief SE where I work boils it down to three things: requirements, CONOPS, and interfaces. In some other post we will talk about the first two, but for now let’s look at what is needed to define interfaces. Specifically to share data in a consistent format.
It’s near October 31st so let’s start with a scary story: all of us know the fate of the Mars probe that crashed due to a metric/SI mistake… there are others (see Six Unit Conversion Disasters ). My favorite is Columbus.
In all of these cautionary tales the concepts were correct, but the application was not. In each the data shared was inconsistent. So let’s see what is available within MBSE to help us share data that is universally understood and create consistent interfaces.
I generally believe that enterprise architecture should not be considered Systems Engineering, rather something that precedes it. However DODAF describes three data item views (DIVs) that would be useful here:
- DIV-1 is conceptual and shows a data exchange, the type of information we would depict at the highest level (or even in DODAF diagrams).
- DIV-2 is logical and shows the elements of the data exchange. This is where we define the messages (and message parameters) passed in an interface.
- Finally DIV-3 is physical and shows the format of the data exchange: think bit positions, Big/Little Endian, and how we define a number.
In the past few weeks I’ve had two experiences that have shaped my opinion of these Data Views.
The first experience was an ANSYS SCADE software demonstration. This is a sophisticated tool for generating safety critical software for aircraft. The demo focused (at least to me) on transforming data structures into platform specific data elements. As a recovering Software Engineer I have spent decades creating or implementing messages where the position of a bit was all important. In the SCADE ecosystem the design does not specify the physical representation.
The second experience was with a SWaP rollup pattern built into my MBSE tool of choice. As an MBSE practitioner, if you are not using these rollup patterns you are missing the lowest of low-hanging fruit. But, as implemented out of the box, these patterns look at size, weight, or power in a unitless world. I noticed this the hard way. (Not quite as hard as the Mars Probe, but still…) I had items in my BDD that had mass specified in imperial pounds (and stored as a “Real”) and also items where the mass was in kilograms (also stored as a “Real”). The pattern rolled up a total (as it should) but obviously there was a problem.
So back to our calling as Systems Engineers to provide universally consistent interfaces. I would argue, cajole, plead, and beg that our systems models should minimize the use of primitive types (reals, integers, strings) and should define values with units of measure, preferably using the ISO-8000 standard. This is in line with the Logical Data View DIV-2, which is where our systems models should live. This standard defines almost every conceivable unit and is built into most modeling tools. It does not, however, include a capybara unit.
Photo by Dušan Smetana on Unsplash