Autosar CAN开发09(使用Vector工具(Configurator、Developer)变更报文(新增报文、删除报文、新增信号删除信号------应用报文))

首先,先简单描述一下使用Vector工具包变更CAN应用报文、信号的整个流程(网管报文、诊断报文是另外的配置方法)。

        1、在DBC里面添加CAN报文信号(填好报文、信号的各种参数,报文属性等)

        2、使用Configurator软件打开代码配置工程,把DBC导入至Configurator中,配置好Can、CanIf、PDUR、COM等模块

        3、使用Developer软件打开代码配置工程(与Configurator软件打开的是同一份代码配置工程,),因为第2步已经操作完成,因此打开Developer软件后,可以看到对应在DBC里面新增的报文信号了,接下来就是Mapping报文信号,也就是将报文信号映射到应用层架构的各个模块里面,供应用层使用。

        具体开发流程操作如下:

另外:本篇文章讲的是Vector工具包信号开发的配置流程,对于具体的各个参数配置项不做深入讲解(这些也讲的话,涉及太多太多了)。       

步骤1:在DBC中进行报文、信号变更

        DBC的操作如果不懂看我前面的一篇文章就可以了。

Autosar BSW层CAN通讯开发------01(DBC)_嵌软小白呗的博客-优快云博客_autosar bsw开发icon-default.png?t=N7T8https://blog.youkuaiyun.com/qq_41848098/article/details/122029487       在DBC中添加报文时,要注意报文的属性(Attribute),在Attribute界面配置好对应报文的属性,不同的报文属性不一样。应用报文、网管报文、诊断报文,都有对应属性,这样在把DBC导入Configurator软件时软件才能识别出对应的报文。

9b2acd76ecd14a96816dda7d3b1ccedd.png

        另外需要注意的是,你需要变更的报文、信号需要添加到DBC中的一个节点里面去,导入DBC至Configurator之后,需要你选择对应的节点导入,并且只能选择一个节点。也就是说,代码里面的所有发送和接收报文都需要添加到DBC的一个节点里面。如下图OBC节点:

12f5d537e4964564be053559bbb7f510.png

        另外提一嘴。

        操作过DBC的人都知道,在DBC里面添加报文和信号非常浪费实际,添加一两个报文或者信号还好。但在实际的工作过程中,需要添加的信号量非常大,操作起来非常费时间。所以一般企业都会有工具通过Excel表等方式直接转成DBC。(比如我们公司,我进去的时候居然没有这种工具,弄了几次我受不了了,我TM当场把Python给学了,弄了个Excel转DBC工具)

步骤2:导入DBC至Configurator

        打开Configurator之后,点击InputFile,即可导入DBC

        

        导入DBC后,在ECU Instance处选择DBC里面的节点,这也就是上面所说的,要在一个节点里面变更报文信号,其它节点的报文信号,Configurator工程是不理会的。0111a25f05324f5a91e94c8a1b1b2164.png

        添加DBC后,需要Update工程,如下图:

        ab94bd4f95e24b5b97fdb0bfdb68dcae.png

       ( 注意:若是DBC的报文、信号有变更,一定要点击Complete Update,否则在Developer软件进行报文信号映射(Mapping)的时候,同一个信号组的信号会以数组的形式存在。正常情况,同一个信号组的信号我们都是希望它以结构体的形式供应用层使用。关于这一点,如果看不懂的话可以不理会,上手开发之后,在开发过程中慢慢就理解了)

步骤3:配置Configurator中所变更报文信号的各个模块的相关属性

        配置之前,先看下Container这个东西,(所谓Container,就是下图所示的一个个像容器的东西,配置的东西都在这些容器里面)

        

045cd06cf3264e83909856f282397099.png

1、CAN模块:

CAN控制器(CanController):        

