구현보다 먼저 '어떤 조건에서 무엇을 통과할지' 정한다
'센서를 빨리 읽고 모터를 안전하게 제어한다'는 문장으로는 서로 다른 구현을 같은 기준으로 비교하기 어렵다. 빠르다는 것이 표본 간격인지, 계산 완료인지, 실제 축의 도달 시간인지 불명확하기 때문이다. 초기 상태·통신 오류·관측 누락 때 무엇을 하는지도 빠져 있다.
요구사항은 주체·조건·행동/결과·단위/한계·판정 근거를 묶어 적는다. NASA 요구사항 작성 안내의 검증 가능성·인터페이스/성능 조건을 참고한다. 한 문장에 서로 다른 의무를 넣으면 실패 원인을 나누기 어려우므로 ID로 분리하고 상위 목적·설계/시험과 연결한다. 문서가 구체적이라는 사실과 실제 시스템이 그 요구를 충족했다는 증거는 다르다.
이 단위는 가상 단일축 속도 제어의 종이 설계/제공 기록 분석이다. 실제 제품의 적절한 주기/안전 한계나 보드 사양을 제안하는 것이 아니다. 다음 단원의 균형 로봇에는 관측/동역학·전력·제어 요구를 새로 세워야 하며 여기 숫자를 복사하지 않는다.
네 요구를 서로 다른 근거로 판정한다
가상 요구 개정R-A에서 장치 clock은mcuB7/ms, 명령 단위는rad/s·sensor_shaft의+z, 명령 허용 범위는±20rad/s라고 준다. M04의 계약을 재사용하지만 통합 계층에서 오류 후 차단 정책을 명시적으로 추가한다.
| 요구 ID | 조건과 판정 |
|---|---|
| R1 주기 | 정상 스케줄 구간의 연속 release 간격은10ms±0.2ms. 같은 장치 clock의 release 기록으로 비교 |
| R2 제출 마감 | 각 release 뒤2ms 이내에 유효 명령 제출 또는 명시적 차단 결정을 기록. 기한 초과 정상 명령은 폐기·차단/위반 기록. 제출은 물리 도달/정지 완료가 아님 |
| R3 관측/오류 | 원본 나이0~30ms·지원 단위/버전·정상 상태일 때만 새 정상 명령 허용. E_STALE/clock 불명/명령 만료는 INHIBITED로 전이·차단 결정 |
| R4 기동/회복 | 부팅은 IDLE/출력 허가 없음. 고장은 FAULT, 차단 뒤 일반 패킷으로 자동 재개하지 않음. 원인 해소/명시 확인 뒤 IDLE까지만 회복 |
R1은 release의 간격, R2는 release에서 결정 제출까지의 지연이다. 주기가10ms라고 계산을10ms까지 해도 된다는 뜻이 아니다. R3의 시간 통과만으로 센서 정확도/기구 상태·권한까지 통과했다고 해석하지 않는다. R4의 출력 불허도 소프트웨어 규칙이며 전력/관성·실제 정지는 관측/독립 검증이 별도다.
제공 기록을 계산해 요구와 연결한다
누락 없는 연속 네 release의 정상 스케줄 기록을0/10/20.2/30ms라고 주면 차이는10/10.2/9.8ms다. 허용 구간9.8~10.2ms의 양 끝을 포함하므로 이 세 간격은 R1에 맞는다. 시험한 구간이 네 release뿐이므로 모든 부하/실행에서 주기가 보장됐다고 보고하지 않는다. 누락 release가 있는지 확인할 ID/연속성 근거도 실제 기록에 필요하다.
별도 실행 기록에서 release100ms, 결정 제출101.1ms라면1.1ms로 R2의2ms 안이다.102.2ms라면2.2ms로 위반이다.102.2가 다음 release110보다 이르다는 이유로 통과시키면 주기와 마감을 혼동한다. 시각은 같은 clock/epoch에서 비교한다고 주었으며 서로 다른 호스트 시각은 직접 빼지 않는다.
관측 원본 시각969ms/now1000ms는31ms로 R3의30ms 한도 밖이다. 드라이버가 E_STALE을 보고하고, 이 통합 요구의 응용 감독은 INHIBITED/차단을 결정한다. M04.06의 드라이버가 오류를 돌려주는 일과 통합 정책이 상태를 바꾸는 일을 분리한다. 과거 정상값으로 현재 관측을 채우지 않는다. 나머지 CRC/schema/range 오류는 새 정상 명령을 거부하고 기존 상태/lease는 유지한다고 이 예제에서 정한다. 별도 고장/관측 무효·만료 조건은 여전히 우선한다.
각 기록에는 요구ID·원본/clock·판정/이유를 붙인다. 예를 들어 R2가 실패해도 R1의 제공 구간 결과를 지우지 않는다. 반대로 세 요구가 맞는다고 한 개의 실패를 평균 점수로 숨기지 않는다. 미확인 항목은 증거가 없으므로 통과 개수에 넣지 않는다.
HSI는 하드웨어와 소프트웨어가 만나는 명세다
HSI(Hardware–Software Interface)는 핀/전기 조건부터 데이터·시간·기동/오류 의미까지 양쪽이 합의하는 경계다. 함수 이름만 적거나 보드 사진만 첨부하면 호환 여부를 판단하기 어렵다.
그림 M26.01-1. 각 칸은 서로 다른 역할/근거다. 아래 방향은 자료/처리의 연결이며 실제 성공을 자동으로 보장하지 않는다. 직접 제작한 개념도이며 본문의 조건과 함께 읽는다.
| 경계 항목 | 가상 H1에 적을 내용 |
|---|---|
| 대상/전기 | 보드/부품 개정·커넥터/핀·방향·전원/논리 동작 범위·접지/시퀀스·미확인 조건 |
| 데이터 | 대상/주소·프레임/길이·bit/byte/부호·scale·단위/축·schema/보정 버전 |
| 시간 | 원본/수신 clock·epoch/단위·주기/지연·버퍼/누락·명령 유효 기간/기산점 |
| 상태/오류 | 부팅 허가·접수/거부·오류 코드/현재값 없음·과거값 분리·차단/회복의 주체 |
| 검증 | 각 조건의 출처·범위·확인 방법·지원 조합과 변경 시 재검토 대상 |
전기 조건의 가상 반례로 수신 핀의 입력 동작 허용 상한3.6V, 송신 출력5V가 제공됐다고 하자. 주소/패킷이 같아도 이 조합은 전기 동작 계약에 맞지 않는다. 여기서 임의 배선/레벨 변환 회로를 선택하거나 전원을 인가하지 않는다. 실제 부품의 동작 범위·입력 임계/출력 보장·절대최대/전류/시퀀스와 인터페이스를 확인해야 한다. 절대최대 정격을 정상 동작 허가로 취급하지 않는다.
소프트웨어에서는 'int16'만으로120이rpm인지0.01rad/s인지 알 수 없다. 원본 시각이 장치clock인지 호스트 수신clock인지도 HSI에 쓴다. 통신이 됐다는 사실은 전기적 여유·데이터 의미·현재 유효성을 모두 검증한 결과가 아니다.
기반 소프트웨어와 응용 정책의 책임을 나눈다
이 예제에서 BSW(Basic Software, 기반 소프트웨어)는 장치 접근/통신·시간원·원시값 변환/검사·오류 보고 등 공통 기반을 담당한다. ASW(Application Software, 응용 소프트웨어)는 제어 목표/알고리즘·명령 허용/감독·상태 전이 정책을 담당한다. 경계의 데이터/오류 계약이 같아야 각각을 바꾸고 시험할 수 있다.
가령 드라이버가 E_STALE과 원본 시각을 돌려주고 ASW가 R3에 따라 INHIBITED를 결정한다. 드라이버가 몰래 과거값을 정상으로 바꾸거나 ASW가 통신 버퍼/CRC 레지스터에 직접 의존하면 오류 의미와 변경 범위가 뒤섞인다. 실제 구현에서는 긴급 보호/하드웨어 차단 등 별도 계층이 필요할 수 있으며 이 두 이름만으로 안전 분리가 보장되지는 않는다.
AUTOSAR Classic 공식 소개는 application/RTE/BSW의 계층을 구분한다. RTE는 응용과 기반 사이의 인터페이스 역할을 한다. 여기의 교육용 책임 구분은 AUTOSAR 스택·RTE 생성기/OS를 구현하거나 준수했다는 뜻이 아니다. BSW/ASW를 사용한다고 일반 MCU 프로젝트가 자동으로 AUTOSAR가 되지도 않는다.
상태기계와 시간 예산을 같은 요구에 묶는다
M04.05의 IDLE/ACTIVE/INHIBITED/FAULT를 재사용하되 전이 조건/우선순위·이유를 통합 요구에 연결한다. 현재 예제는 고장 → 만료/관측 무효 → 새 명령 순으로 판단한다. R3의 무효 관측 처리처럼 추가한 정책은 요구/상태표 개정에 남긴다. 새 seq가 들어왔다는 이유로 차단을 해제하지 않는다.
한 release의 할당 예산을 취득0.2ms·필터0.3ms·제어0.4ms·드라이버 제출0.2ms로 두면 합계1.1ms다.2ms 제출 마감 대비0.9ms가 남는다. 이 숫자는 설계 배분이며 실제 실행의 최악 시간(WCET)을 측정/입증한 결과가 아니다. ISR/스케줄·동기화/대기·USB/버스·오류 처리와 부하 조건을 합쳐 검증해야 한다.
취득을1.3ms로 바꾸면 합계2.2ms, 마감 대비0.2ms 초과다. 여전히10ms 주기보다 짧지만 R2에는 맞지 않는다. 빠른 평균 측정만으로 최악 지연·누락/회복 구간을 보장하지 말고 근거 조건·최대/분포·미측정을 구분한다. 현재 R2는 기한을 넘긴 정상 명령을 폐기하고 차단/위반 기록을 남기는 정책이다. 실제 deadline 감시가 제때 실행되는지도 별도로 검증해야 한다.
형상은 소스 commit 하나보다 넓다
형상 관리(Configuration Management)는 어떤 요구/설계·구현/설정·시험 근거가 한 조합인지 식별하고 변경 영향을 추적하는 일이다. '동일 소스'여도 보드 revision/clock·보정/필터/이득·컴파일러/라이브러리·옵션이나 입력 데이터가 다르면 결과가 달라질 수 있다.
가상 기준 묶음에는 요구R-A/HSI H1, 보드B1/부품표·회로 개정, schemaS1/firmwareF2/calC3, source commit/수정 여부, build 환경/옵션과 firmware artifact 지문, 주기/clock·필터/제어/한도 설정, 입력/결과/판정 기록의 지문을 둔다. 사람이 읽는 별칭은 탐색용이고 실제 검증에는 해당 원본과 정확한 식별 근거가 필요하다. 여기의R-A/B1 등은 실제 파일 hash나 장비 기록이 아닌 제공 예제 이름이다.
Git describe 공식 문서는 tag/commit을 바탕으로 읽기 쉬운 이름을 만들고 dirty 표시로 작업 트리 변경을 나타내는 기능을 설명한다. 그런 이름만으로 외부 보정/빌드 산출물·보드까지 같은 것으로 보장하지 않는다. 전체 명세/산출물과 연결하고, 다른 환경에서 실제 재현했는지는 별도 기록한다. Git 언어/명령 입문을 여기서 반복하지 않는다.
주기를 바꾸면 무엇을 다시 검토해야 하는가
주기10→5ms는100→200Hz의 명목 빈도 변경이다. timer/clock·센서 갱신/전송량/큐, 필터 계수와 지연, 제어기의 이산화/이득·포화/성능, CPU/ISR 부하, 제출 마감/요구·시험 입력/판정과 관련 HSI를 다시 살펴야 한다. M07.03과 M07.04의 샘플링/지연 해석이 필요한 이유다.
모든 timeout/lease·관측 한도를 자동으로 절반으로 줄이는 규칙은 없다. 각 기한의 목적/시작 사건·허용 실패/물리 조건이 다르기 때문이다. 새 요구를 확정하고 영향받는 설계/시험을 갱신한 뒤 새 형상으로 검증한다. 이전10ms 결과는 그 조합의 이력으로 보존하고5ms 조합의 통과 근거로 재사용하지 않는다.
다음 제어/보드·재현 자료로 연결한다
기존 6장 배포·실증의 기본/실물 검증 범위를 구별하며 요구ID→HSI/설계→시험/원본→판정을 연결한다. 기본 완료는 제공 요구/기록의 계산과 모순·미확인을 설명하고 변경 영향을 적은 상태다. 실제 스케줄/보드·폐루프/장비의 요구 충족을 입증한 것은 아니다.
다음 M26.02 IMU·필터·균형 제어에서는 관측/부호·필터 지연과 제어 요구를 구체화한다. 이 단위의 가상 속도 제어 숫자를 균형 로봇의 검증된 설정으로 쓰지 않는다.