- 1 -

[종합설계2] 졸업작품 - 중간보고서

CAN 통신을 이용한

네트워크 기반 임베디드 기기 다중 제어 시스템

석종수 200611477 gbseok@gmail.com 010-2896-2325유성배 200611124 ysbnim@paran.com 010-6394-2182이현승 200811450 23511@naver.com 010-2620-2781

지도교수님 진현욱 교수님 (서명)

건국대학교 정보통신대학 컴퓨터공학부

- 2 -

목차

- 내용 목차 -

0. 작품명 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 4

1. 작품 개요 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 4

2. 진행 상황 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 4

1) 진행 상황표 및 변경 사항 · · · · · · · · · · · · · · · · · · 4

2) 변경 사유 및 대처 방안 · · · · · · · · · · · · · · · · · · · 4

3. 주요 내용 및 중간 결과 · · · · · · · · · · · · · · · · · · · · · · 5

1) 시스템 구성 · · · · · · · · · · · · · · · · · · · · · · · · · · · 5

2) CAN(Controller Area Network) 통신 · · · · · · · · · · · 13

3) IEEE 1588 - 2008 · · · · · · · · · · · · · · · · · · · · · · · 19

4. 결과물에 대한 기대 효과 · · · · · · · · · · · · · · · · · · · · · 31

5. 추후 계획 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 31

6. 참고 문헌 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 32

- 3 -

[그림 1] PC104보드 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 5

[그림 2] 서보모터와 보드를 연결하는 장치 회로도: · · · · · · · · · · · 7

[그림 3] 서보모터 쪽 컨트롤러 ISP 장치 · · · · · · · · · · · · · · · · · 7

[그림 4] RGB 타입의 LED와 보드를 연결하는 장치 회로도: · · · · · · 9

[그림 5] 서보모터의 제어 :· · · · · · · · · · · · · · · · · · · · · · · · · · · 10

[그림 6] Atmega48 Timer의 신호: · · · · · · · · · · · · · · · · · · · · · · 10

[그림 7] 예상되는 하드웨어 부품 및 그에 대한 견적서 · · · · · · · · 11

[그림 8] 자동차에서 Point-to-Point 방식과 CAN 통신 방식 · · · · · · 13

[그림 9] CAN 통신 데이터 패킷 구조 · · · · · · · · · · · · · · · · · · · · 14

[그림 10] DeviceNet 네트워크 구성 · · · · · · · · · · · · · · · · · · · · · · 15

[그림 11] DeviceNet의 OSI 네트워크 모델· · · · · · · · · · · · · · · · · · 16

[그림 12] CANOpen 요약도 · · · · · · · · · · · · · · · · · · · · · · · · · · · 17

[그림 13] IEEE 1588 기본 구성 · · · · · · · · · · · · · · · · · · · · · · · · 21

[그림 14] 지연 보정 Offset 시간 측정 · · · · · · · · · · · · · · · · · · · · 22

[그림 15] 지연 시간 측정 · · · · · · · · · · · · · · · · · · · · · · · · · · · · 22

[그림 16] Model of a Ordinary Clock · · · · · · · · · · · · · · · · · · · · 26

[그림 17] Model of a Boundary Clock · · · · · · · · · · · · · · · · · · · 27

[그림 18] State machine for a full implementation · · · · · · · · · · · 28

[그림 19] Delay Request-Response Mechanism · · · · · · · · · · · · · · 29

[그림 20] Peer Delay Mechanism · · · · · · · · · · · · · · · · · · · · · · · 30

[표 1] 진행 상황표 및 변경 사항 · · · · · · · · · · · · · · · · · · · · · · · 4

[표 2] 변경 사유 및 대처 방안 · · · · · · · · · · · · · · · · · · · · · · · · · 4

[표 3] 보드와 각 장치간의 GPIO 구성 · · · · · · · · · · · · · · · · · · · · 7

[표 4] DeviceNet의 일반적인 특징 · · · · · · · · · · · · · · · · · · · · · · 16

[표 5] 추후 계획 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 31

- 그림 목차 -

- 표 목차 -

- 4 -

0. 작품명CAN 통신을 이용한 네트워크 기반 임베디드 기기 다중 제어 시스템

1. 작품 개요이 작품은 네트워크 기반 임베디드 기기 다중 제어 시스템으로 IEEE 1588-2008 표준을

통한 클록 동기화를 CAN 통신에 구현하여, 이것이 네트워크 기반 임베디드 기기 다중 제

어 시스템에 효과적으로 적용될 수 있음을 보이고자 한다.

시스템의 성능 향상에 따라 시스템은 복수화, 비대화 되기 때문에 공간이 한정적인 경

우 시스템 크기 감소에 어려움을 겪게 된다. 이러한 문제를 해결하는 수단으로 종래의 1

대 1 네트워크가 아니라 CAN과 같은 버스형 네트워크 시스템이 도입되고 있다. 시스템

내의 데이터 공유가 가능해질 뿐만 아니라 중량을 대폭 삭감할 수 있기 때문이다.

한편 IEEE 1588-2008 프로토콜 표준은 디바이스가 네트워크상에서 가장 정밀하고 정확

한 클록을 활용할 수 있게 하는데, 네트워크상에서 타이밍을 동기화해야 하는 임베디드

시스템에도 이 표준을 적용할 수 있다.

