航空论坛_航空翻译_民航英语翻译_飞行翻译

标题: EUROCAT-X空管自动化系统软件支持工作业务流程暂行规定 [打印本页]

---

作者: 航空    时间: 2010-8-1 10:03:45     标题: EUROCAT-X空管自动化系统软件支持工作业务流程暂行规定

EUROCAT-X空管自动化系统软件支持工作业务流程暂行规定

---

作者: 航空    时间: 2010-8-1 10:04:14

EUROCAT-X 空管自动化系统
软件支持工作业务流程暂行规定
中国民用航空总局空中交通管理局
二○○七年八月
1
目录
第一章自动化系统软件支持业务概述......................................................................8
1.1 业务介绍..........................................................................................8
1.2 软件支持业务组织方式..................................................................8
第二章故障管理……………………………………………………………………10
2.1 业务说明........................................................................................10
2.1.1 故障来源.............................................................................10
2.1.2 故障严重程度/优先级初步确定和故障报告提交...........10
2.1.3 故障的分析、诊断和分类.................................................12
2.1.4 故障的最终解决.................................................................14
2.1.5 故障数据库的管理办法.....................................................15
2.2 业务范围和职能划分....................................................................15
2.2.1 业务范围.............................................................................15
2.2.2 业务职能划分.....................................................................16
2.3 工作流程........................................................................................16
2.4 业务相关文档................................................................................17
第三章离线数据管理................................................................................................18
3.1 业务说明........................................................................................18
3.1.1 概述.....................................................................................18
3.1.2 离线数据的分类.................................................................18
3.2 业务范围和职能划分....................................................................19
3.2.1 领导小组的业务范围和职能.............................................19
3.2.2 软件支持中心的业务范围和职能.....................................20
3.2.3 各地区运行管理组的业务范围和职能.............................20
3.2.4 软件数据管理组的业务范围和职能.................................20
3.3 工作流程........................................................................................21
3.3.1 离线数据的申请.................................................................21
3.3.2 离线数据的测试评估.........................................................21
3.3.3 离线数据的审批.................................................................22
3.3.4 离线数据的修改.................................................................22
3.3.5 离线数据的准确性检查.....................................................22
3.3.6 离线数据的发布更新.........................................................23
3.3.7 离线数据的运行测试和验证.............................................23
3.3.8 离线数据的备份和版本管理.............................................24
3.3.9 离线数据修改管理流程.....................................................24
2
3.4 业务相关文档................................................................................29
第四章新版本软件管理............................................................................................30
4.1 业务说明........................................................................................30
4.2 业务范围和职能划分....................................................................30
4.2.1 领导小组的业务范围和职能.............................................30
4.2.2 软件支持中心的业务范围和职能.....................................30
4.2.3 地区运行管理组的业务范围和职能.................................32
4.2.4 软件数据管理组的业务范围和职能.................................33
4.3 工作流程........................................................................................33
4.4 业务相关文档................................................................................35
第五章软件补丁管理................................................................................................36
5.1 业务说明........................................................................................36
5.2 业务范围和职能划分....................................................................36
5.2.1 领导小组的业务范围和职能.............................................36
5.2.2 软件支持中心的业务范围和职能.....................................37
5.2.3 地区运行管理组的业务范围和职能.................................38
5.2.4 软件数据管理组的业务范围和职能.................................38
5.3 工作流程........................................................................................39
5.4 业务相关文档格式........................................................................40
第六章版本控制........................................................................................................41
6.1 业务说明........................................................................................41
6.1.1 概述.....................................................................................41
6.1.2 软件源代码的版本控制.....................................................41
6.1.3 安装软件的版本控制.........................................................42
6.1.4 离线数据的版本控制.........................................................42
6.1.5 自动化系统软件相关技术文档的版本控制.....................44
6.2 业务范围和职能划分....................................................................45
6.2.1 业务分类.............................................................................45
6.2.2 软件支持中心的业务范围和职能.....................................45
6.2.3 地区运行管理组的业务范围和职能.................................45
6.3 业务相关文档格式........................................................................45
第七章技术资料的管理............................................................................................46
7.1 业务说明........................................................................................46
7.2 业务范围及责任划分....................................................................48
7.2.1 领导小组的业务范围和职能.............................................48
3
7.2.2 软件支持中心的业务范围和职能.....................................48
7.2.3 地区运行管理组的业务范围和职能.................................49
7.3 工作流程........................................................................................49
7.4 技术资料业务相关文档格式........................................................50
附件一、《故障报告表》（中文）…………………………………………………..51
附件二、《故障报告表》（英文）………………………………………………… 53
附件三、《PCR 样例表及填表说明》……………………………………………….55
附件四、《EUROCAT-X 自动化系统离线数据分类》………..……………………58
附件五、《离线数据修改表》………………………………………………………61
附件六、《离线数据测试评估报告》…………………………………………………62
附件七、《离线数据修改建议》……………………………………………………64
附件八、《软件测试相关表格文件》
《SSF 平台测试报告》…………………………………………………….65
《SSF 平台测试评估报告》……………………………………………….66
《TEB 平台测试报告》……………………………………………………67
《TEB 平台测试评估报告》……………………………………………….68
《软件升级评估报告》…………………………………………………….69
《OPS 软件升级报告》……………………………………………………70
附件九、《新版本软件发布说明表》…………………………………………………71
附件十、《新版本软件安装报告表》…………………………………………………72
附件十一、《软件补丁说明》……………………………………………………….73
附件十二、《软件补丁安装报告表》……………………………………………….74
附件十三、《软件源代码变更描述文件》………………………………………….75
附件十四、《文件记录表》………………………………………………………….76
附件十五、《软件技术资料管理细则》…………………………………………….77
附件十六、《软件基本功能测试》………………………………………………….81
4
总则
本规定适用于使用EUROCAT－X 空管自动化系统的运行管理。
本规定由总局空管局负责解释。
本规定应视今后的发展作相应的修改。
编写人员：邹朝忠、任吉德、陈文秀、谢玉兰、翟凯、何泽宇、沈力、李钢、
干为敏
5
使用术语说明
民航空管自动化系统软件支持领导小组（CCB）：指对全国空管自动化系统
软件支持业务进行全面管理的机构，其日常办事机构为总局空管局技术中心软件
支持处。
空管自动化系统软件支持中心（SSF）：指对空管自动化系统提供技术支持
的部门。
地区自动化系统运行管理组（LOMG）：指对本地区空管自动化系统进行全
面管理的机构。
软件数据管理组（SDMG）：指本地区LOMG 的日常办事机构，同时负责实
施本地区自动化系统的软件、数据管理业务，提供技术支持等其它相关工作。
ACC：指使用EUROCAT-X 自动化系统的区域管制中心。
TMA：指使用EUROCAT-X 自动化系统的终端管制中心。
TCU：指远端TMA。
TWR：指使用EUROCAT-X 自动化系统的塔台
RTWR：指使用EUROCAT-X 自动化系统的远端塔台。
现场：本文中如果不加说明，指使用EUROCAT-X 自动化系统的所有现场。
OPS 平台：指用于实际管制运行的EUROCAT-X 自动化系统。
TEB 平台平台：指各现场独立于OPS 平台，用于模拟、培训、测试、应急
的EUROCAT-X 自动化系统。
SSF T&E 平台：指SSF 中心专用于测试和评估的EUROCAT-X 自动化系统。
PCR：指经过LOMG 和SSF 调查并确认后的故障报告。
ECR：指用于增加或者更改EUROCAT-X 自动化系统功能的需求。
VDD：指软件版本描述文档。
分区：指EUROCAT-X 自动化系统的分组，根据系统功能和管理区域的不同，
可以分为航路（ER）分区、终端（TM）分区、远程终端（TC）分区、塔台（RT）
分区、旁路（BY）分区、数据准备（OL）分区。
CSCI：指EUROCAT-X 自动化系统的功能模块。
TRACE: 指EUROCAT-X 自动化系统应用软件的日志。
离线数据：指EUROCAT-X 自动化系统使用的各种离线配置参数的总称。
全局数据：指EUROCAT-X 自动化系统中涉及所有分区的离线数据。
本地数据：指EUROCAT-X 自动化系统中仅涉及本地分区的离线数据。
核心离线数据：指对EUROCAT-X 自动化系统运行和安全有致命影响的离线
数据。
关键离线数据：指对EUROCAT-X 自动化系统运行和安全有重大影响的离线
6
数据。
运行离线数据：指对EUROCAT-X 自动化系统运行和安全没有重大影响的离
线数据。
故障：指EUROCAT-X 自动化系统在运行过程中出现的故障，包括系统硬件
及软件故障。
自动化系统运行事件管理系统：指用于EUROCAT-X 自动化系统的故障管
理系统。
缩略语表
ACC Area Control Centre
CCB Central Control Board
CSCI Computer System Configuration Item
DDD Data Description Document
DRDD Dataset Release Description Document
DRA Direct Radar Access
DBMS Database Management System
DPR Data Preparation
ECR Engineering Change Request
ESIM Eurocat Software Installation Manual
ICD Interface Control Document
LOMG Local Operation Management Group
ASID ATC Software issue database
OPS Operational System
OH Operator Handbook
PCR Problem/Change Report
RDD Release Description Document
RDP Radar Data Processing
SDMG Software and Data Management Group
SSDD System/Segment Design Document
SSF Software Support Facility
SSS System/Segment Specification
TCU Terminal Control Unit
TEB Training & Emergency Backup
T&E Test & Evaluation
7
TMA Terminal Maneuvering Area
TWR Aerodrome Control Tower
RTWR Remote Aerodrome Control Tower
VDD Version Description Documents
V&V Verification and Validation
8
第一章自动化系统软件支持业务概述
1.1 业务介绍
自动化系统是空管技术保障体系中的重要组成部分，软件部分所占比重较大
且处于核心地位，与空管业务流程密切相关。保持系统稳定，不断适应空管业务
的需求，是软件支持业务的基本出发点。
软件支持业务主要包括以下几个方面：
 故障管理，包括软件故障的发现、报告、调查及处理。
 离线数据管理，包括离线数据的修改、测试和验证。
 新版本软件管理，包括新版本软件的产生、测试、发布及安装。
 软件补丁管理，包括软件补丁的产生、测试、发布及安装。
 版本控制管理，包括软件源代码版本控制、软件版本控制、离线数据的
