Statement of Pete Meisenzahl, Safetran

MR. MEISENZAHL: I'd like to thank the National Transportation Safety Board for providing Safetran the opportunity to speak on the subject of the future of rail recording capabilities and requirements. I'm going to try to avoid making this a sales presentation but I'm sure that the darn profit motive is going to get in the way.

I'd like to start off by saying, based on yesterday's spirited discussions, I'm not a lawyer. I'm not with the FRA. I'm not with a lawyer's group or have anything to do with videos, so today's presentation probably won't be that spirited.

I'm going to begin today's talk on the background of wayside rail recorders. I'll touch on the subject of log file retrieval. I'll spend most of the time discussing where we think the industry is going with wayside type data recorders, software tools and more future areas of development.

I'll focus today's presentation on the wayside recorder, not the onboard locomotive recorder, so this is a new subject we haven't talked about yet over the last couple of days.

The rail recorders themselves have some interesting safety and environmental aspects to them, and operate in a little bit different environment from most of the other recording devices we've seen presented over the past couple of days. The wayside recorder typically sits in a bungalow filled with batteries. Therefore, there is a fairly high concentration of battery acid fumes inside the bungalow. Operating temperatures of -40 to 160 F are required. And temperatures can swing 50 degrees in one day.

Rail recorders typically have been a single function in that they just pull data from let's say the relays that are inside the bungalow, and typically have been very simple in their operation. Retrieval of the logs has been previously accomplished through front panel displays or optional printer ports from which logs can be extracted directly to a line printer. But they've been pretty simple by and large. These devices were designed for solitary operation, not as part of a network or system architecture.

One of the first steps of advancing the usefulness and user friendliness of existing recorders is the ability to pull the logs. We've heard a couple of presentations where a criticism has been voiced that the user may have recorders from five or six different manufacturers. That means there are five or six different protocols the user must handle, not to mention different software applications, cables, and connectors.

Today, logs can be pulled from recorders from multiple devices, therefore reducing the need for proprietary user interface. For existing recorders, we have the ability to view log data from the front panel of the recorder. We also have the ability to go directly to a printer, which tend to be technology or protocol independent. We also have the ability to pull logs from the recorders by remote means, such as modems and radio based systems. In an effort to have some compatibility between devices that reside inside a bungalow, the ATCS standard was developed. The architecture presented here has been designed with ATCS in mind, as well as the radio-based communication.

And finally, you can communicate with the recorder from the local PC connected to the front panel. Retrieving log files is going to be easier in the future.

The way we see the system architecture moving is in a network based environment also known as the local area network. I'll use the word LAN interchangeably with network. The network hub resides in the central processor unit and, in this case, I'm showing a Processor/Display unit. The Processor/Display unit contains all the processing power, the memory (both CPU memory and Log data), the logic, and the network control.

The Processor/Display unit was designed with user flexibility in mind. The user determines the amount of memory required to capture a predetermined amount of data. That amount varies from railroad to railroad, and is based on the number of inputs used, the sample rate, and the number of train moves over a given time. For the rail industry, the amount of data collected usually reflects 3 to 30 days of train moves. With this architecture, you just define how much memory you want and order the recorder with that much memory. It's not unlike your PC where you just add more memory.

We then tie any of the input and output devices onto this bus. The processor display unit communicates with any of the input and out put devices attached to it and captures as much digital and analog information as needed.

Analog information that might be recorded would include battery voltages, light currents and temperature, while the digital inputs would record crossing relays, gate position relays, gate controls and any relay-based signal.

At sites with a particularly large number of events to record, such as interlockings, then expanding the system is just as easy as attaching another data I/O device (digital or analog) onto the bus. Furthermore, now that we have network-based bus architecture in the bungalow, we can connect new control equipment, like crossing controllers and motion sensors, via interface cards to the LAN. It's just a matter of inserting an interface card into the existing equipment that then makes that device network member and its parameters can be recorded. To connect a grade crossing predictor to the LAN simply requires an interface card. Now, train speed and a number of parameters previously unavailable can be recorded. Finally, you can tie any future LAN-based devices to the network and its parameters are then available to be recorded.

This next chart shows what might be a typical configuration out on the railroad. Here are a few sites with a data recorders tied to either a modem or a spread spectrum radio back to an office. The power of this architecture is that it can be connected in a point to multi-point configuration or a point to point configuration with a hubbing, therefore reducing the need for additional equipment in the field.

On the office side, the modems and radios are connected to a central server that would be also tied to a LAN in the office. The user can pull log data from remote wayside location while sitting at their office PC. You don't need to send somebody out to a site. Furthermore, it can be used by anyone tied to the company LAN.

If your company-based server also happens to be tied to the Internet, you have a link to the outside world. Taken to the extreme, anybody with a laptop and a cell phone can download logs at anytime from anywhere. The maintainers are no longer limited to offices and shops for the communications requirements.

I think the area with the most potential for growth is going to be in the development of user-friendly software tools. We see development in the areas of field-based software tools, office-based software tools and an integrated set of tools.

In deploying the field-based tools, the user needs to have separate security provisions. You don't want your maintainers to be able to go out and re-program the devices or clear logs or change the configuration parameters. So we offer just a maintainer's version, which only allows the logs to be downloaded, stored and viewed. These tools provide some minor log analysis to be performed on-site.

The full user's version allows the user to modify any configuration parameters, generate any of the ladder logic, and also pull data as necessary.

The office-based tools allow the user to download the logs remotely as well as program the equipment and receive alarm indications.

But once the data is in the office, what do you do with it? Well, we see a number of ways to analyze it. We want to be able to analyze it both in a textual form, in its raw form, and as a graphical representation. Graphs provide the means to put things in perspective and show events as they relate to each other. This graph shows the data from an actual train move over a day and a half period. And we also have the ability to zoom in down to the one-second level and see which relays flipped when and so forth.

