Blog Archives - Page 2 of 20

13 March, 2025 . 6 mins read

Exploring Maneuver Sharing and Coordinating Service (MSCS) in Autonomous Driving

Autonomous driving is advancing rapidly, with self-driving cars being tested in urban mobility, highways, and logistics. Have you ever wondered how these vehicles communicate to navigate safely? Unlike human drivers, who rely on signals and intuition, autonomous vehicles use data-sharing systems. This blog examines the limitations of cooperative driving systems and introduces Maneuver Sharing in Autonomous Driving through the Maneuver Sharing and Coordinating Service (MSCS) as a solution to improve vehicle communication, safety, and efficiency.

Current cooperative autonomous driving systems rely on Basic Safety Messages (BSMs) within Vehicle-to-Everything (V2X) communication. Each vehicle regularly transmits BSM data, sharing essential information such as speed, position, and heading with surrounding vehicles. This allows vehicles to assess potential collision risks and respond accordingly.

However, BSMs alone cannot convey the intent behind a vehicle’s movements. As shown in the graph below, a BSM provides only fundamental status data without explaining why a vehicle is moving in a certain way.

In other words, while BSMs enable cooperative autonomous driving, they lack the capability to communicate driving intentions. If vehicles could understand the purpose behind each movement in advance, particularly in emergency situations, driving safety and efficiency would significantly improve.

Real-World Scenario: The Need for MSCS

To illustrate this, let’s define two key entities:

HV (Host Vehicle): The vehicle transmitting its movement intention.
RV (Remote Vehicle): The vehicle receiving the movement information.

Now, consider a different scenario: What if the HV had already informed nearby RVs of its intent to change lanes in advance? In that case, the RV could adjust its route ahead of time, leading to a smoother and safer driving experience.

The same idea applies beyond driving. In any situation, whether at work, in school, or during teamwork, understanding someone’s intentions before they act allows for better planning, coordination, and overall efficiency.

What is MSCS?

To overcome the limitations of BSMs, the Maneuver Sharing and Coordinating Service (MSCS) offers a smarter approach to cooperative driving.

MSCS enhances V2X communication by enabling vehicles to share their intended maneuvers. Understanding the purpose behind a vehicle’s movement enables better analysis and response, enhancing overall road safety and efficiency.

Unlike traditional BSM-based driving, which reacts to real-time data, MSCS enables proactive decision-making by considering the planned maneuvers of surrounding vehicles. This advancement leads to a smoother and more coordinated driving experience.

MSCS operates in compliance with SAE J3186 standards, which defines its primary use cases as:

Cooperative Lane Change
Cooperative Lane Merge

These scenarios demonstrate how MSCS enables smoother lane changes and merges by allowing vehicles to communicate their intended movements. Through MSCS, vehicles notify one another and cooperate to execute maneuvers safely.

It is important to note that MSCS is designed to function based on vehicle intent and follows two distinct communication protocols:

General Vehicle Protocol: Requires mutual negotiation through request and response interactions.
Emergency Vehicle Protocol: Prioritizes emergency vehicles (e.g., ambulances, police cars) without requiring negotiation from surrounding vehicles.

In general, standard vehicles (following the General Vehicle Protocol) must yield to emergency vehicles (following the Emergency Vehicle Protocol). This ensures that special-purpose vehicles can operate efficiently without mutual negotiation.

By implementing MSCS, vehicles can share movement intentions, enabling others to adapt proactively. This results in safer, more efficient, and cooperative autonomous driving.

MSCS and MSCM

Next, let’s differentiate between MSCS and MSCM to explore the operational aspects of MSCS.

MSCS (Maneuver Sharing and Coordinating Service): The overall system that enables maneuver coordination
MSCM (Maneuver Sharing and Coordinating Message): The message exchanged between vehicles to communicate movement intent

The graph below illustrates the structure of MSCM:

In MSCS, a Maneuver represents a coordinated movement involving multiple vehicles, while a Sub-Maneuver refers to the individual actions each vehicle takes to carry out that Maneuver.

