ThemeGallery PowerTemplate

Size: px

Start display at page:

Download "ThemeGallery PowerTemplate"

경민 경
6 years ago
Views:

1 ISO 적용 컴퓨터공학과 MBC Lab 박철우 L/O/G/O

2 Project [ 상황 ] 일반적인상황에서는긴급메시지전송하지않음 전후방챠량의급가속또는급정지정보를제공을통한위험감지를통하여사고예방. [ 차량간긴급메세지전송 ] 차량간긴급메세지전송을통한위험요소분석 전후방챠량의급가속또는급정지정보를제공을통한위험감지를통하여사고예방.

3 Project 브레이크 ABS ECU 전송메세지컨트롤러 No 속도변화 > 20Km/s Yes 긴급메세지전송 ABS 속도센서 브레이크압력센서 [ 상황 ] 일반적인상황에서는긴급메시지전송하지않음 속도가 20Km/s 의변화가있을시긴급메시지전송 전송방식은브로드캐스트 브레이크암력센서활성화시 ABS 속도센서에서속도측정 주행속도 : ABS 속도센서 ABS ECU (CAN) 속도계로정보전달되어 표시합니다. [ 차량간긴급메세지전송 ] 차량간긴급메세지전송을통한위험요소분석 전후방챠량의급가속또는급정지정보를제공을통한위험감지를통하여사고예방.

4 ISO ISO 는기능안정성표준 EE 시스템들의오작동문제로인해발생하는위험도에의한불합리한리스크에따른다고정의 자세한설명은제공하지않으나결국, EE 시스템의원인으로인한위협으로누군가생명의위협을받을수있다는가능성을다룸. ISO 는 ISO 표준의좀더일반적인목적의실현을특정구현 ISO 은모든기능안정성표준의상위개념으로서참조되어짐

5 Life cycle

6 V-model

7 3-7 Hazard Analysis and Risk Assessment 상황분석과위험정의 (Situation Analysis and Hazard Identification) Hazardous Event 를발생시킬수있는 Item 의잠재적 Unintended Behavior 를정의 위험유형 (Hazard Classification) Item 의 Hazard 로부터고려된 Severity, Exposure, Controllability 를결정 ASIL 과 Safety Goal 의결정 (Determination of ASIL and Safety Goals) 요구되는자동차통합안전등급 (Automotive Safety Integrity Level) 을결정 ASIL 이결정된각각의 Hazardous Event 마다 Safety Goal 을결정

8 3-5 Item definition 시스템이표준대로개발되었을때, item definition 이가장먼저해야함 Item definition 은시스템의기본적인정의와역할등의정보를기술해분석하려는아이템을명확히하는단계 Item definition 은외부시스템의존성과사전적구조들이반드시정의되어져야한다. 정의된아이템역할분석데이터를토대로관련기능들을뽑아내는순서로작업이진행 아이템이전체차량이아님을주의해야한다 보통하나의아이템이독립적으로역할을수행하는경우는매우드물다 아이템의크기는임의적이고, 보통큰시스템은디자인하기좀더복잡함. 반면에작은시스템은좀더외부적의존성을가지고있다 3-6 Initiation of the safety lifecycle 원래존재하는것인지수정을하는것인지를판단하는과정임. 적용 긴급제어시스템은차량이급정거하였을때주의차량과자신의차량의피해를최소화하기위하여 ABS ECU 브레이크압력센서 ABS 속도센서, 전송메시지컨트롤러, 알림등과같은상호작용이필요함. 이와같은아이템이가지고있는특성과아이템간의상호작용에따라시스템의기능이설정함. Item boundary 위험분석및평가활동을위한기본데이터가됨. ABS ECU 전송메세지컨트롤러 Item elements ABS 속도센서 브레이크압력센서 Item : 차량 Level에서 ISO 26262에준하는기능을수행하기위한시스템또는배열시스템 (System) : 최소하나이상의 Sensor, Controller, Actuator를포함하고있는 Element들의조합을말함

