State Analysis Ontology in SysML

8/13/2019 State Analysis Ontology in SysML

1/16

978-1-4577-0557-1/12/$26.00 2012 IEEE

An Ontology for State Analysis:

Formalizing the Mapping to SysML

David A. WagnerJet Propulsion Laboratory

4800 Oak Grove Dr.Pasadena, CA 91109

[email protected]

Nicolas RouquetteJet Propulsion Laboratory

4800 Oak Grove Dr.

Pasadena, CA 91109818-354-9600

[email protected]

Matthew B. BennettJet Propulsion Laboratory

4800 Oak Grove Dr.Pasadena, CA 91109

[email protected]

Steven JenkinsJet Propulsion Laboratory

4800 Oak Grove Dr.

Pasadena, CA 91109818-354-6055

[email protected]

Robert KarbanEuropean Southern Observatory

Karl-Schwarzschildstr. 285748 Garching, Germany

[email protected]

Michel InghamJet Propulsion Laboratory

4800 Oak Grove Dr.

Pasadena, CA 91109818-393-6426

[email protected]

Abstract

State Analysis is a methodology developed over the

last decade for architecting, designing and documenting

complex control systems. Although it was originally conceived

for designing robotic spacecraft, recent applications include

the design of control systems for large ground-based

telescopes. The European Southern Observatory (ESO) began

a project to design the European Extremely Large Telescope

(E-ELT), which will require coordinated control of over a

thousand articulated mirror segments. The designers are using

State Analysis as a methodology and the Systems Modeling

Language (SysML) as a modeling and documentation language

in this task. To effectively apply the State Analysis

methodology in this context it became necessary to provide

ontological definitions of the concepts and relations in State

Analysis and greater flexibility through a mapping of State

Analysis into a practical extension of SysML. The ontologyprovides the formal basis for verifying compliance with State

Analysis semantics including architectural constraints. The

SysML extension provides the practical basis for applying the

State Analysis methodology with SysML tools. This paper will

discuss the method used to develop these formalisms (the

ontology), the formalisms themselves, the mapping to SysML

and approach to using these formalisms to specify a control

system and enforce architectural constraints in a SysML

model.

TABLE OF CONTENTS

1. INTRODUCTION.............................................. 12.STATE ANALYSIS.............................................. 23.EARLIER MODELING EFFORTS........................ 34.ONTOLOGY DEVELOPMENT............................. 55.ONTOLOGY SUMMARY..................................... 56.MAPPING TO SYSML ........................................ 87.APPLYING THE PROFILE................................. 108.CONCLUSIONS AND FUTURE WORK............... 13ACKNOWLEDGMENTS......................................... 14REFERENCES....................................................... 14BIOGRAPHIES...................................................... 15

1. INTRODUCTIONtate Analysis is a formal methodology thatextends basic concepts from control theory and

software architecture to aid in the design ofcomplex control applications. Over the last tenyears as we have been elaborating and formalizingthis methodology we have also been searching formodeling frameworks and tools that might help totransition this from a collection of ad-hoc methods

into a more integrated process that more cleanlybridges the gap we see between system analysisand control software specification. The goal ofthis process is to make it easier for systemengineers to precisely express design intent in atool that actively helps to ensure consistency.

Over this period significant progress has beenmade in the field of model based systemengineering (MBSE), which shares similar goalsin a somewhat broader engineering perspective.Much effort has focused on the development and

application of the Unified Modeling Language(UML), its derivative the Systems ModelingLanguage (SysML), and tools that support theselanguages. While these languages and tools helpsignificantly to formalize the expression,exchange, and graphical representation of systemmodels, they remain ambiguous and in need ofextension to capture the specific semantics of agiven engineering domain. In the same way that

S


2/16

2

English or another human language requires thecreation and definition of new words to enable theprecise discussion of new concepts, modelingrequires the formal definition of concepts andrelations that are unique to a given domain so thatmodels elements can have precise meanings.Then, in order to express these concepts in aformal modeling language like SysML, a mappingis required between the domain concepts andrelations and those of the language.

In this paper we will first present a review of thearchitectural principles and methodology of StateAnalysis and summarize some earlier efforts inorder to set the stage for describing our currentwork. We will then describe our current ontology,its mapping to SysML, the process used todevelop and validate it, and an example system

analysis to demonstrate how the concepts areapplied to the analysis of a real system. We willconclude by describing some of the limitationsdiscovered during this effort and future work wehave identified to resolve them. We begin with adiscussion of the relevant architectural principlesthat guide our modeling approach.

2.STATE ANALYSIS

Spacecraft design is reaching a threshold ofcomplexity where customary methods of control

are no longer affordable or sufficiently reliable.At the heart of this problem are the conventionalapproaches to systems and software engineeringbased on subsystem-level functionaldecomposition, which fail to scale in the tangledweb of interactions typically encountered incomplex spacecraft designs. A straightforwardextrapolation of past methods has neither theconceptual reach nor the analytical depth toaddress the challenges associated with futurespace exploration objectives.

