×

Happy to Help!

This website doesn't store cookies. Enjoy the experience, without worrying about your data!

Great, thanks!

ISO 26262 Compliant Unit Testing Strategies: A Step Towards Achieving Functional Safety in Automotive Product Development

  • Home
  • _e("Posts tagged","weblizar") "ISO 26262 Standard"
  • July 13, 2018
  • 0

ISO 26262 Compliant Unit Testing Strategies: A Step Towards Achieving Functional Safety in Automotive Product Development

Tags :

Category : Embedded Blog

It is always better to be safe than sorry! And when human life is at stake, the commitment to safety requires to be of highest order.

We are talking about safety of the automobiles – passenger vehicles, commercial vehicles, off-road vehicles, Electric Vehicles and more. To be more specific, we are referring to the Functional Safety in Automotive.

As per the ISO 26262 standard, functional safety corresponds to the fool-proof design and development of electric and electronic components of a vehicle.

“There are an exploding number of electronic and electric components in a modern-day automobile. A lot of them including the anti-lock braking system, airbags, electronic power steering and more have a direct impact on the safety of the driver and the passengers. Rigorous and standardized software and hardware testing process is one of the ways to ensure robust and fool-proof systems.”

In this blog, we will talk about the unit testing aspect of the functional safety. The need for such a guideline will also be discussed.

The transition from ISO 9001 based Testing to ISO 26262 Compliant Unit Testing

As already mentioned, the safety criticality of several automotive components is quite high. In such scenarios, the functional safety at both unit level and system level needs to be ensured.

A few years back when ISO 26262 was uninitiated, the unit testing standards were in compliance with ISO 9001. The need for the concepts of ‘functional safety’ arose when certain failures in safety critical components started getting reported on a regular basis.

After Though testing has always remained a part of automotive product development process, but after these recalls, the testing process was in dire need of a revamp.

On top of this, the numerous car recalls by many global automotive OEMs over the years also added fuel to the fire. In these recalls, sometimes, the fault was found to be with the airbag and at times, with the braking system.

Though testing has always remained a part of automotive product development process, but after these recalls, the testing process was in dire need of a revamp.

“One of the major aspects where ISO 26262 compliant Unit Testing differs with ISO 9001 is related to the writing of the test cases. For ISO 26262 compliance, the test cases are always written in accordance with the safety requirements.”

New concepts and methods of unit testing have been included in the ISO 26262 that make it ideal for achieving functional safety in automobiles. We will touch upon these methods further in the blog.

ISO 26262 Compliant Unit Testing: What Makes the Process Different?

If we look from a broad perspective, ISO 26262 guidelines are focused on making the software codes more comprehensible, reliable and easy to test. One of the example is the restriction of the software component and their interface sizes. By doing so, the code is rendered less prone to errors.

The ISO 26262 unit testing guidelines aim at demonstrating that only the unit design specifications are fulfilled and any unrequired feature is done away with.

Such requirement based unit testing lets the automotive testing team input the values and check the output. Depending on the output, the bugs are identified and processed.

Understanding the Unit Testing Recommendation Table, Defined by ISO 26262

The section 6 of ISO 26262 standard has the recommendations for unit and integration testing. The recommendation table 10 has all the methods for software unit testing. Whereas, the table 11 recommends the methods for derivation of the test cases.

We will go through each of the methods to have a better understanding:

ISO 26262 Table 10 – Methods for unit testing of the software

Requirement-based test: This method helps in systematic identification of implementation failures. The failures occurring due to incomplete and inconsistent requirement are also identified.

In this method, the input values are derived from the behavioral requirements which are usually developed previously. If there are no documented requirements, they need to be deduced from the functional model as it has the executable specifications.

It has to be made sure that for all the requirements that have to be implemented by a software unit, one test case must be defined.

After the requirements are finalized, requirement-based testing is applied. As we can see in the table, it is mandatory for all ASIL ratings (A to D).

ISO 26262 Unit Testing 1

 

