Implementing Internet of Things in the Swedish Railroad Sector

Evaluating Design Principles and Guidelines for E-Infrastructures

Authors: Mikael Berg Mattias Nordlindh

Tutor: Owen Eriksson

Department of Informatics and Media Uppsala University Sweden

Abstract The Swedish Transportation Administration started an initiative to create a new e-infrastructure for

the railroad sector in Sweden. The purpose is to follow the movement of railroad vehicles on the

railway tracks and enhance logistics aspects of the transportation of goods by train. The Swedish

initiative works as a pilot project for the railroad sector in the EU and if successful the e-

infrastructure could be rolled out in the entire EU. It is a rare opportunity to be a part from the

beginning of the creation of such a potential large scale e-infrastructure.

The aim of this thesis is to provide advice early in the development process to aid in the success of

the design and creation on the e-infrastructure. In the doing of this we will need to evaluate the

areas: (1) the current state of the e-infrastructure, (2) the usefulness of the EPCGlobal standard for

this e-infrastructure and (3) the usefulness on established e-infrastructures design principles.

As a result of the thesis we have provided advice to enhance the design and implementation of the e-

infrastructure, also advice is given on how to make the EPCGlobal standard’s more compatibility with

the transportation sector. We have found the design principles by Hanseth & Lyytinen (2004) and

Eriksson & Ågerfalk (2010) useful for the evaluation of the e-infrastructure. We also advocate that

new design principles should be created to encompass the new concept of Internet of Things in e-

infrastructures.

Keywords Internet of Things, e-infrastructure, design principles, electronic product code, EPC, Radio Frequency

Identification, RFID, identifiers

Table of Contents 1 Introduction ..................................................................................................................................... 1

1.1 Background .............................................................................................................................. 1

1.2 Aim........................................................................................................................................... 3

1.3 Outline ..................................................................................................................................... 3

2 Research Setting .............................................................................................................................. 4

2.1 Design and creation research .................................................................................................. 4

2.1.1 Research contribution ..................................................................................................... 4

2.1.2 Research process in Design and Creation Research ........................................................ 5

2.2 The Case Study ........................................................................................................................ 5

2.2.1 The “RFID proof of concept” ........................................................................................... 5

2.2.2 Benefits of developing the e-infrastructure .................................................................... 9

2.3 The research process ............................................................................................................. 10

2.3.1 Awareness ..................................................................................................................... 10

2.3.2 Evaluation ...................................................................................................................... 11

2.3.3 Suggestion ..................................................................................................................... 12

2.3.4 Conclusion ..................................................................................................................... 12

3 E-Infrastructure ............................................................................................................................. 13

3.1 The notion of e-infrastructure (EI) ........................................................................................ 13

3.2 Types of E-Infrastructures ..................................................................................................... 13

3.3 Design principles for e-Infrastructures .................................................................................. 14

3.3.1 Design principles that address the bootstrap problem ................................................. 14

3.3.2 Design principles that address the adaptability problem ............................................. 15

3.4 The importance of identifiers for e-infrastructure design .................................................... 15

3.5 The important distinction between things and institutional objects .................................... 15

3.6 Identifier Problems and Design Principles for identifiers ...................................................... 17

3.6.1 Identifier Problems ........................................................................................................ 17

3.6.2 Design principles for Identifiers in e-infrastructures ..................................................... 18

4 The Internet of Things ................................................................................................................... 20

4.1 EPCGlobal Architecture Framework ...................................................................................... 20

4.2 Tag Data Standard (TDS) ........................................................................................................ 21

4.2.1 Naming, addressing, and identifying resources (URN, URL and URI) ............................ 22

4.2.2 Electronic Product Code (EPC) ....................................................................................... 23

4.2.3 EPC Schema ................................................................................................................... 25

4.2.4 EPC Binary Coding Schema ............................................................................................ 28

4.3 EPC Information Services (EPCIS) .......................................................................................... 30

4.3.1 EPCIS Event Types .......................................................................................................... 30

4.3.2 EPCIS Vocabulary Types ................................................................................................. 32

4.3.3 EPCISEvent ..................................................................................................................... 34

4.3.4 ObjectEvent ................................................................................................................... 34

4.3.5 AggregationEvent .......................................................................................................... 35

4.3.6 Master Data ................................................................................................................... 36

4.3.7 Service Layer .................................................................................................................. 37

4.3.8 EPCIS Capture Interface ................................................................................................. 37

4.3.9 EPCIS Query Interfaces .................................................................................................. 37

5 Swedish transport administrations implementation of EPCIS ...................................................... 40

5.1 Tag Data Standard (TDS) ........................................................................................................ 40

5.1.1 The EPC used for railroad vehicles ................................................................................ 40

5.1.2 Location identifier ......................................................................................................... 40

5.2 EPC Information Services (EPCIS) .......................................................................................... 42

5.2.1 ObjectEvent ................................................................................................................... 42

5.2.2 AggregationEvent .......................................................................................................... 42

5.2.3 Master Data ................................................................................................................... 43

5.2.4 Services .......................................................................................................................... 43

5.3 Evaluation of the EPCIS implementation by the STA ............................................................ 44

5.3.1 Tag Data Standard (TDS) ................................................................................................ 44

5.3.2 EPC Information Services (EPCIS) .................................................................................. 44

6 European Centralized Virtual Vehicle Registry (EC VVR) ............................................................... 46

6.1 EC VVR e-infrastructure ......................................................................................................... 46

6.1.1 National Vehicle Registry (NVR) .................................................................................... 47

6.1.2 Virtual Vehicle Registry (VVR) ....................................................................................... 48

6.1.3 The user roles of the EC VVR framework ...................................................................... 48

6.1.4 National Vehicle Register data model ........................................................................... 50

6.1.5 Rules for registering vehicles ......................................................................................... 51

6.1.6 The registration process for vehicles............................................................................. 52

6.2 EC VVR in Sweden .................................................................................................................. 53

6.2.1 External Delivery Client (Swedish national naming service) ......................................... 53

6.2.2 Rules and processes of the registration of railway vehicles in Sweden ........................ 54

6.2.3 The information model of the Swedish NVR ................................................................. 54

6.2.4 Data model of the External Delivery Client XML response ........................................... 56

6.3 Evaluation of the EC VVR e-infrastructure ............................................................................ 57

6.3.1 Evaluation of the Swedish NVR ..................................................................................... 57

6.3.2 Evaluation of the vehicle registration process .............................................................. 57

6.3.3 Evaluation of the External Delivery Client ..................................................................... 57

6.3.4 EDC usage evaluation .................................................................................................... 58

6.4 Conclusion ............................................................................................................................. 59

7 Specifications for the Swedish railway sector e-infrastructure .................................................... 60

7.1 Requirements ........................................................................................................................ 60

7.2 Advice .................................................................................................................................... 61

8 Advice evaluation .......................................................................................................................... 64

8.1 Design identifiers based on information infrastructural aspects .......................................... 64

8.2 Select appropriate identifiers for important institutional objects ........................................ 64

8.3 Authorized institutional control systems for identifiers ....................................................... 65

8.4 Build upon existing installed bases........................................................................................ 65

8.5 Modularize the Information Infrastructure ........................................................................... 65

9 Conclusion ..................................................................................................................................... 67

10 Further Research ........................................................................................................................... 69

Table of Figures ..................................................................................................................................... 70

References ............................................................................................................................................. 71

Appendix A – Standard form for registration ........................................................................................ 73

1

1 Introduction In an even faster changing environment the demands on railroad logistics and transportation gets

increasingly higher, and to be able to keep the railroad as a competitive alternative for logistics and

transportation the possibility for improvements constantly has to be evaluated. One possible mean

to achieve better effectiveness in the railroad sector is to implement Internet of Things (IoT) for

tracking and detection of railroad vehicles (railroad cars and engines) and train compositions (a set of

railroad vehicles).

1.1 Background During 2007-2008 the Swedish Rail Administration (The SRA or “Banverket”), started a number of

RFID-projects (Radio Frequency Identifier), which is one of the technologies that could be used to

implement the Internet of Things, in cooperation with the industry. The projects were launched in

four different regions and active or semi-active RFID-tags where used.

The regions where:

Luleå – Narvik

Piteå – Umeå

Luleå – Borlänge

Stockholm (commuter trains in the metro area)

The SRA installed a number of RFID readers in these regions and the companies (the keepers) that

operated trains on these parts of the railroad tagged their railroad vehicles with RFID-tags. The

information that was captured with the readers was sent to a number of applications both at the

SRA, the operators (keepers) of the railroad vehicles, and companies that transported goods on these

vehicles. The aim of these projects was to investigate if an automatic identification system of railroad

vehicles was useful in order to make the logistics for these companies more efficient, and if such a

system would be useful for the SRA in their work to maintain, survey and direct the railroad traffic.

These pilots proved that the RFID-technology worked and the companies and the SRA were very

pleased with the results they got using the technology. However, the real usefulness of the RFID-

technology would be gained if these pilots could be scaled up so that most of the railroad vehicles

would be tagged, and that readers could be installed covering the whole railroad network making it a

true e-infrastructure for automatic railroad vehicle detection. Such an e-infrastructure could be used

for proactive vehicle maintenance systems, track and trace systems, intermodal transport, efficient

shunting of freight vehicles, acquiring correct information about train compositions, reduced

environmental impact, etc.

In 2007 the SRA also realized that it was important that the information from the readings of the

RFID-tags could be integrated with the European Centralized Virtual Vehicle Register (EC VVR). The

EC VVR is a decentralized solution for tracking, storing and updating information about railroad

vehicles in the EU. The EC VVR consists of the National Vehicle Registers (NVR’s), and the Virtual

Vehicle Registry (VVR) which is the service that all NVR’s should connect to. Each Member State in

the European Community is responsible for implementing the NVR’s. In Sweden it is the Swedish

Transport Agency/NSA (National Security Agency) which is responsible for the implementation of the

NVR in Sweden, and from 2010 there is an operational NVR in Sweden and the NSA has developed a

2

service that can be used for retrieving information about a vehicle if the standardized European

Vehicle Number is provided as a parameter to the service.

However, one problem that had to be solved in order make this a true e-infrastructure for the

Internet of things was that it had to encompass vehicles operated by train operators (keepers) in the

whole of Europe, because 60-70 % of the railroad wagons in Sweden have keepers or owners from

other European countries. This led to the conclusion that in order to be able to implement a RFID-

based e-infrastructure for railroad vehicles, European standards had to be used. This should

encompass both standards for, (1) RFID-tags and the reading of these tags, (2) the information

exchange of these readings, and (3) the master data that provides the bulk of information about

these readings.

As a consequence the SRA started a feasibility study in 2009 to decide how this standardization effort

should be carried out. One suggestion from the feasibility study was that passive tags and the air

transfer protocol “ISO 18000-6 type C / UHF gen 2 class 1” should be used. This is a standard for

RFID-tags and the reading of these tags. The “ISO 18000-6 type C / UHF gen 2 class 1” protocol

regulates the air interface, which is used for transmitting the data from the RFID-tags on the railroad

vehicles to the reader which is placed at the side of the track. This protocol is based on passive tags

and allows the tag to be read at speeds up to 200 km/h. Passive tags were chosen for maintenance

reasons because they do not require any battery support, which is a necessity for semi-active and

active tags. Another result was that SRA decided to use the GS1 EPGlobal framework (see section 4.1)

for the information exchange of the readers.

A result of the feasibility study was also that the SRA was able to upgrade the TSI (Technical

Specifications for Interoperability), which regulates the interoperability of IT capabilities in the

Railway Sector in Europe, to prescribe that the ISO 18000-6 type C / UHF gen 2 class 1 protocol

should be used. Based on the results from the feasibility study a number of new projects started in

2009 and 2010 to test the technology and the standards that they had decided on.

At the 1:st of April 2010 the Swedish Rail Administration and Swedish Road Administration

(“Vägverket”) formed the Swedish Transport Administration (STA). The STA is the agency responsible

for all modes of traffic: on roads, on railways, on the sea and in flight. The STA is responsible for the

longtime planning of the national infrastructure, and for building, maintaining and operating of all

national roads and railway. In this thesis we will only focus on the railroad traffic. The responsibility

to provide effective IT support for the transport sector is an area that have been increasingly

important during the last decade for both the Swedish Rail Administration Swedish Road

Administration now forming the new STA.

The RFID-project in Sweden is an example of an information infrastructure (e-infrastructure) project,

and government agencies have sometimes played a key role for the development of e-

infrastructures. E-infrastructures (Edwards et al., 2009) typically form only when various applications

merge allowing dissimilar applications to be linked into networks. Scaling up is a central element in e-

infrastructure development to quote Edwards et al. (2004, p. 9) “Systems that worked well in a small

local area, with a few hundred users, typically require substantial redesign in order to function in

many places with thousands or millions of users.” However, the knowledge how to accomplish this is

still limited.

3

1.2 Aim The development of the RFID-infrastructure in Sweden provides a unique opportunity to study how

an e-infrastructure for the Internet of Things evolves and what design decisions that have to be made

in order to accomplish this task. The aim with the thesis is to:

evaluate the implemented e-infrastructure and the usability of the chosen standards

evaluate design principles for e-infrastructure development and their usability

give advice on how to further develop the RFID-based e-infrastructure in for railroad

vehicles in Sweden

provide design principles and guidelines on how to implement e-infrastructures

1.3 Outline The first chapter of the thesis gives an introduction and a background to the thesis work. Chapter

two describes the chosen research approach, the case study and the research process. Chapter three

describe the notion of e-infrastructure and the theoretical framework used in the thesis. In chapter 4

the notion of the Internet of Things (IoT) and especially the EPCGlobal Framework is described.

Chapter five describes and evaluates the implementation of the EPCGlobal Framework by the

Swedish Transport Administration. Chapter six describes and evaluates the implementation of the EC

VVR framework by the NSA in Sweden. Chapter seven presents advice for how the RFID e-

infrastructure should be developed and finally chapter 8 summaries the research contribution and

suggests topics for further research.

4

2 Research Setting In this chapter we will describe the research approach, the case study that we have performed and

the research process. Based on the aim of our research we have chosen a design and creation

research strategy. Furthermore development of e-infrastructures has to be studied in real life and its

development must be studied over time. This means that the design approach must be combined

with a case study.

2.1 Design and creation research

2.1.1 Research contribution

The Design and Creation Research Strategy is usually used to present a construct, model, method or

instantiation as a knowledge contribution. (Oates, 2010)

Constructs: The concepts or vocabulary used in a particular IT-related domain. For example,

the notion of entities, object or data flows.

Models: Represent a situation and is a combination of constructs used for better

understanding of problems and solution development. For example DFD (Data Flow Diagram)

or a Use Case.

Methods (or Methodologies): Process stages to be followed to solve problems using IT. It

also includes guidance on models. Formal mathematical algorithms, commercialized

methodologies and in-house procedure manuals and informal description of practices are

also included.

Instantiation: An instance of a working system that demonstrates that constructs, models,

methods works in an IS (Information System).

For conducting Design and Creation research in the IS-field it is crucial that the project should

demonstrate not only technical skill but academic qualities such as analysis, explanation and critical

evaluation. It must also contribute to general knowledge or knowledge base in the subject field.

Examples of research projects where the main focus is the IS (an instantiation) and where the IS

contributes to the knowledge base are:

When an IT-application is used in a new domain, where it previously hasn’t been used.

The researcher has to argue for why using the system in this new context and the IS

developed has to support the arguments.

IT-application that incorporates a theory from another discipline that’s new to

computing. For example: an educational theory used in the context of developing an IT-

application for computer-aided learning. In this case it’s up to the researcher to argue for

the relevance and applicability of this theory in this new context. The relevance of the

theory has to be argued by the researcher and it has to be shown that the theory can be

incorporated into a computer-based system.

There is also the case where the IT-application is the vehicle for something else:

An IT application is developed, but the contribution to knowledge is based on what

happens next, for example, the IT-application for computer-aided learning is developed,

5

but the primary focus of the research is on how the students and teacher then use and

adapt it in the classroom.

Another example of conducting design and creation research is when the IT application is a tangible

end product, but the focus is on the development process.

2.1.2 Research process in Design and Creation Research

The research process in design and creation research can be described by these five steps;

Awareness, Suggestion, Development, Evaluation and Conclusion. (Oates, 2010)

Awareness is the recognition and articulation of a problem, which can come from

studying the literature where authors identify areas for further research, or reading

about new findings in another discipline, or from practitioners or clients expressing the

need for something, or from field research or from new development technology.

Suggestion involves a creative leap from curiosity about the problem to offering a very

tentative idea of how the problem might be addressed.

Development is where the tentative design idea is implemented. How this is done

depends on the kind of IT artifact begin proposed. For example an algorithm might need

the construction of a formal proof. A systems development method will need to be

captured in a manual that can then be followed in a system development project. A new

user interface embodying novel theories about human cognition will require software

development.

Evaluation examines the developed artifact and looks for an assessment of its worth

