Umfrage: Formale Verifikation / Modellprüfung

[Skrjiban]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,

ich bin kürzlich mal zufällig auf das Thema Formale Verifikation von Programmen gestoßen und mir kommt das Konzept - grade im Bereich Automatisierungstechnik - extrem hilfreich vor und es ist mir ein Rätsel, warum ich davon jetzt zum ersten mal höre. Nachdem ich aber selbst in meiner Berufslaufbahn bisher vergleichsweise selten zum tatsächlichen SPS-Programmieren gekommen bin, wollte ich hier ein wenig "Marktforschung" betreiben bei den Leuten, die drin sind in der Materie.

---

Zunächst für alle die's nicht wissen: Was ist Model Checking?
Ein großes Problem beim Programmieren ist ja die Fehlersuche. Normalerweise mache ich dabei im Prinzip folgendes:
Normaler Testablauf:

1. Ich überlege mir, welche Betriebsfälle eintreten können. Insbesondere welche einen Fehler hervorrufen könnten.
2. Ich teste die Fälle und prüfe, ob das eintretende Verhalten das gewünschte ist.
3. Wenn ja -> gut, wenn nein -> Fehler beheben.

Das ganze kann ich strukturiert machen (z.B. Unit Testing) oder manuell, indem ich, auf gut Deutsch gesagt, solang rumprobiere bis alles geht.

Problematisch ist der erste Schritt, denn durch Überlegung kommt man kaum auf alle abstrusen Fehler, die sich so in ein Programm einschleichen. Jeder der mal irgendwas programmiert hat kennt das Problem.

Bei der Modellprüfung funktioniert der Ablauf deshalb so:

1. Ich lege eine Reihe von Bedingungen fest, die IMMER vom Programm eingehalten werden. z.B. "Niemals NOT-Aus und Motor an", "Niemals A0.1 für länger als 10 Sekunden", "Wenn sqrt(EW5 * EW6 > 10) dann irgendwann A0.5 = 1 binnen 8s". Alle Bedingungen zusammen ergeben das sog. Modell.
2. Der Model Checker prüft JEDEN MÖGLICHEN BETRIEBSFALL des Programms auf die Wahrheit des Modells.
3. Wenn kein Fall existiert, in dem das Modell nicht eingehalten wird -> gut, ansonsten -> fehlerhaftes Gegenbeispiel anzeigen -> Fehler beheben.

In der Hardwareentwicklung ist diese Methodik der Formalen Verifikation recht verbreitet, z.B. um die korrekte Funktionsweise von Prozessoren zu beweisen. In der Softwareentwicklung habe zumindest ich noch nie etwas davon mitbekommen. Und bei SPS erst recht nicht.

Eine Recherche ergab dann auch nicht arg viel. Ein Programm namens ArcadePLC hab ich gefunden:
http://arcade.embedded.rwth-aachen.de/doku.php?id=arcade.plc
Ist mir aber beim Datei laden abgestürzt, drum kann ich nichts dazu sagen. Bis auf eine kostenpflichtige Publikation des Entwicklers habe ich auch bei google keinerlei Dokumentation oder Diskussion dazu gefunden.

Das Tool UPPAAL scheint relativ verbreitet zu sein, ist aber nicht speziell für SPSen gedacht : http://www.uppaal.com/index.php?sida=186&rubrik=93

Ich habe nichts gefunden, wo ich einfach mein Programm/Projekt laden konnte, Bedingungen eingebe und dann ein Ergebnis erhalte.

---

Jetzt zu meinem eigentlichen Anliegen:

• Wem war das Prinzip schon vorher geläufig? Setzt ihr es ein?
• Wenn ja: Welche Tools verwendet ihr dafür?
• Wenn nein: Warum nicht?
• Wer das Prinzip vorher nicht kannte: Was meint ihr dazu? Würdet ihr es einsetzen, wenn es eine gute Software dafür gäbe?
• usw.

Schonmal danke für die Antworten!

 

[bike]

