스마트카 기능안전 소프트웨어 아키텍처

01 E-GAS 안전 아키텍처 아이디어

자동차 기능 안전은 전자 및 전기 시스템의 고장으로 인한 인명 피해 위험을 합리적인 범위 내에서 제어하는 ​​것을 목표로 합니다. 다음 그림은 일반적인 전자 및 전기 시스템 하드웨어 구성도입니다. 전자 및 전기 시스템의 구성 요소에는 그림에 보이는 하드웨어 외에 그림에 보이지 않는 소프트웨어도 포함되어 있습니다.

그림 1 일반적으로 사용되는 전자 및 전기 하드웨어 시스템

전자 및 전기 시스템의 오류에는 소프트웨어 및 하드웨어 설계 오류로 인한 시스템 오류와 무작위 하드웨어 오류로 인한 오류가 모두 포함됩니다. . 시스템 아키텍처에 따라 기능적 오류를 예방 및 감지하고, 오류 발생 시 피해를 방지하거나 줄이기 위해 다양한 안전 메커니즘을 설계해야 합니다. 이를 위해서는 이러한 안전 메커니즘을 관리 및 제어하고 기능 안전의 전반적인 개발 어려움을 줄이기 위한 강력한 기능 안전 소프트웨어 아키텍처가 필요합니다.

현재 E-GAS(Standardized E-Gas Monitoring Concept for Gasoline and Diesel Engine Control Units)는 의심할 여지 없이 가장 널리 사용되는 보안 소프트웨어 아키텍처 솔루션입니다. E-GAS는 원래 가솔린/디젤 엔진 관리 시스템을 위한 안전 아키텍처 솔루션으로 제안되었지만 간단한 적용을 거쳐 차체 시스템, 변속기 시스템, 신에너지 3전기 시스템 등에 사용할 수도 있으며 매우 우수한 성능을 발휘합니다. 성능 확장 가능하고 널리 사용됩니다.

아래 그림은 E-GAS의 3레이어 소프트웨어 아키텍처 설계입니다. 소프트웨어는 위에서 아래로 레벨1~3으로 나누어져 있으며, 총 3개의 레이어가 기능 구현 레이어(기능 레벨)입니다. , Level2는 기능 모니터링 레이어(기능 모니터링 레벨), Level3은 컨트롤러 모니터링 레벨입니다. 이 아키텍처는 우수한 계층형 모니터링 프레임워크를 형성하고 기능 안전 분해를 효과적으로 구현합니다. QM(ASIL X) + ASIL X(ASIL X)의 안전 분해 전략이 일반적으로 채택됩니다. 즉, 기능 구현 소프트웨어(레벨 1)는 다음에 따라 개발됩니다. QM 레벨, 기능적 중복 소프트웨어 또는 안전 조치(레벨 2, 레벨 3)는 최고 요구사항 레벨 ASIL X(ASIL X)에 따라 개발되어 기능 소프트웨어의 안전 개발 비용을 효과적으로 줄일 수 있습니다.

그림 2 E-GAS 3계층 모니터링 아키텍처 체계

Level1 기능 구현 계층

Level1은 기능 구현 계층으로, 세부사항 기능적 모터 컨트롤러의 경우 이 계층은 요청된 토크를 모터의 토크 출력으로 변환합니다.

Level2 기능 모니터링 레이어

Level2는 기능 모니터링 레이어로, Level1 기능이 정상적으로 실행되는지 모니터링하는 데 사용됩니다. Level2의 핵심은 Level1이 정상적으로 실행되고 있는지 판단하는 방법을 설계하는 것입니다. Level1이 정상적으로 실행되고 있는지 판단하는 방법은 모니터링되는 기능과 관련되는 경우가 많지만, 모니터링되는 기능마다 소프트웨어 다양화 및 중복성을 통해 판단 방법이 다릅니다. 그러나 합리성 확인과 같이 더 광범위하게 적용되는 일부 판단 방법도 있습니다.

그림 3 타당성 검사

위 그림과 같이 Level2에서 타당성 검사 방법을 사용하여 Level1 기능이 정상적으로 작동하는지 여부를 판단할 때 먼저 이를 기반으로 제어를 계산합니다. 센서에서 입력된 신호가 허용 출력의 합리적인 범위 내에 있는지 확인하고, 액츄에이터에서 피드백된 실제 출력을 계산하여 최종적으로 레벨 1의 실제 출력이 허용 가능한 합리적인 범위 내에 있는지 판단합니다. 합리적인 범위를 벗어나면 레벨 1 기능이 비정상인 것으로 판단하고 오류 처리를 수행한다.

레벨3 컨트롤러 모니터링 레이어

레벨3은 컨트롤러 모니터링 레이어로 주로 세 가지 기능으로 구성됩니다.

전자 및 전기 시스템 하드웨어 진단: 컨트롤러 CPU 코어 오류, RAM 오류, ROM 오류 등과 같은 전자 및 전기 시스템 하드웨어 오류를 모니터링합니다.

