F: AEPVektor

AEPVektor mag einen Hashwert ü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öße. Über die Auswahl einer geeigneten Hashfunktion sagt der Standard nichts aus, dies unterliegt dem Hersteller.

 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. AP-Werte 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 AP-Wert, z.B. 57.101 mit Indexrange 1-280

 

Variante 1: Ich würde die Input-Parameter der Methoden wie folgt verwenden:

AEAPWert.SetAP(), Beispiel Index 1

RefLen = 15 -> Länge der Referenzdefinition in Bytes, inkl. RefLen Member = 1, da USHORT OType = 506, da USHORT ApWertName = 57.101.1

AEAPWertVektor.SetAPListe(), Anhand Beispiel Index 1, 5 Prefix = 57.101.

Anzahl = 2

RefLen = 8 -> -> Länge der Referenzdefinition in Bytes, inkl. RefLen Member = 1 OType = 506 ApWertName = 1 -> Gesamtname des APWertes setzt sich aus Prefix + APWertName zusammen RefLen = 8 -> -> Länge der Referenzdefinition in Bytes, inkl. RefLen Member = 1 OType = 506 ApWertName = 5 -> Gesamtname des APWertes setzt sich aus Prefix + APWertName zusammen

 

Variante 2: Mein Kollege besteht aber auf folgender Darstellung AEAPWert.SetAP(), Beispiel Index 1 RefLen = 19 -> Länge der Referenzdefinition in Bytes, inkl. RefLen Member = 1 OType = 506 ApWertName = 57.506.101.1 -> seine Argumentation: entspricht dem Beispiel im Dok. OCIT-O_Lstg_V2.0_A01.pdf, S. 136, Kap. 4.5.4: 41.500 = Digitaler Input 500 entspricht dem OCIT-O-Type eines digitalen Eingangs. Wenn ich den im ApWertNamen verwende, dann muss ich hintendran noch die OITD Nr. und den Index anhängen, da ich sonst steuergeräteseitig nicht über alle Infos verfüge, um auf den Wert zuzugreifen. Bei der Variante 1 (ApWertName = 57.101.1) wäre die Argumentation so: ich brauche den OCIT-O-OType nicht im ApWertNamen, da die SetAP() Methode diese Information ohnehin schon mit sich führt.

Wie hat sich die ODG das gedacht?

A: die Variante 1 ist richtig, da in der Variante 2 ein Denkfehler steckt. Hier wird auf die Instations-Typdefinition verwiesen. 41.500 ist ein Typ aus Instations (PD-DM-LSA), nicht aus Outstations. Daher ist die Argumentation, die sich auf die Typbezeichnung des DigEingangs bezieht, hinfällig.

F: 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: 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: 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-Werte 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-Werte 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 eines AP-Wertes bestimmt die Gruppe in der sich der AP-Wert befindet. D.h. der AP-Wert „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-Werte 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 AP-Werte.

F: AP-Werte 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 AP-Wert „Det.Luecke.1“ existiert müssen auch die APWertGruppen „Det“ und „Det.Luecke“ existieren und werden somit beim InstanceInfo-Aufruf zurückgeliefert.

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: AP-Werte 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-Werte 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 AP-Werte-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: 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: Ein Hersteller vertritt den Standpunkt, dass bei Archiven, die nicht instanziert 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 Archive existieren nicht, Get liefert Err_Path_Val als Ergebnis. Bei nicht konfigurierten Archiven liefert Get das Ergebnis.

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: 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: Auftrag mit mehreren Auftragselementen

Werden bei einem Auftrag mit mehreren Auftragselementen in einem Auftragsframe immer alle Auftragselemente geschrieben, auch wenn sich nur ein Auftragselement ändert (weil die AE-Nr nicht im Auftragsframe enthalten ist sondern nur die Zustandsdaten)? Wenn dem so ist, fände ich das Schade, denn das würde aus meiner Sicht eine erhebliche Einschränkung bedeuten! Wozu gibt es dann die AESiplOnline und AEAPWertVektor, außer dass sich der VSR ein wenig Konfigurationsaufwand spart? 

A: Wie richtig vermutet werden immer die Daten von allen Auftragselementen eingetragen. Wenn die Zentrale nur die reinen Änderungen ins Archiv eingetragen haben möchte, muss Sie für jedes Element einen eigenen Auftrag anlegen. Es ist also keine Einschränkung, da man damit zum gleichen Ziel kommt. Die Auftragselemente AESiplOnline und AEAPWertVektor sind nur zur schnelleren bzw. einfacheren Konfiguration der Archive durch die Zentrale da.

F: 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: 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: 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: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 V2.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: Wie ist die Betriebsart zu setzen, wenn es unterschiedliche Befehlsquellen für die Schaltwünsche gibt?

A: Gemäß Schalttabelle (Lokal Zeitsteuerung und Zentrale). Übrige Betriebsarten Sonderbetrieb, Eigensteuerung, Handstoppbetrieb, Lokal Fix, gemäß Spezifikation.

 

F: 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 OCIT-O V2.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: 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: 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 betriebssystemabhä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: BTPPL-Telegrammgrößenbegrenzung
Seit Extensible mit 4 Byte Datenlänge, kann die Objekt- und Telegrammgröße den phys. FG-Speicher übersteigen. Wäre eine Festlegung auf eine max. BTPPL-Telegrammgröße möglich/sinnvoll?

A: Max. Größe der BTPPL-Telegramme ist 1 MByte. Die Geräteausstattung muss entsprechend sein. Bei zu großen Telegrammen wird der Fehlercode TOO_MANY zurückgegeben. Eine Verarbeitung von Telegrammen > 1 MByte ist ein Thema für OCIT-O Version 3.

 

