【ETAS CP AUTOSAR工具链】RTA-BSW基础软件开发详解

本篇文章以RTA-BSW为蓝本,首先介绍了跟汽车ECU基础软件开发密切相关的AUTOSAR理论知识,并基于此描述了整个RTA-BSW的开发流程与框架,最后以一个从工程建立到RTE生成的完整开发流程实例分析,帮助读者更好的理解文章前两节涉及的理论知识。如果读者觉得前两节的理论知识读起来味同嚼蜡 ,笔者建议可以从Example Project这节开始阅读,不理解的地方可以在前两节的理论知识里寻找答案。

本文中的一些观点(例如“ETAS提供的基础软件高内聚低耦合”这个观点)为目前的主流观点,笔者对这些观点持保守态度。笔者认为AUROSAR  CP这套东西非常适合整车厂作为集成商,以RTE为切入点做ECU的系统架构设计,而把应用层的开发与硬件和底软的开发交给供应商来做(就像只做整车电子电气架构,具体的零部件由供应商提供一样),但是随着新能源汽车以及自动驾驶功能的冲击,带来了EE架构从分布式向集中式的演进、ECU芯片由MCU向SOC的演进。更快的迭代周期和更集中的功能实现都指向了使用基于成熟的开源项目(诸如Linux)来自主研发基础软件与操作系统,开发域控制器这条道路。AUROSAR  AP听说能应对这些挑战,但是笔者没有接触过,就不多说了,但是目前不仅特斯拉没有用AUROSAR  AP,国内几大造车新势力也没有用。

本篇文章介绍的RTA-BSW的版本为v3.1.0,它与ISOLAR-AB的V4.0版本兼容。文章内并不涉及BSW具体的模块配置与静态代码,后边会针对不同BSW栈进行详细介绍。

目录

定义与缩略语

AUTOSAR

架构

方法

接口

多核

RTA-BSW Workflow 

Creating Templates

 BSW初始配置生成

BSW代码生成

处理CodeGen引发的验证错误

Example Project 

工程创建

System Description Creation 

ASW Configuration 

ECU抽取 

BSW自动/手动配置

BSW Code Generation

RTE生成 


定义与缩略语

  • ARXML:用于描述SWCs、Systems和ECU配置的AUTOSAR XML文件。
  • ASW:AUTOSAR Application Software,在AUTOSAR规范中,应用程序由多个相互间通信的SWCs组成,其中包括服务SWCs、应用SWCs和复杂的设备驱动SWCs。
  • BSW:AUTOSAR Basic Software modules。AUTOSAR定义了一个全面的BSW体系结构,由服务、接口和驱动程序等BSW模块组成,这些模块提供了对于ASW独立于ECU的硬件抽象,从而促进SWCs的再利用和迁移。
  • BSW Stack:在AUTOSAR分层软件架构的基础上,按数据流向的一个纵向切片。由来自服务层、ECU抽象层和微控制器抽象层的功能相关的BSW模块组成。
  • CAN:Controller Area Network,是 ISO国际标准化的串行通信协议。
  • CDD:Complex Device Driver,用于访问AUTOSAR未定义标准化访问的硬件,为自定义的BSW模块。CDD向上层提供标准化接口,因此ASW可以使用RTE访问。然而,CDD提供的功能,例如它如何访问硬件,是特定于具体驱动的实现。
  • DTC:Diagnostic Trouble Code.
  • ECU:Electronic Control Unit.在AUTOSAR的背景下,ECU包括一个微控制器和一组实现特定功能的外设,并且与特定的ASW和AUTOSAR配置相关联。AUTOSAR在定义ECU时不考虑机械设计,也就是说如果一个外壳包含多个微控制器,那么对应每个微控制器都需要自己的AUTOSAR配置和BSW堆栈。
  • E/E:Electrical and Electronic.
  • FlexRay:Automotive总线支持高数据速率通信,FlexRay总线数据收发采取时间触发和事件触发的方式。
  • EEPROM:Electronically Erasable Programmable Read-only Memory.
  • I-PDU:Interaction Layer PDU.
  • IOC:Inter-OsApplication Communication,用于在0s应用程序之间发送和接收数据(多核)。
  • MCAL:Microcontroller Abstraction Layer,为AUTOSAR SW架构中基础软件的最低软件层。MCAL包含内部驱动程序(BSW可直接访问微控制器及其内部外围设备)并为ECU抽象层提供标准接口。
  • OSEK:汽车电子开放系统及其接口(汽车电子开放系统及其接口)。OSEK包括OSEK-OS和OSEK-COM的规范,它们被用作AUTOSAR Os和BSW模块Com的基础。
  • PDU:Protocol Data Unit,作为一个共同的实体,通过网络发送/接收的一组消息。
  • PIM:Per-Instance Memory,提供通过RTE生成的API访问的内存。
  • Schema:一个 XML 文件,用于描述另一个配置 XML 文件允许的结构和内容类型,包括数据类型、可用元素及其允许的顺序以及更专业的规则,例如多重约束。An ARXML 文件使用AUTOSAR提供的Schema。
  • SPI:Serial Peripheral Interface,采用主从架构的同步串行接口,广泛应用于汽车嵌入式系统。
  • SWC:AUTOSAR Software Component,ASW中的功能单元。AUTOSAR应用程序由多个SWC组成。
  • TP:Transmission Protocol,用于传输和接收大于单个总线帧的I-PDU的传输机制。
  • UDS:Unified Diagnostic Services,由ISO-15765定义并由AUTOSAR Dcm模块支持的标准化诊断服务。
  • VFB:AUTOSAR Virtual Function Bus.AUTOSAR虚拟功能总线VFB是由ASW的连接抽象组成,包括系统中所有SWC及其连接,但不包括到特定ECU的映射。VFB使ASW的集成发生在开发阶段的早期,并允许验证SWC之间的通信关系的一致性。

