VIKING Domain2 DATEX2 Workshop in Stockholm 7 - 8 June 2005

7-8 June 2005 Viking Domain 2 DATEX2 Workshop in Stockholm 1

VIKING Domain2DATEX2 Workshop

Stockholm

7 - 8 June 2005

Agenda Tuesday 7 June 1000 – 1700

10.00 – 11.30 Welcome and presentation of the DATEX2 project

11.30 – 12.30 Lunch

12.30 – 14.30 Presentation of the data model and data dictionary (WP 1 and 2)

14.30 – 14.50 Coffee

14.50 – 15.30 Presentation of the data model and data dictionary (cont.)

15.30 – 16.30 Discussion and conclusions about the data model and data dictionary

16.30 – 17.00 Presentation of the XML schema (WP 3) and discussion

19.00 Dinner

Wednesday 8 June 8.30 – 12.30

08.30 – 09.00 Presentation of the Platform Independent Model (PIM) for data exchange (WP 4)

09.00 – 09.30 Discussion and conclusions about the PIM for data exchange

09.30 – 10.00 Presentation of the study for Platform Specific Models (PSM) for data exchange and “Low cost profile” (WP 4 and 5)

10.00 – 10.20 Coffee

10.20 – 10.50 Discussion and conclusions about PSM for data exchange and “Low cost profile”

10.50 – 11.20 Presentation of the study for migration (WP 6) and discussion

11.20 – 12.30 Concluding discussions and harmonising of Viking viewpoints

12.30 Close of workshop and lunch

Background

• Standardisation – CEN ENV13106 and ENV13777

• DATEX MoU – organisation – GAS,SMC,TC – User Fora

• EC – role

• EG-Projects - members

The DATEX2 Project

• Tender procedures• Organisation• Work packages• Progress• Status today • TC´s role• Ongoing work

DATEX2 Project - Organisation

• The European Commission - owner of the study,The DATEX2 Project finances and signs the contract.

• The DATEX Technical Committee (TC) - supports the Commission in the programme definition and the technical aspects of the study.

• The contractor - a consortium of experts led by Faber Maunsell.

EC initiative for a DATEX projectTechnical specificationPreannouncment for a DATEX projectInvitation to tenderStart of the project

FM consortium – 6 wpTC monitoring

End of the DATEX2 projectTC continues the work

Interoperability between a RP and a LCPMigration

Demonstrator – ITS Barcelona 2006 Testing and validationReleased documents

DATEX2 implementations

DATEX2 Project

• WP1: Data Model

• WP2: Data dictionary

• WP3: XML schema

• WP4: Exchange model and PSM study

• WP5: Low cost profile

• WP6: Migration

WP1: Data Model

• Content Platform Independent Model (PIM)

• Described in UML

WP2: Data dictionary

• Revision of the current DATEX Data Dictionary (ENV 13106)

• Requirements from EC - DATEX TC and CEN TC278 WG8

WP3: XML schema

• Derived from the data model

• Generated by software

WP4: Exchange model and PSM study

• Exchange Platform Independent Model (PIM)

• Exchange Platform Specific Model (PSM) study

WP5: Low cost profile

• Simple and low cost

• Minimum implementation and link establishment complexity

WP6: Migration

• Migration path from old Datex

• Backwards compatibility issues

DATEX Technical Committee

Strategical road map for DATEX2

DATEX Objectives

Facilitate the widespread exchange of travel information in EU through the use of common standards and best practice for both public-sector and commercial interests and ensure there are mechanisms in place to make them happen.

The way to the market

1. Finalize the DATEX2 project

2. Produce usable DATEX2 documents (DATEX 2.0 specifications) – PIM Data Model incl. Data Dictionary– PIM Data Exchange– XML-schema– PSM Data Exchange using HTTP, XML

and Web Services– ”Low cost profile” (subset of ”Regular

profile”)

3. Implementation of demonstrators

4. Evaluation of demonstrators

5. Produce DATEX 2.1 specifications for the market

6. Organize and implement DATEX support

7. Start the standardisation process in CEN

Comments:

• ”Low cost profile” is a true subset of ”Regular profile”

