Railway Bridge Health Monitoring System

In my last post I put forth the idea of using the unique capabilities and UX of the iPhone to help track defects in railways, which came about after my initial conversations with a friend from the railroad industry.

Hours into our conversation I was perplexed at the lack of proactive monitoring of the today’s bridges used by trains for transport.

Should a uniquely located bridge collapse, an energy crisis could ensue as a result of the coal fields in the northeast/midwest being severed from the southwest.

I looked at several existing methods and solutions used today to address this issue and drew from each to conclude in a refined approach to monitoring the health of railway bridges.

There were basically 3 design considerations which needed to be met:

  1. Easy to deploy
  2. Low Maintenance
  3. Long Term

The system had to be easily deploy-able were an electrician in the field could install the components of the solution. Obviously low maintenance is also key, reducing the total cost of ownership and Long Term reducing the need for personnel to visit these bridges.

Application Requirements:

In order to monitor the health of a structure, vibrations of the structure need to be gathered and analyzed to develop a baseline under normal conditions. Subsequent measurements of vibrations can then be compared to the baseline to determine if an anomaly exists.

To accomplish this requirement sensors (3-axis accelerometers) are placed throughout the span of the bridge collecting data. The frequency components of interest range between 0.25-20Hz, the measurements would need to take place 40 secs before and after the passage of the train and time synchronization between the sensors would also be a factor to take into account.

Existing approaches use technology such as Solar panels to supply power in remote areas, GSM for data transmission, GPS for time synchronization and a star topology for the sensors to communicate to a head node which would collect and transmit the data for analysis.

There are multiple problems here since solar panels are expensive, prone to theft, vandalism and damage; GSM data transmission isn’t always viable when there isn’t network coverage in remoter areas and relying on a head node to collect and transmit the data would be like putting all your eggs in one basket. If the head node failed, the system would stop working.

The techniques I came across with basically fell into 2 categories: Existing bridges and new bridges.

I focused on existing bridges since there are very sophisticated things being done with new bridges. Today engineers are embedding sensors and fiber in the concrete while the bridges are being built in order to take measurements, but this approach is obviously not viable for existing bridges.

The methods in use for existing bridges included visual inspection, wired solutions which were bulky, expensive and time consuming to setup and a few wireless solutions some of which were proprietary, not scalable and interesting work from India.

In summary there are several challenges in deploying such a solution at sometimes remote and hostile locations. A lack of power which calls for alternate sources of energy, a way to effectively and reliably collect and transmit the data for analysis and keeping installation and maintenance costs low.

Since the train comes and goes, so can the data collected by the sensors. The train would activate the standby sensors as it approaches the bridge and then collect the data buffered by the sensors after passing the bridge. This approach would deal with the transmission of data limitations while at the same time eliminating the need of power for this component of the system. The train would carry the data and uploaded it to a collection station.


To deal with reliability and power requirements the linear path Star Topology would be dropped in favor of a Mesh Network which provides TRUE self-organizing and self-healing properties. On top of the Mesh Network, TSMP (Time Synchronized Mesh Protocol) would be used providing more than 99.9% reliability and the lowest power consumption per delivered packet.

The key for achieving maximum reliability is to use channel hopping, in which each packet is sent on a different channel. In this case, transient failures in links on a given channel are handled gracefully, and persistent link failures that develop after the site survey do not destabilize the network.

Sensors of this type using this approach can last 7-10 years on a small battery meeting the application requirements.

Now to raise some money, build a working prototype and demo it to the Railway companies.

Enhanced by Zemanta

TrackInspector – Using the iPhone to track railroad defects

Over a glass of wine and cigar with a friend who works in the railroad industry, we began to talk about the technology in use to monitor the health of railways and bridges. I was truly amazed at the politics on maintaining these bridges, how fragile these communication channels are and how critical they are in maintaining the energy supply to major cities within the US. (more on this in a later post)

According to a recent Reuters article here, almost half of the electricity generated in the United States is supplied by coal-fired plants. These coal fields are found in specific coal regions within the US. Once the coal is mined the facility can negotiate a transport rate if there are competing railroad they can use.

Enter the FRA (Federal Railway Administration):

The purpose of FRA is to promulgate and enforce rail safety regulations, administer railroad assistance programs, conduct research and development in support of improved railroad safety and national rail transportation policy, provide for the rehabilitation of Northeast Corridor rail passenger service, and consolidate government support of rail transportation activities.[2]

