Third Generation On-Board Monitoring and Control System
`Based on Controller Area Network Technology
`Dr. John Donelson III, Science Applications International Corporation
`David Brabb, Sharma & Associates
`Mark C. Edwards, Science Applications International Corporation
`Lawrence B. Jordan Jr, Wi-Tronix, LLC
`Lisa A. Matta, Wi-Tronix, LLC
`Shahram Mehrvarzi, Office of Research & Development, Federal Railroad Administration
`S. K. (John) Punwani, Office of Research & Development, Federal Railroad Administration
`Dr. Vinaya Sharma, Sharma & Associates
`Dr. Som P. Singh, Sharma & Associates
`Monique F. Stewart, Office of Research & Development, Federal Railroad Administration
`David G. Toth, The Timken Company
`Wayne Zavis, Wilcoxon Research
`
`Summary: The Office of Research and Development of the Federal Railroad Administration (FRA) is
`sponsoring a project to integrate on-board monitoring systems with remote controlled mechanical
`components in freight railroad operations. The integrated system, called On-Board Monitoring and
`Control System (OBMCS), is being demonstrated in the FRA Advanced Concept Train (ACT) project,
`which features advanced mechanical components controlled remotely from the locomotive, including
`angle cocks, cut levers, and hand brakes. The system will also have a low-power wireless communication
`link between OBMCS and an ISO container tag tracking system. This interface provides a mobile
`gateway whereby communications tags installed on ISO containers could be able to maintain continuous
`two-way communication with remote monitoring centers when the containers are moving by rail. The
`third generation OBMCS has a modular architecture based on Controller Area Network (CAN)
`technology. It also has a standard physical interface for power and CAN bus communication. Low-cost,
`low-power CAN microcontrollers are dedicated to specific sensor monitoring and actuator control
`functions. Wireless transceivers based on Institute of Electrical and Electronics Engineers (IEEE)
`802.15.4 specification (ZigBee) provide remote wakeup capability and a communications link to other
`systems, such as a container tag tracking system. A wireless Local Area Network (WLAN) based on
`IEEE 802.11b specification (Wireless Ethernet) provides intra-train communication between the
`locomotive and cars. Cell telephone telemetry provides an Internet connection between the cars and a
`Web-accessible database server.
`
`Index Terms: On-board monitoring system, real-time control system, on-board sensors
`
`INTRODUCTION
`
`The Federal Railroad Administration’s Office of
`Research and Development (FRA) has been
`sponsoring development of on-board monitoring
`systems for freight trains.
` The multi-year
`project, which commenced in June 1999, is part
`
`of the Rolling Stock Program Element in FRA's
`Five-Year Strategic Plan for Railroad Research,
`Development, and Demonstrations [1]. In 2000,
`Science Applications International Corporation
`(SAIC) and Wilcoxon Research (WR) developed
`a prototype on-board condition monitoring
`system, designated Phase II-B. It was installed
`
`139
`
`EX1016
`Petitioner Hum (223)
`
`
`Page 1 of 11
`
`

`

