Item definition

Item definition, 아이템 정의

ISO 26262 Part 1.Vocabulary의 정의를 인용하여

1.69

item

system or array of systems to implement a function at the vehicle level, to which ISO 26262 is applied 

아이템

ISO 26262가 적용되는 자동차 수준에서 기능을 수행하는 시스템 또는 시스템 배열

어려운 영어가 아니니 해석은 되겠지만, 아이템이 시스템 또는 시스템 배열이라고?

이는 ISO 26262 Part 10. Guideline 를 활용해서 확인해 보자.

Figure 4. Example item dissolution

위 그림을 보니까 시스템은 하부 시스템들로 구성될 수 있으며,

item의 정의대로 System 또는 System 배열로 구성되어져 있음을 알 수 있다.

두번째로 E/E는 Sensor, Controller, Actuator로 구성되어 있다.

각 Sensor, Controller, Actuator는 Hardware, Software로 구성되어질 수 있다.

Element는 Hardware부터 System까지 폭 넓게 사용될 수 있다.

이노무 단어가 너무 폭 넓게 되어 있으니까 가끔 어떻게 이해해야 할지 헷갈려 할 때가 있다.

(버럭 버럭)

그럼 Component는 무엇인가?

1.15

component

non-system level element that is logically and technically separate and is comprised of more than one hardware part or of one of one or more software units

컴포넌트

논리적 및 기술적으로 분리 가능하고, 하나 이상의 하드웨어 소자나 하나 이상의 소프트웨어 단위으로 구성된 것으로, 시스템 수준은 아닌 엘리먼트

비고. 컴포넌트는 시스템의 일부이다.

자 그럼 이 글의 제목에서 말한 Item definition, 아이템 정의를 말해보자.(ISO 26262 Part 3. clause 5 참조)

첫번 째 목적은, 아이템 정의의 목적은 아이템, 환경과 기타 아이템과의 의존성 및 상호작용을 정의하고 기술하는 것이다.

두 번재 목적은, 아이템에 대한 적절한 이해와 그 다음 단계의 활동이 수행될 수 있도록 지원하는 것이다.

아이템 정의는 개발하고자 하는 범위를 정확히 정해놓고 시작하자는 것이다.

Figure 22. Item boundary

위 ISO 26262 Guideline 그림을 보자.

점선으로 테두리가 쳐진 부분이 아이템 정의, Item definition이다.

예를 들면 Actuator control ECU는 아이템 정의 내에 있다. 달리 말하면 VS ECU는 개발 범위에 속하지 않는다. 그저 내용을 받아오면 된다.

그럼 받아만 오면 되는 것이냐? 

이런 얘기를 하는 것은 당연히 아니라는 것이겠다.

ISO 26262 Part 3

5.4.2 아이템, 그 아이템의 인터페이스, 그리고 타 아이템과 엘리먼트와의 상호작용과 관련된 가정에 대한 경계는 다음 사항을 고려하여 정의해야 한다.

위 문장에 대해 자세히 a) ~ g)까지 설명은

다른 아이템과의 상호작용, 영향, 기능 분배, 등등에 대하여 고려하고 있다.

아이템 정의 시

ISO 26262 Part 3

5.4.1 아이템과 환경 사이의 의존성은 물론, 아이템의 기능 및 비기능 요구사항에 대한 정보를 이용 가능해야 한다.

아이템과 관련하여 다 정의해야 한다는 것이다.

a) 작동모드와 상태를 포함하는 아이템의 기능과 목적을 기술하는 기능 개념

b) 운영 및 환경 제약 사항

c) 법률적 요구사항(특히 법과 규정), 국가표준과 국제표준

d) 해당되는 경우에 한해, 유사한 기능, 아이템 및 엘리먼트에 의해 달성되는 동작

e) 아이템에서 예상되는 동작에 대한 가정

f) 알려진 고장형태와 위험원을 포함하는 동작결여로 인해 발생할 수 있는 잠재적 결과

고려할게 참 많지 않은가?

그런데, 해당 아이템 정의는 보시다시피 안전(Safety)를 고려하지 않았다.

왜?

이유는 아직 개발 처음이기 때문이다.

개발 초기부터 어떤 기능안전컨셉을 가지고 갈지 정해지지 않았다.

아이템 범위를 정했으니,다음 작업은 어떤 수명주기를 착수하고, ASIL 부여하여 Safety goal를 설정하여

레벨에 맞게끔 개발을 정해야 한다.

Figure 23. Second iteration on the item design

Figure 22과 Figure 23의 차이는 Redundant Switch를 추가하였다.

이는 아이템 정의가 초기 정해지고, Hazard Analysis and Risk Assessment를 통해 ASIL 을 결정하고,

ASIL 레벨에 다라 안전 컨셉을 부여하게 된다.

위 Figure 23은 ASIL C에 따라 Redundant Swith를 부여한 경우이다.

많은 경우 Redundancy를 고려할 수 있겠지만, ASIL A의 경우에는 권장사항도 아니다.

ASIL에 맞게끔 공대생 답게 가격경쟁력을 가진 개발을 위한 머리를 굴려야하겠다.

지끈 지끈 해보자

이상. 끝