NB-IoT应用场景_iot框架

大家好，又见面了，我是你们的朋友全栈君。

NB-IOT实现万物互联 产品设计思路分享

NB-IOT窄带物联网（Narrow Band Internet of Things, NB-IoT）,是一种专为万物互联打造的蜂窝网络连接技术。NB-IOT作为近年大火的一项物联网技术，因为其特性受到了众多行业众多企业的青睐。其广覆盖，大连接，低功耗，低成本的四大主要特点符合众多行业的实现物联网平滑过度的要求，成为了物联网技术又一代宠儿。本人也是因从业相关行业，开发NB-IOT产品有相关经验，才有思路想写这篇文章，希望能给有需求的开发者提供一些思路上的帮助。本文将从设备硬件，设备软件，平台软件进行一个初步的分析介绍，将作者在设计开发过程种的一些雷区分享给大家，并给大家描述出开发NB设备的一个大致流程，希望能够为大家带来些帮助。本文适用于想了解NB-IOT通讯或者处于开发初期的开发者。

产品结构思路

设备：单片机+NB模组+传感器。 其中单片机作为主控，现也有opencpu的模组可以实现不带单片机。NB模组作为通讯工具，负责上传数据。传感器是产品实现主要功能的部件，负责获取数据，比如水表依靠传感器来读数，智能灯智能锁等。
云平台：电信云（OC），移动ONENET平台，联通telit平台，私有云等。这些平台主要负责设备管理以及数据中转，用的比较多的是三大运营商的平台。这些平台将设备上报数据推送到企业数据管理平台并将企业平台命令下发至设备，完成设备与企业平台交互，这是常用的设计方式。使用过程中也可以使用NB模组通过UDP，TCP服务直接将数据上传至企业服务器。
企业服务器：企业正式使用平台，将数据解析处理，数据命令下发的管理平台。
总结：产品传感器获取功能数据，NB模组负责通讯，运营商的平台主要负责设备管理以及数据中转，企业物联网平台查看设备数据，并控制设备。

作者在实际开发过程中使用过移远BC95,BC28,BC25，有方N21，中移M5310-A，中移M5311等NB模组，不同模组各有优有劣，实际使用过程中，用户可以根据自己的需求来选型。作者目前使用过的模组虽然各有差异，但在NB通讯这块都是正常的，下面作者将选取BC28作为样例来进行一个简要设计分析。

硬件设计

设计真正开始便是在硬件设计。开发者对模组接口的深刻理解，对各项硬件注意事项熟练掌握，都将直接关乎到软件调试，产品开发周期以及产品兼容等方面。所以在开发前都需要开发者仔细阅读硬件手册。这里作者将分享一些硬件手册上没有的注意点，希望看官注意到设计时可以多方面思考。

模组电源设计

模组电源设计的主要需求是保持模组有稳定的供电电压，并且需要一定的电流驱动能力。主要需要考虑两方面设计情况 1.能抗住瞬间大电流，防止拉死主控设备。2.需要提供稳定的电压，防止在上报的时候电压被拉至NB模组极限电压之下。在设计之前，需要了解NB模组对电流的需求能力。下图是本人把一次上电上报过程中的电流大小给抓了出来。从下图可以看出，max电流值达到1.4a，上报时间约为20s，平均电流20ma。

从上图相信有经验的工程师一眼就可以看到有设计的关键点。其关键所在便是NB模组上电瞬间有达到1A电流，电源设计必须加隔离设计。作者使用过的模组开机的瞬间电流均达到了A级别，也曾询问过模组厂的FAE，确实模组开机过程的电流偏大。针对这个现象设计的时候就必须将电源做处理，不然很容易出现开机拉死主控等各种各样的现象。并且因为NB产品多用电池供电，而NB模组极限电压多为3.1V(作者使用过的均是)，建议在模组Vbat端口附近处加钽电容，防止电压跌落至最低电压，导致引起模组重启复位。至于如何加隔离设计，各位看官变各凭本事了。

模组接口

