[특별기획] 자동화 산업용 네트워크의 종류와 이해Ⅳ

폐쇄형 네트워크에서 개방형 네트워크로 ‘DeviceNet’

월간 모션컨트롤은 자동화 산업용 네트워크의 다양한 종류와 각각의 특성을 파악해 독자들의 이해를 돕기 위한 특집을 구성 중에 있다. 이에 가장 먼저 이더켓(EtherCAT)의 특장점 및 적용사례를 소개한 바 있으며, 4월호에서는 두 번째 순서로 ‘ETHERNET Powerink’를, 그리고 지난 달 세 번째 순서로 아시아의 대표적인 필드버스로 급부상한 ‘CC-Link’를 소개했다. 이어서 이번 6월호에서는 네 번째 순서로 세계 표준을 목표로 하여 보다 쾌적하게, 그리고 보다 경제적으로 제어 기기의 상호 접속이 가능하도록 한 필드버스인 ‘DeviceNet’을 소개한다.

지난 호에서 강조한 바와 같이 국내의 심각한 노동력 부족과 급격한 임금 상승에 맞서 기업의 생산성 향상과 생산 품질의 경쟁력을 회복하는데 하나의 필수적인 해결 방안으로 인식되고 있으며, 산업용 네트워크는 최소한의 인력으로 공장의 가동 및 유지, 보수가 가능 하게끔 하고 있다. 따라서 기업들은 각자의 특성에 걸 맞는 산업용 네트워크를 채택해 사용하기 위한 노력이 지속되고 있는 가운데, 이번 순서에서는 ‘DeviceNet’을 소개해본다.

이번 회를 통해 DeviceNet의 네트워크 구성과 네트워크상을 흐르는 메시지에 대하여 설명하고, 이것을 통하여 DeviceNet란 무엇인가, DeviceNet에 의해 무엇이 가능한가를 이해시킬까 한다. 또한 DeviceNet 제품을 개발하는 사람에 따라서는 개발하는 하드웨어 및 소프트웨어의 전체적인 형상을 대략 파악할 수 있게 될 것이다. 그 외에도 DeviceNet 제품 유저에 따라서는 DeviceNet 시스템을 구축·보수 관리하는 것 외에도 유용한 기초지식을 얻을 수가 있을 것으로 보인다.

‘DeviceNet’이란?

DeviceNet는, PLC, PC(PC), 센서, 액츄에이터 등의 제어 기기간의 상호 접속이 용이하게할 수 있도록 하는 필드 버스이다. DeviceNet의 선택은 성 배선에 의해 배선 비용의 절감과 멀티벤더 기기의 접속에 의해 쾌적하고 보다 경제적인 시스템 구축을 실현할 수 있도록 한다. 또한 DeviceNet은 개방적인 필드 버스 중에서 가장 성공한 제품이며, 폭넓은 용도에 사용되고 있다.

[DeviceNet의 이점]

●신뢰성

- 배선수의 감소로 배선에 의한 오류방지, 용이한 보수, 서비스
- 디바이스에 자체의 Diagnostic 기능, Real Time성, Open & Global

●성능

- 최신 제어 기술을 도입, 고속응답, 단순성, 사용의 편의성
- Deterministic, 제어기기, 상호접속용이성, 호환성, 교환성 보유

●비용

- 배선작업의 감소, 배선수 감소, COST Down 구현
- 모쥴방식의 개발 : 개발 시간 단축, Test 및 인증비용 저렴

즉, DeviceNet이란 저 코스트의 통신링크이다. 산업용 기기(리밋 스위치, 광전센서, 밸브 매니폴드, 모터 스타터, 프로세스 센서, 바코드 리더, 인버터, 패널 디스플레이, 오퍼레이터 인터페이스 등)를 네트워크에 접속하면 비용이 드는 하드배선이 필요 없게 된다. 직접 접속되므로 하드 배선된 I/O 인터페이스에서는 용이하게 액세스하거나 이용이 불가능했던 디바이스 레벨의 중요한 진단만이 아니고 디바이스간의 통신도 개선할 수 있다.

DeviceNet은 간단한 네트워크 솔루션이다. 산업용 오토메이션 기기의 배선과 설치에 드는 비용과 시간을 절약하고 복수 벤더의 동종의 구성요소에 상호호환성을 제공한다. DeviceNet은 오픈된 네트워크 규격이다. 사양과 프로토콜이 공개되어 있으면 벤더는 디바이스를 시스템에 접속하기 위하여 하드웨어, 소프트웨어를 구입하거나 저작권 사용료를 지불하거나 할 필요가 없다. 누구라도 Open DeviceNet Vendor Association, Inc.(ODVA)를 통해 약간의 비용으로 DeviceNet 사양서를 구입할 수 있다. DeviceNet 제품을 제조하고 있는(또는 제조하려고 하는) 기업은 ODVA에 가입하여 DeviceNet 사양의 기능강화를 행하고 있는 기술워킹그룹에 참가할 수가 있으며, DeviceNet 사양서 구입자에게는 DeviceNet 제품을 개발하기 위한 무제한 또는 무료의 라이센스가 교부된다. 서포트가 필요한 기업은 실장을 용이하게 하는 샘플 코드, 개발용 툴, 다수의 소스로부터의 개발 서비스 등을 구입할 수가 있다. 중요한 하드웨어 부품은 세계적 규모의 큰 반도체 메이커에서 입수할 수 있다.

