{4} Requirements without Children (395 matches)

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.

Das Gerät muss mindestens einen von anderen Digitalausgängen unabhängige zweipoligen Warnausgang aufweisen, die nach Kundenwunsch durch die Kabelverschraubung nach Außen geführt werden kann.

Die Warnausgang soll zur Ausgabe von dem Warnstatus verwendet werden. Die Polarität soll auswählbar sein, d.h. "normally closed" oder "normally open".

Die empfangene Signale müssen verstärkt werden, damit sie in Digitalsignale umgewandelt werden können.

Dafür soll das AFE eine Verstärkerkette mit einstellbarem Verstärkungsfaktor aufweisen.

Die Regelung von der Verstärkung soll in Software passieren.

Die Kommunikation über Wi-Fi muss über WPA3 verschlüsselt werden können.

Weitere Verschlüsselungen wie WEP oder WPA/WPA2 dürfen auch zur Verfügung stehen.

Bei der Auslieferung eines Zählers bzw. Inbetriebnahme von der Wi-Fi-Schnittstelle muss WPA3 aktiv mit einem nicht-generischen Password eingestellt sein. Dies damit ein versehentliches Einschalten des Wi-Fis nicht zu einem ungeschütztem Zustand des Geräts führt.

Die Analogschnittstellen müssen galvanisch getrennt sein.

Die Akkus sollen von dem Gerät wieder aufgeladen werden können.

Das Gerät soll den Ladezustand bestimmen und anzeigen können. Bei dem Aufladen muss das Gerät den Ladestrom abhängig von Akkumulatorparametern begrenzen können.

RSM600 soll ein Terminal (Display und Tastatur) 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 der Tastatur soll die angezeigte Größe ausgewählt werden können.

Es soll möglich sein, das Terminal mit einem Kabel mit 6 Adern (bis mindestens 0,5 mm²) und Schirmung anzuschließen.

Wie soll das Gerät zeigen, dass es sich im Akkubetrieb befindet?

RSM600 soll als Standard mit folgenden Flanschformen verfügbar sein:

Nach ASME B 16.5:

• ANSI150RF/RTJ
• ANSI300RF/RTJ
• ANSI600RF/RTJ
• ANSI900RF/RTJ

Nach DIN EN 1092-1:

• PN10 Typ 11, Oberflächengüte B1
• PN16 Typ 11, Oberflächengüte B1
• PN25 Typ 11, Oberflächengüte B1
• PN40 Typ 11, Oberflächengüte B1
• PN64 Typ 11, Oberflächengüte B2

Es soll möglich sein die Sensoren mit Hilfe des für GT400 bereits entwickelten Werkzeug auszutauschen während die Anlage unter Druck steht.

Dies soll bis mindestens maximal 105 bar möglich sein.

Neue Bauteile dürfen außer bereits gesetzlich verbotenen Substanzen auch keine der folgenden Schadstoffe enthalten:

• Per- und polyfluorierte Alkylverbindungen (PFAS)

Das Kabel für Spannungsversorgung muss mindesten 3 Adern (Positiv, Negativ und PE) mit Aderquerschnitt von 0,75 mm² von bis mindestens 2,5 mm² haben können.

Für die Trockenkalibrierung muss die Temperatur bei Raumtemperatur mit kleiner Fehler als 0.58 K bestimmt werden können. Dies beinhält alle Fehler inklusive Fehler vom Sensor und Messungenauigkeit der HW-Schnittstelle.

Herleitung: Vor allem für Trockenkalibrierung ist die hohe Genauigkeit notwendig. Schallgeschwindigkeit soll mit einer Genauigkeit von 0,1 % bestimmt werden.

Störung (laut AGA8) bei Temperatur T = 293,15 K Stickstoff, 1 bar : dSoS/dT = 0,6 m/s/K. Maximalfehler Schallgeschwindigkeit dSoS_max < 0,001 * 349,102 = 0,3491. 0,3491 / 0,6 = 0,5816

