电子化运行管理平台A350机载软件构型及数据管理项目采购.docx
《电子化运行管理平台A350机载软件构型及数据管理项目采购.docx》由会员分享，可在线阅读，更多相关《电子化运行管理平台A350机载软件构型及数据管理项目采购.docx（15页珍藏版）》请在冰点文库上搜索。
电子化运行管理平台A350机载软件构型及数据管理项目采购
电子化运行管理平台--A350机载软件构型及数据管理项目采购需求说明
项目业务需求
项目主要业务需求如下：
1、机载软件管理
（1）飞机目标构型、实飞构型、机上存储构型的初始化、变更（例行、非例行）、构型报告导入及差异对比管理、功能号管理、媒体集管理。
（2）机载软件的订购、获取、验收、存储、传输、装载（USB、无线方式）控制、反馈等流程管理。
2、电子飞行包数据管理
电子飞行包数据流程管理，变更管理，构型控制。
3、自制软件管理
自制软件及数据的流程管理，变更管理，构型控制。
4、电子手册管理
飞机维修类手册，AirN@vLineMaintenance流程及构型管理。
飞机放行类手册，AirN@vDispatch流程及构型管理。
客舱乘务员手册CCOM流程及构型管理。
手册有效性管理。
5、数据接口
（1）与电子化运行地面系统接口
A350机载软件构型及数据管理系统与电子化运行地面系统的GAS/LSBM/FLSR/AIRLINK需要通过接口方式实现数据交互。
（2）与TDMS系统接口
需要LCM从TDMS调用的信息：
TDMS中系统工程师发起EO时需要填写的全部信息，包括EO编号、EO标题、ATA章节、所属媒体集号、属于新建EO或改版EO、软件信息、装机截至时限、审批人、适用机尾的信息、软件信息、到货方式、装载方式等相关字段。
需要TDMS从LCM调用的信息：
1、LCM中单机软件装载状态反馈的全部信息，包括反馈任务中对应的EO信息、飞机的机尾号、反馈的状态等相关字段；2、LCM中新引进飞机的基线构型（第一版实飞构型）的构型信息；3、LCM中机载软件数据每天定时同步到TDMS系统。
（3）电子化运行管理平台移动端需求
将电子化运行管理平台的构型查询功能和任务反馈功能集成到国航之翼客户端。
1.项目目标和建设原则
1.1.项目目标
1、在公司首架A350飞机交付前，搭建一套规范、安全、高效的机载软件构型和数据管理系统。
通过建设A350机载软件构型和数据管理系统，满足A350电子化运行要求，实现统一的机载软件构型和数据管理，完成机载软件、电子飞行包数据，电子手册（维修、飞技、客舱）的构型管理和流程管理，满足A350机型网络安全操作的运行要求，保证A350新飞机交付后正常运行。
2、通过信息化手段提高业务的响应度及对问题的快速定位和追踪。
3、加强人员及操作过程的管控，决策者可及时对过程环节进行监控和调整，以提高决策力。
1.2.项目建设原则和依据
本项目按照国航信息系统建设的OSS、4H要求进行设计，并在此基础上，根据项目和业务特点，重点考虑以下几点内容：
1、A350机载软件构型和数据管理业务流程参考规范
（1）机载软件的管理范围和规范依据空客ISI00.00.00095。
（2）涉及装载流程参考空客ISI00.00.00188，需要结合公司实际情况。
（3）有关流程要满足空客飞机网络安全手册SecurityHandbook的要求。
（4）机载软件构型报告参考空客ISI45.00.00033，并以我公司最终交付飞机的实际构型报告为准。
2、平台化和扩展性原则
本项目建设的性质属于在现有的电子化运行管理系统（LCM）的基础上，复用基础计算资源、数据库资源及通用应用模块、流程工具，开发实现差异化的A350机载软件构型和数据管理等主要功能，建设电子化运行管理平台，需要覆盖波音电子化机型、空客电子化机型、非电子化机型的机载软件管理，要求三个模块的数据彼此独立、互不影响，并且要求电子化运行管理平台从架构设计上具有横向和纵向扩展能力，从横向上看，可通过建设独立模块支持商飞等其他飞机制造商的电子化机型；从纵向上看，同一飞机制造商的电子化机型可在模块内通过功能扩展实现。
3、移动化
需要电子化运行管理平台支持移动端的需求，通过与国航之翼APP集成，机务一线生产用户可在移动端进行飞机单机构型状态查询和装载任务反馈。
4、项目约束
本项目于中标通知书下发后五个月内完成功能开发及测试，并于2017年9月进入项目试运行阶段。
本项目将于2018年5月完成验收。
2.系统功能性要求
2.1.功能点要求
本项目主要功能需求包括A350飞机机载软件（由空客或第三方提供）全生命周期管理、航空公司自制软件全生命周期管理、电子飞行包数据全生命周期管理、飞机电子手册全生命周期管理、飞机单机构型状态管理、媒体集管理、飞机基础主数据管理、A350数字安全证书台账管理、移动端构型状态查询功能和任务反馈、统计及报表需求等。
其中最核心的业务需求是机载软件（含标准机载软件、自制机载软件、电子飞行包数据、电子手册等）全生命周期的过程管理和飞机单机构型状态管理。
（1）机载软件管理
Ø机载软件初始化
飞机交付前，根据航空公司和空客确认的新飞机引进运行准备工作计划，需要在飞机交付前9个月到3个月完成A350电子化运行地面系统部署和测试工作，并对飞机的交付构型进行初始化，并存储FLS部件副本。
空客在A350飞机交付时会向航空公司提供飞机检查报告文件，报告中列出了每个机载软件和相应的FIN号，包含已经安装的部件，该报告随同飞机一并交付。
飞机在交付前，空客会向航空公司交付飞机检查报告中列出和定义机载软件集合、飞机定义部件等相关信息。
因为客户化机载软件是非飞机定义部件，因此空客飞机交付时不含客户化机载软件部件信息，航空公司需在飞机交付前对这部分机载软件进行提前制作并有效管理。
客户化机载软件和空客交付飞机时已经安装的机载软件作为飞机初始化机载软件，是飞机构型管理的基线。
Ø机载软件变更
机载软件的件号变更和版本变更会导致飞机的构型信息发生变化，当一个机载软件需要更新或变更时，对应的业务流程包括：
1、软件变更评估，2、依据评估结果发起变更流程，3、建立飞机目标构型信息，4、根据时限要求发起机载软件装载流程。
变更的机载软件包括EFB数据、标准机载软件、客户化机载软件等。
Ø机载软件装载
机载软件的装载包括如下业务流程：
分配装机任务、装载任务清单准备、装载数据准备、执行装载任务、飞机最新的构型文件下载、反馈工卡执行结果、确认安装结果、机载软件重新装载等。
装载任务清单准备：
对于由变更流程产生的FLS装载要求，均由AMECO工程部颁发相应的工程文件执行装载，其中例行装载通过CAMP、CQMP、重检EO或EB颁发装载工作条目，非例行装载通过颁发一次性EO规范装载工作任务。
工程文件的颁布在机务TDMS系统完成。
装载任务清单由LCM系统根据软件变更和目标构型来生成，同时装载要求中应明确装载方式，选择使用USB方式或者无线方式，分别对应不同的业务流程和业务操作。
执行装载任务：
机务维修机械员，负责执行指定的工卡，使用OMT/FAP完成机载软件到飞机ASFC/OSFC服务器的装载工作，使用相关机载系统完成机载软件到各机载系统的安装工作。
该项工作前提是FLSR里面变更的机载软件被推送到飞机的reference库，reference库对应于飞机AISD域的OSFC服务器的大容量存储器，reference库里面的机载软件如果不执行装载，并不会生效。
机务工程师执行软件装载的实质是把把推送到飞机的Reference库的机载软件安装生效，变为飞机的实飞构型，满足飞机运行要求。
飞机最新的构型文件下载：
机务维修机械员使用专用工具，从飞机下载构型文件到USB或通过无线方式存储到指定位置，机载软件构型管理系统需要实现自动监听并完成该指定位置内文件的同步复制工作。
反馈工卡执行结果：
为保证装载过程可能出现的问题不影响航班正常运行，FLS流程发起人员需要及时获得工卡执行情况，为实现此需求，构型管理系统需要实现如下功能：
1、工卡执行部门人员登陆系统反馈工卡号及每个软件更新执行状态，系统通知FLS流程发起人员和工卡工程师（系统消息，邮件或短信）。
2、系统读取飞机上下载的构型报告等文件，在系统中生成实飞构型与目标构型比对结果，待工卡工程师确认关闭。
反馈完成后，FLS流程状态变为“已完成装载”。
确认安装结果：
系统对机载软件装载前后的飞机构型文件进行比较，生成FLS构型符合性报告，产生通知消息给FLS流程创建的人员和构型总管理员，由其确认关闭，结束流程，标记软件状态为“已装机”。
如果构型符合性报告有差异，系统自动通知相关人员，视情况发起重新装载流程。
机载软件重新装载：
针对已经获得批准的FLS软件，可能因为装载错误或者其他原因，需要由业务部门发起重新装载，则由发起装载的业务单位人员从已经批准的FLS软件中选择要装载的软件，启动FLS主动变更流程，设定装载期限要求，设定适用的飞机机号，提交后FLS流程状态为“已发布”，衔接装机批准流程。
（2）飞机单机构型控制
Ø飞机构型分类
A350飞机构型分为5类，包括交付构型、实飞构型、目标构型、批准构型、Reference库构型，具体业务定义可参见实施方案。
Ø飞机构型状态初始化
飞机交付时，空客向航空公司提供交付构型报告，由飞机电子化运行办公室将交付构型报告导入系统，作为第一版实飞构型的基础。
目标构型初始化：
交付构型和自制类机载软件作为初始化的单机目标构型。
机上存储构型初始化：
交付构型和通过USB或无线传输到Reference库的机载软件组成的软件构型作为初始化的机上存储构型。
实飞构型初始化：
飞机交付后，在正式投入商业运营前，机务工程师会将自制类软件装载到飞机，装载生效的自制类软件加上飞机交付构型报告共同形成该架飞机的第一版实飞构型，作为后续单机构型管理的基础。
Ø目标构型和实飞构型对比
在飞机全生命周期的运行过程中，软件构型和硬件构型是不断变化的，飞机单机构型管理最核心的工作就是机载软件全生命周期的控制和追踪。
每次装载任务完成后，需要系统更新目标构型与实飞构型的对比报告，启动流程发给每个机载软件更改发起人员和构型总管理员确认，确认后存档构型对比报告。
目标构型和实飞构型均是XML格式的文档，从国泰运行的经验上看，飞机自动下载的实飞构型报告能覆盖90%左右的机载软件数据，对于从飞机下载的实飞构型报告未涵盖的机载软件，需要通过机务工程师人工反馈的方式，由系统记录该部分机载软件的构型状态，确认是否已正确安装。
为保证飞机运行安全，系统需要管理所有机载软件的构型状态，确保目标构型和实飞构型一致。
此外，系统还要实现对装机时限提醒、禁装权限设置、构型符合性报告管理等功能。
装机时限提醒：
系统自动判断软件的装载时限，流程中根据剩余时间，显示不同的颜色。
当已批准的装机软件时限小于3个自然日时，发送邮件提醒给相关人员。
禁装权限设置：
对于已经批准装机的软件，软件制作人员和构型总管理员可以设置禁装限制，在系统允装构型中给予提示，并由构型总管理员负责处理。
构型符合性报告管理：
当维修人员反馈的机载软件构型状态报告导入系统后，系统需要立即计算并生成新的构型状态符合性报告，如果出现禁装部件装机的情况，需要在构型状态符合性报告中报警，同时系统自动发出消息通知维修单位工卡工程师和构型总管理员。
为持续监控飞机构型状态的一致性，业务部门要求系统需要每天凌晨2：
00生成新的单机软件构型符合性报告，单机软件构型符合性报告并将所有的发布在系统的指定位置。
当用户手动输入或系统通过接口调用获取机载装机构型状态文件时，系统需要实时计算并生成该飞机的单机软件构型符合性报告，对不符合软件数据进行告警，并通过邮件和任务的方式相关人员构型差异性对比结果。
系统需要实现可以通过有效的用户权限控制，实现定期报告和差异性报告的浏览、下载等权限管理。
2.2.接口集成要求
本项目需要实现的数据接口功能包括同TDMS系统集成、同FLSR功能集成、同GAS功能集成、同国航之翼的功能集成，其中同FLSR功能集成和同GAS功能集成主要用于A350构型管理模块，同TDMS系统集成和同国航之翼集成主要用于电子化运行管理平台，可为全机队提供数据接口服务。
（1）同A350电子化运行地面系统FLSR数据接口
机载软件均存储在A350电子化运行地面系统的FLSR里面，FLSR是空客提供的软件产品，按照空客的运行建议，10架飞机需要配置500G的存储容量。
FLS部件核查和电子签名验证步骤完成后会存储在FLSR中，为保障机载软件存储的安全性，空客建议航空公司将每一个机载软件进行备份存储。
空客建议FLS部件使用ARINC665格式存储，包含软件制造商交付部件附带的关联文档，比如EASA表单、符合性等。
LCM作为数据流管理本来不会涉及机载软件实体的存储过程，但是为了流程处理的智能化，系统还是需要监控网络位置的不同文件夹，以便实时掌控数据流的动向。
空客提供FLSR的接口开发API，支持构型管理系统通过件号、FIN号获取FLS部件的相关数据。
同时根据业务需要可以在系统上传FLS部件的相关关联文件，便于业务审批。
（2）同A350电子化运行地面系统GAS数据接口
GAS里面的CMT模块用于软件制作，业务用户在本系统发起制作软件制作流程后，会生成硬件FIN号和软件FIN号，用户使用CMT工具制作软件实体，然后按照制作流程生成的编号为软件实体命名，并在系统里面记录软件实体的状态。
GAS的AIRLINK模块负责管理飞机与地面系统上下行数据传输，构型管理系统通过空客提供的API获取AIRLINK模块的上行数据传输结果，用于确认变更的机载软件成功传输到飞机的Reference库。
GAS的LnTV模块负责存储所有从飞机上下载下来的飞机实飞构型报告，构型管理系统通过空客提供的API调用LnTV的数据接口，获取单机实飞构型报告，作为构型比对的一项输入，结合机务工程师装载任务反馈，与系统里面的目标构型数据进行比对。
（3）同TDMS系统数据接口
LCM系统需要从TDMS系统获取的字段包括：
EO的版次（R00版或改版）、EO编号、EO标题、EO编写人（对应于EO的“主编”字段）、ATA章节、生效日期（对应于EO的“生效日期”字段）、装机的截止时限（对应于EO的“截止日”字段）、审批人（对应于EO的“校对”字段）、历史版本EO编号（只针对改版EO）、等效或替代（对应于EO的“本版次与上版次的关系”中的“等效、替代、终止”字段）、飞机信息（对应于EO“分组Group”字段的全部数据）、软件信息（对应于EO的“机载软件影响”字段的全部数据）等。
目前LCM系统仅需要从TDMS系统获取数据，TDMS系统对LCM系统没有数据需求。
（4）同国航之翼功能集成
业务背景：
实际业务生产场景中，一线机务人员需要实时查看飞机的实飞构型、目标构型及需要反馈的装机状态，目前需要机务人员在后台办公室找到可以接入国航内网的电脑通过登录LCM系统才可以进行查询和任务反馈，飞机电子化运行保障效率受到较大影响。
业务需求：
将飞机电子化运行管理系统的构型查询功能和任务反馈功能集成进国航统一的国航之翼客户端，在互联网环境下，一线机务人员可以通过登录国航之翼实时查询飞机构型状态，可以极大的提高实际工作效率。
同时，由于一线机务人员任务反馈及时，机载软件的构型管理的及时性将得到极大提升，国航电子化运行机队机载软件构型管理的准确性和实时性将进一步提高。
国航之翼客户端需要支持多个条件组合查询飞机构型状态，相关条件为：
飞机注册号、构型类型、软件类型、时间、EO等，构型状态数据应支持翻页功能，方便用户查看。
LCM系统支持用户基于移动端应用进行快速构型反馈功能。
用户身份验证通过后可以查看自己的待办任务清单。
按照管理要求，单机构型反馈任务应按照人员所属维修基地进行隔离，系统需要对反馈操作进行相应权限验证和控制。
用户基于移动端应用进行反馈时，可以查看反馈任务的详细信息，包含反馈飞机信息、软件及件号信息、反馈状态等。
3.系统非功能性要求
3.1.可用性要求
后台年可用性指标：
99.9%，包括主机硬件、操作系统和主机应用程序。
用户最长容忍故障恢复时间：
60分钟。
系统平均年连续无故障运行时间：
大于525000分钟。
停机维护次数和时间：
年允许停机维护4次，每次60分钟。
系统目标用户数量：
500个。
最大并发用户数量：
30个。
3.2.安全性要求
达到GB/T22240—2008《信息系统安全等级保护定级指南》要求；
目标系统能够通过角色向用户进行职责和权利分配；
目标系统只支持自身用户验证方式登陆；
不允许业务用户直接登录数据库；
目标系统在用户和授权方面支持按照组织架构分级分片进行管理；
目标系统至少支持通过组织数据、信息类型、个人数据和报表四个方面授权；
目标系统应支持中央管理模式，在一个系统内创建用户，然后将用户发布到其他指定系统内，被管理的系统的用户数据可以随时和中央系统同步；
在密码策略上，要符合信息管理部的安全管理规定，系统内部口令及管理口令为8位长度及以上，复杂度包含字母、大小写、数字、特殊字符等。
3.3.易用性要求
用户体验度：
考虑到用户计算机整体知识水平，用户界面简洁，各项功能相应界面清晰，排版合理，符合用户期望描述。
符合用户操作习惯，具有良好的适用性和易用性。
系统响应时间指标：
系统功能操作平均响应时间：
3秒。
3.4.可维护性要求
系统应具备高可维护性，便于功能的加载、扩展、更新和修正。
3.5.可移植性要求
系统具备良好的扩展性和可移植性；具备业务处理的灵活构型，支持业务功能的灵活重组与更新；支持移动端的业务需求。
3.6.兼容性要求
浏览器兼容性：
IE浏览器（8-11）、Chrome浏览器（各版本）、QQ浏览器、火狐浏览器、搜狗浏览器、360浏览器等。
应用系统兼容操作系统：
WindowsXP;WindowsVISTA;Windows7、Windows8、Windows10等。
语言版本：
中文、英文。
文件下载：
OFFICE（word、excel）、PDF、WPS。
3.7.开放性要求
工作流引擎使用activiti，数据库使用Oracle。
3.8.设计约束
本项目按照国航信息系统建设的OSS、4H要求进行设计。
4.实施方案要求
4.1.设计方案要求
Ø总体架构
机载软件构型管理系统总体架构，由波音电子化机型构型管理、空客电子化机型构型管理、非电子化机型构型管理模块及移动数据服务四大版块组成。
系统整体结构为B/S结构，自上而下分成五层：
交互层：
系统支持PC机浏览器方式访问，并提供统一用户访问界面。
对于飞机的构型数据查询及部分业务办理，为了避免地域或网络的限制，满足航站机务人员飞机单机构型状态查询和装载任务反馈的需要，需要系统提供移动端数据服务支持。
应用层：
包含波音电子化机型构型管理模块、空客电子化机型构型管理模块、非电子化机型构型管理模块以及移动数据网关服务。
系统基于软件构型管理和业务流程管理两条主线设计，软件构型管理和业务流程管理保持松散耦合，同时又有相应的关联，并与外部工具、接口、系统进行集成，实现不同机型机载软件构型的闭环控制。
服务层：
由系统相关基础服务或通用功能模块组成，以支撑上层应用。
主要包含了用户认证、安全控制、监控告警、流程引擎、系统管理、配置管理等。
数据层：
业务数据库主要包含了波音电子化机型、空客电子化机型、非电子化机型的构型存储库以及基础数据、配置数据、流程数据等内容。
基础设施层：
主要由服务器、网络、中间件、外围关联系统等组成，以提供系统运行、应用集成、网络通讯、数据存储、服务交联等支撑。
Ø物理架构
系统物理架构基于现有的服务器资源配置，只需适当扩容即可，系统由LCM系统虚拟化应用服务器、LCM系统数据库虚拟化服务器组成，并与LSAPL、FLSR、LSE等系统存储服务集成，并支持与外围相关工具、接口等进行数据交联服务。
其中两台应用服务器通过nginx实现高可用和负载均衡，两台数据库服务器为双机热备方式。
Ø技术架构
本系统总体架构中的波音电子化机型构型管理模块和非电子化机型构型管理模块均基于J2EE规范的分层结构之架构思路上建设，其中波音电子化机型构型管理模块已经投产并稳定运行两年，其应用开发框架采用了MVC设计模式，并应用了GoF设计思想，通过将代码按照层次划分为业务逻辑或数据处理、用户界面、应用流程控制这三个层次，系统中各个组件模块的功能按照高内聚、低耦合原则相互独立封装，层与层之间保持松耦合关联，以增强代码稳定性，确保系统的灵活性、可扩展性及易维护性。
空客A350电子化运行机型的构型管理版块亦基于此架构建设，以保证技术平台及架构的一致性，并能灵活、快速的满足后续业务扩展需求，同时降低系统的运维成本。
涉及的相关技术：
开发框架基于Javascript、Jquery、Bootstrap、Spring、Mybatis、Shiro、Quartz、Activiti、Mail、WebService、Junit等技术，数据库采用Oracle11g，应用中间件采用Tomcat，构建工具采用Maven。
4.2.开发方案要求
Ø遵循《国航应用开发安全管理规范》，进行开发工作。
Ø所实现的客户化代码必须有严格的注释并作为交付物在项目结束时交付给国航，并由国航进行验收。
Ø中标人需要在标书中提供具体的开发过程系统管理手段、方式、方法、流程；代码的维护方式、方法和如何进行版本控制等。
Ø本项目的功能开发基于现有LCM系统，要求供应商在现有技术平台、基础管理模块、数据库基础上客户化A350构型管理系统，并通过架构设计和功能开发确保A350构型管理模块不影响已上线的波音电子化运行构型管理模块、非电子化机型构型管理模块的功能；同时具备电子化运行管理平台的开发维护能力，含已上线的功能模块，可根据用户需求对现有的电子化运行管理平台的UI、数据报表、应用系统监控等功能进行优化。
4.3.集成方案要求
投标人负责本次项目中集成实施工作，具体工作内容包括但不限于：
平台应用部署，系统接口开发、部署、联调测试。
集成工作包括完成项目范围内的软硬件安装、调试、部署、测试、培训、上线、试运行等具体实施工作。
4.4.风险点及难点解决方案要求
要求投标人列出项目（业务、咨询、功能、非功能等）相关的技术风险和难点，并做出评估并给出解决措施与意见。
4.5.咨询方案要求
无
升级会员 