图1平台体系结构

    1.1 人机界面

    人机界面的主要作用是完成操作者与数据实体间的交互。目的是反映数据模型在日常业务中的可视化应用。每一步操作都是人或者设备与数据模型间的交互。根据人机界面的显示要求，从定义好的数据结构中抽取相应的内容。因此界面访问权限控制模型是这一部分设计的重点。人机界面支持二次开发，可以采用多种HMI显示工具进行定制化设计。例如：MS.NET、Oracle Forms、Delphi等。只要是支持标准数据库连接的图形化界面工具均可以作为HMI的开发软件。

    1.2 外部接口

    外部接口可以理解为外部系统、控制设备与本系统的交互界面。对于应用业务来说，外部接口所提供的正是一系列本系统与其它系统交互的数据结构。同人机界面相对，设计外部接口的主要目的是为了引入自动控制的概念。如果周围设备的自动化程度较高，则系统完全可以按照接口数据自动运行。在复杂的系统中，涉及的通信对象往往不只一方。以过程控制系统为例，外部接口的通信对象主要包含基础自动化、检测仪表、各类单体设备(机电一体化产品)，MES等外部系统。各类系统所采用的协议、硬件、访问模式均有不同。平台的通信对象定义模型及通信内容定义模型，能够以文档的形式识别预定义的通信对象属性参数及通信内容约定参数，使外部接口全面可配置化。

    1.3 数据业务

    数据业务主要包含消息分配单元、数据存储单元、数据监控单元3部分。这3部分是平台结构的核心所在，它集中体现了摆脱行业限制、以数据模型为核心的设计思想。平台的运作是独立的，不依赖于人机界面或者其它外部条件川。在具体项目开发中，这3部分囊括了预先定义好的数据模型及辅助应用逻辑。

    消息分配单元提出消息对象的处理方法，然后由标准业务应用负责执行。主要业务操作全部由预先定义好的执行者去完成，不同的处理方法针对不同的“标准业务应用”。消息分配单元是在平台构架下最具有项目特色的部分。开发者可以通过预定义的事件行为模型及行为函数模型调配业务逻辑访问控制顺序及内容。

    数据存储单元是保存业务数据模型的场所。它是应用平台进行业务开发时的主要工作区，同时也决定了运行状况及未来的扩展性。平台本身已经集成了适用于多个领域的标准数据模型。除此之外，当面对不同业务应用需要采用具有项目特色的数据模型时，开发人员可以通过平台提供工具使其有效地集成到系统中来。

    数据监控单元由服务监控、日志控制、数据维护3部分组成。主要作用是监视平台上运行的进程、会话的工作状态。在发生异常时可以按照预先定义的控制策略进行调整，从而使后续的信息能够正常处理。另外数据监控单元还可以通过日志控制向开发者、使用者提供不同级别的系统消息或者预定义输出消息。这为故障分析、新功能测试提供了可靠保障。同时还可以按照预定义的规则进行数据清理、数据分析。

    1.4 外部扩展

    外部扩展单元主要用于集成专业性的解决方案。例如数学模型、控制策略、专家系统等已经模块化的应用都可以在平台上利用外部扩展单元进行有效融合。与标准业务应用部分相同，外部扩展单元也需受到消息分配单元的指挥。以温度计算模型为例，当需要在不同时间、位置对某一材料进行连续温度监视时，消息分配单元将在需要的时刻向温度计算模型提供材料信息、环境状况、检测参数等数据，从而得到准确的计算结果。

2 设计要点

    平台设计的目标是向开发者或用户提供高效而有序的“数据操作环境”，使系统具有良好的开放性，该平台着重考虑了以下几个方面的设计。

    2.1 访问模式

    数据模型设计采用了多用户的访问模式，目的是将不同用途的业务板块有效地隔离开。不同用户间的数据访问必须在开发时独立授权。例如：平台的进程控制中需要应用Oracle系统用户下的视图SYS.V_$ PROCESS，SYS.V_$ SESSION，因此需要提前以DBA身份进行授权操作。设计时通常将数据库用户分为通信用户与业务用户，业务用户具有访问通信用户指定实体的授权。多用户数据访问流程如图2所示。

