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


Requirement

Title

Operational needs

Identifier

SWIM-SERV-011

Requirement

A service description shall

  • include information about the operational needs fulfilled by the service;
  • indicate whether information exchange requirements (IER) were used in the identification of the needs for the service; and if so
  • include or refer to the information exchange requirements (IER).

Rationale

Operational needs relate to the operational context in which the service is used. IERs reference the requirements that are at the origin of the service.

This requirement supports decision making in terms of service suitability within a particular operational context.

Verification

Completeness: Verify that operational needs are included; verify that the indication on whether IERs were used is included.

Consistency: If IERs were used, verify that the IERs and the source(s) are included.

Correctness: if a source is included, verify that the IERs are available in the referenced source.

Examples/Notes

Example operational need:

  • “The Flight Management service fulfils the need to retrieve information about flights and flight plans and the need to provide information about changes in flights”.

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

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

Level of Implementation

Mandatory

Guidance

Examples

See the Operational Needs section within the Donlon TOBT Setting Service Description.

Guidance for JSON service description 

tentative JSON Guidance

Schema

The guidance concerns JSON Schema v0.0.3 (see Schema releases).

 Schema excerpt [+]
		"ServiceGeneralDescription" : 
		{
			"description" : "Description of the service in terms of what it provides, the purpose and under which conditions and quality levels the service is provided.",
			"type": "object",
			"additionalProperties": false,
			"required": ["operationalNeed", "functionality", "qualityOfService", "accessAndUseCondition", "validation"],
			"properties":
			{
			...
				"operationalNeed":
				{
					"description" : "The operational need fulfilled by the service [SWIM-SERV-011]",
					"type" : "array",
					"items" : { "$ref":"#/definitions/OperationalNeed" },
					"minItems": 1
				},
			...
			}


		"OperationalNeed" : 
		{
			"description" : "A statement of the operational attributes of a system needed for the effective and/or efficient provision of air traffic services to users. [SWIM-SERV-011]",
			"type": "object",
			"additionalProperties": false,
			"required": ["name", "description"],
			"properties":
			{
				"name":
				{
					"description" : "The name of the operational requirement.",
					"type" : "string",
					"minLength":1
				},
				"description":
				{
					"description" : "Description of the operational needs fulfilled by the service. Includes or refers to information exchange requirements [SWIM-SERV-011].",
					"type" : "string",
					"minLength":1
				}
			}
		},
 Rules [+]

Rules expressed for the cases as defined in Registry URD.

caserules
COMPLIANTmandatory
CANDIDATEsame
DEFINITIONsame

Guidance

Within field operationalNeed, itself within field serviceGeneralDescription, list one or more occurrences of type OperationalNeed, such as operational context and requirements that are at the origin of the service

Operational Need - Mandatory

Rationale: Operational needs relate to the operational context in which the service is used. IERs reference the requirements that are at the origin of the service.
This information supports decision making in terms of service suitability within a particular operational context.

Guidance:

  • include information about the operational needs fulfilled by the service;
  • indicate whether information exchange requirements (IER) were used in the identification of the needs for the service; and if so
  • include or refer to the information exchange requirements (IER).
  • indicate relationship to PCP and/or SESAR Deployment Plan


attribute namedescriptiontypeguidancerule
nameThe name of the operational requirement.stringProvide a short name for the operational needMandatory
descriptionDescription of the operational needs fulfilled by the service. Includes or refers to information exchange requirementsstring

Describe the operational context of the service.

Make reference to the ConOps, OSED or other applicable reference document where additional information on the operational concept can be found.

Make explicit the needs addressed by the service.

List the requirements at the origin of the service (eg IERs).

Mandatory

Example

        "serviceGeneralDescription": {
            "operationalNeed": [
                {
                    "name": "Operational and Business context",
                    "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. 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).\n\r 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 Requirements",
                    "description": "The service is defined to satisfy two IERs, which were derived from the A-CDM Implementation Manual :\r\n[IER1] 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)\r\n[IER2] 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)."
                }
            ]
			
		}


A complete JSON example is available in page JSON example - Donlon TOBT Setting service description.


  • No labels