{ "informationService": { "descriptionInformation": { "serviceDescriptionIdentification": { "serviceDescriptionTitle": "OpenATM Service Definition", "serviceDescriptionEdition": "0.6", "serviceDescriptionReferenceDate": "2020-06-23" }, "abbreviations": [ { "name": "AMQ", "description": "ActiveMQ" }, { "name": "AMQP", "description": "ActiveMQ Protocol" }, { "name": "ANSP", "description": "Air Navigation Service Provider" }, { "name": "ATM", "description": "Air Traffic Management" }, { "name": "ATSU", "description": "Air Traffic Service Unit" }, { "name": "AoI", "description": "Area of Interest" }, { "name": "AoR", "description": "Area of Responsibility" }, { "name": "ASPL", "description": "Abbreviated System Plan" }, { "name": "ATM", "description": "Air Traffic Management" }, { "name": "ATS", "description": "Air Traffic Services" }, { "name": "BER", "description": "Basic Encoding Rules" }, { "name": "BS", "description": "Basic Sector" }, { "name": "CC", "description": "Control Condition" }, { "name": "CFL", "description": "Cleared Flight Level" }, { "name": "COP", "description": "Coordination Point" }, { "name": "CWP", "description": "Controller Working Position" }, { "name": "DCT", "description": "Direct" }, { "name": "ECL", "description": "En-route Cruising Level" }, { "name": "EET", "description": "Estimated Elapsed Times" }, { "name": "ETO", "description": "Estimated Time-Over" }, { "name": "FDPS", "description": "Flight Data Processing System" }, { "name": "FPM", "description": "Flight Plan Monitoring" }, { "name": "FS", "description": "Flight Sector" }, { "name": "GUFI", "description": "Globally Unique Flight Identifier" }, { "name": "HDG", "description": "Heading" }, { "name": "JMS", "description": "Java Messaging System" }, { "name": "ICD", "description": "Interface Control Document" }, { "name": "LoA", "description": "Letter of Agreement" }, { "name": "MFX", "description": "Metering Fix" }, { "name": "MSB-CB", "description": "Maastricht Service Bus – Connector Box" }, { "name": "MTCD", "description": "Medium-Term Conflict Detection" }, { "name": "MUAC", "description": "Maastricht Upper Area Control Centre" }, { "name": "NFL", "description": "Entry Flight Level" }, { "name": "NSFL", "description": "Supplementary Entry Flight Level" }, { "name": "OPS", "description": "Operational Sector" }, { "name": "PER", "description": "Packed Encoding Rules" }, { "name": "PFL", "description": "Planned Flight Level" }, { "name": "RFL", "description": "Requested Flight Level" }, { "name": "RMP", "description": "Reliable Multicast Protocol" }, { "name": "ROCD", "description": "Rate of Climb/Descend" }, { "name": "SAC", "description": "System Area Code" }, { "name": "SAS", "description": "Shared ATS System" }, { "name": "SCL", "description": "Slovenia Control" }, { "name": "SIC", "description": "System Identification Code" }, { "name": "SFPL", "description": "System Flight Plan" }, { "name": "SOA", "description": "Service-Oriented Architecture" }, { "name": "STCA", "description": "Short-Term Conflict Alert" }, { "name": "SWIM", "description": "System Wide Information Management" }, { "name": "TFL", "description": "Transfer Flight Level" }, { "name": "TSFL", "description": "Supplementary Transfer Flight Level" }, { "name": "VRC", "description": "Vertical Rate of Climb" }, { "name": "XER", "description": "XML Encoding Rules" }, { "name": "XML", "description": "Extensible Markup Language" } ] }, "name": "OpenATM", "version": "1.0", "serviceAbstract": "The OpenATM service decouples the ATM data service provider (ADSPs) from the air traffic service units (ATSUs) through an open and standardised service interfaces to foster ADSP/ATSU cross-vendor interoperability. Its aim is to provide ATSUs with an interface that allows its own CWP working positions (or other systems that require ATM data as a service) to connect with a remotely located FDPS. The OpenATM service includes correlation, flight data distribution, flight data management, etc.", "serviceCategorisation": { "serviceType": "SERVICE_DEFINITION", "businessActivityType": [ "SERVICE_DELIVERY_MANAGEMENT" ], "informationCategory": [ "FLIGHT_INFORMATION_EXCHANGE" ], "intendedConsumer": [ "AIR_TRAFFIC_SERVICE_PROVIDER" ], "applicationMessageExchangePattern": [ "SYNCHRONOUS_REQUEST_REPLY", "PUBLISH_SUBSCRIBE_WITH_PUSH_MECHANISM" ], "geospatialCategorisation": { } }, "serviceProvision": { "provider": "Eurocontrol (MUAC) and potentially Slovenia Control in the future", "providerType": [ "AIR_TRAFFIC_SERVICE_PROVIDER" ], "pointOfContact": [ { "name": "Primary PoC - Kristof Schippers", "description": "For any additional information on this service definition, please contact ATM Data as a Service (ADaaS) in EUROCONTROL MUAC", "email": "kristof.schippers@eurocontrol.int" }, { "name": "Secondary PoC - Marko Hrastovec", "description": "For any additional information on this service definition, please contact ATM Data as a Service (ADaaS) in Slovenia Control", "email": "marko.hrastovec@sloveniacontrol.si" } ] }, "serviceGeneralDescription": { "operationalNeed": [ { "name": "Operational Needs", "description": "ADaaS (ATM Data as a Service) refers to the concept of building a cross-vendor interoperable system architecture, where air traffic service units (ATSUs) are decoupled from ATM data service providers (ADSPs) through open and standardised interfaces. The concept is built upon the principle that data is accessed and/or updated by multiple (remotely located) users while ensuring a single point for updates, and as such eliminates redundancy and streamlines costs by centralising data in one entity. It paves the way for further harmonisation in air traffic management and helps alleviate the de-fragmentation of the European network, as required by the Single European Sky. The key to such an approach is the utilisation of system-wide information management (SWIM) compliant data exchange protocols and open service oriented architecture (SOA) as vital elements, in order to facilitate the seamless integration of future applications." }, { "name": "Service Definition", "description": "In order to facilitate an accelerated development and deployment of the ADaaS concept, MUAC offers the OpenATM service definition describing an open service interface that can be implemented in various multi-vendor scenarios. The current operational MUAC FDPS-CWP interface has been used as a starting point; based on good engineering practices its implementation already accommodates an interface between a data centre and an OPS room using different technologies and manufactured by different suppliers. Additionally, its interface design rationale has not changed since its inception, but has proven in practice that a continuous and flexible extension of its payload contents is possible; thereby not only demonstrating the feasibility to define services, but also demonstrate its maturity and the many aspects needed for commissioning of such services (e.g. performance, safety, security, etc.)." }, { "name": "Information Exchange Requirements", "description": "The identification of the needs of the service is not based on Information Exchange Requirements (IER). See next section for an overview of the process being followed." }, { "name": "Service identification and modelling", "description": "Eurocontrol (MUAC) and potentially Slovenia Control in the future" } ], "functionality": [ { "name": "Subscription Management", "description": "allows service consumers to subscribe or unsubscribe to the distribution of a series of information areas.\r\nThe following information areas can be subscribed to: • flightplan-data, • sector-specific-data, • safety-net, • flightplan-monitoring, • datalink, • correlation, • heartbeat, • flight-bright, • mtcd-service, • system-information, • strategic-constraint, • sectorisation-data, • ssr-code, • meteo-data, • runway-info, • special-area, • map-data", "realWorldEffect": "Not applicable" }, { "name": "Data Distribution", "description": "ensures that each service consumer is provided with the latest up-to-date information relative to the subscribed information areas.", "realWorldEffect": "Not applicable" }, { "name": "Heartbeat Distribution", "description": "supports the service provider and the service consumer to monitor each other’s status.", "realWorldEffect": "Not applicable" }, { "name": "Management of Flight Plan Data", "description": "allows service consumers to provide the correct & latest up-to-date controller information, create, modifiy, udate ASPL or SFPL, Submit requests about instructions/clearances given to the flight crew (e.g. DCT, CFL, NFL, speed, heading, …), Change status information regarding the flight’s airframe (e.g. no FSSA, RVSM status, …), Etc.", "realWorldEffect": "Any instruction communicated to the pilot (either via voice or datalink) are expected to be executed by the aircrew. Furthermore, such information is communicated towards downstream partners and the network manager." }, { "name": "Management of Sector Specific Data", "description": "allows service consumers to provide the correct & latest up-to-date controller information regarding sector-specific information and coordination & transfer information, such as taking control of a flight (or proposing hand-over, request-on-frequency, etc.), Change the coordinated entry and exit levels, Deliver departure clearance for an flight departing from an internal aerodrome, Skip and cancel-skip of an internal sector, Bypass and cancel-bypass of the 1st downstream internal sector, Delegate the flight to another internal sector, Change the next downstream internal sector into the preferred one, Change the entry/exit frequency of sectors, Etc.", "realWorldEffect": "Upon communication of the SSR code to the aircrew, the aircraft transponder will emit that code. Furthermore, the present/next SSR codes allocated to the flight plan are communicated to downstream partners interested in the flight." }, { "name": "Management of Correlation", "description": "allows service consumers to provide inputs related to the linkage of flight plans with tracks, such as link a flight plan with and unlink a flight plan from a specific track, set the present, next or downstream SSR code a flight.", "realWorldEffect": "Correlation establishment, and the resulting identification of the current aircraft position related to the flight plan are communicated towards the network manager." }, { "name": "Management of Flight Bright", "description": "allows service consumers to provide inputs related to highlight of a track or flight plan, such as adding or removing SSR codes or Mode S callsigns to / from the Bright function for his OPS sector; adding or removing a Flight to / from the Bright function for his OPS sector;or another internal OPS Sector; point a flight to an external flight sector / centre", "realWorldEffect": "The management of flight bright does not have a real-world effect." }, { "name": "Management of Sectorisation", "description": "allows service consumers to perform a re-sectorisation change, such as verifying a new sectorisation change (would it be valid if performed), performing a sectorisation change.", "realWorldEffect": "Re-sectorisation changes in the configuration of the air traffic control unit result in the real-world effect that air traffic is handled in a more efficient way (in accordance with the flow of traffic)." }, { "name": "Management of SSR code", "description": "allows service consumers to reserve an SSR code for manual assignment later on (i.e. manual assignment by using the Operation setSsr, see section 3.7.4), and to clear such code from display in the whole OPS sector.\r\nAn SSR code reserved for manual assignment is not available for automatic assignment. The SSR code will be re-served during a design parameter time and then released if not manually assigned to any flight plan or released according to the standard release rules if manually assigned to a flight plan during this design parameter time.", "realWorldEffect": "The management of SSR code does not have a direct real-world effect. Its effect is reflected via the aforementioned management of correlation when the SSR code is communicated to the aircrew." } ], "qualityOfService": [ { "name": "Maximum time of Delivery", "description": "Maximum time of delivery depends on the service interface type: \r\n• All functions receiving or producing traffic or flight related data. All functions producing system warnings or system errors. Less than 350ms.\r\n• Functions sending and/or receiving management information and/or maps including cartographical and aeronautical data. Less than 500ms.\r\n• Functions sending and/or receiving statistical information and/or predicted airspace visual representations. Less than 1000ms." }, { "name": "Reliable messaging", "description": "Supported through configuration of Apache AMQ Broker." }, { "name": "Authentication", "description": "XYZ certificate used for mutual authentication." }, { "name": "Authorisation", "description": "Based on identities retrieved from XYZ certificates. Multiple clients per organization are authorized to consume the service at a given point in time. If a connection to the broker (rather than login request) is attempted by a client application while another one (from the same organization) is already established, the connection (or login request) will be refused." }, { "name": "Service Availability", "description": "The underlying infrastructure to accommodate the OpenATM service is developed for continuous operational use (24 hours per day, 7 days per week)." }, { "name": "Service Performance", "description": "Service restart time is required to be less than 5 minutes." }, { "name": "Subscription persistency", "description": "Organizations will be considered as subscribed to the service until:\r\n• a “logout” is performed,\r\n• a design parameter of number of heartbeats are missed from the consumer.\r\nUpon these events, the subscription will be terminated. The client is expected to re-subscribe at broker level upon broker subscription expiration." }, { "name": "Transport level integrity and confidentiality", "description": "Transport level integrity and confidentiality is achieved via IPsec (AES256)." }, { "name": "Message persistency", "description": "OpenATM service does not support message persistency. Consumers are ensured that latest available and up-to-date data is received." } ], "accessAndUseCondition": [ { "type": "SERVICE_POLICY", "name": "Access and Use Conditions have to be agreed", "description": "Usage and access conditions have to be agreed between the service provider and the service consumer. \r\nExample of restrictions in usage and access of the OpenATM service: Identified users are granted permission to access and use the OpenATM service according the Terms of Use, provided that:\r\n • they agree not to distribute any part of the delivered data received from the OpenATM service, without prior written authorization from the service provider.\r\n • they agree not to use the OpenATM service for any commercial use unrelated to ther service provider’s business interests without the prior written authorization of the service provider. o Prohibited commercial uses includes any of the following actions taken without the service provider’s express approval: o sale of access to the OpenATM service; o sale of the data delivered via the OpenATM service.\r\n • Prohibited commercial uses do not include any use that the service provider expressly authorizes in writing." } ], "concepts": [ { "name": "Initialisation & distribution of messages", "description": "As a general principle, the MSB-CB is the system instance that governs the initialisation towards the remote clients. The MUAC FDPS initialisation capabilities are thus de-coupled from the remote connecting clients. Initialisation is performed by requesting a full transmission of all data on a dedicated channel for the requestor only so as not to be disturbed by initialisations of other clients at the same time . The MSB-CB is arranging the initialisation, and the client is not expected to include any logic (e.g. sequence number checking). Whenever a client subscribes to an interface, the internal flight plan data store is copied and all required data messages (supported by the requested interface(s)) for the initialisation are then emitted towards the client. Any update which is arriving in the meantime is distributed instantaneously to the up-and-running clients (i.e. the ones not initialising), while the updates for initialising clients are buffered until all initialisation data has been sent. After the initialisation is completed, the buffered updates are sent. For the updates, there are two types of data distribution: cyclic updates and updates on create/update/cancel for the non-cyclic distribution. It’s important to note that as a general principle, the majority of the data is sent only when changed (i.e. only the “delta” with respect to the previous message of the same type is distributed)." } ], "validation": [ { "type": "COLLABORATIVE_VALIDATION", "description": "The Maastricht Upper Area Control Centre (MUAC) established in 2013 the Shared ATS System (SAS), where a virtual centre network solution has been put into operational use, with one air navigation service provider offering shared ATM data services for the benefit of another ATSU in the core area of Europe. With the Shared ATS System the safety, efficiency and cost-effectiveness of a data service solution has been proven.\r\n\r\nThe ADaaS Demonstrator, designed and developed in cooperation between MUAC and Slovenia Control, is composed of 3 phases: \r\n• Phase 1: An ATM infrastructure is setup between MUAC and Slovenia Control where MUAC Controller Working Positions (CWP) installed in Slovenia Control are remotely connected to an FDPS instance in MUAC. The communication between the MUAC FDPS and CWPs is using the legacy interface. It is currently implemented and successful shadow operations have been conducted in June 2016. \r\n• Phase2: The interface between FDPS and CWP is changed to an open interface and the Slovenia Control CWP is connected to the MUAC FDPS via this interface. The OpenCWP interface decouples the ATM data service provider (ADSPs) from the air traffic service units (ATSUs) through an open and standardised service interfaces to foster ADSP/ATSU cross-vendor interoperability. Services include correlation, flight data distribution, flight data management, etc. and has been successfully demonstrated in shadow operations in February 2017. \r\n• Phase 3: The distributed architecture that allows remotely located data service providers to be completely synchronised is established. The identified solution(s) within the Target ADaaS Architecture have been experimentally established, in order to validate the assumptions and uncertainties of such architecture. Its feasibility has been demonstrated in shadow operations in November 2017" } ] }, "serviceInformationDescription": { "informationDefinition": [ { "name": "Information Definition", "description": "The information definition is described in section 4 Exchanged Information of the specification document (see SERVICE_SPECIFICATION in service documents). The AIRM semantic correspondence is established in a separate document (see AIRM_TRACE in service documents).", "airmConformant": true, "airmVersion": "4.1.0" } ], "exchangeSchema": [ { "name": "Schema", "reference": "In order to define the messages, the ASN.1 definition language is used as a formal notation to define the OpenATM interface. For the OpenATM service, usage can be be made of the XER encoding (XML message format) and BER encoding. The usage of either message format is supported and can be either switched by using a configuration file, or alternatively by starting another CWP server process). The ASN.1 and XSD definition files are available in service documents. More information on XER and BER encoding is avaialble in the information definition.", "schemaLanguage": "ASN.1/XML" } ] }, "serviceTechnicalDescription": { "technicalConstraint": [ { "name": "running at the service consumer site", "description": "The service instance is expected to be running at the service consumer site in a fully secure environment.Other possible constraints would be part of a service level agreement to be established and agreed between the service provider and the service consumer." }, { "name": "Time Synchronization based on NTP", "description": "Service provider and consumer remain time-synchronized via NTP with their own time servers." } ], "securityMechanism": [ { "name": "Network security based on Virtual Private Network (VPN)", "description": "Private VPN can be established with SLA agreement with network provider", "type": [ "INTEGRITY", "CONFIDENTIALITY" ] }, { "name": "Network security based on IPSec tunnelling", "description": "IPSec tunnelling can be established over the internet", "type": [ "INTEGRITY", "CONFIDENTIALITY" ] }, { "name": "Application level authentication", "description": "Authentication performed at application level", "type": [ "AUTHENTICATION" ] } ], "serviceMonitoring": { "monitoringDescription": "See HeartbeatDistribution Interface." } }, "serviceInterface": [ { "name": "SubscriptionManagement", "description": "The following section provides further details on the general (un)subscription mechanism, as introduced in the section on “Initialisation & distribution of messages”. The mechanism guarantees that any connecting client receives the correct & latest up-to-date information for the service(s) it subscribes to. Additionally, it provides the means to unsubscribe to services. All services implemented on the MSB-CB are distributed over a dedicated Process Queue (i.e. 1 queue per connected client). On the queue, only those messages related to the requested services are distributed. This is done to allow connecting clients to choose whichever service they want, and limit the amount of data traversed over the network. The initialisation service is implemented by means of the following message: \r\n • RequestLogin message (client requests subscription and initialisation to the MSB-CB for one or more services) \r\n • RequestLogout message (client requests to unsubscribe from all services)", "interfaceProvisionSide": "PROVIDER_SIDE_INTERFACE", "tiPrimitiveMessageExchangePattern": "SYNCHRONOUS_REQUEST_RESPONSE", "serviceInterfaceBinding": "SWIM_TI_YP_1_0_AMQP_MESSAGING", "networkInterfaceBinding": "IPV4_UNICAST", "interfaceBindingDescription": "AMQP 1.0 content-type header used to specify media type values", "operation": [ { "name": "login", "description": "The operation allows to:\n\u2022\tRequest client subscription and initialisation for one or more services,\n\u2022\tUnsubscribe to one or more services.\n", "operationMessage": [ { "direction": "IN", "name": "RequestLogin message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "logout", "description": "The operation allows requesting the un-subscription from all services.\n", "operationMessage": [ { "direction": "IN", "name": "RequestLogout message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] } ], "behaviour": [ { "name": "service behaviour", "description": "The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents)." } ] }, { "name": "DataDistribution", "description": "TBD", "interfaceProvisionSide": "CONSUMER_SIDE_INTERFACE", "tiPrimitiveMessageExchangePattern": "FIRE_AND_FORGET", "serviceInterfaceBinding": "SWIM_TI_YP_1_0_AMQP_MESSAGING", "networkInterfaceBinding": "IPV4_UNICAST", "interfaceBindingDescription": "AMQP 1.0 content-type header used to specify media type values", "operation": [ { "name": "distributeFlightPlanData ", "description": "The flight plan data distribution ensures that each client is provided with the latest up-to-date flight plan information detailing the fol-lowing information:\n\u2022\tGeneral flight plan information\n\u2022\tClearances\n\u2022\t4D-Trajectory\n\u2022\tAirspace crossing & sector sequence information\n\u2022\tEntry & Exit coordination data for the current leg\n\u2022\tCurrent (under-control or first) and next sector conditions\n\u2022\tBasic correlation information\nNote that the current implementation of the service only includes the coordination information related to the current leg . Downstream leg information may be provided at the same time by another service or by extending the definition of the current data type (see section Error! Reference source not found.), but this is considered out-of-scope of the ADaaS project. For the 4D-Trajectory, airspace crossing and sector sequence information, the complete flight within the considered system\u2019s AoI will be covered.\n", "operationMessage": [ { "direction": "IN", "name": "FlightPlanDataMessage" } ] }, { "name": "distributeSectorSpecificData", "description": "The SectorSpecific data distribution ensures that each client is provided with the latest up-to-date OPS sector-specific information for a flight detailing the following information:\n\u2022\tSector status (normal, skipped, bypassed, etc.)\n\u2022\tEntry, Internal & Exit coordination data for the OPS sector for which information is distributed. \n\u2022\tIntra-sector dialogue information\n\u2022\tEvent trigger information (for display purposes) for the OPS sector t\nImportant: the service will emit all sector-specific data for all flights over the service. It is the clients responsibility to filter out the relevant messages for him. The rationale of using such an approach is that it allows the usage of topics (multicast) at a later stage in the project without changing the client side functionality.\n", "operationMessage": [ { "direction": "IN", "name": "SectorSpecificDataMessage" } ] }, { "name": "distributeFlightPlanMonitoring", "description": "This service provides all subscribed clients with all detected deviations (Lateral, Vertical and Longitudinal) between the trajectories cleared data and the track. Additionally, it provides an automatic re-routing proposal when available.\nThe service is implemented by means of the FpmMessage. Conformance monitoring information is only provided for SFPLs, which are under-control and not in MANUAL sub-state. Re-routing information may already be received for SFPLs, which have been coordi-nated at entry (e.g. ACT received at the server, or manual coordination performed) and are not yet-under-control of the local centre.\n", "operationMessage": [ { "direction": "IN", "name": "FlightPlanMonitoringMessage" } ] }, { "name": "distributeCorrelation ", "description": "This service provides all subscribed clients with all detected deviations (Lateral, Vertical and Longitudinal) between the trajectories cleared data and the track. Additionally, it provides an automatic re-routing proposal when available.\nThe service is implemented by means of the FpmMessage. Conformance monitoring information is only provided for SFPLs, which are under-control and not in MANUAL sub-state. Re-routing information may already be received for SFPLs, which have been coordi-nated at entry (e.g. ACT received at the server, or manual coordination performed) and are not yet-under-control of the local centre.\n\n", "operationMessage": [ { "direction": "IN", "name": "CorrelationMessage" } ] }, { "name": "distributeFlightBright", "description": "The flight bright distribution service provides the means to highlight a flight within for the own OPS sector based on SSR Code(s) \u201cSSR Bright\u201d and/or ModeS callsign(s) \u201cModeS bright\u201d, and within own or to other OPS sectors (internal/external) based on callsign(s) \u201cflightplan bright\u201d.\nThe service is implemented by means of the FlightBrightMessage. The message is distributed to the own OPS sector (case of bright for SSR code, ModeS code, or flightplan bright for the own OPS sector) or to another OPS sector (case of flightplan bright to another OPS sector); in other words message distribution is \u201cOPS sector oriented\u201d.\nAt initialisation, actual bright information for the OPS sector is distributed. Per OPS sector there can be a maximum of 20 requests for flight bright.\n\n", "operationMessage": [ { "direction": "IN", "name": "FlightBrightMessage" } ] }, { "name": "distributeSectorisation", "description": "The sectorisation distribution service ensures that each client is provided with the latest up-to-date sectorisation information residing at the server. Basically, the following information is distributed:\n\u2022\tSectorisation pattern: contains the sectorisation pattern (i.e. unique identifier for each sectorisation) selected for each sector group.\n\u2022\tSector composition: composition contains the list of airspace volumes and basic sectors composing each flight sector (see section Error! Reference source not found. for more information on the concept).\n\u2022\tSector consolidation: contains the list of flight sectors consolidated into each OPS sector (see section Error! Reference source not found. for more information on the concept).\n\u2022\tSector allocation: contains the list of flight sectors allocated to each internal/external centre.\n", "operationMessage": [ { "direction": "IN", "name": "SectorisationMessage" } ] }, { "name": "distributeSsrCode", "description": "The service provides the OPS sector with the information related to reservation of a free manual-assignable SSR code sequence described in section Error! Reference source not found..\nThe service is implemented by means of the SsrCodeMessage. The message is distributed to the own OPS sector only.\n", "operationMessage": [ { "direction": "IN", "name": "SsrCodeMessage" } ] }, { "name": "distributeWindForecast", "description": "The meteorological information distribution service aims to provide all operational sectors with the latest:\n\u2022\tWind & temperature forecast information extracted from the external world for a range of different levels,\n\u2022\tAirport related meteorological information received from the external world from the following sources:\no\tMETAR and METAR COR\no\tSPECI and SPECI COR\n\u2022\tQNH, transition level and transition altitude information for airports\n\nThis service is implemented by means of two messages:\n\u2022\tWindForecastMessage, containing the wind & temperature forecast information.\n\u2022\tAirportMeteoMessage, containing the airport related infor-mation.\n", "operationMessage": [ { "direction": "IN", "name": "WindForecastMessage" } ] }, { "name": "distributeMap", "description": "The map distribution service aims to provide requesting clients with the latest information of map data. A distinction is made between static, semi-dynamic and dynamic maps:\n\u2022\tStatic: It is defined offline, and their contours cannot be modified on-line. Textual elements and/or other display elements may be modified.\n\u2022\tSemi-dynamic: It is defined offline, and their contours can be modified on-line. Textual elements and/or other display elements may be modified.\n\u2022\tDynamic: They are created on-line. All of their contents may be modified.\n", "operationMessage": [ { "direction": "IN", "name": "MapMessage" } ] }, { "name": "distributeSystemMode", "description": "The system mode distribution service provides to all connected & subscribed clients the following FDPS system information:\n\u2022\tSystem: Primary or Fallback\n\u2022\tSystem mode: Operational or Test mode\n\u2022\tSystem sub-mode: Authorised or unauthorised\n\u2022\tLink status: ON or OFF (link between Primary and Fallback)\n\u2022\tMTCD Status: ON or OFF\n\u2022\tMTCD Time Horizon\n\u2022\tFDPS degradation level\n\u2022\tFDPS SW and adaptation data version\nFDPS coordinate projection parameters\n", "operationMessage": [ { "direction": "IN", "name": "SystemModeMessage" } ] }, { "name": "distributeSpecialArea", "description": "The special area distribution service provides all subscribed clients with the latest status of all special areas (e.g. TSA, TRA, etc.) residing at the server side. For each area the following information is provided:\n\u2022\tAirspace status:\no\tpre-warning (pending to be active within 15 minutes) \no\tactive\no\tinactive\n\u2022\tOperation Mode:\no\tManual (i.e. the special area activation/de-activation is triggered by manual supervisor action)\no\tScheduled (i.e. the special area activation/de-activation is triggered automatically by following an activation/de-activation schedule)\n\u2022\tThe applicable lower and upper level related to the special area activation \n\u2022\tThe start and end time related to the special area activation.\n\u2022\tIn case of booking via LARA, additional LARA booking information, being:\no\tUnique LARA reservation identifier\no\tLARA activation status\no\tList of callsigns involved in the mission\no\tMission type\no\tPermeable or non-permeable indicator\n", "operationMessage": [ { "direction": "IN", "name": "SpecialAreaMessage" } ] } ], "behaviour": [ { "name": "service behaviour", "description": "The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents)." } ] }, { "name": "HeartbeatDistribution", "description": "\n \n", "interfaceProvisionSide": "CONSUMER_SIDE_INTERFACE", "tiPrimitiveMessageExchangePattern": "FIRE_AND_FORGET", "serviceInterfaceBinding": "SWIM_TI_YP_1_0_AMQP_MESSAGING", "networkInterfaceBinding": "IPV4_UNICAST", "interfaceBindingDescription": "AMQP 1.0 content-type header used to specify media type values", "operation": [ { "name": "distributeHeartbeat", "description": "The Hearbeat distribution supports the service provider and the service consumer to monitor each other\u2019s status.\n", "operationMessage": [ { "direction": "IN", "name": "HeartbeatMessage (full message)" }, { "direction": "OUT", "name": "HeartbeatMessage (header only)" } ] } ], "behaviour": [ { "name": "service behaviour", "description": "The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents)." } ] }, { "name": "FlightPlanDataManagement", "description": "The Flight Plan Data Management service supports any connecting CWP client to send certain inputs in order to trigger the correct & latest up-to-date controller information, more specifically:\n\u2022\tCreate ASPL or SFPL,\n\u2022\tModify an ASPL/SFPL or upgrade an SFPL,\n\u2022\tDowngrade an SFPL into an ASPL,\n\u2022\tDelete an existing ASPL/SFPL,\n\u2022\tSubmit requests about instructions/clearances given to the flight crew (e.g. DCT, CFL, NFL, speed, heading, \u2026)\n\u2022\tChange status information regarding the flight\u2019s airframe (e.g. no FSSA, RVSM status, \u2026)\n\u2022\tEtc.\nWhen an input is made and successfully processed the response to the request is delivered in two parts:\n\u2022\tEach input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input.\n\u2022\tSecondly, provided the input was accepted, the updated information (as delivered by the Flight Plan Distribution service) on the flight is sent. As such, subscription to the Flight Plan Distribution service is mandatory prior the user requesting flight data modifications.\n\n\n \n\n", "interfaceProvisionSide": "PROVIDER_SIDE_INTERFACE", "tiPrimitiveMessageExchangePattern": "SYNCHRONOUS_REQUEST_RESPONSE", "serviceInterfaceBinding": "SWIM_TI_YP_1_0_AMQP_MESSAGING", "networkInterfaceBinding": "IPV4_UNICAST", "interfaceBindingDescription": "AMQP 1.0 content-type header used to specify media type values", "operation": [ { "name": "createModifyFPL", "description": "The operation allows to:\n\u2022\tCreate ASPL or SFPL,\n\u2022\tModify an ASPL/SFPL,\n\u2022\tUpgrade an ASPL into SFPL,\n\u2022\tDowngrade an SFPL into an ASPL.\n", "operationMessage": [ { "direction": "IN", "name": "RequestCreateModifyFPL message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "changeAcStatus", "description": "The operation allows modifying:\n\u2022\tnumber of aircraft related to a flight plan\n\u2022\taircraft type\n\u2022\tflight\u2019s wake-turbulence category\n\u2022\tflight\u2019s deviation status\n\u2022\tRVSM capability\n\u2022\t8.33 kHz capability\n\u2022\tUHF equipment\n\u2022\tBRNAV/PRNAV equipment\n\u2022\tModeS capability\n\u2022\tNumber of people on board\n\u2022\tFSSA capability\n\u2022\tAvoiding weather indicator\n\u2022\tFuel dumping indicator\n", "operationMessage": [ { "direction": "IN", "name": "RequestChangeAcStatus message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "changeCallsign", "description": "The operation allows to:\n\u2022\tModify the callsign of an existing ASPL or SFPL.\n", "operationMessage": [ { "direction": "IN", "name": "RequestChangeCallsign message" }, { "direction": "OUT", "name": "\tAcknowledgementMessage" } ] }, { "name": "deleteFPL", "description": "The operation allows to manually deleting an existing ASPL or SFPL from the system.\n", "operationMessage": [ { "direction": "IN", "name": "RequestDeleteFPL message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "retrieveFlight", "description": "The operation allows retrieving manually the flight plan data (Flight Plan Data Message) for an existing ASPL or SFPL from the system.\n", "operationMessage": [ { "direction": "IN", "name": "RequestRetrieveFlight message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "manageDCT", "description": "From an operational perspective, a DCT action can represent multiple cases. The interface definition has been considered to fulfil the op-erational scenarios listed below. For completeness reasons the required options to be passed in the RequestDCT input are given below:\n\u2022\tDCT to a (intermediate) Point\no\tto\nAllows the sending of a single route point name (or coordinate) with optional intermediate point. In this case, the MSB-CB will automatically determine the most likely type of DCT instruction given (i.e. make the distinction between \u201cto-original-route\u201d and \u201cto-trajectory\u201d as given below). From an interface and client implementation perspective this option allows to perform DCT actions without the requirement for the client to reference to index in the trajectory. Also, this option allows also performing a DCT instruction for an ASPL for which no trajectory is available.\n\u2022\tDCT to Point on the Trajectory (Uplink = UM74)\no\tto-trajectory\n\uf0a7\tintermediate-point not sent\n\uf0a7\tend-point represents the index point and posi-tion in the trajectory\n\u2022\tDCT to Point on the Original Route (Uplink = UM74 + UM72)\no\tto-original-route\n\uf0a7\tintermediate-point not sent\n\uf0a7\tend-point represents the point name (located on the original route)\n\u2022\tDCT to (Intermediate) Point not located on the trajectory; in this case the end-point is on the trajectory (Uplink = UM79: \"CLEARED TO [end-point] VIA [intermediate-point])\no\tto-trajectory\n\uf0a7\tintermediate-point represents the route point name or position of the intermediate point\n\uf0a7\tend-point represents the index point and posi-tion in the trajectory\n\u2022\tDCT to (Intermediate) Point not located on the trajectory; in this case the end-point is on the original route (Uplink = UM79: \"CLEARED TO [end-point] VIA [intermediate-point] + UM72)\no\tto-original-route\n\uf0a7\tintermediate-point represents the route point name or position of the intermediate point\n\uf0a7\tend-point represents the point name (located on the original route)\n\u2022\tDCT to (Intermediate) Point not located on the trajectory, and no end-point specified. In this case, the DCT is considered to be a point completely off-route, which is not to be rejoined. A typical example is a DCT to a point outside the AoI, which is not located on the trajectory (Uplink = UM74).\no\tto-trajectory\n\uf0a7\tintermediate-point represents the route point name or position of the intermediate point\n\uf0a7\tend-point represents the null index point\t\nNote 1: A current heading restriction will be removed upon receiving a DCT input.\nNote 2: For ASPLs, a DCT to an Intermediate OR End Point is allowed (with whatever DctData option) provided any reference to a trajectory point is populated with the null-TrajectoryPointNumber. Inputs combining both Intermediate AND End Point will not be processed.\n", "operationMessage": [ { "direction": "IN", "name": "RequestDCT message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "changeRoute", "description": "From an operational perspective, a change route action represents a re-routing of the flight across multiple waypoints (unlike a DCT where the flight is instructed to go to only one waypoint).\nNote 1: A current heading restriction will be removed upon receiving Operation changeRoute.\nNote 2: Only available for SFPLs.\n", "operationMessage": [ { "direction": "IN", "name": "RequestChangeRoute message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "manageHeading", "description": "The interface definition has been compiled taking into account the operational cases listed below. For completeness reasons the possible parameters, for such situations, to be passed in the RequestHeading input are indicated as well:\n\u2022\tPresent Heading (uplink possible)\n\u2022\tAssigned Heading \u2013 relative or absolute true/magnetic heading (uplink possible)\n\u2022\tNon-specified Heading; use track direction as heading and update trajectory with this value (no uplink possible)\n\u2022\tHeading to avoid weather, for example CBs; use track direction as heading an generate an observed tactical trajectory with it (no uplink possible)\nIn the first three cases above, the type of heading closure is mandatory in the request. The following cases have been distinguished in case the application limit and trajectory resuming point are included in the request:\n\u2022\tNo application limit and rejoining point specified in the input: a default application limit will be applied and the trajectory will be closed based on pre-defined closure rules.\n\u2022\tApplication limit specified as distance and rejoining point present in the request: the specified distance and rejoining-point will be applied.\n\u2022\tApplication limit specified as \u201cIndefinite\u201d: the system will auto-close the trajectory at AoR exit.\nIn all cases, the input heading is considered as magnetic heading.\n\n", "operationMessage": [ { "direction": "IN", "name": "RequestHeading message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "manageXheading", "description": "The command allows resetting a previous heading instruction for ASPLs only. In case the command is requested for an SFPL, the result will be returned with an error.\n", "operationMessage": [ { "direction": "IN", "name": "RequestXheading message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "manageCFL", "description": "To process the input of a cleared flight level, with application time/distance and/or ROCD restriction.\n", "operationMessage": [ { "direction": "IN", "name": "RequestCFL message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "manageECL", "description": "To process the input of an enroute cruising level. The ECL is applied until the exit of the AoI (i.e. propagated all the way), unless the ap-plication-limit is present in the request.\n", "operationMessage": [ { "direction": "IN", "name": "RequestECL message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "manageRFL", "description": "To process the input of a requested flightlevel as requested by the pilot or filed by the airline company.\n", "operationMessage": [ { "direction": "IN", "name": "RequestRFL message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "managePFL", "description": "To process the input of a planned flight level (PFL). The PFL is best described as an ECL, but only applied until the requesting sector\u2019s exit.\n", "operationMessage": [ { "direction": "IN", "name": "RequestPFL message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "manageSpeed", "description": "The interface definition has been compiled taking into account the operational cases listed below: \n\u2022\tPresent speed (uplink possible)\n\u2022\tAssigned speed, including route point until where the speed restriction should apply (uplink possible)\n\u2022\tSpeed range, including route point until where the speed re-striction should apply (between a lower and upper speed)\n\u2022\tMinimum or Maximum speed instruction, including route point until where the speed restriction should apply (uplink possible)\n\u2022\tKeyword, to represent a pure textual speed instruction to the ATCO (e.g. CLEAN speed) without affecting the flight\u2019s calculat-ed profile\n\u2022\tResume speed, to cancel any previous speed restriction (uplink possible)\n", "operationMessage": [ { "direction": "IN", "name": "RequestSpeed message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] } ], "behaviour": [ { "name": "service behaviour", "description": "The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents)." } ] }, { "name": "SectorSpecificDataManagement", "description": "The Sector Specific Data Management service supports any connecting CWP client to send certain inputs in order to trigger the correct & latest up-to-date controller information regarding sector-specific information and coordination & transfer information, more specifically:\n\u2022\tAllow taking control of a flight (or proposing hand-over, request-on-frequency, etc.),\n\u2022\tChange the coordinated entry and exit levels,\n\u2022\tDeliver departure clearance for an flight departing from an internal aerodrome,\n\u2022\tSkip and cancel-skip of an internal sector,\n\u2022\tBypass and cancel-bypass of the 1st downstream internal sector,\n\u2022\tDelegate the flight to another internal sector,\n\u2022\tChange the next downstream internal sector into the preferred one,\n\u2022\tChange the entry/exit frequency of sectors,\n\u2022\tEtc.\nWhen an input is made and successfully processed the response to the request is delivered in two parts:\n\u2022\tEach input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input.\n\u2022\tSecondly, provided the input was accepted, the updated information (as delivered by the Flight Plan Data Distribution & Sector Specific Data Distribution service) on the flight is sent. As such, subscription to the both aforementioned services is mandatory prior the user requesting sector specific data modifications.\n\n \n", "interfaceProvisionSide": "PROVIDER_SIDE_INTERFACE", "tiPrimitiveMessageExchangePattern": "SYNCHRONOUS_REQUEST_RESPONSE", "serviceInterfaceBinding": "SWIM_TI_YP_1_0_AMQP_MESSAGING", "networkInterfaceBinding": "IPV4_UNICAST", "interfaceBindingDescription": "AMQP 1.0 content-type header used to specify media type values", "operation": [ { "name": "manageControl", "description": "To process the input of a control input command, to allow either:\n\u2022\tTake control of the flight,\n\u2022\tTransfer control of the flight,\n\u2022\tDelegate control of the flight to the sector where the flight is geographically located,\n\u2022\tHand-over propose/accept.\n", "operationMessage": [ { "direction": "IN", "name": "RequestControl message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "manageNFL", "description": "To process the input of an entry flightlevel for the coordination between internal sectors or with the external upstream partner. \n", "operationMessage": [ { "direction": "IN", "name": "RequestNFL message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "manageTFL", "description": "To process the input of a transfer flightlevel for the coordination between internal sectors or with the external downstream partner.\n", "operationMessage": [ { "direction": "IN", "name": "RequestTFL message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "changeSectors", "description": "The operation allows to:\n\u2022\tSkip and cancel-skip of an internal sector,\n\u2022\tBypass and cancel-bypass of the 1st downstream internal sector,\n\u2022\tDelegate the flight to another internal sector,\n\u2022\tChange the next downstream internal sector into the pre-ferred one.\n", "operationMessage": [ { "direction": "IN", "name": "RequestChangeSectors message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "changeEntryCoordination", "description": "The operation allows performing coordination changes related to the entry of the sector performing the request. The operation applies to both internal and external entry coordination.\nChanges to the following items can be requested, or negotiated:\n\u2022\tNFL & NSFL (as also possible with requestNFL \u2013 see section 3.6.4)\n\u2022\tDeparture level (indicates the initial cleared level for departure flights out of an internal aerodrome)\n\u2022\tETO (Estimated Time Over)\n\u2022\tCOP (Coordination Point)\n\u2022\tPSSR (Present SSR Code)\n\u2022\tDCT-to point (including intermediate point if required)\n\u2022\tAccepting Frequency\n\u2022\tSpeed\n\u2022\tHeading\n", "operationMessage": [ { "direction": "IN", "name": "RequestEntryCoordination message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "changeExitCoordination", "description": "The operation allows performing coordination changes related to the exit of the sector performing the request. The operation applies to both internal and external exit coordination.\nChanges to the following items can be requested, or negotiated:\n\u2022\tTFL & TSFL (as also possible with requestTFL \u2013 see section 3.6.5)\n\u2022\tETO (Estimated Time Over)\n\u2022\tCOP (Coordination Point)\n\u2022\tPSSR (Present SSR Code)\n\u2022\tDCT-to point (including intermediate point if required)\n\u2022\tTransferring Frequency\n\u2022\tSpeed\n\u2022\tHeading\n", "operationMessage": [ { "direction": "IN", "name": "RequestExitCoordination message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "manageDepartureClearance", "description": "The operation allows performing a departure clearance (for a flight departing from an internal aerodrome). For example, a TWR sector can perform this action, or eventually a higher sector that has to deliver the departure clearance.\nItems available in the departure clearance are kept limited for the first phase and include:\n\u2022\tDeparture level (indicates the initial cleared level for departure flights out of an internal aerodrome)\n\u2022\tTake-off time\n\u2022\tPSSR (Present SSR Code)\n\u2022\tAccepting Frequency\n\u2022\tSID\n\u2022\tDeparture runway\n", "operationMessage": [ { "direction": "IN", "name": "RequestDepartureClearance message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "changeFreq", "description": "The operation allows an OPS sector:\n\u2022\tTo select the frequency to be sent to the transferring previ-ous adjacent center or internal sector,\n\u2022\tTo select the default for the frequency to be sent to the transferring previous adjacent center or internal sector,\n\u2022\tTo change the exit frequency with the next partner or internal sector,\n\u2022\tTo reset the exit frequency.\n", "operationMessage": [ { "direction": "IN", "name": "RequestChangeFreq message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] } ], "behaviour": [ { "name": "service behaviour", "description": "The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents)." } ] }, { "name": "CorrelationManagement", "description": "The Correlation Management service allows any connecting CWP client to perform inputs related to the linkage or unlinkage of flight plans with tracks, more specifically:\n\u2022\tLink a flight plan with a specific track,\n\u2022\tUnlink a flight plan from a specific track,\n\u2022\tSet the present, next or downstream SSR code a flight.\nWhen an input is made and successfully processed the response to the request is delivered in two parts:\n\u2022\tEach input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input.\n\u2022\tSecondly, provided the input was accepted, the updated information (as delivered by the Flight Plan Distribution service) on the flight is sent. As such, subscription to the flight plan distribution service is mandatory prior the user requesting flight data modifications. Additionally, if the user is subscribed to the Correlation Distribution service, extended correlation information will be sent.\n\n \n", "interfaceProvisionSide": "PROVIDER_SIDE_INTERFACE", "tiPrimitiveMessageExchangePattern": "SYNCHRONOUS_REQUEST_RESPONSE", "serviceInterfaceBinding": "SWIM_TI_YP_1_0_AMQP_MESSAGING", "networkInterfaceBinding": "IPV4_UNICAST", "interfaceBindingDescription": "AMQP 1.0 content-type header used to specify media type values", "operation": [ { "name": "linkWithTrack", "description": "To process the input of a manual linkage/unlinkage request of a flight plan with a track.\n", "operationMessage": [ { "direction": "IN", "name": "RequestLink message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] }, { "name": "setSsr", "description": "To process the input of setting the present, next or downstream SSR code of a flight plan.\n", "operationMessage": [ { "direction": "IN", "name": "RequestSetSsr message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] } ], "behaviour": [ { "name": "service behaviour", "description": "The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents)." } ] }, { "name": "FlightBrightManagement", "description": "The Flight Bright Management service allows any connecting CWP client to perform inputs related to highlight of a track or flight plan, more specifically:\n\u2022\tSSR Bright:\no\tAdd an SSR Code to the SSR Bright function for his OPS sector\no\tCancel all SSR Codes from the SSR Bright function for his OPS sector\no\tDelete one SSR Code from the SSR Bright function for his OPS sector\n\n\u2022\tModeS Bright:\no\tAdd an ModeS callsign to the ModeS Bright function for his OPS sector\no\tCancel all ModeS callsign from the ModeS Bright function for his OPS sector\no\tDelete one ModeS callsign from the ModeS Bright function for his OPS sector\n\n\u2022\tFPL Bright:\no\tAdd a flight to the FPL Bright function for his OPS sector\no\tDelete a flight from the FPL Bright function for his OPS sector\no\tAdd a flight to the FPL Bright function of another internal OPS Sector (by specifying an internal flight sector)\no\tPoint a flight to an external flight sector / centre\n\nWhen an input is made and successfully processed the response to the request is delivered in two parts:\n\u2022\tEach input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input.\n\u2022\tSecondly, provided the input was accepted, the updated information (as delivered by the Flight Bright Distribution service) on the flight is sent. As such, subscription to the Flight Bright distribution service is mandatory prior the user requesting modifications. Please do note that the distribution of the FlightBright message is OPS sector oriented.\n\n \n", "interfaceProvisionSide": "PROVIDER_SIDE_INTERFACE", "tiPrimitiveMessageExchangePattern": "SYNCHRONOUS_REQUEST_RESPONSE", "serviceInterfaceBinding": "SWIM_TI_YP_1_0_AMQP_MESSAGING", "networkInterfaceBinding": "IPV4_UNICAST", "interfaceBindingDescription": "AMQP 1.0 content-type header used to specify media type values", "operation": [ { "name": "manageFlightBright", "description": "To process the input of a manual SSR Code track bright, ModeS track bright or flight plan bright.\n", "operationMessage": [ { "direction": "IN", "name": "RequestFlightBright message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] } ], "behaviour": [ { "name": "service behaviour", "description": "The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents)." } ] }, { "name": "SectorisationManagement", "description": "The sectorisation management service provides any connecting client with the means to perform a re-sectorisation change. Two kind of requests can be made, being:\n\u2022\tA request to verify a new sectorisation change (i.e. would the request once executed be valid for the server?),\n\u2022\tA request to perform a sectorisation change.\n\nWhen an input is made and successfully processed the response to the request is delivered in two parts:\n\u2022\tEach input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input.\n\u2022\tSecondly, provided the input was accepted, the updated information (as delivered by the Sectorisation Distribution service) is sent. As such, subscription to the Sectorisation distribution service is mandatory prior the user requesting sectorisation modifications. \n\n \n", "interfaceProvisionSide": "PROVIDER_SIDE_INTERFACE", "tiPrimitiveMessageExchangePattern": "SYNCHRONOUS_REQUEST_RESPONSE", "serviceInterfaceBinding": "SWIM_TI_YP_1_0_AMQP_MESSAGING", "networkInterfaceBinding": "IPV4_UNICAST", "interfaceBindingDescription": "AMQP 1.0 content-type header used to specify media type values", "operation": [ { "name": "changeSectorisation", "description": "To process the input of a manual sectorisation request.\n", "operationMessage": [ { "direction": "IN", "name": "RequestChangeSectorisation message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] } ], "behaviour": [ { "name": "service behaviour", "description": "The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents)." } ] }, { "name": "SsrCodeManagement", "description": "The SSR code management service allows a client to reserve an SSR code for manual assignment later on (i.e. manual assignment by using the Operation setSsr service call), and to clear such code from display in the whole OPS sector.An SSR code reserved for manual assignment is not available for automatic assignment. The SSR code will be reserved during a design parameter time and then released if not manually assigned to any flight plan or released according to the standard release rules if manually assigned to a flight plan during this design parameter time. When an input is made and successfully processed the response to the request is delivered in two parts: \r\n• Each input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input. \r\n• Secondly, provided the input was accepted, the updated information (as delivered by the SsrCode Distribution service) is sent. As such, subscription to the SsrCode distribution service is mandatory prior the user requesting modifications.", "interfaceProvisionSide": "PROVIDER_SIDE_INTERFACE", "tiPrimitiveMessageExchangePattern": "SYNCHRONOUS_REQUEST_RESPONSE", "serviceInterfaceBinding": "SWIM_TI_YP_1_0_AMQP_MESSAGING", "networkInterfaceBinding": "IPV4_UNICAST", "interfaceBindingDescription": "AMQP 1.0 content-type header used to specify media type values", "operation": [ { "name": "getSsr", "description": "The manual input allows:\n\u2022\tto reserve a SSR code\n\u2022\tto clear the SSR code on all CWP units within the OPS sector\n", "operationMessage": [ { "direction": "IN", "name": "RequestGetSsr message" }, { "direction": "OUT", "name": "AcknowledgementMessage" } ] } ], "behaviour": [ { "name": "service behaviour", "description": "The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents)." } ] } ], "serviceDescriptionReferences": { "serviceDocument": [ { "title": "D2.4 Annex : OpenCWP Service Yellow SWIM Profile", "description": "The official OpenATM service definition as published, including the information definition, service behaviour, numerous diagrams (interfaces, sequence and others), additional technical details, and conformance matrix to the SWIM Service Description specification", "version": "1.0 (Released)", "reference": "ADaaS_WP2_MUAC_D2_4_OpenCWPService v1.0.pdf", "documentType": "SERVICE_SPECIFICATION" }, { "title": "Semantic Correspondence", "description": "The AIRM Semantic Correspondence. The correspondence was performed on AIRM 4.1.0 (sesarju:airm:v410).", "version": "1.0", "reference": "AdaaS_AIRM_mapping.xlsx", "documentType": "AIRM_TRACE" }, { "title": "XML Schema", "description": "The XSD definition files are embedded in the following package", "version": "", "reference": "AdaaS.XSD", "documentType": "MACHINE_READABLE_SERVICE_DESCRIPTION" }, { "title": "ASN.1 files", "description": "The ASN.1 files are embedded in the following package", "version": "", "reference": "CB-Messages-ASN1.tar.gz", "documentType": "MACHINE_READABLE_SERVICE_DESCRIPTION" }, { "title": "Example", "description": "A nice little program that explains the service consumer step-by-step on how to connect.", "version": "", "reference": "cb_example_01.tar", "documentType": "CODE_EXAMPLE" } ] } } }