DeviceNet의 특징

다양한 제조업체의 디바이스들 사이에 상호처리가 가능한 개방 통신 표준 DeviceNet은 여러 제조업체들의 비슷한 컴포넌트들 간의 상호 처리를 가능하게 해 준다. 신속하고 편리한 설치 및 공간과 시간의 절감으로 DeviceNet은 배선과 그에 따른 노동력 및 공간이 필요 없다. 뿐만 아니라, 필요에 따라 손쉽게 확장할 수 있는 미래지향성 DeviceNet은 네트워크를 편하게 확장할 수 있는 강력한 기능을 제공하기도 한다. 각 디바이스들의 작동상황을 모니터함으로써 가동시간의 향상, 및 네트워크에서 일어나는 일을 즉시 알려주어 신속한 대응 또한 가능토록 하고 있다.

생산자/소비자(Producer/Consumer) 통신을 통한 효과적인 대역폭 활용 및 가용 대역폭을 효과적으로 이용함으로써 중요한 메세지를 언제나 주고받을 수도 있으며, 전원을 차단하지 않고도 설치와 추가가 가능하여 디바이스를 추가할 때에도 기기를 정지시킬 필요가 없다. DeviceNet의 커뮤니케이션 링크의 경우, 수십 년 동안 프로세스 산업은 모든 종류의 현장 장치를 어드레스 할 수 있는 단일 및 개방형 표준을 만들고자 노력해왔다. 본래의 표준화 목표는 기존의 4~20mA를 단일 디지털 표준으로 대체하는 것이었다. 그러나 그 목표의 범위가 증가하여 복잡한 고도의 서비스, 즉 제어기간의 고속 데이터 전송 및 고속 스캔을 요구하며, 수많은 장치들이 120/220VAC, 24VDC 개별배선에 의한 I/O 의 호환이 가능한 제품이 요구되고 있는 현실에서 DeviceNet을 사용하면 이러한 모든 것이 일거에 해결될 수 있다.

왜 DeviceNet 통신링크인가?

오랜 기간에 걸쳐서 프로세스 업계는 여러 가지 종류의 필드기기를 대상으로 하는 단 하나의 오픈된 규격을 작성하려고 노력해 왔다. 당초의 규격 적용 범위는 4∼20mA 규격을 하나의 디지털 규격으로 치환하는 것에 초점을 맞추어 왔다. 그 적용 범위가 복잡하고 고도의 서비스(컨트롤러 간의 고속 데이터 통신, 초고속 스캔을 행하는 많은 수의 기기의 동기 등)에 까지 확대해 나가기 위한 통일 규격의 개발이 지연되었다. 동시에 통신기술에 걸리는 코스트는 요즈음 대폭으로 내려가서 SP50 필드버스에서는 생각지도 않은 간단한 디바이스를 직접 네트워크에 접속하는 것도 코스트 효율이 좋게 되었다. 이와 같은 간단한 디바이스의 규격에는 120/220V AC와 24V DC의 하드 배선용 디스크리트 I/O와 같은 레벨의 상호 호환성을 필요로 한다.

DeviceNet은 보다 복잡한 디바이스의 상호접속성을 실현하면서 간단한 디바이스의 상호 호환성도 제공한다. 디스크리트 디바이스의 상태의 독취와 더불어 DeviceNet은 온도를 보고하기도 하고 모터 스타터의 부하 전류를 계측하기도 하고 드라이브의 감속률을 변경하기도 하고 1시간에 컨베이어를 통과한 패키지 수를 계산하기도 하는 기능을 제공한다.

Controller Area Network(CAN)는 저코스트 제품의 열쇠

DeviceNet 통신 링크는 브로드캐스트 지향의 통신 프로토콜인 Controller Area Network(CAN)을 베이스로 하고 있다. CAN 프로토콜은 자동차의 고가의 와이어 하네스를 저가의 네트워크 케이블로 치환하기 위해 BOSCH가 유럽의 자동차 시장을 목표로 하여 개발한 것이다. 그렇기 때문에 CAN에서의 프로토콜은 ABS와 에어백의 제어를 필요로 하는 것과 같은 애플리케이션에서의 빠른 응답성과 높은 신뢰성을 갖추고 있다. 칩은 높은 온도 정격과 내노이즈성, 산업용 오토메이션 시장에도 충분히 적합한 기능을 갖춘 여러 가지 패키지로 구입할 수 있다.

그러나 가격을 내리고 CAN 칩의 성능을 높이는 원동력은 소비자와 CAN의 상업적 수요이다. 타 산업용 오토메이션 네트워크가 1년간 연간수요가 2만∼20만개의 전용을 사용하고 있는 것에 비하여 Device 제품에서는 자동차와 그 외의 소비자·상용 애플리케이션으로서 사용되고 있는 것과 같은 CAN 칩을 사용하고 있다. DeviceNet에 사용되고 있는 CAN 칩의 수는 대략 다른 네트워크의 1/5∼1/10이다.

네트워크 사이즈 최대 64 노드
네트워크 길이 끝에서 끝의 네트워크 길이는
속도에 따라 다르다.

전송속도 거리
125Kbps 500m
250Kbps 250m
500Kbps 100m

