The difference between IoT application development and traditional software development

Since the popularity of shared bicycles, the development of IoT applications has become more popular, and even some non-IoT companies have begun to cut into IoT projects. As a result, projects developed with traditional Internet technologies and teams have many problems. The core reason is that there are some particularities in the development of IoT applications that need to be paid attention to. I have been engaged in the design and management of IoT software for many years. I would like to talk about the areas that should be paid special attention to when developing IoT applications.
To know the particularity of IoT application development, we must first understand the difference between IoT applications and traditional Internet projects. Technically speaking, the biggest difference between IoT applications and traditional projects is the difference in the source of data generation. The data of traditional software or ordinary Internet software is input by people, and the server must preprocess the received data. If the data does not meet the requirements, it will return to the user to re-enter the data. For example: Take the user using the bank APP to transfer money online as an example, if the user enters a wrong account that does not exist or enters a letter in the transfer amount (generally, the client will control the amount input to prevent the amount column from entering letters like this) event happens), then the server will catch this input error and send it back to the client to ask for re-input. Even in order to improve development efficiency, many development frameworks have integrated input compliance detection into the development framework.
However, the data of the Internet of Things is basically not generated by manual input, and many Internet of Things application devices have been used in high temperature and high humidity environments for a long time, and can only use relatively low-end operating systems and programming languages, which are more prone to terminal program errors. And network problems produce data corruption problems. I categorize common problems into the following three categories and give solutions:

1. The instability of the network leads to disordered data packets. The reason is that most IoT devices currently use low-level operating systems and use lower-level communication protocols (mainly TCP and UDP). There are two more problems: packet sticking and data confusion.
(1) Packet sticking means that multiple data packets initiated by the terminal program are combined by the network layer and sent to the server, resulting in the server unable to parse the data correctly.

The solution is to agree on the header and footer of the data packet, such as "OX" as the header and footer of each data packet

服务端即使收到"OX12345OXOX67890OX"这样的数据也很容易就能把数据还原成"OX12345OX" 和 "OX67890OX"并进行后续处理。

(2)数据错乱指数据在传输过程中被改变了,导致服务端收到的数据是错误的。

解决办法是在发送每一包的数据都增加一个校验位X
服务端每次收到数据先计算校验位X是否正确,如果校验位不正确说明传输过程中数据已不可信,告诉设备重新发送数据即可。


2.通讯超时问题:这里主要指的时终端的数据已经送到服务端,服务端接收数据后通知终端时网络阻塞导致的,
这里的主要问题是终端与服务器状态不一致(终端以为数据没有发送成功,而服务器已经执行了该数据)。

解决办法是服务端要有重复数据处理机制,这里也分两种情况。
(1)不改变业务状态的过程数据:比如共享单车要定时向服务端发送自己所在的位置坐标,当服务器接收到的坐标发现跟之前已经接收过的数据是重复数据时只要丢弃这包数据并告诉终端“接收成功,继续发送下一包数据“即可。
(2)需要改变业务状态的数据:比如学员在学车时先要在教练车的终端设备上做签到,如果9:00分终端向服务器发起签到请求,服务端处理了签到请求并发还给终端设备告知允许签到,这时网络阻塞终端设备没有收到允许签到的回复。这一时刻设备终端学员是非签到状态而在服务端学员已经是签到状态(终端设备的学员状态与服务器端的学员状态产生了不一致)。等到9:01分学员再次尝试签到,这个时候服务端又接收到了签到请求,服务端就需要把学员的签到时间改成9:01分并返回给设备签到成功(这里的处理逻辑与传统程序的处理逻辑不一样了),如果第二次没有产生网路阻塞,终端设备接收到服务端发送过来的允许签到结果后把自己的状态改为学员9:01分签到。最终终端设备和服务器的状态是一致的。

3.终端产生的异常数据:主要原因是大部分物联网终端的应用场景(要求终端体积要小,在室外高温高热环境长期工作)采用的是低级操作系统及开发语言做应用开发,这就需要开发人员人工管理内存(目前的高级开发语言比如JAVA就是系统自动管理内存,不需要开发人员干预),很容易因为内存越界等问题导致数据错乱(例如转账金额变成字母)。这种问题是最麻烦的,因为发回设备重新交互也不会产生正确的结果,只能在服务端把异常数据另外保存起来并记录下终端编号及发生时间,供后续人员排查问题并手工处理异常记录。


Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324459318&siteId=291194637