and deviation from expectations.

Conclusion is where the results from the design process are consolidated and written

up, and the knowledge gained is identified, together with any loose ends – unexpected

or anomalous results that cannot yet be explained and could be the subject of further

research.

How we have performed these steps in our thesis work is described in more detail in section 2.3.

In design and creation research some kind of data generation and analyses methods needs to be

used. The methods that are common are: interviews, observations, questionnaires and study of

literature and documents. Questionnaires and interviews are often used to get information from

domain-experts about the domain and the context the IT-artifact is going to be use in. The methods

we have used are described in more detail in section 2.3.

2.2 The Case Study To study the development of an e-infrastructures based on RFID-technology implementing the Internet of Things in the railway sector we have conducted a case study in the railway sector.

2.2.1 The “RFID proof of concept”

In the introduction we described how the STA started a number of projects in order to test the

standards and technologies they had decided on. These “Proof of concepts” were tested in four

projects:

1. One project was performed at the railroad between Stockholm – Göteborg where a post

train with 9 railroad cars that travelled at a maximum speed of 160 km/h was RFID-tagged.

6

2. In a second project 30 engines of a high-speed train at the railroad Stockholm – Göteborg was tagged.

3. In a third project container cars were tagged at the railway between Falköping – Göteborg and this was project was a part of the EU financed “Dry Port project”.

4. A fourth project was performed in cooperation with Volvo, which tagged 210 container cars that transport car parts at the railroad between Olofström-Göteborg.

These projects used passive tags and the air interface was UHF gen 2 class 1 / ISO18000-6 type C.

RFID-tags where delivered from Scirocco, Siemens, Confidex and OmniID.

RFID-readers

Figure 1 -RFID-reader and Axle counter/wheel sensor

The readers that read the tags are placed approximately 3 meters beside the railway. Only one reader is used, which means that the railroad vehicle has to be tagged on both sides (see Figure 2 below) in order to be captured by the reader. The reader is also combined with axle counters, which are sensors that can count how many axes there are on the physical train that passes the read point. This means that combining the information from the readers and the axis counters the number of rail road vehicles on a physical train can be counted and the number of railroad cars of the physical train that do not have RFID-tags can be counted.

7

Tag position on wagons as specified in the European Commission’s decision 2006/861/EU of 28th July

2006. This has to be standardized for the ability to read RFID tags from all vehicles registered in the

EU.

Figure 2 - RFID tag position on wagon

Structure of tag information The structure of the information of the tags follows the GS1 EPCGlobal standard EPC GIAI 96 (see

chapter 4). The GIAI 96 number is composed by a company prefix that is a unique number provided

by GS1, and each organization that gets a company prefix is responsible for assigning a unique GIAI

asset number. This implies that the combination of the company-prefix and GIAI number is unique

worldwide. For the RFID-tags put on the railroad vehicles in Sweden the standardized European

Vehicle Number (EVN) is used as the GIAI, with an additional digit 1 or 2 at the beginning of the

number. This additional digit is a necessity because there have to be two tags, one on each side, on

each railroad vehicle, because the information in the tag have to be captured no matter which side of

the vehicle that is turned to the reader.

Figure 3 - Structure of RFID-tag

8

Figure 4: Structure of the data exchange in the RFID system in the STA

The information captured by the readers is exchanged using the EPC Information Services (EPCIS).

This is an EPCglobal standard designed to enable EPC-related data sharing within and across

enterprises. The information flows from the tags on the train to the Middleware via the readers. The

Middleware create an EPCIS-message that reports the passage of a physical train where the vehicles

that carries a RFID-tag are identified, the message is then forwarded to Fosstrak which stores the

message in the database.

Fosstrak Fosstrak is an open source software platform that implements the EPCGlobal standards. It supports

application developers and integrators by providing the core software components of the EPCGlobal

standards. (Fosstrak, RFID Software platform). The Fosstrak database that stores the EPCIS messages

can be accessed both internal and external users directly via a web interface or by system-to-system

services.

External user can access the information from Fosstrak; either by posting a request or by

subscription. If the user subscribes to a certain type of information, the system will forward the

information to all subscribers.

Internal system such as Opera can be update with information from the RFID- system. Opera is a

system where all train-compositions that are scheduled to run on the Swedish railway are registered.

Railway companies are obliged to report the train-composition before a train’s departure.

9

Figure 5: Structure of data exchange for vehicle identification

The only railroad vehicle information that is contained in the EPCIS Train Message is the EVN, thus in

order to get information about the vehicle the NVR’s have to be searched using a system-to-system

VVR-service. The idea is that the VVR should do a distributed search in all the registers that are

connected to the EC VVR-infrastructure. However this functionality is not yet implemented. Today

there is only one system-to-system implemented and it works with the Swedish VVR.

2.2.2 Benefits of developing the e-infrastructure

The reason why the STA is developing the e-infrastructure for the RFID-identification of railroad

vehicles is that such a system can be beneficial for the whole railroad sector. One main use of a RFID-

system is to combine measuring values from non-RFID wayside monitoring detectors e.g. hot box/hot

wheel detectors, with the correct railway wagon.

Figure 6 - Non RFID Wayside Monitoring System/Detectors

10

The information from the hotbox wheel detector, and other detector systems, could be combined

with the information from the RFID-system giving information about which railroad vehicle that has

problems and/or needs maintenance. This type of information can be very valuable for a number of

stakeholders in the railway sector.

One of the problems for the owner of the infrastructure is that it is usually hard to know who’s

responsible for the specific railroad vehicle that causes damage to the infrastructure. The RFID-

/EPCIS-system give traceability so that the owner or keeper can be held responsible.

Railway companies - There are a lot of possible benefits for railroad companies. To get real-time

information that makes planning easier and maintenance more efficient by utilizing the information

in their maintenance scheme.

Customers of cargo transports - The complete supply-chain can be more automated with the use of

this this information.

Passengers - The passenger can get more reliable real-time information about trains.

All these measures will lead to more efficient railroad and transport system in which in the end will

lead to sustainable transport of people and/or goods.

2.3 The research process We have used a design and creation research approach combined with a case study in the thesis

work, and in this chapter we are going to describe the research process. We have performed the

following steps in the research process: awareness, evaluation, suggestions and conclusions. In these

steps we have used different method for data generation and analyses methods. We have also

conducted development however the development efforts have had the purpose to learn more

about how the e-infrastructure has been implemented and should primarily be seen as a part of the

awareness step. How these steps have been performed in a sequential below, however in reality

these steps have not been followed in a step-wise fashion. They have been performed in an iterative

way where each iteration have refined the end result.

2.3.1 Awareness

During this step we conducted interviews with domain-experts from STA, NSA and GS1. We also had

meetings with STA & NSA. One of the problems was that there was no single domain-expert, all

where experts in their own field but no one knew the whole picture.

We had two physical meetings with the Swedish Transport Administration (STA) & the National

Security Agency (NSA) in Borlänge, Sweden where both STA and NSA where represent. After

analyzing the information from that meeting we conducted phone interviews with representatives

from STA, NSA and GS1.

11

Phone interviews Jeremy Morton, Responsible for the Global Electronic Party Information Registry at GS1 –

Contacted Once

Alice Mukaru, RFID/EPC Expert at GS1 – Contacted Once

Carina Larsson, HR Director at NSA – Contacted Twice

Lennart Andersson, Chief of architecture at STA – Contacted Once

Mattias Turesson, Developer at STA – Contacted Once

Peter Larses, Developer STA – Contacted Once

Mail conversations Mattias Turesson, Developer STA

Peter Larses, Developer STA

Carina Larsson, HR Director at NSA

In this step we also studied a number of powerpoint presentations that the STA had made to

describe how they had implemented the e-infrastructure. A number of standard documents that

described the EPCGlobal Framwork and the EC VVR were also studied.

We also used the development of a gateway (see figure 6) that use the EPC train messages as input

and the VVR service developed by the NSA to search for information in the Swedish NVR. The

gateway uses the EVN from the EPC train message and makes a lookup in the Swedish NVR. In this

development process we had also to examine different kind of systems documentation, XML-files

and XML-schemas. During this development process we ran into different kind of questions and

problems that had to be answered and resolved, which triggered the need for interviews and mail

conversations.

2.3.2 Evaluation

The focus in this step was to evaluate the implemented e-infrastructure and the usability of the

chosen standards. In this step we evaluated the implemented e-infrastructure in relationship to the

two standardization frameworks, EPCGlobal and EC VVR.

The first activity was to analyze and describe the EPCGlobal framework (see chapter 4). In this activity

we made a selection from the standardization documents and presented what was of interest. We

then analyzed how the STA had used the framework to implement the e-infrastructure (this is

presented in sections 5.1-5.2) and after that an evaluation of this part of the e-infrastructure has

been performed (this is presented in section 5.3). This implies that the evaluation in section 5.3 is a

criterion-based evaluation where the EPCGlobal framework described in chapter 4 provides the norm

for the evaluation. But the evaluation was also based on the qualities of the used FTP service that

was used as input to developed gateway.

The second activity was to analyse and describe the EC VVR framework (see sections 6.1). In this

activity we made a selection from the standardization documents and presented what was of

interest. We then analysed how the NSA has implemented the EC VVR framework in Sweden, this is

described in section 6.2. We also made an evaluation of the implementation of the EC VVR in Sweden

(see section 6.3). This implies that the evaluation in section 6.3 is based on EC VVR framework

described in section 6.3, which provides the norm for the evaluation. But the evaluation was also

based on the qualities of the used system-to-system service provided by the NSA.

12

The third activity was to evaluate design principles for e-infrastructure development Hanseth &

Lyytinen (2010) and Eriksson & Ågerfalk (2010) (see chapter 3) and their applicability in the design of

e-infrastructure in the case study. This is presented in section 7.2.

The third and final step was the evaluation of the EC VVR. The EC VVR is evaluated by studying the

standards and statues that specified the EC VVR especially EC Decision (2011/107/EU) amending

Decision 2007/756/EC “adopting a common specification of the national vehicle register”

2.3.3 Suggestion

The aim with the suggestion step is to provide advice for how to answer questions and solve

problems. Our suggestions to the STA and NSA how to proceed with the development of the e-

infrastructure development are based on the evaluation step. We have also based our suggestions on

design principles on design principles for e-infrastructure design this is presented in section 7.1.

2.3.4 Conclusion

We have concluded our work by identifying the knowledge gained in our thesis work. This knowledge is concerns the usability of the design principles for e-infrastructure, but we also provide knowledge of how these design principles must be further developed in order to make them useful for the development of the Internet of Things. This is presented in chapter 8.

13

3 E-Infrastructure This chapter emphasize on the difference between traditional IS development and e-infrastructure

development. The first part introduces both the notion of e-infrastructure and design principles for

e-infrastructure development. The second part shows the distinction between things and

institutional objects and introduces identifiers and the importance of design of such identifiers in IS.

The design principles, both for e-infrastructures and identifiers, is used in the analysis and evaluation

of the case study described in the previous chapter.

3.1 The notion of e-infrastructure (EI) Hanseth and Lyytinen (2010) define an e-Infrastructure or Information Infrastructure as: “a shared,

evolving, heterogeneous installed base of IT capabilities among a set of user communities based

on open and/or standardized interfaces”. E-infrastructure differs from traditional Information

Systems (IS) in the way that a IS is seen as an application (a user tool) with a clear purpose to serve a

specific organizational goal. E-infrastructure on the other hand doesn’t have a clear purpose other

than a general idea of offering information related services. The general idea with an e-infrastructure

(EI) is to make information accessible over organizational boundaries. (Hanseth & Lyttinen, 2004)

E-Infrastructures are developed over time and don’t have any clear defined boundaries, which have

implications on how the evolution of the EI unfolds and what strategies are suitable for the design of

the EI. If something is changed or added to the EI each version has to be compatible with the as-is

infrastructure (the installed base). (Hanseth & Lyttinen, 2004)

Two critical features of EI’s are that they must be open and that they must be based on some type of

shared standards in order to promote continuous growth and evolution of the E-Infrastructure

(Hanseth & Lyttinen, 2004). Standards form a constitutive part of infrastructure design, and

standards can be defined as general agreements between producers and users of technology

(Hanseth & Lyytinen, 2010).

3.2 Types of E-Infrastructures Infrastructure can be designed in different ways and one strategy is to decompose complex

infrastructure into more basic ones, which only have one type of functionality. Layering is one way of

decomposing infrastructures, and using the layering principle two types of horizontal e-

infrastructures could be identified; application infrastructures and support infrastructures. (Hanseth

& Lyttinen, 2004, pp. 217-218)

A supporting infrastructure offers data transportation, access and security services, and the typical

example is the internet. The support infrastructure could further be split into a transport and service

infrastructure. An example of a transport infrastructure is the TCP/IP protocol that is the transport

infrastructure of the Internet, another example is the SOAP protocol for exchanging XML based Web

service messages between a web service and a client. Service infrastructures provide necessary

support for addressing, identification and service property discovery. An example of a service

infrastructure is the Domain Name Service (DNS) on the Internet, which is used to resolve IP

addresses from textual representations (like www.google.com). This means that an application

infrastructure is always built on top of a support infrastructure. An application infrastructure enables

collaborative information sharing among larger business communities. (Hanseth & Lyttinen, 2004,

pp. 216-218)

14

Figure 7: The structure of infrastructure (Hanseth & Lyttinen, 2004, p. 218)

3.3 Design principles for e-Infrastructures Development of IS is traditional conducted by setting up fixed goal such as effectiveness or user

satisfaction. This approach doesn’t work for infrastructure development because of the complexity of

the infrastructure and the developer’s lack of control over the goals. Another thing that differs EI

development from IS development is that you always have to consider the installed base when

developing infrastructures. (Hanseth & Lyttinen, 2004). Hanseth & Lyytinen (2010) formulates five

design principles for promoting EI growth where the notion of the installed base is focused (Hanseth

& Lyttinen, 2004, pp. 222-225). The theory of Hanseth and Lyytinen (2010) is useful for

understanding “the bootstrap problem” i.e. how e-infrastructures directly need to meet users’

requirements in order to be initiated; and “the adaptability problem” i.e. how local designs need to

adapt to the unbounded scale and uncertainty of the design.

3.3.1 Design principles that address the bootstrap problem

Design initially for direct usefulness – Users must be attracted for other reasons then the size of the

already installed base and therefore a small group of potential first users need to be identified and

the first version of the infrastructure has to offer the group immediate benefits.

Build upon existing installed bases – Utilize existing infrastructures as much as possible in the

creation of the infrastructure. Service infrastructures should be implemented, expanded and

enhanced incrementally when the infrastructure grows and those additional services become

necessary.

Expand installed base by persuasive tactics to gain momentum – Emphasis one getting as many

users as possibly involved in the infrastructure instead of adding functionality. An infrastructure will

primarily get its value from the size of its user base and not from the amount of functionality.

15

3.3.2 Design principles that address the adaptability problem

Make the IT capability as simple as possible – Make each IT element in the infrastructure as simple

as possible.

Modularize the Information Infrastructure – Modularize the infrastructure by building the key

functions separately. Use techniques as layering, gateways and standards as a mean of separation of

concerns and simplify future evolutionary decisions.

3.4 The importance of identifiers for e-infrastructure design Identifiers, which are used for uniquely referring to, or identifying, objects such as telephone

numbers, license numbers, and personal identification (PID) numbers, play a major role e-

infrastructures (Eriksson and Ågerfalk, 2010). According to Hanseth and Lyytinen (2010) registers of

identifiers must be available to all e-infrastructure users and they must be common to avoid mistakes

and errors. This requires building an additional infrastructure to maintain and distribute updated

versions of each register and a social and institutional process to control them. According to Hanseth

and Lyytinen (2004) identifiers and registers of identifiers constitute the naming infrastructure, which

is an important part of the overall EI. Identifiers are used for uniquely refer or identify an object.

Traditionally in IS development selection and design of identifiers have primarily been considered as

a technical problem, for example choosing a unique, stable and compact primary key in a relational

database. (Eriksson & Ågerfalk, 2010, p. 434). According to Eriksson and Ågerfalk (2010) must

identifiers be analysed as language constructs.

3.5 The important distinction between things and institutional objects In order to understand the role and function of identifiers for e-infrastructures it is important to

understand the distinction between what Searle (1995, p. 27) terms “brute facts” and “institutional

facts”. Essentially, the difference between the two is that:

Brute facts concern physical things and their properties and only require the institution of language

in order that the facts can be asserted; for example, the assertion “The black and blue engine weighs

50 tons”.

Institutional facts, on the other hand, require human institutions and language for their very

existence. Something or someone can be money, a resident, or a railroad vehicle only insofar as it is

represented as such in an inter-subjectively agreed upon manner.

Institutional objects, their attributes and relationships, are examples of institutional facts. One way

of creating institutional objects is by using explicit declarative (regulative) language acts, which can

be performed by the use of information systems. For example, a representative of The National

