DATA ACCESS TECHNOLOGY FOR TTI SERVICES SUMMARY

Transcription

1 DATA ACCESS TECHNOLOGY FOR TTI SERVICES Dr. Josef Kaltwasser Senior Consultant Heusch Boesefeldt GmbH, Tempelhofer Str Aachen, Germany tel: fax: web: SUMMARY As response to EC s recommendation on the development of a legal and business framework for participation of the private sector in deploying telematics-based Traffic and Travel Information (TTI) services in Europe, European road operators have incorporated data access technology into their European ITS deployment programme TEMPO. The paper presents the technical concept chosen in the CENTRICO project to demonstrate Open TIS Access Points (OTAP), improving data access for seamless services on some of Europe s busiest roads. RATIONAL OF THE OTAP DEMONSTRATOR Commercial, operational data exchange between road operators as content providers and providers of Traffic and Travel Information (TTI) services is well established on regional / national level throughout Europe. What still can be observed is a lack of seamless cross-border services that operate throughout Europe. One of the reasons for this may well be that there is no harmonisation yet between these island solutions, confronting potential providers of such services with a high commercial risk. Accessing information from various sources implies dealing with data access in various countries and languages, according to different legal frameworks and data access policies, under different terms and conditions via different interface specifications and concerning different content and quality. As a reaction on the EC s recommendation on the development of a legal and business framework for participation of the private sector in deploying telematics-based Traffic and Travel Information (TTI) services in Europe (1), the CENTRICO project covering the Southeast of England, the North of France, the Low Countries and the West of Germany has decided to establish a demonstrator for an improved, easy access of TTI service providers to the increasing amount of real-time traffic and travel related data held in the road operators databases. While up to now demonstrators and test sites have concentrated on small scale feasibility demonstrations with high technical ambitions in a R&D environment (like, e.g., in the TRIDENT project (2)), CENTRICO is aiming at a large scale, deployment oriented demonstrator that can later be developed into commercial services, with a full coverage of the CENTRICO area. Thus, the demonstrator will cover areas as important as Greater London, the Ruhrgebiet or the conurbations in the Low Countries. In its initialisation phase in 2002, CENTRICO has elaborated on the technical options and requirements for data access 1

2 technology in such a challenging environment. This paper presents the concepts chosen and the solutions found. REQUIREMENTS As a start, the CENTRICO project team conducted several workshops that aimed at identifying functional requirements and business needs for the anticipated interface. The following key issues were identified: easy access to data; good geographical coverage of data; reliable/known quality of data; reliable delivery of data; harmonised descriptions of the data content; and accessible and standardised terms and conditions for data access and usage. In a second step, these functional requirements were analysed in depth on how they would affect the technical specification of a data access interface. The result was the following set of technical requirements for the OTAP demonstrator: the OTAP shall minimise implementation complexity of SP side of solution; the OTAP shall maximise availability of technical support for the proposed solution in common system development environments; the OTAP shall not reduce the data quality itself or the reliability of this quality; the OTAP shall not constrain the TICs capabilities of describing data quality; the OTAP shall provide reliable delivery of information / data; the OTAP shall describe the basic data primitives used to build the provided data structures in a data dictionary, providing name, semantic description and technical specification for each entry (language for description is English); the data model used to structure the elements of the data dictionary for the OTAP shall be described and made available (UML description preferred, if this is not possible table / textual descriptions are acceptable, description language shall be English); the OTAP shall support mapping of location references (e.g. RDS-TMC location codes according to CEN ENV ) to digital road maps by providing WGS84 latitude/longitude co ordinates. the regulatory and contractual framework for using the OTAP shall be made available via easily and quickly accessible channels (preferably Internet). It shall minimise the reference to external documents (e.g. legal frameworks), support the SP as much as possible in obtaining external information (where it can not be avoided), and be made available in English language. Based upon these technical requirements, the following mission statement was derived for a generic concept of the OTAP system: Design an interface for Traveller Information Services to access online traffic and travel related data collected in databases of road operators' Traffic Information and Control Systems (TICS). Make this interface as 'easy' as possible by preferring widespread technology 2