The Executing Vehicle (HV) initiates the Maneuver request and identifies surrounding Affected Vehicles, which receive MSCM messages to coordinate movement. HV must obtain agreement from Affected Vehicles unless it is an emergency vehicle.

MSCM Data Structure

MSCM messages contain key data components, including the MSCM Type, which classifies messages into one of eight types:

Additionally, each Maneuver in MSCM consists of multiple Sub-Maneuvers, structured as follows:

In conclusion, there are 8 types of protocols for each Maneuver in MSCM.

MSCS Operational Process

To understand the operation of MSCS, let’s examine how it functions in standard vehicles. The system follows three sequential stages:

Awareness State
Maneuver Negotiation State
Maneuver Execution State

Awareness State
- This is the preliminary stage of MSCS operation
- While vehicles are aware of their surroundings via BSM, they have not initiated MSCS yet
- Only MSCM Type 0 messages (intention notifications) can be sent in this stage
Maneuver Negotiation State
- Vehicles begin negotiating the execution of a Maneuver
- Emergency vehicles skip this step, as negotiation is not required
- MSCM Types 1-3 are used to request and confirm Maneuvers, while Types 4-5 handle cancellations
Maneuver Execution State
- Vehicles execute the approved Maneuver
- The HV and RV reach a mutual agreement and act accordingly
- MSCM Type 7 messages confirm execution, and the Maneuver concludes when all Sub-Maneuvers are completed.

In conclusion, Maneuver Sharing and Coordinating Service (MSCS) represents a significant advancement in autonomous driving, allowing vehicles to communicate their movement intentions and not just their basic status. By enhancing Vehicle-to-Everything (V2X) communication, MSCS improves safety, coordination, and efficiency on the road. Unlike traditional systems that react to real-time data, MSCS enables proactive decision-making, particularly in complex scenarios like lane changes or merges.

With protocols that prioritize emergency vehicles and ensure smooth coordination, MSCS creates a structured environment for vehicles to work together seamlessly. This proactive approach helps prevent collisions, reduces traffic congestion, and leads to safer, more efficient roads. As autonomous vehicles continue to evolve, MSCS will be at the forefront of shaping a future where roads are not only safer but also smarter, bringing us closer to a fully integrated, autonomous transportation system.

To stay informed about the latest news on mobility tech and software-defined vehicles, read our blog for more technology insights or subscribe to AUTOCRYPT’s monthly newsletter.

6 March, 2025 . 7 mins read

Taking Charge with the Transition to SDVs: Autocrypt’s presence in Europe, an interview with Joohwa Sarah Lee

The automotive industry is going through a period of transformation: with electrification, automation, and software becoming the stars of the show, the traditional automotive industry in Europe has been through the ups and downs of trying to keep up with the Joneses. Established car manufacturers have realized that to navigate the transformations, quickly implementing and introducing new technologies to build innovative business models will be key.

joohwa sarah lee autocrypt svp — Joohwa Sarah Lee, SVP of AutoCrypt Technologies GmbH

Anticipating these changes, Autocrypt established its European subsidiary back in 2021, and has been working with its European partners and customers to ensure that new innovations go hand-in-hand with secure, resilient environments. And as we head into 2025, we sat down with Joohwa Sarah Lee, who leads Autocrypt’s European business, to discuss the current landscape in Europe, Autocrypt’s strategies, and what we can expect moving forward.

Q: Sarah, could you tell us a bit about yourself, and what you do?

Hello – I’m Joohwa Sarah Lee, SVP at Autocrypt Technologies. I’ve been in the automotive space for nearly two decades now, first as an R&D engineer at a major German automotive manufacturer, gaining extensive experience in vehicle thermal management systems, HVAC and battery systems.

My background is in mechanical engineering and computational science engineering (CSE), but I’ve really enjoyed being a part of all areas of the automotive business, from open innovation to even tech scouting, collaborating with internal development departments. At Autocrypt, I’ve been working with creating innovative partnerships with manufacturers and suppliers, and especially highlighting to them the importance of regulatory compliance in the current automotive landscape.

Q: Wow, your experience is quite extensive in the automotive industry – what got you interested in this industry in the first place?

