장비 매뉴얼만 보고 통신 방식을 찾아내는 방법: Interface·Protocol·Command 분석 실전 가이드

장비 매뉴얼만 보고 통신 방식을 찾아내는 방법: Interface·Protocol·Command 분석 실전 가이드#

1장 처음 보는 장비 앞에서 무엇부터 확인해야 할까#

새로운 장비 연동 업무를 맡으면 개발자는 흔히 다음 질문부터 시작합니다.

이 장비하고 어떻게 통신하지?

하지만 이 질문은 아직 너무 큽니다.

장비와 통신하려면 최소한 다음 정보를 알아야 합니다.

장비
│
├─ 정확한 모델은 무엇인가?
├─ 펌웨어 버전은 무엇인가?
├─ 어떤 Connector가 있는가?
├─ 전기적 Interface는 무엇인가?
├─ 통신 Parameter는 무엇인가?
├─ 어떤 Protocol을 사용하는가?
├─ Device Address가 필요한가?
├─ 어떤 Command가 존재하는가?
├─ Response는 어떤 구조인가?
└─ Error를 어떻게 표현하는가?

현장에서 장비가 응답하지 않는다고 하더라도 원인은 전혀 다른 계층에 있을 수 있습니다.

잘못된 Cable
잘못된 전압 Level
잘못된 Baud Rate
잘못된 IP
잘못된 Port
잘못된 Device Address
잘못된 Command
잘못된 Checksum
잘못된 Response 해석

따라서 장비 매뉴얼을 읽을 때 가장 중요한 것은 특정 명령어 하나를 찾는 것이 아닙니다.

장비와 프로그램 사이에 존재하는 통신 계층을 하나씩 분리하는 것이 출발점입니다.

전체 흐름은 다음처럼 생각하면 쉽습니다.

Model
↓
Connector
↓
Electrical Interface
↓
Communication Parameter
↓
Protocol
↓
Frame
↓
Command
↓
Response
↓
Application

이 순서를 기억해 두면 제조사가 달라져도 비슷한 방식으로 문서를 분석할 수 있습니다.

2장 모델명과 펌웨어부터 확정해야 하는 이유#

매뉴얼을 찾기 전에 가장 먼저 확인해야 할 것은 장비의 정확한 Model입니다.

겉모습이 비슷하다고 같은 제품이라고 판단하면 안 됩니다.

예를 들어 같은 제품군에서도:

ABC-100

ABC-100A

ABC-100E

ABC-100-RS485

ABC-100-ETH

처럼 Interface가 다른 모델이 존재할 수 있습니다.

또한 같은 Model이라도 Firmware Version에 따라:

지원 Command 추가

Packet Format 변경

CRC 방식 변경

TCP Port 변경

Register Map 추가

Bug Fix

등이 발생할 수 있습니다.

현장에서 가능하면 다음 정보를 먼저 확보합니다.

확인 항목 예
Manufacturer 제조사명
Product Name 제품명
Model ABC-100
Hardware Revision Rev. B
Firmware Version 2.3.1
Serial Number 장비 고유번호
Interface Option RS-485 / Ethernet

장비 Label을 사진으로 남기는 것도 좋습니다.

특히 다음 표기를 확인합니다.

MODEL

REV

FW

INPUT

OUTPUT

COM

RS232

RS485

LAN

CAN

USB

ADDRESS

이 단계에서 모델을 잘못 확인하면 이후에 찾은 모든 통신 정보가 맞지 않을 수 있습니다.

매뉴얼도 종류가 여러 개다#

제조사는 하나의 제품에 여러 문서를 제공할 수 있습니다.

User Manual
Installation Manual
Communication Manual
Protocol Manual
Programming Manual
Register Map
API Guide
Command Reference
Integration Guide
Quick Start Guide
Firmware Release Note

일반 User Manual에는 통신 방법이 거의 나오지 않고 별도의 Communication Manual이나 Protocol Specification에만 Packet 구조가 들어 있는 경우도 많습니다.

따라서 제품 매뉴얼 하나를 찾았다고 문서 조사가 끝난 것이 아닙니다.

3장 Connector 모양만 보고 통신 방식을 결정하면 안 된다#