`IHHA Specialist Technical Session (STS) Kiruna Sweden, 2007
`
`on a test vehicle provided by the Research and
`Tests Department
`of Norfolk Southern
`Corporation in Roanoke, VA and was tested
`during
`the period November 2000 through
`November 2001 [2].
`
`In fall 2003 a second generation monitoring
`system, designated as Phase II-C, was installed
`on five 100-ton hopper cars owned by Southern
`Company Services in Birmingham, AL. These
`cars are currently deployed in revenue service
`operations on a BNSF route between Miller
`Steam Plant, 20 miles northwest of Birmingham,
`and coalmines in the Powder River Basin in
`Wyoming – a 3,000-mile round-trip journey.
`The Phase II-C system monitors bearings,
`wheels, trucks and brakes. It features the latest
`technology in wireless communications and
`railroad bearings ([3] and [4]).
`
`The third generation monitoring system currently
`under development consists of a fully integrated
`network of passive sensors and mechanical
`actuators, which are controlled remotely from
`the locomotive or from the wayside by a hand-
`held computer. The integrated system, called
`On-Board Monitoring and Control System
`(OBMCS), has modular architecture. It consists
`of a network of microcontrollers linked by a
`Controller Area Network (CAN) bus. The
`protocol for communication on the CAN bus
`network is CANopen, an open standard for CAN
`systems maintained by the CAN in Automation
`(CiA) Consortium
`(http://www.can-cia.org/).
`Each microcontroller in OBMCS is dedicated to
`one or more specific monitoring and/or control
`functions.
` At
`this
`time
`the mechanical
`components integrated in OBMCS include angle
`cocks, cut levers, and hand brakes. CAN
`microcontrollers also manage
`the OBMCS
`power subsystem and various communication
`functions.
`
`OBMCS is currently being installed on five
`freight cars, which were loaned to the project by
`various US railroads and fleet owners. FRA
`acquired
`an EMD GP40-3
`locomotive
`(DOTX2000) for dedicated use in the project.
`DOTX2000 has several safety and security
`features, which were developed under FRA
`sponsorship. The special train consisting of
`
`DOTX2000 and the five cars equipped with
`OBMCS
`and
`the
`advanced mechanical
`components is called the Advanced Concept
`Train (ACT). The ACT will be featured in a
`series of demonstrations with U.S. railroads
`commencing in summer 2007.
`
`This paper discusses OBMCS requirements,
`architecture, and potential benefits of
`the
`technology.
`
`DEVELOPMENT OF SYSTEM
`REQUIREMENTS
`
`The requirements for integrating and remotely
`controlling mechanical systems in OBMCS were
`driven by the need to develop a common
`approach for interfacing these systems with
`earlier generations of the on-board monitoring
`system, providing power
`to
`them
`and
`communicating with them. To address these
`needs, the OBMCS design team prepared an
`OBMCS
`Interface Requirements Document
`(IRD)
`for sensors and
`remote controlled
`actuators.
` The design
`team held weekly
`conference calls in summer 2004 to review
`successive drafts of the IRD. This document
`outlines general requirements for any device
`(sensor or actuator) with regard
`to form,
`capability, electrical interface, communication
`interface, timing, and operational and safety
`considerations. Various appendices to the IRD
`describe additional requirements for specific
`devices, such as angle cocks, cut levers, and
`hand brakes.
`
`The selection of CAN bus technology for
`OBMCS architecture was based mainly on
`considerations of system cost and power
`consumption. It was also based on the desire to
`be
`compliant with well-established open
`standards, as much as possible, in developing
`OBMCS hardware, communication systems, and
`software. CAN is a serial bus system that
`supports standardized development of embedded
`systems. The CAN protocol was internationally
`standardized in 1993 as ISO 11898-1. During
`the last 15 years, CAN technology has been
`widely adopted in the automotive and other
`machinery
`industries.
` Presently dozens of
`manufacturers of produce CAN compliant
`
`140
`
`
`Page 2 of 11
`
`

