SWIM Master Class 2015

Solution Description

Document information

Company : m-click.aero

Team Leader : Aleksandar Balaban

Team : Matthias Pohl, Volker Diels-Grabsch, Markus Schneider

Project name : Aviation Data Validation Platform

Summary

This contribution to the SWIM Master Class 2015 will demonstrate a aviation data validation platform used to implement technical service for syntactical and semantic validation of aeronautical data - SWIM Technical Infrastructure’s Data Validation Functional Block (SWIM-TI DV FB).

The implementation performs both syntactic and semantic data validation and can be used for advanced data evaluations based on predefined validation/business rules. The validation rules are expressed in structured English following a profile of the Semantics of Business Vocabulary and Business Rules (SBVR). Our solution consists of a validation web client, an administration tool and a validation service exposed via SWIM Yellow Profile (YP) compatible service endpoint. It is suitable for standalone deployment as well as in an aviation cloud infrastructure and can easily be integrated into those SWIM-TI supported information workflows, that require either verification/validation of aeronautical data or decision making based on business rules evaluation.

1

Table of Contents1 ACRONYMS AND TERMINOLOGY.........................................................................................................4

2 PROJECT OBJECTIVE AND SCOPE........................................................................................................5

2.1 PROBLEM STATEMENT................................................................................................................................52.1.1 Syntactic and semantic data validation...............................................................................................52.1.2 Semantic validation based on business rules......................................................................................6

2.2 PROPOSED SOLUTION..................................................................................................................................72.2.1 Demonstration Scenarios....................................................................................................................9

3 TECHNICAL SOLUTION...........................................................................................................................11

3.1 ARCHITECTURE.........................................................................................................................................113.1.1 Functional View................................................................................................................................123.1.2 Component View................................................................................................................................123.1.3 Process View.....................................................................................................................................133.1.4 Deployment View...............................................................................................................................14

3.2 TECHNOLOGY (E.G. API, PROTOCOL, DATA MODELS, STANDARDS, RUNTIME COMPONENTS)..................143.3 SERVICES INVOLVED (EXISTING / NEW, PROVIDER / CONSUMER).............................................................153.4 MATURITY OF THE PROTOTYPE.................................................................................................................153.5 TECHNICAL CONSTRAINTS........................................................................................................................15

4 BENEFITS.....................................................................................................................................................16

4.1 BUSINESS BENEFITS..................................................................................................................................164.2 TECHNICAL / TECHNOLOGY BENEFITS......................................................................................................16

SWIM COMPLIANCE SELF-ASSESSMENT.................................................................................................18

4.3 DATA STRUCTURE.....................................................................................................................................184.3.1 AIRM compliance..............................................................................................................................184.3.2 Physical data model maturity............................................................................................................18

4.4 SERVICE....................................................................................................................................................184.4.1 Service endpoint documentation.......................................................................................................18

4.5 INFRASTRUCTURE.....................................................................................................................................194.5.1 Use of recognized mainstream protocols/standards.........................................................................194.5.2 Adopted security mechanism.............................................................................................................19

4.6 GOVERNANCE...........................................................................................................................................194.6.1 SLA in the context of the SWIM Master Class...................................................................................19

APPENDIX A USED WORKS...................................................................................................................20

APPENDIX B VALIDATION WEB CLIENT............................................................................................1

B.1 INPUT DOCUMENT UND VALIDATION REPORT............................................................................................1

APPENDIX C GENERIC INTERFACE BINDING..................................................................................2

C.1 Plain Old XML (POX) over HTTPS POST over TCP..............................................................................2

2

List of tablesNo table found.

