[주차유도 시스템]은 어떻게 동작할까? 주차면 센서·Controller·전광판 데이터 흐름 이해하기

주차유도 시스템은 어떻게 동작할까? 주차면 센서·Controller·전광판 데이터 흐름 이해하기#

1장 전광판의 빈자리 숫자는 어디에서 만들어질까#

주차장 입구 전광판에는 다음과 같은 정보가 표시됩니다.

B1  32대
B2  18대
B3   7대

운전자에게는 단순한 숫자지만 이 값이 만들어지기까지 여러 장비가 연결됩니다.

차량
↓
주차면 Sensor
↓
점유 상태 판단
↓
층별 Controller
↓
주차면 상태 집계
↓
빈자리 계산
↓
전광판
↓
중앙 Server

예를 들어 B2층에 200개의 주차면이 있고 182면이 점유되어 있다면:

전체
200

점유
182

빈자리
18

이라고 계산할 수 있습니다.

하지만 실제 시스템에서는 단순한 뺄셈보다 더 많은 상태를 고려해야 합니다.

정상 빈자리

점유

장애 Sensor

사용 중지 주차면

예약 주차면

관리자 차단 주차면

등을 어떻게 계산할 것인지 정책이 필요하기 때문입니다.

따라서 전광판에 표시된 숫자는 단순한 Sensor 개수의 합이 아니라 여러 장비 상태를 해석한 결과값입니다.

2장 주차면 Sensor는 차량 유무를 상태로 바꾼다#

주차면 Sensor의 가장 기본적인 역할은 다음 질문에 답하는 것입니다.

이 주차면에 차량이 있는가?

결과는 흔히:

VACANT

또는:

OCCUPIED

처럼 표현할 수 있습니다.

주차면 검지에는 다양한 방식이 사용될 수 있습니다.

방식	판단 원리	주로 고려할 요소
초음파	차량과 Sensor 사이 거리	설치 높이·각도·오염
지자기	차량에 의한 자기장 변화	Calibration·주변 금속
영상	Camera 영상 분석	조명·가림·영상 품질
복합 Sensor	여러 검지 방식 결합	비용·정확도·설치 환경

중요한 것은 Sensor가:

차량

이라는 개념을 직접 이해하는 것이 아니라는 점입니다.

실제로는:

거리 변화

자기장 변화

영상 특징 변화

같은 물리적 변화를 측정한 뒤 내부 알고리즘으로 차량 존재 여부를 판단합니다.

3장 Sensor 상태와 Event는 다르게 관리할 수 있다#

주차면 Sensor가 다음 상태를 가지고 있다고 하겠습니다.

VACANT

차량이 들어오면:

VACANT
↓
OCCUPIED

로 변경됩니다.

여기서 OCCUPIED는 현재 상태입니다.

상태가 바뀐 순간에는:

VEHICLE_OCCUPIED

같은 Event를 생성할 수 있습니다.

차량이 나가면:

OCCUPIED
↓
VACANT

상태가 바뀌고:

VEHICLE_LEFT

같은 Event가 발생할 수 있습니다.

따라서:

State
→ 현재 어떤 상태인가

Event
→ 무엇이 발생했는가

로 구분하면 이해하기 쉽습니다.

서버에서는 두 정보를 함께 관리하면 장애 분석에 유리합니다.

예:

sensorId
L2-045

previousState
VACANT

currentState
OCCUPIED

changedAt
2026-09-24 11:32:10

4장 층별 Controller는 여러 Sensor를 관리한다#

수백 개 Sensor를 모두 중앙 Server에 직접 연결하면 관리가 복잡해질 수 있습니다.

그래서 중간에 Controller나 Gateway를 둘 수 있습니다.

Sensor 001 ─┐
Sensor 002 ─┤
Sensor 003 ─┤
Sensor 004 ─┤
            ▼
       Floor Controller
            │
            ▼
       Central Server

Controller는 단순한 통신 중계기 이상의 역할을 할 수 있습니다.

대표적으로:

Sensor Polling

Event 수신

Sensor ID 관리

상태 Cache

Timestamp 추가

오류 감지

층별 빈자리 계산

Server 전송

전광판 제어

등을 수행할 수 있습니다.

즉:

Sensor
→ 개별 주차면 상태

Controller
→ 여러 Sensor의 상태 관리

로 역할을 나눌 수 있습니다.

5장 Controller는 Polling 또는 Event 방식으로 Sensor 상태를 받는다#

Sensor 상태를 가져오는 방식은 크게 두 가지로 볼 수 있습니다.

Polling 방식#

Controller가 Sensor에게 계속 질문합니다.

Sensor 001 상태?
→ VACANT

Sensor 002 상태?
→ OCCUPIED

Sensor 003 상태?
→ VACANT

그리고 다시 반복합니다.

