메모리 분할 및 기능 안전 메커니즘 구현-일체 포함-php.cn

1. 애플리케이션 소프트웨어

AUTOSAR 아키텍처에서 애플리케이션 소프트웨어는 RTE 위에 위치하며 상호 연결된 AUTOSAR SWC로 구성됩니다. 이러한 구성 요소는 애플리케이션 소프트웨어 기능의 다양한 구성 요소를 원자적으로 캡슐화합니다.

메모리 분할 및 기능 안전 메커니즘 구현

그림 1: 애플리케이션 소프트웨어

AUTOSAR SWC는 하드웨어 독립적이므로 사용 가능한 모든 ECU 하드웨어에 통합될 수 있습니다. ECU 내에서 정보 교환을 용이하게 하기 위해 AUTOSAR SWC는 RTE를 통해서만 통신합니다.

AUTOSAR SWC에는 내부 기능을 제공하는 많은 함수와 변수가 포함되어 있습니다. AUTOSAR SWC의 내부 구조, 즉 변수와 함수 호출은 헤더 파일을 통해 공개적으로 숨겨집니다. 외부 RTE 호출만 공용 인터페이스에 적용됩니다.

메모리 분할 및 기능 안전 메커니즘 구현

그림 2: SWC

AUTOSAR SWC에는 런타임에 호출해야 하는 함수도 포함되어 있습니다. 이러한 C 함수를 AUTOSAR에서는 Runnable이라고 합니다.

Runnable은 자체적으로 실행될 수 없으며 OS의 실행 가능 개체에 할당되어야 합니다. 이러한 할당은 Runnable의 함수 호출을 OS 작업 본문에 삽입하여 수행할 수 있습니다.

Runnable은 호출 OS-Task의 컨텍스트 내에서 루프 및/또는 이벤트 기반으로 실행됩니다. Runnables에 의한 작업 할당은 그림 3과 4에 따라 수행됩니다.

메모리 분할 및 기능 안전 메커니즘 구현

그림 3: AUTOSAR 계층형 소프트웨어 아키텍처 - Runnables 매핑

2. OS-Applications

그림 4는 그림 3의 관계에 대한 설명을 보여줍니다. 이 다이어그램에 따르면 AUTOSAR SWC의 Runnable은 OS 작업에 할당됩니다.

메모리 분할 및 기능 안전 메커니즘 구현

그림 4: SWC와 OS-응용 프로그램 매핑

AUTOSAR OS-응용 프로그램은 Cohesive를 형성하는 OS 개체(예: 작업, ISR, 일정, 카운터 및 경보)의 모음입니다. 기능 단위. 동일한 OS-응용 프로그램에 속하는 모든 개체는 서로 액세스할 수 있습니다.

OS-애플리케이션의 OS 객체는 다른 AUTOSAR SWC에 속할 수 있습니다. RTE는 SWC 간의 효율적인 통신을 촉진하기 위해 OS 애플리케이션의 모든 구성원이 무제한 액세스 권한을 갖는 메모리 영역을 구현합니다.

OS 애플리케이션은 두 가지 범주로 나뉩니다.

신뢰할 수 있는 OS 애플리케이션: "신뢰할 수 있는 OS 애플리케이션은 런타임 시 모니터링 또는 보호 기능이 비활성화된 상태에서 실행할 수 있습니다. 메모리에 액세스하고 OS 모듈. 신뢰할 수 있는 OS 애플리케이션은 런타임 시 타이밍 동작을 적용할 필요가 없으며 프로세서에서 지원하는 경우 권한 모드에서 실행할 수 있습니다.
신뢰할 수 없는 OS 애플리케이션 실행. 런타임 시 모니터링 또는 보호 기능이 비활성화된 경우는 허용되지 않습니다. 이는 메모리에 대한 액세스를 제한하고, OS 모듈의 API에 대한 액세스를 제한하며, 런타임 시 타이밍 동작을 시행합니다. 프로세서가 지원하는 경우 특권 모드에서 실행할 수 없습니다.

3. 통신 및 코드 공유

그림 4와 그림 3에 따르면 하나의 OS 애플리케이션에는 여러 AUTOSAR SWC 및 관련 Runnable이 포함될 수 있습니다. Runnable만 변수에 직접 액세스하고 해당 SWC에서 함수 호출을 수행할 수 있습니다.

SWC의 내부 함수 호출 및 변수는 외부 인터페이스의 헤더 파일에서 정의가 제공되지 않기 때문에 다른 SWC에서 공개적으로 접근할 수 없으며, 따라서 변수를 통한 직접적인 통신을 계획하고 다른 SWC의 코드를 실행할 수 없습니다. .

그림 5의 코드 공유 예는 이를 보여줍니다. 코드 공유는 SWC 내에서만 허용되며 OS 애플리케이션의 SWC 간에는 공유가 허용되지 않습니다. 다른 SWC와의 통신은 RTE를 통해 수행되어야 합니다. Runnable4는 SWC2.2에 속하는 기능을 수행하지 못할 수도 있습니다.

