[주차권 발행기]는 어떻게 동작할까? Ticket Command·Paper Sensor·ACK·오류 처리 이해하기

주차권 발행기는 어떻게 동작할까? Ticket Command·Paper Sensor·ACK·오류 처리 이해하기#

1장 티켓 발행 버튼을 누르면 내부에서는 무슨 일이 일어날까#

주차장 입구에서 차량이 들어오면 운전자는 버튼을 누르거나, 시스템이 자동으로 차량을 감지해 티켓 발행을 시작할 수 있습니다.

겉으로 보면 단순합니다.

차량 진입
↓
티켓 발행
↓
주차권 출력

하지만 실제 시스템에서는 여러 장비와 상태가 연결됩니다.

차량
↓
차량검지기
↓
주차관제 Controller
↓
Ticket Command
↓
주차권 발행기
↓
Printer 상태 확인
↓
Paper Sensor 확인
↓
인쇄·절단·배출
↓
완료 상태
↓
Controller

따라서:

발행 명령을 보냈다

와:

티켓이 실제로 정상 출력됐다

는 서로 다른 상태입니다.

이 구분이 주차권 발행기 장애 진단의 출발점입니다.

2장 주차권 발행기는 어떤 장비인가#

주차권 발행기는 단순한 Printer가 아닙니다.

일반적으로 다음 요소가 결합되어 있습니다.

Communication Interface

Controller / MCU

Printer Module

Paper Feed Motor

Paper Sensor

Cutter

Ticket Outlet Sensor

Status LED

Button 또는 Trigger Input

제품에 따라:

Barcode

QR Code

Magnetic Stripe

RFID

할인 정보

입차 시간

등을 티켓에 기록할 수도 있습니다.

즉 주차권 발행기는:

명령을 받고 → 현재 상태를 판단하고 → 종이를 이동시키고 → 정보를 인쇄하고 → 티켓을 배출한 뒤 → 처리 결과를 상위 시스템에 알려주는 장비

라고 볼 수 있습니다.

3장 Ticket Command는 무엇인가#

Ticket Command는 발행기에게 티켓을 출력하도록 요청하는 명령입니다.

예를 들어 상위 Controller가 다음과 같은 의미의 명령을 보낼 수 있습니다.

ISSUE_TICKET

또는 제조사 Protocol에서는:

Command Code
0x31

같은 Binary 값으로 정의할 수도 있습니다.

명령에는 다음 정보가 포함될 수 있습니다.

Ticket Type

Entry Time

Lane ID

Sequence Number

Vehicle Type

Print Text

Barcode Data

다만 실제 Field와 Command Code는 제조사마다 완전히 다릅니다.

따라서:

티켓 발행 명령
=
특정한 표준 Packet

이라고 생각해서는 안 됩니다.

주차권 발행기의 Protocol은 반드시 해당 제조사의 통신 명세를 확인해야 합니다.

4장 발행기는 명령을 받자마자 인쇄하지 않는다#

발행기가 Ticket Command를 받았다고 바로 Motor를 돌리는 것은 아닙니다.

일반적으로 내부 상태를 먼저 확인합니다.

Ticket Command 수신
↓
Printer Ready?
↓
Paper 존재?
↓
Paper Jam?
↓
Cutter 정상?
↓
Door 상태 정상?
↓
내부 Fault 없음?
↓
출력 시작

예를 들어 Paper Sensor가:

NO PAPER

상태라면 발행기는 명령을 거부할 수 있습니다.

Printer가 이미 다른 티켓을 출력 중이라면:

BUSY

를 반환할 수도 있습니다.

따라서 상위 프로그램에서는 단순히:

Command 전송 성공

만 확인하면 안 됩니다.

5장 Printer Status를 이해하면 장애가 보인다#

주차권 발행기는 여러 내부 상태를 가질 수 있습니다.

예:

READY

PRINTING

BUSY

PAPER_LOW

PAPER_EMPTY

PAPER_JAM

CUTTER_ERROR

OFFLINE

ERROR

이런 상태를 하나의 Boolean 값:

printerOk = true

로 처리하면 장애 분석이 어려워집니다.

차라리:

Printer State

Paper State

