Background
The system DBMAS (DB-Meldeanlagensystem, DB signaling system) is a new standardized solution for remotely controlling and monitoring alarm systems and further operationally relevant infrastructural facilities which has been called for tenders by DB AG in 2009. Facilities to be connected include amongst others hot box detection systems in the track area, wind sensor systems on bridges and dams, and safety devices of railway tunnels.
The focus in the design of DBMAS is on the standardization of communication interfaces. Hence, the telecontrol protocol IEC 60870-101/104 has been defined to be the mandatory interface from the DBMAS control center to connected devices, the so-called field level. For all other system interfaces, a disclosure of the protocol is required.
The company SST (Signal & System Technik), which meanwhile changed its name to voestalpine SIGNALING Siershahn GmbH, has been awarded the contract for the implementation of DBMAS.
Requirements
DBMAS was supposed to be implemented based on the already existing product CMS (Central Monitoring System) of the company SST. CMS is a platform independent system which is very flexibly scalable and brings together information from different railway and vehicle diagnostic systems. In particular, the existing client-server communication, which was based on a proprietary protocol, had to be migrated to a standardized communication structure meeting, amongst others, the following requirements:
The communication had to be IP-based, and the protocol had to operate effectively at low bandwidths (in part less than 64 kbit/s). Encrypted transmission should be principally possible. Furthermore, it should be possible to model and transfer respectively the complex information structures of the system. As the transmitted information is at least in parts relevant to security and a very prompt reaction of the operator is required, a quasi-real-time communication had to be possible. In addition to that, the protocol should preferably be standardized in the sense of a norm. For being able to integrate the protocol into existing software solutions, it should be possible to implement the interfaces in C++.
Solution
SST had already gained first, good experience with (at that time still very new) OPC UA for standardizing the communication of train diagnostic systems. Thus, OPC UA was the prime candidate for the client-server communication in DBMAS.
After evaluating further options and a proof-of-concept using a test implementation, SST and DB Netz AG made a joint decision to use OPC UA for implementing the client-server communication in DBMAS, because OPC UA met all requirements. An OPC UA information model was developed, which was able to reproduce the complex data structures of diverse diagnostic information. The data are highly efficiently transmitted via UA TCP binary protocol; even in networks with lower bandwidth it is possible to achieve excellent reaction times by using the OPC UA Subscription mechanism.
OPC UA Background
The OPC UA Specification defines a service-oriented architecture (SOA), which is platform independent and functionally combines “classic” OPC functionalities like Data Access and Alarms & Events, as well as Historical Data Access. The OPC UA communication stacks are implemented in ANSI C/C++, Java, and .NET and form the basic protocols for TCP/IP based network communication. In addition, signing and encryption of messages as well as authentication and authorization via X.509 certificates are already part of the standard.
The most characteristic feature of OPC UA is that there are extensive possibilities of information modeling. Information units (nodes) and their relations among each other (references) follow an object-oriented design paradigm. Thus, each kind of data itself, as well as its meta information, can be semantically described and generically mapped.