이에 따라 최근 자동차 분야, 산업 분야 등의 시스템에서 실제로 사용되고 있는 CAN

통신을 IEEE 1588-2008 표준을 통한 정교한 클록 동기화를 적용하여 구현한 시스템을 제

안한다.

2. 진행 상황1) 진행 상황표 및 변경 사항

진행률 변경 사항 및 파악된 문제점

시스템 요구사항 분석 75% IEEE 1588 v1에서 IEEE 1488 v2로 변경

개발 환경 구성 80% 환경 구성 중 보드 고장으로 인한 시간적 지연 발생

시스템 설계 80% CANOpen 프로토콜과 함께 DeviceNet 파악 중

시스템 구현 35% 진행 중

[표 1] 진행 상황표 및 변경 사항

2) 변경 사유 및 대처 방안

변경 사유 대처 방안

시스템요구사항 분석

IEEE 1588 v1은 Ethenet 환경에서만 구성되기 때문에, RS485통신과 비슷한 CAN 통신을 지원하지 못함

IEEE 1588 v2 적용

개발 환경 구성 - 수리 후 진행 중

시스템 설계 IEEE 1588 v2 기준 CANOpen과의 적합성 고려 DeviceNet 파악 중

시스템 구현 - -

[표 2] 변경 사유 및 대처 방안

- 5 -

3. 주요 내용 및 중간 결과1) 시스템 구성

(1) 주요 장치

주요 장치인 PC104 보드를 3개 이상 사용하여 노드를 구성한다. 이 노드들은 CAN

통신과 IEEE 1588 표준이 적용된 네트워크 환경에 놓일 것이다.

[그림 1] PC104보드

PC104는 컴퓨터 폼 팩터와 컴퓨터 버스를 모두 정의 하는 PC/104 컨소시엄의 통

제를 받는 임베디드 시스템 표준이다.

사용되는 PC104 보드에는 전체 시스템의 데모를 위해 모터, LED 등의 부수적인 장

치를 추가한다.

(2) 장치의 기본 구성 및 보드와의 통신 수단

현재 보드에서 외부의 일반적인 하드웨어로 통신을 하려면 다음 3가지를 이용할

수 있다. USB(Universal Serial Bus), GPIO(General Purpose Input Output), Serial

COM Port.

우리 프로젝트의 경우는 클럭을 동기화시키는 프로젝트로써, 속도의 저하가 일어날

수 있는 Serial COM Port의 경우는 사용하기 힘들다. 또한, USB의 경우는 외부 장치

의 구현이 힘들고 비용이 많이 들어가기에 구현하기가 힘들다. 따라서 구현하기 용이

하고, 속도의 저하가 적은 GPIO를 이용하기로 하였다.

우리는 실제 외부의 하드웨어 장치의 구동을 동기화시킴으로써, 우리 프로젝트의

효용성을 부각하기로 하였다. 외부 하드웨어 장치의 경우 눈에 보이기 쉬운 것에 초

점을 맞춰 모터와 LED를 사용하는 장치로 하였다.

- 6 -

(3) 모터의 선정

모터의 경우는 가장 시간 반응성을 제어하기 용이하고, 동기화 여부도 눈으로 쉽게

확인 할 수 있는가의 여부를 중점으로 선정하였다.

일반적인 DC/AC 모터 등은 속도자체가 일정한 값이 나오지 않고, 속도가 빨라 눈

으로 확인하기에도 불편한 점이 있다.

스테핑 모터의 경우는 속도자체를 일정하게 만들 수 있고, 눈으로 확인할 수 있을

정도로 속도를 낮추는 것도 가능하다. 하지만, 모터를 사용하기 위해 구성해야하는 하

드웨어가 복잡하고(모터에 6가닥의 전원선이 공급되며, 각각 전원의 세기가 적절히

조정되어야 한다.), 가격이 비싸다. 또한, 모터자체의 속도 동기화 특성이 너무 우수하

기 때문에, 실제 보드에서 동기화가 잘 되었는지를 확인하기 난해하다.

서보 모터의 경우는 속도를 제어하는 것이 아닌, 위치를 제어하는 모터이다. 또한

모터를 시용하기 위해 구성해야 하는 하드웨어가 그리 복잡하지 않고(모터에 전원선

2가닥, 신호선 1가닥이 공급되며, 전원의 세기는 고정이다.), 가격이 다소 저렴하다. 또

한, 위치 제어이므로, 실제 보드에서 동기화가 잘 되었는지를 확인하기 편하다.

따라서, 모터의 경우는 서보모터를 통해 구성하기로 하였다. 또한, 속도는 약간 늦

더라도 힘이 센 걸로 구성하여, 외부의 영향을 받지 않게 하였다.

(4) LED의 선정

LED의 경우는 하나의 LED에 RGB의 색상이 같이 있는 걸로 구성하였다. 따라서, 다

양한 색상을 보드에서 출력할 수 있도록 구성하였다.

(5) 장치의 구성

LED의 경우는 제어가 단순하여, 별도의 컨트롤러가 필요하지 않다. 하지만, 서보모

터의 경우는 신호선에 전달해야 할 신호를 구성해야 하므로, 별도의 컨트롤러가 요구

된다. GPIO에서 신호를 직접 주는 경우도 생각해 볼 수 있으나, 서보모터에 전달해야

