Umfrage: Formale Verifikation / Modellprüfung

Zuviel Werbung?
-> Hier kostenlos registrieren
http://www.durr.com/fileadmin/user_upload/durr_career/downloads/report_duerr_top_arbeitgeber.pdf
Bitte Seite 79 - 80 lesen. Das ist ein Tool mit dem vorab getest und somit die IB verkürzt werden kann und danach wohl weniger Fehler enthält. Das wollen wir doch alle!
Ich kenns aber nur von den Artikeln.

Da geht's um Simulation, das ist ganz was anderes, was der TE meint...

Das was Dürr macht gibt es schon lange und wird häufig vom Kunden gefordert.

Man baut sich im Büro mit einer geeigneten Software (Simit oder Winmod) + Testumgebung mehr oder weniger gut seine Anlage nach... und kann dann sein SPS-Programm im Büro incl. der Schrittketten und sonstwas ausgiebig testen.

Von Siemens (Simit) nimmt man sich nen zusätzlichen Simulations-PC. Dort drinn ist ne spezielle PB-Karte, welche PB-Teilnehmer simulieren kann. Das Ding wird dann über PB mit der originalen SPS mit originalem Programm verbunden. Auf dem Simulation-PC läuft weiterhin die Simulation der verfahrenstechnischen Zusammenhänge, also z.B. wenn man nen Motor ansteuert werden durch das Simulationsprogramm die Eingänge für Drehüberwachung, Motorstrom sonstwas automatisch ausgegeben. Wenn manns dann noch weitertreibt, können auch noch Volumenströme oder was auch immer mit dem Motor zusammenhängt realitätsnah nachgebildet werden.
Hab ich ja eigentlich in meinem ersten Beitrag schon alles geschrieben.

https://eb.automation.siemens.com/mall/de/WW/Catalog/Products/10205995

http://support.automation.siemens.com/WW/view/de/68108412/130000



Gruß.
 
Zuletzt bearbeitet:
Da geht's um Simulation, das ist ganz was anderes, was der TE meint...

Der Grenze zwischen der Validieren und Simulation sind in unser Arbeitswelt nicht bzw nur sehr schwer ziehen.

Der TE versucht Techniken für die Softwareentwicklung auf die Automatisierung zu verwenden.
Da kommt der Vergleich mit Äpfeln und Melonen wieder zum Tragen.

Da bei Programmen auf Rechner Fehler schwerer zu finden bzw deren Auswirkung manchmal nicht offensichtlich zu erkennen sind.
Aber bei PLC Programmen ist es etwas anderes.
Wenn ein Fehler da ist, dann macht der sich meist schnell bemerkbar.
Theorie ist wichtig, doch noch gibt es keine Modelle nach denen man Validieren könnte.
Auch sind die Anforderungen so verschieden, dass allein das Erstellen solcher Modelle einfach zu fehleranfällig und zu teuer ist.

Warum schreibt der TE nicht, er will eine Geschäftsidee um zu verdienen, bei der aber Andere für ihn arbeiten.
Denn wenn der einmal ein Pflichtenheft sich angeschaut hätte, wären die Fragen klüger ausgefallen.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Grenze zwischen der Validieren und Simulation sind in unser Arbeitswelt nicht bzw nur sehr schwer ziehen.

Jo, das liegt aber daran, dass der Begriff "Simulation" sehr inflationär für alle möglichen Dinge missbraucht wird ;)

für mich bedeutet Simulation erstmal nur, etwas im Moment nicht vorhandenes "nachzubilden". Also z.B. die SPS durch PLCSIM oder die PB-Geräte und Anlage mit Simit.

Der eigentliche Softwaretest (Validierung) ist für mich nicht Simulation, wird aber von einigen Leuten trotzdem so bezeichnet.

Gruß.
 
@MrSpexx
m.M. will der TE nicht Fehler in der Anlage erkennen sondern vorab das SPS-Programm auf Programmierfehler hin überprüfen.
Richtig, so wie ichs mir vorstelle braucht man auch keine echte SPS dazu (aber ich muss natürlich vorher irgendwie angeben auf welcher es laufen soll).

