# Validierung Sicherheits-SPS (F-CPU)



## Blockmove (27 November 2013)

Auf Wunsch unserer Instandhalthaltung sollen neue Anlagen / Fertigungslinien vermehrt mit F-CPUs und Profisafe ausgerüstet werden.
Es handt sich dabei nicht um überwachungspflichtige Anlagen, sondern um Standard-Fördertechnik und "normale" Sondermaschinen".

Ich bin gerade dabei mir die Validierung genauer anzuschauen und bin dabei auf verschiedene Ansichten, Meinungen und Vorgehensweisen gestossen:


Normaler Funktionstest genügt ... F-CPU ist nix anderes als z.B. ein PNOZmulti.
Validierung und Funktionstest erfolgt durch einen Kollegen, der nicht am Projekt beteiligt ist und somit unvoreingenommen ist
Validierung erfolgt im Zuge der Abnahme zusammen mit der Sicherheitsfachkraft des Kunden bzw. der Fachabteilung des Kunden
Egal ob die Anlage überwachungspflichtig ist oder nicht, die Validierung erfolgt durch TÜV, Dekra oder sonstigen externen Sachverständigen

Wie führt ihr die Validierung durch?

Gruß
Dieter


----------



## Sinix (27 November 2013)

Hi,

eine Validierung durch den TÜV für jede einzelne unserer Sondermaschinen würde diese für die Kunden unbezahlbar machen.
Zum einen halten wir uns an die geltende Maschinenrichtlinie und die Anwendung der Normen beim Erstellen des Sicherheitskonzeptes.
Dazu gehört natürlich auch eine Risikoanalyse und Bewertung, bei der in schwierigen Fällen ein zertifizierter Sachverständiger (oder TÜV)
hinzugezogen wird.

Die Validierung der F-CPU würde ich ganz klar mit dem PNOZMulti gleichsetzen, da beides Sicherheits-Steuerungen sind.

Die Abnahme der F-CPU ist in Kapitel 11 der Betriebsanleitung beschrieben. Ich habe mir dafür eine Checkliste erstellt,
die ich am Ende der Inbetriebnahme durchgehe und als Dokument zu den Ausdrucken des Sicherheitsprogrammes ablege.

Allerdings steht dort auch: 





> Die Abnahme eines F-Systems wird in der Regel von einem unabhängigen
> Sachverständigen durchgeführt.


 Dies habe ich in der Vergangenheit nicht gemacht, sondern lasse
meinen Kollegen kontrollieren. 

Würde mich auch mal interessieren wie die anderen user das handhaben.


MfG


----------



## Blockmove (27 November 2013)

Sinix schrieb:


> Die Validierung der F-CPU würde ich ganz klar mit dem PNOZMulti gleichsetzen, da beides Sicherheits-Steuerungen sind.
> 
> Die Abnahme der F-CPU ist in Kapitel 11 der Betriebsanleitung beschrieben. Ich habe mir dafür eine Checkliste erstellt,
> die ich am Ende der Inbetriebnahme durchgehe und als Dokument zu den Ausdrucken des Sicherheitsprogrammes ablege.
> ...



Ein PNOZmulti ist lt. Herstellerdefinition *keine* Sicherheits-SPS. Es ist ein konfigurierbares Schaltgerät.
Deshalb ist hier die Validierung einfacher ... Auch wenn die Funktionalität nahezu gleich ist.

Der von dir zitierte Satz


> Die Abnahme eines F-Systems wird in der Regel von einem unabhängigen
> Sachverständigen durchgeführt.


ist für mich auch der Grund zu dieser Umfrage.
Wenn im Handbuch des Herstellers sowas steht und ich mich nicht daran halte, dann muss ich gut begründen können warum ich mich nicht daran halte.
Wie sieht hier eine "rechtssichere" Begründung aus?

Gruß
Dieter


----------



## Sinix (27 November 2013)

Hallo Dieter,



Blockmove schrieb:


> Wenn im Handbuch des Herstellers sowas steht und ich mich nicht daran halte, dann muss ich gut begründen können warum ich mich nicht daran halte.
> Wie sieht hier eine "rechtssichere" Begründung aus?



Die DIN EN ISO 13849-2 (Validierung) gibt unter Abschnitt 4.1 darüber folgende Auskunft:



> Die Validierung sollte von Personen durchgeführt werden, die unabhängig von der Gestaltung der SRP/CS sind.
> 
> Anmerkung: "Unabhängige Person" bedeutet nicht unbedingt, dass eine Prüfung durch Dritte erforderlich ist



*sollte* ist nicht *muss* 
*Person* ist nicht *Sachverständiger*

Angaben zur Validierung der sicherheitsbezogenen Software (zu der m.M. auch das PNOZMulti-Projekt zählt) ist in der DIN EN ISO 13849-2 Kapitel 9.5 beschrieben.
(Hab leider nur Papierform hier, sonst würd ichs der Vollständigkeit halber posten).

MfG


----------



## Blockmove (27 November 2013)

@Sinix

Das Thema Validierung (V-Modell) aus der 13849-2 kenne ich auch.
Nur geht hier das Siemens-Handbuch über die Norm hinaus.
Wir haben demnächst die Siemens Fachberatung im Haus und da will ich eine verbindliche Stellungsnahme zu diesem Punkt

Gruß
Dieter


----------



## Matze001 (27 November 2013)

Bei uns ist es so das unser Projektleiter die Funktion der Sicherheitseinrichten bei der internen Vorabnahme im Haus überprüft.

Grüße

Marcel


----------



## Blockmove (28 November 2013)

Matze001 schrieb:


> Bei uns ist es so das unser Projektleiter die Funktion der Sicherheitseinrichten bei der internen Vorabnahme im Haus überprüft.



Bei manchen ist ja damit die Forderung nach Projektfremden Mitarbeiter erfüllt 


Gruß
Dieter


----------



## Matze001 (28 November 2013)

Blockmove schrieb:


> Bei manchen ist ja damit die Forderung nach Projektfremden Mitarbeiter erfüllt
> 
> 
> Gruß
> Dieter



Es wird folgendermaßen Argumentiert:

Ein gewisses Wissen über die Anlage und ihre Funktion sollte gegeben sein um die Funktion und Ausführung der Sicherheitsfunktionen bewerten zu können.
Ich kann zwar auch unsere Azubine ausm Büro die Not-Halt-Schalter drücken lassen, die Türschalter betätigen, etc pp... aber was bringt mir das?

Grüße

Marcel


----------



## bike (28 November 2013)

Zunächst wird bei uns eine Aufstellung gemacht, welche Komponenten sicherheitsrelevant sind und wie reagiert werden muss, damit nichts passiert.
Dann schreibt ein Programmierer das F-Programm.
Bei der IB werden die Funktionen ausgetestet.
 Wenn fertig, wird die Aufstellung von einem Inbetriebnehmer hergenommen und es wird Schritt für Schritt die Sicherheit nach den Vorgaben geprüft.
Für die Aufstellung gibt es vorgegebene Tabellen, die nach Prüfung abgehakt werden.

@Dieter. überfordere die Jungs von BigS nicht. Die werden bzw können sich nur auf deren Vorgaben herausreden.


bike


----------



## Larry Laffer (28 November 2013)

bike schrieb:


> @Dieter. überfordere die Jungs von BigS nicht. Die werden bzw können sich nur auf deren Vorgaben herausreden.



Das sehe ich auch so ...
BigS kann ja nicht pauschal eine Absolution für einen Vorgehensweise geben - du könntest die dann schluss-endlich dann auch darauf festnageln. Wenn die aber die Messlatte sehr hoch gelegt haben dann sind die damit aus dem Schneider. Egal, was du machst - du bleibst wahrscheinlich ja "unter" der definierten Forderung von S. und bist dann somit verantwortlich.

