OCIT® Offene Schnittstellen für die Straßenverkehrstechnik / Open Communication Interface for Road Traffic Control Systems  

Home

Aktuell

ODG
Schnittstellen
und Produkte
Download
Spezifikationen

Forum
FAQ
Links
Kontakt


 

 

 

 

 

 

 

 

 

ODG

ODG&Partner

 

 

Impressum

 

 

---------------------- FAQ ------------------------

 

 

Page is only available in German!

 

Zu den Einträgen aus dem gelöschtem Forum (August 2012 bis Juni 2005)


AP-Werte


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.

Archive


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 Konfigurations­aufwand 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äts­grü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.


Meldungen und Return Codes


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.



Schalten


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.

 

Systemzugang


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.


Typetool, Trace


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.


Übertragungsprofil 2


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.

Verschiedenes


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.

Versorgung


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.

 

 

 

Einträge aus dem gelöschtem Forum (August 2012 bis Juni 2005)

 

 

 

55

 

Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Fr 20 Jul 2012 11:14:26 CEST
Betreff: IstbildstoerungSekundaer 1:60011 bei Summenüberwachungen
Hallo,

in manchen Projekten wird gefordert, dass das Lstg bei Ausfall aller Lampen von parallel geschalteten Lampen/Kammern (Gelb-/Grün) einer Signalgruppe eine OO-Meldung erzeugen soll. Die Lstg nutzen dazu die Meldung IstbildstoerungSekundaer 1:60011, die Parameter dieser Meldung werden aber bei parallel geschalteten Lampen/Kammern (Gelb-/Grün) einer Signalgruppe von den Herstellern unterschiedlich genutzt...

Was ist hier gem. dem Standard richtig oder ist der Hersteller hier frei resp. muss der Anwender hier vorgabenmachen, wenn er ein einheitliches Verhalten erreichen will (welche Kammer und welcher Signalgeber sind anzugeben)?

Vielen Dank im Voraus für Ihre Mühen!

ODG (odg@ocit.org)
Datum: Fr 20 Jul 2012 13:06:54 CEST
Betreff: Istbildstörung
Dazu gibt es im Standadrat keine Vorgaben!


54

 

Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Fr 22 Jun 2012 08:46:53 CEST
Betreff: Include- Exclude-Liste
Hallo,

wie wir festgestellt haben, interpretieren und realisieren Lstg-Hersteller die Include- und Exclude-Listen unterschiedlich. Wir interpretieren den Standard so, wie es bei Meldungsauftrag::GetInEx beschrieben ist "Die Include und Exclude-Liste wird zurückgegeben. Alle vom Gerät generierten Meldungen befinden sich entweder in der Include- oder Exclude-Liste des Auftrags.", also nicht nur Hauptmeldungen und nicht nur Teile der vom generierten Meldungen!

Ist das richtig?

Vielen Dank im Voraus für Ihre Bemühungen.

Uwe Jakobi


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Iclude-Exclude Liste
Die Include/Exclude Liste dient als Filter für die einzutragenden Meldungen und da hat es nur Sinn auf den Typ der Hauptmeldung zu schauen und nicht auf die Nebenmeldungsteile.



53

Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Mo 14 Mai 2012 09:05:16 CEST
Betreff: Liste::SetEventDestination
Guten Tag

SetEventDestination scheint die Voraussetzung, dass SetEvent und GetSFSinceWithEvent (= GetSFSince + SetEvent) nicht mit ACCESS_DENIED antworten.
In OCIT-O_Basis_V2.0_A03, Kapitel 5.1.2 Ablauf, Punkt 7 Festlegen des Event-Ziels, wird das im Prinzip auch bestätigt. Mit der Ausnahme, dass wenn KEIN Ziel eingetragen ist (= kein SetEventDestination gemacht wird???) per Default die Zentrale genommen wird. Nur welche, wenn es eine gibt für VD, eine für Schaltbefehle und eine um Verkehrsflüsse zu beobachten (zum Beispiel)?
Weiter stellt sich die Frage, auf welchem Port die OnFull-Events gesendet werden sollen. Einzig bei OnNetzAus ist festgelegt (Basis, Kapitel 2.2.1.2), dass der btpplHi-Port verwendet werden soll. Ansonsten sehe ich dazu den Port, auf welchem SetEventDestination aufgerufen wird als Grundlage; als Default btpplLow.

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Do 24 Mai 2012 11:49:29 CEST
Betreff: Liste::SetEventDestination
Die Zentrale ist per Definition Fg0.

Zu den Ports gibt es keine Vorgaben.



52

Name: Christian Jobst (joc@rkag.ch)
Datum: Di 14 Feb 2012 12:06:48 CET
Betreff: Projektspezifische Modifikationen
Guten Tag
In einem Projekt ist die Diskussion entstanden, ob Projektspezifische Modifikationen laut OCIT-O optional oder zur Grundausstattung gehören. Gemäss Funktionsspiegel (OCIT-O_V2.0_Funktionsspiegel_V1.0_A02.pdf) sind Projektspezifische Modifikationen eine so genannte "Projektspezfische Ausstattung".
Ich interpretiere den Funktionsspiegel also so, dass Proj.Mod. zum Funktionsumfang gehören (also nicht eine optionale Ausstattung ist, die explizit gefordert werden muss) - eine OCIT-Zentrale also die Proj.Mod. unterstüzten muss -, jedoch im Projekt die Bedeutung, Verwendung, etc. von Proj.Mod. zu definieren ist.
Ist das korrekt?
Vielen Dank im Voraus für Ihre Bemühungen!


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Projektspez. Modifikationen
Projektspez. Modifikationen müssen projektabhängig vereinbart werden. Das Problem dabei sind ja nicht Modifikationen, sondern die Anwendungen, die aktiviert / geschaltet werden sollen.



51

Name: Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Mo 12 Dez 2011 12:56:56 CET
Betreff: Gleichartige Uhren in Zentrale und Gerät festlegen.
Hallo,

im OO-Funktionsspiegel steht in Tabelle 65.1 unter dem Punkt "1.3 Systemzeit" der Text " Gleichartige Uhren in Zentrale und Gerät festlegen."

Was ist genau mit "gleichartig" gemeint?

Die Anforderung des Standards ist doch, dass alle via OO kommunizierenden Teilsysteme eine identische Systemzeit verwenden. Dies kann aber durchaus mit verschiedenen "Uhren" (Hardware-Zeitquellen) erreicht werden. Bei einem System mit unterschiedlichen Profilen wird ja i.d.R. für die via Profil angeschlossen Lstg frei gelassen, ob DCF oder GPS verwendet wird (was ja wohl auch klappt)und die via Profil 1 oder 3 angebundenen Lstg nutzen den ntp der Zentrale (und DCF oder GPS als lokale Rückfallebene). Die Zentrale wiederum nutzt oft einen vorhandenen Zeitserver...

Danke im Voraus für Ihre Bemühungen!


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Uhren
Formulierung wird entsprechend geändert!



50

Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Mo 05 Dez 2011 17:29:30 CET
Betreff: Liste::Get - FillingDegree
Wie soll der Parameter
OUT.FillingDegree aktueller Füllstand der Liste PROZENT=UBYTE
bei Liste::Get genau ausgefüllt werden?

Ist dieser Wert nur sinnvoll in Bezug auf eine Liste, welche ein OnFull-Event versendet? Man also ablesen kann, mit wie viel Prozent die Liste bereits gefüllt ist?
Oder gilt er unabhängig davon, was bedeutet, dass eine resetbare Liste bei 0 beginnt und bis in die Gegend von 100 hochzählt?


Filling Degree
Falls noch kein SetEvent oder GetSFSinceWithEvent aufgerufen wurde, wird der Füllstand (ab Position dann Näherung an 100) geliefert.

