RAILWAY SAFETY CRITICAL SYSTEMS WITH TASK REDUNDANCY AND ASYMMETRIC COMMUNICATIONS CAPABILITY

Abstract

A railway safety critical application system substitutes commercial off-the-shelf (COTS) hardware and/or software for railway-domain specific product components, yet is validated to conform to railway safety critical system failure-free standards. The safety critical system uses a pair of tasks executed on a controller of a COTS personal computer or within a virtual environment with asymmetric communications capability. Both tasks receive and verify safety critical systems input message data and security code integrity and separately generate output data responsive to the input message. The first task has sole capability to send complete safety critical system output messages, but only the second task has the capability of generating the output security code. A failure of any of systems hardware, software or processing capability results failure to transmit a safety critical system output message or an output message that cannot be verified by other safety critical systems.

Claims

1. A control system for a railway application system, comprising: at least one controller executing first and second tasks; the first task having a first external communications interface capable of sending and receiving a railway systems message within a railway application system, the message including an input security code and input data; the second task having a second external communications interface capable of receiving a railway systems message, the second task having a security code generator; and an inter-task communications pathway coupling the first and second tasks; wherein the first and second tasks respectively receive via their respective first external communications interface and second external communications interface an input railway systems message including input systems data and an input security code and verify the input message, the second task generates an output security code and sends it to the first task via the inter-task communications pathway, and the first task generates output railway systems data and sends an output railway systems message including the output railway systems data and the second task output security code for use within the railway application system.

2. The system of claim 1, wherein the first and second tasks compare their respective input message integrity verifications.

3. The system of claim 1, wherein the first task verifies output railway systems data integrity before sending the output railway systems message.

4. The system of claim 1, wherein the first and second tasks are executed by different software instruction sets.

5. The system of claim 1 wherein the functions of at least one of the tasks is executed virtually.

6. A method for controlling a railway application control system, comprising: receiving by respective first and second tasks that are executed on at least one controller a railway systems input message that is generated within a railway application system that includes a security code and railway data, and independently verifying the input message integrity; independently generating by the first task output railway systems data in response to the input message; generating by the second task an output security code and sending the generated output security code to the first task via a first pathway; receiving by the first task the output security code generated by the second task; and assembling and sending via a second pathway different from the first pathway, by the first task, an output railway systems message including the output railway systems data and the output security code received from the second task.

7. The method of claim 6, further comprising generating and comparing first and second task input message integrity verifications.

8. The method of claim 6, further comprising generating and comparing first and second task output railway systems data.

9. A control system for a railway safety critical application system, comprising: a first controller having a first external communications interface capable of receiving input safety critical systems data within a railway safety critical application system, the first controller being configured to process the input safety critical data to generate output safety critical systems data; a second controller having a second external communications interface capable of receiving the input safety critical systems data within the railway safety critical application system, the second controller having a security code generator configured to process the input safety critical systems data to generate an output security code; and an inter-controller communications pathway coupling the first and second controllers; wherein the first and second controller respectively receive via their respective first external communications interface and second external communications interface the input safety critical systems data and verify the integrity of the input safety critical data, wherein the second controller generates the output security code and sends the output security code to the first controller via the inter-controller communications pathway, and the first controller sends an output safety critical systems message including the output safety critical systems data and the output security code from the second controller for use within the railway safety critical application system.

10. The control system of claim 9, wherein the first controller has a software instruction set different from a software instruction set of the second controller.

11. The control system of claim 9, wherein the first controller has a software instruction set distinct from a software instruction set of the second controller.

12. The control system of claim 9, wherein the first controller has a microprocessor different from a microprocessor of the second controller.

13. The control system of claim 9, wherein the first controller has a microprocessor distinct from a microprocessor of the second controller.

14. The control system of claim 9, wherein the first controller has an operating system different from an operating system of the second controller.

15. The control system of claim 9, wherein the first controller has an operating system distinct from an operating system of the second controller.

16. The control system of claim 9, wherein the first controller and the second controller independently verify integrity of the input safety critical data.

17. The control system of claim 9, wherein the second controller is not capable of sending an output safety critical systems message.

18. A method for controlling a railway safety critical application control system, comprising: receiving, by a first controller having a first external communications interface, input safety critical data within a railway safety critical application system; processing, by the first controller, the input safety critical data to generate output safety critical systems data; receiving, by a second controller having a second external communications interface, the input safety critical data within the railway safety critical application system, processing, by the second controller, the input safety critical systems data to generate an output security code; sending, by the second controller to the first controller via an inter-controller communications pathway, the output security code; and sending, by the first controller, an output safety critical systems message including the output security code from the second controller and the output safety critical systems data for use within the railway safety critical application system.

