Custom Software Development
A fast, reliable communication and processing solution for receiving and responding to vehicle and driver sightings from various sources.
Problem:Aurecon needed a fast and reliable processing solution for receiving and responding to traffic data. The system needed to enrich collected data with additional information from external sources, determine additional actions (for example, alerting on transgressions), and route output to interested parties.
Solution: Architecting a communication middleware concerned with retrieval and routing of traffic related data between integrating parties.
We developed the Communication Logic Engine (CLE) system for the Aurecon Group. CLE retrieves and correlates information in near real-time about vehicles sighted by roadside sensors; more specifically ANPR traffic cameras, vehicle mounted cameras, and roadside “stop and approach” user events.
The system retrieves vehicle and driver information from eNaTIS, looks up information on taxis and buses, checks for transgressions in static data, calculates average speed over distance to check for speed transgressions, and correlates and distributes this information to authorised external parties.
One of the primary goals of the system is to be as efficient as possible and to make use of parallelism where applicable.
The CLE is a mission critical system and downtime interferes with the ability for integrating parties to perform their work. Law enforcement is presently the biggest user of CLE and thus it is imperative that the system is highly available.
The system should also be able to scale even further and handle more messages if necessary at a later stage.
The foundational technologies of CLE include:
C# 6 is a development language used for all endpoints, whereas Managed Windows Services handles the hosting of all service endpoints. We chose ASP.NET MVC for the web-based system health dashboard, and ASP.NET WCF Services for receiving ANPR messages from cameras.
The majority of CLE’s hosting is on the Microsoft Azure cloud platform, with most of the system hosted on Azure Virtual Machines. We chose to use both Azure ServiceBus and NServiceBus for reliable messaging by all endpoints. Redis Cache ensures that vehicle and driver information is cached for easy access.
For monitoring purposes, we make use of Application Insights, and Table Storage is utilised to assist with long term audit data. SignalR has been implemented for near real-time server push communication to the health dashboard.
The overall system architecture leverages many Service-Oriented Architecture (SOA) concepts, with the Azure ServiceBus serving as the central input/output hub for data transformation, processing and enrichment. It is capable of receiving, transforming, enriching, and routing messages, as well as dispatching outputs to relevant systems.
The primary non-functional requirements of the system are reliability, speed and fault tolerance. With these guiding principles in mind, our architectural team spent a lot of time refining the architecture, constantly aiming to expand the capabilities of the system without incurring unnecessary latency.
In order to report on and monitor performance issues and overall system health, metrics are emitted to Azure Application Insights and Azure ServiceBus.
A dashboard displays near real-time system health and monitoring results based on predefined thresholds:
