AUTOSAR 계층 구조와 기본 소프트웨어(BSW) 설정 검증

개념

이 환경에서 결함은 코드가 아니라 설정에 있다

레슨 1~9 는 코드를 쓰고 하드웨어를 만지는 임베디드를 다뤘다. AUTOSAR 환경은 성격이 다르다. 통신·진단·메모리 같은 기본 기능은 표준화된 모듈로 이미 제공 되고, 개발 작업의 상당 부분이 그 모듈들을 설정하는 일 이다.

그래서 결함의 분포가 바뀐다.

QA 에게 이것이 뜻하는 바는 분명하다. 설정을 검증 대상으로 다루지 않으면 결함의 대부분을 보지 못한다. 코드 리뷰만 하고 설정은 "도구가 생성하니까 맞겠지" 로 넘기는 것이 이 환경에서 가장 큰 공백이다.

계층 구조 — 어느 층의 문제인지 가른다

AUTOSAR 클래식 플랫폼의 공개 문서는 최상위 추상 수준에서 소프트웨어를 응용(Application)·실행 환경(RTE)·기본 소프트웨어(BSW) 세 층으로 구분하고, 그 아래에서 마이크로컨트롤러가 돈다고 설명한다. 그리고 BSW 는 다시 서비스(Services)·ECU 추상화(ECU Abstraction)·마이크로컨트롤러 추상화(MCAL)· 복합 드라이버(Complex Drivers) 로 나뉜다.

┌─────────────────────────────────────────┐
│  응용 계층 (소프트웨어 컴포넌트)          │  ← 우리가 만드는 기능
├─────────────────────────────────────────┤
│  RTE (실행 환경)                         │  ← 컴포넌트 간 통신을 중개
├─────────────────────────────────────────┤
│  BSW  ┌ 서비스 계층                      │  ← OS·통신·진단·메모리·ECU 상태
│       ├ ECU 추상화 계층                  │  ← MCU 내외 장치에 일관된 접근
│       ├ MCAL (마이크로컨트롤러 추상화)   │  ← MCU 의존 드라이버
│       └ 복합 드라이버                    │  ← 표준 계층에 안 맞는 특수 하드웨어
├─────────────────────────────────────────┤
│  마이크로컨트롤러                         │
└─────────────────────────────────────────┘

공개 문서가 설명하는 각 층의 역할은 이렇다.

• MCAL — MCU 가 제공하는 기능의 표준 드라이버를 담는다. 비휘발성 메모리, 통신(CAN·LIN·이더넷·FlexRay), 입출력(ADC·PWM·핀) 등. 목적은 상위 계층이 하드웨어에 독립적이게 하는 것 이어서, MCAL 모듈은 하드웨어 의존이고 상위 계층은 독립이다
• ECU 추상화 계층 — MCU 안팎의 기능에 일반적인 방식으로 접근 하게 한다. 워치독 인터페이스, 메모리 인터페이스, 통신·입출력 서비스 인터페이스가 여기 있다
• 서비스 계층 — BSW 의 최상위로, 응용과 다른 BSW 모듈에 기본 서비스를 제공한다. OS(태스크 스케줄링), 통신 스택, 진단 스택, 메모리 스택, ECU 상태 관리가 여기 든다
• 복합 드라이버 — 표준 계층 구조에 맞지 않는 특수 하드웨어 기능을 다룬다
• RTE — 응용 소프트웨어에 통신 서비스를 제공하고, 컴포넌트가 특정 ECU 배치에 독립적 이게 한다

계층 구조·모듈 이름·각 층의 정확한 역할 정의는 AUTOSAR 가 공개한 계층 소프트웨어 아키텍처 문서에서 확인한다(원문 확인). 릴리스에 따라 구성과 모듈 목록이 바뀐다.

QA 가 계층을 아는 이유 — 결함의 책임 소재

계층을 읽을 수 있으면 "이 현상이 어느 층의 문제인가" 를 물을 수 있다. 이것이 레슨 1 에서 다룬 계층 지도와 같은 가치이고, 모듈 62 레슨 1 의 공장 계층 지도와 같은 발상이다.

오른쪽 열이 QA 의 작업 이다. 각 현상마다 층을 가르는 관측 이 정해져 있고, 그 관측 없이 추측으로 올라가면 책임 소재 논쟁이 길어진다.

설정이 코드가 되는 흐름 — 검증 지점은 어디인가