Furthermore, there is a fundamental gap betweenthe requirements on software specified by systemsengineers and the implementation of theserequirements by software engineers. Softwareengineers must perform the translation ofrequirements into software code, hoping tocapture accurately the systems engineer'sunderstanding of the system behavior, which is

not always explicitly specified. This gap opens upthe possibility for misinterpretation of the systemsengineer's intent, which lead to preventableimplementation and operational errors

State Analysis [1] addresses the above challengesby asserting the following basic principles:

- Control subsumes all aspects of systemoperation. It can be understood and exercisedintelligently only through models of the systemunder control. Therefore, a clear distinction mustbe made between the control system and thesystem under control.

- Models of the system under control must beexplicitly identified and used in a way that assuresconsensus among systems engineers.

- Understanding state is fundamental to successfulmodeling. Everything we need to know andeverything we want to do can be expressed in

terms of the states of the system under controlbecause ultimately those are the things we wish tocontrol.

- The manner in which models inform softwaredesign and operation should be direct, requiringminimal translation.

State Analysis improves on the current state-of-the-practice by producing requirements on system

Figure 1 State-Based Control Architecture


3/16

3

and software design in the form of explicit modelsof system behavior, and by defining a state-basedarchitecture for the control system. It provides acommon language for systems and softwareengineers to communicate, and thus bridges thetraditional gap between software requirements andsoftware implementation.

State Analysis provides a uniform, methodical,and rigorous approach for:

- Discovering, characterizing, representing, anddocumenting the states of a system;

- Modeling the behavior of state variables andrelationships among them, including informationabout hardware interfaces and operation;

- Capturing the mission objectives in detailed

scenarios motivated by operator intent;

- Keeping track of system constraints andoperating rules; and

- Describing the methods by which objectives willbe achieved.

For each of these design aspects, there is a simplebut strict structure within which it is defined: thestate-based control architecture (also known as the"Control Diamond", see Figure 1).

The architecture has the following key features:

- State is explicit: The full knowledge of the stateof the system under control is represented in acollection of state variables.

- State estimation is separate from state control:Estimation and control are coupled only throughstate variables. Keeping these two functionsseparate promotes objective assessment of systemstate, ensures consistent use of state across thesystem, simplifies the design, promotesmodularity, and facilitates implementation insoftware.

- Hardware adapters provide the sole interfacebetween the hardware in the system under controland the control system: They form the boundaryof our state architecture, provide all themeasurement and command abstractions used for

control and estimation, and are responsible fortranslating and managing raw hardware input andoutput.

- Models are ubiquitous throughout thearchitecture: Models are used for both execution(estimating and controlling state) and higher-level

planning (e.g., resource management). StateAnalysis requires that the models be documentedexplicitly, in whatever form is most convenientfor the given application.

- The architecture emphasizes goal-directedclosed-loop operation: Instead of specifyingdesired behavior in terms of low-level open-loopcommands, State Analysis uses goals, which areconstraints on state variables over a time interval.

- The architecture provides a straightforwardmapping into software: The control diamondelements can be mapped directly intoimplementation artifacts in a modular softwarearchitecture.

In summary, the State Analysis methodology isbased on a control architecture that is inherentlymodel-based and has the notion of state at its core.In the following section, we describe our earlyefforts at capturing the products of State Analysis.

3.EARLIER MODELING EFFORTSFrom its earliest stages State Analysis hasdeveloped graphical notations to conciselyexpress its concepts and relations. As in manyother fields we quickly discovered the limitationsof trying to do engineering with simple drawingtools such as PowerPoint and Visio. Althoughthey could create pretty pictures, these tools hadno representation of what the boxes and linesmeant, and so could not enforce any kind ofconsistency with the rules of State Analysis or

even the implied semantic conventions (e.g., colorcoding) in an individual diagram. Thus began oursearch for tools to enable more formal modeling.

The first prototype for a State Analysis databasewas built in 2003 with a fairly simple entity-relation schema. It supported multi-user web-based sharing through a browser form interfacebuilt using a simple web interface over a file-


4/16

4

based data manager. This development wasseminal in that it could be used to specify acontrol system architecture in terms of StateAnalysis concepts. However, the schema wasmanually encoded in the source code of the tool,making it difficult to analyze and update.

The second prototype was built using CommonLisp and the LOOPS object oriented databaseframework. Again, a web-based form userinterface was provided to allow users to captureState Analysis artifacts.

A formal description of the ontology was initiatedto guide the design of the database in this secondprototype. The ontology was described in terms ofan object-oriented design, with object types foreach of the State Analysis elements, each having

properties, and typed links to describerelationships between the State Analysis elementobjects. This tool performed better than theearlier one, but it still suffered in terms ofusability and maintainability because the ontologywas manually encoded in the tool implementation.

The last prototype, the State Analysis Database[2], was implemented using a commercialbackend relational database that was formallyspecified using XML and Entity-Relationshipdiagrams. The structure of the State AnalysisDatabase schema was developed to enableenforcement of the correct relationships betweendifferent model elements, between differentsoftware specification elements, and betweenmodels and the corresponding softwarespecifications. Thus, the schema prevented a classof architectural engineering errors, and provided aguide for doing a complete and consistentengineering analysis. The front end of thedatabase was a standalone web-client application.The client application could create html reports

