Sicherheitsrelevante Software für Maschinen

[Tommi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zitat von Safety vom 25.09.2011:

Diese Betrachtung der Software ist sehr interessant, aber hierzu sollten wir eventuell ein eigenes Thema eröffnen

Hallo zusammen,

ich eröffne hiermit das o.g. Thema.

neben der Hardware-Betrachtung mit Sistema muss man ja auch noch
die Software (z.B. eines PNOZmulti) validieren.
Das ist, wie auch schon gesagt wurde, viel Schreibarbeit.

Mich würde mal interessieren, wie ihr das macht:

Jeden Not-Halt, jede Schutztür und jedes Lichtgitter incl. Quittierung zu testen, ist sicherlich selbstverständlich. Hier muss man jetzt "nur" noch, vielleicht im Gegensatz zu früher, dokumentieren. Nach Norm vor und nach der Programmierung.

Aber wie weit treibt ihr das mit den Modultests?
Macht ihr wirklich mit einem Draht eine Brücke zwischen den zwei Kanälen eines Schutztürschalters oder klemmt ihr einen Draht eines Kanales ab um zu sehen, was passiert? Und das dann bei jeder Tür und jedem NOT-HALT Schalter?

Wir bei uns diskutieren gerade darüber.

Gibt es diesbezügliche Hilfen der Steuerungshersteller?

Sollen wir hier im Forum mal Checklisten erstellen?

Ich bin gespannt auf Antworten.

Gruß
Tommi

 

[Safety]

Hallo,
wir sollten mal versuchen die verschiedenen Punkte des vereinfachten V-Model durch zugehen.
Also der erste Punkt wäre die Spezifikation, aber da Du nach Funktionstests und was man alles testen muss gefragt fast. Werde ich zunächst mal hierzu meine Meinung abgegeben, also meine Interpretation dieser Norm.
Man muss zunächst mal feststellen mit welchen Systemen und Komponenten man eine Sicherheitsfunktion realisiert wird. Fangen wir mal mit der Software an, wenn man ein Zertifiziertes System verwendet also SPS, wurden die Tests wie Querschluss und Kanalfehler und so weiter alle durch geführt und auch bei einer Baumusterprüfung bestätigt. Wenn dies auf die Software bezieht, also konsequent, wenn möglich, mit Zertifizierten und geprüften Funktionsbausteinen arbeitet, dann muss ich viele Grundlegenden Tests und Versuch nicht machen da es ja im Detail schon vom Hersteller gemacht wurde und der muss auch durch entsprechende Qualitätskontrollen immer einen gleichbleibenden Stand bestätigen. Also was muss ich jetzt nachweisen. Wie komme ich zu meinem System, warum habe ich es so angeschlossen und warum habe ich diesen Funktionsbaustein ausgesucht. Also ausgehend von der Software-Spezifikation beschreiben wie ich zu allem komme, z.B. Schaltungsbeispiele vom Hersteller Datenblätter und Betriebsanleitungen konsequent umsetzten. Dann muss ich nach meiner Meinung nur noch Nachweisen das mein realer Anschluss auch stimmt. I/O Prüfungen und die Reaktionen bis hin zum messen der Spannungen am z.B. STO Eingang der Umrichter sind selbst verständlich. Anders sieht es bei selbst gestrickten Lösungen in Software wie im Hardwarebereich aus.
Aufzeigen wie man zu der Lösung kommt und nachweisen das es auch so ausgeführt reicht nach meiner Meinung, Kurschlüsse, Querschlüsse nur wenn ich den Nachweis nicht führen könnte und bei Eigenkreationen.

 

[Safety]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich konkretisiere das ganze mal, wenn ich ein Gerät wie eine zertifizierte Sicherheits-SPS kaufe muss ich davon ausgehen das die mir zugesicherten Funktionen nach dem angegeben Daten wie SIL/PL/Kategorie usw. eingehalten werden. Ich kann eventuell die Querschlusserkennung noch selbst testen aber die meisten Fehlererkennungssysteme kenne ich nicht und brauche ich auch nicht zu kennen. Also muss ich versuchen die von mir machbaren Fehler zu vermeiden.
Wenn ich z.B. einen Verriegelungsschalter mit potenzialfreien zwangsöffnenden Kontakten an die Eingänge der PNOZmulti oder Mini anschließe dann gebe ich in der Software an Eingang 1 erwartet Testtakt 0, Eingang 2 Testtakt 1, alles andere wir vom System erkannt und führt zu einem sicheren Zustand. Also was könnten wir falsch machen, einen Testtakt direkt auf den Eingang, also eine Fehlverdrahtung, würden wir erkennen bei Auslösen des Verriegelungsschalter da ein Kanalfehler entstehen würde. Bei zweimal diesen Fehler würden die Eingänge nicht auf 0-Signal gehen.
So dann sollten wir uns aber auf das V-Model stürzen.

 

[hapr]

Hallo,
im Grunde genommen hat Safety ja schon alles gesagt. Der Maschinen- oder Anlagenbauer muss bei Sicherheitsbauteilen von der Funktionalen Sicherheit ausgehen. Dafür fordert er vom Hersteller zum Beispiel die EG-Baumusterprüfbescheinigungen. Eine reine EG-Konformitätserklärung dürfte eventuell ausreichen, wenn dort auf Normen und die EG-Baumusterprüfung angegeben ist. Aber eine EG-Konformitätserklärung ohne Angaben einer EG-Bumusterprüfung darf IMHO nicht ausreichen.

Zurück zur Software:
Auch für den Maschinen- oder Anlagenbauer kann das V-Modell verwendet werden:
1.
Spezifikation, Planung Systemtest (Was muss abgesichert werden?; Wie kann ich die Absicherung prüfen?)
2.
Design, Planung Integrationstest (Was müssen einzelne Funktion erfüllen?, Wie kann ich die Funktion prüfen?)
3.
Realisierung, Planung Modultest (Codieren der Sicherheitsfunktionen, Wie kann ich alle Verzweigungswege der SW prüfen?)
4.
Durchführung der Modultests (Simulation der Eingangsinformationen und Zwischenergebnisse)
5.
Durchführung der Integrationstests (Prüfen der Komponente in einer Testumgebung oder im unvollständigem System)
6.
Durchführung Systemtest (Prüfen des kompletten Systems mit allen Beingungen)

So, schon wieder Essen fertig ;-)
Harald.

 

[Safety]

Die Sepzifikation einer Sicherheitsfuntkion ist sehr wichitg, da hier von alles ausgeht.
Leider wird in der realität meist nichts gemacht und der Programmierer muss sich das alles aus den Fingern saugen, oft wird erst bei der IB angefangen sich Gedanken zumachen sowas kann nur zu Fehlern führen. Anbei ein Beispiel wie eine Spezifikation aussehen könnte.


SF1
Erforderlicher PLr=d Realiserung in mindestens Kategorie 3
Wenn: Tür1 geöffnet
Dann: Antrieb sicherheitsgerichetet Stopp
Sicherer Zustand: Beibehaltung der sicheren Energietrennung STO bis Tür1 geschlossen und
manuelle Rückstellfunktion betätig

Beim Öffnen der Tür 1, verriegelte trennende Schutzeinrichtung mit Verriegelungsschalter PSENcs 4.2p -B1, angeschlossen an PNOZmulti Eingang-a1:IM0 Kanal 1 und Eingang –a1:IM1 Kanal 2, werden der Sicherheitsausgang -a1o0 und somit die Schütze -K1 und
-K2 abgeschaltet. Der Sensor PSENcs 4.2 entspricht PLe und Kategorie 4, Querschlusserkennung im Eingangskreis nicht nötig da Fehlererkennung im Sensor.

Antriebsmotor –M1: Stillsetzen der gefahrbringenden Bewegungen, STO - sicher abgeschaltetes Moment. Unverzügliches Abschalten STO, Stopp-Kategorie 0 nach DIN EN 60204-1.

Unter Anwendung DIN EN ISO 13855 Abschnitt 9 ist sichergestellt, dass beim Öffnen einer der verriegelten trennenden Schutzeinrichtungen kein Gefährdungsbereich erreicht werden kann, bevor die Maschinenbewegungen gestoppt sind. Die Stoppzeit ohne die Programmlaufzeit beträgt 0,4 Sekunden. Es muss sichergestellt werden, dass auch mit Programm in PNOZmuti -a1 eine maximale Stoppzeit von 0,8 Sekunden nicht überschritten wird.

Die Schütze besitzen zur Diagnose Mirrorkontakte gemäß DIN EN 60947-5-1 Anhang F (Rücklesekontakte) -K1:21/22, -K2:21/22, die in Reihe geschaltet sind; diese gehen auf PNOZmuti -a1 Eingang -a1:IM2 und müssen entsprechend in der Software ausgewertet werden.

Schutz gegen unerwarteten Wiederanlauf nach Wiederherstellung der Energieversorgung muss softwareseitig in –a1 sichergestellt werden

Die Abschaltung muss solange aufrechet erhalten bleiben, bis die Tür 1 geschlossen ist und somit dier Verriegelungsschalter PSENcs 4.2 -B1 wieder 1-Signal bringt und die Mirrorkontakte von -K1:21/22 und -K2:21/22 (Rücklesekontakte) geschlossen sind und die manuelle Rückstellfunktion mit dem Taster -S1, PNOZmuti -a1:I3, folgendermaßen betätigt wird: Darf nur erfolgen durch das Loslassen des Antriebselements in seiner betätigten (Ein)Position, negative Flanke.


Dokumente:
Datenblätter und Betriebsanleitungen mit Schaltungsbeispielen
1.1 PSENcs 4.2, Seite 0815
1.2 PNOZmulti Mini mm0.2p, Seite 0815
1.3 Schütze -K1,-K2 x.y, Seite 0815 Funkenlöschglied Seite 0819

2.1 Schaltplan:
PSENcs4.2 Seite 31
Manuelle Rückstellfunktion Seite 32
Ausgang o0 Seite 105
Schütze Seite 105 und 130

 

[Tommi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

@hapr:

nicht daß wir beim Forumstreffen 2012 20kg mehr wiegen...


@safety:

Also, ich beschreibe meine Funktionen nicht ganz so ausführlich. Meinst Du wirklich, daß das in dieser Form erforderlich ist?

Ich habe in der Softwarespezifikation des V-Modells eher an eine Tabelle gedacht:

Waagerecht die Outputs, senkrecht die Inputs und die Betriebsarten. Dann in die Zellen z.B. SS1 oder STO. (ist das verständlich?, siehe Bild)

Beschreibungen zu Quittierungen (z.B. überwachter Start) etc. in der Systemgestaltung. Ebenso z.B., daß Not-Halt immer Prio1 hat.

Beschreibung der erforderlichen Verdrahtungstests etc. in der Modulgestaltung bei ausschließlicher Verwendung bereits validierter Module.

Und das ganze dann von unten nach oben testen...

Gruß
Tommi

 

[Safety]

Hallo Tommi,
wie soll denn der Programmierer sonst wissen was er zu machen hat. Klar könnte man den einen oder anderen Satz weglassen, im Grunde muss man diese Spezifikation schon nach der Risikobeurteilung erstellen. Ein klare Angabe was und wie ist Grundvoraussetzung eine Tabelle kann die Spezifikation nicht ersetzen. Eigentlich fehlen noch Angaben von anderen Normen.
Und ich wage zu behaupten dass viele Fehler vermieden werden können wenn man diese Beschreibung genau macht.

 

[Tommi]

Hallo Dieter,

die Spezifikationen und teilweise auch die Risikobeurteilung macht bei uns, wie Du auch schon gesagt hast, der Programmierer selbst, sonst niemand.

Aus Deiner Sicht (Pilz) mag das, was Du schreibst, richtig sein.
Du hast mit allen möglichen Kunden zu tun. Wir sind "nur" ein Team im
Betrieb und da ist so eine Tabelle meiner Meinung nach übersichtlicher.

Damit kann man auch dem Laien (dem Meister vor Ort) erklären, was er
bekommt.

Alles was nicht laienverständlich ist, kommt in die Systemgestaltung des V-Modells, das ist für das allgemeine Verständnis nicht wichtig.

Gruß
Tommi

 

[Safety]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Tommi,
so eine Tabelle kann hilfreich sein wird aber bei komplexen Sicherheitsfunktionen versagen bzw. nicht ausreichen. Aber ich erlebe oft genau diese Reaktion, wenn Du die Spezifikation in einer einfachen Tabelle unterbekommst und damit dann an alles gedacht hast und der Programmierer der in Deinem Team ist das auch lesen kann reicht es. Aber lese Dir mal was bei dieser einfachen SF schon alles zu beachten ist und es ist nicht mal alles aufgeführt. Und wer macht die Validierung? Kann der auch alles aus dieser Tabelle lesen?
Das ist nur die Angabe wie die SF zu funktionieren hat, wie prüft und dokumentiert Ihr die Tabelle 2 aus DIN EN ISO 13849-2? Grundlegende und Bewährte Sicherheitsprinzipien, Einhaltung der Kategorie Anforderungen usw. ?

 

[Tommi]

Hallo Dieter,

bei der Validierung sind auch "Laien" dabei, z.B. der Meister, der
die Anlage später mal betreibt, oder die SIFA. Die müssen das
verstehen.

Alles andere, z.B. auch Deine oben zitierte Tabelle, ist dann bereits
durch die Modul- und Systemtests erledigt.

So habe ich das V-Modell verstanden.

Wie gesagt, wir sind ein kleines Team bei uns im Betrieb, wir müssen
uns nicht um den Rest des Planeten kümmern, wie Pilz und Co.

Gruß
Tommi

 

[Andreas Koenig]

also ich hab bei mir noch den PLr angegeben der erfüllt sein muss und differenziere bei Linearantrieben zwischen den Bewegungsrichtungen. Dann hab ich eine viel genutzte Spalte mit Verbalbeschreibungen für Sonderlösungen. Das Beispiel in der Tabelle ist ja einfach: Bei uns gibt es öfters komplexere Lösungen: ((Schutztür zu) ODER ((Rundtisch in einer Grundstellung) UND (Hubtüre 1 zum Arbeitsraum zu) UND (Hubtüre 2 zum Arbeitsraum zu)) UND (Roboterzelle geschossen und quittiert) UND NICHT Notaus maschinenintern) UND (NICHT Nothalt Roboterzelle))= Sperrventile Hydraulik freigeben. --> So was lässt sich in so einfachen Tabellen nicht abilden.

 

[Tommi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dann hab ich eine viel genutzte Spalte mit Verbalbeschreibungen für Sonderlösungen.

Hallo Andreas,

das stimmt, ohne sowas wird es wohl nicht gehen.

Vielen Dank für die bisherigen Wortmeldungen. :s12:

Gruß
Tommi

 

[hapr]

Hallo,

Habe in den letzten Tagen nicht viel Zeit gehabt, deshalb die späte Reaktion.

die Spezifikationen und teilweise auch die Risikobeurteilung macht bei uns, wie Du auch schon gesagt hast, der Programmierer selbst, sonst niemand.

Das kann ich so nicht unkommentiert lassen. Ich weiß, das es so die Praxis ist. Aber der Programmierer ist eigentlich der letzte in der Kette. Das bedeutet nicht, dass es bei uns anderst läuft. Die Praxis dürfte überall gleich sein.

Wenn der Programmierer ans Arbeiten für die Maschine/Anlage kommt, dann ist die Konzeptphase und die Realisationsphase für die Hardware erledigt. Hier hat sich dann schon jemand anderes Gedanken gemacht, wie die Maschine/Anlage funktionieren soll. Derjenige (oder mehrere Personen) haben sich schon Gedanken über Funktion und wahrscheinlich auch mögliche Gefahrenstellen Gedanken gemacht. Meistens fehlt es hier, die entsprechende Dokumentation auszuführen.

Der Programmierer kommt dann zur Maschine/Anlage und muss sich die Funktion denken oder hinterfragen. Damit ist es schon wahrscheinlich, dass es Abweichungen von der ursprünglich gedachten Funktionsweise und der von ihm realisierten Funktionsweise gibt. Das wird dann erst in einer Nachbesserung wieder ausgemerzt.

Und am Schluss der Realität: Ach ja, wir brauchen ja noch eine Betriebsanleitung. Natürlich erstellt die wieder der Programmierer. Schließlich hat er die auszuführende Funktion realisiert. Nur kennt er die Überlegungen von Konstruktion und Hardware Entwicklung nicht. Damit fehlen dann entsprechende Angaben/Sicherheitshinweise in der Betriebsanleitung.

Fazit:
1.
Meistens fehlen Zuständigkeiten für Dokumentationen in den einzelnen Phasen. Die werden dann zu einem späteren Zeitpunkt von anderen (nicht ausreichend informierten) Personen nachgeführt.
2.
Das V-Modell bezieht sich nicht nur auf die Software. Es lässt sich auf die gesamte Entwicklung der Maschine/Anlage verwenden.

@Tommi
Auch wir sind ein kleines Team. Geht es um die Dokumentation, dann stehe ich überwiegend alleine da. Meistens interessiert sich keiner für die Dokumente, sind ja für den TÜV ;-) . Ich gehe von aus, das es bei größeren Teams noch chaotischer wird, wenn dort keine vernünftige Vorgehensweise festgeschrieben ist.

Harald.

 

[Andreas Koenig]

Betriebsanleitungen

Wir haben den Luxus bei >100 (+ diverse Externe) Leuten in der Abteilung jemand zu haben, der sich nur um CE/Maschinensicherheit/Risikoanalysen/Schreiben & Übersetzen der Betriebsanleitungen kümmert (=ich) Das ist bei ca. verschiedensten 1200 Sondermaschinen vom Keinkram bis zur Montagelinie in einem Zeitraum von 15 Jahren jedoch auch eine Menge Arbeit.

Andererseits kann man nur so die nötige Routine und Erfahrung sammeln, die man in dem Job einfach braucht. Ich kenne alle Maschinen die wir in den letzten Jahren gebaut haben und alle Sicherheitslösungen, die wir in den letzten Jahren eingesetzt haben und da kann man aus Analogieschlüssen schnell entscheiden. Und vor allem kann ich mit den anderen Mitarbeitern die Prozesse beeinflussen. Z.B. wenn ich nur noch 3 Typen Bedienschnittstellen (PC, Touch-Panel, OP77) mit ziemlich standardisierter Oberfläche nehme, kann ich große Teile der Betriebsanleitung schon mal zusammenkopieren. Gleiches gilt für die Sicherheitslösungen und Mechanik.

Natürlich haben wir es auch mit Outsourcen versucht.
1) ein langjähriger Externer für die BA, der bestimmt >70% für uns gearbeitet hat: hatte Routine, Preis ok --> leider in Rente
2) ein externer Programmierer: haben wir quasi genötigt auch BA/GFA zu machen --> ging in die Hose, ausser dem auf Software bezogenen Teil mittelmäßige bis unzureichende Anleitungen, sicherheitstechn. Fachkunde nahe 0.
3.1. Externe Firma "A": beschäftigt sich professionell mit dem Erstellen von Anleitungen, hatten einen Mitarbeiter vor Ort wohnen: Preis ging so la la, bestanden auf ihrem eigenen Standard zur Erstellung von BA, lehnten es ab, nach unserem Werksstandard zu arbeiten --> K.O., der betreffende MA war nicht grad schnell, eher ein "Redakteur/Schreiber", zu wenig technischer Sachverstand.
3.2. Externe Firma "B": ein Ingenieurbüro mit <5 MA aus dem "Osten": Preis günstig, Leistung fachlich unbrauchbar, nach dem ersten, äusserst mangelhaft ausgeführten Auftrag und "aussergerichtlicher Einigung" wurde der Lieferant gesperrt, keine weiteren Kontakte
3.3. Externe Firma "C", professioneller Anbieter von technischen Dokus: machen fachlich einen kompetenten Eindruck. Die Anleitungen, die sie für uns gemacht haben, waren von der Aufmachung recht gut, vom Inhalt auch ok, ABER: Der Preis war erst mal deutlich höher, als das was ich selbst investiere. Ich musste aber weiter ca. 1/3 der sonst benötigten Zeit für Informationsbeschaffung, Begleitung des ext. Mitarbeiters, Prüfung etc. aufbringen. Büro 150 km weg, MA kann also für den Preis nur 2 mal für eine Maschine kommen.
4. Eigene Konstrukteure oder Programmierer: haben so viel um die Ohren mit ihren Projekten, dass eigentlich von vorn herein nichts gescheites kommen kann, auch wenn sie willig sind.

Sicher sind die Verhältnisse bei einem Serienhersteller nicht ganz so verschärft als bei Sondermaschinen....

Dem Kleinbetrieb wird nichts anderes übrig bleiben, als jemand "nebenbei" damit zu beschäftigen.

 

[Safety]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
es ist ein großer Irrglaube, dass ein externer allein und ohne Mitwirkung von den Konstrukteuren eine Risikobeurteilung und ein Sicherheitskonzept erstellen kann. Es ist eine Teamarbeit, ein externer Experte ist für viele Bereiche des Maschinenbaus eine gute Lösung. Der dann die Daten zusammenfasst und Lösungsvorschläge macht und dann die Dokumentation erstellen aber immer in Zusammenarbeit des Teams. Und ob man mit zwei Besuchen sowas hinbekommt ist abhängig von der Komplexität der Maschine.



Ich denke nicht das es bei Andreas so war oder ist aber mann könnte der Meinung sein.

 

[Andreas Koenig]

Doch, die Tendenz ging eigentlich immer in die Richtung, nöglichst wenig vor Ort zu sein: Wenn der Externe 2+ 300 km fährt, macht das schon mal ganz grob mindestend 200€ Sprit und 450-500 € Arbeitskosten = 650-750€ nur für die Fahrtstrecke. Dafür hab ich schon einen ganzen Tag gearbeitet. So, jetzt laufe ich 2 halbe Tage mit dem Externen herum = noch mal >800€ jeweils für mich und den Externen. Da ist aber noch nichts als Notizen aufgeschrieben.

Aber wie ich schon geschrieben hab, kann man mit einem Kleinstbetrieb nur selten jemand der sich speziell um Sicherheitsfragen kümmern und da ist es allemal besser sich jemand externes zu nehmen, als im eigenen Saft zu schmoren und mangels Erfahrung die eigenen Fehler nicht mal zu erkennen. Bei Serien- und Massenfertigern sieht die Situation auch anders aus, da da ja meist eine Produktserie langfristig gefertigt und fortentwickelt wird. Im Sondermaschinengeschäft wo ich arbeite sieht es deutlich anders aus. Da hast Du nicht viel Zeit zum analysieren, du musst in der Lage sein, für eine Angebotserstellung innerhalb von Minuten zu vor allem aus Erfahrung erfassen, wie die Risiken sind und was das für Auswirkungen auf die Grobkalkulation hat. Geht nur mit viel Standardisiererung: wenn man immer Umrichter PL=d einsetz, brauch man nur überlegen, brauch ich da einen PL=e, brauch ich eine Lizenz für Sonderfunktionen wie sichere Geschwindigkeit, ferner hab ich C-normen einzuhalten, kann ich Probleme mit Anhang VI-Maschinen bekommen....
Was hier falsch kalkuliert ist, macht nacher Probleme.
Beim konstruktiven und Steuerungsentwurf muss man möglichst immer begleitend dabei sein, an Durchsprachen teilnehmen, schauen ob die gefundenen Lösungen so ok sind und schon da Risikoanalyse und Betriebsanleitung teilerstellen, beim Bau der Maschine muss man regelmäßig vor Ort sein, um mit den Schlossern z.B. nicht konstruktiv festgelegte Schutzeinrichtungen zu besprechen und bei auftretenden Problemen sofort Maßnahmen einzuleiten. Bei der Abnahme ist es zu spät, dann steht meist schon der LKW oder Flieger bereit.
Dann hab ich auch im Werk noch einen anderen internen Experten in der Instandhaltung und interne Spezialisten für Pressen etc. Externe Experten für mich unter meinen Bedingungen machen nur für Sonderfälle wie Ex-Schutz Sinn. Gruss Andreas

 

[Safety]

Systemgestaltung

Hallo,
ich denke es ist an der Zeit hier weiter zumachen.
Also die Softwarespezifikation hat nun schon einiges an Diskussionen ausgelöst, dann kommen wir mal zu den nächsten Punkten.

Systemdesign:
Hier geht es um das Software-Werkzeug, Funktionsbibliotheken, Programmiersprachen.
Software Werkzeug:
Es soll eine Software benutzt werden die einer Sicherheitsnorm entspricht, hier kann nur die IEC 61508-3 genommen werden bzw. Teile der DIN EN ISO 13849-1.
Unbefugtes modifizieren von Parametern verhindern:
Passwortschutz beim Download, Löschen, besonderen Funktionen der Software
Architektur/Struktur:
Aufbau nach dem drei Stufenmodel Eingabe-Bearbeitung-Ausgabe
Programmiersprache:
Anwendung einer LVL-Teilmenge einer IEC 61131-3 Sprache z.B. KOP-FUP empfohlen.
Einsatz von validierten/ zertifizierten Funktionsbausteinen
Siehe hierzu DIN EN ISO 13849-1 Abschnitt 4.6.3,b
Wenn man eine Zertifizierte Sicherheits-SPS benutzt und die dazugehörige Software, wie
z.B. PNOZmulti und den PNOZmulti Configurator dann ist da nicht mehr viel zumachen.
Denke jetzt erkennt man auch warum der Einsatz einer Standard-SPS hier schon scheitert.

 

[Safety]

Zuviel Werbung?
-> Hier kostenlos registrieren

Modulgestalltung

Modulgestaltung:
Es geht hier um Softwaremodule, eigen erstellt Funktionsbausteine.
Semiformale Verfahren zur Beschreibung von Daten und Kontrollfluss:
Funktionsbeschreibung, Design- und E/A Matrix, Kontrollflussdiagramme
Modulare, Strukturierte Programmierung:
Struktur E/B/A, Konsequente Anwendung von zertifizierten Funktionsbausteinen, Symbolische selbsterklärende Variablenbezeichnungen, keine schnick schnack in der Software nur das was man braucht.
Beherrschung von Fehlerquellen:
Verwendung von Methoden zur Erkennung von Externen Fehlern, Kanalfehler, Querschlüsse, Parametereingrenzen, Min. Max. Neg. Pos. usw.
Dokumentation:
Detail Kommentierung, auch Projektfremde müssen verstehe was da gemacht wurde.

 

[Tommi]

Dokumentation:
Detail Kommentierung, auch Projektfremde müssen verstehe was da gemacht wurde.

Hallo Dieter,

danke für Deine Ausführungen.

Müssen Projektfremde nicht eher die Spezifikation verstehen, statt
die Modulgestaltung?

Gruß
Tommi

 

[hapr]

Hallo Tommi,

kommt darauf an, wofür Du Projektfremde brauchst.

Für die Realisierung: dann müssen sie die Module ausreichend kommentieren, damit andere (für die Wartung, Erweiterung, Anpassung) die Wirkweise bestmöglichst verstehen können. Dann stimmt Deine Aussage, dass sie die Spezifikation verstehen müssen.

Für Wartung, Erweiterung, Anpassung: dann müssen ausreichend Kommentatre bei den Modulen sein, damit sie bestmöglichst die erforderliche Bearbeitung ausführen können. Die Spezifikation sollten sie trotzdem verstehen, um den Änderungsumfang besser einschätzen zu können.

Anwendung im Schadensfall: Ich könnte mir vorstellen, dass die Nachvollziehbarkeit besser auszuführen ist, wenn nach einem Schadensfall entsprechende Stellen die Herausgabe der technischen Unterlagen zur Prüfung verlangen.

Ist schon wieder Mittag ;-)
Harald.