版本控制、软件相关文档资料的版本控制。
 技术资料管理，包括软件相关文档资料管理。
 其它自动化系统软件相关工作，包括软件功能扩展的可行性分析及评估
等。
1.2 软件支持业务组织方式
软件支持业务涉及多个部门和众多的工作步骤，需要完善的软件支持管理规
定和规范化的工作流程来保证各项业务的顺利开展。
软件支持体系的参与部门主要有民航空管自动化系统软件支持领导小组（以
下简称“领导小组”）、总局空管局技术中心软件支持处（以下简称“软件支持处”）、
空管自动化系统软件支持中心（以下简称“软件支持中心”）、地区自动化系统运
行管理组（以下简称“地区运行管理组”）、软件数据管理组、自动化系统供应商
（以下简称“供应商”）等。
领导小组作为全国空管自动化系统软件支持工作的管理者，全面负责管理自
动化系统软件支持业务的相关工作。
软件支持处在领导小组的领导下，负责软件支持的日常管理工作。
软件支持中心在软件支持处的直接领导下，承担自动化系统故障调查分析、
软件及补丁管理、测试验证、版本控制等软件支持工作。
地区运行管理组作为各地区自动化系统软件支持工作的管理者，接受领导小
9
组的业务管理，全面负责本地区自动化系统软件支持业务的相关工作。
软件数据管理组作为地区运行管理组的日常办事机构，代表地区运行管理组
处理日常事务，同时具体负责实施本地区的软件和数据管理业务，包括组织实施
系统故障分析、PCR 报告提交、新版软件和补丁现场测试安装、数据管理等相
关工作，为地区运行管理组的决策提供依据。
系统供应商作为自动化系统的提供者，承担软件源代码修改、工厂测试验证
等工作。
下图表示自动化系统软件支持业务中各相关部门之间的关系。
指导联系
软件支持中心
软件数据管理组
指导联系
软件版本发布，离线数据版本控制交互联系
交互联系
汇报联系
自动化生产厂商
交互联系
指导联系
汇报联系
各地区技术部门
各现场故障报告联系
领导小组
软件支持处
图一、软件支持业务组织结构图
10
第二章故障管理
2.1 业务说明
故障管理业务由各地区的软件数据管理组与软件支持中心共同负责。软件数
据管理组及相关人员对出现的故障进行应急处理和初步分析，并收集故障的相关
数据，提交到软件支持中心；软件支持中心对出现的系统故障进行记录、分析，
查找故障原因，建立PCR，提出解决办法，在有授权的情况下，解决故障；各
现场和软件支持中心发现重大故障需要及时报地区运行管理组和领导小组。故障
管理主要包括以下内容：
 故障发现及报告；
 故障调查；
 故障分析过滤；
 故障诊断；
 故障等级确定；
 PCR 报告建立；
 故障解决、归档和管理。
2.1.1 故障来源
系统运行过程中，故障主要来源于：
 各现场的运行平台，包括各地ACC、TMA，RTWR 以及TCU 平台等；
 上述各现场TEB 平台；
 软件支持中心测试/评估平台；
 系统供应商；
 其它来源。
2.1.2 故障严重程度/优先级初步确定和故障报告提交
在EUROCAT-X 自动化系统OPS 平台和TEB 平台发现的故障，由相关技术
人员和各地区软件数据管理组首先对故障进行应急处理、初步分析、判断，并确
定故障的严重程度和处理的优先级，由软件数据管理组统一提交故障报告给软件
支持中心。软件支持中心根据各现场提交故障报告的等级，经技术分析测试后，
形成相应等级的PCR，并提交系统供应商。
删除的内容: 软件支持业务
的工作流程
软件支持业务的核心工作是
软件版本的更新及离线数据
的更新，软件版本更新是解决
软件故障的最终手段，也是软
件功能变化的实现手段，它需
要软件支持业务的全部相关
部门的共同参与。
一个软件版本的更新是由于
软件源代码更新产生的，它需
要进行软件源代码验证，源代
码编译，SSF 测试，CCB 批
准下发，现场TEB 测试，CCB
批准新版本软件发布，现场新
版本软件安装，现场OPS 验
证/测试，现场新版本软件运
行等步骤，此外还需要对软件
的源代码更新及新版本软件
提供版本控制及版本管理的
服务，在这个步骤中产生的文
档也需要进行规范化，以保证
各部门之间实际运作的可控
性及规范性。
下图描述软件版本更新的概
要流程
... [1]
11
严重程度是指从技术角度上，该故障对自动化系统软件运行所造成的影响程
度，严重程度的划分等级和标准如下表：
严重程度标准故障举例
S1 致命故障，系统基本功
能无法实现
频繁发生的整个系统死机
无法接受的MMI 频繁死机
频繁发生的关键服务器死机
在模拟训练平台上频繁的练习重新启动
S2 严重故障，某个运行功
能严重受到影响
某个MMI 频繁死机（每2 小时一次）
某些关键功能无法实现，如无法创建某一类的飞
行计划，进程单上显示的主要内容出错等
S3 一般故障，某个运行功
能受到影响，但是可以
通过实施相应的处理方
式加以解决；给使用者
带来不便，但不影响主
要功能的实现。
如，无法及时显示、删除飞行条、无法及时触发
移交等
对于发生的故障，除定义严重程度外，还应该定义故障的优先级，表示故障
的紧急程度。
故障优先级划分，应该根据故障对运行部门日常管制工作的影响程度来决
定。某些严重故障由于对运行部门的影响不大，其优先级相对较低，例如某些不
经常出现的故障、可以通过实施管理手段避免出现的故障、仅在模拟系统出现的
故障；而有些严重程度低的故障由于对运行系统影响非常大，需要解决的优先级
很高，如发生频率较高的故障或者在每个管制席位上都可能出现的故障。
现场运行部门根据故障对日常运行的影响程度，按下表的定义确定故障解决
的优先级。
优先级定义确定的标准
P1 非常紧急基本管制功能无法实现，严重影响到管制部门的日常运行
P2 紧急部分管制功能无法实现，影响到管制部门的日常运行
P3 普通次要管制功能无法实现，不严重影响到管制部门的日常运行
P4 低需要加以解决，但不紧急，如某些文档错误、轻微的非关键错误
P5 非常低不要求必须解决
12
在初步确定好故障的严重程度和优先级以后，由各现场的技术人员和管制人
员负责收集与故障有关的数据，包括：发现的阶段、编号、故障点、故障类别、
故障发生的地点、时间、所用的节点名称、扇区、当时的系统配置、所用的软件
版本、离线数据版本、相关的文档、故障现象的详细描述、故障严重程度和优先
级等有关信息，并附上故障发生时的日志等各类记录文件，填写统一的《故障报
告表》，通过运行事件管理系统、传真、电子邮件三种方式之一提交到软件支持
中心。
在软件支持中心平台发现的故障由软件支持中心的技术人员根据上述标准
初步确定故障的严重程度和优先级，收集故障的详细信息，存入运行事件管理系
统。
当出现影响系统正常运行的重大故障时，发现故障的现场必须及时向所在地
地区运行管理组及领导小组报告。
2.1.3 故障的分析、诊断和分类
故障的分析、诊断和分类由各地区软件数据管理组和软件支持中心，根据故
障报告及相关信息共同完成。
初步分析、过滤
故障发生后，各地区软件数据管理组和相关技术人员应立即进行应急处理，
保障系统正常运行,并进一步对故障类型进行初步分析和诊断，属于系统本身软
件缺陷的，将《故障报告表》、日志等相关信息提交软件支持中心。
对于各现场提交的故障报告，软件支持中心技术人员根据现场报告的故障严
重程度和优先级，结合实际情况，来确定解决故障的次序。
对于故障报告，软件支持中心技术人员首先进行初步的分析，查看所提供的
故障信息是否准确、全面，所提供的记录文件是否正确，在故障调查过程中，现
场有义务配合软件支持中心收集正确、详尽的相关信息。
根据故障报告的信息，软件支持中心技术人员对故障做出初步的评估和分
类：
 对系统需求理解错误而提交的“故障”
如果由于对系统需求理解错误而提交的故障，软件支持中心应在《故障报告
表》调查结果描述内容里加以说明，通过运行事件管理系统、传真、电子邮件三
种方式之一返回到现场。
如果运行部门和技术部门在系统运行过程中认为有必要修改系统设计，则需
13
要依据新需求的有关管理办法进行相应的处理。
 重复故障