AUTOSAR 환경의 작업 흐름은 설정 → 생성 → 빌드 다. 설정은 표준 교환 형식 파일로 관리되고, 생성 도구가 그 설정에서 코드를 만든다.

[설정 파일(ARXML 등)]
      │  ① 설정 자체가 맞는가
      ↓
[생성 도구]
      │  ② 생성이 성공했는가, 경고를 무시하지 않았는가
      ↓
[생성된 코드 + 손으로 쓴 코드]
      │  ③ 생성 결과가 설정과 일치하는가
      ↓
[빌드 결과]
      │  ④ 대상에서 동작이 설정대로인가
      ↓
[동작]

네 지점 각각이 검증 대상이고, ①과 ②가 가장 저평가되어 있다.

① 설정 자체의 검증. 설정 파일은 사람이 읽기 어렵고 양이 많아서, 대개 도구 화면으로만 본다. 그런데 결함은 여기 있다 — 신호 길이가 1비트 어긋나고, 주기가 10 ms 가 아니라 100 ms 이고, 블록 크기가 부족하다. 설정 값을 상위 명세(통신 매트릭스·진단 명세·요구사항) 와 대조하는 작업 이 QA 가 할 수 있는 가장 직접적인 기여다. 수가 많으므로 자동 대조 가 답이다 — 설정 파일을 파싱해 명세와 비교한다.

② 생성 경고 무시. 생성 도구는 경고를 쏟아낸다. "이 설정은 권장되지 않습니다", "참조가 해결되지 않았습니다". 양이 많아 무시하는 관행이 생기고, 그 안에 진짜 문제가 섞인다. 경고 목록을 기준선으로 관리 하고 새로 생긴 경고만 보게 만드는 것이 실무적 해법이다. 모듈 14 레슨 5 의 거짓 경보 줄이기와 같은 구조다.

③ 생성 결과 대조. 생성 코드를 사람이 읽는 것은 비효율적이지만, 특정 값이 설정대로 들어갔는지 는 확인할 수 있다. 신호 매핑, 주기 상수, 버퍼 크기 같은 핵심 값을 골라 자동 확인한다.

④ 동작 확인. 가장 익숙한 영역이고, 레슨 3·4 의 버스 관측과 레슨 9 의 타이밍 측정이 쓰인다. 다만 ①~③을 건너뛰고 ④만 하면 결함을 늦게·비싸게 발견한다.

설정 불일치의 전형 — 통신 스택

레슨 3 에서 CAN·DBC 를 다뤘다. AUTOSAR 통신 스택에서는 같은 정보가 설정으로 들어가고, 불일치가 전형적인 모양으로 나타난다.

두 번째가 가장 늦게 발견된다. 바이트 순서가 뒤집혔는데 시험 값이 작으면 두 해석이 비슷한 값이 되어 통과한다. 큰 값을 넣어야 드러난다. 경계값과 큰 값을 시험 데이터에 반드시 포함 하는 이유다.

다섯 번째도 흔하다. 타임아웃 값이 주기보다 짧으면 정상 통신에서 고장 판정이 나고, 너무 길면 끊김을 늦게 잡는다. 주기와 타임아웃의 관계 를 설정 대조 항목에 반드시 넣는다.

설정 불일치의 전형 — 진단과 메모리

진단 스택 쪽은 모듈 46 레슨 3 의 UDS 와 이어진다. 설정에서 오는 전형적 문제다.

• 서비스·서브기능 지원 설정 과 명세 불일치 → 지원해야 할 요청에 부정 응답
• 세션·보안 수준 조건 설정 오류 → 보호해야 할 기능이 열려 있거나, 정상 접근이 거부된다. 전자가 보안 문제 이므로 반드시 시험한다
• 고장 코드(DTC) 설정 — 성숙 조건, 치유 조건, 저장 조건. 설정이 명세와 다르면 고장이 기록되지 않거나 지워지지 않는다
• 응답 시간 제약 — 긴 처리에 대한 응답 지연 처리가 설정되어 있는가

메모리 스택 쪽은 이렇다.

• 블록 크기와 개수 — 부족하면 저장이 실패한다. 실패가 상위에 전달되는지 확인
• 쓰기 주기·트리거 — 전원이 꺼질 때 저장되는가. 레슨 6 의 전원 장애 주입과 연결
• 마모 평준화·중복 저장 설정 — 수명과 복구에 영향
• 초기값·기본값 — 첫 기동이나 블록 손상 시 무엇이 들어가는가