3 with low technological entry threshold and giving highest priority to choices that offer minimal costs and maximal stability for both, the centres and the service providers. The resulting concept is based upon the following key principles: use the Internet as Wide Area Network; use a simple client / server interface paradigm based upon the HTTP protocol; frequently update complete situation descriptions; use XML / XML Schema for data coding; use attributes / phrases / supplementary advises according to the DATEX Data Dictionary (ENV 13106:2000); describe the data models used in UML; and provide WGS84 latitude/longitude co ordinates in addition location referencing tables. A major observation concerning the key principles presented so far when compared to many other, similar initiatives in ITS in the past is that the focus of this work lies on avoid inventing new, ITS specific technology. The intention is rather to identify suitable standard ICT technologies and tailor them to the envisaged application in ITS. Throughout the rest of this paper, we will describe the concept in detail, devoting one section per major technology used for the OTAP Entry Level specification that will be used throughout the OTAP Demonstrator project carried out as a one year Centrico project in 2003/4. These technologies are: UML (Unified Modelling Language) as the main data modelling notation preferred to describe the data model of TTI publications, see (3). XML (extensible Mark-up Langiage) as the most widely used transfer syntax for structured data (see (4)), in business to business (B2B) environments usually used in conjunction with the XML Schema specifications (3). HTTP (HyperText Transfer Protocol) as the standard application layer protocol on the most widely use part of the Internet, the World Wide Web (WWW). DATA MODELLING The basic assumption underlying the OTAP work was that it would be simply impossible to standardise the models of all data exchange flow via the OTAP interface. While this might have been an option for the initial, Centrico led demonstrator given the fact that most content providers were planning to build their OTAP feeds on top of existing DATEX systems, it was obvious on the long run that the OTAP mission would be requiring an open, inclusive policy that would encourage participation from as many content owners as possible. Thus, the entry threshold had to be as low as possible and this would certainly mean that organisations intending to publish their data would not be forced to apply a different data model. On the other hand, clients need a semantically rich, consistent description of the data provided via a data exchange interface to be able to develop their clients against it and to enable them to get the maximum benefit out of the data they receive. The OTAP answer to this conflict is not to standardise the data model itself, but to prescribe and standardise the way the content providers describe the data model they are using in their data to the client, i.e. to standardise the metamodel. In the strive to use industry standard 3

4 solution with broadest possible support, decision was taken to go for UML as the standard description model for object oriented systems, although in the envisaged application only the static parts of UML class modelling are used, i.e. classes and their attributes, but no behaviour. From various similar approaches taken in other domains (e.g. the UML profile for CORBA, see (7)), it became quickly apparent that it would not be sufficient to prescribe the use of UML as such together with the prescription of the English language for all specifications to support European wide use but that additional rules would be needed on which UML elements to use for these publication models and how to use them. Again, experiences in this field were available to start from, e.g. from the TRIDENT and COURIER projects. In the end, a set of 10 clauses was specified that governed the use of UML in specifying publication models for OTAP. +key 1 DemoEntityKey demoentitykeyattr1 : Decimal DemoAbstractEntity entityatt1 : Decimal <<0..n>> entityattr2 : String entityattr3 : DemoSpecialType entityattr4 : DemoSpecialEnumeration +democomponent 0..n DemoComponent <<0..1>> compattr1 : String compattr2 : Decimal <<0..n>> compattr3 : DemoSpecialType <<0..n>> compattr4 : DemoEnumeration DemoDerivedEntity derivedentityattr5 : Decimal +somebodyelse 0..n AnotherEntity OTAP entity / component modelling examples This diagram illustrates the main concepts prescribed for modelling objects in OTAP. A distinction is made between objects from the application domain named entity classes which denote physical object concepts from traffic engineering that have their own identity and their own lifecycle, and artificial objects invented to group associated attributes, which will always belong to some other object. For entities, the concept of a key is used which denotes the part of the object state that gives identity to the object. UML itself does not know this concept, i.e. it relies completely on implicit object identification. This may be seen as an advantage from pure object oriented perspective, but experiences in data modelling show that with the envisaged objects state serialisation for data exchange in mind it is beneficial to explicitly model this aspect of data. Key attributes are collected in a component class (see below) which is a UML class that stands in a composition relationship (multiplicity 1, role name key ) to the entity class. Component classes are logical attribute groupings that give additional semantics but can not live on their own, i.e. they are always in a whole / part relationship to other objects, either other components or entities. Thus, components do not have keys. Entities themselves may also be part of other classes. Nevertheless, this is seen as a less dependant relationship and thus modelled as an aggregation rather than a composition in UML (see relation between DemoDerivedEntitiy and AnotherEntity in the example). 4

