[주차 차단기]는 어떻게 동작할까? Open·Close·Stop 명령과 안전센서 제어 원리

주차 차단기는 어떻게 동작할까? Open·Close·Stop 명령과 안전센서 제어 원리#

1장 서버에서 OPEN을 보내면 바로 차단기가 열릴까#

주차관제 서버에서 다음 명령을 전송했다고 생각해보겠습니다.

OPEN

화면만 보면 단순합니다.

하지만 실제 차단기 내부에서는 여러 판단을 거칩니다.

Parking Server
      │
      │ OPEN
      ▼
현장 Controller
      │
      ├─ 현재 상태 확인
      ├─ 안전 Sensor 확인
      ├─ Motor 상태 확인
      └─ 명령 허용 여부 판단
              │
              ▼
         Motor Driver
              │
              ▼
          Barrier Arm

즉:

OPEN 명령 수신
=
즉시 Motor 회전

은 아닙니다.

컨트롤러는 현재 차단기가 이미 열려 있는지, 차량이나 사람이 위험 영역에 있는지, Motor에 Fault가 발생하지 않았는지 등을 확인한 뒤 실제 동작을 결정할 수 있습니다.

이 차이를 이해해야:

서버에서는 OPEN 성공인데
왜 차단기는 안 움직였지?

같은 현장 장애를 제대로 분석할 수 있습니다.

2장 차단기 시스템은 세 영역으로 나누어 보면 쉽다#

차단기 시스템은 크게 세 부분으로 나눌 수 있습니다.

서버·상위 시스템#

다음과 같은 판단을 합니다.

차량 번호 인식

입차 허용 여부

정산 완료 여부

관리자 수동 제어

OPEN / CLOSE 요청

즉 업무 판단을 담당합니다.

현장 컨트롤러#

서버 명령을 받아 실제 장비 상태와 결합합니다.

OPEN 요청 수신

현재 위치 확인

안전 Sensor 확인

Motor Fault 확인

동작 결정

결과 보고

실제 안전 제어는 서버보다 현장 Controller가 담당하는 경우가 많습니다.

차단기 구동부#

실제 물리 동작을 수행합니다.

Motor

Motor Driver

Gearbox

Spring

Barrier Arm

Limit Switch

Encoder

전체를 단순화하면:

Server
→ 무엇을 할 것인가

Controller
→ 지금 해도 되는가

Motor·Barrier
→ 실제로 움직인다

라고 볼 수 있습니다.

3장 OPEN·CLOSE·STOP은 요청이지 물리 상태 자체가 아니다#

프로그램에서 흔히 사용하는 명령은 다음과 같습니다.

OPEN

CLOSE

STOP

하지만 이 값은 보통 동작 요청 Command입니다.

실제 상태는 별도로 존재할 수 있습니다.

예:

OPENING

OPENED

CLOSING

CLOSED

STOPPED

BLOCKED

ERROR

예를 들어:

Command
OPEN

을 보냈는데 현재 상태가:

OPENED

라면 Controller는 Motor를 다시 구동하지 않을 수 있습니다.

반대로:

OPEN

을 보냈는데:

SAFETY_FAULT

상태라면 명령을 거부할 수도 있습니다.

따라서 프로그램에서는:

Command와 State를 반드시 분리해서 관리하는 것이 좋습니다.

4장 OPEN 명령은 어떤 순서로 처리될까#

일반적인 흐름을 보겠습니다.

Server
↓
OPEN Command
↓
Controller
↓
Command 형식 확인
↓
현재 Barrier 상태 확인
↓
Safety 조건 확인
↓
Motor 구동 허용
↓
OPENING
↓
Open Limit 확인
↓
Motor 정지
↓
OPENED
↓
Server 상태 보고

여기에서 중요한 점은 서버가 OPEN을 전송했다고 해서 업무가 완료된 것이 아니라는 것입니다.

