The Challenge of Safety and Security in Automotive Systems Part-4

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-4."

I am continuing my previous article here:

After the utilitarian Security Concept, the specialized Security Concept might be characterized. Within the last stage, the useful security necessities were depicted, and based on them through induction the specialized security necessities are state. These requirements will describe in which way the safety requirements shall be implemented to achieve the safety goals. If there are some safety requirements not allocated to some functional modules, then the allocation shall be made in this step. This implies at least a basic knowledge of the system even if the components should be treated as black boxes; the interfaces between these system components shall be specified. What can be observed here is the fact that decomposition is widely used. Also, a better understanding of the faults and consequences that can appear in the system is mandatory because the last step should be the definition of probability target values for the safety goal and the involved elements.

IMPLEMENTATION OF AN ASIL A SYSTEM. USE CASE

In a Remote Keyless Entry System on an AUTOSAR system and in which way the SWC are developed as services and software components. That structure should be changed if some functional safety requirements are added. There are some cases when the lock button press shall be safety relevant. For example, in the USA the double lock (which will close the car without the opportunity to be opened from the inside) is considered functional safety. The double lock functionality supposes that two consecutive lock button presses within a predefined time (e.g. 3 seconds) shall lead to the closing of the car without the possibility of opening the doors from inside. This can be very dangerous in case somebody is shopping and leaves someone else in the car, but pressing twice on the lock button and being very hot outside can cause the person inside the car to suffocate or any other injuries. From the things stated above, the functional safety requirement may be defined as:
to protect the system against undesired double lock actions means the rejection of the RF telegram in case it is not coming within the predefined time and not from a correct sequence. For this, the following architecture shall be designed. We will assume that the
cryptology protocol is a simple one in which just the telegram counter and the timestamp of the telegram are variable.

The FSsrv(Functional Safety Service) Module is a module that replicates the behavior of the main path RF- RKE Application modules. It is performs the telegram identification, decryption, and authentication, and checks also the integrity of the received telegram. At a higher level, the FSMgr (Functional Safety Manager) is a module that handles the process monitoring and means that checks if the first path outputs are the same as the second path outputs. In this case, the telegram is delivered to the RKE Application to be processed, otherwise it should be rejected. The FSObserver is the module that handles the evaluation of the process monitoring. Only if the outputs of the second path are the same as the output of the first one, the command for double lock be executed. This module acts as a watchdog application and if an error is detected in at least one path, then the current telegram processing shall be aborted and the telegram rejected. Also, it is highly recommended to take into consideration the following:

a) The design of the SWC and entire architecture (or at least of the Functional safety relevant part) shall be a multilayer architecture. Using such architecture, the errors in the high layers are avoided because a high layer application is started only if an application from the next below layer is requesting the start of it. This saves on one hand the CPU load and on the other hand the unwanted behaviors because a high layer application will process a request only if it was already initialized. Something else, the ask will not be taken into thought.

b) All state machine variables should be enumeration types whose values were been generated using the extended Hamming distance algorithm.

c) 2oo3 majority is used for all critical variables and also for the state machine variables. Also, it should be stored in three non-consecutive RAM addresses.

The method described above represents a simple method to develop a safety system with the ASIL A fulfilled in the context of the AUTOSAR concept. Also, the time needed for developing such modules is not drastically increased compared to the development of the non-ASIL systems. (Only with Quality Management).

Conclusion
Standardization of the functional safety concept provides an easier and clearer method to develop a safe system. The entire development process is not as simple as it seems at first because all possible fault causes shall be taken into consideration, but a thorough analysis can lead to the elimination of all “hard” bugs from the software that can provoke damage or injuries to the end-users. Following the methodology for the development of such systems, the accomplishment of the “safety” mission can be very easy. Also, because AUTOSAR provides standard interfaces and modules to assure safety the mission becomes more and more easy. But in the end, the implementation of software to accomplish this seems to be the easiest step if the entire methodology is fulfilled. In conclusion, it needs to be stated that the functional safety concepts need a qualified person to do all the needed steps and it is necessary to distinguish that even safety and security go hand in hand and refer to the same goal, but the concepts are different.

Thanks for Reading.