简单物联⽹终端设备的设计思路总结
个⼈总结，物联⽹终端设备的研发⼀般有以下步骤：
1. 公司领导经过“极为慎重严谨的调研和评估”之后决定⽴项；
2. 产品经理根据领导层决定的产品定位，“参考”竞品，输出“⼗分确定的”需求；
3. 系统⼯程师根据“⼗分确定的”需求，输出“提纲挚领⽽⼜细致⼊微的”系统⽅案；
4. 软硬件开发⼈员根据“⼗分确定的”需求和“提纲挚领⽽⼜细致⼊微的”系统⽅案，输出“稳定性极其棒，可扩展性⼗分强，可维护
性特别好的”软硬件设计⽅案以及版本；
5. 测试⼈员同样根据”⼗分确定的“需求和”提纲挚领⽽⼜细致⼊微的”系统⽅案，输出“⾮常⾃动化，可24⼩时⽆⼈值守⽽且100%
覆盖所有功能的”软硬件测试⽅案并完成测试；
6. ⽣产产线“⽆需试产的直接⼀次批量成功”；
7. 领导请⼤家在公司楼下⼩餐馆聚餐庆功。
哈哈，当然以上带有夸张，不过⼤体步骤是没问题的。这⾥主要想讨论的就是步骤3和步骤4。以下将以智能⽔表为例进⾏讨论。
⼀从逻辑上分解设备
个⼈认为，⼀般的物联⽹终端设备，都可以分为三个部分：属性，数据，状态。⽽系统⽅案就可以根据这三个部分进⾏完善和输出。 1. 属性
属性指的是这个设备⼀般不会发⽣变动（多次断电开机都会保持⼀致）的参数。可以分为三类，基础属性，联⽹属性，业务属性。其中业务属性是跟需求紧密相关的。例如：
⽔表的基础属性包括：表号，表类型，软件版本，硬件版本等；
⽔表的联⽹属性包括：IMEI，IMSI，CCID，APN，远端IP和端⼝等；
⽔表的业务属性包括：最⾼流速阈值，最⼤累计流量阈值，最⾼⽔温阈值，最⾼⽔压阈值，最低⽔温阈值，最低⽔压阈值，数据上报周期，数据采集周期等；
2. 数据
数据就是这个设备在⼯作过程中所需要获取的某些数值。可以分为两种，⼀种是从硬件中可以直接获取的数值，称为直接数据；另⼀种是因为业务需求所需要计算或记录的数值，称为间接数据。例如： ⽔表的直接数据包括：累计流量，瞬时流量，⽔温，⽔压等；
⽔表的间接数据包括：最⼤瞬时流量，最⾼⽔温，最低⽔温，最⾼⽔压，最低⽔压等；
3.状态
状态指的是这个设备在⼯作中的运⾏情况。分为物理状态，逻辑状态两种。物理状态⼜可以分为⽹络状态，能源状态，控件状态等；逻辑状态则主要是指业务相关的⼀些状态。例如：
⽔表的⽹络状态包括：信号强度，信噪⽐，⼩区id，频点，覆盖等级等
⽔表的能源状态包括：电池电压，电量等
⽔表的控件状态包括：阀门开关状态等
⽔表的逻辑状态包括：各种报警标志，定时上报标志，数据采集标志，LCD显⽰标志等
西安性文化节>LIBOR⼆确定与云端的通信协议
这⾥的协议指的是业务协议，这种通信协议原则就⼀个，精炼。具体来说，就是能云端做的事都在云端做，因为本⾝物联⽹终端设备的能源和各种代码空间都受限，⽽且由于⼀个系统中，设备数量⼀般都很多，对稳定性的要求很⾼，因此协议越简单，通信过程就越可控，功耗也越少。
我们结合上⾯所说的设备的三个部分，协议也就有了最基本（但不是必须的）的三个内容：
1. 设置设备属性；
2. 上报设备数据；
3. 改变设备状态；
在这三个内容的基础上，也可以根据业务需求，再进⾏扩展，例如⽔表的协议可以是这样的：
设置设备属性：包括，设置联⽹属性帧、设置业务属性帧，基础属性⼀般不会修改（软件版本也是通
过fota的⽅式进⾏变更，⽽⾮远程设置）。
上报设备数据：包括，上报直接数据帧和报警信息帧，间接数据不需要上报，因为可以通过直接数据进⾏处理得到。
改变设备状态：包括，改变控件状态帧及其响应帧，⽹络状态和能源状态⼀般是不能修改的，逻辑状态⼀般不建议修改，属于设备运⾏过程的标识。
其中，只有改变控件状态帧⼀定需要应⽤层的响应，因为它在执⾏层⾯涉及改变外界，存在由于控件故障⽽失败的风险，这是不可控风险，⽽其他的帧，均属于程序逻辑操作，风险是属于软件内部的问题，是可控风险。
关于是否需要响应帧，如果它是⽤来规避通信失败的，应当根据系统所使⽤的具体传输协议来决定，如果使⽤的本⾝就是类似于TCP这种有保障机制的协议，那就不需要在业务协议中再额外规定响应帧。现在⽐较成熟的物联⽹协议，例如coap，mqtt等⼀般都包含⽤于确认某条数据重要程度的机制。
简⽽⾔之，⽤于确保通信稳定的响应帧，应该交给底层（⾮应⽤层）协议去做，应⽤层中的响应帧，是⽤于确认某种存在不可控风险的操作的执⾏结果的。
另外，关于应⽤层协议中的帧头帧尾帧长等帧结构相关的部分，应当根据具体情况确认是否需要，只
有确定payload中不会有跟帧头帧尾相同的数值时（或者使⽤转义的⽅法从payload中排除与帧头帧尾相同的数据），那帧头帧尾才可以对帧的数据处理起到⽐较⼤的作⽤，否则作⽤很⼩甚⾄是反作⽤。
⽽帧长，则是在不适合使⽤帧头帧尾的情况下的最好办法，⼀个帧，在不考虑传输错误的情况下，完全可以以帧长开头，后⾯跟数据然后结束。⽽说到传输错误，⼀般的物联⽹协议都没有纠错机制（当然有可能是我了解的不够深），因此我们就需要有校验机制，这⾥我们⼀般采⽤CRC校验，简单的可以采⽤累加和或者异或校验。
所以，个⼈认为物联⽹应⽤层最精简的帧结构，完全可以是：
|帧长|数据|CRC|
或
|帧头|(数据|CRC)(转义)|帧尾
业务协议到这⾥基本上就结束了，但是⼀般物联⽹设备都有⼀个最终兜底的措施——FOTA，所以⼀般协议⾥也会涉及FOTA相关的内容，这⾥简单说⼀下。
由于它是软件层⾯的兜底措施，因此不容失败，所以个⼈认为应当采⽤成熟的⽂件传输协议，HTTP,F
TP等。⽽触发⽅式⼀般就是在业务协议中，额外多⼀个帧⽤于触发FOTA，之后⼀般都通过另⼀个FOTA协议完成⽂件下载，这个过程⼀般是这样的：
1. 对旧版本号与新版本号进⾏⽐对与确认；
2. 然后进⾏⽂件下载；
3. 下载完成后进⾏⽂件完整性确认；
4. 然后进⾏flash烧录；
5. 然后运⾏新程序；
6. 还要再对⽐该程序的版本号是不是⽬标版本号，不⼀致还要再回退到之前的版本；
7. 然后再使⽤业务层协议上报升级结果。
所以这个帧也是跟改变控件状态帧⼀样，需要有响应帧，因为FOTA这个⾏为太重要了，⼀点风险也不能承受，同时⼀般FOTA过程是不考虑功耗的（都需要FOTA了，事情已经很严重了）。
三确定系统框架
1.硬件框架
PS：笔者主要是做软件的，硬件⼯作只在⼤学期间和刚⼯作的⼀年内做过，因此只能做简单描述。
个⼈认为，硬件框架最重要的是关键器件选型，什么是关键器件⼀般是根据产品需求来确定，⽽选型时的功能和性能标准⼜是根据产品定位来确定。还是以智能⽔表为例，智能⽔表的产品需求中必要的有三点：
1. 能获取⽔流相关的物理信息，流速，⽔温，⽔压等等；这意味着传感器是关键器件；
2. 能将这些数据上报；这意味着微控制器（MCU）和⽆线通信模块也是关键器件；
3. 易安装，易维护；这意味着低功耗长续航，也就是说电源模块也是关键器件，⼀般是电池和电源芯⽚。
产品定位可能有两种，⼯业⽔表和民⽤⽔表。
⼯业⽔表，对⽔表本⾝的稳定性要求更⾼，对于⽔流信息的精度，时效性要求更⾼，⼯作环境也更加恶劣，续航时间也要求更⾼，但是对成本相对不敏感。因此需要选择精度更⾼的传感器，抗⼲扰能⼒更强，速度更快的微控制器和⽆线通信模块，容量更⼤的电池和更稳定的电源芯⽚。民⽤⽔表则相反。选型时需要更多向成本倾斜。
除此之外，选型还有⼀个原则就是尽量考虑使⽤同样的器件和可替代性强的器件，以此来确保供应链的稳定性。
这其中的取舍把握，就是对需求的理解和硬件经验的体现。
另外⼀般来说，第⼀版的选型都会稍微偏向性能，也更加考虑兼容性⼀些，更加便于开发，⽽后根据第⼀版产品的市场反馈以及实际开发结果，再将额外冗余的部分去掉来降成本。
个⼈认为，选型完成之后，对于⽔表这种⽐较简单的物联⽹终端来说，硬件设计就没有太⼤的难点了，但还需要注意⼀下射频的设计，低功耗的设计，PCB的布局结构与外壳的匹配等细节问题，避免⽆谓的功耗和信号损失。
2.软件框架
PS：由于嵌⼊式编程主要是使⽤C，因此以下的讨论也主要⽤C来说明。
软件框架的设计总体来说是根据需求和协议来的，但也需要考虑硬件的选型——主要是MCU的选型。⽐如MCU是否允许跑RTOS甚⾄linux，还有休眠时MCU外设的状态以及如何唤醒等等。⼀般情况下，个⼈建议，只要MCU允许，能上操作系统就上，它可以帮助你更好的控制软件的逻辑和时序（在使⽤熟练的情况下），⽽且主流RTOS都⽀持了很多组件，可以⽅便各种功能的实现（⾮常推荐RT-Thread）王磊晓芬小说免费阅读
。另外，主流的MCU都有成熟的HAL库，这样我们主要就是基于硬件驱动层和RTOS之上，考虑应⽤层软件的框架。
个⼈习惯在设计应⽤层软件框架时，从数据结构⼊⼿，先根据需求建⽴合适的数据结构及其处理接⼝，然后再根据需求和数据结构设计程序流程。
那⾸先来看数据结构，结合我们在上⾯分解的三部分，数据结构就很明显可以分为三种了，属性，数据，状态。接下来我们根据上⾯对设备的逻辑分解，逐⼀分析这三个数据结构：
1. 属性，属性是云端主动配置或者缺省默认的，是要能掉电保存的，设备的联⽹参数，数据采集间隔，上报间隔，报警阈值等信息都来
源于它。所以它需要可以进⾏读取，修改，保存操作。同时，它的各个成员参数在真正的业务流程启动之前就应该是有效的。
2. 数据，数据是从传感器采集到的，不需要掉电保存，它需要被上报，因此它要能被读取和修改。
3. 状态，状态是设备在运⾏过程中产⽣的⼀些逻辑参数，表明它的⽹络状况，运⾏情况等等，也不需要掉电保存，它同样也是需要能被
读取和修改。
根据以上的分析可知，应⽤层软件⼤致可以分为四个模块：
1. ⾸先要有⼀个采集数据的模块A，它负责在需要的时候从传感器中获取信息，并填充到数据中，同时要读取属性中的各种报警阈值，进
⾏报警判断，然后再将报警状态更新到状态中；
2. 然后，需要有⼀个与云端通信的模块B，它负责在需要的时候将数据中的数据取出并发送⾄云端，并接收云端下发的命令等，同时也要
更新状态。
3. 由于⽔表可能还需要控制阀门，检测按键等，因此还需要有⼀个模块C处理这些⼯作。它也需要更新状态。
4. 上⾯三个模块都是要在需要的时候才⼯作，因此就需要有个告诉它们什么时候该⼯作的总服务模块Z。
也就是说这四个模块的关系应该如下：
Z给ABC下发命令并接收结果
这样的模式下，业务逻辑被抽离出来放在了Z中，真正⼲活的是ABC，代码的可维护性和可扩展性就会很好，有新的需求或者⼯作流程需要修改时，只需要修改Z即可。但是⼀定要确保Z除了处理业务逻辑和分发指令之外，不会做其他实际的⼯作，否则Z和ABC的耦合性就会越来越强。
那么到⽬前为⽌，我们的应⽤层程序⾥共有七个部分，三个数据结构，四个逻辑模块，接下来我们依次分析⼀下它们应该怎么实现。
四详细设计
PS：这⾥只对软件的详细设计进⾏讨论
1.数据结构
三个数据结构由于都需要被多个模块访问，因此，它们可以实现为全局变量，那么同样由于它们会被多个模块访问，因此需要被加以控制，防⽌同时被不同模块访问造成混乱。控制⽅式可以采⽤互斥锁，也就是在这三个数据结构中，除了它们本⾝的成员，再加上⼀个互斥锁成员。如此⼀来，可以专门为它们编写相应的操作函数，其中由于属性需要掉电保存，因此它还需要⼀个存储函数，且它的读取函数也会不同。
三个数据结构的操作函数伪代码如下：
属性
static attr_t s_attr ={0};
uint8 init_attr(void)
{
if(NULL== s_attr.attr_mutex)
{
mutex_t temp_mutex =NULL;
s_attr.attr_mutex =osMutexNew(NULL); osMutexAcquire(s_attr.attr_mutex, osWaitForever); temp_mutex = s_attr.attr_mutex;gps监控
美国次贷危机的原因
尝试从flash中读取属性到s_attr;
if(尝试从flash中读取属性失败）
{
给s_attr赋默认值;
}
s_attr.attr_mutex = temp_mutex; osMutexRelease(s_attr.attr_mutex);
return0;
}
else
return-1;
}
uint8 read_attr(attr_t* attr)
{
if((NULL!= attr)&&(NULL!= s_attr.attr_mutex))
{
osMutexAcquire(s_attr.attr_mutex, osWaitForever); memcpy(attr,&s_attr,sizeof(attr_t));
attr.attr_mutex =NULL;
osMutexRelease(s_attr.attr_mutex);
return0;
}
else
面子理论
return-1;
}
uint8 write_attr(attr_t* attr)
{
if((NULL!= attr)&&(NULL!= s_attr.attr_mutex))
{
osMutexAcquire(s_attr.attr_mutex, osWaitForever); attr->attr_mutex = s_attr.attr_mutex;
memcpy(&s_attr, attr,sizeof(attr_t)); osMutexRelease(s_attr.attr_mutex);
}
else
return-1;
}
uint8 store_attr(void)
{
uint8 ret =0;
if(NULL!= s_attr.attr_mutex)
{
osMutexAcquire(s_attr.attr_mutex, osWaitForever); ret =尝试将attr存储⾄flash中; osMutexRelease(s_attr.attr_mutex);
return ret;
}
else
return-1;
}
状态
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议