CANopen PDO·SDO 차이｜실시간 데이터와 파라미터 통신 구분

CANopen 장비의 매뉴얼이나 EDS 파일을 보면 PDO, SDO, TPDO, RPDO라는 표현을 자주 볼 수 있습니다.

둘 다 CANopen의 Object Dictionary에 있는 데이터를 주고받는 방법이지만 목적은 완전히 다릅니다.

가장 간단하게 정리하면

PDO = 빠르게 반복해서 주고받는 실시간 Process Data

SDO = 장비의 파라미터를 읽고 쓰는 설정·진단 통신

입니다.

예를 들어 서보드라이브라면

현재 위치·목표 속도 → PDO

가속도 설정·전류 제한값 → SDO

처럼 나눠 사용할 수 있습니다.

CANopen Object Dictionary란?

CANopen 장비에는 통신으로 접근할 수 있는 데이터가 Object Dictionary라는 구조로 정리되어 있습니다.

각 데이터에는

16bit Index

와

8bit Sub-index

가 사용됩니다.

예를 들어 하나의 데이터가

Index 0x2000

Sub-index 0x01

에 저장되어 있을 수 있습니다.

이렇게 보면 Object Dictionary는 장비 내부의 통신용 데이터베이스와 비슷합니다.

SDO는 이 Object Dictionary의 항목을 직접 읽거나 쓰는 데 사용되고, PDO는 필요한 Object를 미리 골라 빠르게 전송하는 데 사용합니다.

PDO와 SDO 핵심 차이

구분	PDO	SDO
전체 이름	Process Data Object	Service Data Object
주요 목적	실시간 Process Data	설정·진단·파라미터
통신방식	Producer → Consumer	Client ↔ Server
응답 확인	일반적으로 별도 응답 없음	요청과 응답 존재
데이터 효율	높음	상대적으로 Overhead 큼
Object 접근	미리 Mapping된 데이터	Object Dictionary 직접 접근
대표 용도	위치·속도·I/O	설정값·Device Parameter

즉 실시간성이 중요한 데이터는 PDO가 유리하고, 특정 Parameter를 정확하게 읽고 쓰는 작업에는 SDO가 적합합니다.

PDO란?

PDO는 Process Data Object의 약자입니다.

CANopen에서 높은 우선순위의 제어·상태정보를 빠르게 전달하는 데 사용합니다.

대표적으로

모터 현재속도
목표속도
현재위치
Digital Input
Digital Output
센서 측정값

등이 PDO에 적합합니다.

표준 CAN 기반 CANopen CC에서는 하나의 PDO가 하나의 CAN Data Frame으로 전송되며 최대 8Byte의 Application Data를 사용할 수 있습니다.

별도의 요청·응답 과정을 최소화하기 때문에 실시간 제어에 유리합니다.

TPDO와 RPDO는 무엇일까?

PDO는 방향에 따라

TPDO

RPDO

로 구분합니다.

TPDO

Transmit PDO

해당 장치가 전송하는 Process Data입니다.

예를 들어 Encoder가 자신의 현재 위치를 CAN Bus로 전송한다면 Encoder 입장에서는 TPDO입니다.

RPDO

Receive PDO

해당 장치가 수신하는 Process Data입니다.

서보드라이브가 Master에서 Target Position을 받는다면 Servo 입장에서는 RPDO가 됩니다.

즉 같은 CAN Frame이라도

보내는 장치에서는 TPDO

받는 장치에서는 RPDO

라는 개념으로 볼 수 있습니다.

실제 Servo에서는 어떻게 사용할까?

Servo Drive를 예로 들어보겠습니다.

Master에서 Servo로

Controlword

Target Position

을 전송해야 하고,

Servo에서는 Master로

Statusword

Actual Position

을 보내야 한다고 가정하겠습니다.

구조는 다음처럼 만들 수 있습니다.

Master → Servo RPDO

Controlword
Target Position

그리고

Servo TPDO → Master

Statusword
Actual Position

형태입니다.

이렇게 하면 매 제어 Cycle마다 필요한 핵심 데이터만 빠르게 교환할 수 있습니다.

PDO Mapping이란?

PDO의 중요한 특징은 Object Dictionary에서 어떤 데이터를 PDO에 넣을 것인지 지정할 수 있다는 것입니다.

이를 PDO Mapping이라고 합니다.

예를 들어 TPDO에 다음 데이터를 넣는다고 가정하겠습니다.

Statusword = 2Byte

Actual Position = 4Byte

Actual Current = 2Byte

합계는

2 + 4 + 2 = 8Byte

입니다.

표준 CANopen CC의 8Byte PDO 안에 정확히 들어갑니다.

