先提出几点容易混淆的概念：

1、什么是软件平台

架构，平台的概念是复杂且不一致的。为了尽量简化，以达到在概念上保持一致的目的，把应用层抛开后，以下的统称为软件平台，不涉及应用相关的需求，只会将应用根据软件平台对应用提供的支持进行大致的分类。

2、模块化结构性开发和软件水平分层的关系

软件的水平分层2/3/5/7...怎么分都好，是一个结果和目标，真实开发过程中，无论是出于对软件团队的能力要求，还是开发的可操作性，建议都以模块化为切入点。

3、功能性需求和非功能型需求的关系

应用的迭代是非常敏捷的，和应用强相关的需求都不在平台考虑范围。换句话说，平台需要提炼出非功能强相关的需求。以及需要注意到一些潜在的新技术。

本质上非功能需求也是通过功能提炼出来的。

4、软件平台工作量

软件平台的概念很大，且是定制化比较高的。不太存在一步到位给出具体软件工程需求的可能性，需要专家团队细化协作。且任何解法也不是唯一的，只是基于自身遗留客观情况的取舍。

软件平台

完整的软件平台应该考虑两部分组成，即用于车内的CarOS和用于云端的架构。实际开发中需要继续收敛话题，我们先聚焦车内的软件平台，并分为两个软件模块：安全模块和性能模块。（非精准的类比为CP和AP）

软件平台的安全模块和性能模块

Car.OS设计初衷是用于承载车辆内所有类型的应用程序。根据要求和限制，我们将车内应用分为不同类别，以引导出不同需求的可以承载不同应用的软件平台模块：

1、安全模块可以支持从QM到ASIL-D的所有控制回路，包括：

• 无安全保证的应用。堆栈部署在一个或多个µC上，没有任何安全保证。

• 在安全认证环境中运行的安全相关应用程序。堆栈部署在满足所需安全属性和功能的一个或多个µC。

2、性能模块在基于Linux的操作系统上运行，包括：

• 没有UI的应用程序：应用程序可能使用特殊用途的硬件，如GPU。性能模块承载所有QM软件，并可以使用分解降级来承载ASIL-B。同时在安全模块上有一个安全检查器。

• 需要UI（如信息娱乐或导航）的应用程序运行在相同的基于Linux的操作系统之上，软件平台需要可以承载虚拟化的Android操作系统和信息娱乐堆栈。

软件平台/安全模块

CarOS中的安全模块是可以通过一个具有多核支持的Classic AUTOSAR和一个ASIL-D微内核的组合实现。Classic AUTOSAR应符支持所有软件组件（SWC）可以依赖RTE作为与其他SWC和车辆网络的通用通信中间件。只有该平台上的应用程序才能直接访问本地现场总线。根据API框架描述（ARXML...）配置网络，并生成RTE中的stubs/ skeletons/ slots。

安群模块需要能够支持：

•    遵循Classic AUTOSAR的各种QM任务控制和任务处理。

•    ASIL-D堆栈可监控ASIL-A/B任务。安全模块为应用程序开发人员提供了关于如何使用这些监控的明确指导，例如看门狗等的具体说明。

•    ASIL-D微核上的ASIL-D任务。ASIL-D堆栈通过E2E保护防止消息损坏和重播错误，但使用CAN进行通信。

安全模块不存在任何与后端的直接连接。

需要注意的是，由于技术和成本原因，Classic AUTOSAR堆栈没有按照ASIL-D进行开发。要运行ASIL-D SWCs，在Classic AUTOSAR堆栈旁边放置另一个ASIL-D安全内核，以实现时间、内存和CPU的FFI。

ASIL-D核提供：

•   ASIL-D微内核、服务中断（ISR）handling, resources, events

•   端到端保护，确保没有消息被破坏或重复（消息计数器、循环冗余校验CRC）；安全研究趋势是Keyed-Hash消息认证码HMA-C）

•   定时保护，确保关键功能及时执行且不会中断

•   看门狗功能，用于失效安全/失效复位或监控系统其他部分中运行的软件

•   内置自检（BIST）

安全模块需要考虑未来的各种需求，如多核µC的使用效率或复杂任务链的调度。

软件平台/性能模块

HPC由带加速器的微处理器、附加的小型微控制器单元以及大量的互联和外围设备组成。这些HPC上运行的性能模块支持一系列用例，从传感器融合和AI算法到用户界面再和云通信或车内通信。

大多数性能模块部署目标是Linux。

未来的AD安全概念需要判断是否必须将需求分解为ASIL-D=ASIL-B（D）+ASIL-B（D）。解法之一是提供一个支持ASIL-B性能模块（例如基于QNX），该模块具有本地ASIL-B支持，以承载具有已部署分解功能的AD功能。例如，两个ASIL-B检查程序可以监控QM中的第三个ML组件。

ISO 26262允许的另一种分解是ASIL-D=ASIL-D（D）+QM（D）。这将允许软件平台在Linux（QM）中实现性能模块，但这将需要在安全模块上实现ASIL-D作为检查器组件，以达到相同的ASIL总体水平。（依旧回想一下，架构设计和技术路线的选择强相关，在总体设计之前先罗列技术点，对设计是很有帮助的）这将减少由于支持QNX和Linux双系统而导致的工作，并且不用使用OS抽象层。