Das Thema hat inzwischen einen echt langen Bart.
Das Problem liegt daran, ein Modell zu erstellen.
Bei einer Serie ab x + 1000 Stück pro Jahr ist solch eine Modulbildung vielleicht sinnvoll.
Doch wer baut so viele Produkte in Serie?
Zu den Tools die Frage:
Wo gibt es für unsere Umgebung irgend welche Tools?

Junge von der Uni, so abstrakt zu fragen zeigt, dass du dich mit der Automatisierung, das unser Geschäft hier ist, nicht im geringsten beschäftigt hast.



bike

 

[winnman]

Zuviel Werbung?
-> Hier kostenlos registrieren

Punkt 1. wird wohl fast jeder Programmierer im SPS Umfeld machen.
2. wird bei der IBS realisiert und daraus ergibt sich Punkt 3.

Was willst du uns sagen?

 

[Skrjiban]

Hm, hab ich mich so unklar ausgedrückt?

Das Problem liegt daran, ein Modell zu erstellen.
Bei einer Serie ab x + 1000 Stück pro Jahr ist solch eine Modulbildung vielleicht sinnvoll.
Doch wer baut so viele Produkte in Serie?

Reden wir aneinander vorbei? Mir kommt es so vor, als ob du von einem 3D-Modell sprichst. Darum gehts mir nicht. Mir geht es um eine Spezifikation für ein SPS-Programm. Anschließend will ich prüfen, ob das Programm diese Spezifikation auch einhält. Und das automatisch, mit einem Software-Tool (= http://de.wikipedia.org/wiki/Model_Checking )

Punkt 1. wird wohl fast jeder Programmierer im SPS Umfeld machen.
2. wird bei der IBS realisiert und daraus ergibt sich Punkt 3.

Da komm ich jetzt nicht ganz mit. Auf welche Punkte beziehst du dich?

 

[Bapho]

Also m.E. ist das was für akademische Denkspiele.

Ich muß mir ja im Vorfeld meinen Programmablauf, Funktionen und die Sicherheit überlegen und irgendwie definieren. Dieses Konzept wird dann umgesetzt, in dem ich diese Vorgaben mit einer Programmiersprache in eine Logik übersetze. Wenn sowas ordentlich gemacht wird, sollten schonmal kaum gravierende Bugs auftreten und wenn ich das ganze ordentlich strukturiere lassen sich Fehler auch schnell finden und ach Änderungen leichter einpflegen, zBsp. doppelter Code ist einmal zuviel.
Ist auch immer abhängig von der Komplexität der Aufgabe, aber die meiste Arbeit liegt eigentlich vor dem Programmieren und da werden oft die meisten Fehler gemacht.

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hm, hab ich mich so unklar ausgedrückt?



Reden wir aneinander vorbei? Mir kommt es so vor, als ob du von einem 3D-Modell sprichst. Darum gehts mir nicht. Mir geht es um eine Spezifikation für ein SPS-Programm. Anschließend will ich prüfen, ob das Programm diese Spezifikation auch einhält. Und das automatisch, mit einem Software-Tool (= http://de.wikipedia.org/wiki/Model_Checking )



Da komm ich jetzt nicht ganz mit. Auf welche Punkte beziehst du dich?

Bestimmt nicht.
Für die Definition der Logik braucht doch zuerst ein Modell, was die Maschine bzw Anlage tun soll.
Mit dieser Definition könnte man die Anforderung an das PLC Programm definieren.
Aber dein Unverständnis zeigt, dass du zuerst dich um die Grundlagen kümmern und verstehen sollst.


bike

 

[ducati]

Hihi, da treffen sie wieder aufeinander

Für die (SPS-) Automatisierung ist das wirklich alles Quatsch, da einfach zu aufwendig... (erstens von der Zeit und zweitens von den Kosten)

In der Automobilindustrie (Fahrzeugentwicklung, nicht Fertigung) wird sowas aber schon eingesetzt. Ich hab da mal nen Vortrag gehört, der hat die Algorithmen von nem Schachcomputer verwendet und quasi den Softwaretest gegen das Fahrzeugsteuergerät antreten lassen...

Aber das ist alles schon etwas her, daher habe ich jetzt aus dem Hut auch keine weiterführenden Links.

Aber wie Bike schon sagt, bei Produktzahlen im 6 oder 7 stelligen Bereich mit entsprechenden Kosten für Rückrufaktionen und Imageschäden lohnt sich der Aufwand. In der SPS-Automatisierung mit Verwendung des identischen Programms zwischen vielleicht 1 und 100 mal macht solch ein Aufwand wenig Sinn... Zumal das ganze nicht trivilal für den Durchschnittsingenieur umsetzbar ist.

Was man heute schon häufig macht, ist eine mehr oder weniger aufwändige Simulation der Maschine/Anlage im Büro aufzubauen, um die Software mit angebundener simulierter Hardware zu testen. Das ist aber schon nicht ganz simpel. Natürlich könnte man sich jetzt vorstellen, die Simulationssoftware noch um einen automatischen "Softwarefehlersuchalgorithmus" zu erweitern. Aber solange das nicht wirklich intuitiv zu bedienen ist, sehe ich da für die Praxis schwarz.

Erschwerend kommt hinzu, dass die SPS-Software ja nicht alleine dasteht, es gibt noch die Visualisierung, welche mittlerweile eine sehr großen Umfang besitzt. Also müsste für einen automatisierten Softwaretest auch automatisch Eingaben in der Visu vorgenommen werden... und das ist schon schwieriger ohne die Visu selbst zu manipulieren...

Zurück zur Praxis: Softwarefehler sind schön und gut, aber Sorgen sind auf der Baustelle ganz andere vorhanden. In der Regel Projektorganisatorischer Art. Oft erfährt man erst auf der Baustelle, welcher Sensor mit welchem Messbereich an welcher Stelle wirklich verbaut ist... Da nützt die beste Simulation im Vorfeld nichts, wenn die Realität ganz anders aussieht.

Aber trotzdem macht ne Simulation Sinn, ist aber aufwändig (geschätzte zusätzliche 50-100% der SPS-Softwarezeit)

Gruß und habt Euch alle lieb

PS: eine Industriesteuerung, wie wir sie hier regelmäßig errichten hat nicht 10 Eingänge und 10 Ausgänge sondern mal locker >1000 Eingänge und >500 Ausgänge. Und das sind u.U. nur Teilanlagen von einer großen Produktionsanlage... Das ist das Problem mit dem Aufwand...

PPS: und nein, das sind keine Kernkraftwerke, wo man den Aufwand vielleicht noch rechtfertigen könnte

PPPS: wenn etwas in der Praxis nicht gemacht wird, liegt das meist nicht daran, dass alle anderen so doof und man selbst so schlau ist sondern es gibt gute Gründe dafür... abundzu findet man aber trotzdem ne Marktlücke. Oder man hat gut Verkäufer, die auch den letzten Scheiss an den Mann bringen.

 

[MrSpexx]

Meiner Meinung macht die Prüfung nur Sinn wenn auch standardisierte Softwarekomponenten verwendet werden. Wird ein Programm von Hand neu gestrickt ist der Aufwand zu groß. Das Problem besteht wohl da drin das der Programmierer und Prüfer der selbe sein wird. Wenn dir bei der Programmierung bestimmte Konstalationen nicht auffallen, wirst du auch bei der Prüfung nicht da dran denken.

Ein guter SWtest ist sehr wichtig. Beim normalen Automatikablauf sind Fehler auch schnell gefunden. Das Problem ist eher, wie reagiere ich bei Fehler xy. Ich teste bei der Inbetriebnahme jede Fehlermeldung und hake sie ab. Damit läßt sich oft noch der ein oder andere Fehler finden.

Aber das Zauberwort heißt: Standardisierung. Ein Motorbaustein der z.B. über einen UDT Fehler ausspuckt und gekapselt ist muss normalerweise nicht mehr getestet werden. So kann viel Zeit gespart werden.

Zu deinem Punkt fällt mir noch folgendes ein:
http://www.freepatentsonline.com/DE102010005308.html

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Meiner Meinung macht die Prüfung nur Sinn wenn auch standardisierte Softwarekomponenten verwendet werden. Wird ein Programm von Hand neu gestrickt ist der Aufwand zu groß.
...
Aber das Zauberwort heißt: Standardisierung. Ein Motorbaustein der z.B. über einen UDT Fehler ausspuckt und gekapselt ist muss normalerweise nicht mehr getestet werden. So kann viel Zeit gespart werden.

Jo, da dieser Motorbaustein dann ja vielleicht auch 10000 mal verwendet wird, könnte solch ein Test dafür u.U. sinnvoll sein (bzw. nach jeder "kleinen" Änderung mal den Test pauschal drüber laufen lassen). Oder Siemens könnte solch einen Automatischen Softwaretest für seine PCS7-APL-Bibliothek verwenden... Also allgemein für Programmierer von Bibliotheken.

Aber für ein komplettes SPS-Programm macht das alles keinen Sinn.

Gruß.

 

[Skrjiban]

Erstmal Danke für die ausführlichen Antworten. Zumindest weiß ich jetzt schonmal, dass die Methodik definitiv nicht in der Praxis gemacht wird, zumindest nicht bei SPS-Programmen.

wenn etwas in der Praxis nicht gemacht wird, liegt das meist nicht daran, dass alle anderen so doof und man selbst so schlau ist :wink:

Hat ja auch niemand behauptet

Ich muß mir ja im Vorfeld meinen Programmablauf, Funktionen und die Sicherheit überlegen und irgendwie definieren. Dieses Konzept wird dann umgesetzt, in dem ich diese Vorgaben mit einer Programmiersprache in eine Logik übersetze. Wenn sowas ordentlich gemacht wird, sollten schonmal kaum gravierende Bugs auftreten und wenn ich das ganze ordentlich strukturiere lassen sich Fehler auch schnell finden und ach Änderungen leichter einpflegen, zBsp. doppelter Code ist einmal zuviel.
Ist auch immer abhängig von der Komplexität der Aufgabe, aber die meiste Arbeit liegt eigentlich vor dem Programmieren und da werden oft die meisten Fehler gemacht.

Da stimme ich dir natürlich zu. Ich entwickle hauptberuflich PC-Software und auch da ist es meist so, dass eine gute Planung schwieriger als die tatsächliche Implementierung ist. Eine andere Wahrheit ist aber auch, dass sich a) nie alles vorher planen lässt, weil immer wieder Änderungen vorkommen und b) in der Praxis dann doch im Schnitt ein nicht unwesentlicher Teil der Zeit und des Geldes (ich glaube 40% des Budgets oder sowas, habs grad nicht mehr im Kopf) für Fehlersuche und Behebung draufgeht. Ich weiß natürlich nicht wie das in der professionellen Automatisierungsindustrie aussieht (deswegen frage ich euch ja) - ich würde mal auf "ähnlich" tippen.