`

`IHHA Specialist Technical Session (STS) Kiruna Sweden, 2007
`
`microcontrollers. Similar numbers of vendors
`provide software development tools for CAN
`systems.
`
`the
`requirements,
`interface
`the
`Based on
`OBMCS design team developed a specification
`for the OBMCS CAN controller network in
`summer 2004. It defines message parameters,
`bus speed, and other important parameters of the
`network. The system design team adopted
`CANopen as the communication protocol for the
`OBMCS CAN network.
` The CANopen
`specification was developed by Bosch in the
`early 1990s. It handed over to the CAN in
`Automation Consortium in 1995. Off-the-shelf
`devices,
`software development
`tools, and
`CANopen protocol stacks are widely available to
`support development of embedded systems
`compliant with various CANopen standards.
`The OBMCS CAN specification document has
`undergone numerous revisions as details of the
`system design have been modified and refined.
`A major objective in development of this
`document was to maintain compliance with
`CANopen draft standard DS-301 for the CAN
`communication profile and message IDs and DS-
`401 for creation of the generic digital I/O and
`analog input functionality of the devices on the
`OBMCS CAN network.
`
`SYSTEM ARCHITECTURE
`
`This section discusses details of OBMCS
`architecture. We shall discuss communications
`and sensor signal processing algorithms in the
`following sections. Figure 1 shows a top-level
`diagram of OBMCS architecture. Sensors and
`actuators mounted on the cars are linked via a
`wireless Local Area Network (WLAN) to a
`computer in the locomotive, which displays
`system
`status
`information
`and
`transmits
`commands to the cars to operate the actuators.
`The sensors monitor freight car mechanical
`components. The actuators control and operate
`mechanical systems, such as angle cocks and cut
`levers. GPS receivers provide location, date,
`time, speed, and heading information for each
`car.
`
`On-Board Monitoring & Control
`System
`
`SSB •Sens or Sys tem Bo><
`
`Communieation Sys tems
`
`- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - , - -
`
`Clie nt
`
`TCPIIP :
`
`Railroads
`Car Owners
`Rail Customers
`
`OatabaseJWebServer
`
`Figure 1: Top-level OBMCS architecture
`
`Cell telephones transmit system performance and
`status information from each car to a database
`server and web site, which can be accessed
`remotely by clients. The Code Division Multiple
`Access (CDMA) cell phone provisioned with 1X
`Radio Transmission Technology
`(1XRTT)
`service provides a two-way Internet connection
`between the train and the database server. The
`1XRTT connection can also be used for remote
`trouble shooting and
`to upload software
`modifications. Other wireless communication
`technologies, such as satellite and Global System
`for Mobile communications (GSM), could be
`used instead of or in addition to the CDMA cell
`telephone. When the system is not in an area
`having 1XRTT coverage, the data packets are
`stored on a solid state flash disk. The data
`packets are forwarded to the database server
`when
`the 1XRTT
`Internet connection
`is
`reestablished. The store and forward algorithm
`uses a Transmission Control Protocol (TCP)
`server process to transmit stored data packets
`and messages.
`
`Figure 2 shows a diagram of OBMCS sensors,
`communications systems, and power subsystem
`components installed on the test cars. It also
`shows a list of the mechanical systems that can
`be controlled remotely from the locomotive.
`Currently only hand brakes, angle cocks, and cut
`levers have been integrated with OBMCS. The
`tri-coupler is a passive connection device that
`couples the cars, pneumatic line, and electric
`power line for an Electronically Controlled
`Pneumatic (ECP) brake system.
`
`141
`
`
`Page 3 of 11
`
`

`