Nach SetEvent oder GetSFSinceWithEvent wird der Füllstand ebenfalls ab Position gesetzt und nähert sich dann 100 (bis zum nächsten SetEvent oder oder GetSFSinceWithEvent


49

Andreas Grob (andreas.grob@bergauer.ch)
Datum: Mo 05 Dez 2011 13:37:45 CET
Betreff: EvListe::OnInvalidate
Die Parameter 3 und 4 von EvListe::OnInvalidate sind wie folgt beschrieben:

IN.Neu.ZNR Gerätenummer, des Gerätes welches das neue Event beantragt hat
IN.Neu.FNR

Doch wie kommt man zu dieser Information? Im btppl-Header wird nur die Ziel ZNR/FNR übertragen. Von der Quelle bekommt man zwar die IP-Adresse, doch ein Lookup darauf geht nicht, da sie nicht unbedingt in der ocit_route Datei steht.


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Do 08 Dez 2011 14:49:57 CET
Betreff: EvListe::OnInvalidate
Die Dokumentation zu EvListe::OnInvalidate wird wie folgt präzisiert:
" Die Gerätenummer des neuen Eventzieles. Diese kann auch identisch mit
der Gerätenummer des beantragenden Gerätes sein."


Im btppl-Header wird nur die Ziel ZNR/FNR übertragen. Parameter ZNR/FNR ergibt sich aus dem neuen Event-Ziel.

Von der Quelle bekommt man zwar die IP-Adresse, doch ein Lookup darauf geht nicht, da sie nicht unbedingt in der ocit_route Datei steht. Da aber Liste::SetEventDestination nur von autorisierten Geräten ausgelöst werden kann, muss es dazu zwingend einen RemoteDevice-Eintrag (ocit_route1) geben.


48

Name: Kröcker (kroecker@qsg-verkehrstechnik.de)
Datum: Di 22 Nov 2011 10:00:47 CET
Betreff: putResult in putResponse
ich muss in einem Projekt eine Schnittstelle nach OCIT_C implementieren.
Da benutze ich drei Schema-Dateien: global.xsd, protokoll.xsd und parking.xsd.
Das funktioniert so weit, aber im Respond wird immer ein zusätzlicher Rahmen "putResult" generiert.
Das mach den Respond nicht OCIT_C-konform.
Kann jemand mir ein Tipp geben wie das zu vermeiden wäre?

Hier ist ein Beispiel:

%3Csoap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"%3E
%3Csoap:Body%3E
%3CputResponse xmlns="http://odg_und_partner/OCIT_C"%3E
%3CputResult xsi:type="putResponseType"%3E
%3ClastStart%3E2011-11-22T09:42:58.796875+01:00%3C/lastStart%3E
%3CerrorCode%3E0%3C/errorCode%3E
%3CerrorText%3ENur ein Test.%3C/errorText%3E
%3CbadList%3E
%3C/badList%3E
%3C/putResult%3E
%3C/putResponse%3E
%3C/soap:Body%3E
%3C/soap:Envelope%3E


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Mo 19 Dez 2011 15:01:03 CET
Betreff: putResult in putResponse
In unseren Biliotheken werden die Zwischenelemente nicht erzeugt.

Wir verwenden Axis 1.4. (Axis 1) Die Klassen werden während des Builds als Ant Target generiert:

%3C!--a classpath to include the axis task JAR and all the dependent libraries --%3E %3Cpath id="axis.classpath"%3E
%3Cfileset dir="${ITS_EXTERN1}/xml-axis/lib"%3E
%3Cinclude name="**/*.jar"/%3E
%3C/fileset%3E
%3C/path%3E

%3C!-- =================================================================== --%3E
%3C!-- generates the sources out of the wsdl and schema --%3E
%3C!-- =================================================================== --%3E %3Ctarget name="xsd2java" depends="init"%3E
%3Ctaskdef resource="axis-tasks.properties" classpathref="axis.classpath"/%3E
%3Caxis-wsdl2java output="${src.dir}" debug="false" wrapArrays="true" verbose="true" all="true"
helpergen="true" deployscope="Application" serverside="true" skeletondeploy="false"
implementationClassName="odg.external.soap.OCIT_CSOAPBindingSkeleton"
url="${project.dir}/wsd/OCIT_Cimpl.wsdl" timeout="300000"%3E
%3C/axis-wsdl2java%3E
%3C/target%3E

Die in diesem Target verwendeten Variablen ITS_EXTERN1, src.dir und project.dir verweisen auf unsere Buildumgebung und sind entsprechend der Zielumgebung anzupassen. Näheres siehe http://axis.apache.org/axis/java/ant/ant.html



47

Name: Daniel Stalder (std@bergauer.ch)
Datum: Mo 14 Nov 2011 09:36:22 CET
Betreff: Sprachversionen der Speziifikationsdokumente
Sind die Spezifikationsdokumente (-%3E OCIT-O_Lstg_V2.0_A03.pdf) auch auf Englisch verfügbar, resp. ist es vorgesehen diese zu übersetzen?

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Mehrsprachige Spezifikationsdokumente?
Die ODG ist der Meinung, dass eine Übersetzung der Spezifikation alleine nur wenig Nutzen bringt, da auch die gesamte XML und Objektdefinition in Deutsch abgefasst ist. Die deutsch- englischen Obbjektnamen können nicht geändert werden.



46

Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Di 08 Nov 2011 11:15:54 CET
Betreff: SupplyTransaction::Get
Guten Tag

Der OUT-Parameter "Blocks" der Methode SupplyTransaction::Get ist wie folgt beschrieben in:
- xml/html-Doku: Array von Blockarten von Versorgungsdaten. Alle Objekte der entsprechenden Blöcke werden neu versorgt.
- pdf-Doku: Ein Array mit allen zu versorgenden Blocks.

Leider verstehe ich beides nicht. Für was wird dieser Parameter benötigt? Was soll er aussagen? Ist er zu verschiedenen Zeitpunkten (auch während eines Versorgungsvorganges) unterschiedlich abgefüllt?


Freundlich Grüsse
Andreas Grob


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Mo 14 Nov 2011 14:11:32 CET
Betreff: SupplyTransaction::Get
Der Parameter Blocks, der bei Get zurückgegeben wird, ist derselbe wie derjenige, der mit InitSupplyTransaction gesetzt wird. Werden die Doku besser formulieren.



45

Name: Dieter Isler (dieter.isler@bergauer.ch)
Datum: Mi 26 Okt 2011 09:29:47 CEST
Betreff: vorgesehene Auftraege fuer Liste 3 (Service)
Hallo

In OCIT-O_Lstg_V2.0_A03.pdf, Seiten 157/158 steht unter anderem, dass die Archive 0 bis 4 persistent (Listenstruktur und Daten) sind und die festdefinierten Archive 0 bis 4 und 31 bis 36 (siehe Pkt 3.5.6.3) vorzugsweise und ausschliesslich die dafuer vorgesehenen Auftraege enthalten soll. Das Archiv 3 ist ja das Archiv fuer den Service-Zugang. In der ganzen PDF- Sammlung fand ich keinen weiteren Hinweis dazu.

Besten Dank im Voraus fuer Ihre geschaetzte Antwort.

Freundlich gruesst

Dieter Isler

vorgesehene Auftraege fuer Liste 3 (Service)
Im Dokument „OCIT-O_V2.0_Funktionsspiegel" findet sich in Kapitel 5.2 Schnittstellenfunktionen, Punkt 4.4.5, folgende Präzisierung:
„Archiv Service-Systemzugang (Listennummer 3): Archiv im Steuergerät für Aufträge die der zentrale Systemzugang verwaltet. Ausstattung, Archivgröße und Aufträge werden durch den Gerätelieferanten festgelegt.“


Dieter Isler (dieter.isler@bergauer.ch)
Datum: Di 27 Sep 2011 15:28:09 CEST
Betreff: SF von Auftrag R09
In der Doku (OCIT-O_Lstg_V2.0_A02.pdf, Seite 124/166) steht, dass für jedes relevante R09-Telegramm abgespeichert wird. Der R09-Auftrag generiert immer Frames des Typs MWAuftragFrame09.
Wie ist das nun, wenn mehr als ein R09-Telegramm empfangen wird?
Wird dann für jedes Telegramm ein SF vom beschriebenen Typ erstellt, oder wird vorgegangen wie wenn in einem anderen Auftragstyp mehr als ein Auftragselement angeheftet ist (wie ein SF der alle AE vom Auftrag enthält)?
Im Moment sieht's bei mir so aus:

 

44

Name: Dieter Isler (dieter.isler@bergauer.ch)
Datum: Di 27 Sep 2011 15:28:09 CEST
Betreff: SF von Auftrag R09
In der Doku (OCIT-O_Lstg_V2.0_A02.pdf, Seite 124/166) steht, dass für jedes relevante R09-Telegramm abgespeichert wird. Der R09-Auftrag generiert immer Frames des Typs MWAuftragFrame09.
Wie ist das nun, wenn mehr als ein R09-Telegramm empfangen wird?
Wird dann für jedes Telegramm ein SF vom beschriebenen Typ erstellt, oder wird vorgegangen wie wenn in einem anderen Auftragstyp mehr als ein Auftragselement angeheftet ist (wie ein SF der alle AE vom Auftrag enthält)?
Im Moment sieht's bei mir so aus:

21.09.2011 11:18:30.282 ip=10.1.3.163 port=3294 T %3C lfdnr=27
hdrlen=16 flags=20 job=0xab8e 0 type=0:400 method=102 znr=20 fnr=22
Correspondig Request=26
Liste
0: ListenNr.ListenNr 33 OEPNV
Respond Methode GetSFSince
0: ret.RetCodeListe 1002 SF_NOFOLLOW
1: AbZeit.ZEITSTEMPEL_UTC 0x4e79abce 21.09.2011 11:18:06
2: AbPosNr.ARCHIVPOSNR 0x1ed
3: BisZeit.ZEITSTEMPEL_UTC 0x4e79abe4 21.09.2011 11:18:28
4: BisPosNr.ARCHIVPOSNR 0x2b1
5: Listenversion.LISTENVERSION 2
6: SekundenFrames.Anzahl_2 6
7: SekundenFrames[0].zeit.ZEITSTEMPEL_UTC 0x4e79abd4 21.09.2011 11:18:12
8: SekundenFrames[0].Auftragsframes.Anzahl 2
9: SekundenFrames[0].[6] !! skipping 6 Sekundenframe = 184 bytes !!
4e 79 ab d4 02 01 00 15 09 0b 0b 12 0a 00 00 33 20 00 00 00
00 00 00 00 00 00 00 01 00 15 09 0b 0b 12 0d 00 // hier ist ein zweiter SF...
00 33 20 00 00 00 00 00 00 00 00 00 00
4e 79 ab d9 01 01 00 15 09 0b 0b 12 11 00 00 33 20 00 00 00
00 00 00 00 00 00 00
4e 79 ab dc 01 01 00 15 09 0b 0b 12 14 00 00 33 20 00 00 00
00 00 00 00 00 00 00
4e 79 ab de 01 01 00 15 09 0b 0b 12 17 00 00 33 20 00 00 00
00 00 00 00 00 00 00
4e 79 ab e1 01 01 00 15 09 0b 0b 12 1a 00 00 33 20 00 00 00
00 00 00 00 00 00 00
4e 79 ab e4 01 01 00 15 09 0b 0b 12 1d 00 00 33 20 00 00 00
00 00 00 00 00 00 00

Besten Dank für Ihre geschätzte Antwort.

Mit freundlichen Grüssen

Dieter Isler

ODG (odg@ocit.org)
Datum: Do 06 Okt 2011 14:04:33 CEST
Betreff: SF von Auftrag R09
Der MWAuftragR09 erzeugt für jedes relevante R09-Telegramm einen entsprechenden Auftragsframe. Dies können durchaus mehrere pro Sekunde sein, d.h. der Sekundenframe kann mehrere MWAuftragFrameR09 beinhalten.Der gezeigte Trace scheint korrekt zu sein - nur ist das, was mit "SF" bezeichnet wird, kein Sekunden- sondern der MWAuftragFrameR09.

43


Name: David Thompson (th@vrag.ch)
Datum: Mo 29 Aug 2011 11:07:58 CEST
Betreff: Fehlende Stdmethoden Get
In OCIT-O_Lstg_V2.0_A03.xml die Standard Modifikation Objekte haben keine Einträge %3CSTDMETHOD%3EGet%3C/STDMETHOD%3E:
- 1:231 IVAEinAus
- 1:239 IVAIndividualverkehrEinAus
- 1:233 IOepnvEinAus

Ist das ein Fehler? Normalerweise sind StdMethoden nicht vererbt. Hier wäre es von 1:207 IModEinAus was schon ein Get Method definiert.
Sonst kann ich diese Zustände nur mittels IstVektor sehen, stimmt das?

Es ist auch ähnlich mit die Befehle:
- 1:230 ZVAEinAus
- 1:238 ZVAIndiviualverkehrEinAus
- 1:232 ZOenpvEinAus

Method 16 (Schalte) existiert aber keine 0 (Get). Ist das korrekt?

Danke

Antworten auf diesen Eintrag |

ODG (odg@ocit.org)
Datum: Fr 21 Okt 2011 09:33:08 CEST
Betreff: Fehlende Stdmethoden Get

Die ODG Technik hat am 22. Workshop (Oktober 2011) folgendes festgelegt: Standardmethoden werden nicht vererbt. In die XML der Ausgabe 04 werden die fehlenden Standardmethoden eingefügt.

42


Name: Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Fr 17 Jun 2011 10:48:08 CEST
Betreff: „Zählweise“ des Umlaufzählers TX
Gem. OCIT-Oustations-Lstg ist

TX = (RRS + SignalzeitenVersatz) % TU

d.h. TX nimmt Werte TX=0..TU-1 ein.

In unseren Projekten mussten wir nun leider feststellen, dass es zwischen den Realisierungen der einzelnen OCIT-Oustations-Lizenznehmer einen Unterschied von einer Sekunde beim TX gibt! :-) Konkret halten sich die einen an die obige Rechenregel, d.h. dass der Zustandswechsel von TX=TU-1 nach TX=0 zu Anfang der Sekunde gemäß obiger Rechenregel erfolgt (z.B. bei TU=60 Sekunden ist TX=0 zu Anfang jeder vollen Minute, Sekunde 0). Die andere Lösung nutzt (vermutlich aus historischen Gründen) Werte für TX‘=1..TU und versetzt, um Kompatibilität zu OCIT-Oustations zu erreichen, den per OCIT-Oustations übertragenen TX um +1 Sekunde (z.B. bei TU=60 Sekunden ist TX=0 zu Anfang jeder vollen Minute plus 1 (!!!), also zu Sekunde 1).

Problem hierbei ist, dass die Umlaufzähler TX mehrerer LSA bei einem herstellergemischten System mit den beschriebenen unterschiedlichen Realisierungen in Folge auch tatsächlich um eine Sekunde versetzt sind mit allen hinlänglich bekannten verkehrlichen und systemtechnischen Folgen.

Meine Fragen dazu:

1. Welche der beschriebenen Realisierungen ist/sind Standard-konform?

2. Sollten beide Realisierungen Standard-konform sein: welche Empfehlungen gibt die ODG den Anwendern, um die daraus entstehenden praktischen Probleme zu umgehen?

Wie immer, vielen Dank im Voraus für Ihre Bemühungen.

Mit freundlichen Grüßen
Uwe Jakobi


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Fr 21 Okt 2011 09:40:29 CEST
Betreff: Zählweise des Umlaufzählers
Zu 1): Standardisiert ist das Verhalten auf der Schnittstelle. OCIT-O macht keine Aussage zur Vi-sualisierung! Standardkonform sind Schaltzeitpunkte 0 bis TU-1, Referenzzeit zeigt ebenfalls von 0 bis TU-1. Beispiel: Bei einem 60 Sekunden Umlauf muss das TX=0 auf den Beginn der vollen Minute liegen. Zu 2): Visualisierungen können aus historischen Gründen auch einen Wertebereich von 1 bis TU anzeigen.

 


41


Name: Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Mi 15 Jun 2011 11:40:28 CEST
Betreff: Veränderung des Objekt IstVektor aufgrund von Zentralen Schaltwünschen
Hallo,

ich melde mich wieder einmal ausgelöst durch Beobachtungen bei OO-Schnittstellentests bei einem Kunden... ;-)

Mir ist bei der Beobachtung der Meldungen in den Zentralen schon öfters aufgefallen, dass einige Lstg ungewöhnlich viele Meldungen BzIstVektor erzeugen, obwohl sich keine Schaltparameter geändert haben.

Die Analyse hat ergeben, dass diese Lstg unmittelbar nach Empfang eines Zentralen Schaltwunsches einen ersten BzIstVektor erzeugen (i.d.R. in der gleichen oder eine Sekunde später), weil das Lstg geänderte Parameter „VorgangsNr“ des Zentralen Schaltwunsches unmittelbar übernimmt und dies dann als geänderter IstVektor interpretiert wird.

Ist dieses Verhalten Standard-konform?

Ich bin bisher davon ausgegangen, dass nur ZUSTANDSÄNDERUNGEN zur Erzeugung von Meldungen/Auftragsframes führen. Aus meiner Sicht ist eine SYSJOBID keine Zustandsdate, sondern sie ist ein Hilfsobjekt, das die Verbindung zum Verursacher der Zustandsänderung herstellen soll. Der Zeitpunkt der Übernahme der Änderung einer (oder mehrerer) SYSJOBID ohne Änderung der zugehörigen Schaltparameter im Lstg ist zum einen herstellerabhängig realisiert, zum anderen bringt die Erzeugung einer solchen Meldung für die Zentrale keinen nutzbaren Informationsgewinn, sondern ist redundant.

Sollte das Ergebnis ein Standard-konformes Verhalten sein, bitte ich im Nennung der dies begründenden Textpassagen in den OO-Dokumenten.

Vielen Dank im Voraus für Ihre Bemühungen!

Mit freundlichen Grüßen
Uwe Jakobi


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Fr 21 Okt 2011 09:26:20 CEST
Betreff: Veränderung des Objekt IstVektor aufgrund von Zentralen Schaltwünschen
In OCIT-O Lstg Kap. 3.5.6 steht:... Bei jedem Betriebszustandswechsel werden die Betriebszustände erfasst. Dieser Text wird in Ausgabe 4 geändert auf: ...„... Jede Änderung des IstVektors generiert einen Eintrag des IstVektors in der Betriebszustandsliste.“



40