Cutter State

Communication State

처럼 나누는 것이 좋습니다.

예를 들어:

Communication
ONLINE

Printer
READY

Paper
EMPTY

라면 통신은 정상인데 티켓 발행은 불가능한 상태입니다.

6장 Paper Sensor는 종이 상태를 어떻게 판단할까#

발행기에는 여러 Paper Sensor가 있을 수 있습니다.

제품에 따라:

Paper Roll Sensor

Paper Entry Sensor

Paper Exit Sensor

Ticket Taken Sensor

등을 사용할 수 있습니다.

예를 들어 다음 구조를 생각해볼 수 있습니다.

Paper Roll
↓
Paper Sensor
↓
Print Head
↓
Cutter
↓
Exit Sensor
↓
Ticket Outlet

이 Sensor들의 조합으로 다음 상태를 판단할 수 있습니다.

종이 있음

종이 부족

종이 없음

종이 이동 중

Ticket 배출 완료

Ticket 미수거

따라서 화면에:

PAPER ERROR

가 표시되어도 실제 원인은 하나가 아닐 수 있습니다.

7장 Paper Jam과 Out of Paper는 완전히 다른 장애다#

둘 다 티켓이 나오지 않지만 원인은 다릅니다.

Out of Paper#

용지가 실제로 소진된 상태입니다.

Paper Roll
EMPTY

주로 확인할 것은:

용지 잔량

Paper Sensor

Sensor Cable

용지 장착 방향

입니다.

Paper Jam#

용지는 있지만 정상적으로 이동하지 못하는 상태입니다.

Paper 존재
↓
Motor 구동
↓
Paper 이동 실패
↓
Jam

가능한 원인은:

잘못된 용지 규격

Cutter 걸림

Roller 오염

용지 접힘

Paper Path 이물질

Motor 문제

등입니다.

따라서 상위 시스템에서도:

PAPER_EMPTY

와:

PAPER_JAM

을 구분해 관리하는 것이 좋습니다.

8장 실제 티켓 출력은 여러 단계로 진행된다#

발행 명령이 허용되면 내부에서는 대략 다음 흐름이 진행될 수 있습니다.

Ticket Command
↓
Paper Feed
↓
Print
↓
Barcode / QR 출력
↓
Cut
↓
Ticket 배출
↓
Exit Sensor 확인
↓
완료

제품에 따라 Cutter가 없거나, 미리 절단된 Ticket를 공급하는 방식일 수도 있습니다.

Thermal Printer라면 감열지를 사용해 열로 문자를 출력합니다.

따라서 Ribbon을 사용하는 Printer와 구조가 다릅니다.

현장에서는 반드시 사용 중인 Printer Module의 방식을 확인해야 합니다.

9장 RS-232는 발행기와 Controller를 연결하는 대표적인 방법이다#

오래된 주차권 발행기나 일부 전용 장비에서는 RS-232 통신을 자주 볼 수 있습니다.

전체 구조:

Parking Controller
↓
RS-232
↓
Ticket Dispenser

예를 들어 통신 조건이:

9600-8-N-1

이라고 가정할 수 있습니다.

하지만 실제 설정은 장비마다 다릅니다.

확인해야 할 항목은:

Baud Rate

Data Bits

Parity

Stop Bits

Flow Control

입니다.

DB9 핀 번호도 무조건 가정하면 안 된다#

PC 쪽 DB9에서는 일반적으로 다음 Pin을 자주 사용합니다.

2
RXD

3
TXD

5
GND

하지만 장비 쪽 Connector와 DTE·DCE 구성에 따라 Cable 결선이 달라질 수 있습니다.

따라서:

2번은 무조건 RX
3번은 무조건 TX

라고 장비 전체에 일반화하면 안 됩니다.

실제 장비 Pinout을 확인해야 합니다.

10장 ACK가 왔다고 티켓이 나왔다는 뜻은 아니다#

이 부분은 특히 중요합니다.

Controller가 발행 명령을 보냅니다.

ISSUE_TICKET

발행기가:

ACK

를 반환했습니다.

이것만 보고:

Ticket 발행 완료

라고 판단하면 안 됩니다.

