有一段时间不写关于工业软件方面的博文了,以至于有网友私信问我-"你还在搞工业软件么?”疫情再一次爆发,人没有出门,思想到也没有闲着。前一阶段主要研究工业控制领域的标准,协议和各种单一技术的实现,比如IEC61131-3,IEC61499 ,OPC UA 控制协议,PLC 运行时,以及工业4.0 的管理壳,ISA-95 标准,MES 等等。在学习和研究这些标准,技术的过程中,也经常有朋友问我,这个技术有前途么?在国内如何推广等问题。这些带有普遍性的问题,究其根本,就是我们从哪里切入工业软件领域的市场?
众多的标准和技术,正在构建成为一个缜密的技术体系。在开放性系统没有完全到来之际,依靠某一项单一技术是难以进入该领域的主战场的。比如,我们开发了某一个硬件产品,用户只有替代国外产品,获取价格优势的动力,而前提是与他们现有的软件兼容。毕竟,在工业自动化领域巨头林立,游戏规则又完全是别人说了算。
反复思考这个问题,本人感觉我们缺乏系统性思考。我们的自动化厂商往往是从设备研发做起来的。购买国外的开发工具和运行时源代码,开发出各种PLC,驱动器,传感器和网关。上层软件仍然摆脱不了国外的系统。
在这段时间,也研究了各种工业控制方面的技术标准和技术,开始从OT 行业的角度来看待技术,比如开口必谈模型,OPC UA 协议和各种标准体系。他们强力地接受了OT 行业的观念。却很少涉及工业软件内部的实现,而且网络上相关的研究文章很少。比如如何实现基于模型的组态化MES系统?如何实现数字化工厂软件?与IT行业各种开源软件相比,OT显得多少有点神秘感。
于是我想,也许我们应该换一种思路。从上层软件入手,直接解决用户的问题。然后再进一步开发底层设备。自顶向下的方式更加利于市场推广。当然,直接将IT行业的技术照搬到OT行业是不现实的。OT行业除了行业的固执以外,还有他们独特的需要。使用IT 的最新技术实现满足OT需求的软件系统是正确的方法。
于是,我开始了这个领域的探索工作,为了使研究成果能够快速地融入应用项目,我的原型系统是一个物联网系统(MAXIM System)。这个系统能够很快地应用与工业物联网,MES,SCADA等软件之中。
实现物联网系统组态化的关键是建模,只有通过建立数字模型,才可能实现参数化和图形化。这就是OT 行业推崇的基于模型的设计。
系统是一组相互作用的元素,它们共同作用以实现某种特定目标。建立模型要能够反映这些元素的属性,以及它们之间的相互关系。数学是系统工程中最有效的建模语言。许多物理元素和规律能够使用数学来描述和推演。在IT领域,面向对象的概念也是一种建立系统元素属性以及相互作用的方法。
实践证明,面向对象的概念是构建复杂系统最有效的方法。例如C++ 程序设计语言中,使用所谓“类“(class)来描述事物。而同一类的事物称为”对象“,也被程序设计语言中被称为”类“的实例。
现在数字化物模型大多数是基于“面向对象”的概念来构建的。而数字化模型的描述语言也是基于这些概念设计出来的。
除了面向对象程序设计语言之外,独立的模型描述语言被设计出来,它们与具体的程序设计语言无关。这样的数字化模型能够通过不同的程序设计语言来处理,并且在不同程序设计语言编写的程序之间交换模型化的数据。模型描述语言与编程语言无关(programming language independent )非常重要。
评价一个模型描述语言的优缺点有下面这些标准。
1 简洁,适合非程序员编写。
2 处理效率高(速度快,仅使用少量内存和存储空间)。
3 保持网络流量小而快。
4 可读性,适合人类阅读。
前面提到面向对象程序设计语言中的类与对象是构建物体数字化模型的有效方法。但是如果直接采用程序设计语言来构建模型的话,势必造成模型将依赖于某一种计算机语言,而不同的程序设计语言,其语法和语义存在很大的差异性。因此,系统工程师更加倾向于采用语言中性的形式化模型描述语言。UML 就是一种常见的模型语言,称为统一建模语言。UML是采用XML 来描述。
主要的模型描述语言
物联网始终是一个笼统的概念,有大量非人类节点参与通信的网络都可以称为物联网。从这个意义上讲,传统的网络型自动控制系统都是物联网系统。为了具备通用性,我们研究物联网模型的相关技术,它们可以很容易地复制到大量具体的控制系统中。
系统架构曾经是一个试错,“走到哪算到哪儿“的观念。有时候架构只是在开发结束时,编写文档时才来总结架构。物联网系统也是从将一个树莓派,PLC 连接到一个网站,数据库系统,然后增加网页,手机App;形成物联网应用。
这种“野蛮生长“的应用系统,难以扩展和团队分工。软件无法在不同应用项目中重复使用,软件功能不能不断地扩展。往往迫于项目进度,人力成本的限制;造成开发的应用系统功能单一,简陋。可靠性和确定性无法验证。
从长期主义的观点出发,采取基于模型开发的形式化架构方法论十分重要。国际系统工程协会(INCOSE)定义了基于模型系统工程(MBSE),即形式化应用建模来支持广泛的系统工程活动,包括需要分析,设计,分析,验证和确认。这些活动从概念设计阶段开始,延续到整个开发和后续的生命周期阶段。
基于MBSE的思想设计物联网系统架构,将目前 “设备/应用程序“的二层物联网架构转变成为”设备-物联网平台-应用“三层架构。
三层物联网架构带来的好处是:
物联网是一种分布式系统,模型定义的实体分布在网络中。物模型数据存储在云端服务器中,物理设备和软件组件能够访问物模型,存取数据。
物联网模型与设备中的模型有所不同,比如在自动控制领域,在设备中建立该设备中的数据模型。应用程序通过server/client 方式来访问设备。例如opc ua 模型下:
在物联网应用系统中,物联网服务器是一个中间层。底层是现场设备,高层是应用软件和支撑软件组件(Support Software Component)。底层和上层组件通过server/client方式实现相互访问。
由于增加了中间层,访问将是异步进行的。应用程序访问物联网层,物联网层访问现场设备,反之亦然。
软件相互之间的访问也演变成为互为Server和Client。如图所示
三层物联网模型的基本特点
物联网平台与设备和软件组件之间采用标准化的协议实现交互,它们可以是工业控制领域的OPC UA 协议,也可以是物联网系统中常用的MQTT,或者互联网系统常用的TCP/IP,websocket,HTTP 等等。
协议姑且重要,语义同样十分地关键。语义涉及到模型的规范化描述。
在MAXIM System 物联网平台的模型的设计中,设计了一套内部统一的物模型模板(Template),各种外部协议的数据可以转换成为内部的物模型模板格式。
前面我们已经提到,使用面向对象的概念来构建物模型。并且使用XML和JSON语言来描述对象的模板(Template)。
建立物模型的方式由许多种,也有大量现场的信息模型可以借鉴。例如C++ 中的类,OPC UA 的信息模型,IEC61499 标准中的功能块。在本实验系统中,我们采用图模型来构建物模型。
使用图模型能够有效地描述面向对象的物模型。
模型中的最小元素称为颗粒。在前面的讨论中,我们使用json语言来描述对象。也就意味着模型的最小颗粒是类,其中包含了属性,方法等。如果以对象作为颗粒,那么每一个类就将成为一个元素,元素的类型会有许多,而且对象内部的引用和描述会比较复杂。因此在建模中可以将颗粒进一步细分。基本颗粒变成变量,方法。一个类可以由变量,方法等元素来描述。如此一来,最小颗粒的种类只有简单的几种。模型描述的方法更加灵活和简单,而构建物模型会变得相当复杂一点。
将模型描述的方法进一步地形式化,人们发现能够使用图论中的图来构建物模型。在图论中,图是由一些圆圈和连线构成的。图模型由下列几个要素
例如:下面的这张图反映了两个人A和B以及一台车的关系。它由三个节点和四个关系构成。如果在每个节点中还包含人的姓名,性别,年龄以及车的型号,颜色等属性。含有的信息量就更加丰富。
OPC UA 是工业软件中的一个重要的协议。它的信息模型是以图形模型为基础的。在OPC UA 中,定义了一组节点。使用这些节点能够定义面向对象中的对象。
事实上,许多数字化工厂的标准中也是通过图来建立各种复杂的模型的。
物联网中的数据是具有复杂的关系,比如公司拥有车间,车间拥有生产线,生产线拥有设备,设备中有电机和传感器。不同的人员和软件在不同的时刻关心和处理的数据也是不同的。一个物联网系统中事物的关系是非常复杂的,多样的。因此,表现事物的数据也存在复杂的关系,数据的关系称为数据的上下文(Context),有人称数据的上下文关系为“数据的脉络”。非常的贴切。如果数据脱离了上下文关系(context),那它仅仅是数据而已。数据上下文对于数据而言,就好比如鱼得水。
物联网是“事物”的网络。这里的事物包罗万象,包括了任何能够数字化描述的事物,包括机器,人,动物,软件等等。这些事物是又相互关系的。搞清楚事物的相互关系,就能够当一个事件发生时,根据数据的脉络,通知相关的节点发生改变。如果事物是节点的话,物联网本质上是多个节点的网络。所以有人说,物联网是图,图就是物联网。
构建模型的目的为了系统中不同的主体的相互访问和交换数据,只有交互双方都保存了一致的模型,才可以相互交换信息。比如OPC UA 系统中,要求服务器端和客户端都保留服务器的模型信息,客户端才可以访问服务器。
一个容易引起混乱的事情是,在OPC UA 的信息模型中,自动控制系统中的设备被称为是服务器,而访问它们的软件被称为客户端。这和IT行业的服务器、客户端的概念恰恰相反的。在一个IT概念下的服务器/客户端系统(例如多台PLC 加上SCADA 软件) 中,服务器软件要访问所以的现场设备。它就需要保留所有现场设备的信息模型。对于IoT 系统而言,保留所有设备的信息模型,是非常庞大和复杂的。需要适合模型存储的数据库技术。
建立模型的方法有两种方式,一种是通过菜单和表格来建立模板。这种方式的优点是比较直观,非IT 专业人士可以使用,但是建立大量数据模型时,效率低下。另一种方法是采用语言描述。在实验系统中使用JSON 语言来描述物模型。
下面是一个电表的JSON模板
{
"Name":"Meter",
"DisplayName":"Meter",
"Description":"",
"NodeType":"Object",
"Catalog":["Template","Meter"],
"Attributes": [
{
"Name":"energy",
"Unit":"kWh",
"ValueType":"float",
"DisplayDigits":3,
"DefaultValue":0,
"Value":0,
"DataReference":""
},
{
"Name":"Current",
"Unit":"A",
"ValueType":"Float",
"DisplayDigits":"3",
"DefaultValue":0,
"Value":0,
"DataReference":""
},
{
"Name":"Voltage",
"Unit":"V",
"ValueType":"Float",
"DisplayDigits":"3",
"DefaultValue":0,
"Value":0,
"DataReference":""
}
],
"Childs":[],
"Reference":[]
}
既然图模型能够有效地构建物联网系统中的物模型。在物联网系统中如何能够高效地存储和访问图模型呢?在几个著名的物联网系统中采纳了图数据库(Graph Database),例如GE 公司的predix。OSIsoft 公司的AF。
图数据库是图模型数据的数据库。它的数据建立,查询和修改都是以图的形式进行的。所以,要建立图模型的物联网需要使用图数据库。neo4j是目前最流行的开源图数据库。
neo4j 的架构如下图所示:
在物联网系统中,大量的现场实时数据是存储在实时数据库中的。它们通常是所谓时间序列数据库。
在物联网应用中,通常建立多种数据库。
时间序列数据库
快速存储大量具有时间标签的数据。每一项数据具有一个唯一的数据引用指针(DataRefernece)。
图数据库
以图模型的方式存储物模型性的数据以及实时数据库中的数据引用指针。应用程序能够通过图数据库中的物模型,迅速查询
在OSIsoft 公司的软件产品中称为资产架构数据库(AF Database),也有人称为CPS 数据库(Cyber-Physical Systems database)。在我们的设计中,简单地称为数字资产数据库(Asset Database)
为了验证图模型数据库在物联网建模中的应用,我们编写了一个演示系统MAXIM System 。
这是物联网模型管理平台,基于NodeJS设计,它通过Neo4J Driver 访问Neo4J数据库。IoT Server 的主要功能;
IoT Server 的前端系统采用Vue 架构。实现前后台分离模式。Vue 采用独立的服务器,通过Restfull API 访问IoT Server。
Vue 前端主要功能是基于web 的IoT 系统管理
图数据库用来存储基于物模型的数据及其关系。InfluxDB 存储非结构性实时数据。
使用Jquery,Bootstrap,HTML5,CSS,Javascript 这些基础技术构建HMI 模型代码工作量比较大。在我们的演示系统MAXIM System中,我们采用了VUE 前端架构来构建HMI 模型。
HMI 界面是一种分层结构,最顶层是Page,然后可以进一步分为面板(Panel),按钮,滑杆,仪表盘以及众多特定行业的HMI 单元,例如电机,阀门,反应釜等等。
复杂的HMI 是由基本的单元构建而成的。HMI模型化的第一步就是建立HMI基本单元的模型。
HMI 模型由两个部分组成:
图模型适合描述分层结构,系统中的HMI 模型采用系统统一的图模型。每个HMI基本单元是系统模型中一个节点。 而关系描述了分层结构。
在前端采用VUE 组件来实现HMI 基本单元的视图(View)
通过实验系统的研发,证明了采用图模型建立组态化物联网系统的可行性。这种方式更具有通用性,可以快速地构建各种物联网应用系统。
涉及的内容很多,无法在一篇博文中描述。感兴趣的读者,看我的其他一些相关文字
尽管图模型可以建立方法,订阅,事件等动态执行的节点。但是如何能够更强地描述物联网运行算法,和程序。仍然需要进一步研究。