20、汽车片上系统软件开发环境解析-优快云博客

本文链接：https://blog.youkuaiyun.com/nginx7reverse/article/details/155146222

汽车片上系统软件开发环境解析

1. 引言

汽车电子系统的发展历程可谓是一部不断演进的历史。早在1960年，大众甲壳虫首次配备了电路；到1978年，梅赛德斯S系列为防抱死制动系统（ABS）配备了嵌入式系统。早期的汽车电子系统主要由电子控制单元（ECU）、传感器和执行器组成，这些系统自主运行，很少与其他系统共享数据。

然而，到了2010年代，豪华汽车配备并连接了近百个ECU。随着车辆功能的增加，汽车电子系统在整个生命周期（如开发、测试、生产和维护）变得极其复杂。

1.1 概述

早期，特定服务的ECU相互独立工作。但随着客户对各种复杂功能的需求，汽车电子系统需要更复杂的控制机制。如今，ECU通过网络连接成分布式控制系统，像自适应巡航控制（ACC）和自适应前照灯系统（AFLS）等复杂功能，就需要整个汽车领域的复杂分布式控制策略。

为了在ECU之间共享数据，早期采用直接连接的方式，但这种网络拓扑增加了布线成本，且灵活性受限，因为它依赖于ECU结构。因此，大多数分布式控制系统采用基于总线的网络，这种网络由智能传感器和智能执行器组成，它们有自己的网络接口，可独立连接到网络，确保了高度的灵活性和可扩展性。

不过，随着ECU、智能传感器和执行器数量的增加，分布式控制系统的设计、验证和确认变得更加复杂。同时，汽车环境中的安全和可靠性问题也至关重要，因为网络流量的增加可能导致拥塞、延迟和网络遗漏。为了解决这些问题，汽车行业广泛采用“分而治之”的方法，将汽车系统分为动力总成、底盘、车身和多媒体等子系统，每个子系统都有独立的网络，如底盘用FlexRay，车身用CAN，多媒体用MOST。网关可以解决集成异构网络的问题，但可能会影响性能。

模型驱动开发（MBD）是解决汽车软件开发问题的有效方法，它便于表示、模拟和生成自动代码。汽车开放软件架构（AUTOSAR）是汽车行业开发的一种MBD方法，是汽车电子系统开发的开放标准规范，它提供了软件模型、平台模型和系统模型。

1.2 软件环境的重要性

法律法规（如强制安全设备和废气排放）只能通过电子系统来实现。客户对功能和安全的需求不断增加，原始设备制造商（OEM）也希望推出具有创新功能的新车。汽车电子系统的软件技术可以在成本和开发之间找到良好的平衡。

在汽车电子系统中，需要考虑以下几个问题：
1. 法规、法律和客户的要求，如安全、经济、舒适和服务。
2. 随着功能增加，ECU和ECU网络的复杂性。
3. 异构ECU和ECU网络（如CAN、LIN、FlexRay、MOST等）的使用。

为了满足这些需求，需要一个复杂的分布式汽车系统。汽车功能是一种由ECU和ECU网络组成的分布式系统，但目前还没有用新技术进行结构化。对于某些功能，ECU被分组到几个子域中，如动力总成、车身舒适、底盘和信息娱乐。但ECU网络的接口在这些域之间甚至在同一域内都没有标准化，网络节点之间的相互关系和交互也没有被考虑。

传统的汽车功能开发策略是将功能需求逐个分配给ECU，且相互连接很少。但随着ECU互连的增加，整个过程（如开发、验证和确认）变得高度复杂和昂贵。非正式的开发过程和不合适的组件使问题更加复杂。直到2000年代，才提出合适的汽车软件架构抽象和集成概念。目前，许多先进的汽车功能分布在整个子域的多个ECU上，如高级驾驶员辅助系统（ADAS）就需要复杂而安全的ECU互连。

为了提供标准的汽车系统架构，OEM和一些供应商在2003年建立了合作伙伴关系，成立了AUTOSAR，其核心合作伙伴包括宝马集团、博世、大陆、戴姆勒、福特、通用、标致雪铁龙、西门子VDO、丰田和大众。

1.3 汽车系统的软件环境

开放系统及其汽车电子接口（OSEK）是嵌入式实时操作系统的开放标准，包括通信栈（COM）和网络管理（NM）。它由德国OEM和卡尔斯鲁厄大学在1993年开发，1994年法国汽车OEM加入，当时OSEK/VDX开始。OSEK在ISO 17356中标准化，AUTOSAR将其规范作为AUTOSAR OS，该操作系统具有OSEK OS、OSEKtime和OSEK COM等功能。

