Project acronym: TraSer. Duration: 36 months. System Architecture

Transcription

1 Project acronym: Project title: Identity-Based Tracking and Web-Services for SMEs Start date of project: Sixth Framework Programme IST Call 5 Fp IST-5 ICT for Networked Businesses Priority 2 Specific Targeted Research Project Duration: 36 months System Architecture Document Date : 28 th of August 2007 Organisation and authors Abstract : RUG: Fred van Blommestein, TNO: Bram van der Waaij and Erik Langius HUT: Teppo Tossavainen SZTAKI: Marcell Szathmári : This document describes the system architecture: the components, their functions and the protocols of communication between the components. RUG: University of Groningen TNO: Netherlands Organization for Applied Scientific Research HUT: Helsinki University of Technology SZTAKI: Computer and Automation Research Institute, Hungarian Academy of Sciences

2 Table of Contents 1. Introduction Traser architectural overview rmation representation Registering events ing and reporting CACHING and BUFFERING interoperation with non-traser environments Confidentiality and transfer of information custody Standards future developments References INTRODUCTION In this document the architecture of the infrastructure (software and protocols) is elaborated. 2. TRASER ARCHITECTURAL OVERVIEW Storage Storage Figure 1. system A system consists of the following components: Items: Objects that carry a unique identification number Other objects Reading devices that can read Item Identifications s that allow users to register item related events with or without reading devices s that store item related events s that may query or subscribe to item related information 2

3 Objects may be tangible (a box) or intangible (a purchase order). Objects are of a certain type. Objects have properties. The Object type describes the kind of properties (Property Types). Properties are directed, tagged associations with other objects or with data types. Data types conform to the Data Type system of ISO (UN/CEFACT Core Components) [1]. Data types are represented in XML following the UN/CEFACT XML Naming and Design Rules 2.0 [2]. Items are Objects that have a unique, world wide identification number as a special property. Other properties are assigned to Items by means of Events. Events are registered by s or generated by s. s and s are roles of applications participating in the network. The identification of an Item consists of a URI and a number, unique within the scope of that URI. Identifications may be affixed to the item in the form of a machine readable label: a bar code, an RFID tag or otherwise. Is a Object Item Has Refers to Relates to Has Property or is represented by Event ID@URI Is a DataType Figure 2. Data model Basically, the identification has the format ID@URI. The representation may however differ per label or storage format. The ID and the URI may be stored as different data elements. The ID@URI is the key to information on the Item. The URI must be resolvable and must support defined protocols to store and retrieve that information. Reading devices read the identification of labels or tags of Items. They may also read or add other information and transmit that to the that is to register the recorded information as Event. For the communication between Labels or Tags and Reading devices, and between Reading Devices and s relies on standard protocols, such as ISO Events happen to Items. Events are of an Event Type. The Event Type describes the Properties that may be assigned by the Event to an Item. s upload Events that are recorded, with the Event Timestamp, the Event Type, the responsible organisation and any additional data on the Event as defined by its Type to the, identified by the URI. Events may be triggered by reading tags or labels, but may also happen apart from the Item, e.g. when an Item is sold. s store Item+Event related information. Events are stored, not changed or deleted during the time there information is needed. s may support a retention period, after which outdated information may be cleaned up. protocols do not support active deletion by s. Items are identified by their ID@URI and Events by their timestamp. That information may be retrieved by s, or it may actively be distributed to s that have subscribed to the information. Events may affect other Items as well. Based on rules to be stored on the, other events may be created and uploaded to the applicable servers, see chapter 4. It is at the discretion of the what Event Types it supports and stores per Item Type. s may also restrict the s they serve, but as the objective of 3

