Home » railML newsgroups » railML.infrastructure » Schema version 1.00 RC1 released
Train Detection and Train Protection [message #104 is a reply to message #98] Fri, 01 October 2004 12:16 Go to previous messageGo to previous message
Gregor.Theeg is currently offline  Gregor.Theeg
Messages: 8
Registered: September 2004
Junior Member
Dear railML partners,

the basic difference between detectors and train protection elements is
the following:
Detection elements detect a wheel/axle, vehicle or obstacle and give
information from the train to the infrastructure (signal box). The signal
box uses this information for proving a track free (axle counters, track
circuits) or for switching purposes (e.g. switching a level crossing
on/of, release or approach locking of routes etc.
Train protection elements (such as balises, trackside magnets or
mechanical barriers (which are still in use at Berlin S-Bahn) are actors;
they give information from the infrastructure to the train, e.g. order to
brake immediately.
Based on this difference, we should divide the "small things along the
track" into 2 containers: "detectionElements" and
"trainProtectionElements".

"detectionElements" can contain 0...many elements "detector" and
"trackCircuitChange" and maybe more others in later versions.

Althought in most (not in all) cases there are different forms of
detectors used for axle counting and for activating a level crossing and
they must meet different requests, principally they are all the same
thing, which means that in line schema they shall be the same type of
element with different attributes. Only the signal box makes the one an
axle counter and the other a switching-device, sometimes the information
from one detector is used for several purposes, so the detector is both.
I suggest the following (mostly not-required) attributed:
- The ID and positioning attributes we already have.
- The kind of detected object, e.g. wheel, vehicle (=railway vehicle),
obstacle (including road vehicles), end of train. Axle counters must
detect wheels, for switching on a level crossing sometimes induction loops
(which are vehicle detectors) are used.
-The technical principle, e.g. mechanical, hydraulic, pneumatic, magnetic,
inductive and optical. Most modern forms are inductive, but optical forms
are increasingly used, especially for obstacle detection, and at Innotrans
2004 I even saw a modern mechanical detector!
- Position: Wheel detectors can be at right or left rail, vehicle and
obstacle detectors between or ...meters right or left from the rails.
- Detection of direction ("true"/"false"): Today detectors used for axle
counting always have to distinguish directions.
- Type (Bauform; according to the producer)
- Information, if this detector is used for axle counting
("true"/"false"). Sometimes in layout maps we want to draw all "axle
counters".

Track circuits are detectors that are no point, but have a length. In our
definition we should clearly distinguish between the track circuit and the
limit of a track circuits (e.g. insulated rail joint). The attributes
"length" and "frequency" refer to the track circuit, not to its limit.
Because of the functional analogy between an axle counting point and an
insulated rail joint (limiting track sections to be proven free) I would
put the trackCircuitChange into the container "detectionElements",
although they are no detector. Because of the same analogy between track
circuits (a physical element which actually belongs into line schema) and
axle counting circuits (a logical thing which actually belongs into
interlocking schema) I like to have both of them at the same position in
railML DTD. Thus, we should leave the track circuit (not the
trackCircuitChange!) out for the moment (which means in version 1.0) and
think about this problem later during the development of interlocking
schema.
trackCircuitChanges I would like to give additional attributes:
- If the right, left, both or no rail is insulated. No rail for
insulated-rail-joint-free track circuits.
- If at upper, lower or both sides there is a track circuit.

"trainProtectionElements" in most cases are a "tracksideMagnet" or a
"balise". A trackside magnet can also be a combination of 2 magnets, e.g.
Signum. The basic difference is that a trackside magnet submits only its
condition (1 bit), e.g. "I'm under alternate current 1000 Hz" or "I'm
under direct current with polarity ...", whereas a balise submits a data
telegram. Additional attributes should be the system, e.g. "PZB90",
"Signum", "ZUB123", "ETCS Level1", "Crocodile",...; and the type of the
element (Bauform).
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Schema version V0.95-02 released
Next Topic: V1.00 RC1: overview of open discussion points
Goto Forum:
  


Current Time: Sat Jul 06 12:28:06 CEST 2024