T/CAMET11001.2-2019 智慧城市轨道交通 信息技术架构及网络安全规范 第2部分:技术架构.pdf

T/CAMET11001.2-2019 智慧城市轨道交通 信息技术架构及网络安全规范 第2部分:技术架构.pdf
积分0.00
特惠
积分0
VIP全站资料免积分下载
立即下载
同类资料根据编号标题搜索
文档
仅供个人学习
反馈
标准编号:
文件类型:.pdf
资源大小:21.6 M
标准类别:铁路运输标准
资源ID:265572
VIP资源

标准规范下载简介:

内容预览由机器从pdf转换为word,准确率92%以上,供参考

T/CAMET11001.2-2019 智慧城市轨道交通 信息技术架构及网络安全规范 第2部分:技术架构.pdf

对城市轨道交通安全生产网、内部管理网、外部服务网进行运行、维 护和管理的计算机网络

PaaS:平台即服务(PlatformasaService) PIS:乘客信息系统(PassengerInformationSystem) SaaS:软件即服务(SoftwareasaService) 通楊食 SDN:软件定义网络(SoftwareDefinedNetwork) SLA:服务水平协议(ServiceLevelAgreement VDC:虚拟化数据中心(VirtualDataCenter) VXLAN:虚拟可扩展局域网(VirtualExtensibleLocalAreaNetwor WLAN:无线局域网(WirelessLocalAreaNetworks) RESTAPI:代表性状态转移应用程序编程接口(Representational

4.1智慧城市轨道交通信息技术架构应采用云计算平台架构YD/T 3532-2019 移动应用身份认证总体技术要求,接照T/ CAMET11001.1和T/CAMET11001.3的要求,为各应用系统提供相应 等级的服务。

世,开迪 4.3安全生产网、内部管理网、外部服务网宜设置域内的大数据平台,各 应用系统应向大数据平台提供共享数据,不同网间的大数据平台的信息交 换通过安全信息通道进行,原则上高安全级别的应用系统可直接向低安全 级别的大数据平台传输数据,低安全级别的数据需通过安全隔离的策略与 高安全级别大数据平台进行数据交换,并对数据使用过程进行详细记录。 4.4智慧城市轨道交通信息技术架构应实现与既有云化部署应用系统的 融合迁移,应按融合迁移的进程,预留既有虚拟化平台与新建云计算平台 次源融人山非二达 生知次酒

用系统应向大数据平台提供共享数据,不同网间的大数据平台的信息 通过安全信息通道进行,原则上高安全级别的应用系统可直接向低安 别的大数据平台传输数据,低安全级别的数据需通过安全隔离的策略 安全级别大数据平台进行数据交换 并对数据使用过程进行详细记录

5.1总体技术架构如图1所示,由六个层次、三大体系构成0六个层次

图1 总体技术架构图

6.1.1架构总体要求

1.1.1应满足业界通用虚拟化、弹性计算、高等级安全、跨地理位 布大规模性、一致性等要求,并针对性满足智慧城市轨道交通对云 平台架构的要求。

全的需求,支持智慧城市轨道交通信息技术架构达到4级以上的灾 衣复等级。

根据业务系统对云计算平台需求,选择通用的、绿色节能的服务器 和网络设备。

1.1.4应对不同厂商的计算、存储、网络等资源池和不同虚拟化技 平台以及主、备数据中心的资源进行统一调度和管理,并支持虚拟化 金属管理。

6. 1.2云计算平台逻辑架构

6.1.2.1云计算平台应包括IaaS层、PaaS层和SaaS层,其逻辑架构见 图2。

图2云计算平台逻辑架构图

6.1.2.2IaaS层宜由逻辑化/池化后的计算、存储、网络等软硬件资源 池及封装后的多种IaaS服务组成,这些资源可直接被云服务用户使用 也可组合支撑更复杂的业务场景,用户可在laaS服务基础上部署和运行 操作系统和各种应用软件。 6.1.2.3PaaS层应为客户提供部署、管理和运行应用程序的环境和服 条应提供应用框加中间件及

也可组合支撑更复杂的业务 操作系统和各种应用软件。 6.1.2.3PaaS层应为客户提供部署、管理和运行应用程序的环境和服 务,应提供应用框架、中间件及相应的部署和管控等能力,同时PaaS还应 提供代码管理、编译打包、废布部署、持续集成和持续交付等开发运维 体化服务。

6.1.2.4SaaS层应涵益安全生产、内部管理和外部服务,云服务提供商

6.1.2.4Saas层应涵盖安全生产、内部管理和外部服务,云服务提供商 宜结合智慧城市轨道交通云业务场景提供应用类服务。

宜结合智慧城市轨道交通云业务场景提供应用类服务。

络扩展等多种功能需求。 2)应采用集中化管理技术,对网络设备进行逻辑抽象形成统 一的资源池,再进行灵活化、集中化、细粒度地控制调度 通过统一的管理平台,把网络节点组织成统一的资源池 统一管理,统一编排。 d 3)应基于云管理平台实现计算、网络资源统一自动化发放 可根据用户虚拟机/物理机资源申请,将逻辑虚拟网络映 射到物理网络并自动分配网络资源。 4 网络管理、业务以及存储等平面应隔离,避免相互影响 应能针对不同业务承载,利用API实现基于SDN的业务 管理和控制,满足不同的SLA需求。业务承载网应按业务 的安全等级进行划分、相互隔离。提供的SLA和网络隔离 质量应能提供技术手段进行验证和确认。 5 应设计穴余链路、保护链路,灵活部署相应的保护机制,提 高数据中心网络利用率、降低故障发生率,且为数据中心 提供高效的全局保护。在控制平面和转发平面都遵循高 可靠性设计,通过分布式集群等机制实现数据中心业务系 统的高可用性。应支持分布式SDN控制器,控制器的物理 1.3.2Iaas服务 基于资源池的各项资源可封装组合成多种Iaas服务,IaaS服务包括 不限于云主机服务、裸金属服务器服务块存储服务、对象存储服务、虚 私有网络服务、负载均衡服务虚拟数据中心服务、备份服务。 a)云主机服务应为用户提供申请即用的虚拟机服务,功能要求应 1)应支持云主机操作系统的多种安装方式; 支 汇知动太调整

