AIRM Compliance Handbook

Transcription

1 AIRM Compliance Handbook Document information Project Title AIRM Project Number Project Manager Document Name Edition Task contributors EUROCONTROL FINMECCANICA, EUROCONTROL, DFS Abstract AIRM Compliance Handbook The AIRM (ATM Information Reference Model) Compliance Handbook provides practical guidelines, examples and best practices in order to help building evidence of AIRM Compliance for all kinds of OuA (Object Under Assessment). Note: Please refer to the AIRM Compliance Framework [1] for further information related to AIRM Compliance.

2 Authoring & Approval Prepared By - Authors of the document. Name & Company Position & Title Date Gianluca Marrazzo / FINMECCANICA P S3T Lead 10/02/2015 Reviewed By - Reviewers internal to the project. Name & Company Position & Title Date Stefan Keller / DFS P Member 26/02/2016 Scott Wilson / EUROCONTROL P Project Manager 26/02/2016 Francisco Graciani / EUROCONTROL P Member 26/02/2016 Miguel Marti / EUROCONTROL P Member 26/02/2016 Document History Edition Date Status Author Justification /02/2015 Draft G. Marrazzo New document and draft structure /02/2015 Draft G. Marrazzo Structure elaborated and updates based on initial feedback received /02/2015 Draft G. Marrazzo Draft updated to prepare for SMT# /04/2015 Draft R. Suzic Explained UML* star approach /04/2015 Revised draft G. Marrazzo R. Suzic Incorporated changes in preparation for ISRM Foundation /09/2015 Revised draft G. Marrazzo R. Suzic Added reference to compliance template. New examples text added to support ISRM /12/2015 Revised draft G. Marrazzo Inclusion and better linking to available templates (MS Word and Excel). Templates updated. General editing and cleanup /02/2016 Revised draft M. Marti F. Graciani General review checking that all parts of the document are readable and complete. 2 of 33

3 Intellectual Property Rights (foreground) Copyright (c) 2016, SESAR Joint Undertaking =========================================== All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the disclaimer in the documentation and/or other materials provided with the distribution. * Neither the names of the SESAR Joint Undertaking nor the names of its contributors may be used to endorse or promote products derived from this specification without specific prior written permission. DISCLAIMER THIS SPECIFICATION IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ========================================== This license is an instance of the BSD license template as provided by the Open Source Initiative: Details on the SJU and its members: 3 of 33

4 Table of Contents EXECUTIVE SUMMARY INTRODUCTION PURPOSE OF THE DOCUMENT INTENDED READERSHIP DOCUMENT STRUCTURE ACRONYMS DEFINITIONS GENERAL GUIDANCE WHAT IS THE OBJECT UNDER ASSESSMENT FOR AIRM COMPLIANCE? WHAT TYPES OF OUA ARE CONSIDERED IN THIS HANDBOOK? WHAT IS AIRM COMPLIANCE IN A NUTSHELL? WHAT SHALL I PROVIDE TO PROVE AIRM COMPLIANCE? CAN WE TOLERATE EXCEPTIONS? WHAT ARE AIRM COMPLIANCE LEVELS? WHAT ARE SIMPLE AND ONE-TO-MANY MAPPINGS? HOW DO I RECOGNIZE THAT I NEED A ONE-TO-MANY MAPPING? AIRM COMPLIANCE FOR ISRM SERVICE PAYLOADS IS MY MESSAGE BUILT ON A STANDARD MODEL? IF NOT, HOW TO MAP AN <<ENTITYITEMATTRIBUTE>>? SIMPLE MAPPING EXAMPLES MAPPING INHERITED PROPERTIES ONE-TO-MANY MAPPING EXAMPLES SPECIAL CASE EXAMPLE (OUT OF SCOPE, CR) AIRM COMPLIANCE FOR PHYSICAL MESSAGE IS MY MESSAGE BUILT ON A STANDARD MODEL? IF NOT, WHAT DO I HAVE TO PROVIDE? MAPPING EXAMPLES AIRM COMPLIANCE FOR EXCHANGE MODELS WHAT DO I HAVE TO PROVIDE? MAPPING EXAMPLES Using Excel template Same example using UML APPENDIX A TEMPLATES A.1 WORD DOCUMENT TEMPLATE A.2 EXCEL TEMPLATE A.2.1 Best practice for OuA URN APPENDIX B UML MAPPINGS THROUGH THE STAR MODEL APPROACH B.1 WHAT IS UML MAPPINGS: THE * MODEL APPROACH? B.2 TOOLING SUPPORT? B.3 HOW CAN IT LOOK LIKE? REFERENCES of 33

5 Executive summary The AIRM Compliance Handbook provides practical guidelines, examples and best practices in order to help building evidence of AIRM Compliance for a number of different OuA (Objects Under Assessment): logical service messages such as ISRM (Information Services Reference Model) service payloads, physical messages defined in a Service Technical Design Description (STDD) or in a non-soa (Service Oriented Architecture) data sharing interface, Standard Exchange Models such as AIXM, FIXM and WXXM. This document tells the data modeler how to practically apply and implement the requirements stated in the AIRM Compliance Framework [1] in order to achieve a compliance report for each and any of these OUAs. The AIRM Compliance Framework document therefore remains the normative document for AIRM Compliance. 5 of 33

