CN104240017A - 一种城市轨道交通线网联网管理的方法 - Google Patents

Abstract

本发明涉及一种城市轨道交通线网联网管理的方法，包括以下步骤：对城轨线网执行业务建模操作，获得业务模型的信息关系图，从信息关系图中提取城轨线网的对象类；比较分析既有城轨线路的数据库表、数据点表和文档资料，提取出城轨线路的对象类集合；以城轨线网的对象类为导向，从城轨线路的对象类集合中提取城轨线网的数据元；设定城轨线网的数据元的属性值，划分同组数据元，命名城轨线网的数据元；根据预设的城轨线网数据库的命名规范，命名城轨线网数据库中的数据库对象，建立城轨线网数据库。本发明针对城市轨道交通行业数据元不统一的现象，解决了各线路标准各自为政、共享困难等问题，提高城轨数据标准的可扩展性及可用性。

Description

一种城市轨道交通线网联网管理的方法

技术领域

本发明涉及数据库、数据资源整合技术领域，尤其涉及一种城市轨道交通线网联网管理的方法。

背景技术

城市轨道交通具有运量大、速度快、准时可靠、环境舒适等特点，经济发达国家城市的交通发展历史告诉我们，只有采用大客运量的城市轨道交通系统，才是从根本上改善城市公共交通状况的有效途径。

目前，城市轨道交通的大规模规划和建设说明国家充分认识到城市轨道交通的重要地位，但是仅从工程上规划建设还远远不够。在城市化，信息化加速发展的时代，城市人口日趋增多，交通严重堵塞，事故频发，急需通过信息技术解决现有的交通问题，促进现有信息资源的利用、共享和增值。

由于城市轨道交通行业缺乏相应的国际标准及国内标准，因此利用信息资源共享来改善城市轨道交通现状并非易事。我国现有城市轨道交通系统存在如下问题：各线路自主招标、建设，采用“线路管控”管理方式，只考虑当前线路的数据存储，运营和监管问题，导致线路数据标准不统一；在调度方面，各线路单独调度，线与线间的运营无法协调且无法统筹全局，导致城市轨道交通缺乏全局性的调度指挥能力。

线网的功能是统筹监控和综合管理线路数据，提供应急指挥功能，协调各线路运力，为新建线路提供标准。线网统筹兼顾各线路，其数据需要从线路中获取。但目前线路数据内容和数据编码方式不统一，阻碍线网直接利用既有线路数据，实现上述功能。因此，建立城市轨道交通线网数据标准是建设城市轨道交通线网数据中心的重要基础。

目前在运输行业，陈琪明撰写的(国标《道路、水路货物运输基础数据元》的研究和制定)针对物流信息化与物流企业对于道路、水路货物运输的实际需求，经过收集、分析与研究，提取道路、水路货物运输业务活动过程中信息化和地理信息所需的、基本的数据元编制和制定了该行业的数据标准。为了提高信息技术行业内部的数据共享，信息技术标准对整个软件开发生命周期中数据的检索、交换和一致性使用进行了规范。同时定义具有规范意义和形式的信息单元称为已标准化数据元。在规范化的过程中，定义了数据元、数据元分类、数据元的基本属性、数据元编写规则和数据元命名规则等相关内容。在电子政务行业，电子政务数据元的提取分为两大步骤，一是数据元的提取，二是对具体数据元提取其属性。在对业务流程分析的基础上，利用业务流程建模获得电子政务业务的主导方和相关参与方，并确定业务的实施细则，进行数据元的抽取。

上述行业都提出了相应的数据标准建立方法，但有异于其它行业，城市轨道交通存在线网和线路的概念，且这两种概念具有层次关系。由于其它行业内部并无层次关系，因而可以仅从业务分析得到其数据标准。但对于城市轨道交通行业，线网的数据是以线路的数据为基础，所以忽略线路数据而仅从线网业务分析角度建立数据标准的方法不能满足需求。在线网的数据标准建立过程中，需要吸纳现有线路系统的数据元及其属性。同时，城市轨道交通线网和线路都包括多个专业，数据标准的建立方法需要适合各专业。不解决兼容性的问题，就导致整个城市轨道交通无法正确地联网，不能对整个城市轨道交通进行合理化的规划和必要的调控。

发明内容

本发明的目的，旨在解决各线路标准各自为政、共享困难等问题，提高城轨数据标准的可扩展性及可用性，结合城市轨道交通自身特点，针对城市轨道交通行业数据元混乱、无法兼容的问题提供一种城市轨道交通线网联网管理的方法。

为了达到上述目的，采用如下技术方案：

一种城市轨道交通线网联网管理的方法，包括步骤一至步骤五：

步骤一、利用软件工程的需求分析流程对城轨线网执行业务建模操作，获得业务模型的信息关系图，从信息关系图中提取城轨线网的对象类；

步骤二、比较分析既有城轨线路的数据库表、数据点表和文档资料，提取出城轨线路的对象类集合；

步骤三、以城轨线网的对象类为导向，从城轨线路的对象类集合中提取城轨线网的数据元；

