Jochen Kühner
Level-3
- Beiträge
- 4.291
- Reaktionspunkte
- 527
-> Hier kostenlos registrieren
Hat sich jemandschon mal mit automatisierten Tests für Bausteine in Tia Portal beschäftigt?
TIA Unittesting mit TIA
- Ersteller Jochen Kühner
- Erstellt am
-> Hier kostenlos registrieren
LowLevelMahn
Level-1
- Beiträge
- 766
- Reaktionspunkte
- 90
da bin ich ja mal gespannt wer außer mir noch Antwortet 
auch interessant wäre doch:
https://de.wikipedia.org/wiki/Fuzzing
https://en.wikipedia.org/wiki/Mutation_testing
das automatische Testen scheitert leider direkt an der fehlenden Automatisierbarkeit der internen TIA-Tools wie Kompiler/Linker, Loader usw.
auch interessant wäre doch:
https://de.wikipedia.org/wiki/Fuzzing
https://en.wikipedia.org/wiki/Mutation_testing
das automatische Testen scheitert leider direkt an der fehlenden Automatisierbarkeit der internen TIA-Tools wie Kompiler/Linker, Loader usw.
RobiHerb
Level-2
- Beiträge
- 679
- Reaktionspunkte
- 113
-> Hier kostenlos registrieren
Codesys Vielleicht auch mal einen Blick über den Zaun werfen
Seit mindestens 2013 im CODESYS Store $$$$ zu haben,
es gibt sogar eine kostenlose Testversion.
Seit mindestens 2013 im CODESYS Store $$$$ zu haben,
es gibt sogar eine kostenlose Testversion.
- Beiträge
- 5.433
- Reaktionspunkte
- 1.409
Leute ihr schmeißt wieder mit Begriffen um euch die ich erstmal Googeln muss
Davon habe ich noch nie gehört. Macht man das Speziell bei Bibliotheken die man verteilen will oder Testet ihr damit ganze Projekte?
Davon habe ich noch nie gehört. Macht man das Speziell bei Bibliotheken die man verteilen will oder Testet ihr damit ganze Projekte?
- Beiträge
- 11.607
- Reaktionspunkte
- 3.866
-> Hier kostenlos registrieren
Leute ihr schmeißt wieder mit Begriffen um euch die ich erstmal Googeln muss
Davon habe ich noch nie gehört. Macht man das Speziell bei Bibliotheken die man verteilen will oder Testet ihr damit ganze Projekte?
Ein ganzes Projekt damit zu testen dürfte - meines Wissens - nur selten Sinn machen.
Aber für einzelne Teilbereiche in der Prozess- und Regelungstechnik oder in der Sicherheitstechnik haben die Tests durchaus Sinn.
Im Maschinenbau werden solche Tests zusammen mit Simulation und 3D-CAD diskutiert.
Da ja moderne 3D-CAD Kollisonserkennung haben , Kräfte und Belastungen ermitteln können, sollen in (ferner) Zukunft automatische Tests von SPS-Programmen ohne aufwendige Beschreibungen im Maschinenbau möglich sein.
Momentan ist das wohl eher in der Phase zwischen Hirngespinst und Vision.
Gruß
Blockmove
RobiHerb
Level-2
- Beiträge
- 679
- Reaktionspunkte
- 113
Was das hilft, wenn Du TIA benutzt?
Du kannst entweder das System wechseln oder das mal bei Siemens einfordern.
Wenn Siemens PLCOpen konform wäre, könntest Du das vielleicht sogar in den CODESYS Testmanager importieren.
Hier ein Screenshot aus dem Antrieb eines "Autonomen" Fahrzeugs, SIL 2 Level.
TÜV und andere lieben es, wenn sie mal den Source im Klartext (XML) analysieren (Export und Import) können und Unit Tests sehen sie auch lieber als ein Hinweis am Firmenschild, dass alles ISO 9xxx ist.
Du kannst entweder das System wechseln oder das mal bei Siemens einfordern.
Wenn Siemens PLCOpen konform wäre, könntest Du das vielleicht sogar in den CODESYS Testmanager importieren.
Hier ein Screenshot aus dem Antrieb eines "Autonomen" Fahrzeugs, SIL 2 Level.
TÜV und andere lieben es, wenn sie mal den Source im Klartext (XML) analysieren (Export und Import) können und Unit Tests sehen sie auch lieber als ein Hinweis am Firmenschild, dass alles ISO 9xxx ist.
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Unter Step7 würde mir einfallen wie man dort so etwas umsetzen könnte, aber bei TIA fehlen mir dazu die Schnittstellen um an die relevanten Informationen im Projekt und in der SPS oder der Plcsim heranzukommen.
Funktionen die ausschließlich auf ihren Eingangsdaten arbeiten, lassen sich noch relativ einfach testen. Da reicht im SPS-Programm die Prüfung in einem Zyklus.
Will ich hingegen Funktionsbausteine z.B. für Antriebe testen, dann wird es etwas aufwendiger. Möchte ich beispielsweise prüfen ob bei meinem Antriebs-FB für ein Ventil die Laufzeitüberwachung funktioniert, muss das SPS-Programm für die Prüfung eine entsprechende Zeit abgearbeitet werden.
Nur mal überlegt welche Funktionalität es benötigt um Unittests an SPS Programmen vornehmen zu können:
- eine SPS oder SPS-Simulation (Plcsim)
- die Möglichkeit eine Quelldateien in Textform über ein Tool in einem Projekt zu übersetzen, es die SPS zu laden, Programmteile zu löschen, die SPS in Stop/Run versetzen
- ein weiteres Programm in der SPS welches die Ergebnisse der Prüfung entgegennimmt/speichert, ggf. Aufrufe von Fehler-OBs entgegennimmt
- Schnittstelle von der SPS zu einem externen Tool welches die Ergebnisse der Prüfung übernimmt
Dabei ist auch die Frage, wie schreibt man seine Überprüfungsprogramme? Macht man das direkt in z.B. SCL, oder überlegt man sich eine sinnvolle Makrosprache die dann durch ein Tool in ensprechede Prüfroutinen übersetzt werden.
Beispiel:
Set(Antrieb.BefehlOeffnen = true)
Wait(T#5s)
Assert(Antrieb.Laufzeitstörung == true)
Es ist auf jeden Fall mit einem nicht geringem Aufwand verbunden.
Funktionen die ausschließlich auf ihren Eingangsdaten arbeiten, lassen sich noch relativ einfach testen. Da reicht im SPS-Programm die Prüfung in einem Zyklus.
Will ich hingegen Funktionsbausteine z.B. für Antriebe testen, dann wird es etwas aufwendiger. Möchte ich beispielsweise prüfen ob bei meinem Antriebs-FB für ein Ventil die Laufzeitüberwachung funktioniert, muss das SPS-Programm für die Prüfung eine entsprechende Zeit abgearbeitet werden.
Nur mal überlegt welche Funktionalität es benötigt um Unittests an SPS Programmen vornehmen zu können:
- eine SPS oder SPS-Simulation (Plcsim)
- die Möglichkeit eine Quelldateien in Textform über ein Tool in einem Projekt zu übersetzen, es die SPS zu laden, Programmteile zu löschen, die SPS in Stop/Run versetzen
- ein weiteres Programm in der SPS welches die Ergebnisse der Prüfung entgegennimmt/speichert, ggf. Aufrufe von Fehler-OBs entgegennimmt
- Schnittstelle von der SPS zu einem externen Tool welches die Ergebnisse der Prüfung übernimmt
Dabei ist auch die Frage, wie schreibt man seine Überprüfungsprogramme? Macht man das direkt in z.B. SCL, oder überlegt man sich eine sinnvolle Makrosprache die dann durch ein Tool in ensprechede Prüfroutinen übersetzt werden.
Beispiel:
Set(Antrieb.BefehlOeffnen = true)
Wait(T#5s)
Assert(Antrieb.Laufzeitstörung == true)
Es ist auf jeden Fall mit einem nicht geringem Aufwand verbunden.
LowLevelMahn
Level-1
- Beiträge
- 766
- Reaktionspunkte
- 90
-> Hier kostenlos registrieren
Das sind übrigends (nur so nebenbei gesagt) die Dinge welche in der normalen (auch Hardwarenahen) Entwicklung mit C/C++ (oder auch andere Hochsprachen/Systemen)
absoluter Standard sind
Voller und direkter Zugriff und Kontrolle über den "Source-Code" und die dazugehörenden Build-Tools (Kompiler/Linker/Loader/Debugger...)
und Siemens hätte sich mit TIA viel viel weniger Schmerzen ins Haus geholt und wirklich mal was revolutionäres in der Automatisierungsbranche vollbracht
wenn sie einfach diesem Der-Rest-der-Welt-funktioniert-schon-lange-so-Standard gefolgt wären - schade das die falschen Entwickler/Entscheider am Anfang das ganze in diese
Richtung getrieben haben
RONIN
Level-3
- Beiträge
- 2.529
- Reaktionspunkte
- 773
Für die API von PLCsim gibt's seit gestern ein neues Anwendungsbeispiel. Hat zwar eher mit Prozesssimulation statt Unittesting zu tun, aber ich schmeiß ihn mal rein.
https://support.industry.siemens.com/cs/ww/de/view/109739660
https://support.industry.siemens.com/cs/ww/de/view/109739660
- Beiträge
- 9.711
- Reaktionspunkte
- 2.787
Ja, ob sowas in der SPS-Programmierung nötig ist, muss jeder für sich entscheiden.
In der Steuergeräteentwicklung in der Automobilentwicklung wird solch ein Test auch gemacht. Da wird dann die getestete Software aber auch in 100.000en Fahrzeugen eingesetzt...
Für unsere Branche könnte man sicherlich Standard-Bibliotheks-Bausteine damit testen. Aber für das normale SPS-Programm, welches nur für eine Anlage verwendet wird, übersteigt der Aufwand den Nutzen bei weitem. Vielleicht noch für Serienmaschinenhersteller interessant, aber selbst das...
Gruß.
PS: wir sind doch oft schon froh, überhaupt eine ordentliche Funktionsbeschreibung für die SPS-Funktionalität zu bekommen. Viele Probleme bei der IBS sind doch nicht Tippfehler, sonder generell eine im Vorfeld falsch ausgedachte Logik. Oft sind dann noch nicht mal die richtigen Feldgeräte verbaut, Messbereiche von 4...20mA Signalen unbekannt etc... Ich denke jeder der mal auf ner IBN war, weiss was ich meine.
Also Simulation im Vorfeld: JA
Aber aufwändige automatisierte Softwaretests: eher mit Kanonen auf Spatzen schiessen.
Meine Meinung.
F
Zuletzt bearbeitet:
OP
Jochen Kühner
Level-3
- Beiträge
- 4.291
- Reaktionspunkte
- 527
-> Hier kostenlos registrieren
Ob es nun mit Kanonen auf Spatzen schießen sein mag oder nicht, es ist trotzdem Kein Grund warum es nicht funktionieren sollte.
Wie gesagt, Siemens hätte sich da einfach z.B an b&r orientieren können. Da ist das ganze Projekt einfach ein Verzeichnis mit xml files, linker und compiler sind extern nutzbar, und unitests möglich.
Wie gesagt, Siemens hätte sich da einfach z.B an b&r orientieren können. Da ist das ganze Projekt einfach ein Verzeichnis mit xml files, linker und compiler sind extern nutzbar, und unitests möglich.
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Und in welche Runtime-Umgebung lädst du das Programm bei B&R?
Für einmalige Projekte und einzelne Bausteine ist so ein Test wohl eher überdimensioniert, aber wenn ich für eine Firma eine Bausteinbibliothek erstelle und warte, dann ist das durchaus sinnvoll und es rechnet sich.
Als Beispiel sei nur die Siemens PCS7-APL genannt, da wäre so etwas durchaus sinnvoll. Der Test muss natürlich auch die diversen spezifizierten Verhalten wie bei SPS Neuanlauf usw. nachbilden können.
Außerdem wissen wir ja noch gar nicht wie aufwändig das für eine SPS real ist, weil es anscheinend noch niemand gemacht hat. Vielleicht ist es mit einer passenden Infrastruktur so praktisch, dass man auch für einzelne Funktionen besser einen kleinen Unittest schreiben kann, als das manuell durchzuspielen.
Für einmalige Projekte und einzelne Bausteine ist so ein Test wohl eher überdimensioniert, aber wenn ich für eine Firma eine Bausteinbibliothek erstelle und warte, dann ist das durchaus sinnvoll und es rechnet sich.
Als Beispiel sei nur die Siemens PCS7-APL genannt, da wäre so etwas durchaus sinnvoll. Der Test muss natürlich auch die diversen spezifizierten Verhalten wie bei SPS Neuanlauf usw. nachbilden können.
Außerdem wissen wir ja noch gar nicht wie aufwändig das für eine SPS real ist, weil es anscheinend noch niemand gemacht hat. Vielleicht ist es mit einer passenden Infrastruktur so praktisch, dass man auch für einzelne Funktionen besser einen kleinen Unittest schreiben kann, als das manuell durchzuspielen.
OP
Jochen Kühner
Level-3
- Beiträge
- 4.291
- Reaktionspunkte
- 527
Bei B&R kann man jede SPS auf dem PC in Simulationsmodus schalten, also du kannst auf dem PC die Runtime starten. (alles per Kommandozeile)
- Beiträge
- 9.711
- Reaktionspunkte
- 2.787
-> Hier kostenlos registrieren
ein Kollege hat mal folgendes fuer ne Bausteinbibliothek gemacht:
- die Ein und Ausgaenge der Bausteine auf nen DB verschaltet.
- nen externes Java Programm geschrieben, welches die Bausteineingaenge im DB beschreibt und die Ausgaenge einliest
- in ner Exeltabelle dann das gewuenschte Verhalten abgelegt, also bei welchen Eingangskombinationen sollen Welche Ausgangskombinationen anstehen
- das ganze dann automatisch durchlaufen lassen
- fuer statische Bausteinverhalten hat das m.M. nach schon funktioniert, aber fuer alles, wo Timer etc. im Spiel sind schon deutlich problematischer...
Gruss
- die Ein und Ausgaenge der Bausteine auf nen DB verschaltet.
- nen externes Java Programm geschrieben, welches die Bausteineingaenge im DB beschreibt und die Ausgaenge einliest
- in ner Exeltabelle dann das gewuenschte Verhalten abgelegt, also bei welchen Eingangskombinationen sollen Welche Ausgangskombinationen anstehen
- das ganze dann automatisch durchlaufen lassen
- fuer statische Bausteinverhalten hat das m.M. nach schon funktioniert, aber fuer alles, wo Timer etc. im Spiel sind schon deutlich problematischer...
Gruss
LowLevelMahn
Level-1
- Beiträge
- 766
- Reaktionspunkte
- 90
bei den Tests vielleicht - aber die fehlenden Zugänglichkeit bei Siemens (danke Jochen für die Info zu B&R) führt dazu das es exakt 0 Anreiz für andere Firmen und Entwicklern gibt Tools zu entwickeln die in irgendeiner Form den Entwicklungsprozess unterstützen (z.B. Unit-Tests, Build-Systeme, Versions-Kontrolle, Regressions-Tests, freie Projektverwaltung, Codegenerierung usw... die Liste ist lang)
so wie es bei normal offenen Systemen möglich ist - und weil König Siemens schon genug Probleme mit seinen monolithischen Entwicklungsklötzen hat gibt es keinerlei Evolution in diesem Bereich - und nein ich denke nicht das die Strategie war wir-machen-alles-selbst-und-geschlossen-weil-das-besser-für-unsere-Kunden ist (und auch KnowHow-Schutz spielt da keine Rolle - anderes Thema) - unerfahrene Entwickler neigen zur Verschlossenheit weil sie denke dann mehr Kontrolle zu haben - was aber leider den Arbeitsaufwand für "jede" Lösung schlecht skalierbar macht
dazu kommt noch das Problem das ein SPS-Entwickler die Qualität/Sinnhaftigkeit einer Lösung meist praktisch erleben muss - da Siemens aber alles dicht macht kommt da nichts was man evaluieren könnte - Ergo - nach der Mentalität vieler SPSler - ist es wohle nicht gut genug für die Industrieanwendung - was aber eigentlich nur das Resultat einer schlechter Produktstrategie ist
in der SPS Entwicklung bei Siemens herrschen Zustände wie zu Entwicklungszeiten um 1984 - und viele SPSler erklären das gerne mit Echtzeit und Sicherheit - was aber damit gar nichts zu tun hat - es wird nur alles künstlich auf dem alten Stand gehalten damit keiner heult (oder weil Siemens es einfach nicht sauber hin bekommt) - es muss nicht gleich C# mit Garbage Collector und WPF oder das schon-wieder-halb-tote OOP auf der SPS sein - das macht nicht unbedingt alles Sinn - C# wohl nicht - aber ein klein wenig würde es schon geben was man sich da abschneiden könnte - ein zugänglicher Kompiler - nicht Open Source - würde trotzdem Sprachenerweiterung mit z.B. Macros usw. erlauben - könnte man alles ausprobieren und sich entwickeln lassen - so sind uns allen einfach die Hände gebunden - schade
ich hoffe aber noch immer
Zuletzt bearbeitet:
- Beiträge
- 9.711
- Reaktionspunkte
- 2.787
Dass TIA nicht toll ist, ist ja allgemein bekannt. Und Siemens hat alles geschlossen, damit gerade Fremdfirmen nicht soleicht Tools, Visu etc. entwickeln können , auch bekannt. Ist halt deren Strategie.
Zum Thema automatisierter Softwaretest, warum brauchst Du da den Zugriff auf den Compiler? Was spricht gegen meine oben aufgezeigte Vorgehensweise? Bzw. was konkret wollt Ihr denn automatisiert machen?
Und das SPS-Programmierung sich von sonstiger Softwareentwicklung unterscheidet ist doch auch allen klar, hat viele gute Gruende und wurde hier auch schon mehrfach diskutiert.
Gruss
Zum Thema automatisierter Softwaretest, warum brauchst Du da den Zugriff auf den Compiler? Was spricht gegen meine oben aufgezeigte Vorgehensweise? Bzw. was konkret wollt Ihr denn automatisiert machen?
Und das SPS-Programmierung sich von sonstiger Softwareentwicklung unterscheidet ist doch auch allen klar, hat viele gute Gruende und wurde hier auch schon mehrfach diskutiert.
Gruss
- Beiträge
- 11.607
- Reaktionspunkte
- 3.866
-> Hier kostenlos registrieren
Tja und da hast du dann bei Siemens gleich das Problem, dass sich PLCSIM anders verhält als reale CPUs.
Ein Kollege lag da letztes Jahr mit Siemens im Clinch. Sein Baustein lief auf PLCSIM und auf einer 300er CPU. Auf der 300F CPU gab es einen Stop.
Ursache war ein falscher Pointerzugriff. Also genau sowas, was man eigentlich mit PLCSIM und / oder auch Unittests finden will.
Er hat die Sache aufbereitet, dokumentiert und an den Support weitergeleitet. Ergebnis kann man sich ja denken
LowLevelMahn
Level-1
- Beiträge
- 766
- Reaktionspunkte
- 90
Ich ändere Code - check den ein und mein Build/Test-System fährt automatisch alle Tests (Sofort/über Nach/am Wochenende) und schickt mir einen eMail wenn ich was kaputt gemacht haben - oder verhindert meinen commit
mit automatischen Integrationstest wird mir sogar genau gesagt welche Änderung den Fehler verursacht hat, nebenbei bekomme ich noch eine nette Info wie weit meine Tests den Code abdecken (coverage) - und das für alle beteiligten Entwickler
Ohne die Möglichkeit Build->Load->Run->Debug per Script/Code-Whatever auszuführen muss man schon wieder alles manuell machen - und das macht man 1-2 mal und dann lässt man es - Automatisierung hilft gegen das Einbrechen der Qualität
sie unterscheidet sich überhaupt nicht - gar nicht - wenn ich z.B. in C -einzelne Units (also die C-Dateien) zwangsweise mit:
- Zustandsautomaten bauen
- keinen Heap nutze
- rekursionen verbiete
- einzeln Units zur Laufzeit ersetzbar halte (dynamic (re)load)
- das ganze in einem Hart-Echtzeit System laufen lasse (FreeRTOs, ThreadX, INTEGRITY,...)
nur die Sprache/Betriebssystem ist anders - SPS Programmierung ist nur sehr vereinfacht - aber eben auch stark eingeschränkt - damit will ich nicht sage das C für SPS Programmierung gebraucht werden sollte - nur als Vergleich
ein in C geschriebenes, echtzeitfähiges ABS-System wird auch vollständig getestet - da gibt es auch Zeitverhalten usw. das zu berücksichtigen ist - und da funktioniert es auch - bissle Robotersteuerung, Ventile oder Motoren sind da auch nicht so Ultra-Krass kompilzierter
Hätte Siemens ein normal offenes System würden solche Fehler viel schneller aufgedeckt und auch behoben werden müssen - Siemens kann sich ständig darauf ausruhen das seine Tools nur von Hand mit viel zum-Laufe-bekommen-Wille genutzt werden - jegliche
Integration würde sofort massive Problem aufdecken - ich denke aber nicht mal das Siemens das bewusst vermeidet - es sind einfach schlechte Entscheider/Entwickler beteiligt - so einfach ist das - man merkt regelrecht wie unprofessionell die ganze Entwicklung läuft
der Anteil an jungen/unerfahrenen Entwicklern muss relativ hoch sein - und ganz ganz alte sind auch nicht so oft das gelbe vom Ei
Zuletzt bearbeitet:
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Die Runtime-Umgebung bei B&R oder Codesys dürfte sich in der Simulation auch von der im Zielsystem unterscheiden. Da ist Siemens sogar im Vorteil, weil der Binärcode CPU-unabhängig ist, Codesys kompiliert hingegen nativ für den jeweiligen Zielprozessor. Außer das Zielsystem ist ebenfalls x86, oder du hast auf dem PC einen ARM o.Ä. Emulator, der dann wieder Unterschiede zur echten CPU aufweisen kann.
Similar threads
