introduction
DeviceNet은 원래 미국 회사 Allen-Bradley (현재 Rockwell Automation) 에 의해 개발되었습니다.
그 후, 전 세계적으로 DeviceNet의 사용을 촉진하기 위해 ODVA (Open DeviceNet Vendor Association)라는 독립 기관이 창설되어 DeviceNet의 규격을 관리, 발전, 적합성 시험 등을 담당하고 있습니다. DeviceNet은 산업용 컨트롤러 및 I/O 장치들 간의 Digital Multi-Drop 네트워크로서. 각 디바이스 / 제어기는 네트워크상의 Node가 됩니다.
또한, DeviceNet은 Producer - Consumer 네트워크로서 Multiple Communication Hierarchy와 메세지 우선순위 기능 및 Master-Slave /Peer-to-Peer통신 구조가 모두 가능합니다. 그리고, DeviceNet의 독특한 기능은 네트워크상에 Power를 공급한다는 점입니다.
이 기능을 통해, 적정량 이하의 Power는 네트워크에서 직접 공급 받을 수 있는 장점이 있습니다. DeviceNet은 ISO 표준의 OSI 계층모델을 준수하며, 각 계층별 기능은 다음과 같습니다.
그 후, 전 세계적으로 DeviceNet의 사용을 촉진하기 위해 ODVA (Open DeviceNet Vendor Association)라는 독립 기관이 창설되어 DeviceNet의 규격을 관리, 발전, 적합성 시험 등을 담당하고 있습니다. DeviceNet은 산업용 컨트롤러 및 I/O 장치들 간의 Digital Multi-Drop 네트워크로서. 각 디바이스 / 제어기는 네트워크상의 Node가 됩니다.
또한, DeviceNet은 Producer - Consumer 네트워크로서 Multiple Communication Hierarchy와 메세지 우선순위 기능 및 Master-Slave /Peer-to-Peer통신 구조가 모두 가능합니다. 그리고, DeviceNet의 독특한 기능은 네트워크상에 Power를 공급한다는 점입니다.
이 기능을 통해, 적정량 이하의 Power는 네트워크에서 직접 공급 받을 수 있는 장점이 있습니다. DeviceNet은 ISO 표준의 OSI 계층모델을 준수하며, 각 계층별 기능은 다음과 같습니다.
Protocol Architecture
Data Link Layer
DeviceNet의 데이터 링크 층은 CAN 사양 및 CAN 컨트롤러 칩의 실장에 의해 정의됩니다. CAN 사양은 두 버스 상태를 Dominant (논리 0)와
Recessive (논리 1) 상태로 정의하고 있으며, 어떤 Transmitter도 Bus를 Dominant 상태로 Drive할 수 있습니다. 즉, 모든 Transmitter가 송신하지 않을
때에만, 버스는 Recessive 상태가 됩니다. 이것을 (CAN에서 채용한) Bus arbitration scheme 이라고 합니다. CAN은 다음처럼 여러 프레임을
지원하고 있습니다만, DeviceNet은 이중에서 Data 프레임을 이용하여 Data를 전송하며, 나머지 프레임은 예외처리를 위해 사용됩니다.
- Data 프레임 - Remote 프레임 - Overload 프레임 - Error 프레임
CAN은 Carrier sense network로서, Node는 다른 Node 들이 전송하지 않을 때에만 전송을 시도 할 수 있습니다. 이 기능을 통해 완전한 Peer-to-Peer기능을 제공하게 되며, 따라서 둘 이상의 CAN Node가 네트워크를 액세스 할 때 발생하는 잠재적 충돌을 a Non-destructive, Bit-wise Arbitration Mechanism에 의해 아무런 Data의 손실 없이도 해결할 수 있습니다. ( 자세한 CAN의 특징은 다른 기술자료를 참고하시기 바랍니다.)
- Data 프레임 - Remote 프레임 - Overload 프레임 - Error 프레임
CAN은 Carrier sense network로서, Node는 다른 Node 들이 전송하지 않을 때에만 전송을 시도 할 수 있습니다. 이 기능을 통해 완전한 Peer-to-Peer기능을 제공하게 되며, 따라서 둘 이상의 CAN Node가 네트워크를 액세스 할 때 발생하는 잠재적 충돌을 a Non-destructive, Bit-wise Arbitration Mechanism에 의해 아무런 Data의 손실 없이도 해결할 수 있습니다. ( 자세한 CAN의 특징은 다른 기술자료를 참고하시기 바랍니다.)
Network & Transport Layer
DeviceNet에서는 어떤 Device와 정보를 교환하기 위해서는 먼저 그 Device와의 Connection이 확립 해야 되기 때문에 각 DeviceNet 제품들은
Unconnected Message Manager (UCMM) 혹은 Group 2 Unconnected Port 기능을 지원해야 합니다.
이 기능을 사용하여 Explicit Messaging Connection 을 확립하게 되면, 이 Explicit Connection은 Node간에 정보를 이동하거나, I/O Connection을 확립하는데 사용됩니다. 일단 I/O Connection이 확립되면, Device간에 Data가 교환 될 수 있습니다. 여기서, 이 Connection의 ID를 정의 하는데 11-bit CAN Identifier 가 사용되는데 Connection ID의 유일성은 Producer-Consumer 기능을 충분히 발휘하기 위해 엄격하게 관리됩니다. DeviceNet은 11 Bit CAN Identifier를 네 그룹으로 나눕니다. 처음 3 개의 그룹은 두 개의 필드를 ( 6 비트의 MAC ID, 나머지 메시지 ID ) 조합하는데 바로 이 조합 된 필드가 Connection ID가 됩니다.(아래 그림 참조)
이 기능을 사용하여 Explicit Messaging Connection 을 확립하게 되면, 이 Explicit Connection은 Node간에 정보를 이동하거나, I/O Connection을 확립하는데 사용됩니다. 일단 I/O Connection이 확립되면, Device간에 Data가 교환 될 수 있습니다. 여기서, 이 Connection의 ID를 정의 하는데 11-bit CAN Identifier 가 사용되는데 Connection ID의 유일성은 Producer-Consumer 기능을 충분히 발휘하기 위해 엄격하게 관리됩니다. DeviceNet은 11 Bit CAN Identifier를 네 그룹으로 나눕니다. 처음 3 개의 그룹은 두 개의 필드를 ( 6 비트의 MAC ID, 나머지 메시지 ID ) 조합하는데 바로 이 조합 된 필드가 Connection ID가 됩니다.(아래 그림 참조)
The Upper Layers: the Common Industrial Protocol (CIP)
DeviceNet은 Upper 레이어로 Common Industrial Protocol (CIP) 을 사용합니다. CIP는 철저한 Object oriented 특성을 지니고 있습니다.
각 Object는 Attributes (data), Services (commands), Behavior (reaction to events) 를 가지고 있습니다. CIP 사양에는 두 가지의 다른 Type의 Object (즉, Communication Object / Application-specific Object)가 정의 되어 있습니다. Vendor-specific Object도 정의 될 수 있는데. 이는 CIP 사양에 존재하지 않는 제품을 정의할 때 사용됩니다. 모든 Device상에는 최소한의 Common Object가 실장 되는데, 이를 통하여 Device간에 그 Device의 제조사에 관계없이 호환성이 가능하게 됩니다. CIP 기반 네트워크는 공통의 Application 계층을 기반으로 하고 있기 때문에, 애플리케이션 Data는 네트워크 Type에 관계없이 동일하게 유지됩니다. 따라서, 응용 프로그래머는 Device가 어떤 네트워크에 연결 되어 있는지 알 필요가 없습니다. CIP는 Device Profile도 정의 하고 있습니다. 이 Device Profile은 Minimum Object Set, Configuration option, I/O data format 을 정의합니다. 표준 Profile 중에 한 Type을 따르는 Device는 동일한 Profile을 가진 다른 Device와 동일한 I/O Data와 동일한 Configuration option을 가지며, 동일한 명령에 반응하며, 동일한 행동을 하게 됩니다. CIP와 DeviceNet 에서 Device Profile의 Subset가 아래쪽 표에 나와 있습니다. DeviceNet은 Vendor 자신의 제품에 Minimum Object Set외에도 Vendor 고유의 특성을 추가하도록 하는 표준 메커니즘을 가지고 있습니다. 그러나 이러한 추가 기능은 DeviceNet 규격에 규정 된 방식을 엄격히 준수하여 구현되야 합니다.
각 Object는 Attributes (data), Services (commands), Behavior (reaction to events) 를 가지고 있습니다. CIP 사양에는 두 가지의 다른 Type의 Object (즉, Communication Object / Application-specific Object)가 정의 되어 있습니다. Vendor-specific Object도 정의 될 수 있는데. 이는 CIP 사양에 존재하지 않는 제품을 정의할 때 사용됩니다. 모든 Device상에는 최소한의 Common Object가 실장 되는데, 이를 통하여 Device간에 그 Device의 제조사에 관계없이 호환성이 가능하게 됩니다. CIP 기반 네트워크는 공통의 Application 계층을 기반으로 하고 있기 때문에, 애플리케이션 Data는 네트워크 Type에 관계없이 동일하게 유지됩니다. 따라서, 응용 프로그래머는 Device가 어떤 네트워크에 연결 되어 있는지 알 필요가 없습니다. CIP는 Device Profile도 정의 하고 있습니다. 이 Device Profile은 Minimum Object Set, Configuration option, I/O data format 을 정의합니다. 표준 Profile 중에 한 Type을 따르는 Device는 동일한 Profile을 가진 다른 Device와 동일한 I/O Data와 동일한 Configuration option을 가지며, 동일한 명령에 반응하며, 동일한 행동을 하게 됩니다. CIP와 DeviceNet 에서 Device Profile의 Subset가 아래쪽 표에 나와 있습니다. DeviceNet은 Vendor 자신의 제품에 Minimum Object Set외에도 Vendor 고유의 특성을 추가하도록 하는 표준 메커니즘을 가지고 있습니다. 그러나 이러한 추가 기능은 DeviceNet 규격에 규정 된 방식을 엄격히 준수하여 구현되야 합니다.
The Predefined Master/Slave Connection Set
근본적으로 DeviceNet은 Peer-to-Peer Messaging model 을 채용합니다만, Master/Slave 관계를 기반으로 한 단순화 된 통신 방식도 제공하고 있습니다. 이 사전 정의 된 연결 방식이 Predefined Master/Slave Connection Set. 으로 알려져 있습니다.
이러한 Connection 방법은 I/O 메세지의 교환을 간소화시키게 됩니다. 다수의 센서 및 액츄에이터는 통상적으로 Power-up 시에 그 Device가 Produce/Consume하는 Data의 유형과 양을 알 수 있는 Predefined function (Connection object)을 제공하도록 설계되어 있습니다. 따라서, 네트워크에 전원을 공급 한 후, 마스터가 Slave안에 있는 이 Predefined Connection Set에 대한 Ownership을 요구하면 Data 교환이 즉시 가능하게 되고, Slave Device는 자신이 Configure된 결과와 Application의 요구에 따라, 오른쪽 표에 나타난 메세지 Type중 몇 개를 사용하여 Data를 Produce하게 됩니다.
