交换开关控制系统的开发应用

　　摘要：本文针对原交换开关控制系统在设计时存在的不足问题进行分析，并运用实例进行反复研讨论证从而确定了在原有交换开关控制系统的基础上进行开发应用，经过交换开关系统技术改造后，使备机融入代播体系，使其发挥效益，同时提高了系统的稳定性。

　　0 引言

　　我台于2006年8月进行室内交换开关控制系统改造，通过室内交换开关的倒换，实现了每部发射机都可以上任意一副天线，使发射机间的相互代播简单快捷，提高了发射机应急播出能力。

　　随着时间的推移，原交换开关控制系统在设计时存的不足逐渐暴露出来：

　　1.当服务器端死机后，客户端无法及时发现。即当天控工控机出现死机时，值班员是无法察觉的（系统无监控、报警界面）。

　　2.该系统人机交换界面设计不够人性化，操作不方便，功能不够强大，系统不够完善。

　　3.该系统不能进行系统升级。随着事业的发展，我台安装了一部150kW发射机备机，备机无法融入当前系统，发挥应有的作用。

　　在经过反复研讨论证后，我们确定了在原有交换开关控制系统的基础上进行开发应用。改造分为三个方面：

　　（1）对原有交换开关控制系统使用的PLC控制器进行改进，即基于增加一部备机和一个同轴开关的前提下，重新设计了PLC硬件接线和PLC端口分配；

　　（2）对原有交换开关控制系统使用的PLC控制器的内部程序进行编写，达到需要的扩展功能；

　　（3）开发了一套基于PC终端的自动化软件，使新的天控系统软件实现自动化和远程监控功能。

　　一、PLC控制器硬件的改进

　　我台原有室内交换开关控制系统使用的PLC控制器是AB公司的Logix5561,经面查看硬件设备后，结合升级改造的要求，重新设计了PLC控制器的硬件接线和PLC端口分配：

　　1.增加一部发射机和一个同轴开关控制

　　相应新增加的信号有：来自发射机备机的合高压信号、去往发射机备机的天线正常信号、备机同轴开关的天线位和负载位返回信号和控制同轴开关转动的电机电源输入信号。

　　因此，将这几个信号做了如下分配：备机的合高压信号接到天控柜的FBT板，此板有12路输入，此前四部发射机的合高压信号用了四路；备机的天线正常信号接到天控柜TXBSFA板，此板有12路输出，此前四部发射机的天线正常信号用了四路；备机同轴开关的信号接到天控柜控制板2上的第四个端子，该端子上的直通和转向返回信号接备机同轴开关的天线位和负载位，该端子的直通输出和转向输出接到分别通过二极管并联控制中间继电器，中间继电器的输入接220VAC,输出接备机同轴开关电机电源。

　　2.硬件端口分配

　　根据以上的硬件连接，给各信号分配相应的PLC端口：备机的天线正常信号分配的端口地址是模块2的4号端口，同轴开关的直通输出和转向输出分配的端口地址是模块4的15号和14号地址；备机合高压信号分配的端口地址是模块7的4号端口，同轴开关的直通返回和转向返回地址分别是模块9的15和14号端口。

　　二、PLC控制器内部程序编写

　　完成了PLC控制器的硬件接线和端口分配，我们对PLC内部程序进行编制。PLC控制器内部编程主要实现以下功能：交换开关和同轴开关的转动、天线正常信号的输出、指示信号的输出（包含PLC和上位机的通讯）。

　　1.交换开关和同轴开关的转动

　　设计如下：设置允许接收变量，每当需要转动开关时，该变量设置为允许，当接收来自上位机的转动信号完成之后，如果交换开关处于高压状态，则相应的转动信号被置为零，重新设置该变量为禁止接收状态，然后进行相应开关的转动。

　　2.天线正常信号的输出

　　这部分的内容设计思路如下：列出发射机上天线的所有情况，根据当前的交换开关状态输出是否允许发射机加高压，如果允许发射机加高压，输出天线正常信号，如果允许并且发射机处于合高压状态，则禁止相应开关转动。

　　3.指示信号的输出（包含PLC和上位机的通讯）

　　每当输入信号发生变化之后，上位机程序能够及时读取相应信号，控制系统能够及时驱动相应的指示灯。

　　新的PLC程序是否能够实现设计目标，需要进行PLC程序调试。为此，编写了一份测试文档，针对天控系统的各种运行情况，查看运行结果是否符合预期目标，主要内容是交换开关和同轴开关的转动、高压状态下是否禁止运行、运行图禁止/自动情况下交换开关的转动情况、输出指示是否正常，经过反复测试修改，PLC程序能够实现预期目标。

　　三、开发一套基于PC终端的天控自动化软件

