The Challenge of Safety and Security in Automotive Systems Part-3
Tags: tutorial, softwaredevelopment, softwareengineering, software
Published: 2024-01-15 14:02:30

Hello Readers,
My name is Santosha S Chikkur, and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunities to work on various projects, which has inspired me to learn the essential processes involved in developing AUTOSAR Modulеs and Add-Ons "The Challenge of Safety and Security in Automotive Systems Part-3."

**6. Hardware-specific devices**

**Security can be assured in functional safety by implementing the following requirements:**

b) The ECU shall be protected from flashing (programming) from unauthorized entities. Such requirement can be fulfilled if through programming a flash boot loader application decides based on some logic if the flashed program is an original OEM program or just a “malware” application. Also, this is based on some cryptographic security functions.
c) Diagnosis application for configuring the car variant and setting/getting the DTCs (Data Trouble Code) shall be protected, and only authorized diagnosis applications should be accepted. This is realized with some security codes.
d) Depending on the national laws of the country/countries in which the car is supposed to run the car variant is configured based on them and the handling should be made only in some specific configurations. Not all configurations of parameters shall be available for one car.

**FUNCTIONAL SAFETY CONCEPT**
The functional safety concept means the description of the functional correlations that should be achieved to fulfill the safety goals and standards. For each safety goal, some functional safety requirements should be defined. This definition of the functional safety concept is made through several steps which will be described below.

The first step refers to Hazard analysis and Risk assessment. In this step, the identification of the hazardous events and assessment of the corresponding risk for humans on the vehicle level and then based on these the relevant functional safety goals are determined. After this step has been realized, it is needed a review from an independent source can be made also by the customer. Here the risks could be classified based on three concepts [8]: severity, frequency of event (known in automotive as exposure) actions (or controllability), and also the ASIL (Automotive Safety Integrity Level) as described in Figure. Severity describes the possible damages to the hardware, equipment, environment, or possible injuries to the people. An action describes the possibility of reducing/avoiding the possible faults and also reducing the frequency to zero or duration of it below a threshold where the damages are controllable.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/30r2yifvfoj77y7rrnlm.png)

Each safety requirements are assigned to an ASIL or QM (in case the document quality level is enough for that functionality) and based on this the minimum testing requirement. For example, for an ASIL D (the highest level) the tester should be independent of the development team, and unit testing is required with 100% code and decision coverage. In Figure, the level of the ASIL concept is described.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gsy35d58ecqvkpi54rtz.png)

Below an example is presented (based on the 2010 Hyundai Veracruz Recall issue). Item and Content.


**Item ID**: #1
**Malfunction description**: The lamp switch may malfunction.
**Possible scenario**: A breakdown of the light switch may cause the brake lights to not light up when the brake pedal is discouraged and to stay lit up when the brake pedal is discharged.
**Reason category**: Typical driving scenario.
**Reason for functional safety**: Prevent the other participants of the traffic about your intentions.
**Severity** Collisions with delta v > 40 km. Life-threatening injuries or fatal injuries cannot be excluded.
**Frequency**: Driving at night
**Action**: Less than 10% of average drives or read users are normally able to avoid the hazardous by activation/deactivation of the brake lights. It is assumed that most of the drivers see if the driver in front of them reduces the speed, but maybe it will take too much time to brake in a hazardous situation.
**Fault Tolerance Time**: 500 milliseconds
**ASIL Category***: B
**Safe State**: The brake lights enlighten when the brake pedal is discouraged and don't light up when the brake pedal is discharged.


The next steps are referring to the description of the Functional Safety Concept. Firstly, it is necessary to describe the functional properties of the use cases found in Step 1. For each of them, another table is made based on the Item ID, and a detailed explanation and quantification of the terms used shall be done. In case that are some emergency methods are needed, it is mandatory to define them. In the next steps, the functional safety requirements on the function level representing the safety strategy shall be created. These will contain in which way the functional safety goal will be achieved and not implemented. Also, it is possible to define requirements outside of the analyzed functions, which will help achieve the safety goal (e.g. mechanical dimensions, warning signs). Identification of the needed elements that can be used for the achievement of this safety goal can be first identified in the current preliminary architecture in case the system is a new one, or already in the frozen architecture if the system is a reuse one. Very important to understand here is the fact that these elements should be functional because the functional safety concept is supposed to be made at the function level. The next steps consist of the definition of warnings and degradation concepts and, the definition of the driver’s action or other endangered person. At this level, it shall be stated what will happen if a dangerous fault has been detected (e.g. driver warning, emergency operation) and also what action is needed to be taken from the driver side to be made in case that warnings of malfunction occur. The final step is the refinement of all concepts/ideas/requirements stated in previous steps. Here it is necessary to describe through diagrams (e.g. UML diagrams) the functional redundancies and the information flow.

NOTE: In this article, I have explained only a Functional Safety Concept. at the last, I will give a conclusion.

This will be continued in the next article, including examples. Please let me know in the comments below if you have any questions. Thanks for reading.