铁路工程管理平台面向铁路工程建设提供多种类型的云服务, 其主要用户包括工程监管、建设管理、工程设计、工程施工、工程监理、工程咨询等单位, 不同单位主要围绕铁路工程项目协作.平台的应用系统覆盖铁路工程项目建设的各个阶段.目前平台用户实体单位200余家, 平台管理的项目500多个.

平台的架构模式如图1所示.工程监管单位主导, 其他用户参与, 一个平台技术支撑单位, 多个应用系统研发单位.铁路工程管理平台同时提供SaaS、PaaS、IaaS、DaaS服务.基于行业云的铁路工程管理平台立足于解决铁路工程项目行业监管困难、单位间和专业间协同困难等问题.

图1

Fig.1

	Figure Option ViewDownloadNew Window
	图1 平台的架构模式Fig.1 Platform architecture pattern

铁路工程管理平台架构设计需要考虑如下需求:

1)与面向数据交换的行业云不同, 各类用户依赖平台应用进行铁路工程各项工作.

2)平台的租户包括实体型组织、项目型组织, 用户可以同时在不同组织中担当角色.

3)行业监管需要平台提供基础数据服务, 支撑各类工程数据的语义一致和语法可识.

4)应用系统应能够支撑多租户, 租户间充分共享各类信息资源.同一个应用面向200个租户, 200个独立部署的模式耗费大量资源, 故不可接受.

5)在满足行业监管需要的同时, 租户间应保护私密性.

6)适应各类租户对不同类型监管数据分析的需要, 如建设单位按项目, 施工单位总部机构按其所参与的项目内容进行数据分析.

7)为促进平台应用的多样化、技术不断创新、发展充满活力的需求, 应支持同个应用不同开发上在平台有不同部署.

8)为应对平台业务和建设模式的复杂性, 平台应提供统一平台配置管理服务.

平台提供DaaS服务的模块包括基础数据系统、元数据系统和数据仓库.应用系统通过服务总线访问基础数据服务和系统之间的信息交换, 如图2所示.

图2

Fig.2

	Figure Option ViewDownloadNew Window
	图2 铁路工程管理平台服务架构Fig.2 Service architecture of railway engineering management platform

1)基础数据系统提供铁路工程的基础数据管理, 包括人员数据、组织数据、项目信息和基础设施数据等.这些数据是各类应用系统运行的基础.

2)元数据系统提供数据分类与编码、交付标准和转换标准的管理.这些核心的数据规范与标准使平台具有一致的语义和语法, 为各类业务应用协作提供保证.

3)数据仓库是平台共用技术组件, 将平台各类数据按照主题项目、组织、专业等分析主题分类存储, 并提供数据归集和处理工具.

平台提供的PaaS服务包括GIS和BI分析.

1)铁路工程为线形工程, GIS为各类应用系统提供地理空间服务, 主要包括底图服务、路径搜索与导航.统一的GIS平台服务支撑铁路工程统一的图标图示, 以及图层开发规范.

2) BI分析是为各类应用提供数据展示与分析、报表设计的基本工具.

平台提供的SaaS服务包括工程管理类和专业应用类.目前已经上线的成熟工程管理类应用包括办公系统、调度指挥、问题库、物资管理、设计交付、信用评价、施工日志、施工组织等, 专业应用类包括路基压实、线性监测、拌合站/试验室、隧道围岩测量、沉降观测、梁场、板厂等.考虑到铁路工程项目之间的差异, 各个模块设置的较为专一, 以方便按照租户需求组合应用.

根据平台管理需要, 设置门户、监控监测平台和配置管理中心.门户和监控监测平台为用户和采集设备两类主体提供平台接入, 配置管理中心则主要服务于平台的整体管理, 具体功能如下:

1)针对行业平台多租户属性, 门户为各类应用在展示层集成提供规范和工具, 主要的门户类型包括项目门户、机构门户、个人门户等.

2)配置管理中心主要模块包括认证授权、应用管理(含厂商管理)、账户管理、租户管理、监控中心和日志管理等.

2.1.1 铁路工程元数据分类

铁路工程管理平台的关键数据通过元数据进行管理.元数据一般被定义为“ 数据的数据” , 是关于数据的组织、格式及关系的信息.它用规范的方式对数据的特征进行描述, 通过一个模型结构, 用标准的数据元素表达通用的信息.元数据是平台数据资源管理的重要手段, 通过元数据可构建一个关键数据的定义词库, 使行业内各参与方或各应用系统达到数据定义的统一.元数据主要分为引用型、结构型和管理型3个类型, 如图3所示.引用型元数据主要包括国际字典框架(International Framework for Dictionaries, IFD)编码和图标图示类元数据.