장점은 현재 상태를 지속적으로 확인할 수 있다는 점입니다.

하지만 Sensor가 많아지면 Polling 주기가 길어질 수 있습니다.

예를 들어:

Sensor
500개

Sensor당 통신
10ms

만 단순 계산해도 전체 조회 시간이 누적됩니다.

실제 환경에서는 Timeout과 Retry도 추가될 수 있습니다.

Event 방식#

Sensor 상태가 바뀌었을 때만 Controller에 알려주는 방식입니다.

Sensor 045
VACANT
↓
차량 진입
↓
OCCUPIED Event
↓
Controller

불필요한 통신을 줄일 수 있지만 Event가 유실됐을 때 Controller 상태와 실제 Sensor 상태가 달라질 수 있습니다.

그래서 시스템에 따라:

Event 전달
+
주기적 상태 동기화

방식을 함께 사용할 수도 있습니다.

6장 Sensor와 Controller 사이에는 다양한 통신 방식이 사용된다#

주차유도 시스템의 하위 통신은 제조사마다 다릅니다.

대표적으로:

RS-485

CAN

Ethernet

BLE

Sub-GHz Wireless

기타 제조사 전용 Wireless

등을 사용할 수 있습니다.

RS-485 방식#

유선 Sensor 시스템에서는 여러 Sensor를 하나의 Bus에 연결할 수 있습니다.

Controller
    │
────┼──────── RS-485
    │
    ├─ Sensor 01
    ├─ Sensor 02
    ├─ Sensor 03
    └─ Sensor 04

이 경우 확인해야 할 항목은:

Address

Baud Rate

A/B 배선

Termination

Bias

Cable

Ground

등입니다.

RS-485는 전기 규격이므로 Sensor Address와 Packet Format은 제조사의 상위 Protocol이 결정합니다.

무선 방식#

무선 Sensor라면 배선은 줄어들지만 다른 문제가 생깁니다.

Battery

RSSI

Packet Loss

중계기

간섭

재전송

통신 범위

특히 지하 주차장의 콘크리트·벽·배관·차량 자체가 Radio 환경에 영향을 줄 수 있으므로 실제 현장에서 시험해야 합니다.

7장 Controller가 빈자리 수를 계산한다#

예를 들어 B2층에 다음 상태가 있다고 하겠습니다.

전체 주차면
200

OCCUPIED
175

VACANT
20

ERROR
3

DISABLED
2

단순히:

200 - 175 = 25

라고 표시해도 될까요?

반드시 그렇지는 않습니다.

ERROR Sensor를 빈자리로 표시하면 실제 차량이 있는데도 빈자리로 안내할 수 있습니다.

따라서 정책을:

안내 가능한 빈자리
=
VACANT 상태 중 사용 가능한 주차면

처럼 정의할 수 있습니다.

예:

VACANT
20

ERROR
3

DISABLED
2

실제 안내 숫자
20

이런 정책은 Controller에서 계산할 수도 있고 중앙 Server에서 계산할 수도 있습니다.

중요한 것은 어느 시스템이 최종 빈자리 숫자의 기준인지 명확하게 정하는 것입니다.

8장 전광판은 숫자를 계산하는 장비가 아닐 수 있다#

전광판은 일반적으로 표시가 주 역할입니다.

예:

B1  23

B2  만차

B3  17

Controller나 Server가:

B2
FREE=0

이라고 판단하면 전광판은:

만차

를 표시할 수 있습니다.

전체 구조는:

Sensor
↓
Controller
↓
빈자리 계산
↓
Display Command
↓
전광판

처럼 볼 수 있습니다.

전광판도 여러 통신 방법을 사용할 수 있습니다.

RS-232

RS-485

Ethernet

TCP Socket

HTTP

제조사 전용 Protocol

따라서 전광판의 숫자가 잘못됐다고 해서 전광판 자체가 원인이라고 단정하면 안 됩니다.

전광판은 잘못된 데이터를 정상적으로 표시하고 있을 수도 있습니다.

9장 중앙 Server는 전체 주차장을 하나의 상태로 만든다#

층별 Controller에서 다음과 같은 정보가 올라온다고 하겠습니다.

B1
FREE 23

B2
FREE 18

B3
FREE 7

중앙 Server에서는:

전체 빈자리
48

를 계산할 수 있습니다.

또한 더 세부적인 상태도 관리할 수 있습니다.

주차면 ID

층

구역

Sensor 상태

마지막 Event 시간

통신 상태

Battery

Signal Quality

예:

{
  "sensorId": "B2-A-045",
  "level": "B2",
  "zone": "A",
  "occupied": true,
  "changedAt": "2026-09-24T11:20:32+09:00",
  "deviceStatus": "ONLINE"
}

이런 정보가 있어야 운영 화면에서 개별 Sensor까지 추적할 수 있습니다.