根据故障的描述，可以明确判断为已建立但尚未解决的PCR，软件支持中
心应将现场提供的最新信息加入原有的PCR 报告，汇总后提交供应商。
如果PCR 已经关闭，但故障又重现，把现场提供的最新信息加入原有的PCR
报告，重新返回供应商。
如果上述故障已有应急解决方案，软件支持中心应及时通过运行事件管理系
统、传真、电子邮件三种方式之一返回到现场。
 系统内部故障
如果排除了上述几种故障，其他的故障将被视为系统内部故障，软件支持中
心需要对故障进行进一步的分析和处理。
系统内部故障的诊断和处理
对于系统内部故障，软件支持中心技术人员根据故障报告中的故障描述信
息，以及相应的系统日志等相关记录文件，利用专用软件工具或其它方式，在软
件支持中心的平台上进行模拟、测试，重现故障，进一步加以分析，查找故障原
因，寻求解决方案。
根据不同类型的故障，采取不同的处理方式：
 硬件故障
如果确定是硬件故障，软件支持中心应在《故障报告表》的故障描述内容中
描述故障诊断的过程及其分析、诊断的结论和解决方案，通过运行事件管理系统、
传真、电子邮件三种方式之一返回到现场。现场根据相应的相关规程进行处理。
 操作不当造成的故障
如果由于现场运行部门操作方法不当导致系统相应错误或软件运行错误，
软件支持中心应在《故障报告表》中描述故障诊断的过程及其分析、说明正确的
操作方法、提供建议的解决方案，通过运行事件管理系统、传真、电子邮件三种
方式之一返回到现场。现场根据相应的相关规程进行处理。
 离线数据定义不正确造成的故障
如果由于离线数据定义不正确而导致系统运行出现故障，由软件支持中心提
供解决方案，在《故障报告表》中描述故障诊断的过程并说明更改方法，通过运
行事件管理系统、传真、电子邮件三种方式之一返回到现场。现场根据相应的相
关规程进行处理。
 系统配置出错
如果经过分析，确定是由于系统配置不当而导致的故障，软件支持中心在《故
14
障报告表》中描述故障诊断的过程及故障的分析和说明，此外软件支持中心在其
平台上修改相关的配置文件，并测试通过后，将正确的配置返回现场。如果需要
各现场修改配置，并重新安装软件，具体的操作流程见《新版本管理》相关章节。
 软件设计缺陷/错误
软件支持中心技术人员通过对故障进行详细分析后，如果认为系统软件设计
存在缺陷或错误，应提交相应等级的PCR 给系统供应商，并根据合同的规定，
要求系统供应商在规定时间内给予解决。
在系统供应商提出最终的解决方案之前，软件支持中心应该与相关地区软件
数据管理组共同协商，提出应急解决方案，并报领导小组审核、通知各相关现场，
以确保在系统供应商解决问题前，为运行部门提供有效的技术支持。
 其它故障
对于其它暂时无法判定原因的故障，软件支持中心应及时通报系统供应商，
同时根据故障现象和有关信息，在软件支持中心平台上进行模拟，设法重现故障，
并通过分析相关记录文件，查找故障原因，寻求解决方案。
2.1.4 故障的最终解决
所有故障都应该有完整的生命周期，故障解决过程中的不同阶段，都应该有
不同的状态，故障的最终解决才是生命周期的结束。故障是否最终解决由提交故
障现场测试后决定，当故障被最终解决后，现场将软件支持中心返回的故障报告
表的最终状态标为结束，再通过运行事件管理系统、传真、电子邮件三种方式之
一到软件支持中心；如现场认为该故障未最终解决，将原因增加到故障报告表，
再次提交给软件支持中心，由软件支持中心继续诊断处理。
非软件原因引起的故障
对于非软件原因引起的故障，相关现场根据软件支持中心返回故障报告表所
提供的故障原因和解决方案，根据相关流程加以解决。在现场的运行人员确认故
障不复存在以后，现场将软件支持中心返回的故障报告表的最终状态标为结束，
提交回软件支持中心。
软件原因引起的故障
对于软件原因引起的故障，由领导小组授权软件支持中心发布新的软件版本
或各地区运行管理组申请相关软件补丁加以解决，（相关管理规定见新版本管理
和软件补丁管理章节）对于S1、S2、S3P1 级别的PCR 各提出现场应以软件补丁
的形式及时安装更新。
在领导小组规定时间内，各地区运行管理组应负责组织完成软件版本或软件
15
补丁的更新，如果现场运行人员确认故障不复存在，应在更新后一个月内将故障
报告表的最终状态标为结束，提交回软件支持中心。
2.1.5 故障数据库的管理办法
软件支持中心负责故障数据库的管理、备份等工作，各地区软件数据管理组
可以通过运行事件管理系统来完成PCR 的建立、查看、编辑、整理、备份等工
作。
2.2 业务范围和职能划分
2.2.1 业务范围
故障管理业务的工作范围包括以下几个方面：
 故障发现：现场技术维护人员和管制人员发现故障后向本地区软件数据
管理组提交故障记录。
 一级维护处理：现场根据一级维护处理流程，排除故障，保证系统正常
运行。
 现场数据的收集：现场收集与故障相关的数据，填写《故障报告表》，
要求故障现象描述详尽、完整准确。
 初步调查分析：现场需要确保所收集现场数据的准确性，初步排除由硬
件等非软件引起的故障，并将故障报告表，提交软件支持中心以便进一
步调查分析。
 故障信息：软件支持中心搜集各现场所提交的故障信息，确认故障分析
所需的信息完整可用。
 故障分析：软件支持中心依据所收集到的现场数据和故障现象描述，分
析各地提交的软件故障，运用专用软件工具或其它方式，确定问题所在。
 解决方案：软件支持中心根据分析结果，提出解决方案。对软件缺陷/
错误或软件配置错误原因引起的故障，在合同保修期内，向系统供应商
提交PCR，要求其按合同尽快解决问题；保修期过后，则依据相关管理
规定办理。
 PCR 建立：软件支持中心根据各地故障报告的严重程度及优先级，经与
现场交流和确认后，建立相应的PCR 报告。
16
 软件故障报告库的管理：跟踪软件故障发现、诊断和处理的整个过程，
软件支持中心整理完善软件故障报告，记录在自动化系统运行事件管理
系统中。
 系统日志：系统日志记录系统运行过程中的关键信息，对故障的发现和
排除具有非常重要的作用。各地现场对与故障有关的系统日志进行收
集，软件支持中心对故障调查所需的重要系统日志进行整理和归档保
存。
2.2.2 业务职能划分
软件支持中心在整个故障处理过程中，均提供相应的技术支持。结合故障管
理业务范围，软件支持中心和各地软件数据管理组业务职能划分如下：
各地软件数据管理组负责：
 故障信息的收集
 初步调查分析
 提供技术支持
 解决故障
 保存系统日志
 重大故障报告运行管理组
软件支持中心负责：
 确认故障信息
 故障分析
 提出解决方案
 软件故障报告库的管理
 整理和归档系统日志
 重大故障报告领导小组
2.3 工作流程
故障处理工作流程如下图所示：
17
图二、故障处理流程图
2.4 业务相关文档
《故障报告表》的中文版参见附件一；
《故障报告表》的英文版参见附件二；
《故障报告表》样例表及填表说明参见附件三。
18
第三章离线数据管理
3.1 业务说明
3.1.1 概述
EUROCAT-X 自动化系统使用了大量种类繁多的离线数据，这些离线数据通
过EUROCAT-X 自动化系统DPR 工具来操作管理。离线数据由领导小组、软件
支持中心、地区运行管理组进行分类管理。
离线数据是EUROCAT-X 自动化系统的重要组成部分，直接影响到自动化系
统的功能设置和正常运行。为了对EUROCAT-X 自动化系统离线数据的使用进行
规范化管理，必须对所有离线数据进行详细分类并建立完善的管理规定和工作流
程。
离线数据管理主要包括以下内容：
 离线数据修改需求
 离线数据修改方案
 离线数据修改申请
 离线数据测试和评估
 离线数据审批
 离线数据修改
 离线数据检查
 离线数据发布
 离线数据有效性测试
 离线数据统一备份和版本管理
3.1.2 离线数据的分类
EUROCAT-X 自动化系统的离线数据非常庞大，很多数据对系统的运行至关
重要，如果数据设置错误，可能会导致整个系统无法正常运行。为了提高数据管
理效率，确保系统运行安全，需要根据其影响范围和性质，将离线数据分类：
 全局数据
指EUROCAT-X 自动化系统中涉及所有分区的离线数据，该类数据直接影响
到系统中所有分区的运行。
 本地数据
19
指EUROCAT-X 自动化系统中仅涉及本地分区的离线数据，该类数据只影响
到该分区的运行。
根据数据项对系统运行的影响程度，上述两类数据还可分为以下三种类型：
 核心数据
指对EUROCAT-X 自动化系统运行和安全有致命影响的离线数据。
此类数据直接影响到整个EUROCAT-X 自动化系统的运行性能，如果数据定
义错误，可能会导致系统无法正常运行。此类数据与各现场的具体运行环境无关，
而且一旦确定之后，不应轻易修改。
 关键数据
