Airline - Integration - With - Airbus - IS - v1 4

In-Service Data Sharing
Full Automatic Reporting implementation
1
Table of Contents
1. INTRODUCTION 4
1.1 IN-SERVICE DATA SHARING 4
1.2 FULL AUTOMATIC SOLUTION 4
2. SOLUTION OVERVIEW AND GENERIC REQUIREMENTS 4
2.1 SOLUTION OVERVIEW 4
2.2 GENERIC REQUIREMENTS 5
2.2.1 Connection to FTS+ 5
2.2.2 Monitoring/Log 6
2.2.3 Master flows & Administration module 6
2.2.4 Data control 7
3. IN-SERVICE DATA REPORTING 7
3.1 RELIABILITY, SCHEDULED MAINTENANCE AND SERVICE BULLETIN

REPORTING 7
3.1.1 Data scope and format 7
3.1.2 Frequency 9
3.1.3 Control file 9
3.2 WARRANTY CLAIMS 10
3.2.1 Data scope and format 10
3.2.2 Frequency 11
3.2.3 Control file 11
4. DEPLOYMENT 11
5. REFERENCE DOCUMENT 13
6. TERMINOLOGY 13
7. APPENDIX 14
7.1 FTS+ API DOCUMENTATION 14
2
7.2 DETAILED DESCRIPTION 14
7.2.1 Aircraft Hours and Landings - Required data and format 14
7.2.2 Aircraft Events - Required data and format 15
7.2.3 Technical Logbook - Required data and format 17
7.2.4 Component Removal – Required data and format 18
7.2.5 Engine Removal - Required data and format 20
7.2.6 APU Removal – Required data and format 21
7.2.7 Performed Scheduled Maintenance and Findings – Required data and format 22
7.2.8 Service Bulletin – Required data and format 24
7.2.9 Warranty Claims – Required data and format 25
3
1. INTRODUCTION
ISDS, sharing Fleet Performance to improve Fleet Performance.
1.1 IN-SERVICE DATA SHARING
ISDS (In-Service Data Sharing) is a set of solutions aiming at setting a simple & efficient in-
service data access for fleet performance optimization.
ISDS is proposing different scenarios of data collection from the manual upload to the full auto-
matic data exchange.
Security and data confidentiality are of primary of importance for our customers. On security as-
pect, ISDS is using secured Web protocols and interfaces.
Sharing is also a cornerstone of ISDS: to offer the possibility of data sharing between operators,
aircraft manufacturers and suppliers.
1.2 FULL AUTOMATIC SOLUTION
The Full Automatic Solution allows you to provide Airbus with your data automatically without
any human intervention. It is based on Machine To Machine data flow.
This document aims at describing the solution offered by Airbus to set-up Full Automatic Data
Exchange.
2. SOLUTION OVERVIEW AND GENERIC REQUIREMENTS

2.1 SOLUTION OVERVIEW
The solution is based on an Airbus solution, named “FTS+”.

This File Transfer Service (FTS) aims at providing a secure and reliable solution for file ex-
changes between Airbus and its Customers. The in-service data reporting is done in 3 steps:
• Step 1: upload of your Spec2000 data through FTS+, as an XML file
• Step 2: when this upload is completed, upload a control file (i.e. an empty file with a spe-
cific name), in order to inform Airbus that the Spec2000 data has been uploaded
• Step 3: manage the potential technical errors raised by the transfer to FTS+ (ex.: in case
of FTS+ unavailability)
For these uploads, you will have to develop the means to generate the Spec2000 files, and to
upload them to FTS+. This second part, i.e. the connection and upload to FTS+, is performed
through:
- Either a JAVA API provided by Airbus
- Or by using standard FTPS protocol
Further details are available in the next chapters.
The following figure describes the process to manage the files exchange using FTS+.
4
Figure 1: Data exchange process
Note: the functional errors, i.e. the functional cases where Airbus is not able to import your ‘in-
service’ data, are visible and can be monitored through AirbusWorld portal, “Data Loading Inter-
face” (DLI) service.
For security aspects, each operator using FTS+ has its own storage space (data segregation
principle), with specific credentials and therefore has no capability to have access to other oper-
ators data.
2.2 GENERIC REQUIREMENTS
This paragraph details generic requirements that are applicable whether you exchange reliabil-
ity, scheduled maintenance, service bulletin or warranty claims data.
2.2.1 Connection to FTS+
Login
Each operator connects to FTS+ thanks to a login named “FTS Application Service Account
(SA)” and a password.
Airbus provides you with a “FTS application Service Account” (logon & password).
Password management
The password must be change at least once a year.
A focal point within your company shall be nominated in order to be reminded by Airbus for the
password update before its expiration.
As such, these credentials information shall be customisable in your information system.
Warning: the password must not contain any of following characters: !?+
Information to connect to FTS+ for ISDS