AUTOSAR

在AUTOSAR的背景下,BSW包含了三个关键概念:

  • Architecture:汽车软件体系结构的定义(包括全面的BSW堆栈)的一个架构,该体系结构提供向上渐进的抽象架构,以促进应用程序和基本软件的重用。
  • Methodology:供应商和OEM之间工作的一种系统方法的定义,该方法允许使用通用配置语言进行无缝交互。
  • Interfaces:一种数据交换与API类型定义,交互的语法和语义的定义,包括体系结构中模块之间以及供应商和OEM之间的接口。

已经熟悉AUTOSAR开发的读者可以跳过本节。RTA-BSW工作流。其中主要描述了两个过程:

  1. 如何使用ConfGen工具从系统描述中导出BSW配置。
  2. 如何使用CodeGen工具生成BSW源代码。

架构

AUTOSAR分层SW架构是AUTOSAR如何提供管理汽车软件复杂性的关键。AUTOSAR定义了ASW(由SWCs组成)、BSW(基础软件),RTE(运行时环境)各层的职责和BSW模块之间的关系。

上图显示AUTOSAR分层SW体系结构中的各层结构。每一层都封装和抽象了下面一层的功能和行为。

  • Application Software:AUTOSAR将应用软件建模为高内聚低耦合的SWC集合。这种设计使应用开发模块化并可以独立实施/测试单独的SWC(模块)。一个低耦合的架构意味着SWC之间的依赖关系是有限的,以允许SWC在不同的ECU上的复用,而不改变系统的设计。同样,一个高内聚的体系结构限制了一个模块的边界(一个单独的SWC将在类型上执行一小部分任务)。
  • AUTOSAR Run-Time Environment (RTE):RTE提供通信和向应用软件提供调度服务。RTE的目的是使应用软件独立于到特定ECU的映射。这使得SWC可以在不同车辆以及ECU中重复使用。
  • Service Layer:为应用程序、RTE和BSw模块提供基本服务的服务层模块。
  • ECU Abstraction Layer:ECU抽象层提供访问硬件的API,不管它们的位置(微控制器内部/外部)和它们与微控制器的连接(端口引脚,接口类型)。ECU抽象提供了与服务层的接口,该接口与微控制器和ECU都无关。
  • Microcontroller Abstraction Layer (MCAL):)AUTOSAR基础软件的最低软件层,包含内部设备的驱动程序,如Fls与Eep,以及直接映射到内存空间的外设。这些驱动程序可以直接访问内部硬件。
  • Microcontroller Hardware:微控制器硬件包含位于微控制器“内部”的设备例如内部EEPROM或CAN控制器。同时包含微控制器外部通过SPI连接的硬件芯片。

