在工程公司，各种设计软件、管理软件众多，且来源于不同软件商，彼此独立，数据格式差异大，数据流通难，彼此隔绝形成信息孤岛。现在解决数据流通主要方式有两种，一是建立（建立方式是购买或者自主开发）各软件之间的接口；二是以某一平台软件为基础，建立各软件与平台的接口。
接口的操作从软件层面上看，就是软件进程之间的通讯，常用的方式有大致有三种，一是使用套接字进行网络通讯，二是使用套接字或者命名管道来进行进程间通讯，三是使用文件来交流信息。虽然方式不同，但通讯或者交流内容都差不多，就是某种格式的数据流，在实际使用中，第三种方式应用更加广泛，以下统一使用第三种方式来进行叙述。
1、两种数据流通方式的经济型分析
软件A和B，分别接收格式为a和b的文件，实现软件A数据导入B,需要在A中建立生成格式b的接口，为叙述方便简洁标记为Ab，同理建立接口Ba就可以实现软件B数据导入A。
如果有软件S1，S2，S3……Sn，达成数据一一数据流通，采用第一种方式所需要的接口数量C1为：
C1=2×(n-1)!
采用第二种方式所需要的接口数量C2为：
C2=2×n
当n≤3时，C1≤C2，n＞3时，C1＞C2。
化工行业软件众多，数量肯定是大于3，所以采用第二种数据流通方式无疑是最有利的。
2、当前存在的基础平台
目前能够提供平台的厂家有三家，分别是Intergraph、AVEVA和西门子，都具有同样的局限性，其一是仅能覆盖部分软件，要求各部门和专业推行该公司的设计及管理软件，仅能构建单一的软件环境，一旦脱离了该公司设计软件，平台本身毫无意义。其二是虽然三个软件平台都具有开放性接口，但开发成本很高，目前很少有外部公司软件接入平台。其三是维护成本很高，尤其是Intergraph的SPF，采用WindowsServer+IIS+SQL/Oracle+.Net构架，要求维护人员具有计算机专业背景。
3、现状
当前的现状是两种数据流通方式共存，造成这种现状的原因是其一三家平台软件商不能也不可能提供所有的设计和管理软件，其二即使某平台软件商提供了某专业的设计软件，也可能不是最优的选择，各软件公司都有自己的强势产品，比如Intergraph有CSII、SPPID、SPMATL，AVEVA有PDMS和E3D等等，用户是希望采用有优势、自己长期使用有经验积累的产品，不希望被局限在某一个软件商的指定范围内。
当然还有很多软件是没有建立流通方式的，这也是现状之一，是行业和工程公司急需解决的问题，也是协同设计的被重视的原因。
4、行业软件标准接口
如果将平台软件化实为虚，变成一种统一的文件数据接口格式，作为公司或者行业的标准接口，面向各个设计和管理软件开放，将会有效解决所有数据流通问题，这也是国际上通用的解决软件之间数据流通的方式，比如STEP格式就是为了解决各大三维软件模型数据流转而建立的标准，标准号是ISO-。
建立统一的行业软件标准接口，对软件商、工程公司和工厂等各方都是非常有利的。对于软件商，仅需要开发针对标准接口格式的输入和输出两个接口就可以满足与业内所有软件的数据流转，大大降低了开发成本；对于用户，可以自由选择有利的软件，无需担心数据流通问题，无需购买多余接口，降低采购成本；对于软件维护人员，维护成本极大降低，仅需要理解标准接口文件格式即可，不需要考虑本软件与其他软件的关系；对于工厂数字化交付，不论是采用Intergraph、AVEVA或者其他平台，工程公司和其业主都无需被软件商绑架，必须采用指定的设计软件。
建立统一的行业软件标准接口，对于整个化工行业和化工软件行业的健康发展也是有利的，当前业内国外软件已呈垄断之势，国内软件商都是在夹缝中生存。国外软件商一旦垄断，慢慢侵蚀其他设计和管理软件的生存空间，放任其一家独大，整个行业和各工程公司都会失去话语权。行业内的国产工业软件处于萌芽状态，需要被引导和保护，行业软件标准接口的建立有利于国内软件商组成一个整体，提升工程行业的运行效率，减少因为数据格式差异壁垒带来的内卷，也有利于构建多样化的生态，以抵抗垄断性的单一的生态环境。
综上，建立行业软件标准接口是有实际需求的，也是有前瞻性，是能带来化工行业整体效率提升和行业健康发展的有利措施。
5、行业软件标准接口建立的可行性
目前数字化交付已经成熟了应用到很多工厂，数字化交付的广泛应用从侧面证明得了软件标准接口的可行性。数字化交付包含对象的识别及分类，关系的描述，属性的承载，软件标准接口所需要描述的就是对象、关系、属性这三点。
6、可扩展标记语言
可扩展标记语言xml是一种良好的承载和传递信息的结构化的标记语言，发布于年，广泛应用于计算机技术的各个领域，对人而言具有良好的可读性，对计算机而言，具有很强描述功能。举例如下：
note
date
day12/day
month01/month
year/year
/date
toGeorge/to
fromJohn/from
headingReminder/heading
bodyDontforgetthemeeting!/body
/note
上面的内容承载了一份便条的信息，包含发送方、接收方、传递信息内容和时间，可见其良好的可读性。Xml语言也具有较好的容错率，当出现多余内容，计算机程序能够很好的过滤掉，不致使程序奔溃。
7、VNet和SPF中对象、属性及关系的描述
数字化交付从侧面验证了软件标准接口的可行性，那么在数字化交付平台中是如何描述对象、属性及关系，现从两个知名的数字化交付平台来分析，分别是Aveva的VNet和Intergraph的SPF。
AvevaNet中的对象表达
Object
IDJ-A/ID
ClassIDPUMP/ClassID
Context
IDIPE/ID
/Context
NamePump-J-A/Name
Characteristic
NameDescription/Name
Value循环水泵/Value
/Characteristic
Property
NameWeight/Name
Value2/Value
Unitst/Units
/Property
Associationtype=”isreferencedin”
Object
ID/ID
/Object
/Association
/Object
上面表达的是，存在一个对象，其ID为J-泵，ClassID为Pump，Context（背景，可以设置为某个具体工厂）是IPE，Name为Pump-J-A，存在一个Characteristic（特性），Name为Description，Value为循环水泵，存在一个Property（属性），Name为Weight，Value为2，Units为t，存在一个Association（关系），其类型为isreferencedin（被引用），关联对象的ID为。
SPFoundation中的对对象的描述如下：
SPFCDWEquipment
IObjectUID="cc-d4d6-48e1-d-9b"
Name="T-"
Description=""
ContainerID=""/
ISPFCDWObject/
ISPFCDWEquipmentPI/
ISPFCDWEquipmentSPFCDWEqType2="EE7A8"
SPFCDWEqType3="EE7B0"
SPFCDWEqType0="{47BF-DD41-4E1A-9B41-C4BC8FF92}"
SPFCDWEqType1="EE"
SPFCDWEqTypeDescription="1diameter,1chamber,ellipticalheadtower"/
/SPFCDWEquipment
Rel
IObjectUID="99VA"
ContainerID=""/
IRelUID1="cc-d4d6-48e1-d-9b"
DefUID="SPFTEFComprisedOf"
UID2="FFC48EFACBF7E9EFBE2D"/
/Rel
上面表达的是，存在一个SPFCDWEquipment对象，该对象拥有接口IObject（为了区分于本文标题中的接口，将此接口命名为属性接口），该接口中包含属性UID，其值为"cc-d4d6-48e1-d-9b"，属性Name，其值为"T-“……拥有接口ISPFCDWObject、ISPFCDWEquipmentPI……该对象存在一个Rel（关联关系），关联关系拥有接口IObject和IRel，IObject就不介绍了，IRel包含属性UID1、DefUID、UID2并有具体赋值。
通过上述对比可以看出，VNet的表达可读性稍好一些，但是SPF接口的引入有很好的可扩展性，接口本身不作为内容，而作为内容的修饰。在进行软件标准接口编制时，可以参考这两个软件的格式及描述方法。
8、事物关系的划分及属性接口引入的必要性分析
人类通过分析事物的同和异来认识事物并进行划分归类，将具有相同特性的划分在一个体系，同体系下不同的事物再划分为子体系，比如物种，常使用界、门、纲、目、科、属、种来逐层划分。计算机对客观世界的描述是建立在人类对世界的认知经验上，为了表述客观世界同样引入了这个体系，以类、子类表达这种关系，称之为继承。早期的计算机语言，比如C++是包含多重继承，多重继承的概念就是某个子类既包含父类1特征，也包含父类2特征，比如定义飞机这个类，继承了机械装置和飞行物这两个父类，既是机械装置又是飞行物。后来的JAVA和.NET放弃了多重继承，引入了接口，接口包含方法的定义，但不包含方法的实现，本身不能去实例化一个对象。接口把通用行为抽离出来供多个类使用，定义一个飞行的接口，飞机、飞鸟、飞虫虽然类别上差距很大，都可以继承这个接口。例如对飞行距离和时间关系进行编程时，就可以直接使用这个接口来处理。
属性接口与计算机编程中的接口定义是有区别的，但对客观世界描述的目的是一样的，属性的获取和设置本身也是一种方法和行为。虽然在软件标准接口中的作用不大，但是为了考虑后续功能的扩展，是有必要建立的，尤其是用于搜索的时候，可以直接对属性接口进行查找，找到所有实现了该属性接口的对象，比如搜索所有温度、压力在某个范围的对象，不限于设备、管道、仪表，我们就可以定义一个IProcess属性接口，查询IProcess就可以搜索到实现了此接口的对象。
9、软件标准接口的建议方案
综合前面几条叙述，一个完整的行业软件标准接口的方案需要清晰的表述对象的各项属性及对象与对象之间的关系，在此给出以下建议方案。
9.1属性的实例化
属性是最基本的元素，其实现的基本格式如下：
NameV-/Name
对于某些有特殊要求的属性，可以采用属性修饰的方法来实现，比如温度，可以采用如下格式：
DesignTemperaturetype="dimension"
Value0/Value
UnitDegree/Unit
/DesignTemperature
对于位置信息，可以采用如下格式：
StartPositiontype="position"
X0/X
Y0/Y
Z0/Z
/StartPosition
9.2接口的定义和实例化
在软件标准接口里，必须得对接口的定义进行细致的规定，比如定义一个IProcess的接口和ILine3D的接口，格式如下：
IProcess
DesignTemperaturetype="dimension"/
DesignPressuretype="dimension"/
Fluid/
/IProcess
ILine3D
StartPositiontype="position"/
EndPositiontype="position"/
/ILine3D
这两个接口实例化的格式如下：
IProcess
DesignTemperaturetype="dimension"
Value40/Value
UnitDegree/Unit
/DesignTemperature
DesignPressuretype="dimension"
Value3.5/Value
UnitMPa/Unit
/DesignPressure
FluidPG/Fluid
/IProcess
ILine3D
StartPositiontype="position"
X0/X
Y0/Y
Z0/Z
/StartPosition
EndPositiontype="position"
X/X
Y/Y
Z/Z
/EndPosition
/ILine3D
9.3类的定义和实例化
标准接口中应对常见类进行定义，以下是Object、Equipment和Vessel的定义格式：
Object
IObject/
/Object
Equipment
IObject/
IProcess/
IEquipment/
/Equipment
Vessel
IObject/
IProcess/
IVessel/
IEquipment/
/Vessel
Vessel中引用IEquipment接口，也是实现了一种继承关系，一个Vessel也是一个IEquipment，如果以IEquipment作为接口去查询，Vessel应被包含在搜索结果中。
类实例化对象，就是接口中属性的实例化，如实例化一个3DLine：
Line3D
IObject
UID***/UID
ID***/ID
Name***/Name
Description***/Description
Context***/Context
/IObject
IGeometry/
ILine3D
StartPositiontype="position"
X0/X
Y0/Y
Z0/Z
/StartPosition
EndPositiontype="position"
X/X
Y/Y
Z/Z
/EndPosition
/ILine3D
/Line3D
9.4关系的定义和实例化
关系应该作为一种特殊的对象存在，应当被提前定义好，其定义的内容包括关系的类型，关系双方的对象类型。
关系的实例化格式如下：
RelationShip
IObject
UID***/UID
ID***/ID
Name***/Name
Description***/Description
Context***/Context
/IObject
IRelationShip
UID1***/UID1
UID2***/UID2
Type***/Type
/IRelationShip
/RelationShip
LeeKey