SWIM Retrospectives and Service Harmonization Efforts Recap
SWIM Retrospectives
capturing the experience in using the SWIM related artefacts
Retrospective template
What was done
•
-
What was done well
•
-
What was not done
•
-
What can be done better
•
-
candidate opportunities
understanding what we have
Retrospective 5 - DWD
What was done
•
Imported services into the Registry.
•
Edited services in the Registry
What was done well
•
The Registry team solved problems very quickly.
What was not done
•
-
What can be done better
•
The
responsiveness
of the Registry can be improved. Sometime there is a delay
when you click the ‘edit’ button.
•
There is a large
degree of freedom
when describing services. Harmonisation of
entries through codelists may be good.
Retrospective 6 – DWD
Harmonization of Service Description elements in terms of Service Definition
What was done
•
Create (private) GitHub repo and upload
example descriptions
to work on
•
Review service descriptions for turbulence/icing service as well as for OPMET
(METAR, SIGMET)
•
Upload examples and draft descriptions
What was done well
•
Find
commonalities
for describing geographical extent (e.g. using GeoJSON
format) for service discovery. The SSCONE work was used.
•
Evaluation of data source files (
Grib2
) for turbulence/icing regarding data values
(e.g. severity index)
What was not done
•
Evaluate
all service description elements
, focus was on general description
aspects
•
Discussion/evaluation regarding serviceInterface, serviceInformationDescription
and
scope of functionality
(which refers to granularity)
What can be done better
•
Compare further service descriptions from the MET community,
identify similar
services
(HTTP, AMPQ) and evaluate commonalities/differences
•
Define the service
granularity
(e.g. OPMET service or METAR/SIGMET/TAF
service)
•
Establish and define a
structure for topic based
(AMQP) services -> resource
address
•
Evaluate the service description in terms of which information is "
really needed
"
and
applicable
by the user
Within the SESAR implementation projects (mainly IP68, IP69) there were efforts to contribute to service harmonisation for MET SWIM services
and share the lessons learnt with the SWIM community. A few initial services were chosen to showcase the description, registration and discovery
process. The activities aimed at finding subsets or commonalities of describing elements which can be used for harmonisation.
Retrospective 2 - Skyguide
What was done
•
Proof of Concept testing the
SWIM YP
•
use the
R/R
and
P/S
,
AMQP
and
https
, to establish the channel
•
security principles and architecture were respected using each partner’s
PKI
and
certificates
•
pushing for SWIM for all our connections with our partners, and this was a first
step
What was done well
•
-
What was not done
•
no attention put on the
business message payload
yet
•
no
(local) registry
yet
•
best way to have a proper end-to-end
monitoring
of the channels
•
inject this experience into a
Reference Architecture
which can guide further
projects
•
some guidance about the way to group messages in
topics
or AMQP queues
according business domains / subdomains may help
What can be done better
•
many data of this information type does not have an XM model to support a
standard exchange, and we will likely go to
proprietary XML
. Need guidance
here.
•
discuss the definition of new of evolution of
existing XM standards
about all
that is not covered by the existing XM
•
Where to discuss topics not clear sometimes -
SSCONE, SITCOM or SWIM-TEC
Retrospective 3 – Skyguide - registry specific
What was done
•
-
What was done well
•
-
What was not done
•
federated
and
interconnected
registries should be put in place
•
need some
vision
paper in the area
What can be done better
•
criterion to determine if a service is to be published in a
European, national or
local registry
•
service discovery should be a feature, but it is really unclear to have concrete
use cases
in our operational ATM /AIM / ATFCM where we can demonstrate the
need for service discovery
•
What will be the
technology
to enable such a vision? Probably not all registry
products are
interoperable
.
Retrospective 4 – EUROCAE WG104 – Service
Standard
What was done
•
Description of:
•
the approach and methodology aspects applied for the development of this Performance
Standard.
•
the minimum Service requirements (including
non-functional requirements
) needed for the
service to support the operating concept in the applicable context.
•
the
Data Catalogue
resulting from the logical service model payload.
•
the test procedures to verify the service performance.
•
implementation guidelines and examples for implementing an Arrival Sequence Service.
•
Explanation of how the data catalogue used in the Arrival Sequence Service standard
satisfies the requirements of the
EUROCONTROL Info. Specification
•
Service definition
in
JSON
for the
SWIM Registry
What was done well
•
Extensive work done in the data catalogue , including the
AIRM tracing
What was not done
•
-
What can be done better
•
-
Retrospective 1 - Overall
What was done
•
ICAO adoption - PANS, Manual
•
Defined role in architecture
•
Suite of foundation/reference material
•
Recognised reference website and registry
•
Established SWIM specifications and communities of interest
•
Conformant services beginning to come
•
Defined role in ATM value chain
•
Experience in applying SWIM
What was done well
What was not done
What can be done better
•
Know what has been done
•
Know what to do and who has to do it
•
Reduce friction in using SWIM community and artefacts
Capturing the experiences in using SWIM-related artefacts through retrospectives, this content delves into the evaluation of service descriptions, harmonization efforts within SESAR implementation projects, and reflections on what was done well and what can be improved in terms of service definitions and functionalities.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
SWIM Retrospectives capturing the experience in using the SWIM related artefacts
Retrospective template understanding what we have candidate opportunities What was done What was not done - - What was done well What can be done better - -
Retrospective 5 - DWD What was done What was not done Imported services into the Registry. Edited services in the Registry - What was done well The Registry team solved problems very quickly. What can be done better The responsiveness of the Registry can be improved. Sometime there is a delay when you click the edit button. There is a large degree of freedom when describing services. Harmonisation of entries through codelists may be good.
Retrospective 6 DWD Harmonization of Service Description elements in terms of Service Definition Within the SESAR implementation projects (mainly IP68, IP69) there were efforts to contribute to service harmonisation for MET SWIM services and share the lessons learnt with the SWIM community. A few initial services were chosen to showcase the description, registration and discovery process. The activities aimed at finding subsets or commonalities of describing elements which can be used for harmonisation. What was done What was not done Evaluate all service description elements, focus was on general description aspects Discussion/evaluation regarding serviceInterface, serviceInformationDescription and scope of functionality (which refers to granularity) Create (private) GitHub repo and upload example descriptions to work on Review service descriptions for turbulence/icing service as well as for OPMET (METAR, SIGMET) Upload examples and draft descriptions What was done well Find commonalities for describing geographical extent (e.g. using GeoJSON format) for service discovery. The SSCONE work was used. Evaluation of data source files (Grib2) for turbulence/icing regarding data values (e.g. severity index) What can be done better Compare further service descriptions from the MET community, identify similar services (HTTP, AMPQ) and evaluate commonalities/differences Define the service granularity (e.g. OPMET service or METAR/SIGMET/TAF service) Establish and define a structure for topic based (AMQP) services -> resource address Evaluate the service description in terms of which information is "really needed" and applicable by the user
Retrospective 2 - Skyguide What was done What was not done no attention put on the business message payload yet no (local) registry yet best way to have a proper end-to-end monitoring of the channels inject this experience into a Reference Architecture which can guide further projects some guidance about the way to group messages in topics or AMQP queues according business domains / subdomains may help Proof of Concept testing the SWIM YP use the R/R and P/S, AMQP and https, to establish the channel security principles and architecture were respected using each partner s PKI and certificates pushing for SWIM for all our connections with our partners, and this was a first step What was done well What can be done better many data of this information type does not have an XM model to support a standard exchange, and we will likely go to proprietary XML. Need guidance here. discuss the definition of new of evolution of existing XM standards about all that is not covered by the existing XM Where to discuss topics not clear sometimes - SSCONE, SITCOM or SWIM-TEC -
Retrospective 3 Skyguide - registry specific What was done What was not done federated and interconnected registries should be put in place need some vision paper in the area - What was done well What can be done better criterion to determine if a service is to be published in a European, national or local registry service discovery should be a feature, but it is really unclear to have concrete use cases in our operational ATM /AIM / ATFCM where we can demonstrate the need for service discovery What will be the technology to enable such a vision? Probably not all registry products are interoperable. -
Retrospective 4 EUROCAE WG104 Service Standard What was done Description of: the approach and methodology aspects applied for the development of this Performance Standard. the minimum Service requirements (including non-functional requirements) needed for the service to support the operating concept in the applicable context. the Data Catalogue resulting from the logical service model payload. the test procedures to verify the service performance. implementation guidelines and examples for implementing an Arrival Sequence Service. Explanation of how the data catalogue used in the Arrival Sequence Service standard satisfies the requirements of the EUROCONTROL Info. Specification Service definition in JSON for the SWIM Registry What was not done - What was done well Extensive work done in the data catalogue , including the AIRM tracing What can be done better -
Retrospective 1 - Overall What was done What was not done ICAO adoption - PANS, Manual Defined role in architecture Suite of foundation/reference material Recognised reference website and registry Established SWIM specifications and communities of interest Conformant services beginning to come Defined role in ATM value chain Experience in applying SWIM What was done well What can be done better Know what has been done Know what to do and who has to do it Reduce friction in using SWIM community and artefacts