• Migration is a matter of normal upgrading or implementation of a new system and is handled by the users of DATEX

Strategical road map for DATEX2

Relationship with Other Initiatives

– ISO TC204 WG9.1

• Should be considered in modelling activity

– CENTRICO OTAP

• The initial phase of OTAP should be a simple form of the interface defined in this standard.

• The Platform Independent Models used in OTAP should be compatible with the models defined in this standard

– Trident

• Experience in the PT domain is useful

Structure

• Divide Project into:

– Platform Independent Model (PIM)

• Independent of the implementation technology

• Universal across all implementations

– Platform Specific Model (PSM)

• Specific to the implementation technology

• One model for each technology

• New models added as new technologies become available

The DATEX Project

INTERFACE

UML Mapping requirements/restrictions to implementationtechnologiesPlatform

SpecificModel(PSM)

JAVA RMIImplementation

PlatformIndependent

Model(PIM)

XML (HTTP)Implementation

XML Schema

CORBAImplementation

EDIFACT(FTP - ISDN)

Implementation

SOAP(XML - HTTP)

ImplementationXML Schema

EDIFACT(FTP - HTTP))

Implementation

Exchange Mechanism / Protocol(Interface Definition - technology Independent)

Various levels of sophistication(simplest being OTAP)

Modelling/Definition of I/F objects& methods (+ sequence, state,

collaboration diagrams)

PIMTesting /

CertificationStrategy

(Independentof

technology)

Static UML Information Data Models(DATEX Data Object Models)

Universal modelsindependent of Technology

(see UML mappingrestrictions)

UML Static Models of Objects(defining relationships,

attributes but no methods)

Methodology for Development ofStatic UML Information Models

PSMTesting /

CertificationStrategy

(Specific toTechnology)

Data Dictionary(Data Registry ISO 14817 ?)

Input fromISO

Location Referencing(on-the-fly referencing ?)

INTERFACE

Platform Independent Model (PIM)

• Methodology for developing Static Information Publication Models

• Static UML Information Publication Models (DATEX Data Objects)

• Location Referencing

• Data Dictionary

• Exchange Mechanism / Protocol (PIM interface)

• PIM Testing/Certification Strategy

Platform Specific Model (PSM)

• UML Mapping Requirements/Restrictions to specific technology

• Technology Specific Model (one for each technology)

• PSM Testing/Certification Strategy (one for each technology)

PIM - 1

• Static UML Information Publication Models (DATEX Data Objects)

– What Data Objects are to be modelled?

• ACC, INC, RMK, LOS, TTM, AVS, CTT, FLO, IVD etc.

• new object types e.g. both fixed and moving images

– All attributes in Data Dictionary or only those known to be used?

– Multimodality (PT) ?

PIM - 2

• Location Referencing

– What system? Compare options

• AlertC Location Code

• TPEGLoc

• ....

– Extendable to PT ?

– On-the-fly referencing ?

PIM - 3

• Data Dictionary

– Static (frozen) or dynamic dictionary?

– Application to Data Registry (ISO 14817)

– Data Directory functions ?

PIM - 4

• Exchange Mechanism / Protocol

– Various levels of sophistication

– Simplest being initial like OTAP

– Objects with behaviour (methods)

– Sequence, state and collaboration diagrams

PIM - 5

• PIM Testing/Certification Strategy

– Defined testing/certification strategy for each level of sophistication of the interface

– Is independent of the implementation technology

– Will be used as basis for PSM testing/certification strategies

PSM - 1

• UML Mapping Requirements/Restrictions

– Each technology may impose restrictions on validity of UML models, e.g.

• UML Profile for CORBA

• XMI

PSM - 2

• Technology Specific Model

– Each technology will have its own model defined

– Will define how the Interface specified in the PIM is mapped on to the specific technology, e.g.

• IDL for CORBA

• XML Schema for XML over HTTP

– Each model will define link management appropriate to the technology

PSM - 3

• PSM Testing/Certification Strategy

– Specific testing/certification strategy for each implementation technology

– Defined testing/certification strategy for each level of sophistication of the interface

– PIM Testing/Certification Strategy will be used as a basis

