Working towards the next version of the SWIM Supporting Material

Page tree

Working towards the next version of the SWIM Supporting Material

Skip to end of metadata
Go to start of metadata
Page Table of Content

Version

This page concerns v2.0 of the Specification. Supporting material on v1.0 is SWIM-SERV-011 Operational needs

Requirement

Title

Operational environment

Identifier

SWIM-SERV-130

Requirement

A service description shall include or refer to information about:

  • the operational needs used in the development of the service; and/or
  • the capabilities offered by the service.

Rationale

Information about the operational environment is useful to get an understanding of the service.

Information about the operational needs addressed by the service and the capabilities the service offers supports decision making in terms of service suitability within a particular operational context.

Verification

Completeness: Verify that operational environment information is included or referenced.

Consistency:. Not applicable.

Correctness:. Not applicable.

Examples/Notes

Example operational need:

  • The context is the Airport Collaborative Decision Making (A-CDM) concept as defined in Airport CDM Implementation Manual v4. In A-CDM it is important to allow A-CDM Partners to set the value of some milestones when necessary. The classical example is to allow the Aircraft Operator or the Ground Handler to set the Target Off-Block Time (TOBT) that indicates what is the target time for the aircraft to be ready for off-block. Setting the TOBT value is possible at many stages during the A-CDM process, as early as Milestone 2 (EOBT-2hr) up to and including Milestone 11 (Boarding starts). The Business Logic may involve validations such as: not accepting values in the past; not accepting a new value too close the existing one (there is a minimum change involved); Limiting the number of changes after TSAT has been issued.

Note: When describing operational needs, it is best practice to add a reference to an operational concept document, or contextual description.

Information about the information exchange requirements can be documented as part of the operational environment.

Example IERs:

  • “It shall be possible for the end user to access up-to-date network weather forecasts (up to D-10) in the specified geographical areas (regional/sub-regional/local) or airports (e.g. snow situation), with variable granularity levels depending on the time horizon. (reference REQ-07.06.01-OSED-WX01.0010; source SESAR 1 OSED 07.06.01)”;
  • “To allow the Aircraft Operator or Ground Handler to set, update or delete the value of the Target Off-Block Time of a departing flight, in accordance with the operations involving Target Off-Block Time that take place between A-CDM Milestones 2 and 11 (derived from: Airport CDM Implementation Manual v4)”.

Example capability:

  • The service offers a flight plan retrieval capability.

Note: Capabilities are supported by functions. These are described in SWIM-SERV-140.

Level of Implementation

Mandatory

Guidance

This requirement asks for one of two things:

  • the operational needs. This is the service from the point of view of the service consumer.  It details what the service should do to satisfy the consumer's needs.
  • the capabilities. This is the service from the provider viewpoint. It details what the service can do.

This flexibility is allowed as a service can be developed in different ways - sometimes starting from a "top-down" approach but at other times as a "bottom-up" collection of operations.


Verification Support

Completeness

Check that:

[  ] The service description includes or refers to information about the operational environment.

Examples

The following example shows the content as a table.

operational environmentoperational needs

The context is the Airport Collaborative Decision Making (A-CDM) concept as defined in Airport CDM Implementation Manual v4.

In A-CDM it is important to allow A-CDM Partners to set the value of some milestones when necessary.

The classical example is to allow the Aircraft Operator or the Ground Handler to set the Target Off-Block Time (TOBT) that indicates what is the target time for the aircraft to be ready for off-block.

Not any value can be accepted. There may be many business rules for validating the value. As for example: value cannot be in the past, value can no longer be changed, too many changes, etc.

Setting the TOBT value is possible at many stages during the A-CDM process, as early as Milestone 2 (EOBT-2hr) up to and including Milestone 11 (Boarding starts).

The Business Logic may involve validations such as:

  • not accepting values in the past,
  • not accepting a new value too close the existing one (there is a minimum change involved),
  • limiting the number of changes after TSAT has been issued.

information exchange requirements

IER 1

To allow the Aircraft Operator or Ground Handler to set, update or delete the value of the Target Off-Block Time of a departing flight. This is done in accordance with the operations involving Target Off-Block Time that take place between A-CDM Milestones 2 and 11 (derived from: Airport CDM Implementation Manual v4)

IER 2

To allow the competent authority to set the value of the Target Off-Block Time for a given aircraft in specific circumstances. In other words, under adverse conditions or special circumstances this service allows the competent authorities to set the Target Off-Block Time value of the flight. (derived from: Airport CDM Implementation Manual v4)

The following example shows an extract of the content of a JSON file that conforms to the Service Metadata Schema

Example of SWIM-SERV-130 using Service Metadata Schema
"generalDescription": {
 "operationalEnvironment": {
  "operationalNeeds": [{
   "name": "Airport Collaborative Decision Making",
   "description": "The context is the Airport Collaborative Decision Making (A-CDM) concept as defined in Airport CDM Implementation Manual v4. In A-CDM it is important to allow A-CDM Partners to set the value of some milestones when necessary. The classical example is to allow the Aircraft Operator or the Ground Handler to set the Target Off-Block Time (TOBT) that indicates what is the target time for the aircraft to be ready for off-block. Not any value can be accepted. There may be many business rules for validating the value. As for example: value cannot be in the past, value can no longer be changed, too many changes, etc. Setting the TOBT value is possible at many stages during the A-CDM process, as early as Milestone 2 (EOBT-2hr) up to and including Milestone 11 (Boarding starts). The Business Logic may involve validations such as: not accepting values in the past, not accepting a new value too close the existing one (there is a minimum change involved), limiting the number of changes after TSAT has been issued."
  }, {
   "name": "Information Exchange Requirement 1",
   "description": "To allow the Aircraft Operator or Ground Handler to set, update or delete the value of the Target Off-Block Time of a departing flight. This is done in accordance with the operations involving Target Off-Block Time that take place between A-CDM Milestones 2 and 11 (derived from: Airport CDM Implementation Manual v4)"
  }, {
   "name": "Information Exchange Requirement 2",
   "description": "To allow the competent authority to set the value of the Target Off-Block Time for a given aircraft in specific circumstances. In other words, under adverse conditions or special circumstances this service allows the competent authorities to set the Target Off-Block Time value of the flight. (derived from: Airport CDM Implementation Manual v4)"
  }]
 }
}

Complete examples are available at Example service description.

  • No labels