至于模组接口连接，各位都可参考模组的硬件设计手册，这里仔细看，不会有像上电大电流一样的雷区。
但根据实际经验还是有些建议可以提一下。1.模组可以预先做好同系列模组的兼容性设计，比如BC28,BC25等系列就可先做好兼容性设计，后期换模组就可以直接贴，无需重新画板。2.sim卡电路可以做好贴片卡和插卡的兼容性设计。3.DEBUG串口有空间还是需要引出调试口出来，因为后期调试时如果遇到问题，找模组厂FAE，FAE的第一句话就是抓个log看看（真实经验哈哈哈）抓log就需要这个debug口，而且给模组固件升级也是需要这个，之前踩过模组版本过低的大雷。4.RF_ANT射频接口打板一定要加50欧姆匹配阻抗，不然没加匹配阻抗的板子去配天线基本是无效的，千万不要等着正式生产才加匹配阻抗。5.单片机和模组通讯，在测试极限情况下，比如高低温，有时候会出现通讯失败的情况。有的模组厂会要求单片机加外部晶振或者把模组的串口接收容错加大（当然这是不建议的）。还有则是在没有网络的大功率寻网时，引发的模组重启，或者单片机复位的情况。模组重启需要查看射频天线是否接地以及供电是否稳定，单片机复位则需要查看复位原因，作者遇到过单片机常规RC复位电路扛不住NB在无网络大功率高频干扰导致复位的情况。6.其他开机键的设计，reset，wake-up，串口电平转换的设计的都可参考设计手册，串口电平转换的电压需要采用模组输出电压。

低功耗设计

低功耗设计目前主要有两种设计思路。方式1.单片机控制模组进入PSM状态，同时单片机自己也休眠。方式2.单片机控制NB模组供电，直接关断NB模组供电，同时单片机进入休眠。这里阐述的是的单片机控制NB模组，不包括NB模组内嵌单片机方式。
方式1：单片机和NB模组同时进入休眠，作者使用的单片机深度休眠功耗为1ua，NB模组休眠PSM状态为3ua-5ua。这种状态下整机功耗大概会在5ua左右。在PSM模式发送数据加上采集传感器数据，假设用时15s（PSM状态下比重新上电可少去扫频，小区同步等初始化流程，对于一天上报一次的话可忽略），持续电流为30ma。除去电池钝化，进而可以计算出大概的电池使用寿命。下图为作者抓的PSM状态下，产品整机的功耗图，可以看出其平均电流约为5ua左右。

方式2：单片机直接设计控制电路，控制NB模组的供电，这种方式相信看官会比较熟悉，以前的产品不考虑功耗经常性的会设计控制电压输出电路。作者最终选择也是选择了这种电路。此种方式，作者使用的是核心元器件为AO3415，具体功能大家可以自行百度，或者使用自己熟悉的控制电路。

此种电路整机功耗只有单片机的休眠模式的功耗，作者使用的单片机休眠电流为1ua左右。在此种模式下，整机功耗长时间为1ua，发送数据的时候需要程序重新初始化，重新入网，上报数据的时间会比PSM模式下的更长。在网络一般的情况下约为20s-30s，持续电流也是30ma左右，除去电池钝化，可以计算出电池的使用寿命（其实作者之前算过，现在不太想重新算一遍2333，大致就是方式2会使用寿命更长一点点）。当然这些都是在网络状况好或者一般的情况下，在网络状况差的情况下，数据上报时间会更长，数据上报电流会更大。

usim卡APN设置

低功耗设计若用采用模组PSM来实现的话，采购的SIM 卡一定需要提前配置好相应场景的APN，这是给新接触NB的开发人员的一个大坑，下意识的认为模组低功耗和sim卡无关。实际上不同的应用场景，卡会有不同的APN设置，这些设置主要完成PSM设置以及eDRX的时长配置，并由卡商出厂前配置好，所以如果在调试过程中发现怎么也进不了PSM，可以往这方面思考。大致的APN设置可以参考下图，不同运营商可能有不同的配置，主要要注意有这一回事。

sim卡除了APN设置不同，其计费方式也是不同的资费也是不同，我接触过有50M每年的，也有2w次连接每年的，这类需要用户按照自己的需求来评估。另，需要注意的是电信NB卡屏蔽了TCP,UDP服务！！！！

程序设计

