Technical safety concept

1 The first objective of this subphase is to specify the technical safety requirements. The technical safety requirements specification refines the fimctional safety concept, considering both the functional concept and the preliminary architectural assumptions (see ISO 26262-3). 

2 The second objective is to verify through analysis that the technical safety requirements comply with the functiorml safety requirements 

1 Within the overall development lifecycle, the technical safety requirements are the technical requirements necessary to implement the functional safety concept, with the intention being to detail the item-level functional safety requirements into the system-level technical scfety requirements. 

NOTE Regarding the avoidance of latent faults, requirements elicitation can be performed after a first iteration of the system design subphase. 

The basic requirement says that the system design should be drived from the functional safety concept, whereby the architecture should still play a central role. In effect, this causes the various functions of the functional safety concept and then-requirements to be again allocated to common elements. This is often the case for microcontroller. 

---

At this point three aspects of plant technical safety concepts shall be explained here, which have been selected because of their Sequent application in the chemical process industry ... 

Keywords Technical Safety Concept, Technical Safety Requirements, Safety Verification, Safety arguing, Automotive, ISO 26262, AUTOSAR. 

AUTOSAR, Technical Safety Concept Status Report, vol. Document Version 1.2.0, no. Part of Release 4.1 Rev 1 (October 2013)... 

Another safety-related metric is the fraction of functional safety concepts that are matched by a technical safety concept. This can be computed based on derivation relations between functional and technical safety requirements combined with realization relations between analysis functions and design functions making up the architectural aspects of the functional and technical safety concepts, respectively. 

The value for VS QUALIFICATION.TIME is derived in later phases of the Functional Safety Project (e.g. during creation of the Technical Safety Concept). 

The technical safety concept contains more than 100 requirements that shall be realized in software. In the following, we apply our proposed approach for one concrete technical safety requirement ... 

Please note that the technical safety concept is associated with the product development. Next to the 3 parts of product development of systems, EE-hardware and software, and the chapters about production development and plant engineering (part 7) are described. Those are activities that are considered besides the development V-cycles. Furthermore, some activities are mentioned that are not directly addressed by the norm but often necessary for the product development. 

Which general targets could be formulated for a safety concept. ISO 26262 clearly defined that the functional and technical safety concept should be defined derived from the ITEM Definition, a system on vehicle level and the resulting safety goals from the Hazard and Risk Analysis. 

In the next phase the requirements and the associated architectures and results will be passed on to the technical safety concept. In the first iterations there won t be any complete verification for sure. Therefore, the outstanding issues of the verification will also have to be passed on so that it is clear in the technical safety concept, which information are actually positively verifiable and which aren t. It is another process iteration. 

NOTE The software architectural design is not necessarily limited to one microcontroller or ECU, and is related to the technical safety concept and system design. The software architecture for each microcontroller is also addressed by this chapter. 

At least during the verification of the technical safety concept the result of the inductive and deductive analysis need to be merged. Which technical failures propagate further upwards to the safety goals in what way, how likely, and with which intensity, is then shown in the overall safety assessment, when all verification, integration and validation results are available. 

NOTE Hardware elements whose faults are multiple-point faults with a higher order than two can be omitted from the calculations unless they can be shown to be relevant in the technical safety concept. 

Chapter 7, part 4 addresses the system design, the technical safety concept and their verification, which should be derived from the functional and technical safety requirements. Therefore, in requirement 7.4.3.1 the inductive (for all ASILs) and deductive (for the higher ASILs) safety analysis is required. In this context of product development on system level it is primarily a matter of the analysis of systematic failure. In one indication (note 1) it says that a quantitative analysis can support the results. 

Fig. 4.68 Information flow in the system and EE hardware development derived from technical safety concept (TSC)...

NOTE Anomalies and incompleteness identified between the system design, regarding the technical safety concept, will be reported in accordance with ISO 26262-2 —, Clause 5.4.2 (Safety culture)... 

Thus it is also in the second interpretation, the request itself is really what is required, according to ISO 26262 in deriving the functional safety concept for technical safety concept through to the component requirements. Here ISO 26262 calls the activity also verification of requirements. 

---