BACnet 기초 BACnet

BACnet은 현대 건물 자동화 시스템 대부분에서 사용하는 프로토콜입니다. 냉동기 플랜트 제어반, VAV(가변 풍량) 박스 컨트롤러, JACE 또는 EBO 상위 관리 장치 (건물의 컨트롤러를 관리하는 게이트웨이와 서버), Distech 액추에이터, Honeywell 옥상형 공조기를 다룬다면 거의 확실히 BACnet으로 통신하고 있습니다. 배경을 간단히 살펴보면, ASHRAE는 특정 제조사에 종속되지 않는 건물 제어용 공통 언어를 만들기 위해 1987년에 개발을 시작했습니다. BACnet을 정의하는 ASHRAE 135 표준은 산업의 요구 변화에 따라 새로운 객체 유형과 서비스를 계속 추가하며 발전해 왔습니다. 이 페이지는 BACnet/IP 16진수 변환기 도구의 각주에서 안내하는 기초 설명입니다.

BACnet인 것과 아닌 것

BACnet을 규정하는 핵심 개념은 장치가 자신을 스스로 설명한다는 것입니다. 네트워크의 BACnet 장치는 숫자로 가득 찬 메모리 블록만 노출하지 않습니다. 이름과 형식이 지정된 객체 목록을 제공하며, 각 객체에는 다시 이름과 형식이 지정된 속성이 있습니다. 장치에 어떤 객체가 있는지 물으면 답하고, 개별 객체의 이름, 단위, 현재 값을 물어도 답합니다. 프로토콜 자체에 충분한 메타데이터가 포함되어 있으므로 클라이언트는 처음 방문한 건물에서도 컨트롤러에 질의해 실제로 사용할 수 있는 포인트 목록을 만들 수 있습니다. 이 특성만으로도 기존 프로토콜과 뚜렷이 구별됩니다.

가장 자주 비교되는 대상은 Modbus입니다. Modbus는 의도적으로 단순합니다. 레지스터는 16비트에 불과하며, 그 비트가 십분의 일 도 단위 온도인지 여러 상태를 묶은 워드인지는 제조사 매뉴얼을 봐야만 알 수 있습니다. BACnet은 반대입니다. BACnet의 Analog Input 객체는 자신에 대해 Object_Name, Units, Description, 현재 Present_Value, 상한과 하한, 그 밖의 수십 가지 속성을 알고 있습니다. 이 정보를 별도 문서에 둘 필요가 없습니다. 프로토콜이 레이블과 값을 함께 전달합니다.

BACnet은 특정 배선 하나를 뜻하지도 않습니다. ASHRAE 135는 객체, 속성, 서비스, 주소 지정으로 구성된 프로토콜 논리를 한 번 정의한 뒤, 이를 여러 물리 매체로 전달할 수 있도록 몇 가지 데이터 링크 옵션을 정의합니다. 현장에서 주로 접하는 두 방식은 일반 Ethernet/IP 네트워크의 UDP 데이터그램을 사용하는 BACnet/IP와, 토큰을 전달하는 마스터 링을 구성해 RS-485 연선에서 동작하는 BACnet MS/TP입니다. TLS WebSocket을 사용하는 최신 BACnet/SC(Secure Connect)와 기존 BACnet/Ethernet도 있지만 건물 자동화 시스템(BAS) 업무에서는 비교적 드뭅니다. 어떤 데이터 링크를 사용하더라도 상위 객체 모델과 서비스는 같습니다.

장치, 객체, 속성

모든 정보는 세 개의 중첩 계층에 담깁니다. 장치는 JACE, VAV 박스 컨트롤러, 냉동기 내장 BACnet 카드, MS/TP 온도조절기 같은 컨트롤러입니다. 각 장치는 BACnet 네트워크 전체에서 고유한 장치 인스턴스 번호 하나를 가집니다. 값의 범위는 0부터 4,194,302까지이며 흔히 device:1001처럼 표기합니다. 장치는 자신을 하나의 Device 객체로 노출합니다.