6 1 Introduction 1.1 Purpose of the document This document is practical guidance to assess AIRM Compliance for different categories of Object Under Assessment (OuA). It applies the AIRM Compliance Framework in a way that satisfies the AIRM Foundation Rulebook [2]. It explains how to build evidence for semantic correspondence to AIRM for: - ISRM service payloads; - Physical messages from data sharing interface definitions. These might both be related to SWIM services documented in Service Technical Design Description (STDD), or to non- SWIM interfaces (even non SOA) which aim for standalone AIRM Compliance; - Data exchange models or formats (and their extensions) specified by international bodies, such as AIXM, FIXM, IWXXM, WXXM, ED133, etc. 1.2 Intended readership This document is intended for Data Modelers, Service Architects. Furthermore it is of interest for SWIM Compliance Applicants and SWIM Support in the context of SWIM Compliance. 1.3 Document structure Section 2 contains general guidance. The next sections are specific guidance dedicated to each type of OuA. Therefore the reader can easily browse the document to reach the content of his interest. 1.4 Acronyms Term AIRM AIXM ATM CLDM ED133 FIXM ICAO ICD ICT IDL IETF IM Definition ATM Information Reference Model Aeronautical Information Exchange Model Air Traffic Management AIRM Consolidated Logical Data Mode Flight Object Interoperability Specification Flight Information Exchange Model International Civil Aviation Organization Interface Control Document Information and Communications Technology Interactive Data Language Internet Engineering Task Force AIRM Information Model 6 of 33

7 ISO ISRM IWXXM NAF NID OCL OMG OuA S3T SBVR SESAR SJU SOA STDD SWIM TOGAF UML URN XML XSD Term International Standards Organization Information Services Reference Model Definition ICAO Weather Information Exchange Model NATO Architecture Framework Namespace Identifier Object Constraint Language Object Management Group Object Under Assessment. In the context of AIRM Compliance is a set of information or data constructs assessed against AIRM Compliance Framework criteria. In this document it means either a data exchange model or a message. Services and Systems Support Team Semantics of Business Vocabulary and Rules Single European Sky Air Traffic Management Research SESAR Joint Undertaking Service Oriented Architecture Service Technical Design Description System Wide Information Management The Open Group Architecture Framework Unified Modeling Language Uniform Resource Name Extensible Markup Language XML Schema Definition 1.5 Definitions Definition Name Entity Property Data Type Definition A definition (type) of an item of interest that is subject to Constraint/Business Rule(s). A typed element that represents an attribute or role of an entity that is subject to Constraint/Business Rule(s). The abstract class that represents the general notion of being a data type (i.e., 7 of 33

8 Constraint/ Business Rule AIRM Compliance (a.k.a. Information Compliance) AIRM Compliance assessment Interoperability Semantic Interoperability Service payload Syntactic Interoperability Standard Object under Assessment (OuA) Source element Target element Semantic correspondence Semantic trace Special constructs a type whose instances are identified only by their value). An element of guidance that introduces an obligation or a necessity A documented adherence for a set of information or data constructs to the ATM operational information consolidated semantics expressed by the AIRM components, and the processes to document, measure and track variances from it. The process through which AIRM Compliance is ascertained and documented. The ability of disparate and diverse organisations to interact towards mutually beneficial and agreed common goals, involving the sharing of information and knowledge between the organisations, through the business processes they support, by means of the exchange of data between their respective ICT systems Ability of an information exchange provision (logical or technical) which ensures that the precise meaning of exchanged information is preserved and understood by all parties. The formal representation of the content and structure of the input and output parameters of a service operation. Ability of a technical information exchange provision which ensures that the representation of the information is correctly interpreted by all parties. Syntactic interoperability is about describing the exact format of the information to be exchanged in terms of grammar, format and schemas. A specification, adopted by a recognised standardisation body or Community of Interest for repeated or continuous application. A set of information or data constructs which is subject to AIRM Compliance demonstration. A specific information or data construct of the set is referred to as an Object under Assessment element. A shorthand for Object under Assessment element. A shorthand for a specific information or data construct of the AIRM model products The quality for a pair of source and target elements, whose textual definitions are in one of the following relations: ExactCopy: Definition of source and target are exact copy of each other. SyntacticallyEqual: The source definition uses a different syntax (e.g. English vs. American spelling) Rewritten: The source definition has been rewritten. The meaning is the same, i.e. the definition still describes exactly the same entity as the target definition. Restriction: Source definition is a restricted case of the target definition, i.e. it retains the original definition but adds additional qualifiers. A process for finding semantic correspondence between two elements Elements having the following designators: 1. AIRM_OutOfScope, or 2. AIRM_Change_Request, or 8 of 33