Das Messfenster (zeitlich) muss immer so gewählt sein, dass gewährleistet ist, dass der Signalbeginn in einem einstellbaren Bereich (2 Parameter) der Messung liegt. Eine Reglung soll in einstellbarer Schrittweite erfolgen.

Das Gehäuse soll gegen Schädlinge geschützt sein.

Für Kommunikation soll ein Kabel mit mindestens 8 Adern und mindestens 0,75 mm² Aderquerschnitt durch die M20 KV Option Vergussverschraubung ausgeführt werden können.

Dadurch können zwei (2) Kommunikationskanäle (Ethernet, RS485, Ethernet-APL oder VDSL) ausführt werden. Da zwei Vergussverschraubung (eine als Standard und eine optional) zur Verfügung stehen ist dadurch der vollständige Mindestumfang der Kommunikation erfüllt.

Für den Temperaturaufnehmen PT100 sollen 4-adrige Kabeln mit Aderquerschnitt von bis mindesten 0,75 mm² verwendet werden können.

Die Anschlüsse von Digitalausgänge (Frequenz, Richtung, Encoder, Alarm oder Warnung) soll mit Aderquerschnitt bis mindestens 0,75 mm² möglich sein.

Es soll möglich sein, die Ansicht mit bis zu 10 Werten / Daten selbst zu konfigurieren als eine Art Favoritenübersicht.

Der Messalgorithmus soll mindestens ein Vergleichswert für Signalqualität umsetzten (zum Beispiel SNR, Signalamplitude, etc.) damit entschieden werten kann ob ein Signal auswertbar ist.

Die Signalqualitätswerte sollen für

• Regelung der Messzustandsmaschine verwendet werden können
• Verwerfen von nicht auswertbaren Signalen
• Berechnen der Akzeptanzrate

verwendet werden.

Die Grenzwerte sollen parametrierbar sein.

Es muss möglich sein, selber mehrere Modbus Userlisten über mindestens 100 Werte zu erstellen.

Unterschiedliche Schnittstellen für Modbus Server (COM1, COM2, Eth1, Eth2, Wi-Fi, etc) sollen gleichzeitig unterschiedliche Userlisten verwenden können (mind. 1 pro Schnittstelle). Zum Beispiel soll es möglich sein Instanz-F auf COM1 und Eth1 zu verwenden und gleichzeitig eine selbst erstellte Userliste auf Eth2. Es ist nicht notwendig, dass mehrere Userlisten auf eine Schnittstelle gleichzeitig verwendet werden können. Zum Beispiel könnte die aktive Userliste für eine Schnittstelle aus einem Dropdownmenü über alle angelegte Userlisten ausgewählt werden.

Die Userlisten sollen, für jeden in der Liste spezifizierten Koordinatewert (typischerweise Anzeigewert), eine Modbusadresse zuordnen.

Anwendungsfall ist für Kundenspezifische Geräte die über voreingestellten Modbusadressen Daten auslesen.

Beispiel:
Kundengerät holt Durchfluss immer über Modbusadresse 1234 und Schallgeschwindigkeit immer über Modbusadresse 5678. Die Userliste muss damit die Verknüpfungen

• 'Koordinate für Durchfluss' : Adresse 1234
• 'Koordinate für Schallgeschwindigkeit' : Adresse 5678

beinhalten.

Siehe auch das Plattformprojekt.

Die Differenzlaufzeiten sollen für jeden Pfad kalibriert werden, indem verlangt wird, dass das Gerät bei 0-Durchfluss eine Gasgeschwindigkeit von 0 misst.

Auf Basis der Maximalamplitude im gemessenen Rohsignal soll nach jeder Messungen die Verstärkung der Verstärkerschaltung für jeden Messvorgang individuell (up- und downstream für jeden Messpfad) so angepasst werden, dass die erwartete Signalamplitude in einer gut zu analysierenden Größenordnung liegt. Die Regelung soll über eine fixe Stepsize (Parameter) realisiert werden, um ein Übersteuern zu vermeiden. Es soll ein einstellbares Toleranzband (2 Parameter) in der Signalamplitude umgesetzt werden, um ein Toggeln zwischen Einstellungen zu vermeiden.