Name: Dirk THIBAU (dthibau@mbhg.irisnet.be)
Datum: Mi 27 Apr 2011 13:41:32 CEST
Betreff: OCIT-O Profil 1 over IP
Is it possible to implement profil 1 over Ethernet by using a com-port redirection and terminal servers approach over an Ethernet network instead of using dedicated point-to-point connections with modems?

Best regards,

Dirk THIBAU
Mobiel Brussel


ODG (odg@ocit.org)
Datum: Mi 27 Apr 2011 15:52:49 CEST
Betreff: OCIT-O Profil 1 over IP
Assumed routing:

Central unit (PPP + ser. pseudo interface) - %3E IP net - %3E "Device Server" (outputs serially) - %3E V.34-Modem - %3E Profile 1 interface (cu 2 wire long-distance line) - %3E V.34-Modem - %3E Profile 1 equipment. Problem could be a strange timing of the signal flow (because of the IP net). Profile 1 makes no defaults for this.

39


Name: Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Mi 16 Mär 2011 10:10:48 CET
Betreff: Unterstützung von gerouteten Netzen durch OCIT-Outstations
Wir sind von Kunden angesprochen worden, dass Vertreter eines ODG-Mitglieds aktuell viele Kunden durch die Aussage verunsichern würde, OCIT-Outstations würde KEINE gerouteten Verbindungen unterstützen. Wir sind diesbezüglich um eine Stellungnahme gebeten worden und geben hiermit diese Frage zur Sicherheit an die ODG weiter mit der Bitte, hierzu ein klares Statement abzugeben.

Das Dokument OCIT-O-Profil_3_V1.0_A01.pdf beschreibt in Kapitel 4.4 "Gerouteter Betrieb" explizit die Anforderungen an einen solchen Betrieb von OCIT-Outstations und empfiehlt diesen sogar bei bestimmten Rahmenbedingungen. Dies impliziert aus unserer Sicht eindeutig, dass OCIT-Outstations sehr wohl einen gerouteter Betrieb unterstützt und somit die Aussage des ODG-Mitglieds falsch ist.

Auch haben unsere Nachfragen bei 2 OCIT-Outstations Lizenznehmern ergeben, dass OCIT-Outstations einen gerouteten Betrieb unterstützen würde.


Sollten die in OCIT-O-Profil_3_V1.0_A01.pdf beschriebenen Rahmenbedingungen einen realen gerouteten Betrieb, z.B. über ein öffentliches Netz, nicht ermöglichen oder extrem einschränken, bitten wir hier um Klarstellung.

Vielen Dank im Voraus für Ihre Bemühungen!


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Fr 21 Okt 2011 09:57:40 CEST
Betreff: Unterstützung von gerouteten Netzen durch OCIT-Outstations
OCIT-O Profil 3 unterstützt geroutete Verbindungen unter den in der Dokumentation OCIT-O-Profil_3_V1.0_A01.doc, Kapitel 4 genannten Bedingungen.



38


Name: Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Di 22 Feb 2011 17:07:23 CET
Betreff: Inhalt der Reference auf einen leeren APWert
Thema: Inhalt der Reference auf einen leeren APWert

Kommentar: Hallo,

ein in einem Projekt angefertigter BTPPL-Trace zeigt bei einem Methodenaufruf SystemobjektFeldgeraet.GetListConfig f?r einen Auftrag folgende Daten

38: listObjects[0].AInfo[4].Auftrag.RefLen 5
39: listObjects[0].AInfo[4].Auftrag.MOtype 1:407 MWAuftragAbtastAenderung
40: listObjects[0].AInfo[4].Auftrag.Auftragsnummer.AuftragsNr 4
41: listObjects[0].AInfo[4].Auftrag.DataLen 11
42: listObjects[0].AInfo[4].Auftrag.running.BOOL 1 true
43: listObjects[0].AInfo[4].Auftrag.ActivateEventOnInsert.BOOL 0 false
44: listObjects[0].AInfo[4].Auftrag.Abtastintervall.ZEITDAUER_10MSUL 0x64
45: listObjects[0].AInfo[4].Auftrag.Versatz.ZEITDAUER_10MSUL 0x64
46: listObjects[0].AInfo[4].Auftrag.AbtastAENr.AuftragsElement.AuftragsElementNr 0
47: listObjects[0].AInfo[4].AE.Anzahl 1
48: listObjects[0].AInfo[4].AE[0].RefLen 5
49: listObjects[0].AInfo[4].AE[0].MOtype 1:434 AEAPWert
50: listObjects[0].AInfo[4].AE[0].AuftragsElement.AuftragsElementNr 0
51: listObjects[0].AInfo[4].AE[0].DataLen 7
52: listObjects[0].AInfo[4].AE[0].Nr.AuftragsElementNr 0
53: listObjects[0].AInfo[4].AE[0].APWert.RefLen 5
54: listObjects[0].AInfo[4].AE[0].APWert.MOtype 1:511 APWertRkUshort
56: listObjects[0].AInfo[4].AE[0].APWert.RK.RelKnotenNr.OBJECT_ID_UBYTE 0

Wie man sieht, fehlt bei derReference auf AE[0].APWert der Parameter APWert.ApWertName.ANYPATH. Ist es formal richtig, dass dann dieser Parameter ganz weggelassen wird (wie in dem obigen Beispiel), oder muss nicht zumindest die L?ngenangabe (USHORT) des leeren Strings, also "0x0000" vorhanden sein? Aus den Unterlagen kann ich leider nicht erkennen, ob der String bei ANYPATH auch als NULL/NOTHING vorkommen darf.

Wie es dazu gekommen ist, dass ein Auftrag nebst AEAPWert mit leerem ApWertName in der Liste angelegt werden konnte, habe ich leider nicht in dem BTPPL-Trace finden k?nnen... :-(


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Di 22 Feb 2011 17:10:45 CET
Betreff: Inhalt der Reference auf einen leeren APWert
Bei dem Trace fehlen die Rohdaten und auch die Zeile 55. Falls das Längenbyte "0x0000" nicht in den Rohdaten vorhanden sein sollte, wäre dies eine Protokollverletzung.




37


Name: Uwe Jakobi (Neu Einsortiert durch ODG) (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Fr 18 Feb 2011 10:14:05 CET
Betreff: Voedefinierte Aufträge
Sie k?nnen sich den Eintrag anschauen, indem Sie folgende URL in Ihrem Browser ?ffnen: http://www.ocit.org/tinc?key=mYkrZizb%26start=85.1

Folgende Daten wurden ?bermittelt:

Thema: Vordefinierte Auftr?ge

Kommentar: In mehreren von uns analysiertem BTPPL-Traces haben wir festgestellt, dass einige Lstg in den Listen 32-35 mehr Aufträge vordefiniert haben, als in der Tabelle OCIT-O_Lstg_V2.0_A03 auf Seite 164 vorgegeben. Ist dies standardkonform?

Ferner gibt es Fälle, bei denen z.B. für Liste Nr 32 4 Aufträge mit den Auftrags-Nummern 0..3 vordefiniert sind, die jedoch alle als Degree 0 enthalten. Ist dies standardkonform? Bisher bin ich davon ausgegangen, dass bei Meldungsaufträgen die Auftragsnummer gleich dem Degree ist/sein muss? Ist diese Annahme falsch?


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Fr 18 Feb 2011 10:15:59 CET
Betreff: Vordefinierte Aufträge
Kommentar: In mehreren von uns analysiertem BTPPL-Traces haben wir festgestellt, dass einige Lstg in den Listen 32-35 mehr Aufträge vordefiniert haben, als in der Tabelle OCIT-O_Lstg_V2.0_A03 auf Seite 164 vorgegeben. Ist dies standardkonform?

A ODG: Nein.

Ferner gibt es Fälle, bei denen z.B. für Liste Nr 32 4 Aufträge mit den Auftrags-Nummern 0..3 vordefiniert sind, die jedoch alle als Degree 0 enthalten. Ist dies standardkonform?

A ODG: Nein, siehe oben.

Standardkonform ist ein vordefinierter Meldungsauftrag. Bisher bin ich davon ausgegangen, dass bei Meldungsaufträgen die Auftragsnummer gleich dem Degree ist/sein muss? Ist diese Annahme falsch?

A ODG: Ja. Auftragsnummer darf ungleich Degree sein.



36


Name: Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Mi 09 Feb 2011 18:52:53 CET
Betreff: Längenangabe bei STRINGDOMAIN
STRINGDOMAIN hat gem. DTD einen optionalen Parameter MAXLEN?, der gem. Kapitel 5.5 Codierung der Daten, Seite 26 von OCIT-O_Protokoll_V2.0_A03 folgender Anforderung genügen muss: "Strings werden immer mit einem 16-Bit (USHORT) Längenwort dargestellt, welches die Anzahl der BYTES(!) im String angibt."

Nun ist mir aufgefallen, dass einige STRINGDOMAIN eine MAXLEN %3C 256 haben und diese anscheinend von einigen Systemen in diesem Fall nicht ein Längenwort (USHORT) senden, sondern ein Langenbyte (UBYTE).

Ist das korrekt? Wenn ja, sollte der obige Text in OCIT-O_Protokoll_V2.0_A03 geändert werden... ;-)

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Fr 11 Feb 2011 11:03:35 CET
Betreff: Längenangabe bei STRINGDOMAIN
Entsprechend OCIT-O_Protokoll_V2.0_A03 ist bei STRINGDOMAIN immer ein Längenwort (USHORT) voranzustellen. Das ist unabhängig von der MAXLEN Angabe in der Type-Datei. Wenn anstelle des Längenworts nur ein Längenbyte gesendet wird, ist das ein Fehler in der Implementierung.



35


Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Mo 24 Jan 2011 14:34:10 CET
Betreff: LsaVersion::Checksum berechnen
Guten Tag

Wir diskutieren zur Zeit, wie die LsaVersion::Checksum berechnet werden muss. Das Verfahren ist dabei klar, aber unklar ist über welche Objekte dieses Verfahren angewandt werden muss.
Konkret steht nichts in der Dokumentation, ob das Objekt VDVersion dafür ausgeklammert werden muss. Es wird jedoch darauf hingewiesen, dass "Anzahl folgender VersorgbaresObjekt Elemente" nicht zu berücksichtigen ist.

ODG (odg@online.de)
Datum: Di 25 Jan 2011 11:58:17 CET
Betreff: LsaVersion::Checksum berechnen
Bei der Checksummenberechung werden alle versorgbaren Objekt (also auch die VDVersion) mit einbezogen. Der Hinweis mit "Anzahl folgender VersorgbaresObjekt Elemente" bezieht sich auf die im Antworttelegramm der Methode ReadVD mit übertragene Länge des "VersorgbaresObjekt"-Arrays.


34


Name: Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Di 14 Dez 2010 16:35:54 CET
Betreff: Verhalten von Lstg und Zentrale bei negativen Zeitsprüngen
Hallo,

wir haben festgestellt, dass es Probleme gibt, wenn ein Lstg negative Zeitsprünge durchführt (Zeitsprung in die Vergangenheit). Neue Sekundenframes ab dem Zeitsprung werden nicht mehr ausgelesen, wenn die Zentrale schon an dieser Zeit "vorbei" war...

Wir haben im Standard lange gesucht und auch mit verschiedenen Personen diskutiert, ob und wenn ja, wo der Standard OO das Verhalten von Lstg und/oder Zentrale in diesem Fall festlegt, aber leider keine konkreten Angaben gefunden.

Wenn ich den Standard richtig verstanden habe, soll die Zentralen immer (!) die vom Lstg im Res-Telegramm angegebene Positionsnummer und Zeitstempel des letzten Sekundenframes als Parameter für AbPosNr und AbZeit des nächsten GetSFxxx nehmen.

Gibt es nun im Lstg einen Zeitsprung in die Vergangenheit, muss das Lstg neue Sekundenframes in die vorhandenen einsortieren (mindestens den für die Meldung "Zeitsprung"). Diese haben nun aber einen Zeitstempel in der Vergangenheit und es kann wei schon gesgat passieren, dass die Zentrale schon zeitlich daran "vorbei" ist mit dem Ergebnis, so es dazu tatsächlich keine Festlegungen gibt, dass diese Sekundenframes nicht mehr von der Zentrale ausgelesen werden und wir damit einen Datenverlust in der Zentrale haben würden (obwohl die Sekundenframes im Lstg vorhanden sind)...

Eine vergleichbare Fragestellung ergibt sich, wenn das Lstg einen Reset/Kaltstart durchführt und die Zentrale weiter mit GetSFxx fortfährt, weil sie diesen Vorgang im lstg nicht "mitbekommen" hat. Auch hier hätte die Zentrale nur die Chance wieder mit dem Lstg "synchron" bez. AbPosNr dun AbZeit zu kommen, wenn das Lstg die Zentrale dazu "zwingt" indem das Lstg die aktuellen Werte setzt. Da einige Lstg bei No_SF die folgenden Parameter nicht mehr senden oder diese mit irgendwelchen Inhalten setzen, sollten der Standard m.E: nach fordern, dass das Lstg diese Parameter "richtig" setzt, spätestens beim ersten vorliegenden Sekundenframe.

Wer muss sich Standardkonform nun wie verhalten, damit die geschilderten Probleme bei Zeitsprüngen in die Vergangenheit nicht auftreten?

Ich sehe nur zwei prinzipielle Möglichkeiten:

1. Die Zentrale liest aufgrund der Meldung "Zeitsprung" ab dem Zeitstempel dieser Meldung (oder besser ab einer Sekunde davor?) die Listen aus und filtert die schon einmal empfangenen Sekundenframes. Diese Variante wäre noch am ehesten die, die ich persönlich in den Standard reininterpretieren würde... ;-)