할 신호는 수 ms의 짧은 신호를 전달해야하는데, 보드에서 이런 신호를 전달하기에

는 무리가 있다(예를 들어 보드 운영체제에서 스케줄링만 일어나도, 약간의 지연이

발생할 수 있다.). 따라서, 그러한 신호를 만들기 위한 별도의 컨트롤러를 장착하며,

별도의 ISP (In System Programmer)도 요구된다.

따라서. 시연용 하드웨어의 구성은 모터 세트 2개에 LED 세트 1개, 서보모터 쪽 컨

트롤러용 ISP 세트 1개, CAN통신용 버스 구성 세트 1개로 구성할 예정이다.

- 7 -

(6) 보드와 각 장치간의 GPIO 구성

- 보드와 모터간 GPIO 구성 : GPIO에 0~255의 값을 넣으면, 서보의 현재 각도가

0~180도로 조정된다.

- 보드와 LED간 GPIO 구성 : 다음의 표와 같이 신호를 주면 되며, 1이 On, 0이 Off

이다. (각각의 세기 조정은 불가능하다.)

8 7 6 5 4 3 2 1X X R1 G1 B1 R2 G2 B2

[표 3] 보드와 각 장치간의 GPIO 구성

(7) 서보모터와 보드를 연결하는 장치 회로도

CONN PWR 4-H의 경우는 컴퓨터 파워 서플라이 전원방식의 커넥터이다. 여기에

서플라이 전원 케이블을 꽂아 전원을 공급한다. 5V의 전압(빨강)만 사용한다. LED D1

은 전원이 공급되었는지 여부를 나타낸다.

HEADER8의 경우는 보드의 GPIO와 연결되는 커넥터이다. 여기서 GPIO 신호를 받

는다.

별도의 컨트롤러인 Atmega48을 장착하여, 알맞은 신호를 서보모터에 전달한다.

[그림 2] 서보모터와 보드를 연결하는 장치 회로도

- 8 -

(8) 서보모터 쪽 컨트롤러 ISP 장치

컨트롤러인 Atmega48에 프로그램을 굽는 장치이다. 프로그램을 작성한 후, CON6

으로 컴퓨터와 연결하여 프로그램을 굽게 된다.

[그림 3] 서보모터 쪽 컨트롤러 ISP 장치

- 9 -

(9) RGB 타입의 LED와 보드를 연결하는 장치 회로도

CONN PWR 4-H와 HEADER8은 앞서 말한 것과 동일하다.

GPIO 신호만으로도 LED 구동은 가능하나, 오래 사용 시, 안전상의 문제가 있다(보

드의 전기적 손상 및 수명 단축). LED에 직접 신호를 공급하여 켜지 않고, 별도의 장

치를 두어, 보드를 보호한다.

[그림 4] RGB 타입의 LED와 보드를 연결하는 장치 회로도

- 10 -

(10) 서보모터의 제어 방법

[그림 5] 서보모터의 제어

위 그림과 같이 1.5msec일 때는 중심각도(0)로, 0.7msec일 때는 오른쪽(+90),

2.3msec일 때는 왼쪽(-90)으로 동작된다. 서보모터로 현재의 위치를 계속 해서 유지하

게 하기 위해서는 위치 신호를 10ms ~ 20ms정도 반복해서 보내 주어야 한다. 신호

를 받지 못한 상태에서는 이 시간이 지나면, 서보 모터가 정지하게 되며, 따라서 정해

진 위치를 벗어나게 되어도 이를 자동으로 복구하지 못하게 된다.

따라서, 컨트롤러로 이 신호를 보내줘야 하는데, 우리가 컨트롤러로 사용할

Atmega48에서는 Timer를 내장하고 있어, 이를 이용하여 이 신호를 보내면 간편하다.

[그림 6] Atmega48 Timer의 신호

Timer 전체 시간을 10~20ms정도로 세팅한 후에, 8비트의 신호를 GPIO로 받아서,

레지스터 OCRn에 지정한다. Timer는 레지스터 TCNT를 통해 0~255까지 카운트 하게

된다. 카운트 하는 동안 컨트롤러는 TCNT 값과 OCRn을 비교하여, OCRn이 TCNT 값

보다 크면 OCn 핀에 LOW값을 출력하고 OCRn이 TCNT 값보다 작으면 OCn 핀에

HIGH 값을 출력한다. 따라서, 이를 이용하면, 서보모터의 신호를 지정하기 용이하다.

- 11 -

(11) 예상되는 하드웨어 부품 및 그에 대한 견적서

- 12 -

[그림 7] 예상되는 하드웨어 부품 및 그에 대한 견적서

- 13 -

2) CAN(Controller Area Network) 통신(1) 개요

CAN(Controller Area Network) 프로토콜은 고수준의 보안 기능을 갖춘 실시간, 직

렬, 방송 프로토콜이다. CAN 프로토콜은 고속 전송을 위한 ISP11898과 저속 전송을

위한 ISO11519-2에 정의되어 있는 국제 표준이다. CAN은 초기에 자동차에 적용하기

위하여 고안된 직렬 네트워크 통신 방식이다. 최근에는 다양한 산업 분야에 폭 넓게

적용되고 있다.

초기에는 UART 방식을 고려하였으며 UART가 일대일(point to point) 통신이기 때

