제조사 Protocol 문서 읽는 법: Packet Format·Data Type·Byte Order 해석하기

제조사 Protocol 문서 읽는 법: Packet Format·Data Type·Byte Order 해석하기#

1장 Protocol 문서를 받았다면 무엇부터 확인해야 할까#

처음 보는 PLC, 계측기, 센서, 카드리더, 프린터, 키오스크, 산업용 Controller를 연동해야 한다고 가정해보겠습니다.

제조사에서 Protocol 문서를 받았지만 첫 페이지부터 다음과 같은 내용이 보입니다.

AA 55 01 10 04 00 64 00 C8 7A

처음 보면 의미 없는 HEX 문자열처럼 보입니다.

하지만 Protocol 문서는 결국 다음 질문에 답하는 문서입니다.

어디서 Packet이 시작되는가?

누구에게 보내는가?

무엇을 요청하는가?

데이터는 몇 Byte인가?

각 Byte는 어떤 값을 의미하는가?

숫자는 어떤 순서로 저장되는가?

Packet이 정상인지 어떻게 검사하는가?

정상 처리와 오류를 어떻게 구분하는가?

따라서 HEX 전체를 한 번에 이해하려 하지 말고 구조를 먼저 나눠야 합니다.

예:

AA 55 | 01 | 10 | 04 | 00 64 00 C8 | 7A

이것을 문서가 다음처럼 정의한다고 가정하겠습니다.

AA 55
Header

01
Device Address

10
Command

04
Data Length

00 64 00 C8
Data

7A
Checksum

그러면 낯선 HEX 문자열이 갑자기 읽을 수 있는 Message가 됩니다.

Protocol 분석의 첫 번째 원칙은 값을 해석하기 전에 Frame 구조부터 확정하는 것입니다.

2장 Protocol 문서의 버전과 적용 범위를 먼저 확인한다#

Packet을 분석하기 전에 문서 자체가 현재 장비에 맞는지 확인해야 합니다.

Protocol 문서 첫 부분에서 다음 정보를 찾습니다.

Document Version

Protocol Version

Product Model

Hardware Revision

Firmware Version

Release Date

같은 제품이라도 Firmware에 따라 Protocol이 달라질 수 있습니다.

예:

Firmware 1.x
Command 0x10 지원

Firmware 2.x
Command 0x10 변경
Command 0x11 추가

같은 차이가 있을 수 있습니다.

따라서 최소한 다음 정보를 연결해 기록하는 것이 좋습니다.

항목 확인 내용
장비 Model 어떤 제품인지
Hardware Revision 보드·하드웨어 버전
Firmware 실제 장비 Firmware
Protocol Version 문서의 Protocol Version
Document Revision 문서 개정판
적용 대상 어떤 Model·Firmware에 적용되는지

문서가 오래되었거나 적용 Model이 다르면 이후의 Packet 분석이 아무리 정확해도 실제 장비와 맞지 않을 수 있습니다.

3장 가장 먼저 Packet Format 표를 찾는다#

Protocol 문서에서 가장 중요한 부분 중 하나는 다음과 같은 표입니다.

Field Size 설명
STX 1 Byte Packet 시작
Address 1 Byte 장비 주소
Command 1 Byte 명령
Length 2 Byte Data 길이
Data N Byte 실제 Payload
CRC 2 Byte 오류 검출
ETX 1 Byte Packet 종료

이를 그림으로 바꾸면 훨씬 이해하기 쉽습니다.

┌─────┬─────────┬─────────┬────────┬────────────┬─────┬─────┐
│ STX │ Address │ Command │ Length │    Data    │ CRC │ ETX │
└─────┴─────────┴─────────┴────────┴────────────┴─────┴─────┘

이 단계에서 중요한 것은 각 Field의 의미와 크기를 따로 기록하는 것입니다.

Header·STX#

Frame이 어디에서 시작되는지 알려줍니다.

예:

02

또는:

AA 55

같은 고정값을 사용할 수 있습니다.

Address#

여러 장비 중 어느 장비를 대상으로 하는지 나타낼 수 있습니다.

01
02
03

처럼 한 Byte로 구성될 수도 있고 더 긴 Identifier를 사용할 수도 있습니다.

