차량 OTA — 차량 상태 전제와 중단·롤백, 그리고 사용자가 겪는 것

개념

이 레슨의 범위 — 경계를 먼저 긋는다

차량 OTA 는 두 축으로 다뤄진다.

즉 이 레슨은 "갱신해도 되는 상태인가" 와 "사용자가 무엇을 겪는가" 를 맡는다. 규정 대응과 보안 검증은 그쪽 레슨이 다루고, 여기서는 차량이라는 물리적 대상에 소프트웨어를 넣는 일의 고유 조건 에 집중한다.

공격 기법은 다루지 않는다. 모듈 35 레슨 8 에서 세운 대로, 확인하는 것은 거부 동작 이다.

서버 배포와 무엇이 다른가

웹 서비스 배포의 전제가 차량에서 전부 깨진다.

마지막이 조합 폭발을 만든다. 같은 차종도 사양과 기존 소프트웨어 버전이 다르고, 갱신 경로가 여러 갈래가 된다. 레슨 4 의 조합 설계가 여기서도 쓰인다.

다섯 번째가 위험의 크기를 정한다. 서버 배포 실패는 재시도로 끝나지만, 차량 갱신 실패로 차가 움직이지 못하면 견인과 정비소 작업 이 따라온다. 그래서 이 영역의 판정 기준이 "성공했는가" 가 아니라 "실패해도 차가 움직이는가" 가 된다.

갱신 전제 조건 — 무엇을 확인하고 넣는가

차량에 갱신을 넣기 전에 확인해야 하는 조건들이다. 전형적 축이 이렇다.

각 조건의 구체적 기준(배터리 잔량 몇 %, 온도 범위, 통신 품질) 은 요구사항에서 확인한다(원문 확인). QA 가 숫자를 정하지 않는다.

QA 가 설계할 시험은 조건마다 경계 전후 다. 그리고 더 중요한 것이 있다 — 갱신 중에 조건이 깨지는 경우 다.

[조건 확인]  →  [다운로드]  →  [설치]  →  [검증]  →  [완료]
     ↑              ↑            ↑          ↑
  여기서만 보면   이 사이에 운전자가 시동을 걸 수 있다
  충분하지 않다   배터리가 떨어질 수 있다
                  통신이 끊길 수 있다

조건을 시작 시점에만 확인하고 그 뒤를 감시하지 않으면 가장 위험한 상황이 만들어진다. 설치 중에 운전자가 차를 움직이려 하는 경우다.

그래서 확인할 질문이 셋이다.

1. 조건을 지속 감시하는가 — 단계마다, 또는 주기적으로
2. 조건이 깨지면 무엇을 하는가 — 중단하는가, 일시 정지하는가, 계속하는가
3. 운전자가 움직이려 할 때 어떻게 되는가 — 막는가, 알리는가, 중단하는가

세 번째가 설계 판단이 갈리는 지점 이고, 어느 쪽이든 명세에 있어야 한다. 막는 설계라면 "언제까지 못 움직이는가" 가 사용자에게 전달되어야 하고, 중단하는 설계라면 "중단 후 상태가 안전한가" 가 보장되어야 한다. 명세에 없으면 구현이 임의로 정해져 있다 — 모듈 46 레슨 10, 모듈 41 레슨 9 에서 반복한 지적이다.

중단과 부분 실패 — 판정은 "안전한 상태로 남는가"

모듈 35 레슨 8 에서 중단 시 판정 기준을 세웠다. 이 레슨에서는 차량 특유의 부분 실패 를 더 본다.

차량에는 제어기가 여럿 있고, 하나의 갱신이 여러 제어기를 건드릴 수 있다. 그러면 일부만 갱신된 상태 가 만들어진다.

[갱신 대상: 제어기 A, B, C]
 
A 갱신 성공 → B 갱신 성공 → C 갱신 실패
                                  ↓
                     A·B 는 새 버전, C 는 옛 버전
                                  ↓
            → 서로 호환되는가? 차가 움직이는가?

