。
[技术洞见]主要分享前瞻性且有深度的技术观点及行业见解，旨在为从业者搭建一个专业的、高质量的技术型分享及交流社区。撰稿人皆是长期在行业一线的实践者与思考者。受视角的局限，文章观点难免有疏漏或有待商榷之处，我们真诚地期待您指出及评论。引起思考并深度探讨是我们的初衷，也是我们的目标。
本期文章是由Growth Hacking撰稿，作者阐述了一个完整且可靠的汽车软件平台需要具备哪些“特质”，全文共3200余字，以下是正文：
一个完整且强壮可靠的软件平台，目标的设定基于整车的性能，安全和实时性等多维度的考量，兼顾支持多核异构HPC的硬件限制。（这里必须要强调的是一个度，安全和实时不是绝对的）
为了做到人无我有，人有我优的软件平台，需要有几点宏观的考量：
1，应对多域融合，复杂度，威胁等级不同应用的集成。
2，应对达到最高安全（ASIL-D）和安全级别，以保证各种工况的自动驾驶。
3，提供一个集成的、可扩展的工具环境，支持从系统设计到验证的快速反馈循环。
4，采用持续集成（CI）、持续验证（CV）和持续交付（CD）方法，来应对大规模软件的复杂性。
5，提供从简单微控制器到复杂微处理器的无缝解决方案，平台将基于开放标准构建。它将包括非通用CPU，如图形处理单元（GPU）和深度神经网络（DNN）引擎。标准将包括AUTOSAR和机器人操作系统（ROS）。
6，为从微控制器和高性能计算平台构建的系统提供一个高效、可扩展的运行调度环境。
软件平台的开发需要重视以下技术：
1，高性能是第一指标
2，最先进的用户体验
3，开放式的标准
4，Safety和Security
5，确定性执行和实时性
6，支持跨域异构的架构
1、高性能
支持高性能微处理器和并行叠加。
支持多核计算、多线程。
通过共享内存等方法实现高性能通信。
应对硬件加速集成，如GPU提供的特殊加速器。
2、用户体验
精简的、最低限度的中间件API和工具接口。
有效支持系统建模和架构。
在虚拟和真实驱动器中，从构思到原型再到验证的快速往返时间，包括系统评估。
虚拟化和可扩展性允许集成像DevOps这样的CI/CD工作风格，DevOps部署频率>每天1次。
3、开放的标准
使用面向服务的架构，可进行动态部署。
灵活部署到软件在环/硬件在环仿真环境以及目标硬件。
具有模块化和可扩展架构的多API支持。
多COM堆栈支持和COM堆栈扩展性。
必须与AUTOSAR兼容。
考虑到基于ROS的出现，与ROS兼容，用于快速成型和工具重复使用。
必须和SOMEIP兼容，兼顾DDS。
4、功能安全
可以达到ASIL-D安全等级
实现确定域值内的FFI
支持功能级失效执行和正常降级。
支持在SOTIF环境下通过模拟和回归测试进行早期验证。
Zero Work思想减少功能开发人员的安全相关开发工作。
5、信息安全
安全抽象层，以及BSW层提供的安全feature。
遵守周围系统的安全要求。
保密性。
6、确定性和实时性
支持事件触发和时间触发的调度方法。
数据域和时域的确定性设计，跨SOC和ECU的E2E计算链的实时保证。
软件平台系统模块的概述，包括所有可自主开发的和第三方组件，如下图所示（不同视角的抽象样例，接触不同种架构后会发现其中大量重合）。
(后台回复：AES19，获取高清图片）
提炼出软件平台中的“相同”与“不同”是明确需求阶段的重中之重。
软件平台对应的 ECU通常是多核，上图所示。
HPC是以下组件的组合：
微控制器，ASIL等级高达ASIL-D。（微控制器可以是SOC设备的实时安全核心。）
微处理器，通常是ASIL等级为ASIL-B或ASIL-C的SoC。在这一领域，软件平台解决方案应侧重于增强和改进微处理器，以使其适应新的要求。
通信主干网，高速通信主干是ECU上所有软件平台Host之间的主通信信道。假定的通信主干是：
Ethernet：默认通信主干假定为以太网。补充TSN功能，可提供确定性。
PCIe：与以太网主干网相比，更高的带宽和更低的延迟。PCIe可用于满足这些要求，但是投入产出比还没有实际案例验证其必要性。
微控制器&软件平台
在安全岛上，软件平台被设计为软件功能应用程序（也称为软件组件、应用程序...）和复杂设备驱动程序的组合。遵循AUTOSAR方法。
微控制器软件架构基于AUTOSAR Classic。
微处理器&软件平台
微处理器软件架构将基于符合POSIX的操作系统。该架构将重点改进微处理器系统的功能。
软件平台将支持Linux/QNX等。
软件平台将提供一个运行时环境，将用户从底层软件机制和硬件中抽象出来。在这个抽象的环境中需要考虑的技术点包括多核、内存、时间戳和确定性。
API遵循开放标准，标准包括：
Classic AUTOSAR
Adaptive AUTOSAR
基于AUTOSAR自适应的确定性子集API。
ROS
高级应用程序API，定制的。
在性能核上，软件平台应提供Adaptive AUTOSAR（以下简称AP）兼容层，AP由下图所示的模块组成。
软件平台可以用商业化的堆栈，并需要将扩展规范（关于所需功能），以涵盖整车级别的技术要求，并支持在目标系统上部署。
首先对AP的选择需要提出一些细化的要求，这是比较复杂和核心的内容，对AP，CP，OS等等细化的需求明确后才可以清晰知道需要扩展开发的部分，这个还和遗留的架构和软件强相关。后续空了考虑单独出一期。
泛泛地说将有三类扩展模块：
核心模块：这些模块将是开发的重点。
第三方模块：重点在适配和集成。
项目特定模块：这些模块将根据项目特定需求开发。
为了支持AD，现在很多开发者开始考虑提供ROS的兼容性框架。
早期阶段，建议可分两个阶段提供ROS支持：
第1阶段：ROS 2支持prototype。
第2阶段：ROS 2支持SOP。那么谁是第一个吃螃蟹的呢？
需要考虑到已有的：ROS 2客户端library，ROS 2中间件接口（DDS绑定），与ROS工具套件的互操作性......到量产还有很多需要开发，集成的内容。
单独列出这个话题，是因为在考虑整体软件平台的项目中，对硬件的依赖是无法回避和忽视的。我的观点是：在软件定义汽车的时代，硬件依旧极其重要。
比如智驾域软件平台应加强对GPU和神经元处理单元（NPU）等非通用CPU的支持。例如：
支持在硬件加速器上执行的功能组件的通信和调度。
抽象出来自通用CPU的访问请求，以进行管理。
软件平台的重点之一是提供一个通信中间件，抽象出所有通信相关的内容。这包括平台软件、功能应用程序、非软件平台的ECU组件与传感器或执行器等车辆组件之间的通信。（整车是做一个完整的系统，弱化域的概念。这个和后续的调度部分也强相关）
通信中间件技术将基于：
基于信号的通信
面向服务的体系结构（SOA），支持服务发现和发布/订阅范例。
SOMEIP, DDS...
软件平台需要提供以下通信绑定/传输层（可选但是不限于）：
共享内存
以太网
PCIe
整车级通信
有一些都需要遵循的特性：
统一的且通用API抽象，接口是整个平台的一个重点。
高性能的通信。
安全可靠的通信。
1 共享内存
平台需要提供一个高性能的共享内存管理系统。
2 以太网
平台将车内和车外通信的以太网网络技术兼容。同时探索与TSN设备的兼容性，以储备能力提供基于以太网的确定性通信。
3 PCIe
平台需要考虑提供基于PCIe的通信主干网，支持高带宽和低延迟要求。这项工作的范围仅限于通过基于PCIe的骨干网实现通信，并提供连接共享内存管理层和PCIe驱动程序所需的软件堆栈。储备技术，未见商业价值。
4 整车级通信
平台提供通过网关组件在经典总线（如CAN、CAN-FD和以太网）上进行通信的可能性。这将启用平台ECU（HPC）与其他车辆部件（如非平台ECU、执行器和传感器）之间的通信。
平台将支持基于信号的安全相关通信。这种通信可以在平台托管的应用程序之间进行，也可以在平台应用程序和外部组件（如非平台ECU、执行器、传感器等）之间进行。
平台的默认通信选项将包括具有动态发布/订阅机制的面向服务的通信。面向服务的通信能力将符合技术清单。对底层通信技术的访问将由所提供的应用程序API完全抽象。
面向服务的通信需要Scalable Service-Oriented Middleware Over IP (SOME/IP)和Data Distribution Service (DDS)。解决方案同时支持部分SOMEIP和DDS。
DDS的大规模使用有待验证。
首先明确一个目的，调度的核心是简化开发流程，提高平台开发可靠性。
平台将提供功能应用（内容）和网络（路径）调度机制。这些将用于满足需求要求，并简化功能应用程序的集成和验证过程。
平台调度基础将遵循以下方法：
全局调度：一种全局调度方法，允许描述完整的系统行为
事件驱动的调度：任务/计算链的执行可以基于外部触发器触发，例如具有显著抖动的传感器输入。
数据驱动的调度
时间驱动的调度：通过经验是需求创建/调整时间表。
硬件引擎调度：管理对硬件（如加速器）的访问。
平台提供一个调度套件，支持用户创建、配置和验证自定义调度程序。
调度套件将遵循以下原则：
用户友好性。
对最终用户隐藏的复杂性。
紧密的CI/CD集成，工具性能。
离线和在线可视化。
总结一下，软件平台话题的几个要素：
大致架构设计以及各个模块的Spec，需求明确，
各种技术的融合，
Make or Buy,
集成工作
作者：
Growth Hacking SUN
汽车电子与软件特约撰稿人，汽车软件从业者。
最后，汽车电子与软件是一个中立性的开放社区，真诚欢迎行业各路英雄，煮酒论剑。投稿请联系微信：18918250345
