Design methodology and specification modelstatic.inf.mit.bme.hu/decoscd/deliverables/DECOS_deliv_Design_Methodology.pdf0.3w 16/09/2005 PIM metamodel changed + Chapters restructured

Version: 1.0r Status: released DECOS_deliv_Design_Methodology.doc

Design methodology and specification model

D 1.1.3

Document Identification

Document Id: DECOS_1.1-016_1.0r_D113

Date: 30/09/2005 Assoc. Deliv.:

D 1.1.3

Contact Person: Prof. A. Pataricza Org.: BUTE

Phone/Fax: +36 1 463 3595 E-Mail: [email protected]

Status Name Date Signature

Created/updated:

Reviewed:

Released Coordinator:

DECOS Design methodology and specification model Page 2/51


Distribution Table

Name Company Department No. of copies

Hardcopy/ Softcopy

all partners 1 e-copy

Change History

Version Date Reason for Change Pages

Affected

0.1w 15/07/2005 Initial version all

0.2w 20/08/2005 PIM example changed Chapter 4

0.3w 16/09/2005 PIM metamodel changed + Chapters restructured all

0.4w 22/09/2005 Design methodology changed Chapter 5

1.0r 30/09/2005 Final version all

Authors

This deliverable is based on the contributions of all DECOS partners and it was created by the DECOS team at the Budapest University of Technology and Economics (A. Balogh, Gy. Csertán, O. Dobán, I. Majzik, A. Pataricza, D. Varró, Sz. Varró-Gyapay), the DECOS team at Technical University of Darmstadt (Md. S. Islam) and the DECOS team at ARCS (G. Weissenbacher).



Contents

1 Executive summary.............................................................................................................................5

2 Objectives and Scope .........................................................................................................................6

3 PIM metamodel update .......................................................................................................................7

3.1 Changes of the PIM metamodel ............................................................................................................7 3.2 PIM metamodel and SysML ..................................................................................................................7 3.2.1 SysML metamodel.................................................................................................................................7 3.2.2 Comparison of SysML and PIM metamodel........................................................................................17 3.3 Data model of the PIM.........................................................................................................................18

4 Design methodology .........................................................................................................................21

4.1 General workflow.................................................................................................................................21 4.2 Targeting DECOS architecture............................................................................................................21 4.3 Software development.........................................................................................................................23 4.4 V&V test bench....................................................................................................................................24 4.5 Creating the PIM..................................................................................................................................25

5 Interfacing DECOS PIM to SCADE...................................................................................................27

6 Design example .................................................................................................................................29

6.1 Description of the doors subsystem ....................................................................................................29 6.1.1 Description of the modules ..................................................................................................................29 6.1.2 Component diagram of the doors subsystem......................................................................................35 6.1.3 Non-functional requirements of the doors subsystem.........................................................................36 6.2 PIM of the example..............................................................................................................................37 6.3 Creation steps of the example PIM .....................................................................................................42 6.3.1 Definition of the DAS ...........................................................................................................................42 6.3.2 Definition of jobs ..................................................................................................................................44 6.3.3 Definition of resources.........................................................................................................................45 6.3.4 Definition of messages ........................................................................................................................45 6.3.5 Definition of interfaces and ports .........................................................................................................46 6.3.6 Definition of the communication ..........................................................................................................48 6.3.7 Definition of variables ..........................................................................................................................49 6.3.8 Definition of performance constraints..................................................................................................49

7 References .........................................................................................................................................50

8 Appendix ............................................................................................................................................51

Figures

SysML extension of UML....................................................................................................................................8 SysML package structure ...................................................................................................................................9 Graphical nodes in Assembly diagrams .............................................................................................................9



SysML Assembly with parametric Constraint ...................................................................................................10 Metamodel Extensions .....................................................................................................................................11 Metamodel for Rate Distribution .......................................................................................................................11 Probability .........................................................................................................................................................11 Graphical nodes in allocation diagram .............................................................................................................12 Abstract syntax for Requirement metamodel ...................................................................................................13 SysML requirements model..............................................................................................................................13 Model Library Quantities...................................................................................................................................14 Modeling methodology workflow ......................................................................................................................21 Model Transformation (PIM to PSM) ................................................................................................................22 PIM-PSM transformation workflow ...................................................................................................................23 Step of PIM creation .........................................................................................................................................26 Component diagram of the doors subsystem...................................................................................................36 The top-most diagram of the PIM example ......................................................................................................37 Packages of the functionality package .............................................................................................................38 The top-level Job package of the doors subsystem.........................................................................................38 The Job package of the left-front mirror ...........................................................................................................39 Resources of the left mirror ..............................................................................................................................39 The Message package of the left mirror...........................................................................................................40 Interfaces and ports of the left front mirror. ......................................................................................................40 Communication of the left front mirror ..............................................................................................................41 Variables of the left mirror ................................................................................................................................42 Content of the Performance package...............................................................................................................42 Top-level package diagram of the doors subsystem........................................................................................43 Functionality package of the PIM .....................................................................................................................43 DAS diagram with the Normal operating mode ................................................................................................44 Job package of the mirror functionality.............................................................................................................44 Job breakdown of the mirror functionality to left and right side ........................................................................44 Jobs of the left front mirror module...................................................................................................................45 Resources of the left mirror ..............................................................................................................................45 The packages of the messages package.........................................................................................................46 Messages of the mirror functionality.................................................................................................................46 Interfaces and variables of the doors subsystem.............................................................................................47 Interfaces and ports of the Automatic Movement job .......................................................................................47 Communication packages of the doors subsystem..........................................................................................48 Communication of the left front mirror ..............................................................................................................49 Variables of the left front mirror ........................................................................................................................49

Tables

Comparison of SysML metamodel and DECOS PIM metamodel ....................................................................16



1 Executive summary

The work presented in this document is part of Workpackge 1.1 (WP1.1) of Sub-project 1 (SP1) of DECOS. SP1 addresses three issues:

• the Platform Interface Layer (PIL) and its application programming interface (API);

• allocation of Distributed Application Subsystem (DAS) jobs to available hardware and software by transforming the Platform Independent Model (PIM) of these DASs to a Platform Specific Model (PSM);

• support for DAS development.

The specification models developed in SP1 are based on requirements provided by the application and the technology sub-projects and partners. The current work focuses on the refinement of the specification of a metamodel for the PIM and to define a modeling methodology that is based on requirement capturing, the creation of a PIM, and the PIM-to-PSM transformation.

The aim of the workpackage (WP 1.1) is to develop representation models to capture the fundamental properties of each DAS / job in a platform independent way. In addition requirements with respect to dependability and performance have to be expressed. Finally a modeling methodology has to be defined in order to describe the usage and role of the requirement models.

In the frame of WP 1.1 the following results have been achieved:

• The requirements for PIM metamodel have been collected. Project partners proposed operational-, dependability-, and performance requirements.

• A metamodel has been created that can be used in the initial phases of system development to capture the requirements of DASs. The language of the metamodel is UML.

• The metamodel has been defined in UML but the role of UML is solely to define the elements of the metamodel and the connection among the elements of the metamodel. The metamodel itself is modeling language independent.

• The conformance of the PIM metamodel to the current mainstream modeling technology- and application domain specific standards has been checked.

• The main steps of the development workflow has been identified the role of PIM within the workflow has been clarified.

• The steps of PIM development have been defined.

• As a pilot experiment an example PIM has been created in conformance with the planned demonstion system of SP5.

• The pilot experiment indicated that the approach selected by the partners promises a seamless integration of the advanced DECOS concept with state of the art commercial tools corresponding to the industrial best practice.

The size of this document is intentionally kept at a level that allows for a quick overview of the WP 1.1 activities. Important implementation and analysis details can be found in an addendum document: "DECOS_1.1-019_0.1w_D113_addendum.doc".



2 Objectives and Scope

The objective of this document is to define a modeling methodology for DECOS and especially to describe the steps of PIM development. Additionally it also presents refinement of previous WP1.1 results. This is necessary one hand because of continous changes in standards (e.g. SysML) on the other hand because of the better understanding of modeling problems and a continous feedback from industrial partners (e.g. PIM metamodel).

Since the release of Deliverable 1.1.1 the PIM metamodel has been updated in order to increase its expressive power and to decrease its complexity. The changes from Version 1.0r to Version 2.0r are detailed in Chapter 3. The full description of Version 2.0r can be found in the addendum.

SysML is an evolving standards for the definition of large IT systems. In Chapter 3 a comparative study between the PIM metamodel and the SysML metamodel is given.

According to Milestone 1.1.1 the PIM can be created by a variety of tools. In order to provide compatibility of these tools with DECOS a datamodel is defined for the PIM. (See Chapter 3). It is defined in XML in order to provide an open interface towards the other DECOS tools, like the PSM development tool.

The DECOS developer is provided with a modeling methodology (also called modeling workflow). It describes the main steps of DECOS based development from requirement capturing to code deployment. The workflow is defined at a higher abstraction level. Detailed steps are described for the creation of the PIM that is the first phase of the workflow. The modeling workflow and the steps of PIM development are detailed in Chapter 4.

Since SCADE has an important role in the DECOS development the possible connection between PIM and SCADE is examined (Chapter 5) in detail.

In order to explain the PIM metamodel and the modeling methodology a system example is presented in Chapter 6. The example is from SP5 and it is the doors subsystem of a car. The intention is to elaborate the example as detailed as possible in order to present a useful input for the PIM-PSM mapping too.

Finally a short annotated description of the "DECOS_1.1-019_0.1w_D113_addendum.doc" document is found in the Appendix.

This document does not deal in detail with the PIM-PSM mapping (also called HW-SW Integration) and with the V&V workflow (also called DECOS Test Bench). The former is detailed in D1.3.1 while the latter is presented in full detail in D4.1.2. Here only short summaries of these sub-workflows are inserted for the sake of completeness.

The doors subsystem is elaborated only at the level of creating and checking of a PIM. PSM generation for the example will be given in the final D1.3.1 while V&V of the example will be presented in the final D4.1.2. It is still not decided whether job code for the example will be implemented. If yes, it will be part of SP5 deliverables.



3 PIM metamodel update

3.1 Changes of the PIM metamodel

The current version of the PIM metamodel is 2.0r. Chages from PIM 1.0r (presented in the released D1.1.1) to PIM 2.0r are listed below:

• Missing association names and rolenames added to every association for navigability in OCL.

• Documentation of ONA and Symptom were corrected in the model file.

• Message has been changed to abstract in the model (it was already described as abstract in the documentation but not int the model)

• Some association-end multiplicities has been corrected.

• AbstractUnit has been removed from the model. Since only Jobs can have Interfaces, they have no serious common features with Resources.

• An association called „corresponds” has been added to Message. Since messages appear on both the sender and receiver site, these two instances has to be matched. A solution like the one used at MessagePartIds could have been be used, but this is simpler and easier to use.

• Associations modified in the Performance and Dependability packages to qualified associations for better readability.

• Meta-class GatewayJob added to represent inter-DAS software gateways. The gateway is a specialization of the Job.

