电子化运行理平台--A350机载软件构型及数据管理项目采购

1、电子化运行管理平台-A350 机载软件构型及数据管理项目采购需求说明项目业务需求项目主要业务需求如下：1 、机载软件管理（ 1 ）飞机目标构型、实飞构型、机上存储构型的初始化、变更（例行、非例行） 、构型报告导入及差异对比管理、功能号管理、媒体集管理。（ 2 ）机载软件的订购、获取、验收、存储、传输、装载（USB 、无线方式）控制、反馈等流程管理。2、电子飞行包数据管理电子飞行包数据流程管理，变更管理，构型控制。3、自制软件管理自制软件及数据的流程管理，变更管理，构型控制。4、电子手册管理飞机维修类手册， AirNv Line Maintenance 流程及构型管理。飞机放行类手册， AirN

2、v Dispatch 流程及构型管理。客舱乘务员手册 CCOM 流程及构型管理。手册有效性管理。5、数据接口1 ）与电子化运行地面系统接口A350 机载软件构型及数据管理系统与电子化运行地面系统的GAS/LSBM/FLSR/AIRLINK 需要通过接口方式实现数据交互。（ 2 ）与 TDMS 系统接口需要 LCM 从 TDMS 调用的信息： TDMS 中系统工程师发起EO时需要填写的全部信息，包括EO 编号、 EO 标题、 ATA 章节、所属媒体集号、属于新建EO或改版EO、软件信息、装机截至时限、审批人、 适用机尾的信息、 软件信息、 到货方式、 装载方式等相关字段。需要 TDMS 从 LC

3、M 调用的信息： 1 、 LCM 中单机软件装载状态反馈的全部信息，包括反馈任务中对应的 EO 信息、飞机的机尾号、反馈的状态等相关字段；2 、 LCM 中新引进飞机的基线构型（第一版实飞构型）的构型信息；3 、 LCM 中机载软件数据每天定时同步到TDMS 系统。（ 3 ）电子化运行管理平台移动端需求将电子化运行管理平台的构型查询功能和任务反馈功能集成到国航之翼客户端。1. 项目目标和建设原则1.1. 项目目标1 、在公司首架A350 飞机交付前，搭建一套规范、安全、高效的机载软件构型和数据管理系统。通过建设 A350 机载软件构型和数据管理系统，满足A350 电子化运行要求，实现统一的机载

4、软件构型和数据管理，完成机载软件、电子飞行包数据，电子手册（维修、飞技、客舱）的构型管理和流程管理， 满足 A350 机型网络安全操作的运行要求， 保证 A350 新飞机交付后正常运行。2、通过信息化手段提高业务的响应度及对问题的快速定位和追踪。3、加强人员及操作过程的管控，决策者可及时对过程环节进行监控和调整，以提高决策力。1.2. 项目建设原则和依据本项目按照国航信息系统建设的OSS、 4H 要求进行设计，并在此基础上，根据项目和业务特点，重点考虑以下几点内容：1 、 A350 机载软件构型和数据管理业务流程参考规范（ 1 ）机载软件的管理范围和规范依据空客ISI 00.00.00095

5、。（2）涉及装载流程参考空客ISI00.00.00188 ，需要结合公司实际情况。（ 3 ）有关流程要满足空客飞机网络安全手册 Security Handbook的要求。（ 4 ）机载软件构型报告参考空客ISI 45.00.00033 ，并以我公司最终交付飞机的实际构型报告为准。2、平台化和扩展性原则本项目建设的性质属于在现有的电子化运行管理系统（ LCM ）的基础上， 复用基础计算资源、 数据库资源及通用应用模块、 流程工具，开发实现差异化的 A350 机载软件构型和数据管理等主要功能， 建设电子化运行管理平台，需要覆盖波音电子化机型、空客电子化机型、非电子化机型的机载软件管理， 要求三个模

