热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署

课程大纲

• 能把一份控制软件交付按六档形态谱定档，并说清该档下 OEM 的可改动空间、调试可见度、工具链许可依赖与「改一处」的再验证范围与周期代价
• 能按 DIA（开发接口协议）体例把活动与工作产物在 OEM/Tier1 之间逐条分派，并指出哪些条目一旦不分派就会让安全工作产物与缺陷责任落缝
• 能读懂并写出一份 SEooC 的 AoU（使用假设）清单，逐条判定假设在本车型上是否成立，并在不成立时给出处置动作与责任归属判据
• 能区分 ISO 26262-2 的三类确认措施（确认评审／功能安全审核／功能安全评估），判断某项签署需要哪一档组织独立性，即「谁有资格签」
• 能填出一张跨企业权限矩阵——对外 A2L 裁剪范围、标定量授权等级、SecurityAccess 等级、诊断例程白名单——每栏标明发给谁、有效期、撤销条件与撤销的技术验证方法
• 能定出联合验证的分工与放行签署链：台架归属、用例来源、通过判据编写方、证据包互认三档与抽样复测规则，并说清签署点如何改变缺陷与保修责任归属
• 能在 AUTOSAR 分层图上画出自研/外包切点，说明该切法下换供应商的可行层级，并列出二供导入所需交付物与退出成本清单

1. 控制软件交付物形态谱：六档，以及每一档要付的代价
   • 六档形态按「可改动→不可改动」排序：源码 / 目标码（obj+lib）/ Simulink 受保护模型 / FMU / 完整 AUTOSAR SWC+ARXML / 纯 hex+A2L。定档不是商务偏好而是第一变量——形态一定，后面四讲的权限、验证与退出成本条款就基本被定死了
   • 每一档按六列打分：OEM 可改动空间（能不能改一行逻辑）、可否插入自有监控与诊断（能不能加一路合理性校验或一条 DTC）、调试可见度（能不能设断点、看内部变量、拿到符号与映射）、集成所需工具链与许可证依赖（对方的编译器版本、模型保护许可、ARXML 工具链）、改一处的再验证范围与周期代价、IP 保护强度与二供导入可行性
   • 判据一（可见度）：目标码与受保护模型看着能集成，但内部变量在 A2L 与调试器里都不可见，偶发问题只能退回对方复现，故障定位从「以天计」变成「以发布轮次计」；接受这一档的前提是先把可观测量清单——对方必须导出哪些内部量到 A2L 或诊断 DID——写进交付要求，事后要不到
   • 判据二（节奏）：纯 hex+A2L 是完全不可改档，OEM 只剩标定这一根杠杆，任何逻辑变更都是对方的一次完整发布，项目节奏被对方排期锁死；这一档必须在定点前谈死变更响应时限与最小发布批量（条款怎么写归 Q2-02，本课只给「必须谈」的技术理由）
   • 判据三（可插入性）：能不能在交付件之外插入自有监控与诊断，决定了 OEM 还有没有独立的安全兜底手段；受保护模型与 hex 档下，监控只能加在件的外部信号侧，其检出延迟必须重新对照危害时间预算核算（监控器的规格化要求见 K2-05）
   • 混合形态是实务常态：算法核心走受保护模型或目标码、外层调度与接口走源码，或「OEM 上层策略 + Tier1 BSW 与执行器驱动」。混合交付必须逐模块定档；一份清单里出现两档以上时，再验证范围按最不可见的那一档取，不许按平均取
   • 交付形态标识不是一个字段而是一组四项：形态档 + 随件可标定量清单及其授权等级 + 验证证据包（覆盖率／HIL 报告／安全分析工作产物）+ 该形态下 OEM 可改动范围的声明；四项缺一项，K4-04 的发布件完整性清单在跨企业场景就验不住（发布件构成本体归 K4-04，本课只补跨企业这四项的判据）
   • 与 J7-07 第 5 讲的分界写死：那门讲 CAE 模型的 FMU 黑箱交付与脱敏，对象不上车、不进 ECU；本课的 FMU 档指的是上车件的交付载体。两门对象不同，交付清单与验收判据都不通用