`IHHA Specialist Technical Session (STS) Kiruna Sweden, 2007
`
`On-Board Sensors and
`Advanced Com onents
`
`On-Board Sensors
`Themiocouple
`-
`• Bearing Vibration Accelerometer
`~ Tri-axial Ride Quality Sensor
`-
`Brake Piston Travel Sensor
`(1 per truck for truck mounted brakes)
`
`Advanced Components
`
`• ECP Brakes
`-Hand Brakes
`-Tri Coupler
`• Auto Cutlever
`- Auto Angle Cock
`• Hopper Doors
`
`JB =Junction Box
`SSB = Sensor S
`
`tern Box
`
`Power
`Communications
`
`Figure 2: OBMCS sensors, actuators, and
`communication systems
`
`Bearing Accelerometers
`
`Vertically oriented accelerometers mounted on
`bearing adapters monitor bearings and wheels
`for defects and derailment.
` Derailment
`monitoring is performed continuously. Bearing
`and wheel
`defect monitoring
`is
`done
`intermittently.
`
` Algorithms
`for defect
`monitoring are discussed below.
`
`Bearing Temperature Sensors
`
`Temperature sensors embedded inboard and
`outboard on bearing adapters monitor bearing
`temperature continuously.
` An overheated
`bearing can be detected immediately with 100
`percent certainty of the location of the defective
`bearing.
`
`Ride Quality Sensors
`
`Tri-axial accelerometers mounted on the main
`sill over the bolster bowls on the A and B ends
`of the car monitor ride quality. Laterally
`oriented sensors monitor low-frequency truck
`hunting motion. Vertically oriented sensors
`measure impacts imparted by the tracks and
`vertical pitching
`and bouncing motions.
`Longitudinally oriented sensors detect shocks
`during coupling and shocks from slack run out
`and run in during acceleration and deceleration,
`respectively.
`
`Brake Piston Travel Sensors
`
`Proximity sensors adjacent to the brake piston
`rod monitor its stroke during braking. These
`sensors provide an indication that the brakes are
`either applied or released with the brake cylinder
`in the proper retracted position. They can also
`indicate brake piston over-travel when the brakes
`are applied. An over-travel condition indicates
`the need to immediately service the brakes.
`These sensors permit automation of brake
`system tests at a freight terminal before the train
`departs from the terminal. A full-service brake
`application would be made while the train is
`stopped at the terminal. The brakeman would
`then check the status of the brake piston travel
`sensors shown on the locomotive computer
`display to determine whether any brake cylinders
`are beyond the safe operating limit. Automation
`of this procedure could eliminate the need for the
`brakeman to visually inspect the brakes of each
`car before the train departs from the terminal.
`
`Figure 3 shows a diagram of the OBMCS
`distributed architecture. It shows various sensors
`and actuators connected on a CAN bus network.
`
`Figure 3: OBMCS distributed architecture
`
`Sensor System Box
`
`The Sensor System Box (SSB) has a single
`board embedded computer (SBC) system, which
`manages all communications between OBMCS
`and external systems including the locomotive.
`The SBC hosts a Linux operating system. The
`SSB SBC functions as the master node on the
`
`142
`
`
`Page 4 of 11
`
`