Ansonsten war der Konsens hier ja, dass so eine Modellbildung zu aufwändig wäre, als dass es sich lohnen würde. Es geht aber ja auch gar nicht darum, das Verhalten vom ganzen Programm im Detail zu spezifizieren. Das ist natürlich utopisch. Und ich will die Modellbildung auch gar nicht in die Planungsphase einbinden. Es geht nur darum, das Testen am Ende schneller und sicherer zu machen, indem ich die _essenziellen_ Verhaltensweisen der Steuerung prüfe.

Minibeispiel: Letztens hab ich eine Torsteuerung mit Logo programmiert. Das Tor sollte abends zugehen und morgens wieder auf (mit Zeitumstellung) das Tor konnte man von außen per Zugangskarte oder per Funk öffnen, von innen über Bewegungsmelder. Dann ne Lichtschranke zur Sicherheit, die verhindert dass jemand eingeklemmt wird. Ganz simpel. Nach ein bisschen rumprobieren lief das Ganze dann auch und die Tests waren gut. Ich bin nach Hause gefahren und hab am nächsten Tag erfahren dass das Tor natürlich nicht abends geschlossen hat wie es sollte, weil sich irgendwo ein mieser kleiner Fehler eingeschlichen hat, der so selten war, dass er beim Testen nie aufgetreten ist.
Da hätte ich jetzt gerne eine Software gehabt, wo ich das Logo-Programm lade, dann eine Bedingung á la "Uhrzeit > 20:00h || Uhrzeit < 06:00h => Tor zu" eingebe (was nun wirklich nicht viel Arbeit ist) und hätte alle Fälle aufgelistet bekommen, in denen dies nicht der Fall ist. Neben einigen legitimen Fällen ware auch der unerwartete dabei gewesen und ich hätte auf die Frage "Geht das Tor jetzt heute abend auch zu?" mit Gewissheit "Ja!" antworten können.

