全面掌握AUTOSAR教程:从基础到应用

本文还有配套的精品资源,点击获取 menu-r.4af5f7ec.gif

简介:《AUTOSAR教程-雪云飞星》是一份详细介绍AUTOSAR(汽车开放系统架构)的教程资源,覆盖了汽车软件开发的关键技术框架。教程深入解析了AUTOSAR的基础软件(BSW)、虚拟功能总线(VFB)、软件组件(SWC)、运行时环境(RTE)、配置工具(ARTE)以及适应性平台等核心概念,强调了它们如何协同工作以及在车辆电子系统中的实际应用。教程适用于具备嵌入式系统和软件工程知识,以及熟悉汽车电子系统架构的学习者,旨在提供理论知识与实践操作相结合的学习经验。 AUTOSAR教程-雪云飞星.zip

1. AUTOSAR基础知识与架构概览

在现代汽车电子系统中,AUTOSAR(汽车开放系统架构)已经成为了业界的标准。本章节我们将探索AUTOSAR的基础知识和整体架构,为深入理解后续章节打下坚实的基础。

1.1 AUTOSAR的起源与发展

AUTOSAR由几家主要汽车制造商和供应商于2003年发起成立,旨在制定和推广汽车软件架构的开放标准。通过标准化,它旨在减少复杂性、增强软件模块的可重用性,并提高软件开发的效率。

1.2 标准化架构的核心组件

AUTOSAR的标准化架构可以分为三个主要层次: - 应用层(Application Layer) - 运行时环境(Runtime Environment,RTE) - 基础软件(Basic Software,BSW)

1.3 架构中的关键概念

  • 虚拟功能总线(Virtual Functional Bus,VFB) : 一个软件层,负责抽象化和隔离应用软件和基础软件。
  • 软件组件(Software Components,SWC) : 可复用的软件单元,它们通过VFB进行通信。
  • 运行时环境(Runtime Environment,RTE) : 位于应用层与BSW之间,它确保了SWC之间的实时通信和数据交换。
  • 基础软件(Basic Software,BSW) : 由多个模块组成,负责与硬件接口和上层软件之间的通信。

通过这些核心组件和概念,AUTOSAR架构实现了软件模块的模块化与分层化,为汽车软件的开发和维护提供了坚实基础。在接下来的章节中,我们将深入探讨这些组件和概念的详细内容,以及如何在实践中应用它们。

2. 基础软件(BSW)的构成与作用

2.1 BSW的模块化设计

2.1.1 BSW模块的功能划分

基础软件(BSW)是AUTOSAR架构的核心组成部分之一,它位于ECU软件的最底层,提供了与硬件交互的接口以及与上层软件(如SW-C)交互的接口。BSW的模块化设计允许它被细分成多个模块,每个模块都有特定的功能和职责。

  • 驱动层(驱动程序) :驱动层直接与硬件打交道,负责硬件资源的访问,如内存、中断、定时器、总线接口等。
  • 通信层 :负责实现车辆内部不同ECU之间的通信,支持包括CAN、LIN、MOST和FlexRay等多种网络协议。
  • 复杂驱动层 :复杂驱动层管理的是那些比传统驱动程序更复杂的硬件接口,比如ADC、DAC、PWM等。
  • ECU抽象层(EAL) :抽象和简化ECU的硬件,为上层软件提供统一的接口,隐藏了硬件的差异性。

模块化的优点在于其高度的可配置性与可扩展性,允许开发者针对不同的硬件平台和需求进行选择和组合,同时也有助于在不同项目之间的复用。

2.1.2 模块间的交互与协同

BSW模块之间通过定义良好的接口进行交互和协同工作。这种协作确保了整个软件的稳定性,同时也提供了一定程度的灵活性。例如,一个消息如果是通过CAN总线发送的,那么通信管理模块(COM)就需要与CAN驱动层进行交互,以确保消息的正确发送与接收。

