仿淘宝网站制作,永久免费生成app网页,2021搜索引擎排名,wordpress hacker主题一、智能汽车基础软件平台分类
汽车软件主要分为应用软件和基础软件。应用软件和业务形态高度关联#xff0c;不同控制器的应用软件之间差异较大。基础软件介于应用软件和硬件之间#xff0c;用于屏蔽硬件特性、支撑应用软件。可有效地实现应用软件与硬件之间解耦#xff0…一、智能汽车基础软件平台分类
汽车软件主要分为应用软件和基础软件。应用软件和业务形态高度关联不同控制器的应用软件之间差异较大。基础软件介于应用软件和硬件之间用于屏蔽硬件特性、支撑应用软件。可有效地实现应用软件与硬件之间解耦非常适合平台化最终形成基础软件平台。 根据中国汽车基础软件发展白皮书3.0所描述车用 基础软件平台分为车用基础软件开发平台和车用基础软件验证平台。其中基础软件开发平台包含内核、虚拟化模块中间件功能软件以及与之相配套的开发工具链用于支撑应用软件的快速迭代开发。基础软件验证平台通过调试、分析、仿真、测试等手段验证设计和实现的一致性。 1.1 安全车控基础软件平台
安全车控基础软件开发平台主要面向车辆经典控制领域如动力系统、底盘系统和车身系统等该类基础软件开发平台对实时性和安全性的要求极高。目前主流的安全车控基础软件开发平台兼容 OSEK/ VDX 或 Classic AUTOSAR 标准其功能安全等级需要达到 ASIL-D。
1.2 自动驾驶基础软件平台
自动驾驶基础软件开发平台主要面向智能驾驶领域用于智能驾驶辅助以及全自动驾驶功能的控制器上。目前智能驾驶控制器主要使用的底层操作系统有 QNX 以及 Linux。 与安全车控基础软件开发平台相比对智能驾驶基础软件开发平台的要求主要体现在
强大的计算能力以满足图像识别和决策计算的要求强大的数据吞吐能力以满足多传感器数据的实时接入和处理要求高度的灵活性、扩展性、可编程性以满足多种算法模型的需要易用性以满足 ADAS 和自动驾驶算法所需调试、调优、调测的需要
当前异构分布硬件各单元所要求的功能安全等级有所不同AI 单元需要达到 QM 至 ASIL-B计算单元需要达到 QM 至 ASIL-D。
1.3 信息娱乐基础软件平台
车载信息娱乐基础软件开发平台主要为车载信息娱乐服务以及车内人机交互提供控制平台是汽车实现座舱智能化与多源信息交互的必要运行环境。
车载信息娱乐基础软件开发平台对于实时性、安全性、可靠性的要求处于中等水平既可以使用 Android、Linux 等非实时操作系统也可以使用 QNX、VxWorks 等实时操作系统。为便于应用程序移植当前越来越多的车载信息娱乐基础软件开发平台采用 Android Automotive OS 或其他类 Linux 系统。
随着车辆由单纯的交通工具向智能移动终端转变车载信息娱乐基础软件开发平台需要满足如下要求
支持多样化应用满足支付、娱乐、导航、信息服务等多样化功能需求支持多生态资源将手机端庞大的信息娱乐服务生态资源通过采用相同或类似的操作系统快速移植到车辆智能终端避免重复开发安全通过深度定制达到车辆信息安全和功能安全的标准
1.4 智能座舱软件全景
随着新能源汽车的快速普及智能座舱成为了一个重要的研发方向。智能座舱是汽车内部的控制中心可以提供多种信息和服务包括车辆状态、导航、娱乐等功能。为了实现这些功能智能座舱需要一个可靠、高效的软件平台来支持。
对于智能座舱软件来说主要的功能定义就是上述信息娱乐基础软件平台。
在智能座舱的软件平台中操作系统内核、中间件和虚拟化技术都是非常重要的组成部分。其中操作系统内核是整个软件平台的基础它负责管理硬件资源、提供系统调用和进程管理等功能。常见的操作系统内核有Linux、QNX、RTOS等。
在智能座舱的软件平台中中间件是连接不同组件的重要工具。中间件可以提供消息传递、进程通信、远程调用等服务从而方便系统的开发和维护。优化中间件可以提高系统的可靠性和性能。
虚拟化技术是将物理资源虚拟化为多个逻辑实例的技术。在智能座舱中虚拟化技术可以用于隔离不同的系统组件提高整个系统的可靠性和安全性。常见的虚拟化技术包括Hypervisor和容器技术。Hypervisor是一种虚拟化技术它可以将物理服务器虚拟化为多个虚拟机从而提高整个系统的可扩展性和灵活性。而容器技术则是将操作系统层面进行虚拟化从而提高系统的性能和资源利用率。
二、车用操作系统
2.1 AutoSAR CP
AUTOSAR CP 是 Classical Platform AUTOSAR 的简称广泛用于对实时性、安全性要求高的动力域控、底盘域控、车身域控等方面以达到软硬件解耦、提高开发效率、提升软件复用性等目的。 在智能汽车软件平台领域方面AUTOSAR CP一般不用于信息娱乐域。本文只简要介绍AutoSAR CP的基本概念不做详细解读。
AutoSAR CP的软件分层架构
在 AUTOSAR CP 分层架构中自上而下分别为应用软件层Application Layer、运行时环境 Runtime Environment、基础软件层Basic Software Layer AutoSAR CP Arch
应用软件层
包含若干个软件组件软件组件间通过端口进行交互。每个软件组件可以包含一个或者多个运行实体运行实体中封装了相关控制算法其运行可由 RTE 事件触发。
运行时环境
作为应用软件层与基础软件层交互的桥梁为软硬件分离提供了可能是 VFB 的具体实现。 RTE 可以实现软件组件间、基础软件间以及应用软件组件与基础软件之间的通信。RTE 封装了基础软件层的服务、提供了标准化接口使得应用软件层可以通过 RTE 接口调用基础软件服务。此外 RTE 抽象了 ECU 之间的通信即 RTE 使用标准化接口将 ECU 之间的通信抽象为软件组件之间的通信。
基础软件层
又可分为四层包括服务层、ECU 抽象层、微控制器抽象层和复杂驱动。各层又由一系列基础软件组件构成包括系统服务、存储服务、通信服务等它们主要用于提供标准化的基础软件服务。
服务层提供了汽车嵌入式系统软件常用的一些服务包括系统服务、存储服务以及通信服务三大部分。 还提供包括网络管理、存储管理、模式管理和实时操作系统等服务。ECU 抽象层与 ECU 平台相关但与 微控制器无关包括板级硬件抽象、存储硬件抽象、通信硬件抽象和 I/O 硬件抽象。该层将 ECU 结构进 行了抽象负责提供统一的访问接口实现对通信、存储器或者 I/O 的访问从而不需要考虑这些资源是由微控制器片内还是片外提供的。微控制器抽象层是实现不同硬件接口统一化的特殊层包括微控制器驱动、存储驱动、通信驱动以及 I/O 驱动。通过微控制器抽象层可将硬件封装起来避免上层软件直接对微控制器的寄存器进行操作。最后由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题 难以抽象所以在 AUTOSAR CP 规范中没有被标准化统称为复杂驱动。
如上所述AUTOSAR CP 良好的分层架构为软硬件之间解耦、软件模块之间解耦提供了坚实的保障。
AutoSAR CP的发展历程
对于传统汽车电子开发领域早期使用的OS是OSEK OS, 其中OSEK是德文“Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug”的缩写译为汽车电子开放系统及接口。OSEK OS是一个为满足汽车电子可靠性、实时性、成本敏感性等需求而打造的实时单核操作系统(RTAOS)。
AUTOSAR CP 与 OSEK OS联系
首先AUTOSAR CP是基于OSEK OS继承发展而来所以上述的OSEK OS的基本特点在AUTOSAR CP都能够得到满足所以AUTOSAR CP是向后兼容的也就意味着在OSEK OS上能够运行的应用程序同样也可以在AUTOSAR CP上运行。
除此之外AUTOSAR CP也存在自身的一些独特的基本特点下面将从基本属性与系统基本服务两个方面对比OSEKOS 与AutoSAR CP AutoSAR CP 的优缺点
架构充分解耦导致标准和接口规范繁多。AUTOSAR CP 的规范文档非常详尽但正是两百多个多达几万页的标准文档让一些传统的嵌入式工程师望而止步。同时 AUTOSAR CP 提出了很多新概念比如标定量通过描述文件进行描述应用接口不通过传统全局变量的方式与底层软件交互而是 对接口进行描述定义通过 RTE 统一接口进行匹配等。AUTOSAR CP 的软件开发理念和传统嵌入式工程师的认知偏差也是其普及率不高的原因之一。工具链价格昂贵。目前AutoSAR CP的工具链都是老牌经典的AutoSAR OS公司所有软件授权和开发费用非常高。工具链之间兼容性差影响合作开发的灵活性。由于各厂商对 AUTOSAR CP 规范的理解并不完全一致而且各厂商的工具也并不完全兼容导致 OEM 集成各家供应商开发的软件模块需要花费大量的精力和时间。自动化程度低导致开发和集成效率偏低。基础软件与应用软件的接口集成需要大量的手动配置工 作不仅操作上低效出错率高而且在错误检查方面也不如传统软件集成方便。代码可读性差导致调试困难。这是代码生成工具普遍存在的问题和 MATLAB 的 AUTOSAR 工 具箱生成的代码一样一些 AUTOSAR 工具链的 RTE 代码生成工具生成的代码可读性也较差这给软件 调试带来了不少麻烦。
2.2 AutoSAR AP
在基于域的EEA架构体系中智能座舱域通常使用Linux 或者Android作为操作系统车身控制域一般使用AutoSAR CP自动驾驶域通常使用Linux或者QNX。
新能源汽车在由分布式EE架构向中央计算-区域控制EE架构发展的过程中一些厂商认为需要在中央计算平台中提供一个高灵活高性能且支持SOA的新软件平台-- Adaptive Platform AutoSAR简称AutoSAR AP。
什么是AutoSAR AP
AUTOSAR 组织在 2017 年推出了新的 AUTOSAR 平台—— AUTOSAR AP。AUTOSAR AP 的出现是为了填补高性能计算平台上缺乏好用中间件的空白采用面向对象的 SOA 架构旨在为上层应用提供灵活的软件开发平台同时利用汽车行业经验和优势让所有汽车软件能持续迭代更快更好地量产上车。
不同于传统的AutoSAR CP它们的主要区别在于
AUTOSAR经典平台CP标准满足了深度嵌入式ECU的需求而智能ECU的需求却无法满足。传统ECU的设计目的是专为目标车辆而设计在车辆使用寿命期间不会有特别大的改动。智能ECU则适应新型EE架构的发展引入了以太网高性能计算平台以及OTA软件升级等。因此AUTOSAR主持修订了第二个软件平台规范AUTOSAR自适应平台AP。AP主要提供高性能的计算和通信机制并提供灵活的软件配置例如支持空中软件更新。专门为CP定义的功能如访问电信号和汽车专用总线系统可以集成到AP中但不在标准化的重点中。
AutoSAR AP的分层架构
AutoSAR AP的基本构成包括应用程序层、运行时层、操作系统和硬件抽象层。这些组件通过标准化的接口进行通信和协作以实现整个AUTOSAR Adaptive Platform的功能。 1.应用程序层Application Layer
应用程序层是AUTOSAR Adaptive Platform中的最高层它包括了所有的应用程序组件。应用程序层通过服务层和运行时层与其他组件进行通信和协作以实现整个应用程序的功能。User Application 通过原子服务接口(Atomic Service)获取服务Atomic Service 原子服务提供了一系列的标准化服务例如通信服务、诊断服务、存储服务等。这些服务为应用程序组件提供了一些基本的功能和接口以便它们能够相互通信和协作。
2.运行时层Runtime Layer
运行时层提供了一些基本的软件组件和操作系统服务例如操作系统抽象层、内存管理、进程管理等。这些组件和服务为应用程序组件提供了一个运行环境以便它们能够在AUTOSAR AP中运行。
3.操作系统和硬件抽象层Operating System Layer
AUTOSAR Adaptive Platform使用基于POSIX标准的操作系统例如Linux。操作系统层提供了一些基本的操作系统服务和驱动程序例如文件系统、网络协议栈、设备驱动程序等。这些服务和驱动程序为运行时层和应用程序层提供了底层的支持。硬件抽象层则提供了一个通用的硬件接口以便AUTOSAR Adaptive Platform可以在不同的硬件平台上运行。硬件抽象层将硬件平台与操作系统层和运行时层分开以便AUTOSAR Adaptive Platform可以在不同的硬件平台上进行移植和扩展。
AutoSAR AP的应用场景 根据上述软件架构图可见AutoSAR AP主要作为中间件而存在它支持POSIX操作系统通过服务和API为上层服务提供功能。
在向中央集中式的计算平台发展过程中目前还按自动驾驶域车身和底盘域智能座舱域等进行功能划分。这些域控制器均需得到高性能 MPU 芯片的支撑。基于 POSIX 系统之上的 AUTOSAR AP 平台及相关工具链为应用开发过程中的效率带来显著提高而智能座舱域控制器从生态的角度考虑一般在 Linux 基础之上搭载安卓系统。而诸如 SOA 通信、整车诊断、健康管理的方面则可以参考 AUTOSAR AP 平台标准进行实现。如果考虑到多域融合的发展在舱驾一体化的道路上AutoSAR AP和Android将有很大的可能在Hypervisor的基础上实现统一。 AutoSAR AP的案例
基于AutoSAR AP的应用场景可以以一个OTA升级的案例来进行讲述。
本节主要介绍基于 AP 的智能域控制器后续简称 IDCOTA 升级场景及其实现方案。
IDC 的 OTA 功能可以进行自身应用软件及系统软件、关联器件固件的升级并在数据管理、软件升级、可追溯性、安全验证方面满足 AP 的相关要求。
在OTA的功能实现过程中IDC与外界的数据交互如图所示。 云端OTA云服务器向车端HUT终端信息展现单元 Head Unit Telematics推送升级任务用户确认升级后HUT 会通过网关向 IDC 及 其他 ECU 以 UDS 的形式发送升级指令及升级数据IDC 接收升级指令与数据后在确保安全的情况下 完成软件升级并向 HUT 反馈安装进度及安装结果。
1. 数据传输与管理
a. IDC 内部分为 OTA 进程和 UDS Server 进程UDS Server 进程与 HUT 端交互负责处理、转发 指令和接收软件包OTA 进程处理软件包进行升级。 b. OTA 使用专用的磁盘分区保证有足够的资源来存储软件包及相关数据从而保证数据的安全性。 c. IDC 会进行完整性校验以保证软件包的完整性。 d. OTA 结束后IDC 会删除临时数据最大限度节省空间。
2. 软件升级
a. OTA 采用双分区机制通过活跃分区去升级备份分区升级成功后重启备份分区完成备份分区 和活跃分区的互相切换轻松实现 IDC 上的应用软件、中间件、操作系统、配置数据的安装、更新、删除。 b. OTA 采用双分区机制通过切换启动分区可以实现 IDC 上所有软件及数据的快速回滚功能。 c. OTA 支持周边器件的升级如 MCU、相机等。 d. OTA 内部维护状态机状态变化实时落盘可以支持在异常中断后恢复升级。
3. 可追溯性
a. OTA 提供获取当前软件版本号、安装进度、安装结果的接口。 b. OTA 会记录升级过程中的日志供 HUT 获取。
4. 安全性
a. OTA 在软件升级前会使用强加密算法校验证书链与软件包签名保证软件包的真实性及完整性。 b. OTA 在软件升级前会检查当前车速、IDC 的温度、供电情况保证在安全的情况下进行 IDC 软件 升级。 c. OTA 时会激活 IDC 心跳监控机制及分区损坏回滚机制当切换到备份分区启动失败后IDC 不会 给 MCU 发送心跳报文MCU 会认为 IDC 在 OTA 后变砖会给 IDC 断电重启切回原分区启动保证车机可用。
2.3 虚拟化Hypervisor
为什么需要虚拟化
随着汽车电子电气架构从分布式架构到Domain域架构再到中央计算-区域控制架构的演变分散的ECU 功能集成到车载中央计算机这就是多域融合的趋势。 汽车电子底层硬件不再是由单一芯片提供简单的逻辑计算而是需要复杂的多核 SoC 芯片提供更为复杂控制逻辑以及强大的算力支持。但是多域业务具有不同的技术需求比如座舱域业务强调交互体验、应用生态丰富比较适合的操作系统是 Android车控域有实时性、可靠性要求操作系统倾向于 RTLinux、RTOS智驾域强调大算力融合感知、推演规划也有实时性、可靠性要求也会选择RTLinux、RTOS。
在未来多域融合技术集成到一颗SOC之上时需要考虑关键业务的安全可靠和实时性技术要求又要考虑到丰富的生态应用这些需要不同的操作系统才能支持。如何在一颗SOC上划分资源并发运行多种操作系统保证多域融合的可靠性需要有资源隔离技术的支持。
资源隔离技术有多种从硬件底层逐层向上包括硬件隔离、虚拟化隔离、容器隔离、进程隔离等。硬件隔离的隔离性最好性能、安全、可靠性都有保证但灵活性、可配置性差不能实现硬件共享 导致整个系统的资源利用率差不能充分达到软件定义汽车的目标。容器隔离、进程隔离可以更轻量级地实现业务隔离但还是在同一个操作系统内存在着资源干扰、相互安全攻击的隐患并且无法支持异构操作系统业务域融合影响传统业务继承不利于生态发展。
目前在智能座舱域的实际应用中硬件隔离和虚拟化隔离都有实际的使用范例。
Hypervisor
在新能源汽车智能座舱中虚拟化技术也被广泛应用以提高系统的资源利用率、可靠性和安全性。虚拟化技术可以将一台物理服务器划分成多个虚拟机每个虚拟机都可以独立运行不同的应用程序和操作系统。
虚拟化技术可以分为两种类型一种是基于Type1类型的Hypervisor的虚拟化技术另一种是基于Type2类型的虚拟化技术。
Type1类型的Hypervisor是一种直接运行在物理服务器硬件上的虚拟化软件也被称为裸机Hypervisor。Type1类型的Hypervisor能够直接访问服务器的硬件资源包括处理器、内存、网络和存储等能够提供更高的性能和稳定性。在智能座舱中Type1类型的Hypervisor可以被用来运行多个虚拟机每个虚拟机可以运行不同的操作系统和应用程序。同时Type1类型的Hypervisor还可以提供强大的安全隔离功能确保不同的虚拟机之间互不干扰从而提高整个系统的可靠性和安全性。
相比之下基于Type2的虚拟化技术则是运行在操作系统之上的虚拟化技术。虚拟机OS可以与主机OS共享同一个操作系统内核这样可以减少虚拟化层的开销和系统资源的占用。虚拟机OS位于主操作系统之上可以将应用程序及其依赖项封装成一个完整的软件单元从而实现应用程序的快速部署和扩展。在智能座舱中基于Type2的虚拟化技术可以用于隔离不同的应用程序和服务。 Type 1类型的Hypervisor直接运行在物理硬件之上直接访问物理硬件并管理所有硬件资源在延时、安全性和效率上更胜一筹。但此类型Hypervisor需要硬件支持移植难度大开发成本也较高在互联网领域常用于数据计算中心。
Type 2类型的Hypervisor运行在某个操作系统之上利用操作系统访问物理硬件因此在延时方面具有不可避免的劣势。且底层操作系统的任何Bug都将危及其上的虚拟机因此安全性方面相对较弱。但是移植难度小开发成本低。在互联网领域常用于客户端系统。
Hypervisor可以将一台物理服务器划分成多个虚拟机每个虚拟机可以独立运行不同的操作系统和应用程序。Hypervisor能够提供强大的安全隔离功能确保不同的虚拟机之间互不干扰从而提高整个系统的可靠性和安全性。同时Hypervisor还能够动态调整虚拟机的资源分配以满足系统运行的需求。在智能座舱中使用Hypervisor可以实现多个应用程序之间的隔离从而提高系统的可靠性和安全性。
Hypervisor具有如下功能
1设备模拟。Hypervisor可以创建客户操作系统可以访问的一些虚拟硬件组件是否需要取决于客户操作系统上运行的应用程序
2内存管理。Hypervisor负责为自身和客户操作系统管理和分配硬件内存资源
3设备分配和访问。Hypervisor通常可以将硬件组件分配给客户操作系统并控制客户操作系统实际可以访问哪些硬件组件
4上下文切换。当Hypervisor需要在内核上安排新的客户操作系统时Hypervisor必须通过将在该处理器内核上运行的现有客户操作系统的“上下文”即操作条件保存到内存中来“切换上下文”。然后进行加载新的客户操作系统时可以从内存中访问新的客户操作系统而不会中断执行环境
5捕获指令。客户操作系统可能会根据其访问权限级别执行技术上不应执行的指令。Hypervisor可以分析客户操作系统尝试发送到硬件的指令并模拟硬件对客户操作系统指令的响应
6异常处理。发生异常即异常行为时可以将某些异常路由到Hypervisor进行处理
7虚拟机管理。如前所述Hypervisor最终负责启动和停止客户操作系统在其上运行的虚拟机。
区域硬隔离
与Hypervisor虚拟化相对应的一种多操作系统应用方式是区域硬隔离。
它是通过物理隔离来保障不同系统组件之间的安全。比如说在智能座舱SOC规划与设计的时候根据功能划分的不同在同一颗SOC内部划分出不同的CPU内核以及其他物理硬件资源并分配给不同的功能来使用。比如仪表盘就可以使用独立的CPU核和独立的显示模块并运行独立的RTOS操作系统。
区域硬隔离能够提供更高的安全性和隔离性避免不同的系统组件之间的相互干扰。在智能座舱中区域硬隔离可以被用于对关键系统组件的保护从而提高整个系统的可靠性和安全性。 在智能座舱中使用Hypervisor和使用区域硬隔离都有其优势和不足。实际上二者的选择取决于智能座舱芯片供应商的所选择的技术路线也取决于主机厂对可靠性和芯片性能的判断。 Hypervisor与区域硬隔离的优缺点
以仪表盘的实现为例现代智能座舱的发展要求支持“一芯多屏”的功能。顾名思义就是要求在一颗智能座舱SOC芯片上同时支持实现液晶仪表盘功能和娱乐中控大屏功能甚至还有其他的屏幕。
由于液晶仪表盘属于高安全性和高可靠性领域一般需要使用RTOS操作系统。娱乐中控大屏需要有丰富的生态应用一般需要使用Android系统来支持。
区域硬隔离和Hypervisor都可以用于实现仪表盘功能但它们有各自的优缺点。 综上所述使用区域硬隔离和Hypervisor都可以实现仪表盘功能需要根据具体的场景和需求进行选择。如果对可靠性和安全性要求较高可以选择区域硬隔离如果需要灵活性和可扩展性可以选择Hypervisor。