步骤四、设定城轨线网的数据元的属性值,根据属性值,划分同组数据元,命名城轨线网的数据元；

步骤五、根据预设的城轨线网数据库的命名规范，命名城轨线网数据库中的数据库对象，建立城轨线网数据库。

进一步地，所述从信息关系图中提取城轨线网的对象类包括以下步骤：

利用软件工程的需求分析流程，构建城轨线网中包括乘客信息显示系统、电力监控系统、防淹门系统、广播系统、环境与设备监控系统、火灾报警系统、列车信息系统、门禁系统、屏蔽门系统、视频监控系统、信号系统和自动售检票系统的各专业系统的系统结构图、系统实现图、系统时序图和数据流图；

获取各专业系统中输入输出信息以及输入输出信息之间关系的信息关系图；

从信息关系图中提取城轨线网各专业系统的对象类。

进一步地，所述步骤二包括以下步骤：

分析既有城轨线路的现有数据库表、数据点表和文档资料，提取出城轨线路的对象类集合；

比较既有城轨线路的现有数据库表、数据点表和文档资料的同种对象类的数据元；

根据同种对象类的不同数据元，设定城轨线路中同种对象类的数据元集合。

进一步地，所述步骤三包括以下步骤：

从城轨线网的对象类集合中，提取指定的对象类；

查找城轨线路的中该指定的对象类对应的数据元；

以该指定的对象类对应的数据元作为城轨线网的数据元。

进一步地，所述步骤四包括以下步骤：

根据数据元标识符分配规则、数据元命名规则、数据类型、数据元值域、数据元备注、默认值、报警值和报警等级，设定城轨线网数据元的属性值；

根据属性值,划分同组数据元,命名城轨线网的数据元。

进一步地，所述预设的城轨线网数据库的命名规范包括，数据库对象的名称采用26个英文大写字母和数字0-9，加上“_”的任意组合组成；数据库对象的名称由前缀和实体名称组成，长度小于或等于30个字符，前缀描述对象的类型，实体名称包含描述实体内容的信息的数据库标识，数据库对象的名称各组成部分用“_”分隔。

进一步地，所述数据库对象包括数据表、数据字段、主键约束、外键约束、check约束、索引、视图、触发器、函数和存储过程，所述数据表的命名格式为，TB_数据库标识_表标识；所述数据字段的命名格式为，表标识_字段标识；所述主键约束的命名格式为，PK_主键表标识_主键字段标识；所述外键约束的命名格式为，FK_外键表标识_主键表标识_主键字段标识；所述check约束的命名格式为，CK_约束表标识_约束字段标识；所述索引的命名格式为，IN_索引表标识_索引字段标识；所述视图的命名格式为，VI_视图标识；所述触发器的命名格式为，TR_触发器标识；所述函数的命名格式为，FN_函数标识；所述存储过程的命名格式为，SP_存储过程标识；以上数据表除外的命名格式中，如果表标识的长度大于15个字符，采用表标识的缩写，缩写形式为各语义单词的首字母。

进一步地，所述步骤五包括以下步骤：

对城轨线网数据库中的设备类型表、子系统表、车站表、线路表、设备表、设备属性取值类型表和设备属性表的主键字段建立索引；在城轨线网数据库中设备属性取值表中增加表示线路字段，并按线路字段对设备属性取值表分区；对设备属性取值表中的设备字段和设备属性字段建立联合索引，并建立设备字段和设备属性字段的唯一约束。主键字段就是数据库主键，唯一地标识数据库表中的每一行。与其它字段的关系是唯一标识本行其它字段的内容。建立唯一约束可以保证在设备属性取值表中，每一条记录的设备字段和设备属性字段的组合都是独一无二的。

与现有技术相比，本发明的有益效果在于：

本发明结合城市轨道交通自身特点，针对城市轨道交通行业数据元不统一的现象，解决了各线路标准各自为政、共享困难等问题，提高城轨数据标准的可扩展性及可用性。本发明的另一个特点在于使用自顶向下业务分析结合已有线路数据元，在兼顾线路的现有情况的前提下，体现了线网数据标准的特点。

附图说明

图1是本发明所述城市轨道交通线网联网管理的方法的步骤流程图；

图2是本发明所述城轨线网数据标准系统框图；

图3是本发明实施例的广州城轨线网广播专业系统的业务建模实施过程示意图；

图4是本发明实施例的广州城轨线网广播专业系统的功能结构图；

图5为本发明实施例的广州城轨线网广播专业系统的系统实现图；

图6为本发明实施例的广州城轨线网广播专业系统的系统时序图；

图7为本发明实施例的广州城轨线网广播专业系统的数据流图；

图8为本发明实施例的广州城轨线网广播专业系统的信息关系图；

图9为本发明实施例的广州城轨线网数据元的提取流程图；

图10为本发明实施例的广州城轨线网数据元的属性模型图；

图11为本发明实施例的广州城轨线网数据库对象的E-R图。

具体实施方式

下面将结合附图以及具体实施方法来详细说明本发明，在本发明的示意性实施及说明用来解释本发明，但并不作为对本发明的限定。

