很多智能硬件项目最初只有一句比较简洁的描述:
“做一个能采集数据并连接手机的设备。”
或者:
“需要一个带Wi-Fi、可以远程控制的硬件。”
从产品方向来看,这些描述已经能够说明目标,但对于真正进入研发还远远不够。
智能硬件开发通常涉及硬件电路、嵌入式软件、通信、结构、电源、电池,以及根据项目需要配置的APP、Web系统、服务端或设备管理平台。前期一个没有明确的小问题,可能在后面同时影响主控选型、PCB尺寸、功耗、结构、软件架构和项目成本。
因此,在正式开始原理图或PCB设计之前,更重要的工作往往不是“尽快选芯片”,而是先把产品需求转换成可以执行的工程条件。

产品需求和工程需求不是完全相同的概念。
例如产品提出:
设备需要通过手机查看数据。
从研发角度还需要继续确认:
手机与设备通过BLE还是Wi-Fi连接;
手机只是近距离读取,还是需要远程查看;
是否必须注册账号;
数据是否上传服务器;
是否保存历史数据;
多台设备是否需要绑定到同一用户;
设备断网以后如何工作;
是否需要远程控制;
是否需要OTA升级。
不同答案,对应的是完全不同的系统架构。
如果只是手机通过BLE近距离读取数据,设备可能不需要云端。
如果用户需要异地查看,则通常需要继续考虑:
设备联网 → 服务端 → 数据存储 → APP/Web → 用户与设备关系
因此,智能硬件前期需求梳理真正要解决的是:
把“想实现什么功能”进一步转换成“设备如何实现这些功能”。
智能硬件项目很容易在早期不断增加功能。
例如一个最初只需要采集温度的设备,讨论过程中可能陆续增加:
蓝牙;
Wi-Fi;
屏幕;
蜂鸣器;
GPS;
本地存储;
OTA;
APP;
远程报警。
如果这些功能没有优先级,主控、PCB、电池、结构和软件范围都会持续变化。
因此建议先把功能划分为三类。
没有这些功能,产品核心价值就无法成立。
例如:
数据采集;
设备控制;
BLE连接;
必要的报警功能。
本版本希望实现,但如果影响周期或成本,可以根据项目情况讨论。
暂时不在首版实现,但已经明确后续版本可能增加。
这种划分非常重要。
因为后续功能即使暂时不开发,也可能影响首版硬件预留。
例如首版不需要OTA,但第二版明确要远程升级,那么Flash容量和软件架构最好在第一版选型阶段就考虑。
很多智能硬件本质上首先是一台数据采集设备。
常见数据包括:
温度;
湿度;
压力;
加速度;
姿态;
光照;
距离;
电流;
电压;
生理参数;
位置信息。
但“需要测温度”和“需要测到什么程度”是两个不同问题。
项目至少应该明确:
测量范围;
精度要求;
分辨率;
采样频率;
传感器数量;
传感器位置;
是否连续采样;
是否需要校准;
数据是否需要本地处理。
例如环境温度监测与高速振动采集,对采样率、ADC、MCU、缓存和通信的要求完全不同。
如果采集指标没有明确,就很难判断:
应该使用什么传感器、需要多少主控资源,以及后续产生多少数据。
智能硬件常见通信方式包括:
BLE;
Wi-Fi;
4G/5G;
Ethernet;
RS485;
CAN;
NFC;
其他无线或有线通信方式。
不同通信方式解决的问题不同。
比较适合:
手机近距离连接;
配置设备;
数据量不大的传输;
低功耗设备;
本地设备控制。
如果产品并不需要一直连接互联网,而主要与附近手机交互,BLE通常值得优先评估。
适用于设备需要:
连接局域网;
直接访问互联网;
持续或周期上传数据;
接受云端控制;
进行OTA升级。
但Wi-Fi会明显影响功耗、联网逻辑和配网流程。
如果设备没有稳定Wi-Fi环境,又需要独立联网,就可能考虑4G、5G或其他蜂窝通信方式。
这又会进一步影响:
SIM/eSIM;
天线;
功耗;
网络资费;
模组成本;
弱网处理。
因此,通信选型不能只问:
“要不要Wi-Fi?”
更应该问:
设备在什么环境中工作、谁连接它、数据最终需要到哪里。
智能硬件并不等于“必须有APP”。
有些设备只需要本地控制或接入已有系统,并不需要单独开发移动应用。
但如果项目存在以下需求:
用户注册;
设备绑定;
远程查看;
多设备管理;
历史数据;
消息提醒;
设备控制;
OTA;
权限管理;
那么系统范围就已经不再只是硬件本体。
可能需要形成:
终端硬件 + 嵌入式系统 + 通信接入 + 服务端 + APP/Web + 数据管理
如果设备本身属于IoT系统的一部分,还可能进一步涉及设备身份、平台接入、远程命令、在线状态、告警和批量设备管理。
因此项目启动前最好明确:
本次开发的是一台独立设备,还是一个包含设备端和应用端的完整系统。
北京心玥科技的软件开发既可以作为智能硬件、IoT等项目的组成部分,也可以根据项目需求独立承接。实际范围应根据产品边界确定,而不是默认所有硬件项目都必须配置APP或平台。
“低功耗”是智能硬件需求中最常见、也最容易描述不清的条件之一。
工程上真正需要知道的是:
使用什么电池;
电池容量;
目标续航多久;
是否可以充电;
设备多久采样一次;
多久通信一次;
是否必须保持在线;
屏幕是否常亮;
传感器能否休眠;
是否存在高功耗执行器。
例如两个都写着“低功耗BLE设备”的产品,一个要求纽扣电池工作一年,另一个使用可充电锂电池工作一周,设计逻辑可能完全不同。
更合理的方法是建立功耗预算:
休眠功耗 + 采样功耗 + 处理功耗 + 通信功耗 + 其他外围功耗
再结合各状态持续时间,估算平均电流。
之后才能进一步判断:
MCU平台;
无线方案;
电源芯片;
电池;
软件休眠策略。
很多硬件项目在早期只关注功能,PCB完成以后才开始认真考虑外壳。
这样容易产生一些典型问题:
PCB放不进去;
电池空间不足;
USB接口位置不合理;
天线被金属结构遮挡;
按键和LED位置不匹配;
连接器无法装配;
螺丝柱与PCB器件冲突;
散热空间不足。
因此,即使结构设计还没有完全完成,也建议尽早确认:
产品大致尺寸;
PCB最大尺寸;
电池位置;
接口位置;
显示屏;
按键;
指示灯;
安装孔;
天线区域;
外壳材料;
是否需要防水防尘;
设备如何固定或安装。
尤其对于BLE、Wi-Fi、4G等无线设备,天线附近的材料和结构会直接影响通信性能。
所以PCB、结构和天线设计不应该完全割裂。
智能硬件中的Wi-Fi、BLE、4G等功能,往往可以选择:
芯片级设计
或者
成熟模组
两种路线。
使用模组通常可以减少部分射频和认证相关开发工作,比较适合:
样机阶段;
研发周期较紧;
产品数量暂时不大;
团队希望降低RF设计难度。
芯片级方案则可能在:
PCB空间;
大批量BOM;
深度定制;
产品集成度;
方面具有更多优化空间。
但芯片级方案通常也意味着更高的硬件设计、RF调试和认证协同要求。
因此:
样机最优方案和最终量产最优方案不一定完全相同。
是否需要在首版就按照量产架构设计,要结合项目目标判断。
OTA经常被认为只是软件功能。
实际上它会影响:
Flash容量;
Bootloader;
固件分区;
通信协议;
服务端;
APP或设备平台;
升级失败恢复策略。
如果硬件已经完成,后面才决定加入OTA,有可能发现主控Flash空间不足。
因此,即使第一版暂时不开放OTA功能,如果产品后续明确需要远程升级,也应该在主控和软件架构阶段提前考虑。
同时还需要确定:
升级由谁触发;
固件如何下载;
如何验证固件;
断电怎么办;
升级失败能否回滚;
多版本设备如何管理。
OTA不是简单“把程序从服务器下载下来”,而是一套需要考虑失败场景的升级机制。
设备一旦需要接入互联网,就会出现一些纯离线电子产品没有的问题。
例如:
这个设备是谁?
它属于哪个用户?
服务器如何确认它是真实设备?
换用户以后怎样解除绑定?
设备离线以后平台怎样判断?
因此,联网设备前期还要考虑:
设备唯一标识;
SN或Device ID;
密钥或证书;
首次配网;
用户绑定;
设备解绑;
心跳;
在线/离线状态;
远程命令;
数据上报;
权限控制。
这些问题会同时影响设备端固件、服务端、APP或Web系统。
如果直到APP开发阶段才考虑设备身份,往往会出现设备端和平台端反复调整协议的问题。
样机不是“开机以后功能能跑”就算完成。
在项目开始之前,就应该大致确定哪些指标需要验证。
例如:
传感器能否正常采集;
按键、LED、屏幕是否正常;
控制输出是否正确。
BLE连接距离;
Wi-Fi连接;
弱网恢复;
数据上传;
断线重连。
休眠电流;
工作电流;
典型工作周期;
实际续航估算。
连续运行;
反复重启;
网络断开;
外设异常;
掉电恢复。
PCB装配;
接口位置;
天线;
散热;
操作便利性。
如果项目有明确测试标准,则还应按照约定标准进行验证。
对于涉及认证、环境或专项可靠性测试的项目,一部分可以在内部研发过程中检查,一部分可能需要与第三方测试或认证机构协同完成。
这是智能硬件研发中很容易被低估的环节。
样机能够正常运行,并不意味着可以马上进入批量生产。
从样机到试产和量产,还可能涉及:
PCB设计优化;
DFM/DFA;
BOM优化;
替代器件评估;
PCBA打样;
结构优化;
工装治具;
生产测试方案;
FAI;
小批试产;
问题整改;
合作工厂对接;
供应链管理;
量产质量管理。
如果产品需要认证,还可能涉及:
根据认证要求调整设计;
整理技术资料;
样机准备;
与第三方机构协调测试;
根据测试结果进行设计整改。
因此,如果项目目标不是“做一台演示样机”,而是后续准备正式销售,那么这些条件应该在研发前期就有所考虑。
北京心玥科技可以根据项目范围参与DFM/DFA、BOM优化、PCBA打样、试产、FAI、治具、供应链及合作工厂对接等工程工作,但这与拥有自有EMS工厂是两个不同概念。
如果项目还处在需求沟通阶段,可以优先整理下面这些内容。
这个设备解决什么问题,主要由谁使用?
首版必须实现哪些功能?
需要连接什么传感器、执行器或外部设备?
BLE、Wi-Fi、4G、RS485、CAN还是其他方式?
是否需要APP、Web、上位机、后台或IoT设备管理平台?
适配器、USB、电池还是其他供电方式?
如果使用电池,希望工作多久?
是否已有ID、MD或外壳尺寸约束?
室内、室外、工业现场还是其他环境?
当前目标是验证技术、制作工程样机,还是后续计划试产和量产?
是否已经有原理图、PCB、结构、程序、协议或者现成样机?
这些信息不一定第一次就全部确定。
但越早明确关键约束,技术方案、报价和周期评估就越接近实际情况。
不是所有需求都必须在第一天冻结。
例如一些界面细节、非核心数据显示方式,可以在开发过程中继续完善。
但下面几类条件最好尽早确定:
核心功能;
主控资源需求;
通信方式;
电源方式;
电池和续航目标;
主要传感器;
PCB尺寸上限;
关键接口位置;
是否需要OTA;
是否需要联网平台;
已经明确的认证或环境要求。
因为这些条件会直接改变硬件架构。
如果PCB已经完成后再改变:
主控、供电、通信、屏幕、无线方式或结构尺寸
通常意味着返工成本明显提高。
北京心玥科技有限公司围绕电子产品研发、嵌入式软硬件开发、智能硬件与IoT、工业电子设备开发以及PCB/PCBA工程实现开展相关研发工作,同时继续承接Web、APP、上位机、后台管理系统、设备管理平台等软件开发业务。
智能硬件项目可以根据当前状态从不同阶段开始。
如果只有产品想法,可以先进行需求分析、技术方案和核心器件选型。
如果已经有ID或MD设计,可以进一步结合结构尺寸进行PCB、电源、天线及接口规划。其中MD机械结构设计可根据项目安排由自有人员参与,ID工业设计则根据实际项目与合作团队协同。
如果已经有硬件,也可以针对现有电路开展嵌入式固件、通信、APP、平台或系统联调。
对于需要进入试产和量产阶段的项目,可以根据实际范围继续开展DFM/DFA、BOM优化、PCBA打样、FAI、治具、试产以及合作供应链对接等工作。
具体开发内容以及原理图、PCB源文件、BOM、固件源码、软件源码、通信协议、测试资料等交付范围,应按照双方项目约定确定,并非所有项目默认采用完全相同的交付清单。
智能硬件需求准备的意义,并不是在项目开始之前把所有细节一次性确定。
真正重要的是:
先把会影响系统架构、硬件设计和研发成本的关键约束明确下来,再把可以逐步优化的内容留到后续迭代。
这样既能减少前期无效设计,也更有利于后续样机验证和产品迭代。
不一定。项目早期可以只有产品目标、核心功能和基本使用场景,但至少应尽量明确通信、电源、尺寸、传感器、软件系统和使用环境等关键条件。研发过程中可以继续完善详细需求。
不一定。如果设备可以独立工作,或者接入已有系统,就不一定需要单独开发APP。如果存在手机配置、设备绑定、数据查看、远程控制等需求,则可能需要APP、Web或其他软件系统。
不建议只从芯片开始。应该先明确通信场景、功耗、实时控制、接口和软件需求,再决定使用无线SoC还是“MCU + 通信模组”等架构。
如果项目明确计划后续量产,建议首版就考虑主要结构、BOM、可制造性、器件供应和测试方式。但样机阶段仍然允许为了快速验证技术采用部分不同于最终量产的方案。
可以,但最好尽早让结构与电子设计协同检查。PCB、电池、天线、接口、按键、屏幕和散热都会受到结构空间影响。如果外观尺寸已经完全冻结而内部空间不足,可能限制后续硬件方案。
根据产品不同,可能还需要设计优化、DFM/DFA、BOM优化、测试方案、认证协同、治具、小批试产、FAI、供应链和生产问题整改等工作。具体范围应根据产品和合作方式确定。