FOTA(Firmware over the air)

경로 및 정보 2023. 2. 6. 11:14

NeoIDM FOTA(Firmware over the air) ⑴ - 개요 : 네이버 블로그 (naver.com)

 

NeoIDM FOTA(Firmware over the air) ⑴ - 개요

IoT 디바이스 관리 플랫폼 [ 연재 포스팅 ] NeoIDM FOTA(Firmware over the air)에 대해서 아래...

blog.naver.com

 

 

[ 연재 포스팅 ]

NeoIDM FOTA(Firmware over the air)에 대해서 아래 순서로 연재할 예정입니다.

1. NeoIDM FOTA ⑴- 개요

2. NeoIDM FOTA ⑵ - FOTA Campaign

3. NeoIDM FOTA ⑶ - Lwm2m firmware updates object 와 Update mechanism

​

​

​

NeoIDM FOTA(Firmware Over The Air) - ⑴ 개요

​

NeoIDM FOTA에 대해 알아보기 전에, FOTA가 무엇인지 먼저 말씀드리겠습니다.

​

FOTA(Firmware over the air)란?

​

무선 네트워크(Over the air)를 통해서, 디바이스의 Firmware(펌웨어)와 특정 데이터를 다운로드하여 업데이트하는 것입니다.

​

업데이트 방식에 따라 Full updates와 Incremental updates로 구분할 수 있습니다.

​

▶▶ Full Updates

디바이스의 이전 상태에 관련해서, 새로운 펌웨어(firmware)로 전체를 재 설치(reinstall) 하는 방식입니다.

따라서, 디바이스는 전체 펌웨어(firmware)를 다운로드하여 저장할 수 있는 공간을 제공하여야 합니다.

​

▶▶ Incremental Updates

기존(origin) firmware와 새로운(target) 펌웨어(firmware)와의 차이점(diff 또는 delta)만을 다운로드하여 업데이트하는 방식입니다. Full updates 방식에 비해, 작은 저장 공간을 사용하는 장점이 있습니다.

차이점으로 업데이트하는 방식이기 때문에 diff를 생성하고, 이를 이용하여 새로운 버전으로 업데이트하는 프로그램들이 추가로 필요합니다.

Diff를 생성하는 program을 diff generator, 새로운 버전으로 update 하는 program을 updates agent라 합니다.

​

│ FOTA 종류 │

 
Full Updates
Incremental Updates
방식
새로운 펌웨어로 전체를 재 설치(reinstall) 하는 방식.
차이점(diff 또는 delta)만을 다운로드하여 업데이트하는 방식.
유의사항
디바이스는 전체 firmware를 다운로드하여, 저장할 수 있는 공간을 제공해야 함.
diff를 생성하고, 이를 이용해서 새로운 버전으로 업데이트하는 프로그램들이 추가로 필요.

​

NeoIDM FOTA의 작업 흐름(workflow)과 구성 요소

​

FOTA를 서비스하기 위해서는 diff를 생성, 관리 및 디바이스로 배포하는 기능을 하는 서버의 역할과 diff를 다운로드하고, 업데이트를 수행하는 디바이스의 역할이 필요합니다.

​

FOTA 서비스의 구성 요소와 전체 작업 흐름(workflow)은 아래 [그림 1]과 같습니다.

​

​

│ NeoIDM의 전체 작업 흐름(workflow)│

​

[그림 1] NeoIDM FOTA Work Flow

​

​

│ NeoIDM의 구성요소 │

서버
디바이스
*NeoIDM
Diff Generator
디바이스의 펌웨어(firmware) 버전 간 diff를 생성
NeoIDM
Client
LwM2M 프로토콜을 사용하여, diff를 다운로드하고, 업데이트 진행 상태 및 결과를 서버에 보고
NeoIDM FOTA Campaign
업데이트 대상이 되는 디바이스를 선정하고 업데이트 수행 기간 등을 설정
*NeoIDM
Updates Agent
diff를 사용하여 디바이스 업데이트를 수행.
NeoIDM
Server
LwM2M 프로토콜을 사용하여 디바이스로 diff 다운로드 및 업데이트 실행 명령을 전달.
업데이트 결과를 수집하여
통계 처리 등을 수행.
    

​

​

NeoIDM Diff Generator와 Updates Agent

​

이어서 Incremental updates의 핵심 구성 요소인 Diff generator와 Updates agent에 대해서 좀 더 알아보겠습니다.

​

우선 업데이트 대상이 되는 디바이스 펌웨어(firmware) 데이터는 저장 형태에 따라

File system과 Flash memory system으로 구분할 수 있습니다.

​

File system의 디바이스는 파일들이 업데이트의 대상이 되고,

Flash memory system의 디바이스는 Flash memory의 Block data가 업데이트 대상이 됩니다.

File system과 Flash memory system가 모두 있는 디바이스는 각각 방식에 따라 system을 업데이트해서 적용합니다.

​

다만, NeoIDM Diff Generator는 Windows 또는 Linux OS의 환경의 Server에서 동작하며

NeoIDM Updates Agent는 디바이스 내에서 동작합니다.

​

​

File System을 위한 Diff Generator & Updates Agent

​

File System에 대한 diff를 생성할 수 있습니다.

[그림 2]는 origin version과 target version의 차이점을 나타냅니다.

- Diff Generator는 파일 추가, 삭제, 속성 등의 차이점을 추출합니다.

- Updates Agent는 diff를 사용하여, 파일 추가, 삭제, 속성 변경 등의 작업을 수행합니다.

​

[그림 2] 버전 간 file system 비교

​

Flash memory system을 위한 Diff Generator & Updates Agent

​

Flash memory system에 대한 diff를 생성할 수 있습니다.

[그림 3]은 origin version과 target version의 차이점을 나타냅니다.

- Diff Generator는 flash memory의 차이점을 특정 크기(block) 단위로 추출합니다.

- Updates Agent는 이를 이용하여, 특정 크기(block) 단위로 업데이트를 수행합니다.

​

[그림 3] 버전 간 Flash Memory 비교

​

다음 포스팅에서는 NeoIDM FOTA 연재를 통해서 NeoIDM FOTA Campaign, Lwm2m firmware updates object 와 update mechanism에 대해서 알아보겠습니다.

​

'경로 및 정보' 카테고리의 다른 글

Toyota’s global supplier management network  (0) 2023.02.08
LIN 개요  (0) 2023.02.07
[자동차SW블로그] 차량용 진단 프로토콜 UDS를 이용한 차량 진단 방법 및 Reprogramming 진행 과정  (0) 2023.02.06
자동차 보안기술  (0) 2023.02.06
HKMC 용어 경로  (0) 2023.02.03
블로그 이미지

wtdsoul

,

[자동차SW블로그] 차량용 진단 프로토콜 UDS를 이용한 차량 진단 방법 및 Reprogramming 진행 과정

경로 및 정보 2023. 2. 6. 10:42

자료실 : MDS테크 (mdstech.co.kr)

 

MDS테크

인텔리전트 융합 솔루션 전문기업 MDS테크

www.mdstech.co.kr

UDS(Unified Diagnostic Service) 프로토콜을 이용한 차량 진단 및 Reprogramming

자율주행 기술이 고도화되면서 차량 내 ECU의 개수는 물론, 개별 ECU에 올라가는 프로그램 코드의 양과 복잡도 또한 증가하고 있습니다. 프로그램의 양이 많아지고 복잡해질수록 계획 단계에서 생각하지 못한 오류들이 발생하게 됩니다. 스마트폰 같은 전자기기에서는 이러한 오류 개선을 위한 업데이트가 당연하게 여겨지고 있지만, 사실상 차량용 ECU 또한 이러한 업데이트가 필요합니다. 특히, AUTOSAR가 본격적으로 적용되면서 SW 업데이트에 대한 필요성은 증대되었고, 이에 대한 대비도 필수가 되었습니다.

​

이 글에서는 차량용 진단 프로토콜로 범용화되어있는 UDS(Unified Diagnostic Service) 프로토콜이 SW 업데이트에 적용되는 방식과 해당 기능이 FBL에서 사용되는 방식을 간략히 알아보도록 하겠습니다. 상세한 적용 방법 및 Reprogramming을 위한 FBL 응용에 대해서는 하단의 담당자 연락처로 문의주시기 바랍니다.

차량 진단 프로토콜

차량은 고장이나 사고 등 많은 위험이 따르는 교통수단이기 때문에 이를 방지하기 위해서 반드시 수명주기 동안 차량 상태를 모니터링해야 합니다. 차량에 탑재된 장치로부터 진단 장비로 진단 데이터를 가져오기 위해서는 특별한 진단 프로토콜을 사용해야 하는데, 일반적으로 많이 사용하는 프로토콜이 XCP, OBD, UDS입니다.

 

- UDS(Unified Diagnostic Service) 프로토콜

→ 진단에 중점, 일반적으로 차량 오작동 진단을 목적으로 offline 진단에 사용됨

​

- OBD(On-board Diagnostics) 프로토콜

→ 진단에 중점, onboard ECU 자가 진단 서비스가 주요 목적

