Tag Archives: DeviceNet

DeviceNet 기초지식

DeviceNet이란 무엇인가 ?

DeviceNet이란 저 코스트의 통신링크이다. 산업용 기기(리밋 스위치, 광전센서, 밸브 매니폴드, 모터 스타터, 프로세스 센서, 바코드 리더, 인버터, 패널 디스플레이, 오퍼레이터 인터페이스 등)를 네트워크에 접속하면 비용이 드는 하드배선이 필요 없게 된다. 직접 접속되므로 하드 배선된 I/O 인터페이스에서는 용이하게 액세스하거나 이용이 불가능했던 디바이스 레벨의 중요한 진단만이 아니고 디바이스간의 통신도 개선할 수 있다.
DeviceNet는 간단한 네트워크 솔루션이다. 산업용 오토메이션 기기의 배선과 설치에 드는 비용과 시간을 절약하고 복수 벤더의 동종의 구성요소에 상호호환성을 제공한다.
DeviceNet는 오픈된 네트워크 규격이다. 사양과 프로토콜이 공개되어 있으면 벤더는 디바이스를 시스템에 접속하기 위하여 하드웨어, 소프트웨어를 구입하거나 저작권 사용료를 지불하거나 할 필요가 없다. 누구라도 Open DeviceNet Vendor Association, Inc.(ODVA)를 통해 약간의 비용으로 DeviceNet 사양서를 구입할 수 있다. DeviceNet 제품을 제조하고 있는(또는 제조하려고 하는) 기업은 ODVA에 가입하여 DeviceNet 사양의 기능강화를 행하고 있는 기술워킹그룹에 참가할 수가 있다.
DeviceNet 사양서 구입자에게는 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의 상업적 수요이다. 1994년에는 CAN 칩 메이커 4개사(Intel, Motorola, Philips, Siemens)로서 400만개 이상의 CAN 칩을 출하했고, 1996년에는 1천만개 이상의 출하가 예상되고 있다. 타 산업용 오토메이션 네트워크가 1년간 연간수요가 2만∼20만개의 전용을 사용하고 있는 것에 비하여 Device 제품에서는 자동차와 그 외의 소비자·상용 애플리케이션으로서 사용되고 있는 것과 같은 CAN 칩을 사용하고 있다. DeviceNet에 사용되고 있는 CAN 칩의 수는 대략 다른 네트워크의 1/5∼1/10이다.

표1. DeviceNet의 특징

네트워크 사이즈
최대 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 애플리케이션층은 전송한 데이터의 해석과 의미를 정의하고 있다.

CDeviceNet 사양서란?

DeviceNet 프로토콜

ISO 애플리케이션층 (제7층)

CAN 프로토콜

ISO 데이터링크층(제2층)

물리층

ISO 물리층(제1층)

전송 미디어

ISO 미디어층(제0층)

통신 프로토콜의 특징

– 어떤 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장에서는 가능한 토폴로지와 구성요소를 정의하고 있다. 생각되는 토폴로지의 종류를 그림2에 나타냈다. 사양서에는 시스템의 접지방법 굵은 케이블과 가는 케이블의 조합, 종단처리, 전원 공급에 관하여도 언급하고 있다. 기본적인 간선, 지선 토폴로지는 신호와 전원공급용으로 별도의 트위스트 페어 버스를 제공한다. 굵은 케이블 또는 가는 케이블은 어느 쪽이라도 간선, 지선으로 사용할 수 있다. 종단간 네트워크 거리는 데이터 속도와 케이블의 굵기에 따라 변한다(표1 참조).
디바이스는 직접 버스에서 전원을 공급하고 같은 케이블을 사용하여 서로 통신할 수 있다. 네트워크의 전원을 떨어뜨리지 않고 네트워크에서 전원을 떼어내거나 취부할 수 있다.
전원 탭은 네트워크 내의 어느 부분에도 추가할 수 있고 복수의 전원 공급이 가능하다. 간선의 정격전류는 8A이다. 포토 아이솔레이션된 설계를 선택하면 외부전원을 사용하는 기기(AC 드라이브 스타터 및 솔레노이드 밸브 등)가 같은 버스 케이블을 사용할 수 있다. 다른 CAN 베이스의 네트워크에서는 네트워크 전체에서 단 하나(만약 있다면)의 전원만 인식한다.
비절연형 및 절연형 물리층을 갖는 트랜시버의 간이 블록도를 그림 2에 나타냈다. DeviceNet 사양서에서는 부품의 요건, 오배선의 보호, 예 등의 추가정보가 설명되어 있다. 끝에서 끝까지의 네트워크 거리는 데이터 레이트와 케이블 굵기에 따라 변한다.
DeviceNet에서는 여러 가지 컨넥터 타입을 사용할 수 있다(그림 3참조). 실드형 비실드형 커넥터의 어느 것이라도 사용할 수 있다. 실드형 컨넥터를 필요로 하지 않는 제품의 경우 오픈형 커넥터를 사용할 수 있다. 플러그 접속 커넥터가 필요하지 않은 경우는 스크루 커넥터 또는 클램프 커넥터를 케이블에 직접 접속할 수가 있다. DeviceNet 사양서에는 싱글탭과 멀티포트탭을 구성할 때의 케이블과 커넥터 부품의 사용방법을 설명하고 있다.

그림1. 비절연형 물리층(좌) 절연형 물리층(우)

표3. 데이터 전송속도와 길이 데이터 레이트

데이터 레이트

125Kbps

250Kbps

500Kbps

Thick 간선 길이

500m

250m

100m

Thin 간선 길이

100m

100m

100m

최대지선 길이

6m

6m

6m

누계지선 길이

156m

78m

39m

그림 2. 다양한 커넥터 타입

인디케이터

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

CAN과 DeviceNet

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

