Back to the Systems Engineering Concept Model (SECM) Working Group Wiki
Property & Expression Modeling Focus Team
Team
Roger Burkhart, Harald Eisenmann, Manas Bajaj, Ilya Tolchinsky, Nerijus Jankevicius, Hans Peter de Koning
Status: Draft concepts and requirements available for review
Objectives
The objective of the team is to establish the set of requirements for a comprehensive concept model of system property as defined in the SEBoK:
“Any named, measurable or observable attribute, quality or characteristic of a system or system element. (OMG 2003)”
see http://sebokwiki.org/wiki/System_Property_%28glossary%29 .
This activity is a precursor to developing the full set of concept model requirements. The concept of system property is tackled first, as it is a central concept in any system model. In SysML v1.4, these concepts are modeled as:
ValueType and ValueProperty
Annex E.5, Model Library for Quantities, Units, Dimensions, and Values (QUDV)
Limitations of SysML v1
Limited support for compound value properties: e.g. computer data record, vector, matrix, nth-order tensor, array, quaternion, …
No support for value property collections: a variable-length list (or sequence), set, bag, ordered set of a particular value type
Too simplistic support for measurement scales other than ratio scale (in QUDV)
The inability to easily restrict a valid range of values for a value property. One can do this with constraints, but it should be very simple to do. For example, one may wish to restrict the valid range of values for water temperature to 0 – 100 degrees Celsius or 32 – 212 degrees Fahrenheit.
Complex meta-model (including QUDV) leads to implementation inefficiencies for tool vendors and usability issues for end-users
A (numerical) value type defines (and fixes) a selected measurement unit, but the actual measure scale in use (rather than unit) for a value property of a given value type should be selectable from a set of permissible measurement scales
Ideally SysML implementations would be capable of doing automated scale conversion of numerical property values, but the meta-model (including QUDV) has insufficient information to do so in all cases
Limited support for tabular (discretely sampled) data like time series, frequency spectra, temperature (pressure, enthalpy, …) dependent material properties, etc.
Limited support for uncertainties and probability distributions / density functions
SE Needs for Properties & Expressions
-
-
Draft high level class diagram:
Glossary of Terms
compound property: property that comprises other (possibly nested) scalar or compound properties, and has as many values as it has (nested) properties.
Note: A compound property is a generalization of a structured, multi-component property such as a vector, matrix, higher order tensor or computer data record.
Examples: 3D Cartesian coordinate, velocity vector, complex number, quaternion, rotation matrix, elasticity tensor, time-stamped diagnostic message.
physical dimension: synonym of quantity dimension
precision: maximum number p of significant digits that can be represented in a format, or the number of digits to that a result is rounded.
Source: IEEE-Std-754-2008.
Note: In this definition the kind of 'digit' depends on the selected format: in a 'binary format' is it a 'binary digit', in a 'decimal format' it is a 'decimal digit'.
-
quantity: property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
Source:
VIM
quantity dimension: expression of the dependence of a
quantity on the base quantities of a system of quantities as a product of powers of factors corresponding to the base quantities, omitting any numerical factor
Source:
VIM
scalar property: property with a single value
system: combination of interacting elements organized to achieve one or more stated purposes
Note 1: A system may be considered as a product or as the services it provides.
Note 2: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun, e.g., aircraft system. Alternatively, the word “system” may be substituted simply by a context-dependent synonym, e.g., aircraft, though this may then obscure a system principles perspective.
Source: ISO 15288:2008
system element: member of a set of elements that constitutes a system
Note: A system element is a discrete part of a system that can be implemented to fulfil specified requirements. A system element can be hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities (e.g., water, organisms, minerals), or any combination.
Source: ISO 15288:2008
system property: named observable characteristic of a
system or
system element
simplification of “any named, measurable or observable attribute, quality or characteristic of a system or system element”: “observable” includes “measurable”, “characteristic” includes “attribute” and “quality”
Source:
SEBoK, derived from
SE Conceptual Model Semantic Dictionary (Draft #12, 2003-03-27)
value: particular magnitude or designation for a given observable characteristic
Examples: (1) the value 1540.5 expressed in kilogram for the “mass” property of “my car”, (2) the value red for the “color” variable, (3) the default value true for the “isEncrypted” boolean formal parameter of operation “sendData”, (4) the value 299792458 expressed in m/s for the “speed of light in vacuum” physical constant.
value type: named definition of the essential semantics and structure of the set of possible values of an observable characteristic, without the value itself
Driving Requirements
The requirements for Properties, Values Expressions (status 26 April 2017) are provided hereafter in an Excel file. Currently the requirements are transferred to the SECM Team Cloud Server model.
Older versions of the requirements specification are kept below:
Requirements Analysis
A first analysis iteration to help elaborate and validate the requirements has been performed. Two different data modeling approaches have been used:
UML object-oriented class diagram at meta-model level,
RDF/RDFS/OWL ontology style semantic data model, including some example instantiation (RDF/OWL 'individuals').
UML Object-Oriented Data Model
MOF and RDF/OWL Modeling Stacks
RDF/OWL Experimental Ontology
As an experiment an OWL equivalent of the UML class model was created, including a very simple instantiation of an HSUV car with 4 wheels, where each wheel has a diameter of 17 inch. The following 4 ontologies are in the stack:
secm-core (Upper Ontology)
secm-iso-iec-80000 (Middle Ontology - Example of a normative model library)
secm-us-customary (Lower Ontology - Example of a user-defined model library)
secm-hsuv-test01 (Lower Ontology - Example of a user-defined system model)
As tool Protege v4.3 is used. All files are encoded in Manchester OWL Syntax for easiest human readability.
Open Issues
Include and merge generic “value type” concept.
Can we replace “system property” with just “property” and include it to represent properties of environment / some global context?
Further explore possibility of dual object-oriented and ontology conceptual data model approach - useful?
More detailed requirements and prototyping on expressions and constraints.
References
Conceptual Data Modeling Methodologies
Ontology Definition Metamodel (ODM), v1.1, OMG, 2014-09-02, see
http://www.omg.org/spec/ODM/1.1/
In particular the explanation in section 8.5 “Why Common Logic over OCL?” as well as the overview and mapping of Common Logic in chapter 12.
-
-
-
-
-
-
Quantities, Measurement Units and Scales, Quantity Dimensions, Physical Constants, Metrology
-
-
-
-
IEEE-Std-754-2008 - IEEE Standard for Floating-Point Arithmetic, IEEE, 2008, see
IEEExplore
Prototypes and Applications