선택한 단어 수는 입니다.
최소 단어 이상 선택하여야 합니다.
최소 단어 이상 선택하여야 합니다.
선택한 단어 수는 30입니다.
최대 10 단어까지만 선택 가능합니다.
최대 10 단어까지만 선택 가능합니다.
문제 정의
- 계획은 OEM으로부터 전자식 주차 브레이크 시스템 고객 요구사항을 제공받아 전자식 주차 브레이크 시스템에 대해 개념을 확인한다. 또한 안전 목표 및 기능 안전 요구사항을 충족시키기 위해 프로젝트가 완료되어야 하는 시점까지 어떻게 개발할 것인지 계획하는 단계이다.
- Actuator Status 판단부분 검증을 위해 Actuator Status 판단부분과 연관이 있는 총 17개의 검증대상 프로세스를 생성하였다. 본 논문에서는 17개의 검증대상 중 Host Command, Host Availability Left, Host Availability Right, Actuator Status Left 그리고 Actuator Status Right 총 5개의 프로세스에 대해 기술한다.
- 8은 전자식 주차 브레이크 스위치 또는 외부 상황을 판단하여 Park Apply, Hold Apply, Release, Dynamic Apply, Roller bench Apply, Auto Adjustment 요청을 받는 프로세스이다. 본 논문에서는 Apply 요청, Release 요청 2가지 location automata로 추상화시켜 표현한다.
- Actuator Status Process는 타 프로세스의 정보를 바탕으로 모터의 구동상태가 Park Applied, Hold Applied, Released, Applying, Releasing, Completely Released 또는 Unknown인지 판단하여 다음 Actuator 명령을 만들 수 있도록 상태를 결정하는 가장 중요한 프로세스이다. 본 논문에서는 Unknown, Applying, Applied, Releasing 그리고 Released 총 5개의 location automata로 추상화시켜 표현한다.
- 전자식 주차 브레이크 시스템은 자동차의 제동 및 운행과 관련된 시스템이기 때문에 높은 안전성을 요구하는 제품이다. 본 논문에서는 전자식 주차 브레이크 시스템 중 VDA 305-100의 내용을 준수하여 개발되는 Motor on Caliper Integrated Type 전자식 주차 브레이크 시스템 프로젝트 기준으로 기술한다[17]. Motor on Caliper Integrated Type는 전자식 주차 브레이크 시스템의 소프트웨어와 하드웨어를 안전 개념을 적용하여 2개의 제조사에서 개발하는 Type이다.
- 본 연구를 통해 요구사항 검증의 중요성을 알 수 있었다. 인스펙션을 수행하더라도 설계된 요구사항에는 많은 결함이 있을 수 있고 이는 시스템의 정확성과 안전성을 떨어뜨린다는 것을 알 수 있었다.
- 시스템에서 검증 대상을 선택하고 검증 대상에 대해 유한 모델을 생성한다. 생성 된 유한 모델에서 시스템이 만족해야 할 속성을 충족하는지 확인할 수 있다. 만약 유한 모델이 검증하고자 하는 속성을 만족하지 못하는 경우 반례를 보여준다.
- 3을 보면 알 수 있듯이 모델검증은 시스템을 검증하기 위해 검증대상의 수행행위를 모델링 한다. 이 과정에서 검증하고자 하는 속성에 따라 추상화가 가능하며 정형명세된 수행행위를 검증하고자 하는 속성으로 논리적으로 검증한다. 반면 테스트는 발생할 수 있는 경로에서 가질 수 있는 모든 경우의 수 중에서 샘플링을 통해 검증한다.
제안 방법
- Host Command, Host Availability, Actuator Status 3개의 프로세스를 시스템 요구사항을 사용하여 모델링 하였다. 시스템 요구사항은 하나의 문장이 하나의 식별자로 만들어져 있으며 검증 대상의 시스템 요구사항은 총 807개의 요구사항으로 구성되었다.
- Simulation을 통해 추상화된 모델이 예상되는 시나리오로 동작하는지 확인하여 추후 검증 시 제대로 된 결과를 도출할 수 있는지 검증하였다. 이 과정에서 검증대상에 대한 시스템 요구사항이 807에서 931개로 증가 되었으며 본 논문에서 설명되는 Host Command, Host Availability, Actuator Status 3개 프로세스에 관련된 시스템 요구사항은 73개에서 90개로 증가되었다.
- 가장 먼저 UPPAAL을 사용하여 요구사항을 검증하는 시점을 고려하였다. 시스템 설계 문서가 베이스라인이 설정되고 시스템 설계 문서를 바탕으로 소프트웨어 설계를 시작하기 전 모델검증을 적용하였다.
- 각각의 하드웨어 및 소프트웨어 설계자는 시스템 영역에서 도출된 시스템 요구사항과 기술적 안전 요구사항 중 해당 영역에 할당된 요구사항에 대해 분석을 수행하고, 수행한 결과를 바탕으로 하드웨어 및 소프트웨어 요구사항 도출 및 설계를 진행한다. 하드웨어 및 소프트웨어 영역에 대해서도 FMEA, FTA등을 통해 성숙도를 올리며 검증이 충분히 이루어지면 하드웨어 및 소프트웨어를 구현한다[7, 10, 20].
- 검증대상이 되는 시스템 검증모델이 완성된 뒤 Simulator Tab을 이용하여 Simulation을 수행하였다. Simulator는 시스템 모델의 가능한 동적 루트에 대한 검사를 수행할 수 있는 기능이다.
- 시스템 요구사항은 하나의 문장이 하나의 식별자로 만들어져 있으며 검증 대상의 시스템 요구사항은 총 807개의 요구사항으로 구성되었다. 그 중 본 논문에서 사용되는 Host Command, Host Availability, Actuator Status 3개의 프로세스를 모델링 하는데 사용된 관련 시스템 요구사항은 Table 1과 같이 시스템의 기능에 대해 기술하는 73개의 요구사항이다.
- 기술적 안전 요구사항을 분석한 뒤 Verifier Tab의 Query를 이용하여 속성을 생성하였다. 전자식 주차 브레이크 시스템 개발 프로젝트에서는 기 도출된 137개의 기술적 안전 요구사항 중 점검 대상인 Actuator Status프로세스와 관련되는 79개의 기술적 안전 요구사항을 UPPAAL에서 제공하는 속성 타입으로 표현한 뒤 검증하였다.
- 먼저 고객으로부터 고객 요구사항을 제공받아 어떠한 기능을 수행하는 시스템인지 명확히 하고 고객 요구사항을 바탕으로 개념을 설계한다. 안전목표 및 기능 안전 요구사항 명세를 도출하고 도출한 명세를 바탕으로 시스템, 하드웨어 및 소프트웨어를 설계한다[5].
- 이 과정에서 검증하고자 하는 속성에 따라 추상화가 가능하며 정형명세된 수행행위를 검증하고자 하는 속성으로 논리적으로 검증한다. 반면 테스트는 발생할 수 있는 경로에서 가질 수 있는 모든 경우의 수 중에서 샘플링을 통해 검증한다.
- 본 연구에서는 모델검증을 System Requirements Verification 시점에 적용하였다. 모델검증으로 인스펙션의 부족한 점을 보완하면서 추후 테스트로 인해 발생되는 시스템 설계내용의 변경을 최소화 하였다
- 본 연구에서는 시스템 개발 프로세스에서 시스템 요구사항 분석 영역에서만 모델검증을 사용하였다.
- 본 연구에서는 실제 양산되는 ASIL D등급의 자동차 전자식 주차 브레이크 시스템 프로젝트에서 OEM의 고객 요구사항과 안전목표를 바탕으로 도출된 기능 안전 요구사항이 반영된 시스템 요구사항과 기술적 안전 요구사항 검증을 위해 모델검증을 적용하였다. 모델검증의 적용 시점 및 방법, 프로젝트 수행에 있어 모델검증을 수행함으로써 얻을 수 있었던 개선점을 기술한다.
- 설계자는 ‘deadlock’ 발생되면 Simulation Trace 파트의 진행경로를 확인하고 분석한 뒤 고착상태를 해결할 수 있는 시스템 요구사항을 추가하였다.
- 하드웨어 및 소프트웨어를 구현한 뒤 테스트를 통해 설계명세서에서 요구하는 기능이 제대로 구현되었는지 검증을 한다. 소프트웨어 및 하드웨어 검증이 완료되면 통합을 하여 시스템 통합시험을 수행하며 시스템 검증이 완료되면 고객이 요구하는 기능이 구현되었는지 확인하는 작업을 수행한다. 시스템을 개발하는 Supplier에서 시스템 검증을 완료하면 OEM은 OEM에서 제공한 고객 요구사항을 바탕으로 인수시험을 수행한다.
- 소프트웨어 구현은 기 도출된 소프트웨어 요구사항 명세서, 소프트웨어 구조 설계서, 소프트웨어 단위 설계서를 바탕으로 코딩을 진행하며 동시에 단위시험을 수행한다. 소프트웨어의 정적 분석 및 동적 분석이 충분히 수행되면 소프트웨어 통합시험을 수행하고, 소프트웨어 통합시험이 완료되면 소프트웨어 요구사항 명세서를 바탕으로 소프트웨어 요구사항 테스트를 진행한다.
- 가장 먼저 UPPAAL을 사용하여 요구사항을 검증하는 시점을 고려하였다. 시스템 설계 문서가 베이스라인이 설정되고 시스템 설계 문서를 바탕으로 소프트웨어 설계를 시작하기 전 모델검증을 적용하였다. 개발초기에 결함이 발견되도록 하여 소프트웨어 설계 변경이 최소화될 수 있도록 하였다.
- 시스템 요구사항을 바탕으로 검증모델이 완성되면 UPPAAL Verifier Tab을 이용하여 기술적 안전요구사항 검증을 수행한다.
- 시스템 설계 단계는 고객 요구사항을 분석한 내용을 바탕으로 실제 개발을 위한 기술적 안전 요구사항을 도출하고 하드웨어 및 소프트웨어 영역에 할당하는 단계이다. 시스템설계는 요구사항 도출 및 아키텍쳐 설계와 함께 FMEA(Failure Mode Effect Analysis), FTA(Fault Tree Analysis)등의 안전분석을 바탕으로 성숙도를 올린다. 설계내용에 대한 검증이 충분히 이루어지면 시스템 설계는 베이스라인이 설정된다[5, 6].
- 모델검증은 정형 검증 기법의 하나로 정형명세로부터 생성된 유한모델과 시스템이 만족해야 할 요구사항이 갖추어 졌을 때, 시스템이 요구사항을 만족하는지 논리 알고리즘을 통해 확인하는 방법이다. 시스템에서 검증 대상을 선택하고 검증 대상에 대해 유한 모델을 생성한다. 생성 된 유한 모델에서 시스템이 만족해야 할 속성을 충족하는지 확인할 수 있다.
- 먼저 고객으로부터 고객 요구사항을 제공받아 어떠한 기능을 수행하는 시스템인지 명확히 하고 고객 요구사항을 바탕으로 개념을 설계한다. 안전목표 및 기능 안전 요구사항 명세를 도출하고 도출한 명세를 바탕으로 시스템, 하드웨어 및 소프트웨어를 설계한다[5]. 설계가 완료되면 설계한 시스템 요구사항 명세서, 구조 설계서, 인터페이스 명세서 등의 문서를 참조하여 하드웨어와 소프트웨어 구현을 한다.
- 요구사항 테스트를 모두 만족하면 하드웨어와 소프트웨어를 통합하여 하드웨어 및 소프트웨어의 인터페이스 테스트를 수행하여 시스템 통합시험이 가능한지 확인한다. 하드웨어와 소프트웨어 간에 인터페이스가 확인이 되었으면 시스템 요구사항 명세서를 바탕으로 시스템 테스트를 진행하고 진행된 시스템 개발 절차에 대해 전반적으로 검토한다.
- 이러한 방법으로 기술적 안전 요구사항에 대해 분석한 뒤 기술적 안전 요구사항이 요구하는 목적을 검증모델에 맞게 검증 속성으로 작성한 뒤 검증하였다.
- 기 기술된 것과 같이 ISO 26262 표준에 따라 개발되는 전자식 주차 브레이크 시스템은 9명이 참석한 인스펙션을 수행하였다. 잘 정의된 요구사항을 검증하기 위해 2시간의 사전회의와 40시간의 검토시간이 소비되었고 추가로 8 시간의 인스펙션 회의시간이 투입되었다. 또한 요구사항을 검증하기 위한 98개의 체크리스트 항목 작성시간도 추가되었다.
- 기술적 안전 요구사항을 분석한 뒤 Verifier Tab의 Query를 이용하여 속성을 생성하였다. 전자식 주차 브레이크 시스템 개발 프로젝트에서는 기 도출된 137개의 기술적 안전 요구사항 중 점검 대상인 Actuator Status프로세스와 관련되는 79개의 기술적 안전 요구사항을 UPPAAL에서 제공하는 속성 타입으로 표현한 뒤 검증하였다.
- 전자식 주차 브레이크 시스템 개발은 Fig. 5와 같이 계획, 시스템 설계, 소프트웨어 설계, 소프트웨어 구현, 소프트웨어 통합시험, 시스템 통합시험, 확인 순으로 크게 7개의 절차로 개발되었다.
- 개발초기에 결함이 발견되도록 하여 소프트웨어 설계 변경이 최소화될 수 있도록 하였다. 전자식 주차 브레이크 시스템의 개발 프로세스 중 시스템 설계문서가 완성되고 설계문서에 대한 인스펙션이 완료된 시점에 UPPAAL을 이용하여 시스템 설계문서 중 시스템 요구사항 명세서에 기술된 시스템 요구사항을 검증하였다.
- 전자식 주차 브레이크 양산 프로젝트에 모델검증을 적용하면서 프로젝트 일정에 차질이 생기지 않도록 전체 시스템에서 주요부분을 식별하였고 해당부분만을 검증 모델로 작성하였다.
- 시스템 요구사항 명세서는 시스템 요구사항과 기술적 안전 요구사항 2가지 성격의 요구사항을 포함한다. 하드웨어 및 소프트웨어를 구현한 뒤 테스트를 통해 설계명세서에서 요구하는 기능이 제대로 구현되었는지 검증을 한다. 소프트웨어 및 하드웨어 검증이 완료되면 통합을 하여 시스템 통합시험을 수행하며 시스템 검증이 완료되면 고객이 요구하는 기능이 구현되었는지 확인하는 작업을 수행한다.
- 변수는 Table 2와 같다. 해당 변수 값을 Host Command 프로세스와 Host Availability 프로세스에서 업데이트 할 수 있도록 하였고 Actuator Status 프로세스에서는 업데이트된 변수를 Guard로 활용하여 transition이 수행되도록 하였다.
대상 데이터
- Actuator Status 판단부분 검증을 위해 Actuator Status 판단부분과 연관이 있는 총 17개의 검증대상 프로세스를 생성하였다. 본 논문에서는 17개의 검증대상 중 Host Command, Host Availability Left, Host Availability Right, Actuator Status Left 그리고 Actuator Status Right 총 5개의 프로세스에 대해 기술한다.
- 검증모델이 완성된 후 79개의 기술적 안전 요구사항을 검증하였다. 검증을 위한 UPPAAL 운용환경은 Intel i7-4810MQ의 CPU, 8GB의 RAM, 64bit 운영체제였으며 79개의 기술적 안전 요구사항을 검증하는데 소요된 시간은 총 42.8초가 소요되었다.
- 검증하고자 하는 대상은 전자식 주차 브레이크 시스템에서 외부 정보를 제공받아 제공받은 정보를 바탕으로 현재의 Actuator의 상태를 판단하는 Actuator Status 판단부분을 검증 대상으로 선정했다. 그 이유는 실제 Actuator에 명령을 전달할 부분이며 Actuator Status 판단부분에서 결함이 발생할 경우 하드웨어의 파손은 물론 최악의 경우 안전 사고가 일어날 수 있기 때문이다.
데이터처리
- 시뮬레이션 기능을 이용할 때 하나의 프로세스에 대한영향을 시뮬레이션 하고 싶을 때는 모델링된 Locations에서 Transition을 수행할 Location들만 식별하여 Committed 옵션을 활성화하면 Committed된 Location으로만 제어된다. 시스템 요구사항, 구조 설계자료와 개념 등을 바탕으로 시뮬레이션을 통해 검증모델의 성숙도를 올린 뒤 검증모델이 검증되었다고 판단되면 검증모델을 통해 실제로 검증하고자 하는 속성을 Verifier Tab을 이용하여 검증한다.
이론/모형
- 특별히 V 모델에 안전을 특화 시킨 Spiral 모델을 사용하는 개발 프로세스도 간혹 사용되지만 대부분의 시스템은 V 모델에 기반하여 개발을 진행한다. 본 논문에서 언급하는 전자식 주차 브레이크 시스템의 양산 프로젝트도 V 모델을 기반으로 진행되었다.
- 일반적으로 산업계에서는 시스템 요구사항과 소프트웨어 요구사항 분석을 위해 인스펙션을 수행한다. 정적 분석을 위해서 QAC, CodeSonar, PolySpace 등의 툴을 사용하며, 동적 분석, 소프트웨어 통합 시험, 소프트웨어 요구사항 시험을 위해 VectorCast, LDRA 등의 툴을 사용한다. 소프트웨어 요구사항 시험이 완료되면 시뮬레이터 환경에서 CANoe, vTestStudio 등의 툴을 사용하여 시스템 테스트를 수행하고 시뮬레이터 환경에서 시스템 테스트가 완료되면 실차 테스트를 진행한다.
성능/효과
- 검증대상에 대한 모델링을 완성하는데 약 12일 정도의 시간이 소요되었다. 검증모델이 완성된 후 79개의 기술적 안전 요구사항을 검증하였다. 검증을 위한 UPPAAL 운용환경은 Intel i7-4810MQ의 CPU, 8GB의 RAM, 64bit 운영체제였으며 79개의 기술적 안전 요구사항을 검증하는데 소요된 시간은 총 42.
- Table 6은 인스펙션과 모델검증을 통해 발견된 결함들의 유형이다. 결함 유형을 보면 인스펙션은 대부분이 개별 요구사항의 부적절함을 발견하였으며, 모델검증의 경우 개별 요구사항의 적절함 보다는 다수 요구사항 간의 논리적 오류를 발견하였다.
- 그만큼 시스템은 정교하게 기술될 수 있었다. 기존의 요구사항 개수대비 증가한 비율만 보더라도 인스펙션은 약 2.0%에 그친 반면 모델 검증은 약 18.2%의 요구사항 개수가 증가하였다. 모델검증 검증으로 삭제 된 불필요한 시스템 요구사항까지 고려하면 효율성은 더욱 차이 난다.
- 또한 연구를 통해 인스펙션과 모델검증간에 발견할 수 있는 결함의 유형도 다르다는 것을 알 수 있었다. 인스펙션을 통해 요구사항 하나하나의 완성도를 올릴 수 있으며 모델검증을 통해 요구사항 간의 논리적 결함을 발견할 수 있다는 것을 알게 되었다.
- 본 연구에서는 모델검증을 System Requirements Verification 시점에 적용하였다. 모델검증으로 인스펙션의 부족한 점을 보완하면서 추후 테스트로 인해 발생되는 시스템 설계내용의 변경을 최소화 하였다
- 즉 요구사항을 도출할 때 Actuator의 Apply기능이 수행된 뒤 Host Availability의 변경 영향성에 대해서는 생각하지 못했던 것이다. 반례를 통해 원인을 빠르게 분석할 수 있었고 적절한 요구사항을 추가 정의함으로써 현재는 Apply 명령이 수행된 뒤 Host Availability의 상태가 변경되더라도 Actuator Status는 Apply를 수행하지 않는다는 것을 보장한다
- 속성 검증을 통해 기 도출된 79개의 기술적 안전 요구사항 중 8개의 속성을 만족하지 못하는 것을 확인하고 불만족한 8개의 속성을 만족시키기 위해 시스템 요구사항을 추가하였으며 그로 인해 시스템 요구사항은 931개에서 955개가 되었다. 불만족한 시스템 요구사항 중에는 “Electric Parking Brake System shall not operate APPLY after the parking force is generated to the maximum.
- Host Command, Host Availability, Actuator Status 3개의 프로세스를 시스템 요구사항을 사용하여 모델링 하였다. 시스템 요구사항은 하나의 문장이 하나의 식별자로 만들어져 있으며 검증 대상의 시스템 요구사항은 총 807개의 요구사항으로 구성되었다. 그 중 본 논문에서 사용되는 Host Command, Host Availability, Actuator Status 3개의 프로세스를 모델링 하는데 사용된 관련 시스템 요구사항은 Table 1과 같이 시스템의 기능에 대해 기술하는 73개의 요구사항이다.
- 투입된 공수 및 추후 시스템 유지보수 시 재활용될 검증모델까지 비교하지 않더라도 모델검증 툴 사용의 효율이 좋다는 것을 알 수 있다. 실제로 인스펙션 수행 결과를 확인해보면 요구사항 검증에 있어 문법적 오류나 오타, 3개 이하의 적은 수의 요구사항이 같은 페이지에 기술된 경우에는 검증하는데 좋은 효율을 보였지만 관계 된 요구사항들이 다른 페이지에 기술되거나 관계가 복잡해질수록 효율이 급격히 떨어짐을 알 수 있었다.
- Simulation을 통해 추상화된 모델이 예상되는 시나리오로 동작하는지 확인하여 추후 검증 시 제대로 된 결과를 도출할 수 있는지 검증하였다. 이 과정에서 검증대상에 대한 시스템 요구사항이 807에서 931개로 증가 되었으며 본 논문에서 설명되는 Host Command, Host Availability, Actuator Status 3개 프로세스에 관련된 시스템 요구사항은 73개에서 90개로 증가되었다.
- 이러한 경우 시스템 요구사항 명세서 수정부터 소프트웨어 구조변경까지 수정이 필요하게 되며, 구현된 소스코드는 유지보수가 어려운 복잡한 구조를 가질 확률이 높아진다. 이러한 문제점을 개선하기 위해 소프트웨어 구현 이후 단계가 아닌 고객 요구사항 분석 및 설계 단계에서부터 전기전자시스템 요구사항 검증은 ISO26262에서 요구하지 않더라도 반드시 필요하다는 것을 알 수 있다.
- 본 연구를 통해 요구사항 검증의 중요성을 알 수 있었다. 인스펙션을 수행하더라도 설계된 요구사항에는 많은 결함이 있을 수 있고 이는 시스템의 정확성과 안전성을 떨어뜨린다는 것을 알 수 있었다.
- 또한 연구를 통해 인스펙션과 모델검증간에 발견할 수 있는 결함의 유형도 다르다는 것을 알 수 있었다. 인스펙션을 통해 요구사항 하나하나의 완성도를 올릴 수 있으며 모델검증을 통해 요구사항 간의 논리적 결함을 발견할 수 있다는 것을 알게 되었다.
- 만약 기술적 안전 요구사항 검증이 시스템 테스트 단계에서 처음으로 수행됐다면 문제점은 뒤늦게 확인되었을 것이고, 시스템 설계문서의 변경뿐만 아니라 소프트웨어 설계까지 변경을 해야 했다. 최악의 경우에 시스템 테스트에서 전자식 주차 브레이크의 제동력이 이미 최대 크기로 발생되어 있는 상태에서 제동력을 추가 발생시키는 동작을 수행 함으로써 테스트용 하드웨어를 손상시켜 프로젝트 비용을 증가시킬 수도 있었다. 해당사례와 같이 모델검증을 통해 시스템 요구사항의 성숙도를 증가시킬 뿐 아니라 속성 검증을 통해 잘못된 시스템 요구사항까지 발견할 수 있었다.
- 투입된 공수 및 추후 시스템 유지보수 시 재활용될 검증모델까지 비교하지 않더라도 모델검증 툴 사용의 효율이 좋다는 것을 알 수 있다. 실제로 인스펙션 수행 결과를 확인해보면 요구사항 검증에 있어 문법적 오류나 오타, 3개 이하의 적은 수의 요구사항이 같은 페이지에 기술된 경우에는 검증하는데 좋은 효율을 보였지만 관계 된 요구사항들이 다른 페이지에 기술되거나 관계가 복잡해질수록 효율이 급격히 떨어짐을 알 수 있었다.
- 본 연구에서는 검증대상을 축소시켜 진행했음에도 불구하고 많은 결함을 찾을 수 있었다. 특히 반례를 통한 원인 분석은 시스템을 매우 효율적으로 분석 할 수 있었으며 빠르게 부족한 부분을 찾을 수 있게 하였다.
- 해당 기술적 안전 요구사항을 검증하기 위해 Host Command 프로세스와 관계없이 Host Availability프로세스의 파라메터값 중 Release파라메터의 값이 False인 경우 Actuator Status의 Location의 상태가 Status Releasing이 될 수 없다는 속성을 검증하였다.
- 해당 문제는 시스템 요구사항 중 “Motor command left / right can send APPLY message when actuator left / right status was APPLIED”의 잘못된 시스템 요구사항으로 발생하였고 기술적 안전 요구사항을 충족시키기 위해 잘못된 시스템 요구사항은 삭제되었다.
- 최악의 경우에 시스템 테스트에서 전자식 주차 브레이크의 제동력이 이미 최대 크기로 발생되어 있는 상태에서 제동력을 추가 발생시키는 동작을 수행 함으로써 테스트용 하드웨어를 손상시켜 프로젝트 비용을 증가시킬 수도 있었다. 해당사례와 같이 모델검증을 통해 시스템 요구사항의 성숙도를 증가시킬 뿐 아니라 속성 검증을 통해 잘못된 시스템 요구사항까지 발견할 수 있었다.
후속연구
- 추후 전자식 주차 브레이크 시스템 개발 프로젝트에서는 이러한 부분까지 모델검증을 접목하여 효율적으로 검증을 해보고자 한다. 모델검증을 이용하여 ISO 26262에서 요구하는 요구사항 검증의 효율을 증가 시킴으로써 시스템의 완성도를 올리기 위한 연구를 진행할 예정이다.
- 시스템 설계단계에서 모델검증으로 많은 결함을 발견한 것과 같이 소프트웨어 설계단계에서도 좋은 효율을 낼 수 있을 것으로 기대되며 소프트웨어 설계단계에서도 소프트웨어 요구사항 검증을 위해 모델검증을 활용 할 예정이다.
- 이후에는 OEM이 개발된 시스템에 대해 고객 요구사항을 바탕으로 테스트를 진행하고 시스템에 대한 확인이 완료되면 프로젝트는 종료된다.
- 무엇보다 모델검증 전용 툴보다 추상화가 어려워 시뮬레이션이나 검증을 수행할 때 리소스 부족에 자주 접하게 되어 시스템이 큰 경우에는 해당 기능을 사용하기가 어렵다. 추후 전자식 주차 브레이크 시스템 개발 프로젝트에서는 이러한 부분까지 모델검증을 접목하여 효율적으로 검증을 해보고자 한다. 모델검증을 이용하여 ISO 26262에서 요구하는 요구사항 검증의 효율을 증가 시킴으로써 시스템의 완성도를 올리기 위한 연구를 진행할 예정이다.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.