독립 모니터링: 컨트롤러 관련 오류가 발생한 후 컨트롤러는 더 이상 안전 관련 로직을 안정적으로 실행할 수 없습니다. 안전을 보장하려면 심각한 MCU 오류 후에도 이를 보장하기 위한 추가 외부 독립 모니터링 모듈이 필요합니다. , 아직 안전한 상태로 진입하는 것은 가능합니다. 이 추가 독립 모니터링 모듈은 일반적으로 감시 기능이 통합된 전원 관리 칩입니다.

응용 흐름 확인: Level1, Level2의 모니터링 프로그램이 정상적으로 실행되는지 모니터링합니다. 이 모니터링 기능은 프로그램 흐름 검사와 Watchdog Feeding을 바인딩하여 구현됩니다. Level1, Level2 관련 모니터링 프로그램이 설정된 순서대로 실행되지 않거나, 지정된 시간 내에 실행되지 않으면 프로그램 흐름 확인에 실패하여 도그를 정상적으로 급식할 수 없어 시스템 안전상태에 진입하게 됩니다.

그림 4 Level3 기능 블록 다이어그램

02 해외 기능 안전 소프트웨어 아키텍처 개발

기능 안전과 소프트웨어 아키텍처에 관해서는 "소프트웨어"부터 시작할 수 있습니다. 기능안전성을 준수하는 아키텍처''와 '기능안전성 소프트웨어 아키텍처' 사이의 관계를 살펴본다.

전자는 소프트웨어 개발 관점에서 기능 안전을 갖춘 소프트웨어 아키텍처 설계 프로세스의 준수에 중점을 둡니다. 즉, 소프트웨어 아키텍처 설계 프로세스는 다음과 같이 ISO 26262에서 제시한 다양한 요구 사항을 충족해야 합니다. , 설계 원칙, 설계 요소 요구 사항, 보안 분석 요구 사항, 오류 감지 메커니즘 요구 사항, 오류 처리 메커니즘 및 설계 검증 방법 등이 있습니다. 그 중 소프트웨어 아키텍처 수준의 보안 분석의 주류 방법은 "소프트웨어 FMEA(Failure Mode and Effects)"입니다. 분석)' 및 '소프트웨어 DFA'(종속 실패 분석)'입니다.

후자는 임베디드 소프트웨어 시스템의 관점에서 시스템 수준의 기능 안전을 지원하는 데 중점을 둡니다. E-Gas 보안 아키텍처의 아이디어를 바탕으로 "계층화된 모니터링 아이디어", "보안 대책" 및 "진단 프레임워크"가 "기능 안전 소프트웨어 아키텍처"의 핵심이며 "계층화된 모니터링 아이디어"와 " 보안 조치'는 위에 나와 있습니다. 기사에서 설명한 대로 이 섹션의 나머지 부분에서는 주로 '진단 프레임워크'에 중점을 둡니다. 우리가 사용하는 기본 소프트웨어 개발 플랫폼이 AUTOSAR CP, AP, non-AUTOSAR인지에 관계없이 기능안전 소프트웨어 아키텍처의 설계 아이디어는 유사하며 여기서는 AUTOSAR CP를 기준으로 설명합니다.

1) 기능 안전 진단 프레임워크 기술 요구 사항

그림 5 오류 응답 시간 및 오류 허용 시간 간격

FTTI(Fault Tolerance Time Interval, Fault Toler)를 결합합니다. 개미 시간 간격) 결함 진단 프로세스를 이해합니다. 결함 발생부터 가능한 위험 발생까지의 기간이 FTTI 시간입니다. 이 기간 동안에는 주로 진단 테스트, 결함 대응 프로세스 및 가능한 위험이 발생하기 전에 안전한 상태로 진입하려는 희망이 있습니다(그림 4.1-8). ). 진단 테스트 프로세스에서는 진단 테스트 트리거링, 오류 확인(디바운스) 등을 고려해야 합니다. 오류 응답 프로세스에서는 합리적인 작동 모드(예: 오류 안전, 오류 작동, 비상 작동 등) 진입, 오류 저장을 고려해야 합니다. , 등.

요약하자면, "진단 프레임워크"의 핵심 설계에서는 진단 테스트 및 오류 대응 프로세스를 포괄하는 것을 고려해야 합니다. 주요 기능 안전 진단 프레임워크 기술 요구 사항은 다음과 같습니다.