Security Agency in Sweden may register the European railroad vehicle with the European Vehicle

Number number (EVN) 917410613520 in the Swedish National Vehicle Registry.

16

The Swedish National Registry for Railroad Vehicles

Figure 8: Relationship between institutional objects and physical things

In this case the language act requires that there exists a physical thing with certain properties that

makes it meaningful to instantiate the object 917410613520 in the registry. However the creation of

institutional objects does not always require that a physical thing exists. For example, a corporation

can come into existence, but there need be no physical thing that is the corporation. Instead the

decisive requirement is that there has to be some obligations, commitments, rights or duties, which

can be declared and collectively recognized as an organization (Searle, 2006, p. 28; Habermas, 1988

p. 273-274).

A fundamental insight of speech act theory is thus that language constructs are used not only to

describe reality as it is. Using language also implies constructing social reality (Searle, 1995), and

institutional objects, which is used for regulating social relationships.

According to Searle (1969), there are two ways to identify objects using language (there are two

reference mechanisms); using a definite description (such as, the black and blue engine) or an

identifier (such as, 917410613520). This does not mean that an identifier is the same as a definite

description, as assumed by the representational view of information systems. In fact, trying to

present a definite description based on a set of identifying properties of a thing as the identity of the

object would lead to the peculiar consequence that the meaning of the identifier would change if

there were any change at all in the properties of the thing (Searle 1969). This means that the two

expressions “The black and blue engine” and “917410613520” only pick out the same object in a

specific use situation, for example, as long as the engine is black and blue.

17

If they had exactly the same meaning, then the identifier would have a different meaning depending

on how the attributes in the definite description changed over time. Thus it would not fulfil its

referential function, i.e. to represent the existence of the object and the thing over time. It would

also imply that we would only be able to refer to an object by describing it. But this is precisely what

the identifier construct avoids and which makes it a very practical construct (Searle 1969, p. 172)

It is true that in the case where the object also represents the existence of a physical thing the

identifier has to be connected to attributes that represent properties of the physical thing. This is

because we must be able to substitute the identifier for an identifying description in certain contexts

of use. For example, if someone asks you which railroad vehicle is “917410613520)”, assuming that

they cannot see the EVN number, you could answer, “The black and blue engine”. In that sense the

identifier has a semantic meaning, but the function of the identifier is not to represent identifying

properties. The identifier does not represent properties of a thing, it represents the existence of an

object. The EVN-number painted on the physical thing, should not be considered as a property in the

same sense as the physical features of the engine or the colour of the thing, these are brute facts. An

identifier can only be an identifier by virtue of a genuine difference between the identifier and the

thing identified: “If they are the same, the notion of naming and referring can have no application.”

(Searle 1969, p.75).

3.6 Identifier Problems and Design Principles for identifiers There are many examples that point to the significance of identifiers for e-infrastructures, including

the naming infrastructure of the Internet and the European Article Number (EAN). However, the

identifiers and registers that constitute the naming infrastructure often prove hard to design and

difficult to maintain.

3.6.1 Identifier Problems

Eriksson and Ågerfalk (2010) has identified three general problems associated with identifiers, these

are referred to as (1) The Descriptive Identifier Problem, (2) The Identifier Selection Problem, and (3)

The Identifier Control Problem.

The Descriptive Identifier Problem

To embed descriptive information in identifiers brings forth two major problems. First when changing the descriptive attributes that are included in the identifier, the identifier itself need to change too keep it semantic correct. To change an identifier for an object is problematic and should be avoided, therefore such information that could change shouldn’t be embedded in identifiers. (Eriksson & Ågerfalk, 2010, pp. 444-447)

Secondly an identifier with embedded descriptive information gets a reduced range of valid identifiers, this is a problem when the need of identifiers outgrows the range of the identifier.

The Identifier Selection Problem

The identifier selection problem concerns the choice of the right identifier to the institutional object.

The choice of identifier should be based on the identifiers’ institutional meaning.

18

The Identifier Control Problem

The identifier control problem concerns the lack of institutional control of the identifiers. For

identifiers to be stable there is a need for institutional control over them. The identifiers need to be

established at an institutional level and often this involve some political complexity. There is a need

for a standardized and authorized system for the assignment and control of identifiers for enabling

efficient exchange of information between information systems, organizations and society at large.

(Eriksson & Ågerfalk, 2010, pp. 448-449)

3.6.2 Design principles for Identifiers in e-infrastructures

Based on the three problems Eriksson & Ågerfalk (2010) have suggested three general design principles for identifiers:

1. Design identifiers based on technical, usage, institutional and information infrastructural aspects.

Eriksson & Ågerfalk presents six design principles for identifiers to avoid the descriptive identifier problem. First of all, an identifier must fulfill the basic criteria to be able to represent the existence of all the institutional objects it is intended to represent. There are also a number of further criteria (see below) that have to be considered, and these criteria have to be balanced when the identifier is designed:

The identifier should be stable, which means that neither its structure nor its value should have to be changed after it has been assigned to the institutional object.

If manual use of the identifier is extensive, it should include a check-digit.

If the identifier is visible to users either on-screen or through other media, consider giving it a pattern. If a pattern is used, embed minimal descriptive information. Information embedded in the identifier should not be used as attribute values by database administrators and programmers; for example, although date of birth is included in the Swedish PID number, the date of birth should be stored as a separate field in the database, which should be used to determine the exact date of birth.

If users have to learn and remember the identifier, consider making it mnemonic. This could be done by using a non-descriptive name, making the identifier as short as possible, or giving it a pattern (as shown above).

If the identifier is used extensively to exchange information between different IT systems, departments, and organizations and in society at large, consider giving it a pattern. If it is important, it has to be recognizable. Giving the identifier a pattern is also a way of assigning its uniqueness; for example, include the code of the issuing authority in the identifier.

The design of the identifier is also affected by technical concerns. It should be possible to build effective indices on the identifier field, and the identifier should preferably be represented by one column in the database.

In a redesign situation, the implications for the installed base have to be considered and a transition strategy should be developed, which will likely affect the new design.

2. Choose the appropriate identifier or identifiers for important institutional objects and not

to overuse identifiers that seem interchangeable.

This design principle is focused on the important matter of choosing the right identifier to the

institutional object when there is a choice. Such important choices should be based on analyses of

the institutional context, or domain, for which the identifier was originally designed. This is required

19

in order to recognize the institutional objects that the identifiers represent and the constitutive rules

that govern their existence and validity; that is, to understand the identifiers’ institutional meaning.

3. Develop a standardized specification and an authorized institutional control system that

can be used for the creation, maintenance, and verification of identifiers

Identifiers have to be established at an institutional level and often involve a great deal of political

complexity. This means that a standardized and authorized system for the assignment and control of

identifiers is a basic condition for the efficient exchange of information between information

systems, organizations, and society at large.

20

4 The Internet of Things The growth of the Internet has been an ongoing process over the last couple of decades now

connection over a billion people through computers and mobile devices all around the world. The

Internet is now evolving from just being a network of interconnected computers to a network of

interconnected things, from books to cars, from electrical appliances to food and thus creating

the Internet of Things. (Internet of Things - An action plan for Europe, 2009)

There are two areas of the IoT, one with smart things that are aware and connected while the other

is dumb or passive things. The aware and connected (smart) things will sometimes have their own

Internet Protocol Address, be embedded in complex systems and use sensors to gather information

about their surroundings and/or interact with other things or systems. (Internet of Things - An action

plan for Europe, 2009)

The dumb or passive things are things with a computer readable identity, making them visible to

computer-based systems. Most often when discussing the IoT these tags are RFID tags but

identification of physical things could also be done with other techniques like barcodes, 2-D codes

etc., e.g. any computer readable technology. These technologies are all able to observe and identify

physical things (Auto-ID Center, 2002).

The concept of IoT was made popular by the Auto-ID Center that was founded in 1999 as a research

collaboration between several big universities and industrial partners (Auto-ID Labs, History). The

center is proclaimed to be the founders of the concept of IoT and was designing, building, testing and

deploying a global infrastructure on top of the Internet. Their vision of IoT was as follows:

Our vision is simple: a world in which low-cost RFID tags are put on every manufactured item

and tracked using a single, global network as they move from one company to another and

one country to another. The key is to create a universal, open standard for identifying

products and sharing information. We are working with companies and organizations around

the world to make it as easy for one company to read another’s tags as it is for Dell

computers to communicate with Apple machines over the Internet. (Auto-ID Center, 2002)

In 2003 the Auto-ID Center was divided into two parts, EPCGlobal and Auto-ID Labs. The research

that was done in the years of the Auto-ID Center (1999-2003) forms the basis for today’s EPC

network (Auto-ID Labs, Publications). EPCGlobal is a part of the global organization GS1 and is their

suite of RFID standards and services for increased visibility and efficiency throughout the supply

chain, continuing to working towards the original vision of the Auto-ID Center (GS1, 2011). Auto-ID

Labs is still a research collaboration with collaboration between the same universities as in the

Auto-ID Center, their focus is on further development of the IoT infrastructure (Auto-ID Labs,

History).

4.1 EPCGlobal Architecture Framework EPCGlobal is a part of the GS1 organization which is an international non-profit organization with

member organizations in over 100 countries. They are dedicated to the design and implementation

of global standards and solutions to improve the efficiency and visibility of supply and demand chains

globally and across sectors. The GS1 system of standards is the most widely used supply chain

standards system in the world. (GS1, 2011)

21

The EPCGlobal Architecture Framework is a collection of standards to design an e-infrastructure that

combines Radio Frequency Identification (RFID) technology, existing communications network

infrastructure and the Electronic Product Code (EPC) to immediate and automatic identification and

tracking of physical items (things). (GS1, 2011)

The EPCGlobal standards, as seen in Figure 9 below, describe how identifiers for different physical

items should be constructed and defines an e-infrastructure for the identifiers to be read,

interpreted and conveyed. The standard also specifies a set of services that will be able to provide

additional information about uniquely identified things.

Figure 9: The EPCglobal architecture framework

EPCGlobal architecture framework is made up from fourteen standards, several of these describe

technical aspects of building an e-infrastructure and those standards are of no real interest for this

thesis. This thesis is focusing on the core design decisions in building e-infrastructures and will limit

its focus to identifiers, data structures and services for data-sharing. Therefore the standards that

don’t deal with those fields will not be further elaborated on. The standards that are of interest for

this thesis are the Tag Data Standard (TDS) and the EPC Information Services (EPCIS). Object Naming

Service (ONS) was also of interest from the start but we soon became aware that this part of the

standard was reconsidered and not used.

4.2 Tag Data Standard (TDS) The tag data standard covers two areas:

1. the specification of the Electronic Product Code (EPC), and its different representations in various levels of the EPCGlobal Architecture; and

2. the specification of data that is carried on RFID tags.

EPC is a universal identifier for any physical thing, it’s used in information systems that need to track

or refer to physical things. A large part of the systems using EPC rely upon RFID Tags as the data

22

carrier. For this reason the Tag Data Standard focus both on the EPC and on the encoding of the EPC

onto RFID tags, along with standards for other data that is stored on the RFID tags. (EPC Global, 2010,

pp. 16-17)

Even though the Tag Data Standard defines the standards for the encoding of the EPC and also the

encoding of the data on the RFID tags, a clear distinction between the two is necessary. The EPC is

the identifier and the RFID tag the data carrier. (EPC Global, 2010, pp. 16-17)

4.2.1 Naming, addressing, and identifying resources (URN, URL and URI)

The base format of an EPC is in Pure Identity EPC URI format (described later) and as the name

implies the EPC is a Uniform Resource Identifier (URI). (EPC Global, 2010, p. 16) This section is to

explain the underlying structure of the URI format. URI’s can be further classified as a locator, a name

or both, and therefore the formats for Uniform Resource Locator (URL) and Uniform Resource Name

(URN) are also explained. (Berners-Lee, Fielding, & Masinter, 2005, p. 7)

Uniform Resource Identifier A Uniform Resource Identifier (URI) provides a simple and extensible means for identifying a

resource. A URI is a compact sequence of characters that identifies an abstract or physical resource.

The URI syntax is defined by a hierarchical sequence of components referred to as the scheme,

authority, path, query and fragment and shown in the figure below. (Berners-Lee, Fielding, &

Masinter, 2005, pp. 1, 16)

foo://example.com:8042/over/there?name=ferret#nose

\_/ \______________/\_________/ \_________/ \__/

| | | | |

scheme authority path query fragment

| _____________________|__

/ \ / \

urn:example:animal:ferret:nose

Figure 10: Example URIs and their component parts

(Berners-Lee, Fielding, & Masinter, 2005, p. 16)

Uniform Resource Locator Uniform Resource Locator (URL) refers to the subset of URIs that in addition to identifying a resource also provides means to locate the resource (e.g. its network location). In general, URLs are written as follows: (Berners-Lee, Masinter, & M., 1994, p. 2)

Generic URL syntax:

<scheme>:<scheme-specific-part>

The URL contains the name of the scheme to be used (<scheme>) followed by a colon (”:”) and then

by a scheme specific string (<scheme-specific-part>). The interpretation of the scheme specific string

depends on what scheme is being used. (Berners-Lee, Masinter, & M., 1994, p. 2)

File Transfer protocol (ftp) example:

ftp://<user>:<password>@<host>:<port>/<url-path>;type=<typecode>

Uniform Resource Name

23

Uniform Resource Name (URN) is intended to serve as persistent, location-independent, resource identifier; it’s designed to make it easy to map other namespaces into URN-space. All URNs have the following syntax: (Moats, 1997, p. 1)

<URN> ::= "urn:" <NID> ":" <NSS>

Phrases enclosed in quotes are required and <NID> is the Namespace Identifier and <NSS> is the Namespace Specific String. The namespace Identifier determines the interpretation of the Namespace Specific String. (Moats, 1997, p. 1)

An individual scheme does not have to be classified as either a “name” or a “locator”, instances of URI’s from any given scheme may have the characteristics of either or both. (Berners-Lee, Fielding, & Masinter, 2005, p. 7)

4.2.2 Electronic Product Code (EPC)

The EPC is a universal identifier for any physical thing, it is used within information systems that need

to track or refer to physical things. Within the EPCGlobal Architecture the EPC can exist in three kinds

of formats: Pure identity EPC URI, EPC Tag URI and EPC Binary Encoding. The latter two contains RFID

specific information beside the actual EPC, the Pure identity EPC URI is an independent identifier

despite what technology it is used with. (EPC Global, 2010, pp. 20, 26)

EPC URI (Pure Identity)

Within computer systems the EPC takes the form of a URI, this form of the EPC is also called the

“Pure identity EPC URI”. This is the preferred way to refer to a physical object within business

applications. (EPC Global, 2010, pp. 28-29)

The EPC URI is a string with the following syntax:

urn:epc:id:scheme:component1.component2. …

Example of an EPCI URI:

urn:epc:id:sgtin:0614141.112345.400

As seen in the syntax for the Pure Identity EPC URI, the URI is also, as indicated by the initial “urn”

part, a Uniform Resource Name (URN) and then conforms to the general syntax of the URN. The next

part of the URN is “epc:id:scheme” which is the Namespace Identifier and is specifying that this URN

is an EPC identifier which will use the EPC scheme (see Table 1) specified at the “scheme” location.

The last part “component1.component2. …” is the Namespace Specific String whose precise form

depends on which EPC scheme that is used. It is this last part of the URN that will make the EPC a

unique identifier.

Each EPC scheme provides a namespace of identifiers that can be used to identify physical things, the

different schemas are used for different types of things (trade item, fixed asset etc.). This makes all

the EPC’s from all schemes collectively are unique identifiers for any type of physical thing. (EPC

Global, 2010, p. 29)

EPC Tag URI

When EPC is stored on Gen 2 RFID Tag it is stored with additional control information that is used in

the process of data capture from RFID tags. The EPC Tag URI is a string representation of the EPC and

this additional control information stored on a Gen 2 RFID tag. The EPC Tag URI is used at the data

24

capturing level when the additional control information stored on the RFID tag is of interest to the

capturing application. It is also used when writing the EPC memory bank of an RFID tag in order to

fully specify the content to be written. In The EPC Tag URI a particular binary encoding scheme is

specified, so it includes the length of the encoding. This is in contrast to the Pure Identity EPC URI

which identifies an EPC scheme but not a specific binary encoding e.g. GIAI (Global Individual Asset

Identifier) but not specifically GIAI-96. (EPC Global, 2010, p. 26)

EPC Binary Encoding

The EPC memory bank of a Gen 2 RFID Tag contains an EPC Tag URI in a compact binary format, this

format of an binary representation of an EPC Tag URI is called EPC Binary Encoding. The reason for

using the binary encoding is that it takes less memory to store and the memory available on RFID

tags are limited. There is a one-to-one relation between EPC Tag URI and the binary representation

of a Gen 2 RFID Tag. The EPC Binary Encoding is usually only encountered at low levels of the