`

`IHHA Specialist Technical Session (STS) Kiruna Sweden, 2007
`
`CAN bus. It runs a fully CANopen compliant
`stack to manage communications between the
`SSB and other nodes on the CAN bus.
`
`The embedded SBC has X86 architecture
`packaged in the PC/104 form factor, which
`implements
`the
`standard
`PC/AT
`bus
`specification (IEEE P996) in a compact 3.55” x
`3.75” circuit board that eliminates the need for
`back planes or card cages through a self-stacking
`bus. It has four serial ports, USB ports, and a
`10/100 Ethernet chipset integrated on the SBC
`circuit board. It also has 16 16-bit analog input
`channels and 24 digital I/O channels integrated
`on the circuit board. The SBC analog-to-digital
`converter samples the analog signals from the
`bearing accelerometers. The SSB SBC executes
`signal processing routines for detecting bearing
`and wheel defects and derailment. In future
`generations of OBMCS the functions of the SSB
`SBC will be supplanted by one or more
`microcontrollers.
` This will further reduce
`OBMCS cost and power requirements.
`
`Smart Junction Box
`
`The system is symmetric between the A-end and
`B-end of the car. CAN bus messages from
`various nodes at each end of the car are routed
`through the Smart Junction Boxes to the SSB. A
`CAN microcontroller in the Smart Junction Box
`processes signals from the tri-axial ride quality
`sensor and bearing temperature sensors.
`
`Accessory Interface Box
`
`The Accessory Interface Box (AIB) provides a
`standard physical connection
`scheme
`for
`interfacing sensors and actuators to the CAN
`bus. It has six identical ports for connecting
`sensors and actuators to the CAN bus. Each port
`provides 12 and 24 Volts DC power and signal
`lines for communication on the CAN bus. One
`of the ports can be used to daisy chain the AIB
`boxes if necessary. This connection scheme
`provides a pathway for future expansion of
`OBMCS capabilities.
` Presently CANopen
`networks can have up to 128 nodes attached to
`the bus. Since each node can support multiple
`sensors and actuators, many possibilities exist
`
`for future expansion of system capabilities,
`subject to the availability of adequate power.
`
`Presently only angle cocks, cut levers, and hand
`brakes have been integrated with OBMCS.
`Figure 3 shows that these systems are connected
`to OBMCS through the AIB. They operate on
`24-volt power supplied by the AIB. The AIB
`has a small 24-volt, 2 amp-hr battery that
`provides electric current to operate actuators.
`The AIB can provide up to 50 Watts of power
`for short-term operation of angle cocks, cut
`levers, and other actuators. The AIB has a 12 –
`30 volt DC power supply to charge the 24-volt
`battery.
`
`Smart Battery Charger, Wakeup, and Power
`Management System
`
`The Smart Battery Charger System manages
`OBMCS power. A 12-volt, 100-amp-hr, lead-
`acid gel cell battery provides electric power to
`operate OBMCS.
` An electric generator
`(developed by The Timken Company) embedded
`inside a Class F railroad bearing provides power
`to charge the battery when the train is moving.
`The generator bearing provides up to 24 watts of
`power to recharge the battery. A voltage
`regulator rectifies the variable frequency AC
`voltage output from the generator bearing. The
`output of the regulator charges the battery.
`
`The generator bearing also has an embedded
`tachometer, which produces a square wave
`signal having 12 pulses per revolution of the
`axle. A CAN microcontroller in the Smart
`Battery Charger monitors the tachometer signal
`to determine when to turn the system on and off
`based on train speed. The microcontroller also
`monitors
`the battery voltage
`to determine
`whether it is sufficient to run the system. The
`nominal wake up speed for the system is 10 mph
`if battery voltage is adequate to operate the
`system.
` The microcontroller in the Smart
`Battery Charger runs continuously. When it is
`not communicating on the CAN bus, its power
`consumption is typically less than 10 mA. A
`counter timer in the microcontroller can be
`programmed to wake up the system for a short
`communication burst when
`the car
`is not
`moving.
`
`143
`
`
`Page 5 of 11
`
`