List of figuresFigure 1 - Data Validation Service.........................................................................................................5Figure 2 - Procedural and declarative validation....................................................................................6Figure 3 - SWIM-TI functional breakdown.............................................................................................7Figure 4 - Implementation process and execution elements..................................................................8Figure 5 - Basic process flow................................................................................................................. 8Figure 6 - m-click.aero common purpose aviation middleware............................................................11Figure 7 - Components and layers.......................................................................................................13Figure 8 – UML sequence diagram......................................................................................................14Figure 9 - UML deployment diagram...................................................................................................14Figure 10 - Validation Service user interface.........................................................................................1Figure 11 - Validation Service, XML validation report for B2B use ca....Error! Bookmark not defined.

3

1 Acronyms and TerminologyTerm Definition

AIXM Aeronautical Information Exchange Model

AIRM ATM Information Reference Model

Business RuleA rule that defines or constrains some aspect of business and are intended to assert business structure or to control or influence the behaviour of the business

Business Rule Engine Software component responsible for declarative business rule execution

Cloud A computational infrastructure available via internet and used on demand

DV-FB Data Validation Functional Block as described in the SWIM-TI

Schematron A rule-based validation language for making assertions about the presence or absence of patterns in XML trees

SESAR Single European Sky Research Initiative

Semantic Means beyond formal syntactical with emphasizes on understanding what the information is expressing

SWIM-TI System Wide Information Management Technical Architecture

SWIM-TI YP SWIM Technical Infrastructure Yellow Profile

Validation Engine Software component responsible for declarative validation rule execution

Validation Rule a criterion or constraint used in the process

XSLT Extensible Stylesheet Language Transformations

4

2 Project objective and scope

2.1 Problem statementStandard ATM formats for aeronautical, weather, and flight (AIXM, WXXM, & FIXM) are becoming more widely accepted in both USA and EU ATM communities. As more and more data is being on-ramped via SWIM in the form of data publishers and web services, governance of this information becomes critical for managing the information content and quality. In an operational context, the data must be validated as a precondition for safety, security, and efficiency of operations . This fact has also been considered in the design of SWIM-TI and assigned to the Data Validation Function Block (DV FB).

Data validation is essential, especially when data sets exchanged across autonomous organizational domains such as Flight Information Region (FIR) boundaries. Beside basic data validation based syntactical checks, a method has been developed within Eurocontrol for the checking of data using a semantic vocabulary called Semantics Business Vocabulary and Rules (SBVR), which is an OMG standard. Using SBVR, a set of business rules can be defined to enable the advanced validation of data content and ensure data quality within the ATM data models. Furthermore, the translation of SBVR to an ISO-standard, Schematron, enables the validation through existing XSLT processes.

2.1.1 Syntactic and semantic data validationCommon way to keep aviation data sets valid and consistent is based on syntactical description of document structure. Therefore, syntactic validation is based on the structural data check as defined by an XML schema. This check, although essential for aeronautical data quality, neither includes domain and application specific validation rules (defined by the regional operation of the system using the data), nor it is capable to express special application dependent (business) constrains.

Semantic data validation means introduction of additional rules (assertions) specified by domain experts using appropriate taxonomy. It is a human understandable domain specific language utilized in order to eliminate or reduce the lack of expressiveness in the data structure description (e.g. cardinalities or data value ranges). Semantic validation is performed by a software component called validation engine. As we can see in the following image two kinds of validation are needed in order to ensure sufficient quality of aviation data. They need to be preformed in two autonomous steps and the whole validation process has to be available as an infrastructure service.

Figure 1 - Data Validation Service

5

2.1.2 Semantic validation based on business rulesFor semantic data validation (business rules enforcement) there are two distinctive approaches, a procedural and a declarative one.

In the procedural approach the encoding of validation rules using an adequate programming language is a step-by-step, iterative validation procedure for each assertion for every validation rule.

The declarative approach assumes design of higher-level, “declarative” statements (i.e. business rules), which represent the data validity requirements or describe the conditions for a fulfilment of certain business rules.

In the implementation of procedural validation, a developers program validation classes with a function per validation rule assertion, specify rules containing assertions as higher-level functions, and finally, compile and pack them into software libraries. As an output, a number of software modules and libraries would be created carrying different sets of rules. These libraries are then deployed into a validation/rule enforcement application server container.

