以下文章来源于计算机视觉深度学习和自动驾驶，作者黄浴
每个人都有一种动驾驶已经进入了下半场。demo或者POC人们不再关心早期工作。这里所谓的上半年大多是解决典型场景（即高速公路、街道、停车场等）的感知、定位、预测、规划决策和控制解决算法和执行方案（线路控制底盘技术）等常见问题。
此外，在上半场期间，计算平台（AI芯片及其SOC）英伟达等传感器技术的研发过程也取得了初步成果Xavier和Orin、HDR固态激光雷达和4D毫米波雷达等。
下半年意味着解决罕见的长尾场景，构建数据闭环的持续高效研发框架，已成为行业的共识。在此过程中，如何实现自动驾驶技术工程实施是关键（见附录示例），包括开发标准化和平台、大规模生产和实施商业化（成本、汽车规则和OTA）的工作。
底盘系统约占整车成本的10%，线控底盘是自动驾驶的关键部件，因为如果不支持，自动驾驶最终输出的控制信号可能无法正确执行。
线控（Drive-by-wire 或 X-by-wire），即以电线(电信号)的形式取代机械、液压或气动的连接，无需依靠驾驶员的力或扭矩输入。
线路控制底盘主要包括制动系统、转向系统、驱动系统和悬架系统。它具有响应速度快、控制精度高、能量回收强的特点，是实现自动驾驶不可或缺的部件。
线路控制底盘技术的安全是自动驾驶最基本、最核心的因素。虽然纯机械控制效率低，但可靠性高；虽然线路控制技术适用于自动驾驶，但也面临着电子软件故障带来的隐患。只有实现双重甚至多重冗余，才能确保在故障情况下仍能实现其基本功能。
全球L林肯是自动驾驶创业公司最主流的测试开发车MKZ，由于其高性能、高精度的线控性能，易于使用逆向工程进行改装，以及成熟的线控改造服务提供商AS和Dataspeed，为自动驾驶初创企业的研发提供了稳定易用的平台。
电动汽车底盘包括三电系统（电池、电机、电气控制）、能量回收和热管理系统、线路控制转向和制动系统和悬架系统。滑板底盘是根据车型要求对安装在底盘上的转向、制动、三电、悬架进行模块化布置，从而缩短开发周期。因被称为滑板底盘，因为它的底盘。滑板底盘灵活性高，能满足自动驾驶系统的需要。
滑板底盘的核心优点是软件定义和软硬件解耦。它可以简化机械结构，减少零件和硬件的边界和限制，通过分布式轮毂电机驱动算法升级更安全的底盘功能。底盘可以完全由软件定义，体现在分布式驱动算法上。因为分布式驱动算法可以完全解放底盘，从传统的汽车底盘到真正的轮式机器人。为了充分释放滑板底盘的模块化、灵活性等优点，需要一套算法驱动的设计和柔性制造系统，实现多类小批量分布式制造。
Arrival、Rivian、Canoo和REE欧美创业公司和中国创业公司Upower和PIX Moving，都宣布使用滑板领域。丰田、现代、雪铁龙等车企，以及舍弗勒、采埃孚等。Tier -都开始开发滑板底盘。
随着汽车行业的网络化、智能化、共享化、电气化（CASE）”趋势推动下的智能化发展，促使汽车分布式架构向着集中式架构转变。E2A是各种传感器、处理器、电子电气分配系统和软硬件的总体布局方案(包括数据中心平台和高性能计算平台)的集成。
通过E2A，电力总成、驱动信息和娱乐信息可以转化为物理布局、信号网络、数据网络、诊断、容错、功耗管理等电子电气解决方案。
汽车E2A分为三个时代：分布式多MCU组网架构、功能集群域控制器（Domain Controller）与区域连接域控制器（Zone Controller）中央平台计算机（CPC）。
自动驾驶汽车需要使用大量传感器，车内线束也在迅速增长。车内需要传输的数据量激增，线束不仅承载更多的信号，而且需要更快的数据传输速度。新一代自动驾驶E2A在平台下，通过标准化API接口实现了软硬件的真正解耦，可以获得更强的计算能力支持。同时，数据通信的带宽也得到了加强，资源分配和任务调度更加灵活方便OTA（over-the-air）。
智能车E2A，Aptiv提出大脑与神经相结合的方案包括三个部分：中央计算集群、标准电源、数据主网络和电源数据中心。该智能汽车架构注重三个特点：灵活性、生命周期内的持续更新、系统架构的相对容错性和鲁棒性。
特斯拉Model 3的E2A分为域控架构和电源分配架构。驾驶辅助和娱乐系统AICM控制合并到CCM在中央计算模块中，电源分配架构考虑了自动驾驶系统所需的电源冗余要求。
中间软件是基础软件的主要类别。在操作系统、网络和数据库上，应用软件的下层是为应用软件提供操作和开发的环境，方便复杂的应用软件的灵活高效开发和集成。共享资源，管理不同技术之间的计算资源和网络通信。
此外，中间件的定位不是操作系统，而是软件框架，虽然包括RTOS、抽象层的微控制（MCAL）、协议和服务，如服务通信层。
中间件的核心是“统一标准、分散实现、集中配置”。它具有以下功能：解决汽车功能的可用性和安全要求；保持汽车电子系统的冗余；移植不同平台；实现标准的基本系统功能；通过网络共享软件功能；集成多个开发商提供的软件模块；更好地维护产品寿命；充分利用硬件平台处理能力；实现汽车电子软件的更新升级。
面向服务的软件架构SOA（Service-Oriented Architecture）具有松耦合的系统有中立的界面定义，这意味着 由于应用程序的组件和功能没有被强制绑定，应用程序的不同组件和功能与结构之间没有密切的联系。当应用程序服务的内部结构和实现逐渐改变时， 软件架构不会受到太大影响。
可访问接口标准和优秀扩展 SOA 使服务组件的部署不再依赖于特定的操作系统和编程语言，在一定程度上实现软硬件的分离。SOA从用户的角度考虑软件架构开发的功能，以业务为中心，抽象包装业务逻辑。
新一代中间件平台支持的自动驾驶软件，通过SOA进行适当颗粒度的功能抽象、软件代码插件化（独立的开发、测试、部署及发布） 、软件功能服务化以及功能之间松耦合。
AUTOSAR（见附录）是一个各大整车厂商和零部件厂商联合制定软件的标准化接口。
AI模型压缩和加速是两个不同的话题，压缩重点在于减少网络参数量，加速目的在降低计算复杂度、提升并行能力等。
目前压缩和加速AI模型的技术大致分为四种方案如下：
1) 参数修剪和共享：探索模型参数中的冗余，并尝试去除冗余和不重要的参数；2) 低秩分解：使用矩阵/张量分解来估计深度CNN模型的信息参数；3) 迁移/紧致卷积滤波器：设计特殊的结构卷积滤波器，以减少参数空间并节省存储/计算；4) 知识蒸馏：学习蒸馏模型并训练更紧凑的神经网络以再现更大网络的输出。
通常，参数修剪和共享、低秩分解和知识蒸馏方法可以用于具有全联接层和卷积层的深度神经网络模型；另一方面，使用迁移/紧致滤波器的方法仅适用于具有卷积层的模型。低秩分解和基于迁移/紧致滤波器的方法提供了端到端流水线，可在CPU / GPU环境中轻松实现。参数修剪和共享会使用不同的方法，如矢量量化，二进制编码和稀疏约束等。总之，实现压缩和加速需要多个步骤来进行。
至于训练方式，可以从预训练方式中提取基于参数修剪/共享低秩分解的模型，或者从头开始训练（train from scratch）。迁移/紧致卷积滤波器和知识蒸馏模型只能从头开始训练。这些方法是独立设计的，相互补充。例如，可以一起使用迁移网络层以及参数修剪和共享，也可以将模型量化和二值化与低秩分解近似一起使用。
知识蒸馏将深度宽度网络压缩成较浅网络，其中压缩模型模拟了复杂模型所学习的函数。基于蒸馏方法的主要思想是通过学习得到softmax输出的类分布，将知识从大教师模型转变为小学生模型。一种蒸馏框架通过遵循“学生-教师”范式来简化深度网络的训练，其中学生根据教师输出的软版本受到惩罚；该框架将教师网络（teacher network）集成到一个有类似深度的学生网络（student network）中，训练学生预测输出和分类标签。
模型参数可以采用32位/比特浮点（FP32）格式表示，但不如以定点（fixed point）格式表示，因为这几乎没有精度损失，甚至更高，但计算量却较低。这种策略不仅可以减少占用的内存，还可以减少与计算相关的功耗。但是，DNN模型的每一层对准确性都有不同的影响，因此可以使用细粒度的混合精度量化方法，其中每层权重和激活值的位宽不同。
自动驾驶芯片以及SOC（system on chip），目的是实现高效、低成本、低功耗的自动驾驶计算平台。而工控机实现的自动驾驶平台，是很难实现量产规模化和控制成本的。
一个SOC可能会包括自动驾驶芯片（深度学习模型实现）、CPU/GPU、DSP芯片、ISP芯片和CV（计算机视觉）芯片等。在芯片基础上，还有一个支持深度学习模型实现的编译器需要开发来最大效率地提高芯片的利用率，避免处理器等待或者数据瓶颈堵塞。
其中算法的适配性（模块和进程分解）、自动驾驶软件的高效运行（包括进程数据通信、深度学习模型加速、任务调度和资源管理等）及其安全（功能安全/预期功能安全）保障，都是需要很多工程性的艰苦努力和必要付出的代价（比如系统冗余）。
目前英伟达的Xavier和Orin（见附录）是市场上最成功最开放的自动驾驶芯片。
AI的最挑战应用之一，自动驾驶，是一个长尾效应的典型。大量少见的极端情况（corner case）往往是缺乏搜集的训练数据，这样要求我们在一个闭环中不断地发现这些有价值的数据，标注后放入训练集中，同时也放入我们的测试集或者仿真场景库；在NN模型得到迭代升级后，会再交付到自动驾驶车进入新的循环，即数据闭环。
如图就是特斯拉的数据闭环框架：确认模型误差、数据标注和清洗、模型训练和重新部署/交付。
如图是谷歌waymo的数据闭环平台：数据挖掘、主动学习、自动标注、自动化模型调试优化、测试校验和部署发布。
数据闭环需要一个云计算/边缘计算平台和大数据的处理技术，这个不可能在单车或单机实现的。大数据云计算发展多年，在数据批处理/流处理、工作流管理、分布式计算、状态监控和数据库存储等方面提供了数据闭环的基础设施支持。
模型训练平台，主要是机器学习（深度学习）而言，开源的最早有Caffe，目前最流行的是Tensorflow和Pytorch（Caffe2并入）。在云平台部署深度学习模型训练，一般采用分布式。按照并行方式，分布式训练一般分为数据并行和模型并行两种。当然，也可采用数据并行和模型并行的混合。
-模型并行：不同GPU负责网络模型的不同部分。例如，不同网络层被分配到不同的GPU，或者同一层不同参数被分配到不同GPU。
-数据并行：不同GPU有模型的多个副本，每个GPU分配不同的数据，将所有GPU计算结果按照某种方式合并。
模型并行不常用，而数据并行涉及各个GPU之间如何同步模型参数，分为同步更新和异步更新。同步更新等所有GPU的梯度计算完成，再计算新权值，同步新值后，再进行下一轮计算。异步更新是每个GPU梯度计算完无需等待，立即更新权值，然后同步新值进行下一轮计算。
分布式训练系统包括两种架构：Parameter Server Architecture（PS，参数服务器）和Ring -AllReduce Architecture（环-全归约）。
主动学习（active learning）的目标是找到有效的方法从无标记数据池中选择要标记的数据，最大限度地提高准确性。主动学习通常是一个迭代过程，在每次迭代中学习模型，使用一些启发式方法从未标记数据池中选择一组数据进行标记。因此，有必要在每次迭代中为了大子集查询所需标签，这样即使对大小适中的子集，也会产生相关样本。
机器学习模型往往会在out-of-distribution（OOD) 数据上失败。检测OOD是确定不确定性（Uncertainty）的手段，既可以安全报警，也可以发现有价值的数据样本。
不确定性有两种来源：任意（aleatoric）不确定性和认知（epistemic）不确定性。导致预测不确定性的数据不可减（Irreducible）不确定性，是一种任意不确定性（也称为数据不确定性）。另一类不确定性是由于知识和数据不适当造成的认知不确定性（也称为知识/模型不确定性）。
最常用的不确定性估计方法是贝叶斯近似（Bayesian approximation）法和集成学习（ensemble learning）法。
一类 OOD 识别方法基于贝叶斯神经网络推理，包括基于 dropout 变分推理（variational inference）法、马尔可夫链蒙特卡罗 (MCMC) 和蒙特卡罗 dropout法等。另一类OOD识别方法包括 (1) 辅助损失或NN 架构修改等训练方法，以及 (2) 事后统计（post hoc statistics）方法。
数据样本中有偏离正常的意外情况，即所谓的极端情况（corner case）。在线检测可以用作安全监控和警告系统，在corner case情况发生时进行识别。线下检测可应用于大量收集的数据，选择合适的训练和相关测试数据。
DevOps，简单地来说，就是更好的优化开发(DEV)、测试(QA)、运维(OPS)的流程，开发运维一体化，通过高度自动化工具与流程，使得软件构建、测试、发布更加快捷、频繁和可靠。
DevOps 是一个完整面向IT运维的工作流， IT 自动化以及持续集成（CI）/持续部署（CD）作为基础，来优化程式开发、测试、系统运维等所有环节。
主干（trunk- based）开发是CI前提（不是特征分支开发），自动化以及代码集中管理是实施CI的必要条件。DevOps 是CI思想的延伸，CD/CI是 DevOps 的技术核心。
MLOps的核心目标是使得AI模型从训练到布署的整条端到端链路能够稳定，高效地运行在生产环境中，满足客户的终端业务需求。
为了达到这个目标，其对AI系统核心技术也提出了相应的需求。比如布署自动化，对AI框架的前端设计会提出明确的需求，如果AI框架的前端设计不利于导出完整的模型文件，会使得大量的下游不得不在布署环节引入针对各自业务场景需求的”补丁”。
布署自动化的需求，也会催生一些围绕AI核心系统的软件组件，比如模型推理布署优化、模型训练预测结果的可复现性和AI生产的系统可伸缩性。
基于场景的自动驾驶汽车测试方法是实现加速测试、加速评价的有效途径。
“场景作为行驶环境与汽车驾驶情景的一种综合体现，描述了车辆外部行驶环境的道路场地、周边交通、气象(天气和光照)和车辆自身的驾驶任务和状态等信息，是影响和判定智能驾驶功能与性能因素集合的一种抽象与映射，具有高度的不确定、不可重复、不可预测和不可穷尽等特征”。
1）按照场景的抽象程度，可分为功能场景、逻辑场景、具体场景；2）按照测试场景数据来源，可分为自然驾驶场景、危险工况场景、标准法规场景和参数重组场景。
场景：静态部分和动态部分交通：驾驶行为和VRU（行人、自行车）等非机动行为天气：传感器（摄像头、雷达、激光雷达）和干扰
场景库建设，基本上基于真实、虚拟以及专家数据等不同的数据源，通过场景挖掘、场景分类、场景演绎等方式分层构建成一个完整的体系。
德国PEGASUS（见附录）是一个建立场景数据库的传统方法项目。
不少自动驾驶公司都公布过自己的安全报告，其中涉及到自动驾驶安全的诸多设计考虑，主要有：
系统安全操作域设计（ODD）应变（最小风险条件）目标和事件监测和反应（OEDR）信息安全验证和确认（V&V）政府法规
自动驾驶车辆应工作在操作域设计（ODD）的场景，在出现任何故障和故障时，可预测、可控和安全地运行。与安全相关的故障是指一种对人员造成合理概率伤害的故障。其他类型的故障可能会导致与安全无关的结果，例如驾驶员的不幸体验。
所谓最小风险条件是一种系统状态“当给定行程无法或不应完成时，降低撞车风险……这可能需要自动将车辆停在其当前行驶道路内，或需要进行更广泛的机动，以便车辆从活动车道上移开和/或自动将车辆返回调度中心。对于L3级自动驾驶系统，当接近ODD出口或出现自动驾驶故障时，一个善于接受的“应变准备就绪用户（fallback-ready user）”应准备好接管驾驶任务。
ISO 26262，“用于功能安全的道路车辆”，国际标准化组织于2011年制定的汽车生产中电气和/或电子系统功能安全标准。功能安全过程需要进行危险分析和安全风险评估（hazard analysis and safety risk assessment），该评估指定了一个称为汽车安全完整性等级（Automotive Safety Integrity Level，ASIL）的属性。对于高度安全相关的功能，内置了特定的冗余，以便这些系统的故障不会造成不合理的安全风险。
这种情况可分为三类：“故障运行（fail- operational）”，其中一个传感器可能会故障，但冗余传感器可以继续系统的安全运行；“故障降级（fail-degraded）”，当发生故障时，系统仍在运行，但可能不具备全部功能；以及“故障安全（fail-safe）”，即系统不再运行，但故障不会造成不安全状况。
ISO 26262的目标是：
- 提供汽车安全生命周期，并支持定制必要的活动
- 涵盖整个开发过程的功能安全方面
- 提供一种基于汽车特定风险的方法来确定风险等级（ASIL）
- 使用ASIL来指定各个条目的必要安全要求
- 提供验证和确认（V&V）措施的要求
ISO 26262标准包括十部分，分别为：
- 词汇，功能安全管理，概念阶段（1-3）；
- 系统级、硬件级和软件级的产品开发（4-6）；
- 生产经营及配套流程（7-8）；
- 汽车安全完整性等级（ASIL）导向分析和安全导向分析（9）；
- 准则（10）。
汽车安全完整性等级（ASIL）是ISO 26262-道路车辆功能安全标准定义的风险分类方案。按标准有4个ASIL级别，即A-B-C-D，从最低到最高。ASIL的确定是危害分析和风险评估（hazard analysis andrisk assessment）的结果。
ASIL D代表在发生故障时可能发生严重危及生命或致命伤害，并要求最高级别的保证，以确保相关安全目标充分且已实现。提到“质量管理（QM）”，QM级别意味着与危险事件相关的风险并非不合理，因此不需要按照ISO 26262采取安全措施。
IEC 61508定义了广泛引用的安全完整性等级（SIL）分类。ASIL是风险的定性度量，SIL是根据安全功能的类型定量定义为危险故障的概率或频率。ASIL D与SIL 3对齐，ASIL A与SIL 1相当。
美国国家高速交通安全局（NHTSA，National Highway Traffic Safety Administration）负责制定、设置和执行美国联邦机动车安全标准（FMVSS）以及机动车和设备法规。其使命描述为“拯救生命、防止受伤、减少与车辆相关的碰撞”，确保自动驾驶车辆的道路测试将对其他道路使用者的风险降至最低；另外，将测试操作限制在适合测试自动驾驶车辆能力的道路、交通和环境条件下；并制定报告要求，以在测试期间监控自动驾驶技术的性能，确保从自动驾驶模式过渡到驾驶员控制的过程安全、简单和及时；自动驾驶测试车辆应具有检测、记录并通知驾驶员自动技术系统出现故障的能力，确保任何自动驾驶车辆技术的安装和操作不会禁用任何联邦要求的安全功能或系统。
ISO/PAS 21448规定了车辆预期功能安全性（SOTIF），做危急情况分析，比如天气状况、机械扰动、电磁兼容干扰、声干扰和糟糕的反映。SOTIF指由于预期功能的不足或人员合理预见的误用而导致的危害；其定义并改进功能定义，将以下风险降低到可接受的水平：
-通过分析，那些预先功能的剩余风险-通过验证，那些已知情况下的意外行为-通过验证情况的确认，那些可能导致意外行为的剩余未知情况
SOTIF的自动驾驶系统功能局限包括：
-目标场景考虑不周到，系统无法对环境做出正确相应 （Perception）-功能逻辑仲裁机制、算法不合理，导致决策出现问题 （Decision）-执行机构的输出与理想输出发生偏差，难以完美控制 （Execution）
SOTIF把驾驶的场景(Scenario)分成四个区间：
-已知安全 Known Safe-已知不安全 Known Unsafe-未知安全 Unknown Safe-未知不安全 Unknown Unsafe （黑天鹅）
SOTIF主要覆盖电子电器系统非故障引起的危害, 例如：1）车辆运行过程中超出了ODD范围，需要驾驶员接管（但是系统本身并无故障，并不算是“失效”），而且这个接管过程需要一定时间；在这个接管的过渡时间中，要保证系统能够“坚持住”，这就对系统提出了新的安全要求；2）视觉感知系统将一个救护车误认为是一辆普通的卡车，而导致车辆没有给救护车让道，电子电器系统没有任何失效，但是确实形成了某种危害。
SOTIF一般验证都是围绕ODD/OEDR/应变等引申出来的含义展开的, 比如系统性的把智能驾驶系统暴露出ODD，看看系统接管的性能是否OK；系统性的训练和测试系统的OEDR能力（感知极端工况），看看系统的响应是否正确。还有一个安全任务是汽车的网络安全，网络安全漏洞可能会损害系统实现基本安全目标的能力。
BMW公司在其L3级自动驾驶概念车Vision iNEXT设计中就考虑各种安全故障的处理（见附录）。
自动驾驶进入一个工程化落地的时期，这里提到了一些必要的工程化要素，如线控底盘、电子电气架构、中间件软件平台、模型压缩加速、车载自动驾驶芯片（计算平台）、数据闭环、DevOps/MLOps、场景库建设及其测试和系统安全设计等。
另外，这里还有没提到的工程问题，比如传感器清洗、计算平台的内存/指令优化和任务调度等。
2021 年 2 月，小马宣布最新一代的自动驾驶车辆从一套标准化产线正式下线，开启全天候自动驾驶的公开道路测试，并加入到各地的 Robotaxi 车队中做规模化的运营。
这批车辆从设计、开发到产线生产、标定和验证，经历非常严格的标准化流程。整个流程里面大概涉及 40 多道工序（如摄像头和激光雷达清洗、震动和防水等）200多项质检项目，尽可能保证整个系统的一致性。
比起以前的系统，在硬件稳定性方面大概有 30 倍到 50 倍提升的效果，整个自动驾驶系统的生产效率和前一年相比大概能够提升 6 倍。
2022年1月20日，小马智行公开新自动驾驶解决方案，包括软硬件系统外型设计、传感器以及计算平台。据说，该系统面向L4车规级量产设计，可加速 L4自动驾驶技术的规模化部署。第一批搭载该系统的车型为丰田S-AM（7座赛那混电），计划2023年上半年投入Robotaxi日常运营。
2021年12月22日，AutoX（安途）对外揭晓AutoX RoboTaxi超级工厂的内部视频。该超级工厂由Auto X独立设计、投建。而RoboTaxi则是AutoX与克莱斯勒FCA集成合作打造，具备车规级冗余线控，支持量产。
AutoX无人车零部件进入仓库后，先进行质量检测，通过检测的零件走上部装线，进行局部集成。
总装线由半自动化滑板传输线和吊装输送线组成，采用ABB 7轴机器人。电控系统与传动系统则是由西门子、欧姆龙、施耐德、飞利浦、三菱、SEW等提供。从车内操作界面可以对系统的全部软硬件模块进行质检。
下线时，车间内自动化多传感器在转盘、四轮定位等方面进行标定，并在厂内完成恒温房、喷淋房等车规级检测，在出厂时即可进入无人驾驶状态。
Xavier被NVIDIA称作为“世界上最强大的SoC（片上系统）”，有高达 32 TOPS的峰值计算能力和 750 Gbps 的高速 I/O 性能。
Xavier SoC基于台积电12nm工艺， CPU采用NVIDIA自研8核ARM64架构（代号Carmel），GPU采用512颗CUDA的Volta，支持FP32/FP16/INT8，20W功耗下单精度浮点性能1.3TFLOPS，Tensor核心性能20TOPs，解锁到30W后可达30TOPs。
Xavier 内有六种不同的处理器：Volta TensorCore GPU，八核ARM64 CPU，双NVDLA 深度学习加速器（DLA），图像处理器，视觉处理器和视频处理器。
和Xavier相比，Orin的算力提升到接近7倍，从30TOPS提升到了200TOPS。CPU部分从ARM Cortex A57到A78。Xavier的功耗大概30W，Orin功耗仅为45W左右。
Orin多芯片方案版本用两个Orin + 两个7nm A100 GPU，算力达到2000TOPS。Orin 系统级芯片集成NVIDIA 新GPU 架构Ampere、Arm Hercules CPU 内核、新深度学习加速器（DLA）和计算机视觉加速器（PVA），每秒运行200万亿次计算。
DRIVE AGX系列推出一款新型Orin SoC。其功率仅为5瓦，但性能却可达到10 TOPS。
NVIDIA 构建并开放 DRIVE Hyperion 平台。该平台配置高性能计算机和传感器架构，满足自动驾驶汽车的安全要求。DRIVE Hyperion 采用适用于软件定义汽车的冗余 NVIDIA DRIVE Orin 系统级芯片，持续改善和创建各种基于软件和服务的新业务模式。
新平台采用 12 个环绕摄像头、12 个超声波模块、9 个普通雷达、3 个内部感知摄像头和 1 个前置激光雷达打造。是有功能安全的架构设计，具备故障备份。
不少汽车制造商、卡车制造商、一级供应商和无人驾驶出租车服务公司采用了此 DRIVE Hyperion 架构。
AUTOSAR (AUTomotive Open System ARchitecture) 是由各大整车厂商和零部件厂商联合制定的，是由BMW、BOSCH、Continental、DAIMLER、Ford、OPEL、PSA、TOYOTA、VW等共同制定的汽车开放式系统架构标准，俗称AUTOSAR Classic （CP），基本上做为MCU/ECU的标准，包 括发动机控制机和电机控制器。
CP主要包含微控制器层（Microcontroller）、基础软件层（Basic Software）、中间件层（Runtime Environment，RTE）以及应用层（Application）。基础软件层再分为服务层（Services Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer）和复杂驱动（Complex Device Drivers）。
具体讲，服务层主要提供各类维持系统运行的基础服务，如监控，诊断，通信，以及实时操作系统等；ECU抽象层主要功能是封装微处理器及其外围设备；微处理器抽象层主要功能是对微控制器进行分装，例如I/O、ADC、SPI等；复杂驱动用于那些不能进行统一封装的复杂硬件，为上层RTE访问硬件提供支持。
后来出现的AUTOSAR Adaptive platform （AP），更多地应用于 ADAS 和自动驾驶等对于计算能力和带宽通信要求更高的领域中，尽可能从其他领域 (如消费电子产品) 的发展中获益，同时仍然考虑汽车的特定要求，如功能安全。
AP平台主要提供高性能计算与通讯机制，并且提供灵活的软件配置，例如软件远程更新（OTA）等，包括如下主要部分：（1）用户应用，一个应用可以为其他应用提供服务，这样的服务称为非平台服务；（2）支持用户应用的AUTOSAR Runtime（ARA，Autosar Runtime for Adaptive Application），其由功能集群提供的一系列应用接口组成，其中有两种类型的功能集群，即自适应平台基础功能和自适应平台服务；（3）硬件视作机器（Machine），可以通过各种管理程序相关技术虚拟化，并且可以实现一致的平台视图。
AP需要支持E2A的两个关键特征：异构软件平台的集成和面向服务的通信。AP组件封装面向服务SOA软件底层的通讯细节 (包括SOME/IP协议，IPC等)，同时提供代理(Proxy)-骨架(Skeleton)模型，方便应用开发人员调用标准服务接口(API)进行开发。
AP选择POSIX PSE 51作为OS要求，避免底层OS过于复杂，上层应用限制使用一些复杂功能，避免overspec。
德国PEGASUS项目（2016~2019年5月）聚焦于高速公路场景的研究和分析，基于事故以及自然驾驶数据建立场景数据库，以场景数据库为基础对系统进行验证。
该研究定义了场景（scenario）“功能—逻辑—具体”（functional-logical-concrete）三级分层体系，以及面向概念—开发—测试—标定 (concept-development-testing-calibration) 的场景库构建流程及智能驾驶测试方法。
PEGASUS通过开发OpenScenario接口试图建立可用于模拟仿真、试验场和真实环境中测试和试验高级智能驾驶系统的标准化流程。
该项目分四个阶段：1）场景分析&质量评估，定义一种系统的场景生成方法以及场景文件的的语法结构，计算场景的KPI，定义一套基于专家经验的场景困难（危险）程度评价方法；2）实施流程，以安全为基础，设计一套足够灵活的、鲁棒性强的适用于自动驾驶功能的设计实施流程；3）测试，输出为一套用于实验室（仿真软件，台架等）以及真实交通场景的方法和工具链；4）结果验证&集成，对前三个阶段的结果进行分析。
PEGASUS建立三种测试场景格式标准，即OpenCRG、OpenDRIVE和OpenSCENARIO，定义了测试场景的六层模型：道路层、交通基础设施、前两层的临时操作（如道路施工现场）、对象、 环境和数字信息。
宝马2018年发布了L3自动驾驶概念车Vision iNEXT，驾驶员可以选择自己驾驶（在“加速Boost”模式下）或被驾驶（在“缓解”模式下）。“增压”模式使用电力驱动系统，提供高动态、几乎静音的零排放驾驶体验。在“轻松Ease”模式下，车辆为驾驶员和乘客提供了一个从事一些活动的空间。
一旦系统出现故障，L3级BMW自动驾驶车将以视觉、听觉和触觉警报的形式向人类驾驶员发送一系列警告，紧急程度将越来越高。该警告级联包括L3级BMW自动驾驶接管请求，并使用人机界面（HMI）。如果应变准备就绪用户（即人类驾驶员）不接受接管请求的警告级联，L3级宝马自动驾驶车将执行风险缓解操作。这仅仅意味着，如果无法到达路肩，例如在交通繁忙时，车辆将采取行动，甚至包括在硬路肩或车道上安全停车。如图所示是风险缓解过程示意图：
宝马INEXT概念车遵循相同的BMW流程，这些流程包括ISO 26262和ISO/PAS 21448 SOTIF以及其他稳健的内部流程。L3级BMW自动驾驶车中故障安全操作的一个例子是风险缓解（risk mitigation）策略。
随着对L3级BMW自动驾驶车的改进，稳健的更新过程变得至关重要。iNEXT生产车辆将部署OTA（over-the-air）功能。这些软件更新遵循行业最佳实践的开发、验证和部署策略，以便及时交付。
在SOTIF功能架构中，BMW区分技术（Technical）SOTIF和人为因素（Human Factors ）SOTIF，因为措施验证可以通过技术设计决策（设计-安全）或通过验证系统的人类行为来显示安全运行（与评估风险相关的设计决策）。在功能安全方面，根据ISO 26262定义了驾驶功能的安全目标，并导出功能和技术安全概念。
在故障条件下，BMW设计可通过“故障运行（fail operational）”策略（冗余）、“故障降级（fail degraded”）”策略（降级运行）或“故障安全（fail safe）”策略（使车辆安全停车）实现安全功能。选择哪种方法始终取决于故障条件下设计元素的性质和系统的剩余能力。
考虑的设计安全因素包括：
-设计架构-传感器-执行器-通信故障-潜在的软件错误-可靠性-潜在不胜任的控制-不良控制行为-与环境目标和其他道路使用者的潜在碰撞—可能由自动驾驶车操作引起的潜在碰撞-离开道路-失去牵引力或稳定性-违反交通法规-与正常/预期驾驶实践的偏差
BMW认为有必要采用多样性冗余（多样性）：主通道和辅助通道本身冗余，并且都有自己的诊断单元。这允许检测有故障的通道，并让另一个通道接管。如果故障影响两个通道，第三个基本通道将接管，以达到最低风险条件。
如图就是BMW在L3级自动驾驶的冗余安全设计：
实施冗余的目标，就是允许驾驶员作为应变准备就绪（fallback-ready）用户接管驾驶任务。如果应变准备就绪的用户没有接管驾驶任务，则会触发风险缓解（risk mitigation）操作。
风险缓解策略确保安全运行，直到达到故障安全状态（即驾驶员接管驾驶任务或车辆完全停止）。若无法确保L3级BMW 自动驾驶的安全连续运行，将执行该程序，例如：
-如果驾驶员忽略了标准接管请求（TOR）；
-由于环境条件中的危险导致减少的传感器或执行器
-性能（传感器堵塞、低摩擦等）—由于车辆部件（机械、E/E）的故障。
故障操作（fail-operational ）策略如图所示：