"저장 실패가 상위에 전달되는가" 가 가장 중요한 질문 이다. 조용히 실패하면 설정이 저장된 줄 알고 운영하다가 재기동에서 잃는다. 모듈 39 레슨 11 의 용량 소진, 모듈 62 레슨 5 의 버퍼 한계와 같은 구조다.

OS 설정과 타이밍 — 레슨 9 와 이어진다

서비스 계층의 OS 가 태스크 스케줄링을 맡는다. 설정에서 정하는 것이 태스크·주기·우선순위·매핑 이고, 그것이 곧 레슨 9 의 응답 시간 분석 입력이다.

QA 가 대조할 항목이 분명하다.

• 설정상 태스크 목록·주기·우선순위 vs 분석에 들어간 값
• 설정상 주기 vs 실제 관측 주기(레슨 4 의 관측 수단)
• 응용 컴포넌트가 어느 태스크에 매핑되었는가 vs 설계 의도
• 인터럽트 설정과 우선순위 vs 분석에 들어간 인터럽트 부하

세 번째가 자주 어긋난다. 컴포넌트의 실행 가능 단위가 의도와 다른 태스크에 매핑되면 주기가 달라지고, 그것이 간헐적 타이밍 문제로 나타난다. 설정 대조로만 잡히는 결함이다.

변경이 전체를 흔든다

AUTOSAR 환경의 변경 관리에는 특유의 성질이 있다. 설정 한 곳을 바꾸면 생성 결과가 넓게 바뀐다. 신호 하나를 추가하면 통신 설정·RTE·응용 인터페이스가 함께 바뀌고, 태스크 주기를 바꾸면 타이밍 분석이 다시 돌아간다.

그래서 변경 영향 판정이 코드 변경보다 넓게 잡혀야 한다. 축은 이렇다.

마지막 두 줄이 가장 비싸다. 도구나 BSW 버전이 올라가면 생성 결과가 달라질 수 있고, 그 차이를 사람이 다 읽을 수 없다. 생성 결과를 형상 관리에 넣고 버전 간 차분을 보는 것 이 실무적 대응이다. 차분이 예상 범위를 넘으면 조사한다.

이 변경 관리의 성격은 모듈 35 레슨 8(R155·R156 의 영향 판정), 모듈 40 레슨 7 (설계 변경), 모듈 33 레슨 7(인증 버전) 과 같은 모양이다 — 규제·표준 환경의 변경 관리는 전부 "넓게 보고 근거를 남긴다" 로 수렴한다.

QA 가 만들 산출물

정리하면 넷이다.

1. 설정-명세 대조표와 자동 대조 — 통신 매트릭스·진단 명세·요구사항과 설정 값을 비교. 항목이 많으므로 자동화가 전제
2. 생성 경고 기준선 — 현재 경고 목록을 기준으로 두고 새 경고만 본다
3. 층을 가르는 관측 절차 — 현상별로 어느 관측을 해 어느 층을 배제하는가
4. 변경 영향 판정표 — 설정 변경 유형별 재검증 범위

1번이 이 환경에서 QA 가 만드는 가장 가치 높은 것 이다. 설정 값은 수천 개이고, 사람이 화면으로 확인하는 방식으로는 덮을 수 없다. 명세를 기계가 읽을 수 있는 형태로 두고 설정과 비교하는 구조를 만들면, 그 뒤로는 변경마다 자동으로 돈다.

실무에서 왜 필요한가

국내 자동차 전자 부품 조직에서 AUTOSAR 기반 개발이 보편화되면서, QA 가 겪는 전형적 좌절이 있다. 코드 리뷰를 할 코드가 적다. 대부분이 생성 코드이고, 손으로 쓴 부분은 응용 로직 일부다. 그래서 익숙한 방식으로는 할 일이 없어 보이고, 결국 동작 시험(④ 지점) 만 하게 된다.

그 결과가 설정 결함을 늦게 발견하는 것 이다. 신호 비트 위치가 어긋난 것을 통합 시험에서 버스 관측으로 발견하면, 그때까지의 모든 시험이 잘못된 전제에서 돌았을 수 있다. 설정 대조로는 착수 단계에 잡힌다.