Although there are some benefits in using this method, such as better overall performances and more specificity in cases of very complex rules, the lack of flexibility and low level programmatic approach make this variant rather inappropriate for dynamically changing business driven data validation and business rule enforcement. Another major difficulty with this approach is that maintenance complexity requires well-written and well-maintained, up to date software documentation.

In the declarative approach, validation statements (assertions) are expressed using standardized, high-level description taxonomy (preferably constrained native human language such as SBVR) and stored and managed in a component called a business rule repository. The validation is performed by a dedicated component, responsible for obtaining, parsing and applying these rules. The term “declarative” means that domain experts can directly describe what the valid aeronautical data are, instead of indirectly specifying validation procedures.

Declarative Approach

Describing, what?

Procedural Approach

Doing, how?

Figure 2 - Procedural and declarative validation

The use of Schematron is a concrete example how an XML document might be checked against predefined structural validity rules initially expressed in SBVR. Those rules described conditions beyond those stated in a standard XML Schema, such as allowed value ranges of properties, constraints regarding associations between entities and so on.

6

The data validation service presented here utilizes declarative approach. It is well suited for business rule enforcement because it provides better support for domain experts to specify high-level rules using a predefined taxonomy using SBVR. The most beneficial in this approach is that all rules are stored in a human readable format and therefore better suited for processing, categorizing, managing and monitoring. The rules are evaluated against input documents by a dedicated software component called a business rules or validation engine.

2.2 Proposed solutionIn both USA and the Europe SWIM initiatives and corresponding specifications the concept of validation service has (at least partially) been specified. In FAA SWIM for example, there is an infrastructure service classified as “common service” containing validation properties, while in SESAR SWIM the data validation has been identified as one of technical infrastructure’s building elements called functional blocks (FB).

P14.1.3-D35-SWIM Architectural Definition for Iteration 3.0 specifies the functional decomposition of the entire SWIM-TI. One of functional blocks defined there is dedicated to data validation (DV FB).

Figure 3 - SWIM-TI functional breakdown

This data validation solution proposal aims to provide an implementation for the DV FB, which is based on the general specification from the P14.1.3-D35, as well as on results of previous work done during the OGC Testbed 11 and on the Eurocontrol’s effort to define data validation rules for common and special use cases involving aeronautical data types like AIXM 5.1, D-NOTAM, FAA D-NOTAM, as well as other AIXM schema derivations.

During the aviation thread developments of the OGC Interoperability Testbed 11, several tasks were specified in order to develop a solution for declarative aeronautical data validation based on standardized, high-level validation rules1:

The first task involved development of an aviation profile for defining business rules using OMG SBVR2.

The second one’s aim was to translate SBVR to ISO Schematron for XSLT3 for validation execution purposes.

Finally, there was another one dedicated to exposing of validation functionality via standard service endpoint.

1 OGC Testbed 11 Aviation – Digital NOTAM Validation and Enrichment2 http://www.omg.org/spec/SBVR/3 ISO/IEC 19757-3:2006

7

Despite the lack of precise specifications for SWIM DV FB in the SESAR P14.1.3-D35-SWIM Architectural Definition for Iteration 3.04, it is proposed that the data validation service for the OGC Testbed 11 shall be operated as part of SWIM infrastructure deployed and maintained based on software as service concept. That means, the service provides a standard, Yellow Profile, web based access endpoint for syntactic (XML Schema) and semantic (SBVR rules) data validation. The initial set of validation rules is based on XML schemas of aviation data types as well as on the AIXM 5.1 Business Rules 0.55

Following figure depicts the solution explained here. It covers all aspects of core implementation proposal, from derivation and conversion of declarative validation rules given in SBVR considering the syntactical description of aeronautical data (AIXM 5.1 Schema) to the final solution based on Schematron for XSLT as declarative validation engine:

