Achieving Safe Adoption of Autonomous Driving with Next-gen Software Systems

.feature-img {
display: none;
}

Connected cars powered by software may be straight out of science fiction, but they’re all set to radically transform the way we envision mobility today. With seasoned automotive entities leveraging emergent technologies, it’s only a matter of time before driverless cars become a common sight¹. However, the road ahead is paved with challenges ranging from increased complexity in automotive software and gradual decoupling of the hardware and software components to the need for greater focus on methodical, safety-based design and production which can drive the safe adoption of futuristic tech. Here’s how KPIT establishes and enables the safe adoption of next-gen software that drives autonomous vehicles.

Levels of Autonomous Driving²

Experts have defined five levels³ in the evolution of autonomous driving each of which describes the extent to which a car takes over tasks and responsibilities from its driver, and how the human and machine, interact. The five levels of vehicle automation span:

• L0: Driver only: System offers momentary driving assistance via warnings, alerts, and emergency safety interventions while driver stays engaged and attentive
• L1: Driver assistance: System helps the driver but does not take over
• L2: Partly automated driving: System can take control but responsibility for vehicle operations stay with the driver
• L3: Highly automated driving: The driver can disengage from driving for a certain period of time, in certain situations
• L4: Fully automated driving: The vehicle can drive itself most of the time with the driver being engaged in other activities yet remaining able to take control, if required
• L5: Full automation: The vehicle assumes full control of driving functions with passengers being just that

These levels may be realized provided certain requirements for building such future-ready cars are fulfilled. Current connected car architecture entails basic software—AUTOSAR—which while efficiently operating on small microcontrollers and well-suited for time-critical, safe and secure applications, do not fully meet the purpose. Most of these features prioritize convenience over safety thereby, fall short of effective and methodical requirements-based design and suitable validation and verification testing. While high computing power is necessary for such cars, the software infrastructure within, also needs approximately 25GB of each hour⁴ and uses nearly 40 microprocessors and dozens of sensors to undertake data collation.

KPITs Requisites for Building Future-ready Cars

KPIT envisions a service-oriented architecture as robust foundation for connected cars. Equipped with split-up ECUs in the Safety IO Controller and the High Performance Controller and dedicated infrastructure to enable high computation power, KPIT’s framework leverages a widespread POSIX-like Operating System (for instance, Linux), Adaptive AUTOSAR, and an IO Controller that provides Sensor and Actuator Services, along with a deeply embedded, real-time Operating System (for instance, Classic AUTOSAR).

While the Performance Controller assists the human driver and focuses on the non-high speed functions, the IO controller looks at high-speed functions, filter processing, and calculation with strong timing. The software varies on available functions constraints and the attached sensors/actuators. The benefits of the Performance Controller—request IOs/data on demand (SOME/IP)—are updated Over-The-Air and may span novel functions, bug-fixing, and substitute each other (fail-operational). All the stated elements are essential to enabling both system integrity and availability for a large scale software system like autonomous driving.

Concepts for Fail-operational Systems⁵

One of the core principles used early on in the connected car design and development journey when designing the automotive electronic control systems was fail-safe operation. Today, fail-safe is inadequate while fail- operational capability emerges as the bare minimum.

Fig. 1: Moving from Fail-safe to Fail-operational spans critical steps that focus on fault detection, redundancy and gradual safe stop

The journey from fail-safe to fail-operational as diagrammatically depicted in Figure 1, includes the following:

Deactivate / degrade function safe state spans

• Inform the driver
• Report a diagnostic error

Standard approach in many safety-relevant systems include

• Airbag, ESP, air conditioning, battery charging
• Driver assistant functions such as adaptive cruise control, lane assist

Some functions as below, provide a degraded mode, sometimes limited in time

• Electronic Power Steering
• Braking

In highly automated cars, safety critical systems such as these are often assigned dedicated systems that help them perform these functions when a fault is detected. While this takes care of redundancy, it also enables the vehicle to operate until it slows down to a safe stop itself.

Safe State entails

Continued driving until driver is in the loop

• Approx. 7-15s for conditional autonomous driving
• Several minutes for high and full autonomous driving

Perform an autonomous “safe-stop” (stand-still at a non-hazardous place)

• Drawing the driver’s attention to the situation
• May last several minutes based on the situation

 

KPITs Approach to Enabling Fail-operational Systems

Fig. 2: The four pillars of fail-operational systems

A holistic model of autonomous car chain of effect consists of sensing elements like radars, cameras, and other sensors which are fed into the perception layer which contextualizes sensor inputs into a manageable representation of the environment around the vehicle. The represented environment is then, used in planning components to produce an executable trajectory for the control module.

From the safety perspective it is obvious that the straightforward simplex implementation is not sufficient in achieving neither fail-safe nor -operational capabilities and that additional design elements have to be introduced in order to detect errors and prevent failures from bringing the system into a non-safe state.

Fig.3: Comparison between two approaches when introducing internal diagnostics into AD car architecture

The idea of introducing internal diagnostics into a system so that, if an error is detected, the system can fail in a safe way has been explored in Figure 3 above, though it is clear that with 1oo1D architecture it is not possible to achieve fail-safe and -operational criteria for high safety systems like autonomous driving. However, the solution which is becoming more and more popular in the automotive industry is the so-called two-out-of-two with diagnostics (2oo2D) architecture where two 1oo1D channels work in parallel to ensure maximum availability. In case of a failure in one of the channels, the healthy one is still available to ensure continuous operation.

Fig.4: Analysing fault resulting in failure in a safety critical system

The important factor to consider with 2oo2D approach is to ensure independence of channels so that the system can be protected from common cause failures. A common cause failure is a scenario in which one root cause causes a discrepancy in both channels thus causing both of them to fail. Some common practices in addressing this topic are using different sensor sets across different channels, using different implementations in critical parts (e.g. maths library, fusion algorithm and similar elements), diversifying hardware platform and other coupling factors.

Conclusion

Connected cars have come a long way since the 1980s in terms of design, infrastructure and technologies. Today, these strive to be future-ready but with considerable emphasis on safety. KPIT’s thought process for autonomous driving cars incorporates the re-use of available integrity mechanisms from fail-safe systems as the mainstay for building fail-operational systems. While software systems designed to achieve a high diagnostic coverage are readily available today, the road ahead mandates these be accommodated in robust design to fulfil the AD function. KPIT also recognizes that established methods for tracking software quality and safety are key to developing an optimally safe solution and works to address the challenge in covering all the cases for complex software solution through best-in-class verification and validation methods both, in the virtual and field environments.

References

1. https://www.brookings.edu/research/securing-the-future-of-driverless-cars/

2. https://www.nhtsa.gov/technology-innovation/automated-vehicles-safety

3. The levels 0 to 5 are defined according to their relative extent of automation. Levels 3-5 are still in the testing phase.

4. https://qz.com/344466/connected-cars-will-send-25-gigabytes-of-data-to-the-cloud-every-hour/

5. https://www.forbes.com/sites/samabuelsamid/2022/02/08/automated-driving-must-be-fail-operational/?sh=24ef7b2a527f