电信运营支撑系统的生产调度流程管理（5篇材料）

第一篇：电信运营支撑系统的生产调度流程管理

电信运营支撑系统的生产调度流程管理

Workflow Management of Telecom Operational Support System 2003-11-27 作者:叶云/YE Yun,张帆/ZHANG Fan 摘要:文章对电信运营竞争的环境下运营支撑系统中生产调度流程管理的作用、类型划分和实现要求进行了分析，并对业务受理调度流程中各环节的定义及实现进行了进一步探讨。

关键字:运营支撑系统；生产流程；业务受理；电信运营图

英文摘要:With regard to the fierce competition in the telecom operation field, the workflow management of the telecom operational support system(OSS)is analyzed in respects of its functions, classifications and deployment requirements.The definition and implementation of each section of the service acceptance workflow are further discussed.英文关键字:OSS;Workflow;Service acceptance;Telecom operations map

随着电信运营市场竞争环境的形成，以及加入WTO后国外电信运营商的逐步进入，中国电信运营商面临如何增强竞争力、扩大市场份额、实现效益目标的挑战。在这种情况下，运营支撑系统成为运营商的关注焦点。

对于中国运营商而言，如何按照商业企业的性质和原则来规划、实现、改进运营支撑的管理、组织、流程，是目前需要重点解决的问题。其根本内容，就是改变过去以电信网络为中心的管理、运维模式，实现以客户为中心的商业企业市场营销、客户关系管理、电信产品销售服务。

以客户为中心的运营支撑系统架构的根本内容就是如何实现以客户为中心的业务提供、业务保证、业务计费以及基础建设的端到端过程。而端到端过程的实现，关键问题是如何实现业务在各系统间的流转和衔接。因此，基于工作流的生产调度系统在运营支撑系统建设中起着非常重要的作用。运营支撑系统的发展趋势

国际上运营支撑系统建设正处于飞速发展时期。电信管理论坛(TMF)2000年在电信管理网(TMN)体系基础上，提出了电信运营图(TOM)，后来又补充提出了增强电信运营图(eTOM)，为实现新一代运营支撑系统提供了业务框架规范，在国际范围内得到了广泛的认同和支持。随着中国在电信领域与国际的接轨，先进的运营支撑建设思想也以更快的速度在中国得到应用和实践。如何在运营支撑系统的规划建设中考虑中国国情，体现运营商的实际需求，中国电信运营商以及一批有实力的IT服务提供商在多方面进行了有益的探索。在建设内容上，已经形成了如图1所示的运营支撑功能框架。

在运营支撑系统功能框架中，运营支撑系统(OSS)从电信网元管理到客户之间，由下而上划分为网络管理层、业务管理层、客户服务层3个管理层面。

在各系统功能实现内容上，按照在企业运营过程中的不同管理内容，划分为业务实现、业务保证、业务计费、战略/规划及基础建设等4个过程管理域。

在运营支撑系统功能框架中的各系统之间，按照电信业务前后端管理模式进行总体规划。在业务前端，根据电信运营商的实际情况及需要，规划实施丰富的、多种的客户接入渠道及手段，包括传统营业厅、网上营业厅、呼叫中心、分销商、客户经理等，并提供附加的管理功能，如客户经理的绩效管理等；在业务后端，按照统一的业务实现、业务保证、业务计费、战略/规划及基础建设业务过程管理域定义后台模型并实现。

在业务功能上，目前运营支撑系统覆盖了专业计费、综合帐务、综合结算、资源管理、综合营业/客服、生产调度、故障管理、网络管理、综合营销、经营分析等建设内容，呈现出全面发展建设的态势。

生产调度的作用及类型

