产品
汽车应用软件开发已成为汽车开发过程中最复杂，最关键的活动。AUTOSAR（汽车开放系统架构）为汽车电子控制单元（ECU）开发了标准化的开放软件体系结构，是主机厂、供应商以及工具和半导体供应商的合作伙伴。重点是管理汽车电气/电子（E / E）架构开发中日益增长的复杂性，旨在实现新技术并提高开发效率-而不影响质量。Autosar旨在软件架构、开发方法、应用程序界面三个技术领域中实现标准化。
除此重点外，AUTOSAR的关键成功因素还在于其开发协议，该协议从法律层面控制着合作伙伴与其精益组织之间的关系，从而区分了即核心合作伙伴和其他合作伙伴（保费，开发和合作伙伴），从而参照精益流程以快速做出决策。
为了掌握OEM和供应商之间软件模块（例如驾驶员辅助系统）的复杂性
整体来说AutoSar有如下9个目标：
1.软件的可移植性。
OEM和供应商应能够在车辆网络内重用软件。也可以在不同OEM的不同汽车平台上使用相同的软件。
2.对不同车辆和平台型号的可扩展性。
AUTOSAR应提供用于开发可适用于不同车辆以及车辆平台和硬件的软件系统的机制。这意味着AUTOSAR应该是可配置的，以便可以集成到不同的车辆中。
3.支持不同的功能域。
AUTOSAR应该能够在尽可能多的功能域中重用软件组件。这包括与非AUTOSAR系统的数据交换，例如与车辆信息娱乐系统的通信。
4.定义开放式体系结构。
AUTOSAR的体系结构应该是可维护的，可适应的和可扩展的。因此，错误可以不断修复。可以实现将来的要求和个性化增强。
5.开发高度可靠的系统。
AUTOSAR必须实现可用性，可靠性，功能安全性，完整性，维护性和安全性。通过这种方式，例如可以考虑对功能安全性的要求。
6.自然资源的可持续利用。
支持使用有效利用自然资源和使用可再生能源的技术。
7.各种伙伴之间的合作。
汽车行业的特点是合作伙伴之间的广泛合作。AUTOSAR应通过定义数据交换格式和允许来自不同合作伙伴的基本软件和应用程序集成的体系结构来支持协作。
8.汽车ECU基本软件功能的标准化。
基本软件应可用于不同的功能域，OEM和供应商。然后可以将基本软件作为产品提供。
9.支持适用的汽车国际标准和最新技术。
AUTOSAR应与现有和相关的国际标准兼容。这允许在当前和将来的车辆系统中使用AUTOSAR。一个例子是对现有和将来的总线系统的支持，例如FlexRay，CAN，以太网等。
这些项目目标在高级系统要求的“ AUTOSAR主要要求规范”中进行了详细说明。下面的示例说明了这一点：项目目标“软件的可移植性”分为以下主要要求：
主要特征和核心功能是根据主要要求得出的。从中得出“软件需求规范”（SRS）。这些SRS的详细信息产生了“软件规范”（SWS）。下图显示了它们的相关性。“软件规范”构成了将AUTOSAR标准实施到软件中的基础。
其中，AUTOSAR的标准化分为软件架构、开发方法、应用程序界面三个技术领域。
AutoSar的软件架构
ECU软件体系结构的主要概念在于通过软件抽象层-运行时环境（RTE）来拆分独立于硬件的应用程序软件和面向硬件的基本软件（BSW）。一方面，该抽象层支持为驾驶员辅助系统开发特定于OEM且具有竞争力的软件应用程序。另一方面，它简化了与OEM无关的BSW的标准化过程。此外，这是ECU软件针对不同汽车系列和变体进行可扩展性的前提。它提供了在多个ECU之间分布应用程序以及集成来自不同来源的软件模块的可能性。
BSW进一步分为以下几层：“服务”，“ ECU抽象”，“微控制器抽象”，运行时环境从基本软件中提取应用程序层，并组织它们之间进行数据和信息通信。这构成了在应用程序级别上面向组件，与硬件无关的软件结构的基础，其中软件模块为独立的单元。例如，驾驶员辅助系统的功能由软件模块实现。这些软件模块共同构成了应用程序。各个软件模块仅直接与RTE通信。因此，无论通信发生在ECU内还是超出ECU边界，通信都经过清晰设计来确保独立性，可以在不了解所使用或计划的硬件的情况下开发软件组件，或者在ECU之间分配现有软件模块。
AutoSar设计方法论
除了软件体系结构以外，AUTOSAR还对汽车软件的开发方法进行了标准化，从而促进了现代系列项目相关合作伙伴的合作。AUTOSAR设计方法论解决了将ECU和各种ECU中的软件模块集成到具有不同总线系统的车辆通信网络中。它定义了通用工件和相关活动，尤其是活动的依赖性。该设计方法可应用于应用软件的开发，运行时环境和系统配置中。
对于产生或可以在AUTOSAR设计方法中使用的信息，AUTOSAR定义了具有语义约束的正式数据交换格式（AUTOSAR方案）。此信息作为形式描述存储在AUTOSAR XML（.arxml）文件中。许多工具将这些描述用于RTE和AUTOSAR BSW的配置和生成。例如，软件组件描述为应用程序软件提供了标准化的组件模型。或者，系统描述使用交叉链接的ECU实例定义系统上的纯软件层与物理系统体系结构之间的关系。它描述了网络拓扑，每个通道的通信以及各个ECU上软件模块的分配。AUTOSAR设计方法的原理如下图所示。
AutoSar的设计方法原理
AUTOSAR应用程序接口–所显示的接口符号
除了描述汽车工业中E / E系统的基本能力外，实际交换格式还需要许多方面支持，例如文档，需求可追溯性和各种工件的生命周期。此外，集成的变型管理使OEM和供应商可以表达基本的AUTOSAR产品系列，并在必要时与合作伙伴交换此信息。这些变体的共同理解和统一解释是成功开展项目合作的关键要素。
AutoSar应用接口
通过应用程序接口确保应用程序模块与RTE的链接。AUTOSAR一方面通过语法将基本接口机制标准化，另一方面在车辆域主体中标准化应用程序接口的语义、内部和舒适性，动力传动系统，底盘以及乘客和行人保护。其重点是针对广泛引入的应用程序的接口规范，以强调软件模块的重用和交换。最后，标准化应用程序接口的使用对于应用程序的重用至关重要。
来自AUTOSAR所有合作伙伴的专家都对接口规范进行了标准化，例如关于使用的数据类型，单位和缩放因子。它们允许软件设计人员和开发人员在扩展或复用软件模块的情况下使用它，而不依赖于任何特定的硬件或ECU。驾驶员辅助系统等应用程序包括差异化的竞争功能。因此，AUTOSAR并没有标准化应用程序的内部功能过程（例如算法），而是将在应用程序之间交换的信息。
系统架构：虚拟功能总线（VFB）
为了开发功能系统架构，AUTOSAR引入了虚拟功能总线的概念-VFB。VFB允许描述整个系统中，即整个车辆中应用模块之间的功能交互。此描述独立于实际的ECU架构和实施的网络。这样，VFB从硬件中提取了应用程序。AUTOSAR将单个应用程序描述为软件组件（SWC）。VFB既提供了它们之间的通信机制，也提供了使用基本软件到软件组件的服务的机制（请参见图7，上部）。各种机制由所谓的端口表示（参见6.1节）。
在进一步的过程中，功能系统体系结构映射到物理体系结构上，这意味着ECU和网络拓扑。在此，将软件组件分配给ECU。在每个ECU中，VFB的功能都由RTE和底层基本软件实现（请参见图7，下部）。为了避免造成误解，应明确指出：AUTOSAR已指定VFB概念。此概念已在市场上可用的各种系统架构工具中实现。
AUTOSAR设计方法概述
应用软件架构
AUTOSAR软件体系结构的层模型将应用软件以软件组件的形式放置在应用层中。
可以将软件组件分组为再次在外部充当软件组件的合成。通过这种通用组件概念，可以将软件组件的任何嵌套层次结构实现为一个系统。可以独立于硬件设计和开发应用程序软件，软件组件通过端口进行通信，每个端口代表一个某些沟通机制。在应用程序之间进行通信时，最重要的机制是用于形成由数据发送者发起的在“发送者-接收者”之间的通信端，以及用于由接收者发起的通信的“客户端”。
除此之外，还有其他端口用于过程控制（外部触发事件）或用于访问某些参数（校准，操作模式，非易失性存储器）。每个端口都有一个接口，用于确定要通信的数据类型。AUTOSAR用编程语言C定义了端口的精确映射。下图显示了ECU内部以及不同ECU中的应用程序之间的通信路径。软件组件由称为“软件组件模板”的特定AUTOSAR的正式描述。除了对端口和接口的描述之外，它还包含所谓的内部行为。
该术语成立于AUTOSAR的早期，但不幸的是经常引起误解。在AUTOSAR的上下文中，“内部行为”描述了与时间或事件相关的过程控制（事件和调度）的组件。这包括“可运行实体”的定义，即由底层操作系统按事件或时间安排的最小软件实体。明确要在组件中实现的算法不属于“内部行为”。
实际上，有几种典型的方法可以填写或编辑软件组件说明。许多用于基于模型的开发的设计工具可以从图形模型中生成软件组件描述，并允许编辑相应的条目。同样，RTE生成器通常允许编辑软件组件说明。对于具有特定硬件要求的应用程序，例如依赖于某些传感器或执行器的软件，AUTOSAR提供了所谓的传感器/执行器软件组件，在软件组件说明中可以注明这些约束。
运行时环境RTE与基本软件BSW
AUTOSAR运行时环境（RTE）将应用程序从基本软件的任何实现细节中提取出来，并从控制设备的硬件中提取出来。它表示特定ECU上VFB的运行时实现。RTE提供了应用程序之间的通信机制以及访问基本软件服务的机制。这还包括为通信提供数据缓冲和排队。
RTE的实际程序代码取决于应用程序，它们的通信，基本软件使用的服务以及调度。实际上，代码是由RTE生成器根据软件组件描述的信息创建的。严格来讲，RTE是一种“中间件”层技术，它可以通过分散的网络来重新定位应用程序层的组件。
基本软件通过RTE为应用程序提供所有系统服务和功能。尽管基本软件的功能对于应用程序必不可少，但车辆用户通常不会很好地注意到这些功能。随着对硬件的依赖性越来越高，基本软件又分为多个层：服务层，ECU抽象层和微控制器抽象层。
依次地，每个层包含代表精确指定功能范围的各个模块。AUTOSAR基本软件包含大约总共80个不同的模块，为此标准对每个模块都具有要求和软件规范。其中，模块及其接口的功能行为用C定义，因此一个模块的两种不同但符合标准的实现方式可以直接互换。基本软件模块的功能行为及其配置的参数化使用与应用程序组件相同的形式描述机制。控制单元的基本软件模块的配置说明在ECU配置说明中进行了概述。
AUTOSAR服务
服务层包括系统服务，例如通信服务，诊断协议，存储服务，ECU操作模式的管理以及作为独立模块的AUTOSAR操作系统（OS）。AUTOSAR OS基于实时系统标准OSEK / VDX，并且在某些领域得到了扩展，但在其他领域也受到限制。
它是静态配置和缩放的，并提供基于优先级的实时行为和中断处理。在运行期间，可以使用各种保护机制来进行内存访问或时间行为。AUTOSAR OS还适用于小型和性能较低的微控制器，但同时也支持多核使用以及对代码和数据使用多个内存分区。
服务模块与操作系统及硬件无关。这些系统服务可通过RTE用于应用程序，应用程序无法直接访问底层的基本软件模块。这是保留给服务使用的，以作为其功能的一部分访问ECU或微控制器资源。服务模块及其底层模块也称为功能堆栈，例如FlexRay的通信堆栈。有时将这样的堆栈实现和集成为一个大型软件单元，而没有底层模块结构。
服务层包括系统服务，例如通信服务，诊断协议，存储服务，ECU操作模式的管理以及作为独立模块的AUTOSAR操作系统（OS）。AUTOSAR OS基于实时系统标准OSEK / VDX，并且在某些领域得到了扩展，但在其他领域也受到限制。它是静态配置和缩放的，并提供基于优先级的实时行为和中断处理。在运行期间，可以使用各种保护机制来进行内存访问或时间行为。
AUTOSAR OS还适用于小型和性能较低的微控制器，但同时也支持多核使用以及对代码和数据使用多个内存分区。服务模块与操作系统无关，与硬件无关。这些系统服务可通过RTE用于应用程序。应用程序无法直接访问底层的基本软件模块。
这是保留给服务使用的，以作为其功能的一部分访问ECU或微控制器资源。服务模块及其底层模块也称为功能堆栈，例如FlexRay的通信堆栈。有时将此类堆栈实现和集成为一个大型软件单元，而没有AUTOSAR定义的基础模块结构。尽管这破坏了抽象原理并降低了灵活性，但由于可能实现更高的效率和性能，因此在AUTOSAR中使用功能堆栈进行处理已很普遍。
小结
AUTOSAR成功的决定性原因是伙伴关系的基本原则，截至2014年10月，已有180多家伙伴公司形成了合作标准化和实施竞争。因此，AUTOSAR伙伴关系的主要结果是在其标准及其实施的自由过程中实施竞争的约束。AUTOSAR引入的另一个基本变化是用户的范式转变，从实现软件转向配置和生成软件。这样就可以通过AUTOSAR系统描述中的适当工具在软件中快速实施，从而在电子控制软件的开发中达到无与伦比的抽象度。这种抽象水平以及特定硬件的独立性使软件重用达到了新的水平，并使人们能够集中精力开发创新的客户功能，这些功能目前主要出现在自动驾驶系统领域。
免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删
155-2731-8020
