Prepared by Paul Niquette
March 14, 1997
By recognizing and exploiting the advantages of Intelligent Distributed Control (IDC) technologies, MK/ASD has pioneered Vehicle Monitoriing Systems (VMS) for the railroad industry. Development and start-up marketing programs have taken place over a period of five years. MK/ASD is now capable of demonstrating Transaction Based Monitoring (TBM). This 'third generation' architecture applies low-cost wireless modems or cellular telephony to achieve an effective partitioning of monitoring functions between...
Many industries have long recognized the need for achieving the highest possible equipment availability commensurate with the economics of maintenance, inasmuch as...
Figure 1 summarizes the TBM architecture in block diagram form. There are four major sections:
1. Sensors and Signal Conditioning comprises subsystem elements that have been developed as modular units in MK/ASD's System/86 product line. As indicated, much of this section of the architecture will necesarily be application-specific, calling for custom engineering in order to meet the contracted specifications.
2. Onboard Data Communications Networks operate in realtime to deliver event-driven information packets, which for our railroading example, will contain train parameters from various locations throughout the train to the...
3. Onboard Data Acquisition and Communication section comprising the TBM central processing unit and wireless modem or cellular telephone interface. This section is responsible to collect information into files and determine the significance of key parameters. In response to commands from the wayside or in non-railroading applications from a shop-based processor, this section manages the bandwidth and message content that gets sent by wireless signaling to the wayside or shop-based processor.
4. Diagnostic Processor and Dataview Software reside on the wayside or in the shop-based computer subsystem. All message transfers are initiated by this processor, operating as a master, with remote or moving nodes responding as slaves. The wireless protocol follows a heirarchical message structure, which is designed to conserve bandwidth and to assure effective information processing throughout the TBM system.
Figure 1 introduces a central theme in the TBM wireless architecture: forms a logical interface designed to optimize functional responsibilities insofar as they are carried out in the various TBM subsystems, whether in onboard resources or the immensely capable off-line processing installed on the wayside or in shop-based computer subsystem.
TRANSIT INDUSTRY APPLICATIONS
As described below, MK/ASD has provided leadership to the transit industry in VMS and in other network-based monitoring and control applications, beginning with VMS system demonstrations at Metro North Commuter Rail (MNCR) and including the Advanced Automatic Train Control system developed for the Bay Area Rapid Transit District (BART).
The best evidence for the influence of MK/ASD's contributions to the industry is the R-142 new-car procurement by New York City Transit (NYCT). The R-142 technical specifications feature onboard VMS architecture that exactly match those of MK/ASD's first generation IDC products and equipment. Moreover, NYCT has specified that the signalling subsystems be capable of future wireless enhancements -- specifically support for Communications Based Train Control (CBTC). The third-generation TBM architecture described in this technical briefing anticipates the requirements of the wireless environment imposed by CBTC.
FREIGHT RAIL OPPORTUNITY
There can be no doubt that there exists a significant, unaddressed need for TBM in the freight rail segment. The reason is the emergence and rapid adoption by the industry of Electronically Controlled Pneumatic (ECP) Brake. The economic and performance improvements resulting from simultaneous brake application and graduated release provide huge benefits to railroad operations. Even greater payoffs are projected for the VMS adjuncts to ECP Brake.
In the coming years freight cars number in the hundreds of thousands will be equipped with microprocessor-based Car Control Units (CCUs) for the operation of ECP Brake. In order to operate, ECP Brake requires there to be either electrical power generation aboard each freight car or head-end power distributed to each freight car. ECP Brake requires a signalling system, too -- an onboard communications network.
Since the inception of ECPbrake in 1993, MK/ASD has participated in the planning efforts under the aegis of the Association of American Railroads (AAR). MK/ASD was able to influence the system architecture and onboard network protocol selected for ECP Brake -- Echelon -- the same as already applied in the transit applications described herein. The onboard network is recognized by the industry as an 'information superhighway' capable of...
Many high-priority TBM applications have been enumerated, each having tangible economic returns. None have yet been addressed significantly by the supplier industry. Auxiliary uses for IDC supported by the Echelon ECP Brake network include...
In 1992, MK/ASD initiated VMS product development and obtain the cooperation of Metro North Commuter Rail (MNCR) in conducting an onboard demonstration of prototype VMS equipment on the M4 vehicles in 1993. That equipment is still operational. In collaboration with MNCR, MK/ASD guided the specifications for the first generation VMS architecture, which resulted in a change-order for MK's M6 new-car program that incorporated MK/ASD's System/86 products.
This joint effort has been successful in pioneering at least four aspects of vehicle monitoring systems...
The management of technology is the management of change. That's true of suppliers and their customers alike. It is quite plainly impractical to defer the application of technology, expecting some 'ultimate' manifestation to materialize. The practical realities of high-technology have necessitated that commercial venders and buyers recognize product 'generations' as well as 'lines.'
Commercial enterprises generally organize their products or services into 'lines' -- minimizing cost at one extreme and maximizing performance at the other (it is seldom practical to optimize for both in what would then be merely a product 'point'). Various pricing and product factoring stratagems are used to create and to expand a customer base.
The first generation of VMS developed by MK/ASD in collaboration with MNCR engineers was called 'System/86,' which comprised several kinds of ruggedized data-acquisition nodes (DANs), including Digital MiniDAN, Analog MiniDAN, Remote DAN, Local DAN all delivering parametric measurements either directly or via network to a multiple-central processing unit (CPU) for storage.
As industry began to adopt VMS, an awareness developed that there are shortcomings associated with manually downloading data from the train for offline analysis. These shortcomings will almost certainly be observed in non-railroading applications of VMS. Various suppliers of VMS for railroading have observed the ubiquity of cellular telephones as a promising method for automating the procedure. What might be called a second generation of VMS appeared, which sought to facilitate by telephony the downloading of large amounts of raw data from train to wayside. MK/ASD studied the requirements and identified a lower cost and more efficient architecture -- in effect, skipping the second generation of VMS.
MK/ASD has successfully demonstrated a third generation architecture, called Transaction Based Monitoring (TBM), which is able to apply the lowest cost, point-to-point wireless modems in the industry. Trains communicate with the wayside only at fixed points and in a hierarchy of message exchanges (transactions). The expression 'downloading' does not apply to TBM. The paragraphs set forth below describe the attributes and issues that have resulted in MK/ASD's TBM.
The emphasis in the first generation was placed on gathering online data in abundance during operation, for subsequent offline analysis. The concept was strongly analogous to strip-chart recording, which produces great amounts of paper-based, graphical data recordings that need to be laboriously interpreted by experts. Although intrinsically cumbersome, this was a way of life that was well understood by railroad maintenance technicians.
It should be noted, however, that from its inception, the System/86-based VMS made use of an adaptive 'event-driven' data acquisition algorithm that minimized data storage and network traffic by recording groups of measurements based on one or more of its parameters transitioning a moving threshold rather than making highly repetitious, time-based recordings of data samples. The challenge became, in effect, to 'conceal' the event-driven nature of the measurements by processing them into graphical depictions that would be indistinguishable from those produced by a strip-chart recorder.
The System/86 offline software is called 'Dataview,' and it goes far beyond the requisite graphical conversion requirements by providing database management tools that, in the hands of experts, will be able to isolate faults, to correlate symptoms among train parameters, and, most importantly, to predict failures.
ISSUES DISCOVERED IN FIRST GENERATION VMS:
The principal shortcoming of the first generation VMS is its requirement for a technician to go aboard the train periodically and to perform a manual downloading procedure, which transfers data previously collected in realtime aboard the train onto a credit-card memory for subsequent offline analysis using the Dataview software. Among the issues raised by this requirement are the following:
Issue #1 The downloading procedure is labor intensive, error-prone, and it must be performed in the maintenance yard during non-operating hours; therefore, the monitored data will be obtained no more often than once per day.
Issue #2 Long intervals between downloadings will mean that the data is old -- not timely, which limits its usefulness in fulfilling the maintenance mission, especially in predicting failures.
Issue #3 Longer intervals between downloadings will mean large amounts of data being transferred and high pre-processing overhead -- many minutes even on the fastest processors -- for converting the information into database format.
Some of the consequences of these issues are intended to be obviated by onboard 'diagnostics' -- realtime fault detection that alert the train operator to certain classes of failures which can then be acted upon immediately. Notification of other classes of onboard problems can be relayed to the wayside by the operator by voice radio for maintenance planning.
Experience has revealed that onboard diagnostics incorporated in the first generation will raise issues of their own, which are additive to those above...
Issue #4 In order to minimize distraction of the operator, only the simplest kind of alert can be given to the operator -- essentially a 'go-no-go' indication.
Issue #5 To assure service availability, the onboard diagnostics must be strongly biased against 'the false alarm'; accordingly, there will necessarily occur excessive incidents of 'the missed threat,' a fact which sharply limits the usefulness of the onboard diagnostics.
Issue #6 As a practical matter, only crude algorithms can be implemented in the onboard diagnostics, which all but eliminates multi-parameter correlations and trend-based detection.
SECOND GENERATION VMS
It may seem obvious that a 'wireless download' will potentially deal with all of these issues. In the extreme, for example, the data might be transferred by radio links from the onboard system to a wayside network. The 'download' concept would then be replaced, in effect, by by that of 'telemetry.'
The 'telemetry' model relocates the intelligence from onboard processing to the wayside -- what might be called in railroading a 'dumb-train' approach for VMS. It also requires that the data be transferred more or less continuously -- or if not continuously, the data must be stored in onboard buffers during telemetry 'black-outs' for transfer as wireless links become re-established.
The operating expenses can become significant in a system using cellular telephones on each train. Morever, there are a number of technical problems with operating a 'proximity-relevant' network of multiple moving nodes. Wayside data interpretation would have to be managed in a prioritized multi-tasking mode, since data would be pouring in from the 'dumb trains' throughout operating hours.
After considerable analysis and reflection on the experiences accumulated from the first generation VMS, the MK/ASD team concluded that applying cellular telephones in this way may in many cases be going too far -- that a much more practical and economical architecture can be developed that resolves the issues set forth above and meets all the identified VMS requirements. We call it 'Transaction Based Monitoring.'
Still, the ubiquity of cellular telephony seems to offer a promising candidate for wireless messaging and has been selected by at least one supplier for the second generation of VMS. Whereas TBM may readily apply cellular telephones wherever they are appropriately supported by the operating environment, MK/ASD has favored low-cost modems in its design.
THIRD GENERATION VMS
In effect, MK/ASD regards Transaction Based Monitoring (TBM) as skipping the second generation, which typically demands high data rates and may then be forced to depend upon cellular-telephony or other wide bandwidth moving-node systems for wireless transfers of bulk data.
TBM applies modems widely available in the industry that are characterized by...
The onboard intelligence pioneered by MK/ASD and MNCR in System/86 is applied in TBM. More significantly, the huge offline capabilities of Dataview software will be fully exploited for achieving levels of diagnostic sophistication that are beyond those possible in the first generation VMS. The train operator is not distracted by the demands of real-time diagnostics and does not need to participate in TBM.
The guiding principal of TBM is to partition the diagnostic and reporting work between the vehicle and the wayside in the most 'time-relevant' way.
The expression 'time-relevant' gives recognition to the fact that information to be transfered in specific categories will be useful only at certain times -- times when the train is located in a place where the data can either be acted upon or relayed into a more broadly based network supporting the maintenance system for the preparation of work orders. The uninterrupted, continuous operation that is mandatory in a 'telemetry' concept does not apply. Moreover, 'downloading' of large amounts of data will be performed rarely and only as a consequence of the transaction content that precedes the transfer.
MK/ASD has architected TBM to perform information transfers using a heirachical structure of messages -- the Transaction Repertoire. In briefest summary, there are general three categories of transactions:
Category 1 ~~ all is well & routine train status,