From pioneers to experts
At Strukton Systems, we develop applications for the public transport information panels at underground stations and bus stops in Rotterdam, Eindhoven and, in the near future, Breda. Up till now, we have primarily worked with public transport data, but we can also include other information like advertising and safety instructions. We now also offer these dynamic passenger information systems for public buildings. This allows you to check all current public transport departures from the building’s hall, including rail and tram connections. You can include all sorts of information!
Around 2000, you could more or less call us pioneers in this field. We worked on passenger information systems for the Leiden bus terminal, the Rotterdam tram network and the Zuidtangent near Amsterdam Airport Schiphol. These were the first functional passenger information systems in the Netherlands that hadn’t been set up by the transport operators themselves. It was a learning process for everyone involved.
Passenger information is free
Free? Yes! In its concession contracts with transport operators, the Dutch government stipulates that they have to share their data free of charge. In principle, anyone can use these data to develop their own application. I believe the next step forward will be mobile applications, with data projected on your personal Google Glass. But for the time being, there’s still a strong need for public information panels at stations and stops.
Back-up for the timetable
As system architects, we design systems that process information. Everything boils down to the question: what does the customer want exactly? This is what we use as the foundations for our software architecture – whether the project involves dynamic passenger information or monitoring a building’s maintenance status. A DPI system seems simple enough, but it’s actually quite complex in terms of organisation. The reliability of the data supplied by the operator can actually make or break a system. And if Vodafone’s network is down, you won’t have any up-to-date passenger information to work with. In these cases, you need to have a back-up, so that the panels can display the regular public transport timetable.
Huge mass of data
To operate one of these systems, we need to collect all the data required for the application – supplied by all the operators – at a single central point. This leaves you with a huge mass of data, which you can subsequently interpret from a wide range of angles. You could say we’re the people who produce these ‘angles’: which information does the traveller want to see, and how can we present it in an organised way? Each bus stop, for example, has its own code, and we configure these codes for the information panels at the individual stops. This means that each stop is always supplied with the right information, so that passengers know exactly what the status of their connection is.
Back-up for contingencies
Theory is one thing, practice another: in real life, you tend to spend 20% of your time on the system’s functionality, and 80% on dealing with unforeseen situations and coming up with elegant solutions for these contingencies. What do you do, for example, when there’s a communication disruption, or when you have two buses on the road that both claim to be handling the same scheduled connection? Any situation you can come up with can be neatly dealt with via the software, but reality can hold quite a few surprises in store.