데이터 패킷 0 〜 8 byte
버스 토폴로지 리니어(간선/지선) 동일 네트워크상에 Power 및 신호
버스 어드레싱멀티캐스트(1:N)의
피어·투·피어 멀티캐스트 및 마스터/슬레이브의
특수형
시스템의 특징 통전 상태에서 네트워크로부터의
디바이스의 분리 및 교환

CDeviceNet 사양서란?

DeviceNet 사양서는 산업용 제어 시스템의 요소 간에서 데이터를 전송하기 위한 네트워크 통신시스템을 정의하고 있다. 사양서는 2권으로 나누어져 있으며 다음의 각 요소를 정의하고 있다.

VolumeⅠ

DeviceNet 통신 프로토콜과 애플리케이션(제7층-애플리케이션층)
CAN과 DeviceNet에 있어서의 그 이용(제2층-데이터링크층)
DeviceNet 물리층과 미디어(제1층-물리층)

VolumeⅡ

동종제품 간에서 상호운용성과 상호교환성을 얻기 위한 디바이스 프로파일 DeviceNet은 CAN(Controller Area Network)을 사용하고 있다. CAN은 데이터 전송의 구문과 형식을 정의한다. DeviceNet 애플리케이션층은 전송한 데이터의 해석과 의미를 정의하고 있다.

통신 프로토콜의 특징

어떤 DeviceNet 제품에서도 메시지의 송수신이 가능한 피어 투 피어 데이터 교환을 특징으로 하며, 피어 투 피어의 최적 서브세트로서 정의되는 마스터/슬레이브 조작도 특징 중 하나다. DeviceNet 네트워크는 최대 64개의 Media Access Control Idetifier(MAC ID) 노드 어드레스를 가질 수가 있다. 각 노드는 무수한 I/O를 서포트 할 수 있다. 공기압 밸브 액추에이터용의 일반적인 I/O 점수는 16 또는 32점이다.

오브젝트 모델

DeviceNet의 노드는 오브젝트의 집합체로서 모델화되어 있다. 오브젝트는 제품내부의 특정한 구성요소를 추상적으로 표현한 것이다. 제품의 이 추상적인 오브젝트 모델의 실현은 실장방법에 따라 다르다. 오브젝트 인스턴스와 오브젝트 클래스는 어트리뷰트(데이터)를 가지며 서비스(메소드 또는 프로시저)를 제공하고 비헤이비어를 실행한다. 어트리뷰트(1∼255), 인스턴스(0∼6535) 및 노드 어드레스(0∼63)는 각각의 번호로서 어드레스를 지정한다.

DeviceNet 물리층과 미디어

DeviceNet 사양서의 VolumeⅠ, 제9장에서는 가능한 토폴로지와 구성요소를 정의하고 있다. 사양서는 시스템의 접지방법 굵은 케이블과 가는 케이블의 조합, 종단처리, 전원 공급에 관하여도 언급하고 있다. 기본적인 간선, 지선 토폴로지는 신호와 전원공급용으로 별도의 트위스트 페어 버스를 제공한다. 굵은 케이블 또는 가는 케이블은 어느 쪽이라도 간선, 지선으로 사용할 수 있다. 종단 간 네트워크 거리는 데이터 속도와 케이블의 굵기에 따라 변한다(사진 3 참조).

디바이스는 직접 버스에서 전원을 공급하고 같은 케이블을 사용하여 서로 통신할 수 있다. 네트워크의 전원을 떨어뜨리지 않고 네트워크에서 전원을 떼어내거나 취부 할 수 있다. 전원 탭은 네트워크 내의 어느 부분에도 추가할 수 있고 복수의 전원 공급이 가능하다. 간선의 정격전류는 8A이다. 포토 아이솔레이션된 설계를 선택하면 외부전원을 사용하는 기기(AC 드라이브 스타터 및 솔레노이드 밸브 등)가 같은 버스 케이블을 사용할 수 있다. 다른 CAN 베이스의 네트워크에서는 네트워크 전체에서 단 하나(만약 있다면)의 전원만 인식한다.

비절연형 및 절연형 물리층을 갖는 트랜시버의 간이 블록도를 아래 그림과 같이 나타냈다.

DeviceNet 사양서는 부품의 요건, 오배선의 보호, 예 등의 추가정보가 설명되어 있다. 끝에서 끝까지의 네트워크 거리는 데이터 레이트와 케이블 굵기에 따라 변한다. DeviceNet에서는 여러 가지 컨넥터 타입을 사용할 수 있다. 실드형 비실드형 커넥터의 어느 것이라도 사용할 수 있다. 실드형 컨넥터를 필요로 하지 않는 제품의 경우 오픈형 커넥터를 사용할 수 있다.

플러그 접속 커넥터가 필요하지 않은 경우는 스크루 커넥터 또는 클램프 커넥터를 케이블에 직접 접속할 수가 있다. DeviceNet 사양서에는 싱글탭과 멀티포트탭을 구성할 때의 케이블과 커넥터 부품의 사용방법을 설명하고 있다.

사진 5. 데이터 전송속도와 길이

인디케이터

