ISO 26262:2011 Functional Safety Assessment Report. Texas Instruments Richardson, TX USA. Project: TDA2X ADAS SoC. Customer:

Transcription

1 ISO 26262:2011 Functional Safety Report Project: TDA2X ADAS SoC Customer: Texas Instruments Richardson, TX USA Contract No.: Q13/ Report No.: TI R002 Version V1, Revision R1, January 23, 2014 Dave Butler The document was prepared using best effort. The authors make no warranty of any kind and shall not be liable in any event for incidental or consequential damages in connection with the application of the document. All rights reserved.

2 Management Summary The ISO 26262:2011 Functional Safety of the Texas Instruments TDA2X ADAS SoC, performed by exida consisted of the following activities: - exida assessed the procedures and processes employed by Texas Instruments to develop the TDA2X ADAS SoC product, through an audit and review of project documentation, to document the level of compliance with the relevant ASIL A requirements of the ISO 26262:2011 standard. This effort resulted in a detailed safety case, in accordance with the exida certification scheme. This activity was performed using subsets of the ISO 26262:2011 requirements, tailored to the work scope of the development team. Additionally, the requirements in IEC 61508:2010, Annex F, were used to assess the integrated circuit development process used on the project. - exida reviewed and assessed a detailed Failure Modes, Effects, and Diagnostic Analysis (FMEDA) tool, used by end users to document the hardware architecture and failure behavior. - exida reviewed the manufacturing quality system and production process in use at Texas Instruments. The functional safety assessment was performed to the requirements of the ISO 26262:2011 standard, to the ASIL A integrity level. A Safety Case was created and reviewed, using the exida Safety Case tool, which was used as the primary audit tool. Hardware chip development process requirements and all project documentation requirements were assessed. Validation and Verification test reports, including environmental test reports, were reviewed. Also, user documentation, including safety manual documentation, was reviewed. The results of the Functional Safety can be summarized by the following statements: The audited development process, as tailored and implemented by the Texas Instruments TDA2X ADAS SoC development project, complies with the relevant ASIL A safety management requirements of ISO 26262:2011. The assessment of the FMEDA, performed to the requirements of ISO 26262:2011, has shown that the TDA2X ADAS SoC product s SPFM, LFM and PMHF lie within the allowed range for ASIL A, according to tables 4, 5 and 6 of ISO 26262:2011, part 5. The assessment of the work products, resulting from development activities, has shown that the hardware developed for the TDA2X ADAS SoC has resulted from following the defined development process and complies with the relevant safety requirements according to ISO 26262:2011 ASIL A. This means that the TDA2X ADAS SoC product, with the hardware versions listed in section 3.1, is capable for use in ASIL A applications, when properly designed into an item per the requirements in the Safety Manual [D125]. T-034 V4R3 Page 2 of 24

3 The manufacturer will be entitled to use the following Functional Safety Logos. T-034 V4R3 Page 3 of 24

4 Table of Contents Management Summary Purpose and Scope Tools and Methods used for the assessment Project Management exida Roles of the parties involved Standards / Literature used Reference documents Documentation provided by Texas Instruments Documentation generated by exida Approach Product Description Hardware and Software Version Numbers ISO 26262:2011 Functional Safety Scheme Product Modifications Results of the ISO 26262:2011 Functional Safety Lifecycle Activities and Fault Avoidance Measures Overall Safety Management Safety management during the concept and product development phases Safety management after release for production Concept phase Product Development at the System Level Product Development at the Hardware Level Initiation of Product Development at the Hardware Level Specification of Hardware Safety Requirements Hardware Design Evaluation of the Hardware Architectural Metrics Evaluation of Safety Goal Violations Due to Random Hardware Failures Hardware Integration and Testing Product Development at the Software Level Production and Operation Page 4 of 24

5 5.6.1 Production Operation, Service (Maintenance and Repair), and Decommissioning Supporting Processes Specification and Management of Safety Requirements Configuration Management Change Management Verification Documentation Confidence in Use of the Software Tools Qualification of Software Components Qualification of Hardware Components Proven In Use Argument Automotive Safety Integrity Level (ASIL)-oriented and Safety-Oriented Analyses Decomposition with respect to ASIL tailoring Criteria for coexistence of elements Analysis of dependent failures Safety analysis Results of to IEC , Annex F Requirements Design Entry Requirements Synthesis Requirements Test Insertion and Test Generation Requirements Placement, Routing, Layout Generation Requirements Chip Manufacturing Requirements Terms and Definitions Status of the document Liability Releases Future Enhancements Release Signatures Page 5 of 24

