PLC Alarm Logic이란?｜설비 이상을 감지하고 기록하는 방법

PLC Alarm Logic은 센서와 설비 상태를 감시해 이상 조건을 판단하고 경보를 발생·기록하는 제어 로직입니다. Alarm 발생 조건부터 Latch, Reset, Interlock, HMI 이력 관리와 설계 시 주의사항까지 알아봅니다.

자동화 설비에서는 모터 과부하, 센서 이상, 압력 저하, 온도 상승처럼 다양한 문제가 발생할 수 있습니다. 이러한 이상 상태를 작업자가 즉시 알 수 없다면 불량품이 생산되거나 설비가 손상될 가능성이 있습니다.

PLC에서는 단순히 설비를 움직이는 프로그램만 작성하는 것이 아니라 설비의 이상 상태를 감지하고 필요한 동작을 정지시키며 작업자에게 원인을 알려주는 프로그램도 함께 구성합니다.

이러한 제어 구조를 일반적으로 Alarm Logic이라고 합니다.

Alarm Logic을 제대로 설계하려면 단순히 경고등을 켜는 것에서 끝나는 것이 아니라 Alarm 발생 조건, 유지 방식, Reset 조건, HMI 표시와 발생 이력까지 함께 고려해야 합니다.

PLC Alarm Logic이란 무엇일까?

PLC Alarm Logic은 설비의 입력신호와 내부 상태를 감시하여 미리 정의된 이상 조건이 발생했는지를 판단하는 프로그램 로직입니다.

예를 들어 모터가 운전 중인데 Overload 신호가 발생했다고 가정해 보겠습니다.

PLC에서는 다음과 같은 논리로 Alarm을 구성할 수 있습니다.

모터 운전 중 + Overload 신호 ON → Motor Overload Alarm 발생

Alarm이 발생하면 단순히 내부 Bit 하나를 ON시키는 것에 그치지 않고 설비의 목적에 따라 여러 동작을 연계할 수 있습니다.

모터를 정지시키거나 다음 공정을 진행하지 못하도록 Interlock을 걸고 HMI에 Motor Overload 메시지를 표시할 수 있습니다.

필요하다면 경광등이나 부저를 동작시키고 Alarm 발생시간을 기록할 수도 있습니다.

따라서 Alarm Logic은 이상 감지 → Alarm 판단 → 설비 보호 → 작업자 통보 → 이력 관리까지 연결되는 중요한 제어 기능입니다.

PLC에서는 어떤 조건을 Alarm으로 판단할까?

Alarm 조건은 설비 특성에 따라 매우 다양합니다.

대표적으로 디지털 입력을 이용하는 방법이 있습니다.

Motor Overload Relay, 비상정지 관련 상태, 압력스위치, 온도스위치 등의 접점 상태를 PLC가 확인하여 이상 여부를 판단할 수 있습니다.

아날로그 데이터를 이용해 Alarm을 발생시키는 방법도 있습니다.

예를 들어 정상 압력 범위가 정해져 있다면 현재 압력값이 기준보다 낮아졌을 때 Low Pressure Alarm을 발생시킬 수 있습니다.

현재 압력 < Low Limit → Low Pressure Alarm

온도도 마찬가지입니다.

현재 온도 > High Limit → High Temperature Alarm

하지만 단순히 기준값을 한 번 벗어났다고 바로 Alarm을 발생시키면 순간적인 노이즈나 측정값의 흔들림 때문에 불필요한 Alarm이 반복될 수 있습니다.

따라서 실제 설비에서는 Alarm의 성격에 따라 시간지연, Deadband 또는 Hysteresis 등의 조건을 함께 검토할 수 있습니다.

Alarm에 Delay Time을 사용하는 이유

센서값은 항상 완벽하게 일정하지 않습니다.

예를 들어 정상 운전압력이 5bar 정도인 설비에서 순간적으로 압력이 떨어졌다가 바로 회복되는 현상이 발생할 수 있습니다.

이때 압력이 기준값 아래로 내려가는 순간마다 Alarm을 발생시키면 작업자는 실제 고장이 아닌 상황에서도 반복적으로 경고를 확인해야 합니다.

