Consideration of requirement of decomposition for a safety related system NEC IEC61508 ISO 26262 We considered the concept of system decomposition paying attention to the decomposition concept of the system which includes software in individual application standard ISO 26262 of functional safety standard IEC61508 In order to divide a safety related system and to deliver the requirements for safety into each subsystems/components, such independency is made into requirements, but under the present circumstances, it is insufficient in view of bilaterally supervising. This research considers the attribute of decomposition and is examining the attribute. As a result, the conclusion that the independency and the diagnostic coverage of the divided subsystem/component were important for system decomposition was reached. And it proposes making independency and the diagnostic coverage into a matrix, and considering it as the attribute of system decomposition. 1. B IEC61508 C ( B.1) ISO SC3/TC22/WG16 2005 2007 (ISO WD26262) ( ) 1
2. IEC61508 ISO WD26262 4 IEC6150 SIL( Safety Integrity Level ) ISO WD2626 ASIL( Automotive Safety Integrity Level ) SIL/ASIL (tolerable risk) (Residual Risk) ISO WD26262 Decomposition ASIL D ASIL C ASIL A ASIL D C+A ASIL B ASIL A C B+A ASIL A ASIL A ISO26262 1 Decomposition ISO WD26262 Decomposition IEC61508 ISO26262 1. 2. 3. 4. 5. 6. A IEC61508/ISO26262 7. B 2
1. Decomposition ISO WD26262 (Diagnostic coverage) ( ) ( ) ( IC ) ( ) ( ) ( ) CCF( Common cause failure) CCF ( ) 2 (Safety State) Safety State (Latent failure) ABS/VSA IEC61508 6 FT 3 3
CCF 3 S f d CCF CCF f d CCF S f d CCF CCF ( ) CCF (i) ( ) S CCF f d 3 FT FT 4 S fud fd dud 4 FT fd dud fud S fd dud fud 4
2. CPU OS API IO 5 OS 5 IO Safety Concept (Safety state) IO 5
OS API OS FT 6 S h O OS f d 6 FT h OS o f d S S = f + O + f * d A ASIL OS ASIL-D 10-8 h o 10-7 h * d 10-7 ASIL C Decomposition 3. Decomposition WD26262-5 6
Decomposition ASIL CCF ASIL ASIL 1 1 None Low Medium High None ( < 60%) ASIL A ASIL B Low (>=60%) ASIL A ASIL B ASIL C Medium (>=90%) ASIL A ASIL B ASIL C ASIL D High (>=99%) ASIL B ASIL C ASIL D ASIL D ASIL D Medium High High Medium 4. ASIL Decomposition 1 Decomposition 5. ISO WD26262 07 CD(Committee Draft) ASIL Decomposition 2006 10 MISRA Decomposition 6 ISO TC22/SC3/WG16 7
IEC61508 ( JIS C 0508) ISO WD26262-3 Concept (Working draft) 1 ISO WD26262-4 System (Working draft) 1 ISO WD26262-5 Hardware (Working draft) 1 ISO WD26262-6 Software (Working draft) 1 1 ISO WD26262 2006 12 MISRA Safety Analysis Guidelines (MISRA SA)Draft Ver.13J 2 2 MISRA SA Ver.13J 2006 6 8
A IEC61508 SIL Safety Integrity Level) SIL SIL 4 SIL IEC61508 5 IEC61508 SIL ASIL (Automotive Safety Integrity Level) ASIL SIL (A~D) SIL ASIL SIL1~3 A.1 ASIL 2007 IEC61508 WD26262 (tolerable risk) A.1 (Residual Risk) (ASIL) (ASIL) Lower than tolerable A.1. 9
ASIL SIL ( ) A 1 B 2 or 3 C 3 or 2 D 3 A.1 ASIL 1. ( ) (Random mode failure) ( ) (Systematic failure) 2. Hazard ( ) (Usability) ( ) (Hazard) IO (Systematic failure) 1. ( ) ( ) ( ) Hazard ( ) 2. ( ) ( ) ( ) ( ) OS ( ) ( ) 3. ( ) ( ) SIL/ASIL 10
IEC61508 A.2 1 2 3 4 5 9 10 11 6 7 8 E/E/PES E/E/PES 12 13 14 16 15 A.2 IEC61508 IEC61508 ISO WD26262 SIL/ASIL A.3,A.4 A.2 IEC61508 Safety integrity level High demand or continuous mode of operation (Probability of a dangerous failure per hour) 4 10-9 to < 10-8 3 10-8 to < 10-7 2 10-7 to < 10-6 1 10-6 to < 10-5 NOTE See notes 3 to 9 below for details on interpreting this table. 11
A.4 ISO WD26262 ASIL Level Random HW failure target values D < 10-8 /h C < 10-7 /h B No requirement( 10-6 ) A No requirement 10-5 12
B 2 IEC61508 IEC61508 Part1 Annex A Table A.1 Software safety requirements specification ) Table A.1 Software safety requirements specification (see 7.2) Technique/Measure Ref SIL1 SIL2 SIL3 SIL4 1 Computer-aided specification tools B.2.4 R R HR HR 2a Semi-formal methods Table B.7 R R HR HR 2b Formal methods including for example, CCS, C.2.4 CSP, HOL, LOTOS, OBJ, temporal logic, --- R R HR VDM and Z a) The software safety requirements specification will always require a description of the problem in natural language and any necessary mathematical notation that reflects the application. b) The table reflects additional requirements for specifying the software safety requirements clearly and precisely. c) Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent techniques/measures are indicated by a letter following the number. Only one of the alternate or equivalent techniques/measures has to be satisfied. 13
Table A.4 Software design and development: detailed design (see 7.4.5 and 7.4.6) (This includes software system design, software module design and coding) Technique/Measure Ref SIL1 SIL2 SIL3 SIL4 1a Structured methods including for example, C.2.1 JSD, MASCOT, SADT and Yourdon HR HR HR HR 1b Semi-formal methods Table B.7 R HR HR HR 1c Formal methods including for example, CCS, C.2.4 --- R R HR CSP, HOL, LOTOS, OBJ, temporal logic, VDM and Z 2 Computer-aided design tools B.3.5 R R HR HR 3 Defensive programming C.2.5 --- R HR HR 4 Modular approach Table B.9 HR HR HR HR 5 Design and coding standards Table B.1 R HR HR HR 6 Structured programming C.2.7 HR HR HR HR 7 Use of trusted/verified software modules and components (if available) C.2.10 C.4.5 R HR HR HR Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent techniques/measures are indicated by a letter following the number. Only one of the alternate or equivalent techniques/measures has to be satisfied. 14