프레임이 보여도 설정과 해석이 맞는지 확인한다
M28.01에서는 물리 연결·링크 프레임·응용 의미를 구분했다. 이번에는 '500kbit/s가 같으니 설정도 같다', '에러 카운터가 낮으니 문제가 없었다', 'DBC가 숫자로 바꿨으니 최신 센서 값이다'라는 판단을 나누어 검토한다.
기본 활동은 자체 가상 CAN 설정/상태와 신호 정의의 종이 분석이다. 아래 clock·분주비·속도/범위·payload는 실제 차종/보드 설정이 아니다. 실제 버스에 명령을 전송하거나 기존 인터페이스를 변경하지 않는다. 필요한 도구 선수는 설정/로그의 항목을 읽는 수준이며 일반 언어 문법을 반복하지 않는다.
비트율은 한 비트의 전체 길이이고 샘플 지점은 그 안의 위치다
서로 다른 ECU는 각자 clock을 가지고 같은 버스를 읽는다. 프레임 시작/비트 경계의 변화로 동기를 맞추더라도 어느 시점에 비트를 읽을지와 허용 보정 범위가 필요하다. 전파 지연·트랜시버 지연·발진기 오차도 영향을 준다. 케이블이 길어지는 문제를 payload의 단위 변환으로 해결할 수는 없다.
그림 M28.02-1. 각 칸은 서로 다른 역할/근거다. 나란히 비교할 항목이며 위아래가 시간 순서를 뜻하지 않는다. 직접 제작한 개념도이며 본문의 조건과 함께 읽는다.
TQ(Time Quantum)는 비트 시간을 나누는 기본 시간 조각이다. 여기서는 제어기에 주어진 clock을 실제 분주비로 나누어 TQ clock을 만든다는 가상 조건을 정한다. 레지스터에 쓰는 숫자와 실제 분주비가 같다는 뜻은 아니다. 장치에 따라 +1 인코딩·추가 분주나 다른 clock 경로가 있으므로 실제 설정에는 해당 제어기 자료가 필요하다.
명목 한 비트는 SYNC 구간1TQ + TSEG1 + TSEG2로 나눈다. TSEG1은 전파 지연/위상 보정 구간을 합친 표현이며, TSEG1이 끝나고 TSEG2가 시작하는 지점에서 샘플한다. SJW(Synchronization Jump Width)는 재동기화 때 허용하는 위상 보정 폭이다. 항상 덧붙이는 네 번째 구간이 아니다.
Microchip DS70005340C §5.3의 구간/샘플 개념을 사용하되 아래 값은 자체 예시다.
| 가상 조건/계산 | 결과 |
|---|---|
| 입력 clock24MHz / 실제 분주비3 | TQ clock8MHz, TQ=125ns |
| SYNC1 + TSEG1 11 + TSEG2 4 | 총16TQ, 명목 한 비트2µs |
| 1 / 2µs | 명목 비트율500,000bit/s=500kbit/s |
| 샘플 위치 (1+11)/16 | 비트 안의75% 지점 |
| SJW1TQ | 허용 보정 폭125ns. 총17TQ로 더하지 않음 |
조건을 TSEG1=13/TSEG2=2로 바꾸면 총16TQ와 명목 비트율은 같지만 샘플 위치는14/16=87.5%다. 같은 비트율이 모든 타이밍 설정의 동일함을 뜻하지 않는다. 어느 구성이 실제 버스에 적합한지는 전파/트랜시버·clock 오차·장치별 허용 범위/SJW 조건을 더 확인해야 한다. 이 계산으로75% 또는87.5%를 모든 장치의 권장값으로 정하지 않는다.
Linux SocketCAN 설정 문서는 TQ·prop_seg/phase_seg·SJW와 장치별 범위/clock을 구분한다. 명령을 복사하기 전에 실제 clock과 계산 결과를 읽는 이유다. 이 단위에서는 실제 can0 설정/활성화를 수행하지 않는다.
중재에서 진 것과 프레임 오류를 구별한다
중재 중 recessive를 내보내다 dominant를 읽고 물러나는 것은 정상 경쟁이다. 이를 전부 배선 오류나 송신 실패로 세면 부하/우선순위 분석을 잘못한다. 반면 링크 검사를 어긴 경우는 오류 보고/상태를 확인해야 한다.
| 관찰한 종류 | 의미와 아직 모르는 원인 |
|---|---|
| 중재 패배 | 다른 우선순위가 먼저 전송. 그 자체는 bit 오류 아님 |
| ACK 오류 | 정상 수신 확인을 얻지 못함. 상대 없음/모드·설정/배선 등은 추가 확인할 가설 |
| CRC 오류 | 전송 오류 검사 불일치. 센서의 물리 측정 정확도를 검사한 것이 아님 |
| stuffing/형식 오류 | 허용 비트열/고정 형식 위반. 임의의 특정 케이블 고장으로 확정하지 않음 |
| bit 오류 | 예외가 아닌 구간에서 송신 의도와 관측이 다름. 중재/ACK의 정상 동작 예외를 구분 |
같은 오류 메시지에도 여러 원인이 가능하다. 원본의 시각·인터페이스/모드·비트 타이밍·전원/토폴로지·상대/트랜시버 상태·카운터/누락을 함께 기록한다. 관찰과 원인 가설, 설정 변경, 재검사 결과를 한 줄의 '정상화'로 덮지 않는다.
오류 상태는 통신 능력과 복구 정책의 일부다
TEC(Transmit Error Counter)와 REC(Receive Error Counter)는 송신/수신 오류 상태를 관리하는 카운터다. 모든 오류마다 둘 다 무조건1씩 늘어나는 단순 횟수계가 아니다. 성공/오류 종류와 예외에 따라 변하므로 현재 숫자에서 과거 오류 총수를 역산하지 않는다.
Microchip 같은 문서 §12.1의 상태 경계는 다음과 같다. 정상 통신 모드의 오류 상태를 설명하며, 인터페이스가 관리상 내려간 상태나 복구 중인 bus-off를 카운터 숫자만으로 대체하지 않는다.
| 상태/경계 | 해석 |
|---|---|
| error-active: 두 카운터가127 이하인 영역 | 통신·활성 오류 플래그 사용 가능. 오류가 한 번도 없었다는 뜻 아님 |
| error-passive: TEC 또는 REC가128 이상 | 수동 오류 플래그 사용. 정상 데이터 통신이 전부 금지된 상태는 아님 |
| bus-off: TEC가255를 초과해 전이 | 해당 노드가 버스 통신에서 이탈. REC만 높다는 이유로 bus-off라고 하지 않음 |
bus-off 조건이 있으면 passive보다 bus-off 판정을 먼저 구분한다. 경계 예시로 TEC127/REC0은 active 영역, TEC128/REC0은 passive 영역이다. TEC가255를 초과하는 전이는 bus-off를 일으킨다. 이 경계의 논리 값을 실제 특정 장치의8bit 레지스터 출력 형식이라고 간주하지 않는다.
복구에는 프로토콜/제어기의 재진입 조건과 시스템 정책이 있다. SocketCAN의 자동 restart 설정은 기본으로 꺼져 있으며 드라이버/설정에 따라 재시작 동작이 달라진다. '에러가 나면 무조건 즉시 반복 재시작'을 해결책으로 쓰지 않는다. 재시작으로 통신 상태가 돌아와도 단선·잘못된 타이밍·전원 문제가 해결됐다는 증거는 아니고, 과거 명령/응용 상태를 자동 재개해도 된다는 뜻도 아니다.
CAN FD에서는 길이 코드와 속도 구간을 다시 읽는다
CAN FD(Flexible Data-rate)는 한 프레임에 최대64B payload를 담을 수 있다. BRS(Bit Rate Switch)로 데이터 구간의 비트율 전환을 지정할 수 있다. FD라고 항상 두 속도를 쓰는 것은 아니다. BRS를 쓰지 않는 형식/조건도 있으며, 속도·트랜시버·노드/토폴로지·ISO/non-ISO 모드는 서로 맞아야 한다.
예를 들어 nominal500kbit/s·data2Mbit/s와 BRS 사용을 제공했다고 하자. 경쟁/확인 등을 위한 구간과 빠른 데이터 구간의 속도가 다르므로 전체 프레임 비트 수를2Mbit/s로 나누면 안 된다. Classical8B의108bit 합도 FD64B에 재사용하지 않는다. FD는 제어/CRC·stuffing 구조도 달라 별도 계산이 필요하다.
DLC는4bit 길이 코드이며 FD에서 코드9 이상은 숫자 그대로의 바이트 수가 아니다. 아래 표는 ST AN5348의 길이 코드 표를 기준으로 읽는다.
| FD의 DLC | payload 바이트 수 |
|---|---|
| 0~8 | 각 코드와 같은0~8B |
| 9 | 12B |
| 10 | 16B |
| 11 | 20B |
| 12 | 24B |
| 13 | 32B |
| 14 | 48B |
| 15 | 64B |
도구 화면이 'DLC'라고 부르더라도 실제 raw 코드인지 이미 환산된 길이인지 확인한다. FD 코드15를15B라고 기록하거나 길이64를4bit 코드 칸에 그대로 넣는 실수를 구분한다. 앱의 실제 payload 길이와 도구 표시 의미가 맞아야 한다.
FD에는 remote frame이 없다. 일반적인 Classical-only 제어기는 FD 프레임을 오류로 볼 수 있으므로 기존 버스에 FD 송신 노드를 하나 추가하는 것만으로 호환을 보장할 수 없다. FD 지원 제어기가 Classical 프레임을 처리하는 능력과 Classic-only 노드가 FD 트래픽을 견디는 것은 다른 조건이다. Microchip CAN 비교의 이 구분을 확인한다. FD가 응용 인증/데이터 신선도까지 새로 보장하는 것도 아니다.
DBC는 바이트를 신호 값으로 읽는 약속이다
CAN payload는 바이트열이다. DBC(CAN database)는 ID에 해당하는 메시지와 그 안의 신호 이름·시작 비트/길이·byte order·부호·배율/offset·단위 등을 정의하는 데 쓰인다. Kvaser DBC 설명과 CANlib Signals 문서는 이 해석 항목을 구분한다. 파일을 받았다고 현재 ECU 형상에 맞는 정의인지까지 확인된 것은 아니다.
다음은 자체 가상 V1 신호 계약이다. 실제 차종의 DBC가 아니며 완전한 DBC 파일이나 실행 결과를 제공한 것도 아니다.
| 항목 | 제공 정의 |
|---|---|
| 메시지 | Classical CAN·11bit ID0x120(십진288), payload8B |
| 신호 | ShaftSpeed, 단위rad/s, sensor_shaft의+z 회전 |
| 원시 필드 | payload byte0부터 start bit0·길이16bit·Intel little-endian·unsigned |
| 물리 변환 | speed=raw×0.01−10 |
| 응용 허용 범위 | −10~20rad/s 포함. raw0xFFFF는 범위 계산 전에 무효 처리하는 별도 sentinel |
| 추가 필드 | byte2의 값1은 version1, byte3의 값1은valid. 나머지4B는 이 예시에서0 |
| 시간/형상 | 별도 제공 메타데이터의 clock/epoch와 원본 표본 나이0~5ms 포함. 버전/축·생산자 계약도 확인 |
Intel little-endian은 이16bit 정수에서 낮은 자리 바이트가 앞의 payload 위치에 있다는 뜻이다. CAN 선로에서 바이트 안의 비트 순서를 거꾸로 뒤집으라는 뜻이 아니다. Motorola(big-endian) 신호의 start bit/진행 표기와도 임의로 섞지 않는다. 여기서는 start0·byte 경계에 맞춘16bit만 계산한다.
가상 payload가 E8 03 01 01 00 00 00 00이라고 하자. 모든 바이트는16진수 표기다. 첫 두 바이트의 raw는0x03E8=3×256+232=1000이고 speed=1000×0.01−10=0rad/s다. version1/valid1은 이 행의 형식 조건을 만족하지만 신선도/실제 동작은 추가 판단한다.
정상 숫자·무효값·오래된 값의 차이를 남긴다
입력을 바꾸면서 해석을 확인한다.
| 첫 두 바이트/조건 | 판정·이유 |
|---|---|
| D0 07, version1/valid1 | raw0x07D0=2000, speed10rad/s. 다른 조건 확인 후 사용 |
| 00 00, version1/valid1 | unsigned raw0이지만 offset 때문에 물리 값−10rad/s. 0으로 덮지 않음 |
| FF FF | 제공 sentinel로 무효. 645.35rad/s나 signed−1로 정상 표시하지 않음 |
| E8 03을 big-endian으로 잘못 해석 | raw59395→583.95rad/s. byte order 위반이며 제공 범위도 초과 |
| 정상 raw이나 version2 또는valid0 | 계산 가능한 숫자가 있어도 V1의 유효 관측으로 사용하지 않음 |
범위를 넘는 숫자를 조용히20에 잘라 정상 센서값으로 만들지 않는다. 원본·형식/무효 이유를 남기고 마지막 정상값을 보여줄 때도 그 원본 시각과 오래됨을 유지한다. unsigned라는 말은 원시 정수의 부호 규칙이며 물리 값이 항상 양수라는 뜻은 아니다.
이 표의 sentinel/valid/version·허용 범위는 별도로 제공한 응용 계약이다. 모든 DBC의 기본 의미로 일반화하지 않는다. DBC에 적힌 범위도 수신 도구가 자동으로 오류를 차단하거나 장비가 물리적으로 해당 범위를 지킨다는 보장이 아니다. ID/DBC 이름이 맞아도 생산자 인증은 별도다.
수신 시각과 생성 시각을 마지막까지 구분한다
가상 메타데이터에서 now=1000ms이고 표본은 같은 clock/epoch라고 하자. sample=995ms이면 나이5ms로 이번 계약의 시간 경계를 만족한다. sample=994ms이면6ms로 초과다. 숫자가0rad/s로 잘 해석돼도 오래된 관측은 그대로 무효다.
clock 변환의 불확실성 때문에 나이를4~6ms로만 안다면5ms 이내임을 보증할 수 없다. 이 경우는 확정된 신선한 값도, 모든 가능한 경우에서 오래된 값도 아니다. '시간 조건 미확인'으로 남긴다. clock/epoch가 없거나 현재 형상에 맞지 않으면 수신 시각으로 대신 채우지 않는다. 같은clock이라고 준 값에서도 sample이 now보다 미래여서 나이가 음수면 이번0~5ms 조건을 만족하지 않으며 임의로0으로 잘라 신선한 값으로 만들지 않는다. 이 시간은 payload8B에 자동 포함된 필드가 아니라 예시에 별도로 준 메타데이터다.
M26.05·기존 4.4 시간 정합의 clock/원본 시각 원칙을 적용한다. 타이밍 설정이 맞음 → 링크 프레임 수신 → 신호 해석 → 현재 유효 관측 → 응용 처리/물리 결과는 각각 근거가 필요한 단계다.
다음 M28.03 ISO-TP·UDS에서는 진단 요청/응답의 더 큰 메시지·주소·세션/시간을 다룬다. 링크 ACK와 진단의 응용 응답을 구별한 상태로 이동한다.