장비 뒤쪽을 보면 다음과 같은 Connector를 만날 수 있습니다.

DB9

RJ45

Terminal Block

USB

M12

D-Sub

Screw Terminal

여기서 흔히 하는 실수가 있습니다.

DB9
=
RS-232

또는:

RJ45
=
Ethernet

이라고 바로 판단하는 것입니다.

Connector의 형태와 실제 전기 Interface는 같은 개념이 아닙니다.

예를 들어 RJ45 Connector를 사용하면서 Ethernet이 아니라 제조사 전용 Serial Signal을 전달하는 제품도 존재할 수 있습니다.

Terminal Block에는:

A
B
GND

가 있을 수도 있고:

TX+
TX-
RX+
RX-

가 있을 수도 있습니다.

또는:

D+
D-

처럼 제조사별 표기를 사용할 수도 있습니다.

따라서 반드시 매뉴얼의 다음 항목을 찾습니다.

Connector

Pin Assignment

Pinout

Terminal Assignment

Communication Port

Electrical Interface

Pinout 표가 중요한 이유#

예:

Pin Signal 설명
1 GND Signal Ground
2 RXD Receive Data
3 TXD Transmit Data

이런 표를 발견했다면 RS-232 계열 Serial Interface일 가능성을 판단하는 강한 단서가 됩니다.

반대로:

Terminal Signal
1 A
2 B
3 SG

라면 RS-485 계열 Interface를 의심할 수 있습니다.

하지만 Signal 이름만으로 최종 확정하지 말고 Electrical Specification까지 확인하는 것이 좋습니다.

4장 매뉴얼에서 통신 방식을 찾는 검색어를 알아두자#

100페이지가 넘는 PDF를 처음부터 끝까지 읽을 필요는 없습니다.

먼저 문서 검색 기능으로 다음 단어를 찾습니다.

Serial 계열#

Serial

UART

RS-232
RS232

RS-422
RS422

RS-485
RS485

Baud
Baud Rate

Parity

Stop Bit

Data Bit

Flow Control

Network 계열#

Ethernet

TCP

UDP

TCP/IP

IP Address

Subnet

Gateway

Port

Socket

DHCP

Protocol 계열#

Protocol

Communication Protocol

Command

Message

Frame

Packet

Request

Response

Register

Function Code

Checksum

CRC

BCC

Device 식별 관련#

Address

Device ID

Node ID

Station ID

Slave ID

Unit ID

API 계열#

API

REST

HTTP

HTTPS

JSON

XML

Webhook

MQTT

Topic

이 검색어만 활용해도 문서에서 통신 관련 부분을 상당히 빠르게 찾을 수 있습니다.

5장 물리 Interface와 Protocol을 반드시 분리해서 읽는다#

장비 통신을 처음 배우는 개발자에게 가장 중요한 개념입니다.

다음은 서로 같은 종류의 정보가 아닙니다.

RS-485

Modbus RTU

RS-485는 주로 전기적인 통신 Interface를 설명합니다.

Modbus RTU는 그 위에서 사용할 수 있는 Protocol입니다.

전체적으로 보면:

Application
│
│ Modbus RTU
│ 제조사 Protocol
│ 기타 Protocol
│
├────────────────
│
│ RS-485
│ RS-232
│ RS-422
│
├────────────────
│
Cable / Signal

따라서 매뉴얼에:

Interface
RS-485

Protocol
Modbus RTU

라고 적혀 있다면 두 정보를 함께 기록해야 합니다.

반대로:

RS-485 지원

이라고만 적혀 있다고 해서 Modbus를 사용한다고 판단하면 안 됩니다.

제조사 자체 Protocol일 수도 있습니다.

Ethernet도 마찬가지다#

Ethernet

이라고 적혀 있다고 해서 어떤 Application Protocol인지 알 수 있는 것은 아닙니다.

그 위에서:

TCP Socket

UDP

HTTP

HTTPS

Modbus TCP

MQTT

OPC UA

제조사 Protocol

등 다양한 통신이 사용될 수 있습니다.

따라서:

Interface가 무엇인가

와:

그 Interface 위에서 어떤 Protocol이 동작하는가

를 항상 별도로 기록합니다.