장치 안에는 객체가 있습니다. 장치가 네트워크에 노출하려는 모든 입력, 출력, 설정값, 스케줄, 경보, 달력 항목, 파일, 논리 포인트는 객체입니다. 각 객체는 유형(Analog Input, Binary Output, Multi-state Value, Schedule 등)과 장치 내부에서 고유한 인스턴스 번호를 가집니다. 이 두 값이 객체의 Object_Identifier를 구성합니다. 내부적으로는 객체 유형 10비트와 인스턴스 번호 22비트를 하나의 32비트 값에 담지만, 사람이 읽을 때는 항상 analog-input,3 또는 AI:3처럼 두 값을 함께 표기합니다.

객체 안에는 속성이 있습니다. 모든 객체는 최소한 Object_Identifier, Object_Name, Object_Type, 현재 Present_Value를 가집니다. 대부분은 이외에도 열두 개 이상의 속성을 제공합니다. Analog Input은 일반적으로 Units, Description, Status_Flags, High_Limit, Low_Limit, COV_Increment 등도 노출합니다. 실제 데이터는 속성에 들어 있으며, 모든 읽기와 쓰기는 특정 장치의 특정 객체에 있는 특정 속성을 대상으로 합니다.

객체 유형은 몇 가지 익숙한 계열로 묶을 수 있습니다. 그중 아날로그, 바이너리, 다중 상태의 구분을 기억해 두세요.

이외에도 Schedule, Calendar, Trend Log, Notification Class, File, Loop, Group 등 여러 객체가 있으며 각각 고유한 속성 집합을 가집니다. 대부분의 BAS 업무에서는 아날로그·바이너리·다중 상태 계열, 장치 탐색을 위한 Device 객체, 시간대별 로직을 위한 Schedule 계열을 주로 다룹니다. 나머지는 특정 기능이 필요할 때 나타납니다.

현장에서 접하는 서비스

서비스는 객체 모델에 수행하는 동작입니다. 클라이언트가 속성을 읽거나 쓰고, 경보를 확인하거나, 값 변경 알림을 구독하기 위해 통신망에 보내는 요청입니다. ASHRAE 135에는 약 서른다섯 가지 서비스가 정의되어 있지만 일반적인 BAS의 거의 모든 작업은 다음 몇 가지가 처리합니다.

• ReadProperty — 한 객체의 속성 하나를 가져옵니다. 일상적인 읽기 요청은 "device:1001의 AI:3에 있는 Present_Value는 무엇인가?"와 같습니다. 응답에는 해당 속성이 보유한 형식 지정 값(실수, 정수, 불리언, 열거형, 문자열)이 들어 있습니다.
• WriteProperty — 한 객체의 속성 하나를 설정합니다. 일상적인 쓰기 요청은 "AO:1의 Present_Value를 우선순위 16에서 75 %로 설정하라"와 같습니다. 명령 가능 객체에서는 우선순위도 쓰기 요청의 일부입니다. 다음 절에서 자세히 설명합니다.
• ReadPropertyMultiple / WritePropertyMultiple — 여러 속성을 한 요청으로 가져오거나 설정합니다. 그래픽 화면에 필요한 포인트를 컨트롤러에서 폴링할 때 수많은 개별 ReadProperty 호출 대신 이 서비스를 사용합니다. 속성 하나를 요청하든 서른 개를 요청하든 네트워크 오버헤드는 같습니다.
• SubscribeCOV + ConfirmedCOV-Notification — Change of Value(COV, 값 변경)입니다. 클라이언트가 폴링하는 대신 한 번 구독하면, 값이 해당 속성의 COV_Increment보다 크게 변할 때마다 장치가 알림을 보냅니다. 가져오는 방식이 아니라 푸시 방식입니다. Modbus에서는 값 변경을 놓치지 않도록 클라이언트가 충분히 자주 폴링해야 하지만, BACnet에서는 변경이 발생했을 때 장치가 클라이언트에 알릴 수 있습니다. 구독에는 유효 기간이 있으므로 클라이언트는 만료 전에 다시 구독합니다.
• Who-Is / I-Am — 장치 탐색을 처리하는 비확인형 브로드캐스트 쌍입니다. 다음 절에서 따로 설명합니다.

