CANopen
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
CANopen은 유럽 표준 EN 50325-4로 지정된 통신 프로토콜로, CAN 버스를 기반으로 한다. CANopen 장치는 통신 유닛, 유한 상태 기계, 객체 사전, 응용 프로그램으로 구성되며, 객체 사전은 장치 구성 및 통신에 사용되는 변수들의 집합이다. CANopen은 NMT, SDO, PDO, SYNC, TIME 등의 통신 객체를 지원하며, 마스터/슬레이브, 클라이언트/서버, 생산자/소비자 모델을 사용하여 메시지를 교환한다. EDS는 장치의 통신 동작과 객체 사전 항목을 설명하는 파일 형식이며, 이를 기반으로 장치 구성 파일(DCF)을 생성하여 CANopen 네트워크에 통합할 수 있다.
더 읽어볼만한 페이지
- 통신 표준 - CAN 버스
CAN 버스는 1983년 로버트 보쉬 유한회사에서 개발된 차량 내 통신 네트워크 프로토콜로, 자동차, 농업 장비 등 다양한 분야에서 전자 제어 장치 간의 통신을 가능하게 한다. - 통신 표준 - 8b/10b 인코딩
8b/10b 인코딩은 8비트 데이터를 10비트 데이터로 변환하여 클럭 정보 내장, 직류 성분 균형 유지, 런 길이 제한 등의 특징을 가지며 기가비트 이더넷, 파이버 채널, USB 3.0, HDMI 등 다양한 통신 기술에 널리 사용되는 부호화 방식이다. - 컴퓨터 네트워킹 - 유니캐스트
유니캐스트는 데이터를 단일 목적지로 전송하는 방식으로, 브로드캐스트 및 멀티캐스트와 대비되며, 개인적 또는 고유한 리소스가 필요한 네트워크 프로세스에 사용되지만, 대량 데이터 전송 시 비용이 증가하는 단점이 있다. - 컴퓨터 네트워킹 - 노드 (네트워크)
노드(네트워크)는 데이터 통신에서 데이터를 주고받는 장치를 의미하며, 물리적 네트워크 노드, 인터넷 노드, 통신 네트워크 노드, 분산 시스템 노드, 네트워크 가상화 노드 등으로 분류된다. - 네트워크 프로토콜 - UUCP
UUCP는 유닉스 시스템 간 파일 복사, 원격 명령 실행, 이메일 및 유즈넷 뉴스 전송을 위한 프로토콜 및 프로그램 모음으로, 초기 인터넷 확장에 중요한 역할을 했으나 TCP/IP 기반 서비스 보편화로 사용이 감소했다. - 네트워크 프로토콜 - 프레임 릴레이
프레임 릴레이는 LAN 간 또는 WAN 종단점 간 데이터 전송을 위한 고속 패킷 교환 방식 통신 프로토콜로, X.25 프로토콜을 간소화하여 속도를 높이고, 영구 가상 회선을 통해 안정적인 연결을 제공하며, 서비스 품질 설정을 통해 프레임 우선순위를 지정할 수 있었으나, 현재는 다른 기술에 밀려 사용이 감소하고 있다.
| CANopen |
|---|
2. 역사
CANopen은 2004년 12월, 독일의 비영리 단체 CAN in Automation(CiA)이 통신 프로파일 DS-301 (v4.02)을 처음 릴리스하면서 시작되었다. 이후 CiA는 모터, 원격 I/O 등 다양한 장치(디바이스)에 대한 표준 사양 (약 20개)을 추가로 제정하였다.
2. 1. 국제 표준
CANopen은 유럽 표준 EN 50325-4로 지정되어 있다. CAN 자체는 국제 표준 ISO 11898, ISO 15765, ISO 11519 등으로 규정되어 있다.3. 장치 모델
CANopen 장치는 제어 소프트웨어를 구현할 때 다음과 같은 표준 속성을 포함해야 한다.
- '''통신 유닛'''은 네트워크 상의 다른 노드들과 메시지를 교환하기 위한 프로토콜들을 구현한다.
- 장치를 시작하거나 재시작할 때 유한 상태 기계에 의해 현재의 상태를 관리한다. CANopen 장치는 Initialization, Pre-operational, Operational, Stopped 상태를 구현해야 한다. 네트워크 관리(NMT) 메시지를 장치에 전송하여 이러한 상태를 변경할 수 있다.
- '''객체 사전'''은 장치가 지원하는 변수들의 집합이다. 각 변수는 16비트 인덱스 번호와 8비트 서브인덱스 번호로 참조할 수 있다. 변수는 장치의 설정을 읽거나 변경하고, 센서 값을 읽는 데 사용된다.
- 장치를 operational 상태로 설정하면, 장치의 응용계층에서 미리 설정된 객체 사전 변수들을 주기적 또는 특정 이벤트에 의해 전송할 수 있다.
CANopen 노드는 정보를 수신하고 이용하는 컨슈머와 정보를 관리하고 발신하는 프로듀서로 구성된다.
3. 1. 객체 사전 (Object Dictionary)
CANopen 장치는 제어 소프트웨어를 구현할 때 객체 사전(Object Dictionary)을 포함해야 한다. 객체 사전은 장치가 지원하는 변수들의 집합이며, 16비트 인덱스 번호와 8비트 서브인덱스 번호로 각 변수를 참조할 수 있다. 이러한 변수들은 장치의 설정을 읽거나 변경하고, 센서의 값을 읽는 데 사용된다.객체 사전의 각 변수는 다음과 같이 정의된다.
- '''인덱스''': 변수 참조를 위한 16비트 주소
- '''Object name''' (Object 타입/크기): 단순 변수, 배열 등
- '''Name''': 변수 이름
- '''Type''': 변수의 자료형
- '''Attribute''': 읽기 전용, 쓰기 전용, 읽기/쓰기 가능 여부
- '''Mandatory/Optional''' (M/O): 필수 정의 변수(M) 또는 선택적 정의 변수(O)
기본 장치 프로파일 CiA 301에는 인덱스 범위 0x1000-0x1FFF까지의 영역을 장치 통신 파라미터로 사용한다. 다음은 그 예시이다.
| 인덱스 | Object name | Name | Type | Attribute | M/O |
|---|---|---|---|---|---|
| 0x1000 | VAR | device type | UNSIGNED32 | ro | M |
| 0x1001 | VAR | error register | UNSIGNED8 | ro | M |
| 0x1008 | VAR | manufacturer device name | Vis-String | const | O |
부울, 정수, 부동 소수점과 같은 객체 사전 값에 대한 기본 자료형은 표준에서 정의된다. 문자열, 배열 및 레코드와 같은 복합 데이터 유형도 정의되어 있으며, 8비트 인덱스로 하위 인덱싱될 수 있다. 배열 또는 레코드의 하위 인덱스 0의 값은 데이터 구조의 요소 수를 나타내며 UNSIGNED8 유형이다.
전자 데이터 시트(EDS)를 기반으로 장치의 객체 사전 내용을 특정 CANopen 네트워크에 장치를 통합하기 위해 장치 구성 파일(DCF)로 사용자 지정할 수 있다. CiA 306에 따르면 EDS 파일의 형식은 INI 파일 형식이며, CiA 311에는 XML 스타일 형식이 설명되어 있다.
4. 통신
CANopen은 임베디드 시스템에서 간편하게 멀티 마스터 네트워크를 구축할 수 있게 해주는 공개된 상위 소프트웨어 사양이다.
2004년 12월, 독일의 비영리 단체인 :de:CAN in Automation에서 CANopen 통신 프로파일 DS-301(버전 v4.02)을 처음으로 발표했다. 이후 모터, 원격 I/O 등 약 20개의 장치 표준 사양이 제정되었으며, 신칸센과 CERN의 실험 시설 등 다양한 곳에서 활용되고 있다.
CANopen의 통신 속도는 1Mbps이며, 하드웨어에서 재전송 처리를 지원하여 노이즈가 많은 환경에서도 안정적인 통신이 가능하다. 하나의 네트워크에는 최대 127개의 노드를 연결할 수 있으며, 필요에 따라 확장 가능하다.
CANopen 통신은 PDO와 SDO로 구성되며, NMT를 통해 장치를 시작(boot-up)하고 관리한다. CANopen 노드는 정보를 수신하고 이용하는 컨슈머(consumer)와 정보를 관리하고 발신하는 프로듀서(producer)로 구성된다.
CANopen은 칩 제조사에 따른 차이를 흡수하기 위해 통신 프로파일 DS-301을 정의한다. NEC 일렉트로닉스, 르네사스, 후지쯔 등 약 50개의 칩 제조사에서 제공하는 CAN 내장 마이크로컨트롤러 및 CAN 컨트롤러의 차이를 흡수한다.
CAN in Automation에 따르면, DS-3xx (DS 300번대)는 공통 프로파일로 정의되며, 통신 프로파일 DS-301 외에도 커넥터 및 와이어를 정의한 프로파일도 제공된다.
CANopen 마스터는 CANopen 슬레이브 노드의 상태를 하트비트(heartbeat) 또는 가딩(guarding)을 통해 확인하고 제어한다.
긴급 메시지는 장치 내부의 치명적인 오류 발생 시 다른 장치로 높은 우선순위로 전송되는 인터럽트 유형의 오류 알림이다. 이 메시지는 '오류 이벤트'당 한 번만 전송되며, 새로운 오류가 발생하기 전까지는 반복되지 않는다. CANopen 통신 프로파일에 정의된 긴급 오류 코드를 통해 오류 레지스터 및 장치별 추가 정보가 장치 프로파일에 지정된다.
4. 1. 통신 객체 (Communication Objects)
CANopen의 데이터 계층인 CAN 버스는 11비트 아이디, 원격 전송 요청(RTR) 비트, 0에서 8바이트 길이의 가변 데이터로 구성된 짧은 메시지를 전송할 수 있다. CANopen 표준은 11비트 CAN 프레임 아이디를 4비트의 기능 코드와 7비트의 CANopen 노드 아이디로 나누어 사용한다. 따라서 CANopen 네트워크에서 최대로 지원 가능한 노드 수는 127개이다 (아이디 0은 브로드캐스트 용도로 사용).CAN 버스 표준의 확장인 CAN 2.0B에서는 29비트의 확장 프레임 아이디를 제공하지만, 실제로 이 확장 버전을 필요로 하는 CANopen 네트워크는 매우 드물다. CANopen에서 11비트의 CAN 프레임 아이디를 통신 객체 식별자(Communication Object Identifier, COB-ID)라고 부른다.
CANopen 프레임의 구성은 다음과 같다.
| CAN-ID | RTR | 데이터 길이 | 데이터 | |
|---|---|---|---|---|
| 길이 | 11 비트 | 1 비트 | 4 비트 | 0-8 바이트 |
CAN-ID는 다음과 같이 구성된다.
| 기능 코드 | 노드 ID | |
|---|---|---|
| 길이 | 4 비트 | 7 비트 |
전송 중 충돌이 발생했을 경우, CAN 버스에서는 낮은 아이디를 갖는 프레임이 버스 중재(arbitration)에 의해 네트워크를 이용할 수 있는 우선권을 가진다. 그러므로 더 낮은 4비트 기능 코드를 갖는 프레임이 우선적으로 전송된다.
다음은 CANopen에 정의된 기능 코드들이다.
| 기능 | 기능 코드 |
|---|---|
| NMT 노드 제어 | 0000b |
| SYNC | 0001b |
| Emergency | 0001b |
| Timestamp | 0010b |
| PDO | 0011b~1010b |
| SDO | 1011b~1100b |
| NMT 노드 모니터링, LSS | 1110b |
모든 CANopen 장치는 제어 소프트웨어에 특정 표준 기능을 구현해야 한다.
- '''통신 유닛'''은 네트워크의 다른 노드와 메시징을 위한 프로토콜을 구현한다.
- 장치의 시작 및 재설정은 상태 머신을 통해 제어된다. 초기화, 사전 작동, 작동 및 중지 상태를 포함해야 한다. 상태 간의 전환은 장치에 네트워크 관리(NMT) 통신 객체를 발행하여 이루어진다.
- '''객체 사전'''은 16비트 인덱스가 있는 변수 배열이다. 또한 각 변수는 8비트 하위 인덱스를 가질 수 있다. 변수는 장치를 구성하고 환경을 반영하는 데 사용할 수 있다. 즉, 측정 데이터를 포함한다.
- 장치의 '''응용 프로그램''' 부분은 상태 머신이 작동 상태로 설정된 후 실제로 장치의 원하는 기능을 수행한다. 응용 프로그램은 객체 사전의 변수로 구성되며 데이터는 통신 계층을 통해 송수신된다.
4. 1. 1. 미리 정의된 COB-IDs
CANopen은 간단한 네트워크 구조를 위해 메시지 식별자(COB-ID)의 미리 정의된 할당을 지원한다. 다음은 CANopen에서 지원하는 메시지 식별자들이다.[1]| 통신 객체 | COB-ID (16진수) | 슬레이브 노드 | 사양 |
|---|---|---|---|
| NMT 노드 제어 | 000 | 수신 전용 | CiA 301 |
| 글로벌 안전 실패 명령 | 001 | ? | CiA 304 |
| 플라잉 마스터 | 071 ~ 076 | ? | CiA 302-2 |
| 활성 인터페이스 표시 | 07F | ? | CiA 302-6 |
| 동기화 | 080 | 수신 전용 | CiA 301 |
| 비상 | 080 + 노드 ID | 송신 | CiA 301 |
| 타임스탬프 | 100 | 수신 전용 | CiA 301 |
| 안전 관련 데이터 객체 | 101 ~ 180 | ? | CiA 301 |
| PDO | 180 + 노드 ID 200 + 노드 ID 280 + 노드 ID 300 + 노드 ID 380 + 노드 ID 400 + 노드 ID 480 + 노드 ID 500 + 노드 ID | 1. 송신 PDO 1. 수신 PDO 2. 송신 PDO 2. 수신 PDO 3. 송신 PDO 3. 수신 PDO 4. 송신 PDO 4. 수신 PDO | CiA 301 |
| SDO | 580 + 노드 ID 600 + 노드 ID | 송신 수신 | CiA 301 |
| 동적 SDO 요청 | 6E0 | ? | CiA 302-5 |
| 노드 클레임 절차 | 6E1 ~ 6E3 | ? | CiA 416-1 |
| 노드 클레임 절차 | 6F0 ~ 6FF | ? | CiA 416-1 |
| NMT 노드 모니터링 (노드 감시/하트비트) | 700 + 노드 ID | 송신 | CiA 301 |
| LSS | 7E4 7E5 | 송신 수신 | CiA 305 |
송신 및 수신 방향은 장치의 관점에서 정의된다. 예를 들어 네트워크 장치에 쿼리(query)를 할 경우에는 0x600+노드ID를 보내고 0x580+노드ID를 반환받는다.[1]
4. 2. 통신 모델
CANopen 노드는 다음과 같은 종류의 통신 모델을 이용한다.- '''마스터/슬레이브 모델''': 네트워크상의 한 노드는 다른 노드들에게 데이터를 보내거나 요청하는 마스터(Master) 역할을 한다. NMT 프로토콜은 마스터/슬레이브 통신 모델의 한 예이다.
- '''SDO 프로토콜''': 클라이언트/서버 모델에 기초하여 동작한다. SDO 클라이언트(Client)는 SDO 서버(Server)상의 OBD 변수를 읽어오거나 변경할 수 있다.
- '''하트비트(Heartbeat)''' 또는 노드 가딩(Node guarding) 프로토콜: 생산자/소비자(Producer/Consumer) 모델을 이용한다. 푸시(Push) 모델에서 생산자는 특별한 요청이 없어도 소비자에게 데이터를 전송하며, 풀(Pull) 모델에서 소비자는 생산자에게 데이터를 요청해야만 한다.
CANopen의 노드는 컨슈머(Consumer)와 프로듀서(Producer)로 구성된다.
; 컨슈머
: 컨슈머는 정보를 수신하고 이용하는 측이다.
; 프로듀서
: 프로듀서는 정보를 관리하고 발신하는 측이다.
4. 3. 프로토콜
CANopen 장치는 제어 소프트웨어를 구현할 때 다음과 같은 표준 속성을 포함해야 한다.- '''통신 유닛'''은 네트워크 상의 다른 노드들과 메시지를 교환하기 위한 프로토콜들을 구현한다.
- 장치를 시작하거나 재시작할 때 유한 상태 기계에 의해 현재의 상태를 관리한다. CANopen 장치는 Initialization, Pre-operational, Operational과 Stopped 상태를 구현해야만 한다. 네트워크 관리 (NMT) 메시지를 장치에 전송하여 이러한 상태를 변경할 수 있다.
- '''객체 사전'''(object dictionary)은 장치가 지원하는 변수들의 집합이다. 16비트 인덱스 번호와 8비트의 서브인덱스 번호로 각각의 변수를 참조할 수 있다. 변수는 장치의 설정을 읽거나 변경하기 위해 사용하거나, 센서의 값을 읽기 위해 사용한다.
- 장치를 operational 상태로 설정하면 장치의 응용계층에서 미리 설정된 object dictionary 변수들을 주기적으로 또는 특정 이벤트에 의해 전송할 수 있다.
CANopen은 칩의 차이를 흡수하는 통신 프로파일 DS-301을 정의하고 있다. NEC 일렉트로닉스, 르네사스, 후지쯔 디바이스 외 약 50개의 전 세계 칩 제조업체에서 출시된 CAN 내장 마이크로컨트롤러 및 CAN 컨트롤러의 차이를 흡수하고 있다.
통신은 PDO 및 SDO로 구성되며, NMT에 의한 부트업이 정의되어 있다.
임베디드 시스템의 네트워크 기술로서 간편하게 멀티 마스터 네트워크를 구축할 수 있다. CANopen은 사양이 일반적으로 공개된 상위 소프트웨어이다.
2004년 12월에 독일의 비영리 단체 :de:CAN in Automation이 처음으로 통신 프로파일인 DS-301을 릴리스했다. 이 때의 버전은 v4.02이다.
긴급 메시지는 장치 내부의 치명적인 오류 상황 발생에 의해 트리거되며, 관련된 애플리케이션 장치에서 다른 장치로 높은 우선순위로 전송된다. 이는 인터럽트 유형의 오류 알림에 적합하게 만듭니다. 긴급 텔레그램은 ‘오류 이벤트’당 한 번만 전송될 수 있다. 즉, 긴급 메시지는 반복되지 않아야 한다. 장치에서 새로운 오류가 발생하지 않는 한 추가적인 긴급 메시지를 전송해서는 안 된다.
CANopen 통신 프로파일에서 정의된 긴급 오류 코드를 통해 오류 레지스터 및 장치별 추가 정보가 장치 프로파일에 지정된다.
4. 3. 1. 네트워크 관리 (NMT) 프로토콜
NMT 프로토콜은 장치의 상태를 변경하거나 장치가 부팅하고 정상적으로 동작하는지를 감지하는 데 사용된다.NMT 마스터 노드는 '''NMT 노드 제어 프로토콜'''을 이용하여 장치의 상태를 변경한다. 이 프로토콜의 COB-ID는 0이며, 네트워크 상의 모든 노드는 이 메시지를 수신하여 처리해야 한다. 데이터는 2바이트이며, 첫 번째 바이트는 변경할 상태를 나타내며, 두 번째 바이트는 수신 대상 노드를 가리킨다. 두 번째 바이트가 0일 경우 네트워크 상의 모든 노드들은 첫 번째 바이트에 기록된 상태로 전이해야 한다.
| COB-ID | 데이터 바이트 0 | 데이터 바이트 1 |
|---|---|---|
| 0x000 | 요청된 NMT 명령 코드 | 주소 지정된 노드 |
| NMT 명령 코드 | 의미 |
|---|---|
| 0x01 | 운영으로 이동 |
| 0x02 | 정지으로 이동 |
| 0x80 | 사전 운영으로 이동 |
| 0x81 | 노드 재설정으로 이동 |
| 0x82 | 통신 재설정으로 이동 |
'''Heartbeat 프로토콜'''은 master에서 네트워크 상의 노드들이 동작하고 있는지를 확인하기 위해 사용한다. Heartbeat producer는 주기적으로 1바이트 데이터를 포함한 메시지를 전송하여 자신의 상태를 master에게 알린다. COB-ID는 0x700 + 노드 아이디이다. 1바이트 데이터에는 노드의 상태 코드(NMT state code)가 담겨져 있다. Heartbeat consumer는 이 메시지를 주기적으로 수신하여야 한다. 만일 OBD에 정의된 특정 시간 내에 heartbeat를 수신하지 못하였을 경우에는 해당 노드를 재시작(reset)하거나 에러 메시지를 띄우는 방식으로 이 상황에 반응할 수 있다. 프레임 형식은 다음과 같다.
| COB-ID | 데이터 바이트 0 |
|---|---|
| 0x700 + 노드 ID | 상태 |
| NMT 상태 코드 | 표시된 상태 |
|---|---|
| 0x00 | Boot up (초기화 중) |
| 0x04 | Stopped |
| 0x05 | Operational |
| 0x7f | Pre-operational |
CANopen 장치는 부팅 시에 Initializing 상태에서 Pre-operational 상태로 이동하여 대기하여야 한다. Initializing 상태에서 Pre-operational 상태로 이동할 때 한 번만 1바이트 데이터에 0을 포함한 heartbeat 메시지를 전송하며, 이것을 '''bootup 프로토콜'''이라고 한다. 이후에는 0이 아닌 현재의 노드 상태를 포함한 heartbeat 메시지를 주기적으로 전송한다.
노드 guarding이라고 하는 요청/응답 방식 (pull 모델)으로도 slave를 모니터링할 수 있다.[1]
CANopen 마스터는 CANopen 슬레이브 노드로부터 하트비트 또는 가딩을 통해 기본적으로 시작된다.
4. 3. 2. 서비스 데이터 객체 (SDO) 프로토콜
CAN 버스에 연결된 노드의 객체 사전(OBD)에서 값을 읽거나 쓰기 위해 SDO 프로토콜을 사용할 수 있다. SDO 서버는 SDO 클라이언트의 요청에 따라 자신의 OBD에 있는 변수를 보내주거나 변경할 수 있다.SDO 프로토콜을 설명하는 CANopen 문서를 보면, 업로드(upload)와 다운로드(download)라는 용어를 볼 수 있다. 이는 SDO 서버의 관점에서 기술하는 용어이다. 즉, SDO 서버의 변수 값을 읽어 SDO 클라이언트에게 보내주는 동작(read)은 업로드라고 하고, 값을 쓰는 행위(write)는 다운로드라고 한다.
OBD 변수는 CAN 프레임에서 지원하는 최대 8바이트보다 더 큰 크기를 정의할 수 있다. 따라서 SDO 프로토콜은 8바이트보다 긴 메시지를 전송하기 위한 분할(segmentation)과 역분할(desegmentation)을 지원한다. CANopen 명세에서는 이를 지원하기 위한 두 가지 프로토콜을 정의하는데, 하나는 SDO 다운로드/업로드이고 다른 하나는 SDO 블록(Block) 다운로드/업로드이다. SDO 블록 전송은 더 최근에 표준화된 프로토콜이며, 전송 시 약간의 크기를 줄일 수 있고 더 큰 데이터를 전송할 수 있다.[1]
SDO 통신을 위한 COB-ID들은 OBD에 정의하여 사용할 수 있으나, 대부분 미리 정의된 COB-ID를 사용한다. SDO 클라이언트에서 서버로 보내는 요청 메시지의 경우 0x600 + 노드 ID를 사용하고, SDO 서버에서 클라이언트로 보내는 응답 메시지의 경우 0x580 + 노드 ID를 사용한다. SDO 프로토콜은 부팅 후 노드가 사전 작동(Pre-operational) 상태에 있을 때 사용할 수 있다. 주로 노드의 고유 값들을 읽어오거나 설정을 변경하기 위해 사용한다.[1]
SDO 다운로드를 시작하기 위해 SDO 클라이언트는 SDO 채널의 '수신' COB-ID를 가진 CAN 메시지에 다음 데이터를 보낸다.[1]
| 바이트 번호: | 바이트 0 | 바이트 1-2 | 바이트 3 | 바이트 4-7 | ||||
|---|---|---|---|---|---|---|---|---|
| 길이: | 3비트 | 1비트 | 2비트 | 1비트 | 1비트 | 2바이트 | 1바이트 | 4바이트 |
| 의미: | ccs=1 | 예약됨(=0) | n | e | s | 인덱스 | 서브인덱스 | 데이터 |
- '''ccs'''는 SDO 전송의 클라이언트 명령 지정자이며, SDO 세그먼트 다운로드의 경우 0, 다운로드 시작의 경우 1, 업로드 시작의 경우 2, SDO 세그먼트 업로드의 경우 3, SDO 전송 중단의 경우 4, SDO 블록 업로드의 경우 5, SDO 블록 다운로드의 경우 6이다.[1]
- '''n'''은 데이터를 포함하지 않고 데이터 부분에 있는 바이트 수이며, e와 s가 설정된 경우에만 유효하다.[1]
- '''e'''는 설정된 경우 신속한 전송을 나타낸다. 즉, 교환된 모든 데이터가 메시지 내에 포함된다. 이 비트가 지워지면 메시지는 데이터가 하나의 메시지에 맞지 않아 여러 메시지가 사용되는 분할된 전송이다.[1]
- '''s'''는 설정된 경우 데이터 크기가 n(e가 설정된 경우) 또는 메시지의 데이터 부분에 지정되었음을 나타낸다.[1]
- '''index'''는 접근할 데이터의 객체 사전 인덱스이며, 리틀 엔디안으로 인코딩된다.[1]
- '''subindex'''는 객체 사전 변수의 서브인덱스이다.[1]
- '''data'''는 신속한 전송(e가 설정됨)의 경우 업로드할 데이터를 포함하거나, 업로드할 데이터의 크기(s가 설정되고 e가 설정되지 않음)를 포함하며, 종종 리틀 엔디안으로 인코딩된다.[1]
4. 3. 3. 프로세스 데이터 객체 (PDO) 프로토콜
센서에서 읽은 값들을 실시간으로 전송하기 위해 PDO 프로토콜을 사용한다. PDO 메시지를 전송하기 전에 매핑 과정이 필요하다. 한 번에 최대 8바이트를 PDO 메시지에 담아 전송할 수 있다. 예를 들어 4바이트 OBD 데이터 2개 또는 4바이트 OBD 데이터 한 개와 2바이트 OBD 데이터 2개를 한 프레임에 담아 전송할 수 있다. 물론 필요하다면 1바이트의 데이터만 전송할 수도 있다. 어떤 노드는 자신의 PDO 매핑을 미리 가지고 있기도 하며, 마스터(master)는 슬레이브(slave)들의 매핑을 Pre-operational 상태에서 설정할 수 있다. 매핑을 완료하면, 노드를 operational 상태로 설정하여 PDO 메시지 전송을 시작한다.PDO 메시지는 전송 PDO (TPDO)와 수신 PDO (RPDO)로 나눌 수 있다. TPDO를 전송하는 노드는 누가 발신자인지를 COB-ID에 기록하지만 수신자는 지정하지 않으며, 이를 수신할 지 여부는 수신 노드들의 설정에 의해 결정된다. RPDO를 전송하는 노드는 COB-ID에 특정 노드를 수신자로 지정하여 메시지를 송신한다. 기본적으로 한 노드는 4개씩의 TPDO와 RPDO를 사용할 수 있지만, 특정 목적에 따라 더 많은 PDO들을 정의하여 사용할 수 있다.
PDO 메시지는 동기적 또는 비동기적으로 전달할 수 있다. 동기적 PDO에서는 노드가 마스터로부터 SYNC 메시지를 수신하였을 때 PDO 메시지를 전달한다. 반면 비동기적 PDO 에서는 내부 또는 외부 트리거에 의해 메시지를 전송한다. 내부 트리거의 예는 센서에서 데이터를 감지할 때마다 PDO를 전달하는 경우이며, 외부 트리거의 예는 RTR 플래그를 설정한 빈 TPDO 메시지를 전송하여 응답형식으로 받는 경우이다. RPDO를 사용하면 두 개 이상의 장치를 동시에 시작할 수 있는데, 동일한 RPDO를 두 개 이상의 다른 장치에 매핑하고 해당 RPDO가 동일한 COB-ID로 매핑되었는지 확인하면 된다.
4. 3. 4. 동기화 객체 (SYNC) 프로토콜
동기화 공급자(SYNC producer)는 동기화 소비자(SYNC consumer)에게 동기화 신호를 전달한다. 동기화 소비자는 SYNC 메시지를 수신하면 동기적 작업을 시작한다.[1]SYNC 메시지는 데이터 없이 COB-ID만 전달하며, COB-ID는 0x080이다. OBD 0x1005에서 SYNC COB-ID를 변경할 수 있다.[1]
일반적으로 동기 PDO 메시지의 전송 시간을 고정하고 동기 객체의 전송 주기를 일정하게 유지하면, 센서 장치가 공정 변수를 샘플링하고 액추에이터 장치가 조정된 방식으로 작동하도록 보장할 수 있다.[1]
동기 객체의 식별자는 인덱스 1005h에서 확인할 수 있다.[1]
4. 3. 5. 타임스탬프 객체 (TIME) 프로토콜
CANopen에서 타임스탬프 객체는 일반적으로 6바이트 필드를 사용하여 시간을 나타낸다. 이는 자정 이후 경과된 밀리초(최대 27비트, 32비트 필드에 저장)와 1984년 1월 1일 이후 경과된 날짜 수를 나타내는 부호 없는 16비트 숫자로 구성된다. 이 방식은 2163년 6월 7일에 오버플로된다.일부 시간 제약적인 응용 분야, 특히 전송 속도가 낮은 대규모 네트워크에서는 매우 정확한 동기화가 필요할 수 있다. 이러한 경우 로컬 시계를 마이크로초 단위의 정확도로 동기화해야 할 수 있다. 이를 위해 로컬 시계의 불가피한 드리프트를 조정하는 특수한 형태의 타임스탬프 메시지를 사용하는 선택적 고해상도 동기화 프로토콜이 사용된다.
고해상도 타임스탬프는 1 마이크로초의 해상도를 가진 부호 없는 32비트로 인코딩되며, 이는 시간 카운터가 72분마다 다시 시작됨을 의미한다. 고해상도 타임스탬프(객체 1013h)는 PDO에 매핑하여 구성된다.
5. 전자 데이터 시트 (Electronic Data Sheet, EDS)
전자 데이터 시트(EDS)는 CiA306에 정의된 파일 형식으로, 장치의 통신 동작 및 객체 사전 항목을 설명한다. 이를 통해 서비스 도구, 구성 도구, 개발 도구 등과 같은 도구가 장치를 제대로 처리할 수 있다.
이러한 EDS 파일은 CiA CANopen 적합성 테스트를 통과하는 데 필수적이다.
2007년 말부터 CiA311에 XML 기반의 새로운 형식인 XDD가 정의되었다. XDD는 ISO 표준 15745를 준수한다.
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com