EPCGlobal Architecture and is translated into either EPC Tag URI or Pure identity EPC URI before

presented to application logic. (EPC Global, 2010, p. 26)

Figure 11 describes the different forms an EPC could take throughout the different layers of the

EPCGlobal architecture. At the lower levels the EPC is represented by its binary form and as it moves

higher up in the layers of the architecture the EPC shifts first to an EPC Tag Uri then to the pure

identity form at the level of business applications. (EPC Global, 2010, pp. 26-27)

25

Figure 11: Different structures of an EPC through the layers of the EPCGlobal Architecture

4.2.3 EPC Schema

When allocating EPC’s for physical things different EPC Schema’s are used and the type of schema to

be used depends on the properties of the physical thing. The schemas are presented in the Table 1

below. (EPC Global, 2010, pp. 29-31)

EPC Scheme Typical Use

sgtin Trade item

sscc Logistics unit

sgln Location

grai Returnable asset

giai Fixed asset

gdti Document

26

gsrn Service relation (e.g., loyalty card)

gid Unspecified

usdod US Dept of Defense supply chain

Table 1: EPC schemas

GS1 Company Prefix (GCP) 4.2.3.1

The GS1 Company Prefix (GCP) is a required part of creating EPCs and it will be part of ensuring the

uniqueness of each EPC. To ensure that organizations will be provided with a unique GCP the

distribution of the GCP is controlled by GS1. For an organization to obtain a GCP they need to make a

request to a GS1 member organization. GS1 keeps records of all distributed GCPs and their

associated organization, this information is transparent and available through services at GS1. (GS1,

2011)

The distribution of GCP is done through that GS1 Global Office assigns GS1 Prefixes to member

organizations. The member organizations in turn use the GS1 Prefix to provide GCPs to applying

companies. The GS1 Prefix is assigned to member organizations, usually one per country. This

doesn’t mean that the GCP identifies the origin for a given product; the GS1 Prefix is only a number

capacity. (GS1, 2011)

A complete GS1 Prefix list can be found at GS1s webpage1:

Table 2: Example of GS1 prefixes

With the use of a GCP the companies are, without any involvements from GS1, able to generate EPCs

by themselves. The GCPs provided to the companies in combination with reference numbers

assigned by the organization themselves will create an EPC. Even if several companies use the same

serialized range the EPC will differ because of the GCP and will still remain a unique identifier. (GS1,

2011)

1 Company prefix list can be found at GS1 webpage: http://www.gs1.org/barcodes/support/prefix_list

27

Serialized Global Location Number (SGLN) 4.2.3.2

The Serialized Global Location Number (SGLN) EPC scheme is used to uniquely identify physical

locations or companies. The SGLN is a Global Location Number (GLN) with a serialized number added

to it, the part named “Extension” below, the general syntax for an EPC using a SGLN schema is: (EPC

Global, 2010, pp. 32,33)

urn:epc:id:sgln:CompanyPrefix.LocationReference.Extension

The first part of the identifier “urn:epc:id:sgln” determines that it’s a EPC using the SGLN

schema. The Company Prefix is assigned by GS1 to the managing entity. The managing entity

specifies the Location Reference to uniquely identify a physical location. The Extension is also

assigned by the managing entity to unique physical locations. If the Extension part is a single zero (0)

digit it indicates that the entire SGLN is in fact a GLN without any extension. (EPC Global, 2010, pp.

32,33)

Example: urn:epc:id:sgln:0614141.12345.400

Figure 12 and Figure 13 shows company addresses identified with a GLN EPC, this information is

found by using the service Global Electronic Party Information Registry (GEPIR) provided by GS1.

Figure 12: GS1 Sweden AB is identified by a GLN EPC

Figure 13: The Swedish Transport Administration (“Trafikverket”) is identified by a GLN EPC

Global Individual Asset Identifier (GIAI) 4.2.3.3

GIAI is used to identify any kind of fixed physical asset e.g. a computer, a chair or a desk at a

company. GIAI enables assets to be individually recorded as part of a fixed asset inventory control

system. This means that any individual asset within a company could be uniquely identified. The GIAI

key itself doesn’t contain any descriptive information about the asset it represents and its purpose is

only to work as an identifier. Any detailed information about the asset is stored in its owner’s

database and the GIAI key will refer to that information. (EPC Global, 2010, p. 34)

The EPC general syntax for the GIAI:

urn:epc:id:giai:CompanyPrefix.IndividulAssetReference

28

The Company Prefix is assigned by GS1 to the managing entity, and the individual Asset Reference is

assigned by the managing entity. (EPC Global, 2010, p. 34)

EPC GIAI Example: urn:epc:id:giai:0614141.12345400

4.2.4 EPC Binary Coding Schema

For each EPC Scheme there is one or more corresponding EPC Binary Coding Schemes that specifies

how the EPC is encoded into a binary representation. The different Binary Coding Schemas that exist

for the same EPC schema differs in the amount of bits it uses, shorter binary coding schemas result in

fewer bits and therefore could be used with cheaper RFID tags (RFID tags with less memory is

cheaper) but with the downside of a shorter range of serial numbers. (EPC Global, 2010, pp. 78,79)

The EPC memory bank of a Gen 2 tag contains a binary encoded EPC along with other control

information. The EPC Tag URI specifies both the EPC and the control information in the memory

bank, it’s also specifics the binary encoding schema that is to be used. (EPC Global, 2010, pp. 53, 54)

Each coding scheme for EPCs is distinguished through the use of a separate namespace. In the EPC

URI notation, this is indicated using a URI prefix such as urn:epc:id:sgtin or urn:epc:id:sscc,

respectively representing the use of SGTIN and SSCC coding schemas. In the binary encoding of an

EPC, the namespace is instead indicated using a binary header, the first 8 bits of the binary encoding

of an EPC. This binary header is followed by a series of fields whose length, structure and function is

in turn determined by the header value i.e. the specific schema. (EPC Global, 2010, pp. 79-82)

There are currently sixteen binary encoding schemas defined in the standards. In Table 3 below five

of those schemes are presented with their binary header values and encoding length. (EPC Global,

2010, pp. 79-82)

Table 3: Binary encoding schemes and their header values

29

GIAI-96 4.2.4.1

As shown in Table 3 above the GIAI-96 binary encoding scheme is 96 bits large, it is used for the GIAI

scheme. Table 4 below describes the coding table used for the GIAGI-96 binary coding schema. (EPC

Global, 2010, pp. 100,101)

Table 4: EPC Binary Coding table for GIAI-96

30

4.3 EPC Information Services (EPCIS) EPC Information Services (EPCIS) is an EPCglobal standard for sharing EPC related information

between trading partners. EPCIS enables applications to leverage EPC data via EPC-related data

sharing, both within and across enterprises. (GS1, 2007, p. 7)

EPCIS deals with two kinds of data, Event Data and Master Data. Event data is created in the course

of carrying out business processes; data is captured by the EPCIS Capture Interface and made

available through the EPCIS Query Interfaces. Event Data is mostly made up from EPC’s, EPC’s are just

identifiers and to be able to interpret such event data additional information is required. Master data

provides additional information and the necessary context for giving event data more meaning.

Master data is also available for query through the EPCIS Query Interfaces.

4.3.1 EPCIS Event Types

There are five event types defined in the EPCIS specifications, one generic one and four subclasses

that can represents events from a wide variety of industries:

EPCISEvent is a generic event that serves as the base class of all the events in the EPCIS

specification.

ObjectEvent represents an event that occurred to a number of entities denoted by EPC’s.

AggregationEvent represents an event that occurred to a number of entities denoted by

EPC’s that are physically aggregated together.

QuantityEvent represents an event that specifies a quantity of entities sharing the same EPC

class; no individual entities are specified in this event.

TransactionEvent represents an event which a number of entities denoted by EPC’s become

associated or disassociated with some business transactions.

The UML diagram below shows the five events, there properties and associations:

31

Figure 14: Core events of the EPCIS (GS1, 2007, pp. 28, 29)

What, when, where and why The four subclass events (ObjectEvent, AggregationEvent, QuantityEvent and TransactionEvent)

described above all contains fields that represents four key dimensions of any EPCIS event. The four

dimensions are: (1) the objects or other entities that are the subject of the event; (2) date and time

of the event; (3) the location where the event occurred and (4) the business context of the event.

These four dimensions can be summarized as “what, when, where and why” and is described in the

table below. (GS1, 2007, pp. 29, 30)

Retrospective (at the time of the event)

Prospective (true until contradicted by subsequent event)

What EPC EPCClass + quantity (QuantityEvent) BusinessTransactionList (TransactionEvent)

When Time

Where ReadPointID BusinessLocationID

Why (business context) BusinessStepID DispositionID

32

Table 5: What, when, where and why for EPCISEvents

4.3.2 EPCIS Vocabulary Types

Events may carry additional descriptive information besides the information from the four

dimensions of “what, when, where and why”. There is a set of defined vocabulary types that could be

used within an EPCIS event. In most cases these vocabulary types gives additional information to the

EPCIS event but in some cases they are a necessity e.g. the BusinessTransactionList (a set of

BusinessTransaction vocabulary types) is a primary subject to the TransactionEvent. (GS1, 2007, p.

30)

The EPCIS event vocabulary types are summarized in the table below and are described in the

following sections.

Table 6: EPCIS Vocabulary Types

Action Type

The Action type is not a vocabulary type and should not be extended by industry groups. The Action

type describes how the EPCIS event relates to the lifecycle of the entities denoted by the EPC’s in the

event. The Action type is an enumerated type with three possible values:

ADD – The entity in question has been created or added to.

OBSERVE – The entity in question has not been changed in any way, it have only been

observed.

DELETE – The entity in question has been removed from or destroyed.

The Action type cannot be assigned any other value then described above but the interpretation of

the Action type can be different for different types of EPCIS events. (GS1, 2007, pp. 31, 32)

Location Types

There are two types of real locations identifiers in the EPCIS specifications; those are the vocabulary

types ReadPointID and BusinessLocationID.

ReadPointID – A recorded location that is meant to identify the most specific place at which

an EPCIS event took place. Read Points are determined by the EPCIS Capturing Application.

The Read Point is designed to identify the” where” dimension of the event.

Vocabulary Type User /

Standard

URI

ReadPointID User urn:epcglobal:epcis:vtype:ReadPoint

BusinessLocationID User urn:epcglobal:epcis:vtype:BusinessLocation

BusinessStepID Standard urn:epcglobal:epcis:vtype:BusinessStep

DispositionID Standard urn:epcglobal:epcis:vtype:Disposition

BusinessTransaction User urn:epcglobal:epcis:vtype:BusinessTransaction

BusinessTrasactionTypeID Standard urn:epcglobal:epcis:vtype:BusinessTransactionType

EPCClass User urn:epcglobal:epcis:vtype:EPCClass

33

BusinessLocationID – Is a uniquely identified and recorded location that specifies a specific

place where a thing is assumed to be until it is reported to be at another place by a

subsequent EPCIS event with a different Business Location.

(GS1, 2007, pp. 32-36)

Business Step

A business step denotes steps in the business process; it specifies the business context in which an

event took place. The business step is represented by the vocabulary type BusinessStepID:

BusinessStepID – A vocabulary type that denotes steps in the business process, like

“shipping”, “loading”, “receiving” etc. By assigning identifiers to common business steps

those terms get a standardized meaning across the EPCIS standard.

(GS1, 2007, p. 37)

Disposition

The disposition specifies the business state of a thing; the disposition is denoted by the vocabulary

DispositionID:

DispositionID – The field in the EPCIS-event that specifies the business condition for all the

things of an event. The disposition is assumed to be true until another EPCIS-event

contradicts the disposition.

(GS1, 2007, pp. 37, 38)

Business Transaction

A particular business transaction is denoted by a Business Transaction. A business transaction could

be included in an EPCIS-event to specify the events participation in particular business transactions. A

business transaction is described by the vocabularies BusinessTransactionType and

BusinessTransactionID:

BusinessTransactionTypeID –Identifies the type of the of business transaction that the event

is part of. This vocabulary is optional when specifying business transactions in the EPCIS-

events. An example of this field could be: “purchase order.”

BusinessTransactionID – User defined vocabulary that is an identifier that denotes a specific

business transaction. An example value of this field could be: “Acme Corp purchase order

number 12345678.”

(GS1, 2007, p. 38)

34

4.3.3 EPCISEvent

EPCISEvent is the base class for all EPCIS events and all of the more specific events are subclasses to

EPCISEvent. EPCISEvent has three fields; eventTime, recordTime and eventTimeZoneOffset that all

EPCIS events will also inherit. The field’s formal specifications are described in the table below. (GS1,

2007, pp. 40, 41)

Field Type Description

eventTime Time The date and time at which the EPCIS Capturing Applications asserts the event occurred.

recordTime Time (Optional) The date and time at which this event was recorded

by an EPCIS Repository.

eventTimeZoneOffset String The time zone offset in effect at the time and place the event occurred, expressed as an offset from UTC. The value of this field shall be a string consisting of either the character ‘+’ or ‘-’, followed by two digits whose value is within the range of 00 through 14 (inclusive), followed by a colon character ‘:’, followed by two digits whose value is within the range 00 through 59 (inclusive), except that if the value of the first two digits is 14, the value of the second two digits must be 0. For example, the value +05:30 specifies that where the event occurred, local time was five hours and 30 minutes later than UTC (that is, midnight UTC was 5:30am local time).

Table 7: Fields of the EPCISEvent

4.3.4 ObjectEvent

An ObjectEvent captures information about an event with one or more physical thing identified by

EPC’s. Even though the ObjectEvent can contain several EPC’s, no relationship or association

between those EPC’s does exist. The EPC’s have just been part of the same event. The ObjectEvent’s

fields, their types and respective descriptions are described in the table below: (GS1, 2007, pp. 40-44)

Field Type Description

eventTime recordTime eventTimeZoneOffset

Inherited from EPCISEvent

epcList List<EPC> A set of one or more EPC’s identifying the physical objects that take part in this event. When the identifiers are EPC’s they should be in the pure identity URI form.

action Action How the event relates to the lifecycle of the EPC’s denoted in the event.

bizStep BusinessStepID (Optional) The business step of which this event was a part off.

disposition DispositionID (Optional) The business condition for

all the objects that takes part of the

event. The condition is assumed to be

true until another EPCIS-event

contradicts the disposition.

35

readPoint ReadPointID (Optional) The read point at which

the event took place.

bizLocation BusinessLocati

onID

(Optional) The business location

where the objects associated with the

EPC’s in the event may be found,

until contradicted by a subsequent

event.

bizTransactionList Unordered list of

zero or more BusinessTransa

ction instances

(Optional) A set of business

transactions that define the context of

the event.

Table 8: Fields of the ObjectEvent

4.3.5 AggregationEvent

The AggregationEvent is a subclass to the EPCISEvent and therefore inherits its members. An

AggregationEvent is an event that applies to things that have been physically aggregated together

with each other. There is a set of things that will be contained within another containing thing, the

containing object’s identifier will serve as the identifier for the physical aggregation itself. This type

of event is intended to be used for aggregations that have a strong physical relationship between the

contained and the containing things. The physical relationship between the things should be such

that they should appear at the same location at the same until they are disaggregated. (GS1, 2007, p.

44)

The Action type role within the AggregationEvent:

ADD – The epc’s in the epc-list of the event should be aggregated with the parent of the

event. This includes when the aggregation occurs for the first time as well as for adding

children to an existing aggregate.

OBSERVE – The event don’t affect the aggregation, the parent container and its children is

observed at a specific location and time. The reading could be incomplete and omit the

parent epc and/or some children epc’s.

DELETE – The epc’s in the epc-list should be disaggregated from the parent. The epc’s no

longer has any physical relationship with the parent epc. The list of child epc’s may be

omitted from the event which means that all the children to the parent epc should be

disaggregated.

The AggregationEvent is intended to represent aggregation between physical things, therefore the

children in an AggregationEvent is identified with epc’s. However the parent entity is not necessarily

a physical object separate from the aggregation and could therefore be identified by either an EPC or

another suitable identifier drawn from a private vocabulary. The AggregationEvent’s fields, their

types and respective descriptions are described in the table below: (GS1, 2007, pp. 45-46)

36

Field Type Description

eventTime

recordTime

eventTimeZoneOffset

Inherited from EPCISEvent

parentID URI (Optional when action is OBSERVE,

required otherwise) This field contains

the identifier of the parent of the

association. If the identifier is an EPC it

should be in the pure identity URI

format. The identifier could also be a

valid URI.

childEPCs List<EPC> A set of EPC’s identifying the contained

objects of the association. The EPC’s

should be in the pure identity URI

format. The set may be empty if the

action is DELETE which indicates that all

previously aggregated children are

disaggregated from the parent.

action Action How this event relates to the lifecycle of

the aggregation named in this event.

bizStep BusinessStepID (Optional) The business step of which

this event was a part.

disposition DispositionID (Optional) The business condition of the