• Type of model

• MDA

• Deliverables

• Constrains report

• Tools

• Model content

• Detail study of the model

Type of model

• UML model

• Model driven Architecture (MDA)

• It is a content model for exchange of traffic information– It’s not a data model that you put in a database

– It’s not a model that you need to have in a TIC system.

• In the model we describe the information and how it relates to other information.

• It’s the content/payload

• Independent of technology

• Model Driven Architecture

• Defined by OMG (Object Management Group)

• PIM (Platform Independent Model)

• PSM (Platform Specific Model)

• A PIM can be realized in more then one PSM.

• DATEX1 technology dependent

Deliverables

• Constrains report– Notation– Rules and UML constrains– Naming conventions– Extension mechanisms– Tagged values– Data types

• UML model

Requirements

• Input from– DATEX1– TRIDENT– OTAP– National extensions– Etc

• All inclusion option was chosen

Data types

• Generic data type are defined like Integer, String etc.

• Support that you can create your own specific data types. Those have to be derived from a Generic data type.

• E.g.– Old Attribute SpeedInMetersPerSecond– Now

• A data type called MetersPerSecond• An attribute called Speed with data type

MetersPerSecond

• Enterprise Architect, http://www.sparxsystems.com.au/

• Cheap 200€

• Free viewer

Model content

• Four high level packages– General– Payload (WP1)– Exchange (WP4)– Management (?)

Model contentcd D2LogicalModel

Payload

+ Payload

+ Publication

General

+ DataTypes

+ Location

+ PayloadEnumerations

+ ReusableClasses

Exchange

+ Authorization

+ CatalogueReference

+ Compression

+ Encryption

+ Exchange

+ FilterReference

+ Subscription

+ Target

+ ExchangeEnumerations

D2LogicalModel

Exchange::Exchange

+ supplierIdentification: String+ clientIdentification: String [0..1]+ requestType: RequestTypeEnum [0..1]+ response: ResponseEnum [0..1]+ subscriptionReference: GUID [0..1]+ keepAlive: Boolean [0..1]+ creationTime: DateTime+ deliveryBreak: Boolean [0..1]+ changedFlag: ChangedFlagEnum [0..1]+ historicalStartDate: DateTime [0..1]+ historicalStopDate: DateTime [0..1]

Payload::Payload

+conveys

+toBeExchanged

General

cd General

ReusableClasses

+ DataCharacteristics

+ HazardousMaterials

+ HeaderInformation

+ Mobility

+ NonManagedCause

+ Record

+ RecordIdentifier

+ Restriction

+ SituationRecord

+ SourceInformation

+ TrafficViewRecord

+ ClassificationScheme

+ ElaboratedData

+ Impact

+ People

+ Period

+ Vehicles

+ WeatherRelated

+ TrafficElement

+ OperatorAction

+ Advice

PayloadEnumerations

+ PayloadEnumerations

+ AtoD

+ EtoH

+ ItoM

+ LocationEnums

+ NtoR

+ StoZ

Location

+ AlertCDirection

+ AlertCLinear

+ AlertCLocation

+ AlertCPoint

+ AlertCPrimaryPointLocation

+ AlertCSecondaryPointLocation

+ Area

+ Destination

+ GroupOfLocations

+ Itinerary

+ ItineraryIdentifier

+ Linear

+ Location

+ NetworkLocation

+ OffsetDistance

+ Point

+ PointsByCoordinates

+ PositionalDescription

+ TPEGLanguage

+ AlertCArea

+ AlertCLinearByCode

+ AlertCMethod2Linear

+ AlertCMethod2Point

+ AlertCMethod4Linear

+ AlertCMethod4Point

+ TPEGAreaLocation

+ TPEGDescriptor

+ TPEGEnumerations

+ TPEGLinearLocation

+ TPEGPointLocation

DataTypes

+ Generic

+ Specific

Payload

cd Payload

Payload

«abstract»Publication::Publication

Payload Publicationscd Publication

«abstract»Publication

CataloguePublication::CataloguePublication

ElaboratedDataPublication::ElaboratedDataPublication