9 3. Object under Assessment_Issue. Object under Assessment_Issue AIRM_Change_Requ est AIRM_OutOfScope Mapping A construct signifying the following semantic trace case: A model element of object under assessment is found to have an error which prevents its correct sematic trace to the AIRM. A construct signifying the following semantic trace case: An element of the Object under assessment is found to be in scope of the AIRM but there is missing corresponding element so a request to change the AIRM has been raised. The AIRM_Change_Request element is further decorated with the actual AIRM Change Request number. A construct signifying the following semantic trace case: An element of the Object under Assessment is found to be out of the-scope for the AIRM. The documentation of a semantic trace, i.e., for a given element of the Source either: The identification of one or multiple elements of the Targetthat (together) semantically correspond, or The identification of one of the special cases designators describing the relation between the source element and the target. Mapping Artefact The set of Mappings covering a whole Object Under Assessment. 9 of 33

10 2 General guidance 2.1 What is the Object Under Assessment for AIRM compliance? Any set of information or data constructs can apply to AIRM Compliance. It is typically a data model or a message given in some standard notation, however the following sections will clarify some OUA through examples. In order to be acceptable, all the constructs composing the OUA must have their semantics (i.e. their meaning) completely and correctly documented in plain text. It doesn t matter if the documentation is inside the OUA itself or is held in a separate document/artifact. 2.2 What types of OUA are considered in this Handbook? Three types of OUA are discussed further in the next chapters of this edition of the Handbook: - Logical message: a technology-independent representation of the information content conveyed by a service operation as parameter of input or output. A logical message is described in the context of a specific service through a Service Description Document (SDD). This category includes the payload of ISRM services or non-isrm services. Logical messages are typically represented in UML; - Physical message: a technology-specific representation of the information shared between two systems. A physical message could be part of: o o a SOA interface, e.g. in case of services running on SWIM. In this case the message is documented in a Service Technical Design Description (STDD) document, along with the full service interface description; a non-soa interface. In this case the physical message does not relate to any service, but is documented in some other kind of document (e.g. Interface Control Document, ICD). Physical messages are typically represented as XSD schemas, but can also be described in UML, IDL, binary format, text. - Standard Exchange Model, such as AIXM, FIXM, WXXM. These are recognized either globally or within a certain Region or community of interest. When available, a logical model (UML) from these standards is considered as the OUA. This Handbook is non-exhaustive and not restrictive on the OUA type, namely there could be other kinds of OUA which are not known or not relevant to SESAR for the time being, and which could be introduced and considered for AIRM Compliance in future editions of this document. 2.3 What is AIRM Compliance in a nutshell? AIRM Compliance is the demonstration of semantic correspondence between textual definitions of the OUA and AIRM. Compliance requires that every construct of an OUA (source element) can be mapped to: - one construct (target element) in the AIRM having the same meaning (semantics) or - several target elements in the AIRM which together cover the meaning of the source element. By default, if the description of a source element is missing then the element itself is not AIRM Compliant. Definitions for source and target are not required to be exactly the same, some flexibility is allowed. Namely, the semantics for source can be rewritten or made more specific/restrictive with respect to the semantics of the target. Compliance is not satisfied if the description for source is conflicting or is 10 of 33

11 generalised with respect to the target. Finally, Compliance is satisfied also in some special cases when the correspondence cannot be found, as explained in Section 2.5 Some examples of valid and invalid mappings are presented in Table 1. The last column explains the differences between OUA and AIRM descriptions. AIRM Compliance is achieved only if all OUA constructs elements have a valid mapping to AIRM. 2.4 What shall I provide to prove AIRM compliance? You shall build a mapping artifact, i.e. a documentation of all the semantic correspondences between OUA and AIRM, including any reason for exceptions as explained below. The mapping artifact must be made accessible in order to claim AIRM Compliance. The mapping can be represented in several ways: table, UML diagrams or whatever format fulfilling AIRM Compliance requirements and allowing the mapping evidence to be easily understandable. The next chapters will present various representations, examples and best practices for various types of OUA. 2.5 Can we tolerate exceptions? Yes. As shown in Table 1 there are cases where it is not possible to find a semantic correspondence of an OuA construct and AIRM: - OuA construct is out of scope of AIRM. There might several cases, for example a construct: o o o is not an ATM piece of information; is technology-specific or protocol-specific data; is only a container of other ATM data (however its content is in the scope of AIRM) for the purpose of a specific data exchange; - AIRM has a missing content or an opportunity to improve the quality of the AIRM (e.g. improving definition of the terms, etc).. In this case a change request to AIRM is needed. - There might be a mistake in the OuA that has gone unnoticed but you may not be able to fix it right away (e.g. you are working on an OuA for a standard and you need to follow a Change Management process). In this case you can put a suitable reference to the OuA change and proceed under the assumption that the gap. Each OuA kind has a specific way to document these special cases. See next chapters. 2.6 What are AIRM Compliance Levels? Depending on the granularity (entities, attributes, data types...) on which you build correspondence between OuA constructs and AIRM elements, you can reach different levels of AIRM Compliance: - Level 1 (or AIRM Ready ) requires that you map only the higher level entities of the OUA. For example: o o If the OUA is a UML model you need only to map the entities without caring about inner properties (i.e. class attributes or association ends). If the OUA is an XSD schema, you need only to map complex types without having to map the inner elements and simple types. - Level 2 (or AIRM Compatible ) requires that you map also the inner properties of OUA entities. For example: attributes and association ends for a UML model, XSD elements inside a complex type. 1 1 Level 2 is the currently the most commonly sought level, since only limited R&D has been performed at Level of 33