objects associated with the EPC’s,

presumed to hold until contradicted by

a subsequent event.

readPoint ReadPointID (Optional) The read point at which the

event took place.

Table 9: Fields of the AggregationEvent

4.3.6 Master Data

The EPCIS event does just contain limited information and therefore additional data is necessary to

interpret the event. This additional data is called Master Data and provides necessary context to the

event data. Master data doesn’t grow merely because more business is transacted but instead tends

to grow as the organization grows in size. Event data on the other side grows in quantity as more

business is transacted. For example a location identifier has associated master data that describes

the specific business locations that is being identified and a GIAI has associated master data that

describes the asset.

37

4.3.7 Service Layer

The EPCIS specification defines a service layer for both the capturing of EPCIS events and for client

applications to query subsequent EPCIS data. Figure 15 below shows the main architecture and the

different interfaces that are the core of the EPCIS service layer (GS1, 2007, p. 55).

Figure 15: Architecture of EPCIS service layer

4.3.8 EPCIS Capture Interface

The EPCIS provides operations by which EPCIS events may be delivered from an EPCIS Capture

Application to either an EPCIS Repository or consuming application. The functionality is specified by

the EPCIS Capture Interface, the interface only has one method, capture. The capture-method takes

a set of EPCIS events as argument, e.g. a set of valid EPCIS events or subtypes of these. The method

returns no result. (GS1, 2007, pp. 57, 58)

Figure 16: The EPCIS Capture Interface

4.3.9 EPCIS Query Interfaces

The EPCIS provides a framework by which client applications may query EPCIS data. Two interfaces

are provided; EPCIS Query Control Interface and EPCIS Query Callback Interface and these are

referred to collectively as the EPCIS Query Interfaces. (GS1, 2007, p. 61)

38

EPCIS Query Control Interface EPCIS Query Control Interface provides both on demand queries, in which a client application request

a query to be executed and the result is returned in response, and standing queries, in which a client

application subscribes to periodic results from the execution of a specific query. Results of standing

queries are delivered to the client application via the EPCIS Query Callback Interface. These two

different kinds of available techniques for a client application to receive EPCIS data is respectively

referred to as “pull” and “push”. (GS1, 2007, p. 61)

The EPCIS Query Control Interface is defined below; any implementation of the interface shall

implement all of the defined methods.

Figure 17: The EPCIS Query Control Interface

Subscribe – Registers a subscriber for a previously defined query. The values to any

parameters used by the query, this is done by providing a set of name/value pairs where the

name corresponds to the named parameter and the value to its value. A destination URI for

the result to be delivered too. Definition for how the subscription should be processed i.e.

conditions for the query to be invoked and a new result to be returned. A string to be used as

an identifier to distinct the subscription from other subscriptions.

Unsubscribe – Removes a registered subscription with the specified string identifier.

Poll – A request to execute a predefined query with a specified name and returning the

results. Named parameters defined by the query is also included in the request.

getQueryNames – Returns a list of available predefined query names that could be used with

the subscribe and poll methods.

getSubscriptionIDs – Returns a list of the id’s of all the subscriptions to a specified query

name.

getStandardVersion – Returns a string that specifies what version of the EPCIS specification

this implementation complies with. E.g. for version 1.0 of the EPCIS specification the method

should return the string “1.0”.

39

getVendorVersion – Returns a string that identifies what vendor extensions this

implementation provides. An empty string specifies that no extensions are provided and the

implementation only supports the standard functionality. A non-empty string indicates

vendor extensions and the meaning of the string is vendor-defined.

(GS1, 2007, pp. 62-65)

EPCIS Query Callback Interface Unlike the EPCIS Query Control Interface, the EPCIS Query Callback Interface is not directly accessible

for client applications. Instead, a client application subscribes a query via the EPCIS Query Control

Interface whereby the query results are returned via the EPCIS Query Callback Interface. (GS1, 2007,

p. 93)

Figure 18: The EPCIS Query Callback Interface

Each time the EPCIS service executes a standing query it shall attempt to deliver the result of the

query to the subscriber. This is done by the service invokes one of the three methods in the EPCIS

Query Callback Interface. If the query succeeded the callbackResults will be invoked with the result

as the argument. If the query is not executed normally one of the callbackQueryTooLargeException

or callbackImplementationException will be invoked, which one depends on what kind of exception

that aborted the execution of the query. (GS1, 2007, p. 93)

40

5 Swedish transport administrations implementation of EPCIS This chapter will describe how the Swedish transport administration (STA) have used EPCGlobal

framework to implement the railroad e-infrastructure.

5.1 Tag Data Standard (TDS) The first section describes the different identifiers used for the e-infrastructure. The identifiers are

based on the EPC standard.

5.1.1 The EPC used for railroad vehicles

The chosen standard for the identification of physical vehicles is the Global Individual Asset Identifier

(GIAI) EPC Schema. GIAI has the general syntax as described below:

General syntax: urn:epc:id:giai:CompanyPrefix.IndividulAssetReference

GS1 Company Prefix (GCP) According to the standard the company prefix should be set to the owner of the asset. The company

prefix for a specific company is assigned by GS1 and this is also the way that the company prefix is

assigned in this case.

Individual Asset Reference (IAR) The Individual Asset Reference should be set by the company that is responsible for the company

prefix. However, in this case the STA have decided how the IAR should be assigned. The IAR is

designed as a 13-digit code. The first is either one (1) or two (2), this value represent the position

(either side of the wagon) of the tag on the vehicle. The rest of the IAR consists of the twelve (12)

digit EVN number.

Syntax for Individual Asset Reference: (1/2)dddddddddddd

Vehicle identifier example Example GIAI EPC for a railroad vehicle: urn:epc:id:giai:735003433.1317445521311

In the example the company prefix is 735003433 and this is the GCP of Green Cargo, and it shows

that the physical thing is owned by Green Cargo. The individual asset reference is 1317445521311

and is identifying not only the physical railroad vehicle but more precise one end of the vehicle

because there is a RFID tag located on each side of the railroad vehicle. If the first digit is removed

the remaining twelve digits are a valid EVN (317445521311).

Figure 19: Information about Green Cargo from GEPIR

5.1.2 Location identifier

There will be a set of readers located beside the railway tracks on a number of different locations.

The locations of the readers are of great importance for the e-infrastructure. To uniquely identify

physical locations the Serialized Global Location Number (SGLN) schema is used.

41

SGLN General syntax:

urn:epc:id:sgln:CompanyPrefix.LocationReference.Extension

The GS1 company prefix used in the location identifier is the GS1 Company Prefix of the Swedish

transport administration. The Location Reference is only three zeros (000) for all the location

identifiers. The Extension is the part where the location identifier starts to differ from each other.

The Extension part is assigned a serial number to keep the identifiers unique.

The SGLN location identifiers are associated with a text representation of the location and the reader

brand that is located at the read point. Below in Table 10 all of the location identifiers and their

associated data are presented.

epcisSGLN epcisReadPointReadable epcisReaderType

urn:epc:id:sgln:735999271.000.1 Hunstugan_USP Intermec

urn:epc:id:sgln:735999271.000.2 Odensberg_USP Siemens

urn:epc:id:sgln:735999271.000.3 Odensberg_NSP Scirocco

urn:epc:id:sgln:735999271.000.7 Hunstugan_NSP Tagmaster

urn:epc:id:sgln:735999271.000.8 Falkoping Scirocco

urn:epc:id:sgln:735999271.000.9 Goteborg Tagmaster

urn:epc:id:sgln:735999271.000.10 Tväråbäck Adage

urn:epc:id:sgln:735999271.000.11 Pölsebo Siemens670R

urn:epc:id:sgln:735999271.000.12 Lönsboda Siemens670R

urn:epc:id:sgln:735999271.000.13 Sunderbyns_Sjukhus Adage Table 10: Location identifiers and their associated data

Location identifier example Example location EPC: urn:epc:id:sgln:735999271.000.12

The EPC above is using the SGLN EPC scheme and is composed by the GS1 company prefix

“735999271” which is the GCP of “Banverket” which now is a part of the Swedish transport

administration (see Figure 20 below). The location reference is a value of “000” and the extension

value is “12”. The EPC is associated with location and reader data as described in Table 10 above. This

specific EPC identifies the location of “Lönsboda” with a RFID-reader of type Siemens670R.

Figure 20: Information about Swedish transport administration from GEPIR

42

5.2 EPC Information Services (EPCIS) This chapter will describe how the Swedish transport administration (STA) has implemented the EPC

Information Service (EPCIS) specification. The aim of the implementation of the EPCIS specifications

is to track individual railroad vehicles and train compositions at specific reading points.

5.2.1 ObjectEvent

The STA started out to create an EPCIS ObjectEvent for every railroad vehicle, which constitutes the

physical train that passes a reader. The reader is set to a limited time frame when a train is

considered to have passed the reader. Based on these ObjectEvents an aggregated file was created

and this file was considered to represent the passage of a train composition. However, it was soon

discovered that there was a need for an identifier that represented the aggregation of railroad

vehicles i.e. the train composition. It was not enough to separate the passings of two different train

compositions only by two different xml-files.

Xml ObjectEvent:

5.2.2 AggregationEvent

In order to solve the problem of not having an identifier for the passing of a train composition the

EPCIS event type AggregationEvent was used. The AggregationEvent has a field named parentID that

could be an EPC or a valid URI as defined in the EPCIS. The event also has a field named childEPCs

that is a list of EPS’s, all of which are associated to the parentID. The AggregationEvent type is used in

23T14:26:50.9879517+01:00" xmlns:epcis="urn:epcglobal:epcis:xsd:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:epcglobal:epcis:xsd:1 file:///F:/Local%20Projects/RFIDSchema/EPCglobal-epcis-1_0.xsd"> <EPCISBody> <EventList> <ObjectEvent> <eventTime>2011-02-23T13:26:50.9879517Z</eventTime> <eventTimeZoneOffset>+01:00</eventTimeZoneOffset> <epcList> <epc>urn:epc:id:giai:735999271.1917400000019</epc> </epcList> <action>OBSERVE</action> <bizStep>PassageO</bizStep> <readPoint> <id>urn:epc:id:sgln:735000512.000.1</id> </readPoint> </ObjectEvent> <ObjectEvent> <eventTime>2011-02-23T13:26:52.9879517Z</eventTime> <eventTimeZoneOffset>+01:00</eventTimeZoneOffset> <epcList> <epc>urn:epc:id:giai:735999271.1917400000020</epc> </epcList> <action>OBSERVE</action> <bizStep>PassageO</bizStep> <readPoint> <id>urn:epc:id:sgln:735000512.000.1</id> </readPoint> </ObjectEvent> </EventList> </EPCISBody> </epcis:EPCISDocument>

43

such a way that for each GIAI that is read an AggregationEvent is created. The GIAI is put in the child

list and all the created aggregation events for on train composition passage will have the same

parentID, which is set to a GUID2 that uniquely identify every train passage.

Xml AggregationEvent:

5.2.3 Master Data

The STA focus has been on Event Data and has not yet started the work to create an infrastructure

for Master Data. They have recognized the importance of creating a location database where unique

SGLN EPC identifiers are instantiated and controlled. There is also a need for accessing the EC VVR

registry and the OPERA system in order to identify railroad vehicles and to get information about

train compositions.

5.2.4 Services

There are two services described in the EPCIS specifications, the EPCIS Query Control Interface and

the EPCIS Query Callback Interface. Neither of these services is implemented as described in the

2 Globally unique identfier (GUID) is a unique reference number used as an identifier in computer software

<ns0:EPCISDocument schemaVersion="1.0" creationDate="2011-06-21T09:37:38.8723177+02:00" xmlns:ns0="urn:epcglobal:epcis:xsd:1" xmlns:bv="http://xsd.banverket.se/LA/EPCISExtension.xsd" xmlns:epcglobal="urn:epcglobal:xsd:1" xmlns:sbdh="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader"> <EPCISBody> <EventList> <AggregationEvent> <eventTime>2011-06-21T09:37:38.8723177+02:00</eventTime> <eventTimeZoneOffset>+02:00</eventTimeZoneOffset> <parentID>bcb54b67-d47c-44b2-9246-d57f9f5f6257</parentID> <childEPCs> <epc>urn:epc:id:giai:735003433.1317445522194</epc> </childEPCs> <action>OBSERVE</action> <bizStep>PassageO</bizStep> <readPoint> <id>urn:735999271.0001.1243</id> </readPoint> </AggregationEvent> <AggregationEvent> <eventTime>2011-06-21T09:37:40.1433177+02:00</eventTime> <eventTimeZoneOffset>+02:00</eventTimeZoneOffset> <parentID>bcb54b67-d47c-44b2-9246-d57f9f5f6257</parentID> <childEPCs> <epc>urn:epc:id:giai:735003433.1317445522087</epc> </childEPCs> <action>OBSERVE</action> <bizStep>PassageO</bizStep> <readPoint> <id>urn:735999271.0001.1243</id> </readPoint> </AggregationEvent> </EventList> </EPCISBody> </ns0:EPCISDocument>

44

specifications. There is a possibility to get access to the created EPCIS events through an ftp server,

after being authorized by the STA.

There are plans on implementing the push (push data out to listeners), pull (execute queries against

collected EPCIS data) and subscribe (standing query that executes when some conditions are met)

functionality of the EPCIS Query Control Interface. The push functionality will be implemented first

because of the easier technical requirements. There are plans on utilizing the Fosstrak software to

implement this functionality but for now a preliminary solution to the push functionality is to

distribute the EPCIS events through an ftp server.

5.3 Evaluation of the EPCIS implementation by the STA In this chapter the Swedish Transport Administration (STA) implementation of EPCIS will be

evaluated with the EPCGlobal standards.

5.3.1 Tag Data Standard (TDS)

This section will evaluate the chosen identifiers that are used in the e-infrastructure against the Tag

Data Standard (TDS) specifications.

Vehicle identifier 5.3.1.1

According to the EPCGlobal framework it is the owner of the physical asset that should be the entity

that manages the assignment of the individual asset reference of the EPC. However, the asset

reference is in this case made up from the European Vehicle Number (EVN) which the owners don’t

have any control over. It is the National Security Authority (NSA) of member states in the EU is

responsible for the assignment and managing of the European Vehicle Number to railway vehicles.

This means that the NSA’s are the real managing entities for the identifier used as the individual

asset reference in the EPC’s. This creates an ambiguity concerning the control of the identifier

because the actual managing entity (the NSA’s) of the individual asset reference is not the one that is

assigned the GCP.

Location identifier 5.3.1.2

Locations will be identified by an EPC with the EPC identifier described in 5.1.2. The STA is the entity

in charge of identifying the reader locations and of doing the actual placing of readers. Therefore it’s

a correct choice to use The STA assigned GCP as the company prefix in the EPC identifier.

With that said the EPC is not completed without the location reference. For now there is no clear

strategy for how the creation of the location reference for the identifier is to be done. It’s vital that

there exist a clear separation between the location identifier and the RFID-readers.

5.3.2 EPC Information Services (EPCIS)

This section will evaluate the chosen data structures that are used in the e-infrastructure. The

evaluation will be both against the EPC Information Services (EPCIS) specifications and good design

principles for data structures.

ObjectEvent 5.3.2.1

The ObjectEvent was not used anymore, and for a correct reason, as it was found to be insufficient.

This solution did not allow for associating several ObjectEvents generated for each railroad vehicle in

the train composition.

45

AggregationEvent 5.3.2.2

The problem to connect all the readings for each railroad vehicle that constitutes a train composition

was solved using an EPCIS aggregation event. For each railway vehicle that passes an RFID-reader an

aggregation event is created, the events are connected to each other by that they are assigned the

same GUID to a parent id property of each event.

It is important to be able to connect each railroad vehicle passage to a specific train composition

passage, still the implemented solution could be criticized because it is not in line with the standard.

The aggregation event is implemented in such a way that an aggregation event is created for the

reading of each vehicle. This is not in line with the standard where the EPC’s of the railroad vehicles

should appear as child EPS’s of a single aggregation event encompassing the entire train composition.

Master Data 5.3.2.3

Three types of master data has been identified as important to the usefulness of the e-infrastructure,

Location master data, Train-compositions master data and railway vehicle master data.

There is additional information about the locations stored at the STA as it is described in 5.1.2. This

information is today only created and stored for internal development purposes only. The need for

additional information about locations is recognized and a location-database is planned for

development by the STA. How this database should be designed and how this location master data

should be conveyed is not yet defined. Master data of railway vehicles is stored in the national

vehicle register and is more thoroughly discussed in chapter 6.

Service-plattforms 5.3.2.4

The current ftp-solution is sufficient for small scale distribution of the EPCIS events but will not be

enough when the amount of users scales up. There is no automated process for users to retrieve

EPCIS event data with this solution. Therefore there is a need for the EPCIS Query Callback Interface

and EPCIS Query Control Interface to be implemented. Fosstrak could be a good choice to limit the