AcknowledgeAlarm, ReinitializeDevice, AtomicReadFile, CreateObject, 시간 동기화 서비스 등은 관련 기능을 사용할 때 나타납니다. 위 다섯 가지가 건물 전체에서 이루어지는 일상적인 읽기, 쓰기, 알림의 거의 전부를 처리합니다. 확인형과 비확인형의 구분, 서비스 계열, 특정 장치가 실제로 어떤 서비스를 지원하는지 나타내는 BIBB는 BACnet 서비스에서 더 자세히 설명합니다.

우선순위 배열 — BACnet 명령 스택

모든 명령 가능 객체, 즉 Analog Output, Binary Output과 명령 가능으로 구성된 Analog/Binary/Multi-state Value에는 Priority_Array라는 특수 속성이 있습니다. 대기 중인 명령을 보관하는 16슬롯 배열이며 인덱스는 1부터 16까지입니다. Present_Value에 대한 WriteProperty는 값을 단순히 덮어쓰지 않고 선택한 우선순위의 배열 슬롯에 기록합니다. 그러면 객체의 실제 Present_Value는 번호가 가장 낮은 null이 아닌 슬롯의 값으로 결정됩니다. 모든 슬롯이 null이면 Relinquish_Default 속성값을 사용합니다.

슬롯 1의 우선순위가 가장 높고 슬롯 16이 가장 낮습니다. 업계 관행상 번호가 낮은 슬롯은 중요한 명령을 위해 예약합니다. 슬롯 1은 수동 인명 안전 명령, 슬롯 5와 6은 중요 설비 및 최소 켜짐·꺼짐 명령에 사용합니다. 슬롯 8은 운영자의 수동 강제 조작, 슬롯 16은 BMS의 일반 제어 시퀀스가 기록하는 슬롯입니다. 슬롯 9–15는 주로 애플리케이션별 용도로 사용할 수 있습니다. 전체 예약표는 ASHRAE 135에 있습니다. 일상적인 고장 진단에서는 "슬롯 8이 슬롯 16보다 우선하며, 슬롯 8에 null을 쓰면 슬롯 16이 제어권을 넘겨받는다"는 원칙을 기억하면 됩니다.

예제를 따라가 보겠습니다. BMS 제어 시퀀스가 슬롯 16에 댐퍼 개도 65 %를 씁니다. 기술자가 운영자 워크스테이션에서 같은 댐퍼를 슬롯 8의 0 %로 수동 강제 조작합니다. 이제 객체의 Present_Value는 0 %로 결정됩니다. 슬롯 8의 인덱스가 슬롯 16의 시퀀스보다 낮아 우선순위가 더 높기 때문입니다. 작업이 끝나면 기술자는 슬롯 8에 null을 쓰는 같은 WriteProperty 요청을 보냅니다. 슬롯 8이 비고, null이 아닌 가장 낮은 번호의 슬롯이 16이 되면서 댐퍼는 다시 65 %로 돌아갑니다. 제어 시퀀스에 별도 알림을 보낼 필요 없이 시퀀스 값이 새로운 최종값이 됩니다.

명령 가능 BACnet 포인트를 읽을 때 두 가지를 기억해야 합니다. 첫째, 그래픽 화면에 보이는 값은 우선순위에 따라 결정된 값이며 BMS 제어 시퀀스가 쓰는 값과 같지 않을 수 있습니다. 제어 시퀀스가 우선순위 16에 65 %를 쓰고 있어도, 누군가 몇 년 전에 슬롯 8에 쓴 강제 조작을 해제하지 않았다면 시퀀스가 "고장 난" 것처럼 보입니다. 둘째, null을 쓰면 명령이 해제되며 다른 값으로 덮어쓰는 것이 아닙니다. 강제 조작을 해제하지 않는 것은 현장에서 우선순위 배열 로직에 문제가 생기는 가장 흔한 원인입니다.

