Task Status

This page is part of the ongoing SWIM communities of interest discussions. The content is working material. It should not be treated as final as it is still subject to review, comment and change.

This task will:

update the supporting material for service overviews.
consider a service overview as a subset of a service description → ensure that the requirements for service overview are covered in the Service Description specification
consider what the Registry should implement in terms of service overviews

The relationships between service overviews, service definitions and service descriptions is discussed on the Artefacts to describe services page.

Current supporting material

The current supporting material to be updated is at: Service Overview

New supporting material

The following text will form the new supporting material once agreed.

Status

The proposed new supporting material is based on a draft PANS-IM so may be subject to change.

Introduction

The Information Service Overview is introduced in the ICAO Procedures for Air Navigation Services – Information Management (PANS-IM).

An information service provider shall provide an information service overview for each version of each information service. The overview contains metadata on the service that facilitates discoverability and enables information service consumers to compare between different information services.

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

Content of an information service overview

The content of an information service overview is outlined in Table 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) of an information service overview.
includes the requirements for the field based on the PANS-IM.
provides an example of the expected content based on Donlon.
provides a mapping to the relevant requirement in 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	Example Content - Based on Donlon	Mapping to Service Description requirements
Information service name	Information service providers shall name the information service. The name of the information service should enable information service consumers to reference or identify the information service. The name should provide an indication of the purpose of the information service.	Donlon TargetOffBlockTimeSetting Service	SWIM-SERV-006: name identification is in rationale. It is not possible to turn this into a verifiable requirement. notes give a best practice on the 'indication of purpose' in the name. The service description describes the service. It does not impose requirement on the design. Therefore, the "indication of the purpose" is a best practice rather than a rule.
Information service version	Information service providers shall provide versioning to the information services. The service version shall be provided in numerical format (n.n.[n]). The version of the information service shall allow information service consumers to distinguish between versions of an information service.	1.0.0	SWIM-SERV-006: version notes give a best practice on using a numerical format The service description describes the service. It does not impose requirement on the design. Therefore, the "numerical format" is a best practice rather than a rule. the distinguishing aspect of the version is covered in the rationale. It is not possible to turn this into a verifiable requirement.
Information service lifecycle status	Information service providers shall specify the stage that the information service version is currently in as one of the three phases: Prospective, Operational or Retired.	Operational	New requirement covers this the three phases are in the notes.
Information service lifecycle date	Information service providers should include the dates for current and future lifecycle stages. 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 lifecycle date metadata field shall specify "NIL". Note - In the case of prospective stage, the date indicates the date by which information service provider plans to make the information service operational.	2018-07-31	New requirement covers this. The use of NIL is not outlined in the specification.
Information service functions	Information service providers should provide a description of the business-level characteristics of the information service functions to assist information service consumers with a business view of the interactions with the information service, without having to look at the interface details. The description should include the functionality of the service as a list of the functions and real-world effects. If an information service provider does not make the information service functions available, the Information Service Functions metadata field shall specify "NIL".	Allow the service consumer to set (i.e. define or update) the target off-block time (TOBT) value for a specific flight. real-world effect: TOBT value is defined or updated Allow the service consumer to delete the target off-block time (TOBT) value for a specific flight. real-world effect: The TOBT value is marked as undefined	SWIM-SERV-012 function real-world effect 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: a) Flight information; and/or b) Aeronautical information; and/or c) Meteorological information; and/or d) Environment information; and/or e) Capacity, demand & flow information; and/or f) Surveillance information; and/or g) Other information	Flight information	SWIM-SERV-009
Brief description of the information service	Information service providers shall provide a brief summary description of the information service to assist the information service consumers on whether the described service is suitable for use in a particular situation. The brief summary 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 TargetOffBlockTimeSetting service supports flight information exchange by allowing aircraft operators and ground handlers to set the Target Off-Block Time (TOBT) for their flight departures at Donlon Airport. The service may be used by the Donlon Tower Controllers in specific circumstances, such as under adverse conditions or other special circumstances. The service is part of a set of services supporting the Airport Collaborative Decision Making (A-CDM) concept and its implementation by providing the A-CDM partners with common situation awareness about flights at a CDM airport.	SWIM-SERV-007 abstract note covers the items that are best practice to include. The content can be mapped to other parts such as operational needs and service categories.
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. 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 the additional information available on the information service overview, the Additional information on the Information Service metadata field shall specify "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.	New requirement covers this 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 understand the quality of the information service. The description should specify parameters based on ISO 25010. The quality of the information service should be expressed using the following parameter (or other applicable parameter): Performance parameters (quantitative) - Capacity of a service - Time behaviour of a service Reliability parameters (quantitative) - Availability of a service - Recoverability of a service Security parameters (qualitative) - Confidentiality of a service - Integrity of a service Note - Examples of applicable parameters related to performance, reliability and security is provided in the Manual om Implementation of System-wide Information Management (Doc...)	Availability: 99.95 % outside the planned outages Capacity: 2000 service requests per hour Time behaviour: 2s delay for 95% of messages	SWIM-SERV-014 the requirement covers the top level parameter the notes cover the sub-parameters e.g. capacity... ISO 25010 is mentioned in the notes.
Information service validation type	Information service providers shall ensure that the information service is validated. The 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: a) independent validation; b) collaborative validation; c) user validation; or d) self-validation. The validation method(s) used and its corresponding result shall be recorded. Information services may evolve which triggers the need for revalidation. Each new version of an information service should be re-validated.	self-validation	SWIM-SERV-027 Obviously the spec does not mandate that services shall be validated as this is a governance/process aspect. Instead the specification requests a description of what was done. quality of service is covered by the requirement The spec does not specify what methods to use as this is process related. The methods are given as a best practice in the notes. the evolution aspect is not covered by the specification.
Information service validation description	Information service providers shall provide a description of the validation method applied to assist information service consumers assess the confidence level of the information service. 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 description should include a brief statement on the validation results, and how the information service consumers may obtain the validation evidence.	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	SWIM-SERV-027 validation method validation results obtaining evidence The reassurance is covered in the rationale
Filtering available	Information service providers should provide information on the availability of filtering capability to allow information service consumers to narrow the content of the information that they consume. The capability of filtering information should describe the filters information service providers offer for an information service. 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 service consumer can filter information feed based on time. 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.	SWIM-SERV-024 filter encoding The use of NIL is not outlined in the specification.
Access restrictions	Information service providers shall provide a description of any constraints on the access to the information service to assist information service consumers in understanding whether they may be eligible to access the information service. These constraints should specify the requirements and/or restrictions on information service consumers for accessing the information exchanged by the information services that are considered to be sensitive.	The access to the service is subject to authorization. Authorization is dependent on formal arrangements (Service Level Agreement) with the Donlon Airport Operator. The access to the service is subject to authentication based on the user id and password for authorized users.	SWIM-SERV-013 and New requirement - security
Message exchange patterns	Information service providers shall indicate the message exchange pattern used by the information service to assist information service consumers understand relationships of multiple messages exchanged with the information service providers. The message exchange pattern shall be expressed as one or more of the following: a. request/reply or b. one way or c. publish/subscribe	request/reply	SWIM-SERV-017 The types are covered in the notes to the requirement. This is a design requirement and not covered in the service description spec,
Information exchange models	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. If information service providers do not use the domain-specific information exchange models for their information service payloads, then information service providers shall describe the alignment to the AIRM and indicate the exchange schema used.	The service is using an information exchange model that is specific to the service and aligned with the AIRM version 1.0.0.	SWIM-SERV-022
Geographical extent of information	Information service providers shall provide a description of the geographical coverage of the information exchanged to allow information service consumers understand the geographical coverage of the information being provided. Note: The geographical coverage may be expressed in terms such as of ICAO region, FIR, Aerodrome or polygon. More granular information such as coverage at Airport X, FIR Y may be provided as it may facilitate search responses.	Donlon airport (EADD).	New requirement covers this.
Source of information	Information service providers should specify the sources of information exchanged. Information service providers should also provide information on any subsequent modifications applied in order to provide information service consumers with background on information sources and modifications. If an information service provider does not make the source of information available, the Source of Information metadata field shall specify "NIL".	The service consumer.	New requirement covers this The use of NIL is not outlined in the specification.
Provider organization	Information service providers shall provide the name of their organization to assist information service consumers in identifying and gaining context on the information service. The name of the organization shall be followed by any abbreviated name, if any, by which the organisation is known. Note – The provider organization may or may not be the organization originating the information.	Donlon Airport Operator	SWIM-SERV-008
Support Availability	Information service providers should provide a description of the support offered to information service consumers on all relevant aspects related to the information service to allow information service consumers understand the level of support to expect. If an information service provider does not make support availability information available, the Support Availability metadata field shall specify "NO SUPPORT AVAILABLE".	For incidents on services in operation, contact the Service desk [24/7]: +693 555 01 service-desk@donlon-airport.com	New Requirement covers this
Provider Point of Contact	Information service consumers should have a point of contact to request, if needed, additional information regarding an information service. Information service providers shall provide a point of contact as an email or website where a potential information service consumer can direct additional questions regarding the information service.	To request access to the service: http://www.donlon-airport.com/swim/service-request	New Requirement bundled in with additional information note covers the request to access

Creating an information service overview

An information service overview can be created:

using a template based on the table above
using the service metadata schema
- as the service overview should not rely on a schema, the service metadata schema is only informative.
from the content an existing service description.

Registering a service overview

Two considerations to discuss with Registry CCB:

add a service overview (with "prospective" or "operational" status) to the registry e.g.
- upload a service overview using the service metadata schema. This is the same schema as used for service descriptions but with different validation rules applied.
- use the HMI to create a service overview
- upload other formats e.g. based on a template (Word, Excel)
generate a service overview (with "operational" status) as a view (HTML/JSON) of a registered service description.
- In effect, this treats the service overview as a subset of the service description. A service description therefore will contain more than a service overview.

Service Overviews