Wieviele mögliche Fälle hast Du, bei einer Anlage mit 1000 Eingängen und 500 Ausgängen? Das solltest Du ja eigentlich ausrechnen können. Und da ja im Programm auch viele Timer verbaut sind kannst Du höchstens sagen wir mal pro 5 Sekunden einen Fall testen. Wie lang soll sowas dann dauern?
Mal abgesehen davon wird es nicht so einfach sein nur Eingang X und y zu setzen und rückzusetzen, weil du intern viele Zustände haben kannt in denen du auf den Eingang X oder auf Eingang Y oder auf beide wartest. Alle Ausgänge mal in allen Kombinationen zu setzen wird dir da nicht viel weiterhelfen, bzw. du wirst wohl auch so viele Fehler bekommen, dass du deine Zustände gar nicht in der gewünschten Reihenfolge durchlaufen kannst.
Oft kommt es auch gar nicht darauf an wie die Eingänge statisch sitzen, sondern auch in welcher Zeit.
Das Phänomen das ihr beschreibt heißt Zustandsraumexplosion. Die Anzahl der Ein- und Ausgänge ist nicht so tragisch, wenn ich die genannten 500 Ausgänge habe und jeder so im Schnitt von ~4 - 5 Eingängen abhängt, dann hab ich 16 bis 32 mögliche Kombinationen, also insgesamt 8000 - 16000 Fälle. Das ist Pipifax. Problematisch wirds aber wirklich, wenn man Variablen über mehrere Zyklen behält oder wenn man z.B. Zählereingänge hat. Wenn mein Programm einen Zählereingäng über 5 Zyklen überwacht, hab ich 2^16^5 = 1,089258 * 10^24 Fälle. Das ist hundert mal so viel wie es Sterne im Universum gibt. Und wenn ich Timer verwende sind die zeitkontiniuerlich und asynchron, also gibts prinzipiell unendlich viele Fälle.

... weswegen ich das Ganze ja auch als interessantes mathematisches Problem bezeichnet hab. Denn jedem leuchtet intuitiv ein, dass viele Fälle das gleiche Verhalten erzeugen, und man kann in Vorraus analysieren, welche das sein werden. Und so kann man dann alle Fälle simulieren, ohne alle Fälle simulieren zu müssen.

Und wer definiert die "richtige Verhalten" für all diese Fälle?
Wie ich vorher schon gesagt hab, gebe ich a) wichtige Fälle an, welche nicht eintreten sollen sowie b) wichtige Fälle, die eintreten sollen. Letzteres mache ich normalerweise durch Ausprobieren und zugucken, typischerweise bei der Inbetriebnahme, wie ihr mir gesagt habt. Und Fall a ist wohl ähnlich dem, was typischerweise als Fehlercode gemeldet wird. Aber bei einem Fehlercode muss ich versuchen, diesen durch Tests explizit zu erzeugen und finde damit nicht alle möglichen Ursachen und weiß beim Eintreten auch nicht genau, was die Ursache war. Bei einer Modellprüfung krieg ich das alles frei Haus geliefert. Zudem kommt hinzu, dass ich zwingend die Peripherie simulieren oder nachbauen muss (wie in dem Dürr-Artikel beschrieben), wenn ich die Fehlercodes noch vor der Inbetriebnahme vernünftig testen möchten, während ich mir das bei der Modellprüfung wohl häufig sparen kann, wenn das Simulationsmodell für die Peripherie nicht so arg kompliziert ist. Und wenn ich die Volumenströme durch Ventile simulieren will, kommen wir zum nächsten Punkt...

Da geht's um Simulation, das ist ganz was anderes, was der TE meint...
Das was Dürr macht gibt es schon lange und wird häufig vom Kunden gefordert.
Richtig erkannt, das meine ich nicht. Ist aber insofern interessant, dass es sich mit dem was ich meine teilweise ersetzen oder alternativ auch gut kombinieren lässt. Denn wenn ich das Verhalten der SPS simuliere, kann ich die dadurch erzeugten Ein- und Ausgangswerten ja auch solche Simulationsmodelle für die Peripherie weitergeben und deren Verhalten mitsimulieren. Ist dann aber schon ein weiterführendes Thema.

