In transportation, as with many other industries, evolving technologies and innovations are all progressing at varying rates. We have a Rubik’s Cube of various solutions and processes that work independently of one another yet are required to supplement each other in order to create efficiencies and streamline processes.
Permit systems, suspension databases, defect platforms, and payment systems are all trying to communicate from various platforms, and this can make for a tangled intersection of data. Thanks to the growth in cloud computing and the resulting dramatic rise in options for Internet of things (IoT) devices, our communities are more connected, our cities are becoming smarter and our enterprises more efficient.
We are living in an increasingly connected and data-driven world. It is no accident that those two things are inextricably linked. Our connectivity means that we now have access to unprecedented amounts of data relating to what people are doing and how they’re doing it.
That being said, data collection on the scale it exists today is only worthwhile if the information collected is accessible to those who need it. To harness the power of data, we need systems that can share that data and put it to use in scenarios where the customer can receive its benefit, with seamless user experiences that create positive outcomes.
So, what’s the answer?
Application Programming Interface (API) integration can bridge the gap between parking, public transport services and multi modal solutions, paving the way for the creation of multi modal transport hubs across the country, linking counties and cities, making economical sustainable transport accessible to all.
What is an API? An API is a set of defined rules that explain how computers or applications communicate with one another. They sit between an application and the web server, acting as an intermediary layer that processes data transfer between systems. A data interpreter, so to speak, that allows services and products to communicate with each other and leverage each other’s data and functionality. It enables companies to open up their applications, data and functionality to external third-party developers, business partners, and internal departments within their organisations. Developers don't need to know how an API is implemented; they simply use the interface to communicate with other products and services.
Conduent’s Permit system, for example, uses APIs to communicate with branches of local government, such as the Council Tax office, the DVLA and private organisations such as Experian.
- Council Tax Service (API) – Conduent use a council tax interface as a validation step within the permit issuance process. The API integration takes an input, for example a council tax number and/or name. If a successful response is returned this will act as a proof item, confirming a resident resides at the property that the permit is being issued against.
- Driver and Vehicle Licensing Agency (DVLA) Interface (API) – Conduent uses the DVLA Interface to support emission-based permits. The API takes a Vehicle Registration Mark (VRM) input and contacts the DVLA to return multiple vehicle details relating to that VRM. These details are then used to validate which emissions band a vehicle falls within and in turn helps determine the cost of the permit.
- Known Vehicle List (KVL) - Conduent also use APIs to support Oxfordshire County Council with its Zero Emission Zone (ZEZ) where we have developed a KVL (Assigned Rights Register). Within this we use multiple APIs to retrieve vehicle details. One of these is with the DVLA: where we have unretrievable or missing details, we then use several third parties to build up the data required. This is then used to list permits within a rules engine to support the price calculation for entering the ZEZ.
- Payment API – Conduent has had a payment APIs for many years that allows third parties to query the back-office database to retrieve Penalty Charge Notice (PCN) balances.
Systems need to seamlessly connect in order to keep our cities and counties moving. Fast forward to a world with automated vehicles. Vehicles that think for themselves when navigating the streets. Autonomous vehicles will need to communicate with, not only the road, but the kerbside. For this to be achieved all systems would need to speak a universal language - the language of data.
Whilst fully autonomous vehicles are not on our kerbside just yet, work is already underway. With the development of the National Parking Platform (NPP) managing data exchange between systems, based on the Alliance of Parking Data Standards (APDS) technical specifications, which will form the basis of the forthcoming ISO Technical Specification, and the revision of the CEN Technical Specification, the sector is moving at pace to make these dreams a reality.