6 1 Purpose and Scope This document describes the results of the ISO 26262:2011 standard functional safety assessment of the Texas Instruments: TDA2X ADAS SoC by exida, according to the accredited exida certification scheme, which includes the requirements of ISO 26262:2011 standard. The purpose of the assessment was to investigate the compliance of: - the TDA2X ADAS SoC with the technical ISO 26262:2011 requirements of parts 5 and 8 for ASIL A and - the TDA2X ADAS SoC development processes, procedures and techniques as implemented for the safety-related deliveries with the ISO 26262:2011 managerial and production requirements of parts 2, 5, 7, 8 and 9 for ASIL A and - the TDA2X ADAS SoC development processes, procedures and techniques as implemented for development of integrated circuits per IEC , Annex F for SIL 1 and - the TDA2X ADAS SoC hardware analysis represented by the Failure Mode, Effects and Diagnostic Analysis with the relevant requirements of ISO 26262:2011 requirements of parts 5 and 9 The assessment has been carried out based on exida quality procedures. The results of this assessment provide the safety instrumentation engineer with the required failure data as per ISO 26262:2011and confidence that sufficient attention has been given to systematic failures during the development process of the device. 1.1 Tools and Methods used for the assessment This assessment was carried out using the exida Safety Case tool. The Safety Case tool contains the exida scheme which includes all the relevant requirements of ISO 26262:2011. To properly fulfill assessment objectives, expectations are defined by the scheme to define acceptance levels for the assessment. The expectations are reviewed to verify that each and every relevant requirement is covered by the development processes and project documentation assessed. Because of this methodology, comparable assessments in multiple projects with different assessors are achieved. The arguments and evidence for the positive judgment of the assessor are documented in the tool s assessment data, and are summarized herein. The assessment was planned by exida and agreed with Texas Instruments (see [D007]). results were iteratively documented and retained by exida (see [R2]) Page 6 of 24

7 2 Project Management 2.1 exida is one of the world s leading accredited Certification Bodies and knowledge companies, specializing in automation system safety and availability, with over 300 years of cumulative experience in functional safety. Founded by several of the world s top reliability and safety experts from assessment organizations and manufacturers, exida is a global company with offices around the world. exida offers training, coaching, project-oriented system consulting services, safety lifecycle engineering tools, detailed product assurance, cyber-security and functional safety certification and a collection of on-line safety and reliability resources. exida maintains a comprehensive failure rate and failure mode database on process equipment based on 100 billion hours of field failure data. 2.2 Roles of the parties involved Texas Instruments exida exida Manufacturer of the TDA2X ADAS SoC Performed and/or reviewed the hardware safety analyses Performed the Functional Safety per the accredited exida scheme. Texas Instruments contracted exida with the ISO 26262:2011 Functional Safety of the above specified devices. 2.3 Standards / Literature used The services delivered by exida were performed based on the following standards / literature. [N1] ISO 26262:2011, parts 1-9 Road Vehicles Functional Safety 2.4 Reference documents Documentation provided by Texas Instruments Doc. ID Typical Name Version Date D001aa Quality Manual - Stafford's TUV Process Report 1.1 3/15/2013 D001ab Quality Manual - Stafford's TUV Process Certificate Expires: 3/7/2016 3/12/2013 D001b Quality Manual F 10/11/2013 D001c Overall Development Process - Wireless Product Development Rev. Q 11/19/2014 D001d Overall Development Process - System Product Development Rev. N 2/18/2014 D001da Overall Development Process - Production Part Approval Process Rev. A 8/29/2014 D001e Configuration Management Process F 10/11/2013 D001ea Configuration Management Process - tailoring of meta process Rev /14/2014 D001f Field Failure Reporting Procedure Rev. A 6/23/2013 D001g Field Return Procedure Rev. A 6/23/ Page 7 of 24