The operator connects to FTS+ via one of the two URLs:
• ftsplus-v.airbus.com for validation environment and testing purpose
• ftsplus.airbus.com in production environment
In order to send files to FTS, two solutions are possible:

• Usage of the FTS+ Java API (HTTPS protocol, TCP/443)
5
• Usage of FTPS standard protocol (FTPS protocol <<Port number is still to be defined
at the moment of writing: please contact your Airbus focal point for obtaining this infor-
mation>>)
Folder structure
The FTS+ structure is defined with a folder by operator (only this operator is authorised to
read/write in).
Path example: FTS-MIS-IF/AIB/xxx.xml
The files (xml, control file) must be directly uploaded under this operator’s dedicated folder (no
other sub-folder).
FTS+ Java API

FTS+ API is provided in appendix with its documentation.
There is one major release of FTS+ API per year. The two last FTS+ API are supported.
Operator shall ensure to upgrade to latest FTS+ API at least once a year.
FTPS standard protocol

Airbus does not deliver anything in this case, standard FTPS implementation is required. Au-
thentification is also managed through user/password that Airbus will provide. (<<Verisign certif-
icate to be trusted: still to be defined at the moment of writing, please contact your Airbus focal
point for obtaining this information>>).
2.2.2 Monitoring/Log
Monitoring /Log
We advise you to log the data that has been uploaded (date, filename) for tracking purpose.
We also advise to log information on any step related to data exchange (file generation, connec-
tion step, etc.).
Connection issue
In case of connection issue (for example related to FTS+ unavailability) we advise you to make
three trials.
If the file upload always failed at the third try, the problem must be managed by your internal
administrator (for example: an e-mail can be send to an airline administrator who will contact
either AirbusWorld support or DLI support (dli.contact@airbus.com) to analyse the problem and
agree on actions to solve it).
2.2.3 Master flows & Administration module
Flow mastering
Airbus advice operators to be able to master (activate/deactivate) data flow exchange with Air-
bus.
The operator shall be able to define:
• Data type: which data type (Spec2000 record) shall be exchanged
• Aircraft Type: Aircraft type concerned (if applicable)
Operators shall be able, if applicable, to configure the interval of time between the end of report-
ing period and the data exchange (for example: monthly reports will be sent 5 days after the end
of the month).
Parameters management
6
The FTS+ url, port, login, password, path name (folder name) must be configurable.
If feasible, the interval of time between the end of reporting period and the data exchange must
be configurable too.
Airbus fleet
Only data related to Airbus fleet shall be uploaded.
Data export
We advise operators to be able to perform manual export.
The exported files should be transmitted via AirbusWorld portal / Data Loading Interface service
(upload) or other means in case of FTS unavailability (workaround solution).
2.2.4 Data control
Spec2000 conformity
Operators must check the XML file conformity before uploading it.
3. IN-SERVICE DATA REPORTING

3.1 RELIABILITY, SCHEDULED MAINTENANCE AND SERVICE BULLETIN REPORTING
3.1.1 Data scope and format
Data scope
This interface enables operators to push the following data:
• Aircraft Hours and Landings (Spec2000 ch.11): this record is for detailing the daily flight
hours (airborne or block) and take-offs performed by the aircrafts of an operator’s fleet.
• Aircraft Events (Spec2000 ch.11): this record is for detailing operational Interruptions &
technical Incidents. Operational Interruptions are Delay, Cancellation, In-Flight Turn-
back and Diversion. A Delay is a technical delay (equivalent to IATA code 41 to 46).
Technical Incidents are all major incidents that must be reported to the authority.
• Technical Logbook (Spec2000 ch.11): this record is used to collect Complaint written in
the logbook by the pilot, cabin crew or maintenance crew.
• LRU Removal (Spec2000 ch.11): this record is used to report on removals and includes
the 3 following categories: Component Removal used to report on LRU unscheduled
removal (only serialized parts), Engine Removal used to report on Engine scheduled and
unscheduled removal and APU Removal used to report on APU scheduled and un-
scheduled removal.
• Performed Scheduled Maintenance and Findings (Spec2000 ch.11): this record is for col-
lecting aircraft scheduled maintenance visit data.
• Service Bulletin (Spec2000 ch.11): this record is for collecting information on the incorpo-
ration of service bulletins, other modifications such as Supplemental Type Certificates
and Airworthiness Directives when included with a Service Bulletin.
Supported format
Data shall be exchanged thanks to Standard Spec2000 chapter 11.
All Spec2000 mandatory fields are expected. For optional ones, Airbus specified the data that
should be reported in priority (see 7.2).
The following Spec2000 versions are supported:
7
8
Spec2000 rec-
2006 2007 2008 2009 2011 2012
ords
Aircraft hours
and landings      
Aircraft Events      
Logbook      
LRU removal      
Scheduled
Maintenance      
Service bulletin      
Table 1: Spec2000 supported version
Spec2000 version identification