그래서 이 환경에서 QA 의 역할이 바뀐다. 설정을 명세와 대조하는 자동화를 만드는 것 이 핵심 작업이 되고, 그것은 전형적인 QA 역량이다 — 명세를 읽고, 판정 가능한 비교로 바꾸고, 결과가 0건이면 통과인 검사를 쌓는 일. 모듈 61 레슨 2 의 정합성 조회, 모듈 62 레슨 4 의 대조 지점과 같은 발상을 설정 파일에 적용하는 것이다.

두 번째 기여는 층을 가르는 관측 이다. "CAN 이 안 나갑니다" 라는 보고가 오면 응용·스택·MCAL·하드웨어 사이에서 책임 소재 논쟁이 벌어진다. 관측으로 층을 배제해 가는 절차를 가진 QA 가 있으면 그 논쟁이 짧아진다.

실습 과제

설정 항목 이름·릴리스별 구성·도구 사용법은 공식 문서와 사용 중인 도구 문서에서 확인한다(원문 확인). 과제는 구조와 절차를 설계하는 것이 목표다.

과제 1 — 계층 지도와 층 가르기 절차 (25분)

1. 본문의 계층도를 직접 그리고, 각 층의 역할을 한 줄씩 자기 말로 쓴다. 모듈 이름과 정확한 역할 정의는 원문 확인 표시를 둔다
2. 본문의 표를 확장해 현상 10개 에 대한 층 가르기 절차를 만든다
3. 각 절차는 "어떤 관측을 해서 어느 층을 배제하는가" 를 단계로 적는다. 레슨 3·4 의 관측 수단을 어디서 쓰는지 명시한다
4. 관측으로 배제할 수 없는 현상이 있으면 따로 표시하고, 그때 쓸 방법을 적는다

과제 2 — 설정-명세 대조표 설계 (35분)

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

1. 가상의 통신 명세 를 만든다. 신호 10개에 대해 프레임 ID, 비트 위치, 길이, 바이트 순서, 스케일, 오프셋, 주기, 수신 타임아웃을 적는다
2. 같은 신호들에 대한 설정 값 을 만들되 의도적으로 5곳을 틀리게 한다. 본문의 여섯 불일치 유형을 섞어 넣는다
3. 대조 규칙 을 판정 가능한 형태로 쓴다. 결과가 0건이면 통과인 형태로
4. 규칙으로 틀린 5곳을 모두 찾아내는지 확인한다. 못 찾는 것이 있으면 규칙을 보강한다
5. 주기와 타임아웃의 관계 를 검사하는 규칙을 반드시 넣는다
6. 이 대조를 자동화 하려면 무엇이 필요한지 적는다 — 명세를 기계가 읽는 형태로 두는 방법, 설정 파일을 파싱하는 방법, 결과를 보고하는 형태
7. 항목이 수천 개일 때 사람이 화면으로 확인하는 방식이 왜 실패하는지 한 문단 쓴다

과제 3 — 바이트 순서 결함을 드러내는 시험 데이터 (20분)

1. 바이트 순서가 뒤집힌 신호를 가정하고, 작은 값에서는 통과하는 이유를 비트 수준으로 설명한다
2. 그 결함을 반드시 드러내는 시험 값 집합 을 설계한다. 경계값과 큰 값을 포함하고, 각 값이 어떤 결함을 드러내는지 적는다
3. 같은 방식으로 스케일·오프셋 오류 를 드러내는 값을 설계한다 (비율로 일정하게 틀리는 성질을 이용한다)
4. 이 시험 값들을 통신 시험의 표준 데이터 세트 로 만든다

과제 4 — 진단·메모리 설정 검증 (30분)

1. 진단 — 본문의 네 항목에 대해 각각 시험 케이스를 쓴다. 보안 수준 조건 항목에는 "보호해야 할 기능이 열려 있는가" 를 반드시 넣고, 그것이 보안 문제인 이유를 적는다. UDS 시험 절차는 레슨 3 을 참조한다
2. 고장 코드 의 성숙·치유·저장 조건을 시험하는 방법을 설계한다. 조건을 만드는 수단(레슨 6 의 장애 주입) 을 지정한다
3. 메모리 — 블록 설정 대조표를 만든다. 블록 크기 총합이 가용 용량을 넘지 않는지 확인하는 규칙을 넣는다
4. "저장 실패가 상위에 전달되는가" 시험을 설계한다. 실패를 만드는 방법과 기대 동작, 조용히 실패할 때의 증상을 적는다
5. 전원 차단 시 저장 동작 시험을 설계한다. 전원 조작은 승인과 안전 조치가 전제 임을 명시한다(레슨 6)

