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