The attribute id of the ATA_InformationSet element permits to identify the Spec2000 version.
The version of the record element must be coherent with the associated XSD version.
3.1.2 Frequency
Reliability, Scheduled Maintenance and Service Bulletin data shall be reported on monthly ba-
sis. Operators shall export one file per record, per month and aircraft type (or aircraft family).
Modification
In case of modification (data created, updated, deleted or cancelled) on a period already ex-
changed, the operator must export again the full scope period (total replacement data for report-
ing period).
For instance, in case of modification of an event during a previous month, the totality of the
events of the month must be resent.
Empty period / No data

In case of no data for a period, the operator should not export any record but warn Airbus that
no data will be uploaded.
3.1.3 Control file
For Reliability, Scheduled Maintenance and Service Bulletin, in order to monitor the asynchro-
nous data transfer, when the xml file upload is ended, operators shall upload an empty file in
FTS with same name as xml file and a ctl extension.
Ex: AIS2k-FH020913_ 1378284643024.ctl is associated to AIS2k-FH020913_
1378284643024.xml
9
3.2 WARRANTY CLAIMS
3.2.1 Data scope and format
Data scope
This interface enables operators to push the following data:
• Warranty claims: (Spec2000 ch.14): Only claim creation (submittal) is managed thanks to
machine to Machine data exchange. Any modification or deletion shall be done thanks to
the Airbus dedicated application WarrantyXpress.
Supported format
Data shall be exchanged thanks to Standard Spec2000 chapter 14.
All Spec2000 mandatory fields are expected. For optional ones, Airbus specified the data that
should be reported in priority (see 7.2).
The following Spec2000 versions are supported:
Spec2000 rec-
2006 2007 2008 2009 2011 2012
ords
Warranty
claims      
Table 2: Spec2000 supported version
Attachment
For Warranty claims, operators can export attachments associated to the claim.
Attachments can be of any type but cannot be an xml file not clm file.
An attachment can be a picture (*.jpg, ..) or a compressed file (e.g. zip file) including several
files.
Attachments shall be compliant with following naming convention: all attachments file name
shall start by the xml claim filename (see example blow).
The attachment file size is limited to 4Mo. You are limited to 5 attachments.
Therefore for one claim you can have up to three files:

• The claim itself (Spec2000 xml file),
• The attachments,
• The control file (see below).
For example:
- ClaimABC.xml
- ClaimABC.jpg
- ClaimABC.pdf
- ClaimABC.zip
- ClaimABC.doc
10
3.2.2 Frequency
Warranty claims can be submitted at any time. One file shall contain one single claim.
3.2.3 Control file
For Warranty claims, in order to monitor the asynchronous data transfer, when the xml file and
its attachments upload is ended, the operator shall upload an empty file in FTS with same name
as xml file and a clm extension
Ex: CLM_012345.clm associated to CLM_012345.xml
4. DEPLOYMENT
In order to deploy the Full Automatic data exchange between operators and Airbus, the follow-
ing steps must be followed:
1. The operator supplies Airbus with file examples for data validation (for instance by using
manual export function in its information system). An export example of all kinds of data
you want to exchange with Airbus is required.
2. Airbus analyse the files and provide feedbacks on data quality
3. Once data quality is validated, Airbus provide operator with login, password and folder
name.
4. The operator set-up its Information System and configure the exchange (data flow, air-
craft type…)
11
5. The operator informs Airbus of the start of the automatic exchange and informs Airbus
about the exchange type (which data is exchanged and when)
6. The operator and Airbus are coordinating the beginning of automatic reporting
For any contact with Airbus, as listed in the above steps, please use the following generic ad-
dress: dli.contact@airbus.com.
12
5. REFERENCE DOCUMENT
Reference Author Document Name Revision

Spec2000 version 2006 Air Transport Association E-Business Specification for 2006.1
Materiels Management
Spec2000 version 2012.2 Air Transport Association E-Business Specification for 2012.2
FTS+ API and documen- Airbus FTS+ API and associated docu-
tation mentation
6. TERMINOLOGY
API Application Programming Interface