ACK의 의미는 Protocol에 따라:

명령을 받았다

Packet이 정상이다

명령 실행을 수락했다

정도일 수 있습니다.

실제 흐름은 다음과 같을 수 있습니다.

Ticket Command
↓
ACK
↓
PRINTING
↓
CUTTING
↓
EJECTING
↓
COMPLETED

따라서 다음 상태를 구분하는 것이 좋습니다.

REQUESTED

ACCEPTED

PRINTING

COMPLETED

FAILED

11장 NAK와 Error Code도 구분해야 한다#

발행기가 명령을 처리하지 못하면 NAK나 별도의 Error Response를 보낼 수 있습니다.

예:

NAK

또는:

ERROR 03

같은 구조입니다.

Error Code는 제조사마다 다르지만 의미는 다음처럼 설계될 수 있습니다.

01
BUSY

02
PAPER_EMPTY

03
PAPER_JAM

04
CUTTER_ERROR

05
INVALID_COMMAND

중요한 점은:

NAK가 곧 통신 장애라는 뜻은 아니라는 것입니다.

Packet은 정상적으로 전달됐지만 장비가 Command 실행을 거부한 것일 수도 있습니다.

즉:

통신 실패

와:

업무 처리 실패

를 분리해야 합니다.

12장 가상의 Packet 구조로 흐름을 이해해보자#

제조사 전용 Protocol이 다음처럼 구성된다고 가정해보겠습니다.

STX

Command

Ticket Type

ETX

BCC

가상의 Packet:

02 54 01 03 XX

이를 다음처럼 해석할 수 있습니다.

02
STX

54
Ticket Command

01
Ticket Type

03
ETX

XX
BCC

이것은 구조 설명을 위한 가상의 예입니다.

실제 장비에 전송해서는 안 되며 제조사 Protocol을 확인해야 합니다.

BCC·Checksum·CRC는 장비마다 다르다#

어떤 장비는:

BCC

를 사용하고,

다른 장비는:

Checksum

또는:

CRC

를 사용할 수 있습니다.

심지어 검증 Byte가 없는 단순 ASCII Protocol도 존재할 수 있습니다.

따라서 Packet Dump를 봤다고 임의로 CRC 방식을 추측하면 안 됩니다.

13장 티켓에는 어떤 데이터를 넣을 수 있을까#

제품과 시스템에 따라 Ticket에는 다음 정보가 들어갈 수 있습니다.

입차 시간

주차장명

Lane

Ticket Number

Barcode

QR Code

안내 문구

일부 시스템에서는 차량번호를 함께 인쇄할 수도 있습니다.

예:

입차시간
2026-09-24 10:24:31

Ticket
A00012345

Lane
IN-02

이때 주의할 점은 Ticket Number입니다.

Ticket Number가 전체 시스템에서 중복되면 정산이나 출차 처리에 문제가 생길 수 있습니다.

따라서:

Ticket ID 생성

발행 Event 저장

Printer Command

출력 완료

의 순서를 명확하게 설계해야 합니다.

14장 Ticket ID는 출력 전에 만들 것인가, 이후에 만들 것인가#

이것은 시스템 설계에서 중요한 문제입니다.

예를 들어 먼저 Ticket ID를 생성합니다.

Ticket ID 생성
↓
DB 저장
↓
Print Command
↓
출력 실패

그러면 DB에는 Ticket이 있는데 실제 종이는 없는 상황이 생길 수 있습니다.

반대로:

Print
↓
완료
↓
DB 저장

방식은 출력 후 DB 저장 단계에서 장애가 발생하면 실제 Ticket은 있는데 서버 기록이 없는 문제가 생길 수 있습니다.

따라서 보통은 하나의 상태 흐름으로 관리하는 편이 안전합니다.

예:

CREATED
↓
PRINT_REQUESTED
↓
PRINTING
↓
PRINTED
↓
ISSUED

실패라면:

PRINT_FAILED

상태로 남길 수 있습니다.

15장 Timeout 후 재전송은 조심해야 한다#

Controller가 발행 명령을 보냈다고 하겠습니다.

Command
↓
Ticket Dispenser

발행기는 실제로 티켓을 출력했습니다.

