or how we got playful in search of a remote condition monitoring solution.
In our continuing series of posts about the different stages that a software development project goes through from start to finish we constantly find ourselves saying “every project is different and we have to vary our approach accordingly”.
At one end of the spectrum we have projects where the requirements are very well defined, everyone has a clear picture of what the solution will look like, and the route for getting there is can be described accurately at the outset. At the other, however, are projects where the requirements are vague, it’s not clear what shape the solution will take and there’s no prescribed route for arriving at the answer. The first type requires a systematic and formalised approach, the second calls for imagination and creative problem solving capabilities.
A good example of this second type of project is one recently commissioned by the Rail Safety and Standards Board (RSSB). It is a part-funded project under the Future Railway RCM competition. Our proposal was to examine the feasibility of developing a remote monitoring system that would detect the presence of human beings and potentially dangerous objects on or near to rail tracks.
As you can imagine there are a number of challenges to overcome and it has allowed us to demonstrate our Heath Robinsonish ingenuity!
The Rail Safety and Standards Board (RSSB) helps the industry to understand risk, guide standards, as well as manage research, development and innovation. It promotes collaboration with a view to achieving continual improvement in the business of moving people and freight safely and efficiently by rail.
The development of effective Remote Condition Monitoring (RCM) systems that identify potential problems before they develop into something more serious is a top priority for the Rail Industry. If such systems can be developed and implemented they have the potential to greatly improve both rail safety and punctuality.
There are many things that RCM systems can monitor, but our proposal focused on finding a way to use forward facing CCTV cameras on trains to detect potential hazards on and around rail lines and then raise alarms as appropriate.
We set ourselves the objective of developing a low cost solution that can be retrofitted to existing trains equipped with forward facing cameras and which could also be incorporated into new CCTV systems supplied in the future. The system will monitor, in real-time, CCTV images to detect:
- Signs of unauthorised human incursion within the boundary fence, including trespass and vandalism. The key point being “unauthorised” – the system had to be capable of filtering out human beings in full high visibility wear or in public areas.
- Trees or other objects which have moved from their position on reference images, or database of known assets, with the objective of identifying whether they have moved significantly and may be encroaching on the track, or whether infrastructure assets, such as signs or signals, have become obscured.
The Feasibility Phase
The first phase of the project is a feasibility study to determine whether the overall objectives of the system could be met using current software technology and techniques.
Our focus in this phase was to develop some basic software to trial a number of approaches to detecting changes in the CCTV imagery.
We decided to record and compare two different journeys: a baseline journey of where we are confident there are no changes to detect, and a subsequent journey to see if any changes have subsequently occurred. This would allow us to identify any discrepancy between the two journeys that exceeded the normal background changes. We could then alert the user to such changes.
Overcoming the challenges
The project involves several awkward technical problems that we have to address before we can even begin to attempt to create a final solution. This is where we went into full ‘Heath Robinson contraption’ mode.
Controlling the local environment
We had a few videos of train journeys, but no way of creating changes within them. We therefore created our very own ‘train’.
Initially, this was a moving trolley with a web camera mounted on it and connected to a laptop for recording and processing the data. We then ran this up and down the Zircon offices to create a series of journeys. To make certain each journey was identical we ran a masking tape ‘track’ down the middle of the hall and marked off starting and end points.
Although the trolley worked well, none of us could walk the same speed each time, every time. We had to develop a way of equalising each journey. We initially constructed a tachograph from an old door alarm and several magnets. This ‘ticked’ each time the wheel completed a revolution and gave us an exact distance reading that we could use to smooth out the journeys in the program.
However, we eventually settled on using a toy train that belonged to the son of our Operations Director! This ran on its own track at a constant speed. This meant that we were able to eliminate a number of variables and allowed our software to focus solely on detecting changes to the local scenery. Which led us to …
Finding a Change
We had to find objects we could easily change or move – ranging from chairs to inflatable cacti, we eventually settled on the office potted plants and Christmas trees which did a great job!
Looking at the data
We were unsure about how the values created by the program would react to changes in the environment. This meant we needed some way of seeing them. This we solved by writing a csv file which we could then open in Microsoft Excel. We then ran that through a multitude of filters & modifiers to produce many different graphs.
The Zircon office is busy …. people drink a lot of tea and coffee!. Preventing people wandering into shot was a continual challenge!
Eventually, we managed to create a great test environment in which to experiment with different approaches, solutions and refinements. We were able to come up with ideas, put together test programs and gather data very quickly. Sometimes we would think of a solution, toss together a test program, and have data by lunch to analyse.
The outcome of this creative problem solving process is a feasibility report that is now being assessed by the RSSB before work commences on the next phase of the project.