指对EUROCAT-X 自动化系统运行和安全有重大影响的离线数据。
此类数据与各现场的具体运行环境有关，如果数据定义错误或者各现场的数
据不匹配，可能会导致系统某些关键功能无法正常运行。
 运行数据
指对EUROCAT-X 自动化系统运行和安全没有重大影响的离线数据。
此类数据与各现场的日常运行工作密切相关，但对数据的修改不会导致系统
性的致命故障。各现场由于运行需求、外部接口和运行环境不同，此类数据的设
置也有所不同。
具体离线数据的分类参见附件四《EUROCAT-X 自动化系统离线数据分类》。
3.2 业务范围和职能划分
离线数据管理业务涉及领导小组、软件支持中心、地区运行管理组和软件数
据管理组，以下是各部门的业务范围和职能：
3.2.1 领导小组的业务范围和职能
 受理各地区运行管理组或软件支持中心提交的《离线数据修改表》。
 安排软件支持中心和各现场进行测试和评估。
 负责根据软件支持中心和各现场提交的《离线数据测试评估报告》对核
心数据和关键数据的修改进行审批，并下发到各地区运行管理组。
 根据软件支持中心提交的《离线数据修改建议》，将离线数据修改要求
下发到各地区运行管理组。
20
3.2.2 软件支持中心的业务范围和职能
 统一归档EUROCAT-X 自动化系统的离线数据， 包括各现场
EUROCAT-X 自动化运行系统和模拟培训系统的离线数据，软件支持中
心至少应该保留各地两个最新版本的离线数据。
 负责软件支持中心测试评估平台的所有离线数据的修改、更新、备份和
版本管理。
 对系统供应商提出离线数据修改建议进行测试和评估，并将《离线数据
测试评估报告》提交领导小组。
 在故障调查和测试基础上提出离线数据修改建议，并提交领导小组发布
到各地区运行管理组。
 对各地区运行管理组提交的核心和关键离线数据修改需求进行测试和
评估，并将《离线数据测试评估报告》提交领导小组。
 协助各地区软件数据管理组对部分离线数据进行测试和评估。
 为各地离线数据的修改提供技术支持。
3.2.3 各地区运行管理组的业务范围和职能
 根据领导小组下发的离线数据修改要求，安排软件数据管理组进行数据
测试和修改。
 对软件数据管理组提交的《离线数据修改表》进行协调和审批，必要的
情况下，可以要求软件数据管理组对部分离线数据进行测试和评估。
 对软件数据管理组提交的核心离线数据和关键离线数据的《离线数据修
改表》进行初步审批，并将申请表提交领导小组。
 负责协调并确定离线数据的发布时间。
 必要时负责离线数据发布的现场总协调工作，并负责组织需求提出单位
共同确认数据的有效性和系统运行功能的正确性。
3.2.4 软件数据管理组的业务范围和职能
 根据现场需求，填写《离线数据修改表》。
 根据领导小组下发的《离线数据修改建议》，填写《离线数据修改表》。
 根据地区运行管理组的要求，对部分离线数据进行测试和评估，并向地
21
区运行管理组提交《离线数据测试评估报告》。
 根据已经批复的《离线数据修改表》，实施所有离线数据的修改和准确
性检查。
 负责本地区现场离线数据的发布和更新。
 离线数据生效后，协助地区运行管理组组织需求提出单位共同确认数据
的有效性和系统运行功能的正确性。
 负责本地区现场所有离线数据的备份。
 负责本地区现场离线数据的版本管理工作，确保在用离线数据的一致性
和完好性。
 对离线数据发布过程中出现的问题进行分析和解决。
3.3 工作流程
3.3.1 离线数据的申请
根据EUROCAT-X 自动化系统的运行情况和现场需求，由软件数据管理组填
写《离线数据修改表》，并提交地区运行管理组进行审批。具体填写项目和要求
参见附件五。
对于现场提出的核心离线数据和关键离线数据的修改，由软件数据管理组填
写《离线数据修改表》，经该地区运行管理审批后，提交给领导小组审批。
对于厂商或软件支持中心提出的核心离线数据和关键离线数据的修改，由软
件支持中心填写《离线数据修改建议》，提交给领导小组审批。
地区运行管理组根据下发的《离线数据修改建议》，安排软件数据管理组填
写《离线数据修改表》。
3.3.2 离线数据的测试评估
为了确保离线数据修改方案的准确性，对部分需要修改的离线数据进行必要
的测试和评估。
对运行离线数据的测试和评估主要包括：
 软件数据管理组根据相关技术文档对离线数据的具体修改方案进行评
估。
 在必要时，软件数据管理组或软件支持中心在测试、模拟、培训平台对
离线数据进行测试和评估。
22
 由软件数据管理组或软件支持中心完成《离线数据测试评估报告》。
对核心离线数据和关键离线数据的测试和评估主要包括：
 由软件支持中心进行测试和评估。
 软件支持中心完成《离线数据测试评估报告》，提交领导小组进行审批。
如果评估结果认为离线数据修改方案有误，需要调整离线数据修改方案，修
改《离线数据修改表》，并按上述流程重新进行评估。
3.3.3 离线数据的审批
 地区运行管理组负责运行离线数据的协调和审批工作，以及核心离线数
据、关键离线数据的初步审批工作。
 领导小组负责核心离线数据和关键离线数据的协调和审批工作。
3.3.4 离线数据的修改
根据审批的《离线数据修改表》，由软件数据管理组本地成员负责本地数据
的修改工作；由地区运行管理组授权的软件数据管理组成员负责全局数据的修改
工作。
软件支持中心负责修改软件支持中心测试验证平台的离线数据。
对于各现场模拟培训平台所需要的离线数据的修改和发布由各现场的软件
数据管理组和管制部门共同完成。
3.3.5 离线数据的准确性检查
所有离线数据被修改后，软件数据管理组需要对比《离线数据修改表》进行
检查，以确保数据修改的准确性。其中软件数据管理组的本地成员负责本地数据
的检查工作；由地区运行管理组授权的软件数据管理组成员负责全局数据的检查
工作。原则上修改离线数据的人员不参与该次修改的检查工作。
检查工作主要包括：
 直观检查
将所修改的数据与《离线数据修改表》对照，以避免录入错误。
 文件比较工具检查
通过文件比较工具(如diff 工具)，比较新老数据，以确保修改内容的正确性。
23
 其它手段检查
采用其它技术手段进行检查。
检查结束以后，检查人员要在《离线数据修改表》的相关项目上签字。
如果在检查过程中发现错误，由软件数据管理组负责修改完善。
软件支持中心技术人员负责软件支持中心测试验证平台的离线数据检查工
作。
3.3.6 离线数据的发布更新
地区运行管理组负责协调并确定离线数据的发布更新时间，由软件数据管理
组根据具体的数据发布流程组织实施离线数据的发布。原则由软件数据管理组的
本地成员负责本地离线数据的发布、由软件数据管理组负责组织各地成员共同配
合完成全局离线数据的发布。必要时由地区运行管理组负责数据发布现场的总协
调工作。
对于核心离线数据和关键离线数据的发布和更新，必要时由领导小组协调各
地区运行管理组确定合适的发布时间，由各地区的软件数据管理组共同完成。
软件支持中心测试验证平台的离线数据的发布更新由软件支持中心技术人
员负责完成。
3.3.7 离线数据的运行测试和验证
离线数据更新后，需要对有关的系统功能进行测试，以确保离线数据的有效
性。
 对于本地离线数据，由软件数据管理组的本地成员与数据修改提出单位
的相关人员共同进行测试和验证。
 对于全局离线数据，由地区运行管理组负责组织软件数据管理组成员与
数据修改提出单位的相关人员共同配合完成测试和验证。
 对于核心离线数据或关键离线数据，由地区运行管理组负责组织软件数
据管理组以及相关单位人员共同配合完成测试和验证。
 对于软件支持中心测试验证平台的离线数据，由软件支持中心技术人员