time of the development process.

The STA has found Fosstrak to be a real good alternative to implement the different parts of the

EPCIS specifications from scratch. If it’s possible to use Fosstrak it will be a timesaver in the

development process because of the already implemented parts of the EPCIS infrastructure. The STA

is exploring Fosstrak and has great anticipation on it but they haven’t made any commitments to it

yet.

46

6 European Centralized Virtual Vehicle Registry (EC VVR) To achieve interoperability of the trans-European conventional rail system, the European commission

has made a number of decisions. These decisions are documented in the statutes; (2011/107/EU,

2011) and (2004/50/EC, 2004). These statutes state that each member state should have an

infrastructure for the authorization of vehicles, and to register vehicle information into a national

vehicle register. The member states national vehicle registers (NVR’s) should also be connected to a

European Centralized Virtual Vehicle Register (EC VVR), which will allow for interoperability between

the national registers. The European Railway Association (ERA) is responsible for the ECVVR.

(2011/107/EU, 2011)

6.1 EC VVR e-infrastructure The European Centralized Virtual Vehicle Register (EC VVR) should be a system that allows authorized

users to search for railroad vehicles. The EC VVR framework is a decentralized solution for storing

and updating information about railroad vehicles in the EU. ERA is responsible for the EC VVR

framework, the VVR and the infrastructure of the NVR’s, but the Member State (MS) is responsible

for implementing the NVR’s. There are two different ways to connect to the VVR, either by using a

Standard NVR developed by the ERA that follows all the specifications of the EC VVR or to use a

custom NVR. If the MS use a custom NVR it has to be adapted to meet the requirements of a

Translation Engine (TE) to be able to communicate with the VVR.

The intentions with the EC VVR framework are the following:

Recording authorization

Recording the EVN allocated to vehicles

Looking for brief, European-wide information on a particular vehicle

Following up legal aspects such as obligations and legal information

Retrieving information for inspections mainly related to safety and maintenance

Enabling contact with the owner and keeper

Cross-checking some safety requirements before issuing Safety Certificates

Following up a particular vehicle

The EC VVR is the framework that specifies the structure and how enquiries about railroad vehicles

stored in any of the member states NVRs’ is performed. The EC VVR consists of two subsystems:

The National Vehicle Registry (NVR), which is the Local Register of each member state

The Virtual Vehicle Registry (VVR), which is the central search engine for the European

Railroad Agency (ERA)

47

Figure 21: EC VVR Architecture

6.1.1 National Vehicle Registry (NVR)

Each member state shall keep a computer-based NVR of the vehicles authorized in its territory; All

vehicles that are authorized in a member state should be registered in the NVR, but passenger cars

and freight wagon only need to be registered in the NVR where they first was first placed in service.

The NVR shall be kept updated by an organization independent of any railway undertaking. The NVR

should be accessible by safety authorities, investigating bodies, regulatory bodies, European Railway

Agency (ERA), railway companies, infrastructure managers and persons or organizations registering

vehicles or is identified in the NVR. The NVR should be linked to the VVR to make the interoperability

between the rolling stock of the member states feasible.

The Member States has the option to either developed an own registry or to use a Standard National

Vehicle Registry (sNVR). Which is a standard implementation of all the required setting that is

needed for adding, retrieving and updating information about vehicles. It also comes with

connections to the VVR.

If the Member State does not want to use the standard implementation of the National Vehicle

Register or already have a register (installed base). The Member State can use the existing register

and connect to the Virtual Vehicle Register through a Translation Engine. The Translation Engine is an

interface or gateway to make the National Vehicle Register accessible in the ECVVR.

48

Figure 22: ECVVR architecture (with sNVR and NVR/TE)

6.1.2 Virtual Vehicle Registry (VVR)

The other subsystem of the EC VVR is the VVR; the VVR is software and the entry point for authorized

users to make a distributed search. This means that the authorized user only need to make an

enquiry about a vehicle in the VVR and the VVR retrieves the information from the appropriate NVR.

The VVR allows its users to retrieve information about authorization and registration of railroad

vehicles in the EU. This makes the distributed National Vehicle Registers (NVRs) transparent to the

users and permits information to be retrieved in an efficient manner.

6.1.3 The user roles of the EC VVR framework

There are a number of user roles defined with different access rights. These user categories and the

access levels are defined in the lists below.

RE/NSA‘XX’ (Registration Entity/National Security Agency)

A Registration Entity is the body responsible for keeping and updating the National vehicle

Registry. The National Security Agency in Member State ‘XX’

Other NSA/REs

This means other NSA/REs than the one the Vehicle is originally registered in.

ERA (European Railway Agency)

European Railway Agency is the European Union’s organization for creating a safe, modern

integrated railway network over the whole Union (over national borders).

Keepers

The keeper of the vehicle, this is especially important to be able to distinguish from the

owner of the vehicle.

Fleet managers

Another important category since it is common that the owner, keeper and the manager

often are not the same person.

Owners

49

The owner of the vehicle

RUs (Railway Undertaking)

The company or organization that operates the railroad vehicles (Train Operator)

IMs (Infrastructure Manager)

In this aspect this means primarily the physical infrastructure of the railroad.

IBs and RBs (Investigating and Regulatory Body)

Investigating and regulatory bodies are the checking and auditing bodies notified by Member

State.

Other legitimate users

These are the users not specified on beforehand, but have to be granted recognition by NSA

or ERA. This is defined occasional and duration can be limited.

Access code/Type of access To ensure the integrity of the information in the ECVVR each entity gets a matching access level.

No access

The user has ho rights

Restricted consultation (conditions in “Read rights” column)

This means that the user have restricted Read rights. For example a fleet manager can read

information about their own fleet.

Unrestricted consultation

The user can read all information

Restricted consultation and updating

The user can read and update information, but with some defined restrictions.

Unrestricted consultation and updating

The user can read and update everything.

50

6.1.4 National Vehicle Register data model

EC decision 2011/107/EU on adopting a common specification of the national vehicle register

(amending decision 2007/756/EC) specifies the required fields and data format of the NVR. From this

specification a data model over the information objects of the NVR is created, the data model is

presented in Figure 23.

Figure 23: National Vehicle Register data model

Table 11 presents the identifiers and their data format of each information object of the data model.

No. Identifier Format Information Object

1 European Vehicle Number 12 digits (2006/920/EC, 2006, p. 109)

Vehicle

2 Member State numeric code

2 digits (2006/920/EC, 2006, p. 116)

Member State

The name of the NSA Text National Safety Authority (NSA)

3 Reference to the ERATV Alphanumeric code(s) European Register of Authorized Types of Vehicles (ERATV)

4 Coded restrictions Category|Type|Value Restrictions

Non-coded restrictions Text

5 Registered Business Number

Text Owner

6 Registered Business Number

Text Keeper

7 Registered Business Number

Text Entity in charge of maintenance

8 Withdrawal code 2 digits Withdrawal

51

9 List of member states List of numeric codes Member States where the vehicle is authorized

10 Authorization Number Old vehicles: Text New vehicles: European Identification Number (EIN)

Authorization of placing in service

Table 11: Identifiers and their format for the objects in the data model

Descriptions of the information objects from the data model:

1. Vehicle

o The information object of a vehicle.

2. Member State

o The member state where the vehicle has been registered.

National Safety Authority (NSA)

o The national body entrusted with the tasks regarding railway safety in accordance

with directive (2004/49/EC, 2004, p. 20).

3. European Register of Authorized Types of Vehicles (ERATV)

o A public register containing the approved vehicle types and their associated technical

data. A reference to a vehicle type in the ERATV is required from every instance of a

vehicle in the NVR if the vehicle type is specified in the ERATV.

4. Restrictions

o Any restrictions on how the vehicle may be used. The restrictions are represented

either as coded restrictions or in plain text e.g. non-coded restrictions.

5. Owner

o The owner of the vehicle.

6. Keeper

o The person or entity that, being the owner or having the right to dispose of it,

exploits a vehicle economically in a permanent manner as a means of transport and

is registered as such in the NVR. (2008/57/EC, 2008, p. 8)

7. Entity in charge of maintenance

o The entity in charge of the maintenance of the vehicle. (2008/57/EC, 2008, p. 8)

8. Withdrawal

o The date when the withdrawal took place and the withdrawal code stating the mode

of the withdrawal.

9. Member States where the vehicle is authorized

o A list of member states where the vehicle is authorized.

10. Authorization of placing in service

o All operations by which a vehicle is put into its design operating state are authorized.

The authorization states a starting time from when the authorization is valid and an

optional valid-until-time. (2008/57/EC, 2008, p. 8)

6.1.5 Rules for registering vehicles

Each Member State is responsible for that each individual vehicle is assigned an identification code,

which is stored in a NVR. Authorized persons and organizations have to be able to access the register.

52

The specification of the NVR should in particular include the definitions of the content, the functional

and technical architecture, the data format, the operating modes and rules for data input.

Each Member State should register all authorized vehicles in the NVR, with the exception that freight

wagons and passenger cars only need to be registered in the NVR where they first was taken into

service.

Vehicle registration, confirmation of registration, alteration of registration item(s) and confirmation

of the change(s) in the NVR should be done via a standard form (appendix A).

The NVR for each Member State should be computer-based. The ERA is responsible for the VVR that

all NVR should be connected to, this to make enquiries through the VVR for information stored in any

of the NVRs.

Existing vehicles should be registered in the NVR in the MS where they were originally registered.

Someone that’s independent to the railroad companies should manage the NVR. The MS should

inform the other MSs and the commission how this is organized.

The rules in the Technical Specification of Interoperability (TSI) are applicable when numbering the

vehicles in the NVR. ERA will develop a guide for application of these rules.

The registering process is in accordance with article 21 of Directive 96/48/EC.

6.1.6 The registration process for vehicles

There are a number of different ways how railroad vehicles can be registered in the ECVVR

framework and this chapter specifies them.

Application for registration

This is the entity applying for a vehicle registration and which fills in the first part of the form with all

the necessary information and then forwards it to the:

a) RE of the MS where registration is sought

b) RE of the first MS where it intends to operate for a vehicle coming from a third country.

Registering a vehicle and issuing a European Vehicle Number If it is the first registration for the vehicle, the RE concerned issues the European Vehicle number.

It is possible to have an individual registration form per vehicle, or a single form for a whole set of

vehicles of the same series.

The RE shall take reasonable steps to ensure the accuracy of the data it enters in the NVR. To this end

the RE can request information from other REs, in particular when the entity applying for registration

in a Member State is not established in that Member State.

Changing one or more registration item(s)

The entity applying for a change of its vehicle registration item(s) fills in the actual EVN (Item No 0)

(references to item numbers in this section are defined in statute (2011/107/EU, 2011)). Indicates

the new content of the modified item(s), and then forwards the form to the RE of the Member State

where the vehicle is registered.

53

Should a keeper change, it is the responsibility of the keeper currently registered to notify the RE and

the RE has to notify the new keeper of the change of registration. The former keeper is only removed

from the NVR and relieved of his responsibilities when the new keeper has acknowledged the

acceptance of keeper status.

Should an owner change, it is the responsibility of the owner currently registered to notify the RE.

Then the former owner will be removed from the NVR. The new owner may request his details to be

entered into the NVR.

Following the registration of changes, the NSA may deliver a new authorization number and in some

cases a new EVN.

Withdrawal of registration The entity applying for a withdrawal of registration ticks in the box corresponding to ‘Withdrawal’. It

then fills in the item No 10 and forwards it to the RE of any Member State where the vehicle is

registered. The RE delivers the withdrawal registration by filling in the date of withdrawal and

acknowledging the withdrawal to the said entity.

Authorization in several Member States When a vehicle already authorized and registered in one Member State is authorized in another

Member State, it needs to be registered in the NVR of the latter Member State. However, in this

case, only data related to Items 1, 2, 6, 11, 12 and 13 have to be recorded, as these data only relate

to the latter Member State.

As long as the VVR and the link with all NVRs are not fully operational, the Registration Entities

concerned shall exchange information in order to ensure that data relating to the same vehicle is

consistent.

Freight wagons and passenger cars are only registered in the NVR of the Member State where they

are first placed in service.

6.2 EC VVR in Sweden The work for a NVR in Sweden has been a work in progress for a long time and the Swedish NSA

works closely with the NVR in their daily routines, both within the organization itself but also

externally with companies within the railway sector. The Swedish NVR also contains additional

information then what specified in the specifications for the NVR (2011/107/EU). For these reasons if

the Swedish NSA is to use the standardized NVR (sNVR) they need to extend both the functionality

and the ability to work with the register and also the amount of information contained within the

register.

The Swedish NSA has developed their own NVR and it’s deeply integrated within the organization

and their work routines. The NVR is connected to the VVR through a translation engine (TE) that

makes it possible for the VVR to interact with the non-standardized NVR.

6.2.1 External Delivery Client (Swedish national naming service)

The National Vehicle Register (NVR) contains information about registered railway vehicles in

Sweden, to make this information more accessible the Swedish NSA has developed a systems-to-

systems service named “External Delivery Client” henceforth referred to as “the service”. Through

54

the service information about registered railway vehicles can be accessed through the Internet. The

intention is that the service will be connected to both the Swedish NVR and the Virtual Vehicle

Register (VVR) making it possible to get information not only about vehicles registered in Sweden but

any vehicle registered in the entire European Union. The aim with the service is to ease the workload

of the railway companies and other stakeholders, which can benefit from an automated way to

receive information from the Swedish NVR.

The service is not intended to be freely used by the public, the Swedish NSA wants to have control

over who that is allowed to access the service. How this should be achieved is not yet decided, today

the service doesn’t utilize any kind of user authentication.

The only restriction that the Swedish NSA does is that the owners of the registered vehicles are not

displayed in the information provided by the service. This is a demand from the European Railway

Agency (ERA) and the vehicle owners influenced them to do so.

Through the usage of the service it’s possible to access three types of information; (1) access

information about a specific vehicle, the information provided through the service is directly

accessed from the NVR. (2) Information about all vehicles that have had their information recently

changed in the NVR. (3) Information about different vehicle types.

The service is a SOAP3-based web service that utilizes XML4 messages for both the arguments as well

as the response back to the user, the service exposes three methods:

GetFordonsindivid

Get all vehicle individuals that satisfies the Id tag

GetChangedFordonsIndivider

Get all changed vehicle individuals changed from date

GetFordonstyper

Get all vehicle types based on designation or version

6.2.2 Rules and processes of the registration of railway vehicles in Sweden

In this chapter the Swedish registration process for railway vehicles performed by the Swedish NSA is

presented.

The Swedish NSA provides an e-service where the companies can download the registration forms

for changing and deregistration of an individual railway vehicle.

Companies applying for approval of a railroad vehicle from the NSA have to fill out a form that is

showing the characteristics required for registration.

6.2.3 The information model of the Swedish NVR

As described in the introduction to this chapter, Sweden has developed their own non-standardized

NVR, in Table 12 the mapping between the identified information objects from the NVR

specifications and the Swedish implementation of their NVR is compared.

3 Simple Object Access Protocol

4 Extensible Markup Language

55

The comparison shows that all information objects from the NVR specifications are also specified in

the Swedish NVR, the field name in the database is not always the same but the content and

meaning of the information is the same. The Swedish NVR contains more information compared to

the NVR specifications.

NVR information model information objects

Implemented Swedish NVR fields

No. Term No.5 Term/Identifiers

1 Vehicle 64 Vehicle number

2 Member State 66 Identification of the Memberstate where the vehicle has been authorised first

National Safety Authority (NSA) 67 Identification of the NSA where the vehicle has been authorised first

3 European Register of Authorized Types of Vehicles (ERATV)

75 Reference to the RRS

4 Restrictions Technical restriction related to construction

Minimum curve radius

60 Minimum curve radius

Track circuit restrictions

61 Track circuit restrictions

Speed restrictions in km/h (marked n wagons and coaches but not marked on locomotives)

8 Maximum speed, active

9 Maximum speed, at transportation

10 Maximum speed, (loaded)

11 Maximum speed (empty)

Geographical restriction

Kinematic gauge 12 Vehicle gauge

Wheel set gauge 62 Wheelset gauge

No CCS on board 83 CCS on board

ERTMS A on board 84 ERTMS A on board

B system on board 85 B system on board

Environmental restrictions

Climatic zone 63 Climatic zone

Restrictions on use included in the authorisation certificate

Time-based 91 Authorisation valid until

Condition based (distance travelled, wear etc.)

92 Condition based

5 Owner 79 Owner

6 Keeper 77 Keeper

7 Entity in charge of maintenance 80 Entity in charge of maintenance

8 Withdrawal 86 Withdrawal

9 Member States where the vehicle is authorised

87 MS where the vehicle is authorised

10 Authorisation Authorisation 88 EIN

5 The row number of the field in the excel-file describing the properties of the Swedish NVR

56

of placing in service

number

Suspension of authorisation

89 Driving ban

Date of the authorisation