LocationTablePublication::LocationTablePublication

MassDataPublication::MassDataPublication

MeasurementTablePublication::MeasurementTablePublication

SituationPublication::SituationPublication

TrafficViewPublication::TrafficViewPublication

FilterPublication::FilterPublication

NetworkViewPublication::NetworkViewPublication

Publications

• Show all publications

• Focus on – SituationPublication– MassDataPublication

DATEX2 vs DATEX1

• All is identified with GUID• Not bound to AlertC LocationCode• TPEGLoc support• X and Y support• No Trigrams• A real data model• Hierarchical “attributes”• Split in TrafficElements and

OperatorAction• Old DOB’s have a separate definition of

what it contains.

Summary

• Large model – union

• Not finished, but a good starting point

• Refinement of traffic data?

• Core model and national extensions?

• Role

• Tools

• Format

• Same function as the old Data Dictionary

• Include all definitions

• Definitions are in the PIM UML model, as tagged values.

• The tag “Definition”

• The dictionary is created with a tool that extracts all definitions and puts those in a Word document.

More definitions

• Not all definitions are in the UML model– Vehicle classification– Speed classification – etc– Other describing text

• Currently no domain ranges

Summary

• The final document will be created when the model is finished.

• Tight connection to the model

• National DD are still needed for translation

• Deliverables

• The role of the XML Schema

• The process

• The tool

• Demo create a Schema

• Demo create a XML document

• Summary

Deliverables

• Word document describing the process and the rules

• XSD conversion tool

The role of the XML Schema

• XSD

• The XML Schema will be the base in all PSM implementations.

• Act as a specification of the protocol

• Validation

The process

DATEX 2UML Model

Enterprise Architect

DATEX 2 Conversion Tool

XML Schema

XML Spy

saved as XMI

saved as XSD

DATEX 2Namespaces

&Data Type

Transformation

saved as Config.XML

The tool

• Developed in C# (MS.Net)

• Open Source

• The tool reads an XMI file and creates an XSD file.

• XMI (OMG specification, how to store an UML model in XML)

• Create a Schema

• Create a XML document

Summary

• Very simple to create a XML Schema from the UML model.

• The tool also helps validating the UML model.

• Background

• Deliverables

• Deliverable modes

• Define the Exchange package

Background

• At a PIM level define the exchange mechanism

• The dynamic features

• Without choosing technology

Deliverables

• UML model – Sequence diagrams– Exchange package

• Word document

The document

• System overview

• Defines Actors

• Use cases

• Deliverable modes

The document

Use cases

Exchange

Sequence diagrams

Summary

• Sometimes handles internal things

• A lot of optional things

• A more clear definition of the interface is needed.

WP4 PSM study

• Background

• Deliverables

• Summary

Background

• The study has, evaluate and proposed the best suited technology for the “regular profile”

Deliverable

• Document

• A workshop

DocumentPossible Candidates

• Transport Control Protocol / Internet Protocol– TCP/IP is the basis for all following communication protocols. In addition it

can be used on its own and is known as socket connection. It is a powerful and flexible platform, but programming TCP/IP as it is can be a complex job.

• File Transfer Protocol– FTP is a simple and widely used protocol. Its functionality is limited though.

• Hyper Text Transfer Protocol– HTTP is a simple and standardised protocol. Its functionality is limited and

additionally leads to some server overhead.• Remote Method Invocation

– Java RMI is relatively simple, powerful and flexible. It uses HTTP as communication medium. It is pure Java so it inherits all advantages and disadvantages of Java.

• Common Object Request Broker Architecture– CORBA is powerful and flexible. Its complexity is a big disadvantage.

• Web Service– Web services are software-powered resources or functional components

whose capabilities can be accessed via internet. Standards-based web services use XML to interact with each other, which allows them to link up on demand. Web Services use HTTP as communication medium.

Study criteria

• Referring to ISO 9126

• Functionality, performance, usability etc.

• Out comes a matrix

• The winner was…

Outcome from workshop

• Workshop in January 2005

• The workshop agreed on technology

• Web Services, HTTP, XML

Summary

• Web services the best suited technology for Datex2.

