candb와 data

안녕하세요. 이해하신 것처럼 시그널의 비트 위치, 시그널의 길이. 팩터, 오프셋 등의 정보는 모두 can db에 작성되고 캔메세지 자체에는 그런 정보가 담기지않습니다.따라서 수신자 제어기가 캔 메세지로 받는 정보는 데이터 영역에 담긴 데이터 값만을 바이트 단위로 받을뿐입니다.따라서 수신자 제어기가 스스로 시그널에 대한 정보를 파싱할 수는 없습니다.수신자 제어기의 sw를 개발하는 사람이 dbc에 담긴 내용을 바탕으로 , 파싱하는 로직을 별도로 구현해야되는겁니다. ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ수신자 제어기에서는 data 영역에서 어디까지가 어떤 signal에 대한 값인지 어떻게 알게 되나요? 위 질문에 대한 답변을 요약하면.수신자제어기 스스로는 어디까지가 어떤 시그널값인지 알 수 없습니다. 그래서 수신자 제어기 sw 개발자가 can db를 보고, 파싱하는 코드를 별도 구현해야합니다. 답변이 이해되셨을까요??

Bus Off(버스 오프) 상태가 흔히 발생되는 상태인가요?

안녕하세요. 버스 오프가 흔히 일어나는 증상이냐고 물으셨는데 딱 잘라서 대답하기가 힘든 질문이네요.그냥 제 개인적 경험으로는 실제 차량에서 버스 오프 에러가 발생하는 경우를 본적은 없습니다.그래서 제품 개발 과정 중에 버스 오프 처리 로직을 검증할 때도,일부러 CAN High, CAN LOW 전선을 서로 접촉시켜서 신호를 강제로 캔 스펙을 벗어나도록 만들어서 강제로 캔 버스 오프 상태를 만들어서 테스트합니다.실제 차량에서도 물리적으로 제어기나 통신wire에 뭔가 문제가 생기지 않는다면 발생할 일은 없을거 같습니다.1. 일부 제어기만 에러를 "감지" 한다는 표현은 제가 설명을 애매하게 한 거 같습니다.일부 제어기만 에러를 "유발" 한다고 표현하는게 나을거 같습니다.예를 들어 스터핑룰을 어기는 상황이라면, 네트워크에 연결된 어떤 제어기든그 상황을 인식할 수 있을테니 일부만 인식하는게 아니라 모든 제어기가 인식 할겁니다.제가 설명하려고 했던건, 특정 제어기 1개가 맛이 가서 계속 스터핑 룰을 어기는 형태로 신호를 내보낸다면, 해당 제어기는 버스 오프 상태에 진입해서 더 이상 통신에 참여 못하게 해서 다른 제어기들 끼리라도 통신을 할 수 있게 한다는 의미였습니다.마찬가지로 예를들어 CRC 에러의 경우에도, 값이 틀린 CRC가 메세지에 담겨있다면모든 제어기가 CRC에러를 감지할 겁니다. 말씀하신 것처럼 캔통신에서는 모든 제어기가 똑같은 통신선을 사용하니까 에러 상황이 발생하면보통은 모두가 감지할 겁니다. 2.a 메세지를 보내고 받는다 라고 표현을 해서 좀 혼동하실 수 있는데송신측이 하나의 메세지를 보내는 행위를 끝내면, 그 메세지가 수신측에 전달되는게 아니고캔 통신에서 메세지를 보내는 행위는 사실 메세지를 통째로 보내고 받는게 아니고송신측은 1또는 0의 데이터를 1bit씩 차례차례 쓰는거고, 수신측은 버스를 읽어서 송신측이 보낸 1 또는 0의 데이터를 실시간으로 1비트씩 계속 수신하는겁니다.그러다가 송신측이 앞에서 ID,DLC,Data,CRC에 해당하는 값을 출력한 후에 ack bit 값을 write하는 타이밍일 때, 이때 수신측이 버스에 값 0을 write 한다는 의미입니다..설명이 이해가 돼셨을지 모르겠네요 .. ㅠㅠ2.b 이 부분은 강의에서 잠깐 추가 설명했던 부분인데네트워크에 수신측 제어기가 없는 상태일 때는, ack에러에 의해 에러 카운트가 지속적으로 증가하지만에러 passive 상태까지만 가고 버스오프 상태에 진입하지는 않습니다.ack에러가 발생한 상황이랑, 수신제어기가 없을때의 상황이랑.. 버스에 출력되는 신호의 형태가 달라서이게 구분이 되는데,,, 그 내부 메커니즘 까지 설명하기가 어려워서 설명을 생략했씁니다. 아무튼 결론은 네트워크에 수신 제어기가 없을때는, passive 에러 state 상태를 유지하다가,그 네트워크에 수신 제어기가 새롭게 연결되서 , ack bit를 0으로 보내주면다시 에러카운트가 내려가서 정상동작하게 됩니다.이 부분도.. 너무 자세히 설명하기에는 내용이 너무 복잡해서 제가 설명 생략한 부분이 있어서혼란스러울거 같습니다.근데 결론을 말하면제어기가 에러를 감지하면, 에러 프레임을 전파하게 되고. 그러면 다른 제어기도 에러프레임에 의해 에러를 감지해서 또 에러프레임을 전파하는게 맞습니다.근데 그렇다고 해서 에러가 계속 무한히 전파되는건 아니고..이게 캔통신을 메세지 하나하나 단위로 주고 받는다고 생각하면 이해가 어려운데앞에서 말했듯이 캔 통신은 실제로는 비트상에 0,1을 쓰면서 비트단위로 실시간으로 송수신이 이뤄지는거라는걸 알아야 좀 더 정확한 동작을 이해할 수 있습니다.이거까지 설명하기에 복잡해서 설명을 생략했는데 그래도 글로 써보자면누군가 에러 프레임을 네트워크에 보내면,그걸 수신한 다른 제어기도 하나의 새로운 에러 프레임을 보내는게 아니라실제 버스상에 출력되는 신호 형태로만 얘기하면처음에 누군가가 보낸 에러플래그의 길이가 추가로 더 길어지는 형태인데..보쉬에서 제공하는 실제 캔통신 스펙 문서에 아래 그림과 함께 자세한 설명이 적혀있습니다.(사진)좀 더 구체적인 캔통신의 동작과정을 이해하려면실제로 캔하이, 캔로우에 어떤식으로 신호가 출력되는지그리고 Start of Frame, End of Frame, Delimeter 이런 개념까지 다 알아야되는데이것들을 다 설명하기가 어렵네요.. 이렇게 글로 주절주절 적은 답변이 이해가 될지 모르겠습니다 ㅠㅠ