이것이 차량 OTA 의 가장 어려운 문제 다. 확인할 질문이 넷이다.

네 번째가 최후 방어선 이다. 모든 복구가 실패해도 차량이 안전하게 움직여 정비소까지 갈 수 있는 상태 가 남아야 한다. 그 상태의 정의와 보장 범위는 요구사항에서 확인한다(원문 확인) — QA 가 정하지 않지만, 그 요구가 있는지 확인하는 것 은 QA 의 일이다. 없으면 설계 지적이다.

세 번째의 "되돌리는 중 실패" 도 시험 대상이다. 롤백이 또 다른 쓰기 작업이고, 그 작업도 실패할 수 있다. 모듈 46 레슨 7 의 A/B 구성과 부트로더 설계가 이 문제를 다루는 수단이다.

시험 설계에서 만들 중단 지점이다.

다섯 번째를 반드시 넣는다. 그리고 여기서 되돌리는 중 다시 중단 하는 이중 실패도 설계한다.

사용자가 겪는 것

이 레슨이 모듈 35 레슨 8 과 명확히 갈리는 부분이다. 규정은 체계를 요구하고, 사용자 경험은 별도로 설계되고 시험되어야 한다.

동의. 갱신을 시작하기 전에 받는 동의다. 확인할 것 — 동의 범위가 이 갱신에 맞는가(한 번 받은 동의가 모든 갱신에 쓰이지 않는가), 거부할 수 있는가, 거부하면 어떻게 되는가, 나중에 할 수 있는가, 동의 기록이 남는가.

예약과 시점. 사용자가 갱신 시점을 정할 수 있는 설계가 많다. 예약 시점에 조건이 안 맞으면 어떻게 되는가. 다시 예약하라고 알리는가, 조용히 넘기는가. 조용히 넘기면 사용자는 갱신된 줄 안다.

진행 안내. 얼마나 걸리는지, 지금 어디까지 왔는지. 남은 시간 표시가 실제와 크게 다르면 사용자가 중단을 시도한다. 그리고 그 중단 시도가 어떻게 처리되는가 가 시험 대상이다.

제약 안내. 갱신 중에 못 하는 것이 무엇인지. 차를 못 움직인다면 언제까지인지 가 전달되어야 한다. 전달되지 않으면 사용자는 고장으로 인식한다.

결과 안내. 성공했는지, 무엇이 바뀌었는지, 실패했으면 무엇을 해야 하는지. 실패 안내가 가장 중요하고 가장 부실하다. "업데이트 실패" 만 보이면 사용자는 무엇을 해야 할지 모른다 — 다시 시도하는가, 정비소에 가는가, 그냥 타도 되는가.

기능 변화 안내. 갱신으로 동작이 달라지는 경우 가 특히 중요하다. 운전자 보조 기능의 거동이 바뀌었는데 안내가 없으면, 운전자는 이전 거동을 전제로 운전한다. 이것이 레슨 2 의 예상 가능한 오사용으로 직결된다 — IVI 표시가 오해를 만드는 경우(레슨 5) 와 같은 구조다.

기능 변화와 ODD 변화

위의 마지막 항목을 따로 다룰 만하다. OTA 가 기능의 거동이나 ODD 를 바꾸는 경우 가 있다.

세 번째가 미묘하다. 성능 문제로 ODD 를 좁히는 갱신이 나갈 수 있다 (레슨 2 에서 다룬 상황). 사용자가 좁혀진 것을 모르면 이전 범위에서 기능이 작동하지 않는 것을 고장으로 인식 하거나, 더 나쁘게는 작동한다고 믿고 그 범위에서 의존 한다.

다섯 번째도 실무에서 자주 발생한다. 갱신 후 사용자 설정이 초기화되는 것은 흔한 결함이고, 차량에서는 좌석·거울·운전 보조 설정처럼 안전·편의에 걸린 항목 이 포함된다.

갱신 경로 조합

레슨 4 의 조합 설계가 여기서도 쓰인다. 차량 OTA 의 조합 축이다.