DLI Data Loading Interface
ISDS In-Service Data Sharing
13
7. APPENDIX
7.1 FTS+ API DOCUMENTATION
FTS+ API and its documentation is described in [FTS+ API and documentation].
7.2 DETAILED DESCRIPTION
N.B.: If Airbus terms are not equivalent to Spec2000 Business terms, it is highlighted in red col-
or in the table below.
7.2.1 Aircraft Hours and Landings - Required data and format
This record details the flight hours (airborne or block) and take-offs performed by the aircrafts of
an operator’s fleet during the reporting period.
This information is provided by aircraft operators.
Refer to Spec2000 version 2011 to get further information on the format description.
These are the data Airbus would like to get in priority.
Mandatory, Condi-
Airbus term Spec2000 business term tional or Recom-
mended
Record Status Record Status Mandatory
Reporting Organization Code Reporting Organization Code Mandatory
Reporting Period Start Date Reporting Period Start Date Mandatory
Reporting Period End Date Reporting Period End Date Mandatory
Operator Code Operator Code Mandatory
Operator Name Operator Name Optional
Airframe Manufacturer Code Airframe Manufacturer Code Mandatory
Aircraft Model Aircraft Model Mandatory
Aircraft Manufacturer Serial Mandatory
Aircraft Manufacturer Serial Number
Number
Aircraft Registration Number Aircraft Registration Number Mandatory
Aircraft Cumulative Total Flight Mandatory
Aircraft Cumulative Total Flight Hours
Hours
Aircraft Cumulative Total Flight Mandatory
Aircraft Cumulative Total Cycles
Cycle
Total Flight Hours Airborne of the Mandatory
Aircraft Total Flight Hours
day
Revenue Flight Hours Airborne of Optional
Aircraft Revenue Flight Hours
the day
ETOPS Flight Hours Airborne of Optional
Aircraft ETOPS Flight Hours
the day
Total Take-offs Airborne of the Mandatory
Aircraft Total Landings (Cycles)
day
14
Revenue Take-offs Airborne of Mandatory
Aircraft Revenue Departures
the day
ETOPS Revenue Take-offs Air- Optional
Aircraft ETOPS Revenue Departures
borne of the day
Aircraft APU Type Aircraft APU Type Conditional
Aircraft APU Serial Number Aircraft APU Serial Number Conditional
APU Cumulative Total Hours APU Cumulative Total Hours Conditional
APU Cumulative Total Cycles APU Cumulative Total Cycles Conditional
7.2.2 Aircraft Events - Required data and format
Aircraft Events record is details operational Interruptions & technical Incidents.

