열리다

CANopen

CANopen자동화에 사용되는 임베디드 시스템의 통신 프로토콜 및 장치 프로파일 사양입니다.OSI 모델의 관점에서 CANopen은 네트워크 계층을 포함하여 위의 계층을 구현합니다.CANopen 표준은 어드레싱 체계, 여러 개의 작은 통신 프로토콜 및 장치 프로파일에 의해 정의된 애플리케이션 계층으로 구성됩니다.통신 프로토콜은 네트워크 관리, 장치 모니터링 및 노드 간 통신을 지원합니다. 여기에는 메시지 분할/분할을 위한 단순한 전송 계층이 포함됩니다.데이터 링크와 물리 레이어를 구현하는 하위 레벨의 프로토콜은 보통 Controller Area Network(CAN; 컨트롤러 영역 네트워크)이지만, 다른 통신 수단(Ethernet Powerlink, EtherCAT 등)을 사용하는 디바이스도 CANopen 디바이스 프로파일을 구현할 수 있습니다.

기본적인 CANopen 장치 및 통신 프로파일은 CAN[1]자동화에서 발표한 CiA 301 사양에 나와 있습니다.보다 특수한 디바이스용 프로파일은 이 기본 프로파일을 기반으로 구축되며, I/O 모듈용 CiA 401[2] 및 모션 컨트롤용 CiA 402와[3] 같이 CAN in Automation에서 릴리스된 수많은 표준에서 명시되어 있습니다.

디바이스 모델

모든 CANopen 디바이스는 제어 소프트웨어에서 특정 표준 기능을 구현해야 합니다.

  • 통신 유닛은, 네트워크내의 다른 노드와의 메시징을 위한 프로토콜을 실장한다.
  • 장치의 시작 및 리셋은 상태 기계를 통해 제어됩니다.Initialization, Pre-Operational, Operational 및 Stopped 상태를 포함해야 합니다.스테이트간의 이행은 Network Management(NMT; 네트워크 관리) 통신 오브젝트를 디바이스에 발행함으로써 이루어집니다.
  • 개체 사전은 16비트 인덱스를 가진 변수 배열입니다.또한 각 변수는 8비트 서브인덱스를 가질 수 있습니다.변수를 사용하여 장치를 구성하고 측정 데이터를 포함하는 환경(예: 측정 데이터)을 반영할 수 있습니다.
  • 디바이스의 어플리케이션 부분은 상태 머신이 동작 상태로 설정된 후에 실제로 디바이스의 원하는 기능을 수행합니다.응용 프로그램은 개체 사전의 변수에 의해 구성되며 데이터는 통신 계층을 통해 송수신됩니다.

오브젝트 딕셔너리

CANopen 장치에는 장치와의 구성 및 통신에 사용되는 개체 사전이 있어야 합니다.오브젝트 딕셔너리의 엔트리는 다음과 같이 정의됩니다.

  • Index(사전에 있는 개체의 16비트 주소)
  • 객체 이름(개체 유형/크기), 배열, 레코드 또는 단순 변수와 같은 엔트리 내 객체의 심볼 유형
  • Name, 엔트리를 설명하는 문자열
  • Type: 변수의 데이터 유형(또는 배열의 모든 변수의 데이터 유형)을 제공합니다.
  • Attribute: 이 엔트리의 액세스 권한에 대한 정보를 제공합니다.읽기/쓰기, 읽기 전용 또는 쓰기 전용입니다.
  • [ Mandatory / Optional ]필드(M/O)는 디바이스 사양에 준거한 디바이스가 이 오브젝트를 실장할 필요가 있는지 여부를 정의합니다.

부란, 정수 플로트와 같은 객체 사전 값의 기본 데이터형은 표준(비트 단위의 크기는 관련 유형 정의인 인덱스 범위 0x0001~0x001F에 선택적으로 저장됨)과 문자열, 배열 및 레코드(인덱스 범위 0x0040~0x025F에 정의됨)에 정의됩니다.복합 데이터형은 8비트 인덱스로 하위 인덱스를 지정할 수 있습니다. 배열 또는 레코드의 하위 인덱스 0 값은 데이터 구조 내의 요소 수를 나타내며 UNSIGNED8 유형입니다.

예를 들어 기본 디바이스 프로파일 CiA301에서[4] 표준화된 디바이스 통신 파라미터는 인덱스 범위 0x1000~0x1FFF("통신 프로파일 영역")에 매핑된다.이 영역의 처음 몇 개의 엔트리는 다음과 같습니다.