F: 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: 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: 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

< DESCRIPTION>Keine Instanz zu angegebenem Pfad (Wert) gefunden

< VALUE>17

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: Was sind <Interface> und <Implements>?

A: <Interface> und <Implements> wurden bisher nicht verwendet, bleiben aber als Reserve in der Type Datei enthalten.

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: 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 die jeweilige 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: 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

< DESCRIPTION>Struktur der Auftragsframes für Aufträge vom Typ AESignalbild

< MEMBER>1

< OTYPE>296< DECL>< NAME>Signalbild

< DESCRIPTION>Aktuelles Signalbild

< REFERENCE>

< MEMBER>1

< NAME>SIGNALBILD

< /REFERENCE>

< /DECL>

< /STRUCTDOMAIN>

Und ich weiss ob es grün, rot, gelb, usw. für jedes SignalBild. Aber für AEBinar..:

 < STRUCTDOMAIN>

< NAME>AEBinaerFrame

< DESCRIPTION>Struktur der Auftragsframes für Aufträge vom Typ AEBinaer

< MEMBER>1< OTYPE>295

< /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: 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: 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: 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: 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: 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: Hauptmeldung / Nebenmeldung

Ich bitte um Erläuterung folgender Textpassage, zu finden bei den Meldungen

1:60006, Feindlichkeit

1:60007, Zwischenzeit

1:60008, Mindestgrünzeit

1:60009, Mindestrot

„Bei Verletzungen, die die Signalüberwachung erkennt, wird dieser Meldungsteil als Nebenmeldungsteil einer Sollbild-Störung gespeichert.“

Frage:

1) Ist als Vorspann dieser Meldungen die Hauptmeldung „Sollbild Störung“ noch relevant, oder dürfen diese Meldungen auch als Hauptmeldung verspeichert werden?

2) Wenn diese Meldungen als Nebenmeldung zu verwenden sind, wäre dann das Element VorgangsNummer nicht in der Nachrichtendefinition zu entfernen?

 

A: zu 1: Ja, diese Meldungen dürfen auch als Hauptmeldungsteil verwendet werden.

zu 2: Wenn die Verletzung nicht von der Sollbildüberwachung sondern schon vorher erkannt und korrigiert wird, wird die betreff. Meldung als Hauptmeldung mit VorgangsNummer verwendet.

F: 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: 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".

1. 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?
2. 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: 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: 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: Wieviel 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: AEAggregiert auf Programmumlauf bezogen

Wie könnte dies mit den bestehenden Objekten AEAggregiert und AuftragZykl gelöst werden?

 

A: Es sind verschiedene gerätespezifische Lösungen möglich, z. B. die Verwendung von AP-Variablen. Auch die Verwendung des Triggers ist möglich, allerdings gibt es dabei Einschränkungen z. B. bei Synchronisiervorgängen.

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

 

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: 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: 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

1. a) Einer Kette aller Meldungsteile 60200 bis inkl. 60205
2. b) einer Kette der Meldungsteile 60200 und 60206
3. 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: a) Objekt EvList - Methode 203 (Netz aus)

1. a) 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?
2. 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 Zentralenmischbetrieb (Profil 1 + Profil 2) ausschließlich für Profil 2 Outstations vorbehalten?

A: 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.

A: Frage b):

Eine Beispielfirma benutzt das Objekt OfflineEvent (LSA-seitig) nur im Profil 2. Wenn die Zentrale kein Profil 2 unterstützt, wird dieses Objekt auch nicht verwendet. Bei der Zentrale die gleichzeitig das Profil 1 und 2 unterstützt, wird dieses Objekt nur für die Anlagen mit dem Profil 2 verwendet. Die Methoden dieses Objekts haben das Ziel, eine Neukonfiguration der Liste 36 (mit der Meldungen, die zur Callback-Anforderung führen) anzufordern. Beim Profil 2 kann im Gegensatz zum Profil 1 die LSA, wenn die Stromversorgung wiederkehrt, die Verbindung mit der Zentrale initialisieren (Callback-Anforderung) und danach das Event OnNetzEin senden.

F: 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: 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: 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: Ist der OCIT-Zenrale Systemzugang unabhängig von der OCIT-Outstations Version

Im Rahmen der Diskussion der Kompatibilität der OCIT-Versionen ist die Frage enstanden, ob ein zentralenunabhängiges OCIT-Versorgungsgateway, wie es im Zuge der Disksussion der OCIT-Instations VD (2.0) spezifiert wird, mit Steuergeräten mit OCIT-Outstations Version 2 über den Zentralen Systemzugang einer Zentrale, die mit einer OCIT-Outstations-Schnittstelle in der Version 1.1 geleifert und ausgerüstet wurde, zusammenarbeiten kann? Mit anderen Worten, ist der OCIT-Zenrale Systemzugang unabhängig von der OCIT-Outstations Version?

A: Verbindungstechnisch ist der zentrale Systemzugang in V2.x genauso wie in V1.x eine geroutete TCP/IP Verbindung mit Standard-Interface. In Version 1 fehlt jedoch die nach Benutzergruppen "Anwender" und "Hersteller" getrennte Zugangsberechtigung, wie sie in V2.x vorgesehen ist. Der zentrale Systemzugang muss daher für V2.x mit dieser Funktion nachgerüstet werden. Dann funktioniert er mit V1.x und V2.x.

F: 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. 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: 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: 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: 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. Für WinNT ist die Abhaengigkeit zu gnome-xml aufgeloest, für linux Systeme scheinbar nicht. Gibt es eine version vom typetool bei der ein build unter linux problemlos geht? Das Makefile für 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 für 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: 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: 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.

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: 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: 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: Ä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: 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.