다음 상태는 전부 다릅니다.

OPEN Command 전송

Controller 수신

Controller ACK

Motor 동작 시작

Barrier OPENING

Open Limit 도달

OPENED 완료

따라서 로그도 각각 구분해두는 편이 좋습니다.

5장 CLOSE 명령은 OPEN보다 안전조건이 더 중요할 수 있다#

차단기를 닫는 것은 차량이나 사람과 충돌할 수 있기 때문에 안전 Sensor가 중요합니다.

예:

CLOSE Command
↓
차량 검지 여부 확인
↓
광전 Sensor 확인
↓
안전 Loop 확인
↓
동작 가능?

차량이 아직 Barrier 아래에 있다면:

CLOSE
↓
Safety Sensor ACTIVE
↓
Close 금지

같은 정책이 사용될 수 있습니다.

또는 닫히는 도중 Sensor가 감지되면:

CLOSING
↓
Safety Sensor ACTIVE
↓
STOP

하거나 제품 설정에 따라:

CLOSING
↓
Safety Sensor ACTIVE
↓
REVERSE
↓
OPENING

으로 동작할 수도 있습니다.

정확한 동작은 Controller와 제조사 설정에 따라 달라집니다.

6장 STOP은 단순히 Motor 전원을 끄는 것과 다를 수 있다#

STOP을 받았을 때:

Motor OFF

만 하면 된다고 생각하기 쉽습니다.

하지만 실제 Barrier Controller에서는:

감속

Brake

Motor Drive 차단

현재 위치 저장

STOPPED 상태 전환

등이 포함될 수 있습니다.

특히 고속 Barrier나 무거운 Arm에서는 갑작스러운 정지가 기구부에 부담을 줄 수 있기 때문에 Controller가 자체적인 감속 로직을 사용할 수도 있습니다.

따라서 프로그램에서는:

STOP Command 전송

과:

실제 Barrier 정지 확인

을 별개로 처리해야 합니다.

7장 Limit Sensor는 차단기의 끝 위치를 알려준다#

Barrier가 완전히 열렸는지 어떻게 알 수 있을까요?

대표적인 방법이 Limit Sensor입니다.

두 개의 Limit를 사용하는 구조라면:

Open Limit
→ 완전 개방

Close Limit
→ 완전 폐쇄

를 나타낼 수 있습니다.

예:

Barrier OPENING
↓
Open Limit OFF
↓
계속 이동
↓
Open Limit ON
↓
Motor Stop
↓
OPENED

닫을 때는 반대로 동작합니다.

CLOSING
↓
Close Limit 감지
↓
Motor Stop
↓
CLOSED

Limit Sensor 위치가 틀어지거나 Switch가 고장 나면 Barrier는 실제 위치와 내부 상태가 어긋날 수 있습니다.

예:

실제 Arm
완전 개방

Controller
OPENING

상태가 계속될 수도 있습니다.

이런 경우 Motor·Protocol보다 Sensor부터 확인해야 합니다.

8장 Encoder는 중간 위치까지 알 수 있게 한다#

일부 Barrier는 단순 Limit Switch뿐 아니라 Encoder를 이용합니다.

Limit Switch가:

완전 열림

완전 닫힘

을 확인하는 데 적합하다면 Encoder는:

현재 각도

이동 방향

이동 속도

중간 위치

같은 정보를 제공할 수 있습니다.

예:

0°
CLOSED

45°
OPENING

90°
OPENED

처럼 내부 위치를 관리할 수 있습니다.

이를 활용하면:

Soft Start

Soft Stop

속도 제어

장애물 감지

Position Error 검출

같은 제어도 가능해집니다.

정확한 위치 계산 방식은 Controller와 Motor 구조에 따라 다릅니다.

9장 안전센서는 차단기 명령보다 우선할 수 있다#

주차 차단기 주변에는 다양한 Sensor가 사용될 수 있습니다.