그림 5: OS 애플리케이션의 코드 공유

4. 애플리케이션 소프트웨어의 메모리 파티션

AUTOSAR ECU의 애플리케이션 소프트웨어는 안전 관련 SWC와 Non-SW로 구성될 수 있습니다. 안전 관련 SWC 구성 요소. ISO26262의 요구 사항에 따라 ASIL 수준이 다른 SWC 간의 간섭 방지가 보장되어야 합니다.

AUTOSAR OS는 OS 애플리케이션을 전용 메모리 영역에 배치하여 메모리 관련 오류로부터 면역됩니다. 이 메커니즘을 메모리 분할이라고 합니다. 하나의 OS-Application의 메모리 파티션에서 실행되는 코드는 다른 메모리 영역을 수정할 수 없기 때문에 OS-Application은 서로 보호됩니다. AUTOSAR OS 사양의 해당 요구 사항은 표 1에 나와 있습니다.

메모리 분할 및 기능 안전 메커니즘 구현

표 1: AUTOSAR OS-OS-애플리케이션의 메모리 파티션

애플리케이션 소프트웨어는 다양한 ASIL 레벨의 SWC로 구성될 수 있습니다. 그러나 ASIL 등급이 다른 SWC를 동일한 OS 애플리케이션에 할당하면 안 됩니다. 메모리 파티셔닝은 동일한 OS 애플리케이션에 할당된 SWC 간에 간섭 면역을 제공하지 않습니다. OS는 다른 OS 애플리케이션이 잘못된 액세스를 수행하는 것을 방지할 뿐입니다. 결함이 있는 SWC가 동일한 OS 애플리케이션에 있는 다른 SWC의 메모리 영역을 수정하는 것을 방지하지 않습니다.

참고: 작업 수준 분할에 대한 자세한 내용은 후속 분할을 참조하세요.

5. SWC의 메모리 파티셔닝

혼합 ASIL SWC는 서로 다른 ASIL 등급의 Runnable로 구성될 수 있으므로 이러한 Runnable 간의 간섭을 지원하지 않는 실행 환경이 필요합니다. 다음과 같은 이유로 인해 다양한 메모리 파티션에서 SWC의 다양한 Runnable을 실행할 수 없습니다.

메모리 파티션은 OS 애플리케이션 수준에서 실행됩니다. 그림 3과 그림 4에서 볼 수 있듯이 SWC는 하나의 OS-Application에만 할당될 수 있으므로 메모리 파티션은 하나만 있습니다. 또한 SWC Runnables는 OS-Applications 작업에 의해서만 호출될 수 있습니다.

그림 6에 표시된 것처럼 SWC Runnable은 여러 OS 애플리케이션의 작업에 배포될 수 없습니다.

메모리 분할 및 기능 안전 메커니즘 구현

그림 6: SWC 및 파티션

메모리 파티션은 동일한 SWC에서 Runnable을 분리하는 데 사용할 수 없습니다. SWC가 서로 다른 ASIL을 가진 Runnable을 포함해야 하고 이러한 Runnable을 간섭 없이 독립적으로 실행해야 하는 경우 OS-애플리케이션 수준의 메모리 분할로는 충분하지 않으며 메모리 분할은 작업 수준에서 수행되어야 합니다. 방법은 그림 7에 나와 있습니다.

메모리 분할 및 기능 안전 메커니즘 구현

그림 7: 작업 수준 파티셔닝

작업 수준 메모리 파티셔닝과 관련된 요구 사항은 표 2의 AUTOSAR OS 사양에 나열되어 있습니다. 약한 단어 "may"를 사용하는 것은 작업 수준 파티셔닝 구현이 AUTOSAR OS에서 선택 사항임을 나타냅니다. 따라서 모든 AUTOSAR OS 구현이 작업 수준 메모리 파티셔닝을 지원하는 것은 아닙니다.

메모리 분할 및 기능 안전 메커니즘 구현

표 2: AUTOSAR OS 요구 사항 – 작업 수준의 메모리 파티셔닝

6. 메모리 파티셔닝 구현

메모리 파티셔닝을 사용하면 시스템 및 소프트웨어 수준에서 다양한 기술 보안 개념을 구현할 수 있습니다. 메커니즘.

그림 8은 가능한 구현을 보여주며 모든 기본 소프트웨어 모듈은 신뢰할 수 있는/모니터링 모드 메모리 파티션에서 실행됩니다(그림 8에서 빨간색으로 강조 표시됨). 일부 SWC는 논리적으로 그룹화되어 별도의 신뢰할 수 없는/사용자 모드 메모리 파티션(녹색으로 강조 표시됨)에 배치됩니다. 선택한 소프트웨어 모듈은 기본 소프트웨어 모듈과 동일한 신뢰/관리 모드 메모리 파티션에 속합니다(그림 8에서 빨간색으로 강조 표시된 네 번째 SWC 참조). 각각 하나 이상의 SWC를 포함하는 신뢰할 수 없는/사용자 모드 파티션이 여러 개 있을 수 있습니다.