6장 Serial 장비라면 통신 Parameter를 모두 찾아야 한다#

매뉴얼에서 다음과 같은 표를 발견했다고 하겠습니다.

Baud Rate    9600
Data Bits    8
Parity       Even
Stop Bits    1

흔히:

9600-8-E-1

처럼 표현할 수 있습니다.

하지만 여기서 끝이 아닙니다.

Serial 통신에서는 다음 항목을 확인합니다.

항목 확인 내용
Interface RS-232·RS-422·RS-485
Baud Rate 9600·19200·115200 등
Data Bits 7·8 등
Parity None·Even·Odd
Stop Bits 1·2 등
Flow Control None·RTS/CTS·XON/XOFF
Duplex Half·Full
Device Address 필요한지 확인
Termination RS-485·422에서 확인
Connector DB9·Terminal 등
Pinout TX·RX·A·B 등

예를 들어:

RS-485
9600
8
Even
1
Address 01

이라고 되어 있다면 프로그램에서는 최소한 이 설정이 맞아야 합니다.

PC
9600-8-E-1

Device
9600-8-E-1

장비는 9600인데 프로그램만 19200으로 설정되어 있으면 Protocol을 아무리 정확하게 구현해도 정상적인 통신을 기대하기 어렵습니다.

기본값과 현장 설정값을 구분한다#

매뉴얼에:

Default Baud Rate
9600

이라고 적혀 있다고 해서 현장 장비도 반드시 9600이라고 생각하면 안 됩니다.

설치 과정에서 다음이 변경될 수 있습니다.

Baud Rate

Device Address

Parity

Operating Mode

따라서:

Manual Default

와:

Current Device Configuration

은 구분해야 합니다.

7장 Ethernet 장비에서는 IP보다 Port와 역할까지 봐야 한다#

Ethernet 장비라면 다음 항목을 찾습니다.

IP Address

Subnet Mask

Default Gateway

DHCP

TCP / UDP

Port Number

Server / Client

Connection Limit

Keepalive

Timeout

예를 들어:

IP
192.168.10.50

TCP Port
5000

이라고 되어 있다면 아직 정보가 충분하지 않습니다.

다음 질문이 남습니다.

장비가 TCP Server인가?

장비가 TCP Client인가?

연결 후 먼저 누가 Message를 보내는가?

연결을 계속 유지하는가?

매번 연결하고 끊는가?

Heartbeat가 필요한가?

예를 들어 두 장비 모두 TCP를 사용하지만 구조는 전혀 다를 수 있습니다.

장비가 Server인 경우#

Application
↓
connect()
↓
Device TCP Server

프로그램이 장비에 접속합니다.

장비가 Client인 경우#

Device
↓
connect()
↓
Application TCP Server

장비가 중앙 Server에 접속합니다.

Port 번호만 보고 이 역할을 놓치면 프로그램 구조 자체를 잘못 만들 수 있습니다.

8장 Protocol 이름을 찾았으면 공식 규격과 제조사 확장을 구분한다#

매뉴얼에 다음 문장이 있다고 하겠습니다.

Protocol: Modbus RTU

이것은 매우 중요한 단서입니다.

Modbus는 Application Layer Protocol이며 Request·Response와 Function Code 구조를 사용합니다. Modbus Organization의 공식 문서에서도 Modbus TCP 통신에는 등록 Port 502가 사용되고, Serial Line 구현에서는 Address·Baud Rate·Character Format·Electrical Interface 등이 주요 설정 요소로 다뤄집니다.

그러나 여기에서도 주의해야 합니다.

Modbus를 사용한다고 해서:

Register 40001
=
온도

처럼 데이터의 의미까지 표준화되는 것은 아닙니다.

제조사가 별도의 Register Map을 정의합니다.

예:

Register 100
Temperature

Register 101
Humidity

Register 200
Alarm Status

따라서 필요 문서는 두 종류입니다.

Modbus Specification
+
Manufacturer Register Map

이 원칙은 다른 Protocol도 비슷합니다.

표준 Protocol
+
제조사 Data Mapping

을 함께 봐야 실제 장비를 제어할 수 있습니다.

9장 Protocol 이름이 없다면 Frame 구조를 찾는다#

