{27} Requirements affecting FW Linuxcontroller (mit Beschreibung) (58 matches)

Es sollte in der Übersicht eine Visualisierung vorhanden sein um alle angeschlossenen Kabel zu sehen.

Die Visualisierung soll alle vorhandene physische Schnittstellen (zum Beispiel durch Optionskarten) anzeigen sowie Status der Kommunikation an der Schnittstelle. Darstellung von passiven Kabeln (i.e. Kabeln über denen keine Kommunikation stattfindet) ist nicht notwendig.

z.B. Grün --> Modul vorhanden und verkabelt (Kommunikation vorhanden) Gelb --> Modul vorhanden nicht verkabelt (keine Kommunikation) Rot --> Modul nicht vorhanden (evtl. interessant bei den Optionen)

Eine freie Programmierung von bis zu mindestens 10 Funktionen soll möglich sein. Die Programmierung soll als Textstring zumindest darstellbar sein. Zum Beispiel könnte

({xxxx} + {yyyy})/2

die Mittelwert aus den Werten an den Adressen xxxx und yyyy entsprechen oder

{xxxx} > 0.9 {yyyy}

ein Binärwert 1 wenn der Wert an der Adresse xxxx grösser als 90 % des Werts der Adresse {yyyy} ist, und 0 sonst.

Die berechnete Werte sollen über Modbus aufrufbar sein (durch Erstellung eigenes Superblocks). Binärwerte sollen zusätzlich an einem DO ausgeführt werden können.

Zum Beispiel errechnete theoretische Schallgeschwindigkeit und eine definierte Schallgeschw. als Vergleich.

Es soll möglich sein die Trockenkalibrierung über die WebUI zu steuern.

Dabei soll die Quelle für Schallgeschwindigkeit einstellbar sein; aus AGA10 oder Vorgabewert. Siehe auch Dokument zu WebUI und RSM200.

Statistische Daten zu gemessener Schallgeschwindigkeit und Gasgeschwindigkeit sollen vor dem Kalibrierung gesammelt werden, und nachdem die Kalibrierung ausgeführt wurde.

Aus den statistischen Daten und Daten über Gasbeschaffenheit sollen einen Trockenkalibrierschein als PDF über das WebUI bereitgestellt werden. Siehe auch RSM200.

Über das WebUI soll es möglich sein

• einen Parameter Report
• einen Prüfschein

zu erstellen und als PDF runterladen. Der Parameter Report ist eine vollständige Auflistung aller Parameter des RSM600. Der Prüfschein beinhält nur die Eichamtliche Parameter (vgl. Datenbuch bei Umwertern). Siehe auch GT400 und RMS200.

Folgende Kommunikationsmöglichkeiten über Netzwerk (Ethernet, DSL, Wi-Fi) sollen unterstützt werden:

Erstes Release:

• Kommunikation mit einem geräteinternen Webbserver über http oder https
• Kommunikation zwischen Modbus Clients und RSM600 über Modbus TCP
• Kommunikation mit einem Zeitserver über SNTP
• Kommunikation mit Modbus Servers wobei RSM600 als Modbus Client fungiert
• Anfrage und Empfang von einem IP-Adresse über DHCP

Spätere Releases

• Kommunikation zwischen OPC Clients und RSM600
• Versand von E-Mails über MTP / SMTP (für Cry-Out)

Es soll durch Konfiguration möglich sein, Kommunikationsservices ein- oder auszuschalten. Dies soll für jede Netzwerkschnittstelle unabhängig möglich sein. Zum Beispiel soll das möglich sein Modbus nur auf Eth 1 zu erlauben, und http auf Eth 1 und Eth 2.

Funktionalität soll zum grossen Teil vom Plattformprojekt übernommen werden. Allerdings soll es für Modbus Server möglich sein unterschiedliche Modbudadresslisten gleichzeitig für unterschiedliche Schnittstellen zu verwenden.

RSM600 soll als Option WLAN über Wi-Fi anbieten.

Wi-Fi soll grundsätzlich den gleichen Funktionsumfang wie Ethernet anbieten, d.h. Modbus TCP und Aufruf von dem geräteinternen Webbserver soll möglich sein.