펌웨어 훼손 & 전자서명 훼손

펌웨어 훼손, 전자서명 훼손의 경우 사실 ISO14229 진단통신 표준과 직접적인 연관은 없습니다.최근 사이버 시큐리티가 중요해지면서차량 제조사에서 다운로드 과정에서 SW암호화,복호화 이런 과정들이 추가됐는데..이 부분은 제조사마다 컨셉이 조금씩 달라서제 강의에서 다루기에는 애매합니다..

업데이트와 OTA

맞습니다. OTA 이전의 기존의 제어기 업데이트 과정입니다. 제 마지막 강의에 OTA에 대한 강의가 있는데 해당 강의를 보면 조금 더 이해가 될 거 같습니다.개념만 말씀드리면, 인터넷(무선통신)을 통해서 자동차 제조사의 서버와 통신할 수 있는 별도의 제어기가 있고, 이 제어기가 통신을 통해 새로 다운로드 할 SW (Hex파일)을 다운로드 받습니다. 이 역할을 하는 제어기를 통신제어기라고 지칭하겠습니다.그리고, 통신제어기는 자동차회사 서버와 인터넷으로 소통할 수 있지만, 차량 내부의 캔 네트워크에도 연결돼 있기 때문에, 다른 제어기와 캔 통신으로 통신이 가능합니다.기존의 다운로드 방식에서 다운로드 할 파일을 전달해주는 캔통신 장치가 하던 역할을, 통신 제어기가 수행해서 다운로드가 이뤄집니다.UDS 진단통신은 OTA 가 나오기 한참전부터 기존에 사용해오던 표준입니다.

MCU 제조사의 IDE 와 EB Tresos Studio 간의 관계

안녕하세요. 이해하신 내용이 맞습니다.저도 아쉬운 부분인데 사실STM CubeIDE나 TI의 CCS 등의툴을 써보면 무료인데다 인터넷에 자료도 많고 쓰기도 편한데다가역할만 놓고보면 MCAL이랑완전 똑같아서 그런 툴들을 활용 못하는게 아쉽습니다. 근데 어쨋든 이해하신대로오토사기반으로 개발 할 때는 그런 툴을 통한 CODE generation 작업은 하지않습니다 대사 Eb tresos와 다른 bsw 툴로 code gen 작업을 하게되고 Ide 툴로는 빌드만하게 됩니다. 그리고 빌드조차도 ide에서 제공하는 툴이 아니라, 기능안전 인증 이슈 등의 이유로 별도의 유료 컴파일러를 사서 빌드하기도합니다.이 경우에는 MCU 제조사가 제공하는 IDE는 아예 사용안하는거죠 대표적인 예를들면 인피니언 aurix의 경우 인피니언에서 제공하는 aurix studio라는 ide에 stm cube ide와 비슷한 기능이 모두제공되는데.해당 ide의 코드제레이션 기능도 사용하지않고. 빌드 할 때 컴파일러도 태스킹 컴파일러라는 유료 컴파일러를 사서 사용하는게 대부분입니다.