이렇게 필요한 데이터를 미리 Mapping하면 매번

0x6041 값을 주세요

0x6064 값을 주세요

라고 요청할 필요가 없습니다.

한 번의 CAN Frame으로 세 데이터를 동시에 전송할 수 있습니다.

PDO Mapping 관련 Index는?

CiA 301 구조에서는 PDO Communication과 Mapping Parameter가 Object Dictionary에 따로 존재합니다.

대표적으로

0x1400~ = RPDO Communication Parameter

0x1600~ = RPDO Mapping Parameter

0x1800~ = TPDO Communication Parameter

0x1A00~ = TPDO Mapping Parameter

영역을 사용합니다.

Communication Parameter에서는

COB-ID
Transmission Type

등을 설정하고,

Mapping Parameter에서는

어떤 Object를 몇 bit씩 PDO에 넣을지 지정합니다.

SDO란?

SDO는 Service Data Object의 약자입니다.

SDO는 CANopen 장비의 Object Dictionary에 있는 항목을 읽거나 쓰는 데 사용합니다.

예를 들어 Master가 Servo의

Maximum Current
Acceleration
Node Parameter
Manufacturer Information

등을 읽거나 변경할 때 사용할 수 있습니다.

SDO는 기본적으로 Client-Server 방식입니다.

Object Dictionary를 가지고 있는 장치가 SDO Server가 되고, 해당 장치에 접근하는 장치가 SDO Client가 됩니다.

SDO Upload와 Download 방향은?

CANopen에서 처음 보면 가장 헷갈리는 부분입니다.

SDO Upload

Server → Client

즉 장비의 값을 읽어오는 동작입니다.

예를 들어

Slave의 0x2000 값을 읽어라

는 SDO Upload입니다.

SDO Download

Client → Server

즉 장비에 값을 쓰는 동작입니다.

예를 들어

0x2000 Parameter를 100으로 설정하라

는 SDO Download입니다.

일반적인 PC 파일 Upload·Download 느낌과 반대로 느껴질 수 있으므로 Object Dictionary Server를 기준으로 방향을 생각하면 쉽습니다.

SDO는 왜 PDO보다 느릴까?

SDO는 요청을 보내고 상대방의 응답을 확인하는 Confirmed Communication입니다.

예를 들어 Master가

Index 0x2000 / Sub-index 01 값을 읽고 싶다

라는 요청을 보내면 Slave가 해당 요청을 확인하고 값을 응답합니다.

즉

Request

↓

Response

과정이 필요합니다.

반면 PDO는 이미 어떤 데이터를 보낼지 Mapping돼 있기 때문에 데이터를 CAN Frame에 바로 담아 전송합니다.

따라서 반복적으로 전송하는 실시간 Process Data는 PDO가 훨씬 효율적입니다.

4Byte 이하 데이터는 SDO로 한 번에 보낼 수 있을까?

CANopen CC의 SDO에는 Expedited Transfer 방식이 있습니다.

작은 데이터는 하나의 SDO 요청과 응답 과정으로 처리할 수 있습니다.

대표적으로 최대 4Byte의 데이터를 Expedited 방식으로 전송할 수 있습니다.

예를 들어 32bit Parameter 하나라면

4Byte

이므로 Expedited SDO로 처리할 수 있습니다.

하지만 데이터가 더 크면 다른 전송방법이 필요합니다.

Segmented SDO는 무엇일까?

SDO로 전송해야 하는 데이터가 한 Frame에 들어가지 않는다면 여러 개로 나눠 전송할 수 있습니다.

이를 Segmented Transfer라고 합니다.

예를 들어 장비의 긴 문자열이나 큰 Parameter Block을 보낸다면

Segment 1
ACK
Segment 2
ACK
Segment 3
ACK

처럼 여러 번 나눠 전송합니다.

따라서 큰 데이터를 전송할 수 있지만 요청과 응답이 반복되므로 PDO보다 통신시간이 길어집니다.

Block Transfer는 언제 사용할까?

CANopen SDO에는 Block Transfer 방식도 있습니다.

Segmented 방식은 각 Segment마다 응답을 확인하기 때문에 큰 데이터를 전송하면 Overhead가 커질 수 있습니다.

Block Transfer는 여러 Segment를 하나의 Block으로 묶어 전송하고 이후 확인하는 방식으로 통신효율을 높입니다.

따라서 비교적 많은 양의 데이터를 SDO로 전송해야 할 때 사용할 수 있습니다.

실제 지원 여부는 장비의 CANopen Stack을 확인해야 합니다.

PDO는 정말 응답이 없을까?

PDO는 기본적으로 Unconfirmed Communication입니다.

즉 TPDO를 보낸 뒤