鉴于城市轨道交通线网由城市轨道交通多条线路及其多个专业系统组成，本方法包括层次型业务模型、数据元层和技术层。

层次型业务模型：在线网层次提取城市轨道交通线网的对象类，同时在线路层次建立城市轨道交通线路的数据元标准。

数据元层：以城市轨道交通线网的对象类为导向，从城市轨道交通线路的数据元标准中提取城市轨道交通线网的数据元，进而规范城市轨道交通线网的数据元的属性，获得城市轨道交通线网的数据元标准。

技术层：采用统一的命名规范命名数据库建设过程中各阶段涉及的数据库对象，进而采用线网查询效率优化的原则建立城市轨道交通线网的数据库。

数据元是通过定义、标识以及允许值等一系列属性描述的数据单元，一般由对象类、特性和表示三部分组成。其中，城轨线网的数据标准指城轨线网数据元的标准，城轨线网的数据元指城轨线网控制中心实时监视的各专业系统的设备的属性，城轨线网数据元的对象类指城轨线网控制中心实时监视的各专业系统的设备和服务器状态等。

本发明方法的整体流程如图1所示，包括步骤S101-步骤S105。

如图2所示，城轨线网数据标准包括自动售票检票系统、环境与设备监控系统、屏蔽门系统、广播系统、电力监控系统、信号系统、火灾报警系统、门禁系统、视频监控系统、防淹门系统、乘客信息显示系统和列车信息系统等各个专业系统。

步骤S101：利用软件工程的需求分析流程对城轨线网执行业务建模，获得业务模型的信息关系图，从信息关系图中提取城轨线网的对象类。对象类指业务上关联的具体的实体对象，如自动售票机等；数据库对象指具体的某一数据信息，如自动售票机的运行状态等。

步骤S101所述城轨线网的对象类通过以下方法获得：通过软件工程的需求分析方法，如图3所示，逐步构建城轨线网各专业系统的系统结构图、系统实现图、系统时序图、数据流图，对系统时序图的交互数据和数据流图的输入输出信息进行细化和扩充，从而获得信息关系图，并从信息关系图中提取城轨线网的各专业系统的对象类。对象类指城轨线网控制中心实时监视的各专业系统的设备和服务器状态。提取对象类，即提取城规线网中各专业系统的设备和服务器的状态。

图3为广州城轨线网广播专业系统的业务建模实施过程。业务建模包括业务分工、业务流程和业务信息三部份。其中业务分工包括系统结构图和系统实现图，业务流程包括系统时序图，业务信息包括信息关系图和数据流图。以广州地铁的广播系统为例，如图4所示，广州地铁的广播系统结构图包括线网级广播系统、线路级广播系统、车站级广播系统和车辆段级广播系统。

广播系统(PA)主要用于对乘客进行公告信息广播，发生灾害时兼作防灾广播、对乘客进行安全疏散引导，以及为运营管理及维护人员播发有关信息等。为了分析广播系统的业务，了解系统内设备交互以及数据流向情况，需要对整个系统进行业务建模。建模的过程是现有技术，此处不赘述。这里使用系统结构图、时序图、数据流图和信息关系图逐步对业务进行分析。

从图4的功能结构图中可以看到广播系统由四部分组成：

第一部分是线网级广播系统，通过城轨内部骨干网与各线路控制中心局域网连接，对整个线网的广播系统进行监控管理。

第二部分是线路级广播系统，通过城轨内部骨干网与车站局域网连接，为总调、行调和环调的中心调度人员提供广播操控功能，实现全线车站的广播功能和监控管理工作。

第三部分是车站级广播系统，负责车站内部的广播功能以及广播系统设备的管理工作，可接收控制中心对车站的广播。

第四部分是车辆段广播系统，实现值班员和现场工作人员对车辆段播音区的广播，车辆段广播系统为独立广播系统，受车站级ISCS(综合监控系统)的控制，但其主要设备状态和报警信息通过ISCS网络直接传送到控制中心广播系统。

图5中包含了广播系统中的各部分之间的多个交互过程，这些交互过程是相互独立的。

当线网级广播系统需要对车站进行话筒广播和广播监听时，控制指令由线网级广播系统、线路级广播系统、车站广播系统逐级传送，最终在车站执行广播或将监听信息和车站级广播系统工作状态逐层向上传送给线网级广播系统。

当线路级广播系统需要对车站进行话筒广播和广播监听时，控制指令由线路级广播系统、车站级广播系统逐级传送，最终在车站执行广播或将监听信号和车站级广播系统工作状态逐层向上传送给线路级广播系统。

当车辆段需要进行话筒广播和广播监听时，控制指令由相应车站的广播系统传送给车辆段广播系统并执行，然后将执行结果和车辆段广播系统的工作状态传送给车站广播系统，并将相应的操作记录逐级传送给线路广播系统和线网广播系统进行记录。

车辆段广播系统为独立的广播系统，其主要设备状态和报警信息通过主干网传送给线路级广播系统和线网级广播系统。

图6的系统实现图用于描述系统的内部实现。根据广播系统的内部结构，下面对其中四部分进行说明：

