4. 可追溯性需求分析

仿真数据谱系能否真正发挥作用，取决于追溯需求是否被正确识别。追溯需求分析的核心任务，是把“谁在什么场景下需要沿着谱系查到什么程度”转化为可执行的粒度与深度指标。粒度回答“追到多细”，深度回答“追到多远”，两者共同决定谱系模型的存储结构、元数据字段和查询能力。

三类典型场景的追溯诉求差异

型号研制、适航认证与科研复现对追溯的要求并不相同，若用同一套粒度与深度标准覆盖全部场景，要么造成存储与维护成本浪费，要么在关键审查中无法提供足够证据。

型号研制场景强调“快速定位变更影响”，因此粒度需下沉到参数与工况，深度覆盖从几何模型到结果文件的主链即可。适航认证场景强调“证据可审查”，粒度必须包含文件版本、签署人、审批时间戳，深度需延伸到需求条目与验证报告，形成闭环。科研复现场景强调“他人可重跑”，粒度需精确到脚本、依赖库版本与随机种子，深度不必很长，但每一环都必须可获取。

粒度设计：从对象到字段

粒度设计的第一步是确定追溯对象。以典型的CAE仿真为例，可追溯对象包括：几何模型文件、网格文件、材料参数卡、边界条件设置、求解器版本与编译选项、运行脚本、输入deck、结果文件、后处理脚本、报告文档。每个对象需要绑定唯一标识（如UUID或内容哈希）、版本号、生成时间、生成者、父对象引用。

粒度并非越细越好。若把每个求解器内部迭代步都纳入谱系，存储与查询开销会急剧上升，而审查方通常只关心“输入—版本—结果”这条主链。合理的做法是分层：主链对象记录完整元数据，中间过程对象仅记录摘要与哈希，需要时再按哈希回溯到原始文件。

深度设计：正向与反向追溯路径

深度设计要同时考虑正向追溯（从需求/输入追到结果）和反向追溯（从结果追回输入与版本）。适航认证通常要求双向可追，型号研制更常用反向追溯定位问题，科研复现则以正向追溯为主。

深度层数可用“追溯跳数”度量。例如某型号研制项目规定：从结果文件出发，最多3跳必须到达网格与几何版本，最多5跳必须到达需求条目。若某条路径超过规定跳数，说明谱系中存在断链或冗余中间对象，需要补齐引用或合并节点。

从需求到谱系模型的落地方法

把追溯需求转化为谱系模型，可按以下顺序推进。首先，针对每个场景列出“追溯问题清单”，例如“结果R的网格版本是什么”“该版本由谁在何时生成”“对应需求条目是哪条”。其次，为每个问题定义所需字段与最大跳数，形成粒度—深度矩阵。再次，检查现有数据源能否提供这些字段：仿真脚本是否输出版本号？求解器日志是否记录编译选项？文件系统是否保留哈希？缺失的字段需要在流程中补采。

以某科研复现项目为例，其追溯需求为：论文中的图3可由脚本重跑得到。对应粒度要求为脚本文件、依赖库版本、随机种子、输入数据哈希；深度要求为数据→脚本→参数→结果，共3跳。落地时在脚本头部写入环境快照，运行结束后自动生成谱系记录，包含上述字段。复现者拿到谱系记录后，按哈希校验数据、按版本安装依赖、按种子重跑，即可判断结果是否一致。

追溯需求的验证与迭代

需求分析完成后，需要用真实或构造的追溯查询验证粒度与深度是否足够。验证方法包括：随机抽取一个结果文件，尝试在限定跳数内回答预设问题清单；若某问题无法回答或跳数超限，则回到矩阵调整粒度或补充引用。适航场景还应模拟审查方提问，检查审批链、签署时间戳与工具确认记录是否完整。

追溯需求不是一次性的。型号进入不同阶段（方案、详细设计、试验、定型），追溯粒度与深度会变化；适航审定基础版本更新也会引入新的证据要求。因此，粒度—深度矩阵应作为受控文档纳入配置管理，随阶段评审同步更新，并在谱系系统中以规则形式固化，使新增数据自动按最新要求采集。

综上，追溯需求分析的本质是场景驱动的粒度与深度权衡。先明确“谁问什么”，再定义“追到多细、追到多远”，最后用查询验证并迭代。只有把需求转化为可检查的字段与跳数指标，仿真数据谱系才能从概念走向可执行、可审查、可复现的工程能力。