为了达到这种协作,BSW模块之间使用了一套统一的消息和信号处理机制。它包括了运行时环境(RTE)的角色,其作用是负责在BSW模块和SW-C之间以及BSW模块之间进行通信和数据交换。

2.2 BSW在系统中的位置与作用

2.2.1 BSW与应用层的交互

BSW与应用层(SW-C)之间的交互非常关键。BSW提供一系列的服务来支持SW-C的运行,这些服务包括但不限于任务调度、中断处理、诊断服务和时间管理。BSW模块的这些功能为上层应用提供了稳定而可靠的运行环境。

例如,BSW中的任务管理模块负责调度和管理SW-C中的软件任务,它确保任务按照预定的优先级和时间要求执行。RTE作为BSW与SW-C之间的桥梁,负责封装BSW提供的服务,以便SW-C能够以统一的方式访问它们。

2.2.2 BSW对硬件的抽象与管理

BSW的关键作用之一是对硬件的抽象。这意味着软件开发者可以不必关心底层硬件的具体实现,而是通过BSW提供的标准化接口来访问硬件资源。这大大简化了软件的开发工作,并且提高了代码的可移植性。

ECU抽象层(EAL)是这一功能的关键实现者。EAL为不同的硬件平台定义了一组统一的API,保证了软件的可移植性。例如,不管底层硬件是使用哪种微控制器,EAL可以保证对内存、输入输出接口等硬件资源的访问方式是一致的。

2.3 BSW的配置与优化

2.3.1 BSW模块的配置方法

BSW模块的配置通常通过专门的配置工具来完成,这些工具根据预设的参数和需求生成配置代码和数据。BSW模块的配置过程是将BSW模块参数化的过程,以适应不同的硬件和软件需求。配置工具如AUTOSAR ARTE(AUTOSAR Run Time Environment)为开发者提供了一个图形化的界面,通过这个界面开发者可以轻松地选择需要的BSW模块,设置参数,并生成相应的配置文件。

配置过程通常包括选择BSW模块、定义模块间的通信和接口参数、配置模块的启动行为等。每个模块都有其配置参数,这些参数由AUTOSAR标准定义,并通过工具进行管理。例如,通信模块(COM)配置包括定义通信堆栈参数、设置通信周期和消息缓冲区大小等。

2.3.2 性能优化与故障排除

配置BSW不仅仅是设置参数,还包括了优化BSW以满足性能要求和诊断故障。性能优化可能涉及调整任务调度策略、中断处理机制和通信协议参数等。BSW的配置决定了其对资源的使用,比如CPU和内存的占用,以及对延迟和吞吐量的影响。

故障排除是BSW配置中不可或缺的一部分。开发者需要通过日志和诊断服务来监视BSW的运行情况,并根据需要进行调整。在某些情况下,可能需要结合专业的调试工具来分析和解决问题。

在进行性能优化和故障排除时,开发者必须理解BSW模块的工作原理以及它们是如何与系统中的其他部分协同工作的。例如,一个通信模块的性能问题可能是由于数据传输速率设置不当,或者是因为没有正确配置优先级和调度策略。

通过本章节的介绍,我们了解了基础软件(BSW)在AUTOSAR架构中的关键作用以及其模块化设计。接下来将深入探讨BSW模块的配置与优化策略,以及它在系统中的位置和作用。

3. 虚拟功能总线(VFB)概念与标准化通信

虚拟功能总线(VFB)是AUTOSAR架构中用于标准化通信的关键组件,它在软件组件(SWC)和基础软件(BSW)层之间架起了一座桥梁。VFB在现代汽车电子架构中的重要性不容小觑,它不仅促进了模块间的解耦,还提供了一种高效、灵活的方式来实现软件之间的通信。

3.1 VFB的定义与设计原则

3.1.1 VFB的基本概念