AUTOSAR分层软件体系结构的目标是通过以BSW的形式在应用软件和硬件之间提供一个抽象的、统一的和标准化的接口来提高应用软件的可重用性。通过增加可重用性,可以在面对汽车软件的整体复杂性时减少重复工作。AUTOSAR软件架构的每一层都封装了一些依赖关系:

  • 服务层为ASW(通过运行时环境)和其他BSW模块提供抽象服务。抽象服务可在任何AUTOSAR ECU上使用,从而促进ASW的可移植性和可重用性。
  • ECU抽象层在微控制器硬件布局(例如CAN控制器的数量和类型)与其上的服务层之间提供了AUTOSAR定义的抽象层。这确保了服务层可以在不考虑单个ECU硬件的特殊特性的情况下运行。
  • 微控制器抽象层(MCAL)包含内部MCU硬件设备的驱动程序,并封装了MCU的硬件特定特性。这种封装为ECU抽象层提供了一个AUTOSAR定义的接口,使其独立于MCU硬件。

BSW堆栈通过AUTOSAR分层软件体系结构定义了一个切片,该切片由来自服务、ECU抽象和微控制器抽象层的模块组成。在高层次上,由AUTOSAR体系结构内的不同层提供的功能块,共同形成了RTA-BSW的BSW堆栈的基础。不同的功能块如下图所示。

BSW堆栈通常是在功能级别上定义,由相互协作以向应用层提供具体某个功能的相关模块组成。常见的有以下几个:

  • RTA-BASE:  ECU和BSW初始化和状态管理。
  • RTA-COM:使用Com、PduR和特定总线模式的车辆网络通信栈。
  • RTA-MEM:使用非易失性存储器的持久存储(跨驱动周期)。
  • RTA-DIAG:事件记录以及与诊断服务的交互。

在服务层中,AUTOSAR允许模块之间的"水平"交互,例如Dem模块使用NVRAM管理器保存故障数据,这两个模块都是服务模块。同样,AUTOSAR允许ECU抽象层中模块之间的水平交互。但是,微控制器抽象层中的模块之间不允许进行水平交互。AUTOSAR对复杂的驱动程序例外,允许这些驱动程序使用与任何BSW模块的水平接口。当一个软件层访问上面或下面的软件层的接口时,发生“垂直”交互。单一的垂直交互,例如从服务层到ECU抽象层,显然是允许的,因为它们定义了将堆栈连接在一起的接口。此外,BSW模块可以访问另一层组的较低层模块,例如用于外部硬件的SPI。绕过一个软件层,即跳过一个层的垂直交互,应该避免,在AUTOSAR中不鼓励这样做,标准化的BSW也不使用这种方法。AUTOSAR不允许绕过两个或多个软件层。为了避免对硬件的依赖,AUTOSAR不允许服务和ECU抽象层中的模块绕过MCAL。最后,任何层的BSW模块都可以与系统服务交互,这个例外对于操作系统提供的服务很重要,因为它意味着独立的数据一致性和调度机制可以应用于BSW。

 复杂设备驱动程序(CDD)在AUTOSAR架构中具有独特的特性。它为直接访问非标准微控制器硬件提供了一种标准化的机制,并提供了ASW通过RTE访问的AUTOSAR接口。由于其在分层架构中的位置,它基于以下规则限制了对BSW模块的访问:

  • CDD访问的BSW模块必须公开一个可配置的接口(例如,指定回调例程的名称)。
  • BSW模块接口必须是可重入的,因为可能同时发生来自上层和CDD的访问。
  • 此外,不能使用BSW管理器模块,因为来自管理器和CDD的调用之间的交互可能会使该模
    块处于无效状态。

BSW模块还可以通过其在架构中的作用分为Interface(提供调用抽象)、Handler(支持异步\并发访问)、Manager(典型在服务层,不仅提供调用,还可以向下层传递参数)、Driver(驱动)、CDD(复杂驱动)、Library(库)。


方法

AUTOSAR方法定义了如何开发ECU软件,将开发过程划分为多个可分离的动作,这些动作涵盖了ECU SW开发的所有方面,从创建系统级描述到生成ECU的可执行文件。

系统设计阶段定义抽象应用架构、网络拓扑以及应用到ECU和通信到网络信号的映射。 

系统设计阶段的结果是包含一个或多个ARXML文件的AUTOSAR系统描述。描述了整个车辆架构。因为它包含了关于车辆的所有信息(其中一些是专有的),所以不允许OEM将整个系统描述分发给供应商。因此,AUTOSAR方法在系统设计中定义了子过程,以从完整的系统描述中导出系统提取(包含与一个功能子系统相关的信息)或ECU提取(包含单个ECU的信息)。这允许向供应商提供相关的系统信息,而不会同时提供不必要的专有信息。