문에 서로 다른 3개의 ECU 간의 통신 방식으로 적합하지 않아 다중 통신(multi

master communication) 방식이 요구되어 CAN 프로토콜을 개발하게 되었다. 최초의

집적화 된 CAN 부품은 1987년 인텔(Intel)에 의하여 생산되었다.

다음 그림은 자동차의 전자 장치간의 일대일 통신 구성과 CAN 통신 구성을 비교

한 것이다. 일대일 통신의 경우에는 배선 재료비가 증가할 뿐만 아니라 생산시간이

길어지며 신뢰성이 떨어지는 문제가 발생할 수 있다. CAN 통신 배선량을 줄여서 비

용을 줄이고 생산 시간을 단축시키며 신뢰성을 높일 수 있다. 그리고 배선량이 감속

되면서 자동차 디자인을 보다 자유롭게 할 수 있다.

[그림 8] 자동차에서 Point-to-Point 방식과 CAN 통신 방식

- 14 -

(2) CAN 통신의 구현

① 데이터 패킷 구조

[그림 9] CAN 통신 데이터 패킷 구조

② 충돌 탐지 알고리즘 : CSMA/CD-NDBA

CSMA/CD는 충돌 탐지 기능을 가진 Carrier Sense Multiple Access를 나타낸다.

CSMA/CD를 이용하면 버스 주소지정이 버스 상(carrier sense)에서 반송파를 감지

(listening)하여 이루어지며, 단지 버스가 유휴상태일 때 전송된다. 이 방식에서, 다

중 노드들이 동일한 네트워크에 부착되는 것이 가능하다. 충돌이 탐지되면, 재전송

하기 전에 임의 시간이 지날 때까지 전송을 시작했던 모든 노드들이 다시 "listen"

으로 되돌아가게 된다. 그러나 이 기법은 과중하게-로드된 버스에서는 여전히 약간

의 지연을 유발한다.

이러한 지연을 피하기 위해, CAN 버스에서 두 개 노드들이 동시에 전송할 때, 한

개 메시지가 우선 순위를 갖게 하는 방법이 필요하다 - 이것은 'Non-Destructive

Bit-wise Arbitration'을 사용하여 달성된다. CAN 버스의 각 노드는 유일한 식별자

(ID)를 가지며, 그것은 11비트 또는 29 비트 숫자이다. CAN은 이진 0 이 이진 1 에

우선하도록 결정한다. 따라서 더 낮은 ID 번호 - 더 높은 우선 순위, 그러므로 식별

자 0(즉, 11 비트 이진 0 들)이 버스에서 최고의 우선 순위를 갖는다. 이것을 알아

보는 다른 방법으로 메시지 충돌 상황이 있는데, 다른 노드가 1 을 보낼 때 0 을

보내는 최초의 노드가 버스 제어를 획득하게 되고 성공적으로 자신의 메시지를 전

송하는 것이다.

- 15 -

③ 하이 레벨 프로토콜

CAN higher level protocol(또한 Application layer protocol로도 알려져 있다)은

현재의 하위 CAN 계층(물리 계층과 데이터 링크 계층)들의 "위"에서 실행되는 프로

토콜이다. 상위 단계 프로토콜은 CAN의 물리 계층과 데이터 링크 계층들을 개발된

응용 계층의 밑바탕으로 사용한다. 많은 시스템들, (예. 자동차 산업)은 독점적 응용

계층을 사용하지만, 많은 산업들에서, 이 방법은 비용-효과적이지 않는다. 여러 단

체들이 시스템 통합을 쉽게 하기 위해서 표준화된 개방형 애플리케이션 계층들을

개발하고 있다.

몇가지 이용할 수 있는 CAN 상위 단계 프로토콜 중 우리가 주목하는 프로토콜

은 Open DeviceNet Vendors Association의 DeviceNet과 CiA의 CANOpen(subset

of CAL)이다.

(3) DeviceNet

DeviceNet은 CAN 기반의 개방형 제조사 독립형 통신링크이다. 1994년

Allen-Bradley에 의하여 산업용 네트워크의 한 종류로 개발되었다. 산업용 기기(리미

트 스위치, 광전센서, 밸브제어기, 모터 구동기, 인버터, 패널 디스플레이 등)를 네트워

크에 접속함으로써 비용을 줄일 수 있다. 각종 장치(device)를 네트워크에 직접 연결

함으로써 장치레벨의 중요한 진단뿐만 아니라 장치간의 통신을 할 수 있다. 산업용

자동화 기기의 배선과 설치에 드는 비용과 시간을 절약하고 여러 제조사의 동종 구성

요소에 대하여 상호호환성을 제공한다.

[그림 10] DeviceNet 네트워크 구성

- 16 -

[표 4] DeviceNet의 일반적인 특징

DeviceNet 통신 링크는 브로드캐스트 지향의 통신 프로토콜인 CAN을 기반으로 하

고 있다.

[그림 11] DeviceNet의 OSI 네트워크 모델

CAN 프로토콜은 ABS와 에어백 제어와 같이 빠른 응답과 높은 신뢰성을 갖추고 있

다. 사용되고 있는 CAN 제어기는 높은 온도 정격과 잡음에 대하여 강건하다.

- 17 -

(3) CANOpen

CANopen은 CAN-in-Automation (CiA)의 표준을 의미한다. 특히 유럽에서

CANopen은 CAN 기반 산업 시스템 솔루션들을 위한 선도적인 표준으로 간주될 수

