일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 비트코인
- python
- Bitcoin
- 파이썬
- AUTOSAR
- toefl writing
- 백테스트
- 클라우드
- TOEFL
- 토플
- Cloud
- 개발자
- 자동매매
- 암호화폐
- backtrader
- 백트레이더
- 오토사
- 토플 라이팅
- 확률
- GeorgiaTech
- can
- it
- 블록체인
- 프로그래밍
- 아마존 웹 서비스
- AWS
- probability
- 퀀트
- 자동차sw
- backtest
- Today
- Total
목록can (14)
Leo's Garage
Vector Microsar Set up을 하면서, 초기에 CAN DBC를 import하게 되면, CAN Message에 담겨있는 Signal들을 각각 SWC 상에서 연결하게 된다. 물론 개발자의 입장에 따라서 각 Signal을 직접 연결하는 것도 방법이지만, 편의성을 위해서 각 Signal을 Group 단위로 모아서 Authoring 작업도 가능하다. CANdb++ editor를 통해 DBC file을 열고, 각 message 하위에 Signal Group을 생성해서 Signal을 그 안에 위치시킬 수 있다. 완벽하게 적절한 예제 사진은 아니지만(인터넷 상에 적절한 예제가 없다 ㅜㅜ), 위의 Multiplexing/Group 항에 현재는 Multiplexing에 대한 정보가 담겨있지만, Signal G..
CAN 통신 과정은 아래와 같다. RTE Start 이후에 특정 Software Component에서 User Request API를 이용하여 Full Communication 요청을 BswM에게 보낸다. BswM은 해당 요청을 받고, ComM에게 Full COM 요청이 왔음을 알린다. 이때 User Request API 자체에 특정 Channel에 대한 정보가 담겨 있는데, 이를 바탕으로 ComM은 해당 요청이 어떤 Channel에 대한 요청인지를 파악하고, 해당 Channel에 대한 통신 시작 요청을 전달한다. Nm은 옵션인데, 해당 기능을 구현해야 한다면, Nm Channel을 통해서도 통신 시작을 알린다. CanSM은 ComM으로부터 Full Communication으로 상태를 변경함을 전달받는다..
아마도 이 기능은 AUTOSAR 표준은 아닌 것으로 알고 있다. Vector MICROSAR CAN 모듈에 있는 기능이며, 해당 기능은 기본적으로 CAN을 Polling으로 받는 상황에서 특정 CAN ID의 HW Object에 대해서 Interrupt로 받을 수 있게 하는 기능이다. 이 기능은 주로 전체적인 CAN signal은 Polling으로 받으나, 개발 중에 아주 빠른 속도로 XCP msg 등을 받아야 할 필요가 있을 때 활용할 수 있다. AUTOSAR 표준에는 없는 기능이기 때문에 타사의 AUTOSAR 구현체에서는 이를 어떤 식으로 구현했는지는 모르겠다. 다만, 실제 현업에서 개발 시에는 CAN을 각 ID 별로 다르게 동작시켜야 할 필요가 있을 수 있으므로 별도의 방법이 있을 것이다. 물론 정 ..
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의 몇 배가 각 영역에 할당되어야..
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..
메시지 Arbitration ( 둘 이상의 CAN Controller가 Bus를 누가 먼저 사용할 지 합의하는 과정)은 데이터 전송을 위하여 실제 사용가능한 대역폭을 결정하는데 매우 중요하다. CAN 통신의 경우, UART와 다르게 bus 구조로 네트워크에 많은 Node가 함께 연결되어 있다. 즉 우선 순위에 대한 특정한 프로토콜이 필요하며 이를 통해서 데이터 전송에 대한 혼선을 막을 수 있다. 모든 CAN 컨트롤러는 bus가 idle 상태임을 감지하면 곧바로 메시지를 전송할 수 있다. 이 때문에 두 개 이상의 CAN 컨트롤러가 동시에 메시지를 전송하게 되는 상황이 생길 수 있는 것이다. 이러한 메시지 동시 송신은 다음의 과정을 통해서 해결할 수 있다. 메시지를 전송하는 노드는 메시지 전송을 하는 동안에..