软件架构安全设计:死代码、级联失效和数据一致性

摘要：安全相关软件架构不是把代码分层画漂亮，而是要把死代码、级联失效和数据一致性这些隐性风险，落实到边界、接口、监控、降级和验证证据中。

图 1　封面：软件架构安全设计要把死代码、级联失效和数据一致性放到同一套工程防线里。

一、架构安全不是把代码分层画漂亮

⁠　　很多项目在谈软件架构时，第一反应是分层图、模块图、接口图，似乎图画得越清楚，架构就越安全。但在真实量产项目里，架构安全真正要回答的问题不是“模块名字是否优雅”，而是“当输入异常、状态冲突、资源紧张、代码变更、配置切换同时出现时，系统还能不能把风险控制在可接受边界内”。

⁠　　对于底盘、制动、转向、悬架等安全相关控制软件，这个问题尤其现实。车辆不会因为软件注释写得整齐就更安全，也不会因为模块被分成应用层、服务层、驱动层就自动具备安全性。真正起作用的是边界、约束、监控、降级、诊断和验证证据。

⁠　　软件架构安全设计的核心，是把安全需求从概念层落到软件结构中。安全目标经过功能安全概念、技术安全概念、软件安全需求逐级分解之后，最终必须体现在软件组件、接口、调度、数据、状态机和错误处理上。如果中间断了一段，后面测试再努力，也只能证明“某些场景跑过了”，不能证明“风险被系统性控制了”。

⁠　　工程上最容易被忽略的风险，往往不是一眼就能看见的语法错误，而是那些藏在结构里的问题：一段没人敢删的死代码，一个故障在多个模块之间扩散，一份看起来名字相同但时间基准不同的数据。这类问题单独看都不醒目，组合在一起却可能把控制器带到很难解释的状态。

⁠　　所以这篇文章不从宏大的架构口号讲起，而是抓三个很具体的问题：死代码、级联失效、数据一致性。它们看似属于代码质量、系统设计、接口规范三个不同话题，实际在安全相关软件里，是同一个问题的三个侧面：软件是否能在复杂变化中保持可理解、可隔离、可验证。

图 2　小红书封面：软件架构安全别只看代码能跑。

二、先把工程问题问对

⁠　　做安全相关软件架构，第一步不是马上拆模块，而是问清楚风险藏在哪里。一个底盘控制功能通常会从传感器输入开始，经过信号处理、状态判断、控制算法、执行器请求、诊断监控和网络通信，最后作用到车辆行为。任何一个环节出问题，都可能通过数据、状态或资源传递到下游。

⁠　　如果只看单个函数，工程师容易得到一个局部结论：这个函数输入输出正常，这个分支覆盖率达标，这个模块单测通过。但车辆层面的安全风险并不会尊重函数边界。错误的车速信号可能影响制动分配，异常的横摆角速度可能影响稳定性控制，失效的执行器状态可能让上层算法继续做出过于乐观的请求。

⁠　　因此，架构安全要把问题从“代码是否能运行”提升到“失效如何传播”。这也是为什么安全相关开发不能只依赖最后的台架验证。台架可以暴露问题，但架构要提前决定问题被限制在哪里、谁负责识别、谁负责上报、谁负责降级、谁有权继续使用某个数据。

⁠　　死代码要问的是：这段逻辑是否仍可能被构建、配置、变体或异常路径触发。如果它确实不可达，是否已经形成了可解释的清理证据。如果它在某些变体中可达，那么对应需求、测试和安全分析是否还存在。

⁠　　级联失效要问的是：一个模块的错误是否会通过共享状态、队列阻塞、全局标志、资源占用、错误返回值或时序抖动影响其他模块。如果会影响，架构有没有隔离和熔断机制，而不是把希望寄托在每个开发者都小心使用接口上。

⁠　　数据一致性要问的是：使用这份数据的人，是否知道它来自哪里、更新时间是什么、是否有效、是否和其他信号属于同一个时间窗口、是否经过滤波或补偿、是否允许跨任务异步读取。如果这些问题回答不清楚，所谓“同一个车速”在不同模块里就可能不是同一个工程对象。

图 3　工程问题：风险藏在哪，要从信号链、状态链和故障链一起看。

三、结论先说：安全架构要能留下证据

