×

Happy to Help!

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

Great, thanks!

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

  • 0

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

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.

  3. Non-uniformity of Functional Safety Activities Among the OEMs, Suppliers And After-Market Companies
  4. 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.

  5. Quantitative Assessment of Every Hardware component
  6. 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.

  7. Increase in product development cost Due to ISO 26262 Implementation
  8. 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.

  9. Increase in Time-to-market due to ISO 26262 Compliance
  10. 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.


  • 0

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

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.