`

`IHHA Specialist Technical Session (STS) Kiruna Sweden, 2007
`
`COMMUNICATION SYSTEMS
`
`Intra Train Communication
`
`Figure 3 shows various wireless communication
`systems operating in the SSB. Communication
`between OBMCS and the locomotive is via
`Direct Sequence Spread Spectrum (DSSS) based
`on IEEE 802.11.b specification for Wireless
`Ethernet operating in the 2.4 GHz frequency
`band. An ad hoc WLAN configuration is used.
`Optimized Link State Routing
`(OLSR)
`(OLSR.ORG) mesh networking software runs on
`the locomotive computer and the SSB SBC.
`OLSR is a routing protocol for wireless ad hoc
`networks. If a node in the WLAN does not have
`line of sight connectivity with another node in
`the network, OLSR will attempt to set up a route
`between the source node and destination node
`using intermediate nodes to relay the message
`through the network. For example, in a long
`train, the locomotive might not have line of sight
`connectivity with most of the cars in the train
`when it is going around a curve. In this
`situation, OLSR would determine a route
`between the locomotive and each car using
`intermediate cars to forward message packets to
`their intended destination.
`
`Network Data Distribution Service (NDDS)
`software manages messaging between
`the
`locomotive computer and the cars. NDDS
`operates on a publisher/subscriber paradigm. It
`runs on top of the WLAN TCP/IP protocol
`software in both the locomotive computer and
`the SSB SBC. Publisher processes running on
`the locomotive computer transmit data topics
`(commands and status requests) to the cars.
`Subscriber processes running on the SSB SBC
`listen for specific data topics to which they
`subscribe. For example, when an SBC process
`that
`subscribes
`to angle cock operation
`commands receives a message to operate one of
`the angle cocks (A- or B-end), processes on the
`SBC react to the message and send the command
`to the appropriate node on the CAN bus.
`Similarly, publisher processes running on the
`SSB SBC transmit specific data topics to the
`locomotive, such as the status of a specific
`OBMCS subsystem.
` Subscriber processes
`
`running on the locomotive computer receive
`specific data topics from each of the cars and
`display them on the appropriate screens on the
`locomotive computer display.
`
`GPS Receivers
`
`the SSB provides
`in
`receiver
`The GPS
`continuous location (latitude, longitude, and
`altitude), date,
`time, speed, and heading
`information. Its output is sampled once a
`second. The reported GPS location is the
`location of the GPS antenna on the car.
`
`Cell Telephone Telemetry
`
`The CDMA cell telephone telemetry system is a
`Kyocera Wireless M200
`tri-mode
`telemetry
`module provisioned with Verizon Wireless
`1XRTT service. It operates over a serial
`connection to the SSB SBC using a point-to-
`point protocol (PPP) connection. The IXRTT
`service provides two-way Internet connectivity
`between the ACT test cars and a Web-accessible
`database server located at SAIC’s facility in
`McLean, VA. The rated speed of the M200
`module is 150 kbps. The realized transmission
`speed, which is dependent on the network
`connection, is typically around 70 kbps or less.
`
`When it has a 1XRTT connection, the CDMA
`radio
`transmits summary
`information about
`monitored components and OBMCS status
`information to the database server according to a
`defined schedule. Each data packet is tagged
`with position, date, and time data obtained from
`the GPS receiver. The 1XRTT telemetry link
`supports remote query from a Web browser and
`real-time system diagnostics and software
`modification via standard SFTP and SSH
`connections.
`
`Remote Wake Up
`
`The OBMCS also has a remote wake up
`capability, which uses a low power wireless
`radio frequency (RF) communication system
`based on IEEE 802.15.4 specification (ZigBee).
`When OBMCS is asleep, the microcontroller in
`the Smart Battery Charger periodically turns on
`the ZigBee radio transceiver so it can check for
`
`144
`
`
`Page 6 of 11
`
`

`

`IHHA Specialist Technical Session (STS) Kiruna Sweden, 2007
`
`beacon message packets directing the system to
`wake up. For example, this feature is used to
`wake up cars on a siding when they are being
`coupled to a train. The wakeup sequence is
`necessary in order for the locomotive computer
`to properly configure the WLAN and graphical
`displays before train operations commence. The
`ZigBee radio wake up duty cycle requires very
`little power and can execute repeatedly while the
`rest of the system is asleep.
`
`Figure 3 also shows that the ZigBee radio can
`provide a RF link between OBMCS and other
`external systems. For example, the ZigBee radio
`could communicate with low-power RF tags
`mounted on cargo containers.
` Such a
`communication link would enable OBMCS to
`function as a mobile gateway for low-power
`communication systems
`for
`tracking cargo
`containers moving by rail.
`
`LOCOMOTIVE COMPUTER SYSTEM
`
`is a Wi-Tronix
`locomotive computer
`The
`Wireless Processing Unit (Wi-PU) manufactured
`by Wi-Tronix, LLC. It is a PC computer
`packaged in PC/104 form factor and is housed in
`a rugged enclosure. It hosts Microsoft Windows
`XP Embedded (XPe) operating system. It has
`several communication systems including cell
`telephone telemetry, Wireless Ethernet, and a
`differential GPS receiver.
`
`An extensive suite of software is required to
`provide
`the functionality necessary for
`the
`locomotive computer to display OBMCS status
`information and
`remotely control various
`actuators. To facilitate development of the
`required software, the OBMCS design team
`developed a requirements document and an IRD
`for integrating the locomotive computer with
`OBMCS. The IRD specifies the messages and
`data
`that must be exchanged between
`the
`locomotive and the railcars in order to display
`OBMCS status information and to implement
`remote control functions.
`
`The locomotive computer display has a variety
`of Graphical User
`Interfaces
`(GUIs)
`for
`displaying OBMCS information to the operator.
`The GUIs are selected and operated by function
`
`keys at the bottom of the display. The screens
`on
`the
`locomotive computer display are
`compliant with the Association of American
`Railroads
`(AAR) Specification M-591
`for
`Locomotive System
`Integration Operating
`Displays.
`
`Figure 4 shows the Train Operations Screen. It
`enables the operator to control mechanical
`actuators such as cut levers, angle cocks, and
`hand brakes remotely from the locomotive. This
`screen shows the order and orientation of the
`cars. It also shows a list of the actuators
`installed on each car. This information must be
`available to the locomotive computer in order for
`the operator to be able to control the advanced
`components installed on the test cars. Using a
`function key, the operator scrolls left or right to
`select a car for remote control operation. The
`operator then scrolls up or down through the list
`of devices
`to select
`the operation
`to be
`performed. Soft keys, highlighted in blue at the
`bottom of the screen, indicate which functions
`can be performed by pressing the corresponding
`function key at the bottom of the display.
`
`Figure 4: Locomotive Computer Train Operation
`Screen
`
`The GUIs in the locomotive computer display
`must be self configuring. To achieve this
`objective, each car must transmit its position,
`orientation, and a list of devices installed on the
`car
`(both sensors and actuators)
`to
`the
`locomotive. A GPS receiver on each car
`provides car location information. A digital
`compass on each car provides car orientation
`information. Together these data provide the
`information the locomotive computer needs to
`
`145
`
`
`Page 7 of 11
`
`