从运营支撑系统功能框架可以看出，生产调度实现业务受理、业务投诉、建设申请等从开始到竣工处理的一整套流程，完成流程的配置、状态、时限和业务队列的处理、调度和管理。生产调度利用工作流平台实现业务流程的全部和部分自动化。工作流管理系统使企业中大量的基于知识与规则的任务能与活动协调一致、高效运行，并且在正确的时间将正确的信息传给正确的岗位或应用系统，从而实现正确的业务流程。生产调度子系统不是业务系统，而是业务的“操作系统”，它的作用是为电信企业的业务运行提供一个可以灵活扩展的支撑环境。

按照不同的运营商情况的差异，生产调度系统一般实行主干网、本地网两级调度，同时处理其他生产调度系统传来的异地业务受理、业务协作等业务调度，实现两级的业务流程各环节的顺利流转。

生产调度处理的业务流程按照不同的过程管理域，分为以下4类：

●业务受理处理流程，包括订单审核、任务分解、调度方案设计、施工管理、竣工处理等环节，并包括预受理、咨询等处理流程，属于业务实现管理域。

●故障处理流程，包括由客户报障、网管报警、网络维护巡检触发的相应故障处理流程和应急调度流程，属于业务保证管理域。故障处理流程还包括业务投诉的相关处理流程。

●由帐务系统发起的业务停/复机处理流程，包括欠费停机和缴费复机两大类，属业务计费管理域。

●由网络基础建设、运行维护、网络优化、上级调度产生的订单处理流程等属于战略/规划及基础建设管理域。

为实现生产调度系统在运营支撑系统中的发动机作用，完成以上4类流程的顺畅流转和功能的无缝衔接，对生产调度系统功能提出了如下的要求：

生产调度在订单生命周期中完成各类型业务订单的调度，实现订单在系统状态中的迁移以及用户对业务处理规则的制订和修改，并完成对业务的统计和分析。

●生产调度要处理可能出现的各种处理结果，不得出现不可预测的状态，而且要实现异常工单或订单的调度管理及合并工单或订单的调度管理，以及实现对订单流向的跟踪及追溯。

●在系统各施工环节中，对工单或订单实施时限监控和提供预告警功能。

●提供异常情况的处理能力，包括追单、撤单、缓装、转待装等。

●接受通过其他生产调度系统传过来的异地的业务受理订单，并及时地通过相关生产调度接口回复。

●对异地处理业务全程监控，对异地回复的经其他生产调度系统传回的信息及时处理后并回复给客户。

为实现以上功能要求，生产调度系统必须具有强大的灵活配置能力，以适应各种类型流程的管理需要，要具有如下能力：

●组织架构自定义，适应用户组织机构、岗位、职责变化的需要。

●流程自定义，适应用户不断进行的流程重组、业务优化的需要。

●调度环节权限自定义，适应各部门之间人员、职责变化的需要。

●流转表单通过模板自定义，适应表单变化的需要。

●时限管理设置与流程监控设置提供灵活的时限与流程监控管理途径。

●开放的、标准的对外信息接口定义，实现与其他系统的功能衔接。业务受理调度流程各环节的定义及实现

在各类调度流程中，各种业务受理流程的定义最为复杂，环节定义及功能实现也不尽相同，各运营商实现时往往存在环节模糊功能界定不清的问题。下面本文对国内外业务受理流程的定义及实现进行比较分析，为生产调度的建设提供借鉴。

在TMF制订的电信运营图标准中，对业务提供的典型描述如图2所示。图中，业务受理环节分为受理、订单处理、业务配置、网络提供、网络配置等主要处理过程。之所以业务提供流程出现如上的过程划分与后台的业务逻辑关系密不可分。

目前电信业务的后台基础实体模型已经在运营支撑建设领域被广泛接受(如图3所示)，内容描述如下：

●网络资源是电信运营商提供电信产品的基础，也是网络资源承载业务资源。

●一种或多种业务资源有机组合成为可提供的电信服务，包括主体服务和附加服务。

●服务是为满足客户要求由电信运营商向使用者提供的基本功能元素。服务分两类，一类是主体服务，另一类是承载在主体服务上的附加服务。

