The great Prague cleanup. VARS system will cover telematics data

To get more than 150 thousand telematic devices spread around Prague into one “list”–this is the goal of the project Technical Inspection of Telematic Assets, which VARS BRNO is currently implementing at the Prague road administrator TSK Praha. “We are creating a smart system with artificial intelligence principles on top of the equipment registration itself, which will be able to monitor the life cycle of individual devices and manage the planning of revisions, repairs or replacement,” explains David Novák, Technical Director of VARS BRNO, explaining what makes the project exceptional.

How did the need for property technical inspection arise in TSK Prague?

Prague, the largest Czech city, has an enormous number of telematics devices from different suppliers and times–often from the time when it was rare to have digital documentation. In practice, tracing the warranty conditions or technical documentation when dealing with such assets is complicated. The management of approximately 150,000 devices is complicated and inefficient.

What do the 150,000 devices even include?

These are the visible parts of telematics – traffic lights, tunnel control, traffic light boards – and at the same time, sensors, controllers controlling individual intersections and, at the third level, power and communication infrastructure, for example, communication lines usually running through metro tunnels. We will include four thousand of these in the first step in the passport process, covering all possible types of equipment. The remaining ones will be added by TSK itself.

Is Prague exceptional in this aspect?

In scope, yes, but otherwise, all infrastructure managers solve or should solve a similar problem. We can see that they have recently realised this and are starting to address it.

What does their particular need look like?

Imagine a massive volume of equipment, each with a manual, a warranty card, and a service contract. For some equipment, the documentation is electronic; for others, paper; for some, the documentation is missing. The more such equipment there is, which is undoubtedly a trend, the harder it is for administrators to navigate. A piece of equipment malfunctions, and suddenly, they are wondering what they are entitled to, whether there is a service contract, and whether there is a contractual time limit for intervention or removal of the malfunction. We get all of this into one system.

How challenging is it to put together such documentation?

It amounts to detective work. Some documents are electronic, others are lying around in cupboards and must be found and digitised. In some cases, they are missing because, for example, the supplier has not handed over the documentation. In any case, it must be pointed out that the mere collection of documents is not the principle of the project.

So what is it?

The project has innovative potential; that’s how it was written. Our task is to create a system above the list of telematics assets that can track parameters such as warranty, lifetime, and service. And then, on top of that, processes that actively manage asset management can predict the likelihood of failure and suggest preventive service or equipment replacement–this was the superstructure that the client most appreciated, and thanks to which we won this project.

How do you track something like that?

The basis is historical data on individual devices’ lifetime and failure rate over time. If I take an elementary example, if we know that the lifetime of a piece of equipment is five years, then the administrator knows that if he has a hundred pieces of equipment and they are going to be five years old within a year, he will need to invest in them and he can plan that investment much more effectively.

Okay, this relates to the given lifetime of the device. But how can the system predict failures?

The system is linked to the maximum information that can be obtained in some objective way. Again, I will describe this using the example of a traffic light controller, a computer. For example, we can monitor the voltage conditions on the controller and link them to the diagnostics. From these values, we are able to detect anomalies that may indicate that a failure is occurring. At the same time, we can predict when that failure will occur based on experience with similar failures. If the system assesses such a risk, it can alert the administrator and suggest appropriate action.

It is also essential that the system can compare data from different telematics devices and put them into context–this can also reveal the causes of anomalies or faults that are not detectable from a purely data-driven perspective. For example, a problem with faulty traffic light components was solved in Prague. It took a long time to find the cause, and in the end, it turned out that the “defective” ones were mainly exposed to sunlight. Typically, our system can also help to detect such connections.

What is the project process from the VARS perspective? What are the steps?

In the first phase, we had to understand what the devices are, what they consist of, what information they contain and where it is stored. That was incredibly laborious and tedious work, which we have now finished. In the next step, we designed and launched the part that tracks the individual devices and their data. On top of these, we are now creating analytics and visualisation tools for ease of use. Gradually, the system will fill itself with information about checks, inspections and repairs. As soon as we gain a history of such operations, we can start to play with predictions.

How long does that history have to be?

Each device should have at least one life cycle to gain sufficient data. In order of magnitude, it is units of years after which this investment starts to pay off. The more data in the system, the more accurate the predictions will be.

How much does such a system require the inclusion of the human factor?

Maintenance, repair and replacement data will have to be entered manually. But even there, we expect to create a working client for the field workers that will guide them to solve the problem, contain documentation and suggest a typical procedure if it is entered into the system. At the same time, the field worker will be able to mark the task as completed. In theory, we can also link our system to third-party systems, such as manufacturers.

Does such a system have any advantages for the end user of the roads – i.e. drivers?

If the system can predict failures, there are ultimately fewer of them. Drivers will feel that. At the same time, the system brings better planning, which means more efficient management and savings for the road manager. For example, the budget can be used for further development of telematics, which should contribute to safer and smoother traffic. Also, for example, the project envisages an interface for the public to report faults.