19. The method of claim 18, further comprising independently verifying, at each of the first controller and the second controller, the input safety critical data.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The teachings of the present invention can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

[0020] FIG. 1 is an onboard train control system general schematic drawing showing interaction of train safety critical systems of the present invention;

[0021] FIG. 2 is a schematic of a computer or controller of the type used in train safety critical system control systems of the present invention;

[0022] FIG. 3 is an exemplary safety critical systems message format used in the safety critical system control systems of the present invention;

[0023] FIG. 4 is a block diagram showing communications interaction among the safety critical system control systems of the present invention;

[0024] FIG. 5 is a timing diagram showing processing steps performed by an exemplary embodiment of the safety critical system control systems of the present invention; and

[0025] FIG. 6 is a timing diagram showing processing steps performed by another exemplary embodiment of the safety critical system control systems of the present invention.

[0026] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.

DETAILED DESCRIPTION

[0027] After considering the following description, those skilled in the art will clearly realize that the teachings of the present invention can be readily utilized in a railway safety critical system that substitutes commercial hardware and/or operating system software for proprietary product components, yet is validated to conform with railway safety critical system standards. In some embodiments of the present invention the safety critical system utilizes a virtual computer environment with one or more personal computers, with two independent tasks and operating systems, or other commercially available controllers and operating systems. Each computer, operating system, software language and compliler may differ for additional diversity. Both tasks receive and verify safety critical systems input message data and security code integrity and separately generate output data responsive to the input message. The separate paired tasks communicate asymmetrically. The first task has sole capability to send safety critical system output messages, including the output data and an output security code, but only the second task has the capability of generating the output security code. A failure of either computer hardware, software or processing capability results failure to transmit a safety critical system output message or transmits an output message that cannot be verified (and thus not used or trusted) by other safety critical systems that receive those unverified messages.

General Description of Train Safety Critical Systems

[0028] FIG. 1 shows generally a railway system with fixed tracks 10 and one or more trains 40. The general description herein concerning train communications, interactions of train systems including safety critical systems or the like, is of a general nature to assist in understanding how the present invention may be utilized in a railway train. Individual train networks and train systems may vary from the general exemplary description set forth herein. The train 40 includes a wireless data/communications system 42 that is capable of transmitting and receiving wireless data, which is in communication with the communications system wireless track-train-control station network (not shown).

[0029] The train transmitter and receiver communications safety critical system 42 is communicatively coupled directly or indirectly to other safety critical systems, including the onboard train management system (TMS) 50 and an onboard unit (OBU) 51 that intervenes in train speed control and braking in the event that the train operator fails to follow local track speed and stopping mandates. Typically the train 40 also has an onboard data recording system (DRS) 60 of known design, with a recorder 62 and one or more associated memory storage devices 64, for among other things acquiring, processing, organizing, formatting and recording incident data. As with any other safety critical system, the DRS 60 function may be incorporated as a subsystem within another train onboard vital system, such as the train management system (TMS) 50, rather than as a separate stand-alone device.

[0030] As also shown in FIG. 1, train 40 generally has other safety critical subsystems, including drive system 72 that provides driving force to one or more wheel carriages, and brake system 74 for altering train speed. The on-board train management system (TMS) 50 is the principal electronic control device for all other controlled train subsystems, including the navigation position system (NPS) 82A with associated train location detection system 82B that provides train position and speed information. Other subsystems include throttle control that causes the drive system 72 (e.g., more or less throttled speed) and receives commands from the TMS 50. The brake system 74 causes the brakes to brake the train 40. The brake system 74 also receives commands from the TMS 50. Other train cars and/or tandem locomotives 40 optionally may be in communication with the TMS 50 or other subsystems in train 40, such as for coordination of braking and throttle control. The train 40 also has a train crew human-machine interface (HMI) 90 that has an electronic display screen 91 and operator actuated brake B and throttle T controls (one or both of which are used by the operator depending upon the train operating conditions), so that the train operator can drive the train. The HMI 90 communicates with the TMS 50 via communications data bus 92, though other known communications pathways can be substituted for the data bus when implementing other known control system architectures. The HMI 90 communicates train operator respective throttle T and brake B control commands to the respective engine control 72 and the brake system 74.