完成测试和验证。
如果在测试和验证过程中发现问题，根据问题的严重程度，由地区运行管理
组决定是否回滚，并由软件数据管理组具体组织实施。
24
3.3.8 离线数据的备份和版本管理
软件支持中心统一归档EUROCAT-X 自动化系统的所有离线数据，包括各现
场运行系统、模拟培训系统和软件支持中心测试评估平台的离线数据。软件支持
中心至少应该保留各地两个最新版本的离线数据。
各地区软件数据管理组负责统一进行各分区离线数据的备份和版本管理工
作，同时也负责统一管理《离线数据修改表》，《离线数据测试评估报告》。（有关
离线数据版本管理参见本文档的相关章节）
各地区软件数据管理组在修改和更新运行系统离线数据以后的规定时间内
（一个月内），应将最新的离线数据版本号和具体的离线数据以可靠的方式提交
软件支持中心，进行统一归档。
必要时，软件支持中心可以要求各现场软件数据管理组提交在用的离线数据
版本号和具体的离线数据。
3.3.9 离线数据修改管理流程
1．核心离线数据的修改更新流程
流程图如下所示：
图三、核心离线数据修改更新流程
核心数据一般由软件支持中心根据运行需要提出修改需求，或由系统供应商
25
提出修改建议，可能需要各现场统一进行修改和发布更新。
具体的修改更新流程如下：
1. 软件支持中心根据运行需要提出修改需求，或由系统供应商提出修改建
议。
2. 软件支持中心填写《离线数据修改建议》,并在软件支持中心测试评估平
台上进行测试。
3. 必要时由领导小组指定在某个或所有现场的模拟培训平台上进行进一
步测试。
4. 软件支持中心和现场地区运行管理组根据测试评估结果，分别填写《离
线数据测试评估报告》，提交领导小组审批。
5. 领导小组将审批后的《离线数据修改建议》和《离线数据测试评估报告》
发布到各地区运行管理组。
6. 各地区软件数据管理组根据下发的《离线数据修改建议》，填写《离线
数据修改表》，并上报地区运行管理组审批。
7. 各地区软件数据管理组组织修改离线数据，并进行检查。
8. 地区运行管理组协调并确定离线数据的发布更新时间。
9. 各地区软件数据管理组负责各现场的离线数据发布更新。
10. 各地区软件数据管理组负责离线数据的备份和版本管理，并定期提交软
件支持中心统一归档。
2．关键离线数据的修改更新流程
流程图如下所示：
图四、关键离线数据修改更新流程
26
具体修改更新流程如下：
1. 由软件数据管理组根据运行需求，填写《离线数据修改表》。
2. 提交地区运行管理组审批。
3. 地区运行管理组将《离线数据修改表》提交领导小组进行协调和审批。
4. 领导小组要求软件支持中心进行测试和评估。
5. 必要时由领导小组指定在某个或所有现场的模拟培训平台上进行进一
步测试。
6. 软件支持中心和各地区运行管理组根据测试评估结果，分别填写《离线
数据测试评估报告》，提交领导小组审批。
7. 领导小组将审批后的《离线数据修改表》和《离线数据测试评估报告》
下发到各地区运行管理组。
8. 如果各地区间的离线数据需互相匹配，领导小组负责协调各相关地区运
行管理组，并确定离线数据的统一发布更新时间。
9. 各地区软件数据管理组根据《离线数据修改表》，修改离线数据。
10. 各地区软件数据管理组组织实施离线数据的发布、更新、测试和验证。
11. 各地区软件数据管理组负责离线数据的备份和版本管理，并定期提交软
件支持中心统一归档。
3．运行离线数据的修改更新流程
流程图如下所示：
图五、运行离线数据修改更新流程
具体的修改更新流程如下：
1. 根据现场运行需要，由软件数据管理组填写《离线数据修改表》。
2. 必要时，在模拟培训系统（TEB 平台）进行测试和验证。
27
3. 将《离线数据修改表》和《离线数据测试报告》提交该地区运行管理组
审批并协调确定发布时间。
4. 软件数据管理组根据《离线数据修改表》修改数据。
5. 软件数据管理组将修改后的离线数据发布到各现场运行系统，并进行测
试和验证。
6. 各地区软件数据管理组负责离线数据的备份和版本管理，并定期提交软
件支持中心统一归档。
4. 全局离线数据的修改更新流程
流程图如下所示：
图六、全局离线数据修改更新流程
具体的修改更新流程如下：
1. 根据现场运行需要，由需求所在地的软件数据管理组成员填写《离线数
据修改表》。
2. 软件数据管理组负责组织在模拟培训平台上对相关数据进行测试评估。
3. 软件数据管理组将《离线数据测试评估报告》提交地区运行管理组审批，
并由地区运行管理组协调各现场，确定发布时间。
4. 软件数据管理组成员根据《离线数据修改表》的要求修改数据，并协同
需求方验证数据修改的正确性。
5. 由软件数据管理组负责将修改后的离线数据发布到各现场运行系统。
28
6. 地区运行管理组负责组织相关单位人员共同进行运行功能测试和验证，
并由需求方确认数据修改的正确性。
7. 软件数据管理组负责离线数据的备份和版本管理。
8. 各地区软件数据管理组定期将修改后的离线数据提交软件支持中心统
一归档。
9. 对于其中属于核心离线数据和关键离线数据的数据修改，参照相关的操
作流程。
5. 本地离线数据的修改更新流程
流程图如下所示：
图七、本地离线数据修改更新流程
具体的修改更新流程如下：
1. 根据现场运行需要，由需求提出所在地的软件数据管理组成员填写《离
线数据修改表》，并提交地区运行管理组审批。
2. 在需要的情况下，可以由地区运行管理组指定的软件数据管理组成员对
离线数据进行测试评估，并将《离线数据测试报告》提交地区运行管理
组审批。
3. 软件数据管理组根据《离线数据修改表》的要求修改数据，并协同需求
方确认数据修改的正确性。
4. 地区运行管理组负责协调并确定数据发布时间，软件数据管理组本地成
29
员负责将修改后的离线数据发布到现场运行系统、并组织现场相关单位
人员共同进行运行功能测试和验证。
5. 软件数据管理组负责离线数据的备份和版本管理。
6. 各地区软件数据管理组定期将修改后的离线数据提交软件支持中心统
一归档。
7. 对于其中属于核心离线数据和关键离线数据的数据，参照相关的操作流
程。
3.4 业务相关文档
《离线数据修改表》的格式和填表说明见附件五。
《离线数据测试评估报告》的格式和填表说明见附件六。
《离线数据修改建议》的格式和填表说明见附件七。
30
第四章新版本软件管理
4.1 业务说明
安装自动化系统新版本软件是解决系统存在的问题和设计缺陷，实现和完善
自动化系统相关功能的主要途径。新版本软件管理业务主要包含以下内容：
 新版本软件的审核和确认；
 新版本软件的PCR 测试；
 新版本软件的功能测试；
 新版本软件的稳定性测试；
 新版本软件有关文档的审核和确认；
 新版本软件的审批和发布；
 新版本软件的安装、验证；
 新版本软件的版本管理。
4.2 业务范围和职能划分
新版本软件管理业务涉及领导小组、软件支持中心、地区运行管理组和软件
数据管理组等相关部门，以下是各部门的业务范围和职能。
4.2.1 领导小组的业务范围和职能
领导小组全面负责新版本软件的管理工作。
领导小组依据软件支持中心提交的软件支持中心平台新版本测试报告以及
各地区运行管理组提交的TEB 平台新版本测试报告进行审批，并决定是否发布
新版本软件。
4.2.2 软件支持中心的业务范围和职能
软件支持中心负责对系统供应商提供的新版本软件和版本说明文档进行审
核和确认，制定新版本软件的测试计划，并在软件支持中心平台对新版本软件进
行编译和测试，包括PCR 测试、功能测试和稳定性测试等，最终形成新版本软
件和相关测试报告，经领导小组审批确认后发布到各地区运行管理组，同时为各
现场新版本软件的相关工作提供技术支持。
31
新版本软件的审核和创建
 根据版本说明文档（VDD）对新版本软件进行审核，确定新版本软件所
涉及的计算机软件配置项（CSCI）的正确性。
 对新版本软件进行编译，生成新的目标文件。
 创建新版本软件。
新版本软件测试
 制定新版本软件测试计划。
 根据测试计划将新版本软件安装在软件支持中心平台进行PCR 测试和
功能测试。
 如果新版本软件通过软件支持中心的PCR 测试和功能测试，软件支持
中心向领导小组提交测试报告，申请在各地区的TEB 平台进行测试，
同时在软件支持中心平台继续进行稳定性测试和其它测试。
 负责收集新版本软件测试中产生的PCR，明确PCR 的影响范围和程度，
并在测试报告中明确新版本软件的安装建议。
 新版本软件所有测试完成后，软件支持中心正式向领导小组提交完整的
新版本软件测试报告。
新版本软件的发布
 新版本软件通过领导小组审批后，软件支持中心根据软件和离线数据版
本管理规则，设定新版本软件和离线数据的版本号，将新版本软件发布
到各地区运行管理组。
 以下文档随同新版本软件发布到各地区运行管理组：
 新版本软件的版本说明文档（VDD）。包括新版本软件的目的，
所包含的ECR 和PCR，新版本软件和上一版本的变化（软件及
配置文件的变化，功能的变化等），新版本软件的影响功能和范
围等。
 新版本软件的系统离线数据及说明文档（DDD）。包括新版本软
件的系统离线数据所涉及的变化和选定的参数等。
 新版本软件相关的技术文档。
 新版本软件和离线数据的安装说明。
 新版本软件所有涉及的其它文档。包括新版本软件的发布、安
装、运行操作和维护支持等文档。
新版本软件相关工作的技术支持
 为了保证各现场顺利更新自动化系统软件，软件支持中心应为各现场新
32
版本软件的相关工作提供技术支持。
4.2.3 地区运行管理组的业务范围和职能
地区运行管理组负责组织新版本软件在TEB 平台的测试，并将测试报告提
交领导小组。此外，地区运行管理组负责本地自动化系统新版本软件的审核，安
装审批和安装时间的确认，并组织和协调新版本软件的安装。
新版本软件的测试
 根据领导小组的要求，各地区运行管理组在规定的时间内负责组织新版
本软件在本地区TEB 平台的测试。
 根据软件数据管理组提交的新版本软件测试中产生的PCR，明确PCR
的影响范围和程度，并在TEB 平台测试报告中明确新版本软件的安装
建议。
 根据领导小组的要求，各地区运行管理组在规定时间内将TEB 平台测
试报告提交领导小组，作为领导小组审批和发布新版本软件的依据。
新版本软件的审核和安装审批
 审核和明确新版本软件和离线数据版本号。
 审核新版本软件所有相关文档的完整性和正确性。
 负责审批和协调本地区新版本软件的安装时间。
 新版本软件的安装时间应避开重要会议、大型体育赛事和运输高峰期
