7 |
Application Layer |
최상위층. 이것은 사용자가 네트워크와 상호 작용하는데 사용되는 소프트웨어를 설명하는 계층이다. 예를 들어 DeviceNet이 해당된다. |
6 |
Presentation Layer |
변환될 데이터의 구문을 서술한다. - 예를 들어 서로 다른 수학 포맷을 사용하는 두 개 시스템들 간의 부동 소수점 수 변환 |
5 |
Session Layer |
하위 계층들에 의해 처리된 패킷들보다 큰 데이터 순차들 처리에 관하여 서술한다. |
4 |
Transport Layer |
두 개 통신 노드들 간의 데이터 전송 품질과 속성을 설명한다. 재전송과 오류 복구같은 문제들을 다룬다. |
3 |
Network Layer |
다양한 데이터 링크를 거쳐 일련의 교환들이 어떻게 한 네트워크에서 임의의 두 개 노드들 간의 데이터를 전송할 수 있는지 설명한다. 라우팅과 어드레싱 같은 문제들을 다룬다. |
2 |
Data Link Layer |
특정 매체를 통해 전송된 데이터 비트의 배열과 조직을 서술한다. 예를 들어, 이 계층은 checksum과 framing을 다룬다. |
1 |
Physical Layer |
교환된 신호들의 해석, 전기적 특성들과 함께 통신 매체의 물리적 특징들도 서술한다. |
물리 계층에서, CAN은 광섬유 또는 꼬임-쌍(가장 보편적) 같은 다양한 종류의 매체를 사용하여 잠정적으로 통신할 수 있다. 꼬임-쌍 시그널링은 각각의 전선에서 서로 다른 전압들을 사용하여 실행되므로(balanced-line signalling 으로도 알려져 있다), 한 전선에서의 신호 전압은 또한 다른 전선에서 전송되지만, 반전된다. 수신기에서, 이 신호는 한 신호를 반전하고 두 개의 신호를 합해서 복원된다 - 이것은 두 개 전선들에 대해 공통적인 것이므로, 이 방법은 버스상에서 발견된 어떤 노이즈도 줄일 수 있다. 바로 이 과정에서 CAN은 자체의 잡음 면역(noise immunity)과 결함 허용(fault tolerance) 기능들을 유도한다. 두 개의 전선들은 CAN_H(or CAN High)와 CAN_L(or CAN Low)로 불린다. 정지 상태(또는 "recessive")에서 CAN_H와 CAN_L은 2.5V에 놓인다. 이것은 디지털 "1"로 표시되며, 또한 "recessive" 비트로도 알려져 있다. 디지털 '0'은 또한 "dominant' 비트로도 알려져 있으며, CAN_L보다 큰 CAN_H에 의해 지시된다. 일반적으로 디지털 '0' 의 경우, 관련된 전압은 CAN_H = 3.5V 그리고 CAN_L = 1.5V이다.
CAN의 특징
CAN의 가장 매력적인 특징들은 다음과 같다:
CAN 칩 제조사
아래에 주요 CAN 칩 메이커들이 요약되어 있다:
Vendor |
Product |
Type |
Comments |
Fujitsu |
F2MC-16L |
2.0B, Integrated |
16 bit |
Hitachi |
HCAN-1 |
Stand-alone |
- |
Intel |
82527 |
2.0B, FullCAN, Stand-alone |
- |
Intermetall |
CCU 3010E |
Integrated |
- |
Mitsubishi |
M37630 E4/M4 |
2.0B, Integrated |
8 bit |
Motorola |
MC68HC05XX |
2.0A, Integrated |
8 bit, XX=4K, 16K or 32K |
National Semiconductors |
COP87L88EB |
2.0B, BasicCAN, Integrated |
8 bit |
NEC |
uPD78F0948 |
2.0B, 8 bit Integrated |
Many variations available |
Philips Semiconductors |
SJA 1000 |
2.0B, BasicCAN, Stand-alone |
C200 was replaced by SJA 1000 |
SGS Thomson |
ST10F167 |
Integrated |
16 bit |
Infineon |
SAE81C90/91 |
2.0B, FullCAN, Stand-alone |
2.0B Passive |
Temic |
TSC8051A11 |
Integrated |
8 bit |
Texas Instruments |
TMS370E08D55 |
2.0B, Integrated |
- |
Toshiba |
TMP88PP87 |
2.0B, Integrated |
8 bit |
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 을 보내는 최초의 노드가 버스 제어를 획득하게 되고 성공적으로 자신의 메시지를 전송하는 것이다.
CAN higher level protocol
CAN higher level protocol(또한 Application layer protocol로도 알려져 있다)은 현재의 하위 CAN 계층(물리 계층과 데이터 링크 계층)들의 "위"에서 실행되는 프로토콜이다. 상위 단계 프로토콜은 CAN의 물리 계층과 데이터 링크 계층들을 개발된 응용 계층의 밑바탕으로 사용한다. 많은 시스템들, (예. 자동차 산업)은 독점적 응용 계층을 사용하지만, 많은 산업들에서, 이 방법은 비용-효과적이지 않는다. 여러 단체들이 시스템 통합을 쉽게 하기 위해서 표준화된 개방형 애플리케이션 계층들을 개발하고 있다.
몇가지 이용할 수 있는 CAN 상위 단계 프로토콜들이다:
Bitwise arbitration
CAN 버스에서 두 개 노드들이 동시에 전송할 때, 한 메시지가 우선 순위를 갖는 방법이 필요합니다 -이것은 'non-destructive bit-wise arbitration'을 사용하여 달성된다.; CAN 버스의 각 노드는 유일한 식별자(ID)를 가지며, 그것은 11비트 또는 29 비트 숫자이다. CAN은 이진 0 이 이진 1 에 우선하도록 결정한다. 따라서 더 낮은 ID 번호 - 더 높은 우선 순위, 그러므로 식별자 0 (즉, 11 비트 이진 0 들)이 버스에서 최고의 우선 순위를 갖는다. 이것을 알아보는 다른 방법으로 메시지 충돌 상황이 있는데, 다른 노드가 1 을 보낼 때 0 을 보내는 최초의 노드가 버스 제어를 획득하게 되고 성공적으로 자신의 메시지를 전송하는 것이다.
BasicCAN과 FullCAN
BasicCAN과 FullCAN 이라 이름 붙여진, 두 개의 일반적인 CAN 접근법이 있다. 이것들은 들어오고 나가는 데이터가 처리되는 방식에서 서로 다르다. 간단히 말하면, BasicCAN은 CAN 메시지 전송과 수신을 처리하기 위해 호스트 CPU를 필요로 하며, 프레임 저장소를 다룬다. FullCAN은 메시지 전송, 메시지 수신 그리고 최대 16개 메시지들의 저장을 CAN 컨트롤러에 맡긴다. CPU는 정보가 필요할 때 CAN 컨트롤러에 문의한다. 이 방식에서, FullCAN은 CAN 처리의 책임을 CPU에서 배제시킨다 - 다른 작업들을 처리할 수 있는 자유를 부여. FullCAN에서 CAN 컨트롤러는 인터럽트가 설정되어 있다면 CPU를 인터럽트 할 수 있다 - 그리고 어떤 지정된 ID를 가진 메시지가 수신된다면 컨트롤러가 CPU를 인터럽트 하면서 "필터링 허용' 같은 작업들을 처리할 수 있다.
Standard CAN 과 Extended CAN
표준 CAN에서는 식별자들이 11비트 길이를 가지며 확장 CAN에서는 식별자들이 29비트 길이를 갖는다. CAN 프로토콜 버전 2.0 에서 명시된 것에 의하면, V2.0A로 컴파일하는 CAN 컨트롤러는 반드시 11-비트 식별자를 가져야만 한다. 반면 V2.0B 에서는, 11비트 또는 29비트 아무 것이나 될 수 있다. V2.0B active를 이용하면, CAN 컨트롤러는 표준 포맷과 확장 포맷 모두를 전송하고 수신할 수 있다. V2.0B passive를 이용하면, CAN 컨트롤러는 표준 프레임을 전송하고 수신하게 되며 확장 프레임은 오류 없이 무시하게 된다.
CAN2.0A 와 CAN2.0B
CAN 2.0A는 표준 CAN을 위한 규격서이다. CAN 2.0B는 확장 CAN을 위한 규격서이다.
DeviceNet
DeviceNet은 무엇인가?
DeviceNet은 산업 디바이스들(limit switches, photoelectric sensors, valve manifolds, motor starter, process sensors, panel displays, operator interfaces 등)을 단일 네트워크를 통해 서로 연결하기 위한 신뢰성있는 CAN 기술을 바탕으로 한 공개형 저가 커뮤니케이션 링크이다. 이것은 연결 수 증가로 인한 오류와 값비싼 배선을 감소시켜준다. 또한 산업 자동화 장치들을 배선하고 설치하는데 드는 비용과 시간은 줄여주는 반면 여러 공급업체들로부터의 믿을 만한 부품 호환성도 제공한다. 직접 연결은 디바이스들 간의 향상된 커뮤니케이션을 제공하며 마찬가지로 유선 I/O 인터페이스들을 통해서는 이용이 불가능하거나 쉽게 접근할 수 없었던 중요한 디바이스-레벨 진단도 제공한다.
이 기술은 미국, 오스트레일리아, 뉴질랜드, 일본, 중국에서 광범위하게 사용되며 유럽 지역에서도 급속히 인기를 얻고 있다. DeviceNet은 자동차 네트워킹을 위한 ISO 표준을 기본으로 하며 계측 제어기 통신망(CAN)으로 알려져, 사실상 모든 산업들에서 사용된다. 예. 자동차, 제조, 농업, 의료 설계 제어, 선박, 항공 우주 등. DeviceNet은 이제 공식적인 CENELEC 표준이다 - EN50325.
누가 DeviceNet을 개발했는가?
ODVA는 DeviceNet 규격서를 관리하고 DeviceNet의 전세계적인 성장을 지원하는 독립적인 공급자 단체이다. ODVA 는 제조업체들과 작업하며 개발자 툴, 개발자 교육, 호환성 테스트, 마케팅 활동들을 통해 돕고 있다. 300여개 이상의 회사들로 구성된 국제적인 회원제를 갖고 있다. ODVA는 DeviceNet 제품 카다로그를 발행하며 특수 종류의 제품들을 위한 Device Profiles을 개발하여 공급자 Special Interest Groups (SIGs)을 지원한다. 미국에 기반을 두는 ODVA는, WMG's CAN Lab을 통하여 유럽에서도 그 기반을 넓혀가고 있으며, 그것은 이제 실제적으로 ODVA Europe을 포함한다. 또 다른 연구소가 일본, 도쿄의 ASTEM RI (Advanced SofTwarE and Mechatronics Research Institute)에 설립되었다.
DeviceNet은 어떻게 동작하는가?
DeviceNet은 프로토콜을 바탕으로 한 연결이다. 즉, 필요한 모든 디바이스들은 정보 교환에 대한 연결 우선을 설정한다. DeviceNet은 이른바 오브젝트 모델링 접근법을 적용한다, 다시 말하며, 각 정보는 서로 다른 오브젝트들에서 구조화된다. (Get 과 Set 같은) 서비스들은 이러한 정보를 추출/교환 하기 위해 이러한 오브젝트들에 적용될 수 있다. 네 개의 기본 오브젝트들은 이러한 정보 교환을 처리하기 위해 필요하다:
Identity object. 디바이스의 식별 정보(제조자 ID, 디바이스 프로파일, 개정판 등)들은 이 오브젝트에 저장된다. 사용자들은 이 오브젝트에 대한 원격 접속으로 특정 오브젝트를 식별할 수 있다.
Message Router. 이 오브젝트는 올바른 목적 오브젝트로 이것을 라우팅하여 수신된 명시적 메시지들을 처리한다.
DeviceNet Object. 이 오브젝트는 모든 DeviceNet 관련 정보들을 저장한다, 즉, MAC ID 와 보오율.
Connection Object. 이 오브젝트는 Explicit Messaging 또는 I/O Messaging 같은 모듈의 연결을 처리한다. 각각의 오브젝트는 attributes(Vender ID같은)라 불리는 자신의 고유한 파라매터들을 갖고 있다. 이러한 속성들은 디바이스의 동작을 지배한다. 연결이 이루어졌을 때, 이 연결을 통해 교환된 모든 데이터들이 통신 연결 인스턴스에 의해 처리되어진다.
Explicit Messaging과 I/O Mesaging
명시적 메시지는 모듈의 정보(제조자, 파라매터 등)를 포함하는 메시지이다. 이 정보는 I/O 메시지보다 상대적으로 덜 중요하다. 따라서 이것은 버스에서 I/O 메시지 교환을 방해하지 않도록 보다 높은 CAN 식별자(600-7BF Hex)를 통해 전송된다. I/O 메시지는 모듈의 실시간 I/O 정보를 포함하고 있는 메시지이다. "실시간" 을 달성하기 위해, 이러한 메시지들은 가능한 빨리 전송되어져야 하며, 따라서 명시적 메시지보다 낮은 CAN 식별자(000-3FF Hex)를 통해 전송된다.
DeviceNet의 특징
DeviceNet의 특징에는 다음이 포함된다; 저비용(저가의 CAN 칩을 바탕), 고속. 이것은 3가지 보오율을 지원한다: 125Kbps, 250Kbps, 500 Kbps 산업 규격의 95%를 충족하는 것으로 알려져 있다. 신뢰성. 이것은 신뢰성을 보증하기 위하여 엄격한 적합 테스트를 통과한 애플리케이션 층들과 훌륭히 검증된 CAN 프로토콜을 사용한다. 최대 64개의 active 노드들을 지원한다. 이론상, 노드는 브리지 시스템(CAN/CAN bridge 또는 다른 gateway)을 사용하여 확장될 수 있다. 간편한 인스톨. 사실상의 "Plug-and-Play".
DeviceNet의 최대 케이블 길이
DeviceNet은 허용 영역내에서 전송된 메시지 하강 전파를 보증하기 위하여 최대 케이블 길이(trunk 와 drop 케이블)를 정의하고 있다. 트렁크 케이블과 드롭 케이블 길이의 상위 한계는 아래의 표와 같습니다.:
Baud Rate |
100% Thick Cable |
100% Thin Cable |
Flat Cable |
125 Kbps |
500 metres |
100 metres |
420 metres |
250 Kbps |
250 metres |
100 metres |
200 metres |
500 Kbps |
100 metres |
100 metres |
100 metres |
Trunk cable length specification
Baud Rate |
Maximum |
Cumulative |
125 Kbps |
6 metres |
156 metres |
250 Kbps |
6 metres |
78 metres |
500 Kbps |
6 metres |
39 metres |
Drop cable length specification
DeviceNet 케이블 설치시 주의사항
트렁크 케이블과 드롭 케이블을 설치하기 위해서는, 몇 가지 사항들을 주의해야 합니다.
UCMM-capable과 UCMM-Incapable 디바이스
UCMM (UnConnected Message Manager) capable 디바이스들은 peer-to-peer 모드에서 데이터를 교환할 수 있는 디바이스들이다. 다른 말로는, 어떤 디바이스가 다른 디바이스들과 동시에 서로 다른 연결을 가질 수 있는 것이다.
UCMM Incapable 디바이스들은 (위와 같이) peer-to-peer 모드에서 동작할 수 없는 디바이스들이다. 이러한 디바이스들은 일반적으로 "Group 2 Only server" 또는 "Group 2 Only slave"와 같이 일컬어진다. 이러한 디바이스들은 한 개의 디바이스(마스터) 이상과는 연결할 수 없다. 다른 말로는, 이것은 한번에 오직 하나의 마스터에 의해서만 소유(할당, 또는 연결)될 수 있으며, 교환되는 어떤 정보도 디바이스와 그것의 마스터 사이에서만 있는 것이다. 마스터는 필요한 경우, 다른 디바이스들로부터의 요청에 응답하기 위해 슬래이브를 프록시하게 된다.
DeviceNet과 호환되는 CAN 송수신기
아래에 DeviceNet 승인 CAN 송수신기 제조업체가 나열되어 있습니다.
Description |
Manufacturer |
82C250/82C251 | Philips Semiconductors |
UN5350 UN5351 (not released) |
Texas Instrument (Unitrode) |
그러나 DeviceNet 규격서에 언급되어 있지 않을지라도, 공급자에게 25 볼트(UC5350과 82C251) 이상의 과전압 방지를 제공하는 CAN 송수신기를 사용할 것을 알려 주어야 한다. DeviceNet이 CAN 송수신기의 유지-전압을 18볼트로 규정한 이유는 Philips Semiconductors(82C251)에서 나온 최초의 CAN 송수신기가 단지 18볼트까지의 과-전압 방지를 가진 것이었기 때문이다.
LIN (Local Interconnect Network)
LIN(Local Interconnect Network)은 차량에서의 분산된 전자 시스템을 위한 저비용의, 직렬 통신 시스템이다. 이것은 CAN과 같은, 현존하는 자동 다중화 네트워크를 보완하기 위해 고안된 것이다. 이 규격에는 프로토콜과 물리 계층의 정의와 더불어 개발 도구와 애플리케이션 소프트웨어에 대한 인터페이스 정의도 들어있다. LIN은 CAN의 대역폭과 다기능이 필요하지 않은 액츄에이터와 스마트 센서를 위한 비용-절감 통신을 가능하게 한다. 이 통신은 SCI (UART) 데이터 포맷, single-master/multiple-slave 개념, single-wire 12V 버스, 안정된 time base가 없는 노드들을 위한 클럭 동기화을 바탕으로 한다. 개발 환경과 맞추어 Serial low cost communication concept의 개념을 표준화하기 위한 LIN 협회가 만들어져서, 자동차 제조업체들과 그들의 공급업체들은 매우 경쟁력있는 가격으로 복잡한 계층적 다중 시스템들을 생성, 실행, 처리할 수 있게 되었다.
LIN의 핵심 기능
LIN communication 개념
LIN 네트워크는 한 개의 마스터 노드와 한 개 혹은 그 이상의 슬래이브 노드들로 이루어진다. 모든 노드들은 하나의 전송과 하나의 수신 작업으로 분할되는 한 개의 슬래이브 커뮤니케이션 작업을 포함하며, 이에 반해 마스터 노드는 모든 부가적인 마스터 전송 작업을 포함한다. active LIN 네트워크에 있는 통신은 항상 마스터 태스크에 의해 초기화된다. 이 마스터는 동기화 break, 동기화 byte, 메시지 식별자로 구성된 메시지 헤더를 전송한다. 정확히 하나의 슬래이브 태스크는 식별자의 수신과 필터링시 활성화되어 메시지 응답 전송을 시작한다. 응답은 2, 4 혹은 8 데이터 바이트와 한 개의 checksum 바이트로 구성된다. 헤더와 응답 파트는 하나의 메시지 프레임을 형성한다.
LIN 메시지 프레임의 구성
LIN 메시지 프레임의 내용은 아래와 같이 나타난다:-
메시지의 식별자는 수신지가 아닌, 메시지의 내용을 나타낸다. 이 통신 개념은 다양한 방식에서의 데이터 교환을 가능하게 한다: 마스터 노드(자신의 슬래이브 태스크를 사용하는)에서 한 개 또는 그 이상의 슬래이브 노드들까지, 그리고 하나의 슬래이브 노드에서 두 개의 마스터 노드와/또는 다른 슬래이브 노드들. 마스터 노드를 통해 라우팅할 필요 없이, 또는 네트워크에서 마스터의 메시지들을 모든 노드들로 방송할 필요 없이, slave에서 slave로 직접 신호들을 커뮤니케이트하는 것이 가능하다. 메시지 프레임의 순서는 마스터로 제어되며 사이클을 형성할 수 있다.
LIN의 대상이 되는 애플리케이션
LIN 버스의 전형적인 애플리케이션들은 (자동차) 문, 핸들, 의자, climate regulation, lighting, rain sensor, 또는 이와 같은 조립 유닛들이다. 이러한 유닛들에서 LIN의 예민한 비용 특성은 스마트 센서, 액츄에이터, 또는 조명 같은 메카트로닉스 요소들의 도입을 가져왔다. 이것들은 차량의 네트워크에 쉽게 연결될 수 있으며 모든 종류의 진단과 서비스들에 접속할 수 있게 된다. LIN 구현 하에서, 흔히 사용되는 아날로그 신호 코딩은 디지털 신호들로 대체될 것이며, 이것은 최적화된 배선 작업을 가져올 것이다.
자동차 애플리케이션들에서, 다음과 같은 것들이 LIN 구현에 이상적이다:-
자동차 지붕 (Vehicle Roof)
자동차 문 (Vehicle Doors)
엔진 (Engine)
비록 LIN이 원래 자동차 애플리케이션을 위해 설계된 것이기는 하지만, 이것은 또한 산업 자동화와 소비 전자제품들을 위한 센서 버스로써도 관심을 받고 있다.
LIN을 지원하는 반도체
현재 다음의 반도체 제조업체들이 LIN 송수신기와 보드상에 LIN 송수신기를 포함한 마이크로컨트롤러를 개발하고 있다:-
LIN Consortium Steering Committee의 주요 회원들
LIN 추가 정보
LIN 컨소티움 웹사이트 http://www.lin-subbus.org
SAE J1939
SAE J1939는 무엇인가?
SAE J1939는 확장 CAN (29비트 식별자)을 사용하는 클래식 C CAN 기본 네트워크로 원래는 그림 1과 같은 일반 트럭과 트레일러 시스템 내의 전자 제어 장치들을 함께 연결하기 위해 개발된 것이였다.
그림 1: J1939로 함께 연결된 전형적인 시스템
J1939 메시지의 포맷
29 비트 CAN ID를 가진 확장 CAN 프레임의 포맷은 그림 2에 나와 있습니다. J1939 프로토콜은 중재 필드의 29비트 ID를 보다 작은 필드들로 깨뜨려서 (그림 2 참고. 29비트의 ID가 11비트와 18비트의 두 개 필드로 나누어짐) 우선 순위, 수신 디바이스와 데이터 내용을 제어한다. SOF, SRR, IDE와 RTR은 이 설명에서는 무시된다. 이것은 J1939-21의 데이터 연결층에서 명시된다.
그림 2: 29비트 CAN ID 를 가진 확장 CAN 프레임의 분할
29비트 CAN ID의 최초 3비트는 가장 높은 우선 순위를 가진 000으로, 메시지 우선 순위를 결정하는데 사용된다. 이것은 당연히 CAN이 작동하는 방식과 일치한다.
CAN ID의 그 다음 비트는 저장되어 전송된 메시지를 위한 0으로 설정되어야 한다. 29비트 CAN ID의 그 다음 9비트는 DP(데이터 페이지)와 PDU 포맷으로 나누어진다. 이러한 것들은 CAN 메시지의 데이터 영역에 어떤 데이터가 포함되는지를 서술한다. DP비트는 page selector이며, 8비트 PDU 포맷은 서로 다른 데이터 내용을 나타내는 256 values를 제공한다. Page 0 (DP=0)은 현재 정의된 모든 정보를 포함하며, Page 1 (DP=1)은 향후 확장을 위해 남겨진다.
29비트 CAN ID의 그 다음 8비트는 PDU 규격이다. PDU 포맷 영역이 0에서 239인 경우, 이 영역은 PDU1으로 알려진 수신지 주소를 포함한다. PDU 포맷 영역이 240에서 255인 경우, 이 영역은 PDU2로 알려진 확장 데이터 내용을 포함한다.
29비트 CAN ID 의 마지막 8비트는 전송 디바이스의 주소를 포함한다. 따라서 256 디바이스들은 단일 J1939네트워크에 속할 수 있다.
그림 3: J1939 영역에서의 CAN 29비트 ID 분할
PDU1
PDU1의 경우, PDU Specific 영역은 메시지의 수신지 주소가 되며 따라서 PDU1은 특정 수신지 주소를 이용하여 직접적인 통신을 허용한다. 이것은 그림 4에 나와있다.
그림 4: PDU1에 관한 J1939 영역에서의 CAN 29비트 ID 분할
J1939를 통해 얼마나 많은 데이터 바이트들이 전송될 수 있는가?
특정 파라매터 그룹을 위해 8 또는 그 이하의 데이터 바이트 전송이 필요하다면, 1 single CAN 프레임을 통해 전송하시오. 전송될 데이터 바이트가 8바이트 이상인 경우, 이것들은 다중 CAN 프레임을 통해 전송된다. 최대 1785 data bytes가 7 바이트의 배수들로 전송될 수 있다. CAN 프레임의 다른 바이트는 하나의 'multiplex' 비트로 사용되며 따라서 총 (255 x 7) = 1785 CAN 프레임들이 전송될 수 있다.
SAE J1939의 애플리케이션
J1939 는 원래 일반 트럭과 트레일러 시스템에서 ECU들을 연결하기 위해 개발되었다. 그러나, 이것의 응용은 건설, 농기계를 거쳐 심해 탐사 차량에까지 널리 확산되고 있다.
J1939 물리 계층
J1939 물리 계층은 J1939/11 규격에서 표준화되었다. J1939 네트워크는 차량의 ECU 각각을 함께 연결하면서 차량 둘레에서 동작하는 단일의, 선형, 차폐된 꼬임 쌍의 전선으로 설계된다. 이 위상은 반사를 줄이는 termination 레지스터를 가진 250Kbaud에서 실행되는 선형 버스로 설계된다. J1939 네트워크는 다중 버스 섹션들로 구성될 수 있으며, 그들 하나 하나는 서로간에 브리지로 연결된다. 이 브리지의 주요 기능은 서로 다른 세그먼트들 간의 전기적 독립을 제공하여 한 시스템의 전기적 실패가 부근 시스템에 그와 같은 실패를 일으키지 않도록 하기 위함이다. 예를 들어, 트레일러 상의 CAN/J1939 시스템의 실패가 트럭의 트랙터 중심 CAN/J1939 제어 시스템의 실패를 일으켜서는 안된다. 더 자세한 사항은 그림 1과 J1939-11을 참고하기 바란다.
J1939에서 사용할 수 있는 표준
J1939 는 SAE에 의해 표준화되었다 (www.sae.org 참고). 다음 규격들을 SAE에서 구입할 수 있다:-
J1939 약자 (Abbreviations)
TTCAN
TTCAN은 무엇인가?
TTCAN은 Time Triggered Controller Area Network를 뜻한다. TTCAN은 자동차 최초 generation drive-by-wire 시스템의 요구에 부응하기 위해 개발되어졌다. 통신 네트워크의 순수한 타임 트리거 실행은 전역적으로 동기화된 시간의 진행에 의해 활동이 결정된다는 것을 의미한다. 통신은 사전-정의된, 다시 말하면 설계시 정의된 시간 스케쥴에 의해 좌우된다.
TTCAN의 주요 특징
TTCAN의 주요 특징은 Basic Cycle로 불리는 시간의 규칙적 반복 사이클을 사용하는 방법과 같은 Time Division Multiplexed Access (TDMA)를 통해 버스 액세스가 제어되는 것이다.
Basic Cycle은 네 종류들 중의 어느 것과 혼합이 될 수 있는 time windows의 고정된 수(즉, 설계시 고정된)로 분할된다; Reference Message, Exclusive Window, Arbitration Window, Free Window.
아래 도표의 Basic Cycle 을 보시오.
전반적인 주요 특징들은 다음과 같습니다:-
Reference Message
이것은 타임 마스터 제어 유닛(global time master)에 의해 전송되며 Basic Cycle의 타이밍을 제어한다. Reference Message는 Basic Cycle의 시작을 나타낸다. 전역 시간(global time)은 4 data bytes에서 전송될 수 있으며 일반 데이터 전송을 위해 이용할 수 있는 나머지 4 data bytes를 남긴다.
Exclusive Window
이것은 전송될 메시지와 데이터를 수용할 수 있을 만큼의 길이를 가진 시간 조각(time slice)이다. 이 Exclusive Window는 단지 한 개의 특정 CAN 메시지를 위해 예비된 것이다.
Arbitration Window
Arbitration Window에서 수많은 노드들이 메시지 전송을 시도하게 된다. 따라서 Arbitration Window에서 버스 액세스를 다투게 되는 노드들은 일반적인 비-파괴 bitwise 중재 방법에 의해 경쟁하게 된다. 그러므로 가장 낮은 CAN 식별자를 가진 메시지가 중재에서 이기게 된다. 보통 CAN 시스템에서, 중재에서 진 노드들은 메시지의 재전송을 시도하게 된다. 이것은 TTCAN에서는 사용할 수 없는데 재전송은 Basic Cycle의 나머지 실행을 망가뜨리기 때문이다.
Free Window
Free Window는 TTCAN 시스템의 향후 확장을 위해 예비된 것이다. 따라서 나중에 더 많은 노드들이 추가될 수 있다.
TTCAN의 표준화 계획이 있나?
현재 TTCAN은 ISO-11898 파트 4에서 표준화가 진행되고 있다.
TTCAN에 알맞은 애플리케이션
현재 이용되고 있는, drive-by-wire 시스템의 최초 세대에 이상적이다. 기계적 백업이 포함된 Throttle-by-wire 또는 Brake-by-wire 시스템.
이것의 대역폭은 효율적이지 않을 수 있으므로 대부분의 steer-by-wire 시스템에는 적합하지 않을 수 있다; 그러한 시스템에 필요한 대역폭은 자동차의 속도가 증가함에 따라 증가된다.
TTCAN을 지원하는 반도체
비록 아직 결과가 알려지지는 않았으나, 많은 회사들이 그들의 CAN 컨트롤러에 time triggered 기능을 제공하고 있다
TTCAN에 대한 어떤 대체 기술들을 이용할 수 있나?
TTCAN은 현재 drive-by-wire 시스템의 최초 세대를 위해 이용할 수 있는 기술인 반면 다른 기술들은 차세대 drive-by-wire의 사실상 업계 표준 최고 자리를 놓고 다투고 있다. 이러한 경쟁 기술들에는 byteflight, Time Triggered Protocol(TTP), FlexRay, EC-Net 이 포함된다. 이러한 기술들 각각은 CAN과 TTCAN의 대역폭을 훨씬 능가하는 대역폭을 보장한다; 5Mbaud부터 최대 25Mbaud.
요약
요약하여, TTCAN의 핵심 이점들은 다음과 같습니다:-
첫댓글 좋은 정보 감사 합니다.