Der TE versucht Techniken für die Softwareentwicklung auf die Automatisierung zu verwenden.
Da kommt der Vergleich mit Äpfeln und Melonen wieder zum Tragen.
ducati spricht davon, nicht vorhandene Teile für den Test durch Simulationen zu ersetzen (da haben wir Mocks und Fakes), MrSpexx von Standardisierung der Softwarebausteine und besseren Softwarestrukturen (da haben wir die ganze OOP, Standard-Klassenbibliotheken mit so Prinzipien wie Kapselung, etliche design patterns uvm.) und das Hauptproblem ist laut ducati, dass der Auftraggeber nicht genau spezifiziert und zu spät im Entwicklungsprozess Sonderwünsche hat (1:1 übernehmbar). Hört sich für mich bislang recht vertraut an.

Hängt natürlich von vielem ab. Bei mir in der Prozessautomatisierung/Anlagenbau ist das Problem, dass ich vorher nicht 100%ig weiss wie die Anlage aussieht und was die Steuerung machen soll. Die Infos der "Verfahrenstechniker" sind immer sehr bescheiden bzw. fehlerhaft.
PS: und dass der Kunde tausend Extrawünsche hat, welche das Programm unnötig aufblähen.
Dann muss ich jetzt weiter fragen: Was ist daran problematisch, und was tust du dagegen?
 
Ich denke du bist auf dem Holzweg. Versuch mal das Problem von der anderen Seite her anzugehen. Standardbausteine für immer wieder kehrende Aufgaben/ Programmaufbau.

Aber du bist hartnäckig das gefällt mir. ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
auch zwischen Äpfeln und Melonen lassen sich Gemeinsamkeiten finden. Trotzdem bleiben die Unterschiede erhalten ;)

Zum Rest denke ich ist alles gesagt.

Wie bike schon sagte, schau Dir mal ein Pflichtenheft und ein umfangreiches Automatisierungsprojekt an (das hat mit Deiner Logo so gut wie nichts gemein). Dann verstehst Du uns auch.

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Naja gut, wenn jetzt schon mit dem Forentroll verglichen werden musss, dann sind euch wohl die Ideen ausgegangen. Ich bedank mich trotzdem für die bisherigen Antworten, war ja doch was informatives dabei.

Gruß
 
Die Problematik bei Software in der Automatisierungstechnik ist doch, dass diese mit der realen Welt interagiert. Im Gegensatz zu Businessanwendungen, bei denen definierte Daten (Dateien, Benutzereingaben, etc.) hineinkommen und wieder hinausgehen. D.h. deine Verifikation in der Automatisierungstechnik muss zumindest teilweise die reale Welt abbilden können, und die ist bekannterweise komplex.

Das nächste Problem ist, dass eine Anlage nur in den wenigsten Fällen aus nur einer einzigen Steuerung mit einem Steuerungsprogramm besteht. Hast du beispielsweise Busteilnehmer wie Frequenzumrichter oder Servoantriebe mit eigenen Programmen und hunderten von Parametern, busfähige Messungen, Ventilinseln usw., muss deine Verifikation genau wissen wie sich diese Teilnehmer intern verhalten, welche Regelkreise dort ablaufen und das alles abbilden können.
Ich sag mal aus Erfahrung, dass es einem SPS-Programmierer nur selten auf Anhieb gelingt dass die Kommunikation mit einem neuen Busteilnehmer auf Anhieb nur anhand der Beschreibung im Handbuch gelingt. Bei der Inbetriebnahme sind immer kleine Anpassungen zu machen.

Ich teste meine SPS-Programme meistens mit Plcsim mit einer mehr oder weniger aufwändigen Simulation durch. Wie aufwändig ich die Simulation gestalte, hängt davon ab wie kritisch die Anlage ist die man dann in Betrieb nimmt, und wie groß die Möglichkeiten sind an der Anlage irgendwelche Fehlerzustände durchzutesten.
Aber eine komplette Verifikation bei der man dann sagen kann: "Programm ist fehlerfrei" halte ich zumindest bei nicht trivialen Anlagen für unmöglich.

Und dann bleibt ja noch dein angesprochenes mathematisches bzw. logisches Problem: das Halteproblem ;-)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Naja gut, wenn jetzt schon mit dem Forentroll verglichen werden musss, dann sind euch wohl die Ideen ausgegangen. Ich bedank mich trotzdem für die bisherigen Antworten, war ja doch was informatives dabei.

Gruß