EAST - ADL是一种用于汽车电子系统的架构描述语言，旨在以更高的抽象级别补充AUTOSAR，涵盖车辆特征、功能、需求、可变性、软件组件、硬件组件和通信等方面，目前由EAST - ADL协会与欧洲FP7 MAENAD项目合作维护。

AUTOSAR于2003年开始第一阶段，到2006年底，第一批AUTOSAR产品上市。3年内，52个高级成员加入了AUTOSAR联盟并制定了主要规范，之后又增加了关联成员、开发成员和参与者。成员们认为AUTOSAR可以控制汽车电子系统的复杂性，提高产品质量和利润率。近年来，AUTOSAR举办了多次开放会议，2013年是其成立10周年，还将进行全球巡回活动。

1.4 AUTOSAR的目标

AUTOSAR的概念是实现软件组件的硬件无关性迁移和已开发软件组件的重用。其项目目标如下：
1. 软件的可移植性
2. 对不同车辆和平台变体的可扩展性
3. 不同的功能域
4. 定义开放架构
5. 可靠的系统
6. 自然资源的可持续利用
7. 各合作伙伴之间的协作
8. 汽车ECU基本软件功能的标准化
9. 适用汽车国际标准和先进技术

AUTOSAR的每次建模结果都会导出符合UML 2.0的AUTOSAR可扩展标记语言（AR - XML）。根据自上而下的方法，AUTOSAR从描述语言开始，其描述需要通过元模型级别逐步指定为具体的XML文件。

AUTOSAR在开发过程中的基本好处是应用软件开发组件的重用和迁移，而不受硬件和底层基本软件模块的影响。基于组件的方法需要AUTOSAR运行时环境（RTE）来实现虚拟功能总线（VFB）的概念，用于应用层和基本软件（BSW）之间的交互。应用程序在通信时不需要了解RTE下的具体实现和通信方法，应用程序开发人员只需了解接口，无需了解系统服务和资源的更多信息。

AUTOSAR联盟试图接受尽可能多的现有解决方案，并与新的和其他标准化组织合作，以接受他们的标准，如TTCAN、LIN、SAE J1939、FlexRay、MOST甚至以太网。因为在通信栈方面，一种标准可能只适用于特定情况，而汽车电子系统可以根据需求和特点同时使用多种通信标准。

2. AUTOSAR架构

为了克服传统开发过程的缺点，满足不同客户的各种需求，AUTOSAR提出了基于模型的汽车开放系统架构开发过程。软件架构、ECU硬件和网络拓扑通过软件组件和接口进行设计，这些用AR - XML描述，支持从设计到集成的AUTOSAR开发过程。AUTOSAR的建模元素基于对象管理组织（OMG）元对象设施的规则定义。

2.1 AUTOSAR概念

AUTOSAR开发过程的第一阶段是设计软件组件架构。AUTOSAR软件架构由软件组件和接口组成，软件组件的通信端口根据数据流方向分为提供端口和需求端口，提供端口只发送数据，需求端口只接收数据。

AUTOSAR提供两种广泛使用的基本通信模式接口：
1. 发送者/接收者接口 ：发送者将信息分发给一个或多个接收者，或一个接收者从多个发送者获取信息。这种接口用于异步数据分发，发送者不被阻塞，也不期望接收者响应，接收者自主决定何时以及如何使用数据。例如，道路速度传感器是发送者，仪表盘和门锁模块是接收者。
2. 客户端/服务器接口 ：服务器提供操作，多个客户端可以调用这些操作。每个操作有一个由名称和参数列表组成的签名，参数有名称、类型和方向。客户端调用请求并传递参数，服务器执行请求的服务并返回响应。AUTOSAR软件组件可以根据调用方向是客户端或服务器，甚至可以同时是两者。例如，门锁模块是服务器，遥控钥匙或中央门锁模块是客户端。

软件组件架构的设计与软件组件运行的技术架构（如ECU硬件和网络拓扑）无关。软件组件之间的通信可以是ECU内通信或ECU间通信，AUTOSAR RTE作为通信层，通过相同的接口和服务提供通信抽象，无论是通过CAN、LIN、FlexRay和MOST等ECU间通信，还是通过共享内存和消息队列等ECU内通信。由于软件组件的通信需求取决于应用程序，RTE需要定制以实现适当的通信，大部分RTE将根据可用的通信资源生成，部分可能通过配置定制，生成的RTE适用于特定的ECU，使软件组件与硬件实现细节分离。