2. Das Lstg hält sich ab der Meldung "Zeitsprung" (die ja in jede Liste eingetragen werden sollte :-) was aber nicht alle Firmen tun ...) nicht an die von der Zentrale erhaltenen AbZeit und AbPosNr, sondern übergibt die Sekundenframes ab dem Zeitstempel der Meldung "Zeitsprung"...

Bei Reset/Kaltstart des Lstg gilt dies prinzipiell genau so.


Bei dieen Überlegungen ist dann letzlich bei mir die Frage aufgetaucht, was passieren kann, wenn es einen extremen Zeitsprung in die Zukundt gibt und in den Listen bereits sehr viele Sekundenframes vorliegt. Dann gehen zwar keine Daten verloren, aber die Zentrale erhält u.U. erst zu einem späteren Zeitpunkt Kenntnis über den Zeitsprung. Können hieraus Konsequenzen in der Zentrale entstehen, die genauerer Festlegungen im Standard oder im Projekt bedürfen.

Darf ich hierzu um eine Stellungnahme bitten? Sollte der Standard eindeutige Festlegungen hierzu enthalten, bitte ich um Angabe, wo das nachzulesen ist. Danke!

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (ODG@ocit.org)
Datum: Do 17 Feb 2011 17:06:50 CET
Betreff: Zeitsprünge
Die Frames werden mittels der Positionsnummer fortlaufend gekennzeichnet. Es gehen auch bei Zeitsprüngen keine Frames verloren, da sie nicht einsortiert werden.

Kaltstart ist eine firmenspezifische Maßnahme, bei der u. U. alle Archive gelöscht werden. Bei Reset bleiben in Geräten mit OCIT-O die persistenten Archive erhalten. Bei Zeitsprüngen kann man daher auf alle Frames zugreifen.Es bleibt die grundsätzliche Schwierigkeit der Darstellung in der Zentrale, da die Daten bei Zeitsprüngen nicht ohne weiteres eingeordnet werden können.



33


Name: Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Fr 26 Nov 2010 19:01:26 CET
Betreff: Kombinationen von Aufträgen und Auftragselementen
Hallo,

in OCIT-O_Lstg_V2.0_A03.pdf ist in Kapitel "3.5.3.10 Kombinationen von Aufträgen und Auftragselementen" angegeben, dass die Kombination von AuftragZykl 1:403 und AEBinaer 1:431 möglich ist. Nun ist der durch AEBinaer 1:431 erzeugte AEBinaerFrame 1:295 aber leider leer (weil der Zustand von Channel in Bit 2^7 von Subsekunde bei MWAuftragAbtastAB 1:406 kodiert wird...)

Kodiert man den Zustand des Channel in einem Byte, so interpretiert das typetool dies nicht und kommt damit mit der Interpreation des Bytestreams ab dann durcheinander... vermutlich, weil halt AEBinaerFrame 1:295 erwartet wird, das ja leer sein muss...

Ich folgere daraus, dass AEBinaer 1:431 nur mit MWAuftragAbtastAB 1:406 möglich ist. Ist das richtig?

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Mi 08 Dez 2010 14:23:23 CET
Betreff: Kombinationen von Aufträgen und Auftragselementen
Ihre Folgerung ist richtig. Die Kombination von AuftragZykl 1:403 und AEBinaer 1:431 ist zwar möglich, aber sinnlos! Eine entsprechende Bemerkung wird ind Dokument eingefügt.

 



32


Name: Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Mo 08 Nov 2010 15:14:34 CET
Betreff: Befehle der Schaltuhr
In OO-Lstg steht in Kapitel 3.3.3.2.1 Objekt Tagesplan:

Hinweis: Jeder Tagesplan muss mindestens einen Eintrag haben. Der Schaltwunsch muss vollständig sein, NULLVALUES und Zustand „keiner“ sind generell nicht erlaubt!

Welche Werte sollen die Parameter Programmwunsch, ModVA, ModOepnv und ModVAIndividualverkehrEinAus enthalten bei

- KnotenEinAus = Ausxx
- wenn das Lstg einzelne dieser Parameter nicht nutzt / unterstützt?
Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Di 09 Nov 2010 09:52:25 CET
Betreff: Befehle der Schaltuhr
Der OCIT-Standard schreibt nur vor welche Werte NICHT verwendet werden dürfen (NULLVALUE und der Zustand „keiner“). Der Benutzer kann unter den übrigen zur Verfügung stehenden Werten (Zustände „Ein“ und „Aus“ für Modifikationen bzw. ein vorhandenes Signalprogramm für den Programmwunsch) frei auswählen.

 

 


31


Name: Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Do 30 Sep 2010 07:09:07 CEST
Betreff: Ausstattung von Zenzralen und Feldgeräten
Wir haben in unseren Projekten immer wieder das Problem, in den Ausschreibungen die "Ausstattung" der Zentralen und Feldgeräte bezogen auf die Schnittstelle OCIT-Outstations ausreichend genau zu spezifizieren, was im Ergebnis immer wieder zu Problemen bei der Integration von Geräten verschiedener Hersteller führt. Um diese Probleme zukünftig minimieren zu können erscheint es mir erforderlich, die in der Ausschreibung zu spezifizierenden Anforderungen bezogen auf die Schnittstelle OCIT-Outstations genauer zu spezifizieren.

Dazu habe ich zuerst versucht, die Aussagen hierzu in den Dokumenten des Standards zu identifizieren.

In dem Dokument OCIT-O_System_V2.0_A02.pdf, Kapitel 7 - Ausstattung der Feldgeräte gibt es dazu folgende Texte:

1. OCIT-Outstations konforme Geräte müssen nicht alle in den Spezifikationen festgelegten Funktionen unterstützen, sondern nur diejenigen, die für den jeweiligen Zweck und Ausbau notwendig sind.

2. Zentrale Einrichtungen müssen dagegen alle Funktionen unterstützen die im System verlangt werden.

3. Es bleibt daher jedem Hersteller überlassen, welche Grundausstattung und welchen Leistungsumfang er mit den Geräten seines OCIT-Programms anbietet. …

4. Der Hersteller dokumentiert die Ausstattung seiner Gerätetypen in eigenen Datenblättern.

5. Für OCIT-Outstations Lichtsignalsteuergeräte hat sich eine auf der bisherigen Einsatzerfahrung beruhende Grundausstattung von in OCIT-Outstations spezifizierten Funktionen und Komponenten herausgebildet. Diese Grundausstattung und ihre Varianten sind in einem sogenannten „Funktionsspiegel“ beschrieben.

Aus meiner Sicht sind diese Aussagen bezogen auf das beschriebene Problem wenig hilfreich... :-( ... und habe deshalb versucht, diese zu interpretieren mit der Bitte an die ODG, meine Interpretation zu prüfen und zu kommentieren.

a. Ich verstehe den Text2 so, dass zuerst einmal der AG die Aufgabe hat, die zu unterstützenden Funktionen der Zentralen Einrichtungen zu spezifizieren. Hieraus ergibt sich dann irgendwann eine konkrete Realisierung, die durch den Hersteller über von ihm festgelegte OCIT-Outstations Objekten, Methoden, Parameter usw. realisiert werden.
Nach unseren Erfahrungen nutzen die Zentralen Einrichtungen verschiedener Hersteller und Versionen die OCIT-Outstations Objekten und Methoden sehr unterschiedlich und von den in den Dokumenten des Standards definierten lediglich zwischen 20 bis maximal 30%. Dies ist keine negative Bewertung, da diese Zentralen sicher alle die Anforderungen der Kunden realisieren! Die Aussage soll nur dazu dienen, unser Spezifikationsdilemma klar zu machen...

b. Da Zentralen und Feldgeräte ja interoperabel sein sollten ;-) besteht die Anforderung, dass von diesen auch die gleichen OCIT-Outstations Objekte, Methoden, Parameter usw. unterstützt werden müssen. Da bis auf die Events alle OCIT-Outstations Methodenaufrufe von der Zentrale erfolgen, ergeben sich die zur Erreichung der Interoperabilität vom Feldgerät zu unterstützenden Objekte und Methoden primär aus der Realisierung durch die Zentrale.

c. Aufgrund des geringen Prozentsatzes der von den Zentralen genutzten Objekte und Methoden einerseits sowie der obigen Texte 1-3 erscheint es uns sinnvoll, den Ausschreibungen für Feldgeräte einen Funktionsspiegel der zu unterstützenden Objekte und Methoden beizufügen. Dieser ist aber unseren bisherigen Erfahrungen aber nur sehr schwer von den Herstellern zu bekommen, die Art der Dokumentation (siehe Text 4) ist sehr unterschiedlich und nicht immer geeignet, einer Ausschreibung beizufügen. Ferner verweisen die Hersteller, vermutlich zu Recht, darauf, dass sich aufgrund der von den Kunden gewünschten Weiterentwicklung der Produkte Änderungen bei den unterstützenden Objekten und Methoden ergeben können.

Aus diesen Ausführungen wird hoffentlich das Spezifikationsdilemma etwas klarer und ich habe deshalb die Frage an die ODG, ob es zur Beseitigung oder zumindest Minderung Hilfen der ODG gibt oder bei nächsten Versionen angedacht sind? Wir haben z.B. versucht dies u.a. auch durch die Anforderung zu lösen, dass die Hersteller eine Type-Datei liefern müssen, in der nur die unterstützten Objekte und Methoden aufgeführt sind. Damit kommen aber offenkundig nicht alle Hersteller zurecht, aus welchen Gründen auch immer.

Wir meinen, dass die ODG hierzu eine Lösung anbieten sollte, um die in den Projekten aufgrund unzureichender Interoperabilität, entstanden durch mangelnde transparente Abstimmung der Leistungsmerkmale der Schnittstelle OCIT-Outstations, immer wieder auftretenden Probleme zu minimieren.


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (2)



ODG (odg@ocit.org)
Datum: Do 17 Feb 2011 16:51:45 CET
Betreff: Geräteausstattung
ODG (odg@ocit.org)
Datum: Do 17 Feb 2011 16:20:59 CET
Betreff: Geräteausstattung
Der Satz aus dem Dokument System lautet vollständig: „OCIT-Outstations konforme Geräte müssen nicht alle in den Spezifikationen festgelegten Funktionen unterstützen, sondern nur diejenigen, die für den jeweiligen Zweck und Ausbau notwendig sind. So müssen beispielsweise Lichtsignalsteuergeräte die auf Bundesstraßen eingesetzt werden sollen, nicht zwingend die Funktionen enthalten, die für Geräte mit verkehrsabhängiger ÖPNV-Bevorzugung notwendig sind. Zentrale Einrichtungen müssen dagegen alle Funktionen unterstützen die im System verlangt werden.“

Ein standardkonformes Gerät muss jedoch alle Objekte und Methoden unterstützen, die für den anforderungsgemäßen Ausbau und Funktionalität des Gerätes notwendig sind.
Es kann mehrere Wege geben, eine geforderte Funktionalität zu erfüllen. Ein standardkonformes Gerät unterstützt alle Wege, die Zentrale wählt einen davon.

Beispiel: Ist die Aufzeichnung von Detektorwerten gefordert, muss das Gerät alle Varianten, wie spezifiziert unterstützen, hier: MWAuftragAbtastAB und AuftragZykl.


Antworten auf diesen Eintrag

1 Name: ODG (odg@ocit.org)
Datum: Do 07 Okt 2010 17:37:16 CEST
Betreff: Ausstattung von Zentralen und Feldgeräten
Die Ausstattung einer Zentrale wird lt. Ausschreibung festgelegt und ist kein OCIT-O Thema. Die Geräteausstattung legt der Hersteller entsprechend fest. Er muss darauf achten, dass die verlangten Methoden richtig quittiert werden.

Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Fr 24 Dez 2010 12:46:22 CET
Betreff: Geräteausstattung
Ihre Antwort

"Die Ausstattung einer Zentrale wird lt. Ausschreibung festgelegt und ist kein OCIT-O Thema. Die Geräteausstattung legt der Hersteller entsprechend fest."

ist aus meiner Sicht für alle Anwender von OO absolut unbefriedigend!

Da u.a. an Ihrer Aussage "Die Geräteausstattung legt der HERSTTELLER entsprechend fest" bei Ausschreibungen von Lstg immer wieder eine Auseinandersetzung zwischen Ausschreibenden und den Bietern bzw. später dem Hersteller entzündet, bitte ich die ODG um eine klare Aussage, wie genau dieser Satz zu verstehen ist. Soll dies bedeuten, dass der Ausschreibende gem. OO keinen Einfluss mehr auf die Geräteausstattung hat (bezogen auf den Standard OO) und das "zu nehmen" hat, was der Hersteller bietet? Wir wissen alle, dass der Standard OO viele Freiräume lässt, die von den Herstellern auch intensiv genutzt werden. Ergebnis Ihrer Aussage wäre, dass der Ausschreibende keine Anforderungen bezüglich der Ausgestaltung der Freiräume hätte!? Das wäre aber sicher nicht im Interesse der Hersteller wie der Betreiber von Lstg...