Es ist immer leicht auf andere mit dem Finger zu zeigen.
Du hast nicht einen vernünftigen, sinnvollen Satz zu dem Thema Automatisierung abgelassen.
Anstelle die Beiträge lesen und zu verstehen, bist du zu weit von der Realität abgehoben, um ernsthaft das Thema zumindest zu diskutieren.
Wer unterstellt, wenn auf ein Modell verweisen wird, an ein 3D Modell gedacht werde, der zeigt was derjenige wirklich von der Programmierung versteht.

Und Ideen? Wer führt denn das große Wort und will die Automatisierung revolutionieren und hat keine Ahnung?
Wir können zumindest programmieren. ;)

Nimm dir eine Auszeit und denk nach.

bike
 
Siemens hat ja vor einiger Zeit Unigraphic übernommen.
Damit haben sie mit NX ein sehr leistungsfähiges 3D-CAD-System.
Es wird wohl gerade an der Kopplung TIA-PLCSIM-UG "gebastelt".
Wenn das 3D-Modell "sauber" ist, dann beherrscht NX schon heute Kollisionserkennung.
Also könnte zumindest das Thema Simulation / Test vielleicht einfacher werden ... So in 10-15 Jahren ;)

Gruß
Dieter
 
Siemens hat ja vor einiger Zeit Unigraphic übernommen.
Damit haben sie mit NX ein sehr leistungsfähiges 3D-CAD-System.
Es wird wohl gerade an der Kopplung TIA-PLCSIM-UG "gebastelt".
Wenn das 3D-Modell "sauber" ist, dann beherrscht NX schon heute Kollisionserkennung.
Also könnte zumindest das Thema Simulation / Test vielleicht einfacher werden ... So in 10-15 Jahren ;)

3D kann man auch selber machen, mit der Unreal Engine oder der Blender Gameengine. Hab zusammen mit dem ErwinLSE da mal was entwickelt:
http://www.youtube.com/watch?v=KzuPgLJ88UU
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ein 3D Modell damit Störkonturen gefunden werden ist doch schon heute mit jedem bessern CAD Programm möglich.
Doch mit der Simulation kann man nach meinem Wissen keine Software validieren.
Jetzt warte ich auf die PLC ProgrammierAPP für das Eifon.
Denn dann weiß ich, dass es langsam Zeit wird zu gehen. ;)


bike
 
Doch mit der Simulation kann man nach meinem Wissen keine Software validieren.

Eine Simulation ist schon aufwendig, aber eine automatische Validierung eines kompletten Anlagenprogrammes ist geschätzt mindestens Faktor 10 aufwändiger. Und wie will man z.B. die Stabilität eines Regelkreises beweisen, wenn man mangels gebauter Anlage überhaupt kein Prozessmodell hat?
 
Thomas du hast wie meist leider recht.
Ich wollte dem TE erklären, dass er bevor das nächste mal so eine unsinnige Frage stellt, sich informieren sollte.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Thomasv2.1: Das überzeugt mich. Darf man also sagen, dass eine Verifikation bzw. Validierung schon erstrebenswert ist, aber nur dann, wenn sie auch wirklich die komplette Anlage miteinbezieht, was aufgrund der hohen Komplexität unmöglich ist?

3D kann man auch selber machen, mit der Unreal Engine oder der Blender Gameengine. Hab zusammen mit dem ErwinLSE da mal was entwickelt:
Das sieht ziemlich cool aus. Mit welcher Schnittstelle exportierst du die Daten aus PLCsim?
 
@Thomasv2.1: Das überzeugt mich. Darf man also sagen, dass eine Verifikation bzw. Validierung schon erstrebenswert ist, aber nur dann, wenn sie auch wirklich die komplette Anlage miteinbezieht, was aufgrund der hohen Komplexität unmöglich ist?


Das sieht ziemlich cool aus. Mit welcher Schnittstelle exportierst du die Daten aus PLCsim?

Bist du wirklich überzeugt oder fragst du nur ins blaue hinein?
Du nimmst ein Stichwort und machst an einer Stelle weiter, obwohl dir die Grundlagen nicht geläufig sind.

Es ist nach heutigem Stand der Technik nicht möglich in einem überschaubaren Rahmen realistische Modelle zu erstellen und dann die Software zu validieren.



bike
 
Zurück
Oben