​

- XCP(Universal measurement and Calibration Protocol) 프로토콜

→ 주로 진단 데이터 교환을 위해 onboard ECU들을 연결해 주는 확장 가능한 네트워크 생성을 지원, low bandwidth delay나 real-time fault analysis가 요구되는 onboard 진단 시스템에 사용됨

 

UDS 프로토콜

UDS(Unified Diagnostic Services)는 ECU 진단 및 Reprogramming 시 사용할 수 있는 차량용 프로토콜로, 다양한 ECU를 지원하고 특정 국가 및 제조사에 의존적이지 않습니다. 네 개의 계층 모델을 기반으로 하며, OSI 네트워크 모델과 비슷하고 사실상 표준으로 취급되고 있기 때문에 대부분의 Automotive 제조사에서 개발 과정뿐 아니라 차량 AS 시에도 사용하고 있습니다. AUTOSAR 표준에 따르면 UDS(Unified Diagnostics Services)는 ECU reprogramming을 bootloader에 구현할 때 가장 적합한 프로토콜로 생각할 수 있습니다.

 

UDS 적용 예시

1. 오작동 진단

UDS 프로토콜의 주요 사용처 중 하나는 진단입니다. 차량에 문제가 생겼을 때 FCM(Fault Code Memory)에 DTC(Diagnostic Trouble Code)가 저장되는데, 이 정보를 가져오기 위해서 ReadDTCInformation 같은 UDS명령어가 사용됩니다.

 

2. ECU Reprogramming

S/W 업데이트 기능에 적용되는데, 오작동을 일으키는 부분을 업데이트하거나 ECU에 새로운 기능을 추가하기 위해서 사용됩니다.

 

3. Remote routine activation

다른 시스템 테스트를 시작하거나 입력 파라미터 값들의 오작동 여부에 대한 검사를 동시에 해야하는 경우, UDS 프로토콜의 Remote Routine Activation 서비스가 사용될 수 있습니다.

 

4. Data exchange

UDS 프로토콜을 사용해서 ECU 상의 ECU 시리얼 번호 같은 static data 혹은 현재의 센서 값 같은 dynamic data를 읽어올 수 있습니다.

 

ECU Reprogramming에서 사용되는 UDS의 주요 기능

▶ UDS에 의해서 server쪽이 reprogramming mode로 변경되고 reprogramming 시퀀스가 시작

▶ Data 전송의 시작/종료를 핸들링

▶ UDS는 주고받을 data block의 크기와 순서 그리고 data가 저장될 메모리 block을 관리

▶ Client는 UDS 서비스를 통해서 서버에서 실행되는 루틴을 시작하고 멈춤

▶ Client는 UDS서비스를 통해서 서버의 SW reset을 실행

​

FBL(Flash Bootloader)

ECU에 업데이트된 SW 및 보안 패치를 적용해야 하는 경우, FBL이 제공하는 Reprogramming 기능을 사용할 수 있습니다. 일반적으로 FBL SW의 구조는 아래 그림과 같습니다. 통신 프로토콜, UDS, Flash Driver와 같은 Reprogramming을 위한 기능이 포함돼있음을 확인할 수 있고, 상황에 따라 SW 업데이트를 진행하거나 혹은 어플리케이션을 로딩하는 역할을 합니다.

[일반적인 FBL(Flash Bootloader) SW 구조]

​

FBL을 사용한 펌웨어 업데이트

FBL은 시스템 부팅 시 가장 처음 활성화되는 SW 모듈입니다. 업데이트를 처리하기 위한 루틴이 존재하고, 업데이트 시 CRC check나 SeedKey check와 같은 내부 인증 절차를 거치는데, 시스템에 사전 정의된 방식으로 업데이트 바이너리를 검사하고, 확인된 문제가 없다면 Flash 메모리에 업데이트 버전을 복사하게 됩니다. Flash 메모리에 쓰기가 끝나면 다시 한번 기록한 바이너리의 정합성 및 동일성 검사를 하고, 이상이 발견되지 않으면 FBL에서 어플리케이션으로 제어가 넘어가게 됩니다. Reprogramming 관련 FBL 프로세스는 2단계로 구분할 수 있는데, 때로는 명시적으로 별도의 처리 기능별 FBL로 나누어 구현하기도 합니다.

 

​

● 1단계 : MCU 초기화

MCU 리셋 후 FBL의 1단계를 거쳐 MCU가 초기화되면서 시스템을 사용하기 위한 준비를 합니다. CAN을 사용하는 FBL인 경우, CAN 프로토콜이나 CAN Controller가 SW 업데이트를 할 수 있도록 초기화됩니다. 1단계에서는 어플리케이션으로 제어가 넘어가거나 혹은 Reprogramming으로 진입해도 필요한 대응이 가능하도록 MCU 초기화가 진행됩니다. 업데이트가 존재할 경우(혹은 통신채널을 통해서 업데이트 프로세스로 진입하도록 요청된 경우) Reprogramming 프로세스로 진입하고, 아니면 어플리케이션 시작 위치로 점프하면서 제어가 어플리케이션으로 넘어갑니다.

 

​

● 2단계 : Reprogramming

연결된 통신채널로 펌웨어 업데이트 요청이 있을 때 활성화되어 어플리케이션 소프트웨어 업데이트를 진행합니다. 일반적으로 2단계에서는 제어기의 펌웨어를 다운로드 받아서 Flash memory에 reprogram하는 기능을 수행합니다. FBL에는 flash memory에 firmware를 업데이트하기 위해 필요한 flash 루틴 및 UDS 함수들이 포함되어 있습니다. FBL은 UDS 서버 역할을 하며 업데이트를 요청한 UDS client SW와 UDS 명령어 및 응답을 주고받으며 Reprogramming을 진행하게 됩니다. 일반적인 진행 과정을 간단히 설명하면 아래의 그림과 같습니다.

 

 

※ 일반적인 Reprogrammig 진행 과정

 

​

1. ECU 하드웨어 ID와 소프트웨어 ID를 읽고 올바른 장치인지 확인

2. UDS 고급 서비스를 사용할 수 있는 확장된 진단 세션으로 전환

3. Routine control을 사용해서 Reprogramming을 위한 체크사항 확인

4. DTC를 OFF로 설정

5. 진단이 아닌 다른 컨트롤러의 버스 통신을 OFF

6. Programming Session으로 전환

7. Server에 Seed를 요청해서 받은 Seed로 계산된 Key 값을 서버로 전달

8. 누가 ECU 메모리 프로그래밍을 했는지에 대한 정보 기록

9. Flash programming을 위해서 메모리 삭제

10. Reprogramming 작업 시작 요청(데이터의 크기나 메모리 정보에 대한 알림)

11. 블록 단위로 바이너리 다운로드

12. 바이너리 전송이 종료되었음을 알림

13. 전송된 데이터를 검사하고 Reprogramming이 성공했는지 확인

14. ECU를 재부팅

15. 버스 통신을 정상화시킴

16. DTC를 ON으로 설정

17. ECU가 재부팅되고 정상 작동되기 때문에 기본 진단 세션으로 복귀

 

​

지금까지 UDS 프로토콜이 적용된 FBL에서 소프트웨어 업데이트를 위한 Reprogramming에 대해서 간략히 살펴보았습니다. 앞서 언급한 소프트웨어 업데이트를 위해 필요한 FBL 및 UDS Server/Client 기능을 직접 구현하기 위해서는 많은 시행착오가 필요하고, 많은 시간 소요가 예상되기 때문에 특별한 경우가 아니라면 직접 구현은 권장하지 않습니다.

 

​최근에는 FBL 및 업데이트 기능이 개발 플랫폼에 구현된 기능의 일부로 제공되는 경우가 많은데, 여기서 제공되는 모듈에 필요한 설정을 적용하여 사용하는 것이 시간과 비용을 아끼고 더 안전한 시스템을 구축하는데 도움이 될 것 입니다.

​

현대오트론에서 개발한 mobilgene은 현대기아 자동차에서 요구하는 AUTOSAR 규격을 모두 지원하는 개발 플랫폼입니다. AUTOSAR규격의 FBL 및 UDS기반의 Reprogramming 을 위한 기능을 개발 플랫폼에서 제공하고 있기 때문에 기능 구현 자체보다는 사용할 옵션 설정 수준에서 해당 기능을 쉽고 안전하게 적용할 수 있습니다. 자세한 문의는 <문의하기>로 연락주시기 바랍니다.

'경로 및 정보' 카테고리의 다른 글

LIN 개요  (0) 2023.02.07
FOTA(Firmware over the air)  (0) 2023.02.06
자동차 보안기술  (0) 2023.02.06
HKMC 용어 경로  (0) 2023.02.03
ISO/SAE 21434:2021(en), Road vehicles — Cybersecurity engineering  (0) 2023.02.02
블로그 이미지

wtdsoul

,

자동차 보안기술

경로 및 정보 2023. 2. 6. 10:17

C3-2.김휘강 (gagabox.com)

 

 

http://krnet.gagabox.com/board/data/dprogram/2355/C3-2_%B1%E8%C8%D6%B0%AD.pdf

 