VFB是一种软件架构设计概念,它允许软件组件在不直接依赖于特定硬件的情况下进行通信。这种设计方法有助于软件重用,并提高了系统的可维护性。VFB的作用可以类比于现实世界中的公交系统,它规定了运行在不同路线上(相当于不同的ECU上)的车辆(相当于不同的软件组件)必须遵循的标准,以确保能够顺畅地在车站(相当于不同软件组件之间的通信点)进行乘客(相当于数据)交换。

3.1.2 VFB的设计目标与优势

VFB的设计目标是实现软件组件之间的解耦以及支持分布式系统的设计。它为开发人员提供了一组定义明确的接口和协议,使得软件组件能够独立于特定的硬件平台和底层通信机制来设计和测试。VFB的优势在于:

  • 可扩展性 :可以容易地增加或修改软件组件而不影响整个系统。
  • 兼容性 :通过标准化接口,不同的软件组件可以来自不同的供应商,并确保它们能够正确地工作在一起。
  • 维护性 :更改和升级系统中的特定部分可以局部进行,不必重新设计整个系统。

3.2 标准化通信机制

3.2.1 VFB通信模型

VFB通信模型采用了发布-订阅机制,这一机制允许软件组件发布消息而不必直接与接收者通信,接收者订阅消息并接收它们。这种模式支持了一对多和多对多的通信模式,大大增加了设计的灵活性。在AUTOSAR中,VFB模型被进一步具体化为“运行时环境(RTE)”,它负责具体实现VFB概念。

3.2.2 VFB中的服务与接口

在VFB模型中,服务和接口是通信的基础。服务定义了一组可供其他组件调用的操作,而接口则是这些操作的访问点。AUTOSAR定义了多种标准服务,例如诊断服务、时间管理服务等,它们提供了软件组件间通信和交互的基本规则。接口则规定了消息的格式、大小和传输方式,确保了通信的一致性和可靠性。

3.3 VFB的实现与应用案例

3.3.1 VFB在车辆网络中的实现

实现VFB通常需要考虑网络拓扑、通信协议和消息缓冲等问题。在网络层,VFB依赖于多种通信协议,例如CAN、FlexRay或以太网,以适应不同的通信需求和性能要求。在实现时,软件工程师会利用AUTOSAR提供的工具链来定义消息和配置网络参数,确保不同组件间通信的流畅和高效。

3.3.2 VFB案例分析与经验分享

在具体的案例中,VFB已被广泛应用于多个现代汽车项目中,尤其是在需要高度集成的领域,如主动安全系统、动力总成控制等。通过采用VFB,汽车制造商能够更加灵活地更新和迭代软件,同时保持系统的稳定性和性能。

例如,在一个动力总成控制单元的案例中,软件工程师利用VFB来管理发动机控制单元(ECU)与传动系统ECU之间的通信。通过明确定义的接口和服务,两个ECU能够无缝交换数据,如扭矩请求和实际值,从而协调整个动力系统的运作。

3.3.3 VFB的性能考量

在实现VFB时,性能考量是不可忽视的因素。数据的传输延迟、带宽的合理使用以及实时性要求都是设计VFB时需要考虑的问题。通过合适的消息缓冲机制和优化的调度策略,可以保证数据实时地传输到目标组件,而不产生过多的延迟。

下面是一个VFB通信模型的Mermaid流程图,用来展示VFB中的消息发布与订阅流程:

graph LR
    A[软件组件A] -->|发布消息| B[运行时环境(RTE)]
    C[软件组件B] -->|订阅消息| B
    D[软件组件C] -->|订阅消息| B
    B -->|转发消息| C
    B -->|转发消息| D

在实际应用中,软件组件A会将消息发布给RTE,然后RTE根据B和C组件的订阅情况,将消息转发给它们。这种方式允许软件组件之间通过标准化的通信接口交互,而不关心其他组件的具体实现细节。

从代码层面,我们可以用伪代码展示VFB中软件组件发布和订阅消息的逻辑:

// 伪代码展示软件组件发布消息
void publishMessage( Message msg ) {
    // 将消息发布到VFB/ RTE
    rte_publish( msg );
}

// 伪代码展示软件组件订阅消息
void subscribeMessage( Message msg ) {
    // 订阅来自VFB/RTE的消息
    rte_subscribe( msg );
}

// RTE消息发布逻辑
void rte_publish( Message msg ) {
    // 根据消息类型和订阅者,将消息分发给合适的软件组件
    // ...
}

// RTE消息订阅逻辑
void rte_subscribe( Message msg ) {
    // 存储订阅信息,用于后续的消息分发
    // ...
}

以上伪代码展示了软件组件和RTE之间进行消息发布和订阅的基本逻辑。具体实现时,会有更复杂的逻辑来处理消息的过滤、缓冲和传输等。

通过VFB的标准化通信机制,AUTOSAR提供了一个灵活、高效、可扩展的平台,以应对汽车电子系统不断变化的需求。随着汽车电子技术的发展,VFB将继续扮演着至关重要的角色。

4. 软件组件(SWC)的可重用性与独立性

随着软件开发过程趋向于敏捷和模块化,软件组件(SWC)的概念在软件工程中变得越来越重要。SWC的可重用性与独立性不仅能够提高软件开发的效率,而且还能确保代码质量,减少维护成本。在AUTOSAR标准中,软件组件的设计原则和特性、配置与集成,以及性能优化与测试,是确保软件组件高效运作的关键因素。

4.1 SWC的设计原则与特性

4.1.1 SWC的模块化与可重用性

模块化是软件工程中的一个核心概念,指的是将一个复杂的系统分解为模块的过程。每个模块都负责一个子功能,而模块之间的相互作用则通过定义良好的接口来管理。在SWC的设计中,模块化通过以下方式实现可重用性:

  • 封装 :将数据和函数结合到一个单元(组件)中,以防止外部干扰和误用。
  • 接口定义 :清晰定义输入和输出接口,确保模块之间能够独立于实现细节进行通信。
  • 抽象层 :通过抽象层,隐藏内部实现细节,仅展示需要交互的功能点。

模块化的SWC可以轻松地被其他项目或在不同版本的应用中重用,显著提高了开发效率和软件的可维护性。

4.1.2 SWC的独立性与封装性

独立性是确保软件组件能够单独开发、测试和维护的关键。SWC的独立性主要体现在以下几个方面:

  • 模块独立性 :模块间的耦合度低,更改一个模块不会影响其他模块。
  • 版本独立性 :软件组件可以独立于其他组件升级和发布。
  • 技术独立性 :组件可以被复用在不同的技术栈和平台上,只要它们的接口保持一致。

封装性是确保SWC内部数据和逻辑不被外部访问和修改的机制,从而保护组件的内部状态,这可以通过访问控制来实现,例如公开接口函数,隐藏内部变量。

4.2 SWC的配置与集成

4.2.1 SWC的配置工具与方法

SWC的配置是确保组件能够适应不同应用场景的关键步骤。配置工具可以是简单的文本编辑器,也可以是集成开发环境(IDE)中的图形化工具。配置方法通常包括以下几种:

  • 手动配置 :直接编辑配置文件或XML描述文件,适用于配置不复杂的情况。
  • 图形化配置 :使用软件提供的图形界面配置工具,减少配置错误,提高效率。
  • 生成器工具 :使用自动代码生成器,根据预定义的规则和模板来创建配置。

在配置SWC时,通常需要指定内存大小、定时周期、同步机制等参数。

4.2.2 SWC的集成流程与步骤

软件组件的集成是指将配置好的SWC插入到更大的系统环境中,确保其正常运行的过程。SWC的集成步骤可以分为以下几个阶段:

  1. 静态集成 :在不运行程序的情况下,进行接口的匹配和兼容性检查。
  2. 动态集成 :在运行时,检查组件之间的交互逻辑和数据流是否符合预期。
  3. 功能测试 :确保集成的组件能够正常完成既定的功能。
  4. 性能测试 :评估集成后系统的性能是否满足要求。