Command#

어떤 작업을 요청하는지 나타냅니다.

예:

01
Status Read

02
Data Read

10
Configuration Write

Length#

Data가 몇 Byte인지 알려주는 Field입니다.

하지만 여기에서 자주 실수가 발생합니다.

Length=10이라는 값이:

Data만 10 Byte

인지:

Command + Data가 10 Byte

인지:

전체 Packet이 10 Byte

인지는 Protocol마다 다릅니다.

Length라는 이름만 보고 계산해서는 안 됩니다.

Data#

실제 값이 들어갑니다.

예:

온도

압력

Card ID

Sensor 상태

설정값

문자열

Checksum·CRC#

전송 중 데이터가 손상됐는지 검사합니다.

어떤 Byte부터 어떤 Byte까지 계산하는지도 반드시 확인해야 합니다.

4장 Data Type을 모르면 HEX를 값으로 바꿀 수 없다#

다음 데이터가 있다고 하겠습니다.

00 64

사람이 보기에는 두 Byte입니다.

하지만 Protocol 문서가:

uint16

이라고 정의했다면 하나의 16bit 정수일 수 있습니다.

Big Endian이라고 가정하면:

0x0064
=
100

입니다.

그런데 같은 두 Byte라도 Data Type이 다르면 의미가 전혀 달라질 수 있습니다.

자주 등장하는 Data Type#

표현 의미 일반적인 크기
uint8 부호 없는 8bit 정수 1 Byte
int8 부호 있는 8bit 정수 1 Byte
uint16 부호 없는 16bit 정수 2 Byte
int16 부호 있는 16bit 정수 2 Byte
uint32 부호 없는 32bit 정수 4 Byte
int32 부호 있는 32bit 정수 4 Byte
float32 32bit 부동소수점 4 Byte
double 64bit 부동소수점 보통 8 Byte
ASCII 문자 데이터 가변
BCD 10진 숫자를 Digit 단위로 저장 규격에 따라 다름
Bit Field 하나의 Byte·Word에서 Bit별 의미 부여 규격에 따라 다름

Signed와 Unsigned도 중요하다#

다음 Byte:

FF

를 uint8로 읽으면:

255

입니다.

하지만 int8로 읽으면 일반적인 2의 보수 표현에서:

-1

이 될 수 있습니다.

따라서 Field를 읽을 때는:

Size
+
Data Type
+
Signed 여부

를 함께 확인해야 합니다.

5장 Byte Order를 틀리면 숫자가 완전히 달라진다#

여러 Byte로 구성된 숫자에서는 Byte Order가 중요합니다.

대표적으로:

Big Endian

Little Endian

이 있습니다.

예를 들어 숫자:

0x1234

가 있다고 하겠습니다.

Big Endian#

상위 Byte가 먼저 옵니다.

12 34

Little Endian#

하위 Byte가 먼저 옵니다.

34 12

따라서 Packet에서:

34 12

를 발견했다고 해서 무조건 0x3412라고 해석하면 안 됩니다.

Protocol이 Little Endian이라면 실제 값은:

0x1234

입니다.

4 Byte에서는 더 중요해진다#

예:

12 34 56 78

Big Endian이라면:

0x12345678

Little Endian이라면 Byte 배열은:

78 56 34 12

가 될 수 있습니다.

Word Order까지 따로 존재할 수 있다#

산업 장비에서는 32bit 값을 16bit Register 두 개로 나누기도 합니다.

예:

Word 1
12 34

Word 2
56 78

그런데 제조사 구현에 따라 Word 자체의 순서를 바꾸는 경우도 있습니다.

따라서 다음을 별도로 확인해야 할 수 있습니다.

Byte Order

Word Order

특히 PLC·Modbus·계측기 연동에서 자주 만나는 문제입니다.

6장 문자열도 그냥 읽으면 되는 것이 아니다#

Protocol에 문자열이 포함되어 있다고 하겠습니다.

41 42 43 31 32 33

ASCII라면:

ABC123

으로 읽을 수 있습니다.

하지만 문자열도 다음 항목을 확인해야 합니다.

Encoding

Maximum Length

Fixed Length 여부

Null Termination

Space Padding

Length Prefix

Delimiter

