Leo's Garage

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 Project를 Bring up하다보면 마주치는 모듈 중 하나가 BswM(Basic Software Mode Manger) 모듈이다. 보통 초기화 단계의 설정과 OS run을 마치고 나면, 이제 Mode Management가 시작되게 된다. AUTOSAR 내에는 다양한 모드 매니져들이 존재하는데, EcuM(ECU State Manger), ComM(Communication Manager) CanSM(CAN state Manger) 등이 있다. 그런데 이렇게 많은 모드 매니져가 전부 BSW들의 모드를 직접 변경하거나 관리하는 것이 아니다. AUTOSAR 내에 모든 모드를 관리하기 위한 모듈이 존재하는데 그게 바로 BswM이다. 따라서 우리가 정상적으로 Key on을 하고 init이 끝났다면,..

아마도 이 기능은 AUTOSAR 표준은 아닌 것으로 알고 있다. Vector MICROSAR CAN 모듈에 있는 기능이며, 해당 기능은 기본적으로 CAN을 Polling으로 받는 상황에서 특정 CAN ID의 HW Object에 대해서 Interrupt로 받을 수 있게 하는 기능이다. 이 기능은 주로 전체적인 CAN signal은 Polling으로 받으나, 개발 중에 아주 빠른 속도로 XCP msg 등을 받아야 할 필요가 있을 때 활용할 수 있다. AUTOSAR 표준에는 없는 기능이기 때문에 타사의 AUTOSAR 구현체에서는 이를 어떤 식으로 구현했는지는 모르겠다. 다만, 실제 현업에서 개발 시에는 CAN을 각 ID 별로 다르게 동작시켜야 할 필요가 있을 수 있으므로 별도의 방법이 있을 것이다. 물론 정 ..

오늘은 최근 AUTOSAR Project Bring up 단계에서 겪은 몇 가지 이슈들을 정리하도록 하겠다. 1. MICROSAR + Third Party Tool(Tresos)간의 internal Generator 시 Container 생성 이슈 현재 개발 중에는 Vector사의 MICROSAR와 MCAL을 조합해서 개발을 하고 있다. 이때, MCAL의 Base와 CD 부분을 MICROSAR import해서 MCAL generator에 활용하곤 하는데, 최근에 MICROSAR 내에서 MCAL 의 특정 모듈의 Container를 생성 시에 naming이 MCAL implement code와 다르게 생성되는 이슈가 있다. 이런 경우에는 Configurator tool 내부에서 어떠한 이슈나 에러로 잡지 못..

최근에 신규 프로젝트가 시작되어 제어기 BSW bring up을 하고 있다. 이전까지는 AUTOSAR 적용 BSW를 아예 처음부터 시작해 본 적은 없고, 누군가 어느정도 작업해 둔 프로젝트에서 할당된 모듈을 설정하거나 CDD Code를 작성하거나 했었는데, 이번에 처음으로 아예 바닥부터 작업하고 있다. 게다가 이번에는 AUTOSAR Tool Vendor의 Sample Code라던지 혹은 기존에 Demo project 같은 것을 가져와서 하는게 아니라 아예 필요한 모듈만 가져와서 빌드 환경부터 만드는 프로젝트라 나름 꽤나 머리 싸매면서 진행하고 있다. 뭐 물론 그 동안에 굴렀던 시간이 있어서 하나 하나 다 찾아가면서 해볼 정도는 아닌데, 그래도 몇 몇 부분은 이론으로 혹은 남이 해 둔 것만 봤었는데 다 하..

Vector 사의 MICROSAR는 Vector 사에서 AUTOSAR 표준과 추가적인 기능을 더 넣어서 만든 유사 AUTOSAR Package이다. 여기서 유사라고 말 한 이유는 MICROSAR가 완벽하게 AUTOSAR 표준만을 따른 것은 아니고 또한 AUTOSAR Methodology를 완벽하게 계승한 것이 아니기 때문이다. 아무튼 각설하고, Vector의 MICROSAR를 사용해서 BSW Configuration을 작업하는데, CAN DBC import에서 Attribute 부분이 말성인 경우가 많다. 뭐 오토사 Based Project가 아니더라 하더라도 그 이전의 개발 프로세스였다고 하더라도 제어기 설계에서 가장 기본이 되는 부분은 통신/네트워크 구성에 대한 정보를 import하는 것이다. 이 때..