desired by users. For example, a prototypecommand dictionary report generator wasimplemented. In addition to the form-based userinterface, a graphical interface was developed inthe client to draw some of the diagrams specifiedby State Analysis

The State Analysis Database had a client-serverdistributed system design. A single central

database was the repository for requirements andmodels. The database was hosted using acommercial database manager. Communicationwith clients and other tools was through SQLqueries and other industry standard mechanismsso that the database could be easily re-hosted on avariety of systems. The database could beaccessed through the internet using the HTTPprotocol a database web server serviced HTTPdatabase requests from clients and tools.

We designed the database schema to reflect theformal State Analysis process. Each of the kindsof architectural elements that could be modeled orspecified in State Analysis had a correspondingtable in the database. Relationships betweenarchitectural elements were captured as referencesto related elements in tables, or through the use of

linking tables between tables. The design wasguided by the nature of each kind of relationshipand the desire for the schema to enforcearchitectural rules where possible and reasonable,rather than having to rely completely on externalconsistency checking scripts.

Although we learned much about modeling, andrefined our concepts at each step, none of theseearlier tools gained much traction with the systemengineering community for doing real system

analysis because they just werent very easy touse, and they required significant effort toimplement and maintain. The desire for a moreuser-friendly graphical modeling interface basedon customizable tooling led us to the approachdescribed in this paper. The current approach is toleverage existing graphical interfaces provided bycommercial system modeling tools, which arefounded on the industry-standard modelinglanguages UML and SysML. SysML is created asa UML profile1, i.e. it extends the UML meta-

model using the stereotype mechanism.Murray [3] first prototyped a UML customizationfor State Analysis using the MagicDraw modelingtool. The profile, consisting of UML stereotypes,was manually created in MagicDraw[13],

1 A UML Profile is a collection of definitions for stereotypes, tags and

constraintsthat customize UML for a domain, redefining the semantics of

the modeling language by extension.


5/16

5

demonstrating for the first time the viability ofthis general approach.

Karban [4] is leading a team using State Analysisin the design of the control system for theEuropean Extremely Large Telescope (E-ELT), ahighly complex hardware/software system.

Because of their need to specify hardware,software, and system-level interactions,allocations, and other non-software properties,SysML is a more appropriate modeling languagechoice than UML. They have developed ahandmade profile for MagicDraw that definesmany of the basic concepts and relations fromState Analysis.

In both Murrays and Karbans efforts,customized stereotypes were used to apply

domain-specific meanings to model entities(Classes or Blocks) in order to help reduceambiguity. In the current version of UML/SysML,stereotypes are the only way to specify a domain-specific meta-model that can be readily mapped tomodel entities and their relationships.

Although these approaches have significantlyimproved the ability of graphical models toexpress design intent, and have made it mucheasier to integrate control analysis into systemmodels, they have only limited ability to verifymodel consistency with the underlying semanticmeaning of the applied stereotypes and relations.To achieve that it became clear that we needed tomore precisely formalize the concepts of StateAnalysis, and then map those concepts to SysML.

4.ONTOLOGY DEVELOPMENT

Our aim in this effort has been to provide amodeling framework for future applications ofState Analysis. that enables us to leverage recentadvances in graphical modeling tools, while alsoenabling us to perform formal analyses ofconsistency and correctness with respect to StateAnalysis domain relationships and constraints.Ontology is the study or analysis of thefundamental concepts and relationships in adomain. Here, the domain is that of software-intensive control systems. The State Analysisdomain is defined as an ontology in OWL2 [6]using the open-source Protg ontology tool [7].

The mapping of the State Analysis ontology into aprofile extension of SysML is defined as amapping ontology that relates concepts from thedomain ontology onto SyML elements that will beused to represent them in SysML models. Thisintegration of OWL2 and SysML facilitates usingOWL2 as a language and formalism forrepresenting heterogenous conceptual domains,for reasoning about properties of the domains, andfor simplifying the model-to-modeltransformation workflow required for projectinginformation from one domain into another[10,11]. Not only does this process allow us tocleanly separate the ontology from the semanticsof SysML, it also allows us more flexibility tochange the mapping of domain concepts (asstereotypes) into SysML entities or relationswithout affecting the concepts themselves. This is

important as the SysML standard continues toevolve. The mapping flexibility allows us tomaximize the usability of a State Analysisextension of SysML given the evolvingconstraints and limitations of the SysML abstractsyntax language and of the SysML concretesyntax diagrams.

The State Analysis ontology described here isconstructed on top of a set of related ontologiesdescribing the organizational and engineering

context in which State Analysis is performed.Ultimately, the product of State Analysis is aspecification for a deliverable control systemproduct. It is beyond the scope of this paper todescribe them here, but these base ontologiesdescribe and relate the concepts of project,mission (that is, the mission the system isdesigned to perform), and deliverablecomponents. Building upon these common baseconcepts makes it easier in the long run to relatediscipline-specific models built using the State