'경로 및 정보' 카테고리의 다른 글

FOTA(Firmware over the air)  (0) 2023.02.06
[자동차SW블로그] 차량용 진단 프로토콜 UDS를 이용한 차량 진단 방법 및 Reprogramming 진행 과정  (0) 2023.02.06
HKMC 용어 경로  (0) 2023.02.03
ISO/SAE 21434:2021(en), Road vehicles — Cybersecurity engineering  (0) 2023.02.02
IoTSecurity101/README.md  (0) 2023.02.02
블로그 이미지

wtdsoul

,

HKMC 용어 경로

경로 및 정보 2023. 2. 3. 09:45

현대 기아(HKMC) 용어 정의 : 네이버 블로그 (naver.com)

 

현대 기아(HKMC) 용어 정의

[ 2022.10.18 업데이트 ] SR : Sourcing Request 견적 기준(설계 요구 사양) IRE : Initial Risk ...

blog.naver.com

'경로 및 정보' 카테고리의 다른 글

[자동차SW블로그] 차량용 진단 프로토콜 UDS를 이용한 차량 진단 방법 및 Reprogramming 진행 과정  (0) 2023.02.06
자동차 보안기술  (0) 2023.02.06
ISO/SAE 21434:2021(en), Road vehicles — Cybersecurity engineering  (0) 2023.02.02
IoTSecurity101/README.md  (0) 2023.02.02
SOME/IP Protocol과 Service Discovery 소개 및 개념  (0) 2023.01.30
블로그 이미지

wtdsoul

,

ISO/SAE 21434:2021(en), Road vehicles — Cybersecurity engineering

경로 및 정보 2023. 2. 2. 16:51

ISO/SAE 21434:2021(en), Road vehicles — Cybersecurity engineering

 

https://www.iso.org/obp/ui/#iso:std:iso-sae:21434:ed-1:v1:en

 

www.iso.org

 

Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
SAE International is a global association of more than 128,000 engineers and related technical experts in the aerospace, automotive and commercial-vehicle industries. Standards from SAE International are used to advance mobility engineering throughout the world. The SAE Technical Standards Development Program is among the organization's primary provisions to those mobility industries it serves aerospace, automotive, and commercial vehicle. These works are authorized, revised, and maintained by the volunteer efforts of more than 9,000 engineers, and other qualified professionals from around the world. SAE subject matter experts act as individuals in the standards process, not as representatives of their organizations. Thus, SAE standards represent optimal technical content developed in a transparent, open, and collaborative process.
The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1 and the SAE Technical Standards Board Policy. In particular, the different approval criteria needed for the different types of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and SAE International shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
SAE Technical Standards Board Rules provide that: “This document is published to advance the state of technical and engineering sciences. The use of this document is entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising therefrom, is the sole responsibility of the user.”
Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was jointly prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 32, Electrical and electronic components and general system aspects, and SAE TEVEES18A Vehicle Cybersecurity Systems Engineering Committee.
This first edition of ISO/SAE 21434 cancels and supersedes SAE J3061:2016[37].
The main changes are as follows:
  • — complete rework of contents and structure.
Any feedback or questions on this document should be directed to the user’s national standards body. A complete listing of these bodies can be found at www.iso.org/members.html. Alternatively, to provide feedback on this document, please visit https://www.sae.org/standards/content/ISO/SAE 21434/.

Introduction

Purpose of this document
This document addresses the cybersecurity perspective in engineering of electrical and electronic (E/E) systems within road vehicles. By ensuring appropriate consideration of cybersecurity, this document aims to enable the engineering of E/E systems to keep up with state-of-the-art technology and evolving attack methods.
This document provides vocabulary, objectives, requirements and guidelines related to cybersecurity engineering as a foundation for common understanding throughout the supply chain. This enables organizations to:
  • — define cybersecurity policies and processes;
  • — manage cybersecurity risk; and
  • — foster a cybersecurity culture.
This document can be used to implement a cybersecurity management system including cybersecurity risk management.
Organization of this document
An overview of the document structure is given in Figure 1. The elements of Figure 1 do not prescribe an execution sequence of the individual topics.
Figure 1 — Overview of this document
Clause 4 (General considerations) is informational and includes the context and perspective of the approach to road vehicle cybersecurity engineering taken in this document.
Clause 5 (Organizational cybersecurity management) includes the cybersecurity management and specification of the organizational cybersecurity policies, rules and processes.
Clause 6 (Project dependent cybersecurity management) includes the cybersecurity management and cybersecurity activities at the project level.
Clause 7 (Distributed cybersecurity activities) includes requirements for assigning responsibilities for cybersecurity activities between customer and supplier.
Clause 8 (Continual cybersecurity activities) includes activities that provide information for ongoing risk assessments and defines vulnerability management of E/E systems until end of cybersecurity support.
Clause 9 (Concept) includes activities that determine cybersecurity risks, cybersecurity goals and cybersecurity requirements for an item.
Clause 10 (Product development) includes activities that define the cybersecurity specifications, and implement and verify cybersecurity requirements.
Clause 11 (Cybersecurity validation) includes the cybersecurity validation of an item at the vehicle level.
Clause 12 (Production) includes the cybersecurity-related aspects of manufacturing and assembly of an item or component.
Clause 13 (Operations and maintenance) includes activities related to cybersecurity incident response and updates to an item or component.
Clause 14 (End of cybersecurity support and decommissioning) includes cybersecurity considerations for end of support and decommissioning of an item or component.
Clause 15 (Threat analysis and risk assessment methods) includes modular methods for analysis and assessment to determine the extent of cybersecurity risk so that treatment can be pursued.
Clauses 5 through 15 have their own objectives, provisions (i.e. requirements, recommendations, permissions) and work products. Work products are the results of cybersecurity activities that fulfil one or more associated requirements.
“Prerequisites” are mandatory inputs consisting of work products from a previous phase. “Further supporting information” is information that can be considered, which can be made available by sources that are different from the persons responsible for the cybersecurity activities.
A summary of cybersecurity activities and work products can be found in Annex A.
Provisions and work products are assigned unique identifiers consisting of a two-letter abbreviation (“RQ” for a requirement, “RC” for a recommendation, “PM” for a permission and “WP” for a work product), followed by two numbers, separated by hyphens. The first number refers to the clause, and the second gives the order in the consecutive sequence of provisions or work products, respectively, of that clause. For example, [RQ-05-14] refers to the 14th provision in Clause 5, which is a requirement.

1   Scope

This document specifies engineering requirements for cybersecurity risk management regarding concept, product development, production, operation, maintenance and decommissioning of electrical and electronic (E/E) systems in road vehicles, including their components and interfaces.
A framework is defined that includes requirements for cybersecurity processes and a common language for communicating and managing cybersecurity risk.
This document is applicable to series production road vehicle E/E systems, including their components and interfaces, whose development or modification began after the publication of this document.
This document does not prescribe specific technology or solutions related to cybersecurity.

2   Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

3   Terms, definitions and abbreviated terms

3.1   Terms and definitions