90 Date of the authorisation

Authorisation valid until

91 Authorisation valid until

Table 12: Mapping between the information objects in the NVR data model and the Swedish NVR

6.2.4 Data model of the External Delivery Client XML response

To be able to analyze the data model for message sent from the External Delivery Client several of

the XML responses had to be analyzed. This was necessary because there is no XML-schema for the

XML-file that is returned from the service. Based on this analysis the information objects presented

in Figure 24 below was identified.

Figure 24: Information objects from XML responses

The Swedish implementation of the NVR contains all the required data stated in the NVR

specifications, it also contains additional data. For this reason a separated comparison of both the

NVR specifications and the Swedish NVR with the structure of the XML is not necessary and instead a

combined comparison is done in Table 13.

No. Information objects present in both NVR specifications and the Swedish NVR

XML response from the External Delivery Client

1 Vehicle European Vehicle Number

2 Member State Member State

National Safety Authority (NSA)

3 European Register of Authorized Types of Vehicles (ERATV)

Vehicle type

57

4 Restrictions Vehicle instance - Vehicle attributes Vehicle type - Vehicle type attributes

5 Owner Owner

6 Keeper Keeper

7 Entity in charge of maintenance Company in charge of maintenance

8 Withdrawal Deregistration

9 Member States where the vehicle is authorized Foreign states where the vehicle is authorized

10 Authorization of placing in service Authorization of placing in service

Only present in the Swedish NVR

Type designation/Version Vehicle Type - Type designation Vehicle Type - Version

Vehicle category Vehicle Type - Vehicle category

Vehicle subcategory Vehicle Type - Vehicle subcategory Table 13: Comparison between the Swedish NVR and the External Delivery Client XML response

The comparison shows that the information in the XML response contains all the information

described in the NVR specifications, with the exception that it doesn’t contain the Nation Security

Authority (NSA). The XML-file also use different terms for the information objects. First of all the

naming is in Swedish, but the semantic meaning is also different in some cases e.g. (7) entity

compared to company, (8) deregistration with withdrawal, (9) member state with foreign state. The

link to the ERATV is replaced with the actual technical data for the specific Vehicle type associated

with the Vehicle (3). The XML-response don’t always display the owner of the vehicle and the

deregistration tag.

6.3 Evaluation of the EC VVR e-infrastructure In this chapter the Swedish implementation of the EC VVR e-infrastructure will be evaluated against

the statutes.

6.3.1 Evaluation of the Swedish NVR

Sweden has developed their own NVR and by implementing a TE to communicate with the VVR they

have done so in accordance with the statutes. As shown in Table 12 the Swedish NVR contains all the

required information stated in the NVR specifications and also additional information. The Swedish

NSA has implemented their own NVR, because of how the Swedish NSA works with the NVR within

their organization, the standardized NVR would not be sufficient.

The NSA has also followed the statutes to implement the NVR with the requested connection to the

VVR. Their decision to develop their own customized NVR, and not to use the sNVR is also correct.

6.3.2 Evaluation of the vehicle registration process

The vehicle registration process is form based and the forms is in accordance with directive

1996/48/EG, 2001/16/EG and the Swedish railroad law.

6.3.3 Evaluation of the External Delivery Client

Authentication and authorization

There is no authentication technique implemented in the service and there is also no strategy on

who that should be allowed to utilize the service and what they are allowed to do with the

information from it.

58

The directive 2011/107/EU defines the user roles and their access rights in the EC VVR infrastructure.

The Swedish NSA should use these specifications to decide how the users should be authorized to

use the service. Though in this case only read access rights will apply. With the defined users, the

Swedish NSA could form an agreement for authorization to the service and how the information

could be used by the users, the agreement should be a written contract.

XML-schema The XML response that is delivered from the service doesn’t have any XML-schema associated with

it. Without the XML-schema it’s impossible to know the exact content of the XML-response and users

are not able to interpret the information properly.

Missing vehicle numbers Some vehicle numbers does not match any entry in the NVR. The response-status information in the

XML response contains an error message informing that the service failed to find any information

associated with the vehicle number. However, it is not clear why the search fails, is the vehicle

number not valid? Is the vehicle number not registered? Is the vehicle registered in another member

state? It’s not defined how the error message should be interpreted.

6.3.4 EDC usage evaluation

XML-arguments

The service is developed in such a way that the arguments for the exposed methods is XML

messages, how these messages should be constructed is unknown for users and therefore they are

not capable of utilizing the service properly. Today this works as a way of controlling the access to

the service, because it’s not intended to be used freely by anyone, but this is not a formal way of

restricting the usage of the service. If the XML-messages are known a user is capable of using the

service with no restriction and with no required authentication.

SOAP suggestions

It could be argued that the service is developed in a non-user-friendly way by how it’s utilizing XML

messages. SOAP is a protocol designed for being able to utilize both simple and compound datatypes.

Simple types include string, float, integer, enumeration, etc. Compound types are formed from

simple types, which can be used for representing an object type, for example a vehicle (Siddiqui,

2002). One of the principles of SOA architecture is discoverability, i.e. information about what the

web service does and how it is used, this information should be provided from the service itself by

for example using the Web Service Description Language (WSDL) (SOA Principles). By making the

service discoverable it makes the service more independent and easier to use for new users because

the service itself describes its functionality and how to access it.

To increase the usability of the External Delivery Client its exposed methods should utilize this

principle e.g. the method GetFordonIndivid could take the simple type integer as a parameter (a

national vehicle number) and returned a compound type representing the vehicle. If the service is

developed in this way it both gets easier for new users to use and interpret the service but also to

ease the work for the user by not being forced to parse the returning XML-message.

Performance issues

The response time of the service has been slow. The responses have been slow both when checking a

single Nation Vehicle Numbers when the initial loading time can be long (over 10 seconds), and when

59

a larger amount of vehicle numbers. For the Swedish NSA to an interest in providing a high quality

service that could sustain a big workload that demands high response times they need to see a direct

benefit for the parties within the railway industry.

6.4 Conclusion

Swedish NVR

The Swedish implementation of the NVR has been evaluated against the directives from EU

specifying the structure of the NVR. Sweden has developed their own implementation of the NVR, it

contains all the specified information is connected to the VVR using a TE, and this is all done in line

with the status.

Vehicle registration process

The railway vehicle registration process of the Swedish NSA is in accordance with the statutes. There

is no obligation to RFID-tag a railway vehicle neither in the statutes nor in the registration process by

the Swedish NSA. This is a problem because the amount of tagged vehicles is low and the value of the

e-infrastructure is dependent of the number of tagged vehicles.

External Delivery Client

The initial statement was that the VVR in the EC VVR infrastructure could work as an ONS for the

European railway sector. In this chapter the service, External Delivery Client, developed by the

Swedish NSA has been evaluated against the EC VVR specifications. From the evaluation of the

service, some problems have been recognized; to address the stated problems the following changes

to the service is suggested:

Formalize a way of properly authorizing and authenticating users

Develop and make available XML-schemas for both the XML response as well as the XML

parameters of the service

The scope of the service have to be defined

These improvements have to be implemented in order to say that the EDC service is in line with the

statues of the VVR. However, the EDC service does only work for searching for railway vehicles in

Sweden.

60

7 Specifications for the Swedish railway sector e-infrastructure The evaluation shows that there exist pilot projects within the EPCIS infrastructure as well as the EC

VVR infrastructure that has given some positive results. With these projects some problems have also

been identified. In section 7.1 we will present these problems as requirements for making a well-

designed e-infrastructure, and in 7.2 we will provide advice how these requirements could be met.

7.1 Requirements

R 1. Company prefix

The EPCIS specifications prescribe that the company prefix part of an EPC using the GIAI encoding

scheme (the GCP) should be the managing entity of the EPC. Today the owner of the vehicle is

assigned to be that managing entity. However there are a number of ambiguities that come with

such a solution. It becomes unclear who is the entity that really is responsible for the vehicle

identifier. The owner of the physical vehicle is not responsible for the chosen identifier (EVN) the NSA

is. Assigning the GCP to the owner would also make the identifier instable. For example if a vehicle

changes keeper should the company prefix then be changed?

R 2. Tagging Cars

The value of an e-infrastructure for capturing events about train vehicles and train compositions is

based on the number of vehicles that has been tagged. A major problem today is that only a limited

number of vehicles are tagged (see 1.1). The tagging of a vehicle implies a cost, and to tag an already

used vehicle is an even larger cost than for a new vehicle. A problem is also that the statutes do not

prescribe that the vehicles should be tagged (see 1.1). According to the statutes the visibility of the

identifier should be accomplished by painting the identifier on the vehicle.

R 3. Reader location and location identifiers

There is a need for placing RFID-readers on all strategically locations of the railway to make the

coverage of the vehicle passages as comprehensive as possible. This will increase the usefulness of

the infrastructure. These locations are of great importance and a stable location identifier needs to

be designed. This location must also be related to the railway topology.

R 4. Detector matching

There is no interoperability between other detectors and sensors that already exist on the

railroad (2.2.2) and the EPCIS infrastructure. How the EPCIS events should be combined with the

detector information is not clear, but the combination of these different types of detector readings

will provide useful information.

R 5. Aggregation Event, Structure of EPCIS events

The aggregation event has been chosen as the EPCIS event to report vehicle passages. The event

structure allows for connecting a number of events with each other to form a train composition

passages. But the aggregation event is not used as intended by the EPCIS specifications. As the event

now is structured it uses a lot of redundant information and becomes unnecessary large in size.

61

R 6. Transmission of EPCIS events, Push, Pull and Subscribe

One of the most important factors of the infrastructure is the capability to convey the EPCIS events

to different organizations with system-to-system services. To make the infrastructure useful for the

operational service provision must be improved. There are some different conveying techniques that

should be implemented to increase the usefulness of the infrastructure: push for direct access of

data, pull to request a subset of data and subscribe to get data when some specific conditions are

met.

R 7. Location master data

There is a need for retrieving master data about locations in a better way. This master data should be

the responsibility of the Swedish transport administration to store, update and convey.

R 8. Train-compositions master data

The Opera system maintained by the STA contains master data about train-compositions. There is a

need for retrieving this data from the Opera system.

R 9. Swedish VVR, the EDC service

To make the EDC service fully operable as a Swedish VVR a proper way of authorizing and

authenticating users is required. Also the service needs better documentation to increase its

usability.

7.2 Advice Based on the requirements presented in the previous section we will in this section provide advice

how to further develop the e-infrastructure.

A 1. The GCP of the vehicle identifier EPC should be set to the GCP of the Swedish NSA

It is the Swedish NSA, which is the responsible entity in Sweden, and thus it should be the GS1

Company Prefix (GCP) of the Swedish NSA that should be used as the company prefix in the

identifier. It is very important that there is an independent authority, which can guarantee the

validity of the EPC’s identifying railway vehicles and also the correctness of the information

associated with those vehicles. This should fulfill requirement R 1.

A 2. A strategy for tagging railway vehicles should be developed

There is a need for a strategy for tagging railway vehicles. To accomplish this, the statutes should

prescribe that it to be mandatory for railway companies to tag their vehicles as a part of the

registration process in a similar way that has been deployed in the USA and Russia. However such a

strategy should also encompass the advantages that the railway operators should get from such an

effort. This would address requirement R 2

62

A 3. New registration routines for railway vehicles

A new registration routine should be developed that should encompass RFID registration. This

routine should prescribe that the registration of the vehicle in the NVR would imply an obligation for

the Keeper to tag the vehicle. Instead of painting the number of the vehicle, a RFID tag would make

the vehicle more visible in the railroad system. With the NSA’s as the managing entity for the EPC’s

and the responsible entity for the registration and authorization of railway vehicles they are certainly

in a position to change the registration routines to include EPC specific registration routines. This

would address requirement R 2

A 4. Strategy for reader location and location coding

A strategy for reader location should be developed. This strategy must encompass a plan for where

the readers should be placed in order to take the full advantage of the readers. The readers have to

be placed at important links and nodes in the railroad network and they must be placed so that it is

possible to match the readings from the readers with the information that is generated by other

technical sensor equipment at the railroad. The locations of the readers have to be identified by a

location code and this location code has to be instantiated and controlled in a strict manner. It is

important that the location is considered as an own information object in the system. This read point

must be related to the topology of the railroad network (in the BIS-system) and the RFID-equipment.

These locations can be based on already identified locations in the railroad network but it should also

be possible to create new locations. The question if this location coding can be managed within the

BIS system or if this should be an application of its own is not clear at this stage. The location of the

readers should also be mapped into the EPCIS event using ReadPointID field and the SGLN coding

scheme. The location code should be mapped into the LocationReference part of the SGLN and the

CompanyPrefix should be the GCP assigned to the STA. This would address requirement R 3.

A 5. Routines for location coding

It is important that strict routines for registering Location Codes are developed. When new reader

equipment is deployed this has to be registered. This information has to be related to the railroad

network topology and the reader location, and it is important that the identifier of a location at the

railroad is separated from the reader equipment to avoid the descriptive identifier problem. This

would address requirement R 3.

A 6. Structure of EPCIS event reporting on train-compositions at passages

The AggregationEvent as described in 0 is poorly structured and the following changes are proposed:

Instead of using several AggregationEvents for a train composition it is suggested to use just

one and instead extend the childEPCs-tag to contain all the EPC’s identifying the vehicles in

the train composition.

The action-tag should be ADD instead of the current OBSERVE. When EPC’s are aggregated to

a parent for the first time ADD should be used as the action. If OBSERVE is used the parentID-

tag could be omitted from the event. This suggestion could be ignored if it’s not possible to

know the parentID in this context, then OBSERVE should be used.

63

These changes would fulfill requirement R 5. Suggested structure of the AggregationEvent:

A 7. Transmission of EPCIS events, Push, Pull and Subscribe

The implemented services in the Fosstrak framework could be used to easily get the required service

platform in production. This implementation would fulfill requirement R 6.

A 8. Location and train-composition master data

The query operations for different kinds of master data should preferable be handled with a gateway

which users can query for different kinds of master data. The STA needs to investigate if there

current systems are capable of being integrated with such a gateway. This advice encompasses both

requirement R 7 and R 8.

A 9. The EDC Service

The following changes to the EDC service are suggested: (1) implement a proper way of authorizing

and authenticating users, (2) develop and provide XML-schemas to the service users. These changes

would fulfill requirement R 9.

<ns0:EPCISDocument schemaVersion="1.0" creationDate="2011-06-21T09:37:38.8723177+02:00" xmlns:ns0="urn:epcglobal:epcis:xsd:1" xmlns:bv="http://xsd.banverket.se/LA/EPCISExtension.xsd" xmlns:epcglobal="urn:epcglobal:xsd:1" xmlns:sbdh="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader"> <EPCISBody> <EventList> <AggregationEvent> <eventTime>2011-06-21T09:37:38.8723177+02:00</eventTime> <eventTimeZoneOffset>+02:00</eventTimeZoneOffset> <parentID>bcb54b67-d47c-44b2-9246-d57f9f5f6257</parentID> <!-- ParentId the identifier for a train composition at a passage --> <childEPCs> <epc>urn:epc:id:giai:735003433.1317445522194</epc> <epc>urn:epc:id:giai:735003433.1317445522087</epc> <epc>urn:epc:id:giai:735003433.1317445521535</epc> <epc>urn:epc:id:giai:735003433.1317445523614</epc> <!-- A set of EPC in the train composition --> </childEPCs> <action>ADD</action> <!-- ADD is used to create an aggregation between the child EPC's and the parentId --> <bizStep>PassageO</bizStep> <readPoint> <id>urn:735999271.0001.1243</id> </readPoint> </AggregationEvent> </EventList> </EPCISBody> </ns0:EPCISDocument>

64

8 Advice evaluation In this chapter an evaluation of the advice given in the last chapter will be done against the design

principles by Hanseth & Lyytinen (2004) and Eriksson & Ågerfalk (2010).

8.1 Design identifiers based on information infrastructural aspects The EPC vehicle identifier is based on the GIAI EPC schema, identifiers created from this schema has

an issuing authority, the GCP, which is responsible for the identifier. Identifiers created from the GIAI

schema follows a pattern which ensures their uniqueness and stability which makes the identifier

comply with the design principles from Eriksson & Ågerfalk (2010).

The asset reference in the EPC vehicle identifier is an EVN. The EVN itself does not comply with the

design principles because it contains descriptive information about physical attributes of the railway

vehicle. When those physical attributes changes the EVN needs to be updated and in turn the EPC

identifier needs to be updated, this is an effect of the descriptive identifier problem (described in

chapter 0). This makes the EVN identifier less stable and in turn makes the EPC vehicle identifier to

be less stable.

8.2 Select appropriate identifiers for important institutional objects The GIAI ECP schema specifications are intended for identifying fixed assets for an organization and

not explicit railway vehicles. It could be discussed how suitable the identifier is for railway vehicles.

How could a railway company differentiate their inventory such as chairs, desk, computers etc. from