그런데 Response Packet만 유실됐습니다.

Controller 입장에서는:

Timeout

입니다.

이때 같은 Command를 그대로 다시 보내면:

Ticket 1장 출력
+
Ticket 1장 추가 출력

이 발생할 수 있습니다.

따라서 Ticket Command는 특히 중복 처리에 주의해야 합니다.

가능하면:

Request ID

Ticket ID

Sequence Number

등을 사용해 동일 요청을 식별할 수 있도록 설계하는 것이 좋습니다.

예:

Request
REQ-00125

Ticket
TK-00125

장비 Protocol에서 이를 지원하지 않는다면 상위 Controller에서 상태 조회와 물리 Sensor를 함께 이용해 재시도 여부를 결정해야 합니다.

16장 장애는 네 영역으로 나누면 찾기 쉽다#

티켓이 나오지 않는다고 하겠습니다.

바로 Printer를 교체하기 전에 단계적으로 확인합니다.

Trigger 영역#

차량 검지

Ticket Button

Controller Input

발행 조건

Communication 영역#

RS-232 Cable

COM Port

Baud Rate

TX / RX

Packet

ACK / NAK

Printer 영역#

Printer Ready

Paper

Cutter

Motor

Print Head

Application 영역#

Command 생성

Ticket ID

Timeout

Retry

State 관리

DB 저장

전체 흐름:

Vehicle
↓
Trigger
↓
Controller
↓
Communication
↓
Ticket Dispenser
↓
Printer
↓
Ticket

어디까지 정상인지 확인하면 원인을 빠르게 좁힐 수 있습니다.

17장 현장에서 자주 만나는 장애 유형#

증상 확인할 항목
아무 반응 없음 전원·통신·Trigger·Port
ACK 없음 Cable·Baud·Packet·Protocol
ACK는 오지만 출력 안 됨 Printer Status·Paper·Motor
종이가 중간에 멈춤 Paper Jam·Roller·Cutter
빈 종이 출력 Print Head·용지 방향·감열지
두 장씩 출력 Retry·중복 Command
티켓은 나오지만 서버 기록 없음 DB·Event 처리·Network
PAPER EMPTY 반복 Sensor·용지 장착·Sensor 배선

빈 감열지가 나오는 경우#

감열지를 반대로 장착하면 Printer가 동작해도 글자가 나오지 않을 수 있습니다.

따라서:

Motor 정상
Paper Feed 정상
Ticket 배출 정상

이어도 Print 결과가 비어 있을 수 있습니다.

통신 문제와 Printer 문제를 구분해야 합니다.

18장 로그는 명령부터 실제 출력 완료까지 남긴다#

다음 Log만 있으면 부족합니다.

Ticket command sent

다음처럼 전체 상태를 남기는 것이 좋습니다.

10:20:10.100
VEHICLE_DETECTED

10:20:10.130
TICKET_CREATED
TK-00123

10:20:10.140
PRINT_REQUEST

10:20:10.160
PRINTER_ACK

10:20:10.350
PRINTING

10:20:10.800
TICKET_EJECTED

10:20:10.820
PRINT_COMPLETED

장애라면:

10:21:40.100
PRINT_REQUEST

10:21:40.120
PRINTER_NAK

ERROR
PAPER_EMPTY

처럼 남깁니다.

권장 Log Field:

Timestamp

Device ID

Lane ID

Ticket ID

Request ID

Command

Raw TX

Raw RX

Printer Status

Paper Status

Error Code

Retry Count

이 구조가 있으면 장애 발생 시 명령·통신·Printer 상태를 연결해서 볼 수 있습니다.

19장 보안과 개인정보도 확인해야 한다#

주차권 발행기는 단순 Printer처럼 보이지만 상위 주차관제 시스템과 연결되어 있습니다.

Network Gateway 등을 통해 원격 제어가 가능하다면:

Authentication

Authorization

Network Segmentation

Access Log

Remote Management 제한

등을 고려해야 합니다.

티켓에는 필요 이상의 개인정보를 출력하지 않는 것이 좋습니다.

또한 Log에는 다음 정보가 포함될 수 있습니다.

차량번호

입차 시간

