Open Architecture Train Control
Transportation Systems
Design, Inc. www.tsd.org
Created: 02 April 2002 Updated: 16 January 2003
TM
Open Architecture Train Control
|
TM |
Open Architecture Train Control (OATC) is based upon an open systems paradigm. It is further based upon open consensus-based IEEE network communications standards and Rail Transit Vehicle Interface Standards to describe a next-generation of network-based train control. OATC applies many of the original goals of AAR's Advanced Train Control System program and ongoing efforts by US railroads and the rail transit industry to maximize the use of Commercial Off The Shelf (COTS) technology and open systems to next-generation train control.
OATC is based upon the use of well-established network communications standards. Increasingly, these standards are being used by suppliers and mandated by railroads and transit properties. Thus, OATC is simply the logical evolution of interconnecting existing open technology systems and applying them to train control. I.e., OATC simply "connects the dots" to existing standards.
OATC systems are comprised of objects that communicate over standard communications networks. Each OATC object is described by a Profile that fully defines its network interface. By defining, and thereby "exposing," its network interfaces it becomes easier for suppliers to develop compatible interoperable subsystems and components.
From multiple compatible sources flow many "win-win" benefits to end-users and suppliers. Losers are those who want to continue to sell (or are willing to buy) only closed proprietary systems.
It depends. OATC is neither a monolithic train control architecture nor a specific train control implementation. Rather, OATC is a design approach based upon the use of open systems and open interfaces. Therefore, one instance of OATC may define a system based only upon CBTC and not use track circuits. Another may be based only on track circuits. Still another instance of OATC may use both. One OATC instance may place most of the intelligence in vehicle based computers, another on wayside based computers.
It is important to stress that OATC subsystems communicate over open (but secure) networks (i.e. true Layer 3 network protocols) rather than simply "communications." Therefore, a CBTC system may or may not conform to OATC recommended practices. And CBTC systems with proprietary subsystem interfaces are incompatible with OATC's open architecture network paradigm. More details on networks, interfaces are open network Profiles provided in the table below.
For over a century railroad signaling was based upon the application
of vital relays and closed-loop control circuitry that relied on the inherent skill of the design engineer. Toward the end of the 20th Century, train control architectures that used electronics and microprocessor technology normally tried to mimic this failsafe approach to safety by structured fault tree analysis that attempts to delineate failsafety as exceeding a somewhat arbitrary limit of "mean time between unsafe failures" (MTBUF). The typical limits for MTBUF claim to be derived from theoretical failures of older gravity-based relay mechanisms. While this approach has certain arguable merits it has also been the culprit of more than one unsafe failure. Thus, determining a "safety baseline" against which newer systems can be safely compared has become problematic. Does anyone know what the MTBUF of a vital relay is?Therefore and consistent with a modern systems approach to safety being deployed across many industries, each OATC instance
must have a comprehensive System Safety Program Plan (SSPP) that evaluates all components for failures that can impact safety. The OATC interface specification will identify the failure mode requirements for each OATC component. The OATC system designer then becomes responsible for the interaction of OATC components as a system to demonstrate the safe operation of the system by applying the OATC components in a closed-loop application that assures the proper system function.By taking this approach, OATC applications engineers can safety configure OATC
components to meet their own requirements without having to know the internal functioning of each of these components. As a result, it is anticipated OATC systems will be demonstrably safe while being easier to apply and configure. As a result, OATC based systems are expected to be considerably less costly to procure and safety certify.By defining standard OATC Profiles for each networked train control subsystem it becomes possible (much like Legos) to more easily adapt OATC subsystems to multiple different train system configurations and applications. This re-use in turn reduces a product's development and life cycle costs.
Further, by completely defining and fully exposing subsystems interfaces and subsystem behavior, it is expected that system integration and safety assurance can be significantly simplified. OATC objects may be based upon LonMark Profiles, XML, and other modern and self-describing standards.
It is important to appreciate the difference between a system that is open and one simply based upon a standard. Microsoft Windows is clearly a standard and just as clearly proprietary. Therefore Microsoft Windows is not considered by most experts to be an open operating system. Linux is clearly an open operating system, and a standard that operates on many different mainframe and servers, it is not yet common as a desktop or workstation standard.
Systems that are open and have open interfaces have many advantages over proprietary systems. However, it is important to understand that many combinations and permutations are possible. For example, it possible to have an open interface to a proprietary subsystem such as TCP/IP over Ethernet on a Windows XP system. It is even possible to patent an industry standard. (See below).
Thus, while OATC systems are based upon open standards and open interfaces OATC systems may also interoperate with proprietary subsystems that have their own internal intellectual property rights. AMD for example, was able to "clean room reverse engineer" the Intel Pentium CPU because the Pentium interface is fully defined, or "open" yet the intellectual property associated with manufacturing both Intel's and AMD's CPUs remain valuable property and closely guarded secrets.
Thus, it is possible for an OATC train control system to use a proprietary Microsoft OS in a Control Center to communicate using the open Internet Protocol (IP) over an open IEEE-802.3u or IEEE-8017 wired network to an open IEEE-802.11 wireless network to a wired IEEE-1473-L network that communicates to vehicle objects with open OATC Profiles. It is also possible for an open protocol such as internet protocol (IP) to interoperate over a proprietary wireless communications network. All these configurations can produce viable OATC architectures.
However, increasingly transit properties are troubled by the high cost, rapid obsolescence and unreliability of low volume proprietary systems and are migrating away from such systems. For this reason, many such as SF-BART are beginning to successfully migrate off closed operating systems in favor of Linux and they are discovering that when they do their new systems open paradigms systems are not only less expensive the are also more reliable.
More details will appear here. The following should help provide initial overall guidance as to standards and best practices for use with OATC:
|
Standard or Reference |
Description |
Comments |
| IEEE Spectrum Magazine | "Can you patent an Industry Standard?" | A must read. This article tells how, why and what to watch out for. |
| IEEE Definitions | IEEE RTVISC Definitions | Intended to be a initial and not a restricted list. |
| IEEE 1483 | Verification of Vital Functions | |
| IEEE-1474 | An open consensus-based standard defining user interface and functional and performance requirements for Train Control. | Defines standards for performance but not a specific design. |
| IEEE-1473-L | The de facto and de jure communications protocol used on most rail transit vehicles in the US. IEEE-1473-L is based upon ANSI/EIA 709.1 an open consensus based standard. | See: IEEE 1473-L Frequently Asked Questions |
| ANSI 709 | The International Standards Organization Open System Interconnect 7-Layer control network protocol more commonly known as LonWorks | Railway Age Conference Paper |
| SNVTs | Standard Network Variable Types. SNVT's describe the type of data that travel over an ANSI 709.1 network. SNVTS are the building blocks used to define Profiles | SNVTs define specific data types and associated Engineering Units |
| Profiles | An open standard that uses SNVTs to define objects with exposed interfaces traveling over an ANSI 709.1 network. Profiles are developed by the LonMark Association. | See LonMark and this IEEE-1473-L FAQ |
| IEEE 802.3u | A standard for wired communications commonly known as 100BaseT Ethernet | |
| IEEE 802.11 | A set of open standards for wireless data communications | |
| IP | The most widely-used method for transporting data within and between communications networks. | IP defines a Layer 3 protocol. It is a connectionless routable protocol |
| XML | A superset of HTML typically transported over IP. A standard means to self-describe data across diverse hardware and applications | |
| Linux / BSD | Open source operating systems and collections of software tools similar to and compatible with the Unix operating system. | Related GPL tools include gcc, Apache, Samba, MySQL, Postgress, ObjectAda, etc. |
| GPL | The General Public License | A commonly accepted way to distribute Open Source software |
| Open Source | A web site dedicated to open source objectives | Learn about the dangers of Microsoft's Shared Source |
| Other items will be added to this list.. |
Stay tuned. This site is expected to be more fully populated over the next several months. However, the George Washington University in Washington, DC currently offers an on-site course CWEG118 that follows closely OATC goals and objectives. Customized versions are also available directly through TSD.
A discussion board will be available soon to facilitate the development of OATC Profiles but it is TSD's intention to model the process used by Internet and the open source community. "Request For Comments" (RFC's) will be posted in a public discussion group and everyone will be permitted to contribute.
In addition, new Rail Vehicle Profiles based upon open LonMark Profiles for systems using the industry standard IEEE-1473-L are expected to be play a significant role in helping to establish interoperability among network-based train control systems.
"Open" means different things to different people. Some firms claim their systems are open because their products have an RS-232 port. While a first step in the right direction RS-232 defines only the physical communications layer. Therefore, to prevent abuse of the OATC term, a TSD trademarked logo is applied to a subsystem that has a fully exposed interface and connects to a well defined network.
It is useful to note that as of early 2003 a Google web search of "Open Architecture Train Control" returns only a few links containing this term and all but two links refer back to www.tsd.org web pages where we are defining it here. However, because OATC is intended to be an open consensus-based development what we agree OATC means in the future may evolve. So stay tuned. The web based discussion forum is planned shortly.
This section is under construction but click here for a preview