至于单片机程序设计主要功能是把设备的信息上报到对应的平台上去。逻辑功能还是相对来说较为简单的。
此块最重要的功能是保证数据上传成功，以作者目前的项目经验来看，NB-IOT产品目前面临的最大的困难的就是数据上报失败，导致设备失联。那么在程序设计这块，如何保证数据上传成功，就需要认真思考，在符合产品要求的情况下，最大可能保证数据上传成功。

代码设计

NB-IOT主函数设计是非常简单，其主体可以分为四部分1.初始化2.采集信息3.上报数据4.进入休眠。具体还是得参考NB上行协议。这里作者只是简单得描述。

<code style="margin-left:0">int32_t main(void)
{ 
   
GPIO_INIT();
ADC_INIT();          //初始化所需
...
...
while(1)
{ 
   
UART_RxHandle();       //串口接收
if(CJ_FLAG)            //采集传感器信息
{ 
   
}
if(SB_FLAG)           //上报数据
{ 
   
}
if（SLEEP_FLAG）      //进入休眠
{ 
   
}
}
}</code>

主函数设计作者只是给了个粗略的模型，具体的需要根据协议以及功能来进行具体编写，在此不加赘述，相信大家都有自己的理解。
1.初始化，依据不同单片机，所需要不同的功能进行初始化。
2.采集信息，这一部分依据不同的产品来进行采集信息，比如水表，气表需要采集读数，烟感光感需要采集响应的烟浓度，光强等信息，这是不同产品的基石。这一部分相信大部分厂家都有自己的技术积累，不是难点。
3上报数据，这一块可以说是NB-IOT的单片机程序重点了。上报数据的流程该如何设计，怎么设计重传机制，怎么设计异常处理机制。这些问题都需要认真思考并考虑产品特性来进行设计。
首先按照我们所设计的产品类型，产品大致可以分为4类应用场景：固定上报型产品，移动上报型产品，固定控制类产品，移动控制类产品。四种产品类型大致可以涵盖NB所涉及到的应用场景。依据不同类型可以设置所需要设计的不同模式。比如上报类产品对实时性要求不高的情况下，可以将eDRX功能关闭，将PSM模式打开，或者直接进行断电处理。对控制类产品，所需的实时性较高的，需要一直保持在线状态下，可以选择可持续性电源，可以关闭eDRX功能，关闭PSM模式，这类有点类似2g，4g通讯。此例将用固定上报类的应用场景进行数据上报流程分析，希望能够给大家带来帮助。
下图是模组厂手册上提供的使用流程

从此图可以看出，模组厂提供的流程是比较全面的，我们自己在设计流程的时候也是基于模组提供的流程来进行设计符合自己产品的上报流程。分析上图，我们可以很容易分析出模组的一个数据上报过程。其基本流程是，先设置模组基本配置，再查询入网情况，入网成功，则上报数据，入网失败进行异常处理，完成之后进入PSM或者关机。
再分析模组流程之后，设计者就需要实现符合自己的上报数据流程，需要考虑好入网时间控制，重传次数控制，异常处理控制，从而设计出符合自己产品的程序流程。下图是作者目前使用的上报数据流程,使用的是固定上报类，开关电式上报，模组BC28,连接电信物联网平台。

以上是作者项目所使用的上报数据流程，严格控制上报时间，严格控制在无网络的情况下的搜网时间，目前在出货产品中运行良好。以上流程最重要的有有两点：1.获取cell id号，小区号，实测在产品移动的情况下cell id小区号是发生变化的，目前以此作为一个产品是否发生移动的一个标志，若产品发生移动，由于先验频点的关系会导致入网时间加长，得到此标志后控制搜网时间加长，进而保证能够入网。2.清除先验频点，模组搜网机制是第一次入网之后会将入网的频点记录下来，下次搜网时会先搜索记录的频点，这就是先验频点。由机制可以知道，在产品发生移动的情况下，先验频点不仅不会成为入网的捷径，反而会成为入网的阻碍。在入网时间不够的情况下，或者没有清除频点的情况下，会直接导致模组入网失败。作者血泪经验，望各位慎重处理。
以下是大致的代码流程，大家可参考设计思路

