Final Report

Transcription

1 Final Report COSP - CoSpace Experiments at the Scientific Research Facility of ZFB s A330 FFS - (P55) Project partners: EEC and TUB/ ILR Author: Dipl.-Ing. Thomas Pütz, Technische Universität Berlin / ILR Date: 31/05/05 Revision: 06/10/05

2 CONTENT CONTENT... 2 LIST OF FIGURES... 4 LIST OF TABLES... 4 REFERENCE DOCUMENTS INTRODUCTION CONTEXT, OBJECTIVES & PROJECT OVERVIEW GENERAL OBJECTIVES PROJECT OVERVIEW GENERAL RESPONSIBILITY ASSIGNMENT SYSTEM REQUIREMENTS GENERAL COCKPIT INTERFACE SYSTEM SPECIFICATION PRINCIPLES MOTIVATION PROCEDURES ASAS COCKPIT INTERFACE FUNCTIONAL REQUIREMENTS GENERAL ASAS COCKPIT INTERFACE OVERVIEW DISPLAY OF TRAFFIC TARGET IDENTIFICATION TARGET SELECTION TARGET POSITIONING TARGET CONFIRMATION SPACING INSTRUCTION SELECT APPLICATION ASSESS FEASIBILITY MONITOR SPACING SUGGESTED SPEED ADVISORIES AND MESSAGES END OF SPACING HMI REQUIREMENTS DESIGN PHILOSOPHY / COLOUR CODING ND INTERFACE TARGET SYMBOL AND ASAS LINK PREDICTIVE SPACING POSITION SYMBOL DESIGN OF SPACING SCALE DISPLAY OF SUGGESTED SPEED DISPLAY OF ADVISORIES AND MESSAGES MCDU INTERFACE TECHNICAL REALIZATION GENERAL ENVIRONMENT IMPLEMENTATION PLANNING (WP1) COMMENTS ON SPECIFICATION SOFTWARE CORE STRUCTURE ND COCKPIT DISPLAY OF TRAFFIC INFORMATION MCDU DIALOGUE ASAS CALCULATIONS GENERAL TRAFFIC POSITIONING AND POSITION EXTRAPOLATION DIRECT DISTANCE DISTANCE-BASED SPACING FOR REMAIN BEHIND PROJECTION ON THE FLIGHT PLAN CALCULATION OF CURVE PARAMETERS of 92

3 4.9.3 TIME-BASED SPACING FOR REMAIN BEHIND DISTANCE-BASED SPACING FOR MERGE BEHIND TIME BASED SPACING FOR MERGE BEHIND SPACING TREND AND CLOSURE RATE SUGGESTED SPEED CALCULATION AND TIME CONSTRAINT TOLERANCE MARGINS IN ACQUISITION TIME TO REACH SPACING AND PREDICTIVE SPACING SYMBOL TRAFFIC SIMULATION AUDIO EQUIPMENT EXPERIMENTAL DESIGN EXPERIMENTAL PLAN SIMULATION RUN PLAN SIMULATED ENVIRONMENT DATA COLLECTION RESULTS PROBLEMS DURING DEVELOPMENT GENERAL FEW SPARE TIME NUMBER OF OVERRUNS TIME SYNCHRONIZATION OF SIMULATION ENVIRONMENT TRAFFIC SIMULATION PRECISION OF SUGGESTED SPEED LIMITATIONS OF THE SOFTWARE FMS NEW VISUAL SYSTEM OTHER RESTRICTIONS DESIGN LIMITATIONS GENERAL PROJECTION POINTS DIFFERENCE TO TIME BASED SPACING OF EEC EXTRAPOLATION IN CURVE SEGMENTS COLOR CODING MOVEMENT OF THE PREDICTIVE SPACING SYMBOL TIME CONSTRAINT HEADING THEN MERGE ALTITUDE-DEPENDENT FLIGHT ENVELOPE EXPERIMENTAL RESULTS CONCLUSION / NEXT STEPS GENERAL COMPLETION OF HEADING THEN MERGE TOOL FOR MODIFYING THE FMS DATA BASE SUG IAS CALCULATION BASED ON LEAD HISTORY AUTOMATIC DISENGAGEMENT IN FINAL APPROACH ASAS AUTOMATIC GUIDANCE MANAGED SPEED MODE APPENDIX A: ENTRY QUESTIONNAIRE APPENDIX B: POST-RUN QUESTIONNAIRE APPENDIX C: FINAL QUESTIONNAIRE of 92

4 LIST OF FIGURES Figure 1 - Project Time Schedule [T. Pütz]... 9 Figure 2 - ASAS features on ND [EEC] Figure 3 - Spacing instructions [EEC] Figure 4 - Spacing applications Figure 5 - Merging procedure [EEC] Figure 6 - Spacing scale [EEC] Figure 7 - Interpretation of spacing scale indications [EEC] Figure 8 - Drifting situations [EEC] Figure 9 - Phases of spacing task [2] Figure 10 - Spacing task and navigation mode [2]...21 Figure 11 - Full flight simulator [ZFB/ILR] Figure 12 - Scientific Research Facility [ILR] Figure 13 - MCDU Flow Chart [T. Pütz] Figure 14 - Extrapolated position in curved segments [EEC] Figure 15 - Along Track Distance calculation [T. Pütz] Figure 16 - Simple Along Track Distance [2] Figure 17 - Turn Parameters [2] Figure 18 - Interpolation of target's position [EEC] Figure 19 - Merging Distance [EEC] Figure 20 - Time Constraint [EEC] Figure 21 - Instability Margin [EEC] Figure 22 - Track angle deviation [EEC] Figure 23 - Windows Simulation Interface [T. Pütz]...54 Figure 24 Setup of the audio equipment [T. Pütz]...55 Figure 25 Radio Management Panel [Airbus FCOM] Figure 26 IOS audio setting for recording [ILR] Figure 27 - Simulated airspace and trajectories [EEC] Figure 28 - Simulation cycles [CAE] Figure 29 - Simulation banding scheme tree [CAE] Figure 30 - Spacing jumps [EEC] Figure 31 - Speed conversion TUB and EEC [EEC] Figure 32 - Flight Envelope Limits with Ref. Speed 300 kts [T. Pütz] Figure 33 - Flight Envelope Limits with Ref. Speed 320 kts [T. Pütz] Figure 34 - Suggested, selected speed and CAS [T. Pütz] Figure 35 - Actual and required spacing [T. Pütz] LIST OF TABLES Table 1 Exchange Parameters Table 2 - Objectives, dimensions, metrics and measures related to flight deck analysis Table 3 - Participants age and experience distribution Table 4 - Run-plan Table 5 - Run description Table 6 - Major ATC-instructions Table 7 - Weather scenarios Table 8 - Data collection method and data attributes...64 Table 9 - used variables in data log Table 10 - states and associated message of COASASMSG Table 11 - correlation of pilot's action and ASAS-states of 92

5 REFERENCE DOCUMENTS [1] EUROCONTROL / FAA cooperative R&D, Principles of operations for the use of airborne separation assurance systems, Edition 7.1, 2001 [2] EUROCONTROL EEC, ASAS Spacing cockpit interface - User Requirement Document, Version: 1.3, June 2004 [3] EUROCONTROL EEC, CoSpace 2003 Flight Deck Experiment Assessing The Impact Of Spacing Instructions From Cruise To Final Approach, EEC Report No. 397 Volume I, November 2004 [4] EUROCONTROL EEC, User Manual for The Base of Aircraft Data (BADA), EEC Note No. 08/02, Revision 3.4, June of 92

6 1 INTRODUCTION This document is the final report of the collaboration project COSP of EEC (EURONTROL Experimental Centre) and Technische Universität Berlin (TUB). The purpose of this document is to describe the development and implementation of EUROCONTROL s ASAS Cockpit interface into the A330 Full Flight Simulator at the Institute of Aeronautics and Astronautics (ILR) of the TUB and to present the results and findings during the preparation and execution of CoSpace flight deck experiments at the Scientific Research Facility of ZFB s A330 FFS conducted in March It is not intended for a documentation of the deeper analysis of the experimental data and its appraisal. The CoSpace project is sponsored by the EEC in Paris-Brétigny, the CASCADE programme of the EUROCONTROL European Air Traffic Management (EATM) programme, and the European Commission (EC) Directorate General for Transport and Energy (DG-TREN) Trans-European Network for Transport (TEN-T) programme. The present experiment was made in collaboration with the EVP (European ATM Validation Platform) project from EC. COSP is a subproject of CoSpace and means CoSpace Experiments at the Scientific Research Facility of ZFB s A330 Full Flight Simulator. The planned duration had been 14 months. It was prolonged to 16 months. The performed experiments of COSP are part of a series of air and ground validation experiments of CoSpace aiming at investigating the use of spacing instructions for sequencing arrival flows. The trials intent lay in an extended validation of airborne spacing results of CoSpace. Performing larger experiments with professional airline pilots in a more realistic environment (A330 Full Flight Simulator) and with a larger number of test subjects was the key objective of EUROCONTROL s Experiments at the SRF. The document is organised as follows: Section 2: introduces the context, the objectives and gives a project overview; Section 3 describes the system specifications; Section 4 describes the technical realization; Section 5 describes the experimental design; Section 6 comprises alls aspects of data collection; Section 7 presents the problems, design deficiencies and general results; Section 8 summarises the main findings and the possible next steps. 6 of 92

7 2 CONTEXT, OBJECTIVES & PROJECT OVERVIEW 2.1 GENERAL CoSpace is a project of EUROCONTROL for development and enhancement of spacing tasks. The CoSpace principles can be classified as one variant of an ASAS application. The main idea is to increase the controller availability through a reorganisation of tasks between controller and flight crew. The operational concepts such as in the EATM (European Air Traffic Management) programme and the ATM (Air Traffic Management) Strategy for envisaged by EURO- CONTROL, the next phases of the ICAO (International Civil Aviation Organization) CNS/ATM concept as well as strategic elements of the National Airspace System Plan (NASP) of the FAA aim at enhancing the current ATM systems in order to cope with the predicted growth of traffic for the next decade. As such, traffic is expected to double by 2015 based on the traffic figures of According to forecasts prepared by the ICAO, total world airline scheduled passenger traffic in terms of passenger-kilometres is expected to grow at an average annual rate of 4.5% over the period 1999 to Therefore, measures to increase level of safety and capacity of air space are judged to be essential for future ATM. Improving ground systems alone might not be sufficient to achieve the required capacity and safety levels in aviation. Thus actions on the flight deck side have to be considered. Concepts like the reorganisation of spacing tasks between controller and flight crew, assuming that appropriate avionics are installed on board, promise to improve prevailing ATM systems. Systems for Airborne Separation Assistance (ASAS) are proposed to enhance the methods of air traffic management and to increase capacity and safety levels. The definition of ASAS is as follows: An aircraft system that enables the flight crew to maintain separation of their aircraft from one or more aircraft, and provides flight information concerning surrounding traffic. [1] There are four different classes of ASAS which are defined in the Action Plan 1 ( Principles of Operation for the Use of Airborne Separation Assurance Systems, PO-ASAS) of FAA and EUROCONTROL. CoSpace falls within the Airborne Spacing application category defined in PO-ASAS: These applications require the flight crews to achieve and maintain a given spacing with designated aircraft, as specified in a new ATC instruction. Although the flight crews are given new tasks, separation provision is still the controller s responsibility and applicable separation minima are unchanged. [1] 7 of 92

8 The increased controller availability could lead to improved safety, which in turn could enable better efficiency and capacity. In addition, it is expected that flight crews would gain in awareness and anticipation by taking an active part in traffic situation management. 2.2 OBJECTIVES The key objective of the project COSP presented here was to gain more insight on the impact of spacing instructions on the cockpit work of the flight crew under realistic conditions and to obtain flight data regarding spacing errors. The Scientific Research Facility (SRF) of the A330/A340 Full Flight Simulator (FFS) at the Institute of Aeronautics and Astronautics of the TUB is equipped with an appropriate environment for pilot experiments. The display development environment is one of the main features of the SRF. A control room with data, audio and video recording capabilities enables the experimental team to monitor, control and analyze the test procedure. Moreover, the SRF is embedded in the ATM Network of the ILR. A simulation of surrounding air traffic can be integrated in the network, so that complex ATM scenarios are possible. Therefore, the SRF fulfilled the specification requirements for CoSpace experiments. The trials aimed at an extended validation of airborne spacing results of CoSpace through a more realistic environment (A330 FFS) and larger number of test subjects. The CoSpace Experiments at the SRF fulfilled the key objective by performing larger experiments with 10 professional airline pilots (5 crews, each on 2 days). An elaborate data acquisition was carried out during the experiments to obtain informative evaluation results. The trial results should prove the benefits and limitations of spacing instructions under realistic conditions. The following outcomes were expected: Analyzing pilot s workload and pilot s activity (spacing task performance and compatibility with conventional flight tasks), Evaluation of pilot s acceptance of spacing instructions, Getting realistic values for spacing errors (spacing accuracy and flight efficiency), Examination of operational problems under the aspect of safety. For this reason technical modifications and implementation work at the SRF was required to enable these pilot experiments. The key element of the trial preparation was the implementation of the ASAS Spacing cockpit interface. Furthermore, the second major technical measure was to prepare complex traffic scenarios for the ATM network of the ILR. 8 of 92