Null-terminated 방식#

예:

41 42 43 00

이라면:

ABC

뒤의 00이 문자열 종료를 나타낼 수 있습니다.

Fixed Length 방식#

문자열 Field가 항상 10 Byte라고 할 수도 있습니다.

실제 값:

ABC

뒤에:

00 00 00 00 00 00 00

또는 Space가 채워질 수 있습니다.

Length Prefix 방식#

다음처럼 구성할 수도 있습니다.

03 41 42 43

여기에서:

03
문자열 길이

41 42 43
ABC

를 의미할 수 있습니다.

따라서 Protocol 문서에서 String이라고 적혀 있는 것만으로 충분하지 않습니다.

7장 Bit Field는 한 Byte 안에 여러 상태를 넣는다#

산업 장비 Protocol에서는 한 Byte 또는 한 Word를 여러 Flag로 사용하는 경우가 많습니다.

예:

Status
0x05

Binary로 보면:

0000 0101

문서에서 다음처럼 정의했다고 가정합니다.

Bit 의미
0 Running
1 Alarm
2 Door Open
3 Remote Mode

0x05는:

0000 0101

이므로:

Bit 0 = 1
Running

Bit 1 = 0
Alarm 없음

Bit 2 = 1
Door Open

Bit 3 = 0
Remote Mode 아님

처럼 읽을 수 있습니다.

따라서:

Status = 5

라는 숫자 자체보다 각 Bit가 무엇을 의미하는지가 중요합니다.

문서에서 다음 표현을 발견하면 Bit Field를 의심합니다.

Bit 0

Bit 1

Flag

Mask

Reserved

0x01

0x02

0x04

0x08

8장 Length는 Packet Parser 설계를 좌우한다#

Packet을 프로그램으로 처리하려면 Frame이 언제 끝나는지 알아야 합니다.

대표적인 방법은 다음과 같습니다.

Fixed Length#

항상 16 Byte라면:

16 Byte 수신
↓
Packet 하나 완성

이라고 처리할 수 있습니다.

Length Field#

Header
Length
Data
CRC

구조라면 먼저 Length를 읽고 필요한 Byte가 전부 들어올 때까지 기다립니다.

Start·End Delimiter#

STX
...
ETX

처럼 시작과 종료 Byte를 이용할 수도 있습니다.

Line Delimiter#

ASCII Protocol에서는:

\r

\n

\r\n

등이 Message 종료 기준이 될 수 있습니다.

중요한 것은 Serial이나 TCP에서:

read()

한 번이 Packet 하나라는 보장이 없다는 점입니다.

예를 들어 장비가:

AA 55 01 04 10 20 30 40 7A

를 보냈는데 프로그램에서는:

첫 번째 Read
AA 55 01

두 번째 Read
04 10 20

세 번째 Read
30 40 7A

처럼 받을 수도 있습니다.

따라서 Protocol Parser는 Byte Stream에서 Frame을 다시 조립할 수 있어야 합니다.

9장 Checksum과 CRC는 계산 범위까지 읽어야 한다#

Protocol 문서에:

CRC16

이라고 적혀 있다고 해서 구현 준비가 끝난 것은 아닙니다.

최소한 다음을 확인해야 합니다.

Algorithm

Polynomial

Initial Value

Input Reflection

Output Reflection

Final XOR

Byte Order

계산 대상 범위

예를 들어 Packet:

02 01 10 02 12 34 XX XX 03

가 있다고 하겠습니다.

CRC 계산 범위가:

Address부터 Data까지

인지:

STX부터 Data까지

인지에 따라 결과가 달라집니다.

Checksum도 여러 방식이 있다#

다음과 같은 방식이 존재할 수 있습니다.

Byte 합계

XOR

Two's Complement

LRC

BCC

CRC

따라서 Checksum이라는 단어만 보고 계산식을 추정하면 안 됩니다.

문서의 공식이나 Sample Packet을 이용해 직접 계산해보고 결과가 일치하는지 확인해야 합니다.

10장 Request와 Response를 하나의 대화로 읽는다#

Protocol 문서는 Request만 읽는 것이 아니라 Response까지 연결해야 합니다.

예를 들어:

Request
Address 01
Command 10
Data 05

