대규모 SCADA 프로젝트의 태그 명명 규칙과 엔지니어링 템플릿

태그명이 흐트러지면 후공정에서 치르는 대가

• 중복과 충돌: 두 스테이션이 모두 Pump1_Run 을 갖고, 리포트가 섞이며, 이벤트가 어느 현장인지 구분되지 않는다
• 화면과 태그가 어긋난다: HMI 표시명은 고쳤는데 실제 태그는 전기 담당의 약어 그대로여서, 장애 분리에 어휘가 두 벌 필요하다
• 알람 문구를 태그에서 생성하지 못한다: 메시지를 손으로 쓰기 때문에 프로세스 측 개명이 알람 목록에 닿지 않는다
• 증설이 혼란을 복제한다: 다음 구역을 첫 구역에서 복사하며 나쁜 이름까지 가져가고, 라인이 늘 때마다 정리 비용이 커진다
• 인계가 구전에 의존한다: T12 가 A펌프 토출 온도인 줄 아는 사람은 원래 담당뿐이고, 그 사람은 이미 현장에 없다

이 다섯 대가는 시운전 중이 아니라 그 이후에 나타납니다. 그래서 미루기 쉽고, 사후 수습 비용은 큽니다. 명명 규칙은 첫 주에 정하는 편이 싸고, HMI가 가동된 뒤 수만 개 태그를 바꾸는 일은 같은 양의 일이 아닙니다.

명명 규칙이 커버해야 할 필드: 구역, 설비, 신호, 유형

명명 규칙은 취향이 아닙니다. 모든 태그, 알람 문구, 화면 객체를 그로부터 이끌어 내는 계약입니다. 필드가 빠지면 후공정 스크립트는 구역으로 걸러내지 못하고, 알람 문구를 만들지 못하며, 프로세스 값과 지령도 가리지 못합니다.

아래 네 필드는 첫 태그를 만들기 전에 정해야 하는 하한입니다. 구분자, 길이, 문자 집합도 같은 규칙에 넣습니다. 브랜드가 섞인 PLC와 이후 데이터베이스 내보내기가 느슨한 철자를 허용하지 않기 때문입니다. 당사는 단일 프로젝트에서 약 80000 변수, 366대 설비를 동일 네트워크로 수집한 실적이 있습니다. 이 숫자는 개별 건의 서술이며, 전형적인 규모도 아니고 모든 계약에 내거는 태그 수 상한도 아닙니다. 보여주는 것은 태그 수가 많아져도 규칙이 버텨야 한다는 점입니다. 파일럿 라인 수백 점에서만 깔끔해서는 부족합니다.

• 구역(사이트, 라인, 건물): 자산의 지리적 소속 — 공장, 작업장, 라인, 펌프장 코드. 이것이 없으면 다른 건물의 동일 기종이 충돌한다
• 설비(유닛, 스키드, 개별 기기): 자산 자체 — 압축기, 컨베이어, 펌프 세트. 한 기기의 신호가 함께 정렬되도록 한다
• 신호(측정값 또는 기능): 읽거나 쓰는 것 — 운전 피드백, 토출 압력, 고장, 설정값
• 유형(클래스): 아날로그 입력, 아날로그 출력, 디지털 입력, 디지털 출력, 연산점, 알람, 설정값. 히스토리안, 화면, 알람 엔진이 점의 성격대로 다루게 한다
• 구분자, 길이, 문자 집합: 구분자는 하나(밑줄이 흔한 방법), 길이는 가장 짧은 PLC와 히스토리안이 모두 받는 값, 공백과 내보내기를 깨는 로케일 기호는 태그명에 넣지 않는다

화면보다 먼저 내는 엔지니어링 템플릿: I/O 할당, 점표, 화면 사양서

화면은 SCADA 프로젝트에서 눈에 보이는 부분이라 논의가 화면부터 시작되기 쉽습니다. 대규모 건에서는 순서를 뒤집습니다. I/O 할당, 점표, 화면 사양서는 누군가 그리기 전에 있어야 합니다. 이 셋이 없으면 이후 화면은 즉석에서 이름을 만들고, 가동 중인 시스템에 대조할 마스터가 남지 않습니다.