基于资源池的各项资源可封装组合成多种Iaas服务,IaaS服务包括 但不限于云主机服务、裸金属服务器服务块存储服务、对象存储服务、虚 拟私有网络服务、负载均衡服务虚拟数据中心服务、备份服务。 a)云主机服务应为用户提供申请即用的虚拟机服务,功能要求应 1)应支持云主机操作系统的多种安装方式; 应支持云主机参数/规格的自定义和动态调整: 3 应提供云主机个数的弹性伸缩能力; 4) 应提供多种规格的云主机服务类型;

5) 应支持云主机的在线克隆和离线克隆; 6) 应支持云主机的快照和备份; 7) 8) 9) 应提供云主机的自动故障检测故障隔离和快速恢复; 10 应支持定义不同SLA的主机服务; 11) 应支持虚拟机操作系统零注入,即虚拟机在创建时不需 要安装或者注人非原生的软件包; 12) 应支持运行状态下的云主机迁移,满足业务不中断。 6 裸金属服务器服务宜用于对时延、I/0等要求高,或不支持虚拟 化的业务部署,功能要求应包括: 1 应支持多种配置的物理机规格; 2) 应支持物理服务器的自助申请: 3) 应支持自动化完成网络配置、OS安装; 4 应支持同一个租户内虚拟机、物理机互通; 5) 应支持物理机之间直接提供高速互通能力(两层); 6) 应支持基于资源使用策略进行裸金属服务器的开/关机。 C 块存储应为用户提供数据块级随机存储服务,功能要求应 包括: 1 应提供自由配置存储容量、随时扩容的功能 应提供根据不同业务场景的块存储类型: 3) 应提供快照功能为块存储提供数据备份能力; 4)厂 d 对象存储服务应支持基于对象的海量存储,功能要求应包括: 1 应提供低延迟、高并发的数据访问能力; 2 应提供多副本机制,保证数据高可靠性; 应提供鉴权和访问控制表机制: 应提供标准的RESTAPI; 5)应提供PB级别的海量数据存储能力;

