10/6/2022 |
Published By
.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 sight1. 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.
Experts have defined five levels3 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:
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 hour4 and uses nearly 40 microprocessors and dozens of sensors to undertake data collation.
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.
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
Standard approach in many safety-relevant systems include
Some functions as below, provide a degraded mode, sometimes limited in time
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
Perform an autonomous “safe-stop” (stand-still at a non-hazardous place)
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.
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.
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
Subject Matter Expert – Autonomous Driving
KPIT Technologies GmbH
Recommend
8 likes
Hanser Automotive
Recommend
8 likes
Plot Number-17,
Rajiv Gandhi Infotech Park,
MIDC-SEZ, Phase-III,
Hinjawadi, Pune – 411057
Phone: +91 20 6770 6000
Frankfurter Ring 105b,80807
Munich, GERMANY
Phone: +49 89 3229 9660
Fax: +49 89 3229 9669 99
Leave a Reply