8 D001h Manufacturer Qualification Procedure Rev. AH 3/5/2013 D001j Quality Management System (QMS) Documentation Change Procedure Rev. D 3/1/2014 D001k Control of Design Records F 10/11/2013 D001l Non-Conformance Reporting procedure Rev. A 9/24/2013 D001m Corrective Action Procedure Rev. E 4/10/2014 D001n Action Item List Tracking Procedure Rev. N 2/18/2014 D001o Training Procedure Rev. C 10/23/2013 D001p Test Equipment Calibration Procedure Rev. K 1/3/2014 D001q Customer Notification Procedure Rev. Q 2/22/2014 D001s Software Tool Qualification Procedure Rev /16/2014 D001t ASIC Development Process Rev. N 2/18/2014 D001v Modification Procedure Rev. N 2/18/2014 D001w Modification Procedure - Product/Process Change Control Rev /14/2013 D001wa Modification Procedure - change request workflow Snapshot 9/18/2014 D001x Impact Analysis Template D002 Evidence of Competence Rev /14/2014 D003 Evidence of Quality Management Expires: 11/11/ /12/2012 D004 Safety Plan Rev /14/2014 D007 Functional Safety Plan 9/12/2013 D016 Functional Safety Concept Rev Draft 12/22/2014 D020 Integration and testing Plan Rev. A 8/29/2014 D020b Integration and testing Plan - environment Snapshot 9/18/2014 D020c Integration and testing Plan - environment PPAP2 Snapshot 12/16/2014 D020d Integration and testing Plan - environment PPAP 1 Snapshot 12/16/2014 D023 Technical Safety Requirements Specification Rev Draft 12/22/2014 D023b Technical Safety Requirements Specification snapshot 12/18/2014 D033 Integration testing specification(s) Rev. A 8/29/2014 D034 Integration testing report(s) Snapshot 8/6/2014 D036 Validation Report Rev Draft 12/22/2014 D040 Hardware Safety Requirements Specification Rev Draft 12/22/2014 D040b Hardware Safety Requirements Specification - version control Snapshot D040c Hardware Safety Requirements Specification - Chapter /15/2013 D041 Hardware-Software Interface Specification Rev. Q 6/1/2014 D041b Hardware-Software Interface Specification - Chapter /15/2013 D042 Hardware Safety Requirements Verification Report Rev Draft 12/22/2014 D042b Hardware Safety Requirements Verification Report - Production Test Coverage Snapshot 9/29/ Page 8 of 24

9 D043 Hardware Design Specification Rev /15/2013 D043b Hardware Design Specification - DFT 1 Rev /31/2012 D043c Hardware Design Specification - DFT 2 Rev /31/2012 D043d Hardware Design Specification - DFT 3 Rev /31/2012 D044 Hardware Safety Analysis Report V1R1 8/29/2014 D045 Hardware Design Verification Report Snapshot 12/8/2014 D045b Hardware Design Verification Report Snapshot 12/8/2014 D052 Hardware integration and testing report Rev Draft 12/22/2014 D055b D055c D055d Design and Coding Guidelines for modelling and programming languages Design and Coding Guidelines for modelling and programming languages - clock_reset constraints Design and Coding Guidelines for modelling and programming languages - LINT Snapshot 9/18/2014 Snapshot 10/10/2014 Snapshot 10/10/2014 D064 Safety Analysis Report V1R1 8/29/2014 D080 D081 D082 D083 D084 D087 D087b Safety-related content of the production plan Safety-related content of the production control plan Control measures report Specification of requirements on the producibility at system, hardware or software development level report for capability of the production process Safety-related Content of the information made available to the user Safety-related Content of the information made available to the user Expires: 11/11/2015 Expires: 11/11/2015 Expires: 11/11/2015 Expires: 11/11/2015 Expires: 11/11/ /12/ /12/ /12/ /12/ /12/2012 Rev. Q 6/1/2014 Rev /1/2014 D088 Instructions regarding field observations Rev /1/2014 D097 Configuration Management Plan Rev /14/2014 D097b Configuration Management Plan - from procedure F 10/11/2013 D098 Change Management Plan Informal 1/6/2014 D098b Change Management Plan - approval example Snapshot 8/5/2014 D098c Change Management Plan - Snapshot 8/6/2014 D099 Change Request - upper half Snapshot 9/1/2014 D099b Change Request - lower half Snapshot 9/1/2014 D099c Change Request - CM labels identified Snapshot 9/18/2014 D099d Change Request - CR references Config ID 9/29/2014 D100 Impact Analysis and Change Request Plan informal 1/6/2014 D101 Change Report Snapshot 9/1/ Page 9 of 24