DeviceNet에서는 제품이 인디케이터를 구비하고 있을 필요는 없지만 제품이 인디케이터를 장비하고 있는 경우 DeviceNet의 사양에 준거할 필요가 있다. 모듈 스테이터스 LED와 네트워크 스테이터스 LED 또는 모듈 스테이터스/네트워크 스테이터스 LED의 어느 쪽인가를 갖추고 있을 것을 권장한다. 인디케이터는 2색 발광(녹/적) LED로 하고 점등, 소등, 점멸을 조합하여 사용한다. 모듈 스테이터스 LED는 디바이스에 전원이 투입되어 있는가 디바이스가 정상으로 동작하고 있는가를 나타냅니다. 네트워크 스테이터스 LED는 통신링크의 스테이터스를 나타낸다.

CAN과 DeviceNet

DeviceNet의 데이터 링크층은 CAN 사양과 CAN 컨트롤러 칩의 실장에 따라 완전히 정의되어 있다. CAN 사양은 도미넌트(로직 0)와 리세시브(로직 1)의 두 종류의 버스 상태를 정의하고 있다. 어떤 트랜스미터에서도 버스를 도미넌트 상태로 할 수가 있다. 어떤 트랜스미터도 도미넌트 상태가 아닌 때에만 리세시브 상태로 된다.

CAN이 규정하는 프레임 타입

- 데이터 프레임
- 리모트 프레임
- 오버로드 프레임
- 에러 프레임

데이터는 데이터 프레임을 사용하여 DeviceNet상에서 전송된다. 다른 프레임을 DeviceNet상에서는 사용되지 않지만 예외처리로 사용된다. 데이터 프레임 포맷을 <사진 7>에 나타냈다.
우선순위가 높은 데이터가 우선권을 얻는다 버스가 정지하고 있는 경우 어느 DeviceNet 노드도 송신을 시도할 수가 있다는 점에서 DeviceNet은 Ethernet와 유사하다. 이에 따라 고유의 피어·투·피어 기능이 제공된다. 2개 이상의 노드가 동시에 네트워크를 액세스하려고 할 경우 비트 단위 비파괴 아비트레이션(중재) 메커니즘에 의해 데이터와 대역폭을 손상하지 않고 일어날 가능성이 있는 충돌을 피할 수 있다.

이에 대하여 Ethernet에서는 충돌검출기를 사용하고 있으며 양 노드가 데이터의 전송중지와 재전송을 하지 않으면 안되므로 데이터와 대역폭의 손실이 발생된다. CAN은 독자의 비파괴적인 비트 단위의 아비트레이션 메커니즘 사용한다. 이와 같은 CAN 고유의 특징에 의해 Throughput(출력)를 저하시키지 않고 또한 우선순위가 높은 쪽의 노드가 재송신을 행하지도 않고 충돌을 회피(승자를 결정)할 수가 있다. CAN은 충돌을 회피하기 위하여 비트 단위 아비트레이션 메소드를 사용한다. CAN 네트워크상의 리시버는 모두 Start of Frame 비트가 나타내는 리세시브에서 도미넌트로의 천이에 동기화된다. ID와 RTR 비트를 어떤 목적에도 사용하고 있지 않으므로 버스 액세스의 우선순위를 고려할 필요가 없다. 디바이스는 송신하는 것과 동시에 송신한 것이 같은가 같지 않은가를 확인하기 위하여 감시(수시)를 행한다. 이것에 의해 동시 송신을 검출할 수가 있다.

아비트레이션 필드의 송신 중에 리세시브 비트를 송신하고 있는 노드가 도미넌트 비트를 수신하면 송신을 중지한다. 동시에 송신하고 있는 2개의 노드가운데 11비트 ID가 낮은 쪽이 아비트레이션의 승자로 된다. CAN에서는, DeviceNet에서 서포트하지 않는 29비트 ID 필등서의 데이터 프레임 포맷을 지정한다. 컨트롤러 필드에서는 2개의 고정 비트와 1개의 4비트 길이 필드가 있다. 이 길이는 0∼8의 사이의 수로서 데이터 필드의 바이트 수를 나타낸다. 0∼8바이트라고 하는 사이즈는 빈번히 교환할 필요가 있는 I/O 데이터의 량이 적은 로우-엔드한 디바이스에는 최적이다. 또한 8비트의 경우 간단한 디바이스가 유연하게 대응할 수 있음으로 해서 진단 데이터나 속도지령과 가속도를 드라이브에 보낼 수가 있다.

CRC 필드는 Cyclic Redundancy Check(순회용장검사)의 체크워드로서 CAN 컨트롤러가 프레임 에러를 검출하는데 사용된다. 그보다 전에 온 비트를 본래의 것으로 하여 계산한다. ACK 슬롯에 도미넌트 비트가 있으면 송신측 외에도 적어도 하나의 수신측이 수신됐다는 것을 나타낸다. CAN은 CRC나 자동 리트라이 등의 몇 가지 방법으로 에러의 검출과 폴트의 분리를 실현하고 있다. 이들의 방법은 애플리케이션에서는 하나도 보이지 않고 장해 노드가 네트워크의 장해로 되는 것을 방지한다.

DeviceNet용 CAN 부품의 개요

대부분의 슬레이브는 Intel 82527 또는 Motorola 68HC705X4를 사용하고 있다. 대부분의 마스터/피어가 Philips 82C200을 사용하고 있다.

통신 컨트롤과 애플리케이션