`

`IHHA Specialist Technical Session (STS) Kiruna Sweden, 2007
`
`determine the sequence and orientation of the
`cars in the train. The list of devices on each car
`provides the information necessary to configure
`each GUI in the locomotive display. When cars
`are added to or removed from the train, the
`locomotive
`computer
`screens must
`be
`reconfigured to show the correct train consist
`information. When cars are picked up from a
`siding, they must wake up and transmit their
`location and configuration data to the locomotive
`computer so that the WLAN and locomotive
`compute GUIs can be properly configured. The
`ZigBee radio remote wake up system enables
`cars on a siding to wake up so they can join the
`train. Together these OBMCS features provide
`the capability necessary
`to automatically
`configure the locomotive computer GUIs.
`
`ADVANCED COMPONENTS
`
`In parallel with development of on-board
`monitoring
`systems, FRA also
`sponsored
`development of several advanced mechanical
`systems, including an auto angle cock, auto cut
`lever, hand brake actuator, and tri-coupler.
`Sharma & Associates developed the auto cut
`lever, auto angle cock, and tri-coupler. UTD Inc
`developed the hand brake actuator. These
`systems are intended to be operated remotely
`from the locomotive. They can also be operated
`manually from the side of the car. The tri-
`coupler couples the cars, the pneumatic brake
`line, and the power cable for an ECP brake
`system installed on each car. The auto cut
`levers, angle cocks, and tri-coupler increase crew
`safety and efficiency while retaining normal
`manual functionality. Together they allow for
`remote cutting in and cutting out of cars without
`the need for manually handling angle cocks, cut
`levers, brake line glad hands, and ECP brake
`power line connections. Figure 5 shows the auto
`angle cock. Figure 6 shows the auto cut lever.
`
`Figure 5: Auto angle cock
`
`Figure 6: Auto cut lever
`
`SIGNAL PROCESSING ALGORITHMS
`
`Bearing Defect Analysis
`
`The OBMCS monitors bearings, wheels, trucks
`and brakes. The SSB SBC samples the bearing
`vibration signals from accelerometers mounted
`on bearing adapters at a rate of 50,000 samples
`per second.
` A digital signal processing
`algorithm analyzes the data for large-amplitude
`spectral lines at frequencies associated with
`specific
`types of bearing defects.
` Large
`amplitudes at these frequencies can give an early
`indication of specific types of bearing defects.
`This processing is discussed in detail in [5].
`
`Wheel Defect Analysis
`
`to bearing
`is applied
`Rain flow analysis
`accelerometer data to detect wheel defects. Data
`from a single rotation of the wheel is used in this
`
`146
`
`
`Page 8 of 11
`
`

`

