|
Evidence of implemented processes for FuSy activities of the entire safety life cycle (presponsibilities, WP elaboration, product life cycle, ) is needed. All (relevant) parts of the ISO 26262 standard need to be described as processes. Often thoseprocesses are documented in a process landscape and ideally contain templates and check lists for documentation of work products. Evidence of competence of personell involved in development, production, service and decommissioning is needed. The printed circuit board designer should give evidence of competence for his task (e.g. being an electrical engineer). Personnel working with devices conducting voltage needs to be trained for this purpose. Work products of ISO 26262-7 shall pay attention to hazards resulting from service, repair and decommissioning to enable and require competence of personnel for these tasks, either. Evidence of an implemented and certified quality managment system (e.g. IATF 16949 or ISO 9001) is needed. This is the baseline for any higher quality requirements, e.g. safety requirements. It shall be ensured that the QMS certificate addresses the company devision and plant which the safety related development and/ or production is performed at. If further quality and competence certificates are available, they should be documented, too. Special attention shall be paid to processes for detection and reporting safety anomalies. They shall be handled according to a specified process (see ISO 26262-2 5.4.3.2). A process for design and document reviews to detect anomalies as well as for spreading them to responsible persons shall be defined and be known by any person involved in the safety lifecycle. At start of development of a safety related item it shall be distinguished between new development, modification of existing item or modification of environment (technical and climatical) of an unmodified item. If something existing was modified, modification shall be analysed (e.g. regarding specified boundary conditions) as well as its impact on functional safety. Resulting safety activities to achieve FuSy with modification shall be identified and performed. This means conduction of relevant process steps of ISO 26262. In case of reuse of existing elements within a safety related item, impactanalysis at element level shall be performed as mentioned above. The safety plan shall define planning of activities and procedures for achieving FuSy. It mainly inherits the core steps and documents of FuSy and shall contain the planning of the overall safety management, development activities, development interface agreement, supporting processes, safety analyses and some more. It may contain references to further documents with relevant contents to avoid redundancy of information documentation. See also ISO 26262-2 6.4.6.5. The safety case is a document containing an argumentation chain for a safety-related product, why it should be considered as achieving a suitable functional safety and not containing unreasonable risks. Such an argumentation chain might include arguments for the absence of unreasonable risks due to a suitable HARA being performed with defined safety goals where functional and technical safety concept base on as well as the HW and SW requirements. All together should imply that every inherent risk potential was analysed and faced by the requirements and resulting measures. To confirm FuSi of item and its elements, key work products shall be reviewed, FuSi process audit shall be conducted etc. (see ISO 26262-2 6.4.9.1). These confirmation measures shall be documented in reports containing a judgement of goals being reached or not. See also ISO 26262-8 9 Verifications. For the RfPR, all confirmation reviews shall be finalised and available as well as further safety related documents of the safety case. The RfPR itself shall contain the confirmation of completeness of required documents, name and signature of release-responsible person, release version and configuration as well as release date. The RfPR later may be used as baseline for change requests. It shall be evidenced that the safety lifecycle phases production, operation, service and decommissioning are managed regarding safety issues. This contains definition of responsible persons equiped with authority to maintain FuSy, planning, initiation and execution of activities for those phases as well as process definition and execution regarding FuSy. After changes to released configuration documented in RfPR, a new release is necessary. This document ideally exists before development of the item. It shall describe the item with its base functionality, dependencies on and interaction with the environment (driver, other items at vehicle level, surrounding). Drawings of the item and ist interfaces as well as a list of main components of it help to understand and define the scope. The intended use case of the item shall be described as well as operation conditions, a functional concept describing purpose and functionality as well as operational modes and states, constraints, expected behaviour and consequences in case of failures. The item definition shall be only as precise as necessary but at the same time precise enough to ground the HARA and FSC on it. Pay enough attention to analysis of requirements by relevant legacy and standards. Such an analysis shall be periodically updated and contain Name, date, scope (geographical and technical) and content of the requirement sources. Based on Item Definition, hazards resulting from (mal-)functions of the item shall be identified and safety goals shall be derived. For HARA it is assumed that the item inherits no safety mechanisms, even if existing. Potential impacts at the level of vehicle are in scope. First, potential hazards caused by item shall be identified (by brainstorming or by experience). Afterwards, the hazards need to be analysed systematically for several operational states and modes and be rated (severity at occurrence, possibility of control of hazard or to evade it, probability of exposure (regarding frequency or duration)). ASIL rankings can be derived from ratings above. Safety Goals shall be derived from hazards, if applicable, by summarising some hazards. A safety goal wording shall describe which hazard is to be avoided at the level of vehicle. The HARA shall be varified against its requirements, according to ISO 26262-3 6.4.6.1. It shall be documented, if the analysed situations fit with the expected use case of the item, if the item definition is completely considered and all ASIL rankings of safety goals and safety goals themselves are consistent with the hazards. Functional safety requirements shall be derived from safety goals and get allocated to components of HW and/ or SW of the item. All safety requirements together are called FS concept and shall cope with the hazards and safety goals identified in HARA. The functional safety concept shall be verified to give evidence of ist ability to mitigate or avoid the hazards identified during HARA and to check consistency and compliance with safety goals. Technical safety requirements shall be specified compliant with the functional safety concept and the system architectural design. They describe the technical realisation of the functional safety requirements under consideration of the itemīs architecture. They shalll be traceable regarding their origin in a functional safety requirement, e.g. by a comprehensible and systematic identification number. Technical safety requirements shall be allocated to HW- and SW-components of the item and be ASIL rated according to their origin in a functional safety requirement. Basing on preliminary assumptions and item definition, the system architecture shall be specified. It shall consider measures for control of random HW failures during operation as well as results of analyses for avoidance of systematic failures. The system adaptation according to topics above and technical safety requirements is called technical safety concept. Basing on preliminary assumptions and item definition, the system architecture shall be specified. It shall consider measures for control of random HW failures during operation as well as results of analyses for avoidance of systematic failures. Furthermore, all other functional and technical safety requirements shall be realised. The interface between HW and SW shall be speciefied by considering all HW components controlled by SW and those which support SW execution. The HSI implicitly defines the interaction between development of HW and SW. If some requirements to those SLC phases are identified during system architectural design, they shall be specified as addressed in ISO 26262-7. For combrehensibility and clarity reasons it may be suitable to document all requirements touching ISO 26262-7 in a single document. The technical safety concept shall be verified to provide evidence of ist correctness, completeness and consistency regarding boundary conditions of the system. All aspects described for the WP Technical safety concept shall be considered for verification. Standardised methods are given in ISO 26262-4 6.4.9. Identified safety anomalies or incompletenesses shall be reported as defined according to ISO 26262-2 5.4.3 (to responsible persons to get reworked). The SAR shall provide results of analyses and shall state pass or fail of the analysed object. Boundary conditions, reference documents, safety object (e.g. safety goals) and scope of analysis shall be documented. Corresponding analyses (FMEA, FMEDA, FTA, others) need to be performed first. It may improve comprehensibility to document analyses results in single reports for each analysis. The compliance of the system architectural design with the functional and technical safety concepts shall be evaluated. ISO 26262-4 7.4.1.1 states four test objectives to be checked. Corresponding test methods are listed for each level of integration. The test strategy may be documented in a schedule to stay comprehensible. Furthermore, it shall contain test sequences to be followed. Results from tests (see above) shall be documented. If applicable, deviations from planned testing shall be documente, too. One statement for each test case regarding pass or fail as well as a total pass or fail statement shall be documented in the report. the different integration levels need to be considered for documentation, either. To provide evidence the item satisfys all requirements (safety goals) in a competely integrated state (System including HW, SW, external measures, integrated into target vehicle), it shall be validated. Validation is to specify in a manner enabling the evidence of functional safety achievement at the level of vehicle. Verification checks each single aspect against its requirement, validation checks entire item integrated in target environmnet regarding appropriateness of its realisation (including measures etc.) to achieve functional safety goals. Thus, even configuration and calibration data shall be considered. The validation specification contains description of test procedures, test cases, drving manoeuvres, acceptance criteria, needed equipment and environmental conditions. Execution and results of evauluation shall be documented. The evaluation shall be evaluated to state whether it is passed or failed. The technical safety concept derives measures for achievement from requirements of the functional safety concept. To precise the TSC, safey requirements for HW parts are derived. That includes monitors for relevant HW parts. Target values as HW metrics or FTTI shall be documented, too. Resulting from the detailed HW requirements, the HSI needs to be refined, either. Aim is to enable correct control and usage of the HW by SW. Especially the safety-related content shall be considered in a sufficiently detailed way. The HW safety concept shall be verified jointly by responsible persons for HW and SW. Special attention shall be paid on correct interaction of HW and SW. Compliance with the general technical safety concept shall be considered, either. HW design is structured into detailed design and architectural design. Architectural design means HW componentes and their interaction with one another. Detailed design means the level of parts forming a component. HW architectural design shall implement FS requirements and thus being specified for that. Specification of detailed HW design shall consider part properties and mission profile to avoid safety goal violation due to non-functional failures. Safety analyses of HW shall identify failure causes and effects of faults. In case of implemented measures for avoidance of single-point faults or to reduce residual faults, their effectiveness shall be proven. Analysis results shall be documented as well as the analysis procedure itself. As for other work products it shall be ensured that normative requirements to the work product are fulfilled. In this case it addresses coping with HW safety requirements, compatibility with HSI specification and suitability of safety-related special characteristics to achieve functional safety during production and operation. The verification enables improvement of safety requirement implementations, if necessary, and thus it is a functional safety-related quality assurance practice. Anything improving functional safety during production, operation, service and decommissioning shall be documented. If safety analyses (FMEA, FMEDA, FTA, HARA, ) output characteristics being important for achievement of functional safety, these shall be highlighted. Additional, verification measures including pass-fail-criteria shall be specified for verification of fulfilment of special characteristics. Even assembly or service instructions can cope with this requirement shall be communicated to responsible persons. Documentation of this information may be gathered with those of ISO 26262 part 7 for enhanced clarity. Random hardware faults can result in faults or failures of safety-relatd functions. Thus, diagnostic mechanisms shall be implemented considering latent and residual faults. Diagnostic mechanisms shall enable the HW architecture to cope with the required metrics, usually at the item level. For each HW component FIT-rate, failure modes and relevance of each fault regarding all safety goals are to be defined. A safety analysis report (SAR) is needed. The SAR and the previous analysis shall be verified regarding their correctness and completeness. Thus, a suitable understanding of the technical situation is needed. Futhermore, ISO 26262-8 clause 9 shall be applied. The residual risk of safety goal violation after consideration of diagnostic measures shall be sufficiently low which is to evidence. The Evaluation of the Probabilistic Metric of random Hardware Failure PMHF can be used as well as the Evaluation of Each Cause of safety goal violation. Both methods aim to identify the statistical quantity of faults being able to violate a safety goal although diagnostic measures are applied. If some ASIL specific requirement is not satisfied, it does not necessarily mean a fail regarding functional safety. Those exceptions can be accepted under conditions listed in ISO 26262-5 9.4.1.2 and 9.4.1.3. In such a case, evidence shall be provided that all alternative requirements are satisfied. A rationale for the need of applicating this method shall be given. A verification according to ISO 26262-8 clause 9 shall be performed to evidence the technical correctness and completeness of the analysis performed (WP 9.5.1). The applicated analysis method shall be considered. Several development levels of hardware shall get integrated and tested step by step, considering ISO26262-8 9 (also regarding independency of verifying). In particular, requirements of ISO26262-5 10.4.1 to 10.4.6 shall be considered. They present testing procedures for several testing purposes. Adapted to the respective hardware, integration and testing procedures shall be specified. The hardware verification shall get documented. This includes results, statements regarding the level of compliance of verification results with expected results and a judgement of pass or fail. The hardware verification shall get documented. This includes results, statements regarding the level of compliance of verification results with expected results and a judgement of pass or fail. The safety requirements documented in the functional safety concept need to be specified for their application to software. Their specification shall especially consider the aspects listed in ISO 26262-6 6.4.2. Resulting from the detailed SW requirements, the HSI needs to be refined, either. Aim is to enable correct control and usage of the HW by SW. Especially the safety-related content shall be considered in a sufficiently detailed way. The SW safety concept shall be verified jointly by responsible persons for HW and SW. Special attention shall be paid on correct interaction of HW and SW. Compliance with the general technical safety concept shall be considered, either. The SW architecture displays the SW elements and their interactions in a hirarchical structure. Aspects listed in ISO 26262-6 7.4 shall be considered to avoid systematic faults caused by SW. Furthermore, the SW architectural design shall enable implementation of safety and non-safety requirements as well as each kind of analysis and verification. Performed analyses according to ISO 26262-6 7.4.10 shall be documented in a report containing evidence of correct and capable implementation of safety-related functions, safety-related SW parts and safety measure effectiveness. In case of needed freedom of interference for correct implementation of SW functionalities, dependent failures and their effects shall be analysed according to ISO 26262-9 7. The results shall be documented in a corresponding report. The SW architecture shall be verified according to ISO 26262-8 9 to provide evidence of aspects listed in ISO 26262-6 7.4.14. The implemented architecture gets compared with and judged regarding its requirements. The SW unit design results from requirements derived from the SW architectural design. Thus, SW units need to get specified to satisfy the needs addressed to them, especially safety-related requirements. Aspects listed in ISO 26262-6 8.4 shall be considered. At the level of source code, the implementation of properties listed in ISO 26262-6 8.4.5 shall be ensured by application of methods listed in Table 6. Besides SW architecture, also implementation of SW units shall comply to their requirements (see ISO 26262-6 9.1 and 9.4). In general, for verifications ISO 26262-8 9 shall be complied with. The refined SW verification report shall contain also results and judgements regarding SW unit verification. Comparable to HW integration and verification (ISO 26262-5 10), SW shall be integrated and verified stepwise. Attention shall be paid to the interfaces between SW elements, to verify the correct interaction between SW elements and the functionality of the entire embedded SW. The test environment needs to satisfy ISO 26262-6 10.4.7. The SW integration shall be specified in sequences considering aspects listed in ISO 26262-6 10.4.1 to build the entire embedded SW while verifying it stepwise. The SW verification report gets amended once more by documenting results and judgements of corresponding verification activities. The SW shall be tested completely integrated and executed in target environment to verify the complete fulfilment of safety requirements as well as absence of undesired functionalities or properties regarding functional safety. Ideally, testing and implementation are performed by different persons. The SW verification report gets amended once more by documenting results and judgements of corresponding verification activities. To ensure correct usage and applicability of configurable SW, configuration data shall be specified (e.g. data type, content). To ensure correct usage and applicability of calibrateable SW, calibration data shall be specified. The configuration data shall comply with specifications met according to ISO 26262-6 C.5.1. The calibration data shall comply with specifications met according to ISO 26262-6 C.5.2. The data for configuration and calibration shall get verified to ensure they comply with their specifications. Also generation and application of calibration data shall be verified according to ISO 26262-6 C.4.11. These verifications need to be specified and thus refine the earlier versions of SW verification specifications. The SW verification report gets amended once more by documenting results and judgements of corresponding verification activities. The SW architectural design maybe was changed due to enable configuration and calibration. Thus, it needs to be refined regarding those changes. Changes to the SW architecture shall be documented. It is to check whether furhter work products needto be reworked afterwards. Comparable to ISO 26262-6 5.5.1, the SW development environment of configuration and calibration data as well as the one used for adaptation of SW to enable configuration and calibration needs to be documented to enable reproducability. The production plan which is already required by other standars shall contain safety-related aspects, resulting from the safety requirements. This shall enable the assembly staff not to endanger the functional safety by proper handling of components and the required care in their installation. For example, sensitive sensors, their handling and mounting (e.g. heat transfer). Furthermore it shall be ensured that the correct version of software gets flashed (if applicable). A process FMEA is inevitable prior to production plan creation. The production control plan shall contain additional measures for assurance of achievement of the functional safety. Corresponding sequences of control steps, test equipment and test criteria shall be documented. Safety requirements identified during production planning shall be documented and communicated to the responsible persons. This aims to ensure producibility. Already during pre-series production it can by analysed, if the currently planned series production is suitable for ist aim. A corresponding report shall than be documented. If service intervals are needed to keep functional safety working, these shall be planned including affected components and be justified. Required service actions shall get defined regarding their work steps, tools and test criteria. Information needed by users to be aware of safety-related functionalities, components, their effects in case of correct and incorrect performance and their maintenance shall be documented in a user manual as well as related warnings. If measures are needed to avoid harm to persons at disassembly, they shall be documented (e.g. voltage deactivation of a traction battery before removal and disassembly. Safety requirements identified during the planning of operation, service and decommissioning shall be documented and communicated to the responsible persons. If needed, rescue instructions shall be documented for avoidance of harm to passengers as well as to rescue services by safety-related components. This work product requires something like stepfs 5 and 6 of P-FMEA with functional safety in focus. The production control plan shall be performed as well to analyse the control mechanism's capability. This requirement is satisfied by production process audits and tool monitoring according to IATF 16949. Field monitoring of safety-related components shall be implemented and used for identification of safety issues. Corresponding analyses shall be performed and responsible persons be informed regarding analyses results. The selection of a supplier shall be based on the evaluation of the supplierīs capability to develop (and produce) comparable complex elements. Thus, a request for quotation shall contain aspects listed in ISO 26262-8 5.4.2.2. The selection shall be justified considering all those aspects. The DIA shall contain an allocation of all necessary FS work products to either the supplier or the customer. That addresses especially main parts as the HARA, FS assessment and validation, personell appointment, specification of audit procedures, communication channels, topics and frequency. Furthermore, technical interfaces need to be specified. The suppliers safety plan is a document providing an overview of the main tasks and summarising aspects listed in ISO 26262-8 5.4.3 and 5.4.4 as well as ISO 26262-2 6.4.6.5. It is not necessarily a different document from ISO 26262-2 6.5.3. According to ISO 26262-8 5.4.5.3, a FS assessment shall be performed on the supplierīs side and be reported to customer. It aims to evidence compliance of the item and implemented processes with the customers safety requirements as well as functional safety requirements in general (ISO 26262 series of standards). The supply agreement shall contain confirmation of required production process capability of supplier and allocation of responsibilities of both parties regarding FS activities (see also DIA). Furthermore, production monitoring and communication of reports regarding monitoring (production/ field) and (safety) anomalies shall be specified. The configuration management plan shall contain mandatory directives to enable configuration management. Thus, general conditions of creation (development, production) of elements/ items/ work products shall be documented for the reason of reproducability and traceability of changes between versions. Furthermore, each work product, item and element required by the safety plan shall be listed to be placed under configuration management. The change management plan shall represent a directive for handling changes, beginning with the request and ending with the report. It shall contain each work product which is subject to change management (all WPs required by safety plan). The change request shall contain a unique identifier, a date, a detailed description of the change, a justification and the baseline which the request bases on. It shall be comprehensible, why which product developement state shall get changed in which way. This is a significant part of the decision base for the later acception or rejection of the change request. After the input of the change request, it shall be identified the type of CR (error resolution, adaptation, elimination, enhancement, prevention, ...), affected work products with responsible persons and parties affected and potential impact on functional safety. A timeline for implementation and verification shall be created. Authorised persons shall decide, if the request is accepted or rejected. The changes shall be performed and verified as planned. If needed, all affected confirmation measures and the FS assessment shall be repeated. The change report contains a list of all changed work products and components, a detailled change documentation and a date for planned release of the change. Verification aims to ensure a work productīs compliance with its requirements. Thus, the verification shall be planned considering the verificationīs object and content, suitable methods and tools, pass/ fail criteria as well as a regression strategy. This document shall be able to guide its user through the verification and to offer all information needed for verification. The verification specification is a subset of the verification plan and contains details of the chosen verification method.In case of testing, many detail suggestions are provided by the standard. Here should be specified in such detail that a simple execution of a list remains. The verification shall be performed as planned, but by a different person than the one(s) who created the verified work product. The execution and its results shall be documented, containing a statement regarding the degree of compliance and the pass or fail of the work product. A detailed documentation helps the work productīs creator(s) to rework it and enables later comprehension of the document and the verifyerīs decision. Documentation management aims to establish a guidline for information documentation, storage and availability. Each information related with a work product shall be documented. The documentation management plan shall enable availability of all necessary inormation during the entire safety lifecycle. Documented information shall comply to the standardīs requirements regarding form and content: comprehensible content, clear structured, verificable, maintainable, equipped with title, author, approver, document-ID, version history and state. Software tools used for support of development activities shall be examined regarding their trustworthiness, if not each result is double-checked and the functional safety relies on its results. In case of probable impact on the functional safety by not detecting faults or by causing faults of a safety-related component, the tool needs to get evaluated and qualified for its intended use cases. Such a tool criteria evaluation report shall contain a confirmation of compliance of the toolīs operational environment and constraints to its qualification sheet. If none is available, the report shall contain the planning of the intended tool usage and the evaluation of the toolīs impact possibilities as well as the tool error detection probability, both resulting in a tool confidence level classification. Dependent on the tool confidence level, different tool qualification methods might be applied. The performance and results shall be documented as well as a summarising statement, how any constraints for their use are to be considered. If existing software components shall be reused in a new item, the need to get qualified. Such a qualification bases on a suitable SW component documentation containing e.g. the component ID, maximum target ASIL, requirements of the component to its environment and the other way around. The qualification report evidences the requirement compliance, contains the verification result and further aspects as to be read in the standard. It is used to evidence the proper use of the SW component. To be safe, this anaysis gets entirely verified regarding its formal correctness. The verification report contains the verification result with degree of compliance and a statement regarding pass or fail. If existing hardware elements shall be reused in a new item, the need to get evaluated. This is to be planned, considering e.g. the component ID, maximum target ASIL, requirements of the component to its environment and the other way around, pass/fail criteria and some more aspects. If existing hardware element shall get evaluated by testing, a testplan shall be created. Its content is a description of functions to be tested, allocated safety requirements, pass/fail criteria and many more to be read in the standard. The test plan should enable a simple execution of a list. Independent to the evaluation method, the evaluation shall get documented in a report containing the classification, the corresponding evaluation execution and results and the statement regarding the pass/ fail of the element. The classification and methods for evaluation are to be read in the standard. Another kind of compliance evidence is the proven in use argument which provides an argumentation for achievement of functional safety of an element, basing on positive experiences and field data. The element needs to be described regarding ist environmental constraints, dimensions, functionality and further aspects which are required to be complied with for applicability in a reuse. A modification of the reused element or ist operational environment is probable. Thus, the modification shall get identified, analysed and evaluated considering the standardīs requirements. The target values for functional safety incidents to be reached for a convincing proven in use argument are presented by the standard, too. If a component developed according to ISO 26262 gets applied in context of T&B, but for an application out of the standardīs scope, it shall be ensured that the operational constraints of the component for ist functionally safe operation are considered. Thus, a manual for the applier is needed. If in context of T&B a component not developed according to ISO 26262 gets integrated into a safety-related system developed according to ISO 26262, it shall be evidenced that the component does not affect the functionally safe operation of the system. The work product ISO 26262-4 6.5.3 needs to be adapted to decomposition. The resulting system architecture as well as changed allcoation of requirements to components shall be documented. Further aspects to be considered can be read in ISO 26262-9 clause 5.4. Note 1: This standard describes decomposition of requirements to enable partitioning of the system architecture, if necessary. Actually, often system architecture shall be decomposed and for this reason requirements get adapted afterwards. Both ways are possible. Note 2: It is allowed to realise safety requirements with technologies other than E/E. Partial realisation by other technologies is possible even in context of decomposition. Note 3: Decomposition enables realisation of requirements without components having the original ASIL. This work product just aims to ensure the update of all requirements affected by the performed decomposition. Thus, all affected requirements shall get updated regarding their ASIL classification (e.g. ASIL B(D)) and regarding their wording, if the functionality was adapted. Exist safety and non-safety parts within the same element (or parts with different ASILs), they all shall have the highest allocated ASIL of the element until sufficient independence and freedom from interferrence are evidenced. The ASIL attribut is to be adapted correspondingly. To identify dependencies of failures, a dependent failure analysis shall be performed. The goal is to evidence a sufficient independence of elements and the freedom of interferrence as well as to identify measures for mitigate plausible dependent failures, if necessary. A common method is the fault tree analysis. To ensure formal correctness of the dependent failure analysis and its data base, it shall get verified. The verification report contains the verification result with degree of compliance and a statement regarding pass or fail. To ensure a sufficiently low risk of systematic faults or random hardwarwe faults, safety analyses shall be performed with different methods, corresponding to affected ASIL and the analysis` aim. Well-known standards for their performance shall be considered, newly identified hazards and their consequences shall be communicated to responsible persons to be mitigated. Affected work products and phases of the safety life cycle need to get reworked or iterated. To be sure, analyses shall get verified regarding their formal correctness. The verification report contains the verification result with degree of compliance and a statement regarding pass or fail. |