等。
新版本软件安装的组织和协调
 明确各现场新版本软件的安装人员。
 将新版本软件的影响范围和安装时间等及时通知相关部门。
 将软件支持中心提供的新版本软件磁带和相关文档提交给软件数据管
理组。
 负责组织和协调新版本软件在本地区的安装。
 根据新版软件工作情况，决定是否需要回滚至老版本软件。
 新版软件正式运行一周内，将新版本软件安装及运行情况上报领导小
组。
33
4.2.4 软件数据管理组的业务范围和职能
各地区软件数据管理组负责新版本软件在TEB 平台的安装和测试，负责新
版本软件在运行平台的安装和测试验证。
新版本软件的初验
 验证新版本软件及相关文档的正确性、一致性和完整性。
新版本软件TEB 平台的测试
 各地区软件数据管理组负责将新版本软件安装到TEB 平台，并组织相
关人员进行PCR 测试、功能测试和稳定性测试。
 负责收集和整理新版本软件测试中产生的PCR，并及时提交软件支持中
心。
 完成TEB 平台测试报告，并提供新版本软件的安装建议，上报本地区
运行管理组。
新版本软件的安装和测试验证
 根据相关文档制定新版本软件升级的操作步骤，供相关技术人员参考和
使用。
 准备《新版本软件安装报告表》。
 负责当前软件版本和离线数据版本的备份。
 在规定的时间内，将新版本软件安装到运行平台，并对新版本软件进行
测试和验证。
 如果新版本软件工作不正常，经地区运行管理组决定后，由软件数据管
理组负责将系统回滚至原来版本，并确保系统正常运行。填写《故障报
告表》，并报本地区运行管理组。
 将新版本软件安装及运行情况及时上报本地区运行管理组。
4.3 工作流程
流程图如下所示：
34
$
$
图八、新版本软件管理工作流程图
具体流程如下：
1. 软件支持中心对系统供应商提供的新版本软件和相关文档进行初步审
核和验证，如发现新版本软件存在问题，需要将其返回系统供应商。通
过审核的新版本软件，软件支持中心对其进行编译，创建新版本，并安
装到软件支持中心平台进行PCR 测试和功能测试。
2. 如果新版本软件通过软件支持中心的PCR 测试和功能测试，软件支持
中心向领导小组提交测试报告，申请在各地区的TEB 平台进行测试，
同时在软件支持中心平台继续进行稳定性等测试。如果未能通过测试，
软件支持中心将相关测试情况上报领导小组，并将新版软件返回系统供
应商。
3. 领导小组依据软件支持中心提交的新版本软件测试报告，确定是否将新
版本软件发布到各地进行TEB 平台测试。
4. 各地区运行管理组根据领导小组下发的文件要求，组织人员将新版本软
35
件安装到TEB 平台进行PCR 测试、功能测试和稳定性测试等，并将新
版本软件测试报告和安装建议上报领导小组。
5. 软件支持中心完成稳定性等测试后，正式向领导小组提交完整的新版本
软件测试报告和安装建议。
6. 领导小组依据软件支持中心和各地区运行管理组提交的新版本软件测
试报告，确定是否发布新版本软件。
7. 领导小组将新版本软件安装通知下发到软件支持中心和各地区运行管
理组，要求软件支持中心将新版本软件和相关文档发送到各地区运行管
理组，并要求各地区运行管理组在规定的时间内将新版本软件安装到运
行平台。
8. 软件支持中心制作新版本软件的现场安装磁带，并随同相关文档发送到
各地区运行管理组。
9. 各地区运行管理组安排本地区软件数据管理组负责新版本软件和相关
文档的审核和验证。
10. 各地区运行管理组协调确定各现场安装新版本软件的时间。
11. 各现场软件数据管理组负责在规定的时间内将新版本软件安装到本地
的运行平台，并进行测试验证，确保其运行稳定可靠。
12. 如果新版本软件运行不正常，依据地区运行管理组的决定，由软件数据
管理组负责回滚至原来的软件版本，并将存在的问题报告地区运行管理
组，由地区运行管理组上报领导小组。
13. 地区运行管理组在新版软件正式运行一周内，将新版本软件安装及运行
情况上报领导小组。
4.4 业务相关文档
《软件测试相关表格文件》参见附件八
《新版本软件发布说明表》参见附件九
《新版本软件安装报告表》参见附件十
36
第五章软件补丁管理
5.1 业务说明
软件补丁是对自动化系统软件的一种紧急修补，主要目的是为了尽快解决现
场出现的问题。软件补丁管理业务主要包含以下内容：
 软件补丁的审核和确认；
 软件补丁的测试；
 软件补丁的审批和发布；
 软件补丁的安装和验证；
 软件补丁的版本管理。
根据软件补丁对系统的影响程度和紧急程度，将软件补丁分为紧急补丁和重
要补丁。
 紧急补丁：适用于系统出现重大故障，而且没有应急解决措施的情况。
 重要补丁：适用于系统出现严重问题，但采取某种应急解决措施以后，
系统仍然可以安全运行的情况。
5.2 业务范围和职能划分
软件补丁管理业务涉及领导小组、软件支持中心、地区运行管理组和软件数
据管理组，以下是各部门的业务范围和职能。
5.2.1 领导小组的业务范围和职能
领导小组负责审批和发布自动化系统的软件补丁。
 领导小组受理各地区运行管理组提出的软件补丁安装请求。
 根据各地区运行管理组提出的软件补丁安装请示，下发文件要求软件支
持中心对有关补丁进行编译、制作和测试。
 根据软件支持中心提交的软件补丁测试报告，及时审批并确定是否发
布。
37
5.2.2 软件支持中心的业务范围和职能
软件支持中心负责对系统供应商提供的软件补丁和说明文档进行初步审核
和确认，根据领导小组的要求和供应商提供的修补源代码产生软件补丁，并在软
件支持中心平台进行测试，将测试结果和《软件补丁说明》文档上报领导小组，
将领导小组批准的软件补丁发布给申请软件补丁的地区运行管理组，同时对各现
场的软件补丁安装提供技术支持，并对软件补丁进行版本管理。
软件补丁的审核和创建
 根据软件补丁说明文档对软件补丁进行初步审核，确定软件补丁修改的
正确性。
 根据领导小组的要求和系统供应商提供的软件修补源代码制作软件补
丁。
软件补丁的测试
 根据软件补丁的等级和所涉及的CSCI，制定软件补丁的测试计划。
 根据软件补丁测试计划，将软件补丁安装在软件支持中心平台进行测试
和评估。测试内容应包含《软件基本功能测试》。
 软件支持中心需要在得到领导小组指示和系统供应商提供的软件修补
源代码后尽快完成测试，并向领导小组提交测试报告和《软件补丁说
明》。
软件补丁的发布
经过领导小组审批后，在规定的时间内将软件补丁随同《软件补丁说明》
和《软件补丁安装说明》两个文档发布到申请软件补丁的地区运行管理组。
 紧急补丁通过测试后，应在24 小时内发布到申请软件补丁的现场。
 重要补丁通过测试后，应在3 个工作日内发布到申请软件补丁的现场。
软件补丁的版本管理
 软件支持中心负责对软件补丁进行命名。软件补丁的命名方式为“{当
前软件版本号}－p{序号}”，根据在此版本软件中发布补丁的顺序来决
定补丁的序号，例如，XXX-V2.1.9-p1，为软件XXX-V2.1.9 版本的第一
个补丁。
 软件支持中心负责对发布过的软件补丁和有关文档进行归档和管理。
38
5.2.3 地区运行管理组的业务范围和职能
各地区运行管理组根据各现场自动化系统的运行情况，负责向领导小组提交
安装软件补丁的申请，并负责本地区软件补丁的审核、测试、安装审批和安装时
间的确认，同时组织和协调软件补丁的安装。
软件补丁的申请
 对软件数据管理组提交的软件补丁安装申请进行审核和评估。
 根据现场运行情况将软件补丁安装申请上报领导小组。
软件补丁的审核
 验证软件补丁及相关文档的正确性、一致性和完整性。
 根据软件补丁的影响范围和程度，确定需要安装软件补丁的现场。
软件补丁的测试
 必要时，各地区运行管理组在规定的时间内组织人员在本地区TEB 平
台进行测试。
软件补丁安装时间的确定和安装过程的协调
 将软件支持中心提供的软件补丁和相关文档下发软件数据管理组。
 协调并确定各现场软件补丁的安装时间。
 确定各现场软件补丁的安装人员。
 将软件补丁的影响范围、安装目的和安装时间等及时通知到相关部门。
 负责软件补丁安装全过程的组织和协调工作。
5.2.4 软件数据管理组的业务范围和职能
各地区软件数据管理组负责本地自动化系统软件补丁的安装和验证。
软件补丁的测试、安装和验证
 各地区软件数据管理组负责将软件补丁安装到TEB 平台，并组织相关
人员进行补丁测试。
 根据相关文档制定运行平台软件补丁安装的操作步骤，供安装人员参考
和使用。
 负责备份当前的软件版本和离线数据版本。
 在规定的时间内，将软件补丁安装到运行平台，并组织人员对系统的运
39
行和相关功能进行测试和验证。
 如果软件补丁工作不正常，经地区运行管理组决定后，由软件数据管理