For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
ISO Online browsing platform: available at https://www.iso.org/obp
IEC Electropedia: available at https://www.electropedia.org/
3.1.1
architectural design
representation that allows for identification of components (3.1.7), their boundaries, interfaces and interactions
3.1.2
asset
object that has value, or contributes to value
Note 1 to entry: An asset has one or more cybersecurity properties (3.1.20) whose compromise can lead to one or more damage scenarios (3.1.22).
3.1.3
attack feasibility
attribute of an attack path (3.1.4) describing the ease of successfully carrying out the corresponding set of actions
3.1.4
attack path
attack
set of deliberate actions to realize a threat scenario (3.1.33)
3.1.5
attacker
person, group, or organization that carries out an attack path (3.1.4)
3.1.6
audit
examination of a process to determine the extent to which the process objectives are achieved
[SOURCE:ISO 26262-1:2018 [1], 3.5, modified — The phrase “with regard to” was substituted by "to determine the extent to which" and "are achieved" was added.]
3.1.7
component
part that is logically and technically separable
3.1.8
customer
person or organization that receives a service or product
[SOURCE:ISO 9000:2015 [2], 3.2.4, modified — The phrase “could or does receive” was replaced by “receives”, the phrase “that is intended for or required by this person or organization” was omitted, and the example and note 1 to entry were omitted.]
3.1.9
cybersecurity
road vehicle cybersecurity
condition in which assets (3.1.2) are sufficiently protected against threat scenarios (3.1.33) to items (3.1.25) of road vehicles, their functions and their electrical or electronic components (3.1.7)
Note 1 to entry: In this document, for the sake of brevity, the term cybersecurity is used instead of road vehicle cybersecurity.
3.1.10
cybersecurity assessment
3.1.11
cybersecurity case
structured argument supported by evidence to state that risks (3.1.29) are not unreasonable
3.1.12
cybersecurity claim
statement about a risk (3.1.29)
Note 1 to entry: The cybersecurity claim can include a justification for retaining or sharing the risk.
3.1.13
cybersecurity concept
cybersecurity requirements of the item (3.1.25) and requirements on the operational environment (3.1.26), with associated information on cybersecurity controls (3.1.14)
3.1.14
cybersecurity control
measure that is modifying risk (3.1.29)
[SOURCE:ISO 31000:2018 [3], 3.8, modified — The word "cybersecurity" was added to the term, the phrase “maintains and/or” was deleted, the notes to entry were deleted.]
3.1.15
cybersecurity event
3.1.16
cybersecurity goal
concept-level cybersecurity requirement associated with one or more threat scenarios (3.1.33)
3.1.17
cybersecurity incident
situation in the field that can involve vulnerability (3.1.38) exploitation
3.1.18
cybersecurity information
information with regard to cybersecurity (3.1.9) for which relevance is not yet determined
3.1.19
cybersecurity interface agreement
agreement between customer (3.1.8) and supplier concerning distributed cybersecurity activities (3.1.23)
3.1.20
cybersecurity property
attribute that can be worth protecting
Note 1 to entry: Attributes include confidentiality, integrity and/or availability.
3.1.21
cybersecurity specification
cybersecurity requirements and corresponding architectural design (3.1.1)
3.1.22
damage scenario
adverse consequence involving a vehicle or vehicle function and affecting a road user (3.1.31)
3.1.23
distributed cybersecurity activities
cybersecurity activities for the item (3.1.25) or component (3.1.7) whose responsibilities are distributed between customer (3.1.8) and supplier
3.1.24
impact
estimate of magnitude of damage or physical harm from a damage scenario (3.1.22)
3.1.25
item
component or set of components (3.1.7) that implements a function at the vehicle level
Note 1 to entry: A system can be an item if it implements a function at the vehicle level, otherwise it is a component.
[SOURCE:ISO 26262-1:2018 [1], 3.8, modified — The term “system” has been replaced by “component”, the phrases “to which ISO 26262 is applied” and “or part of a function” have been omitted and the Note 1 to entry has been replaced.]
3.1.26
operational environment
context considering interactions in operational use
Note 1 to entry: Operational use of an item (3.1.25) or a component (3.1.7) can include use in a vehicle function, in production, and/or in service and repair.
3.1.27
out-of-context
not developed in the context of a specific item (3.1.25)
EXAMPLE:
Processing unit with assumed cybersecurity requirements to be integrated in different items.
3.1.28
penetration testing
cybersecurity testing in which real-world attacks are mimicked to identify ways to compromise cybersecurity goals (3.1.16)
3.1.29
risk
cybersecurity risk
effect of uncertainty on road vehicle cybersecurity (3.1.9) expressed in terms of attack feasibility (3.1.3) and impact (3.1.24)
3.1.30
risk management
coordinated activities to direct and control an organization with regard to risk (3.1.29)
[SOURCE:ISO 31000:2018 [3], 3.2]
3.1.31
road user
person who uses a road
EXAMPLE:
Passenger, pedestrian, cyclist, motorist, or vehicle owner.
3.1.32
tailor,verb
to omit or perform an activity in a different manner compared to its description in this document
3.1.33
threat scenario
potential cause of compromise of cybersecurity properties (3.1.20) of one or more assets (3.1.2) in order to realize a damage scenario (3.1.22)
3.1.34
triage
analysis to determine the relevance of cybersecurity information (3.1.18) to an item (3.1.25) or component (3.1.7)
3.1.35
trigger
criterion for triage (3.1.34)
3.1.36
validation
confirmation, through the provision of objective evidence, that the cybersecurity goals (3.1.16) of the item (3.1.25) are adequate and are achieved
[SOURCE:ISO/IEC/IEEE 15288:2015 [4], 4.1.53, modified — The phrase “requirements for a specific intended use or application have been fulfilled” has been replaced by “cybersecurity goals of the item are adequate and are achieved”, note 1 to entry has been omitted.]
3.1.37
verification
confirmation, through the provision of objective evidence, that specified requirements have been fulfilled
[SOURCE:ISO/IEC/IEEE 15288:2015 [4], 4.1.54, modified — The note 1 to entry has been omitted.]
3.1.38
vulnerability
weakness (3.1.40) that can be exploited as part of an attack path (3.1.4)
[SOURCE:ISO/IEC 27000:2018 [5], 3.77, modified — The phrase “of an asset or control” has been omitted; the phrase “by one or more threats” has been replaced by “as part of an attack path”.]
3.1.39
vulnerability analysis
systematic identification and evaluation of vulnerabilities (3.1.38)
3.1.40
weakness
defect or characteristic that can lead to undesirable behaviour
EXAMPLE  1:
Missing requirement or specification.
EXAMPLE  2:
Architectural or design flaw, including incorrect design of a security protocol.
EXAMPLE  3:
Implementation weakness, including hardware and software defect, incorrect implementation of a security protocol.
EXAMPLE  4:
Flaw in the operational process or procedure, including misuse and inadequate user training.
EXAMPLE  5:
Use of an outdated or deprecated function, including cryptographic algorithms.

3.2   Abbreviated terms

CAL cybersecurity assurance level
CVSS common vulnerability scoring system
E/E electrical and electronic
ECU electronic control unit
OBD on-board diagnostic
OEM original equipment manufacturer
PM permission
RC recommendation
RQ requirement
RASIC responsible, accountable, supporting, informed, consulted
TARA threat analysis and risk assessment
WP work product

'경로 및 정보' 카테고리의 다른 글

자동차 보안기술  (0) 2023.02.06
HKMC 용어 경로  (0) 2023.02.03
IoTSecurity101/README.md  (0) 2023.02.02
SOME/IP Protocol과 Service Discovery 소개 및 개념  (0) 2023.01.30
CAN 통신 흐름 (1) CAN 컨트롤러 - CAN 트랜시버 - 버스  (0) 2023.01.30
블로그 이미지

wtdsoul

,

IoTSecurity101/README.md

경로 및 정보 2023. 2. 2. 13:50

IoTSecurity101/README.md at master · V33RU/IoTSecurity101 · GitHub

 

GitHub - V33RU/IoTSecurity101: A Curated list of IoT Security Resources

A Curated list of IoT Security Resources. Contribute to V33RU/IoTSecurity101 development by creating an account on GitHub.

github.com

 

'경로 및 정보' 카테고리의 다른 글

HKMC 용어 경로  (0) 2023.02.03
ISO/SAE 21434:2021(en), Road vehicles — Cybersecurity engineering  (0) 2023.02.02
SOME/IP Protocol과 Service Discovery 소개 및 개념  (0) 2023.01.30
CAN 통신 흐름 (1) CAN 컨트롤러 - CAN 트랜시버 - 버스  (0) 2023.01.30
초기 설정 (1) CAN_BTR (CAN bit timing register)  (0) 2023.01.30
블로그 이미지

wtdsoul

,

SOME/IP Protocol과 Service Discovery 소개 및 개념

경로 및 정보 2023. 1. 30. 22:57

https://jjeongil.tistory.com/177

 

SOME/IP Protocol과 Service Discovery 소개 및 개념

SOME/IP 간략 소개SOME/IP는 "Scalable service-Oriented MiddlewarE over IP"의 약자입니다. 이 미들웨어는 일반적인 자동차 사용 사례와 최소 유선 형식 수준의 AUTOSAR와 호환되도록 설계되었습니다. http://some-ip.c

jjeongil.tistory.com

 

SOME/IP 간략 소개

SOME/IP는 "Scalable service-Oriented MiddlewarE over IP"의 약자입니다. 이 미들웨어는 일반적인 자동차 사용 사례와 최소 유선 형식 수준의 AUTOSAR와 호환되도록 설계되었습니다.  http://some-ip.com/에서 공개적으로 액세스할 수 있는 사양이 제공됩니다. 이번 포스팅에서는 SOME/IP 사양의 기본 구조와 오픈 소스 구현 및 오픈 소스 구현에 대한 간략한 개요를 제공하고자 합니다.

 

먼저 SOME/IP 사양의 세 가지 주요 부분부터 살펴보겠습니다.

 

On-wire format

Protocol

Service Discovery

 

 

SOME/IP On-wire format

원칙적으로 SOME/IP 통신은 IP를 통해 devices 또는 subscribers 간에 전송되는 메시지로 구성됩니다. 다음 그림을 참고하세요.

 

두 장치(A 및 B)가 표시되어 있습니다. Device A는 B에 SOME/IP 메시지를 보내고 하나의 메시지를 반환합니다. 기본 전송 프로토콜은 TCP 또는 UDP를 활용합니다. 메시지 자체에는 큰 차이가 없습니다. 이제 Device B에서 이 메시지에 의해 Device  A에서 호출되는 기능을 제공하는 서비스를 실행하고 있다고 가정하고, 그 답으로 메시지를 보냅니다.

 

SOME/IP 메시지에는 header와 payload의 두 부분이 있습니다. 그림에서 헤더는 주로 식별자입니다:

 

Service ID : 각 서비스의 고유 식별자

Method ID : 0-32767(방법), 이벤트의 경우 32768-65535

Length : 페이로드 길이(바이트)(다음 ID도 포함, 8바이트 추가)