잘 받았습니다

라는 별도의 응답 Frame을 기다리지 않습니다.

이 때문에 빠르고 효율적입니다.

다만 CAN Data Link Layer 자체에는 Frame 전송을 위한 ACK 메커니즘이 존재합니다.

여기서 말하는 응답 없음은 PDO Application Protocol에서 별도의 Request-Response 절차가 없다는 의미입니다.

PDO는 여러 장치가 받을 수도 있다

CAN은 Broadcast 기반 통신입니다.

한 장치가 특정 CAN-ID의 TPDO를 전송하면 해당 Frame을 필요로 하는 여러 장치가 동시에 받을 수 있습니다.

즉 구조적으로

Producer

↓

PDO

↓

Consumer A

Consumer B

Consumer C

형태도 가능합니다.

따라서 동일한 센서 데이터가 여러 Controller에 필요한 경우에도 효율적으로 사용할 수 있습니다.

PDO는 언제 전송될까?

PDO는 항상 일정 주기로만 보내는 것은 아닙니다.

Communication Parameter의 Transmission Type 등에 따라 여러 방식으로 동작할 수 있습니다.

대표적으로

Synchronous PDO

SYNC Message에 맞춰 전송 또는 처리

Event-driven PDO

값 변경이나 Event 발생 시 전송

Timer 기반 PDO

설정된 시간주기에 따라 전송

등으로 사용할 수 있습니다.

따라서 PDO = 무조건 10ms 주기 통신처럼 이해하면 안 됩니다.

SYNC와 PDO를 같이 쓰는 이유

여러 장치에서 같은 시간기준으로 Process Data를 처리해야 할 때 SYNC Object를 활용할 수 있습니다.

예를 들어

SYNC

↓

Servo A PDO 처리

Servo B PDO 처리

Servo C PDO 처리

처럼 동작하게 만들 수 있습니다.

이를 통해 여러 축의 제어데이터를 정해진 통신 Cycle에 맞춰 처리할 수 있습니다.

다만 실제 정밀 Motion System에서는 CAN Bus 속도와 장치성능 등 전체 시스템 조건도 함께 고려해야 합니다.

PDO 8Byte에는 무엇까지 넣을 수 있을까?

표준 CANopen CC를 기준으로 하나의 PDO에는 최대 8Byte의 Application Data가 들어갑니다.

예를 들어

Controlword = 16bit = 2Byte

Target Position = 32bit = 4Byte

Mode = 8bit = 1Byte

Reserved = 8bit = 1Byte

라면

2 + 4 + 1 + 1

= 8Byte

입니다.

따라서 하나의 PDO에 모두 넣을 수 있습니다.

반대로

32bit 데이터 3개

를 전송한다면

4 × 3

= 12Byte

이므로 표준 CANopen CC의 PDO 하나에는 들어가지 않습니다.

이 경우 여러 PDO로 나누는 방식 등을 고려해야 합니다.

CANopen FD에서는 달라질까?

그렇습니다.

일반 CANopen CC는 Classical CAN을 기반으로 하기 때문에 하나의 PDO Application Data가 최대 8Byte입니다.

반면 CAN FD 기반의 CANopen FD에서는 하나의 PDO를 통해 최대 64Byte까지 Process Data를 전달할 수 있습니다.

따라서 문서를 읽을 때

CANopen CC

인지

CANopen FD

인지 구분해야 합니다.

CANopen PDO는 항상 64Byte 또는 항상 8Byte라고 하나로 말하면 정확하지 않습니다.

실제 장비 설정은 어떻게 나눌까?

서보시스템을 예로 들어보겠습니다.

장비 시작 시에는 SDO를 이용해

Acceleration = 500

Maximum Current = 8A

Operation Mode = Position

같은 Parameter를 설정합니다.

그 뒤 운전이 시작되면 PDO를 이용해

Target Position

Controlword

Actual Position

Statusword

를 반복적으로 교환합니다.

즉 실제 흐름은

시작·설정 단계 → SDO

↓

정상 운전 단계 → PDO

라고 이해하면 쉽습니다.

물론 운전 중에도 진단이나 Parameter 조회를 위해 SDO를 사용할 수 있습니다.

왜 모든 데이터를 PDO로 보내지 않을까?

PDO가 빠르다고 해서 모든 데이터를 PDO에 넣는 것이 좋은 것은 아닙니다.

CAN Bus의 대역폭은 한정돼 있기 때문입니다.

예를 들어 100개의 Parameter를 전부 PDO로 반복 전송하면 실제로 거의 변하지 않는 설정값까지 계속 Bus를 차지하게 됩니다.

그래서

자주 변하고 빠르게 필요한 데이터 → PDO