Let's now talk about the future direction of this technology. The hardware systems are available and, in many cases, already installed. The design of the hardware has been such that the flexibility and expansion requirements have all been design in. The devices have all the means to capture data (as much data as the user requires) and communicate information via LAN-based architectures back to an office environment.

With the infrastructure in place, the railroads can use the equipment to make their systems safer and more reliable. To do that, I think the ability to perform remote testing is going to be very important. The ability to sit in an office and exercise a crossing at regular intervals and verify that the crossing worked will have tremendous safety and reliability implications. It will certainly reduce the maintenance costs of the railroad as a maintainer will only used in the event of a crossing failure - rather than using large teams of maintainers to perform periodic maintenance. They don't have to send someone out to a site every week, every day, every month to check on it. There are some FRA testing rules that would be difficult to perform remotely. But by and large, the majority of the test parameters could be performed remotely and we are currently working with one of the railroads to implement the required FRA testing using these product lines.

There are a couple of FRA test philosophies circulating in the rail community and I'd love to get into a detailed discussion concerning those philosophies but time won't allow us. But suffice to say I think that this is the direction that we're going.

Furthermore, now that all the equipment is deployed in the field, I think we can also do predictive maintenance. The field recorders are collecting a large amount of data. We can bring it back into the office, monitor it, and analyze it over time. If the light currents are monitored, for instance, we may be able to predict when a light will go out. The battery voltages could also monitored to determine when the batteries need replacing and maintaining.

I think this is going to be a very powerful feature. And again, I want to emphasize that the hardware is going to play a fairly minor role while the software and the systems integration is going to require the most development effort.

The final topic today is the integrated office-based software package. The package, which is in development now, represents the future for recorder-based systems. The package is called the Alarm Reporting and Management System, ARMS, which is a client/server based system operating on any of the Windows environments.

What's very important to note is that our customers are often not very computer literate. I think the population as a whole is tired of these very complicated computer programs. The office based tools of the future have to be user friendly and the user has to be able to define what they want to see presented to them. And every customer has different requirements for using the applications. Therefore, the software needs to be flexible in its design but it needs to be easy to use.

I'll spend just a couple of minutes describing the integrated office package. It's based on a network management software package. All the recorders are tied back into the network through the server, as I showed earlier and are controlled by a series of Windows-based applications. The Windows-based tools are a suite of software applications bundled together, not unlike Microsoft Office, which consists of Microsoft Word, Power Point, Excel and so forth.

The first application would be the ARMS Database, database management and builder, which would allow you to create and input all the site data for a given wayside location. You would include DOT number, milepost number, any telephone numbers, the maintainer who's responsible, any specific software, any specific conditions, alarms, priorities, and so forth. This database creates a huge map of the entire network of recorders. The ARMS Database then ties in with rest of the ARMS software applications.

The next module is the ARMS monitor, which is a real time monitoring and recording of incoming alarms. When an alarm is generated at the recorder level, it passes through the modems or radios or however you decided to get it back to the office. It comes through the network management unit to the ARMS monitor where it is displayed on a CRT. An operator acknowledges the alarm by double-clicking the text message on the CRT. The software sends the acknowledgement back through the network into the recorder, turning off the alarm. The alarm is recorded in its own separate database and, based on information that it got from the ARMS database, the operator knows how to handle it. He knows which maintainer to call, which phone number, which operations to perform because it was all decided ahead of time.

Most railroads don't have the ability to put somebody in the system 24 hours a day, seven days a week. Therefore, the next software module shown is the ARMS Exchange, which is a telephone voice messaging or paging. In the event that the ARMS Monitor is unmanned, the ARMS Exchange takes over.

Let's take the alarm again through the recorder, through the network management into ARMS Monitor. When ARMS Monitor is turned off, the alarm is forwarded to ARMS Exchange. Exchange then looks at the ARMS database, gets the phone number, and calls or pages the maintainer. The maintainer then receives the phone call at, let's say, 1:00 in the morning, hears a digitized voice saying there is an alarm at this location. The maintainer isn't too happy about this and just hangs up.

Monday morning, the supervisor wants to know what the heck happened and the maintainer says he never got the phone call. The ARMS exchange has a record that shows the phone call was picked up and the maintainer was on the phone for 17 seconds before hanging up.

Under normal conditions, the maintainer would get the phone call and key in a password. This action sends an acknowledgement back through the system to the recorder in the field and turns off the alarm. The maintainer is then responsible for that alarm. And you can see, this all happens very, very quickly. The railroad is aware of any potential safety issues or any maintenance problems, virtually real time.

The next module is ARMS Remote. This module allows the user to remotely control and configure all recorders in the field. Let's presume you have 100 recorders in service. Based on data that you've been capturing you realize that you need to change one of the voltage parameters. Well, it's a big job to go out and change 100 programs in 100 recorders. Using the ARMS remote, you'll be able to do a complete update of all your systems with just a keystroke. Suffice to say this application is password protected. Security is very important to the system. Other functions that can be performed using this application include system reset, clock synchronization, and remote monitoring.

The last two modules operate in the background and are not real-time. ARMS Edit used for editing and configuring the system prior to uploading the new program. This application can be used as part of the ARMS suite of software tools or as a stand-alone module used to configure recorders locally. ARMS ViewLog provides ability to retrieve logs and view them as I showed in an earlier slide. ARMS ViewLog also provides the user with the ability to print the log data and get the reports necessary to back up what you've been seeing and take appropriate action. As with ARMS Edit, this application operates either with the ARMS suite of applications or as a local tool for log extraction and data analysis.

Thank you for your attention.