[0031] In this exemplary embodiment of FIG. 1, each of the TMS train control system 50, the OBU 51, the data recording system (DRS) 60 and the HMI 90 have internal computer/controller platforms 100 of known design that communicates with each other via data bus 92. However the number of computer controllers, their location and their distributed functions may be altered as a matter of design choice. In this exemplary embodiment, general control of train 40 subsystems is performed by TMS 50 and the controller platform 100 therein; the intervention functions are performed by the OBU 51 and the controller platform 100 therein; the data recording functions are performed by the data recording system 60 and the controller platform 100 therein; and the HMI functions are performed by HMI 90 and the controller platform 100 therein, though any of these systems 50, 51, 60, 90 may be combined in part or in whole.

General Description of Safety Critical Railway Systems Tasks and Their Communication

[0032] Referring to FIG. 2, a physical or virtual controller platform 100 includes a processor 110 and a controller bus 120 in communication therewith. Processor 110 is coupled to one or more internal or external memory devices 130 that include therein operating system 140 and application program 150 software module instruction sets that are accessed and executed by the processor, and cause its respective control device (e.g., TMS 50, OBU 51, DRS 60 or HMI 90, etc.) to perform control operations over their respective associated safety critical subsystems.

[0033] While reference to an exemplary controller platform 100 architecture and implementation by software modules executed by the processor 110, it is also to be understood that the present invention may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. Preferably, aspects of the present invention are implemented in software as a program tangibly embodied on a program storage device. The program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (CPU), a random access memory (RAM), and input/output (I/O) interface(s). The computer platform 100 also includes an operating system and microinstruction code. The various processes and functions described herein may be either part of the microinstruction code or part of the program (or combination thereof) which is executed via the operating system. In addition, various other peripheral devices may be connected to the computer/controller platform 100.

[0034] It is to be understood that, because some of the constituent system components and method steps depicted in the accompanying figures are preferably implemented in software, the actual connections between the system components (or the process steps) may differ depending upon the manner in which the present invention is programmed. Specifically, any of the computer platforms or devices may be interconnected using any existing or later-discovered networking technology and may also all be connected through a larger network system, such as a corporate network, metropolitan network or a global network, such as the Internet.

[0035] Computer/controller platform 100 receives input communications from one or more input devices I via respective communications pathways I through input interface 160, that in turn can distribute the input information via the controller bus 120. Output interface 180 facilitates communication with one or more output devices O via associated communications pathways O. The controller platform 100 also has a communications interface 170 for communication with other controllers on a shared external data bus, such as the data bus 92 that was previously described.

[0036] Referring go FIGS. 2-4, communications among computer/controller platforms 100 and their respective safety critical systems (SCS1-SCSn) are accomplished via a safety critical systems message (SCSM) 200 carried on data bus 92. Each SCSM 200 is formatted and transmitted in accordance with a known protocol that is approved for safety critical data integrity in railway critical systems, including a known security code generated by known CHECK-SUM, HASH, etc. protocols. The exemplary SCSM 200 shown in FIG. 3 includes a time stamp 210, and if required a sequence number and source and destination identifiers (not shown), safety critical system data (SCS data) 220 and a security code (SC) 230. For ease of description herein, an incoming or input safety critical systems message (SCSMI) comprises safety critical input data (DI) and an input security code (SI). Similarly, an outgoing or output safety critical systems message (SCSMO) comprises safety critical output data (DO) and an output security code (SO). When a safety critical system SCS1-SCSn receives a SCSMI its data integrity is verified with a known SCI 240 analysis module within the tasks (T1, T2) that is implemented in hardware, firmware, software or any combination thereof. If the SCSMI data integrity is verified the DI are utilized by the tasks to prepare a responsive output message SCSMO including output data DO and an output security code generated in SCO 250 generation module. As with the SCI 240 module the SCO 250 module generation function is implemented in hardware, firmware, software or any combination thereof. The subsequently generated SCSMO is communicated to one or more intended recipient SCS controller platforms that in turn treat the message as a SCSMI.

Redundant Control System and Operation

[0037] In FIG. 4 the safety critical system tasks SCS1 and SCS2 respectively comprise a paired set of tasks T1 300 and T2 320 that are in bilateral communication with each other via inter-controller data interface 330. The tasks 300, 320 are running in commercially available industrial, commercial or consumer devices, such as for example industrial programmable logic controllers, separate or unitized computer/controller motherboards, or commercial off-the-shelf personal computers/motherboards. By way of further example if the tasks 300, 320 are executed literally or virtually in personal computers, they may be executed on the same or separate controllers 100, in one or more computers that housed in separate devices, combined in a common device housing, separate boards in a server rack, etc. Each of the one or more computers may comprise different hardware including separate or common controller platforms 100, and/or processors 110 and/or operating systems 140 and/or application programs 150 stored therein that are executed by the processor(s) to perform the its respective dedicated safety critical system function. The components and software used in each respective task 300, 320 may be sourced from different vendors. For example, each task 300, 320 may utilize different vendor models, versions or types of processors 110, operating systems 140 and application software 150, so as to reduce potential of a generalized vendor-wide component or software failure. In another exemplary embodiment or configuration implementation of the separate tasks T1 and T2, both are executed simultaneously and virtually in real time, in a common computer processor 100, with the respective SCI 240 and SCO 250 sub-tasks also implemented virtually.