있다.

CANopen 표준의 핵심 요소는 object dictionary (OD)를 통한 디바이스 기능성의

서술이다.. 이 object dictionary는 두 부분으로 나뉘는데 첫 번째 부분은 통신 파라메

터들과 함께 디바이스 식별, 제조업체 이름 등과 같은 일반적인 디바이스 정보들을

포함하고, 두 번째 부분은 특수한 디바이스 기능성을 기술한다..

16-Bit 인덱스와 8-Bit 하위-인덱스가 object dictionary에서 entry ("object")를 식별

한다. object dictionary에서 이 엔트리들은 input과 output 신호들, 디바이스 파라메

터들, 디바이스 함수들 또는 네트워크 변수들과 같은, 디바이스의 "Application

Objects"에 표준화된 액세스를 제공한다.

[그림 12] CANOpen 요약도

CANopen 디바이스의 기능과 특성은 ASCII 포맷을 이용한 "Electronic Data Sheet

(EDS)"를 사용하여 기술될 수 있다. 이 경우 EDS는 템플릿의 일종으로 이해되어야만

한다. 실제 디바이스 셋팅은 "Device Configuration File (DCF)"로 불리는 것에 의하여

기술되어지고. EDS와 DCF는 data carrier의 형태로 제공될 수 있으며, 이것은 디바이

스 내의 저장된 것 또는 인터넷에서 다운로드될 수 있다.

또한 다른 잘 알려진 field bus와 유사하게 CANopen은 두 개의 기본 데이터 전송

체계들을 구분한다 : "Process data Objects (PDO)"라 불리는 것을 통하는 작은 처리

데이터 부분들의 고속 교환과 "Service data Objects (SDO)"로 불리는 것을 통한

object dictionnary에서의 엔트리들에 대한 액세스. 후자의 것들은 일반적으로 보다

큰 데이터 부분들의 전송을 위한 것 뿐만 아니라 디바이스 구성 동안에 파라메터들의

- 18 -

전송을 위하여 주로 사용된다.

Process data 오브젝트 전송들은 대개 추가적인 프로토콜 오버헤드가 없는

broadcast 오브젝트들로 요청되거나 또는 순환의, 트리거된 이벤트들이다. PDO는 최

대 8 data bytes의 전송을 위해 사용될 수 있다. 동기화 메시지들과 관련하여, PDO의

수용과 마찬가지로 전송은 전체 네트워크를 통하여 동기화될 수 있다 ("Synchronous

PDO"). 한 개의 PDO에 대한 애플리케이션 오브젝트의 할당 (Transmission 오브젝트)

은 object dictionnary에 저장된 구조 기술 ("PDO Mapping")을 통해 조정 가능하며,

따라서 관련 애플리케이션 필수 요건에 맞게 디바이스 조정이 허용된다.

SDO의 전송은 두 개의 네트워크 노드들 사이에서 일대일 (peer-to-peer) 연결 형태

로 두 개 CAN 오브젝트들과 함께 승인된 데이터 전송으로서 수행된다. 통신 object

dictionnary 엔트리들의 주소 지정은 object dictionnary 엔트리의 인덱스와 서브-인덱

스를 공급하여 실행된다. 전송된 메시지들은 매우 큰 길이가 될 수도 있고 SDO 메시

지의 전송은 추가적인 프로토콜 오버헤드를 포함한다.

- 19 -

3) IEEE 1588 - 2008(1) 개요

IEEE 1588 표준은 “Standard for a Precision Clock Synchronization Protocol for N

etworked Measurement and Control Systems”라고 공식적으로 인정되어있다.

버전 1은 2002년에 나온 IEEE 1588-2002이고, 최근 2008년에 버전 2인 IEEE 1588-

2008로 개정되었다. 이 새 버전은 정교성, 정확성, 견고성이 개선되었으나, 이전의 버

전 1과 호환되지 않는다.

일반적으로 이더넷에서는 패킷 전송 방식으로 원격지와 통신이 이루어진다. 이 방

식의 장점은 하나의 물리적인 선로를 여러 매체들이 공유하여 전송을 한다는 것. 회

로방식 및 시분할방식 등 비교되는 여러 기술에 비해 선로 이용도가 높고 주어진 가

변적인 데이터를 보낼 수 있어 가장 일반적인 통신 방법으로 발전해 왔다.

그 결과 이더넷은 사용자 급증에 따라 보다 빠른 대역폭을 요구 받게 되며, 확장된

역량을 바탕으로 데이터 위주에서 음성·영상·게임 등 다양한 애플리케이션·콘텐츠를

수용할 수 있게 됐다.

하지만 이처럼 다양한 방식의 애플리케이션을 수용할 수 있음에도 불구하고, 근본

적인 동작 원리인 패킷 방식이 가지고 있는 한계 즉, 원격지와의 정확한 동기화를 이

루어야 하는 애플리케이션에서는 그 수용의 한계를 가지고 있었다. 이에 IEEE에서는

타임 프로토콜의 표준화를 추진했고, IEEE1588이 이를 근간으로 탄생하게 된다.

(2) 응용 분야

동기식 이더넷은 현존하는 다양한 동기식 시스템용 애플리케이션에 쉽고 표준화된

방식으로 적용을 할 수 있다. 예를 들면 컨베이어 시스템을 이용하는 공장자동화, GP