를 보냈다고 하겠습니다.

Response가:

Address 01
Command 10
Status 00

로 돌아올 수 있습니다.

여기에서 00이 성공이라고 문서가 정의했다면:

Request
↓
Command 10

Response
↓
Command 10
Status 00

이라는 대화를 구성할 수 있습니다.

Response Command가 다를 수도 있다#

예:

Request
0x10

Response
0x90

처럼 응답 Command Code를 별도로 정의하는 Protocol도 있습니다.

Error Response도 별도로 본다#

예:

Response
Command 0x90
Error 0x03

이라면 문서의 Error Code Table에서:

0x03
Invalid Parameter

같은 의미를 찾아야 합니다.

장비 연동 프로그램에서는 다음을 구분해야 합니다.

Response 없음
→ Timeout

Response 있음 + CRC 오류
→ Frame 오류

Response 있음 + Error Code
→ 장비가 명령을 거부

Response 있음 + Success
→ 정상 처리

이 네 가지는 전혀 다른 상황입니다.

11장 Timing 규칙도 Protocol의 일부다#

Packet 구조가 완벽해도 Timing 규칙을 지키지 않으면 통신이 되지 않을 수 있습니다.

문서에서 다음 용어를 찾습니다.

Response Timeout

Command Interval

Polling Interval

Inter-frame Delay

Turnaround Time

Busy Time

Retry Interval

예를 들어:

Response Time
Maximum 500 ms

라고 되어 있다면 프로그램이:

Timeout 100 ms

로 설정되어 있으면 정상 장비인데도 계속 Timeout으로 판단할 수 있습니다.

반대로 너무 긴 Timeout은 장애 감지를 늦춥니다.

Retry도 Protocol 의미를 고려한다#

상태 조회:

GET STATUS

같은 명령은 재전송해도 결과가 크게 달라지지 않을 가능성이 높습니다.

하지만:

PRINT

OPEN

RESET

COUNT +1

같은 상태 변경 명령은 첫 요청이 실제 처리되고 Response만 사라졌다면 재전송 시 중복 동작할 수 있습니다.

따라서 Protocol 문서에서 다음 기능도 확인합니다.

Sequence Number

Request ID

Transaction ID

Duplicate Detection

12장 실제 예제 Packet을 손으로 분해해보자#

가상의 Protocol 문서에 다음 Packet이 있다고 하겠습니다.

AA 55 03 21 04 34 12 78 56 9B

문서에서 다음처럼 정의했다고 가정합니다.

Offset Size Field
0 2 Header
2 1 Address
3 1 Command
4 1 Length
5 4 Data
9 1 Checksum

그러면:

AA 55
Header

03
Address

21
Command

04
Data Length

34 12 78 56
Data

9B
Checksum

입니다.

그런데 Data Field는 아직 해석이 끝난 것이 아닙니다.

문서에서 Data를:

Field A
uint16 Little Endian

Field B
uint16 Little Endian

이라고 정의했다고 하겠습니다.

첫 번째 값:

34 12

Little Endian이므로:

0x1234
=
4660

두 번째 값:

78 56

역시 Little Endian이므로:

0x5678
=
22136

가 됩니다.

즉 전체 Packet은:

Header
AA55

Device
03

Command
21

Length
4 Byte

Value A
4660

Value B
22136

Checksum
9B

로 읽을 수 있습니다.

이것이 Protocol 문서를 읽는 핵심 과정입니다.

HEX를 바로 의미로 바꾸는 것이 아니라 Frame → Field → Type → Byte Order → 값 순으로 단계적으로 해석합니다.

13장 Protocol 분석표를 만들어두면 구현이 훨씬 쉬워진다#

문서를 분석하면서 결과를 표로 정리하는 것이 좋습니다.

예:

Frame 정의#

Field Offset Size Type Byte Order 설명
Header 0 2 bytes - AA 55
Address 2 1 uint8 - Device Address
Command 3 1 uint8 - Command Code
Length 4 1 uint8 - Data Length
Value A 5 2 uint16 Little Sensor A
Value B 7 2 uint16 Little Sensor B
Checksum 9 1 uint8 - Frame 검사

Command 정의#