图2 多用户数据访问流程

    2.2 时序控制

    为解决并发冲突并实现时序控制，平台设计了统一的数据接口。按照数据自然收发的时间顺序对所有通信内容都采用同一时序控制逻辑，只有完成前一时刻所接收数据的处理，才继续处理后续的数据。这意味着需要将所有接收到的数据进行串行化序列组合。对于外部系统来说，“通信用户”是整个系统平台的门户。采用统一的对外门户可以简洁地对通信消息进行串行化操作，使消息队列井然有序，从而解决了系统中的并发冲突或者由于时序调配不当产生的异常。这部分的处理包含两步操作，首先由与业务相关的通信实体进行消息注册，同时触发消息处理请求；然后再由消息处理模型按照注册的队列进行消息分配。

    2.3 事务处理

    平台的事务处理分为控制性事务处理及自治事务处理两部分。控制性事务处理可以使不同的工作会话在处理数据结构内容时能够保持被访问数据的唯一性。当数据库提交工作时就能确定或者存储了所有修改，或者什么都没有存储。平台设计中采用了最外层统一调配、提交及分离用户控制提交的策略。在不同用户中完成不同的业务操作，然后由平台的执行单元统一提交。例如：在通信用户中，完成消息导入、消息注册、发送处理请求之后才进行本用户的提交。而在业务用户中则是完成预先定义的所有数据处理才进行本用户的提交。对于一条消息只有唯一的一次提交机会，如果出现致命错误则采用“全部回滚”的处理方法。自制事务处理是事务处理中的特例情况，在进行一些必要信息的记录或者进行外部扩展功能集成时会采取这种方法。此类操作并不会影响到外层整体处理的提交与回滚。通过“事务调配”结合Oracle提供的“多版本”、“一致读”等特性，使平台在体系结构的层次上保证了系统的稳定性。

    2.4 配置业务

    配置业务是指通过开发人员对业务应用逻辑及其执行方法进行可视化配置操作。通过配置业务，平台能够实现跨行业、跨领域应用。应用逻辑的组成需要包含完善的数据模型及围绕其展开的业务控制。平台的消息分配单元将按事件行为模型及行为函数模型的预定义内容，自动调配“标准业务应用”。事件行为模型主要用于定义业务逻辑的不同功能函数间的执行顺序。而行为函数模型则用于描述各类执行函数所应用到的技术参数。例如在完成厚板冷床的自动上料控制时就需要在事件行为模型中定义上料事件逻辑执行顺序，并在行为函数模型中定义冷床的尺寸、热传导系数、可用上料位置、步进速度等。

    与标准业务应用相同，外部扩展单元中的内容也是应用逻辑的重要组成部分。许多专有技术(例如数学模型、策略模型等)都采取独立封装或者模块化的形式来提供。在集成这些部分内容的时候，无论是通过数据库内部访问或者外部调用，平台仍然以可定义的模式将其纳入到应用逻辑当中。以材料跟踪为例，通过定义跟踪的对象、区域、事件，在完成跟踪业务标准模板设计后生成自动材料跟踪控制脚本，即可展现材料在不同时刻的连续空间位置变化。
3 主要功能

    通过没计业务数据模型并定义应用逻辑，自动完成各类数据操作是平台最主要的功能。

    3.1 数据通信

    数据库自身支持以SQL宰Net进行简单的数据传输，但这仅仅限于数据库系统之间。在针对某些特殊没备进行数据通信时，推荐采用标准以太网的TCP／IP电文形式进行实时数据传输。平台的外部接口主要就是为了解决这一问题而设计的。从功能的角度来讲，数据通信不仅需要完成消息的发送与接收。它还有义务及时通知平台通信用户，以便能够有序地对电文队列进行组织。平台数据通信结构如图3所示。