Siehe auch Tasks zu Hardware (277).

Das RSM600 Wi-Fi Modul soll als Access Point fungieren können. Das SSID soll als öffentlich oder versteckt auswählbar sein.

Das RSM600 Wi-Fi Modul soll sich auch an einem vorhandenen AP anschließen können.

Bei der Auslieferung soll kein AP einstellt sein.

Die Kommunikationsschnittstellen von RSM600 sollen möglichst unabhängig von einander konfigurierbar sein, damit Flexibilität gewährleistet ist. Folgende Fälle sollen auf jeden Fall realisierbar sein

Standardfälle:

• Eth1 : Industrie PC (Bedienung und Visualisierung)
• COM1 : Flow Computer (Instanz-F)

• Eth1 : Industrie PC (Bedienung und Visualisierung)
• HF : Flow Computer (Pulse / Frequenz)

• Eth1 : Industrie PC (Bedienung und Visualisierung)
• HF : Flow Computer 1 (Pulse / Frequenz)
• COM1 : Flow Computer 2 (Instanz-F)

• Eth1 : Industrie PC (Bedienung und Visualisierung)
• COM1 : Flow Computer 1 (Instanz-F)
• COM2 : Flow Computer 2 (Instanz-F)

Applikation 1:

• Eth1 : Switch : PC1, PC2 ... PC x (Bedienung und Visualisierung), Flow Computer y (Instanz-F über Modbus TCP)
• HF : Flow Computer 1 (Pulse / Frequenz)
• COM1 : Flow Computer 2 (Instanz-F)
• COM2 : PGC (Modbus Client)

Applikation 2:

• Eth1 : Kunde 1 (Bedienung und Visualisierung)
• Eth2 : Kunde 2 (Bedienung und Visualisierung)
• Wi-Fi : Kunde x (Bedienung und Visualisierung Nicht Release 1)
• HF : Flow Computer 1 (Pulse / Frequenz)
• COM1 : Flow Computer 2 (Instanz-F)
• COM2 : PGC (Modbus Client)

• Eth1 : Kunde 1 (Bedienung und Visualisierung)
• Eth2 : PGC (Modbus TCP Client mit entsprechender Modbusliste)
• Wi-Fi : Kunde x (Bedienung und Visualisierung Nicht Release 1)
• HF : Flow Computer 1 (Pulse / Frequenz)
• COM1 : Flow Computer 2 (Instanz-F)
• COM2 : Flow Computer 3 (DZU Nicht Release 1)

RSM600 soll ein Display und Keypad aufweisen.

Das Display muss zumindest grundlegende Daten wie Zählerstand und aktuellen Durchfluss anzeigen können. Weitere Anzeigewerte dürfen auch verfügbar sein und werden in Unteranforderungen spezifiziert.

Mit dem Keypad soll die angezeigte Größe ausgewählt werden können.

Der Funktionsumfang von Display und Keypad werden in Unteranforderungen näher spezifiziert.

Das soll eine Funktion "Cry-out" unterstützen. Darüber soll wichtige Nachrichten sowie Alarm oder Warnung nach Wunsch über E-Mail oder Mobilfunk ausgeschickt werden können.

Die exakte Funktionalität, mit welcher Technologie diese Funktion umgesetzt werden soll und unter welchen Bedingungen dies gesehen kann, werden in Systemanforderungen spezifiziert.

Das Gerät muss eine Echtzeituhr (RTC) aufweisen.

Das RTC muss eine eigene Backupbatterie oder Akkumulator haben.

Das RTC soll über via SNTP über Ethernet synchronisiert werden können. Das RTC soll auch über Modbus eingestellt werden können.

Die Echtzeituhr soll weniger als 1 s / 24 h Drift haben.

Siehe auch das Plattformprojekt.

Das Gerät muss erkennen wenn das Displaygehäuse vom übrigen System elektrisch getrennt wird, und dies entsprechend als Ereignis archivieren.

Dies soll verhindern, dass der Eichschalter gedruckt (oder durch Kurzschluss der Signalleitungen das Drucken des Eichschalters imitiert wird) werden kann ohne dass die Plombierung gebrochen wird.

