AIRM Rulebook

Rule template

Recommendation template

Principle template

Last Version

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.

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.

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.

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.

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:

• 8.33kHz
• ADS-B
• ADS-C
• 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”.

Example: ValDistanceType

The name of a codelist shall begin with “Code” and end with “Type”

Example: CodeAirspaceType

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 ‘_”.

Example: NO_RESTRICTION

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: contains

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 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.

Example: ICAO

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'.

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.)

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.

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

==========================================

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 protected].

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.

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.

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.

Examples:

• 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.

Constraints and business rules present in the AIRM can be further restricted in a derived model. They cannot be extended.

Example: A business rule restricts the length of a CharacterString to 4 characters. It can be restricted to length [2] but cannot be extended to length [7].

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 [10].

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.

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 [6].

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.

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

Examples:

• • 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

Examples:

• 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.