I’ve always been interested in cars, even as a child. I remember as a child growing up in Korea, I saw a Ferrari F50 for the first time – its lines and color were so striking, it’s embedded in my memory. When I was trying to figure out what to study at university I vacillated for a while between automotive design and Engineering. I’m glad I chose the latter, but even more glad that engineering brought me to work in the automotive industry. Though I’m interested in a lot of different areas, be it engineering or business or recruiting, I don’t believe I’ll ever stray from the automotive sector.

Q: You’ve had quite a career in the automotive sector: What would you say has been the biggest change you’ve seen in the industry?

The transition from internal combustion engines (ICE) to electric vehicles has most likely been the biggest change in the history of the industry. I’m based in Germany, and this is a country where until the mid-2010s, the country’s ICE technology was world-class due to its decadeslong history in engine research and innovation. German manufacturers have been slower to adopt EV technology, which allowed for other competitors to push their way into the market. Despite those challenges, though, the European market remains one of the largest and most important, so it’s exciting to see governments looking to boost innovation through policy and regulatory support. This will play a crucial role in keeping Europe’s automotive leadership alive.

Q: What is the biggest challenges facing the industry as we move forward?

Along with electrification, the transition from traditional architecture to software-driven vehicles is going to be a challenge for legacy manufacturers, compared to the newer EV manufacturers. The shift from a distributed structure to domain and zonal architecture requires a lot of research, time, and human resources. While a lot of OEMs agree that transitioning to SDVs is the right move, it’s difficult to change architectures that they have maintained for decades.

Q: So what can they do?

Ultimately, SDVs are the right move, but we have to talk numbers. With SDVs, manufacturers can definitely expect higher profitability. Take Tesla, for example. They achieved a 22% operational profit margin in 2022 through their subscription models such as FSD. Vehicle and user apps and APIs have become a critical factor when it comes to consumer purchasing decisions – a McKinsey report said that 50% of EV buyers said that they consider connectivity features a major priority when it comes to a new vehicle purchase.

SDVs also contribute to cost savings in development. Simulations and virtual testing not only cost less, they are much more efficient in terms of development and prototyping. Furthermore, after SOP, software updates will be far less costly than a hardware change. Ultimately, SDVs aren’t just a technological trend but will be an essential strategy for manufacturers in the current era of autonomous and electric vehicles.

Q: How have you seeing the growing importance of security in the automotive industry?

The demand for security is rapidly increasing, which is why I saw joining Autocrypt as a major opportunity. Automotive security will be in demand, more than ever, as software-defined vehicles become the norm. This isn’t just in Korea or Europe, it’s a global phenomenon. A good example is the Indian market, where the AIS-189 regulation will be implemented as of October 2027. The regulation is based on UNR-155, and similarly requires a cybersecurity management system. This means that Indian OEMs and parts suppliers are urgently demanding security testing solutions, especially in the area of PKI. This is really exciting for me, as we really get to open doors to collaborating with different manufacturers and suppliers all over the world.

Q: What’s the next step for AUTOCRYPT in Europe (and maybe beyond)?

Europe was and continues to be a key player in the global automotive market. We’ll definitely focus on strengthening our partnerships with European OEMs and Tier-1 suppliers, and continue establishing our reputation as a leading player in vehicle cybersecurity. AUTOCRYPT has decades of experience in securing vehicles, and that puts us in the perfect place to address the unique challenges posed by the transition to SDVs.

But the automotive market isn’t limited to a single region. As vehicles are manufactured and sold to other regions, there’s going to be more and more hoops that manufacturers and suppliers need to jump through. I’m looking forward to guiding our partners and customers through regulation compliance and providing the necessary approvals and systems in place to make it an efficient and seamless process.

Q: Any final thoughts?

There’s a lot of changes in the automotive market right now. Vehicle software, artificial intelligence, and cybersecurity will be at the core of this new era and it’s critical for manufacturers to begin implementing some changes. Companies equipped with solutions to deal with changes (whether technological, regulatory, etc.) will have a significant edge in addressing the growing demand from consumers and regulatory bodies for advanced, intelligent automobiles.