●产品是对电信服务的包装，由一项主体服务和承载在该主体服务之上的附加服务构成。服务功能绑定资费策略后就构成了产品。

●产品套餐是对产品的组合包装。产品套餐是由一个或多个产品组合而形成，在产品套餐上可以定义统一的套餐优惠策略。

●客户定购电信运营商的产品或产品套餐，使用电信运营商的服务，成为电信运营商的用户。

综合以上内容描述，业务受理流程中的主要处理环节功能可以划分如下几种：

●受理完成产品、产品包的前台受理，以及竣工后通知用户。

●订单处理完成订单审核，并将产品/产品包分解为服务，转入“业务配置过程”；竣工处理过程根据“业务配置过程”返回的各服务竣工内容，确定产品、产品包的竣工情况后返回“受理”环节。

●业务配置将服务拆分为业务资源，实行任务分解，转入“网络提供过程”；在竣工过程中根据“网络提供过程”返回的各业务资源配置完成的内容，确定服务的竣工情况后返回“订单处理”环节。

●网络提供根据业务资源配置的要求，利用资源管理系统，完成各业务资源调度方案设计的功能，即调度网络资源承载业务资源；在竣工过程中根据网络配置竣工的内容，确定业务资源配置完成后返回“业务配置”环节。

●网络配置根据完整的服务调度方案设计，完成现场施工的内容，包括网管施工、线路施工、新装施工、测量施工等；竣工后，返回网络配置竣工内容至“网络提供”环节。

在具体实现中，基于生产调度的工作流平台实现以上功能。订单处理、业务配置、网络提供、网络配置为生产调度系统的业务受理流程管理的具体内容(见图2)。

业务受理流程管理包括如下关键环节：

●订单处理。含订单处理、业务配置，包括订单审核和任务分解的管理环节。

●资源调度设计。含网络提供，包括资源调度、调度方案设计环节。

●施工管理。包含网络配置，包括工单生成、派发、施工管理、测量等环节。

●竣工处理。包含以上环节中的竣工处理内容，包括计费帐务信息的归档、资源归档以及故障管理中业务等级协定相关信息的归档，完成后返回前台受理。

以上内容最终实现以客户为中心的业务受理端到端过程。

总结

在运营支撑规划建设中，将生产调度流程管理划分为业务提供、业务保证、业务计费、基础建设4种类型的调度流程，能使企业中大量的、基于知识与规则的任务与活动能够协调一致、高效运行，并且能在正确的时间将正确的信息传给正确的岗位或应用系统，从而实现正确的业务流程。在竞争环境下，中国电信运营商对运营支撑系统提出了更高的要求，因此，运营支撑系统必须具有强大的灵活配置功能，并认真考虑业务流程的规范化问题。

参考文献：

[1] TMF GB910 Version 2.1,Telecom Operations Map [S].[2] TMF GB921 Version 3.0,The enhanced Telecom Operations Map(eTOM)Business Process Framework [S].[3] TMF GB920 Version 1.5, New Generation Operational Support Systems(NGOSS), Architecture Overview [S].[4] ITU-T M.1400, Designations for Inter-Operator Networks(Revised)[S].[5] ITU-T M.3100,Principles for a telecommunication management network [S].[6] 张雷, 黄友平.基于CRM的电信业务流程重组[J].电信技术, 2002,(4):8-10.叶云，深圳市中兴通讯股份有限公司技术中心主任工程师，清华大学硕士毕业，已发表论文10余篇，长期从事运营支撑系统的需求分析、系统设计工作。

张帆，中国网络通信有限公司北京分公司运维部项目经理，长期从事运营支撑系统的建设规划、项目管理工作。

第二篇：国内电信运营支撑系统建设的五大硬伤

国内电信运营支撑系统建设的五大硬伤