6、块的数据彼此独立、 互不影响， 并且要求电子化运行管理平台从架构设计上具有横向和纵向扩展能力， 从横向上看， 可通过建设独立模块支持商飞等其他飞机制造商的电子化机型； 从纵向上看， 同一飞机制造商的电子化机型可在模块内通过功能扩展实现。3、移动化需要电子化运行管理平台支持移动端的需求，通过与国航之翼APP 集成，机务一线生产用户可在移动端进行飞机单机构型状态查询和装载任务反馈。4、项目约束本项目于中标通知书下发后五个月内完成功能开发及测试，并于2017 年 9 月进入项目试运行阶段。本项目将于2018 年 5 月完成验收。2. 系统功能性要求2.1. 功能点要求本项目主要功能需求包括A350

7、飞机机载软件（由空客或第三方提供）全生命周期管理、航空公司自制软件全生命周期管理、电子飞行包数据全生命周期管理、 飞机电子手册全生命周期管理、 飞机单机 构型状态管理、媒体集管理、飞机基础主数据管理、 A350 数字安全证书台账管理、 移动端构型状态查询功能和任务反馈、 统计及报表需求等。其中最核心的业务需求是机载软件（含标准机载软件、自制机载软件、电子飞行包数据、电子手册等）全生命周期的过程管理和飞机单机构型状态管理。（ 1 ）机载软件管理? 机载软件初始化飞机交付前，根据航空公司和空客确认的新飞机引进运行准备工作计划， 需要在飞机交付前 9 个月到 3 个月完成 A350 电子化运行地面系

8、统部署和测试工作，并对飞机的交付构型进行初始化，并存储FLS部件副本。空客在 A350 飞机交付时会向航空公司提供飞机检查报告文件，报告中列出了每个机载软件和相应的 FIN 号，包含已经安装的部件，该报告随同飞机一并交付。飞机在交付前，空客会向航空公司交付飞机检查报告中列出和定义机载软件集合、 飞机定义部件等相关信息。 因为客户化机载软件是非飞机定义部件，因此空客飞机交付时不含客户化机载软件部件信息， 航空公司需在飞机交付前对这部分机载软件进行提前制作并有效管理。客户化机载软件和空客交付飞机时已经安装的机载软件作为飞机 初始化机载软件，是飞机构型管理的基线。? 机载软件变更机载软件的件号变更和

9、版本变更会导致飞机的构型信息发生变化，当一个机载软件需要更新或变更时，对应的业务流程包括： 1 、软件变更评估， 2 、依据评估结果发起变更流程， 3 、建立飞机目标构型信息，4 、根据时限要求发起机载软件装载流程。变更的机载软件包括EFB数据、标准机载软件、客户化机载软件等。? 机载软件装载机载软件的装载包括如下业务流程：分配装机任务、装载任务清单准备、装载数据准备、执行装载任务、飞机最新的构型文件下载、反馈工卡执行结果、确认安装结果、机载软件重新装载等。装载任务清单准备：对于由变更流程产生的 FLS 装载要求，均由AMECO 工程部颁发相应的工程文件执行装载，其中例行装载通过CAMP 、

10、CQMP 、重检 EO 或 EB 颁发装载工作条目，非例行装载通过颁发一次性EO 规范装载工作任务。 工程文件的颁布在机务TDMS系统完成。装载任务清单由 LCM 系统根据软件变更和目标构型来生成，同时装载要求中应明确装载方式，选择使用 USB 方式或者无线方式，分别对应不同的业务流程和业务操作。执行装载任务：机务维修机械员，负责执行指定的工卡，使用OMT/FAP 完成机载软件到飞机ASFC/OSFC 服务器的装载工作， 使用相关机载系统完成机载软件到各机载系统的安装工作。 该项工作前提是 FLSR 里面变更的机载软件被推送到飞机的 reference 库，reference 库对应于飞机AI