在集成过程中,需要特别注意不同组件之间的依赖关系和冲突解决策略。

4.3 SWC的性能优化与测试

4.3.1 SWC的性能测试方法

性能测试是确保软件组件满足性能指标的重要手段。测试通常包括以下几个方面:

  • 响应时间 :组件处理请求所需的时间。
  • 吞吐量 :单位时间内的处理能力。
  • 资源消耗 :内存、CPU等资源的使用情况。
  • 稳定性 :长时间运行下的性能稳定性。

性能测试可以采用压力测试、负载测试、稳定性测试等方法。对于实时系统,还应该特别关注实时性指标。

4.3.2 SWC的优化策略与实例

SWC的性能优化包括代码优化、算法优化和系统架构优化等。优化策略可以基于以下方法:

  • 代码层面 :减少循环、优化分支逻辑、使用高效的数据结构。
  • 设计层面 :采用多线程或异步处理来提高并发性能。
  • 资源管理 :合理分配和管理内存、CPU等资源。

性能优化实例可能包括针对特定功能进行算法改进,或者在多核处理器上分配任务以利用并行计算优势。

// 代码示例:使用C语言优化排序算法
void quicksort(int *arr, int low, int high) {
    if (low < high) {
        int pivot = arr[high]; // 选择基准元素
        int i = low - 1;
        for (int j = low; j < high; j++) {
            if (arr[j] < pivot) {
                i++;
                // 交换两个元素的位置
                int temp = arr[i];
                arr[i] = arr[j];
                arr[j] = temp;
            }
        }
        // 将基准元素放到正确的位置
        int temp = arr[i + 1];
        arr[i + 1] = arr[high];
        arr[high] = temp;
        int pi = i + 1;
        quicksort(arr, low, pi - 1); // 对基准左边的元素进行快速排序
        quicksort(arr, pi + 1, high); // 对基准右边的元素进行快速排序
    }
}

在上述代码示例中,展示了快速排序算法的一个基本实现。对于性能优化,考虑减少函数调用、使用尾递归优化等方法。

通过对软件组件进行深入分析,我们能够理解其设计原则和特性对整体系统性能和可维护性的重要性。在实际操作中,正确配置和集成软件组件,以及有效地优化和测试,都是确保最终产品高质量和高可靠性的关键步骤。随着软件开发实践的不断进化,软件组件在现代软件系统中的作用将会越来越大。

5. 运行时环境(RTE)的映射与通信机制

5.1 RTE的作用与结构

5.1.1 RTE的定义与功能

运行时环境(RTE)是AUTOSAR架构中的核心组成部分,它提供了一个软件执行环境,使软件组件(SWCs)能够在ECU上运行并与其他软件组件和基础软件(BSW)进行通信。RTE的基本职能是确保数据和调用在不同软件组件之间安全、高效地传输,同时对上层的SWCs隐藏底层BSW的复杂性。

RTE的主要功能包括:

  • 通信管理 :管理SWC之间的交互,并确保正确的数据传输。
  • 抽象化 :向SWCs提供统一的接口,以隐藏不同BSW模块的实现细节。
  • 配置管理 :RTE根据配置数据管理整个系统的运行时行为。
  • 错误处理 :提供错误检测和处理机制,增强系统的鲁棒性。

5.1.2 RTE的架构与组件

RTE的架构是分层设计的,由不同的组件构成,每一层服务于特定的功能需求。主要组件包括:

  • RTE接口 :定义了软件组件和RTE之间的交互方式。
  • RTE内核 :核心部分,管理数据交换和调用,是RTE的核心执行环境。
  • RTE生成器 :根据配置数据生成RTE代码。