메모리 분할 및 기능 안전 메커니즘 구현

신뢰할 수 없는/사용자 모드 메모리 파티션에서 SWC 실행은 제한되며 다른 메모리 영역을 수정할 수 없습니다. 반면 신뢰할 수 있는/모니터링되는 프로그램 메모리 파티션에서 SWC 실행은 제한되지 않습니다.

보안 관련 애플리케이션에 사용되는 최신 마이크로 컨트롤러는 전용 하드웨어(MPU(메모리 보호 장치))를 통해 메모리 파티셔닝을 지원합니다.

참고: 메모리 슬라이싱은 MPU 또는 유사한 하드웨어 기능을 갖춘 마이크로컨트롤러에서 구현된다고 가정합니다.

일반적인 MPU 구현을 사용하면 신뢰할 수 없는 애플리케이션이 마이크로 컨트롤러 주소 공간의 여러 파티션에 액세스하도록 허용될 수 있습니다. 액세스 제어는 읽기, 쓰기 및 실행 액세스의 조합으로 정의됩니다. MPU 구성은 모니터 모드에서만 허용됩니다.

참고: 일부 마이크로컨트롤러 구현에서는 MPU가 프로세서 코어에 통합되어 있습니다. 따라서 MPU는 관련 코어에 대한 액세스만 제어합니다. 다른 버스 마스터(예: DMA 컨트롤러 및 기타 코어)는 이 분할된 MPU 인스턴스에 의해 제어되지 않습니다.

아래 표와 사용 사례는 메모리 보호 장치의 구성이 시스템 요구 사항에서 파생될 때 가능한 시나리오 집합을 보여줍니다. 참고: 이 표는 사용 중인 특정 하드웨어 장치의 기능에 대해 완전하지 않을 수 있습니다.

메모리 분할 및 기능 안전 메커니즘 구현

표 3: 메모리 보호 구성 체계

아이콘 설명:

참고: 성능 측면에서 버스 경합, 인터페이스로 인해 부작용이 있을 수 있습니다. 중재 등

사용 사례 1: SWC가 동일한 파티션에 있습니다.

동일한 파티션에 있는 SWC는 서로의 RAM 영역에 액세스할 수 있으므로 서로의 메모리 내용을 손상시킬 수 있습니다.

사용 사례 2: 서로 다른 파티션의 SWC.
다른 파티션에 있는 SWC는 서로의 RAM 영역에 액세스할 수 없으므로 서로의 메모리 내용을 손상시킬 수 없습니다.
사용 사례 3: MCAL 드라이버
MCAL 드라이버는 읽기/쓰기/초기화와 같은 기능의 모음입니다. 이는 BSW 또는 CDD와 같은 다른 단체에 의해 실행되어야 합니다. 자세한 내용은 그림 8을 참조하세요.
기능 안전 메커니즘 메모리 파티셔닝은 메모리 및 메모리 매핑된 하드웨어에 대한 액세스를 제한하여 보호를 제공합니다. 한 파티션에서 실행된 코드는 다른 파티션의 메모리를 수정할 수 없습니다. 메모리 파티션은 읽기 전용 메모리 세그먼트를 보호할 뿐만 아니라 메모리 매핑된 하드웨어도 보호할 수 있습니다. 또한 사용자 모드에서 실행되는 SWC는 재구성과 같은 CPU 명령에 대한 액세스가 제한되어 있습니다.

메모리 분할 메커니즘은 마이크로컨트롤러 하드웨어(예: 메모리 보호 장치 또는 메모리 관리 장치)의 지원을 통해 구현될 수 있습니다. 잘못된 메모리 액세스를 감지하고 방지하려면 OS에서 마이크로 컨트롤러 하드웨어를 올바르게 구성해야 합니다. 그런 다음 신뢰할 수 없는/사용자 모드 메모리 파티션에서 SWC 실행을 모니터링합니다.

신뢰할 수 없는/사용자 모드 파티션에 메모리 액세스 위반이나 CPU 명령 충돌이 있는 경우 잘못된 액세스가 차단되고 마이크로 컨트롤러 하드웨어에서 예외가 발생합니다. OS 및 RTE는 파티션 종료를 수행하거나 이 파티션의 모든 소프트웨어 파티션을 다시 시작하여 잘못된 소프트웨어 파티션을 제거합니다.

참고: OS의 실제 응답은 보호 후크 구현을 통해 구성할 수 있습니다. 자세한 내용은 OS SWS[i] 설명서를 참조하세요.

참고: AUTOSAR 문서 "응용 프로그램 수준 오류 처리 지침"[ii]은 오류 처리에 대한 추가 정보를 제공합니다. 문서에는 오류 처리가 수행되는 방법과 필요한 데이터(예: 대체 값)를 얻을 수 있는 위치가 설명되어 있습니다. 또한 이 문서에서는 AUTOSAR에서 OS-응용 프로그램/파티션 종료 및 다시 시작을 수행하는 방법에 대한 자세한 지침(사용자 설명서)을 제공합니다.