12 - Level 3 (or AIRM Compliant ) requires that you map also the base types and constraints for all OUA constructs. E.g.: all classifiers for UML attributes, all types for XSD elements, SBVR or OCL constraints, The next chapters will clarify what the various levels are depending on the specific type of OuA that you are assessing. 12 of 33

13 Table 1. Examples of compliant and non compliant cases. Source (element from OuA) Target (element in AIRM) Compliant Name Description Name Description? flight_rules AircraftType ReroutingIndicator.reaso n ReadyStatus.readyForIm provement RegulationCause ICAOAddress Indicates if the rules applicable for the flight are visual (VFR), instrumented (IFR) or visual and then instrumented (VFR_THEN_IFR) or vice versa (IFR_THEN_VFR). The designator(s) of the aircraft type(s) (e.g. B747). If the flight was rerouted, indicates why. Cannot be null if rerouted is true; must be null otherwise. True if the flight is in Request For direct Improvement mode (RFI) state. False if it is not, i.e. when the SIP Wanted Message mode is on (SWM).Null if readytodepart is true; cannot be null otherwise Describes the cause of a regulation. The unique 24-bits address of the aircraft and is allocated by the registering authority of the State within which the aircraft is registered. Flight.flightRule AircraftType.icaoIdent ifier ReroutingIndicator.re ason ReadyStatus.readyFo rimprovement RegulationCause icaoidentifier Indicates if the rules applicable for the flight are visual (VFR), instrumented (IFR) or visual and then instrumented (VFR_THEN_IFR) or vice versa (IFR_THEN_VFR). This is the ICAO designator of an AircraftType as published in ICAO doc If the flight was rerouted, indicates why. True if the flight is in Request For direct Improvement mode (RFI) state. False if it is not, i.e. when the SIP Wanted Message mode is on (SWM). Cause of the most penalising regulation ICAO designator of an AircraftType as published in ICAO doc YES YES YES YES NO NO Degree of correspondence OuA description is exact copy from AIRM OuA description is rewritten from AIRM OuA element definition is more restrictive, i.e., a restriction, in comparison to the AIRM one, see the additional sentence restricting the meaning in the OuA description. OuA element definition is more restrictive, i.e., a restriction, in comparison to the AIRM one, see the additional sentence restricting the meaning in the OuA description. Source element definition is broader, i.e., a generalisation, in comparison to the AIRM one; the OuA definition allows for any more general case while the AIRM definition points to the most penalising regulation. The two elements simply have different meanings: the former is an aircraft identifier while the latter is an aircraft type.

14 AircraftCluster HazardousCargo DiplomaticClearance ED-133 specific container of data related to Aircraft Information about dangerous material shipped by an airframe which needs special flight procedures and management by ground units and crew. A special permission for military transport aircraft of the participants to fly over each other country's territory and to land at and take-off from military and civilian airports (to the exception of the airports and/or areas specifically mentioned in a list of exempted airports and/or areas to be completed by each participant) whilst adhering to all national rules, international agreements, ICAO rules, restrictions described in the national military and civilian Aeronautical Information Publications, ATC regulations, NOTAMs or other special requirements. AIRM_OutOfScope N/A YES AIRM_OutOfScope N/A YES AIRM_CR#470 N/A YES Flight.attribute1 An attribute for a flight. OUA_issue N/A YES Out of scope for AIRM. Any construct which is not ATM-wide, but is bound to system- or solutionspecific information is out of scope for AIRM Out of scope for AIRM. The OUA element is related to concept which is outside SESAR operational concepts and requirements, and therefore is not qualified for AIRM. There is a gap in the AIRM and this element needs to be added to it. An AIRM Change Request identifier is given as a means of interim mapping. The OUA element is affected by some problem or mistake in the definition and therefore cannot be mapped to AIRM. This element needs to be handed back to the owner of the OUA for change. 14 of 33 frame of the SESAR Programme co-financed by the EU and EUROCONTROL. Reprint with approval of publisher and the