PS: The ‘+’ symbol in the table implies Recommended and ‘++’ implies strongly recommended

Interface Testing as per ISO 26262 standard: Correct implementation of interfaces is very strongly recommended by the ISO 26262 unit test recommendation table. This is because, every software unit may have been tested individually but their communication with other units is also very critical.

During the interface testing, the value range of the incoming signals from the interface is defined and divided in classes. These classes have a boundary value which is used to define the test cases. After the test cases are defined interface testing can be performed.

Interface testing is performed to detect early failures that could go unnoticed till the integration testing process. At that stage, it would be even difficult to localize the issue.

Fault Injection Testing: Quite a self-explanatory term, fault injection implies the insertion of some arbitrary faults. This may include corrupting the values of CPU registers, code mutation, corrupting the variable value and more. Faults can be injected either at compile time or run-time.

This testing is done to ensure that the software unit behaves in an expected manner at the occurrence of any error.

Fault Injection Testing is strongly recommended, but only for automotive products that require ASIL D compliance.

ISO 26262 Unit Testing 2

 

Resource Usage Test: This test is performed to ensure that the unit being tested does not eat up a lot of CPU memory. Resource Usage testing is usually done on the target platform or the simulator. This test is strongly recommended only when the software product is targeting to be ASIL D compliant.

Back-to-back Comparison Test: The software unit under test must behave like the model based on which the unit was designed. Back-to-back comparison test achieves exactly that.

For this test method, a model is required that can simulate the unit being tested. The test suites from the source code are applied to the model and vice versa. The results of both the scenarios are compared and output is recorded.

ISO 26262 Recommendation Table 11- Derivation of Test Cases

The entire process of requirement based testing depends on the test cases you have defined. ISO 26262 underlines some methods to derive these test cases to ensure the software is assigned the required ASIL level.

We look at some of the test case derivation methods at a glance:

Requirement Analysis: Every software unit will have some behavioral requirements. For instance, if a function is supposed to return ‘0’ as the output for a negative input value, we will keep -1 as a test case value.

If you are using some unit testing tools, these values will be generated based on the requirements. It is strongly recommended for all ASIL levels.

Analysis of the Equivalence Classes: There is a range of input values for which the behavior of the software unit should be similar. This range is called the equivalence class.

These classes can be identified based on the input and output division. The input range thus derived is categorized under a subset of the unit. Once the equivalence classes are determined, a value that represents the class is chosen and test class is generated based on it.

Equivalence class test generation is strongly recommended by ISO 26262 recommendations for ASIL B to D compliance.

Boundary Values Analysis: Every input can have a minimum and maximum possible value, called the boundary values. For software being tested for ASIL B, C or D, test generation based on boundary values is strongly recommended.

The Metrics for ISO 2626 Compliant Unit Test Coverage

Statement Coverage: A part of unit testing, statement coverage covers those lines of codes that have been tested at least once. Only one test case is required. Statement coverage is strongly recommended only for ASIL level A and B.

ISO 26262 Unit Testing 3

 

Branch Coverage: Branch coverage is applicable at a decision point, for eg. an ‘if…else’ condition. In such a scenario, both true and false condition need to be executed. Naturally, two test cases are required here. It is strongly recommended for ASIL B, C and D functional safety compliance.

Modified Condition/Decision Coverage (MCDC): This is where Functional Testing becomes a very serious business. MCDC is highly recommended for ASIL level D. Here, every condition in the decision in the ‘if.. else’ condition or the loops, can independently influence the outcome.

Role of Testing Tools in ISO 26262 compliant Unit Test Process

The Unit Testing tools can be quite helpful in helping you achieve the right ASIL level for your software. Running the unit test methods manually can be an extensive task and prone to errors.

Tools like Reactis and CANTATA etc. ease the process considerably. They can help the developers automate the testing process by

  • Test case derivation
  • Framework generation
  • Execution of the test cases
  • Test report generation etc.

Many of these tools are built around the ISO 26262 guidelines and offer complete structural coverage metrics at the software unit level.