RTE架构的设计使其能够为SWC提供一致的执行环境,同时允许开发者集中处理BSW的配置和RTE的生成,这大大简化了开发过程。

5.2 RTE的映射机制

5.2.1 映射过程与原理

映射过程是RTE生成的关键部分,它将软件组件与基础软件相关联。映射过程中,SWCs被赋予适当的BSW模块以满足其通信需求。映射原理可以分解为以下几个步骤:

  1. 接口匹配 :确定SWC所需数据接口与BSW提供的接口是否匹配。
  2. 通信路径配置 :根据数据流和调用需求配置通信路径。
  3. 参数实例化 :将配置数据中的参数实例化,使其在运行时可用。
  4. 映射验证 :验证映射是否正确,确保没有遗漏或错误。

5.2.2 映射中的参数管理与优化

映射过程中,参数管理是确保系统正确运行的另一关键方面。通过优化参数设置,可以在保持性能的同时减少系统资源的使用。

优化参数管理的方法包括:

  • 参数分组 :将参数按照使用频率和重要性分组,以优化访问和存储。
  • 缓存策略 :实现适当的缓存策略以减少对硬件的访问次数。
  • 动态更新 :支持参数的动态更新,以便于实时系统调整。

5.3 RTE的通信机制与故障处理

5.3.1 RTE中的通信机制

RTE中的通信机制主要包括以下几种方式:

  • 信号传递 :通过信号传递数据,这是最为常见的通信方式,用于实现周期性或事件触发的数据交换。
  • 服务接口 :提供服务调用接口,允许软件组件请求BSW服务。
  • 远程过程调用(RPC) :用于SWC之间或SWC与BSW模块之间的非周期性、异步通信。

5.3.2 RTE故障诊断与恢复策略

RTE的故障处理机制包含:

  • 故障检测 :利用诊断服务监测系统运行状态,实时发现故障。
  • 故障隔离 :一旦发现故障,将其限制在最小影响范围内,避免故障蔓延。
  • 恢复策略 :实现故障恢复程序,比如重置通信通道,或者执行降级服务。

为了提高系统可靠性,RTE中的故障处理通常与车辆的诊断系统紧密集成,能够将故障信息传输给诊断工具,为维修和故障排除提供支持。

graph TD
A[SWC层] -->|通信信号| B[数据接口层]
B --> C{映射过程}
C -->|通信路径配置| D[通信路径层]
D --> E[BSW层]
E -->|服务请求| F[服务接口层]
F --> G[RTE内核]
G -->|运行时管理| H[ECU硬件]
H -->|诊断信息| I[故障处理]
I --> J[恢复策略]
J -->|维修信息| K[诊断系统]

通过以上章节,我们可以看出,RTE的实现不仅关系到各个软件组件之间的有效通信,还涉及到了数据的准确传递、配置管理以及故障的诊断和恢复。确保这些关键要素的协调工作是实现可靠、高效车载系统的关键所在。在实际开发中,深入理解RTE的运作机制,能够帮助开发者更好地进行系统设计和优化。

6. 配置工具(ARTE)的应用与管理

配置工具(ARTE)是AUTOSAR标准的一个重要组成部分,它为系统设计人员提供了一套完整的界面和功能,以简化配置流程、保证设计与标准的一致性,并加速开发过程。本章节将详细介绍ARTE的界面与功能、它在系统设计中的应用,以及如何通过高级配置和优化来提升系统性能。

6.1 ARTE的界面与功能

6.1.1 ARTE的用户界面介绍

ARTE工具的用户界面设计以直观和高效著称,目的是为了让使用者能够轻松地进行各种配置操作。界面通常包括项目浏览器、属性编辑器、图形视图和诊断视图等模块。项目浏览器用于展示系统结构、软件组件和配置项;属性编辑器用于修改选中元素的属性;图形视图提供了图形化的配置视图,方便用户理解各组件之间的关系;诊断视图则用于展示和分析配置过程中可能出现的错误和警告信息。