4 is to establish an open environment, s should be as tolerant as acceptable in their support to s. s may retrieve Item related information from s by querying them or by subscribing on periodic or event triggered reports. 1.0 allows only predefined queries with the restriction that an Item ID@URI always must be used as a key. Free queries and selection of items by other properties is foreseen in a later version. The concept allows traversing Item related graphs or lattices. Item Item Internet Figure 3. Overall configuration 3. INFORMATION REPRESENTATION Item related information is represented as XML structures in queries and reports. X as a query language allows to filter Event Types and Properties based on arbitrary criteria. limits the selection of Items to the knowledge of their ID@URIs. So it is possible to pose the query Give the colour of item 123@traser.org, but it is not possible to ask Give me the identification numbers of all blue items. In 1.0 queries are predefined. On the semantic web information elements are all regarded as Resources that have URIs. Even values of data types carry a URI. The information is represented as a graph or lattice. One may traverse such graph to retrieve the needed information. This principle resembles the principle in many aspects. Items all have ID@URIs and information can be retrieved by traversing the graph of Items that refer to each other by means of their properties. information is transferred as XML messages. XML has a hierarchical structure. The root of XML messages is an Item or a set of Items, identified by their ID@URI. The set contains all items that are related to an event or that are the response to a query. The structure basically lists the properties of the Items and the properties of other objects. When the property of an Item is another Item, the properties of the other Item are listed in a new tree. To illustrate the structure the following example is given. Note that the precise XML representation may be different in practise, only the overall structure is illustrated. 4

5 <update> <item type= rollcage id= > <event type= stuff id= > <weight unit= kg >5</weight> <location> <address>tracking Lane 1</address> <city>budapest</city> </location> <contains> <item id= /> <item id= /> <item id= /> </contains> </event> </item> <item type= box id= > <event type= pack id= > <weight unit= kg >1</weight> </event> </item> <item type= box id= > <event type= pack id= > <weight unit= kg >1.5</weight> </event> </item> <item type= box id= > <event type= pack id= > <weight unit= kg >2.5</weight> </event> </item> </update> In this example weight is represented by a data type and location is an object without an ID@URI. Properties of Items, contained in the rollcage are represented on top level. XML messages are constructed conform the UN/CEFACT Naming and Design Rules [2]. 4. REGISTERING EVENTS All events to be registered in a data store have the ID@URI of an Item and a timestamp as their key. Events may be triggered by the scanning of a barcode or the reading of an RFID tag, but may also happen when the Item is subject to some administrative or commercial transaction. Depending on the character of the Item and on the application area many kinds of different events may need to be defined. In the pilots a few will be used, related to the asset management and Supply chain control application areas. Examples may be Check out, Check in, Load, Unload, Store, Ship, etc. In the future Event Types will be stored in the UN/CEFACT Core Component Library. Each pre-defined event will have its data structure defined that will be represented as an XML schema. 5

6 An event on one item may trigger events on other items. If, for example, a roll cage is shipped, as a consequence all boxes inside the roll cage are shipped as well. There are two ways to handle such occasion: the status of the boxes may be updated or at query time they are calculated based on them being packed in the roll cage. supports both. Per application it is to be decided whether updates are propagated to related Items or not. The trade-off to be made is between update- and query efficiency. 6

7 Rule Base Item Item 2 1 Internet Figure 4. Propagated uploads 5. QUERYING AND REPORTING nodes may query a on information about Items. In 1.0 no generic query language will be supported, but the queries will be predefined, based on the application requirements. Queries will be expressed in the generic query language X. Responses will be formatted as XML messages conform UN/CEFACT Naming and Design Rules. processing may involve composing new or derived queries by the that are submitted to other servers. E.g. a query that is requesting the weight of the boxes that are contained in a roll cage may imply that the that holds information on the roll cage queries the servers that hold information about the boxes. Rule Base Roll Cage Box 1 2 Internet Figure 5. Propagated queries clients may also subscribe to Item information. rmation delivery may be event based or periodic. Key to subscriptions is always a ID@URI or a list of ID@URIs. 7

8 6. CACHING AND BUFFERING Due to technical limitations (e.g. the availability of an Internet connection) and performance reasons, upload propagation need not always to be performed directly after the original event was uploaded. At several places in the network uploads may temporarily be buffered: - in the transponder, until the transponder (that may have sensors for e.g. temperature) is read by a reading device - in the reading device, until an Internet connection is available to connect to an - in the, until performance allows propagation of the upload. When querying, it is indicated whether it is acceptable for the query client to receive not total up-to-date information. If information at all times need to be up-to-date, the server node, before answering the query, is to request other servers that are likely to produce updates to empty their buffer. These other servers are selected based on relations the item has with other items. E.g. if a box was stuffed in a roll cage, when querying the status of the box, the server of the roll cage is queried as well. Conversely, servers that have received information because of propagated queries may cache the results to improve performance. They may distribute cached information if allowed by the query client. By means of buffering and caching and the indication of service levels in the queries, a trade off can be established between performance and information accuracy and actuality. 8