Wir handhaben das auch so in etwa, wie Bike. Zusätzlich wird bei uns noch die Signatur des F-Programms mit dokumentiert.

Gruß
Larry


----------



## Aventinus (28 November 2013)

Bei uns läuft´s ähnlich.


----------



## Blockmove (28 November 2013)

Heute war Siemens zum Thema Safety im Haus.
Wir haben den Berater zum Thema Abnahme F-CPU und diesem Satz:



> Die Abnahme eines F-Systems wird in der Regel von einem unabhängigen
> Sachverständigen durchgeführt.



aus dem Handbuch "befragt".

Wir haben dazu folgende Aussage bekommen:

Es gilt die Validierung / Abnahme nach der jeweiligen Norm. Ein externer Sachverständiger ist nicht unbedingt notwendig.
Der oben zitierte Satz ist nur im Handbuch zu Dristibuted Safety zu finden und in keinem weiteren Manual.
Auf den Siemens Kursen und Schulungen ist auch keine Rede von einer Abnahme durch externe Sachverständige bei nicht überwachungspflichtigen Anlagen.

Unsere Frage warum dann dieser Satz nicht einfach aus dem Handbuch gestrichen wird, wurde - sagen wir einfach mal - nicht zufriedenstellend beantwortet.
Letzlich geht es wohl in die Richtung wie bike und Larry es schreiben 

Fazit:
http://www.youtube.com/watch?v=3L8aFkOXjb8

Gruß
Dieter


----------



## Sinix (29 November 2013)

Wundert mich garnicht, hab auch schon andere Fehler in Siemens-Handbüchern/online-Hilfen gefunden. :sm14:


----------



## Blockmove (29 November 2013)

Sinix schrieb:


> Wundert mich garnicht, hab auch schon andere Fehler in Siemens-Handbüchern/online-Hilfen gefunden. :sm14:



Ist halt bei Sicherheitsthemen etwas ärgerlicher als sonst.
Da hat das Handbuch ja eher schon den Status einer Urkunde.

Und Siemens schreibt auch noch "Sachverständiger" und nicht "Sachkundiger".

Gruß
Dieter


----------



## Larry Laffer (29 November 2013)

@Dieter:
ich bin sowieso überrascht, dass die sich überhaupt in irgendeiner Art und Weise dazu geäußert haben.
Naja ... wie auch immer ...

Gruß
Larry


----------



## Safety (29 November 2013)

Hallo,
die Software Verifizierung und auch Validierung ist nur ein Teilprozess bei der Erstellung von Sicherheitsfunktionen, das ist erst mal sehr wichtig. Der Aufbau, Komponenten, Werkzeuge und Komplexität sind entscheidend über die Vorgehensweise.

Um diesen Teilprozess ausführen zu können muss die aus der Risikobeurteilung kommende Anforderung der Sicherheitsfunktion vorhanden sein.
Also muss die Sicherheitsfunktion identifiziert und die Anforderungen definiert werden.

Dann muss man den PLr definieren und sucht dann die entsprechende Struktur, Kategorie, überlegt und dokumentiert wie man die Anforderungen der Kategorie einhalten kann, auch an den Teil 2 der 13849  denken.

Jetzt müssen die weiteren Parameter überlegt angegangen werden, Werte wie PFHd, MTTFd, DC ermitteln. Bei entsprechendem PL und Kategorie ist besonders wichtig, was muss ich machen um einen bestimmten DC zu erreichen. Denn dies wird ja dann oft mit der Software gemacht. Der Programmierer muss das wissen, einer der von mir am häufigsten vorgefundenen Fehler.

Die Externen Fehler müssen beherrscht werden, dies wird auch bei der Softwareerstellung verlangt, kann man aber auch hierbei schon betrachten und macht auch Sinn.
Eine Software kann keinen PL haben, hier geht es bei steigendem PL um Fehlervermeidung. Wie kann man dies machen, durch erhöhten Aufwand bei den Prüfungen und Dokumentation.

Wenn das alles Mal überlegt ist muss man die Softwarespezifikation erstellen. Bei einfachen Sicherheitsfunktionen kann man dies schon mit der Identifikation und Anwendungsdokumentation erstellen. Da können auch schon die Hardware Struktur E/A Ebene mit eingebaut werden.
Jetzt ist die Auswahl der Softwarewerkezeuge und ob man Zertifizierte Funktionen verwenden kann sehr wichtig welchen Umfang das ganze annehmen muss.

Bei einem Softwarewerkzeug welches umfangreiche Fehler zu lässt und bei dem man nicht nach Norm geführt wird werden jetzt Datenflussdiagramme und umfangreiche Dokumentationen gefordert. Bei einem System welches einfaches Nachvollziehen der Sicherheitsfunktionen zulässt kann man dies sehr einfach mit einem Ausdruck durchführen, wichtig ist das die Sicherheitsfunktion mit allen Anforderungen erkennbar ist. Also unter alle Umständen Spagetticode vermeiden.

Keine eigenen Module immer zertifizierte Funktionen, Trennung von Safety und Nonsafety Code.

Dann erstellt man einen Validierungsplan, ein Teil davon ist die Softwarevalidierung. Hier werden auch gleich die Testszenarien erstellt.
Alles Dokumentieren, dann hat es der Validierer  einfacher, am besten hat sich nach meinen Erfahrungen dann ein Vieraugenprinzip bewährt. Der Ersteller erklärt anhand der Dokumentation die einzelnen Sicherheitsfunktionen.

Funktionstest sind dann auch der reale Nachweise dass die Anforderungen erfüllt sind, falls da Änderungen notwendig sind muss man an den entsprechenden Punkt zurück springen.

E/A Test wie man das von „Standard Anwendungen“ kennt sind natürlich immer notwendig.
Aber natürlich mit entsprechender Vorsicht!

Bei der Software wird man zunächst bei offenen System Testen ob es auch funktioniert dann zur Validierungsabschluss eine Blackbox Test.
Auch hier ist entscheiden wie komplex das System und/oder die Sicherheitsfunktion ist.


*ACHTUNG KÖNNTE ALS WERBUNG VERSTANDEN WERDEN!!!!!!!!!!!*

Zur PNOZmulti, auch hier muss man verifizieren und validieren, aber es handelt sich um ein System das einem führt und eine einfache Validierung zulässt. Vollgraphische Programmierung einfaches Nachvollziehen der Datenstruktur durch verfolgen der Verbindungslinien und Verwendung von zertifizierten Funktionsbausteine die man nur noch Parametrisieren muss. Bewerten wie sich die Logikelemente verhalten. Aber dazu gehört auch eine Erklärung der Funktionen, die auf der Anforderung beruht.

Wenn man durchgängig zertifizierte Komponenten einsetzen kann wird das dann nochmal einfacher. Geh aber nicht immer.
Bin zurzeit mit Kollegen damit beschäftigt zu diesem Thema eine Vorgehensweise bei der PNOZmulti zu erstellen dies wird dann 2014 in vielen Vorträgen in ganz Deutschland präsentiert.


----------



## Klopfer (29 November 2013)

Safety schrieb:


> Bin zurzeit mit Kollegen damit beschäftigt zu diesem Thema eine Vorgehensweise bei der PNOZmulti zu erstellen dies wird dann 2014 in vielen Vorträgen in ganz Deutschland präsentiert.



Hallo Safety,

wenn das so weit ist, dann lass doch mal Termine hören (gerne auch per PM falls das als unerlaubte Werbung gelten sollte).

Gruß

Klopfer


----------



## Blockmove (29 November 2013)

@Safety

