[AutoSAR]EB tresos Studio的个人理解：用于生成BSW

介绍

软件开发环境 EB tresos Studio 让您能够配置、验证和生成 ECU 基础软件 (BSW)。

软件开发环境 EB tresos Studio 是我们的 EB tresos AutoCore 和 EB tresos OsekCore的工具环境。凭借其导入器和生成器接口，该工具可完美地融入汽车开放系统架构 AUTOSAR 工作流程，并且可以无缝集成到现有工具链中。这样就能实现公司特定的汽车基础软件模块以及传统软件组件的集成。

用于生成BSW

因为AutoSar 是分层的，所以不同的MCU 配置不同的BSW，上层的ASW
应用可以无缝切换。特别是现在升级成了TC397的多核MCU，以前的单核MCU的ASW也可以升级BSW，可以简单的实现多核程序的运行。

在AUTOSAR中，和MCU有关的一层是MCU抽象层，及MCAL。因为注册了不同的MCU驱动就可以驱动不同的MCU

附录 AUTOSAR的分层模型及各层简述

AUTOSAR从上往下分为

• 应用层ASW、
• RTE层
• 基础软件层（BSW）

ASW应用层由多个软件组件SWC组成，每个SWC是具有一定功能的模块，如汽车发动机控制逻辑，这些模块可以由matlab的autosar软件包依据模型进行设计
RTE全称Runtime Environment，即运行时环境，它的内部是一条autosar框架定义的虚拟功能总线（VFB），SWC、BSW通过这条虚拟功能总线进行通信。

BSW按照层级结构可以分为服务层、ECU抽象层、硬件抽象层（MCAL）和复杂驱动层（CDD）。（参考：http://www.uml.org.cn/car/202111011.asp）

• 硬件抽象层（MCAL）

主要包含了相关的Driver，通过该层次可以访问MCU的资源，比如访问整个芯片的CAN,LIN等控制器，配置MCU的Port脚，配置MCU的时钟等。主要包含下面的内容： MCU,PORT,DIO,ADC,SPI,CAN,LIN,FLEXRAY,PWM,ICU,OCU等

• ECU抽象层

底层驱动的抽象，同时它也是外设的驱动，它提供了可以访问外设和底层MCU的接口，该层次主要包含了下面的内容：CanIf,Can Transceiver Driver, MemIf, Fee, Ea, External Flash/EEPROM Driver, WdgIf等

• 服务层

包含操作系统的功能、车辆网络通信管理服务、存储器服务(NVRAM管理)、诊断服务(包括UDS通信、错误存储和故障处理)、ECU状态管理，模式管理、逻辑和时间程序流监控(Wdg管理器)、密码服务(密码服务管理)、调度管理（Schedule Manager）

• 复杂驱动

跨越于微控制器硬件层和RTE之间，其主要任务是整合具有特殊目的且不能用MCAL进行配置的非标准功能模块，将该部分功能嵌入到AUTOSAR基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求。复杂驱动程序跟单片机和ECU硬件紧密相关。其上层程序接口是根据AUTOSAR指定并且实施的；其下层程序接口受标准接口程序的限制。复杂驱动可以使用特定的中断或是复杂的微控制器外设（如PCP/TPU）来直接访问微控制器，从而实现对复杂传感器的评估和执行器的控制，比如喷油控制，电磁阀控制，增量位置检测等

BSW从上到下分层，分层的目的是为了实现各层的复用和对下一层的隔离，这正如RT-Thread的分层思想那样，RT-Thread可以适配不同的MCU就是因为采用了驱动和设备分离的策略，RT-Thread的同一个设备因为注册了不同的驱动就可以驱动不同的MCU。在AUTOSAR中，和MCU有关的一层是MCU抽象层，及MCAL，用RTT的驱动和设备分离的思想来理解autosar的mcal就是同一个ECU抽象层因为注册了不同的MCU驱动就可以驱动不同的MCU。在autosar的成员中就有nxp这样的芯片原厂提供autosar的mcal。

在S12Xs 上尝试配置BSW

我在官网只看到了：NXP HS12(X) AUTOSAR MCAL软件包（包含了RTM）
我理解，应该会有 HS12(X)_AUTOSAR_OS的安装包，但是我没有找到。我个人理解是官方没有释放OS，还是说不用OS

