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

Abstraction

At the same time with the growing of complexity E/E systems, the level of safety needed to be fulfilled by the work products increased very fast. Could we determine the way to fulfill a standard safety level for all manufacturers? Are these standardized and applicable? The article sheds light on these standards and provides the basic knowledge to design a functional safety system from the software point of view. Functional safety concepts are described in the ISO 26262[1] standard where concepts such as ASIL, risk assessment methods, and hazard analysis are described very clearly. The article briefly describes these concepts in a manner related to software development. Also, in the AUTOSAR complaint system, the need for functional safety concepts is very huge because in the context of standardized interfaces between modules can lead also to some errors. But for avoiding this, the AUTOSAR requirements provide some methods that are taken into consideration and described also in the article. The last part of the article presents a lightweight implementation of a safety system considering as a use case the designing of a remote keyless entry system.

INTRODUCTION

Nowadays, the automotive industry is continuously changing due to the increasing of customer amount and the complexity of specifications and new technologies but nevertheless Ed “The Internet of Things” (interconnectivity between all electronically devices) because they want their devices interconnected. Also, they should take into consideration the laws and regulations regarding the environment and safety. To resume all things from above can be considered that the main concerns are about building safe, connected, and green embedded systems [2]. In this article, the focus will be on the concepts that make a system more and more safe. To be declared a safe system, it shall fulfill some “functional safety requirements” and the development (including both software and hardware) should be made after a predefined process.

What is interesting is the fact that safety laws were defined also in the ancient world. As an example, the Codex Hammurabi (~1780 BC) [3] may serve as a basis. This was needed in those times because the technology level was very low and a guarantee of the “hand-made” work was more than needed to achieve one “technical” system. But now, do we need such laws because almost all actions of the worker are aided by a computer? In this way, such examples are relevant, and these are some of the most discussed topics, but behind the “open doors,” there are many discussions between the customer and automotive companies. It is known the case of Toyota's problem with the accelerator pedal that kills one person. For this, Toyota calls back about 8.5 billion cars to the garage and also some penalties to the injured people. This causes a lot of waste of money and time also for the company and customers. The Honda Civic has a defective chip in a DC/DC converter that because of a shortcut to the ground blows a main fuse and the motor stops. In Europe about 3751 cars were affected and called back to the producer. Another well-known case is a loss of power steering on the Mazda cars. Three accidents are known and checked currently by investigation agents. These three cases should raise the question: "Are functional safety rules necessary?”

The growing complexity of embedded systems (from both software and electronic points of view) in the automotive industry led to the introducing of an automotive standard to ensure the functional safety requirements. The standard is called ISO 26262 and defines the process for development of the automotive equipment and introduces the actions that should be taken in case of possible hazards caused by malfunctions of electronic and electrical systems in passenger vehicles. The standard is derived from the IEC 61508 standard, the generic functional safety standard for electrical and electronic (E/E) systems. ISO 26262 standards were created and released as a draft version in June 2009 and since then for the lawyers, this has been considered a state of the art. Based on this, a court process could be started against the automotive companies. Confusion between functional safety and quality is made almost every day by unfamiliar developers with this topic. Quality could be defined as something that “missing it annoys”, but functional safety refers to something that “missing it hurts”. From the “Vocabulary” section of the ISO 26262 standard, a definition for functional safety can be considered: “Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems”. In this context, the unreasonable could be considered both unacceptable, and excessive, and risk could be considered the combination of the probability and extent of the damage. Failures of the automotive systems can be failures due to hardware (some shortcuts, low/high voltage) or maybe failures at the design level (e.g. software errors).

The minimization of the risk means at first seeing the reduction of the probability of errors, but this is more complicated than this. In fact, minimization of the individual components will not lead to the elimination of the risk associated with the entire system. Reducing the error occurrence probability below a predefined threshold given by risk assessment of the entire system with all interconnected sub-systems (e.g. software components, sensors, actuators, mechanical devices, external devices) in fact should be considered as fulfilling the functional safety requirements. The following chapters should be considered as key parts of the ISO26262 standard [4]: Vocabulary, Management of functional safety, Concept phase, Product development at the system level, Product development at the hardware level, Product development at the software level, Production, and operation, Supporting processes, ASIL (Automotive Safety Integrity Level) and safety-oriented analysis and Guideline on ISO26262. From these chapters, it could be seen that the standard provides a lifecycle (starting from quotation, concept refinement, development, industrialization, and product validation) methodology for the development of the automotive systems and also adds methods to support tailoring of the necessary activities for the phases of the lifecycle process. Also, the aspects of the functional safety of the entire development (Prototype, Design and realization, Integration and test) process are defined inside these chapters. The risk classes are described using the methods inherited from the automotive specific risk-based approach and the ASIL methods are used for the realization of the specifications for achieving an acceptable risk. Based on these specifications defined previously, architecture is realized, and then the integration and validation test cases and measurement for detecting if the considered risks are below the predefined threshold and are considered acceptable. In this case, the functional safety system is considered a safe one; otherwise, another development cycle should be applied again.

NOTE: In this article I have explained only an introduction that's why I'm not giving any conclusion, in the next article I will explain AUTOSAR AND FUNCTIONAL SAFETY how it is and what are the topics we need to take care. And also, I'm going to explain insights of this topic.

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.