색인 오브젝트명 이름. 유형 기여하다 M/O
0x1000 VAR 디바이스 타입 서명 없음32 M
0x1001 VAR 에러 레지스터 서명 없음8 M
...
0x1008 VAR 제조업체 장치 이름 가시 문자열 컨스턴트 O
...

적절한 툴이 주어지면, 전자 데이터 시트(EDS)에 근거하는 디바이스의 오브젝트 사전의 내용을 디바이스 컨피규레이션 파일(DCF)에 커스터마이즈 해, 디바이스를 특정의 CANopen 네트워크에 통합할 수 있다.CiA 306에[5] 따르면 EDS 파일의 형식은 INI 파일 형식입니다.CiA 311에서[6] 설명하는 XML 스타일의 포맷이 출시될 예정입니다.

의사소통

통신 객체

CANopen의 데이터 링크 계층인 CAN 버스는 11비트 ID, 원격 전송 요청(RTR) 비트, 0~8바이트의 데이터로 구성된 짧은 패키지만 전송할 수 있습니다.CANopen 표준은 11비트 CAN 프레임 ID를 4비트 기능 코드와 7비트 CANopen 노드 ID로 나눕니다.이것에 의해, CANopen 네트워크내의 디바이스수는 127대(0은 브로드캐스트용으로 예약되어 있습니다)로 제한됩니다.CAN 버스 표준(CAN 2.0 B)의 확장에서는 29비트의 확장 프레임 ID가 허용되지만 실제로는 확장 ID 범위가 필요할 정도로 큰 CANopen 네트워크는 거의 볼 수 없습니다.

CANopen에서는 CAN 프레임의 11비트 ID는 Communication Object Identifier(COB-ID)로 알려져 있습니다.전송 충돌이 발생할 경우 CAN 버스에서 사용되는 버스 조정에 의해 ID가 가장 작은 프레임을 지연 없이 먼저 전송할 수 있습니다.시간 크리티컬 기능에 낮은 코드 번호를 사용하면 지연이 최소화됩니다.

CANopen 프레임의 내용:

CAN-ID RTR data 길이 데이터.
길이 11비트 1비트 4비트 0 ~ 8 바이트

11비트 식별자를 가진 데이터 프레임을 "기본 프레임 형식"이라고도 합니다.

디폴트 CAN-ID 매핑에서는 첫 번째 4비트에 함수코드(NMT, SYNC, EMCY, PDO, SDO...)를 어트리뷰트 하여 프레임을 정렬하고 중요한 기능에 우선순위를 부여합니다.단, 이 매핑은 특수한 목적으로 커스터마이즈할 수 있습니다(기본 통신에 필요한 NMT 및 SDO 제외).

기능코드 노드 ID
길이 4비트 7 비트

이 규격은 네트워크 관리 및 SDO 전송에 특정 CAN-ID를 예약합니다.일부 기능 코드 및 CAN-ID는 디바이스 초기화 후 표준 기능에 매핑해야 하지만 나중에 다른 용도로 설정할 수 있습니다.

사전 정의된 연결[7] 세트

단순한 네트워크 구조의 경우 CANopen은 메시지 식별자의 사전 정의된 할당을 지원합니다.

통신 객체 COB-ID 16진수 슬레이브 노드 사양
NMT 노드 제어 000 수신 전용 CiA 301
글로벌 페일 세이프 명령어 001 ? CiA 304
동기 080 수신 전용 CiA 301
비상. 080 + 노드아이디 송신 CiA 301
타임스탬프 100 수신 전용 CiA 301
PDO 180 + 노드아이디
200+노드아이디
280 + 노드아이디
300+노드아이디
380 + 노드아이디
400 + 노드아이디
480 + 노드아이디
500+노드아이디
1. PDO 전송
1. PDO 수령
2. PDO 전송
2. PDO 수령
3. PDO의 송신
3. PDO 수령
4. PDO의 송신
4. PDO 수령
CiA 301
SDO 580 + 노드아이디
600 + 노드아이디
송신
받다
CiA 301
NMT 노드 모니터링(노드 가드/하트비트) 700 + 노드아이디 송신 CiA 301
LSS 7E4
7E5
송신
받다
CiA 305

커뮤니케이션 모델

CANopen 노드 간의 메시징에는 다양한 종류의 통신 모델이 사용됩니다.

마스터/슬레이브 관계에서는 하나의 CAN오픈 노드가 마스터로 지정되며, 마스터 노드는 슬레이브로부터 데이터를 보내거나 요구합니다.NMT 프로토콜은 마스터/슬레이브 통신 모델의 예입니다.

