EP3061044A1

EP3061044A1 - Method for the generation of conjoint domain models for system-of-systems

Info

Publication number: EP3061044A1
Application number: EP14796439.9A
Authority: EP
Inventors: Deepak Dhungana; Andreas Falkner; Alois Haselböck
Original assignee: Siemens AG Oesterreich
Current assignee: Siemens AG Oesterreich
Priority date: 2013-10-24
Filing date: 2014-10-22
Publication date: 2016-08-31
Also published as: WO2015059178A1

Abstract

Method for the generation of conjoint domain models for system-of-systems Subject of the present invention is a method for the generation of conjoint domain models for system-of-systems comprising the steps of: definition of a portfolio of component systems in various versions, selection of some of these component systems and ensuring their compatibility to form a consistent system of system, Automatic generation of conjoint domain models applying pull injection, where the inheriting class injects features from another domain model into its own model, and push injection operators where the inheriting class injects new features into a class definition of another model. The invention enables a light-weight (i.e., easy-to-use) approach for pursuing development, integration, and interoperability of individual systems in a System-of-systems context.

Description

Beschreibung / Description

Method for the generation of conjoint domain models for sys- tem-of-systems

Software solutions in complex technical environments, such as railway control systems or power plants, are assemblies of heterogeneous components, which are very large and complex systems themselves.

In such environments, monolithic engineering approaches are often not applicable, due to the interdisciplinary nature and the sheer size and complexity of the projects. Large-scale systems such as power plants, industrial production sites or railway interlocking systems are designed and constructed by combining many components and subsystems and can be seen as so called system-of-systems .

All involved component systems have to be inter-operable, i.e., they need to communicate, exchange data, and be

aligned, consistent and compatible to each other.

Due to the heterogeneity of the used tools concerning formal^¬ isms, languages and formats, the necessary integration of such cross-domain networks of heterogeneous systems into one architecture introduces a crucial challenge for project suc^¬ cess. The data models of the component systems, referred to as domain models in this description must be consolidated. It requires rigorous tool integration methods to ensure model compatibility and re-usability across tool boundaries as well as to manage change and model evolution in a collaborative environment. Modelers must be able to express and enforce structural and behavioral requirements of the target platform architecture. Data constraints in integrated environments pose additional maintenance challenges, as they must be ad^¬ justed to changes during the system's lifetime. From state of the art literature, there are approaches known, how to deal with similar challenges. As examples shall be mentioned : P. A. Bernstein and S. Melnik. Model management 2.0: manipu^¬ lating richer mappings. In ICMD, 2007.

H. Bruneliere, J. Cabot, C. Clasen, F. Jouault, and J.

B^'ezivin. Towards model driven tool interoperability: Bridg- ing eclipse and microsoft modeling tools. In ECMFA, pages 32- 47, 2010.

G. Hohpe and B. Woolf. Enterprise Integration Patterns: De^¬ signing, Building, and Deploying Messaging Solutions. Addi- son-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003. ISBN 0321200683.

Jossic, M. Del Fabro, J. -P. Lerat, J. Bezivin, and F.

Jouault. Model integration with model weaving: a case study in system architecture. In Systems Engineering and Modeling, 2007. ICSEM '07. International Conference on, pages 79-84, 2007. doi: 10.1109/ICSEM.2007.373336.

A. Schurr and H. Dorr. Introduction to the special sosym sec- tion on model-based tool integration. Journal on Software and Systems Modeling (SoSym), 4(2), May 2005.

The known approaches usually require highly trained special^¬ ists to use them effectively. Due to the lack of easy-to-use alternatives, ad-hoc processes such as point-to-point inte^¬ gration can be observed in reality. To deal with the obvious drawbacks (exponential increase in complexity, single points of failure), open integration strategies such as enterprise service bus architectures have been proposed. These allow loose coupling between independent systems, which is often not adequate in practical settings to prevent redundancy, in^¬ consistency or ambiguity in shared data. The task of the invention is to present a generative approach that enables reconciliation of a common platform based on reusable domain models of the involved systems.

This task is performed with a method according to claim 1.

An advantageous embodiment of the invention is described in claim 2.