DeviceNet 사양서 VolumeⅠ 제3, 4, 5장에서 DeviceNet 통신프로토콜을 정의하고 있다. 이들 장에서는 각각 컨넥션, 메세징 프로토콜, Communication 오브젝트에 대하여 기술하고 있다. DeviceNet을 사용하는 애플리케이션은 표준 또는 애플리케이션 고유의 오브젝트를 디바이스 프로파일이라고 부르는 것에 편입시킨다. 디바이스 프로파일은 네트워크에서 보았을 때의 기기를 완전히 정의하고 있다. 브젝트 라이브러리는 DeviceNet 사양서 VolumeⅡ의 제6장에서 설명하고 있다. 디바이스 프로파일의 라이브러리는 DeviceNet 사양서 VolumeⅡ의 제3장에서 설명하고 있다. ODVA는 오브젝트와 디바이스 프로파일의 새로운 사양의 작성에 관련되는 업계 전문가의 업무 조정을 행하고 있다. 이것은 분과회(SIG)를 통하여 행해진다.

또한 DeviceNet은 Strobe, Poll, Cyclic, Change-of-State 및 애플리케이션에 의한 데이터 전송을 서포트하고 있다. 유저는 마스터/슬레이브, 멀티 마스터 및 피어·투·피어 중에서 선택하거나 디바이스의 기능과 애플리케이션의 필요 요건에 따라 조합하여 구성할 수 있다. 데이터 전송을 선택하는 것으로서 시스템의 리스폰스 타임이 대폭적으로 단축된다. 잘 알려진 어떤 DeviceNet용 애플리케이션은 커넥션의 표준 Predefined Set를 사용한다. 이것에 의해 디바이스를 Master/Slave Connection Set로서 동작시킬 수 있다.

커넥션

DeviceNet 통신프로토콜은 커넥션이라고 하는 개념을 베이스로 하고 있다. 다른 기기와 정보교환을 하기 위해서는 기기와의 커넥션을 확립할 필요가 있다. 커넥션을 확립하기 위하여 각 DeviceNet 제품은 Unconnected Message Manager(UCMM)이나 Unconnected Port의 어느 쪽인가를 실장한다. 어느 것이라도 사용가능한 CAN ID를 예약하는 것에 의해 기능을 실행한다. UCMM에 대해서는 DeviceNet 사양서 VolumeⅠ제4장에, Unconnected Port에 대하여는 VolumeⅠ, 제7장에 상세하게 기재되어 있다.

UCMM이나 Unconnected Port를 사용하여 Explicit Messaging 커넥션을 확립하면 그 커넥션은 어떤 노드에서 다른 노드로 정보를 전송하거나 또는 I/O 커넥션을 확립하기 위해 사용된다. 일단 커넥션이 확립되면 I/O 데이터를 네트워크상의 기기 간에서 전송할 수 있도록 된다. 이 시점에서 DeviceNet의 모든 프로토콜은 11비트의 CAN ID에 포함된다. 그 이외의 것은 데이터이다.

11비트의 CAN ID는 커넥션 ID를 정의하기 위해 사용된다. DeviceNet에서는 11비트의 CAN ID를 4개의 그룹으로 나뉜다. 최초 3개의 정의 그룹에는 6비트의 MAC ID용 필드와 메시지 ID용 필드의 2개의 필드가 있다. 이 두 개를 조합시킨 필드가 커넥션 ID를 정의한다. 그림 6에 메시지 그룹의 정의를 나타낸다. 그룹4 메시지는 오프라인 통신용이다. 기기는 클라이언트, 서버, 또는 그 양쪽으로 될 수가 있다. 클라이언트와 서버는 송신측, 수신측, 또는 그 양쪽이 될 수가 있다. 일반적인 클라이언트 기기의 경우 커넥션은 리퀘스트를 송신하고 리스폰스를 수신한다. DeviceNet는 이 모델에 대하여 여러 가지 패턴을 제공하고 있다. 클라이언트에서도 서버에서도 메시지를 수신하는 것 만이라고 하는 커넥션도 있다. 이와 같은 커넥션은 Cyclic 또는 Change_of_State 메시지의 수신측이다. Cyclic 또는 Change_of_State의 송신측이다. Cyclic 커넥션이나 Change_of_State 커넥션을 사용하면 대역폭의 제한을 대폭 감소시킬 수 있다.

설계상 DeviceNet 시스템의 노드는 자신의 ID 처리의 책임이 있다. 이들의 ID는 전체범위에 균등하게 분배되어 있다. 모든 노드는 MAC ID 값에 관계없이 사용가능한 전범위의 메시지 우선순위를 가지고 있다. 중복 MAC ID 알고리즘을 사용하면 각 네트워크용의 집중관리 툴이나 레코드를 필요로 하지 않고 CAN ID의 일관성을 보증할 수 있다.