当填加一个新的DBC之后,Configurator中会在CAN模块生成新的一路CAN控制器,因为一个节点必须要一路CAN通道。如下图所示,这个工程就有2路CAN通道 ,工程里面共添加了2个DBC

    122d27e324474ae9a651e9f7d1d70c48.png

        至于CAN控制器的各个参数配置,涉及的东西都是关于CAN控制器的,内容较多,我另外会用一篇文章去讲解。

CAN邮箱(CanHardwareObject):

        新增个DBC文件后,除了会生成一路CAN控制器,另外还会在CanHardwareObject里面自动生成两个邮箱(一个TX,一个RX),如下图所示:

        cc4e7b5132124b98a56046e5d27c27bb.png

        关于CAN邮箱,类型有Full-can和Basic-can,简单来说:就是配置成Full-can,那么一个邮箱只能存一个ID的报文。配置成Basic-can,那么一个邮箱就能存放多个不同ID的报文。

2、CANIF模块:

       在导入DBC后,CANIF会根据所导入的DBC生成相应的报文Container(容器)。Vector软件会自动将CANIF模块的报文与CAN模块中的CAN控制器和邮箱索引起来(在上面CAN模块中有说,导入DBC会自动在CAN模块生成对应的CAN控制器和邮箱,所以,该DBC中的报文也会自动索引到对应的CAN控制器和邮箱中。当有多个DBC和多路的CAN控制器时,CAN报文自然不会索引到错误的CAN控制和邮箱了)

        CANIF模块的接收报文如图所示:(包含应用报文、NM报文、诊断报文、烧录报文等) 

6a17a75a88f040f78b6a9526bd9e2fd1.png

        CANIF模块的发送报文如图所示:(包含应用报文、NM报文、诊断报文、烧录报文等) 

fc20072bf51744bd90e6a105c9f273a4.png

        在CANIF模块中,可以配置各帧CAN报文的类型,可以配置为CAN格式、CANFD格式,扩展帧格式等(实际上在DBC配好后,这些会根据DBC自动帮你配好)

3、PDUR模块:

        导入DBC后,Pdur模块也会自动生成DBC节点中的报文。这个模块通常配置的项比较少。

dcccda9eaaa84322ba9998b6ef88aae7.png

4、COM模块:

         4cc397f908b94bf19530bc1e5cb6f18b.png

         在该模块可以配置报文的周期、报文发送的偏置时间、事件型报文触发后的发送次数,配置界面如下(通常这些参数也是在DBC里面直接配好了):

28f90bed1f094f97b30b884910177d22.png


当把这上述四个模块配置好后,应用报文的底层配置基本是没什么问题,然后可以生成COM(Communication)代码了,界面如下图所示:

        

571ef4919ed04edcbd49ff0fd03e8897.png

        若所配置的工程没有问题,生成代码应当是全部通过。

451aeba072a04f16a8853dccfac6236a.png


        底层Configurator弄好后,接下来就是使用Developer软件把报文信号Mapping(映射)到应用层中去了。

          Developer中,报文数据Mapping界面如下:

bbbcbc146faa40a4a9f0e81fa40d4f23.png

        Mapping完成后,就是使用模型把各个报文信号连到应用层各个模块中去了,界面如下:

        ac9af99513da48f884469199f447e618.png

        完成Develoer的操作后,若是操作无误,则可在Configurator中生成RTE和OS文件了,界面如下:

        


         使用Vector工具链开发应用报文的整个流程就是这些了。但实际上开发起来的细节是非常多的,对于新手来说不太友好。

        我是通信工程师,因此在这整个开发流程中,我实际上只用开发Configurator部分。因为对于各个报文信号在哪里写、在哪里读是由应用层决定的,因此Developer部分是由应用层同事开发,他们把报文信号Mapping至对应的模块直接使用就可以了。

        事实上,开发流程熟悉后其实不难。主要还是出现问题后如何去查,该怎么查,这就要求对代码和架构比较熟悉了。比如开发完之后,发现被你开发过,工程跑起来连报文都发不出,这可咋整。我刚开发的时候就出现过这样的问题,后面查代码才发现是收发器没有跟CANIF层索引起来,然后再Configurator里面配一下就好了。


 返回目录:

Autosar BSW 开发笔记(目录)-优快云博客

<think>好的,用户现在作为一个汽车软件工程师,已经对AUTOSAR有了基本了解,现在想深入探讨Classic AUTOSAR。我需要先回顾之前的对话,确保这次的回答与之前的介绍衔接上。之前已经提到过Classic和Adaptive的区别,所以这次需要更详细地展开Classic部分。 用户身份是汽车软件工程师,可能已经具备一定的行业知识,所以需要深入技术细节,但也要避免过于晦涩。需要确定用户的具体需求,比如是否想了解架构、开发流程、工具链,或者实际应用中的问题。用户没有明确说明,所以应该覆盖主要方面,包括架构、组件、通信机制、开发工具、实际应用案例等。 考虑到用户可能需要实际操作的指导,可能需要提到工具链,比如Vector工具,ETAS的ISOLAR,以及开发中的配置流程。同时,ECU开发流程中的V模型、集成阶段的问题也可能相关。此外,用户可能对如何入门学习Classic AUTOSAR感兴趣,可以推荐学习资源或标准文档。 需要结构化回答,分点清晰,便于理解。可能分为核心概念、架构分层、通信机制、开发流程、工具链、挑战与解决方案、学习资源等部分。要确保术语准确,例如RTE、BSW、MCAL、SWC等,必要时给出英文全称和解释。 还要注意用户可能的实际应用场景,比如在开发ECU时如何应用Classic AUTOSAR,可能需要举例说明,比如动力总成控制模块的开发步骤。同时,对比Adaptive AUTOSAR,强调Classic的实时性和确定性,适用于安全关键系统。 需要检查是否有遗漏的关键点,例如诊断功能、网络管理、ECU配置描述文件(ECUC)等。确保回答全面,但不过于冗长。最后,总结学习路径,帮助用户规划下一步的学习或实践。</think>好的!作为汽车软件工程师,深入了解 **Classic AUTOSAR** 需要从架构设计、开发流程、工具链到实际应用场景逐步展开。以下是一个 **聚焦工程实践** 的技术解析: --- ### **1. Classic AUTOSAR 的核心特点** - **目标场景**: 面向 **实时性要求高**、**功能安全(ISO 26262)关键** 的控制系统(如发动机控制、刹车系统、变速箱等)。 - **关键特性**: - **静态配置**:软件组件(SWC)在编译时绑定,运行时不可动态修改。 - **确定性执行**:基于 **OSEK/VDX** 实时操作系统(如Vector的MICROSAR OS),任务调度严格遵循优先级。 - **低资源占用**:适合资源有限的微控制器(如8/16/32位MCU)。 --- ### **2. 架构分层与核心模块** #### **分层架构(自上而下)** 1. **应用层(Application Layer)** - **SWC(Software Component)**:功能实现的最小单元,如“发动机扭矩计算”组件。 - 通过 **Port**(端口)与其他SWC或BSW交互(发送/接收数据,调用服务)。 - 接口类型:**S/R接口**(Sender/Receiver,数据传递)、**C/S接口**(Client/Server,服务调用)。 - **RTE(Runtime Environment)**: - 核心枢纽,负责SWC间的通信及与BSW的交互。 - **生成方式**:通过工具链(如Vector的DaVinci)基于SWC接口描述自动生成。 2. **基础软件层(BSW)** - **服务层(Service Layer)**: - 诊断服务(UDS协议)、存储管理(NvM)、网络管理(CAN NM)。 - **DEM(Diagnostic Event Manager)**:记录故障码(DTC)并触发诊断响应。 - **ECU抽象层(ECU Abstraction Layer)**: - 提供硬件无关的API(如控制ECU的某个GPIO引脚)。 - **微控制器抽象层(MCAL)**: - 直接驱动硬件(如PWM模块、ADC采集),需适配具体MCU型号(如Infineon Aurix、NXP S32K)。 --- ### **3. 通信机制(以CAN为例)** - **PDU(Protocol Data Unit)**:数据传递的基本单位(如CAN帧)。 - **信号路由流程**: ``` SWC → RTE → COM模块(信号打包) → PDUR(协议路由) → CAN接口层(CANIF) → CAN驱动(CAN Driver) → MCAL → 物理CAN总线 ``` - **关键配置**: - **DBC文件**:定义CAN信号报文,通过工具(如CANoe)生成通信栈配置代码。 - **IPDU(Interaction Layer PDU)**:在PDUR中定义信号报文的映射关系。 --- ### **4. 开发流程(V模型)** 1. **需求阶段**: - 使用 **ARXML(AUTOSAR XML)** 定义SWC接口、ECU资源分配及通信矩阵。 2. **设计阶段**: -工具链(如ETAS ISOLAR)中配置SWC、Port、RTE,生成应用层框架代码。 3. **BSW配置**: - 配置通信栈(CAN/LIN)、诊断服务(DCM/DEM)、OS任务调度表。 4. **集成与测试**: - **MIL/SIL**:模型在环/软件在环测试(如Matlab Simulink)。 - **HIL**:硬件在环测试(如dSPACE平台),验证ECU与整车交互。 --- ### **5. 工具链与生态** - **配置工具**: - Vector:**DaVinci Configurator**(BSW配置)、**DaVinci Developer**(SWC设计)。 - ETAS:**ISOLAR-A/B**(AUTOSAR全栈工具)。 - **代码生成**: - 应用层代码(SWC逻辑)由开发者手动实现,但RTE、BSW代码由工具自动生成。 - **调试与测试**: - **CANoe**:总线仿真与测试。 - **TRACE32**:MCU底层调试(如内存、寄存器查看)。 --- ### **6. 工程实践中的挑战** #### **难点与解决方案** - **内存分配冲突**: - **解决**:使用 **AUTOSAR Memory Stack**(MemIf、Fee、Ea)统一管理EEPROM/Flash。 - **多核调度同步**: - **解决**:配置OSEK OS的Spinlock或核间通信(IPC)机制。 - **启动时间优化**: - **解决**:通过 **BswM(Basic Software Manager)** 管理模块初始化顺序,减少冗余操作。 #### **示例:动力总成ECU开发** 1. **需求**:实现发动机喷油量控制,响应周期1ms,满足ASIL-D功能安全等级。 2. **设计**: - SWC划分:`SensorAcquisition`(传感器数据采集)、`FuelInjectionCtrl`(喷油计算)。 - RTE配置:定义S/R接口传递曲轴转速、节气门开度等信号。 3. **BSW配置**: - 配置MCAL的ADC驱动(采集氧传感器电压),CAN驱动发送喷油指令。 - 集成诊断服务(如检测氧传感器故障码P0130)。 --- ### **7. 学习路径建议** 1. **理论储备**: - 通读 **AUTOSAR Classic Platform 标准文档**(官网提供,重点阅读BSW、RTE、方法论)。 - 理解 **OSEK/VDX** 实时操作系统原理(任务调度、优先级反转处理)。 2. **实践入门**: - 使用 **免费工具链**(如Arctic Core + Eclipse)搭建简单ECU demo(如LED控制)。 -Vector官网下载 **MICROSAR** 试用版,体验BSW配置与代码生成。 3. **深入项目**: - 参与真实ECU开发(如车身控制器),重点掌握 **ARXML配置**、**RTE交互调试**、**HIL测试**。 --- ### **总结** Classic AUTOSAR 是传统汽车电子的基石,其核心价值在于 **标准化开发流程** 和 **软硬件解耦**。工程师需熟练掌握工具链配置、通信栈调试及功能安全设计。随着Adaptive AUTOSAR的兴起,理解两者的差异(如动态通信 vs 静态绑定)将帮助你在EE架构转型中保持竞争力。
评论 20
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值