⁠　　如果只用一句话概括软件架构安全设计，那就是：安全架构不是让代码看起来整齐，而是让风险路径可追踪、失效传播可控制、验证结论可复现。图纸、需求、代码、测试、审查记录和问题单要能互相指向，否则架构只停留在汇报材料里。

⁠　　对死代码来说，关键不是“这段代码现在没跑到”，而是它为什么存在、还能不能被激活、是否会影响覆盖率和静态分析结论、是否会误导维护人员。安全相关项目里，不能把历史遗留逻辑当作无害背景，因为变体配置、编译开关和紧急修复都可能把旧逻辑重新带回执行路径。

⁠　　对级联失效来说，关键不是“每个模块内部都有错误处理”，而是模块之间有没有传播边界。一个模块进入故障状态后，下游看到的是明确的降级信号，还是一组仍然看起来合法但语义已经失真的数据，这是两种完全不同的安全架构。

⁠　　对数据一致性来说，关键不是“变量名统一”，而是数据契约统一。有效位、时间戳、序列号、刷新周期、坐标系、单位、滤波状态、来源优先级和失效策略，都应被视为接口的一部分。少了这些约束，接口表再漂亮，也不能支撑安全论证。

⁠　　因此，架构设计输出不应该只有静态模块图，还应该包含接口约束、故障传播分析、资源隔离策略、数据生命周期、调度约束、降级路径和验证映射。后续代码评审、单元测试、集成测试、故障注入、SIL/HIL 回归，都要能回到这些架构决策。

图 4　结论先说：架构安全不是一个点，而是一条从需求到验证的链路。

四、死代码为什么不是小事

⁠　　死代码在日常开发里很常见。旧功能下线后留下的函数，某个车型变体不再使用的分支，临时调试开关包裹的逻辑，条件编译里永远不会打开的宏，合并代码时被保留下来的兼容路径，都可能成为死代码的来源。

⁠　　在普通业务软件里，死代码主要带来维护成本和理解成本。但在安全相关控制软件里，它还会带来证据成本。功能安全开发强调需求、设计、实现、测试之间的追踪关系。如果一段代码没有需求来源，测试也无法说明它的目的，它就会成为安全论证里的疑点。

⁠　　更麻烦的是，死代码并不总是完全不可执行。有些代码在当前配置下不可达，在另一个车型、另一个软件版本、另一个编译选项下可能重新出现。有些分支在正常场景下不可达，在异常输入、数据溢出、状态恢复或诊断模式下可能被触发。工程师说“这段不会跑”，需要证据支撑，而不是凭印象判断。

⁠　　死代码还会干扰覆盖率解释。覆盖率不足可能来自测试缺失，也可能来自不可达代码。如果团队不区分这两类情况，就容易出现两种错误：要么为了追覆盖率写没有工程意义的测试，要么把真正漏测的安全路径误判为死代码。

⁠　　从架构角度看，死代码的风险不只在代码本身，还在它破坏了系统可理解性。维护人员看到旧接口、旧状态、旧故障码，可能会误以为这些设计仍然有效；新需求开发时，也可能沿用已经失效的路径，导致安全分析和实际实现逐渐分离。

⁠　　处理死代码不能只靠一次“大扫除”。更稳妥的做法是建立代码生命周期机制：新增代码必须能追踪到需求或问题单；废弃代码要有下线计划；变体代码要有配置边界；条件编译要被纳入构建矩阵；静态分析和覆盖率评审要区分不可达、无效、未测和暂存四种状态。

⁠　　对于安全相关模块，死代码清理还应和变更影响分析绑定。删除一段旧逻辑之前，要确认它没有被诊断、标定、售后、生产测试或特殊工况依赖。保留一段暂时不用的逻辑，也要说明保留原因、有效期限、责任人和验证策略。这样做看起来麻烦，但它能让未来的维护成本和安全风险可控。

图 5　死代码：看似无害的残留逻辑，也可能成为安全论证里的断点。

五、级联失效最怕“局部没问题”

⁠　　级联失效的危险之处在于，起点往往很小。一个传感器数据偶发异常，一个任务执行时间超限，一个通信队列堆积，一个共享变量被旧值覆盖，一个诊断标志更新晚了一拍，都可能通过架构耦合传到多个功能。