10 D102 Verification Plan Rev /14/2014 D102b Verification Plan - RAMP Dashboard Snapshot 8/5/2014 D102c Verification Plan - Design Rule Check Results Snapshot 10/10/2014 D102d Verification Plan - synthesis checklist Snapshot 8/6/2014 D102e Verification Plan - Module Simulation Test Plan Snapshot 8/6/2014 D102f Verification Plan - Roles Snapshot 8/6/2014 D102g Verification Plan - Module Simulation Test Results Snapshot 8/6/2014 D103 Verification Specification Snapshot 8/6/2014 D103b Verification Specification - test cases 1 of 3 Snapshot 10/10/2014 D103c Verification Specification - test cases 2 of 3 Snapshot 10/10/2014 D103d Verification Specification - test cases 3 of 3 Snapshot 10/10/2014 D104 Verification Report Snapshot 8/6/2014 D104b Verification Report - Gate Netlist Simulation Results Snapshot 8/6/2014 D105 Documentation Management Plan Rev /14/2014 D106 Documentation Guideline Requirements Rev. D 3/1/2014 D107 Software Tool Criteria Evaluation Report 0.1 9/29/2014 D108 Software Tool Qualification Report 0.1 9/29/2014 D122 Safety Analyses V1R1 8/29/2014 D125 Safety Manual Rev /1/2014 D125b Safety Manual - Tech. Ref. Manual Rev. Q 6/1/2014 D125c Safety Manual - Data Manual 8/1/2014 D127 ISO 900x Certificate - Foundry Expires: 6/2/2016 6/3/2013 D128 RTL - Example logic Snapshot 9/18/2014 D128b RTL - Example interface Snapshot 10/10/ Documentation generated by [R1] [R2] [R3] TI Q R002 V1R0 ISO Report VH-28.docx TI V1R6 Safety Case WB TI R001 V1R1 FMEDA VH28 Report (this file) SafetyCaseWB files FMEDA Tool Review Report 2.5 Approach The assessment was carried out in accordance with the requirements of the exida scheme, which requires assessment to all relevant requirements from the ISO 26262:2011 standard. Page 10 of 24

11 The assessment was planned by exida and agreed with Texas Instruments. The following ISO 26262:2011 objectives were subject to detailed auditing at Texas Instruments: FSM planning, including o Safety Life Cycle definition o Scope of the FSM activities o Documentation and quality management o Activities and Responsibilities (Training and competence) o Configuration management o Tools and languages Hardware Safety Requirements Specification Change and modification management Hardware architecture design process, techniques and documentation Hardware design / Safety Analysis Integration Test Planning and execution Work product and phase verification activities Hardware-related operation requirements The project team, not individuals, was audited. The on-site certification audit was done in Richardson, TX in July Page 11 of 24

12 3 Product Description The purpose of the VisionSurround28 Super/High/Mid device (VH-28) is to function as a digital signal processor (DSP) in embedded automotive applications in the driver assistance space. Some of these applications may be safety critical. Multiple safety applications were analyzed during the concept and design phase for this product in order to support Safety Element out of Context (SEooC) development such as described in ISO :2011. Product documentation and tools are delivered to customers to enable item (system) level safety analysis: These include a safety manual, safety analysis reports and a FMEDA tool. The VisionSurround28 Super/High/Mid device is intended to be usable in automotive Advanced Driver Assistance Systems. Specific targeted application segments include, but are not limited to: Front Camera Lane Departure Warning Traffic Sign Recognition High Beam Assist Collision Mitigation Backup Camera Obstacle Detection Park Assist Surround View Systems Radar Ethernet Surround View LVDS Surround View Long Range Radar Short Range Radar As this device is for a general market rather than custom or bespoke product, it cannot be said that a specific implementation configuration can be assumed. As long as the requirements specified in the Safety Manual [D125] are followed, the DSP can also be used in safety critical applications beyond the ones mentioned above. Page 12 of 24