ECU Extract包含BSW模块和单个ECU对应RTE的配置与生成所需要的足够信息。例如,ECU Extract的ECU配置(ECUC)值集合将定义由该ECU而非其他ECU发送/接收的信号(帧)。ECU提取是从系统描述中通过删除其他ECU的元素获得的,该过程由ISOLARAB自动完成。

RTA-BSW提供了两个独立的工具来帮助用户生成嵌入式BSW代码。它们是:

  • RTA-BSW ConfGen:ConfGen工具提供了一种从系统描述、系统提取或ECU提取导出默认ECU配置的自动化方法。
  • RTA-BSW CodeGen:CodeGen工具提供了一套代码生成器,使用所提供的ECU配置为BSW模块生成嵌入式代码。

在调用CodeGen工具生成BSW嵌入代码之前,集成商负责将任何所需的手动建立与配置(使用ISOLAR-AB)的BSW模块准备好。

最后就是应用程序的开发,ASW开发过程在很大程度上独立于系统设计。后者只需要关于每个SWC的有限信息集,例如用于通信的端口,运行实体等。因此ASW开发可以与系统设计并行进行。AUTOSAR促进了SWC在新ECU中的重用,并简化了OEM的集成。


接口

AUTOSAR接口定义了AUTOSAR软体开发过程中的参与者(如OEM和供应商)交换信息的时机和方式。AUTOSAR定义了几种标准化数据格式,用于交换与SWC、系统和ECU配置描述相关的信息。

  • SWC Description:ARXML描述了SWC的接口、动态行为和资源需求。SWC描述的语法和语义由AUTOSAR软件组件模板描述。具体的应用ARXML描述通常由供应商创建,并与相关的源代码或目标代码实现文件一起提供给OEM,供集成使用。
  • BSW Module Description:描述BSW模块的接口、动态行为和资源需求的ARXML。BSW模块描述的语法和语义由AUTOSAR BSW模块描述模板描述,通常由BSW模块的BSW代码生成过程创建,BSW模块向RTE提供AUTOSAR接口。
  • System Description:车辆E/E架构的ARXML描述,包括网络拓扑和信号、ECU拓扑以及到ECU的SWC映射。AUTOSAR系统模板定义了系统描述的语法和语义。
  • ECU Extract:ARXML由OEM提供给ECU供应商。它会生成对应ECU涉及的所有信号等信息,AUTOSAR系统模板定义ECU Extract的语法和语义(这与用于系统描述的AUTOSAR配置语法相同)。
  • ECUC Description:BSW配置参数的ARXML描述,源自ECU提取和BSW模块描述。参数配置BSW的特定部分,例如顶层的Com容器包含模块的全部配置。Com容器将包括多个子容器(这些子容器又可能包含额外的子容器),它们配置模块的不同方面,包括ComSignals等。形成ECUC描述的容器和参数由AUTOSAR提供的ECU配置参数定义文件定义。这个ARXML文件定义了每个标准化BSW模块的可用容器和参数。

在分层的SW体系结构中,AUTOSAR区分了三种不同的API形式:

  • AUTOSAR Interface:AUTOSAR使用软件组件模板定义语法。SWC实现者定义语义,例如发送或接收的数据类型等实现。
  • Standardized AUTOSAR Interface:AUTOSAR定义了语法和语义,它由两部分组成,首先是软件组件模板定义语法,AUTOSAR提供对应的ARXML定义对应接口类型以及发送或接收的数据类型定义。
  • Standardized Interface:由AUTOSAR定义的语法和语义,直接对应C函数,不需要有接口和Port等信息。

服务层BSW模块可以向上层RTE提供标准化AUTOSAR接口或标准化接口,因为AUTOSAR定义语法(接口形式)和语义(块的行为)以确保ASW的可移植性。相反,ASW使用AUTOSAR接口,因为AUTOSAR只定义了数据交换格式的语法,即软件组件模板。用户定义包含在应用程序功能中的接口的语义。


多核

RTA-BSW不支持跨多个ECU和微控制器内核的BSW分布。因此,在使用多核ECU时会应用以下约束:

  • 所有BSW模块必须映射到单个核心。
  • 包含BSW的核心必须将ECUC参数EcucPartitionBswModule-Execution设置为true。
  • 不包含BSW的核心必须将ECUC参数EcucPartitionBswModule-Execution设置为false。

