加载中…
个人资料
小龙
小龙
  • 博客等级:
  • 博客积分:0
  • 博客访问:29,505
  • 关注人气:11
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
谁看过这篇博文
加载中…
正文 字体大小:

序言

(2018-07-04 21:27:53)
标签:

tap

智能制造

工艺编程

工艺模型

分类: 七天学会TAP编程

TAP(Technology Analyse Paltform)是笔者专为工艺人员开发的一款编程工具.利用它的支持,工艺人员只需花极少的时间, 学习一点最基本的编程知识, 即可摆脱对专业程序员的依赖,独立完成复杂工艺模型的开发和调试.

TAP诞生于一家专业的工业炉公司. 与制造业众多的细分领域相似,工业炉也是一个有着悠久历史,且高度专业化的行业, TAP的开发灵感缘于一个并不成功的软件项目.

该项目由多个优秀的工艺专家规划, 目标是综合考虑计划,工艺,设备,环境及能耗等多种因素, 通过开发一系列在线诊断和优化模型, 构建一个结构完整, 功能齐备的大型加热炉优化系统. 因为所有模型都以软件方式实现, 作为程序员的笔者也得以进入团队,全程参与了项目研发.

虽然项目本身立意新颖, 但在软件开发上依旧沿用了传统模式 -- 工艺人员提供算法,专业程序员负责编程。这是一种在应用软件开发中得到广泛应用的模式, 其成功有赖于两个基本前提:

1.需求方的业务模型足够成熟稳定,所有细节都能被清晰的定义出来.

2.软件开发者具有必要的行业知识,和甲方的业务交流足够顺畅.

不幸的是,该项目在两这方面都出了问题.

由于大型加热炉本身结构复杂,工况多变, 其工艺优化算法也有一定的不确定性, 很难一次性定义出所有的算法细节,所以更合理的开发方式应该是渐进式的--先建立起基本框架, 然后对模型进行长时间的持续改进,直至最终得到一组适用的模型. 但这种做法存在一个致命问题: 绝大多数工艺人员不懂编程, 算法的改进高度依赖专业程序员的配合, 而国内生产企业和工程公司中都没有配置软件工程师, 只能在立项后找软件公司合作, 所以模型也只能随着项目一次性完成, 无法进行持续优化. 雪上加霜的是,由于大型加热炉工艺中包含热工,机械,电子,仪表等多个专业, 所需背景知识涉及流体力学,传热学,材料力学,控制论和数值计算等多个学科, 没有程序员能同时具备如此多的专业知识, 更遑论去理解工艺模型的细节, 所以除非工艺人员能一次性定义出所有细节,否则就无法编程,这也让渐进式开发变得既艰难, 又低效.

上述缺陷很快就对项目实施产生了严重影响. 为解决这一问题,曾自学过一些软件编程的工艺人员试图采用折中的方式: 由笔者开发系统框架, 工艺人员自己编写算法部分. 这个看似完美的方案, 却导致了更为致命的后果 由于要开发的并非一个小型计算软件,而是一个复杂的软件系统, 不同模型间无论数据还是计算逻辑都高度耦合, 其代码的复杂度大大超过了工艺人员的编程能力, 一旦在运行中出现问题, 很难判断是算法本身存在缺陷,还是编程出了差错,亦或两者兼而有之, 这使得粗通编程的工艺师对代码中的错误束手无措. 而笔者又不懂工艺,看不懂算法代码, 同样找不出错误所在, 这让整个项目的开发陷入了停滞,再加上其它一些因素的影响, 最终只能草草收场.

随着行业经历的日益丰富, 笔者发现类似情况并非个案,而是普遍存在于工艺模型的开发之中,这也导致了某种戏剧化的结果 在工业炉领域, 工艺模型的开发者大多并非工艺出身,而以控制专业居多. 由于模型的计算结果最终都要通过控制系统反馈给设备, 控制系统的开发者对工艺的实现细节有所了解, 而控制专业本身就要学习编程, 这也让他们似乎具备了开发模型所需的复合能力.只是控制人员对工艺的理解大多停留在设备层面, 这也注定了其开发的模型只能流于表面。而那些深谙工艺之道的行业专家因为没有编程能力, 很难将自己的工艺经验转化为有效的优化模型, 这无疑是巨大的损失.