<code style="margin-left:0"> unsigned char NB_IOT（void）
{ 

unsigned char res；
NB_BAT_EN();          //NB上电
READ_CELLID();       //读取存储的上次的cell id
res=NB_SendAtCommand（AT_AT,10,1）；  //发送AT
if（res!=0） return res；            //不通讯直接返回不执行上报，并带标志，可在硬件上识别何种原因不上报
res=NB_SendAtCommand（AT_NCCID,10,1）；
if（res!=0） return res；           //读取不到sim卡 
NB_SendAtCommand（AT_NCDP,10,1）；  //设置指向IP端口
NB_SendAtCommand（AT_CGATT,10,1）； //设置主动入网
while（NB_READ<NBruntime）         //控制入网时间
{ 

NB_SendAtCommand（AT_NUESTATS,10,1）； //查询网络信息，得到相应值以及cell id是否改变标志位
if（cell_id!=0) NBruntime=0xxx;       //产品发生移动，修改入网时间
NB_SendAtCommand（AT_CGATT?,10,1）； //查询是否入网
if（NB.CGATTOK||NBread） break;     //入网成功跳出循环
}
if（!NB.CGATTOK&&!NBread）         //检测入网是否失败
{ 
                                           //入网失败 执行异常处理 
NB_SendAtCommand（AT_CFUN_0,10,1）；        //关闭射频
NB_SendAtCommand（AT_NCSEARFCN_0,10,1）；   //清除频点
NB_SendAtCommand（AT_NRB,1,1）；            //模组重启
NB_SendAtCommand（AT_CFUN_1,10,1）；        //打开射频
res=0xff；
return res;                               //返回特定值，再进行重传一次
}
else                                       //入网成功，执行上报 
{ 

if（!IMEI_GET)      
NB_SendAtCommand（AT_CGSN,10,1）；        //查询IMEI
NB_SendAtCommand（AT_CSQ,10,1）；        //查询CSQ
NB_SendAtCommand（AT_CCLK,10,1）；       //查询基站时钟，校时
while(NB_READ<NBruntime&&!NBread)        //NBread 等待平台下发标志 是平台下发到模组的标志，
{ 
                                        // 入网和平台下发标志是上报成功的两个必要条件
}
res=NB_SendPacket(DATA);                  //发送数据
if（res!=0） return res；                 //发送数据失败
NB_RxHandle();                           //执行平台下发命令 
}
}</code>

NB-IOT远程升级

这是说的是通过NB模组实现单片机的远程升级，不是通过云平台DFOTA实现NB模组的固件升级。这里主要涉及到的是单片机IAP远程升级。这里的远程升级是需要有协议支持，协议可以下发远程升级的IP端口，在通过单片机来进行对NB模组的连接至相应的服务器。其原理大致可以如下：
1.模组上报数据到云平台，接收远程升级的指令
2.单片机复位，跳转到boot程序，通过TCP，或者其他连接方式连接至升级服务器接收升级文件
3.接收完成，iap跳转至新的程序处执行
这里所涉及到的是通过NB模组与升级服务器建立连接的过程，其他的均为单片机IAP知识，这里不多做阐述，主要描述一下NB模组的TCP，UDP连接功能。
目前使用的NB模组都是支持TCP，UDP服务的，用户可以根据需求使用相关功能。但值得的注意的是电信NB卡屏蔽了TCP，UDP服务，需要定向开通才能使用，（作者曾经用电信卡调试过UDP，真是一把辛酸泪）。作者目前使用TCP连接升级服务器接收升级文件，会出现连接不稳定的情况，没有4g，2g连接稳定，这方面作者自己也在摸索，以及连接TCP接收升级文件对其流量的影响都需要待考量，待进一步实测，虽然出货都带有这项功能，但还没有现场使用过该功能，所以其影响还需要实际经验来进行支撑。需要注意的是如果是模组使用TCP,UDP这类上报方式直接上报至客户服务器的话，异常处理也需要做类似处理，否则入网可能存在同样的上报数据失败的情况。

上行协议设计