Client ID : ECU 내의 호출 클라이언트에 대한 고유 식별자로, 전체 차량에서 고유해야 합니다.

Session ID : 세션 처리를 위한 식별자. 각 통화에 대해 증가시켜야 합니다.

Protocol Version : 0x01

Interface Version : 주요 서비스 인터페이스 버전

Message Type :

-- REQUEST (0x00) 응답을 기다리는 요청(공백도) 

-- REQUEST_NO_RETURN (0x01) A fire&forget 요청 

-- NOTIFICATION (0x02) 응답이 없을 것으로 예상되는 알림/이벤트 콜백 요청 

-- RESPONSE (0x80) response message

Return Code : 

-- E_OK (0x00) 오류 발생이 없을 시

-- E_NOT_OK (0x01) 지저오디지 않은 오류 발생  

-- E_WRONG_INTERFACE_VERSION (0x08) Interface version 불 일치

-- E_MALFORMED_MESSAGE (0x09) 페이로드의 크기를 줄일 수 없도록 감도화 오류

-- E_WRONG_MESSAGE_TYPE (0x0A) 예상치 못한 메시지 유형 수신 (예를 들어 RE-QUEST_NO_RETURN)

 

정상적인 기능 호출과 클라이언트가 가입한 이벤트에 대한 알림 메시지에 "Requests" 및 "RESPONSE"가 있음을 알 수 있습니다. 오류는 정상적인 응답 또는 알림으로 보고되지만 적절한 반환 코드가 있습니다.

 

payload에는 직렬화된 데이터가 포함되어 있습니다. 위 그림은 전송된 데이터 구조가 기본 데이터 유형만 있는 중첩 구조라는 단순한 경우의 직렬화를 보여주고 있습니다. 이 경우, 구조 요소는 그냥 평평하게 됩니다. 즉, 단순히 적재물에 하나씩 기록된다는 뜻입니다.

 

SOME/IP Protocol

이 섹션에서는 주로 두 가지 사항이 중요합니다.

 

the so-called transport bindings (UDP and TCP)

the basic communication patterns publish/subscribe and request/response.

 

위에서 언급한 바와 같이 기본 전송 프로토콜은 UDP 또는 TCP일 수 있습니다. UDP의 경우 SOME/IP message가 분할되지 않습니다. message가 둘 이상 UDP 패킷에 있을 수 있지만 UDP 패키지는 최대 1400바이트일 수 없습니다. 큰 message는 TCP를 통해 전송되어야 합니다. 이 경우 TCP의 robustness가 사용됩니다. TCP 스트림에서 동기화 오류가 발생하면 SOME/IP 규격에서 다음 message의 시작을 다시 찾기 위해 magic cookies를 호출할 수 있습니다.

 

service interfaces를 인스턴스화해야 하며 동일한 인터페이스의 인스턴스가 여러 개 있을 수 있으므로 정의된 인스턴스(인스턴스 ID)에 대한 추가 식별자가 있어야 합니다. 그러나 인스턴스 ID는 SOME/IP 메시지 header의 일부가 아닙니다. 인스턴스는 전송 프로토콜의 포트 번호를 통해 식별됩니다. 즉, 동일한 인터페이스에서 여러 인스턴스가 동일한 포트에서 제공될 수 없습니다.

 

이제 기본 SOME/IP 통신 패턴을 보여 주는 다음 그림을 보십시오.

 

Remote Procedure Calls에 대한 표준 REQUEST/RESPONSE 메커니즘 외에도 이벤트에 대한 PUBLISH/SUBSCRIBE 패턴도 있습니다. SOME/IP 프로토콜의 이벤트는 항상 이벤트 그룹에 그룹화되므로 이벤트 자체는 가입할 수 없고 이벤트 그룹에만 가입할 수 있습니다. SOME/IP 사양도 "필드"를 알고 있습니다. 이 경우 Setter/Getter 방법이 REQUEST/RESPONSE 패턴을 따르고 있으며 변경사항의 알림 message는 이벤트입니다. Subscription 자체는 SOME/IP Service Discovery을 통해 수행됩니다.

 

 

SOME/IP Service discovery

SOME/IP 서비스 검색은 서비스 인스턴스를 찾고 서비스 인스턴스가 실행 중인지 탐지하고 publish/subscribe 처리를 구현하는 데 사용됩니다. 이것은 소위 말하는 offer messages를 통해 수행됩니다. 즉, 각 device는 이 device에서 제공하는 모든 서비스를 포함하는 메시지를 broadcast(멀티캐스트)합니다. SOME/IP SD messages는 UDP를 통해 전송됩니다. 클라이언트 애플리케이션에 서비스가 필요하지만 현재 제공되지 않는 경우 "find messages"도 보낼 수 있습니다. 다른 SOME/IP SD messages는 이벤트 그룹을 Publish/Subscribe하는 데 사용할 수 있습니다.

 

다음 그림은 SOME/IP SD messaged의 일반적인 구조를 보여줍니다.

 

vsomeip 간단 개요

도입 사례를 구현하기 전에 vsomeip이라고 하는 SOME/IP의 GENIVI 구현의 기본 구조에 대해 간단히 살펴보겠습니다.

 

그림과 같이 vsomeip은 기기 간 SOME/IP communication (외부 통신)뿐만 아니라 내부 프로세스 간 communication 도 포함합니다. 두 Device는 사용된 전송 프로토콜(TCP 또는 UDP)과 해당 매개 변수를 포트 번호 또는 기타 매개 변수로 결정하는 통신 endpoints 을 통해 통신합니다. 이러한 모든 매개 변수는 vsomeip 구성 파일에 설정할 수 있는 구성 매개 변수입니다(json 파일, vsomeip 사용자 설명서 참조). 내부 communication은 로컬 endpoint를 통해 이루어지며, 이 엔드포인트는 Boost.Asio Library를 사용하여 Unix 도메인 소켓에 의해 구현됩니다. 이 내부 통신은 D-Bus 데몬과 같은 중앙 구성 요소를 통해 라우팅되지 않으므로 매우 빠릅니다.

 

중앙 vsomeip 라우팅 관리자는 외부 디바이스로 전송해야 하는 경우에만 messages를 수신하고 외부에서 들어오는 messages를 배포합니다. Device 당 라우팅 관리자는 하나만 있으며, 아무것도 구성되지 않은 경우 실행 중인 vsomeip 애플리케이션도 라우팅 관리자를 시작합니다.

 

vsomeip은 데이터 구조의 직렬화를 구현하지 않습니다. 이는 CommonAPI의 SOME/IP Binding에서 다루고 있습니다. vsomeip은 SOME/IP Protocol과 Service Discovery을 포함합니다.

 

이는 SOME/IP 및 vsomeip에 대한 짧은 소개였습니다  그러나 처음 접하시는 분들에게는 충분할 것입니다. 더 자세한 것은 나중에 예제를 통해 설명하도록 하겠습니다.

'경로 및 정보' 카테고리의 다른 글

ISO/SAE 21434:2021(en), Road vehicles — Cybersecurity engineering  (0) 2023.02.02
IoTSecurity101/README.md  (0) 2023.02.02
CAN 통신 흐름 (1) CAN 컨트롤러 - CAN 트랜시버 - 버스  (0) 2023.01.30
초기 설정 (1) CAN_BTR (CAN bit timing register)  (0) 2023.01.30
AUTOSAR CAN 통신 스택 : AUTOSAR 개발을 위해 반드시 알아야하는 계층형 구조[출처] AUTOSAR CAN 통신 스택 : AUTOSAR 개발을 위해 반드시 알아야하는 계층형 구조  (1) 2023.01.27
블로그 이미지

wtdsoul

,

CAN 통신 흐름 (1) CAN 컨트롤러 - CAN 트랜시버 - 버스

경로 및 정보 2023. 1. 30. 02:13

 

https://joondong.tistory.com/4?category=651471 

 

 

2. CAN 통신 흐름 (1) CAN 컨트롤러 - CAN 트랜시버 - 버스

CAN 통신에서 어플리케이션의 구성과 신호의 흐름을 간단하게 설명하겠습니다.CAN 통신의 회로 구성입니다. STM32F091RC는 MCU 내부에 CAN 컨트롤러는 포함하고 있지만, CAN 트랜시버는 따로 구성해야

joondong.tistory.com

CAN 통신에서 어플리케이션의 구성과 신호의 흐름을 간단하게 설명하겠습니다.

CAN 통신의 회로 구성입니다. STM32F091RC는 MCU 내부에 CAN 컨트롤러는 포함하고 있지만, CAN 트랜시버는 따로 구성해야 하고 대부분의 MCU가 그런 것으로 알고 있습니다. 먼저 CAN 통신은 Logic Low(0V)와 Logic High(3.3V) 신호를 사용하는 UART나 SPI와는 다릅니다. CAN RX는 송신에 전혀 관여하지 않으며, CAN 컨트롤러가 CAN 트랜시버에 Logic Low 신호와 Logic High 신호를 전송할 때는 UART, SPI와 동일하게 0V, 3.3V를 사용하지만, CAN 트랜시버가 버스에 데이터를 보낼 때, CAN Low와 CAN High 신호선은 다음과 같은 상태가 됩니다.

 


  CAN TX
 0 V 3.3 V 
 CAN High  5 V 2.5 V
 CAN Low  1.1 V 2.5 V

 

 