15 2.7 What are simple and one-to-many mappings? Simple mappings occur when there is a one-to-one semantic correspondence between a construct from OUA and a model element in AIRM. All the examples presented in Table 1 were all simple mappings. A One-to-many mapping is needed when it is necessary to compose more atomic AIRM elements in order to build the meaning of a single OUA construct. Let s take the example of an OUA element Target Startup Approval Time (TSAT). In CLDM (AIRM Consolidated Logical Data Model) and IM (AIRM Information Model) the TSAT notion is represented as in Figure 1. AIRM IM AIRM CLDM StartUpApprovalTime «IMEntity» TargetStartUpApprov altime notes The time provided by ATC taking into account TOBT, CTOT and/or the traffic situation that an aircraft can expect to receive start up / push back approval. TemporalEnabledEntity «CLDMEntity» StartUp + startuptolerance :DateTime [0..1] + time :DateTimeWithPlanningType [0..*] «DataType» DateTimeWithPlanningType DateTime + planningstatus :CodePlanningStatusType [0..1] CharacterString «CodeList» CodePlanningStatusType + SCHEDULED [0..1] + ESTIMATED [0..1] + TARGET [0..1] + ACTUAL [0..1] + CALCULATED [0..1] + OPTIMAL [0..1] + AMAN_PLANNED [0..1] Figure 1 Representation of TSAT in IM and CLDM. Table 2 shows an example of a one-to-many mapping to map the TSAT to AIRM elements.

16 Table 2. Example of a one-to-many mapping Construct from OuA Element in AIRM Name Description Name Description CLDM::StartUp.time (CLDM Semantic Trace in AIRM) Time at which the start-up of the aircraft engines is done by the flight crew upon the ATC approval. Explanation CLDM element having the same type of data (i.e. a time) as the OuA construct. This is the main CLDM mapping) TSAT The time provided by ATC taking into account TOBT, CTOT and/or the traffic situation that an aircraft can expect to receive start-up / push-back approval. CLDM:: CodePlanningStatusType. TARGET (CLDM Context Trace in AIRM) N/A Additional context necessary to qualify the semantics of the time attribute Namely, it represents which planning status is associated with the time (context CLDM Mapping) IM::TargetStartUpApprovalTime (IM Definition Trace in AIRM) The time provided by ATC taking into account TOBT, CTOT and/or the traffic situation that an aircraft can expect to receive start-up / push-back approval. This contains the full normative definition of the OuA construct (IM Definition Mapping) As shown in the example, a one-to-many mapping can be composed of three CLDM and IM mappings, each being a building block for the one-to-many meaning of TSAT: Main CLDM mapping. The mandatory and unique CLDM mapping indicating the AIRM element having the type of data as the OuA construct. E.g. a time for TSAT; Context CLDM Mapping. One or more optional additional CLDM mappings helping achieving a more accurate semantic definition by giving more context to the main CLDM mapping. E.g. the TARGET planning status for TSAT; IM Definition Mapping. An IM mapping allows referencing a unique IM element containing a normative definition (typically from ICAO) for the OUA construct. Can be optional or mandatory depending on contexts as explained in next chapters. Note that if any of the composing mappings is missing, then the semantics of the OUA would not be described accurately in terms of AIRM elements, as the semantic would miss some building block. 2.8 How do I recognize that I need a one-to-many mapping? It cannot be told a priori. One-to-many mappings are needed whenever it is not possible to find a unique AIRM element which accurately represents the meaning of an OUA construct. Judgment of such accuracy however cannot be measured. As a rule of thumb, one-to-many mappings are likely to occur when the OUA construct: 16 of 33

17 - is a mixture of format aspects and operational aspects o e.g. ICAO Departure Aerodrome designator is a compound of ICAO format for aerodrome designator the flight departure operational phase - is a complex acronym, hinting at a complex-looking definition o e.g. EOBT, SOBT, CTOT, TSAT are compounds of a time quantity; an operational phase of flight (Off-Block, Takeoff,...); a planning horizon (estimated, scheduled, computed, target,...); A set of examples for one-to-many mappings is given in the next chapters. 17 of 33

