Application of the ISO26262 Functional Safety standard for MCAL development

 

Introduction

    In my previous blogs we have talked about AUTOSAR and MCAL and briefly about how to develop a plug-in for Elektrobit's EBTresos. In this blog we will talk about how to apply the ISO26262 FuSa(Functional Safety) standard when developing a MCAL. 
 
    The ISO26262 standard, which is based on IEC61508, is a risk-based safety standard where the risk of hazardous operational situations is qualitatively assessed and safety measures are defined to avoid or control systematic failures and to detect or control random hardware failures, or mitigate their effects.

    Goals of ISO 26262:

  • Provides an automotive safety lifecycle (management, development, production, operation, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases.
  • Covers functional safety aspects of the entire development process (including such activities as requirements specification, design, implementation, integration, verification, validation, and configuration).
  • Provides an automotive-specific risk-based approach for determining risk classes (Automotive Safety Integrity Levels, ASILs).
  • Uses ASILs for specifying the items' necessary safety requirements for achieving an acceptable residual risk.
  • Provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety is being achieved
    With all being said, let's dive into how this standard is actually applied to the development of an MCAL.

Development of the MCAL

    The ISO26262 safety lifecycle starts off with the item definition process. During the item definition process, the item which is a particular automotive system product is identified and it's top-level system functionality requirements are defined.

    Since the MCAL is part of a bigger system, there are certain intricacies attached to it as the system in which it can be deployed can vary depending on the particular automotive system in which the MCAL will be used. Hence not all the safety relevant conditions will not be known beforehand when developing the MCAL. Basically not everything is known before hand. As such the standard ISO26262 development process cannot be applied when developing such a safety component.

    The SEooC(Safety Element out of Context) development process isolates the item as a part of a whole system which is safety relevant. SEooC's are safety relevant and they are intended for reuse across various applications where the validity of their assumptions can be established during integration. SEooCs are developed based on assumptions, including the area of application, intended function, technical architecture, and functional and technical safety requirements. SEooCs are designed and developed following safety best practices outlined in standards like ISO 26262, and they are intended for reuse across various applications where the validity of their assumptions can be established during integration.

 Development lifecycle and activities

     Any ISO26262 safety relevant product development begins with the creation of a DIA(Development Interface Agreement). This document identifies the relationship between the customer and the supplier. It can define a RASIC chart identifying who will be responsible for the different work products required as per the ISO26262 standard. For the development of a MCAL as a SEooC, a DIA and a HARA is not mandatory, but it is a good practice to create this document and identify the safety work products to be delivered along with the MCAL source code. A change management plan can also be identified and added to the DIA. 

    A software safety requirement specification(SRS-S) can be created identifying all the safety relevant pitfalls which can occur in the MCAL being developed. These requirements will be inputs during the design of the MCAL. Once these requirements have been identified other functional requirements for the MCAL can be identified and the process of the MCAL development can start. The functional and safety relevant requirements are the basis for the design and implementation of the MCAL. 

    Once the MCAL has been developed and tested, a safety manual must be created which is used during the integration of the developed MCAL in the complete system along with other components of the system. 

    The work products in short have been listed below.

  • DIA

  • HARA

  • SRS-S

  • Configuration manual(not safety relevant but a deliverable nonetheless)

  • Safety manual 

     There are a few other work products which depend on the ASIL level of the MCAL being developed.These will be covered in a separate blog focusing on the ISO26262 development process in detail.

 Conclusion

    The blog has covered in short the application of the ISO26262 standard when developing a MCAL. The different work products to be delivered along with the source code of the MCAL have also been identified and briefly explained. 

    Sophon Technologies has the expertise to develop MCALs for any SoC, micro-controllers used in the automotive industry. Sophon Technologies has already successfully developed drivers for Mcu, Port, Dio, Spi, Can, Can-FD, Lin, Ethernet, Pwm, Gpt, Adc modules up to ASIL-D.

        If you have any requirements do get in touch with us through our website www.sophontech.in.


 

 

 

 

Comments

Post a Comment

Popular posts from this blog

What's AUTOSAR and MCAL?

Image
  What is AUTOSAR and MCAL?   Introduction        AUTOSAR ( AUT omotive O pen S ystem AR chitecture) which is a global development partnership, was started in 2003. It is a open architecture which enables OEMs to reduce the development time for ECUs by the use of configuration over code development. The objectives are scalability to different vehicle and platform variants, transferability of software, consideration of availability and safety requirements, cooperation between different partners, sustainable use of natural resources and maintainability during the product lifecycle .The philosophy of AUTOSAR is to collaborate on the development of the standard and compete on the implementation.           AUTOSAR follows a layered approach to software development with the complete software split into multiple layers such as Application layer(SW-Cs), Runtime environment (RTE) and the Basic software (BSW).     ...
Read more

MCAL development using Elektrobit's EBTresos MCG

  Introduction           In my previous blog I have talked about what the open architecture AUTOSAR is and how it helps OEMs in rapidly developing and deploying their solutions. I have also covered the role of MCAL as the layer closest to the HW and which interacts with the HW directly. We have also understood that any module in the BSW consists of a static code and a generated configuration. The configuration is generated using a MCG(Module Configuration Generator) tool. In this blog we look at how we can use 2 of the most commonly used MCG tools viz. Elektrobit's EBTresos and Vector Informatik's DaVinci Configurator Pro to develop the MCAL. Development of the MCAL as a EBTresos plugin Identifying the configuration parameters           The process of developing a MCAL for any tool begins with identifying the different containers and the configuration parameters which are under the specific containers. The process of ide...
Read more