国内电信业的竞争正从“资源竞争”转移到“业务竞争。”在这个转移过程中，各大运营商纷纷重新规划建设适应新电信环境的运营支撑系统。一时间，关于BOSS的讨论、研究以及相关的建设案例被炒得热闹非凡。可就在这热闹繁华的泡沫底下，往往会看到运营商的业务发展被不完善的支撑系统所拖累，投入了大量资金，却远远没有达到预想的效果，而软件集成商在获取大量订单的情况下，却一个一个陷入到BOSS系统的建设项目当中，消耗了大量人力、财力。

我们必须让自己冷静下来，思考问题究竟出在哪里？

总结国内的BOSS系统建设情况，有以下五大硬伤，严重影响着运营支撑系统的正常发展。

一、赢单不赢利

对于国内做电信运营支撑系统的软件集成商来说，目前最头痛的问题就是赢单不赢利。在BOSS系统的招标过程中，有的竞争厂商为了拿到订单，大打价格战；也有新进入的厂商处于所谓的战略考虑，直接出地板价拿下；还有的运营商预算低，让厂商没有任何回旋余地。这样一来，软件集成商处于一种尴尬的境地：“拿不着单是等死，拿下单是找死。”

对于这种情况，运营商往往并不在意，甚至是一定程度地纵容。殊不知，软件厂商在出现利润长期得不到保证的情况下，要么是给多少钱，出多少力，集成商投入少，导致提供给运营商的软件质量和服务得不到保障；要么是由软件集成商亏本投入，最后支撑不下去而放弃。这种例子，在国内BOSS系统建设中比比皆是。

当然，出现这种情况，国内的软件集成商自身也有很大问题。由于它们的产品设计不到位，质量不过硬，基本上是项目型的公司，且项目管理差强人意，系统实施的周期过长，从而导致项目成本居高不下。使得本来就少的利润被进一步侵蚀。

因此要扭转这种“赢单不赢利”的局面，只能从两方面着手：一方面，运营商应该认识到，一味降价并不是好事，一个报价过低的系统，不是软件本身有问题，就是后续的服务跟不上，因此需要预留一定程度的利润给软件集成商，以充分保证软件质量的可靠和持续的服务；另一方面，软件集成商要狠抓内部管理、合理控制成本、严格管理软件开发过程、优化产品质量，改纯项目型公司运作为项目、产品迭代运作方式，通过项目完善自身的产品，通过产品化来减少项目实施周期，稳定产品质量。

二、过分乐观的工期

尽管大家都知道BOSS系统是一项非常艰巨、周期相当长的系统工程，但在实际系统建设过程中，却经常将其忘之脑后。其理由为，一是软件集成商的销售人员为了拿单，在应标时投运营商所好，宣称在较短的时间内能够将系统实施完成；二是运营商由于各种因素，包括一些企业内部的“政治”因素，将工程预期压缩得很短。

因此一个完整的BOSS系统，在各方因素的推动下，被要求在3个月、甚至是1个月之内实施上线。如果是拿现成的产品实施倒也罢了，但运营商还有非常多的个性化需求和自有的业务处理流程，软件集成商提供的产品又没有足够的灵活性去适应运营商个性化的需求。更严重的是，运营商和软件集成商缺乏全面把握业务的人才，无法细致地在前期定义功能需求。

有了这么多的限制条件，系统还要在非常紧的工期下实施上线，于是在资源、质量、进度均衡的项目管理平衡圈上，便只有牺牲系统的质量了。过粗的需求分析、草草的设计、未经严格测试的系统，匆匆忙忙赶在期限内上线，结果当然可想而知，更谈不上对系统扩展性的远期规划。系统漏洞百出，然后又在本来就不牢固的基础上现场打补丁，越改越乱的情况经常出现。好一点的勉强应付，差一点的被推到重来。几番折腾，到系统能够稳定运行时，已经离当初的预期过去很远了。如此匆忙应急救火的行为，可谓是“能让项目尽早地开始，却不能让项目尽早地结束。”