9 2.3 PROJECT OVERVIEW The project has been divided into 7 work packages (See Figure 1). The content of WP0 was the proper project management and the coordination of all parties. WP1 to WP3 represent the phase for specification, development, implementation and testing. WP4 to WP7 was foreseen as second phase for preparing, conducting and evaluating the experiments with professional airline pilots as trial participants. The completion of WP1 to WP3 had to be accomplished for starting the second phase. A formal acceptance of all partners was necessary to start the second phase and to plan and confirm the full flight simulator sessions. The work packages contained the following: WP 0: Project Management (14 months, duration of the project + 2 delay), WP 1: Consideration and definition of all steps of integration of CoSpace into the SRF A330 FFS (2 months), WP 2: Software Development of EFIS and FMS features (6 months + 6 delay), WP 3: Specification of the dynamic traffic generation, definition of the final ATM scenario and recording parameters (6 months + 3 delay), WP 4: Preparation of briefing materials and questionnaires (2 months), WP 5: Final Implementation of enhanced software and dress rehearsal with full equipment (2 months), WP 6: Preparation and execution of experiments with professional airline pilots (2 months), WP 7: Evaluation of the experiments and composing of the final report (3 months). Workpackage Management WP 0 Definition WP 1 Implementation WP 2 Scenario WP 3 Questionnaires WP 4 "dress rehearsal" WP 5 Experiments WP 6 Evaluation WP 7 Year/ Month oct nov dec jan feb mar apr may jun jul aug sep oct nov dec jan Figure 1 - Project Time Schedule [T. Pütz] feb 2005 mar apr may jun 9 of 92

10 The time table shows several revisions for the period of each work package. Several limitations of the simulator, the tight time schedule and detailed coding problems of the algorithms forced the team to postpone the trials from November 2004 to March In summary the main technical obstacles lay in the following fields. Detailed information will be given in chapter 7: The existing traffic simulation software GATS (Generic Air Traffic Simulation) by ILR/ TUB had not met the specification of the project. The introduction of new software with higher precision and variable update rate was necessary. Simulation overruns due to insufficient spare time for the extensive calculations of CoSpace ASAS. Time Reference System could not be used as a stable time reference for ASAS. Synchronisation with external processes over network caused calculation failures. In some cases the Software FMS as data source for ASAS did not deliver reliable information. Modification of the navigation data base was not possible. The software FMS has to handle new waypoints which caused additional functional problems. All lateral revisions sometimes had impact on the stability and the reliability of the Software FMS. The introduction of a new visual system caused scenario configuration problems. 2.4 GENERAL RESPONSIBILITY ASSIGNMENT The general distribution of responsibilities between EEC and ILR had been allocated as follows: EUROCONTROL/ EEC and TUB/ ILR were the project partners. EEC was responsible for the specifications and validation of the ASAS Spacing cockpit interface and of the simulation environment. EEC was also responsible for validation objectives and has to provide ILR with all necessary information. ILR was responsible for implementation and necessary adaptations to the FFS environment. ILR s development had to meet EEC s requirements, so that a reliable and efficient system on the basis of the existing simulation environment of the ILR (SRF A330 FFS) was provided for the conducted experiments. Comments and proposals from ILR were also expected during the whole project due to the expertise in FFS research and on the A330 aircraft. 10 of 92

11 2.5 SYSTEM REQUIREMENTS GENERAL The system requirements were gathered in the User Requirement Document (URD) [2] for the ASAS Spacing cockpit interface. The following aspects were considered: The ASAS Spacing interface respected the functional requirements and the HMI requirements (Human-Machine Interface) described in the URD. The system was compatible with the Distributed Interactive Simulation (DIS) format in order to be integrated with other traffic. The DIS format is detailed in the annex of the URD (URD ANNEXE 4: MCS INTERFACE SPECIFICATIONS). This requirement was revised during the project due to the already mentioned deficiencies of the existing system GATS. The system enabled the recording of defined flight and ASAS parameters (see URD ANNEXE 3: SYSTEM RECORDINGS). Later the document Flight deck data logs specification completed this requirement. It was possible to modify the defined user parameters for ASAS in a flexible way. An initialisation file shall was used. Overall performance of the ASAS interface did not modify or slow down the management of the flight parameters and of the standard cockpit interface on the simulator in a perceptible manner. The cockpit simulator provided a radio communication facility to and from the crew. The possibility existed to replay and mute when necessary the recorded audio files COCKPIT INTERFACE The cockpit simulator must contain all the following standard elements: PFD, ND and MCDU for each pilot, FCU, ECAM, landing gear and pedestal with throttle, flaps, speed brakes and navigation respectively communication panels. An external view is optional. (URD) [2] The A330/ 340 Full Flight Simulator is equipped with all elements given before. The simulator is a JAR certified Level D FFS. A complete EIS (Electronic Instruments System) with ECAM and EFIS, the FMS (Flight Management System) including all MCDU s and the FGES (Flight Guidance and Envelope System) with FCU (Flight Control Unit) of an Airbus A330, a motion system with 6 degrees of freedom (6 DOF), all RMP s (Radio Management Panel) for tuning the communication frequencies, all necessary primary and secondary controls of the aircraft and finally a Wide Visual system (EP1000CT) for an external view. 11 of 92

12 The reference aircraft for the simulator (each simulator is modelled on one real existing aircraft) is the LTU A (D-AERF) with the manufacturer serial number (MSN) 82. In addition to these standard elements, new features (denoted ASAS) are needed to support the spacing task. These features are: new MCDU pages for data input, and new graphical indications on the ND to visualise the target and allow the pilot to perform the necessary speed adjustments. On the ND, the ASAS features are (Figure 2): (URD) [2] Target aircraft symbol, Reference line between own ship and target, Predicted spacing, Spacing scale, Suggested airspeed and Pilot prompts. All these features were precisely described by the URD. They are identical in distance and time based spacing (except for the units). In this phase of the project it was only foreseen to let the pilot do the necessary speed adjustments through the FCU, any automatic or managed guidance functions was not planned. Figure 2 - ASAS features on ND [EEC] 12 of 92

13 3 SYSTEM SPECIFICATION 3.1 PRINCIPLES MOTIVATION A new allocation of spacing tasks between controller and flight crew is envisaged as one possible option to improve air traffic management and in particular the sequencing of arrival flows. It relies on a set of new spacing instructions where the flight crew can be tasked by the controller to maintain a given spacing (in time or in distance) with respect to a designated aircraft. This task allocation, denoted airborne spacing, is expected to increase controller availability. This could lead to improve safety, which in turn could enable better quality of service and, depending on airspace constraints, more capacity. In addition, it is expected that flight crew would gain in awareness and anticipation by taking an active part in the management of their situation with respect to a designated aircraft. The motivation is neither to transfer problems nor to give more freedom to flight crew, but really to identify a more effective task distribution beneficial to all parties without modifying responsibility for separation provision. Airborne spacing assumes airborne surveillance (ADS-B) along with cockpit automation (Airborne Separation Assistance System, ASAS). No significant change on ground systems is initially required. [3] PROCEDURES The controller is provided with a set of new instructions for sequencing purposes. (Figure 3) Figure 3 - Spacing instructions [EEC] 13 of 92

14 Airborne spacing is composed of three phases: Identification phase, in which the controller designates the target aircraft to the flight crew and the pilots identify the target with ASAS. Spacing instruction, in which the controller specifies the task to be performed by the crew. End of airborne spacing, which marks the completion of the task. From the flight crew perspective, the identification phase consists in selecting a preceding aircraft (the target). Then, through the new spacing instructions, pilots are tasked to acquire and maintain a given spacing with respect to the target until controllers cancel the spacing instruction. Finally, to end airborne spacing pilots deselect the target. As for any standard instruction, the use of spacing instructions is at the controller s initiative, who can decide to end its execution at any time. The flight crew however can only abort it in case of a problem onboard, such as a technical failure. In terms of responsibility, as opposed to visual separation, there is no transfer of separation responsibility. Four spacing instructions for sequencing are proposed in Figure 4. [3] Figure 4 - Spacing applications With these four types of spacing the controller is enabled to build up a chain of aircraft following the same route to the airport, the so called arrival stream. In the arrival stream all aircraft have the same trajectory. With using ASAS a desired spacing in time or distance will be maintained. In this case the controller has to instruct the Remain Behind or Heading then remain behind task. Aircraft with different trajectories have to be converged at a specific point. By using the Merge behind (See Figure 5) and the Heading then merge behind the controller is enabled to do this. In today s situation the controller has to guide the aircraft to the final approach ensuring spacing respectively separation at the same time. He continuously has to monitor the situation. In order to control the arriving traffic, the controller can use heading and speed instructions. 14 of 92

15 With the spacing task, the maintaining of the spacing is transferred to the flight deck. The spacing can be achieved through speed adjustments by the pilot. The controller must ensure that aircraft speeds are compatible. Controller and pilot have to estimate the feasibility of the spacing procedure. The spacing instruction is typically issued before descent. The spacing task is independent of visibility conditions but applicability conditions have to be respected. Figure 5 - Merging procedure [EEC] ASAS COCKPIT INTERFACE In order to comply the spacing instructions there are additional cockpit interface features to support the pilot. These HMI are new ND and MCDU features. The ND contains several display clues: Target aircraft symbol, reference line between own ship and target, predicted spacing, spacing scale, suggested airspeed and pilots prompts. Figure 6 - Spacing scale [EEC] The display of traffic information is one key feature of the ASAS cockpit interface. It is able to show the surrounding traffic, but at this stage it was only planned to show the selected target. 15 of 92

16 TCAS information is an overlay except for the target aircraft symbol. After the instruction of the controller, the crew selects the designated aircraft by entering of a unique identifier (SSR code) into the system. The target symbol indicates position, track, relative altitude and the vertical trend. To help the pilot to recognize and to identify the target, a reference line connects the own aircraft with the target. It is a phase depending coloured dashed double line. In a running spacing the reference also indicates the merging waypoint if selected and the type of the spacing measurement (direct connection, along track distance). On the left side of the ND you can find the Spacing Scale. This scale is used by the crew for a target/actual value comparison of the spacing. A magenta spacing bug indicates the required spacing. If the spacing bug is outside the scale, then it is displayed above or below the scale. The yellow reference line and the spacing value in numbers show the actual value. The upper part of the scale is used for the lower spacing values and moving into the lower part of the displays means increasing the spacing. A green arrow graphically represents the spacing trend. The trend is the projected spacing after a certain time. It shows the closure rate of own aircraft upon the target. The trend is pointing downwards if own aircraft goes slower than the target and upwards if it goes faster. The spacing scale has got upper and lower tolerance margin which inform the crew about the desired spacing range (e.g. +/-0.5 NM for distance based spacing and +/-5 seconds for time based spacing). Leaving this area triggers the necessary indications. There are two tolerance zones for each direction. A caution zone represented by amber rectangles indicates the pilot to take action. The warning tolerance margin represented by filled red rectangles triggers the warning situation if it is reached. Figure 7 below shows the interpretation of different spacing conditions. The spacing scale is only displayed during active spacing. In all other phases of a spacing task, it is hided on the ND. Figure 7 - Interpretation of spacing scale indications [EEC] 16 of 92

17 The ASAS Cockpit Interface supports the pilot with the display of a suggested speed in order to simplify the selection of an appropriate speed. The suggested speed shall be displayed on the ND in the centre, at the bottom, under the aircraft symbol and above the line used for messages. Flashing of the suggested IAS is used to advise the crew of a drifting situation. The display of advisories and messages improves the situation awareness and triggers necessary immediate corrective action of the pilots. Messages are displayed on the ND and the MCDU at the same time. On ND they are located at the bottom centre. On the MCDU the scratchpad is used. Advisory messages are presented in white colour, caution messages are displayed in amber and a warning message is showed in amber and is boxed on the ND. (See Figure 8) Figure 8 - Drifting situations [EEC] Predictive Spacing Position Symbol improves look-ahead estimation of the spacing situation. The crew can identify the position on the flight plan where the spacing will be acquired. The symbol is a broken arrow with an arc. It is only displayed during certain phases of the spacing task ( assess feasibility and acquire spacing ). If the Predictive Spacing symbol is positioned beyond the merging waypoint in a merge or heading then merge application, the symbol is displayed in amber with an shifted arc at the point of conjunction of the trajectories. In remain there is a pre-defined time constraint to acquire spacing. If the time to reach the desired spacing is greater than the time constraint, the beyond symbol is displayed instead of the normal predictive spacing symbol. This condition is triggered also for exceeding the final approach fix of the arrival airport with this predicted position. 17 of 92