• Parent-child meta-association between Jobs added, to represent the refinement hierarchy of Jobs.

• Latency and executionTime attributes introduced for Resource performance to provide information about the physical timing constraints of the resources.

• PIMFunctionalElement meta-class added as a common parent for all of the functionality meta-classes.

• PerformanceConstraint meta-class added to support the definition of performance constraint expressions that refer to multiple model elements.

• JobDependability extended with a new attribute (SIL) to represent a job-level criticality level and override the DAS level setting. This enables the distinction between safety-relevant and non-safety-relevant Jobs in a single DAS.

• ResourceDependability meta-class introduced to support the definition of reliability requirements for resources.

3.2 PIM metamodel and SysML

The following comparison presented in this chapter is based on the 1.3w version of the PIM metamodel and on the 0.9 version of the SysML standard. The importance of SysML from the point of view of standard compliancy of the DECOS PIM metamodel is detailed in D 1.1.1.

3.2.1 SysML metamodel



The proposed SysML specification is defined as an extension of the UML 2.0 Superstructure Specification (see Hiba! A hivatkozási forrás nem található.), this way reuses the UML syntax and semantics roles.

<<metamodel>>MOF

<<metamodel>>UML

<<instanceOf>>

<<import>>

<<instanceOf>>

<<modelLibrary>>

SysML

<<userModel>>

XYZsystem<<reuse>>

<<instanceOf>>

<<metamodel>>SysML

Figure 1: SysML extension of UML

As shown on the Hiba! A hivatkozási forrás nem található. SysML reuses a subset of UML (<<IMPORT>> relationship) and creates extensions to support the specific requirements needed to model complex engineering systems. Several extension mechanisms are used including stereotypes, metaclasses and model libraries. The SysML stereotypes and metaclasses are instantiated in the <<USERMODEL>> while classes are grouped into subclasses in the <<MODELLIBRARY>>.

The SysML package structure is shown in more details on Hiba! A hivatkozási forrás nem található.. Among these packages there are some imported from the UML without any modification, like State Machines, Interactions and Use Cases.

New SysML packages are Requirements, Parametrics and Allocation. The Assemblies package uses structured classes from COMPOSITESTRUCTURES (UML2.0) and contains some minor extensions.

The following diagrams of the SysML metamodel describe the static, structural constructs of the engineering systems:

1. Class diagrams are interpreted and used in the same way as in UML 2.0, extended by some new notational elements.

2. Assembly diagrams

Assembly diagrams can be used to model either the logical or physical decomposition of a system, the specification of software, hardware, or human systems.

Assembly diagrams aim to model systems as trees of modular components, through describing the system as a collection of different specific parts and their relationships. For this purpose SysML defines a stereotype of UML::CLASSES called <<ASSEMBLY>>.



CommonBehaviors

Use Cases

Actions Activities

StateMachines

Auxillary

Constructs

Classes

Requirements

Assemblies

Interactions Parametrics

Allocation

Profiles

<<metamodel>>SysML

Figure 2: SysML package structure

An <<ASSEMBLY>> may own a part of a system defining in this way the system boundaries. Some of the parts of an <<ASSEMBLY>> may be shown as ports indicating that they can be connected externally.

An <<ASSEMBLY>> node does not typically include features of software structures, rather includes the required or provided interfaces on the class or any of its ports. Hiba! A hivatkozási forrás nem található. shows the graphical representation of an <<ASSEMBLY>>, which includes a part, a property or a port.

PROPERTY

UML::Property with

isComposite = False

propertyName:TypeName

PORT

UML::Port

portName:TypeName

<<assembly>>

ClassName

<<ASSEMBLY>>

SysML::Assemblies::Assembly

PART

UML::Property with

isComposite = True

partName:TypeName

Figure 3: Graphical nodes in Assembly diagrams

SysML introduces the stereotype <<NESTEDCONNECTOREND>>, which connectors may cross the boundaries of a class, and may be connected directly to a nested property or part.

3. Parametric diagrams

SysML defines parametric constraints, which help to integrate engineering analysis such as performance and reliability models with SysML assemblies. These constraints can be used for instance to describe critical performance parameters of a model element, and their relationships to other parameters in a system.

Parametric diagrams are special diagrams, which make possible the representation of parametric constraints with special graphical conventions. The usage of a parametric constraint is shown as a part within an <<ASSEMBLY>>, where it is bounded to other <<ASSEMBLY>> properties to describe the relation between them. This way parametric constraints are used as part of SysML assembly diagrams.



By using these parametric constraints a performance and reliability analysis can be integrated with a system model. The parametric models can define a set of system properties where a parametric relationship states how a change to the value of one property impacts the value of other properties. Time can be modeled for instance as an additional property that other properties can depend on. Parametric constraints can be dependent also on the state of the object they belong to. In this case the state of the object can be defined as its property.

Hiba! A hivatkozási forrás nem található. shows how a SysML <<PARAMCONSTRAINT>> stereotype declares that an assembly is defined for use as a parametric constraint. The Assembly’s ports define the parameters of the parametric constraint.

<<assembly>>AssemblyName

ParameterName:

TypeName<<paramConstraint>>

Name: TypeName

<<paramConstraint>>

Name: TypeName

ValueBindingConstraint

Figure 4: SysML Assembly with parametric Constraint

The UML Connector stereotype <<VALUEBINDINGCONSTRAINT>> declares that two connected properties are constrained to have equal values.

The following behavioral diagrams are used in SysML describing the system’s dynamic structures:

4. Activity diagrams

SysML does not extend the standard UML 2.0 activity diagrams with new graphical nodes or paths, but with stereotypes (see Hiba! A hivatkozási forrás nem található.):

• In UML Activities, control can only enable actions to start. SysML extends this with control disabling actions that are already executing.

• At the same time BEHAVIORs can declare that they cannot be disabled once started. SysML also distinguishes between BEHAVIORs that are intended to run until they are disabled, and those that run to completion.

• BEHAVIORs that have parameters typed by control become in SysML CONTROLOPERATORs. CONTROLOPERATOR can represent a complex logical operator that transforms its inputs to produce an output that controls other actions.

• OBJECTNODES in activity diagram (including pins) can buffer or overwrite their values by a newly arriving value (<<OVERWRITE>>), or simple discard values if they do not immediately flow downstream (<<NOBUFFER>>).

• <<OPTIONAL>> stereotype can be applied to parameters, in this case the lower multiplicity must be equal to zero.

• Entity flows in an activity diagram may have a restriction on the <<RATE>> on which entities flow along edges. SysML defines both discrete and continuous flows (Hiba! A hivatkozási forrás nem található.). Rate can be applied also to parameters where the parameter must be streaming, and the stereotype gives the rate over time that objects or values are expected to flow in or out of the parameter.



<<metaclass>>

UML:Parameter

<<metaclass>>

UML:ActivityEdge

<<metaclass>>

UML:ParameterSet

<<stereotype>>

Optional

<<stereotype>>

Rate

rate: Quantity

<<stereotype>>

Continuous

<<stereotype>>

Discrete

<<metaclass>>

UML:Behavior

<<metaclass>>

UML:Operation

<<stereotype>>

ControlOperator

<<metaclass>>

UML:ObjectNode

<<stereotype>>

NoBuffer

<<stereotype>>

Overwrite

<<metaclass>>

UML:Constraint

<<stereotype>>

ResourceConstraint

resourceClass:UML: Class

Probability: UML: ValueSpecification

<<stereotype>>

Probability

Figure 5: Metamodel Extensions

• Edges coming from the same decision or object node can be extended with expressions of constant probabilities (see Hiba! A hivatkozási forrás nem található.).

• Output parameter sets may have similar probabilities, which define whether the parameter set will be given values at runtime.

• <<RESOURCECONSTRAINT>> can specify the types of resources used by the model element it constrains.

DistributionDefinition(from Distributions)

RateDistribution

DiscreteRateDistribution

ContinuousRateDistribution

ParameterActivityEdge

0..1

0..1+rate

0..1

0..1+rate

Figure 6: Metamodel for Rate Distribution

ActivityEdge UML: ValueSpecification(from UML)

+probability

0..10..1

UML: ActivityNode(from UML)

+probabilitySource

0..1

0..*

ParameterSet UML: ValueSpecification(from UML)

+outputProbability

0..1 0..1

Figure 7: Probability

5. Interaction diagrams



SysML interaction diagrams include the UML

• sequence diagram

• timing diagram

which are unchanged from UML 2.0.

6. State Machine diagrams

SysML includes the Behavioral state machines specifying the behavior of various model elements. Protocol state machines that describe the lifecycle of an object expressing the protocols the object is using, is not part of SysML.

The concrete syntax for state machines is unchanged from UML 2.0.

Use Case diagrams used in SysML have the same role and syntax as in UML 2.0.

SysML generic diagrams include

7. Allocation

In SysML the term Allocation is used to describe the organized cross-association of elements within a user model, to assess the way how a developing user model “hangs together”. Allocation is a mechanism for associating elements of different types, or in different hierarchies, at an abstract level.

An <<ALLOCATION>> is a SysML stereotype of the UML::DEPENDENCIES::USAGE dependency, an <<ALLOCATED>> element is derived from the UML::KERNEL::NAMEDELEMENT.

Some graphical nodes which may be included in allocation diagram can be seen on Hiba! A hivatkozási forrás nem található..

ActivityName

<<allocated>>{allocatedTo=ElementName}

<<allocated>>

{allocatedFrom=ElementName}{allocatedTo=ElementName}

ClassNameNamed

Element

NamedElement

NamedElement

<<allocation>>

Allocation derived properties

displayed in compartment of

Class.

Allocation derived properties

displayed in compartment of Action

in Activity Diagram.

Allocation (one to many)

Figure 8: Graphical nodes in allocation diagram

The aim of <<ALLOCATION>> in SysML is to relate model elements in a very general, flexible way. The various association types may be expressed in SysML models, like

• Requirement Allocation, which defines the allocation of requirements to a system design, deployment or any other aspect of the system.

• Flow Allocation maps flows in functional system models to flows in structural system representations.

• Structural Allocation supports the mapping between the separate “logical” and “physical” representations of a system.

• Deployment Allocation is an association between a conceptual, abstract software assembly and an abstract hardware assembly.

• Property Allocation includes the allocation of system performance to various elements in the system model.

8. Requirements models



SysML <<REQUIREMENT>> describes the structure, property, capability that a system or a component must satisfy, or a function wich must be performed. SysML <<REQUIREMENT>> is a stereotype of the UML::CLASS (see Hiba! A hivatkozási forrás nem található.).

<<stereotype>>

UML::Trace

<<stereotype>>

Derive

<<stereotype>>

Satisfy

<<stereotype>>

Verify

<<metaclass>>

UML::Comment

<<stereotype>>

Rationale

<<metaclass>>

Operation

<<metaclass>>

Behavior

<<stereotype>>

TestCase

<<metaclass>>

Class

<<stereotype>>

Requirement

