Service Architecture

The services architecture for Connected & Autonomous Vehicles must not only address connectivity, vehicle data integration and autonomy alone. Each of the these can be achieved in a siloed fashion presenting potential opportunities for advancement however a big picture view of the emerging ecosystem is required to capture the real potential of this market.

The enablement of new services and efficiencies realised through linking Vehicles, Infrastructure and the Cloud surmount anything that can be achieved by each on their own. Work package 5 looks at tying the three segments of Vehicle, Infrastructure and Cloud together into an Alloyed Architecture.

For vehicles to operate autonomously, they must be able to perceive their environment, plan optimal routes and take decisions. Data gathered through on-board vehicle sensors can be fused with map data and some form of 'passenger' input to instruct vehicle actuators to drive the vehicle. Roadside systems such as traffic lights, speed detection and warning systems and cameras can help Infrastructure operators to plan and route traffic based on road and traffic conditions. They can also provide a broader external view to connected and autonomous vehicles adding the ability to detect and interact with non-connected entities such as traditional vehicles, cyclists and pedestrians. Connecting both Infrastructure and Vehicles to the Cloud through a Data Broker allows service providers to exchange data and facilitate the creation of microservices.

The key to addressing limitations of existing systems and models is to design an architecture covering each of the three segments of vehicles, infrastructure and cloud, where each segment is able to exchange data where needed while considering user anonymity and security.

The main objectives of the work package are to -

• Create 'open' access to application and services providers addressing multiple use case scenarios
• Consolidate use case architectures developed during the project into a common architecture (i.e. Alloyed Services Architecture)
• Identify and plan for key prototype systems that can be designed to demonstrate the services architecture in a live demonstration with an initial focus on an LDM application

The project team has approached the service architecture design by looking at a range of common services elements applicable to the sector. These include everything from user & device management, app development environments to APIs across segments. A key consideration for the service architecture is to allow intelligence to sit within or across one or more segments depending on the use case or service.

Architecture Service Elements

A delineation has been made on service types based on whether the data being exchanged is considered 'Open' and available to all or 'Closed' and available only to limited parties. Another consideration is whether the data needs to be 'Secure' by having specific security mechanisms limited to one or more parties. Lastly a further category is identified as being 'Hybrid' where data is largely closed but made available only for transactional processes such as for automated payments.

Services Delineation

This work package thereafter defines the overall architecture for communications and interaction. It considers all the use cases developed as part of the project, identifies a suitable architecture for each and finally defines a common architecture which can accounts for all use-case requirements. This is documented in a detailed design package, which can be used to implement the system.

Common Software Architecture

A number of product and service opportunities are identified leading up to the end of work package 5 including -

• On-Board Unit (OBU) - development of both a factory install and aftermarket on board unit capable of delivering capabilities required to deliver the use cases developed
• Roadside Unit (RSU) - development of a roadside unit capable of integrating with existing traffic systems with the added capability for peripherals integration such as computer vision sensors
• V2X Stack - a standards based V2X stack for V2V and V2I communications with custom development for sensor integration
• Access Technology Integration - hardware and software development of 802.11p, 4G LTE and 5G access modules to be used in On-board Units and Roadside Units.
• Data Broker - a cloud based device management and data processing system connected to On-board units and Roadside units via multiple standard protocols (e.g. MQTT, AQMP)