13 3.1 Hardware and Software Version Numbers This assessment is applicable to the following version(s) of TDA2X ADAS SoC: Product Model Versions TDA2xxAxxxxxxQ1 A = product revision x = covered options 4 ISO 26262:2011 Functional Safety Scheme exida assessed the development process used by Texas Instruments for this product development, against the objectives of the exida certification scheme. The results of the assessment are documented in [R2] and summarized in [R1]. exida created a safety case, referencing project procedures and documentation, to show that the project complies with the functional safety management requirements of the ISO 26262:2011 standard. This was done by a pre-review of the completeness of the related requirements and then a spot inspection of certain requirements. The safety case documents the evidence and arguments that show that all of the functional safety management requirements of ISO 26262:2011 standard have been adequately met. The detailed development audit investigated the compliance with the ISO 26262:2011 standard of the processes, procedures and techniques as implemented for the Texas Instruments TDA2X ADAS SoC. The assessment was performed in accordance with the exida certification scheme which includes subsets of the ISO 26262:2011 requirements, tailored to the work scope of the development team. The result of the assessment shows that the TDA2X ADAS SoC is capable for use in ASIL A applications, when properly designed into a safety-related element per the requirements in the safety related instructions in the product documentation. 4.1 Product Modifications The modification process has not yet been fully assessed and audited, so modifications are not currently covered by this assessment. Only the models and version(s) of the product documented in section 3.1 are certified by this assessment. 5 Results of the ISO 26262:2011 Functional Safety exida assessed the development process used by Texas Instruments during the product development against the objectives of the exida certification scheme, which includes ISO 26262:2011, parts 2-9. The results of this assessment are contained in [R2] and summarized in [R1]. The development of the TDA2X ADAS SoC was done per this ISO 26262:2011 ASIL A compliant development process. The Safety Case was updated with project-specific design documents. Page 13 of 24

14 5.1 Lifecycle Activities and Fault Avoidance Measures Texas Instruments has an ISO 26262:2011 compliant development process, as assessed during the ISO 26262:2011 certification. This compliant development process is documented in [D001aa] through [D001x]. This functional safety assessment investigated the compliance with ISO 26262:2011 of the processes, procedures and techniques as implemented for the product development. The audited development process complies with the relevant managerial requirements of ISO 26262:2011 ASIL A. Page 14 of 24

15 5.1.1 Overall Safety Management Objective Some of the objectives of the ISO 26262:2011, part 2 standard are to define the requirements for the organizations that are responsible for the safety lifecycle, or that perform safety activities in the safety lifecycle, mainly with respect to: - Safety Culture - Competence Management - Quality Management - Tailoring of the Lifecycle (covering part 2 chapter 5) The related requirements of ISO 26262:2011-2, were tailored to the scope of SEooC development in accordance to the guidance of ISO 26262: The procedures defining the lifecycle, followed during development, are identified in the Functional Safety Management Plan. This plan, together with the process documents identified, specifies how functional safety is to be achieved during the SEooC development. - The supporting processes related to change management and configuration management are detailed in a Configuration Management Plan. - The procedures documented to handle Corrective Actions, Engineering Change Management and Customer Notification of safety related issues cover the handling of anomalies. - Team competence is documented in a Team Competence Plan in the Functional Safety Plan, and documents expected and achieved competencies for personnel assigned to the project. - The functional safety management system is based on a valid ISO 9001:2008 certification Safety management during the concept and product development phases - To ensure that the safety management roles and responsibilities, regarding the development phases in the safety lifecycle are defined. - To ensure that the requirements for the safety management during the concept phase and the development phases are met, including those relating to the planning and coordination of the safety activities, the progression of the safety lifecycle, the creation of the safety case, and the execution of the confirmation measures. - To ensure that the distinction between a new item development and a modification to an existing item is clear. - To ensure that the associated responsibilities within distributed developments for items and elements are allocated. The related requirements of ISO 26262:2011-2, -4, -5 and -8 were tailored to the scope of a SEooC development in accordance to the guidance of ISO 26262: The requirements from part 3 and 6 are not applicable to the development of the TDA2X ADAS SoC. Page 15 of 24