부트로더도 업데이트를 하나요?

이 부분도 실무적으로 중요한 부분인데프로젝트마다 사정이 달라서 강의에 담지 못한 내용인데요.보통은 부트로더도 업데이트 할 수 있도록 환경을 구성하긴합니다.대표적인 방법은 부트로더를 2개로 분리해서 개발하는겁니다.하나는 부트로더를 다운로드 받기 위한 부트로더.또 다른 하나는 강의에서 다뤘던 제어sw 다운로드를 위한 부트르더.이렇게 구성하면 제어sw 다운로드 하듯이 부트로더를 리프로그래밍해서 업데이트가 가능합니다

AUTOSAR compliance

안녕하세요. 질문 주신 부분은 저 또한 일을 하면서 항상 궁금했던 부분인데요. 결론만 먼저 말씀드리면 죄송하지만 솔직히 저도 잘 모르겠습니다 ㅠㅠ실제로 일을 하다보면 모든 것을 swc 러너블로 만들어서 사용하기에는 알맞지 않은 경우가 제법 많습니다. (답변 쓰면서 떠오르는 전형적인 예시 : bsw서비스 api는 rte port를 통해서 호출하는게 규칙인데. 그냥 일반 함수처럼 곧바로 api 직접호출)그래서 실제로 오토사가 제시하는 정석적인 방법을 사용하지않고 개발하는 경우가 제법 많이 있습니다. 그러면 저도 이렇게 해도되는건가? 하는 의문을 갖게되는데 그래도 sw동작 효율을 따지면 오토사 룰을 어기는게 낫다고 판단되면 그렇게 많이 해왔습니다. 그리고 이렇게 개발했을때 oem에서 그 정도 레벨까지 따져서 묻고, 확인하는 경우는 제 경험상 없었기 때문에 별 문제는 없었습니다. 결국 고객입장에서 오토사는 최소한의 품질보증(?)을 위한 수단일뿐 오토사 그 자체가 최종목표가 아니기 때문에, 결론적으로는 제품 동작만 잘된다면 오토사 룰을 어기더라도 큰 문제는 없지않을까 싶습니다. 애초에 sw 내부를 그 정도까지 oem에서 일일이 체크하는 경우를 못봤습니다.그렇지만 전세계의 모든 케이스를 제가 다 알고있는건 아니기에 100% 문제없다고 장담드릴수는 없겠습니다..

디버거와 디버깅

안녕하세요.. 질문의 의도를 제가 정확하게 이해를 못했습니다.IDE 에서 브레이크포인트 찍거나, 변수값 확인하거나,변수값 변경하거나, SW를 MCU에 다운로드 하거나 하는 그런 기능이 디버깅 기능이고.이런 기능을 사용 하려면 결국 사용자의 PC와 MCU 간에 서로 소통을 해야되니까중간에 디버거라는 하드웨어가 필요한 것입니다.

adc

안녕하세요. 어떤 것과 헷갈리신건지 모르겠지만일반적으로 MCU 가 제공하는 기능중에 ADC 라고 하면아날로그 to 디지털의 약자로 발생된 전압(아날로그 신호)를 측정해서 측정 값으로 바꿔주는 기능을 의미합니다.혹시 말씀하신 것은 DAC가 아닌지요?

BSW 개발자의 역할

그리고 두번째 질문도질문 자체가 좀 애매한데요.부트로더, UDS 기반의 서비스 구현을 오토사 기반의 SW로 개발할 수도 있고Non Autosar SW로 개발 할 수도 있습니다.어떤게 더 유리한 방법인지를 따져서 정할 문제이고 정해져 있는 규칙은 없습니다. 이건 부트로더,진단통신 SW 뿐만 아니라 어떤 SW 이든 마찬가지인데어떤 SW를 개발하든 꼭 오토사 기반으로 개발할 필요는 없습니다.재사용성 ,개발효율 이런걸 따져서 유리한 방법을 고르면 됩니다,, 실제로 부트로더 sw만 별도로 판매하는 업체들도 있는데그 업체들도 오토사기반으로 개발된 부트로더를 판매하기도하고, 오토사 기반이 아닌 부트로더를 판매하기도 합니다.