Reference model based design of tool landscapes for rail infrastructure engineering.

Holm, Timo ; Lehmann, Othmar ; Horn, Stefan 等

Abstract: The domain of rail automation will in the near future face drastic changes. For instance the use of a standardized electronic representation of Signaling Planning will become an integral part of the communication of customer requirements. These changes pose challenges for the manufacturers of rail automation systems, who must adapt their engineering tools accordingly. In order to do so, these challenges have been analyzed as part of this contribution. The analysis has been used to derive a reference model for the integrated, tool-based engineering of rail automation systems which were described using UML component model. It is applied today at Siemens AG to evaluate engineering tools for rail automation as well as to design entire engineering tool landscapes from scratch.

Key words: reference, model, rail, infrastructure, engineering

1. INTRODUCTION

The business with rail automation plants in general and electronic interlocking in particular faces drastic changes. Driven mainly by market forces, the electronic representation of customer requirements--more accurately the electronic representation of Signaling Planning--is introduced as integral part and interface of the communication between customer and plant manufacturer. The procedural changes needed in the engineering process to harvest the potentials of this particular as well as other trends are not fully understood yet.

This contribution gives an overview of these challenges manufacturers of rail automation solutions must face and aims to help evaluate and design engineering tools and entire landscapes thereof by introducing a reference model of an integrated engineering tool landscape for rail interlocking systems.

2. TRENDS IN RAIL AUTOMATION ENGINEERING AND ENGINEERING LEVERS

Unique for the domain of rail automation is the simultaneous occurrence of three major trends:

* Electronic representation of Signaling Planning--This trend is driven mainly by market forces. Standardized modeling languages to represent parts of the customer requirements are introduced as integral part and means of communication between customer and plant manufacturer. This trend bears a lot of potential for increasing productivity, since it not only disposes of a major media brake but also enables all stakeholders to push tool support for consistency checking and overall automatization efforts. One prominent example for standardized data formats in this context is railML (Nash et al., 2010), which is currently extended in order to cover interlocking applications.

* Test automation--An interlocking system as result of rail automation engineering activities usually needs to comply with the highest safety integrity levels (level 4) of IEC EN 61508 (IEC EN 61508, 2010). Therefore a lot of effort is put into testing individual engineering artifacts as well as the their interplay. In order to optimize this major cost driver the automation of major parts of these activities is evaluated.

* Mechatronic modeling & integrated engineering data management--The concept of mechatronic objects as discipline-spanning entities representing reusable units in the context of plant modeling is often paired with the integrated and lifecycle phase spanning management of engineering data. This trend has several origins, for instance the fields of model based engineering, mechatronic modeling and holistic plant data management. In order to support the collaboration of all disciplines involved, additional functionalities are needed. For instance concepts like users, roles and rights management as well as methods to represent engineering processes and workflows (see figure 1).

[FIGURE 1 OMITTED]

However the levers to harvest efficiency potentials in engineering are well known and accordingly described in system engineering theory (Loewen et al., 2005):

* Integration of disciplines--usually different disciplines are involved in designing a plant. Examples are electrical engineering and interlocking logic programming. Activities associated with these disciplines are executed in the same plant lifecycle phase by a multitude of engineers in parallel. Integration of disciplines targets to support those engineers with communicating changes affecting adjoining crafts.

* Plant lifecycle integration--the manufacturing process phases of a plant may not be conceived as independent from one another. Instead those plant lifecycle phases need to be designed in a continuous manner in order to leverage the possible benefit potentials. The artifacts (outputs) of one phase for instance should ideally be fitted to support the processes of the following phase.

* Reuse--the results of an engineering process, usually referred to as engineering artifacts, are often of a recurring pattern. In order to save time and effort, the reuse of those artifacts--within one and the same project but also in a project-spanning manner--is an important benefit lever.

* Coverage--artifacts which are to be reused within a project context ideally cover as much as possible: They span multiple disciplines and are--generally speaking--big, which means they cover as many requirements and functions as possible while simultaneously being flexible and of universal applicability.

[FIGURE 2 OMITTED]

The interrelations between the four levers mentioned is depicted in figure 2.

3. REFERENCE MODELING