10장 MQTT를 사용하면 Event 기반 데이터를 전달하기 쉽다#

Controller와 중앙 Server 사이에서는 MQTT를 사용할 수도 있습니다.

예를 들어 Topic을 다음처럼 설계할 수 있습니다.

parking/site01/B2/sensors/B2-A-045/state

Payload:

{
  "eventId": "evt-00125",
  "occupied": true,
  "timestamp": "2026-09-24T02:20:32Z"
}

층 요약 Topic은:

parking/site01/B2/summary

처럼 만들 수 있습니다.

Payload:

{
  "total": 200,
  "occupied": 182,
  "free": 18
}

MQTT를 사용할 때는 단순히 연결만 하는 것이 아니라 다음도 설계해야 합니다.

Topic Naming

QoS

Retained Message

Client ID

Authentication

Reconnect

중복 Message 처리

특히 Retained Message를 사용한다면 새 Subscriber가 마지막 상태를 즉시 받을 수 있지만 오래된 상태가 그대로 표시되지 않도록 Timestamp와 상태 유효성도 함께 고려해야 합니다.

11장 오래된 데이터는 정상 데이터보다 더 위험할 수 있다#

전광판이 다음과 같이 표시하고 있다고 하겠습니다.

B2
15

문제는 이 숫자가 10분 전 값이라면 실제로는 이미 만차일 수도 있다는 점입니다.

따라서 데이터에는 Timestamp가 중요합니다.

예:

{
  "level": "B2",
  "free": 15,
  "timestamp": "2026-09-24T02:10:00Z"
}

현재 시간이:

11:20

인데 마지막 Update가:

11:10

이라면 시스템에서:

STALE

로 판단할 수 있습니다.

전광판에서도 정책에 따라:

를 계속 표시하기보다:

정보 확인 중

또는:

--

같은 표시를 선택할 수도 있습니다.

12장 Sequence Number를 사용하면 Event 순서를 확인하기 쉽다#

Network에서는 Message가 지연되거나 재전송될 수 있습니다.

예를 들어 Sensor 상태가:

Sequence 101
OCCUPIED

Sequence 102
VACANT

순서로 발생했다고 하겠습니다.

그런데 Network 지연 때문에 Server에는:

102
↓
101

순서로 도착할 수도 있습니다.

Timestamp나 Sequence 없이 마지막 도착 Message만 적용하면 상태가 다시:

OCCUPIED

로 돌아가는 문제가 발생할 수 있습니다.

따라서 Event에:

eventId

sequence

timestamp

sensorId

등을 넣으면 상태 순서를 판단하기 쉬워집니다.

예:

{
  "sensorId": "B2-A-045",
  "sequence": 102,
  "occupied": false,
  "timestamp": "2026-09-24T02:21:10Z"
}

Server가 이미 102를 처리했다면 이후 늦게 도착한 101은 오래된 데이터로 무시할 수 있습니다.

13장 Sensor Online과 주차면 상태를 분리해야 한다#

중요한 설계 포인트입니다.

Sensor가:

OCCUPIED

라고 마지막으로 보고한 뒤 통신이 끊겼다고 하겠습니다.

Server에 남아 있는 마지막 값은:

OCCUPIED

입니다.

하지만 현재 실제 상태는 알 수 없습니다.

그래서 다음 두 상태를 따로 관리하는 것이 좋습니다.

Occupancy
OCCUPIED

Communication
OFFLINE

또는:

occupancy
UNKNOWN

deviceStatus
OFFLINE

처럼 정책을 만들 수 있습니다.

단순히:

occupied = false

로 바꾸면 통신 장애 Sensor를 빈자리로 표시하는 심각한 문제가 생길 수 있습니다.

따라서:

Sensor 장애를 VACANT으로 처리해서는 안 됩니다.

14장 빈자리 숫자가 틀릴 때는 어디부터 확인해야 할까#

전광판은:

B3
0

으로 표시되는데 실제로는 빈자리가 많이 있다고 하겠습니다.

다음 순서로 확인합니다.

개별 Sensor#

Sensor Power

Detection 상태

Calibration

Sensor ID

Sensor 통신#

RS-485

Wireless

Address

Packet

Timeout

Controller#

Sensor 목록

Polling

Event 처리

Local Cache

집계 값

상위 Network#

Ethernet

Switch

VLAN

Gateway

MQTT / TCP

Server#

마지막 Event

Timestamp

Sequence

DB 상태

집계 Logic

전광판#

마지막 수신값

Communication

Display Mapping

전체 경로:

Parking Bay
↓
Sensor
↓
Controller
↓
Network
↓
Server
↓
Display Controller
↓
전광판

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

15장 현장에서 자주 발생하는 장애#