操作系统模块(RTA-OS)支持多核应用,EcuM模块可以被配置为在每个适用的核上启动操作系统。RTE(RTA-RTE)支持将ASW的元素映射到多核的应用程序。RTE使用OS的IOC API在不同核心的SWC之间进行通信,并且这种机制不支持对BSW的访问,BSW使用基于API的C函数与RTE交互。因此,RTE和BSW交互必须发生在同一核心中。

将访问BSW的SWC映射到与BSW相同的核心中并不总是可能的,例如,不同的核心可能具有不同安全级别的软件。如果是这种情况,那么BSW分区中的代理SWC将完成不同核心对BSW的访问。


RTA-BSW Workflow 

下面介绍一下RTA-BSW的预期工作流中的活动和生成的输出。这个工作流程包含了一些关键的步骤:

  1. AUTOSAR系统描述ARXML文件完全使用AUTOSAR创作工具(如ISOLAR-AB)生成或通过从legacy文件(如DBC)导入信息来创建。
  2. 用户使用AUTOSAR软件组件模板ARXML定义VFB配置(信号连接,实体定义),通过附加的ASW配置(即SWC和部件)来扩充系统描述。
  3. RTA-BSW ConfGen使用系统描述和ASW配置来创建一个使用ECUC值集合ARXML的默认BSW配置。
  4. 用户在默认的BSW配置基础上扩展其他BSW组件与配置。
  5. RTA-BSW CodeGen生成BSW实现,其中包括C源代码(向RTE提供AUTOSAR接口),对应的SWCD模块ARXML,还包括一个或多个包含在RTE生成器配置中的BSWMD文件。


Creating Templates

首先我们需要建立System Template和Software Component Template,我们可以在ISOLAR-AB中完成,也可以导入Legacy File来实现,ISOLAR-A支持导入多种不同的Legacy File格式,以执行AUTOSAR系统描述的初始填充。下面是DBC文件对应的BSW模块。


 BSW初始配置生成

下面则可以通过ConfGen来产生对应的基础模块配置,首先我们选择一个对应的AUTOSAR Project,然后点击对应的ConfGen摁扭。

选择要为其生成Ecu Value Description值的ECU实例。

点击[0K]ConfGen过程将开始,并将结果报告给控制台。

ConfGen完成后,项目将包含EcucValueDescription与ParamDefs的ARXML文件。这将允许您在其基础上自定义ECU配置并生成AUTOSAR BSW。重复的ConfGen会将覆盖对应的Project_EcucValues.arxml(CAN除外的ECU配置值)以及Can_EcucValues.arxm(CAN对应BSW模块),用户可以在单独的ARXML文件中使用相同的ARPackage和EcucContainer结构定义附加的Ecuc参数和引用值。防止用户的配置因为重复生成丢失。

通过在Settings/algo.properties添加相应的默认值,用户可以更改ConfGen生成的默认的ECU配置(注意:algo.properties只能更改无法在系统模板中配置的默认值)。algo.properties文件中的规则采用逗号分隔的默认值列表的形式:

某些硬件要求按特定顺序排布CAN邮箱。可以通过在algo.properties文件中设置邮箱映射规则来支持这一点。 我们可以根据canHandleType或者controllerName等来排序,具体就不介绍了。


BSW代码生成

选择对应的工程,点击下面的摁扭。

 选择下面的位置可以建立一个新的代码生成规则。

然后会弹出下面的界面,选择生成规则。

  1. List of run configuration instances: 这里列出的每一项都是一个配置集合,您可以为每个项目创建一个运行配置集合,或者为不同的用例创建自定义配置。(例如,只验证和只运行Com模块)
  2. Select RTA-BSW:显示已安装的RTA-BSW版本列表并提示选择。
  3. Select Project:提示选择工作区项目。
  4. Select Output Path:默认情况下,路径将被设置为{ProjectPath}/src/BSW/Gen,但可以设置为任何目录作为代码生成目录。
  5. Module List:包含可以生成的模块列表。通过查看在所选项目中配置了哪些模块,并将其与所选RTA-BSW中的可用模块进行比较,然后,您可以通过单击选中按钮打开/关闭模块,CodeGen即可以根据选择和用户的配置进行代码生成工作。
  6. Miscellaneous Options:包含用于控制代码生成流程的其他选项,例如关闭代码生成(仅验证)或指示流程不生成SWCD ARXML(以避免覆盖手动配置)。