대표적으로:

Loop Detector

Photoelectric Sensor

Radar Sensor

Safety Edge

Barrier Position Sensor

등이 있습니다.

차량이 Barrier 아래에 있는데 Server가:

CLOSE

를 보냈다고 가정해보겠습니다.

Controller는 다음처럼 판단할 수 있습니다.

CLOSE 요청
↓
Safety Loop
OCCUPIED
↓
CLOSE 거부

또는:

CLOSING
↓
Photo Sensor 감지
↓
STOP
↓
OPEN

처럼 동작할 수도 있습니다.

이 때문에 서버는 모든 물리 상황을 직접 제어하려고 하기보다 Controller가 독립적으로 안전 판단을 수행할 수 있도록 설계하는 것이 중요합니다.

10장 차량검지기와 차단기는 어떻게 연결될까#

전형적인 입차 흐름을 보겠습니다.

차량 진입
↓
Loop Detector
↓
VEHICLE_DETECTED
↓
LPR Camera 촬영
↓
번호판 인식
↓
입차 허용
↓
OPEN Command
↓
Barrier OPENING
↓
OPENED
↓
차량 통과
↓
후방 Loop 상태 변화
↓
CLOSE 허용
↓
Barrier CLOSED

이 구조에서:

차량 검지

번호판 인식

입차 승인

차단기 Open

차량 통과

차단기 Close

는 각각 별도의 사건입니다.

하나의 Boolean 값으로 전체를 표현하면 장애 분석이 어려워집니다.

11장 Emergency는 일반 명령과 별도로 생각해야 한다#

Emergency 상황에서는 일반적인:

OPEN

CLOSE

STOP

규칙보다 높은 수준의 정책이 적용될 수 있습니다.

예를 들어 화재 상황에서:

Emergency
↓
Barrier Open 유지

하도록 설계된 현장이 있을 수 있습니다.

반대로 특정 보안 시설에서는 별도의 비상 통제 정책이 적용될 수도 있습니다.

따라서:

Emergency = 무조건 OPEN

또는:

Emergency = 무조건 CLOSE

라고 일반화하면 안 됩니다.

비상 동작은:

시설 종류

피난 계획

소방·안전 설계

운영 정책

제조사 Controller 기능

등을 기준으로 프로젝트 단계에서 정의해야 합니다.

프로그램에서는 Emergency를 일반 priority 숫자 하나로 처리하기보다 별도의 운영 상태로 관리하는 것이 좋습니다.

12장 Fail-safe와 Fail-secure를 구분한다#

장비 제어에서는 장애가 발생했을 때 어떤 상태로 갈 것인지가 중요합니다.

예:

Server 연결 끊김

Controller 장애

Sensor 장애

전원 장애

가 발생할 수 있습니다.

Fail-safe#

장애 시 사람과 설비의 안전을 우선하는 상태로 이동하도록 설계하는 개념입니다.

Fail-secure#

장애 시 보안이나 접근 통제를 유지하도록 설계하는 개념입니다.

주차장에서는 한 가지 방식이 모든 현장에 정답인 것은 아닙니다.

예를 들어:

입구

출구

보안구역

피난구역

마다 요구사항이 다를 수 있습니다.

따라서 장애 상태에서:

OPEN 유지

CLOSE 유지

수동 해제

Local Mode 전환

중 무엇을 선택할지는 현장 안전 설계에 따라 결정해야 합니다.

13장 차단기 명령 Packet은 어떻게 구성될까#

차단기를 Serial Protocol로 제어한다고 가정해보겠습니다.

제조사 전용 Protocol은 예를 들어 다음처럼 설계될 수 있습니다.

[Address]
[Command]
[Data]
[Checksum]

가상의 Command Code:

0x01
OPEN

0x02
CLOSE

0x03
STOP

라고 할 수 있습니다.

예:

01 01 00 XX

를:

Address
01