Operational Interruptions are Delay, Cancellation, In-Flight Turn-back and Diversion.
A Delay is a technical delay (equivalent to IATA code 41 to 46).
Technical Incidents are all major incidents that must be reported to the authority:
- Fire (real or warning),
- Runway Overshoot,
- System Failure, Emergency Procedure, Abnormal Operation,
- Smoke (real or warning),
- Burnt,
- Aborted Approach,
- Abandon Aircraft,
- Aborted take-off,
- Belly landing / Ditching,
- Depressurization,
- Diversion,
- Emergency descent,
- Engine shutdown in-flight,
- Interrupted flight (ATO).
Mandatory, Condi-
mended
Operator Code Operator Code Mandatory
Aircraft Model Aircraft Model Mandatory
15
Aircraft Manufacturer Serial Mandatory
Aircraft Manufacturer Serial Number
Number
Event Unique Identifier Event Record Identifier Mandatory
Flight Number Departure Flight Number Optional
Event Date Event Occurrence Date Mandatory
Station From Departure / Reporting Station Code Mandatory
Station To Arrival Station Code Optional
ETOPS Flight ETOPS Flight Indicator Mandatory
Event During ETOPS Phase Indi- Mandatory
Event During ETOPS Phase Indicator
cator
Recommended by Air-
ATA Discrepancy Airline ATA System Code (Discrepancy/ Symptom)
bus
Action Performed ATA Airline ATA System Code (Maintenance Action) Optional
AOG Flag Aircraft on Ground Indicator Mandatory
Delay Flag (Direct Cause) Delay Indicator Mandatory
Delay Duration In Minutes Delay Time Optional
Cancellation Flag (Direct Cause) Cancellation Indicator Mandatory
Aircraft Changed Flag Substitute Aircraft Indicator Mandatory
Aborted Take Off Flag Aborted Take-off Indicator Mandatory
In Flight Turn Back Flag Air Turnback Indicator Mandatory
General Air Interrupts Indicator General Air Interrupts Indicator Mandatory
Ground Interruption Flag General Ground Interrupt Indicator Mandatory
Aborted Approach Flag Aborted Approach Indicator Mandatory
Return to Gate Indicator Return To Gate Indicator Mandatory
Diversion Flag Diversion Indicator Mandatory
Engine Shut Down Flag In-Flight Shutdown Indicator Mandatory
Emergency Descent Flag Emergency Descent Indicator Mandatory
Service Interruption Chargeabil- Mandatory
Service Interruption Chargeability Indicator
ity Indicator
Suspected Maintenance Error Mandatory
Suspected Maintenance Error Indicator
Indicator
Suspected Operational Error In- Mandatory
Suspected Operational Error Indicator
dicator
Technical Incident Indicator Technical Incident Indicator Mandatory
READI Exclusion Indicator (Ref- Mandatory
READI Exclusion Indicator (Reference READI Group)
erence READI Group)
Event Description Aircraft Event Text Mandatory
Maintenance Work Performed Aircraft Event Text (Corrective Action) Optional
Logbook Reference Logbook Record Identifier (Discrepancy) Conditional
16
7.2.3 Technical Logbook - Required data and format
It is used to collect Complaint written in the logbook by the pilot, cabin crew or maintenance
crew.
Mandatory, Condi-
mended
Operator Code (Operator of the Mandatory
Operator Code
Flight)
Operator Name (Operator of the Optional
Operator Name
Flight)
A/C Type Aircraft Model Mandatory
MSN Aircraft Manufacturer Serial Number Mandatory
A/C Serie Aircraft Series Optional
Engine version Aircraft Engine Model Conditional
Aircraft Engine Type Aircraft Engine Type Conditional
Engine Serial Number Engine Serial Number Conditional
Engine Position Code Engine Position Code Conditional
Aircraft APU Type Aircraft APU Type Conditional
Aircraft APU Serial Number Aircraft APU Serial Number Conditional
Logbook Reference Logbook Record Identifier Mandatory
Defect Date Discrepancy Occurrence Date Mandatory
Source Type Mandatory
Discrepancy Origination Type Code
(PIREP/CAREP/MAREP/CARGO)
Station From Departure / Reporting Station Code Mandatory
Station To Arrival Station Code Optional
Technical Incident Technical Incident Indicator Mandatory
ETOPS Flight Indicator ETOPS Flight Indicator Mandatory
ATA Airline ATA System Code (Discrepancy/Symptom) Optional
Defect Description Discrepancy Text Mandatory
Departure Date Actual Departure Date Optional
Flight Type Type Of Flight Optional
Flight Phase Phase Of Flight Optional
17
Flight Number Departure Flight Number Optional
Fault Code Aircraft Message Code Optional
Aircraft Message Aircraft Message Text Optional
Comment Comment Text Optional
Action reference Maintenance Tracking Identifier Mandatory
Reference Logbook Record Iden- Mandatory
Reference Logbook Record Identifier
tifier
Maintenance Activity Type Mandatory
Maintenance Type Code
(Scheduled, Unscheduled, Other)
Action Date Maintenance Action Date Mandatory
Action End Date Maintenance Action Completion Date Mandatory
Maintenance Station Maintenance Action Station Code Mandatory
Logbook Status Mandatory
Maintenance Action Status Code
(Open/Closed/Deferred)
Maintenance Action Text Maintenance Action Text Mandatory
ATA Airline ATA System Code (Maintenance Action) Mandatory
Deferral reason Maintenance Action Deferral Reason Text Optional
Maintenance Action Code Maintenance Action Code Optional
7.2.4 Component Removal – Required data and format
It is used to report on LRU unscheduled removal (only serialized parts).

