Consulting Services V-Top

The key document in any IEC 61508 / ISO 26262 development project is the Safety Plan, as recommended in the Management section of both these standards. It specifies how FuSa will be ensured throughout the development project and in production. The Safety Plan must identify the various roles and responsibilities as they apply to the development process.

The Safety plan lists the various techniques and measures that will be implemented as part of the development project, to ensure that the targeted SIL/ASIL is achieved. The initially delivered Safety Plan must be subsequently refined during  the entire development process.

As in the case of the Safety Plan, the Cybersecurity Plan is a key document, that specifies how the identified risks for the security (see also TARA) will be handled throughout the development phase of a project.

This Plan must identify the various roles and responsibilities as they apply to the development process, and includes all the actions to take listed in the TARA report, that shall be implemented as part of the development project, following a priority-based scheduling.

As it happens for all the plans, the initially delivered Cybersecurity Plan must be subsequently refined during the development phase.

In order to achieve a predefined Quality level for a service/product, the project management is a crucial point and the plan that specifies how and when and by whom the necessary operative actions will be implemented is, of course, the main reference.

As it happens for all the plans, the initially delivered Quality Plan must be subsequently refined during all the following phases, from development, thought the production to the end of the service/product useful lifetime.

The Safety Manual, according to IEC 61508 recommendations, is necessary to make safety-relevant information available to the designer of a FuSa-related system. It is the key communication mechanism between the product vendor and the product users. This document must list any product/application restrictions or limits, specific installation and maintenance requirements, failure characteristics in case of a product, and many other items. It shall be refined or confirmed by validation testing.

For any product, the standard compliant Test Plan will be created starting from the Safety Requirements Specification (SRS). In an IEC 61508 / ISO 26262 compliant development process, the Test Plan should be created as soon as a freeze version of SRS is available and updated in case of any further SRS update during the development process.

The Test Plan specifies how a product will be tested once the design (in case of Simulation Testing) or the development (in a traditional context) is complete. Being directly based on the SRS, it “ignores” any specific design or development features; this will ensure that the final product meets the requirements that were set forth at the beginning of the development of the product.

This kind of services are specifically provided by exida Development

For our Customers we can implement the Safety Integrity Functions (the ones provided by AUTOSAR are already available in our SLib and they only need to be adapted) and the Safety Mechanisms which are recommended by the Safety Manual of a microprocessor selected by the Customer.

In the Automotive context, the new implemented or customized SW modules (usually written in C and/or Assembly language) are released ASIL-D compliant (full-tested and MISRA checked) and inclusive of all the necessary documentation (as provided by AUTOASAR):

• Module Detailed Specification (Requirements and Design)
• Static Code Analysis Report
• Test Cases and Unit Test Execution Report (note: Integration Tests are not included)

We can also instrument the source code developed by the Customer and perform the product specific or Integration Testing, on the basis of a Test Plan - provided by the Customer or defined by exida - in order to achieve the target Safety Integrity Level (SIL).

Note: the purpose of the specific Test Cases included in an Integration Test Plan is to ensure all claimed safety functions, independence measures, and HW and SW diagnostics are tested. To perform a formal integration and module testing is a requirement for IEC 61508 / ISO 26262 compliance. As an input into the creation of the Integration Test Plan, it is useful the outcome of the SW Hazard Analysis.

The Safety Requirements Specification lays out the foundation upon which a product should be designed and shall contain all the relevant safety requirements. Usually, it can be derived from the analysis of the generic Functional Specification document. It is advisable to clearly separate the safety requirements from the functional /generic requirements that also address non-safety functions, hence this eases the final audit process.

In case no functional / generic specification document exists, the Safety Requirements Specification can be created by interviewing the engineers who are involved in the project and are aware of the functional specification requirements of the product. Note that the SRS will need to be updated with each revision of the requirements.

The Safety Case is a report that collects all the documents of the project related evidence so to demonstrate that the standard requirements have been implemented and tested or audited during product development and all the outstanding action items have been closed: for this reason the Safety Case may evolve during the entire project life cycle.

The Safety Concept describes the safety related HW and high-level SW architecture. It decomposes the design of the safety functions and specifies the associated safety integrity functions such as self-tests, and safety support functions like operating and communication systems, and justifies the partitioning.

The Safety Concept is based on the review of the existing design documents, in order to extract the HW and high-level SW structure and any functional safety solution that will be composed into a UML model, that meets all standard requirements for such a semi-formal model. In case no design documents exist, is possible to collect the specific structure and the safety solutions through analysis sessions held with Project Engineers.

This deliverable is the basis of the detailed design and verification. Note that the Safety Concept will need to be updated with each revision of the SRS. For the Automotive domain, special services are offered to create a Safety Concept adopting AUTOSAR Software Architecture.