Weiterhin muss verhindert werden, dass das Terminalgehäuse ausgetauscht werden kann, ohne dass dies erkennt und geloggt wird. Damit kann auch nicht die Plombierung des Eichschalters durch Tausch von Terminalgehäuse umgegangen werden.

Die Loggeinträge sollen einen Zeitstempel beinhalten. Aus dem Zeitstempel soll die Zeitpunkt des Eintrags mindestens sekundengenau festgestellt werden.

Das schreiben von Parametern soll geloggt werden. Es soll auch mitgeloggt werden, welcher Anwender den Parameter geschrieben hat. Der neuer Wert soll ebenfalls geloggt werden.

Das Parameterarchiv soll dafür in eichamtlich und nicht-eichamtlich aufgeteilt sein. Das eichamtliche Archiv soll nur mit offenem Eichschalter löschbar sein.

Das Gerät soll entsprechend ISO 17089 Teil 1, Kapitel 7.4 die eigene Funktionalität durch Berechnung von Diagnose Daten aus den gemessenen Ultraschalllaufzeiten überwachen.

Das Gerät soll einen Vergleichsreport (Fingerprint) nach ISO 17089 erstellen können. Das Report soll über die WebUI zumindest als PDF zum Download bereitgestellt werden.

Dies entspricht zum grossen Teil dem Maintainance Report bei RSM200 oder dem Inspection Report bei GT400.

Die aufzuzeichnende Grössen werden in ISO 17089:2019 5.5.5 und 8.9 beschrieben. Für statistische Grössen (Mittelwert und Standardabweichung) soll eine Dauer für Datensammlung angegeben werden können um ein statistisches Ensemble zu definieren.

Weiterhin sollen manche Werte mit Referenzwerten verglichen werden (siehe vor allem 8.9). Die Referenzwerte werden bei der Inbetriebnahme angelegt in dem die Funktion Fingerprint erstmal ausgeführt wird. Zweck ist Abweichungen oder Drift zu erkennen.

Siehe auch GT400 (Inspection Report) und RSM200 (Maintainance Report)

Das Gerät soll den Zustand der Akkumulatoren anzeigen können.

Unter anderem sollen:

• aktuelle Ladung als Anteil der maximalen Ladung
• ob zurzeit aufgeladen wird oder nicht
• erwartete mögliche Betriebszeit mit aktueller Ladung

angezeigt werden können.

Der Stromausgang soll durch Auswahl als einer der folgenden Modi parametriert werden können:

• Aus
• Absolutbetrag des Durchfluss
• Durchfluss mit Vorzeichen (siehe auch Anf. 87).

Die Parametrierung von Messeinheiten soll aus dem Plattformprojekt (RFC 7) übernommen werden.

Da der Messcontroller alle Berechnung in metrischen Einheiten ausführt und übergibt soll die Umwandlung zwischen metrischen Einheiten und parametrierten Einheiten im Linuxcontroller stattfinden.

Die serielle Schnittstellen COM1 und COM2 sollen von einander unabhängig als Modbus Server, Modbus Client oder DZU (nicht Release 1) verwendet werden können.

• (nicht Release 1) Als DZU sollen Daten an einem Flow Computer ausgegeben werden können. Siehe RMG-internes Dokument DZU_20140204.pdf für Spezifikation.

• Als Modbus Server sollen Daten über Instanz-F, beispielsweise an einem Flow Computer, ausgegeben werden können. Siehe ISO 17089, Anhang F für Spezifikation.

• Als Modbus Client sollen Daten für die AGA10-Berechnung von einem PGC geholt werden können. Dafür sollen zumindest Modbuslisten für die RGC7 und PGC9300 als Standard auswählbar sein. Siehe Dokumentation zu den jeweiligen Produkten für Modbusadressen.

Zusätzlich soll es die Möglichkeit geben, eigene Modbus Userlisten anzulegen um kundenspezifische Anwendungen zu unterstützen. Es soll möglich sein unterschiedliche Modbuslisten auf unterschiedliche Schnittstellen gleichzeitig zu verwenden. Zum Beispiel wäre es damit möglich Fremdgeräte als Quelle für Gaszusammensetzung zu verwenden.