NXP HS12(X) AUTOSAR MCAL软件包 文件包含：

• MCAL3.0
• RTMC

我就不知道：OS 在哪？难道不需要？

NXP HS12(X) AUTOSAR MCAL软件包 的文件结构

SIP DIRECTORY STRUCTURE:
========================

BSW/_Common                                                 ; 共用头文件 (Compiler.h, Platform_Types.h, Std_Types.h, etc. )
BSW/<mod>                                                   ;模块源代码
Doc/TechnicalReferences                                     ; Technical reference manuals
Generators/Components                                       ; Code generation files
Generators/Components/<derivative>/_Schemes/<mod>/bswmd     ; Module Parameter Definition files 配置信息

在MCAL文件中可以看到全部的BSW文件

查看模块的配置信息：

我在添加modules没有看到OS相关的选项

但是官方的参考文档中有OS相关的模块信息配置

我在思考 BSW 一定需要 OS吗？

参考：https://blog.csdn.net/xyfx_fhw/article/details/99717642，OS的作用：
OS： 操作系统。就仅仅位于系统服务层，由于OS是需要直接操作硬件的一些功能的，所以系统服务层才会贯穿三层结构至达硬件。AutoSAR OS是基于OSEK OS开发出来的，OSEK也是早期ECU上的OS标准了，现在也有一些厂商在使用。

参考：https://www.freesion.com/article/8884454956/ BSW生成规范要点-开发规范（下）

12、中断服务例程

中断服务程序(ISR)的实现是高度依赖于微控制器的。

ISR的实现依赖于平台：

如果BSW正在模块分为平台独立的模块,BSW不得执行中断服务例程。

保持ISR的运行时间尽可能短：

中断服务例程(ISR)和在中断上下文中运行的函数的运行时间应该保持较短。例如，从ISRs调用的回调函数也会影响运行时间。

如果ISR可能需要很长时间，那么应该使用操作系统任务。

定义并记录ISR例程:

如果BSW模块实现了中断服务例程(ISR)，则这些功能应按照BSW模块描述中的BSW模块描述模板[4]规范中的描述进行定义和文档化。

支持中断类CAT2:

如果BSW模块实现了中断服务例程(ISR)，那么该实现至少应该支持中断类CAT2。

AUTOSAR架构不允许在应用程序级别的中断上下文中执行。考虑到这一点，需要特别注意由中断例程调用的嵌套函数。

从ISR到OS任务的过渡是受限制的:

如果BSW模块实现了中断服务例程(ISR)，并且需要从ISR过渡到OS任务，那么这种过渡应该在基础软件的尽可能低的级别进行:

• 在CAT2 ISR情况下，它的上下文最后只能到RTE。

• 在CAT1 ISR情况下，他的上下文最后只能在MCAL layer。

处理中断的BSW模块应部分或全部作为源代码交付，以便能够编译为使用CAT1或CAT2中断。

示例:来自MCAL层的BSW模块作为目标代码交付。中断处理程序可以写成一对小存根(一个CAT1存根和一个CAT2存根)，作为源代码交付。在模块集成过程中，根据需要编译代码—调用主处理程序。

所以，我认为应该是需要的，但没有找到相关的OS源代码下载地址。

附录：arxml 配置信息

在generator文件夹中可以看到

Generators/Components//_Schemes//bswmd ; Module Parameter Definition files

C:\Freescale\Freescale_S12_MCAL3.0_RTMC\Generators\Components\Mcs12x_S128\_Schemes\Adc\bswmd
Adc_bswmd.arxml

.arxml 描述文件即是 参数定义文件 (Parameter Definition file) 。

基于.arxml文件，就可以利用第三方提供的配置工具，将该文件作为输入导入配置工具进行相关的配置，比如：将ADB LED控制器的.arxml导入Vector的DavinciDeveloper软件中，可以自动生成相关的配置，完整配置好后即可生成代码文件，这样就可以免去手写代码的时间，提高开发效率。

看个.arxml文件，这个是AutoSAR Classic Platform提供的ECU configuration文件规范

