GM4 Article 7(5) U-space service providers

• ED Decision 2022/022/R found in: U-space (2021/664) (May 2024)

GM4 Article 7(5) U-space service providers ED Decision 2022/022/R EXCHANGE OF INFORMATION — INFORMATION MODEL (a) U-space services may be provided concurrently by multiple USSPs in the same airspace. This requires the exchange of information and coordination among those USSPs, as well as between USSPs and other entities (such as UAS operators, ATSPs and CIS providers). Such exchange of information is expected to be based on open protocols and formats, using public, IP-based networks as transport layers. (b) The exchange of information (and its models) should be described in a technology-agnostic way (e.g. in the Unified Modelling Language (UML)). The aim is to document the key aspects of a dedicated information exchange service at conceptual level. (1) Operational and business context of the service: (i) service requirements (e.g. information exchange, constraints, validation rules); (ii) stakeholders that provide/use the service; (iii) operational activities supported by the service (e.g. flight planning, flight execution, etc.); (iv) relation of the service to other services. (2) Service description: (i) interfaces (e.g. based on request/response or publish/subscribe); (ii) interface operations (methods to interact with the service, e.g. request a flight authorisation); (iii) payload definition; (iv) features (e.g. a flight authorisation object); (v) properties/attributes (e.g. the identifier within a flight authorisation object); (vi) data types (e.g. defining the identifier within a flight authorisation record as a list of characters and numbers); (vii) associations (e.g. the relation of a flight authorisation to a registered UAS); (viii) dynamic behaviour (and life cycle) description. (3) Service performance level and validation aspects. (c) The information exchange services described in point (b) may be realised in different technical implementation levels enabling an architectural approach based on one concept, allowing for multiple potential solutions. (d) Consequently, different types of data frames might be in use to carry payload. A standard data encoding may be used to provide the service (JSON or ASTERIX on the example of traffic information). (e) The data encoding should be mapped to the definition of the service payload. Furthermore, the service that provided the information on this data encoding should be mapped in relevant technical details as well, e.g. in the service interfaces and operations. EUROCAE ED-269, which establishes a conceptual definition and its implementation in a standard data encoding, may be used as an example. (f) Provision of safe services (1) In addition to the operational information exchanged among the respective USSPs, further information on the respective service’s performance (e.g. degradation of services) may be collected and made available to ensure the provision of safe services. Sufficient monitoring may support technical operations to be performed under controlled conditions. This includes ensuring compliance with the related data quality, latency and data protection requirements set out in [Annex III](#_DxCrossRefBm1226740025) to [Regulation (EU) 2021/664](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021R0664&qid=1705662224579). (2) The provision and exchange of any safety-relevant information should follow processes that are comparable to established standards (e.g. ISO 9001 series). Additional information that originates from these processes should be exchanged as well. This includes but is not limited to: (i) service availability (planned or unplanned downtime, points of contact for technical and operational matters, etc.); (ii) service limitations (degraded operations, regional constraints, known issues); (iii) service integrity (security/safety incidents). (3) Both operational and service performance information should be protected; technical and operational measures should be taken by the USSPs to ensure the necessary information protection. (g) Protocol Any information exchange should be based on a common open communication protocol, such as the transmission control protocol (TCP). As a minimum, the requirements documented in the SWIM Technical Infrastructure (TI) Yellow Profile, edition 1.1, published on 5 July 2020, should be met. (h) Extension of information exchange services (1) Information exchange services may be extended by the entities described in point (a). (2) The extension of information exchange services, by changing their description (as described in point (b)(2)), should not jeopardise their semantic interoperability and standardisation across the Member States. (3) The extension of the payload definition can be usually managed by: (i) adding additional properties/attributes to the features; (i) adding new features. (4) The extension points for additional properties/attributes could be already foreseen in the payload definition, such as free text or a custom enumeration. (5) If custom features are added by an extension, the association between the default and the additional features should always be managed in the additional feature. (6) The description of the extended service should introduce optional elements (interfaces, operations, features, attributes/properties, data types, etc.) only. For instance, if additional information regarding communication infrastructure is provided by an extended flight authorisation service, a new feature called ‘communication infrastructure service availability’ might be introduced. This new feature might be associated with a flight authorisation feature. The association should be designed without changing the flight authorisation feature, to allow the processing of flight authorisations by services that have no knowledge of the ‘communication infrastructure service availability’. (7) The approach to the service description is laid down in the SWIM Service Description and the EUROCONTROL Specification for SWIM — Information Definition. (i) Protection of information The necessary protection level will vary depending on the type of the information exchanged. As a minimum, the requirements documented in the SWIM Technical Infrastructure (TI) Yellow Profile, edition 1.1, published on 5 July 2020, should be met. Additional protection should be put in place where applicable, especially when considering the relevant data privacy regulations (e.g. GDPR).