7.8 KiB
概述
物模型包括设备以太设备模型(接口/能力/属性)和感知能力模型(原安心云监测原型)，这部分在3.0+Iota的基础上没有大的改动。本方案旨在描述感知平台中概念的组合意义和少许的改动说明。
以太设备模型：具体参考《设备接入平台方案》。描述采集能力的模型= 接口+协议+属性。
感知能力模型：
感知能力模型可以理解为设备能力上的扩展。在结构物健康监测领域，就是测点和监测因素的抽象。在感知平台我们统一将这种转换模型称为‘感知模型’，转换后的数据叫做‘感知数据’或‘感知态’
我们总结了感知模型计算场景，主要有以下四种：
单个设备输出单个感知状态：如下，压力计输出的压强值，在不同的场景分别测量水位和渗流量。
注：定义的物模型 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中的结构可以定义如下：
// 结构定义 伪代码
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为空的问题。
界面设计
参考
参考：智能涂鸦 优点：低代码
- 产品定义界面：
首先产品是按类目进行分类，这个目前我们的产品比较单一，可以不考虑。
在行业解决方案中，将产品归类。如"结构物监测">"环境"中可以选择“温湿度”传感器（这个在之前的设备管理界面中添加）。
选择产品后，列举所有可行方案（前文中SenseMap），进行预览和选取。其中涂鸦的预览界面如下，我们的预览应该包括输出属性、计算、转换公式等信息。
- 定义产品的硬件开发；这部分我们通过协议去适配硬件厂商，不需要
其他界面暂无参考： 产品配置（定义固件、多语言、联动、配网、消息推送、快捷开关）、设备联调*（与APP）、自动测试用例
总结：涂鸦智能硬件高度定制化，所以能够在平台实现低代码（零代码）开发。这与我们平台定位有所缺别，我们更期望适配所有情况（设备、监测场景）。
感知模型界面
菜单中增加“感知模型”管理。
管理界面类似如下
在Thing配置界面增加感知实例的方案选择和参数设置（类似测点配置）：
Thing上增加行业标签属性（类似原结构物类型和监测因素选择）
设备部署完成后，支持自动生成感知状态配置。（选取默认方案）
进入感知配置，可以选择计算方案，输入参数信息等。