아키텍처 설계
LKAS 요구사항도 개발했고, System과 HW는 설계 되어 있다고 가정한다.
상세 설계(기능 모듈)
차량이 차선을 벗어나려는 움직임이 감지되면, LKAS 시스템은 운전자 개입 없이 조향 보조를 수행해야 한다.
-
Flow Chart
-
모듈 설계
- 순환 복잡도 계산을 위해 Graph형태로 변경
Black Box Test
여러 종류가 있지만, 동등 분할과 경계값 분석을 사용하여
Test Case를 설계하였다.
- 동등 분할
[요구사항 2 - 차선 인식]
기존: 차량 속도가 60km/h 이상이고 차선이 인식되면, LKAS 시스템은 능동 감시 상태로 전환되어야 한다.
수정: 차량 속도가 60km/h 이상 177km/h 미만이며, 차선이 인식되면, LKAS 시스템은 능동 감시(Active) 상태로 전환되어야 한다.
추후, 요구사항이 변경 되었다. 이처럼 앞 단계 요구사항 개발/검증 단계에서 면밀히 검토해야 추후에 수정에 따른 비용을 줄일 수가 있다. 변경 이유는 현대차의 경우 177km/h이라는 제약조건이 있다고 하여 변경하였다. OEM이나 차종마다 다를 것이다.
- 경계 값 분석
[요구사항 3 - 차선 이탈 감지]
기존 : 차량이 차선을 벗어나려는 움직임이 감지되면, LKAS 시스템은 운전자 개입 없이 조향 보조를 수행해야 한다.
수정 : 차량이 차선을 벗어나려는 움직임(-25 > offset || 25 < offset)이 감지되면, LKAS 시스템은 운전자 개입 없이 조향보조를 수행해야 한다. 또한 offset의 범위는 다음을 만족해야 한다. (-50 < offset < 50)
역시, 상세하게 요구사항이 변경되었다. 만족해야하는 조건이 누락된 채 모호하게 쓰였기 때문이다. 검증 단계 전반에서 이를 확실히 해주어야 한다.
White Box Test
앞서, 변경한 Graph구조와 순환 복잡도를 계산하여
"최소"의 커버리지를 수행하는 테스트 케이스 경로를 설계했다.
물론 여력이 되면 품질 확인을 위해 모든 커버리지를 테스트하는게 좋지만,
실제 개발환경에서는 테스트도 비용이 어마무시하게 들어간다.
추적표 작성
이처럼, 문서화 된 작업 산출물들이 V-Model 검증단계에서도, 확인단계에서도 엄청나게 나오게 된다.
하지만, 중구난방으로 명명규칙도 없이 로컬에다 막 저장한다면?
추적성이 무너지고, 무너진 추적성은 변경사항을 연관된 문서들에 반영할 수 없다.
즉, 일관성이 깨지게 된다.
그러면 Baseline 자체도 수립이 불가능하다.
추적성은, A-SPICE/V-Model/ISO26262에서도 아주 중요하게 생각한다.
A-SPICE의 BP들을 보면 추적성/일관성/계획을 아주아주아주 강조하고 있다!
따라서, 추적표를 작성하여 관리해 프로젝트를 통제/관리하는 것이 아주 좋은 방법이다.
[요구사항 2 - 차선 인식]
차량 속도가 60km/h 이상 177km/h 미만이며, 차선이 인식되면, LKAS 시스템은 능동 감시(Active) 상태로 전환되어야 한다.
[요구사항 3 - 차선 이탈 감지]
차량이 차선을 벗어나려는 움직임(-25 > offset || 25 < offset)이 감지되면, LKAS 시스템은 운전자 개입 없이 조향보조를 수행해야 한다. 또한 offset의 범위는 다음을 만족해야 한다. (-50 < offset < 50)
이름 정도만 기재하였지만, 실제론 위치부터 담당자 등등 상세하게 링크가 이어지도록 잘 구성해야 한다.