3-7 Hazard Analysis and Risk Assessment 위험분석및평가활동은, 아이템의기능불량이나동작상태, 차량운행환경등의정보가포함된위험상황 ( 아이템이의도하지않은동작을해여발생할수있는사건을의미 ) 분석작업을통해수행 요구하는위험분석및평가활동은위험한상황을발생시킬수있는모든사건들을분석해최종적으로 ASIL 등급할당과안전목표를설정하는절차로진행됨.

9 3-7 Hazard Analysis and Risk Assessment 위험분석및평가활동은, 아이템의기능불량이나동작상태, 차량운행환경등의정보가포함된위험상황 ( 아이템이의도하지않은동작을해여발생할수있는사건을의미 ) 분석작업을통해수행 요구하는위험분석및평가활동은위험한상황을발생시킬수있는모든사건들을분석해최종적으로 ASIL 등급할당과안전목표를설정하는절차로진행됨. 시스템의복잡도에따라발생가능한위험상황의수가수천, 수만개까지만들어질수있다 요구사항들을준수하며안전활동검증 (Safety Assessment) 작업을수행하는데에는안전관리도구가반드시필요함 적용 긴급메시지전송시스템의경우에는 자동차의 20Km/s 의속도변화가없었는데의도하지않은긴급메시지의전송이이루어져주위차들의급제동으로인한위험이발생가능성이있음. 위험도분석및평가활동도구

10 3-7 Hazard Analysis and Risk Assessment 아이템정의가만들어지고, 아이템정의는위험도분석을위한기본으로사용되어짐 위험도분석은위험한이벤트들을리스트로만드는것. 각각의이벤트들은 ASIL(Automotive Safety Integrity Level) 이주어짐. ASIL 은이벤트가얼마나위험한지에대한표시이고, 범위는 A~D 까지이고, D 는가장위험한단계이다. E1 E2 E3 E4 지속시간 - 작동시간 1% 미만 빈도 예 1 년에 1 회미만발생 엔진정지상태로내리막주행 1 년에수차례발생하는상황 안전하지않게가파른경사주행 작동시간 1~10% 1 개월에 1 회발생하는상황 미끄러운노면브레이크사용 작동시간 10% 초과 거의매주행시마다발생하는상황 S1 S2 S3 C1 C2 C3 설명 예 경상이나심하지않은부상 20Km/h 미만의속도로나무와충돌 생명을위협할가능성이있는심한부상, 생존가능 20~40Km/H 의속도로나무와충돌 생명을위협하는부상 ( 생존불확실 ) 또는치명상 40Km/H 를초과하는속도로나무와충돌 설명 정의 간단히제어가능 모든운전자가피할수있는위험 일반적으로제어가능 90% 의운전자가피할수있는위험 제어하기어렵거나또는제어불능 90% 미만의운전자가피할수있는위험

11 3-7 Hazard Analysis and Risk Assessment-ASIL ASIL C 정상일경우긴급메시지를전송하지않음 E3 : 빈도 - 1 개월에 1 회발생하는상황예 : 미끄러운노면브레이크사용 S3 : 설명 : 생명을위협하는부상 ( 생존불확실 ) 또는치명상예 : 40Km/H 를초과하는속도로나무와충돌 C2 : 설명 : 일반적으로제어가능 90% 운전자가피할수있는위험예 : 경미한고장이발생했을때차량정지 = ASIL B ASIL A 속도의변동폭이 20Km/s 이하이면정상 E4 : 빈도 - 거의매주행시발생예 : x S1: 설명 : 경상이나심하지않은부상예 : 20Km/H 미만의속도로나무와충돌 C2 : 설명 : 일반적으로제어가능정의 : 90% 운전자가피할수있는위험예 : 경미한고장이발생했을때차량정지 = ASIL A ASIL B ABS 속도센서장착 E4 : 빈도 - 1 년에 1 회미만발생예 : 엔진정지상태로내리막주행 S2 : 설명 : 경상이나심하지않은부상. 예 : 20Km/H 의속도로나무와충돌 C2 : 설명 : 일반적으로제어가능정의 : 모든운전자가피할수있는위험예 : 경미한고장이발생했을때차량정지 = ASIL B