6)应支持数据生命周期管理,实现自动删除超期的对象。 e) 虚拟私有网络应构建出逻辑隔离的虚拟网络环境支持用户自 行管理,控制该环境内的IP地址、网段、路由和虚拟网络设备 等,功能要求应包括: 1 应具备多租户之间的网络逻辑隔离能力; 2) 可自定义私网网段,并具有地址分配能力; 3) 可控制私网内的子网划分、路由连通等; 4) 应支持灵活的访问控制规则。 f 负载均衡应实现流量分发,功能要求应包括: 应采用穴余设计: 2 应提供传输层或应用层的负载均衡服务,支持多种连接 方式; 3) 应支持配合虚拟机提供云计算资源的弹性扩展: 4) 应支持对绑定的虚拟机进行健康检查; 5) 应提供会话保持功能。 8 虚拟数据中心应将物理资源池化,应支持通过逻辑隔离技术基 于业务需要灵活分配的逻辑数据中心,包括计算、存储和网络 资源,功能要求应包括: 1)应提供灵活多样的划分方式,保证VDC问互相隔离; 2) 应提供设置每个VDC的资源使用配额能力(包括CPU、内 存、存储、网络); 3) 应提供跨多个物理数据中心资源的统一分配的VDC资源 构建方式: 4) 应提供系统管理员、VDC管理员、业务用户等完备的权限 管理机制: 5)应提供独立管理实体,在VDC内用户可以自助申请、管理 及监控IT资源。 备份服务应对云主机的磁盘提供备份服务,应通过备份副本恢 复到原盘或者新创建的盘,功能要求应包括:

1) 应支持全量备份、增量备份等多种备份方式; 2) 应支持手工备份和定时备份; O 3) 应支持虚拟机在线备份,虚拟机开机、关机都可进行备份; 4) 应支持租户面的元数据和用启数据的备份及恢复; 5) 6) 应支持自定义备份策略代 7) 应支持数据存储至少3备份。

6.1.4.1PaaS应提供数据库服务、大数据服务、中间件服务,也可为内

6.1.4.2数据库服务

数据库应将一组独立数据节点通过网络联接并协同工作,通过数 片与集群,对外提供统一的高负载海量数据管理与服务能力的数据 理系统,应包括关系型数据库服务和非关系型数据库服务。 a)关系型数据库服务的功能要求应包括: 1 应基于分布式集群技术及负载均衡服务提供高可用性; 2) 应提供多副本、热备份等能力,保证业务连续性; 3) 应提供自动多重备份的机制; 4) 5) 应提供白名单访问策略: 6) 应提供SQL审计功能,并可提供接口; 7) 应支持通用的主流的关系型数据库。 b)非关系型数据库服务的功能要求应包括: 1 应基于分布式集群技术及负载均衡服务提供高可用性; 2) 应支持在线数据库扩容; 3 应支持本地备份和异地灾备; 应支持表级别在线备份; 5 应支持兼容SQL标准接口; 6)具备二次开发能力,支持C++和Java等编程接口。

6.1.4.3大数据服务