18 3.2 FUNCTIONAL REQUIREMENTS GENERAL All following requirements are mentioned in the User Requirement Document [2] ASAS COCKPIT INTERFACE OVERVIEW As previously described, the spacing task is divided into three main steps: Target identification, Spacing instruction, End of spacing. Three different spacing tasks are proposed but only two of them have been realized in the first phase of the project (the according simulation parameter is presented in brackets): No task (cospcmode = 0) Remain (cospcmode = 1) Merge (cospcmode = 2) Heading then Merge (cospcmode = 3) not implemented yet! The system follows a logic visualized in the diagram phases of spacing task. Each spacing task is divided in several phases correlating to the required or performed tasks by the crew. These phases are (See Figure 9): Nothing (cophase = 0) Identify target (cophase = 1) Assess feasibility (cophase = 3) Acquire spacing (cophase = 4) Stabilise spacing (cophase = 5) Maintain spacing (cophase = 5) Caution (cofaillevl = 1 or coreflcol = 2) Warning (cofaillevl = 2 or coreflcol = 3) The phase is primarily identified by the input of the crew into the MCDU. One exception is the switching from acquire to stabilise. It is triggered by the spacing error fulfilling a certain condition: The difference between the current spacing and its required value is equivalent to the distance (or time) necessary to accelerate/decelerate from current closure rate. A further 18 of 92

19 exception is the Maintain spacing phase. It corresponds to a situation where the spacing is achieved with the required precision and the spacing evolution is stabilised. Figure 9 - Phases of spacing task [2] 19 of 92

20 3.2.3 DISPLAY OF TRAFFIC For display realism purposes, the system shall display surrounding traffic: The system shall display the surrounding traffic on the Navigation Display (ND) with a simplified or full TCAS logic. The movement of traffic on the navigation display shall be smooth. The display and positioning of the traffic shall be consistent with the ND display mode and range selected. The display should be consistent with the TCAS mode selected (THRT, ALL, ABOVE, BELOW) if such a mode exists TARGET IDENTIFICATION When instructed by the controller, the crew shall be capable of selecting a designated aircraft as target for ASAS instruction: The system shall provide a means to select a target aircraft designated by a unique identifier (SSR code). Once a target has been selected, the system shall provide the necessary information for the crew to position the target. Once positioning of the target has been confirmed by the controller, the pilot shall be able to positively confirm the target selection in the system TARGET SELECTION The pilot shall be able to select a SSR code on the MCDU and eventually modify his entry. A message Format error shall be displayed if the entry is incorrect. The SSR code is a four digit field; entries with 1, 2, 3 or 4 digits are allowed. A message Invalid SSR code shall be displayed if: o there is no corresponding aircraft with this SSR code in the traffic list, or o the target aircraft is outside of the defined ADS-B range (user parameter, e.g. 120NM) TARGET POSITIONING Once a valid SSR code has been selected: Information on the target shall be displayed on the MCDU: SSR code, call-sign, Ground Speed, distance, altitude and vertical speed). 20 of 92

21 Information to identify (SSR code) and position the target in bearing, distance and altitude shall be displayed on the ND. The target symbol shall be distinct from TCAS symbolism TARGET CONFIRMATION In order to make sure that a positive identification has been made: It shall be necessary to confirm the target selection before being able to access the spacing instructions. Before confirmation of the target selection, it shall be possible to modify the SSR code SPACING INSTRUCTION The spacing can be performed in Distance-based or Time-based ; this shall be a user parameter. Once given a spacing instruction by the controller, the crew shall: Select the desired spacing application, Assess feasibility. The spacing application will become active after being confirmed by the crew and the system shall provide: A scale to monitor the spacing value, A suggested speed for guidance, Advisories and messages to warn crew of drifting situations SELECT APPLICATION The system shall allow the crew to choose from one of the four spacing applications. It should give a choice between REMAIN and MERGE to the flight crew. The system should figure out the application from the choice made and the active lateral navigation mode as described below (Figure 10): Figure 10 - Spacing task and navigation mode [2] 21 of 92

22 The system shall require from the crew the information relevant to the spacing application: Remain behind: required spacing in NM (1 99) for distance-based spacing or in seconds (1 300) for time-based spacing. It shall be entered by the crew. Merge behind: o Required spacing in NM or seconds. It shall be entered by the crew. o Merging waypoint. It should take the value of next waypoint and should be confirmed by the crew. Heading then Merge behind: o o Required spacing in NM or seconds. It shall be entered by the crew. Merging waypoint. It shall be entered by the crew. For all applications: The crew should be able to enter xx as required spacing value to be exactly xx behind or to enter +xx to be at least xx behind. The system shall display a Format error message and shall allow a new entry if the entry is not compatible with the field. The system shall display Invalid waypoint if the merging waypoint entered does not exist in the database ASSESS FEASIBILITY Once the information relevant to the spacing application has been entered by the crew: Information shall be displayed for the crew to assess feasibility: o o Current spacing and required spacing value, Suggested speed, o Time to reach spacing with suggested speed and with current speed ( Remain behind and Merge behind ), o Time before resuming towards merging waypoint ( Heading then Merge behind ), o o Time before resuming heading ( Heading then Remain behind ), Predicted geographical position of where spacing will be reached. 22 of 92

23 An advisory ASAS Unable spacing message shall be displayed in white if the suggested speed is outside of the flight envelope (for remain behind and merge behind ). An advisory (white) or caution (amber) ASAS Direct to xxxxx message shall be displayed if current spacing is greater than the required spacing. The system shall invite the crew to confirm acceptance and activate the spacing task MONITOR SPACING The information present on the ND shall be sufficient for the crew to monitor the spacing task: The spacing scale shall represent the value and the trend (at x seconds) of the current spacing with regards to the required spacing; The movement of the spacing trend should be smoothed out to avoid flickering; The display of the spacing trend shall be filtered for low values; The range of the spacing scale shall be independent of the range of the ND; The spacing scale should be centred on the current spacing value; Lower spacing values should be at the top of the spacing scale and higher values at the bottom; The caution and warning zones shall be materialised on the scale (in amber and red). Complementary information on the target and the spacing task is displayed on the ASAS page of the MCDU: SSR code, call sign, ground speed (GS), time to reach spacing with suggested speed and with current speed as well as the current spacing, the required spacing and the suggested speed SUGGESTED SPEED A suggested speed is provided as guidance to perform the spacing task: The suggested speed shall respect the rules of the ASAS application: o For merging applications, the spacing shall be reached at the merging waypoint (after which both aircraft share the same trajectory), o For remain behind applications, the spacing should be reached within a given acquisition time (user parameter e.g. 5 min). This generates a time constraint to achieve spacing which decreases as a timer down to the recovery time value. 23 of 92

24 o once acquired, the spacing should be recovered within a given recovery time (user parameter e.g. 2 min) The suggested speed shall be indicated in IAS and/or in Mach in cruise; The system shall indicate if the suggested speed is outside of the flight envelope; The update of the suggested speed should be as smooth as possible ADVISORIES AND MESSAGES Advisories and messages are designed so that: Advisories should prevent situation from drifting; In caution, crews should react immediately to recover situation; In warning, crews should report to the controller. For remain behind and merge behind applications: The system shall generate advisories if the difference between own aircraft speed and suggested speed (before filtering) exceeds given values: o The header of the suggested speed ( SUG_IAS ) should start blinking on the ND if the difference is above a first threshold (user parameter e.g. 7 kts); o An advisory message ASAS ACCELERATE or ASAS SLOW DOWN should be displayed if the difference is above a second threshold (user parameter e.g. 15 kts); A caution message ASAS ACCELERATE or ASAS SLOW DOWN shall be displayed when the difference between current spacing and required spacing becomes greater than the caution tolerance (user parameter). A warning message ASAS UNABLE SPACING shall be displayed when the difference between current spacing and required spacing becomes greater than the warning tolerance (user parameter). For all applications it should be regarded that: Caution and warning messages should override advisory messages. Caution and warning messages shall be accompanied by an aural alert. Aural alerts should be explicit and should not consist of a simple sound. (No aural alerts were implemented in this project phase!) 24 of 92

25 END OF SPACING The system shall enable to end the spacing task at any time. The target will remain selected. Once the spacing task has been ended, it shall be possible to: o o o Confirm the end of spacing task and deselect the target; Select a new spacing task with the same target; Return to the spacing application previously selected. If no information is received from the target for more than a given stale time (user parameter), the system shall automatically end the spacing application, deselect the target and display the message Target 1234 lost (1234 being the SSR code of the target). 25 of 92

26 3.3 HMI REQUIREMENTS DESIGN PHILOSOPHY / COLOUR CODING The ASAS interface should be consistent with Airbus design philosophy as much as possible. The display logic and the colouring shall adhere to the specifications in the URD ND INTERFACE No graphical elements shall overlap beyond the selected ND range. The additional symbols and elements shall adhere to the current mode and range of the EFIS control panel TARGET SYMBOL AND ASAS LINK The target symbol has to be displayed as a white triangle with information of track, relative altitude and trend. The ND position of the target is determined by its geographical position. The direction of which is correlates to the track/ heading of the target. The data tag on the right side gives information about the flight attitude. The parameters are the relative altitude in hundreds of feet and the tendency of the vertical speed represented by a vertical arrow pointing up/down for a target climbing/descending with a vertical speed greater than 500 ft/min. The reference line links own aircraft s position with target s position for illustration purpose of the spacing application. It is realized with a double dashed line with a phase depending colouring. The geometry of the link depends on the ASAS application: It runs direct from own aircraft to target when no application is selected; In case of Remain behind, it runs alongside the trajectory; In case of Merge behind, it runs from own aircraft to the merging waypoint and from the merging waypoint to the target alongside the trajectory. The target and the reference line and data tag shall be displayed in Stabilise and Maintain phase: In red in case of warning, In amber in case of caution, Or else in white. In acquisition phase only the reference line is displayed in cyan all time, the target itself remains White. 26 of 92

27 3.3.4 PREDICTIVE SPACING POSITION SYMBOL The Predictive Spacing Symbol is only presented during the assess feasibility and acquire spacing phase It is not displayed in the cases described below: The time to spacing is greater than the time to the merging waypoint minus an anticipation parameter. The time to spacing is greater than the time constraint to acquire spacing. Again the symbol turns to amber and changes its shape. The predictive spacing would be beyond the final approach fix of the arrival airport. Also here the amber variant. When it is not possible to compute the time to reach spacing, nothing is displayed for the time being. The movement of the predicted spacing is very sensitive to any change of parameters. A filtering is necessary DESIGN OF SPACING SCALE The spacing scale is the main indication for the actual spacing situation. It is located on the left side of the navigation display. Additional display clues help the pilot to estimate the situation and plan his activities: The spacing scale is only presented in acquire, stabilise and maintain phase. The actual spacing is centred at the yellow reference marking. Lower spacing values are at the top of the scale and higher spacing values at the bottom. The scale is displayed in the same units as the required spacing entered on the MCDU. (e.g. +/-0.5 NM for distance based spacing and +/-5 seconds for time based spacing). The range of the scale should be limited to values between half of the caution tolerance and the caution tolerance, so that the margin area is not visible if the spacing is correct. A small tolerance margin should be added. The actual value is also displayed as a numerical value in white to the left of the reference marking. The required spacing is a magenta spacing bug fixed on the moveable spacing scale. Whenever the bug is out of range the textual value is displayed either on the top or at the bottom of the scale. 27 of 92