Du erwähnst hier das 4-Augen-Prinzip. Bei Siemens war mir nicht klar wer das zweite Augenpaar sein soll / muss.
Deshalb hab ich diesen Thread gestartet.

Aus gegebenen Anlass möchte ich hier mal der Werbung für PNOZmulti widersprechen.
Wir haben eine Anlage bei der z.B. für Steuerung-Ein und die Quittierung von Schutztüren kein überwachter Start verwendet wird.
Es wurde eine Art Logik aus UND, ODER, SR zusammengeflickt. Nur passt es halt hinten und vorne nicht.

PNOZmulti und all die anderen sogenannten konfigurierbaren Schaltgeräte sind für mich ehrlich gesagt irgendwie nur Tricksen der Hersteller mit den ungenauen Formulierungen in den Normen.
Eine F-CPU kann ich auch nur grafisch programmieren und ich hab genauso zertifizierte Funktionsblöcke. Die Hardwarekonfig hinsichtlich Querschlussüberwachung, Taktung, Ansprechzeiten ist auch vergleichbar. Früher hab ich bei bei einfachen Vorrichtungen (4 bis 5 Zylinder) eine Logo zur Steuerung verwendet. Heute "konfiguriere" ich meine Schrittkette in einem PNOmulti 

So wie es aussieht wird 2014 das Jahr der Validierung.
Ihr arbeitet an Vorträgen, vom TÜV kam neulich ein Schulungsangebot, SiTrain wil auch was machen 

Gruß
Dieter


----------



## Safety (30 November 2013)

Hallo Dieter,
ich habe nie gesagt dass wir bei dem System nicht validieren müssen, es ist durch das Werkzeug und die Programmiersprache nur einfacher. Es geht mir auch darum einfache Strukturen zu programmieren, dann kann das jeder leicht nachvollziehen. Die von Dir beschriebenen Fehler müssen schon beim Vieraugenprinzip und den Funktionstests auffallen.
Zum Vieraugenprinzip es geht doch um Fehlervermeidung und wenn jemand das Ganze mit erstellt hat dann ist er Betriebsblind. Also es müssen keine Externen Prüfer sein, einfach jemand der versteht was da gemacht wurde und auch die Fehler erkennen könnte. Das ist eine Norm, wes geht darum Fehler in der Sicherheitsfunktion zu finden das ist das Ziel.


----------



## Blockmove (30 November 2013)

@Safety

Wenn ich mich schon mit Kollegen von anderen Firmen unterhalten habe, dann hat eigentlich keiner ein PNOZmulti oder ein 3RK3 nach dem 4-Augenprinzip validiert.
Begründet wurde das damit, dass man ja sowieso nur vorgefertigte geprüfte Elemente verschaltet. Es ist der gleiche Vorgang wie beim Erstellen eines Hardwareplans mit Sicherheitsrelais.
Fehler tauchen beim Funktionstest auf.

In letzter stell ich aber fest, dass immer öfter auf Validierung hingewiesen wird.
Findet ein Umdenken in der Branche statt oder hat die BG einen mahnenden Finger gehoben?

Gruß
Dieter


----------



## bike (30 November 2013)

Blockmove schrieb:


> So wie es aussieht wird 2014 das Jahr der Validierung.
> Ihr arbeitet an Vorträgen, vom TÜV kam neulich ein Schulungsangebot, SiTrain wil auch was machen



Du schreibst genau das, das ich auch schon bemängelt habe.
Die Hersteller schreiben und damit keiner mehr selber denken muss, wird das einfach als Gesetz oder Vorschrift übernommen.
Mir hat noch kein Hersteller erklärt, warum die Vorschriften so oft geändert werden müssen.

Daher haben wir uns einen eigenen Reim darauf gemacht:
Man muss täglich ändern, damit die Maschinenbauer nicht mehr durchblicken und dann die teuren Kurse buchen und sie die unnötigen, überteuerten  "sicheren Komponenten" kaufen.
Ich habe noch nie gehört, dass ein "Sicherheitsberater" erklärt hat, die eine oder andere Sicherheitsfunktion nicht notwendig sei und als Standardkomponenten ausreichend seien.
Da wird nur erklärt mehr ist besser.

Wir haben da eine relativ gute Ausgangsstellung, da wir unsere eigenen Fachleute haben.
Doch was macht ein kleiner Maschinen- und Anlagenbauer?


bike


----------



## Blockmove (30 November 2013)

bike schrieb:


> Du schreibst genau das, das ich auch schon bemängelt habe.
> Die Hersteller schreiben und damit keiner mehr selber denken muss, wird das einfach als Gesetz oder Vorschrift übernommen.
> Mir hat noch kein Hersteller erklärt, warum die Vorschriften so oft geändert werden müssen.
> 
> ...



Ich wiederspreche dir jetzt mal dahingehend, dass die Vorschriften sich häufig ändern.
Die Versionen und Änderungen lassen sich schon nachvollziehen und sind eigentlich nicht allzu häufig.
Richtig große Änderungen sind schon geraume Zeit her.

Aber:
Was sich sehr häufig ändert, ist die Auslegung der Hersteller und vorallem der sogenannten unabhängigen Berater.
Manchmal kommt mir das vor wie bei Bibel und Koran. Da gibt es im Umfeld auch unzählige Glaubensrichtungen und Sekten.
Und alle begründen die Richtigkeit ihres Handeln mit der Bibel oder dem Koran.

Bei den Firmen bzw. deren Fachleuten / Vertrieblern gibt es schon Unterschiede.
Hier muss ich mal dem Arbeitgeber von Safety ein Lob aussprechen. Da war die Beratung eigentlich immer sehr problemorientert.
Es gbt aber auch andere ... Da willst du eigentlich nach der "Beratung" zum Arbeitsamt gehen und eine Umschulung zum Rosenzüchter beantragen.

Gruß
Dieter


----------



## Safety (30 November 2013)

Hallo Dieter,
zur Frage ob da ein Umdenken stattfindet, denke da die Anwendungen mit Programmierung stark zugenommen haben wird das eben zum Thema.
Habe schon viele Fehler in Software gefunden, meist bei der Fehlererkennung und Startverhalten.
Nur nebenbei, ich habe von 4 Jahren ein Seminar mit einem Kollegen  zu dem Thema erstellt, da war das alles auch schon Thema nur hat es eben wenige interessiert.
Zu dem Thema Kundenberatung, meine unsere Kunden sind intelligente Konstrukteure die hochkomplexe Systeme beherrschen müssen, wir sind immer wieder bei den Kunden und das Unternehmen lebt vom Verkauf von Produkten. Denkt Ihr wirklich das man über Jahre und Jahrzehnte da jemand, sagen wir es mal vorsichtig die Unwahrheit sagen kann, denkt Ihr die merken das nicht.
Zur Beratung, hat Dieter schon gesagt wie wir vorgehen. Nur so kann man langfristig mit Kunden zusammenarbeiten.


----------



## Blockmove (30 November 2013)

@Safety
Ich hab im Büro gerade letzte Woche 3 Handbücher genauer angeschaut:
Siemens Distributed Safety, Pilz PSS4000 und Pilz PNOZmulti.

Wenn ich mir anschaue welchen Umfang bei den Sicherheits-SPSen die Kapitel Planung und Inbetriebnahme haben und ich mir dazu die Unterlagen zu PNOZmulti anschaue, dann stelle ich mir schon die Frage ob das so passt. Besonders wenn man den Funktionsumfang anschaut.

Gruß
Dieter

PS: Dandbuch und die Checkliste zu PS4000 finde ich übrigends sehr gut


----------



## Tommi (30 November 2013)

Blockmove schrieb:


