0. 순서
1. CAN (Controller Area Network) 통신이란
1.1. 등장 배경
1.2. CAN의 구성
1.3. CAN의 특징
1.4. High Speed CAN vs Low Speed CAN
1.4.1. About High Speed CAN
1.4.2. About Low Speed CAN
2. About CAN Frame
2.1. Data Frame
2.1.1. Detail of Data Frame
2.2. Remote Frame
2.3. Error Frame
2.4. Overload Frame
3. Detail of CAN Protocol
3.1. 동기화 관련
3.2.1. Hard Synchronization
3.2.2. Soft Synchronization
3.2. Bit Stuffing
3.3. 중재 (ID Arbitration)
4. Error Handling in CAN
4.1. CAN Error Type
4.2. Error 검사 범위
4.3. Error 상태와 Error Frame
4.4. Error 발생 후 재전송
5. Future of CAN
5.1. CAN FD (2세대 CAN)의 개념
5.2. CAN FD의 특징
5.3. CAN FD Data Frame
5.4. CAN XL(eXtra Long)
5.5. CAN / CAN FD / CAN XL 비교
* OSI 7계층으로 본 CAN 통신
* ISO 11898 규격
1. CAN (Controller Area Network) 통신이란
- 차량 내 각 ECU 장치들이 Host Computer 없이 서로 통신하기 위해 설계된 Message 기반 표준 Protocol
- ECU(Electronic Control Unit) : 자동차 내에서 하나 이상의 전기/하위 시스템을 제어하는 Embedded System
차량의 원활한 제어를 위해 각 ECU 간의 통신이 필요 - Host Computer : Network에 연결되어 다른 장치들과 양방향 통신을 할 수 있는 Computer
- ECU(Electronic Control Unit) : 자동차 내에서 하나 이상의 전기/하위 시스템을 제어하는 Embedded System
- 현재 주로 사용하는 CAN은 1991년 Bosch 사에서 개발한 CAN 2.0
- 이름 내의 'Controller'는 ECU를 의미
- 즉 차량 내부 ECU 간의 통신을 위해 개발된 Protocol
- 초기 목적은 차량 내 ECU 간의 통신이었으나 현재는 다양한 산업 분야에서 사용
1.1. 등장 배경
- 과거에는 자동차의 모든 동작을 기계적인 방식으로 제어하였으나, 기술의 발전으로 ECU를 통해 전자적으로 제어
- 초기에는 이 ECU들을 UART(Universial Asynchronous Receiver Transmitter) Protocol을 통해 연결
- Parallel 형태의 Data를 Serial 형태로 변환하여 Data를 전송하는 Protocol
- 1 : 1 통신 방식
- 이 때, 차량에 요구되는 서비스가 늘어남에 따라 ECU가 증가하는 경우, 1:1 통신을 하는 UART의 특성상 수많은 연결선이 필요로 해짐
- 이로 인해 배선이 늘어나 공간이 부족해지고 무거워져 연비가 하락하는 문제가 발생함
- 위와 같은 문제를 해결과 안정성 향상을 위해 1986년에 Bosch 사에서 CAN Protocol을 개발
- 다양한 ECU 간의 통신을 하나의 Bus로 연결하여 통신에 필요한 배선의 양을 줄
- ECU를 Bus 형태로 연결하는 구성은 RS485와 동일
1.2. CAN의 구성
- RS485의 Twisted Pair Cable을 통해 Serial 통신으로 통신
- EMI(Electromagnetic Interface)에 덜 영향을 받고자 위와 같은 구조 채택
- CAN Bus의 양 끝에 Termination Resistor가 위치
- 여러 ECU가 Multi Master로 Bus에 연결
- No Master Device. 모든 Node 간의 통신 가능
- 각 Node는 고유의 ID를 보유 : ID 값을 통해 통신 순위 선택
- 낮은 ID 값을 우선적으로 선택
- CAN Node는 CAN Controller를 보유한 MCU(ECU)
CAN Controller : Protocol의 Data Link Layer - CAN Frame, ID 확인 등 관리 - CAN Transciver : Protocol의 Physical Layer
- Node A에서 주기적으로 Data Frame 전송
- 해당 Data가 필요한 Node에서 Remote Frame 전송 (Data Frame ID와 동일)
1.3. CAN의 특징
- 최대 1Mbps로 데이터 실시간 전송 가능
- 장거리 통신 가능 (40kbps로 최대 1km 통신 가능)
- 차동 신호(CAN High, CAN Low)를 사용하여 노이즈에 강하며 장거리 전송에 적당
- RS485와 동일
- 노드의 증감 및 네트워크 구성에 유연하여 경제적
- 한 Bus에 여러 ECU가 연결되어 연결선 수를 효율적으로 줄일 수 있음
- 두 개의 신호로 통신하므로 2개의 선만 필요로 함 : ECU 추가 시 필요한 통신 선의 양 적음
- Multi Master 통신 : 여러 ECU들이 통신 Bus를 공유하며 필요할 때 마다 Bus 사용 가능
- 모든 Node가 Bus Master가 되어 Bus가 Idle 상태라면 언제든 Message 전송이 가능
- 또한 모든 Node들은 모든 Message를 볼 수 있음
- Node의 ID Filtering을 통한 Message 우선 순위 지정으로 Node 간 통신 중재
- ID 값이 낮을수록 우선 순위가 높음 (뒤에서 설명)
- CAN Filtering을 통해 ID 값을 수신하여 우선순위를 결정하여 버스 사용시의 충돌 방지
- 이 부분에서 RS485보다 안정성 면에서 뛰어남
- 탁월한 Error 처리와 제한 기능 (결함 노드 버스 연결 단절)
- PLUG & PLAY 기능을 통해 ECU를 Bus에 간단하게 연결 및 제거할 수 있음
- Node 15, 16의 ID를 비교
- ID를 한 bit씩 비교해가며 더 적은 값을 선택
- Node 15를 선택, Node 16은 전송 중단
1.4. High Speed CAN vs Low Speed CAN
- High Speed CAN : Power Train 내의 ECU들끼리 연결된 Bus
- Low Speed CAN : 차량의 바디, 샤시 들의 ECU들을 연결하는 Network 역할
- ISO 11898 규격은 아래에서 설명
1.4.1. About High Speed CAN
- Logic 1 전송 시 CAN_H, CAN_L가 모두 2.5V를 가짐
- Logic 0 전송 시 CAN_H는 3.5V, CAN_L은 1.5V를 가짐
- 즉 둘의 신호 차이가 없으면 Recessive(열성) Voltage : 1 bit
- 차이가 있으면 Dominant(우성) Voltage : 0 bit
- Bus 구성의 Topology
- Termination은 양단 끝에서 처리
1.4.2. About Low Speed CAN
- Logic 1 전송 시 CAN_H는 최대 0.3V, CAN_L는 최소 4.7V를 가짐
- Logic 0 전송 시 CAN_H는 최소 3.6V, CAN_L은 최소 1.4V를 가짐
- 즉 둘의 신호 차이가 -4.4V 이하면 Recessive(열성) : 1
- 차이가 2.2V 이상이면 Dominant(우성) : 0
- Fault Tolerant라 불리는 이유 : 위의 두 선 중 하나가 끊어지더라도 충분히 통신이 가능함
- 복잡한 Bus 형태로 구성 가능
- 종단저항은 각각의 ECU 내에서 처리 가능한 형태
- 맨 끝단에서는 처리 X : ISO11898-2 사양에서는 종단저항 처리에 대한 내용이 따로 기술되어있진 않음
- 억지로 처리한다 했을 땐 위처럼 각각의 ECU 내에서 처리
- Baud Rate vs Range
- 통신 속도와 통달 거리는 서로 Trade - Off 관계
- 하나가 커지면 하나는 줄어듦
- 필드에서 사용 시에 참고용 정도
2. About CAN Frame
- CAN Frame의 4가지 종류
1. Data Frame : Data를 한 node에서 다른 node로 전송하기 위한 Frame
2. Remote Frame : 특정한 Data Frame의 전송을 다른 Node에 요청
-> 위 둘은 ID 값이 들어가는 Field가 있어 표준형과 확장형으로 나뉨
3. Error Frame : 어떤 node에서 Error가 발견됐을 경우 주변 node들에게 Error가 났다는 사실을 알리기 위한 Frame
4. Overload Frame : 어떤 node가 remote frame을 받았는데, 그 node가 이미 하던 일이 있어 바로 보낼 수 없게 되는 경우, 자신이 과부하 상태임을 알리는 Frame
- CAN 2.0 사양서는 Part A / B로 나뉨
- A는 기존의 CAN 1.2 사양서의 내용을 그대로 옮겨와 표준형 CAN Frame에 대한 기술 정의
- 표준형 CAN Frame : ID Field가 11bit로 구성되어있는 Frame
- 11 bit -> 2^11 : 2048개의 Message 종류를 보낼 수 있음
- CAN 2.0 B에서는 위의 표준 Frame 뿐만 아니라 ID Field가 29bit로(5억개 이상)늘어난 확장형 Frame도 지원
- 본 글에서는 Standard Frame을 기준으로 설명
2.1. Data Frame
- IFS (Inter Frame Space) : Frame 간 3bit 정도의 간격 유지용. Idle Time 유지 역할
- SOF (Start Of Frame) : 모든 Frame이 기본적으로 보유하는1bit Data. Frame의 시작을 알림
- ID (Identifier) : Bus에 접근할 Node 설정 (통신할 장치 선택). 표준형은 11bit, 확장형은 29 bit
- RTR (Remote Transmission Request) : 이 Frame이 Data / Remote Frame인가를 알림
- 0 (Dominant) : Data Frame
- 1 (Recessive) : Remote Frame
- IDE (IDentifier Extension) : 이 Data Frame이 표준형 / 확장형 Data Frame인가를 구별하는 기준
- 0 : Standard Frame
- 1 : Extended Frame
- 확장형의 경우 IDE 뒤에 확장되는 ID가 따라옴(18bit)
- SRR (Substitute Remote Request) : 현재 Data Frame이 확장형인 경우, RTR은 확장된 ID 뒤로 이동하고
원래 RTR의 자리를 대체하는 1bit - ID 값이 끝난 후에 RTR bit를 표시할 수 있도록 RTR을 임시적으로 대체해주는 역할
- DLC (Data Length Code) : 0~8 byte의 크기를 나타냄
- Data :
- CRC (CycleRedundancy Check) : Serial 통신시 Noise가 많이 발생하므로, 통신 Data의 검증을 위해 사용
- 송신 Node에서 Bit pattern을 보내며 그에 대한 CRC 값을 계산하고 뒤에 붙여서 보냄
- 수신 Node에서는 받은 Bit pattern으로 CRC를 직접 계산하고, 송신단에서 보낸 CRC값과 비교하여 같은지 확인
- 둘이 다르면 수신한 Bit pattern 중에 Error가 발생한 것
- ACK(Acknowledge) : Receiver로부터의 Acknowledge
- 송신 Node에서 이 bit를 1로 보냄
- 수신 Node에서 Message를 받고 Error 없이 잘 받았음을 표시하기 위해 ACK Bit에 1을 Overwrite
0이 Dominant Bit이므로 0이 쓰임 - 즉 수신단에서 Message를 정상적으로 받았다면 ACK 값이 0으로 변함
- EOF (End Of Frame) :
2.1.1. Detail of Data Frame
- CAN Rx : MCU로 입력되는 Data Line
- stuff bit : CAN Bus에 문제가 없는지 확인하는 bit (Heartbeat 느낌)
- 위 Bit들 중 ACK Delimeter, CRC Delimeter, EOF Bit는 CAN Frame에서 '1'로 고정
2.2. Remote Frame
- DLC와 CRC 사이에 Data Field가 없다는 것과 RTR bit의 값을 제외하고 Data Frame과 동일
- Data를 요청하는 Frame이기 때문에 Data Field 필요 X
- Node A에서 Remote Frame을 전송
- A에서 보내는 Message는 Remote Frame이므로 Data Field가 없음
- ID Field 내에 있는 값을 갖는 Message를 Node B에 요청
- Node B는 위에서 요청된 ID를 갖는 Message를 생성할 수 있는 Node
- 이 요청을 받아들여 해당 ID를 포함하는 Data Frame을 생성해 전송
- 어떤 Node에서 이 Message를 받는지는 모름
- 위처럼 Data Frame과 Remote Frame은 한 쌍으로 주고 받아지며, 두 Frame의 ID 값은 같아야 한다
2.3. Error Frame
- Error 발생 시 상태를 알려주기 위한 부분
- 위의 Error Flag - Error Delimiter 까지가 Error Frame
- Error Flag (무조건 6 bit)
- Error Flag (Secondary) : 올 수도 있고 안올 수도 있음 (0~6 bit)
- Error Delimiter : Error 구분자. 8개의 Logic '1'의 값을 가짐
- Error Flag는 Error의 상태에 따라 능동 / 수동 Error Frame으로 나뉨
- CAN Node는 자체적으로 Error Counter를 가짐 (Error 발생 시 +1, 정상 동작 시 -1 방식?)
- 이 Error Counter가 일정 값 이상이 되면 Error가 많이 발생했음을 인지하고
- Error가 별로 없으면 능동, 많으면 수동 Error Frame 사용
- 능동 Error Flag는 6~12개의 '0', 수동은 6개의 '1'이 들어감
- 즉 Node의 Error 상태에 따라 Error Flag의 값이 달라짐
2.4. Overload Frame
- Error Frame과 비슷한 형태
- Overload Flag에는 6개의 '0'이 들어감
- Overload Delimiter에는 8개의 '1'이 들어감
- 위의 Overload Frame은 Active Error Frame과 같은 값을 가짐
- 위를 어떻게 구분? -> 모양은 똑같으나 CAN Node는 이 둘을 구분할 수 있음
- Error Frame은 Data / Remote Frame을 전송하는 도중에 Error가 발생해서 그 즉시 Error Frame이 나오게 됨
- Overload Frame은 한 Frame의 전송이 완료된 후 전송됨
- 따라서 둘의 시점에 따라 Frame을 구분함 : Data / Remote Frame 도중에 검출되면 Error Frame, Data / Remote Frame 의 전송이 끝난 후에 검출되면 Overload Frame
3. Detail of CAN Protocol
3.1. 동기화 관련
- CAN Node에서 동기를 맞추는 것이 매우 중요
- CAN Node들은 Network 주변에 나열되어있고, 비동기이므로 서로 동기를 맞춰야 하는데, 완벽하게 맞추긴 어려움
- 따라서 CAN 통신에서는 아래와 같은 동기를 능동적으로 맞출 수 있는 기법들을 사용
3.2.1. Hard Synchronization
- CAN Frame은 맨 앞에 SOF가 있다
- Logic 1(Idle 상태) -> 0으로 떨어지는 순간
- 최초의 동기를 이 순간에 맞춰 모든 Node들이 이를 통해 계산을 시작
3.2.2. Soft Synchronization
- Resynchronization 이라고도 부름
- Frame 도중에 1 -> 0으로 바뀌는 모든 지점, 즉 모든 Falling Edge에서 bit의 시작을 다시 맞추는 것
- 재동기화를 맞추는 동작의 과정 : Bit Timing
- 동기화가 중요하므로 아래와 같은 Bit Timing을 맞춤
- Time Quanta : 1 bit의 폭을 굉장히 잘게 쪼갠 단위
- 즉 1 bit를 여러 조각내서 더 자세히 쳐다보게 함
- CAN에서는 이 Time Quanta를 여러개로 나누고 그를 아래 4개의 영역으로 나눔
- Sync
- Propagation
- Phase 1
- Phase 2
- Phase 1과 2 사이의 지점을 Sample Point 라고 함
- Sampling 하는 지점. 이 시점에서의 Logic값을 토대로 Logic 1/ 0을 판별
- Phase 1, 2는 내가 갖고있는 Clock과 Packet이 다른 경우가 있으므로 1을 늘려 Sample Point를 뒤로 늦추거나
Phase 2를 줄여 Sample point를 앞으로 당길 수 있음 - 즉 매 Falling Edge마다 Phase 1, 2를 조정하여 Sample Point를 조정하는 것이 Bit Timing 기법
3.2. Bit Stuffing
- bit가 쭉 전송될 때, 즉 Frame에 bit 열이 전송될 때 연속된 6개의 bit값이 동일한 값이 나오면,
연속된 6개 bit 값이 나오지 않도록 반대 극성을 삽입하는 것- Stuffing : 채워넣는 것을 의미
- Ex) 111111 패턴이 나올 때 111110 1 형태로 전송 / 000000 패턴이 나올 때 000001 0 형태로 전송
- 재동기화를 위한 Edge 확보
- 즉 Falling Edge를 강제적으로 만들어주기 위함 (재동기화가 Falling Edge에 발생하므로)
- 수신 측면에서는 이렇게 강제로 넣어준 bit를 빼주는 과정을 Bit Destuffing이라 함
- 위처럼 1이 연속으로 6개가 나올 경우, 6번째 자리에 0을 삽입하고 원래 1을 그 뒤에 붙임
- 이후 0이 연속으로 6개가 나와 0을 넣어 줌
- 이런 동작은 CAN Controller 내부에서 자동으로 이뤄지므로 우리가 별도로 프로그래밍을 할 필요는 없다
3.3. 중재 (ID Arbitration)
- CAN의 중요한 특성 중 하나
- ID의 우선 순위를 통해 충돌을 회피하게 하는 특성 : 안정성 유지의 핵심 기능
- CAN Bus에서 자주 일어나는 부
- 한 Bus에 여러 Node들이 물려있는 형태
- 이들이 동시에 각자 Message를 보내려 시도하는 상황
- 동시에 SOF를 시작
- Dominant Bit : 0 / Recessive Bit : 1
- Network 상에서 둘이 부딫히면 Dominant Bit가 우세함 : 즉 0이 이김
- 위 그림의 경우 ID의 1~2번째 bit는 동일한데, Node B의 3번째 bit가 1 : 열성
- 이후 Node B는 Listening Mode로 전환하여 ID를 전송하지 않고 다른 Node들의 통신 내용을 듣기만 함
- 이후 Node A의 6번째 bit가 1 : 5번째 bit부터 Listening Mode로 전환
- Node D의 3번째 bit가 1 : 2번째 bit부터 Listening Mode로 전환
- 즉 Node C의 ID의 우선순위가 가장 높음
- 따라서 Node C만 ID를 계속 전송
- 따라서 ID 값이 작을수록 더 높은 우선순위를 갖게 됨
- 0이 우선 순위가 높으므로
4. Error Handling in CAN
4.1. CAN Error Type
- Bit Error 감지 : 송신 Node가 bit pattern을 bus를 통해 전송
- 이 때, 전송을 바로 끝내지 않고 Loop back에서 bus 상태를 다시 읽어보게 됨
- 내가 보낸 bit pattern의 정보와 실제 loop back에서 읽은 bus의 상태가 같으면 정상 전달됐음을 확인
- 만약 둘이 다르다면 Bit Error가 발생
- Stuffing Bit 검사 : Bit Stuffing의 규칙을 어기고 동일한 6개의 bit가 연속해서 나타나는 경우
- Message Type 검사 : CAN Frame에서 '1'로만 고정되어있는 Field들이 있음 (ACK Delimeter, CRC Delimeter, EOF)
- 위와 같은 Field에서 '0'이 나온다면 CAN Frame이 잘못된 것
- CRC : Data가 손상된 것
- 송신 Node에서 Bit pattern을 보내며 그에 대한 CRC 값을 계산하고 뒤에 붙여서 보냄
- 수신 Node에서는 받은 Bit pattern으로 CRC를 직접 계산하고, 송신단에서 보낸 CRC값과 비교하여 같은지 확인
- 둘이 다르면 수신한 Bit pattern 중에 Error가 발생한 것
- ACK 검사 : 아래와 같은 CAN Field의 일부분 중 ACK Delimeter는 무조건 1의 값을 가져야 함
- ACK는 왔다갔다 함
- 송신 Node에서는 이 Field를 처음에 1로 보냄
- 이후 이 Message를 필요로 했던 Node가 이걸 받고 Error없이 잘 받았음을 표시하기 위해 ACK Field에 0을 Overwrite 함 : 0이 우성이므로 0이 쓰임
- 즉 수신단에서 Message를 정상적으로 받았다면 ACK 값이 0으로 변경됨
- 만약 Message를 다 보냈는데 ACK 값이 계속 1인 경우를 ACK Error라 함
4.2. Error 검사 범위
- 각 Error의 검사 범위는 각자 다름
- Bit Error는 전체 (SOF ~ EOF). 모든 CAN Field를 검사
- Stuff Error, CRC Error는 동일 (SOF ~ CRC Delimeter 직전까지)
- Message Foam Error(항상 '1'이어야 하는 Field. 즉 CRC Delimeter, ACK Delimeter, EOF 확인)는 위의 각각 부분
- ACK Error는 ACK 시점에서 확인
- Error Counter와 Error 상태
- CAN Node에는 2가지 Error Counter가 존재
- TEC(Transmit Error Counter)
- REC(Receive Error Counter)
- 뭔가 문제가 생겼을 때 Counter를 1씩 증가. 큰 문제가 생길 경우 8개씩 증가
- 정상적으로 송/수신이 되면 1씩 줄임
- 정상적인 상태인 기기는 보통 Error Counter가 적당한 선에서 유지됨
- Error Counter의 수치에 따라 Node의 상태를 3가지로 구분
- Error Active : Error가 있기는 한데 그렇게 큰 문제가 되지는 않는 경우. 일반적인 상태임
- Error Passive : Error가 점점 늘어나다 일정 값을 넘은 경우
- TEC > 127or REC > 127
- Error Counter가 줄어들면 다시 Error Active 상태로 이동
- Bus OFF : Error Passive 상태에서 Error Counter가 더 들어나면 해당 Node가 심각한 문제가 있는 상태이며, 다른 Node의 전송까지 방해할 수 있으므로 Bus로부터 단절을 시켜 이 node가 bus에서 아무 동작을 하지 않도록 함
- TEC > 255
- Error Active 상태로 가기 위해선 SW를 Reset하거나 11개의 연속적인 '1' bit열을 발생되어야 함
- 11개의 연속적인 '1' 은 Idle 상태가 길게 유지되어 아무도 Bus를 쓰지 않는 경우
4.3. Error 상태와 Error Frame
- Error 상태에 따라 Error Frame의 Error Flag를 달리 해서 보냄
- Error Active 상태에서 Error가 발생할 경우 Error Frame을 Active Error Frame 형태로 보냄
- Error Flag를 6개의 '0' bit로 보냄
- Error Passvie 상태에서는 Error Frame을 Passive Error Frame 형태로 보냄
- Error Flag를 6개의 '1' bit로 보냄
- 이를 통해 Error Frame만 봐도 장치의 상태를 알 수 있
4.4. Error 발생 후 재전송
- Error Frame은 Data / Remote Frame 전송 도중 보내지게 됨
- Error Frame 전송 이후 3bits의 IFS(Inter Frame Space) 후에 전송에 실패했던 Data Frame을 다시 보내게 됨
- Error Active의 경우 IFS 직후 Data Frame을 다시 전송
- Error Passive의 경우 Error가 많이 있는 상태이므로 IFS 이후 8bit의 Suspend Transmission 후 Data Frame 전송
- 이 suspend 기간에 전송을 기다리던 다른 Node들이 bus를 점유해서 사용
- 이 경우 Error Passive 상태에 있는 Node들은 다른 node에게 우선순위가 밀려 bus를 사용하지 못하게 됨
- 즉 Error가 많은 Node가 다른 Node의 통신을 방해하지 않도록 함
- 8 bit를 추가로 쉬었는데도 아무도 bus를 쓰지 않는다면 그 때 해당 Node가 bus를 사용
5. Future of CAN
5.1. CAN FD (2세대 CAN)의 개념
- CAN FD의 경우 기존의 CAN Frame 중에서 Data / CRC Field를 Data 구간이라 명칭하고 그 외의 구간을 중재 구간이라 명칭함
- 데이터 구간을 고속으로 전송하고자 위와 같이 분리함
- Data 구간에서는 속도를 최대 8Mbps (기존의 8배) 까지 올림
- 기존에는 Data Field가 8 byte로 고정되어있어 모든 구간에서 Clock이 동일했음
- CAN FD의 경우 Data 구간에서는 8배 빠른 Clock으로 보낼 수 있도록 함 : 최대 64 byte까지 전송 가능
5.2. CAN FD의 특징
- 기존 CAN과의 호환성 : Data 구간을 제외한 나머지 Field들은 이전과 동일
- 전송 속도 고속화로 인해 Bus 부하 문제 감소
- Bus의 장기간 사용으로 인한 문제 감소
- Data Rate : 100kbps ~ 8Mbps
- Data Field 최대 64 byte 증가
- CRC Field 증가 (15 -> 21 bits) : Error 검출 능력 증가
- FlexRay와 유사한 성능에 구현 비용이 저렴
- 현재 FlexRay는 거의 쓰지 않음
5.3. CAN FD Data Frame
- EDL(Extended Data Length) ~ FDF(FD Format Indicator) :
- Reserverd 영역으로 사용하던 'r0'를 EDL(1)로 사용
- 즉 이 부분이 기존의 '0'이 아닌 '1'로 읽히면 Classic CAN이 아닌 CAN FD임을 알려줌
- 이후 뒤의 Format이 CAN FD로 바뀌게 됨
- BRS(Bit Rate Switch) :중재 구간과 데이터 구간이 속도가 달라져 속도가 전환되는 것을 알려주는 부분
- 0일 때는 속도 전환을 하지 않음을 의미
- 1일 때는 속도 전환을 함을 의미
- 즉 아래 BRS bit 직후부터 CRC구간까지, 즉 Data 구간의 속도가 변함
- ESI(Error State Indicator) : CAN Node의 Error 상태 (Active / Passive)를 알려줌
- 즉 Packet에서 장치의 상태를 볼 수 있게 해줌
- 0 : Active Error
- 1 : Passive Error
- DLC(Data Length Code) : 0~8 byte 까지는 기존 DLC 크기 동일
- 이후로는 12, 16, 20, 24, 32, 48, 64 단계로 Data의 길이를 표시
- Classic CAN은 8 byte / CAN FD는 8 ~ 64 byte
5.4. CAN XL(eXtra Long)
- 2018년 말부터 3세대 CAN
- TCP / IP와의 연동을 위해 Payload Data 증가 및 고속화
- 최대 Payload 2048 byte
- Ethernet과의 연동을 위한 CAN to Ethernet Bridge Protocol Converter
- Bosch가 보유한 기본적인 CAN의 특허권은 기간이 만료됨
- CAN FD, XL도 Bosch에서 만들어 특허권을 보유
5.5. CAN / CAN FD / CAN XL 비교
- CAN XL의 경우 32bit의 Message ID를 Data Field 내의 Acceptance Field에 추가할 수 있게 함
- Bus 방식은 동일 (ID를 통한 중재)
- CAN FD의 경우 Data byte가 일정 byte 이하일 때는 17bit를, 이상일 때는 21bit를 사용
* OSI 7계층으로 본 CAN 통신
- OSI 7계층 : 통신 시스템 구성 시 호환성을 갖게 하고 각각의 모듈들을 재사용 하기 위해 네트워크 프로토콜이 통신하는 구조를 7개의 계층으로 분리하여 각 계층간 상호 작동하는 방식을 정해 놓은 것
- 관련 내용 : https://youngseong.tistory.com/343
- CAN은 위 중 1, 2 계층에 해당
- Physical Layer : 0, 1의 Bit Stream의 물리적 전달을 담당하는 부분
- Data Link Layer : Physical Layer를 통해 송/수신되는 Data의 흐름 및 Error 관리
- Physical Layer에서는 Data를 주고 받기만 할 뿐 그 Data의 내용이나 Error 여부에 대해선 신경쓰지 않음
- OSI Layer에 대응하는 CAN Layer의 내용
1) CAN Physical Layer
2) CAN Protocol
- LLC(Logical Link Control) : Message Filtering, Overload Notification, Error Recovery Procedure 담당
- ECU에서 CAN Message를 받을 때, Message가 너무 빠른 속도로 올 때 Overload Frame을 보냄
- MAC(Meduium Access Control) : Messgae Framing, Arbitration, Acknowledgement, Error Detection ,Signaling 담당
- 구리선에 두 개 이상의 CAN Message가 얹혀졌을 때 충돌 시 조정, ECU Receiver가 정보를 제대로 받았을 때 알림
- 실제 물리적으로 CAN 구현 시 Host / CAN Controller, CAN Transceiver로 구성
Physical Layer에 PLS(Physical Signaling) 추가?
- 각 계층 별 구성 내용
- CAN보다 상위 계층으로 올라가는 Protocol
- CAN이 최하위 2개 계층에 해당하므로 위와 같은 Protocol이 많음
- 위 Protocol들은 CAN 위에 올라가서 동작하는 Protocol
* ISO 11898 규격
- ISO11898-1, ISO11898-2 ... 는 CAN 통신과 관련된 규격을 의미
- ISO11898-1 : CAN Controller에 해당하는 부분을 표준화하여 사양으로 정리해놓은 것
- ISO11898-2, ISO11898-3 : 모두 CAN Transceiver에 해당
- ISO11898-2 : High Speed CAN (최대 1Mbps), 즉 Power Train Bus로 사용하는 통신 선로 관련
- ISO11898-3 : Low Speed CAN (최대 125kbps), 즉 차량 바디, 샤시 등의 ECU를 연결하는 통신 방식 관련
- ISO11898-4 TTCAN(Time Trigger CAN) : CAN 통신에서는 ID 값이 있어 우선 순위를 결정하여 높은 노드의 메세지부터 전송
- 이 때 우선 순위가 낮은 ID의 메세지들은 계속 밀려 전송이 안 될 수도 있는데, 이를 방지하기 위해 시간을 나눠 각 노드와 메세지들에게 할당하는 방식
- SAE/J2411 : 기존 CAN(+ / -)과 다르게 Single Wire를 사용. 저속이며(최대 33.3kbps) 저렴함
- CAN Controller에 ISO11898-2를 붙이면 고속, 3을 붙이면 저속, SAE를 붙이면 Single Wire CAN 통신 구성 가능
참고 자료 : https://www.youtube.com/playlist?list=PLTp_ZhmNQUh6GTPYNv47uZd2D2DfRtCVk
https://medium.com/@devjohnpark/host%EB%9E%80-0b6091482d18
https://blog.naver.com/PostView.naver?blogId=diguyz&logNo=220779773683
https://www.youtube.com/watch?v=WikQ5n1QXQs
http://realsys.co.kr/data/arm/10.CAN%ED%86%B5%EC%8B%A0%20%EC%82%AC%EC%9A%A9.pdf
'Study_Communication' 카테고리의 다른 글
OSI 7 Layer란 (0) | 2024.05.24 |
---|---|
Windows에서 Putty, VNC 사용법 (2) | 2023.09.04 |