SWIM Supporting Material
Information Service Overview Handbook v1.1
Introduction
The Information Service Overview is introduced in the ICAO Procedures for Air Navigation Services – Information Management (PANS-IM, Doc 10199) that has applicability on 28 November 2024.
An information service provider shall provide an information service overview for each version of each information service. The information service overview is "A set of information service metadata intended to promote information service discovery and an initial evaluation of the information service characteristics". As such, it enables information service consumers to compare between different information services.
This page contains supporting material. The content is mature but is subject to review, comment and change by the SWIM Community of Interest.
Good to know
The Service Orientation Process lists the Information Service Overview as an outcome of the design step (the service has a "Prospective" lifecycle status). This is an announcement by the service provider of an implemented service to come.
It is then updated by the service provider during the implementation step and completed at deployment (the service has an "Operational" lifecycle status).
Glossary
Term | Definition |
|---|---|
Information service overview | A set of information service metadata intended to promote service discovery and an initial evaluation of the information service characteristics. |
Operational (status of a service) | The status indicating that the service is employed in its operational environment. |
Prospective (status of a service) | The status indicating that the service is being designed, developed, or tested for operational activities and is expected to be available in the future. |
Retired (status of a service) | The status indicating that active support for the service has been withdrawn, the service has been partially or totally replaced by a new service, or an upgraded service has been installed. |
(Source: https://reference.swim.aero/glossary.html )
Requirements for information service overviews
PANS-IM states that:
Information service providers shall provide information service metadata through information service overviews.
Information service overviews shall be structured using the metadata fields in Table 5-1. This practice facilitates discoverability of information services and enables information service consumers to compare different information services.
Information service providers shall provide a complete description of all metadata fields in the information service overview for each version of an information service.
Information service providers shall inform consumers where they can access the information service overviews and the metadata on information services therein.
The uniform resource locator (URL) where information service overviews are publicized shall be included in the AIP. In case a SWIM registry is used (see 5.4), the URL shall be the one of the registry.
Content of an information service overview
The content of an information service overview is outlined in Table 5-1 of the PANS-IM. Each field must be completed (using "NIL" where allowable and applicable.)
The following table provides supporting material for the content. It:
details the required content (field name) of an information service overview.
includes the requirements for the field based on the PANS-IM and the field schema.
provides example content based on the Example service description - Donlon TOBT Setting Service.
provides the relationship to the SWIM Service Description Specification. This shows how the content of a service description can be used to create a service overview.
Information Service Overview Field Name | Information Service Overview Requirements | Relationship to EUROCONTROL Specification for SWIM Service Description Edition 2.0 | Field schema | Example Content - Based on Donlon |
|---|---|---|---|---|
Information service name | Information service providers shall name the information service. | This requirement is covered by SWIM-SERV-040 Service identification. | Free text | TargetOffBlockTimeSetting |
The name of the information service should enable information service consumers to reference or identify the information service. | The ability to identify the service is given in the rationale of SWIM-SERV-040 Service identification. It is not possible to turn this into a verifiable requirement. | |||
The name should provide an indication of the purpose of the information service. | The notes to SWIM-SERV-040 Service identification include a best practice on the 'indication of purpose' in the name. The service description describes the running service. It does not impose requirements on the design of the service. Therefore, the ‘indication of the purpose’ is a best practice rather than a requirement. | |||
Information service version | Information service providers shall provide versioning to the information services. | This requirement is covered by SWIM-SERV-040 Service identification. | n.n[.n] | 1.3.0 |
The service version shall be provided in numerical format (n.n[.n]). | The notes to SWIM-SERV-040 Service identification include a best practice on using a numerical format The service description describes the running service. It does not impose requirement on the design of the service. Therefore, the ‘numerical format’ is a best practice rather than a requirement. | |||
The version of the information service shall allow information service consumers to distinguish between versions of an information service. | The ability to distinguish versions is covered in the rationale of SWIM-SERV-040 Service identification. It is not possible to turn this into a verifiable requirement. | |||
Information service life cycle status | Information service providers shall specify the stage that the information service version is currently in as one of three stages: prospective, operational or retired. | This requirement is covered by SWIM-SERV-110 Service lifecycle information. The three phases mentioned in PANS-IM are in the notes to SWIM-SERV-110 Service lifecycle information and are available at: https://reference.swim.aero/information-services/service-categories/CodeLifeCycleStageType.html | Prospective or Operational or Retired | OPERATIONAL |
Note.⸻ For more information on service stages see Doc 10203. | ||||
Information service life cycle date | Information service providers should include the dates for current and future lifecycle stages. | This requirement is covered by SWIM-SERV-110 Service lifecycle information. | YYYY-MM-DD | since 2020-04-07 |
The planned date of retirement should be listed whenever it is known to exist. | ||||
If an information service provider does not make the date available, the information service life cycle date metadata field shall specify “NIL”. | The use of NIL is not outlined in the specification. | |||
Note.⸻ In the case of a prospective stage, the date indicates the date by which the information service provider plans to make the information service operational. | ||||
Information service functions | Information service providers should provide a description of the business level characteristics of the information service functions. This will provide information service consumers a business view of the interactions with the information service, without having to look at the interface details. | This requirement is covered by SWIM-SERV-140 Service functions. | Free text or NIL |
|
The description should include the functionality of the service as a list of the functions and real world effects. | This requirement is covered by SWIM-SERV-140 Service functions. | |||
If an information service provider does not make the information service functions available, the information service functions metadata field shall specify “NIL”. | The use of NIL is not outlined in the specification. | |||
Information category | The information domain(s) covered by the information service shall be listed as one or more of the following: | This requirement is covered by SWIM-SERV-100 Service categories. SWIM-SERV-100 Service categories allows this to be added in conjunction with https://reference.swim.aero/information-services/service-categories/CodeInformationDomainType.html . | Flight information; and/or Aeronautical information and/or Meteorological information and/or Environment information and/or Capacity, demand and flow information and/or Surveillance information and/or Other information | FLIGHT INFORMATION |
Brief description of the information service | Information service providers shall provide a brief description of the information service to assist information service consumers on whether the described service is suitable for use in a particular situation. | This requirement is covered by SWIM-SERV-050 Service abstract. | Free text (intended use) | The TargetOffBlockTimeSetting service supports the Airport CDM concept and its implementation by allowing A-CDM Partners, typically aircraft operators and ground handlers, with the capability to set the Target Off-Block Time (TOBT) that indicates the target time for the aircraft to be ready for Off-Block. It is part of a set of services supporting the Airport CDM concept and its implementation by providing the A-CDM partners with Common Situation Awareness about flights at a CDM airport. |
The brief description shall include the information domain(s) covered by the information service, the operational need being addressed by the information service, the intended use of the information service, and the intended consumer audience for the information service. | The note to SWIM-SERV-050 Service abstract includes a best practice on the content of the abstract. The content can be extracted from other fields in the service description such as
| |||
Additional information on the information service | Information service providers should provide a description of the location at which more information, potentially including more detailed technical information on an information service, may be found. | This requirement is covered by SWIM-SERV-070 Provider point of contact and SWIM-SERV-170 Additional technical information for the service consumer. | Free text or NIL | Additional information on the information service can be found at the European SWIM Registry https://eur-registry.swim.aero/services/ or from the Donlon Airport Operator. |
The location should be provided as a link to where an information service consumer can find more information. | ||||
If an information service provider does not make additional information available on the information service overview, the additional information on the information service metadata field shall specify “NIL”. | The use of NIL is not outlined in the specification. | |||
Quality of the service | Information service providers shall provide a description on the qualitative and quantitative information pertaining to the characteristics of an information service to allow information service consumers to understand the quality of the information service. | This requirement is covered by SWIM-SERV-180 Quality of service. | Capacity: free text (description of capacity) and/or Time behaviour: free text (description of time behaviour) and/or Availability: free text (description of availability) and/or Recoverability: free text (description of recoverability) and/or Confidentiality: free text (description of confidentiality) and/or Integrity: free text (description of integrity) |
|
The description should specify parameters based on ISO 25010. | The notes to SWIM-SERV-180 Quality of service include a reference to ISO 25010. | |||
The quality of the information service should be expressed using the following parameters (or other applicable parameters): ii) integrity of a service. | This requirement is covered by SWIM-SERV-180 Quality of service. The requirement text includes the top level parameters:
The notes to the requirement include the sub-parameters e.g. capacity. | |||
Note.⸻ Examples of applicable parameters related to performance, reliability and security are provided in Doc 10203. | ||||
Information service validation type | Information service providers shall ensure that the information service is validated.
| The EUROCONTROL Specification for SWIM Service Description does not mandate that services shall be validated as this is a governance/process aspect. Instead the specification requires a description of what was done. | Independent validation and/or Collaborative validation and/or User validation and/or Self-validation | SELF-VALIDATION |
This validation shall include the parameters provided in the quality of service metadata field of the information service overview to assist information service consumers with the initial evaluation of the information service. |
| |||
Information services shall be validated by at least one of the following validation methods: | The EUROCONTROL Specification for SWIM Service Description does not specify what methods to use as this is process related. The methods are given as a best practice in the notes to SWIM-SERV-200 Service validation information and are available at https://reference.swim.aero/information-services/service-categories/CodeServiceValidationType.html . | |||
The validation method(s) used and its corresponding result shall be recorded. | This requirement is covered by SWIM-SERV-200 Service validation information. | |||
Information services may evolve which triggers the need for revalidation. Each new version of an information service should be revalidated. | The evolution aspect is not covered by the EUROCONTROL Specification for SWIM Service Description. | |||
Note.⸻ For more information on the validation methods see Doc 10203. |
| |||
Information service validation description | Information service providers shall provide a description of the validation method applied to assist information service consumers in assessing the confidence level of the information service. | This requirement is covered by SWIM-SERV-200 Service validation information. | Free text (validation result) | Donlon Airport tested the service in accordance with its quality management system (QMS) based requirements. The validation was successful. To obtain the validation evidence, contact the Service desk [24/7]: +693 555 01 service-desk@donlon-airport.com |
By sharing the validation results, information service providers reassure information service consumers that the information service and its provider have the ability to deliver the declared capabilities and quality of service. | The role of the validation information in reassuring the service consumer is covered in the rationale to SWIM-SERV-200 Service validation information. | |||
The description should include a brief statement on the validation results, and it should describe how the information service consumers may obtain the validation evidence. | This requirement is covered by SWIM-SERV-200 Service validation information. | |||
Filtering available | Information service providers should provide information on the availability of filtering to allow information service consumers to narrow the content of information that they consume. | This requirement is covered by SWIM-SERV-310 Filter encoding. | Free text or NIL | The service allows filtering based on a start and end time given as HTTP Query parameters start_date and end_date. The values are formatted in ISO8601. Example: &start_date=2022-06-22&end_date=2022-06-25. Note: the information provided by the service is limited to DONLON (see Geographical extent of information) so there is no need for a geospatial filter in this case. |
The capability of filtering information should describe the filters information service providers offer for an information service. | This requirement is covered by SWIM-SERV-310 Filter encoding. | |||
If an information service provider does not offer filtering or does not make information on filtering available on the service overview, the filtering available metadata field shall specify “NIL”. | The use of NIL is not outlined in the specification. | |||
Access restrictions | Information service providers shall provide a description of any constraints on access to the information service to assist information service consumers in understanding whether they may be eligible to access the information service. | This requirement is covered by SWIM-SERV-150 Service access and use conditions and SWIM-SERV-160 Security constraints. | Free text | The access to the service is subject to the signature of a Service Level Agreement with the Donlon Airport Operator. The access to the service is subject to the signature of a Service Level Agreement with the Donlon Airport Operator. |
These constraints should specify the requirements and/or restrictions on information service consumers for accessing the information exchanged by the information service that are considered to be sensitive. | This requirement is covered by SWIM-SERV-150 Service access and use conditions and SWIM-SERV-160 Security constraints. | |||
Message exchange patterns | Information service providers shall indicate the message exchange pattern used by the information service to assist information service consumers in understanding the relationships of multiple messages exchanged with the information service providers. | This requirement is covered by SWIM-SERV-210 Application message exchange pattern. | Request/Reply and/or One way and/or Publish/Subscribe | Synchronous Request Reply |
The message exchange pattern shall be expressed as one or more of the following: | The notes to SWIM-SERV-210 Application message exchange pattern include typical message exchange patterns. The service description describes the running service. It does not impose requirement on the design of the service. Therefore, the selection of the message exchange patterns is a not part of the requirement. A list of message exchange patterns is available at https://reference.swim.aero/information-services/service-categories/CodeApplicationMessageExchangePatternType.html | |||
Information exchange models | If information service providers use for their information service payloads the domain specific information exchange models, then information service providers shall indicate the domain-specific information exchange models used for their information service payloads, including the extensions of the information exchange models and their versions. | This requirement is covered by SWIM-SERV-290 Information definition - minimum. | Free text | The service is using an information exchange model that is specific to the service and aligned with the AIRM version 1.0.0. |
Status: Living Material