大数据服务应基于分布式架构,通过大规模、可扩展的并行计算框 为海量数据提供高效的存储、计算和分析能力,应包括离线计算服务、 计算服务、流式计算服务。 2) 应支持SQL、Map/Reduce、图编程、机器学习等计算模型; 3) 工具: 应提供多租户管理体系,实现应用数据与程序的隔离; 应提供按需使用、弹性伸缩的服务模式; 6) 应提供海量数据、高并发的数据上传下载能力,实现PB级 别的计算吞吐能力; 7) 应提供权限管理及审计功能,确保管理员能设置访问控制 及管理操作日志,对系统日常运行进行分权分域和细粒度 控制。 b)内存计算服务的功能要求应包括: 1)应提供面向海量数据进行任意维度的密集计算与检索的 能力; 2) 应支持百TB级别数据的存储、计算能力 3) 应采用并行计算框架,提供数据高性能计算能力; 4) 5 应支持多重嵌套:多表关联、相关子查询等复杂SQL; 6)应提供按需使用弹性伸缩的服务模式。 C 流式计算服务的功能要求应包括: 1)应提供分布式数据流式处理服务; 2 应支持与大规模数据处理服务平台无缝集成能力; 3 应提供完整的RESTAPI、JavaSDK操作与管理; 4) 应支持HTTP/HTTPS协议;

5) 应支持局部节点故障不影响全局的能力和分钟级自动 恢复; 楊馆 6)应支持CQL语言,降低业务开发难度。

6.1.4.4中间件服务

PaaS层应支持消息中间件、缓存中间件数据访问中间件等当前典 的中间件服务。 衣 a)消息中间件服务的功能要求应包括: 1)应支持主的报文格式和传输协议; 2 应支持RESTAPI; 应支持提供可靠的消息机制: 应支持多层面的弹性伸缩能力,如节点、分区、副本; 5 应支持集群间的异步复制。 b) 缓存中间件服务的功能要求应包括: 1) 应支持透明故障切换; 2) 应支持多租户; 3 应支持服务多平面隔离。 C 数据访问中间件服务的功能要求应包括: 1) 应支持对主流数据库、数据缓存的透明访问; 2) 应支持标准的SQL语法,具备把标准SQL翻译为特定数据 源语义的能力; 3) 应支持对SQL的优化,如基于规则的优化等。 1.4.5通用组件服务

6. 1.4.5通用组件服务

PaaS平台应内置多种通用服务组件,提供预编码应用程序并支持动 态扩展,以减少应用开发的编码时间。服务组件包括但不限于权限控制、 工作流引擎、目录服务、数据服务、服务治理、服务门户、可视化报表、API 网关、搜索引擎

6. 1. 4. 6其他服务

PaaS可面向管理信息系统中碎片化应用开发、弹性调度应用等 提供容器服务和微服务。

a)容器服务的功能要求应包括: 1) 应提供不同应用的逻辑隔离; 2) 4) 应提供完善的单机事务管理能力,并能实现事务隔离级别 的传播; 5)容器网络应支特oyerlay和underlay。 b)微服务开发框架应包括编程模型、运行模型、通信模型和服务 契约,功能要求应包括: 应支持架构开放及组件解耦,可随时进行扩展、定制 配置; 2) 应兼容开源生态; 3) 应支持基于微服务OpenAPI自研SDK; 4) 应支持多种服务注册发现开发模式; 5 应支持客户以插件方式接入自研或特定领域通信协议: 应支持离线开发工具。 6.1.5S SaaS层应为用户提供工具型和管理型的应用,应满足移动化应 用,提供即时通信、服务消息推送、LBS签到等服务功能,应整合各类数据 支撑智慧城市轨道交通大数据运营分析系统。 证 6.2云计算平台部署 6.2.1中心级云计算平台 6.2.1.1中心级云计算平台应包含云管理平合、资源管理平台、虚拟化 或容器等组件,支持智慧城市轨道交通云服务保障和云服务编排。 6.2.1.2中心级云计算平台应实现下列功能: a)对于部署了云计算平台的主用中心、灾备中心、控制中心、车 站、车辆段、停车场等,应实现统一管理: b 应实现云和非云统一管理; C)应实现异构虚拟平台统一管理; 小应实现运营和运维统一管理,

a)对于部署了云计算平台的主用中心、灾备中心、控制中心、车 站、车辆段、停车场等,应实现统一管理: b 应实现云和非云统一管理; 应实现异构虚拟平台统一管理; d)应实现运营和运维统一管理:

