0 引言
在当下企业的智能制造实践中普遍存在一种现象，就是无论投入多少人力物力，最终结果却只能体现为显示在多个大屏幕上的各种图表和炫酷工艺画面，却无法真正持续地优化生产，这样的”智能制造”只能用来应对项目验收和领导视察，而智能制造本身则成了一场项目秀，笔者把这种现象称为智能制造的”大屏化”。造成这一现象的原因很容易被归结为企业管理上的浮夸风，可技术层面的原因却往往被忽视了，很少有人注意到，当下大多数智能制造项目都是由IT和自控人员主导，作为智能制造真正的主体 -- 产线上的工艺人员 -- 却只能作为项目的辅助方，而IT和自控人员又不懂工艺，这种身份与能力上的错位直接导致了”大屏化”现象的泛滥，而造成工艺人员参与度过低的主要原因在于其计算机编程能力的普遍缺失。
智能制造的应用范围虽涉及企业内部几乎所有部门，但其最核心也是难度最大的应用场景在于基于产线数据的工艺分析与优化，其过程与结果都要以计算机软件的方式呈现。随着智能制造时代的到来，原本只起到辅助作用的工艺分析与优化模型(以下简称工艺模型,其内容包含但不仅限于现有的二级模型)正逐步成为智能制造的核心内容, 而工艺人员是否具备相应的编程能力,进而摆脱对专业程序员的依赖并主导工艺模型的开发，则是决定智能制造能否真正落地的关键。工艺模型的开发具有专业性, 定制化和持续性等基本特征，正是这些基本特征决定了现有开发模式无法适应智能制造时代的需要,下面对此做一简要分析。
1专业性
与商业互联网相比，智能制造在应用方面最大的特点就是其远为强烈的专业性，一条产线上的工艺过程大多涉及多个不同专业，只有经过系统的专业训练和长期的生产实践才可能真正掌握相关知识与技能, 才可以对工艺过程进行持续有效的分析优化,而当下智能制造建设主要由IT公司和从事控制系统开发的公司主导,前者大多由商业互联网转型而来，其优势在于数据平台的搭建与运营，基本不具备专业化的工艺分析与优化能力, 后者则大多在工业领域深耕多年,相较于IT公司拥有更多的工业基因，所以普遍相信自己既懂工艺又懂IT，是真正能主导智能制造的力量，不过在笔者看来这只是一种错觉。与专业工艺人员相比, 绝大多数控制系统开发人员既没受过与工艺相关的专业训练, 更缺少工艺计算和生产管理经验，其对工艺的理解非常表面化，不可能对产线数据进行深入分析, 自然无法成为智能制造应用开发的主体。上述两类公司虽然在智能制造概念的推广和数据平台建设上贡献颇大，却无法取代工艺人员而主导智能制造的应用开发, 只有将工艺模型开发的主导权真正交还到工艺人员手中，让更多工艺人员全面深入参与到智能制造的应用开发当中,智能制造才可能摆脱目前热度虽高却难以在应用层面真正落地的窘境, 真正发挥出其在工业智能方面的巨大潜力, 而这一构想的实现有赖于工艺人员软件编程能力的构建。
2 定制化
工艺模型具有很强的”场景属性”，即使是同一类设备按相同设计构成的相似产线间，其工艺细节也往往存在一些重要差别, 很难实现模型软件的产品化，更适合项目定制的开发方式，而这也大大降低了模型开发的利润率，如果再考虑到工业领域中工艺模型的复杂性和极其丰富的多样性, 以通用软件开发为主的大型公司恐怕很难在其间找到足够规模的赢利点, 而那些希望在智能制造应用开发领域获取超额利润的想法其实并不现实, 这也决定了智能制造应用开发将更多依赖中小型专业公司和生产企业自身，并将以项目化定制为主要开发模式。
3 持续性
大多数工艺模型的开发都是一个不断试错的过程, 很难一蹴而就, 随着工业企业经营环境的日益复杂, 需求端的变化正变得愈加频繁和难以预测，这也导致产线工况和设备状态的稳定性有所下降, 并让之前开发的工艺模型的适用性随之降低甚至完全失效。在未来可以预测的时间内，这种源自市场端的不稳定性很可能会成为常态，而工艺模型的开发必须与这种不稳定性相适应，需要改变过去那种一次开发长期使用的模式，并建立一种可持续的优化机制。
理解了工艺模型的3个基本特性，对于当下模型开发中主流的”编程外包”模式的弊端就不难有一个清晰认识。所谓编程外包是指工艺人员设计算法并交由专业程序员编程的开发模式，过去十数年中该模式一直是工艺模型开发的基本方式, 其最大弊端在于无法让工艺人员真正成为工艺模型开发的主体, 同时也无法让工艺模型具备适应市场变化所需要的持续优化能力。
绝大多数工艺人员不懂编程，只能将算法细节写成软件需求书提交给程序员。由于工艺算法的高度专业性, 其细节远非程序员所能理解,这让双方的沟通变得极其低效。一旦模型运行出现问题, 程序员看不懂算法而工艺人员又看不懂代码，有时很难判断究竟是算法本身失效还是程序中存在bug, 这也极大降低了模型纠错的效率。由于只能依赖专业程序员编程, 而工艺模型中又往往包含一些独特的，甚至是专利级别的算法细节, 工艺人员大多不愿将其透露给他人，这也极大降低了工艺人员开发模型的主动性。
从执行角度来说，编程外包大多以项目方式操作, 即使是简单模型的开发也需要经过立项，招标，执行和验收等一系列复杂流程, 流程走完少则数月多则一两年, 项目质保期过后即使只是对模型进行简单修改也需要重新走一遍流程，开发效率之低下其实不难想象。如果再考虑到大多数外包项目都由小公司执行, 其人员变动乃至公司本身的存续都会给项目带来风险, 这样的开发模式显然无法支持模型的渐进式开发和持续优化, 其弊端在工艺模型只起到生产辅助作用时尚不明显，一旦智能制造开始普及，工艺模型被提升到智能制造核心应用的地位后，编程外包方式的弊端就会愈发明显，甚至会成为阻碍智能制造落地最大的技术性障碍。
要解决这一难题，方法在于为工艺人员开发专用的工艺模型编程平台(以下简称TAP)，让他们可以自主进行工艺模型的设计与编程，彻底摆脱对专业程序员的依赖。只有这样，才能让工艺人员主导智能制造的应用开发，从根本上上改变智能制造热度虽高却在应用端无法落地的窘境, 让智能制造真正成为推动产业升级和制造业转型的利器。从这个角度来说，TAP虽然只是一个编程工具, 与智能制造那些大型数据平台和复杂的数学算法相比似乎微不足道，可其作用却非同一般，对那些苦于无法进入智能制造世界的工艺人员来说TAP就像一把钥匙, 有了它，智能制造世界的大门才能真正为他们打开。
那么TAP应该是一个怎样的系统，应该具备哪些功能，又该如何实现这些功能呢？笔者以为做为一个被工艺人员使用的编程平台, TAP应该具备如下基本特点：1）支持车间一级的工艺模型开发与调试；2）模型开发过程中所需的现场数据读取，程序框架搭建，工艺算法编码与调试，工艺画面制作与显示内容控制等工作都可以在TAP下完成；3）可大大减少模型编程所需的计算机知识, 即使没有编程经验的工艺人员, 经过少量训练后也能独立从事模型的编程工作；4）同时支持模型在线运行和离线开发与调试, 工艺人员可在自己的电脑上随时随地编写与调试模型, 或者利用既有模型对工艺数据进行离线分析, 调试好的模型则可以方便的部署到现场在线运行；5）支持模型从其它数据平台获取所需数据并在TAP下建模对其进行分析与计算；6）考虑到很多工艺模型中都会包含一些标准的数学计算，TAP应能支持在模型代码中直接使用诸如Mathlab和Python等第三方软件的计算功能，既可以在模型代码中方便地为计算所需参数赋值，也可以将计算结果直接在模型代码中使用；7）考虑到一些具备基本编程能力的工艺人员希望用诸如VC++一类通用编程工具开发自己的计算模块, TAP应提供针对这些外部计算模块的整合能力, 工艺人员在自己开发核心算法模块的同时，又可利用TAP定制数据通讯和工艺画面,并在TAP下开发其它非核心算法, 并将所有部分方便的整合到同一个模型中, 让工艺模型开发变得更加灵活。
考虑到工业领域尚没有类似TAP的系统，为此，笔者依托上述需求自己开发了一个TAP的原型系统,并初步具备了TAP所需基本能力, 验证了工艺人员专用编程平台在技术上的可行性, 下面对其主要功能做一简单介绍。
1）基于C语言的脚本编程。TAP下编程采用基于 C 语言的脚本,这是 C 语言的一个子集,工艺人员只需学习<变量定义与赋值>,<自定义函数>，<函数调用>及<逻辑分支语句>这四个最基本的 C 语言要素,即可在 TAP 下进行模型开发, 没有编程经验的工艺人员，经两周左右培训即可初步具备 TAP 下的开发能力。如果有一定编程经验，不超过一周的学习即可开始在 TAP 下进行模型开发,利用TAP进行工艺编程的难度已经被大大降低。
2）数据通讯的快速定制。工业现场的数据源种类较多,通讯协议也是五花八门,其编程需要丰富的计算机知识和编程经验,绝大部分工艺人员不具备这样的能力,所以数据通讯多委托专业计算机公司开发。为解决这一问题,TAP 定义了一个车间级的通讯结构(如图1所示), 将多种通讯协议的结构抽象为3种基本模式, 为每种模式提供了统一的编程界面,工艺人员无须了解通讯协议的细节，只需定义数据格式，配置好由 TAP 提供的协议驱动模块,再按照 TAP 规范编写简单的几行脚本, 即可实现与不同数据源的数据交换。利用 TAP 的支持,几乎所有工艺人员都可快速开发出稳定高效的通讯程序, 实现多个数据源与工艺模型的快速集成,让工艺人员也具备了开发复杂数据通讯程序的能力, 极大降低了模型编程难度，提高了开发效率。
图1 TAP通讯结构
3）实现了产线过程数据的集中存储和离线仿真,极大简化了模型的数据管理和代码调试。在传统开发模式下，工艺数据的存储和使用须开发者自己编程实现, 要耗费大量精力,而 TAP 中由 ProcDB(过程数据库)自动管理数据, 无须开发者深度参与, ProcDB 提供的离线仿真功能,可让开发者快速定制模型调试所需的数据流,大大方便了模型的离线调试。
4）工艺模型(在线,离线)编程,调试及运行。TAP 本身并未实现任何具体的工艺算法,而是将工艺模型在结构上的共性提炼和抽象为一组概念模型, 以此为基础实现了一个通用的工艺模型框架和一系列运行支持, 通过将模型中实现框架结构所需的部分独立出来，TAP 允许工艺人员只使用最少量的 C 语言基础知识即可开发出复杂的工艺模型,同时 TAP 支持对模型进行源代码级调试, 并通过过程数据库支持模型的离线调试, 大大提高了模型的调试效率。
TAP 下开发的工艺模型可选择两种运行方式：在线运行和离线运行。无论采用哪种运行方式,工艺模型本身都无需进行任何修改,只需在 TAP 运行工具中选择不同的运行方式并连接不同的数据源(数据岛或者过程数据库)即可。唯一的差别在于: 离线运行方式支持对模型进行源代码级调试,而在线运行没有此功能。同时离线运行方式也可以用来开发针对工艺数据的离线分析模型。
5）实现了基于数据驱动和事件机制的工艺模型整体框架, 让工艺人员专注于核心算法的实现, 大大减少了工作量和编程所需的计算机知识。用传统方式开发工艺模型, 核心工艺算法的编程一般只占整体工作量的15%-30%，大量的工作消耗在软件框架搭建，数据管理，用户交互等功能的开发上,而编写这些功能所需的计算机知识, 要远远多于核心工艺算法的编程。也恰恰是这些知识和经验壁垒构成了工艺人员自主开发工艺模型的最大障碍,为此,TAP实现了一个基于数据驱动和事件机制的通用的工艺模型框架，利用该框架, 工艺人员可快速搭建出所需的软件架构，定制数据管理及用户交互方式,所有这些工作都只需写很少量的脚本代码,甚至不需要写任何程序，这不仅极大降低了对计算机知识的要求,让工艺人员具备了独立开发工艺模型的编程能力，同时也成倍减少了模型开发的工作量, 让工艺人员聚焦于核心工艺算法的开发与改进, 大大提高了开发效率。
6）支持将 MathLab 等外部计算软件开发的计算模块快速嵌入到模型代码中, 大大降低了工艺模型中数值计算部分的编写难度和工作量。很多工艺算法中都包含一些复杂却标准的数值计算,如插值算法，偏微分方程求解和快速傅里叶变换等,如果自己编写这些算法程序会大大增加模型开发和调试难度, 利用 MathLab和Python 等专业计算软件提供的计算能力显然是更好的选择，为此TAP 实现了一个支持框架, 可在工艺模型代码中直接调用外部计算软件中开发的计算模块，并用代码中的变量为参数赋值及存储计算结果,进而大大降低了复杂算法的编程难度和工作量。
7）对基于 Python 的 AI 算法提供了封装和调用机制, 工艺人员可轻松将 AI 功能集成到自己的工艺模型中。TAP 为 AI 应用提供了两方面的支持, 一是利用工业现场数据结合工艺模型生成 AI 算法训练所需的数据集, 二是支持对 AI 算法的 TAP 封装, 可在模型中直接调用这些算法, 并在代码中为 AI 算法的参数赋值和读取计算结果。
8）图形与代码相混合的编程界面可大大简化对 MathLab 和Python 等外部计算软件的调用编程。TAP 使用了一种图形与代码相混合的编程界面, 工艺人员可将在 MathLab 和Python 等外部计算软件中编制的计算模块封装成 TAP 下的”逻辑芯片”, 再以图形化方式嵌入到 TAP 的模型代码中, 并以鼠标拖拽方式用代码中的变量为参数赋值, 操作简单直观, 大大简化了调用外部计算模块的编程工作。
9）支持工艺画面的自主绘制，用户输入的响应方式可由开发者自主定义, 大大简化了用户界面的开发。TAP 提供了类似组态软件的工艺画面绘制功能, 并支持将画面内容与模型脚本进行绑定,工艺人员可快速开发出复杂多变的工艺画面，在代码中控制画面的显示内容, 并让模型能响应用户输入。
10）支持多种编程模式, 为工艺模型的开发提供了极大的灵活性。TAP 支持三种开发模式: 全 TAP 模式, 独立编程模式和混合编程模式。工艺人员既可以用 TAP 开发全部模型, 也可以只用 TAP 定制数据通讯, 程序框架和工艺画面, 再依据 TAP 规范用诸如 VC++或 C#一类通用编程工具编写算法模块并嵌入到 TAP 中运行, 这样做既为复杂算法的开发提供了便利, 也可以利用 TAP大大减少模型整体开发的难度和工作量。对于包含多个模型的中大型应用项目, 也可以采用混合编程模式, 既用 TAP 开发相对简单的模型, 用通用编程工具开发复杂算法模块, 再将这些模型按TAP定义的接口方式整合为一个依托 TAP 运行的完整应用项目。
4 TAP开发范例—大型加热炉综合诊断系统
大型加热炉是钢铁企业中得到广泛应用的大型炉窑, 其结构及工艺都比较复杂。综合诊断系统的开发，是希望能关联整个生产流程实时信息, 搭建涵盖热工工艺、状态监测和设备管理的诊断系统平台，为今后的持续优化和技术升级提供服务。
该系统包含多个工艺模型, 原本以外包方式由笔者用VC++实现，之后笔者将其中部分模型移植到了TAP下, 验证了TAP开发复杂工艺模型的可行性, 具体内容如下：1）在线优化模型。物料跟踪、板坯温度跟踪、板坯在炉时间预测、脉冲式烧嘴长短火焰优化、动态热平衡计算。2）离线分析模型。板坯升温曲线分析、动态热平衡统计分析、阀门状态统计分析。相关的脚本调试界面和工艺画面示例如图2和图3所示，其中的工艺画面也在TAP下制作完成。
图2 TAP模型代码调试界面
图3 TAP制作的工艺画面
5结论：
工艺模型编程能力的构建是智能制造中一个极其关键，却被普遍忽视了的问题，这直接导致了实际具备工艺和生产管理知识的专业人员无法真正主导工艺模型的开发, 而这也是智能制造虽然叫好却很难真正落地的重要原因之一，需要给与技术上的解决。TAP原型系统的开发证明了一个工艺模型专用编程平台在技术上是可行的，希望由此能给更多相关技术人员以启示，为最终解决工艺人员自主编程问题提供一个有益的起点和参考.