28 A green arrow pointing up or down with a specific length depending on the closure rate of the own ship towards the target represents the spacing trend. For the accomplished experiments it showed the spacing that would be acquired in 60 seconds. The caution tolerance margins are located as an amber band in the upper and lower spacing area of the tolerance. The warning tolerance is also presented like this but as a red band DISPLAY OF SUGGESTED SPEED The suggested speed is displayed on the ND in the centre, at the bottom, under the own aircraft symbol and above the line used for messages. The designation SUG IAS is displayed in white. This text element has a blinking function. It is used to advise the crew of a drifting situation. The rate of blinking should be of approximately half a second on and half a second off (one second for a full blinking cycle). The speed value itself is displayed in green except for suggestions outside the flight envelope. If the speed could be reached with another flap setting it is presented in amber or else in red. The suggested speed is calculated, filtered and rounded respecting a speed margin of 5 kts. Then the value is send to the ND DISPLAY OF ADVISORIES AND MESSAGES Messages shall be displayed both on the ND and the MCDU; at the bottom centre of the ND and on the scratchpad of the MCDU: Advisory messages should be in white, Caution messages should be in amber, Warning messages should be in amber and should be boxed on the ND MCDU INTERFACE The MCDU is used by the crew to input the parameters of target selection and ASAS applications, such as the SSR code, the required spacing value (for Remain and Merge behind applications) and the merging waypoint (for Merge behind applications). The following general display rules apply to the data: The data field labels are in white, with a small font; Modifiable data is displayed in cyan (besides a corresponding LSK); 28 of 92

29 Non-modifiable data is displayed in green; Active constraints are displayed in magenta; Missed constraints are displayed in amber; Large font is used when the data is entered by the pilot and small font is used when the data is generated by the system; Amber box prompts are used to indicate that a specific data entry is necessary for the ASAS application; The CLR key on the MCDU shall be used to clear ASAS messages on both the MCDU and the ND. Pilot entered data (data is entered in the scratchpad): No value entered: o o Compulsory information: The data field consists of amber boxes Non-compulsory information: A bracket prompt is displayed Value entered (Large font): o o Modifiable data: Appears in cyan Non-modifiable data: Is presented in green System generated data: Computable data: It appears in small font Non-computable data: Dashes appear in the data field 29 of 92

30 4 TECHNICAL REALIZATION 4.1 GENERAL This chapter describes the steps of development and explains, besides the environment, the main ideas and principles of the ASAS cockpit interface. It should not to be regarded as a detailed description of all software features. 4.2 ENVIRONMENT The ZFB Full Flight Simulator is JAR certified motion simulator level D with a modern visual system. The FFS is equipped with original hardware of the simulated aircraft. The hardware is integrated in the simulation process, so called Hardware-in-the-loop. The simulator provides two possible aircraft configurations, A340 and A330. The FFS can be converted shortly from one configuration to another. Figure 11 - Full flight simulator [ZFB/ILR] The flight characteristics correspond to an existing reference aircraft. For the performed experiments it was the following aircraft which is also in service: Aircraft type: A Engine: PW 4168 Registration: D-AERF Operator: LTU Serial number: of 92

31 The simulation is running on a host computer which is processing all the aerodynamic and flight mechanical parameters, the engine and all systems which are not integrated as hardware. The interfacing to the original hardware is also done by the host connected via Ethernet to the DMC-Interfaces (DATAPATH-C Micro-Computer). Furthermore, all necessary information for the motion system, the control loading system, the audio and the visual system is generated. The host itself is an IBM RS 6000 Model 580. Two identical host computers allow the training and research operation mode of the facility. A switching of the network enables this feature (See Figure 12). Figure 12 - Scientific Research Facility [ILR] The flight deck provides two touch-screen displays with a graphical user interface based on TIGERS TM. They are driven by two IBM 320H computers. Together it is called Instructor Operating Station (IOS). The IOS allows the instructor to operate, control and monitor the simulation. In the preparation phase of the CoSpace experiments a new visual system was implemented. The visual system now is an Evans & Sutherland EP-1000CT. It provides a highresolution, textured backdrop to a worldwide 3D training environment. It meets the requirements of FAA/JAA Level D flight training. The displayed picture is produced by three WIDE Visual Projectors. Next-generation weather effects improve the realism. A library of 3D airplanes enables the visibility of a target aircraft and the feeling to move in a real traffic sce- 31 of 92

32 nario. Calligraphic point lights and low-visibility runway lighting effects complete the visual impression. The motion system is a hydraulically operated platform with 6 degrees of freedom. It realizes the rotatory and translatory movement of the simulated aircraft. In addition, a control loading system gives dynamic force feedback to the pilot depending on actual control force. This is only the case for rudder, nose wheel steering and horizontal stabilizer trim. The main components of the simulator are: Host Computer (x 2), IBM RS 6000 Model 580, Instructor Computer (x 2), IBM 320H, Visual Computer, E&S EP-1000CT Motion System, CAE Series 500, 6 DOF (Degrees of Freedom), digital, Control Loading System, CAE, digital, Cockpit with visual system (Visual System WIDE, 3 Projectors), Original avionic, connected with DMC-Interfaces (2 x FMGEC, 3 x FCPC, 2 x FCSC, 2 x FCDC, 2 x DMC, GPWS, CMC, ACARS, FWC, TCAS). The simulation host is connected over Ethernet to the other network components. The original hardware adheres to the ARINC standard (ARINC 429). DMC-Interfaces enable the communications transfer between Ethernet and ARINC. The host computer of the Scientific Research Facility SRF offers different programmers interfaces in the domains display development, flight management and flight control and guidance. For this purpose the functionality of the original hardware is substituted by software modules which are extendable and modifiable. In order to ensure a comparatively fast development process the SRF supports a standalone operation mode without cockpit, original hardware, motion, visual and control loading. The time from start of the software loading until the final flight preparation full flight mode is much longer in stand-alone mode. This expedites the testing and debugging of the modified software. The following aircraft systems are completely available as software modules: Electronic Flight Instrument System and Display Management Computers (EFIS/ DMC), Flight Management System (FMS), Flight Guidance and Envelope System (FGES) including Autopilot and Autothrust. 32 of 92

33 Moreover, one SRF feature is The Interactive Graphics Environment for Real-time Systems (TIGERS TM ) of CAE Ltd. Canada. It is designed for graphical user interfaces for simulations of any kind. TIGERS TM is used for the IOS of the FFS and also for new display pages of the display units in the cockpit. The pages can be displayed on special designed CRTs (Cathode Ray Tube) and also on RGB displays outside the cockpit by using the High Resolution Graphic Controllers (HRGC). For stand-alone development it is possible to use the TIGERS Window Manager (TWM) displayable on any X-Windows system by exporting the page display to the desired work station. The SRF provides audio and video recording capabilities. In addition the Data Gathering Utility (DGU) can record data of pre-selected flight parameters (See chapter 6 DATA COLLEC- TION). All information can be time-stamped. The time stamp is generated by the time reference system IRIG-B. In summary the SRF comprises the following: Host Computer (HOST, research computer) (x 1), IBM RS 6000 Model 580, Instructor Computer (IOS) (x 1), IBM 320H, Test Bench (K1 Cabinet, test bench for avionics), IRIG-B (Time Reference System), Audio- and Video recording equipment, Work station for display development (21 Touch screen for TIGERS TWM and IOS), RGB-displays (x 2, for HRGC), ASCII - terminals (x 3), Ethernet Interface. 33 of 92

34 4.3 IMPLEMENTATION PLANNING (WP1) Objective of work package 1 was the planning of the development and the planning of the preparation of the flight trials. Content of the first work package was to collect, define and structure the software modification measures in order to establish a stable simulation platform for flight trials to investigate the aspects of spacing instructions. At the beginning all elements had to be assigned to a software and hardware platform: The proposal had foreseen these main work items: Collecting specifications and algorithms, Definition of the necessary interfaces and exchange parameters, Seeking out all implementation methods, Checking the feasibility of integration in the systems of the SRF/ FFS. Detailed planning of the technical steps of integration, As a prerequisite for the first work package only the specification of ASAS Spacing cockpit interface (User Requirement Document) was required. The outcome of this work package has been several deliverables summarized in one document ( Impact analysis and development planning ). The document consists of the impact and feasibility analysis, comments on the detailed specifications of EEC and a development planning including milestones at which software modules can be tested independently. Also a first step for development was the creation of a simulator software configuration for research and development at the SRF. The configuration uses the same modules like the trainings configuration for the professional airline pilot training. In addition, all necessary simulator files for ASAS development and traffic simulation had to be compiled, linked and added to the simulator configuration. Display development, Software FMS and traffic are no trainings features. Moreover, the adaptation of the software environment and the preparation of the traffic simulation were necessary. For implementation reasons several certain measures had been planned. Means to realize the ASAS cockpit interface at the SRF are the modification of the software FMS and the software part of the MCDU, the EFIS modification respectively the flight plan overlay on the ND, the implementation of logic and algorithms and the coupling to a traffic simulation. With the modification of software FMS/MCDU the integration of all menu pages, the implementation of the user dialogue on each page and the definition and insertion of an output interface was required. 34 of 92

35 In order to display the ASAS symbols the EFIS modules needed modification. All necessary CDTI symbols had to be defined in the navigation display modules. At the same time the interface for the transfer of symbol attributes had to be created or modified. Regarding logic and algorithms, the computation methods of navigation and spacing instruction parameters had to be identified, designed and tested and also the display logic had to be developed. For this reason, special functions to the according simulation module like the calculation of the Along Track Distance had to be added. Traffic Simulation/ DIS environment work comprised in the first approach the adaptation of DIS based traffic simulation software to the requirements of CoSpace, the ensuring of a sufficient update rate, the modification of the existing update rate of the displays for a smooth display of traffic movement, the recording of all significant traffic data and also the possibility to replay recorded VHF Radio Telephony which is synchronized to the traffic information on the ND. The GATS, first variant of traffic generation, had important restrictions. No curve segments could be calculated, and no dynamic effects like acceleration/ deceleration, configuration change or weather could be simulated and no realistic aircraft performance could be reproduced. With slight modifications it was possible to replay recorded data. In the course of the project it turned out that the traffic simulation was not able to generate more than 3 or 4 aircraft without having greater impact on the processing spare time. The only solution was a greater revision of the whole concept. A new traffic tool had to be developed and adapted to the requirements of CoSpace. This is described in chapter 4.10 (TRAFFIC SIMULATION). In terms of identification of hardware improvements or additional equipment there was nothing identified at the beginning. During the first scenario preparation it also turned out that additional audio equipment was necessary for a synchronized audio scenario. For the first steps of implementation it was essential to get an overview of the software structure. Therefore, it was useful to create flow charts for certain aspects like the MCDU dialogue. Also the preparation of a table for all used symbols with the according attributes supported the integration of ASAS elements. In particular a set of parameters/ variables for interfacing was defined and revised several times. The interfacing was essential for the distributed simulation environment and also for the data recording. All parameters had to meet exactly the experimental objective. 35 of 92

36 4.4 COMMENTS ON SPECIFICATION Several minor problems and restrictions occurred after provision and analysis of the specification document. Some of them are presented here. The MCDU page MCDU MENU could not be modified. It was proposed to use the Spare Button as the entry point for ASAS. Therefore, a small ASAS sticker was fixed on the spare button to indicate the ASAS functionality during the experiments. The reference line should be displayed as a double dashed line. Two methods to create double dashed lines were offered by the system: o The first method draws to separate lines. This requires the transformation of the offset position from rectangular coordinates to a geographical position in order to correct the coordinates of the flight plan line segment. There was no opportunity to draw flight plan overlay symbols with screen coordinates on the navigation display because of the architecture of the SRF display modules. The software modules and the research hardware had been designed very closely to the Display Management Computer (DMC) and Cathode Ray Tubes (CRT) of the original Airbus cockpit. o In order to get a double line effect you can draw a thick line and overwrite it with a slightly smaller black line. As a result you get two perfect parallel lines. Line thickness and line pattern could be modified in the display system of the SRF. The second option was realized because it was simple to implement. Flashing elements were also expected. They should be activated via trigger labels. Important was the calculation of the time span for one cycle. It depends on the refresh rate of the ND display. The cycle length (for a full ON/OFF cycle) should be scalable and must be a multiple of the refresh rate. Flashing messages on Airbus EFIS use a cycle length of approximately 1 second. With the existing refresh rate the cycle length was scaled to the required value. It was recommended that a blinking effect could be realized via a switching between two colours (for example green and dark green) so that the value can always be read. Another possible choice was to make the header SUG_IAS blink instead of the value itself. It was considered to choose the second variant. In training mode TCAS parameters are given by the original hardware and the necessary entry parameters a given by the chosen trainings scenario. The implementa- 36 of 92