SDO 프로토콜에서 클라이언트/서버 관계는 SDO 클라이언트가 데이터(객체 사전 인덱스 및 서브 인덱스)를 SDO 서버에 송신하고, SDO 서버는 요청된 데이터(특정 인덱스에 있는 객체 사전의 내용)를 포함한 하나 이상의 SDO 패키지로 응답한다.

생산자/소비자 모델은 하트비트 및 노드 가드 프로토콜에서 사용됩니다.생산자/소비자의 푸시 모델에서는 생산자가 특별한 요청 없이 소비자에게 데이터를 보내는 반면, 모델에서는 소비자가 생산자에게 데이터를 요청해야 한다.

프로토콜

네트워크 관리(NMT) 프로토콜

NMT 프로토콜은 상태 시스템 변경 명령(예: 장치 시작 및 중지), 원격 장치 부팅 및 오류 상태를 감지하는 데 사용됩니다.

모듈 제어 프로토콜은 NMT 마스터가 장치 상태를 변경하는 데 사용됩니다.이 프로토콜의 CAN 프레임 COB-ID는 항상 0입니다.즉, 기능 코드0과 노드 ID 0이 있습니다.즉, 네트워크 내의 모든 노드가 이 메시지를 처리합니다.실제 노드 ID(명령어의 수신처)는 메시지의 데이터 부분(두 번째 바이트)에서 지정됩니다.이 경우에도 0을 지정할 수 있습니다.즉, 버스상의 모든 디바이스가 지정된 상태가 됩니다.

COB-ID 데이터 바이트 0 데이터 바이트 1
0x000 요청된 상태 주소 지정 노드
NMT 명령어코드 의미.
0x01 '작동 가능'으로 이동합니다.
0x02 '정지'로 이동
0x80 '사전 작동'으로 이동합니다.
0x81 '노드 재설정'으로 이동합니다.
0x82 '통신 재설정'으로 이동합니다.

하트비트 프로토콜은 네트워크의 노드를 모니터링하고 노드가 활성 상태인지 확인하는 데 사용됩니다.하트비트 생산자(통상은 슬레이브 디바이스)는 바이너리 함수 코드 1110과 그 노드 ID(COB-ID19 = 0x700 + 노드 ID)를 가지는 메시지를 정기적으로 송신합니다.프레임의 데이터 부분에는 노드 상태를 나타내는 바이트가 포함되어 있습니다.하트비트 사용자는 이러한 메시지를 읽습니다.(디바이스 오브젝트 딕셔너리에 정의되어 있는) 일정 시간 내에 메시지가 도착하지 않으면 사용자는 디바이스 리셋이나 오류 표시 등의 조치를 취할 수 있습니다.프레임 형식은 다음과 같습니다.

COB-ID 데이터 바이트 0
0x700 + 노드 ID
NMT 상태 코드 표시된 상태
0x00 기동(초기화 중)
0x04 멈춘
0x05 동작중
0x7f 동작 전

CANopen 장치는 부팅 중에 자동으로 초기화 상태에서 사전 작동 상태로 전환해야 합니다.이 이행이 이루어지면 단일 하트비트 메시지가 버스로 전송됩니다.이것은 부트업 프로토콜입니다.

노드 가드라고 불리는 응답/응답 스타일(풀 모델) 프로토콜은 슬레이브 모니터링을 위해 존재합니다.

SDO(Service Data Object) 프로토콜

SDO 프로토콜은 원격 장치의 개체 사전에서 값을 설정하고 읽는 데 사용됩니다.오브젝트 딕셔너리에 액세스 하는 디바이스는 SDO 서버, 리모트디바이스에 액세스 하는 디바이스는 SDO 클라이언트입니다.통신은 항상 SDO 클라이언트에 의해 개시됩니다.CANopen 용어에서는, SDO 서버로부터 통신을 참조하기 때문에, 오브젝트 사전으로부터의 읽기가 SDO 업로드를 가져오고, 사전 엔트리에의 쓰기가 SDO 다운로드가 된다.

오브젝트 사전 값은 CAN 프레임의 8바이트 제한보다 클 수 있으므로 SDO 프로토콜은 더 긴 메시지의 분할 및 분할 해제를 구현합니다.실제로 SDO 다운로드/업로드와 SDO 블록 다운로드/업로드라는 두 가지 프로토콜이 있습니다.SDO 블록 전송은 프로토콜 오버헤드를 약간 줄이면서 대량의 데이터를 전송할 수 있는 표준에 추가된 새로운 기능입니다.

