![Sample our Arts journals, sign in here to start your access, latest two volumes FREE to you for 14 days]({"type":"image" , "src" : "/sda/110799/TOC-Subject-Sample-2021-Arts.jpg"})
Abstract
Ontology has many applications to engineering but is not easily taken up by engineers. For example, specifying products in space and time together (four dimensions) enables more reliable modelling and analysis, but this work is primarily ontological and not accessible to most engineers. This paper summarises an existing method for integrating ontology and engineering, then applies it to four-dimensional requirements modelling, extending prior results. Requirements in this paper are treated as desired effects of a system on its operating environment. These effects are often respecified in multiple designs and tools, leading to redundancy and potential inconsistency. This can be addressed with centralised models of operating environment developed in systems engineering languages. These languages can specify the structure of operating environments formally enough to specify desired effects (except for spatial aspects), but cannot do the same for desired behaviour of those environments, because behaviours typically specify actions taken by a system to achieve those effects. This paper proposes new engineering-accessible extensions to logical system modelling for specifying intended environmental effects, including spatial relationships, without committing to the actions taken to achieve them. The proposed model supports centralised specifications of required system effects on their operating environments, enabling efficient integration with design.
Acknowledgements
The authors thank Chris Delp for leadership in promoting this work, Daniel Dvorak for clarifying state modelling of requirements, Al Jones for many helpful comments and discussion, and Moneer Helu and Tim Sprock for the example of process plan specialisation. Thanks also to Raphael Barbau and Ed Seidewitz for their ongoing work validating and informing some results of this paper with automated reasoners and library specialisation, respectively, which will be reported in the future.
Identification of any commercial equipment and materials is only to adequately specify certain procedures. It is not intended to imply recommendation or endorsement by the U.S. National Institute of Standards and Technology, nor does it imply that the materials or equipment are necessarily the best available for the purpose.
Disclosure statement
No potential conflict of interest was reported by the authors.
Notes
1 Sometimes the term ‘requirement’ includes descriptions of products developed at early stages, such as a marketing requirement on the weight of lawn mowers, or the color. In the terminology of this paper, such specifications are designs. The requirement is to be able to lift the lawn mower or that it is pleasing to look at.
2 References to SysML in this paper include UML unless otherwise indicated (SysML includes most of UML).
3 Control system requirements give desired effects on their operating environments, but numerically rather than ontologically. Typically these are desired values (steady states, set points) for numeric characteristics (variables) of the system under control, and acceptable ranges for the values of numeric characteristics as they reach desired values (Dorf and Bishop Citation2017). Control requirements might also give desired relationships between characteristics that change over time, possibly varying by ‘modes’ of systems under control (Morse Citation1995).
4 This enables UML to be extended for transformation to the Web Ontology Language (OWL) (OMG Citation2014; W3C Citation2012), a standard for interchanging SROIQ ontologies.
5 UML/SysML classes/blocks and generalization are equivalent to OWL classes and subclassing, respectively.
6 Dashed arrows for classification, and dividing lines between classes and instances are used in this paper for illustration, but are not SyML/UML notation. Instances here are actual, imagined, or simulated things, reflecting the meaning of ‘onto’ (real) in ‘ontology.’ Figures in this paper notate them with SysML/UML instance specifications, which are model elements, similar to OWL individuals, rather than real things.
7 Since four-wheel drive vehicles are also cars, John's car might be four-wheel drive or not. Models capture knowledge at the time they are created, which might be incomplete.
8 SysML properties are equivalent to OWL properties.
9 Properties at opposite ends of SysML associations are equivalent to OWL inverse properties.
10 SysML subsetting properties are equivalent to OWL subproperties.
11 SysML multiplicities are equivalent to OWL cardinality restrictions.
12 SysML redefining properties are equivalent to OWL universal property and cardinality restrictions that do not restrict the property types.
13 Part-part relationships are equivalent to conjunctions of OWL complex role inclusions (Krdzavac and Bock Citation2008). UML calls this ‘internal structure’, and SysML just ‘structure’. They are analogous to connections in mereotopology (Cohn and Varzi Citation2003).
14 Connectors inherit like properties do, see discussion of Figure in Section 3.2.
15 Metaclasses in this paper classify model (M1) elements, including elements that are not classes, such as properties (Scott et al. Citation2004). Only M2 Class and its subclasses categorize M1 classes.
16 Metamodels and models are analogous to syntax and semantics in language theory. Syntax gives rules for speaking or writing sentences in a language, while semantics gives rules for interpreting these sentences in terms of real, imagined, or simulated things (Genesereth and Nilsson Citation1987; Bock et al. Citation2006). Metamodels are an abstract form of syntax that omits visual or other concrete aspects of syntax (Bock Citation2003b; OMG Citation2015b).
17 Dependencies do not have implications for instances like generalizations do (see Section 3.1), making it unclear whether requirement satisfaction inherits to specialized blocks. SysML currently reproduces some generalization semantics unnecessarily in requirement satisfaction.
18 SysML uses a different relationship (stereotyping) between its metaelements and UML’s, but the effect is the same as generalization.
19 This could be highlighted by labelling generalization arrows with «satisfy» and «deriveRqt». These would come from basing SysML’s Satisfy and DeriveRqt stereotypes on UML Generalization rather than Dependency.
20 Activities are classes in SyML and can be specialized, along with links (redefinitions) between elements of special and general activities (actions and control flows), but these elements are not properties, making it unclear whether they inherit to specialized activities and how redefinition applies to them.
21 A superscripted -1 is used in this paper to indicate a property on the other end of an association from another property, see footnote 9 in Section 3.1.
22 Logical metaproperties also generalize engineering-specific ones, providing an ownedStep metaproperty for easily finding steps among the other properties of process plans, as well as fromStep and toStep restricting sequencing to step properties.
23 The latter option was suggested by Jim Logan.
24 The association for no overlap in time is restricted to the more commonly-used ordering in time (happensBefore).
25 Conditions on portions are taken to be sufficient, rather than necessary, meaning portions will ‘expand’ until the conditions are no longer true. For example, time slices for parked cars will take up all the time between neighboring portions when the car is not parked.
26 Portion properties are assumed to support an unlimited number of values, see multiplicities in Section 3.1.
27 The temporal connector in this example must have multiplicity 1 on both ends, which is the default (connector multiplicities apply only to values of the properties being connected). This ensures every occurrence (value) of a step infers exactly one occurrence (value) for the step after it, a logical equivalent of execution semantics (Bock and Odell Citation2011; OMG Citation2017b). When the same step happens more than once, resulting in multiple values (occurrences) per step, temporal connectors must be typed by an intransitive (but not anti-transitive) specialization of happensBefore. This enables step properties to have some values (occurrences) that happen earlier (transitively) than multiple values of the next step, and still satisfy one-to-one connector multiplicities. This intransitive temporal precedence is the logical equivalent of token movement in an operational token-based semantics (Bock Citation2003a).
28 This includes objects that are not changed during the behavior, but needed for it to occur. For example, the road in Figure is not affected by speed control, but is necessary for that to happen.
29 See adjunct properties in SysML (OMG Citation2017a).
30 This use of the term ‘state’ is not the same as in action-oriented state machines, which are for reacting to events (Bock Citation2000; Friedenthal et al. Citation2014).
31 This paper uses total systems for operation, but they can be specified for other lifecyle stages, for example showing interactions between systems and their environments during inspection, maintenance, disposal, and so on. Total systems for operations are similar but more detailed than SysML use cases.
32 This connector must have multiplicity 1 (which is the default) at least on the takingPicture end, to ensure each picture is taken by exactly one of these camera states (see footnote 27 in Section 4.2 for more about connector multiplicities).
33 This connector must have multiplicity 1 on both ends to ensure each operational state of the platform and heater is paired with exactly one negative state it is meant to bring to an end, and vice versa.
34 Equals signs in property compartments in this paper indicate all instances of the class must have the specified value for the property (SysML has a weaker meaning for this notation). An element symbol is used in this paper to indicate property values must be drawn from a specified set. These are equivalent to OWL object property restrictions ObjectHasValue and ObjectOneOf, respectively.
35 This means there exists at least one occurrence of a behavior that is not an occurrence of another (‘antigeneralization’).