11、SD 域的 OSFC 服务器的大容量存储器，reference 库里面的机载软件如果不执行装载，并不会生效。机务工程师执行软件装载的实质是把把推送到飞机的 Reference 库的机载软件安装生效，变为飞机的实飞构型，满足飞机运行要求。飞机最新的构型文件下载：机务维修机械员使用专用工具，从飞机下载构型文件到 USB 或通过无线方式存储到指定位置，机载软件构型管理系统需要实现自动监听并完成该指定位置内文件的同步复制工作。反馈工卡执行结果：为保证装载过程可能出现的问题不影响航班正常运行， FLS 流程发起人员需要及时获得工卡执行情况，为实现此需求，构型管理系统需要实现如下功能： 1 、工卡执行部门

12、人员登陆系统反馈工卡号及每个软件更新执行状态，系统通知FLS流程发起人员和工卡工程师（系统消息，邮件或短信） 。 2 、系统读取飞机上下载的构型报告等文件， 在系统中生成实飞构型与目标构型比对结果， 待工卡工程师确认关闭。反馈完成后，FLS流程状态变为“已完成装载”。确认安装结果：系统对机载软件装载前后的飞机构型文件进行比较，生成 FLS 构型符合性报告，产生通知消息给FLS 流程创建的人员和构型总管理员，由其确认关闭，结束流程，标记软件状态为“已装机” 。如果构型符合性报告有差异，系统自动通知相关人员，视情况发起重新装载流程。机载软件重新装载：针对已经获得批准的FLS软件，可能因为装载错误或

13、者其他原因， 需要由业务部门发起重新装载， 则由发起装载的业务单位人员从已经批准的 FLS 软件中选择要装载的软件，启动FLS主动变更流程，设定装载期限要求，设定适用的飞机机号，提交后FLS流程状态为“已发布”，衔接装机批准流程。（ 2 ）飞机单机构型控制? 飞机构型分类A350 飞机构型分为 5 类，包括交付构型、实飞构型、目标构型、批准构型、 Reference 库构型，具体业务定义可参见实施方案。? 飞机构型状态初始化飞机交付时，空客向航空公司提供交付构型报告，由飞机电子化运行办公室将交付构型报告导入系统，作为第一版实飞构型的基础。目标构型初始化：交付构型和自制类机载软件作为初始化的单机

14、目标构型。机上存储构型初始化：交付构型和通过USB 或无线传输到Reference 库的机载软件组成的软件构型作为初始化的机上存储构型。实飞构型初始化：飞机交付后，在正式投入商业运营前，机务工程师会将自制类软件装载到飞机， 装载生效的自制类软件加上飞机交付构型报告共同形成该架飞机的第一版实飞构型， 作为后续单机构型管理的基础。? 目标构型和实飞构型对比在飞机全生命周期的运行过程中，软件构型和硬件构型是不断变化的， 飞机单机构型管理最核心的工作就是机载软件全生命周期的控 制和追踪。每次装载任务完成后，需要系统更新目标构型与实飞构型的对比报告，启动流程发给每个机载软件更改发起人员和构型总管理员确认

15、，确认后存档构型对比报告。目标构型和实飞构型均是XML 格式的文档， 从国泰运行的经验上看， 飞机自动下载的实飞构型报告能覆盖90% 左右的机载软件数据，对于从飞机下载的实飞构型报告未涵盖的机载软件， 需要通过机务工程师人工反馈的方式， 由系统记录该部分机载软件的构型状态， 确认是否已正确安装。为保证飞机运行安全，系统需要管理所有机载软件的构型状态，确保目标构型和实飞构型一致。此外，系统还要实现对装机时限提醒、禁装权限设置、构型符合性报告管理等功能。装机时限提醒：系统自动判断软件的装载时限，流程中根据剩余时间， 显示不同的颜色。 当已批准的装机软件时限小于 3 个自然日时，发送邮件提醒给相关人

