Achieving Graceful Degradation for Level 2+ Autonomous Vehicles

Highly automated Level 3 (L3) autonomous vehicles (AVs) in which the driver can disengage and take his eyes and mind off the driving task for certain periods of time in certain situations [1] are soon to be a reality. But the development of the L3 technology is highly complex and bringing this technology to market is very expensive. Thus vehicle manufacturers (OEMs) are prioritizing the development of the cost-efficient Level 2+ (L2+) autonomous vehicles (AVs), to provide users with access to autonomous driving features at the earliest. The Level 2+ (L2+) is an industry derived terminology for conditional autonomous vehicles which is placed between the L2 and L3 autonomy levels. L2+ vehicles have the capability to perform driving functions following a mapped route while the driver has hands off the wheel, but has eyes and brain engaged [2] also the driver is responsible for vehicle maneuvers at all times

Below is a quick reference guide that explains the various Levels of Autonomy as developed by the Society of Automotive Engineers (SAE). Each level describes the extent to which a car takes over tasks and responsibilities from its driver, and how the human and machine, interact.

Levels of Autonomous Driving [1]

Traditionally, vehicle manufacturers (OEMs) have applied error mechanisms, that on detection of a fault that affects system operation will disable affected system functionality immediately and inform the human driver of feature unavailability, irrespective of the fact the system can function safely with reduced functionality or under limited Operating Design Domain (ODD) conditions.

Such error management mechanisms were acceptable for L0 / L1 / L2 feature systems as the human driver had his hands on wheel and taking back control did not cause major inconvenience. However, in an L2+ autonomous driving system where the human driver is driving with hands off the wheel, but with eyes on and brain engaged, and the vehicle is controlling the driving functions, ranging from following a mapped route, to making lane changes and modulating speed in traffic [2], following the error management mechanism of disabling the L2+ system in case of a fault and not giving the system sufficient time to recover while the system can function with reduced performance while meeting the required integrity as per ISO 26262 Automotive Functional Safety standard will cause great inconvenience to the human driver.

OEMs are looking to address this issue by adopting a Graceful Degradation management approach, i.e., when a system capability is reduced due to a fault but the residual system capability supports the ODD conditions in which the vehicle is operating in is aligned with the required integrity level as per the ISO26262 standard, the system is gracefully degraded and in parallel intimates to the human driver through system alerts .This provides the system sufficient time to self-heal while not causing inconvenience or it maintains the degraded state until the user reaches the service station to do the necessary diagnostics and repairs

Fig 1: Example of graceful degradation strategy

Making the most of the L2+ onboard system resources

In the past the L0 / L1 / L2 autonomy was achieved largely through multiple Electronic Control Unit (ECU) configuration approach to incorporate multiple features on a vehicle. The rise of L2+ autonomy demands migration to consolidated ECU configuration that utilizes a single powerful computing unit that houses all the features offered on the vehicle. In the past AV systems only implemented strategies that react to system faults by disabling the feature, but the consolidated ECU configuration approach gives us the opportunity to respond to a system fault by introduce graceful degradation that increases the feature availability while ensuring system integrity that does not lead to unreasonable risk as per ISO 26262.

Fig 2 – Multiple ECU Configuration

The diagram in Fig 2 shows a typical Multiple ECU configuration where the 3 to 4 features are housed on-board three separate ECUs. This configuration will have limited resources at its disposal due to two key factors i.e.

• The ECUs are designed specifically for the onboard features only, limiting the resources on-board.
• Design constraints limits the features to access resources between ECUs

Fig 3: Comparison between Multiple and Consolidated the ECU configuration approach

The diagram in Fig 3 shows the Consolidated ECU approach where all features are housed on a High-Performance Computing platform (HPC). This approach counters the limitations of the multiple ECU approach, where all on-board features that amount to around 25+ features will have access to all resources that are part of the consolidated ECU and will be able to access the resources efficiently.
Sufficient resources will be available on-board the HPC that can be shared between features to provide a N+1 and in some cases a N+2 redundancy setup of components as showcased in the diagram (Fig 4) below, where the component 3 and 5 can be shared by features 1 and 3, similarly component 9 is shared by features 2 and 3.

Fig 4: Feature structure on-board the consolidated ECU approach

KPITs approach to implementing Graceful Degradation.

The transition towards the consolidated ECU approach is complex due to the feature overlap caused by the resource sharing structure in the ECU. This has the potential to lead to various common cause failures if not analyzed systematically and could be the cause to hazardous scenarios.

Fig 5: Approach towards implementing graceful degradation on L2+ system

KPIT deploys the VDA 7 step FMEA AIAG & VDA structure to identify the effect of the component faults on multiple feature functionality simultaneously and its criticality on the integrity of the features on-board the L2+ system. This process helps identify suitable graceful degradation strategies to maximize availability by providing the human driver with reduced feature operation with the available residual system capability that can support the ODD, while the ensuring integrity level as per the ISO26262 is achieved.

This approach increases system complexity, which will have to be cascaded to various levels of the architecture while establishing traceability and completeness of the cascaded requirements. To achieve this KPIT follows the Model Based System Engineering (MBSE) approach to address the considerable increase in number of the system requirements, system specific use cases and scenarios, interfaces and interactions leading to additional effort in overall engineering which demands for strong systems engineering processes supported by right set of tools [4]

In summary

Industry’s focus on putting autonomous cars on road at the earliest demands the need to develop L2+ vehicles at the earliest. While various automotive suppliers (Tier1s) provide solutions for the L2+ computational unit that can host all required features, by proposing a single consolidated ECU onboard the vehicle, the responsibility to develop a suitable graceful degradation strategy, falls on the OEMs to provide customers with the required comfort level while maintaining feature integrity as per ISO26262 during a system fault.

KPIT’s proposed approach to achieve graceful degradation incorporates the widely used industry set analysis approach to understand the impact of the faults on the L2+ feature and its integrity to derive suitable graceful degradation strategies. KPIT also recognizes the complexity in implementing these strategies on to the consolidated ECU and the strict business requirements demanding shortened time to market and optimal cost of development. To achieve this KPIT uses the Model-Based System Engineering along with supporting tools to help the OEMs efficiently cascade the graceful degradation strategies to the lowest design level while ensuring traceability and completeness.

References

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

2. https://www.autocar.co.uk/car-news/business-autonomous-vehicles/l2-baffling-jargon-future-autonomy

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://developmentuat.kpit.com/insights/model-based-system-engineering/