12 3-7 Hazard Analysis and Risk Assessment-ASIL

3-7 Safety Goal Hazard analysis and Risk assessment 분석을통해도출한안전목표 ASIL 이결정된각각의 Hazardous Event 마다 Safety Goal 을결정 From the Safety Goals, FSRs (Functional Safety Requirement) are derived.

13 3-7 Safety Goal Hazard analysis and Risk assessment 분석을통해도출한안전목표 ASIL 이결정된각각의 Hazardous Event 마다 Safety Goal 을결정 From the Safety Goals, FSRs (Functional Safety Requirement) are derived. 안전성목표로부터, 기능안전요구사항들이나온다. ( 예 : 실패사례분석 ) Each hazardous event is then assigned to a Safety Goal, which is formulated so that when the goal holds, the event will not occur. 속도의변동폭이 20Km/H 미만인경우에주위차량에긴급메시지를전송해서위험을초례한사례들을수집및분석예 ) 의도치않은급제동으로인한긴급메시지브로드캐스팅으로인하여사고발생사례분석 정상일경우긴급메시지를전송하지않음 속도의변동폭이 20Km/H 이상인데 broadcast 장비에긴급메시지전송요청을하는 ABS 오작동사례를수집및분석예 ) ABS ECU 시스템의오작동사례분석 속도의변동폭이 20Km/s 이하이면정상 ABS 속도센서의장착위치에따른오작도사례를모음 ABS 속도센서의속도감지오작동사례를수집및분석예 ) 센서의위치에따른오작도사례분석 ABS 속도센서장착

14 3-7 Safety Goal

15 Safe Requirements Phases diagram G001 : 정상일경우긴급메시지를전송하지않음 SR001 : 속도의변동폭이 20Km/s 이하이면정상 SR002 : ABS 속도센서장착 G001 정상일경우긴급메시지를전송하지않음 SR001 속도의변동폭이 20Km/s 이하이면정상 SR002 ABS 속도센서장착

Safe Requirements Phases diagram G001 정상일경우긴급메시지를전송하지않음 ASIL B E4 : 빈도 - 거의매주행시발생예 : x S2 :

예 : 20 ~40Km/H 의속도로나무와충돌 C2 : 설명 : 일반적으로제어가능 90% 운전자가피할수있는위험경미한고장이발생했을때차량정지 = ASIL B SR001

미만의속도로나무와충돌 C2 : 설명 : 일반적으로제어가능정의 : 90% 운전자가피할수있는위험예 : 경미한고장이발생했을때차량정지 = ASIL B SR002 ASIL

16 Safe Requirements Phases diagram G001 정상일경우긴급메시지를전송하지않음 ASIL B E4 : 빈도 - 거의매주행시발생예 : x S2 : 설명 : 생명을위협할가능성이있는심한부상, 생존가능. 예 : 20 ~40Km/H 의속도로나무와충돌 C2 : 설명 : 일반적으로제어가능 90% 운전자가피할수있는위험경미한고장이발생했을때차량정지 = ASIL B SR001 ASIL A 속도의변동폭이 20Km/s 이하이면정상 E4 : 빈도 - 거의매주행시발생예 : x S1: 설명 : 경상이나심하지않은부상예 : 20Km/H 미만의속도로나무와충돌 C2 : 설명 : 일반적으로제어가능정의 : 90% 운전자가피할수있는위험예 : 경미한고장이발생했을때차량정지 = ASIL B SR002 ASIL B ABS 속도센서장착 E4 : 빈도 - 1 년에 1 회미만발생예 : 엔진정지상태로내리막주행 S2 : 설명 : 경상이나심하지않은부상. 예 : 20Km/H 의속도로나무와충돌 C2 : 설명 : 일반적으로제어가능정의 : 모든운전자가피할수있는위험예 : 경미한고장이발생했을때차량정지 = ASIL B

