一辆车从“有个想法”到“供应商能照着图纸把零件造出来”中间隔着的不只是时间还有一整套需求文档的逐层翻译。我刚入行的时候产品经理扔给我一句“我们要做个自动紧急刹车50km/h以下要能刹停”我第一反应是“这不很简单吗”结果真正上手后发现这句话要变成 PRD再从 PRD 拆成 SSTS最后落到 CTS每一步都有无数细节会被放大。这篇文章不聊虚的直接手把手拆一个典型功能把这三份文档的关系、写法、常见坑讲清楚。不管你是刚接触汽车电子开发的需求工程师、测试工程师还是想了解整车开发流程的软件/硬件工程师这篇内容都能帮你少走弯路。1. PRD、SSTS、CTS 三种文档一张表看懂分工1.1 汽车功能开发的文档金字塔在汽车电子产品开发里PRD、SSTS、CTS 是三个层级非常分明的文档它们的关系就像一个金字塔。PRDProduct Requirements Document是产品需求文档回答“用户要什么”。它描述的是一个功能在整车层面的表现比如“车辆低速行驶时如果前方有障碍物或车辆系统应能自动制动以避免碰撞”。这个文档通常由产品经理或系统需求工程师牵头写核心读者是项目组、系统工程师、测试负责人。SSTSSystem Specification and Test Specification是系统规格与测试规格回答“系统怎么做到”。它把一个 PRD 功能拆解成若干条可量化的系统需求并且为每条需求配套对应的系统级测试方法。比如“系统应在前方目标相对距离小于某个阈值时发出制动请求”“制动减速度应大于多少”等。这个文档通常由系统工程师编写核心读者是软硬件开发团队、测试团队、以及下游的零件供应商。CTSComponent Technical Specification是零部件技术规范回答“零件应该长什么样、怎么验证”。它定义了某个具体零件比如雷达、摄像头、制动控制器的功能边界、性能参数、电气接口、机械接口、环境要求、诊断需求以及 DV/PV 实验要求。这个文档通常由零件工程师负责最终交给 Tier1 供应商作为开发依据。文档中文含义核心问题主要编写人主要读者PRD产品需求文档用户要什么产品经理/需求工程师项目、系统、测试SSTS系统规格与测试规格系统怎么做到系统工程师软硬件、测试、供应商CTS零部件技术规范零件怎么做、怎么验零件工程师供应商、采购、质量用一个建房子的类比就特别好懂。PRD 是房主说“我要一套能住的三居室采光要好冬天不能冷”SSTS 是建筑设计师画的整栋楼的施工图、材料清单和验收标准比如“客厅面积不少于 20 平米南向窗户面积不少于 3 平米保温层厚度 80mm”CTS 则是给材料供应商的具体要求比如“这批水泥必须是 PO42.5 标号初凝时间不早于 45 分钟抗压强度 28 天不低于 42.5MPa”。没有中间那层施工图直接告诉水泥厂“我要一栋好房子”供应商根本没法干活。1.2 CTS 别和芯片设计里的 CTS 搞混说个真实存在的尴尬事。我和一位做芯片后端的朋友聊天他说“CTS 不 balance 只解 DRC”我当时愣了半天心想这不是我们刚发给供应商的零部件技术规范吗怎么还能不 balance后来才知道他说的 CTS 是芯片设计里的 Clock Tree Synthesis时钟树综合而 DRC 是 Design Rule Check。在芯片后端流程里时钟树综合除了查 DRC还要关注时钟偏斜skew、latency 这些时序平衡指标所以“只解 DRC 不管 balance”确实是会被吐槽的做法。但在汽车电子需求链里CTS 指的是 Component Technical Specification也就是零部件技术规范。这两种 CTS 八竿子打不着可偏偏缩写一样。如果你在文档里不把全称写出来或者项目内部没有统一术语表跨团队沟通时特别容易鸡同鸭讲。后来我养成了一个习惯第一次在文档中出现 CTS 时一定写全称“Component Technical SpecificationCTS”后面再简称 CTS。同理SSTS 也是第一次出现就写全称。这个细节看起来小但实际项目里因为术语不统一造成的返工并不少见。尤其是当同一家公司既有芯片设计团队又有整车电子团队时开会前最好先确认一下对方说的 CTS 是哪个 CTS。否则你辛辛苦苦准备了一晚上零部件接口参数对方其实想聊时钟树的 balance 问题。1.3 为什么必须从 PRD 到 SSTS 再到 CTS不能跳级我见过最典型的返工案例就是为了赶进度跳过 SSTS直接拿 PRD 去写 CTS。结果呢供应商拿到 CTS 后问了一堆问题这个零件要不要支持 12V 电源跌落控制器放在驾驶室还是发动机舱通信接口是 CAN 还是 LIN需不需要在紧急情况下自动复位这些问题在 PRD 里根本找不到答案而 CTS 里也没写供应商就只能猜。猜来猜去最后做出来的零件和系统需求对不上整个项目返工。原因很简单PRD 是“用户语言”SSTS 是“系统语言”CTS 是“零件语言”。从用户语言直接翻译成零件语言中间少了系统架构、功能分解、接口定义、失效模式分析这些关键环节。每个环节都在做“翻译消歧”跳级等于把这些歧义都丢给了供应商。还有一点特别重要就是可追溯性。每条 CTS 需求要能追溯到 SSTS 里的某一条系统需求每条 SSTS 需求要能追溯到 PRD 里的某一条产品需求。这个链条一旦断裂后面出了问题根本无法定位是哪个需求变了、哪个零件该负责。V 模型开发流程里这个追溯矩阵是质量审核必查项也是出了问题之后迅速找到责任方的关键。2. 从想法到 PRD别急着写功能先写场景和指标2.1 一个合格 PRD 的开头应该是什么很多人写 PRD 喜欢上来就写“我们要做一个自动紧急制动功能”然后就没了。这种文档别说供应商连系统工程师看了都头疼。一个合格的 PRD开头应该包含背景与目标、用户场景、功能需求、性能指标、安全法规约束、验收标准。拿自动紧急制动AEB举例。背景与目标可以写“在城市工况下驾驶员反应不及时导致的追尾事故频发因此需开发 AEB 功能降低低速碰撞风险”。用户场景要写清楚不能只写一个“前方有车”至少包括前方车辆静止、前方车辆匀速行驶、前方车辆减速、行人横穿、雨雾天气等典型场景。性能指标必须量化。比如“在干燥沥青路面上自车以 10km/h 到 80km/h 的速度行驶前方车辆静止时系统应在碰撞前至少 1.5 秒发出制动请求以避免碰撞若无法避免应实现碰撞速度降低 20km/h 以上。” 这种描述才是可以往下拆的。这里有个容易被忽视的点PRD 里的验收标准不是给工程师看的而是给老板和客户看的。它应该用一句话总结“我如何判断这个功能做成功了”。比如“完成 AEB 功能道路测试在验证场景列表中的所有场景下满足上述性能指标。” 这样一旦后面测试不通过项目干系人就可以明确知道是没达到验收标准而不是吵“我感觉已经做得挺好了”。2.2 用“必须、应该、可以”管理优先级顺便喂给 AI写 PRD 需求时我强烈建议每条功能描述都带优先级。可以用 Must必须、Should应该、Could可以三档也可以用 MoSCoW 法。Must 代表没有它功能就不成立比如“系统必须能检测前方车辆并触发制动请求”。Should 是应该有但可以有条件的妥协比如“系统应该能在夜间弱光环境下检测行人如果性能不满足可以要求车速限制在 40km/h 以下”。Could 是锦上添花比如“系统可以支持通过手机 App 查看 AEB 的触发记录”。为什么优先级这么重要因为后续 SSTS 拆需求、测试排优先级、供应商做设计全部要依赖这个优先级。一条 Must 需求如果没有被系统需求覆盖测试阶段就会暴露严重问题一条 Could 需求如果被当成 Must 去实现项目成本和周期都会失控。另外最近很火的“AI 根据 PRD 生成测试用例”也是建立在 PRD 结构足够好的前提下。如果你的 PRD 是“AEB 要很灵敏反应要快”AI 大概率生成一堆“验证系统是否灵敏”这种没法落地的用例。但如果 PRD 写的是“系统应在前方目标 TTC 小于 1.5s 时发出制动请求TTC 计算周期应不超过 20ms”AI 就能很自然地生成边界值用例、时序用例、异常输入用例。所以想用 AI 提效先把 PRD 写成结构化、可量化的表格而不是一段口语化描述。我自己试过的做法是PRD 里每个功能点用一个表格行来描述列包括需求 ID、需求描述、优先级、性能指标、关联场景。这样无论是人工拆 SSTS还是扔给大语言模型做初稿测试用例效率都高很多。不过得注意AI 生成的测试用例只是初稿尤其是 AEB 这种安全相关功能最终必须由系统工程师和测试工程师逐条审核不能直接作为正式用例发布。2.3 PRD 评审时我会重点问的三个问题PRD 评审会上我一般会问三个问题能挡掉不少后期的大坑。第一个问题是“这条需求可测量吗” 如果需求写的是“系统应快速响应”那我会直接怼回去多快算快10ms100ms1s没有量化的需求SSTS 根本没法拆测试也不知道怎么判定 Pass/Fail。遇到这种情况就要拉着功能工程师一起把“快速”翻译成具体数值。第二个问题是“失效了怎么办” 汽车电子里没有完美的系统AEB 也有传感器脏污、控制器故障、CAN 通信超时这些异常情况。PRD 阶段哪怕不写具体诊断策略也要明确“系统应有降级策略并在失效时提醒驾驶员”。否则后续 SSTS 里没有降级需求CTS 里也不会设计故障处理机制真出了问题才来补成本就大了。第三个问题是“需求之间有没有冲突” 比如 AEB 要在危险时自动制动但同时驾驶员可能正在踩油门加速避让。这时候 AEB 应该听谁的类似的冲突如果不在 PRD 阶段提出并明确仲裁逻辑后面系统工程师就会自己拍脑袋做出来的行为和产品预期可能完全不一样。3. 把 PRD 翻译成 SSTS系统级文档的分层拆解3.1 SSTS 的骨架长这样SSTS 是系统工程师的主场。它既要包含系统需求也要包含系统测试规范所以结构上一般会分成两大部分需求部分和测试部分。以 AEB 为例需求部分的典型目录是系统概述与适用范围系统架构与组成功能需求性能需求接口需求诊断与安全需求可追溯矩阵测试部分则对应为系统测试规范包括测试环境、测试工具、测试用例、通过标准。实际项目里SSTS 可能会写得非常厚但骨架就是这样。关键是从 PRD 到 SSTS 的时候不要把 PRD 条目原样复制粘贴。PRD 写“系统应避免低速碰撞”SSTS 必须拆成若干条可验证的系统需求。比如SSTS ID需求描述验证方法对应 PRD IDS-AEB-001自车速度在 10km/h~80km/h 范围内时系统应能检测前方静止车辆HIL 测试P-AEB-001S-AEB-002当预测碰撞时间 TTC 小于 1.5s 时系统应向制动控制器发送制动请求HIL 测试P-AEB-001S-AEB-003系统发出的制动请求应使车辆产生至少 4m/s² 的减速度台架测试P-AEB-002S-AEB-004系统在自车速度低于 5km/h 时不应触发制动HIL 测试P-AEB-001S-AEB-005系统应能识别传感器故障并在 200ms 内降级为关闭状态同时点亮故障灯实车测试P-AEB-003你会发现每条 SSTS 需求都绑定了验证方法。这是我很坚持的一点写 SSTS 的时候每条需求旁边必须有一列“验证方法”。如果一条需求写出来却想不到怎么验证说明它还没写清楚需要回头再想。3.2 系统架构和接口SSTS 最容易漏的部分功能需求好写接口需求难写。AEB 系统至少涉及环境感知、决策控制、制动执行、人机交互四个子系统。感知部分可能是前向摄像头和毫米波雷达决策控制部分可能是独立的域控制器制动执行部分可能是电子稳定程序或制动控制器人机交互部分则是仪表上的警示灯和提示音。SSTS 里如果只写功能需求而不写它们之间的接口后面联调一定会出问题。举个真实场景摄像头通过车载以太网把目标数据发给控制器雷达通过 CAN 发送目标距离和相对速度控制器做融合决策后再把制动请求通过私有 CAN 报文发给制动控制器。这一串过程中每个信号的周期是多少超时怎么办信号有效范围是什么丢帧容错是多少这些全部要在 SSTS 的接口需求里定义清楚。比如一条接口需求可以这样写“F-CAN 报文‘AEB_BrakeReq’周期 20ms有效范围 0x00~0x640xFF 表示无效若制动控制器在 100ms 内未收到该报文应保持当前制动压力并在仪表上提示 AEB 不可用。” 有了这种需求后续 CTS 里各零件的通信协议才有依据。接口需求最怕的就是“我以为你定义了你以为我定义了”。SSTS 评审时建议把各个零件负责人和系统测试负责人拉到一起把接口清单逐条过一遍哪怕多花半天时间也比后期联调时三周解不出一个问题强。3.3 实操把 PRD 一条需求展开成 SSTS 多条需求的例子用一个具体例子演示。PRD 里有这样一条需求“P-AEB-001Must车辆在低速行驶时若检测到前方有障碍物或车辆系统应自动制动以避免碰撞。”这条需求看着没毛病但要落到系统层必须拆分。我把 AEB 工程师平时会拆的至少 5 条相关需求列出来探测需求系统应能探测前方车辆、行人、两轮车并输出目标类型、距离、相对速度、置信度。决策需求系统应根据目标信息和自车速度计算 TTC并判断是否需要触发制动。执行需求系统应在触发时向制动控制器发出制动请求并满足减速度要求。HMI 需求系统应在触发前和触发过程中发出声音和视觉警示。失效降级需求系统在传感器故障或通信故障时应退出 AEB 功能并提示驾驶员。每条 SSTS 需求都会对应 PRD 里的 P-AEB-001但它们各自独立成条分别有验证方法。这就是“一条 PRD 需求变成多条 SSTS 需求”的典型过程。如果跳过这一步直接去写 CTS你面对的就会是“这个传感器要能探测行人”“这个控制器要能决策”这种模糊要求供应商看了根本不知道要实现到什么精度。所以SSTS 的价值就是把模糊的用户诉求翻译成明确的系统行为和边界让后续每一层都有据可依。4. 从 SSTS 到 CTS零件级规格要怎么落到能造出来4.1 一个 AEB 系统实际拆成了哪些 CTSSSTS 定义好了系统行为接下来就是把系统里的每个物理零件单独写成一本 CTS。一个典型的 AEB 系统会拆成前毫米波雷达 CTS前视摄像头 CTS制动控制器/ESC CTSHMI 警示灯 CTS线束 CTS如果还有域控制器那还要单独写域控制器 CTS每本 CTS 只描述一个零件但它的输入并不是“PRD 里所有需求”而是“SSTS 里与该零件相关的需求子集”再加上零件自身的技术约束。以制动控制器 CTS 为例核心章节一般包括功能范围、性能参数、接口定义、诊断需求、环境与机械要求、DV/PV 试验项。功能范围要说明这个控制器在 AEB 系统里承担什么角色比如“接收来自决策控制器的制动请求并闭环控制制动液压”。性能参数要写响应时间、液压压力范围、压力上升速率、最大制动压力。接口定义要写供电、接地、CAN/LIN 报文、引脚定义。环境与机械要求要写工作温度、防护等级、振动等级、安装位置。这几个部分缺一不可。少了任何一块供应商要么没法开发要么只能自己瞎猜。4.2 制动控制器 CTS 里的一条典型需求长什么样为了让“从 SSTS 到 CTS”的翻译更直观我拿一条制动控制器的需求举例。SSTS 里有这么一条“系统发出的制动请求应使车辆产生至少 4m/s² 的减速度。” 这条需求到了制动控制器 CTS就不能只写“应使车辆产生 4m/s² 减速度”了因为制动控制器不直接决定整车减速度它只控制液压。它需要被翻译成零件可执行、可验证的要求。CTS 里可以这样写“控制器收到 AEB 制动请求信号后应在 50ms 内建立制动液压液压压力上升斜率应不低于 150bar/s并在 200ms 内达到目标压力当目标压力大于 80bar 时实际压力误差应在 ±3bar 以内。”这个 150bar/s 是怎么来的其实就是从“整车 4m/s² 减速度”倒推出来的。先算出需要的制动压力再除以系统允许的时间常数再考虑制动盘、轮胎、液路等一圈机械参数最后标定出一个供应商可测量的液压指标。这个计算过程不需要写在 CTS 里但零件工程师必须能解释清楚评审的时候供应商也会问。另外CTS 里还要写测试要求。DVDesign Verification阶段供应商要做常温耐久、高低温、振动、EMC 等实验PVProduction Validation阶段要从量产件里抽样做可靠性验证。这些实验不是随便写的每一条都能在 CTS 里找到对应测试方法和判定标准。这里再呼应一下热搜那句话“CTS 不 balance 只解 DRC”。在芯片设计领域时钟树综合如果只看 DRC 不管 balance会导致时序收敛出问题。在汽车零部件开发里也一样如果 CTS 只写“自己这个零件怎么达标”不写“和系统其他零件怎么配合”那就算单个零件全合格装到车上也可能出问题。所以 CTS 里必须同时兼顾零件自身性能和系统级配合缺一不可。4.3 供应商Tier1拿到 CTS 后会怎么挑刺CTS 发给供应商之后别以为就完事了。供应商的第一轮反馈基本都会是一堆澄清问题。我整理几个最常被问的“工作温度 -40℃~85℃ 是指环境温度还是控制器表面温度” 这个问题看似抠字眼但会直接影响供应商的散热设计和器件选型。如果没写清楚供应商可能按最严的选取成本高按最松的选取实际装车后又会可靠性不足。“CAN 唤醒方式是什么本地唤醒还是总线唤醒” 制动控制器这种常电零件唤醒策略直接影响静态电流而静态电流在整车项目里是硬指标。“DV 实验是在零件单体状态做还是带着负载做” 带不带负载测试结果差别很大。比如继电器触点耐久空载做和带电机做完全是两回事。“这条诊断故障码对应的恢复条件是什么” 很多 CTS 只写“发生故障时置位故障码”但不写故障恢复条件供应商做诊断策略时就得猜。这些问题的答案很多在 SSTS 里已经定了但 CTS 里没写进去。所以我建议 CTS 在发给供应商之前内部先做一轮“可制造性评审”请系统工程师、采购、质量、硬件工程师一起过一遍把这种容易被问的问题提前补上。这样一轮改完再发出去能省好几轮邮件往返。5. 避坑与实战从 PRD 到 CTS 的项目管理心得5.1 文档版本与追溯管理文档写得再完整如果没有版本管理一样会乱成一锅粥。汽车项目动辄两三年需求改动的次数极其频繁今天 PRD 改一个阈值明天 SSTS 就要跟着改最后 CTS 和测试用例也得同步更新。这个链条只要有一个环节漏了后面测试就会拿旧需求来验收问题一堆。我习惯用的追溯表格至少包含四列PRD ID、SSTS ID、CTS ID、测试用例 ID。每次需求变更先更新 PRD然后逐条检查下游 SSTS 和 CTS 是否需要同步变更再更新追溯矩阵。如果有条件推荐用需求管理工具比如 DOORS、Jama、Polarion小项目或者早期阶段用 Excel 加严格命名规范也能撑到首发。版本号管理上我建议每次评审通过后生成一个新版本变更记录写清楚“改了什么、为什么改、谁改的”。这听起来有点繁琐但真等到项目做了一年有人来问“这个阈值为什么从 1.5s 变成 1.2s”翻翻变更记录就能找到答案比自己回忆靠谱多了。5.2 我踩过的一些坑这几年我踩过的坑不少挑几个有代表性的说。第一个坑是 PRD 评审时没拉系统工程师。那时候我以为 PRD 是产品的事等产品经理写完发给系统工程师系统工程师一看发现有一半需求根本没法工程实现比如“系统应避免所有碰撞”这种绝对化表述。结果 PRD 大改后面所有文档跟着返工。后来我吸取教训PRD 初稿阶段就把系统、测试、采购、质量都拉进评审会提前暴露问题。第二个坑是 SSTS 里的性能参数没有验证方法。早期我写 SSTS 只写需求不写验证方法到 DV 阶段测试工程师跑过来问“这条要求怎么测试验台架搭不出来”我当时就傻眼了。后来我给自己立了个规矩写每条需求时至少写一个可行的验证方法哪怕是“仿真分析”也行不能留空。第三个坑是 CTS 直接把 SSTS 需求复制粘贴给供应商。比如 SSTS 写“系统应能探测前方车速为 0 的车辆”到了雷达 CTS如果不细化成“雷达应能输出距离 0~200m、目标车速 -20~50m/s 的目标列表”供应商根本不知道该按什么指标设计。CTS 不能是系统需求的“复印件”必须做颗粒度更细的翻译。5.3 抽空写点个人体会最后说点个人心得。刚工作那会儿我觉得写文档特别烦明明代码和硬件才是真功夫。但后来我发现项目里绝大部分问题都不是单个零件坏了而是需求和需求之间没对齐。PRD、SSTS、CTS 这条链本质上是用一套统一的“语言”把用户想法、系统设计、零件实现串起来让你在开发之前就把该想的问题想完而不是等到装车之后再去救火。我自己的一个小习惯是每写完一条需求都问自己一句“我如何证明这条需求是满足的” 如果答不上来那就说明这条需求还没写清楚。这个习惯帮我挡掉了大量模糊需求也让我写出来的文档更容易被下游执行。希望你也能用上这个方法从想法到零件的路就会顺很多。
从PRD到CTS：汽车电子需求文档逐层拆解实战指南
一辆车从“有个想法”到“供应商能照着图纸把零件造出来”中间隔着的不只是时间还有一整套需求文档的逐层翻译。我刚入行的时候产品经理扔给我一句“我们要做个自动紧急刹车50km/h以下要能刹停”我第一反应是“这不很简单吗”结果真正上手后发现这句话要变成 PRD再从 PRD 拆成 SSTS最后落到 CTS每一步都有无数细节会被放大。这篇文章不聊虚的直接手把手拆一个典型功能把这三份文档的关系、写法、常见坑讲清楚。不管你是刚接触汽车电子开发的需求工程师、测试工程师还是想了解整车开发流程的软件/硬件工程师这篇内容都能帮你少走弯路。1. PRD、SSTS、CTS 三种文档一张表看懂分工1.1 汽车功能开发的文档金字塔在汽车电子产品开发里PRD、SSTS、CTS 是三个层级非常分明的文档它们的关系就像一个金字塔。PRDProduct Requirements Document是产品需求文档回答“用户要什么”。它描述的是一个功能在整车层面的表现比如“车辆低速行驶时如果前方有障碍物或车辆系统应能自动制动以避免碰撞”。这个文档通常由产品经理或系统需求工程师牵头写核心读者是项目组、系统工程师、测试负责人。SSTSSystem Specification and Test Specification是系统规格与测试规格回答“系统怎么做到”。它把一个 PRD 功能拆解成若干条可量化的系统需求并且为每条需求配套对应的系统级测试方法。比如“系统应在前方目标相对距离小于某个阈值时发出制动请求”“制动减速度应大于多少”等。这个文档通常由系统工程师编写核心读者是软硬件开发团队、测试团队、以及下游的零件供应商。CTSComponent Technical Specification是零部件技术规范回答“零件应该长什么样、怎么验证”。它定义了某个具体零件比如雷达、摄像头、制动控制器的功能边界、性能参数、电气接口、机械接口、环境要求、诊断需求以及 DV/PV 实验要求。这个文档通常由零件工程师负责最终交给 Tier1 供应商作为开发依据。文档中文含义核心问题主要编写人主要读者PRD产品需求文档用户要什么产品经理/需求工程师项目、系统、测试SSTS系统规格与测试规格系统怎么做到系统工程师软硬件、测试、供应商CTS零部件技术规范零件怎么做、怎么验零件工程师供应商、采购、质量用一个建房子的类比就特别好懂。PRD 是房主说“我要一套能住的三居室采光要好冬天不能冷”SSTS 是建筑设计师画的整栋楼的施工图、材料清单和验收标准比如“客厅面积不少于 20 平米南向窗户面积不少于 3 平米保温层厚度 80mm”CTS 则是给材料供应商的具体要求比如“这批水泥必须是 PO42.5 标号初凝时间不早于 45 分钟抗压强度 28 天不低于 42.5MPa”。没有中间那层施工图直接告诉水泥厂“我要一栋好房子”供应商根本没法干活。1.2 CTS 别和芯片设计里的 CTS 搞混说个真实存在的尴尬事。我和一位做芯片后端的朋友聊天他说“CTS 不 balance 只解 DRC”我当时愣了半天心想这不是我们刚发给供应商的零部件技术规范吗怎么还能不 balance后来才知道他说的 CTS 是芯片设计里的 Clock Tree Synthesis时钟树综合而 DRC 是 Design Rule Check。在芯片后端流程里时钟树综合除了查 DRC还要关注时钟偏斜skew、latency 这些时序平衡指标所以“只解 DRC 不管 balance”确实是会被吐槽的做法。但在汽车电子需求链里CTS 指的是 Component Technical Specification也就是零部件技术规范。这两种 CTS 八竿子打不着可偏偏缩写一样。如果你在文档里不把全称写出来或者项目内部没有统一术语表跨团队沟通时特别容易鸡同鸭讲。后来我养成了一个习惯第一次在文档中出现 CTS 时一定写全称“Component Technical SpecificationCTS”后面再简称 CTS。同理SSTS 也是第一次出现就写全称。这个细节看起来小但实际项目里因为术语不统一造成的返工并不少见。尤其是当同一家公司既有芯片设计团队又有整车电子团队时开会前最好先确认一下对方说的 CTS 是哪个 CTS。否则你辛辛苦苦准备了一晚上零部件接口参数对方其实想聊时钟树的 balance 问题。1.3 为什么必须从 PRD 到 SSTS 再到 CTS不能跳级我见过最典型的返工案例就是为了赶进度跳过 SSTS直接拿 PRD 去写 CTS。结果呢供应商拿到 CTS 后问了一堆问题这个零件要不要支持 12V 电源跌落控制器放在驾驶室还是发动机舱通信接口是 CAN 还是 LIN需不需要在紧急情况下自动复位这些问题在 PRD 里根本找不到答案而 CTS 里也没写供应商就只能猜。猜来猜去最后做出来的零件和系统需求对不上整个项目返工。原因很简单PRD 是“用户语言”SSTS 是“系统语言”CTS 是“零件语言”。从用户语言直接翻译成零件语言中间少了系统架构、功能分解、接口定义、失效模式分析这些关键环节。每个环节都在做“翻译消歧”跳级等于把这些歧义都丢给了供应商。还有一点特别重要就是可追溯性。每条 CTS 需求要能追溯到 SSTS 里的某一条系统需求每条 SSTS 需求要能追溯到 PRD 里的某一条产品需求。这个链条一旦断裂后面出了问题根本无法定位是哪个需求变了、哪个零件该负责。V 模型开发流程里这个追溯矩阵是质量审核必查项也是出了问题之后迅速找到责任方的关键。2. 从想法到 PRD别急着写功能先写场景和指标2.1 一个合格 PRD 的开头应该是什么很多人写 PRD 喜欢上来就写“我们要做一个自动紧急制动功能”然后就没了。这种文档别说供应商连系统工程师看了都头疼。一个合格的 PRD开头应该包含背景与目标、用户场景、功能需求、性能指标、安全法规约束、验收标准。拿自动紧急制动AEB举例。背景与目标可以写“在城市工况下驾驶员反应不及时导致的追尾事故频发因此需开发 AEB 功能降低低速碰撞风险”。用户场景要写清楚不能只写一个“前方有车”至少包括前方车辆静止、前方车辆匀速行驶、前方车辆减速、行人横穿、雨雾天气等典型场景。性能指标必须量化。比如“在干燥沥青路面上自车以 10km/h 到 80km/h 的速度行驶前方车辆静止时系统应在碰撞前至少 1.5 秒发出制动请求以避免碰撞若无法避免应实现碰撞速度降低 20km/h 以上。” 这种描述才是可以往下拆的。这里有个容易被忽视的点PRD 里的验收标准不是给工程师看的而是给老板和客户看的。它应该用一句话总结“我如何判断这个功能做成功了”。比如“完成 AEB 功能道路测试在验证场景列表中的所有场景下满足上述性能指标。” 这样一旦后面测试不通过项目干系人就可以明确知道是没达到验收标准而不是吵“我感觉已经做得挺好了”。2.2 用“必须、应该、可以”管理优先级顺便喂给 AI写 PRD 需求时我强烈建议每条功能描述都带优先级。可以用 Must必须、Should应该、Could可以三档也可以用 MoSCoW 法。Must 代表没有它功能就不成立比如“系统必须能检测前方车辆并触发制动请求”。Should 是应该有但可以有条件的妥协比如“系统应该能在夜间弱光环境下检测行人如果性能不满足可以要求车速限制在 40km/h 以下”。Could 是锦上添花比如“系统可以支持通过手机 App 查看 AEB 的触发记录”。为什么优先级这么重要因为后续 SSTS 拆需求、测试排优先级、供应商做设计全部要依赖这个优先级。一条 Must 需求如果没有被系统需求覆盖测试阶段就会暴露严重问题一条 Could 需求如果被当成 Must 去实现项目成本和周期都会失控。另外最近很火的“AI 根据 PRD 生成测试用例”也是建立在 PRD 结构足够好的前提下。如果你的 PRD 是“AEB 要很灵敏反应要快”AI 大概率生成一堆“验证系统是否灵敏”这种没法落地的用例。但如果 PRD 写的是“系统应在前方目标 TTC 小于 1.5s 时发出制动请求TTC 计算周期应不超过 20ms”AI 就能很自然地生成边界值用例、时序用例、异常输入用例。所以想用 AI 提效先把 PRD 写成结构化、可量化的表格而不是一段口语化描述。我自己试过的做法是PRD 里每个功能点用一个表格行来描述列包括需求 ID、需求描述、优先级、性能指标、关联场景。这样无论是人工拆 SSTS还是扔给大语言模型做初稿测试用例效率都高很多。不过得注意AI 生成的测试用例只是初稿尤其是 AEB 这种安全相关功能最终必须由系统工程师和测试工程师逐条审核不能直接作为正式用例发布。2.3 PRD 评审时我会重点问的三个问题PRD 评审会上我一般会问三个问题能挡掉不少后期的大坑。第一个问题是“这条需求可测量吗” 如果需求写的是“系统应快速响应”那我会直接怼回去多快算快10ms100ms1s没有量化的需求SSTS 根本没法拆测试也不知道怎么判定 Pass/Fail。遇到这种情况就要拉着功能工程师一起把“快速”翻译成具体数值。第二个问题是“失效了怎么办” 汽车电子里没有完美的系统AEB 也有传感器脏污、控制器故障、CAN 通信超时这些异常情况。PRD 阶段哪怕不写具体诊断策略也要明确“系统应有降级策略并在失效时提醒驾驶员”。否则后续 SSTS 里没有降级需求CTS 里也不会设计故障处理机制真出了问题才来补成本就大了。第三个问题是“需求之间有没有冲突” 比如 AEB 要在危险时自动制动但同时驾驶员可能正在踩油门加速避让。这时候 AEB 应该听谁的类似的冲突如果不在 PRD 阶段提出并明确仲裁逻辑后面系统工程师就会自己拍脑袋做出来的行为和产品预期可能完全不一样。3. 把 PRD 翻译成 SSTS系统级文档的分层拆解3.1 SSTS 的骨架长这样SSTS 是系统工程师的主场。它既要包含系统需求也要包含系统测试规范所以结构上一般会分成两大部分需求部分和测试部分。以 AEB 为例需求部分的典型目录是系统概述与适用范围系统架构与组成功能需求性能需求接口需求诊断与安全需求可追溯矩阵测试部分则对应为系统测试规范包括测试环境、测试工具、测试用例、通过标准。实际项目里SSTS 可能会写得非常厚但骨架就是这样。关键是从 PRD 到 SSTS 的时候不要把 PRD 条目原样复制粘贴。PRD 写“系统应避免低速碰撞”SSTS 必须拆成若干条可验证的系统需求。比如SSTS ID需求描述验证方法对应 PRD IDS-AEB-001自车速度在 10km/h~80km/h 范围内时系统应能检测前方静止车辆HIL 测试P-AEB-001S-AEB-002当预测碰撞时间 TTC 小于 1.5s 时系统应向制动控制器发送制动请求HIL 测试P-AEB-001S-AEB-003系统发出的制动请求应使车辆产生至少 4m/s² 的减速度台架测试P-AEB-002S-AEB-004系统在自车速度低于 5km/h 时不应触发制动HIL 测试P-AEB-001S-AEB-005系统应能识别传感器故障并在 200ms 内降级为关闭状态同时点亮故障灯实车测试P-AEB-003你会发现每条 SSTS 需求都绑定了验证方法。这是我很坚持的一点写 SSTS 的时候每条需求旁边必须有一列“验证方法”。如果一条需求写出来却想不到怎么验证说明它还没写清楚需要回头再想。3.2 系统架构和接口SSTS 最容易漏的部分功能需求好写接口需求难写。AEB 系统至少涉及环境感知、决策控制、制动执行、人机交互四个子系统。感知部分可能是前向摄像头和毫米波雷达决策控制部分可能是独立的域控制器制动执行部分可能是电子稳定程序或制动控制器人机交互部分则是仪表上的警示灯和提示音。SSTS 里如果只写功能需求而不写它们之间的接口后面联调一定会出问题。举个真实场景摄像头通过车载以太网把目标数据发给控制器雷达通过 CAN 发送目标距离和相对速度控制器做融合决策后再把制动请求通过私有 CAN 报文发给制动控制器。这一串过程中每个信号的周期是多少超时怎么办信号有效范围是什么丢帧容错是多少这些全部要在 SSTS 的接口需求里定义清楚。比如一条接口需求可以这样写“F-CAN 报文‘AEB_BrakeReq’周期 20ms有效范围 0x00~0x640xFF 表示无效若制动控制器在 100ms 内未收到该报文应保持当前制动压力并在仪表上提示 AEB 不可用。” 有了这种需求后续 CTS 里各零件的通信协议才有依据。接口需求最怕的就是“我以为你定义了你以为我定义了”。SSTS 评审时建议把各个零件负责人和系统测试负责人拉到一起把接口清单逐条过一遍哪怕多花半天时间也比后期联调时三周解不出一个问题强。3.3 实操把 PRD 一条需求展开成 SSTS 多条需求的例子用一个具体例子演示。PRD 里有这样一条需求“P-AEB-001Must车辆在低速行驶时若检测到前方有障碍物或车辆系统应自动制动以避免碰撞。”这条需求看着没毛病但要落到系统层必须拆分。我把 AEB 工程师平时会拆的至少 5 条相关需求列出来探测需求系统应能探测前方车辆、行人、两轮车并输出目标类型、距离、相对速度、置信度。决策需求系统应根据目标信息和自车速度计算 TTC并判断是否需要触发制动。执行需求系统应在触发时向制动控制器发出制动请求并满足减速度要求。HMI 需求系统应在触发前和触发过程中发出声音和视觉警示。失效降级需求系统在传感器故障或通信故障时应退出 AEB 功能并提示驾驶员。每条 SSTS 需求都会对应 PRD 里的 P-AEB-001但它们各自独立成条分别有验证方法。这就是“一条 PRD 需求变成多条 SSTS 需求”的典型过程。如果跳过这一步直接去写 CTS你面对的就会是“这个传感器要能探测行人”“这个控制器要能决策”这种模糊要求供应商看了根本不知道要实现到什么精度。所以SSTS 的价值就是把模糊的用户诉求翻译成明确的系统行为和边界让后续每一层都有据可依。4. 从 SSTS 到 CTS零件级规格要怎么落到能造出来4.1 一个 AEB 系统实际拆成了哪些 CTSSSTS 定义好了系统行为接下来就是把系统里的每个物理零件单独写成一本 CTS。一个典型的 AEB 系统会拆成前毫米波雷达 CTS前视摄像头 CTS制动控制器/ESC CTSHMI 警示灯 CTS线束 CTS如果还有域控制器那还要单独写域控制器 CTS每本 CTS 只描述一个零件但它的输入并不是“PRD 里所有需求”而是“SSTS 里与该零件相关的需求子集”再加上零件自身的技术约束。以制动控制器 CTS 为例核心章节一般包括功能范围、性能参数、接口定义、诊断需求、环境与机械要求、DV/PV 试验项。功能范围要说明这个控制器在 AEB 系统里承担什么角色比如“接收来自决策控制器的制动请求并闭环控制制动液压”。性能参数要写响应时间、液压压力范围、压力上升速率、最大制动压力。接口定义要写供电、接地、CAN/LIN 报文、引脚定义。环境与机械要求要写工作温度、防护等级、振动等级、安装位置。这几个部分缺一不可。少了任何一块供应商要么没法开发要么只能自己瞎猜。4.2 制动控制器 CTS 里的一条典型需求长什么样为了让“从 SSTS 到 CTS”的翻译更直观我拿一条制动控制器的需求举例。SSTS 里有这么一条“系统发出的制动请求应使车辆产生至少 4m/s² 的减速度。” 这条需求到了制动控制器 CTS就不能只写“应使车辆产生 4m/s² 减速度”了因为制动控制器不直接决定整车减速度它只控制液压。它需要被翻译成零件可执行、可验证的要求。CTS 里可以这样写“控制器收到 AEB 制动请求信号后应在 50ms 内建立制动液压液压压力上升斜率应不低于 150bar/s并在 200ms 内达到目标压力当目标压力大于 80bar 时实际压力误差应在 ±3bar 以内。”这个 150bar/s 是怎么来的其实就是从“整车 4m/s² 减速度”倒推出来的。先算出需要的制动压力再除以系统允许的时间常数再考虑制动盘、轮胎、液路等一圈机械参数最后标定出一个供应商可测量的液压指标。这个计算过程不需要写在 CTS 里但零件工程师必须能解释清楚评审的时候供应商也会问。另外CTS 里还要写测试要求。DVDesign Verification阶段供应商要做常温耐久、高低温、振动、EMC 等实验PVProduction Validation阶段要从量产件里抽样做可靠性验证。这些实验不是随便写的每一条都能在 CTS 里找到对应测试方法和判定标准。这里再呼应一下热搜那句话“CTS 不 balance 只解 DRC”。在芯片设计领域时钟树综合如果只看 DRC 不管 balance会导致时序收敛出问题。在汽车零部件开发里也一样如果 CTS 只写“自己这个零件怎么达标”不写“和系统其他零件怎么配合”那就算单个零件全合格装到车上也可能出问题。所以 CTS 里必须同时兼顾零件自身性能和系统级配合缺一不可。4.3 供应商Tier1拿到 CTS 后会怎么挑刺CTS 发给供应商之后别以为就完事了。供应商的第一轮反馈基本都会是一堆澄清问题。我整理几个最常被问的“工作温度 -40℃~85℃ 是指环境温度还是控制器表面温度” 这个问题看似抠字眼但会直接影响供应商的散热设计和器件选型。如果没写清楚供应商可能按最严的选取成本高按最松的选取实际装车后又会可靠性不足。“CAN 唤醒方式是什么本地唤醒还是总线唤醒” 制动控制器这种常电零件唤醒策略直接影响静态电流而静态电流在整车项目里是硬指标。“DV 实验是在零件单体状态做还是带着负载做” 带不带负载测试结果差别很大。比如继电器触点耐久空载做和带电机做完全是两回事。“这条诊断故障码对应的恢复条件是什么” 很多 CTS 只写“发生故障时置位故障码”但不写故障恢复条件供应商做诊断策略时就得猜。这些问题的答案很多在 SSTS 里已经定了但 CTS 里没写进去。所以我建议 CTS 在发给供应商之前内部先做一轮“可制造性评审”请系统工程师、采购、质量、硬件工程师一起过一遍把这种容易被问的问题提前补上。这样一轮改完再发出去能省好几轮邮件往返。5. 避坑与实战从 PRD 到 CTS 的项目管理心得5.1 文档版本与追溯管理文档写得再完整如果没有版本管理一样会乱成一锅粥。汽车项目动辄两三年需求改动的次数极其频繁今天 PRD 改一个阈值明天 SSTS 就要跟着改最后 CTS 和测试用例也得同步更新。这个链条只要有一个环节漏了后面测试就会拿旧需求来验收问题一堆。我习惯用的追溯表格至少包含四列PRD ID、SSTS ID、CTS ID、测试用例 ID。每次需求变更先更新 PRD然后逐条检查下游 SSTS 和 CTS 是否需要同步变更再更新追溯矩阵。如果有条件推荐用需求管理工具比如 DOORS、Jama、Polarion小项目或者早期阶段用 Excel 加严格命名规范也能撑到首发。版本号管理上我建议每次评审通过后生成一个新版本变更记录写清楚“改了什么、为什么改、谁改的”。这听起来有点繁琐但真等到项目做了一年有人来问“这个阈值为什么从 1.5s 变成 1.2s”翻翻变更记录就能找到答案比自己回忆靠谱多了。5.2 我踩过的一些坑这几年我踩过的坑不少挑几个有代表性的说。第一个坑是 PRD 评审时没拉系统工程师。那时候我以为 PRD 是产品的事等产品经理写完发给系统工程师系统工程师一看发现有一半需求根本没法工程实现比如“系统应避免所有碰撞”这种绝对化表述。结果 PRD 大改后面所有文档跟着返工。后来我吸取教训PRD 初稿阶段就把系统、测试、采购、质量都拉进评审会提前暴露问题。第二个坑是 SSTS 里的性能参数没有验证方法。早期我写 SSTS 只写需求不写验证方法到 DV 阶段测试工程师跑过来问“这条要求怎么测试验台架搭不出来”我当时就傻眼了。后来我给自己立了个规矩写每条需求时至少写一个可行的验证方法哪怕是“仿真分析”也行不能留空。第三个坑是 CTS 直接把 SSTS 需求复制粘贴给供应商。比如 SSTS 写“系统应能探测前方车速为 0 的车辆”到了雷达 CTS如果不细化成“雷达应能输出距离 0~200m、目标车速 -20~50m/s 的目标列表”供应商根本不知道该按什么指标设计。CTS 不能是系统需求的“复印件”必须做颗粒度更细的翻译。5.3 抽空写点个人体会最后说点个人心得。刚工作那会儿我觉得写文档特别烦明明代码和硬件才是真功夫。但后来我发现项目里绝大部分问题都不是单个零件坏了而是需求和需求之间没对齐。PRD、SSTS、CTS 这条链本质上是用一套统一的“语言”把用户想法、系统设计、零件实现串起来让你在开发之前就把该想的问题想完而不是等到装车之后再去救火。我自己的一个小习惯是每写完一条需求都问自己一句“我如何证明这条需求是满足的” 如果答不上来那就说明这条需求还没写清楚。这个习惯帮我挡掉了大量模糊需求也让我写出来的文档更容易被下游执行。希望你也能用上这个方法从想法到零件的路就会顺很多。