3. 供应商协作模式：Tier1与Tier2的角色分工、协作流程与知识产权要点
做AUTOSAR方案这么多年，我最大的感触就是：技术问题往往不是最难的，最难的是把人、流程和权责理清楚。尤其是当你面对Tier1和Tier2的协作时，一个不小心，项目就可能卡在“谁该做什么”的扯皮上。
今天咱们就聊聊这个实战中绕不开的话题。我个人习惯把供应商协作比作“搭积木”——Tier1是那个搭积木的人，Tier2是提供积木块的厂商。但现实远比这个复杂，因为积木块之间还有接口、有协议、有知识产权。
3.1 Tier1与Tier2的角色分工：谁该做什么？
先明确一个基本概念。在AUTOSAR生态里，Tier1和Tier2的分工不是一成不变的，但大体上有个约定俗成的边界。
| 角色 | 核心职责 | 典型交付物 |
|---|---|---|
| Tier1（一级供应商） | 系统集成、ECU开发、整车适配 | 集成后的BSW、RTE、SWC、诊断栈、通信栈 |
| Tier2（二级供应商） | 提供基础软件模块、MCAL、OS、协议栈 | 独立的AUTOSAR模块（如CanStack、EthernetStack）、MCAL驱动、配置工具 |
Tier1 说白了就是“总包方”。他们拿到OEM的需求，负责把整个ECU的软件架构搭起来。我见过不少Tier1的工程师，他们最头疼的不是写代码，而是怎么把Tier2给的模块“拼”到一起。因为每个Tier2的模块都有自己的配置方式和接口习惯，整合起来相当费劲。
Tier2 则是“专业户”。他们专注于某个领域，比如Vector的CanStack、EB的OS、Infineon的MCAL。Tier2的交付物通常是经过认证的、可配置的二进制或源码包。嗯，这里要注意，Tier2一般不关心你的整车网络是怎么设计的，他们只保证自己的模块在标准环境下能跑通。
我的经验： 有一次项目里，Tier2交付的MCAL驱动在单核上跑得好好的，但一上多核就出问题。Tier1说是Tier2的驱动有bug，Tier2说是Tier1的核间通信配置不对。最后两边扯了两个月，才发现是Tier1的RTE配置里，把中断优先级设错了。所以，分工明确不等于责任明确，接口处的灰色地带才是真正的坑。
3.2 协作流程：从RFQ到交付物
协作流程一般分三个阶段：RFQ（询价）→ SOW（工作说明书）→ 交付物验收。每个阶段都有它的门道。
3.2.1 RFQ阶段：别只盯着价格
RFQ阶段，OEM或Tier1会向多个Tier2发出询价。很多人觉得RFQ就是比价格，其实不然。我建议在RFQ里至少明确三件事：
- 技术范围： 你到底需要哪些AUTOSAR模块？是只要CanStack，还是连Ethernet、SecOC都要？
- 配置自由度： Tier2提供的模块是“黑盒”还是“灰盒”？你能改多少参数？
- 支持力度： Tier2提供多少小时的技术支持？是邮件支持还是现场支持？
我曾经见过一个项目，RFQ阶段只写了“需要AUTOSAR BSW”，结果Tier2报了个低价，交付时才发现他们只提供了最基础的模块，连诊断栈都没有。最后Tier1只能自己补，工期直接翻倍。
3.2.2 SOW阶段：把话说死
SOW是整个协作的“宪法”。我个人习惯在SOW里把以下内容写死：
- 功能清单： 每个模块必须支持哪些功能（比如CanStack要支持CAN FD、支持PDU多路复用）。
- 配置接口： Tier2提供什么样的配置工具？是独立的GUI，还是基于Excel的导入导出？
- 集成测试： Tier2需要提供哪些测试用例？测试覆盖率要达到多少？
- 交付物清单： 源码、文档、测试报告、配置工具，一个都不能少。
避坑指南： 我曾经在SOW里没写清楚“交付物格式”，结果Tier2给了个Linux下的编译环境，而我们用的是Windows。最后花了两周时间搭交叉编译环境。所以，交付物的平台兼容性一定要在SOW里写清楚。
3.2.3 交付物验收：别等到最后才看
交付物验收是很多项目容易忽视的环节。很多人觉得“Tier2是大厂，交付物肯定没问题”。但我的经验是，验收一定要分阶段进行：
- 单元验收： Tier2交付单个模块后，先跑一遍他们提供的测试用例。别急着集成。
- 集成验收： 把Tier2的模块集成到你的BSW里，跑一遍集成测试。这时候最容易发现接口不匹配的问题。
- 系统验收： 在目标硬件上跑完整的ECU软件，验证性能、时序、内存占用。
你想想看，如果等到项目快结束了才发现Tier2的模块有bug，那返工的成本可就高了。我一般会在SOW里约定：每个验收阶段都有明确的通过标准，不通过就退回，Tier2承担修改成本。
3.3 知识产权与保密协议要点
知识产权这块，说实话，是供应商协作里最容易“翻脸”的地方。AUTOSAR本身是开源的，但Tier2的模块往往是他们的商业机密。所以，知识产权和保密协议必须提前谈好。
3.3.1 知识产权的归属
一般来说，Tier2交付的模块，其知识产权归Tier2所有。但Tier1或OEM在使用过程中产生的衍生代码（比如基于Tier2的模块做的配置、修改、扩展），其知识产权归属需要明确。
我建议在协议里写清楚：
- 背景知识产权： Tier2原有的模块代码，归Tier2所有。
- 前景知识产权： Tier1在集成过程中产生的配置代码、适配代码、测试代码，归Tier1所有。
- 改进型知识产权： 如果Tier1对Tier2的模块做了修改，修改部分的知识产权归Tier1，但Tier2有权在自己的产品中使用这些修改（通常需要付费或交叉授权）。
注意： 有一次项目里，Tier1的工程师为了修复一个bug，直接改了Tier2的源码。结果项目结束后，Tier2说“你改了我的代码，这部分代码的知识产权应该归我”。最后打了好久的官司。所以，尽量不要直接修改Tier2的源码，而是通过配置或封装层来解决。如果非要改，一定要在协议里约定好归属。
3.3.2 保密协议的要点
保密协议（NDA）是供应商协作的“标配”。但很多NDA写得过于宽泛，导致执行起来很困难。我个人觉得，NDA里至少要明确以下几点：
- 保密范围： 哪些信息属于保密信息？是所有的技术文档、源码、配置，还是只限于特定的模块？
- 保密期限： 保密义务持续多久？一般是项目结束后3-5年。
- 例外情况： 哪些信息不属于保密范围？比如公开信息、独立开发的信息、从第三方合法获取的信息。
- 违约责任： 如果一方泄露了保密信息，赔偿金额怎么算？是按实际损失，还是按约定的违约金？
举个例子，我见过一个NDA里写“所有技术信息均为保密信息”，结果Tier1的工程师在技术论坛上问了一个关于AUTOSAR配置的问题，Tier2就说“你泄露了我们的技术信息”。最后发现，那个问题其实在AUTOSAR官方文档里就有答案。所以，保密范围一定要具体，别搞“一刀切”。
3.4 实战中的协作建议
说了这么多，最后给几条实战建议：
- 建立沟通机制： 每周一次技术对齐会，Tier1和Tier2的工程师直接对话，别让项目经理传话。
- 使用版本管理： 所有交付物都要有版本号，Tier2的模块更新时，要提供变更日志。
- 预留缓冲时间： 供应商协作中，接口问题、配置问题、bug修复，都会消耗时间。我一般会在项目计划里预留20%的缓冲时间。
- 做好备份： 如果Tier2的模块是二进制交付，一定要备份好源码和配置工具。万一Tier2倒闭了，你还能自己维护。
好了，关于供应商协作模式，今天就聊到这儿。说白了，协作的核心就是把丑话说在前头，把责任划清楚，把流程走扎实。下次咱们聊聊AUTOSAR的配置工具链，那个也是个大坑。