their railway vehicles? Should even the railway vehicles be categorized with such types of office

inventories? These issues points out the need for a Global Vehicle Identifier (GVI) to distinguish

railway vehicles from other types of assets.

In the previous chapter we showed that the EVN suffered from the descriptive identifier problem

that could make the EPC vehicle identifier less stable. Even though the EVN number could be

somewhat unstable it is the real identifier for railway vehicles in the EU. There are though immediate

benefits of using the EVN as the asset number, as being able to query registers like the NVR for

additional information (master data) about the railway vehicle. The amount of changed EVN’s in

Sweden in a year is approximately 5 numbers, this makes the upsides of using the EVN as the asset

number outweighs the instability it brings to the EPC identifier.

The choice of organization that will have its GCP as the GCP for the vehicle identifier could be

discussed. According to the specifications for the GIAI EPC schema the organization that is the owner

of the physical object should have the position as the GCP. If the owner is to be the GCP of the

identifier this will cause problems when ownership of the vehicle is changed because then the

identifier needs to be updated to include the new owners GCP for the identifier to make sense. This

will in turn make the identifier less stable. Choosing the NSA as the GCP for the vehicle identifier

corresponds to design principle one to avoid the descriptive identifier problem. This is why advice A1

is important for the design of the vehicle identifier.

We have emphasized on the importance to use the NSA as the GCP of the vehicle identifier even

though the GCP of the owner would confirm better with the specifications for the GIAI EPC schema.

The owner would be a better choice if the identifier only was to identify the physical railway vehicle,

but that is not the case. The institutional object that is being identified is “An European authorized

65

railway vehicle” and the owner of that object is the issuing NSA and therefore the choice of the NSA

as the GCP is correct.

8.3 Authorized institutional control systems for identifiers Two control systems are involved in the assigning of the vehicle identifier. The first one is that the

identifier is based on the GIAI EPC schema, which is controlled through GS1 by distributing GCP’s to

organizations that in turn can create EPC’s. The identifiers is ensured to be universal unique because

of the central responsibility at GS1 to assign and distribute GCP’s to organizations. The second one is

that the NSA’s of the EU member nations have standardized routines for handling the registration act

for railway vehicles and the assigning of EVN’s to those vehicles.

By using the GCP of the NSA’s in the EPC vehicle identifier and then also making them responsible for

the asset number in the EPC will make the NSA’s responsible for the EPC vehicle identifier. The

responsibility implies the creating, assigning and keeping of register with the identifiers. The NSA’s

also needs to develop routines to handle the mapping between the EVN and the EPC identifiers. The

mapping between the identifiers will be the core of enforcing interoperability between two different

infrastructures.

8.4 Build upon existing installed bases The creation of this new infrastructure in the railway sector has utilized the already installed base.

The NVR and EC VVR is part of the installed base which is a complete infrastructure that handles

information, identifiers, routines and rules of railway vehicles. By utilizing the NVR and EC VVR

infrastructure benefits such as having stable routines for creating, assigning and identify railway

vehicles. To being able to use this infrastructure there is a need to realize the importance of the

identifier for vehicles, the EVN’s. The connection with the new infrastructure is to keep the identifier

for the same physical railway vehicle from the new infrastructure (EPC) mapped with the EVN. This

could either be done by embedding the EVN within the EPC or to keep a mapping table that maps the

identifiers to each other.

Another part of the installed base is the EPCGlobal architecture framework with its standards,

implementations, routines and rules for an infrastructure within the logistic sector. By using this

already established architecture comes with benefits such as not having to developing a new way of

creating stable identifiers, encode those identifiers to RFID tags, establish a standard to read

information from the tags and convey the read events. This and much more is already provided

within the EPCGlobal architecture. The EPCGlobal architecture is globally widespread within the

logistic sector making future integration with the logistic sector at large instead of just the railway

sector possible due to a common standard.

8.5 Modularize the Information Infrastructure Hanseth & Lyytinen (2004) propose a design guideline to their fifth design principle (see 3.3) saying

that when creating a new infrastructure divide the infrastructure recursively into independent

transportation, service and application infrastructures. Following this guideline should enhance the

layering and modularity of the infrastructure. The EPCglobal architecture consists of a set of

standards (see Figure 9); these standards are separated because they are dedicated to different parts

of the architecture. The standards are clearly segregated into the transportation, service and

application infrastructure. The standards that we have evaluated in this paper are TDS, EPCIS and

66

ONS and they correspond respectively to transportation, application and service infrastructures.

These standards and the rest of the EPCGlobal architecture (even tough not evaluated in this paper)

follows this separation of concerns philosophy and therefore also conforms to the fifth design

principle by Hanseth & Lyytinen (2004).

Gateways are used for several reasons and could be used to either combine different standards even

across infrastructural boarders or combine information from different data-sources to get more

valuable information. Gateways are vital components in the making of the new railway infrastructure

and in Figure 4 and Figure 5 such gateways are presented. Those gateways are working to combine

data from different standards and between different infrastructures to being able to deliver useful

information.

The usage of gateways emphases on the importance of enabling interoperability between the

infrastructures, it enables data from both infrastructures to be combined into valuable and useful

information for the railway sector. Gateways also helps keeping elements of the infrastructure as

simple as possible and making more complex systems/gateways when needed, this conforms to the

fourth design principle by Hanseth & Lyytinen (2004).

67

9 Conclusion The work of developing the e-infrastructure has progressed during the work of this thesis and the

development seems promising. The project and the e-infrastructure are still implemented in a small

scale but this will scale up during 2012. There has been a process that has lead up to the usage of the

EPCGlobal standards (see 1.1) and the choices and decisions during this process have been well

grounded. In these types of projects there are always some problematic issues and in this thesis

some of those issues have been discovered. Even though there are some issues that need to be

resolved the benefits of using an established standard like the EPCGlobal is far greater. Some of

these issues concern the implementation of the standard and are evaluated against the EPCGlobal

standards, the following advice is provided from the evaluation.

A 6. Structure of EPCIS event reporting on train-compositions at passages

A 7. Transmission of EPCIS events, Push, Pull and Subscribe

A 8. Location and train-composition master data

The system-to-system service developed by the Swedish NSA has been evaluated against the statutes

defining the EC VVR framework, the following advice was given.

A 9. The EDC Service

In the evaluation of the e-infrastructure some problematic and interesting design issues has been

discovered. These issues have been evaluated against the design principles for identifiers proposed

by Eriksson & Ågerfalk (2010), and the design principles for designing e-infrastructures at large by

Hanseth & Lyytinen (2004). These design principles has proven most useful in both the evaluation of

the e-infrastructures as well as for the given advice.

The design principles from Eriksson & Ågerfalk (2010) gave a stable ground for evaluating the choices

of identifiers in the e-infrastructure. In this thesis we have continued to argue for the importance of

identifiers to be more than something purely technical. An identifier needs to be stable and to be

stable it needs to be well designed, be based on the correct institutional meaning and as well have a

responsible entity that supports routines for creating, issuing and maintaining the identifier. With the

design principles of Eriksson & Ågerfalk (2010) as a basis the following advices is proposed in the

thesis to the Swedish transport administration and the Swedish national security agency.

A 1. The GCP of the vehicle identifier EPC should be set to the GCP of the Swedish NSA

A 2. A strategy for tagging railway vehicles should be developed

A 3. New registration routines for railway vehicles

A 4. Strategy for reader location and location coding

A 5. Routines for location coding

The design principles of Hanseth & Lyytinen (2004) have been most useful in the evaluation of the e-

infrastructure as a whole. The principles of building upon an existing installed base and to modularize

the e-infrastructure are the principles that aided the most in the evaluation. In this project the STA is

creating a new support infrastructure for the railroad sector for which Hanseth & Lyytinen (2004)

don’t give any advice or guidelines for doing, except that it should be avoided and instead utilize

existing support infrastructures.

68

The STA is currently benefiting from using an already established standard, the EPCGlobal standards,

and the open source implementation in Fosstrak. To combine the EPCGlobal standards with the EC

VVR/NVR e-infrastructure provides a stable identification system for the e-infrastructure. The

EPCGlobal standards are separated into different layers and the standards is keeping a separation of

concerns between the different standards. To modularize the e-infrastructure through the usage of

gateways and the EPCGlobal standards the core structure of the e-infrastructure is well designed and

provides a foundation for growth and evolvement of the e-infrastructure.

Identification and identifiers has a crucial role within e-infrastructures and we suggest an extension

to the application, service and transport infrastructure e-infrastructure model by Hanseth & Lyytinen

(2004) (see Figure 7) to include an identification infrastructure (Figure 25 below). Hanseth & Lyytinen

(2004) includes identification within the service infrastructure and not as an independent part of the

model and the structure of e-infrastructures. The problem with doing so is that the importance of

identification in e-infrastructures is not emphasized enough. This part of e-infrastructures becomes

even more important in the context of the Internet of Things where identification has such a vital

role. With more emphasis on the importance of identification the importance of designing stable

identifiers increases. Registers of such identifiers are what makes up the identification infrastructure,

an example is the EC VVR infrastructure for identifying European railway vehicles.

identification infrastructure

application infrastructure

service infrastructure transport infrastructure

Figure 25: Proposed structure of e-infrastructure

There is a need for additional design principles that encompass the new aspects of e-infrastructure

development that has come with the introduction of the Internet of Things. The design principles

need to consider the real world of physical things and the behavior of such things. When physical

things are equipped with RFID tags there needs to be RFID-readers placed at important locations to

be able to interact and/or capture the location of the object. There is a lot of important design

choices involved in both the placing of the readers as well as to handle the locations themselves

where such technical equipment is placed and this is such an area where current design principles

are not sufficient.

EPCGlobal standards are intended for logistics and not explicitly the transportation sector. Even

though it’s the standard of choice by the STA and it has been proven sufficient in most areas there

69

are some limitations in others. One limitation is that there is no way for an organization to

differentiate a railway vehicle from other types of fixed assets identified by the GIAI EPC schema. We

propose that a Global Vehicle Identifier (GVI) schema is to be developed and dedicated to the usage

with vehicles. The Global Vehicle Identifier should have the following structure:

urn:epc:id:gvi:IssuingAuthority.IndividualVehicleReference

The object that is being identified with this schema is an “authorized vehicle” with its issuing

authority as company prefix. The issuing authority is an agency that has the right to authorize a

vehicle’s placing in service.

10 Further Research

There are few studies that have analyzed the creation of new support infrastructures for the Internet

of Things. This project presents a unique opportunity to observe the process of creating a new

support infrastructure for the Internet of Things from the very beginning. It’s extremely important for

the success of any e-infrastructure that the underlying support infrastructure is successfully

designed. However, there are few studies that have had the opportunity to study when such a new

infrastructure is actually developed and have had the opportunity to suggest how the infrastructure

should be developed. We therefore propose that further research should investigate what design

decisions make a support infrastructure successful and to formalize guidelines for creation of support

infrastructures for the Internet of Things.

70

Table of Figures Figure 1 -RFID-reader and Axle counter/wheel sensor ........................................................................... 6

Figure 2 - RFID tag position on wagon..................................................................................................... 7

Figure 3 - Structure of RFID-tag ............................................................................................................... 7

Figure 4: Structure of the data exchange in the RFID system in the STA ................................................ 8

Figure 5: Structure of data exchange for vehicle identification .............................................................. 9

Figure 6 - Non RFID Wayside Monitoring System/Detectors .................................................................. 9

Figure 7: The structure of infrastructure (Hanseth & Lyttinen, 2004, p. 218) ...................................... 14

Figure 8: Relationship between institutional objects and physical things ............................................ 16

Figure 9: The EPCglobal architecture framework .................................................................................. 21

Figure 10: Example URIs and their component parts ............................................................................ 22

Figure 11: Different structures of an EPC through the layers of the EPCGlobal Architecture .............. 25

Figure 12: GS1 Sweden AB is identified by a GLN EPC .......................................................................... 27

Figure 13: The Swedish Transport Administration (“Trafikverket”) is identified by a GLN EPC ............ 27

Figure 14: Core events of the EPCIS (GS1, 2007, pp. 28, 29) ................................................................. 31

Figure 15: Architecture of EPCIS service layer ...................................................................................... 37

Figure 16: The EPCIS Capture Interface ................................................................................................. 37

Figure 17: The EPCIS Query Control Interface ....................................................................................... 38

Figure 18: The EPCIS Query Callback Interface ..................................................................................... 39

Figure 19: Information about Green Cargo from GEPIR........................................................................ 40

Figure 20: Information about Swedish transport administration from GEPIR ...................................... 41

Figure 21: EC VVR Architecture ............................................................................................................. 47

Figure 22: ECVVR architecture (with sNVR and NVR/TE) ...................................................................... 48

Figure 23: National Vehicle Register data model .................................................................................. 50

Figure 24: Information objects from XML responses ............................................................................ 56

Figure 25: Proposed structure of e-infrastructure ................................................................................ 68

71

References (n.d.). Retrieved December 8, 2011, from Fosstrak, RFID Software platform: http://www.fosstrak.org/

96/48/EC. (1996). Official Journal of the European Union, 6-24.

2001/16/EC. (2001). Official Journal of the European Union, 1-27.

2004/49/EC. (2004). Official Journal of the European Union, 16-39.

2004/49/EC. (2004). Official Journal of the European Union, 16-39.

2004/50/EC. (2004). Official Journal of the European Union, 40-57.

2006/920/EC. (2006). Official Journal of the European Union, 1-160.

2007/756/EC. (2007). Official Journal of the European Union, 30-51.

2007/756/EC. (2007). Official Journal of the European Union, 30-51.

2008/57/EC. (2008). Official Journal of the European Union, 1-45.

Internet of Things - An action plan for Europe. (2009, June 18). Retrieved December 7, 2011, from

ec.europa.eu/information_society/policy/rfid/documents/commiot2009.pdf

2011/107/EU. (2011). Official Journal of the European Union, 33-54.

Auto-ID Center. (2002, May). Retrieved December 7, 2011, from

http://www.ifm.eng.cam.ac.uk/automation/documents/centerguide.pdf

Auto-ID Labs, History. (n.d.). Retrieved December 7, 2011, from http://www.autoidlabs.org.uk/

Auto-ID Labs, Publications. (n.d.). Retrieved December 7, 2011, from

http://www.autoidlabs.org/publications/page.html

Berners-Lee, T., Fielding, R. T., & Masinter, L. (2005, January). Uniform Resource Identifier (URI) :

Generic Syntax.

Berners-Lee, T., Masinter, L., & M., M. (1994, December). Uniform Resource Locators (URL).

Bowker, G. C., & Star, S. L. (1999). Sorting Things Out : Classification and its Consequences.

Cambridge, Massachusetts: MIT Press.

EPC Global. (2010, August 18). EPC Tag Data Standard Version 1.5.

Eriksson, O., & Ågerfalk, P. J. (2010). Rethinking the Meaning of Identifiers in Information

Infrastructures. Journal of the Association for Information Systems, 433-454.

GS1. (2007, September 21). EPC Information Services (EPCIS) Version 1.0.1 Specification.

GS1. (2011). GS1 - EPCGlobal About. Retrieved November 08, 2011, from

http://www.gs1.org/epcglobal/about

72

GS1. (2011). GS1 - Overview. Retrieved November 08, 2011, from

http://www.gs1.org/about/overview

GS1. (2011). GS1 - Products & Solutions. Retrieved November 08, 2011, from

http://www.gs1.org/productssolutions

GS1. (2011). GS1 Company Prefix. Retrieved November 09, 2011, from

http://www.gs1.org/barcodes/technical/company_prefix

GS1. (2011). Implementation. Retrieved November 09, 2011, from

http://www.gs1.org/barcodes/implementation

GS1. (2011). Prefix List. Retrieved November 09, 2011, from GS1:

http://www.gs1.org/barcodes/support/prefix_list

Hanseth, O., & Lyttinen, K. (2004). Theorizing about the Design of Information Infrastructures: Design

Kernel Theories and Principles. Sprouts: Working Papers on Information Environments,

Systems and Organizations, 207-241.

Hanseth, O., & Lyytinen, K. (2010). Design theory for dynamic complexity in information

infrastructures: the case of building internet. Journal of Information Technology, 1-19.

Moats, R. (1997, May). URN Syntax.

Siddiqui, B. (2002, Mars 1). Deploying web services with WSDL, Part 2: Simple Object Access Protocol

(SOAP). Retrieved December 2, 2011, from

https://www.ibm.com/developerworks/library/ws-intwsdl2/

soaprinciples.com. (n.d.). SOA Principles. Retrieved December 2, 2011, from Service Discoverability:

http://www.soaprinciples.com/service_discoverability.php

Swedish Transport Administration, About us. (n.d.). Retrieved December 8, 2011, from

http://www.transportstyrelsen.se/en/About-us/

73

Appendix A – Standard form for registration

74

Appendix A – Standard form for registration

75

Appendix A – Standard form for registration