클라이언트에서 서버로 및 서버에서 클라이언트로 각 SDO 전송 메시지의 COB-ID를 오브젝트 딕셔너리로 설정할 수 있습니다.오브젝트 딕셔너리에는 주소 0x1200~0x127F에 최대 128대의 SDO 서버를 설정할 수 있습니다.마찬가지로 디바이스의 SDO 클라이언트 접속은 변수 0x1280~0x12로 설정할 수 있습니다.FF. 단, 사전 정의된 연결 세트는 부팅 직후(Pre-operational 상태)에도 디바이스를 구성하기 위해 사용할 수 있는SDO 채널을 정의합니다.이 채널의 COB-ID는 수신용 0x600 + 노드 ID 및 송신용 0x580 + 노드 ID입니다.

다운로드를 시작하기 위해 SDO 클라이언트는 다음 데이터를 SDO 채널의 '수신' COB-ID와 함께 CAN 메시지로 전송합니다.

바이트 수: 바이트 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입니다.
  • n은 데이터를 포함하지 않는 메시지 데이터 부분의 바이트 수입니다.e 와 s 가 설정되어 있는 경우에만 유효합니다.
  • e(설정되어 있는 경우)는 신속한 전송을 나타냅니다.즉, 교환되는 모든 데이터가 메시지 내에 포함되어 있습니다.이 비트를 클리어하면 메시지는 데이터가 하나의 메시지에 들어가지 않고 여러 개의 메시지가 사용되는 세그먼트화된 전송이 됩니다.
  • s(설정되어 있는 경우)는 데이터 크기가 n(e가 설정되어 있는 경우) 또는 메시지의 데이터 부분에 지정되어 있음을 나타냅니다.
  • index는 액세스할 데이터의 개체 사전 인덱스입니다.
  • subindex는 오브젝트 사전 변수의 서브 인덱스입니다.
  • 데이터는 빠른 전송 시 업로드되는 데이터(e가 설정됨) 또는 업로드되는 데이터 크기(s가 설정됨, e가 설정되지 않음)를 포함합니다.

프로세스 데이터 객체(PDO) 프로토콜

Process Data Object 프로토콜은 다양한 노드 간에 실시간 데이터를 처리하는 데 사용됩니다.디바이스에서 또는 디바이스로1개의 PDO당 최대 8바이트(64비트)의 데이터를 전송할 수 있습니다.하나의 PDO에 여러 개의 객체 사전 엔트리를 포함할 수 있으며 매핑 및 파라미터 객체 사전 엔트리를 사용하여 하나의 PDO 내의 객체를 구성할 수 있습니다.

PDO 에는, 송수신 PDO(TPDO 및 RPDO)의 2 종류가 있습니다.전자는 디바이스에서 송신되는 데이터(디바이스는 데이터 생산자), 후자는 디바이스로 송신되는 데이터(디바이스는 데이터 소비자)를 위한 것입니다.즉, RPDO를 사용하면 디바이스에 데이터를 전송하고 TPDO를 사용하면 디바이스에서 데이터를 읽을 수 있습니다.사전 정의된 연결 세트에는 4개의 TPDO와 4개의 RPDO에 대한 식별자가 있습니다.구성에서는 512개의 PDO를 사용할 수 있습니다.

PDO 는, 동기 또는 비동기식으로 송신할 수 있습니다.동기 PDO 는 SYNC 메시지 후에 송신되는 반면, 비동기 메시지는 내부 또는 외부 트리거 후에 송신됩니다.예를 들어, 장치에 RTR 플래그가 있는 빈 TPDO를 전송하여 필요한 데이터가 포함된 TPDO를 전송하도록 요청할 수 있습니다(장치가 TPDO 요청을 수락하도록 구성된 경우).

예를 들어, RPDO 를 사용하면, 2 개의 디바이스를 동시에 기동할 수 있습니다.같은 RPDO를 2개 이상의 다른 디바이스에 매핑하여 이들 RPDO가 같은 COB-ID로 매핑되어 있는지 확인해야 합니다.

Synchronization Object(SYNC) 프로토콜

Sync-Producer는 Sync-Consumer에 동기화 신호를 제공합니다.Sync-Consumer는 신호를 수신하면 동기 작업을 시작합니다.

일반적으로 동기 PDO 메시지의 전송 시간을 Sync 객체의 전송 주기성과 결합하여 고정함으로써 센서 장치가 프로세스 변수를 샘플링하도록 배열할 수 있고 액추에이터 장치가 조정된 방식으로 그 작동을 적용할 수 있음을 보증한다.

Sync 객체의 식별자는 인덱스 1005h에서 사용할 수 있습니다.

타임스탬프 오브젝트(TIME) 프로토콜

