自2002年开始开发以来，AUTOSAR已在汽车行业确立了自己的地位，成为软件基础结构和系统描述的全球标准，具有连续的设计流程和标准的交换格式，供所有参与的开发合作伙伴使用。从2009年推出AUTOSAR Release 4.x开始，系统地替换了车辆电子控制单元无差别软件中的所有专有解决方案。从那时起，AUTOSAR的工作就从后向标准化转变为向前标准化，并为汽车行业提供了独特的支持，例如多核和以太网等新技术。本文将继续就AutoSar在汽车电子及自动驾驶系统中的开发应用进行分析介绍，力求从不同的维度上帮助读者解读和分析相应的技术原理。

AutoSar的系统配置

在AUTOSAR的上文中，系统是指网络控制单元的组合，其中可以包括车辆的所有ECU。系统配置遵循虚拟总线功能-VFB级别上功能系统体系结构的发展。在设计系统配置时，要考虑系统的实际物理体系结构。这些决定主要与系统拓扑有关，即哪些控制单元可用以及如何连接。对于每个控制单元，都有关于处理器体系结构，处理器容量，内存，接口以及外围设备或信令方法的资源描述。网络拓扑的描述范围从总线系统到各个通道的通信矩阵。此外，它包含确定哪个应用程序软件组件应在哪个控制单元上运行的确定性。所有这些信息都注册在系统描述中。实际上，这可以通过系统体系结构设计工具以及VFB设计（也称为系统生成器）来完成，也可以通过基本软件模块的配置工具来完成。系统配置通过单个控制单元的进一步配置成功完成，最后通过软件集成而成功搭载。软件集成对于每个ECU是独立的，即，如果需要，它可以并行运行。某个控制单元的所有相关信息将被复制到系统配置之外的ECU描述中，这被称为系统描述的ECU摘录。

ECU还汇总了每个基本软件模块的配置描述。基本软件配置的许多参数直接来自系统说明或软件组件的说明，剩余的可用参数是使用基本软件配置工具设置的。在几乎所有基本软件模块的配置步骤完成之后，属于配置的代码由生成器生成-就像在RTE中一样。应用程序软件组件的实现（即算法和编码的创建）可以完全与系统配置并行完成，因为此步骤独立于硬件。最终，基本软件的整个代码以及RTE代码和所有应用软件组件的代码都集成到每个控制单元的ECU软件中。

对自动驾驶系统特性的影响

AUTOSAR标准旨在开发车辆中整个电气/电子系统的软件。唯一的例外是信息娱乐系统，因为它们的软件设计与消费电子产品非常接近，因此使用了许多基本机制，例如动态内存管理。因此，自动驾驶系统是AUTOSAR标准的核心焦点，AUTOSAR标准为驾驶员辅助系统提供的一些特定机制。

1）分布式实时系统的开发

自动驾驶系统通常具有相对复杂的算法，高安全性要求和多种传感器的特点。它们通常被实现为分布式实时系统，例如在一个ECU中对传感器数据进行预处理，并在不同的ECU上处理控制算法，或者将监视或诊断功能放在单独的ECU上实现的。

AUTOSAR从以下不同方面简化了分布式实时系统的开发：

—— 使应用软件的实现（即源代码的编码）与功能和物理体系结构的设计以及系统配置脱钩。

—— AUTOSAR设计方法可以在电子控制单元上灵活分发应用软件。系统配置以及软件组件到电子控制单元的分配是静态的，即分配在运行时无法更改，但在设计过程中相对容易。

—— 对于软件组件，可以考虑响应和执行时间的要求。因此，可以定义单个ECU或整个系统的条件以及其他可用资源。此信息在整个开发过程中都可用，并且将由适当的软件开发工具考虑。例如，对于车道偏离警告系统的应用，可以定义最大200 ms的时间延迟并将其细分为各个资源单元。

—— 描述的标准化交换格式简化了多个开发合作伙伴对分布式系统的开发。