16、员。禁装权限设置：对于已经批准装机的软件，软件制作人员和构型总管理员可以设置禁装限制， 在系统允装构型中给予提示， 并由构型总管理员负责处理。构型符合性报告管理：当维修人员反馈的机载软件构型状态报告导入系统后， 系统需要立即计算并生成新的构型状态符合性报告， 如果出现禁装部件装机的情况， 需要在构型状态符合性报告中报警， 同时系统自动发出消息通知维修单位工卡工程师和构型总管理员。为持续监控飞机构型状态的一致性，业务部门要求系统需要每天凌晨2 ：00 生成新的单机软件构型符合性报告，单机软件构型符合性报告并将所有的发布在系统的指定位置。当用户手动输入或系统通过接口调用获取机载装机构型状态文件时，

17、系统需要实时计算并生成该飞机的单机软件构型符合性报告， 对不符合软件数据进行告警， 并通过邮件和任务的方式相关人员构型差异性对比结果。 系统需要实现可以通过有效的用户权限控制， 实现定期报告和差异性报告的浏览、 下载等权限管理。2.2. 接口集成要求本项目需要实现的数据接口功能包括同 TDMS 系统集成、 同 FLSR功能集成、 同 GAS 功能集成、 同国航之翼的功能集成， 其中同 FLSR功能集成和同 GAS 功能集成主要用于 A350 构型管理模块， 同 TDMS系统集成和同国航之翼集成主要用于电子化运行管理平台， 可为全机队提供数据接口服务。(1)同A350电子化运行地面系统FLSR数

18、据接口机载软件均存储在A350电子化运行地面系统的FLSR里面，FLSR是空客提供的软件产品，按照空客的运行建议， 10 架飞机需要配置500G 的存储容量。FLS部件核查和电子签名验证步骤完成后会存储在FLSR中，为保障机载软件存储的安全性， 空客建议航空公司将每一个机载软件进行备份存储。空客建议 FLS 部件使用 ARINC665 格式存储， 包含软件制造商交付部件附带的关联文档，比如 EASA 表单、符合性等。LCM 作为数据流管理本来不会涉及机载软件实体的存储过程， 但是为了流程处理的智能化，系统还是需要监控网络位置的不同文件夹，以便实时掌控数据流的动向。空客提供 FLSR 的接口开发

19、 API ，支持构型管理系统通过件号、FIN号获取FLS部件的相关数据。同时根据业务需要可以在系统上传FLS部件的相关关联文件，便于业务审批。（ 2 ）同 A350 电子化运行地面系统GAS 数据接口GAS 里面的 CMT 模块用于软件制作，业务用户在本系统发起制作软件制作流程后， 会生成硬件 FIN 号和软件 FIN 号， 用户使用 CMT工具制作软件实体，然后按照制作流程生成的编号为软件实体命名，并在系统里面记录软件实体的状态。GAS 的 AIRLINK 模块负责管理飞机与地面系统上下行数据传输，构型管理系统通过空客提供的 API 获取 AIRLINK 模块的上行数据传输结果，用于确认变更

20、的机载软件成功传输到飞机的 Reference 库。GAS 的 LnTV 模块负责存储所有从飞机上下载下来的飞机实飞构型报告，构型管理系统通过空客提供的 API 调用 LnTV 的数据接口，获取单机实飞构型报告， 作为构型比对的一项输入， 结合机务工程师装载任务反馈，与系统里面的目标构型数据进行比对。3 ）同 TDMS 系统数据接口LCM 系统需要从TDMS 系统获取的字段包括： EO 的版次（ R00版或改版）、EO编号、EO标题、EO编写人（对应于EO的“主编”字段） 、 ATA 章节、生效日期（对应于 EO 的“生效日期”字段） 、装机的截止时限（对应于 EO 的“截止日”字段） 、审批