We’ll continue to see amazing changes in the next few years, and as the European (and global) automotive industry transitions to SDVs, AUTOCRYPT already has developed many of the solutions that are or will be required for the new market. Leveraging these capabilities and expanding our business opportunities is my goal, and I’m optimistic about our future here!

Many thanks to Joohwa Sarah Lee for the interview. For more insights, follow her on her personal Linkedin page.

31 January, 2025 . 5 mins read

Hardware-in-the-Loop Simulation: What it means for ECU testing

With rapid advancements in autonomous driving technologies and various convenience features, vehicles now offer a wide array of functionalities. However, as modern vehicles rely on an increasing number of ECUs, HILS ECU Testing has become essential for validating and optimizing software performance before deployment. By simulating real-world driving conditions, HILS ensures that ECUs function reliably before integration into actual vehicles.

This isn’t simply a braggart outfitting of a vehicle. The numerous features offered by modern-day vehicles simply cannot be managed by a single ECU. Multiple ECUs must work together using complex interconnections to delivery seamless, safe functionality

For example, an automatic climate control system operates with the collaboration of several ECUs; one may be managing temperature sensors, while another runs airconditioning, windows, and heaters, and so on. This is a simple example, but for more complex features, dozens of ECUs may be required to perform a single function in perfect unison.

Difficulties in Testing

When adding a new feature to a vehicle, it is essential to test and validate the software of the ECUs because unlike hardware defects, software defects often remain undetected during the product development stage, making them difficult to address. Unlike hardware issues, these defects can cause unpredictable and potentially life-threatening outcomes. However, directly testing functions on actual vehicles can be equally risky, so traditionally, prototypes resembling the network environment of a vehicle are used to test functions by combining the relevant ECUs.

However, testing in a network environment is costly due to the exponential increase in the complexity of ECUs and software in recent years.

For example, luxury models like the Mercedes-Benz S-Class, BMW 7 Series, and Hyundai Genesis can be equipped with hundreds of ECUs. Testing a single vehicle function requires assembling a prototype model, a process that is both costly and time-consuming. Instead, automakers increasingly rely on HILS ECU Testing to simulate real-world conditions before deploying physical prototypes. Moreover, luxury sedans often contain over 20 million lines of software code—approximately three times the amount of code found in a large aircraft.

Therefore, assembling and testing hundreds of ECUs for every new feature adds considerable cost and time for manufacturers and suppliers. Testing a single function could mean creating a unique testing environment for all related ECUs, which would vary by vehicle model.

HILS Testing

This is where HILS (Hardware-in-the-Loop Simulation) comes in. HILS is a testing technique used to verify the functionality of developed products by simulating their actual operational environment.

In vehicle testing, HILS serves as a simulation system for various ECU functionalities. HILS makes it possible to test everything from individual ECUs to integrated network systems for all driving scenarios before ever testing on an actual vehicle.

Instead of combining physical ECUs into a prototype, HILS testing uses simulations. The testing environment consists of three main components:

Test Input Generator: Generates and provides input values for the test. Tools like fuzzers are included in this component
Target ECU: The specific ECU to be tested
HILS: A virtual controller that mathematically models the vehicle environment and simulates the actual movements of controllers. When needed, real actuators can be connected for experimentation.

In the example provided by below by AUTOCRYPT, you can see how the test process works. The Target ECU is connected to the HILS system, which receives test input values generated by the Fuzzer. The output from the HILS system verifies the functionality of the ECU, eliminating the need to physically assemble all related ECUs for testing. Only the ECU to be tested needs to be connected to the HILS environment.

HILS Advantages

While it does not completely eliminate the need for prototype vehicles, simulated testing is generally more cost-effective than creating physical products. It reduces the number of prototype vehicles, and shortens the time and manpower spent on test benches.

HILS also provides a significant advantage in conducting dangerous tests, such as wire breaks, sensor failures, or crash simulations. It is equally effective during the development of control algorithms when the actual components for testing may not yet exist. Furthermore, the ability to conduct tests anytime, anywhere, adds a practical advantage.