슬롯에 값을 입력하고 ×를 눌러 명령을 해제한 뒤 Present_Value가 다음 우선 슬롯의 값으로 바뀌는 과정을 직접 확인하려면 우선순위 배열 결정 도구를 사용하세요. 이 절의 대화형 실습 도구이며 16개 슬롯의 전체 예약표도 함께 제공합니다.

빈 배열이 아니라 실제로 운전 중인 장비에서 같은 결정 규칙을 확인하려면 DDC 워크벤치를 사용하세요. 기능 블록 프로그램으로 공기조화기(AHU)를 운전하며 모든 명령 가능 포인트에 개별 우선순위 배열을 제공합니다. 각 포인트는 세 단계로 명령됩니다. 제어 시퀀스는 슬롯 16에, 사용자의 수동 조작은 슬롯 8에 쓰며, 프로그램에 해당 블록이 없는 포인트는 Relinquish_Default로 넘어갑니다. NULL — 해제됨 상자의 선택을 해제한 채 두면, 하위 제어 시퀀스가 계속 올바르게 값을 써도 포인트가 고장 난 것처럼 보입니다. 이 절에서 설명한 장애를 실제 장비가 연결된 형태로 재현하는 것입니다. 먼저 더 작은 장비인 FCU 워크벤치에서 시험해 볼 수 있습니다.

Who-Is / I-Am — 장치가 자신을 알리는 방법

두 비확인형 서비스가 장치 탐색을 처리합니다. 클라이언트(BMS, 엔지니어링 도구, JACE)가 Who-Is 요청을 네트워크 전체에 브로드캐스트합니다. 요청의 의미는 이 범위에 포함되는 인스턴스 번호의 장치는 자신을 식별하라는 것입니다. 요청에 특정 범위, 즉 장치 인스턴스의 하한과 상한을 넣을 수도 있고 범위를 생략해 "네트워크의 모든 장치는 응답하라"고 요청할 수도 있습니다.

브로드캐스트를 수신하고 범위에 해당하는 모든 장치는 I-Am으로 응답합니다. 이 비확인형 브로드캐스트에는 장치 자신의 인스턴스 번호, 최대 APDU 길이(한 메시지로 수신할 수 있는 최대 크기), 세그멘테이션 지원 여부, 공급업체 ID가 들어 있습니다. 이 교환은 한 번으로 끝나며 그 밖의 항목을 협상하지 않습니다.

실제로는 EBO의 탐색 대화상자, N4 Workbench의 BACnet 네트워크 스캔, Yabe 같은 도구에서 이 과정을 볼 수 있습니다. 도구가 Who-Is를 보내고 I-Am 응답으로 장치 목록을 채운 다음, 이어지는 ReadProperty 호출을 바탕으로 나머지 포인트 브라우저를 구성합니다. 목록에 나타나지 않는 장치는 거의 항상 Who-Is / I-Am 과정에 문제가 있습니다. 브로드캐스트가 장치에 도달하지 않았거나 응답이 되돌아오지 못한 것입니다. 장치 탐색이 라우터를 넘지 못하는 이유는 BACnet 네트워킹에서 먼저 설명합니다.

MS/TP와 BACnet/IP — 같은 프로토콜, 다른 전송 방식

현장에서 접하는 두 BACnet 데이터 링크는 MS/TP와 BACnet/IP입니다. 객체 모델, 속성 이름, 서비스, 우선순위 배열은 두 방식에서 완전히 같으며 각 메시지를 둘러싼 프레이밍만 달라집니다.