Analysis ontology with models from otherdomains such as software, electrical, ormechanical design that share the base concepts.

5.ONTOLOGY SUMMARY

The State Analysis ontology is divided into twolayers, one for the fundamental concepts ofphysical system modeling, and a second layerdefining the fundamental concepts of control


6/16

6

system modeling. This layering enables modelingof the physical system (the plant in controlsystem terminology, or system under control inState Analysis) to be independent of anyinfluences of the control system design, enforcingthe methodological emphasis on completing theanalysis of the physical system before beginningcontrol system design. As described in theprevious section, these mapping to SysML is thendefined in another separate layer in order to helpdecouple the semantics of the State Analysisontologies from those of SysML, and allow themappings to evolve with the SysML standard. Inthis section we will discuss key concepts in bothlayers. Note that the diagrams presented in thissection were generated from the OWL2 modeland a documentation generation transformation.

Physical System Modeling Concepts

Figure 2AffectedConcept

A fundamental concept in State Analysis is themodeling of state effects, or physical (causal)relationships between state variables of the systemunder control, the commands, and themeasurements of the system. To model thisrelationship we used the abstract entities AffectorandAffected. A StateVariableof the system under

control can be both the source and target of aneffect, and so derives from both. A Measurementcan only be affected, and a Command can onlycause an effect as shown in Figure 2 and Figure 3.The base concept Thing is simply an anonymousabstract container used as an OWL convention tokeep our model distinct from other ontologymodels in the same system of models. Thus, thereis one base Thing from which all of the StateAnalysis concepts derive, for the sole purpose of

identifying that they are all part of the sameontology.

Figure 3AffectorConcept

The state effect relation is reflected in the namedfilled-in arrow (representing an OWL2 property)

in Figures 2 and 3. The square brackets indicatethe multiplicity of the relationship. In this case itsays that an Affector can affect zero or moreAffectedelements.

The StateVariableGroup entity is a modelingconcept intended merely as a container for anarbitrary group of state variables, measurements,or commands in a diagram so that the model neednot express every single state effect in a singlediagram. This allows diagrams to express effectsbetween groups that can then be detailed in

separate diagrams for each group. In largecomplex systems this enables a moreunderstandable and incremental presentation ofthe model details.

Control System Modeling Concepts

In State Analysis, the control system is specifiedin terms of estimators and controllers that areassociated with the state variables of the system.Estimators and Controllers are the main active

elements that the ontology represents in theabstract concept ControlSystemComponent (seeFigure 5). A ControlSystemComponent can behardware or software that actively performs afunction (i.e., in software this would be a functionthat is scheduled to execute). An Achiever canactively perform the function of achieving a goal.A Controller achieves control goals (goals thatconstrain state variables of the physical system),whereas an Estimator achieves knowledge goals


7/16

7

that specify constraints on the quality of stateknowledge (level of acceptable uncertainty in theestimated values of state variables) needed toachieve given control goals.

Figure 5 Achiever

A FunctionalStateVariable is a control systemartifact responsible for representing the value of astate variable from the system under control. Asdepicted in Figure 4, there are several kindsreflecting distinct relationships with otherelements in the control system2. Two we willdescribe here are ControllableStateVariable andBasisStateVariable. As laid out in Figure 6, aBasisStateVariable has a relation with one

Estimator (i.e., it provides the knowledge basisfor control), and a ControllableStateVariable(Figure 7) has a relation with one Controller.

2 Functional state variables are also described as software state variables in

previous work. The new name recognizes that they do not have to beimplemented in code; for instance they could alternatively be implemented

as switches in hardware or registers on an FPGA board.

Figure 6 Basis State Variable

Note that a functional state variable can performboth of these roles. That is, a givenimplementation state variable can be bothcontrollable (representing a controllable statevariable of the system under control, and havingan associated controller to effect control), andbasis (having an associated estimator to provideupdates).

Figure 7 Goal Associations

In the process of developing this ontology and itsassociated mapping to SysML, a few refinementsto basic concepts were added as a result of the

Figure 4 Implementation State Variable Types


8/16

8

need to remove ambiguities or overloadedmeanings of certain concepts. One in particularhad to do with the concept of a Goal. As shown inFigure 4, the concept of a Goalwas divided intoseparate concepts for scheduled and unscheduledgoals. ScheduledActivities3 are those that havebeen coordinated on a timeline with all of theother goals and sub-goals needed to accomplish aplan, whereas Goals more abstractly specify intentthrough elaboration dependencies on other goals[1].

6.MAPPING TO SYSML

In general, our strategy for mapping theontologies into SysML is to define the ontologicalconcepts and relationships as SysML stereotypesthat can be applied to appropriate modelingentities: concepts to blocks, and relationships tosemantically compatible SysML relationships. Ina SysML tool such as MagicDraw, this can beaccomplished by creating a profile module todefine the stereotypes and any associated diagramand tooling customizations. In other attempts[3,4] the translation from ontology to profile hadto be performed by hand, which is not onlytedious, but also prone to error because they werenot based on a semantically verifiable ontology.