37 tion of a fully functional TCAS system with Traffic Advisories (TA) and Resolution Advisories (RA) combined with simulated traffic could have been realized only by calculating the necessary entry values. Detecting the system structure and the necessary algorithms would have been an intricate and time-consuming process. Moreover, TA and RA messages were not desired in ASAS mode because it was not part of project objectives to study the interaction between ASAS and TCAS. Therefore, it was decided to neglect the TCAS feature TA and RA. It was suggested to use the Simplified display rules of the URD [2] (Ref. URD 8.2.2). Only Other traffic and Proximate Traffic have been displayed in the trials. 4.5 SOFTWARE CORE STRUCTURE The developed ASAS Cockpit Interface at the ILR according to the specifications of EEC is designed as a black box module in principal. This ASAS module uses source from the CDB of the simulation, processes the data and writes the target parameters again into the CDB. The simulation dispatcher calls the ASAS module with a certain rate (every ms). Some information is gathered from the network and written into the CDB. Other information is only exchanged over CDB, for example FMS parameters. The information is displayed with TI- GERS TM, in the flight plan overlay or on the new MCDU pages. The master clock is realized by a counter in the first and critical band of the simulation. All external processes have to synchronize themselves to this master clock. Basic information for the ASAS calculations: Trailing Aircraft Parameters (Position, Ground Speed, Altitude, etc.), Leading Aircraft Parameters (Position, Ground Speed, Altitude, etc.), Flight plan information (Latitude, Longitude, Position in Flight Plan, etc.), FMS information (waypoint pointer, active mode, etc.), Master Clock (due to synchronisation problems with the time reference system IRIG- B only a counter in the critical band of the simulation was used). The flight guidance and management parameters can be read out from the CDB. The high update rate and the precision of these values do not require a further preparation of the data. The traffic parameters including the target information is acquired over Ethernet. An external process ( snci ) receives the TCP/IP data packets. This process buffers the data packets and uses the Shared Memory Access to provide the CDB with the received data. A module ( simconnect.c ) in the synchronous part of the simulation decodes the data and fills the target 37 of 92

38 parameters with the current values. An extrapolation routine estimates the current position if there is no current position update. The FMS information needs further treatment before the parameters flow into the ASAS algorithms. Whenever the FMS is busy, for instance during calculation of the predictions, the data processing of FMS data is paused. ASAS refers to the last value available. The flight is checked in terms of consistency. Then the lateral waypoints are separated from the pseudo waypoints because the course change is performed over each lateral waypoint. The FMS calculates the necessary positioning pointer for the flight plan, i.e. the value of the pointer designates a waypoint, for example next waypoint or destination airport. The ASAS algorithms browse the flight plan completely. The pointers are important for positioning but also for limitation of the processed flight plan legs. Waypoints beyond the destination airport may not be regarded for ASAS because the application ends on the final segment. The prediction of the curve segments and the calculation of the necessary Along Track Distance are executed by the ASAS module. The prepared data is further processed in the ASAS algorithms routines as described in chapter 4.8 or in [2]. The ASAS module output consists of target values like navigatory parameters, e.g. spacing error, or like flight performance parameters, e.g. closure rate. Furthermore, all logical values like visibility flags, colours or readout values are determined and exchanged with the information output modules of the HMI. 4.6 ND COCKPIT DISPLAY OF TRAFFIC INFORMATION The CAE Ltd. developed software TIGERS TM (The Interactive Graphics Environment for Real-time Systems) provides the design and the implementation of display pages for the experimental displays in the A330 FFS cockpit. TIGERS TM editor for graphical user interfaces is not designed for developing symbols which are dynamic in number and position. Therefore, the moving map flight plan overlay is coded in the programming language C. Only the spacing scale could be designed with this CAE tool. The Graphics Editor (GE) of the TIGERS package is an interactive graphics display editor used to create and to modify graphics pages; pages which are displayed in real-time by the TIGERS Graphics Page Interpreter (GPI). Using GE, you can design and modify a graphics display, a page, and save it in a file. The page can have dynamic input and output information associated with database variables. One of the most important features of this editor is that it allows users to associate database variables with graphic objects. These database variables can also be accessed by application programs. Once a display has been prepared, and displayed in real-time, the output of the programs can be made to control the features of the screen display. 38 of 92

39 The ND flight plan overlay uses the TIGERS HRGC Graphics Library which is according to IBM GL standard for AIX operation systems. These drawing functions allow the developer to create symbols which are variable in position, number, angle or colour. The flight plan overlay is updated whenever the aircraft position is changed by a certain tolerance distance or a symbol property has changed. TCAS symbols are updated independently. There are three types of graphical objects for the ND: Navaid (navigation aid) Symbols, TCAS Symbols and Flight Path Symbols. The navaid type is used for the target symbol and the predictive spacing position. The TCAS type is only necessary for the TCAS traffic. The reference line is represented by the flight path symbol. As required in the URD, The movement of certain symbols should be smoothed out. [2] Therefore, an appropriate extrapolation algorithm for a smooth movement was required. The state vector update rate is much lower than the maximum simulation rate (critical band 60 Hz). The proposed rate of 1 to 5 seconds of ADS-B data transmission was realized outside the main simulation by using an external traffic simulation. The extrapolation is furthermore discussed in chapter MCDU DIALOGUE The MCDU dialogue is realized by five interacting sub-modules. Each sub-module represents a new MCDU page. These pages enable the pilots to interact with the ASAS logic. The new pages are: ASAS Target Page (a340qfm_cosp0), ASAS Mode Page (a340qfm_cosp1), ASAS Remain Behind Page (a340qfm_cosp2), Active ASAS Mode Page (a340qfm_cosp3), ASAS Merge Page (a340qfm_cosp4). The MCDU dialogue is tailored according to the phases of a spacing task and comprises the required ASAS applications. Each page represents one or more stages of a spacing task. The user can navigate via the line selection keys between the phases and also the pages. ASAS Target Page (Page 0) features the activation of the display of traffic via selecting the according SSR code and enables the identification of the selected target aircraft. ASAS Mode Page offers all available spacing procedures (Remain, Merge, Pass) whereas the type of spacing is pre-selected trough the initialisation parameters. 39 of 92

40 ASAS Remain Behind Page and the ASAS Merge Page prompt the pilots to specify the spacing task parameters and the activation of the spacing process. Active ASAS Mode Page provides the crew with all necessary information about the current spacing task. The interrelation between all pages is presented in the following flowchart (Figure 13): 40 of 92

41 Figure 13 - MCDU Flow Chart [T. Pütz] 41 of 92

42 4.8 ASAS CALCULATIONS GENERAL The following presented calculations reflect only the main ideas and principles of the ASAS algorithms and calculations. Secondly their description reveals limitations and problems TRAFFIC POSITIONING AND POSITION EXTRAPOLATION In principle the traffic position messages are extrapolated as follows: Position( t) := Position t 0 ( ) + Velocity( t 0 ) ( t t 0 ) (4-1) A simple filtering improves the stability of the actual position information. Within curved flight plan segments the following problem appears. This simple linear extrapolation leads to an increasing error if there is no position update. The target aircraft seems to leave the curve segment in a tangential direction (Figure 14). The extrapolation is only used for calculating distances in distanced-based spacing, for the traffic display in the ND and also in the visual system of the FFS. Figure 14 - Extrapolated position in curved segments [EEC] 42 of 92

43 4.8.3 DIRECT DISTANCE ASAS requires the calculation and the display of symbols on the ND. The positioning of flight plan symbols in the flight plan overlay needs geographic coordinates (Latitude and Longitude). Therefore, the simulation offers accurate functions for navigational calculations like the Sodano Equations 1. New Position Range Bearing void new_pos (float *LAT1 /* latitude of position one */,float *LON1 /* longitude of position one */,float *DIST /* distance from position one to two */,float *BRG12 /* bearing from position one to two */,float *LAT2 /* latitude of position two */,float *LON2 /* longitude of position two */ ) void rng_brg (float *LAT1 Latitude of position one,float *LON1 Longitude of position one,float *LAT2 Latitude of position two,float *LON2 Longitude of position two,float *DIST Distance from position one to two,float *BRG12 Bearing from position one to two ) These functions allow the geodesic calculation of distances, angles and new positions by using Sodano and Sodano inverse functions. The results for the distance calculations are nearly the same compared to the results of the orthodromic calculation. Sodano is more accurate for calculations of positions on an ellipsoid which is closer to the earth geometry. The Along Track Distance calculation assumes a flat triangle for the projection point on the predicted flight path. This approximation has a very small error and is negligible. The Range-Bearing-functions demand comparatively much processing time. The number of calls was reduced as much as possible in order to save simulation spare time. 4.9 DISTANCE-BASED SPACING FOR REMAIN BEHIND The spacing between target and own ship is defined as the Along Track Distance. This means under the assumption of being on the same trajectory the length of the projected tra- 1 Sodano, Emmanuel M., "General Non-iterative Solution of the Inverse and Direct Geodetic Problems." Proceedings of the XlII I.U.G.G. General Assembly at Berkley, Calif., of 92

44 jectory on the earth (track) between the two aircraft is the distance along the track. (Figure 15) In reality the trajectory will not fit because of a different flight performance, deviations in the regulation of holding the trajectory, weather etc. In order to compensate a projection point is calculated for each aircraft and only the ATD between the projection points is taken into account. The cross track error is limited to left and to right of the track. Margin is 1 nautical mile. In case of being off the track the direct distance is taken into account instead. This is also the case for a flight plan discontinuity. Figure 15 - Along Track Distance calculation [T. Pütz] PROJECTION ON THE FLIGHT PLAN The projection point is the intersection of a straight line through an aircraft crossing the nearest flight plan segment under 90 degrees and the trajectory. For the calculation the flight plan is regarded in terms of a polygon with linear and curved segments. A simple Along Track Distance is presented in Figure 16. Figure 16 - Simple Along Track Distance [2] 44 of 92

45 Within curved segments the method to estimate projection points is more complex. First the angle between the circle centre, the beginning of the turn and the actual position has to be determined. The intersection of the corresponding radial and the circle is the projection point CALCULATION OF CURVE PARAMETERS Each curved segment (See Figure 17) has a beginning and ending on a linear segment of the flight plan. To determine the impact of curves on the Along Track Distance, the distance of the start and the corresponding waypoint has to be calculated. This value (Formula 4-6) has to be subtracted from the two linear segments. The arc length is then added to the ATD. The calculation is simplified by an instantaneous bank angle i.e. no transition. In addition, no speed change and no wind are also considered. Figure 17 - Turn Parameters [2] With the course change β and the ground speed V the arc length can be determined. R := g V 2 tan( bankangle) arclength := R β (4-2); (4-3) The distance from the waypoint to the end of the arc is expressed by the following: α := 90 β 2 R R h := l := sin( α) tan α ( ) (4-4) (4-5); (4-6) 45 of 92

46 4.9.3 TIME-BASED SPACING FOR REMAIN BEHIND The objective of time-based spacing is to follow the target with a constant time delay [2]. This means the own ship has to be at the place, where the target was a predefined number of seconds ago. Time based spacing = how many seconds ago was the projection of the target on current track equivalent to the current projection of own aircraft on the track. [2] In order to have information about the position of the target a certain number of seconds ago (x seconds) a history table has to be built up. But the simple state vector position generated by the pseudo ADS-B information is not accurate enough for this purpose. Therefore, an interpolation estimates the correct position regarding the history positions. The resulting position is also projected on the planned track. Figure 18 - Interpolation of target's position [EEC] The along track distance to the history position is the spacing error in distance and by dividing it with own ground speed the error in time is expressed. Subtracted from the predefined spacing you get the Time Based Spacing: TimeBasedSpacing() t := x+ ATD( own_pos ( t), target_pos ( t x) ) owngs() t (4-7) Due to the very scarce spare time of the simulation host computer some simplifications have been made. The extrapolation has been improved, and by using the projection points the 46 of 92

47 ATD is comparatively stable. The distances of the history table are added and a simple interpolation adjusts the result to exactly x seconds. The resulting distance is subtracted from the ATD and you get the spacing error in distance. Then formula 4-7 is used also. This trade-off has specific disadvantages. The normal concept does not consider the actual target position. The simplification needs this actual position information. This has influence on the calculated spacing if there are any specific changes in behaviour of the target. Any changes in the actual trajectory of the target have direct impact and can lead to a discontinuity in spacing (spacing jumps). In a next phase it should be planned to remove this simplification! DISTANCE-BASED SPACING FOR MERGE BEHIND The merging spacing value is the projected spacing distance that will exist between the two aircraft when the target reaches the merging waypoint. [2] During distance-based spacing this means the actual distance along the track from the target which is at the furthest end of turn and the own ship. The furthest point of turn is the converging point of the two trajectories. It is located behind the merging waypoint because each course change needs a turn with a certain radius. The greatest turn determines this point. Figure 19 - Merging Distance [EEC] MergingDistance := Dist( own, FurthestEndOfTurn ) Dist( target, FurthestEndOfTurn ) (4-8) Once the own ship has ended its turn, the system switches to Remain behind calculations. 47 of 92