The invention enables a light-weight (i.e., easy-to-use) ap^¬ proach for pursuing development, integration, and interoperability of individual systems in a System-of-systems context. The invention will be described with reference to the follow^¬ ing drawings .

Fig. 1 shows an example of a system portfolio in the rail au^¬ tomation .

Fig. 2 shows an overview of the method for generating a con- joint model of involved systems in a system-of-systems .

Fig. 3 shows a CSL meta model

A rail automation portfolio as shown in Fig. 1 typically comprises a large, heterogeneous set of independent systems. Fig. 1 shows only some examples of different rail automation systems: signaling hardware (SIG), railway control center (RCC) , operator terminal (OT) , European train control system (ETCS), and radio block center (RBC) . These systems represent the reusable components (i.e., the portfolio) which can be combined as needed in a system-of- systems context as long as the specified dependencies are satisfied . A concrete rail automation solution contains a selected sub^¬ set of such systems, depending on the needs of the customer and the favored technology. For example, Figure 1 sketches three such solutions in three different countries. Different component systems are integrated into one System-of-systems based on the country-specific requirements.

Based on such a system-of-systems , different installation (for different railway stations) can be configured and de^¬ ployed. Each component system must be configured according to its special, partly significantly differing requirements, e.g. concerning exact locations of signals, concrete types of elements, detailed hardware wiring, monitor screen layout in control centers, etc. Therefore, each has its highly- specialized engineering tool (configurator) . A modeling framework is needed for collaborative design, implementation and maintenance of domain models and configurator tools for the whole rail automation portfolio, enabling a seamless in- terplay of configurators for more efficient and integrated systems in product deployments. These methods are of general nature and applicable to industrial domains other than rail automation . Often, domain models of individual systems are not designed as part of a comprehensive super-model, but are built and maintained separately by different groups of experts. The re^¬ sult is a set of independent models or tools, each special^¬ ized for a different component system in the portfolio.

However, the stakeholders responsible for modeling these sys^¬ tems must collaborate and communicate with each other to achieve a common understanding of the concepts. In many cas^¬ es, the domain models partly overlap (representing the same concepts from different perspectives) . Different kinds of de^¬ pendencies and constraints exist between the concepts of dif^¬ ferent models. Therefore, supporting collaborative

modeling is a key requirement in this context. Industrial state-of-practice shows that inter-system dependencies are usually resolved by data-exchange interfaces, using pro^¬ prietary APIs and tools. For the rail automation domain there are efforts to standardize such interfaces, e.g., by XML- based RailML. In any case, the corresponding architecture is a complicated network of engineering tools, highly cross-linked by hard-to- maintain interfaces. The users of the tools must obey a com- plicated error-prone process, e.g., when to configure which component and how to transfer data to which subsequent tool.

An alternative to such a complex tool architecture should therefore support distributed modeling of individual systems. The users should have the possibility to define shared con^¬ cepts or to reuse concepts from other systems.

One of the toughest challenges in system integration is deal^¬ ing with relationships between the participating systems. In System-of-systems context, the systems are intrinsically in^¬ dependent of each other, but dependencies arise if the sys^¬ tems are to be integrated. Although a system can have depend^¬ encies to many other systems, not all of them need to be ac^¬ tive in a concrete System-of-systems - i.e., a cross-system dependency is only enabled if all its components are selected in the System-of-systems . Such cross-system dependencies can be structural dependencies (associations) between classes of two component systems, or reasoning expressions such as con^¬ straints or rules. In the example presented in Fig. 1, these dependencies are depicted in textual form - the lines between these descriptions and model elements show the involved com^¬ ponent systems .

First dependency Dl : Class hierarchy across systems: An RBC signal is the same as an ETCS signal, however needs an addi^¬ tional attribute for the RBC id. This could be seen as a spe^¬ cialization (inheritance hierarchy) that goes beyond a system boundary . Second dependency D2 : Implementation of foreign concepts:

Signals and tracks from ETCS and RCC components can be dis^¬ played in OT (e.g. by implementing the IElement interface) . Third dependency D3 : Conditional associations: If signaling hardware is available, every signal lamp in RCC has a connec^¬ tion to its controlling module in SIG. This can be realized by an association between the two components. Note that this association does not exist if RCC and SIG are not used to^¬ gether .