증상	주요 확인 항목
특정 주차면만 계속 점유	Sensor·Calibration·설치
여러 Sensor가 동시에 Offline	전원·RS-485 Bus·Gateway
한 층 전체 숫자가 고정	Floor Controller·Network
서버 숫자는 정상인데 전광판만 틀림	전광판 통신·Mapping
전광판 숫자가 늦게 변함	Polling 주기·Queue·Network
무선 Sensor가 간헐적으로 누락	RSSI·Battery·간섭
재부팅 후 상태가 과거 값으로 돌아감	Cache·Retain·Timestamp
빈자리가 실제보다 많음	Offline Sensor를 VACANT 처리했는지 확인

특히:

여러 장비가 동시에 고장처럼 보인다.

면 개별 Sensor보다 공통 Controller·전원·Network부터 확인하는 것이 효율적입니다.

16장 로그에는 상태가 어떻게 바뀌었는지 남긴다#

좋지 않은 Log:

Sensor updated

보다 다음이 유용합니다.

2026-09-24 11:20:32.125

sensorId
B2-A-045

previous
VACANT

current
OCCUPIED

sequence
10234

controller
CTRL-B2-01

Controller 집계 Log:

2026-09-24 11:20:32.130

level
B2

previousFree
19

currentFree
18

전광판 Update:

2026-09-24 11:20:32.180

display
DISPLAY-B2-01

value
18

이렇게 하면 하나의 차량 주차 Event가:

Sensor
↓
Controller
↓
집계
↓
전광판

까지 정상 전달됐는지 추적할 수 있습니다.

17장 자기 점검#

주차면 Sensor가 직접 빈자리 수를 계산하는가#

일반적으로 개별 Sensor는 자신의 점유 상태를 제공하고 Controller나 중앙 Server가 여러 Sensor 상태를 모아 빈자리 수를 계산합니다.

Sensor가 Offline이면 VACANT으로 처리하면 되는가#

아닙니다. 실제 상태를 알 수 없기 때문에 장애·UNKNOWN 상태로 별도 관리하는 것이 안전합니다.

전광판 숫자가 틀리면 전광판이 고장난 것인가#

반드시 그렇지는 않습니다. Sensor·Controller·집계 Logic·Network에서 이미 잘못된 값이 만들어졌을 수 있습니다.

MQTT Retain을 사용하면 항상 좋은가#

마지막 상태를 빠르게 제공하는 장점이 있지만 오래된 상태를 현재 값으로 오인하지 않도록 Timestamp와 유효성 정책이 필요합니다.

Sensor 상태와 Event는 무엇이 다른가#

상태는 현재 점유 여부이고 Event는 VACANT에서 OCCUPIED로 바뀌는 것처럼 특정 시점에 발생한 상태 변화입니다.

18장 이 글을 마치며#

주차유도 시스템의 전체 흐름은 다음과 같습니다.

Parking Bay
↓
Vehicle
↓
Parking Sensor
↓
VACANT / OCCUPIED
↓
RS-485 / Wireless
↓
Floor Controller
↓
State Validation
↓
Free Count
↓
Ethernet / MQTT / TCP
↓
Central Server
↓
Display Data
↓
전광판·방향 안내

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

주차유도 시스템의 빈자리 숫자는 전광판이 직접 만드는 값이 아니라 개별 주차면 Sensor의 상태를 Controller나 Server에서 집계한 결과입니다.

VACANT·OCCUPIED 같은 현재 상태와 VEHICLE_ENTER·VEHICLE_EXIT 같은 상태 변화 Event는 서로 다른 정보로 관리하는 것이 좋습니다.

Sensor와 Controller 사이에는 RS-485·CAN·무선 등 다양한 통신 방식이 사용될 수 있으며 실제 Interface와 Protocol은 제조사 규격을 확인해야 합니다.

Sensor가 Offline이라고 빈자리로 판단해서는 안 되며 Occupancy 상태와 Device Communication 상태를 분리해서 관리해야 합니다.

Timestamp·Sequence Number·Event ID를 함께 사용하면 늦게 도착한 Message나 중복 Event 때문에 과거 상태가 현재 상태를 덮어쓰는 문제를 줄일 수 있습니다.

전광판 정보가 잘못됐을 때는 Sensor → Controller → Network → Server → 전광판 순으로 데이터가 어디까지 정상인지 확인해야 합니다.

결국 주차유도 시스템을 이해한다는 것은 단순히 주차면에 센서를 설치하고 전광판에 숫자를 표시하는 것을 의미하지 않습니다.

한 대의 차량이 주차면에 들어온 순간 발생한 물리적 변화가 Sensor 상태로 변환되고, Controller의 집계와 Network 전송을 거쳐 중앙 Server와 전광판의 실시간 정보로 이어지는 전체 데이터 흐름을 이해하는 것이 핵심입니다.

[주차유도 시스템]은 어떻게 동작할까? 주차면 센서·Controller·전광판 데이터 흐름 이해하기