Command
OPEN

Data
00

Checksum
XX

처럼 정의할 수도 있습니다.

하지만 이것은 어디까지나 구조 설명을 위한 예시입니다.

OPEN·CLOSE·STOP Code는 제조사 Protocol마다 완전히 다를 수 있습니다.

14장 Modbus를 사용하는 장비라면 Register가 Command가 될 수도 있다#

일부 Controller에서는 Modbus RTU나 Modbus TCP를 사용할 수도 있습니다.

예를 들어 제조사가:

Register 0x0010
Barrier Command

라고 정의했다고 가정해보겠습니다.

값:

0
STOP

1
OPEN

2
CLOSE

라고 정의할 수도 있습니다.

그러면 개념적으로:

Write Register
↓
Command Register
↓
Controller
↓
Barrier Action

이 됩니다.

하지만 0x0010, 0, 1, 2는 Modbus 표준이 정의하는 값이 아닙니다.

장비 제조사가 정의한 Register Map입니다.

따라서 실제 시스템에서는 반드시 장비의 Modbus Register Map을 확인해야 합니다.

15장 ACK와 실제 동작 완료를 구분해야 한다#

차단기 제어에서 매우 중요한 부분입니다.

서버가:

OPEN

을 전송하고 Controller에서:

ACK

를 받았습니다.

이것이:

Barrier OPENED

를 의미하는 것은 아닐 수 있습니다.

ACK는 보통:

명령을 받았다.

또는:

명령을 처리 대상으로 받아들였다.

정도의 의미일 수 있습니다.

실제 흐름은:

OPEN Command
↓
ACK
↓
OPENING
↓
Open Limit
↓
OPENED

가 될 수 있습니다.

따라서 Server에서는 상태를 구분해서 관리하는 것이 좋습니다.

REQUESTED

ACCEPTED

EXECUTING

COMPLETED

FAILED

이런 구조는 원격 Monitoring과 장애 분석에 매우 도움이 됩니다.

16장 Timeout 후 무조건 OPEN을 다시 보내면 위험하다#

다음 상황을 생각해보겠습니다.

Server
↓
OPEN
↓
Controller
↓
실제로 OPEN 실행

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

Server에서는:

Timeout

으로 보입니다.

이때 바로:

OPEN 재전송

할 수 있습니다.

OPEN처럼 동일 상태 요청은 비교적 영향이 적을 수 있지만 모든 Command가 그런 것은 아닙니다.

예를 들어:

OPEN FOR 5 SECONDS

TOGGLE

ONE CYCLE

COUNT +1

같은 Command라면 중복 실행이 문제가 될 수 있습니다.

따라서 Remote Control에서는 다음을 고려할 수 있습니다.

Command ID

Sequence Number

현재 상태 조회

중복 Request 제거

Idempotent Command 설계

예:

Command ID
CMD-20260924-000123

Target
GATE-12

Command
OPEN

Controller 또는 중간 Server가 이미 처리한 Command ID를 기억하면 중복 실행을 줄일 수 있습니다.

17장 API로 차단기를 제어할 때도 같은 원칙이 적용된다#

상위 시스템이 REST API를 제공한다고 가정해보겠습니다.

예:

POST /api/gates/12/commands
Content-Type: application/json
Authorization: Bearer <token>

{
  "command": "OPEN",
  "commandId": "cmd-20260924-00123"
}

Server Response:

{
  "commandId": "cmd-20260924-00123",
  "status": "ACCEPTED"
}

여기서:

HTTP 200 / 202

가 곧:

Barrier OPENED

라는 뜻은 아닙니다.

다시 상태를 확인하거나 Event를 받아야 할 수 있습니다.

예:

{
  "gateId": "12",
  "state": "OPENED",
  "lastCommandId": "cmd-20260924-00123"
}

즉:

HTTP 성공
≠
Controller 명령 실행 완료
≠
실제 Barrier 동작 완료