Fourth dependency D4: Consistency of concepts: Both the tools RCC and ETCS have a representation of track length, but from different sources (read from a paper plan vs. measured in the field) . Automated processes should check if the dif^¬ ferences of their values lie within an allowed range.

The possibility to define or automatically derive such cross- system dependencies is vital for the design of a system port^¬ folio. Moreover, the target tool platform must be able to process them.

In the proposal phase of a project, it is difficult to esti- mate the costs for setting up the necessary toolset for engineering and verification because of the heterogeneous land^¬ scape. In the realization phase, component systems along with their models and tools must be selected and integrated. Ap^¬ propriate processes must be set up to control planning, engi- neering, and verification activities.

An automated or semi-automated selection and combination of the different component systems for a concrete project is needed to optimize costs and quality. The conjoint model shall minimize redundancies (to avoid duplicated and possibly conflicting user input) and avoid inconsistencies within and between models. Apart from that, models may exist in differ^¬ ent versions and the engineers must be supported in selecting an appropriate one. The key requirement in this context is therefore supporting automated consolidation and reconcilia^¬ tion of selected portfolio models and versions to a single, non-redundant model best-suited for the required variant. In addition to the model, tools comprise code for reasoning (rules, constraints), for the user interface, for generating output in various formats, etc. It must be ensured either that this code is consistent to the conjoint domain model or that it is adapted automatically so that it will work proper^¬ ly on the target tool platform. The target tool platform is the "host" of the system-of-systems , which coordinates the individual systems based on the conjoint domain model. Building up a set of engineering tools for the different products is an expensive and long-term task. Instead of cre^¬ ating the whole system portfolio from scratch, step-to-step modernization of the engineering tool landscape may be an ef^¬ fective strategy. Therefore, a powerful platform must support the integration of existing tools: legacy tools as well as third-party tools. Systems provided by an external supplier are more difficult to adapt or integrate into a common model as access to them is restricted.

A conventional approach would be to equip legacy tools with interfaces to exchange data between them. This is not feasi^¬ ble as it ends in the aforementioned complex and hard-to- maintain tool network. In addition, proprietary interfaces between tools would hinder integration and should be avoided. The systems of a portfolio are continuously extended and maintained over years by different teams in various depart^¬ ments. Hence a monolithic approach where one modeling team is responsible for the whole set of models and their interplay is not possible. Necessary integration tasks are automated data exchange and migration, data merging, and consistency checking across tool boundaries.

An overview of the approach according to the invention is depicted in Figure 2. It consists of a modeling step and the deployment to a runtime platform:

Component systems 1 represent the set of available systems in the portfolio, which can be reused to create a System-of- systems as required in a certain domain. Modeling workbench 2 is a tool (called CSL Studio) to specify the domain models of the component systems, considering the dependencies among the systems.

Domain models 3 are the textual models of the concepts sup- ported by the component systems 1.

Requirements for System-of-systems 4 represent the set of criteria for selecting the systems from the portfolio re^¬ quired for building a System-of-systems .

System-of-systems configurator is a tool integrated in CSL Studio which ensures consistent and valid selection of input models and generates a conjoint model for the selected sys^¬ tems .

Conjoint domain model 6 represents a common model of the selected components which can be used in a target platform where all selected components are deployed.

Target platform 7 is an integration framework which is required for deploying the selected portfolio systems. This framework "interprets" the generated domain model to ensure consistency during deployment and runtime.

The data-structure of the involved systems is described using a domain-specific language designed to support the most com^¬ mon patterns required in industrial settings and to enable distributed modeling. The formal modeling language of the system models is CSL (Configuration Specification Language) . CSL is based on a standard object-oriented meta-model similar to Ecore or MOF, as shown in Fig. 3, and provides all state-of-the-art fea^¬ tures like packages, interfaces, classes with attributes of various types, associations between classes (uni- and bi^¬ directional) , inheritance and aggregation relationships, methods, constraints, rules. The individual domain models (cf . meta-class Component in Fig. 3) are formulated in CSL separately by different knowledge engineers. The following snippet shows the ETCS model from Fig. 1 in CSL notation. The syntax of CSL is mostly self-explanatory, so only key ele^¬ ments will be shown, that have been introduced to solve the model redundancy problem, i.e., similar classes which are part of different models but have overlapping properties. package etcs;