虽然特斯拉使用linux可能不应该拿来作为实现安全方案的主要例证，但他们在ADAS中使用Linux降低了工作量应该是其中之一个主要原因。

软件平台/性能模块/应用模式

基于内存分配，性能模块上的应用程序通常以以下方式之一构建。

• 全静态RAM：应用开发人员设定不能为了防止内存碎片或内存不足而产生新的操作。这是嵌入式应用程序的可靠默认设置，即使它们与安全无关。如果应用程序与安全相关，则必须这样做。它通常通过完整的代码生成、基于模型的开发（Matlab）和复杂的测量与控制任务来实现。平台在开发和运行时实施这种应用程序模式。

• 运行时静态RAM，仅在启动时分配内存：此应用程序开发模式允许应用程序开发人员在启动时从只读内存（ROM）、持久性或文件系统读取二进制或文本配置，按照定义获取内存，然后在操作期间完全静态操作。该模式也用于复杂的人机界面（HMI），但在安全C-D环境中禁止使用，因此，安全模块不支持该模式。

• 动态内存：仅允许在性能模块、特定护栏内以及性能模块支持的定义限制内使用动态内存。应用程序需要实施开发应用程序控制接口。

性能模块可以定义线程池的使用方式，各种情况包括进程如何与非阻塞的回调函数进行同步和异步通信，进程间彼此之间如何通信，以及在整车层面的通信。性能模块还可以为应用程序提供跟踪和调试功能。不仅限于纯1对1连接，性能模块还可以使用高效的发布-订阅机制。

此外，计算平台将提供persistency，以避免闪存在整个生命周期内损坏。使用请求时刷新或关机时刷新等策略，并对babblingidiot进行保障和约束。对persistency设计了各种约束限制，如考虑每个key的最大数据大小以及与出厂重置相关的软件更新数据迁移。将加密功能与persistency相结合，可以实现安全的数据存储。循环冗余校验（CRC）和默认回退值用于在性能模块支持健壮的应用程序开发。

软件平台/性能模块/从应用到服务

分类的模型的多种多样的，和开发的工作流工具链，和组织架构都有关系，这部分应该统一语言然后定制

再跳跃到软件平台之上的应用框架说一些前沿的。

基于一些设想和对软件平台的设计目标：开发人员可以高效地构建、部署和测试小型、可重用和高质量的应用程序，这些应用程序可以以不同的方式组合，以提供最终用户可见的功能。（也可以理解为服务）

ROS似乎符合提到的许多要求。在不同领域中各种机器人用例重已经被反复验证，并打下坚实基础。它提供了开发人员需要的工具链和适当的抽象用来简化开发。

ROS并不是OS或者软件平台，再次强调不是一个操作系统或者软件平台。它是一个应用程序编排框架，主要专注于算法开发和快速原型制作。正在扩展的方向（1）到小型嵌入式平台，包括裸机，（2）到硬实时系统，（3）重点关注生产环境。

ROS 2的操作系统旨在符合汽车标准，如ISO 26262，并可达到ASIL-D级别的安全支持。这使得在未来在未来在未来，ROS 2可能成为性能模块应用程序和扩展服务编程模型的首选。在未来在未来在未来，甚至可能延伸到安全模块。

ROS 2可以用DDS标准进行进程间通信。它旨在使用发布-订阅模式以及同步和异步RPC风格通信的扩展，实现可靠、高性能、互操作、实时、可扩展的数据交换。这点和软件平台的编排调度和实时性是息息相关的。ROS应该是一个独立的子话题。

软件平台/性能模块/基础服务

拉回来，到软件平台的基础服务。软件平台本质是提供尽可能丰富，完整的基础服务。

基于库的概念，不同应用程序所需的任何服务都可能是由平台的基础服务提供。理想情况下，不同车型的基础服务是从相同的源代码创建的。说的是理想情况，非常难实现，并且需求可能本身就是不同的。

例如以下这些比较有代表性的基础服务:

• 通信

• 安全相关的服务

• Persistency

• Logging

• 能量管理

• 时间服务

• 诊断

• ......

AP已经提供了一大部分需要的基础服务，但按照整车的视角和覆盖未来的需求并不完整，需要做出相应的扩展额定制性的开发。这部分的工作细化明确后会是软件平台（除集成外）的主要工作。系统需求，各类服务的需求，Software requirement specification，Software architecture specification...再逐一得到明确。

软件平台/性能模块/Android Linux(单独再聊吧)

作者：

Growth Hacking SUN

汽车电子与软件特约撰稿人，汽车软件从业者。

[技术洞见]主要分享前瞻性且有深度的技术观点及行业见解，旨在为从业者搭建一个专业的、高质量的技术型分享及交流社区。撰稿人皆是长期在行业一线的实践者与思考者。受视角的局限，文章观点难免有疏漏或有待商榷之处，我们真诚地期待您指出及评论。引起思考并深度探讨是我们的初衷，也是我们的目标。

最后，汽车电子与软件是一个中立性的开放社区，真诚欢迎行业各路英雄，煮酒论剑。投稿请联系微信：18918250345