매뉴얼에 Protocol 이름이 없더라도 다음과 같은 표가 있을 수 있습니다.

Packet Format

Header
Address
Command
Length
Data
Checksum

이것만 있어도 상당한 정보를 얻을 수 있습니다.

예:

STX
Address
Command
Length
Data
Checksum
ETX

라면 다음과 같은 Frame 구조를 예상할 수 있습니다.

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

각 항목은 서로 다른 역할을 합니다.

Header·STX#

Packet의 시작을 찾습니다.

Address#

여러 장비 중 대상 장비를 구분할 수 있습니다.

Command#

장비에 무엇을 요청하는지 나타냅니다.

Length#

뒤에 몇 Byte가 오는지 알려줄 수 있습니다.

Data#

실제 Parameter나 결과가 들어갑니다.

Checksum·CRC#

전송 중 데이터 오류를 검사합니다.

ETX·Delimiter#

Packet 끝을 나타낼 수 있습니다.

이 구조를 찾았다면 다음 단계는 각 Field가 몇 Byte인지 기록하는 것입니다.

10장 ASCII Protocol과 Binary Protocol을 구분한다#

매뉴얼에 다음 예제가 있다고 하겠습니다.

READ,TEMP,01<CR><LF>

사람이 읽을 수 있습니다.

ASCII나 Text 기반 Protocol일 가능성이 높습니다.

반면:

02 01 10 00 04 A7 31 03

처럼 보인다면 Binary Protocol일 가능성이 있습니다.

ASCII Protocol에서 찾아야 할 것#

Encoding

Command 문자열

Field Separator

CR

LF

Delimiter

숫자 표현 방식

예:

GET,STATUS,01\r\n

이라면:

GET
Command

STATUS
Target

01
Device

\r\n
Message 종료

처럼 해석할 수 있습니다.

Binary Protocol에서 찾아야 할 것#

Byte Order

Field Length

Signed / Unsigned

Integer Size

Float Format

BCD

Bit Mask

Checksum

CRC

Escape 처리

특히 다음 용어가 나오면 주의해서 읽어야 합니다.

Big Endian

Little Endian

MSB

LSB

High Byte

Low Byte

예:

12 34

가 실제 값 0x1234인지 0x3412인지 Byte Order에 따라 달라질 수 있습니다.

11장 Command 표는 장비 연동의 핵심 문서다#

통신 Parameter까지 맞았다면 다음으로 찾아야 할 것은 Command Table입니다.

예:

Command Code 설명
Get Status 0x01 장비 상태 조회
Read Data 0x02 현재 데이터 조회
Reset 0x10 장비 Reset
Set Config 0x20 설정 변경

여기에서 처음 테스트할 명령은 신중하게 선택해야 합니다.

가장 좋은 것은:

Status Read

Version Read

Device Information Read

같은 읽기 전용 명령입니다.

반대로 처음부터:

Reset

Initialize

Erase

Format

Motor Start

Valve Open

Gate Open

Firmware Update

같은 Command를 보내는 것은 피하는 것이 좋습니다.

현장 장비에서는 하나의 Byte가 실제 Motor·Relay·Valve 등의 물리 동작을 일으킬 수 있기 때문입니다.

Request와 Response를 함께 본다#

매뉴얼에서 Request만 보면 부족합니다.

다음도 확인해야 합니다.

정상 Response

Error Response

Timeout

Busy

Unsupported Command

Invalid Parameter

예:

Request
01 03 00 10 ...

Response
01 03 02 00 64 ...

Error
01 83 02 ...

처럼 정상과 Error Frame의 형태가 다를 수 있습니다.

12장 매뉴얼에서 반드시 뽑아야 할 정보를 한 장으로 정리한다#

실무에서는 매뉴얼을 계속 뒤지는 것보다 분석 결과를 별도의 표로 만들어두는 것이 좋습니다.

예를 들어 다음 형식을 사용할 수 있습니다.