abstract class Signal {

attr name: String;

assoc onTrack [1..1 ] : Track;

}

class MainSignal extends Signal {

}

class ShuntingSignal extends Signal {

}

class Track {

attr lenMeasured: Int (unit="m") ;

assoc signals [0..*] : Signal oppositeOf onTrack;

}

Basic relationships between individual domain models are classical inheritance as well as association and aggregation. The following CSL snippet shows how the first dependency Dl in Fig. 1 could be solved by inheritance (an RBC signal is subclass of an ETCS signal) . By importing the required compo^¬ nent, it is possible to access classes in it. package rbc;

import etcs; class Signal extends etcs. Signal {

attr rbcld: String;

}

Basic domain concepts and features can be factored out into common basis models to be reused by the individual domain models. This library of common interfaces and classes is usu- ally provided by a supervisor team of knowledge engineers which have a general overview over all portfolio system mod^¬ els. The other standard way of using model data from other models is by association or aggregation, where a link to a basic class associates its structure and behavior to a system model class. The following CSL snippets are an insufficient way to represent second dependency D2 from the example of fig. 1 (tracks and signals in ETCS can aggregate up to four display elements in OT) : package ot;

enumeration ot.IconType {

track, signalLeft, signalRight

} class DisplayElement {

attr icon: IconType;

} package etcs;

import ot; abstract class Signal {

attr name: String;

assoc onTrack [1..1 ] : Track;

aggreg o!isplayElements [0..4] : ot . DisplayElement;

} class Track {

attr lenMeasured : Int (unit= "m") ;

assoc signals [0..*] : Signal oppositeOf onTrack;

aggreg displayElements [0..4] : ot .DisplayElement;

}

The weakness of the approach described above is that

DisplayElements know nothing about Tracks and Signals (the dependency can be described only in one direction) . It can be overcome by introducing a new concept : Pull injection is an operator for optional insertion of features from another domain model into a model. This injection only takes place if the referenced model is part of the final system-of-systems . If the referenced model is not used, no features are injected.

More formally, let CI be a so-called injection class in model Ml with features Fll ...Fin (a feature is either an attrib^¬ ute, an association, a function, a constraint, or a rule) . Let C2 be a class in model M2 with features F21 ...F2m.

Model Ml: class CI { Fll ... Fin }

Model M2 : class C2 isa Ml. CI? { F21 ... F2m } The isa operator is executed during conjoint model generation time and injects the features Fll ...Fin of CI into class C2, if and only if both models Ml and M2 are part of the System- of-systems. After the injection, class C2 contains the union of the features Fll ... Fin and F21 ... F2m class C2 { Fll ... Fin } U { F21 ... F2m }

Note that the union of features is built, i.e., features with the same signature are not duplicated. Features with the same name, but with different signature (e.g. attributes with dif^¬ ferent types) lead to an error during system model genera^¬ tion. The models must be corrected.

A class can pull injection information from more than one in- jection class. If the '?' is omitted at the injection opera^¬ tor, the model containing that injection class must be part of system-of-systems . The rest of this section demonstrates pull injection by a proper implementation of second dependency D2 with CSL.

Example: The operator terminal system OT has, among others, the following concepts (cf . Fig. 1) : package ot; enumeration ot.IconType {

track, signalLeft, signalRight

} class DisplayElement {

attr icon: IconType;

assoc element [1]: IElement

oppositeOf displayElements;

}

^injection

class IElement {

attr displayString: String;

aggreg displayElements [*] : DisplayElement;

}

The Qinjection annotation specifies that the properties of the class IElement may be injected into classes of other com^¬ ponents. The topology elements of the ETCS domain model rep^¬ resent the fact, that, if an operator terminal is present, the topology elements will have connections to the OT display elements and will have an additional attribute displayString by using the isa keyword. package etcs;