⁠　　很多项目复盘时会发现，单个模块拿出来看并没有明显错误。输入检查做了，错误码返回了，日志也记录了。但问题发生在模块之间：上游认为自己已经通知异常，下游却仍按正常数据使用；监控模块认为故障已经锁存，控制模块却在一个周期内使用了未更新的状态；通信模块降级了，应用层却没有进入匹配的安全状态。

⁠　　这类问题的根源通常不是某个 if 判断写错，而是架构边界没有定义清楚。谁拥有某个状态，谁可以修改某个数据，谁负责把故障从局部转换成系统级响应，谁在冲突时拥有最终裁决权，这些问题如果没有在架构阶段定下来，就会在集成阶段变成扯不清的责任边界。

⁠　　级联失效还常常来自共享资源。CPU 时间、内存、总线带宽、非易失存储、诊断服务、日志缓冲区、标定参数访问，都可能成为传播通道。一个非关键任务占用过多时间，可能影响关键控制任务调度；一个日志模块异常写入，可能拖慢故障处理；一个配置管理模块状态混乱，可能让多个功能同时进入不一致模式。

⁠　　安全架构要做的第一件事，是识别传播路径。信号传播、控制传播、状态传播、资源传播、故障传播都要画出来。不要只画“正常数据流”，还要画“错误怎么走”。真正有价值的架构图，不是把所有模块连得很整齐，而是能让评审者看见错误在哪里被挡住。

⁠　　第二件事，是设置传播边界。接口层要检查输入范围、有效性和时效性；资源层要限制非关键任务对关键资源的影响；调度层要保证关键任务的时间预算；诊断层要把局部故障转换为明确的系统状态；降级策略要说明哪些功能关闭、哪些功能保留、哪些输出需要限幅或冻结。

⁠　　第三件事，是让降级可预测。最糟糕的降级不是功能变少，而是行为不可解释。安全相关控制器在故障状态下可以降低性能，但不能让驾驶员、整车系统和维修人员面对一组互相矛盾的状态。架构设计要让每一种故障组合都有清晰优先级，而不是依靠后续调试临场补丁。

图 6　级联失效：一个局部故障如果没有边界，就可能扩散成系统风险。

六、数据一致性不是变量名一致

⁠　　底盘控制软件里，数据一致性是一个容易被低估的问题。车速、轮速、横摆角速度、纵向加速度、制动压力、方向盘角度、踏板行程，这些信号在系统里被多个模块使用。大家都说“用的是车速”，但实际可能来自不同源、不同周期、不同滤波链路和不同时间戳。

⁠　　数据一致性首先是来源一致。一个信号可能来自传感器直接采集，也可能来自融合估算、网络转发、诊断替代值或降级计算值。架构必须明确每个消费者在不同状态下使用哪个来源，来源切换时如何告知下游，切换后的数据质量如何表达。

⁠　　其次是时间一致。控制算法经常需要同时使用多个信号，如果这些信号属于不同采样时刻，就可能形成错误判断。比如车速已经更新，制动压力还是上一周期；横摆角速度来自高速任务，方向盘角度来自低速网络；有效位已经失效，数值却还停留在最后一次正常值。变量名一致不能解决这些问题。

⁠　　再次是语义一致。一个模块里的“valid”可能表示传感器硬件正常，另一个模块里的“valid”可能表示数据新鲜，还有一个模块里的“valid”可能表示信号通过了合理性检查。如果接口契约没有写清楚，下游会把不同语义的有效性当成同一个东西。

⁠　　数据一致性还包含原子性。多个相关信号如果分别读取，读取过程中上游发生更新，下游可能拿到一半新数据、一半旧数据。对于需要同步判断的控制逻辑，架构上应考虑快照机制、序列号检查、双缓冲或任务边界约束，保证一组数据在同一次计算中来自一致状态。

⁠　　还有一个常见问题是标定和配置数据。安全相关阈值、限幅、时间常数、故障判据如果来自标定系统，架构要说明它们的范围检查、版本匹配、失效默认值和在线更新策略。标定数据不是“参数而已”，它们直接改变控制逻辑，也必须纳入数据一致性管理。

⁠　　因此，一个合格的数据接口不只包含变量名和类型，还要包含单位、范围、刷新周期、时间戳、有效位、来源、坐标系、精度、默认值、失效策略和所有权。只有这些信息完整，下游模块才能知道自己拿到的数据能不能用、怎么用、什么时候不能再用。