21、人（对应于 EO的“校对”字段） 、历史版本EO 编号（只针对改版EO） 、等效或替代（对应于 EO 的“本版次与上版次的关系”中的“等效、替代、终止”字段）、飞机信息（对应于EO “分组Group ”字段的全部数据）、软件信息（对应于 EO 的“机载软件影响”字段的全部数据）等。目前 LCM 系统仅需要从TDMS 系统获取数据， TDMS 系统对LCM 系统没有数据需求。（ 4 ）同国航之翼功能集成业务背景：实际业务生产场景中，一线机务人员需要实时查看飞机的实飞构型、 目标构型及需要反馈的装机状态， 目前需要机务人员在后台办公室找到可以接入国航内网的电脑通过登录 LCM 系统才可以进行查询和

22、任务反馈，飞机电子化运行保障效率受到较大影响。业务需求：将飞机电子化运行管理系统的构型查询功能和任务反馈功能集成进国航统一的国航之翼客户端， 在互联网环境下， 一线机务人员可以通过登录国航之翼实时查询飞机构型状态， 可以极大的提高实际工作效率。同时，由于一线机务人员任务反馈及时，机载软件的构型管理的及时性将得到极大提升， 国航电子化运行机队机载软件构型管理的准确性和实时性将进一步提高。国航之翼客户端需要支持多个条件组合查询飞机构型状态，相关条件为：飞机注册号、构型类型、软件类型、时间、 EO 等，构型状态数据应支持翻页功能，方便用户查看。LCM 系统支持用户基于移动端应用进行快速构型反馈功能。

23、 用户身份验证通过后可以查看自己的待办任务清单。 按照管理要求， 单机构型反馈任务应按照人员所属维修基地进行隔离， 系统需要对反馈操作进行相应权限验证和控制。用户基于移动端应用进行反馈时， 可以查看反馈任务的详细信息，包含反馈飞机信息、软件及件号信息、反馈状态等。3. 系统非功能性要求3.1. 可用性要求后台年可用性指标： 99.9% ，包括主机硬件、操作系统和主机应用程序。用户最长容忍故障恢复时间： 60 分钟。系统平均年连续无故障运行时间：大于525000 分钟。停机维护次数和时间：年允许停机维护4 次，每次 60 分钟。系统目标用户数量：500 个。最大并发用户数量：30 个。3.2.

24、安全性要求达到 GB/T 22240 2008 信息系统安全等级保护定级指南要 求；目标系统能够通过角色向用户进行职责和权利分配；目标系统只支持自身用户验证方式登陆；不允许业务用户直接登录数据库；目标系统在用户和授权方面支持按照组织架构分级分片进行管理；目标系统至少支持通过组织数据、信息类型、个人数据和报表四个方面授权；目标系统应支持中央管理模式，在一个系统内创建用户，然后将用户发布到其他指定系统内， 被管理的系统的用户数据可以随时和中央系统同步；在密码策略上，要符合信息管理部的安全管理规定，系统内部口令及管理口令为 8 位长度及以上，复杂度包含字母、大小写、数字、特殊字符等。3.3. 易用性

25、要求用户体验度：考虑到用户计算机整体知识水平，用户界面简洁，各项功能相应界面清晰，排版合理，符合用户期望描述。符合用户操作习惯，具有良好的适用性和易用性。系统响应时间指标：系统功能操作平均响应时间： 3 秒。3.4. 可维护性要求系统应具备高可维护性，便于功能的加载、扩展、更新和修正。3.5. 可移植性要求系统具备良好的扩展性和可移植性；具备业务处理的灵活构型，支持业务功能的灵活重组与更新；支持移动端的业务需求。3.6. 兼容性要求浏览器兼容性： IE 浏览器（ 8-11 ）、 Chrome 浏览器（各版本）、QQ 浏览器、火狐浏览器、搜狗浏览器、 360 浏览器等。应 用 系 统 兼 容 操