• 통합 결함 관리: E-GAS 다계층 모니터링 프레임워크의 각 결함 모니터링 계층에서 보고된 결함의 통합 상태 관리
• 결함 응답 시간 요구 사항: 결함 허용 시간 간격(FTTI)을 충족해야 함 안전 상태 진입 감지) 요구사항
• 독립성 요구사항: 온칩 보안 메커니즘과 기능 간에는 공통적인 원인 문제가 있으며, 독립적인 모니터링(MCU 오프칩 모니터링)이 지원되어야 합니다
• 다양한 요구사항: 소프트웨어 아키텍처는 프레임워크 설계의 일반화 및 지원을 충족해야 합니다. 다양한 보안 전략(프로젝트마다 보안 메커니즘에 대한 요구 사항이 다름)
• 진단 테스트 타이밍: 전원 켜기 및 끄기, 주기, 조건 트리거 등
• 결함 디바운스/지연 확인: 안전 메커니즘의 디바운스 테스트를 지원해야 함 기능, 최소한 시간 기반 및 개수 기반 디바운스 알고리즘 지원
• 진단 이벤트 및 기능 분리: 진단 이벤트 및 기능은 독립적으로 관리되며 a 매핑 관계
• 고장 저장: 고장 정보의 비휘발성 저장 지원

2) 외국 진단 프레임워크 기술의 해석

진단 프레임워크 기술을 해석하기 전에 두 가지 제안이 있습니다. 참고용.

① 제안 1: 필요에 따라 진단 테스트 시기를 결정하세요

a. 전원을 켤 때: 다음은 일반적인 애플리케이션 요구 사항을 기반으로 한 설명입니다. 안전 메커니즘과 해당 기능은 이중 지점을 형성합니다. 잠재적인 다중 지점 오류의 실패율을 줄이기 위해 안전 메커니즘은 일반적으로 시스템 시작 단계(전원이 켜진 경우) 동안 자체 점검을 수행해야 합니다. 또한 다중 프로세서 시스템에서는 진단 테스트 동기화 문제를 고려해야 합니다.

b. 런타임: 크게 정기 진단 테스트와 조건 진단 테스트로 구분됩니다. 진단 주기의 정의에는 FDTI(고장 감지 시간 간격)의 제약 조건을 고려해야 하며, 조건부 진단 테스트는 일반적으로 상태 전환이 발생할 때 또는 기능을 활성화하기 전에 기능을 진단합니다.

c. 전원을 끌 때: 시간이 많이 걸리는 테스트를 수행하도록 선택할 수 있으며 테스트 결과는 일반적으로 다음 시작 시 처리됩니다.

② 권장사항 2: 그룹 진단 테스트 수행

진단 관리(진단 트리거링 및 결함 응답 등 포함)를 용이하게 하려면 심각한 결함/비중대 결함, 진단 테스트 타이밍 및 결함에 따라 그룹화하십시오. 다른 요인. 전원을 켜는 동안 코어 오류, 램 테스트 오류 등과 같은 중대한 오류가 감지되면 오류 응답은 자동 상태(예: MCU가 연속 재설정 상태에 있음)로 처리될 수 있습니다.

그림 6 "기능 안전 진단 프레임워크" 및 "기능 안전 진단 제어 흐름"

E-Gas 3계층 모니터링 프레임워크 Level1(기능 레벨) 및 Level2(기능 모니터링 레벨) )은 ASW(응용 소프트웨어, 즉 그림 4.1-9의 SWC) 계층에 위치하고, Level3(컨트롤러 모니터링 수준)은 BSW(기본 소프트웨어) 계층에 위치한다. "진단 프레임워크"도 BSW 계층에 있습니다. 위에서 언급한 것처럼 주로 진단 테스트와 오류 대응 프로세스를 다루며, 그 구성과 작업 프로세스는 다음과 같습니다.

• BswM과 EcuM은 주로 전원 켜기 및 끄기 관리를 담당하며 각각 STARTUP, UP 및 SHUTDOWN 단계에서 전원 켜기, 런타임 및 전원 끄기에 대한 진단 테스트를 수행합니다
• ASW-Level1(E- 가스 레벨1) 적용 범위 기능 입력/출력 진단, ASW-레벨2(E-Gas 레벨2)는 일반적으로 ASW-레벨1 ASIL 레벨 분해를 실현하기 위해 ASW-레벨1 기능의 중복 알고리즘으로 구현됩니다. ECU 및 MCU 수준에서 하드웨어 오류를 모니터링합니다(ISO26262(2018)-Part5 Annex D 및 MCU 안전 매뉴얼을 참조하는 것이 좋습니다). 레벨 1 및 레벨 2 공통 원인 오류에 대한 진단을 다루고 다음 사항에 대한 질문 및 답변 감시 메커니즘을 구현합니다. "모니터링 컨트롤러"를 사용한 논리 및 시간 독립적 진단
• TestManager는 TestLib 안전 메커니즘의 진단 테스트를 시작하고 해당 테스트 결과를 수집하는 역할을 담당합니다.
• DEM은 E-Gas 레벨 1/2/3의 테스트 결과를 수집합니다. , 진단 이벤트를 디바운스하고 오류 코드를 표시하며 NvM 스토리지를 통해 오류 정보를 제공합니다. FiM은 DEM 진단 테스트 결과(디바운스 후)를 기반으로 구성된 기능을 표시하고 기능 소프트웨어(ASW-Level1)는 표시를 기반으로 기능 억제를 결정합니다.

위 내용은 스마트카 기능안전 소프트웨어 아키텍처의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!