> PS: Dandbuch und die Checkliste zu PS4000 finde ich übrigends sehr gut



Hallo Dieter,

könntest Du den Link zu diesem Handbuch mal posten?

Danke.

Gruß
Tommi


----------



## Safety (30 November 2013)

Hallo für PNOZmulti gibt es und gab es schon länger dieses Dokument:
http://www.pilz.com/downloads/restricted/PNOZmulti_SafetyMan_21103-DE-01.pdf


----------



## Blockmove (30 November 2013)

Safety schrieb:


> Hallo für PNOZmulti gibt es und gab es schon länger dieses Dokument:
> http://www.pilz.com/downloads/restricted/PNOZmulti_SafetyMan_21103-DE-01.pdf



Dieses Handbuch meinte ich.
Unter 3.2 findest sich dieser kleine Satz


> Wir empfehlen, die definierten Sicherheitsanforderungen prüfen und genehmigen zu lassen.



Wenn ich nichts übersehen habe, dann ist dies alles zu einer Validierung durch eine  weitere Person.

Gruß
Dieter


----------



## Safety (30 November 2013)

Hallo Dieter,
ja das hätte man mit dem Normentext besser beschreiben können.


----------



## Blockmove (30 November 2013)

Safety schrieb:


> Hallo Dieter,
> ja das hätte man mit dem Normentext besser beschreiben können.



Vielleicht könnt ihr das ja mal intern erörtern.
Wie du ja schreibst, nimmt die Programmierung zu.
Und in den guten alten Zeiten als Sicherheitstechnik aus einer Handvoll Hilfsschützen bestand, hatten doch einige Elektriker den Schaltplan in der Hand beim Bauen, Konstruieren und Inbetriebnehmen.
Heute steckt 90% der Funktionalität in irgendwelchen Programmen und Parametrierugen und die sieht nur noch der Programmierer.

Vielen Dank für die Infos Safety und ein schönes Wochenende

Gruß
Dieter


----------



## Larry Laffer (1 Dezember 2013)

Manchmal wäre es ja auch schön, wenn es so eine Art Fall-Beispiele (wie zu der guten alten Hilfsschütze-Zeit) gäbe statt verklausolierter Formulierungen.
Ich finde die Info's von Safety auch sehr nett und vor Allem auch sehr umfassend - ich würde jetzt aber nicht behaupten wollen, dadurch nun wesentlich schlauer geworden zu sein.

Gruß
Larry


----------



## Blockmove (1 Dezember 2013)

Larry Laffer schrieb:


> Manchmal wäre es ja auch schön, wenn es so eine Art Fall-Beispiele (wie zu der guten alten Hilfsschütze-Zeit) gäbe statt verklausolierter Formulierungen.
> Ich finde die Info's von Safety auch sehr nett und vor Allem auch sehr umfassend - ich würde jetzt aber nicht behaupten wollen, dadurch nun wesentlich schlauer geworden zu sein.
> 
> Gruß
> Larry



Beispiele gibt es bei Pilz für PSS4000 hier:
https://www.pilz.com/de-DE/eshop/0001000023701480NB/PSSuniversal-PLC-Steuerung

Bei Siemens findet man Sie auch in den FAQs.

Ich versuche mich soweit es geht es geht an die Schaltungsbeispiele des BGIA-Reports
http://www.dguv.de/medien/ifa/de/pub/rep/pdf/rep07/biar0208/rep2_08_kap8.pdf
zu halten. Die meisten Beispiele lassen sich auch mit einer Sicherheits-SPS realisieren.

Was mich zunehmend nervt ist, dass die Kollegen ihre eigene Sprache entwickeln
Wenn ich ein Sicherheitshandbuch lese, dann hab ich meist gleich Google offen zum Begriffe suchen.
Wenn man nicht ständig damit zutun hat, dann weiss man eben nicht was _SRP_/_CS  _(sicherheitsrelevanter Teil einer Steuerung) ist.
Die ständigen Verweise auf Abschnitte aus Normen kosten Nerven und bringen dem Beuth-Verlag ein Vermögen.
Wenn man dann wenigstens die Norm nach dem 5mal Lesen verstanden hat, dann ist es ja noch ok, aber in vielen Fällen musst du dir dann noch Erläuterungen zur Norm kaufen um überhaupt den Inhalt der Norm zu verstehen. Aber Herr Ostermann will seine Bücher auch verkaufen.


Das Thema Sicherheit ist halt eine grüne Wiese auf der viele grasen 

Gruß
Dieter


----------



## Safety (1 Dezember 2013)

Hallo Larry,
ich nehme die Kritik gerne entgegen.
Es gibt nicht „die“ Vorgehendweise, das ist eben abhängig vom System und der Komplexität der Sicherheitsfunktion.
Es ist nicht einfach, das was in mehreren Normen steht in ein paar Sätzen umfassend und allgemeingültig zu erklären.  
Was ich immer wieder feststellen muss ist die meisten wollen immer einen Teilprozess betrachten, das geht aber nicht.
Wenn du eine Vorgehensweise sehen willst wie man Sicherheitsfunktionen dokumentieren kann, dann sehe Dir mal die Beispiele im BGIA Report 2/2008 und im IFA Report 7/2013 an.
Dann ist der von der Software  erbrachte Teil eventuell einfacher zu erbringen.
Zu dem Thema Normen und generell Maschinensicherheit, ist eben ein Spezialthema  wie SPS-Programmieren oder Elektroplanung. Ich verstehe auch nicht alles was die Softis da erzählen.
Ansonsten, kann ich mal versuchen was in einfachen Worten zu beschreiben, aber meine Zeit lässt das erst in den Weihnachtswochen zu.


----------



## Blockmove (1 Dezember 2013)

@Safety

Wie wärs denn, wenn ihr so einige Beispiele aus dem BGIA-Report in eure Systeme (Pascal, PNOZmulti, PSS4000) übersetzen würdet.
Die BGIA-Report-Beispiele decken schon einen Großteil der "normalen" Anwendungen ab. Für mich zumindest bilden Sie eine gute Basis.

Gruß
Dieter


----------



## Sinix (2 Dezember 2013)

Safety schrieb:


> Zur PNOZmulti, auch hier muss man verifizieren und validieren, aber es handelt sich um ein System das einem führt und eine einfache Validierung zulässt. Vollgraphische Programmierung einfaches Nachvollziehen der Datenstruktur durch verfolgen der Verbindungslinien und Verwendung von zertifizierten Funktionsbausteine die man nur noch Parametrisieren muss.



Bei aller Liebe, ich habe schon PNOZMulti-Projekte gesehen bei denen die Verknüpfungen über mehrere Seiten drunter und drüber gingen, da ist mir mein F-CPU mit FUP oder KOP (auch symbolisch,grafisch,farbig,querverweisfähig) lieber.



Larry Laffer schrieb:


> Ich finde die Info's von Safety auch sehr nett und vor Allem auch sehr umfassend - ich würde jetzt aber nicht behaupten wollen, dadurch nun wesentlich schlauer geworden zu sein.


Muss mich dem anschließen. Weis die Beiträge von user Safety sehr zu schätzen. Hier im ersten Beitrag viel geschrieben, aber zur eigentlichen Frage des TE nicht viel beigetragen. Die Aussagen zur Validierung ein Bruchteil der 13849-2, die der TE ja auch wie vor beschrieben kennt. Für mich wäre eine Information bezüglich der Validierung für einen kleinen Maschinenbaubetrieb interessant. Zwar steht hinter dem Ganzen die Sicherheit insbesondere für den Menschen, jedoch habe auch ich den Eindruck das die Automatisierungs und Validierungs-Lobby den Anwender zu mehr Konsum von Dienstleistungen bringen will. Als kleiner Maschinenbauer wird es wohl irgendwann unmöglich eine sichere Maschine nach geltenden Normen und Handbüchern zu validieren, weil die Validierungskosten inkl. Normenrecherche > Verkaufspreis. Die Chinesen wirds freuen, mich nervt schon allein eine zusätzliche Person ins Projekt zu holen.