线网级的广播系统主要由分设于总调、行调和环调内的3套后备广播控制盒、与TCC的工作站广播控制功能配套的3套话筒前级、广播机柜组成，其中广播机柜内主要包括广播系统线网主控制模块、音频前级处理模块、音频切换矩阵、网络接口模块。线网控制中心数据库(Traffic Control Center，简称为TCC)。

线路级的广播系统主要由分设于总调、行调和环调内的3套后备广播控制盒、与线路控制中心(简称为OCC)的工作站广播控制功能配套的3套话筒前级、广播机柜组成，其中广播机柜内主要包括广播系统线路主控制模块、音频前级处理模块、音频切换矩阵、网络接口模块。

车站级的广播系统由1套备用广播控制盒、与车站工作站广播控制功能配套的1套话筒前级、广播机柜、扬声器网络及噪声传感器组成，其中广播机柜内主要包括广播系统车站主控制模块、音频前级处理模块、音频切换矩阵、主备功率放大器、输出分区控制器、网络接口模块。

车辆段的广播系统车辆段广播系统设备由1套广播控制盒、广播机柜、扬声器网络组成，其中广播机柜内主要包括广播系统车辆段主控制模块、音频前级处理模块、音频切换矩阵、主备功率放大器、输出分区控制器、网络接口模块。

图7为广播系统的数据流图。数据流图是结构化系统分析方法的主要表达工具，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程。

如图7所示，线网TCC工作站发出控制指令并传送到线路级别的广播系统，各线路主控制模块识别指令的类型、进行优先级别的判断，如果优先级允许则将向车站级别的广播系统发送控制指令，如果优先级别不允许，则向TCC工作站返回线路广播系统的工作状态；当车站广播系统接收到线路的控制指令，首先车站的主控制模块识别指令的类型、进行优先级别的判断，如果优先级允许则交给扬声器网络模块和监听模块执行相应的话筒广播命令和监听操作，并逐级向上返回执行的结果并分别在车站、线路和线网进行操作的记录存档；如果优先级别不允许，则逐层向线路级和线网级返回车站广播系统的当前工作状态，并在各级记性操作记录。

图8为信息关系图。信息关系图描述各系统包含哪些输入输出信息以及输入输出信息之间的关系。通过对广播系统时序图中的交互数据和数据流图中的输入输出信息进行细化、扩充，得到广播系统的信息关系图。如图8所示，广播系统相关信息包括调度员信息和监控信息，调度员信息包括TCC调度员(线网级)、OCC调度员(线路级)和车站调度员(车站级)，他们拥有不同的调度权限；监控信息包括线网中心与线路中心通信状态、线路中心与车站/车辆段通信状态、车站广播模块、车站广播系统故障、车站广播系统故障以及线路后备广播控制盒等。

S102：比较分析既有城轨线路的数据库表、数据点表和文档资料，提取出城轨线路的对象类集合。提取对象类集合就可以建立城轨线路的数据元标准。

数据库表中存储了城轨线路中包含的设备的信息，例如设备的编号、设备的类型、设备所处的车站、设备所在系统等；所有设备的属性取值信息，例如属性的所属设备、属性取值的数据类型、属性的取值等；城轨线路包含的设备的属性种类，例如属性种类的编号、属性种类的名称等；城轨线路包含的车站信息，例如车站的编号、车站的名称等；城轨线路包含车站的信息，例如车站的编号、车站的名称等；城轨线路包含的系统信息，例如系统的编号、系统的名称；文档资料指城轨线路业务相关的各个系统的设计文档，包括系统的功能介绍、系统的架构、系统的设备部署以及系统的工作原理等信息。

步骤S102具体包括以下步骤：

S1021：分析既有线路的现有数据库表、数据点表和文档资料等，提取出城轨线路的对象类集合。

对象类的提取：线路的数据点表中记录了线路中每个车站每个系统包含的设备信息，包括设备的名称、设备的属性等信息，但是车站之间的设备信息存在诸多的不一致，需要结合数据表中设备的相关记录、系统设计文档中的功能需求、系统的设备部署以及工作原理等信息，提取出线路中所有设备的集合，即为对象类集合。例如，6号线的自动售检票系统的对象集包括自动售票机、票房售票机、验票机、进闸机等。

S1022：比较既有城轨线路的现有数据库表、数据点表和文档资料的同种对象类的数据元。

例如线路1的设备A有A1、A2、A3、A4、A5共5种属性，而在线路2上的设备A有A1、A2、A6、A7共4属性，则设备A的数据元有A1、A2、A3、A4、A5、A6、A7共7中属性。比较既有城轨线路的现有数据库表、数据点表和文档资料的同种对象类的数据元就是分析不同线路上的数据库表、数据点表和文档资料记载的相同设备是否有属性上的差异，找出并集，作用是为了在建立城轨线路的数据元标准时，可以确定同种对象类具有何种数据元。

S1023：根据同种对象类的不同数据元，设定城轨线路中同种对象类的数据元集合。设定城轨线路中同种对象类的数据元集合后，就可以建立城轨线路的数据元标准。