48 4.9.5 TIME BASED SPACING FOR MERGE BEHIND In analogy to time-based spacing in Remain with this procedure the own aircraft has to be a predefined number of seconds behind when it reaches the merging waypoint. The merging procedure ends when the own aircraft finishes its turn, so that the trajectories are the same. TimeBasedSpacing() t := x+ ATD( own_pos ( t), FurthestEndOfTurn ) ATD( target_pos ( t x), FurthestEndOfTurn ) owngs() t (4-9) SPACING TREND AND CLOSURE RATE The spacing trend presented in the spacing scale is basically the derivative of the spacing value. Practically it is the closure rate multiplied with the value for the look-ahead time. The closure rate is the difference of the ground speed between target and own aircraft. ClosureRate Dist := owngs( t) targetgs() t SpacingTrendValue Dist := ClosureRate Dist LookAheadTime (4-10) (4-11) For time-based spacing, the spacing trend value corresponds to the impact of the closure rate on own ground speed during the look-ahead time. The closure rate is the difference between ground speed of the trailing aircraft and the history value of target s ground speed regarding the anticipation parameter in time for the pilot reaction (x - y). ClosureRate Time := owngs( t) targetgs( t x + y) (4-12) ClosureRate Time SpacingTrendValue Time := owngs() t LookAheadTime (4-13) SUGGESTED SPEED CALCULATION AND TIME CONSTRAINT The suggested speed supports the pilot in selecting an adequate indicated air speed in order to acquire, stabilize and maintain the given spacing. SuggestedIAS Dist := targetgs() t + SpacingError TimeConstraint (4-14) SuggestedIAS Time := targetgs( t x + y) + SpacingError owngs() t TimeConstraint (4-15) Normally in maintain phase the closure rate has to be zero. This means that the trailing aircraft has to keep the ground speed of the target. In case of a spacing error the value is increased or decreased depending on a time constraint. 48 of 92

49 The reduction of the spacing error should not be performed at once, with the maximum or minimum available speed. This would lead to higher accelerations of the aircraft influencing flight performance, engine activity, fuel consumption and passenger comfort. During acquisition phase the time constraint starts at a high value and is progressively reduced to a minimum value of 2 minutes (Figure 20). In remain phase the upper value is 5 minutes and in merge the upper value is determined by the time to the merging waypoint. Figure 20 - Time Constraint [EEC] The value for the suggested speed is rounded and filtered. It is displayed in steps of five knots. This reduces pilot s workload and avoids too much activity of the aircraft itself (engine, pitch angle) TOLERANCE MARGINS IN ACQUISITION The tolerance limits are progressively reduced in acquisition phase. To avoid undesired cautions or warnings an instability margin of 1 second exists (Figure 21). Figure 21 - Instability Margin [EEC] 49 of 92

50 4.9.9 TIME TO REACH SPACING AND PREDICTIVE SPACING SYMBOL The time to reach spacing is an information on the MCDU to inform the pilots about the expected begin of the maintain phase. In addition this information is used for positioning the predictive spacing position symbols. For Remain behind applications it is calculated from spacing error and closure rate. For time-based spacing the own ground speed is used to convert the spacing error. In this case the closure rate does not consider the delay due to pilot reaction. SpacingError TimeToSpacing Dist := owngs( t) targetgs() t SpacingError owngs() t TimeToSpacing Time := owngs( t) targetgs( t x) (4-16) (4-17) Time to reach spacing for Merge behind applications has one difference in calculation. If one of the aircraft has a track angle deviation, it could be corrected by using the cosine of the angle between the actual track of the aircraft and the bearing to merging waypoint (See Figure 22). For a Direct-To operation, which has been used for the merging application, there is no greater deviation. Therefore, the track angle deviation is not regarded in the ASAS Cockpit Interface software at the SRF. Figure 22 - Track angle deviation [EEC] SpacingError TimeToSpacing Dist := owngs( t) cos ( β) targetgs() t SpacingError owngs() t TimeToSpacing Time := owngs( t) cos( β) targetgs( t x) (4-18) (4-19) The predictive spacing symbol shows the geographical position where the spacing will be reached. It is located along the predicted track. The distance from the trailing aircraft to the predictive spacing symbol is calculated with the own ground speed and the time to spacing value. When it is not possible to compute the time to reach spacing no predictive spacing position or value is indicated on the ND and also on the MCDU. DistanceOfBrokenArrow := TimeToSpacing owngs() t (4-20) 50 of 92

51 4.10 TRAFFIC SIMULATION The experimental set-up required pseudo ADS-B information generated by external software. Several methods had been identified. Main requirement was to enable the ASAS logic to interpret the pseudo ADS-B position reports as a continuous trajectory. Moreover it should be possible to have surrounding traffic information but with a lower precision or lower update rate. Four main options for traffic generation had been extracted: 1) Installing a SOLARIS machine in Berlin to run DIS manager and re-using EEC logs 2) Normal use of the Generic Air Traffic Simulation (GATS) 3) Replaying recorded flights from the A340/330 FFS simulator (possible for 4-5 flights but not 20) a) Using GATS 4) Replaying traffic from ASCII data files with a specific format provided by EEC: a) Using GATS b) Development of a new traffic replay tool. Installation of a SOLARIS machine was considered as too complex and time-consuming. That was also the case for exporting the DIS Manager software from the SOLARIS station. GATS provides two traffic formats. One is based on flight plans (solution 2) and it only supports a steady-state flight performance (constant speed and altitude). Curved segments could not be realized because the flight plan could only be fragmented in legs with a length of several seconds. The other format is based on recorded data file format. GATS reads out a data file with an update rate possible lower than 1 second. Therefore, only the second variant (3.a or 4.a) was established in a first approach. Tests with solution 3.a had been performed on a sample file with flight data. The test was finished successfully. A test with a complete traffic file of EEC had also been performed; it was decided to have ideally one data file per aircraft. At first, option 4.a) was preferred but then option 4.b) had to be realized because of deficiencies of GATS. Due to the scarce simulation spare time of the host computer the GATS solution had to be revised. It was necessary to develop a new replay tool for the existing traffic files in order to replay more than 4 or 5 surrounding aircrafts. In order to have a smooth movement of traffic in the visual display, bank and pitch were added to the EEC traffic data files. Even if the data was not available, the bank and pitch fields were filled with the value zero but at least the leading aircraft had to be complete. 51 of 92

52 The new system had to fulfil the following requirements: 1) The new traffic generator shall transfer the data of up to 50 aircraft to the main simulation. 2) Each aircraft of the simulated surrounding traffic has its own data file with position and flight data of a specified data format. Each data set consists of nine parameters. The first parameter is the so-called time-stamp, which designates the point of time of the described flight condition. The time stamp is only transferred for the target aircraft. The data files have different starting times and also different time intervals. The interval length lies between 5 seconds and 0.1 seconds, but typically at 1 second. 3) The parameters shall be distributed over the simulation network using Ethernet and TCP/IP protocol. The data is written into the common data base (CDB) block of the main simulation. The external processes have to be synchronized with the master clock of the main simulation. For this reason the necessary parameters have to be read in the CDB. 4) The traffic scenario and the main simulation shall be started via a parameter of the CDB (label: costartrun). The parameter is controlled by this new traffic tool. 5) The position reports shall be processed in the main simulation that means all necessary mathematical operations will be performed in the ASAS modules on the simulation host. Any delays in external processing and the network itself are compensated in the synchronous process of the real-time simulation on the host. Older reports which have a delay of more than 1 second will be filtered out. The correct order of the data has to be ensured. 6) The traffic tool shall be designed for a Windows software platform. The external hardware shall base on a common off-the-shelf personal computer. The following source parameter (Table 1) shall be read out by the traffic tool and based on the source parameter the tool shall provide the simulation with the required target parameters: Source Parameter Pos. Parameter CDB source Data type Comment 1 Simulation time cosimtmd Double 2 Start run flag costartrun Logical 52 of 92

53 Target Parameter Pos. Parameter CDB target Data type Comment 1 Time stamp cotimstamp Double Only for target 2 Latitude dfgaclat Float 3 Longitude dfgaclon Float 4 Absolute Height dfgacalt Float 5 Ground speed dfgacspd Float 6 Vertical speed dfgacvspd Float 7 Track angle dfgactrk Float 8 Pitch angle dfgacpitch Float 9 Roll angle dfgacroll Float Table 1 Exchange Parameters The traffic tool is equipped with a graphical user interface. The experimental leader/ operator can monitor and control the external simulation with this interface. Each scenario is prepared in its own directory. The program supports the selection of a directory. All scenarios can be started, stopped and reset. All flights are listed in a table with all currently transferred parameters. The new tool is called WSI (Windows Simulation Interface). Figure 23 presents the WSI user interface. Monitoring and Controlling capabilities are provided in the main window. Coloured indications show the status of the data stream. Readout of all main parameters is displayed. Pushbuttons allow the control of the traffic generator especially the start and reset of the scenario. In order to establish a communication between simulation host and external software platform further functional elements had to be integrated into the simulation environment. This additional software is running on the simulation host, i.e. snci and the simconnect-module, and is receiving the data packets from the WSI, decodes them and writes the data into the CDB. 53 of 92

54 Figure 23 - Windows Simulation Interface [T. Pütz] 4.11 AUDIO EQUIPMENT To complete the experimental set-up an audio scenario was created. The simulator allows only the communication between crew, instructor and one observer. The requirement for experiments was to provide a radio communication facility with replay function for audio files. Also a muting function shall be integrated in order to allow the instructor to override replayed ATC messages manually and to enable him of giving ATC instructions. The WSI traffic tool was expanded with audio replay functionality. This allows the synchronisation of the audio file with the main simulation. The audio data file can be a normal WAVEfile. It is placed in the same folder as the scenario so that the whole experimental scenario could be changed via the WSI. Audio source is the notebook which is placed in the cockpit. The electrical connection to cockpit had to meet strict requirements in order to protect the certified and original hardware of the simulator. For this reason a galvanic isolation and a protection against voltage peaks had to be implemented. The galvanic isolation was realized by a direct injection box which is 54 of 92

55 used for professional audio equipment. A microphone pre-amplifier equipped with a peak limiter protects against any voltage peaks. Figure 24 shows the complete setup. Figure 24 Setup of the audio equipment [T. Pütz] A special setting of the audio environment has to be configured for using the external audio source. All radio management panels have to be configured before each experiment. The plug socket of the boom-set is used for the connection to the audio source equipment. Normally the push-to-talk button enables the transmission. In this operation mode it has to be performed by software. The push-to-talk button has to be triggered via the simulation. A simple logic in a simulation module enables the muting of the audio source. Especially the radio management panel of the instructor has to be configured for transmission: (Figure 25) Figure 25 Radio Management Panel [Airbus FCOM] 55 of 92

56 All the audio signal settings had to be adapted and to be tested. The audio channels have to be configured and the recording level had to be figured out. Afterwards a formal acceptance test was performed by Zentrum für Flugsimulation GmbH. The Scientific Research Facility provides a video recording facility for logging audio and video information on video tapes. There are different channels for audio recording which could be activated and mixed with other channels. Depending on the experimental objective the voices can be separated or mixed together. In the CoSpace experiments at the SRF it was required to have all the audio information on one video tape. The setting for audio recording can be arranged on the lower IOS Page. Also it is possible to do the settings with the help of a script-file which is executed in the simulator monitoring utility CTS-PLUS. Figure 26 presents an example audio setting which was used in earlier experiments. Figure 26 IOS audio setting for recording [ILR] 56 of 92

57 5 EXPERIMENTAL DESIGN 5.1 EXPERIMENTAL PLAN The experiments carried out were a continuation of the cockpit simulator experiments done at EEC in April The intention was to assess the effect of preceding aircraft s different reactions, which are under spacing as well as the target aircraft. Unlike previous trials the type of spacing was chosen as time-based only with different initial spacing deviations (see below). For all scenarios the merge instruction was given with a spacing the pilots had to achieve. The type of spacing (time-based and large vs. small) as well as the pilot function (PF and PNF) could be seen as independent variables, whereas the trials looked closer to dependent variables (also Table 2): Human shaping factors: subjective feedback on motivation and perceived usefulness, workload shared between PF and PNF, usability, strategies; Activity: number and magnitude of (speed) adjustments; duration between (speed) actions; Effectiveness: spacing accuracy; Safety: subjective feedback, losses of spacing, critical aircraft states, passenger comfort. High level objective Metrics Measures Motivation and perceived Subjective Feedback usefulness Workload Subjective Feedback; missed actions / instructions Human shaping factors Crew coordination (subjective) Subjective Feedback; Task distribution PF / PNF usability Subjective Feedback; number of errors, usage of displays and interfaces Skills and training needs Subjective Feedback; comparison of sequent runs (errors, behaviour, strategies) Communication with ATC Subjective Feedback; number and duration of transmission Flight Crew activity Navigate and fly the aircraft Subjective Feedback, number and duration of actions on flight parameters Strategies Subjective Feedback; reaction time; communication between pilots Acquire / maintain spacing Number and magnitude of speed actions, time in between Effectiveness Maintain situation awareness Subjective Feedback, number and duration of actions on flight parameters, panel scanning, communication between pilots, reaction time Crew coordination (checklists, briefing, cross check) Subjective Feedback; communication between pilots; observations 57 of 92

