I am guessing that no one actually got an intelligent transportation system for Christmas; not even those that are fans of slot cars or model trains. However, the old saying that ‘a puppy is for life, not just for Christmas’ has some relevance to those who are expecting to install new – or expand existing – ITS investments.
Throughout the working life of an intelligent transportation system there is a need for repair and maintenance of physical assets, particularly those that are exposed to a range of temperatures, humidity, dust and vibration. Electronic equipment is sensitive, even when ‘hardened’ components are chosen. The word ‘systems’ in ITS is important in this context as a complete solution is made up of numerous subsystems all working together. A fault in one component in one subsystem will often manifest itself as an apparently unrelated symptom in a completely different subsystem.
Tracking down the fault from a symptom is often a piece of detective work. Add in the layers of software that put the intelligence into ITS and the level of complexity is raised again. Worse, the old ‘switch it off and on again’ method will often result in the symptom disappearing, only to reappear at some point in the future, but in a slightly different form. Often maintenance is just the suppression of symptoms and not the solution. The upshot of this is that the cost of ownership of ITS can be higher than expected. Unfortunately ITS generally falls into the revenue budgets that are continually being reduced. In the UK, where there is currently a very aggressive political drive to cut public spending, it can be difficult to sustain the resources needed.
Design for maintenance needs to be given much more emphasis in ITS. There are three parts to this: designing out the sources of faults and building in resilience; improving tools and techniques for tracing faults from symptoms; and designing in features that enable repairs to be carried out safely, quickly and effectively. All need to be addressed. Bearing in mind that we are talking about systems, these stages need to involve their associated supply chains. Systems are only as good as their weakest link. Software embedded across a system is a particular challenge as seemingly minor incompatibility can manifest itself as a major loss of function. Standards are important in improving quality, but do they place enough importance on the maintainability of systems compared with, say, interoperability?
A key challenge is how to achieve these changes while keeping the capital costs competitive. There will always be some maintenance required and repairs due to external damage are also inevitable. However, much more attention to maintenance and repair during the requirements phase will reduce the whole-life cost. Bear in mind that an ITS is often quite visible to the traveling public and systems that always seem to be under repair quickly lose credibility. Paying for quality in operation is a good move in the long term. The key question is how do we get that outcome to be properly recognized in the procurement process?