既然知道带着光环的工期不切现实，运营商和系统集成商不如静下心来，做好系统的项目规划。即使是业务紧，迫切需要新系统的支持，也可以根据系统的轻重缓急，规划好建设的分期分批实施，不要想着一步登天。这方面，可以充分借鉴OMM（运营成熟度模型）。BOSS系统的建设，最重要的是要打好基础，构架好扩展性、伸缩性良好的数据模型和技术体系。一两次应急系统的建设可能还说得过去，要是长此以往，运营商和系统集成商总是在忙于类似的系统应急和救火，问题就大了。

三、变化的需求和难变的系统

如果任意问一个BOSS系统的项目经理，关于BOSS项目最头痛的5个问题，估计80％的人的回答是“客户的需求变化太快。”

需求变化快，系统还没上线，原来的业务流程就变了，需要支持的业务又增多了，数据格式和以前又不同了。国内现有的BOSS系统，对于这些种种的变化，又缺乏足够的适应能力。尽管各个厂家都会宣称自己的系统灵活性怎么强，可遇到实际情况的变化，又都是一顿手忙脚乱地修改。最痛苦的是，需要将以前的模块推倒重来才能适应新的要求。

“多变的需求”经常是运营商和系统集成商产生纠纷的最主要原因。

从系统集成商的角度看，合同签订时，不覆盖这些变化的需求，能不做就不做，能少做就少做；而对于运营商来讲，投资了这么大一个系统，可一些关键业务还支持不了，更是想不通，于是便压着集成商反复修改，反正“顾客就是上帝，钱在谁手里谁是大爷。”

变化的需求固然需要控制，但是我们应更多地站在运营商的角度考虑。首先，运营商要发展，业务必然会根据竞争情况发生变化；其次，构建的BOSS系统绝对不是一个静态的系统，必须“与时俱进”。

“如何支持从几十种业务到几百种业务的扩充”、“如何支持从几十万用户到几百万用户规模的增长”、“如何支持运营商各种个性化服务”等问题，都必须是在构建BOSS系统时重点考虑的问题。

再回到项目与产品的关系上面来，对于BOSS系统的建设，应遵循以下理念：

统不需修改就能适应电信行业业务管理70％左右的共性化功能；

过系统数据定制的方式，适应运营商25％左右的个性化的功能；

不推翻原有架构、不重做原有模块，利用面向对象的继承和重用，以增加业务插件的方式，满足剩余5%的功能。

四、铁打的营盘流水的兵

BOSS系统的建设讲究长期规划、分布实施和持续建设。对于系统建设是这样，对于参与建设的人来说，也同样如此。但对于国内的软件集成商来说，能做到这一点的，可谓少之又少。

由于大多数公司都是项目型的公司，有了项目，就把开发人员、实施人员长期置于外面出差。有很多不适应这种状况的人员，在公司无望解决这种局面的时候，选择了退出。还有的就是公司之间挖墙角。有的甚至是整个项目团队被连锅端掉。挖墙角时，有冲人去的，将骨干人员挖过来，补充自己的设计开发力量；也有冲公司去的，如两个公司同时在竞一个标，其中一个公司将其主要人员挖过去，使得另外一个公司力量被极大削弱，而被迫退出。

更多的是，软件集成商内部根本就没有长久的规划，跟着运营商的指挥棒走。今年大力建设“九七系统”时，全力投入做“九七”；明年本地网计费系统热起来了，又把力量转向本地网计费系统；过一阵大家一炒CRM，人员又去改做CRM系统。而一旦没拿到单，相关人员裁的裁，转的转。等拿到单时，又临时去拼凑人员，重砌炉灶来建设系统。

很多厂家就是这样，一轮一轮地进行着低水平的重复，没有积累或很少积累，公司总觉得上不了规模。总觉得没单的时候人太多，把人闲死；有单的时候人又太少，把人忙死。