6.1.2 ARTE的主要功能与操作

ARTE提供了丰富的功能,以支持整个软件的配置过程。这些功能包括但不限于:

  • 配置数据库管理 :支持创建和管理配置数据库,允许版本控制和备份。
  • 模块化配置 :用户可以针对不同的模块或软件组件进行独立配置。
  • 参数化设计 :通过参数化,用户可以定义和调整软件行为而不需改变代码。
  • 依赖性检查 :ARTE能够检测配置项之间的潜在依赖性问题。
  • 集成和验证 :ARTE支持与编译器、运行时环境等工具的集成,并提供验证机制来确保配置的正确性。

6.2 ARTE在系统设计中的应用

6.2.1 ARTE在设计阶段的作用

在系统设计阶段,ARTE扮演着不可或缺的角色。其主要作用包括:

  • 简化配置流程 :ARTE将复杂的配置过程抽象为直观的操作,减少了配置错误的发生。
  • 提升设计一致性 :通过标准化的配置流程,ARTE确保了设计遵循AUTOSAR标准,增强了产品的可移植性和互操作性。
  • 快速原型开发 :利用ARTE可以迅速搭建系统原型,并进行迭代测试。

6.2.2 ARTE与AUTOSAR标准的对接

要确保系统符合AUTOSAR标准,ARTE提供了多种机制来对接标准:

  • 标准模板 :ARTE内置了AUTOSAR标准的模板,方便用户根据标准创建项目。
  • 校验工具 :ARTE中的校验工具能够自动检查配置项是否符合AUTOSAR标准。
  • 文档生成 :ARTE支持生成符合AUTOSAR标准的配置文档,方便设计审核和项目交付。

6.3 ARTE的高级配置与优化

6.3.1 高级配置技巧

高级配置技巧允许用户针对特定需求,进行更为精细和个性化的系统配置:

  • 模板定制 :用户可以根据自己的需求定制和扩展内置模板。
  • 动态配置 :通过脚本或程序接口实现动态的配置,适用于批量处理或自动化测试。
  • 配置优化向导 :ARTE提供向导以指导用户进行性能优化和资源分配。

6.3.2 ARTE的性能优化与案例分析

性能优化是确保系统运行效率和稳定性的关键步骤。ARTE通过以下方式支持性能优化:

  • 资源使用分析 :通过ARTE可以分析软件组件对资源的使用情况,从而优化资源分配。
  • 性能测试集成 :ARTE可以集成性能测试工具,并提供测试结果分析。
  • 案例分析 :通过对典型案例进行分析,ARTE可以提供实际的配置优化经验。

通过本章节的内容,我们可以看到ARTE在AUTOSAR标准的配置和管理中扮演的重要角色,以及如何有效利用ARTE来提升配置的效率和系统的性能。

本文还有配套的精品资源,点击获取 menu-r.4af5f7ec.gif

简介:《AUTOSAR教程-雪云飞星》是一份详细介绍AUTOSAR(汽车开放系统架构)的教程资源,覆盖了汽车软件开发的关键技术框架。教程深入解析了AUTOSAR的基础软件(BSW)、虚拟功能总线(VFB)、软件组件(SWC)、运行时环境(RTE)、配置工具(ARTE)以及适应性平台等核心概念,强调了它们如何协同工作以及在车辆电子系统中的实际应用。教程适用于具备嵌入式系统和软件工程知识,以及熟悉汽车电子系统架构的学习者,旨在提供理论知识与实践操作相结合的学习经验。

本文还有配套的精品资源,点击获取 menu-r.4af5f7ec.gif