S 수신이 불가능한 음영 지역에 필요한 망동기 신호, 정확한 계약 순서가 필요한 금

융시스템, 군사시스템, 차량 멀티미디어 시스템 등에 유용하다.

(3) 동기화 방법

원격지와의 클럭을 동기화시키는 방법은 하드웨어적인 방법과 소프트웨어적인 방법

으로 나눌 수 있다.

- 하드웨어 방법 : 이것은 자신의 오실레이터 클럭과 다른 시스템으로부터 인가된

클럭 신호를 이용하여 하나 또는 여러 개의 클럭 신호를 도출해 내는 방법. 보편

적이기 때문에 회로방식이나 시분할 방식에서 데이터를 전송하기 위한 용도로 많

이 활용된다.

- 소프트웨어 방법 : 외부의 일반적인 클럭 소스에서 출력되는 주파수 정보를 통해

애플리케이션 단계에서 클럭을 동기화 시키는 방법. 소프트웨어 측면에서 시간은

스칼라(Scalar)이다. 따라서 크기를 가지며 비교 가능한 방법으로 표현할 수 있다.

보다 정의된 클럭 정보를 얻고자 한다면, 에폭(EPOCH)이라는 기준을 가지고 상

대값으로 절대값을 표현할 수도 있다.

- 20 -

서로 다른 위치의 두 시스템이 각각의 방법으로 동기화를 이룬다는 것은 불가능에

가깝다. 처해진 환경이나 본래의 특성이 같을 수 없기 때문. 이를 해결하기 위한 한정

적인 몇 가지 대안이 있다. 그것은 다음과 같다.

- 모든 시스템이 하나의 오실레이터를 사용한다. 다만, 거리의 문제를 극복해야 한

다.

- 모든 시스템의 오실레이터 특성을 동일하게 만든다.

- 모든 시스템이 이더넷과 같이 서로 연결이 되어 있다면, 각각의 클럭을 하나의

마스터 클럭에 맞춰 조절한다.

IEEE1588은 이 마지막 방법을 구현하기 위해 출발한다. 물론 기존의 NTP(Network

Time Protocol)이 존재하지만 수 미리초의 오차로 인해 정밀을 요구하는 솔루션에는

적합하지 않다.

(4) IEEE 1588 - 2008

IEEE1588은 이더넷과 같이 지리적으로 분산된 시스템의 동기를 정밀하게 맞추기

위한 방안이다. 가장 좋은 방법은 기준이 되는 클럭 즉, 마스터 클럭에서 모든 슬레이

브 디바이스에 클럭을 보내 이를 동기화 시키는 것. 하지만 이것은 다음과 같은 몇

가지 한계를 가지고 있다.

- 마스터 클럭은 동일한 시간 간격으로 슬레이브 디바이스에 클럭을 전송할 수 없

다. 따라서 각 슬레이브 디바이스는 독립된 자신의 클럭을 통해 이를 보정해야

한다. 이 때 문제는 각각 사용하는 클럭 소스의 성능 차이로 인해 오차가 생길

수 있다는 부분이다.

- 마스터 클럭에서 슬레이브 클럭까지의 물리적인 거리는 각기 다르기 때문에 동일

한 시간을 가질 수 없다.

- 클럭이 전달되는 통로에 의해 일정의 지연시간을 가지게 된다.

정확히 말하자면 IEEE1588은 두 번째와 세 번째 방식의 오차를 최소화하기 위해

특화되었다고 볼 수 있다. 물론 거리에 대한 사항에 한계를 둔다면 첫 번째 사항도

상당히 줄일 수 있다.

- 21 -

IEEE 1588의 기본 구성은 다음과 같다.

[그림 13] IEEE 1588 기본 구성

(5) 의미

이더넷 네트워크에서 동기 클럭을 갖는다는 것은 보다 다양한 분야에 이더넷이 진

출할 수 있다는 것을 의미한다. 이더넷은 그 동안의 확장성이나 검증된 많은 장점을

가지고 있음에도 불구하고 노드간 정밀한 송수신 시간을 요구하거나 일정한 지연을

요구하는 시스템에서 적용되는데 부정적이었다.

하지만 IEEE1588v2를 기반으로 하는 패킷 전송은 이 한계를 극복하는 좋은 사례로

남을 수 있다. 특히 멀티캐스팅을 기초로 하는 멀티미디어 시스템에서의 도입은 통신

선과 멀티미디어용 선이 분리된 것을 통합시킬 수 있어 원가 절감 및 선로 관리에 유

용해진다.

(6) 적용

① IEEE1588 동작 방법

IEEE1588v1(2002) 버전에서는 통신 지연을 측정하기 위해 Sync, Followup, Delay

Req, DelayResp 등 4개의 이벤트 메시지(Event-Message)를 사용하지만 IEEE1588v2

(2008)에서는 P2P(Peer to Peer) 지연을 측정하기 위해 PdelayReq, PdelayResp, Pd

elay-Followup 등 3개의 메시지를 추가했다. 이 이벤트 메시지가 디바이스를 떠나

거나 도달할 때, 로컬 시간이 기록된 타임스탬프(Time-Stamp) 정보를 포함하여 전

송 또는 수신된다.

타임스탬프 패킷을 구현하는 방법은 소프트웨어 및 하드웨어 등 두 가지 경우의