Blockmove schrieb:


> Was mich zunehmend nervt ist, dass die Kollegen ihre eigene Sprache entwickeln
> Wenn ich ein Sicherheitshandbuch lese, dann hab ich meist gleich Google offen zum Begriffe suchen.
> Wenn man nicht ständig damit zutun hat, dann weiss man eben nicht was _SRP_/_CS  _(sicherheitsrelevanter Teil einer Steuerung) ist.
> Die ständigen Verweise auf Abschnitte aus Normen kosten Nerven und bringen dem Beuth-Verlag ein Vermögen.
> ...





Blockmove schrieb:


> @Safety
> 
> Wie wärs denn, wenn ihr so einige Beispiele aus dem BGIA-Report in eure Systeme (Pascal, PNOZmulti, PSS4000) übersetzen würdet.
> Die BGIA-Report-Beispiele decken schon einen Großteil der "normalen"  Anwendungen ab. Für mich zumindest bilden Sie eine gute Basis.
> ...




*ACK*


----------



## Safety (2 Dezember 2013)

Hallo,
zuerst  möchte ich mal klarstellen das ich hier nicht für ein Unternehmen schreibe und das auch in meiner Freizeit mache. Ich schreibe hier um etwas von meiner Erfahrung wiederzugeben und um selbst auch was dazuzulernen. Das was so über meine Beiträge hier geschrieben wird gibt mir zu denken.
Und im Gegensatz zu vielen unter meinem Namen.
Weiterhin denke ich es war ein Fehler ein Produkt ins Spiel zu bringen, hätte mich wie sonst auch neutral verhalten sollen. Aber das System kenne ich und das kann ich beschreiben.



> Bei aller Liebe, ich habe schon PNOZMulti-Projekte gesehen bei denen die Verknüpfungen über mehrere Seiten drunter und drüber gingen, da ist mir mein F-CPU mit FUP oder KOP (auch symbolisch,grafisch,farbig,querverweisfähig) lieber.


 
Zu Spagetticode habe ich was geschrieben.
Wenn Dir das besser gefällt auch o.k.



> Ich finde die Info's von Safety auch sehr nett und vor Allem auch sehr umfassend - ich würde jetzt aber nicht behaupten wollen, dadurch nun wesentlich schlauer geworden zu sein.


 
Hier muss ich gestehen, ich möchte nicht „NETT“ sein, ich möchte mit euch über bestimmte Themen diskutieren. Beziehst Du das auf alle meine Beiträge?



> Muss mich dem anschließen. Weis die Beiträge von user Safety sehr zu schätzen. Hier im ersten Beitrag viel geschrieben, aber zur eigentlichen Frage des TE nicht viel beigetragen. Die Aussagen zur Validierung ein Bruchteil der 13849-2, die der TE ja auch wie vor beschrieben kennt. Für mich wäre eine Information bezüglich der Validierung für einen kleinen Maschinenbaubetrieb interessant. Zwar steht hinter dem Ganzen die Sicherheit insbesondere für den Menschen, jedoch habe auch ich den Eindruck das die Automatisierungs und Validierungs-Lobby den Anwender zu mehr Konsum von Dienstleistungen bringen will. Als kleiner Maschinenbauer wird es wohl irgendwann unmöglich eine sichere Maschine nach geltenden Normen und Handbüchern zu validieren, weil die Validierungskosten inkl. Normenrecherche > Verkaufspreis. Die Chinesen wirds freuen, mich nervt schon allein eine zusätzliche Person ins Projekt zu holen.


 
Ja ich habe als Benutzer was zu dem Thema geschrieben, o.k. es gefällt Dir nicht. Dieter kennt die Normen, davon gehe ich aus. Ich habe versucht das Thema aus meiner Sicht zusammen zufassen. Ist mir wohl nicht gelungen. Aber wieso sollten auch all meine Beiträge perfekt sein? Übrigens hatte ich schon mal versucht das Thema aufzugreifen. Ist dann aber nach ein paar Antworten eingeschlafen.