注重持续发展的公司，一定要有自己的产品线规划。要静得下心、沉得住气，保留和稳定一批队伍，注重产品开发。走项目与产品迭代发展的路线，产品出来后，拿到实际项目中检验完善，然后再整理提高，以此不断地循环反复，产品的水平自然而然地就上去了。

公司运作的目的是什么，谈得很多的是四个“价值最大化”：股东价值最大化、客户价值最大化、员工价值最大化和社会价值最大化。这四个方面中，“员工价值最大化”是一个基础。没有员工长期的、富有创造力的奉献，根本谈不上其他三个方面。

对于员工来说，有三点非常重要：成就感、利益和自身能力的不断提高；而对于公司来说，怎样将公司的成就、利润和发展与员工的以上方面有效地结合在一起，形成一个良性循环，这点尤显重要。只看事物的任何一方面，都会走向极端。

五、“城头变幻大王旗”

在任何领域，追求的都是长期友好的合作。但对于国内BOSS系统的建设，经常看到的却是“城头变幻大王旗”。可换来换去还是那么几家集成商，换来换去的系统，本质上并没有多

大改变。

软件集成商的愿望都是美好的，都希望做好项目。可遇到种种实际情况时，美好的愿望就打了折扣。比如软件厂商拿到的订单一多，人手忙不过来；或签下的订单利润不高，不愿意过多地投入；或自身软件能力存在问题；或项目管理失控；或人员频繁变动；或厂商和运营商产生冲突。有了这些主观和客观的因素，反映到最后提交的系统就是一个差强人意的系统。

运营商有时也提出一些理想但不切实际的要求，让软件集成商勉为其难，或者是眼里容不得一点沙子，一些小问题故意扩大化。

而在软件集成商内部，却经常不大理会运营商的一些问题，认为运营商提出的问题幼稚，在技术上一点也不懂；而运营商则认为号称高科技的公司，却做出这么一个漏洞百出的系统，运营商内部的一些人员甚至经常恶意责骂集成商开发人员的能力。宁愿冒着自己建设的系统上不去、出大问题的风险，也要去看软件集成商的笑话。

这样一来，本来就存在不少问题的系统，再加上运营商和软件集成商之间的不协调，互相看不起，将问题都推到对方身上。结果就经常出现“签单前是朋友，实施后成怨敌”的情况。当运营商进行下一期BOSS系统建设时，更换厂家就是自然而然的事情了。

可是更换的成本和代价是相当大的，劳民又伤财。并且，在没有解决本质问题的时候，每一次更换，又是新一轮争吵的开始。

要解决这个问题，双方都需要从完善自身着手，但运营商可以发挥更多的主导作用。在招标时，不要轻易相信软件厂商许下的空头支票，一定要眼见为实，同时细致地、多角度地考察兄弟运营商的建设情况，以及软件集成商的历史表现，初期就剔除不合格的厂家；建设时，既要严格规范，又要从实际出发。不把自己当作出钱的甲方，颐指气使。心态上更应该将软件集成商当作是一个壕沟的战友，和软件集成商一起共同面对问题、解决问题。

以上部分环环相扣，任何一个环节出问题，都会导致其他环节的连锁反应。国内电信运营商和系统集成商只有舍去浮躁，回归理性，共同营造一个良性的建设环境，这样双方才能共同发展，在运营质量和规模上跨上新的台阶。

第三篇：生产调度流程

流程说明：

一、步骤说明

1、生产管理部下达月度生产作业计划。

2、生产调度员了解原料储备情况、设备情况、技术情况、质量情况、生产情况等，进行生产准备。

3、根据生产作业计划安排生产。

4、生产调度员根据在生产过程中发现的问题以及分厂和工艺设计/质检部提供的生产现场的问题报告协调有关部门处理生产过程中出现的问题。