18 3 AIRM Compliance for ISRM Service Payloads Payloads for ISRM services are expressed in UML and modeled in a Sparx EA production Environment according to the ISRM Foundation. ISRM requires that every <<EntityItemAttributes>> in the payload is mapped to one or more elements (entities or properties) in AIRM. This accounts as requiring Level 2 AIRM Compliance as described in the AIRM Compliance Framework document. The mapping to the AIRM is provided by referencing the target AIRM elements via their URNs. Each element (entity or property) of AIRM can be univocally identified by a human readable string with the following syntax: urn:xses:sesarju:airm:v331:consolidatedlogicaldatamodel:subjectfields:airspacein frastructure:airspace:airspace@designator 2 For each <<EntityItemAttributes>> the URN(s) of target AIRM element(s) must be added in one or more tagged values. Tagged values may be accessed via the Tagged Values window after selecting the payload <<EntityItemAttributes>> in the project browser. It may also be activated by Ctrl+Shift+6 if hidden. 3.1 Is my message built on a standard model? According to the ISRM Modeling guidelines, in this case the payload is only represented as an empty <<EntityItem>> acting as a placeholder for a message expressed in some published exchange model (e.g. AIXM, FIXM, ED133...) for which there is already an existing AIRM Compliance Report available. In this case the placeholder root <<EntityItem>> must have a mandatory IM Definition Mapping. You must add an IMDefinitionTrace tagged value to the payload EntityItem and fill it in with the URN of an AIRM <<IMMessage>> or <<IMEntity>> containing the normative definition for the payload. Furthermore, you must enter a description of the standard model used (name and version) and a reference (e.g. web link) to the compliance report for the exchange model in the payload Entity s description property. See Figure 2 for an example. «EntityItem» Entity items::metar tags IMDefinitionTrace = urn:x-ses:sesarju:airm:v400:informationmodel:subjectfields:airtrafficoperations:informationservicesproducts:meteorologicalinformationproduct:metar notes The METAR bulletin is based on the IWXXM 1.0 standard model ( This EntityItem corresponds to the following element in the IWXXM standard: -./iwxxm/v1.0/metarspeci/metar Figure 2. Mapping a payload based on a standard model. Example for METAR. If the exchange model used for the service payload does not have an already published AIRM compliance report, then it must be built following instructions in Chapter 5. 2 The last element (after denotes the property, the second to last element denotes the class name in the AIRM, while the other colon (:) separated values identity the actual path of the element inside the specific version (3.3.1 in this case) of the AIRM. A property can be either an attribute or a role of a CLDM class. 18 of 33

19 3.2 If not, how to map an <<EntityItemAttribute>>? For each <<EntityItemAttribute>> composing your payload you must enter one (for simple mappings) or more (for one-to-many mappings) URN(s) of the target AIRM element(s) into pre-defined tagged values. Three types of tagged values can be added, allowing simple and one-to-many mappings as presented in Section 2.7. For simple mappings you shall add a single tagged value CLDMSemanticTrace to each <<EntityItemAttribute>> and fill it in with the URN of the (unique) semantically correspondent CLDM element. As per Section 2.5 there are two special cases - if payload attribute is out of AIRM scope, you shall fill it in with CLDM_out_of_scope ; - if payload attribute is missing in AIRM, or AIRM having an error impeding tracing, you shall fill it in with CR_XYZ, where XYZ is the unique number of a Change Request issued to the AIRM Change Control Board (CCB). For one-to-many mappings: 1. You shall add a mandatory tagged value CLDMSemanticTrace to each <<EntityItemAttribute>> and fill it in with the URN of the CLDM element containing the same real-world quantity (time, distance, pressure, etc ) as the payload attribute. This tagged value represents the Main CLDM mapping as presented in Section You shall add one or more tagged value CLDMContextTrace to each <<EntityItemAttribute>> and fill them in with the URNs of CLDM entities, properties or enumerated values which help to cover the full semantics of your <<EntityItemAttribute>>. This tagged value is the implementation of the Context CLDM Mapping as presented in Section 2.7; 3. You shall add one tagged value IMDefinitionTrace to each <<EntityItemAttribute>> and fill it in with the URN of a <<IMMessage>> or an <<IMEntity>> containing the normative definition corresponding to the <<EntityItemAttribute>>. This tagged value is the implementation of the IM Definition Mapping as presented in Section 2.7; An example is given in Figure 3. The attribute StartUpApproval.targetTime represents the Target Startup Approval Time (TSAT). As explained in section 2.8 it is a compound term and is one of the cases needing a one-to-many mapping. Note again the reference to a specific value TARGET in the CodePlanningStatysType enumeration in CLDM, in order to select the actual planning horizon for the start-up approval time. Figure 3. Example of TSAT requiring a one-to-many mapping via multiple tagged values. When the tagging of the attributes is complete, a table (excel file) can be extracted from the ISRM showing the mapping of the attributes line by line. This extraction is supported by a script. As long as 19 of 33

20 this script is not available the table must be prepared manually. The table is needed as input for the AIRM compliance check and it is a legal means according to the AIRM Compliance Framework which requires a documented mapping. This table will be used in the AIRM Compliance Report of the service in order to document the AIRM compliance of this specific service. 3.3 Simple mapping examples The code attribute in the OtherInformation field of the flight plan maps to the CLDM attribute Aircraft.icaoAircraftAddress. See Figure 4 how the URN from the target attribute has been used to fill in the tagged value for the source attribute. Figure 4. Simple mapping for aircraft address field in the flight plan. 3.4 Mapping Inherited properties An inherited AIRM attribute can be referenced in the context of the child class. In order to do so, the URN of the attribute shall be manually composed by: 1) using the URN of the child class; 2) appending symbol and the name of the inherited attribute to the URN. See in the following example (Figure 5) how the base attribute in the payload has been mapped to the inherited Cloud.base entity. 20 of 33

21 Figure 5. Simple mapping for an inherited property Cloud.base. 3.5 One-to-many mapping examples Figure 3 above has already shown one example of one-to-many mapping. Figure 6 shows the mapping the departure_aerodrome attribute. The mapping must be done both to the Aerodrome.designator itself and to the Flight.departureAerodrome in order to represent the full meaning of the payload attribute. Figure 6. Mapping for ADEP designator field in the flight plan. The IM tagged value is not used The following is an example (Figure 7) for mapping the EOBT following the same approach as it was done in the TSAT example of Figure of 33

