AUTOSAR BSW 开发这个方向刚入行的人最容易懵圈资料多、模块多、工具链复杂光是 NVM、COM、CANIF、ECUC 这些缩写就能把人绕晕。我当年从 MCAL 裸机开发转到 BSW 集成时第一个月基本是在看文档和调配置中度过的很多东西网上查不到现成答案只能靠翻规范、试配置、打日志一点点磨出来。这篇笔记是我在实际项目中沉淀下来的目录式总结把 BSW 开发的核心链路、配置思路和踩坑记录串在一起给正在做 AUTOSAR 集成或者准备入坑的工程师一个可以参照的路线。简单说这篇东西能帮你搞清楚 BSW 各个模块是干什么的、它们之间数据怎么流动、用 DaVinci Configurator 配置时有哪些容易翻车的细节以及遇到问题该怎么排查。1. 整体设计思路BSW 开发到底在做什么1.1 先建立整体认知AUTOSAR 分层架构很多初学者拿起 AUTOSAR 规范就一头扎进某个模块结果越看越迷糊。原因很简单AUTOSAR 是一个分层架构每一层都有明确的职责边界脱离整体看局部永远看不明白。从下往上分四层MCAL微控制器抽象层、ECU 抽象层ECU Abstraction Layer、服务层Services Layer和 RTERuntime Environment。再往上就是应用层 SWCSoftware Component。BSW 指的是 RTE 以下的所有部分也就是前三层加在一起。MCAL 直接操作寄存器比如 Dio、Port、Mcu、Adc、Pwm、Spi 这些ECU 抽象层对上提供统一接口把 MCAL 的差异屏蔽掉典型的有 CanIf、LinIf、EthIf、WdgIf服务层做的是通用服务比如通信服务Com、PduR、Dcm、存储服务NvM、Fee、Eep、诊断服务Dem、Dcm、网络管理Nm、OS 等。这套分层设计解决的核心问题只有一个让应用层代码与硬件解耦。以前在裸机上写个 CAN 报文你要自己初始化控制器、配置邮箱、处理中断每个芯片都有一套管法。有了 AUTOSAR 之后你的应用层通过 RTE 调用标准接口底层换了芯片应用代码基本不用动。代价就是配置工作量巨大一个复杂项目BSW 配置项上千个都很正常。1.2 学习 BSW 的正确路径不是所有模块都要精通BSW 模块很多但实际项目里真正需要你深入掌握的也就那几个。我的建议是分三批学第一批是通信与诊断链路这是项目里最常动、问题最多的部分。CanIf、CanTp、PduR、Com、Dcm、Dem 这几个必须吃透。经手的项目里至少有六成问题出在这一条链路上要么是报文周期性不对要么是诊断超时要么是信号映射错了。第二批是存储与网络管理NvM、Fee、Eep、Nm 这些。NvM 的链路特别有意思从 SWC 调用 NvM_Write数据先到 NvM 内部队列然后通过 Fee 模块写入 Eep 抽象最后才是底层 Eep 驱动。任何一个环节配置不对存储就会失败。NvM 是项目后期最容易让人头疼的模块。第三批是 OS、WdgM、EcuM、BswM 这些基础服务模块。OS 主要关心任务调度和中断优先级EcuM 和 BswM 是状态管理的基础启动流程、休眠唤醒流程都靠它们。这部分通常调试好了之后就不太动但是启动到不了 APP、休眠唤不醒这类问题排查起来极其费时间。剩下的 SecOC、E2E、Xcp、Eth 等模块用在特定车型或特定控制器上用到的时候再深挖。学习路径不是从 OS 开始也不是从 SecOC 开始而是从数据链路开始这条路最贴近日常开发也最容易建立正向反馈。1.3 工具链选型DaVinci 与 EB tresos 的差异配置 BSW 的主流工具就两家Vector 的 DaVinci Configurator 和 Elektrobit 的 EB tresos。二者逻辑完全不同这点一定要提前搞清楚。DaVinci 属于模型抽象路线界面里的配置项更像是对 AUTOSAR 模型的可视化操作生成代码时是整套生成配置数据存在 .arxml 文件里。EB tresos 则是编辑器路线直接编辑各个模块的配置界面风格更像传统 IDE密密麻麻的表格。我用 DaVinci 的时间更长整体体验是DaVinci 的上手曲线略陡但一旦理解了它的数据模型配置效率很高特别是做 SWC 和 RTE 这一块几乎没有替代者。如果项目定了 Autosar 4.4 版本DaVinci 的兼容性也做得更顺滑。成本差异也很大DaVinci 价格不便宜EB 相对便宜些。但如果项目里已经有 Vector 的 CANoe、CANape大概率会直接选 DaVinci因为工具链本身就成体系。选哪个不重要重要的是别两边混着用。有的工程师习惯在 EB 里写代码、在 DaVinci 里配 BSW结果生成的模块接口对不上数量多起来之后基本改不干净。一个项目锁一条工具链这是我一直坚持的做法。2. 通信链路拆解一条 CAN 报文的数据旅程2.1 COM 模块信号与 PDU 的解耦层COM 模块在通信链路里扮演的角色是信号与 PDU 的解耦层。应用的 SWC 通过 RTE 调用 Com_SendSignal把信号值传进来COM 负责把这个信号填到对应的 PDU 的数据字节里然后通过 PduR 发到通信接口层。这里最核心的机制是信号与 PDU 的映射关系。在 DaVinci 里你配置了一个 I-PDUInteraction PDU然后在里面定义多个信号每个信号对应一个起始位和长度。你在代码里发的是信号网络上传的是 PDU二者通过配置绑定。这个设计和传统 CAN 矩阵有些类似但比 CAN 矩阵更灵活因为 PDU 的触发方式可以是周期发送、事件发送、或者只发变化的值。我刚开始调 COM 时犯过一个典型错误在 SWC 的 Runable 里直接调用 Com_SendSignal期望报文立刻发出。实际上 COM 的发送要等 PDU 的周期到了才会执行。想立刻发得在配置里把发送模式改成 DIRECT_N_SENT 或设置最小发送间隔为 0同时调用 Com_SendSignal 后还要触发 Com_TriggerIPDUSend如果配置了 Manual 模式。很多新手在这卡半天就是因为没搞明白 COM 的周期调度模型。2.2 PduR 与路由策略网关思维从这里开始PduR 是通信链路的枢纽它干的事是路由把收到的 PDU 从上往下发或者从下往上提。提一句容易混淆的点PduR 的路由不只是网关控制器的事单 ECU 内部Dcm 诊断请求、Com 周期性报文、CanTp 的分包重组都要经过 PduR 来分发。配置 PduR 时最关键的是路由路径也就是 RoutingPath。你需要定义源模块和目标模块以及对应的 PDU 映射。比如 Dcm 收到了 0x2E 诊断请求Dcm 调用 PduR 把数据发到 NvM再比如 Com 通过 PduR 把周期报文发到 CanIf。每条路由都要显式配置漏一条运行时就静默失败而且大概率不报错因为 PduR 对无效路由的处理只是丢弃。网关型控制器的 PduR 配置会更加复杂涉及 PDU 转换、网关路由表。我做过一个网关项目PduR 路由表接近一百条每条都有方向、ID 映射、周期策略。调试这种配置没有别的办法只能一条条核对用一个报文矩阵表格逐项比对。我强烈建议在配置前先把路由表整理成 Excel每条路由都记录源、目的、PDU ID、周期、触发方式配置时对着表填能减少九成低级错误。2.3 CANIF 与 CAN Driver硬件抽象的关键一跳CanIfCAN Interface是通信栈从逻辑到物理的转折点。上面 Com/PduR 关心 PDU 和信号CanIf 开始关心 CAN 帧、硬件对象和收发模式。这里的核心概念是 HOHHardware Object Handle它直接对应 CAN 控制器的硬件报文槽位比如一个邮箱。配置 CanIf 时要确定的两个重要参数是 CanIfTxPduCanId 和 CanIfRxPduCanId它们定义了软件 PDU 和硬件 CAN ID 的绑定关系。同时要留意 CanIf 的缓冲策略是 Immediate立即写硬件还是 Queued先进队列。Immediate 适合对响应时间要求高的报文比如实时状态反馈Queued 适合大数据量的块发送避免长时间占用硬件。CAN Driver 这一层就是真正操作寄存器了。Can_Write 调用后数据进到硬件发送缓冲区CAN 控制器自动组帧发送。CanIf 的一个重要职责是处理 Bus-off 恢复。比如 MCU 的 CAN 控制器进入 Bus-off 状态后CanIf 会做 re-initialization这个流程配置错了总线就会永久拉死。我调试过一个 Bus-off 恢复的问题控制器反复重启后来发现是 CanIf 的 CanIfBusOffProcessing 配置了 TRIGGER_REINIT但没有给 CanIf 正确初始化 Can_Init 回来的参数导致控制器无法正常恢复这个环节非常细但项目里几乎都会遇到。2.4 通信还要注意什么CanTp、28 服务与时间同步很多人以为通信链路就是 Com 到 CanIf 就完了实际上诊断和网络管理都跑在这条链路上面。CanTp 模块负责处理多帧诊断报文比如 0x22、0x27 这类需要回很多数据的服务都会走 CanTp 分包发送。CanTp 的配置主要是收发窗口的大小、块序列号超时、帧间时间隔参数。这里常见的问题是 STmin 配置过小导致接收端 buffer 溢出整车网络里就会出现偶发的诊断负响应。另一个容易被忽视的是 0x28 服务CommunicationControl。这个服务在 AUTOSAR 诊断规范里用来控制通信典型场景是产线刷写时关闭通信、下线后恢复。Dcm 要支持 0x28需要在配置里把 CommunicationControl 的子功能打开同时要把关闭通信的动作真正挂到 CanIf 的停发停收逻辑上。很多项目只是 Dcm 返回了正响应但通信根本没停这种半吊子实现在整车 EOL 测试时必然被刷出来。还有一个问题在带时间同步的控制器上比较常见Com 模块的 I-PDU 周期是同步到时间主站的如果时间同步配置没做多个控制器的周期报文会互相错开。BswM 里通常会配置 TimeSync 相关的协调逻辑这个领域比较冷门但只要项目要求时间确定性网络就得重点研究。正常通信链路的日志可以用 CANoe 直接抓但时间同步的问题必须用 CANoe 的 TimeSync 窗口分析普通报文窗口看不出来。3. 存储与网络管理NVM 链路与 NM 状态机3.1 NVM 模块链路从 SWC 到 Flash 的完整路径NVM 是 BSW 里链路最长、最容易出错的一个模块。它的作用很直白让应用层读写非易失性数据比如故障码计数、驾驶模式记忆、校偏参数。但它的内部结构和普通 Flash 读写完全不是一个量级。先说数据路径。你调用 NvM_Write 时数据先进入 NvM 内部的管理队列NvM 会做校验可选、加时间戳可选取决于配置然后调用 FeeFlash EEPROM Emulation模块。Fee 是模拟 EEPROM 的一层它把 NvM 的数据块映射到 Flash 的扇区里用磨损均衡和掉电保护策略管理物理写入。做完这些才交给 Eep 驱动Eep 驱动可能是操作真正的 EEPROM 芯片也可能继续落到内部 Flash。你没看错数据要经过 NvM - Fee - Eep 三层才落地。理解了链路配置才有依据。NvM 配置几个关键点数据块类型NvMBlockManagementType是 Native数据直接存原始值还是 Redundant存两份互为校验配置错了数据可靠性大受影响。我的原则是安全相关数据用 Redundant普通配置用 Native配合 CRC。写策略NvMWriteStrategy包括立即写、周期写、掉电前写。这里最坑的是掉电前写。很多项目希望在检测到掉电的瞬间把关键数据写进 Flash但写 Flash 需要时间掉电电压维持不了那么久。解决办法是把关键数据做成短块或者用外部 EEPROM否则就必须准备好足够大的电容。这块是硬件、软件联调时的重灾区。数据校验NvM 支持 CRC 校验我建议项目里开启 CRC 并且用 CRC8 或 CRC16看数据量大小。不校验的话Flash 里读出脏数据后应用直接采用后果很严重。Fee 层有几个参数要关注FeeBlockNumber、FeeBlockSize、FeeNumberOfWriteCycles 等。Fee 使用分页管理删除、写入扇区都有固定开销如果你的数据块特别小Flash 磨损会集中在几个扇区老化速度不均匀。我遇到过一个问题某个数据块每秒写一次两个月后 Flash 扇区被擦穿数据反复丢失。后来想了两个办法降低 NvM 写频率由秒级改为条件触发或者把块分配到 Fee 的不同区域以平衡磨损项目上最后选了前者改动最少问题解决。3.2 AUTOSAR 网络管理状态机不是你想的那样网络管理Network Management简称 NM是整车睡眠唤醒机制的核心。AUTOSAR 的 NM 不是总线层面的硬件唤醒它通过周期性报文来协调各个 ECU 的休眠时机。AUTOSAR NM 的核心是状态机一共四种状态Bus-Sleep Mode、Prepare Bus-Sleep Mode、Network Mode、Partial Network Mode。Network Mode 下面又分 Repeat Message State、Normal Operation State、Ready Sleep State 三个子状态。状态机的流转逻辑ECU 从 Bus-Sleep 被总线报文或本地事件唤醒进入 Network Mode先发 Repeat Message一段持续重复 NM 报文的阶段告诉其他节点我醒了然后进入 Normal Operation周期发送 NM 报文以保持网络活跃当所有节点都进入 Ready Sleep 状态并满足一定时间条件网络回到 Bus-Sleep。实际开发中最容易出问题的就是谁先睡、谁后睡的协调。AUTOSAR 的机制是每个 ECU 在满足自身休眠条件后发送 NM 报文并设置 Sleep Indication 位当总线上所有节点都声明可以睡了网络才能真的睡。如果你的 ECU 不响应其他节点的睡眠请求或者自己的 NM 报文周期和相位有问题整车网络就会一直处于唤醒状态静态电流居高不下。这个问题在整车厂路试时是必测项目被挂过不少项目。配置 NM 时最关键的几个参数是 NM 报文 ID一般在 0x500 范围内、报文周期典型值为 100ms、500ms、Repeat Message 次数和时间通常配置为 3~5 次总时长 500ms~1s、以及唤醒源列表NM 报文 ID、CAN 帧接收等。还有一个容易漏掉的配置NM 报文的 PDU ID 要和 CanIf 的接收 PDU 映射一致少了这条映射NM 报文根本收不到状态机永远卡在 Bus-Sleep。NM 模块在 DaVinci 里配置的时候我建议先把 NmCluster 和 NmNode 的关系理清。一个控制器可能同时挂在多个网络比如动力 CAN 和车身 CAN每个网络对应一个 NmCluster每个节点有自己的 NM Type比如 Passive被动或者 Active主动。Active 节点参与协商Passive 节点只监听不参与。配置成 Passive 后节点不会发 NM 报文也就不会阻碍网络睡眠。某些从节点把 NM Type 配错成 Active会导致睡眠流程永远协商不成功这个问题在 BCM、Gateway 项目中非常常见。4. DaVinci Configurator 配置手册SWC 接口与 RTE 避坑4.1 SWC 接口配置Port、Interface 与 Data MappingDaVinci Configurator 是 Vector 家的王牌工具它在 AUTOSAR 项目里做的活主要是两块BSW 模块配置和 SWC/RTE 配置。配置 SWC 接口时核心概念是 Port、PortInterface 和 Data Mapping 三层结构。先有一个感性认识。你在 Simulink 里建模型时模型的输入输出端口将来都会变成 SWC 的 Port而 Port 的类型由 PortInterface 决定。比如一个车速信号需要一个 SenderReceiverInterface定义 PPort提供端口和 RPort需求端口然后在这个接口里定义数据元素 DataElement比如 VehicleSpeed类型选 UInt16 或 Float32。完成这一步之后还要用 Data Mapping 把这个 DataElement 映射到 COM 模块的某个信号上RTE 生成代码时SWC 的读写接口才会真正和通信栈接上。这一步流程看着简单实际项目里最烦的是接口数量和命名规范。一个车身控制器SWC 接口几十上百个是常态如果命名不规范后面 RTE 生成的函数名会让你怀疑人生。我推荐在创建接口前先定一套命名规则接口用 IF_ 前缀数据元素用 Sig_ 前缀Port 用 PPort/RPort 加模块名缩写。别嫌麻烦等到你需要维护上百号接口的时候这套命名规则能救你命。4.2 RTE 生成避坑指南冲突、遗漏与数据类型RTE 是连接 SWC 和 BSW 的桥梁它由 DaVinci 自动生成但是自动不等于没坑。最常见的坑是 RTE 生成时报 Unresolved Reference 错误。这类错误九成以上来自组件间的接口映射没有配对。你定义了端口但没有在装配图Assembly Connector里把两个组件连起来RTE 找不到映射关系自然生成失败。排错时别去翻复杂的代码先在 DaVinci 的 RTE 视图里检查所有组件的连接线是否完整。第二个坑是数据类型不匹配。CAN 矩阵里车速可能是 UInt16但你 SWC 里定义的 DataElement 是 Float32。RTE 生成时不会帮你做隐式转换它只是把两个类型硬接上运行时数据就会错乱。我见过一个实际案例发动机水温报文读出 150仪表显示 -106查找了半天最后发现是信号定义在 COM 里为 UInt8但 SWC 变量是 SInt8符号位被当作数值位使用了。检查方式很简单看生成的 Rte_Read_xxx 函数确认它调用的最终信号类型和你 Simulink 模型的端口类型一致。第三个坑是 Runnable 的执行周期设置。你在 DaVinci 里给 SWC 的 Runnable 配置了 Periodic Trigger周期是 10ms但你看代码发现 Runnable 在一个 100ms 的 Task 里被调用10ms 的周期形同虚设。RTE 的调度精度由 OS Task 周期决定Runnable 必须被映射到合适的 Task 里才能按预期执行。映射不对轻则逻辑滞后重则数据竞争。配置 Runnable 时要同时检查 DaVinci 的 Task Mapping 和 OS 的 Task 周期保证逻辑正确。4.3 ECUC 模块配置参数从哪里来到哪里去ECUCECU Configuration是 AUTOSAR 所有模块配置的参数容器每个模块都有自己的 ECUC 参数定义比如 CanIf 的 CanIfTxPdu、NvM 的 NvMBlockDescriptor、Dcm 的 DcmDslProtocol 等。你用的工具不管是 DaVinci 还是 EB本质上就是一个图形化的 ECUC 配置编辑器。很多工程师理解不了配置到底在配置什么用 ECUC 的概念解释就清楚了你在界面里改动一个参数比如 CanIf 的 CanIfTxPduCanId 改成 0x1A0这个参数会存储到一个 .arxml 配置文件里生成代码时配置生成器比如 DaVinci 的 Generator会把这个参数写入生成的 CanIf_Cfg.c 和 CanIf_Cfg.h 文件中形成常量或数据结构。运行时的代码通过引用这些配置常量实现不同的行为。因此ECUC 配置的核心在于引用关系。比如你配置了一个 NvMBlockDescriptor其中的 NvMFeeBlockNumber 参数必须对应 Fee 模块中存在的块号。这类跨模块引用关系是配置错误的高发区。排查时DaVinci 的 Validation 功能会报一致性错误但有时给出的提示非常泛泛。我的经验是在开始写功能代码之前先跑一遍完整的配置生成流程确保 0 错误这是最容易提前消化问题的方式。不要带着 Validation 警告去写代码等集成调试时会一起爆雷。5. 常见问题排查与实战心得5.1 高频问题速查表从现象到根因我把实际项目中遇到的高频问题整理成一个速查表。这个表是我给团队做培训时的素材也是排查问题时优先对照的清单。现象可能根因排查方法报文不发送/不接收CanIf 的 PDU ID 映射错误、Can Controller 未初始化检查 CanIfTxPduCanId/CanIfRxPduCanId、用 CANoe 看硬件层面是否有错误帧信号值变成默认值COM 信号映射未配置或 RTE 数据类型不匹配查看 Rte_Read 函数最终读取的信号对比 Canoe 解析的信号值诊断超时无响应CanTp 的接收窗口或超时参数异常、Dcm 未配置 0x22/0x2E 服务抓取总线报文确认帧是否分片完整检查 CanTp 的 N_As、N_Cr 参数NVM 写回失败Fee 块未映射、NvM 写周期过短、掉电时序不对查看 Dem 事件码或 NVM 内部错误码检查 Fee 的块编号与 NvM 配置控制器无法休眠NM 报文 Repeat 时间过长、状态机未进入 Ready Sleep抓 NM 报文检查某一节点是否持续处于 Normal Operation任务跑飞 / 抢占错乱OS Task 优先级或 ScheduleTable 配置不当用 Lauterbach/Lauterbach Trace 抓任务执行序列这张表对应的问题我基本都亲自排查过一遍。通信类问题最多的是配置漏配或错配而存储类问题则更多的是代码逻辑没有遵循 NVM 的异步模型。NvM 的写进并不保证立刻持久化你调用 NvM_Write 后要等待 NvM 的回调或者查询状态。不少项目因为没有做写完成的等待连续写结果数据丢失。记住这句话NvM 是异步服务不是同步函数。5.2 避坑技巧EB tresos 还是 DaVinci以及配置管理工具链稳定之后配置管理就成为新的隐患。AUTOSAR 的配置全部保存在 .arxml 文件里多人协作时 merge 冲突是家常便饭。如果在开发初期没有建立严格的配置管理流程后面几乎必然出事。我的建议是除了用 Git 管理 .arxml 之外还要有配置变更记录的意识。每个模块的配置改动都要写清改动原因、影响范围、关联需求。一个配置项改错往往要很久之后才爆雷没有变更记录排错如同大海捞针。DaVinci 和 EB tresos 还涉及生成代码的覆盖问题。这两款工具在重新生成代码时某些安全关键配置会被重置或覆盖。我见过一个项目EB 生成代码后之前的 CanIf 保留代码被整体覆盖导致车辆批量下线后 CAN 通信失效。避免方法是把手工修改的代码严格放在工具指定的用户代码保护区并在生成步骤前后用版本差异对比工具检查。生成前做一次代码快照生成后 diff 一遍这种习惯能堵住九成以上的低级覆盖事故。5.3 调试技巧从 BSW 到 RTE 的日志追踪法调试 BSW 问题最怕的是黑盒式乱猜。我调试时有个固定套路先定位数据在哪个模块断了然后再查配置。具体方法是分层打日志。比如应用层调 Com_SendSignal如果 CANoe 上没看到预期报文那么问题可能出现在 RTE - Com - PduR - CanIf - Can 的任何一个环节。我可以在关键函数的入口和出口加调试打印但要小心在最终发布版本中去掉或者用条件编译控制。如果硬件跟踪设备允许比如 Lauterbach我可以直接在 OsTask 里看各模块的调用序列不用打日志。在 AUTOSAR 里跨模块调用的顺序是可以通过查看函数调用栈确定。通信发送路径的顺序通常是 Rte_Write - Com_SendSignal - PduR_ComTransmit - CanIf_Transmit - Can_Write。如果某个环节没有执行到问题就锁定在这一层以及它的配置。诊断路径的调试更复杂。Dcm 收到诊断请求后会按软件服务、安全等级、会话状态逐层过滤。我调试 0x28 服务失败时先确认 Dcm 配置里打开了 CommunicationControl 服务然后确认 Dcm 在非默认会话下允许该服务最后验证该服务的安全等级是否为无限制。任何一个条件不满足Dcm 都返回负响应且总线报文里只看到 NRC。硬件调试器的优势在于你可以直接看 DcmDslProtocol 的状态变量比肉眼分析报文快得多。5.4 最后的几个心得从入门到能独立负责写了这么多最后聊点干活之外的经验。第一个心得不要把 AUTOSAR 想得太玄。它就是个极其啰嗦但逻辑清晰的架构所有模块的相互作用都能在规范文档里找到答案。遇到问题先查文档AUTOSAR 规范虽然厚但每个模块的 SWSSoftware Specification文档结构非常统一建议先把 Changelog 和 Introduction 读了再跳到你要用的章节。第二个心得一定要学会用配置工具的 Validation 功能但也别完全依赖它。Validation 能发现结构错误但发现不了逻辑错误。比如 PDU 周期设成 0ms工具不会报错但运行时负载异常。逻辑正确性要靠你自己的报文矩阵和时序计算来判断工具只是辅助。第三个心得项目初期就把所有模块的接口清单整理出来。从应用层需要哪些信号到 COM 的哪个 I-PDU再到 CanIf 的哪个硬件对象一层一层列清楚。这个清单不仅是配置的依据也是排错时的地图。我做过印象最深的排查被问题折磨了三周最后靠这个清单发现 CanIf 把手刹状态和门锁状态两个信号的硬件对象搞反了一个字节的问题清单一对照立即找到。开发 BSW 没有捷径但有方法。先把链路摸清再逐层深入配合文档和工具链的节奏大多数人半年左右就能独立负责一个控制器的 BSW 集成。希望这篇笔记能让你少走一些弯路特别是通信、存储和配置这三块值得你多花时间。