Currently railroads are in their majority inspected manually on a fixed schedule, meaning that someone actually goes out and either inspects with the assistance of equipment or visually.

Equipment assisted inspections are performed by a variety of methods:

A list of methods used to detect flaws in rails:

These techniques can be used in a variety of different ways:

The probes and transducers can be utilized on a “walking stick”, on a hand pushed trolley, or in a hand held setup. These devices are used when small sections of track are to be inspected or when a precise location is desired. Many times these detail oriented inspection devices follow up on indications made by a rail inspection cars or HiRail trucks. Handheld inspection devices are very useful for this when the track is used heavily, because they can be removed relatively easy. However, they are considered very slow and tedious, when there are thousands of miles of track that need inspection.

My interest level rose when we talked about the current handheld inspection devices being used and how the iPhone could add an enormous amount of value to this market.

Today a handheld device is used to record the fault and subsequently docked with a Windows PC, in order to sync the data recorded with a centralized system where photographic evidence can be later attached.

The Federal Railway Administration Track Safety Standards determine how and what data needs to be collected to perform inspections, which got me thinking on the iPhone hardware capabilities and getting a proof-of-concept out. Later came the design and architecture of the TrackInspector iPhone app.

The iPhone application allows the inspector to enter GPS-assisted track location being inspected, defects found during the inspection including a photograph and any remedial action taken. The inspection is immediately time-stamped and transmitted over the cellular network (GSM) or Wi-Fi, to a database server where the data can be retrieved securely and on-demand from anywhere in the world using a browser like any other website. The secure server allows centrally archiving, analyzing and reviewing all inspections as well as visualizing trends in the infrastructure.

Something I am sure Railway companies like BNSF (Burlington Northern Santa Fe) or Union Pacific would be interested in.

More Details: http://www.lonehorn.com/portfolio/trackinspector/

Enhanced by Zemanta

Healthcare Electronic Clipboard iPad Application

Just after finishing up my first iPhone application I got involved in the Healthcare industry with the implementation of an Electronic Healthcare Records (EHR) system for a 3 location practice. Additionally I came across the video below on a Doctor from Croatia putting the iPhone to use in the field including remote diagnostic procedures and CPR with his own invention.


This brought about the idea of building applications for the healthcare industry for the iPhone platform. The iPhone though did not present the ideal device for doctors to use because of its size and difficulty in entering information.

After the release of the Apple iPad on January 27, 2010 the idea of an electronic clipboard didn’t seem too far fetched, so I put together a mock-up of what the app on the iPad would look like and can be seen below.

Enhanced by Zemanta

What is an AppDelegate?

Recently I needed to call an external process after an iPhone app I have been working on finished loading uploading tracking information to a web server.

The way to do this is by creating a custom class and then calling that _NAME_AppDelegate.m file within your code, but what is an AppDelegate?

The AppDelegate just sits there doing nothing, waiting to be told that something potentially important has or will happen. The application/iPhone OS is the one doing the work and calling the AppDelegate when it has or will do something that the AppDelegate (and by extension, you) might want to respond to in your code.

Here is a complete scenario:

(Starting at the iPhone’s home screen)
1. A user taps on your app’s icon.
2. The iPhone OS loads your app into memory and whatever else it needs to run your app. At this point, the OS has control.
3. The iPhone OS finishes its launch procedure with your app, and is ready to hand over control to it.
4. The OS calls your AppDelegate’s applicationDidFinishLaunching method.
5. Your code is now in control, starting with whatever is in the applicationDidFinishLaunching method of your AppDelegate.
. (User uses the app for a while)
6. User taps on the Home button to quit your app.
7. Since your app has no direct way of knowing when the Home button is tapped, the iPhone OS sends an applicationWillTerminate message to your AppDelegate, so you can clean up any open files, etc. before the app quits.

There are also other notifications that your AppDelegate can receive between launching and quitting, such as if your app is about to run out of memory.

Develop an iPhone Application


With the iPhone Apps store closing in on the 1 billion download mark, its hard to argue that it hasn’t been a huge success and even with the numerous applications available to do just about anything you can think of, there is still room for innovation as long as you keep an open mind and hold on to your imagination.

Standford has made available a course on iTunes that will have you creating your very own application in no time.



Reblog this post [with Zemanta]