Figure 4 - Implementation process and execution elements

During the preparation phase, the (AIXM 5.1 related) Rules were partially automatic converted to Schematron. A standard Schematron engine (based on XSLT) was utilized to evaluate subset of Schematron rules (also called profile) against input data documents. Service endpoint, validation engine and rule repository are run-time relevant components.

The initial service implementation, with exception of quite complicated validation engine internal architecture, has following execution flow. It first tests incoming document against all known/supported aeronautical data formats and if the input represents a valid XML document in accordance with a schema, it will be forwarded to the next processing stage where the semantic validation will be performed.

4 http://eur-registry.swim.aero/sites/default/files/P14.1.3-D35-SWIM%20Architectural%20Definition%20for%20Iteration%203.0.doc 5 https://ext.eurocontrol.int/aixmwiki_public/bin/download/Main/AIXM_Business_Rules/AIXM-5.1-BusinessRules-v.0.5.xlsx

8

Figure 5 - Basic process flow

The validation service capabilities are related to tests of syntactic and semantic correctness of aeronautical data. Accordingly, depending on input parameters, only first or both, the first and the second step will be executed. Combining execution steps this service’s typical usage is to provide an answer/assistance to following:

Is a document well-formed (XML)?

Does a document correspond to one of standardized (AIRM) aeronautical data model?

What aeronautical data model a document conforms to?

Does a document satisfy business conditions stated in a rule set?

Policy definition and enforcement (rule based access and service execution control)

Considering the concepts of service orientation (SOA) and cloud computing, proposed solution has following functional and non-functional characteristics:

Centralized deployment in a SWIM cloud environment and available for all (authorized) aviation stakeholders capable to consume services based on the SWIM Yellow profile

Declarative approach based on validation engine and high level validation/business rules taxonomy

Web front end as well as B2B service endpoint

Administration front end application

Predefined common validation rules (AIXM 5.1 Business Rules ver. 0.56.)

XML schema validation (syntactical validation)

Additional validation and business rules per domain or per service user

The option to use service with use case specific validation rule sets

The option to use service as part of policy enforcement procedure to control service access based on validation results

6https://ext.eurocontrol.int/aixmwiki_public/bin/download/Main/AIXM_Business_Rules/AIXM-5.1-BusinessRules- v.0.5.xlsx

9

2.2.1 Demonstration Scenarios Data Validation presentation will demonstrate the following functionalities:

1. The use of web interface (application) to validate input data, evaluate validation reports and manage users and business rules.

2. The se of SWIM interface to request the service to confirm to compliance with AIRM data types and syntactically validate input data sets (XML Schema compliance).

3. Use of SWIM interface to request the data validation based on common purpose (semantic) validation rules as provided by Eurocontrol's AIXM Business Rules set in the version 0.5.

4. Use of SWIM interface to execute a set of custom business rules on an input document demonstrating business rules based "decision making" support. Two business cases will be demonstrated:

a. The first will be based on a flight plan preparation and validation task regarding allowed flight levels for chosen routes and segments.

b. Second business case will demonstrate Digital NOTAM validation including the use of the AIXM GML meta data section to store validation results in "Tool Chaining Mode".

10

3 Technical SolutionTechnical solution represented here presents all functions, components, logical and physical building blocks and deployment for validation service and business rule enforcement. As functional block of the SWIM-TI this architecture shall be seen in the context of overall SWIM as a single SWIM node equipped with functions characteristic for data validation. In order to be capable to interact (receive service invocations, process them and provide computation results), this solution also used other functional blocks of the SWIM-TI such as messaging and security.

3.1 ArchitectureThe validation platform architecture is based on the m-click.aero Aviation Cloud Platform. This is typical SOA multilayer, aviation common purpose architecture:

Figure 6 - m-click.aero common purpose aviation middleware