Figure 8 Controllable State Variable

Thanks to some advanced model transformationsdeveloped by JPLs Integrated Model-Centric

3Also called executable goals, or XGoals in earlier papers.

Engineering [10] team, the SysML profiles cannow be generated automatically from the OWL2ontologies, and validated in the process against aset of consistency assertions derived from thesemantic relationships defined in the ontologies.Furthermore, similar transformations, in theinverse direction, can then be applied to theSysML models to verify that any models that usethese stereotypes conform to the semanticsexpressed in the ontologies, and thus conform tothe rules of the architecture that they express.

One of the key challenges in this entire effort wasfinding appropriate mappings of the domainconcepts defined in our ontology concepts ontoSysML modeling entities (Block, Port, etc.).Although the basic entities in SysML are definedwith very abstract semantics, so that they can be

specialized to model a wide variety of systems (byspecializing the SysML stereotypes orspecializing UML meta-classes), one must beaware of these meanings and relationships inorder to avoid using them with domain semanticsthat conflict with the SysML abstract semantics.This is not something SysML itself would orcould enforce, but is something that could causeproblems for semantic reasoners attempting toapply formal methods to verify model correctness.Keeping the mappings to SysML distinct from the

domain ontology makes it easier to refine themappings or to define alternate mappings withoutaffecting the domain semantics.

Context diagram

A concept that came to State Analysis throughSysML is that of a modeling context. StateAnalysis establishes the need to formallydistinguish between the control system beingdesigned and the plant, or system under control,that it will interact with. SysML convention

further requires that the combination of controlsystem and plant be defined in a containingcontext in order to establish the extent of what isbeing modeled using an internal block diagram.We model the context in SysML as a blockstereotyped as a modeling context (see Figure 11),which will then contain the models for controlsystem and system under control. The diagramdepicting this relationship is called the context


9/16

9

diagram. The line between control system andplant is depicted in the context diagram throughthe containment of model elements into eithercontrol system or plant parts of the model. Theplant model can then be further decomposed, forexample into a physical system and anenvironment, or into multiple elements of adistributed physical system.

State Effects Diagram as ibd

The SA concept of a state effects diagram (SED)is implemented in SysML using an internal blockdiagram (ibd) associated with the modelingcontext block (see example in Figure 12). Usingan ibd associated with the modeling contextallows the model to express relations betweenspecific state variables contained within thecontext. Different modeling context blocks can becreated if it is necessary to consider differenteffect models for the same physical model (e.g.,models of different fidelity might be used atdifferent times in a development process), ordifferent configurations of the system as is likelyto be the case during concept studies. A blockdefinition diagram (bdd) would only expressrelations between state variable types, andalthough one can define very context-specifictypes, it seems more appropriate to expressrelations between specific instances definedwithin a context.

State Effects Models as Parametrics

The use of an ibd to represent state effects isbasically just an abstraction of SysMLs conceptof parametrics. The state effect relation ismodeled as a stereotyped dependency arrow thatindicates a causal effect. The behaviors behindthese relations can then be specified in SysMLparametric (par) diagrams (or possibly state charts

or activity diagrams, depending on the nature ofthe behaviors) to document the details of therelations in the form of mathematical formulae oralgorithms.

Goal Elaborations

In State Analysis, goals express user intent asexplicit constraints on state variables of thesystem under control over time. Goals are usually

defined abstractly so that the time domain, andoften the specific constraint, is expressedparametrically as a goal type rather than as aspecific goal instance. This concept of a goal typecan readily be expressed in SysML as astereotyped block. We have also tried modelinggoal types as use cases, with distinct propertiesand diagrams. The use case includes relation,where one use case depends on another issemantically quite similar to the SA elaboratesrelation (see Figure 9). Thus, applying the SAstereotypes to these SysML elements makes itpossible to express certain aspects of goalelaboration directly in use case diagrams (thosestereotypes extend the SysML UseCase Meta-Class).

Figure 9 Simple Goal Elaboration

The main drawback of this approach is that usecase diagrams have no notion of time. Goalelaboration diagrams must indicate the temporaldependencies between elaborated sub-goals andtheir parent goals. Our solution to this was to addstereotyped dependency relations between goalsto express a few simple temporal relationsincluding concurrent, and prerequisite. In theState Analysis theory such relations are expressedin the form of a mini temporal constraint network(TCN). SysML use case diagrams have no such

notion of time. This problem could be addressedby using parametric diagrams and SysMLConstraint Blocks to express temporal constraintsin such networks.

Use case diagrams also permit the use ofgeneralization to model goals that have alternatetactics as shown in Figure 10. This clearlyexpresses the notion that there are two ways the


10/16

10

parent goal can be achieved, but does not providea simple way to formally express the selectioncriteria, or specification of which tactic to choosein a given set of conditions.

Figure 10 Representing Alternate Tactics

Architectural Diagrams

