차량에서의 네트워크
아래의 그림은 다양한 전자 시스템이 결합된, 전형적인 현대 고급차의 내장을 보여준다. 이러한 정도의 분리된 시스템들의 경우, 이것들을 함께 연결하기 위해 보통 사용되는 배선 장치는 믿어지지 않을 정도의 엄청난 케이블들을 필요로 하며, 이것은 전체적인 차량의 무게와 제조 비용에서 상당한 부분을 차지하게 된다.
이 문제의 확실한 해결책은 이러한 모든 시스템들을 차량 둘레에서 실행되는 한 개 혹은 두 개의 전선들로 구성된, 사무실의 데스크탑 PC들을 함께 연결한 것 같은 방식인, 하나의 공통 네트워크 버스에 연결하는 것이다. 이것은 차량에서의 배선 양을 즉각 획기적으로 감소시키며, 네트워크 인터페이스 칩들이 아주 저렴한 이상, 차량의 총 제조 비용도 감소된다.
이것이 바로 계측 제어기 통신망(CAN)의 숨은 개념이다. 그러나 그토록 많은 시스템들과 우선 순위들 변경으로 서로 다른 응답 시간들과 우선 순위들을 처리하기 위해서는 별도의 독립적인 네트워크들을 사용하는 것이 마땅하다는 것을 금방 알게 된다(예를 들어 사용자는 썬루프 컨트롤러가 우선 순위를 갖는 것을 원하지 않거나 블록 정보, 에어백 개발 시스템을 원하지 않을 수도 있다!). 네트워크의 서로 다른 종류들은 크게 4개의 클래스 범주들로 나눌 수 있다:
클래스 A 네트워크들은 전자 부트 작동기(electronic boot release), 전동 거울 조정장치, 비 탐지, 썬루프, 기상 관리 등과 같은 편의 기능 또는 고급 기능들에 일반적으로 사용되며 10 kbit/s 미만으로 작동한다.
클래스 B 네트워크들은 파워 윈도우, 좌석 조절장치, 계기 같은 정보의 일반적인 전송을 담당한다. 이것들은 10 ~ 125 kbit/s 정도로 실행된다.
클래스 C 네트워크들은 파워 트레인, 안정성 제어(ABS, 견인 제어, 액티브 서스펜션), 엔진 관리, 변속 같은 실시간 제어 애플리케이션 - 정보의 빠른 응답 시간 또는 전송이 필요한 모든 애플리케이션- 들에서 사용된다. 이것들은 125 kbit/s부터 최대 1Mbit/s 로 작동합니다.
클래스 D 네트워크들은 인터넷, 디지털 TV, x-by-wire 같은 애플리케이션들에서 사용되며, 일반적으로 1Mbit/s 이상의 빠른 속도에서 실행되는 것들이다.
CAN (Controller Area Network)
CAN은 무엇인가?
CAN 버스는 마이크로컨트롤러들 간의 통신을 위해 설계되었다 - 자동차 분야에서 이것은 엔진 관리 시스템, 변속장치 제어, 계기 팩, 그리고 차체 전자 기술 같은 온-보드 전자 제어 장치(ECUs)들 간의 정보 교환에 사용되곤 한다.
이론적으로 하나의 단일 네트워크에는 최대 2032개의 디바이스들이 한 개의 CAN 버스(한 개의 ID 번호를 가진 한 개의 노드를 가정)에 연결될 수 있다. 그러나 하드웨어(즉, 송수신기)의 현실적인 제한으로 인해, 이것은 실제적으로는 한 개의 단일 네트워크에 최대 110개 노드들을(필립스 82C250 CAN 컨트롤러를 사용) 허용한다. CAN은 최대 1 Mbit/sec 의 데이터 통신을 제공하여, 실시간 제어를 촉진한다. 덧붙여, 오류 제한(Error Confinement)과 오류 탐색(Error Detection) 기능들은 noise-critical 환경들에서의 신뢰성을 더욱 높여준다.
누가 CAN을 개발했는가?
Controller Area Network는 원래 1980년대 후반에 자동차 산업을 위해 독일 회사 Robert Bosch GmbH에 의해 개발되었다. 그들이 CAN을 개발하게 된 동기는 - 고객들의 그들 차량에 대한 더욱더 많은 기능상의 요구들이, 대부분은 전자식으로 작동되며 더욱 많은 배선을 의미하는, 또 다른 온-보드 시스템과의 어떤 통신 형태를 필요로 하는 것이기 때문에, 현대 자동차에서의 내부-ECU 통신에 필요한 꾸준히 증가하고 있는 거대한 배선 작업의 문제에 대한 해결책을 제공하기 위해서였다.
그들의 결론은 모든 온-보드 주변장치들이 부착될 수 있는 하나의 단일 네트워크 버스를 설계하는 것이였다. 1993년 CAN은 표준 ISO 11898(고속 애플리케이션용)과 ISO 11519(저속 애플리케이션용)가 되었다. 이것은 다중-마스터 직렬 통신 버스로 이것의 기본 설계 사양은 고속, 높은 잡음 면역성, 그리고 오류-검출 기능들에 적합하게 되어있다. 이러한 기능들의 결과로, CAN 버스는 또한 제조 산업과 항공 우주 산업들에서도 폭넓게 사용되게 되었다.
CAN은 어떻게 동작하는가?
CAN 통신 프로토콜은 CAN 버스에서 디바이스들 통신 사이로 데이터가 전달되는 방법을 명시한다. 이것은 ISO의 개방형 시스템 상호연결 모델(Open System Interconnection model)을 따르며, 이 모델은 통신 네트워크 표준인 일곱 계층으로 되어 있다. 이 OSI 모델은 두 개 네트워크 노드들 간의 층화된 통신 시스템을 기술하며, 이론상 각 계층은 로컬 모드에서는 오직 자신의 직접적인 위, 아래의 계층들과 통신할 수 있으며, 원격 모드에서는 동등한 계층과 통신할 수 있다.
OSI 모델의 계층들은 아래의 표에 나와 있다. 사실 CAN 프로토콜은 OSI 모델의 가장 낮은 두 개 층들로 설명될 수 있다 - 데이터 링크 계층과 물리적 계층. 애플리케이션 계층 프로토콜들은 개별적인 CAN 사용자들에 의해 개발된 독점 구조, 또는 특정 산업 내에서 사용되는 신생 표준들 중의 하나가 될 수 있다. 프로세스-제어/제조 분야에서 사용되는 공통적인 애플리케이션 표준 층은 DeviceNet으로, 이것은 PLC의 네트워킹과 지능 센서들 그리고 액츄에이터에 특히 적합하다. 자동차 산업에서 많은 제조업체들은 그들 자신의 독점적인 표준을 사용하고 있다.
|
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의 가장 매력적인 특징들은 다음과 같다:
-
저비용.
-
극대화된 견고성
-
빠른 데이터 전송 속도(최대 1MBit/sec)
-
신뢰성. 탁월한 오류 처리와 오류 제한 기능들
-
결함 메시지들의 자동적인 재-전송
-
물리적으로 결함이 추정되는 노드들의 자동적인 버스 연결절단
-
기능위주의 어드레싱 - 데이터 메시지들은 소스 혹은 목적지 주소들을 포함하지 않으며, 그들의 함수 그리고(또는) 우선순위와 연관된 식별자들만을 포함한다.
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 상위 단계 프로토콜들이다:
-
Open DeviceNet Vendors Association의 DeviceNet
-
Honeywell의 Smart Distributed System(SDS)
-
CiA의 CAN Application Layer(CAL)
-
CiA의 CANOpen(subset of CAL)
-
스웨덴 Kvaser의 CANKingdom
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 케이블 설치시 주의사항
트렁크 케이블과 드롭 케이블을 설치하기 위해서는, 몇 가지 사항들을 주의해야 합니다.
- 트렁크 라인 탭에서 연결될 가장 먼 디바이스까지의 길이가 탭에서 가장 가까운 말단 레지스터까지의 길이보다 멀다면, 드롭 길이 계산과 함께, 드롭 라인 길이는 트렁크 케이블 길이의 부분으로써 포함되어야 한다.
- 누적 드롭 라인 길이는 케이블 시스템에서의 모든 드롭 라인들, thick 또는 thin 케이블,의 합계를 말한다. 이 합계는 주어진 사용 통신 비율에 허용된 최대 누적 길이를 초과할 수 없다.
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의 핵심 기능
-
개선된 ISO 9141을 바탕으로 저비용의 single-wire 구현
-
최대 속도 20Kbit/s (EMI-이유로 제한)
-
Single Master / Multiple Slave 개념 따라서 중재 불필요
-
보편적인 UART 인터페이스를 바탕으로 하는 저 비용 실리콘 구현. 이것은 거의 모든 마이크로컨트롤러들이 필요한 하드웨어를 칩 상에 갖고 있다는 것을 뜻함.
-
크리스탈 또는 세라믹 공진회로(resonator)가 없는 slave 모드에서의 반 동기화로 slave 하드웨어의 중요한 비용 절감 효과
-
신호 전송을 위한 보증된 대기 시간. 따라서 예측 시스템 가능.
-
다른 slave 노드들에서 하드웨어나 소프트웨어를 변경하지 않고도 LIN 네트워크에 노드들을 추가 가능
-
전형적인 LIN 네트워크의 크기는, 적은 수의 64 식별자들과 상대적으로 느린 전송속도로 인한, 12 노드들 이하 (그러나 여기에 제한되지는 않음),
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)
-
Rain Sensor
-
Light Sensor
-
Light Control
-
Sun Roof
자동차 문 (Vehicle Doors)
-
Mirror
-
Central Locking
-
Mirror Switch
-
Window Lift
엔진 (Engine)
-
Sensors
-
Small Motors
-
핸들(Steering Wheel)
-
Cruise Control Switches
-
Wiper
-
Turn Signal
-
Radio
-
Climate Control
-
Seat
-
Seat Position Motors
-
Occupancy Sensor
비록 LIN이 원래 자동차 애플리케이션을 위해 설계된 것이기는 하지만, 이것은 또한 산업 자동화와 소비 전자제품들을 위한 센서 버스로써도 관심을 받고 있다.
LIN을 지원하는 반도체
현재 다음의 반도체 제조업체들이 LIN 송수신기와 보드상에 LIN 송수신기를 포함한 마이크로컨트롤러를 개발하고 있다:-
-
Philips
-
Motorola
-
Infineon Technologies
-
ST Microelectronics
-
Mitsubishi
LIN Consortium Steering Committee의 주요 회원들
-
Audi AG
-
BMW AG
-
DaimlerChrysler AG
-
Motorola GmbH
-
Volcano Communication Technologies AB
-
Volvo Car Corporation
-
Volkswagen AG
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 분할
PDU2
PDU2 포맷은 특정 수신지가 아닌 오직 통신 메시지들이다. 특정 PDU 영역은 그림 5에서 보여지는 것처럼, 그룹 확장이 된다.
그림 5: PDU2에 관한 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 Recommended Practice for a Serial Control & Communications Vehicle Network
-
J1939/11 Physical Layer, 250 Kbits/s, Shielded Twisted Pair
-
J1939/13 Off-Board Diagnostic Connector
-
J1939/15 Reduced Physical Layer, 250 Kbits/s, Unshielded Twisted Pair
-
J1939/21 Data Link Layer
-
J1939/31 Network Layer
-
J1939/71 Vehicle Application Layer
-
J1939/73 Application Layer - Diagnostics
-
J1939/81 Network Management
J1939 약자 (Abbreviations)
-
ACK Acknowledgement
-
CAN Controller Area Network
-
CRC Cyclic Redundancy Check
-
DLC Data Length Code
-
DP Data Page
-
EOF End of Frame
-
ID Identifier
-
IDE Identifier Extension Bit
-
PDU Protocol Data Unit
-
PGN Parameter Group Number
-
RTR Remote Transmission Request
-
SOF Start of Frame
-
SRR Substitute Remote Request
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 을 보시오.
전반적인 주요 특징들은 다음과 같습니다:-
-
최초 generation Drive-by-wire 시스템 겨냥
-
Time Triggered bus access
-
실리콘이 이제 등장하기 시작
-
현재의 기술 지식과 개발 도구 사용 가능
-
Global time master를 통해 전역적으로 동기화된 시간
-
중재가 파괴되는 경우 메시지 재전송 중단 기능
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 기능을 제공하고 있다
-
Atmel은 현재 그들의 T89C51CC01 8051 기본 프로세서에 레벨 1을 구현하고 있다.
-
NEC의 모든 현존하는 CAN 칩들은 이미 레벨 1까지의 표준을 지원하고 있으며, 레벨 2의 구현 작업이 곧 시작될 것이다.
-
Hitachi는 그들이 TTCAN 하드웨어 지원을 개발하고 있다는 것을 발표했다.
-
Bosch는 최근 실리콘에서의 레벨 1과 2의 최초 구현을 선보였다. 그들은 현재 TTCAN 기능을 가진 자립형 82527 호환 컨트롤러를 설계하고 있다. 이것의 TTCAN 코어의 VHDL 모델은 Bosch에서 이용할 수 있게 될 것이다.
TTCAN에 대한 어떤 대체 기술들을 이용할 수 있나?
TTCAN은 현재 drive-by-wire 시스템의 최초 세대를 위해 이용할 수 있는 기술인 반면 다른 기술들은 차세대 drive-by-wire의 사실상 업계 표준 최고 자리를 놓고 다투고 있다. 이러한 경쟁 기술들에는 byteflight, Time Triggered Protocol(TTP), FlexRay, EC-Net 이 포함된다. 이러한 기술들 각각은 CAN과 TTCAN의 대역폭을 훨씬 능가하는 대역폭을 보장한다; 5Mbaud부터 최대 25Mbaud.
요약
요약하여, TTCAN의 핵심 이점들은 다음과 같습니다:-
-
현행 기술을 바탕으로 한 통신의 시간 결정 방법을 제공한다. 현행 기술에 바탕을 두고 있으므로, TTCAN에 관한 전문 지식은 단체의 현행 CAN 지식과 경험에 근거하게 될 것이다.
-
원래 CAN을 겨냥했던 개발 도구들은 TTCAN에서의 데이터 분석을 위해 사용될 수 있다. TTCAN 프레임이 CAN의 것과 정확히 같으므로, 현재의 CAN 버스 분석 도구로 TTCAN의 직접적인 모니터링이 가능하다. 그러나, 현재의 도구들은 거의 확실하게 메시지 스케쥴을 방해할 것이므로, TTCAN 버스에서 전송한다면 이것이 반드시 가능한 것은 아니다.
-
따라서 CAN에서 TTCAN 시스템으로의 변경은 커다란 재정적 지출을 필요로 하지 않을 것이다.
-
버스가 하이 로딩에서 실행되는 것이 가능해짐에 따라 데이터 처리량이 증가한다.
페이지 히스토리
2008-04-06 00:50 에 임프™님이 마지막으로 수정
'CAN/OBD-II' 카테고리의 다른 글
| OBD2 Codes 설명 (0) | 2010.03.25 |
|---|---|
| 현대 OBDII Specific Trouble Codes (0) | 2010.03.25 |
| 현대자동차의 엔진라인업 (4) | 2010.03.25 |
| 자동차 통신 이해하기_CAN ● MUX ● LAN ● LIN 통신 CAN ● MUX ● LAN ● LIN 통신 (0) | 2010.03.25 |
| CAN 동작 시연 (0) | 2010.03.25 |