对于刚开发NB的企业来说，一份好的NB通讯协议，将会省去非常多的麻烦。作者也是从NB协议由无到有慢慢做过来的，面对不同的客户，不成熟的NB协议逐渐暴露出了各种各样的问题。因此在此也提供一些上行协议订制的经验分享给大家。注：产品为固定上报类。
1.上报内容预留字节 这个不必多说，任何新协议订制都可以留出该位置，留白，应对后期修改，在对sim卡流量影响不大的情况，个人建议留10字节（如果经验比较足，就没必要留这么多）。
2.上报内容携带模组IMEI,sim卡信息CCID,IMSI。这些是模组”设备身份证”，客户经常要求将其贴在产品上，作者做过一个客户的协议，上报内容这些信息都不带，然后要求出货产品上要贴这个东西。真的增加厂家工作量。而CCID，IMSI虽然都是卡的唯一标识，但还是建议都读取出来上报上去，接触的客户多了，奇怪的要求会变多，有备无患，作者之前的协议只有CCID，有客户就一定要IMSI，怎么讲都没用。
3.设备网络信号信息，这类也是必须的，可以实时监控设备所处的网络环境。比如SNR,RSRP,CSQ，PCI等等。用户可以通过模组指令来获取，对设备环境判断的意义重大。目前有NB信号测试仪类的产品，其实质便是通过NB模组来获取所处位置的网络状态，之后显示至观看界面，来达到监控信号的功能。
4.网络基站信息，这类信息也是可以通过模组读取出来，比如CELL ID,可以将其上报上来，以此信息来做基站定位，目前已经有云平台支持基站定位，对位置要求精度不高的应用场景可以使用基站来做定位，精度大概在1km左右。作者目前也还未开始做这个，但是这个确实也是个产品亮点，有需求的可以仔细研究下。

5.历史数据，这个作者认为也是必须的，上报传感器数据，作为大部分NB类产品的目的，每日自动上报或者其他方式上报数据到平台。但是这其中始终绕不开的一个问题就是数据上报不上来，导致设备失联，这里有可能是网络问题，有可能是模组问题等等。那么如果产生了漏报数据，为了防止扯皮，当然也为了更好的监控数据，历史数据是很重要的一点。因为许多客户是对上报成功率是有要求，也需要统计日结曲线这类东西，所以我们得想尽办法把每天的数据都能在平台上可以查阅到。当然这也可应对客户发问，这两天数据没报上来，我在哪能看到。真实经验，可参考！！！

蓝牙功能

目前作者接触的NB模组，除了常规的NB功能之外，经常会内嵌一些模块增加模组可卖点，其中见的较多的是内嵌蓝牙模块，也有内嵌GPRS定位的。当然现在很多单片机也都有蓝牙，蓝牙模块也不贵，这里只讨论在NB模组内的蓝牙。在此介绍一下模组内嵌蓝牙模块的。用户可以根据需求来进行选择。NB和蓝牙是两个不相关的两个通道，而且蓝牙不受网络环境，sim卡资费的限制，所以在某些场景蓝牙功能确实是有很大作用的。
1.可以作为应急方案，在没有网络的情况下，有可以控制设备的通道。这是比较稳妥的应急方案，也可增加产品亮点。
2.作为设置设备参数的通道，有的企业会接不同协议的订单，此时因为客户的协议是不一样的，有时是完不成对产品的出厂设置的。这时保留蓝牙作为出厂设置的通道是可以独立于NB协议之外的，这样可以方便完成对接。
3.开发APP，蓝牙使用需要APP配合的，作者接触过两款，厂家都提供APP源码，二次开发的难度不高。
4.功耗功耗实测得看是否是BLE蓝牙，如果不是BLE蓝牙待机功耗会偏大，建议用得时候才开启这样功耗会小点。当然如果给NB模组断电处理的，这方面是不需要考虑的。
5.单片机程序设计，单片机程序设计非常简单，直接通过指令打开蓝牙即可。

云平台对接

目前NB数据上传主要通过走运营商的设备管理平台再将数据推送至企业管理平台，或者通过tcp，udp直接将数据上传至企业服务器。目前作者使用较多的是电信物联网平台，移动ONENET平台，UDP来进行数据传输。联通目前的平台还没对接，目前联通NB基站覆盖率确实还是比不上电信移动，而且有的NB模组也还未出对接联调平台的固件。所以还是推荐电信移动，用的省心。UDP,TCP这类是直接数据上传至用户服务器的，不涉及到云平台对接。
下面将用对接电信物联网平台作为例子来进行阐述一下平台对接流程。

