GS1 Railway Visibility Standard

Class 5 - GS1 Railway
Internet of Trains
CS632/SEP564, Fall 2018
Daeyoung Kim
Professor, School of Computing, KAIST
• kimd@kaist.ac.kr, http://oliot.org, http://autoidlab.kaist.ac.kr, http://resl.kaist.ac.kr http://autoidlabs.org http://gs1.org

Introduction
Motivation & challenge
New GS1 application standard for visibility in rail
GS1 EPCIS for Rail Vehicle Visibility Application Standard

© Auto-ID Lab Korea / KAIST
Slide 3
Introduction
• Problem
• Due to limited visibility and information about rail vehicles, it’s
difficult for rail operators to plan and meet customer demands for
timely deliveries and updates.

Slide 4
Introduction
• Objective
• Provides roadmap for rail stakeholders to gain visibility of rolling
stock and access to real-time information

Slide 5
Introduction
• The standard provides significant business benefits for all
players
• Improved safety
• Facilitation of preventative maintenance
• Reduced environmental impact of transport
• Improved customer service
• Greater process efficiencies
• Reduced costs

Slide 7
Rail Vehicle Visibility
• Business need
• The needs for information sharing:
• A need for tracking of vehicles as they travel within countries and across different countries
• A need to associate the vehicle data with the Wayside Train Monitoring System (WTMS) data
about vehicles and vehicle components to enhance preventive maintenance
• The use of RFID for railway vehicles becomes more and more
popular. -> More applications for vehicle and train visibility
information will emerge.
• These two applications are the basis for the initial EPCIS application
in rail.

Slide 8
• Asset tracking applications
• Normal operative functions where the location of specific vehicles
needs to be known
• Vehicle level management
• Tracking the location and status of each vehicle as they travel
• Independent of the train
• Potential future applications:
• Real-time cargo tracking
• Estimating the vehicle distance travelled for planning preventive maintenance
• Planning vehicle availability

Slide 9
• Wayside Train Monitoring System (WTMS)
• An integrated system of measurement devices that monitor the
condition of rolling stock travelling on the railway tracks
• Reduce accidents, enable preventive maintenance and improving rail
system reliability
• Typical WTMS device types:
• Hot Axle-Box Detectors (HABD) or hot-box detectors
• Wheel impact load detectors (WILD)
• Acoustic Axle Bearing Monitoring (AABM)
• Automatic pantograph monitoring systems (APMS)
• RFID allows for automatic collection of all measurement results
and creating statistical data of measurement results per vehicle.
• Applying standard EPC/RFID protocols will facilitate the exchange
of data across WTMS systems and between railway operators.

Slide 10
• RFID enabled Automatic Vehicle Identification (AVI) systems
• Fixed readers and wheel sensors (at trackside)
• The fixed trackside readers identify the vehicles of the passing train.
• Identify all tagged vehicles and their order in the train
• Detect the presence of vehicles with missing or broken tags and
their relative location in the train
• Important for the WTMS use case, since it enables the measurement results to
be linked to the correct vehicles in a train set
• Determine the travel direction, the orientation, axle count, speed,
and length of each vehicle
• Enable train level information exchanges
• Ex) A train entering or leaving a yard and the composition/formation of the
train

Slide 11
• RFID enabled Automatic Vehicle Identification (AVI) systems
Fixed trackside RFID configuration

Slide 12
• Train Management System (TMS)
• A system used to control railway operations
• Detect and control movement of trains on a track
• The information from the TMS can be used to generate additional
event data.
• Ex) The train entering or leaving an area can be deduced by combining data
from a TMS and data from previously read points provided by the AVI system.

Slide 14
Vehicle Identification
• Vehicle identification with “master” GIAI
• Identify each rail vehicle as an asset
• EPC URI is used to represent rail vehicles which are included in
EPCIS events.
• Ex) urn:epc:id:giai:4012345.98765432198765432
• Unambiguously determine static information about the rail vehicle
• Rail vehicle type, axle count, vehicle owner, etc.
• Communicate information as master data
• Not physical, deduced by proxy GIAI

Slide 15
• AIDC device identification with “proxy” GIAI
• Multiple EPC/RFID tags
• to enable the automatic identification of the side or end of the wagon
• Placing two tags on opposite sides of the wagon at opposing corners
• Ex) Vehicle end/side indicator as per GS1 in Europe’s “RFID in Rail” guideline
• Vehicle orientation can be inferred from the identity of the tag
observed.

Slide 16
• AIDC device identification with “proxy” GIAI
• Each of these tags is identified by a unique GIAI
• Ex) tag 1 of 2: urn:epc:tag:giai-96:1.4012345.18765432198765432
tag 2 of 2: urn:epc:tag:giai-96:1.4012345.28765432198765432
• These “device” GIAIs serve as “proxy” representation
Rail vehicle with multiple tags - top views Rail vehicle with multiple tags - side
views

