자동차 E/E 시스템에 오픈소스(Open source)사용 시 요구되는 개발관련 활동 및 책임

자동차가 연결성(Connectivity), 스마트(smart)화 그리고 ADAS(Advanced Driving Assistance System) 및 자율주행(Automatic Driving) 관련 기능들이 급격하게 늘어나면서, 외부의 오픈소스(Open Source)를 사용하는 경우가 늘어나고 있다. 이러한 경우 자동차의 문제 발생시 책임관련 부분 및 이슈를 해결하기 위해 아래 사항들을 고려 해야 한다.

Many of the advances in automobile efficiency, performance, safety and in-vehicle infotainment have been driven by software. Today cars contain about 100 million of lines of code (much of which is open source) and growing! Learn more about the future of open source in the automotive industry.

from Slidesahre "Open Source Will Drive the Automotive Industry"

● Responsibility

Open소스는 출처 및 근거가 명확해야 하며, Open 소스가 가지는 요구사항인 소스의 Open및 변경에 대한 범위를 자체 ECU SW에 탑재하는 경우, 반드시 고객사(OEM 및 TIER)에게 알려야 한다. 특히 Open source의 경우 개발 지원이 되지 않기 때문에 ACQ4를 적용할 필요가 없지만, OEM 및 상위 Tier에서는 반드시 ACQ4 적용을 통해 관리가 되어야 한다.

 ● 개발 및 테스트 계획서

 개발 계획서 및 테스트 계획서에 반드시 제약사항에 open source의 사용을 밝히고, 근거를 제시한다. 무엇보다도 테스트 계획서은 테스트 scope 및 verification criteria가 기술되어야 한다. 이러한 근거에 따라 반드시 개발 및 테스트가 수행되어야 한다.

 ● 설계 관점

Open 소소의 경우는 SRS(소프트웨어 요구사항 명세서)에 기록되는 것을 권고한다, 단 Open Source가 하나 또는 복수개의 기능 또는 비기능 요구사항이 아닌 하나의 컴포넌트(인터페이스 및 bus 등)인 경우는 SRS에 나타나지 않을 수 있다. 하지만 반드시 SAD의 아키텍처에 포함되어야 하며 이러한 경우 반드시 아키텍처에 Open Source로 표기하는 것이 권고된다.

 ● 테스트 관점

테스트의 경우는 SDD(소프트웨어 단위 설계서)가 없는 경우, 별도의 SDD를 작성하는 것이 좋으나, 어려울 경우, ISO 26262의 SW Component 인증방법을 사용하여 단위테스트를 대체하는 것도 방법일 수 있다. 이러한 경우 테스트 전략에 근거와 기준을 작성하여 수행해야 한다.

특히 안전기능과 관련된 컴포넌트의 경우는 반드시 SW Component qualification을 수행해야 하며, DFA를 통해 ASIL 공존 및 Co-existence 부분을 판단해야 한다.

나머지 소프트웨어 통합 및 소프트웨어 기능 테스트는 자체개발 소프트웨어와 동일하게 취급한다.