Command 방향 의미
0x01 Request Status 조회
0x02 Request Data 조회
0x10 Request 설정 변경
0x81 Response Status 응답
0x82 Response Data 응답

Error 정의#

Code 의미 처리
0x00 Success 정상
0x01 Invalid Command Command 확인
0x02 Invalid Length Frame 확인
0x03 Busy 일정 시간 후 재시도

이 정도까지 정리되면 실제 Code 구현은 상당히 쉬워집니다.

14장 문서가 애매하면 확정·추정·미확인을 구분한다#

실제 제조사 문서는 항상 완벽하지 않습니다.

다음처럼 적혀 있을 수도 있습니다.

DATA
2 Byte Value

그런데:

Signed?

Unsigned?

Big Endian?

Little Endian?

이 적혀 있지 않을 수 있습니다.

이때 임의로 결정하고 Code에 박아 넣으면 나중에 큰 문제가 생깁니다.

다음처럼 기록합니다.

Field
Temperature

Size
2 Byte

Type
미확인

Byte Order
미확인

그리고 Sample Packet과 실제 값을 비교합니다.

예를 들어 실제 장비 화면이:

Temperature
25.0°C

인데 Packet이:

00 FA

라면:

250
×
0.1
=
25.0

같은 Scale 적용 가능성을 추론할 수 있습니다.

하지만 문서에 없는 내용을 확인하지 않은 상태에서 이를 공식 규격이라고 기록하면 안 됩니다.

실무 문서에서는 다음처럼 구분하면 좋습니다.

확정
→ 제조사 문서와 실제 결과 일치

문서상
→ 문서에는 있으나 실장비 미검증

추정
→ Sample과 관찰값으로 추론

미확인
→ 추가 확인 필요

15장 Protocol 문서를 읽을 때 흔히 하는 실수#

HEX 표기를 실제 문자로 착각한다#

31

이 숫자 자체가 31이라는 의미일 수도 있고 ASCII 문자 1을 나타내는 Byte 0x31일 수도 있습니다.

Data Type과 Encoding을 확인해야 합니다.

Length를 전체 Packet 길이라고 가정한다#

Protocol에 따라 Data만 의미할 수도 있습니다.

CPU Architecture로 Byte Order를 결정한다#

장비 내부 CPU가 Little Endian이라고 Protocol까지 반드시 Little Endian인 것은 아닙니다.

Protocol 문서에 정의된 Byte Order가 기준입니다.

CRC가 있으니 안전한 Protocol이라고 생각한다#

CRC는 전송 오류 검출용입니다.

인증이나 암호화 기능을 제공하지 않습니다.

TCP를 쓰니까 Packet 경계가 보존된다고 생각한다#

TCP는 Byte Stream입니다.

한 번의 recv()가 하나의 Application Packet과 정확히 일치한다는 보장은 없습니다.

Length·Delimiter 등의 Protocol 규칙으로 Frame을 복원해야 합니다.

정상 Response를 받으면 실제 장비 동작도 성공했다고 생각한다#

Response가:

ACK

인 경우 명령 수신만 의미할 수도 있습니다.

실제 동작 완료 상태가 따로 존재하는지 확인해야 합니다.

16장 현장에서 사용할 Protocol 문서 분석 체크리스트#

문서 자체#

□ 정확한 Model용 문서인가?

□ Firmware Version이 맞는가?

□ Protocol Version을 확인했는가?

□ 문서 Revision을 확인했는가?

Transport#

□ RS-232·RS-422·RS-485·TCP·UDP 중 무엇인가?

□ Serial Parameter를 확인했는가?

□ TCP라면 Client·Server 역할을 확인했는가?

□ Port 번호를 확인했는가?

Frame#

□ Header가 있는가?

□ Address가 있는가?

□ Command가 있는가?

□ Length가 있는가?

□ Payload 위치를 확인했는가?

□ Checksum·CRC가 있는가?

□ 종료 조건을 확인했는가?

Data#

□ 각 Field의 Byte 크기를 확인했는가?

□ Signed·Unsigned를 확인했는가?

□ Integer·Float·ASCII·BCD를 구분했는가?

□ Byte Order를 확인했는가?

□ Word Order를 확인했는가?