Read Point and Business
Location Identification
How locations can be identified in a rail context

Slide 18
Read Point and Business Location
Identification
• Read Points
• A location that is meant to identify the most specific place at which
an EPCIS event took place
• Identified using the SGLN
• Unique Read Point – Unambiguously determine the read point’s
physical location, line name/ID, and track name/ID
Example of Read Point

Slide 19
Identification
• Identifying a track using EPC/RFID
• A single track: A one-to-one relation between reader and read point
• Multiple tracks: apply separate read points with distinct SGLNs for
each track
AVI system monitoring a single track AVI system monitoring multiple tracks

Slide 20
Identification
• Business location
• The location where the rail vehicle is assumed to be following the
event
• Assumed to be valid until superseded by the business location of a
subsequent event pertaining to the rail vehicle
• Used to tell the location where the vehicles or trains are found after
the event took place
• Ex) track section, station, shunting yard, or specific shunting yard location
• Used to serve asset tracking needs
• While the read point is more directly related to the measurement values
received in conjunction with an EPCIS event
Business location

Determining vehicle and train
visibility data

Slide 22
Determining vehicle and train visibility data
• Determining the train direction
• Available from the AVI system
• Expressed in terms of the ‘railroad direction’ of the track
• Using the direction indicator
• 0 : the direction was not detected
• 1 : one direction in the rail network
• 2 : the opposite direction in the rail network
• The compass direction indicating the actual direction of the train at
the read point
• Expressed using a cardinal (N, S, W, E) or intermediate cardinal (NW, NE, SE,
SW) value

Slide 23
• Determining the train direction
Determining Train Direction

Slide 24
• Determining the orientation of the rail vehicle
• The correct assignment of measurement values
requires the direction of travel of the vehicle.
• The orientation of a rail vehicle is determined by:
• The observed tag
• The train direction
• Ex)
Train direction indicator = 2 (compass direction = NE)
t1: Vehicle 2 – tag 2, vehicle end 2 passed first
t2: Vehicle 1 – tag 1, vehicle end 1 passed first

Slide 25
• Determining Source and Destination
• Information on the origin of the train and its ultimate destination
• Parties with access to the railroad plan – can derive this based on
the provided read points and direction information
• Parties that do not have access – utilize the Source and Destination
elements in EPCIS
• Identified with SGLN
• Not necessary, may additional

Slide 26
• Determining a train passage
• The AVI can detect whether observed vehicles are connected in the
same train-set.
• A separate EPCIS event for each vehicle observation
• To specify which vehicles were observed as part of the same passage,
a passage identifier should be added to the object events.
• Passage identifier should be included as an EPCIS Business
Transaction.
• A Transaction Event will be used to list all observed rail vehicles.
• The train number can be used to link to information in other train
management systems.
• Include the vehicle level information in the EPCIS transaction event
for a passage
• To avoid use of “dummy” EPCs for hidden vehicles

Sharing vehicle and train
visibility data with EPCIS
Special issues when applying Epcis functions to railway vehicle visibility

Slide 28
Sharing vehicle and train visibility data with
EPCIS
• Vehicle and train visibility – critical tracking events
Standard Rail Journey Diagram

Slide 29
EPCIS
• EPCIS event data
• ObjectEvent (action OBSERVE) – serves as an observation of a uniquely
identified rail vehicle in passage along its journey, or upon its arrival
at or departure from a terminus
• TransactionEvent (action ADD) – serves as a “summary” event following
the observation of a passing train’s trailing vehicle, reiterating the
proxy GIAIs of positively identified vehicles, as well as relevant totals
for all vehicles

Slide 30
EPCIS
• What
• Indicates the objects to which the EPCIS event pertains
• Each observed rail vehicle should be captured in a separate ObjectEvent.
• The epcList element should contain only the master GIAI of the observed
vehicle.
• Ex)
• A passage should be defined using a TransactionEvent.
• The epcList element includes the master GIAIs of all observed, positively
identified rail vehicles.
• Ex)

Slide 31
EPCIS
• When
• eventTime – the time at which the vehicle was observed (Object events), the
time at which the first (leading) vehicle of a passing trainset was observed
(Transaction events)
• recordTime – the date and time at which this event was recorded by an EPCIS
Repository
• Ex)

Slide 32
EPCIS
• Where
• Indicates the location at which the EPCIS event was observed, as well as the
whereabouts of the object subsequent to the event
• readPoint – the SGLN corresponding to the event’s location
• bizLocation – the SGLN corresponding to the object’s whereabouts subsequent
to the event
• For all object events and transaction events, either the readPoint or the
bizLocation or both should be populated.
• Ex)