import ot; class Signal isa ot. IElement? {

attr name: String;

assoc on rack [1..1] : Track;

} class Track isa ot. IElement? {

attr lenMeasured : Int (unit= "m ") ;

assoc signals [0..*] : Signal oppositeOf onlrack;

} The following model is generated if systems ETCS and OT are together part of the planned System-of-systems : enumeration ot.IconType {

track, signalLeft, signalRight

} class ot . DisplayElement {

attr icon: ot.IconType;

assoc element [1]: ot . IElement oppositeOf o!isplayElements;

} interface ot . IElement {

} class etcs. Signal implements ot. IElement {

attr name: String;

assoc onTrack [1..1 ] : etcs. Track;

attr displayString: String;

aggreg displayElements [*] : ot . DisplayElement

} class etcs. Track implements ot. IElement {

attr lenMeasured : Int (unit= "m") ;

assoc signals [0..*] : etcs. Signal oppositeOf onTrack;

attr displayString: String;

aggreg displayElements [*] : ot .DisplayElement

}

The concept of pull injections looks very similar to standard implementations of interfaces. The main differences are: In^¬ jection declarations can be optional, allowing a flexible combination of different components to a conjoint model, and interfaces cannot have properties (like attributes or associ^¬ ation links) but only method declarations. Goal of the inven^¬ tion is to automatically generate a consistent conjoint model which is specifically created for a concrete SoS without any redundancies. The difference to the concept of traits in the programming language Scala are that pull injections are transformed to standard UML class features in the conjoint model and that this transformation is optional dependent on the existence of both involoved packages.

Another concept for an advanced interplay of system models is push injection, where properties of a class are injected into a class definition of another model. More formally, let CI be a class in model Ml with features Fll...Fln. The push injec^¬ tion operator Qoverride adds the features F21 ...F2m from within model M2 into model Ml:

Model Ml: class CI { Fll ... Fin }

Model M2 : @override class Ml. CI { F21 ... F2m }

When both model Ml and M2 are part of System-of-systems , class CI will have the following features: class CI { Fll ... Fin } U { F21 ... F2m }

If model M2 is not part of System-of-systems , class CI re^¬ mains unchanged. Note that the union of features is built, i.e., features with the same signature are not duplicated. Mismatching types lead to conflicts during model generation.

Example: First Dependency Dl implies that signals in RBC shall reuse those in ETCS - but class Signal in component ETCS has various subclasses for each different type of signal (main signal, shunting signal,...). Building subclasses of all those subclasses in RBC is not appropriate. The concept of push injection provides a simple and natural solution: The ETCS class Signal is overwritten (using the annotation

Qoverride) and extended in RBC: package rbc;

import etcs; @override

class etcs. Signal {

attr rbcld: String;

assoc rbc[l..l]: RBCSystem oppositeOf signals;

} class RBCSystem {

assoc signals [1..*] : etcs. Signal oppositeOf rbc;

}

For a System-of-systems with both components RBC and ETCS, the generated conjoint model looks like: class etcs. Signal {

attr name: String;

assoc onTrack [1..1 ] : etcs. Track;

attr rbcld: String;

assoc rbc[l..l]: rbc . RBCSystem oppositeOf signals;

}

class etcs . MainSignal extends etcs. Signal {

} class etcs . ShuntingSignal extends etcs. Signal {

} class etcs. Track {

attr lenMeasured: Int (unit="m") ;

assoc signals [0..*] : etcs. Signal oppositeOf onTrack;

} class rbc . RBCSystem {

assoc signals [1..*] : etcs. Signal oppositeOf rbc;

}

Claims

Patentanspruche / Patent claims

1. Method for the generation of conjoint domain models for system-of systems by use of a computer comprising the steps of :

- definition of a portfolio of component systems in various versions,

- selection of some of these component systems and ensuring their compatibility to form a consistent system of system,

- Automatic generation of conjoint domain models applying pull injection, where the inheriting class injects features from another domain model into its own model, and push injection operators where the inheriting class injects new features into a class definition of another model.

Method according to claim 1, wherein a conjoint domain model for a system-of systems in rail automation is generated .

Method according to claim 1 or 2, wherein, when building a final system-of-systems , only those features are in^¬ serted which are part of the actually used domain mod^¬ els.