4、硬件产品需求分析:从工业场景出发,如何收集用户需求、定义功能规格、确定性能指标(如温度范围、防护等级、功耗、可靠性)

工业物联网(IIoT)硬件产品的需求分析,与消费电子有着本质区别。消费电子追求“体验优先、快速迭代”,而工业硬件则遵循“场景驱动、可靠性优先、全生命周期成本可控”的原则。在工业现场,一台网关或传感器可能被部署在高温高湿的车间、粉尘弥漫的矿山、或零下三十度的户外变电站,其工作环境远比办公室严苛。本章将围绕“从工业场景出发”这一核心,系统拆解如何将模糊的现场痛点转化为可量化、可测试、可交付的硬件需求规格(HRS,Hardware Requirements Specification)。

IIoT硬件需求分析工程链路 ① 工业场景识别 温度/湿度/振动/粉尘 EMC/防爆/安装空间 ② 用户需求收集 现场访谈/问卷/日志 痛点→需求→期望 ③ 功能规格定义 功能树/接口/协议 数据流/控制流 ④ 性能指标 温度/防护/功耗 可靠性/MTBF 需求验证与迭代反馈 硬件需求规格书(HRS)输出 功能规格 + 性能指标 + 测试标准 + 验收条件 功能规格定义 · 功能树分解 · 接口/协议定义 · 数据流与控制流 性能指标量化 · 环境适应性(温度/湿度) · 防护等级(IP/IK) · 功耗与可靠性(MTBF) 验证与评审 · 需求可测试性检查 · 对标竞品/行业标准 · 内部评审/客户确认 关键输出物 需求追溯矩阵(RTM) | 功能规格书(FRS) | 性能指标表(PIS) | 测试用例基线 评审签字版 | 变更控制流程

4.1 工业场景驱动的需求收集:从现场到需求池

核心原理:工业场景的复杂性决定了需求收集不能依赖“头脑风暴”或“竞品抄板”。IIoT硬件(如边缘网关、智能传感器、工业路由器)的需求源头是物理环境、业务流程、维护模式与安全合规的交集。需求收集的本质是建立“场景-角色-痛点-需求”的映射关系。例如,一个部署在钢铁厂连铸机旁的振动传感器,其需求不是“测量振动”,而是“在85℃热辐射、水汽凝结、强电磁干扰环境下,连续运行2年且误差小于±5%”。

