工业互联网仅是一种实现智能制造的工具或方法,本身不属于一个具体的产业。然后又有来自IT的朋友希望能够了解制造业运行的问题,难题,希望有些全局性的认知,这个的确太大的话题,我来试着分析一下,胆子似乎越来越大了。
一、基础问题—先不谈技术路线
其实,对于智能制造、工业互联网、大数据、人工智能这些话题而言,如果不解决基础问题,其实,后面的技术问题也会是一团糟,因为在一个需要结构性思维、跨界协作的年代,作为规划者与执行者,每个参与其中的人、企业必须先得在基础性问题上获得共识,才能相互协作,构成所谓的“生态系统”。
生态系统是NNMI所要共建的,而对于IT与OT融合,本身IT思维就在生态系统的构建,那么就必须解决生态系统中的个体的人与个体企业之间的“语义”一致性与规范问题,这些问题不解决后面的技术就无法真正融合。
1.人才问题
人才问题的难题首先在于教育与产业间的培育矛盾,大学教育按照垂直的专业划分的,而企业的用人却需要横向的跨界人才,这就是如图1所谓的“T”型人才。
图1-T型人才是广度与深度的集成
尤其是在智能制造的年代,我们需要的人才是跨越多个学科、领域的人才,如图2为奥地利工业4.0研究院对于人才培养的需求分析,显然,不可能存在一些人他们能够在所涉及的每个领域都是专业人士,但是掌握系统与接口、具有系统理念与创新管理方法与技能、集成产品与流程规划设计这方面能力的人才,通常需要的是具有“结构性思维”、“系统思维”的人才,或者掌握基本的接口与方法,可以规划整体架构并协调内部外部团队进行协作的人才也极其重要。
图2-工业4.0时代的知识结构需求
没有这样的人才,对于一个企业而言,就会出现无法统一对接,买来一大堆软件、产品却无法协同,推进产线智能化的过程会出现重复工作、返工、变更,甚至整体推倒重来的风险。
重视人才,在很多时候都是“叶公好龙”式的—口头上重视人才,而实际上却并非如此,重视人才不是去哪里挖人,而是注重发挥人的知识和经验,培养人的主动性与创造性。
2.创新思维与文化
智能制造必须基于“创新”的设计,正向设计思想来实施,如果只是想“Copy”的话,这个复杂度就远大于传统的机器与产线测绘的问题,因为,它牵扯的专业太多,任何一个环节的不了解和偏差导致全局的无效或损耗,反倒不能起到真正的效率。
图3-创新思维与文化
关于在推进智能制造、工业互联网的过程中,发现非自动化业界的人往往会谈到现场的很多问题,比如资产信息的输入编码问题、行业信息差异如何集成,数据如何预处理,实时性如何保证,就发现这些问题事实上OPC UA TSN已经在寻求解决并对大部分问题予以了设计,隔行如隔山说的是跨界,但即使在行业内部,实际上对OPC UA TSN的理解大部分人都是知之甚少。
同样道理,很多时候,大家都认为创新很难,不过,在更多的时候我们发现其实,不懂得使用创新的工具和方法的人更多,就像MATLAB/Simulink和PLC之间完全可以建模仿真直接代码自动生成,但是,很多人并不知道这一点,包括数字孪生可以降低验证的成本,缩短研发周期,其实,很多人不了解。
在过去的数百年里,各个公司已经为如何创新提供了非常多的方法、工具、软件,一切的行为都是让“创新”这件事情变得简单。
对于制造业而言,创新就是在寻找设计到经济制造的最优路径的过程,因此,创新是有实际意义的,而并非是创新就会投资很大,花费周期很长,而且易于被抄袭,那么你就忘记了创新同样目的是解决(1).缩短产品研发周期,(2).降低成本,(3).保护知识产权,如果我们非要把创新和赚钱对立起来,那么我们也就无法理解创新的精髓和实施的路径,当然了,创新的方法、工具的学习是首要的,因为,的确在很多时候,首先往往来自于“不知道”,当你知道后,你会惊叹“原来还有这样的方法啊!”。
3.组织架构支撑问题
对于需要分布式架构的计算而言,企业的组织架构也必须是分布式的,扁平化,而非传统的垂直管道管理,否则,构建了分布式的技术架构,却受到了垂直架构的管理制约,无法发挥其效用,构成不同的瓶颈和信息延迟,甚至会产生由于利益(业绩考评)而带来的人为障碍。
图4-分布式组织架构
这个是往往被忽视,也比较难办的,在很多时候,人们对于智能制造的理解总是聚焦于技术,而并不考虑组织架构对推进智能制造的影响。
事实上,ERP这些软件本身的设计就是在于降低组织中的信息传递所消耗的时间,包括信息的完整与准确,降低重复的信息检索消耗的时间,信息在多个部门间传递的时间消耗,传递中的偏差,而对于协同制造而言,同样如此。
分布式智能其实对于每个个体的节点计算能力要求较高,而基于分布式的架构的组织对于个体同样能力要求更高,因此,在推进智能制造中,组织的架构设计与能力升级同样重要,架构不合理会造成内部的信息传递中出现滞后(例如审批环节会造成积压),包括篡改、伪造等潜在的风险以规避对自身的责任、考评的不利影响。
4.精益的基础问题
这件事情毋庸置疑非常关键,因为,基于量化和生产制程模型才是生产的本质与核心,而精益设定了量化指标以及采集数据和流程的依据,这需要良好的精益基础支撑,否则,就无法知道目标的设定。
精益不是一种工具方法那么简单,而是一种追求持续改善的文化,很多公司也在推进精益,但如果把精益理解为一种流程、考评指标的方法,那么就会出现各种应付差事的行为,那么就失去了本身的意义。
精益本身提供了制造业所解决的核心问题即质量、成本与交付问题所展开的系列持续改善活动,包括思想、原则、方法与工具的整体设计,无论智能制造如何变化,同样是必须围绕这些问题来展开,因为这是生产制造组织中的核心问题,自动化,信息化,智能化都是要围绕解决质量、成本与交付问题而产生,最大的区别在于标准化与大规模定制对于这三个问题的挑战变得更为苛刻。
因此,对于精益的实施和基础的稳定才能让整个智能制造建立在有效的基础上,对此制造业的专家们已经达成共识。
因此,人才、创新思维、组织与精益构成了我们推进智能制造的基础问题,必须在此基础讨论才能有序推进。
二、产业中的基础难题
工业场景中存在很多与IT场景不同的问题,即使在工业场景内部由于垂直行业的差异带来巨大的差异,总体而言,工业有一些共性特征使得必须予以很好的解决,否则,就无法突破进而规划的更为合理。
1.确定性的数据传输
控制基于等时同步思想,确定性传输信号,确定性控制任务周期。这是与IT比较大差异的地方。
目前的各个实时以太网技术都已经有了近20年的运行,更远的传统现场总线也仍然在工厂早期大量部署,这些问题使得IT对OT的访问造成了壁垒,尽管总线的种类就物理上并不多,但基于此的协议却有非常多种类型,即使对于同一总线介质而产生的协议也不尽相同。
这使得IT对OT访问的经济性产生了障碍,因为需要编写不同的访问驱动,而由于不开放的工艺Know-How保密需求也使得很多数据无法被真正的访问,但如果不能访问1个关键参数则对整个模型产生了不完整,则对数据的后续处理、优化产生了巨大的障碍。
2.复杂约束条件下的制造经济性
材料特性与成本、机械、控制、软件、作业规范、加工对象的标准化、人工经验等都是影响经济性的因素,而且具有非常大的刚性,组合非常多,筛选路径需要高成本验证。批量小,验证难度大。
制造业的过程就是不断的在寻找最优的路径,在生产的每个工序中,材料、加工步序、时间、成本等都在变化,例如:A材料效果非常适合于粘结却成本高昂,另一种低廉的成本需要消耗较多的加工时间或人工,或者加工过程中机器会出现较大的磨损,不同的材料、工序造成机器的时间消耗不同,这些都是需要不断优化的,这些都归根结底与产品的品质、成本与交付能力相关,我们可以想象,在制造过程中,这些约束条件构成的组合是成千上万,甚至数以亿计的,这跟制药中筛选最佳的配方是一个道理,这个成分用于治疗胃病却会造成肾脏的损伤,种种原因,任何制造的过程都是不断的寻找最经济的道路的过程,创新就发生在这个寻找最经济道路的过程中。因此,你必须意识到,创新是竞争力的主推器,它看上去很难却是不断增强你的能力的关键。
3.基于建模目前存在标准与接口的问题:控制、机械、安全、材料、工艺等建模各自为政,平台差异,无法实现统一的协同仿真。
创新往往基于原创性设计,遵循第一性原理,那么就会回归到物理与材料,目前的各种建模仿真软件间就缺乏统一的协同仿真接口,尽管FMU/FMI正在开发,其目前也主要在已经非常成熟的汽车工业应用领域开始。
如图8可以将机械的数据与控制的算法通过FMI接口实现对接,机械的调整与控制算法可以实现交互,在产线中实现变化中的虚拟仿真,进而验证与设备虚拟调试。它能带来的好处非常多,但是,却很少有制造业的工程师掌握这些工具与方法,而又大喊创新之难。
4.小数据应用场景
如果是控制可以微秒采样,但如果是管理运营不需要低周期,但数据量不大,如故障信号多,但如果故障信号多意味着设备质量不过关本身就没有市场。
与离散制造业相比,流程工业本身基于连续的生产,因此在传统上产生了很多已有的学习模型,就像自适应控制、卡尔曼滤波、模糊控制算法很多实际上已经有较为成熟的参数与模型学习的方法。
(1)卡尔曼滤波器
R.E.Kalman等人发明的卡尔曼滤波器是用于估计或学习系统状态的数学框架,估计器会给出位置和速度在统计上的最佳估计。卡尔曼滤波器也可以用于识别系统参数,因此,卡尔曼滤波器就位识别状态与参数提供了数学框架。
该领域也称为系统辨识(或系统识别)。系统辨识是识别任意系统的参数和结构的过程。
卡尔曼滤波器可以从贝叶斯定理推导出,在贝叶斯解释中,定理引入了证据对信念的影响。改定理提供了一个严格的数学框架,用于纳入任何具有一定程度上不确定性的数据,简单来说,给定目前所有的证据(或数据),贝叶斯定理可以让你确定新证据如何影响信念,对于状态估计,就是对状态估计准确性的信念。
(2)自适应控制
控制系统需要以一种可预测可重复的方式对环境做出反应,控制系统对环境进行测量并且通过改变测量值来实现控制过程。通常控制系统以全部的参数都硬编码到软件的方式进行设计和实现,这种方式在大多数情况下效果良好,特别是当系统在设计过程中已知时,当系统定义不明确或预期在运行期间会发生显著变化时,实施学习控制就变得非常必要。
图10-采用神经网络学习的自适应控制系统(飞行控制)
5.高端应用简单,低端应用复杂
汽车行业整体规范标准,虽然复杂产品但易于实现先进制造。而其它行业缺乏原材料、整体产品的规范性,流程的复杂和约束反倒需要更大的学习模型,却受限于数据量、成本约束没有办法进行模型学习。
对于深度学习而言,在很多场景,如波士顿大狗、AlphaGo等已经有了成熟的应用,人们寄望于同样的技术能够为工业场景提供应用,但就深度学习对工业而言,存在很多难点:
(1).解释性工具的缺失
现在的各种深度学习模型,往往需要通过多层神经网络,使用方法类似于一个黑匣子,这给模型的解释与拍错带来巨大的挑战,我们在进行机器学习的应用场景中,取得优秀的精度往往只是众多任务中的一个,应用中另外一个重要的是任务是分析预测失败的结果,从中吸取教训对模型进行拍错,并进行优化提高。
由于深度学习的模型复杂,我们已经无法通过人工方式得知为什么对一些特定的模型预测会出现失误,这样的问题让我们在实际中往往束手无策,这就好比深度学习在靶场上能够取得优异的成绩,但不能上战场。
为什么深度学习从业人员没有开发相应的评判,解释工具?这就要从开发人员面对的囚徒困境说起,对于统计中经典的决策树、线性模型,往往需要专业人员数十年的努力,才能得到比较完备的预测、评判、拍错体系,这个过程往往比较痛苦,得到的注意力较少,而现今的领军人物都开始进入工业界捞名捞利,几乎没有人会选择更难走的道路进行工具开发。
(2).应用场景限制
深度学习目前最为火热的是在图像、计算机语言领域,这些领域往往有大量的数据,而且变量维度非常高,观测之间、变量之间往往具有强相关性。而对于工业场景而言,其数据量较小、数据维度较低,深度学习的成绩往往就不那么显著了。
数据量小的时候,稀疏的数据量不足以支撑复杂神经网络的训练,而经典统计和机器学习模型可能已经取得了优异的成绩,而且不会过度拟合。当维度较低的时候,从业人员往往进行人工单变量观察,进行多种变量组合,以得到优秀的成绩,因此不需要依赖深度机器学习。
(3).模型训练成本限制
由于采用GPU集群、FPGA等硬件对深度学习进行加速,这些成本高昂的方法也使得一般从业人员难以承受,对人才的培养也造成了壁垒,对于需要部署大量GPU集群的应用而言,工业领域的成本投入产出评估就是问题。
6.行业属性太强
共性易于解决但不解决个性整体就没有意义,解决核心工艺解决相当于解决90%的问题,其它数据呈现、传输、 *** 作都是小问题,可以用公共技术资。每个不同的行业会有不同的行业Know-How,IT与OT的区别就是一个共性的工作,一个个性的工作在自己的领域,IT希望采用通用的平台架构来适应变化的市场,通过大规模的普遍使用降低整体拥有成本,而OT通过技术壁垒提升竞争力,这看上去是矛盾的,但是,并非不能解决,抽取共性技术,这是需要两方的技术人员在一起协同的,但沟通的语言和方法一直处于障碍阶段,IT似乎总认为你只要有数据我就能分析,而OT的问题在于,你到底想要什么数据?为了这个问题双方纠缠了许多年,就是所谓的两化融合之所以难的原因。
不同的行业不同的特征,这是工业互联网的平台遇到的难题,而每个垂直的行业又有着自己的技术保密性需求,因此,对于如何推进,这些垂直的壁垒构成了巨大的障碍。
三、技术实现要点的分析
对于推进智能制造其实有些关键要点需要突破,有些看上去那么基础缺似乎也被忽视-如OPC UA,有些存在很多问题却似乎风头很盛像机器学习。
1.OPC UA的背后是模型
这个问题目前大家的共识已经很清楚了,OPC UA TSN被列为未来主要的技术路线,对于OPC UA的理解目前大部分仅停留在这是一项技术,而它是一项规范,而这个规范背后实质上又是基于对制造流程的反映,它所构建的架构是匹配最优的技术路线的,包括管理壳的传输,其中包含资产、能源、维护问题,因此,不要仅停留于它的技术特性来看待OPC UA,它是为了解决连接中的各种问题而定义的,包括传输机制、安全、信息筛选、预处理、降低流量消耗(Pub/Sub机制)、解决资产端的信息交互问题,OPC UA的背后是对所有产业共性问题的应对策略包—它的每一种设计、集成都是为了解决产业中存在的现有问题。
2.数字化设计的背后是创新
数字化设计必须基于创新思想,基于原创性的开发,才能让一个企业真正的复用知识和经验,并且具备应对变化的能力,而数字化设计仅是工具,而其背后的逻辑是“正向设计”,智能制造是形成“应对变化”的竞争力,这导致了“变化”不能被“固定”的方式复制—形成了企业新的竞争壁垒,这不难理解吧?以前人家做一个,你拷贝一个,现在,人家变成做的每个都不一样,而这个拷贝的过程就没法进行,因为对小批量进行抄袭的经济性不够。第二个问题是“知识和经验”难以拷贝,就像现在的喜马拉雅、樊登读书会一样,你听知识和你自己去阅读一遍完全是不同的,知识和经验只有你自己亲身体验才能真正掌握,它不像抄袭一个机械的几何设计那么容易复制。
图11-基于数字孪生的柔性产线设计
数字孪生在设计阶段可以用于产线规划的验证,而在运营维护阶段同样能够对正在运行的产线进行监测,并对数据进行学习,优化。从图X可以看到对于流程工业同样如此,通过数字交互,可以让生产中的设备提供不仅是维护,也包括最优的参数和动态的模型构建。
3.边缘计算/云计算
边缘计算主要基于实现生产中的“策略”如调度、优化,边缘计算涵盖了数据的连接、存储、应用(工业APP)的开发,运行环境(也同样需要类似PLC的RunTIme)、开发工具(可借助于开放的通用工具如Python),传统的DCS/SCADA包括了其中很多功能,因此,传统OT厂商借助于自身的架构也可以推进边缘计算功能,在原有平台上开发相应的功能,对于IT厂商,其本身有较强的IT工具、容器技术,所需的是对运营场景中的分析、优化算法进行集成,但测试验证是IT厂商比较难的,因为OT厂商在这方面具有非常强的优势,因此,IT与OT的合作,分别在连接开放性、开发工具集成以及垂直行业Know-How方面的合作,这样才能构建融合的生态系统,但是,这个生态系统不能是IT与OT的简单融合,而是包括了End User、OEM、自动化、AI、数字化设计软件等系列厂商的共同融合,因此,协同的复杂性是当前的主要问题。
边缘计算解决协同中的策略与规划问题
边缘计算亦或云计算,本身划分时候是以时间粒度为主的,而实现方法可以有通用的,但是,最主要还是围绕解决问题,降低企业运营成本。
IT的开放性、架构性是优势,而OT的应用紧密性,对稳定可靠的保障是基础。由于IT在广泛的消费与商用市场所积累的低成本存储、计算资源,包括开源社区所拥有的应用如机器学习算法、图像处理算法、语音等都可以被工业场景使用。
4.机器学
人工智能为未来智能化提供了无限遐想空间
就目前而言,机器学习对于工业场景仍然是有较大的潜力的,但是,因何在文初即提出关于“创新”的问题,提出“数字化”设计的问题就在于学习必须基于模型,而我们在基础建模方面,包括机器制造商,产线设计厂商,都缺乏原创性设计,使得学习缺乏基础模型,对于监督式学习,仍然需要采用人工的标定,并且需要真实的物理机器进行测试,那就无法发挥真正机器学习的作用。
图13-机器学习基本的过程
那么在较好的情况下,我们认为机器学习也还是可以为很多应用提供场景,如产品缺陷的视觉检测、工艺参数的最优化都可以借助于机器学习(监督式),这取决于预测函数—是监督式机器学习的核心,理想的预测函数能够按照需求,将因变量映射到自变量空间。
什么是机器学习模型适用场景?
1.低成本模型:软件尽量用现成的,且对硬件要求较低。
2.模型易于解释:在实际应用中,我们往往需要对模型产生的结果进行解释和拍错,如果模型过于复杂,难以排错,势必影响应用。
3.模型易于修改:建立的机器学习模型往往需要对未发生的事情进行预测,这个时候需要将人的判断放入模型,这就要求机器学习应该很容易带入人工设置的参数。
如何评估监督式机器学习的效果?
1.统计量是否优秀,应用业绩是否优秀:均方差误差(Mean Square Erro,MSE),另外就是绝对误差中位数
2.衡量分类的统计量:分类任务中,实际标签和预测值进行分类,让其定义为阳性和阴性。
衡量指标为准确率=真阳性/真阳性+假阳性。
准确率刻画的是喊“狼来了”的孩子有多少次喊狼来了是正确的。
召回率=真阳性/真阳性+假阴性。
因此,对我们来说,智能制造整体来看,必须基于非常清晰的人才基础、创新思维与文化、精益运营管理的基础之上,然后再去一个个解决现实的垂直壁垒,不仅仅是自动化与信息化、智能化的融合,也包括业务上的上下游企业的关联合作,生态系统构需要技术的规范与标准作为“语言”沟通的基础,无论是OPC UA TSN通信还是FMU/FMI的建模仿真,亦或IEC61131/IEC61499的编程开发,包括管理壳这些标准与规范,以及安全,因此,生态系统的构建是在“标准与规范”,而标准与规范背后是流程与模型的一致性,是软件与知识,是人的智慧。
而在标准与规范之上,就是思想的开放,因为,人们总是执着于自我,IT与OT的融合中事实上有异议,相互之间并非是完全开放的,这些都是要解决的,因为融合的过程会有合作,但也会有潜在的利益冲突,这就需要更大的“和”—基于更高的智慧,全局的理解“竞争力”、理解合作,不偏执于自我和自己的领域—看上去下面就要谈到“佛”的般若境界了,的确,智能制造需要的不仅仅是技术,也包括思维的提升,包括对价值观、世界观的提升,扯太远了。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)