CAN TX가 High여서 CAN Low와 CAN High의 출력 전압이 같아진 상태를 리세시브 상태(버스상 Logic High)이라고 하고, CAN TX가 Low여서 CAN Low와 CAN High의 출력 전압이 달라진 상태를 도미넌트 상태(버스상 Logic Low)이라고 합니다.

 

CAN TX에 의해 변하는 CAN Low와 CAN High는 다시 CAN 트랜시버 내부에서 CAN RX(RXD)로 다시 전송되어 CAN 컨트롤러가 CAN 버스의 상태를 모니터링하게 됩니다. CAN 트랜시버 내부 기능 다이어그램은 다음과 같습니다.

CAN High, CAN Low에서 되돌아 오는 신호는 AND 연산되어 RXD(CAN RX)로 출력됩니다. 즉, 자신이 CAN 버스를 사용하여 무언가를 전송중일 때는 CAN TX와 CAN RX의 신호를 오실로스코프로 관찰해보면 동일한 파형이 관찰됩니다. 그리고 CAN 버스의 신호 상태는 리세시브와 도미넌트가 있습니다. 도미넌트 신호는 리세시브 신호에 우선합니다. CAN 트랜시버 내부의 출력 드라이버는 CAN TX(TXD) 신호가 1일 때 VCC와 GND가 연결된 트랜지스터의 게이트를 조절해서 CANH, CANL 신호가 모두 2.5V가 되게 하고, CAN TX(TXD) 신호가 0일 때 CANH는 5V CANL는 1.2V가 되게 합니다. 임베디드 프로그래밍을 위주로 공부해서 회로에 관해서는 필요한 부분만 찾아 공부하는 식이어서 모르는게 많지만, 내부의 다이오드는 CAN TX(TXD) 신호가 1일 때 다른 노드에서 출력되는 더 높은 CANH 전압과 더 낮은 CANL 전압이 출력 드라이버에 영향을 미치는 것을 방지하고, 리세시브를 출력하는 노드의 출력 드라이버가 CAN 버스에 영향을 미치지 못하게 되는 것 같습니다. 하지만 입력 드라이버는 CAN 버스에 그대로 연결되어 있기 때문에 두개 이상의 노드가 리세시브와 도미넌트를 동시에 출력했을 경우, 버스 상태는 도미넌트가 되고, 버스에 있는 모든 노드는 CAN 버스가 도미넌트라고 인식하게 된다고 생각하는데, 제가 잘못 이해하고 있는 부분이 있다면 알려주세요.

'경로 및 정보' 카테고리의 다른 글

IoTSecurity101/README.md  (0) 2023.02.02
SOME/IP Protocol과 Service Discovery 소개 및 개념  (0) 2023.01.30
초기 설정 (1) CAN_BTR (CAN bit timing register)  (0) 2023.01.30
AUTOSAR CAN 통신 스택 : AUTOSAR 개발을 위해 반드시 알아야하는 계층형 구조[출처] AUTOSAR CAN 통신 스택 : AUTOSAR 개발을 위해 반드시 알아야하는 계층형 구조  (1) 2023.01.27
mobilgene Classic  (0) 2023.01.27
블로그 이미지

wtdsoul

,

초기 설정 (1) CAN_BTR (CAN bit timing register)

경로 및 정보 2023. 1. 30. 01:44

https://joondong.tistory.com/6

 

3. 초기 설정 (1) CAN_BTR (CAN bit timing register)

CAN 프로토콜도 다른 통신 프로토콜과 마찬가지로 여러가지 전송 옵션을 규정하고 있습니다. 따라서 CAN 컨트롤러가 송수신을 시작하기 전에 어떻게 송수신할 지 미리 설정해 두어야 합니다. 전

joondong.tistory.com

 

CAN 프로토콜도 다른 통신 프로토콜과 마찬가지로 여러가지 전송 옵션을 규정하고 있습니다. 따라서 CAN 컨트롤러가 송수신을 시작하기 전에 어떻게 송수신할 지 미리 설정해 두어야 합니다.

 

전송 옵션은 CAN_MCR과 CAN_BTR에서 설정할 수 있습니다. 이 두 레지스터에 대한 설명은 CAN 레퍼런스 매뉴얼에 나와있지만 좀 더 전체적인 관점에서 이해할 수 있도록 레지스터의 비트필드의 기능을 간단히 설명한 다음에 CAN 프로토콜, 제가 알고있는 것을 약간 섞어서 다시 설명해 보겠습니다.

  • BRP (Baud rate prescaler)
    : CAN 컨트롤러에 공급되는 PCLK를 분주하여 타임 퀀텀 주기를 설정합니다.
  • TS1/2 (Time segment 1/2)
    : 비트 세그먼트1/2에 배정할 타임 퀀텀의 개수를 정의합니다. 즉, 비트 세그먼트1/2의 주기를 결정합니다.
  • SJW (Resynchronization jump width)
    : CAN 컨트롤러는 비트 세그먼트1의 주기를 늘리고 비트 세그먼트2의 길이를 줄이는 방식으로 재동기화를 수행하는데, 이때 늘리고 줄일 시간의 길이를 타임 퀀텀 단위로 정의하는 필드입니다.
※ 참고로 주기는 시간과 동일한 의미로 이해하면 됩니다.
 
주의할 것은 타임 퀀텀이 버스상 1비트의 주기가 아니라는 것입니다. 이것은 CAN 통신이 비동기식 통신이기 때문에 네트워크 안에서 각 노드가 개별적으로 동기를 맞춰 나가는 과정과 관련있습니다. CAN 컨트롤러는 버스상 1비트를 4개의 세그먼트로 구성하고, 다시 그 세그먼트를 몇 개의 타임 퀀텀으로 구성합니다. 하지만 타임 퀀텀은 CAN 컨트롤러 내부에서 연산되기 때문에 오실로스코프로 관찰할 수 없습니다. 타임 퀀텀은 BRP에 의해 결정되는 가장 작은 시간 단위로 TS1과 TS2를 사용하여 세그먼트에 타임 퀀텀이 몇 개를 배정하느냐에 따라 각 세그먼트의 주기가 달라지고, 나아가 전체 1비트의 주기가 달라집니다. 즉, 동일한 프리스칼라를 설정해도 각 세그먼트에 배정된 타임 퀀텀의 개수에 따라 1비트의 주기가 달라질 수 있다는 의미입니다. CAN 버스상의 각 노드는 서로 다른 길이의 타임 퀀텀을 가질 수는 있지만, 타임 퀀텀으로 구성되는 1비트의 주기는 모든 노드가 같아야 합니다. 즉, CAN 버스상의 모든 노드의 전송 속도는 동일해야 합니다.
 
4개의 세그먼트는 다음과 같습니다.
  • SYNC_SEG
    : 각 비트의 하강 엣지가 이 SYNC_SEG 안에 들어 있는지의 여부로 동기를 판정합니다. (무조건 1 타임 퀀텀, 설정 불가, 나머지 세그먼트는 설정 가능)
  • PROP_SEG
    : 네트워크의 물리적 지연시간을 보정하기 위해 사용됩니다. 1~8 타임 퀀텀
  • PHASE_SEG 1
    : 위상 오류(위상차)를 보정하기 위해 사용됩니다. (1~8 타임 퀀텀)
  • PHASE_SEG 2
    : 위상 오류(위상차)를 보정하기 위해 사용됩니다. (PHASE_SEG 1의 최대값(8) + 정보처리시간(<= 2타임 퀀텀))
※ STM32에서는 PROP_SEG와 PHASE_SEG 1을 합쳐서 비트 세그먼트 1로 정의합니다.
 
※ STM32에서는 PHASE_SEG 2는 비트 세그먼트 2로 정의합니다.
 
※ 위에 있는 타임 퀀텀의 범위는 각 세그먼트에 대한 가능한 타임 퀀텀입니다. 하지만 두개의 보드에서 동일한 설정을 해도 트랜시버에 따라 어떤 보드는 송신을 하고 어떤 보드는 송신을 못해서 어떻게 정해야 하는지는 잘 모르겠습니다. 그리고 STM32는 PROP_SEG 세그먼트와 PHASE_SEG 1 세그먼트가 비트 세그먼트 1로 정의하고 사용하는데 이 비트 세그먼트의 비트를 조절할 때 PROP_SEG 세그먼트와 PHASE_SEG 1 세그먼트의 비율이 어떻게 되는지도 잘 모르겠습니다..
 

제가 사용한 설정은 48MHz MCU 속도에서 아래 두개 입니다.

프리스칼라   1024  2
 BS1  3  15
 BS2  5  8
 SJW  1  1
 비트타임/속도  192000ns/5208bps  1000ns/1Mbps

 