구분 확인 결과 출처
Manufacturer ABC 제품 Label
Model X100 제품 Label
Firmware 2.1.4 System 화면
Connector 3-Pin Terminal Manual p.23
Interface RS-485 2-Wire Manual p.24
Baud Rate 9600 Manual p.25
Data Bits 8 Manual p.25
Parity Even Manual p.25
Stop Bits 1 Manual p.25
Address 1~247 Protocol Manual
Protocol Modbus RTU Protocol Manual
Device Address 현재 5 현장 설정
Register Map 별도 문서 Register Map
CRC Modbus CRC Protocol Spec
Termination 현장 확인 배선 점검

이 표에서 특히 중요한 것이:

문서에 적힌 값

실제 현장 값

을 구분하는 것입니다.

예:

Default Address
1

Current Address
17

처럼 별도로 적어야 합니다.

13장 문서에서 찾은 정보를 바로 실장비에 적용하지 않는다#

매뉴얼 분석이 끝났다고 바로 Write Command를 보내는 것은 좋은 방법이 아닙니다.

검증 순서는 다음처럼 잡는 것이 안전합니다.

문서 분석
↓
설정표 작성
↓
Sample Packet 확인
↓
Simulator 구성
↓
Read-only Command 시험
↓
Response 확인
↓
현장 연결
↓
다시 Read-only 검증
↓
필요한 제어 Command 검증

가장 먼저 확인할 수 있는 것#

Serial 장비라면:

Port Open 가능?

Byte가 들어오는가?

Status 조회가 되는가?

TCP 장비라면:

Link Up?

IP 도달 가능?

TCP Connection 가능?

읽기용 Command Response?

순서로 확인합니다.

연결 성공과 Protocol 성공을 같은 것으로 생각하지 않는 것이 중요합니다.

TCP connect()가 성공했다는 것은 Socket 연결이 됐다는 뜻이지 장비 Protocol이 정상이라는 뜻은 아닙니다.

14장 응답이 없을 때는 추측하지 말고 계층별로 확인한다#

장비에 명령을 보냈는데 아무 Response도 없다고 하겠습니다.

이때 바로:

Protocol이 틀린 것 같다.

라고 판단하면 안 됩니다.

1단계 장비#

Power

Boot 상태

Fault

Operating Mode

2단계 Connector·Cable#

Connector

Pinout

Cable

TX / RX

A / B

Ground

3단계 Interface#

RS-232인가?

RS-485인가?

RS-422인가?

TTL UART인가?

TTL UART와 RS-232는 같은 것이 아닙니다.

전압 Level이 다른 Interface를 직접 연결하면 정상 통신하지 않을 뿐 아니라 Hardware Damage 위험도 있습니다.

4단계 Communication Parameter#

Baud

Data Bits

Parity

Stop Bits

Flow Control

5단계 Protocol#

Address

Command

Length

Data

CRC

6단계 Timing#

Response Timeout

Inter-frame Delay

Polling Interval

Turnaround Time

7단계 Application#

Parser

Buffer

Encoding

Byte Order

Retry

이 방식으로 접근하면 장애 범위를 상당히 빠르게 줄일 수 있습니다.

15장 흔히 발견하는 매뉴얼 표현을 읽는 법#

장비 매뉴얼에는 짧은 문장 안에 중요한 정보가 들어 있습니다.

Communication: RS-485#

알 수 있는 것:

전기 Interface
RS-485

아직 모르는 것:

Protocol
Baud Rate
Address
Command

9600, 8, N, 1#

알 수 있는 것:

Baud
9600

Data Bits
8

Parity
None

Stop Bits
1

Modbus RTU#

알 수 있는 것:

상위 Protocol
Modbus RTU

추가로 찾아야 할 것:

Device Address

Register Map

지원 Function Code

Baud·Parity

TCP Server Port 5000#

알 수 있는 것:

TCP 사용

장비가 Server 역할

Listening Port
5000

추가로 찾아야 할 것:

Packet Format

Connection 유지 방식

Heartbeat

Timeout

Request / Response

ASCII Command#

알 수 있는 것:

Text 기반 Command 가능성

추가 확인:

Encoding

Delimiter

CR / LF

Field Separator

CRC-16#

아직 정보가 부족합니다.

CRC-16이라는 이름만으로 구현 방식을 확정하지 않습니다.

추가 확인할 수 있는 항목:

Polynomial

Initial Value

RefIn

RefOut

XorOut

Byte Order

CRC 계산 범위

