1. Implementation structure The protocol stack was implemented formerly by UniControls, Inc. under the OS9 Real-Time OS. The new implementation for the VxWorks 5.4 RT OS was developed by porting the OS9 implementation under VxWorks and rewriting substantial parts of the port so they better exploit the characteristic features of the VxWorks RT OS. New features have been added to the VxWorks implementation as well: a full implementation of the network layer, better handling of hardware failures through signals and ANSI long jumps, better deadlock prevention via time-outed intertask communication mechanisms and priority inheritance. The VxWorks implementation is fully written in the C programming language and consists of 3 parts, each implementing one of the TCN application interfaces – AVI, AMI and LSI. As the AMI interface is optional and may not be used in all applications, the AMI part of the protocol stack is optional and can be excluded from the protocol stack. This saves memory in applications that use only the AVI and LSI services. A simplified structure of the VxWorks implementation of the message communication subsystem is shown on fig. 3. Apart from the OS9 implementation the interrupt handling routine was moved to a special task, the Interrupt server. This structure preserves short interrupt latencies of the VxWorks OS and provides control over the relative priority of the interrupt handler to other running tasks. Introduction On the 1 st of october 1999 the Train Communication Network (TCN) had received the status of the international standard No. IEC 61375–1. UniControls Inc., very early implemented the Wire Train Bus (WTB) that is a crucial part of the standard. The physical and link layers were implemented as the WTB2000 communication processor unit, a module for the VME-bus based PEP Modular Computers industrial computer family. The higher layers were implemented under the OS9 operating system. The Department of Control Systems Engineering FEE CTU aids in the implementation of the higher layers under the VxWorks 5.4 RT OS. An open standard for communication in trains T. Pilc, P. Burget, Z. Šebek, Z. Hanzálek email: pilc@rtime.felk.cvut.cz, burgetpa@…, sebek@…, hanzalek@… Department of Control Engineering Faculty of Electrical Engineering Czech Technical University Acknowledgments This work was published with the kind agreement of UniControls Inc. This work was supported by the Ministry of Education of the Czech Republic under Project VS97/03. References [1]International Standard IEC 61375-1: Electric railway equipment – Train bus, Part 1: Train Communication Network; IEC, 1999 [3]Douglas E. Comer: Internetworking With TCP/IP Volume II – Design, Implementatin, and Internals; Prentice-Hall, 1991 [4]Wind River Systems: VxWorks Programmer’s Guide 5.4, 1st ed.; Wind River Systems, 1999 [3]TCN Tutorial: http://www.labs.it/rosin/tcncorso/tutindex.htm [4]UniControls Inc.: http://www.unicontrols.cz/ Fig.1 – Train Communication Network structure The TCN standard The TCN network is not really another ”fieldbus” standard for industrial communication like CAN, PROFIBUS or INTERBUS-S although it provides common fieldbus services. The TCN is designed specially for communication in train compositions. Thanks to its relation to this field it has the following features:  Hierarchical – constituted of two distinct busses, each with specific properties: the Wire Train Bus (WTB) is the communication backbone of the train, interconnecting separable parts of the train composition like the locomotive and the coaches. The Multifunction Vehicle Bus (MVB) connecting standard on-board equipment in the non-detachable parts of the train composition.  Redundant – the physical layer of both WTB and MVB buses can optionally be duplicated.  Failure recovery – remains partly operational in case of the failure of one or more nodes.  Automatic reconfiguration – the WTB interconnecting the separable parts of the train automatically reconfigures the bus in a defined maximum time and announces the configuration change to all applications.  Extendable and open – the standard treats the use of sensor busses as the third level of the TCN network and enables replacement of the WTB and/or MVB busses by other bus types under specified conditions.  Both DSM and messaging supported – two communication mechanisms are supported by the bus: Process Variables, a Real-Time distributed shared memory or distributed database-like communication and Application Messages, based on sending of arbitrary length, unicast and multicast messages.  Remote network management – mechanisms for managing/configuring the whole network from one place are defined. An overview of technical parameters of MVB and WTB busses can be found in tab.1. Tab.1 – WTB and MVB parameters overview g Implementation Overall implementation criteria were specified based on the properties and the field of use of the TCN protocol stack. The main criteria the implementation is subject to were identified as: 1.Safety – the implementation should be able to detect and gracefully react to a hardwarefailure of the WTB2000 unit by notifying the application of the failure. 2.Extendibility and maintenability – the implementation should be well structured to be easy maintenable and new features and extensions can be added. 3.Memory requirements – the implementation shall have modest memory requirements Fig.2 – TCN services in the context of the ISO OSI architecture Fig.3 – Implementation of the message communication (AMI)