适用场景

这份清单适合用于机器人项目的系统设计评审前自查,也适合在评审会上作为追问框架。它不解决所有设计细节,而是帮助团队判断:项目是否已经具备进入详细设计的条件。

核心判断

系统设计评审不是检查方案页是否完整,而是确认目标、架构、接口、资源、安全、风险和验证是否已经形成基本闭环。

1. 目标和边界

检查项

需要确认的问题

未确认的风险

使用场景

机器人在哪些环境中运行?

后续方案按各自理解补场景

任务范围

执行哪些任务,不执行哪些任务?

功能边界扩大,设计发散

使用对象

谁操作,谁维护,是否无人值守?

交互、提示、维护策略不一致

成功标准

什么结果算任务成功?

测试和验收口径不一致

失败处理

失败后停机、重试、报警还是人工处理?

异常流程靠现场补

2. 总体架构

链路

评审追问

感知链路

传感器是否覆盖关键场景?数据用于显示还是控制?

控制链路

指令如何下发,反馈如何回来,实时控制由谁完成?

供电链路

电源是否支撑整机峰值和任务循环?

通信链路

模块之间如何通信,超时和中断如何处理?

安全链路

急停、限位、驱动关断是否进入架构?

异常链路

异常后系统进入什么状态,如何恢复?

3. 关键技术路线

技术点

需要的依据

扭矩 / 负载

计算、样机测试、历史复用经验

传感器可靠性

场景测试、环境适应性验证

算法实时性

延迟测试、算力评估、仿真结果

续航和功耗

功耗预算、任务循环测试

控制周期

控制链路测量、闭环验证

判断标准:关键技术路线不能只靠“应该可以”,至少要有计算、仿真、实验、样机验证或明确的验证计划。

4. 子系统边界和接口

检查项

关键问题

责任边界

机械、电气、控制、软件、算法、测试分别负责什么?

状态来源

哪些状态由谁提供?

判断条件

哪些条件由谁判断?

动作执行

哪些动作由谁执行?

结果确认

哪些结果由谁确认?

接口状态

正常、等待、超时、异常、恢复如何定义?

接口不应只写“能通信”。至少要明确谁发起、谁响应、什么算正常、什么算超时、异常后怎么恢复。

5. 性能和资源预算

预算类型

典型内容

重量

整机重量、子系统重量、结构余量

功耗 / 续航

平均功耗、峰值功耗、任务循环续航

算力

主控算力、算法负载、实时任务资源

通信带宽

传感器数据、控制数据、日志数据

热设计

发热源、散热路径、环境温度

成本

核心部件、结构加工、装配维护成本

精度误差

传感器误差、机械误差、控制误差

评审重点:每个局部都合理,不代表整机一定成立。资源预算要放到整机里看。

6. 安全和异常策略

场景

要确认的问题

急停触发

哪些执行机构必须关断?谁确认关断完成?

通信中断

系统暂停、降级还是停机?

传感器异常

数据无效时控制策略如何处理?

驱动报警

谁停止,谁恢复,谁提示?

人员介入

是否允许继续动作?

电池保护

低电量、过流、过温如何处理?

安全和异常策略如果前期没有定义,后面通常不是补几句说明,而是补状态、补接口、补日志、补恢复流程。

7. 关键风险和验证路径

风险

建议验证方式

扭矩不足

计算 + 工况测试

续航不足

标准任务循环测试

算法延迟

端到端延迟测量

避障不稳定

场景覆盖测试

安全链路不完整

急停 / 故障注入测试

问题无法关闭

日志、复现条件、复测标准

评审输出建议

系统设计评审结束时,不建议只输出“原则通过”。建议形成以下交付物:

  • 目标和边界确认记录

  • 系统架构和关键链路说明

  • 关键技术路线依据

  • 子系统边界和接口问题清单

  • 性能与资源预算表

  • 安全与异常策略清单

  • 关键风险与验证计划

  • 下一阶段详细设计输入

一句话总结

系统设计评审不是看方案页是否完整,而是判断项目是否已经具备进入详细设计的条件。

Logo

DAMO开发者矩阵,由阿里巴巴达摩院和中国互联网协会联合发起,致力于探讨最前沿的技术趋势与应用成果,搭建高质量的交流与分享平台,推动技术创新与产业应用链接,围绕“人工智能与新型计算”构建开放共享的开发者生态。

更多推荐