Re-programming 시퀀스에 대한 질문입니다.

[1] Re-Prgoramming 에 대한 표준 문서를 따로 서술해놓은 자료는 없습니다. 하지만 Re-Programming에 사용되는 34, 36, 37 서비스의 경우는 ISO-14229-1 문서에 서술되어 있습니다. 각 서비스들은 해당 표준 문서를 기반으로 구현됩니다. Sequence는 상이할 수 있으나 여태 프로젝트를 진행하면서 위 문서를 따르지 않는 것은 보지 못하였습니다. 더불어 sequence의 경우, 34-36-37 서비스 후가 조금 다를 뿐이지, 34-36-37은 sequential 하게 요청되는 것을 볼 수 있었습니다. 프로젝트 진행하시는데, 도움이 되셨으면 좋겠습니다. [2] 맞습니다. 최근에는 주행중에 데이터를 전송하고 차량을 reboot할 때 업데이트 됩니다. 우선 제가 설명드린 부분은 single core 일 때를 기준으로 강의를 작성했습니다. 종혁님이 말씀하신 부분일 경우 dual core의 제품이여야 할 것입니다. 주행중에는 main core가 동작하되, update할 sw의 데이터는 sub core에 저장했다가 차량이 reboot할 때 새로운 sw로 갈아치는 원리입니다. 강의를 수강해주시고 추가로 질문해주셔서 감사합니다. 좋은 하루 되세요 !

본 강의는 MCU 를 가정하고 진행되는 것일까요?

넵 맞습니다. MCU 제품이라는 가정하에 강의를 로드하였습니다

Downgrade 방지

안녕하세요, 강의를 수강해주셔서 감사합니다. 넵, 최근에 SW 업데이트 기능이 중요시 됨에 따라 Downgrade 방지의 기능도 개발되고 있습니다. 사실 해당 부분에 있어, 반드시 "루틴 컨트롤로 구현되어져야 한다"라는 법규는 따로 없습니다. 하지만, 제 개발 경험을 빗대자면 몇몇 OEM은 루틴 컨트롤($31 Service)를 통해서 RAM에 SW를 Download 후, Downgrade를 체크하여 플래시에 저장합니다. 각 OEM마다 다를 것으로 생각되어집니다. 하지만, 제 생각이지만 해당 기능을 제공하기 위한 서비스는 루틴 컨트롤로 구현하는 것이 적합하다고 보입니다. 감사합니다.

ACK

넵, 이해하신게 맞습니다. 제가 생각하기에 프로그래밍은 제품의 동작도 중요하지만, 에러 처리의 부분도 상당히 중요하다고 생각합니다. 그렇기 때문에 ERROR를 판단했을 때, 이에 대한 처리를 해주어야 하며 그에 따라 위처럼 코딩되어 있을 수도 있습니다. 이를 FSM (Finite State Machine) 이라 칭합니다. 임베디드 프로그램은 유한한 State 내에서 동작하며 각 State에 맞춰 동작하도록 프로그래밍 되어 있을 것입니다. 여기서 Finite에는 Success, Fail 등의 State가 존재할 수도 있을 것이구요. 해당 용어도 참고하시면 좋을 것 같습니다. 감사합니다.

DLC란 것이,

넵, 문의해주신 내용이 맞습니다. 내용을 덧붙이자면, 아시겠지만 우선 DLC를 사용하는 이유는 CAN Transciver가 어느 부분의 데이터까지가 유효한 데이터인지 알기 위한 것으로 생각하시면 좋을 것 같습니다. 03 22 F1 86 05 22 F2 90 27 89 등의 진단 메세지를 보낸다고 가정하겠습니다. 위 두 예제는 22 서비스지만, 각각의 길이가 다릅니다. 두번째 메세지에서 DLC가 없을 경우 만약 22 F2 90 까지만 보냈다면 ECU는 아직 유효한 메세지를 덜 받았는지 혹은 모두 받았는지 판단할 근거가 없습니다. 그렇기 때문에 데이터를 처리하는 과정에서 에러가 발생할 수 있습니다.