`IHHA Specialist Technical Session (STS) Kiruna Sweden, 2007
`
`analysis. Average counts from multiple wheel
`rotations improve the statistical significance of
`the results. Prototype algorithms for detection of
`flat spots and shell defects on wheel surfaces
`have been developed and will be tested in the
`ACT demonstrations. Since flat, out of round,
`and shell defects on wheels develop slowly, this
`analysis is performed once each day at speeds of
`30 mph or higher.
`
`Derailment Detection
`
`Bearing accelerometer data are analyzed to
`detect derailment. Short data segments are
`checked for high amplitude bursts that repeat
`periodically. A large number of stress cycles at
`high amplitude in a short data segment could be
`indicative of a derailment in which the wheel
`below the bearing adapter accelerometer is
`rolling in the ballast or over the cross ties. This
`algorithm runs continuously on the SSB SBC
`when the train is moving.
`
`Truck Hunting Monitoring
`
`Analog to digital circuitry on the microcontroller
`in the Smart Junction Box samples the output of
`the lateral ride quality accelerometer mounted on
`the center sill above the bolster bowl. The
`sensor signal is filtered by a low-pass filter
`having 3 dB cutoff at 15 HZ and 40 dB per
`decade roll off. The filtered signal is sampled at
`256 Hz. A data window corresponding to 2,000
`ft of travel along the rail is used in the
`processing. Root mean square (RMS) and peak-
`to-peak values are calculated for
`the data
`window. If the car body lateral acceleration
`exceeds 0.26 g RMS or 1.5 g peak-to-peak, an
`alarm message
`indicating excessive
`truck
`hunting is transmitted to the locomotive. This
`processing is done only when the car speed is 30
`mph or greater.
`
`Vertical Ride Quality (Pitch and Bounce)
`
`Analog to digital circuitry on the microcontroller
`in the Smart Junction Box samples the output of
`the vertical ride quality accelerometer mounted
`on the center sill above the bolster bowl. The
`sensor signal is filtered by a low-pass filter
`having 3 dB cutoff at 15 HZ and 40 dB per
`
`decade roll off. The filtered signal is sampled at
`256 Hz. A data window corresponding to 400 ft
`of travel along the rail is used in the processing.
`RMS and peak positive values are calculated for
`the data window. If the car body vertical
`acceleration exceeds 0.6 g RMS or 0.96 g peak,
`an alarm message indicating excessive vertical
`motion is transmitted to the locomotive.
`
`Longitudinal Ride Quality
`
`Analog to digital circuitry on the microcontroller
`in the Smart Junction Box samples the output of
`the
`longitudinal
`ride quality accelerometer
`mounted on the center sill above the bolster
`bowl. The sensor signal is filtered by a low-pass
`filter having 3 dB cutoff at 30 HZ and 40 dB per
`decade roll off. The filtered signal is sampled at
`256 Hz. Peak events both positive and negative
`are calculated for each data window. Peak
`values above selected thresholds are counted.
`The threshold values will vary depending on
`whether the car is loaded or not. Presently there
`are no AAR guidelines for longitudinal ride
`quality. At this time the OBMCS design team is
`still considering various criteria for longitudinal
`ride quality.
`
`Bearing Temperature Sensor Processing
`
`Analog to digital circuitry in the Smart Junction
`Box samples
`the output of
`the bearing
`temperature sensors once every 30 seconds.
`Exponential smoothing
`is applied
`to
`the
`temperature sensor data. If bearing temperature
`reaches 220 ºF, the signal is monitored more
`frequently. Above this level if the bearing
`temperature rises faster than 3 ºF per minute, a
`hot bearing alarm message is sent to the
`locomotive. If the bearing temperature reaches
`240 ºF, an alarm message to stop the t