电信物联网平台对接

电信物联网平台分为测试平台，正式平台。用户需要先在测试平台调试，完成认证，才能使用正式环境。
电信测试平台
电信正式平台
电信物联网平台的对接电信给了相应的步骤，新手可以按照其步骤进行对接。其数据传输的原理可从下图数据流看出，平台主要完成数据接收以及转换的工作。而我们开发也是围绕着这两方面来进行，从功能可以看出电信物联网平台主要起到了一个中转站的作用。

了解了其原理，便可按照电信平台给出的开发流程进行开发，自定义厂商自己的profile以及编解码插件。

其中开发的最为重要的便是profile定义，以及编解码插件的开发。
profile文件主要包括了设备信息以及上下行数据,设备信息是解释了设备是何款设备，其基础属性等信息，包含了manufacturerId（厂商ID）、manufacturerName（厂商名字）、deviceType（设备类型）、model（设备型号）、protocolType（协议类型）等等。上下行数据由厂商定义的通讯协议规定。

profile定义了设备信息，设备信息按照要求填写即可。其属性列表对应着设备主动上报消息，命令列表对应着命令下发下发格式，另还有响应字段对应着命令回复等。可以按照NB设备上行协议进行一步一步的设定。
本文不细究配置属性列表，命令列表的方法。
在完成profile定义之后就可进行编解码插件的开发。NB-IoT设备和中国电信物联网开放平台之间采用CoAP协议通讯，CoAP 由 UDP 作为承载，遵循 UDP 基本的协议报文格式，那么CoAP的消息也就是应用层的消息，其数据格式由我们厂商根据自己需求定义。NB-IoT设备的应用层数据一般为二进制数据，数据上传至中国电信物联网开放平台做协议解析时，会转换成统一的Json格式。要实现二进制消息与Json格式消息的转换功能，中国电信物联网开放平台需要使用设备厂商提供的编解码插件。

开发的主体思路如图所示，其中也还有许多细节需要开发者注意，这里不一一阐述。再完成映射之后就可部署插件，部署之后便可进行调试工作。调试之后便是申请流程，申请测试，至此电信云平台对设备端的开发便可算结束。云平台到第三方平台可参考电信云平台调用API文档。这里只简单的阐述一下电信云平台的开发步骤，具体实现需要用户自己对接完成。到这里电信云平台的开发过程可以基本了解，至于对接推送至第三方服务器，推送具体的格式以及要求有API对接文档可以参考。移动ONENET平台的实现方式更为简单，不需要在ONENET上进行开发，将开发工作压向设备端，设备端将上报的实例属性等内容上报上来，ONENET只做推送，增加了模组开发难度以及设备端和ONENET的通讯的复杂程度，简化了设备管理平台ONENET的开发。孰优孰劣还凭用户自己体验。那么至此开发NB设备管理平台已经简单介绍到这里。因作者本人不是上位机从业者，所以只能介绍个大概，具体实现作者可以给大家推荐几个官方群，里面有专业指导以及开发指南可供大家参考。

结语

目前NB-IOT市场潜力是非常大的，许多新产品都在抢夺市场的过程中，对有相关应用场景的实业公司研发NB-IOT产品是大趋势，对于我们相关行业从业者来说掌握NB-IOT设备的运行机制以及开发流程也是对自身的一大提升。本文大致阐述了一款NB设备产品的开发流程（固定上报类），提出了一些作者在实际开发过程中实际遇到的难点，并给出一些相关的建议。希望本文能够给尚未接触过NB通讯看官一些思路的上的帮助。在我们实际开发过程中，是会遇到许许多多的困难的，不管是模组，单片机，物联网平台等等，善于思考，善于寻求协助依旧是我们解决问题的关键点。实际使用之后，我们会发现NB-IOT设备其实和2G，4G设备类似，开发流程相差无几，无外乎是一个通讯模组的应用。当然研发工作者也需要了解清楚其特性，其应用场景，做到心里有底，严谨从容。最后，辛苦大家看看看了这么久啦 – –。

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/189013.html原文链接：https://javaforall.cn

未经允许不得转载：木盒主机 » NB-IoT应用场景_iot框架