□ Scale Factor가 있는가?

□ Unit을 확인했는가?

□ Bit Field가 있는가?

동작#

□ Request와 Response를 연결했는가?

□ Error Response를 확인했는가?

□ Timeout을 확인했는가?

□ Retry 조건을 확인했는가?

□ 중복 명령 위험을 검토했는가?

검증#

□ Sample Packet을 손으로 분해했는가?

□ Length 계산이 맞는가?

□ Checksum·CRC가 일치하는가?

□ 읽기 전용 Command로 확인했는가?

□ Raw TX·RX Log를 확보했는가?

17장 자기 점검#

Packet Format에서 가장 먼저 봐야 하는 것은 무엇인가#

Frame의 Field 순서와 각 Field의 Byte 크기입니다. Header·Address·Command·Length·Data·Checksum 등의 위치를 먼저 확정해야 합니다.

00 64는 어떤 값인가#

Data Type과 Byte Order를 알아야 결정할 수 있습니다. uint16 Big Endian이라면 100으로 해석할 수 있지만 다른 Type이라면 결과가 달라질 수 있습니다.

Length 값이 10이면 Data가 10 Byte라는 뜻인가#

반드시 그렇지는 않습니다. Payload만 의미하는지 전체 Frame 길이를 의미하는지 Protocol 문서의 정의와 Sample을 확인해야 합니다.

장비 CPU가 Little Endian이면 Protocol도 Little Endian인가#

반드시 그렇지 않습니다. 내부 Architecture와 외부 Protocol의 Byte Order는 별도로 정의될 수 있습니다.

CRC가 정상이라면 Command 처리도 성공한 것인가#

아닙니다. CRC는 Frame 손상 여부를 검사하는 기능이며 실제 Command 성공 여부는 Response Status나 Error Code를 별도로 확인해야 합니다.

18장 이 글을 마치며#

제조사 Protocol 문서를 실제 Packet으로 바꾸는 과정을 정리하면 다음과 같습니다.

Protocol Version 확인
↓
Transport 확인
↓
Packet Format 확인
↓
Field 위치·크기 확인
↓
Data Type 확인
↓
Byte Order 확인
↓
Length 규칙 확인
↓
Checksum·CRC 확인
↓
Command 분석
↓
Response 분석
↓
Error Code 분석
↓
Timing 확인
↓
Sample Packet 검증
↓
Simulator 검증
↓
실제 TX·RX 비교

특히 다음 원칙을 기억하면 됩니다.

원시 HEX를 바로 의미로 해석하지 말고 먼저 Header·Address·Command·Length·Data·Checksum 같은 Frame 구조로 분리해야 합니다.

같은 Byte 배열도 Data Type과 Byte Order에 따라 전혀 다른 값이 될 수 있으므로 Field의 크기·자료형·Endian을 항상 함께 확인해야 합니다.

Length·Checksum·CRC 같은 Field는 이름만 보고 의미를 추측하지 말고 계산 범위와 Sample Packet을 직접 대조해야 합니다.

Request와 Response를 하나의 대화로 읽고 정상 Response·Error Response·Timeout을 서로 다른 상태로 구분해야 실제 장애를 정확하게 판단할 수 있습니다.

문서에 없는 내용은 추정일 뿐이므로 확정 정보·문서상 정보·추정·미확인을 구분해 기록해야 합니다.

결국 Protocol 문서를 읽는 능력은 HEX 값을 많이 외우는 능력이 아닙니다.

AA 55 03 21 04 34 12 78 56 9B

이라는 한 줄을 보고:

어디서 시작하는가?

누구에게 보내는가?

무슨 명령인가?

몇 Byte를 읽어야 하는가?

각 Byte는 어떤 Type인가?

숫자는 어떤 순서로 조립하는가?

Packet이 정상인지 어떻게 확인하는가?

장비는 성공과 실패를 어떻게 알려주는가?

를 차례대로 질문할 수 있는 능력입니다.

이 질문에 답할 수 있게 되면 센서, 계측기, PLC, Reader, Printer, Controller, Gateway처럼 제조사와 용도가 전혀 다른 장비를 만나도 같은 방법으로 Protocol 문서를 분석할 수 있습니다.

이 페이지의 목차