Ich meine, dass sich die ODG um eine sachliche Beantwortung meiner Fragen gedrückt hat und bitte darum, dieses Thema an geeigneter Stelle abzustimmen.


Mit freundlichen Grüßen
Uwe Jakobi


ODG (odg@ocit.org)
Datum: Sa 25 Dez 2010 09:27:36 CET
Betreff: Geräteausstattung
Der Satz ist so zu verstehen: "Die Geräteausstattung legt der Hersteller entsprechend DER AUSSCHREIBUNG fest" Das Thema wird auf dem nächsten ODG-Workshop noch einmal behandelt.

 

 

30


Name: Uwe Jakobi (@Uwe.Jakobi@AlbrechtConsult.com)
Datum: Mi 29 Sep 2010 16:23:31 CEST
Betreff: Überwachung der Protokoll-Schichten unterhalb von BTPPL
Beim OCIT-Outstations-Schnittstellentest ist aufgefallen, dass nach einem Verbindunsgaufbau einige Zeit vergeht, bis die BTPPL-Kommunikation ordnungsgemäß arbeitet. Dabei gehen am Anfang offenkundig BTPPL-Telegramme verloren.

In diesem Zusammenhang kam zwischen den Vertretern der beiden Firmen die Diskussion auf, ob die den Lizenznehmern bereitgestellte BTPPL-Library Fehler in den Schichten unterhalb von BTPPL erkennen kann oder nicht. Im Projekt Nürnberg waren die Firmen hier unterschiedlicher Ansicht... :-(

Ich bitte deshalb die ODG um eine Aussage zu diesem Punkt sowie um Angabe, wie konkret die Anforderung des Standards an die Überwachung und Fehlererkennung bezüglich der Schichten unterhalb von BTTPl zu beschreiben sind, damit die Anwender dies zukünftig richtig in die Aussschreibungsunterlagen aufnehmen können. Danke!

ODG (odg@ocit.org)
Datum: Do 07 Okt 2010 17:39:09 CEST
Betreff: Überwachung der Protokoll-Schichten unterhalb von BTPPL
Profil 2 ist nicht für „Dial on Demand“ vorgesehen. Die Einwahlkontrolle ist im Dokument OCIT-O-Profil_2_V1.0_A03.1, Kapitel 3 beschrieben. Die btppl-Lib kann nicht erkennen, ob bei einem Ver-bindungsaufbau Telegramme verloren gehen. Dies ist eine Aufgabe der Anwendung.



29


Name: Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Mi 29 Sep 2010 16:10:25 CEST
Betreff: Funktionsumang des Lstg bei Profil 2
Beim Profil 2-Schnittstellentests in der Stadt Nürnberg tauchte die Frage auf, welche der im Dokument OCIT-O-Profil_2_V1.0_A03.pdf gelisteten Objekte und Methoden von der Zentrale wie vom Lstg bereitzustellen sind, wenn der AG die Realisierung der Kommunikation per Profil 2 fordert. Ferner stellte sich die Frage, welche Meldungen zu Profil 2 das Lstg bereitstellen muss.

Sollte das Ergebnis sein, dass die Festlegung / Abstimmung zu obigen Fragen Aufgabe des AG bei den Ausschreibungen sein: kann die ODG Angaben machen, welche Anforderungen vom Standard genau als Optional oder Projektspezifisch deklariert sind und damit der AG bei Anwendung von Profil 2 festlegen muss?

Abschließen habe ich die Bitte, dieses Thema wenn möglich in einer nächsten Überarbeitung der Dokumente "Profil 2" und "Funktionsspiegel" aufzunehmen. Danke!

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Do 07 Okt 2010 17:40:20 CEST
Betreff: Funktionsumang des Lstg bei Profil 2
Die Zentrale muss nur die für ihre Funktion notwendigen Funktionen unterstützen. Das FG alle. Die Meldungen 60154 und 60155 werden künftig als optional deklariert.



28


Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Di 14 Sep 2010 16:37:56 CEST
Betreff: Offline Archiv 36
Bei Schnittstellentests letzter Woche mit Profil 2, wurden folgende Fragen in den Raum gestellt:
1.) Kann ausschliesslich mit der Liste 36 eine GSM-Verbindungsaufnahme initiiert werden? Hier geht es darum, ob auch andere Listen dies tun können und nicht um das OfflineEvent, welches auch eine Verbindung initiieren kann.
2.) Folgt die SetEvent Methode bei Liste 36 den normalen Spielregeln? Wenn die Liste schon als Trigger verwendet werden soll, ist es irgendwie sinnlos was anders als 0% zu konfigurieren. Soll das LSTG andere Werte zulassen oder grundsätzlich immer 0% aufweisen?


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Mi 15 Sep 2010 13:29:26 CEST
Betreff: Archiv 36
zu 1: Grundsätzlich können alle Listen ein Event auslösen, welches eine Verbindungsanforderung hervorruft. Für das Wählprofil soll man aber nur die Liste 36 benutzen, da man hier alle Meldungen hinzufügt, die sofort gemeldet werden sollen.zu 2: Die SetEvent Methode der Liste 36 unterscheidet sich nicht von den SetEvent Methoden der anderen Listen. Entsprechend den Regeln soll hier der Wert 0% verwendet werden.



27


Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Fr 03 Sep 2010 14:41:46 CEST
Betreff: Liste::SetOverwriteOnFull
Ist das Setzen auch bei den Standardlisten (0, 1, 4) möglich? Wenn ja, impliziert dies, dass die Methode auf laufende Listen angewandt werden kann.

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Mo 06 Sep 2010 10:39:29 CEST
Betreff: Liste::SetOverwriteOnFull
Zu dem Punkt ob „SetOverwriteOnFull“ bei laufender Liste verwendet werden kann oder nicht ist in den Dokumenten nichts definiert. Wahrscheinlich spricht nichts gegen die Verwendung bei laufender Liste, aber diese Frage muss am nächsten Workshop der ODG geprüft werden.



26


Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Fr 03 Sep 2010 14:36:29 CEST
Betreff: Auftrag::Start/Stop
Bei der Fehlerbeschreibung im XML steht: "NOT_ACTIVE : wird geliefert, wenn die Liste nicht gestartet ist." Was hat NOT_ACTIVE für einen Wert?

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Mo 06 Sep 2010 10:35:52 CEST
Betreff: Auftrag Start Stop
Den RetCode „NOT_ACTIVE“ gibt es nicht. Das ist ein Fehler in der DESCRIPTION der XML und wird durch die Kommentare aus dem Dokument OCIT-O Basis, Kapitel 4.2.4.2 zu den Methoden 105 Start und 106 Stop ersetzt.



25


Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Fr 27 Aug 2010 16:20:11 CEST
Betreff: Archive auslesen bei Zeitsprüngen
Guten Tag

Zum Auslesen eines Archivs wird GetSFSince(WithEvent) verwendet. Dieser Befehl liefert eine AbZeit/AbPos zurück, mit welcher der nächste Aufruf gemacht wird.

Nun habe ich die Systemzeit des LSTG um 5 Minuten vorgestellt (%3C30 Minuten, sonst verweigert btppl den Befehl). Soweit lief alles ordnungsgemäss weiter. Dann kam das LSTG auf die Idee, die Zeit wieder korrekt einzustellen. Da jetzt die SF mit einer scheinbar in der Vergangenheit liegenden Zeit (bezüglich den zuletzt erhaltenen AbZeit/AbPos-Werten) eingetragen wurden, bekam ich während 5 Minuten NO_SF als Respond.

Wie muss in dieser Situation vorgegangen werden?
Was kann das LSTG/die Zentrale tun, damit die Werte ausgelesen werden?
Oder sind die Daten einfach verloren?

ODG (odg@ocit.org)
Datum: Sa 04 Sep 2010 13:42:07 CEST
Betreff: Archive auslesen bei Zeitsprüngen
Verwenden sie einfach „BisZeit/BisPosNr“ für den nächsten GetSFSince-Aufruf! Siehe Beschreibung der Methode 102 GetSFSince aus dem Dokument OCIT-O_ Basis_V2.0-A03, Kapitel 4.2.42:


Methode 102 GetSFSince:

Sekundenframes ab übergebener Zeit/Positionsnummer in der Reihenfolge ihres Entstehens lesen. Es werden nur Sekundenframes zurückgegeben, die im Ringpuffer nach diesem Element eingetragen wurden (Ohne Zeitumstellung sind das nur jüngere Elemente. Bei Zeitumstellungen wird in jedem Fall nach der Reihenfolge des Eintragens ausgegeben, nicht nach dem Zeitstempel).....

BisZeit: ZEITSTEMPEL_UTC:
Zeitstempel des letzten im folgenden gesendeten Elements also von Element[Anzahl-1].

BisPosNr : ui4
Positionsnummer des letzten im folgenden gesendeten Elements also von Element[Anzahl-1].


24


Name: Uwe Jakobi (Uwe.Jakobi@albrechtConsult.com)
Datum: Mo 16 Aug 2010 17:35:18 CEST
Betreff: Anwenderversorgung von Zwischenzeitenmatrizen
In OCIT-O_Lstg_V2.0_A02 ist zum Objekt VTZwischenzeitenmatrix 1:668 zu lesen

"In diesem Objekt werden die verkehrstechnischen Zwischenzeitenmatrizen für besondere Signalprogramme (z.B. Schlechtwetter) gespeichert. Verkehrstechnische Zwischenzeitenmatrizen haben die Nummern 1..3. ..."

Kann man daraus folgern, dass nur verkehrstechnische Zwischenzeitenmatrizen anwenderversorgt werden können, oder kann die Zwischenzeitenmatrix mit Nr=0 (die sog. sicherheitstechnische Zwischenzeitenmatrix) auch anwenderversorgt werden? Exemplarische Rückfragen bei 2 OO-Lizenznehmern haben ergeben, dass deren Lstg die Anwenderversorgung der Zwischenzeitenmatrix mit Nr=0 erlauben...

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Mi 25 Aug 2010 11:27:15 CEST
Betreff: Anwenderversorgung von Zwischenzeitenmatrizen
Gemäß der OCIT-O V2.0 Dokumentation darf die sicherheitstechnische Zwischenzeitenmatix nur herstellerversorgt werden. Eine Versorgung der sicherheitstechnischen Zwischenzeitenmatix ist nicht modelliert und in der LSA-Anwenderversorgung nicht enthalten. Im Objekt Signalprogramm ist die sicherheitstechnische Zwischenzeitenmatix mit der Nr. 0 jedoch als Auswahl versorgbar, eben dann, wenn diese anstelle einer verkehrstechnischen Zwischenzeitenmatix verwendet werden soll.



23


Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Mo 26 Jul 2010 17:11:57 CEST
Betreff: SetOverwriteOnFull
Guten Tag

In der Datei OCIT-O_Basis_V2.0_A02.pdf kann folgendes nachgelesen werden:

1. Liste::Reset: "Hält die Liste an. Entfernt alle mit AddAuftrag angefügten Aufträ-ge wieder aus der Liste. Der Ringpuffer wird gelöscht. Setzt die EventDestination auf die Zentrale. Wenn eine EventDestination eingetragen war, wird an die alte EventDestination ein OnInvalidate gesendet."

2. Liste::SetOverwriteOnFull: "Falls gesetzt (true), überschreibt die Liste die alten Datenframes (Ringpuffer). Andernfalls stoppt die Liste. Die Defaulteinstellung nach Reset ist true (Ringpuffer)."

Nun meine Frage dazu: Gehe ich richtig in der Annahme, dass beim Text vom Reset vergessen wurde zu erwähnen, dass OOF ebenfalls zurückgesetzt werden muss?


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Mi 28 Jul 2010 09:11:54 CEST
Betreff: SetOverwriteOnFull
Bei einem Reset der Liste muss das FG das Verhalten des Ringpuffers auf "OverwriteOnFull=true" einstellen.

 



22


Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Mi 24 Mär 2010 11:00:04 CET
Betreff: Was sind Auftragselemente mit zusammengesetzter Struktur?
Bei MWAuftragAbtastAenderung und MWAuftragVergleich steht bei der Methode SetAEZeit beim Parameter AbtastAENr: "Nummer des Auftragselements, das abgetastet wird. Das Auftragselement darf keine zusammengesetzte Struktur sein." Was sind Auftragselemente mit zusammengesetzter Struktur?

Wenn ich mal spekuliere und AEAggregiert als solches Element anschaue, dann verstehe ich nicht, warum dieses AE nicht in einem MWAufragAbtastAenderung verwendet werden soll. Hingegen sehe ich die Problematik beim MWAuftragVergleich, da zwei Werte geliefert werden durch das AE, aber nur auf einen Wert verglichen werden kann. Analog verhält es sich auch bei AEDetExt, AEAggregiertExt, AEAPWertVektor und AESiplOnline.