2）AUTOSAR功能安全机制（ISO 26262）

有关车辆功能安全的基本方法在发布的标准ISO 26262中进行了描述。ISO 26262是系统开发标准，它定义了开发车辆中电气/电子系统的过程和技术要求。从系统描述以及派生的危害分析和风险评估开始，定义了相应的安全机制。在系统开发过程中，在功能和相关的技术安全概念中对它们进行了说明。从技术安全概念出发，在系统设计的背景下得出了对系统软件的要求。ISO 26262的第6部分包含与安全相关的软件开发的相应要求。由于AUTOSAR标准定义了开发方法和软件基础结构，因此只能实现技术安全概念的部分内容。因此，根据ISO 26262的命名法，AUTOSAR也被称为“上下文安全元素”。这意味着开发项目中的特定安全要求必须与AUTOSAR标准中有关技术安全概念的假设相一致。

在AUTOSAR的开发过程中，分析了典型的技术安全概念和ISO 26262的技术要求，并推导出了适当的安全机制，并将其集成到AUTOSAR标准中。特别要强调的是内存分区、端到端保护、程序流监控、防御行为。

在对与安全相关的驾驶员辅助系统的技术安全概念进行规范说明期间，需要适当考虑AUTOSAR提供的安全机制，以避免在ECU的开发和验证中进行过多的工作。

3）内存分区

内存分区为驻留OS应用程序的一个或多个软件组件在内存中创建的保护边界。这些软件组件在应用程序级别上又被组织为逻辑分区。它们对内存（包括主内存和非易失性内存）以及内存映射硬件的写入权限有限。另外，在内存分区中运行的软件应用程序以CPU的应用程序模式执行。这意味着它们只能访问CPU的特殊控制寄存器，并且不能执行限于超级用户模式的特殊命令。

如果软件组件在应用程序分区中运行并尝试写入非法存储区，则将被所谓的基于硬件的存储器保护单元（MPU）检测到，并且相应的写访问将被阻止。这会导致执行和应用程序分区中断，从而导致错误。相应的应用程序分区将以受控结尾方式由操作系统和RTE决定。如果进行了相应的配置，此分区中的所有软件组件将随后启动。如果位于应用程序分区中的软件组件尝试更改CPU寄存器（只能在超级用户模式下更改），则相同的机制也将生效。

4）端到端保护

端到端安全协议的概念假定在该术语期间应保护与安全相关的数据交换，以防止对物理总线进行通信的两个软件组件之间的通信路径产生错误影响。这些例子都是随机的硬件错误，例如发送或接收网络控制器中的寄存器损坏，电磁波干扰以及在例如RTE或网络中实现虚拟功能总线通信的软件中的系统错误，堆栈等。

端到端安全协议可以在通信路径中发现这些错误并在运行时进行处理。AUTOSAR的端到端库提供了满足最高与汽车安全完整性等级D（ASIL）有关的安全相关通信要求的相应机制。它们的基本机制是校验和（CRC），消息ID和活动计数器。保证机制的相应算法和状态机在所谓的AUTOSAR端到端库的规范中定义。如上图显示了使用端到端库的两个软件组件之间的通信操作。

5）程序流监控

程序流的监视旨在发现应用软件的控制过程中的故障。当一个或多个程序指令以错误的顺序，不及时地执行或根本不执行时，就会发生错误的程序流程。控制序列中的错误可能来自系统性软件错误或随机性和系统性硬件故障。它们可能导致数据损坏，程序中止，并最终导致违反安全目标。

程序流的监视涉及两种监视：首先，监视随时间的行为，称为“临时程序流监视”，其次，监视程序段的逻辑执行顺序，称为“逻辑程序流监视”。AUTOSAR基本软件模块看门狗管理器提供了监视程序执行的核心功能。这监视所谓的被监视软件组件，它们是逻辑被监视单元。