5、生产过程中出现的设备问题报告设备管理部，由设备部安排维修部门进行设备维修，备件更换；生产过程中出现的质量问题报告工艺设计/质检部，由工艺设计/质检部进行质量问题处理；生产过程中出现的原料问题，通知物流公司，物流公司进行原料供给；能源问题通知保障分厂，保障分厂进行协调；中间件转序问题与各分厂进行协调；生产调度员及时将生产进度情况随时报告部门领导。对于以上不能解决的问题由生产管理部部长协调相关部门人员进行解决。

6、生产调度员根据分厂的生产状况和生产过程中发生的各种情况形成调度日志。

二、流程要素说明 步骤 2 3 4 生产准备

按生产计划安排生产 协调生产

责任人

生产管理部生产调度员 生产管理部生产调度员 生产管理部生产调度员 输入 生产作业计划、生产现场问题报告 生产管理部生产计划员、各厂

协调相关部门处理生产过程中出现生产管理部部长、生产调度员、相的设备、技术、质量、原料、能源关部门 等问题 掌握生产进度状况 生产管理部生产调度员、工厂、相关部门

生产管理部生产调度员 输出 形成调度日志

三、流程其它说明

1、流程输出表单：《调度日志》。

2、流程依据的管理制度、办法、依据：《调度工作制度》。

3、流程中的时间要求：在保证生产计划完成的前提下，可对生产作业计划做出临时性调整，事后通知计划员。

4、流程频次：1次/月

第四篇：生产计划生产调度现场管理流程

<计调科工作流程图><业务流程>1.盘点昨天生产数据及各工段现有车辆数量<负责人/协助人><所需资料>各车间工段长昨天生产报表、月度批次表等2.简单分析该数据调度3.9点开生产晨会制造本部领导、调度、各车间主任、工段长、生服部等部门负责人各车间的生产情况及遇到的问题4.整理记录晨会内容当日未能解决调度晨会记录表5.跟踪解决晨会问题调度/各车间主任、段长及其他有关人员当日产量、计划、车型等6.协调处理应急事件与该事件有关的部门及人员公司的相关管理规定7.三点半开例会各车间段长当天计划的完成数据及情况8.跟踪解决例会中的问题调度、与问题有关部门人员9.统计当天生产情况调度/各工段长生产报表10.安排班车调度/物流科11.填写调度日志，同夜班人员交接调度/夜班人员调度日志结束

第五篇：生产调度系统考察报告

生产调度系统考察报告

南化集团的系统由石大赛普公司施工，实时数据库选用美国ASPEN公司的INFOPLUS，价值300多万元。工期将近半年时间，现在只有少数数据实现了集中显示，刷新速率极慢，大部分数据都没有上传到信息中心，也没有进行更深层次的数据应用。其结构是在每套DCS处增加一台操作员站，在这台操作员站上安装相应的OPC软件，将欲上传的数据组态到OPC中；在控制网和管理网之间安装一台石大赛普公司自行研发的称为 ALL-LINK的远程数据终端设备，意欲起到将管理网和控制网隔离的作用，保护各DCS系统运行安全。

双多化工有限公司的系统由北京思创信息系统有限公司施工，在每套DCS中选一台操作员站安装OPC软件，同时增加一块网卡（加上DCS系统用的双冗余网卡这台微机一共有3块网卡），利用OPC协议将欲上传的数据传输到调度室的数采网关微机，同时在调度室增设数据服务器和WEB服务器，实现数据存储、处理和发布的功能。这样，在厂区内任一台连接到服务器的微机上都可以观看到上传的生产装置的实时数据，数据刷新速率大约在10秒左右，满足调度要求。另外，我们注意到管理网络上的某些微机还有视频监控功能，在他们厂区内分布有五六十台视频摄像头监控厂区内重点监控内容，包括生产岗位人员、重点装置区等，在有权限的微机上可以实现视频实时监控和历史录像浏览，并且可以自由选择切换画面，对某些具有云台的摄像头进行转向与调焦等操作。同时，在调度室内的22台视频监视

器也能实时监控这些内容，监控画面也可以进行切换。视频监控系统由南自公司施工完成。

2011-9-26