CAN이 규정하는 프레임 타입

– 데이터 프레임
– 리모트 프레임
– 오버로드 프레임
– 에러 프레임
데이터는 데이터 프레임을 사용하여 DeviceNet상에서 전송된다. 다른 프레임을 DeviceNet상에서는 사용되지 않지만 예외처리로 사용된다. 데이터 프레임 포맷을 그림 4에 나타냈다.

그림 3. CAN DATA Frame

우선순위가 높은 데이터가 우선권을 얻는다

버스가 정지하고 있는 경우 어느 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 커넥션을 리퀘스트할 뿐이다.

표3. DeviceNet의 4종류의 메시지 그룹 10비트

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

오브젝트 모델

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

그림4. DeviceNet 오브젝트 모델

표4. 4개의 어드레스를 지정하는 요소의 범위 어드레스

어드레스

최소치

최대치

노드

0

63

클래스

1

65535

인스턴스

0

65535

어트리뷰트

1

255

표5. 오브젝트 클래스 오브젝트 클래스 번호

오브젝트 클래스 번호

오브젝트 클래스명

사양서 참조 부분

1

Identity

Vol. VolⅡ, Rel. 2.0, 페이지6-3

2

Message Router

Vol. VolⅡ, Rel. 2.0, 페이지6-17

3

DeviceNet

Vol. VolⅡ, Rel. 2.0, 페이지5-50

4

Assembly

Vol. VolⅡ, Rel. 2.0, 페이지6-23

5

Connection

Vol. VolⅡ, Rel. 2.0, 페이지5-5

6

Parameter

Vol. VolⅡ, Rel. 2.0, 페이지6-86

Identity 오브젝트 VolⅡ, Rel 2.0, 6-3 페이지

통상 DeviceNet 제품은 Identity 오브젝트 중에 인스턴스를 하나(인스턴스#1) 가지고 있다. 이 인스턴스는 벤더 ID, 디바이스 타입, 제품 코드, 리비전, 스테이터스, 시리얼 넘버, 제품명, 상태라고 하는 어트리뷰트를 가지고 있다. 필요로 하는 서비스는 Get_Attribute_Single 및 Reset이다.

Message Router 오브젝트 VolⅡ, Rel 2.0 6-17 페이지

통상, DeviceNet 제품은 Message Router 오브젝트 중에서 인스턴스를 하나(인스턴스#1) 가지고 있다. Message Router 오브젝트는 Explicit 메시지를 다른 오브젝트에 전달하는 제품의 구성요소이다. Message Router 오브젝트에는 통상 DeviceNet 네트워크 상에 나타날 수 있는 비헤이비어는 없다.

DeviceNet 오브젝트 VolⅠ, Rel 2.0, 5-50 페이지

통상 DeviceNet 제품은 DeviceNet 오브젝트중에 인스턴스를 하나(인스턴스#1) 가지고 있다. 이 인스턴스에는 다음과 같은 어트리뷰트가 있다. 노드 어드레스 또는 MAC ID, 전송속도, Bus-off 액션, Bus-off 카운터, Allocation Choice 및 마스터의 MAC ID 이다.
필수의 서비스는 Get_Attribute_Single만이다.

Assembly 오브젝트 VolⅡ, Rel 2.0, 6-23 페이지

통상 DeviceNet 제품은 옵션으로 하나 이상의 Assembly 오브젝트를 가지고 있다. 이 오브젝트의 주된 목적은 다른 애플리케이션의 다른 어트리뷰트(데이터)를 하나의 어트리뷰트로 그룹화하여 하나의 메시지로서 전송할 수 있도록 하는 것이다.

Connection 오브젝트 VolⅠ, Rel 2.0, 5-5 페이지

통상 DeviceNet 제품은 적오도 2개의 커넥션 오브젝트를 가지고 있다. 각 커넥션 오브젝트는 DeviceNet 네트워크상의 2개의 노드간의 실제의 커넥션 엔드포인트를 나타내고 있다. 이 두 종류의 커넥션을 Explicit Messaging 커넥션 및 I/O Messaging 커넥션이라고 부른다. Explicit 메시지는 어트리뷰트 어드레스 지정, 어트리뷰트 값 및 지정된 액션을 기술하는 서비스 코드를 포함한다. I/O 메시지에는 데이터만 포함된다. I/O 메시지의 경우 데이터의 취급에 관한 모든 정보는 그 I/O 메시지에 관련되는 커넥션 오브젝트에 포함된다.

Parameter 오브젝트 VolⅡ, Rel 2.0 6-86 페이지

옵션인 Parameter 오브젝트는 설정가능한 파라미터를 가진 기기로서 사용된다. 하나의 인스턴스가 하나의 설정 파라미터를 나타냅니다. Parameter 오브젝트는 컨피규레이션 툴이 모든 파라미터를 액세스하기 위하여 표준 방법을 제공하고 있다. Parameter 오브젝트의 어트리뷰트인 구성 옵션에는 값, 범위, 문자열 및 제한값이 포함된다.

Application 오브젝트

통상 Assembly 또는 Parameter 클래스의 오브젝트를 제외하고 적어도 하나의 오브젝트가 기기에 존재한다. VolⅡ의 제6장의 DeviceNet 오브젝트 라이브러리에 표준 오브젝트가 다수 기재되어 있다.

메시징

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)로 처리할 수 있다.
I/O 메시지의 일반적인 포맷을 그림 5에 나타냅니다.

그림 5. I/O 메시지 포맷(상)과 Explicit 메시지 포맷 (하)

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 커넥션을 실현할 수 있다. VolumeⅠ의 제7장에 Predefined Master/Slave Connection Set에 관한 상세한 정보가 기재되어
있다.

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 페이지)로 ?

페이지 1 의 212