가끔 읽거나 설정하는 데이터 → SDO

로 구분하는 것이 효율적입니다.

실제 데이터시트를 읽어보자

CANopen Servo의 사양에 다음과 같이 적혀 있다고 가정하겠습니다.

CANopen CiA 301

CiA 402 Drive Profile

4 TPDO / 4 RPDO

SDO Server Supported

Dynamic PDO Mapping Supported

이를 해석하면

CiA 301

CANopen Application Layer와 Communication Profile 사용

CiA 402

Servo·Drive 관련 표준 Object 사용

4 TPDO / 4 RPDO

송신·수신 Process Data Object를 여러 개 제공

SDO Server

Object Dictionary Parameter를 SDO로 읽고 쓸 수 있음

Dynamic PDO Mapping

PDO에 들어가는 Object를 일정 범위에서 사용자가 변경할 수 있음

이라는 의미입니다.

EtherCAT의 PDO·SDO와 헷갈리면?

앞에서 다룬 EtherCAT CoE에서도 PDO·SDO라는 용어를 사용합니다.

그 이유는 EtherCAT CoE가 CANopen의 Object Dictionary와 Application Profile 개념을 활용하기 때문입니다.

하지만 실제 전송매체는 다릅니다.

CANopen에서는 CAN Frame을 사용하고,

EtherCAT CoE에서는 EtherCAT Frame을 사용합니다.

따라서 개념은 비슷해도

CANopen PDO = CAN Bus에서 전송

EtherCAT CoE PDO = EtherCAT Process Data로 Mapping

이라는 차이가 있습니다.

흔히 잘못 해석하는 부분

첫 번째는

“SDO는 느리니까 사용하면 안 된다.”

라는 생각입니다.

SDO는 설정과 진단처럼 응답확인이 필요한 통신에 적합하도록 만들어졌습니다.

두 번째는

“PDO가 Object Dictionary 전체를 자유롭게 읽는다.”

라는 생각입니다.

PDO는 미리 Mapping한 Object를 전송합니다.

세 번째는

“TPDO는 Master가 보내고 RPDO는 Slave가 보낸다.”

라는 생각입니다.

Transmit와 Receive는 각 장치의 입장에서 판단합니다.

네 번째는

“PDO와 SDO 중 하나만 사용한다.”

라는 생각입니다.

실제 CANopen 시스템에서는 두 방식을 함께 사용하는 경우가 일반적입니다.

정리

CANopen에서 PDO와 SDO를 구분하는 가장 쉬운 방법은 데이터가 얼마나 자주 필요한지를 보는 것입니다.

PDO = 빠르고 반복적으로 필요한 Process Data

SDO = 설정·조회가 필요한 Parameter Data

그리고 PDO는

TPDO = 장치가 전송

RPDO = 장치가 수신

으로 나뉩니다.

실제 장비를 설정할 때는

Object Dictionary 확인 → SDO로 초기 Parameter 설정 → PDO Mapping 구성 → TPDO·RPDO로 실시간 데이터 교환

순서로 이해하면 CANopen 통신구조가 훨씬 쉽게 보입니다.

특히 서보나 I/O 장비에서는 모든 Parameter를 PDO에 넣기보다 실시간성이 필요한 값만 PDO로 Mapping하고 나머지는 SDO로 접근하는 것이 효율적인 설계의 핵심입니다.

참고자료

• CAN in Automation(CiA) – CANopen: CANopen Application Layer가 SDO, PDO, NMT, Special Function 및 Error Control Protocol로 구성되며 Object Dictionary를 중심으로 장치 통신을 구성하는 방식을 설명합니다.
• CAN in Automation(CiA) – CiA 301 Version 4.2.0: CANopen application layer and communication profile. Object Dictionary, PDO·SDO, NMT와 CANopen의 기본 통신서비스를 정의하는 핵심 사양입니다.
• CAN in Automation(CiA) – PDO Protocol: CANopen CC의 PDO는 하나의 CAN Frame으로 최대 8Byte의 Application Data를 전송하며 TPDO·RPDO 및 PDO Communication·Mapping Parameter 구조를 사용한다고 설명합니다.
• CAN in Automation(CiA) – SDO Protocol: SDO는 Object Dictionary 전체에 접근할 수 있는 Confirmed Client-Server Communication이며 Expedited, Segmented, Block Transfer 방식을 지원합니다.
• CANopenNode – PDO / SDO Documentation: PDO는 실시간 데이터 전송을 위한 낮은 Protocol Overhead 방식이며 SDO는 Object Dictionary의 Parameter 설정과 조회에 주로 사용되는 구조임을 실제 CANopen Stack 구현을 통해 설명합니다.