简单物联网终端设备的设计思路总结.pdfVIP

简单物联⽹终端设备的设计思路总结 简单物联⽹终端设备的设计思路总结 个⼈总结，物联⽹终端设备的研发⼀般有以下步骤： 1. 公司领导经过“极为慎重严谨的调研和评估”之后决定⽴项； 2. 产品经理根据领导层决定的产品定位，“参考”竞品，输出“⼗分确定的”需求； 3. 系统⼯程师根据“⼗分确定的”需求，输出“提纲挚领⽽⼜细致⼊微的”系统⽅案； 4. 软硬件开发⼈员根据“⼗分确定的”需求和“提纲挚领⽽⼜细致⼊微的”系统⽅案，输出“稳定性极其棒，可扩展性⼗分强，可维护 性特别好的”软硬件设计⽅案以及版本； 5. 测试⼈员同样根据”⼗分确定的“需求和”提纲挚领⽽⼜细致⼊微的”系统⽅案，输出“⾮常⾃动化，可24⼩时⽆⼈值守⽽且100% 覆盖所有功能的”软硬件测试⽅案并完成测试； 6. ⽣产产线 “⽆需试产的直接⼀次批量成功”； 7. 领导请⼤家在公司楼下⼩餐馆聚餐庆功。 哈哈，当然以上带有夸张，不过⼤体步骤是没问题的。这⾥主要想讨论的就是步骤3和步骤4。以下将以智能⽔表为例进⾏讨论。 ⼀ 从逻辑上分解设备 个⼈认为，⼀般的物联⽹终端设备，都可以分为三个部分：属性，数据，状态。⽽系统⽅案就可以根据这三个部分进⾏完善和输出。 1. 属性 属性指的是这个设备⼀般不会发⽣变动 （多次断电开机都会保持⼀致）的参数。可以分为三类，基础属性，联⽹属性，业务属性。其中业务 属性是跟需求紧密相关的。例如： ⽔表的基础属性包括 ：表号，表类型，软件版本，硬件版本等 ； ⽔表的联⽹属性包括 ：IMEI，IMSI，CCID，APN，远端IP和端⼝等； ⽔表的业务属性包括 ：最⾼流速阈值，最⼤累计流量阈值，最⾼⽔温阈值，最⾼⽔压阈值，最低⽔温阈值，最低⽔压阈值，数据上报周 期，数据采集周期等 ； 2. 数据 数据就是这个设备在⼯作过程中所需要获取的某些数值。可以分为两种，⼀种是从硬件中可以直接获取的数值，称为直接数据；另⼀种是因 为业务需求所需要计算或记录的数值，称为间接数据。例如： ⽔表的直接数据包括 ：累计流量，瞬时流量，⽔温，⽔压等 ； ⽔表的间接数据包括 ：最⼤瞬时流量，最⾼⽔温，最低⽔温，最⾼⽔压，最低⽔压等 ； 3.状态 状态指的是这个设备在⼯作中的运⾏情况。分为物理状态，逻辑状态两种。物理状态⼜可以分为⽹络状态，能源状态，控件状态等 ；逻辑状 态则主要是指业务相关的⼀些状态。例如 ： ⽔表的⽹络状态包括 ：信号强度，信噪⽐，⼩区id，频点，覆盖等级等 ⽔表的能源状态包括 ：电池电压，电量等 ⽔表的控件状态包括 ：阀门开关状态等 ⽔表的逻辑状态包括 ：各种报警标志，定时上报标志，数据采集标志，LCD显⽰标志等 ⼆ 确定与云端的通信协议 这⾥的协议指的是业务协议，这种通信协议原则就⼀个，精炼。具体来说，就是能云端做的事都在云端做，因为本⾝物联⽹终端设备的能源 和各种代码空间都受限，⽽且由于⼀个系统中，设备数量⼀般都很多，对稳定性的要求很⾼，因此协议越简单，通信过程就越可控，功耗也 越少。 我们结合上⾯所说的设备的三个部分，协议也就有了最基本（但不是必须的）的三个内容： 1. 设置设备属性； 2. 上报设备数据； 3. 改变设备状态； 在这三个内容的基础上，也可以根据业务需求，再进⾏扩展，例如⽔表的协议可以是这样的： 设置设备属性：包括，设置联⽹属性帧、设置业务属性帧，基础属性⼀般不会修改（软件版本也是通过fota的⽅式进⾏变更，⽽⾮远程 设置）。 上报设备数据：包括，上报直接数据帧和报警信息帧，间接数据不需要上报，因为可以通过直接数据进⾏处理得到。 改变设备状态：包括，改变控件状态帧及其响应帧，⽹络状态和能源状态⼀般是不能修改的，逻辑状态⼀般不建议修改，属于设备运⾏ 过程的标识。 其中，只有改变控件状态帧⼀定需要应⽤层的响应，因为它在执⾏层⾯涉及改变外界，存在由于控件故障⽽失败的风险，这是不可控风险， ⽽其他的帧，均属于程序逻辑操作，风险是属于软件内部的问题，是可控风险。 关于是否需要响应帧，如果它是⽤来规避通信失败的，应当根据系统所使⽤的具体传输协议来决定，如果使⽤的本⾝就是类似于TCP这种有 保障机制的协议，那就不需要在业务协议中再额外规定响应帧。现在⽐较成熟的物联⽹协议，例如coap，mqtt等⼀般都包含⽤于确认某条 数据重要程度的机制。 简⽽⾔之，⽤于确保通信稳定的响应帧，应该交给底层 （⾮应⽤层）协议去做，应⽤层中的响应帧，是⽤于确认某种存在不可控风险的