[기존 버전]  ×  [대상 버전]  ×  [차종·사양]  ×  [갱신 방식]  ×  [조건 상태]
 여러 갈래      보통 하나      다양            무선·유선·정비소   전원·통신·온도

첫 번째 축이 특히 문제 다. 모든 차량이 최신 버전은 아니다. v1.0 에서 v3.0 으로 건너뛰는 차량과 v2.9 에서 올라가는 차량의 경로가 다르고, 건너뛰기가 지원되는지 가 명세에 있어야 한다.

확인할 질문이 셋이다.

1. 어느 기존 버전에서 올라갈 수 있는가 — 지원 경로 목록이 있는가
2. 순차 갱신이 필요한 경우 가 있는가. 그 경우 사용자가 아는가
3. 지원하지 않는 경로를 시도하면 어떻게 되는가. 거부하는가, 시도하다 깨지는가

세 번째가 가장 위험하다. 지원하지 않는 경로를 시도해 설치 중 실패하면 부분 갱신 상태가 된다. 거부가 깔끔하게 되는지 를 반드시 시험한다.

대표 경로 선정은 레슨 4 의 근거 세 축(점유·위험·경계) 을 쓴다. 경계 가 특히 중요하다 — 가장 오래된 지원 버전, 지원 경계 직전 버전, 그리고 미지원 버전.

안전 경계

이 레슨의 시험은 실차와 전원을 건드리는 영역에 가깝다. 분명히 해 둔다.

• 실차 갱신 시험을 QA 가 임의로 하지 않는다. 차량·전원·장소·안전 조치가 전제이고, 갱신 실패로 차량이 움직이지 못할 수 있다
• 전원 차단·배터리 조작은 승인과 안전 조치가 전제 다(모듈 46 레슨 6)
• 운행 중 갱신 시도 같은 시험은 설계만 하고, 수행은 통제된 환경에서 해당 담당이 한다
• 이 레슨의 실습 과제는 전부 설계·문서 과제 다

그리고 공격 기법은 다루지 않는다. 패키지 위조·중간 변조에 대한 확인은 거부 동작 검증 으로 다루고(모듈 35 레슨 8), 기법은 쓰지 않는다.

실무에서 왜 필요한가

차량 OTA 에서 사고가 나는 지점은 거의 정해져 있다.

첫째, 조건을 시작 시점에만 확인한다. 설치 중에 운전자가 차를 움직이려 하는 상황이 설계에 없고, 그 조합을 시험하지 않았다. 이것은 조건 지속 감시가 있는지 묻는 질문 하나 로 드러난다.

둘째, 부분 갱신 상태를 다루지 않는다. 제어기 여러 개를 건드리는 갱신에서 중간 실패는 반드시 발생하고, 버전 조합 호환성이 정의되어 있지 않으면 그 상태를 판정할 수 없다. "모든 복구가 실패해도 차가 움직이는가" 라는 요구가 있는지 확인하는 것 이 QA 의 가장 가치 있는 질문이다.

셋째, 실패 안내가 부실하다. "업데이트 실패" 만 보이면 사용자는 무엇을 해야 할지 모르고, 정비소 문의가 쏟아진다. 안내 문구를 사용자가 할 행동이 적혀 있는지 로 검토하는 것은 QA 가 할 수 있는 단순하고 효과 큰 작업이다.

넷째, 기능 변화를 알리지 않는다. 운전자 보조 기능의 거동이 바뀌었는데 안내가 없으면 운전자는 이전 거동을 전제로 운전한다. 이것은 사용성 문제가 아니라 안전 문제 이고, 레슨 2 의 오사용으로 이어진다. QA 가 이 연결을 알고 올리면 처리 경로가 달라진다.

다섯째, 건너뛰기 경로를 시험하지 않는다. 모든 차량이 최신 버전이 아니고, 오래된 버전에서 올라오는 경로가 가장 깨지기 쉽다. 그런데 개발 환경의 차량은 대개 최신 버전이라 그 경로가 시험되지 않는다.

채용시장에서의 위치