图 7　数据一致性：同名数据不等于同一份工程语义。

七、架构机制要落到可执行规则

⁠　　安全架构不能停在“注意隔离”“加强检查”这种表达上。真正可落地的架构机制，必须能转化为接口规则、配置规则、调度规则、测试规则和评审规则。开发人员看到机制后，要知道自己在代码里具体该做什么，也要知道违反规则会被什么证据发现。

⁠　　接口契约是第一道防线。每个安全相关接口都应明确输入输出、数据范围、刷新周期、错误返回、无效值策略、边界行为和责任归属。接口不是为了让模块能连起来，而是为了让模块在异常状态下也能按约定失效。

⁠　　干扰隔离是第二道防线。安全相关功能与非安全相关功能之间，关键任务与普通任务之间，不同 ASIL 分解或不同风险等级的软件单元之间，都要考虑空间、时间和资源层面的相互影响。隔离不一定意味着物理分开，但必须说明如何防止一个功能的错误拖垮另一个功能。

⁠　　时间分区是第三道防线。控制周期、监控周期、诊断周期、通信周期之间要有优先级和预算。关键任务超时之后，是立即进入降级、丢弃本周期输出、冻结上一次安全输出，还是触发复位，不能到集成测试阶段再凭经验选择。

⁠　　内存保护和数据访问控制是第四道防线。安全相关状态不宜被多个模块随意写入，全局变量也不应成为跨层通信的便利通道。架构上应尽量定义清楚写权限、读权限、更新时机和一致性保护机制，减少“谁都能改一点”的隐性耦合。

⁠　　看门狗、健康监控和故障处理是第五道防线。它们不是系统最后才加上的保险丝，而应在架构阶段就与任务调度、状态机和降级策略绑定。监控到异常之后，系统进入什么状态、输出如何处理、故障如何锁存、恢复条件是什么，都要被定义。

⁠　　E2E 校验和通信保护是第六道防线。跨 ECU、跨核、跨进程的数据传输，不能只相信通信栈能把字节送到。对于关键数据，应考虑计数器、校验、超时、序列、重复、丢失和篡改检测等机制，并把处理结果映射到控制功能可理解的状态。

⁠　　降级模式是最后一道防线，也是最能体现架构能力的一道防线。安全设计不是要求系统永远不出错，而是要求出错时还能用可预测方式进入安全状态。降级策略要避免功能之间互相打架，也要避免把所有故障都粗暴处理成同一种状态。

图 8　架构机制：把接口、隔离、调度、保护、监控和降级变成规则。

八、验证不是跑一遍，而是形成证据链

⁠　　软件架构安全设计最终要靠证据说话。需求评审、架构评审、接口评审、代码评审、静态分析、单元测试、集成测试、故障注入、覆盖率分析、SIL/HIL 测试、台架和整车验证，都不是彼此孤立的活动，而应该形成一条可追踪证据链。

⁠　　需求追踪回答“为什么要做”。每一个安全相关机制都应该能回到安全需求或风险分析结论。比如某个数据有效位为什么必须存在，某个任务超时为什么要触发降级，某个接口为什么要做边界检查，都应能找到来源。

⁠　　静态分析回答“代码结构有没有明显风险”。死代码、不可达分支、未使用变量、越界访问、初始化问题、复杂度过高、隐式类型转换等问题，不一定每个都会直接导致安全事故，但它们会降低软件可理解性和可验证性。安全相关软件不应该把这些问题留给运气。

⁠　　覆盖率回答“测试有没有走到应走的路径”。但覆盖率不能被机械追求。对于不可达代码，要有合理解释和清理计划；对于安全机制相关路径，要确保正常、异常、边界、恢复、降级都被覆盖；对于异常组合，要结合故障注入和接口测试补足。

⁠　　接口测试回答“模块之间是否按契约互动”。很多系统问题不是单元内部错误，而是接口理解不一致。接口测试要覆盖非法值、过期值、无效位、抖动输入、重复帧、丢帧、超时、状态切换、初始化顺序和恢复路径。