Figure 9: Abstract syntax for Requirement metamodel

Requirements in SysML diagrams can be grouped into packages, connected to each other, generated or deduced from another requirement (<<DERIVE>>). Compound requirements are allowed by using the nesting capability.

SysML defines various requirement relationships, like << SATISFY>> representing that a requirement can be fulfilled by another model element, <<VERIFY>> which links a requirement to verification procedure called <<TESTCASE>>, etc. An example for the <<TESTCASE>> can be a performance test related to a given requirement.

*

*

+target{redefines

Client}

*

*

*

*

+target{redefines

Client}*

*

+source{redefines

Supplier}

*

* *

*+source

{redefines

Supplier}

+source

{redefines

Supplier}

0..1*

+subRequirement

<<metaclass>>UML::Dependency

<<stereotype>>

RequirementVerification

Verdict verdict

<<stereotype>>

TestCase

<<metaclass>>UML::NamedElement

passfail

inconclusiveerror

<<enumeration>>

Verdict

<<stereotype>>UML::Trace

<<metaclass>>UML::PackageableElement

String text

String id

String criticality

<<stereotype>>Requirement

<<metaclass>>

UML::Dependency

<<stereotype>>RequirementSatisfaction

<<metaclass>>

UML::NamedElement

<<stereotype>>SysML::ReferenceData

<<stereotype>>Rationale

Figure 10: SysML requirements model

9. Auxiliary Constructs

• SysML introduces the definition of <<VIEW>> which is a stereotype of UML::MODEL, and represents a model from a particular viewpoint.



• In SysML input and output items represent things that flow between parts in the context of an enclosing <<ASSEMBLY>>. Items may have properties and determine the type of the <<ITEMFLOW>>. SysML enables the properties of items to be used also in parametric relationships.

• SysML extends the UML data types by real and complex numeric types.

• SysML model library declares classes that a user model may use to express quantities and distributions (see Hiba! A hivatkozási forrás nem található.). <<QUANTITY>> is a data type that specifies a value with a <<DIMENSION>> and a <<UNIT>> of measure. A quantity may have an associated <<DISTRIBUTION>>.

+value:Real

<<dataType>>

Quantity

+symbol: String

Dimension

+symbol: String

Unit

<<primitive>>

DistributedQuantity<<distributionDefinition>>

Distribution

+dimension

0..1 0..1

0..1

0..1

+dimension

+unit

0..1

0..1

+distribution

1

<<modelLibrary>>

Quantities

Figure 11: Model Library Quantities

The following Table summarizes the aforesaid novel aspects of SysML and their references to our PIM metamodel.



SysML diagrams PIM diagrams Name Description Comment

Structure Diagram

Class diagram UML 2.0 UML 2.0

Assembly diagram It models either the logical or physical decomposition of a system. Component diagram

Parametric diagram Parametric models are analysis models that define a set of system properties, typically used in combination with assembly diagrams.

Requirement diagram Isn't defined in PIM as standalone diagram, requirement information is embedded in model elements.

Behavior Diagram

Activity diagram UML 2.0

Interaction Overview D.

The SysML interaction diagrams include the sequence diagram, interaction overview diagram, and timing diagram, and are unchanged from UML 2.0 except for some minor notational enhancements to timing diagrams.

UML 2.0

Sequence diagram UML 2.0

Timing diagram UML 2.0

State Machine diagram

UML 2.0 State Machine Diagram

Use Case diagram UML 2.0 Use Case Diagram

SysML metamodel PIM metamodel

Name Reference Description Comment

Assemblies Assembly UML::Class An Assembly is a class that describes a structure of interconnected parts.

DAS

Port UML::Port Assemblies define a component in terms of structural features belonging to a class, including its internal parts, and ports that can be used to to connect it externally.

Interface, Port

Part UML::Property (isComposite=True) Job

Property UML::Property (isComposite=False)

An Assembly may have a property. OperatingMode

Parametrics ParamConstraint SysML::Assembly Parametric constraint is an Assembly used only to constrain the values of properties within a containing assembly.Their can be used to identify critical performance parameters and their relationships to other parameters, which

Several predefined properties of the PIM elements



can be tracked throughout the system lifecycle.

Activities UML::Activity Activities can be distinguished like 1. RunToDisable 2. RunToCompletion 3. Disableable 4. ControlOperator

Desciption of behaviour is intentionally left open.

Control UML::Pin Control can both enable and disable actions that are already under execution.

Control may have a type so that it can be processed by actions.

ControlOperator UML::Behavior, UML::Operation

ControlOperators can represent a complex logical operator that transforms its inputs to produce an output that controls other actions.

UML::ObjectNode SysML extends object nodes with the parameter isBuffer/isOverwrite.

Rate UML::ActivityEdge Entity flows may have a restriction on the rate on which entities flow along edges.

Probability UML::ParameterSet

Edges coming out of decision nodes and object nodes can be assigned to expressions with constant probabilities.

ResourceConstraint UML::Constraint The constraint can specify the types of resources used by the model element.

Allocations PropertyAllocation UML::Dependencies::Usage

Allocation of system performance to various elements in the system model.

Resource allocation is done by the transformation. Only requirements are reflected in the PIM.

FlowAllocation Maps flows in functional system models to flows in structural system representations.

RequirementAllocation Allocation of requirements to a system design, or any other aspect of a system.

StructuralAllocation Mapping between the separate “logical” and “physical” representations of a system.

DeploymentAllocation Association between an abstract software and hardware assembly.

Requirements Test Case UML::Behavior, UML::Operation

TestCase represents a procedure used to verify a requirement. A TestCase has an attribute, verdict, to qualify the outcome of the verification.

Description of test cases and requirements can be described in the documentation or an external XML file referenced in the documentation field.

RequirementVerification

UML::Dependency

A relationship between a Requirement and a TestCase used to verify this Requirement.

Table 1: Comparison of SysML metamodel and DECOS PIM metamodel



3.2.2 Comparison of SysML and PIM metamodel

The approach of SysML and the DECOS PIM metamodel is somewhat different. SysML targets the definition of a general-purpose modeling language, while the PIM metamodel is targeted for the description of distributed, dependable, embedded systems.

The designers of SysML do not intend to be more specific than this as can be seen in the SysML proposal:

“This specification defines a general-purpose modeling language for systems engineering applications, called the Systems Modeling Language (SysML). SysML supports the specification, analysis, design, verification and validation of a broad range of complex systems. These systems may include hardware, software, data, personnel, procedures, and facilities.”

However, they leave the specification open for specialization to specific application domains. Because of this generality, there are lots of open points in the specification.

SysML is defined as an extension to the UML 2.0 standard, as opposed to our metamodel, which is defined as a general metamodel, that can be mapped to any extensible modeling formalism. The PIM Profile as provided in this document is just one example of mapping the metamodel to an existing modeling language.

Diagrams

Most of the UML 2.0 diagrams are used in the same way as used in SysML. The Assembly diagram of SysML is a specialized version of Component diagram, so since we are using Component diagrams for the same purpose, the difference is minor. As you will see later, we don’t use a Requirement diagram explicitly, rather offer a possibility to embed this kind of information into the model.

Elements

SysML describes the structure of the system using Assemblies, Parts and Ports. Assembly is the specialization of Class, and contains Parts. The Parts and Assemblies are connected through Ports. Parts can contain more Parts, and using this recursive embedding feature, multi-level hierarchies can be described in the system.

In the PIM, the structure of the system is described using DASs and Jobs, and on the other hand, with Nodes and Resources. Jobs are defined as the basic unit of distribution, thus a two level hierarchy can be described. This is in accordance with the DECOS Technology Paper.

SysML describes the connections using Ports. We have a two-level hierarchy for this, namely Interfaces and Ports, which allows the partitioning of Ports into logical groups depending on their usage.

SysML provides a mechanism for constraining the properties of an Assembly. However, it does not define what these properties are, since these will application or domain specific. Our approach is different, since one of our main tasks is identifying the properties that are needed to describe the properties of the system that will be used by the transformation.

SysML uses and slightly specializes the Action semantics and Activity diagrams of standard UML 2.0 for describing the behavior of the system. Since we do not restrict the usage of the PIM metamodel to UML, the description of behavior is not defined in it. The current PIM metamodel leaves the description paradigm of the semantics intentionally open, but provides a proper slot (documentation) for the elements. The metamodel compliant implementations of the modeling concept, like the UML profile proposed, can reuse the original semantics of the modeling paradigm extended by the DECOS concepts. If needed a general semantics description language like ASM can be used to provide a uniform semantics definition language



out of which the input description of a particular implementation paradigm can be transformed in an automated way.

SysML provides a way to map requirements to system elements, functional elements to system structural elements and software to hardware. In the case of PIM, these mappings are either explicitly contained in the model (e.g. Performance requirements are attached to the respective model elements), or the mapping will be done automatically by the transformation.

SysML provides Requirement Verification and Test Case elements to embed documentation of requirements and test cases into the model. Since that was not requested, the PIM does not support this explicitly. However, the documentation field can be used for this purpose, moreover, the documentation can reference an XML document, that can contain arbitrary requirement specifications and the test cases that should be used to check them.

Summary

There are many common features of SysML and the PIM metamodel. After comparing them, we can conclude that the PIM metamodel could be defined as a specialization of the SysML metamodel. The PIM would then gain some improvements that were not explicitly requested by our partners, but of course these could be useful. The main part of the work would be to define the parametrics that are explicitly needed in our domain. SysML defines only Ports instead of Interfaces and Ports, because of this, the two level structuring the PIM provides may be lost.

Since the SysML specification is version 0.9, it is still not complete and has some open issues. However, when it will be finalized, a PIM that is the specialization of the SysML metamodel can possibly be developed.

3.3 Data model of the PIM

The data model of the PIM is defined using the PIM metamodel. We provide an XML Schema description for the data format. PIM modelling tools may use other data formats, but tool providers have to provide support for mapping to the standard PIM data format.

For modelling, we suggest the usage of the Sparx Systems Enterprise Architect [2]. This tool offers UML2 (Unified Modelling Language 2) modelling capabilities. The DECOS PIM Profile (introduced earlier in this document) can be imported to the modelling tool and can be used for creating models that use the profile elements. This modelling tool (as many other commercially available UML modelling tools) offers a standard XMI (XML Metadata Interchange) export functionality.

The Extensible Markup Language (XML) is a W3C recommendation - www.w3c.org/xml. XML is a subset / application profile of Standard Generalized Markup Language (SGML) [ISO 8879]. Its goal is to enable generic SGML to be served, received, and processed on the Web. XML has been designed for ease of implementation and for interoperability with both SGML and HTML. XML describes a class of data objects called XML documents and partially describes the behavior of computer programs which process them. By design, XML documents are conforming SGML documents.

The XML Metadata Interchange (XMI) is a standard of the Object Management Group (OMG) [3]. XMI is a widely used interchange format for sharing data object using XML. Sharing objects in XML is a comprehensive solution that builds on sharing data with XML. XMI is applicable to a wide variety of data objects: analysis, software, components, and databases.