Concluding Thoughts

ISO 26262 has become a de facto standard for automotive industry in terms of functional safety. The unit testing recommendations by ISO 26262 should be followed in letter and spirit to build a really safe automotive system.

If you are new to ISO 26262 and functional safety, we recommend these blogs for you to have a clear understanding of concepts like safety management, ASIL level etc.

  • April 19, 2018
  • 0

Understanding How ISO 26262 ASIL is Determined for Automotive Applications

Tags :

Category : Embedded Blog

According to the Motor vehicle safety data, by the BTS (Bureau of Transportation Statistics), more than 6 million crashes involving motor vehicles are reported every year on an average.

As per the U.S. Transportation Department data, United States automakers had to make a record safety recall of 53.2 million vehicles in 2016. This increase in auto safety recalls was caused by the rise in road traffic deaths/road traffic fatalities in U.S.

An auto recall, according to National Highway Traffic Safety Administration (NHTSA, US), is said to be issued when a manufacturer or NHTSA determines that a vehicle, equipment, car seat, or tire can create an unreasonable safety risk or fails to meet minimum safety standards”.

These statistics clearly lead us to one common conclusion – how even after technical advancements along the breadths and depths of the industry, an automobile is still a major reason for road accidents.

Hence safety, becomes the fundamental requirement of an automotive application development. For an automotive vehicle, in specific, the functional safety is a very crucial paradigm at every stage of production and decommission.

The Functional Safety Paradigm in Automotive

Within the automobile industry, the functional safety as a process is based on the guidelines specified by ISO 26262 , an international safety standard for automotive.

ISO 26262 standard defines functional safety as the “absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical/electronic systems”.

For ISO 26262 compliance; a functional safety consultant identifies and assesses hazards (safety risks). These hazards are then categorized based on their criticality factor under the Automotive Safety Integrity Level (ASIL) under ISO 26262. Such a clear classification of hazards helps to :

  • Establish various safety requirements to mitigate the risks to acceptable levels
  • Smoothly manage and track these safety requirements
  • Ensure that standardized safety procedures have been followed in the delivered product.

Automotive Safety Integrity Level (ASIL) , specified under the ISO 26262 is a risk classification scheme for defining the safety requirements. Under the ISO 26262, ASILs are assigned by performing a risk analysis of a potential hazard by looking at various risk parameters (Severity, Exposure and Controllability) of the vehicle operating scenario.

ASIL and Safety Criticality of Automotive Components:

The safety lifecycle of any automotive component, within the ISO 26262 standard starts with the definition of the system and its safety-criticality at the vehicular level.

This is done through hazard analysis and risk assessment for the corresponding automotive component (hardware/ software), necessary for the determination of the Automotive Safety Integrity Level (ASIL) .

Hence, determination of ASIL forms the very first phase of the automotive system development.  Here, basically all potential scenarios of hazards and dangers are evaluated for a particular automotive component, the occurrence of which can be critical for vehicle safety.

For example, an unexpected inflation of airbag or failures of brakes are potential safety hazards that should be assessed and managed in advance. This step is followed by identifying the safety goals for each component, which are then classified according to either the QM or ASIL levels, under the ISO 26262 standard.


ISO 26262 Standard
Automobile Safety Issue types. Image credit: Mentor

Safety goals are basically the level of safety required by an automotive component to function normally without posing any threats to the vehicle.

For example, for a car door, the safety goal could be both the importance of having it opened or closed depending on which action is safe under a particular condition. During instances of fire inside the vehicle or a flood, the safety goal would be to have the car door opened as quickly as possible so that the passengers can escape. On the contrary, while the vehicle is moving fast, the safety goal related to the door will be to remain closed- accidental opening of door of a moving car could lead to greater risks.

Determining the ISO 26262 ASIL for an Automotive Application

There are four ASILs identified by the ISO 26262 standard: ASIL A, ASIL B, ASIL C, ASIL D.

ASIL D represents the highest degree of automotive hazard and ASIL A the lowest. There is another level called QM (for Quality Management level) that represents hazards that do not dictate any safety requirements.