更为重要的是, 随着自动化技术的日益普及和智能制造的兴起, 工艺模型的开发正在被赋予全新意义.由于大多数模型算法建立在过程数据之上, 而这些数据中蕴含了极为丰富的工艺信息, 所以对模型的持续优化, 其本质就是对工艺数据进行提炼分析, 进而探索工艺内在规律的过程,这将导致一个非常关键的变化: 在现有的开发模式下, 一旦模型失效, 就意味着项目的失败, 而在新的情境中, 失效的模型却将成为进入工艺秘境的最佳路径, 通过对失效模型的程序代码进行深入解析, 可以发现更多深入而隐秘的工艺内涵, 它们既可能为现有的工艺经验提供更精细的数据支持,也可能对早已成为共识的工艺知识提出挑战,而更大的可能,则是将我们带入一个全新的工艺世界.

无论怎样, 模型开发都将为深入认识工艺过程提供全新的,或许也将是最为重要的途径,而所有这一切都建立在一个基本的前提之上: 工艺人员必须摆脱对专业程序员的依赖, 具备独立的编程能力. 虽然直到今天, 软件编程依旧被当做一个专业,而不是一种能力,但笔者坚信,要不了多久, 工艺编程就将逐步成为每个工艺师必备的基础能力。而这一即将到来的变化也带来了新的问题 究竟该使用什么的工具进行工艺编程呢?.

我们当然可以选择VC++, C#,Basic或者Java, 但这些通用工具并非为工艺编程设计, 要想将这些结构庞大,功能繁杂的工具用于工艺编程,需要掌握大量的编程知识和长期的编程训练, 其间的付出不亚于培养一个专业程序员, 对绝大多数每天埋头于工程图纸和现场问题的工艺人员来说, 显然是不现实的. 而上文所提项目的失败也证明,对绝大多数工艺人员来说,通用编程工具并不适合, 甚至可能是个非常糟糕的选择.

是否有这样的一个工具,它专门为工艺编程设计, 工艺人员只需经过少量的学习, 就能独立开发出自己的工艺模型呢?很遗憾,目前市场上还没有这样的产品. 但也正是受这一问题的启发,笔者产生了开发TAP的想法.

有趣的是, 自决定开发TAP直到推出1.0, 一直困扰笔者的, 与其说是软件技术本身,不如说是公司上下看待TAP 的方式. 对习惯了专业分工,各司其职的工艺人员来说, 软件编程似乎只是锦上添花的装饰, 有则更好,没有也无关大局, 即使是行业里最优秀的工艺专家, 也习惯于把软件看做是众多辅助专业中的一员 – “模型编程本来就是程序员分内之事,与工艺人员无关”. 类似的观念如此根深蒂固,以至于即使在TAP出生地”, 笔者也很难为其找到用武之地..

在自动化技术已广泛应用于生产实践, 大数据分析和人工智能正迅猛发展的今天,这样的困局值得我们思考. 对软件编程的轻视,究竟是行业的自身规律使然, 还是体现了传统制造业的某些内在缺陷? 如果是后者, 这些缺陷又是什么,它们如何形成, 又如何演变, 对行业发展产生了怎样的影响? 我们又该如何应对?

这些问题看似不着边际,却在无形中塑造着行业的今天和未来。在崇尚权威的传统制造业,任何对固有观念的质疑都注定命运多舛,这也让笔者意识到,开发TAP不仅仅是在做一款软件,更是对某些传承了数十年的观念提出挑战.这注定不是一次愉快的经历,但如果能把问题完整的呈现出来, 吸引一些人开始思考,并尝试着做出改变, 那么即使最终证明: TAP不过是为正确的问题提供了错误的答案, 笔者依旧有理由感到欣慰.

正是基于上述原因, 笔者决定用对话方式来写这篇编程指南. 这并非笔者的独创.早在两千年前,古希腊的先哲们就在用这种方式记录下他们的困惑与思考. 之所以东施效颦, 只是觉得对话更能展现TAP开发过程中所经历的迷茫,困惑与冲突。这是笔者一个人与一个行业的对话, 虽然这样的对话在现实中从未真正发生, 但在过去的四五年中, 却几乎每一天都在笔者的内心里进行.它既是灵感的源泉,也是某种前行的动力, 因为笔者相信, 对于那些真正的变革者来说,壮着胆子提出问题要比给出答案更加艰难,也更有意义.

此次对话将在TAP的开发者小龙和一位工艺师之间展开. 希望通过对话,不仅能向各位看官介绍TAP的编程细节, 也能展示出对话者之间观念的冲突. 如果由此能引申出更多现实中的交流, 即使是针尖对麦芒式的交锋,笔者也将不胜荣幸并乐见其成.

 

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有