XMI defines many of the important aspects involved in describing data objects in XML:

• The representation of data objects in terms of XML elements and attributes is the foundation.



• Since objects are typically interconnected, XMI includes standard mechanisms to link data objects within the same file or across files.

• Object identity allows data objects to be referenced from other data objects in terms of IDs and UUIDs.

• The versioning of data objects and their definitions is handled by the XMI model.

• Validation of XMI documents using DTDs and Schemas.

XMI is a model driven XML integration framework for defining, interchanging, manipulating and integrating XML data and objects. XMI-based standards are in use for integrating tools, repositories, applications and data warehouses. The XMI standard provides rules by which a schema can be generated for any valid XMI-transmissible MOF-based metamodel.

As described before, the concrete syntax of the XMI file depends only on the metamodel of the modelling language. This means that two tools that support the XMI standard use the same modelling language (with the same metamodel) they produce the same output for a model. This standardization eases the integration of tools and the interoperability between modelling tools of various vendors.

However, the XMI standard is definite, there may be several tool-dependent modifications to the concrete syntax. This means that the output format of tools may differ if they modify the original metamodel, or the XMI mapping. These differences are minor in most cases, and they do not cause difficulties in the tool integration.

The actual data model of the DECOS PIM is defined using the UML metamodel and the XMI standard. The actual output format is described by the XML Schema provided by BUTE. We introduce a sample XMI document that illustrates the structure of the output. The XMI documents are human-readable, but it must be noted that their primary usage is the tool-to-tool information forwarding.

<?xml version="1.0" encoding="UTF-8"?>

<tns:XMI xmlns:tns="http://www.decos.eu/PIM"

xmlns:xlink="http://www.w3.org/XLink" xmlns:xcml="http://www.w3.org/XML"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.decos.eu/PIM

C:\decos\DECOS_PIM_2.0r_PIM-XMI.xsd" xmi.version="1.1">

<XMI.header>

<XMI.metamodel xmi.name="DECOS PIM metamodel"/>

</XMI.header>

<XMI.content>

<Model>

<DAS name="sampleDAS">

<DAS.ownedJob>

<TimeTriggeredJob name="SensorJob"

externalDescriptor="http://www.acme.org/description.html">

<Job.dependability operating_mode="OP1">

<JobDependability failureMode="fail_operational"/>

</Job.dependability>

<Job.ownedInterface>

<SPLIF>

<Interface.ownedPort>

<StateMessagePort name="sensorValueOutputPort" direction="out"

outgoingBuffer="0" incomingBuffer="0">

<Port.visibleStateVariable>

<StateVariable xmi.idref="var1"/>



</Port.visibleStateVariable>

</StateMessagePort>

</Interface.ownedPort>

</SPLIF>

</Job.ownedInterface>

<Job.ownedStateVariable>

<StateVariable averagable="false" fixedLength="true"

initialValue="0" type="double" length="8"

name="sensorValue" description="Actual sensor value"/>

</Job.ownedStateVariable>

</TimeTriggeredJob>

</DAS.ownedJob>

<DAS.initialOperatingMode>

<OperatingMode xmi.id="OP1" name="normalOpMode"/>

</DAS.initialOperatingMode>

</DAS>

</Model>

</XMI.content>

</tns:XMI>

The sample describes a DAS containing a job a sensor and an interface. The DAS has a single operation mode called normalOpMode. The job (called SensorJob) is a time triggered job, and has a declared dependability requirement. The job has a single service provider linking interface (SPLIF) that contains a state variable (sensorValue). The other constructs can also be easily identified in the example.

The XMI notation offers a standard notation for PIM (and other) models, and is portable between tools. Even if it has been designed for inter-tool data exchange, it is also well-readable for humans. Custom tools that has to be used in the DECíOS project can be easily extended to parse this type of notation, because all modern programming languages offer XML processing libraries that can read the XML/XMI documents. This enables the integration of various PIM tools in an integrated toolchain that uses a standard, widely supported data format.



4 Design methodology

4.1 General workflow

The design methodology of DECOS starts with requirement collection and finishes with the preparation of the final executable code. The general workflow is depicted in Figure 12. The workflow is splitted into three parallel but interdependent, cooperating sub-workflows. This is denoted in the figure by the three vertical swimlanes. The three sub-workflows are:

• architecture design

• software development

• validation and verification

platform spec.

information

behavioural

modeling

HW-SW

integration

req.

capture

HW-SW integration

PIM

creation

implementation

deploymentPSM

DECOS comp

code library

executables

SW development

job model

SCADE/Matlab

PIM

requirements

additional

requirements

job code

library

requirement

definition

V-plancreation

V&V activity

definition

test bench

V&V activity

exection

Figure 12: Modeling methodology workflow

4.2 Targeting DECOS architecture

In order to achieve a technology-invariant system design of the final application, the DECOS architecture design starts with a PIM of each DAS and the basic technology platform and its services are hidden by the Platform Interface (PI). The subsystems (DASs) functionality, performance and dependability requirements are represented by a PIM. A key objective of the DECOS architecture system design is the technology invariant mapping of the desired system functionality onto a targeted set of physical resources and it is the



DEOCS PIM�PSM mapping process. The mapping process is defined as the mapping of different characteristics requirements (such as dependability/criticality, performance etc) of DASs on common hardware resources. The process is done in WP1.3 i.e., by means of SW-HW integration process. As mentioned above that the process starts with the PIM (more specifically marked PIM) and after performing a SW-HW integration (allocation, scheduling) the PSM is obtained. According to the OMG Model Driven Architecture (MDA), the PSM is the abstraction level where application design meets implementation concepts and languages [4]. This design process is analogous to the kind of model-based design which starts with the application software and is modeled abstractly without considering the platform details and then transforms the model to another model related to the target platform. In Figure 13, the PIM is described as the first model and the PSM is described as the second model. The constraints model represents the platform resource constraints and additional constraints. Constraints have to be satisfied while transformation is performed from PIM to PSM. The model transformations allow designer to perform semi-automatic transformation of PIM to PSM. The details of the process are given in the D 1.3.1 and a short description is given below.

Domain Specific Application Model

(e.g., expressed in UML)

Platform Independent Model (PIM)

(PIM language based on UML)

Platform Specific Model (PSM)

Transformation

HW Platform

Constraints model

Figure 13: Model Transformation (PIM to PSM)

As explained above, the aim of HW-SW integration is to provide the PSM that controls the deployment task during software development.

For the HW-SW integration workflow the following steps are suggested (see Figure 14). The first step is to check the feasibility of the input modells. In this step the constraint list of the (marked) PIM and the additional constraints are matched with the feature list of the HW resource model. The inputs of this step are the (marked) PIM, the HW resource model, the constraint list, the PI description and the PI API description. Onthologies can help in the checking the feasibility of the input.

If the problem is feasible, the next step is the interactive allocation in which the elements of software are mapped to the hardware resources and virtual communication links are mapped to physical communication links taking a multitude of constraints into consideration. The software elements are jobs (described in the PIM) of the DAS, the modules of the architectural services layer (described by the PI) and the modules of the application services middleware (described by the PI API). The hardware elements are the components, the partitions, and physical networks.

In the allocation step in the simplest case only the type of resources are considered but not the amount of resources. It means for example that replicas of jobs are mapped to different nodes, or jobs needing a special device are mapped to the partition that contains this device, but no care is taken to sum up the memory requirements of software elements mapped to a given component and math it up with the available memory of the component. This is in order to support simplicity for doing the job by hand in the first phase of the project.



wrapper code

information

arch. services

code inf.

MW code

information

UML to

SCADE

Simulink

Gateway

feasibility

test

interactive

allocation

allocation test

HW-SW integration

scheduling

scheduling

test

SCADE CGwrapper code

generation

completeness

testdeployment

PSMPSM

candidate

system map &

res. usagewrapper code

MW code

library

arch. services

code library

executables

PIMsimulink

models

global

constraint

satisfaction

controller

fail

new schedulingneeded

fail

newallocationneeded

SW development

resource

usage

calculation

SCADE

model

PIM

(marked) HW resource

model PI API

description

constraints

job code

information

PI description

wrapper code

information

arch. services

code inf.

MW code

information

job code

information

fail

job code

library

SCADE

model

Figure 14: PIM-PSM transformation workflow

Since allocation does not deal with the amount of resources, it is possible that an infeasible map is created. In order to check this the resource usage has to be computed at first. This is based on the map created during allocation, the amount of resources described in the HW resource model and the size information of the software elements.

