3、BSW配置基础：EB tresos Studio与Vector DaVinci Developer简介、配置参数结构（容器、参数、引用）、配置描述文件（ARXML）解析

3.1 两大配置工具：EB tresos Studio 与 Vector DaVinci Developer

做AUTOSAR BSW配置，你绕不开两个工具：EB的tresos Studio和Vector的DaVinci Developer。说实话，这两家几乎垄断了市场。我个人习惯是，项目前期用DaVinci做系统设计和SWC建模，到了BSW配置阶段，反而更常用tresos Studio。为什么？因为tresos在底层MCAL配置上更灵活，颗粒度更细。

先说说EB tresos Studio。它主要面向BSW和MCAL的配置。你想想看，一个典型的ECU项目，底层驱动、通信栈、存储栈、诊断栈，全得靠它来配。它的界面长什么样？左侧是模块树，右侧是参数编辑区。每个模块对应一个配置容器，里面塞满了参数和引用。

我记得第一次用tresos时，被它的“模块依赖图”搞晕过。你配一个Can模块，它可能依赖CanIf、CanTrcv、EcuM好几个模块。如果依赖没配全，生成代码时会报一堆错。嗯，这里要注意：配置顺序很重要。我建议先配MCAL层，再配ECU抽象层，最后配服务层。

再来看Vector DaVinci Developer。它更擅长做系统级设计。比如你要定义ECU的软件架构、SWC之间的接口、Runnable的触发方式。说白了，它解决的是“软件长什么样”的问题，而tresos解决的是“软件怎么跑在硬件上”的问题。

我在项目中遇到过一种情况：客户用DaVinci Developer设计好了SWC架构，但到了BSW配置阶段，发现某些信号路由不对。后来排查发现，是DaVinci里定义的Port和tresos里配置的CanIf通道没对应上。所以，两个工具的配置必须保持同步，否则后面联调会非常痛苦。

3.2 配置参数结构：容器、参数、引用

BSW配置的核心，说白了就是三个东西：容器（Container）、参数（Parameter）、引用（Reference）。你打开任何一个ARXML文件，看到的都是这三者的组合。

3.2.1 容器（Container）

容器就是参数的“文件夹”。一个容器可以包含多个子容器，也可以包含参数和引用。比如Can模块的配置，最顶层是一个CanConfigSet容器，里面包含CanController、CanHardwareObject等子容器。

<CONTAINER>
  <SHORT-NAME>CanConfigSet</SHORT-NAME>
  <SUB-CONTAINERS>
    <CONTAINER>
      <SHORT-NAME>CanController_0</SHORT-NAME>
      <PARAMETERS>...</PARAMETERS>
    </CONTAINER>
  </SUB-CONTAINERS>
</CONTAINER>

我曾经犯过一个低级错误：在tresos里复制了一个CanController容器，改了名字但没改里面的波特率参数。结果两个控制器跑在不同的波特率上，通信时断时续。排查了两天才发现。所以，复制容器后一定要检查所有参数。

3.2.2 参数（Parameter）

参数就是具体的配置值。它可以是整数、浮点数、枚举、字符串等。比如Can控制器的波特率、Can邮箱的ID类型（标准帧/扩展帧）、调度周期等。

这里有个坑：参数的取值范围。有些参数在ARXML里定义了最小值、最大值和步长。比如某个定时器参数，范围是0~65535，步长是1。如果你配了个65536，生成代码时不会报错，但运行时定时器会溢出。我建议配完参数后，用工具自带的“验证”功能跑一遍。

3.2.3 引用（Reference）

引用是BSW配置里最容易被忽视的东西。它用来建立模块之间的关联。比如CanIf模块要引用Can模块的某个控制器，或者EcuM要引用某个唤醒源。

<REFERENCE>
  <SHORT-NAME>CanIfCanControllerRef</SHORT-NAME>
  <DESTINATION>CanController</DESTINATION>
  <VALUE>/Can/CanConfigSet/CanController_0</VALUE>
</REFERENCE>

引用路径写错了，是配置里最常见的错误。我记得有一次，一个同事把引用路径写成了绝对路径，但项目里用了相对路径的配置方式，结果生成代码时引用解析失败。嗯，这里要注意：引用路径的格式必须和项目配置一致。有的项目用绝对路径（以/开头），有的用相对路径。

3.3 配置描述文件（ARXML）解析

ARXML是AUTOSAR的配置描述文件，说白了就是XML格式的配置文件。你看到的tresos界面里的所有配置，最终都会序列化成ARXML文件。反过来，你也可以直接编辑ARXML文件，然后导入到工具里。

ARXML的结构其实不复杂。顶层是AUTOSAR根元素，里面包含AR-PACKAGES，每个包下面有ELEMENTS，元素里就是容器、参数、引用。

<AUTOSAR>
  <AR-PACKAGES>
    <AR-PACKAGE>
      <SHORT-NAME>CanModule</SHORT-NAME>
      <ELEMENTS>
        <ECUC-MODULE-CONFIG>
          <SHORT-NAME>Can</SHORT-NAME>
          <CONTAINERS>
            <ECUC-CONTAINER>
              <SHORT-NAME>CanConfigSet</SHORT-NAME>
              <PARAMETERS>...</PARAMETERS>
            </ECUC-CONTAINER>
          </CONTAINERS>
        </ECUC-MODULE-CONFIG>
      </ELEMENTS>
    </AR-PACKAGE>
  </AR-PACKAGES>
</AUTOSAR>

你可能会问：为什么要直接编辑ARXML？在tresos里配不就行了？说实话，有些场景下直接改ARXML更高效。比如你要批量修改100个邮箱的ID，在界面上点100次鼠标，不如写个脚本改ARXML来得快。

ARXML里还有一个重要的概念：模块定义（Module Definition）。它定义了每个模块有哪些容器、参数、引用。你看到的tresos界面，其实就是根据模块定义动态生成的。所以，如果你要自定义一个模块，就得先写模块定义文件。

我在项目中遇到过一种情况：客户要求增加一个自定义的BSW模块，用来做硬件抽象。我花了三天时间写模块定义，定义好容器结构、参数类型、引用关系。然后导入tresos，界面就自动生成了。嗯，这就是AUTOSAR的灵活性——一切皆可配置，一切皆可扩展。

3.4 本章知识体系

下面这张图，是我自己总结的BSW配置知识体系。你可以看到，工具、参数结构、ARXML文件三者之间的关系。

这张图里，我把BSW配置分成了三层：工具层、参数结构层、文件层。工具负责展示和编辑，参数结构是逻辑骨架，ARXML是物理载体。三者缺一不可。

好了，这一章的内容就到这里。BSW配置的基础，说白了就是搞懂工具怎么用、参数怎么配、文件怎么改。下一章我们会深入具体的模块配置，比如Can栈、Lin栈、存储栈。到时候再聊。