2. ISO 26262-8 的 DIA 与 SEooC：把「责任怎么划」从经验谈变成有依据的方法
   • DIA（开发接口协议）解决的是同一条安全生命周期被公司边界切开之后谁做哪一段，它的条目构成＝活动与工作产物在双方之间的逐条分派 + 每条的里程碑 + 证据交换清单（谁在哪个节点把哪份工作产物交给谁）+ 确认措施由谁执行；四栏缺任一栏，落缝的就是那一栏
   • DIA 必须与 ICD 同时冻结：ICD 只冻信号与接口，安全工作产物的归属不在 ICD 里，只冻 ICD 会让安全工作产物落缝——这条定位 M1-02 已写明，本讲给的是分派表本身怎么填
   • SEooC 是「带假设的安全元素外部交付」：Tier1 在不掌握具体整车安全目标的前提下先按自设假设做出件来，随件交付三件——安全手册、假设条件（AoU）清单、安全分析工作产物；只收到件和一份报告、没收到 AoU 清单，这件东西在本车型上的 ASIL 主张就无从校验
   • AoU 的写法判据是「可判真伪」：要写成「整车侧提供 X 信号且其失效行为为 Y」「本件承接的安全目标不高于 ASIL Z」「上游有 W 机制承担 V 类失效」这类能落到具体承担方、生效工况与失效行为的句子；写成「整车应合理使用」「上游应保证信号可靠」这类不可判定句，等于没写
   • OEM 侧的回验动作要落成表：每条 AoU 标「本车型成立／不成立／部分成立」，不成立的必须给处置（补整车侧机制 / 改需求 / 让对方重做分析），并记录回验人与回验证据；未回验的 AoU 是安全案例里最典型的空洞——件在、报告在、结论悬空
   • 假设不成立时的责任归属三条判据：假设写清且 OEM 未回验 → 责任在 OEM；假设未写或写成不可判定句 → 责任在交付方；假设写清、回验通过、实车仍失效 → 回到失效分析走 CR。索赔口径与商务后果归 Q2-02、M2-05，本讲只给技术归属判据
   • ISO 26262-2 的确认措施回答的是「谁有资格签」，与安全机制通道的物理/功能独立是同形异义的两件事（辨析已在 K2-03 写明）。三类措施对象不同、不能互相顶替：确认评审针对工作产物本身、功能安全审核针对流程是否被执行、功能安全评估针对最终的安全达成度
   • 确认措施的组织独立性沿「同项目他人 → 不同团队／不属同一直线上级 → 不同部门或外部组织」逐级提高，档次随 ASIL 升高；哪一项措施在哪个 ASIL 上要求哪一档，按 ISO 26262-2 现行版本的对应表逐格确认，不得凭印象填（讲义阶段查原文补全）
   • 跨企业时确认措施的落法必须在 DIA 里点名：由 OEM 做、由 Tier1 做、还是双方各做一份并互认。漏了这一条，典型结局是「双方都以为对方在做功能安全评估」，到评估节点才发现无人执行
   • 与 K2-05／I7-03 的接口：SOTIF/AI 侧的 safety case 与 26262 侧必须互链而不是各写一套；跨企业开发时两侧证据分散在两家公司，把它们拼起来靠的就是本讲的证据交换清单与互认规则——互链要求的本体归 K2-05 与 I7-03，本课只给拼装规则
   • 本讲不重讲 HARA/ASIL/TSR/安全机制与 Safety Case 本体（归 K2-03），不重讲机械与结构件承接安全要求的三条路径（归 I7-03），只用 ISO 26262-8 的分布式开发接口这一段
3. 跨企业权限分级与钥匙分发：发什么、发给谁、怎么收回
   • 对外 A2L 不等于内部全量，裁剪按两条判据逐量落「发／不发」：安全等级（安全相关量能不能让外部改）与商业敏感度（该量是否暴露了算法结构）。裁剪版与内部全量之间的版本对应关系归 K6-05，本讲只管发给谁、发到哪一级、怎么撤
   • 标定量按角色分授权：Tier1 / 第三方标定商 / 产线 / 售后各拿哪一档可标性（只读 / 可标 / 需授权可标 / 不可标写保护）；可标性等级的字段口径引 K6-10，本讲不重讲标定量规格表本身
   • SecurityAccess 的等级分发本质是跨企业问题而不是内部问题：哪一级钥匙给 Tier1、哪一级给第三方标定商、哪一级只留售后。0x27 机制本体与种子-密钥算法强度归 K5-01 与 K2-04，本讲只讲分发、托管与撤销
   • 种子-密钥托管的三条硬条款：一车一密还是全车系通用（通用即等于没发钥匙——K2-04 案例里的「算法可从刷写工具逆向」就是现成后果）、密钥托管方与交付介质、以及合同终止或人员离职后的撤销路径与生效时限
   • 撤销必须技术上可执行才算数：只写「授权到期即失效」而没有配套手段（钥匙轮换、工具端授权到期、账号回收、下一版软件换算法）的条款撤销不了；每条授权都要配一条撤销动作与一条撤销验证方法（撤销后拿旧钥匙实测一次进不进得去）
   • 诊断服务与例程的对外白名单要逐条标开放与否，重点是能直接夺取执行器控制权或抑制记录的那几个（点动类、例程类、DTC 记录控制类、通信控制类）；开放的必须带前置条件与退出复位要求——例程本体、整车前置条件与残留位检查归 K5-01 与 K3-01
   • 授权动作必须留痕并可审计：谁在什么时候把哪一级权限发给了哪家的哪个工具或账号、用过几次、什么时候撤的。出问题时这份留痕是责任归属的唯一物证，也是评审时唯一能证明「我们控住了」的东西
   • OTA 参数的远程可改分级、灰度与回滚归 K7-02；本讲只补它那张分级清单的对外授权版三栏——授权给哪家供应商、授权范围、撤销条件
   • 与 K6-05 的责任矩阵咬合：标定量责任矩阵的跨企业版必须与 SecurityAccess 权限等级、对外 A2L 裁剪范围逐条对齐；三张表任意两张对不上，就一定存在一条「名义上不给改、技术上改得动」的量，而这类量从来不会在评审时被发现，只会在售后现场被发现