处理CodeGen引发的验证错误

如果作为CodeGen输入的BSW的Configuration包含无效的配置或与AUTOSAR规范不匹配,则会抛出验证错误。用户将看到的第一个错误通知是CodeGen Build Error对话框,如下所示。

可以在“问题日志”窗口中找到有关错误的详细信息。显示的每个错误都将包含有关问题的描述,在许多情况下,还会包含导致错误的文件名或参数。在下面的参数错误示例中,可以看到出问题的地方在"EcuMGeneral"下的"EcuMMainFunctionPeriod"参数。 

将鼠标悬停在一个错误上会弹出包含完整描述的错误提示。


Example Project 

工程创建

首先通过单击File->NeW->AUTOSAR Project在ISOLAR-AB中创建一个新的AUTOSAR项目。选择项目的名称,然后点击“完成”。

建立完成之后如下图所示,创建Project会默认创建ISOLAR_PlatformTypes.arxml,其中包含了一些基本数据类型的定义。


System Description Creation 

下面,我们导入DBC文件来完成system template configuration,具体的过程详见【ETAS CP AUTOSAR工具链】基本概念与开发流程,导入完成之后可见增加了系统的初始配置。

相关的配置信息存放在DBC_SysDesc.arxml中,通过下图可以看到对应的AR-PACKAGE的结构和参数,可以看到是一些系统信号和Ecu的基本描述。


ASW Configuration 

在系统模板配置之后,我们需要在运行RTA-BSW插件之前定义VFB/ASW配置,以充分利用BSW ConfGen过程。这样做将允许导入过程使用ASW配置来分配EcuC值。为此,我们将从Example文件夹导入预先制作的配置,在项目上点击鼠标右键,选择导入。

然后选择导入File System。

选择展开Example\lmport文件夹并选择【ASW】。选择所有文件并通过点击【FINISH】将它们导入到项目根目录中。

 刷新项目,现在应该有一个基本的ASW配置。如下所示。

我们来看system.arxml内包含的内容,如下图所示,会有SWC-TO-ECU-MAPPING,以及ECU以及Composition的引用。


ECU抽取 

下一步是创建ECUExtract,ISOLAR-AB为其提供了一个自动生成该元素的工具。在ECU实例的上下文菜单中选择【CreateECUExtract】,【选择默认设置并导航到Finish】按钮,然后针对此ECU抽取BSW ConfGen步骤所需的完整信息集。

抽取最终会生成三个文件, 下面分别介绍三个ARXML的内容。

  • System_EcuExtr.arxml:系统涉及的I-SIGNAL(系统信号),还有SENDER-RECEIVER-TO-SIGNAL-MAPPING,还有SWC-TO-ECU-MAPPING等映射信息,最后还引用了Test_FlatMap与Test_FlatView。
  • Test_FlatMap.arxml:包含了系统涉及的FLAT-INSTANCE-DESCRIPTOR,其中包含了所有Interface对应的实例信息,包含SW-DATA-DEF-PROPS,UPSTREAM-REFERENCE-IREF,ECU-EXTRACT-REFERENCE-IREF。每个实例映射对应的部件,组件以及端口信息。每个实例分为UPSTREAM与ECU-EXTRACT两类,保证抽取与设计的一致性。
  • Test_FlatView_SWCD.arxml: 包含系统涉及的PORTS,COMPONENTS,以及CONNECTORS,包含系统涉及的所有组件以及相关的端口与连接信息。

BSW自动/手动配置

使用前文提到的方式执行ConfGen,会生成以下文件,红框的文件是之前在提到的Project_EcucValues.arxml(CAN除外的ECU配置值)以及Can_EcucValues.arxml(CAN对应BSW模块)。

下图为Can_EcucValues.arxml包含的内容。

这里建立一个基础的RTE组件,用于后边RTE生成。

对应的ARXML文件如下,读者可以稍微感受以下ARXML源文件的样子,后边我们会以一个专题文章来介绍一下这种标签语言。

