Diagnosis for the digital interlocking

Diagnosis for the digital interlocking

The digital interlocking (DSTW) will be used by DB Netz AG in the next few years for new construction projects and replacement investments, e.g. in the Digital Node Stuttgart (DKS), the DSTW Koblenz-Trier, Mainz and Rostock.
The architecture of the DSTW partitions the requirements to systems, subsystems and surrounding systems, and defines interfaces in the safety-relevant area SCI-[XY] between these systems. In addition, the interfaces for diagnosis SDI-[XY] must also be defined.

Requirements and models
The starting point are the requirements of the infrastructure manager, which are only excerpted here, such as the maintenance manager's need to have access to current diagnostic and prognostic data from the field, which relates to the current structure (as built) of the plant, for which live data is required. Another requirement is to be able to understand the meaning of the plant's data (configuration, raw, diagnostic and forecast data) without having to read manufacturer-specific documentation. which is not to say that the structure of several manufacturers' products must be standardised. This requires a standardised modular system as an equipment model with which the manufacturer can map the non-standardised hierarchical structure of his system down to the smallest exchangeable unit.
Since the need for entire sub-models and various attributes arises from the above requirements, the discussion of these requirements must precede any detailed discussion of specific attributes in the following sub-models. This enables a focused discussion with an agreed level of consideration. This is a basis for the complex process of unification and standardisation, e.g. between several operators.

The product group model (or operational or logical model) looks at whether the subsystem can fulfil its operational functions. An example of a class derived from Field Element is, for example, the switch.
The equipment model makes it possible to identify the material (i.e. the type) up to the serial number and installation location of a failed component remotely. The maintenance engineer can therefore take a new piece of equipment of the type of the failed material with him for fault clearance as part of an optimised value chain.
The difficulty so far is that despite standardised partitioning of the overall system, the special architecture of the subsystems in the field is manufacturer-specific. Nevertheless, an operator wants to detect possible deviations, errors or faults and understand the underlying diagnoses and hierarchical and functional error propagations in their meaning.
The solution is a standardised modular system - referred to here as an equipment model - with which the manufacturer maps the specific hierarchical and functional architecture of his system down to the smallest exchangeable unit.

Via the functional reference IsImplmentedBy/Implements between objects of the product group model and the equipment model, it becomes clear which product group is implemented by which equipment. Conversely, it becomes clear which logical product groups are affected by a failure of a piece of equipment.

Implementation in the OPC UA protocol
For an interface, the semantics (meaning) of the transmitted data, the syntax and the protocol must be standardised. The OPC UA protocol is used for the diagnostic interfaces.

This protocol has the following advantages, among others:

• Support of information models
• Standardisation of a compact binary syntax as part of the protocol
• Recognised security with certificates and support of a reverse connect from the more secure network area to the less secure areas.

Summary
The product group model presented provides a view of the technical availability of an operational component. The equipment model makes it possible to identify the material (i.e. the type) right down to the serial number and installation location of a failed component remotely. Whether the failure of a sub-component leads to a failure on the level above can be identified by the redundancy mapping shown.
In addition to hierarchical relationships, functional dependencies are also used. In this way, failure effects can be tracked and the deeper cause (root cause) of failures can be recognised.
The model presented is the basis for the standardisation of the SDI interfaces in EULYNX.

Prof. Dr.-Ing. Karl-Albrecht Klinge, Chair of Applied Computer Science - Distributed Systems | Dean Faculty of Engineering | CIO, Mainz University of Applied Sciences