5 Classes may inherit from other classes in a specialisation relationship, i.e. they are derived from another class and they extend the base class object state. In OTAP, only single inheritance is allows to avoid the well known multiple inheritance problems of ambiguous state definitions. Base classes may be indicated as Abstract (a stereotype that is by default denoted by setting the class name in italics), which means that it is not allowed to create instances from these classes, but only from derived classes. Attributes types are fixed to be either Decimal, String, an enumeration or a special type, where special types are used for types that are either constrained (e.g. a decimal with a specific value range), or have a special physical domain (e.g. a unit like km/h ), or both. Thy are modelled as classes with a DatatType stereotype and are derived from either Decimal or String. An enumeration is modelled as a class with an Enumeration stereotype, giving the allowed literals and also if applicable additional explanations / long names. <<Enumeration>> DemoEnumeration demoliteral1 : long name 1 demoliteral2 : long name 2 String Decimal <<DataType>> DemoSpecialType OTAP type modelling This rigid type structure was chosen because domain modelling was identified as a weak part in UML and derived mappings to exchange formats and the given structure allows to add encoding details to the classes, as we will se in the next sections where a mapping of model to XML / XML Schema serialisation is discussed. DATA ENCODING Each of the modelling rules presented in the previous section has a corresponding rule to map the feature governed by the modelling rule to a corresponding XML Schema concept. XML Schema as the main technology to structure the transfer syntax was chosen for two main reasons. Firstly, XML Schema is a powerful tool to model data in terms of structures and data types that allows automatic validation of exchange messages against the schema so that rich data definitions can not only be provided by the content provider but also be validated for every message received. But further to these technical advantages and probably even more important than that XML Schema provides another advantage by the fact that it is a widely supported standard that is supported by many software tools, be they open source or part of commercial off the shelf software (COTS). This platform specific mapping (of the platform independent UML model) to XML / XML Schema is summarised by the following specifications: All UML classes (entities, components and all abstract classes) are mapped to XML Schema complex typed definitions; 5

6 Only non abstract classes (i.e. concrete entity classes) are also mapped to XML Schema element declarations on highest level, so that these objects can be serialised and validated against the schema; XML Schema object referencing mechanisms are not supported, as all OTAP publications form a tree where object references can be implemented using object inclusion, i.e. the state of the parts are included in the state of the whole ; Attributes are also always mapped to XML elements; For compositions, aggregations and attributes, UML multiplicity is mapped to minoccurs / maxoccurs statements in XML Schema; Inheritance is mapped to the XML Schema type extension mechanism, adding the state of the derived class to the state of the base class; The name of XML Schema elements is determined by the attribute name (for UML attributes) or by the role name (for compositions/aggregations); The order of appearance of parts is determined by a tagged value in the UML model; String is mapped to xs:string. Decimal is mapped to xs:decimal; Enumerations are mapped to a XML Schema simple type using the xs:enumeration facet to specify the literals; Special types (derived either from String or Decimal) are mapped to XML Schema simple types; A valid XML serialisation of one sample object instance according to the example presented in the previous section could thus look like this: <DemoDerivedEntity> <key> <demoentitykeyattr1> </demoentitykeyattr1> </key> <democomponent> <compattr2> </compattr2> <compattr4> demoliteral2 </compattr4> </democomponent> <entityatt1> </entityatt1> <entityattr3> 22 </entityattr3> <entityattr4> demoliteral1 </entityattr4> <derivedentityattr5> demoliteral100 </derivedentityattr5> </DemoDerivedEntity> 6

