Understanding Values, Value Types, Units and Quantity Kinds/Dimensions.

“A model without values has no value”  – Dr. Darren Kelly

This topic is a natural follow-on to the previous parametric modeling discussion.  When modeling systems at an abstract level, it is usual to define a set of attributes or parameters that will be important in driving design.  Examples include Measures of Effectiveness MOEs), Measures of Performance (MOPs), Key Performance Parameters (KPPs), Critical Parameters (CPs), and Technical Performance Measures (TPMs).  Please not that defining these parameters is not the same thing as assigning values to them… the actual numbers that drive or represent the performance of the system design.  Assigning or computing these values is one of the key objectives of requirements/performance/feasibility analysis.

Unfortunately, quite a number of system models never get past the abstract attribute phase… and never included real values!  In a way, the presence of numerical values is an indicator of the maturity of the model.  How, then, are values actually represented in a SysML model?  Well, once a Value Property (a.k.a. attribute) has been defined in a SysML model, most tools provide a field where a number can be entered directly.  This field technically should be titled “Initial Value”, since it doesn’t represent the actual value of the property in all circumstances and contexts.

For example, let’s say we are modeling an automobile in Rhapsody, so we define a Block named Automobile, and a Block named Tire.   Even if the car has four of them, we only want one definition of Tire.


Then we define a Value Property (attribute) of Tire named Pressure.  If I want to enter a value for the pressure of the tire, the best I can do at this point is enter an initial value.  Let’s say we enter the value 35.  The tool may also force us to enter an attribute type. This is really so the tool knows how to store the value… integer, string, double, float, etc..  Of course, these attribute types really have nothing to do with pressure… but more on that later!


Now, everywhere the tire is used (or the Tire block is used to type a Part, such as leftfront:Tire, leftrear:Tire, etc.), the default value of Pressure will be 35.    This value is not contextualized… Every tire on the car has a value of pressure that is exactly 35.


Is that realistic?  No, but it may be adequate as a starting point.   SysML provides a couple of way to specify pressure such that the value of leftfront:Tire.Pressure can be different from the value of leftrear:Tire.Pressure.  Through the arcane concept of property specific types, the modeler can re-define the initial value for a particular context.  Rhapsody can actually do this pretty well.  Just open the attributes on leftfront:Tire and insert a new value:


And here’s what happens on the ibd:


The other mechanism SysML uses for context specific values is instance semantics.  These can actually be more robust than redefinition of values, but tool support of this concept seems to be inconsistent.  Readers are highly encourage modelers to consult the INCOSE MBSE Wiki, and particularly the Telescope MBSE Challengeto see how they managed to resolve analysis issues without directly using contextualized values in SysML.    A SysML descriptive model can still fulfill the role of a system design document or specification without contextualized values…  it is just more powerful if it can address contextualized values!

As shown by the tire example above, it is entirely possible to specify values without identifying meaningful Value Types.  Analysis routines and equations don’t use units and dimensions (a.k.a “quantity kinds”), they just crunch numbers.  It is the systems engineers that have to keep track of the units, and manually insert conversion factors in the code!  In fact, Phoenix MBSEpak works just fine without units and dimensions!  The website for the InterCAX family of plug-ins has demonstrated use of value types (perhaps with full units and dimensions) for MagicDraw, Artisan Studio, and Enterprise Architect.  They only have demonstrated the “Real” attribute type in Rhapsody, but as a company InterCAX is aware of the metrology required to track and transform values between units, and is attempting to incorporate that into their tools.

A textual requirement may specify a particular value, such as in a specification document or table.  When such values appear, they always include the units.  The overall requirement may captured as a text string attribute of a SysML Requirement element, and the value may even be exposed for explicit binding to a parametric evaluation constraint (MBSEpak includes just such an extension mechanism to SysML).  The units associated with the value in the requirement, however, have not been so well treated.  It is currently up to the modeler to keep track of the units and conversion factors.

A SysML Value Type is used, obviously, to type a Value Property. It ties together a Unit, along with a Quantity Kind (previously known in SysML as “Dimension).  The Quantity Kind can be length, surface area, volume, mass, etc.  Values may be transformed from one type of Unit to another, as long as they have the same Quantity Kind.  By using a standard formalism for Units and Quantity Kinds when establishing Value Types, we are building the ability to automatically transform values into our models.   The good news is that a standard library of Value Types, Units, and Quantity Kinds can be imported into your SysML model as a library, so you don’t have to reinvent anything.   In fact, the SysML specification includes an appendix that defines SI Units and Quantity Kinds, and most tools have codified this library and made it available.  Once these Value Types are available in the model, they can be used instead of the standard “string, double, float” etc. Attribute types when defining a Value Property.  If you use a good Value Type library, unit conversions can become automatic.

Back to our tire example, the Dimension pressure, the Unit pounds per square inch, and the Value Type psi have been defined.  This could have been done using a library, but this way the browser is less cluttered for example purposes.  Also included is the unit newton-meters, but that is actually inconsistent with pressure.  This is a mistake… the modeler originally meant newtons_per_meter^2, but the author left it in the example because it makes a good point.


This Value Type was then applied to the attribute Pressure.  Of course, this only had to happen once, and all the usages of Tire were also updated.



Note that each domain will need to extend the “standard” Value Types library to include things that are unique to that domain.  PK (probability of kill) for instance is unique to military applications.  PRA (probability of raid annihilation) is unique to air defense.  The reader is sure to think of others.

Readers are highly encouraged to walk through the ESA Telescope Model online, paying particular attention to their treatment of units & dimensions (look under “MD Customization for SysML::SI Definitions” and  “QUDV Library”), and parametric analyses (“APE::APE_Performance”).


1 Comment

  1. Here is a comment from Manas Bajaj, posted with permission:

    Hello Rick

    Great to read your blog posts. Two quick comments on the post: http://blog.ricksteiner.net/?p=86

    (1) For Rhapsody, we have not demonstrated units because they (IBM/Rhapsody) do not provide a QUDV library yet. A SysML tool should provide this. We can start providing a QUDV library as part of Melody/SLIM-for-Rhapsody but then that would not reach as many users as Rhapsody would, and really it is the responsibility of the SysML tool. But, we are really open to providing it if you, as a user, think it would be valuable. Note, we are working on automated unit conversions too as part of our parametric solver capability.

    (2) Requirements – Since SysML does not provide property-based requirements (yet), we have taken the approach to represent requirements as constraint blocks (via a refine relationship), and then use that constraint block in a parametric models to automatically verify requirements. A requirement constraint block provides an easy way to model the requirement as a mathematical equation which is more precise than just getting the numerical value from the requirement text. The Satellite model included in ParaMagic / Melody tutorials shows this approach.


    Manas Bajaj, PhD
    Chief Systems Officer
    InterCAX LLC
    75 5th Street NW, Suite 312
    Atlanta, GA 30308, USA
    Email – manas.bajaj@intercax.com
    Voice – +1-404-592-6897, x101
    Web – http://www.intercax.com
    Twitter – http://www.twitter.com/InterCAX

Leave a Reply

Your email address will not be published. Required fields are marked *