※ 저는 위상이라는 개념을 어떤 동일한 신호에 대해 어떤 개체가 인식하는 신호의 발생 시점이라고 이해하고 있습니다. 따라서 위상차란 두개 이상의 개체가 인식하는 어떤 신호의 시작 시점의 차이라고 알고 있습니다. 여기서 개체는 회로에서 어떤 부품이 될 수도 있고, 회로에서의 어떤 위치도 될 수 있습니다. 만약 틀렸다면 지적 부탁드립니다.

 

※ 그리고 주의할 점은 1비트는 어떤 세그먼트를 길게하든 짧게하든 최소 8타임 퀀텀에서 최대 25타임 퀀텀으로 구성되어야 합니다. 처음에 뭣도모르고 PHASE_SEG1/2를 1타임 퀀텀으로 해서 테스트해봤는데 통신이 되지 않았습니다. 타임 퀀텀과 세그먼트는 오실로스코프로 관찰할 수 없었지만, PHASE_SEG1/2를 1타임 퀀텀으로 설정하여 1비트가 3타임 퀀텀인 상태에서 위상차가 발생하면 SJW(최소 1타임 퀀텀)만큼 늘리거나 줄이게 되는데, 최소값인 1타임 퀀텀 조차도 3타임 퀀텀에 비해 너무 길어서 그런게 아닌가 추측해봅니다. 즉, 오차를 조정했는데 너무 많이 조정해서 또 다른 오차가 발생하게 되는 것입니다.

 

STM32 CAN 컨트롤러에서 세그먼트들은 1비트에서 다음과 같이 할당됩니다.

CAN RX를 사용한 이유는 앞서 설명했듯이 CAN TX에 따라 달라지는 CAN Low, CAN High 신호가 AND 게이트를 거쳐 CAN 컨트롤러와 연결된 CAN RX로 출력되면, CAN 컨트롤러가 이 신호로 버스의 상태를 모니터링하기 때문입니다. 위의 예에서 RXD는 Logic High 1비트를 출력한 후 Logic Low로 전환하고 있습니다. CAN 컨트롤러는 CAN RX 기준으로 하강 엣지(리세시브->도미넌트)가 SYNC_SEG 안에 있는지의 여부로 동기를 판정합니다. ‘전송’ 파트에서 자세히 설명하겠지만, 버스상의 어떤 노드도 신호를 보내고 있지 않은 상태(리세시브)에서 어떤 노드가 데이터 프레임을 전송하면 전송을 시작한다는 의미로 SOF 신호를 보내게 되는데 이 SOF 신호는 도미넌트 신호 입니다. 이때 CAN RX에서 하강 엣지를 탐지하게 되고 버스상의 모든 노드는 SOF 신호에 SYNC_SEG를 맞춥니다. 이때는 버스상의 모든 노드가 동기화된 상태입니다. (참고로 버스 프리 상태에서는 비트를 세그먼트로 나누어 동기를 잡지 않습니다.) 하지만 SPI 통신처럼 동기를 잡아주는 클록이 따로 없고, 신호선의 길이와 노드들의 상대적인 위치 때문에 오차가 누적되어 하강 엣지가 SYNC_SEG 밖에서 탐지되는 상황이 발생합니다. 이때 하강 엣지가 비트 세그먼트2에서 탐지되면 비트 세그먼트2의 타임 퀀텀 개수에서 SJW에서 설정한 타임 퀀텀의 개수를 빼주어 비트 세그먼트2의 주기를 줄이고, 하강 엣지가 비트 세그먼트1에서 탐지되면 비트 세그먼트1의 타임 퀀텀 개수에서 SJW에서 설정한 타임 퀀텀의 개수를 더하여 비트 세그먼트1의 주기를 늘리는 방식으로 오차를 조정합니다.

참고로 STM32 레퍼런스 매뉴얼(RM0091 837페이지)에선 비트를 판정하는 유효한 엣지를 다음과 같이 정의하고 있습니다.

A valid edge is defined as the first transition in a bit time from dominant to recessive bus level provided the controller itself does not send a recessive bit.

 

‘컨트롤러가 리세시브 비트를 보내고 있지 않다면, 유효한 엣지는 1비트 타임 안에서 도미넌트부터 리세시브 버스 레벨까지의 첫번째 전환으로 정의된다.’ 정도로 해석될 수 있는데요. 이렇게 되면 비트를 판정하는 엣지가 상승 엣지가 되어버립니다. 하지만 어떤 CAN 문서를 찾아봐도 상승 엣지에서 비트를 판정한다는 내용을 찾을 수 없었습니다. 따라서 dominant와 recessive의 위치가 바뀌어야 할 것 같습니다. 아마 레퍼런스 매뉴얼 작성자의 실수라고 생각되지만 다른 의견이 있으면 말씀해주세요.

'경로 및 정보' 카테고리의 다른 글

SOME/IP Protocol과 Service Discovery 소개 및 개념  (0) 2023.01.30
CAN 통신 흐름 (1) CAN 컨트롤러 - CAN 트랜시버 - 버스  (0) 2023.01.30
AUTOSAR CAN 통신 스택 : AUTOSAR 개발을 위해 반드시 알아야하는 계층형 구조[출처] AUTOSAR CAN 통신 스택 : AUTOSAR 개발을 위해 반드시 알아야하는 계층형 구조  (1) 2023.01.27
mobilgene Classic  (0) 2023.01.27
자율주행차 보안 모델 KISA  (0) 2023.01.26
블로그 이미지

wtdsoul

,

AUTOSAR CAN 통신 스택 : AUTOSAR 개발을 위해 반드시 알아야하는 계층형 구조[출처] AUTOSAR CAN 통신 스택 : AUTOSAR 개발을 위해 반드시 알아야하는 계층형 구조

경로 및 정보 2023. 1. 27. 15:23

AUTOSAR CAN 통신 스택 : AUTOS.. : 네이버블로그 (naver.com)

 

AUTOSAR CAN 통신 스택 : AUTOSAR 개발을 위해 반드시 알아야하는 계층형 구조