针对广州城轨已有线路的数据点表，统计出每个专业系统包含的对象类集合。不同线路的数据元存在不一致的情况，主要包括如下四种情况：

(1)部分对象类采用中文拼音缩写的方式编码,部分对象类却采用英文缩写的方式编码；

(2)同种对象类，在不同线路的数据元集出现子集和超集的关系；

(3)同种对象类，在不同线路的数据元集各不相同；

(4)对象类的中文名称相同，但对象类的编码不同。

针对上述四种情况，采取如下处理方法：

(1)针对第一种情况，所有对象类统一采取英文名称缩写的方式进行编码，具体编码方式为取对象类英文名称中每个单词的首字母作为对象类的编码，如果发生了编码冲突的情况，采用增加顺序码的方式来解决冲突。

(2)针对第二种情况，取该种对象数据元的并集作为对象类的数据元集。

(3)针对第三种情况，通过查看数据点表中数据元的解释信息确定名称不同的数据元是否指同一种数据元，如果是同种数据元则取相对规范的其中一种数据元名称作为数据元的名称；反之，将其作为两种不同的数据元处理，并最终确定该种对象类的数据元集。

(4)针对第四种情况，如果对象类的数据元集完全一致，则可以确定为同种对象类，使用情况一中的编码方式对对象类进行编码；如果数据元集不一致则根据情况三中的方法确定各对象类中数据元的关系，进一步确定是否为同种对象类。如果是同种对象类采用情况二和情况三采用的方法进行处理，并对对象类进行编码；反之，将其作为两种不同的对象类，并分别对其编码。

表1广州城轨线路广播专业系统的广播模块数据元标准表

S103：以城轨线网的对象类为导向，从既有线路的数据元标准中提取城轨线网的数据元。

进一步，步骤S103所述城轨线网的数据元通过以下方法获得：从城轨线网的对象类集合中，取出特定对象类，并在城轨线路的数据元标准中查找该指定对象类对应的数据元，以其作为城轨线网的数据元。

图9本发明实施例的广州城轨线网数据元的提取流程图。

导向指通过业务层得到城轨线网对象类，并根据比较分析得到城轨线路的数据元标准，通过得到的城轨线网对象类作为查找的内容，在城轨线路数据元标准中找到对应的对象类。提取的准则是以对象类以业务层得到的为标准，而城轨线路的数据元标准作为辅助。

步骤S104：设定城轨线网的数据元的属性值,根据属性值,划分同组数据元,命名城轨线网的数据元。这样就可以建立城轨线网数据元的表示规则，规范城轨线网数据元的属性。

进一步，步骤S104所述规范城轨线网的数据元的属性的方法为：通过数据元标识符分配规则、数据元命名规则、数据类型、数据元值域、数据元备注、默认值、报警值和报警等级等方面建立城轨线网数据元的表示规则，规范城轨线网数据元的属性。

线网数据元的表示规则是通过描述数据元的属性来实现，这些属性实际上是数据元的元数据。以下分别从数据元标识符分配规则、数据元命名规则、数据类型、数据元值域、数据元备注、默认值、报警值、报警等级等方面建立城轨线网数据元的表示规则。图10为广州城轨线网数据元的属性模型。图中被分在同一组的数据元，拥有相似的逻辑关系。图中“1:1”意为“有且仅有一个”，“0:1”意为“有零个或一个”，“0:N”意为“有零个或多个”，说明数据元具有某个属性的个数。

数据元命名规则包括唯一性规则，语义规则，语法规则和英文名称(EnglishName)规则。

(1)唯一性规则

在具体语境下，数据元的名称必须唯一，名称一般由对象类词、特性词、表示词和限定词构成。

(2)语义规则

数据元名称中有且仅有一个对象词、特性词、表示词。可以使用限定词来限定对象类词、特性词或表示词，限定词是可选的。

(3)语法规则

对象类词应位于数据元名称的左起第一位，特性词处于第二位，表示词处于最后位置，限定词可以附加在对象类词、特性词和表示词上。限定词应位于被限定成分的前面。表示词和特性词重复时，将冗余词删除掉。

(4)英文名称(EnglishName)规则

若名称是名词则用单数形式，是动词则用现在时，名称各成分间不可以使用特殊字符。可以使用首字母缩略词、大写首字母和缩写词，名称由多个单词组成时，第一个单词首字母小写，后续单词首字母大写，如deviceNumber。

对象类的编码规则。数据元所属的概念集合或事物，每个对象类词有一个编码，用来作为该数据元编码的一部分。为了在广州城轨线网中唯一标识对象类，对对象类编码时综合考虑了对象类的所在线路、位置、专业以及设备类型等信息。线网对象类编码采用组合编码，由5层组成，依次为线路编码、设备位置编码、设备专业编码、设备类型编码和序列码。其中，线路编码只能包括0-9这10个自然数和大写的英文字母，设备位置编码只包括0-9这10个自然数，设备专业编码只包括大写的英文字母，设备类型编码只包括大写的英文字母和0-9这10自然数。编码对于每一层之间使用‘_’进行分隔。这种编码方式既能够唯一标识线网中的每一个设备，也使编码易于理解。具体的编码结构如表2所示。