수가 있다. 소프트웨어적인 방법은 패킷을 수신 또는 송신하기 직전의 인터럽트를

기준으로 ISR (Interrupt service routine)로 구현하는 것이고, 하드웨어적인 방식은

하드웨어적으로 구현하여 타임 스탬프를 전달하는 것으로, 보다 정밀하다.

- 22 -

[그림 14] 지연 보정 Offset 시간 측정

위 그림은 마스터에서 슬레이브까지의 지연 시간을 측정하는 방법을 도식화 한

것이다.

- 마스터에서는 TM1의 시간정보를 싱크 메시지에 넣어 보낸다.

- 슬레이브에서는 메시지가 도착한 시간 즉 TS1을 저장한다.

- 마스터에서는 이어 TM1시간 정보가 담겨있는 FollowUP 메시지를 보낸다. 이를

수신한 슬레이브는 마스터와의 지연 시간을 슬레이브 클럭으로 추정해 낼 수

있다.

슬레이브에서 마스터까지의 지연은 위의 절차가 완료된 후, DelayReq에 슬레이브

의 로컬 시간을 마스터로 보내고 메시지 출발 시간을 기록한 다음 마스터로부터 D

elayResp를 기다린다. 마스터는 DelayReq가 수신된 시간과 송신하는 시간을 Delay

Resp에 넣어 슬레이브로 전송한다.

위의 방법으로 측정된 지연은 PPS(Pulse per Second)형태이고, GPIO로 출력된다.

[그림 15] 지연 시간 측정

- 23 -

② IEEE1588 Message Classes

IEEE 1588 프로토콜은 이벤트(Event)와 일반적(General)인 메시지를 사용한다. 이

벤트 메시지는 타임스탬프를 계산하기위해 송수신되는 시간 타임을 포함한 메시지

를 나타낸다. 일반적 메시지는 타임스탬프를 계산하는데 사용되지 않는 메시지를

나타낸다.

이벤트 메시지(Event Message)는 다음 4개의 메시지를 포함한다.

a) Sync

BitsOctets Offset

7 6 5 4 3 2 1 0

header 34 0

originTimestamp 10 34

b) Delay_Req

BitsOctets Offset

7 6 5 4 3 2 1 0

header 34 0

originTimestamp 10 34

c) Pdelay_Req

BitsOctets Offset

7 6 5 4 3 2 1 0

header 34 0

originTimestamp 10 34

reserved 10 44

d) Pdelay_Resp

BitsOctets Offset

7 6 5 4 3 2 1 0

header 34 0

requestReceiptTimestamp 10 34

requestingPortIdentity 10 44

- 24 -

일반적 메시지(General Message)는 다음 6개의 메시지를 포함한다.

a) Announce

BitsOctets Offset

7 6 5 4 3 2 1 0

header 34 0

originTimestamp 10 34

currentUtcOffset 2 44

reserved 1 46

grandmasterPriority1 1 47

grandmasterClockQuality 4 48

grandmasterPriority2 1 52

grandmasterIdentity 8 53

stepsRemoved 2 61

timeSource 1 63

b) Follow_up

BitsOctets Offset

7 6 5 4 3 2 1 0

header 34 0

preciseOriginTimestamp 10 34

c) Delay_Resp

BitsOctets Offset

7 6 5 4 3 2 1 0

header 34 0

receiveTimestamp 10 34

requestingPortIdentity 10 44

d) Pdelay_Resp_Follow_Up

BitsOctets Offset

7 6 5 4 3 2 1 0

header 34 0

responseOriginTimestamp 10 34

requestingPortIdentity 10 44

- 25 -

e) Management

BitsOctets Offset

7 6 5 4 3 2 1 0

header 34 0

targetPortIdentity 10 34

startingBoundaryHops 1 44

boundaryHops 1 45

reserved actionField 1 46

reserved 1 47

managementTLV M 48

f) Signaling

BitsOctets Offset

7 6 5 4 3 2 1 0

header 34 0

targetPortIdentity 10 34

One or more TLVs M 44

Sync, Delay_Req, Follow_Up, Delay_Resp 메시지는 Delay Request-Response 라

는 통신 선로간의 딜레이를 계산하는 메커니즘을 사용하여 Ordinary Clock과 Boun

dary Clock을 동기화하는데 필요한 정보를 담아 통신하는데에 쓰인다.

Pdelay_Req, Pdelay_Resp, Rdelay_Resp_Follow_Up 메시지는 Link Delay를 측정하

는데 사용된다. Link Delay는 P2P(Peer-to-Peer) 전송으로 구성된 시스템에서 Sync

메시지와 Follow_Up 메시지가 올바르고 정확한 정보를 포함하는지 확인하는 곳에

쓰인다. Peer Delay 메커니즘으로 구현된 Ordinary Clock과 Boundary Clock은 Sync

메시지와 Follow_Up 메시지, 측정된 Link Delay 정보를 이용하여 시스템을 동기화

할 수 있다.

Announce 메시지는 동기화 체계를 수립하는데 일반적으로 사용되는 메시지이다.

Management 메시지는 동기화된 클럭을 유지하는데 필요한 IEEE 1588 데이터

셋의 정보를 업데이트 및 유지, 관리 하는데 사용되는 메시지를 나타낸다. 또한 Ma

nagement 메시지는 노드와 Clock 사이에 사용되며, IEEE 1588 프로토콜을 초기화

