'통합 시험을 했다'보다 무엇을 비교했는지를 적는다
센서 값이 보이고 모터 명령 숫자가 생성됐다는 사실만으로 통합이 완료되지는 않는다. 어느 형상/요구에서 어떤 입력을 줬고, 어떤 계층의 결과/오류를 어느 시각 기준으로 비교했는지 필요하다. 실패/미확인을 지우고 마지막 좋은 화면만 남기면 조건과 결함을 설명하기 어렵다.
NASA Product Verification는 요구와 형상·방법/조건·결과/결함·재검증을 연결한다. Product Validation은 의도한 용도/환경·사용자 기대의 충족을 다룬다. 문서가 정리됐다고 제품의 두 검증이 끝난 것으로 표시하지 않는다.
이 단위의 기본 활동은 자체 가상 R-I/H-I와 후보C0의 제공 출력표 분석이다. 이 후보의 실제 실행 파일/펌웨어나 실행 로그는 제공하지 않았다. 수치/사례를 종이로 검토하는 일과 실제 코드/모델 실행·대상MCU·장비/폐루프 시험은 구분한다. 분석에서 찾은 불일치/미확인도 학습 산출물이며 실제 후보를 통과시키는 과제가 아니다.
이전 단위의 서로 다른 예제를 한 장비로 합치지 않는다
R-A의 단일축 속도, R-B의 균형/5ms 관문, R-UI의 접수/30ms 표시 예제는 다른 제공 계약이다. 숫자가 편리하다는 이유로 표본 나이/주기/명령 단위를 섞지 않는다. 이번 R-I는 균형 모형의 일부를 재사용하고 다음 조건을 새로 명시한 검토용 기준이다. 실제 장비에 적절하다고 검증한 설정이 아니다.
| 요구 | 이번 R-I의 비교 조건 |
|---|---|
| R-I1 관측 | 같은 장치clock/epoch·지원축/단위/버전, 표본 나이0~5ms 포함·abs(θ̂)≤0.15rad일 때만 정상 제어 계산 |
| R-I2 시간 | 연속 release10±0.2ms, release부터2ms 이내 유효 제출 또는 차단 결정. 늦은 정상 명령 폐기/차단·위반 기록 |
| R-I3 계산/한도 | 제공 상보필터와 u=-(3θ̂+2ω), 추상u한도±0.2. 요청/제한값을 함께 남김 |
| R-I4 상태 | 관측 무효는 INHIBITED. 고장/만료 우선·차단 후 일반 명령으로 자동 재개 금지 |
| R-I5 UI/기동 | ACK 대기50ms 후 미응답은 결과 미확인. 재부팅은 새epoch/IDLE·이전epoch 요청 거부 |
θ̂(rad)와ω(rad/s)는 같은 축의 추정 입력이며 u는 추상 무차원 출력이다. H-I·firmware F-I1/cal C-I1과 후보C0는 제공 이름이다. 실제 commit/hash·보정/보드 식별자가 아니다. UI의 shaft 속도 요청을 균형 모형의u로 바꾸는 실제 bridge도 제공하지 않는다. 이 표가 장치 전체의 통합 구현을 뜻하지 않는 이유다.
시험 전에 입력·기대·원본과 판정을 고정한다
한 사례마다 요구ID, 대상/형상·환경, 초기 상태/epoch, 입력/시간·결함 조건, 기대 결과·허용 오차, 관측 필드와 판정/이유를 적는다. 기대는 결과를 본 뒤 맞추지 않는다. 경계/실패 조건에도 같은 기준을 적용하고 불일치를 기록한다.
제공 자료 분석이면 그 출처를, 실제 실행이면 명령/환경·원본/결과 지문·clock/설정/버전을 남겨야 한다. 모형 실행과 실제MCU·물리 관측을 같은 실행 횟수로 합산하지 않는다. M26.01 형상/요구와 M00.06 검증 경로를 연결한다.
여섯 개의 독립 제공 사례를 비교한다
아래는 후보C0에 대한 자체 연습용 출력표다. 실제 코드/장비 출력이 아니며 각 사례의 초기 조건은 독립적이다. 앞 행의 필터/명령 상태를 다음 행으로 자동 이어 쓰지 않는다. PASS는 이 제공 사례에서 기대와 보고가 맞는다는 뜻이다.
| 사례 | 입력/기대와 제공 보고·판정 |
|---|---|
| T1 정상 계산 | age1ms/축·버전정상, 이전θ̂0·ω.2/θ_acc.1/Δt.01/α.98. 기대θ̂.00396·요청-.41188/제한-.2·제출1.1ms. 제공 보고도 같음 → PASS |
| T2 오래된 관측 | age6ms라 현재 무효/INHIBITED 기대. 제공 보고는 과거 정상값으로 현재를 채우고 ACTIVE 유지 → FAIL |
| T3 마감 위반 | 정상 명령 결정2.2ms는2ms 초과라 늦은 정상 명령 폐기/차단·위반 기록 기대. 제공 보고는 정상 제출/ACTIVE → FAIL |
| T4 반대 부호 | 제공 국소 모형에서 음의 피드백을 기대. 제공 식은u=+(3θ+2θ̇)로 양의 특성근 존재 → FAIL |
| T5 ACK 단절 | UI대기50ms 뒤 미응답. 기대 결과 미확인/관측 분리. 제공 보고도 미확인·물리 결과 미상 → PASS |
| T6 재부팅 | 새epoch에서IDLE, 이전epoch요청 거부 기대. 제공 보고도IDLE/이전요청 거부·자동재개없음 → PASS |
T1의 계산은0.98×(0+0.2×0.01)+0.02×0.1=0.00396rad다. 요청u=-(3×0.00396+2×0.2)=-0.41188, 한도 후-0.2다. 포화가 걸려도 요청/제한을 정확히 기록했다면 이 산술/한도 항목은 맞을 수 있다. 실제 자세 정확도나 균형 유지는 별도다.
T4의 부호 비교는 정확 상태·국소/무지연/비포화 모형이라는 별도 조건이다. 실제 필터를 붙인 전체 폐루프의 안정성을 이 계산으로 보장하지 않는다. T4는 M26.02의 θ̈=4θ+2u에 제공 반대 부호를 대입해λ²-4λ-10=0, 양근2+√14≈5.7417s⁻¹가 있음을 계산한다. 실제 모터 배선/장착 부호가 원인이라고 확정한 것은 아니다. 실제 원인이 아닌 제공 수식의 모형 불일치를 판정한 것이다.
여섯 사례 중 일치는T1/T5/T6의3개, 불일치는T2/T3/T4의3개로 사례 일치율3/6=50%다. T5에 ACK가 없다고 분모에서 빼지 않는다. 기대대로 미확인을 남기는 것이 해당 논리 요구의 통과다. 이50%는 실제 제어·작업/정지 성공률이 아니다.
평균 시간과 마감 위반을 따로 보고한다
별도 제공 성능 구간의 연속 release는0/10/20.2/30ms다. 간격10/10.2/9.8ms는 R-I2의 제공 주기 범위 안이다. 네 cycle의 결정 지연은1.1/1.9/2.2/1.5ms라고 준다. 평균은1.675ms, 최대2.2ms,2ms 초과는1/4=25%다.
평균이2ms보다 작다고 마감 요구를 통과시킬 수 없다. 주기/결정 마감·필터/driver/표시 지연의 기산점/분모를 구별한다. 여섯 사례와 네 cycle의 분모를 합쳐 시스템 평균 점수를 만들지 않는다. 표본이 작고 제공 범위도 제한돼 전체 worst-case/실시간 성능이 검증된 것은 아니다.
이 구간의2.2ms 위반과 T3는 같은 종류의 결함을 설명한다. 서로 다른 독립 실물 시행 두 개로 세지 않는다. clock/누락/실측 조건·부하가 없는 계산/제공 자료에서 물리 실행 빈도를 만들어내지 않는다.
결함의 관찰·가설·수정안·재검증을 분리한다
불일치가 보이면 먼저 요구/입력·형상/측정 방법이 맞는지 확인한다. 시험 도구/조건 오류와 후보 결함을 구분해야 한다. 원인을 모르면 가설로 남기고 추가로 어떤 자료가 필요한지 적는다.
| 결함 | 관찰·가설/추가 근거·수정 후 확인 |
|---|---|
| D1/T2 | age6인데ACTIVE. 가설은 과거값을현재로쓰는경로/관문순서 오류. 원본/유효성·상태전이근거 필요. 수정후 age5/6·누락/clock/버전 경계 재확인 |
| D2/T3 | 2.2ms 정상제출. 가설은 대기/스케줄·clock기산/늦은출력처리 오류. 각구간/감시기록 필요. 수정후 정상·경계2ms·초과/부하·회복 근거 확인 |
| D3/T4 | 제공식의 양의 피드백. 모형상 부호 불일치 확인. 실제축/장착·driver 매핑 원인은 미상. 수정후 선언한 축/오차/출력 부호와 모형·한도·관문을 함께 확인 |
수정안을 적었다고 후보C1을 실행한 것은 아니다. 새로운 통과 로그가 없으면 D1~D3를 해결/재검수 통과로 바꾸지 않는다. 이전 실패와 원본은 보존하고 변경한 요구/코드·모형/설정·검증 조건을 새 형상으로 연결한다. 요구를 사후 완화해2.2ms를 통과시키는 것과 실제 성능을 개선하는 것은 다르다.
보드/기구의 사전 결함은 소프트웨어 일치율로 덮지 않는다
M26.03의 가상 보드에는 전원peak/열·pin map/신호/미확인이 남았고, M26.04의 공차 후보는 실제 공정/조립 능력이 미검증이다. 이들을 해소한 실물 자료가 없으므로 실제 장비 시험에 적합하다고 보고할 수 없다.
특히 지그 위 접촉 범위 계산·CAD fixed 상태, 정규화u·PWM평균, UI접수/미확인을 실제2륜 균형 유지나 물리 정지로 바꾸지 않는다. 현재 결론은 제공 자료 분석 완료, 후보 불일치3개/실물 근거 미확인, 전체 통합/릴리스 BLOCKED다.
이렇게 실패를 남기는 것이 기본 학습 미완료라는 뜻은 아니다. 학습 목표는 요구와 사례를 정확히 판정하고 부족 근거를 설명하는 일이다. 실제 후보 구현/장비의 통과를 주장하는 일과 구분한다.
포트폴리오에는 결과의 종류와 범위를 먼저 쓴다
제목은 '제공 임베디드 사례의 요구/결함 분석'처럼 실제 수행 범위에 맞춘다. '실물 균형 제어 검증 완료'처럼 아직 없는 실행/성과를 제목으로 만들지 않는다. 기존 6.6 평가 설계·6.8 포트폴리오와 M32.05 재현 패키지의 원본/실패·형상 원칙을 적용한다.
보고서는 문제/대상·요구ID/입력·형상/가정 → 기대/제공 결과·계산/불일치 → 원본과 미확인 → 가설/수정 제안·재검증 계획 → 결론/한계 순서로 쓴다. 실제 실행을 추가했다면 환경/명령·버전/원본/결과 지문과 실제 수행 내역을 별도 붙인다. 제공 이름C0/H-I를 실제 파일hash라고 적지 않는다.
다음 JSON은 실행 프로그램이 아닌 이 제공 분석의 보고 예시다. physicalRuns가0이면 물리 성공률은0%가 아니라 정의할 시행이 없어null/미측정이다.
{
"kind": "given-case-analysis",
"exampleBaseline": "R-I/H-I/C0",
"providedCases": 6,
"caseMatches": 3,
"caseMismatches": 3,
"executedFirmwareRuns": 0,
"physicalRuns": 0,
"physicalSuccessRate": null,
"integrationDecision": "BLOCKED"
}
성공한 화면만 골라 전체 결과처럼 제시하지 않는다. 실패/미확인/중단과 같은 형상/조건의 전체 분모를 남긴다. 보안/개인 자료·외부 자산의 권한/라이선스도 실제 공개 범위에 맞춰 확인한다. 이 단위는 보고 예시를 읽는 활동이며 외부 저장소/서비스에 게시하지 않는다.
다음 전문화로 넘길 상태
W08 기본 완료는 요구/HSI→센서/제어→보드/기구→UI/clock→평가/결함·재현의 설명/제공 분석을 수행한 상태다. 실제 장비/독립 사용자·제품 검증을 완료한 것은 아니다. 각 계층의 미확인과 통합 결론을 그대로 유지한다.
다음 M28.01 차량 통신의 계층/프레임으로 이동할 때도 MCU/버스·요청/관측의 단위/시간·형상/시험 범위를 이어 간다. W08 교재 완료와 뒤 차량 통신·전체 A01 경로 검수는 별도다.