이를 줄이기 위해 일정 시간 이상 이상상태가 지속되었을 때 Alarm을 발생시키는 방식을 사용할 수 있습니다.

예를 들어 다음과 같습니다.

압력 Low 조건 발생 → 3초 지속 → Low Pressure Alarm

순간적으로 0.5초 정도 압력이 떨어졌다가 정상으로 돌아온다면 Alarm을 발생시키지 않고 3초 이상 지속되는 경우에만 이상으로 판단하는 방식입니다.

다만 모든 Alarm에 Delay를 적용하는 것이 적절한 것은 아닙니다.

즉시 대응이 필요한 보호 조건은 불필요한 지연을 두어서는 안 됩니다. 특히 사람의 안전과 관련된 기능은 일반 PLC Alarm Logic만으로 처리하기보다 관련 안전규격과 설비 위험성 평가에 맞는 안전회로 또는 Safety PLC 등의 구조를 검토해야 합니다.

Alarm Latch는 왜 사용할까?

설비 이상이 아주 짧은 시간 동안 발생했다가 사라지는 경우가 있습니다.

Alarm 조건과 Alarm Bit를 단순히 동일하게 구성하면 원인이 사라지는 순간 Alarm 표시도 함께 사라질 수 있습니다.

작업자가 HMI를 확인했을 때는 이미 Alarm이 사라져 어떤 문제가 있었는지 알기 어려울 수 있습니다.

이런 상황에서 Alarm Latch를 사용할 수 있습니다.

개념적으로는 다음과 같습니다.

이상 조건 발생 → Alarm Bit ON → 원인이 사라져도 Alarm 상태 유지

이후 작업자가 문제를 확인하고 Reset 조건이 충족되면 Alarm을 해제합니다.

이 방식을 사용하면 순간적인 이상도 작업자가 확인할 때까지 기록하거나 표시할 수 있습니다.

그러나 모든 Alarm을 무조건 Latch 방식으로 구성할 필요는 없습니다.

설비 상태를 실시간으로 보여주는 Warning은 조건이 정상으로 돌아오면 자동 해제하도록 구성할 수도 있고 중요한 Fault는 작업자의 확인과 Reset이 필요하도록 구성할 수 있습니다.

Alarm Reset은 어떻게 설계할까?

Alarm Logic에서 발생 조건만큼 중요한 것이 Reset 조건입니다.

가장 단순한 방법은 작업자가 Reset 버튼을 누르면 Alarm Bit를 OFF시키는 것입니다.

하지만 실제 프로그램에서는 Reset 버튼만 눌렀다고 무조건 Alarm을 해제하도록 만드는 것이 적절하지 않을 수 있습니다.

예를 들어 Motor Overload가 아직 발생한 상태인데 Reset 버튼을 누른다고 Alarm 표시만 사라진다면 실제 이상상태와 HMI 표시가 일치하지 않게 됩니다.

따라서 일반적으로 다음과 같은 구조를 고려할 수 있습니다.

Alarm 원인 제거 + Reset 명령 → Alarm 해제

즉 작업자가 Reset 버튼을 누르더라도 실제 고장 원인이 정상으로 복구되었는지 확인한 후 Alarm을 해제하는 방식입니다.

설비에 따라서는 원인이 정상으로 복귀하면 자동으로 Alarm을 해제하는 Auto Reset 방식도 사용할 수 있습니다.

어떤 Reset 방식을 사용할지는 Alarm의 중요도와 설비 운전조건을 고려하여 결정해야 합니다.

Alarm과 Warning은 어떻게 구분할까?

모든 이상상태가 설비를 즉시 정지해야 할 정도로 심각한 것은 아닙니다.

따라서 Alarm Logic을 설계할 때는 이상상태의 수준을 구분하면 관리하기 편리합니다.

예를 들어 윤활유 부족이 예상되지만 아직 운전 가능한 상태라면 Warning으로 표시할 수 있습니다.

반대로 Motor Overload처럼 계속 운전하면 장비에 문제가 발생할 수 있는 상황이라면 Fault 또는 Alarm으로 처리하고 설비를 정지시킬 수 있습니다.

시스템에 따라 다음과 같이 분류하기도 합니다.