• Background

• Deliverables

• Summary

Background

• Low cost profile

• OTAP inspired

Deliverable

• A short document

Basic idea

• Subset of regular profile

• Client requests only

• No subscription management

• All data sent every time

• Cheap and easy to implement

Summary

• Ongoing project in Centrico

• Looks like OTAP exchange

• DATEX2 content

• Compatible with Regular profile SERTI

Conclusions and Viking statements

• Data model and Data Dictionary– Union vs core model– Traffic data and refinement– Structure

Refinement chain

Data collection

Data supplier

Refinement of data

Content provider

Refinement to services

Service provider

Dissemination to road user

Distributor

Presentation and use

Road user

Main objectives:

• Traffic safety

• Availability

• Environment

• Exchange model– Degree of refinement– Level of standardisation

• Low cost profile– Subset of regular profile?– Matter of implementation?

• Migration– Matter of implementation?– Issue for the market and users?

Viking and DATEX2

• Swedish test implementation 2005

• Viking test sites?– Denmark– Finland– Germany– Norway

VIKING Domain2 DATEX2 Workshop in Stockholm 7 - 8 June 2005

Documents

VIKING-YACHTING.COM RescYou Pro liferaft Learn …...May 2017 VIKING LIFE-SAVING EQUIPMENT A/S VIKING RescYou liferafts range Tel +45 76 11 81 00, Email: VIKING@VIKING-life.com Choose

Dishwasher - Viking Parts by Viking - Factory Parts for

Viking Voice - Okaloosa County School District€¦ · Viking Voice Weekly Newsletter ... Contact Connie Krembel, 833.3300 X1271 ... Viking extracurricular activities, and Viking

Viking V1N2 pp4-5 · VIKING APPLIANCES 36"W. Viking Overlay Refrigerator/Freezer, DFBB363L 36”W. Viking All Gas Range 6 Open Burners,VGIC365-6BSS 36"W. Viking 6" Height Backguard,

Viking V2N2 Vegas4-5 pp - Viking Range, LLC

Viking Parts by Viking - Factory Parts for Viking Appliances

Viking Bladder Tanks - Viking Group Inc bladder tanks/Viking... · The Viking bladder tank, together with Viking ratio controllers, form ... (FM versions subject to extra price in

VIKING HIGH VISIBILITY · Saedding Ringvej 13 . 6710 Esbjerg V . Denmark Tel.: +45 76 11 81 00, E-mail: VIKING@VIKING-life.com VIKING LIFE-SAVING EQUIPMENT

Viking Roof Garden Membrane System Product Warranty · and training provided by Viking Roofspec (“Viking Specifications”). 2. This Warranty covers only materials supplied by Viking

Grzegorz Żabiński VIKING AGE SWORDS FROM … · 30 Map 1. Viking Age swords from Scotland (Viking Age sword finds and Viking graves after RCAHMS; Viking settlements after Barrett

Page 1 of 25 - Viking Parts by Viking

Instruction Guide Viking M / Viking L / Viking XL -

VICU53616BSS - Viking Parts by Viking - Factory Parts for

Multi-tenancy - Cisco · Multi-tenancy ConfiguringMultipleLeaf. bridge-domain2 fabric-control bridge-domain2,10-11 membervni5000,10010-10011 vrfcontextCisco:vrf1 vni20000 ipv6pimssmrangeff30::/12

RescYou Coastal liferaft - Viking Life-Saving …...January 2020 VIKING LIFE-SAVING EQUIPMENT A/S VIKING RescYou liferafts range Tel +45 76 11 81 00, Email: VIKING@VIKING-life.com

Danielson domain2

Viking Graben

REGLAS ARTES GRÁFICAS VIKING - · PDF fileREGLAS VIKING PARA TROQUELES PLANOS Reglas de corte VIKING VIKING MM, VIKING FLEX página dureza / calidades ﬁlos superﬁcie recubrimientos

VIKING HOMELANDS CRUISE · Viking River Cruises is known for. Viking Sea, the third ship, in Viking’s new ocean cruise line, Viking Ocean Cruises. Like her sisters, Viking Star

Viking longships