吉宁博士观点
在设备管理系统中，普遍使用的软件都存在不少令人无法忽视的缺陷。传统的设备管理系统中，即使是专业公司上门调研、根据当时情况制定方案，然后根据实际情况开发再实施的也不能够避免。问题具体是出在什么地方呢？
传统的设备管理软件开发实施之前，必须对所管理的设备进行具体分类。然后根据分类的情况定制数据存储系统，然后按所需要的功能增加存储单元，处理单元，之后进行程序编码最后实施调试，并在调试过程中进行适应性调整，同时录入数据。好点的公司还能预留部分前瞻性接口，一般的就数据录入完毕就结束开发以及实施了，基本就没什么事了。好点的就有空备份下数据，维护下服务器，基本项目周期完成了。
这类设备管理系统是现在开发市场大部分研发机构采用的开发模式，是否普遍存在缺陷呢？笔者现在就发表一下自己的看法。此类设备管理系统中，研发机构就像做只有一个扣子的皮带。难道使用方就永远不会增加或减少腰围吗？那就算今年不变，明年也不变，那第三、第四年呢？那其他不一样腰围的客户呢？这种皮带绑住的是什么呢？设备类型、类型参数、报表、体系甚至连时间周期等等的相关内容都被约定成型了。这类设备管理系统所有开发前定义的对象基本都是不可变的、没有灵活性的，可见这类设备管理系统的生命周期是何以短暂。企业不能因为系统无法新增或改变类型而不是用或不管理新的设备，更不可能改变设备就重新部署或修改软件。这类系统不但不能成为企业的助力，更加是制约与阻力。传统的系统已经无法适应企业日新月异的进步，所以必须要利用新的开发思路以及实施方法，提升设备管理信息化的效率、扩展系统的适用性、延长系统活跃期和生命期，增加系统稳定性，从而减少企业重复投资、无用投资。利用有效的设备管理系统支撑整个体系的正常运转，减少不必要的人力开支、设备空转、作业堵塞，提升各部门信息共享程度，提升人机、人人、机机间契合度，增加协作效率与稳定性。
总结之前观点，这个新模式开发的设备管理系统应具有非常高的开放性，但前提保证系统的稳定性与安全性。
如何能把设备管理系统设计成为高开放性系统，涉及到两个很重要的问题。
问题一：如何将系统框架化、模块分离、定立通信标准、聚合策略，并保证系统安全性？
问题二：如何进行无约定开发，模块通用化，并能保持数据间关系稳定、存储正常，以保证系统兼容性与稳定性？
开放性系统基本可以按以下内容进行层次划分。
数据服务层：建立统一的业务数据模型，为整个信息数据提供一个统一的数据视图，隔离应用与底层数据源，以标准存取方式提供服务给其它层服务或用户调用，使得应用界面与各数据源是松耦合的。
业务服务聚合层：根据业务逻辑，对核心业务进行梳理和整合，为上层应用提供相对独立的业务服务，同时从业务活动分离抽象可共享的、基于标准的服务。
复合应用层：根据业务流程的变化，面向客户需要和业务过程组成较高层次的复合应用，通过调用下层提供的业务服务，最后展示给用户。
服务基础环境：提供服务交互所需的消息传输、转换和路由，对服务进行集中管理和监控，包括服务的目录、版本、配置等。
解决第一个问题可以由业务数据模型着手。
业务数据模型可从数据实体服务层、服务聚合层、跨组织服务聚合层三个层次进行描述，这三个层次是从具体的组织内数据实体视图到虚拟化的、面向用户的跨组织数据视图进行区分的：
数据实体服务层：为系统提供数据实体的统一视图，并将数据都封装成为定义简单的、原子的数据实体服务模型。
在不同的业务系统中，数据以不同形式存在，使用不同的标准进行建模和编码，对整个设备管理系统来说，数据实体有全局的，有局部的，有原子的，有组合的。因此，在数据实体服务层，要重新建立一个全新的、统一的、集成的数据模型，重新定义新的关联和数据结构，对数据实体的描述也要进行扩充，除了其本身的固有的属性，还应包括每个数据实体的位置、来源、用处、限制和数据存储模型，以及对这些数据实体服务的描述，当然，这些数据服务仅仅是对数据实体的一些简单操作。在分析抽象时数据实体时要从整个设备管理系统的高度去看，而不是从某个业务领域去看，主要使用自顶向下的分析建模方法，要按照数据实体的不同功能和来源进行分类和分层，分析抽象出最原子、最底层的数据实体，对每一种数据实体要描述清楚其局部模式和全局模式之间的映射关系。新的数据模型将以全新的体系结构图开始，是系统内所有数据实体从各个角度的描述，是对数据实体服务的描述。
数据实体服务层向上发布其元数据信息，提供的是较低层的、细粒度的数据服务。
数据聚合服务层：基于数据实体服务层，按照某个部门或特定业务领域制定的某种聚合策略，建立聚合服务模型。
每个聚合服务对应唯一的一种聚合策略，有唯一的全局标示。对每个聚合服务的描述，包括其标识、种类、功能、聚合策略和该聚合服务向下层服务的映射和转换模式，也包括对服务接口的定义。每种聚合服务可以对应到任意多个数据实体服务的组合，也可以对应到数据实体服务和底层聚合服务的混合组合，也可以是多个子聚合服务的再组合。当聚合服务被调用时，聚合服务模型把服务调用映射、转换到各数据实体服务或底层子聚合服务，生成服务的实例，并与这些服务进行交互。
那么按照这样的思路，就可以把整个设备管理系统归类划分。每个功能作为一个通用性聚合策略，利用业务服务聚合层控制用户权限，按设备管理系统规划的控制程度给予不同用户相应权限，基于定立的通信标准连结各个功能模块，并在复合应用层与用户交互。有效设置即可解决第一个问题。至于第二个问题其实只需在数据聚合层通过聚合策略按约定规则存储时把业务数据解散耦合分离为结构数据、实例数据、抽象结构分别按策略规则存储，读取时按策略规则读取抽象结构，根据结构数据建立视图，最后填充实例数据，这样就能解决。兼容性、稳定性、安全性的保障体现在策略规则的定义上，所以策略规则的定义必须全面、规范、严谨，而且要多方面考虑以及顾全。
本文针对设备类型的单一、参数定义的死板、不同项目间通用性不强这几个问题来探讨一下具体解决方案的思路与实施，讨论衍生几个设计理念。
一、结构式与列表式设备类型模式以及类型参数的扩展性
以往的设备管理软件中，设备类型、类型参数基本都是在软件开发之前已经调研后定义好，开发过程中根据定义的数据进行数据库设计、程序代码设计。软件使用过程中，并不能再更改。假如要更改，必须由开发人员重新更改数据库以及软件代码等等，涉及的工作十分的复杂。
传统的列表式数据设计中每一个设备类型就需要使用一个数据库表结构、一个处理模块、甚至一套从录入到输出以及变更调整等等的一系列程序代码来支持。
传统的设备管理在使用过程中是非常缺少灵活性与机动性的，现代企业改革创新过程中已经失去活跃周期，有些更甚至失去软件存活意义。
各种泵机、阀门、油管、油管等等设备的参数、属性、组成结构是一样的吗？答案显然是否定的。即使，按照现有的设备进行来定义，设计若干个数据表与处理程序，就可以保证适用性了吗？答案也是否定的。在软件的使用过程中，如果新增了没有的设备或者从根本改变了设备的类型，那传统软件是否适应？答案亦是否定的。
那么怎么具体实现动态的、结构式的设备类型以及类型参数呢？
这次的项目，笔者针对这样的情况采用了非定式数据库以及程序代码模式。所有设备类型均可以在程序使用过程中再进行定义、扩展。只要具有权限的用户，就能更改全部以框架式设计的数据结构。把所有有关设备类型、类型参数的程序进行结构化设计。包括设备类型、类型中所包含的参数和属性内容。使用中改变不对系统稳定性产生影响，不需停机，不需更新软件，实时更改设备类型、类型的参数、属性、结构。
框架中可以将设备作2部分组成，一部分就是设备的结构数据，令一部分就是实例数据。相同类型的设备，结构数据是相同的，只是实例数据有差异而已。传统的软件中，把结构数据表单化了，一个数据表的结构只能存放一个类型设备的数据。本项目软件中，并不把设备结构表单化，而是记录化，通过大家的处理模块把设备结构作为数据来进行存储。调用经过程序再从把记录转成结构。
在这次的项目开发中，笔者使用的数据处理模式以及程序处理模块都是框架式的，与以往其他类似程序上结构有很大的区别。那么究竟是利还是弊，大家现在来做个对比。
通过这样的处理模式，就可以从实现设备类型动态存储，结构上解决设备类型差异性引发的兼容性问题，以及设备类型更替等适应性问题等等。
在软件使用过程中，报表的应用格式改变或者报表的申报流程改变，也跟刚才所述的同样问题困扰着传统报表设计人员。解决这个问题也同样应用了类似的方法。
二、不受限制的级别模式-树形关联模式。
以往的设备管理系统中，约定的类别或设备级别基本是不可更改的。往往是在设计时就定义几个主要的设备进行延伸一定的子设备（一般3-5层），定义以后就不可更改了。传统设计中，设备的上级关系或下级关系是设备类型，这样的关联性设计往往是缺乏灵活性的。例如，原来全部外浮顶罐中使用了某类型的雷达探头，一段时间后，某部分罐更换的其他类型的探头，用传统的软件，那就难以适用了。
传统的软件中，设备类型基本是不分级别的，实际使用中，分类太少就经常导致数据混乱，容易模糊不清，如果分太细致，又难统计跟查询数据，无法有效管理。
这次的项目中，利用无级树形设备关联模式，用户自己能够去定义任何设备间的层次级别。类似于大家常用的WINDOWNS中的文件夹设计那样，不论设备类型、不论设备级别，都可以设置它的所属对象，即时大到使用单位整体、细致到螺丝都能够实现。把设备类型和实例设备都作为对象处理。实例对象的上级关系可以对应的是另一个实例对象。设备类型上级关系可以对应另一个设备类型。根据这样思路去设计就增强了灵活性，使得适用性更广更强，更可以满足实例跟结构不同查询方式。这样的设计更加便于调整，设备关系清晰明确，类型关系有条不紊。同类设备间下级设备差异性问题也能很好的解决，加强设备的独立性，同时也加强了设备互相间的协作性。
综上所诉，利用无级树形设备关联模式，是设备对象组别管理最为科学的分组以及分级管理模式，多元化的关联系，多种模式的查询以及分组、分级功能更是能让使用者更容易适应。同时分组分级的权限管理模式也让设备权限管理更加有条不紊，避免重叠、交叉设置，管理效率大大提升。
三、总线以及模块通信链路简介
系统平台能作为一个通用性聚合策略，利用业务服务聚合层控制用户权限，按设备管理系统规划的控制程度给予不同用户相应权限，基于定立的通信标准连结各个功能模块，并在复合应用层与用户交互，细致严谨的架构设计更不能缺乏。