Goal-oriented control systems are constructedusing Estimator and Controller components thatassociate with state variables to achieveknowledge and control goals. The functionalarchitecture of the system can be modeled inSysML using block definition diagrams (bdd) todefine Estimator, Controller, andFunctionalStateVariable types as parts of theControl System context block, and then using ibdsto model the internal connections between them(see example in Figure 16). The stereotypes for

these entities defined in our ontology constrain thekinds of information flow relations they can havewith each other. For example, an Estimator canhave an update relation with a State Variable, buta controller cannot. A Controller can issuecommands to a hardware adapter, but anEstimator cannot.

SA defines the concept of Hardware Adapter asan interface between the control system andsystem under control. In SysML we can modelhardware adapters as interface blocks and nested

ports. Ports are all that is necessary to documentsimple interfaces; aggregating several of theminto an interface block allows the model toexpress a little more design intent, or detail abouthow the system constrains the interfaces.

7.APPLYING THE PROFILE

For the purpose of exposition we define a simplesystem we can model using the concepts

described in the previous section. Our systemconsists of a controllable valve in a pipeline.Figure 11 depicts the context diagram for thissystem. We have defined a Physical System StateAnalysis block and a separate Control Systemblock, both contained in an Analysis Contextblock (those stereotypes specialize the SysML stereotype).

Figure 11 System Context Diagram

The Analysis Context block provides a context inwhich we can model relations between the controlsystem and the system under control it interactswith. The diagram indicates that the system under

control is a characterization of the actual physicalsystem and its environment, using a stereotypeddependency relationship (alternatively this couldbe expressed with a realization or specializationrelationship). Similarly, the control systemcontext characterizes the actual softwareimplementation. This separation between ananalysis context and the thing being analyzed canbe important in a larger modeling environment inwhich there may be multiple characterizations ofthe same physical thing. Note that the order of

creation may be different in these two cases.Whereas the physical system may exist prior to itscharacterization, the software implementationmay be created after conceiving the State Analysisfunctional architecture.

The System Under Control block is showncontaining a number of State Variable partproperties. The types of these State Variable part


11/16

11

properties are defined in separate diagrams (notshown), and stereotyped as State Variables.

The next step in the State Analysis process is todefine abstract state effects. Figure 12 shows howthis is done using an ibd. State effects areindicated using dependency arrows stereotyped

with the Affects stereotype. Also shown are theTapPressure measurement, and SetValvePoscommand that have been defined to enablecommunication between the physical and controlsystems. State effect relationships identified inthis diagram must subsequently be elaborated intodetailed state effect models, or measurementmodels using parametric diagrams or otherbehavior representations.

Figure 12 State Effects Diagram

Parametric diagrams provide a good way todocument state effect and measurement models asshown in Figure 13 and Figure 14. The constraintfunction inside of the constraint block can be inthe form of a mathematical relationship, orpseudo-code logic (SysML does not currentlyspecify the details of constraints).

Figure 13 State Effects Model as Parametric

Figure 14 elaborates the measurement model forthe TapPressure measurement. This diagrampreserves the abstractAffectsrelationship from theState Effects Diagram in order to show how thisabstract relation is realized in a parametric model.

The measurement model constraint block details

how actual pressure in the pipe, as represented bythe Pressure state variable, causes a particularmeasurement value to be produced. In StateAnalysis, measurement models are importantbecause they document factors such as sensorsensitivity and range, noise, and latency that mustbe compensated for in the estimation process.

Figure 14 Measurement Model as Parametric

Once the system under control has beensufficiently modeled, the design of the controlsystem can begin. In this system we define

functional state variables to represent each of thestate variables identified in the state analysis (seeFigure 15). Stereotyped dependencies indicatethat each functional state variable implements oneor more state variables in the system under control(the control system design can opt to aggregateclosely-related state variables into a single datastructure, particularly if they are all updated at thesame time). Estimator components are defined foreach state variable, and a controller is defined forthe Valve Position (similar relations are defined

for the Flow state variable, not shown). All ofthese elements are defined as part properties in thecontrol software context block described above.


12/16

12

Figure 15 Control Component Definitions

Finally, we can describe the architecture of thecontrol system in terms of its information flowusing another ibd (Figure 16). Note that theinterface between the elements inside the controlsoftware context (the content of the diagram) andthe system under control is depicted using aninterface block described as a HardwareAdapter.This block is defined elsewhere in the model

containing typed ports for each of the commandand measurement types that the control systemwill exchange with the system under control.Command and Measurement elements aremodeled in SysML as signals that flow throughflow ports. The flow ports indicate the direction ofthe flow (in SysML 1.3 this will be modeled with

flow properties). Measurements always flow fromthe system under control into the control system.Commands normally flow from the controlsystem to the system under control, but we defineour hardware adapter so that it can buffer one ormore previously sent commands for reference bythe control system. In our very simple example,the valve position estimator has no direct sensingof the valve position (see Figure 13), so it uses thelast sent command to infer the valve position.

The profiles for MagicDraw are constructed sothat the stereotype menus will only offer thosestereotypes that apply to the selected SysMLentities or relations. For example, to create thestate effect relations in Figure 12, the part blocks(whose types are already stereotyped as ) are automatically added