7 DATA EXCHANGE The analysis phase for OTAP showed clearly that the point to point networking paradigm of the DATEX links was not a suitable approach for the 1:n relationship between content and service providers. It would be preferable, instead, to choose the widely used client / server paradigm, as is the de facto standard on the World Wide Web (WWW). Therefore, the data exchange protocol would be HTTP, with the current version (1.1) being specified in RFC2616 (6). The OTAP specifications do not derive from this standard, i.e. every valid OTAP data exchange is a valid HTTP response / request pattern. What the OTAP specifications do is to govern which HTTP options shall be used for which purpose in the OTAP context. The OTAP specifications governs the use of the following HTTP features: Use of the HTTP REQUEST / RESPONSE messages; Use of the If-Modified-Since and Last-Modified header fields; Use of content encoding to compress XML payload; Handling of response codes; Handling of authentication; Handling of cookies; Packaging if publications and associated metadata into so called information products ; The basic communication pattern is a simple client pull query, where the client issues a HTTP REQUEST (GET method) on the URL that represents the information product and the server responds with a corresponding HTTP RESPONSE method. The request has the access credentials as main parameters (plus additional optional headers). The response contains the XML serialised payload data. Supplier Client HTTPrequest(usr,passwd) HTTPresponse OTAP basic request /response pattern This basic pattern can be implemented on the server side in one of two possible ways. Option A is called the Application server solution. In this mode, the content provider operates an application server software package (e.g. Tomcat) that responds to HTTP requests by calling application code that accesses the content provider s database on the fly and generates the corresponding request by serialising the information product into XML while processing the request. This refined pattern is denoted in the following diagram. 7

8 TIC Backend Application Server Client InternalRequest HTTPrequest Query InternalResponse HTTPresponse HTTPrequest OTAP Application Server option The second option is to use a file based standard WWW server instead (e.g. Apache). In this mode, the server generates the information products periodically and uploads these pre packaged information as files to the webspace. The client s requests are handled by this software packages, providing the files without reaching back to the content provider s database. This option is less favourable in terms of information timeliness, but it may be preferable for organisations who s Internet access / security policy to not allow for option A. This solution named File server solution in OTAP is described in the following diagram. TIC Backend WWW Server Client Update UpdateFile HTTPrequest Update HTTPresponse UpdateFile Update HTTPrequest HTTPresponse UpdateFile OTAP File Server option 8

9 In both options, OTAP foresees various options to reduce redundant downloads, i.e. the client will not download an information product that contains only objects who s state is already known to the client. In the case that at least one object has changes its state, i.e. an update has been processed by the content provider, OTAP will always transfer the complete state of the information product, i.e. the current state of all valid situation elements. This regulation avoids the synchronisation problems well known for DATEX links. In case of large information products, the content compression option should be used to reduce bandwidth requirements. CONCLUSIONS This paper presents the technical approach taken for Open TIS Access Points (OTAP) in the Centrico project. The paper shows how the requirements for such an interface have been elaborated from the policy level in direct response to the EC recommendation 551 down to a technical solution that is based upon three well proven and widely used Internet technologies, namely UML, XML and HTTP. The solution will now be implemented by five major European road operators covering some of Europe s busiest roads as well as a wide range of private and public service providers, and the demonstrator will be evaluated in depth to elaborate on the technical and commercial value of this interface. REFERENCES (1) European Commission: Recommendation of 4 July 2001 on the development of a legal and business framework for participation of the private sector in deploying telematicsbased Traffic and Travel Information (TTI) services in Europe, 2001/551/EC, document C(2001) 1102), July 2001 (2) (3) (4) (5) (6) (7) 9