구분	의미	일반적인 처리 예
Information	상태 안내	화면 표시
Warning	주의 필요	메시지·경고등
Alarm	이상 발생	경보·동작 제한
Fault	운전 지속 곤란	설비 또는 관련 장치 정지

다만 이러한 용어와 등급은 회사나 프로젝트, HMI 시스템에 따라 다르게 정의될 수 있습니다.

따라서 중요한 것은 명칭 자체보다 각 등급이 발생했을 때 설비가 어떻게 동작해야 하는지 명확하게 정의하는 것입니다.

Alarm과 Interlock은 무엇이 다를까?

Alarm과 Interlock도 자주 함께 사용되는 개념입니다.

Alarm은 이상상태가 발생했다는 사실을 작업자에게 알리는 기능에 가깝습니다.

Interlock은 특정 조건이 충족되지 않았을 때 설비의 동작을 제한하는 제어조건입니다.

예를 들어 안전도어가 열려 있다는 상태를 HMI에 표시하는 것은 Alarm 또는 Warning Logic과 관련될 수 있습니다.

반면 특정 운전조건이 충족되지 않았을 때 모터 운전 명령이 성립하지 않도록 하는 것은 Interlock Logic의 영역입니다.

실제 프로그램에서는 두 기능이 함께 사용되는 경우가 많습니다.

이상 조건 감지 → Alarm 발생 → 관련 운전 Interlock

이렇게 구성하면 작업자는 왜 설비가 정지했는지 HMI에서 확인할 수 있습니다.

단, 사람의 안전을 위한 Safety Interlock은 일반적인 PLC 프로그램의 Interlock과 동일한 개념으로 취급해서는 안 되며 필요한 안전등급에 맞는 별도의 설계가 필요합니다.

HMI에서는 Alarm을 어떻게 표시할까?

PLC에서 Alarm Bit를 생성했다면 작업자가 이를 쉽게 확인할 수 있어야 합니다.

HMI에서는 PLC의 Alarm Bit와 메시지를 연결하여 현재 발생한 Alarm을 화면에 표시할 수 있습니다.

예를 들어 PLC에서 다음과 같은 Alarm Bit를 사용할 수 있습니다.

Motor Overload Alarm

Low Air Pressure Alarm

High Temperature Alarm

Sensor Error Alarm

HMI에서는 각 Bit가 ON될 때 해당하는 Alarm 메시지를 표시하도록 설정합니다.

단순히 Alarm 001처럼 표시하는 것보다 어떤 장치에서 무엇이 발생했는지 알 수 있도록 구체적인 메시지를 작성하는 것이 유지보수에 유리합니다.

예를 들어 ALM-021 Motor Error보다 Conveyor Motor #1 Overload처럼 대상과 원인을 함께 표현하면 작업자가 문제를 더 빠르게 파악할 수 있습니다.

Alarm History는 왜 중요할까?

현재 발생 중인 Alarm만 확인해서는 설비 문제의 원인을 찾기 어려운 경우가 있습니다.

이때 중요한 것이 Alarm History입니다.

Alarm History에는 시스템 구성에 따라 Alarm 발생시각, 복구시각, Alarm 이름, Alarm 번호, 확인 여부 등의 정보를 저장할 수 있습니다.

예를 들어 다음과 같은 형태입니다.

14:10:25 / Low Air Pressure / 발생

14:10:32 / Servo Alarm / 발생

14:11:05 / Low Air Pressure / 복구

이 기록을 확인하면 어떤 문제가 먼저 발생했는지 파악하는 데 도움이 됩니다.

예를 들어 Servo Alarm이 먼저 발생했다고 생각했지만 실제 이력을 확인해 보니 그보다 몇 초 전에 Air Pressure Alarm이 발생했다면 고장 원인을 분석하는 방향이 달라질 수 있습니다.

따라서 복잡한 자동화설비에서는 Alarm History가 중요한 유지보수 자료가 됩니다.

PLC RTC와 Alarm History는 어떤 관계가 있을까?

Alarm 발생시각을 기록하려면 정확한 시간정보가 필요합니다.

이때 PLC의 **RTC(Real Time Clock)**를 활용할 수 있습니다.

Alarm이 발생하는 순간 현재 날짜와 시간을 함께 저장하면 언제 문제가 발생했는지를 확인할 수 있습니다.