입니다.

18장 차단기 상태는 State Machine으로 관리하면 이해하기 쉽다#

차단기는 전형적인 State Machine으로 표현할 수 있습니다.

CLOSED
   │
   │ OPEN
   ▼
OPENING
   │
   │ Open Limit
   ▼
OPENED
   │
   │ CLOSE
   ▼
CLOSING
   │
   │ Close Limit
   ▼
CLOSED

중간에 다음 상태도 있을 수 있습니다.

STOPPED

BLOCKED

ERROR

MANUAL

EMERGENCY

예를 들어:

CLOSING
↓
Safety Sensor ACTIVE
↓
BLOCKED
↓
OPENING

처럼 상태가 전환될 수 있습니다.

이 방식으로 구현하면 단순한 Boolean:

isOpen = true / false

보다 실제 현장 상태를 훨씬 정확하게 표현할 수 있습니다.

19장 원격 Monitoring에는 Command와 State를 모두 남긴다#

장애를 분석하려면 단순히 현재 상태만 보면 부족합니다.

다음 정보를 함께 기록하는 것이 좋습니다.

Timestamp

Gate ID

Command ID

Requested Command

Controller ACK

Previous State

Current State

Safety Sensor State

Open Limit

Close Limit

Motor Fault

Error Code

예:

10:10:00.100
OPEN REQUEST
GATE-01

10:10:00.130
COMMAND ACCEPTED

10:10:00.160
STATE OPENING

10:10:01.420
OPEN LIMIT ON

10:10:01.430
STATE OPENED

장애라면:

10:20:00.100
CLOSE REQUEST

10:20:00.130
COMMAND ACCEPTED

10:20:00.150
SAFETY LOOP ACTIVE

10:20:00.151
CLOSE BLOCKED

처럼 원인을 바로 확인할 수 있습니다.

20장 차단기가 안 움직일 때는 순서대로 확인한다#

Server에서 OPEN을 보냈는데 동작하지 않는다고 하겠습니다.

상위 시스템#

OPEN 요청 생성 여부

Target Gate ID

권한

API 결과

Communication#

Packet 전송

RS-232 / RS-485

TCP 연결

Timeout

ACK

Controller#

Command 수신

현재 상태

Interlock

Safety Input

Fault

구동부#

Motor Driver

Motor

Power

Mechanical Jam

Position Sensor#

Open Limit

Close Limit

Encoder

전체 구조:

Server
↓
Communication
↓
Controller
↓
Safety Logic
↓
Motor
↓
Mechanical System
↓
Limit / Encoder

어디까지 정상인지 확인하면 장애 범위를 빠르게 좁힐 수 있습니다.

21장 흔히 하는 잘못된 판단#

OPEN을 보냈으니 차단기는 열렸다#

아닙니다.

Command 전송과 실제 완료 상태는 다릅니다.

ACK가 왔으니 Barrier가 움직였다#

ACK는 명령 수신이나 처리 수락만 의미할 수 있습니다.

Server가 모든 안전 판단을 해야 한다#

네트워크 장애 가능성을 고려하면 현장 Controller가 독립적으로 처리해야 하는 Safety Logic이 있을 수 있습니다.

Safety Sensor가 감지되면 반드시 STOP한다#

장비 설정에 따라 Stop, Reverse, Close 차단 등 동작이 달라질 수 있습니다.

Emergency면 무조건 Open이다#

현장 안전·보안 정책에 따라 다르며 프로젝트 단계에서 명확히 정의해야 합니다.

Limit Sensor가 하나라도 정상이면 위치를 정확하게 안다#

Sensor 고장·오정렬·배선 문제 가능성이 있으므로 Encoder나 다른 상태와 교차 확인할 수 있습니다.

22장 차단기 제어 설계 체크리스트#

□ OPEN·CLOSE·STOP Command가 정의되어 있는가?