6.2.1.3中心级云计算平台部署应遵循下列原则

1.3中心级云计算平台部署 a) 应全网统一部署云管理平台,实现线网资源统一管理,业务统 一部署、发放,集中运维; d b)主用中心和灾备中心应按安全生产网、内部管理网、外部服务 网分别部署云资源管理平台; C) 主用中心无法访问时,应能够自动访问灾备中心应用服务器; d)虚机或主机故障时,可以在正常计算节点上重新启动故障虚 机,实现应用节点高可用性; 应基于存储的数据复制技术实现存储本地高可用与同城高 可用; 云资源管理平台应根据业务需要部署普通资源池、高性能资源 池、物理机资源池等; g) 资源池应支持异构; h) 资源池容量应尽量最大化,避免资源的过度条块分割; i 主用中心和灾备中心宜按安全生产网、内部管理网、外部服务 网分别部署云备份服务

.2.2.2站段云节点部署应遵循下列原则。内

a) 车站、车辆段、停车场应根据各业务需求在本地部署资源池、 b) 车站资源池应支持鼻构,纳入中心级云计算平台统一管理。 ) 降级模式下,车站资源池应满足本地自治需求,不影响车站业 务的正常运行。中心业务或网络连接恢复正常后,车站数据应 及时上传至主用中心。

6. 3云计算平台管理

台、灾备中心云平台和站段云节点的统一运营管理和运维管理。 6.3.2云管理平台应采用开放架构、接口协议及开发平台,提供 能力调用。

合、灾备中心云平台和站段云节点的统一运营管理和运维管理。 6.3.2云管理平台应采用开放架构、接口协议及开发平台,提供统一的 能力调用。 D 6.3.3在主用中心运维管理网部署云管理平台服务器及管理软件,宜 段云节点的的统一管理。 衣 6.3.4在灾备中心运维管理网部署云管理平台服务器及管理软件,宜 采用虚拟化集群配置方案,实现对灾备中心云平台的管理。 6.3.5根据运营及运维管理需求,云管理平台宜采用数据级容灾方案 可采用应用级容灾方案。 6.3.6云管理平台应具备运营管理、运维管理功能。 6.3.7云管理平台应具备资源池接口能力、定制集成接口能力、多资源 池管理、VDC管理、云服务管理等运营管理能力。 6.3.8云管理平台应具备告警管理、容量管理、性能管理、拓扑管理、报 表管理、监控管理、角色管理、门户管理等运维管理功能

a 应采用通用、开放、先进的大数据技术,结合城市轨道交通信息 化现状,加强各类数据资源的整合构建统一的技术架构和标 准规范; b 应采用高稳定性、高可用性的产品,并通过监控运维体系保证 平台应用低故障率,确保平台的稳定运行; 应采用开放性的累统架构设计,应充分考虑本系统与其他系统 间对接,便于接入多种已有的业务平台、业务数据和第三方 平台: 应采用开源的架构设计和分布式计算与存储技术,能支持千方

a 应采用通用、开放、先进的大数据技术,结合城市轨道交通信息 化现状,加强各类数据资源的整合构建统一的技术架构和标 准规范; 衣 b 应采用高稳定性、高可用性的产品,并通过监控运维体系保证 平台应用低故障率,确保平台的稳定运行; C 应采用开放性的累统架构设计,应充分考虑本系统与其他系统 间对接,便于接入多种已有的业务平台、业务数据和第三方 平台: 应采用开源的架构设计和分布式计算与存储技术,能支持千方

作,支持平台硬件资源的快速扩展和系统处理能力的线性 增长; 应具备良好的易维护性,支持统一、集中化的日常运维监控管 ? 理能力,能够根据监控数据判断平台节点故障并进行流程化处 理,系统采用松耦合架构,能够截不中断业务的情况下平滑 升级。