The following figure demonstrates the steps involved in the determination of ASIL for an Anti-Breaking System ( ABS).


ASIL for an Anti-Breaking System ( ABS)
Image credit: Whitepaper by Cadence

For any particular failure of a defined function at the vehicle level, a hazard and risk analysis (HARA) helps to identify the intensity of risk of harm to people and property. Once this classification is completed, it helps in identifying the processes and the level of risk reduction needed to achieve a tolerable risk. Safety goal definition as per ASIL is performed for both hardware and software processes within automotive design to ensure highest levels of functional safety.

These safety levels are determined based on 3 important parameters:

Exposure ( E): This is the measure of the possibilities of the vehicle being in a hazardous or risky situation that can cause harm to people and property. Various levels of exposure such as E1: very low probability, E2: low probability, E3: medium probability, E4: high probability are assigned to the automotive component being evaluated.

Controllability (C) : Determines the extent to which the driver of the vehicle can control the vehicle if a  safety goal is breached due to  failure or malfunctioning of any automotive component  being evaluated. The order of controllability is defined as: C1<C2<C3 ( C1 for easy to control while C3 for difficult to control).

Severity ( S): Defines the seriousness or intensity of the damage or consequences to the life of people ( passengers and road users) and property due to safety goal infringement. The order of severity is : S1 for light and moderate injuries; S2 for severe and life-threatening injuries, and  S3 for life-threatening incidences.

The ISO 26262 ASIL Allocation table

The ASIL levels – ASIL A, B, C ,and D are assigned based on an allocation table defined by the ISO 26262 standard.


ASIL Levels
Evaluation safety goals of automotive components Image credit: techdesignforums

Let us try to understand the determination of ASIL values for various components based on the E,C and S parameters.

Few observations from the ASIL allocation table,

  1. A combination of S3, E4 and C3 (the extremes of the 3 parameters) refers to a highly hazardous situation. Hence the component being evaluated is identified to be ASIL D, which means it is prone to severely life-threatening events in case of a malfunction and calls for the most stringent levels of safety measures.
  2. On the contrary, a combination of S1, E1 and C1 ( the lowest levels of the 3 parameters in terms of safety-criticality) calls for QM levels, which means the component is not hazardous and does not emphasize safety requirements to be managed under the ISO 26262.
  3. Similarly, combination of the medium levels – S2, E4 and C3 or S2,E3 and C2 defines either an ASIL C or an ASIL A.

The intensity of the hazard thus depends on the ASIL levels of the components , under consideration. Allocation of ASIL helps in identifying how much threat the malfunctioning of a particular component can cause under various situations.

Under the framework of the ISO 26262 ASIL and functional safety; the safety goals are more critical than the functionality of the automotive component. Let us take the example of charging of a vehicle battery to understand this statement.

The safety goals associated with a battery is a more critical consideration to be evaluated as per ASIL, more than the battery itself as shown in the table below. The overcharging of battery at a speed below 10 km/hour is not as serious a situation as overcharging at very high speeds, where the possibilities of overheating and consequent fire could also be high. :

Vehicle Condition Cause of malfunction Possible hazard ASIL
Running Speed< 10 km/h Charging of battery pack beyond allowable energy storage Overcharging may lead to thermal event A
Running Speed> 10 – 50 km/h Charging of battery pack beyond allowable energy storage Overcharging may lead to thermal event B
Running Speed>  50 km/h Charging of battery pack beyond allowable energy storage Overcharging may lead to thermal event C

Thus, ASIL determination forms a very critical process in the development of highly reliable and functional safe automotive applications. In today’s time where the car designs have become increasingly complex with huge number of ECUs, sensors and actuators, the need to ensure functional safety at every stage of product development and commission has become even more important.

This is why modern day automotive manufacturers are very particular about meeting the highest automotive safety standards in accordance to the ISO 26262 standard and ASIL Levels.

  • April 11, 2018
  • 0