과제 5 — OS 설정 대조와 생성 흐름 검증 (30분)

1. OS 설정 대조표 를 만든다. 본문의 네 항목을 열로 두고, 설정 값과 분석 입력값·관측값을 나란히 적게 한다
2. 컴포넌트 매핑 대조를 특히 공들여 쓴다. 의도한 태스크와 실제 매핑이 어긋났을 때의 증상과, 그것이 설정 대조로만 잡히는 이유를 적는다
3. 생성 경고 기준선 운영을 설계한다. 현재 경고를 기준선으로 두는 방법, 새 경고만 보는 방법, 기준선을 갱신하는 조건
4. 생성 결과 대조 항목을 정한다. 생성 코드에서 확인할 핵심 값 5개를 고르고 (신호 매핑, 주기 상수, 버퍼 크기 등) 자동 확인 방법을 적는다
5. 생성 코드를 형상 관리에 넣고 버전 간 차분 을 보는 운영을 설계한다. 차분이 예상 범위를 넘었을 때의 처리를 적는다

과제 6 — 변경 영향 판정표 (25분)

1. 본문의 여섯 변경 유형으로 판정표를 만들고, 각각의 재검증 범위를 적는다
2. MCAL·MCU 변경 과 도구·BSW 버전 변경 에 대해 특히 구체적으로 쓴다. 왜 가장 비싼지와, 생성 결과 차분 대조가 왜 필요한지 설명한다
3. 변경 유형 4개를 더 추가한다
4. 판정 결과에서 재검증 범위를 도출하는 규칙 을 쓴다
5. 이 환경의 변경 관리가 m35-l08·m40-l07·m33-l07 과 같은 모양("넓게 보고 근거를 남긴다") 이라는 것을 한 문단으로 정리한다

자가 체크리스트

• 이 환경에서 결함의 상당 부분이 설정에 있다는 것과, 그 함의를 설명할 수 있다
• 코드 리뷰만 하고 설정을 넘기는 것이 가장 큰 공백인 이유를 안다
• 응용·RTE·BSW 세 층과 BSW 의 네 하위 계층을 들 수 있다
• MCAL 의 목적이 상위 계층의 하드웨어 독립성이라는 것을 설명할 수 있다
• ECU 추상화 계층과 서비스 계층의 역할 차이를 말할 수 있다
• RTE 가 컴포넌트의 ECU 배치 독립성을 만든다는 것을 안다
• 계층·모듈 구성이 릴리스에 따라 바뀌므로 공개 문서 확인이 필요함을 안다
• 현상별로 어느 층을 의심하고 어떤 관측으로 가르는지 설계할 수 있다
• 설정 → 생성 → 빌드 → 동작 흐름의 네 검증 지점을 들 수 있다
• ①설정 대조와 ②생성 경고가 가장 저평가되어 있다는 것을 안다
• 설정 값이 수천 개여서 자동 대조가 전제라는 것을 설명할 수 있다
• 생성 경고를 기준선으로 관리해 새 경고만 보는 운영을 설계할 수 있다
• 통신 설정 불일치 여섯 유형과 각각의 증상을 짝지을 수 있다
• 바이트 순서 오류가 작은 값에서 통과하는 이유와, 큰 값·경계값이 필요한 이유를 안다
• 주기와 수신 타임아웃의 관계를 대조 항목에 넣어야 하는 이유를 안다
• 진단 설정에서 보안 수준 조건 오류가 보안 문제인 이유를 설명할 수 있다
• 고장 코드의 성숙·치유·저장 조건을 시험 대상으로 다룰 수 있다
• 메모리 스택에서 "저장 실패가 상위에 전달되는가" 가 가장 중요한 질문인 이유를 안다
• OS 설정이 레슨 9 의 분석 입력이라는 연결을 안다
• 컴포넌트 매핑 어긋남이 설정 대조로만 잡히는 결함인 이유를 설명할 수 있다
• 설정 변경이 생성 결과를 넓게 바꾸므로 영향 판정이 넓어야 함을 안다
• MCAL·MCU 변경과 도구·BSW 버전 변경이 가장 비싼 이유를 안다
• 생성 결과를 형상 관리에 넣고 버전 간 차분을 보는 운영의 필요를 안다
• QA 산출물 넷을 들고, 설정-명세 자동 대조가 가장 가치 높은 이유를 말할 수 있다