4. 联合验证的分工与放行签署
   • 四个必须提前定死的分工位：台架归属（OEM 台架 / Tier1 台架 / 第三方）、用例来源（谁出正常、边界与故障注入用例）、通过判据由谁编写、报告由谁签署。热管理域控大量走「Tier1 交台架结论」，这四位不谈清楚，验证证据链就在公司交界处断掉（HIL 台架架构与三关本体见 K4-03，那门只给定位）
   • 用例来源的判据是「需求出自谁，边界与故障注入用例就该由谁出」：OEM 写黑盒功能规格却让 Tier1 自己出用例，等于让被验方定义「验到哪算够」；通过判据必须与规格条款逐条对账，对账这件事本身在 K4-07 已成流程，本讲只管跨企业时它由哪一方执行、对不上时谁改
   • 证据包互认规则写成三档：全认（对方报告直接进本方证据包）／抽样复测后认（定复测比例与选样规则）／必须本方复测（安全相关、整车级、以及本方独有工况）。分档依据＝该证据支持的主张等级 + 该项在本方台架上的可复现性
   • 抽样复测比例不能拍：按证据的失效后果与对方的历史一致性分档，并且必须写清「复测结果不一致怎么办」——升档、全量复测、还是退回重出报告。没有不一致处置条款的抽样条款等于走过场
   • 放行签署落成一张可执行的签署表：谁提出、谁独立复核、谁最终批准、批准所依据的证据包清单、批准的有效期与失效条件；安全相关件的复核独立性档次按第 2 讲的确认措施取。标定口径的整车级验收签署归 K6-04，SOTIF/AI 侧要额外加签的行归 K2-05，本讲只管跨企业这一层
   • 签字改变责任：签署前缺陷责任按 DIA 分派与 AoU 回验结论走，签署后本方即承接了「这份证据足以支持放行」这一判断——所以拒签的成本远低于签完再追责，评审席上说不清的项应当挂起，而不是先签后补
   • 保修与索赔归属随签署点移动：某个缺陷仍算供应商责任还是落到本方，取决于它是否落在已互认的证据覆盖范围内。商务与索赔口径归 Q2-02 与 M2-05，本讲只给「证据覆盖范围」这条技术分界线
   • 跨企业侧的回归要求：对方交的回归报告必须能说清跑的是哪一档回归范围、基线是哪一版、哪些用例因何被裁掉；回归范围裁剪判据与失败分诊本体归 K4-08，本讲只要求这些在证据包里可追溯——不可追溯的回归报告不进证据包
