각 장치가 노드로 지정된다.
각 장치의 우선순위는 장치의 메세지 우선순위에 따라 부여된다.
전송해야하는 슬레이브 장치가 없다.

1. CAN vs CANopen

1-1. 메세지에 주소 포함 여부

CAN은 하드웨어 간의 효율적인 통신을 위한 저수준 프로토콜이다.
CANopen은 CAN 프로토콜 위에 구축된 고수준 프로토콜로, 특정 응용 분야에서 고급 기능과 통신 관리를 제공한다는 차이점이 있다.

CAN 통신은 아주 커다란 특징이 있는데,
주고받는 메세지에 Source Address, Destination Address가 없다는 것이다.
(대신 메시지 식별자를 이용해서 메시지를 구별한다.)

하지만! CANopen 은 주소를 다 갖고있다.

그러므로 아래와 같은 이점이 생기게 된다.

• 특정 장치를 식별할 수 있다.
• 주소를 사용하면 데이터 메시지를 정확한 수신자로 라우팅할 수 있으므로 불필요한 데이터 트래픽을 줄일 수 있다.
• 확장성: 주소를 사용하면 더 복잡한 네트워크 구성을 지원할 수 있으며, 다양한 기능과 장치 간의 통신을 지원할 수 있다.
• 관리 및 디버깅: 주소 정보를 통해 네트워크의 구성과 통신을 관리하고 문제 해결을 용이하게 할 수 있다.

1-2. 실시간성

CAN은 주로 신뢰성에 초점을 두고 있으며, CANopen은 통신주기설정, 실시간 데이터 전송, 통신 프로파일 제공, 빠른 오류 처리 등의 기능을 제공하며 실시간성을 더하고 있다.

CAN (Controller Area Network)은 실시간 통신을 지원할 수 있는 프로토콜이지만, 실시간 통신을 위한 특수한 요구 사항을 갖춘 프로토콜이 아니기 때문에 실시간성을 보장하는 것은 단독으로 사용할 때에는 어려울 수 있다.

CAN은 충돌 검출 및 재전송 메커니즘을 사용하여 데이터 무결성을 보장하며, 신뢰성 높은 통신을 제공한다.
그러나 CAN은 메시지 우선순위 및 충돌 해결을 위한 알고리즘을 사용하고 있기 때문에 메시지가 네트워크를 통과하는 데 몇 밀리초 이상의 시간이 걸릴 수 있다.

따라서 CAN을 실시간 통신에 사용할 때는,
네트워크의 부하, 메시지 우선순위 설정, 통신 주기 설정 및 하드웨어 지원을 고려하여 시스템을 설계해야하고, CANopen과 같은 고수준 프로토콜을 사용하거나 CAN 통신을 실시간 요구 사항에 맞게 확장하여 사용한다.

그렇다면! CANopen은 어떤 방식으로 실시간 통신을 지원할까?

1-2-1. 통신 주기 설정

CANopen은 각 노드 및 데이터 객체에 대한 통신 주기를 설정할 수 있으며, 특정 데이터를 주기적으로 전송하거나 요청하여 실시간 응용 프로그램의 요구 사항을 충족시킬 수 있다.

1-2-2. 실시간 데이터 전송

CANopen은 실시간 데이터를 주고받는 데 사용되므로, 제어 시스템과 같은 응용 분야에서 감시 및 제어 신호를 실시간으로 교환할 수 있다.

1-2-3. 통신 프로파일

CANopen은 실시간 통신을 지원하기 위해 표준 통신 프로파일을 제공하는데, 이러한 프로파일은 실시간 요구 사항을 충족하기 위한 통신 패턴을 정의한다.

1-2-4. 빠른 오류 처리

CANopen은 통신 오류를 빠르게 감지하고 처리하는 기능을 제공해 시스템이 예기치 않은 상황에 대응할 수 있도록 한다.

---

2. CANopen의 통신 모델

아래 모델들은 실질적으로는 동일하지만,

2-1. Master - Slave : NMT

Master는 각각의 디바이스(여러 모터 등의 슬레이브들)의 Host controller 역할을 통해, 진단 및 상태 관리를 할 수 있다. 0~127개의 슬레이브가 있을 수 있다.
단일 CANopen 네트워크에는 동일한 데이터 링크 레이어를 공유하는 호스트 컨트롤러가 있을 수 있다.

2-2. Client - Server : SDO

Server : 대상 사전(Objrct)에 접근하여 요청한 서비스를 제공하는 CANopen 장치
Upload(읽기) / Download(쓰기) 의 활동으로 구성된다.
Client : 장치의 사전(Object)에 방문한 방문자

클라이언트는 서버에 데이터 요청을 보내고, 서버는 요청된 데이터에 반드시 응답해야한다.
고객의 CAN 메세지와 서버의 응답 CAN 메세지는 항상 8바이트의 데이터를 포함한다.

예를 들어 Master가 Slave의 Object Dictionary의 데이터를 필요로 하는 경우에 사용된다.

2-3. Producer - Consumer : PDO

Producer 노드는 Consumer 노드에서 소비되는 데이터를 네트워크에 Broadcast한다.
Producer 노드는 특별한 요청 없이 데이터를 보내게 된다.

---

3. Services

서비스는 우선 순위를 지정하는 범위에 맞는 ID로 구별된다.
서비스는 특정 범위의 인덱스를 통하여 자신의 객체에만 접근할 수 있다.