Challenges Your Automotive Team may Face in ISO 26262 Functional Safety Compliance

Tags :

Category : Embedded Blog

The need for functional safety of E/E systems has become imperative in automotive industry. This is mainly due to the inherent complexity of the electronics embedded systems.

The malfunctioning of the electronic components like the Electronic Control Units (ECUs) has serious repercussions on the safety of the driver and passengers.

For instance, if the ECU controlling the braking system of the vehicle malfunctions, a fatal accident might occur.

With the introduction of ISO 26262, a standard for functional safety of electronics and electric system in road vehicles, the Automotive OEMs and Suppliers have a framework to ensure that the automotive ECU is designed according to the defined safety criticality.

However, with hundreds of electronics and electric systems and sub-systems that are part of the modern-day vehicle; the implementation of ISO 26262 standard has become an uphill task.

We will talk about the associated ISO 26262 challenges and some recommended solutions.

But before we discuss the challenges lets understand the ISO 26262 implementation in a nutshell. You can also refer to our first blog on ISO 26262 to get a clear picture.

ISO 26262 Functional Safety
Source: National Instrument

Understanding ISO 26262 implementation

ISO 26262 standard provides a framework for the entire automotive safety lifecycle i.e. from development to decommissioning. A risk-based approach is followed by ISO 26262 to determine the safety criticality of a component.

Following are some of the critical steps your ISO 26262 consultant may choose to follow:

  • Step 1: Hazard analysis and risk assessment are carried out based on the guidelines defined in ISO 26262 functional safety standard.
  • Step 2: ASIL (Automotive Safety Integrity Level) is assigned to the components and safety goals are determined.
  • Step 3: In the development phase, the safety requirements are classified into software and hardware.

The process may sound easy but in practice, altering the current process of automotive product development and making it ISO 26262 compliant is very challenging.

The functional safety consultant needs to anticipate potential malfunction scenarios of the proposed system right at the onset and recommend solutions to address them.

ISO 26262 Compliance

Source: Research Gate

Major Challenges in achieving ISO 26262 Compliance

  1. Hazard Analysis and Assigning ASIL

    2. Determination of the safety goals along with assigning of ASIL level come across as a major challenge in the course of ISO 26262 implementation.

    Hazard analysis helps to identify and analyse the safety goals of the system, which in turn is used to derive the requirements of functional and technical safety. The hardware and software design of the electronic system of a vehicle has to be prepared in accordance with these derivations.

    The assigning of ASIL to the automotive components depends on 3 factors viz. severity, exposure, and controllability. These three factors are quite hard to determine without adequate exposure to the use cases.

    The factors of severity, exposure and controllability need to be analysed consistently for a particular driving condition in order to prevent the ASIL being reduced. This could happen if we choose the lowest categories of the 3 factors for different driving conditions.

    In addition to the determination of the risk parameter, defining them in a qualitative way is a major problem that is faced by the ISO 26262 experts.

  2. Non-uniformity of Functional Safety Activities Among the OEMs, Suppliers And After-Market Companies

    3. In this day and age of globalization, a distributed approach of development is followed in most industries and automotive is no exception. Hundreds of components in a vehicle are outsourced to tier-1 suppliers some of which they outsource to other service providers.

    In such a scenario, the safety requirement of the component derived at different levels i.e. at OEM, tier-1 suppliers and after-market suppliers need to be uniform.

    Also, the safety requirements need to be shared among them so that there is no incompatibility in the final product.

    For instance, the UDS stack for an ECU is being developed by one organisation and the BSP by the other. Now, when both software will be integrated to the ECU, there must not be any sort of incompatibility in terms of ISO 26262 guidelines.

    Ensuring this compatibility becomes a major challenge given the distributed nature of product development.

  3. Quantitative Assessment of Every Hardware component

    4. The hardware used in the electronic components needs to be tested for failure rates. Quantitative assessment of the hardware is needed for this purpose.

    Quantitative assessment refers to analysing the FIT (Failure in Time) rate. It is the number of failures that is expected to occur in 1 billion device hours of operation. Based on the FIT rate the hardware is given ASIL rating.

    With several of such hardware involved, analysing each one of them is a challenge. Moreover, the testing of the most parts is performed on ASICs or other such circuits in test environment and their readings cannot be fully relied upon.

  4. Increase in product development cost Due to ISO 26262 Implementation

    5. Following are the three reasons why ISO 26262 compliance adds overhead to the OEMs.

    Additional personnel that the OEM has to hire to manage the safety critical components in the vehicle. For every expert or consultant the OEM hires, the cost escalates.

    • Automotive OEMs also need to train the existing engineering man-power, to inculcate a “safety culture” in the development process. As ISO 26262 is a relatively new standard, many engineers are not well-versed with it and need some training to get a hands-on experience.
    • Additional tests and formal verification processes add to the time invested in the product development. The increased time-to-market and efforts manifest in the cost of the development.

    These overheads need to be in check despite taking all measures to ensure functional safety according to ISO 26262 guidelines.

  5. Increase in Time-to-market due to ISO 26262 Compliance

    6. The list of features that are being included in the automobiles is getting bigger with each passing day. In such scenario, the OEMs are under constant pressure to release the new features quite rapidly.

    Some of these features that are safety critical, need to be complaint with the ISO 26262 standards. This implies additional testing and assigning ASIL ratings etc. which add to the time-to-market. With intense competition among the OEMs, keeping the time-to-market as less as possible is imperative and comes across as a major challenge.

    The pain point here for the OEMs is that the customers do not see functional safety as a value-add. Most customers are willing to pay more for active safety features and fuel-saving systems but usually perceive functional safety as a required component of a vehicle.