16 - The Functional Safety Management Plan lists the roles and responsibilities for all relevant activities. The Personnel Management Plan shows the allocation of the activities to persons including the Functional Safety Management responsibility (Safety Manager). - The Project Manager (PM) is responsible for the schedule, the resource plan, the execution and process compliance. The roles of PM and Safety Manager are described in Job Title Descriptions, which are referenced from the Functional Safety Management Plan. - The activities needed to show compliance to the ISO 26262:2011 standard are identified in the Functional Safety Management Plan. - The confirmation reviews are planned in the Confirmation Measure Plan and documented in the Confirmation Measures Reports Safety management after release for production Objective The objective of the ISO 26262:2011 standard is to define the responsibilities of the organizations and persons responsible for functional safety after the item's release for production. (covering part 2 chapter 7) The related requirements of ISO 26262: were tailored to the scope of a SEooC development in accordance to the guidance of ISO 26262: Any field observations after end of development and release for production will be handled via the documentation management system in order to maintain functional safety for the product. The field monitoring process is defined by the following documents: - Corrective Action and Preventive Action Procedure - Customer Return Material and Rework Procedure - Nonconforming Material Control - Containment Procedure - Errata notification is accomplished through customer subscription to a web-based notification system 5.2 Concept phase ISO 26262: is not applicable for the SEooC development of the TDA2X ADAS SoC. 5.3 Product Development at the System Level ISO 26262: is not applicable for the SEooC development of the TDA2X ADAS SoC as these are requirements concerning the system level of development. 5.4 Product Development at the Hardware Level The audited development process complies with the relevant hardware development requirements of ISO 26262:2011 ASIL A. See subsequent sections for more detail. Page 16 of 24

17 5.4.1 Initiation of Product Development at the Hardware Level Objective The objective of these requirements is to ensure that functional safety activities during the individual subphases of hardware development are determined and planned. The project Safety Plan references procedures for achieving functional safety, including projectindependent tailoring of safety activities with respect to ISO 26262:2011. Any requirements not applicable to this development project have also been tailored out in the Safety Plan [D004] and the Safety Case [R2]. Validation and verification planning is done through automated project management software that contains the plan as well as results for various configuration builds of the design. The software also provides for confirmation of certain project artifacts per Table 1 of ISO 26262: Safety Analysis is planned and carried out through the use of a FMEDA tool which has been assessed by exida. A Tool Qualification Report, containing a list of the software tools used on the project, along with confidence in use data has is referenced from the Safety Plan Specification of Hardware Safety Requirements One objective of these requirements is to specify the hardware safety requirements, which are derived from the technical safety concept and system design specification. A second objective is to verify that the hardware safety requirements are consistent with the technical safety concept and the system design specification. The hardware-software interface is to be specified per these requirements. A hardware safety requirements specification has been created, which contains hardware safety requirements that are based on assumptions of use and are allocated to hardware. The hardware safety requirements specification includes: requirements for safety mechanisms to control internal failures of the hardware requirements for detection and annunciation of internal/external failures requirements on the interface between hardware and software other hardware safety requirements Hardware Design The first objective is to ensure that the hardware is designed in accordance with the specified system design specification and the hardware safety requirements. The second objective is to ensure that the hardware design is verified against the system design specification and hardware safety requirements. As the product is approached as an SEooC, System design specifications, per se, do not exist. The Hardware Architectural Design and the Hardware Detailed Design have both been documented adequately. An FMEDA Tool, to be provided to end users of the product for calculation of failure rates, has been assessed as appropriate and correct. The verification of the Hardware Design has been planned, and includes consideration of environmental conditions Page 17 of 24

18 (temperature, vibration, etc.), specific operational environment (e.g., supply voltage) and component specific requirements for verification by qualification and/or testing. Verification also includes review by developers. The ATPG and functional tests, that are run on every unit during production to further verify and validate the hardware design, are run prior to release to production to verify the design Evaluation of the Hardware Architectural Metrics Objective Ensure that the hardware architecture of the item is evaluated against the requirements for fault handling as represented by the hardware architectural metrics. These requirements do not apply to an SEooC assessment as they can only be applied at the item level Evaluation of Safety Goal Violations Due to Random Hardware Failures Objective To make available criteria that can be used in a rationale that the residual risk of a safety goal violation, due to random hardware failures of the item, is sufficiently low. These requirements do not apply to an SEooC assessment as they can only be applied at the item level Hardware Integration and Testing Objective Ensure, by testing, the compliance of the developed hardware with the hardware safety requirements. The verification of the Hardware Design has been planned and includes tests for environmental conditions (temperature, vibration, etc.), specific operational environment (supply voltage, mission profile, etc.) and component specific requirements for verification by qualification and/or testing. Tests were generated based on requirements as well as experience of test authors (error guessing). Requirements are traced to tests. All Test Cases (SoC DV Dashboard tests) have been successfully run as specified in the Test Plan. The Test Results have been documented. There were several test cases that were marked as failed. These test cases fell into two categories: Intentionally excluded from test execution due to passing in a previous iteration and a category where the test was designed to indicate fail when it passes (negative tests). 5.5 Product Development at the Software Level There is no software that is part of this product. The ISO 26262: requirements are, therefore, not applicable. Page 18 of 24

