로봇 안전 제어는 안전 센서·논리·구동부를 하나의 기능 사슬로 정의하고, 단일 고장이 위험한 출력으로 이어지지 않도록 이중 채널, 진단, 상호감시와 안전 상태를 설계하는 일입니다. 워치독과 하트비트는 정지·지연을 찾는 보조수단이지 값의 타당성이나 공통 원인 고장을 자동으로 해결하지 않으며, 안전 PLC도 올바른 사양·배선·프로그램·검증이 있어야 안전 기능이 됩니다.
아래에서는 용어의 차이를 실제 시스템 경계, 실패 조건과 검증 순서로 나눠 살펴봅니다.
안전 제어 아키텍처는 센서 두 개가 아니라 위험을 감지하고 구동을 멈추는 전체 사슬이다
사람 감지 센서나 비상정지 접점에서 시작해 입력 모듈, 안전 논리, 통신, drive 안전 입력, contactor·brake와 feedback까지가 하나의 안전 기능입니다. 어느 한 구간의 고장이 위험 운동을 계속 허용할 수 있는지 기능별로 분석합니다.
로봇 기능안전 PL·SIL은 요구 무결성을 정하는 틀을 설명합니다. 이 글에서는 숫자 계산보다 그 요구를 실제 회로와 software state, 진단과 fault reaction으로 옮기는 아키텍처에 집중합니다.
이중 채널의 목적은 한 채널 고장을 견디고 가능한 한 고장을 발견하는 데 있다
두 접점이나 두 센서가 같은 정보를 독립 경로로 보내면 한 경로의 단선·stuck 신호를 다른 경로와 비교할 수 있습니다. 그러나 동일한 케이블, 전원, connector, software와 환경에 묶이면 한 원인으로 동시에 실패할 수 있습니다.
ISO 13849-1:2023은 안전 관련 제어부의 설계·통합 방법과 성능수준 체계를 제공합니다. 요구 category나 architecture를 제품 개수로 추정하지 말고 위험성평가와 전체 기능 계산·검증으로 결정합니다.
채널 설계표에는 독립성·진단·고장 반응·복구 가능성을 같이 적는다
채널 A와 B가 무엇을 측정하고 어디서 분리되며 어느 지점에서 비교되는지 도면에 표시합니다. 단선, 24V 단락, cross-short, 접점 용착, sensor alignment 오류, stale value와 입력 모듈 고장을 각각 어떤 진단이 찾는지 연결합니다.
진단이 즉시 고장을 찾지 못하면 다음 demand 전까지 발견되는지, 고장 상태에서 추가 fault가 위험을 만드는지 봅니다. discrepancy timeout은 정상 접점 시차보다 길고 위험 노출보다 짧아야 하며 현장 튐을 숨기도록 무한정 늘리면 안 됩니다.
| 구간 | 대표 고장 | 진단 수단 | 요구 반응 |
|---|---|---|---|
| 센서 | 단선·stuck·misalign | pulse·discrepancy·test | 안전 상태+fault |
| 논리 | program·memory·cycle | self-test·cross-check | output disable |
| 통신 | loss·delay·repeat | CRC·counter·timeout | defined fallback |
| 구동 | output stuck·brake fail | EDM·feedback·motion | 재기동 금지 |
제어반 사진에서 확인할 것은 부품 브랜드보다 전원·배선·단자와 채널의 물리적 분리다
사진처럼 PLC와 I/O가 한 제어반에 모이면 배선 정비는 쉬워지지만 같은 전원, 단자대, cable duct, 온도와 오염이 공통 원인이 될 수 있습니다. 안전 채널의 색상·단자·경로를 식별하고 잘못된 jumper나 유지보수 중 교차 연결 가능성을 줄입니다.
일반 PLC와 safety PLC의 역할을 문서에서 분리하고, 일반 제어가 안전 출력을 강제로 우회할 수 없게 권한과 interface를 제한합니다. 사진의 PLC가 어떤 인증을 가졌는지 알 수 없으므로 실제 제품 인증서와 configuration manual을 확인해야 합니다.
워치독은 실행 정지와 기한 초과를 찾지만 잘못된 값을 정상 주기로 보내는 고장은 찾지 못한다
CPU watchdog은 task가 정해진 시간 안에 끝나는지, communication heartbeat는 상대 노드가 응답하는지 확인할 수 있습니다. 그러나 센서가 0을 고정 출력하거나 algorithm이 그럴듯한 잘못된 값을 반복하면 heartbeat는 정상일 수 있습니다.
ROS 2 실시간 제어의 deadline과 jitter 감시는 일반 제어 품질에 유용하지만 safety watchdog과 동일하지 않습니다. 안전 기능에 의존하려면 timer의 독립성, 고장 시 출력, 검증된 software 경계와 인증 조건을 확인합니다.
통신 안전은 패킷 수신 여부뿐 아니라 출처·순서·나이·무결성과 연결 상태를 확인한다
안전 메시지에는 sequence counter, timestamp 또는 age, timeout, identifier와 무결성 검사를 사용해 반복·지연·누락·삽입·잘못된 수신자를 검출합니다. 네트워크가 살아 있어도 오래된 ‘safe’ 값을 재생하면 위험할 수 있습니다.
로봇 ROS 2·DDS 사이버보안의 인증·권한·암호화는 악의적 접근을 줄이지만 기능안전 통신 진단을 자동으로 대신하지 않습니다. safety와 security 분석을 연결하되 각각의 위협·고장 가정을 유지합니다.
안전 PLC는 검증된 하드웨어 위에 제한된 프로그램·설정·I/O 구성이 맞을 때만 역할을 한다
안전 PLC의 인증 범위, 지원 safety function block, firmware, scan time과 proof test 조건을 확인합니다. 일반 변수와 안전 변수를 섞거나 bypass bit, 강제 출력, online edit 권한이 통제되지 않으면 인증된 CPU를 써도 응용 기능은 취약합니다.
IEC 62061:2021은 기계 안전 관련 제어시스템의 기능안전 설계·통합·검증 방법을 다룹니다. 적용 시 요구 SIL과 subsystem, software와 validation 범위를 프로젝트 문서에 추적합니다.
안전 출력은 명령을 보냈다는 사실과 실제 위험 에너지가 제거됐다는 사실을 구분한다
logic이 STO를 요청해도 drive가 수신하지 못하거나 contactor가 용착되고 brake가 체결되지 않을 수 있습니다. output readback, external device monitoring, drive status와 실제 motion 또는 pressure feedback을 이용해 가능한 고장을 진단합니다.
관절 브레이크와 안전 정지처럼 수직축은 torque off 뒤 중력 운동이 생길 수 있습니다. 브레이크의 안전 역할, feedback, stopping sequence와 periodic test를 출력 아키텍처에 포함합니다.
공통 원인 고장은 채널 두 개를 한 번에 무력화하므로 배치·환경·설계 다양성을 검토한다
공통 전원 과전압, 물 유입, 과열, 진동, EMI, 케이블 절단, 동일 firmware bug와 동일한 잘못된 요구사항은 두 채널을 동시에 망가뜨릴 수 있습니다. 물리 분리, 독립 보호, 적절한 diversity와 환경 정격을 위험에 맞게 적용합니다.
로봇 위험성평가 FMEA·STPA를 이용해 부품 고장뿐 아니라 잘못된 control action과 interface assumption도 찾습니다. 독립 센서 두 개가 동일한 잘못된 coordinate frame을 쓰는 체계적 오류도 고려합니다.
점검표는 정상 신호보다 고장 주입 때 안전 상태와 진단이 동시에 나타나는지 확인한다
입력 A 단선, B stuck-high, 두 채널 short, heartbeat freeze, sequence repeat, PLC cycle overrun, output transistor stuck, contactor 용착과 brake feedback 불일치를 계획된 안전 절차로 주입합니다. 각 fault에서 정지 시간, fault code와 restart inhibit를 기록합니다.
고장 시험은 우연히 멈췄는지와 설계된 경로로 멈췄는지를 구분해야 합니다. 두 번째 고장을 추가하기 전에 첫 고장이 검출·유지보수되는 시간, power cycle 후 fault 보존과 bypass 해제 여부도 확인합니다.
검증은 요구사항 검토·회로 분석·software review·시험을 서로 보완하게 구성한다
도면과 I/O list에서 안전 기능 경계를 추적하고, FMEA와 계산으로 구조·진단·고장률 가정을 검토합니다. software에는 상태 전이, timeout, reset, mode selection과 bypass authority를 review하고 실제 장비 시험으로 시간과 fault reaction을 확인합니다.
ISO 13849-2:2012는 분석과 시험을 통한 안전 기능·category·PL 검증을 다룹니다. 이 판본은 현재 ISO 목록상 유효하지만 후속 ISO/DIS 13849-2가 진행 중이므로 적용 시 최신 발행 상태를 다시 확인합니다.
안전 제어 인수 기준은 단일 고장 견딤·진단·안전 상태·복구 통제가 증거로 이어지는 것이다
safety requirement specification에 trigger, response time, safe state, demand rate, reset과 diagnostic coverage 가정을 적고 회로·PLC program·parameter·시험 case의 식별자를 연결합니다. 제품 인증서는 이 추적성을 보조할 뿐 응용 검증을 대체하지 않습니다.
합격은 정의된 고장 주입에서 위험 출력이 허용되지 않고 진단이 요구 시간 안에 나타나며, 공통 원인 대책과 출력 feedback이 확인되고, bypass·mode·configuration 변경이 승인과 재검증 없이 남지 않는 것입니다.
| 인수 항목 | 필수 증거 | 실패 예 | 재검증 계기 |
|---|---|---|---|
| 요구 | SRS·safe state·time | 모호한 stop 범위 | 위험·운전 변경 |
| 구조 | channel·CCF·interface | 공통 전원·배선 | hardware 변경 |
| 논리 | version·review·timeout | bypass·stale 허용 | software 변경 |
| 시험 | fault injection·trace | 진단 없는 정지 | firmware·setting 변경 |
로봇 안전 제어 아키텍처에서 자주 묻는 질문
센서를 두 개 달면 이중 채널 안전 기능인가요?
자동으로 그렇지 않습니다. 전원·배선·논리·출력의 독립성, 진단, 공통 원인과 전체 성능을 확인해야 합니다.
워치독이 있으면 software 오류를 모두 잡나요?
아닙니다. 실행 정지나 기한 초과는 찾을 수 있지만 정상 주기로 전송되는 잘못된 값과 요구사항 오류는 별도 검증이 필요합니다.
일반 PLC 대신 safety PLC만 쓰면 PL·SIL을 만족하나요?
아닙니다. 요구 수준, 인증 범위, I/O와 프로그램 구조, 배선, 고장률 계산과 응용 검증이 모두 맞아야 합니다.
안전 통신에 암호화가 필수인가요?
기능안전과 사이버보안 요구를 함께 분석해야 합니다. 암호화는 보안에 유용하지만 sequence·age·timeout 같은 안전 통신 진단을 대신하지 않습니다.
고장 주입은 실제 장비를 망가뜨리지 않나요?
안전한 시험 계획과 승인된 방법으로 입력·통신·feedback 고장을 모사합니다. 위험한 물리 파손 대신 test interface와 제조사 절차를 사용해야 합니다.
안전 제어 아키텍처와 PL·SIL 판단은 적용 법규, 최신 표준 원문, 인증된 구성품 자료와 자격을 갖춘 검증 절차를 따라야 합니다. 이 글은 특정 회로의 적합성을 보증하지 않습니다.