SOA의 소프트웨어 아키텍처 설계와 소프트웨어 및 하드웨어 분리 방법론

차세대 중앙 집중식 전자 및 전기 아키텍처를 위해 중앙 + 영역 중앙 컴퓨팅 장치 및 지역 컨트롤러 레이아웃의 사용은 다양한 OEM 또는 Tier1 플레이어에게 필수 옵션이 되었습니다. 중앙 컴퓨팅 장치의 아키텍처와 관련하여. SOC 분리, 하드웨어 격리, 소프트웨어 가상화의 세 가지 방법이 있습니다. 중앙 집중식 중앙 컴퓨팅 장치는 자율 주행, 스마트 조종석 및 차량 제어의 세 가지 주요 영역의 핵심 비즈니스 기능을 통합합니다. 표준화된 지역 컨트롤러에는 전력 분배, 데이터 서비스 및 지역 게이트웨이라는 세 가지 주요 책임이 있습니다. 따라서 중앙 컴퓨팅 장치에는 처리량이 높은 이더넷 스위치가 통합됩니다.

전체 차량의 통합 정도가 점점 높아짐에 따라 점점 더 많은 ECU 기능이 지역 컨트롤러에 흡수될 것입니다. 플랫폼 기반 지역 컨트롤러는 동일한 하드웨어 설계와 동일한 IO 인터페이스를 사용하므로 다양한 모델의 확장성 요구 사항을 더 잘 충족할 수 있습니다. 따라서 지역 제어도 차량 하드웨어 추상화의 중요한 기능을 담당합니다. 두 사람은 원래의 Can 통신 대신 고속 이더넷을 사용해 서로 연결하게 된다. 요약하면 확장 가능한 전자 아키텍처는 모델 간의 하드웨어 차이를 보호하는 것입니다. 통신 네트워크에 얼마나 많은 지역 컨트롤러가 사용되더라도 상호 통신 모드는 동일한 규칙을 따릅니다. 동시에 지역 컨트롤러는 로컬 영역 네트워크 내에서 ECU 기능을 추상화하는 책임도 집니다.

중앙 컴퓨팅 플랫폼을 핵심으로 하는 위의 중앙 집중식 아키텍처는 칩 업그레이드를 지원할 수 있는 통합 센서 및 주변 장치 인터페이스를 설정했으며, 궁극적인 목표는 차량 수명 주기 내에서 하드웨어 업그레이드를 달성하여 수명을 연장하는 것입니다. 자동차의 지능형 수명주기. 각 지역 컨트롤러에는 분산 컴퓨팅 및 통신 프레임워크를 제공하고 다양한 운영 체제 커널의 차이점을 보호하며 상위 측에 통합 서비스 개발 프레임워크를 제공할 수 있는 자체 운영 체제 미들웨어 SOA 코어 미들웨어가 있습니다. 관련 기능에는 서비스 관리, 네트워크 관리, 통신 관리, 업그레이드, 진단, 로그, 상태 등이 포함됩니다.

이 기사에서는 소프트웨어와 하드웨어 분리 방향에 초점을 맞춰 SOA용 소프트웨어와 하드웨어를 배포하는 방법을 설명합니다.

01 SOA의 소프트웨어 아키텍처 설계 원리

다음 그림은 일반적인 SOA 소프트웨어 아키텍처 설계 원리를 보여줍니다. 이 서비스 지향 개발 아키텍처는 실제로 서비스 지향 개발을 위한 SOA 아키텍처 모델 솔루션으로, 제품 관리자가 서비스 설계에 집중할 수 있도록 하며 시스템 소프트웨어는 제품 개발 프로세스에 깊이 관여합니다. 이는 자동차 소프트웨어 위기에 대한 솔루션이기도 합니다. 획기적인 발전입니다. 전체 SOA 아키텍처는 논리적 아키텍처로 구축된 소프트웨어-하드웨어 분리 시스템과 서비스 아키텍처로 완성된 서비스 추상화 및 적응을 통해 궁극적으로 표준화된 서비스 시스템을 구축하는 것으로 요약할 수 있습니다.

전체 논리 아키텍처 설계 프로세스는 다음과 같이 요약될 수 있습니다.

전자 및 전기 아키텍처: 확장 가능한 아키텍처(컴퓨팅 및 통신 아키텍처라고도 함)를 설계하려면 계층화된 설계, 계층화된 테스트 및 계층화된 검증은 개발 단계에서 소프트웨어 변경의 연쇄 반응과 통합 테스트 중 문제의 집중 발생을 방지하여 문제를 더 빨리 발견하고 소프트웨어 버전을 더 빠르게 변경할 수 있도록 합니다.