Es soll auch möglich sein, Modbus Userlisten zu importieren, statt in der Bedienoberfläche händisch anzulegen.

Die Funktionalität von Logging (Fehler, Warnungen, Parameterschreiben, etc.) soll von dem Plattformprojekt übernommen werden.

Neben dem physischen Eichschalter soll auch ein virtueller Eichschalter in Software umgestetzt werden. Die Verfügbarkeit des Softwareschalters soll von dem physischen Eichschalter geschutzt sein. Wenn aktiv, sind Softwareschalter und physischer Eichschalter äquivalent bezüglich Rechteerteilung.

Die Umsetztung soll von dem Plattformprojekt übernommen werden.

Es soll möglich sein, eine Aufzeichnung von ausgewählten Werten zu speichern. Dies unterscheidet sich von Archive in dem keine Mittelwerte gebildet und gespeichert werden.

Die Aufzeichnung soll mit auswählbarem Startpunkt und Stoppunkt ausgeführt und über die Webboberfläche auf einem Rechner gespeichert werden können. Die Maximaldauer kann von Hardware/Speicher/sonstige Bedingungen begrenzt sein.

Die Aufzeichnung soll mit einem externen Tool wieder aufgespielt und als Demonstration für zum Beispiel Kunden verwendet werden können.

Der Linuxcontroller soll die vier (4) Zählwerke (Betriebsvolumen (vorwärts und rückwärts) und Störvolumen (vorwärts und rückwärts)) umsetzten und verwalten.

Die Umsetztung soll aus dem Plattformprojekt übernommen werden.

Das Gerät soll zwei Betriebsarten aufweisen:

• 1) MID: Die maximale Zeit, nach der die Eichschreibrechte automatisch zurückgezogen werden, ist auf 30 min begrenzt. Eine kürzere Zeit soll auch durch Parametrierung möglich sein.

• 2) non-MID: Der Eichschalter/Eichtaster kann dauerhaft offen gelassen werden. Es soll immer noch möglich sein, eine Zeit einzustellen, nach der der Eichschalter automatisch geschlossen wird. Die Zeit soll aber nicht begrenzt sein.

Es soll möglich sein die Trockenkalibrierung über die Bedienoberfläche auszuführen. Dafür soll die entsprechende Funktion in der Messcontroller FW angesteuert werden.

Siehe auch Tasks zu Messcontroller FW (357, 358).

Das Messsystem wird vom Messcontroller umgesetzt. Der Ablauf ist von vielen Parametern abhängig. Die meisten Parameter brauchen keine spezielle Behandlung (aus Plattformperspektiv) sondern müssen einfach normal schreibbar und lesbar sein.

Normalbetrieb

Im Nomalbetrieb werden viele Grössen während des Messverfahrens bestimmt und an den Linuxcontroller übergeben. Einige davon fordern spezielle Aufmerksamkeit und/oder werden für weitere Berechnungen (im Linuxcontroller) benötigt:

Für Zählwerk relevant:

• Volumeninkrement mit zugehöriger Gültigkeit und Richtung (1x)

Für Hauptarmaturenbrett relevant:

• Schallgeschwindigkeit (1x)

• Korrigierter Durchfluss (1x)

Eingabe für die Diagnosendatenberechnung:

• Gasgeschwindigkeit (1x pro Pfad)

Daraus Ebenengeschwindigkeiten, Drallwinkel, Profilfaktoren, Symmetrieparameter, Turbulenz, siehe auch Anforderung dazu und ISO 17089-I:2019, 8.9.

Für Messtechnikbrett relevant, da Diagnose nach ISO 17089-I:2019, 8.9:

• SNR (2x pro Pfad)

• AGC (2x pro Pfad)

• Maximalamplitud (2x pro Pfad)

• Schallgeschwindigkeiten (pro Pfad)

• Signaldaten (je nach Auswahl)

Zu den Themen Hauptarmaturenbrett und Messtechnikarmaturenbrett, siehe auch Dokument ”Anwendungsfälle RSM600”

Simulationsbetrieb

