Leo's Garage

Tesla의 홈페이지에 가면 아래와 같이 공개된 NACS 표준을 살펴볼 수 있다.상기 표준 중에 Technical Specification 링크를 들어가보자.목차 중에 Communication between EV and EVSE 목차를 들어가보자.4.5.2를 읽어보면, ISO-15118의 PnC와 호환된다고 함을 확인할 수 있다. ISO15118은 어떤 표준일까?ISO15118 표준은 전기차용 충전 표준이다. 그리고 이 표준은 CCS의 충전 통신 표준이다. 즉, NACS와 CCS는 결국 같은 충전 표준으로 호환됨을 알 수 있다.

ICCU(Integrated Charging Control Unit) : 차량에 있는 고전압 배터리와 보조배터리 모두 충전기 가능하도록 개발된 통합충전 시스템 기존에 LDC와 OBC로 나눠져 있던 전기차 내부 충전시스템을 단일 제어기로 통합시켰다. 기존에 단방향 충전만 가능했으나 이제는 양방향 전력변환이 가능하다. 최근에 아이오닉5, EV6, EV9 등에 탑재되고 있으며 앞으로 전기차 시스템에 중요한 한 부분을 차지할 것으로 보여진다.

CAN DBC file이란 무엇인가 CAN DBC file (CAN Database)는 raw CAN Bus data를 '물리적'인 값으로 디코딩하기 위한 정보가 포함된 Text file이다. 이 raw CAN Data는 아래와 같이 생겼다. CAN ID Data bytes 0CF00400 FF FF FF 68 13 FF FF FF CAN ID에 대한 디코딩 규칙이 포함된 CAN DBC가 있는 경우에는 데이터 Byte에서 signal을 추출할 수 있고, 그 신호 중 하나가 EngineSpeed일 수도 있다. Message Signal Value Unit EEC1 EngineSpeed 621 rpm DBC 디코딩 작동 방식을 이해하기 위해 DBC 구문을 설명하고 예제를 보도록 하자. DBC message ..

Multiplex message는 일반적으로 메시지의 DLC가 허용하는 것보다 더 많은 Signal을 전달할 수 있게 한다. Multiplex message를 정의하려면 포함된 signal이 "multiflexor"로 설정된 경우 해당 값(index)은 message의 나머지 바이트에서 어떤 데이터가 전송되는지를 나타낸다. ECU는 현재 Multiplex message를 사용하고 있다. Signal1는 모든 경우 전송되는 고정 Signal이다. 그리고 multiplexor signal에 따라서 나머지 두 Byte의 Signal의 경우 서로 다른 내용을 송신할 수 있게 된다. 즉, 제한적인 DLC를 최대한 활용해보고자 하는 방안이라고 생각할 수 있다. 물론 CAN FD의 경우에는 DLC를 최대 64Byte..

배경은 역시나 일반 CAN의 한계 때문이다. 자동차가 발전 됨에 따라서 더 많은 기능과 제어기가 들어가게 되었다. 따라서 CAN의 네트워크 속도는 한계에 직면했고 돌파구가 필요했다. 그래서 CAN을 개발한 Bosch는 2012년에 CAN의 확장 형태인 CAN FD(CAN with Flexible Data rate)의 사양을 발표했다. 표준 CAN 네트워크는 Frame 당 최대 payload가 8bytes인 1Mbit/s로 제한된다. CAN FD는 CAN의 physical layer를 변경하지 않고도 Frame당 최대 64bytes까지 더 긴 Data Field를 허용하여 유효 데이터 전송률을 높인다. 또한 CAN FD는 일반적인 CAN bus arbitration을 유지하여 Arbitration이 끝날 ..

Error Handling은 CAN protocol에 정의되어 있으며, CAN 시스템 성능에 매우 중요한 역할을 한다. Error Handling은 CAN 버스의 메시지의 오류를 감지하여 일반적으로는 송신기가 오류 메시지를 재전송할 수 있게 하는 것을 목표로 하고 있다. 따라서 버스 내의 모든 CAN controller는 메시지 내에서 오류를 감지하려고 시도한다. 일단 오류가 발견되면, 오류를 발견한 노드는 Error Flag를 전송하여 Bus traffic을 파괴한다. 다른 노드는 이 Error flag를 통해서 오류를 감지하고 현재 메시지를 폐기하는 등의 조치를 취한다. 각 노드는 두 개의 Error Counter, 전송 Error Counter와 수신 Error Counter를 가지고 있다. 이 C..

CAN bus의 각 bit는 Timing을 위해 최소 4개의 Quanta로 나뉜다. 이 Quanta는 논리적으로 4개의 그룹 또는 세그먼트로 나뉘게 된다. 1. Synchronization Segment : 동기화 세그먼트 2. Propagation Segment : 전파 세그먼트 3. Phase Segment 1 : 위상 세그먼트 1 4. Phase Segment 2 : 위상 세그먼트 2 이 Segment들은 소위 Time Quantum이라고 불리는 단위 시간의 정수 배를 의미한다. Time Quantum은 CAN system의 Clock 주기와 동일하다. 이는 MCU에 의해 구현되는 것이다. 결국 이것들은 CAN message의 1bit가 날아갈 때, CAN clock의 몇 배가 각 영역에 할당되어야..

9 pin DSUB 이 커넥터는 CiA에서 권장하며 거의 산업 표준이나 다름 없다. 전원이 공급되는 경우에는 +7...+13V, 100mA 범위 내에서 공급되면 된다. 보통 2번 핀에 CAN_L, 7번 핀에 CAN_H를 연결한다.

CAN 버스는 Bit-Stuffing과 함께 NRZ(Non-Return To Zero)를 사용한다. Bit Stuffing이란 수신기에 Signal 정보를 제공하기 위한 방법 중 하나인데, Data 내에 하나 이상의 Bit를 삽입하는 것을 의미하며 일반적으로 수싯기는 이렇게 채워진 Bit를 감지하고 제거 또는 무시하는 방법을 알고 있다. 이는 동기화를 유지하기 위함으로 동일한 극성의 5 bit가 연속되면 반대 극성의 Bit가 삽입되는 것이다. NRZ Bit Coding은 전송된 Binary Signal을 직접 다룬다는 의미이고, Logic 1은 High, Logic 0는 Low에 해당한다. 그런데 이 방식의 특징 중 하나는 같은 극성을 가진 연속적인 비트의 경우 레벨의 변화가 없다는 점이다. 따라서 NR..

CAN에는 명시적인 주소가 없다는 점은 기억해야 한다. 이런 점때문에 각 CAN Controller는 Bus에서 모든 트래픽을 수집하고 HW Filter와 SW 조합으로 해당 메시지가 해당 Node에 있어서 의미있는 메시지인지 아닌지를 판단할 뿐이다. 그래서 사실 CAN에는 message 주소라는 개념은 없다. 대신에 메시지에 존재하는 Identifier를 통해서 메시지의 내용을 식별할 뿐이다. CAN 메시지는 따라서 contents-addressed로 분류한다. conventional message address는 일반적으로 Node X에 대한 메시지가 여기 있다. 라는 식으로 정보를 준다. 하지만 Contents - address의 경우에는 여기 X라는 label이 붙은 데이터가 포함된 메시지가 있다..