【车联网原型系统｜二】数据库+应用层协议设计
物联网原型系统导航
【车联网原型系统｜一】项目介绍+需求分析+概要设计 https://blog.csdn.net/weixin_46291251/article/details/125807297
【车联网原型系统｜二】数据库+应用层协议设计 https://blog.csdn.net/weixin_46291251/article/details/125808107
【车联网原型系统｜三】树莓派设计+模拟基站程序 https://blog.csdn.net/weixin_46291251/article/details/125808229
【车联网原型系统｜四】adhoc组网+frp内网穿透 https://blog.csdn.net/weixin_46291251/article/details/125808621
【车联网原型系统｜五】前后端分离 https://blog.csdn.net/weixin_46291251/article/details/125808674
【车联网原型系统｜六】效果展示 https://blog.csdn.net/weixin_46291251/article/details/125808845
【源码下载】 https://download.csdn.net/download/weixin_46291251/86227197
文章目录
【车联网原型系统｜二】数据库+应用层协议设计
应用层协议设计
后端与小车树莓派的通信是通过socket进行的，因此需要定义一个私有协议，区分不同类型的数据报文。数据报文采用json格式进行传输。
总体而言，报文可以分为两类，一类是控制报文，一类是数据报文。控制报文用于用户控制小车，数据报文用于传输数据信息。
字段总体设计
具体的字段和对应的描述如下表：
| 数据字段 | 内容描述 |
|---|---|
| pac_type | 数据包类型 |
| control_type | 区分不同的消息功能类型 |
| src_id | 发送方id |
| dst_id | 接收方id |
| piece | 报文分片标记 |
| time | 发送方时间戳 |
| ack | 标识ack |
| length | 消息长度 |
| state | 状态码 |
| alternate | 保留字段 |
具体字段
pac_type
首先是数据报文类型字段，这个字段主要原来标识报文的流向，主要有三种方向：
- 树莓派 到 基站
- 基站 到 树莓派
- 树莓派 到 树莓派 （对应转发到情况）
| 数据包类型(pac_type) | 数据流向 | 编码 |
|---|---|---|
| pi -> pc | 01 | |
| pc -> pi | 10 | |
| pi -> pi | 11 | |
| 保留类型 | 00 |
control_type
控制类型字段用来标识报文具体对应的功能，这部分要根据pac_type来综合判断，不同的pac_type会对应不同的含义：
- 对于树莓派到基站到类型，是树莓派反馈数据到基站到报文，分为轨迹数据、传感器数据、和树莓派电量低三种。
- 对于基站到树莓派到报文类型，主要是基站下发的控制命令，有开始/停止移动、打开/关闭传感器、一键返航和转发（转发指令给不在基站范围内的小车）。
- 对于树莓派到树莓派类型，和第二张类似，少了转发功能。
| 字段 | 指令含义 | 编码 | |
|---|---|---|---|
| control_type | pac_type == pi -> pc | 轨迹数据 | 000 |
| 传感器数据 | 001 | ||
| 电量低 | 010 | ||
| 无法避障 | 011 | ||
| 保留指令 | 100 | ||
| 保留指令 | 101 | ||
| 保留指令 | 110 | ||
| 保留指令 | 111 | ||
| pac_type == pc -> pi | 运动 | 000 | |
| 停止 | 001 | ||
| 返航 | 010 | ||
| 打开传感器 | 011 | ||
| 关闭传感器 | 100 | ||
| 转发 | 101 | ||
| 保留指令 | 110 | ||
| 保留指令 | 111 | ||
| pac_type == pi -> pi | 运动 | 000 | |
| 停止 | 001 | ||
| 返航 | 010 | ||
| 打开传感器 | 011 | ||
| 关闭传感器 | 100 | ||
| 保留指令 | 101 | ||
| 保留指令 | 110 | ||
| 保留指令 | 111 |
state字段
state字段主要用来反馈指令执行的数据，有成功、失败、超时等，还预留了一些编码用来传递自定义的状态。
| 状态码(state) | 含义 | 编码 |
|---|---|---|
| 成功 | 000 | |
| 失败（超时） | 001 | |
| 失败（指令非法） | 010 | |
| 失败（原因3） | 011 | |
| 失败（原因4） | 100 | |
| 保留状态 | 101 | |
| 保留状态 | 110 | |
| 保留状态 | 111 |
其他字段
ack字段：
系统在收到一个报文之后，可以回复一个ack报文，表示自己收到了报文（可以结合数字签名实现双向的不可否认）
- 每次收取一个报文，按照上述的逻辑收完之后，就发送一个ack报文给发送方，表示已经完成报文的接收。
- 每次发送一个报文，按照上述逻辑发送完之后，就收取一个ack报文，验证这个报文就表示本次发送结束。
piece字段：
这个字段主要是用来处理大报文的 分片问题的。
采用分片的方法，头部pieces字段来指定当前报文是否是最后一个分片，每次都发送一个完成的报头和部分的报文(取决于MTU)。
接收方每次都接收一个MTU大小的报文，解析出头部的pieces字段，判断结束条件，接收完之后将所有的数据字段组合起来即可得到完成的大报文
数据结构设计
这部分主要是小车和基站之间传递报文的内容字段的结构
指令
| 字段 | 含义 | 举例 |
|---|---|---|
| direction（list） | 四个按钮的状态 | [False,False,False,False] |
| speed | 速度 | 50 |
| diff_speed | 转向差速 | 20 |
数据
| 字段 | 含义 | 举例 |
|---|---|---|
| sensor_list | 传感器列表 | |
| data_list | 数据列表 | |
| trace_stack | 路径栈 |
数据库设计
概念模型
表结构设计
设计了以下表：
- user表：存储用户的账号、密码、用户类型（等级）、登陆时间
- sensor_info表：存储传感器的类型编号、名称、分组、描述信息
- pi表：存储系统中的所有树莓派编号、权限等级、描述信息等
- sensors表：存储系统中所有的传感器列表，包括传感器的编号、所属树莓派编号、传感器类型、SN编码（如果有）、权限等级
- data_instruction表：系统下发/执行的所有指令，包括指令id、用户id、树莓派id、时间、执行状态、指令类型、指令的具体数据
- data_sensor:表：树莓派反馈的传感器数据表，包括数据id、传感器id、用户id、时间、具体的传感器数据
- data_trace表：树莓派反馈的轨迹数据表，包括数据id、用户id、树莓派id、时间、具体的轨迹数据。
具体有以下字段
-
data_instruction : [‘id’, ‘user_id’, ‘pi_id’, ‘time’, ‘state’, ‘type’, ‘data’]
-
data_sensor : [‘id’, ‘sensor_id’, ‘user_id’, ‘data’, ‘time’]
-
data_trace : [‘id’, ‘user_id’, ‘pi_id’, ‘time’, ‘data’]
-
pi : [‘id’, ‘level’, ‘description’]
-
sensor_info : [‘id’, ‘name’, ‘group’, ‘description’]
-
sensors : [‘id’, ‘pi_id’, ‘sensor_type’, ‘SN’, ‘level’]
-
user : [‘id’, ‘passwd’, ‘level’, ‘reg_time’]
ER图
传感器表部分
指令存储部分
路径存储部分
传感器数据部分
总
物理模型：
略，见sql文件内
Crow‘foot图