Bitte notieren Sie in einer vollständigen Liste, welche AE bei welchen Aufträgen durch die Aussage in der Spezifikation betroffen sind. Danke.

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Di 30 Mär 2010 11:05:27 CEST
Betreff: Auftragselemente mit zusammengesetzter Struktur
Der Satz „Das Auftragselement darf keine zusammengesetzte Struktur sein." wird in einer Ausgabe A03 voraussichtlich gestrichen. Anstelle dessen, werden bei allen Auftragselementen die Beschreibungen der Methode GetTriggerValue, die die Werte welche zur Abtaständerung / Vergleich herangezogen werden beschreibt, präzisiert.



21


Name: Andreas Leupold (andreas.leupold@uni-weimar.de)
Datum: Mo 15 Mär 2010 21:02:47 CET
Betreff: Allgemeine Fragen zu OCIt
Sehr geehrte Damen und Herren,

im Rahmen meiner Forschungstätigkeit - in der allerdings die (tief) technischen Belange der Lichtsignalsteuerung untergeordnet sind - ergeben sich für mich immer wieder zwei zentrale Fragen im Zusammenhang mit OCIT, welche ich mehrfach versucht habe durch die Informationen, die auf dieser Seite zur Verfügung gestellt werden, zu klären.

Für die folgenden zwei Fragen entschuldige ich mich voraus, da sie zum einen vielleicht nicht so spezifisch wie die anderen Fragen im Forum sind und zum anderen Sie sich diese Fragen vielleicht gar nicht stellen würden, weil diese in Ihrem Verständnis banal sind.

1. Frage - Ist es in einem OCIT-System zwingend, dass für die Kommunikation zwischen Verkehrsrechner und Steuergerät sowohl das Steuergerät als auch der Verkehrsrechner jeweils über ein(e) OCIT-Element (Schnittstelle) verfügen müssen?
Die zweite Frage ist ähnlich.
2. Frage - Ist es ausreichend den Verkehrsrechner mit OCIT-Schnittstellen zu versehen um Steuergeräte verschiedener Hersteller und somit mit verschiedenen Schnittstellen anzuschließen? Soll heißen, beherrscht OCIT die gängigen Schnittstellen der verschiedenen Hersteller, die zum Zeitpunkt der Entwicklung von OCIT bekannt waren, so dass OCIT nur am Verkehrsrechner vorhanden sein muss.

Vielen Dank

Mit freundlichen Grüßen
Andreas Leupold
wissenschaftlicher Mitarbeiter

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Di 16 Mär 2010 09:03:14 CET
Betreff: Allgemeinen Fragen zu OCIT
Zu 1)

Ja, sowohl VR als auch die Lichtsignalsteuergeräte müssen über eine OCIT-Implementierung verfügen.

Zu 2)
Nein, OCIT-O im VR kann nicht die verschiedenen Bestands-Schnittstellen bedienen. In OCIT-O sind sowohl Protokoll (auf Basis TCP/IP) als auch Funktionen definiert. Moderne Geräte mit OCIT-O -Schnittstellen bieten den gesamten OCIT-O Funktionsumfang. Ältere Schnittstellen können keine Internetprotokolle bedienen und ihr Funktionsumfang ist von Typ und Hersteller her verschieden. Da aber der Funktionsumfang von OCIT-O eine Untermenge der von Bestands-Schnittstellen her bekannten Funktionen beinhaltet, ist es möglich Bestandsgeräte über OCIT-Vorsatzgeräte, die in die Lichtsignalsteuergeräte eingebaut werden, zu betreiben.


20


Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Mo 15 Mär 2010 16:23:27 CET
Betreff: FillingDegree von Listen
Guten Tag

Liste::Get liefert unter anderem das Attribut FillingDegree zurück, beschrieben als "aktueller Füllstand der Liste". Was bedeutet das genau?
a) Effektiver aktueller Füllstand der Liste?
b) Wert, welcher mit SetEvent.Fill rsp. GetSFSinceWithEvent.Fill gesetzt wurde?

Wie würde im Fall a) der gesetzte Fill-Wert abgefragt werden?

 


19


Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Mo 15 Mär 2010 13:37:13 CET
Betreff: Zählweise bei nummerierten Elementen
In OCIT-O_Basis_V2. 0_A02.pdf, Kapitel 2.3 steht:
" Die Adressierung nummerierter Elemente wie Signalgruppen und Detektoren etc. beginnt mit dem Indexwert 1. Der Index wir nicht gemappt: Index 1 adressiert Element 1 usw. Damit ist sichergestellt, dass der Indexwert mit der von den Anwendern verwendeten Nummer eines nummerierten Elements übereinstimmt."

Das "etc." ist nicht greifbar. Was versteckt sich noch alles dahinter?

Was ist hier mit Index gemeint? Normalerweise bezieht sich dieser auf den Platz in einem Array, wobei 0 dann dem 1. Element im Array entspricht. Das würde dann aber bedeuten, dass das erste Array-Element bei diesen Ausnahmen nicht verwendet wird (-%3EPlatzverschwendung) und somit der Array um ein Element grösser gewählt werden müsste.

Der Ursprung dieser Frage kommt vom Tagesplan 1:660 her. Da wird dreimal "Nr" verwendet jeweils mit unterschiedlichem Wertebereich, rsp. unterschiedlicher Bedeutung:
- Path: Nr=OBJECT_ID_UBYTE, 0..0xFE, definiert 1=Standard Tagesplan
Ist 0 als Tagesplan-Nr trotzdem zugelassen oder wird mit 2 weitergezählt?
- Programmwunsch.Nr=SIGNALPROGRAMMNR, 1..0xFF
Hier beginnt es laut Type-Definition bei 1.
- Modifikation[0..12].Nr=OBJECT_ID_UBYTE, 0..0xFE, alle 13 müssen da sein (MIN=MAX=13)
Beginnt Nr bei 0 oder ist dies so ein "etc."?


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

odg (odg@ocit.org)
Datum: Mo 15 Mär 2010 13:48:50 CET
Betreff: Zählweise bei nummerierten Elementen
A: „etc.“ meint Index 2 adressiert Element 2 und so geht es weiter.

Zu den Modifikationen: 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.


Andreas Grob (andreas.grob@bergauer.ch)
Datum: Mo 15 Mär 2010 15:48:14 CET
Betreff: Zählweise bei nummerierten Elementen
Danke für ihre Antwort. Leider werden meine Fragen darin nicht abschliessend beantwortet.

- Sie erklären mir den Sachverhalt zu den total 16 Modifikationen. Sie zitieren dafür aus OCIT-O_Lstg_V2.0_A01.pdf. Dieses Dokument erachte ich als überholt und ohne Relevanz. Gerade im Bereich Versorgung wurden einige Änderungen gemacht. Bezogen auf meine Frage wurde mincount auf 13 gesetzt. Entsprechend entfällt das implizite Attribut "Anzahl". Auch wurden die Array-Wertebereiche im pdf korrigiert von [0..13] auf [0..12] in A02.

- Anstelle einer Stellungsnahme zu "etc." erklären Sie mir die Bedeutung von "usw." im aufgeführten Zitat. Gemeint war, was sind weitere nummerierte Elemente analog Signalgruppen und Detektoren?

- Hier nochmals meine ursprüngliche Frage. Welche Zahlen werden beim Tagesplan dem Attribut "Befehl[0..254].Modifikation[0..12].Nr" zugeordnet? 0 bis 12 oder 1 bis 13?


ODG (odg@ocit.org)
Datum: Mo 15 Mär 2010 16:12:15 CET
Betreff: Zählweise bei nummerierten Elementen
Die Nummerierung ist 1 .. 13.

Die Angabe [0..12] bezieht sich auf den Index in der Liste und der erste Index ist eben 0.



18


Name: Dieter Isler (dieter8496@bluemail.ch)
Datum: Mo 01 Mär 2010 12:06:01 CET
Betreff: SiplOnline - Auftrag MWAuftragAbtastAenderung
In der Dokumentation OCIT_O_Lstg_V2.0_A02 steht auf Seite 139ff, dass bei konstantem Anzeigebild nur die Umlaufzeit Tx im Sekundenframe ist. Müsste in diesem Fall auch noch die AnzSigru (== 0) mitgegeben werden, damit der SF vollständig ist, oder genügt nur die Umlaufzeit TX?

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Di 02 Mär 2010 15:18:11 CET
Betreff: SiplOnline - Auftrag MWAuftragAbtastAenderung
Die Anzahl der Signalbilder (also 0) muss im Frame stehen.



17


Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Fr 26 Feb 2010 18:45:05 CET
Betreff: Aggregierungsintervall bei AEAggregiert
Grüezi

In OCIT-O Lstg 2.0 A02 Kapitel 3.5.3.2 steht, wie das Aggregierungsintervall (AggrI) gedeutet werden soll. Bei AggrI=0 habe ich Mühe mit dem Verständnis. Ich deute mal:

Der MWAuftragAbtastAenderung prüft zyklisch, ob sich der Werte eines AE geändert hat und schreibt nur im Änderungsfall ein SF. Bei AggrI=0 muss sich das AE im Prinzip an das Abtastintervall (AbI) des Auftrags halten. Findet nun keine Wertänderung gegenüber dem letzten AbI statt, wird kein SF geschrieben und für das AE verlängert sich dadurch das AggrI (erneut) um das AbI des Auftrags. Daraus folgt eine variable Länge des eigentlichen AggrI.

Habe ich das so richtig interpretiert? Wenn ja, ist das komplex zu implementieren. Das AE muss zu einer gewissen Zeit einen Wert bereit stellen und je nach dem, ob der Auftrag ihn im SF einträgt, von vorne beginnen zu aggregieren oder eben dort weitermachen wo es war. Zudem könnten mehrere AE in einem Auftrag vorkommen...

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Mo 01 Mär 2010 09:06:42 CET
Betreff: Aggregierungsintervall
Richtig interpretiert. Mit einem MWAuftragAbtastAenderung und einem AEAggregiert mit Aggregierungsintervall von 0 kann es unterschiedlich lange Aggregierungsintervalle geben.
Und es können auch mehrere AuftragsElemente in einem Auftrag vorkommen. Allerdings wird vom MWAuftragAbtastAenderung immer nur eines von seinen Auftragselementen auf Änderung "überwacht" und als Trigger verwendet. Welches Auftragselement dies ist wird über die AbtastAENr festgelegt.



16


Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Di 05 Jan 2010 16:07:03 CET
Betreff: Liste::SetEvent
Hallo,

Mit der Methode SetEvent (oder GetSFSinceWithEvent) wird (unter anderem) festgelegt, ab welchem Füllgrad eine Liste das OnFull-Event auslösen soll. Um diesen Mechanismus wieder auszuschalten soll ein Wert grösser 100 für das Attribut Fill verwendet werden (XML-Doku).
Nun ist der Wertebereich von Fill als PROZENT wir folgt definiert:
Basetypename=UBYTE Min=0 Max=0x64 Nullval=0xff Resolution=1.000 Unit=%

Ich gehe deshalb davon aus, dass "grösser 100" konkret 255 bedeutet. Ist das richtig?

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@online.de)
Datum: Mi 20 Jan 2010 10:45:28 CET
Betreff: SetEvent
Ja, richtig!



15


Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Di 05 Jan 2010 15:23:31 CET
Betreff: Liste::SetSize
Guten Tag
Ich habe ein paar Fragen zu Liste::SetSize 0:400:110.

*** In-Parameter Persistenz
Wie muss ein LSTG reagieren, wenn auf eine Liste ein SetSize Befehl abgesetzt wird mit Persistenz=1 (oder 2), das LTSG aber nur 0 (keine) verarbeiten kann?
Ich sehe drei Möglichkeiten:
1.) OK, mit den im LSTG eingestellten Werten im RESPOND-Tgm
2.) PARAM_INVALID, keine Übername der Soll-Werte, entsprechend auch keine Änderung der Listenversion
3.) NOT_INACTIVE, ist für diese Frage aber nicht von Bedeutung
Ich würde 1.) begrüssen.

*** In-Parameter ListeSizeP
Was versteht man unter dem "restlichen verfügbaren" Speicher? Soll man sich hier einen 100%-Kuchen vorstellen, der in %-Stücke zerteilt werden kann (a), oder dass vor einem Aufruf von SetSize jeweils 100% zur Verfügung steht (b)? Anhand der Doku würde ich auf b) tippen, was aber eine Zuordnung schwierig gestaltet. Ein kleines Beispiel: Es soll der ganze restlich verfügbare Speicher gleichmässig auf zwei Listen verteilt werden.
a) Erster Aufruf (L31) mit 50%, zweiter Aufruf (L32) mit 50% -%3E Reihenfolge der Aufrufe/Werte beliebig
b) Erster Aufruf (L31) mit 50%, zweiter Aufruf (L32) mit 100% -%3E Reihenfolge der Aufrufe/Werte ist entscheidend

- Wie muss das LSTG im Fall a) reagieren, wenn der zweite Aufruf einen Wert grösser 50 enthält? Hier denke ich ist die Doku klar, also mit OK und der entsprechenden Grösse im RESPOND-Tgm.

- Kann diese Methode auch zum verkleinern der angesprochenen Liste verwendet werden? Dann müsste der Fall a) der richtige sein. (Ausser 255 (Nullval) würde die Liste in ihre ursprüngliche Grösse zurücksetzen, dann wäre mit einem erneuten setzen der Grösse das Gleiche erreichbar.)