For data validation functional block implementation, the common purpose platform has been enriched with different validation and business rule enforcement specific components as well as with dedicated validation web client.

Validation service posses following layers populated by components:

Application Layer

Service Layer

Integration Layer

Persistence Layer

While every processing step is choreographed using strict service centric approach, the functionalities for data validation are mostly integrated into business logic where the validation engine is located. The rule repository is located in the Data Persistence Layer and corresponding service endpoints reside in the Service Layer. Architectural views below depict most important architectural aspects

11

focusing on the internal components, their orchestration as well as deployment and operational configuration.

3.1.1 Functional ViewFollowing list represents system’s functional decomposition:

Data Validation

o Well-formed document (syntactic validation)

o Semantic validation

Policy Enforcement

Business Rule Evaluation

Management

o Business rule modelling

o Transformation to executable code

o XML Schema administration

o User management

3.1.2 Component ViewThe components are depicted in relation to the layers they belong to. The layers represent dependency hierarchy between architecture’s building elements. Underlying (data repository) components provide their services to the upper-layered elements in the business logic and service layers. Service endpoints for B2B interaction style via SWIM and validation client and administration tool reside in a top layer.

12

Figure 7 - Components and layers

Service and application layers are mostly responsible for interaction with validation users, a web based validation client or in a B2B SWIM scenario, a SWIM Yellow Profile compatible service endpoint. An administration client in form of a web application is used for business rule modelling, user management and access control.

Business Logic Layer contains components responsible for core functionalities are located in the. XML Syntactic checker performs evaluation of input data against known aeronautical XML schema documents and the Validation Engine performs evaluations based in semantic rules. The SBVR to Schematron converter is an auxiliary component essential for rule modelling and their conversion to executable format.

Persistence layer contains a number of data repositories containing the rule documents, XML schema definitions, copy of reference aeronautical data relevant for data validation and so on. The integration layer is responsible to periodical feeding of persistence layer with aeronautical data from different sources (network management, referential static database, D-NOTAM). Two tick blue arrows in the diagram depict dependencies between validation and other SWIM services. While the process of validation sometimes depends on the availability of external SWIM enabled aeronautical and network management data, the validation service exposes its endpoints to other SWIM participants via its service layer.

3.1.3 Process ViewThe major process flow is depicted on the following figure. The service access point receives input data in form of a XML document, forward it to the syntactic checker and finally forward to rule validation engine. Results of both processing stages are collected and returned back to the requester in form of a well-formatted XML document. Both syntactic and semantic validation can be executed separately depending on input parameters used for a service call.

13

Figure 8 – UML sequence diagram

3.1.4 Deployment ViewFollowing deployment diagram represents the deployment artifacts that describe the validator’s internal structure:

Application deployment is based on a single server solution with several building elements:

Application Server with OGC compatible GIS components (WFS, WMS, WPS)

XML Schema validator

Rule/validation engine

Web container for web front-end applications

Relational Database for AIXM and D-NOTAM data

File system for validation artefacts, rules and XML schemas

Connectors for Network Manager and EAD data sources for special validation cases (not part of SWIM Master Class presentation)

3.2 Technology (e.g. API, protocol, data models, standards, runtime components)

The solution stack of the m-click.aero Aviation Suite product, which has been utilized in a number of research and commercial projects, is based on the degree framework. Degree is a GML compatible, open source geographic information system developed to persist, manage, transform and expose all kinds of geographical data. Our Aviation Suite uses unique features of the framework (such as document based data repository) introducing additional, unique extensions for aviation data formats.

Especially for the domain of AIXM 5.1 data management and processing, we additionally implemented an extended WFS 2.0 compatible query language (WFS-TE), which supports specific temporal characteristics of AIXM 5.1 beyond those provided in the basic WFS. Doing so, m-click.aero uniquely offers the full document based aviation information processing chain without internal data transformations. The aeronautical data is stored and managed exactly the same way that they were originally encoded, as native XML documents. There is no loss of information as it would be the case, when AIXM 5.1 documents are converted into an intermediary middleware format (such as plain

14

Java objects) and than again recomposed into entity relationship form suitable for final persisting in a relational database. The overall performances and scalability is much better compared to standard relational database solutions.