Mandatory, Condi-
mended
Operator ICAO Code (Operator Mandatory
Operator Code
of the Flight)
Operator Name (Operator of the Mandatory
Operator Name
Flight)
Aircraft Type Aircraft Model Mandatory
A/C Registration Aircraft Registration Number Mandatory
A/C MSN Aircraft Manufacturer Serial Number Mandatory
Removal Date Removal Date Mandatory
Removal Type Code Mandatory
Removal Type Code
(=Unscheduled)
18
OEM Cage Code Removed Part Manufacturer Code Mandatory
Removed Manufacturer Full Mandatory
Removed Manufacturer Full Length Part Number
Length Part Number
Removal Identifier Removed PART Record Identifier Mandatory
Component S/N Off Removed Manufacturer Serial Number Mandatory
Removal Reason Removal Reason Text Mandatory
Eqpt Supplier Name Removed Part Manufacturer Name Optional
Component P/N Off Removed Manufacturer Part Number Optional
Denomination Removed Part Name Optional
ATA Airline ATA System Code Optional
Time/Cycle Reference Code = Conditional
Time / Cycle Reference Code
Since Installation (SI)
Time Since Installation (TSI) Operating Time Optional
Cycle Since Installation (CSI) Operating Cycle Count Optional
Since New (SN)
Time Since New (TSN) Operating Time Optional
Cycle Since New (CSN) Operating Cycle Count Optional
Since Overhaul (SO)
Time Since Overhaul (TSO) Operating Time Optional
Cycle Since Overhaul (CSO) Operating Cycle Count Optional
Since Last Shop Visit (SLSV)
Time Since Last Shop Visit Optional
Operating Time
(TSLSV)
Cycle Since Last Shop Visit Optional
Operating Cycle Count
(CSLSV)
Component P/N On Installed Manufacturer Part Number Optional
Component S/N On Installed Manufacturer Serial Number Conditional
Installed Date Installed Date Mandatory
Installed Part Manufacturer Mandatory
Installed Part Manufacturer Code
Code
Installed Manufacturer Full Mandatory
Installed Manufacturer Full Length Part Number
Length Part Number
Logbook Record Identifier Logbook Record Identifier Conditional
Link to Aircraft Event Event Record Identifier Optional
Aircraft Cumulative Total Hours Aircraft Cumulative Total Hours Optional
Aircraft Cumulative Total Cycles Aircraft Cumulative Total Cycles Optional
APU Cumulative Hours APU Cumulative Hours Optional
APU Cumulative Cycles APU Cumulative Cycles Optional
19
7.2.5 Engine Removal - Required data and format
It is used to report on Engine scheduled and unscheduled removal.

Mandatory, Condi-
mended
Operator ICAO Code (Operator of Mandatory
Operator Code
the Flight)
Operator Name
Flight)
Registration Aircraft Registration Number Mandatory
Engine Type Aircraft Engine Type Mandatory
(Engine) Position Engine Position Code Mandatory
Engine Serial Number Engine Serial Number Mandatory
Aircraft Engine Model Aircraft Engine Model Mandatory
Open Date Removal Date Mandatory
Scheduled Flag Removal Type Code Mandatory
Removed Part Manufacturer Code Removed Part Manufacturer Code Mandatory
Removed Part Manufacturer Full Mandatory
Length Part Number
Serial Number Off Removed Manufacturer Serial Number Mandatory
Description Removal Reason Text Mandatory
Removed Part Record Identifier Removed PART Record Identifier Mandatory
Fault Aircraft Message Code Optional
Work Performed Maintenance Action Text Optional
Action Discrepancy ATA Airline ATA System Code Optional
Actual Part Cycles Engine Cumulative Cycles Optional
Actual Part Flight Hours Engine Cumulative Hours Optional
Installed Part Manufacturer Code Installed Part Manufacturer Code Mandatory
Installed Part Manufacturer Full Mandatory
Installed Manufacturer Full Length Part Number
Length Part Number
20
Serial Number On Installed Manufacturer Serial Number Mandatory
7.2.6 APU Removal – Required data and format
It is used to report on APU scheduled and unscheduled removal.