이것과 관련하여 중복노드 검출의 문제가 있다. DeviceNet은 CAN ID 필드내의 디바이스 어드레스를 사용하기 위하여 중복 어드레스를 가진 디바이스를 검출하는 메커니즘을 가지고 있다. 중복된 어드레스를 피하는 것은 중복이 일어난 후에 어드레스가 중복된 노드를 지정하는 것보다 효율적이다. 이것은 다른 CAN 베이스 네트워크에서는 고려되지 않는다. 노드가 자신의 ID를 처리하는 또 하나의 이점은 유저에게 기존의 셋업에 대한 지식이 없어도 언제라도 노드의 추가, 삭제/ 또는 기존 노드 간 피어·투·피어 메시지의 추가를 행할 수 있다는 것이다. 집중 레코드를 설치하거나 재구축하거나 할 필요는 없다. 노드는 어떤 ID가 이미 사용되고 있는지를 알고 있으므로 툴은 우선순위 레벨과 데이터의 경로(클래스, 인스턴스, 어트리뷰트), 송신 트리거(Cycilc, Poll, 또는 Change_of_State)를 지정하여 두 개의 디바이스 간에 추가할 I/O 커넥션을 리퀘스트 할 뿐이다.

10비트 16진수 범위 ID의 사용방법

10 9 8 7 6 5 4 3 2 1 0
0 Group1메시지 ID 송신측 MAC ID 000-3ff 메시지
Group1
1 0 10MAC ID Group2

메시지 ID 400-5ff 메시지
Group2
1 1 Group3

메시지 ID 송신측 MAC ID 600-7bf 메시지
Group3
1 1 1 1 1 Group4
메시지 ID(0〜2f) 7c0-7ef 메시지

Group4
1 1 1 1 1 1 1 1 X X X 7f0-7ff 무효인
CAN ID
10 9 8 7 6 5 4 3 2 1 0

사진 8. DeviceNet의 4종류의 메시지 그룹

오브젝트 모델

오브젝트 모델은 어트리뷰트(데이터), 서비스(메소드 또는 프로시져), 및 DeviceNet 제품의 구성요소의 비헤이비어를 구성, 실장하기위한 템플레이트이다. 이 모델은 4개의 숫자로 되는 각 어트리뷰트의 어드레스 지정 기구를 나타내고 있다. 4개의 숫자는 노드 어드레스(MAC ID), 오브젝트 클래스 ID, 인스턴스 번호, 어트리뷰트 번호이다. 이 4레벨의 어드레스는 Explicit Messaging 커넥션과 함께 DeviceNet 네트워크상에서 데이터를 다른 장소로 전송시키기 위해 사용된다. 4개의 어드레스를 지정하는 요소의 범위를 아래와 같이 나타냈다.

메시징

DeviceNet 애플리케이션층에서는 ID의 할당(우선순위의 결정) 방법을 정의하거나 서비스의 지정, 데이터의 전송, 그 의미의 결정을 행하기 위한 CAN 데이터 필드의 사용방법을 정의한다. 통신 네트워크에서는 정보의 전달방법이 가장 중요하다. 지금까지의 통신기술은 특정한 송신측과 수신측을 갖는 메시지에 의해 구성되어 있다. DeviceNet에서는 종래의 송신-수신 어프로치가 아니라 패킷에 데이터의 ID 필드를 갖는 효율 좋은 Producer-Consumer Model을 사용하고 있다. 이 ID에 의해 복수의 우선순위 레벨(아비트레이션에서 사용된다)이나 I/O 데이터의 효율적인 전송, 복수의 수신측을 실현할 수 있다.

데이터를 갖는 기기는 적정한 ID를 사용하여 네트워크 상 데이터를 송신한다. 데이터를 필요로 하는 모든 기기가 메시지를 입수하려고 대기상태로 된다. 기기는 적절한 ID를 인식하면 데이터를 수신한다. Producer-Consumer-Model 에서는 메시지는 이미 특정의 송신측 또는 수신측에 고유한 것이 아니다. 좁은 대역폭을 사용하여 1대의 컨트롤러로부터 단 하나의 메시지를 복수의 모터 스타터가 사용될 수 있다.

DeviceNet는 I/O 메시지와 Explicit 메시지라고 불리는 2종류의 메시징을 정의하고 있다. I/O 메시지는 시간중시, 제어지향의 데이터용이다. 이 메시지에 의해 하나의 송신측 애플리케이션과 하나이상의 수신측 애플리케이션 간에 전용, 특정 목적의 통신경로가 제공된다. 메시지는 싱글 또는 멀티캐스트 커넥션에서 교환되고 우선순위가 높은 ID를 사용하는 것이 일반적이다.

I/O 메시지는 8바이트의 데이터 필드에 프로토콜을 포함하지 않는다. 유일한 예외는 분할 송신된 I/O 메시지에서 여기서는 1바이트가 분할 송신 프로토콜로 사용된다. 메시지의 의미는 커넥션 ID(CAN ID)에 의해 정의된다. 메시지가 이 ID로 송신되기 전에 송수신을 행하는 기기는 양쪽 모두 구성이 완료되어 있을 필요가 있다. 이 구성에는 Producer 및 Consumer를 위한 데이터의 소스·오브젝트 어트리뷰트 어드레스 및 데스티네이션·오브젝트 어트리뷰트·어드레스의 지정이 포함되어 있다.

Explicit 메시지는 2개의 기기간에 다목적의 포인트·투·포인트 통신경로를 제공한다. 이 메시지에 의해 노드구성이나 문제진단을 실시하기 위해 사용되는 전형적인 리퀘스트/리스폰스 지향의 네트워크 통신이 제공된다. Explicit 메시지는 우선순위가 낮은 ID를 사용하는 것이 일반적이고 데이터 필드 중에 메시지의 특정의미를 포함하고 있다. 데이터 필드에는 실행되는 서비스나 특정의 오브젝트 어트리뷰트 어드레스 등이 포함되어 있다.