Bei einer größeren Steuerung stelle ich mir das so vor (korrigiert mich bitte wenn ich falsch liege): Ich muss ich ja auch hier nur das Wichtigste prüfen. Ich kann mir zum Beispiel alle Fälle anzeigen lassen, in denen ein Förderband stillsteht. Oder wenn ich eine Joghurtabfüllmaschine programmiere dann teste ich halt zwischendurch kurz "Wenn Ventil offen dann binnen 30 s Ventil wieder zu". Die Syntax für die Eingabe der Bedingungen muss natürlich intuitiv und simpel sein, ansonsten hat da niemand Lust drauf, ist schon klar.

Erschwerend kommt hinzu, dass die SPS-Software ja nicht alleine dasteht, es gibt noch die Visualisierung, welche mittlerweile eine sehr großen Umfang besitzt. Also müsste für einen automatisierten Softwaretest auch automatisch Eingaben in der Visu vorgenommen werden... und das ist schon schwieriger ohne die Visu selbst zu manipulieren...

Das ist natürlich auch richtig, ein automatischer Test des UI ist wohl prinzipiell quasi unmöglich. Allerdings sind die Fehler in der Visualisierung ja weniger tragisch als im Steuerungsablauf. Außerdem: Ein- und Ausgaben in der Visualisierung werden doch als rohe Daten mit der Steuerung kommuniziert und könnten hier, genau wie Ein- und Ausgänge, getestet werden. Wenn man denn unbedingt will.

 

