Università di Pisa
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Elettronica N.O.
Elaborato finale
Functional Safety applied to
Automotive Systems
Anno accademico 2014/2015
Candidato: Federico Viterbo
Relatore: Prof. Ing. Luca Fanucci
………
………
Tutore: Ing. Rabih Aboul-Hosn
Table of Content
1. List of abbreviations ... 4
2. Introduction ... 6
2.1. History of automobile ... 8
2.2. Evolution of systems in the automobiles ... 13
2.3. Classification of Automotive embedded systems ... 15
2.4. Automotive engineering ... 17
2.5. µController or Microprocessor ... 19
3. State of the art: ISO 26262 ... 22
3.1. Parental Standard IEC 61508 ... 24
3.1.1. Origins of IEC 61508 ... 24
3.1.2. IEC 61508 structure ... 25
3.1.3. Scope of IEC 61508 standard ... 28
3.2. Safety Lifecycle ... 28
3.3. Scope of ISO 26262 ... 32
3.4. Structure of ISO 26262 ... 33
3.5. How to determinate ASILs ... 35
3.6. Tools Qualification ... 38
4. Functional Safety ... 41
4.1. Definition ... 41
4.1.1. Scope ... 42
4.1.2. How to achieve Functional Safety ... 42
4.1.4. How Functional Safety is achieved in accordance with ISO 26262 ... 46
4.1.5. Types of faults ... 47
4.1.6. Fault classification by ISO 26262 ... 50
4.2. Hazard Analysis ... 53
4.2.1. Objectives and Principles of Hazard Analysis ... 53
4.2.2. Flow to be followed to perform Hazard Analysis ... 55
4.2.3. Inputs and outputs of Hazard Analysis ... 56
4.3. Safety Analysis ... 58
4.4. Fault Injection ... 59
4.4.1. Classification of Fault Injection ... 59
4.4.2. Objectives of Fault Injection ... 61
4.4.3. Fault Injection in Automotive System ... 62
4.4.4. How to perform Fault Injection ... 63
5. RH850-P1x ... 65
5.1. Scope of P1x ... 65
5.2. P1x’s principal components ... 66
5.3. Safety Analysis ... 66
5.3.1. Export hierarchy ... 67
5.3.2. Define the functionality of each element ... 69
5.3.3. Fault Characterization analysis ... 70
5.3.4. Fault Impact Analysis ... 71
5.3.5. Safety Mechanisms analysis ... 72
5.3.6. Fault Coverage analysis ... 73
5.4. Fault Injection ... 76
5.4.1. Get the environment ready ... 77
5.4.2. Logic simulation ... 78
5.4.3. Compilation of the design ... 80
5.4.4. Fault Generation ... 82
5.4.5. Fault Simulation... 83
5.4.6. Report of results ... 84
5.4.7. For a better understanding ... 86
6. Conclusion ... 100
1. List of abbreviations
ABS: Antilock Braking System ADC: Analogue to Digital Converter ASIL: Automotive Safety Integrity Level ATP: Automatic Theorem ProvingAWO: AlWays-On area
CAN: Controller Area Network CPU: Central Processing Unit
DIA: Development Interface Agreement DMA: Direct Memory Access
DUT: Device Under Test
E/E/PE: Electrical/Electronic/Programmable Electronic EBD: Electronic Brakeforce Distribution
ECC: Error Correcting Code EPS: Electric Power Steering ESP: Electronic Stability Program FIT: Failure In Time
FTTI: Fault Tolerant Time Interval FMEA: Failure Mode and Effect Analysis FPH: Failure per Hour
HAZID: HAZard IDentification HAZOP: HAZard and OPerability HEV: Hybrid Electric Vehicle
HVAC: Heating, Ventilation and Air Conditioning
HW: HardWare
I/O: Input and/or Output IC: Integrated Circuit
IEC: International Electrotechnical Commission
ISO: ISOlated area, International Organization for Standardization MPF,D: Multi-Point Fault Detected
MPF,L: Multi-Point Fault Latent MPF,P: Multi-Point Fault Perceived
NSR: Non-Safety Related
NVH: Noise, Vibration, and Harshness OEM: Original Equipment Manufacturer
PC: Personal Computer
PLL: Phased Locked Loop
PMHF: Probabilistic Metric of Hardware Failure PWM: Pulse Width Modulation
QM: Quality Management
RAM: Random Access Memory
RF: Residual Fault
ROM: Read Only Memory
RPM: Revolutions Per Minutes RTL: Register Transfer Logic
SF: Safe Fault
SFF: Safe Failure Fraction SIL: Safety Integrity Level SPF: Single Point Fault
SR: Safety Related
STCA: Software Tool Classification Analysis STD: Software Tool Documentation
STQP: Software Tool Qualification Plan STQR: Software Tool Qualification Report
SW: SoftWare
TCL: Tool Confidence Level TCS: Traction Control System TD: Tool error Detection
TI: Tool Impact
VHDL: VHSIC (Very High Speed Integrated Circuit) Hardware Description Language
2. Introduction
Activities described in this document have been performed during a period of 6 months internship in Renesas Electronics Europe Limited, the world's number one supplier of µControllers and a premier supplier of advanced semiconductor solutions, including system-on-chip and a wide range of discrete analogue and power devices. Renesas provides pioneering platforms for the advancement of the Smart Society, embedding intelligence, connectivity, safety and security in solutions for cars, homes, buildings and factories.
The evolution of Automotive Systems with the use of more and more electronic devices has introduced the need to guarantee people’s safety even in case of trouble in the electronics. Renesas Electronics then, is performing to safety the highest standard requirements that customers need for Automotive products.
This document describes how the required Functional Safety is achieved on the Renesas RH850-P1x µController platform, which is used on-board vehicles to perform chassis and safety applications like ABS, ESP, EPS, Airbag, etc.
In Chapter 3 Automotive Systems are described, from the origin of automobiles and following the evolution that they have got during the years. Then it is presented which is the engineering that deals with these kinds of systems and which typology of chip is suited for these applications.
Chapter 4 presents the standard ISO 26262, introducing also the parental standard IEC 61508 from which ISO 26262 comes; its scope is to define the development phases, from the specification to the final release, describing the structure and some important concepts on which Functional Safety bases its fundamentals.
Then, Chapter 5 is dedicated to deeply define the purpose of Functional Safety, explaining its scope and its meaning according with the relative standard. Furthermore, the techniques by which it is possible to accomplish the Functional Safety scope, that have been used during this experience, are introduced; Hazard Analysis, Safety Analysis and Fault Injection are described defining their objectives and how they are performed. As per ISO 26262 requirements, all together are
needed to prevent any injury to the people in the vehicle, whenever a failure occurs in the µController during its normal operation.
In Chapter 6, after a brief introduction of the µController RH850-P1x, the entire flow of Safety Analysis is explained showing the effective data that have been processed; then Fault Injection is outlined through the use of a simple 4-bit counter describing the whole procedure.
In Chapter 7 the activity done during the internship period is evaluated and it is considered which may be the next project on which Functional Safety has to be applied and achieved.
Automotive Systems
Automobiles changed the world in the 20th Century. They have given people the freedom to live, work, and travel almost anywhere they want. The automobile industry has caused the suburbs to grow, and made the development of road and highway systems necessary. The manufacture, sale, and repair of automobiles are very important to the countries that produce large amounts of manufactured goods. But along with the advantages of automobiles, there have been disadvantages. Automobile accidents are a leading cause of death and injury in the world, and the automobile has brought about air and noise pollution and contributed to global warming. Despite the problems automobiles have caused, they are an important part of the culture and economy of the world.
2.1.
History of automobile
Before the invention of trains, trams, and automobiles, people travelled to work by horse or horse and carriage. A tram was a public passenger car operated by rails through the streets of the city. Traveling by horse was a slow means of transportation, so people had to live close to where they worked. People tended to live on farms or in the city where the businesses were located.
In the late 1800’s, when railroads and streetcars were developed, people could live farther from work. The communities that grew next to or near the central cities were called suburbs. The growth of the suburbs dramatically increased when people started owning automobiles, because it became even easier for people to live farther from their work. Also, businesses and stores moved to the suburbs where the people lived.
The travel industry grew with the invention of the automobile. When people had automobiles, they could drive to different places to visit. People started going on vacations and spending money in the cities they visited, which helped the economy. In the early days of the development of the automobile, there were three sources of automobile power: steam engines, electric motors, and gasoline engines.
The first self-propelled vehicles were made during the late 1700’s in Europe using steam-powered engines. Steam engines are external-combustion engines. A steam engine works by using the heat energy of pressurized steam to push the pistons. In the late 1800’s, many Americans also experimented with steam automobiles. These automobiles were not successful, because it took a long time for the engines to heat up, they cost a lot to make, they caused a lot of noise, and sometimes they exploded if too much pressure happened to be in the engine.
Figure 2: This old drawing shows one of the first fire engines that used a steam engine to pump water, instead of pumping by hand
In 1891, William Morrison built the first successful electric-powered automobile in the United States. Electric-powered automobiles were an improvement over steam-powered automobiles because they were quiet, cost less, and they did not produce smelly fumes. The disadvantages of electric cars were that they could only travel about 20 miles per hour, and the batteries needed to be recharged about every 50 miles and, furthermore, their recharge time was very long.
Figure 3: Edison and a 1914 Detroit Electric, model 47
In 1860, Jean Lenoir of France patented an internal-combustion engine that is similar to the type of engine used in automobiles today. Internal-combustion engines run on gasoline or diesel fuel. Gottlieb Daimler and Karl Benz developed the first successful powered automobiles separately in 1885 in Germany. Eventually, gasoline-powered engines were used for nearly all automobiles because they provided for faster and longer trips than engines powered by electricity or steam.
Figure 4: The first gas-powered vehicle
The first modern automobiles were made in Germany and France in the 1890’s. Many small companies made them by hand. Until 1900, Europe led the world in the development and production of automobiles. During the early part of the 20th Century, the United States became one of the leading countries in automobile production. The United States passed other countries in the number of automobiles produced because the United States had a greater population and higher personal income levels than the countries in Europe. The United States had more people who could afford to buy automobiles.
Another reason why the automobile industry grew in the United States was because gasoline prices dropped in the United States when oil was discovered in Texas in 1901. Gasoline is made from oil, so fuel prices went down, making the automobile less expensive to operate. Also, the United States automobile industry used mass production techniques, which further lowered the cost of owning an automobile. Mass production techniques make goods in large quantities using standardized parts and often using assembly lines. The production of automobiles in the United States
increased rapidly in the early 1900’s from less that 5,000 in 1900 to more than 1.5 million in 1916.
Detroit soon became the Automobile Capital of the World. Henry Ford founded the Ford Motor Company in 1903, and five years later introduced the famous Model T.
Figure 5: 1914, Model T Ford Station Wagon
This automobile was popular, because it was the first affordable automobile made for the average American. Originally, the Model T was sold for $825 (that is about 80,000$ nowadays) and over 17,000 were sold in the first year.
In 1913, Ford introduced the moving assembly line, which allowed his company to build automobiles faster and at a lower cost. The frame of the car was pulled through the plant by a chain and workers on each side added parts that were brought to them by conveyor belts. Up until this time, workers assembled each automobile on one spot on the factory floor. With the assembly line, Ford was able to drop the time needed to build a Model T from 12.5 hours to 2 hours and 38 minutes. This time was eventually decreased to 1 hour and 33 minutes, which lowered the price of the Model T because the cost of labour went down. By 1924, the price of the Model T had dropped to $290 (about 15,000$). More than 15 million Model T’s were sold by the time the model was discontinued in 1927. The Model T changed the United States
because large-scale ownership of automobiles led to the growth of the suburbs, motels, shopping centres, and highways.
2.2.
Evolution of systems in the automobiles
There have been many improvements in the automobile over the past 110 years. In the early 1900’s, most automobiles looked more or less like horseless carriages. There were no roofs or windows. By 1906, automobile bodies were changed to include bumpers, a hood that covered the engine, fenders, and lamps placed on the front as headlights.
An important invention in the development of the automobile was the electric self-starter that was invented by Charles Kettering in 1911.
Figure 6: Electric self-starter
General Motors Company first used the electric self-starter in 1912. Prior to that time, automobiles had to be started with hand cranks. A crank was put into the front of the engine and the crank had to be turned by hand until the engine started. The driver had to stand outside to use the hand crank, which was not very comfortable when the weather was bad. It was also difficult to start an automobile with a hand crank, because it took a lot of strength and it was also dangerous as resulted in
many injuries. The electric self-starter was better, because it was easier, faster, and the driver could be inside the automobile when starting it.
Today, automobiles use pneumatic tires, which are rubber tires filled with air. Michelin, a French rubber-making company, introduced the first pneumatic tires used on automobiles in 1895. Before this time, most vehicles had wooden wheels and steel tires. Pneumatic tires were an improvement over steel tires because they gave a smoother ride. Originally, the tires were filled with 55 to 75 pounds per square inch of air pressure. These tires were called high-pressure tires. In 1922, low-pressure tires that held from 30 to 32 pounds per square inch were introduced. The low-pressure tires provided for a smoother ride because they were not as hard and absorbed bumps better.
In 1939, air conditioning and automatic transmissions were introduced. The transmission changes the gears of an automobile depending on the speed. A larger gear is used when an automobile is starting out because a lot of force is needed. Smaller gears are used as the automobile picks up speed. With a manual transmission, the driver presses down on a clutch pedal while shifting the gears with a gearshift.
Figure 7: Manual and Automatic Transmission
Automatic transmissions have internal clutches that disengage the engine automatically as the gears change. Both automatic and manual transmissions are used today. Automatic transmissions are easier to use because the driver does not have to change gears. Manual transmissions give the driver more control and are less expensive to make.
Automobiles continue to be improved as we enter the 21st Century. It is expected that future automobiles will use less fuel, cause less pollution, and be safer to drive. There will be greater use of computers to control more of the automobile’s systems, such as the suspension and navigation systems. The major countries producing automobiles today are China, United State, Japan, German, South Korea, India, Brazil, Mexico, etc. Automobiles are one of the greatest inventions of all time and will continue to change the way we live, even if they are the second biggest single expense after buying a house.
Although the great improvements that the automobiles have brought to the lifestyle condition, the world economy, etc., each year about 300,000 people throughout the world die in traffic accidents due mainly to three causes: driver errors, defective automobiles, and poor road conditions. Then, to reduce the number of injuries and deaths from accidents lighting and guardrails are included in road design, and intersections, the number of lanes, and traffic signals are all carefully planned. Roads and highways are built with safety in mind. Furthermore, safety features are included in automobiles like, for example, seatbelts, airbags and many other equipment, widely realized by embedded systems.
2.3.
Classification of Automotive embedded systems
Automotive electronics or Automotive embedded systems are distributed systems, and according to different domains in the Automotive field, they can be classified into:
Engine electronics
Engine controls demand one of the highest real time deadlines, as the engine itself is a very fast and complex part of the automobile. It controls such things as cooling system, ignition system, fuel injection, etc.
Transmission electronics
Transmission controls the transmission system, mainly the shifting of the gears for better shift comfort and to lower torque interrupt while shifting.
The chassis system has lot of sub-systems like Antilock Braking System (ABS), Traction Control System (TCS), Electronic Brakeforce Distribution (EBD), Electronic Stability Program (ESP), etc. which monitor various parameters and are actively controlled.
Active systems
Active systems are working during the normal driving mode of the vehicle and they are expected to prevent a possible accident. Principal active systems are vehicle stability control, night vision, emergency brake assist system, lane change assistance, collision avoidance system, etc.
Passive systems
Passive systems are activated when the accident has already happened and they try to mitigate the effect of the impact: seatbelt, Airbag, etc.
Driver assistance
These systems help the driver in the driving process. Modern driver assistance systems are for example on-board navigation system, automatic parking, etc.
Passenger comfort
Automatic climate control, electronic seat adjustment with memory, etc. are all optional those systems can improve the comfort for the driver.
Infotainment systems
Music system, information access, etc. are comprised into this category.
All the applications have been developed to improve performances, comfort and safety, but also to reduce costs of systems that compose the vehicle.
2.4.
Automotive engineering
Automotive engineering is a branch of vehicle engineering, incorporating elements of mechanical, electrical, electronic, software and safety engineering as applied to the design, manufacture and operation of motorcycles, automobiles, buses and trucks and their respective engineering subsystems.
Some of the most important engineering disciplines or attributes that are fundamental to the Automotive engineering are:
Safety Engineering: Safety Engineering is the assessment of various crash scenarios and their impact on the vehicle occupants. These are tested against very stringent governmental regulations. Some of these requirements include: seat belt and air bag functionality, front and side impact testing, and resistance to rollover. Assessments are done with various methods and tools: computer crash simulation, crash test dummies, partial system sled and full vehicle crashes.
Fuel Economy and Emissions: Fuel Economy is the measured fuel efficiency of the vehicle in miles per gallon or litres per 100 kilometres. Emissions testing the measurement of the vehicles emissions e.g. hydrocarbons, nitrogen oxides (NOx), carbon monoxide (CO), carbon dioxide (CO2), evaporative emissions and particulates.
Vehicle Dynamics: Vehicle Dynamics is the vehicle's response of the following attributes like ride, handling, steering, braking, comfort and traction. Design of the chassis systems of suspension, steering, braking, structure (frame), wheels and tires, and traction control are highly leveraged by the Vehicle Dynamics engineer to deliver the Vehicle Dynamics qualities desired.
NVH Engineering (Noise, Vibration, and Harshness): NVH is the customer's feedback (both tactile (feel) and audible (hear)) from the vehicle. While sound can be interpreted as a rattle, squeal, or hoot; a tactile response can be seat vibration, or a buzz in the steering wheel. This feedback is generated by
components either rubbing, vibrating or rotating. NVH response can be classified in various ways: powertrain NVH, road noise, wind noise, component noise, and squeak and rattle.
Vehicle Electronics: Automotive electronics is an increasingly important aspect of Automotive engineering. Modern vehicles employ dozens of electronic systems. These systems are responsible for operational controls such as the throttle, brake and steering controls as well as many comfort and convenience systems such as the HVAC (Heating, Ventilation and Air Conditioning), infotainment and lighting systems. It would not be possible for automobiles to meet modern safety and fuel economy requirements without electronic controls.
Performance: Performance is a measurable and testable value of a vehicles ability to perform in various conditions. Performance can be considered in a wide variety of tasks, but it's generally associated with how quickly a car can accelerate, its top speed, how short and quickly a car can come to a complete stop from a set speed, how much g-force a car can generate without losing grip, recorded lap times, cornering speed, brake fade, etc. Performance can also reflect the amount of control in inclement weather (snow, ice, rain).
Shift Quality: Shift Quality is the driver’s perception of the vehicle to an automatic transmission shift event. This is influenced by the powertrain (engine, transmission) and the vehicle (driveline, suspension, engine and powertrain mounts, etc.). Shift feel is both a tactile (feel) and audible (hear) response of the vehicle. Shift Quality is experienced as various events: transmission shifts are felt as an upshift, at acceleration (1-2), or a downshift, maneuverer in passing (4-2).
Durability and Corrosion Engineering: Durability and Corrosion Engineering is the evaluation testing of a vehicle for its useful life. This includes mileage accumulation, severe driving conditions, and corrosive salt baths.
Package and Ergonomics Engineering: Package Engineering is a discipline that designs/analyses the occupant accommodations (seat roominess), ingress/egress to the vehicle, and the driver’s field of vision (gauges and windows). The Package Engineer is also responsible for other areas of the vehicle like the engine compartment, and the component-to-component
placement. Ergonomics is the discipline that assesses the occupant's access to the steering wheel, pedals, and other driver/passenger controls.
Climate Control: Climate Control is the customer’s impression of the cabin environment and level of comfort related to the temperature and humidity. From the windshield defrosting, to the heating and cooling capacity, all vehicle-seating positions are evaluated to a certain level of comfort.
Drivability: Drivability is the vehicle’s response to general driving conditions. Cold starts and stalls, RPM (REVOLUTIONS PER Minutes dips, idle response, launch hesitations and stumbles, and performance levels.
Cost: The cost of a vehicle program is typically split into the effect on the variable cost of the vehicle, and the up-front tooling and fixed costs associated with developing the vehicle. There are also costs associated with warranty reductions, and marketing.
For each of the above points, where electronics systems have been used, the choice of the system components was made based on the signals, the parameters and the necessary processing speed.
2.5.
µController or Microprocessor
The term microprocessor and µController have always been confused with each other. Both of them have been designed for real time application.
Microprocessor is an IC, which has only the CPU inside it i.e. it only provides processing power, such as Intel’s Pentium 1, 2, 3, 4, core 2 duo, i3, i5, i7 etc. These microprocessors don’t have system RAM, ROM, and other peripheral on the chip. A system designer has to add them externally to make them functional. Application of microprocessor includes Desktop PC’s, Laptops, notepads etc.
Figure 9: Basic components in a microprocessor
But this is not the case with µControllers. µController has a CPU, in addition to a fixed amount of RAM, ROM and other peripherals all embedded on a single chip. it is also known as a Mini Computer or a Computer On a Single Chip. Today different manufacturers produce µControllers with a wide range of features available in different versions. Some manufacturers are Renesas Electronics, ATMEL, Microchip, TI, Freescale, Philips, Motorola, etc.
µControllers are designed to perform specific tasks. Specific means applications where the relationship of input and output is defined. Depending on the input, some processing needs to be done and output is delivered. For example, keyboards, mouse, washing machine, digital camera, pendrive, remote, microwave, cars, motorbikes, telephone, mobiles, watches, etc. Since the applications are very specific, they need small resources like RAM, ROM, I/O ports etc. and hence can be embedded on a single chip. This in turn reduces the size and the cost of the chip and allows much more intelligence and flexibility than a fully hardware state machine.
Figure 10: Basic components in a µController
Microprocessor find applications where tasks are unspecific like developing software, games, websites, photo editing, creating documents etc. In such cases the relationship between input and output is not defined. They need high amount of resources like RAM, ROM, I/O ports etc.
The clock speed of the Microprocessor is quite high as compared to the µController. Whereas the µControllers operate from a few MHz to 100 to 200 MHz, today’s microprocessors operate above 2GHz as they perform complex tasks.
Comparing µController and microprocessor in terms of cost is not justified. Undoubtedly a µController is far cheaper than a microprocessor. However µController cannot be used in place of microprocessor and using a microprocessor is not advised in place of a µController as it makes the application quite costly. Microprocessor cannot be used stand-alone. They need other peripherals like RAM, ROM, Buffer, I/O ports etc. and hence a system designed around a microprocessor is quite costly.
3. State of the art: ISO 26262
ISO 26262 is an adaptation of the Functional Safety standard IEC 61508 for Automotive Electrical/Electronic/Programmable Electronic (E/E/PE) systems. This standard, called Road Vehicles – Functional Safety, has been published for the first time in November 2011.
This adaptation applies to all activities during the Safety Lifecycle of safety-related systems comprised of electrical, electronic and software components.
Safety is one of the key issues of future automobile development. New functionalities not only in areas such as driver assistance, propulsion, in vehicle dynamics control and active and passive safety systems increasingly touch the domain of system safety engineering. Development and integration of these functionalities will strengthen the need for safe system development processes and the need to provide evidence that all reasonable system safety objectives are satisfied.
With the trend of increasing technological complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and random hardware failures. ISO 26262 includes guidance to minimise these risks by providing appropriate requirements and processes.
System safety is achieved through a number of safety measures, which are implemented in a variety of technologies (e.g. mechanical, hydraulic, pneumatic, electrical, electronic, programmable electronic) and applied at the various levels of the development process. Although ISO 26262 is concerned with Functional Safety of E/E/PE systems, it provides a framework within which safety-related systems based on other technologies can be considered. ISO 26262 provides:
An Automotive Safety Lifecycle (management, development, production, operation, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases.
An Automotive-specific risk-based approach to determine integrity levels (Automotive Safety Integrity Levels or ASIL).
The use of ASILs to specify applicable requirements to avoid unreasonable residual risk.
Requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety being achieved.
Requirements for relations with suppliers.
Functional Safety is influenced by the development process (including such activities as requirements specification, design, implementation, integration, verification, validation and configuration), the production and service processes and by the management processes.
Safety issues are intertwined with common function-oriented and quality-oriented development activities and work products. ISO 26262 addresses the safety-related aspects of development activities and work products.
3.1.
Parental Standard IEC 61508
3.1.1. Origins of IEC 61508
By the 1980s, software had become the first choice of most designers of control systems. Its flexibility, the cheapness of its reproduction, and the ease with which it facilitates the introduction of new facilities, made it more attractive than purely hardware solutions. Its increased use included more and more safety-related applications, and there were uncertainties about the wisdom of this. It was recognized that it was almost impossible to prove software correct, and even if it were correct with respect to its specification, the difficulty of getting the completeness and accuracy issues with specifications was well known.
At that time, software engineering was still more art than engineering, and safety engineering was unknown in the software development community. Further, because safety was not in most cases studied in its own right, there was an implicit assumption that if a product or plant functioned reliably it would be safe. But safety and reliability are not synonymous:
Safety is the freedom from those conditions that can cause death, injury, occupational illness, or damage to or loss of equipment or property, or damage to the environment.
Reliability instead is the duration or probability of failure-free performance under stated conditions.
Moreover, with systems becoming larger and more complex, questions started to be asked about how safety might be proved and how the use of software in safety-related applications might be justified.
The questions and uncertainties were not limited to software. At the same time, hardware, in the form of microelectronics, was also becoming extremely complex and difficult to prove correct.
The awareness of these issues led to two studies being set up by the International Electro-technical Commission (IEC), one on systems (hardware) and the other on software, both within the context of the Functional Safety of modern programmable
electronic systems. The purpose behind each was the development of a standard to guide system designers and developers in what they needed to do in order to claim that their systems were acceptably safe for their intended uses.
In the early 1990s the two studies were merged, and in 1995 a draft standard, IEC 1508, was produced. This advocated a new approach to Functional Safety. Instead of designing and building a system as well as possible and then assuming that it would be safe, the draft standard called for a risk-based approach, in which the safety activities should be based on an understanding of the risks posed by the system. With an understanding of the risks, and a determination of which risks needed to be reduced, safety requirements would be defined to effect the risk reduction. As these safety requirements would be specified separately from the functional requirements, they could be implemented as simply as possible and also validated separately. This would result in direct evidence of safety planning and should lead to confidence that the risk reduction measures were commensurate with the risks.
Feedback on the draft standard led to further development, and between 1998 and 2000 the seven parts of its successor, IEC 61508, were ratified as an international standard. The principles embodied in the new standard were accepted internationally.
IEC 61508 is a generic standard, intended to satisfy the needs of all industry sectors. It is a large document, consisting of seven parts and a total of about 400 pages. Ideally it should be used as the basis for writing more specific (e.g. sector-specific and application-specific) standards, but it is also intended to be used directly where these do not exist. It has become a requirement of many customers, and its principles are perceived as defining much of what is considered to be good safety-management practice.
3.1.2. IEC 61508 structure
The standard consists of seven parts. The first four are normative i.e. they are mandatory and the fifth, sixth and seventh are informative i.e. they provide added information and guidance on the use of the first four.
General Requirements
It defines the activities to be carried out at each stage of the overall Safety Lifecycle, as well as the requirements for documentation, conformance to the standard, management and safety assessment.
Requirements for Electrical/Electronic/Programmable Electronic (E/E/PE) Safety-Related Systems and Software Requirements
Those two parts interpret the general requirements of Part 1 in the context of hardware and software respectively. They are specific to phase 9 of the overall Safety Lifecycle, illustrated in Figure 13.
Definitions and Abbreviations
It gives definitions of the terms used in the standard.
Examples of Methods for the Determination of Safety Integrity Levels
This part gives risk-analysis examples and demonstrates the allocation of safety integrity levels (SILs).
Guidelines on the Application of Parts 2 and 3 It offers guidance as per its title.
Overview of Techniques and Measures
It provides brief descriptions of techniques used in safety and software engineering, as well as references to sources of more detailed information about them.
Figure 12: Structure of IEC 61508
In any given application, it is unlikely that the entire standard would be relevant. Thus, an important initial aspect of use is to define the appropriate part and clauses.
3.1.3. Scope of IEC 61508 standard
IEC 61508 is not merely a technical guideline. Indeed, its primary subject is the management of safety and it is within this context that it addresses the technical issues involved in the design and development of systems. The standard seeks to introduce safety management and safety engineering, not only into software and system engineering, but also into the management of all aspects of systems. The standard embraces the entire Safety Lifecycle of a system, from concept to decommissioning.
Although the standard formally limits itself to those aspects of safety that depend on the hardware and software of E/E/PE systems, its principles are general and form a framework for addressing all aspects of the safety of all systems.
3.2.
Safety Lifecycle
The overall Safety Lifecycle is crucial to IEC 61508 as well as ISO 26262. Not only does it offer a model of the stages of safety management in the life of a system, but it also forms the structure on which the standard itself is based. Thus, the standard's technical requirements are stated in the order defined by the stages of the overall Safety Lifecycle.
The purpose of the overall Safety Lifecycle is to force safety to be addressed independently of functional issues, thus overcoming the assumption that functional reliability will automatically produce safety. Then, specifying separate safety requirements allows them to be validated independent of functionality, thus giving higher confidence of safety under all operating and failure conditions. The paradox, however, is that safety activities should not be carried out, or thought of, as totally disconnected from other project or operational activities. They need to be integrated into a total perspective of the system at all lifecycle phases.
Figure 13: Safety Lifecycle
The following descriptions explain the definitions of the different phases and sub phases of the Safety Lifecycle, as well as other key concepts:
Item definition
The initiating task of the Safety Lifecycle is to develop a description of the item with regard to its functionality, interfaces, environmental conditions, legal requirements, known hazards, etc. The boundary of the item and its interfaces, as well as assumptions concerning other items, elements, systems and components are determined.
Initiation of the Safety Lifecycle
Based on the item definition, the Safety Lifecycle is initiated by distinguishing between either a new development or a modification of an existing item. If an existing item is modified, the results of an impact analysis are used to tailor the Safety Lifecycle
After the initiation of the Safety Lifecycle, the Hazard Analysis and Risk Assessment is performed. First, the Hazard Analysis and Risk Assessment estimates the probability of exposure, the controllability and the severity of the hazardous events with regard to the item. Together, these parameters determine the ASILs of the hazardous events. Subsequently, the Hazard Analysis and Risk Assessment determines the safety goals for the item, with the safety goals being the top level safety requirements for the item. The ASILs determined for the hazardous events are assigned to the corresponding safety goals.
Functional Safety concept
Based on the safety goals, a Functional Safety concept is specified considering preliminary architectural assumptions. The Functional Safety concept can also include other technologies or interfaces with external measures, provided that the expected behaviours thereof can be validated. Product development at the system level
After having specified the Functional Safety concept, the item is developed from the system level perspective. The system development process is based on the concept of a V-model with the specification of the technical safety requirements, the system architecture, the system design and implementation on the left hand branch and the integration, verification, validation and the Functional Safety assessment on the right hand branch.
Product development at the hardware level
Based on the system design specification, the item is developed from the hardware level perspective. The hardware development process is based on the concept of a V-model with the specification of the hardware requirements and the hardware design and implementation on the left hand branch and the hardware integration and testing on the right hand branch.
Product development at the software level
Based on the system design specification, the item is developed from the software level perspective. The software development process is based on the concept of a V-model with the specification of the software requirements and the software architectural design and implementation on the left hand
branch, and the software integration and testing, and the verification of the software requirements on the right hand branch.
Production planning and operation planning
The planning for production and operation, and the specification of the associated requirements, starts during the product development at the system level
Production and operation, service and decommissioning
This phase addresses the production processes relevant for the Functional Safety goals of the item, i.e. the safety-related special characteristics, and the development and management of instructions for the maintenance, repair and decommissioning of the item to ensure Functional Safety after the item's release for production
Controllability
In the Hazard Analysis and Risk Assessment, credit can be taken for the ability of the driver, or the other persons at risk, to control hazardous situations. The assumptions regarding the controllability in the Hazard Analysis and Risk Assessment and the functional and technical safety concept are validated during the safety validation
External measures
The external measures refer to the measures outside the item, as specified in the item definition, that reduce or mitigate the risks resulting from the item. External measures can include not only additional in-vehicle devices such as dynamic stability controllers or run-flat tyres, but also devices external to the vehicle, like crash barriers or tunnel fire-fighting systems.
Other technologies
Other technologies, e.g. mechanical and hydraulic technologies, are those different from electrical and/or electronic technologies that are in the scope of ISO 26262. These can be considered in the specification of the Functional Safety concept, during the allocation of safety requirements
3.3.
Scope of ISO 26262
The first edition, published in November 2011 is intended to be applied to Electrical and/or Electronic systems installed in series production passenger cars with a maximum gross weight of 3500kg. It aims to address possible hazards caused by the malfunctioning behaviour of electronic and electrical systems.
The standard aims to cover:
Hardware and Software such as electric or electronic devices
Parts or systems that may significantly impact on human lives in case of malfunction/failure are considered
Equipment that consists only of machinery is out of its scope The entire Life Cycle of Automotive products
Motor vehicles up to 3500kg
Safety has been a key aspect in the Automotive Industry even from its earliest stages, but the importance with which it is regarded has become far greater in recent times.
The word Safety is subject to various different interpretations. However, when applied to modern automobile design it can generally be categorized using the following structure:
Passive Safety: Assuming that an accident is effectively inevitable, the aim of passive Safety Mechanisms is to minimize the severity of that accident. The passive safety elements found within a vehicle include seatbelt, crumple zones, airbag, etc.
Active Safety: The systems that are concerned with active safety (based on the knowledge of the current state of the vehicle) will aim to avoid accidents altogether in addition to the minimization of its effects if an accident occurs. Predictive emergency braking, anti-lock braking systems and traction control are all examples of this.
Functional Safety: This focuses on ensuring that all of the electrical and electronic systems (such as power supplies, sensors, communication networks, actuators, etc.), including (but not limited to) all; active Safety
Related systems, function correctly. Functional Safety is dealt with by the ISO 26262 standard.
3.4.
Structure of ISO 26262
The standard consists of 9 normative parts and a guideline for the ISO 26262 as the 10th part. It is based upon a V-Model as a reference process model for the different phases of product development.
The standard is composed in ten parts: Vocabulary
This part of ISO 26262 specifies the terms, definitions and abbreviated terms for application in all parts of ISO 26262.
Management of Functional Safety
This part of ISO 26262 specifies the requirements for Functional Safety management for Automotive applications, including project-independent requirements with regard to the organizations involved (overall safety management), and project-specific requirements with regard to the management activities in the Safety Lifecycle (i.e. management during the concept phase and product development, and after the release for production).
Concept Phase
This part of ISO 26262 specifies the requirements for the concept phase for Automotive applications, including item definition, initiation of the Safety Lifecycle, Hazard Analysis and Risk Assessment, and Functional Safety concept.
Product Development at the System Level
This part of ISO 26262 specifies the requirements for product development at the system level for Automotive applications, including requirements for the initiation of product development at the system level, specification of the technical safety requirements, the technical safety concept, system design, item integration and testing, safety validation, Functional Safety assessment, and product release.
Product Development at the Hardware Level
This part of ISO 26262 specifies the requirements for product development at the hardware level for Automotive applications, including requirements for the initiation of product development at the hardware level, specification of the hardware safety requirements, hardware design, hardware architectural metrics, and evaluation of violation of the safety goal due to random hardware failures and hardware integration and testing.
Product Development at the Software Level
This part of ISO 26262 specifies the requirements for product development at the software level for Automotive applications, including requirements for initiation of product development at the software level, specification of the software safety requirements, software architectural design, software unit design and implementation, software unit testing, software integration and testing, and verification of software safety requirements.
Production and Operation
This part of ISO 26262 specifies the requirements for production, operation, service and decommissioning.
Supporting Processes
This part of ISO 26262 specifies the requirements for supporting processes, including interfaces within distributed developments, overall management of safety requirements, configuration management, change management, verification, documentation, confidence in the use of software tools, qualification of software components, qualification of hardware components, and proven in use argument.
ASIL-oriented and Safety-oriented Analyses
This part of ISO 26262 specifies the requirements for Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses, including requirements decomposition with respect to ASIL tailoring, criteria for coexistence of elements, analysis of dependent failures, and safety analyses. Guidelines on ISO 26262
This part of ISO 26262 provides an overview of ISO 26262, as well as giving additional explanations, and is intended to enhance the understanding of the other parts of ISO 26262. It has an informative character only and describes
the general concepts of ISO 26262 in order to facilitate comprehension. The explanation expands from general concepts to specific contents.
Figure 14: Structure of IEC 61508
3.5.
How to determinate ASILs
ISO 26262 classifies the safety attribute into four criticality levels, from the least critical ASIL A to the most critical ASIL D.
ASILs are assigned by three principal characteristics: Severity
It describes the seriousness of possible injuries resulting from a failure. It is divided into four classes:
o S0: No injuries. It does not appear in the table as no ASIL assignment is required
o S1: Light and moderate injuries
o S3: Life-threatening injuries and fatal injuries. This category may contribute to injuries and even fatal injuries.
Exposure
It is the probability of being in an operational situation that can be hazardous if coincident with a failure mode under analysis. It is divided into four classes:
o E0: Improbably
o E1: Very low probability o E2: Low probability o E3: Medium probability o E4: High probability Controllability
It is the ability to avoid a specified harm or damage through the timely reactions of the persons involved, possibility with support from external measures. It divided into four classes:
o C0: Controllable in general. It means that it does not appear in the table, as no ASIL assignment is required.
o C1: Simply controllable o C2: Normal controllable
o C3: Difficult to control or uncontrollable
In the Part 3 of the standard ISO 26262 is provided examples of these classifications.
The table shows how different degrees of severity, exposure and controllability combine to assign an ASIL at criticality level A to D. Note that the most critical ASIL level D is only assigned when there is a combination of the highest class on all three parameters, while if the safety goal is classified as Quality Management (QM) then ISO 26262 does not need to be applied.
A fundamental principle of the ASIL classification is that it is the safety goals, not the system, that are evaluated. It must be borne in mind that a system usually has to fulfil a whole host of safety goals.
Unfortunately, in practice even experts have adopted an interpretation whereby the most important ASIL classification is transferred to the system. It is therefore common to talk of an ASIL-D system in the case of an airbag system, for example, ignoring the fact that an airbag system must also fulfil many other safety goals under various different ASIL classifications.
As the ASIL classification for any safety goals is typically calculated at whole-vehicle level and separately from the actual implementation of the system, it makes sense for the vehicle manufacturer to specify the safety goals to his suppliers together with the corresponding ASIL classifications. This can be regulated under a DIA (Development Interface Agreement). If this is not the case, e.g. in the case of platform development on the part of the supplier, then the supplier must make assumptions regarding the safety goals and associated ASIL classifications, which the customer (OEM, Original Equipment Manufacturer) must then validate on system integration. Note that there is also an ISO working group to help determine ASIL classifications for certain applications specific safety goal.
The authors of the standard have gone out of their way to keep it as generic as possible. For example, the standard itself prescribes certain properties and criteria that must be fulfilled as part of the functional and technical safety concept within the framework of the ASIL classification but does not cover the selection of a specific safety concept. Strength of this approach is that it does not impose any unnecessary or potentially indiscriminate restrictions and thus ensures the standard's longevity. As a consequence, the information regarding the definition of a suitable safety concept must be acquired in another manner and, naturally, many different safety concepts are suitable for achieving the same safety goals.
If the ASIL used to classify a Safety Goal is not correctly assigned, in term of legacy there could be the possibility to be liable in case of accidents, while in term of process it could lead to an uncompetitive product, to unnecessary delays and to increase marketing costs.
3.6.
Tools Qualification
Even tools used to develop the safety product have to be checked and qualified because they may also introduce faults.
The objective of ISO 26262 software Tool Qualification is to provide evidence that a software tool is suitable for use in the development of safety-related software, such that confidence can be achieved in the correct execution of activities and tasks required by ISO 26262.
To determine the required Tool Confidence Level (TCL), the use cases of the tool shall be analysed. This analysis shall evaluate:
If a malfunctioning software tool and its erroneous output can lead to the violation of any safety requirement allocated to the safety-related software to be developed.
The probability of preventing or detecting such errors in the output of the tool. The evaluation considers measures internal to the software tool (for example, monitoring), as well as measures external to the software tool (for example, guidelines, tests, and reviews) that are implemented in the development process for the safety-related software.
The ISO 26262 tool qualification process requires the creation of the following tool qualification work products:
Software Tool Qualification Plan (STQP)
The software tool qualification plan is a planning document created in an early phase of the development of the safety-related system. It identifies the tool and its version to be qualified, the intended configuration and operational environment and also lists the intended tool use cases.
Software Tool Documentation (STD)
The software tool documentation comprises different information that the tool applicant may need when using the tool. It comprises information such as: tool overview, available tool documentation set, operational environment and constraints, installation instructions, known issues. The STD also provides information necessary to check whether the use cases, configurations and operational environment listed in the STQP are supported by the tool.
Software Tool Classification Analysis (STCA)
The tool classification is necessary to determine the required tool confidence level (TCL). It depends on the particular tool use cases used during the development of the application under consideration.
Figure 16: Determination of TCL Three steps are needed to define a TCL level.
o First the Tool Impact (TI): the intended use cases for the tool shall be analysed to determine if a safety requirement can be violated if the software tool is malfunctioning or producing erroneous output. If a violation of a safety requirement is not possible, tool impact TI0 shall be chosen; otherwise, the tool impact is TI1.
o Second the Tool Error Detection (TD): the intended software tool use cases shall be analysed to determine the probability of preventing or detecting that the software tool is malfunctioning or producing erroneous output. The degree of confidence, that a malfunction or an erroneous output from the tool can be prevented or detected, determines the tool error detection TD.
o In the end Tool Confidence Level (TCL) can be determined following the schematics provided in Figure.
The software tool qualification reports documents the actual tool qualification, i.e. provides evidence that the tool qualification was carried out as planned.
4. Functional Safety
ISO 26262 provides the requirements to be followed to produce an Automotive System that can guarantee with a reasonable confidence no harm and damage for the driver and all passengers.
Hazard Analysis, Safety Analysis and Functional Injection are instruments that have to be used to achieve the Functional Safety scope.
Functional Safety is a concept applicable across all industry sectors. It is fundamental when using complex technology in safety-related systems. It provides the reasonable confidence that the safety-related systems will offer the necessary risk reduction required to achieve safety for the equipment.
4.1.
Definition
To define what Functional Safety is it is useful to start defining the meaning of Safety.
Safety is the state of being safe, the condition of being protected against physical, social, spiritual, financial, political, emotional, occupational, psychological, educational or other types or consequences of failure, damage, error, accident, harm or any other event which could be considered non-desirable.
Then, Functional Safety is the part of the overall safety of a system or piece of equipment that depends on the system or equipment operating in a safe manner in response to its inputs, including the safe management of possible operator errors, hardware failures and environmental changes.
Functional Safety is also the detection of a potentially dangerous condition resulting in the activation of a protective or corrective device or mechanism to prevent hazardous events arising or providing mitigation to reduce the consequence of the hazardous event.
4.1.1. Scope
Every time that an application can lead a physical injury or damage to the health of people either directly or indirectly, then we need to consider Functional Safety on that application.
The challenge is to design the system in a way such that prevents dangerous failures or to control them when they arise. An example in automotive field is “limp home” mode: a default setting in the computer of fuel-injected cars. It is designed to take over the control calibrations of the engine when a serious problem is detected. Dangerous failures may arise from:
Incorrect specifications of the system, hardware or software;
Omissions in the safety requirements specification (e.g. failure to develop all relevant safety functions during different modes of operation);
Random failures of hardware;
Systematic failures of hardware and software; Common cause failures;
Human error;
Environmental influences (e.g. electromagnetic, temperature, mechanical phenomena);
Supply system voltage disturbances (e.g. loss of supply, reduced voltages, noise and/or glitches).
In the modern cars or vehicles there are up to 100 µControllers where each of them is specified to develop a particular function.
4.1.2. How to achieve Functional Safety
Functional Safety is achieved when every specified safety functions are carried out and the level of performance required of each safety functions is met. The flow that has to be followed to achieve Functional Safety comprises:
This means the hazards and safety functions have to be known. A process of function review, formal HAZard IDentification (HAZID), HAZard and OPerability analysis (HAZOP) and Accident Reviews are applied to identify these.
Assessment of the risk-reduction required by the safety function.
This will involve a Safety Integrity Level (SIL or ASIL) that applies to an end-to-end safety function of the safety-related system, not just to a component or part of the system.
Ensuring that the safety function fits with the design intent.
This has to include conditions of incorrect operator input and failure modes. This will involve that the design and lifecycle have to be managed by qualified and competent engineers carrying out processes using a recognised Functional Safety standard. ISO 26262 is the specific one for Automotive System.
Verification of the assigned level.
The system has to meet the assigned SIL or ASIL finding the Mean Time Between Failures and the Safe Failure Fraction (SFF), along with appropriate tests. The Safe Failure Fraction is the probability of the system failing in a safe state: the dangerous (or critical) states are identified from a Failure Mode and Effects Analysis of the system (FMEA).
Conduct Functional Safety audits.
This is needed to examine and assess the evidence that the appropriate Safety Lifecycle management techniques were applied consistently and thoroughly in the relevant lifecycle stages of product.
4.1.3. What is Functional Safety in accordance with ISO 26262?
ISO 26262 focuses on the Functional Safety of E/E/PE systems in vehicles. Functional Safety in accordance with ISO 26262 affects all systems containing electrical, electronic, or electromechanical components, i.e. systems from the fields of actuator and sensor technology as well as control electronics. Industrial systems in general are covered by IEC 61508, with additional sector-specific standards
applying to railroad technology, aircraft technology, etc. ISO 26262 is the sector-specific extension of IEC 61508 to the Automotive Industry.
Functional Safety is concerned with the absence of unreasonable risk to individuals caused by potential malfunctions in E/E/PE systems. Functional Safety is therefore considered a system property. Known active and passive safety systems differ in the fact that active safety focuses on proactive accident prevention, whereas passive safety relates to the reactive mitigation of the consequences when an accident has already occurred. The electronic systems for active and passive safety must themselves be functionally secure since malfunctions in these systems could also cause personal injury.
Figure 17: Examples of Active and Passive safety elements that can be active before, during and after a collision
As shown in the above picture, the elements that are always in alert to prevent accident or to help the drive of the vehicle not to cause injuries to anyone represent the active safety elements. They comprise systems that check instantly the distance from the head vehicle, alarm systems that alert the driver of the wrong position on the lane, systems that are concerned about traction control, electronic stability control, electronic steering, and other systems, with the intent of improving responsiveness to driver input, performance and overall safety, systems that help the driver during the night or in blind corners, navigator systems, etc.
Functional Safety focuses on risks arising from random hardware faults as well as systematic faults in system design, in hardware or software development, or in production, through to the commissioning, repair, and withdrawal of the system. To this scope, ISO 26262 comprises 10 sections with about 750 requirements on approximately 450 pages, which deal with system design, hardware, software, and the associated development processes among other things. The Safety Lifecycle plays an important role in this regard. The Safety Lifecycle governs the identification, design, monitoring and evaluation of the various elements involved in an industry-standard V-model in causal sequence. The term Functional Safety should not be confused with or, even worse, equated to product characteristics such as reliability, availability, and security:
Reliability is the ability of a system to operate as expected.
It is required when a system has to work continuously without any failure. Reliability is measured in Failure in Time (FIT).
Availability is the ability of a system to operate at a particular time.
It is allowed to a system to have some period of interruptions (i.e. stand-by state, to save the battery charge).
Safety is the ability of a system not to lead to injury.
If there is a fault, the system must be designed to take appropriate action. Safety is measured with a range of probabilities, for example, Probability of Failure per Hour (FPH), Probabilistic Metric of Hardware Failure (PMHF), etc. ISO 26262 itself is not a certification standard and therefore contains no clauses regulating certifications or the scope thereof.
From the point of view of the standard, there is no requirement to certify systems, components or processes against it; neither is this standard directly relevant for vehicle registration. The competent certifying bodies are currently finalizing the content of these checks.
From a legal point of view, ISO 26262 does not bring any direct change in the legal situation. The provisions of product liability and liability for material defects continue to apply. With regard to other legal aspects such as reversal of the burden of proof, reference is made to the relevant legal publications. In general, professional standards are deemed relevant when assessing the state of the art, meaning that ISO 26262 is naturally of indirect legal importance.
To take into account the supply structure in the Automotive Industry, ISO 26262 contains requirements for regulating safety-relevant responsibilities in the case of split-site development. This is the purpose of the Development Interface Agreement (DIA), which covers the explicit detailed agreement between the companies involved at their interfaces.
4.1.4. How Functional Safety is achieved in accordance with
ISO 26262
The Safety Lifecycle starts with a definition of the system to be considered at vehicle level as the item. The next step is to carry out a Hazard Analysis and Risk Assessment for the system to be considered.
A corresponding safety goal must then be determined for each hazard. Typically, a large number of safety goals are identified at that point. Each safety goal is then classified either in accordance with QM or in accordance with one of four possible safety classes (from ASIL A to ASIL D).
Safety goals must be implemented in accordance with the classified ASILs. In other words, suitable processes and methods must be implemented to avoid systematic faults and corresponding additional requirements must be applied to the product to rectify technical faults. This is done initially by defining a Functional Safety concept.