하드웨어 컴퓨팅 플랫폼: 확장 가능한 하드웨어 플랫폼에는 SOA 기본 서비스 관리 및 SOA 하드웨어 I/O 제어 관리가 포함되어 있으며 자율 주행 시스템의 여러 센서 및 외부 장치와 호환되며 다중 이기종 칩 및 하드웨어 업그레이드를 지원합니다.

운영 체제 커널/서비스 미들웨어: 파일 예약 및 구동의 핵심인 운영 체제는 소프트웨어와 하드웨어 분리 및 하드웨어에서의 소프트웨어 배포를 지원하는 데 있어 최고의 제어 기능을 달성할 수 있습니다.

커뮤니케이션 아키텍처: 커뮤니케이션 아키텍처의 확장성은 플랫폼 기반 모델 개발에서 빠른 적응을 보장할 수 있으며, 모델 개발의 다음 단계에서 커뮤니케이션 확장을 최소화할 수 있습니다. 현재 세대의 제품에서 배우기 위해 수행하면 많은 추가 개발 작업을 수행할 필요가 없으므로 이후 제품 라인 유지 관리에 대한 부담을 크게 줄일 수 있습니다.

차량 제어의 실시간 요구 사항을 충족하기 위해 핵심 네트워크는 TSN과 같은 안정적인 통신 기술을 채택합니다. 지역 컨트롤러 아래의 LAN에서는 CAN 및 Lin과 같은 전통적인 통신 방법이 계속 존재할 것입니다. 근거리 통신망 내 통신은 기존 신호 형태로 수행될 수 있으며, 핵심 이더넷 백본 네트워크에서는 데이터가 서비스 형태로 상호 작용하므로 DDS와 같은 통신 미들웨어가 필요합니다.

서비스 계층/애플리케이션 계층: 표준화된 서비스 계층과 조정 가능한 애플리케이션 계층에는 SOA 시스템 기능 관리, 단위 도메인 기능 관리, 차량 기능 제어 관리 및 클라우드 서비스 관리의 여러 중요한 부분이 포함됩니다.

02 SOA의 장치 추상화 기술

중앙 도메인 제어를 핵심으로 하는 소프트웨어 아키텍처 배포의 핵심 기술을 자세히 분석하기 전에 몇 가지 관련 중요한 개념을 자세히 설명해야 합니다. Autosar의 센서/액추에이터 설계 패턴은 ECU가 전체 아키텍처의 맥락에서 루프의 센서/액추에이터를 처리하는 방법을 설명합니다.

BEG 장치 추상화는 RTE(테스트 실행 환경)에 위치하며 특정 ECU에 연결된 센서 및 액추에이터에서 추상화된 소프트웨어 구성 요소 집합이며 RTE 위에 있습니다. ECU 추상 인터페이스에 액세스할 수 있는 유일한 구성요소입니다. 장치 추상화는 픽셀, 포인트 클라우드, 전압, PWM 신호, 디지털 신호/메시지, 주파수와 같은 센서 및 액추에이터의 원시 신호를 추출하고 물리적 인터페이스(예: 픽셀, 포인트 클라우드, 압력, 질량, 온도 등)를 제공합니다. ) 실제로 장치 추상화는 전압 값, 디지털 신호, 포인트 클라우드 등과 같은 물리적 값의 변환을 완료합니다.

장치 추상화는 플랫폼 소프트웨어와 기본 드라이버 소프트웨어를 통해 다양한 하드웨어 변형 간 애플리케이션 계층 소프트웨어의 상호 교환성을 반영합니다.

표 1 플랫폼 소프트웨어와 장치(센서) 간의 추상적 관계

분리된 센서 신호 보상 종료

추상적 레이어링

기능

작동 원리

작업 세부정보

플랫폼 소프트웨어

원래 획득 값, 출력 전압 값 입력

디커플링 소프트웨어 및 하드웨어 연결

물리적 특성 고유 인터페이스

기계적 특성, 전기적 특성, 기능적 특성 및 절차적 특성을 제공합니다.

전기 장비 드라이버

입력 전압 값, 출력 필터링된 전압 값

센서 측정 값의 가용성 보장

전기 진단을 위한 전기 장비 드라이버 소프트웨어 실행(예: 감지 접지, 배터리) 단락, 개방 회로 등)