3.3 Services involved (existing / new, provider / consumer)The provider of validation services could be an independent body (a company or an agency) involved in the SWIM technical Infrastructure. The validation service might also be deployed at any of the ATM stake holders involved in the SWIM-TI supported data exchange, if that organization has been mandated to ensure quality of aeronautical data or has interests to perform own, confident validation checks. Therefore both options as centralized service or a service exclusively owned and operated by an organizational domain are possible.

Consumers of validation service might also be any ATM stakeholder, aeronautical service providers or airlines. Beside basic data validation consumers could also have interests to use the semantic validation (business rule engine) in order to evaluate current state of data and derive business decisions (policy enforcement).

Validation service exposes an unique service endpoint, which (depending on input parameters) performs several distinctive but similar operations such as syntactic validation, semantic (business case dependent) validation, business decision support (evaluation business rules in a rule engine) and access control (policy enforcement using rule engine).

Current services form the domain of aeronautical data provision (static & dynamic) as well as network management data are supposed to be used in the validation process but for the purpose of SWIM Master Class those dependencies will not be put in place.

3.4 Maturity of the prototypeFrom the technology perspective our prototype is based on a mature, state of the art solution stack. It is implemented based on Debian GNU/Linux operating system and Java EE compatible middleware. Additionally, web technologies such as HTML5 and JavaScript are applied on top of the solution stack. All these technologies are used in a numerous of applications worldwide.

The service has been tested internally and during the OGC Testbed 11. However fully test coverage and real life experience with numerous customers or as a dedicated application are not available.

Regarding the readiness for industrialization our prototypical implementation provides a solid basis, which can be immediately used for schema based syntactic validation tasks and needs additional effort to be invested for semantic rule based data validation and evaluation.

3.5 Technical constraintsNot known so far.

15

4 Benefits

4.1 Business benefitsStandard ATM formats for aeronautical, weather and flight data (WP8 AIRM standardized AIXM, WXXM and FIXM) are becoming more widely accepted in both USA and EU ATM communities. As more and more data is being on-ramped via SWIM in the form of data publishers and web services, governance of this information becomes critical for managing the information content and quality. In an operational context, the data must be validated as a precondition for safety, security, and efficiency of operations. This fact has also been considered in the design of SWIM-TI and assigned to the Data Validation Function Block (DV FB).

The validation of data documents is essential, especially when exchanged across autonomous organizational domains such as Flight Information Region (FIR) boundaries. The aviation data quality assurance methods presented here is an implementation of SWIM-TI DV FB. It is based on the declarative data validation and business rules enforcement, tasks that are essential for safety and security. Declarative approach has many advantages over ad-hoc programming but it also requires design and implementation of an expert system for access control, rule management and validation execution.

The availability of validation and business rule enforcement services as community-wide available cloud services operated inside or outside of SWIM is the best way to ensure high quality of aeronautical data in technical efficient and costly effective way. Additional benefits are obtained through additional features such as the use case dependent business rule validation using user defined rule sets. Validation results are also applicable for routing and third party service access control - policy enforcement. The service implementation proposed offers full technical infrastructure needed to perform all validation tasks:

Centralized service in cloud or service oriented architecture

Standardized service endpoint, user management and access control

Syntactic data validation

Semantic data validation and business rules

User defined validation and business rules

In the case of many local dedicated implementations per SWIM region, consistency and quality issues combined with high development and maintenance costs are likely to arise. Some of this risk can be avoided through the use of SOA architecture at a global SWIM “cloud” level. It is also crucial that standards such as ISO, OMG, and OGC be adopted for the implementation of data validation services to ensure interoperability and reduce re-work for each SWIM domain user.

