3. 平台需求分析与功能规划
标定自动化与批量试验平台不是“把手工标定脚本搬到网页上”这么简单。它要同时服务算法工程师、试验操作员、设备管理员和项目负责人，既要能驱动转台、采集卡、CAN 总线等真实设备，又要能管理成百上千组试验任务与数据。因此，需求分析的第一步不是列功能，而是先把“谁在用、在什么场景下用、需要平台替他承担什么”讲清楚。本节围绕用户角色、功能模块、非功能需求和优先级划分四条主线展开，并给出一份可直接用于需求评审的优先级矩阵示例。
一、用户角色与核心诉求
平台的角色划分应基于职责边界，而不是组织架构。典型可归纳为四类：
- 算法/标定工程师：定义标定对象与参数（如零偏、标度因数、安装误差角），配置激励轨迹与评价指标，分析标定结果并迭代模型。核心诉求是“可复现、可对比、可追溯”。
- 试验操作员：执行批量试验，负责设备上电、工装装夹、任务下发、异常处置。核心诉求是“少手工、少出错、状态可见”。
- 设备/平台管理员：维护转台、采集设备、电源、总线接口的驱动与资源占用，管理账号与权限。核心诉求是“资源不冲突、故障可定位”。
- 项目/质量负责人：关注试验进度、通过率、数据完整性与报告输出。核心诉求是“看板清晰、结论可信”。
角色确定后，权限模型应落到“功能权限 + 数据权限”两层：功能权限控制能否创建任务、修改标定模型、删除数据；数据权限控制能看哪些项目、哪些设备、哪些批次的数据。例如操作员可执行任务但不能修改标定算法参数，工程师可修改模型但不能删除原始采集数据，这样既保证效率又保证数据可追溯。
二、功能模块划分
功能模块建议按“数据流经平台的顺序”划分，而不是按页面划分，这样模块边界清晰、接口稳定。可归纳为六个模块：
- 设备与资源管理：设备台账、驱动适配、通道映射、资源锁。例如转台轴号、采集卡通道、CAN 通道与波特率都登记在此，任务下发前先申请资源锁，避免两台任务同时占用同一转台。
- 标定模型与参数配置：管理标定对象、待标参数、激励轨迹模板、评价指标。例如某 IMU 标定任务中，待标参数为零偏（3 个）、标度因数（3 个）、非正交误差（3 个），激励轨迹为“静止 30 s → 绕 X 轴 ±30° 正弦 → 绕 Y 轴 ±30° 正弦 → 绕 Z 轴 ±30° 正弦”。
- 任务编排与批量调度：把“设备 + 模型 + 参数组合 + 重复次数”组织成任务，支持批量生成与队列调度。例如对 5 个温度点 × 3 个转速点共 15 组工况批量生成任务。
- 数据采集与处理：原始数据落盘、时间同步、预处理、标定解算。原始数据必须保留，处理结果可重算，这是可追溯性的底线。
- 结果分析与报告：残差曲线、参数收敛过程、通过/失败判定、报告导出。
- 系统管理与审计：账号、权限、操作日志、任务日志。
模块之间通过明确的数据契约衔接：任务模块只认“设备 ID + 模型 ID + 参数集”，采集模块只认“通道配置 + 采样率 + 触发方式”，解算模块只认“原始数据路径 + 标定模型版本”。契约稳定，后续替换设备或算法才不会牵一发动全身。
三、非功能需求
非功能需求往往决定平台能否真正用于批量试验，需给出可验证指标：
- 实时性与同步：采集与激励的时间同步误差应可控，例如要求转台指令与采集起始的同步偏差 ≤ 1 ms；采样率需覆盖被标信号带宽，如 1 kHz。
- 可靠性与恢复：单任务失败不应导致整批中断，支持断点续跑；原始数据写入采用“先落盘、后处理”，异常断电后数据可恢复。
- 可扩展性：新增设备类型或标定算法时，不改动调度与数据模块，仅新增驱动或算法插件。
- 性能：批量任务调度响应时间、单批次数据吞吐量、报告生成时间需给出上限，例如 100 组任务下发 ≤ 5 s。
- 安全与审计：关键操作（修改模型、删除数据、下发任务）必须留痕，日志包含操作人、时间、对象、前后值。
- 易用性：操作员完成一次“选任务—下发—监控—导出”的路径应尽量短，异常状态需有明确提示与处置建议。
四、优先级划分
优先级不能只按“重要/紧急”拍脑袋，建议用“业务价值 × 实现风险”二维判断，并明确 MVP 边界。下面给出一份可直接用于需求评审的优先级矩阵示例（示例为合理假设，非实测数据）：
| 功能项 | 业务价值 | 实现风险 | 优先级 | MVP 是否包含 |
|---|---|---|---|---|
| 设备资源锁与任务队列 | 高 | 中 | P0 | 是 |
| 原始数据落盘与追溯 | 高 | 低 | P0 | 是 |
| 标定模型与参数配置 | 高 | 中 | P0 | 是 |
| 批量任务生成与断点续跑 | 高 | 高 | P1 | 是（基础版） |
| 结果分析与报告导出 | 中 | 低 | P1 | 是（基础版） |
| 多设备并行调度 | 中 | 高 | P2 | 否 |
| 算法插件热加载 | 中 | 中 | P2 | 否 |
| 可视化看板与统计 | 低 | 低 | P3 | 否 |
划分原则是：P0 是“没有它平台无法完成一次完整标定闭环”的能力；P1 是“批量试验效率与可信度”的关键；P2 是规模化与扩展能力；P3 是体验增强。MVP 阶段应把 P0 全部做扎实，P1 做基础版，避免一开始就追求多设备并行和插件化而拖垮主线。
把上述四层串起来看：角色决定权限边界，功能模块决定系统骨架，非功能需求决定工程底线，优先级决定迭代节奏。需求评审时，建议逐条追问三个问题——这条需求服务哪个角色？落在哪个模块？属于哪个优先级？如果三个问题都答不上来，这条需求大概率是伪需求或应推迟。完成本节的需求梳理后，后续的架构设计、接口定义与测试用例都可以直接以这份角色—模块—非功能—优先级清单为输入，避免开发过程中反复返工。