5. AUTOSAR 分层上的自研/外包切分与退出成本
   • 以 K4-01 的 MCAL/BSW/RTE/SWC/标定层分层图为底图，逐层给「谁做」的判据：K4-01 只讲分层不讲分工，本讲补的正是分工线画在哪一层，以及画在那一层意味着什么
   • 切在 RTE 层与切在 SWC 层是两种命：RTE 层切（对方交完整 BSW+RTE、OEM 写 SWC）换 BSW 供应商仍要重做集成与配置，但控制策略资产能整体搬走；SWC 层切（策略 SWC 也由对方交）则策略资产在对方手里，换供应商约等于重写功能
   • 一句话判据：接口切在哪一层，你就只能在那一层以上换得动供应商——切点以下的一切在换供应商时都要重做。这条判据要在定点前用，不是在想换的时候才用
   • 控制策略与基础软件能否分家，看三条：策略侧对 BSW 的依赖是否已收敛到标准接口（对复杂驱动、非标 I/O、私有诊断扩展的依赖越多越分不开）、时序与任务周期约定是否在接口上显式化（周期与响应时间的核算方法见 K4-01）、标定量是否随策略一起搬得走
   • 二供导入所需交付物清单：形态定档件本身、接口与配置（ARXML、工具链与许可版本）、标定量规格表与当前基线、验证证据包与用例集、AoU 与安全分析工作产物。这份清单必须在一供项目里就写进交付要求——等到要换供应商时再要，基本要不到
   • 退出/迁移成本预先估成一张表：重新集成与配置的工时、要重跑哪一档验证（对应第 4 讲——哪些证据能继承、哪些必须重出）、标定是否要重来（轴点或量纲不一致即重来）、诊断与售后资产（DTC 清单、症状树、专用工具）的重做量、以及一次完整发布轮次带来的节奏损失
   • 战略层的自研/外购三判据（是不是差异化竞争点、能不能养住这支队伍、供应风险多大）与 RASIC 一律引 A5-03 讲义 §4.3/§4.4，只引一句不展开；本讲给的是工程判据，回答「这条线切在哪一层」而不是「要不要自研」
   • 本讲显式对标 B3-05 讲义 §5.3/§5.4 的硬件版论证——「架构定义权不能整包交出去、平台会被锁死」以及接口/性能/失效三份责任边界文档（谁写谁验谁签字）——并声明这是它的软件版：不重述硬件版论证，只把同一条道理落到分层切点与退出成本上
   • 产业侧的议价权与商业模式判断（谁卖带软件的总成、谁只卖裸执行器）归 N5-02；算法与标定数据的 IP 权属、许可范围与终止后权利归 M5-05。本讲只到工程切分与成本清单为止，不进商业模式与合同文本

• 以为拿到 hex+A2L 就算「拿到了软件」——其实那一档下 OEM 只剩标定这一根杠杆，任何一行逻辑变更都要走对方的一次完整发布，项目节奏被对方排期锁死
• 以为受保护模型或目标码「能集成就够了」——其实内部变量在 A2L 与调试器里都不可见，偶发问题只能退回对方复现；不在交付要求里先写死可观测量清单，事后要不到
• 以为 ICD 冻结了接口就冻结了责任——其实功能安全的工作产物归属不在 ICD 里，要靠 DIA 逐条分派；只冻 ICD，安全工作产物必然落缝
• 以为 SEooC 件「随件有报告就行」——其实缺了 AoU 清单（以及安全手册与安全分析工作产物这三件里的任一件），它的 ASIL 主张在本车型上无从校验，那份报告证明不了任何事
• 以为 AoU 写了就算数——其实未经 OEM 逐条回验的假设是安全案例里最典型的空洞；而且写成「整车应合理使用」这类不可判定句时，责任反而回到交付方，写得越含糊对交付方越不利
• 以为 ISO 26262 里的「独立性」是一件事——其实是两件：安全机制通道的物理/功能独立（防共因失效）与确认措施的组织独立（谁有资格签）；混谈会推出「通道已分开所以可以自己签」这种荒谬结论
• 以为确认措施三类可以互相顶替——其实确认评审查工作产物、功能安全审核查流程是否被执行、功能安全评估查最终安全达成度，对象不同，做了其中一项不等于另两项也过了
• 以为发了对外裁剪版 A2L 就控制住了改动范围——其实标定量责任矩阵、SecurityAccess 等级、A2L 裁剪范围三张表只要有一处对不上，就存在「名义上不给改、技术上改得动」的量，这类量从不在评审时暴露、只在售后现场暴露
• 以为写上「授权到期自动失效」就算撤销条款——其实没有钥匙轮换、工具端授权到期、账号回收之类的技术手段，撤销在工程上执行不了；每条授权都要配撤销动作与撤销验证方法
• 以为「对方的 HIL 报告我们抽查一下就行」——其实不写「抽样复测结果不一致怎么办」的抽样条款等于走过场，不一致时既没有升档规则也没有退回机制
• 以为签字只是流程动作——其实签署点就是责任转移点，签完即承接了「证据足以支持放行」这一判断；评审席上说不清的项应当挂起，而不是先签后补
• 以为「以后想换供应商时再谈交付物」——其实二供导入所需的那套交付物（配置与工具链、标定基线、用例集、AoU 与安全分析产物）必须在一供项目里就写进交付要求，要换的时候再要基本要不到
• 以为把集成责任整包给 Tier1 只是分工选择——其实切点定在哪一层就决定了以后只能在那一层以上换得动供应商，切点以下的一切在换供应商时全部重做（硬件版的同一论证见 B3-05）

需求区 · 想听众筹

想听/点名均为需求登记，不涉及任何付款（意向金仅登记不收款）。满 5 人点名 → 自动向平台专家发邀约。