4.2 Technical / technology benefitsThe aviation data quality assurance methods are based on the declarative data validation and business rules enforcement, tasks that are essential for safety and security, whenever the aeronautical data are created and exchanged or business processes executed.

Solution presented here provides a technology unique, standardized way for domain experts to define what is supposed to be valid in a context of aviation data types and business cases. They do not need to program, test and maintain hard to understand programming code. The service was designed as SOA based, flexible data validation embedded into SWIM technical infrastructure and available to all stakeholders as a SWIM technical infrastructure service. Depending on deployment strategy it reduces costs and improve reliability and quality of validation (in case of centralized service style

16

deployment and operation). The service offers needed technical assistance in form of service and using the most compatible, standard technologies and technical implementation. A couple of the most important technical benefits are listed below:

High usability and lower development costs through the use of declarative approach suited for domain experts

Central point for technical implementation and execution of quality data assurance.

Business process decision supporting tool

Web based validation service available in internet supports SWIM early adaptation and familiarization

In the SESAR WP14 documents it has been stated that the SWIM-TI role is to be a “technical enabler for SESAR’s system of systems concept, which defines the future European ATM as highly collaborative, dynamic environment”. In the context of SWIM the Data Validation Functional Block provides essential support for SWIM-TI early adaption. Free, web based validation service available at plays an increasing role for informing the aviation audience about possibilities regarding the quality data assurance in the context of SWIM-TI.

17

SWIM Compliance Self-Assessment

4.3 Data structure

4.3.1 AIRM complianceThe data validation’s task is to check the conformance of input documents in accordance with ATM Information Reference Model specification7. Service message body is therefore subject of validation and must not necessarily be compatible with one of data formats described in AIRM. The validation service itself is compatible with AIRM is sense that it is equipped with all aviation data formats’ schemas and can perform checks returning assertions about syntactic (conformance with one of AIRM data schemes) and semantic correctness of input document. Therefore the validation service is responsible to ensure that all data exchanged within the SWIM are compliant with AIRM. The service endpoints are modelled and implemented in accordance with SWIM-TI Yellow Profile (YP).

4.3.2 Physical data model maturityThe validation service itself is based on standard, SWIM-TI YP compatible solution stack: plain XML via HTTPS/TCP/IP. The logical data formats supported by this services are all those stated in the AIRM. On the other side, the validation service supports validation and business rule evaluation for physical data models based on the extensible mark-up language, XML and corresponding XML schema specifications. Therefore, it applies to the currently most frequently utilised physical data model worldwide.

4.4 Service

4.4.1 Service endpoint documentationThe validation service has been registered and documented in the SWIM Registry under following address:

http://eur-registry.swim.aero/services/m-click/aeronautical-data-validation-service-10# http:// eur-registry.swim.aero/services/m-click/aeronautical-data-validation-service-10

Further validation fronted application supposed to provide support for human based validation tasks is available under following URL:

http://eur-registry.swim.aero/services/m-click/aeronautical-data-validation-service-10

SWIM registry contains the full service description including SWIM-TI compliance statements at:

http://eur-registry.swim.aero/services/m-click/aeronautical-data-validation-service-10

http://eur-registry.swim.aero/applications/m-click/aixm-schema-business-rules- validatorValidation

Web Client is available for free testing under following URL:

https://swim.m-click.aero/validator/

7 http://eur-registry.swim.aero/information-reference-document/airm-primer

18

4.5 Infrastructure

4.5.1 Use of recognized mainstream protocols/standardsThe validation service uses solution stack based on XML via HTTP(S) over TCP/IP. Therefore it is fully based on one of the mainstream communication stacks, which is also standardized in the SWIM-TI Yellow Profile. Further standards used to describe validation rules and enforce the validation are:

HTTP/TCP, XML

ISO Schematron for XSLT8

OMG SVBR9

