4. 系统级产品开发：系统级开发启动、技术安全概念（TSC）、系统设计与验证、系统集成与测试

好，咱们进入系统级产品开发这个核心环节。说实话，这是整个功能安全开发中最「接地气」的部分。前面那些概念、计划、管理，说白了都是在搭台子。从这一章开始，咱们要真刀真枪地唱戏了。

我个人习惯把系统级开发分成四个阶段：启动、概念设计、详细设计与验证、集成测试。每个阶段都有它的坑，也有它的窍门。咱们一个一个聊。

4.1 系统级开发启动

启动阶段做什么？不是开会，不是写PPT。是确认两件事：安全目标和安全状态。

我记得有一次，一个团队拿着安全目标来找我评审。目标写的是「防止非预期加速」。我说，这太模糊了。非预期加速到什么程度？持续多久？驾驶员有没有机会干预？这些不明确，后面的技术安全概念根本没法做。

所以启动阶段，我建议你至少完成以下工作：

• 确认安全目标：来自上一阶段，但需要细化到可执行的程度
• 定义安全状态：系统出问题时，应该进入什么状态？是降级、关闭、还是报警？
• 明确系统边界：哪些功能在系统内，哪些在系统外？接口怎么定义？
• 分配ASIL等级：每个安全目标对应的ASIL等级，要落实到子系统或组件

4.2 技术安全概念（TSC）

技术安全概念，简称TSC。这是系统级开发的重头戏。说白了，就是把安全目标翻译成技术语言。

举个例子。安全目标是「当驾驶员踩刹车时，车辆必须减速」。翻译成TSC，就变成了：

• 刹车踏板位置传感器必须检测到踩踏动作
• 信号必须在100ms内传输到ECU
• ECU必须在50ms内计算出目标减速度
• 执行器必须在30ms内响应

你看，一个简单的安全目标，拆解下来就是一堆技术指标。每个指标都要有对应的安全机制来保证。

我在项目中遇到过一种情况：团队把TSC写得特别详细，但忽略了故障容错时间间隔（FTTI）。结果呢？安全机制设计得再好，响应时间超了，系统还是不安全。所以，TSC里一定要明确时间约束。

TSC的输出通常包括：

• 系统架构（含安全相关和非安全相关部分）
• 安全机制（检测、响应、容错）
• 故障处理策略（降级、关闭、报警）
• 安全状态定义（正常、降级、安全状态）
• 时间约束（FTTI、诊断测试间隔等）

4.3 系统设计与验证

有了TSC，接下来就是系统设计。这里我要强调一点：设计不是画图，是决策。

你想想看，一个系统架构摆在你面前，你要决定：

• 用单核还是双核？
• 用硬件冗余还是软件多样性？
• 诊断覆盖率要达到多少？
• 故障响应是立即停车还是降级运行？

每个决策背后都有代价。我见过一个项目，为了追求高安全等级，用了三冗余设计。结果成本翻了三倍，开发周期延长了一倍。最后客户说，我们其实只需要ASIL B，你搞了个ASIL D出来，这不是浪费吗？

所以，系统设计要适度。安全等级够用就行，别过度设计。

验证阶段，我常用的方法有：

• FMEA：分析潜在故障模式及其影响
• FTA：从顶事件向下分析，找出根本原因
• 安全分析：定量评估故障概率和诊断覆盖率
• 仿真验证：用模型验证安全机制的有效性

4.4 系统集成与测试

终于到了集成测试阶段。这个阶段，说白了就是「把零件拼起来，看看能不能跑」。

但功能安全的集成测试，和普通测试不一样。普通测试只测功能对不对，功能安全测试还要测：出故障时，系统安不安全。

我建议你按这个顺序来：

1. 功能测试：先确保基本功能正常
2. 安全机制测试：注入故障，看安全机制能不能正确响应
3. 故障注入测试：模拟各种故障场景，验证系统是否进入安全状态
4. 鲁棒性测试：在极限条件下（高温、低温、电磁干扰等）测试系统
5. 回归测试：每次修改后，重新测试所有相关功能

我曾经遇到过一个案例：故障注入测试时，安全机制触发了，但系统进入了错误的安全状态。本来应该降级到30km/h，结果直接停车了。这在高速上可是要命的。所以，测试不仅要测「有没有触发」，还要测「触发了之后对不对」。

集成测试的文档也很重要。我习惯用这样的表格来记录：

测试用例ID	测试场景	注入故障	预期结果	实际结果	状态
TC-001	正常行驶中传感器失效	断开传感器信号	系统进入降级模式，报警	系统进入降级模式，报警	通过
TC-002	高速行驶中执行器卡死	模拟执行器卡死	系统在100ms内进入安全状态	系统在120ms内进入安全状态	失败

你看，TC-002失败了。为什么？因为执行器卡死时，系统用了轮询方式检测，响应时间超标。后来改成中断方式，才满足要求。这就是测试的价值——发现问题，解决问题。

嗯，这一章就聊到这儿。下一章咱们讲硬件级开发，到时候再细聊硬件安全需求和硬件架构设计。有什么问题，欢迎随时交流。