1.2大数据平台应满足下列网络安全的要求: a)应参照信息安金等级保护标准,基于云计算平台安全架构,融 合各类安全设备实现大数据平台整体安全防护。 应建设一个统一的大数据平台进行数据共享,按照安全生产 网、内部管理网、外部服务网分域逻辑部署,不同网间的大数据 平台域的信息交换通过安全信息通道进行。原则上高安全级 别可直接向低安全级别的大数据平台域传输数据,低安全级别 的数据通过安全隔离的策略上传。 c)各类应用系统应从其同安全等级的大数据平台域获取需要共 享的数据。车站级业务系统应统一通过大数据平台进行共享 数据交换。 1.3大数据平台应提供高效的数据共享引擎,负责完成具体的数据 享与传输任务,并提供与数据共享传输有关的功能组件,包括但不限于 据注册组件、数据资产目录管理组件、数据接口管理组件、权限管理组 、安全高速数据传输协议、任务调度组件文件处理组件、传输控制接 、操作和管理接口等。 1.4大数据平台应提供多种数据传输方式,包括但不限于socket方 、ftp文件共享服务器方式数据库共享数据方式、RestAPI方式以及消 队列方式等。 1.5各业务系统应根据大数据平台的数据共享、数据规范、数据传输 要求,将业务系统中宜共享的数据传输至大数据平台集中存储。其余 据由各系统分散保留各自存储

7.1.2大数据平台应满足下列网络安全的要求:

a) 应参照信息安金等级保护标准,基于云计算平台安全架构,融 合各类安全设备实现大数据平台整体安全防护。 应建设一个统一的大数据平台进行数据共享,按照安全生产 网、内部管理网、外部服务网分域逻辑部署,不同网间的大数据 平台域的信息交换通过安全信息通道进行。原则上高安全级 别可直接向低安全级别的大数据平台域传输数据,低安全级别 的数据通过安全隔离的策略上传。 c)各类应用系统应从其同安全等级的大数据平台域获取需要共 享的数据。车站级业务系统应统一通过大数据平台进行共享 数据交换。

7.1.3大数据平台应提供高效的数据共享引擎,负责完成具体的数据

共享与传输任务,并提供与数据共享传输有关的功能组件,包括但 数据注册组件、数据资产目录管理组件、数据接口管理组件、权限 件、安全高速数据传输协议、任务调度组件文件处理组件、传输 口、操作和管理接口等。

7.1.4大数据平台应提供多种数据传输方式,包括但不限于socket方

要求,将业务系统中宜共享的数据传输至大数据平台集中存储。其 放据由各系统分散保留各自存储。

7.2.1大数据平台应由数据源层、数据集成层、数据存储层、应 层、数据应用层五部分组成。 X

7.2.1大数据平台应由数据源层、数据集成层、数据存储层、应用支撑

7.2.2数据源层应按照三个网络域内业务内容,以应用系统为

粒度,梳理应用系统构成和数据内容,从各应用系统对外数据交换 行整理和分析,生成城市轨道交通全域数据资产清单。

7.2.3数据集成层应通过可监控的数据集成技术,采用消息队列

不同业务场景数据集成处理的需要。

7.2.5应用支撑层应通

联,形成并具备向数据应用层提供多种类型的服务能力,实现本层内设计 常见的数据计算、数据检索、数据挖掘以及数据共享等应用支撑能力。 7.2.6数据应用层应从行业应用的角度,以数据统一的交换和集成能 力为基础,逐步建设覆盖多领域的数据应用场景

.3天数据平台主要技术要求

月,并应满足下列要求: a)数据采集应支持结构化数据、半结构化数据和非结构化数据等 多源异构数据;数据采集阶段,应支持基于元数据的数据规则 b 数据存储应根据数据本身特点和数据应用场景采用不同的存 应用支撑应包括数据检索、数据计算、数据挖掘、多维分析、数 据可视化、数据共享等服务内容。 大数据平台应支持多种模型的构建,实现在城轨运营生产、运 营管理、企业管理、建设管理、资源管理等方面的大数据智能分