Ticket ID

할인 정보

따라서 운영 목적에 필요한 범위만 수집하고 적절한 접근 권한과 보존 정책을 적용해야 합니다.

20장 현장 점검 순서를 정해두자#

티켓 발행 장애가 발생하면 다음 순서로 점검할 수 있습니다.

1단계 전원#

Device Power

Fuse

Power Supply

Status LED

2단계 용지#

Paper 존재

Paper 방향

Paper 규격

Paper Jam

3단계 Printer#

Motor

Roller

Cutter

Print Head

Sensor

4단계 통신#

COM Port

TX / RX

GND

Baud

Parity

Stop Bits

5단계 Protocol#

Command

Length

Checksum

ACK / NAK

Status Code

6단계 Application#

Ticket ID

Retry

Timeout

DB

Event 처리

이 순서로 보면:

발행기가 고장났다.

라는 모호한 판단을 훨씬 구체적으로 만들 수 있습니다.

21장 자기 점검#

Ticket Command를 보냈다는 것은 무엇을 의미하는가#

상위 Controller가 발행기에게 티켓 출력을 요청했다는 의미이며 실제 출력 완료를 의미하지 않습니다.

ACK를 받으면 실제 Ticket이 출력된 것인가#

반드시 그렇지는 않습니다. ACK는 명령 수신이나 처리 수락을 의미할 수 있으므로 출력 완료 상태를 별도로 확인해야 합니다.

Paper Jam과 Paper Empty는 어떻게 다른가#

Paper Empty는 용지가 없는 상태이고 Paper Jam은 용지가 존재하지만 정상적으로 이동하지 못하는 상태입니다.

Timeout 후 무조건 다시 발행 명령을 보내도 되는가#

권장되지 않습니다. 첫 번째 명령으로 이미 Ticket이 출력되었지만 Response만 유실됐을 가능성이 있어 중복 발행이 발생할 수 있습니다.

RS-232 통신이 정상인데 티켓이 안 나오면 무엇을 확인해야 하는가#

Printer Status, Paper Sensor, Motor, Cutter, Print Head 등 발행기 내부 상태를 확인해야 합니다.

22장 이 글을 마치며#

주차권 발행기의 전체 흐름을 정리하면 다음과 같습니다.

Vehicle
↓
Vehicle Detection
↓
Parking Controller
↓
Ticket ID 생성
↓
Ticket Command
↓
RS-232 / Digital Input
↓
Ticket Dispenser
↓
Printer Status 확인
↓
Paper Sensor 확인
↓
Print
↓
Cut
↓
Eject
↓
Output Sensor
↓
Completed
↓
Parking Controller

특히 다음 내용을 기억하면 됩니다.

주차권 발행기는 단순 Printer가 아니라 통신 인터페이스·Controller·Paper Sensor·Motor·Print Head·Cutter 등이 결합된 장비입니다.

Ticket Command 수신과 실제 Ticket 출력 완료는 서로 다른 상태이므로 ACK·PRINTING·COMPLETED 같은 상태를 구분해서 관리해야 합니다.

Paper Empty·Paper Jam·Cutter Error·Communication Error는 모두 티켓 미출력으로 보일 수 있지만 원인이 전혀 다르므로 상태 코드를 세분화해야 합니다.

Timeout 후 발행 명령을 무조건 다시 보내면 동일 Ticket이 두 번 출력될 수 있으므로 Ticket ID·Request ID·현재 Printer 상태를 이용한 중복 제어가 중요합니다.

현장 장애는 전원 → 용지 → Printer 기구부 → Serial 통신 → Protocol → Application 순으로 경계를 나누어 확인하면 빠르게 원인을 좁힐 수 있습니다.

결국 주차권 발행기를 이해한다는 것은 단순히 PRINT 명령을 보내는 방법을 아는 것이 아닙니다.

차량 검지에서 시작된 하나의 발행 요청이 통신 명령으로 전달되고, 내부 Sensor와 기계장치의 상태 판단을 거쳐 실제 종이 티켓으로 만들어진 뒤 다시 완료 Event로 돌아오는 전체 흐름을 이해하는 것이 핵심입니다.

이 페이지의 목차