硬件架构与软件组件架构分开设计，AUTOSAR旨在设计ECU网络的拓扑结构。根据定义的软件架构和网络拓扑，软件组件将被映射到特定的ECU。在AUTOSAR标准中，软件组件模板描述了支持AUTOSAR开发工具之间互操作性和合规性的要求。

下面是AUTOSAR软件组件通信流程的mermaid流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(软件组件):::process -->|提供端口| B(发送者/接收者接口):::process
    A -->|需求端口| B
    B -->|ECU内通信| C(RTE):::process
    B -->|ECU间通信| C
    C -->|通信抽象| D(其他软件组件):::process

汽车片上系统软件开发环境解析

2.2 基本软件（BSW）

目前，AUTOSAR标准中描述的BSW模块超过70个，并且随着标准的更新，模块数量可能会发生变化。例如，AUTOSAR标准4.0中支持多核微控制器的BSW模块，相较于之前仅支持单核的版本，需要描述更多的服务。

每个BSW模块都有明确的接口，用于与其他模块以及RTE进行通信。软件组件位于RTE之上，不能直接访问任何BSW接口，必须通过RTE进行交互。这些接口由应用程序编程接口（API）函数、数据类型以及API的返回代码组成。在BSW模块之间的通信中，主要使用三种类型的接口：AUTOSAR接口、标准AUTOSAR接口和标准接口。此外，AUTOSAR还为BSW模块定义了配置参数。其中，AUTOSAR接口用于定义软件组件之间的通信数据，它独立于特定的编程语言、ECU和网络，具有很强的通用性。

下面是BSW模块分层结构的mermaid流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(系统服务):::process --> B(内存服务):::process
    A --> C(通信服务):::process
    B --> D(内存硬件抽象):::process
    C --> E(通信硬件抽象):::process
    D --> F(微控制器驱动):::process
    E --> F
    F --> G(设备驱动):::process
    G --> H(复杂驱动):::process
    H --> I(ECU抽象组件):::process
    I --> J(RTE):::process

3. AUTOSAR在汽车片上系统开发中的应用案例

汽车片上系统（SoC）通常包含多个处理器、定制的汽车视觉系统视觉处理引擎以及外围设备。在AUTOSAR开发的汽车SoC案例中，需要将SoC的每个组件映射到AUTOSAR分层架构中，如微控制器抽象层（MCAL）、ECU抽象层和复杂驱动（CCD）。

具体的映射过程如下：
1. 确定组件功能 ：详细分析SoC中每个组件的功能和特点，例如处理器的计算能力、视觉处理引擎的图像处理功能以及外围设备的输入输出特性。
2. 选择合适的分层架构 ：根据组件的功能，选择与之匹配的AUTOSAR分层架构。例如，微控制器相关的功能映射到MCAL，而与ECU整体相关的功能映射到ECU抽象层。
3. 进行映射配置 ：通过配置工具，将组件准确地映射到相应的分层架构中，并设置相关的参数和接口。

在这个过程中，AUTOSAR的分层架构和标准化接口起到了关键作用。它使得不同组件之间的通信和协作更加高效，提高了系统的可维护性和可扩展性。同时，通过软件组件的重用和迁移，减少了开发时间和成本，提高了产品的质量和竞争力。

4. 总结与展望

随着汽车电子系统的不断发展，其复杂性也在日益增加。AUTOSAR作为一种基于模型的开发方法，为汽车软件开发提供了有效的解决方案。它通过标准化的软件架构、接口和开发流程，实现了软件组件的硬件无关性迁移和重用，降低了开发成本，提高了产品质量。

在未来，AUTOSAR有望在以下几个方面得到进一步发展：
1. 支持更多的硬件平台 ：随着汽车技术的不断进步，新的硬件平台不断涌现。AUTOSAR需要不断扩展，以支持更多类型的硬件，满足不同汽车厂商的需求。
2. 加强与其他技术的融合 ：如人工智能、大数据等技术在汽车领域的应用越来越广泛。AUTOSAR可以与这些技术进行融合，为汽车提供更智能、更安全的功能。
3. 提高系统的安全性和可靠性 ：汽车作为人们生活中重要的交通工具，其安全性和可靠性至关重要。AUTOSAR需要进一步加强安全机制的设计，确保系统在各种复杂环境下的稳定运行。

总之，AUTOSAR在汽车软件开发领域具有广阔的应用前景，将为汽车行业的发展带来新的机遇和挑战。