이 영역은 완성차·부품사의 커넥티드·OTA 조직, 차량 소프트웨어 플랫폼 기업 의 QA 자리다. 공고에는 "OTA", "FOTA·SOTA", "차량 소프트웨어 배포", "커넥티드 서비스" 같은 말이 적힌다.

특징은 빠르게 커지는 영역 이라는 점이다. 차량 소프트웨어 갱신이 보편화되면서 조직이 새로 만들어지고, 그래서 경험자가 적다. 모듈 35 레슨 8(규정·체계) 과 이 레슨(상태·사용자) 을 함께 아는 사람은 특히 희소하다.

면접에서 가르는 질문은 둘이다. "설치 중에 운전자가 차를 움직이려 하면 어떻게 됩니까" — 조건 지속 감시와 세 가지 설계 선택을 말할 수 있으면 다르다. 그리고 "제어기 셋 중 하나만 실패하면 어떻게 하십니까" — 버전 조합 호환성과 "모든 복구 실패 시에도 움직이는가" 를 들면 실무자로 읽힌다.

실습 과제

전제 조건 기준값(배터리·온도·통신)·안전 상태 정의·소요 시간은 전부 "요구사항에서 확인(원문 확인)" 으로 표시한다. 실습은 설계·문서 과제이며 실차 갱신·전원 조작은 포함하지 않는다.

과제 1 — 전제 조건과 지속 감시 (35분)

1. 본문의 여덟 축으로 전제 조건 명세 를 쓴다. 기준값은 원문 확인 표시하고 누가 정할지 적는다
2. 각 조건의 경계 전후 시험 케이스를 설계한다(조건당 3개)
3. 지속 감시 설계를 확인하는 질문 목록을 만든다 — 어느 단계에서, 어느 주기로, 어느 조건을 다시 보는가
4. 조건이 갱신 중에 깨지는 시험을 설계한다. 여덟 축 중 다섯을 골라 각각 깨지는 시점을 다르게 둔다
5. 운전자가 움직이려 하는 경우 를 가장 공들여 설계한다. 세 가지 설계 선택 (막는다 / 알린다 / 중단한다) 각각에 대해 그 설계라면 무엇이 보장되어야 하는가 를 적는다
6. 명세에 이 처리가 없으면 "구현이 임의로 정해져 있다" 는 뜻임을 적고, 질의 문장을 쓴다

과제 2 — 부분 갱신 상태 설계 (35분)

이 과제가 이 레슨의 핵심 산출물이다.

1. 제어기 4개를 갱신하는 시나리오를 설정한다. 각 제어기의 역할을 정한다 (하나는 주행 관련, 하나는 IVI, 하나는 통신, 하나는 보조)
2. 부분 갱신 상태 를 전부 열거한다. 어느 조합이 가능한지 표로 만든다
3. 각 상태에 대해 네 질문을 적용한다 — 호환성 정의, 알아볼 수 있는가, 되돌릴 수 있는가, 되돌릴 수 없으면 어떤 상태로 남는가
4. 버전 조합 호환성 표 를 설계한다. 정의가 없으면 판정할 수 없는 이유를 적는다
5. "모든 복구가 실패해도 차량이 안전하게 움직이는가" 요구가 있는지 확인하는 절차를 쓴다. 없으면 설계 지적 으로 올리는 문장을 만든다
6. 되돌리는 중 다시 실패 하는 이중 실패 시나리오를 설계한다. 모듈 46 레슨 7 의 A/B 구성이 이 문제를 다루는 방식을 참조로 적는다
7. 주행 관련 제어기가 옛 버전으로 남는 경우의 위험을 한 문단 쓴다

과제 3 — 중단 지점 시험 설계 (30분)