3-8 Functional Safety Requirements Each Safety goal Safety state specify Preliminary architectural assumption drive Functional Safety Requirements Functional concept Safety goals drive considering

17 3-8 Functional Safety Requirements Each Safety goal Safety state specify Preliminary architectural assumption drive Functional Safety Requirements Functional concept Safety goals drive considering Operating mode System states 적용차량의속도를감지하는중복기능을지정 ( 감지하는기능이하나이면고장시작동하지않아서위험하지만중복을적용하면하나가고장시다른하나의작동으로기능이안정될수있음. ABS 는휠속도센서와 ECU 가제어하는휠실린더의개수에따라구분된다. 기본적인작동은감압과증압모드를통해이루어지는데운전자가브레이크를밟으면 ECU 가휠회전속도센서의신호를기초로슬립률을계산 ABS 의작동 (1) 감압모드 : 브레이크를밟으면 ECU 는휠회전속도센서의신호를기초로슬립률 (slip ratio) 을계산 (2) 증압모드 : 브레이크유압이낮아져슬립률이지나치게줄어들면, ECU 는다시솔레노이드밸브를닫음 Functional Safety Requirements 도출

18 4-7 System design ABS senser ECU Emergency message transmission

19 4-6 Technical safety requirements To comply Functional safety requirements verify Technical Safety Requirements specification develop Technical safety requirements refine Functional safety concept considering Item-Level Functional safety requirements Preliminary architectural design Functional safety concept detail System level Technical Safety Requirements System level Technical Safety Requirements allocate allocate Hardware elements Software elements

20 4-6 Technical safety requirements Technical Safety Requirements specification Requirement and recommendations considering System property External interface constraints System configuration requirements Production operation maintenance repair decommissioning

21 4-6 Technical safety requirements Requirement and recommendations evaluate Production operation maintenance repair decommissioning considering Requirements for operation Warning and degradation concept Measure for field data collection and analysis Condition for storage Approved configuration Competence of the personnel involved

22 4-6 Technical safety requirements Requirement and recommendations Ex) programming, sensor calibration/setup and diagnostic equipment maintenance repair describe The work steps and procedures, diagnostics routines and methods The describe of maintenance tools and means

23 4-6 Technical safety requirements Technical Safety Requirements specify between specify Safety-related functional and non-functional requirements System or elements of item Item and other system 적용어떤툴을사용하며어떻게코딩을해야하는지에대한요구사항. 센서의보정 / 설치및진단장비가어떤것이있으면사용가능한지에대한요구사항생산작동유지보수수리해체에관한요구사항만약 ABS 센서를사용할수없다면, ABS ECU 가기능적으로작동하지않으므로사용할수없다. 서로다른축방향의두개의독립적인가속도계의구현을통한두개의독립적인점화회로구현

24 5-6 Specification of Hardware safety requirements TRS No. HSRS No Hardware safety requirement specification(only for emergency message system) Xxx Xxx Sencing data via ABS is compare with other data via other hardware. When emergency situation happen, emergency system shall make broadcast the message to notify the emergency situation. ASIL C Implementation to Design(device subpart) ABS

25 5-6 Specification of Hardware safety requirements To control internal failures Hardware safety requirements specification include To make the element under consideration tolerant to failures external to element To comply with the safety requirements of other element To detect and signal internal or external failures

26 5-6 Specification of Hardware safety requirements

27 6-6 Specification of software safety requirements

