SW Architecture

软件架构（SA，software architecture）是上世纪90年代提出的，它对复杂的软件系统进行结构化，并给出其高级的系统描述。

AUTOSAR

以宝马汽车为首的几家OEM与一些Tier-1成立AUTOSAR（AUTomotive Open System ARchitecture）联盟，是想为汽车工业开发一套支持分布式的、功能驱动的汽车电子软件开发的架构标准化方案。

基础软件层则被抽象为四级（如图）：

1. 服务层（Services Layer）

2. ECU抽象层（ECU Abstraction Layer）

3. 微控制器抽象层（Microcontroller Abstraction Layer）

4. 复杂设备驱动（Complex Device Drivers）

AUTOSAR提供了一个三层的软件结构：

1. 基础软件层 (BSW)：标准化的软件模块，没有任何功能任务，只提供运行上层功能部分的必要服务；

2. 运行环境(RTE)：中间件，从网络拓扑提取出来的，支持在应用软件部件之间或者应用软件部件与基础软件层之间ECU内部/之间的信息交换。

3. 应用层：应用软件部件，和RTE进行交互。

Adaptive AUTOSAR

Adaptive AUTOSAR是一种ARA（AUTOSAR Runtime for Adaptive Applications)的标准化接口，如图所示。它包括两个部分：操作系统功能的接口和通信中间件，后者处理Adaptive AUTOSAR服务和各种本地/远程应用之间的数据交换。这些接口允许OEM实现自动驾驶，在线OTA （over-the-air）软件升级，物联网（IOT， Internet of Things），流媒体等服务。

与经典AUTOSAR相比，这种自适应平台可以在ECU运行时实现服务-客户的动态链接，为此需要提供交通基础设施，云服务器，微处理器（如ARM）和HPC（GPU）硬件等。

执行管理（Execution Management）功能群负责ECU的启动和停止，并保持应用程序状态。和平台健康管理（Platform Health Management）一起，为那些启动降解（degradation）或者类似策略的应用程序维护必要的资源，这样ECU可根据定义好的策略在危机时刻作出反应。

通信中间件实现在本地应用程序之间以及本地应用程序和其他ECU中应用程序之间的服务定向通信，这个包括了AUTOSAR Adaptive 的服务接口。

ASAM (Association for Standardization of Automation and Measuring Systems)

ASAM是一个非营利组织，促进汽车开发和测试过程工具链的标准化， 协会成员主要是国际汽车工业领域的公司。ASAM标准定义用于车辆ECU软件开发和测试协议、文件格式和应用程序接口（API）、模拟和测量领域的工具，基本上应用开发和测试自动化系统都符合ASAM标准。ASAM标准基于UML、XML和CORBA等，独立于IT技术平台。ASAM与其他组织，例如ISO或AUTOSAR，在标准化方面紧密合作。ASAM主要涵盖几个层面：测量和校准、诊断程序、ECU网络、软件开发、测试自动化、数据管理和分析、还有模拟等。

ASAM ODS（Open Data Services）主要用于在测试系统之上建立测试数据管理系统，从测试生成测量或计算的数据。ASAM MDF（Measurement Data Format）是定义的测量数据格式。ASAM OpenDRIVE是静态仿真场景格式，而OpenSCENARIO是仿真动态驾驶场景的描述语言与变量信息。

V-Model for Autonomous Driving software

如图是软件开发V-模型的流程图：汽车界已经采用这种软件开发模型很久了，也是工业标准MISRA（The Motor Industry Software Reliability Association）C编程规范的参考模型（有20年的历史），同时也是构建ISO 26262标准的参考模型。

V-模型代表了一种软件构建加上可追溯性的验证（traceability & verification/validation）的条理化进程；V-模型的左侧是从需求-设计-实现的途径，而其中的每一步，可以分成多个子系统，彼此并行地看待（系统需求只有一组，但每个子系统可以有不同的设计）；V-模型的右侧是从小组件到系统级别的评估，迭代地可追溯性验证（trace & verify/validate）越来越大的系统部分。

根据V-模型看，自动驾驶的测试存在一些挑战性情况：

1. 驾驶员不在环情况；

2. 过于复杂的需求；

3. 采用了非确定性算法；

4. 采用了归纳学习算法；

5. 需要故障-安全/-可操作的实现。

解决这些问题，大家提出的一些可用方法包括：

1. 通过依次松弛的操作场景的分阶段部署法；

2. 采用一种“监控-驱动”结构，将最复杂的自主功能和较为简单的安全功能分开；

3. 故障注入以得到更有效的边界情况（edge case）测试 。

aSPICE

在汽车行业有两个公认的软件设计流程标准，一个是aSPICE（Automotive Software Performance Improvement and Capability dEtermination），另一个是ISO 26262的软件部分。

下图是aSPICE的流程图。aSPICE源自一般SPICE（ISO/IEC 15504）标准，它仍然建立在V-模型之上，这意味着从需求到源代码的每个过程都有相应的测试。按照“V-模型”，其左侧的开发过程如下：

1) 客户的要求；

2) 将其映射到系统要求；

3) 将需求分解为逻辑服务，这包括设计决策；

4) 对于每个软件服务，从系统要求中获取软件要求；

5) 将软件需求细分为单元，管理可用资源（内存，CPU时间等）；

6) 设计并实施每个软件单元。

它右侧的相应测试过程如下：

1) 设计的单元测试；代码是否符合设计？是否满足了非功能性要求（如不崩溃）？

2) 软件架构的集成测试；作为服务的单位组成是否仍然有效？

3) 软件认证测试软件要求；服务是否符合其要求？

4) 系统集成测试系统架构；将所有服务组合到整个系统中，它是否有效？