HILS ECU testing is not simply at its conceptual stage. The automotive industry has already recognized the importance of HILS testing – in fact, ISO 26262, the international standard for functional safety in vehicles, outlines software validation stages throughout a vehicle’s lifecycle, and recommends HILS testing during unit and integration testing.

For instance, Hyundai Motor Group’s vehicle software development process emphasizes HILS testing in the fifth stage of their V-cycle process, highlighting the growing importance of integrated HILS testing in new vehicle development as automotive control software becomes increasingly complex.

According to Wards Auto, the word “software” was first mentioned in a recall in 1994, and since then attribution to software for recall incidents has risen to 15% by 2023. While, software defects are inevitable as automotive software becomes heavier and more complex, this means conducting comprehensive software testing in advance is that much more essential.

HILS plays a critical role in this process by enabling flexible, unrestricted testing, which also aids in rapid response to software defects. Unlike physical tests, which are hindered by the time and cost of prototype production, HILS allows for swift simulation-based defect analysis and response.

To learn more about how AUTOCRYPT utilizes HILS in its fuzz testing solution, click here.

To learn more about AUTOCRYPT’s use of HILS in its fuzz testing solution and other automotive testing services, contact global@autocrypt.io.

23 December, 2024 . 2 mins read

Infographic: 2024 Year in Review

This year has been a remarkable journey for AUTOCRYPT, filled with innovation, meaningful collaborations, and impactful achievements. We are incredibly grateful to our investors, partners, clients, readers, and visitors for your unwavering support in 2024!

As we prepare to step into 2025, we’re excited about the opportunities and challenges that lie ahead. Here’s to another year of growth, innovation, and success—together!

Merry Christmas and Happy New Year!

Below is a recap of AUTOCRYPT’s key milestones and accomplishments in 2024.

Download PDF

(Accessibility version below)

New solutions

2024 has been the year of innovation and growth for AUTOCRYPT. We introduced 4 new groundbreaking solutions designed to address critical challenges in the automotive cybersecurity sector.

AutoCryptⓇ CSTP – Automotive cybersecurity testing platform for regulatory compliance

AutoCryptⓇ CLS – C-ITS local station for V2I communication

AutoCryptⓇ ASL – Adaptive security library for AUTOSAR platforms

AutoCryptⓇ RODAS – Remote driving assistance system for autonomous vehicles

Awards and certifications

This year, our efforts were recognized with several prestigious certifications and awards:

Designated as a Vehicle Type Approval Technical Service Provider for UN R155/156

Received Top Innovator Award at the 2024 CLEPA Innovation Awards

Partnerships

Collaboration fuels innovation, and this year, we forged impactful partnerships that strengthen our solutions and expand our reach:

Events

We participated in several impactful events, connecting with industry leaders and showcasing our innovations:

CES 2024
ITF Summit 2024
VDI ELIV
AutoTech Detroit 2024
Automotive Testing Expo Europe
International VDI Conference
ITS World Congress Dubai
Car Connectivity Consortium

and more…

Resources

This year, we published a range of resources to guide and inform our industry peers:

The Rise of Chinese Software-Defined Vehicles

UNECE Regulation 155: Key Vehicle Components to Focus on for Regulatory Compliance

Public Key Infrastructure: Use Cases in the Automotive Industry

Robotaxis in the Spotlight: Market Trends, Technology, and Disengagement Analysis

3 December, 2024 . 4 mins read

Security Validation and Vulnerability Testing for Automotive Software

As vehicles continue to evolve into sophisticated, software-driven machines, automotive cybersecurity has become as critical as a car’s physical safety. Modern vehicles rely on millions of lines of code that must not only work seamlessly but also remain resilient to potential cyberattacks. Regulations and industry standards mandate manufacturers to safeguard their systems against these threats. Two fundamental processes in achieving this are security validation and vulnerability testing. While both aim to ensure software security, they take distinct approaches to achieve it. Let’s dive into their roles, differences, and why they’re indispensable for automotive cybersecurity.

Security Validation

At its core, security validation is about ensuring that a system meets predefined security requirements and functions as expected under normal conditions. Think of it as a quality assurance process that confirms security measures are implemented correctly and comply with industry standards like UN R155/156 or ISO/SAE 21434.