组负责将系统回滚至原来版本，并确保系统正常运行。填写《故障报告
表》，并报本地区运行管理组。
 填写《软件补丁安装报告表》，并及时上报本地区运行管理组。
5.3 工作流程
流程图如下所示：
图九、软件补丁管理工作流程图
具体流程如下：
1. 地区运行管理组上报软件补丁安装请示。
2. 领导小组对地区运行管理组上报的软件补丁安装请示进行评估确认，指
示软件支持中心产生相应软件补丁。
3. 软件支持中心根据领导小组的要求和供应商提供的修补源代码产生软
40
件补丁并在软件支持中心平台进行测试验证，如发现软件补丁有问题，
需要将其返回供应商。
4. 软件支持中心经过对软件补丁进行测试验证，确保没有问题后，需要向
领导小组提交测试报告和《软件补丁说明》。
5. 领导小组审批软件补丁，如果同意发布软件补丁，则下发文件要求软件
支持中心将软件补丁发布到申请软件补丁的地区运行管理组。
6. 软件支持中心制作软件补丁的现场安装磁带，并随有关文档提交给申请
软件补丁的地区运行管理组。
7. 地区运行管理组负责本地软件补丁和相关文档的审核和验证，安排现场
软件数据管理组进行TEB 平台测试。
8. 现场软件数据管理组负责组织进行TEB 平台测试。
9. 地区运行管理组协调安装软件补丁的现场和安装时间。
10. 现场软件数据管理组成员负责在规定的时间内将软件补丁安装到本地
的OPS 平台，并对软件补丁进行验证，保证其运行稳定可靠。
11. 如果软件补丁不能在OPS 平台正常运行，现场软件数据管理组成员负责
将本地的OPS 平台切换回原来的软件版本运行，并将软件补丁存在的问
题报告本地区的地区运行管理组，由地区运行管理组上报领导小组。
5.4 业务相关文档格式
《软件补丁说明》参见附件十一
《软件补丁安装报告表》参见附件十二
《软件基本功能测试》参见附件十六
41
第六章版本控制
6.1 业务说明
6.1.1 概述
版本控制的主要目的是保持各现场软件、数据、文档等信息的规范化，版本
控制包含以下信息：
 软件源代码
 安装软件SYSREF
 离线数据
 软件相关技术文档
6.1.2 软件源代码的版本控制
软件源代码是指由自动化系统厂商提供的，用于编译产生可执行软件的
EUROCAT-X 各CSCI 的源代码。
软件源代码的版本控制是指为每一个可以使用的完整软件源代码分配一个
固定的，唯一的版本号码。
软件源代码版本命名规则
软件源代码版本号包含该版本软件的一些基本信息。软件源代码版本由两部
分组成，一部分为工厂版本号，也是日常使用的版本号，另一部分为版本在软件
支持中心生成的日期：
 工厂版本号指工厂发布新版本软件时确定的软件版本号码，例如V3.2.0。
 产生日期使用六字符年月日来标识，例如070318 代表2007 年3 月18
日。指SSF 接收到该版本软件的日期
根据命名规则，SSF 标示版本号码V3.2.0_070318 表示由SSF 在2007 年3
月18 日，得到厂方的软件源代码更新。
软件源代码版本数据一致性控制
每一次PCR/ECR 导致的源代码变更，都必须提交到在EUROCAT 软件源代
码库中的SSF 分支上。
42
完成提交后，需要形成一个版本号码，命名规则按照上文的规则执行，这个
版本号将作为SSF 分支的标记(Tag)，用于标识这个版本的软件源代码。
禁止人工直接修改软件源代码库，以避免发生源代码的冲突和不一致。软件
源代码必须从软件源代码库中导出（check out），以保持所有软件源代码都是可
以追溯的，而且是无冲突的。
6.1.3 安装软件的版本控制
安装软件是指可以在各现场安装运行的自动化系统软件，是由SSF 根据自
动化生产厂商提供的软件源代码编译产生的，具体来说，是用于软件安装的
SYSREF 安装包。
在EUROCAT-X 自动化系统的改进完善过程中， SSF 和各个现场
EUROCAT-X 中不可避免存在多个安装软件版本，因此，必须建立一套规范的安
装软件版本控制规定。
现场安装软件版本号命名规则
为了保证软件源代码版本与安装软件版本一一对应，安装软件版本号由“各
现场名_软件源代码编号”两部分构成。例如BJ_ V3.2.0。
安装软件版本完整性控制
为了保证各现场实际运行的安装软件与该版本的软件源代码保持一致，必须
在SSF 和各现场同时拥有一个该安装软件的拷贝，这个拷贝在这个版本的使用
期内不能销毁。
6.1.4 离线数据的版本控制
离线数据的版本控制必须保证：
 各地需要一致的离线数据的一致性
 各地协调数据的不冲突性
 各地自主处理数据的完备性
离线数据版本号命名规则
离线数据的版本号由三部分组成，命名规则为“产生者_产生日期_ _软件版
本号”。
 产生者指具体负责进行离线数据更新的机构，例如CCB，SSF，BJ，SH,GZ
等。
43
 产生日期使用六字符年月日来标识，例如040318 代表2004 年3 月18 日。
 软件版本号指使用该离线数据的软件版本号，如V2.1.7
根据命名规则BJ_070318_V3.2.0 表示由北京现场在2007 年3 月18 日对离
线数据进行修改，且在北京的V3.2.0 版软件上使用。
核心离线数据版本的一致性、不冲突性控制
当一个核心离线数据得到批准运行时，各现场必须保存正在运行的全部离线
数据，并形成拷贝。
各地按照新版本核心离线数据描述文件的要求，在现有运行离线数据的基础
上修改核心离线数据，在确认无误和测试以后，将这个修改后的离线数据的基本
版本号升级到新的基本版本号，分支版本号维持不变，并提交给SSF，SSF 应该
把这个拷贝存档连同它的两个版本号。
关键离线数据版本的一致性、不冲突性控制
为了保证离线数据版本的一致性，当一个关键离线数据得到批准运行时，各
现场必须保存正在运行的全部离线数据，并形成一个拷贝，这个拷贝应该得到保存。
各地按照新版本关键离线数据描述文件的要求，在现有运行离线数据的基础
上修改关键离线数据，在确认无误和测试以后，将这个修改后的离线数据的基本
版本号升级到新的基本版本号，分支版本号维持不变，这个修改以后的拷贝应该
得到保存，并提交给SSF，SSF 应该把这个拷贝连同它的两个版本号存档。
运行离线数据版本的一致性、不冲突性控制
为了保证离线数据版本的一致性，当一个运行离线数据得到批准运行时，各
现场必须保存正在运行的全部离线数据，并形成一个拷贝，这个拷贝应该得到保存。
按照离线数据版本号命名规则，各地应该为自主变更的新运行离线数据分配
一个分支版本号，然后在现有运行离线数据的基础上修改运行离线数据，在确认
无误和测试以后，将这个修改后的离线数据的分支版本号升级到新的分支版本
号，基本版本号维持不变，这个修改以后的拷贝应该得到保存，在需要的时候提
交给SSF，SSF 应该把这个拷贝连同它的两个版本号存档。
离线数据版本的完备性控制
为了保存离线数据的完备性，又保持离线数据的修改的灵活性，各地可以自
由修改各地自主的离线数据，每次经过确认的修改必须形成一个分支版本号，并
将修改后的离线数据形成一个拷贝保存。
对于由基本版本号控制的离线数据，即要各地一致及各地协调的离线数据，
在没有得到修改要求和新的基本版本号时，各现场不能进行修改。
44
6.1.5 自动化系统软件相关技术文档的版本控制
自动化系统软件相关技术资料文档指由自动化系统厂商提供的关于软件的
相关技术文档，以及在系统运行中，由各技术部门产生的与系统相关的技术资料。
SSF 拥有完整的软件相关技术资料文档，各现场亦拥有一些软件相关技术资料文
档。
自动化系统软件相关技术资料文档的版本控制指以编号的方式标识所有技
术文档资料，使技术文档资料的变更和修改可控，保证在软件版本的变更过程中，
技术资料的变更与软件版本变更同步。
自动化系统软件相关的技术资料版本命名规则
为了保证软件技术资料与软件版本的一致性，技术资料版本号命名规则为
“控制单位_类别_软件源代码版本号”
 控制单位指对文档版本进行控制的部门，例如SSF。
 类别指文档归属的大类，具体分类方式参加第7 章，使用一个英文字符
标识，A 表示为第一类，B 表示为第二类，C 表示为第三类。
 软件源代码版本号，参加本章6.1.2
例如SSF_A_V3.2.0，说明文档是由SSF 控制的，基于软件源代码版本V3.2.0
的，第一类控制的文档。
自动化系统软件相关的技术资料版本一致性控制
文档管理机构应该为每一个使用过的软件源代码版本制作一个软件相关技
术资料版本。
为了管理的方便性，对于电子格式的文档，需要为每一个版本的软件相关技
术资料形成一个拷贝。对于纸质文档，则需为其附带版本号。对于经过版本变更，
但未改变的纸质技术资料，可以使用一个描述文档，指明本版本的这个资料与某
个版本的资料一致。
45
6.2 业务范围和职能划分
6.2.1 业务分类
根据业务说明，版本控制业务分为：
 软件源代码
 软件可执行数据（sysref.tar）
 离线数据
 软件相关技术文档