58 Subjective Feedback; flight efficiency; accuracy Quality of flying of flight plan (time; ETA); passenger comfort (change in angle of attack); spacing accuracy Pseudo controller perspective Respect of instructions (reaction time and magnitude, ) Flight errors Subjective Feedback; messages; missed instructions (number and magnitude) Spacing task-related errors Subjective Feedback; loss of spacing (number, magnitude and duration) Safety Passenger comfort Subjective Feedback; aircraft movements (AOA); predicted ETA Critical aircraft states Subjective Feedback; wake turbulences; convergence to other aircrafts; flight envelope Table 2 - Objectives, dimensions, metrics and measures related to flight deck analysis 5.2 SIMULATION RUN PLAN The simulation took place at the Institute of Aeronautics and Astronautics, Berlin between March 7 th and 18 th of The 10 days of experiments were attended by 5 crews, 3 Captains and 7 First Officers rated for Airbus A330/340 (Table 3). Age Experience Flying in general Flying Airbusmodels Hours Years Hours Years , , Table 3 - Participants age and experience distribution The test series for each crew consisted of one training and one measured day to get them trained to the new system, its technology, the logic and phraseology. During each day the pilots had to accomplish different briefings and four different scenarios (runs). On the first day (training day) the pilots were introduced to the new system and principles of ASAS by an initial briefing and a demonstration (video). After an operational briefing (restrictions, routings and aircraft parameters were told) the pilots did 2 runs without ATC-communication. Afterwards, they performed 2 runs with ATC-communication and data recording. Therefore, recorded traffic scenarios for surrounding traffic including target aircraft, which was not under conventional control but under spacing, were implemented into the simulation to increase the realism. Also background traffic communication and instructions the pilots had to answer and follow have completed experimental environment. 58 of 92

59 On the training day the pilots had the opportunity to become acquainted with the system in two runs without any communications (only observer instructions). During the 3 rd run (the first with ATC-communication) the pilots were asked to follow the required spacing by action they think would fit the task best, whereas the pilots had to follow the suggested indicated airspeed (SUG IAS) given through the system on the ND during the last run of the training day. At the end pilots feedback was given in a short debriefing. After a briefing about first results of the previous day and about the ground results gathered during earlier test series the pilots had to perform the same runs in a different order, with a distinct task (PF and PNF), with data recording, and ATC-communication on the second day (measured day). At the end a debriefing and feedback was held. Day Run Comments Pilot 1 Pilot 2 1 Without audio / ATC-communication PF PNF 4 Without audio / ATC-communication PNF PF Training day 2 With audio / ATC-communication; data recording; PF PNF take appropriate actions to follow the spacing exactly 3 With audio / ATC-communication; data recording; PNF PF follow the given SUG_IAS 2 With audio / ATC-communication; data recording; PNF PF follow the given SUG_IAS 3 With audio / ATC-communication; data recording; PF PNF Measured day follow the given SUG_IAS 1 With audio / ATC-communication; data recording; PNF PF follow the given SUG_IAS 4 With audio / ATC-communication; data recording; PF PNF follow the given SUG_IAS Table 4 - Run-plan In general the flight crew task was to perform a full automatic flight with all usual flight tasks such as: Communication to ATC; Communication between the pilots; Briefings and call-outs; Arrival preparation. Additional they were asked to adjust spacing manually via speed-select mode with support of implemented display cues. 5.3 SIMULATED ENVIRONMENT Ensuring comparability of test results the simulated airspace (derived from Paris area) and traffic were similar to the ones used for the CoSpace experiments in November 2002, June 2003 and April Each flight was part of an air traffic environment previously recorded with controllers, thus providing realistic voice communications was possible. Also pseudocontroller was present on the frequency in order to: 59 of 92

60 Give ATC-instructions for the first two runs on the training day; Confirm the target positioning made by the crew; Reissue the proper ATC-instructions in case an instruction was missed or misunderstood by the pilots; Answer any possible ATC-request from the crew. The four scenarios consisted of arrivals to Paris Orly (LFPO / ORY) and Charles De Gaulle (LFPG / CDG) from climb or cruise level to the final approach fix or slightly beyond coming from the southeast. Each run comprised a complete flight from take-off to a full-stop landing. Several minutes of each run elapsed for re-positioning to the starting point of the scenario. Each run represented an aircraft flying at different positions in an arrival chain to Paris, so the simulated aircraft was not the target but number 2, 3 within the chain. The four runs are characterized as follows: Run Flight plan (departure destination) Scenario description Initial altitude and speed after re-positioning 1 LIML / LFPO Baseline FL 300 M LSGG / LFPG Initial spacing (chain), rapid 21817ft climbing to FL 280 reaction time 290 IAS 3 EDDM / LFPG Higher cruise FL, strong FL 320 deceleration M LSGG / LFPG Cruise FL (chain), smooth 21793ft climbing to FL 280 deceleration 300 IAS Table 5 - Run description Elapsed time 24 min 18 min 46 min 18 min Since there were no standard trajectories from the initial approach fix to the final approach fix in the south of Paris (in practice radar vectoring is used by ATC-controllers) these trajectories were added by putting in some new and modified waypoints. The scenarios lasted about 35 to 39 minutes of flight time from the repositioning point to the end of the scenario and approximately 5 to 7 minutes more for the full-stop landing respecting a go-around because of weather conditions. The following figure (Figure 27) describes the simulated airspace and trajectories southeast area of Paris for the different runs. 60 of 92

61 Figure 27 - Simulated airspace and trajectories [EEC] Scenario 1 and 3 was composed of three flight phases: Cruise, initial descent from cruise flight level to IAF and initial approach from IAF to FAF. In addition, there was a climb phase for scenario 2 and 4. All major actions of each scenario are listed in the Table 6. In the course of each scenario the ATC advised a re-routing of the current flight plan in order to match the trajectory of the trailing aircraft with the leading aircraft. During run 1 a DIRECT- TO had to be performed via the DIR-TO page of the MCDU whereas re-routings had to be performed during run 2, 3 and 4. For these cases the pilots were explicitly advised to use the LAT REV page (Lateral Revision page) of the MCDU for putting in the next waypoint. At the beginning of run 2, 3 and 4 the pilots had to perform a re-routing started by a heading instruction of the ATC, in the first case they followed the inserted flight plan of the FMS. The following table lists all the major ATC-instructions of the flights regarding spacing procedure and flight trajectory. 61 of 92

62 Time Run 1 Run 2 Run 3 Run 4 2:57 HEADING 010 3:25 Select target 3:45 HEADING 020 3:55 Select target 4:28 HEADING 10 degrees left 4:50 Reduce speed Mach :27 Merge at waypoint 90 sec behind 5:35 Select target 6:41 Select target 7:10 Merge at waypoint 90 sec behind 8:36 Merge at waypoint 90 sec behind 8:52 Merge at waypoint 90 sec behind 10:57 Descent to FL 80 13:27 Descent to FL :22 Descent to FL :47 Descent to FL :53 Descent to FL 70 20:22 DIR TO LOMAN 22:37 Routing OMAKO TAMAK 22:53 Routing OMAKO TAMAK 23:10 Routing OMAKO TAMAK 23:12 Descent to altitude 4000 ft 25:20 Descent to FL 60 25:22 Descent to FL 60 26:45 Descent to FL 60 28:51 Descent to altitude 3000 ft 29:25 Descent to altitude 3000 ft 29:27 Descent to altitude 3000 ft 30:49 Cancel spacing 33:00 Cancel spacing 33:44 Cancel spacing 33:45 Cancel spacing Table 6 - Major ATC-instructions 62 of 92

63 Reducing workload to the pilots the simulator was already set-up and put into takeoff position on the runway. The flight plan was inserted into the FMS via a script containing the following aircraft parameters: zero fuel weight (ZFW): kg centre of gravity (CG ZFW): 28,1 % (MAC) fuel on board (FOB): kg (fuel freeze was applied) speeds V 1 / V R / V 2 : 147 / 152 / 158 kts Moreover, for increasing realism reasons different weather completed the scenarios according to the ATIS given to the pilots. Secondly, more weather features were triggered by the experimental leader on the IOS such as wind shears for different altitudes or precipitation having impact on the runway condition. Some manually triggered events leaded to a goaround manoeuvre, already mentioned above. Run 1 Run 2 Run 3 Run 4 Visibility 9000 m 9000 m 9000 m 1300 m Clouds Scattered Scattered Broken Broken Clouds ceiling 4000 ft 1400 ft 4000 ft 3000 ft Clouds top ft ft ft ft Wind direction Wind speed 7 kts (ground level) 3 kts (FL 100 and above) 11 kts (ground level) 6 kts (FL 100 and above) 17 kts (ground level) 10 kts (FL 100) 5 kts (FL 360) 5 kts (ground level) 10 kts (FL 100) 5 kts (FL 360) Temperature 20 Celcius 9 Celcius 16 Celcius -3 Celcius (ground level) Precipitation no no rain Light rain Table 7 - Weather scenarios In the planning of the experiments it was discussed to include cabin crew interaction. The pilots should face unexpected situations and handle this. For example, the flying crew would be interfered in their cockpit work by a passenger problem: Business passengers are unhappy with cold meal, are very noisy and unpleasant (due to problems with ovens). The idea of cabin crew interaction was rejected because of the high workload for observers and experimental leader. An additional cockpit occupant could not be realized for safety reasons and limited space on the flight deck of the FFS. Apart from this no further channels for audio communication were available. 63 of 92

64 6 DATA COLLECTION For measurement purpose two groups of data were collected: Objective data: consist of system recordings such as aircraft parameters, pilots actions, and spacing parameters; Subjective data: comprise observer notes, questionnaires, including the use of the NASA Task Load Index (NASA-TLX) for workload assessment, briefing and debriefing items. The following Table 8 combines data collection method, occurrence, relevance, and attributes: occurrence Method / tool Metrics concerned Attributes Subjective / objective Qualitative / quantitative Pre simulation Questionnaire None (pilots profile and experience) Subjective / objective qualitative Observations All human shaping factors, Subjective (observer bias) cues about human activity, Qualitative Run continuous efficiency and safety, specials System recordings All, at a detailed level Objective Quantitative Post run Questionnaire / All, at a detailed level Subjective NASA-TLX Qualitative / Quantitative Questionnaire All, at a detailed level Subjective Post simulation Qualitative / Quantitative Debriefing All Subjective Qualitative Table 8 - Data collection method and data attributes The first day each pilot filled out the entry questionnaire and two post-run questionnaires. In addition, observer notes were taken for all four runs done during the training day as well as data logs (system recordings of aircraft parameters) for the last two runs. On the second day four post-run and one final questionnaire were filled out by each pilot. Furthermore, observer notes and data logs were taken for all four runs during the measured day. Blank questionnaires are presented in the annex. Besides the subjective data described above objective data were taken by video tape recordings from the back of the flight deck and data recordings such as aircraft parameters, pilots actions, and spacing parameters put into data logs. Although all data were put in one data log and recorded four times per second these data logs consist of two different data types: periodic data describe the state of the aircraft, its target and the spacing situation (state data) and discrete data concerning all the pilots actions (action data). 64 of 92