根据软件组件的安全性和整个系统的安全性要求，受监视的单元可以是一组软件组件或组件内的可执行软件模块。被监视的软件模块在预定点用控制代码调用看门狗管理器。由此可以确定受监视的软件模块是否在正确的时间范围内以正确的顺序执行。在违反预定时间限制的情况下，执行指定的预定安全机制，这可能导致ECU立即复位。

6）防御行为

软件的防御行为旨在防止软件中错误的再现和传播，它是软件的非功能性特征，通常通过适当的编程准则和代码模式来实现。因此，AUTOSAR基本软件的防御行为不是由标准本身设置的，而是由标准的实施者确保的特性。典型的措施是，例如，保证不会破坏软件模块的安全相关数据。在从软件组件传输到另一个组件之前，将立即用安全代码保护相应的数据。在接收软件组件中解码数据时，将使用安全代码再次还原数据。如果它与先前存储的数据不同，则该数据已在未经授权的情况下进行了修改，并且软件组件可以触发适当的错误处理。

功能验证中的虚拟化

供应商和汽车制造商的分布式软件组件开发，并行开发基本软件和软件组件，以及汽车制造商或其他供应商将其集成到ECU中，这就使得所有组件的功能迅速增加。软件组件本身的功能，它们与RTE和基本软件的交互以及本节中介绍的安全机制的有效性，以及驾驶员辅助系统运行时的合规性要求是一些机制和功能的示例，需要在最早的时间点进行验证。发现错误的时间越晚，解决方案的工作量就越大，开发项目的风险就越高。所以问题是：如何在操作环境中尽早验证自动驾驶系统的功能？

虚拟验证提供了一种有效的可能性。在主机环境中，集成了AUTOSAR基本软件。可以集成来自不同制造商的软件实现，包括针对客户的调整。使用特定扩展，基本软件的行为类似于带有集成微处理器的控制单元的行为。完全虚拟的验证平台既可以通过软件实现，也可以通过连接的硬件组件实现。在后一种情况下，接口转换器连接到验证主机，以确保与车辆接口的连接。此外，基本软件还包含与硬件兼容的“微控制器抽象层”以及相关的硬件驱动程序。

在开发软件组件的过程中，一方面可以在将软件集成到ECU之前，并对其功能进行测试和验证。另一方面，可以使用可直接在主机操作系统上使用的开发工具（例如调试器）上进行，从而使工作流程更高效。

AUTOSAR的基本软件允许使用设计方法学中的工具来进行标准化开发。该系统在考虑到现有的系列车辆软件和ECU以及传感器等新技术的前提下，确保了软件组件在早期开发阶段的功能。在这种情况下，早期开发的ECU的硬件不需要具备全功能。当然，这可以通过汽车主机厂特定的软件来实现。但是只有AUTOSAR才能实现一致的移植，从而跨OEM为其他项目重复使用测试用例。由于采用了标准化的应用程序接口，虚拟验证平台的实现是模块化和结构化的，因此可以有效实现。

在引入敏捷软件开发方法时，虚拟验证具有重要的优势（参见Sims and Johnson 2012）。因此，软件功能是在相对较短的迭代中开发的，并且在理想情况下，在每次迭代之后都交付了经过测试且功能良好的软件。对于与各种合作伙伴一起开发的复杂系统，这只能通过以合理成本进行虚拟验证来实现。使用虚拟验证平台可以更高效地实现敏捷开发中几乎始终使用的持续集成，并与合作伙伴之间的持续验证和软件交付相关联。

灵活的协作和共享

从技术的角度来看，由于驾驶员辅助系统等数量的增加和互连程度的提高，我们正面临越来越复杂的系统。这不仅引起开发风险，而且引起软件系统验证。所描述的AUTOSAR模块化结构允许重用软件的主要部分，且开发机制中允许集成大量软件应用程序。在开发新应用程序时，无需从头开始重新开发ECU。通过生成和配置新应用程序，可以将新应用程序集成到现有体系结构中，这对质量和开发时间有重大影响。