하고 관리하는데에 역시 사용된다.

Signal 메시지는 언급된 이 외의 목적으로 사용되는 메시지를 나타낸다. 예를 들

어, 마스터와 슬레이브간의 유니캐스트(Unicast) 메시지를 관리할 때 사용된다.

③ Device Type

IEEE 1588 프로토콜의 디바이스 타입은 다음의 5개와 같다.

a) Ordinary Clock

b) Boundary Clock

c) End-to-End Transparent Clock

- 26 -

d) Peer-to-Peer Transpartent Clock

e) Management node

이 상위 5개의 디바이스 타입은 한 개 또는 그 이상의 프로토콜로 구현된다.

Delay Request-Response 메커니즘, Peer Delay 메커니즘, 이 두 개의 메커니즘은

노드들 포트간의 전파 딜레이(Propagation Delay)를 측정하는데 사용된다. Delay R

equest-Response 메커니즘은 Sync, Delay_Req, Delay_Resp, Follow_Up 메시지를 사

용하고, Peer Delay 메커니즘은 Pdelay_Req, Pdelay_Resp, Pdelay_Resp_Follow_Up

를 사용한다.

Ordinary Clock과 Boundary Clock은 이 두 메커니즘을 통하여 구현될 수 있다.

<A> Ordinary Clock

[그림 16] Model of a Ordinary Clock

Ordinary Clock은 한 개의 물리적 포트위에 있는 2개의 논리적 인터페이스를 통

해 통신한다. 이벤트 인터페이스(Event Interface)는 Local Clock의 값을 기준으로 한

타임스탬프를 생성하기 위해 이벤트 메시지를 주고받을 수 있다. 일반 인터페이스

(Genaral Interface)는 일반 메시지(General Message)를 주고 받는다. Ordinary Cloc

k은 시스템에서 Grandmaster Clock이 되거나, Master-Slave 계층에서 Slave Clock

이 될 수 있다.

- 27 -

<B> Boundary Clock

Boundary Clock은 일반적으로 여러개의 물리적 포트를 가지고, 각각의 물리적 포

트는 두 개의 논리적 인터페이스(Event/General)를 통하여 통신한다. 또한 Boundary

Clock은 네트워크 요소로써 사용되지만 센서나 엑츄에이터 같은 어플리케이션 장비

와 연관되지는 않는다.

[그림 17] Model of a Boundary Clock

- 28 -

④ IEEE 1588을 위한 State Machine

IEEE 1588 프로토콜 위에서의 각 노드간 클럭 동기화를 위한 동작 상태는 다음

과 같다.

[그림 18] State machine for a full implementation

- 29 -

⑤ Delay Request-Response Mechanism

Sync, Delay_Req, Delay_Resp, Follow_Up 메시지를 사용하는 Delay Request-Resp

onse 메커니즘은 한쌍의 노드 포트들 간의 동신 딜레이를 측정한다. 이 메커니즘은

두 포트간의 클럭과는 독립적으로 동작한다.

[그림 19] Delay Request-Response Mechanism

- 30 -

⑥ Peer Delay Mechanism

Peer Delay 메커니즘은 포트간 전파 시간(Propagation Time)을 측정한다.

[그림 20] Peer Delay Mechanism

- 31 -

4. 결과물에 대한 기대 효과이 시스템은 네트워크 기반 임베디드 기기 다중 제어 시스템에서 동기화된 통신을 보이

는 것을 최종 목표로 한다. 시스템에 IEEE 1588 표준을 통한 클록 동기화가 적용된 CAN

통신에 구현하여 3개의 노드 간에 원활한 통신이 가능하도록 하고자 한다. CAN 통신과

IEEE 1588 표준 사이에는 CAN 응용으로 DeviceNet 또는 CANOpen이 사용될 것이다.

CAN 통신을 위한 노드에는 PC104 보드 등의 하드웨어 인터페이스가 사용될 것이고,

데모를 위해 보드에 모터, LED 등의 부수적인 장치가 추가 되어 통신 과정을 가시화할 것

이다.

5. 추후 계획

8 9 10진행 예정 사항

3 4 5 1 2 3 4 1 2 3

시스템

요구사항 분석IEEE 1588 v2 적용

개발환경 구성 구성 완료

시스템 설계 DeviceNet 파악 및 적용

시스템 구현 구현 완료

테스트 및

보완테스팅

데모 시연 및

발표발표 자료 완성 및 시연

[표 5] 추후 계획

- 32 -

6. 참고 문헌 - 『AT90CAN128을 이용한 CAN 통신 실무』. (2009). 하이버스(주) 기술연구소, p.15~23.

- Factory Story. (2010). IEEE 1588 PTP

(http://torystory.tistory.com/53).

- IEEE1588.com. (2010). Functional Principle of PTP

(http://www.ieee1588.com/IEEE1588_Functional_Principle_of_PTP.html)

- IEEE Standard for a Precision Clock Synchronization Protocol for Networked

Measurement and Control Systems.pdf

(http://standards.ieee.org, http://ieeexplore.ieee.org/xpl/standrads.jsp)

- ESD. (2011). can-pc104/200

(http://www.esd.eu/german/products/CAN/can-pc104-200_e.htm)

- HES-088 서보모터 데이터시트

- Atmega48 데이터 시트

- 디바이스마트

(http://devicemart.co.kr)