통상 타임스탬프 오브젝트는 시간을 6바이트필드로 나타냅니다.자정 이후의 밀리초수(최대 27비트, 32비트필드에 저장) 및 1984년 1월1일 이후 부호 없는 16비트 일수(이는 6월7일 오버플로우입니다)입니다.

특히 전송 레이트가 저하된 대규모 네트워크에서는 일부 시간 크리티컬애플리케이션에서는 매우 정확한 동기화가 필요합니다.마이크로초 단위로 로컬클럭을 정확하게 동기화할 필요가 있을 수 있습니다.이는 로컬 클럭의 불가피한 드리프트를 조정하기 위해 특수한 형식의 타임스탬프 메시지를 사용하는 옵션의 고해상도 동기화 프로토콜을 사용하여 실현됩니다.

고해상도 타임스탬프는 unsigned32로 부호화되며 분해능은 1마이크로초입니다이는 타임카운터가 72분마다 재부팅됨을 의미합니다.고해상도 타임스탬프(오브젝트 1013h)를 PDO에 매핑하여 설정합니다.

Emergency Object(EMCY) 프로토콜

긴급 메시지는 디바이스 내부의 치명적인 에러 상황의 발생에 의해 트리거되어 해당 애플리케이션 디바이스에서 높은 우선순위를 가진 다른 디바이스로 송신된다.따라서 인터럽트 유형의 오류 경고에 적합합니다.비상 전보는 '오류 이벤트'당 한 번만 발송할 수 있습니다. 즉, 비상 메시지를 반복해서는 안 됩니다.디바이스에 새로운 에러가 발생하지 않는 한, 그 이상의 긴급 메세지는 송신할 필요가 없습니다.CANopen Communication Profile 정의 비상 오류 코드를 통해 오류 레지스터 및 장치별 추가 정보가 장치 프로파일에 지정됩니다.

초기화

ID 1과 노드 ID 2에 대해 구성된 마스터와 2개의 압력 변환기 슬레이브 간의 통신 샘플 트레이스.

CAN ID data 길이 데이터. 묘사
0x0 2 01 00 마스터는 버스상의 모든 디바이스를 동작 모드로 합니다.
0x80 0 마스터가 SYNC 메시지를 전송하여 디바이스에서 데이터 전송을 트리거합니다.
0x181 4 CD 8201 00 ID 1의 노드(CID-0x180), 판독 압력은 0x0182CD(99021) 패스칼
0x182 4 E5 83 01 00 ID 2의 노드(CID-0x180), 판독 압력은 0x0183E5(99301) 패스칼

전자 데이터 시트

EDS(Electronic Data Sheet)는 CiA306에서 정의된 파일 형식이며, 장치의 통신 동작과 객체 사전 항목을 설명합니다.이를 통해 서비스 도구, 구성 도구, 개발 도구 등의 도구를 사용하여 디바이스를 올바르게 처리할 수 있습니다.

이러한 EDS 파일은 CiA CANopen 적합성 테스트를 통과하기 위해 필수입니다.

2007년 말부터 CiA311에서는 XDD라는 새로운 XML 기반 형식이 정의되어 있습니다.XDD는 ISO 표준 15745에 준거하고 있습니다.

CANopen 용어집

  • PDO: Process Data Object - 입력 및 출력.회전속도, 전압, 주파수, 전류 등의 종류 값
  • SDO: Service Data Object - 구성 설정, 노드 ID, 보레이트, 오프셋, 게인 등.
  • COB-ID: 통신 객체 식별자
  • CAN ID: CAN 식별자.이것은 버스의 모든 CAN 메시지 시작 부분에 있는 11비트 CAN 메시지 식별자입니다.
  • EDS: 전자 데이터 시트.INI 스타일 또는 XML 스타일의 형식 파일입니다.
  • DCF: 디바이스 설정 파일.노드 ID 및 보드환율 설정이 변경된EDS 파일입니다

「 」를 참조해 주세요.

레퍼런스

  1. ^ CiA 301 CAN오픈 애플리케이션 계층 사양, 자동화의 CAN에서 무료로 다운로드 가능
  2. ^ CiA 306 CANopen 전자 데이터 시트(EDS) 사양
  3. ^ CiA 311 CANopen XML-EDS 사양
  4. ^ CANopen Basics에서 미리 정의된 연결 세트 [8]
  5. ^ CiA 401 범용 I/O모듈용 CAN오픈 디바이스 프로파일 사양 (자동화의 CAN에서 무료로 다운로드 가능)
  6. ^ 모션 컨트롤러 및 드라이브용 CiA 402 CANopen 디바이스 프로파일(IEC 61800-7-201/301과 동일)

외부 링크