22 Figure 7. Mapping for EOBT Note again the reference to a specific value ESTIMATED in the CodePlanningStatysType enumeration in CLDM, in order to select the actual planning horizon for the off-block time. 3.6 Special case example (out of scope, CR) Examples for out of scope and mapping to AIRM CRs according to the conditions stated in Section 2.5. In Figure 8 the attribute request_number is a technical attribute related to the flight object processing and is therefore not in scope of AIRM. Figure 8. ED133 solution-specific parameter requestnumber not in scope for AIRM In Figure 9, the leglength attribute has still no correspondence in AIRM, so the data modeler has filed a change request (coded as CR_00470 ) in the AIRM CCB tool in order to trace the attribute to a future AIRM construct which will be introduced in a future AIRM release. 22 of 33

23 Figure 9. An OAT (military) flight plan attribute leglength is to be added to AIRM via CR# of 33

24 4 AIRM Compliance for Physical Message As said above, the physical messages from an interface definition are typically described as XML schema definitions (XSD) however other forms can be used. In particular, for services elaborated in SESAR, XSD physical messages are usually contained or referenced from the STDD. 4.1 Is my message built on a standard model? If messages are composed by elements entirely built on an exchange model (such as FIXM, AIXM, IWXXM) then the AIRM Compliance must be assessed for the underlying model only. If the exchange model already has an AIRM Compliance Report, then the compliance for the message is already satisfied and the available Report can be referenced right away. If the underlying model does not have a Compliance Report, you shall produce it by following instructions in Section 5. If the message adds extensions or additional constructs with respect to the exchange model, then Compliance shall be elaborated on the additional part according to next Section If not, what do I have to provide? AIRM Compliance is achieved by mapping all constructs present in schemas (elements typed as simple and complex types) to AIRM. The mapping between schema elements and the AIRM is provided by referencing the target AIRM elements via their URNs. The mapping can be provided as a table as explained in Appendix A Mapping examples The following table presents the mapping between the XSD schemas for the AirportMETObservation Service implemented and validated in SESAR Validation Exercise VP-669. AirportMETObservati on mapping 24 of 33

25 5 AIRM Compliance for Exchange Models Exchange models (such as AIXM, FIXM, ED133, IWXXM etc.) are usually given as a logical model (UML) plus a physical model (XML schemas). It is usually easier to consider the UML model as OUA and perform the mapping against the AIRM. 5.1 What do I have to provide? It shall be provided a Compliance Report as a MS Word document according to the template defined in Appendix A.1. All the required fields shall be filled in. The actual mapping artifact within the template could be provided as a table as explained in Appendix A.2, or via a UML mapping model as explained in Appendix B. 5.2 Mapping examples In order to demonstrate how to obtain the AIRM Compliance for Exchange Models, some examples are presented below explaining the mapping process between AIRM and some Exchange Models. The Exchange Model selected for this particular case is the AIXM, version v5.1.1 and the AIRM model used is the AIRM version Using Excel template Here below there are a couple of examples of AIXM-AIRM mapping using the AIRM Excel template provided for this purpose. See section Appendix A.2 to have access to the latest version of the Excel template. Evidence for AIRM Compliance_L1 (only Entities mapped to AIRM) The following OuA (source element) are mapped to the AIRM (target element): AerialRefuelling, AerialRefuellingAnchor, AerialRefuellingPoint, AerialRefuellingTrack, AuthorityForAerialRefuelling. In all the cases the Degree of Correspondence is ExactCopy (definition of source and target are exact copy of each other), except for AerialRefuellingPoint where the Degree of Correspondence is Restriction (Source definition is a restricted case of the target definition, i.e. it retains the original definition but adds additional qualifiers). Figure 10. Evidence for AIRM Compliance_L1 Evidence for AIRM Compliance_L2 (Entities, attributes and relationships mapped to AIRM) The following OuA (source element) are mapped to the AIRM (target element): ElevatedCurve.elevation, ElevatedCurve.geoidUndulation, ElevatedCurve.verticalAccuracy, ElevatedCurve.verticalDatum. In this specific case, three different values of Degree of Correspondence are found: 25 of 33

26 ExactCopy Restriction Rewritten (The source definition has been rewritten. The meaning is the same, i.e. the definition still describes exactly the same entity as the target definition.) Same example using UML Figure 11. Evidence for AIRM Compliance_L2 In this section, the same examples of the previous section are presented but using UML. For this specific AIXM-AIRM mapping, the AIXM version used is version and the AIRM version used is version Evidence for AIRM Compliance_L1 Figure 12. Evidence for AIRM Compliance_L1 26 of 33

27 Evidence for AIRM Compliance_L2 Figure 13. Evidence for AIRM Compliance_L2 27 of 33