3-1. 서비스의 종류

CANopen_ID = CAN_ID + node_ID
NMT Network Management
EMC Emergeny
SYNC Synchronistation
HB Heartbeat
SDO Service Data Objects
RPDO / TPDO Recive / Transmit Process Data Object
Time Timestamp

3-1-1. NMT

네트워크 매니지먼트
시작, 중지 등의 명령을 내려서 버스에 있는 각 장치의 상태 동기화를 관리한다.
버스에서 높은 우선순위를 갖고 단 하나의 마스터만 존재.

노드id가 없으면 broadcast call(버스에 연결된 모든 제어기에게 메세지를 송신)이다
첫번째 바이트가 1hex = 장치가 작동상태로 전환됨을 의미

3-1-2. EMCY

장치는 치명적인 오류가 발생했음을 알리는 메세지를 작성할 수 있다. ex) 네트워크 연결 끊김 등
응답 동작이 지정되어있지 않다.

[Objrects]

상황	메모리	의미
Error status bits	0x2100
Error register	0x1001
Pre-defined error field	0x1003
COB-ID EMCY	0x1014
Inhibit time EMCY	0x1015	메세지가 전송되는 시간 간격

메세지에는 어떤 상황이 발생했는지 확인할 수 있는 Error Register Flag, Error Register Code 가 포함되어 있다. 이들은 COB-Emergency? 헤더 파일에서 찾을 수 있다.

장치가 RXT 표현 메세지를 보내는 경우
장치가 연결 안됐거나 비트전송률이 나쁘거나 근처에 강한 전자기기의 감지

3-1-3. SYNC

장치에서 동기화를 위해 고정된 시간 간격으로 메세지를 생성한다.
마스터에 의해 작동되는 여러 디바이스의 입력 감지 및 작동 동기화 기능

[Objrects] : Clock signal 과 동일

상황	메모리	의미
COB ID SYNC Messege	0x1005
Communication cycle period	0x1006
Synchronous windows length	0x1007	period of signal
Synchronous counter overflow value	0x1019	SYNC PDOs를 위한 창 길이

3-1-4. HB(SDO)

장치가 서비스중인지 모니터링하는 데에 사용한다.
Slave 들의 alive메세지를 master가 확인하고, Slave들은 Master의 NMT 명령을 확인하는 데에 목적이 있다.

[Objrects] : Clock signal 과 동일

상황	메모리	의미
Consumer heatbeat time	0x1016
Producer heartbeat time	0x1017

Bootup messege : 초기화 상태에서 사전 작동 상태로 전환할 때 보내는 메세지 / 장치는 작동모드로 전환할 준비가 되었음을 신호로 보낸다.

• internal transition of device from INITIALIZING to PRE-OPERATIONAL
• COB-ID : 0x700 + nodeID

3-1-5. TIME(PDO)

실제 날짜와 시간 정보를 제공한다.
메세지의 길이 : 6Byte , 한 장치에서만 생성된다. 응답메세지는 없다.
[Objrects]

상황	메모리	의미
COB ID TIME	0x1012
High resolution timestamp	0x1013

3-1-6. SDO

Master가 디바이스의 특정 구성을 변경해야 하는 경우 등에, Object Dictonary에 접근하거나 값을 변경하는데에 사용된다.

• Client - Server 사이에서 4Byte보다 작거나 같은 메세지이므로 신속하다.
• 각각의 세그먼트는 통신의 초기 or 중지 상태에서 허용된다.
• 장치마다 최소 128개의 SDO 가능

[SDO의 메세지의 기본구조]

Byte 0	Byte 1	Byte 2	Byte 3~7
SDO 명령어	인덱스	서브 인덱스	데이터

[Objrects]

상황	메모리	의미
COB ID for Receive(Server)	0x1200 ~ 0x127F
COB ID for Transmit(Client)	0x600 ~ 0x67F

3-1-7. PDO

Process Data Object
장치마다 요청을 만들어 실시간으로 전달하는 서비스
요청의 빈도를 지정할 수 있다.
객체의 최대 길이는 8바이트
Silent mode - Inhibit Timer : 더 높은 우선순위 메시지가 방해받지 않도록 할 수 있다.
각 디바이스마다 서로 다른 CAN ID 를 이용하여 512개까지의 메시지를 정의할 수 있다

이론적으로는 SDO만을 이용한 데이터 전송이 가능하지만. 단일 프레임 내에 여러 개체의 매개 변수 값이 포함되거나, 정보량이 많을 때 유리합니다.

상황	메모리	의미
ID	0x181 ~ 0x57F
COB ID for Transmit(Client)	0x600 ~ 0x67F

RTPO0
0x1400
0x1600

3-2. Objetct Dictionary

CANopen 노드의 동작을 설명하는 모든 매개변수를 포함하는 표준화된 구조
각 장치에 특정한 구성 파일로 EDS에디터에 의해 구성된다.

16비트의 인덱스와 8비트의 하위 인덱스를 통해서 조회가 가능하며, 각 객체에는 전용 인덱스와 데이터의 길이, 데이터의 포인터, 속성 등을 갖고있다.

• Index 16비트로 구성된 개체의 기본 주소
• Object Name 장치의 이름
• Object Code array, variable, record..
• Data Type VISIBLE_STRING, Unsighed32 ..
• Access read(ro) / write(wo) / read&write(rw)..
• Category 선택 사항

---

참조
CANopen 자료