Modbus는 개방적이고 일반적이며 비교적 사용하기 쉽고 적용에 제한이 거의 없습니다. 그러나 단점이 있습니다. 대부분의 경우 사용자는 기존 센서 또는 Modbus를 통해 통신해야 하는 기타 장치와 같은 하드웨어 제약 때문에 사용할 수 밖에 없습니다. Modbus를 사용해야 하거나 많은 옵션이 있는 경우 프로토콜에 내재된 이점과 제한 사항을 이해해야 합니다.
Modbus가 작업에 적합하다면 사용 방법을 아는 것이 중요합니다. 이를 구현하기위한 옵션은 무엇입니까? 이 프로토콜을 활용하기 위해 응용 프로그램을 어떻게 디자인해야 합니까?
프로토콜 선택 및 설계 고려 사항
Modbus 애플리케이션 계층은 다양한 네트워킹 계층에서 단일 지점 데이터를 전송하기 위한 요청-응답, 마스터-슬레이브 설계로 구현됩니다. 이 기본 설계는 잘 작동하지만 일부 응용 프로그램에는 단점이 있습니다.
Modbus는 SCADA(Supervisory Control and Data Acquisition) 시스템과 자동화 장치 간의 상호 작용을 위한 요청-응답 프로토콜입니다. 전송된 모든 요청에 대해 대상 장치가 응답해야 합니다. 모든 요청에 대해 하나의 응답이 있습니다. 또한 요청은 단일 소스에서 시작되고 단일 디바이스를 대상으로 하는 경우가 많습니다. 이러한 시스템은 요청을 생성하고 응답을 기다리는 클라이언트 장치와 클라이언트의 요청을 구문 분석하고 처리한 다음 응답을 반환하는 서버 장치를 포함하는 것이 특징일 수 있습니다(그림 1 참조).
Modbus 용어는 일반적으로 SCADA 호스트이기 때문에 클라이언트를 마스터로 자주 지칭하고 서버를 슬레이브로 지칭합니다. 슬레이브는 일반적으로 센서 또는 자동화 컨트롤러입니다.
그림 1. 요청-응답/클라이언트-서버 모델
Modbus 상호 작용의 신뢰성
Modbus 메시징 패턴은 HTTP에서 정의한 것과 유사합니다. 이 패턴의 장점은 매우 안정적인 네트워크 계층이 필요하지 않다는 것입니다. 클라이언트(또는 마스터)가 요청을 보내고 응답을 받지 못하면 문제가 있음을 알고 요청을 다시 보낼 수 있습니다. HTTP 비유를 사용하면 웹 브라우저에서 새로 고침 버튼을 클릭하는 것과 같습니다. 반복적으로 요청을 보내고 서버에서 응답을 받지 못하면 서버가 다운된 것으로 간주되어 일시적으로 액세스 시도를 중지할 수 있습니다.
이는 Modbus 통신이 끊어졌을 때 KEPServerEX 및 NI OPC 서버와 같은 일부 OPC 서버에서 나타나는 동작과 유사합니다. 이렇게 하면 제어력 상실을 방지할 수는 없지만 마스터 장치가 제어가 손실되는 시점을 알 수 있으며 안전 장치를 연결하거나 중복 장치를 사용하여 제어를 유지하는 등 적절한 조치를 취할 수 있습니다. 슬레이브 또는 서버에는 해당되지 않습니다.
모든 요청이 마스터 장치에서 나와야 한다는 요구 사항 때문에 지능형 슬레이브는 통신이 끊어졌다는 신뢰할 수 있는 표시가 없습니다. 슬레이브가 요청을 받지 못하면 네트워크가 다운되었거나, 마스터가 다운되었거나, 마스터가 요청 전송을 중단하기로 결정했음을 의미할 수 있습니다. 이러한 신뢰할 수 있는 상태 정보의 부족은 여러 가지 방법으로 해결할 수 있지만 시스템 개발자는 그 필요성을 이해해야 합니다.
이 문제에 대한 일반적인 해결 방법은 장치에 워치독 타이머가 있는 것입니다. 지정된 시간 내에 요청이 수신되지 않으면 슬레이브 장치는 무언가가 실패했다고 가정하고 안전한 상태로 들어갑니다. 장치 및 특정 응용 프로그램에 따라 이는 시스템의 전체 제어에 유익하거나 해로울 수 있습니다.
간단한 워치독 솔루션에는 요청이 수신되고 있다는 것만 확인한다는 한계가 있습니다. 복잡성이 증가하는 체계를 사용할 수 있지만 일반적으로 사용되는 간단하고 효과적인 방법은 레지스터 수준 하트비트를 구현하는 것입니다. 장치가 이를 지원하거나 처음부터 새 장치를 개발하는 경우 이 접근 방식은 애플리케이션 수준에서 마스터와 슬레이브 간의 지속적인 통신을 보장합니다. 즉, 마스터의 제어 코드가 하트비트 값의 변경을 담당하고 슬레이브의 제어 코드가 이를 읽는 역할을 하는 경우 하트비트 값은 정상적인 시스템 기능을 확인하는 간단한 테스트를 나타냅니다.
마스터 제어 코드부터 네트워킹 계층을 거쳐 슬레이브의 제어 루프에 이르는 시스템 기능은 이 레지스터 레벨 하트비트 테스트를 통해 검증됩니다. 슬레이브에서 수정되고 마스터에서 읽혀지는 또 다른 레지스터는 다른 방향의 통신을 나타내는 데 사용될 수도 있습니다.
그림 2. 간단한 하트비트 구현
이 마스터-슬레이브 아키텍처의 특성상 Modbus 슬레이브는 마스터에게 요청하지 않은 데이터를 제공할 수 없습니다. 마스터는 슬레이브에 데이터를 전송하기 위해 이벤트 기반 아키텍처를 구현할 수 있지만, 새 데이터를 검색하기 위해 정의된 속도로 슬레이브를 지속적으로 폴링해야 합니다. 변경이 제한되는 경우 네트워크 대역폭과 마스터 CPU 사용률 측면에서 상당한 오버헤드가 필요합니다.
정보를 자주 업데이트하는 사용 사례(예: 온도 센서)에서는 이 설계가 잘 작동합니다. 이 데이터는 지속적으로 변하기 때문에 응용 프로그램에서 정의한 속도로 폴링하는 것이 좋습니다. 반대로, 경보 비트 또는 상태 물리적 스위치와 같이 느리게 업데이트되는 데이터 요소는 값 변경이 발생할 때까지 기다렸다가 이러한 변경이 발생할 때만 마스터를 업데이트함으로써 보다 효과적으로 모니터링됩니다. 그럼에도 불구하고 Modbus는 각 값을 주기적으로 폴링해야 합니다.
네트워크 제어 및 결정론
슬레이브가 원치 않는 데이터를 마스터로 보낼 수 없다는 것은 Modbus가 일부 애플리케이션에 필요한 수준의 네트워크 제어를 제공한다는 것을 의미합니다. 취약한 네트워크에서 요청-응답 프로토콜은 마스터가 네트워크에서 통신이 발생하는 시기를 결정할 수 있는 유일한 장치임을 보장할 수 있습니다. 올바르게 구성된 경우 마스터가 네트워크 패킷 충돌을 제거하고 더 높은 수준의 결정성을 보장할 수 있음을 의미합니다.
이것은 또한 네트워크 통신이 항상 안정된 상태에 있다는 점에서 제어 시스템에 대해 보다 일반적인 이점을 가질 수 있습니다. 이벤트 기반 정보가 슬레이브에 의해 네트워크를 통해 전송되면 시스템에 지터가 발생합니다. 일부 응용 프로그램에서는 허용될 수 있지만 데이터 전송에 엄격한 폴링 메커니즘을 사용하면 이러한 위험을 줄일 수 있습니다.
태그 지향 커뮤니케이션 및 데이터 구성
Modbus 데이터는 태그 또는 변수의 개념을 중심으로 합니다. 이러한 데이터 요소(홀딩 레지스터, 입력 레지스터, 코일 및 이산 입력)는 프로토콜 내에서 다른 이름으로 호출되지만 아이디어는 동일합니다. 이러한 태그는 언제든지 쓰거나 읽을 수 있는 데이터 요소이지만 현재 값만 제공합니다. 이것은 많은 응용 프로그램에 적합합니다. 그러나 이벤트, 메시지 또는 선입선출 메모리 버퍼(FIFO)와 같은 개념을 구현하는 것은 어려울 수 있습니다.
Modbus는 프로토콜에 의해 전송되는 대부분의 정보를 저장하는 23개의 데이터 뱅크를 정의합니다. 마스터의 각 요청은 단일 데이터 뱅크에서 단일 작업을 수행할 수 있습니다. 즉, 단일 요청은 코일 뱅크에서 읽거나 코일 뱅크에 쓸 수 있지만 둘 다 쓸 수는 없습니다. 그러나 예외가 있습니다.
예를 들어, 함수 코드 23을 사용하면 마스터가 단일 요청/응답 주기에서 홀딩 레지스터를 쓰고 홀딩 레지스터를 읽을 수 있습니다. 그러나 이 코드는 일반적으로 구현되는 함수 코드가 아닙니다. 마스터 및 슬레이브 장치 설명서를 모두 확인하여 이 기능 코드를 사용할 수 있는지 확인해야 합니다.
또한 지정된 뱅크의 데이터는 Modbus 프로토콜의 패킷 크기 제한까지만 순차적으로 액세스할 수 있다는 점을 이해하는 것이 중요합니다. 이 제한은 일반적으로 약 240-250바이트의 페이로드 데이터이지만 사용되는 특정 함수에 따라 다릅니다. 따라서 레지스터 뱅크를 신중하게 설계하는 것이 매우 중요합니다.
예를 들어, 주어진 애플리케이션은 빠른 속도로 상당한 양의 데이터를 전송해야 할 수 있습니다. 이 경우 필요한 요청 수를 최소화하는 것이 좋습니다. 데이터는 순차적으로 액세스해야 하므로 이 애플리케이션은 단일 레지스터 뱅크에 가능한 한 많은 데이터를 집중시키고 사용되지 않는 최소 수의 데이터 요소와 함께 데이터를 압축하는 것이 좋습니다.
다른 응용 프로그램에는 일부 로컬 제어를 허용하는 더 복잡한 슬레이브가 있을 수 있습니다. 이 경우 빠른 속도로 읽히는 일부 데이터와 주기적으로 모니터링되는 일부 데이터가 있을 수 있습니다. 이 경우 데이터는 전송 속도별로 그룹화되어야 합니다. 빠르게 업데이트되는 데이터는 한 곳에 집중되어야 하며, 느리게 업데이트되는 데이터는 단일 요청으로 특정 데이터 세트를 더 쉽게 읽거나 업데이트할 수 있도록 여러 블록으로 구성되어야 합니다.
이를 설명하기 위해 빠르게 업데이트되는 1개의 데이터 값(F5-F1)과 느리게 업데이트되는 5개의 값(S1-S2)을 고려합니다. 또한 S1, S2 및 S3은 하나의 코드 모듈에 해당하고 S4 및 S5는 다른 코드 모듈에 해당하므로 서로 다른 시간에 업데이트될 수 있습니다. 그림 3에서 이 경우에 이상적인 조직은 마스터가 단일 요청으로 빠르게 업데이트되는 데이터를 읽은 다음 필요에 따라 느리게 업데이트되는 다른 데이터 세트를 읽을 수 있는 기능을 제공합니다.
그림 3. 잘 조직된 데이터
주의를 기울이지 않으면 그림 4와 같이 데이터 세트를 쉽게 구성할 수 있습니다. 이 경우 초당 20개 이상의 요청에서 초당 80개 이상의 요청으로 이동됩니다. 실제로 작은 데이터 세트가 단일 블록의 모든 것을 읽는 것이 더 효율적입니다. 그러나 이러한 접근 방식은 복잡한 시스템에서 빠르게 확장할 수 없게 됩니다.
그림 4. 열악한 데이터 구성
태그 번호 매기기
내부적으로 각 Modbus 뱅크의 데이터는 0에서 65,535까지의 주소 값을 사용하여 액세스되지만 문서에서 공통 주소 지정 체계를 사용하여 데이터 요소를 참조하는 것이 더 일반적입니다. 이러한 방식에서, 데이터 요소의 주소에는 액세스할 뱅크를 정의하는 번호가 접두사로 붙습니다. 표 1 에는 이러한 접두사가 표시되어 있습니다.
| 데이터 블록 | 접두사 |
| 코일 | 0 |
| 이산 입력 | 1 |
| 입력 레지스터 | 3 |
| 레지스터 보유 | 4 |
표 1. 데이터 액세스 접두사
참조되는 특정 설명서에 따라 주소 지정은 4005 또는 40004에서 시작하며 400005에서 <> 사이의 고정 너비를 사용합니다. 즉, 서로 다른 문서는 모두 4005, 40004, 및 400005와 같은 동일한 정수 보유 레지스터를 참조할 수 있습니다. 설명서는 사용되는 특정 주소 지정 체계를 정의해야 하며 새로운 시스템 개발은 이 정보를 게시해야 합니다.
네트워크 사용률
요청-응답 프로토콜이 반드시 네트워크 대역폭을 최대한 활용하는 것은 아닙니다. 특정 데이터 조각을 읽어달라는 마스터의 요청에는 확실히 응답이 필요하지만 데이터 쓰기 요청에는 응답이 필요하지 않습니다. 그러나 Modbus 애플리케이션 프로토콜에서는 모든 요청에 응답을 보내야 합니다. 즉, 프로토콜 데이터, 애플리케이션 데이터 및 필요한 네트워크 데이터를 포함하여 전체 Modbus 패킷이 형성되어야 합니다. 또한 네트워크 대기 시간, 슬레이브 처리 시간, 네트워크 충돌 또는 간섭으로 인해 데이터를 요청하고 응답으로 수신하는 프로세스가 단순히 데이터를 브로드캐스트하는 것보다 훨씬 더 오래 걸릴 수 있음을 의미합니다.
이는 위에서 설명한 데이터 조직 고려 사항으로 인해 더욱 악화됩니다. 데이터가 Modbus 메모리 공간 내에서 제대로 구성되지 않으면 필요한 요청-응답 주기 수가 크게 증가할 수 있습니다. 대기 시간 고려 사항으로 인해 네트워크 간섭 없이도 요청-응답 주기가 발생할 수 있는 유한한 속도가 있습니다. 결과적으로 마스터와 슬레이브 간의 상호 작용에 필요한 요청 수를 줄이는 것이 시스템 성능을 향상시키는 가장 중요한 방법 중 하나입니다.
보안 고려 사항
Modbus 프로토콜은 보안을 거의 또는 전혀 제공하지 않습니다. 과거에는 산업 네트워크의 제한된 특성으로 인해 네트워크에 침투하기 위해 물리적 보안 침해가 필요했습니다. 네트워크가 더욱 상호 연결됨에 따라 보안은 더욱 심각한 문제가 되고 있습니다. 최근 몇 년 동안 Modbus 프로토콜 통신을 확보하기 위한 다양한 방식이 공식화되었습니다. 그러나 이러한 체계는 일반적으로 기존 Modbus 네트워크 및 장치와의 호환성을 손상시킵니다.
구현 고려 사항
지정된 시스템의 전반적인 유틸리티는 선택한 특정 드라이버 구현에 따라 달라집니다. 일반적으로 Modbus 마스터는 라이브러리 또는 OPC 서버와 같은 독립형 도구를 통해 애플리케이션에 통합됩니다. 대조적으로, Modbus 슬레이브는 일반적으로 일종의 라이브러리를 사용하여 장치에 통합되거나 장치 펌웨어의 일부로 개발됩니다. 두 경우 모두 지정된 응용 프로그램에 가장 적합한 선택을 하는 데 사용할 수 있는 다양한 구현을 이해하는 것이 중요합니다.
응용 프로그램 또는 라이브러리
일반적으로 KEPServerEX 또는 NI OPC 서버와 같은 어플리케이션은 라이브러리보다 더 많은 기능을 갖추고 있지만 제어 기능은 적습니다. 예를 들어, 두 OPC 서버 애플리케이션 모두 특정 데이터 요소를 특정 속도로 제공하도록 구성할 수 있으며 둘 다 원시 Modbus 데이터를 정의된 데이터 유형으로 변환할 수 있습니다.
그러나 Modbus 요청을 직접 생성하고 보낼 수 없다는 점에서 제한적이며, 모든 요청이 애플리케이션을 통과하고 구성 옵션이 제한됩니다. 반대로 라이브러리는 일반적으로 원시 데이터를 제공하며 모든 요청을 시작해야 합니다. 이를 통해 유연성을 제공하고 모든 트래픽을 엄격하게 제어할 수 있습니다.
요청 스케줄링
응용 프로그램 또는 라이브러리 구현의 경우 전체 시스템의 일부가 요청을 예약하고 해당 요청의 형식을 결정합니다. 일반적으로 구현은 두 가지 형식 중 하나를 사용합니다. 첫 번째 가능성은 모든 요청과 응답이 순서대로 발생하도록 요구하는 것입니다. 이 동기 설계 접근 방식은 코드 작성이 간단하고 네트워크에 구애받지 않지만 TCP/IP 네트워크를 크게 활용하지 못할 수 있기 때문에 일반적으로 선택됩니다.
동기식 설계에서 마스터는 요청을 생성하고, 네트워크를 통해 요청을 보내고, 서버가 요청을 처리하고 응답을 생성할 시간을 가질 때까지 기다리고, 응답이 네트워크를 통과할 때까지 기다리고, 마지막으로 해당 응답을 처리하는 작업을 수행해야 합니다. 충분히 느린 슬레이브 장치 또는 네트워크 계층의 경우 이 왕복 시간이 중요할 수 있습니다.
대안은 마스터의 한 프로세스가 요청을 생성하고 다른 프로세스가 응답을 수신하고 이러한 응답을 데이터가 필요한 코드로 내부적으로 라우팅하는 비동기 디자인입니다. 이 설계는 네트워크에서 한 번에 여러 요청을 처리할 수 있기 때문에 훨씬 더 효율적이지만, 슬레이브의 메모리에 들어오는 요청을 처리할 수 있을 만큼 충분히 큰 버퍼가 있어야 하고 마스터 구현 개발자가 문제에 훨씬 더 많은 리소스를 투자해야 합니다. 그림 5는 이러한 두 메시지 전달 체계의 차이점을 보여 줍니다. 오른쪽의 각 화살표는 요청을 나타내고 왼쪽의 각 화살표는 응답을 나타냅니다.
그림 5. 동기식 메시지 전달과 비동기식 메시지 전달 비교
KEPServerEX 및 NI OPC 서버와 같은 일부 어플리케이션은 차이점을 분할하고 두 구현의 이점 중 일부를 제공하는 스레딩 체계를 구현합니다. 즉, 태그와 장치는 모든 요청이 단일 스레드에서 동기적으로 발생하거나 다른 스레드로 구성될 수 있도록 구성될 수 있습니다. 이 경우 지정된 스레드의 모든 태그가 동기적으로 요청되지만 여러 장치에 병렬로 액세스할 수 있습니다. 이렇게 하면 네트워크에 대한 상당히 엄격한 제어가 유지되는 동시에 시스템의 전반적인 성능이 향상됩니다.
유형 가용성
Modbus는 시스템의 데이터에 대한 제한을 거의 적용하지 않기 때문에 부분적으로 유연합니다. 대신 시스템 데이터는 최대 65,635개의 단어 크기 레지스터 또는 부울 요소로 구성된 최대 16개의 블록으로 구성됩니다. 데이터는 U16 또는 Boolean 유형의 요소에 저장되거나 하위 레지스터 값 또는 여러 레지스터의 경계를 넘는 데이터로 저장될 수 있습니다.
안타깝게도 이러한 유연성이 유용성을 의미하지는 않습니다. 데이터가 바이트 스트림으로 전송되는 TCP 및 직렬과 마찬가지로 Modbus를 사용하는 애플리케이션 코드는 시스템의 나머지 부분에서 이해할 수 있는 방식으로 해당 데이터를 포맷해야 합니다. 예를 들어, 첫 번째 및 두 번째 레지스터를 구성하는 32비트에서 단정밀도 부동 소수점 값으로의 데이터 변환은 전적으로 애플리케이션 코드에 달려 있습니다. 상황을 더 혼란스럽게 하기 위해 이 데이터의 순서는 프로토콜에 의해 정의되지 않습니다. 레지스터가 네트워크(빅 엔디안) 순서로 네트워크를 통해 전송되지만 다양한 디바이스가 교차 레지스터 경계를 다르게 처리한다고 정의합니다.
이 상황은 서로 다른 장치에 따라 가변성이 있을 수 있으므로 모든 구현에서 고려하는 것이 중요합니다. 라이브러리는 일반적으로 레지스터 형태로 원시 데이터를 제공하므로 응용 프로그램에 필요한 대로 데이터를 변환해야 합니다. 라이브러리에서 형식화된 데이터를 제공하는 경우 설명서를 참조하여 예상 형식을 이해해야 합니다. 반면, 응용 프로그램은 일반적으로 일부 가변성을 고려합니다. 예를 들어, KEPServerEX 및 NI OPC 서버는 디바이스별로 멀티레지스터 데이터 타입의 엔디안을 전환할 수 있는 기능을 제공합니다. 이 옵션이 노출되지 않으면 직접 구현하고 레지스터를 원시 데이터로 처리해야 할 수 있습니다.
어드레싱
앞서 논의한 바와 같이 Modbus의 주소 지정은 사용되는 체계가 다양하기 때문에 복잡합니다. 사양은 주소 지정 체계를 엄격하게 정의하지만(즉, 레지스터 번호 0를 유지하는 것은 기능 코드 0x04 있는 주소 0x03 요청하여 읽음) 디바이스는 일반적으로 이 정보를 단일 숫자로 변환합니다. 다른 출처의 문서는 다른 값을 참조하기 위해 동일한 숫자를 사용할 수 있습니다. 표준 라이브러리나 응용 프로그램을 사용할 때 이 점을 고려하는 것이 중요합니다.
일반적으로 라이브러리는 "400005"와 같은 일반적인 주소 지정 체계에서 레지스터 5를 유지하여 저장된 데이터에 대한 요청으로 변환하는 추상화를 제공하지 않습니다. 일부 라이브러리, 특히 형식 지원이 포함된 라이브러리는 그럴 수 있습니다.
대조적으로, OPC 서버 및 기타 애플리케이션은 보다 일반적인 주소 지정 체계를 사용할 가능성이 더 큽니다. NI OPC 서버 및 KEPServerEX와 같은 어플리케이션은 주소 지정 체계 (예 : 0 또는 1에서 시작하는 인덱싱)의 많은 순열을 처리 할 수있는 옵션도 제공합니다. 그러나 이러한 응용 프로그램에는 특히 레지스터를 다른 데이터 형식으로 해석할 때 여전히 특이한 요구 사항이 있을 수 있으며 데이터가 올바르게 전송되고 해석되도록 응용 프로그램 설명서를 항상 참조해야 합니다.
Modbus 구현 및 아키텍처 선택
Modbus가 어플리케이션을 위한 프로토콜로 선택되면, NI는 Modbus 통신을 위한 세 가지 기본 도구를 제공합니다. 가장 낮은 수준에서는 다양한 API 라이브러리를 사용할 수 있습니다. 이러한 라이브러리는 일반적으로 마스터와 슬레이브 지원을 모두 제공합니다. NI LabVIEW Datalogging and Supervisory Control (DSC) 및 LabVIEW Real-Time Module은 Modbus I/O 서버라는 도구를 제공하므로, 로우 레벨 라이브러리의 유연성과 편리한 사용을 제공합니다. I/O 서버는 마스터 및 슬레이브 지원도 제공합니다. 마지막으로, NI OPC 서버는 Modbus 마스터에 대한 드라이버 지원을 포함할 수 있는 완벽하게 작동하는 OPC 서버입니다.
NI OPC 서버는 SCADA 시스템의 백본이 될 수 있는 모든 기능을 갖춘 독립형 OPC 서버 어플리케이션입니다. OPC UA가 출시되기 전의 모든 OPC 서버와 마찬가지로, NI OPC 서버는 Windows 전용 프로그램이므로 슬레이브 디바이스의 고속 컨트롤을 위한 시스템보다는 감독 시스템으로 사용하기에 가장 적합합니다. NI OPC 서버는 Modbus 디바이스뿐만 아니라 다양한 벤더별 프로토콜 또는 OPC UA와 같은 표준 프로토콜을 사용하는 디바이스와 통신할 수 있도록 다양한 드라이버 세트를 제공합니다. 일반적인 시스템은 그림 6과 같습니다.
그림 6. 이 일반적인 SCADA 어플리케이션은 Modbus TCP/IP 디바이스 세트와 NI OPC 서버 호스트를 사용합니다.
많은 OPC 서버와 마찬가지로 NI OPC 서버에는 대용량 데이터 타입, 디바이스별 엔디안 설정, 요청 스케줄링 기능 및 Modbus의 로우 레벨 세부 정보를 추상화하는 더 많은 기능을 처리할 수 있는 기능이 있습니다. 데이터가 애플리케이션에 들어간 후 OPC 또는 OPC UA를 사용하여 로거, HMI(휴먼 머신 인터페이스) 또는 기타 Windows 애플리케이션으로 전송할 수 있습니다.
그림 7. 일반적인 SCADA 어플리케이션에 대한 이 확장된 보기에는 Windows 기반 데이터 히스토리언과 HMI 간의 상호 작용이 포함됩니다.
I/O 서버를 사용하는 Modbus
LabVIEW에 포함된 Modbus I/O 서버는 사용하기 쉬운 OPC 서버와 프로토콜을 완벽하게 제어할 수 있는 강력한 로우 레벨 라이브러리 사이의 중간 지점을 제공합니다. OPC 서버와 마찬가지로 I/O 서버는 Modbus 장치와 통신하기 위한 간단한 구성 기반 인터페이스를 허용합니다. OPC 서버와 마찬가지로 I/O 서버에는 자체 요청 스케줄링 시스템이 포함되어 있으며 데이터 엔디안과 같은 Modbus의 많은 하위 수준 주의 사항을 처리합니다.
그러나 I/O 서버는 LabVIEW에서 간단한 인터페이스를 제공하며 처리된 데이터(레지스터 45 및 46의 단정밀도 부동 소수점 값) 또는 원시 데이터(레지스터 16의 부호 없는 45비트 정수)에 빠르고 쉽게 액세스할 수 있는 기능을 프로그램에 제공합니다. OPC 서버와 마찬가지로 I/O 서버는 일반적으로 감독 제어가 중요한 애플리케이션에 사용되는 반면 분산 마이크로 컨트롤러는 시스템의 고속 제어를 담당합니다.
Modbus 마스터 I/O 서버
I/O 서버는 애플리케이션 내에서 실행되는 기본 OPC 서버로 생각할 수 있습니다. 일반적으로 Modbus 마스터 I/O 서버는 어플리케이션의 일부로 배포되며, 해당 어플리케이션은 HMI 또는 데이터베이스로 데이터를 전달하는 일을 직접 담당합니다. 경우에 따라 이러한 수준의 개발자 참여로 인해 최종 시스템의 유용성이 감소하고 전체 OPC 서버의 확장성이 향상됩니다. 그러나 소규모 시스템의 경우 OPC 중개인을 제거하고 모든 것을 처리할 수 있는 간단한 단일 애플리케이션을 만드는 것이 좋습니다.
그림 8. Modbus 마스터 I/O 서버를 사용하는 샘플 제어 어플리케이션
Modbus 슬레이브 I/O 서버
I/O 서버 마스터와 마찬가지로 슬레이브 서버도 감독 제어용으로만 사용해야 합니다. I/O 서버는 백그라운드 프로세스이므로 사용자 코드에서는 요청이 수신된 시기를 알 수 없습니다. 따라서 I/O 서버는 PAC와 같은 보다 강력한 하드웨어를 사용하여 중앙 허브에서 간헐적으로 낮은 우선 순위 업데이트로 대부분의 제어를 처리하는 애플리케이션에 가장 적합합니다. 이러한 애플리케이션에서 I/O 서버의 Modbus 데이터는 제어 루프의 모든 반복에서 스캔되어 결정을 내리는 데 사용되지만 해당 데이터는 중요한 통신(예: E-stop)에 사용되지 않습니다.
그림 9. 샘플 Modbus 슬레이브 I/O 서버 애플리케이션
저수준 API를 사용하는 Modbus
많은 저수준 Modbus 드라이버가 여러 언어로 존재합니다. LabVIEW DSC 및 LabVIEW Real-Time 모듈은 NI OPC 서버 및 Modbus I/O 서버의 기능을 보완하기 위해 로우 레벨 Modbus API를 제공합니다.
이러한 드라이버를 사용하면 Modbus 요청을 보내거나 받을 때 발생하는 작업을 명시적으로 정의할 수 있습니다. 또한 일반적으로 더 높은 수준의 드라이버보다 더 높은 최대 성능을 제공합니다. 그 대신 일반적으로 많은 데이터 처리 코드를 작성해야 하므로 응용 프로그램이 시스템의 다른 장치와 효과적으로 상호 작용할 수 있습니다. 이 코드의 기능과 동작은 장치가 마스터인지 슬레이브인지에 따라 달라집니다.
그림 10은 로우 레벨 마스터인 LabVIEW Modbus API가 전송된 특정 요청과 해당 요청의 타이밍을 엄격하게 제어하는 방법을 보여줍니다.
그림 10. 하위 수준 마스터는 읽기 요청의 타이밍과 내용을 제어합니다.
로우 레벨 마스터
마스터로 사용할 경우 로우 레벨 Modbus 드라이버를 사용하는 고성능 PAC를 사용하여 고속과 신뢰성이 필요한 시스템을 효과적으로 제어할 수 있습니다. 요청은 애플리케이션 코드에 의해 직접 생성되기 때문에 모든 오류도 즉시 보고되고 알려지므로 시스템이 안전한 상태로 전환되거나 수정 작업을 수행할 수 있습니다.
또한 응용 프로그램은 데이터가 전송되는 정확한 시기를 엄격하게 제어하므로 응용 프로그램 코드가 네트워크 대역폭을 효과적으로 사용할 수 있습니다. 동일한 속도로 모든 것을 스캔하는 대신 다른 슬레이브 장치에 대해 다른 속도를 사용할 수 있습니다. 필요한 경우 응용 프로그램은 응용 프로그램의 성능 요구 사항을 충족하기 위해 완전히 다른 네트워크 경로(두 개의 TCP 연결, 다른 직렬 회선)를 사용할 수도 있습니다.
그림 11은 개발자가 Windows 기반 SCADA 시스템에서와 유사한 저속 이벤트 기반 감독 루프를 개발하도록 선택한 샘플 애플리케이션을 보여줍니다. 병렬 프로세스에서는 결정론적 제어 루프를 사용하여 펌프와 고속으로 통신합니다.
그림 11. 본 NI CompactRIO PAC 샘플 어플리케이션은 로우 레벨 Modbus 마스터 드라이버를 사용합니다.
또한 이러한 하위 수준 드라이버는 매우 유연하기 때문에 시스템 동작에 매우 중요한 우선 순위에 대한 제어를 유지하면서 I/O 서버와 같은 상위 수준 인터페이스의 일부 기능을 다시 만드는 데 사용할 수 있습니다. 이 샘플 응용 프로그램에서는 응용 프로그램의 특정 요구 사항에 맞는 방식으로 모든 요청 및 응답의 예약을 처리하는 통신 루프가 개발되었습니다. 그런 다음 통신 루프에서 새 데이터를 사용할 수 있는 시기에 대한 지식을 바탕으로 결정론적 제어 루프를 작성할 수 있으므로 통신 오류로 인한 잠재적인 단점 없이 첫 번째 시스템의 많은 이점을 얻을 수 있습니다.
그림 12. 이 사용자 지정 제어 응용 프로그램은 통신을 보조 루프로 이동하여 시스템의 성능 요구 사항을 유지하면서 통신 오류의 영향을 줄입니다.
낮은 수준의 슬레이브
애플리케이션 코드에서 직접 요청-응답 프로토콜의 서버 측을 처리하는 것이 어렵기 때문에 많은 Modbus 슬레이브 구현은 마스터 요청에 대한 응답을 처리하는 백그라운드 프로세스를 제공합니다. 이는 원칙적으로 I/O 서버 슬레이브의 동작과 유사합니다.
그러나 하위 수준 드라이버에서는 애플리케이션 코드가 시스템의 요구 사항에 맞게 이 프로세스의 동작을 조정할 수 있는 것이 일반적이며 예상됩니다. 경우에 따라 하위 수준 슬레이브는 응용 프로그램 코드에서 처리할 수 있는 이벤트를 제공합니다. 이렇게 하면 장치 메모리의 변경 내용을 폴링할 필요 없이 마스터에서 들어오는 데이터에 즉시 응답할 수 있습니다.
그림 13. 이 하위 수준 슬레이브 드라이버는 이벤트를 사용하여 공유 데이터 모델의 데이터 변경 내용을 나타냅니다.
보다 진보된 경우, 애플리케이션 코드가 슬레이브 API의 데이터 모델에 직접 삽입될 수 있는 방식으로 로우 레벨 드라이버가 작성될 수 있습니다. 따라서, 단순히 메모리 위치로부터 판독하는 것보다는, 슬레이브는 어플리케이션 특정 방식으로 마스터 요청에 응답할 수 있다. 이렇게 하면 응용 프로그램 코드에서 서버를 작성할 필요 없이 하위 수준 마스터가 제공하는 많은 이점을 얻을 수 있습니다.
그림 14. 이 하위 수준 슬레이브 응용 프로그램은 사용자 지정 데이터 모델을 사용하여 시스템별 방식으로 결정론적 제어 코드와 직접 상호 작용합니다.
Modbus의 장점과 단점
장점
- 일반적으로 사용되며 많은 구현을 사용할 수 있습니다.
- 유연함
- 자유롭게 사용할 수 있는 사양
- 요청-응답 아키텍처는 응용 프로그램 수준 승인을 제공
단점
- 요청-응답이 네트워크를 충분히 활용하지 못하거나 애플리케이션 코드를 복잡하게 만듭니다.
- 높은 네트워크 오버헤드
- 제한된 패킷 크기는 오버헤드를 증가시키고 최대 폴링 속도를 감소시킵니다.
- 데이터 스트리밍이 어렵거나 불가능합니다.
- 부호 없는 16비트 정수 및 단일 비트 이외의 네이티브 형식 지원 없음
- 기본 제공 보안 기능 없음
- 폴링 아키텍처 필요
'데이터계측분석 > 데이터통신 기술자료' 카테고리의 다른 글
| 시리얼통신의 동기식/비동기식 프로토콜 (0) | 2023.05.11 |
|---|---|
| 시리얼 통신 기본 - RS-232 / RS-422 / RS-485 (0) | 2023.05.10 |
| 모드버스(Modbus) 프로토콜 (0) | 2023.05.05 |
| OPC UA(Unified Architecture) (0) | 2023.05.05 |
| 시리얼 통신의 루프백 테스트 (0) | 2023.04.18 |