28 Appendix A Templates Some templates were made available in SESAR in order to help: - documenting AIRM Compliance in a formal and publishable way: MS Word Template; - collecting the actual mapping artifact in a file: MS Excel Template. These templates are applicable to whatever kind of OUA and can be reused and adjusted to the needs of the specific context in which AIRM Compliance is required. A word template is available as an official wrapper for the mapping artifact, while an Excel template can be used as a container for the actual mappings. A.1 Word document template A MS Word template [3] guides the creation an AIRM compliance report and allows collecting all mapping information into a document with can officially be published. The Word template is structured upon the generic SESAR templates and is intended to be filled in with the actual mapping artifact. The template also allows adding all the relevant information and references that the reader of the compliance artifact should be aware of. A.2 Excel template The mapping artifact itself can be organized in tabular format according to an excel template [4]. The table has one row for each mapping, and can also accommodate one-to-many mappings. A.2.1 Best practice for OuA URN If the OuA owner provides a Unique Identifier for each of his definition (as suggested in Compliance Framework Req. 2), then this identifier will naturally be used in constructing the mapping. If not, it may be useful to create such Unique Identifiers specifically for the mapping purpose. Then a recommended practice is to use IETF URN syntax in analogy with the AIRM itself. The NID x-ses-oua should then be used to document the context of a SESAR compliance assessment ( x-ses should only be used for SESAR governed items). 28 of 33

29 Appendix B approach UML mappings through the star model B.1 What is UML mappings: the * model approach? As stated in Definition section, mapping is the documentation of the execution of a semantic trace, i.e., for a given element of the Source either: The identification of one or multiple elements of the Target that (together) semantically correspond, or The identification of one of the Compliance constructs describing the relation between the source element and the target. The Mapping Artefact is the set of Mappings covering the Object Under Assessment. The Mapping Artefact can be represented as a UML to UML mapping. This means that the OuA is a UML 2.1 representation of the information/data class constructs in question. The Mapping Artefact shall have association stereotyped as <<SemanticTrace>> from each OuA element to at least one AIRM::ModelElement. To do this, it may require a new UML model to be produced. Such new model is called star model and is denoted with *, i.e., those new models are denoted as AIRM * and OuA*. This new artefacts created from the AIRM and the OuA are created by applying agreed UML transformation rules such as attribute and rule promotion to class in order to facilitate the UML mapping for AIRM Compliance Level 2 and 3 purposes. Note that the AIRM* and OuA* models allow drawing mapping dependencies and mapping diagrams without having an impact on the original models. For AIRM Compliance Level 2 and 3 purposes to map entities properties, each property shall be promoted from a UML::Attribute or UML::Role to a UML::Class. The container entity/object and the new class shall be associated using UML::Composition with the stereotype <<Contains>>. The new class shall be stereotyped <<Attribute>> or <<Role>> to record its previous status. The new class shall retain the uniform resource name (URN) of the original AIRM model element. The new classes created in the star model generation: - shall be named as <CodeList 3 _NAME>.<Value_NAME> where < CodeList _NAME> is the name of the container and Value _NAME is the name of the value, - shall be named as <Entity_NAME>.<Property_NAME> where <Entity_NAME> is the name of the container and Property _NAME is the name of the property. For example from a CLDMEntity with name C1 that has attribute a1 a new class should be created with name C1.a1; see for an AIRM* example Figure 1 where the promotion is illustrated with the AIRM Consolidated Logical Data Model (AIRM CLDM) on the left and the same model with promoted properties on the right side: 3 For full definitions of model elements see the AIRM Meta model 29 of 33

30 AIRM CLDM AIRM With Promoted Properties TemporalEnabledEntity «CLDMEntity» Runw ay «CLDMEntity» Runw ay «Contains» 0..1 «Attribute» Runw ay.designator + designator :CharacterString [0..1] + type :CodeRunwayType [0..1] «Attribute» Runw ay.type +runway 0..* «Contains» 0..1 «Contains» 0..* «Role» Runway.associatedAerodrome +associatedaerodrome 0..* «CLDMEntity» Aerodrome TemporalEnabledEntity «CLDMEntity» Aerodrome «Contains» 0..1 «Attribute» Aerodrome.designator + designator :CharacterString [0..1] «Role» Aerodrome.runw ay «Contains» 0..* B.2 Tooling support? Figure 14. AIRM and AIRM* (star) model elements Support is given for Sparx Enterprise Architect 4. Namely, the star-model generation is facilitated by a tool that generates AIRM* and OuA* models. The Compliance Applicant can found it on the link below containing the software as well as guidelines on how to use it: B.3 How can it look like? The Figure 15 (next page) depicts the mapping artefact captured as a picture. This mapping artefact to be valid as the evidence of compliance shall have a completing reference to the XMI or EAP file that contains all the mappings of 33

31 Figure 15. UML mapping artefact 31 of 33

32 6 References Title [1] AIRM Compliance Framework [2] AIRM Foundation Rulebook Location ject%20plan/airm_compliance_framework.doc extranet site ject%20plan/forms/allitems.aspx [3] [4] Word template for the AIRM Compliance Report document. Excel template for the mapping artifact. her%20documentation/working_area/service_and_sy stem_support_team/guidance%20documents/airm_ Compliance_Report_Template.doc her%20documentation/working_area/service_and_sy stem_support_team/guidance%20documents/airm_ Compliance_Report_Template.xlsx 32 of 33

33 -END OF DOCUMENT- 33 of 33