Only available in German!
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.
F: Blockweises Versorgen
Die VS-PLUS Worksuite verwendet für die Versorgung der Anlage das OCIT-O
Protokoll. Dabei wird der Block 4 mit der Parameterdatei (VCB Datei) nicht
immer vollständig übertragen, sondern erst im Gerät zu einem vollständigen
Parameter-Satz zusammen gestellt. Im Standard ist folgendes beschrieben :
„Die Versorgungdaten sind entsprechend
ihrer Aufgabe in Blöcke gegliedert. Entsprechend den Festlegungen erfolgt die
Anwenderversorgung immer blockweise, das heißt, auch bei einer Änderung
nur eines Wertes werden immer alle Daten eines Blocks versorgt.“
Das bedeutet für mich, dass der Parametersatz auch immer vollständig übertragen werden muss, oder sehe ich das falsch ?
A: Jeder einzelne Block muss vollständig übertragen und versorgt werden.
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:
Hauptmeldung / Nebenmeldung
Ich bitte um Erläuterung folgender Textpassage, zu finden
bei den Meldungen
1:60006, Feindlichkeit
1:60007, Zwischenzeit
1:60008, Mindestgrünzeit
1:60009, Mindestrot
„Bei …verletzungen, die die Signalüberwachung erkennt, wird dieser Meldungsteil als Nebenmeldungsteil einer Sollbild-Störung gespeichert.“
Frage:
1) Ist als Vorspann dieser Meldungen die Hauptmeldung „Sollbild Störung“ noch
relevant, oder dürfen diese Meldungen auch als Hauptmeldung verspeichert werden
?
2) Wenn diese Meldungen als Nebenmeldung zu verwenden sind, wäre dann das Element VorgangsNummer nicht in der Nachrichtendefinition zu entfernen ?
A: zu 1: Ja, diese Meldungen dürfen auch als Hauptmeldungsteil verwendet werden.
zu 2: Wenn die Verletzung nicht von der Sollbildüberwachung sondern schon vorher erkannt und korrigiert wird, wird die betreff. Meldung als Hauptmeldung mit VorgangsNummer verwendet.
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.