28 6-6 Specification of software safety requirements Technical safety reqirements System design derive software safety requirements specification consider System and hardware configuration Hardware-software interface specification Hardware safety requirements and hardware architecture Include information to ensure The timing constraints External interfaces Software design and subsequent activities to be performed effectively Each operating mode of vehicle Software verification and safety validation of software validation of software aspects to be performed effectively Functional safety to be assessed effectively

29 6-6 Specification of software safety requirements SSR ID 처리내용 Xxx-SSR001 ASIL C 요구된 Technical Safety Requirements ABS 센서로부터의이상요인을입력하여, ABS 센서의이상유무를판정하여출력한다. 입력대상의이상요인은아래와같다 -ABS 센서전원전압무효 -ABS 센서간의노이즈있음 -ABS 센서와단선쇼트의무효.. ABS 센서에서비정상데이터를입력하여시스템제어허가를판정해서출력한다. 이상검출후에정보가끝나기전까지시스템제어가불가능한상태를계속한다. 시스템제어가불가능한비정상데이터를입력하여, 구동모드를판정하여특정부분의출력을제어함 시간 xx ms 처리순서

30 6-7 Software architectural design Software partitioning 이란 Software elements 간의간섭이없도록설계하는방법 Software partitioning 의목적한소프트웨어 partition 에서발생한에러를다른소프트웨어 partition 으로전이되는것을막기위함 Software partitioning 의조건 - Software component 간의간섭이없어야한다. - 다음의속성을보여야한다. - 공유자원의간섭이없음 - 자기영역 ( 코드및데이터 ) 이다른 component 에의해간섭이없음 - Task performance 가다른 component 에의해간섭이없음 Software partitioning 의장점동일한 resource 를사용하는 software partition 들의 coexistence 를허용한다. 하나의 software partition 을변경하였을때, 다른 software partition 은재검증하지않아도된다

31 6-7 Software architectural design Software partitioning 의사례 Partition 을하지않은경우 ( 왼쪽그림 ) Task 전체가같은 ASIL 등급으로묶인다. Partition 을한경우 ( 오른쪽그림 ) Partition A 와 Partition B 는서로다른 ASIL 등급이될수있다. ASIL of Partition A = Max ASIL of (Task1, Task2, Task3) ASIL of Partition B = Max ASIL of (Task4, Task5, Task6) Partitioning 을한경우 Partitioning 을하지않은경우

32 6-8 Software unit design SSS(Softw are Safety Specificatio n) ID Xxx-SSS001 ASIL C 요구된 SSR ID (SSS의상위 requirement(technical requirement or System design)) SSR XXX 처리내용 ABS 센서의이상에대한통지가온후에일정시간동안계속된후에이상을확인하고시스템상태를 OFF 로한뒤에일정구간변경을지시하고오류부분을억제하고제동제어가되도록일정구간의출력을제어한다. 시간 xx ms 처리배치 컴포넌트 SCSR ID SSS 의하위의세부 component specification requirement(cs R) 내용시간 ASIL Scp001 Xxx ABS센서로부터이상을입력다른센서이상여부를판전 SCP002로출력한다 입력대상의원인을아래와같이정의 -ABS 센서전원전압의여부 xxms C scp002 xxx SCP001로부터 ABS센서이상을입력시스템제어의허가를판정하고 SCP003에출력 이상검출시어떤상태까지시스템제어불가상태를계속진행한다. xxms C

33 6-9 Software unit testing a) Software unit design specification 에부합함 b) Hardware-software interface 의 specification 에부합함 c) Functionality 를정확하게구현함 d) 의도하지않은 functionality 가없음 e) 소프트웨어의강인성 (Robustness) ( 접근불가능한소프트웨어가존재하지않음, error detection, handling mechanism 의효과성 ) f) Functionality 를지원하기위한충분한리소스

34 6-10 Software integration testing integration testing 이란함수여러개를모아서테스트를수행하는것방법테스트대상함수들 (Functions under test) 사이의 interface 가올바르게구현되었는지, 입출력값이올바른지에대해테스트를수행한다. 긴급메시지 다른함수 다른함수 다른함수

