先前写了一篇漫谈工业App（1）的博文，阅读量相对比较大，看来关注工业App的人很多，也有读者希望本人多写一点这方面的文章。不过自己觉得惭愧。没有到可以系统地描述工业App的水平，事实上，我的许多博文都是基于自己研究的基础上的结果。自然不会写的那么快了。
实践中的困惑
漫谈工业App（1）是我们2019年全年研究开发的报告。在2019年，我们从IT技术的方向，探索了基于容器（docker）的工业App以及工业边缘设备的开发。由于docker 的可快速部署，更新和多语言，多环境开发的诸多优点。我们认为将工业App 规范成为容器中运行的映像是一种好的方式。为此我们开发了类似android 用户界面的App 管理，运行界面，App 之间的消息系统采用了rabbitMQ 消息系统，并且采用了Google的pbuf 编码。
类似android的界面
基于docker 技术的工业App 架构
基于该架构的边缘设备采用了瑞芯微的RK3399 以及全志的H6 模块构成。终端设备则是我们自行开发的modular-2 ，一台基于Arm 公司 Mbed OS 的STM32 模块化设备。有关信息可以在我的博文中找到。
我提到过，所谓App 就是指容易部署，运行和更新的软件。不同的厂商开发的App 能够在容器上运行。最终达到与设备无关的境界。设备制造商，系统集成商，用户以及第三方软件公司都能够向客户提供有价值的工业App，并且能够保护它们的知识产权，并且获得其商业利益。
大大小小的公司宣称开发了各种平台，架构漫天飞。它们无非是一堆软件，协议和规范。在这堆“东西”（专业一点可以称为Objects）就是平台，它们的相互关系就是架构。2019年我们忙活了一年，就是搞了这一堆“东西”，构建了一个所谓的平台。目的是希望让工业App开发，部署，升级更加敏捷化。它基于容器（docker）技术的微服务架构。并且为App 提供了时间序列数据库，数据可视化。末端设备开发等支撑性微服务。
一开始，我们采用了C++ 作为App的主要开发工具，后来为了提高App开发的效率，又转向了Go 语言开发。
这些技术已经在我们的内部项目中应用起来了。
但是，事情也许仅此而已。作为一个小的团队开发的这一堆“东西”，在自由的市场中，谁会认可你呢？事实上，许许多多的团队都怀揣在远大的理想，在搭建自己的一堆“东西”。其中包括了阿里，百度，或者华为这样的大个子。而像我这样的小个子也不完全认同像阿里，百度的物联网平台。只有各自为战了。另一方面，传统控制行业的工程师和系统集成商基本上无法接收IT工程师的东西。别说你的App 有多容易开发。API 有多丰富。控制工程师根本不愿意编写任何程序。万不得已，也就是买一个mdbus网关，连到远程PC，手机端，也就实现企业上云了。
我们同时也研究了GE,DELL 公司的一些工业物联网项目，无非是API更丰富一点而已。也是叫好不叫座。
信息技术和运营技术的差别（IT/OT）
也许要感谢2020年春天的这一场疫情。居家隔离给了我足够的时间来看看另一个世界中的大个子们-工业界的大佬 Schneider，Siemens，ABB，Honeywell 它们的所想所思。
在它们的眼里，我们前面提及的一堆“东西”是IT技术，而它们的技术是所谓OT技术。
所谓OT 就是Operating Technology，可以翻译成为运营技术。运营技术最常用的定义来自Gartner：“通过直接监视和/或控制企业中的物理设备，流程和事件来检测或引起变化的硬件和软件”。
OT也被定义为与物理世界连接的技术，包括工业控制系统 （ICS），而工业控制系统又包括监督控制和数据采集（SCADA）和分布式控制系统（DCS）。
运营技术无处不在：您可以在智能工厂，运输，石油和天然气，采矿，公用事业（电力，水……）的工业运营以及办公楼和医疗保健设施等设施中找到所需的技术例子。
就像IT一样，OT也是随着时间而发展的。它们不断地采纳了IT领域的最新技术，并且又和IT技术之间保持隔离。在OT发挥重要作用的许多领域中，专有协议开始使用，并且今天经常使用。在诸如建筑物管理之类的应用中，接下来开始在IP上使用通信协议。
OT的一项重要发展是能够远程监视和控制物理设备。诸如OT中的大数据和机器学习等基于IT的技术的注入，以及机器对机器（M2M）通信和物联网（传感器）的发展，在物理管理方面实现了充分的创新。工业流程中的设备，以及诊断和维护（远程诊断，预测性维护）以及我们从工业物联网了解的其他用例中的其他设备。
OT喜欢将自己限制在传统自动化金字塔的最低级别（现场级别，控制级别，生产级别等），在一个制造工厂，往往ERP系统被认为是IT技术，而过程控制，生产线控制，PLM，MES 是OT技术。
控制系统包括SCADA系统（监督控制和数据采集），DCS （分布式控制系统）和可编程逻辑控制器（PLC）。RTU （远程终端设备），人机界面（HMI），嵌入式系统和计算技术，机械，工厂中的物理设备和变频驱动器 （VFD）也是OT运营技术。
尽管IT和OT技术的界面越来越模糊。但是它们关注的重点是不同的。OT技术更加关注与物理设备的连接和控制，强调安全性，实时性和确定性。
正在由于IT和OT技术的不同，OT领域的公司和专家们非常小心谨慎地定义OT领域的软件，网络协议，安全和硬件技术。
OT专家对开放型系统看法
OT 领域的专家和公司并不是固步自封的保守派。他们也在不断地评估IT领域的新技术，特别是开源的IT技术，诸如容器（docker）技术,大数据技术，AI技术等等。
例如Automation.com总编辑 Bill Lydon的指出：“ 下一代制造或生产运营应围绕一个通用的开源体系结构为中心。这将遵循开放标准驱动的Internet和企业计算模型。工业自动化实际上是计算机的一个用例，尚未成熟到可以接受这些概念。”
比如Docker 容器技术，OT 专家也认为容器技术帮助硬件和软件解耦。更加方便地部署工业软件。
施耐德电气的Kling指出，在行业层面上，过程自动化实践正在沿着相邻行业（例如金融，电信和医疗保健）已经走过的道路发展。“在过程自动化领域内的工业控制系统中，我们正在努力，取得成功并将其应用于我们的行业。”
Kling补充说：“今天，我们在使用容器时并不总是意识到，就像在与基于云的服务进行交互时一样。” “依赖云服务的应用程序可能已经利用了容器。我们要做的的是让这些容器将越来越靠近边缘，内部部署或云，或移动到资产上生活的嵌入式设备
Kling 提出，“您再也不必点击Setup.exe！ 您交付的容器已经设置了应用程序，因此整个概念将消失。容器化软件还将提供更高的灵活性，因为您可以为这些模板化的“即用型”应用程序构建存储库，并根据需要进行部署。”
霍尼韦尔的Urso说：“这对我们来说是令人信服的，因为在一个大型项目中，以传统方式完成此过程可能需要18个月的时间。” “我们曾经有很多人在偏远的地方在物理盒子上工作。现在，我们可以让我们的人员处理托管在一组虚拟机中的云数据中心中的项目。完成后，我们将虚拟机复制到物理设备。”
在OT技术中，另外一个重要的概念是MTP（module type packages）
模块工程师能够使用程序库来构建模块，库中包含了许多的功能（function），除了通常的功能以外，还包括了图形描述。这些图形描述方便地构建可重用的模块，一旦模块构建好，MTP 就自动形成了，可以下载到PLC 中运行。
MTP 使用自动化标注语言（“Automation Markup Language，AML, IEC 62714)描述。包括了过程参数的描述，服务的描述以及控制映像的描述。根据标准化的方法和框架，每个MTP都包含将其自身集成到模块化工厂中的所有必要信息，例如通信服务，人机界面（HMI）描述和维护信息。
系统工程师可以使用某些MTP工具来使用MTP模块。
在通信方面，OPC-UA 是一个重要的标准。例如，在ABB的MTP产品中，该公司的ABB Ability System 800xA操作流程并编排智能模块。开放式体系结构主干通过OPC UA的通信将业务流程层链接到模块层。
下面是ABB 公司的MTP架构。
OT 专家们也指出。在过程工业中大受欢迎的另一个容器实例化是模块类型包（MTP）。MTP本质上是创建的容器，可通过可根据生产需求轻松添加，安排和调整的预自动化模块化单元，简化模块化过程工厂的集成和自动化。
IEC61499会成为工业App的封装么？
我并没有过多地研究MTP，不过我猜想MTP 任然是与厂商相关的。不同厂商开发不同的MTP。 工业App 需要更进一步标准化。IEC61499 标准是一个好的选择。IEC 61499 是针对分布式工业测量和控制系统的功能块编程方法。
schneider的“Kling解释说：“ IEC 61499具有围绕功能块构建的事件驱动模型，解决了确保跨供应商之间的可移植性，可配置性和互操作性，以及同时确保软件和硬件独立性的问题，该标准使我们能够独立开发将在各个平台上运行的容器。公司将继续构建最适合其报价的软件包，但由于IEC 61499等标准，该软件将变得越来越具有互操作性。”
61499的分布式特点天然地和容器相吻合，可以在容器中部署多个IEC61499 运行时。使用功能块连线图，可以构成应用程序。
IEC61499应用程序依靠的是功能块库。我们在前面的博文中也提到，功能块的本质是软件组件的图形化。运行时是动态解释执行功能块网络描述的应用程序。IEC61499 开发环境IDE 可以编辑，部署和监控各个运行时上的应用程序。
可以针对不同的应用，编写不同的运行时和功能块库。在我们的研究项目中，我们采用了开源项目4DIAC 的IDE和Forte 运行时。并且将Forte 在docker 容器中运行。扩展了功能块库和模块。4DIAC 的Forte 是C++编写的。可以在linux 环境下运行。
另一方面，为了能构是IEC61499 系统更好地与云计算，大数据，AI，物联网这些IT新技术更好地融合，我们自主开发了TinyForte 微型运行时，他们包括
1 在cortex-M 系列单片机上运行的运行时。采用C++ 语言编写，并且采用Arm 公司的Mbed OS，也可以移植到free RTOS 等其它RTOS 上。
2 在NodeJS 和浏览器上运行的javascript TinyForte。并且开发了基于web UI技术的HMI 功能块库
3 Go 语言实现的tinyForte 版本，开发了数据库访问（influxDB），云端连接的功能块库。
这些实验就是实现 IEC61499 any where 的愿景。
在上面的系统中，上面是一个边缘设备，基于linux和docker技术。docker 的编排工具可以方便地部署IEC61499 运行时。这些运行时相互独立，互不干涉。就像各自拥有CPU。下面是基于cortex-M 单片机系统。它们是实时执行机构和传感器。
每个运行时支撑的功能块是不同的。分别针对了HMI，SCADA，数据库，数据分析，过程控制，和云端访问。通过IEC61499 IDE 可以动态地部署和监控每个运行时的功能块网络。这些功能块有些是实时的（RealTime），有些是随时在线（ anyTime）的。
IEC61499 有效地保护知识产权
只有能够保护开发者的知识产权，是开发者获得经济利益，才能被广泛采纳，IEC614gongyin99 的应用程序使用功能块网络实现，开发者并不需要提高功能块的源代码。他们的IP 封装在了运行时的程序中。这样既能保护知识产权，又不失去灵活性。设备供应商，系统集成商，用户以及第三方开发者都能够提供功能块库。
小结
1 IT的 容器技术适合部署工业App。
2 各种工业App平台或者架构的困惑是缺乏标准，无法被它人接受。
3 简单粗暴地将IT技术应用与OT领域是不够的，行不通的。
4 IEC61499 标准可以成为工业App的封装工具，实现工业App的标准化。
5 我们的愿景是 IEC61499 anywhere
现在，项目还在不断地研究中，博文难免不全面，不准确。将不断更新。目前仅供参考，抛砖引玉。欢迎共同探讨。