⁠　　故障注入回答“故障发生时系统是否按架构预期响应”。传感器卡滞、通信超时、任务超时、内存错误、执行器反馈异常、参数越界、状态机冲突，都应尽量以可重复方式注入。只有这样，降级逻辑才能被证明，而不是停留在文档承诺。

⁠　　SIL/HIL 回归回答“变更之后旧证据是否仍然成立”。安全相关项目里，软件不是写完一次就结束。每次需求变更、缺陷修复、标定更新、平台迁移、编译器升级，都可能影响原来的证据链。回归测试的价值，是让团队知道哪些结论仍然可靠，哪些结论需要重建。

⁠　　验证证据链还有一个容易被忽视的要求：问题闭环。发现问题之后，不能只修代码，还要看需求、架构、接口、测试用例和风险分析是否需要同步更新。如果只修实现，不修证据，下一次审查仍然会出现解释缺口。

图 9　验证证据链：从需求到架构到代码，每个安全结论都要能被证明。

九、项目里最常见的四个误区

⁠　　第一个误区，是把“代码能跑”当成“架构安全”。功能跑通只是起点，安全相关架构还要面对异常输入、故障状态、时序压力、资源冲突和维护变更。能跑说明系统在某些条件下工作，不说明它在风险条件下仍然可控。

⁠　　第二个误区，是把死代码当成无影响。很多团队会说“这段没人调用，不用管”。问题在于，安全论证需要解释软件边界，代码仓库里的每一段安全相关逻辑都可能影响审查、覆盖率、维护和变更影响分析。看似不执行的代码，也可能成为未来误用的入口。

⁠　　第三个误区，是认为模块隔离靠开发人员自觉。自觉很重要，但不能成为架构机制。真正的隔离要靠接口、权限、调度、资源、状态所有权和验证规则来支撑。如果一个模块只要写错一个全局变量就能影响另一个关键功能，架构就没有真正隔离。

⁠　　第四个误区，是认为数据一致性靠命名规范。命名只能帮助阅读，不能保证工程语义。数据是否新鲜、是否有效、是否同步、是否同源、是否经过替代、是否允许复用，要靠接口契约和运行机制保证。没有这些约束，统一命名反而可能掩盖问题。

⁠　　还有一个隐性误区，是把标准当作检查清单，而不是工程方法。ISO 26262、AUTOSAR、MISRA、CERT 等标准和指南可以提供过程、架构、接口、编码和验证方面的框架，但项目真正是否安全，取决于团队能否把这些要求转化成具体产品里的工作产品和验证证据。

⁠　　成熟团队看架构，不会只看图画得漂不漂亮。他们会追问：风险路径在哪里，谁拥有数据，谁拥有状态，故障到哪里停止，降级是否唯一，复位是否可控，证据是否能回到需求，变更之后证据是否仍然有效。这些问题比架构图的视觉效果重要得多。

图 10　常见误区：安全架构必须可追踪、可隔离、可验证。

十、落地检查清单：评审时该看什么

⁠　　如果我是项目里的架构评审人，看一套安全相关软件架构，首先会看安全需求是否真正分配到了软件组件。每个组件承担什么安全责任，是监控、决策、执行、仲裁、诊断、上报还是降级，必须说清楚。只有责任清楚，后续接口和测试才有依据。

⁠　　第二看接口契约。输入输出是否完整，数据语义是否明确，异常输入如何处理，超时如何判断，边界值如何限幅，错误状态如何传递，调用顺序是否有要求，初始化和恢复路径是否定义。接口文档越接近代码实际行为，风险越容易被控制。

⁠　　第三看数据生命周期。一份关键数据从产生、滤波、融合、缓存、发布、消费、失效、替代到记录，是否有完整路径。谁能写，谁能读，什么时候更新，过期多久不能用，默认值是否安全，故障后是否会残留旧值，这些问题要逐项确认。

⁠　　第四看故障传播分析。每个关键模块故障之后，会影响哪些模块；影响通过数据、状态、资源还是通信传播；传播边界在哪里；下游如何识别；系统最终进入什么降级模式。没有传播分析的架构，很容易在系统集成阶段被偶发问题反复拖住。

⁠　　第五看调度和资源。关键任务周期是否满足控制需求，最坏执行时间是否留有余量，普通任务是否可能抢占关键任务，通信和存储是否可能阻塞安全路径，日志和诊断是否会在故障高发时放大资源压力。安全相关软件的时间行为和功能行为同样重要。

