Safety of Perception System for Automated Driving: A Case Study on Apollo

This replication package consists of the detailed results of the safety assessment process of Apollo 7.0’s perception system for its use on a 3.4-kilometer segment of the Dutch highway, A270.

‘Operational design domain description’ consists of a detailed description of the operational area (operational design domain).

‘Hazard Analysis and Risk Assessment’ is a Microsoft Excel workbook of 6 sheets comprising of all intermediate results from the first two steps of safety requirement elicitation (hazard analysis, risk assessment), along with the final result (safety goals and their risk levels).

‘Safety Analysis’ is a pdf document showing the translation of system-wide safety goals to the safety goals specific to components using fault tree analysis.

‘Safety Requirements’ is a Microsoft Excel workbook of 2 sheets comprising the final result of the safety requirement elicitation process, i.e., safety requirements (1) for traditional software (2) specific to ML-based systems.

‘Design assessment’ is a Microsoft Excel workbook of 2 sheets comprising the design assessment results. Specifically, the sheets consist of (1) the safety requirements and applicable design choices for each requirement; (2) where did we assess each requirement; (3) the final verdict for assessment of each requirement; (4) the reason for the verdict and the design decisions found in Apollo’s perception system related artifacts.

 

How to navigate this replication package with a complete running example.
—-------------------------------------------------------------------------------------------------------
The identification of safety requirements starts from the Microsoft Excel workbook: ‘Hazard Analysis and Risk Assessment’ of 6 sheets presenting all intermediate results from the first two steps of safety requirement elicitation (hazard analysis, risk assessment). In the rest of this document, we demarcate running examples with bullets. 

In the sheet “Homepage” of this Excel workbook are descriptions and pointers to the other sheets in the same workbook if readers want to skip directly to the other pages. The second sheet “Operational scenarios” describes the operational scenarios and associated operational modes. The combination of operational scenarios and associated operational modes form operational conditions, each with a unique identifier. These operational conditions are used further.  The sheet also describes which variables are considered from the Operational design domain description (see the separate document with the same name for a detailed description of the operational area) to form these operational conditions.

• An example operational condition is “driving in lane” + “slower-moving vehicle in front” with its unique identifier OC1 (see row 11 in the second sheet).

The third sheet “Operational modes & functions” describes the functions (specific to functional safety or functional insufficiency) of the automated driving vehicle and which operational modes (from the second sheet) these functions are activated. Each function is associated with a unique identifier.

• An example function is “avoid collision with an object in driving lane”  and its unique identifier is F1 (see rows 2-5 of the third sheet).

The fourth sheet “Hazards identification” shows hazards identified by crossing each function from the third sheet with guide words. Each hazard has a unique identifier.

• An example hazard created from the above example function F1 is  “does not avoid collision with an object in driving lane” with its unique identifier H1 (see second row of the fourth sheet).

The fifth sheet “ASIL parameters” describes the parameters for identifying risk levels. The parameters are given to each of the operational modes and operational situations from the prior sheets. The sixth sheet “Hazardous events & safety goals” describes the derivation of safety goals from hazards identified from the fourth sheet and the identification of the risk level for each safety goal based on the risk parameters from the fifth sheet (they are automatically applied using the formula function in Excel). This sheet gives at least four new pieces of information (and how this information is derived): (1) hazardous event; (2) safety goal derived from each of the hazardous events; (3) aggregate safety goal; and (4) risk level (ASIL) for the aggregated safety goal. Each of these has its own unique identifiers. An example of each of these four (following from the example hazard given above) is given below,

• An example hazardous event (in the second row of the sixth sheet) is “does not avoid collision with an object in driving lane” (third column) + “driving in lane” (fifth column) + “slower-moving vehicle in front” (sixth column). This can be combined as “the automated driving vehicle does not avoid collision with a slower-moving vehicle in its driving lane”.  Its unique identifier is HE1.

• The safety goal derived from the above hazardous event (HE1) is “avoid collision in scenario: slower-moving vehicle in front in operational mode: driving in lane” (see second row, 15th column, of the sixth sheet) with its unique identifier SG1.

• The above safety goal (SG1) along with other similar safety goals, forms the aggregated safety goal: “avoid collision with an object (obstacle or vehicle) in driving lane in all operational modes” (see rows two to ten, column 17, of the sixth sheet) with its unique id Aggreg_SG1.

• The risk level associated with the aggregated safety goal, Aggreg_SG1, is ASIL D (see rows two to ten, column 18, of the sixth sheet).  This aggregated risk level is the highest risk level of the associated safety goals (see rows two to ten, column 13 of the sixth sheet). The risk level in each row of column 13 is derived from the risk parameters in columns 10-12 (sixth sheet). The risk parameters in columns 10-12  (sixth sheet) come from the fifth sheet and are associated with the operational mode in column 5 (sixth sheet) and the operational scenario in column 6 (sixth sheet). 

The next part of requirements elicitation is presented in the pdf titled ‘Safety Analysis’. The pdf document shows the translation of system-wide safety goals to the safety goals specific to components using fault tree analysis. Pipeline-level safety-critical events derived from the fault tree analysis are marked with unique identifiers.

• The fault tree for aggregated safety goal with the unique identifier Aggreg_SG1 is shown from page 2 of the document. One of the safety-critical event resulting from the aggregated safety goal is “Lidar obstacle detection, classification  and tracking pipeline estimates incorrect state of vehicle / obstacle” with unique identifier SCE1 (see page 13).

The final part of the safety requirement elicitation is shown in the Microsoft Excel workbook ‘Safety Requirements’. The workbook consists of 2 sheets comprising the final result of the safety requirement elicitation process, i.e., safety requirements (1) for traditional software (2) specific to ML-based systems. 

• An example traditional software safety requirement resulting from the safety-critical event with the unique identifier SCE1 is "if any component in LiDAR obstacle detection, classification, and tracking pipeline becomes non-operational then this failure shall not lead to an incorrect estimation of the state of vehicles or other obstacles.” and its unique identifier is 26262_3 (see the first sheet, rows 28-40, fourth column)

• An example ML pipeline safety requirement resulting from the safety-critical event with the unique identifier SCE1 is “If the performance of Lidar obstacle detection, classification, and tracking pipeline is deteriorated due to strong sunlight, then this deterioration in performance shall not lead to an incorrect estimation of the state of vehicles or other obstacles.” with unique identifier SOTIF_8 (see the second sheet, rows 73-82, sixth column)

Finally, the design assessment of the safety requirements is shown in the Microsoft Excel workbook ‘Design assessment’. The workbook consists of 2 sheets comprising the design assessment results. Specifically, the sheets provide the following information: (1) the safety requirements and applicable design choices for each requirement; (2) where did we assess each requirement; (3) the final verdict for assessment of each requirement; (4) the reason for the verdict and the design decisions found in Apollo’s perception system related artifacts.

• The assessment of the traditional safety requirement with the identifier 26262_3 (from above) is shown in the first sheet in rows 28-40.

• The assessment of the ML pipeline related safety requirement with the identifier SOTIF_8 is shown in the second sheet in rows 73-82.