表2广州城轨线网对象类编码结构

线路编码

设备所在位置编码

设备所在专业编码

设备类型编码

序列码

数据类型。数据元数据类型常有DI、DDI、TDI、DO、AI和MI，如表3所示：

表3数据类型表

数据元值域。数据元值域是符合数据元数据类型和数据格式的数据元允许值的集合。值域可以通过名称、参考资料、枚举、引用规则等给出，如代码数据元的值域是编码，一般通过引用的方式给出。

数据元备注。数据元备注是数据元的补充说明，是一个预留数据元。

默认值。数据元在没有给定值域时的默认值。

报警值。数据元在对应数据值达到报警值时产生报警。

报警等级。数据元的数据值达到报警值时，其报警危险程度使用报警等级表示。

S105：根据预设的城轨线网数据库的命名规范，命名城轨线网数据库中的数据库对象，建立城轨线网数据库。命名城轨线网数据库中的数据库对象包括命名数据库建设过程中各设计阶段的数据库对象，进而提出适合线网的查询优化的物理设计原则，建立城轨线网的数据库。

进一步，步骤S105所述城轨线网数据库的命名规范为：数据库对象的名称采用26个大写英文字母和数字0-9，加上“_”组成；数据库对象的名称不能使用其他字符，不能以数字或下划线开头；数据库对象的名称由前缀和实体名称组成，长度不超过30个字符，前缀描述对象的类型，实体名称包含数据库标识等描述实体内容的信息，数据库对象的名称中的标识使用“_”分隔。

进一步，所述数据库对象的名称的命名格式为：数据表的命名格式为“TB_数据库标识_表标识”；数据字段的命名格式为“表标识_字段标识”；主键约束的命名格式为“PK_主键表标识_主键字段标识”；外键约束的命名格式为“FK_外键表标识_主键表标识_主键字段标识”；check约束的命名格式为“CK_约束表标识_约束字段标识”；索引的命名格式为“IN_索引表标识_索引字段标识”；视图的命名格式为“VI_视图标识”；触发器的命名格式为“TR_触发器标识”；函数的命名格式为“FN_函数标识”；存储过程的命名格式为“SP_存储过程标识”；以上命名格式中(数据表除外)，如果“表标识”的长度大于15个字符，采用“表标识”的缩写，缩写形式为各语义单词的首字母。

进一步，步骤S105所述城轨线网查询效率优化的设计原则包括：对城轨线网数据库中设备类型表、子系统表、车站表、线路表、设备表、设备属性取值类型表和设备属性表的主键字段建立索引；在设备属性取值表中增加表示线路的字段，并按表示线路的字段对设备属性取值表分区；对设备属性取值表中的设备字段和设备属性字段建立联合索引，并建立设备字段和设备属性字段的唯一约束。

建立城轨线网数据库。数据库对象命名规范化，采用城轨线网的统一命名规范命名数据库建设过程中各设计阶段的数据库对象。数据库对象的名称命名规范为：采用26个英文大写字母和数字0-9，加上“_”组成；不能使用其他字符，不能以数字或下划线开头；数据库对象的名称由前缀和实体名称组成，长度不超过30个字符，前缀描述对象的类型，实体名称包含数据库标识等描述实体内容的信息，对象名称中的标识使用“_”分隔。各种数据库对象的命名格式具体如表4所示。

表4数据库对象的命名格式表

数据库对象类型	命名格式
		数据表	TB_数据库标识_表标识
数据字段	表标识_字段标识
		主键约束	PK_主键表标识_主键字段标识
外键约束	FK_外键表标识_主键表标识_主键字段标识
		check约束	CK_约束表标识_约束字段标识
索引	IN_索引表标识_索引字段标识
		视图	VI_视图标识
触发器	TR_触发器标识
		函数	FN_函数标识
存储过程	SP_存储过程标识

以上命名格式中(数据表除外)，如果表标识的长度大于15个字符，采用表标识的缩写，缩写形式为各语义单词的首字母，如设备属性取值表的标识为DEVICEPROPERTYVALUE，其缩写为DPV。其中，各种数据库对象的实施例如表5所示。

表5数据库对象的实施例表

概念设计阶段

在数据元层获得线网数据元标准的基础上，结合系统业务模型的描述情况确定实体之间的联系，最终确定广州城轨线网的系统概念模型：广州城轨线网数据库包含设备类型、子系统、车站、设备、线路、设备属性取值、设备属性种类以及设备属性取值类型八种实体，每个实体仅描述了主要属性，每个子系统中包含N种设备，每种设备类型包含该类的若干个设备，每个设备包含若干设备取值，每个设备取值仅属于一种设备属性种类，每种设备属性种类仅属于一种设备属性取值类型，一个车站中包含多个设备，每个车站仅属于一条线路。针对数据库中的各实体含义作如下简介：