4.5.2 Adopted security mechanism Security mechanism is implemented in accordance with chosen YP Generic Binding, which is the “Plain Old XML (POX) over HTTPS POST over TCP”.

SSL/TLS with server side authentication is used to protect the communication channel and avoid man in the middle attack. For client side authentication we use HTTP Auth., providing user credentials via protected HTTPS channel in form of user/password token.

4.6 Governance

4.6.1 SLA in the context of the SWIM Master ClassSLA in the context of SWIM Master Class is not available. In the operational use as a cloud service, the validation service will possess usual SLA characteristics in accordance with web based, best-effort paradigm and the SWIM-TI Yellow Profile.

8http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=40833 9 http://www.omg.org/spec/SBVR/

19

Appendix A Used Works

ICAO ASBU. (2013, March 28). Aviation System Block Upgrades. Retrieved September 17, 2015, from International Civil Aviation Organization: http://www.icao.int/sustainability/Documents/ASBU.en.Mar. 2013.pdf

ICAO MG. (2015, March 17). Mini-Global Project Demonstrations. Retrieved September 17, 2015, from International Civil Aviation Organization: http://www.icao.int/MID/Documents/2015/DGCA 3/IP4_en.pdf

ISO. (2006, June 01). ISO Publicly Available Standards. Retrieved September 17, 2015, from International Standards Organization: http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip

OGC. (n.d.). OGC Testbed 11. Retrieved September 17, 2015, from Open Geospatial Consortium: http://www.opengeospatial.org/projects/initiatives/testbed11

OMG. (2015, May 07). SBVR. Retrieved September 17, 2015, from Object Management Group: http://www.omg.org/spec/SBVR/

Rules. (2015, September 14). AIXM 5.1 Business Rules. Retrieved September 17, 2015, from AIXM Wiki: https://ext.eurocontrol.int/aixmwiki_public/bin/download/Main/AIXM_Business_Rules/AIXM-5.1-BusinessRules-v.0.5.xlsx

SBVR. (2014, June 04). AIXM 5.1 Business Rules. Retrieved September 17, 2015, from AIXM Wiki: https://ext.eurocontrol.int/aixmwiki_public/bin/download/Main/AIXM_Business_Rules/AIXM-5.1-BusinessRules-usingSBVRandSchematronV0.3.docx

SWIM Profiles (Ectrl, 2015) http://www.sesarju.eu/sites/default/files/documents/swim/SESAR-Factsheet-2015-SWIM-Profiles.pdf

P14.1.3-D35 SWIM Architectural Definition for Iteration 3.0 http://eur-registry.swim.aero/sites/default/files/P14.1.3-D35-SWIM%20Architectural%20Definition%20for%20Iteration%203.0.doc

SWIM-TI Yellow Profile http://eur-registry.swim.aero/infrastructure-profile/yellow-profile

AIRM Primer http://eur-registry.swim.aero/information-reference-document/airm-primer

20

Appendix B Validation Web Client

B.1 Input document und validation report

Figure 9 - Validation Service user interface

1

Appendix C Generic Interface BindingThis appendix describes SWIM Yellow Profile generic binding used to implement the access point for DV FB operations (validation service).

C.1 Plain Old XML (POX) over HTTPS POST over TCP. Generic service instantiation shall be supported on the following interface binding:

Protocol stack:

o Plain Old XML (POX) over HTTPS POST over TCP.

MEP:

o SRR-MEP

Fault handling:

o The service shall be able to determine the content of the HTTP status code and HTTP reason phrase

Encoding:

o HTTP POST: application/xml; charset=UTF-8

Security:

o Confidentiality: transport

o Integrity: transport

o Authenticity: transport mutual

o Authorization: transport

o Non-repudiation: none

Contract:

o Existing: described in XSD

o Future: described in XSD

Contract: - formalism of contract description:

o Described in XSD - minimum: not applicable

o Reference: ISRM

2

-END OF DOCUMENT-

3