When the allocation test fails a new allocation has to be found. If the test does not fail a valid system map and its resource usage is available. Of course it is possible that there are more than one valid maps. If allocation is done automatically the sequence of found valid maps depends on the local and global search algorithms. (The local search algorithm is handled in the allocation step, the global search algorithm is handled at the global constraint satisfaction controller.

After finding a feasible map the next step of HW-SW integration is scheduling. In this step a partition- and message schedule has to be found. For scheduling it its important to know the timing information of software elements and the SCADE modell if such exists as well. The result of scheduling is a PSM candidate, since it is possible that the found scheduling not feasible. If the found schedule is not feasible then either we have to find a new schedule that is feasible, i.e. a new scheduling step is necessary or since no feasible schedule exists for the found map, we have to find a new map, i.e. a new allocation step is necessary. The iteration cycles are controlled by the global constraint satisfaction controller.

4.3 Software development

For the software development workflow the following steps are suggested (see Figure 14). The PIM that describes the requirements for DASes is formulated by the developer in the first step. It can be a UML model that describes functional, dependability and performance requirements. The PIM does not describe however the behaviour of the jobs of the DASes. Behaviour of jobs is described in SCADE (for the safety-critical subsystem) or in SCADE / Simulink (for the non-safety critical subsystem all of our industrial partners in DECOS expressed a preference for Simulink).



By using the PIM-to-SCADE profile SCADE is able to import UML models. This way the PIM (structure of the software) can be imported into SCADE. Using the Simulink gateway of SCADE the behavioural description of the jobs can be imported into SCADE. The developer can do further modeling in SCADE and finally job code can be generated by the certified SCADE CG code generator. Job code is the platform independent ANSI C code of a job. It is cyclically executed has a single C structure as inputs and a different one for outputs.

Additionally to job code generation a wrapper code has to be generated. To each job a wrapper is assigned that is responsible to transform the output data structure of the job code to PI API calls and to transform the PI API return messages and call results to the input data structure of the job code. In order to generate the job code the marked PIM, the SCADE model and the map of jobs to partitions is necessary. The marked PIM is used to extract information about the message interfaces of the jobs and the application level services the job uses. The mapping information is necessary in order to know whether job-to-job communication calls of the PI API should be mapped to interpartition, inter application computer, or intercomponent communication.

Application level services are provided by the middleware, that is divided into moduls in order to load only the code of used services into the partition.

Architecture level services are provided by the connector units. The code is assembled modularly according to the actual mapping of jobs to components in order to minimize the footprint of connector unit code.

Finally job code, wrapper code, middleware code modules and architectural services code modules should be assembled into executable code during deployment. This final step is guided by the information contained in the PSM.

4.4 V&V test bench

Due to the safety-critical nature of applications that will be realised using DECOS technology, verification and certification support is an integral part of the DECOS software development process. In the scope of the DECOS project, a Test Bench that aims to assure the certifiability of DECOS components and systems will be developed. The Test Bench will guide the developer through the verification and validation process, and it will make sure that the verification process adheres to the relevant safety standards (e.g., ISO/IEC 61508). Based on the domain (e.g. automotive, aerospace) and the corresponding relevant standards as well as the application specific requirements, the Test Bench helps to identify the relevant V&V activities. It provides a verification-plan (v-plan) that is based on the requirements and relates these requirements to corresponding verification methods and tools.

Since verification should not be postponed to the later phases of a project, the Test Bench targets almost all phases of the development lifecycle. For example, a safety analysis (e.g., FMECA, HAZOP) is a verification activity that is usually done in the earlier project phases, model based verification is typically carried out during the prototyping phase, and EMI/EMC activities can be performed once a hardware implementation of the system is available. The Test Bench maintains a repository of such V&V methods and tools. These tools are integrated into the Test Bench (where the degree of coupling depends on the specific tool), meaning that there will be a well-defined interface between the Test Bench and the tools. This interface will enable the Test Bench to automatically provide input and process output of a certain class of highly integrated tools. For less tightly integrated tools, these steps will have to be performed manually.

The Test Bench provides adaptive v-plans for various categories of DECOS artefacts. Apart from products based on the DECOS architecture (e.g., applications running on DECOS nodes, or implementations of the DECOS Architecture Model) the Test Bench will also support the validation of development tools which are deployed in the DECOS software development process. Since software tools cannot be certified, the Test Bench will aim to assure their qualifiability (if appropriate). A detailed description of artefact categories covered by the Test Bench can be found in [D4.1.2].

Furthermore, the Test Bench will provide a repository of safety arguments for DECOS artefacts. Whenever a v-plan has been carried out successfully, the corresponding safety arguments (i.e., the evidence for the success of the separate verification steps) are collected in a document denoted as Safety Case. A Safety Case is a collection of demonstrable and valid arguments that provide evidence that a system is adequately



safe for a given application and environment over its lifetime. A central claim of the DECOS Test Bench is that such Safety Cases can be (re-)used in a modular way. Artefacts that have already been verified using the Test Bench don’t need to undergo the complete verification process if they are deployed in a larger context consisting of several DECOS components. This claim is essential for implementations of the DECOS Architecture Model: Once the DECOS hardware is certified to the highest level of criticality (i.e., SIL4) it can be deployed in safety critical applications without need for complete re-verification. Of course, for the DECOS development and configuration tool chain, similar benefits would result.

4.5 Creating the PIM

Creating the PIM is a manual process that starts after requirement collection. The content of the PIM is constrained by the PIM metamodel. The creation process of the PIM is defined in

DAS definition

Diagnostics

definition

Variable

definition

Communication

definition

PIM

requirements

Job definitionResource

definition

Message

definition

Interfaces, ports

definition

Performance

definition

Dependability

definition

Figure 15.



DAS definition

Diagnostics

definition

Variable

definition

Communication

definition

PIM

requirements

Job definitionResource

definition

Message

definition

Interfaces, ports

definition

Performance

definition

Dependability

definition

Figure 15: Step of PIM creation

The steps of PIM creation are:

• Definition of the DAS and the operating modes of the DAS.

• Definition of the set of jobs by hierarchical refinement (function breakdown). When the necessary detail is reached, jobs are assigned to the DAS and set of jobs running in each operating mode is defined.

• Definition of the resources and allocating them to jobs using <<needs>> associations.

• Definition of the messages of the DAS.

• Definition of the interfaces of the jobs and creating the ports and connecting them to the interfaces.

• Definition of the communication by connecting communicating ports and assigning the messages to the ports.

• Definition of the variables of the jobs, assigning messages to variables. Definition of out-of-norm assertions, symptoms, and defined states.

• Definition of diagnostics.

• Definition of the performance constraints.

• Definition of the diagnostic requirements.

A detailed presentation of these steps can be found in Chapter 6, where the development of the PIM example can be found.



5 Interfacing DECOS PIM to SCADE

SCADE Suite is an environment for the development of safety critical software. It supports a model-based development paradigm, where the model is the software specification. Documentation is automatically generated from the model: it is correct and up to date by construction.

The model can be exercised by simulation, using the same code as the embedded code. Formal proof techniques can also be applied to the model to detect corner bugs or prove safety properties. Code is automatically generated from the model with the Qualifiable Code Generator so the code is correct and up to date by construction.

Today, SCADE Suite™ is the de-facto standard for the creation of safety-critical embedded software in the European avionics industry and is the emerging standard for the creation of critical-embedded software in the automotive industry.

As SCADE could be a possible simulation, validation, and implementation environment for applications, the interfacing between DECOS PIM and SCADE models is a very important issue. To inspect the possible methods of interfacing, the two modelling techniques have to be compared. The base of this comparison is the two UML profiles (DECOS PIM UML and SCADE UML) as the designer mostly use these modelling environments for creating system models.

SCADE uses block diagrams and Safe State Machines to describe the behaviour of systems. The UML for SCADE profile developed for the P2I project describes a mapping between UML and SCADE. Similarly, a mapping between DECOS PIM and SCADE can be defined.

SCADE block diagrams consist of nodes representing control blocks and connections representing control or data flow. Nodes have inputs and outputs. Similarly, DECOS PIM contains components that have ports (inputs and outputs) and links between ports. Messages can be passed between ports. There is a natural way to map DECOS components to SCADE nodes, ports to inputs or outputs, and port links to connections. Messages can be mapped to data types.

Safe State Machines and Lustre expressions describe the internal behaviour of SCADE nodes. In DECOS PIM, if necessary, the behaviour can be modelled with UML State Machines.

To help the comparison of the two UML Profiles, the next Table summarizes the mapping of the constructs of the two modelling profile.

DECOS PIM UML SCADE UML

Actuator

Sensor

Node

Job

SynchronousClass

SCADE does not distinguish subtypes of software/hardware components. All types are modelled with the SynchronousClass stereotype.

Message

DECOS PIM maps state variables with messages, and messages with ports. These mappings define an implicit interface type definition.

DataType

SCADE defines explicit data types for interfaces.

Interface

Interfaces are connection points between components, containing one or more ports.

Port

A port is a connection point between components. It consists of one or more interfaces.

Port

A Port is an access point where a job reads an input message or writes an output message. This mapping

Interface

SCADE interfaces define data types and operations that are provided or required by a port of a component.



defines the type of the port, i.e. the data (message) type it sends or receives. Port operations cannot be described in DECOS PIM.

Assertion

Assertions can be defined to create various constraints on variable values, or system state.

SCADE has supports for assertions. It is envisioned to map OCL expression representing (functional) assertions into SCADE assertions.

Operating mode

Operating mode describes a possible system state. The state machine constructed using the operating modes and their relations defines the possible mode changes in the system. DECOS PIM does not limit the state machine constructs to safe state machines.

Safe State Machine state

State machines are used to define the internal behaviour of system components. This technique can also be used for the definition of operation mode changes.

State

States represent an internal state of a component, depending on the value of the associated state variables. The possible state transitions can be defined using state machines.

Safe State Machine state

State machines are used to define the internal behaviour of system components.

State Variable Attribute

UML Attributes can be mapped to SCADE local variables, whose value can be memorized using the SCADE “pre” operator.

As could be seen, there are only minor differences between the two modelling techniques. This allows the implementation of a transformation from DECOS PIM to SCADE UML. The latter Profile is under development; therefore minor changes are possible, but the fundamental concepts are nearly identical. The following table describes the UML concepts that can be used in both profiles. These items are not Profile specific, but they are specified in the UML 2 standard.

UML Concept DECOS PIM UML SCADE UML

Use case diagrams Use case diagrams can be used to define the relations of the environment and the system.

Class diagrams Class diagrams can define data structures, internal static structure of components and other static constructs.

Activity diagrams Activity diagrams can help to understand the flow of data and control between components. Although these diagrams are not used by PIM to PSM transformations, they increase the “readability” of the UML model.

Interaction diagrams As acitivity diagrams, interaction diagrams can also help to illustrate the dynamic behaviour of the system.

Package diagrams Package diagrams are used for the logical grouping of model elements. The various parts of the model can be organized into packages (logical containers) this way.

The mapping introduced here allows the transformation of DECOS PIMs to SCADE models. This enables the further integration of the two techniques to provide an automatic transformation from DECOS PIM to a high level SCADE model.



6 Design example

In order to show the modeling methodology an example is used. It is the Doors subsystem presented in detail in D5.1.1 and in the addendum to D5.1.1. The size of the example allows even manual model handling if necessary. It is realistic in order to fit into the tipical application environments of DECOS and it is realistic in order to be accepted by the industry. The example is presented here for convenience in a somewhat resctructured way. Afterwards the PIM of the example is given and the steps of PIM creation are described.

Certainly the example can not cover the full application area aimed at within DECOS. It is not representative for the safety-critical issues of DECOS since it is meant to be a non-safety-critical subsystem. Despite of it, some safety related sub-functionality can be found in the example.

6.1 Description of the doors subsystem

The main functionalities of the doors subsystem are:

• locking, unlocking and dead-locking the doors

• manual/automatic rising and lowering the windows with anti-pitch functionality

• normal/automatic moving of the external mirrors

The doors subsystem consists of the following modules:

• switch panel module (1 unit in the driver's door)

• window lifter module (4 units, 1 in each door)

• mirror module (2 units, 1 in each front door)

• door lock module (4 units, 1 in each door)

• lock management module

The doors subsystem has the following external connections:

• external mirror reference position

• vehicle speed

• key management

• general unlock

6.1.1 Description of the modules

Each module consists of local sensors, actuators, and controller with logic for the local functionality. An exception for that is the lock management module that contains logic for coordinating multiple other modules.

6.1.1.1 Switch panel modul

The swith panel module detects the depressing or release of the switches and sends the corresponding commands to the:



• window lifter module,

• mirror module.

The switch panel module is connected to the:

• window lifter modules (LF_WL, RF_WL, LR_WL, RR_WL),

• mirror modules (LF_MI, RF_MI),

• lock management module.

The switch panel consists of the following sensors (switches):

• WLMovLFDownCMD

• WLMovLFUpCMD

• WLMovRFDownCMD

• WLMovRFUpCMD

• WLMovLRDownCMD

• WLMovLRUpCMD

• WLMovRRDownCMD

• WLMovRRUpCMD

• InhibitRearLiftersCMD

• ExtMirrorXRightCMD

• ExtMirrorXLeftCMD

• ExtMirrorYUpCMD

• ExtMirrorYDownCMD

• ExtMirrorDriverSelectCMD

• ExtMirrorPsngrSelectCMD

• ExtMirrorMemoryStoreRecallCMD

The swith panel contains no actuators.

The controller of the switch panel is called LF_SP. It has the following inputs and outputs:

inputs

• Key_Status (from key management)

outputs

• WL_Mov_LHF_Up (to LF_WinLifter)

• WL_Mov_LHF_Down (to LF_ WinLifter)

• WL_Mov_LHR_Up (to LR_ WinLifter)



• WL_Mov_LHR_Down (to LR_ WinLifter)

• WL_Mov_RHF_Up (to RF_ WinLifter)

• WL_Mov_RHF_Down (to RF_ WinLifter)

• WL_Mov_RHR_Up (to RR_ WinLifter)

• WL_Mov_RHR_Down (to RR_ WinLifter)

• WL_Automatic_Enable_LHF (to LF_WinLifter)

• WL_Automatic_Enable_LHR (to LR_WinLifter)

• WL_Automatic_Enable_RHF (to RF_WinLifter)

• WL_Automatic_Enable_RHR (to RR_WinLifter)

• LHFCmdCount (to LF_WinLifter)

• LHRCmdCount (to LR_WinLifter)

• RHFCmdCount (to RF_WinLifter)

• RHRCmdCount (to RR_WinLifter)

• MirrorSelection_L (to L_Mirror)

• MirrorSelection_R (to R_Mirror)

• MirrorMovement_L_Up (to L_Mirror)

• MirrorMovement_L _Down (to L_Mirror)

• MirrorMovement_L _Left (to L_Mirror)

• MirrorMovement_L _Right (to L_Mirror)

• MirrorMovement_R _Up (to R_Mirror)

• MirrorMovement_R _Down (to R_Mirror)

• MirrorMovement_R _Left (to R_Mirror)

• MirrorMovement_R _Right (to R_Mirror)

6.1.1.2 Window lifter modules

The window lifter modules are responsible for lowering and raising the windows. They operate according to the commands received from the switch panel, the position settings, the key_management, or the local switches. Switch panel commands have precedence over local operator commands. The modules have an anti-pitch functionality: if the current of the moving motor exceeds a given treshold during lifting, the window fully is opened. The care contains window lifter modules that are called: LF_WL, LR_WL, RF_WL, and RR_WL for left front, left rear, right front, and right rear. If we do not want to name the modules separately the xx shortening is used.

The window lifter modules are connected to the:

• switch panel module,

• key management,



• position settings.

The window lifter modules consist of the following sensors:

• xxWLMovUpCMD (switch)

• xxWLMovDownCMD (switch)

• xxWLCurrent

• xxAntiPinch

The window lifter modules consist of the following actuators:

• xxWLActuator

The controllers of the window lifter modules are called xx_WL. They have the following inputs and outputs:

inputs

• WL_Mov_Up (from Panel)

• WL_Mov_Down (from Panel)

• WL_Automatic_Enable (from Panel)

• CmdCount (from Panel)

• WL_AutoOpen_Sts (from Panel)

• WL_AutoClose_Sts (from Panel)

• Key_Sts (from Key_Management)

outputs

6.1.1.3 Mirror modules

The mirror modules are responsible for moving, heating, and comfort closing the mirrors. They operate according to the commands received from the switch panel and the position settings node. Switch panel commands have precedence over position settings commands. The car contains 2 mirror modules that are called: LF_MI and RF_MI for left and right. If we do not want to name the modules separately the xx shortening is used.

The mirror modules are connected to the:

• switch panel module,

• positions settings,

• key management.

The mirror modules consist of the following sensors:

• xx_ExternalMirrorLFXFeedback

• xx_ExternalMirrorLFYFeedback



The mirror modules consist of the following actuators:

• xx_ExternalMirrorLFXPosition

• xx_ExternalMirrorLFYPosition

The controllers of the mirror modules are called xx_MI. They have the following inputs and outputs:

inputs

• MirrorSelection (from Panel)

• MirrorMovementUp (from Panel)

• MirrorMovementDown (from Panel)

• MirrorMovementLeft (from Panel)

• MirrorMovementRight (from Panel)

• MemoryRecall (from position settings)

• xxMirrorXPosRef (from position settings)

• xxMirrorYPosRef (from position settings)

outputs

• xxMirrorXPos (to position settings)

• xxMirrorYPos (to position settings)

6.1.1.4 Lock/Unlock modules

The lock/unlock modules are responsible for locking/unlocking the doors, dead-locking the doors, and issue the automatic opening/closing command to the windows. They operate according to the commands received from the lock management module, or the local operator. The car contains 4 lock/unlock modules that are called: DL_LF, DL_LR, DL_RF, and DL_RR for left front, left rear, right front, and right rear. If we do not want to name the modules separately the xx shortening is used.

The lock/unlock modules are connected to the:

• key management module

• lock management module

The lock/unlock modules consist of the following sensors:

• xxSwitchLatchClockwiseCMD (switch)

• xxSwitchLatchAntiClockwiseCMD (switch)

• xxAjarSwitch (switch)

• xxLockedUnlockedSwitch (switch)

The lock/unlock modules consist of the following actuators:



• xxLockUnlockActuator

• xxDeadLockActuator

The controllers of the lock/unlock modules are called DL_xx. They have the following inputs and outputs:

inputs

• DLSetSts (from lock management)

• DLUnSetSts (from lock management)

• LockDoors (from lock management)

• UnlockDoors (from lock management)

• KeySts (from key management)

outputs

• DoorAutoCloseReq (to lock management)

• DoorAutoOpenReq (to lock management)

• DoorKeySwitchDLSetReq (to lock management)

• DoorKeySwitchDLUnsetReq (to lock management)

• DoorKeySwitchLockReq (to lock management)

• DoorKeySwitchUnlockReq (to lock management)

• DoorRealLockedSts (to lock management)

• AjarSwitchSts (to lock management)

6.1.1.5 Lock management module

The lock management module coordinates the operation of the window lifter modules, the lock/unlock modules, and the mirror modules.

The lock management module is connected to the:

• swith panel module

• lock/unlock modules

The lock management module does not consist of any sensors.

The lock management module does not consist of any actuators.

The controller of the lock management module is called lock management. It has the following inputs and outputs:

inputs

• CentralDoorLockReq (from switch panel)



• CentralDoorUnlockReq (from swith panel)

• DoorKeySwitchLockReq_LF (from LFLock)

• DoorKeySwitchLockReq_LR (from LRLock)

• DoorKeySwitchLockReq_RF (from RFLock)

• DoorKeySwitchLockReq_RR (from RRLock)

• DoorKeySwitchUnlockReq_LF (from LFLock)

• DoorKeySwitchUnlockReq_LR (from LRLock)

• DoorKeySwitchUnlockReq_RF (from RFLock)

• DoorKeySwitchUnlockReq_RR (from RRLock)

• DoorKeySwitchDLSetReq_LF (from LFLock)

• DoorKeySwitchDLSetReq_LR (from LRLock)

• DoorKeySwitchDLSetReq_RF (from RFLock)

• DoorKeySwitchDLSetReq_RR (from RRLock)

• DoorKeySwitchDLUnsetReq_LF (from LFLock)

• DoorKeySwitchDLUnsetReq_LR (from LRLock)

• DoorKeySwitchDLUnsetReq_RF (from RFLock)

• DoorKeySwitchDLUnsetReq_RR (from RRLock)

outputs

• DLSet_LF_Sts (to LFLock)

• DLSet_LR_Sts (to LRLock)

• DLSet_RF_Sts (to RFLock)

• DLSet_RR_Sts (to RRLock)

• DLUnSet_LF_Sts (to LFLock)

• DLUnSet_LR_Sts (to LRLock)

• DLUnSet_RF_Sts (to RFLock)

6.1.2 Component diagram of the doors subsystem

In order to illustrate the relationship between the above detailed units of the door subsystem, a visual representation is given in Figure 16.



sw_module

RFWinLifter

LRWinLifter

LMirror

RMirror

LFLock

RFLock

LFUp : Sensor

LFDown : Sensor

LFMotorCurrent : Sensor

LFWindowPosition : Sensor

LFWLMotor : Actuator

Panel

LHFUp : Sensor

LHFDown : Sensor

RHFUp : Sensor

RHFDown : Sensor

LHRUp : Sensor

LHRDown : Sensor

RHRUp : Sensor

RHRDown : Sensor

XLeft : Sensor

XRight : Sensor

YUp : Sensor

YDown : Sensor

MSDriver : Sensor

MSPassenger : Sensor

LXMOCMotorPosition : Sensor

LMHeating : Actuator

LXMMovMotor : Actuator

LYMMovMotor : Actuator

LXMOCMotor : Actuator

LMTemperature : Sensor

LXMMovMotorPosition : Sensor

LYMMovMotorPosition : Sensor

LFDLLatchClockwise : Sensor

LFDLLatchCounterClockwise : Sensor

LFDLMotorPosition : Sensor

LFDLMotor : Actuator

LFWinLifter

RRWinLifter

RFLock

RFLock

Figure 16: Component diagram of the doors subsystem

6.1.3 Non-functional requirements of the doors subsystem

The non-functional requirements of the doors subsystem are the performance related requirements and the dependability related requirements.

Performance requirements

In the doors subsystem for each functionality if a key is pressed (either on the switch panel or the local switch) the corresponding actuator (window lifter, mirror movement, or door lock) should react in less then 120 ms.

Dependability requirements

The doors susbsystem is a non-safety critical subsystem so there are no general dependability requirements. Despite of this fact there are some safety related sub-functions:

• Dead-lock can not be activated unintentionally in order to avoid the closing of somebody inside the car.



• Doors should be unlocked in case of a crash in order to avoid that emergency persons can not open the door from outside.

• Opened door status should be reliable reported to the TrafficJam subsystem in order to avoid the car starting without the driver sitting inside.

• Anti-pinch functionality should not work if the driver leaves the car in order to avoid that somebody gets pinched by the window.

6.2 PIM of the example

The PIM of the example is not given here in full detail, but one diagram for each diagram type is presented. The full model can be downloaded from the DECOS document archive. The name of the document is: DECOS_1.1-017_0.5w_PIM_example_2.mdl and DECOS_1.1-017_0.5w_PIM_example_2_web.zip as well. The first document is for Rational Rose, the second is for Java enabled browsers. In modeling each sensor and actuator will be modelled as a separate resource and each controller will be modelled as a job.

Functionality Performance

PIM example #2 of the Doors subsystem (WP 5.1)based on PIM metamodel Version 1.3w

Dependability

Figure 17: The top-most diagram of the PIM example

The top-most diagram of the example (see Figure 17) contains three packages that are similar to the PIM metamodel. The functionality package describes the functionality of the system, while the dependability and performance packages describe the dependability and performance attributes of the elements defined in the functionality package.



DAS, jobs

Communication

Resources

Interfaces, ports, variables

Figure 18: Packages of the functionality package

The functionality package is sub-divided into many other packages, according to the units of the system (see Figure 18). The package "DAS, jobs" describes the DAS, the operating mode of the DAS and the jobs of the system. The Resources package describes the "Resources" needed by the job. The package "Interfaces, ports, variables" describes the interfaces, ports, and variables of the job. Finally the package Communication describes the communication within the DAS.

SP_LF_sub_jobs<<Job>>

Lock_Management_sub_jobs<<Job>>

Normal

Name : String = Normal

Description : String

<<OperatingMode>>

Door_Subsystem

Name : String = Door_Subsystem

Description : String = Example based on WP5.1

Type : String

<<DAS>>

<<initial>>

Gatew ayJobs<<Job>>

Mirror<<Job>>

DoorLock<<Job>>

Window Lifter<<Job>>

Figure 19: The top-level Job package of the doors subsystem

The DAS is called DoorSubsystem (see Figure 19). It has a single operating mode, called Normal. The subsystem consists of 6 functionalitis: SP_LF (the switch panel), Lock_Management (the lock management module), Mirror (the 2 external mirrors), Window Lifter (the 4 window lifters), Door Lock (the 4 door locks) and the Gateway Jobs to the other DASs.



Door_Subsystem

Name : String = Door_SubsystemDescription : String = Example based on WP5.1Type : String

(from DAS, jobs)

<<DAS>>

Manual_Movement

Name : String = Manual_MovementDescription : String

<<Job>>

Automatic_Movement


<<Job>>Normal

Name : String = NormalDescription : String

(from DAS, jobs)

<<OperatingMode>>

<<initial>>

<<runsIn>>

<<runsIn>>

Figure 20: The Job package of the left-front mirror

The left-front mirror contains two jobs (see Figure 20). The Manuam_Movement is responsable for moving the mirrors using the switch panel switches, while the Automatic_Movement job is reponsible for moving the mirrors using the stored mirror position. Both jobs belong to the Door_Subsystem DAS and runs in its Normal operating mode.

ExternalMirrorLFXFeedback<<Sensor>>

Automatic_Movement


(from MI_LF)

<<Job>>

<<needs>>

ExternalMirrorLFYFeedback<<Sensor>>

<<needs>>

ExternalMirrorLFXPosition

Latency : Duration = 0ExecutionTime : Duration = 50

<<Actuator>>

ExternalMirrorLFYPosition<<Actuator>>

Manual_Movement


(from MI_LF)

<<Job>>

<<needs>>

<<needs>>

Figure 21: Resources of the left mirror

The resources of the left mirror are detailed in the LF_MI_Resources package (see Figure 21). The mirror needs 2 sensors in order to work properly: moving motor X and Y position. The mirror controller controls 2 actuators: vertical positioning motor and horizontal positioning motor.



ExtMirrorXLeftREQ

Name : String = ExtMirrorXLeftREQ

TransmissionType : Enum = unicast

ValiditySpan : Duration

<<EventMessage>>

ExtMirrorXPosition

Name : String = ExtMirrorXPosition



<<StateMessage>>

ExtMirrorXPosRef

Name : String = ExtMirrorLFXPosRef



<<StateMessage>>

ExtMirrorXRightREQ

Name : String = ExtMirrorXRightREQ



<<EventMessage>>

ExtMirrorYDownREQ

Name : String = ExtMirrorYDownREQ



<<EventMessage>>

ExtMirrorYPosition

Name : String = ExtMirrorYPosition



<<StateMessage>>

ExtMirrorYPosRef




<<StateMessage>>

ExtMirrorYUpREQ

Name : String = ExtMirrorYUpREQ



<<EventMessage>>

MemoryRecall




<<EventMessage>>

MirrorSelection

Name : String = MirrorSelection



<<EventMessage>>

Figure 22: The Message package of the left mirror

The message package (see Figure 22) of the left mirror describes the messages that are used to communicate with the mirror jobs.

AM_SPLIF

<<SPLIF>>

ExtMirrorXPosition




(from Mirror)

<<StateMessage>>

ExtMirrorYPosition




(from Mirror)

<<StateMessage>>

AM_to_PS

<<StateMessagePort>>

<<hasPort>>

<<write>> <<write>>

Automatic_Movement

Name : String = Manual_Movement


(from MI_LF)

<<Job>>

Figure 23: Interfaces and ports of the left front mirror.

The interfaces and ports package (Figure 23) describes the interfaces (SPLIF, SRLIF, COI) of the left fron mirror job. For the sake of visibility only a part of the package is presented in the figure.



Position_Settings

Name : String = Postion_Settings

Description : String = External_Module_for_Mirror-Seat_Position

(from GatewayJobs)

<<GatewayJob>>

PS_SRLIF(from Position_Settings_...

<<SRLIF>>

<<hasInterface>>

ExtMirrorXPosition




(from Mirror)

<<StateMessage>>ExtMirrorYPosition




(from Mirror)

<<StateMessage>>

PS_from_LF_MI_AM(from Position_Settings_...


<<hasPort>>

<<read>> <<read>>

AM_to_PS(from LF_MI_...


<<write>> <<write>>+sender

+receiver

<<communicate>>

AM_SPLIF(from LF_MI_...

<<SPLIF>>

<<hasPort>>

Automatic_Movement



(from MI_LF)

<<Job>>

<<hasInterface>>

Figure 24: Communication of the left front mirror

The communication package (see Figure 24) describes the interfaces, ports and messages the left mirror has. The Automatic_Movement job has a service providing linking interface that consists a state message port AM_to_PS. The port is used to send ExtMirrorXPosition and ExtMirrorYPosition messages to the state message port PS_from_LF_MI_AM of the Position_Settings gateway jobs.



ExtMirrorLFXPosition_V

Type : String = Byte

FixedLength : Boolean = True

Length : Integer = 8

InitialValue : Boolean = 0

Averagable : Boolean = False

<<StateVariable>>

ExtMirrorLFYPosition_V






<<StateVariable>>

ExtMirrorXPosition




(from Mirror)

<<StateMessage>>

<<image>>

ExtMirrorYPosition




(from Mirror)

<<StateMessage>>

<<image>>

Figure 25: Variables of the left mirror

The communication of the left mirror is done by using its variables that are visible for the message ports (see Figure 25). The variables of the left mirror corresponds to the status of the sensors and actuators the job needs and to the commands the job has to execute. In the figure only a part of the variables are given.

PerfReq_1

Exp : String = "ExtMirrorXLeftCMD.Latency + MISwitchManagementPerformanceNormal.WCET + ExtMirrorXLeftREQPerformanceNormal.LatencyTime + ManualMovementPerformanceNormal.WCET + ExternalMirrorLFXPosition.Latency <= 120ms"

<<PerformanceRequirement>>

ExtMirrorXLeftCMD

Latency : Duration = 0

(from SP_LF_Resources)

<<Sensor>>

MISwitchManagementPerformanceNormal

WCET : Duration

<<JobPerformance>>

MISwitchManagement

Name : String = MISwitchManagementDescription : String

(from SP_LF_sub_jobs)

<<Job>>

<<needs>>

OperatingMode=NormalOperatingMode=Normal

ExtMirrorXLeftREQPerformanceNormal

LatencyTime : Duration

<<EventMessagePerformance>>

ManualMovementPerformanceNormal

WCET : Duration

<<JobPerformance>>

ExtMirrorXLeftREQ

Name : String = ExtMirrorXLeftREQTransmissionType : Enum = unicastValiditySpan : Duration

(from Mirror)

<<EventMessage>>



Latency : Duration = 0

ExecutionTime : Duration = 50

(from LF_MI_Resources)

<<Actuator>>Manual_Movement


(from MI_LF)

<<Job>>


<<needs>>

Figure 26: Content of the Performance package

The performance package describes the performance requirements of the system (see Figure 26). For example the constraint that a mirror should be moved within 120 ms of the pressing of the mirror movement switch is described by the expression:

Exp : String = "ExtMirrorXLeftCMD.Latency + MISwitchManagementPerformanceNormal.WCET + ExtMirrorXLeftREQPerformanceNormal.LatencyTime + ManualMovementPerformanceNormal.WCET + ExternalMirrorLFXPosition.Latency <= 120ms"

6.3 Creation steps of the example PIM

6.3.1 Definition of the DAS



Functionality Performance

PIM example #2 of the Doors subsystem (WP 5.1)based on PIM metamodel Version 1.3w

Dependability

Figure 27: Top-level package diagram of the doors subsystem

DAS, jobs

Communication

Resources

Interfaces, ports, variables

Figure 28: Functionality package of the PIM



Mirror<<Job>>

Lock_Management_sub_jobs<<Job>>

SP_LF_sub_jobs<<Job>>

Normal

Name : String = Normal


<<OperatingMode>>

Door_Subsystem

Name : String = Door_Subsystem

Description : String = Example based on WP5.1

Type : String

<<DAS>>

<<initial>>

Gatew ayJobs<<Job>> DoorLock

<<Job>>

Window Lifter<<Job>>

Figure 29: DAS diagram with the Normal operating mode

6.3.2 Definition of jobs

Door_Subsystem


(from DAS, jobs)

<<DAS>>

Normal


(from DAS, jobs)

<<OperatingMode>>

<<initial>>

MI_LF<<Job>>

MI_RF<<Job>>

Figure 30: Job package of the mirror functionality

Door_Subsystem


(from DAS, jobs)

<<DAS>>

Normal


(from DAS, jobs)

<<OperatingMode>>

<<initial>>

MI_LF<<Job>>

MI_RF<<Job>>

Figure 31: Job breakdown of the mirror functionality to left and right side



Door_Subsystem


(from DAS, jobs)

<<DAS>>

Manual_Movement


<<Job>>

Automatic_Movement


<<Job>>Normal


(from DAS, jobs)

<<OperatingMode>>

<<initial>>

<<runsIn>>

<<runsIn>>

Figure 32: Jobs of the left front mirror module

6.3.3 Definition of resources

ExternalMirrorLFXFeedback<<Sensor>>

Automatic_Movement


(from MI_LF)

<<Job>>

<<needs>>

ExternalMirrorLFYFeedback<<Sensor>>

<<needs>>


Latency : Duration = 0ExecutionTime : Duration = 50

<<Actuator>>

ExternalMirrorLFYPosition<<Actuator>>

Manual_Movement


(from MI_LF)

<<Job>>

<<needs>>

<<needs>>

Figure 33: Resources of the left mirror

6.3.4 Definition of messages



KeySts<<StateMessage>>

CmdCount<<EventMessage>>

Mirror<<Message>>

WindowLifter<<Message>>

DoorLock<<Message>>

Figure 34: The packages of the messages package

ExtMirrorXLeftREQ

Name : String = ExtMirrorXLeftREQ


Val idi tySpan : Duration

<<EventMessage>>

ExtMirrorXPosition




<<StateMessage>>

ExtMirrorXPosRef




<<StateMessage>>

ExtMirrorXRightREQ

Name : String = ExtMirrorXRightREQ



<<EventMessage>>

ExtMirrorYDownREQ

Name : String = ExtMirrorYDownREQ



<<EventMessage>>

ExtMirrorYPosition




<<StateMessage>>

ExtMirrorYPosRef




<<StateMessage>>

ExtMirrorYUpREQ

Name : String = ExtMirrorYUpREQ



<<EventMessage>>

MemoryRecall




<<EventMessage>>

MirrorSelection

Name : String = MirrorSelection



<<EventMessage>>

Figure 35: Messages of the mirror functionality

6.3.5 Definition of interfaces and ports



LF_MI_ipv RF_MI_ipv

Key_Management_ipv Position_Settings_ipv

SP_LF_ipv

DL_LF_ipv

WL_LF_ipv

Lock_Management_ipv GeneralUnlockSource_ipv

WL_RF_ipv

DL_RF_ipv DL_LR_ipv DL_RR_ipv

WL_LR_ipv WL_RR_ipv

Figure 36: Interfaces and variables of the doors subsystem

KeyStatus_V

Type : String = Boolean[2]

FixedLenght : Boolean = True


InitialValue : Boolean[2] = {False,False}


<<StateVariable>>

MemoryRecall_V

Type : String = Boolean



InitialValue : Boolean = False


<<StateVariable>>

ExtMirrorLFXPosRef_V






<<StateVariable>>

ExtMirrorLFYPosRef_V






<<StateVariable>>

KeySts(from Messages)

<<StateMessage>>

<<image>>

MemoryRecall




(from Mirror)

<<EventMessage>>

<<delta>>

ExtMirrorXPosRef




(from Mirror)

<<StateMessage>>

<<image>>

ExtMirrorYPosRef




(from Mirror)

<<StateMessage>>

<<image>>

AM_from_KM_state


<<read>>

AM_from_SP_event

Direction : Enum = In

<<EventMessagePort>>

<<read>>

AM_from_SP_state


<<read>> <<read>>

AM_SRLIF

<<SRLIF>>

<<hasPort>><<hasPort>>

<<hasPort>>

Automatic_Movement



(from MI_LF)

<<Job>>

<<hasInterface>>







<<StateVariable>>







<<StateVariable>>

AM_SPLIF

<<SPLIF>>

<<hasInterface>>

ExtMirrorXPosition




(from Mirror)

<<StateMessage>>

ExtMirrorYPosition




(from Mirror)

<<StateMessage>>

<<image>>

AM_to_PS


<<hasPort>>

<<write>> <<write>>

Figure 37: Interfaces and ports of the Automatic Movement job



6.3.6 Definition of the communication

LF_MI_Communication

DL_LF_Communication

WL_LF_Communication WL_RF_Communication

RF_MI_Communication

DL_RF_Communication

Messages

GeneralUnlockSource_Communication

DL_LR_Communication DL_RR_Communication

WL_LR_Communication WL_RR_Communication

SP_LF_Communicationredundant!

Figure 38: Communication packages of the doors subsystem



MISwitchManagement

Name : String = MISwitchManagement


(from SP_LF_sub_jobs)

<<Job>>

SP_LF_MISM_SPLIF(from SP_LF_...

<<SPLIF>>

<<hasInterface> >

MemoryRecall




(from Mirror)

<<EventMessage>>

SP_to_LF_MI_AM_event

Name : String = SP_to_LF_ML

Description : String = Port to leftfront mirror

Direction : Enum = Out

Buffer : Integer

(from SP_LF_ipv)


<<write>>

<<hasPort>>

ExtMirrorXPosRef




(from Mirror)

<<StateMessage>> ExtMirrorYPosRef




(from Mirror)

<<StateMessage>>

SP_to_LF_ML_AM_state(from SP_LF_...


<<write>><<write>>

<<hasPort>>

Automatic_Movement



(from MI_LF)

<<Job>>

AM_from_SP_event

Direction : Enum = In(from LF_MI_ipv)


<<read>>

+receiver

+sender

<<communicate>>

AM_from_SP_state(from LF_MI_...


<<read>><<read>>

+sender

+receiver

<<communicate> >

Key_Management

Name : String = Key_Management

Description : String = Provides_Key_Status_Information

(from GatewayJobs)

<<GatewayJob>>

AM_SRLIF(from LF_MI_...

<<SRLIF>>

<<hasInterface> >

<<hasPort>>

<<hasPort>>

KM_SPLIF(from Key_Management_...

<<SPLIF>>

<<hasInterface> >

AM_from_KM_state(from LF_MI_...

<<StateMessagePort> >

<<hasPort>>

KM_to_LF_MI_AM(from Key_Management_...


<<hasPort>>

+receiver

+sender

<<communicate>>KeySts(from Messa...

<<StateMessage>>

<<read>>

<<write>>

Figure 39: Communication of the left front mirror

6.3.7 Definition of variables







<<StateVariable>>







<<StateVariable>>

ExtMirrorXPosition




(from Mirror)

<<StateMessage>>

<<image>>

ExtMirrorYPosition




(from Mirror)

<<StateMessage>>

<<image>>

Figure 40: Variables of the left front mirror

6.3.8 Definition of performance constraints

See Figure 26.



7 References

[1] Uml Based Specification Environment, http://www.db.informatik.uni-bremen.de/projects/USE/

[2] Sparx Systems, http://www.sparxsystems.com.au

[3] The Object Management Group http://www.omg.org

[ODM03]

OMG Ontology Definition Metamodel-RFP (2003).

Available: http://www.omg.org/cgi-bin/doc?ad/2003-03-40

[Straeten03]

Van Der Straeten, R., Mens, T. and Simmonds, J. Maintaining Consistency between UML Models Using Description Logic. Workshop on Consistency Problems in UML-based Software Development II, Blekinge Institute of Technology, Research Report, L. Kuzniarz, Z. Huzar, G. Reggio, J.L. Sourouille, M. Staron (Eds), October 2003, San Francisco, USA, pp. 71-77.

[Straeten04] Van Der Straeten, R. Inconsistency Detection between UML Models Using RACER and nRQL. CEUR Workshop Proceedings, Fourth International Workshop on Applications of Description Logics (ADL'04). Edited by Sean Bechhofer, Volker Haarslev, Carsten Lutz and Ralf Moeller. September 24, 2004, Ulm, Germany.

[Haarslev04] Haarslev, V., Möller, R., Van Der Straeten, R. and Wessel, M. Extended Query Facilities for Racer and an Application to Software Engineering Problems. Proceedings of the 2004 International Workshop on Description Logic (DL2004), Volker Haarslev and Ralf Moeller, Editors, Whistler, Canada.

[Moeller03] Ralf Möller , Volker Haarslev. Description Logic Systems. In: The Description Logic Handbook. Franz Baader, Diego Calvanese, Deborah McGuinness, Daniele Nardi, Peter Patel-Schneider (Eds.), Cambridge University Press, 2003, Chapter 8, pp. 282-305.

[Haarslev01]

Volker Haarslev , Ralf Möller. Description of the RACER System and its Applications. Proceedings of the International Workshop on Description Logics (DL-2001), Stanford, USA, 1.-3. August 2001, pp. 132-141.

[Djuric04] D. Djuric. MDA-based Ontology Infrastructure. International Journal on Computer Science and Information Systems, Vol. 1, No. 1, 2004, pp. 91-116.

[Gasevic04]

D. Djuric, D. Gaševic, V. Devedžic. MDA-Based Ontological Engineering. In Chang, S. K. (Ed.) Handbook of Software Engineering and Knowledge Engineering, Vol. 3, World Scientific Publishing Co., Singapore, 2004.

[Berardi02] Daniela Berardi. Using DLs to reason on UML Class Diagrams. In Proc. of the KI-2002 Workshop W6 on “Applications of Description Logics” ADL’02.

[Berardi01]

D. Berardi, D. Calvanese and G. De Giacomo. Reasoning on UML Class Diagram using Description Logic Based System.In Proc. of the KI-2001 Workshop W6 on Applications of Description Logics, ADL’01.

[Horrocks00] Horrocks, U. Sattler and S. Tobies. Reasoning with Individuals for the Description Logic SHIQ. In Proceedings of the 17th International Conference on Automated Deduction, CADE-17, 2000.

[OCL] UML 2.0 OCL specification. www.omg.org/docs/ptc/03-10-14.pdf

[OWL] Web Ontology Language. http://www.w3.org/2004/OWL/

[OWG] Web –Ontology Working Group. http://www.w3.org/2001/sw/WebOnt/

[Protege]

The Protégé Ontology Editor and Knowledge Acquisition System. http://protege.stanford.edu

[Racer]

RACER User's Guide and Reference Manual (Version 1.7.19) www.sts.tu-harburg.de/~r.f.moeller/ racer/racer-manual

[D4.1.2] Erwin Schoitsch et. al., DECOS Test Bench: Design and Specification, DECOS Deliverable 4.1.2



8 Appendix

The addendum of this document deals with the following topics:

Chapter 2.

The current version of the PIM metamodel is 2.0r. Chages from PIM 1.0r (presented in the released D1.1.1) to PIM 2.0r are given in this chapter.

Another new issue of the PIM metamodel is the formal definition of constraints, that were presented in english textual format in D1.1.1. Several constraints can be checked at the PIM level. Some of these were mentioned informally in the Deliverable 1.1.1 document. Now, these constaints and others as well are formalized using the Object Constraint Language. These constraints are to check PIM models, not to check the metamodel itself. Checking the constaints on a specific PIM is possible with the UML Based Specification Environment [x]. This free tool allows the modeler to create models based on a metamodel, and to check OCL constraints on it. Moreover, it checks the multiplicity constraints after each model change. It has only one disadvantage: it does not handle association classes. Thus, the constraints that are using these cannot be checked, or association classes shall be converted to 3-ary associations along with the constraints.

Another addition is the exemplary implementation is a UML profile for PIM. The base is the 1.0r version of the PIM metamodel that was presented in D1.1.1. The profile is implemented for Enterprise Architect. The UML Standard introduces profiles for extending the capabilities of the core modelling language. Meta-model developers who create domain-specific modelling languages based on UML can easily integrate new elements into the existing UML modelling environment. UML profiles define a mapping between UML meta-model elements and the elements of the domain-specific language.

Finally the data model of the PIM is defined using the PIM metamodel. We provide an XML Schema description for the data format. PIM modelling tools may use other data formats, but tool providers have to provide support for mapping to the standard PIM data format.

Chapter 3.

This chapter presents the current 2.0r version of the PIM metamodel in its full detail. If possible, we refer to the DECOS Technology Paper for definitions. This is the document that should serve as a common reference for definitions. Definitions are typeset in italic and where not noted differently are cited from the technology paper.

The included tables list the defined metamodel elements in a tabular format. Please note that the documentation found in these tables is embedded in the metamodel file too.

Chapter 4.

This chapter presents the preliminary SCADE UML profile that was created by Esterel Technologies in order to be able to import UML based PIMs into the SCADE tool.

Documents

Design methodology and specification modelstatic.inf.mit.bme.hu/decoscd/deliverables/DECOS_deliv_Design_Methodology.pdf0.3w 16/09/2005 PIM metamodel changed + Chapters restructured