从组织的角度来看，现在出现了新的复杂性。开发项目涉及各种各样的供应商，并且涉及功能区域之间的大量接口。复杂软件体系结构的开发导致了广泛的多边讨论和谈判，以澄清技术可交付成果之间的接口以及供应商之间特定项目的接口。AUTOSAR设计方法有助于简化这一过程。基于XML的标准化交换格式和标准化的应用程序接口，可以有效地定义内容和交互。另外，有可能建立完全集成的工具链。设计方法论的要素和AUTOSAR规范本身将由工具制造商承担。当前，市场上有各种开发工具可以创建集成的开发环境。开发随着标准基本软件的推出，业务和工作模型也发生了根本性的变化。OEM不再使用自己的ECU基本软件，而是由微处理器制造商，供应商和软件供应商开发和测试AUTOSAR基本软件。

应用软件通过标准化接口是与基本软件进行通信。这样，多个汽车制造商可以共享软件应用程序，这意味着这些应用程序的供应商不会开发定制产品，而是为多个客户提供相同的产品。因此，这些软件应用程序是可重用的，并且由于其进一步的传播而更加稳定。相关的特定应用将由汽车主机厂进行单独指定。通过将提及的标准接口用于OEM的不同型号，将由汽车制造商自行使用相关的应用程序进行开发，并由供应商或OEM与供应商共同完成。通过已经描述的软件组件，控制单元和整个系统的形式描述，可以简化此过程。它们以标准交换格式提供，并允许工具支持的软件集成。集成工作转移到软件级别，因此转移到汽车制造商，他们必须设计体系结构并配置控制单元以及整个车辆系统，以确保最佳的重用性。

不仅单独考虑驾驶员辅助系统，而且考虑车辆当前和将来彼此之间的联网，车辆内部连接性，车辆到车辆，带有交通系统的车辆或基于Internet的服务，很明显，创新速度是实现这一目标的关键因素。在车辆中成功实施此类系统。创新的速度主要取决于软件的复用和联合开发。

硬件抽象

下层服务被称之为硬件抽象。首先，ECU抽象层将ECU布局（即外围模块与微控制器的连接方式）与上层分开。尽管此层是ECU特定的，但它独立于微控制器。下一个抽象级别是通过微控制器抽象层实现的，该层包括微控制器特定的驱动程序。例如是用于数字输入和输出的I / O驱动器，或者是用于将模拟信号转换为数字值的ADC驱动器。因此，AUTOSAR标准直接支持标准化硬件。

复杂驱动程序的层用于处理特殊情况，例如，用于控制具有特殊实时要求或特定机电硬件要求的复杂传感器或执行器。此类模块未标准化为AUTOSAR基本软件模块，因为这里需要汽车制造商或供应商的特定专业知识和知识产权。但是，复杂的驱动程序和标准化模块必须满足AUTOSAR基本软件中接口机制的要求。

总结

在过去的几十年中，用于汽车应用的软件开发变得越来越重要。对安全性，环境保护和舒适性的要求越来越高，导致车辆中使用的电子系统数量急剧增加。对废气排放和安全性越来越严格的法律要求也顺应了这种趋势，众多信息娱乐和驾驶员辅助系统也是如此，其功能依赖于各种不同的传感器，执行器和控制单元的同时交互。

这种发展速度以及功能和控制单元的日益集成给车辆制造商带来了挑战。为了一方面管理不断增长的系统复杂性和依赖性的增加，同时又要保持成本的可行性，必须以一种面向未来的方式对基本软件以及与应用程序和总线系统的接口进行标准化。AUTOSAR作为一种汽车开放系统架构，正严格按照该标准进行开发，同时已发布了多个版本。自动驾驶开发过程中需要掌握至关重要的一环是其开发的复杂性，并将通过在OEM与供应商之间建立可重用和可交换的软件模块来实现统一的软件平台管理。