이런 습관이 생기면 매뉴얼 한 문장에서 확실히 아는 것과 아직 모르는 것을 분리할 수 있습니다.

16장 문서가 애매할 때는 증거의 우선순위를 정한다#

실무에서는 문서끼리 내용이 다른 경우도 있습니다.

예:

User Manual
9600

Protocol Manual
19200

현장 장비 설정
38400

이런 상황에서는 무작정 하나를 선택하지 않습니다.

다음 정보를 함께 확인합니다.

정확한 Model

Hardware Revision

Firmware Version

Manual Version

Manual 발행일

장비 현재 설정

설치 기록

정상 동작 중인 동일 장비

증거를 다음처럼 관리하는 것도 좋습니다.

확정
→ 실제 장비와 문서가 일치함

문서상 정보
→ 아직 실제 장비 미확인

추정
→ 여러 단서를 근거로 추론

미확인
→ 추가 확인 필요

예:

항목 값 신뢰도
Interface RS-485 확정
Baud Rate 9600 문서상 정보
Address 5 확정
Protocol 제조사 Binary 확정
CRC CRC-16 계열 추정
CRC Parameter 미상 미확인

이렇게 기록하면 나중에 추정값이 마치 공식 규격처럼 굳어지는 것을 막을 수 있습니다.

17장 범용 장비 연동 체크리스트#

새로운 장비를 받으면 다음 순서로 확인하면 됩니다.

장비 식별#

□ 제조사를 확인했는가?

□ 정확한 Model을 확인했는가?

□ Hardware Revision을 확인했는가?

□ Firmware Version을 확인했는가?

□ 올바른 Manual Version을 확보했는가?

Hardware Interface#

□ Connector 종류를 확인했는가?

□ Pinout을 확보했는가?

□ RS-232·RS-422·RS-485·Ethernet 등을 구분했는가?

□ TTL UART 여부를 확인했는가?

□ 전압 Level을 확인했는가?

□ Ground 연결 정책을 확인했는가?

Serial 설정#

□ Baud Rate

□ Data Bits

□ Parity

□ Stop Bits

□ Flow Control

□ Duplex

□ Device Address

□ Termination

Network 설정#

□ IP Address

□ Subnet Mask

□ Gateway

□ DHCP / Static

□ TCP / UDP

□ Port

□ Client / Server 역할

□ Timeout

□ Heartbeat

Protocol#

□ Protocol 이름

□ ASCII / Binary

□ Frame 시작 조건

□ Frame 종료 조건

□ Address

□ Command

□ Length

□ Payload

□ Checksum / CRC

□ Byte Order

□ 정상 Response

□ Error Response

검증#

□ Simulator에서 시험했는가?

□ 읽기 전용 Command부터 시험했는가?

□ TX / RX Hex Log를 남기는가?

□ Timeout을 설정했는가?

□ 실장비 제어 명령의 영향을 확인했는가?

□ 원복·비상정지 수단이 있는가?

18장 개발자가 최종적으로 만들어야 할 것은 통신 코드가 아니라 장비 명세다#

장비 연동 작업에서 바로 Code부터 작성하면 다음과 같은 코드가 만들어지기 쉽습니다.

COM3

9600

Address 01

Command 0x10

가 Source Code 안에 아무 설명 없이 Hard Coding됩니다.

몇 달 후 장비가 교체되면 아무도 이 값의 출처를 모릅니다.

그래서 먼저 장비 통신 명세표를 만드는 것이 좋습니다.

예:

DEVICE
Temperature Controller

MODEL
TC-200

FIRMWARE
1.4

INTERFACE
RS-485 2-Wire

PROTOCOL
Modbus RTU

SERIAL
19200-8-E-1

DEVICE ADDRESS
17

SUPPORTED FUNCTIONS
03
06
16

REGISTER MAP
100 Temperature
101 Set Point
102 Alarm

TIMEOUT
500 ms

RETRY
2

SOURCE
Protocol Manual Rev 1.4

이 문서가 있으면:

개발

테스트

현장 설치

장애 대응

장비 교체

모두 같은 기준을 사용할 수 있습니다.

Code는 이 명세를 구현한 결과여야 합니다.

19장 자기 점검#

DB9 Connector가 있으면 무조건 RS-232인가#