6.2.2 软件支持中心的业务范围和职能
软件支持中心负责软件源代码的全部版本控制业务，并负责软件源代码版本
变更相关文档，软件源代码的创建及存档。
软件支持中心负责软件可执行数据（sysref.tar）的全部版本控制业务，并负
责软件源代码版本变更相关文档，软件源代码的创建及存档。
软件支持中心负责离线数据中核心数据及关键数据的版本控制业务，并负责
其相关文档的创建及存档。
软件支持中心负责由软件支持中心管理的自动化系统软件相关技术文档的
版本控制及存档。
6.2.3 地区运行管理组的业务范围和职能
各地区运行管理组负责软件可执行数据（sysref.tar）的版本存档业务，各运
行现场应该备份由软件支持中心产生的各个版本的软件可执行数据（sysref.tar）
各地区运行管理组负责运行离线数据的版本控制，运行离线数据的创建，存
档，以及对核心、关键离线数据版本的创建与存档。各地区运行管理组还负责在
软件支持中心需要的时候为其提供运行离线数据库版本数据。
各地区运行管理组负责由各地管理的自动化系统软件相关技术文档的版本控
制及存档。
6.3 业务相关文档格式
《软件源代码变更描述文件》参见附件十三
《离线数据修改表》参见附件五
46
第七章技术资料的管理
由于EUROCAT-X 系统软件庞大，资料众多，软件本身存在不定期的升级，
软件源代码，各种软件运行相关数据，软件说明文档等资料信息均会存在版本问
题，无法将其近乎海量的资料信息完全放入数据库中进行管理，仍须采用传统档
案管理的方式存储纸质文件、磁带、光盘等介质，软件支持中心的软件技术资料
包括软件数据存档及软件资料存档，其中软件数据存档主要分为磁带、磁盘、光
盘三种存档介质，软件资料存档大致分为SSS、OHK、ICD、License 四种类型
的资料存档。
软件资料文档可以发布在内部Intranet 上，对于电子形式的软件资料文档，
可以通过Intranet 找到，其目的是为了帮助技术人员准确地找到需要的参考文献。
7.1 业务说明
软件支持中心负责Thales 公司提交给软件支持中心的NESACC 自动化系统
软件技术资料的管理，各现场可以在软件支持中心查询、借阅相关的技术资料文
档，各现场需要向软件支持中心提交一个需要使用NESACC 软件技术资料的注
册人员名单，软件支持中心依据这个名单为注册人员提供在其授权范围内的技术
资料服务。
Thales 公司提交给各现场的技术资料，由各地实施管理。
7.1.1 信息资料入库流程
当新资料来的时候，由信息资料管理员专职负责入库：
47
资料管理员负责新
资料入库
新资料标识
在信息资料管理库
中加入相关记录
资料是否需要
异地保存
保存在安全、适合的地
点
新资料介质是否可设
成“写保护”模式
将资料拷贝至目的地置成“写保护”模式
异地新资料标识
信息资料管理库中
加入异地存储记录
新资料介质是否可设
成“写保护”模式
置成“写保护”模式
保存在安全、适合
的地点
Yes
No
Yes
No
Yes
No
图十、软件支持中心技术资料的入库流程
48
信息资料的增加、更新、销毁权限管理
在系统信息资料需要增加、更新、销毁的时候：
 由信息资料管理员专职负责，做好资料标识
 由信息资料管理员在信息资料信息库中增加、更新、销毁相应的项目，
保持信息库中记录内容和实际内容一致
 如有多点存储的信息资料，应几个地点同步增加、更新、销毁相应的项
目，保持同步
信息资料的借阅、使用管理
 信息资料的借阅、使用需经部门技术领导或信息资料管理员的同意
 借阅使用必须填写信息资料借阅使用表，包括借阅人、借阅时间、预计
归还时间、实际归还时间等
 信息资料归还入库时，由信息资料管理员负责检查完好性
 重要并且无备份的信息资料应采取特殊规定，可以采取限制借阅时间或
仅允许查阅，禁止借出等规定
 普遍使用且无需保密的信息资料可上载到企业内部网（INTRANET）上
共享
7.2 业务范围及责任划分
技术资料管理业务涉及软件支持中心、地区运行管理组，以下是各部门的业
务范围和职能。
7.2.1 领导小组的业务范围和职能
负责资料借阅人员名单的审批工作。
7.2.2 软件支持中心的业务范围和职能
软件支持中心负责对Thales 公司提供给软件支持中心的各种软件技术资料
进行管理，并在各地需要查询时提供服务。
49
7.2.3 地区运行管理组的业务范围和职能
地区运行管理组负责Thales 公司提供给本地的各种技术资料的管理。负责
借阅技术资料人员的管理。
7.3 工作流程
流程图如下所示：
现场工作人员
NESACC-CCB
现场工作人员1
各现场
SSF技术资料管理员
SSF技术资料库
3.接收
$
MICROSOFT CORPORATION
访问SSF技术资料人员名单
2.批准
1.提交
4.登记注册
5.查询借阅
$$
$
SSF工作人员
6.资料检索
7.借阅登记
8.移交
接收
9 使用资料
10.归还
11.资料入库、登记
SSF技术资料
服务器
Intranet
通过Intranet查阅SSF软件技术资料
图十一、软件支持中心技术资料流程
50
7.4 技术资料业务相关文档格式
《文件记录表》参加附件十四
《软件技术资料管理细则》参加附件十五
页10: [1] 删除的内容ssd 2007-05-23 9:40:00
软件支持业务的工作流程
软件支持业务的核心工作是软件版本的更
新及离线数据的更新，软件版本更新是解决
软件故障的最终手段，也是软件功能变化的
实现手段，它需要软件支持业务的全部相关
部门的共同参与。
一个软件版本的更新是由于软件源代码更
新产生的，它需要进行软件源代码验证，源
代码编译，SSF 测试，CCB 批准下发，现
场TEB 测试，CCB 批准新版本软件发布，
现场新版本软件安装，现场OPS 验证/测试，
现场新版本软件运行等步骤，此外还需要对
软件的源代码更新及新版本软件提供版本
控制及版本管理的服务，在这个步骤中产生
的文档也需要进行规范化，以保证各部门之
间实际运作的可控性及规范性。
下图描述软件版本更新的概要流程
接受新版软件的测试版本产生测试计划文件送交NESACC-CCB批准安装至SSF平台
送交各现场TEB测试产生测试报告依据测试计划文件进行测试
CCB批准
CCB驳回
源代码编译
接受新版软件的源代码
校验VDD文档及依据VDD文档校验源代码变更
编译失败，返回THALES
产生新版软件测试版本
进入版本管理流程
进入版本管理流程
进入文档管理流程
送交NESACC-CCB批准TEB测试
CCB批准
CCB驳回，进入文档管理流程
TEB测试失败,进入文档管理流程
测试失败，返回THALES
TEB测试成功
产生测试报告
送交NESACC-CCB批准发布新版本软件
进入文档管理流程
CCB驳回，进入文档管理流程
安装至各现场OPS平台各现场的OPS测试
成功，软件版本升级
失败，使用原版本，产生故障报告至SSF
图二、
离线数据的更新分为两种情况，一种是核心
离线数据及关键离线数据的更新，需要各现
场协调统一进行。另一种是运行离线数据的
更新，由各现场自主完成。
对于核心离线数据及关键离线数据的更新，
工作流程与软件版本更新的工作流程一致，
它需要进行离线数据验证，SSF 测试，CCB
批准下发，现场TEB 测试，CCB 批准新版
本离线数据发布，现场新版本离线数据安
装，现场OPS 验证/测试，现场新版本离线
数据运行等步骤，同时还需要对新版本离线
数据提供版本控制及版本管理的服务，在这
个步骤中产生的文档也需要进行规范化，以
保证各部门之间实际运作的可控性及规范
性。
对于运行离线数据的更新，为了保证修改的
实时性，由各现场LOMG 进行决策和具体
的流程操作，为了保证运行离线数据的版
本，各现场需要按照一个NESACC 统一的
版本控制规范对运行离线数据进行管理，并
在一个规定的期限之内送交至SSF 进行统
一的存档。
软件支持业务的业务界面划分
根据软件支持业务的具体工作内容及参与
部门，最主要的业务界面在NESACC-CCB、
NESACC-SSF 与各现场LOMG、各现场技
术支持部门两大部门之间。确认这两个部门
之间的业务范围，业务联系及执行方式是保
证各部门协调工作的基础。
本文的后六个章节对故障管理业务、测试/
验证业务，离线数据管理、软件发布安装、
版本控制、技术资料管理这六个方面进行了
一个业务划分，并制定了一些文档规范，以
保证这个业务界面的运转规范化。

---

作者: lightszzn100    时间: 2010-9-11 22:39:51

xiangwodkfsdkfdskfj

---

作者: lane49    时间: 2010-9-18 11:12:30

很需要

---

作者: zhangy    时间: 2010-12-7 15:21:23

不错，看看！

---

作者: lht520yy    时间: 2010-12-21 18:55:55

http://www.minhang.cc/attachment ... 18f00d&t=1292927241

---

作者: ingooooo    时间: 2018-9-24 18:19:38

谢谢分享，学习一下。

---

欢迎光临 航空论坛_航空翻译_民航英语翻译_飞行翻译 (http://bbs.aero.cn/)

Powered by Discuz! X2