노이즈 제거 필터

센서에 외부 전원이 공급될 때 전압 보상

센서 장치 드라이버

입력 전압 값, 픽셀, 포인트 클라우드, 온도 값과 같은 출력 센서 값

다른 센서 차이 항목 분리

센서 장치 드라이버 실행

센서 제어

·필터링 기능(다운샘플링 포함)

가상 장치 드라이버

의 물리적 동작

센서 의미 값을 입력하고 밝기 값 등 보완된 완전한 값을 출력

센서의 가상 장치 드라이버는 소프트웨어 프로그램으로 물리적 표현을 추상화합니다

·신호 품질 평가

·신호 원래 값 대체(센서 신호 품질이 부족한 경우)

·신호 원래 값 보상

·신호 원래 값 검증

·기능 테스트 진단 인터페이스

표 2 플랫폼 소프트웨어와 장치(실행자) 간의 추상적인 관계

추상적 레이어링	기능	작동 원리	작업 내용
플랫폼 소프트웨어	PWM 입력, PWM 값 출력 디커플링 소프트웨어 및 하드웨어 연결	물리적 특성 원본 인터페이스 제공	기계적 특성, 전기적 특성, 기능적 특성 및 절차적 특성을 제공합니다.
전자 장치 드라이버	입력 전압 값, 출력 필터링된 전압 값 액추에이터 실행 프로세스의 유효성을 확인하세요	전기 진단을 위한 전기 장치 드라이버 소프트웨어를 실행합니다(예: 단락 감지) , 개방 회로 등)	디노이징 필터 액추에이터에 외부 전원 공급 시 전압 보상
액추에이터 장치 드라이버	입력 PWM, 출력 보호 및 해당 PWM 값 디커플링 기계적 프로세스 실행 디커플링된 액추에이터 기능 보호	센서 장치 드라이버는 액추에이터의 물리적 동작을 나타냅니다.	·출력 값을 중첩하여 드라이버의 마찰을 극복합니다. ·실행 신호 값을 출력하고 실행이 유효한지 보장합니다. ·출력을 제한합니다. 과도한 손상을 방지하는 값 · 제어 설정값(센서 데이터 폐쇄 루프와 연동) ·한계 및 성능 정보를 제공하는 인터페이스
가상 장치 드라이버	액추에이터 요청 값을 입력하여 출력합니다. 밸브 개방과 같은 PWM 값 솔루션 커플링 실행기 지터, 비선형화, 실행 제한 및 기타 처리	가상 장치 실행기는 실행기의 물리적 표현을 추상화	·제어 터미널 물리적 요청 값 변환 ·선형 값에 대한 비선형 값 변환 ​​ · 기능 테스트를 위한 진단 테스터 인터페이스 · 특수 모드 처리 · 액추에이터 작동 시작 · 설정점을 재정의하거나 필터링하여 액추에이터 위상 지터 제거 · 좌표 액추에이터 안전한 활성화

요약하면 BEG 장치의 추상적 개념과 설계는 다음과 같이 요약될 수 있습니다.

애플리케이션 소프트웨어는 특정 ECU에 연결된 특정 센서 및 액추에이터와 독립적입니다.

코드는 다양한 센서 및 액추에이터 간에 재사용될 수 있습니다.

다양한 코드 공유 협력 모델(소프트웨어 공유)로 다양한 비즈니스 모델 지원

이 디자인 패턴은 장치 추상화라고도 합니다.

장치 추상화는 S&A 계층 모듈의 상향 노출을 해결합니다. 기능과 서비스 인터페이스는 플랫폼 소프트웨어 아래로 연결되어 인터페이스를 최대한 노출하고 소프트웨어와 하드웨어의 분리를 실현하며 S&A 변경으로 인한 소프트웨어 변경을 방지하는 것이 목표입니다.

03 SOA의 장치 추상화 예

여기에서는 SOA 아키텍처에서 장치 추상화를 구현하는 방법을 설명하는 예를 제공합니다. 이 방법은 입력 원시 데이터 원시 데이터를 정의하기 위해 센서 카테고리(예: 레이더, 카메라 등)만 알면 됩니다. 이러한 센서의 특정 연결 방법은 알 필요가 없으며 최종 응용 프로그램 레이어만 알 수 있습니다. 센싱 데이터를 적용해야 합니다.

센서의 장치 추상화를 예로 들면 다음과 같이 표현할 수 있습니다.

