You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
182 lines
7.8 KiB
182 lines
7.8 KiB
3 years ago
|
## 概述
|
||
|
|
|
||
|
|
物模型包括设备**以太设备模型**(接口/能力/属性)和**感知能力模型**(原安心云监测原型)，这部分在3.0+Iota的基础上**没有大的改动**。本方案**旨在描述感知平台中概念的组合意义和少许的改动说明**。
|
||
|
|
|
||
|
|
以太设备模型：具体参考《[设备接入平台方案](http://svn.anxinyun.cn/Iota/trunk/doc/设备接入平台方案.docx)》。描述采集能力的模型= 接口+协议+属性。
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
感知能力模型：
|
||
|
|
|
||
|
|
感知能力模型可以理解为设备能力上的扩展。在结构物健康监测领域，就是测点和监测因素的抽象。在感知平台我们统一将这种转换模型称为‘**感知模型**’，转换后的数据叫做‘**感知数据**’或‘**感知态**’
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
我们总结了感知模型计算场景，主要有以下四种：
|
||
|
|
|
||
|
|
单个设备输出单个感知状态：如下，压力计输出的压强值，在不同的场景分别测量水位和渗流量。
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
> 注：定义的物模型 MOME (Model Of Monitor Element) 监控对象模型
|
||
|
|
|
||
|
|
几个相同设备组合输出另外一种感知状态：常见多弦锚索计中，取多个单弦设备的平均输出。
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
不同类型设备的组合输出：目前平台通过特殊处理来实现（例如依赖外部温度传感器的温补计算）
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
还有一类就是设备的输出，需要与组内其他设备的数据进行关联计算，得到‘相对’的或‘累计’的变化，即沉降和测斜管内部位移
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
## 感知模型定义
|
||
|
|
|
||
|
|
感知模型是设备数据到感知数据转换的依据，主要包括输出映射和公式计算。同时，需支持透传模型，适配设备态即感知态的场景。
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
可知，感知模型是针对具体设备和感知场景确定的。除了安心云结构监测场景，我们期望平台将各个行业解决方案录入，用户创建Thing 的时候从行业方向、应用场景选择，到对应的感知模型选取，均可以从内置的行业标准库中选取：
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
几个关键表设计大体思路如下：（所有资源应包含公共和私有两部分，各租户可以自建自己的解决方案数据库）
|
||
|
|
|
||
|
|
**IndustrySolution** 行业解决方案
|
||
|
|
|
||
|
|
| 行业名称 | 场景 | 项目 | SenseModel_ID | | |
|
||
|
|
| -------- | -------- | -------- | ------------- | ---- | ---- |
|
||
|
|
| 智慧工地 | 工地安全 | 人员监测 | 1 | | |
|
||
|
|
|
||
|
|
**SenseModel** 感知模型（原监测原型）
|
||
|
|
|
||
|
|
| id | name | items | agg | tags | |
|
||
|
|
| ---- | -------- | --------------------------------------- | ----- | ----------------------- | ---- |
|
||
|
|
| 1 | 人员监测 | [{field:a, name:v,unit:cm,precesion:5}] | [sum] | {"category":"智能网关"} | |
|
||
|
|
|
||
|
|
感知模型包含字段名、显示名、单位、小数位数。 agg字段用于表示该模型需要的默认聚集方法（如空气质量指数模型，默认需进行aqi的指数聚集）。
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
**SenseMap** 感知方案（映射/计算）
|
||
|
|
|
||
|
|
| DeviceMeta 设备 | CapabilityMeta 能力 | SenseModel_ID | MR | | |
|
||
|
|
| --------------- | ------------------- | ------------- | ------------------------------------------------- | ---- | ---- |
|
||
|
|
| abc | abd | 1001 | {"script":"x=a+b","type":"exp","map":{"a":"b"}} | | |
|
||
|
|
| x | c1 | 1001 | {"script":"function","type":"js","map":{"a":"b"}} | | |
|
||
|
|
| y | c2 | 1001 | {"script":"function","type":"js","map":{"a":"b"}} | | |
|
||
|
|
|
||
|
|
上述举例：支持内联公式、表达式、脚本方式实现MR映射计算。示例中 x/y设备关联到同一个SenseModel，实现组合计算。具体实现方案需细化。
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
实例化方面，在部署完成后，设备到感知态的映射需要进一步配置（等同于原测点配置，割离接入无关的参数属性）
|
||
|
|
|
||
|
|
| SenseID | 设备ID | SenseMapID | Params | |
|
||
|
|
| ------- | ------ | ---------- | -------------- | ----------------- |
|
||
|
|
| 1 | abc | 1 | {"height":100} | |
|
||
|
|
| 2 | abd | | | *可以无 Sense Map |
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
## 数据存储格式
|
||
|
|
|
||
|
|
架构方案中已说明，引入数据湖IceBerg。主要用于存储原始设备数据 和 数据源文件归档。计算后的感知数据、聚集数据、告警数据，按照原平台方案存储在ElasticSearch中。简单说明如下：
|
||
|
|
|
||
|
|
设备数据在IceBerg中的结构可以定义如下：
|
||
|
|
|
||
|
|
```java
|
||
|
|
// 结构定义 伪代码
|
||
|
|
TableSchema shecma=TableSchema.builder()
|
||
|
|
.field("id",DataTypes.String())
|
||
|
|
.field("time",DataTypes.Date())
|
||
|
|
.field("data",DataTypes.Map())
|
||
|
|
```
|
||
|
|
|
||
|
|
其中：id-设备ID，time-采集时刻，data-采集数据（map格式）。
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
IceBerg数据入湖的几个步骤：
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
我们定义的IceBerg创建在`Hive`存储之上，所以首先要建立Hadoop Hive的集群，这个可以在ambari中添加服务的方式实现。
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
感知结果：
|
||
|
|
|
||
|
|
感知结果等同于原测点（主题）数据。我们将感知数据做简化，如下，只保留sensor/collecttime/data字段
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
告警数据：
|
||
|
|
|
||
|
|
存储在索引 anxinyun_alarms 、 anxinyun_alarm_details。格式基本不许改动
|
||
|
|
|
||
|
|
聚集数据：
|
||
|
|
|
||
|
|
存储在索引 anxinyun_aggregation 。格式不需要改动。注意修正data为空的问题。
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
## 界面设计
|
||
|
|
|
||
|
|
### 参考
|
||
|
|
|
||
|
|
参考：智能涂鸦 优点：低代码
|
||
|
|
|
||
|
|
1. 产品定义界面：
|
||
|
|
|
||
|
|
首先产品是按类目进行分类，这个目前我们的产品比较单一，可以不考虑。
|
||
|
|
|
||
|
|
在行业解决方案中，将产品归类。如"结构物监测">"环境"中可以选择“温湿度”传感器（这个在之前的设备管理界面中添加）。
|
||
|
|
|
||
|
|
选择产品后，列举所有可行方案（前文中SenseMap），进行预览和选取。其中涂鸦的预览界面如下，我们的预览应该包括*输出属性、计算、转换公式*等信息。
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
2. 定义产品的硬件开发；这部分我们通过协议去适配硬件厂商，不需要
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
其他界面暂无参考： 产品配置（定义固件、多语言、联动、配网、消息推送、快捷开关）、设备联调*（与APP）、自动测试用例
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
总结：涂鸦智能硬件高度定制化，所以能够在平台实现低代码（零代码）开发。这与我们平台定位有所缺别，我们更期望适配所有情况（设备、监测场景）。
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
### 感知模型界面
|
||
|
|
|
||
|
|
菜单中增加“感知模型”管理。
|
||
|
|
|
||
|
|
管理界面类似如下
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
在Thing配置界面增加感知实例的方案选择和参数设置（类似测点配置）：
|
||
|
|
|
||
|
|
Thing上增加行业标签属性（类似原结构物类型和监测因素选择）
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
设备部署完成后，支持**自动生成**感知状态配置。（选取默认方案）
|
||
|
|
|
||
|
|
进入感知配置，可以选择计算方案，输入参数信息等。
|
||
|
|
|