[MrSpexx]

Das Beispiel mit dem Ventil ist gut. Nur ich würde das nicht als SW-Test bezeichnen sondern als Fehlerabfrage. Wenn Ventil länger als 30 Sekunden offen ist: dann gib einen Fehler aus. Wenn Temperatur zu hoch: gib einen Fehler aus.
Ich glaube dafür gibt es hier weitgehend Übereinstimmung. Der Unterschied zu PC-Programmen zu Automatisierungsaufgaben ist ja. Wenn etwas nicht tut sieht man es sofort weil der Ablauf/Bewegung nicht stimmt.
Ein großer Brocken ist auch die Verbindung zur Visu und der Handbetrieb. Das ließe sich - soweit ich das verstanden habe - mit SW Test´s schwer umsetzen.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich entwickle hauptberuflich PC-Software und auch da ist es meist so, dass eine gute Planung schwieriger als die tatsächliche Implementierung ist. Eine andere Wahrheit ist aber auch, dass sich a) nie alles vorher planen lässt, weil immer wieder Änderungen vorkommen .

Naja, wenn vorher nicht klar ist, was die Steuerung im Detail machen soll, dann kannst Du die nicht klaren Fälle auch nicht testen. Da beisst Sich die Katze in den Schwanz.

Ansonsten war der Konsens hier ja, dass so eine Modellbildung zu aufwändig wäre, als dass es sich lohnen würde. Es geht aber ja auch gar nicht darum, das Verhalten vom ganzen Programm im Detail zu spezifizieren. Das ist natürlich utopisch. Und ich will die Modellbildung auch gar nicht in die Planungsphase einbinden. Es geht nur darum, das Testen am Ende schneller und sicherer zu machen, indem ich die _essenziellen_ Verhaltensweisen der Steuerung prüfe.

