Aut u om o at a isier e tes e T es e ten e n v on o n ver e tei e lten e n S y S stem e en e n ü b ü e b r e Pet e rine n t e ze

Transkript

1 Automatisiertes Testen von verteilten Systemen über Petrinetze Tim Ruß Kurzvorstellung ifak 2 1

2 Vorstellung ifak ifak: Institut für Automation und Kommunikation e.v., Magdeburg 50 Mitarbeiter plus Studenten und Gastwissenschaftler Zusammensetzung der Erträge aus F&E: 3 Geschäftsfelder des ifak IKT & Automation Echtzeitkommunikation, Geräte- und Systemtest Wasser & Energie Kläranlagen, Integrierte Planungswerkzeuge Messtechnik& Leistungselektronik Prozessmesstechnik, Kontaktlose Energie-und Datenübertragung Verkehr & Assistenz Intelligente Verkehrssysteme, Qualitätssicherung vernetzter Mobilitätssysteme, Elektromobilität 4 2

3 Einige Kommunikations-Domänen Kommunikation in der Automation Ethernet, PROFINET Prüflabor Feldbussysteme Kommunikation im Verkehr WLANp, Car2X Kooperative Applikationen 5 Motivation: Testen von Netzwerkkommunikation 6 3

4 Motivation: Industrieautomation mit -Protokoll Steuerungen (Controller) tauschen Daten mit Feldgeräten (s) aus Typische Testzeitpunkte: Bei Inbetriebnahme einer Anlage Nach Aufspielen neuer Stack-Versionen Typische Testziele: Erfolgreicher Verbindungsaufbau, ggf. zu mehreren s Robustheit gegenüber Störungen Controller 7 Motivation Wunsch: Manuelle Testabläufe automatisieren Bsp.: PROFINET-Verbindungsaufbau in Wireshark: 8 4

5 Lösung: Testsoftware Projekt: PROGES ( ) - Programmierbarer Fehlergenerator für Ethernet-basierte Automatisierungsnetze Anforderungen: Erfüllung von Sollverhalten nachweisen Gezielt Datenverkehr manipulieren Lösung: PC mit Testsoftware als Man-in-the-middledirekt hinter Steuerung Überwachung Manipulation Controller PC + Tool 9 Ansatz: Modellbasierter Test von sequentiellem Datenverkehr 10 5

6 Ansatz: Testen der beobachtbaren Reaktionen Allgemeines Test-Vorgehen: Vorgaben Testeingaben Testobjekt Reaktionen Vergleich Bewertung Beispiel Unit Test: Vorgaben 5 Eingaben Funktion Rückgaben Vergleich EQUALS 2, 3 a + b 5 Bewertung PASS 11 Ansatz: Testen der beobachtbaren Reaktionen Anwendung auf Netzwerk-Test: Betriebsvorgaben aus Protokoll-Stacks und Applikationen Auswahl über Testfälle Überführung in Modell Hochlauf und Bedienen von Geräten Netzwerk aus Geräten Sequenz aus Datenpaketen Autom. Vergleich Testreport 12 6

7 Ansatz: Testen der beobachtbaren Reaktionen Controller Nachricht A Nachricht B z 0 z 1 z 0 z 1... Modell: Sequentielles Sollverhalten auf Netzwerkebene Protokolle wie PROFINET über Automatenmodelle im Stack implementiert Sequentieller Datenverkehr beobachtbar Vollständiger Test allerautomaten aufgrund der Komplexität nicht möglich Alternative: Test ausgesuchten Datenverkehrs 13 Ansatz: Sollverhalten als Modelle Zustand in Sequenzdiagrammen nicht speicherbar Daher Überführung in gerichteten Graphen Netzwerk-Nachrichten ändern Zustand Endlicher Zustandsautomat(FSM): Nur 1 Zustand zur gleichen Zeit. Jedoch Modellieren paralleler Komm.- Beziehungen gefordert. Nachricht z 0 z 1 Bedingungs-Ereignis-Netz (einfachster Typ) Stellen-Transitions-Netz (Stellen mit erhöhter Kapazität) Petrinetz (Marken mit Attributen) Stelle Transition 14 7

8 Ansatz: Sollverhalten als Modelle Sender und Empfänger nicht explizit modellieren, da nur Sende- Ereignis erfassbar Vorstelle mit Marke Nachricht Top-Down-Entwurf Transition mit Nachrichten-Ereignis als Trigger Nachstelle Globaler Start Nachricht Sequenz Globales Ende = Testfall erfüllt Fragment 15 Manipulation des Datenverkehrs Weiteres Feature: Manipulation zur Fehlergenerierung Fehlerhafte Geräte nachstellen Protokoll-Stack prüfen (Reaktion bei Paketverlust etc.) Umsetzung: Action an Transition Weiterleiten Löschen (nicht weiterleiten) Ändern von Parametern Sollverhalten textuell Sollverhalten grafisch Verhalten im Netz 16 8

9 Markenspiel an einem Beispiel 17 Beispiel Markenspiel Controller Connect Request: erase loop (2) Ping: erase Globale Startstelle Connect Request erase Ping NoCall Connect Request Connect Response OK Loop: ja Loop: nein Loop wiederholen (i prüfen) Ping erase Loop: nein 18 Ping Globale Endstelle 9

10 Beispiel Markenspiel Controller Connect Request: erase loop (2) Ping: erase Globale Startstelle Connect Request erase Ping NoCall Connect Request Connect Response OK Loop: ja Loop: nein Loop wiederholen (i prüfen) Ping erase Loop: nein 19 Ping Globale Endstelle Fähigkeiten und Grenzen des Ansatzes 20 10

11 Fähigkeiten und Grenzen der Lösung Gutverhalten Passiv mitschneiden Punkt des Datenabgriffs frei wählbar (z. B. über TAP), hinter Steuerung am geeignetsten Negativverhalten Gezielte Manipulation Man-in-the-middle nötig Zusätzliche Jitter und Latenzen Nur ausgewählte Testfälle: Automatisierung bisher manueller Prozesse keine Abdeckung der gesamten Spezifikation Netzwerk-Tests ergänzend zu applikativen Tests 21 Automatisiertes Testen von verteilten Systemen über Petrinetze Bei Fragen einfach fragen! Grafiken: 11

12 Zusatz-Folien 23 Modellierung von Kommunikationspartnern? Sender: sendebereit Empfänger: empfangsbereit Vorbedingung m gesendet m m empfangen m gesendet Trigger: Netzwerknachricht Nachbedingung Problem: Beobachtbarkeit des Empfangsereignisses 24 12

13 Post-Event-Entscheidbarkeit Bisher: Entscheidbarkeit durch Netzwerkereignisse (z. B. Loop beenden, Alternative entscheiden etc.)? N. in Loop N. nach Loop Durch zusätzliche Stellen & Transitionen nicht mehr (einfach) möglich Idee: Mehrere, gleichzeitig aktive Markierungen Dann erzeugen, wenn zwei Transitionen feuern könnten Loop weiter Loop beendet M 1 = {0, 1, 0} M 2 = {0, 0, 1} Dann M 1 UND M 2 gegen Netzwerk-Nachrichten prüfen Eine M. gewinnt, sobald mit ihr weitere N.-Transition feuert 25 Überführung Sequenzen - Netze Anfangs: Transitionen modellieren ausschließlich Netzwerk-Nachrichten Dadurch minimale Zwischenstellen Dadurch Fragmente in Fragmenten nie klar getrennt (eines beeinflusst ggf. das andere) par Operand 1 Operand 2 Jetzt: Klare Abgrenzung: Zwischenstellen beginnen und beenden Fragmente par O1 O