图3 平台数据通信结构组成

    平台对通信所描述的对象进行数据模型定义，按照业务需求将不同类型的应用实体组合为通信电文。完成电文内容定义之后，通过平台提供的标准识别格式将电文实体转化为XML结构配置文件。配置文件包含4部分，其实质都是通过定义数据模型完成配置文件的定义。设计具体项目的解决方案时需要在通信相关数据模型中进行如下定义：连接机制定义(最大链接数量、重新链接条件)；电文结构定义(电文头、电文体)；通信节点定义(IP地址、端口定义等)；通信日志定义(输出对象、输出规则等)。

    3.2 资源分配

    资源分配是一个实时的处理过程，平台采用了在数据库中虚拟执行进程的设计方法分配资源。针对某一独立的业务(或项目)设计唯一的服务进程。虚拟进程足通过动态执行DBMS_JOB来完成的。一旦进程的侦听机构获取到外部接口消息，它将对消息注册队列中待处理的内容进行分析。分析的结果需要传送给分配器，由分配器依据预定义规则循环执行函数调用，实现资源分配。侦听机构采用了DBMS_PIPE(管道)及DBMS_ALERT(广播)技术进行设计。管道用于解决不同会话间的通信问题，在数据库中虚拟进程时系统会自动建立新的会话并由它来完成事务处理。广播在侦听机构和触发机构中应用得更为广泛。对于任何触发消息，广播都具备向所有会话提供通知的能力，并且由于不存在阻塞的问题，广播可以获得更好的实时性。平台在控制虚拟进程的启动、停止时也采用了类似的方法。分配器的核心在于预定义数据处理规则及自动生成脚本。定义内容包括：资源分配对象、约束方法条件、控制顺序逻辑和主要对象参数。因此平台技术可以在不同业务领域灵活应用。

    3.3 系统维护

    系统维护提供进程监控、数据维护、日志消息等功能。平台提供可配置的功能模块，使数据监控单元按照开发者的意愿，对运行中的进程、业务数据、日志消息等进行周期性监控及维护。进程监控可以有效地提供进程的当前状态，并且在发生系统异常时能够根据预定义的规则对进程进行中断、重启动、停止等操作。此类监控不同于操作系统的进程监控，它是通过周期性接收服务主会话(启动虚拟进程后自动生成的会话)的心跳信号表示进程状态的。系统采用数据库的消息广播机制，如果监控程序在规定时间内接收不到心跳信号，则判定某一服务的主会话处于无响应状态。

    数据维护是按照数据维护模型中定义的规则进行实体分析、数据清理、备份等操作。数据维护模型主要包含数据清理周期、清理条件、分析周期、分析规则、备份周期、备份条件等内容。对于此类操作，平台仍然采用独立的虚拟进程实时执行。

    为了避免数据库事物特性对写入日志产生影响，平台采用管道发送技术进行日志记录操作。在日志数据模型中，预定义的管道将按照设计好的数据结构填充日志内容。这种形式的日志记录既可以输出预定义的异常信息也可以记录业务流程的调用堆栈，它是故障分析的主要手段。另外平台也提供审计功能，输出对于预定义实体的历史访问情况。

4 应用实例

    包头钢铁(集团)有限责任公司4100 mm宽厚板工程剪切、精整区域的过程控制系统就是采用该平台进行开发的，目前已经成功在线运行。该系统的设计完全结合了平台体系结构的四要素，即外部接口、HMI、数据业务及外部扩展。

    系统外部接口复杂多样，其中与平台连接的控制系统包括轧机过程控制系统、MES、基础自动化(控制范围内的所有PLC)、UTS(超声波探伤装置)、喷印装置。由于平台本身具有对外部接口的可配置性，在与多厂商的测试中，仅仅需要调整电文配置定义就实现了系统间的对接。

    HMI人机界面完全采用C#语言进行可视化设计，界面响应时间完全满足工业控制的要求。由于采用了开放的高级语言进行软件设计，丰富了界面的显示资源与操作功能。

    数据业务是该控制系统中最为复杂的部分。用于现场的控制系统主要有数据管理、材料跟踪、模型设定3方面的要求，因此平台需要对材料、设备、工艺等相关内容进行新的实体定义，另外还需要在外部扩展中集成自动材料跟踪、动态物流控制、剪切设定模型、冷床温度模型等专有技术。

    应用平台进行二次开发分为5个步骤：(1)依据功能需求设计业务相关的数据模型并建立实体关系模型。这一步主要针对包钢的具体项目需求，例如原始数据的组成、生产实绩的项目等。(2)根据第1步的实体设计内容，进行HMI界面设计，确定每个操作界面需要显示的内容。(3)根据外部系统通信要求进行接口相关定义。(4)将所有与业务应用逻辑相关的功能函数进行业务配置，即定义事件行为及行为函数模型中的内容。例如，电文接收处理逻辑定义、跟踪区域定义、事件定义、数学模型集成定义等。(5)通过平台提供的工具生成消息分配配置文件。

    包钢基于该平台设计开发的过程控制系统仅用3个月时间即开发完成。经2个月的现场调试后上线运行，并在设备控制要求发生变化的情况下，仍按期实现冷区全线的自动控制。该平台的应用，为项目顺利达产做出了重要贡献。

5 结束语

    以数据模型为核心、面向开发者的可配置化是该平台最大的特色。由于其体系结构的先天优势，使其能够跨行业应用，因此在冶金、有色、交通、石化等领域有广泛的应用前景。目前该平台还应用于“韶钢炼-轧综合MES”等项目，并且获得了良好的经济效益与运行效果。