하지만 PLC Clock이 실제 시간과 맞지 않는다면 Alarm History 역시 잘못된 시간으로 기록됩니다.

특히 여러 PLC와 HMI, SCADA가 함께 사용되는 시스템에서는 장치마다 시간이 다르면 이벤트 발생 순서를 정확하게 분석하기 어려울 수 있습니다.

따라서 Alarm History를 중요하게 사용하는 설비라면 RTC 상태와 시간 동기화 방식도 함께 관리하는 것이 좋습니다.

Alarm Acknowledge는 Reset과 다를까?

HMI Alarm 시스템에서는 Acknowledge(ACK) 기능을 사용하는 경우가 있습니다.

Acknowledge는 일반적으로 작업자가 해당 Alarm을 확인했다는 의미입니다.

반면 Reset은 Alarm 상태나 관련 Fault를 해제하는 동작을 의미할 수 있습니다.

따라서 개념적으로는 다음과 같이 구분할 수 있습니다.

Alarm 발생 → 작업자 확인(Acknowledge) → 원인 제거 → Reset → 정상복귀

하지만 실제 동작 방식은 HMI와 PLC 프로그램 설계에 따라 달라질 수 있습니다.

Acknowledge 버튼을 눌렀다고 실제 고장조건까지 사라지는 것은 아닙니다.

따라서 확인, 원인 복구, Alarm 해제를 각각 어떤 조건으로 처리할지 명확하게 설계하는 것이 중요합니다.

Alarm Logic을 작성할 때 주의할 점

Alarm Logic에서 가장 중요한 것은 실제 원인과 표시되는 Alarm을 일치시키는 것입니다.

Alarm이 너무 민감하면 순간적인 신호 변화에도 계속 경보가 발생하는 Alarm Chattering 또는 Alarm Flood와 같은 문제가 생길 수 있습니다.

반대로 조건을 지나치게 느슨하게 설정하면 실제 이상상태를 늦게 감지할 수 있습니다.

따라서 센서 특성과 공정 특성을 고려하여 Delay Time과 정상범위, Reset 조건 등을 결정해야 합니다.

Alarm 번호와 메시지의 관리도 중요합니다.

프로그램에서는 Alarm Bit가 M100이라고만 되어 있고 HMI에서는 별도의 이름으로 관리한다면 프로그램 규모가 커질수록 유지보수가 어려워질 수 있습니다.

Alarm 번호, PLC 변수명, HMI 메시지를 일정한 규칙으로 관리하면 문제를 찾기가 쉬워집니다.

또한 사용하지 않는 Alarm이나 의미가 중복되는 Alarm을 지나치게 많이 만들면 정작 중요한 Alarm이 묻힐 수 있습니다.

따라서 Alarm은 많이 만드는 것보다 작업자가 원인을 이해하고 필요한 조치를 할 수 있도록 설계하는 것이 중요합니다.

PLC Alarm Logic 핵심 정리

PLC Alarm Logic은 설비의 센서와 내부 상태를 감시하여 이상 조건을 판단하고 작업자에게 알리며 필요한 제어동작과 이력을 관리하는 프로그램 구조입니다.

단순히 Alarm Bit를 ON시키는 것만으로 완성되는 기능은 아닙니다.

이상 조건이 얼마 동안 지속되어야 Alarm으로 판단할 것인지, 원인이 사라져도 Latch할 것인지, 어떤 조건에서 Reset할 것인지, 관련 설비를 정지시킬 것인지 등을 함께 설계해야 합니다.

HMI와 연동한다면 Alarm 이름과 발생시간, 복구시간 및 확인 여부 등을 기록하여 Alarm History로 관리할 수 있습니다.

특히 RTC를 이용해 정확한 발생시각을 기록하면 반복되는 설비 이상이나 고장 발생 순서를 분석하는 데 도움이 됩니다.

결국 좋은 Alarm Logic은 단순히 **“고장이 발생했다”**고 알려주는 프로그램이 아니라 **“어디에서 어떤 문제가 발생했고 작업자가 무엇을 확인해야 하는지 알 수 있도록 만드는 프로그램”**이라고 할 수 있습니다.