AUTOSAR 在许多主机厂 的汽车 ECU 开发中已变得无处不在，但随着新的、更复杂的自动驾驶汽车技术进入市场，AUTOSAR 将扮演什么角色？
自动驾驶汽车 - 第 3 级
随着自动驾驶系统的功能越来越强大，我们已经进入了汽车不再需要驾驶员支持的时代，但在可预见的未来，自动驾驶系统仍需要驾驶员作为后备（如 SAE 3 级，图 1）。第 3 级系统，即有条件自动驾驶系统，只能在特定条件下和特定地点工作，因此在大部分时间内，车辆需要由驾驶员控制，只有当所有条件都满足时，车辆才能控制驾驶任务。因此，在整个旅程中，车辆和驾驶员之间需要进行控制权的转移，反之亦然。
图 1.SAE 自动化水平
SAE 3 级将是汽车制造商迈出的一大步（需要证明的稳健性水平与民用航空标准类似）。人类具有很强的适应能力，通常可以在控制和指令不佳的情况下工作。但是，当三级车辆完全处于控制状态时，需要适应车辆局限性的就不再是驾驶员了。车辆需要适应驾驶员（任何驾驶员）的局限性。如果车辆决定需要将控制权移交给驾驶员，它必须能够快速、稳健、清晰地传达这一信息。
那么，3 级车辆如何在车辆和驾驶员之间安全地转移驾驶任务的控制权呢？
控制权的转移涉及多个方面（图 2）：驾驶员对车辆：
车辆必须让驾驶员意识到所要求的条件已经满足，并且在必要时车辆可以自动驾驶
驾驶员必须告知车辆他们希望由车辆控制
车辆必须掌握控制权，并可靠地告知驾驶员它已掌握控制权
一旦掌握了控制权，车辆必须持续监控驾驶员，以确保驾驶员能够在必要时重新掌握控制权。
从车辆到驾驶员：
在下列情况下，车辆必须启动控制权转移程序
车辆无法保持控制（紧急转移）
驾驶员对驾驶员监控系统没有反应
系统所需的条件不再满足
如果需要，驾驶员必须控制车辆
在 30-60 秒的受控程序中进行标准的控制权转移，具体取决于执行情况
紧急控制权转移--由于紧急情况，驾驶员需要接管控制权，对于大多数系统来说，这至少需要 5-10 秒钟。
如果驾驶员没有控制或响应驾驶员监控系统，车辆将退回到安全状态，在大多数情况下，这将导致车辆停在车道上并启动紧急呼叫。
图 2 控制权的转移。资料来源：sbdautomotive.com（驾驶员和驾驶室监控--第 810 号报告）
这种控制权的转移需要通过人机接口 (人机界面) 在车辆和驾驶员之间进行管理。车载人机界面 系统包括触摸屏、显示器、开关、按钮、音频、语音和触觉。系统设计必须经过仔细考虑，以确保满足所需的功能安全要求，特别是在集成传统上不支持汽车安全完整性级别（ASIL）要求的音频和信息娱乐系统时。在大多数情况下，将结合使用各种可用显示屏的视觉人机界面 、以铃声或可能的语音命令形式提供的音频反馈、通过座椅或方向盘致动器提供的触觉反馈以及用于驾驶员输入的方向盘按钮和开关（图 3）。使用多个人机界面 系统可确保冗余，并可将功能安全要求从较高的 ASIL-D 级分解为较低的 ASIL-B/A，从而减少设计变更对单个系统的影响，并在驾驶员对显示屏分心或听力受损甚至失聪（即听不到音频反馈）的情况下，提高驾驶员参与的可能性。
图 3.控制权转移人机界面 。资料来源：sbdautomotive.com（驾驶员和驾驶室监控--第 810 号报告）
正如预期的那样，3 级系统的整体系统设计将包含运动控制、车身和 AV/ADAS 领域的大量传感器和智能传感器、ECU 和执行器，而且由于控制要求的转移，现在还将对音频和信息娱乐领域产生影响。这就导致了跨多个领域和 ECU 的高度复杂的整体系统设计，不同的一级供应商将提供符合 ASIL-D 功能安全要求的三级自动驾驶系统。使用 AUTOSAR 可以提供通用的软件架构框架，从而帮助减轻一些开发难题。
另一个重要趋势是，随着电子硬件和软件能力的提高，多个领域的技术正在整合为数量更少、更复杂的多功能 ECU。电子设备架构正从面向功能的 ECU 转向更复杂的功能域控制器，未来还将转向集中式和分区式架构（图 4）。这将最终实现完全可扩展的面向服务的架构，实现许多人所说的 软件定义的汽车换言之，汽车的大部分功能都建立在与硬件无关的软件平台上。为了实现这一目标，大多数制造商都在扩大内部软件开发团队的规模，以管理汽车的软件产品路线图，而不是外包合作伙伴或一级供应商。
在大多数情况下，一级供应商仍将提供硬件和软件组件，但系统的所有权将属于主机厂 。他们必须将这些复杂的系统与来自多个供应商的组件集成在一起。使用 AUTOSAR 框架可以让主机厂 定义可移植的软件组件以及它们之间的通信接口。这有助于完成困难的系统集成和调试任务，并意味着随着 EE 架构的发展，许多软件组件可以重复使用。
图 4.车载电气架构的预计演变。资料来源：sbdautomotive.com（EE 架构平台 - 报告 630）
AUTomotive 开放系统架构（AUTOSAR）是一个由汽车主机厂 、一级供应商和技术开发商组成的开发合作组织，成立于 2003 年，旨在为汽车 ECU 创建一个开放的标准化软件架构。该架构定义了标准软件模块和服务接口，通过封装软件组件实现硬件独立性（图 5）。该平台于 2006 年 5 月首次发布，AUTOSAR 技术的首次实施于 2008 年投放市场。
图 5 AUTOSAR 经典平台。来源：https://www.autosar.org/standards/classic-platform/
最初的平台针对的是提供单一功能的基于微控制器的 ECU，自推出以来已获得了显著的市场渗透率，现在大多数汽车主机厂 都与 AUTOSAR 组织合作。随着汽车系统复杂性的增加，基于微控制器的简单单一功能 ECU 已转向基于微处理器的更复杂的多功能 ECU。为此，AUTOSAR 开发了自适应平台（图 6），提供基于 POSIX 的操作系统，专为在多核 SoC 上运行而设计。最初的平台更名为 Classic，并将共享的低级要求和规范纳入基础标准。
图 6.AUTOSAR 自适应平台
自适应平台于2017年3月首次发布，现在两个平台共存并互为补充。自适应平台并不被视为经典平台的替代品；它们具有不同的属性，适合不同的实现方式。完整的框架还包括可进行系统验证的验收测试，以及定义域之间的标准应用接口，支持更大的软件重用性和可交换性（图 7）。同一系统中的 ECU 可运行任一平台，并仍可利用 AUTOSAR 通信功能提供的 ECU 互操作性。
图 7.AUTOSAR 标准。来源：https://www.autosar.org/
AUTOSAR 和自动驾驶汽车AUTOSAR 经典平台已被用于当今市场上的许多 1 级和 2 级ADAS 系统，通常用于单一功能的 ECU，如 ACC、AEB 和 LKA。AUTOSAR Adaptive 现在开始用于更先进的ADAS 功能，其软件处理在高性能计算平台上实现。许多主机厂 强制要求在其 ECU 上使用 AUTOSAR，特别是管理 CAN/Flexray/LIN/Ethernet 上的车辆通信网络。这通常是由于主机厂需要拥有和管理自己的网络。ECU 配置和报文目录可通过受控方式发布给众多一级供应商，而 AUTOSAR ECU 配置文件 (ARXML) 的使用已非常普遍。随着我们的车辆系统（包括自主车辆系统）越来越复杂，AUTOSAR 显然将在许多方面发挥作用主机厂 。实现三级自主功能的系统将涉及多个领域的多个 ECU，而 ECU 的互操作性、端到端 (E2E) 功能安全消息传递协议、软件可移植性和功能安全特性使得在 AUTOSAR 框架内进行开发成为不二之选。这也将缓解传统的非功能安全人机界面 系统的过渡问题，通过扩展其已支持的 AUTOSAR 功能，实现控制方面的转移，以满足其功能安全要求。尽管如此，AUTOSAR 将仅提供系统内的部分软件层。
虽然自适应平台在一定程度上垄断了车联网，但它可能并不是实现复杂自主功能的主要选择，还有许多其他的软件系统，包括专有和开源系统，如 OpenCL、机器人操作系统 (ROS) 和 Mobileye 等。ADAS 幸运的是，对于开发人员和 AUTOSAR 来说，可以利用 AUTOSAR 协议栈构建通信和安全关键后备系统，同时使用 SOME/IP 和 DDS 等中间件连接其他更高级别的系统，从而实现两全其美。
然而，AUTOSAR 是一个不断发展的生态系统的一部分，其中涉及许多其他软件系统，随着自动化 在更集中和基于区域的架构上得到更大程度的发展，AUTOSAR 的确切作用还有待确定。
关于作者Martin Howle 是SBD Automotive 的 EE 架构领域负责人。