when the diagram is created. An effect is modeledby drawing a dependency arrow from theaffecting state variable block to the affected statevariable block, and then applying the stereotype. If an effect arrowhad been drawn from a measurement to a statevariable the stereotype would not have beenoffered as an option because this is an invalidrelation according to the ontology. In this way thesemantics of the ontology inform the modelingtool to help enforce model consistency with the

rules of the domain. Similarly, these underlyingconstraints are available to MagicDraws built-invalidation tool, or to external tools that can parsethe model and assess consistency of relations.This improves significantly the usability for themodeler, and the ability to validate models duringmodeling.


13/16

13

8.CONCLUSIONS AND FUTURE WORK

Applying stereotyped relations in models allowsthe model to be analyzed to compare thesemantics and constraints expressed in the

stereotype definitions with the details of themodel, in order to verify that the model conformsto the semantics of the domain expressed in theontology. This work has demonstrated that it ispossible to define meaningful domain-specificstereotypes using a model transformation fromOWL2, apply them in a SysML modeling tool,and then use those stereotypes to verifycorrectness properties in the model. Whencomplete, the State Analysis ontology and SysMLprofile should enable control system engineers to

model system behaviors, specify controlbehaviors and intent, and have the model enforcesemantic consistency rules established by theprinciples of State Analysis.

This work improves on previous efforts to enablethe use of SysML to perform State Analysis byproviding a set of tool-specific customizations andmodeling patterns that achieve much of the intentof State Analysis. However, some SA concepts

have yet to be modeled and mapped, and wecontinue to refine others as our technique evolves(several concepts evolved significantly over thecourse of writing this paper). Because thisremains a work in progress we have onlydescribed the modeling and mapping of a few keyconcepts from SA. In particular, we have yet tofind entirely satisfactory representations forintent, including goals and goal networks inSysML. Consequently, our current effort isfocused on formalizing the modeling conceptsrelated to intent and behavior, including goals,scheduled activities, temporal constraints, and theways these concepts associate with state variablesand the flow of time. The modeling of behaviorsis the focus of significant effort in the modeling

community and at JPL [5, 12]. While much of thestandards-focused effort focuses on descriptivemodeling of behaviors, our work also intends tomodel the relationships between intent (goals) andbehavior that explains, through State Analysis,how the behaviors satisfy the specified intent.

We have experimented with using activitydiagrams (stereotyping activities as scheduled

Figure 16 Functional Architecture


14/16

14

goals), and using fork-join relations to representtime points. This is problematic in that activitydiagrams cannot easily express temporalconstraints on the activities, and because thetoken-passing semantics expressed in the SysMLstandard are inconsistent with those of goalnetworks. More recently we have begundeveloping a separate timeline ontology [5] andapplying its concepts as stereotypes to theseactivity diagrams, to express temporal semanticsdistinct from those of SysML This is a focus ofcurrent work.

Considerable work remains to formalize the graphstate variable concept [8] in SA. Graph statevariables relate position, orientation, or otherrelative states within frames of reference.Describing these relations formally requires

defining frames of reference, coordinate systems,and the mathematical structures for representingmultidimensional quantities. Since those conceptsare meaningful outside the domain of SA it seemsbest to define those in a separate ontology andreference them in the SA ontology. As of thiswriting that work remains incomplete.

We continue to reconcile and refine our JPLontology and SysML mappings with onesdeveloped separately by our colleagues at the

European Southern Observatory. While theconcepts and relations defined in our separateontologies are mostly consistent, small differencesremain to be resolved. Most of the refinements atthis point involve deep relations within baseontologies that will help to relate concepts acrossmodeling domains.

ACKNOWLEDGMENTS

Special thanks to Robert Rasmussen, DanielDvorak, and Seung Chung who also contributed

to the ontology development and review.

This research was carried out at the Jet PropulsionLaboratory, California Institute of Technology,under a contract with the National Aeronauticsand Space Administration and at the EuropeanSouthern Observatory.

REFERENCES

[1] Ingham, M., Moncada, A., Bennett, M.,Rasmussen, R., Engineering ComplexEmbedded Systems with State Analysis andthe Mission Data System, AIAA Journal ofAerospace Computing, Information, and

Communication, Vol. 2, No. 12, December2005.

[2] Bennett, M., Rasmussen, R., Ingham, M., AModel-Based Requirements Database Tool forComplex Embedded Systems, InternationalCouncil on Systems Engineering (INCOSE)International Symposium, Washington D.C.,2005.

[3] Murray, A., Rasmussen, R., A UML Profile forState Analysis, IEEE Aerospace Conference,

Big Sky, MT., 2011.

[4] Karban, R., Kornweibel, N., Dvorak, D.,Ingham, M., Wagner, D., Towards a StateBased Control Architecture for LargeTelescopes: Laying a Foundation at the VLT,13th International Conference on Acceleratorand Large Experimental Physics ControlSystems (ICALEPCS), Grenoble, France, Oct.2011.

[5] Chung, S., Delp, C., Fosse, E., Sarrel, M.,Bindschadler, D., Representing Informationusing Timelines for System Design to SystemOperations, IEEE Aerospace Conference, BigSky, MT., March 2012.