⁠　　第六看死代码和变体管理。不同车型、不同配置、不同编译选项下，哪些代码被构建，哪些逻辑可执行，哪些路径只是历史遗留。变体管理如果混乱，安全分析很容易只覆盖了“理想版本”，没有覆盖真实交付版本。

⁠　　第七看验证映射。每个安全机制有没有对应验证活动，每个验证活动有没有明确期望结果，每个问题有没有闭环证据。不要只问“有没有测试”，要问“这个测试能证明哪一条架构决策”。

⁠　　第八看量产维护。软件升级、标定更新、供应商组件变更、编译器变化、平台迁移、问题修复之后，安全架构证据如何更新。架构安全不是开发阶段的一次性动作，而是贯穿产品生命周期的工程能力。

⁠　　这些检查项看起来多，但它们的共同目标很简单：让风险路径暴露出来，让责任边界稳定下来，让验证证据留下来。做到这三点，项目在面对审查、集成问题和量产变更时，才不会靠临时解释硬撑。

十一、写给工程师：别只做模块，要做边界

⁠　　对软件工程师来说，架构安全最重要的能力不是会画多少层，而是能把自己负责的模块放到整车控制链路里理解。你写的一个状态位，可能影响另一个功能是否进入降级；你保留的一段旧代码，可能影响覆盖率解释；你少写的一个时间戳，可能让下游误用过期数据。

⁠　　对系统工程师来说，架构安全最重要的能力是把需求说清楚。不要只写“系统应具备故障处理能力”，而要写清楚故障类型、检测条件、响应时间、降级状态、恢复条件和驾驶员感知。软件团队最怕的不是需求严格，而是需求模糊。

⁠　　对功能安全工程师来说，架构安全最重要的能力是把安全分析落到实现证据。安全机制不能只停留在安全计划或安全概念里，要能在架构、接口、代码、测试和问题闭环中看到对应物。否则评审时看似材料完整，项目真正出问题时仍然找不到责任边界。

⁠　　对质量和项目管理来说，架构安全最重要的能力是守住流程闭环。很多低级问题不是因为工程师不知道，而是因为变更太急、接口没审、问题没闭环、证据没更新。流程不是为了增加负担，而是为了在复杂项目里保留集体记忆。

⁠　　优秀的安全相关软件架构，最后会呈现出一种朴素的特征：关键数据有来处，关键状态有主人，关键故障有边界，关键变更有证据。它不一定看起来炫，但在项目出问题时，能让团队快速定位、解释和修复。

图 11　收束：把风险挡在架构边界内，才是安全设计的价值。

十二、最后总结

⁠　　死代码、级联失效、数据一致性，分别对应软件安全架构里的三个基本问题：代码边界是否干净，故障边界是否稳定，数据边界是否可信。任何一个问题没有处理好，都会削弱安全机制的可解释性和可验证性。

⁠　　安全相关软件从来不是靠某一个天才模块完成的，而是靠一组稳健的工程约束共同工作。接口契约、资源隔离、时间分区、内存保护、健康监控、通信保护、降级策略和证据链，听起来都不新鲜，但真正做扎实并不容易。

⁠　　很多项目的架构问题，早期不会表现为严重故障，而是表现为解释困难：为什么这段代码存在，为什么这个数据能用，为什么这个故障不会扩散，为什么这次变更不影响安全。解释不清楚，就是风险已经在积累。

⁠　　所以，判断一套软件架构是否安全，不要只看它是否分层，也不要只看它是否通过了几轮测试。更应该看它能否把风险限制在边界内，把异常转化为明确状态，把验证结果连接回需求，把变更影响留在证据链里。

⁠　　对于底盘控制软件尤其如此。车辆动态控制面对的是连续变化的物理世界，输入有噪声，执行器有滞后，通信有延迟，驾驶员有预期，系统还有故障和老化。软件架构如果不能承载这些不确定性，代码写得再漂亮也只是局部正确。

⁠　　真正值得信赖的架构，是出了问题之后仍然能解释：哪个风险被触发，哪个机制识别了它，哪个边界挡住了它，系统为什么进入这个状态，验证证据在哪里。做到这一点，安全设计才从文档变成了产品能力。

文章图片来源于网络，若有侵权，请联系删除。