다음 강의(사이버 보안 프로세스)가 기대됩니다~~

아구러푸님, 늘 관심 가지고 들어주셔서 감사합니다 ㅎ 다음 강의는 충전 프로토콜 개발에 사용되었던 인증서와 TLS 1.3 에 대해 12월 초까지 업로드 후 25년 1월까지는 사이버 보안 프로세스를 준비하고자 계획하고 있습니다.아구러푸님의 관심 덕에 의욕이 많이 생깁니다 ㅎ 최대한 말씀드린 일정에 업로드 하고자 노력하겠습니다. 감사하고 행복한 나날들이 지속 되었으면 합니다.

Mode Management 관련 모듈 관련 내용 질의

안녕하세요, 아구러프님 ! 강의를 수강 해주셔서 감사합니다 ㅎㅎ아 제가 실수로 업로드를 잘못했나보네요,, 수정해서 재업로드 하도록 하겠습니다.죄송합니다. 그리고 피드백 해주셔서 감사합니다

통신 관련 모듈 관련 강의자료 질문

안녕하세요, 아구러프님 ! 강의를 수강 해주셔서 감사합니다..해당 부분 확인해보았는데, 일부러 뺀 부분입니다.. 왜냐하면, 실제로 개발하는데 사용되었었던 것이라, 공유하거나 배포되면 안될 것 같아, 해당 부분은 설명으로만 대체하였습니다..이해해주시면 감사합니다. :)

오토사 강의 예상 업로드 일정 문의드려요!

강의를 찍을 겨를이 안되어 일정보다 늦어졌네요 ㅜㅜ 다음주면 아마 업로드 될 것 같습니다. 강의를 찾아주셔서 감사합니다 ㅎㅎ 행복한 하루가 되시길 바래요

Transfer data(36) 서비스의 "block sequence counter" 에 대한 질문입니다.

안녕하세요, 종혁님 !음 우선 그런 경우를 보지는 못하였지만, 문서에 아래와 같이 표현되어 있습니다. At the value of FF(16) the blockSequenceCounter rolls over and starts at 00(16) with the next TransferData request message. FF다음 Sequence Counter는 00부터 다시 시작하시는 것으로 이해하시면 될 것 같습니다.감사합니다 ㅎㅎ

31서비스를 사용해서 sig verify 에 대한 응답

음,, 우선 잘못 이해하신 부분이 있는 것 같습니다.요청) 31 01 02 88 79 26 16 ...위 요청을 가정하였을 때, 01 : 이 부분이 2바이트라고 이해하신것 같습니다.01은 두번째 바이트를 의미합니다. 마찬가지로 02 : 이 부분이 3~4byte 자리이기 때문에31 서비스에서 3~4byte 번 째 자리를 의미하는 것입니다.몇번째 바이트에 해당 값이 들어가냐?를 의미한다고 생각하시면 좋을 것 같습니다. 감사합니다.

34 서비스 응답(74 20 0F FF)에 대한 질문입니다.

안녕하세요, 종혁님 !우선 34 다음에 오는 parameter는 dataFormatIdentifer를 의미합니다. 문서를 확인해보면 상위 니블은 압축방식, 하위 니블은 암호화 방식을 의미합니다. 제조사마다 압축방식을 사용할 수도 있고 사용하지 않을 수도 있습니다. 만약 압축방식과 암호화 방식을 사용하지 않는다면 해당 값이 00일 것이고, 압축방식을 변경함에 따라 값이 바뀔 수도 있습니다. 해당 값은 제조사에 따라 다르며, 2가 정확히 의미하는 바가 있는 것은 아닙니다. 우선 00이 아니기 때문에 특정 압축 방식을 사용했구나라고 이해하시는 것이 좋을 것 같습니다. 실제로 개발하다보면 소프트웨어 패키지에 압축 방식을 사용하여, 시간을 단축시키곤 합니다.감사합니다. 좋은 하루 되세요

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마다 다를 것으로 생각되어집니다. 하지만, 제 생각이지만 해당 기능을 제공하기 위한 서비스는 루틴 컨트롤로 구현하는 것이 적합하다고 보입니다. 감사합니다.