위의 수집 규모에 더해, 당사는 약 30000 알람 포인트 규모의 프로젝트에서 알람 엔지니어링을 수행했습니다. 이 숫자들은 개별 건의 실증이며, 모든 현장이 그 규모일 것으로 보는 값이 아닙니다. 소프트웨어가 몇 점까지 받는지 홍보하는 문구도 아닙니다. 한 세그먼트의 태그 수 상한은 대역폭, 폴링 주기, 서버 여유에서 정해지며, 시운전 때 처음 아는 것이 아니라 아래 템플릿에 적어 둡니다.

• I/O 할당표: 함체, 슬롯, 채널, 신호 유형, 엔지니어링 레인지, 목적지 태그명. PLC 주소 부여 전에 동결한다
• 점표(태그 목록): 마스터 — 태그명, 설명, 구역, 설비, 주소, 데이터형, 스캔 클래스, 단위, 알람 플래그. 한 점 한 행, 파일 책임자는 한 명
• 화면 사양서: 어떤 화면이 있는지, 어떤 태그를 바인드하는지, 탐색과 알람 표시. 작화 전에 쓰고, 작화 뒤 보강으로 남기지 않는다
• 주소와 네트워크도: 어느 컨트롤러가 어느 범위를 가지는지, 동일 세그먼트 대수, 합의한 폴링 주기에서 그 세그먼트가 감당할 태그 수 상한

나쁜 명명, 그것이 일으키는 문제, 권장 구조

아래 표는 현장에서 쓰는 점검 목록이며 만능 규격이 아닙니다. 세 번째 열의 형은 AREA_EQ_SIGNAL_TYPE 입니다. 네 필드를 자사 공장에 맞게 채운 뒤 철자, 구분자, 길이를 동결하고, 이후 반입은 같은 계약을 타게 합니다.

권장 구조는 출발 템플릿입니다. 문자 집합, 길이, 구역과 설비의 구체 코드는 사용 중인 PLC 브랜드와 히스토리안에 맞춰 현장과 합의합니다.

알람 점과 프로세스 점은 나누어 관리한다

프로세스 점은 「지금 얼마인가」에 답하고, 알람 점은 「사람이 움직여야 하는가」에 답합니다. 수백 점에서는 한 점에 같이 두고 싶어지고, 수천 점에서는 감당하지 못합니다. 알람 목록은 프로세스 점표의 생략 명명을 그대로 물려받아, 이후 정리에 깨끗한 목록이 남지 않습니다.

등급 구분, 억제, 복귀 이력 보관은 별도 설계입니다. SCADA 알람 정리 칼럼에서 다루었고, 이 절은 그 등급 튜토리얼을 반복하지 않습니다. 여기서 정하는 것은 후공정을 가능하게 하는 분리입니다. 두 점군, 두 책임자, 구역·설비·신호에서 알람 문구를 만들 수 있는 하나의 명명 계약입니다.

• 점군을 나눈다: 알람이 필요한 프로세스 점에는 짝이 되는 알람 점, 또는 이름으로 연결한 알람 기록을 둔다. 겸용 점으로 만들지 않는다
• 알람 문구는 명명 필드에서 생성한다: 구역, 설비, 신호로 읽을 수 있는 문장을 만들고, 개명 때 태그와 문구를 함께 갱신한다
• 책임자를 나눈다: 프로세스 점은 I/O와 히스토리안, 알람 점은 운전 측이 가지며 등급과 종료 규칙을 붙이고, 두 목록은 다른 주기로 검토한다
• 알람 등급을 모든 프로세스 이름에 복사하지 않는다: 등급은 알람 기록에 속한다. HH, H, L, LL 을 수천 개 프로세스 점에 넣으면 이후 재등급이 대량 개명이 된다

약 30000 알람 포인트 프로젝트에서 버틴 것은 이 분리이지, 더 큰 화면이 아닙니다. 대부분의 공장은 이 수량에 이르지 않습니다. 수백 건 단계에서 점군을 나누는 이유는, 그때 비용이 아직 낮기 때문입니다.