9 7. INTEROPERATION WITH NON-TRASER ENVIRONMENTS As not all industrial users obey principles (yet), an Item identification scheme may be different from E.g. the identification may be represented as a Serial Shipping Container Code (SSCC) instead. In such case a translation must be made to the ID@URI. For such cases the architecture offers three options: - clients may store information on all non items in a default server with a fixed URI - Based on certain parameters (e.g. the SSCC prefix or the ISO allocation class), stored in local client settings, a URI may be chosen by the upload client - The upload client may access a look-up service, that responds with an URI based on the existing ID plus possible extra characteristics (such as the Item Type) will support protocols to use ID@URI look-up services. The URI stored in a client or looked-up through a service needs not be the final URI where the Item information is stored. The update and query traffic may further be redirected based on criteria at the node. Such redirection however should be invisible for the clients. Another special case is when multiple (but different) ID@URIs are affixed to the item, or when an Item label is replaced with one with a different ID@URI. This may be needed when the IDs are pre-allocated to or pre-printed on the label. In this case all URIs should ultimately point or redirect to the URI where the Item information is stored (see also chapter 6). 8. CONFIDENTIALITY AND TRANSFER OF INFORMATION CUSTODY Not everyone is entitled to upload or query information of Items. Each information category of each Item has an owner. The owner decides who may query and who may upload parts of the information belonging to that category. The concept is however based on an open environment and is jeopardised if upload restrictions are too strict. It should for instance not be necessary for a carrier to register with each of the information owners in order to scan the Items he carries. Item rmation ownership and rights Internet Figure 6. rmation Confidentiality 9

10 Updates of information ownership and user rights is registered as a special kind of events. Change of information ownership may imply that storage services are transferred to a new node. The new owner of the information is also responsible for rendering these services and he may decide to employ another service. It is also possible that the former owner is not authorised any longer to retrieve certain Item related information. Wholesalers for instance sometimes do not wish manufacturers to know who are the final customers. Yet the URI of the first information owner in the chain may be affixed to the Item as a barcode or in an RFID tag. therefore includes a redirect mechanism. In case information storage is transferred to a new server, a link will be established on the old server. rmation upload and retrieval is not performed directly, first the server is interrogated whether he still holds the applicable information. This mechanism is illustrated in figure 6. Principles are: The identity of clients and nodes should be verified by means of signatures and certificates The er is agnostic about information confidentiality requirements, the protocol must always be the same. URI transfers may be cached: the second upload or query is directed to the right node immediately The types of information should be coded (technical, logistic, usage) does not support: The case when downstream parties (e.g. customers) should not know the identity of the URI holder The case when manufacturers refuse to transfer ownership (or have bad or illegal intentions) 10

11 Manufacturer (URI1) Wholesaler (URI2) Retailer (URI3) Carrier I have transport related info on Product with ID 123@URI1 Send it to URI2 I have transport related info on Product with ID 123@URI1 Send it to URI3 I have transport related info on Product with ID 123@URI1 OK Product with ID 123 was on at X OK Figure 7. rmation ownership When some party in the chain drops out without redirecting its URI or without updating the redirects upstream, the chain is broken and information on the Item cannot be retrieved or updated any longer. This problem can not be resolved technically, but should be covered contractually. 9. STANDARDS The various architectural components conform to international standards: Data identification in barcoding (FACT Data Identifiers and GS1 Application Identifiers) Data identification in RFID (ISO 15961, 15962, 15963) ISO (Core Components) IETF RFC 2396 Uniform Resource Identifiers XML Schema X UN/CEFACT XML Naming and Design Rules UN/CEFACT Core Component Library UN/CEFACT Core Component Message Assembly 10. FUTURE DEVELOPMENTS In developments after 1.0 the following extensions to the architecture are foreseen: Free query formulation Dynamic updating of Item and Event types Queries on item information selected by other criteria than ID@URI Explicit support of mobile communication systems and geographical information systems 11

12 Reporting of history and statistics 11. REFERENCES [1] ISO (UN/CEFACT Core Components). [2] UN/CEFACT XML Naming and Design Rules