Ähnlich zu Normalbetrieb mit der Ausnahme, dass die aus den Einzelpfaden berechnete, mittlere Gasgeschwindigkeit nicht aus Messungen stammt sondern aus einem Vorgabewert. Basierend hierauf wird daraus ein (korrigierter) Durchfluss

berechnet. Der Simulationsbetrieb wird vor allem bei der Inbetriebnahme verwendet um die Kommunikation zu prüfen.

Trockenkalibrierung

Die Trockenkalibrierung kann über einfaches Schreiben von Parametern stattfinden, allerdings soll auch eine spezialisierte Seite im WebUI angeboten werden. Auf der Seite soll die Quelle für Druck und Temperatur auswählbar sein und danach die Kalibrierung durch einen Klick gestartet werden können. Zusätzlich können weitere Parameter für die Kalibrierung eingestellt werden (Dauer und/oder Anzahl Messungen).

Aus technischer Perspektive wird nach dem Starten von der Kalibrierung erstmal die Schallgeschwindigkeit über AGA10 berechnet. Dies wird als Sollschallgeschwindigkeit (Vorgabewert) an den Messcontroller weitergereicht. Danach wird der Modus von ”Messung” auf ”Kalibrierung” über Parameter umgestellt. Der Messcontroller führt die Kalibrierung aus und geht automatisch zurück in ”Messung”. Die Standardabweichung (vom Messcontroller berechnet) wird ausgelesen und angezeigt.

Signaldaten auslesen

Im Messtechnikarmaturenbrett sollen Signaldaten als Plots angezeigt werden können. Dafür müssen erstmal die gewünschten Messpfade (-richtungen) auswählt werden und als Parameter an den Messcontroller übergeben werden (für einen Sechspfader bspw. 010000000000 um das Downstream-Signal von Pfad 0 anzufordern). Der Messcontroller zwischenspeichert danach das Signal (ein paar hunderte Werte, entsprechend der Sampleanzahl pro Signal) für die erste gewünschte Messung und sendet diese an den Linuxcontroller. Diese können dann sofort aufgezeichnet werden. Danach zwischenspeichert der Messcontroller die zweite gewünschte Grösse und zyklisch so weiter. Sind alle angeforderten Signale abgearbeitet, werden diese von vorne beginnend fortlaufend aktualisiert.

Fenster ”Duchflussprüfung Prüfstelle”

Fenster zur Bestimmung der Parameter zur Kennlinienkorrektur: Während der Durchflussprüfung muss die Kennlinienkorrektur ausgeschaltet werden, um auf Basis der (abgesehen von Reynoldskorrektur und Justage) unkorrigierten Fehlerkurve die Korrekturparameter zu bestimmen. Sonst soll die Messung normal laufen.

Das Gerät soll Fingerprints bei unterschiedlichen Betriebsbedingungen speichern damit sie als Vergleich für zukünftige Fingerprints verwendet werden können.

Grund ist, dass Fingerprints nur unter ähnlichen Betirebsbedingungen mit einander verglichen werden dürfen.

Die Kommunikation zwischen Displaycontroller und Linuxcontroller muss die Anforderungen in WELMEC-Leitfaden 7.4 erfüllen (T1 - T8).

Dort wird gefordert, dass übertragene Daten gegen Änderungen durch eine CRC32 Prüfsumme geschützt wird (T2, T3). Zusätzlich (T4) soll ein nicht öffentlicher Startwertwert verhindern, dass Daten gefälscht werden können.

Für die Kommunikation zwischen Displaycontroller / Linuxcontroller ist besonders wichtig, dass der Status des Eichschalters nicht durch ein gefälschtes Telegramm an das Haupgerät übertragen werden kann. Obwohl die exakte Umsetzung des Übertragungsprotokoll in den Tasks spezifiziert werden soll, wird empfohlen die folgende Komponenten in die CRC32 Prüfsumme aufzunehmen:

• Laufnummer vom Telegramm
• Identifikationsnummer vom Displaycontroller
• Identifikationsnummer vom Linuxcontroller

Eine Verschlüsselung (Verhindern Lesen von dritte) der übertragenen Daten wird nicht in den Richtlinien verlangt, darf aber umgesetzt werden.