|
锁定老帖子 主题：产线管理系统，如何做架构？
精华帖 (0) :: 良好帖 (2) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-07-10
zhanghonglun 写道 halida 写道 我们企业用delphi+oracle做产线管理系统，作业方式就是给我们的产品（手机）贴条码，然后通过刷条码进系统来管控流程。有时候要调用外部程序，有时候要打印（传文档到LPT端口）。因为windows费用的问题，部分电脑采用linux+wine的方式来运行系统。
现在我们考虑重新开发系统，因为Delphi渐渐不支持了，以及因为效率的原因，要换到3层的架构。我们主管的想法是使用.net开发。我不知道.net的界面是否可以支持跨平台。 我个人因为兴趣原因，想用python+pyqt+django+salalchemy来开发系统，但是因为自己的实力不够，所以不好来推这样的架构，我的想法是客户端用pyqt，采用xmlrpc连接业务逻辑服务器，同时运行一个web服务器来显示查询页面（也可以整合到客户端中），DB端用sqlalchemy连到oracle。 请问各位觉得我的想法如何，有什么更好的实现方式（实在不想用.net开发，但是考虑到可维护性，不知道.net能够撑多久）？ 列一下需求： 3层架构 夸平台 能够运行本地程序，做一些交互 方便分布（产线电脑，有些是局域网，只能访问特定的服务器） 方便开发（个人建议能够接近Literate Programming，或者脚本式开发） 实时性好，产线作业员可等不了几秒。 我们的开发team为3人，我是主程序员，可以在架构上面说得上话。只要我能够开发出一个原型，并作出分析报告，采用我的架构应该没有问题。业务逻辑都是现成的，只要按照逻辑重新coding就好了。 我对架构的方面完全没有经验，请问应该如何去学习相关的知识呢？ 我不是专家，这玩意儿不就是传说中的SFCS 系统吗，或者MES，MES 的Scope 可能要大一点， 条码枪不是问题，就是个输入设备而已，焦点在框框里，一扫也就进去了，没那么玄乎，条码打印也很Easy, 就是向某个端口（如Com 或lpt口）写文件而已。如果要共享打印机的话，可能要在打印机的地方搞个服务。这里有个现实的问题，就是不同的标签要换标签纸的，这个可能要配合超级智能机器人才能完成了(可惜我们没有)。产线上不可缺少的还有个玩意儿就是称(Scale)，可能也是个输入设备。 实时性和可用性是个最需要考虑的问题，看你工厂的规模，单位时间内Transaction 的数量，如果采用3 层架构的话，对服务器配置的要求还是有点的，否则性能是个问题。工厂对实时性要求挺高的，IE 作产线规划时，标准工作步骤都定义得很清楚，系统上要按几次键盘，点几次鼠标都是规划好的，每一步需要的时间也是清楚定义的，时间就是产能。如果搞个系统，刷了条码半天没反应，刷个Error Code，要下一步再下一步，生产单位会杀了MIS 单位。如果想把GUI 改成网页，劝你三思而后行，我们海外的维修点使用的系统采用的是B/S 架构，不过那些维修点的工程师不过10 人吧。 提到效率问题，如果Server 比表差的话，两层架构的性能肯定高于三层架构。高并发时Server 甚至会死给你看 客户端的环境也要考虑，产线上的机器跟各位开发人员的机器配置是没法儿比的。 我们两个生产工厂每月产能都上百万的，用的10 年前使用Delphi 写的系统，跑得非常好，只是维护起来有点困难了。维修厂每月产能不到10 万，我们先尝试使用java 改造维修维修厂的系统，现在效果并不理想。恩，3 层架构，但服务器的性能不够，而且是很不够，如今的经济形势去升级服务器又很困难。现在还在恼火中，想改回两层架构（当然可能是玩笑话）。 我有点疑问,就是Business Model 没变，当前系统都能支持，花成本重写系统，有点不可理解，如果一定要改，旧系统的很多细节都要考虑到，否则一旦上线，会搞得你生不如死。那可是产线啊，流程或者业务卡住话后果真的很严重的。这个其实很难的。搞不好就会“照虎画猫”。 别跟我谈架构，先给台Server 吧，我代表老板谢谢您啦。生产工厂用的是最好的Server 和Storage(加起来价值1000 W)，而维修工厂的Server 只是个不入门级Server,并且Storage 是没有分开的。不同的软硬件条件也是约束，架构时要考虑的。 楼上说的是。 程序出问题都要在10分钟内搞定的，不然产线就停在那里。 |
| 返回顶楼 | |
|
发表时间：2009-07-10
最后修改：2009-07-10
|
| 返回顶楼 | |
|
发表时间：2009-07-10
最后修改：2009-07-10
halida 写道 zhanghonglun 写道 halida 写道 我们企业用delphi+oracle做产线管理系统，作业方式就是给我们的产品（手机）贴条码，然后通过刷条码进系统来管控流程。有时候要调用外部程序，印（<script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/themes/advanced/langs/zh.js"></script><script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/plugins/javaeye/langs/zh.js"></script>传文档到LPT端口）。因为windows费用的问题，部分电脑采用linux+wine的方式来运行系统。
现在我们考虑重新开发系统，因为Delphi渐渐不支持了，以及因为效率的原因，要换到3层的架构。我们主管的想法是使用.net开发。我不知道.net的界面是否可以支持跨平台。 我个人因为兴趣原因，想用python+pyqt+django+salalchemy来开发系统，但是因为自己的实力不够，所以不好来推这样的架构，我的想法是客户端用pyqt，采用xmlrpc连接业务逻辑服务器，同时运行一个web服务器来显示查询页面（也可以整合到客户端中），DB端用sqlalchemy连到oracle。 请问各位觉得我的想法如何，有什么更好的实现方式（实在不想用.net开发，但是考虑到可维护性，不知道.net能够撑多久）？ 列一下需求： 3层架构 夸平台 能够运行本地程序，做一些交互 方便分布（产线电脑，有些是局域网，只能访问特定的服务器） 方便开发（个人建议能够接近Literate Programming，或者脚本式开发） 实时性好，产线作业员可等不了几秒。 我们的开发team为3人，我是主程序员，可以在架构上面说得上话。只要我能够开发出一个原型，并作出分析报告，采用我的架构应该没有问题。业务逻辑都是现成的，只要按照逻辑重新coding就好了。 我对架构的方面完全没有经验，请问应该如何去学习相关的知识呢？ 我不是专家，这玩意儿不就是传说中的SFCS 系统吗，或者MES，MES 的Scope 可能要大一点， 条码枪不是问题，就是个输入设备而已，焦点在框框里，一扫也就进去了，没那么玄乎，条码打印也很Easy, 就是向某个端口（如Com 或lpt口）写文件而已。如果要共享打印机的话，可能要在打印机的地方搞个服务。这里有个现实的问题，就是不同的标签要换标签纸的，这个可能要配合超级智能机器人才能完成了(可惜我们没有)。产线上不可缺少的还有个玩意儿就是称(Scale)，可能也是个输入设备。 实时性和可用性是个最需要考虑的问题，看你工厂的规模，单位时间内Transaction 的数量，如果采用3 层架构的话，对服务器配置的要求还是有点的，否则性能是个问题。工厂对实时性要求挺高的，IE 作产线规划时，标准工作步骤都定义得很清楚，系统上要按几次键盘，点几次鼠标都是规划好的，每一步需要的时间也是清楚定义的，时间就是产能。如果搞个系统，刷了条码半天没反应，刷个Error Code，要下一步再下一步，生产单位会杀了MIS 单位。如果想把GUI 改成网页，劝你三思而后行，我们海外的维修点使用的系统采用的是B/S 架构，不过那些维修点的工程师不过10 人吧。 提到效率问题，如果Server 比表差的话，两层架构的性能肯定高于三层架构。高并发时Server 甚至会死给你看 客户端的环境也要考虑，产线上的机器跟各位开发人员的机器配置是没法儿比的。 我们两个生产工厂每月产能都上百万的，用的10 年前使用Delphi 写的系统，跑得非常好，只是维护起来有点困难了。维修厂每月产能不到10 万，我们先尝试使用java 改造维修维修厂的系统，现在效果并不理想。恩，3 层架构，但服务器的性能不够，而且是很不够，如今的经济形势去升级服务器又很困难。现在还在恼火中，想改回两层架构（当然可能是玩笑话）。 我有点疑问,就是Business Model 没变，当前系统都能支持，花成本重写系统，有点不可理解，如果一定要改，旧系统的很多细节都要考虑到，否则一旦上线，会搞得你生不如死。那可是产线啊，流程或者业务卡住话后果真的很严重的。这个其实很难的。搞不好就会“照虎画猫”。 别跟我谈架构，先给台Server 吧，我代表老板谢谢您啦。生产工厂用的是最好的Server 和Storage(加起来价值1000 W)，而维修工厂的Server 只是个不入门级Server,并且Storage 是没有分开的。不同的软硬件条件也是约束，架构时要考虑的。 楼上说的是。 程序出问题都要在10分钟内搞定的，不然产线就停在那里。 有的时候要出货，集卡已经等在仓库门口，可能司机还在狂按喇叭，这时候如果出货功能卡住了，或者产品还在线上包装，但QA 不能做了，靠，急死你啊。反正换系统，特别是核心系统是有挺大风险的。 经济景气时，或者有紧急订单在处理时，产线是8h×3 运转的，估计当机超过10 分钟，MIS 就要集体记大过，奖金也可能没戏了，还无话可说～ |
| 返回顶楼 | |
|
发表时间：2009-07-11
貌似做mes的兄弟们都赶过来了，不如楼主建个mes的圈子？
|
| 返回顶楼 | |
|
发表时间：2009-07-11
http://bbs.palmjob.net/2017/090603071622226-1.htm
对RCP的优缺点说了点描述。 |
| 返回顶楼 | |
|
发表时间：2009-07-11
hatedance 写道 貌似做mes的兄弟们都赶过来了，不如楼主建个mes的圈子？
呵呵，我是业余的，只是支援工厂的MIS 做过一个SFCS 系统。 |
| 返回顶楼 | |
|
发表时间：2009-07-13
最后修改：2009-07-13
python+pyqt+django+salalchemy
其实楼主你所想的方案已经很好了，代替delphi，我想没有什么比python+pyqt更合适了，swing不好，java qt也不好，c++ qt也不好，python+pyqt的生产效率是最高的，你若想先做个原型，他也是首选。运行本地程序，python比java要方便 django+salalchemy 无非是一个server的问题，不一定非用django+salalchemy，你可以有很多选择。server需要足够稳定，足够的并行处理能力，定义好接口，具体实现不一定限于python，java倒是一个不错选择。分布式不是问题 python+pyqt +（server） + oracle 假如你非常想推你的方案，你有两种选择： 1，加班加点的编码吧，把原型搞出来，用事实说话，本人的方案，可行！！！ 2，你对做这个原型不够信心，那就写文档吧，google...查询尽可能多的资料，整出至少100页的文档，一定要图文并茂，一定要表现的煞有其事。对java，.net等主流方案做出比较，同时要得出结论：你的方案最佳。也许文档中一半的东西实际可能用不到，你也要写。你要让主管觉得你确实是为这事呕心沥血了，确实是很认真了。 那你就有希望推行你的方案了。 我有个朋友用了200页的文档说服主管让他负责一个省级boss系统的项目开发。而实际项目开发中并非完全按照文档所说。更没有用到texdo如此重量级的东东。 你要办实事，就千万别拿那些商业中间件来忽悠自己了 假如有幸，那么相信你的方案，搞定它。 对待遗留系统这个话题，随便扯扯可以扯几大筐的话出来。其实无非分两派，一派激进，一派保守，很难用对错来说明。作为激进者想要成功，需要足够的实力和魄力。你的观点和意见越激烈，你就要越沉着。无论是激进派还是保守派都需要全面的分析系统，分析可能存在的所有问题。保守派以为“稳定压倒一切”，激进派认为“不破不立”。 顺便说一句，楼主比较激进，很欣赏这一点，我不喜欢保守派，常常恨得咬牙切齿。只是他们常常是一些掌权者，无奈何。 我也是python pyqt的狂热分子，用过swing，swt，java qt ，全放弃了，比较一下，python pyqt爽就一个字。 当不得不借用一些java类库时，我也先假设是不是能直接用python来调用java类库，然后就google到jpype了，爽就一个字。 |
| 返回顶楼 | |
|
发表时间：2009-07-14
zhanghonglun 写道 halida 写道 我们企业用delphi+oracle做产线管理系统，作业方式就是给我们的产品（手机）贴条码，然后通过刷条码进系统来管控流程。有时候要调用外部程序，有时候要打印（传文档到LPT端口）。因为windows费用的问题，部分电脑采用linux+wine的方式来运行系统。
现在我们考虑重新开发系统，因为Delphi渐渐不支持了，以及因为效率的原因，要换到3层的架构。我们主管的想法是使用.net开发。我不知道.net的界面是否可以支持跨平台。 我个人因为兴趣原因，想用python+pyqt+django+salalchemy来开发系统，但是因为自己的实力不够，所以不好来推这样的架构，我的想法是客户端用pyqt，采用xmlrpc连接业务逻辑服务器，同时运行一个web服务器来显示查询页面（也可以整合到客户端中），DB端用sqlalchemy连到oracle。 请问各位觉得我的想法如何，有什么更好的实现方式（实在不想用.net开发，但是考虑到可维护性，不知道.net能够撑多久）？ 列一下需求： 3层架构 夸平台 能够运行本地程序，做一些交互 方便分布（产线电脑，有些是局域网，只能访问特定的服务器） 方便开发（个人建议能够接近Literate Programming，或者脚本式开发） 实时性好，产线作业员可等不了几秒。 我们的开发team为3人，我是主程序员，可以在架构上面说得上话。只要我能够开发出一个原型，并作出分析报告，采用我的架构应该没有问题。业务逻辑都是现成的，只要按照逻辑重新coding就好了。 我对架构的方面完全没有经验，请问应该如何去学习相关的知识呢？ 我不是专家，这玩意儿不就是传说中的SFCS 系统吗，或者MES，MES 的Scope 可能要大一点， 条码枪不是问题，就是个输入设备而已，焦点在框框里，一扫也就进去了，没那么玄乎，条码打印也很Easy, 就是向某个端口（如Com 或lpt口）写文件而已。如果要共享打印机的话，可能要在打印机的地方搞个服务。这里有个现实的问题，就是不同的标签要换标签纸的，这个可能要配合超级智能机器人才能完成了(可惜我们没有)。产线上不可缺少的还有个玩意儿就是称(Scale)，可能也是个输入设备。 实时性和可用性是个最需要考虑的问题，看你工厂的规模，单位时间内Transaction 的数量，如果采用3 层架构的话，对服务器配置的要求还是有点的，否则性能是个问题。工厂对实时性要求挺高的，IE 作产线规划时，标准工作步骤都定义得很清楚，系统上要按几次键盘，点几次鼠标都是规划好的，每一步需要的时间也是清楚定义的，时间就是产能。如果搞个系统，刷了条码半天没反应，刷个Error Code，要下一步再下一步，生产单位会杀了MIS 单位。如果想把GUI 改成网页，劝你三思而后行，我们海外的维修点使用的系统采用的是B/S 架构，不过那些维修点的工程师不过10 人吧。 提到效率问题，如果Server 比表差的话，两层架构的性能肯定高于三层架构。高并发时Server 甚至会死给你看 客户端的环境也要考虑，产线上的机器跟各位开发人员的机器配置是没法儿比的。 我们两个生产工厂每月产能都上百万的，用的10 年前使用Delphi 写的系统，跑得非常好，只是维护起来有点困难了。维修厂每月产能不到10 万，我们先尝试使用java 改造维修维修厂的系统，现在效果并不理想。恩，3 层架构，但服务器的性能不够，而且是很不够，如今的经济形势去升级服务器又很困难。现在还在恼火中，想改回两层架构（当然可能是玩笑话）。 我有点疑问,就是Business Model 没变，当前系统都能支持，花成本重写系统，有点不可理解，如果一定要改，旧系统的很多细节都要考虑到，否则一旦上线，会搞得你生不如死。那可是产线啊，流程或者业务卡住话后果真的很严重的。这个其实很难的。搞不好就会“照虎画猫”。 别跟我谈架构，先给台Server 吧，我代表老板谢谢您啦。生产工厂用的是最好的Server 和Storage(加起来价值1000 W)，而维修工厂的Server 只是个不入门级Server,并且Storage 是没有分开的。不同的软硬件条件也是约束，架构时要考虑的。 做数据库维护才有意思，工厂不大可能配备DBA，只能几个Developer轮流应付，每天等中午操作工都去食堂吃饭的时候飞奔到厂房，登录、运行脚本、Dump、保存、改名、登出，等都弄完了饭也凉了，後来改成COBOL风格的数据保存方式，数据库维护轻松多了，但是劳动量都转嫁给程序员了，代码量至少涨了30%。 不过劝楼主如果想在那家公司一直做下去的话，自己维护一套通信协议和通信套件还是很有必要的，现在互联网上的常用通信套件都不怎么高效，曾经问过tuxedo的授权价格，当时含了口水差点喷出来。 |
| 返回顶楼 | |