附录：ECU.arXML创建流程

参考：https://blog.csdn.net/qq_40423998/article/details/107609941

ECU.arXML创建流程如下：
1.OEM关注的点是系统级的功能和集成，因此OEM端会提供系统级的描述文件，该文件中包含多个ECU的实例，并不包含软件组件部分，只有ECU级的通讯关系，这部分的设计可以基于UML/SysUML建模，也可以使用PREEVISION建模或者是ARtop来建模。
2. 供应商supplier拿到OEM提供的系统级的功能描述文件并导入到工具链中，比如vector的PREEVISION，加入到系统的虚拟功能总线上，也就是AutoSAR的RTE，这样就可以和系统内的其它模块进行通讯，此时，还是系统级的ECU，并没有软件组件部分。
3. 因OEM提供的系统级的功能描述文件中包含了系统部件到ECU的映射，以及信号的映射，供应商基于此，可进行ECU内部硬件结构和借口的设计，并将信号分配给实际的接口，
至此，供应商即完成了ECU.arXML创建过程。

翻译“EB_tresos_Studio_documentation_en.pdf”

主要针对 Autosar 和 EB tresos Studio 的新手，那些，对图形用户界面不是很熟悉。

3.2. Autosar 概念
Autosar（汽车开放系统架构）是
► 汽车，
► 电子产品，
► 半导体，
► 硬件和软件
致力于为汽车嵌入式架构建立开放行业标准的公司。
遵循此行业标准的软件允许您
► 管理汽车电气/电子 (E/E) 架构中的复杂交互，
► 使产品升级和更新更容易、更灵活，
► 在产品线内和跨产品线重用软件，
► 提高 E/E 系统的质量和可靠性，
► 并在设计的早期阶段发现软件错误。

电子控制单元 (ECU) 是执行应用程序功能（Autosar 应用程序软件组件）的平台。 Autosar 在功能上将 ECU 的应用程序与 ECU 的基本功能分开。 ECU的基本功能是

► 操作系统，
► 通讯系统，
► 和访问外围设备。

这些基本功能在 Autosar 所谓的基本软件 (BSW) 中实现。应用程序组件和 BSW 之间的所有数据交换都通过抽象层进行路由。这个抽象层是运行时环境 (Rte)，它对应用程序组件隐藏了 BSW 层。 Rte 实现了虚拟功能总线 (VFB)，它是应用程序组件实际交换信号/数据的抽象通信层。因此，应用程序组件在不知道该数据将在 ECU 内部或之间采用的路径的情况下交换数据。

BSW 包括用于访问外围设备和通信的驱动程序以及操作系统。应用工程师不再需要或确实可以直接访问 BSW 的资源，而是通过 Rte 中定义的接口路由他们的调用。从理论上讲，这也可以将功能从一个 ECU 转移到另一个 ECU。实际上，由于信号传输时间和延迟，这很困难

3.3. EB tresos Studio：ECU 标准软件的配置和生成工具

3.3.1。 配置和生成工具

由于 Autosar 依赖于根据用户要求生成代码，因此需要 EB tresos Studio 等配置工具来配置标准软件组件并生成特定的 ECU。

该工具遵循 Autosar 方法，但不仅可用于该标准的基本软件模块。 其代码生成器引擎、参数验证语言、数据模型访问和 GUI 的开放概念允许您将 EB tresos Studio 无缝集成到现有工具链和工作流中。 它可以帮助您以高效且易于使用的方式在组织内部署标准软件组件。

EB tresos Studio 的主要概念是遵循 Autosar 方法，提供开放和文档化的界面，帮助避免用户错误并创建易于使用的工具环境。

3.3.2. 用法
EB tresos Studio 的典型使用场景有：
► OEM 使用 EB tresos Studio 预先集成 ECU 标准核心软件并在其供应商之间进行部署。
► 一级公司使用 EB tresos Studio 为其生产 ECU 项目的基础软件规范和代码生成。
► 半导体供应商选择 EB tresos Studio 作为在其客户中部署微控制器驱动程序的工具。 当然，EB 使用 EB tresos Studio 作为其所有 EB tresos AutoCore 产品的配置编辑器。