> Wie wär`s denn, wenn ihr so einige Beispiele aus dem BGIA-Report in eure Systeme (Pascal, PNOZmulti, PSS4000) übersetzen würdet.
> Die BGIA-Report-Beispiele decken schon einen Großteil der "normalen" Anwendungen ab. Für mich zumindest bilden Sie eine gute Basis.



Ich kann das gerne mal vorbringen, aber ich schreibe hier Privat, also kann ich nicht sagen das es was wird. Denke wenn dann wird das mit den entsprechenden Produkten passieren aber das ist ja dann wieder nur ein weiterer Verkaufstrick. Sorry aber was hier in der letzten Zeit geschrieben wird geht mir zu weit.  
Nun gut, ich denke das Ganze ist  interessant, wir sollten zurück  zum Thema kommen.


----------



## Blockmove (2 Dezember 2013)

Sinix schrieb:


> Für mich wäre eine Information bezüglich der Validierung für einen kleinen Maschinenbaubetrieb interessant. Zwar steht hinter dem Ganzen die Sicherheit insbesondere für den Menschen, jedoch habe auch ich den Eindruck das die Automatisierungs und Validierungs-Lobby den Anwender zu mehr Konsum von Dienstleistungen bringen will. Als kleiner Maschinenbauer wird es wohl irgendwann unmöglich eine sichere Maschine nach geltenden Normen und Handbüchern zu validieren, weil die Validierungskosten inkl. Normenrecherche > Verkaufspreis. Die Chinesen wirds freuen, mich nervt schon allein eine zusätzliche Person ins Projekt zu holen.



Also so ganz kann ich deine Argumentation nicht nachvollziehen.
Natürlich muss man sich in das ganze Thema einarbeiten und das kostet unbestritten Zeit.
Aber wenn du dir einmal deine Basis geschaffen hast, dann kannst du darauf aufbauen.
Wir bauen unsere Maschinen meist nach PLd mit Kat3. Das hat sich als günstigster (nicht unbedingt billigster) Weg herausgestellt.
Die Komponenten sind zwar teurer, aber das sparen wir an Zeit bei der Konstruktion / Programmierung / Inbetriebnahme ein.
Mit Kat2 und entsprechender Diagnoseanforderungen und Fehlerausschlüssen spar ich vielleicht mal 100€, sitze aber 2 Stunden länger über der Sistema.
Bei ner Sondermaschine sollte es darauf nicht ankommen.
Validierung war aufgrund unerschiedlicher Aussagen teilweise im Detail unklar ... Deshalb dieser Thread hier.
Wenn alle im Vorfeld gut gearbeitet haben und ihre "Hausaufgaben" gemacht haben, dann ist es eigentlich nicht mal sonderlich schlimm.

Aber damit, dass es immer schwieriger wird und dass immer mehr mit Dienstleistungen rund um Sicherheit Geld verdienen wollen, hast du unbestritten Recht.
Ob dies aber Segen oder Fluch ist, weiss ich nicht so Recht.
Besonders wenn ich manche Beitrage und Frage zum Thema Sicherheit, VDE oder auch Programmierung hier im Forum lese.
Es ist für mich erschreckend wie niedrig teilweise der Kenntnissstand von "Kollegen" im Bereich Automatisierung und Maschinenbau ist.
Da wird eigentlich mit Sachwerten (Anlagen / Maschinen) und Menschenleben fahrlässig umgegangen.

Mein persönliches Fazit beim Thema Sicherheit:
Du brauchst jemand, den du Fragen kannst und glauben kannst 

Gruß
Dieter


----------



## Sinix (3 Dezember 2013)

Safety schrieb:


> Zu Spagetticode habe ich was geschrieben.
> Wenn Dir das besser gefällt auch o.k.



Du hast geschrieben, das man ihn unter allen Umständen vermeiden sollte. 
Ich habe lediglich geäußert, dass auch beim hier favorisierten PNOZMulti ein Spaghetticode möglich ist (und damit kein Allheilmittel ist)
und eine F-CPU auch seine Vorteile hat.

Richtig ist deine Aussage bezüglich programmierbare Fehler, da kann ich bei der F-CPU richtig Bockmist bauen,
und da reicht eigentlich auch kein Ausdruck (wie du schreibst) zur Vermeidung. 



Safety schrieb:


> Ja ich habe als Benutzer was zu dem Thema geschrieben, o.k. es gefällt Dir nicht.
> ...Sorry aber was hier in der letzten Zeit geschrieben wird geht mir zu weit.



Richtig und Falsch. Richtig zuviel Text und zuwenig Aussage zum Thema im Beitrag. Dafür habe ich konstruktive Kritik geübt.
Falsch das hier in letzter Zeit mehr Nonsenns geschrieben wird als sonst auch. Im übrigen weis ich deine fachlichen Beiträge
durchaus zu schätzen, hast ja schon oft ein Danke bekommen.

 Da ich nicht das fachliche Wissen besitze und auch keine Glaskugel -  bin ich eben hier in der Rolle 
der Opposition und kritisiere und hinterfrage, sofern die Admins mir das Recht einräumen meine freie Meinung zu äußern. 
Dies versuche ich dann auch stets sachlich und ohne Anfeindung,da kannst du alle meine Beiträge zu durchforsten. 
Abgesehen davon das ein Forum davon lebt und an Qualität gewinnt.



Safety schrieb:


> Nun gut, ich denke das Ganze ist  interessant, wir sollten zurück  zum Thema kommen.



*ACK*




Blockmove schrieb:


> Also so ganz kann ich deine Argumentation nicht nachvollziehen.
> 
> Natürlich muss man sich in das ganze Thema einarbeiten und das kostet unbestritten Zeit.
> 
> Bei ner Sondermaschine sollte es darauf nicht ankommen.



Da wir nur Sondermaschinen/Einzelstücke herstellen und hier auch kleinere Maschinen ist da schon ein enormer Kostendruck.
Wenn ich mir vorstelle für jede kleine Maschine einen Sachverständigen, gar noch vom TÜV, einzukaufen,
diesen dann noch zu briefen oder  bei den Endkunden mitzunehmen dann rechnet sich das nicht mehr wirklich.
Sistema ist ja auch so ein Beispiel. Kann mir vorstellen, dass der eine oder andere sich hier externes Personal zum Erstellen
holt. Ich bin in der glücklichen Lage eine Bewertung, die mittlerweile von einigen Kunden im Lastenheft steht, selbst durchzuführen.
Szenario: Vielleicht wird beim nächsten Update der 13849-2 der unabhängige Sachverständige aus dem Siemens Handbuch übernommen?
Je nach Interessen der beteilligten Personen im Gremium würde ich das nicht ganz von der Hand weisen.




Blockmove schrieb:


> Besonders wenn ich manche Beitrage und Frage zum Thema Sicherheit, VDE oder auch Programmierung hier im Forum lese.
> Es ist für mich erschreckend wie niedrig teilweise der Kenntnissstand von "Kollegen" im Bereich Automatisierung und Maschinenbau ist.
> Da wird eigentlich mit Sachwerten (Anlagen / Maschinen) und Menschenleben fahrlässig umgegangen.



Stimme ich zu. Allerdings machen die Leute im Forum sich zumindest schon mal Gedanken um die Thematik und hier in Deutschland (und Österreich und einige ander europäische Länder) ist auf Herstellerseite viel mehr gemacht als anderswo auf der Welt, siehe Stammtisch  http://www.sps-forum.de/stammtisch/67662-unsere-lieben-kunden.html




Blockmove schrieb:


> Mein persönliches Fazit beim Thema Sicherheit:
> Du brauchst jemand, den du Fragen kannst und glauben kannst :wink:
> 
> Gruß
> Dieter



Das ist richtig. Auch wir holen Sachverständige zur Beratung bei schwierigen Aufgabenstellungen.
(im Übrigen steht in der Dokumentation "in Beratender Funktion", den Kopf muss trotzdem ich hinhalten)

Aber die Frage ist ja die Validierung deiner F-CPU? 
Für mich bleibt das vorerst der projektfremde Kollege.

MfG Sinix


----------



## Blockmove (3 Dezember 2013)

Sinix schrieb:


> Aber die Frage ist ja die Validierung deiner F-CPU?
> Für mich bleibt das vorerst der projektfremde Kollege.



Das ist auch definitiv der Fall. 
Evtl. reicht es auch, dass der Kollege nicht an den Sicherheitsfunktionen gearbeitet hat.

Gruß
Dieter


----------



## bike (3 Dezember 2013)

Blockmove schrieb:


> Das ist auch definitiv der Fall.
> Evtl. reicht es auch, dass der Kollege nicht an den Sicherheitsfunktionen gearbeitet hat.
> 
> Gruß
> Dieter



Ein komplett "Fremder" des Projektes ist, denke ich, keine gute Lösung.
Der Kollege sollte bzw muss wissen, um was es geht und woher die Risiken kommen können.

Wenn du einen Fremden bzw Externen mit der Überprüfung beauftragen willst, musst du zunächst genau beschreiben, was für die Sicherheit und warum eingebaut wurde und welche Gefahr damit abgewehrt werden soll.

Wenn du dir diesen Aufwand machst und dann noch eine Aufstellung wie welche Funktion funktionieren soll, kannst du oder dein Kollege die Tests selbst machen.
Ist aber zunächst eine ziemliche Fleißarbeit bis die Grundstruktur solch einer solchen Abnahmeprozedur steht, dann wird es weiteren ein Kinderspiel.


bike


----------



## Sinix (4 Dezember 2013)

bike schrieb:


> Wenn du einen Fremden bzw Externen mit der Überprüfung beauftragen willst, musst du zunächst genau beschreiben, was für die Sicherheit und warum eingebaut wurde und welche Gefahr damit abgewehrt werden soll.



 Das Wörtchen "muss" stört mich ein wenig, auch wenn es für eine Validierung reichen würde. Warum? Weil der Sinn das ein Projektfremder prüft ist ja unter anderem der, dass dieser durch sein Fachwissen selbst Gefahren/Lücken erkennt, die dir vielleicht durch die Lappen gegangen sind. Wenn du dem jetzt haarklein deine ganzen Funktionen erklärst wird er sich möglicherweise darauf fokusieren und nur die von dir genannte Sicherheit und deren Gefahrenabwendung prüfen. 

Ideal für mich ist deshalb mein Programmierer/Inbetriebnehmer-Kollege, dem ich mein Projekt übergebe, eine grobe Funktionsbeschreibung der Maschine mache und ansonsten nur auf eventuelle Fragen antworte. Selbstverständlich kostet es Zeit, dass er sich hier einarbeitet. Die Fleißarbeit liegt hier beim Kollegen(Prüfer). Vorteil ist auch das ich dann bei der Maschine meines Kollegen prüfe und wir uns gegenseitig gut gelöste Aufgaben abschauen. 

Sinix


----------



## rostiger Nagel (4 Dezember 2013)

Sinix schrieb:


> Das Wörtchen "muss" stört mich ein wenig, auch wenn es für eine Validierung reichen würde. Warum? Weil der Sinn das ein Projektfremder prüft ist ja unter anderem der, dass dieser durch sein Fachwissen selbst Gefahren/Lücken erkennt, die dir vielleicht durch die Lappen gegangen sind. Wenn du dem jetzt haarklein deine ganzen Funktionen erklärst wird er sich möglicherweise darauf fokusieren und nur die von dir genannte Sicherheit und deren Gefahrenabwendung prüfen.



Vielleicht ist das Wort 'muss' ja garnicht so falsch. Das Valedieren ist doch nicht anderes, als zu prüfen ob die Sicherheitsfunktionen
funktonieren oder entsprechend der Gefahrenanalyse umgesetzt wurden. Wenn jetzt Fehler außerhalb seiner Valedierungsaufgabe
erkannt wird und darauf hingewiesen wird ist dieses zu begrüßen.


----------



## Sinix (4 Dezember 2013)

rostiger Nagel schrieb:


> Das Valedieren ist doch nicht anderes, als zu prüfen ob die Sicherheitsfunktionen
> funktonieren oder entsprechend der Gefahrenanalyse umgesetzt wurden.



Dann widerum benötige ich aber keine externe oder projektfremde Person.


----------



## rostiger Nagel (4 Dezember 2013)

Sinix schrieb:


> Dann widerum benötige ich aber keine externe oder projektfremde Person.



Wenn du als Projektersteller Validierst, wird das wohl wenig sinn machen.

Gegenfrage: Warum sollte er jetzt außer den Validieren nocht mehr machen?

Stell dir doch mal ein Serienmaschinenbau vor, da könnte es doch auch sein
das der Monteur Validiert. Er braucht dann eigentlich doch nicht mehr zu wissen,
wie zu der Validierungsaufgabe gehört.


----------



## bike (4 Dezember 2013)

rostiger Nagel schrieb:


> Wenn du als Projektersteller Validierst, wird das wohl wenig sinn machen.
> 
> Gegenfrage: Warum sollte er jetzt außer den Validieren nocht mehr machen?
> 
> ...



Bei uns machen die Inbetriebnehmer die Safe-Abnahme.
Es gibt eine Liste, welche Parameter und welche Funktionen wie geprüft werden müssen.
Wenn eine Verkettung und/oder Montagelinie  dazukommt, dann ist für die Achsen, Aktoren und Sensoren beschrieben, welche Funktionen wann und wie erlaubt sind.
Nach diesen Vorgaben wir geprüft.

Zum Erstellen des SicherheitsKonzeptes braucht man neben der Mechanik, die Elektrohardware und die Software.
Zu diesem Zeitpunkt ist ein mehr als Zweiaugenprinzip schon gegeben.
Es macht keinen Sinn, dass ein Projektfremder sich noch einmal das  komplette Sicherheitskonzept erarbeitet und dann nach seinem Konzept  prüft.


bike


----------



## rostiger Nagel (4 Dezember 2013)

der Meinung bin ich auch.



bike schrieb:


> Bei uns machen die Inbetriebnehmer die Safe-Abnahme.
> Es gibt eine Liste, welche Parameter und welche Funktionen wie geprüft werden müssen.
> Wenn eine Verkettung und/oder Montagelinie  dazukommt, dann ist für die Achsen, Aktoren und Sensoren beschrieben, welche Funktionen wann und wie erlaubt sind.
> Nach diesen Vorgaben wir geprüft.
> ...


----------



## Sinix (4 Dezember 2013)

@rostiger Nagel



rostiger Nagel schrieb:


> Wenn du als Projektersteller Validierst, wird das wohl wenig sinn machen.



hab ich auch nie erwähnt.



> Gegenfrage: Warum sollte er jetzt außer den Validieren nocht mehr machen?



Weil der Sinn der Prüfung darin besteht Fehler des Erstellers zu erkennen. Aus der 13849-2 u.a.:



> 9.5 ...
> 
> -angewandte Maßnahmen und Methoden zur Vermeidung von systematischen Softwarefehlern während der Softwareentwicklung



Zeig mir bitte den Monteur der eine Plausibilitätsprüfung unsicherer Daten im F-Programm durchführt oder die Versionskennung mit dem richtigen Annex 1 überprüft.


Wie wird bei dir z. Zt. validiert?


MfG Sinix


----------



## rostiger Nagel (4 Dezember 2013)

bike hat doch gerade Beispiele gebracht wie es unter Umständen im
Serienmaschinenbau gemacht wird. Es geht doch um die Aussage, das
ein Valedierer nicht wissen 'muss' oder 'soll', deiner Auffassung nach,
wie das Sicherheitskonzept gestaltet ist. Aber es geht doch nicht um den
Nachweis ob es richtig gewählt wurde, sondern ob es funktioniert.


----------



## Sinix (4 Dezember 2013)

rostiger Nagel schrieb:


> bike hat doch gerade Beispiele gebracht wie es unter Umständen im
> Serienmaschinenbau gemacht wird.



Heisst im Klartext du machst es auch so?



rostiger Nagel schrieb:


> Es geht doch um die Aussage, das
> ein Valedierer nicht wissen 'muss' oder 'soll', deiner Auffassung nach,
> wie das Sicherheitskonzept gestaltet ist.



Meiner Auffassung nach diskutiere ich mit dir/euch darüber wie und (wie sich schnell herausgestellt hat) durch wen
eine Validierung der F-CPU/Sicherheits-SPS vorgenommen wird. Wie es bei mir gehandhabt wird, habe
ich bereits gepostet und sehe viele Parallelen zu user bike und anderen, denen ich dafür dankbar bin.
Darüberhinaus möchte ich wie der TE  aber andere Vorgehensweisen prüfen und dazu gehört u.a. auch das Für und Wider einer
Validierung durch externes Personal / Sachverständigen. 

Wie man sieht gibt es ja vom TÜV-Sachverständigen bis zum Monteur jede Menge Vorschläge


----------



## rostiger Nagel (4 Dezember 2013)

So steht es im BGIA Report 2/2008



> 7.1.1 Leitsätze für die Verifikation und Validierung
> Verifikation und Validierung sollen die Konformität der Gestal-
> tung der SRP/CS mit der Maschinenrichtlinie sicherstellen.
> 
> ...



So macht es vielleicht auch Sinn, ein Abteilungsfremder der es
nicht mit ausgearbeitet hat. Da ist aber auch das Problem, welche
Firma kann sich solche Parallel Welten leisten, die das entsprechende
Fachwissen mitbringen.


----------



## Blockmove (4 Dezember 2013)

Wenn ich die Herstellerhandbücher und die Norm richtig interprediere, dann ist die Software-Validierung im einfachsten Fall durch einen Mitarbeiter möglich, der nicht an der Erstellung / Programmierung der Sicherheitsfunktionen beteiligt war.
Die Software-Validierung erfolgt anhand eines Validierungsplanes (Checkliste) in dem alle Gefährdungen, die vorgesehenen Sicherheitselemente und Funktionen und deren Umsetzung kurz beschrieben sind. Der validierende Mitarbeiter muss in der Lage sein, die Logik und Parametrierung zu verstehen.
Solange vorkonfigurierte und zertifizierte Bausteine verwendet werden, ist damit das Thema Software-Validierung recht einfach zu erledigen.

Werden neue Sicherheitsfunktionen (Chemie, Anlagenbau, ...) programmiert, dann kann eine weitergehende Validierung inkl. Prüfung durch externe Sachkundige oder Sachverständige notwendig sein.

@Safety:
Ich hoffe ich habe mit den Aussagen recht 

Gruß
Dieter


----------



## zumret (4 Dezember 2013)

Blockmove schrieb:


> @Sinix
> 
> Das Thema Validierung (V-Modell) aus der 13849-2 kenne ich auch.
> Nur geht hier das Siemens-Handbuch über die Norm hinaus.
> ...



Ja das Thema mit dem V-Modell ist echt ein wichtiges. Normalerweise sollte das Siemens Handbuch dir in diesem Punkt alles schlüssig erklären. Aber wenn Du sowieso einen Fachberater ins Haus bekommst wird er Dir den Punkt ausführlich erklären.

Grüße


----------



## Blockmove (5 Dezember 2013)

zumret schrieb:


> Ja das Thema mit dem V-Modell ist echt ein wichtiges. Normalerweise sollte das Siemens Handbuch dir in diesem Punkt alles schlüssig erklären. Aber wenn Du sowieso einen Fachberater ins Haus bekommst wird er Dir den Punkt ausführlich erklären.
> 
> Grüße



Weil das Siemens-Handbuch sooo gut ist, habe ich den Thread gestartet 
Lies dir den Anfang des Threads durch 

Gruß
Dieter


----------



## Safety (6 Dezember 2013)

Blockmove schrieb:


> Wenn ich die Herstellerhandbücher und die Norm richtig interprediere, dann ist die Software-Validierung im einfachsten Fall durch einen Mitarbeiter möglich, der nicht an der Erstellung / Programmierung der Sicherheitsfunktionen beteiligt war.
> Die Software-Validierung erfolgt anhand eines Validierungsplanes (Checkliste) in dem alle Gefährdungen, die vorgesehenen Sicherheitselemente und Funktionen und deren Umsetzung kurz beschrieben sind. Der validierende Mitarbeiter muss in der Lage sein, die Logik und Parametrierung zu verstehen.
> Solange vorkonfigurierte und zertifizierte Bausteine verwendet werden, ist damit das Thema Software-Validierung recht einfach zu erledigen.
> 
> ...



Hallo Dieter,
ja wenn man einfache Strukturen und dann auch Zertifizierte Module (Funktionsbausteine) benutzt brauchst Du diesen Teil des V-Model nicht mehr zu erfüllen.
Wie gesagt Ziel des ganzen ist Fehler Vermeidung in der Software. Denn das ist das einzige was man machen kann.  
Man muss sich bei der Forderung von Normen auch Fragen warum wollen die das?
Bei der Validierung durch eine zweite Person geht es darum, das der Mensch dazu neigt eigene Fehler nicht zu sehen. Ich habe gut Erfahrung mit dem Vieraugenprinzip gemacht, der Ersteller erklärt anhand der Dokumentation was er wie und warum gemacht hat. Meist merkt der Ersteller schon beim erklären was falsch ist. Es sollten aber auch in Sicherheitsfunktionen erfahrene Personen sein.
Es ist eben wichtig, dass man von Anfang an alles durch arbeitet, Risikobeurteilung Risikominderungsmaßnahmen, Funktionstest und Prüfungen ob die Maßnahmen auch umgesetzt wurden usw.
Bei der Software ist fast immer der nicht vorhandenen Nahvollziehbare Weg das größte Problem, hier muss man eine Spezifikation haben, damit ich überhaupt weiß was zu tun ist.


----------



## Sinix (9 Dezember 2013)

Safety schrieb:


> Wie gesagt Ziel des ganzen ist Fehler Vermeidung in der Software. Denn das ist das einzige was man machen kann.
> Man muss sich bei der Forderung von Normen auch Fragen warum wollen die das?
> *Bei der Validierung durch eine zweite Person geht es darum, das der Mensch dazu neigt eigene Fehler nicht zu sehen*. Ich habe gut Erfahrung mit dem Vieraugenprinzip gemacht, der Ersteller erklärt anhand der Dokumentation was er wie und warum gemacht hat. Meist merkt der Ersteller schon beim erklären was falsch ist. *Es sollten aber auch in Sicherheitsfunktionen erfahrene Personen sein.*
> Es ist eben wichtig, dass man von Anfang an alles durch arbeitet, Risikobeurteilung Risikominderungsmaßnahmen, Funktionstest und Prüfungen ob die Maßnahmen auch umgesetzt wurden usw.



*ACK*

Sag ich doch:


Sinix schrieb:


> ...der Sinn  das ein Projektfremder prüft ist ja unter anderem der, dass dieser durch  sein Fachwissen selbst Gefahren/Lücken erkennt, die dir vielleicht  durch die Lappen gegangen sind...





Sinix schrieb:


> ...Weil der Sinn der Prüfung darin besteht Fehler des Erstellers zu erkennen. Aus der 13849-2 ...



Würd mich mal interessieren wie Ihr so vorgeht.

Im Handbuch Siemens Distributet Safety Kapitel 11.2.2 - finde ich keinen Hinweis zu vorkonfigurierten und zertifizierten Bausteinen, dessen Betrachtung die Validierung erleichtert. 


> 11.2.2 Abnahme des Sicherheitsprogramms
> Sicherheitsprogramm überprüfen (Druckinhalt "Sicherheitsprogramm")
> 1. Überprüfen Sie im Ausdruck, ob die beiden Gesamtsignaturen übereinstimmen:
> – Gesamtsignatur aller F-Bausteine mit F-Attribut des Bausteincontainers
> ...



Validiert ihr nach Siemens Handbuch, nach DIN 13849-2, Beides oder Sonst irgendwie?
Mir ist schon klar das "Beides" richtig ist, dass muss jetzt niemand beschwichtigen, aber wie wird es in der Praxis gehandhabt?

Danke und Gruß
Sinix


----------



## Profilator (10 Dezember 2013)

Also mein Wissensstand ist folgender:

# Validierung durch TÜV, Sachverständigen o.Ä. > Hängt vom "zutreffenden onfomitätsbewertungsverfahren" ab, siehe MRL. Im normalen Maschinenbau ist das sicher nicht erforderlich. Ob allerdings der Projektleiter der Richtige ist frag ich mich schon. Validieren ist eben nicht nur mal eben die Funktion der Sicherheits- einrichtungen testen. Ein gewisses Wissen über die Anlage reicht wohl kaum aus, dann kann ich auch gleich Sabine - die Azubine- nehmen. 
# Genauso vorsichtig sein sollte man mit Pauschalausagen der Bauteilhersteller im Sinne von .. Abnahme durch unabhängigen Sachverständigen. Ich bin der Meinung hier wollen sich die Hersteller nur durch das Aufstellen von "Maximalforderungen" jegliche Verantwortung vom Hals halten. Fakt ist aber die Norm (13849-1/2) beschreibt wie /durch wen zu validieren ist, und nicht der Hersteller der F-CPU.
# 2014 wird das Jahr der Validierung, das glaube ich auch!
# Übrigens, was hier unterzugehen scheint, validiert werden muss die GESAMTE SF, (Sensor - Logik - Aktor) nicht nur die F-CPU.
# Was mich erschreckt: das Abstimmungsergebnis 62% lassen einen ... Kollegen "drüberschauen" und haben
dann ihre Validierung fertig. Ob das ausreicht ?



MfG


----------



## Tommi (10 Dezember 2013)

Profilator schrieb:


> # Was mich erschreckt: das Abstimmungsergebnis 62% lassen einen ... Kollegen "drüberschauen" und haben
> dann ihre Validierung fertig. Ob das ausreicht ?



Ja! Wenn der Kollege genügend Sachkenntnis hat und systematisch vorgegangen wird,
incl. Dokumentation. 
Wenn die Personen, die in diesem Thread posten, gegenseitig "drüberschauen würden,
wäre das mehr wert, als 10 Sachverständige einzuschalten.

Gruß
Tommi


----------