For instance, security validation could involve verifying that Over-the-Air (OTA) update mechanisms comply with UN R156 requirements or ensuring that each ECU component is secure under different real-world conditions.

Manufacturers employ various testing methods to perform security validation, including but not limited to:

Functional Testing, which ensures key features like encryption and authentication work correctly under normal use cases.
Fuzz Testing, which introduces random or unexpected inputs to assess system stability and expose hidden vulnerabilities.
Penetration Testing, which simulates attack scenarios to test the system’s ability to defend against real-world threats.

The primary goal of security validation is to provide confidence and documented proof that all cybersecurity measures are not only in place but also operating effectively according to regulatory standards.

Vulnerability Testing

While security validation checks compliance, vulnerability testing takes a broader approach, exploring potential weaknesses or flaws that attackers might exploit. This process identifies vulnerabilities—both known and unforeseen—through rigorous probing and stress testing. Given that vehicle software is constantly evolving, vulnerability testing must be an ongoing process to mitigate risks proactively.

Common techniques include:

Fuzz Testing for Vulnerability Detection, which detects weaknesses by feeding unexpected or malformed data into the system.
Network and Protocol Testing, which analyzes communication protocols such as CAN, LIN, and Ethernet for exploitable flaws like injection vulnerabilities.
Hardware Security Testing, which examines hardware-software interactions, such as the extraction of firmware from electronic control units (ECUs), for potential vulnerabilities.

Unlike security validation, which confirms what is known, vulnerability testing ventures into the unknown, uncovering potential attack vectors that may not have been anticipated during the development process.

Key Differences Between Security Validation and Vulnerability Testing

By combining these two processes, manufacturers can build automotive systems that are not only compliant but also resilient to cyber threats.

As the automotive industry moves toward greater connectivity, the stakes for cybersecurity are higher than ever. Security validation ensures that systems meet regulatory standards, while vulnerability testing helps uncover hidden risks before malicious actors can exploit them. Together, they form a comprehensive approach to protecting vehicle systems from cyber threats.

For instance, validating the proper encryption of V2X communication provides compliance, but only through vulnerability testing can potential flaws in cryptographic implementation be identified. By integrating both practices into the development lifecycle, manufacturers can ensure their systems are secure and future-ready.

Cybersecurity in modern vehicles is no longer an optional feature—it’s a foundational requirement. Security validation and vulnerability testing are two sides of the same coin, each addressing distinct yet complementary aspects of the security landscape. When combined, they provide the robust framework needed to protect vehicles from both known and emerging cyber threats.

For manufacturers, embracing these processes is not just about meeting regulatory requirements—it’s about staying ahead in an industry where safety, innovation, and trust go hand in hand.

To learn more about AUTOCRYPT’s vehicle cybersecurity testing measures and cybersecurity regulation compliance consulting services, contact global@autocrypt.io.

12 November, 2024 . 5 mins read

EDR and DSSAD: A Look at Vehicle Accident Analysis Tools

In this age of autonomous driving technology, whenever there is an accident, heads turn to utilizing data from vehicle data recorders like the Event Data Recorder (EDR) or Data Storage System for Automated Driving (DSSAD) to uncover the accident cause. In today’s blog, we’ll take a closer look at the functions of the EDR and DSSAD, their differences, and their significance for accident analysis in the new era of autonomous driving.

It has become easier than ever to obtain recordings of vehicle accidents. With the combination of vehicle dashcams and nearby CCTV footage, determining the cause or perpetrator of an accident has become much more manageable than before. However, it can still be challenging to ascertain the root cause of an accident solely through video footage.

One particular type of accident that is difficult to analyze is the case of a sudden unintended acceleration (SUA). While the number of reported incidents has been decreasing this past decade, SUA accidents remain a frequent and often controversial topic of discussion. These types of accidents can be challenging to evaluate solely through video footage analysis, and this is where additional devices and data become necessary.

EDR