AUTOSAR CAN 통신 스택을 이용해서 CAN 통신을 구현하기 위해 필요한 정보를 정리해보고자 한다. AUTOSAR는 기본적으로 하드웨어 독립적으로 구축하는 것을 목표로 하기 때문에 하위 레이어에 HW 종속적인 모듈이 위치하고, 상위로 갈수록 HW에 독립적인 모듈이 위치하게 된다. BSW를 개발하는 입장에서는 이러한 계층 구조와 각 모듈간의 서로 필요한 정보가 무엇인지 아는 것이 중요하다. 개인적으로 어떤 AUTOSAR Tool을 사용하여 BSW를 Configuration한다고 하더라도 가장 중요한 것은 역시 Communication DB(DataBase)일 것이다. 일반적으로 차량용 제어기는 통신 네트워크 구조를 기반으로 설계가 되어진다. 따라서 어떤 제어기든 개발에 앞서서 가장 중요한 건 바로 이..

AUTOSAR에서는 message를 대략적으로 PDU(Protocol Data Unit)이라고 부른다. 이렇게 대략적이라는 말을 붙이는 이유는 PDU 내부에는 송신 또는 수신 상, 각각 하위 계층 혹은 상위 계층에서 사용하거나 추출하는 데이터 이외의 정보가 포함되어 있기 때문이다. PDU는 크기가 다양하게 n개 있을 수 있고 기본적으로 하위 계층 정보와 함께 Packing된 Signal의 그룹이다. AUTOSAR COM은 송수신 시 각각 PDU 안팎에서 신호의 Packing, Unpacking을 수행하며, 모든 PDU에는 고유한 Identifier가 있다. PDU에는 SDU(Service Data Unit)와 PCI(Protocol Control Information)가 포함된다. SDU는 전송해야 하는..

CAN 통신 스택은 AUTOSAR에서 CAN 버스를 활용한 차량 통신 시스템 모듈 그룹이다. 이는 애플리케이션에서 프로토콜 및 메시지 속성을 숨기는 것과 함께 CAN 네트워크에 대한 균일한 Interface를 제공한다. Low Level은 통신 스택에서 처리되며, CAN 통신 스택은 표준 CAN 및 CAN FD(하드웨어에서 지원하는 경우)을 지원한다. 위의 불록도는 AUTOSAR 의 CAN 통신과 관련된 세부 레이어를 간략하게 보여주고 있다. 다만 해당 블록도가 전부는 아니다. 이 블록도에서는 통신 서비스, 통신 하드웨어 추상화, 통신 드라이버만 고려하고 있다. 1. CAN NM: CAN Network Manager, CAN 종속 모듈이긴 하지만, HW에 대해서는 독립적인 모듈이다. 주요 목적은 CAN ..

요즘 세상에는 굉장히 다양한 CPU, MCU와 OS(Operating System)이 존재한다. PC환경, 서버 그리고 모바일에 이르기까지 엄청나게 고성능 IC들이 즐비하다. 자동차 SW를 개발하면서, 정확히는 안전에 직 간접적으로 관련된 제어기들을 개발하다보면서 드는 의문이 있었다. 비용 문제를 차치하고서라도 조향, 제동, 안전, 전력변환, 전동화 등에 사용되는 제어기의 칩셋이나 OS등을 살펴보면, 이른바 우리 주변에 고성능으로 일컬어지는 CPU나 OS가 아닌 전혀 다른 카테고리의 IC와 OS를 사용하고 있는 경우가 많다. 왜 그럴까? 여기에는 다양한 이유가 있지만 가장 중요한 부분은 Deterministic이다. Determinnistic 해야 한다. 이 말은 어떤 시점에 어떤 경우에도 의도한 동작이..