Edition 1.0.0 MARCH 30th, 2019
Table of Contents
- 1. Introduction
- 2. Using the AIRM Rulebook
- 3. AIRM Modelling Environment
- 4. Content of the AIRM Components
- 5. AIRM Meta-Model
- 6. AIRM Model Elements
- 7. Definition Conventions
- 8. Diagram conventions
- 9. Intellectual Property Rights
- 10. General Principles, Rules and Recommendations
- 11. Detailed Rules on Specific AIRM Components
- 12. References
- Appendix A. AIRM Meta-Model
- Appendix B. Wording Syntax
The AIRM Rulebook provides principles, rules and recommendation in order to facilitate the development and maintenance of the AIRM. The principles, rules and recommendations are intended to be used for modelling, consolidation, validation and verification, and quality check purposes.
Purpose of the Document
The AIRM Rulebook provides principles, rules and recommendations for developing and maintaining the AIRM. This document is a normative rule book that focuses on providing definitions of vocabularies, principles, rules and recommendations.
The AIRM Rulebook is the basis for modelling the AIRM, assessing the quality of the AIRM (the AIRM UML models themselves). It is also used for internal AIRM harmonisation, consolidation, review and change management activities.
The AIRM Rulebook shall be used by contributors and submitters of model elements and change requests in order to increase the quality of their material.
It shall be used by participants in harmonisation and consolidation activities in their review, assessment and consolidation processes for checking quality, structure, semantics and other aspects. If a requested change or submission does not conform to a principle or rule then the breach may be reported back with the unique identity of the violated principle or rule.
|Shorthand to include the AIRM Conceptual Model, AIRM Logical Model and AIRM Contextual Model.
||A conceptual model is a model of the information about the concepts in the universe of discourse, relevant to the architecture effort.
||The logical model is a specification of business/operational information requirements as a formal data structure, where relationships and classes (entities) are used to specify the logic which underpins the
||A set of traces that establishes a semantic correspondence between a concept in an information definition and AIRM concepts.
|Information Definition under Assessment
||A formal representation of information concepts or data concepts which is subject to AIRM Compliance demonstration.
|Physical Data Model
||The physical data model specifies how the logical data model will be instantiated in a particular product or service. It takes into account implementation restrictions and performance issues whilst still enforcing
the constraints, relationships and typing of the logical model.
||A directed link from a concept in an information definition to an AIRM concept.
||Automatic Dependant Surveillance - Broadcast
||Automatic Dependant Surveillance - Contract
||ATM Information Reference Model
||American Standard Code for Information Interchange
||Air Traffic Management
||Berkeley Software Distribution
||Concept of Operations
||European ATM Architecture
||Extended Backus–Naur Form
||Estimated Taxi-Out Time
||Future Air Navigation System
||Global Unique Identifier
||International Civil Aviation Organization
||International Electrotechnical Commission
||Internet Engineering Task Force
||International Standards Organization
||Information Services Reference Model
||(UK) Ministry of Defence Architecture Framework
||NATO Architecture Framework
||North Atlantic Treaty Organisation
||NAF Operations View
||Namespace Specific String
||NAF System View
||Object Management Group
||Portable Document Format
||Single European Sky
||Single European Sky Air Traffic Management Research
||SESAR Joint Undertaking
||Standardization Agreement (NATO)
||Sub Work Package
||World Meteorological Organization
This section describes external documents and other artefacts that, through reference in this text, provide provisions that are considered as normative of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For each publication a description how it has been adopted/used in this set of documents is also provided.
Note: If a reference is expressed with a date then only that version, of the reference, is valid since it is not possible to guarantee that newer versions, of referenced document, does not adversely impact this document.
The following publications, documents and artefacts are considered as informative:
- UPDM v1.0, see 
All parts of the document should be read.
2. Using the AIRM Rulebook
The following terms are used in this document:
- Rules. These are mandatory and shall be applied.
- Recommendations. These are not mandatory. However, compliance is strongly advised.
- Principles. These give general statements about the AIRM.
The following editorial practice has been followed in the writing of the AIRM Rulebook:
- For Rules the operative verb “shall” is used.
- For Recommendations the operative verb “should” is used.
- For Principles a more general wording is used.
The term “AIRM models” is often used as shorthand to include the:
- AIRM Conceptual Model;
- AIRM Logical Model; and
- AIRM Contextual Model.
The rules, recommendations and principles are presented in logical groupings. This means that as new items are added they are inserted in the relevant group. Therefore, the numbering of the items is not consecutive. Indeed,
as items are removed, there may appear to be gaps in the numbering.
The following layout is adopted to ease the use of the document.
When the phrase “latest version” is used it always means at the time of publication of the AIRM Rulebook for this version of the AIRM.
3. AIRM Modelling Environment
The AIRM models shall be represented using the UML v2.1.
Note: This means the AIRM models are based on the meta-model that is defined by the OMG Superstructure document .
The AIRM models shall be exclusively expressed using UML::Class Diagram and UML::Package Diagram principles, notations and conventions.
The AIRM models should be developed and maintained using Sparx Enterprise Architect.
4. Content of the AIRM Components
AIRM Contextual Model
The AIRM Contextual Model shall contain a representation of the external standards and specifications that are necessary for AIRM modelling work.
When the UML construct available in the AIRM Contextual Model has no definition, the definition from the corresponding standard or specification shall apply.
Note: This rule is necessary as not all of the UML models imported into the AIRM Contextual Model contain the definitions from the corresponding standard or specification.
The AIRM Standards Catalog shall list the standards which are acceptable sources for modelling the AIRM.
AIRM Conceptual Model
The AIRM Conceptual Model shall contain definitions of model elements that are part of an ATM operational language, satisfying operational requirements and concerns. The model elements are defined without the consideration of solution, system and implementation aspects.
It is recognised that one of the purposes of the AIRM Conceptual Model is to ensure that the operational language is fully understood and can be communicated to operational experts and modellers.
AIRM Logical Model
The AIRM Common Subject contains definitions of information constructs that are assessed as reusable in relation to other operational entities.
Entities that are defined in two or more subject should be relocated to the Common Subject.
Entities that are considered as domain neutral (usable in the context of other industries such as automotive) should be relocated to the Common Subject.
Example: Address is a general information entity with wide cross-industry applicability.
5. AIRM Meta-Model
The AIRM UML Models shall conform to the AIRM meta-model contained in Appendix A.
The AIRM models shall make use of the following UML model elements: class diagram, package diagram, package, class, attribute, role, dependency, association (including specialisation, aggregation and composition), association class and note. Other UML model elements, such as templates, shall not be used.
The model elements in the AIRM Conceptual Model and AIRM Logical Model shall use one of the following stereotypes:
- < < Subject > > . Represents a field of specific knowledge. These appear as packages in the AIRM.
- < < Information_Message > > . ATM specific message type. This appears as a UML class in the AIRM.
- < < Information_Entity > > . A definition (type) of an operational ATM item of interest that is subject to constraints. This appears as a UML class in the AIRM.
- < < Data_Entity > > . A definition (type) of a data (ATM) item of interest that is implementation independent and is subject to constraints. This appears as a UML class in the AIRM.
- < < Data_Object > > . A standardized or formalized collection of a Logical ModelEntity's or association’s Properties.
- < < CodeList > > . CodeList is used to describe a flexible and open enumeration UML::Enumeration. This appears as a UML class in the AIRM.
- < < DataType > > . DataType is the abstract class that represents the general notion of being a data type (i.e., a type whose instances are identified only by their value). This appears as a UML class in the AIRM.
- < < Measure > > . A Measure is the result from performing the act or process of ascertaining the value of a characteristic of some entity. [ISO 19103]
- < < UnitOfMeasure > > . A unit of measure is a quantity adopted as a standard of measurement for other quantities of the same kind. [ISO 19103] In the AIRM, this is modelled as a CodeList with a restricted meaning.
Note: The AIRM meta-model contains more model elements and stereotypes which are used, e.g., in the context of AIRM compliance.
Note: The rulebook consistently refers to AIRM meta-model elements. Reference to the UML specification are explicitly identified by the “UML::” package prefix.
6. AIRM Model Elements
The AIRM models shall not contain model elements with a purpose to support a specific implementation, algorithm, technology or solution.
Note: Adding such constructs to a model in general imposes constraints that may make a model unnecessarily dependent on implementation decisions. The AIRM models should be focused on describing information needs independent of implementation and technological decisions.
Subjects shall provide a documented rationale explaining the boundaries of the subject.
Note: The rationale is intended to be used to assess, during consolidation, if an entity is a natural part of a subject.
The content of an AIRM Subject shall be documented / illustrated by at least one UML class diagram that portrays those entities and their associations which are most essential to an understanding of the scope of the Subject.
All entities and objects shall appear on at least one UML class diagram.
Names of model elements shall only use characters that are in ASCII ranges 48-57 (numbers), 65-90 (capital letters) and 97-122 (small letters).
In addition, the following are characters are allowed in codelist values to separate words: 95 (underscore).
The ASCII 45 (hyphen), 46 (point), 47 (forward slash) characters shall be allowed if the name of a model element appears below:
- FANS 1/A
Note: The list of exceptions is managed by the AIRM Change Control Board Support Office and takes into account the following:
- The name contains a specific character
- The name refers to a concept widely shared amongst aeronautical community
- Keeping the name the way it is known enables an easier understanding of the model
Name parts and words shall not begin with numbers (0-9) unless an adopted standard mandates such spelling.
Verbs (if any) shall be in the present tense.
Abbreviations and acronyms shall not be used in names of model elements except where they appear in the Abbreviations section of the AIRM Contextual Model.
Names of model elements shall be in the English language following the terms as identified by ICAO or other standard present in the AIRM Standards Catalog. If no term can be identified, the latest version of the Oxford English Dictionary shall be used.
Where conflicting spellings exist for the names of model elements, the spelling listed as the primary British spelling in the Oxford English Dictionary shall be used.
All model element names shall be unique within enclosing namespace(s).
Example: All entities shall be uniquely named within an AIRM model.
Example: All properties shall be uniquely named within the enclosing entity.
Example: All values must be unique within the enclosing codelist.
The name of a subject or other UML::Package shall be expressed using the UpperCamelCase principle.
The name of an entity, object, codelist or datatype shall be expressed using the UpperCamelCase principle.
Note: This rule does not apply to imported standards in AIRM Contextual Model. These might deviate from this rule.
The name of a property shall be expressed using the lowerCamelCase principle.
The name of a role shall be a noun describing the role of the associated entity.
The name of a data type shall end with “Type”.
The name of a codelist shall begin with “Code” and end with “Type”
The name of a value contained in a codelist shall be UPPER_CASE. Spaces shall not appear in the value and words shall be separated by the underscore character ‘_”.
Exception: This rule does not apply if the name of the value is a recognised term such as an abbreviation. In this case the name of the value should be represented as the recognised combination of UPPER and lower case characters.
If given, the name of an association shall be expressed using lower case.
Example: expressed as.
If given, the name of an association shall be represented as either a verb or a verb phrase.
Example: omit “is” when followed by verb-phrase; e.g., instead of “is enabled by” have only “enabled by”, i.e., skip the verb.
In the AIRM Conceptual Model, the name of an association should, where possible, be based on verbs found in the definitions of the associated entities which relate the entities.
In the AIRM Conceptual Model, associations which are merely possible/probable or imprecise shall be given a multiplicity rather than reflecting this status as part of the association name.
Example: An association which can be expressed using such words as “can have”, “may have” or “may be” shall have a multiplicity and the association shall not have the word in its name.
The author of a model element shall be given in the "Author" property. The author shall be the person or project which created the model element.
Entities shall be stereotyped as << Data_Entity >> in the AIRM Logical Model and as << Information_Entity >> in the AIRM Conceptual Model.
A model element with the stereotype << Data_Entity >> shall be a specialisation of the abstract Entity.
Note: Entity is obviously exempt from this rule.
Note: The specialisation can be via a more generalised entity e.g. TemporalEnabledEntity.
Entities shall not inherit from model elements with the stereotype <<Data Type>>, <<CodeList>>, <<Measure>>, <<UnitOfMeasure>>, <<Subject>>, <<Information_Message>> or <<Data_Object>>.
Model elements shall not be represented as ‘root’ or ‘leaf’.
Note: It is impossible, in the context of ATM, to know that the AIRM is complete.
Logical Model Objects
A model element with the stereotype <<Data_Object>> shall be a specialisation of the abstract Object.
Note: Object is obviously exempt from this rule.
Note: The specialisation can be via a more generalised object.
All properties of an entity, object or datatype shall be given "public" access privileges/scope.
In the AIRM Logical Model, attributes shall only be typed by datatypes.
Note: This means that they should not be typed by other entities or objects from the AIRM Logical Model.
Note: This rule does not apply in the AIRM Conceptual Model, so attributes can be typed by other entities. This can help the readability of the model.
In the AIRM Logical Model, attributes shall be typed by:
- Data types found within the ISO series of standards present in the AIRM Contextual Model; or
- Data types found within the AIRM Logical Model’s DataTypes package; or
- Codelists found within a Subject.
- ISO19103 contains primitives for Real, CharacterString, DateTime
- ISO19107 contains geometry constructs
- ISO19108 contains temporal constructs
- ISO 639-2 contains language codes
Note: AIRM specific data types which specialise or otherwise reuse the ISO series can be found in the AIRM Logical Model’s DataTypes package.
Note: AIRM specific codelists can be found in dedicated packages within the relevant Subject.
In the AIRM Logical Model, attributes shall, by default, be represented with multiplicity of [0..1] (zero to one). If an operational constraint has been identified then multiplicities shall be chosen to reflect such constraints.
Note: If no explicit attribute multiplicity is given, [0..1] multiplicity is implied.
Note: Further constraints on multiplicity may be added in "AIRM Derived" models.
In the AIRM Logical Model, role names shall, by default, be represented with multiplicity [0..*] (zero to many). If an operational constraint has been identified then multiplicities shall be chosen to reflect such constraints.
Note: If no explicit role name multiplicity is given, [0..*] multiplicity is implied.
Note: Further constraints may be added in "AIRM Derived" models such as in Physical Data Models.
Datatypes shall not be used as an end-point in an UML::Association.
Associations between entities shall be modelled using an UML::Association where navigability is unspecified.
A model element with the stereotype <<Data_Object>> shall be made part of a <<Data_Entity>> or another <<Data_Object>> by means of a UML::Aggregation association.
In the AIRM Conceptual Model every association (except specialisation/generalisation) shall have at least:
- One association name with a labelled direction, or
- One role name. The role names shall be added to the end of the association which has semantic significance (i.e. as the property of an entity). In the case of UML::Aggregation and UML::Composition the role name shall be added only at the “part” end of the association.
In the AIRM Logical Model every association (except specialisation/generalisation) shall have at least one role name. The role names shall be added to the end of the association which has semantic significance (i.e. as the property of an entity). In the case of UML::Aggregation and UML::Composition the role name shall be added only at the “part” end of the association.
Associations shall not be named in the AIRM Logical Model.
Note: Role names should be used in preference to relationship names. However, it is accepted that naming relationships can improve the readability of the AIRM Conceptual Model which is why this rule is limited in scope.
In the AIRM Conceptual Model, any association name information supplied shall be considered informative, i.e. it will not have to be respected by derived models or by the AIRM Logical Model.
UML::Specialisation should not be given an association name or a role name.
Rationale: UML::Specialisation has a pre-defined (semantic) meaning in UML as a special type of UML::Association.
UML::Aggregation and UML::Composition should not be given an association name.
Rationale: UML::Aggregation has a pre-defined (semantic) meaning in UML as a special type of UML::Association.
The use of association classes should be limited. However, they may be used to model attributes specific to one specific relationship, in situations where the association management business process is unspecified or out of scope of the model.
Aggregation and composition
The use of UML::Aggregation and UML::Composition between entities should be avoided where possible. They should be used only where there is a real-world constraint or they are otherwise allowed by a rule.
An entity can be a specialisation of more than one general entity.
Rationale: Generalisation and specialisations commonly occur in models where concerns such as data structures, algorithms, technology, implementations etc. are not considered.
Note: The UML terms of generalisation and specialisation is preferred over ‘inheritance’ in order to be aligned with UML and NAF terminology. The term inheritance is often associated with technical /programming thinking and aspects.
If a single-generalisation modelling construct can be found, with the same modelling effect as a multiple-generalisation modelling construct, then that construct shall be selected.
Rationale: Extensive use of multiple generalisation and specializations may create complex models that may be more difficult to extend over time.
Deep generalisation and specialisation hierarchies should be avoided.
The issuing Authority of a codelist shall be identified and represented by an AIRM::TaggedValue ‘Authority’, attached to the codelist.
Note: More than one Authority may be attached to a codelist in case of joint governance.
7. Definition Conventions
A good definition:
- Is a dictionary-style statement that describes the concept designated by a term.
- Helps to establish the textual match between languages by stating the essential and delimiting characteristics of a concept (semantic feature).
Note: The quality of the definition is crucial, because without knowing what is meant exactly, we cannot communicate effectively, and without fully understanding the concept, we cannot establish relationships between concepts in our subject field.
All model elements within the AIRM shall have a definition.
If Sparx Enterprise Architect is used to maintain the AIRM (see Recommendation 7), a definition of an AIRM model element shall be stored in the Notes feature.
The definition shall use the following principles for good definitions:
- Predictability - the definition inserts the concept into a concept system.
- Simplicity - the definition is concise, clear, and whenever possible no longer than one sentence; it includes only essential information.
- Affirmativeness - the definition states what the concept is, rather than what it is not.
- Non-circularity - the definition does not use words whose definitions refer back to the concept in question, nor does it begin with the term itself.
- Absence of tautology - the definition is not a paraphrase of the term, but rather a description of the semantic features of the concept.
- Part of speech - the definition begins with a word of the same part of speech as the term being defined.
Example: aerodrome: a defined area on land or water (including any buildings, installations and equipment) intended to be used either wholly or in part for the arrival, departure and surface movement of aircraft/helicopters.
Note: Stating a synonym is not a definition!
The source of a model element definition shall be represented in a AIRM::TaggedValue, ‘Definition:Source’ that indicates its origin.
The 'Definition:Source' for a model element shall be listed in the AIRM Standards Catalog.
Extra details concerning the source of a model element definition should be captured in the AIRM::TaggedValue 'Defintion:SourceDetail'.
Example: This can be used to pinpoint the exact ICAO document used or a section within a larger document.
The 'Definition:Adapted' AIRM::TaggedValue shall be completed in order to indicate the level of semantic correspondence with the source definition. The list of values is:
- ExactCopy: Definition of source and target are exact copy of each other.
- SyntacticallyEqual: Syntax corrections (grammar, spelling)
- Rewritten: The definition has been rewritten for improved quality. The meaning is the same, i.e. the definition still describes exactly the same entity as the target definition.
- Specialised: Source definition is a special case of the target definition.
- Generalised: Source definition is a generalised case of the target definition.
A definition shall not contain references to a name of the submitter, origin or external model or source.
A definition shall not contain references to how it is used.
Example: “This is primarily used by x, y, and z” is not an allowed definition.
Definitions shall contain a “straight definition”. That is, they should not start with “This class defines…” or “This property represents…”.
The status of a model element definition shall be represented in an AIRM::TaggedValue 'Definition:Status'. It shall be one of the following:
- Proposed: The definition has been created or reworked.
- Under Review: The definition is under review by experts.
- Approved: The definition has been approved.
- Under Rework: The definition has been reviewed and/or approved but is subject to change.
Any synonyms for a model element's name shall be represented as a comma separated list in an AIRM::TaggedValue 'Definition:Synonyms'.
Any abbreviation or acronym for a model element's name shall be represented in an AIRM::TaggedValue 'Definition:Abbreviation'.
8. Diagram Conventions
In the AIRM Conceptual Model, UML is used to create two types of diagram:
- Hierarchy diagrams which are used to express taxonomies using UML::Specialisations
- Analysis diagrams which are used to give a narrative about the AIRM model elements contained on the diagram expressed as a (network) of, for example, UML::Associations, UML::Roles and Diagram::Notes.
In the AIRM Conceptual Model, a diagram shall be either a “hierarchy” diagram or an “analysis” diagram.
In the AIRM Conceptual Model, a diagram shall have a stereotype of <<Analysis>> or <<Hierarchy>> assigned.
In the AIRM Conceptual Model, every <<Analysis>> diagram shall be documented by explaining the following:
- Content: What is this diagram about? (mandatory)
- (Maturity) Status - <free text> (mandatory)
In the AIRM Conceptual Model, every <<Analysis>> diagram should be documented by explaining the following:
- Assumptions (optional)
- Additional comments (optional)
- Link to Requirements (optional)
In the AIRM Information Model all diagrams should be possible to read on an A4 format (either in landscape or portrait.)
9. Intellectual Property Rights
All parts of the AIRM shall have following the BSD-type licence attached:
Copyright (c) 2019, Members of the AIRM CCB
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 name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
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
Editorial note: this license is an instance of the BSD license template as provided by the Open Source Initiative: http://opensource.org/licenses/BSD-3-Clause
Details on the AIRM CCB and a list of its members is available on request from email@example.com.
10. General Principles, Rules and Recommendations
Evolution refers to how model elements evolve over time (e.g. version, status, lifecycle, etc).
The status of a model element shall be given in the "Status" property. The value shall be one of the following:
- Proposed: The model element has been created but is not mature enough for use by others or for publication.
- Implemented: The model element has been finalised and has been verified. It is mature enough for use by other parties involved in building the AIRM but is not ready for publication.
- Published: The model element is implemented and has been included in an official AIRM release.
- Validated: The model element has been published and validated.
- Under Rework: The model element has been published/validated but is being reworked. (Note: it is still part of the AIRM in its latest released version.)
- Deprecated: The model element is no longer fit for use and will deleted in the version stated in the AIRM::TaggedValue "Deprecated:TargetRelease".
- Obsolete: The model element has been marked deprecated in the current release version and will be deleted in the next release.
The allowed combination of model element status (AIRM_Rule 65) and definition status (AIRM_Rule 61) are:
- If the status of a model element is "Proposed", its Definition:Status shall be "Proposed", "Under Review", "Approved", or "Under Rework".
- If the status of a model element is "Implemented", its Definition:Status shall be "Under Review" or "Approved".
- If the status of a model element is "Published", its Definition:Status shall be "Under Review " or "Approved".
- If the status of a model element is "Validated", its Definition:Status shall be "Approved".
- If the status of a model element is "Under Rework", its Definition:Status shall be "Proposed", 'Under Review", "Approved" or "Under Rework".
Deprecation of a model element indicates that it is about to be deleted in a subsequent release.
A model element that is marked as deprecated should not further be used and a warning or error should be emitted if it is actually used.
A model element that is marked as deprecated shall contain the following AIRM::TaggedValues:
- Deprecated:DecisionDate: (mandatory) date of deprecation decision
- Deprecated:Rationale: (mandatory) short rational for the deprecation
- Deprecated:TargetRelease: (optional) planned release when the deprecated element will be deleted
- Deprecated:Replacement: (optional) reference to other elements that should or shall be used instead
A model element shall be deleted from the model only after it has been marked as “Deprecated” in a previous release.
A model element that is to be deprecated shall be listed in the AIRM Release Notes.
AIRM Internal Semantic Trace from Logical Model to Conceptual Model
In the AIRM Logical Model, every entity shall have at least one semantic trace to at least one model element in the AIRM Conceptual Model.
An AIRM supplement is a package within the AIRM that elaborates the AIRM content for a specific community
The supplements shall fit within the scope of the AIRM, meaning that it should be relevant to ATM.
The supplement shall follow the same rules as other AIRM content.
Note: this means following naming conventions, stereotypes, completion of metadata about a model element, etc.
The supplement shall follow the structure of the main AIRM.
Note: this means it may have a contextual, a conceptual and a logical model. Indeed, it must have at least one of these.
The supplement shall not introduce new model types such as physical models.
The supplement should not have dependencies on the content of other supplements.
Note: this is to ensure that the change management of one supplement does not affect another supplement. However, reuse of definitions across supplements is to be encouraged.
The supplement shall not remove or otherwise restrict the content of the main AIRM.
Note: supplements are about elaborating the content of the main AIRM. The ability to restrict the AIRM is handled by the AIRM derivation rules and should be handled as a separate step in the development cycle.
Supplements shall contain, where necessary:
- additional subjects;
- additional entities;
- additional objects;
- additional data types;
- additional relationships;
- additional properties;
- additional local definitions.
The model elements in the supplement shall have URNs.
The relationship between two model elements is owned by the source. This applies to associations between model elements and to the properties of a model element that are typed by another model element. For example, if Class1 “has” Class2, the “has” association is owned by Class1; if Class 1 contains a property “name” that is typed as a CharacterString, the “name” property is owned by Class 1.
The main AIRM content cannot “own” an association or property where the target exists in a supplement.
When supplementing a model element from the main AIRM, the supplement shall use the same name as the model element that it is supplementing.
When supplementing a model element from the main AIRM, the supplement shall use the same definition as the model element that it is supplementing.
When adding properties to a model element from the main AIRM, the supplement shall use a specialization of the model element that it is supplementing.
When adding relationships to a model element from the main AIRM, the supplement shall use a specialization of the model element that it is supplementing.
The specialization association shall be stereotyped <<supplement>>.
Note: This makes the exact nature of the specialization clear.
Additional local definitions shall be added to the note field, below the existing definition, separated by a <<supplement>> stereotype
Derivation refers to the way in which model elements can be restricted and subsetted by users of the AIRM. Adaptation is also related to compliance.
An AIRM Derived Model is a model that uses the AIRM to define its semantics but serves a specific restricted purpose.
- A NSV-11b product shall be a derived model.
- Existing models shall prove they are "derivable from" the AIRM as a key element in claiming compliance with the AIRM.
AIRM Derivation Rules are the set of rules to apply in order to establish traceability of the semantics of a given model to the AIRM.
Derivation of the AIRM works by restriction. Therefore:
- Any additional model elements of an AIRM Derived Model, assumed to be within the scope of the AIRM, should be traced to a Change Request identifier in the semantic correspondence statement of the Information Definition.
- Any additional model elements, assumed to be outside the scope of the AIRM, should be traced to the “Out-Of-Scope” construct in the semantic correspondence statement of the Information Definition.
A derived model shall declare any deviation from the AIRM Rulebook.
Note: For example, the AIRM naming conventions may not be applicable to an already existing model. In that case, deviations from the AIRM Rulebook shall be documented and explained.
The upper bound of the multiplicity specified in a derived model shall be lower or equal to the upper bound of the multiplicity and greater or equal to the lower bound of the multiplicity specified in the AIRM.
The lower bound of the multiplicity specified in a derived model shall be greater or equal to the lower bound of the multiplicity and lower or equal to the upper bound of the multiplicity specified in the AIRM.
A derived model may declare leaf nodes final.
A derived model may describe physical implementations of generalisation.
A derived model may describe physical implementations of generalisation.
A derived model may add navigability to its relationships.
Note: This does not mean that the associations cannot be navigated in the other direction but the directionality is a hint that implementations should make the navigation in the primary direction convenient and efficient.
Further constraints (including patterns, maximum values) may be added to a derived model.
Example: The length of datatypes may be restricted. For example, in the AIRM CharacterStrings are not given a maximum length. They can be restricted e.g. to length .
A derived model may convert an attribute to a role name or vice versa. This means:
- A property modelled as an UML attribute in the AIRM may be converted into a property modelled as a role, with a complex “constructed” type.
- A property modelled as a role name in the AIRM may be converted into an attribute (e.g. if multiplicity is restricted to 1..1).
A derived model shall not use an AIRM term with a conflicting definition.
Note: If a derived model does not use the original AIRM definition, a reference to the AIRM definition needs to be provided.
In a derived model, AIRM codelists:
- May remain as codelists; or
- May be converted to enumerations (which can be seen as a restricted codelist); or
- May be converted to a series of classes.
AIRM Uniform Resource Name (URN)
To facilitate the referencing of the AIRM, each AIRM model element has a globally unique name. This unique name is defined according to the Uniform Resource Name (URN) standard .
The URN of an AIRM model element shall use the structure: <URN> ::= "urn:" <NID> ":" <NSS>
Example: A full URN to a property of an entity: urn:aero:airm:1.0.0:ConceptualModel:Subjects:AirTrafficOperations:AirportOperationsManagement:TaxiOut@EXOT
Note: An AIRM namespace identifier (NID) and namespace specific string (NSS) are defined in Rules 70-72 and 74, respectively.
AIRM model elements shall use the namespace identifier (NID): NID = aero
The namespace specific string (NSS) shall use the structure: NSS = <MODEL_NSS>:<ELEMENT_NSS>
The Model Namespace Specific Strings (MODEL_NSS) shall use the structure: MODEL_NSS = <ISSUER>?':'<PRODUCT>':'<VERSION>
The following terms are used in <MODEL_NSS>
- <ISSUER> defines the agency responsible for the AIRM version in question (where applicable). This item shall be a URI itself.
- <PRODUCT> identifies the AIRM (or an AIRM Derived Model by the same issuer).
- <VERSION> is the version number of the product in question. The syntax and semantics are issuer specific (e.g. may or may not include issuer specific branch information).
Note: The components of the MODEL_NSS are considered as case insensitive, e.g. AIRM and “airm” refer to the same product.
The Element Namespace Specific Strings (ELEMENT_NSS) shall use the structure: ELEMENT_NSS = (<NAME_OF_PACKAGE>':')+(<NAME_OF_CLASS>(@<NAME_OF_PROPERTY)?)?
The following terms are used in <ELEMENT_NSS>
- <NAME_OF_PACKAGE> is the recursive definition of the model element’s position within the AIRM UML Package structure
- <NAME_OF_CLASS> is the name of the UML Class in question (where applicable)
- <NAME_OF_PROPERTY> is the name of the UML property within the class (where applicable)
Note: The components of the ELEMENT_NSS are considered case sensitive.
The ISSUER component of the MODEL_NSS shall be left empty.
The PRODUCT component of the MODEL_NSS shall be: PRODUCT = AIRM.
The URN of AIRM Contextual Model elements that already have a URN issued by their originator shall be respected. This means that these elements shall uniformly be referenced by the original URN and the AIRM shall not issue an additional URN for these elements.
Models derived from the AIRM should reference MODEL_NSS to disambiguate their semantic binding to the AIRM.
Published AIRM model element semantics shall be backward compatible.
That is, a given ELEMENT_NSS referring to an AIRM model element in development status “published”, “validated”, “under rework” or “deprecated” shall always refer to the same logical concept. Its semantics shall not depend on the context of a MODEL_NSS.
11. Detailed Rules on Specific AIRM Components
AIRM Technical Standards Profile
Each standard in “AIRM Standards Catalog: UML” shall follow the minimum standard description syntax as depicted below:
where the publishing organisation is either the organisation behind the standard or a concatenation of the organisation, a hyphen, and its publishing part
where the publishing organisation is either the organisation behind the standard or a concatenation of the organisation, a hyphen, and its publishing part
- • OMG UML
- NATO STANAG 3809
Note: The wording syntax is fully explained in Appendix B.
Each standard in “AIRM Standards Catalog: UML” should follow the full standard description syntax as depicted below:
where the minimum standard description is explained as part of the AIRM_Rule 127
where document name follows the syntax below
where standard version follows the syntax below
where Volume follows the syntax below
- ICAO Doc 8168, Vol. I, 5th Ed
- ICAO Doc 8400, 8th Ed
- NATO NAF v.3
Note: The wording syntax is fully explained in Appendix C.
||NATO Architecture Framework (NAF), v3
||OMG Unified Modelling Language (UML), v2.1
||OMG Semantics of Business Vocabulary and Business Rules (SBVR), v1.0
||OMG UML Superstructure
Appendix A. AIRM Meta-Model
|Meta-Model Element Name
|AIRMConstraint||An element of guidance that introduces an obligation or a necessity, i.e., a rule that applies to AIRM model element(s). Rules shall be satisfied by all instances of the AIRM Entities they apply to. Exception: AIRM::Constraint does not cover multiplicity nor ordering constraints. Those are captured as a part of standard UML.|
|Attribute||A defined property of an AIRM Entity.|
|Constraint:AppliesTo||Rule that applies to the AIRM Entity or property|
|Constraint:FormatType||Provides format for articulation of the constraint|
|defines||A formalised representation of data which is managed by or exchanged between systems.|
|Definition:InLexicon||Whether the term definition is in the ATM Lexicon.|
|Definition:Source||Source for a definition.|
|Definition:Status||Status of the definition.|
|Definition:Synonyms||Synonyms for the definition.|
|Deprecated:Decision date||Date of deprecation decision.|
|Deprecated:Rationale||Short rationale for the deprecation.|
|Deprecated:Replacement||Reference to other elements to use instead.|
|Deprecated:TargetRelease||Planned release to delete deprecated element.|
|Mapping:Remarks||Remarks on a mapping from a source to a target.|
|SemanticTrace::Information_Entity||Trace between Data_Enitity to Information_Entity/Information_Message.|
|SemanticTrace::Information_EntityRole||Trace between Data_Entity and Conceptual Model role name.|
|MEGA:UniqueIdentifier||Unique identifier for integration with Mega.|
|represents||A formalized representation of information, subject to an operational process.|
|Data_Entity||A definition (type) of an data (ATM) item of interest that is implementation independent and it is subject to constraints.|
|Data_Object||A standardized or formalized collection of an (Logical Model) Entity's or Association’s Property/(ies).A Data_Object does not exist without the (Logical Model) Entity or Association it is associated with but can be part of the operational language or system-specific property. This appears as a UML class or association class in the AIRM.|
|ISO:CodeList||CodeList is used to describe a flexible and open enumeration UML::Enumeration.|
|ISO:CodelistLiteral||A value listed in the codelist|
|Entity||A definition (type) of an ATM item of interest that is subject to AIRM representational rules.|
|Contextual_Entity||Entity that internally represents part of a standard.|
|Information_Entity||A definition (type) of an operational ATM item of interest that is subject to constraints.|
|Information_Message||ATM specific message type.|
|NAF::Alias||lang=EN-US mso-ansi-language:EN-USAn alternative name for an element.|
|NAF::Attribute||A defined property of an Entity.|
|NAF::Definition||A definition of an element in the architecture. Note - every element added by an architect must have a definition.|
|NAF::Entity||A definition (type) of an item of interest.|
|NAF::Standard||A ratified and peer-reviewed specification that is used to guide or constrain the architecture.|
|Property||A property is a typed element that represents an attribute of a class hat is subject to AIRM representational rules.|
|Role||(AIRM) Role represents an attribute of the source Entity's associationEnd.|
|Standard||A document that provides requirements, specifications, guidelines or characteristics that can be used consistently to ensure that materials, products, processes and services are fit for their purpose. [ISO]|
|StereotypeAttribute||From UML version 2.0 the previously independent tagged value is considered to be a stereotype attribute. The name tagged value is still kept. Each stereotype has zero or more tag definitions, and all stereotyped UML elements have the corresponding number of tagged values.|
|Subject||Represents a field of specific knowledge. These appear as packages in the AIRM.|
|TaggedValue||Tagged Value is a string-based extension that could be attached to UML model elements in a flexible way.|
|UML: DataType||DataType is the abstract class that represents the general notion of being a data type (i.e., a type whose instances are identified only by their value).|
|ISO:Measure||A Measure is the result from performing the act or process of ascertaining the value of a characteristic of some entity. [ISO 19103]|
|ISO:UnitOfMeasure||A unit of measure is a quantity adopted as a standard of measurement for other quantities of the same kind. [ISO 19103]|
|UML::Element||An element is a constituent of a model. As such, it has the capability of owning other elements.|
|UML::ModelElement||An element is a constituent of the AIRM UML model.|
|UML::Property||A property is a typed element that represents an attribute of a class.|
|UML::Slot||A slot specifies that an entity modeled by an instance specification has a value or values for a specific structural feature.|
Appendix B. Wording Syntax
This Appendix presents a notation for wording syntax, based on a visualisation of Extended Backus–Naur Form (EBNF) and is adopted as subset of the ISO/IEC 14977:1996(E) standard.
Indicates a mandatory element.
|Indicates order between two (mandatory) elements. Meaning that “name_1” has to be followed “name_2” in order to satisfy the “full_name” syntax.
|Indicates an optional element.
|Indicates a mandatory element, which may occur several times.
|Indicates an optional element, but which may occur several times.
Indicates a choice between two elements. Either one or the other one must be used.
More than one element can appear on an optional, choice or mandatory branch.