다운로드는 '파일을 보냈다'보다 넓은 상태 흐름이다
진단의 download는 클라이언트에서 ECU/서버로 데이터를 보내는 방향이고, upload는 반대 방향이다. 여기서는 인터넷 파일 다운로드와 혼동하지 않는다. 전송이 끝나도 대상에 맞는 이미지인지, 신뢰할 수 있는 출처인지, 부팅/기능이 정상인지까지 자동 확인되지는 않는다.
기본 활동은 자체 가상 서버의 제공 기록과20B 바이트열 분석이다. 이 바이트열은 실행 가능한 MCU 펌웨어가 아니다. 실제 ECU/차량에 연결하거나 보안 접근·쓰기/flash/리셋을 수행하지 않는다. 아래 서비스 번호는 기록을 읽기 위한 것이며 특정 차종의 실행 명령 순서/주소를 제공한 것이 아니다.
이 단위에서 공백으로 나눈 payload와 서비스/NRC 번호는16진수다. 바이트 수/시간은 별도 표시가 없으면 십진수다.
M28.03의 재조립/응답 구분과 M28.04의 원본 보존/관찰 공백을 이어 간다. 접수·전송·검증·활성화의 근거를 단계별로 남기는 것이 목표다.
대상·이미지·회복 조건을 먼저 고정한다
대상 ECU의 HW/bootloader/현재 형상, 메모리 영역/크기·정렬, 지원 서비스/프로그램 절차, 이미지/설정의 정확한 버전과 출처를 연결한다. 전원/운영 상태·중단/회복 경로와 실패/원본 기록도 필요하다. 숫자 ID 하나로 대상 호환성이나 작업 권한을 대신하지 않는다.
그림 M28.05-1. 각 칸은 서로 다른 역할/근거다. 아래 방향은 자료/처리의 연결이며 실제 성공을 자동으로 보장하지 않는다. 직접 제작한 개념도이며 본문의 조건과 함께 읽는다.
| 단계 | 필요한 근거/관찰 |
|---|---|
| 사전 조건 | 대상/형상·지원 절차·정확한 이미지/정책·현재 전원/운영/복구 조건 |
| 세션/권한 | 서버가 요구하는 세션·보안 수준과 서비스별 조건 |
| 전송 시작/블록 | 허용 영역/크기·길이 한도·현재 블록/응답·진행 상태 |
| 종료/검증 | 실제 수신/저장 범위·무결성/신뢰·호환/활성화 조건 |
| 리셋/복귀 | 새 boot/버전·진단/기능/물리 상태·회복 결과 |
실제 절차의 erase나 검증 루틴·활성화 순서는 서버/bootloader에 따라 다르다. AUTOSAR DCM R24-11도 서비스 처리와 응용 callout/조건을 나눈다. 일반 서비스 목록을 보편적인 flash 레시피로 만들지 않는다.
세션·SecurityAccess·이미지 인증은 서로 다른 관문이다
세션 전환은 진단 문맥의 변경이다. SecurityAccess(0x27)는 제한된 진단 서비스/데이터 접근을 위한 보안 수준과 관계된다. 일반적으로 홀수 하위기능의 seed 요청과 대응하는 짝수 하위기능의 key 제출을 구별하며, 수준/알고리즘·권한 범위는 서버 정의를 따른다.
이 단위는 seed/key 값이나 계산/우회 방법을 제공하지 않는다. 세션 응답이 왔다고 보안 접근이 완료된 것도,0x27 응답이 왔다고 이미지의 서명/대상 호환성이 검증된 것도 아니다. 실제 권한 자료/공식 도구와 해당 절차가 필요하다.
| 부정 응답의 NRC | 읽어야 할 상태 |
|---|---|
| 33: securityAccessDenied | 현재 서비스 접근 권한/조건 불충족 |
| 35: invalidKey | 제출한 key 거부. 무조건 반복해도 된다는 뜻 아님 |
| 36: exceedNumberOfAttempts | 허용 시도 한도 초과 |
| 37: requiredTimeDelayNotExpired | 요구 지연이 아직 끝나지 않음 |
이 코드는 UDS 서비스 식별자가 아닌 NRC다. 제한/지연을 임의 반복·재부팅으로 피해 가는 흐름으로 설명하지 않는다. 오류/시도/기밀 자료의 보존 범위와 실제 승인된 절차를 구분한다. 이 활동에서는 실제 접근 시도 횟수가0이다.
다운로드 응답의 길이는 어느 계층을 세는가
가상 서버의 RequestDownload(0x34) 응답을 재조립된 UDS PDU 74 20 00 0A라고 준다. 요청이 허용된 가상 영역/20B 크기에 맞고 추가 전송 파라미터는 없다고 가정한다. 실제 메모리 주소/영역은 제공하지 않는다.
74는 정상 응답 SID,20은 lengthFormatIdentifier다. 상위 nibble2는 뒤의 길이 필드가2B라는 뜻이고 하위 부분은 예약0이다. 00 0A는 maxNumberOfBlockLength=10B다. py-uds 서비스 정의에서 이 값은 SID와 blockSequenceCounter를 포함한 TransferData 요청 전체 길이다.
이번 조건에서0x36 SID1B와 블록 순서1B를 빼면 실제 데이터 한도는10−2=8B다. ISO-TP PCI·CAN ID/CRC까지 포함한 선로 프레임 길이가 아니다. 내부 API의 버퍼 크기/다른 서비스의 길이 정의를 같은 필드로 읽지 않는다. udsoncan의 응답 해석도 상위 nibble과 길이 바이트의 해석을 확인할 수 있는 자료이며 이 단위에서 라이브러리를 실행하지 않는다.
20B를8/8/4로 나누고 응답을 대응시킨다
예제 바이트는0x01부터0x14(십진20)까지 순서대로20개다. 다음은 자체 제공 전송 기록이다. 표에는 이미 재조립된 UDS 요청/응답을 적었다.
| 블록 | 데이터·전체 요청/대응 응답 |
|---|---|
| 1 | 데이터01 02 03 04 05 06 07 08(8B). 36 01+데이터=10B → 76 01 |
| 2 | 데이터09 0A 0B 0C 0D 0E 0F 10(8B). 36 02+데이터=10B → 76 02 |
| 3 | 데이터11 12 13 14(4B). 36 03+데이터=6B → 76 03 |
BSC(blockSequenceCounter)는1부터 시작하는8bit 순서 번호이며0xFF 뒤0x00으로 순환한다. 응답의76과 해당 BSC를 확인해야 한다. 이 전송의3블록이 맞았다고 임의의 이전/다음 전송과 같은 문맥이라고 가정하지 않는다.
BSC는 ISO-TP CF의4bit 순서 번호와 다르다. 예를 들어 두 번째 UDS 블록에도 그 PDU의 ISO-TP 첫 CF 순서는1일 수 있다.10B UDS 요청은 이번 Classical normal8B의 단일 CAN 프레임에 들어가지 않아 ISO-TP 분할이 필요하다. 세 번째6B 요청은 해당 형식의 SF 수용량7B 안이다. 최대 데이터8B와 CAN payload8B를 같은 것으로 보면 앞 두 블록을 잘못 전송하게 된다.
순서/응답을 잃었을 때 상태를 만들어내지 않는다
0x36은 선행 다운로드/업로드 문맥이 필요하다. 순서가 맞지 않으면 NRC0x24(requestSequenceError), 잘못된 BSC는0x73(wrongBlockSequenceCounter)와 구별한다. 기타 실패/중단·전원 조건은 실제 서버 응답/문서에 따라 해석한다. AUTOSAR의 전송 처리도 이러한 조건을 나눈다.
가상 블록2의76 02가 보이지 않는 경우를 별도 생각한다. 서버가 블록2를 안 받았는지, 받았으나 응답이 유실됐는지 아직 모른다. 이를 성공으로 채워 무조건 블록3으로 가거나 새로운 데이터를 같은 BSC에 붙이지 않는다.
지원되는 재시도도 해당 전송 문맥·같은 BSC·정확히 같은 바이트와 서버의 중복 처리 조건을 확인해야 한다. 연결/세션/boot가 바뀐 뒤 이전 진행 상태가 유지된다고 가정하지 않는다. 재개가 가능한지/어느 범위가 저장됐는지 확인할 근거가 없으면 미확인으로 남긴다. pending은 최종 성공이 아니고 timeout도 서버 취소/미수행을 보장하지 않는다.
이전 원본·형상/epoch·마지막 확정/미확인 블록·재시도 이유와 결과를 보존한다. 블록 수를 맞추기 위해 실패/중복을 지우지 않는다. 이 교재의 예시는 실제 재시도를 실행한 로그가 아니다.
전송 종료와 실제 이미지 검증은 별도다
RequestTransferExit(0x37)은 전송 종료를 요청하고 정상 응답 SID는0x77이다. 가상 서버가 추가 종료 파라미터 없이37→77로 응답했다고 준다. 이것만으로 실행 가능한 이미지·서명/대상 적합·부팅/기능 검증이 전부 끝났다고 하지 않는다.
어떤 서버는 RoutineControl(0x31)의 제조사 정의 루틴 등으로 별도 검증을 수행한다. 루틴 ID·입력/상태 레코드·완료 조건을 확인해야 하며, 단순히0x71 응답 SID를 보았다고 그 루틴의 최종 판정이 성공이라고 가정하지 않는다.
이 예제의20B 바이트열에 대한 SHA-256 기준 계산값은 다음과 같다.
e12f08743344c0eab7afaa22bb71e2725f7e13dece6ac2d23711054ee787b6c2
이는 제공 바이트의 계산값이며 실제 ECU 메모리의 readback/hash 결과가 아니다. 비교하는 데이터/범위·형상과 기준의 출처가 필요하다. byte hash가 같아도 기준 자체가 신뢰할 수 있는지, 누가 승인/서명했는지, 대상 HW/bootloader에 맞는지까지 보장하지 않는다.0x27 접근 권한도 이 이미지 검증을 대체하지 않는다.
NIST SP800-193은 펌웨어의 무단 변경 보호·변경 검출·회복을 구분한다. 이 개념을 참고할 수 있지만 바이트 계산 한 번으로 해당 지침의 제품 검증/적합성을 완료했다고 표시하지 않는다.
활성화와 리셋 뒤 상태까지 근거가 필요하다
현재 제공 기록의 판정은 다음과 같다.
| 확인 범위 | 현재 결론 |
|---|---|
| 가상 블록/응답·20B 구성 | 제공 요청/응답 대응과 계산은 일치 |
| 실제 ECU 수신/저장·무결성 | 실물 readback/검증 결과 없음 |
| 이미지 출처/서명·대상 호환 | 실행 가능한 이미지/신뢰/호환 자료 없음 |
| 활성화/리셋·boot/회복 | 실제 수행/결과 없음 → 활성화 BLOCKED |
20B는 실행 가능한 펌웨어가 아니므로 전송 산술을 실제 flash 성공으로 바꿀 수 없다. 학습 분석 완료와 활성화 보류는 모순되지 않는다. 실제 진단/쓰기·리셋 횟수는 모두0이다.
리셋 흐름도 독립적으로 읽는다. 가정상 ECUReset(0x11)에0x51 정상 응답이 왔더라도 응답 시점/리셋 방식은 설정을 확인해야 한다. 새 boot/버전·무결성/자체 진단·기능과 물리 상태를 별도로 관측해야 한다. 응답 한 번이 새로운 펌웨어의 정상 기동 증거가 아니다.
리셋/전원 단절 뒤에는 이전 세션·보안 권한·명령/승격 상태·clock/epoch를 그대로 재사용하지 않는다. 실패 시 복구/rollback도 어떤 이미지/상태로 돌아왔는지 확인해야 하며 코드 복귀와 물리 상태 복원은 다르다. 기존 6.4 배포 감독기의 형상 변경/이전 승인 무효화·새 관측 원칙을 연결한다.
기록을 다음 단계로 넘긴다
대상/형상·이미지/기준·지원 절차/권한·요청/PDU·블록별 길이/순서/응답·시간/미확인·검증 범위/누락·활성화/복구 판정을 묶는다. 기밀 key나 실제 장치 정보를 예제 산출물에 임의로 넣지 않는다. 이 활동은 제공 기록 분석 보고서이며 외부 장치/서비스에 실행/게시하지 않는다.
다음 M28.06 XCP·A2L에서는 계측/캘리브레이션의 정의/형상·메모리/시간을 읽는다. 관찰이나 파라미터 기록이 실제 적용/비휘발성 반영·정상 동작을 보장하지 않는다는 구분을 이어 간다.