# Sicherheitsrelevante Software für Maschinen



## Tommi (23 Oktober 2011)

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 (23 Oktober 2011)

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 (23 Oktober 2011)

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 (23 Oktober 2011)

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 (23 Oktober 2011)

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 (24 Oktober 2011)

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 (24 Oktober 2011)

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 (24 Oktober 2011)

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 (24 Oktober 2011)

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 (25 Oktober 2011)

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 (25 Oktober 2011)

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 (25 Oktober 2011)

Andreas Koenig schrieb:


> 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 (26 Oktober 2011)

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 (26 Oktober 2011)

*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 (30 Oktober 2011)

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 (30 Oktober 2011)

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 (1 November 2011)

*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 (1 November 2011)

*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 (1 November 2011)

Safety schrieb:


> *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 (1 November 2011)

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.


----------



## hapr (1 November 2011)

Hallo Dieter,

ich gehe mit Dir konform, dass für (ich sage mal) IBN das Systemdesign und die Modulgestaltung bei Verwendung der Sicherheitssteuerungen und deren Programmiersoftware erheblich vereinfacht ist. Hier kann und muss sich der Programmierer (oder Parametrierer?) auf das Verhalten der Basis Software mit entsprechenden Verfahren für Selbsttest und Absicherung der Software Bearbeitung verlassen. Die Basis Software sollte als solches bereits zertifiziert sein.

Bei der Herstellung von Sicherheitsschaltgeräten müssen diese grundlegenden Absicherungen durch den Hersteller bei der Spezifikation, beim Systemdesign und bei der Modulgestaltung berücksichtigt werden. Auch die verwendeten Compiler und Assembler müssen verifiziert und validiert werden. Das kann zu umfangreicheren Modultests in separater Testumgebung führen.

Just my 2 cents
Harald.


----------



## Safety (1 November 2011)

Neben den erwähnten Themen von hapr besteht auch eine Forderung nach Validierung der Module und dies sollte ein Projektfremder durchführen.


----------



## Safety (1 November 2011)

Hallo hapr,
  mir geht es bei diesem Thema um die Anwender nicht um Entwickler, was nicht bedeutet die müssen das nicht beachten. Ich sehe mich als Fachberater eher auf der Anwenderseite und versuche die Normen bei der Projektumsetzung einfließen zu lassen. Also was muss ich als Anwender und Ersteller einer SRASW jetzt noch nachweisen mit einem mir schon vorgegebenen System. Ich denke auch in diesem Forum sind eher Anwender als Entwickler vertreten, oder?


----------



## hapr (1 November 2011)

Hallo,



> Neben den erwähnten Themen von hapr besteht auch eine Forderung nach  Validierung der Module und dies sollte ein Projektfremder durchführen.


Hier bin ich erst gestolpert, habe aber schnell verstanden, was Safety gemeint hat. Es sind nicht die Projektfremden, die Tommy meint (externe bzw. betriebsfremde Projektmitarbeiter). Es sind nicht am Projekt aktiv teilnehmende Personen.



> Ich denke auch in diesem Forum sind eher Anwender als Entwickler vertreten, oder?


Denke ich auch. Daher kann ich auch nur in begrenzten Umfang Hilfe geben. Aber für mich ist der Blick über den Tellerrand sehr hilfreich.

Tellerrand? Bin wech zum Essen ;-)
Harald.


----------



## Tommi (3 November 2011)

hapr schrieb:


> Hallo Tommi,
> 
> kommt darauf an, wofür Du Projektfremde brauchst.
> 
> ...



Hallo Harald,

na, hat's geschmeckt? 

Mit Projektfremden meine ich Auditoren oder Aufsichtspersonen der
Berufsgenossenschaft (nicht die von Sistema).
Denen will ich die Funktion der Software erklären können, auch
wenn sie keine Ahnung von Steuerungstechnik haben.

Deshalb will ich auch von meiner Tabelle nicht weg.
Unterstützt, das habe ich jetzt gelernt, durch Texte,
wenn dies notwendig ist.

Je weiter ich im V-Modell nach unten komme, desto mehr habe ich
zertifizierte Module und da finden dann nur noch Steuerungsfachleute
durch.

Dort prüft ein (projektfremder) SPS-Spezi mit dem Programmierer zusammen.

Gruß
Tommi


----------



## Safety (3 November 2011)

Hallo Tommi,
hier geht es um die geforderte Validierung der Software, diese Überprüfung sollte von einem nicht in diesem Projekttätigen gemacht werden.


----------



## Tommi (3 November 2011)

Hallo Dieter,

machen wir doch, habe ich mich da nicht richtig ausgedrückt?

Aber die Validierung kann immer auch noch mal auditiert oder überprüft
werden und diese Leute müssen das dann auch noch verstehen.

Gruß
Tommi


----------



## Safety (11 November 2011)

*Codierung*

Hallo, 
dann machen wir mal weiter!
Als nächstes kommt dann die 
*Codierung/Programmierung*
DIN  EN ISO 13849-1 Abschnitt 4.6.3 e

*Code der lesbar, testbar, wartbar und vor allem verständlich ist. *
Also nur das was laut Spezifikation erforderlich ist sollte hier rein. Kein schnick schnack und unnötige Zeilen. Verwenden von Symbolischen Variablen, es sollte nachvollziehbar sein wie man von der Spezifikation zum Ausgang kommt. Ich empfehle eine Trennung der SF und eine einzelne Beschreibung die dann auch wenn immer möglich einfach nachvollziehbar umgesetzt wird. 
Gebe mal einen Beispiel:
Ausgehend von der Spezifikation in Antwort 5 dieses Thema, setzt man die Anforderungen Stück für Stück in ein Programm um. Also einlesen des Schalters mit den entsprechenden Fehlererkennungen die da schon beschrieben sind, Schaltungsbeispiele und Programmierbeispiele suchen und verwenden. Der Weg zum Ausgang der dann auf die Schütze wirkt muss einfach verfolgbar sein. Auch die manuelle Rückstellfunktion, wenn möglich, bei dem Eingang und Ausgang und die Diagnose alles einfach gehalten und übersichtlich so kann man alles auch leicht verfolgen. Nicht in etlichen Funktionsbausteinen verteilt.
Aus diesem Grund ist auch eine Beschreibung der SF so wichtig, wenn man eine komplexe Maschineprogrammiert dann zerlegt man diese auch in einzelne Funktionen. 

Programmierrichtlinien die natürlich auch begründet sind, also für die Erstellung von SRASW geeignet. Die Programmierer sollten sich zusammen setzen und vereinbaren wie Sie die Spezifikation in Code umsetzen damit alle das gleiche machen. Damit wird auch die Verifizierung und Validierung vereinfacht bzw. überhaupt erst möglich. Als Vorlage kann der Anhang J der Norm dienen hier die J.4

*Defensiv Programmieren.  *
Sicheren Zustand ist 0/aus/off. Beachten von über Bus gesendeten Daten nicht Speichern, toggeln. Analoge Signal wie verhalten die sich bei Drahtbruch, Variablen begrenzen Max. Min. neg. Werte überwachen. Plausibilitätsprüfungen von Eingabe Werten usw.

*Verifikation durch Kontrol- und  Datenflussanalyse bei PLd und e*
Also bei höheren PL weitere Prüfung durch Flussdiagramme , kann man meiner Meinung bei einfachen Programmen auch Anhand eines Ausdrucks machen. 

Wie oben geschrieben wie komme ich von der Spezifikation zu der SF und wie ist es im Programm umgesetzt. Ich nehme da bei einfachem Code in KOP oder Multi-Configurator einen Ausdruck und kennzeichne den Weg der SF. Wenn es wie bei der Multi vollgraphisch ist das auch sehr einfach. Sind die Programme komplexer dann reicht das aber nicht.
 Und natürlich alles sauber ausdokumentieren.


So das war mal der für meine Begriffe wichtigste Teil bei Verwendung von schon vorgefertigten zertifizierten Systemen.


----------



## Safety (12 November 2011)

Hallo,
also man muss verstehen es geht hier um Fehlervermeidung, eine Software kann keinen PL haben aber man muss eben bei steigendem Risiko PL  auch mehr zur Fehlervermeidung machen.
Wenn man sich mit dem V-Model auseinandersetzt, wird klar warum der Einsatz von Standardsystemen so schwer ist, unabhängig ob man werte bekommt  oder auch die schwierige Frage nach CCF.


----------



## Trap (18 November 2011)

*Einsatz einer Sicherheits SPS bei der Entwicklung von Software*

Ich habe auch noch ein paar Fragen zur Softwareentwicklung von sicherheitsrelevanter Software.

Ich bin neu eingestiegen in dieses Gebiet und stehe jetzt vor der Aufgabe eine Safety Steuerung zu programmieren.

Hier im Betrieb setzen wir Bachmann M1 Steuerungssysteme ein, passend dazu gibt es das Safety
Prozessormodul SLC 284 der Firma Bachmann:
http://www.bachmann.info/produkte/sicherheitstechnik/safety-module/53/66/

Dieses Modul ist laut Datenblatt geeignet um die Anforderungen der DIN EN ISO 13849 umzusetzen. Programmiert
wird die SLC284 mit einer Entwicklungsumgebung der Firma Bachmann. Die dort verwendeten Bausteine basieren 
auf dem PLCOpen Safety V1.0 Standard. 

Ich habe die wichtigsten kapitel zur Softwareentwicklung der DIN EN ISO 13849 durchgearbeitet und auch den
BGIA-Report "Anwendung der DIN EN ISO 13849". 

Jetzt frage ich mich, welche der dort beschriebenen Anforderungen ich evtl. durch den Einsatz des oben genannten Safety 
Moduls einsparen kann bzw. ob ich die Entwicklungsschritte abkürzen kann.

Gilt eine Software, die auf einer Safety Steuerung läuft schon per Definition als sicher ?
Was muss ich noch Dokumentieren um konform zur neuen Richtlinie zu sein ? Muss ich nach dem V-Modell arbeiten ?
Muss ein Projektfremder evtl. jemand vom Tüv meine entwickelte Lösung prüfen ?

Wäre nett, wenn mich jemand erleuchten kann, da ich im Moment bei diesem Thema echt nicht mehr durchblicke.


----------



## Tommi (18 November 2011)

Hallo und willkommen im Forum,

also, mit Bachmann kenne ich mich nicht speziell aus. 

Wenn die eine Sicherheitssteuerung mit Software rausbringen,
muss die auch sicher sein. Das solltest Du Dir aber nochmal mit
Prüfzertifikaten bestätigen lassen. Nur die Angabe im Prospekt
würde mir da nicht reichen.

Die Gestaltung der Sicherheitsfunktionen nimmt Dir niemand ab,
also welcher Sensor mit welcher Logik was abschaltet und wie
das dann wieder quittiert wird. Aber das machst Du doch sowieso,
oder? Nur darf das nicht nur in Deinem Kopf passieren, sondern
Du musst es aufschreiben. 
Außerdem gibt es schon zertifizierte Bausteine (Module) z.B. für eine
Zweihandschaltung oder für die Überwachung eines zweikanaligen
Schutztürschalters oder einer Schützkombination mit Rückführkreis.
Diese Module musst Du dann wie gesagt, logisch verknüpfen und dann
auch testen, sowohl die Module, als auch die Logik.
Das V-Modell musst Du nicht zwingend anwenden, aber wenn was 
passiert und Du hast es verwendet, hast Du bessere Karten, da Du
eine Methode angewendet hast, die von anerkannten Fachleuten erarbeitet
wurde.
Du machst ja nichts weiter, als das, was Du im linken Schenkel des V
von oben nach unten geplant hast, im rechten Schenkel von unten nach
oben zu testen und zum Schluss zu validieren, also es für den Einsatz
nach einem anerkannten Verfahren freizugeben.
Ich hoffe, ich konnte ein wenig helfen.

Gruß
Tommi


----------



## Safety (18 November 2011)

Hallo,
man muss keine Normen anwenden, wenn man dann aber den zu empfehlenden Weg geht und die DIN EN ISO 13849-1 anwenden will, dann führt auch kein Weg an dem Abschnitt 4.6.1 vorbei.  
Zu Deiner Frage, wie tief man in das V-Model einsteigen muss ist abhängig von dem System welches man verwendet. Und hierzu sollte Dir der Hersteller etwas sagen können, oder du liest Dir mal dieses Thema durch.


----------



## stevanver (25 November 2011)

Hallo 

Sind gerade dabei eine Software für unsere Maschine die an einen Kunden geht zu validieren bzw. verifizieren. Meine Frage ist wie genau ist dieses alles zu dokumentieren? kann ma einfach eine Exceliste erstellen und dort die angewendeten Maßnahmen einfach aufzuführen bzw. auf Messprotokolle zu verweisen?

Freue mich über hilfreiche Antworten

Mfg Stevanver


----------



## Safety (26 November 2011)

Hallo,
was man zur Verifizierung machen muss ist in diesem Thema beschrieben, das alles muss natürlich Dokumentiert werden.
Wie tief man das V-Model anwenden muss ist sehr stark abhängig von der Sicherheitsfunktion und dem verwendeten System. Wenn man ein System verwendet das die meisten Schritte des V-Model vorgibt dann ist die Dokumentation auch entsprechend einfach.


----------



## hapr (26 November 2011)

Hallo Stevanver,

nach meinem Empfinden und meinen Erfahrungen bei Zertifizierungen ist die Wahl der Werkzeuge weitgehend frei. Alles, was ich in Listen zu packen habe, wird in Excel geführt. Dort kann ich dann nach den unterschiedlichsten Kriterien sortieren oder interne Informationen (Angaben zu anstehenden Bearbeitungsvorgängen als Beispiel) ausblenden. Sprachliche Beschreibungen führe ich dann in Word Dokumenten aus. Manchmal sagen Bilder mehr als Worte. Übersichten und Abläufe erstelle ich mit DiagramDesigner und füge die Grafiken dann in Word Dokumenten ein.

So hat jeder seine persönliche oder vom Betrieb vorgegebene Arbeitsweise für das Erstellen von Dokumenten.

Ich hoffe, die Information hilft Dir bei Deiner Entscheidung weiter.

Gruß
Harald.


----------



## Tommi (26 November 2011)

hapr schrieb:


> Übersichten und Abläufe erstelle ich mit DiagramDesigner



Hallo Harald,

meinst Du das hier?

http://logicnet.dk/DiagramDesigner/

Gruß
Tommi


----------



## hapr (27 November 2011)

Hallo Tommi,

ja, genau das ist es. Ähnliches Programm ist SmartDraw, aber das ist kostenpflichtig, wenn ich es recht in Erinnerung habe.

Ich benutze immer noch eine ältere Version vom DiagramDesigner. Soweit ich es gesehen habe, sind bei der neuen Version einige Vorlagen noch dazu gekommen.

Gruß
Harald.


----------



## stevanver (6 Dezember 2011)

Danke für die Antworten.

Das hört sich ja schon mal ganz gut an. Ist evtl jemand bereit eine kleine Vorlage seiner doku hier reinzustellen? Würde mir sehr helfen!

Mfg


----------



## Profilator (6 Dezember 2011)

Hallo zusammen,

ich kann mich dem nur anschließen, auch für mich ist die Validierung von SW noch
völlig unklar. Da kann ich mir die 13849-2 noch so oft durchlesen. 
Es wäre echt klasse, wenn wir vielleicht sogar gemeinsam hier eine Art "Checkliste" er-
arbeiten könnten mit zumindest den "Meilensteinen" was so eine Validierung beinhalten muß.

Also ich fang einfach mal an ...


Aufgabe: Gestalten und validieren einer Sicherheitsfunktion (SF)

SF1 - Abschalten von blabla... wenn  blabla... geöffnet wird.
Ausführen in "Anwendersoftware" SRASW



1 / Spezifikation der SF2 / Spezifikation der Sicherheitssoftware3 / Gestaltung der Sicherheitssoftware

4 / Validierung
4a/ Validierungsplan



so das Gerüst könnte man doch mal mit "Leben" füllen, nur zu ....


MfG

Profilator


----------



## Safety (6 Dezember 2011)

Hallo,
eine Beispielhafte Spezifikation habe ich hier schon mal beschrieben, auch Checklisten habe ich schon erstellt die aber nur eine Abfolge der DIN EN ISO 13849-1 und -2 sind, die Tabelle 2 aus der DIN EN ISO 13849-2 Anforderungen an die Dokumentation für Kategorien als Teil des Performance Levels, kann auch weiterhelfen. Wie man eine Software verifiziert wurde hier auch besprochen. Meiner Meinung nach kann man sich Checklisten für Grundlegende SF erstellen aber ohne Detailbeschreibung geht es nicht. Es ist sehr wichtig die SF genau zu beschreiben damit man diese dann auch in einer Software umsetzen kann.


----------



## Tommi (6 Dezember 2011)

Profilator schrieb:


> ich kann mich dem nur anschließen, auch für mich ist die Validierung von SW noch
> völlig unklar.



Hallo,

Du bist auf einem guten Weg!

Benutze Deinen gesunden Menschenverstand, dokumentiere den und berücksichtige
die Tipps von Safety.
Das Gerüst hast Du doch schon, der Inhalt ist abhängig von Deiner Anwendung.

Gruß
Tommi


----------



## useroo7 (9 November 2012)

Hallo zusammen,

Gestern war genau zu diesem Thema ein Workshop (Sichere Anwendungssoftware im Maschinenbau) beim VDMA (Frankfurt). Herr Professor Becker (Uni Bonn) und die IFA arbeiten derzeit an einer praktikablen Umsetzung der EN13849 und IEC62061 hinsichtlich der Software aus. Hierzu soll es voraussichtlich im Oktober 2013 ein Report geben, ähnlich wie der BGIA Report 2008. Wir bekommen noch vom VDMA einen Link zugeschickt (nächste Woche), der es ermöglicht die Präsentatioen der einzelnen Firmen, die die Workshops durchgeführt haben (Siemens, Phoenix, Pilz) herunter zu laden. Ich kann gerne den Link, sobald ich ihn habe, zur Verfügung stellen. Die derzeitig erarbeiteten Methoden, die in diesem Rahmen vorgestellt worden sind, fand ich persönlich umsetzbar, verständlich und hielt sich vom Aufwand noch in Grenzen. Wenn es bei dem vorgestellten Niveau der Dokumentation bleibt, dann hätte man endlich einen Leitfaden für die normgerechte Umsetzung der Software.

Gruß
useroo7


----------



## Profilator (10 November 2012)

Hallo,

wäre auch gern zu dem Workshop gefahren, war aber leider schon ausgebucht. Offensichtlich 
gibt es doch noch einigen Klärungsbedarf gerade zum Thema Sicherheits-Software.

Ich würde mich sehr freuen, wenn du  den Link dann zur Verfügung stellen könntest. 


MfG


----------