BACnet MS/TP는 2선식 RS-485 버스에서 동작합니다. 약 서른 대까지의 마스터가 토큰을 전달하며 버스를 공유합니다. 토큰을 보유한 컨트롤러만 송신할 수 있고, 메시지를 보내거나 할당된 프레임 수를 모두 사용하면 주소 번호 순서상 다음 마스터로 토큰을 넘깁니다. 버스는 몇 가지 정해진 보드레이트 중 하나로 동작하며 일반적으로 38400 또는 76800을 사용합니다. 버스 전체는 하나의 16비트 네트워크 번호를 공유하는 BACnet 네트워크입니다. Ethernet보다 느리지만 저렴하고 견고해 대부분의 VAV 컨트롤러, 여러 소형 유닛 컨트롤러, MS/TP 전용 온도조절기에서 사용합니다.

BACnet/IP는 동일한 BACnet 메시지를 일반 Ethernet 네트워크의 UDP 데이터그램 안에 넣습니다. IANA에 등록된 포트는 UDP 47808이며, 16진수로 0xBAC0입니다. 이 값에서 "BACnet" 포트를 기억하기 위한 연상 표기가 나왔습니다. BACnet/IP 컨트롤러에는 IP 주소와 포트로 접근하며, 동일한 장치 인스턴스 번호로 자신을 식별하고 같은 서비스를 모두 사용합니다. 달라지는 것은 각 메시지를 감싸는 프레이밍입니다. 작은 BACnet 가상 링크 계층(BVLL) 헤더, BACnet 네트워크 계층 헤더, 실제 서비스 순서로 구성됩니다. 브로드캐스트 방식의 차이는 BACnet 네트워킹에서 먼저 다룹니다.

이 구분은 통신이 어디에서 가능한지를 결정하므로 실무적으로 중요합니다. MS/TP 버스는 폐쇄된 저속 직렬 루프입니다. 커미셔닝은 빠르지만 모든 장치가 물리적으로 같은 루프에 있어야 합니다. BACnet/IP는 건물에 이미 구축된 라이저, 스위치, VLAN 등의 Ethernet을 사용하며 같은 IP 세그먼트에 있는 두 장치 사이에서 통신할 수 있습니다. 라우터나 다른 서브넷 같은 L3 경계를 넘을 때는 별도의 브로드캐스트 규칙이 적용됩니다. BACnet 네트워킹은 이 내용부터 설명합니다.

토큰 순환, 마스터/슬레이브 토큰 패싱 동작, Max_Master와 Max_Info_Frames, 세그먼트별 장치 수와 케이블 길이 제한 등 MS/TP의 세부 내용은 BACnet MS/TP에서 다룹니다. BMS 기술자가 주로 접하는 커미셔닝과 버스 장애 진단을 중심으로 구성했습니다.

이 페이지에서 다루지 않은 내용

지금까지 설명한 프로토콜 구조만 알아도 BACnet 포인트 목록을 읽고, 읽기 또는 쓰기 요청을 구성하고, 우선순위 배열의 강제 조작을 알아차리고, Who-Is 장치 탐색을 시작할 수 있습니다. 다음 질문은 통신하려는 장치가 송신 측과 같은 Ethernet 세그먼트에 없을 때 어떤 일이 생기는가입니다. 브로드캐스트 동작, BBMD와 외부 장치 등록(Foreign Device Registration), 세 계층의 주소 체계, BACnet/IP 변환기가 해석하는 EBO 16진수 데이터가 여기에 포함됩니다. BACnet 네트워킹에서 각각을 차례로 설명합니다.

MS/TP 토큰의 세부 동작(토큰 순환, Max_Master, Max_Info_Frames, 보드레이트와 케이블 길이 허용 한도)은 BACnet MS/TP에서 다루므로 이 페이지에서는 제외했습니다. 긴 메시지의 세그멘테이션, 경보와 이벤트 알림, 독립 객체 유형인 스케줄과 달력, 트렌드 로그, File/Group/Loop/Notification Class 객체도 범위에 포함하지 않았습니다. 나머지 주제는 향후 별도 페이지에서 다루며, 이 페이지는 객체 모델, 서비스, 우선순위 배열에 집중합니다.