Das Gerät soll ein SW-Modul zur Berechnung von der Akzeptanzrate umsetzen.

Die Akzeptanzrate soll aus dem aktuellen Zustandswert der Messung (0 oder 1; ungültig oder gültig) und vorangegangenen Zustandswerten berechnet werden. Sie soll eine Aussage über das Verhältnis (0 % bis 100 %) zwischen ungültigen und gültigen Messungen (0 und 1) eines Ensembles darstellen. Die Tiefe der Akzeptanzrate soll einstellbar sein (1 Parameter).

Eine Akzeptanzrate von 100 % soll bedeuten, dass alle Werte des Ensembles gültig sind.

Das Modul soll mehrere Instanzen aufweisen, damit separate Akzeptanzraten für Einzelpfaden sowie für das Gesamtsystem mit dem gleichen Algorithmus berechnet werden können.

Das Akzeptanzratenmodul darf keine Bewertung von Signale o. ä. beinhalten, sondern erhält nur die Gültigkeitsinformation der aktuellen Messung. Eine Bewertung der Signale muss außerhalb dieses Moduls geschehen.

Fällt ein Pfad aus, soll er aus anderen Pfaden rekonstruiert werden können. Grundlage hierfür sollen die Pfadverhältnisse nach IS0 17089, 7.4.1.3 sein. Die Pfadverhältnisse sollen in Geschwindigkeitsintervallen hinterlegt werden um eine Sensitivität auf mit der Geschwindigkeit variierende Anströmbedingungen und damit veränderte Pfadverhältnisse zu gewährleisten.

Sobald ein Pfad ausfällt, soll das Gerät in Störmenge zählen. Fallen mehr als zwei Pfade aus, ist die Gesamtmessung ungültig.

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.

Das Gerät soll in Batteriebetrieb mit voller Funtionalität weiterarbeiten können.

Es soll aber möglich sein, gewisse Funktionen in Batteriebetrieb automatisch auszuschalten, wie zum Beispiel Netzwerk oder Wi-Fi.

Bei Wegfall der externen Spannungsversorgung soll das Gerät automatisch die Umstellung vornehmen um die Funktionalität einzuschränken. Bei Widerherstellung der Spannungsversorgung soll das Gerät automatisch zurück zur vollen Funktionalität übergehen.

Diese Funktion soll Batterielaufzeit verlängern können, in dem Funktionalität angepasst wird.

Must Have: Es soll möglich sein alle Parameter für Signalbearbeitung (Grenzfrequenzen, Filtertiefe, etc.) und Signalregelung (Signalnachführung, AGC-Einstellungen, etc.) für jeden Pfad bzw. Signalweg separat einzustellen.

Useful: In der Bedienoberfläche soll es zusätzlich möglich sein, jeden Parameter für alle Pfade mit einer einzelnen Eingabe einzustellen (zum Beispiel durch das Setzten eines Häkchens).

Es soll möglich sein, einen zweiten (oder mehrere) Durchflusswert berechnen zu lassen. Die Durchflusswerte sollen mit unterschiedlichen Parametereinstellungen berechnet werden, damit die Antwortzeit vs. Genauigkeit angepasst werden kann.

Die Berechnungen sollen parallel verlaufen und die unterschedlichen Durchflusswerte sollen alle als Quelle für Stromausgang, HF-Ausgang, etc. verwendet werden können.

Diese Funktionalität soll ermöglichen, dass das Gerät gleichzeit als Zähler (mit hoher Präzision und längerer Antwortzeit) und Regelgerät (kürzere Antwortzeit).