The Event Data Recorder or EDR is a type of data recording device that is embedded into a vehicle’s Airbag Control Unit (ACU) or the engine’s Electronic Control Unit (ECU). When a collision or a sudden incident occurs while the vehicle is in motion, the EDR records data related to vehicle operations for a specific period of time.

In many countries, there are stringent regulations on what the EDR is required to record. For example, in the United States, the National Highway Traffic Safety Administration (NHTSA) specifies requirements for EDRs under 49 CFR (Code of Federal Regulations) Part 563.

Source: 49 CFR Part 563: Event Data Recorders, published by the National Highway Traffic Safety Administration (NHTSA)

The EDR records critical vehicle data as listed above. In the case of an incident, vehicle owners can provide this information to authorities for accident analysis. The EDR plays a vital role in understanding accident dynamics and improving vehicle safety standards as a whole. The EDR is so vital, in fact, that in 2022 the NHTSA proposed to extend the EDR recording period from five seconds to 20 seconds.

This realization of the importance of EDRs is not limited to the United States. In 2021, the UNECE’s WP.29 (The World Forum for Harmonization of Vehicle Regulations) put into force UN R160, a regulation establishing provisions concerning vehicles and EDRs. R160 defines certain data collection and implementation requirements for EDRs. Following this, in 2022, the European Union approved a new act that requires the installation of an EDR in all motor vehicles in M and N categories (passenger vehicles and trucks). The regulation went into force in July of 2024 for all new vehicles.

DSSAD

The Data Storage System for Automated Driving (DSSAD) is a device designed to record and store data during autonomous driving sequences. It records and stores data on significant events related to autonomous driving, such as system activation, partial autonomous system failure, or minimal risk maneuvers. This data can then be used to address accidents and regulatory issues related to autonomous vehicles.

While DSSADs are only mandated in a handful of countries, their implementation is subject to certain regulatory measures for compliance. For instance, UNECE’s UN R157, which covers automated lane-keeping systems (ALKS), mandates DSSAD for vehicles equipped with ALKS in order to monitor status changes in the autonomous driving system (ADS).

Comparison of EDR and DSSAD

While there are similarities between EDR and DSSAD, there are core differences between the two.

The EDR is primarily designed for investigation of conventional vehicles, while the DSSAD is specifically developed for autonomous and semi-autonomous vehicles.
The EDR stores and provides data related to accidents just before they occur, while the DSSAD will store autonomous driving-related data for a relatively long period.
EDR data is only stored temporarily, and is not typically retained unless a crash occurs, while the DSSAD data is retained for a longer timeframe (typically around six months), or up to a certain number of recorded events to ensure comprehensive documentation.

Despite the differences, the two complement each other in analyzing accidents and clarifying liabilities regarding an incident. A vehicle’s dashcam has limitations, so the EDR can be crucial for accident analysis. Regulations regarding DSSAD in autonomous vehicles can also clarify responsibility between driver(s) and the vehicle.

In today’s era of autonomous driving technology, both the Event Data Recorder (EDR) and the Data Storage System for Automated Driving (DSSAD) are gaining significant attention due to growing concerns about liability in the event of accidents. However, this also brings forth the issue of cybersecurity. Maintaining data integrity is essential, as both the EDR and DSSAD store and retrieve data that could influence accident investigations. Tampering with this data could not only hinder accurate accident analysis but also allow parties to misplace liability. Security measures such as data anonymization and encryption are vital for protecting sensitive information stored by the EDR and DSSAD, as well as safeguarding personal data, location information, and driving records.

EDR and DSSAD are vital tools for transparency and accountability in autonomous vehicles, but their effectiveness hinges on comprehensive cybersecurity. By implementing robust protections against data tampering and unauthorized access, these recording technologies can serve their intended purpose: helping investigators understand complex accidents, advancing autonomous driving technology, and building public trust. The path to widespread adoption requires both sophisticated data collection and unwavering security measures.

Navigating the evolving mobility landscape is complex, but cybersecurity will play a key role in building trust among manufacturers, consumers, and legislators, ultimately paving the way for a secure future.

To stay informed about the latest news on mobility tech and software-defined vehicles, subscribe to AUTOCRYPT’s monthly newsletter.