Conclusion

New features like ESP (Electronic Stability Program), ABS (Anti-lock brake system), and several such advance driver assistance system are being introduced in the automobiles at a very rapid pace. As ISO 26262 is relatively new standard, the challenges are yet to be overcome completely. As the engineers and solution architects get more exposure to the ISO 26262 functional safety standard, we can expect these challenges to get easier to handle.

  • March 22, 2018
  • 0

Understanding the Automotive Functional Safety Best-Practices with ISO 26262 standard

Tags :

Category : Embedded Blog

The modern day vehicles have evolved from predominantly mechanical machine into an electronically-controlled system.

Today, a car consists of hundreds of automotive Electronic Control Units (ECU) and millions of lines of software code.

With passage of time and the lightening pace of technical advancement, the number of ECUs within automobiles is also increasing. This increase in complexity and functionalities of ECU-based car design is driven by a need for a comfortable driving experience along with safety and pollution control.

The automotive ECUs power many of the advanced function and features available in modern cars including advanced driver assistance(ADAS) , telematics, passive safety systems, engine management – to name a few.

Functional Safety in Automotive:

With the widespread of the modern automobiles, run and regulated by automotive ECUs, the need for advanced safety features has also become inevitable.

Functional Safety as a process has become an essential component of the ECU software development cycle. Functional safety schemes for automobiles helps in identifying malfunctions (electric and electronic), and specifies actions and techniques to be adopted to mitigate risks and damage during instances of software or hardware failures.

Inability or a delay in identifying or mitigating instances of ECU (hardware/software) failure can impact all the stakeholders throughout the value chain – including the ECU Supplier, Car manufacturers and the end user.

The consequences may involve loss of life or property, financial loss, legal liability, regulatory actions or even the loss of goodwill for all of those involved.

And this is why today modern vehicles are required to adhere to the safety standards listed within the Automotive Safety Integrity Level (ASIL). ASIL is a risk classification scheme specified within the ISO 26262 – a Functional Safety standard for Road Vehicles.


Functional Saftey Automotive
Image Credit: dcvizcayno.wordpress.com

Ensuring Functional Safety of Automotive Software with ISO 26262 standard

The ISO 26262 standard addresses the need for a unified and automotive-specific international Functional Safety Standard for electrical and electronic ECU and other embedded systems in a vehicle.