设备类型指线网中的设备类型，如自动售票机、电动风阀等；子系统指线网中的每个专业系统，如环境与设备监控系统(BAS)、电力监控系统(PSCADA)等；车站指线网中的每个车站，如广州城轨线网中的车陂南、浔峰岗等；设备指线网中的每个设备，如广州城轨线网中的4号线车陂南站的一号自动售票机；线路指线网中的每条线路，如广州城轨线网中的4号线；设备属性取值指每个设备的每个属性的具体取值，如广州城轨线网中的4号线车陂南站的一号自动售票机的售票机运行状态取值为“正常”；设备属性种类指线网中所有设备的属性种类，如自动售票机的售票机运行状态、电动风阀的故障状态；设备属性取值类型指设备的每种属性的取值的数据类型，如自动售票机运行状态取值的数据类型为数值输入(DI)。

图11为广州城轨线网数据库对象的E-R图。

逻辑设计阶段

逻辑设计阶段主要负责将广州城轨线网数据库对象E-R图中的实体、属性以及联系转化为关系模型。通过分析实体和联系获得业务数据表，通过分析属性、联系获得业务数据项，通过分析线网数据元及其属性获得业务数据项的数据类型、取值规则等信息。除此之外，还需遵循以下原则：

(1)因为广州城轨线网中，业务功能涉及多条线路和多个专业，需要存取的数据库对象较多，为了提高数据操作效率，往往需要根据情况按线路或专业将数据库对象分开存放；

(2)对于经常进行的一些复杂操作，应当建立相应的视图或物化视图以提高用户的操作效率。

广州城轨线网数据库主要包括八张表：设备类型表(TB_TCC_DEVICETYPE)、子系统表(TB_TCC_SUBSYSTEM)、车站(TB_TCC_STATION)、线路表(TB_TCC_LINE)、设备表(TB_TCC_DEVICE)、设备属性取值类型表(TB_TCC_DEVICEPROPERTYTYPE)、设备属性种类表(TB_TCC_DEVICEPROPERTY)、设备属性取值表(TB_TCC_DEVICE PROPERTYVALUE)。设备类型指线网中的设备类型，如自动售票机、电动风阀等。设备类型表如表6所示，为DEVICETYPE_PK字段建立主键约束，唯一标识一种设备类型，并为DT_SUBSYSTEM_FK字段建立外键约束，该字段与子系统表的SUBSYSTEM_PK字段关联，如表6所示。

表6设备类型表

子系统指线网中的每个专业系统，如环境与设备监控系统(BAS)、电力监控系统(PSCADA)等。子系统表如表7所示，为SUBSYSTEM_PK字段建立主键约束，唯一标识线网中的一个子系统。

表7子系统表

车站指线网中的每个车站，如广州城轨线网中的车陂南、浔峰岗等。车站表如表8所示，为STATION_PK字段建立主键约束，唯一标识线网中的一个车站。

表8车站表

城轨线路指城轨线网中的每条线路，如广州城轨线网中的4号线。线路表如表9所示，为LINE_PK字段建立主键约束，唯一标识线网中的一条线路。

表9线路表

设备表如表10所示，为DEVICE_PK字段建立主键约束，唯一标识线网中的一个设备，为DEVICE_SUBSYSTEM_FK字段建立外键约束，该字段与子系统表的SUBSYSTEM_PK字段关联，为DEVICE_STATION_FK字段建立外键，该字段与车站表的STATION_PK字段关联，为DEVICE_DEVICETYPE_FK字段建立外键约束，该字段与设备类型表的DEVICETYPE_PK字段关联。

表10设备表

设备属性取值类型指设备的每种属性的取值的数据类型，如自动售票机运行状态取值的数据类型为数值输入(DI)。设备属性取值类型表如表11所示，为DPT_PK字段建立主键约束，唯一标识一种属性的取值类型，为DPT_NAME字段建立check约束，规定其取值范围仅限于DI、DO、DDI、AI、MI。

表11设备属性取值类型表

设备属性表如表12所示，为DEVICEPROPERTY_PK字段建立主键约束，唯一标识一种设备属性，为DP_DEVICEPROPERTYTYPE_FK字段建立外键约束，该字段与设备属性取值类型表的DPT_PK字段关联。

表12设备属性表

设备属性取值表如13所示，为DPV_PK字段建立主键约束，唯一标识一条设备属性取值记录，为DPV_DEVICE_FK字段建立外键约束，该字段引用自设备表的DEVICE_PK字段，为DPV_DEVICEPROPERTY_FK字段建立外键约束，该字段与设备属性种类表的DEVICEPROPERTY_P字段关联，为DPV_DEVICEPROPERTYPE_FK字段建立外键约束，该字段与设备属性取值类型表的DPT_PK字段关联，为DPV_LINE_FK字段建立外键约束，该字段与表TB_TCC_LINE的LINE_PK字段关联。

表13设备属性取值表

物理设计阶段

物理设计阶段为逻辑数据模型选取一个最适合应用环境的物理结构，然后根据应用系统特点和处理的需要，进行物理存储安排，合理设计数据表、索引、视图、触发器、函数等数据库对象，形成数据库内模式。广州城轨线网数据库的物理设计一方面需要依据逻辑模型创建数据表，另一方面还需要遵循以下原则：