析和价值挖掘。 7.3.2 数据管理技术应满足下列要求: a) 应通过分布式部署和集中式管理架构,实现各节点之间的数据 及时、高效地上传和下达,实现数据的一次采集和多系统共享; b 应提供数据格式定义、数据转换、数据路由、业务规则定义和业 应提供统一的监控管理入口,能够对多种交换作业提供统一的 d 应遵循相关技术标准和规范要求,为跨地域、跨部门、跨平台的 不同应用系统、不同数据库之间的互连互通提供包含提取、转 换传输和加密等操作的数据交换服务。 7.3.3数据安全技术应包括数据管理安全、数据使用安全和数据安全 监控,并应满足下列要求: a) 数据管理安全通过数据安全管理制度和机构、人员和运维管理 规范实现; b 数据使用安全通过数据服务使用申请、数据授权认证、数据备 份恢复、数据安全控制实现; C 数据安全监控实现监控分析、监控预警、监控告警等。 8冈 网络 8.1总体架构 8.1.1网络划分 鱿道通協食 8.1.1.1根据应用、管理及安全防护等级的不同,智慧城市轨道交通信 息技术架构的网络应划分为安全生产网、内部管理网、外部服务网。各业 务系统应根据其业务属性分别部署在安全生产网、内部管理网、外部服务 网中。 8.1.1.2安全生产网应实现安全生产及管控、运输指挥、应急指挥调度 业务相关系统的数据通信及数据共享。与行车安全密切相关信号系统安

7.3.2数据管理技术应满足下列

业务相关系统的数据通信及数据共享。与行车安全密切相关信号系统安 全网可设置独立专网。

8.1.1.3内部管理网应实现企业管理、运营管理、建设管理、资源管理 等企业信息化相关业务系统的数据通信及数据共享。 8.1.1.4外部服务网应实现门户网站等相关面向外部或公众的业务系 统的数据通信及数据共享。

8.1.2.6应构建独立的运维管理网,统一管理安全生产网、内部

及网管系统应通过接入运维管理网实现网络的带外管理;运维管理网的 网络设备、安全设备及网管系统应通过运维管理网实现带内管理。

8.2.1线网中心网络

8.2.1.1网络宜按照核心交换层、汇聚交换层、业务接入层三层

行预先设定的动作进行保护切换。

8.2.2.1通信传输网宜按照线网骨干层和线路骨于层两级架

网。线路骨干网和线网骨干网应通过TDM等时隙或波段隔离技

输节点,用于各车站安全生产业务上传到线网中心。 持E1、FE、GE、10GE等类型业务接口。 D 8.2.2.7骨干网络采用的设备应具有模块化结构,应能进行扩容、升级 和重新配置。

8.2.2.8骨网络应支持物理

钟同步,满足各应用系统时间同步要求。骨干网络应支持IEEE 时间同步协议。

切换时应不影响正常使用。 8.2.2.10传输环网设备应支持关键板卡允余备份,单一节点设 效,应不影响其他站点正常通信。

8.2.2.11通信传输网的端到端时延应不大于250msGB/T 31977-2015 核电冷凝器用铜合金无缝管,传输时延

8.2.3站段局域网络

8.2.3.1根据用户分布及规模,站段局域网可按汇聚层、接入层 置;网络路由交换、保护倒换等协议采用国际标准协议和接口,严 私有协议。

8.2.3.2汇聚网络设备应支持横向和纵向虚拟化QGDW 11466-2016 港口岸电技术相关术语,支持虚多

a) 根据各业务系统需求可设直 至站段汇聚交换机; b ISCS、ATS、AFC等系统站段接人网应采用双网余,应根据承 载业务实际情况,采用星型或环型组网 ) ACS车站接人网应构建二层环网,二层环网应通过标准协议收 敛链路或节点故障情况下的收敛时间应不大于50ms; PIS、ACS等系统可根据需要经由交换机汇聚后接入车站汇聚 交换机,或直接通过光口接入到汇聚交换机:

8.2.3.4站段内部管理网设置应符合

©版权声明
相关文章