这里的NM主要是针对Can协议的网路管理。 AUTOSAR CanNM的核心思想主要归纳为以下两条: 1.  如果节点需要保持通信,则节点需要周期的发送NMPDUs,否则停止发送NMPDUs 2.     如果总线上的所有节点不需要使用总线,那么总线上过了一段时间没有NMPDUs时,则会进入Bus-Sleep Mode。   工作模式和状态   CanNm一共有三个工作模式 1.  Network Mode 2.  PrepareBus-Sleep Mode 3.  Bus-Sleep Mode 模式的改变应该通过回调函数通知上层。 下面单独说每种模式   (1)Network Mode Network Mode又包括三个内部状态 1. Repeat Message State 2. Normal Operation State 3. Ready Sleep State ①Repeat Message State 这个模式被用来确保从Bus-Sleep or Prepare Bus-Sleep到Network Mode的节点被总线上面其他节点发现。这个状态可以用来检测总线上的节点。 当进入Repeat Message State时,节点应该开始传送NMPDUs。 在Repeat Message State时,当NM-Timeout Timer溢出,CanNm模块应该重载Timer。 CanNm模块应该在Repeat Message State 下保持一段时间,这段时间可以通过CANNM_REPEAT_MESSAGE_TIME来进行配置。 当离开Repeat Message State的时候,如果节点需要通信,则进入Normal Operation State;如果节点不需要通信,则进入Ready Sleep State。并且清空Repeat Message Bit。   ②Normal Operation State 这个状态可以保持总线处于唤醒状态。从Ready sleep state进入这个状态的时候应该发送NMPDUs。 在Normal Operation State当NM-Timeout Timer溢出,CanNm模块应该重载Timer。 如果节点不需要使用通信,则网络应该被释放,节点应该进入Ready Sleep State。 如果节点接收到Repeat Message Request Bit,则节点进入Repeat Message State。如果节点自身需要进入Repeat Message State,则该节点进入Repeat Message State并且设置Repeat Message Request Bit。   ③ReadySleep State 这个状态是为了如果本节点已经准备释放总线,而其他节点还需要使用总线的时候,在这个状态下等待其他总线上的节点进入Perpere Bus-Sleep Mode。进入这个状态之后,CanNm模块应该停止NMPDUs的传送。 如果NM-Timeout Timer溢出,节点将会进入Prepare Bus-Sleep Mode。 如果该节点需要使用总线,则节点进入Nomal Operation State。 如果节点接收到Repeat Message Request Bit,则节点进入Repeat Message State。如果节点自身需要进入Repeat Message State,则该节点进入Repeat Message State并且设置Repeat Message Request Bit。 (2)PrepareBus-Sleep Mode   这个状态是为了等待总线上的所有节点能够在进入Bus-Sleep Mode之前,有时间停止节点的active状态如清空队列中为发送的报文。在Prepare Bus –Sleep Mode下,所有节点都静默下来。 当节点进入PrepareBus Mode时,应该通知上层应用。通过配置CANNM_WAIT_BUS_SLEEP_TIME参数,可以改变节点在PrepareBus-Sleep Mode停留的时间,在这段时间之后节点将会进入其他状态。 在Prepare Bus-Sleep Mode下面接收到NMPDU或者被上层应用请求通信时,节点将进入Network Mode中的Normal operation State。   (3)Bus-SleepMode   Bus-Sleep Mode的目的是当没有消息被传送的时候可以减少能量的消耗。在Bus-Sleep Mode下面,节点可以被唤醒(如本地唤醒源和CAN线唤醒源)。CANNM_TIMEOUT_TIME+CANNM_WAIT_BUS_SLEEP_TIME两个参数在整个总线上面的节点都应该时一样的配置,保证了总线上的节点能够统一的进行休眠。 当进入Bus-Sleep Mode时候,应该通知上层应用。 在Bus-Sleep Mode下,如果成功接收到NMPDU,CAN NM模块应该调用Nm_NetworkStartIndication。 如果CanNm_PassiveStartUp被调用,则CAN NM模块进入Network Mode 中的Repeat Message State。 ———————————————— 版权声明:本文为CSDN博主「cococenstar」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/cococenstar/article/details/84096689
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值