　　本次交换天关系统的软件部分，充分利用的软件复用技术，结合以往在自动化方面基础，重新定制了新交换开关系统。首先，使用了基于ACE网络通讯组件包，解决了服务器端死机后，客户端无法发现的问题；其次，使用类visio组件包，解决了窗口在重新绘制和通讯断开时，用户点击后出现“未响应”的问题；然后，利用日志组件包，解决了设备状态变化无法查询的问题；，利用语音组件包，更人性化地提示值班员设备状态变化过程。（软件复用就是将已有的软件成分用于构造新的软件系统。可以被复用的软件成分一般称作可复用构件，无论对可复用构件原封不动地使用还是作适当的修改后再使用，只要是用来构造新软件，则都可称作复用。软件复用主要用来缩减软件开发和维护的花费，是提高软件生产力和质量的一种重要技术。）1.基于ACE的网络通讯组件包

　　旧系统采用了windows自带的通讯组件包，由于系统的通讯组件包未加入心跳机制，所在当服务器出现死机时，客户端用户无法知道它已与服务器断开连接，严重影响了播出任务。如何解决及时发现连接被断开呢？结合我台在通讯组件方面的知识积累，本次通讯组件包，采用了基于ACE开发的通讯组件包，下面介绍一下这个组件包的内容：

　　ACE自适配通信环境（Adaptive CommunicationEnvironment）是可以自由使用、开放源码的面向对象框架，在其中实现了许多用于并发通信软件的模式。ACE提供了一组丰富的可复用C++ Wrapper Facade和框架组件，可跨越多种平台完成通用的通信软件任务。ACE的目标用户是高性能和实时通信服务和应用的开发者。它简化了使用进程间 通信、事件多路分离、显式动态链接和并发的OO网络应用和服务的开发。此外，通过服务在运行时与应用的动态链接，ACE还使系统的配置和重配置得以自动化。

　　ACE有以下优点：增强可移植性；有更好的软件质量；有更高的效率和可预测性；更容易转换到标准的中间件；系统具备工业级质量，可靠性非常高。我台开发出了一套基于ACE的高效网络通信组件包，隐藏层的细节问题，剥离复杂度，让每位网络通信的开发者不用理会数据是如何传输的，而是更加专注于逻辑的开发，进而降低软件开发周期。目前此套组件已实现功能：

　　1）服务器会根据操作系统的不同，自己选择Proactor（windows）框架还是Reactor（linux）框架。

　　2）对底层数据加密，剥离出来一个类，可以通过给这个类注入自己的加密算法完成对数据包的加密，使数据在被窃取后也不能知道真正内容，保证数据的安全性。

　　3）完善的日志系统，服务器会动态的记载当前处理指令情况，每个链接处理数据包的时间，数量，以及工作线程的状态。提供给开发者完善的数据分析标准，也提供给开发人员对服务器的效率进行分析和配置。

　　4）服务器和客户端做了心跳处理，会自动断开或重连无效链接。

　　5）在发送一些大数据时候，采用自主研发的粘包算法，避免大数据的粘包问题。

　　6）大量使用内存池和对象池，使组件运行效率更高、速度更快。

　　7）允许和禁止接入的IP地址控制，避免非法终端接入，窃取机密数据，从而使系统更加具有安全性。

　　8）简化调用接口，在设置好配置文件后，开发人员只需要调用一个函数就可完成UDP,TCP/IP及MDP等网络通讯模块，并可通过回调函数和发送函数进行收发数据管理。

　　2.基于多线程的类visio可视组件包

　　工业控制软件对图形处理要求很高，需要很强的实时响应能力，往往开发类似的界面需要花费很长的开发时间，尤其是当您的应用程序还需要支持打印、关系复杂的连接图以及拖拉操作等功能的时候就更是如此，此类应用程序要求用户可以能够在上面动态的调节各种数据关系，并处理非常复杂的数据流程。再加上MFC只提供了一些基本的GDI调用函数，它能够提供给我们的帮助非常非常少。因此开发这类应用程序不仅要求开发人员要去处理大量的非常复杂的WindowsGDI的调用，而且还需要繁杂的数学计算。这将是一个非常耗时耗力的工作。

　　因此，为了节省每次系统的开发周期，通过研究与实践，我台自主开发出了一套类似visio功能的组件。开发人员可通过此组件，在改动少量的代码条件下，就可实现适合各自的业务需求软件。

　　由于旧系统的图形组件都是基于事件触发的，当绘制未完成时，用户如果点击鼠标或输入等操作，软件会出现未响应及假死情况发生，进而使关键指令不能及时触发处理，带来严重的后果。因此，本组件采用多线程绘制模式，即不在基于以往的事件触发模式，而是启动一个独立的线程，对加入组件并且需要显示的元素进行实时绘制显示，让用户不再碰到假死情况。并且经过开发人员测试和用户测试，可以实现随意功能操作，而软件不会出现未响应的情况，保证用户操作的连续性。充分解决了旧系统“未响应”事件和软件假死情况的发生。