In order to be able to sufficiently consider above mentioned trends when designing an engineering tool landscape, knowing those levers is not enough. Additional information regarding their relevance and place of action is need. In order to gather this information, a reference model based approach was used. Result of these design activities, which were based on the methodology described by Probst in (Probst, 2003), is a generic engineering tool landscape for the domain of rail infrastructure automation. It is supposed to serve as common practice and is currently being adopted by Siemens Rail Automation.

Figure 3 depicts the mentioned architecture, which consists of three functional component-groups, that can be assigned to three corresponding layers:

* Electronic representation of Signaling Planning--In the future an external planer--usually mandated by the customer--will provide a customer file which contains a standardized, electronic representation of parts of the customer requirements. Since a lot of those standards, some country-specific, some customer-specific, will have to be supported, a conversion into a homogenous, uniform representation is necessary. This representation enables the supplier to automatize parts of the plan checking process using rules to support the human plan checker.

* Integrated engineering data management--Assuming the plan checking process was completed successfully, the electronic representation of signaling planning is transferred into the data model sub-component of engineering data management. Ideally it predetermines at least parts of the finished models used by the component Generator in order to produce engineering artifacts like BOMs, plans, PLC code or user documentations. Accessing this data model must happen in a controlled manner. Therefore components for the representation of users, their roles within the engineering process and permissions on (parts of) the data model must exist. However changes made to the engineering data model must not corrupt or leave it in an invalid state. Therefore a set of rules running inside a rule engine are triggered every time changes are made. Changes are made either by the engineers using authoring components, so-called external, pre-existing and internal editors or by a component called Automation runtime environment. Since modification patterns to the data model are highly standardizable, this component offers a way to unburden engineers from this type of activity, e.g. mass-renaming or mass-duplicating of elements. These activities as well as users, roles & rights and also the schema, which defines the underlying structure of the data model, have to be managed by an administrator. An additional component targets the reuse-lever (Loewen, 2005); the product repository contains information of pre-defined sub-models--so-called products the final, project specific engineering data model can be built from. Usually product managers are put into place to manage those reusable artifacts.

* Test environment--When the engineering activities of an interlocking project come to an end, above mentioned engineering artifacts need to be inspected, tested and approved by a certified technical inspection authority in order to meet regulatory requirements of local government agencies or bodies. To support the corresponding processes three components are necessary. A test case generator automatically derives tuples of stimuli and expected results and forms test cases, which are gathered in catalogs and passed on to a component called test manager. The test case generator uses information taken from the electronic representation of signaling planning, which has not yet been modified in any way as a result of the engineering process. This is necessary since results of the engineering process itself are to be tested. This requires a separate approach for the generation of a reference standard.

[FIGURE 3 OMITTED]

4. CONCLUSION & OUTLOOK

In order to design an engineering tool landscape for rail automation systems that considers above mentioned trends, all reference components have to be covered by one or more actual information systems. To decide which design alternatives might be better or worse, additional evaluations have to take place (Holm et al., 2008). The reference architecture however is essential to determine what evaluation criteria (e.g. software quality) are relevant for which component.

5. REFERENCES

Holm, T.; Luschmann, C.; Delgado, A. & Amberg, M. (2008) A Reference Model Based Approach for the Evaluation of Industrial Plant Service and Asset Management Tools, Annals of DAAAM for 2008 & Proceedings of the 19th International DAAAM Symposium, Katalinic, B. (Ed.), pp. 601-602, 9-771726-967007,Trnava (Slovakia), October 2008, DAAAM International, Vienna (Austria)

IEC EN 61508 (2010). Functional safety of electrical/electronic/ programmable electronic safety-related systems--Part 0: Functional safety, IEC Swiss, 2-8318-7816-0, Geneva

Lowen, U.; Bertsch, R.; Bohm, B.; Prummer, S. & Tetzner, T. (2005) Systematization of industrial plant engineering, atp --Automatisierungstechnische Praxis, Vol. 50, I. 4, pp. 54-61

Nash, A.; Hierlimann, D.; Schuette, J. & Krauss, V.P. (2010). RailML--a standard data interface for railroad applications, In: Timetable Planning & Information Quality, Hansen, I., (ed.), 3-10, WIT Press, 1-84564-500-6, Ashurst, Southamption

Probst, C. (2003). Referenzmodelle fur IT-Service-Informationssysteme, Logos Verlag, 978-3832501617, Berlin