- Daraus ergibt sich die Frage, wie wird mit dem Wert 255 (Nullval) hier grundsätzlich umgegangen?

- Was geschieht mit eingestellten Grössen bei einem Liste::Reset? Bleiben sie erhalten oder werden sie auf die Hersteller spezifischen Werte zurückgesetzt?

2 Name: Andreas Grob (andreas.grob@bergauer.ch)
Datum: Di 16 Feb 2010 14:52:33 CET
Betreff: Liste::SetSize
Die Antwort auf die letzte Frage kann ich mittlerweile selbst beantworten. In OCIT-O_Basis_V2.0_A02.pdf, Kapitel 5.1.2 Ablauf steht geschrieben, wie eine Liste aufgesetzt wird.
1. Reset der Liste
2. Festlegung der Listengrösse
3. ...

Daraus schliesse ich zwingend, dass ein Liste::Reset bewirkt, dass die Listengrösse und die Persistenz wieder auf die herstellerspezifischen Werte zurückgesetzt werden.

Antworten auf diesen Eintrag

1 Name: odg (odgf@ocit.org)
Datum: Do 04 Feb 2010 09:02:57 CET
Betreff: Liste:.Set Size
Zum ersten Punkt sind wir der Meinung dass hier NOT_POSSIBLE zurückgegeben werden sollte (und keine Änderungen durchgeführt werden).
Bei zweiten Punkt ist (a) richtig.
NULLVALUE bei ListeSizeP hat keinen Sinn, wird also mit PARAM_INVALID abgelehnt.
Liste.Reset macht das was in den Dokumenten steht (Aufträge und Daten löschen, Eventdestination zurücksetzen), mehr nicht.


14


Name: Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: So 03 Jan 2010 14:03:35 CET
Betreff: BTPPL Version im BTPPL-Header
Bei der Analyse von BTPPL-Traces der Kommunikation zwischen der Nürnberger Lichtsignalsteuerungszentrale und einem Siemens-Lstg ist mir aufgefallen, dass beide Systeme im Flag des BTPPL-Headers die Bits 2^4..2^3 (V = OCIT-Outstations-BTPPL Version) immer auf 0 gesetzt haben.

In den aktuellen OO-Dokumenten steht hierzu:

OCIT-Outstations-BTPPL Version ((Flag %3E%3E 3) %26 3):
0: OCIT-Outstations-BTPPL Version 1
1..3: reserviert

Es wird um Klärung gebeten, ob V2.0-Systeme 0 oder 1 senden müssen.

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: Mo 04 Jan 2010 09:56:36 CET
Betreff: Version
V2.0-Systeme muessen 0 senden:
Das OCIT-Outstations-BTPPL-Protokoll hat sich mit V2.0 nicht geaendert und hat immer noch Version 1.


13


Name: Dieter Isler (dieter8496@bluemail.ch)
Datum: Di 15 Dez 2009 13:21:20 CET
Betreff: AEAPWertVektor - SekundenFrame und GetListConfig
Wenn ich auf dem FG einen AuftragElement vom Typ 1:437 (AEAPWertVektor) an einen Auftrag (z.B.: 1:403 AuftragZykl) anhänge und mit SetAPListe einen Vektor im Format gemäss HTML- Dokumentation (..../ocit_xml_v2.0_20090324/ocit.html.html) anlege, möchte ich den Frame mit GetListConfig Liste X sehen können. Es kommt jedoch als letzte Ausgabe nur die AuftragsElementNr. Die DatenLen jedoch deutet auf mehr Inhalt hin, als für nur ein Byte nötig wäre. Auch der SekundenFrame wird nicht aufgelöst, sondern es erscheint "skipping xxx SekundenFrame = yyyy bytes". Wenn ich hingegen ein SiplOnline- AuftragElement anhänge, erscheint es im Resultat von GetListConfig und der SekundenFrame wird decodiert.
Im File "OCIT-O_Lstg_V2.0_A02.xml" finde ich u. a. einen Frame für SiplOnline, nicht jedoch für AEAPWertVektor. Gibt es eine neuere Lstg- Konfiguration, oder habe ich den AEAPWertVektor falsch verstanden?

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

 



12


Name: Uwe Jakobi (Uwe.Jakobi@AlbrechtConsult.com)
Datum: Fr 11 Dez 2009 16:23:26 CET
Betreff: Zulässige und sinvolle Zuordnung von AuftragsTypen und AuftragsElementen
Hallo!

Können Sie in Form einer Tabelle eine Zuordnung aller AuftragsTypen und aller AuftragsElementTypen bereitstellen, die die erlaubten und ein sinnvolles Ergebnis liefernden Kombinationen darstellen? Insbesondere bezüglich der Nutzung bei den AEs AEAggregiert und AEAggregiertExt besteht in den von uns betreuten Projekten große Unsicherheit und die Hersteller scheinen dies unterscheidlich zu interpretieren... :-(

Danke im Voraus für Ihre Bemühungen! :-)

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

ODG (odg@ocit.org)
Datum: So 07 Mär 2010 18:20:08 CET
Betreff: Zulässige und sinvolle Zuordnung von AuftragsTypen und AuftragsElementen
Eine Liste (0:400) hat Aufträge
Ein Auftrag hat
• entweder vordefinierte Aufträge (nur Meldungen)
• oder ein Auftrag wird mit der Methode Liste::AddAuftrag (0:400.108) hinzugefügt
Ein hinzugefügter Auftrag hat einen Auftragstyp, eine AuftragsNr und im können abhängig vom Auftragstyp AuftragsElement (e) zugewiesen werden. Es gibt Aufträge, denen keine AuftragsElemente zugeordnet werden können.
Die angegebene Domain des Auftragstyps bei Liste::AddAuftrag muss vom Auftrag abgeleitet sein. Auftragstypen sind:
Dynamische Attribute
0:405 Meldungsauftrag Bei jeder Meldungsliste gibt es pro Meldungsdegree (Information, Warnung, Fehler, schwerer Fehler) einen Meldungsauftrag Auftrag:running
Auftrag:ActivateEventOnInsert
Degree
1:403 AuftragZykl Der zyklisch abgefragte Auftrag (AuftragZykl) trägt die Auftragselemente zyklisch ein. Die Zeitpunkte TZykl und Versatz werden im Sekunden-Maßstab eingetragen. Auftrag:running
Auftrag:ActivateEventOnInsert
Abtastintervall
Versatz
1:406 MWAuftragAbtastAB Es ist sinnvoll, die digitalen Daten einer Einzelschleife komprimiert im Messwertarchiv abzulegen. Normalerweise wird bei einem Messwertauftrag die Wertänderung gespeichert, wobei der neue Wert in einem Parameter hinter dem Subsekundeneintrag abgelegt wird. Da bei binären Signalen der neue Wert sich in einem Bit darstellen lässt und solche Wertänderungen sehr häufig auftreten, wird in diesem Sonderfall das Parameterbyte eingespart und der neue Zustand in Bit 2^7 des Subsekundeneintrags im Auftragsframe gespeichert. Auftrag:running
Auftrag:ActivateEventOnInsert
-
1:407 MWAuftragAbtastAenderung Auftrag bei Abtaständerungen. Dieser Auftrag betrachtet den Wert eines Auftragselements (eine Prozessvariable) im angegebenen Intervall. Ändert sich dieser Wert, so schreibt der Auftrag einen Sekundenframe. Auftrag:running
Auftrag:ActivateEventOnInsert
Abtastintervall
Versatz
AbtastAENr.AuftragsElement
1:408 MWAuftragVergleich Dieser Auftrag ist eine Spezialisierung der Prüfung auf Werteänderung. Das Verfahren überträgt nur wenn a) eine Werteänderung stattgefunden hat und b) die eingegebene Bedingung erfüllt ist. Auftrag:running
Auftrag:ActivateEventOnInsert
Abtastintervall
Versatz
MWAuftragAbtastAenderung:
AbtastAENr^5.AuftragsElement
Operator
VglWert
1:409 MWAuftragExtern Auftrag für Prozessvariable die asynchron durch externe Ereignisse entstehen.
Dies sind wohl nur R09-Telegramme!? Auftrag:running
Auftrag:ActivateEventOnInsert
-
1:410 MWAuftragR09 Der R09-Auftrag generiert immer Frames des Typs: MWAuftragFrameR09. Wenn der Auftrag gesetzt wird, werden alle für dieses Feldgerät relevanten R09-Telegramme abgespeichert. Auftrag:running
Auftrag:ActivateEventOnInsert
-
1:411 MWAuftragAMLi Der Auftrag für erweiterte R09-Telegramme ist gegenüber dem Auftrag für R09-Telegramme von der Auswahl her gleich und liefert nur einen erweiterten Datensatz(z.B.:GNA, GNE TX...) zurück Auftrag:running
Auftrag:ActivateEventOnInsert
-
1:412 MWAuftragDetExt Einige Schleifendetektoren liefern bei Konfiguration als Doppelschleife neben der allgemein üblichen Belegungs- und Lückeninformation noch weitere Werte, welche in moderneren Steuerverfahren verwendet werden können. In der Regel sind dies Geschwindigkeit, Fahrzeugart, Fahrzeuglänge und die Fahrdauer von der ersten bis zur zweiten Schleife. Auftrag:running
Auftrag:ActivateEventOnInsert
-

Einem Auftrag können AuftragsElement (e) zugefügt werden.
Bei Meldungsauftrag, MWAuftragExtern, MWAuftragR09 und MWAuftragAMLi ist dies nicht möglich bzw. sinnvoll, da diese Aufträge einen AuftragsFrame immer direkt (asynchron) schreiben, wenn eine Meldung erzeugt oder ein R09-Telegramm empfangen wurde.
Ein AuftragsElement wird mit der Methode Auftrag::AddElement (0:402.120) hinzugefügt
Ein hinzugefügtes AuftragsElement hat einen AuftragsElementtyp (AETyp), eine AuftragsElementNr und abhängig vom AuftragsElementtyp Attribute / Parameter
Folgende AuftragsElementtypen gibt es
DigEingang SignalGruppe APWert
1:431 AEBinaer Binäre Eingänge, wie z.B. Detektoreingänge oder auch Taster werden über das Auftragselement für binäre Eingänge erfasst. AuftragsElement:Nr
Channel^3.Channel x
1:432 AEAggregiert Wenn Schleifendetektoren als binäre Eingänge verwendet werden, ist es ggf. sinnvoll anstelle der Übertragung von Einzelwerten die Zählung und Belegungsgrad bereits im Gerät zu bilden. Die Zählung wird immer normiert in Fz/h (als USHORT) ausgegeben, der Belegungsgrad in % (als UBYTE).Ein AEAggregiert hat ein Aggregierungsintervall. Es gibt zwei Fälle:• Ist das Aggregierungsintervall ==0 wird nur beim Schreiben des Elementes in den Sekundenframe ein neues Aggregierungsintervall begonnen. Die Methode Get TriggerValue liefert in diesem Fall immer den Wert 0.• Ist das Aggregierungsintervall %3E0 wird in diesem Zyklus ein neues Aggregierungsintervall begonnen. Das Auftragselement schreibt immer die Werte des letzten Aggregierungsintervalles in den Sekundenframe AuftragsElement:Nr
Channel^3.Channel
AggregierungsIntervall
Versatz
UseBelegungAsTrigger x
1:433 AESignalBild Das Auftragselement Signalbild referenziert immer logische Signalbilder. AuftragsElement:Nr
SignalGruppe^3.RelKnotenRef^3.RelKnotenNr
SignalGruppe^3.Nr x
1:434 AEAPWert Auftragselement für Anwenderprogrammwerte (APWert). Dieses Auftragselement referenziert einen von APWert abgeleiteten Objekttyp (APWertUshort, APWertLong, APWertBlock, …) AuftragsElement:Nr
APWert?^3.RefLen
APWert?^3.Member
APWert?^3.OType
APWert?^3.ApWertName x
1:435 AEDetExt Auftragselement für Doppelschleifen mit Zusatzinformationen. Nur mit AuftragDetExt sinnvoll. AuftragsElement:Nr
AEBinaer:AuftragsElement:Nr
AEBinaer:Channel^3.Channel x
1:436 AEAggregiertExt liefert aggregierte Zählung, Geschwindigkeit unterschieden nach PKW/LKW und den Belegungsgrad. Aggregierung wie bei Basisklasse. Falls die Zaehlung als Trigger gewählt ist, liefert das Auftragselement die Zählung 1 als Voreinstellung. AEBinaer:AuftragsElement:Nr
AEBinaer:Channel^3.Channel
AEAggregiert:AggregierungsIntervall
AEAggregiert:Versatz
AEAggregiert:UseBelegungAsTrigger x
1:437 AEAPWertVektor Das Auftragselement AEAPWertVektor erlaubt blockweises Lesen von APWerten. AuftragsElement:Nr x
1:438 AESiplOnline Auftragselement zur vereinfachten Beauftragung einer Signalzustandsvisualisierung eines relativen Knotens (über ein einzelnes Auftragselement), das in einem AuftragZyklisch oder AbtastAenderung enthalten sein kann. Es erzeugt als Eintrag im Sekundenframe den Wert TX (USHORT) gefolgt von der Anzahl der Signalgruppen (UBYTE). Darauf folgen die Signalisierungszustände in aufsteigender Reihenfolge von Signalgruppe 1 bis zur angegebenen Anzahl der Signalgruppen. Damit wird die Größe der übertragenen Datenpakete auf das nötigste beschränkt und die Zuordnung der Werte zu den einzelnen Signalgruppen auf Zentralenseite bleibt gewährleistet. AuftragsElement:Nr
RK^3.RelKnotenNr
SignalGruppen.Anzahl
SignalGruppen[0..254]^4.Nr x
1:439 AEDigAusgang Dieses Objekt ist für die Online-Visualiserung des Signalplans (z.B. Fußgängertaster) vorgesehen, andere Verwendungszwecke sind optional. Das Auftragselement DigAusgang referenziert immer logische Zustände. AuftragsElement:Nr
DigAusgang^3.RelKnotenRef^3.RelKnotenNr
DigAusgang^3.Nr