(1)在设备属性取值表TB_TCC_DEVICEPROPERTYVALUE中增加表示线路的字段DPV_LINE_FK，并对其按DPV_LINE_FK字段分区。

(2)对于数据库中每个表的主键字段建立相应的索引。

(3)对设备属性取值表TB_TCC_DEVICEPROPERTYVALUE中的设备字段

DPV_DEVICE_FK和设备属性字段DPV_DEVICE_FK建立联合索引，并建立唯一约束。

以上对本发明实施例所提供的技术方案进行了详细介绍，本文中应用了具体个例对本发明实施例的原理以及实施方式进行了阐述，以上实施例的说明只适用于帮助理解本发明实施例的原理；同时，对于本领域的一般技术人员，依据本发明实施例，在具体实施方式以及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (8)

1.一种城市轨道交通线网联网管理的方法，其特征在于，包括以下步骤：

步骤一、利用软件工程的需求分析流程对城轨线网执行业务建模操作，获得业务模型的信息关系图，从信息关系图中提取城轨线网的对象类；

步骤二、比较分析既有城轨线路的数据库表、数据点表和文档资料，提取出城轨线路的对象类集合；

步骤三、以城轨线网的对象类为导向，从城轨线路的对象类集合中提取城轨线网的数据元；

步骤四、设定城轨线网的数据元的属性值,根据属性值,划分同组数据元,命名城轨线网的数据元；

步骤五、根据预设的城轨线网数据库的命名规范，命名城轨线网数据库中的数据库对象，建立城轨线网数据库。

2.根据权利要求1所述的城市轨道交通线网联网管理的方法,其特征在于，所述从信息关系图中提取城轨线网的对象类包括以下步骤：

利用软件工程的需求分析流程，构建城轨线网中包括乘客信息显示系统、电力监控系统、防淹门系统、广播系统、环境与设备监控系统、火灾报警系统、列车信息系统、门禁系统、屏蔽门系统、视频监控系统、信号系统和自动售检票系统的各专业系统的系统结构图、系统实现图、系统时序图和数据流图；

获取各专业系统中输入输出信息以及输入输出信息之间关系的信息关系图；

从信息关系图中提取城轨线网各专业系统的对象类。

3.根据权利要求1所述的城市轨道交通线网联网管理的方法,其特征在于，所述步骤二包括以下步骤：

分析既有城轨线路的现有数据库表、数据点表和文档资料，提取出城轨线路的对象类集合；

比较既有城轨线路的现有数据库表、数据点表和文档资料的同种对象类的数据元；

根据同种对象类的不同数据元，设定城轨线路中同种对象类的数据元集合。

4.根据权利要求1所述的城市轨道交通线网联网管理的方法,其特征在于，所述步骤三包括以下步骤：

从城轨线网的对象类集合中，提取指定的对象类；

查找城轨线路的中该指定的对象类对应的数据元；

以该指定的对象类对应的数据元作为城轨线网的数据元。

5.根据权利要求1所述的城市轨道交通线网联网管理的方法,其特征在于，所述步骤四包括以下步骤：

根据数据元标识符分配规则、数据元命名规则、数据类型、数据元值域、数据元备注、默认值、报警值和报警等级，设定城轨线网数据元的属性值；

根据属性值,划分同组数据元,命名城轨线网的数据元。

6.根据权利要求1所述的城市轨道交通线网联网管理的方法,其特征在于:

所述预设的城轨线网数据库的命名规范包括，数据库对象的名称采用26个英文大写字母和数字0-9，加上“_”的任意组合组成；

数据库对象的名称由前缀和实体名称组成，长度小于或等于30个字符，前缀描述对象的类型，实体名称包含描述实体内容的信息的数据库标识，数据库对象的名称各组成部分用“_”分隔。

7.根据权利要求1或6所述的城市轨道交通线网联网管理的方法,其特征在于:

所述数据库对象包括数据表、数据字段、主键约束、外键约束、check约束、索引、视图、触发器、函数和存储过程；

所述数据表的命名格式为，TB_数据库标识_表标识；

所述数据字段的命名格式为，表标识_字段标识；

所述主键约束的命名格式为，PK_主键表标识_主键字段标识；

所述外键约束的命名格式为，FK_外键表标识_主键表标识_主键字段标识；

所述check约束的命名格式为，CK_约束表标识_约束字段标识；

所述索引的命名格式为，IN_索引表标识_索引字段标识；

所述视图的命名格式为，VI_视图标识；

所述触发器的命名格式为，TR_触发器标识；

所述函数的命名格式为，FN_函数标识；

所述存储过程的命名格式为，SP_存储过程标识。

8.根据权利要求1或7所述的城市轨道交通线网联网管理的方法,其特征在于，所述步骤五包括以下步骤：

对城轨线网数据库中的设备类型表、子系统表、车站表、线路表、设备表、设备属性取值类型表和设备属性表的主键字段建立索引；

在城轨线网数据库中设备属性取值表中增加表示线路字段，并按线路字段对设备属性取值表分区；

对设备属性取值表中的设备字段和设备属性字段建立联合索引，并建立设备字段和设备属性字段的唯一约束。