“楼宇智能化:将知识变成比数据更重要的资产”
周明春,公众号:美的暖通与楼宇
楼宇智能化:将知识变成比数据更重要的资产
楔子:知识将成为比数据更为重要的资产
关键字:IoT物模型、WoT TD、HayStack、Markup Language
当建筑遇到大数据时代,会发生什么样的化学作用?
但凡参与过几年物联网项目的朋友都知道,现实已经不是数据不够多Huge,而是数据不够Actionable。云计算让我们可用的算力提到了一个新的阶段,制约数据使用的瓶颈在于数据的有效性。何为有效数据,说到底其实就是数据背后所代表的含义你是否明白。打个比方,如果自控系统某个采集点zn3上报数据76.2,那你明白代表什么吗?我想大多数人都一脸懵比,这就是空有数据,但并不了解对应meaning的原因。建筑要实现智能化,当前最大的问题就是如何描述这些数据所代表的含义,只有明白了含义,后续的分析、加工才有的放矢,挖掘价值才有目标。
IoT物模型可以解决这个问题吗?
No. 首先先公布下答案,IoT Thing模型并不能解决这一问题
随着这十年IoT物联网的普及,尤其赶上国家将5G和物联网上升为国家战略,万物互联是未来的必然趋势,几大互联网公司及华为都在狂热地布局自己的物联网地盘,同时也掀起一大批IoT物联网模型或标准的推出。比如阿里云IoT、华为OceanConnect、百度物联,大家都将自己的物模型作为解决设备互联互通的一个钥匙。可这把钥匙是否百试不爽?那倒未必
我们以阿里云的IoT物模型为例
(图片)
它其实是一种数据模型,是物理空间中的实体(如传感器、车载装置、楼宇、工厂等)在云端的数字化表示。通过定义物模型的属性、服务和事件三个维度,分别描述该实体是什么、能做什么、可以对外提供哪些信息。可以看出这是一种相对简单的分类方法。很实用,尤其在智能家居这种产品形态功能较容易定义的应用场景下,通过概括产品的基本属性、外部服务和可上报事件,差不多确实可以将设备产品描述清楚。如果再去了解下华为、腾讯、百度几家主流IoT产品的做法,无不如此。大家其实都是来自同一个出处--W3C万维物联网联盟的WoT TD标准。感兴趣的同学也可以自己去查阅看看。
WoT TD全称是Web of Thing Thing Description。这是一种在网络上进行物联网设备描述的语言规范。建立这套规范的目的就是为了将物联网中的设备抽象为资源和服务能力连接到web空间,搭建可以兼容异构网络和分布式终端的泛应用开发环境,使得物联网上的嵌入式设备和业务更容易接入与访问。
(图片)
WoT TD的核心就是Properties、Action、Event这个三元组。不过就像对人物描述一样,WoT TD的方式类似这样:“人,是具有四肢和大脑,可直立行走的高级哺乳动物”。这不能说不对,但稍显笼统生硬,而且也不准确全面,比如猩猩,袋鼠,也满足上述描述条件。更不用提同样是人,男人/女人,成年人/幼童这些差异性。我这么举例的目的,只是为了说明一个事,这种描述方式当然也可以增加足够的Properties、Action、Event要素,来将设备的描述做的相对足够精确,但这又陷入到一个窘境。我们对事物描述的初衷是为了更好的使用,而不是给自己增加复杂度。这让我想起当年阿里智慧建筑事业部时做过的一件事,为了定义设备模型,我们也是按这种三要素的方式设计设备模型,因为项目上BA设备过于多样化,比如两管制空调、四管制空调、双水泵集水坑、三水泵集水坑…… 逐渐发现起初那种设计好物模型,然后实例化之,就可完成云边数字化的想法过于理想,因为模型上的属性Properties、动作Action、消息Event越来越难固定下来,或者即使开始筹划好了模型,但多了一两组传感点位变化,就得再新建一个独立的模型,虽然我们试图用基本模型、产品模型、项目模型的继承方式来增加灵活性,确实也算是解决了这一困难。不过回过头反思,我觉得这种直接将事物用几组要素来定义描述的方式在智慧建筑上未必合适。
那哪种方式会更好呢?
编程语言 (Programming Language) ?标记语言(Markup Language)
大家对超文本标记语言HTML应该都有概念,这是一种用于创建网页的标准标记语言,通过HTML可以建立Web网站,不管是谷歌、火狐,还是遨游、IE浏览器,无论在全球哪台联网电脑上都可以正确的打开网页。
HTML包括一系列形如<head>、<title>、<style>、<body>的标签,将网络上的文档格式统一,使分散的Internet资源连接为一个逻辑整体。它属于一种Markup描述性文本,这区别于python、Java等编程语言。
和HTML类似,我认识之前的Bacnet、OPC、Modbus楼宇自控协议其实类似于楼宇的编程语言,他们有各自的语法规范,相对应WoT TD则是一种抽象的泛描述语言,只是这种描述还显得粗大,用以做一些基本原则性的分类还行。就像区分空调和电风扇,电冰箱和烤箱。这其实一种归纳概括共性的方法,大家都知道,归纳是我们认识世界的基础,所以用WoT TD来描述相对简单明了且结构相对不复杂的设备,我觉得还是可用的。但就像“龙生九子,各有不同”,建筑是一个相对复杂的聚合体,现场环境和部署工艺的差别都导致很多设备设施,无法用这种简单结构的WoT TD模型来阐述,这就让我们需要引入一种更能描述标记差异特性的语义方法-Haystack。
HayStack 2011年由美国建筑社区协会推出,是一套用于描述建筑数据的语义标签词典和方法工具。它既有行业语义库,包括BA暖通、照明、电梯等细分行业标签,还提供一套标准API接口及工具。我理解它就类似建筑行业的HTML,是一种标记语言,借用标签的方式来对设备/系统的情况进行解释说明。这就像前面IoT物模型虽然对人进行了定义,但张三、李四这些人物个性化的区别,并无法通过名字就能获悉,还得需要很多额外的补充标注信息。比如张三腿长1米,百米可跑进10秒,是学校长跑队队长,同时资助了一位西部失学儿童等。这些都可以依靠补充comment信息来完善对张三的人物画像。类似道理,建筑内的各类设施设备包括逻辑系统和空间 也都可以用haystack的标签方式来说明其详细特征,比如我们对空间内的一个设备进行标签化描述,设备由多个点位组成,所以形成了site(space):equip:point三层结构
(图片)
从整个项目层面来看就形成了如下拓扑图(蓝色是equip、灰色是point,深色是site)
HayStack Tag很大的一个优点就是,它并不强制要求改写原有的模型结构,而是作为一种解释性补充手段。就像电商平台搞的用户画像,通过收集用户的社会属性、消费习惯、偏好特征等各个维度的数据,进而对用户或者产品特征属性进行刻画,从而抽象出用户的信息全貌。Haystack基于丰富的标签信息,打造建筑相对应的行业语义画像,让数据的使用者更能明白数据背后的真实含义,我理解这才是haystack的真实价值所在。
基于标签,我们也可以大大降低传统现场工程的人力过程。比如通过标签筛选,批量创建规则条件,过滤匹配到实际的操作对象,减少之前纯手工部署的大量重复工作。在这一块,通过使用标签,结合美的自己的暖通自控行业经验,可以将FDD和能源优化的算法发挥更大的效果。
(图片)
语义标签不仅是一种工具,还是一套思维方式
IoT物模型是基于一种假设,即我们可以很抽象的定义归纳出设备系统的所有特性可能,不管是属性property还是动作action抑或事件event,甚至也可能未来还有其他新加的类别,也就是所有的特性都可以划分到这几种类别buckets下,这是当前很多IoT物模型的逻辑。虽然这种想法的初衷很好,不过就像前面所说,计划赶不上变化,现场工程的差异性及控制场景的复杂 导致诚如暖通大机这样的设备系统一般都是按需设计定制,这就使得按既有框架的方式来定义物模型,就显得捉襟见肘,力有不逮。而标签这种画像打标方式,则是考虑事物无法从全局上一次定义明确,但可以通过多维信息的补齐,逐步将模糊的事物描述地更全面、更精准。相比较IoT物模型的归纳方法,打标签我认为是一种演绎推理的方式。基于打标的基本原则,可以灵活延伸事物的特征标识,综合这些标识,就可以勾勒出一个建筑事物的立体画像。对于信息标签化,我认为可以借助大数据的一些成熟技术模型,来整理和建立具有行业自身特色的标签体系,这对依托标签进行后续的数据挖掘分析会大有裨益。
尾声
玉不琢不成器,没有被可有效利用的数据就是沉默数据。而建筑数字化平台的互操作性就是衡量数据能否被低成本使用的一个指标,语义标签正是为了解决这一难题而被联盟共同推出的。当然我们不认为一种方法会放之四海而皆准,就像在建筑数字化这个多行业、多过程协同参与的事业中,设计和结构可能用BIM的IFC模型更适合,运营阶段用Haystack标签化更有效,审计过程则习惯用BuildingSync模型,所以还是那个道理,好用的就是最好的。我从不觉得模型形式上的大一统会是最高效的,这也不符合生物多样化的生命发展之路。不过背后的知识却必将成为比数据更为重要的价值资产