분할송신 서비스는 8바이트를 넘는 메시지에 대하여 제공된다. I/O 메시지의 각 프래그멘트에는 1바이트의 오버헤드 프로토콜이 포함된다. 프래그멘트의 수에 제한은 없다. 분할송신은 Explicit 메시지에 대하여도 정의된다. 이와 같은 기능이 들어 있을 때에 그와 같은 기기를 기존의 DeviceNet 네트워크에 추가할 수 있게 되어 있다. DeviceNet가 갖고 있는 오브젝트 지향 설계와 어드레스 지정의 방법을 사용하면 DeviceNet는 기본적인 프로토콜이나 커넥션 모델을 변경하지 않고 확장할 수가 있다. 한편, 2개의 메시지 커넥션(I/O와 Explicit)를 갖는 간단한 슬레이브 기기 애플리케이션을 4K 바이트 이하의 ROM과 175 바이트의 RAM(빌트인 CAN 인터페이스를 갖는 CPU, Motorola 65HC05XA)로 처리할 수 있다.

Predefined Master/Slave Connection Set

DeviceNet은 디바이스간의 커넥션을 다이내믹하게 구성할 수 있는 강력한 애플리케이션층 프로토콜을 제공하고 있지만 몇몇의 기기에서는 이 강력한 기능을 사용할 필요도 없고, 리소스도 갖고 있지 않다는 것도 알고 있다. 이 때문에 Predefined Master/Slave Connection Set라고 불리는 커넥션 ID 세트가 I/O 데이터와 마스터/슬레이브 아키텍처서 통상 발견되는 구성형 데이터의 전송을 간략화하기 위해 지정된다.

많은 센서와 액추에이터에서는 사전에 정해져 있는 기능을 실행하도록 설계되어 있고(압력검지, 모터의 스타트 등), 기기가 송수신하는 데이터의 타입과 량이 전원투입 시에 통보된다. 통상 이들 기기는 입력한 데이터를 제공 하던가 출력할 데이터와 구성 데이터를 요구한다. Predefined Master/Slave Connection Set는 기기 전원 투입 시에 커넥션 오브젝트를 전부 구성해버림으로써 이와 같은 요구에 대응한다. 데이터 전송을 개시하기 위해서는 마스터 디바이스가 슬레이브 내의 Predefined Connection Set의 소유권을 요구하면 된다.

Group2 메시지는 이들 ID의 정의(앞에서 기술한 그림 6을 참조)에 사용된다. 이들로부터 수신측 ID를 사용할 수가 있다. 버스 상에서 CAN ID가 중복되는 것을 방지하기 위하여 이와 같은 커넥션의 사용에 관해서는 엄밀한 규칙이 존재한다. 수신측 ID를 사용하면 중심으로 되어 있는 많은 노드와 통신하지 않으면 안 되는 기기(마스터)는 수신측 노드에서 ID를 차용하는 것으로 된다. 또한 MAC ID가 CAN ID의 상위 8비트 내에 격납된다. 이것이 중요한 것은 저렴한 8비트의 CAN 칩 중 많은 수가 8비트만을 하드웨어 필터링할 수가 있기 때문이다. 수신측 MAC ID를 배타적으로 사용하면 기기는 하드웨어 필터링을 추가로 이용할 수가 있다. 또 하나 중요한 이점은 Predefined Set로부터의 커넥션의 확립이 대폭적으로 간략화된다는 점이다. I/O 커넥션을 기동하여 메시지 커넥션을 포함하며 Bit Strobed의 커맨드/리스폰스, Poll의 커맨드/리스폰스, Change_of_State, Cyclic 등 여러 가지 I/O 커넥션을 실현할 수 있다.

PChange_of_State와 Cyclic 송신

Change_of-State를 사용하면 데이터가 변화한 때에만 기기가 데이터를 송신한다. 송신측 기기가 정상으로 동작하고 있다는 것은 수신측 기기가 확실히 알도록 DeviceNet는 조정 가능한 백그라운드의 Heartbeat Rate를 제공하고 있다는 것이다. 데이터가 변화 하던가 Heartbeat 타이머가 타임 아웃 할 때마다 기기가 데이터를 송신한다. 이것에 의해 커넥션은 유지되고 수신측에서는 데이터 소스에 아무 이상도 없다는 것을 알 수 있다.

Heartbeat의 최소시간이 빈번히 데이터를 송신하는 노드에 의해 네트워크의 점유를 막아준다. 기기가 Heartbeat를 생성함으로서 확인만을 위해서 컨트롤러가 정기적으로 성가신 리퀘스트를 송신할 필요가 없게 된다. 이 방법은 멀티캐스트의 경우 더욱 효과가 올라간다. Cyclic 옵션을 사용하면 불필요한 트래픽과 패킷 처리를 감소시킬 수 있다. 온도나 아날로그 입력 블록을 매초 수십 회 스캐닝하는 것은 아니고 검출 가능한 변화율에 맞추어서 정기적으로 데이터를 보고하도록 설정할 수 있다. 갱신타임이 500ms의 저속 PID 루프에서 온도센서로 Cyclic 속도를 500ms로 설정할 수도 있다. 이와 같이 속도가 변화하는 중용한 I/O 데이터용에 대역폭이 보존되는 것만이 아니고 정도도 향상된다.

