ode profile v1 - deis-project€¦ · ode profile v1 page 4 of 24 1 publishable executive summary...
TRANSCRIPT
ODE Profile V1 D4.1
www.deis-project.eu
This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant
agreement No 732242 (DEIS).
ODE Profile V1
Page 1 of 24
Table of Contents
1 Publishable Executive Summary ............................................................................................................ 4
2 Introduction - The ODE Meta-Model overview ..................................................................................... 5
3 Related work ......................................................................................................................................... 6
4 ODE - Technical concept ........................................................................................................................ 8
4.1 ODE Tool Usage Scenarios ............................................................................................................. 8
4.2 EMF as ecosystem for DDI exchange ........................................................................................... 11
5 Demonstrators: State of ODE implementation in the DEIS Tools ........................................................ 12
5.1 ACME ........................................................................................................................................... 12
5.1.1 Assurance Case Editing ........................................................................................................ 12
5.1.2 Argumentation Editing ........................................................................................................ 12
5.1.3 Artifact Editing ..................................................................................................................... 12
5.1.4 Terminology ........................................................................................................................ 13
5.2 ComposR ..................................................................................................................................... 14
5.3 Hip-Hops ...................................................................................................................................... 16
5.3.1 ODE Integration with HiP-HOPS........................................................................................... 18
5.4 safeTbox™ ................................................................................................................................... 19
6 Summary and Outlook ......................................................................................................................... 22
7 References ........................................................................................................................................... 23
ODE Profile V1
Page 2 of 24
List of Figures
FIGURE 1 ABSTRACT ODE META-MODEL .................................................................................................................................. 5
FIGURE 2 DEVELOPMENT APPROACH FOR TOOL INTEROPERABILITY ................................................................................................ 8
FIGURE 3 ODE PROFILE BUILD WITH EMF ................................................................................................................................ 9
FIGURE 4 ACME ARTIFACT EDITING ....................................................................................................................................... 12
FIGURE 5 ACME ARTIFACT REFERENCING ............................................................................................................................... 13
FIGURE 6 ACME TERMINOLOGY ASSET CREATION ................................................................................................................... 13
FIGURE 8 ACME USING A TERMINOLOGY TERM IN THE ARGUMENTATION ................................................................................... 14
FIGURE 9 SYSTEM MODELING USING COMPOSR ....................................................................................................................... 15
FIGURE 10 FLM MODELING IN FORM OF A COMPONENT FAULT TREE (CFT) USING COMPOSR..................................................... 15
FIGURE 11 MODELING GSN USING COMPOSR ...................................................................................................................... 16
FIGURE 12 HIP-HOPS MODELING WITH MATLAB/SIMULINK ................................................................................................ 17
FIGURE 13 FTA WITH HIP-HOPS ....................................................................................................................................... 18
FIGURE 14 ODE-HIP-HOPS INTEGRATION PROCESS .............................................................................................................. 19
FIGURE 15 EXAMPLE OF A COMPONENT NETWORK MODELED WITH SAFETBOX. .......................................................................... 20
FIGURE 16 EXAMPLE OF A COMPONENT FAULT TREE. .............................................................................................................. 20
FIGURE 17 EXAMPLE OF A GSN .......................................................................................................................................... 21
ODE Profile V1
Page 3 of 24
Abbreviations
Abbreviation Long Version
AADL Architecture Analysis and Design Language
ACME Assurance Case Modelling Environment
CFT Component Fault Trees
DDI Digital Dependability Identity
EMF Eclipse Modeling Framework
FMEA Failure Mode and Effect Analysis
FTA Fault Tree Analysis
GSN Goal Structuring Notation
MDE Model Driven Engineering
ODE Open Dependability Exchange Meta-model
OCL Object Constraint Language
SACM Structured Assurance Case Meta-model
SAE Society of Automotive Engineers
XMI XML Metadata Interchange
XML Extensible Markup Language
Authors
Name, Partner E-mail
Daniel Schneider
Santiago Velasco
Ran Wei [email protected]
Ioannis Sorokos [email protected]
Marc Zeller [email protected]
Eric Armengaud, AVL [email protected]
ODE Profile V1
Page 4 of 24
1 Publishable Executive Summary
The open and cooperative nature of CPS poses a significant new challenge in assuring dependability. The
DEIS project addresses this important and unsolved challenges by developing technologies that form a
science of dependable system integration. In the core of these technologies lies the concept of a Digital
Dependability Identity (DDI) of a component or system. DDIs are composable and executable in the field
facilitating (a) efficient synthesis of component and system dependability information over the supply chain
and (b) effective evaluation of this information in-the-field for safe and secure composition of highly
distributed and autonomous CPS. In order to make this vision reality, it is necessary to build the tools that
would allow engineering and executing DDIs. In this document it is therefore presented the initial version
of the Open Dependability Exchange (ODE) meta-model, which is the meta-model for the DEIS core concept
of Digital Dependability Identities (DDI). Consequently, the work results described here are very tightly
interrelated with the work being carried out in WP3 and the upcoming D3.1. At the same time, this work is
building directly on the requirements, use cases and demonstrators described in D2.1, D5.1, D6.1 and D6.2.
The ODE is a central artifact for the project, this textual description complement and assist in its
comprehension. Thus, we describe our approach to derive and design the ODE and, in particular, provide
details with respect to the current initial version of the ODE. Moreover, we describe the respective
developments that have been conducted on the four tools of the DEIS consortium: ACME (UoY), ComposeR
(SAG), HiP-HOPS (UoH) and safeTbox (IESE). For each tool in particular, we describe which aspect of the
ODE has been currently implemented and provide corresponding screenshots and (if presently
possible/feasible) a download link for the respective tool.
ODE Profile V1
Page 5 of 24
2 Introduction - The ODE Meta-Model overview Cyber-Physical-Systems (CPS) provide the potential for vast economic and societal impact in domains such
as automotive, health care and home automation. The open and cooperative nature of CPS poses a
significant new challenge in assuring dependability. The DEIS project addresses this important and unsolved
challenge by developing technologies that enable a science of dependable system integration. A key
innovation is the concept of the Digital Dependability Identity (DDI). A DDI contains all the information that
uniquely describes the dependability characteristics of a CPS or CPS component. DDIs are used for the
integration of components into systems during development as well as for the dynamic integration of
systems into systems of systems in the field. Some of the objectives we pursue in DEIS are:
• Objective 1: An open model for specifying Digital Dependability Identities enabling the efficient integration of modular dependability assurance cases
• Objective 2: Semi-automated framework for the generation and evaluation of DDIs • Objective 3: A framework for the in-the-field dependability assurance in CPS • Objective 4: autonomous and connected CPS use cases
The ODE is the meta-model for the DEIS core concept of the DDI and thus a central artifact of the project.
It needs to be fit for the DEIS core challenges and objectives as described in the proposal and refined in
D2.1, D5.1 and D6.1. The general concept of the ODE as well as its refinement based on engineering stories
is presented in deliverable 3.1.
In Figure 1, an abstract presentation of the current version of the meta-model can be observed. Many
entities and relationships have been removed or abstracted for ease of comprehension. The detailed
version is presented in Figure 3.
Figure 1 Abstract ODE meta-Model
ODE Profile V1
Page 6 of 24
The current structure of the meta-model includes several packages. At the highest level of abstraction, it is
possible to observe the ODE as a central container. It aggregates other major packages, namely: the
Dependability, Requirements, Hazard and Risk Assessment (HARA), Domain, Architecture, Failure-logic, and
Base packages. The first four mentioned packages aggregate the artifacts that are created/required during
early phases of the development process, such as determining the relevant system development standards,
identifying functional and non-functional requirements, as well as their prioritization through early safety
activities like the HARA, which can have a large impact on the rest of the development. With this
information, the design process is then carried out. Towards this end, the architecture package has been
conceived. Through this package, it is possible to define the primary entities of the system, how they relate
to each other with respect to composition as well as how they interact. Once a design is established, fault
analysis can be performed. The overall aim is to evaluate whether the design avoids, removes or mitigates
the identified Hazards. To investigate this relationship, the sources of Hazards – failures of the system’s
functions – are traced via analysis to progressively more refined, lower-level elements of the architecture.
In the current version of the ODE three different fault analysis techniques have been considered as relevant
for the industry and have been included in the meta-model, namely: Fault Tree Analysis (FTA), Failure Mode
and Effects Analysis (FMEA) and Markov analysis.
Finally, the Base package has been introduced to the ODE for flexibility purposes. In it, a generic mechanism
has been incorporated such that ODE elements can be annotated dynamically. Thanks to that mechanism,
information not considered during the definition of the ODE can be flexibly added during its instantiation.
As explained in deliverable 3.1, during the instantiation of SACM it will be possible to integrate into it an
instantiation of the ODE package, which at the same time aggregate the instantiation of the other
mentioned packages.
3 Related work In this section, we introduce shortly the work provided by other groups with respect to model-based
development. We present the topic by considering several of the goals DEIS wants to achieve with the
definition of the ODE.
Goal: Support an integrated modeling approach
The traditional document-based (e.g. word and excel) approach for system development has been overrun
by the complexity of today's dependability-related systems. Therefore, the current development trend is
towards model-based approaches, which promise to overcome known problems like traceability,
maintainability and reuse.
In the area of integrated modeling approaches, the Unified Modeling Language (UML) [Object Management
Group - UML] provides the means for the specification, construction and documentation of software. UML
was created with the intention to support the design of software by making use of different modeling
ODE Profile V1
Page 7 of 24
techniques to tackle issues of different nature. E.g. use Class or Components diagrams to define the
structure of the system, or Sequence diagrams to specify the behavior of the system.
However, most systems consist of other parts besides software. For this reason, it became necessary to
extend and adapt UML with concepts that facilitates the specification of other types of systems. For that,
the Systems Modeling Language (SysML) [Object Management Group - SysML] was created. UML and
SysML have been standardized by the Object Management Group, and many tool vendors support the most
current specifications.
While UML and SysML are often used for the system's functional design, they do not provide optimal ways
to specify certain qualities of the system, like safety. For instance, there are no means to specify hazards,
or faults. To tackle this issue, several groups have invested efforts in extending UML or defining their own
modeling languages. For example, the Society of Automotive Engineers (SAE) has produced the
Architecture Analysis and Design Language (AADL) [Feiler, P.H., Gluch, D.P., Hudak, J.J.]. The CHESS project
[Montecchi, L., Lollini, P., Bondavalli, A.] is an effort to create a complete modelling tool chain for
dependable systems, SafeML [Biggs, G., Sakamoto, T. & Kotoku] is a SysML profile designed for modelling
the safety-related concerns of a system. In DEIS these approaches have been used as reference and as a
basis, with the aim to support existing engineering challenges as well as future challenges such as openness
and runtime adaptability.
Goal: tool interoperability
In the area of open systems, it is important to provide the means for participant systems as well as for their
designers to communicate with each other. For this reason, it is necessary to define a common language
that allows exchanging data between tools.
With respect to tool interoperability, the Open Services for Lifecycle Collaboration group (OSLC) [Ryman,
A. G.; Hors, A. J. L.; and Speicher, S. 2013] is making an effort to standardize languages in many areas, e.g.
requirements, architecture management, automation, etc. Unfortunately, there is no language yet defined
for the dependability domain. In general, the OSLC domain specifications define a meta-model including
only the main sources of information to be exchanged. While this increases the chances to exchange at
least of a minimum set of information, it hinders covering a larger set of usages based on meta-models that
are more extensive. In DEIS, it is currently more important to support properly the defined engineering
challenges specified in deliverable 3.1. For this reason, the concrete support for tool interoperability will
be tackled later in the project. For now, the ODE meta-model represents one-step forward towards this
goal, which in the future could be reduced or abstracted to support larger levels of interoperability. This
will be evaluated with the first prototypes of the tools.
Goal: tool support
Modern development approaches for dependability systems have started introducing model-based
solutions for documentation. However due to the complexity of the systems, the models tend to become
ODE Profile V1
Page 8 of 24
large and maintenance error prone. For this reason, proper tool-support is required. Although, there are
several tool vendors supporting the existing safety life cycle, they do not provide the flexibility or the
extension possibilities to make appropriate use of them in the context of the DEIS project. For this reason
within DEIS it has become necessary to drive our own tool solutions. They will serve as prototypes
exemplifying the use of the ODE and DDI approaches. In the future is expected that interested tool vendors
integrate several of the ideas developed in DEIS.
4 ODE - Technical concept
4.1 ODE Tool Usage Scenarios
To support engineering stories in DEIS a basis for communication needs to be defined. For this reason, the
priority has been placed in achieving first a proper mechanism for the exchange of data. The development
steps planned to achieve this are sketched in the following figure.
Figure 2 Development approach for tool interoperability
Initially, the ODE exchange format is created (i.e. ODE Meta-Model). The detailed version of the meta-
model is shown in Figure 3 (For an appropriate explanation of the meta-model and its packages, please
refer to deliverable 3.1). With the given meta-model a common language has been defined. For this task
the Eclipse Modeling Framework (EMF) [Dave Steinberg, Frank Budinsky, Marcelo Paternostro, Ed Merks]
has been chosen. The detailed reasons for the use of EMF are explained in section 4.2. With this language,
tool providers within DEIS can now implement importing and exporting features to serialize and de-serialize
(parse) data from their own tools. Since the ODE Meta-Model has been created with flexibility in mind,
there exists a need to set several rules regarding how information is packaged and unpackaged into ODE
instances (i.e. DDIs). These validation rules enable checking the conformity and coherence of the data
provided. In the final step, tool providers in DEIS are expected to extend the features of their respective
tools to support the different uses of the ODE. Complete support for all usage scenarios provided by the
ODE is not compulsory, but it must be negotiated between all partners with respect to the engineering
ODE Profile V1
Page 9 of 24
scenarios used to evaluate the developed concepts. This will occur at a later point in time. A subset of basic
ODE usages has been documented in table 1.
Figure 3 ODE Profile build with EMF
Package Abstraction
level Usage
Base As an ODE user, I am able to… High
… extend during ODE instantiation dynamically the attributes of existing entities
Low … Define new attributes By means of a key-values Map
Low … Filter dynamically added attributes through its tag attribute
Low … identify uniquely artifacts
Architecture High … structure my system design through different views and abstraction levels
As a Systems Engineer, I am able to… High
... define systems/components modularly and compose them to create larger systems
Low ... create a heterogeneous network including systems, physical and logical components
Low … create a hierarchical network of functions/safety functions for a system/components
ODE Profile V1
Page 10 of 24
Low … specify which functions are realized by which systems/components
Low … define the interfaces of the system/components/functions by means of ports
Low … define the types of interaction between system/components/functions by means of signals
Low … specify the boundary of the system dynamically
Low … specify different configurations of the system based on different compositions.
Low … define Which logical components are deployed in which physical components
Low … define the life time of the physical and logical components for replacing purposes
Failure Logic High … perform Fault Analysis modularly on the basis of the system Design
As a safety engineer, I am able to… High
… select one of many techniques (FMEA/FTA/Markov) to perform the fault analysis for functions/systems/ components
High … create and analyze heterogeneous fault analysis models
High … determine the causes that lead to the occurrence of an undesired event.
Low … specify the failure logic propagation between systems/components/functions
Low … specify Failure modes for Function/system/component ports
Low … analyze Hazards by defining a relationship to output failure modes
Dependability
As a requirements engineer I am able to High
… specify requirements for systems/components/functions and other design artifacts
High … distinguish between safety and non-safety critical requirements and measures
High … identify mechanisms to avoid, tolerate, remove, etc. system faults during development as well as during operation times.
High … document relevant contextual information with regard of the development of the system. E.g. standards
High … organize requirements modularly
High … perform hazard and risk assessments
Low … identify situations in which the system can cause harm
Low … evaluate the criticality of the possible failures of the system
Low … link requirements with identified failures in the fault analysis Table 1. Basic ODE Uses
ODE Profile V1
Page 11 of 24
4.2 EMF as ecosystem for DDI exchange
In the context of Model Driven Engineering (MDE), there are a variety of supporting tools, which are mostly
based on the Eclipse IDE. The Eclipse Modelling Framework (EMF) is an established, well-known framework
for modelling, upon which numerous MDE tools are built. EMF provides a modelling language called ECore,
which is also widely used by MDE tools and practitioners. In addition to ECore, EMF provides a framework
to generate model codes and editors in Java based on meta-models defined in ECore.
Models produced by EMF are naturally supported by the majority of MDE tools relevant to EMF. For
example, for model validation, the Eclipse OCL project provides support for model validation on EMF
models only. The Epsilon platform provides a variety of model management operations such as model
validation, model to model transformation, model to text transformation, model merging, etc. The Eclipse
ATL Transformation Language (ATL), supports model-to-model transformation capabilities for models
defined in EMF.
Therefore, support for querying, validating, merging, transforming EMF models is readily available for the
Eclipse ecosystem. This provides a good foundation for the DEIS project for its ODE concepts, in the sense
that DDIs (instances of ODE) can be validated, merged at design time/runtime in an automated manner.
In EMF, model elements are organized in Packages, which can import other packages to use the model
elements defined in the imported packages. The ODE components should be modelled into different
packages on a need-to basis to promote modularity, flexibility and re-use. Thus, instead of producing a large
meta-model, the ODE will be a cluster of packages, each of them capable of handling one specific domain
(e.g. the failure logic package constructs failure logic models only but can be used in conjunction with the
architecture package). At the same time, the ODE should keep existing standards intact, thus the importing
mechanism is used to import the SACM package into the overall package, in the sense that system
assurance cases are independent, which are created using SACM.
For the upcoming implementations the concrete exchange mechanism still need to be discussed. In EMF,
models are typically exchanged in either textual or binary XMI format (an extension of XML). However, one
may wish to make use of other exchange mechanisms. This shall be investigated later for the DEIS project
due to requirements in the area of intellectual property protection. Here is an abstract example of the
format:
<DependabilityPackage metaData=„contentDescriptor“ version=„1.0“>
<AssuranceCasePackage>
<TerminologyPackage ref=<systemDesign>>
</AssuranceCasePackage>
<SystemDesignPackage>...</SystemDesignPackage>
<FailureLogicPackage>...</FailureLogicPackage>
<xx>...</xx>
</DependabilityPackage>
ODE Profile V1
Page 12 of 24
5 Demonstrators: State of ODE implementation in the DEIS Tools This Section provides an overview regarding the implementation of the ODE by the corresponding DEIS
tools. It is important to note that not every tool presently implements the complete ODE. ACME is focusing
on the assurance case part and ComposeR and HiP-HOPS are focusing on the failure logic modeling part.
safeTbox implements both to a certain extent.
5.1 ACME
ACME is a graphical editor to create/edit SACM models. For ACME, we provide an EMF (Eclipse Modeling
Framework) based implementation of SACM. ACME provides editing facilities for AssuranceCase,
Argumentation, Artifact and Terminology creations, and then finally output to an EMF based SACM model.
5.1.1 Assurance Case Editing
ACME provides a transitional solution for system safety engineers to construct SACM models (and SACM
compliant models) using the Goal Structuring Notation (GSN). The GSN meta-model used in ACME is an
extension to ACME so all elements in ACME can be created (Such as AssuranceCasePackages,
ArtifactPackages, TerminologyPackages in SACM, as well as Modules in GSN).
5.1.2 Argumentation Editing
ACME provides a tooling to create GSN models in its Module editor. The full specification of GSN can be
found at (http://www.goalstructuringnotation.info/).
5.1.3 Artifact Editing
In the ArtifactPackage editor, ACME provides the means to create all SACM Artifact elements. For Artifact,
the user can link to an external material to organize the evidence of the structured argumentation. See
Figure 4.
Figure 4 ACME Artifact Editing
ODE Profile V1
Page 13 of 24
The newly created Artifact can then in turn be referenced from the structured argumentation. In this
example, a test report for Component X is organized in an Artifact, and then referenced by Sn1 in the
argument package. See Figure 5.
Figure 5 ACME Artifact Referencing
5.1.4 Terminology
But what is System really? The Terminology provides the link to the System. In ACME, the user can define
their terminologies as shown below:
Figure 6 ACME Terminology Asset Creation
ODE Profile V1
Page 14 of 24
After the creation, the term System bears the meaning that it points to a UAV system model in a local file.
This term can then in turn be used by the GSN Goal G1. The keyword System (now in curly brackets) refers
to the UAV system model, which is organized in the Terminology package and can be accessed via the link
stored in the terminology package.
Figure 7 ACME Using a Terminology Term in the argumentation
In this sense, links among the system information, the evidence and the structured argumentation have
been created so that the SACM model in a sense weaves all the information into a system assurance case.
5.2 ComposR
ComposR is a tool to create and maintain system as well as safety and reliability models. Since ComposR is
based on a commercial UML/SysML modeling tool, such as MagicDraw from NoMagic or Enterprise
Architect from Sparx, system modelling is possible using UML, SysML or any domain-specific extensions
(see screenshot Figure 8). Moreover, ComposR enables the creation of dependability analysis models,
which can be interlinked with the system model. These models may be composed of (Component) Fault
Trees and Markov Chains which can be analyzed in a qualitative and quantitative way using industrial-grade
analysis tools such as ZUSIM or Isograph FT+.
ODE Profile V1
Page 15 of 24
Figure 8 System modeling using ComposR
ComposR implements FLM in form of the Component Fault Tree (CFT) methodology (Kaiser, Liggesmeyer,
& Mäckel, 2003) for large-scale industrial projects (see screenshot Figure 9), e.g. using specific extensions
(Höfig, Zeller, & Heilmann, 2015). Since ComposR allows the creation of safety/reliability analysis models in
a compositional way, safety artifacts can be associated with elements in the system design and reused
systematically in different contexts. Hence, enabling integrated safety analysis to leverage the benefits of
model-based development in context of safety-relevant systems (Zeller & Höfig, 2016).
Figure 9 FLM modeling in form of a Component Fault Tree (CFT) using ComposR
ODE Profile V1
Page 16 of 24
Based on the Component Fault Tree model created using ComposR either a qualitative Fault Tree Analysis
(FTA) in the form of a minimal cut set analysis or a quantitative FTA can be performed using common
algorithms or tools.
Moreover, we implemented a UML-profile to model safety argumentation in the Goal Structuring Notation
(GSN). Figure 10 shows a screenshot of a GSN modeled in ComposR. Since the system and its failure logic
are also available in form of models, specific model elements (or entire models) can be linked with the text
in the GSN model to enable navigation through the safety argument.
Figure 10 Modeling GSN using ComposR
The ComposR is used in WP 5 to model the industrial use case 3 (see Deliverable D5.1). We plan to migrate
ComposR to the ODE meta-model currently developed in WP 3 and enable the synthesis of DDIs within the
DEIS project.
5.3 Hip-Hops
The HiP-HOPS reliability analysis tool is capable of automating Fault Tree Analysis (FTA) and Failure Modes
and Effects Analysis (FMEA), based on an architectural model of a user’s system. This system model is
annotated by the user with component failure logic behavior, which enables the above analyses and more,
e.g. temporal fault tree analysis, architectural optimization, automatic SIL allocation. Currently, HiP-HOPS
is integrated with two commercially available modeling environments:
• MATLAB/Simulink (https://uk.mathworks.com/products/simulink.html)
• SimulationX (https://www.simulationx.com).
ODE Profile V1
Page 17 of 24
HiP-HOPS and more detailed documentation is available online at https://hip-hops.eu, with commercial
and evaluation versions available to download. Figure 11, shows a system model in the MATLAB/Simulink
environment, with the integrated HiP-HOPS menu alongside it. Through this menu, local failure behavior
for the individual system elements can be set, as well as model-wide properties e.g. hazard information.
Figure 11 HiP-HOPS Modeling with MATLAB/Simulink
In Figure 12, the detailed results of the automatic analysis are shown. Specifically, the minimal fault tree
that describes the relationship between component and system failure is seen on the left side. From this
view, the minimal cut sets can also be reviewed via the relevant tab. The right side of Figure 12 depicts
FMEA tabular data, listing the systemic effects of individual component failures.
ODE Profile V1
Page 18 of 24
Figure 12 FTA with HiP-HOPS
Our initial efforts to integrate with the ODE can be found in (Retouniotis, et al., 2017). In the mentioned
publication, we describe extensions to the HiP-HOPS meta-model that enable GSN-style safety
argumentation to be generated based on HiP-HOPS safety analyses. The link between safety argumentation
and analysis established by this process will support DDI generation and integration in the upcoming
development stages. Currently, the meta-model presented in the above publication is being adapted to
ODE proposals discussed between the partners. The aim is to support bi-directional translation from HiP-
HOPS to ODE data structures.
5.3.1 ODE Integration with HiP-HOPS
By design, the ODE shares much common ground with that used internally by HiP-HOPS. Semantic
differences that remain can be addressed by performing a model-to-model (M2M) transformation between
the ODE and HiP-HOPS meta-models. Such a transformation produces an equivalent model from the source
(expressed in the source meta-model) in terms of the target meta-model.
HiP-HOPS input and output is provided in XML format. XML schema definitions (XSD files) are available for
both input and output formats of HiP-HOPS. Past approaches have made use of model-to-text (M2T)
transformations to convert from HiP-HOPS-compatible meta-models into compatible XML input. This
separated the transformation into two steps, a M2M between the source and an intermediate, HiP-HOPS-
compatible meta-model, and then a M2T transformation between the intermediate meta-model and the
XML input/output format.
For DEIS, our planned prototype tool for parsing and serializing ODE models into and from HiP-HOPS will
integrate the two steps described above, using the open-source library EMF4CPP (Catedra SAES (2010)).
ODE Profile V1
Page 19 of 24
EMF4CPP allows C++ code to parse models conforming to Ecore meta-models (such as the ODE instances)
as well as serialize such models. Once the transformation process is complete, HiP-HOPS can be invoked to
perform the required dependability analysis and its output serialized back into the ODE model. Figure 13
visually describes the above process.
Figure 13 ODE-HiP-HOPS integration process
5.4 safeTbox™
safeTbox is a modeling and analysis tool created with the goal to support dependability engineers in the
development and certification of safety critical systems. It has been developed as an extension of the
commercial tool Enterprise Architect (EA), which supports the standard UML and SysML 1.4 constructs.
safeTbox extends EA by providing a set of specialized modeling languages to support primary safety-
engineering activities. Two aspects characterize most of the techniques integrated in safeTbox: modularity
and component integration. With this, safeTbox aims at facilitating maintainability and reusability of
systems, as well as supplier-OEM interaction and integration of third-party components.
In the current state of the ODE, safeTbox implements quite well the architecture package. Thanks to its
abstract compositional approach, safeTbox can be used to model systems, functions, logical components
and hardware devices similarly as it can be done using SysML. Moreover, the definition of interfaces (ports)
as well as the specification of the interaction between entities (signals) is also possible as defined in the
ODE meta-model, see Figure 3. In the next figure, an example of a network of logical components can be
observed.
ODE Profile V1
Page 20 of 24
Figure 14 Example of a component network modeled with safeTbox.
In the area of Failure logic modeling, safeTbox supports the ODE in the sense that it has an implementation
of component fault trees (Domis, D (2005)), which follow similar concepts with respect to the definition of
compositional failure logic, as well the definition of internal and interface failure modes. In the next figure,
it is possible to see an example of a Component fault tree modeled with safeTbox. Currently there are no
FMEA or Markov capabilities. It is also possible to associate design artifacts (e.g. systems, ports) with failure
modeling artifacts (e.g. failure model, interface failure modes).
Figure 15 Example of a component fault tree.
With respect to the dependability package only the definition of requirements, its modular composition
and refinement is being supported so far. Currently, a flexible implementation of the Goal Structuring
Notation (GSN) supports these features. This implementation was engineered during 2017. The
ODE Profile V1
Page 21 of 24
implementation has followed the standard definition of the technique, which makes it therefore fully
compatible with other tools following the same standard see Figure 16. Other sub-packages, e.g. domain,
and HARA have been still under discussion lately. For this reason, no support has been implemented yet.
Figure 16 Example of a GSN
Similarly as explained for the Hip-Hops tool, the next steps in the development of safeTbox include the
implementation of the import and export of models into the ODE exchange format.
ODE Profile V1
Page 22 of 24
6 Summary and Outlook
In this document, we presented the status of the development of the ODE. Initially, an abstract version of
the meta-model was used to show the more important blocks. This was necessary in order to reduce the
complexity of the explanations and make the concept easier to comprehend for stakeholders outside from
DEIS. In a further section, we introduced the goals that the ODE should tackle from the tool perspective,
together with the reference work used as input for its definition and refinement. In chapter 4, details of
the meta-model as well as of the technology used for its creation were provided. In chapter 5, the current
tool implementations and their support of the ODE was presented. Until now, different members of the
consortium have implemented the tools in isolation (tools are mostly freely accessible. See download links
in the respective section). This is reflected in the overall support of the ODE, in that each tool supports only
a subset of all specified features. This is partially desired in DEIS, since this reflects the current state of the
practice; it cannot be expected that tool-vendors support entirely all aspects in the development of
dependability systems. In this sense, the ODE plays the role of the binding mechanism that would allow
stakeholders to cooperate based on a common language, and serve as basis of the tool interoperability
concept. With this initial version of the ODE, the immediate tool implementation will provide mechanisms
for the exchange of information between the existing tools. Therefore, each partner will provide
import/export functionalities between their own tool specific format and ODE.
According to the planned activities our coming efforts are going to be invested in the deliverable 4.2, in
which the semi-automated synthesis of development time DDIs should be supported.
ODE Profile V1
Page 23 of 24
7 References
Biggs, G., Sakamoto, T. & Kotoku, T. Softw Syst Model (2016) 15: 147. https://doi.org/10.1007/s10270-
014-0400-x
Catedra SAES. (2010). EMF4CPP. Retrieved from Catedra SAES:
https://www.catedrasaes.org/html/projects/EMF4CPP/EMF4CPP.html
Dave Steinberg, Frank Budinsky, Marcelo Paternostro, Ed Merks, EMF: Eclipse Modeling Framework, 2nd
Edition, Dec 16, 2008, ISBN-10: 0-321-33188-5
Feiler, P.H., Gluch, D.P., Hudak, J.J.: The Architecture Analysis & Design Language (AADL): An Introduction.
Tech. rep., Software Engineering Institute, Carnegie-Mellon University, Pittsburgh (2006).
Höfig, K., Zeller, M., & Heilmann, R. (2015). ALFRED: A Methodology to Enable Component Fault Trees for
Layered Architectures. 41st Euromicro Conference on Software Engineering and Advanced Applications
(SEAA)
Jose Luis de la VaraRajwinder Kaur Panesar-Walawege (2013): SafetyMet: A Metamodel for Safety
Standards, MODELS 2013. Lecture Notes in Computer Science, vol 8107. Springer, Heidelberg
Kaiser, B., Liggesmeyer, P., & Mäckel, O. (2003). A new component concept for fault trees. SCS '03:
Proceedings of the 8th Australian workshop on Safety critical systems and software, (S. 37 - 46).
Montecchi, L., Lollini, P., Bondavalli, A.: Dependability concerns in model-driven engineering. In:
Object/Component/Service-Oriented Real-Time Distributed Computing Workshops (ISORCW), 2011 14th
IEEE International Symposium on, pp. 254 –2 63 (2011).DOI 10.1109/ISORCW.2011.32
Object Management Group - UML, Unified Modeling Language (UML) specification, Version 2.5.1,
https://www.omg.org/spec/UML/About-UML/, 2017
Object Management Group - SysML, System Modeling Language (SysML) specification, Version 1.4,
https://www.omg.org/spec/SysML/1.4/About-SysML/, 2015
Oleg Lisagor, (2010): Failure Logic Modelling: A Pragmatic Approach, PHD thesis, University of York
Peter Fenelon, John A. McDermid, (1993):An Integrated Toolset For Software Safety Analysis, Journal of
Systems and Software.
Pohl, K., Broy, M., Daembkes, H., Hönninger, H. (2016): Advanced Model-Based Engineering of Embedded
Systems - Extensions of the SPES 2020 Methodology, springer
Ryman, A. G.; Hors, A. J. L.; and Speicher, S. 2013. OSLC resource shape: A language for defining
constraints on linked data. In Bizer, C.; Heath, T.; Berners-Lee, T.; Hausenblas, M.; and Auer, S., eds.,
Proceedings of the WWW2013 Workshop on Linked Data on the Web. http://ceur-
ws.org/Vol996/papers/ldow2013-paper-02.pdf.
ODE Profile V1
Page 24 of 24
Höfig, K., Zeller, M., & Heilmann, R. (2015). ALFRED: A Methodology to Enable Component Fault Trees for
Layered Architectures. 41st Euromicro Conference on Software Engineering and Advanced Applications
(SEAA).
Kaiser, B., Liggesmeyer, P., & Mäckel, O. (2003). A new component concept for fault trees. SCS '03:
Proceedings of the 8th Australian workshop on Safety critical systems and software, (S. 37 - 46).
Retouniotis, A., Papadopoulos, Y., Sorokos, I., Parker, D., Matragkas, N., & Sharvia, S. (2017). Model-
Connected Safety Cases. In M. Bozzano, & Y. Papadopoulos (Hrsg.), Lecture Notes in Computer Science
(Bd. 10437). Cham, CH: Springer. doi:https://doi.org/10.1007/978-3-319-64119-5_4
Zeller, M., & Höfig, K. (2016). INSiDER: Incorporation of system and safety analysis models using a
dedicated reference model. 2016 Annual Reliability and Maintainability Symposium (RAMS).