Mandatory, Condi-
mended
Operator ICAO Code (Operator of Mandatory
Operator Code
the Flight)
Operator Name
Flight)
APU type Aircraft APU Type Mandatory
Aircraft APU Serial Number Aircraft APU Serial Number Mandatory
Aircraft APU Model Aircraft APU Model Optional
Open date Removal Date Mandatory
Scheduled Flag Removal Type Code Mandatory
Removed Part Manufacturer Code Removed Part Manufacturer Code Mandatory
Removed Part Manufacturer Full Mandatory
Length Part Number
Serial Number Off Removed Manufacturer Serial Number Mandatory
Description Removal Reason Text Mandatory
Removed Part Record Identifier Removed PART Record Identifier Mandatory
Fault Aircraft Message Code Optional
Work Performed Maintenance Action Text Optional
Action Discrepancy ATA Airline ATA System Code Optional
Actual Part Cycles APU Cumulative Cycles Optional
Actual Part Flight Hours APU Cumulative Hours Optional
Installed Part Manufacturer Code Installed Part Manufacturer Code Mandatory
Installed Part Manufacturer Full Installed Manufacturer Full Length Part Number Mandatory
21
Length Part Number
Serial Number On Installed Manufacturer Serial Number Mandatory
7.2.7 Performed Scheduled Maintenance and Findings – Required data and format
Mandatory, Condi-
mended
OPERATOR (Aircraft operator) Operator Code Mandatory
Scheduled Maintenance Record Mandatory
Scheduled Maintenance Record Identifier
Identifier
Operator Specific Task Indicator Operator Specific Task Indicator Mandatory
Date at Reported Inspection (Task Mandatory
Task End Date
End Date)
TASK NUMBER Airframer Maintenance Task Number Optional
Recommended by
FH at Reported Inspection Aircraft Cumulative Total Flight Hours
Airbus
Recommended by
FC at Reported Inspection Aircraft Cumulative Total Cycles
Airbus
Check Package Type Operator Maintenance Check Identifier Optional
Approved Interval Optional
(Interval actually approved by the Operator Maintenance Check Interval Text
local Authorities)
Actual interval since the previous Recommended by
inspection Operating Day Count Airbus
Nber of months
inspection Operating Time Airbus
Nber of FH
inspection Operating Cycle Count Airbus
Nber of FC
22
A/C status at previous inspection: Optional
Previous Inspection Date
Date at previous inspection
Inspection Method Used Inspection Method Description Optional
Finding? (Y/N) Maintenance Finding Indicator Mandatory
Maintenance Task Out-Of-Scope Conditional
Maintenance Task Out-Of-Scope Finding Indicator
Finding Indicator
Finding N° Conditional
Non Routine Tracking Number
(ONLY NUMBER)
Details of Finding Conditional
(e.g. corrosion Level, compo-
nent/element which failed and Maintenance Findings Defect Text
how did it fail, possible reasons
for defect)
Type of Findings Maintenance Findings Defect Code Conditional
Associated Corrective Action Non-Routine Corrective Action Taken Text Conditional
ATA 100 Code Airline ATA System Code (Discrepancy/Symptom) Optional
Corrosion Level (0,1,2,3) Corrosion Level Conditional
Corrosion Type (Only valid code) Corrosion Type Code Optional
Temporary Protection System Conditional
Corrosion Temporary Protection System Indicator
TPS? (Y,N,D)
Temporary Protection System Corrosion Temporary Protection System Visible Indi- Conditional
Visible?(Y,N,D) cator
Temporary Protection System Optional
TPS Type Previous CPCP
Previous type
Temporary Protection System Optional
TPS Type Current CPCP
Current type
Cumul Blend-Out Conditional
Cumulative Blend-Out CPCP Indicator
(Y,N,D) [cf CPCP]
Non-Typical Indicator Conditional
Non-Typical Corrosion CPCP indicator
(Y,N,D) [cf CPCP]
Location of Damage Optional
Airframe Manufacturer Maintenance Zone
Zone Number
Left Hand, Right Hand Airframe Left Hand/Right Hand Position Code
LH/RH
Aircraft Model Stringer Identifier
Between Stringer and Stringer
Aircraft Frame Identifier
Between Frame and Frame
Airframe Rib Identifier
Between Rib and Rib
Airframe Spar Identifier
Spar
Zone Location Indicator
External/Internal/Both (E, I, X)
Airframe Station Identifier
Station
23
Part Concerned Part Type Code Optional
Repair Approval Sheet (RAS) Optional
Repair Approval Reference
Number (if available)
Material Type Repair Structural Material Type Description Optional
Extent of Damage : Optional
(ref. to SRM 51.10.13/51.11.13 for Damage Length with Unit (mm/inches)
criteria) Length
(ref. to SRM 51.10.13/51.11.13 for Damage Width with Unit (mm/inches)
criteria) Width
(ref. to SRM 51.10.13/51.11.13 for Damage Depth with Unit (mm/inches)
criteria) Depth
Original Material Thickness Remaining Thickness with Unit (mm/inches) Optional
Removal Date Removal Date Conditional
Removed Part Manufacturer Code Removed Part Manufacturer Code Conditional
Removed Manufacturer Full Conditional
Length Part Number
Removed Manufacturer Serial Conditional
Removed Manufacturer Serial Number
Number
Install Date of Removed Part Install Date of Removed Part Optional
Removed P/N (Removed Manu- Recommended by
Part Number
facturer Part Number ) Airbus
Overlength Part Number Overlength Part Number Optional
Removed Part Name Removed Part Name Optional
Removed Universal Serial Number Removed Universal Serial Number Optional
Removed part position relative to Removed part position relative to power plant or Optional
power plant or APU APU
Recommended by
Component FIN Part Position Code
Airbus
Part Position Part Position Optional
Removal Reason Text Removal Reason Text Optional
Removed Part Modification Level Removed Part Modification Level Optional
Removed Operator Part Number Removed Operator Part Number Optional
Removed Operator Serial Number Removed Operator Serial Number Optional
Supplier Code Supplier Code Optional
Removed Universal Serial Tracking Optional
Removed Universal Serial Tracking Number
Number
7.2.8 Service Bulletin – Required data and format
24
Mandatory, Condi-
mended
Reporting Organization code Reporting Organization Code Mandatory
Reporting Period Start date Reporting Period Start Date Mandatory
Reporting Period End date Reporting Period End Date Mandatory
Operator (Aircraft operator) Operator Code Mandatory
Airframe Manufacturer Mandatory
Airframe Manufacturer Code
Code
Aircraft type Aircraft Model Mandatory
Accomplishment Type Indi- Mandatory
Accomplishment Type Indicator
cator
Accomplishment Date Accomplishment Date Mandatory
Modification Document Mandatory
Modification Document Type Code
Type Code
Document Source Document Source Mandatory
Issuance Date Issuance Date Mandatory
Service Bulletin Inspection Mandatory
Service Bulletin Inspection Indicator
Indicator
Service Bulletin Incorpora- Mandatory
Service Bulletin Incorporation Status Code
tion Status Code
Service Bulletin Number Service Bulletin Number Optional
Service Bulletin Inspection Optional
Service Bulletin Inspection Findings Text
Findings Text
Airline Internal Reference Optional
Airline Internal Reference Number
Number
Reason Text Reason Text Optional
7.2.9 Warranty Claims – Required data and format
25