AUTOSAR CAN 통신 스택: BSW 개발을 위해 반드시 알아야하는 계층형 구조 하드웨어에 독립적(...

blog.naver.com

 

AUTOSAR CAN 통신 스택: BSW 개발을 위해 반드시 알아야하는 계층형 구조

하드웨어에 독립적(#hardware-independent)인 #소프트웨어플랫폼 구축을 위해서 많은 플랫폼들이 #계층형구조 를 도입하여 하위에는 하드웨어 종속적인 모듈들을 배치하고 상위로 갈수록 하드웨어에 독립적인 구조가 될 수 있도록 계층과 모듈들을 구성합니다. #AUTOSAR 도 계층형 구조로 되어있어서 하드웨어에 독립적인 어플리케이션 작성이 가능하지만, 더 정확한 구현과 효과적인 디버깅을 위해서 내부의 계층을 잘 이해할 필요가 있습니다. 특히, #어플리케이션소프트웨어(#ASW)가 아니라 #베이직소프트웨어(#BSW)를 개발하는 입장이라면 계층 간 메시지 전달에 대해서 이해하는 것은 꼭 필요한 일이라고 할 수 있습니다. 

​

이 글에서는 AUTOSAR #CAN통신스택을 살펴보고 메시지 전달 과정과 #CAN통신과 관계된 모듈들을 알아보도록 하겠습니다.

 

통신DB import

통신 모듈들을 설정하기 위해서는 ARXML형태로 구성된 통신 데이터가 필요하기 때문에 모듈 설정에 앞서 ECU에서 사용할 통신 데이터를 import 하게 됩니다. 대부분의 AUTOSAR 솔루션들이 통신 DB를 간편하게 import해서 AUTOSAR 데이터 포맷으로 변환해주는 기능을 갖고 있습니다. 예를 들면 현대오트론에서 개발한 모빌진(mobilgene)도 ARXML파일뿐 아니라, CAN/LIN/Flexray/Ethernet등의 데이터베이스 혹은 엑셀 형식으로 저장된 파일을 drag-drop방식으로 끌어와서 간편하게 AUTOSAR ARXML 형태로 만들어 주는 기능을 제공할 뿐만 아니라, import한 데이터를 모듈들의 의존성을 고려해서 자동으로 설정해주는 기능까지 제공하고 있습니다. 다음 그림은 AUTOSAR 협회 사이트에 공개된 현대오트론 모빌진(mobilgene)의 CAN 관련 설명이니 참고하시기 바랍니다.

​

[그림 1] 현대오트론 mobilgene의 Import Network Design 방법(출처: 현대오트론)

​

[그림 2] 현대오트론 mobilgene의 CAN 통신 예시(출처: 현대오트론)

 

 

CAN 통신스택(Communication Stack)

다음 그림은 통신서비스 제공을 위해 AUTOSAR에서 정의하는 모듈들을 서로 다른 색으로 표현된 계층에(MCU 추상화 계층-빨간색, ECU 추상화 계층-초록색, 서비스 계층-파란색) 나누어 표현한 것으로 계층의 특성에 맞춰 통신 관련 모듈들이 분포되어 있는 것을 알 수 있습니다. 그림의 점선 부분은 적용되는 통신 버스에 따라서 LIN, FlexRay, J1939, XCP, CAN, Ethernet 등이 될 수 있습니다.

[그림 3] AUTOSAR에서 정의하는 모듈 계층

CAN 통신 스택은 기능/역할별로 다음의 세 가지 영역으로 나누어 볼 수 있겠습니다. 

​

1. PDU 송/수신 관련 기능

: CAN 메시지를 송수신 하는 과정에서 PDU 전달과 관련된 기능을 수행하는 모듈들을 포함하고 있습니다. 

2. 통신 상태 제어기능

: 통신 상태를 변경하거나, 이상이 발생했을 때 이에 대한 처리를 담당하는 모듈들을 포함합니다. 

3. 네트워크 관리 기능

: 통신 네트워크를 관리하기 위한 모듈들이 포함되어 있습니다. 

 

[그림 4] CAN 통신 스택의 세 가지 기능

이 글에서는 위에서 언급한 세 가지 중 PDU 송/수신에 관여되는 통신 관련 주요 모듈들을 살펴보고, 통신 스택을 구성하는 모듈 간 PDU 흐름을 살펴보도록 하겠습니다.

 

COM 모듈

통신 스택은 일반적인 CAN통신의 송/수신 기능에 관여하는 모듈들(다음 그림 참고: Com, PduR, CanIf, CAN)로 구성됩니다. COM 모듈을 기점으로 상위 layer는 signal을 사용하고, 하위로는 PDU를 사용합니다. Signal은 전달할 메시지, PDU는 계층 간 메시지 전송을 위한 프로토콜 추상화로 생각할 수 있습니다. 어플리케이션에서 전달된 signal 은, COM의 I-PDU 버퍼에 저장되고 PduR_ComTransmit 함수에 의해서 I-PDU 형태로 PduR로 전달됩니다. 반대로 PDU를 수신 받을 때는 PduR에서 Com_RxIndication 함수를 통해서 수신된 PDU가 있음을 알리고, COM에서는 I-PDU 속 signal을 분석해서 해당 signal과 연결된 callback 함수를 호출하여 수신된 signal이 RTE를 통해서 어플리케이션으로 전달됩니다.

​

[그림 5] Signal/PDU 사이 변경을 위해서 COM 모듈에는 각 signal과 PDU가 정의되어 있는데, 간혹 참조 관계가 틀렸거나 존재하지 않는 경우가 있습니다. AUTOSAR BSW 개발 소프트웨어 DB import 시 자동으로 설정해 줘야 하지만, import과정에서 type 설정을 잘못했거나, 혹은 의존관계 모듈의 버전 문제 등 여러 가지 원인으로 정상적인 설정이 안되는 경우가 있습니다. 이런 경우 직접 확인해서 해당 문제를 수정해 줘야 합니다.

 

 

PDU(Protocol Data Unit)

통신 메세지는 네트워크 계층 간 정보 전달의 편의를 위해서 PDU로 바뀌는데 SDU(Service Data Unit)와 PCI(Protocol Control Information)로 구성됩니다. SDU는 다른 계층 또는 모듈로 전달되는 데이터이고, PCI는 발신지/수신지/순서 번호와 같은 정보들로 계층 간 혹은 모듈 간 PDU 전달을 위해 덧붙이는 정보를 말합니다. 예를 들어 COM에서 전달받은 PDU는 PduR에서는 SDU가 되고, 라우팅 정보가 포함된 PCI가 더해져서 새로운 PDU를 구성하게 됩니다. 아래 그림은 다음 계층의 PCI 정보가 덧붙여 지면서 PDU가 계층 간 전달되는 것을 설명하고 있습니다.

 
​
​
[그림 6] 이렇게 하위 계층으로 이동하면서 PDU는 상위계층에서 만들어진 SDU와 PCI를 헤더에 붙여가는 방식으로 PDU가 지나온 전체 경로를 기억하게 됩니다.

[그림 7] 계층별로 주고받는 정보가 다르기 때문에 다음 그림처럼 계층에 따라 PDU에 붙는 prefix도 달라집니다.

PDU는 AUTOSAR의 CAN 스택 내에서만 사용되는 것이기 때문에 CAN Driver를 통해서실제 전송시에는 PDU형태로 전송되지 않고, 필요한 메시지만 PDU에서 추출하여 네트워크로 전송하게 됩니다.

 

PduR 모듈

COM에서 만들어진 PDU는 PduR(PDU Router)로 전달되어 Routing table을 참고해서 해당 PDU를 전달할 목적지를 설정하는 방식으로 PDU를 목적지로 전송하게 됩니다. PduR모듈은 routing table과 engine으로 구성되는데, Routing table은 각 PDU들의 경로 정보를 가지고 있어서, 여기에 기록되지 않은 PDU는 정상적으로 전달되지 않습니다. Engine은 routing table을 사용해서 PDU가 올바른 경로로 전달될 수 있도록 해주는데, 주요하게는 PDU가 위로 전달되는지 혹은 아래로 전달되는지에 따라서 PDU ID와 API를 연결하여 호출해 주는 기능입니다.

[그림 8] PduR 모듈

PduR의 Gateway 기능을 통해서 서로 다른 Bus간 혹은 서로 다른 Controller간 PDU 송/수신도 가능합니다.

 

간혹 DB Import 과정에서 Multicast 설정이나 Gateway 설정에 해당하는 메시지가 정상적으로 세팅되지 못하거나 그 밖에 다양한 원인으로 PduR에 설정되어야 하는 Gateway가 설정되지 않는 경우가 있습니다. 코드생성 자체가 안되는 경우도 있고, 혹은 나중에 테스트 과정에서 해당 기능이 누락되는 경우도 있습니다. 특히, Gateway 설정이 정상적이지 않은 경우가 빈번합니다.

​

[그림 9] PduR을 기준으로 상위는 Bus나 Controller에 의존성이 없지만,

하위부터는 특정 Bus나 Controller에 의존성을 갖게 됩니다.

​

CanIf 모듈

CanIf 모듈에서는 PDU ID를 확인해서 내부의 Channel을 선택합니다. 각 Channel에 연결된 HOH(Hardware Object Handle)에 PDU를 전달하면, CAN controller의 Hardware Object에 해당 PDU를 write 하고, object flag 값을 1로 설정되면 Transceiver에 의해서 Can frame이 전달됩니다.

 

[그림 10] CanIf 모듈

​

지금까지 설명한 Can 통신 스택의 4가지 주요 모듈을 정리하면 다음과 같습니다. 

COM
- PDU data를 signal 단위로 읽고 쓸 수 있는 interface 제공
- 주기적으로 PDU 송신
- Signal에 대한 timeout, data received, data send 등의 이벤트를 ASW에 통지
PduR
- Routing table에 설정된 PDU reference를 참조하여 source 및 destination 모듈 간에 pdu를 전달
CanIF
- Can driver로부터 수신한 PDU를 상위 layer로 전달
- 상위 layer가 송신한 PDU를 can driver로 전달
- Can controller 및 transceiver를 제어하는 interface 제공
- Bus off 발생을 Can으로부터 받아 CanSM에 전달
CAN
- Can controller의 활성화 및 비활성화 제어
- Can interrupt handler를 제공(Tx, Rx, Busoff 등): interrupt 대신 주기 task를 이용한 Polling 방식도 사용 가능

 

마지막으로, 다음 그림은 CAN 메시지 송신 시 모듈 간 호출되는 API 및 Callback 함수를 정리한 것입니다. 함수명은 환경에 따라 다소 다를 수 있지만, 앞에서 살펴본 CAN 통신 스택의 함수 호출 예로 참고하시기 바랍니다. 

[그림 11] CAN 메시지 송신 시 모듈 간 호출되는 API 및 Callback 함수 정리

​

① RTE API를 통해서 전달할 signal이 COM에 도착하면 COM은 signal을 PDU로 변환하고, PduR로 해당 PDU를 전달하면서 전송 요청을 합니다. 

② PduR은 적절한 전송 모듈을(LIN, CAN, XCP등)을 선택해서 해당 모듈로 PDU를 보내서 전송 요청을 합니다. 

③ CanIf는 PDU ID를 확인해서 연결될 channel을 설정하고, 해당 채널을 통해서 Can driver의 HTH(Hardware Transmission Handle)로 전송하려는 메시지를 전달합니다. 

④ Can driver에서는 HTH에 연결된 Can controller의 Hardware Object에 전달할 메시지를 write하도록 합니다. 

 

'경로 및 정보' 카테고리의 다른 글

CAN 통신 흐름 (1) CAN 컨트롤러 - CAN 트랜시버 - 버스  (0) 2023.01.30
초기 설정 (1) CAN_BTR (CAN bit timing register)  (0) 2023.01.30
mobilgene Classic  (0) 2023.01.27
자율주행차 보안 모델 KISA  (0) 2023.01.26
Hyundai Head Unit Hacking 경로  (0) 2023.01.26
블로그 이미지

wtdsoul

,

공지사항

태그목록

글 보관함

달력

«   2025/01   »
일 월 화 수 목 금 토
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

티스토리툴바