<?xml version="1.0" encoding="UTF-8"?>
<AUTOSAR xmlns="http://autosar.org/schema/r4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://autosar.org/schema/r4.0 AUTOSAR_4-2-2.xsd">
  <AR-PACKAGES>
    <AR-PACKAGE>
      <SHORT-NAME>ETAS_Project</SHORT-NAME>
      <AR-PACKAGES>
        <AR-PACKAGE>
          <SHORT-NAME>EcucModuleConfigurationValuess</SHORT-NAME>
          <ELEMENTS>
            <ECUC-MODULE-CONFIGURATION-VALUES>
              <SHORT-NAME>Rte</SHORT-NAME>
              <DEFINITION-REF DEST="ECUC-MODULE-DEF">/AUTOSAR_Rte/EcucModuleDefs/Rte</DEFINITION-REF>
              <CONTAINERS>
                <ECUC-CONTAINER-VALUE>
                  <SHORT-NAME>RteGeneration</SHORT-NAME>
                  <DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR_Rte/EcucModuleDefs/Rte/RteGeneration</DEFINITION-REF>
                  <PARAMETER-VALUES>
                    <ECUC-TEXTUAL-PARAM-VALUE>
                      <DEFINITION-REF DEST="ECUC-ENUMERATION-PARAM-DEF">/AUTOSAR_Rte/EcucModuleDefs/Rte/RteGeneration/RteGenerationMode</DEFINITION-REF>
                      <VALUE>VENDOR_MODE</VALUE>
                    </ECUC-TEXTUAL-PARAM-VALUE>
                    <ECUC-TEXTUAL-PARAM-VALUE>
                      <DEFINITION-REF DEST="ECUC-ENUMERATION-PARAM-DEF">/AUTOSAR_Rte/EcucModuleDefs/Rte/RteGeneration/RteCalibrationSupport</DEFINITION-REF>
                      <VALUE>NONE</VALUE>
                    </ECUC-TEXTUAL-PARAM-VALUE>
                    <ECUC-NUMERICAL-PARAM-VALUE>
                      <DEFINITION-REF DEST="ECUC-BOOLEAN-PARAM-DEF">/AUTOSAR_Rte/EcucModuleDefs/Rte/RteGeneration/RteDevErrorDetect</DEFINITION-REF>
                      <VALUE>0</VALUE>
                    </ECUC-NUMERICAL-PARAM-VALUE>
                    <ECUC-NUMERICAL-PARAM-VALUE>
                      <DEFINITION-REF DEST="ECUC-BOOLEAN-PARAM-DEF">/AUTOSAR_Rte/EcucModuleDefs/Rte/RteGeneration/RteDevErrorDetectUninit</DEFINITION-REF>
                      <VALUE>0</VALUE>
                    </ECUC-NUMERICAL-PARAM-VALUE>
                    <ECUC-TEXTUAL-PARAM-VALUE>
                      <DEFINITION-REF DEST="ECUC-ENUMERATION-PARAM-DEF">/AUTOSAR_Rte/EcucModuleDefs/Rte/RteGeneration/RteIocInteractionReturnValue</DEFINITION-REF>
                      <VALUE>RTE_COM</VALUE>
                    </ECUC-TEXTUAL-PARAM-VALUE>
                    <ECUC-NUMERICAL-PARAM-VALUE>
                      <DEFINITION-REF DEST="ECUC-BOOLEAN-PARAM-DEF">/AUTOSAR_Rte/EcucModuleDefs/Rte/RteGeneration/RteMeasurementSupport</DEFINITION-REF>
                      <VALUE>1</VALUE>
                    </ECUC-NUMERICAL-PARAM-VALUE>
                    <ECUC-TEXTUAL-PARAM-VALUE>
                      <DEFINITION-REF DEST="ECUC-ENUMERATION-PARAM-DEF">/AUTOSAR_Rte/EcucModuleDefs/Rte/RteGeneration/RteOptimizationMode</DEFINITION-REF>
                      <VALUE>RUNTIME</VALUE>
                    </ECUC-TEXTUAL-PARAM-VALUE>
                    <ECUC-NUMERICAL-PARAM-VALUE>
                      <DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/AUTOSAR_Rte/EcucModuleDefs/Rte/RteGeneration/RteToolChainSignificantCharacters</DEFINITION-REF>
                      <VALUE>127</VALUE>
                    </ECUC-NUMERICAL-PARAM-VALUE>
                    <ECUC-NUMERICAL-PARAM-VALUE>
                      <DEFINITION-REF DEST="ECUC-BOOLEAN-PARAM-DEF">/AUTOSAR_Rte/EcucModuleDefs/Rte/RteGeneration/RteVfbTraceEnabled</DEFINITION-REF>
                      <VALUE>0</VALUE>
                    </ECUC-NUMERICAL-PARAM-VALUE>
                  </PARAMETER-VALUES>
                </ECUC-CONTAINER-VALUE>
              </CONTAINERS>
            </ECUC-MODULE-CONFIGURATION-VALUES>
          </ELEMENTS>
        </AR-PACKAGE>
      </AR-PACKAGES>
    </AR-PACKAGE>
  </AR-PACKAGES>
