@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?