Die Kommunikation über Modbus TCP über die Ethernetschnittstellen und Wi-Fi soll analog zu Modbus über serielle Schnittstellen funktionieren (siehe Anf. 365). Unabhängig von einander sollen die Netzwerkschnittstellen für Modbus TCP Server und Modbus TCP Client verwendet werden können.

• 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 ist nicht notwendig, dass mehr als eine Modbusliste auf eine Netzwerkschittstelle als Server gleichzeitg verfügbar ist (auf unterschiedlichen Ports).

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 Datenquelle für den Encoderausgang auszuwählen.

Zumindest müssen Betriebsvolumen und Normvolumen auswählbar 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.

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.

Bevor die Laufzeitanalyse eines Signals durchgeführt wird, soll dieses auf charakteristische Merkmale überprüft werden, welche zur Beurteilung der Eignung des Signals verwendet werden. Betrachtet wird das Signal nach dem Filtervorgang. Typische Größen sind bspw.: globales Maximum, Nullstellen, Extrempunkte, SNR

Es sollen folgende Ebenengeschwindigkeiten berechnet werden:

Axiale Geschwindigkeit Je Ebene (1-4) berechnet sich die Geschwindigkeit

Querströmungsgeschwindigkeit Zunächst muss der Ebenenwinkel der Ebenen (1-4) bestimmt werden. Damit wird die Geschwindigkeit bestimmt Wichtig: In der SW muss der Ebenenwinkel zunächst von Grad zu Bogenmaß umgerechnet werden: y_rad = y_deg * PI/180

Referenzen vk_i: Korrigierte Pfadgeschwindigkeit des Pfads 'i' (m/s) alpha_i: Pfadwinkel des Pfads 'i' in Degree v_aj: Axiale Geschwindigkeit der Ebene 'j' y_j: Ebenenwinkel der Ebene 'j' v_qj: Querströmungsgeschwindigkeit der Ebene 'j'

Zur Ebene 1 gehört der Pfad 1 und 2, zur Ebene 2 der Pfad 3 und 4 usw.

Für den Test des RSM600 stehen diese Aufgaben an: Unter Beachtung des Testkonzepts ​Testkonzept Plattform

Ausfüllen der Testumgebung-Beschreibung

​Testumgebung RSM600 In Zusammenhang mit den folgenden Punkten U.a. Definition der einzelnen Testziele:

• wie können die Anforderungen geprüft werden
• wie können welche Schnittstellen getestet werden

Zusammentragen der Spezifikation der HW-Schnittstellen

Welche elektrischen und logischen Bereiche sind relevant

Finden und definieren Test-Hardware unter Berücksichtigung der Spezifikation zuvor

Die Test-Hardware muss programmatisch ansteuerbar sein (optimalerweise über Ethernet) Sofern möglich sollte sie so viele Schnittstellen abdecken wie möglich um die Anzahl an Geräten klein zu halten

Test-Hardware aufbauen und mit dem RSM600 testen

Aufbau genau dokumentieren (so das es jederzeit nachgebaut werden kann)

Aufsetzen der SW-Testframeworks

Dokumentation des Aufbaus und der Benutzung Dazu gehört neben einem möglichen Python Framework auch statische Codeanalyse, Metriken Erfassung und Performanz-Auswertung

GoCD Test Pipeline(s) aufsetzen, u.a.

• Statische Codeanalyse und Modultests Messcontroller
• Statische Codeanalyse und Modultests Linuxcontroller
• Integrationstests Linuxcontroller
• Systemtest Gesamtprodukt

Aufsetzen einer Testüberblick Infrastruktur

Beispielsweise "Allure Report" ​Link, alle Ergebnisse aus den Pipeline Durchläufen sollen hier zentralisiert gemeldet werden

Absprache mit der Produktion hinsichtlich EOL Tests

Welche Tests können dort wiederverwendet werden, was ist für den EOL Test notwendig Im Optimalfall besteht ein funktionaler EOL-Test vollständig aus einem Subset unserer Tests.