Slide 33
EPCIS
• Why
• Reflects the business context (“Business Step”) of the EPCIS event, as well as
the status (“Disposition”) of the object subsequent to the event
• Business Step
• Specifies the business process linked to the EPCIS event
• Ex)
• Disposition
• Denotes the status of an object subsequent to the EPCIS event
• Ex)

Slide 34
EPCIS
• Why
• Source/Destination
• Use the urn:epcglobal:cbv:sdt:location source/destination type identifier with SGLN
• Ex)

Slide 35
EPCIS
• Why
• Business Transactions
• EPCIS Business Transactions are defined using a combination of Business
Transaction Type and Business Transaction ID
• Rail sector-specific vehicle visibility applications should use HTTP URLs for business
transaction identifiers
• To share information about a passage, the bizTransaction element can be used in
two ways:
• as a transaction reference in a rail visibility ObjectEvent, to indicate which events
belong to the same ‘passage’
• as a transaction type in a rail visibility TransactionEvent, to specify totals and tag
IDs for a particular ‘passage’
• Ex) transaction reference

Slide 36
EPCIS
• Extension elements
• All of these elements should be specified using the namespace
urn:gs1:epcisapp:rail
• Direction elements (for object and transaction events)
• directionIndicator
• 0 : the direction was not detected
• 1 : the first direction in the rail network
• 2 : the second direction in the rail network
• compassDirection
• Using a cardinal (N, S, W, E) or inter-cardinal (NW, NE, SE, SW)
• Ex)

Slide 37
EPCIS
• Extension elements
• Object event elements
• vehicleOrientation
• 1 : vehicle end one is leading, relative to the direction of travel
• 2 : vehicle end two is leading, relative to the direction of travel
• 0 : leading vehicle end not determined
• vehiclePosition – A number identifying the relative position of the rail vehicle within
the passage
• vehicleAxleCount – The number of axles of the vehicle
• proxyGIAI – the GIAI(s) of the observed tag(s)
• Ex)

Slide 38
EPCIS
• Transaction event elements (optional)
• trainAxleCount – the total number of axles observed for the passage of the entire trainset
• trainVehicleCount – the total number of vehicles observed for the passage of the entire trainset
• Vehicle – information on each of the observed vehicles
• vehiclePosition – the relative position of the vehicle in the passage
• vehicleAxleCount – the number of axles of the observed vehicle
• vehicleUniqueIdentified – indicates whether the ID of the observed rail vehicle was captured
• vehicleMasterGIAI – optional element specifying the ID of the rail vehicle
• Ex)

Examples of Rail Visibility
Events

Slide 40
Examples of Rail Visibility Events
• Rail vehicle observations
• Two tags were observed
• First tag 2 of vehicle 676, after that tag 1 of vehicle 070
• The passage ID for both observed vehicles is the same
• Part of the same train set
070 676
Read point
1 2
12

Slide 41
Rail vehicle observation – Object event 1

Slide 42
Rail vehicle observation – Object event 2

Slide 43
• Rail vehicle changing direction
Illustration of direction change – Object event 1

Slide 44

Slide 45

Slide 46
• Train passage transaction event (including untagged vehicle)
• How a train passage can be expressed using a transaction event
• A train passage which consists of three rail vehicles
Train passage

Slide 47
Train passage transaction event

Slide 48
Train passage transaction event

EPCIS Query examples for
rail vehicle visibility

Slide 50
EPCIS Query examples for rail vehicle
visibility
• EPCIS Query Control Interface
• On-demand (synchronous) – a client makes a request through the
EPCIS Query Control Interface and receives a response immediately
• Standing request (asynchronous) – a client establishes a subscription
for a periodic query. Each time the periodic query is executed, the
results are delivered asynchronously to a recipient via the EPCIS
Query Callback Interface

Slide 51
visibility
• On-demand queries via EPCIS Query Control Interface
• Observations of a specified vehicle since a specified date/time
• Example of on-demand query by vehicle
• Observations of all vehicles at a specified read point in a specified
window of time
• Example of on-demand query by read point

Slide 52
visibility
• On-demand queries via EPCIS Query Control Interface
• Events for a given passage
• Example of on-demand query by passage ID
• Passage-level queries
• Example of on-demand query for passage events

Slide 53
visibility
• Standing queries (Subscriptions) via EPCIS Query Call-back
Interface
• Notification whenever a specified vehicle is observed at any read
point
• Example of standing query by vehicle
• Notification whenever any uniquely identified vehicle is observed at
specified read point
• Example of standing query by read point

GS1 Railway Visibility Standard

Recommandé

Recommandé

Contenu connexe

Similaire à GS1 Railway Visibility Standard

Similaire à GS1 Railway Visibility Standard (20)

Plus de Daeyoung Kim

Plus de Daeyoung Kim (20)

Dernier

Dernier (20)

GS1 Railway Visibility Standard