1. 본문의 여덟 중단 지점 각각에 시험 케이스 2개를 설계한다
2. 중단을 만드는 방법을 적는다. 소프트웨어 계층으로 가능한 것 과 전원·통신 조작이 필요한 것 을 가르고, 후자는 승인과 안전 조치 전제 를 명시한다(모듈 46 레슨 6)
3. 판정 기준을 "안전한 상태로 남는가" 로 쓴다. 안전한 상태의 정의는 원문 확인 표시
4. 다운로드 중 중단 에서 부분 파일 처리를 확인하는 시험을 쓴다. 저장 공간이 부분 파일로 차는 경우를 포함한다
5. 검증 실패와 중단을 구분 하는지 확인하는 시험을 쓴다. 구분하지 않으면 생기는 문제를 적는다
6. 재시동 중 전원 순단 이 겹치는 경우를 설계한다

과제 4 — 사용자 경험 시험 설계 (35분)

1. 본문의 여섯 영역(동의·예약·진행·제약·결과·기능 변화) 각각에 시험 케이스 4개를 설계한다
2. 동의 범위 를 공들여 쓴다. 한 번 받은 동의가 모든 갱신에 쓰이지 않는지 확인하는 시험을 만든다
3. 예약 시점에 조건이 안 맞는 경우 를 설계한다. 조용히 넘기면 사용자가 갱신된 줄 아는 경로를 그린다
4. 남은 시간 표시 가 실제와 다른 경우를 시험한다. 차이가 크면 사용자가 중단을 시도하고, 그 시도가 어떻게 처리되는지까지 확인한다
5. 실패 안내 를 가장 공들여 설계한다. 실패 유형 6개를 만들고 각각에 대해 사용자가 할 행동이 적혀 있는지 로 안내 문구를 검토한다. "업데이트 실패" 만 보이면 생기는 일을 적는다
6. 제약 안내 에 "언제까지" 가 들어가는지 확인한다. 없으면 사용자가 고장으로 인식하는 경로를 쓴다

과제 5 — 기능 변화와 ODD 변화 (25분)

1. 본문의 다섯 변화 각각에 시험 케이스 3개를 설계한다
2. ODD 축소 갱신 시나리오를 구체적으로 만든다(레슨 2 의 상황). 사용자가 모르면 생기는 두 가지(고장으로 인식 / 작동한다고 믿고 의존) 를 각각 적고, 후자가 왜 더 위험한지 쓴다
3. 기능 거동 변경 이 전달되지 않을 때 레슨 2 의 예상 가능한 오사용으로 직결되는 경로를 그린다. 이것을 사용성 문제가 아니라 안전 문제 로 올리는 보고 문장을 쓴다
4. 사용자 설정 유지 를 확인하는 시험을 설계한다. 안전·편의에 걸린 항목 (좌석·거울·보조 기능 설정) 을 포함한다
5. 전달 방식이 충분한지 는 사용적합성 평가 영역임을 표시하고 모듈 49 로 넘긴다

과제 6 — 갱신 경로 조합 (30분)

1. 본문의 다섯 축으로 조합 공간을 정의한다. 기존 버전을 5개 두고 전수 조합 수를 계산한다
2. 지원 경로 목록 이 명세에 있는지 확인하는 질문을 쓴다. 없으면 무엇을 시험해야 하는지 모른다는 것을 적는다
3. 순차 갱신이 필요한 경로 를 하나 설정하고, 사용자가 그것을 아는지 확인하는 시험을 설계한다
4. 지원하지 않는 경로를 시도하는 시험을 설계한다. 거부가 깔끔한지, 시도하다 부분 갱신 상태가 되는지 확인한다. 후자가 가장 위험한 이유를 적는다
5. 레슨 4 의 세 근거(점유·위험·경계) 로 대표 경로 12개 를 고른다. 경계 로 가장 오래된 지원 버전, 지원 경계 직전, 미지원 버전을 반드시 포함한다
6. 개발 환경 차량이 대개 최신 버전이라 오래된 경로가 시험되지 않는 문제를 적고, 그것을 막는 방법을 제안한다

과제 7 (선택) — 경계 확인표 (15분)

1. 본문의 범위 표를 확장해 이 레슨과 모듈 35 레슨 8·모듈 50·모듈 46 레슨 7 의 담당을 항목 10개로 가른다
2. 겹치는 항목을 표시하고, 겹칠 때 어느 쪽이 주관인지 적는다
3. 어느 쪽에도 담당이 적히지 않은 항목이 있으면 질의로 만든다

