(Safety) requirements specification 중 UML 소개

ISO 26262는 Function, Technical (or System), Hardware, Software 의 각 레벨 별로 Requirements의 명세와 관리(추적 포함)를 요구하고 있다.

아래 표는 ISO 26262:2011 Part 8 Figure 2의 Structure of safety requirements이다.

각 레벨 별로 ASIL 에 따라 요구되는 방법을 통해 요구사항을 명세하게끔 되어 있다.

아래 표는 ISO 26262:2011 Table 1 Specifying safety requirements 이다.

위 표와 더불어서 ASIL에 관련없이 (또는 모든 ASIL)에 natural language를 고려할 수 있다고 되어 있다.

natural language를 무시(?)할 건 아니다. 각 요구사항들에 위 방법대로 다 작성 시 쉽지 않을 수 있다. 또한 FSR(Functional Safety Requirements), TSR(Technical Safety Requirements)와 같은 상위 레벨에서는 natural language가 더 적절할 수도 있다.

또한 1a Informal notation에 natural language를 포함시켜 생각할 수도 있다.

위 방법 중 가장 관심을 가지고 있고, 많이 활용되는 것이 1b Semi-formal notation이다.

Information notation과 비교하였을 때 정해진 방법이 존재하지만, 완전하고도 강제적인 표기법을 요구하고 있지 않다. 이는 유연하게 활용가능할 수 있다고 이해하면 될 것이다.

가끔 완벽하게 Formal notation을 사용하는 것이 더 바람직한 것이 아니냐? 라는 질문을 받는다. 개발자들 또는 요구사항 명세서 (Requirements specification)을 한번이라도 작성하신 분들은 이러한 질문을 굳이(?) 하지는 않는다.

표기법이 완벽하고 온전하게 정의되어 있다는 것은 이를 활용하는 사람들도 완벽하고 온전(?)하게 이해하고 있어야 한다. 요구사항 도출하고 명세하는 프로젝트 초기에 굉장히 숨막히고 짜증이 많이 날 수 있다. 다른 산업군에서는 이를 요구하기도 하지만, 자동차 분야에서는 잘 활용하지 않는다. (아직까지 나도 보질 못했다.)

그러면 Semi-formal notation의 예로 무엇이 있을까? UML, SysML등이 대표적이라고 할 수 있다.

https://www.visual-paradigm.com/VPGallery/diagrams/index.html

위 각각의 UML Modeling 뿐만 아니라 다른 Modeling 까지 설명이 아주 잘 되어 있으니 참고하길 바란다.

이와 더불어서 Boiler plate이라는 방법이 있다.

2014년에는 이 방법을 Semi-formal notation으로 보는 것이 맞나, 아닌가 라는 조심성있게 접근했던 적이 있었는데, 시간이 지나고 보니 그럴 필요가 없었다.

Semi-formal 이 가지는 의미를 고려해본다고 하면, 충분히 적용이 가능하다고 판단할 수 있겠다.

Safety requirements라는 것은 무엇일까?

이 글 초기에 Function 부터 Software까지의 각 레벨 별로 Functional safety (여기서는 ISO 26262)에서 요구하는 내용을 포함한 Requirements라고 이해하면 된다.

Safety mechanism을 포함하였고, 요구하는 HW architectural metrics, PMHF 등의 목표 값을 고려하여 요구사항을 작성하는 점이 가장 큰 차이일 것이다.

참고로 Boiler plate과 관련된 내용은 별도의 글로 Update 하겠다.

더위 조심하시고, 오늘도 수고하셨고 수고하시길 바랍니다.