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

AUTOSAR AND FUNCTIONAL SAFETY

For a better understanding of the following that will be described, it is very good to understand the difference between safety and security. These two concepts go “hand-in-hand” [5] but refer to two different things. Safety was described above as the “absence of unreasonable risk” due to hazards caused by malfunctioning behavior of the E/E systems”, whereas “security” means protection of the system from undesired access from other components. AUTOSAR provides some techniques to be taken into consideration when a functional safety system is developed. To develop a system that should be considered fully AUTOSAR compatible some strategies such as the ones from below should be applied.

1. Memory partitioning:

this method allows firstly safety and non-safety SWC (software components) to be developed on the same ECU (Electronic Control Unit). Separation of the components from the memory point of view can be made allowing each component a memory area predefined. For example, such IDEs for developing automotive applications allow developers through the “pragma” C option to define their region for the variables. This job could be made also by the system architect who can define at the start of the project section as “START_SWC_1_RAM_INIT_BYTE_AREA” and “START_SWC_2_RAM_INIT_BYTE_AREA” and also their “STOP_” equivalents. Also, such definitions should be made for each data type and the developers will use these macro definitions while developing their SWCs. Defensive programming could be considered relevant also for this method because allows communication between components using a safe way. In [1], the authors described the safe communication between SWCs using the Real Time Environment Layer. Each SWC provides some interfaces and parameters described in some “ecu config” files delivered by the AUTOSAR software architect. At the micro scale, defensive programming means the cal protection (division by zero, NULL pointers, cast to integral types, range limits, saturation, and overflow/underflow). Also, the ECC (Error Correcting Code) methods are used here to assure the integrity of the FLASH/EEPROM areas. Together with these ECC methods, the consistency check methods and data retention survey are used.

2. Program flow monitoring:

is a method that helps developers implement the required 2oo3 (two out of three) decisions needed in the functional safety systems. In this case, at specified moments, some inputs or outputs could be checked, and also if the requirements about timing constraints are met. In this category, also the support for dual controller plays an essential role because in this case, another “watchdog” controller can supervise the core (main controller).

3. Time determinism and time constraints

modeling allows SWC and Basic Software) modules to know at each point of execution exactly if the timing constraints are met or not. Also, this allows synchronized time bases between networks, components, and hardware jitters and also could determine in the run-time the timing violations parts of code. Also, in the operating system (e.g. AUTOSAR OS and OSEK) these constraints are very clearly specified, otherwise, the task scheduling mechanism is not working properly. we have runnable tasks (e.g. cyclic task, 5ms, 10ms, 20ms, interrupts) and in this case, if the execution of the operations inside of the 5ms task is greater than 30% of the lower task period then in case of some interrupts and maybe at some points where more than one cyclic task operation should be executed, a jitter is introduced in the operating system, and this means that the time base is changing. This is not well because the system is not deterministic and time constraints requirements defined at the beginning of the projects are not met.

4. End-to-end communication protection.

Accordingly, to [6], the concept of end-to-end communication (known as E2E communication) protection assumes that safety-related data exchange shall be protected at run-time against the effects of faults within the communication link. As faults can be considered the following: random HW faults (e.g. corrupts register of the SPI interface, bad design in the overflow range), design systematic errors (e.g. bugs in software in at least one communication stacks, not all requirements were implemented in the communication layer through Virtual Function Bus layer or RTE layer) or maybe environmental faults caused by interferences or natural hazard phenomena. The benefit of using this E2E protection is that the errors (faults) in the communication links will be found in the integration phase.

5. Logic and BIST (Built-In-Self Test) methods

In case functional safety is necessary for the system, then the standards recommend having a chip with BIST capabilities. This means that before setting the chip into functional mode, it is necessary to perform this BIST test to detect any possible memory or hardware errors. (E.g. some memory cells are not usable anymore) coming from the production modes. There are two possibilities for implementing BIST capability: chips can have implemented another controller to perform these operations, or hardware monitors (dedicated devices) for this. e).

6. Hardware specific devices

Devices like watch-dog timers, glitch filters, and self-correcting hardware devices can be classified as being part of this category. Watch-dog timers have the responsibility to lead the program execution or the hardware device (maybe both) in a safe state, in case some anomalies are detected in the software. These anomalies can be writing/reading operations from un-allocated memory, a hung situation that can lead to physical damages in the best case. A possibility to implement this is a periodical task to check the state of the system and if a task is detected to not get out in a predefined time, then the system is considered to be hang-out leading to watch-dog intervention and correcting this behavior putting the program execution in a safe state. Glitch filters are used for critical pins like reset, PLL (phased lock loop), and communication pins for removing noises that can appear due to electromagnetically fields for example. Security can be assured in functional safety by implementing the following requirements: a) An electronic immobilizer (known as IMMO) shall be used to protect the car from driving by unauthorized people or entities. IMMO is built using a transponder chip that communicates through low frequency waves with the key-fob slot and terminal control of the car. The communication is realized using some cryptographic functions such as AES128, HITAG2, or HITAG3, but this is OEM specific.

NOTE: In this article, I have explained only an AUTOSAR AND FUNCTIONAL SAFETY. 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.