操作流程:建议采用“五步现场工作法”进行需求收集:

  1. 现场踏勘(Gemba Walk):工程师必须亲自到安装点位,记录环境参数(温度、湿度、粉尘、振动、空间尺寸)、供电条件(是否有220V AC、24V DC、电池)、网络条件(有线/无线/光纤)。
  2. 干系人访谈:分别访谈设备操作工(关注易用性)、设备维护工程师(关注可维护性、故障诊断)、生产管理者(关注数据准确性、OEE提升)、IT/OT管理员(关注网络安全、协议对接)。
  3. 历史数据分析:从现有设备PLC、SCADA或手工记录中提取故障频率、停机时长、环境极端值,作为可靠性指标的输入。
  4. 竞品与标准对标:参考同类产品的公开规格书,同时检索IEC、GB、UL等标准对防护、EMC、防爆的要求。
  5. 需求工作坊:将收集到的原始需求(Raw Requirement)进行归类、去重、优先级排序(MoSCoW法:Must/Should/Could/Won't)。
实战案例:某风电企业需要升级风机机舱内的温湿度传感器。初始需求仅为“测量温度湿度”。通过现场踏勘发现:机舱内存在强电磁干扰(变频器)、温度范围-30℃~+65℃、安装空间狭小(直径小于40mm)、维护窗口每年仅2次。进一步访谈得知,现有传感器因凝露导致PCB腐蚀,平均寿命仅8个月。最终将需求修正为:“在-40℃~+85℃存储、-30℃~+70℃工作,防护等级IP65,具备防凝露涂层,MTBF≥10万小时,采用M12航空插头连接,支持Modbus RTU输出”。这一修正直接避免了后续研发阶段的重大返工。
常见误区:① 只收集“用户说的需求”,忽略“用户没说的环境约束”;② 将“解决方案”误当“需求”(如用户说“我要用4G”,实际需求是“数据需远程可访问”,可能WiFi或LoRa更合适);③ 忽略安装与维护约束,导致产品设计出来无法在现场安装或维修。

4.2 定义功能规格:从需求到可验证的功能树

核心原理:功能规格(Functional Specification)描述系统“做什么”,不涉及“怎么做”。在IIoT硬件中,功能规格通常分为三类:核心功能(数据采集、处理、传输)、辅助功能(本地显示、按键配置、远程升级)、管理功能(设备自检、日志记录、安全认证)。功能规格必须满足“可测试性”——每一条功能都应能对应到具体的测试步骤或验收标准。

功能树分解方法:

功能层级 功能模块 功能描述(示例) 验收标准
L1 核心 数据采集 支持4路4-20mA模拟量输入,16位ADC 精度±0.1%FS,采样率≥100Hz
L1 核心 边缘计算 本地实现阈值报警、数据滤波 报警响应时间≤200ms
L2 辅助 人机交互 0.96寸OLED显示,3个按键 按键寿命≥10万次,显示无残影
L3 管理 远程升级 支持OTA固件升级,断点续传 升级失败可回滚,不影响运行

接口与协议定义:功能规格必须明确物理接口(端子类型、引脚定义、电气特性)和通信协议(Modbus寄存器地址表、MQTT Topic定义、JSON数据格式)。例如,定义RS485接口时,需明确:半双工、波特率9600-115200bps、校验位None/Even/Odd、终端电阻是否内置。

经验提醒:功能规格书(FRS)建议采用“用例(Use Case)”方式描述。例如:“用例UC-01:维护人员通过USB连接设备,使用配置工具修改IP地址。前置条件:设备已上电,USB驱动已安装。主流程:打开工具→扫描设备→输入新IP→点击写入→设备重启生效。异常流:设备无响应时提示错误码E1001。”这种描述方式能极大减少开发与测试的歧义。

4.3 确定性能指标:量化环境、防护、功耗与可靠性

核心原理:性能指标是硬件设计的“硬约束”,直接决定元器件选型、结构设计、散热方案和成本。IIoT硬件性能指标需从四个维度量化:环境适应性(温度、湿度、振动、盐雾)、防护能力(IP等级、IK等级、防爆)、功耗预算(平均功耗、峰值功耗、待机功耗)、可靠性(MTBF、MTTR、使用寿命)。

关键指标确定方法:

  • 温度范围:不能简单照搬“-40℃~+85℃”。需区分存储温度(非工作状态)和工作温度(上电运行)。工业级元器件通常选择-40℃~+85℃(I级)或-40℃~+105℃(扩展级)。需结合现场实测数据,例如户外机柜内部温度可能比环境高15℃。
  • 防护等级(IP):根据安装位置选择。室内控制柜内可选IP20,户外无遮挡必须IP65以上,矿山/粉尘环境建议IP67。注意IP65与IP67的区别:IP65防喷水,IP67防短时浸水。若设备有散热孔,则无法达到高IP等级,需权衡散热与防护。
  • 功耗预算:需列出所有模块的功耗明细:MCU(如STM32H743:~300mW)、4G模块(峰值2W,平均0.5W)、传感器(~50mW)、LED指示(~30mW)。若采用电池供电,需计算电池容量(mAh)与目标寿命(如3年)的关系,并考虑低温下电池容量衰减(-20℃时锂电池容量约下降30%)。
  • 可靠性指标:MTBF(平均无故障时间)通常通过元器件应力分析(MIL-HDBK-217F)或参考同类产品预估。例如,一个包含MCU、电源模块、通信模块的网关,MTBF目标可设为≥50,000小时(约5.7年)。同时需定义MTTR(平均修复时间),影响备件策略。
案例拆解:工业边缘网关功耗与可靠性设计
背景:某油田项目需要部署无线边缘网关,采用太阳能+蓄电池供电,要求连续阴雨天工作7天。
关键输入:网关平均功耗3.5W(含4G通信),太阳能板功率20W(峰值),蓄电池12V/20Ah。
分析过程:① 日耗电量 = 3.5W × 24h = 84Wh;② 蓄电池有效容量 = 12V × 20Ah × 0.7(放电深度) = 168Wh;③ 可支撑时间 = 168Wh / 84Wh = 2天,远小于7天要求。
调整方案:① 降低采样频率(从1s改为10s),平均功耗降至1.8W;② 增加太阳能板至30W;③ 采用低功耗4G模块(平均功耗0.8W)。优化后日耗电43.2Wh,蓄电池可支撑3.9天,结合太阳能补充,满足7天阴雨要求。
复盘:功耗预算必须考虑“最恶劣工况”(如低温、弱信号时4G模块发射功率增大),且需预留15%设计余量。
常见误区:① 盲目追求高指标(如所有器件都选军品级),导致成本失控;② 忽略“指标之间的耦合”,例如提高防护等级(IP67)会导致散热变差,进而影响工作温度范围;③ 可靠性指标只写MTBF,不定义“环境条件”,导致测试无法复现。

4.4 需求评审与基线化:确保可追溯、可验证

核心原理:需求分析的最后一步是建立需求基线(Baseline),并形成需求追溯矩阵(RTM,Requirement Traceability Matrix)。RTM将每条需求与设计文档、测试用例、验证结果关联,确保“需求-设计-测试”闭环。在IIoT硬件开发中,需求变更不可避免(如客户新增一种协议),因此必须建立变更控制流程(CCB,Change Control Board)。

评审检查清单:

检查项 检查标准 通过/失败
完整性 是否覆盖所有场景(正常、异常、边界)? 通过
可测试性 每条需求是否有明确的测试方法? 通过
一致性 指标之间是否矛盾?(如IP67与散热) 需调整
可追溯性 每条需求是否关联到具体干系人? 通过

评审流程:建议组织“红队评审”(Red Team Review),由未参与需求收集的硬件工程师、测试工程师、产品经理组成,从不同视角挑战需求的合理性。评审输出物包括:评审记录、问题清单、需求修订版。最终由产品经理、技术负责人、客户代表三方签字确认,形成基线。

经验提醒:需求基线一旦建立,后续任何变更必须走“变更申请→影响分析(成本/进度/性能)→CCB审批→更新基线”流程。在硬件开发中,需求变更越晚,代价越大(改PCB比改需求文档贵100倍)。建议在项目启动时预留5%-10%的变更缓冲预算。

总结复盘:IIoT硬件需求分析的核心是“场景-需求-指标”的层层映射。本章强调:① 需求收集必须深入现场,用数据说话;② 功能规格必须可测试,避免模糊描述;③ 性能指标必须量化,并考虑指标间的耦合;④ 需求基线是项目管理的基石,必须严格管控变更。只有将需求分析做扎实,后续的硬件设计、打样、测试才能有的放矢,避免“边做边改”的恶性循环。