Ontology and Modeling Patterns for State-Based Behavior Representation

Abstract

This paper provides an approach to capture state-based behavior of elements, that is, the specification of their state evolution in time, and the interactions amongst them. Elements can be components (e.g., sensors, actuators) or environments, and are characterized by state variables that vary with time. The behaviors of these elements, as well as interactions among them are represented through constraints on state variables. This paper discusses the concepts and relationships introduced in this behavior ontology, and the modeling patterns associated with it. Two example cases are provided to illustrate their usage, as well as to demonstrate the flexibility and scalability of the behavior ontology: a simple flashlight electrical model and a more complex spacecraft model involving instruments, power and data behaviors. Finally, an implementation in a SysML profile is provided.

ESEM: Automated Systems Analysis using Executable SysML Modeling Patterns

“…In the future, we plan to improve some of the patterns related to behavior modeling (Castet et al 2015) to support executability. For example, we need to find a more formal way to tie constraints on value properties for each power mode (e.g.…”

Towards a Cradle-to-Grave, Mission-Wide Simulation System

“…The APGen DSL offers descriptive names for all these entities, as part of a language syntax which still contains many elements of its original design in 1996. In recent years, however, the Integrated Model-Centric Engineering (IMCE) initiative at JPL has embarked on a systematic attempt to capture the common elements of the many models used in the design, development and operation of space missions and to provide a uniform terminology for describing them [4]. Although IMCE is still a work in progress, it has the potential of making integration of heterogeneous models much easier than it is today, and we wholeheartedly support its efforts in that direction.…”

“…For instance, IMCE does not currently have a formal definition for what constitutes a subsystem, although the word subsystem is used informally in the examples mentioned in Ref. [4]. The IMCE ontology uses an abstract term, behaving element, to capture the essence of a system component; in fact, a component can be looked at as a concrete implementation of the abstract notion of behaving element.…”

“…Table 4 below lists the specifics of the DSN model. 1 APGen models commands as activity types, but can create special output products (e. g. sequence files) specifically for activities that represent commands 2 The IMCE Ontology includes timelines but not the means to generate them (other than the equations of physics) 3 If the model is implemented externally, the modeling section relies on the API specified in the user-defined library to express the required behavior 4 An activity type that implements a goal should contain decomposition or modeling information that enforces the constraint imposed by the goal 5 Elaboration is in the process of being added to the IMCE Ontology Table 5 below highlights the components of the GNC subsystem. Although GNC implementation varies from one mission to the next, computational components of the model such as quaternion algebra and matrix manipulation are mission-independent, providing significant heritage and reuse opportunities.…”

Automatically Generating the Technology Compatibility Matrix Using Graph Transformations

“…Although effective, it appears to only be applicable to mechanical and eletrical engineering domains, while continuum mechanics seem to pose a problem to this approach. The BeCoS tool developed by Kaderka et al [13,14] uses an ontology to describe systems semantically rigorous in terms of their behavior. State-machines describe transitions within the behavior and, combined with equations, enable analysis of the system.…”