ASPICE-compliant high-precision drive analytics for Tier 1 automotive supplier
About the client
Our client is a top manufacturer of automobile components catering to the US and EU-based OEMs. With decades in the market, the company strives to deliver automotive electronic solutions for a safe, smooth driving experience.
The challenge
For the company’s customers, it’s important to be able to record and analyze driving experience using every piece of data possible to get. For this, our client designed an add-on data analytics solution providing synchronized video and data recording. However, to work properly, the solution needed a data logger component.
Since the component had to be a part of the automotive system, the client needed to develop it in accordance with industry standards — ISO 26262 and the ASPICE framework.
Delivered value
The solution
Within the client’s analytics solution, the data logger had to act as a telemetry collection and processing engine.
Its function was to ingest the ride video stream from the connected camera, GPS tracker data, and other relevant metadata, such as speed or brake pressure. Then it had to aggregate the data, sync it by timestamp, and save it to an SD card as a reproducible video with overlaid dynamic ride stats.
To follow the ASPICE framework, the development process took consecutive phases: from system decomposition and requirements formulation, through implementation, to rigorous validation and integration, unit-by-unit.
Requirements analysis and architecture design
The team started by aligning the data logger component’s design with the entire system's characteristics and architecture, formulating Software Requirements, Software Architecture Design, and Software Detailed Design.
Working out the component details was a major part of this stage. To enable proper real-time data ingestion and telemetry synchronization with the video stream, it was important to consider latency, timing, and edge processing nuances. For example, every data point had to be synced with the “master clock” so that, let's say, the brake pressure indicator would align perfectly with the video frame in which the driver hits the brake pedal.
Implementation
The data logger was designed to run on top of Debian OS. To complete the required function, the logger consisted of multiple microservices that communicated via D-Bus and performed dedicated tasks:
- Time point tracking
- Map creation based on location data collected from the GPS tracker
- Metadata extraction
- Data synchronization
- Video recording to an integrated SD card
- Bidirectional communication with the media system via the automotive Ethernet.
DevOps and CI/CD automation. Deploying the data logger required a tailored Debian OS image optimized specifically for the client’s electronic control unit (ECU). Because any modification or service addition demanded a full image rebuild, our DevOps team implemented a robust CI/CD pipeline. This automation guaranteed stable, reproducible OS builds while maintaining strict adherence to the automotive industry standards.
DevSecOps and custom SBOM generation. Compliance requirements mandated comprehensive SBOM (software bill of materials) generation. However, off-the-shelf security scanners frequently misinterpret the ECU’s non-standard packages. To overcome this, a custom Python-based DevSecOps tool was developed. This flexible script filtered out irrelevant dependencies and provided accurate, clean, and complete component descriptions, ensuring flawless security reporting.
Unit verification and integration testing
When implemented, every developed software unit, microservice, module, and component was verified against the software design, architecture, and requirements with automated Python tests. To test the software integration with the ECU firmware and service communication, we used the hardware-in-the-loop approach. For this, the client provided us with a local and a cloud-based Azure hardware test bench for emulating real ECU signals, such as GPS data, car speed, or acceleration.
How it works