26、 作 系 统 ： Windows XP; Windows VISTA;Windows7 、 Windows8 、 Windows10 等。语言版本：中文、英文。文件下载： OFFICE（word 、 excel ）、 PDF、 WPS 。3.7. 开放性要求工作流引擎使用 activiti ，数据库使用 Oracle 。3.8. 设计约束本项目按照国航信息系统建设的 OSS、 4H 要求进行设计。4. 实施方案要求4.1. 设计方案要求? 总体架构机载软件构型管理系统总体架构，由波音电子化机型构型管理、空客电子化机型构型管理、 非电子化机型构型管理模块及移动数据服务四大版块组成。号汾返证白，任

27、君题者宜理案里生虚濠亚看导入号比一安鱼管理财H屈文携文百理日志青Vik技器国科电子北悯里希整世理整一用户PORTAL事微，化机型何生云停委用埃.王陵K飞乩上匏据言以机组!枸当野之宣理的交付宾飞像惘与口一讦物构君迫狂它呼布飞机杓里基线送E管理EF日将洋，魅揖，|七物也行能日到丽十疝位海部件中购恪防鎏机身忘牛制愕芸/区悟他刘皆岳/证书官理/用亲箫计飞机王前零号隹M理贯理配置管理招举管涅/磅/什熊司飞机科空里陇温也管理举斗订股引收港机恰恃L£L帘统数嘱/校匚集.我管理旅能铺W宣西中存以于眈机笈构型宫畔”山蛀/曾埋机坐拘如齿置管典粉二苣里身的寞在矍REFR. .礼恂的是厘生三竺佳FLSn程肢

28、存珅装机氐裸E=3粒件怖1嵋才|作注机应摆fls m tu印件制做机应甯口3抄据含理及装机应爸电子手田管理她国系统/USB事,，证书己建报交统计.，他面_LE拣集引移动同工屉将 用尸族探粗田立括捡L 任M守座描_ 搀口情词金曲 接口慢机膏理安运全h隹雄障护flfi灌音电子化，电子化空电子牝基破熟揭通告miiSH 1/J<:存整机整枸如库也出料，库机型椅型庠品嫡卸置手外,L胸型都据应卬蠡抠即釉交”度为坞重建52 朦神曲, 卷在品倏 y络布莺 益尔文件春片盍平门 而用中”件 工机“岳域/_|_具 措也"火由律现,哲计系统整体结构为B/S结构，自上而下分成五层：交互层：系统支持PC机

29、浏览器方式访问，并提供统一用户访问界面。对于飞机的构型数据查询及部分业务办理， 为了避免地域或网络的限制，满足航站机务人员飞机单机构型状态查询和装载任务反馈的需要，需要系统提供移动端数据服务支持。应用层：包含波音电子化机型构型管理模块、空客电子化机型构型管理模块、非电子化机型构型管理模块以及移动数据网关服务。系统基于软件构型管理和业务流程管理两条主线设计，软件构型管理和业务流程管理保持松散耦合，同时又有相应的关联，并与外部工具、接口、系统进行集成，实现不同机型机载软件构型的闭环控制。服务层：由系统相关基础服务或通用功能模块组成，以支撑上层应用。主要包含了用户认证、安全控制、监控告警、流程引擎、系统管理、配置管理等。数据层：业务数据库主要包含了波音电子化机型、空客电子化机 型、非电子化机型的构型存储库以及基础数据、配置数据、流程数据 等内容。基础设施层：主要由服务器、网络、中间件、外围关联系统等组 成，以提供系统运行、应用集成、网络通讯、数据存储、服务交联等 支撑。?物理架构系统物理架构基于现有的服务器资源配置，只需适当扩容即可， 系统由LCM系统虚拟化应用服务器、LCM系统数据库虚拟化服务器 组成，并与LSAPL、FLSR、LSE等系统存储服务集成，并支持与外 围相关工具、接口等进行数据交联服务。其中两台应用服务器通过 nginx实现高可用和负载均衡，两台数据库服务器为双机热备