AE’s für Rohwerte (nicht aggregierte / verdichtete Rohwerte)
AE’s für aggregierte Rohwerte

AEBinaer AEAggregiert AESignalBild AEAPWert AEDetExt AEAggregiertExt AEAPWertVektor AESiplOnline AEDigAusgang
0:405 Meldungsauftrag - - - - - - - - -
1:403 AuftragZykl - x x x x x x x x Nicht alle AE machen wirklich Sinn
1:406 MWAuftragAbtastAB x - - - - - - - - AddElement darf bei dem Auftragstyp MWAuftragAbtastAB nur einmal (!) mit dem Typ AEBinaer aufgerufen werden (und sonst mit keinem Typ). Sonst liefert AddElement den Fehler NOT_POSSIBLE zurück!
1:407 MWAuftragAbtastAenderung x x x x x Das Auftragselement darf keine zusammengesetzte Struktur sein. -%3E Was bedeutet das?
Nicht alle AE machen wirklich Sinn
1:408 MWAuftragVergleich x x x x x x x x Das Auftragselement darf keine zusammengesetzte Struktur sein. -%3E Was bedeutet das?
Nicht alle AE machen wirklich Sinn
1:409 MWAuftragExtern - - - - - - - - -
1:410 MWAuftragR09 - - - - - - - - -
1:411 MWAuftragAMLi - - - - - - - - -
1:412 MWAuftragDetExt x Da diese Daten völlig asynchron entstehen, soll hier sinnvollerweise auch nur ein Auftragselement pro Auftrag definiert werden.

Zu klären:

1. Unter welchen Bedingungen sind mehrere AEs pro Auftrag möglich bzw. sinnvoll?
Antwort ODG: Gem. Dokumentation

2. Wie die obige Tabelle zeigt ist aus den OO-Dokumenten nicht eindeutig erkennbar, für welchen Auftragstyp welche AEs vom Lstg (sinnvoll) zu unterstützen sind. Insbesondere scheint es keine explizite Festlegung zu geben, welchem Auftragstyp die aggregierten AEs zugewiesen werden können/dürfen. Bitte die "Kreuzchen" entsprechend eintragen.

Antwort ODG: Keine Einschränkung.

3. Welche Werte würde AuftragZykl für ein AEAggregiert eintragen, wenn das Abtastintervall von AuftragZykl deutlich kleiner ist, als der AggregierungsIntervall von AEAggregiert?

Antwort ODG: Immer den aktuellen Wert des AEAggregiert

4. Sind beim Auftragstyp MWAuftragAbtastAenderung mehr als ein AE möglich und/oder sinnvoll?
Antwort ODG: Ja

5. Welchem Auftragstyp darf AEDigAusgang zugeordnet werden? (Die Grafik in OO Lstg Seite 116 ist nicht vollständig und enthält ein paar Pfeile ohne Sinn.)

Antwort ODG: Analog zu AESignalbild



11


Name: solarik (a.solarik@gesig.at)
Datum: Mo 16 Nov 2009 12:03:16 CET
Betreff: ocit-o profil 3
hallo,

kap 3.2.1 zitat: "Ist das Feldgerät in der Zntrale nicht bekannt, *muss*die Zentrale keinen DHCP Offer liefern"

was genau ist da gemeint? probiert der author zu sagen, dass die zentrale einen DCHP offer liefern *darf* (bedeutung nicht gemaess RFC2119), oder meint er, dass die zentrale einen DHCP offer verweigern *muss* (wieder nicht gemaess RFC2119)?

besten dank im voraus fuer eine antwort!

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Wen (odg@ocit.org)
Datum: Di 24 Nov 2009 16:19:52 CET
Betreff: OCIT-O Profil 3
Bedeutung: Ist das Feldgerät in der Zentrale nicht bekannt, *darf* die Zentrale einen DHCP Offer liefern (muss aber nicht!)



10


Name: Enrique Gómez (@egomez@sice.com)
Datum: Fr 07 Nov 2008 09:39:29 CET
Betreff: Typetool
Hallo, a quiestion about 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.

Vielen Dank


Wenter (infoocit@online.de)
Datum: Mo 10 Nov 2008 14:38:07 CET
Betreff: Typetool
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.



9


Name: DI Karl Macku (office@debugprofi.at)
Datum: Do 18 Sep 2008 16:17:06 CEST
Betreff: Mapping Ap Werte zu OITD Nummern in Ocit 2.0
Grüß Gott,

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 ?


Danke für die Beantwortung.

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Wenter (p.wentwer@wentersystem.de)
Datum: Mo 22 Sep 2008 11:20:06 CEST
Betreff: AP-Werte
Sie haben Recht mit Ihrer Annahme, denn AP-Werte werden über ihren Namen als String addressiert.



8


Name: DI Karl Macku (office@debugprofi.at)
Datum: Sa 29 Dez 2007 11:40:00 CET
Betreff: AMLI Datensatz Fragen zu GNA/GNE
Grüß Gott,

Ich beziehe mich auf OCIT_O_Lstg_V1.1_A01 Seite 55 und 56 und den zugehörigen Ausführungen zum 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 ?

Herzlichen Dank für die Beantwortung



Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (2)

Admin (infoocit@online.de)
Datum: Mi 16 Jan 2008 14:50:16 CET
Betreff: AMLI Datensatz
Im Gegensatz zu den Zeitschaltwerten in den OCIT-Lichtsignalsteuergeräten, gibt es im AMLI-Datensatz aus historischen Gründen nur ganze Sekundenschritte. Auch 1/10 Sekunde Grün ist wird als volle Sekunde betrachtet.

Im Gegensatz zum Umlauf in den OCIT-Lichtsignalsteuergeräten (Tx = 0 bis Tu-1) wird im AMLI immer Tx = 1 bis Tx = Tu dargestellt.

Für die Erzeugung des AMLI-Datensatzes gibt es in OCIT-O keine Vorschrift.

Korrektur: 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).


Antworten auf diesen Eintrag

1


Name: Admin (p.f.w@online.de)
Datum: Mi 02 Jan 2008 14:12:10 CET
Betreff: GNA/GNE
• 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.


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Karl Macku (karl.macku@debugprofi.at)
Datum: Di 15 Jan 2008 22:00:52 CET
Betreff: GNA / GNE
Danke für die Ausführungen zu TX, demnach ergeben sich folgende Diskrepanzen:

a) GNA und GNE werden anscheinend in vollen Sekundenschritten angegeben, da ansonst der Wertebereich das Datenelement sprengt (Größe = UBYTE).

b) Da eine Signalgruppe zum Zeitpunkt TX= 0 grün bekommen kann, ergibt sich eine Mehrdeutigkeit der Werte GNA/GNE
deren Wertebereich auf [1..253] beschränkt ist, da [0,254,255] Sonderfälle representieren.

Somit darf ich nochmals auf meine Frage zurückkommen, wie die Zuordungsfunktionen GNA/GNE = f(TX) definiert sind.

Herzlichen Dank
Karl Macku

Admin (infoocit@online.de)
Datum: Mi 16 Jan 2008 14:53:38 CET
Betreff: AMLI Datensatz
Im Gegensatz zu den Zeitschaltwerten in den OCIT-Lichtsignalsteuergeräten, gibt es im AMLI-Datensatz aus historischen Gründen nur ganze Sekundenschritte. Auch 1/10 Sekunde Grün ist wird als volle Sekunde betrachtet.

Im Gegensatz zum Umlauf in den OCIT-Lichtsignalsteuergeräten (Tx = 0 bis Tu-1) wird im AMLI immer Tx = 1 bis Tx = Tu dargestellt.

Für die Erzeugung des AMLI-Datensatzes gibt es in OCIT-O keine Vorschrift.



7


Name: Peter Hunkeler (hun@vrag.ch)
Datum: Fr 12 Okt 2007 11:01:42 CEST
Betreff: Archivsteuerung
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?

Besten Dank für entsprechende Hinweise.

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Wenter (infoodg@online.de)
Datum: Fr 12 Okt 2007 11:32:57 CEST
Betreff: Archivsteuerung
- Das Lstg muss das dynamische Konfigurieren der im Stanadard 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.



6


Name: Karl Macku (karl.macku@debugprofi.at)
Datum: Do 27 Sep 2007 21:18:24 CEST
Betreff: Msg 1:60203 BzTkEinAus
Guten Morgen!
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?
Herzlichen Dank!


Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Wen (infoodg@online.de)
Datum: Fr 28 Sep 2007 10:43:40 CEST
Betreff: Meldung
Die Zuordnung der Meldung geschieht über das Element Teilknoten. Dies hat einen PATHPART TeilKnotenRef.




5


Name: Karl Macku (karl.macku@debugprofi.at)
Datum: Mi 05 Sep 2007 18:30:21 CEST
Betreff: Frgane zur Eventbehandlung OCIT_Outstation Profil 1 / Profil 2
Schönen guten Tag!

Ich bitte um Expertenrat auf folgende Fragen:

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 dieses
Objekt in einem Zentralenmischbtrieb (Profil 1 + Profil 2) ausschließlich für Profil 2 Outstations vorbehalten ?

Herzlichen Dank

Wenter (infoodg@online.de)
Datum: Fr 07 Sep 2007 17:23:50 CEST
Betreff: Profil 1 und 2
Antwort auf die Frage 1:
• 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 2:
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.

 

4


Name: solarik (a.solarik@gesig.at)
Datum: Mi 05 Sep 2007 14:25:23 CEST
Betreff: sourcecode btppl und typetool unter linux bauen
es gibt einige nicht definierten abhaengigkeiten beim build vom
typetool unter einem aktuellen linux. die readme.txt
(Sourcen_Protokoll_u._Typetool/README.txt) 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?

herzlichen dank für alle weiterführenden hinweise!

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

Wenter (p.wenter@wentersystem.de)
Datum: Do 06 Sep 2007 09:02:20 CEST
Betreff: Typetool
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.



3


Name: Karl Macku (karl.macku@debugprofi.at)
Datum: Do 14 Jun 2007 22:50:20 CEST
Betreff: 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 ?


Herzlichen Dank für alle weiterführenden Hinweise!



Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

.wenter (p.wenter@wentersytem.de)
Datum: Mo 18 Jun 2007 17:52:40 CEST
Betreff: 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 übertragen werden, dieser ist jedoch nicht eindeutig festgelegt. Aus den Anmerkungen ließe sich folgern: Wert 0 = Anlage AUS, Wert 254 = grün, was ist hier bei anderen Signalisierungen einzusetzen?

ODG: Bei Anmeldungen haben die Elemente GNA und GNE immer den Wert 0!

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 ?

ODG: Bei Anmeldungen haben die Elemente GNA und GNE immer den Wert 0!

c) Anmerkungen Seite 56 Zeile 2 Definition "festgelegte Rotzeit"; Ist diese Zeit projektspezifisch / signalplanspezifisch /signalgruppenspezifisch anzusehen ?

ODG: „Festgelegte Rotzeit“ ist ein Parameter der VA (Parameter Modifikation nach GNE)

Wie ist eine Abmeldung einzutragen, welche in der Zeit zwischen GNE und Ablauf der gegebenen Sperrzeit empfangen wird ?

ODG: 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) Zeile 4 - Ist die Zeitangabe 15 Sekunden eine Fixzeit / projektspezifisch /signalgruppenspezifisch festzulegen ?

ODG: Die Zeitangabe ist im Regelfall eine Fixzeit von 15 Sekunden, nur in Einzelfällen ist sie versorgbar.



2


Name: Hanfried Albrecht (H.Albrecht@AlbrechtConsult.com)
Datum: Mi 29 Jun 2005 14:51:55 CEST
Betreff: OCIT - Zentraler Systemzugang
Frage an die ODG:

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 ?

Antworten auf diesen Eintrag | Zeige Antworten auf diesen Eintrag (1)

 

ODG (infoodg@onlinehome.de)
Datum: Fr 01 Jul 2005 09:45:59 CEST
Betreff: OCIT - Zentraler Systemzugang
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.

 



1


Name: Bespiel (p.wenter@wentersystem.de)
Datum: So 12 Jun 2005 11:50:42 CEST
Betreff: 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 nur
die 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 ?

 

wenter (p.wenter@wentersystem.de)
Datum: So 12 Jun 2005 11:52:31 CEST
Betreff: OCIT-O Meldearchiv
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.



nach oben