图3

Fig.3

	Figure Option ViewDownloadNew Window
	图3 铁路工程元数据分类Fig.3 Railway engineering metadata classification

2.1.2 元数据表达

铁路工程元数据主要通过JSON Schema进行表达.JSON Schema具有很强的结构性, 可以完整定义数据的类型、格式、限制、取值范围、关联关系等信息, 是元数据表达的一种有效方式.隧道专业辅助坑道元数据的JSON Schema片段如下

{

"type": "array",

"title": "辅助坑道",

"format": "table", < --表达方式

"minItems": 1, < --限制条件

"items": { < --隶属关系

"type": "object",

"properties": {

"序号": {"type": "number"}, < --数据类型

"名称": {"type": "string"},

"辅助坑道类型": {

"format": "select",

"type": "string",

"enum": ["单车道", "双车道"] < --取值范围

}, ...

通过Schema定义了元数据元素的表达方式、限制条件、隶属关系、数据类型和取值范围信息.元数据Schema可作为数据交换的模板, 也可用于生成数据模型框架, 是平台数据管理和应用的基础.

2.1.3 元数据应用

元数据在铁路工程管理平台有3个主要应用场景, 如图4所示.1)通过元数据来定义平台主数据的数据模型.具体为通过数据表生成器将元数据转化为主数据表, 主数据表可作为平台主数据库的数据结构定义.2)通过元数据定义监控监测平台与前端软件的数据接口.前端采集的数据通过标准的接口进行上传, 提高了数据的质量.3)基于元数据设计成果交付.具体为将元数据以Schema的方式发布给设计单位, 设计单位根据Schema进行设计成果的统一格式创建和组织, 再提交到设计交付系统, 设计交付系统利用Schema对提交的数据进行校验, 校验合格的数据导入平台主数据库, 从而达到设计成果数据的标准化交付.

图4

Fig.4

	Figure Option ViewDownloadNew Window
	图4 元数据在铁路工程管理平台的应用Fig.4 Application of metadata in railway engineering management platform

数据是决策的重要依据.行业云应确保数据源头质量及存储过程中不被篡改.传统的由各应用获取采集数据的方式存在如下弊端:

1)数据分散管理难以集成, 存在原始数据被篡改风险; 2)接入点分散, 技术能力参差不齐, 安全保障能力不足; 3)重复开发和部署, 浪费大量资源, 原始数据难以持久保存; 4)存在虚假上报监测数据的风险.

为解决上述问题, 支撑铁路工程管理平台大数据分析等应用, 设计监控监测平台.监控监测平台实现铁路工程路基、线路、桥梁、隧道、大临设施和施工日志等各类传感器数据的统一入口、原始数据集中存储和前端采集设备认证, 其功能架构如图5所示.

图5

Fig.5

	Figure Option ViewDownloadNew Window
	图5 监控监测平台功能架构Fig.5 Functional architecture of monitoring platform

监控监测平台的主要技术特征包括:

1)通过接口网关发布数据接口服务.接口网关对上传数据格式和属性阈值简单计算, 阻挡不符合规则的上传数据, 对超过设定阈值的数据报警.

2)为适应传感器通过接口上传数据无状态特点, 以及认证需要, 采用令牌的机制.令牌由平台配置的设备厂商、应用、设备编号, 以及部署位置、项目和专业信息等计算生成.传感器上传的每一条数据都附带令牌信息.平台采用令牌动态计算、内存数据库存储和Hash算法快速匹配令牌数据.

3)快速集中存储转发, 监控监测平台对接收到的数据通过消息队列直接推送到各个专业应用, 确保采集数据及时传递.监控监测平台同时将原始传感数据raw格式快速存储集中数据库中, 其主要技术要求是避免阻塞并减少延迟.经压力测试, 接口并发处理能力满足要求, 测试结果如图6所示, 可以看出, 当用户并发量增加时可通过增加服务器集群数量的方式保证响应时间在可接受的范围内.当服务器集群数量增加到12时, 可支持2 000个用户同时在线使用且平台响应时间在200 ms以内.

图6

Fig.6

	Figure Option ViewDownloadNew Window
	图6 数据并发处理能力测试结果Fig.6 Test results of data concurrency processing capability