The ISO 26262 standard is an adaptation of IEC 61508 standard. It specifies recommendations to ensure the functional safety throughout the product development cycle- at the system, hardware, and software levels. The ASIL standard is a key component for the ISO 26262 compliance.

Most functions within an automotive ECU are implemented and controlled through automotive ECU software and the complexity of this software can reach more than 10 million lines of code.

Typically, these programmable ECUs contain highly modular embedded software. The software may include both safety-related and non-safety-related code and software components that perform functions with different ASIL ratings.

The ISO 26262 standard specifies two approaches to be followed if embedded software includes software components with varying ASIL ratings.

  1. Either develop the entire software according to the highest ASIL, or

  2. Take necessary actions to ensure that the software components with a with a lower ASIL rating are not interfering with software with higher ASIL rating


ISO 26262

Design and development of ISO 26262 compliant ECU Software

The need for developing safety-critical automotive components and the increasing demands for complex and innovative automobile applications are ongoing challenges for the automotive manufacturers and design engineers.

They have to play the balancing act of catering to increased application complexity while reducing the time-to-market with utmost care. And this while ensuring that no comprise is made on ensuring safety of the automotive application and software component.

The expertise then lies in designing the automotive ECU application by taking into account every aspect of safety failures that can occur during the product development cycle. These failures mostly fall under following groups:

  • Random/systematic hardware defects

  • Systematic software defects.

Identifying Sources of Errors during ECU Software development Lifecycle

The systematic software failures occur mostly due to human errors during different product development life cycle phases. These can mostly be traced back to a certain root cause and fixed.

Let us look at some instances of errors that usually occur during the software development cycle and which could have a lasting impact on the performance of the final automotive application:

  1. Requirement specification and communication– This phase results in one of the largest sources of errors. It occurs when:

    • Software executes “correctly” according to the understanding of the requirement, but the requirement eventually appears to be inaccurately defined within the scope of the system

    • The requirement was simply misunderstood by the automotive software developer

  2. Software Design and coding errors– Considered as the second most common source of errors, this type of error usually occurs due to :
    • A poorly structured embedded software code

    • Timing errors, incorrect queries, syntax errors, algorithm errors, error in displaying results errors, lack of self-tests, failed error-handling – to name a few

  3. Errors due to software changes – Such errors is said to have occurred when
    • Changes to the developed software may introduce unanticipated errors

    • Failure of the configuration control process

    These errors can usually be traced back to requirements and programming errors.

  4. Errors due to inadequate testing: During the testing phases, sometimes the software seems to have passed the testing criteria, but during the actual execution it may fail to perform the required task. Such a failure is termed as a testing failure. This happens if:
    • Software functions properly in unit testing

    • Software passes systems and integration testing, but ideally it shouldn’t have. This happens when safety-critical test coverage is inadequate

    Such errors can also be traced back to requirements and programming errors

  5. Errors in Timings: Software performs the right function, but at the wrong time or under inappropriate conditions.

    Such instances of errors during the application development can be reduced or eliminated by introducing failure-safe processes and by taking extra care at each of the phases including: requirement analysis, design, manufacturing process, documentation etc.
    Designing a robust and well –optimized software, keeping into account these instances of errors; can reduce systematic failures to a large extent.

Recommended Approach

The best practice for developing functionally safe automotive software can vary with the end- application and requirement it is being developed for.

The development and design of a software specific to ADAS may not be same as the one for Anti-Lock Brake System (ABS). The need of the hour then is to optimize the software and hardware design according to the specific domain and application.

The ISO 26262, a functional safety standard for automotive, specifies definite techniques and measures to address various types of failures and issues related to the automotive software development lifecycle.

It is also necessary to ensure that while designing the ECU software and ensuring compliance with the ISO 26262 standard, the components (hardware and software) are not seen just as individual systems but as a whole .The best approach is to have a holistic view of the ECU application so that all the applications work in perfect coordination.

Archives

Contact Us

© 2018 Embitel. All Rights Reserved