자가 체크리스트

• 이 레슨이 차량 상태 전제와 사용자 경험을 맡고, 규정·보안은 다른 레슨임을 안다
• 서버 배포와 차량 OTA 의 여섯 가지 차이를 들 수 있다
• 판정 기준이 "성공했는가" 가 아니라 "실패해도 차가 움직이는가" 인 이유를 안다
• 갱신 전제 조건 여덟 축을 들 수 있고 기준값은 요구사항에서 옴을 안다
• 조건을 시작 시점에만 확인하면 가장 위험한 상황이 만들어지는 이유를 안다
• 지속 감시·조건 깨짐 처리·운전자 이동 시도 세 질문을 할 수 있다
• 운전자 이동 시도에 대한 세 설계 선택과 각각이 보장해야 하는 것을 안다
• 명세에 처리가 없으면 구현이 임의로 정해져 있다는 뜻임을 안다
• 제어기 여럿을 갱신할 때 부분 갱신 상태가 만들어지는 구조를 설명할 수 있다
• 부분 갱신에 대한 네 질문을 들 수 있다
• 버전 조합 호환성 정의가 없으면 판정할 수 없다는 것을 안다
• "모든 복구 실패 시에도 움직이는가" 가 최후 방어선이며 그 요구를 확인하는 것이 QA 의 일임을 안다
• 되돌리는 중 다시 실패하는 이중 실패도 시험 대상임을 안다
• 중단 지점 여덟 가지를 들 수 있고 부분 갱신 상태를 반드시 포함한다
• 중단 만들기에서 소프트웨어 계층과 전원·통신 조작을 가르고 후자는 승인 전제임을 안다
• 사용자 경험 여섯 영역을 들 수 있다
• 동의 범위가 이 갱신에 맞는지 확인해야 하는 이유를 안다
• 예약 실패를 조용히 넘기면 사용자가 갱신된 줄 아는 경로를 설명할 수 있다
• 남은 시간 표시가 실제와 다르면 사용자가 중단을 시도한다는 것을 안다
• 실패 안내를 "사용자가 할 행동이 적혀 있는가" 로 검토할 수 있다
• 제약 안내에 "언제까지" 가 필요한 이유를 안다
• 기능 변화·ODD 변화 다섯 가지를 들 수 있다
• ODD 축소를 사용자가 모를 때의 두 결과를 알고, 의존하는 쪽이 더 위험한 이유를 안다
• 기능 거동 변경 미전달이 안전 문제이며 SOTIF 오사용으로 직결됨을 안다
• 갱신 후 사용자 설정 유지가 안전·편의 항목을 포함한다는 것을 안다
• 갱신 경로 조합 다섯 축과 기존 버전 축이 특히 문제인 이유를 안다
• 지원 경로 목록이 없으면 무엇을 시험할지 모른다는 것을 안다
• 미지원 경로 시도에서 거부가 깔끔한지 확인해야 하는 이유를 안다
• 개발 환경 차량이 최신이라 오래된 경로가 시험되지 않는 문제를 안다
• 실차 갱신·전원 조작을 QA 가 임의로 하지 않는다는 원칙을 안다

흔한 실수

서버 배포처럼 다룬다. "실패하면 다시 하면 된다" 는 전제가 깨진다. 차량 갱신 실패는 견인과 정비소 작업이 될 수 있다.

조건을 시작 시점에만 확인한다. 설치 중에 운전자가 차를 움직이려 하는 상황이 빠지고, 그것이 가장 위험하다.

운전자 이동 시도 처리를 명세에 두지 않는다. 구현이 임의로 정하게 되고, 막는 것도 중단하는 것도 각각 보장해야 할 것이 있다.

부분 갱신 상태를 시험하지 않는다. 제어기 여럿을 건드리는 갱신에서 중간 실패는 반드시 발생한다.