5) 系统认证测试系统要求；整个系统/汽车是否符合要求？

6) 验收测试由客户完成。

除了这些流程外，aSPICE还要支持和管理整个流程，包括存档和制定计划等内容。使用ASPICE可实现敏捷开发，灵活的方法会从少的要求开始，但仍执行整个V-模型过程。

ASPICE评估导致从“未实现”（N）到“完全实现”（F）0-5级的评级：

a) 0级：流程最多可以“部分”（P）实现ASPICE定义的工作产品（源代码，需求，体系结构描述，测试报告等）。

b) 1级：“很大程度上”（L）能够生产指定的工作产品。

c) 2级：完全有能力生产工作产品，并且可以通过实现目标，检查进度以及在错过目标时作出反应。

d) 3级：拥有中央标准，而这些都要在工作和项目中遵循。

e) 4-5级：实际上不重要，目标是建立组织流程，更“可预测”和“创新”。

ISO 26262 SOFTWARE DEVELOPMENT PROCESS IN VEHICLE

ISO 26262（Part 6）依照V-模型也给出了一个修正的软件开发流程图如下：

这个文档规定了汽车应用软件级产品开发的要求，包括：

- 软件级产品开发的一般主题;

- 软件安全要求的规范;

- 软件架构设计;

- 软件单元设计和实现;

- 软件单元验证;

- 软件集成和验证;和

- 测试嵌入式软件。

它还规定了与使用可配置软件相关的要求。

重点的是有关软件架构设计的一些表格，比如如下的表1和表2：

表 1 ISO 26262 软件架构设计准则

表2 ISO 26262 软件架构级别的误差检测机制

42010-2011 - ISO/IEC/IEEE Systems and software engineering -- Architecture description

ISO 26262 SW Configuration and Packaging Process

EB SW Architecture for Autonomous Driving

ADTF (Automotive Data and Time-Triggered Framework)

Electronics Architecture and Software Technology - Architecture Description Language (EAST-ADL)

Nvidia Driveworks

车载操作系统

车载操作系统必然是实时操作系统（real time operating system，RTOS），特别是对自动驾驶的支持（其他方面还有车载娱乐，车联网和中控显示屏）。

RTOS是旨在为实时处理数据的应用程序提供服务而且通常没有缓冲区延迟的操作系统。处理时间要求（包括任何OS延迟）0.1秒或更短的时间。

实时系统要求处理必须在规定的时间内完成，否则系统将失败。它们要么是事件驱动的，要么是分时的。事件驱动系统根据优先级在任务之间切换，而时间共享系统根据时钟中断切换任务。大多数RTOS使用先发制人的调度算法。

RTOS具有用于调度（scheduling）的高级算法，调度器的灵活性可实现更广泛的流程优先级编排（orchestration）。实时操作系统的关键因素是最小的中断延迟和最小的线程切换延迟;实时操作系统的重要性在于响应速度，而不是执行的工作量。

ROS

Robot Operating System (ROS) 是在机器人领域一个成熟和灵活的控制编程框架。整个ROS系统可以是分布式计算结构，即各个计算机执行控制过程中的各个部分，但作为一个实体（entity)即机器人在行动。

ROS系统是适合自动驾驶汽车的，原因是已经有大量的相关开源代码，可视化工具齐全，所以容易在ROS环境中开启一个自动驾驶项目。ROS存在的缺点是：

1. 单点失败. 所有ROS应用，完全依赖于一个软件组件roscore，处理ROS不同部分之间的所有协调。

2.不安全性. 目前ROS不支持阻止第三方进入ROS网络的安全机制，也不读取节点之间的通信。

如图给出ROS的工作方式，整个系统由一些节点组成，而一个节点通过发布/订阅（publicate/subscribe）的方式与其他节点进行通信。比如，图中一个传感器作为ROS的一个节点，它可以以信息流的方式发布其获得的信息，发布的信息可以被其他节点如感知，规划或者控制单元获得。

BlackBerry QNX Neutrino Realtime OS

QNX Neutrino是商业实时操作系统，开发该系统的公司已被手机公司黑莓并购。QNX采用微核设计和模块化架构，如图是QNX的结构图。

QNX Neutrino实时操作系统实现了应用级的高效性能和确定性响应时间。采用线程优先级继承消除了优先级反转（priority inversion）问题。

此外，QNX Neutrino支持在虚拟环境下的多核方案，比如Symmetric multiprocessing (SMP)，Asymmetric multiprocessing (AMP)，Bound multiprocessing (BMP)，具有固有的可扩展性。

PolySync

PolySync Core是一个自主操作系统，由中间件（middleware）和一组很常见的自动驾驶应用软件API服务（传感器融合、车辆控制和路径规划等）组成。通过将应用层与操作系统和硬件分离，PolySync Core具有一致性和可移植性，可构建自动驾驶应用程序。如图是PolySync结构图，可以看到支持的传感器有激光雷达、雷达、摄像头和超声波雷达。

在PolySync，有一个底层控制子平台，叫开源车辆控制（Open Source Car Control，OSCC），是软硬件设计的集合体。它可以对汽车进行计算机控制，以推动自动驾驶汽车技术的发展。

OSCC能够向车辆发送控制命令，从车辆的CAN总线读取控制消息，并转发当前车辆控制状态的报告，如转向角和车速。通过各种传感器，如方向盘的扭矩传感器（torque sensor）、节气门（throttle）的位置传感器和刹车（brake）的位置传感器，OSCC给车辆各部件的ECU能够发出控制命令。

“Treat autonomous navigation as a software problem”

Stanley from Stanford U. 2005

Junior from Stanford U. 2007