When we started designing our latest telematics platform, we faced a challenge that many in the automotive industry are now encountering.
Modern vehicles rely on complex software stacks to deliver everything from navigation and infotainment to safety-critical features. These software systems need to be updated, extended, and maintained long after the car is sold.
To support this evolution, we needed an architecture that could manage frequent over-the-air updates, enable seamless integration of new telematics services, and allow us to scale features independently across different vehicle models and hardware platforms.
This is where service-oriented architecture (SOA) became a key enabler. By decoupling vehicle functions into independent, reusable services, SOA allows modern Software-Defined Vehicles (SDVs) to receive seamless software updates and enhancements.
In this article, we’ll take you behind the scenes of how we applied service-oriented architecture in building a flexible, future-proof telematics solution for SDVs.
What Is the Traditional Approach in Developing Telematics Platforms?
In the conventional sense, the telematics architecture takes the bottom-up approach. The development activities begin with the selection of the hardware. The hardware selected is a deciding factor in finalizing the other stages of the solution development – board support packages (BSP), the middle layer, and the applications.
How Does Service-Oriented Architecture Enable Telematics Platforms in SDVs?
The platform developed using a service-oriented architecture, considers the application and its features as top priorities. Based on this, the various stages of development of the telematics solution are as follows:
- Selection of platform-related services for the application – Middle Layer – Platform API Layer
- Virtualization of all the application-related features used by the end-users
- Testing of the application-related features
- Selection of suitable hardware for seamless functionality of the application
Service-oriented architecture aligns perfectly with the SDV ideology- delivering updateable & future-proof automotive solutions.
Developing Telematics Platform for SDV – A Breakdown
In our project, we followed the top-down approach, suited for implementation on Software-Defined Vehicles. Here is an architecture diagram of the telematics solution:
To develop the telematics solution using the service-oriented architecture, we followed these steps:
- Start by defining the platform API layer (SOME/IP). This layer defines all the APIs required for the platform OS and hardware access.
- Define all the OS-related interfaces under the platform API layer.
- Create libraries to store the defined platform APIs.
- Deploy the libraries in containerized environments (Container Runtime)
The platform API layer (SOME/IP) provides a foundation for the telematics architecture. The capabilities of this foundation allow us to develop the components for the above layers without relying on the hardware.
Let’s look into the next layers:
- Design the middle-layer/service layer topping the platform API layer and the containerized environment.
- The middle layer contains reusable components or stacks. The reason behind developing reusable stacks is to give the customer the freedom to utilize them as needed.
- The reusable components deliver communication, telematics, , and vehicle data-related information to the user.
- The application layer (SOME/IP) is defined and deployed to a containerized environment. We developed a hardware platform with a high-performance application processor and a microcontroller with real-time processing for the vehicle interface.
Using software-oriented architecture, customers can develop telematics applications to deliver critical vehicle information to their users.
Integrating Digital Instrument Cluster into the Service-Oriented Architecture
Service-oriented architecture has several advantages – the main one being its potential to be extended to include modules for a digital instrument cluster or in-vehicle infotainment.
Here’s an architecture diagram of such a solution:
- Modules for digital instrument cluster (DIC) can be added to the telematics solution architecture, and these have been indicated as DIC Processor components in the diagram above.
- Multiple applications can be developed on a single hardware using Hypervisors. This is made possible by topping the hypervisor with multiple operating systems and a common platform API layer.
- We can deploy different virtual machine operating systems for each module – For eg. Linux OS for Telematics Processor and Android Auto OS for Android-based DIC or IVI.
- Digital Instrument Cluster can be accommodated by reusing the many common components in the platform layer through the Platform API layer (SOME/IP).
Microservices & Virtualization in Service-Oriented Architecture-Based Telematics Platform
Keeping the primary architecture the same, we have given the provision to design and implement the service components as microservices. These must have defined standard APIs.
The platform health manager administers the health of the microservices and controls their start-up and shutdown states.
Scope for Virtualization
Virtualization future-proofs the telematics solution for SDVs.
There are two concepts of virtualization:
Concept 1: Virtual Machine Concept with Hypervisor
This concept is feasible when we have the physical hardware ready. Using hypervisor, we can deploy multiple OS and applications on the same hardware. This virtualization concept is implemented to integrate digital instrument cluster components into the telematics architecture in the above sections.
Concept 2: Virtual ECU Concept with Cloud Native Platform Deployment
This concept starts by defining the platform and application APIs in the libraries. The next step involves deploying the libraries to the cloud as virtual ECUs.
This part of the concept takes inspiration from the processor used in AWS platforms called AWS Graviton. The processor enables users to develop and deploy middle and application layer libraries on the cloud. By doing so, users can create applications on the cloud without depending on the hardware!
This concept allows the development and testing of applications ahead of time, complementing the SDV principles.
When the hardware is ready, the tested codes from the cloud undergo loop testing for their integration on the hardware.
Benefits of Virtualization
The concept of virtualization is resource-efficient. Here’s why:
- Different user applications with custom OS can run on the same hardware, irrespective of the Host OS over the virtualized CPU, memory, and I/O resources.
- Virtualization can be at the hardware, OS, Library, or Application level.
- Users can concurrently work on the hardware from anywhere in the world.
Key Features of Our Telematics Platform Based on Service-Oriented Architecture
Our telematics solution for software-defined vehicles offers the following advantages:
- Scalability
- Modular Architecture in SDV
- Open-Source Compatibility
- OTA Updates
- Configurability
- Safety
- Security
- Service-Oriented Architecture
One can extend hardware abstraction with a hypervisor to other virtual machines like Android Auto OS, and deploy and execute multiple application components with common API libraries using containerization.
Service-oriented architecture allows modularization by incorporating independent microservices with plug-and-play functionalities. The architecture can accommodate new services or application components based on requirements without affecting the existing system.
The platform API layer enables developers to integrate open-source libraries for Cloud Connectivity, OTA Clients, RTOS, Edge Components, and more.
The OTA components handle the complete OTA update process – download, verify files, and update the vehicle or itself. The upgrades follow an A/B partitioning approach to ensure fail-safe upgrades and support partial updates with a different image, which requires support from ECUs.
The service-oriented architecture uses reconfigurability to engage and disengage specific vehicle parameters, alerts, and features.
It is possible to achieve by executing safety-critical applications with ASIL-A/B at the Edge Device and executing QM applications on the cloud.
Multiple levels of cybersecurity libraries are present for the security of external communication, internal communication, secure boot, and secure update process.
We have implemented all the components as microservices, with defined APIs exposed through SOME/IP. Other services utilize these APIs via service-oriented architecture calls. We have also enabled service discovery and token-based service authentication for each service component.
Modern Telematics Solutions Require Modern Security
A solution as novel as this required our undivided attention in designing its security infrastructure.
The security infrastructure of the telematics solution included the following components:
- Crypto Libraries
- Security Service and Data Protection
- Hardware Security Module Interface
- File Integrity Check Libraries
- Communication Security
- Vehicle Network Security Libraries
- External Access Management
The key piece to the security puzzle was the designing of the telematics gateway connected to the cloud externally along with Bluetooth, WiFi, and USB connectivity.
This architecture enables the adherence to functional safety at the device level for critical decision-making. Additionally, it allows for moving Quality Management services up to for non-critical decisions.
Securing Hardware and Software Platform
- Launching the applications using the secure booting process.
- Downloading the latest updates using secure upgrade protocols.
- Implementing security engines and storage interfaces using the Hardware Security Module (HSM).
- Deploying Software Security Libraries (AES and RSA).
External Connections Security
Secure external connections in the service-oriented architecture are assured through OTA File Integrity and Authenticity checks. These checks follow cryptographic best practices such as public key infrastructure for token and image signing.
Securing Internal Module Access
- Integrating security features into each telematic service.
- Integrating security protocols to monitor and enable application and interface interactions.
- Granting token-based access to applications for connecting with the platform or APIs. These tokens need to be authorized to initiate access.
Securing Vehicle Network Access
- Network Security
- Seed/Key Algorithms
- Secure External Access
Wrapping Up
Embitel’s Telematics Platform for Software Defined Vehicles (SDVs) signifies a transformative leap in automotive technology. The service-oriented architecture and emphasis on virtualization ensure adaptability to evolving industry needs.
The integration of Digital Instrument Cluster modules and the flexibility of virtualization concepts demonstrate a commitment to future-proofing. Crucially, architecture’s robust security measures at every level underscore its resilience against potential threats.
Our telematics solution emerges not just as a contemporary platform but as a forward-looking paradigm, embodying scalability, modularity, and security in the ever-evolving landscape of smart and connected vehicles.