Eine Industriesteuerung macht ohne Anlage oder Anlagenmodell nicht wirklich viel sinnvolles. Der ganze Programmablauf wartet ständig auf irgendwelche Signale vom Feld bzw. ist drauf angewiesen. Ohne Simulationsmodell kannst Du da nicht wirklich was sinnvolles testen.
Was sind "essentielle Verhaltenweisen"? Wenn ich nur 2-3 sicherheitsrelevante Dinge testen will, kann/muss ich das auch von Hand machen, dafür brauch ich Deine Test-Software nicht. Für alles, was die Maschienenrichtlinie betrifft gibt es eh genaue Vorschriften, wie ich was programmieren und testen MUSS.

Das ist natürlich auch richtig, ein automatischer Test des UI ist wohl prinzipiell quasi unmöglich. Allerdings sind die Fehler in der Visualisierung ja weniger tragisch als im Steuerungsablauf. Außerdem: Ein- und Ausgaben in der Visualisierung werden doch als rohe Daten mit der Steuerung kommuniziert und könnten hier, genau wie Ein- und Ausgänge, getestet werden. Wenn man denn unbedingt will.

das siehst Du falsch... Die Visu hat mittlerweile oft einen genauso großen Umfang wie das Steuerungsprogramm und Fehler dort sind genauso tödlich für die Maschine/Anlage. Das mit den Ein/Ausgaben funktioniert so auch nicht, da in der Visu auch noch Software/Scripte ablaufen etc...

Was ist denn die Intension Deiner Fragen hier? M.M. kannst Du Deine Erfahrungen mit der PC-Welt und der Logo so gut wie garnicht auf eine Industrieautomatisierung übertragen. Das siehst Du viel zu blauäugig. Das Extrapolieren funktioniert so überhaupt nicht. Aber wenigsten fragst Du ja hier.

Gruß.

 

[peter(R)]

in der Praxis dann doch im Schnitt ein nicht unwesentlicher Teil der Zeit und des Geldes (ich glaube 40% des Budgets oder sowas, habs grad nicht mehr im Kopf) für Fehlersuche und Behebung draufgeht. Ich weiß natürlich nicht wie das in der professionellen Automatisierungsindustrie aussieht

Wenn ich soviel für die Fehlersuche ausgeben muss habe ich im Vorfeld was falsch gemacht behaupte ich mal - für die Automatisierungstechnik.

peter(R)

 

[Skrjiban]

Was ist denn die Intension Deiner Fragen hier?

Ich möchte wissen, ob es sich lohnt, so etwas zu entwickeln. Ich halte es immer noch für eine Marktlücke, ist außerdem ein schönes mathematisches Thema wozu ich etliche gute Ansätze parat hätte. Nur bin ich eben nicht tief genug in der Anwender-Materie drin um zu wissen, womit die Leute tatsächlich Probleme haben und womit nicht. Sowas wird man ja fragen dürfen.

Wenn also in der SPS-Software kaum Fehler gemacht werden (was mir immer noch schleierhaft vorkommt, seid ihr Übermenschen? ), was macht den Braten denn dann fett?

Eine Industriesteuerung macht ohne Anlage oder Anlagenmodell nicht wirklich viel sinnvolles. Der ganze Programmablauf wartet ständig auf irgendwelche Signale vom Feld bzw. ist drauf angewiesen. Ohne Simulationsmodell kannst Du da nicht wirklich was sinnvolles testen.

Na das ist ja gerade der Punkt. Bei der Modellprüfung simuliere ich im Endeffekt doch ebenfalls Eingaben vom Feld. Nur wenn ich mir eine Simulation (egal ob in Software oder Hardware) baue, probiere ich _einzelne_ Fälle aus, während ich bei der formalen Verifikation _alle_ auf einmal teste, damit ich nichts vergessen oder übersehen kann. Da brauche ich kein Simulationsmodell, denn alle möglichen Fälle schließen automatisch alle möglichen Simulationsmodelle mit ein.

Der Unterschied zu PC-Programmen zu Automatisierungsaufgaben ist ja. Wenn etwas nicht tut sieht man es sofort weil der Ablauf/Bewegung nicht stimmt.

Ich glaube ehrlich gesagt nicht dass man das so festhalten kann. Wenn bei meinem PC-Programm etwas nicht passt, dann bleibt nichts stehen, sondern stürzt es eben mit Fehlermeldung ab oder zeigt Blödsinn an. Das fällt genauso auf. Und interne Variablen können doch bei einer Steuerung wie bei einer PC-Software falsche Werte haben, solange sie kurzfristig keine Auswirkungen zeigen.

Das Beispiel mit dem Ventil ist gut. Nur ich würde das nicht als SW-Test bezeichnen sondern als Fehlerabfrage. Wenn Ventil länger als 30 Sekunden offen ist: dann gib einen Fehler aus. Wenn Temperatur zu hoch: gib einen Fehler aus.

Das leuchtet ein. Was ich mich aber halt frage:

• Woher weiß ich, dass es für alle relevanten Fehlerfälle auch einen Fehlercode gibt?
• Wie kommst du auf die Logik, der den Fehlercode ausgibt? Zugegeben, sowas wie "Temperatur zu hoch" ist natürlich ziemlich simpel. Aber es kommen doch bestimmt auch mal Fehlercodes vor, deren Erkennung nicht so trivial ist. Wie prüfst du dann, ob die Erkennung des Fehlers auch fehlerfrei ist und in allen Fällen richtig funktioniert?
• Ähnlich wie Punkt 1: Wie schließt du aus, dass so ein nicht-trivialer Fehler erkannt wird, obwohl gar kein Fehler aufgetreten ist? Sowas hab ich zum Beispiel schon öfters gesehen, teilw. auch mit bösen Auswirkungen.
• Wenn mein Programm einen Fehlercode ausgibt und dann stoppt, dann verhindere ich damit natürlich schonmal dass etwas Schlimmeres passiert. Was wohl gut genug ist. Aber ich zeige doch damit im Endeffekt nur die Symptomatik an, nicht die Fehlerursache. Schon klar, häufig wirds einfach irgend ein kaputter Sensor o.ä. sein. Aber sowas wie "Ventil zu lange offen" kann doch tausend verschiedene Ursachen haben, die beim Eintreten des Fehlers dann auch wieder irgendeiner rausfinden muss.

In der Hoffnung hier nicht gefressen zu werden ,
Skrjiban

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Junge denkst du wirklich du hast das Wissen solch ein Projekt anzugehen?
Du hast keine Ahnung von Automatisierung und willst so etwas angehen?
Wenn du in der Lage bist, die Suchfunktion fehlerfrei zu nutzen, würden dir andere Beiträge zu diesem Thema in die Hände fallen.
BiG$ bezahlt Entwickler, die zumindest wissen was PLC Programmierung ist, um sich dem Thema zu nähern und es klappt noch? nicht.

Allein deine Fragestellung zeigt, dass du es nicht kannst.


bike

btw ich esse nur was mir schmeckt.

 

[Skrjiban]

btw ich esse nur was mir schmeckt.

uh, der hat gesessen

BiG$ bezahlt Entwickler, ... , um sich dem Thema zu nähern und es klappt noch? nicht.

D.h. man braucht's doch?

 

[MrSpexx]

He nicht streiten! Ich finde die Idee gut. Ich habe noch was für dich wenn der erste Link zu trocken war.

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.

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 würde dann endgültig deinen Rahmen sprengen. Für solche Fällen kannst du mit dem SPS Analyser Signale der Steuerung aufzeichnen und dir später in Ruhe anschauen und analysieren.

 

[MrSpexx]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich glaube ehrlich gesagt nicht dass man das so festhalten kann. Wenn bei meinem PC-Programm etwas nicht passt, dann bleibt nichts stehen, sondern stürzt es eben mit Fehlermeldung ab oder zeigt Blödsinn an. Das fällt genauso auf. Und interne Variablen können doch bei einer Steuerung wie bei einer PC-Software falsche Werte haben, solange sie kurzfristig keine Auswirkungen zeigen.

Ich glaube mit so einer Fehlerprüfung wird das ganze Programm viiieeel zu kompliziert. Mir ist auch nicht ganz klar was du im Kopf hast. Eine einfache Handlingsaufgabe mit ner Schrittkette? Oder was größerers? Willst du mit deiner Prüfung den Fehler nur anzeigen oder auch irgendwie darauf reagieren? Und was willst du den überhaupt für Fehler feststellen? Programmierfehler? Ausfall von HW?

Das leuchtet ein. Was ich mich aber halt frage:Woher weiß ich, dass es für alle relevanten Fehlerfälle auch einen Fehlercode gibt?

Das darfst du als Programmierer entscheiden. Keiner kennt die Anlage so gut wie du!

Wie kommst du auf die Logik, der den Fehlercode ausgibt? Zugegeben, sowas wie "Temperatur zu hoch" ist natürlich ziemlich simpel. Aber es kommen doch bestimmt auch mal Fehlercodes vor, deren Erkennung nicht so trivial ist. Wie prüfst du dann, ob die Erkennung des Fehlers auch fehlerfrei ist und in allen Fällen richtig funktioniert?

Ich würde das in einen extra Baustein reinmachen. Einer der nur abfragt und nicht steuert. Hier kannst du dann abfragen "Bin ich in Hand, dann gib keinen Fehler aus. bin ich inAutomatik dann gebe einen Fehler "Ventil offen" nach 30 Sekunden aus. Aber du sieht, dass ist Arbeit. Denn deinen Prüfcode solltest du ja auch prüfen.

Ähnlich wie Punkt 1: Wie schließt du aus, dass so ein nicht-trivialer Fehler erkannt wird, obwohl gar kein Fehler aufgetreten ist? Sowas hab ich zum Beispiel schon öfters gesehen, teilw. auch mit bösen Auswirkungen.

Du kannst verschiedene Fehlerklassen erstellen und bei wichtigen Fehlern z.B. den Automatikbetrieb stoppen.

Wenn mein Programm einen Fehlercode ausgibt und dann stoppt, dann verhindere ich damit natürlich schonmal dass etwas Schlimmeres passiert. Was wohl gut genug ist. Aber ich zeige doch damit im Endeffekt nur die Symptomatik an, nicht die Fehlerursache. Schon klar, häufig wirds einfach irgend ein kaputter Sensor o.ä. sein. Aber sowas wie "Ventil zu lange offen" kann doch tausend verschiedene Ursachen haben, die beim Eintreten des Fehlers dann auch wieder irgendeiner rausfinden muss.

Genau und das ist die viele Arbeit, die die anderen meinen!



So und jetzt hoffe ich die Zitatfunktion richtig bedient zu haben.

 

[Skrjiban]

Danke für den Link! (und den vorherigen auch, ist irgendwie untergegangen).

Morgen mehr dazu.

 

[ducati]

@MrSpexx
m.M. will der TE nicht Fehler in der Anlage erkennen sondern vorab das SPS-Programm auf Programmierfehler hin überprüfen.

Ich möchte wissen, ob es sich lohnt, so etwas zu entwickeln.

NEIN.

was macht den Braten denn dann fett?

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.

Na das ist ja gerade der Punkt. Bei der Modellprüfung simuliere ich im Endeffekt doch ebenfalls Eingaben vom Feld. Nur wenn ich mir eine Simulation (egal ob in Software oder Hardware) baue, probiere ich _einzelne_ Fälle aus, während ich bei der formalen Verifikation _alle_ auf einmal teste, damit ich nichts vergessen oder übersehen kann. Da brauche ich kein Simulationsmodell, denn alle möglichen Fälle schließen automatisch alle möglichen Simulationsmodelle mit ein.

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? Und wer definiert die "richtige Verhalten" für all diese Fälle?

Aber wie schon gesagt, zum Test von vielfach verwendeten Bibliotheken wäre sowas vielleicht denkbar. Aber dann hast Du als Kunden eben nur die vielleicht 100 Bibliotheksentwickler.

Gruß.