AP-Werte
Archive
Kommunikation, Adressierung, Ports
Meldungen, Return Codes
Schalten
Systemzugang
Typetool, Trace
Übertragungsprofil 2
Verschiedenes
Versorgung
F: Sichtbarkeit AP Werte
Im Falle von AP Werten, welche einer Verkehrslogikanwendung zugeordnet werden
(z.B.: vsplus), ist die Anzahl von indizierten Variablen erst bei aktiver Anwendung
ermittelbar. Im Falle einer Ausführung eines Plans ohne laufende Verkehrslogik,
wird eine Enumeration über Feldgerät.GetInstanceInfo diese entweder
gar nicht oder anderenfalls die theoretische Maximalzahl der Indize liefern
können. Die Maximanzahl wiederum würde den Rahmen der Methode Feldgerät.GetExtInstanceInco
sprengen. Eine Herstellerversorgung der AP Variablenanzahl ist nicht wirklich
sinnvoll, da diese sich wohl an die Versorgung der Verkehrslogik zu orientieren
hat. Ist dieser Umstand berücksichtigt worden, oder meine Denkweise dazu
fehlerhaft?
A: Listen mit AP-Werten welche einer Verkehrslogikanwendung zugeordnet sind,
müssen nach einer Neuversorgung der Verkehrslogik manuell entsprechend
angepasst werden, weil möglicherweise neue Werte dazukommen und nicht
mehr vorhandene AP-Werte entfernt werden sollen. Der Wert nicht mehr vorhandener
AP-Werte wird im Lichtsignalsteuergerät automatisch auf Nullvalue gesetzt,
beim BLOB wird die Länge auf Null gesetzt.
F: Namen von AP Variablen.
Gemäß Dokument OCIT-O_Lstg_V2.0 Seite 126 Kapitel 4.5.4 werden
die Namen von AP Variablen, welche Prozessdaten von OCIT_I SP-PD entprechen,
durch Konvertierung der oitd in die Textform "Member.Otype" gebildet.
Gehe ich Recht in der Annahme, dass indizierte OCIT-I Variable in der Form "Member.Otype.Index" angegeben
werden und der Index im Bereich [1..MaxIndex] zu liegen kommt ?
A: Sie haben Recht mit Ihrer Annahme, denn AP-Werte werden über ihren
Namen als String addressiert.
F: AP-Wert-Gruppen
Wenn ich eine Gruppe „Det“ mit folgenden Elementen bauen würde
Det.Anzahl
Det.Luecke.1
Det.Luecke.2
Det.Belgrad.1
Det.Belgrad.2
-würde die Methode GetElements folgendes Ergebnis liefern:
Det.Anzahl (die anderen haben ja Subgruppen)
-würde die Methode GetSubgroups folgendes Ergebnis liefern:
Det.Luecke
Det.Belgrad
Ist das so richtig ??
A: Ja, genau so ist es.
F: AP-Wert-Gruppen
Ist der Gruppenname unabhängig von den Elementen, d.h. könnte
ich die obige Gruppe auch „Karl“ taufen? oder ist der Gruppenname
zwangsweise das Präfix der Elementnamen?
A: Nein, der Name eine APWerts bestimmt die Gruppe in der sich der APWert befindet.
D.h. der APWert „Det.Luecke.1“ befindet sich in der Gruppe „Det.Luecke“ und
diese wiederum in der Gruppe „Det“. Es könnte natürlich
auch eine Gruppe „Karl“ geben, aber diese wäre ja denn leer
und macht somit keinen Sinn.
F: AP-Wert-Gruppen
Werden die Gruppennamen automatisch aus den APNamen zur Initialisierungszeit
erzeugt, oder bedürfen diese eine Versorgung?
A: Die Gruppen ergeben sich automatisch aus den Namen der vorhandenen APWerte.
F: AP-Wert-Gruppen
Wenn „Det“ ein gültiger Gruppenname ist, ist „Det.Luecke“ automatisch
auch einer? D.h. wenn das Element ApWertGroup ohne Pfadangabe enumeriert wird
(durch Feldgerät - GetInstanceInfo) erscheint „Det.Luecke“ als
eigenes Element APWertGroup ?
A: Wenn ein APWert „Det.Luecke.1“ existiert müssen auch die
APWertGruppen „Det“ und „Det.Luecke“ existieren und
werden somit beim InstanceInfo-Aufruf zurückgeliefert.
F: AP-Wert-Gruppen
Wenn GetSubgroups nur die Subgruppen zurückliefert, sind das u.U.
keine richtigen Referenzen, das Element „Det-Luecke“ gibt’s
ja nicht wirklich, ok ?
A: GetSubGroups liefert die „direkten Subgruppen“ zurück,
also die Referenzen auf die APWertGroups die sich „in“ der entsprechenden
APWertGroup befinden (d.h. deren Name mit dem Name der APWertGroup, von dem
die Methode aufgerufen wurde, beginnt).
F: AP-Wert-Gruppen
Gibt es eine Beschränkung der Anzahl der Untergruppen von APWertGroups?
A: Eine Beschränkung der Schachtelungstiefe der APWertGroups ergibt sich
durch die maximale Länge der APWert-Namen (512). Wenn jedes zweite Zeichen
ein Punkt wäre, gäbe es 255 APWertGroups. Generell gibt es aber keine
Beschränkung der Untergruppen.
F: AEPVektor
AEPVektor mag einen hash Wert über die Daten haben, um erkennen zu
können ob sich diese geändert haben, ist mal der Theorie nach ok.
Mein Problem beginnt diesmal mit der Methode GetTriggerValue, da ich einen
Hashwert (zumindest 128 Bits) nicht in einen OCIT WERT_LONG (= 31 Bits Länge)
konvertieren kann, der passt da wohl nicht rein. Wie ist damit umzugehen?
A: Hashwerte haben keine festgelegte Grösse. Über die Auswahl einer geeigneten
Hashfunktion sagt der Standard nichts aus, dies unterliegt dem Hersteller.
F: Wurzelgruppen
Sowohl bei APWertGroup als auch bei APWertGroupRK wurden sog. Wurzelgruppen
mit einem Leerstring definiert. Sind diese beim Aufruf von GetInstanceInfo
ebenfalls in das Ergebnis zu inkludieren?
A: Ja, die kommen beim Ergebnis von GetInstanceInfo mit.
F: Methoden AEAPWert.SetAP()
und AEAPWertVektor.SetAPListe()
Es geht um die Definition der Verwendung der Methoden AEAPWert.SetAP()
und AEAPWertVektor.SetAPListe(): Es ist genau festzulegen, welche Werte den
Feldern zugewiesen werden, vgl. auch OCIT-O_Lstg_V2.0_A01.pdf, S. 136, Kap.
4.5.4. APWerte gehören zu den OCIT-I-Prozessdaten, es wird die Notation
Member.Otype, resp. im OIPD-Jargon Member.Nummer verwendet.
Nehmen wir an, wir haben einen indexierten APWert, zB. 57.101 mit Indexrange
1-280
Variante 1: Ich würde die Input-Parameter der Methoden wie folgt verwenden:
AEAPWert.SetAP(), Beispiel Index 1
RefLen = 15 -> Länge der Referenzdefinition in Bytes, inkl. RefLen
Member = 1, da USHORT OType = 506, da USHORT ApWertName = 57.101.1
AEAPWertVektor.SetAPListe(), Anhand Beispiel Index 1, 5 Prefix = 57.101.
Anzahl = 2
RefLen = 8 -> -> Länge der Referenzdefinition in Bytes, inkl. RefLen
Member = 1 OType = 506 ApWertName = 1 -> Gesamtname des APWertes setzt sich
aus Prefix + APWertName zusammen RefLen = 8 -> -> Länge der Referenzdefinition
in Bytes, inkl. RefLen Member = 1 OType = 506 ApWertName = 5 -> Gesamtname
des APWertes setzt sich aus Prefix + APWertName zusammen
Variante 2: Mein Kollege besteht aber auf folgender Darstellung AEAPWert.SetAP(),
Beispiel Index 1 RefLen = 19 -> Länge der Referenzdefinition in Bytes,
inkl. RefLen Member = 1 OType = 506 ApWertName = 57.506.101.1 -> seine Argumentation:
entspricht dem Beispiel im Dok. OCIT-O_Lstg_V2.0_A01.pdf, S. 136, Kap. 4.5.4:
41.500 = Digitaler Input 500 entspricht dem OCIT-O-Type eines digitalen Eingangs.
Wenn ich den im ApWertNamen verwende, dann muss ich hintendran noch die OITD
Nr. und den Index anhängen, da ich sonst steuergeräteseitig nicht über
alle Infos verfüge, um auf den Wert zuzugreifen.
Bei der Variante 1 (ApWertName = 57.101.1) wäre die Argumentation so:
ich brauche den OCIT-O-OType nicht im ApWertNamen, da die SetAP() Methode diese
Information ohnehin schon mit sich führt.
Wie hat sich die ODG das gedacht?
A: die Variante 1 ist richtig, da in der Variante 2 ein Denkfehler steckt.
Hier wird auf die Instations-Typdefinition verwiesen. 41.500 ist ein Typ aus
Instations (PD-DM-LSA), nicht aus Outstations. Daher ist die Argumentation,
die sich auf die Typbezeichnung des DigEingangs bezieht, hinfällig.
F: Aufträge der Listen
Wie findet man die Aufträge der Listen?
A: Aufträge der Listen findet man mit:
SystemobjektFeldgeraet::InstanceInfo Auftrag 0:402 Listennummer
F: Persistenz der Archive
Kann man die Archive als Persisitent oder nicht persistent konfigurieren?
A: Nein. Die Liste::SetSize mit IN=“Persistenz“ gibt nur an welche
Teile der Liste nach Netzausfall erhalten bleiben“
F: Abholen von Meldungen aus dem Ringpuffer
Werden Meldungen beim Abholen aus dem Ringpuffer gelöscht (relevant
wenn Verbindung abbricht etc.):
A: Nein, sie können wiederholt abgeholt werden
F: Projekt-oder/ herstellerspezifischen
Archive
Wie geht das das Feldgerät mit projekt / oder herstellerspezifischen
Archiven um? Wie soll z.B. ein Feldgerät auf das Anlegen eines Archivs
mit einer anderen Nummer reagieren? Hierzu scheinen Festlegungen erforderlich,
da mindestens ein VSR-Hersteller auch andere als die hier angegebene Archiv-Nummern
(ohne Wissend es Auftraggebers und der anderen Signalbaufirmen) verwendet.
Dies ist in einem herstellergemischten System nicht akzeptabel!
A: Wenn herstellerspezifische Archive den Projektpartnern nicht bekannt sind,
können sie können nur vom Hersteller bedient werden.
F: Aufträge ändern
Kannn man Aufträge ändern, während die Liste aktiv ist?
Gibt es dazu weitere Festlegungen?
A: Das Lstg muss das dynamische Konfigurieren von Archiven unterstützen.
Es gilt, dass man Aufträge nicht ändern kann, während die Liste
aktiv ist.Außer den Festlegungen dazu im Standard gibt es keine ergänzenden
Festlegungen im Funktionsspiegel.
F: Elemente des Meldungsarchivs
OCIT-O-Basis_V1.1_A02, chap. 4.2.12 specifies the above messages (objects)
as elements of Meldungsarchiv. Does it mean the above elements are stored in
Standard-Meldarchiv as well as in Syslog archive ? Moreover - the table in
OCIT-O-Lstg_V1_1A02-2, chap. 6.4 specifies every archiv (0,1,2,3, 32,33,34,35)
after reset has predefined Meldungauftrags with severity I. Does it mean after
reset all archives will log all messages with severity I specified in OCIT-O-Basis_V1.1_A02,
chap. 4.2.12? e.g. the OPNV archiv after reset will log door open/door close
messages (0:60020,0:60021) ?
A: According to OCIT-O-Basis_V1.1_A02 chapter 4.2.4.2. is in each list an order
with number 0. This inserts the following events as messages into the ring
buffer of the list: Suspend, Unsuspend, time jump, starting order, stop order.
The list 0, 1, 2, 3 cannot be reset. After reset all others contained the order
0 and are filled thereafter with orders and order elements.
F: Vordefinierte Aufträge für Syslog Archiv
OCIT-O-Basis_V1.1_A02 specifies in chapter 5.1 that archives 0, 1, 2 (Betriebzustand,
StandardMeldung, Syslog) have pre-defined "auftrags" which can be
only modified; question is what are pre-defined auftrags for Syslog archive
?
A: There is one „Meldungsauftrag“ (order) per degree which contains
the Syslog Meldung.
SyslogI 0:60033 System Meldung Information. CMsgPart
SyslogW 0:60034 System Warnung. CMsgPart
SyslogE 0:60035 System Fehler. CMsgPart
SyslogS 0:60036 schwerer System Fehler. CMsgPart
F: Signalbild-Visualisierung
To gather/store "visualisation" data OCIT specifies AESignalbild
element (1:433); question is what data and in what format are actually stored
in appropriate ring buffer ? also what represents TriggerValue - the status
of the signal group ? if yes, how the
status of signal group is converted to WERT_LONG value ?
A: In archives the data in the AESignalbildFrame are stored. The coding is
like SIGNALBILD 1:135. Trigger VALUE is not used in connection with signalisation,
since each change is logged here.
F: Tigger Value
GerTriggerValue method is specified by ocit.html for different elements
(in the same way as in our case - AESignalbild (1:433)) but based on what to
decide the Trigger Value is or is not used for the specific element ?
A: The above answer “Trigger VALUE is not used in connection with signalisation,
since each change is logged here” is not completely correct. According
the XML, GetTriggerValue has to be implemented in the cases concerned. That
value is to be returned (in hexadecimals), which would be written into the “Auftragsframe”.
Thus one can query the value of the order element.
F: Versatzzeit
What exactly specifies the "Versatz" value in AuftragZykl (1:403)
?
A: Versatz = “Signalzeitenversatz” means the offset time to the
reference point of time for a dedicated controller in the green wave (see synchronization
above).
F: Intervalle Auftragselement
With Auftragzykl, if we gather/store data in e.g. 100ms interval for auftragselement
XYZ, does it mean in appropriate ring buffer we always obtain 10 secondframes
for each second, where each of these secondframes contains one auftragsframe
which stores one
sample of XYZ ?
A: You obtain only one secondframe per second. Every secondframe contains 10
auftragsframes with one sample of XYZ. The auftragsframes also contains the
subsecond of the sample (see also the grafik on page 25 of OCIT-O-Basis_V1.1_A02,
chap. 5.1.1).
F: What`s the meaning of the sentence in OCIT-O-Basis_V1.1_A02, chap. 5.1.1
?
A: These three lists containing predefined aufträge. There is no need
of the central to configure and to start these lists. This feature is important
for the use case that the controller is conntected to no central or the central
is out of order. The data of these lists are very important for the service
and (maybe just in Germany) especially in case of an accident on the crossroad.
F: Signalsierungsarchiv Optional 1
How to understand the requirements in OCIT-O_V1.1_Funktionsspiegel_V1.0_A01,
chap. 7.2 where par. 4.4.5 marks "Signalisierungsarchiv" as O (which
we understand as optional) while in par. 4.6.1 "Signalbild" as G
(which we understand as mandatory) ?
A: "Signalisierungsarchiv" ist optional, but the controller must
be able to get the Signalbild as written in 4.6.1 (G is a basic function of
the controller).
F: Signalsierungsarchiv Optional 2
What does it mean - "...must be able to get the Signalbild .." ?
We supposed the only way to get Signalbild is via Signalisierungsarchiv, i.e.
first to collect appropriate data in the archiv and then to retrieve (to get)
them from the archiv. Thus the possibility "to get" Signalbild we
understand as necessity to implement Signalisierungsarchiv as well; but this
doesn`t seems to be correct - can you please explain this issue a bit more
?
A: You don´t need the "Signalisierungsarchiv" as a basic function
of an OCIT-O controller. But if this archiv is necessary an used, then the
format of Signalbild has to be as described.
F: Reihenfolge der Daten im Auftragsframe
Laut der Dokumentation, lassen sich mehrere Auftragselemente, ausgenommen "AEBinaer",
in einem Auftrag anlegen. Wie weiss aber die Zentrale welche Daten im Auftragsframe
zu welchem Auftragselement gehören ?
Mittels "MWAuftragAbtastAenderung::SetAEZeit", lässt sich der
Abtastintervall/Versatz für jedes angelegte Auftragselement einstellen.Müssten
dann Abtastintervall/Versatz nicht als dynamische Attribute in den jeweiligen
Auftragselementen,nicht nur "AEAggregiert", vorhanden sein ?
Mittels "MWAuftragAbtastAenderung::Get", lassen sich Abtastintervall/Versatz
und angelegtes Auftragselement auslesen. Falls in diesem Auftrag mehrere Auftragselemente
mit möglicherweise unterschiedlichem Abtastintervall/Versatz angelegt
wurden, was wird dann zurückgemeldet ?
A: Generell ist die Codierung der Messwerte darauf ausgelegt, möglichst
platzsparend zu sein (wegen der knappen Resource Bandbreite). In den geschriebenen
Daten sind daher nur Referenzen auf die Auftragsnummer, nicht auf die Nummern
der Auftragselemente. Die Daten der Auftragselemente werden in der Reihenfolge
ihres Anlegens geschrieben. Die Dateninhalte selbst sind im XML in den Auftragsframes
definiert (z.B. AESignalbildFrame für die Signalbilder).
F:AuftragZykl" mittels "Auftrag::AddElement"
Bei "AuftragZykl" mittels "Auftrag::AddElement", können
mehrere (max. 254) Auftragselemente angelegt werden. Hier werden ja alle Auftragselemente
mit demselben Abtastintervall/Versatz abgetastetund können demzufolge
auch in der richtigen Reihenfolge in den Auftragsframe geschrieben werden.
Der MWAuftragAbtastAenderung ist so definiert, daß nur das mit SetAEZeit "aktiverte" Auftragselement
abgetastet wird. Nur dessen Einstellungen sind relevant. Ändert sich dieses,
so werden die Werte aller Datenquellen geschrieben. Der angeführte Fall
kann so nicht auftreten.Man kann zwar mehrere Auftragselemente anlegen, diese
werden aber ALLE, und deshalb wiederum in der richtigen Reihenfolge, in den
Auftragsframe geschrieben, falls sich das und nur das mit dem letzten von "SetAEZeit" übergebenen
Abtastintervall/Versatz abgetastete Element ändert.
In den Ocit-Outstation-Unterlagen findet sich das Telegramm AuftragZykl
(1:403) mit den zugehörigen Methoden. Kann man bei Verwendung dieses Telegramms
davon ausgehen, daß die Lichtsignalanlage die Inhalte aller Aufträge
einer Liste sendet (also nicht nur bei Änderung [z.B. mit 1:407])? Anwendungsbeispiel:
Signalplan (Auch wenn in OCIT-O-2.0 Telegramm 1:438 verwendet werden soll.
Dort werden nur Signalzustände + TX übertragen.
A: Der AuftragZykl ist kein Telegramm sondern ein Auftrag. Jeder Auftrag erzeugt
AuftragsFrames die, in Sekundenframes gekapselt, in das entsprechende Archiv
(der Liste) eingetragen werden. Diese Sekundenframes können dann von der
Zentrale abgeholt werden. Der AuftragZykl erzeugt diese AuftragsFrames zyklisch,
der MWAuftragAbtastAenderung erzeugt diese nur wenn sich eines seiner Auftragselemente
geändert hat.In den AuftragsFrames befinden sich nur die Werte der AuftragsElemente
des Auftrags der den AuftragsFrame erzeugt hat, nicht von AuftragsElementen
anderer Aufträge.
F: Warum benötigt AuftragZykl::SetZyklus kein AuftragsElement
Warum benötigt AuftragZykl::SetZyklus kein AuftragsElement und bei
MWAuftragAbtastAenderung::SetAEZeit muß es versorgt werden?
A: Beim AuftragZykl gilt die Zykluszeit für den gesamten Auftrag und beim
MWAuftragAbtastAenderung gilt diese nur für das jeweilige Auftragselement.
Man könnte also hier für jedes Auftragselement eine unterschiedliche
Zykluszeit einstellen.
F:
Triggerwerte bei AEDetExt
Dokument bezeichnet AEDetExt als Ableitung von AEBinär, In diesem Fall
muss auch die Methode GetTrigger implementiert werden. Welche Werte werden
als Triggerwerte herangezogen, bzw. was ist der Default Wert?
A: Die Methode GetTriggerValue ist abgeleitet von AEBinär. Die Triggerwerte
sind nicht definiert.
F: Objekt AESiplOnline
Ich beziehe mich auf die Beschreibung Seite 131 OCIT-o Lstg_V2.0_A01 zum
Objekt AESiplOnline
Frage 1) Soll die Reihenfolge der Signalgruppennummern im Array Sigrunummer[AnzahlSigru]
aufsteigend sortiert sein, oder kann diese in der Geräteversorgung beliebig
angesetzt werden?
A: Das Objekt ist so gedacht, dass die Signalgruppen in aufsteigender Reihenfolge
ohne Lücken bis zur höchsten versorgten Signalgruppennummer übertragen
werden.
Frage 2) Bei einem MWAuftragAbtastAenderung soll bei jeder TX Änderung
ein Eintrag im Sekundenframe generiert werden auch wenn keine Änderung
des Signalbilds stattgefunden hat? Da TX mit der Auflösung 1/10 Sekunde
betrieben wird, bedeutet dies 10 Einträge pro Sekunde, ist das so gemeint?
A: Das TX wird zwar in 100ms Einheiten geführt, die Steuergeräte
laufen aber in der Regel in einem Sekundenrythmus, was zur Folge hat, dass
auch das TX immer um 10 erhöht wird. Dadurch gibt es auch nur jede Sekunde
einen Eintrag. Falls ein Gerät einen 100ms Systemtakt unterstützt
und auch in diesem läuft, dann gibt es in diesem Fall tatsächlich
Einträge im Abstand von 100ms, aber dann kann sich auch die Signalisierung
in entsprechenden Abständen ändern.
F: Objekt AESiplOnline
Muss de Methode GetSigState vom Objekt AESiplOnline die aktuellen Signalgruppenzustände
auch liefern können, wenn der zugehörige Auftrag gestoppt ist?
A: Ja, da die Beauftragung des Objekts in einer Liste und der Einzelzugriff über
die Methode unabhängig voneinander zu sehen ist.
F: Konfigurationsdaten der Auftragselemente
und Aufträge
Gehe ich recht in der Annahme, dass die Konfigurationsdaten der Auftragselemente
und Aufträge, welche nach der jeweiligen Pfadbeschreibung zu übermitteln
sind, jene Daten sind, die bei Abfrage des jeweiligen Objekts mit der Methode
Get entstehen zu senden wären ?
A: Ja, es sind die Daten die auch als Antwort des Auftrufs Get des entsprechenden
Auftrags, nach dem RetCode zu senden sind.
F: Nummer des Auftragelements
Ist in der XML Datei bei der Methode absichtlich die Nummer des Auftragelements
doppelt angeführt ?
Einmal im Pfad und einmal in den Daten?
A: Ja, kommt daher dass das Auftragselement seine Auftragselementnummer als
Attribut enthält.
F: Beschreibungstext Methode GetListConfig
Es werden max. 65535 ListenInfo
Instanzen mit Daten . zurückgegeben". Beschreibungstext RetCode: "TOO_MANY:
falls mehr als 65535 Pfade und Daten von Listen und Aufträgen und Auftragselemente
gibt".
a) Sind das zwei unterschiedliche Bedingungen, d..h. muss seitens der VLSA
zusätzlich überprüft werden ob die Summe der Objekte Listen,
Aufträge, Auftragselemente den Wert 65535 überschreitet?
b) wenn a) == ja wie viele Einheiten zählen die Datensätze eines
Objekts (Pfade und Daten) ?
A: zu a) Nein. Dies ist eine Bedingung. Entweder max. 65535 oder TOO_MANY und
nichts.
zu b) nicht mehr relevant, da a) == NEIN
F: Beschreibung Eingabe Element ListenNr
GetListconfig Methoden Beschreibung Eingabe Element ListenNr: „Bei
einem leeren Array wird die Konfiguration aller Listen zurückgegeben“.
GetListConfig Beschreibung in XML Datei: „Bei einem leeren Array (Länge
null) wird die Konfiguration aller veränderbaren Listen (also alle im
Feldgerät vorhandenen bis auf 0, 1 und 4) zurückgegeben“Was
ist nun gewünscht?
A: Es handelt sich um die veränderbaren Listen. RetCode für die Methode
GetListConfig:
„
OK. Funktion wurde korrekt durchgeführt“ (auch wenn der Eingabeparameter
listNrs leer ist und keine veränderbare Liste existiert).
F: Wie bestimmt / ändert man eigentlich welche Zentrale (Znr /Fnr) obige
Events bekommen soll?
Bei OnFull und OnInsert ist das ja leicht, da die Objekte
Liste und Auftrag die notwendigen Methoden zum Setzten des Eventziele beinhalten.
A: Das OnNetzAus Event geht an die Event Destination des Standard-Meldearchivs.
OnTransactionStateChanged geht über die Methode SetEventDestination der
Transaction zu ändern.
F: Wie übermittle ich der Zentrale einen Signalgeber (GetInstanceInfo)
mit 2 roten Kammern?
A: Im Standard sind nur die drei Kammern (0=rot, 1=gelb, 2= grün) definiert.
Ein Auslesen der vorhandenen Signalkammern eines Signalgebers über InstanceInfo
ist im Konzept gar nicht vorgesehen, die Kennungen der Kammern sind als Teile
von Meldungen gedacht. Der angesprochene Fall mit den zwei getrennt überwachten
Rotlampen kann in OCIT-O somit momentan auch nicht abgebildet werden.
F: AMLI Datensatz.
a) Der Wert von TX ist im Bereich [0..255] gültig,
die Darstellung der Umlaufsekunde bei einem Umlauf von Tu, liegt im Bereich
von [0..Tu-1].
b) Die Werte von GNA und GNE liegen im gültigen Bereich von [1..253]; der Wert 0 ist für die Darstellung spezieller Fälle reserviert.
Nun meine Fragen:
1) Werden die Werte GNA/GNE gebildet indem man zur aktuellen Umlaufsekunde 1 hinzuzählt ?
2) Stellt der Wert GNE die letzte Umlaufsekunde dar, zu der die zugehörige ÖV
Signalgruppe noch grün hatte, oder den ersten Umlaufsekundenwert, bei
dem die Signalgruppe nicht mehr grün hatte ?
A: Der Start eines Umlaufs erfolgt immer bei TX=0.
Der Umlaufzähler TX beginnt beim Schaltwert 0 (= Beginn der 1. Sekunde
des Umlaufs) und endet beim letzten Schaltwert des Umlaufs (TX kleiner TU).
Die in den Versorgungsdaten angegebenen Zeiten haben eine Auflösung von
0,1 Sekunden.
Die 1. Sekunde umfasst die Schaltwerte 0 bis 9.
Wert 0 und Wert TU bezeichnen demnach einen identischen Zeitpunkt.Zugelassen
ist der Schaltwert 0, nicht zugelassen ist der Schaltwert TX=TU.
Im Gegensatz zum Umlauf in den OCIT-Lichtsignalsteuergeräten (Tx = 0 bis
Tu-1) wird im AMLI immer Tx = 1 bis Tx = Tu dargestellt. Die ODG hat auf ihrer
technischen Sitzung am 29. 1. 08 folgende Änderung beschlossen: TX wird
ab sofort OCIT konform eingetragen (Tx = 0 bis Tu-1).
F: Erweitertes R09 Telegramm AMLI, Datenelemente GNA und GNE
a) Gemäß OCIT_0_Lstg_V1.1_a01 Seite 55 soll bei Anmeldungen im Feld
GNA der Zustand der Signalgruppe übertagen werden, dieser ist jedoch nicht
eindeutig fesgelegt. Aus den Anmerkungen ließe sich folgern: Wert 0 =
Anlage AUS, Wert 254 = grün, was ist hier bei anderen Signalisierungen
einzusetzen ?
b) Welcher Wert ist für das Feld GNE bei Anmeldungen einzusetzen, der Wert des Grünendes des letzten Umlaufs ? oder wird dieses Feld bei Anmeldungen nicht ausgewertet ?
c) Anmerkungen Seite 56 Zeile 2 Definition "festgelegte Rotzeit"; Ist diese Zeit projektspezifisch / signalplanspezifisch /signalgruppenspezifisch anzusehen ? Wie ist eine Abmeldung einzutragen, welche in der Zeit zwischen GNE und Ablauf der gegebenen Sperrzeit empfangen wird ?
d) Zeile 4 - Ist die Zeitangabe 15 Sekunden eine Fixzeit / projektspezifisch /signalgruppenspezifisch festzulegen ?
A:
a) Bei Anmeldungen haben die Elemente GNA und GNE immer den Wert 0!
b) Bei Anmeldungen haben die Elemente GNA und GNE immer den Wert 0!
c) „Festgelegte Rotzeit“ ist ein Parameter der VA (Parameter Modifikation
nach GNE).
Falls die Abmeldung kurz nach der Umschaltung auf Rot (innerhalb der Zeit des
VA-Parameters „festgelegte Rotzeit / Modifikation nach GNE“) erfolgt,
d.h. der Bus bei Gelb / Rot noch gefahren ist, wird das tatsächliche Grünende
bei GNE eingetragen. Erfolgt die Abmeldung später als der parametrierte
Wert wird GNE auf 0 gesetzt.
d) Die Zeitangabe ist im Regelfall eine Fixzeit von 15 Sekunden, nur in Einzelfällen ist sie versorgbar.
F: Konfigurierbarkeit der OCIT-Archive
Eine herausragende Eigenschaft des OCIT ist die Konfigurierbarkeit der
OCIT-Archive in den LSA-Steuergeräten durch die OCIT-Zentrale. Ist es
richtig dass diese Archiv-Eigenschaften fest eingestellt werden, entsprechend
der Konzeption des Projektes oder können diese zur diese zur Laufzeit
verändert werden? Gibt es hier bereits ensprechende Erfahrungen?
A: Das Lstg muss das dynamische Konfigurieren der im Standard festgelegten
Archive unterstützen. Zum dynamischen Ändern der Archive (im Standard
festgelegt) gibt es keine ergänzenden Festlegungen im Funktionsspiegel.
Es gilt, dass man Aufträge nicht ändern kann, während die Liste
aktiv ist. Wenn herstellerspezifische Archive den Projektpartnern nicht bekannt
sind, können sie können nur vom Hersteller bedient werden.
F: OCIT-O Meldungsarchiv
Gemäß Dokumentation OCIT_O_Lstg besteht das Meldungsarchiv aus einer
Liste von Meldungsteilen somit gemäß OCIT_O_Basis aus einem Hauptmeldungsteil
und 0 bis mehreren Meldungsteilen. Ein Blick in die XML Beschreibung zeigt
einen Hauptmeldungsteil mit OType = 60200 und den entsprechenden Submeldungsteilen
60201 bis 60205. Da jedoch die Forderung ansteht, immer alle Meldungsteile
mitzuversenden, Absatz 6.2.6 OCIT_O_Lstg, wäre es natürlich speicherplatzmäßig
sinnvoller anstatt der Verkettung allein nurdie Nachricht 60206 mit dem kompletten
Istvektor zu versenden welche den Overhead verkürzen würden.
Die Nachricht 60206 ist gemäß XML nicht als Hauptmeldungsteil deklariert,
was zwar der XML Definition eines Meldungsframes nicht entgegensprechen würde,
jedoch der Beschreibung in O_Basis 4.2.8, welcher als ersten Meldungsteil einen
Hauptmeldungsteil vorsieht. Die Verwendung von 60200 als Hauptmeldungsteil
für 60206 scheint aber eher unvernünftig, weil damit die Störmeldung
doppelt versendet werden würde.
Daraus resultieren nun folgende Fragen:
Besteht das Zustandsarchiv aus
a) Einer Kette aller Meldungsteile 60200 bis inkl. 60205
b) einer Kette der Meldungsteile 60200 und 60206
c) aus dem Meldungsteil 60206 alleine
Wenn 60206 verwendet wird, sind dann die Meldungen 60200 bis 60205 zusätzlich
zu erzeugen oder damit hinfällig, bzw. vice versa ?
A: Die Beschreibung in OCIT-O-Basis zum Aufbau einer Meldung ist so zu verstehen,
daß der erste Meldungsteil einer Meldung immer implizit der Hauptmeldungsteil
der Meldung ist, von dem sich z.B. der Degree der Meldung ableitet. Hier ist
der Klassenname im xml-Modell möglicherweise etwas unpräzise oder
mißverständlich. Es ist technisch kein Problem, eine Meldung, die
von der Basisklasse MELDUNGSTEIL abgeleitet ist, als 1. Meldungsteil, also
Hauptmeldungsteil zu verwenden. Genauso kann eine Meldung, die von HAUTPMELDUNGSTEIL
abgeleitet wird, als Nebenmeldungsteil verwendet werden.
Normalerweise besitzt der erste Meldungsteil immer eine Vorgangskennung. Im Falle des Istvektors gibt es eine Sonderstellung, da viele der enthaltenen Parameter eigene Vorgangskennungen besitzen. Daher ist BzIstvektor nicht von MELDUNGSTEIL abgeleitet.
Zur Verwendung des Betriebszustandsarchivs: In den bisher erfolgten Implementierungen wird ausschließlich die Meldung 1:60206 ins Betriebszustandsarchiv geschrieben. Die übrigen Meldungen in Verbindung mit 1:60200 sind für dieses Archiv ohne Bedeutung. Sie sind dennoch nicht obsolet, da die Meldungen, die einzelne Elemente des gesamten Istvektors repräsentieren, zentralenseitig Anwendung finden.
F: Listen
Ich habe eine Frage zu den Listen. Ich will in eine Liste das Folgende
speichern, z. B. für manche Detektoren die Werte (1 oder 0) jede Sekunde.
Ich habe mit AuftragZykl getestet. Für AESignalbildFrame war es einfach
weil:
<STRUCTDOMAIN>
<NAME>AESignalbildFrame</NAME>
<DESCRIPTION>Struktur der Auftragsframes für Aufträge vom Typ
AESignalbild</DESCRIPTION>
<MEMBER>1</MEMBER>
<OTYPE>296</OTYPE>
<DECL>
<NAME>Signalbild</NAME>
<DESCRIPTION>Aktuelles Signalbild</DESCRIPTION>
<REFERENCE>
<MEMBER>1</MEMBER>
<NAME>SIGNALBILD</NAME>
</REFERENCE>
</DECL>
</STRUCTDOMAIN>
Und ich weiss ob es grün, rot, gelb, usw. für jedes SignalBild. Aber
für AEBinar..:
<STRUCTDOMAIN>
<NAME>AEBinaerFrame</NAME>
<DESCRIPTION>Struktur der Auftragsframes für Aufträge vom Typ
AEBinaer</DESCRIPTION>
<MEMBER>1</MEMBER>
<OTYPE>295</OTYPE>
</STRUCTDOMAIN>
Das bedeutet das ich bekomme keinen Wert wenn ich Konfigure die Liste, nur die Reference (1, 2, ...). Wie kann ich den Detektor Wert belommen? Wie kann ich speichern was ich bekomme wenn ich einfach DigEingang.GetWert (500.16) mache und ich bekomme Wert (TRUE/FALSE)?
A: Dies hat mit der unterschiedlichen Behandlung des Auftragselements AEBinaer zu tun. Wird dieses Auftragselement zu einem MWAuftragsAbtastAB hinzugefügt so bekommt der Zustand des DigEingangs kein zusätzliches Byte im Auftragsframe, sondern wird im höchstwertigen Bit der Subsekunde vom Auftragsframe gespeichert (siehe Kapitel 4.5.2.5 im Lstg). Wird das Auftragselement AEBinaer mit einem anderen Auftrag (z.B. AuftragZykl) verwendet, so wird der Zustand des DigEingangs in einem zusätzlich Byte gespeichert.Da diese „doppelte Verwendung“ nicht im XML abgebildet werden konnte, ist nur die erste Variante dort definiert.
F: Beschreibung des IstVektors
Uns ist aufgefallen, dass bei der Beschreibung des IstVektors im Dokument OCIT-O_Lstg_V2.0_A01 Diskrepanzen zur Beschreibung in der XML Datei besteht: Gemäß XML wird die Istvektormeldung (1:60206) als Meldungsteil (der Hauptmeldung 1:60200) beschrieben, in der Lstg als "Haupt-Meldungsteil" (somit eigenständig).
A: Die Beschreibung in OCIT-O_Lstg_V2.0_A01 bezieht sich auf den Hauptmeldungsteil KnotenBetriebszustand 1:60200 als Element des Betriebszustandsarchivs. Der Hauptmeldungsteil wird aus den Daten des Istvektors 1:221 gebildet, die im Meldungsteil BzIstVektor eingetragen werden. Die Zeit der letzten Änderung ist dann dort zu finden.
F: Auftrag mit mehreren Auftragselementen
Werden bei einem Auftrag mit mehreren Auftragselementen in einem Auftragsframe immer alle Auftragselemente geschrieben, auch wenn sich nur ein Auftragselement ändert (weil die AE-Nr nicht im Auftragsframe enthalten ist sondern nur die Zustandsdaten)? Wenn dem so ist, fände ich das Schade, denn das würde aus meiner Sicht eine erhebliche Einschränkung bedeuten! Wozu gibt es dann die AESiplOnline und AEAPWertVektor, außer dass sich der VSR ein wenig Konfigurationsaufwand spart?
A: Wie richtig vermutet werden immer die Daten von allen Auftragselementen eingetragen. Wenn die Zentrale nur die reinen Änderungen ins Archiv eingetragen haben möchte, muss Sie für jedes Element einen eigenen Auftrag anlegen. Es ist also keine Einschränkung, da man damit zum gleichen Ziel kommt.
Die Auftragselemente AESiplOnline und AEAPWertVektor sind nur zur schnelleren bzw. einfacheren Konfiguration der Archive durch die Zentrale da.
F: Prozentuale Füllgradgrenzen bei Listen:
Sie erfordern aus unserer Sicht gleichzeitig eine Festlegung der Listengröße. Bsp. 90% Füllgrad bei 1MByte Listengröße (Liste 32,35) macht in der Praxis wenig Sinn.
A: Listen werden vorzugsweise gepollt, deshalb ist das von Füllgrad abhängige Event untergeordnet und nur für einen unerwartete Betriebsfall gedacht.
F: Trigger: Werden diese praktisch eingesetzt?
Verwendung am Beispiel AEAggregiert, AEAPWert, AESiplOnline.
A: Trigger wurden für die umlaufbezogene Datenerfassung konzipiert. Sie werden zur Zeit nicht verwendet, müssen aber implementiert werden.
F: AEAggregiert auf Programmumlauf bezogen
Wie könnte dies mit den bestehenden Objekten AEAggregiert und AuftragZykl gelöst werden?
A: Es sind verschiedenen gerätespezifische Lösungen möglich, z. B. die Verwendung von AP-Variablen. Auch die Verwendung des Triggers (siehe Pkt.8) ist möglich, allerdings gibt es dabei Einschränkungen z. B. bei Synchronisiervorgängen.
F: Ein Hersteller vertritt den Standpunkt, dass bei Archiven, die nicht instanziiert seien (nicht konfiguriert), diese bei Liste::Get auch keine dynamischen Attribute liefern können (die Lichtsignalsteuerungszentrale in N soll konkret das Attribut „Running“ auswerten). Wir vermuten, dass diese Lstg dann einen negativen ReturnCode liefern würden. Andere Herstelle vertreten den Standpunkt, dass die Archive immer instanziiert sind und somit auch immer die dynamischen Attribute liefern können. Welche Aussage ist konform zum Standard?
A: Die Instanziierung erfolgt durch den Hersteller. Nicht instanziierte Archiv existieren nicht, Get liefert Err_Path_Val als Ergebnis. Bei nicht konfig. Archiven liefert Get das Ergebnis.
Kommunikation, Adressierung und Ports
F: Fehlerbehandlung in der btppl Library
Bei einem unsere Tests sind wir heute darauf gestoßen, dass die btppl
Library in keiner Routine keine Fehlerbehandlung durchführt, wenn eine
Speicheranforderung mit btppl_malloc einen Nullpointer zurückliefert,
da kein Speicherplatz in der gewünschten Größe bereitgestellt
werden kann.Dies ist insoweit bedenklich, da sich die Telegrammlängen
mit Ocit2.0 wesentlich erweitert haben. Aus programmtechnischer Sicht bleibt
somit die Möglichkeit bestehen, dass eine die btppl library verwendende
Software abstürzt oder ein eigenartiges Verhalten an den Tag legen kann,
was dem sicherheitstechnischen Umfeld der Applikation wohl nicht entspricht.Wir
bitten dringend um Information wie mit diesem Umstand umgegangen werden soll.
A: Grundsätzlich gilt:
Die btppl lib ist eine Referenzimplementierung. Es steht Ihnen frei die Lib
zu benutzen oder so wie viele Firmen das machen, das Protokoll selbst umzusetzen.
Selbstverständlich aktualsieren wir die Lib mit jeder Ausgabe der Schnittstelle.
Die btppl lib verwendet zur allgemeinen Speicherverwaltung die Funktionen:
BTPPLDLL_API voidptr btppl_btppl_malloc(int size);
BTPPLDLL_API void btppl_btppl_free(void *buf); Zum verwenden von Telegrammspeicher
die Funktionen:
BTPPLDLL_API void * btppl_tg_alloc(size_t len);
BTPPLDLL_API void btppl_tg_free(void * p);
Diese verwenden malloc, free. Die Applikation kann die Funktionen anders implementieren.
An der Stelle wo eingehende Telegramme im Speicher abgelegt werden (Funktion
btppl_tcp_connection_on_ready_receive), führt die lib schon eine Fehlerbehandlung
bei Speichermangel durch, sie schliesst die Verbindung. Ein Test welcher die
Reaktionen der lib bei Speichermangel in allen möglichen Fällen prüft
hat nicht stattgefunden.
F: Kann man die Anzahl der Meldungen bei einer Kommunikationsstörung
verringern?
A: Die Kommunikation wird sowohl von den FG als auch der Zentrale überwacht.
Das FG überwacht in mehreren Ebenen: optional durch Leertelegramme, auf
der PPP-Ebene und über TCP-IP. Die meisten Kommunikationsstörungen
sind nur temporär und „heilen“ sich selbst. Bedingt durch
jeweilige die für die Erkennung einer Kommunikationsstörung gewählten
Technik, können die Entstehungszeiten der Meldungen „Kommunikationsstörung“ in
der Zentrale und im Feldgerät erheblich voneinander abweichen! Es werden
jedoch Meldungen erzeugt. Um fehlerhafte Interpretationen des Zeitpunkts des
der Netzausfalls zu vermeiden, soll die in der Zentrale angezeigte Netzausfallmeldung
nur von der Meldung „Netz Aus“ des Standard-Meldearchivs abgeleitet
werden. Zur sofortigen Information kann das EvListe::OnNetzAus() als Status
angezeigt werden.
F: IP address for a new device
IP address for a new device (added by 1:815, method 101) is supposed to
be obtained via DNS ? i.e. expected procedure to add new device record to controller
is -
1. cetral sends 1:815, method 101 specifying znr/fnr of new device
2. (optionally) central sends 1:817, method 100 to setup/change password for
this device now, when controller wants to contact (for any reason) newly added
device it assembles fqdn (fg<fnr>.z<znr>.domain) and runs gethostbyname
to obtain
it`s address ?
A: All correct!
F: The events (from controller to central) should be sent to PHP, PNP or whatever
of these ports ?
A: All events an PHP.
F: Messages arrive
concurently to both ports PHP, PNP
What is expected behaviour of the controller when the two messages arrive
concurently to both ports (PHP, PNP) or even when request arrives to PHP port
at the time the request on PNP port is processed.
A: Depending upon importance of the instruction the message is sent either
at PNP or at PHP. For the controller the last received instruction is valid.
Regulations about PHP or PNP are implemented in the btppl library (reference
implementation).
F: Otypes in XML
ZModEinAus object as specified in OCIT-O-Lstg_V1_1A02-2, chap. 6.1.8 has
assigned Otype 223; ocit.xml specifies Otype = 206 for the same object; what`s
valid ? for IModEinAus document specifies Otype 229 while ocit.xml 207; what`s
valid ?
A: You are right. Use the Otypes in XML (do so in all doubt). PS: You will
find these mistakes also in the new documents of OCIT-O V2.0 until the new
release A02.
F: Änderung der Passwörter von der Zentrale aus
Im OCIT-O-Funktionsspiegel steht:
Jedes Feldgerät kann folgende Passworte verwalten:
•
Passwort des Feldgerätes selbst (bei Auslieferung vorbelegt mit „OCITPASSWORT“)
•
Passwort der Zentrale (bei Auslieferung vorbelegt mit „OCITPASSWORT“)
•
Passwort der Ersatzzentrale
•
Passwort des zentralen Systemzugangs
•
Passwort für unbekannte IP-Adressen (Default)
Jedes Passwort darf bis zu 12 Zeichen lang sein. Die Passwörter können
von der Zentrale aus geändert werden.
Gibt es genau ein ein Passwort der Zentrale, das zentral geändert werden
kann oder muss jedes Gerät ein eigenes Passwort haben? Sollte die Beschreibung
so gesehen werden, müßte eine Passwortänderung übergreifend über
alle betroffenen Feldgeräte, Versorgungstools und Zentralen synchronisiert
durchgeführt werden.
A: Inhärent in der OCIT Kommunikation (da bidirektional) ist, daß für
jede Kommunikationsstrecke (Zentrale – Feldgerät) ein Paar von Passwörtern
notwendig ist.
Bei Feldgeräten für eingehende Kommunikation das eigene Passwort
und für ausgehende Kommunikation das Passwort des jeweiligen Kommunikationspartners.
Die Zentrale muß für jedes angeschlossene Feldgerät ein Passwortpaar
haben: jeweils eines für eingehenden und eines für ausgehenden Verkehr
zum Kommunikationspartner. D.h. die Zentrale hat viele eigene Passwörter,
nämlich für jedes Feldgerät eines. Ich vermute, diese vielen
eigenen Passwörter der Zentrale sehen Sie als zu aufwändig an. Das
einzig funktionierende Konzept ist es, diese Passwortpaare in der Zentrale
entsprechend zu verwalten. Für das Feldgerät jedoch ist es wünschenwert,
nur ein eigenes Passwort zu haben, das die Zentrale dann ändern kann (um
Kontrolle über die weiteren Kommunikationspartner zu haben).
F: DNS-Server für die Zuweisung der IP-Adresse
Wenn ein DNS-Server für die Zuweisung der IP-Adresse eingerichtet
wird, und dort die IP-Adressen fest vergeben sind, nach welchen Kriterien wird
erfolgt dann die IP-Adress-Zuordnung? Schließlich wird ein RFC-konformer
DNS-Server nichts mit dem BTPPL-Protokoll anfangen können.
A: In der Domain-Datenbank der Zentrale sind den Namen der Geräte (Zentralen
und Feldgeräte) ihre IP-Adressen zugeordnet. Festlegungen zu den Namen
der Geräte finden sich in OCIT-O Protokoll Okt. 6.2.
Beim Profil 1 erfolgt die Zuweisung über das PPP / CHAP Protokoll (siehe
auch OCIT-O Profil 1. Kapitel 2.2.2.1 und 2.2.2.2, in denen die ganze Prozedur
der IP-Zuteilung beschrieben ist).
Beim Profil 2 wird für die Identifizierung des Feldgeräts, damit
auch der Zuweisung der IP Adresse und zur Authentifizierung das CLIP-Leistungsmerkmal
(Rufnummernübermittlung) des Vermittlungsnetzes vorausgesetzt, weitere
Vorgänge mittels PPP wie Profil 1.
Beim Profil 3 (Arbeit) wird anstelle PPP für die Zuweisung das DHCP-Protokoll
eingesetzt.
UMTS ist in OCIT-O nicht standardisiert.
F: Berechnung der OCIT-O-Checksumme Gerät
Beim einem Testplatz (als FG) besteht aus Anwendersicht die Anforderung,
dass die im Testplatz gebildeten Checksummen „OCIT-O-Checksumme Gerät“ der
Blöcke 1-4 identisch sind zu denen, die nach der Versorgung des Lstg von
diesem berechnet werden. Dies setzt u.a. voraus, dass die in den Blöcken
enthaltenen Daten keinen Informationen enthalten, die die unterschiedliche
Einbindung von Testplatz und Lstg in das Netzwerk des Gesamtsystems betreffen.
Ich habe mir das diesbezüglich angesehen und keine solche Daten gefunden,
d.h. man kann m.E. nach davon ausgehen, dass die Checksummern identisch sein
werden. Können Sie das bestätigen oder habe ich was falsch gemacht?
A: Man muß darauf achten, die Vorschriften
zur Checksummenbildung in OCIT-O genau einzuhalten (Verfahren und Reihenfolge).
Sinn und Zweck dieser Prüfung ist, zum Planungszeitpunkt, ohne
die Versorgung in das Lichtsignalsteuergerät zu übertragen, eine
Checksumme zu erzeugen, die nach einer Versorgung auch im Lichtsignalsteuergerät
erzeugt werden soll.
F: Port-Bindung der btppl-Library
Uns ist aufgefallen, dass die durch die btppl-Libray verwendeten Server-Ports (listen auf 2504 (PHP), 3110 (PNP), 5001(Trace-Port)) immer an die IP-Adresse 0.0.0.0 gebunden sind. Durch diesen Umstand ist es nicht möglich, zwei OO-Treiber auf dem gleichen System zu starten. Sinnvollerweise sollte die Library nur diejenige IP (oder Namen) binden, auf der die Zentrale tatsächlich läuft. Diese IP wird der Library in der Datei ocit_route1 ja auch mitgeteilt. Ist dies ein bekanntes Problem, oder haben wir etwas übersehen, oder ist die Anwendung der Library grundsätzlich anders gedacht?
A: Das Binden an die Adresse 0.0.0.0 erfolgt zur Vereinfachung des Verbindungsaufbaus. Da Bei OCIT-O die Zentrale die Verbindung zum Gerät aufbaut existiert die Schnittstelle, zum Zeitpunkt des Starts der BTPPL-Lib unter Umständen noch nicht. In der Datei ocit_route1 steht in in der Regel nicht die IP-Adresse des Geräts sondern deren DNS-Name der über den DNS-Service der Zentrale aufgelöst werden muss. Bei fehlender Verbindung des Geräts zur Zentrale ist keine Namensauflösung möglich, d.h die IP-Adresse des Geräts ist dann nicht bestimmbar.
Wird die BTPPL-Lib nicht an die Adresse 0.0.0.0 gebunden, müssten nach jeder Verbindungsunterbrechung (z.B. PPP) die Serverports neu an die neue Instanz des PPP-Interfaces gebunden werden. Dazu müsste die Konfiguration der BTPPL-Lib von außen über die ip-up und ip-down Skripte angestoßen werden. Dies wurde damals aus Komplexitätsgründen nicht favorisiert. Aus Gerätesicht war ein Betrieb mit mehreren BTPPL-Serverprozessen nicht vorgesehen. Die Btppl-Lib unterstützt aber sehr wohl die gleichzeitige kommunikation mit mehreren Clients. Es ist aber möglich weitere Instanzen der Btppl-Lib mit der Option "Client-Only" zu starten. Damit ist es möglich auf einem Rechner einen Serverprozess und mehrere Clientprozesse zu starten. Bei der BTPPL-Lib handelt es sich um eine Beispielimplementierung des BTPPL-Protokolls, die für eigene Zwecke verändert werden kann.
F: BTPPL-Telegrammgrößenbegrenzung
Seit Extensible... mit 4 Byte Datenlänge, kann die Objekt- und Telegrammgröße den phys. FG-Speicher übersteigen. Wäre eine Festlegung auf eine max. BTPPL-Telegrammgröße möglich/sinnvoll?
A: Max. Größe der BTPPL-Telegramme ist 1 MByte. Die Geräteausstattung muss entsprechend sein. Bei zu großen Telegrammen wird der Fehlercode TOO_MANY zurückgegeben. Eine Verarbeitung von Telegrammen > 1 MByte ist ein Thema für OCIT-O Version 3.
F: Werden Meldungen erzeugt, wenn bestimmte Funktionen vom FG nicht unterstützt
werden?
A: Bei negativen Returncodes werden vom Feldgerät keine Meldungen erzeugt.
Die Erzeugung einer Meldung auf Basis des negativen Returncodes ist optionale
Aufgabe der Zentrale. Der jeweilige Funktionsumfang ist dabei herstellerspezifisch.
F: Welchen Fehlercode muss das Feldgerät zurückgeben, wenn ein Get
auf eine Liste erfolgt, die nicht existiert?
A: Fehlercode bei Get auf Liste soll sein:
ERR_PATH_VAL</NAME>
<
DESCRIPTION>Keine Instanz zu angegebenem Pfad (Wert) gefunden</DESCRIPTION>
<
VALUE>17</VALUE>
F: Meldung 1:60203
Ist es richtig, dass die Meldung 1:60203 keinen %3CREFPATH_DATA%3E Eintrag
besitzt und somit die Zuordnung der Teilknotenzustände zu deren Teilknotennummer
implizit erfolgt, oder ist hier das xml Dokument fehlerhaft?
A: Die Zuordnung der Meldung geschieht über das Element Teilknoten. Dies
hat einen PATHPART TeilKnotenRef.
F: Object 0:817 (RemoteDevice)
OCIT-O-Basis_V1.1_A02, chap. 4.1.3 defines for object 0:817 (RemoteDevice),
method 100 RetCode = OK or NO_CENTRAL; however, the ocit.xml
has no number assigned to NO_CENTRAL response code; does it mean each manufacturer
should define it`s own number to this response code or ?
A: Thats a mistake, but we think this usecase NO_CENTRAL is not realistic.
We will revise that object in OCIT-O V2.0 release A02. Use Ret.Code 32: PARAM_INVALID
if action was not OK.
F: Es wurden unterschiedliche Interpretation darüber festgestellt, ob und wie der Wechsel einer Zeitquelle zu melden ist, wenn tatsächlich kein Zeitsprung vorliegt. Wir haben für diesen Fall die Meldung „60026 „Zeitsprung“ mit Delta = 0 Sekunden mit Angabe der neuen Zeitquelle gefordert. Ist diese Forderung standardkonform oder projektspezifisch?
A: Diese Forderung ist projektspezifisch und widerspricht dem Standard. Wir empfehlen die standardkonforme Verwendung der Meldung „Uhr gestört“ (60016).
F: Es wurden diverse projektspezifische Meldungen gefordert. Ein Hersteller vertritt nun den Standpunkt, dass der Betreiber die Meldungen „definieren“ muss. Gibt es dazu im Standard genauere Festlegungen, wie der Vorgang der „Definition von projektspezifischen Meldungen“ genau ablaufen soll/muss?
A: Das Abstimmungsprocedere ist nicht festgelegt. Das Ergebnis muss lt. Standard eine TYPE-Datei sein.
F: Wie lange dauert es, bis eine neue Versorgung aktiv wird?
A: OCIT-O Lstg V2.0 macht bez. der Versorgung keine Vorgaben für einen
bestimmten Gerätezustand. Prinzipiell kann es 1 bis 2 Umläufe dauern,
bis die neue Versorgung aktiv wird. Bei neuen Signalplanversorgungen muss in
den neuen Plan gewechselt werden.
F: Command arrives from central just before (~ a few seconds) it should be executed
What should be the behaviour of the controller when some command arrives
from central just before (~ a few seconds) it should be executed; e.g. at 13:59:58
arrives the command to change signal program (ZSignalprogramm) which start
time is set to 14:00; it`s
most likely that currently runnig signal program is "somewhere in the
middle" of it`s cycle; since we expect the transition from one signal
program to another has to be smooth there is very little chance the new signal
program can start at 14:00 as requested.
A: Start time will be helpfull by dial on connections or in very large systems.
Is should be set in order of the expected transmission und transition time.
In your case the transition happens after signal program is ready to change.
(F: Just for clarity: Does your answer implies the start_time attribute in
the commands (e.g. ZSignalprogramm) in fact denotes the time the corresponding
action SHOULD BE started, but it`s not absolute necessity the new (e.g. signal
program) actually starts the execution precisely at the time specified ?
A: Yes, you are right!)
F: Synchronization in green waves
Synchronization in green waves - unfortunately we don`t understand philosophy
of the OCIT implementation at all; we need some more glue to be able to correctly
implement green wave synchronization mechanism; without additional informations
the "specification"
at OCIT-O-Lstg_V1_1A02-2, chap. 5.1 is not enough to do that (or better to
do it in a way which guarantees devices from different vendors will be interoperable)
A: There are 4 common used methods for synchronization (Rückrechenverfahren).
All methods deal with the number of seconds since a point of time in the past,
e.g. since 1 January 1970. Each of the methods generates a refence point of
time for synchronisation of all controllers in a green wave system. “Signalzeitenversatz” means
the offset time to the reference point of time for a dedicated controller in
the green wave. Look at chapter 3.4 in the definition for OCIT-O version 2.0:
OCIT-O_Lstg_V2.0_A01
F: Time zones
According the OCIT-O_Lstg_V2.0_A01, chap. 3.4 the value of UTC_1_1_1980OFFSET
is set to 315529200. This value is about 3600 less than the time difference
between 1.1.1970 and 1.1.1980 which is actually 315532800 seconds. What`s the
reason for this setup ? What value to use in calculation - the correct one
or the one specified in OCIT-O_Lstg_V2.0_A01, chap. 3.4 ?
A: The offset dependents on the time zone. 315529800 is correct for GMT. The
315529200 indicated in the document is correct for the 1.1.1980 MEZ, which
is reached one hour earlier.
F: Time zones
As to methods that take summer time into account, i.e. RRV 1.1 and RRV Mitternacht;
the calculation during standard-to-summer time transition is clear. Question
is what means the "Beim Rucksprung gilt dies analog.". Does it mean
at the time of transition from summer-to-standard time (i.e. at UTC + 1hr.)
we "cut out" 3600 seconds from RRS ? i.e. for RRV Mitternacht method
the calculation should be done as follows?
seconds_since_midnight RRS UTC CET CEST
...
10798 10798 0:59:58 1:59:58 2:59:58
10799 10799 0:59:59 1:59:59 2:59:59
10800 7200 1:00:00 2:00:00 3:00:00
10801 7201 1:00:01 2:00:01 3:00:01
10802 7202 1:00:02 2:00:02 3:00:02
...
If the above is correct, depending on the "Umlaufzeit" the "jump" in
RefZeit can happen at the time of summer-to-standard time transition - agree
? Or, "..... dies analog" means we make as "nothing happened" at
the time of summer-to-standard time transition and the rest of the day (in
case of RRV Mitternacht method) or the rest of the year (in case of RRV 1.1
method) we continue calculation according the "summer time" (i.e.
with no "cut out" of 3600 seconds)? Note: one more line in examples
(at OCIT-O_Lstg_V2.0_A01, chap. 3.4) for e.g. 28.10.2007 03:10:00 would avoid
the above question.
A: The procedure is historically conditioned. In the case of time conversion
the Rückrechenzeit shifted 1 hour. The controller must consider this when
synchronizing.
F: ZModEinAus
What is the relationship of ZModEinAus (1:206) and ZVAEinAus (1:230) objects;
ZModEinAus "enables" ZVAEinAus ? i.e. only if ZModEinAus set to "Ein" status
the status of the ZVAEinAus (and other related objects like ZOepnvEinAus, ZVAIndividualverkehrEinAus,
...) is takeninto account ?
A: ZModEinAus is an abstract base class for ZVAEinAus, ZOepnvEinAus, ZVAIndividualverkehrEinAus
and ZProjectEinAus. The method Schalte is only called for instances of the
contrete classes, never for the abstract base class. ZVAEinAus influences only
the behaviour of ZOepnvEinAus and ZIndividualverkehrEinAus: if ZVAEinAus is
true, the other to are taken into consideration. If ZVAEinAus is false: not!
F: Is there currently any OCIT object by means of which we can instruct the
controller to ignore local manual switching (i.e. from the panel on the controller)
of the traffic lights ?
A: No.
F: Beginnt die Zählung der projektspezifischen Modifikationen (ProjModnr)
mit 0
oder mit 1 ?
A: 0 bis 12. Welche Nummer gewählt wird oder mit welcher Nummer die Modifikationen
beginnen ist projektspezifisch zu vereinbaren.
F: Wieviele projektspezifische Modifikationen sind möglich?
A: Es sind 13 projektspezifische Modifikationen möglich. Zusammen mit den 3 Standardmodifikationen ergeben sich 16 mögliche Modifikationen. Das im Dokument OCIT-O Lstg beim Objekt 1:660, Tagesplan, steht:
Anzahl |
Anzahl folgender Modifikationen |
||
Modifikation[0 … 13] |
Projektspezifische Modifikationen |
||
|
Nr.ui1 |
Nummer der Modifikation |
|
Wert |
Wert der Modifikation. Zustand keiner(0) bedeutet, dass dieser Befehl die Modifikation nicht beeinflusst. |
||
ist darauf zurückzuführen, dass die Denk- und Bezeichnungsweise aus der OCIT-O XML (Schreibweise [0 … 13] übernommen wurde. Dort steht bei den Modifikationen auch korrekterweise die Anzahl Mincount = 0 und Maxcount 13, als max. Anzahl. Ebenfalls korrekt ist es, dass in der aus der XML erzeugten HTML Darstellung des Objekts 1:660, Tagesplan, der Index 0- 12 erscheint. Damit werden die max. 13 projektspezifischen Modifikationen adressiert. Im Dokument werden wir demnächst den Text ergänzen und auf die max. Anzahl hinweisen.
F: Standardmodifikationen
Über den "ZentralenSchaltwunsch (1:220) - Get Modifikations[0..15] : ZModEinAus" werden auch die drei Standardmodifikationen mit abgefragt. Diese belegen dann die Modifikationen 0-2 (oder 13-15?). Projektspezifische Modifikationen beginnen ab 3 (oder 0?). (Liegt hier ein Fehler vor? 3+14 != 16)
A: Die projektspezifischen Modifikationen haben im Pfad (Adressierung des Objekts) den Index 0..12. Diese Pfade werden in den im IstVektor bzw. ZSchaltwunsch übermittelten projektspezifischen Modifkationen zur Identifizierung verwendet (Member/OType und der Index als Bezeichnung der projektspezifischen Mod.)
F: ModEinAusZustand
ModEinAusZustand unterstützt nur „keiner/Ein/Aus“. Werte > 3, die von Instations-Seite her existieren können werden vom OO-Treiber mit Ein interpretiert.
A: In OCIT Outstation Definitionen (Dokumente) haben die Modifikationen nur die definierten Zustände (0 = unbestimmter Zustand, 1 = ausgeschaltet, 2 = eingeschaltet). In der OCIT -O XML ist aber ein maximal möglicher Wertebereich bis 4 (Index 0 bis 4, also 5 Werte) festgelegt, dies wurde von OCIT-I übernommen. Die zusätzlichen Werte 3 und 4 können deshalb projektspezifisch festgelegt werden. Davon wurde in der Vergangenheit bereits Gebrauch gemacht (eine Modifikation zur Schildersteuerung). Wenn Werte übertragen werden, die im FG nicht unterstützt werden ist dies jedenfalls ein Fehler im System. Wie die FG darauf reagieren ist nicht festgelegt.
F: Tagespläne der JAUT
In den Tagesplänen der JAUT werden die Befehle mit STRUCTDOMAIN JautBefehl 1:634 abgebildet. Hierzu unsere Fragen:
1. Muss jeder JautBefehl immer alle Steuerbefehle beinhaltet und die nicht zu verändernden mit NULLVALUE, „keiner“, … gefüllt werden oder können einzelne Steuerbefehle weggelassen werden? Ich lese die Lstg-XML so, dass bis auf die TkZustand (MINCOUNT=0) und Modifikation (MINCOUNT=0) immer alle anderen Steuerbefehle enthalten sein müssen!? Oder bezieht sich der MINCOUNT nur auf die Anzahl der jeweiligen Objekte im Lstg. Wenn also ein Lstg x Teilknoten hat, müssen auch für diese immer Steuerbefehle, dann ggf. mit „keiner“ vorhanden sein?
2. Können in der gleichen JAUT-Tabelle mehrere JautBefehle mit der gleichen Uhrzeit eingetragen werden?
3. Falls die Antwort auf 2. „ja“ ist: gibt es Vorgaben zur Abarbeitung von JautBefehlen mit der gleichen Uhrzeit in einer Jaut-Tabelle durch das Lstg? Wenn ja, welche?
4. Ist es zulässig, dass die JautBefehl in anderer als in aufsteigender Reihenfolge in den Tagesplänen der JAUT versorgt werden?
5. Falls die Antwort auf 4. „ja“ ist: ist zu erwarten / zu befürchten, dass das Lstg die JautBefehle umsortieren könnte / wird und sich damit die Daten der Pfade und somit auch die OCIT-O Check-sum. Gerät für diesen Block ändern wird?
6. Gibt es Ihrer Meinung nach zu diesen Fragen „Freiheitsgrade“ im Standard, zu denen wir bei der Leistungsbeschreibung für ein Lstg Festlegungen treffen müssen?
A:
ad 1: Jeder Tagesplan muss mindestens einen Eintrag um 00:00 haben, der den ersten Sollzustand für diesen Tag enthält. Für alle vorhandenen TK müssen die Steuerbefehle und Modifikationen vorhanden sein. Weniger oder mehr werden abgelehnt. „keiner“ und NULLVALUES sind in der JAUT nicht erlaubt.
ad 2: Nein, wegen Definition zu Frage 1
ad 3: Entfällt, da Antwort auf Frage 2 Nein ist
ad 4: Nein, wegen der Eindeutigkeit der Checksummenberechnung.
ad 5: Entfällt, da Antwort auf Frage 4 Nein ist
ad 6: Nein
F: Wie ist die IBetriebsart zu setzen, wenn es unterschiedliche Befehlsquellen für die Schaltwünsche gibt?
A: Gemäß Schalttabelle (Lokal Zeitsteuerung und Zentrale). Übrige Betriebsarten Sonderbetrieb, Eigensteuerung, Handstoppbetrieb, Lokal Fix, gemäß Spezifikation.
F: Systemzugang als VD-Server
Laut OCIT 2.0 soll der Systemzugang auch als VD-Server dienen können.
Das impliziert, dass auf den Btppl-Ports eines Feldgeräts gleichzeitig
mehrere Verbindungen geöffnet werden können. Dort wo die Standard-Btppl-
Bibliothek verwendet wird, ist dies auch der Fall. Bedeutet das nun, dass ich
voraussetzen kann, dass jedes Feldgerät diese Eigenschaft hat?
A: Aus der Formulierung in OCIT-O_Basis Kap. 4.1 zentraler Systemzugang folgt,
dass ein OCIT- FG mehrere Verbindungen beherschen muss, es muss die Zentrale
und den zentralen Systemzugang simultan bearbeiten können.
F: Alternative way/protocol
Instead of btppl containers specified in OCIT is it possible to use another
way/protocol (sftp, ssl, ...) for remote loading of the configuration data
into the controller (feldgeraete): If used (the alternative way/protocol) it
saves a time/development effort since existing "Service tool" doesn`t
need to be modified to support btppl; the goal to limit open ports just to
the btppl`s PHP, PNP shouldn`t be the case, since ocit concept counts with
other open ports/protocols anyway (NTP, DNS, ..)
A: It is possible to use your own protocol for this purpose when you are the
only user of the remote data connection. If you use the connection via the
central unit “Zentraler Systemzugang” then you have to use the
standard (because of firewalls and for later use with OCIT-O V2.0)
F: Ist der OCIT-Zenrale Systemzugang unabhängig von der OCIT-Outstations Version
Im Rahmen der Diskussion der Kompatibilität der OCIT-Versionen ist
die Frage enstanden, ob ein zentralenunabhängiges OCIT-Versorgungsgateway,
wie es im Zuge der Disksussion der OCIT-Instations VD (2.0) spezifiert wird,
mit Steuergeräten mit OCIT-Outstations Version 2 über den Zentralen
Systemzugang einer Zentrale, die mit einer OCIT-Outstations-Schnittstelle in
der Version 1.1 geleifert und ausgerüstet wurde, zusammenarbeiten kann?
Mit anderen Worten, ist der OCIT-Zenrale Systemzugang unabhängig von der
OCIT-Outstations Version ?
A: Verbindungstechnisch ist der zentrale Systemzugang in V2.x genauso wie in
V1.x eine geroutete TCP/IP Verbindung mit Standard-Interface. In Version 1
fehlt jedoch die nach Benutzergruppen "Anwender" und "Hersteller" getrennte
Zugangsberechtigung, wie sie in V2.x vorgesehen ist. Der zentrale Systemzugang
muss daher für V2.x mit dieser Funktion nachgerüstet werden. Dann
funktioniert er mit V1.x und V2.x.
F: How to make html-files with typetool.exe (version date 25.03.2008)
A: copy files
basis-type_v1.1_A02.xml
lstg-type_v1.1.xml
ocit-o-dtd_v1.0.dtd
typetool.exe
in one directory e.g type (Attention: Unlike the older versions of the typetool
it is not necessary to merge basis.xml + lstg.xml in one file!)
Input MS-DOS Window:
c:\users\Besitzer>cd type
c:\users\Besitzer\type>typetool.exe basis-type_v1.1_A02.xml lstg-type_v1.1.xml –h
-f
File basis-type_v1.1_A02.xml eingelesen
File lstg-type_v1.1.xml eingelesen
Referenzen geprueft
Find html-files in your directory type.
F: password encryption
OCIT-O-Basis_V1.1_A02, chap. 4.1.3 defines the mask for password encryption
as concatenation of the following attributes:
SHA1 ( altes OCIT-Passwort+'.'+ZNRZieladresse+'.'+FNRZieladresse+SCHLEIER+altes
OCIT-Passwort+'.'+ZNRZieladresse+'.'+FNRZieladresse ).
On the other side the typetool`s source file (btppl_remotedevice.c) is the
mask defined as concatenation of the following attributes:
SHA1 ( altes OCIT-Passwort+'.'+ZNRZieladresse+'.'+FNRZieladresse+'.'+SCHLEIER+altes
OCIT-Passwort+'.'+ZNRZieladresse+'.'+FNRZieladresse )
i.e. there is one dot more specified (after the FNRZieladresse); thus - what
rules is valid ?
A: Use the rule btppl library (reference implementation).
F: Typetool Linux
Es gibt einige nicht definierte Abhaengigkeiten beim build vom
typetool unter einem aktuellen linux. die readme.txt
(Sourcen_Protokoll_u._Typetool/README.txt). Die Datei enthaelt eine Anleitung
zum bauen die nicht funktioniert. es muss scheinbar mindestens eine "gnome-xml" (==libxml2
?) library inkludiert werden. Fuer WinNT ist die Abhaengigkeit zu gnome-xml
aufgeloest, fuer linux Systeme scheinbar nicht. Gibt es eine version vom typetool
bei der ein build unter linux problemlos geht? Das Makefile fuer btppl
(Sourcen_Protokoll_u._Typetool/svt/dvp/ocit/btppl/linux) enthaelt einige
Referenzen auf eine (siemens?) testzentrale. Der referenzierte
Sourcecode ist scheinbar nicht auf der OCIT cd vorhanden. Wo ist dieser
verfuegbar damit die Referenz- / Testsoftware gebaut werden kann? Unsere OCIT
Outstations cd ist von 07.2004. Gibt es updates fuer den gelieferten Quelltext
oder Bugfixes? Wenn jA: wie bekommt man diese updates?
A: Zum Thema typetool unter linux: einfach die libxml2-devel installieren (download
z.B. von: ftp://xmlsoft.org/libxml2/) Die Referenzierten Quellen (ich nehme
an es handelt sich um die java interface Klassen) sind nicht nötig um
typetool, libbtppl zu erstellen und zu betreiben. Updates werden an alle Lizemznehmer
ohne extra Anforderung verteilt.
F: Was sind <Interface> und <Implements>?
A: <Interface> und <Implements> wurden bisher nicht verwendet,
bleiben aber als Reserve in der Type Datei enthalten.
F: Testing with typetool
I am testing with typetool and I receive:
List
Respond Methode GetYoungest
1: ret.RetCodeList 0 OK
2: PosNr.LISTPOSNR 0x93e
3: Listversion.LISTVERSION 4
4: SecondFrame[1] !! skipping 1 Secondframe = 10 bytes !!
49 13 f8 c8 1 1 0 0 0 0
I do not understand how I should interpetate the Secondframe
Before this call, in this list, I added a ListJobCycle, and a AEAggregated,
just to obtained each minute the occupancy and the Veh/hour. Each minute
a new secondframe is added, but I dont understand how is loaded the information
in Secondframe[1] and why is not translate.
A: In this case the Typetool is used as a client. Thus the list supply is unknown
and it can therefore not interpret the hexcode.
The hexcode means:
character 1 - 8: Zeitstempel (time)
character 9: Anzahl der Sekundenframes (Number of frames)
character 10: Auftragsnummer (order number)
character 11 Subsekunde (subseconds)
character 12 - 13: Zählung (Veh/hour)
character 14: Belegung (occupancy)
The Typetool will interprets the hexcode, if the trace is evaluated.
Condition: GetListConfig is implemented and the order for the list supply is
contained in the trace.
F: What is expected format of syslog messages?
The test with typetool/feldgeraetesimulator
looks like this:
own znr 0 / fnr 0
hdrlen=17 flags=0 job=0x2335 0 type=0:400 method=102 znr=0 fnr=2
Liste
0: ListenNr.ListenNr 2 Syslog
Request Methode GetSFSince
hdrlen=16 flags=20 job=0x2335 0 type=0:400 method=102 znr=0 fnr=2
Liste
Respond Methode GetSFSince
2: ret.RetCodeListe 1002 SF_NOFOLLOW
3: AbZeit.ZEITSTEMPEL_UTC 0x47e587 24.02.1970 13:50:15
4: AbPosNr.ARCHIVPOSNR 0x1
5: BisZeit.ZEITSTEMPEL_UTC 0x47e588 24.02.1970 13:50:16
6: BisPosNr.ARCHIVPOSNR 0x2
7: Listenversion.LISTENVERSION 0
8: SekundenFrames[2] !! skipping 2 Sekundenframe = 16 bytes !!
0 47 e5 87 1 4d b2
0 47 e5 88 2 4d 3c 4d c6
------
where response can be decoded as
------
0 47 e5 87 UTC
1 anzahl auftragsframes
4d auftragsnummer
b2 data
0 47 e5 88 UTC
2 anzahl auftragsframes
4d auftragsnummer
3c data
4d auftragsnummer
c6 data
----------------
4d is auftragnummer or ??
b2, 3c, c6 is what - data or ???; if data, what`s their meaning ??
is it expected each provider defines it`s own objects to specify the format/meaning
of the messages ?
A: The trace is very weired: 4d ist the index of the Auftrag (Auftragsnummer).
b2 can only be interpreted, if the type of the corresponding Auftrag (4d) is
known, which is not explained in the the question. The syslog archive has no
special format.
F: a) Objekt EvList - Methode 203 (Netz aus)
Kann/Muss/Darf dieses Event im Übertragungsprofil 2 ebenfalls ein Callback
an eine Zentrale auslösen, oder ist diese Meldung über einen Eintrag
in der Liste 36 abzubilden?
b) Objekt Offline Event - Methode 200 (OnNetzEin), Methode 201 (OnConfigruationInvalidated). Sind dies Objekte als Erweiterung der Baisfunktionalität einer Zentrale anzusehen, oder ist diesesObjekt in einem Zentralenmischbtrieb (Profil 1 + Profil 2) ausschließlich für Profil 2 Outstations vorbehalten ?
A: Antwort auf die Frage a):
Laut OCIT-O_Profil 2: Um projektspezifisch festlegen zu können, welche
Meldungen zu einer Callback-Anforderung bei der Zentrale führen können,
wird ein neues Archiv angelegt, das „Offlinearchiv“ mit der Nummer
36.
Laut OCIT-O_Basis_V2.0 Pkt. 3.2.1.2: Dazu benötigen die Feldgeräte
eine Pufferung der Versorgungsspannung (Kurzzeit-USV), um die für die
Meldung benötigten Geräteteile über die notwendige Zeit der
Melderoutine weiter mit Spannung zu versorgen. Es werden zwei Methoden zur Übermittlung
der Information über den Netzausfall definiert, die sich in der Länge
der notwendigen Pufferzeit der Versorgungsspannung unterscheiden.
Variante a) Netzausfall-Meldung über Standard-Meldearchiv
Meldung Netz aus mit Angabe des Ausfallzeitpunkts in das Standard-Meldearchiv.
Um die Meldung aus dem Standard-Meldearchiv abzuholen sind mehrere Transaktionen
notwendig.
Variante b) Netzausfall Meldung über Eventliste
Eine Beispielfirma hat die Callback-Anforderung für Netzausfall im Profil
2 so realisiert: Wenn Netzausfall entdeckt wird, kommt die Callback-Anforderung
und danach EvListe::OnNetzAus() (Variante b). Die Meldung NetzAus wird in der
Liste 36 eingetragen (falls sie konfiguriert wurde) und die Callback-Anforderung
wird nicht nochmals aufgerufen.
Antwort auf die Frage b):
Eine Beispielfirma benutzt das Objekt OfflineEvent (LSA-seitig) nur im Profil
2. Wenn die Zentrale kein Profil 2 unterstützt, wird dieses Objekt auch
nicht verwendet. Bei der Zentrale die gleichzeitig das Profil 1 und 2 unterstützt,
wird dieses Objekt nur für die Anlagen mit dem Profil 2 verwendet. Die
Methoden dieses Objekts haben das Ziel, eine Neukonfiguration der Liste 36
(mit der Meldungen, die zur Callback-Anforderung führen) anzufordern.
Beim Profil 2 kann im Gegensatz zum Profil 1 die LSA, wenn die Stromversorgung
wiederkehrt, die Verbindung mit der Zentrale initialisieren (Callback-Anforderung)
und danach das Event OnNetzEin senden.
F: Liste der unterstützten Funktionen
Sinnvoll wäre es, wenn die Gerätehersteller eine Liste erstellen
würden, in der zum einen eingetragen wird, welche Objekte, Methoden und
Parameter von der Zentrale verwendet und welche vom Steuergerät unterstützt
werden. Nur dadurch ist es der ausschreibenden Stelle möglich, die Anforderungen
an das LStg zu spezifizieren und durch den zweiten Teil einen Abgleich mit
den Leistungsmerkmalen der von den Bietern angebotenen LStg herzustellen.
A: Die Anregung wurde an die Hersteller weitergegeben. Grundsätzlich entsprechen
die Funktionen der Lstgs der jeweiligen Version (alles was verpflichtend ist)
und dem geforderten Geräteausbau (z.B. ÖPNV-Archiv als zusätzliche
Einrichtung). Siehe auch Funktionsspiegel.
F: Hardwareplattformen
Auf welche Hardwareplattformen wurde BTPPL im Rahmen von OCIT schon portiert
und unter welchen Betriebssystemen sind diese lauffähig?
A: Uns bekannt sind Motorola PowerPC und Intel. Als Betriebssysteme sind bekannt
vxWorks, Win32, Linux.
F: Anpassungen der BTPPL – Source
Nach welchem Procedere ist vorzugehen wenn Anpassungen der BTPPL – Source
an bestehende (16 Bit ) Hardware, Compiler, Betriebssystem vorzunehmen sind
?
A: Benötigt wird ein TCP/IP-Stack und diverse Internet-Protokolle (DNS,
SNTP, PING), sowie PPP auf Link-Ebene. Für eine Lowcost-Implementierung
kann btppl auch UDP anstelle von TCP verwenden. Die Anpassung der btppl-Sourcen
an betriebssystem-abhängige Schnittstellen läßt sich in den
Dateien btppl_portab, btppl_osdep durchführen. In der Beispiel-Implementierung
verwendet btppl ein Filesystem zur Speicherung von Konfigurationsdaten. Dieses
müßte sich aber auch umportieren lassen, falls kein Filesystem zur
Verfügung steht.
F: Test equipment
"OCIT-O-System_V1.1_A01" document speaks in chapter 7.1 (Konformität)
about availability of testing tools that ODG members use to prove conformity
of devices with OCIT specifications; there is also mentioned these tools are
available upon request
to subjects which owns OCIT license; these standard tools are supposed to be
the ones supplied on OCIT CD (typetool, felgeraetesimulator btppl, ....) or
some other ones ? can we obtain them ?
A: That was a plan of the ODG at the time of the publication. The financing
did not come off however. So the ODG has no common test equipment. In your
license agreement „Nutzungsvereinbarung“ and on CD therefore such
a tool is not included.
F: Element SignalprogrammV (1:666)
Ich hätte da eine Frage zum Element SignalprogrammV (1:666), im Detail
zu den Schaltungen der SPZeile. Dort gibt es neben den Referenzen auf einen Übergang
auch die Möglichkeit ein Signalbild zu einem Schaltzeitpunkt direkt zu
schalten.
Ist es dort erlaubt alle beliebige Signalisierungen zu schalten, oder besteht
eine Einschränkung auf die definierten Bilder der VD Versorgungselemente
( Frei, Gesperrt, StandardAusBlinken, StandardAusDunkel ) ?
A: Im Objekt SignalprogrammV werden zu den Schaltzeitpunkten immer nur die
Zielfarbbilder angegeben. Das Steuergerät bildet den Übergang vom
aktuellen Bild der Signalgruppe eigenständig anhand der Versorgung.
Sind unter ReferenzUebergang keine Übergange (oder keine mit pasendem
Zielfarbbild) angegeben, wird der Versorgte Standardübergang benutzt.
Ist unter ReferenzUebergang ein Übergang mit passendem Quell- und Zielfarbbild
angegeben, wird dieser statt dem Standardübergang benutzt.
Üblicherweise können unter ReferenzUebergang nur die Übergänge
angegeben werden, die auch in der Grundversorgung vorhanden sind (geräteabhängig).
F: Versatzzeitmatrizen der Versorgung, generelle Frage warum diese überhaupt zum Gerät versandt wird ?
A: Die Geräte kontrollieren darüber die verkehrstechnisch gewünschten Zeiten. Übergeordnet sind die sicherheitsrelevanten Zwischenzeiten. Falls die Geräte die Signalsierung entsprechend der Versatzzeiten schieben, wird Zwischenzeitverletzung gemeldet.
F: Ist es so, dass nur Objekte versorgbar sind, die bereits im Gerät existieren, wie z. B. Signalpläne?
A: Signalpläne müssen im Gerät existieren und können nicht von der Zentrale aus angelegt werden. Deshalb ist es sinnvoll mehr Pläne als aktuell gefordert als versorgbare Reserve zu implementieren. Andere Objekte wie z. B. Tagespläne können z. B. von der Zentrale aus angelegt werden.
F: Ist es richtig, dass der Standard keine Vorgaben macht, wie der Parameter „NetzSpannungOk“ des Objekts „GeraeteStatus“ gesteuert wird, dies also bei Bedarf projektspezifisch festzulegen ist?
A: Der Standard macht hier bewusst keine Vorgaben. Projektspezifische Vorgaben hätten u. U. gravierende Auswirkungen auf die herstellerspez. Hard- oder Software.