Airline - Integration - With - Airbus - IS - v1 4

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Airline - Integration - With - Airbus - IS - v1 4

Încărcat de

Drepturi de autor:

Formate disponibile

In-Service Data Sharing

Full Automatic Reporting implementation

1.1 IN-SERVICE DATA SHARING 4

1.2 FULL AUTOMATIC SOLUTION 4

2. SOLUTION OVERVIEW AND GENERIC REQUIREMENTS 4

2.1 SOLUTION OVERVIEW 4

2.2 GENERIC REQUIREMENTS 5

2.2.1 Connection to FTS+ 5

2.2.3 Master flows & Administration module 6

2.2.4 Data control 7

3. IN-SERVICE DATA REPORTING 7

3.1 RELIABILITY, SCHEDULED MAINTENANCE AND SERVICE BULLETIN

3.1.1 Data scope and format 7

3.1.3 Control file 9

3.2 WARRANTY CLAIMS 10

3.2.1 Data scope and format 10

3.2.3 Control file 11

7.1 FTS+ API DOCUMENTATION 14

7.2.1 Aircraft Hours and Landings - Required data and format 14

7.2.2 Aircraft Events - Required data and format 15

7.2.3 Technical Logbook - Required data and format 17

7.2.4 Component Removal – Required data and format 18

7.2.5 Engine Removal - Required data and format 20

7.2.6 APU Removal – Required data and format 21

7.2.8 Service Bulletin – Required data and format 24

7.2.9 Warranty Claims – Required data and format 25

1.1 IN-SERVICE DATA SHARING

1.2 FULL AUTOMATIC SOLUTION

2. SOLUTION OVERVIEW AND GENERIC REQUIREMENTS

The solution is based on an Airbus solution, named “FTS+”.

2.2 GENERIC REQUIREMENTS

2.2.1 Connection to FTS+

As such, these credentials information shall be customisable in your information system.

Information to connect to FTS+ for ISDS

In order to send files to FTS, two solutions are possible:

Path example: FTS-MIS-IF/AIB/xxx.xml

FTS+ Java API

FTPS standard protocol

2.2.3 Master flows & Administration module

2.2.4 Data control

3. IN-SERVICE DATA REPORTING

3.1.1 Data scope and format

The following Spec2000 versions are supported:

Spec2000 version identification

Empty period / No data

3.1.3 Control file

3.2.1 Data scope and format

The following Spec2000 versions are supported:

Therefore for one claim you can have up to three files:

3.2.3 Control file

Reference Author Document Name Revision

API Application Programming Interface

7.1 FTS+ API DOCUMENTATION

7.2 DETAILED DESCRIPTION

7.2.1 Aircraft Hours and Landings - Required data and format

7.2.2 Aircraft Events - Required data and format

Aircraft Events record is details operational Interruptions & technical Incidents.

7.2.4 Component Removal – Required data and format

It is used to report on LRU unscheduled removal (only serialized parts).

It is used to report on Engine scheduled and unscheduled removal.

7.2.6 APU Removal – Required data and format

It is used to report on APU scheduled and unscheduled removal.

7.2.8 Service Bulletin – Required data and format