□ Command와 State를 분리했는가?

□ OPENING·CLOSING 상태가 존재하는가?

□ Open Limit를 확인하는가?

□ Close Limit를 확인하는가?

□ Safety Sensor 상태를 확인하는가?

□ Barrier 아래 차량 검지 정책이 있는가?

□ 명령 ACK와 동작 완료를 구분하는가?

□ Command Timeout이 정의되어 있는가?

□ Retry 정책이 있는가?

□ 중복 Command 처리 정책이 있는가?

□ Command ID 또는 Sequence가 필요한가?

□ Motor Fault를 수집하는가?

□ Sensor Fault를 수집하는가?

□ Manual Mode를 처리하는가?

□ Emergency Mode를 정의했는가?

□ 통신 단절 시 동작 정책이 있는가?

□ 원격 제어 권한이 제한되어 있는가?

□ Command와 상태 이력을 남기는가?

23장 자기 점검#

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

상위 시스템에서 개방 요청을 전달했다는 의미이며 실제 차단기가 완전히 열렸다는 뜻은 아닙니다.

Limit Sensor의 역할은 무엇인가#

Barrier Arm이 Open 또는 Close 끝 위치에 도달했는지를 Controller가 판단할 수 있도록 위치 정보를 제공합니다.

차단기가 닫히는 중 차량이 감지되면 어떻게 해야 하는가#

정확한 동작은 Controller와 현장 Safety Policy에 따라 달라지며 Stop·Reverse·Close 차단 등의 정책이 사용될 수 있습니다.

ACK를 받으면 동작 완료인가#

아닙니다. ACK와 OPENED·CLOSED 같은 최종 상태 보고를 분리해야 합니다.

통신이 끊겼을 때 무조건 Barrier를 열어야 하는가#

아닙니다. Fail-safe·Fail-secure 정책은 시설 용도와 안전·보안 요구사항에 따라 설계해야 합니다.

24장 이 글을 마치며#

차단기 제어의 전체 흐름은 다음과 같습니다.

Parking Server
↓
OPEN / CLOSE / STOP
↓
Communication
↓
Local Controller
↓
State Machine
↓
Safety Sensor
↓
Motor Control
↓
Barrier Movement
↓
Limit / Encoder
↓
OPENED / CLOSED / ERROR
↓
Parking Server

특히 다음 내용을 기억해야 합니다.

Open·Close·Stop은 실제 위치가 아니라 차단기 Controller에 전달하는 동작 요청이며 OPENED·CLOSED·OPENING·CLOSING 같은 상태와 분리해서 관리해야 합니다.

Controller는 Server Command를 그대로 Motor에 전달하는 장치가 아니라 Limit Sensor·차량검지기·광전센서·Motor Fault 등 현장 조건을 확인해 실제 동작 여부를 판단할 수 있습니다.

ACK는 명령을 받았다는 의미일 수 있으며 실제 차단기 동작 완료는 Open Limit·Close Limit·Encoder 등의 Feedback을 통해 별도로 확인해야 합니다.

Timeout 후 무조건 Command를 다시 보내면 중복 동작이 발생할 수 있으므로 Command ID·현재 상태 조회·멱등성 같은 중복 처리 전략이 필요할 수 있습니다.

Emergency와 통신 장애 시 동작은 단순한 프로그램 기본값이 아니라 시설의 안전·보안 요구에 따라 미리 정의하고 현장 Controller에서도 독립적으로 처리할 수 있도록 설계해야 합니다.

결국 차단기를 이해한다는 것은 OPEN을 보내면 열린다는 단순한 흐름을 아는 것이 아닙니다.

서버의 요청이 현장 Controller의 상태 판단과 Safety Logic을 통과하고, Motor의 실제 움직임과 Sensor Feedback을 거쳐 최종 상태로 확정되는 전체 제어 흐름을 이해하는 것이 핵심입니다.

이 페이지의 목차