| Re: V1.00 RC1: open discussion points, part 2 [message #113 is a reply to message #112] |
Tue, 26 October 2004 13:09   |
Gregor.Theeg
Messages: 8
Registered: September 2004
|
Junior Member |
|
|
Hello,
Thanks to Matthias Hengartner for his ideas. My answer to his suggestions:
> [I guess, these containers (<detectionElements> and
<trainProtectionElements>) are meant to be implemented as children of
> <ocsElements>, right?]
Yes.
> hmm. so far, we (normally) have containers for exactly one type of
> trackElement (e.g. <radiusChanges> with [only] <radiusChange>-elements,
> etc.). Exception: <connections> with <switch> and <crossing>.
> If we introduce (as proposed) a container <detectionElements> with elements
> <detector>, <trackCircuitChange> and later others, this ("unwritten")
> convention is broken.
I would have no problem with introducing 2 containers "detectors" and
"trackCircuitBorders" instead of one container "detectionElements" resp.
"tracksideMagnets" and "balises" instead of "trainProtectionElements". I
think, each of these solutions would work as well as the other.
> 3) introduce new element <detector>
> --> maybe also later?
If nobody urgently needs it, o.k.
> 4) discard attributes "length" and "frequency" of <trackCircuitChange>
> --> question about 2) and 4): do we need <trackCircuitChange> _AND_
> <trackCircuit>? Or wouldn't it suffice to have only <trackCircuit>?
If we define the borders of track circuits within the element
trackCircuit, we usually have to define them twice because a track circuit
border usually limits two track circuits. Another solution would be to
define it once in one of the two adjecting track circuits (Which one?) and
refer to it in the other track circuit. Or we define them outside the
track circuit itself and have 2 references.
A border between track circuits is not always an insulated rail joint.
There are also solutions like S-shaped loops or just limiting the track
circuit by the lenght of the rail. Thus the track circuit borders will get
several attributes. Thus, I prefer to define them as an extra element.
> - in the current scheme, we have the containers <trainProtectionElements>
> _AND_ <balises>. Do you think balises should be reordered as a child of
> trainProtectionElements?
I intended to leave out the container "balises" and to make one container
"trainProtectionElements" which contains balises and tracksideMagnets. But
as mentioned above, we can also have 2 containers instead.
> *** crossings ***
I'm afraid I don't understand well the idea of 0...3 connections. 0
connections are for crossings, 1 for single crossing switches (EKW) and 2
for double crossing switches (DKW), am I right? But 3 connections?
This means that a EKW has 1 connection ID (Right or wrong?), but for
interlocking it needs 2 because it has 2 independent point machines with 2
independent pairs of blades.
Yours
Gregor Theeg
--
Dipl.-Ing. Gregor Theeg
wissenschaftlicher Mitarbeiter
Professur für Verkehrssicherungstechnik
der TU Dresden
Tel.: 0351 / 463 36542
Fax: 0351 / 463 36644
|
|
|
|
Members
Search
Help
Login
Home