버전 조합 호환성을 정의하지 않는다. 부분 갱신 상태를 판정할 수 없고, 그러면 그 상태로 운행된다.

"모든 복구 실패 시" 요구를 확인하지 않는다. 최후 방어선이 없으면 차가 움직이지 못하는 상태가 만들어질 수 있다. 요구가 있는지 묻는 것이 QA 의 일이다.

롤백이 성공한다고 가정한다. 되돌리기도 쓰기 작업이고 실패할 수 있다. 이중 실패를 설계한다.

다운로드 중단 후 부분 파일을 확인하지 않는다. 저장 공간이 부분 파일로 차고, 다음 갱신이 공간 부족으로 실패한다.

검증 실패와 중단을 같게 처리한다. 원인이 다르고 대응도 달라야 한다.

한 번 받은 동의를 모든 갱신에 쓴다. 갱신 내용이 달라지면 동의 범위를 벗어날 수 있다.

예약 실패를 조용히 넘긴다. 사용자는 갱신된 줄 알고, 실제로는 옛 버전으로 운행한다.

실패 안내를 "업데이트 실패" 로 끝낸다. 사용자가 무엇을 해야 할지 모르고, 정비소 문의가 쏟아진다. 할 행동이 적혀 있어야 한다.

제약 안내에 "언제까지" 를 안 적는다. 차를 못 움직이는 상태를 사용자가 고장으로 인식한다.

기능 거동 변경을 알리지 않는다. 운전자가 이전 거동을 전제로 운전한다. 사용성 문제가 아니라 안전 문제다.

ODD 축소를 조용히 반영한다. 사용자가 이전 범위에서 작동한다고 믿고 의존하면 가장 위험하다.

갱신 후 사용자 설정 초기화를 사소하게 본다. 차량에서는 좌석·거울·보조 기능 설정이 안전·편의에 걸린다.

최신 버전에서만 갱신을 시험한다. 개발 환경 차량은 대개 최신이고, 실제로는 오래된 버전에서 올라오는 경로가 가장 깨지기 쉽다.

미지원 경로를 시도했을 때를 시험하지 않는다. 시도하다 실패하면 부분 갱신 상태가 된다. 거부가 깔끔한지 확인한다.

실차 갱신 시험을 임의로 한다. 차량이 움직이지 못할 수 있고, 전원 조작은 승인과 안전 조치가 전제다.

참고 자료

• 우리 시스템의 OTA 요구사항 명세 — 전제 조건 기준값, 안전 상태 정의, 지원 갱신 경로, 사용자 안내 요구. 이 레슨이 수치를 적지 않은 모든 항목의 정본이다(원문 확인)
• 버전 조합 호환성 문서 — 부분 갱신 상태 판정의 기준. 비어 있으면 그 공백이 설계 지적 대상이다
• 차량 전기·전원 사양 — 배터리 조건과 급전 관련 제약(원문 확인)
• 제어기 부트로더·갱신 설계 문서 — A/B 구성, 되돌리기 가능 지점 (모듈 46 레슨 7 참조, 원문 확인)
• 조직의 실차 시험 절차서 — 갱신 시험의 승인과 안전 조치. 읽기 전에 차량 영역에 들어가지 않는다
• 모듈 35 레슨 8 — UNECE R155·R156: 규정·체계·식별·심사 증거와 거부 동작 검증
• 모듈 46 레슨 7 — 펌웨어 업데이트와 현장 증거: 부트로더·A/B·롤백의 일반형
• 모듈 46 레슨 6 — 장애 주입: 전원·통신 조작의 기법과 안전 원칙
• 모듈 65 레슨 2 — SOTIF: ODD 변화와 예상 가능한 오사용
• 모듈 65 레슨 4 — 조합 설계: 갱신 경로 대표 선정
• 모듈 65 레슨 5 — IVI: 갱신되는 소프트웨어의 한 축, 설정 유지
• 모듈 49 — 사용성·접근성: 안내가 실제로 전달되는지의 평가
• 모듈 50 — 보안 테스팅: 공격 기법은 이 모듈이 아니라 그쪽이 맡는다