먼저 기본 물리 계층의 MCAL은 uC 포트에 액세스하여 데이터를 수집하고 원시 데이터를 제공합니다. 기간(예: 10ms)에서는 전기 제품의 연결 방법과 해당 데이터 의미를 이해할 필요가 없습니다. 예를 들어 원본 이미지 픽셀 데이터는 기본 LiDAR 센서에서 수집되어 마이크로 컨트롤러 MCU/SOC에 입력됩니다.

두 번째로 MCU/SOC는 일정 주기에 따라 해당 물리적 ​​주소에서 해당 포인트 클라우드 값을 꺼내어 I/O 장치를 통해 I/O 하드웨어 추상화 모듈에 전달하고 측정된 데이터 측정 지점을 감지합니다. I/O 하드웨어 추상점을 통해 1차 전기기기가 라우터에 연결되고, 센서는 라우팅 정보와 해석된 원시 데이터를 기반으로 전압값을 계산하고 필터링 처리를 수행합니다. 이 과정에서는 의미를 이해할 필요가 없습니다. 측정된 데이터의

이후 하드웨어 추상화 모듈의 전압 값은 8비트 드라이버에 따라 단계별로 처리되며, 센서 전자 장치 드라이버에 의해 호출되어 기본 원래 값을 생성합니다. 이 값은 센서 가상 장치 보행자, 도로 표지판 등을 통해 가상 장치 Dri를 구동합니다.

마지막으로 AP Autosar의 응용 소프트웨어는 실시간 실행 환경 RTE를 통해 센서 감지 대상 수준의 데이터를 실시간으로 읽어 응용 소프트웨어의 후속 계획 제어 및 의사 결정 제어에 사용됩니다.

위의 예에서 볼 수 있듯이, 장치 추상화에는 다음과 같은 장점이 있습니다. 센서 및 액추에이터의 변경으로 인해 플랫폼 소프트웨어 및 애플리케이션 소프트웨어에 관련 변경이 발생하지 않습니다. 요약하면 대략 다음과 같은 유형의 소프트웨어 및 하드웨어 분리가 발생합니다. 변환으로.

다양한 유형의 감지 센서를 교체하기 위해 ECU 선택은 더 이상 ECU에서 지원하는 신호 분석 모드 모델로 제한되지 않습니다. 예를 들어 NTC 및 PTC 모델을 교체하려면 장치 드라이버에 있는 소프트웨어 모듈만 수정하면 됩니다.

동일한 유형의 센서와 액추에이터 모듈은 동일한 처리 모듈 중 일부를 공유할 수 있습니다. 예를 들어 사이드 뷰 카메라의 처리 모드의 경우 사이드 뷰 카메라 중 하나의 처리 알고리즘을 직접 적용할 수 있습니다. 세 대의 카메라 매개변수만 재보정하면 됩니다. 일부 카메라를 고해상도 카메라로 업그레이드해야 하는 경우 기본 드라이버 소프트웨어와 플랫폼 소프트웨어를 크게 변경할 필요가 없습니다. O 인터페이스. 형식이나 데이터 입력 모드를 변경할 필요는 없지만 이미지 처리를 위한 알고리즘 모듈을 다시 조정해야 합니다. 예를 들어 원래의 저해상도 처리 알고리즘은 실시간을 충족하지 못할 수 있습니다. 이 경우 신경망 가속 모델의 최적화 방법을 연구해야 하지만 전체 알고리즘 아키텍처 모델은 변경되지 않습니다.

04 요약

현재 많은 OEM이 주장하는 개발 방식은 플랫폼 기반 제품 개발이며, 플랫폼화는 소프트웨어와 하드웨어를 분리하는 핵심 아이디어를 강조하며 SOA 아키텍처 모델을 채택하면 제품 라인과 플랫폼 형성이 용이해집니다. 라인은 분업에서 특정 차량 모델 프로젝트를 담당하는 제품 라인, 기술 센터 구축을 담당하는 플랫폼 라인입니다. 새로운 플랫폼을 개발할 때 기술 링크는 매우 길고 복잡합니다. 계층형 아키텍처 설계와 소프트웨어 및 하드웨어 분리 방법은 계층형 테스트 및 검증을 용이하게 하고 통합 테스트의 부담을 줄이며 문제를 보다 완벽하게 발견할 수도 있습니다. 버전 출시 속도를 높입니다.

위 내용은 SOA의 소프트웨어 아키텍처 설계와 소프트웨어 및 하드웨어 분리 방법론의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!