예를 들면 부하가 큰 마스터에서 노드당의 데이터 바이트 수가 아주 방대한 스캐닝 리스트의 일부로서 30ms마다 스캐닝을 실행했다고 할 경우, 여기서 알 수 있는 것은 PID 계산에서 사용되는 데이터가 470에서 500ms 사이에서 샘플링될 것이라는 것 뿐이다. Cyclic 송신이라면 데이터의 샘플링은 엄밀히 500ms이라는 것을 알 수 있다.
디폴트에서는 Change_of_State 및 Cyclic과도 상호 응답하므로(ACK 있음), 송신측은 목적한 수신측이 데이터를 수신했다는 것을 인식할 수 있다. Change_of_State 또는 Cyclic 속도가 매우 고속인 애플리케이션의 경우에도 ACK 패킷으로 네트워크에 혼란을 초래하지는 않습니다. 불필요한 ACK는 Acknowledge Handler 오브젝트(VolumeⅡ, 제6장, Rel 2.0, 6-228∼6-238 페이지)로 억제할 수가 있다.

현재로는 단순한 슬레이브 노드이더라도 Cyclic 또는 Change_of_State의 어느 쪽이라도 최적의 간격으로 보고하도록 설정할 수 있다. Acknowledge Handler 오브젝트를 사용하면 마스터만이 아니라 슬레이브 데이터의 복수의 수신측을 소유할 수가 있다. 이 멀티캐스트는 표시, 경보 모니터, 데이터 로깅의 어느 목적으로든 필요한 데이터를 수신만 하는 오퍼레이터 인터페이스(01) 디바이스에는 특히 유용하다.

경보 모니터에 있어서 Change_of_State를 빠뜨리지 않는 것이 중요하며 따라서 01 디바이스를 디바이스의 ACK 리스트에 추가하여 어떤 이유로 01이 메시지를 수신하지 못한 경우에도 한번 더(또는 수회) 리트라이를 행하도록 한다. 한편 5초마다 값을 로깅하는 데이터 수집 디바이스의(따라서 노드가 제어목적으로 300ms마다 값을 송신한다) 경우 로거를 ACK로 설정할 필요가 없다. 로거가 값을 놓쳐도 300ms 후에 다음의 값을 수신할 수 있기 때문이다. 마스터로부터의 Cyclic 및 Change_of_State는 노드마다 정의되어 선택된다.

디바이스 프로파일

DeviceNet 사양서는 물리 커넥션의 프로토콜 사양에 국한되는 것만은 아니다. 표준 디바이스 모델을 정의함으로서 상호 운용성을 높이고 있다. 같은 모델의 기기는 모두 공통된 ID와 통신 스테이터스 데이터를 서포트하고 있어야 한다. 기기 고유의 데이터는 여러 가지 기기 타입마다 정의되는 디바이스 프로파일에 포함되어 있다. 복수 벤더의 간단한 기기(푸시버튼, 모터 스타터, 광센서, 공기압 밸브 액추에이터 등)는 각 디바이스 타입의 프로파일에 준거하면 상호 호환성이 있다. 디바이스 프로파일은 아래의 섹션으로 구성되어 있다.

통상 기기 내의 모든 오브젝트 클래스의 인스턴스 번호, 각 오브젝트의 비헤이비어 및 각 오브젝트에 대한 공개 인터페이스의 표가 있다. 기기의 I/O 데이터 포맷의 정의 - 이것은 통상 요구되는 데이터 요소의 어드레스(클래스, 인스턴스, 어트리뷰트)를 포함하는 Assembly 오브젝트의 정의를 포함한다. 기기의 설정 가능한 파라미터 및 그 파라미터에 대한 공개 인터페이스의 정의 - 이 정보는 기기의 유저 도큐먼트의 EDS에 포함되어 있다.

예를 들면 광센서(디바이스 타입6)는 아래의 오브젝트를 포함한다.

- ID Object 1
- Message Router 1
- DeviceNet 1
- Connection 2(Explicit 1, I/O 1)
- Assembly 1
- Parameter 1(오브젝트)
- Presence Sensing 1

DeviceNet 사양에서는 EDS를 정의하고 있다. 이것은 간단한 파일 포맷으로서 이 포맷을 사용하면 제품 고유의 정보를 다른 벤더가 이용할 수 있게 된다. 이와 같이 하면 컨피규레이션 소프트웨어 툴을 계속 변경하지 않고 간단히 업데이트 가능한 User Friendly Configuration Tool이 가능하게 된다. 개정에 제한을 두지 않기 위하여 벤더 고유로 부가가치가 있는 옵션을 추가하기 위한 수단도 제공하고 있다. DeviceNet 사양에는 DeviceNet 사양에 있어서 정의되는 공개 클래스, 서비스, 어트리뷰트와 각 벤더가 추가할 수 있는 벤더 고유의 클래스, 서비스, 어트리뷰트가 있다. 이로서 벤더는, 사양에는 포함되어 있지 않은 추가기능을 고객에게 제공할 수 있다.

자료제공 | ODVA KOREA(www.odva.or.kr)

주요기사