19 5.6 Production and Operation The audited development process complies with the relevant production and operation requirements of ISO 26262:2011 ASIL A Production Objective Ensure that a production process for safety-related elements or items, that are intended to be installed in road vehicles, is developed and maintained. Achieve functional safety during the production process by the relevant manufacturer or the person or organization responsible for the process (vehicle manufacturer, supplier, sub-supplier, etc.). The production process, at all foundries, has been ISO 9001 certified. The ATPG and functional tests, that are run on every unit during production to further verify and validate the hardware design, are run prior to release to production to verify correct operation of the device as produced. In general, the production process and its control measures are implemented and carried out as per the safety related content of the production and control plans. Process failures occurring during production are captured, analyzed, resolved and verified. The production processes, means of production and tools and test equipment used in production have been assessed with regard to functional safety. All test equipment is subject to control of monitoring and measuring devices Operation, Service (Maintenance and Repair), and Decommissioning Ensure that the customer information, maintenance and repair instructions, as well as disassembly instructions regarding the item, system or element, in order to maintain the functional safety over the lifecycle of the vehicle is specified. These requirements do not apply to an integrated circuit, assessed as an SEooC. 5.7 Supporting Processes The audited development process complies with the relevant supporting process requirements of ISO 26262:2011 ASIL A Specification and Management of Safety Requirements Ensure the correct specification of safety requirements with respect to their attributes and characteristics. Ensure consistent management of safety requirements throughout the entire safety lifecycle. Safety requirements for the device have been adequately specified and are managed appropriately. Page 19 of 24

20 5.7.2 Configuration Management Ensure proper analysis and change control of safety-related work products throughout the safety lifecycle. A configuration management planning section is documented in the Functional Safety Management Plan. This section identifies the configuration items, and where to find them in the configuration management tool. Versions are assigned to every configuration item and it is clear how configuration items make up larger configuration items, and ultimately the overall product design, including all product documentation Change Management Ensure the proper analysis and change control with respect to safety-related work products throughout the safety lifecycle. A Modification Procedure exists that identifies how a modification request is initiated and processed, in order to authorize a Product Modification Request. A Product Modification Request System exists to support this process. The Modification Procedure identifies all work products which are subject to change management. Because the impact analysis procedures and supporting documentation are not adequately supported as of this assessment, the certificate issued is only for a specific version of the product. Changes to the certified version of the product are not covered by the certification until the procedures and supporting documentation have been updated and assessed to be compliant with ISO 26262: Verification Ensure that the work products comply with their requirements. Reviews, testing and analysis are carried out according to development procedures to ensure that work products comply with their requirements. Verification records are required and tracked online, using various software tools Documentation Ensure that a documentation management strategy for the entire safety lifecycle is in place to facilitate an effective and repeatable documentation management process. All documentation is kept online, using various software tools. Documentation is versioned and associated, by version, with a particular configuration of the project artifacts. Documentation requirements are planned, tracked and approved via the online tools, and all information is accessible to project personnel. Page 20 of 24