[6] Web Ontology Language (OWL),http://www.w3.org/2004/OWL/

[7] Protg OWL Ontology Editor,http://protege.stanford.edu/

[8] Bennett, M., R. Rasmussen, ModelingRelationships Using Graph State Variables,IEEE Aerospace Conference, Big Sky, MT.,March 2003.

[9] QVT (Query/View/Transformation) -Operational, http://www.omg.org/spec/QVT/,http://www.eclipse.org/m2m/.


15/16

15

[10] Bayer, T.J., Bennett, M., Delp, C.L., Dvorak,D., Jenkins, J.S., Mandutianu, S., Update Concept of Operations for Integrated Model-Centric Engineering at JPL, IEEE AerospaceConference, Big Sky, MT., March 2011.

[11] Rouquette, N., Jenkins, S., Transforming

OWL2 Ontologies into Profiles ExtendingSysML,12

th NASA-EST Workshop on Product

Data Exchange, Oslo, Norway, May 2010.

[12] Conrad Bock, James Odell, OntologicalBehavior Modeling, Journal of ObjectTechnology, Volume 10, (2011), pp. 3:1-36,doi:10.5381/jot.2011.10.1.a3.

[13] MagicDraw modeling tool,https://www.magicdraw.com/

BIOGRAPHIES

David Wagner is a software system

engineer and architect in the System

Architectures and Behaviors group at

JPL and was a principal developer of

the Mission Data System in 2000-

2006. Since then he has continued to

apply MDS technology and State

Analysis in several applications. He is

currently a member of the project

system engineering team on the Europa Habitability

Mission formulation project. He has a BS in Aerospace

Engineering from the University of Cincinnati, and MS inAerospace Engineering from the University of Southern

California.

Robert Karban is a Software

Engineer at the European

Southern Observatory (ESO),

developing highly distributed real-

time control systems for telescopes

since 1996. His current main task

is the modeling and development of interdisciplinary

systems, in particular the control system of the E-ELT, as

its system architect. His roles have varied from project

manager to developer, including mentoring, and devising

development standards. Robert has also been leadingINCOSEs Model Based Systems Engineering (MBSE)

Challenge team on Telescope Modeling since 2007,

providing practical applications of SysML in the

astronomy domain. He is a certified OMG Systems

Modeling Professional - Advanced. Robert Karban

received his M.S. in computer science in 1990 from the

Technical University of Vienna, Austria. Afterwards he

worked several years in the Medical Engineering

industry, and developed in the European Organization for

Nuclear Research (CERN) embedded software for

accelerator control systems.

Nicolas Rouquette is a Principal

Engineer in the Systems and

Software Division at the Jet

Propulsion Laboratory. Nicolas

pioneered comprehensive code

generation of flight/ground software

from high level systems engineering

specifications for the Deep Space One mission. As a

leading expert in modeling and model transformation, he

represents NASA's interests at the Object Management

Group (OMG) where he recently chaired the 2.4 revision

of the Unified Modeling Language (UML) and produced

the last two versions of the Systems Modeling Language

(SysML). Dr. Rouquette received his M.S and Ph.D. in

Computer Science from USC.

Steven Jenkins is a Principal

Engineer in the Systems and Software

Division at the Jet Propulsion

Laboratory, currently supporting

JPL's Integrated Model-CentricEngineering Initiative. His interests

include application of semantic and

modeling technologies to systems

engineering. Dr. Jenkins holds a B.S.

in Mathematics from Millsaps College, an M.S. In

Applied Mathematics from Southern Methodist

University, and a Ph.D. In Electrical Engineering

(Control Systems) from UCLA.

Matthew Bennett is a Senior

Software Systems Engineer in the

Systems Engineering section at the Jet

Propulsion Laboratory. His research

interests include model based

engineering, software architecture,

fault protection, and spacecraft

autonomy. He has designed,

developed, and delivered

architectures, software and technologies for human-

robotic interaction, model-based engineering, fault

protection, autonomous planning and scheduling, control

systems, data visualization, guidance and control,

performance analysis, and simulation. He holds an MS

from the University of Washington in Computer Science,

and a BS from the University of California at San Diego

in Computer Engineering.

Dr. Michel Ingham is the supervisor of

the System Architectures and Behaviors

group, in the Systems Engineering

section at the NASA Jet Propulsion

Laboratory. His research interests

include model-based methods for

systems and software engineering,

software architectures, and spacecraft


16/16

16

autonomy. He is a core contributor to JPLs Integrated

Model-Centric Engineering initiative, and model-based

systems and software engineering efforts across the

Laboratory. He has played an important role in the

development and formalization of the model-based systems

engineering methodology called State Analysis, and its

application to the design and implementation of state-based

flight and ground software architectures. Dr. Ingham

received his Sc.D. and S.M. degrees from MIT's Departmentof Aeronautics and Astronautics, and his B.Eng. in Honours

Mechanical Engineering from McGill University.

Documents

State Analysis Ontology in SysML