</AUTOSAR>

EcucValues文件夹下边包含各个模块的BswMD_EcucValues,其中包含rba_ArxmlGen_AppDataTypes和rba_ArxmlGen_CompuMethods以及rba_ArxmlGen_CompuMethods和rba_ArxmlGen_Measurements等BSW模块涉及容器信息以及rba_ArxmlGen_ComplsStandalone等用于生成BSWMD文件的信息。

ParamDefs文件夹下边包含所有BSW模块支持组件所包含参数以及相关描述,用户建立BSW模块时就会以此为模板,生成ARXML文件供用户自定义参数。 

BSW Code Generation

使用CodeGen生成代码与对应的arxml(BSWMD或者SWCD)文件,生成无错误如下。

具体生成的代码如下,代码生成在{ProjectPath}\src\BSW\Gen,代码分为静态代码和模块配置参数,下图中红框中的为模块的配置参数,src文件夹下的为静态代码。

具体生成的arxml文件如下。

我们通过下图可以看到,没有用到的模块对应的BswMD_EcucValues已经通过更改后缀名称被工程忽略了。

模块对应的BSWMD文件包含一下两个文件,xxx_BSWMD.arxml会引用xxx_Cfg_BSWMD.arxml中的具体信息,而xxx_BSWMD.arxml中的信息又会被别人引用。

  • 模块名_BSWMD.arxml:模块提供的API等信息。

  • 模块名_Cfg_BSWMD.arxml:模块的配置描述信息。

如果有一些基础软件组件还需要提供给RTE标准AUTOSAR接口,像Service类的组件(Standardized AUTOSAR Interface,需要用户基于软件组件模板根据需要完成具体的连接),就会生成对应的SWCD文件,模块名_Cfg_SWCD.arxml包含对应的软件组件模板。


RTE生成 

在RTE生成之前先建立EcucValueCollection.arxml,包含了ECU抽取与ECUC-MODULE-CONFIGURATION-VALUES,其中包含了之前创建的RTE模块(包含了RTE生成的一些参数)。下面是对应arxml的内容。

<?xml version="1.0" encoding="UTF-8"?>
<AUTOSAR xmlns="http://autosar.org/schema/r4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://autosar.org/schema/r4.0 AUTOSAR_00044.xsd">
  
<AR-PACKAGES>
<AR-PACKAGE>
      <SHORT-NAME>EcucValueCollection</SHORT-NAME>
      <ELEMENTS>
        <ECUC-VALUE-COLLECTION>
          <SHORT-NAME>EcucValueCollection</SHORT-NAME>
          <ECU-EXTRACT-REF DEST="SYSTEM">/System_EcuExtract/EXTR_Test</ECU-EXTRACT-REF>
          <ECUC-VALUES>
            <ECUC-MODULE-CONFIGURATION-VALUES-REF-CONDITIONAL>
              <ECUC-MODULE-CONFIGURATION-VALUES-REF DEST="ECUC-MODULE-CONFIGURATION-VALUES">/ETAS_Project/EcucModuleConfigurationValuess/Rte</ECUC-MODULE-CONFIGURATION-VALUES-REF>
            </ECUC-MODULE-CONFIGURATION-VALUES-REF-CONDITIONAL>
          </ECUC-VALUES>
        </ECUC-VALUE-COLLECTION>
      </ELEMENTS>
    </AR-PACKAGE>
  </AR-PACKAGES>
  </AUTOSAR>

RTE生成的过程可能会报一些错误,错误如果未指定会生成在RTE输出目录下RteErr.xml文件中,如下图。

可以看出是因为CanIf模块会引用EcmM的函数,EcuM是一个可执行软件必备的服务,所以我们需要生成并配置EcuM模块即可,配置都正常之后生成RTE会出现如下图。


 十六宿舍 原创作品,转载必须标注原文链接。

©2023 Yang Li. All rights reserved.

欢迎关注 『十六宿舍』,大家喜欢的话,给个👍,更多关于嵌入式相关技术的内容持续更新中。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值