　　为了适应软件在开发好后，在不需要开发人员参与情况下，使用者就可实现对设备的增、删、改功能，进而对系统进行重新布局，此套组件拥有编辑功能，非开发人员可通过鼠标便可手动操作设备。用户可以自行编辑当前交换天关逻辑，并可对设备的大小、位置、角度等参数及设备属性进行修改和保存，生成后的交换天关逻辑图将自动加载，并根据新的逻辑图运行，具有非常好的通讯性。

　　3.基于多线程的日志组件包

　　软件运行日志的对象是软件维护人员、资深客户（比如客户方的系统管理员）。软件中的错误信息，应该分为两类，一类是软件用户能够理解的，另一类是软件用户不能理解的，需要软件维护人员介入的。前者，通常与软件用户的操作行为相关，软件用户在得到提示后，可以自行进行处理；而后者，通常与软件自身缺陷、软件部署环境问题相关的，只有软件维护人员才能处理的。

　　很明显，对于后者的详细内容，没必要用告警对话框的方式提供给软件用户，而且这样做，会大大增加软件错误处理的复杂度。直接将其写入运行日志，是简便、也可靠的方法。可以想象下面的场景，应用软件在某台电脑上运行出错，软件维护人员或客户方系统管理员查看运行日志，发现了一些系统模块调用失败的信息，并与开发人员远程沟通，开发人员根据这些信息，迅速定位错误的代码，随后开发人员可能反馈，某个系统组件没有的到正确的配置，也可能反馈，软件中有一处缺陷，将在下一个版本或补丁包中得到修正。不管是哪一种情况，这一过程都可以提高软件的健壮性。

　　现代软件日益复杂，彻底消除软件中的错误已经被证明是不可能的，那么，及时发现错误、定位错误现场信息，迅速排除软件错误就成为非常重要的事情，甚至在软件实际运行环境中也是如此。因此，软件运行日志就是捕获错误现场信息的一种重要手段。

　　日志流程图如图1所示：

　　

　　4.基于microsoft speech sdk v5.1语音组件包

　　应用微软提供的SAPI可以让我们的软件能说会道。软件中的语音技术主要包括两方面的内容，一个是语音识别（ s p e e c hrecognition），另外一个是语音合成（speechs y n thesis ），也即是文本语音转换系统（TTS）。TTS系统使用合成语音合成文本字符串和文件到声音音频流。而语音识别系统则是转换人类的声音语音流到可读的文本字符串或者文件。这两个工作，都是通过各种语音引擎来完成的。微软所提供的SAPI（全称The Microsoft Speech API），正是在应用程序和语音引擎之间提供一个别的接口，它实现了所有必需的对各种语音引擎的实时的控制和管理等低级别的细节。语音引擎通过DDI层（设备驱动接口）和SAPI进行交互，应用程序通过API层和SAPI通信。通过使用这些API,我们可以快速开发在语音识别或语音合成方面应用程序。SAPI应用程序编程接口（API）明显的减少了构建一个使用语音识别和文本语音转换的应用程序所需要的高层代码，使语音技术更加容易使用并且更加扩大了应用的范围。虽然现在SAPI并不是业界标准，但是应用非常广泛。

　　虽然SAPI功能如此强大，但其是基于COM技术，使用起来过于复杂，若每次开发都从新布置，大大延长了开发周期，而且加大了出错概率。因此，我台技术人员对其进行了二次封装，让未来开发人员在不需要了解SAPI底层细节的情况下，正确使用。语音组件逻辑流程图如图2所示：

　　

　　5.天控编辑平台

　　由于以往平台都是定制开发，即开发的平台只适用与当前台站，当在其它台站需要部署相同设备，但逻辑不同时，需要对软件进行重新开发。就如我们台，此次加了一台备机和一个同轴开关，若使用旧系统，需要再次请开发人员重新设计开发，大大增加了人力、物力及财力。因此，为了解决这个问题，本系统在开发之初，经过整个团队的整体研究，并结合我台自动化方面的基础，自主开发了一套编辑平台，在未来可能需要新加入发射机、交换开关或天线时，不再需要对软件重新开发，只需要通过编辑功能自动加入或删除相应的设备即可使用，这样不仅具有很高的经济价值，而且，经过长期的运行和维护，相应的逻辑功能也会变得越来越稳定。

　　我机房交换开关系统技术改造后，使备机融入代播体系，使其发挥效益，同时提高了系统的稳定性，使系统功能更加完善，在安全播出工作中取得了明显的效果。（作者：梁延成）