흔한 실수

설정을 검증 대상에서 뺀다. "도구가 생성하니 맞겠지" 로 넘기면 결함의 상당 부분을 보지 못한다. 이 환경에서 가장 큰 공백이다.

동작 시험만 한다. ①~③을 건너뛰고 ④만 하면 결함을 통합 단계에서 발견하고, 그때까지의 시험이 잘못된 전제에서 돌았을 수 있다.

설정을 화면으로 눈으로 확인한다. 항목이 수천 개다. 사람이 덮을 수 없고, 덮었다고 믿는 상태가 더 위험하다. 자동 대조를 만든다.

생성 경고를 전부 무시한다. 양이 많아 무시하는 관행이 생기고 진짜 문제가 섞인다. 기준선을 두고 새 경고만 본다.

바이트 순서를 작은 값으로만 시험한다. 두 해석이 비슷한 값이 되어 통과한다. 큰 값과 경계값을 표준 데이터 세트에 넣는다.

주기만 보고 타임아웃을 안 본다. 타임아웃이 주기보다 짧으면 정상 통신에서 고장 판정이 난다. 관계로 검사한다.

진단의 보안 수준 조건을 시험하지 않는다. 보호해야 할 기능이 열려 있는 상태가 운영에 나갈 수 있다. 이것은 보안 문제다.

저장 실패의 전달을 확인하지 않는다. 조용히 실패하면 저장된 줄 알고 운영하다가 재기동에서 잃는다.

컴포넌트 매핑을 확인하지 않는다. 의도와 다른 태스크에 매핑되면 주기가 달라지고 간헐적 타이밍 문제가 된다. 설정 대조로만 잡힌다.

설정 변경을 코드 변경처럼 좁게 판정한다. 신호 하나가 통신 설정·RTE·응용 인터페이스·수신 타임아웃·버스 부하를 함께 건드린다.

도구·BSW 버전을 올리고 전체를 다시 보지 않는다. 생성 결과가 달라질 수 있고 사람이 다 읽을 수 없다. 형상 관리와 차분 대조가 필요하다.

MCAL·MCU 변경을 부분 재검증으로 끝낸다. 하위 계층 변경은 상위로 번진다.

명세를 사람이 읽는 문서로만 둔다. 자동 대조를 만들려면 명세가 기계가 읽을 수 있는 형태여야 한다. 그 전환을 요청하는 것이 QA 의 일이다.

참고 자료

• AUTOSAR 가 공개한 계층 소프트웨어 아키텍처 문서 — 계층 구분, BSW 하위 계층, 각 층의 역할 정의, 모듈 목록. 릴리스에 따라 바뀌므로 해당 릴리스 문서를 확인한다(계층·모듈 구성 — 원문 확인)
• 사용 중인 BSW 공급사와 설정 도구의 문서 — 설정 항목 이름, 생성 흐름, 경고의 의미, 설정 파일 구조. 실무에서 가장 자주 보는 문서다(원문 확인)
• 프로젝트의 통신 매트릭스와 진단 명세 — 설정 대조의 기준이 되는 상위 명세. 기계가 읽을 수 있는 형태로 관리되는지 확인한다
• 대상 MCU 의 레퍼런스 매뉴얼 — MCAL 설정이 하드웨어 제약과 맞는지 확인할 때
• 모듈 46 레슨 3 — CAN·UDS 진단: 통신·진단 설정 검증의 관측 수단
• 모듈 46 레슨 4 — 오실로스코프·로직 분석기: 층을 가르는 관측
• 모듈 46 레슨 6 — 장애 주입: 전원 차단·통신 두절 조건을 만드는 수단과 안전 원칙
• 모듈 46 레슨 9 — RTOS 스케줄링과 WCET: OS 설정이 분석 입력으로 들어간다
• 모듈 14 레슨 5 — 거짓 경보 줄이기: 생성 경고 기준선 운영의 일반형
• 모듈 61 레슨 2 — 정합성 조회: 설정 대조를 "0건이면 통과" 로 쓰는 발상
• 모듈 62 레슨 4 — 대조 지점: 같은 구조의 제조 환경 적용
• 모듈 35 레슨 8 — R155·R156 변경 영향 판정: 같은 모양의 변경 관리