65 Some parameter-formats indicate exact values of variables (such as real, integer ) others indicate a change of the status only (logical variables). The following table shows all variables gathered during the trials. Variable Description [Unit] Format Type Component YTSIMTM simulator Time [sec] real state COSIMTMD simulation time (double precision) [sec] double state COSPSSR4 SSR code of chosen A/C integer state RUPLAT A/C latitude [degs] double state RUPLON A/C longitude [degs] double state VHS absolute height above sea level [feet] real state VHH pressure altitude [feet] real state RNA320AA heading (magnetic) [degs] real state UWCAS calibrated airspeed [knots] real state UBA205AA Mach real state COOWNSPD ground speed of own A/C [knots] real state QEMXWPTID(1,1) next waypoint ident (first letter) blockinteger state QEMXWPTID(2,1) next waypoint ident (second letter) blockinteger state QFLDISTO(1) direct distance to "TO" waypoint [NM] block-real state XZCOMFRE(1) communication frequency on RMP (Captain) [MHz] block-real state XZCOMFRE(2) communication frequency on RMP (FO) [MHz] block-real state COATDACT along track distance actual [NM] real state COATDACTT along track distance actual [sec] real state COATDREQT along track distance required [sec] real state COCRATETIM closure rate time-based real state COSUGIAS indicated suggested IAS for ASAS [knots] real state COSUGGS suggested GS for ASAS [knots] real state LQA103AA selected speed on FCU [knots] real state LQA102AA/4 selected altitude on FCU [feet] real state COEXTGTLAT(1) latitude of extrapolated target position [degs] blockdouble state COEXTGTLON(1) longitude of extrapolated target position [degs] blockdouble state DFGACALT(1) altitude of target [feet] block-real state COTGTSPD ground speed of target [knots] real state QFDPTN(1) MCDU current page number (Captain) blockinteger action MCDU QFDPTN(2) MCDU current page number (FO) blockinteger action MCDU STKACSEL STK: A/C selected logical action MCDU / ASAS STATES COSPCMODE spacing mode 0, 1->remain, integer action MCDU / ASAS STATES 65 of 92

66 2->merge, 3->hdg COPHASE ASAS phase (nothing, ident, assess,...) integer action MCDU / ASAS STATES COWPTSEL merge waypoint selected logical action MCDU / ASAS STATES COSUGCOL suggested speed colour (0 No, 1 Green, 2 Am, 3 Red) integer action MCDU / ASAS STATES JC29A04A SPD BRK command logical action speed brakes action JEA134AA AIRBRAKES LEVER position real action speed brakes action JC27A04A GND SPLRS armed logical action speed brakes action AWVCSU slat/flap csu select pos 0,1,2,3,4 real action flaps selection IDAMLL landing lights sw logical action overhead panel LS16B17B FASTEN SEAT BELTS signs logical action overhead panel IDAGLU LDG GEAR LEVER up logical action landing gear and auto brake system FM15C09A DESCENT mode active logical action FMA FM17C09A OP DES mode active logical action FMA JI18A08A EXP DES mode active logical action FMA FM13C08A G/S TRK mode active logical action FMA FM14C08A G/S CAPTURE mode active logical action FMA FM23C09A V/S mode active logical action FMA FM24C09A FPA mode active logical action FMA FM12C07A ALT ACQ mode armed logical action FMA FM22C07A G/S mode armed logical action FMA FM16C10A HDG mode active logical action FMA FM12C10A NAV mode active logical action FMA FM13C10A LOC CAP mode active logical action FMA FM14C10A LOC TRK mode active logical action FMA FM16C07A LOC mode armed logical action FMA FM12C02A AP 1 engage logical action FMA FM12C02B AP 2 engage logical action FMA FM14C04A A/THR active logical action FMA YSOVRCNT(1) CPUi cumulated number of overruns blockinteger state COTIMTOSPC time to spacing real state COTCASIDX number of TCAS traffic in range integer state COWPTIDT(1) identification of merge waypoint (first letter) blockinteger action MCDU / ASAS STATES COWPTIDT(2) identification of merge waypoint (second letter) blockinteger action MCDU / ASAS STATES COREFLCOL reference line colour (0 Cyan, 1 White, 2 Am, 3 Red) integer action MCDU / ASAS STATES COASASPAGE current MCDU ASAS page code integer action MCDU / ASAS STATES COASASMSG ND and MCDU ASAS messages integer action MCDU / ASAS STATES COTIMSTAMP time stamp of last target position double state COTIMECSTR time constraint for suggested speed real state Table 9 - used variables in data log 66 of 92

67 The data recording was activated manually some seconds prior the release of the flight freeze at the beginning of the scenarios (in-flight) and also stopped manually after touchdown at the destination airport. To analyse and interpret the gathered data some additional information is given: The current shown MCDU-page is indicated by QFDPTN whereas index (1) points to the Captain s MCDU and (2) to the First Officer s. As long as the aircraft is under spacing and the appropriate actions on the MCDU are fulfilled, the variable COASASPAGE marks the actual ASAS-page even the pilot press a NON-ASAS-page on the MCDU marked by QFDPTN. (See Table 11) There are two parameters showing the first two letters of the next waypoint: QEMXWPTID and COWPTIDT. The first one refers to the next waypoint in the flight plan of the FMS the last points to the merging waypoint of the ASAS-logic. The variable COASASMSG can have different states shown below in Table 10 and functioned as a place holder for the associated messages presented on ND and MCDU. state Associated message Type of message Comment 0 No 1 ASAS STABILIZE SPEED Advisory 2 ASAS SLOW DOWN Advisory 3 ASAS ACCELERATE Advisory 4 ASAS SLOW DOWN Caution 5 ASAS ACCELERATE Caution 6 ASAS UNABLE SPACING Advisory 7 ASAS UNABLE SPACING Warning 8 ASAS DIRECT RO Advisory Not used for this trial 9 ASAS INVALID SSR CODE Advisory 10 ASAS PREPARE DIR TO Advisory Not used for this trial 11 ASAS TARGET LOST Advisory 12 ASAS TARGET OUT OF TRACK Advisory 13 ASAS LOSING SPACING Advisory 14 ASAS DIRECT TO Caution Not used for this trial 15 ASAS PREPARE DIR TO Caution Not used for this trial Table 10 - states and associated message of COASASMSG Regarding the ASAS-states and the pilot s input on the MCDU there are several parameters indicating each change. The following table correlates changing of parameters (ASAS-states) and actions done by the pilots on the MCDU. 67 of 92

68 Action Value qfdptn stkacsel cospcmode cophase cowptsel coasaspage Select Target 2037 (SSR code value, as entered) 96 F T Press RE- TURN In ASAS TARGET 2/2 96 T F Select Spacing Select Spacing Select Spacing Select Spacing 90 s (or NM) in MERGE 1/2 90 s (or NM) in MERGE 2/2 At least 90 s (or NM) in MERGE 1/2 At least 90 s (or NM) in MERGE 2/2 100 T 2 1 F T 2 3 T T 2 1 F T 2 3 T 100 Validate Waypoint Press A- SAS OKRIX in MERGE 1/2 100 T F T 100 In MCDU MENU page > 95 > 95 Press RE- TURN In MERGE 1/ T Press RE- TURN In MERGE 2/ T Press END SPACING In MERGE 1/2 for Target T Press IN- SERT In MERGE 2/ T 2 99 Press IN- SERT In ASAS TARGET 2/ T 97 Press MERGE In ASAS MODE 1/ T 0 1 F 100 Press MERGE In ASAS MODE 2/ T 0 F 100 Press DE- SELECT In ASAS MODE 1/ F 0 0 F 96 Press DE- SELECT In ASAS MODE 2/ F 0 0 F 96 Press RE- TURN Press END SPACING In ASAS MODE 2/2 End Merge in ACTIVE ASAS MODE for Target T 0 99 T 2 T F 97 Table 11 - correlation of pilot's action and ASAS-states 68 of 92

69 7 RESULTS 7.1 PROBLEMS DURING DEVELOPMENT GENERAL The development team faced several heavy problems during the coding, testing and debugging phase. Mainly it was caused by the complex environment of the Scientific Research Facility and the given processing and network technology compared to the high requirements in precision of ASAS. The flight simulator was set up in Compared to state-of-the-art technology the processing power of the IBM Risc 6000 Model 580 is relatively low. Also the Ethernet network is using a 10 MBit transfer rate. Real-time systems using the Hardware-in-the-Loop -concept have some disadvantages. Delayed or wrong information can disturb the original hardware. In the case of scarce processing time and loss of network communication caused this effect resulting in unexpected failures of avionic systems like TCAS or GPWS (Ground Proximity Warning System). In addition, high update rates compelled by ASAS of original parts especially like the MCDU can downgrade their functionality. For example, the MCDU seems to work slowly. Also a disordered communication in a Distributed Simulation Environment with external simulations like the traffic generator can produce unforeseeable functional distortions. The main technical problems lay in the following fields: Scarce spare time (CPU time for processes on the same simulation host but outside the main simulation) caused by the used processing technology and an average CPU load factor of 70 % in full flight mode produced limitations. The time consuming functions for precise calculation of range and bearing and extrapolation algorithms used most of the spare time. So called overruns occurred due to the high processing time demand. An overrun occurs if the execution time of the synchronous process exceeds the basic frame time of a real-time simulation. One stable time reference had to be introduced, because the time reference system was sometimes disturbed by overruns or the synchronisation process with the simulation. This led to drifting times between the master clock and the external clock. The existing traffic simulation software GATS (Generic Air Traffic Simulation) by ILR/ TUB had not met the specification of the project. The introduction of new software with higher precision and variable update rate had been necessary. The new tool was then used for experiments. 69 of 92

70 Problems with the calculation of suggested speed arose. The atmospheric compensation due to the different altitudes was not accurate enough because of inaccurate entry values available in the simulation. An alternative calculation method had to be found and verified. The Software FMS as a data source was not always reliable or available along a simulation run. A busy status had to be identified and the resulting information had to be buffered and filtered. In addition, the software FMS had to handle new waypoints. Not all functions are supported for new waypoints in general. A modification of the data base was not available in the development and preparation phase. New waypoints, scarce spare time, overruns and design problems of the Software FMS also had impact on the stability and reliability of lateral revisions. The introduction of a new visual system had had impact on the scenario preparation phase. Many features of the visual scenarios had to be corrected after the installation of the system. The project schedule had foreseen one major milestone, the so called dress rehearsal, which was performed on the 25th of February On that day the team was able to come to a decision if a Go or No-Go situation could be detected for the experiments. Due to the fact that all problems were solved, bypassed or minimized if still existing a Go was decided and experiments could be prepared FEW SPARE TIME Apart from the processing capabilities software design and data gathering for the experiments influenced the available spare time strongly (Figure 28). Various measures were taken to keep the spare time in the limits. The simulator operating system provides a Performance Utility, PFU, for controlling and monitoring the simulation task scheduling. Figure 28 - Simulation cycles [CAE] 70 of 92

71 With help of the PFU it was possible to weight the banding scheme (Figure 29), defined in the dispatcher table, for a better average performance. This included also the commenting out of unnecessary modules. Although it reduced the functionality of the simulator, only functional features of a low priority with no impact on the realism were selected. Figure 29 - Simulation banding scheme tree [CAE] As well in the ASAS software time-consuming functions were replaced with new optimized functions. External processes, mainly the traffic generator, were exported to ensure their functionality. The external data gathering was tested but not implemented because of the insufficient reliability. Therefore, the DGU data log parameters were reduced to a certain number for reasons of spare time saving and of reliability of the data. The final setting was a recording with 69 parameters and recording rate of 4 per second NUMBER OF OVERRUNS If the used time of the foreground processes is greater than one frame an overrun is detected. The impact on the simulation would be that some calculations of a lower priority could not be executed so that parameters for other functional elements could not be generated. Saving spare time was one possible solution. A new simulation host would increase the processing capabilities strongly, the introduction will be performed mid The spare time saving actions together with a new simulator configuration reduced the number of overruns to an acceptable minimum. This minimum is around 500 overruns per session. A fine tuning was realized by reducing the number of recording parameters so far that the number of overruns was within the limits. 71 of 92

72 7.1.4 TIME SYNCHRONIZATION OF SIMULATION ENVIRONMENT The first approach of synchronisation the distributed simulation environment was to use the time reference system IRIG-B as master clock. Several re-synchronisations during the simulation under the influence of overruns led to time jumps. An independent counter outside the critical band was able to count the completely calculated cycles of ASAS, but the result was a drifting between master clock and external time. This had to be compensated by time jumps. The result was spacing jumps (See Figure 30). Finally the counter of the simulation time was placed in the critical band of the simulator. This was tested during the FFS session and then implemented. The measure suppressed the time jumps, even in case of overruns. All damaged parts in the target history table had to be compensated by an additional logic. As result the spacing plot was without any greater jumps caused by the time reference. Figure 30 - Spacing jumps [EEC] TRAFFIC SIMULATION As already described before, GATS did not meet the specification of ASAS. The new traffic tool WSI replaced GATS (See chapter 4.10). The WSI tool running on an external platform is able to synchronize itself with the main simulation and transmits always a time-stamp to avoid any drifting of reference times in the distributed simulation environment. 72 of 92