4)通过批处理定期将RAW格式的原始传感数据转转存到按专业、租户和项目等主题的数据仓库中, 支持数据分析应用.

多租户安全隔离主要涉及物联网接入、应用、数据持久、访问基础数据平台等.考虑到行业云基于项目和专业的信息共享需求, 以及应用共享的资源需求, 设置隔离方式及技术手段如表1所示.

表1

Tab.1

表1(Tab.1)

表1 隔离方式及技术手段 Tab.1 Isolation methods and technical means 隔离类型 技术手段 应用与基础平台隔离 Vlan隔离, 网关鉴权访问 不同租户间隔离 虚拟主机方式, 网关隔离 不同租户 实体化数据隔离 采用共享数据库, 数据表通过租户字段表示 敏感度不同的 应用间隔离 敏感应用与非敏感应用分别部署在敏感区和非敏感区实现物理隔离 非敏感区应用间隔离 Vlan隔离

表1 隔离方式及技术手段 Tab.1 Isolation methods and technical means

认证模型方面, 平台采用OAuth2+OpenID协议的统一认证方案.基于各类应用于平台之间的关系是松耦合的, 而平台基础数据和服务由平台集中管理, 这两方面的特性, 采用标准的OAuth2认证模式, 即应用委托平台认证, 平台统一提供认证功能.此外, 平台各类应用采用的技术架构和开发语言各不相同, 为了保护用户数据不被应用厂商获取, 在访问平台基础数据方面既要鉴别应用身份又要鉴别用户身份.鉴于以上原因, 传统的cookie+session的模式不能适用于平台整体身份认证需要.采用标准的显示JWT token方式实现统一平台认证.

为了保护用户个人信息和工程敏感信息, 应用系统访问基础数据系统需要通过OAuth2授权程序, 如图7所示.

图7

Fig.7

	Figure Option ViewDownloadNew Window
	图7 OAuth2授权程序Fig.7 OAuth2 authorization program

在授权模型方面, 采用基于ABAC和RBAC的两级授权体系.考虑因素如下:

1)不同租户开通产品不同, 产品是维护生态的保证;

2)人员在多组织任职, 人员流动大;

3)项目和专业访问有时间限制;

4)专业众多, 开发商技术架构不统一等;

5)资源需要在项目等各个层面共享.

在模型选择方面, ①MAC过于严格, 将授权工作管理员.②DAC对租户自主授权方式, 不适合行业云的多层面资源共享需求.③RBAC应用最为广泛, 角色机制方便实用, 但角色设置一般为静态, 缺乏灵活的动态授权方法.面对行业云会出现角色爆炸、配置复杂等问题.④ABAC最为灵活, 通过主体(sub)、对象(obj)、动作(act)和环境(env)4个元素的属性判断授权结果, 但是缺少具体的指导性框架, 在大量授权规则下, 冲突检测困难, 处理逻辑复杂也使效率降低.

结合铁路工程领域业务, 变动频繁的主体和环境属性主要涉及项目、组织、租户、应用等相关属性, 这些属性由基础数据平台掌握, 而更细粒度的资源属性由应用系统掌握.此外, 平台各应用系统颗粒度较精细, 可以视为一个独立的资源.因此提出一种动静分离的ABAC+RBAC结合的认证授权模型见图8.

图8

Fig.8

	Figure Option ViewDownloadNew Window
	图8 ABAC+RBAC结合的认证授权模型Fig.8 ABAC+RBAC based authentication model

该模型在平台环境采用ABAC鉴权规则, 主体与一般ABAC规则一致, 客体为应用系统服务, 应用系统内部采用RBAC规则, 利用租户和账户作为角色主体, 进行授权.此授权模型适合平台与应用研发主体不同的行业云情况, 同时能够更好的发挥RBAC成熟和ABAC灵活的特性.

在ABAC策略表达和规则计算选择上, PML^[17]和PERM元模型{policy, effect, request, matches}作为表达方式, 模型中的元素可通过结构体或类实例来定义, 如表2所示.

表2

Tab.2

表2(Tab.2)

表2 ABAC策略的PML表达 Tab.2 PML expression of ABAC strategy 模型 表达 policy p=sub, obj, act, env effect e=some(where(p.eft==allow)) request r=sub, obj, act, env matches m=r.sub.tenant==p.sub.tenant& & r.obj.owner==p.obj.owner& & r.act==p.act& & r.env==p.env

表2 ABAC策略的PML表达 Tab.2 PML expression of ABAC strategy