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

in

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.


2003

2004

2005

2007

2006

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



Cont.

3. Implementation of demonstrators

4. Evaluation of demonstrators

5. Produce DATEX 2.1 specifications for the market



Cont.

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

End


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

IDL

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

TC204

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


WP 1

• 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


MDA

• 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


Tools

• 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

1

1

1

1

+conveys

+toBeExchanged

uses


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?


WP 2

• Role

• Tools

• Format


Role

• Same function as the old Data Dictionary

• Include all definitions


Tools

• 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


WP 3

• 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)


Demo

• 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.


WP 4

• 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.


WP 5

• 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

Documents

VIKING Domain2 DATEX2 Workshop in Stockholm 7 - 8 June 2005