아닙니다. Connector 형태만으로 Electrical Interface를 확정하면 안 되며 Pinout과 장비 사양을 확인해야 합니다.

RS-485라고 적혀 있으면 Modbus를 사용한다는 뜻인가#

아닙니다. RS-485는 물리적 Interface이고 Modbus RTU나 제조사 전용 Protocol 등 다양한 상위 Protocol이 사용될 수 있습니다.

Ethernet Port가 있으면 HTTP API를 사용할 수 있는가#

반드시 그렇지는 않습니다. TCP Socket·UDP·Modbus TCP·제조사 Protocol 등 다양한 방식이 있을 수 있습니다.

매뉴얼의 Default Baud Rate를 그대로 사용하면 되는가#

현장에서 설정이 변경됐을 수 있으므로 현재 장비 설정을 별도로 확인해야 합니다.

CRC-16이라고 적혀 있다면 바로 구현할 수 있는가#

충분하지 않을 수 있습니다. Polynomial·Initial Value·Bit Reflection·Final XOR·Byte Order·계산 범위 등을 추가로 확인해야 합니다.

가장 먼저 전송하기 좋은 Command는 무엇인가#

가능하면 Device Information·Version·Status 같은 읽기 전용 명령부터 검증하는 것이 좋습니다.

20장 이 글을 마치며#

장비 매뉴얼만 가지고 통신 방식을 찾아내는 과정을 다시 정리하면 다음과 같습니다.

장비 Label 확인
↓
Model·Firmware 확정
↓
올바른 Manual 확보
↓
Connector 확인
↓
Pinout 확인
↓
Electrical Interface 확인
↓
Serial 또는 Network Parameter 확인
↓
Protocol 확인
↓
ASCII / Binary 확인
↓
Packet 구조 확인
↓
Command Table 확인
↓
Response·Error 확인
↓
Simulator 검증
↓
Read-only 실장비 검증
↓
통신 명세 작성
↓
프로그램 구현

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

Connector 모양만 보고 통신 방식을 결정하지 말고 Pinout과 Electrical Interface까지 확인해야 합니다.

RS-232·RS-422·RS-485·Ethernet 같은 전달 방식과 Modbus·ASCII·Binary·HTTP 같은 Protocol을 서로 다른 계층으로 구분해야 합니다.

매뉴얼의 기본 설정과 실제 현장 장비에 적용된 설정은 다를 수 있으므로 Default 값과 Current 값을 별도로 기록해야 합니다.

Protocol을 찾은 뒤에는 Command만 볼 것이 아니라 Request·Response·Error·Timeout·Checksum까지 하나의 대화 구조로 읽어야 합니다.

매뉴얼에 적힌 사실과 현장에서 확인한 사실, 개발자가 추정한 내용을 구분해서 기록해야 잘못된 가정이 장비 규격처럼 굳어지는 것을 막을 수 있습니다.

실제 제어 명령을 보내기 전에 Simulator와 읽기 전용 Command로 통신 경로를 먼저 검증해야 합니다.

결국 장비 매뉴얼을 잘 읽는다는 것은 PDF에서 Baud Rate 하나를 찾아내는 능력이 아닙니다.

장비의 Connector에서 시작해 전기적 Interface, 통신 Parameter, Protocol, Packet, Command, Response까지 서로 다른 계층의 정보를 하나의 통신 명세로 재구성하는 능력입니다.

이 과정을 익히면 PLC, 센서, 계측기, Barcode Reader, Printer, 출입통제 장비, 키오스크, IoT Gateway, 산업용 Controller처럼 처음 접하는 장비도 같은 방법으로 접근할 수 있습니다.

장비가 달라져도 질문의 순서는 크게 달라지지 않습니다.

무엇과 연결하는가?

어떤 전기 신호를 사용하는가?

어떤 설정으로 통신하는가?

어떤 규칙으로 Message를 만드는가?

무엇을 보내면 무엇이 돌아오는가?

실패했을 때 무엇이 남는가?

이 여섯 가지 질문에 답할 수 있다면, 이미 그 장비를 프로그램에서 연동하기 위한 상당 부분의 준비가 끝난 것입니다.

이 페이지의 목차