[0038] The T1 task 300 is capable of bilateral communication with the critical system data bus 92 through communications pathway 340, which may comprise a communications port enabled in the task platform 100 communications interface 170. Task 300 has an incoming security code verification module 240 that enables it to verify data integrity of a SCSMI, but it does not have the capability of generating an outgoing SCSMO security code SCO.

[0039] The T2 task 320 has an enabled outgoing security code SCO generator 250, but is incapable of transmitting an SCO and critical output data directly to the critical system data interface 92. Task 320 is only able to transmit the SCO to task 300 via the internal data interface 330: it is only capable of receiving a SCSMI through unilateral, incoming communications pathway 350 and can verify data integrity with SCI verification module 240. In other words, the T2 task 320 is incapable of transmitting directly SCSMO to the data bus 92.

[0040] As can be understood by reference to FIGS. 5 and 6, the respective T1 task 300 and T2 Task 320 in SCS1 are in a mutually dependent, paired relationship with asymmetric communications implementations. The first T1 task 300 is capable of receiving a SCSMI and sending a responsive SCSMO, but it cannot create the responsive message until it receives the SCO from the second T2 task 320. The T2 task is not capable of external communication to the critical system data bus 92, and must rely on the T1 task to send any messages.

[0041] In FIG. 5, one of the safety critical systems SCS2-SCSn is sending a SCSMI in step 400, comprising a DI and an SC1 to SCS1 at time t.sub.1, where it is received by both T1 and T2. At t.sub.2, both T1 and T2 verify the SCSMI data integrity in step 410 and in step 420 both generate DO data (t.sub.3) in response to the input data DI. In step 430 T2 generates the output security code SCO at time t.sub.4 and sends it to T1 in step 440. In step 450 (t.sub.5), T1 now assembles and optionally verifies the DO (provided by T2 in the prior step)with its own generated DO before transmitting the SCSMO through critical systems data bus 92 in step 460 (t.sub.6)to other safety critical systems. If the DO do not corroborate each other during step 450 (i.e., output data is suspect) it will not transmit the SCSMO. Alternatively, if T1 is not enabled to verify the DO or if T1 and/or T2 are malfunctioning, it may transmit a corrupted SCSMO, but the corruption will be identified when the message is received by another safety critical system.

[0042] The embodiment of FIG. 6 has all of the steps and processes as the embodiment of FIG. 5, but adds a compare SCSMI verification step 415, where T1 and T2 check each other's respective verification results. If the compared results are not the same SCS1 flags a fault. This embodiment also adds a compare output data DO step 425 before T2 generates the security output code SCO in step 430. Again, if the compared results are not the same SCS1 flags a fault.

[0043] The software redundancy and mutually dependent asymmetric communication output security code generation/transmission features of the present invention railway control system for safety critical systems assures a higher safety level than any individual or independently parallel processing pair of commercial off-the-shelf controllers or personal computers. A single computer is susceptible to multiple forms of failure that would not necessarily be detected by other safety critical systems receiving SCSMOs from the failing computer. Two independent, parallel task executions T1 and T2, whether implemented on one or multiple computer platforms, feeding identical SCSMOs to other safety critical systems or that corroborate output messages prior to transmission can both be generating identical incorrect output messages. Such failure mode transmission errors are not possible with the control system of the present invention.

[0044] When analyzing possible failure modes of the safety critical systems control system of the present invention SCS1, if T1 calculates an incorrect DO and T2 calculates a correct DO and SCO, then during verification step 450 T1 will flag a mismatch between its own DO and the DO and flag an error. If T1 does not verify the SCSMO in step 450 other safety critical systems receiving that message will flag the error when they verify the received message. Conversely if the T1 DO is correct but either the T2 DO or SCO are incorrect, T2 or other SCS receiving the SCSMO will identify the error. If both T1 and T2 malfunction and generate faulty DO and/or SCO the mismatch of the DO and SCO will be noted by other critical systems that subsequently receive the corrupted message.

[0045] Although various embodiments, which incorporate the teachings of the present invention, have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings.