Sicherheitsrelevante Software für Maschinen

Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Neben den erwähnten Themen von hapr besteht auch eine Forderung nach Validierung der Module und dies sollte ein Projektfremder durchführen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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?
 
Hallo,

Neben den erwähnten Themen von hapr besteht auch eine Forderung nach Validierung der Module und dies sollte ein Projektfremder durchführen.
Zum Vergrößern anklicken....
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?
Zum Vergrößern anklicken....
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.
 
hapr schrieb:
Hallo Tommi,

kommt darauf an, wofür Du Projektfremde brauchst.

Ist schon wieder Mittag ;-)
Harald.
Zum Vergrößern anklicken....

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
 
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
 
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
  1. 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
  1. 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.
  1. 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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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.
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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.
 
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 SF
2 / Spezifikation der Sicherheitssoftware
3 / Gestaltung der Sicherheitssoftware
4 / Validierung

4a/ Validierungsplan



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


MfG

Profilator
 
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.
 

Similar threads

I
Software Resilienz im SPS-/Produktionsbereich
14 15 16
Antworten
308
Aufrufe
20K
If-Schleife
I
M
unvollständige Maschine ja/nein ? (Leitfaden MRL)
Antworten
6
Aufrufe
8K
MasterOhh
M
P
Türzuhaltung -> Beeurteilung des Falls einer eingesperrten Person
Antworten
5
Aufrufe
5K
P51D
P
C
Strategie für die Planung von Klemmleisten
Antworten
3
Aufrufe
8K
postman78
P
B
Software für Gefährdungsanalyse / CE-Kennzeichnung
Antworten
4
Aufrufe
8K
Klopfer
K
Zurück
Oben