21 5.7.6 Confidence in Use of the Software Tools Ensure that criteria have been met for the required level of confidence in use of all software tools used in development of the product. Ensure that qualification of the software tools not meeting confidence in use levels has been carried out, and meets the criteria required. Software tools used in development have all been identified and confidence in use data has been provided for each tool. Tools have been adequately described and shown to be appropriate for their use. A software tool upgrade policy is in place and requires new versions of tools to have documentation that shows either adequate confidence in use data, or adequate qualification results Qualification of Software Components Ensure that all re-used software components have been qualified and evidence of their suitability shows compliance with the requirements of ISO 26262:2011. No software components have been reused to develop this product Qualification of Hardware Components Ensure that all re-used hardware components have been qualified and evidence of their suitability shows compliance with the requirements of ISO 26262:2011. No hardware components have been reused to develop this product. Re-use of IP for chip design is covered through compliance with the IEC , Annex F requirements for ASIC and User Programmable IC chip design and development (see section 6) Proven In Use Argument No proven in use credit is claimed for this assessment. 5.8 Automotive Safety Integrity Level (ASIL)-oriented and Safety-Oriented Analyses Decomposition with respect to ASIL tailoring No decomposition with respect to ASIL tailoring is claimed for this product Criteria for coexistence of elements All components of the design have the same ASIL, which is the ASIL of the overall product, so these requirements are not applicable. Page 21 of 24

22 5.8.3 Analysis of dependent failures No Dependent Failure Analysis is required as the components of the product design all claim the same ASIL, which is the ASIL of the overall product Safety analysis Ensure that a safety analysis has been carried out to identify consequences of faults and failures on the functions, behavior and design of items and elements, as well as to provide information on conditions and causes that could lead to the violation of safety requirements. An FMEDA tool is provided to users of the product. The FMEDA tool provides a means to set up the parameters of a FMEDA, then to calculate the failure rates of the product based on the specified context. Specification of which diagnostics the application implements are among the parameters used to calculate failure rates. There are many other parameters that can be specified in these calculations to produce failure rates specific to the use of the chip. The FMEDA tool has been evaluated by exida and to the extent discoverable by black box testing appears to deliver accurate results according to exida s assessment of the tool (See [R3]). 6 Results of to IEC , Annex F Requirements As ISO 26262:2011 does not have requirements on the development procedures of integrated circuits, exida requires that the development processes used to develop certified IC s at least meet the requirements of IEC , Annex F, in order to show that techniques and measures are in place to avoid systematic failures. The audited development process complies with the relevant chip development requirements of IEC , Annex F. 6.1 Design Entry Requirements Many of the techniques for the design entry phase have been used in the development of the product, including: Structured description, design description in HDL (RTL), Schematic entry, HDL simulation with documented results, application of proven in use simulators, functional test on the module level, functional test on the top level, restricted use of asynchronous constructs, design for testability, RTL coding guidelines and validation of soft-cores. 6.2 Synthesis Requirements Many of the techniques for the Synthesis phase have been used in the development of the product, including: Application of proven in use synthesis tools and target libraries. 6.3 Test Insertion and Test Generation Requirements Many of the techniques for the test generation phase have been used in the development of the product, including: Implementation of Test Structures, estimated test coverage by application of ATPG. Page 22 of 24

23 6.4 Placement, Routing, Layout Generation Requirements Many of the techniques for the Placement/Routing/Layout phase have been used in the development of the product, including: Simulation of gate netlist, to check timing constraints, Verification of the gate netlist against a reference model by simulation, Design rule check and layout versus schematic (LVS) verification. 6.5 Chip Manufacturing Requirements Chips are manufactured in an ISO 9001 certified environment. Additionally, required techniques used in manufacturing chips are used, including: Application of a proven in use process technology, proven in use manufacturing process, Quality control of the manufacturing process, Functional quality pass of the manufactured device, ATPG and functional testing of each instance of the product. 7 Terms and Definitions ASIL FMEDA Automotive Safety Integrity Level Failure Mode Effect and Diagnostic Analysis SEooC Safety Element out of Context Section 9 of ISO 26262: , section 9, identifies they type of engineered component as a safety-related element which is not developed for a specific item. This means it is not developed in the context of a particular vehicle. SIF Safety Instrumented Function Page 23 of 24

24 8 Status of the document 8.1 Liability exida prepares reports based on methods advocated in International standards. Failure rates are obtained from a collection of industrial databases. exida accepts no liability whatsoever for the use of these numbers or for the correctness of the standards on which the general calculation methods are based. 8.2 Releases Version History: V1, R1; Changed product name per TI request; DEB 1/23/2015 Authors: V1, R0; Initial version; DEB 1/23/2015 Dave Butler Review: Mike Medoff; 1/21/2015 Release status: Released 8.3 Future Enhancements At request of client. 8.4 Release Signatures David Butler, CFSE, Safety Engineer Michel Medoff, CFSE, CISA, Senior Safety Engineer Page 24 of 24