35 6-11 Verification of software safety requirements 1a- 하드웨어에주변장치를붙여서가상의환경을만드는방법. 1b- 여러 ECU 를네트워킹하는방법. 1c- 실제차량으로테스트를하는방법.

36 CMMi Terminology & Structure Maturity Levels (1-5) Process Area 1 Process Area 2 Process Area n Required. Specific for each process area. Specific Goals Common Generic Goals Features Required. Common across all process areas. Commitment to Perform Ability to Perform Directing Implementation Verifying Implementation Specific Practices Required Required Generic Practices Sub practices, typical work products, discipline amplifications, generic practice elaborations, goal and practice titles, goal and practice notes, and references Sub practices, typical work products, discipline amplifications, generic practice elaborations, goal and practice titles, goal and practice notes, and references

37 Generic Goals & Practices Each process area is defined by a set of goals and practices Generic goals and practices: They are part of every process area Generic Practices by Goal GG 1 Achieve Specific Goals GP 1.1 Perform Specific Practices

38 Generic Goals & Practices GG 2 Institutionalize a Managed Process GP 2.1 Establish an Organizational Policy GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility GP 2.5 Train People GP 2.6 Manage Configurations GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control the Process GP 2.9 Objectively Evaluate Adherence GP 2.10 Review Status with Higher Level Management

39 Generic Goals & Practices GG 3 Institutionalize a Defined Process GP 3.1 Establish a Defined Process GP 3.2 Collect Improvement Information GG 4 Institutionalize a Quantitatively Managed Process GP 4.1 Establish Quantitative Objectives for the Process GP 4.2 Stabilize subprocess Performance GG 5 Institutionalize an Optimizing Process GP 5.1 Ensure Continuous Process Improvement GP 5.2 Correct Root Causes of Problems

40 CMMi Process Areas Maturity Level Project Management Engineering Process Management Support 5 (Optimizing) 4 (Quantitatively Managed) 3 (Defined) Quantitative Project Management Integrated Project Mngt Risk Management Requirements Development Technical Solution Product Integration Organizational Innovation & Deployment Organizational Process Performance Organizational Process Focus Organizational Process Definition Organizational Training Causal Analysis & Resolution Decision Analysis & Resolution Verification Validation 2 (Managed) 1 (Initial) Project Planning Project Monitoring & Control Supplier Agreement Management Requirements Management Measurement & Analysis Process & Product Quality Assurance Configuration Management

41 Requirements Management (REQM) Purpose : The purpose of Requirements Management (REQM) is to manage the requirements of the project's products and product components and to identify inconsistencies between those requirements and the project's plans and work products. Specific Practices by Goal SG 1 Manage Requirements SP 1.1 Obtain an Understanding of Requirements SP 1.2 Obtain Commitment to Requirements SP 1.3 Manage Requirements Changes SP 1.4 Maintain Bidirectional Traceability of Requirements SP 1.5 Identify Inconsistencies between Project Work and Requirements

42 Requirements Management (REQM) For the Requirements Management Process Area: An example Goal (required): Manage Requirements An example Practice to support the Goal (required): Maintain bi-directional traceability of requirements Examples (suggested, but not required) of typical Work Products might be Requirements traceability matrix or Requirements tracking system

43 Thank You! L/O/G/O

SW¹é¼Ł-³¯°³Æ÷ÇÔÇ¥Áö2013

SW¹é¼Ł-³¯°³Æ÷ÇÔÇ¥Áö2013 SOFTWARE ENGINEERING WHITE BOOK : KOREA 2013 SOFTWARE ENGINEERING WHITE BOOK : KOREA 2013 SOFTWARE ENGINEERING WHITE BOOK : KOREA 2013 SOFTWARE ENGINEERING WHITE BOOK : KOREA 2013 SOFTWARE ENGINEERING