| V1.00 RC1: open discussion points, part 2 [message #112] |
Mon, 25 October 2004 17:49  |
Matthias Hengartner
Messages: 57
Registered: August 2003
|
Member |
|
|
Hello,
later than promised, here some more open discussion points of V1.00 RC1 with
some comments and questions.
*** Train protection / train detection *** (posting from Georg Theeg,
01.10.2004, 10:16)
First of all: Thanks to Gregor Theeg for these detailed informations.
His suggestions:
1) distribute the train protection / train detection elements into 2
containers (<detectionElements> and <trainProtectionElements>)
[I guess, these containers are meant to be implemented as children of
<ocsElements>, right?]
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.
If we do this, we could introduce new container-elements for other groups as
well, e.g. <geometryChanges> (or similar) for radiusChanges and
gradientChanges.
This comment is only meant to be hint to think about the hierarchy of the
trackElements. In my opinion, we should keep it consistent (not that we have
a deep structure in one and a flat structure in the other group of elements.
2) introduce new element <trackCircuit> (later)
3) introduce new element <detector>
--> maybe also later?
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>?
5) additional attributes "insulatedRail" and "side" (or sim.) for
<trackCircuitChange>
6) last paragraph of Mr. Theeg's posting:
<<<
"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).
>>>
Question to these lines:
- in the current scheme, we have the containers <trainProtectionElements>
_AND_ <balises>. Do you think balises should be reordered as a child of
trainProtectionElements?
*** crossings ***
suggestion from Gregor Theeg (01.10.2004, 15:13):
- additional attributes "ID1" and "ID2" for <crossing>
--> since a <crossing> has (normally) two <connection>-elements, and each of
them has a "connectionID", we can use these for identifying the two partial
switches. Do you agree with me?
Best regards
Matthias Hengartner
------------------------------------------------
Matthias Hengartner, IVT ETH Zürich
Tel G (NEU!!): ++41 1 633 68 16
hengartner(at)ivtbaugethzch
------------------------------------------------
|
|
|
|
Members
Search
Help
Login
Home
