Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

- DST, Berlin 18.3.2005, revised 2008 -1 Prozessorientierte Steuerung von Maschinen Rekonstruktion von Schadenereignissen Prozessorientierte.

Ähnliche Präsentationen


Präsentation zum Thema: "- DST, Berlin 18.3.2005, revised 2008 -1 Prozessorientierte Steuerung von Maschinen Rekonstruktion von Schadenereignissen Prozessorientierte."—  Präsentation transkript:

1 - DST, Berlin , revised Prozessorientierte Steuerung von Maschinen Rekonstruktion von Schadenereignissen Prozessorientierte Steuerung von Maschinen Rekonstruktion von Schadenereignissen „ Maschinensicherheit und Steuerung!“ Wilhelm Uhlenberg Vortrag zum Deutschen Sachverständigentag SPS, PLC, CNC, NC, MC, DCS

2 - DST, Berlin , revised Agenda Ablauftechnisches, Fahrplan Vorstellung (Hintergrund), Einführung ins Thema Grundlagen, Fakten, Sachverständigen-Messlatte Problembewusstsein, Risiko und Risikofallen Beispiele  3 Hot Spots Problemklassen und mögliche Ursachen & Markteinordnung Erhebungsschwerpunkte, Fehlermanagement Erkenntnisse & Maßnahmen Fazit, Fragen, Live-Beispiel und Quellenverweise

3 - DST, Berlin , revised Einführung (1) Sachverständiger in der Prozessautomation seit 1987 Öffentlich bestellt und vereidigt seit 1989 (zunächst IHK Köln, dann IHK Hannover) Industrieerfahrung seit 1978 Netzleittechnik (EVUs) Automatisierungstechnik (chemische Verfahrenstechnik, Hochofen) Elektrotechnische Ausbildung, softwaretechnischer Berufsweg, internationale Projekte (Schwellenländer) Derzeit verstärkt an präventiven Maßnahmen zur Konfliktvermeidung engagiert Mitglied der Fachgruppe Elektronik und EDV im BVS seit Vortragsskriptum

4 - DST, Berlin , revised Einführung (2) Prozessorientierte Steuerung von Maschinen – was ist das? Maschinen so steuern, dass möglichst schnell ein Prozess droht? (SV-Eindruck) Maschinelle Abläufe steuern, die den optimalen technischen Prozess widerspiegeln Maschinelle Prozesse menschengerecht und sicher steuern Abläufe steuern, die die betrieblichen Prozesse ergänzen bzw. stützen?  Auftragsplanung  Materialeinsatz  Wartungszyklen  …

5 - DST, Berlin , revised Einführung (3) Prozessorientierte Steuerung von Maschinen – was ist das? Übergeordnet koordinierte Betriebsabläufe (-prozesse) steuern, dass Maschine/Anlage optimal ausgelastet  (ERP, value chain deployment) Fertigungs-/ Herstellungs-Prozesse (rezepturbasierend) flexible steuern Unternehmensstrategien, je nach Ausprägung „PROZESS- bestimmend“:  Betriebssicherheit, Arbeitsschutz, Flexible Fertigung/Herstellung, eProcurement, production on demand, JIT … In der Praxis oft Kombination der Sichtweisen und Standpunkte.

6 - DST, Berlin , revised Was wünschen wir?

7 - DST, Berlin , revised Wann kommt der SV ins Spiel? Wenn der Sachverständige heute gerufen wird ist meist bereits zuvor etwas passiert. Determinanten des Ergebnisses Wann (Zeitversatz) kommen wir hinzu? Was bekommen wir zu sehen? Was ist die Motivation uns zu beauftragen? Was wurde ursprünglich investiert spätere Fehler/Schäden objektiv zu erfassen und die Entstehung zu rekonstruieren? Sind Zustände/Anlagenteile vollständig untergegangen? Wer hilft mit, die tatsächlichen Abläufe zu verschleiern? Müssen wir außerhalb des Auftrages Erkenntnisse liefern?

8 - DST, Berlin , revised Orientierung (1) Was hilft dem SV (hoffentlich bereits vorher den Projektbeteiligten): Klare, widerspruchsfreie Aufgabenbeschreibung Feststehende Verantwortungen (Organisation) Fachkompetente Partner, ausgebildetes Personal Angepasste (harmonisierte) Prozessabläufe Machbarkeitsstudien, Gefährdungsanalyse, Risikobeurteilung

9 - DST, Berlin , revised Was hilft dem SV (hoffentlich bereits vorher den Projektbeteiligten): Bedarfsorientierte Auswahl (was treibt am Markt?) Realistische Termin-/Kostenpläne Zügige, unterbrechungsfreie Realisierung (in einem Rutsch) Aktuelle, stimmige Dokumentation Normenkonformität Verträge, die die zuvor genannten Kriterien beinhalten! Orientierung (2)

10 - DST, Berlin , revised Warum Steuerungen? Die selektive Wahrheit... Funktionieren, sicher und schnell Einfach und flexibel anpassbar durch Programmierung Wirtschaftlich durch Standardisierung Pflegbar und erweiterbar

11 - DST, Berlin , revised AUCH Gefährdungen vermeiden (Sicherheitskomponente) Den Laien führen (bestimmungsgemäßer Gebrauch) Ablaufhistorie / Protokolle (auch Diagnose) Fehlerfreiheit (Methodisch?, Statistisch?) Abläufe sind im Programm dokumentiert  Programme sollen lesbar sein (für wen?) Warum Steuerungen?

12 - DST, Berlin , revised Genereller Leitfaden Leitlinie... Steuerungen sind so zu konzipieren und zu bauen, dass sie sicher und zuverlässig funktionieren und somit keine gefährlichen Situationen entstehen. Insbesondere müssen sie so konzipiert und gebaut sein, dass sie den zu erwartenden Betriebsbeanspruchungen und Fremdeinflüssen standhalten und Fehler in der Logik zu keiner gefährlichen Situation führen. (MRL [GSG 9.VO] Anhang I 1.2.1, EN IEC (war EN 292-2), EN [elektrische Ausrüstung], EN 1050 [Gefährdung/Risiko]). Habe fertig … (Giovanni Trappatoni, 1998)

13 - DST, Berlin , revised WAS, nochmal? Steuerungen an Maschinen sollen: Sicher sein, Zuverlässig sein, Funktionieren (im Sinne der Nutzfunktion) Keine gefährlichen Situationen entstehen lassen Beanspruchungen standhalten Fremdeinflüssen standhalten (?) Fehlertolerant mit Blick auf Gefährdungen

14 - DST, Berlin , revised Weitere relevante Normen Wer Details möchte, bitte nachschlagen unter: EN (bzw. jetzt ),  292-1/2 ist bereits in DIN EN ISO /2 aufgegangen DIN EN 954-1/2 (demnächst /2)  prEN/ISO (Revision von EN und Praxisanwendung von IEC 61508)  DIN EN ISO (Validierung) (Revision von prEN 954-2) Die funktionale Sicherheit unter der Reihe IEC oder DIN IEC (VDE 0810 Teil 2) haben durchaus Relevanz (vermutlich ab QIII 2005 EN ISO [Validierung] Komplexe Systeme eher nach EN/IEC bzw. IEC 62061

15 - DST, Berlin , revised Noch‘n Gedicht (Grundlagen) Wenn die Sicherheit von Steuerungen abhängt, muss die Steuerung (umfassend) so ausgelegt und realisiert werden, dass die Wahrscheinlichkeit von Funktions- fehlern ausreichend(!?) gering ist. Bei programmierbaren elektronischen Systeme ist dazu die Norm IEC zu beachten. (Prozesstechnische Anlagen mehr IEC 61511, [hoch]mathematischer Ansatz). EN ISO (ab ) und EN IEC geben Anleitungen spezifisch für die Sicherheit von Maschinensteuerungen (meist elektronischen). EN ISO soll zukünftig die anwendbare Symbiose aus EN und IEC für elektrisch basierte Steuerungssystem darstellen.

16 - DST, Berlin , revised Gefahr und Risiko Mögliche Gefährdungen einer Maschine aus Risikobewertung Anhand EN 1050 (zukünftig EN ISO 14121) feststellen, ob ausreichende Sicherheit erreicht wurde. Implementierung sicherheitsrelevanter Steuerungsfunktionen aufgrund der zu beseitigenden Risikohöhe abgestuft entsprechend den Anforderungen von EN IEC und EN ISO Die Bemessungsgröße für diese Abstufung ist bei EN IEC (wie in IEC 61508) der Safety Integrity Level (SIL) und bei EN ISO der Performance Level (PL). Bei umfangreichen Projektrealisierung solcher Anteile/Anlagen ist Risikomanagement nach IEC weiterführen.

17 - DST, Berlin , revised Wie sieht‘s mit Risiken aus? Schwere, Tragweite, Ausmaß, Häufigkeit, Eintrittwahrscheinlichkeit, Möglichkeit der Vermeidung. Ganz allgemein und einfach R = W/S (zu einfach!) oder R = S(Ausmaß) * H(äufigkeit)

18 - DST, Berlin , revised Wie werden Risiken analysiert?

19 - DST, Berlin , revised Wann muss man was machen?

20 - DST, Berlin , revised Risikofallen, was sind das? Wissensdefizite (aus Fehlern lernen?) Denkgewohnheiten Motivationslagen Gruppendynamik-Prozesse, Soziale Fallen Kognitive Fallen Gefahr der Checklisten Generalisieren von Regeln Komplexität, Umfang, Überfrachtung Zeitdruck, Stress

21 - DST, Berlin , revised Ausnahmen für spezielle Anwendungsbereiche Kerntechnik Luftfahrt Eisenbahntechnik Raumfahrt Gentechnologie (auch Pharma, teilweise) Militärische Systeme und Anwendungen Sonst kann ein Hersteller seinem Produkt ein CE-Zeichen verleihen, wenn er „meint“, dass die Anforderungen der EG- Richtlinien erfüllt sind. Es ist keine obligate Überprüfung/ Zertifizierung durch eine unabhängige (sachverständige) Stelle gefordert.

22 - DST, Berlin , revised Auslegung & Beanspruchung Inhärent sichere Konstruktion Mechanisch, Physisch Elektrisch, EMV, Strahlung, Emission Ergonomisch Sämtliche Elemente der Mensch-Maschine- Schnittstelle wie Stellteile, Signal- oder Datenanzeigen müssen so konstruiert werden, dass sie leicht verständlich sind, um eine klare und eindeutige Wechselwirkung zwischen Bedienperson und Maschine zu ermöglichen.  Siehe EN 614-1, ISO 6385, EN und IEC

23 - DST, Berlin , revised Problembewusstsein Die selektive Wahrheit (2)... Zu einfach änderbar (on-the-fly): „Verführung des Probierens“ Langzeiteffekte oft nicht erkannt oder vernachlässigt (z.B. Y2K war in 1970 kein Thema) Pflegbarkeit durch fehlende Doku untergraben Neue zuvor unbekannte Gefahrenquellen  (z.B. Datentypen-verletzung, Race condition, dynamische Prioritäten) Empfindlichkeit komplexer elektronischer Steuerungen gegenüber Umfeld steigt  (z.B. EMV-Einflüsse, vagabundierende Ströme im PEN-System).

24 - DST, Berlin , revised AUCH Den Laien „verführen“, statt zielgerichtet und sicher „führen“ Erfahrungs-/Ausbildungsmangel Fehlerfreiheit ist nie 100% (Softwarequalität!) Programme vom Menschen für Maschinen bereits optimiert – warum?  falscher Ansatz Problembewusstsein

25 - DST, Berlin , revised Was lehrt die Praxis? Blinder Einblick?... Komplex und verbunden (nicht nur eine Maschine) Flexibel (bis zur Unkenntlichkeit) Unüberschaubar Variantenreich Von Menschen erdacht Fehleranfällig Flüchtig Gefährdungsgeneigt Und …

26 - DST, Berlin , revised Feldversuche Maschine/Anlage Überzeichnete These: “Es ist etwas passiert und solange der Schaden bezahlt wird, will kaum einer wissen warum” (Personenschaden ausgenommen). 4 Beispiele aus meiner Praxis:  Medikamentenherstellung in einer Gefriertrocknungsanlage  Gussteile, Transport mit einem autom. Kran (Absturz)  Brand in einer Anlage zur Abwasserreinigung nach dem Umkehrosmoseprinzip  Brand in einem Tunnelfinisher (Wäscherei) Sind Automaten den Situationen angepasst?

27 - DST, Berlin , revised Das wahre Leben?

28 - DST, Berlin , revised Medikamentenproduktion (Verfahrensfehler) Anlage produziert ein hochsteriles und unter Vakuumbedingungen abgefülltes Medikament zur Blutbehandlung. Die Verfahrensschritte sind über eine Rezeptursteuerung anpassbar. Gefriertrocknungskammer muss kühlen, evakuieren und verschließen. Design- und Qualifizierungsmaßnahmen nach EU-GMP-Regeln. WinCC nach Standards CRF 21 Part 11 mit DCS-System gekoppelt …. Merksatz: Sehr hohe Standards und Konformitätshürden schützen nicht immer vor Routine oder mangelnder Sorgfalt!

29 - DST, Berlin , revised Medikamentenproduktion (Verfahrensfehler) Motivation des Kostenverteilungsversuches  Anlage war schon 2-fach zuvor (angeblich gleich) aufgebaut und betrieben worden. (Routine??)  Hoher Wirtschaftlicher Schaden (Rohmaterial verdorben) in einer Charge. Rohmaterial verdorben Verzögerung der Produktion durch erneute Qualifizierung und Genehmigungsprozeduren. DESHALB:  Trotz Superdokumentation und nachvollziehbaren Projektphasen, ist manchmal der Blick von Außen (Unbeteiligter) für die Sicherheit gewinnbringend.  Automatismen zur Störungsdiagnose waren definiert Automatische Fehlererkennung war aber nicht erneut getestet worden.  Störfolge-Protokollierung war vorhanden Hinweise wurden vor Produktionsbeginn nicht ausreichend beachtet.  Schichtübergabe – Organisationsverschulden?

30 - DST, Berlin , revised Beispiel (DCS System) Unterschiede zur SPS (wie sie früher war) Viele dezentral und autonom arbeitende Controller Viel zellenübergreifende Kommunikation, auch zu Bedienplätzen, Externen Subsystemen. Funktionsbausteine, die die gesamte Infrastruktur bedienen können (z.B. Regler mit Istwert aus anderem Anlagenbereich). Anwenderspezifische programmierte Erweiterungen möglich (Protokolltreiber, Feldbusse, Komplexe Kolonnen) Meist wahlfrei redundant ausbaubar durch einfache Hardware- Erweiterung. Modulare Messtechnik (2. Schicht) Heute kaum mehr Unterschied, wenn Feldbus oder Profibus und WinCC (Bedienung) an z.B. S7 oder PCS7

31 - DST, Berlin , revised Transport in einer Gießerei Anlage zum Transport von Gussteilen über mehrere Fertigungsstufen. Krananlage stellt Transport zwischen den Stufen her. Oberhalb der Station „Sandstrahlen“ lässt der Greifer des Krans aus unbekanntem Grund den Rohling aus oberster Stellung fallen. Schaden durch Aufschlag von über 600 kg Masse auf diverse Schacht-, Antriebs- und Halteeinrichtungen innerhalb der Strahlkabine. Verantwortlichkeit wurde in der Programmierung der Steuerung der Krananlage vermutet, die den Greifer zufällig geöffnet haben soll.

32 - DST, Berlin , revised Anlagenausschnitt

33 - DST, Berlin , revised Beispiel (Siemens S7-315) Problem mit der Sollposition des Greifers Bosch-Rexroth ECUDRIVE03 Positioniersteuerung Betriebsarten Umschaltung (sicher?)

34 - DST, Berlin , revised Osmoseanlage, Abwasseraufbereitung Mehrstufige Anlage soll schwach radioaktive Abwässer aufbereiten, dass das Restabwasser dem „normalen“ Abwasserstrom zugeführt werden darf. Die (radioaktiven) festen Stoffe getrocknet, einzementiert in die Endlagerung. In einer unbeobachteten Phase während des späten Abends (2001) entstand ein Brand der Teile der Anlage vernichtete. Zündquelle (durch einen Brand-SV) der Heizstab in Kreislaufbehälter aus Kunststoff (Füllmenge ca. 680 l). Trockener Behälter entflammte sich. Ventilstellungen des Verteilsystem, Betriebzustände einzelner Aggregate (Pumpen, Heizstäbe) und Füllständen weiterer Zwischentanks deuten auf „unsinnige“ Befehle der SPS hin. Theoretische Möglichkeit: überlangen Heizvorgang (Flüssigkeit verkocht).

35 - DST, Berlin , revised Beispiel (SPS Siemens S ) Das Anwenderprogramm der SPS enthielt Fehler Initiierten Heizvorgang im Kreislaufbehälter zeitlich oder temperaturgeführt? Die Pufferbatterie der SPS komplett entladen Ob ein Programm aktiv war, ist unklar Welche Programmversion war zum Schadenszeitpunkt aktiv? Entwickler stellte Version bereit (begründete Zweifel) Durfte die Anlage nachts unbeaufsichtigt gefahren werden? Hat der vorhandene Programmfehler zur Brandentstehung beigetragen? Was war die Ursache? Viel Wahrscheinlichkeit und Eventuelles - Wenig Gesichertes und Konkretes

36 - DST, Berlin , revised Brand in einer Wäscherei Die eingebaute Sprinkleranlage hat nicht ausgelöst. Ist die Maschinensteuerung (B&R) oder die Löschwassersteuerung der Brandmeldeanlage verantwortlich? Welchen Zustand wies die Anlage/Maschine vor dem Brandereignis auf? War das Wasser angestellt? Letzte Wartung, letztes Auslöseereignis – wann? SK10 Sicherheitsschalter - Zustand? Konformitätserklärung nach EN-294 war da!

37 - DST, Berlin , revised Beispiel: Menschen wirken mit Die Brandmeldeanlage und Löschsteuerung war modifiziert worden. Die Betriebselektriker waren fluktuiert. Die Löschanlage hatte vor 6 Monaten bereits einmal ausgelöst. Die Glasperlen in den SK-10 Temperaturschutz- Schaltern wurden vermutlich nach der ersten Auslösung nicht ersetzt. Die Schalter wurden elektrisch überbrückt, damit die Maschine erneut angefahren werden konnte. Keiner hat etwas gemacht….

38 - DST, Berlin , revised Kernfragen aller Beispiele Ist die Schadenentstehung eindeutig (noch) auf eine Ursache oder Ursachenfolge zurückzuführen? Sind technische Fehler objektiv vorhanden? Was ist der bestimmungsgemäße Gebrauch der Anlage? Sind die zur Vermeidung von kritischen Betriebszuständen ergriffenen Maßnahmen ausreichend? Entsprechen Sie dem Stand der Technik? Verletzen technische Fehler vertraglich geschuldete Leistungen? Ist der Schadensumfang durch Nachlässigkeiten in Konstruktion oder Betriebsweise begünstigt worden?

39 - DST, Berlin , revised Steht die vermeintliche Ursache in einem kausalen Zusammenhang mit der technisch möglichen Ablaufreihenfolge? Ist der Bediener involviert? Bei Steuerungen speziell: Kann zweifelfrei nachgewiesen werden, welche Programmvariante/ -version zum Schadenzeitpunkt aktiv innerhalb der SPS ausgeführt wurde? Anmerkung: Verdacht wird auf Anlagenteile fokussiert wo man die geringsten Einblicke hat oder die beim Schaden sogar untergegangen sind (Grauzonenverlagerung, Ablenkungsstrategie?) Kernfragen aller Beispiele

40 - DST, Berlin , revised Antworten, die nicht gefragt waren Sollten oder müssen wir Fragen außerhalb des Auftrages beantworten? Jein 1. GG: Nachfragen beim Auftraggeber Was ist, wenn Gefährdungen bestehen und erkannt wurden (Zufallsfund)? Was, wenn die Sache in die vermeintlich falsche Richtung abzudriften droht? Kennen wir den Vertrag? Kennen wir die wahre Geschichte? Was, wenn augenscheinlich technische Regeln oder gültige Normen verletzt werden? Was, wenn Manipulationen offensichtlich werden?

41 - DST, Berlin , revised Allgemeine Schwerpunkte Gebrauchstauglichkeit (Usability) Das Ausmaß, in dem ein Produkt durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient, sicher und zufriedenstellend zu erreichen. (nach DIN EN ISO ) Nutzungskontext umfasst die Benutzer, deren Ziele und Aufgaben, die Ausrüstung am Arbeitsplatz sowie die physische und soziale Umgebung (z.B. Sprache!), in der das Steuerungssystem genutzt wird.

42 - DST, Berlin , revised Schwerpunkt: Nutzung Die Nutzungsqualität von Steuerungssystemen beschreibt die Gebrauchstauglichkeit der Programmabläufe in einem hochwertigen Nutzungskontext. Ein hochwertiger Nutzungskontext umfasst eine gesunde, sichere und angemessene Arbeitsgestaltung sowie aktivierende soziale Beziehungen und Strukturen. Er ermöglicht dem Benutzer, die Arbeitsaufgaben in einem kontinuierlichen Verbesserungsprozess zu bewältigen.

43 - DST, Berlin , revised Schwerpunkt: Ergonomie Aufgabenangemessenheit Die Steuerungs-Software muss die Erledigung der Arbeitsaufgabe unterstützen, ohne durch spezielle Eigenschaften die Benutzer zusätzlich zu belasten. Erwartungskonformität Softwareabläufe müssen den Kenntnissen und Erfahrungen der Benutzer entsprechen. Dazu gehören Kenntnisse aus dem Arbeitsgebiet des Benutzers, seine Ausbildung und seine Erfahrung sowie allgemein anerkannte Konventionen. Fehlertoleranz Das System muss trotz einer Fehlbedienung stabil und funktionstüchtig bleiben. Es darf keine gefährliche Situation entstehen. Eventuelle Fehler bei der Handhabung können auch durch Beschreiben vermieden werden. Fehler müssen mit begrenztem Arbeitsaufwand beseitigt werden können.

44 - DST, Berlin , revised Schwerpunkt: Arbeitsplatz Steuerungen sind als Arbeitsmittel Teil des Arbeitssystems und deswegen verlangt das Arbeitsschutzgesetz den Einsatz ergonomisch gestalteter Arbeitsmittel. Die Grundsätze der Ergonomie sind auf die Verarbeitung von Informationen durch den Menschen anzuwenden. Aus Daten müssen Informationen generiert werden Nur aus Informationen kann Wissen entstehen Nur aus Wissen entstehen richtige Entscheidungen

45 - DST, Berlin , revised Regelungskreislauf

46 - DST, Berlin , revised Ordnung durch Regeln Steuerungssoftware wurde im deutschen Normenwerk traditionell dem Gebiet der MSR-Schutzeinrichtungen zugeordnet (MSR = Messen, Steuern, Regeln). Dies entsprach der bisherigen Rechtsprechung bis ca. 1999, die bei Haftungsfragen Fehler von Programmen als Fehler der gesamten Steuerungsanlage eingestuft hat. Internationale Sicht einheitlich als Prozesssteuerung (process control) Im Zuge der Harmonisierung Europäischer Normen in EU durchgesetzt. Zunehmend im deutschen Sprachraum adaptiert, zumal die Leistungsbereiche heutiger Technik alle Aspekte aus MSR bereits integriert haben.

47 - DST, Berlin , revised Nachvollziehbarkeit durch Regeln Regeln stehen Gesetzen nach (MRL ist Gesetz) Regeln/Normen haben Vorteile Anscheinsbeweis Entlastung Nachvollziehbarkeit Verträge können individuell alles regeln (auch anders!) Können aber auch Bezug nehmen Projekte brauchen Verträge (auch zum Vorbeugen)

48 - DST, Berlin , revised Was wirkt, wenn kein Vertrag?

49 - DST, Berlin , revised Wie sieht‘s im Markt aus? SPS programmieren kann jeder Elektriker und Maschinenbauer Ja und Nein Alte Projektkopien werden „vermodifiziert“ (passend oder nicht?) Maschinenkonstruktion und Steuerprogrammerstellung sind so von einander entkoppelt, dass gemeinsame Grundsätze und klare Verantwortungen verschwimmen. Abläufe werden programmgerecht und nicht prozessgerecht und selten selbstsicher realisiert. Reproduzierbarkeit und Rückverfolgung ist mit konstruktiven Mitteln bisher selten erreicht (Einfluss: Diagnose Deckungsgrad). Zugang zu Programmiergeräte/PC und Steuerung unterliegt keiner besonderen Sicherung bzw. Nachverfolgung. Versions-/Revisionskontrolle und Änderungsdokumentation werden selten angewendet oder kaum aktuell gehalten.

50 - DST, Berlin , revised Was bestimmt die Auswahl? Umfrage aus unter Rücklauf 603 (Bewertungsbasis)

51 - DST, Berlin , revised Was sind die Kosten?

52 - DST, Berlin , revised Wie fehlerhaft ist Software? Untersuchungen (1994), bis zu 25 Fehler pro 1000 Programmzeilen durchschnittlich. Fehlerquote 2,5 % „Gute“ Software hat heute etwa 2-3 Fehler pro 1000 Zeilen. Quote ~2,5 ‰. „Sehr gute“ SW (Bord-Software Space Shuttle) hat weniger als einen Fehler pro Zeilen. (< 1 ‰) „Sehr gute“ SW kosten aber 1000 US $/line Erstellung! Space-Shuttle-Software (3 Millionen Zeilen) sind das 3 Mrd. US $ „Sehr gute“ SW kosten in der Industrie für 1000 Programmzeilen € Testaufwand! Das bekannte Produkt Windows-95 hatte etwa zehn Millionen Programmzeilen. Wäre die Software „GUT“  enthielte das Produkt statistisch bis Fehler Mindset-Problem?? Bill Gates im FOCUS (Nr.43, 23. Oktober 1995, Seite ) ”There are no significant bugs in our released software that any significant number of users want fixed.”

53 - DST, Berlin , revised Gemeinsame, heutige Gefahren Komplexität von Systemen und Anwendungen nehmen zu Konventionelle konstruktive oder analytische Entwicklungsmethoden (?) Lebens-/Innovationszyklen der Komponenten eines Systems werden stetig kürzer Erfahrungen aus Langzeiteinsatz werden Mangelware Qualifizierte, kompetente und erfahrende Know-how-Träger fehlen Prüfaufwand im Verhältnis zur Nutzung unwirtschaftlich 100% Tests sind äußerst selten geworden. Verifikation/Validation wird unvollständig bzw. isoliert für Teilsysteme Abweichungen in der Realisierung von „Standards“ auf unterschiedlichen Teilgewerken (Bereichen) Fehlerbehandlung unterschiedlich, Risikobewertung verschieden Online (on-the-fly) „Verprogrammierung“ (schnell mal eben...) Vieles wird heute „zusammengeklickt“ oder „gebrowsed“ War ein Konzept vorhanden und auch bekannt?

54 - DST, Berlin , revised Ursachen von Unterlassungen Unterschätzen der Aufgabenstellung Offensichtliche Fehler (Tippfehler, Entwurfsfehler im Abstraktionsmodel, Testfehler...) Fehlende Sicherheitsabfragen ( unvorhergesehene Fälle treten auf ) Vertrautheit fehlt (neue Fehlerquellen) Numerische Rundungsfehler, Race Conditions, Prioritäten Ungeprüfte Wiederverwendung alter Programmbausteine Nicht ausreichend (reale) Tests Schnittstellenfehler (Programmteile, Komponenten, Libraries passen nicht zusammen) Software und Hardware passen nicht mehr zusammen Fehlinterpretation in den Ein/Ausgabe-Daten Gigantismus (Titanic-Effekt)

55 - DST, Berlin , revised Häufige begleitende Fehler Kein Konzept (insbesondere kein Sicherheitskonzept) Gefährdungsanalyse, Risikobewertung, Ausfallszenario Fehlendes Verständnis technischer Art Eigene Anforderungen unklar (nicht definiert oder fixiert) Fehlerhafte Anwendung, Werkzeuge, … Falsche Partner – Outsourcing Effekte Kostenbewertung isoliert (meine Inder können das dreimal programmieren und es bleibt immer noch ein Gewinn) Solziale Komponente: Wertschätzung Unrealistische Terminabläufe Subjektive Drucksituation führt zur Eile und zu mangelnder Sorgfalt

56 - DST, Berlin , revised Wie kann es besser werden? Prozessablauf der EN bzw. EN ISO in 5 Schritten einhalten: Gefährdungsanalyse und Risikobeurteilung. Bewertung! Entscheiden über Maßnahmen zur Risikoverringerung durch Steuerungsmittel Festlegen der sicherheitstechnischen Anforderungen für sicherheitsbezogene Teile der Steuerung Gestalten und Verifizieren Validieren

57 - DST, Berlin , revised Weg vom Fehlerbeseitigen. Hin zum Fehlervermeiden Studien/Planung: Unified Modeling Language (UML), Sicherheitsbedürfnis/-Risiko-Beschreibung Konzeption: Prototyping, Muster-Engineering Realisierung/Erstellung: In Software die Lebenszyklen der Maschine ebenfalls nachvollziehen. Operativ: z.B. Praxis S7 (Graph7) Schrittkettengestaltung (Führung der Programmierung) Stark Operativ: Diagnoseinformation sammeln und archivieren. Wie kann es besser werden?

58 - DST, Berlin , revised Wie kann es besser werden? Anwender/Nutzer-Horizont in den Mittelpunkt einer Risikobewertung Als kontinuierlichen und fortzuschreibenden Prozess begreifen Umfeld bei der Auswahl der Bauteile und Gestaltungsgrundsätze kennen und beachten Budgets der Risikoklasse und dem PL oder SIL anpassen (Wahrscheinlichkeiten zum Fehlereintritt) Personal neu ausbilden, sensibilisieren und ausrichten Bei Gefahr für Menschen simulieren, testen, verifizieren, validieren. KOSTEN sind erheblich! Spannungsfeld (Termine/Resourcen/Abhängigkeiten) aktiv steuern Kommerzielle Zwangsjacken frühzeitig identifizieren Grundsatz KISS, Anleihen XP oder V-Modell® XT helfen (z.B. XP [eXtreme Programming] Praktiken und Methoden ansehen) V-Modell XT ist eine Weiterentwicklung des 1997 veröffentlichten V-Modell 97

59 - DST, Berlin , revised Diagnose Deckungs-Grad Fehlermanagement, aber wie? Kontinuierlich und Automatisch Online Qualitätsmessungen Statistische und/oder stochastische Auswertung Vorausschauende Wartung Trend-Kontrolle Informationen korrelieren (nicht Daten vergleichen!) Fehlerspeicher, Kurzzeitarchive (transition recording) Ereignis-Logging (z.B. Betriebsarten-Umschaltung, Teachen)

60 - DST, Berlin , revised Fehler – Einfluss Bewertung Konzept Betrieb

61 - DST, Berlin , revised Ein paar Anmerkungen Wenn prEN ISO :2004 die EN ersetzt (vermutlich dieses Jahr) Performance Level einer Maschine oder Anlage Wann nimmt man wann?

62 - DST, Berlin , revised Kann man prozessorientiert, sicher und effizient steuern? Ja! Fragen und ein kleines praktisches Beispiel F a z i t - Mit der räumlichen sowie geistigen Distanz zu Problemen nimmt der Enthusiasmus zur Fehleinschätzung zu - Danke für die Zeit Vortragsskriptum

63 - DST, Berlin , revised Kleine Belohnung Optimal prozessorientiere Steuerung Vortragsskriptum

64 - DST, Berlin , revised Glossar DC Diagnostic Coverage MTTF mean time to (dangerous) failure CCF Common Cause Failure (Factor) SIL Safety Integrity Level PL Performance Level FEMA Fault Tree Analysis SPIRE Diagnose Deckungsgrad Mittlere Zeit bis zum Fehler gemeinsamer Ursache Fehler gemeinsamer Ursache Integritätsstufe für sicherheitsrelevante Teile Fehler-Möglichkeits-und – Einfluss-Bewertung

65 - DST, Berlin , revised Referenzen / Quellen Siemens Automatisierung: Schriften der Simatic Familie Gunhild Lütge: Amoklauf der Maschinen. Die Zeit. 2. April 1993, S. 23–24, Prof. Dr. Klaus Pommerening, Johannes-Gutenberg-Universität Mainz, IT-Sicherheit in der Medizin, K. Beck, Extreme Programming Explained, Addison-Wesley, 1999 K. Beck, Test-Driven Development by Example, Addison-Wesley, 2003 K. Beck, E. Gamma, Test Infected: Programmers Love Writing Tests, siehe: Herbert Klaeren, Die artifiziellen Paradiese der Informatik ComputingCases ml, ml Strukturierte Erstellung von Sicherheitsspezifikationen in UML mit Hilfe der FMEA- Methode1, Friedemann Bitsch, Ercüment Canver, Adam Moik. FORMS-Workshop 12/99, Braunschweig Schaefer, M.; Gnedina, A.; Bömer, T.; Büllesbach, K.-H.; Grigulewitsch, W.; Reuß, G.; Reinert, D.: Programmierregeln für die Erstellung von Software für Steuerungen mit Sicherheitsaufgaben, Bundesanstalt für Arbeitsschutz und Arbeitsmedizin – BAuA (Hrsg.), Bremerhaven 1998 [prEN 50128] Bahnanwendungen – Software für Eisenbahnsteuerungs- und – Überwachungssysteme

66 - DST, Berlin , revised Referenzen / Quellen Nuefelder, A. M., Ensuring Software Reliability, Marcel Dekker, New York, NY, Goble, W. M., Control Systems Safety Evaluation and Reliability, ISA, Research Triangle Park, NC, Software Bug Contributed to Blackout By Kevin Poulsen, SecurityFocus Feb :55PM Cyber-Security: Are Plant Operations Vulnerable? Brian M. Ahern, President and CEO, Verano Inc., September 16, 2003 Reliability in Control Systems Software, Dr. William M. Goble, Principal Partner ‘Critical Infrastructure Security and You’, Rik Farrow, Network Magazine, October 5, Focus Zeitschrift (Gates Interview) C‘t Computerzeitschrift (Automatisiertes Haus) BG-Information „Management und Software - Arbeitshilfen zur Erhöhung der Nutzungsqualität von Software im Arbeitssystem“ (SP 2.11/2) (BGI 852-2) BG-Information „Einrichten von Software – Leitfaden und Check für Benutzer“ (SP 2.11/3) (BGI 852-3) BG-Information „Software-Kauf und Pflichtenheft – Leitfaden und Arbeitshilfen für Kauf, Entwicklung und Beurteilung von Software“ (SP 2.11/4) (BGI 852-4) Wieland, R.; Koller, F.: Bildschirmarbeit auf dem Prüfstand der EU-Richtlinien. Konzepte, Strategien und betriebliche Erfahrungen, Bundesanstalt für Arbeitsschutz und Arbeitsmedizin – BAuA (Hrsg.), Bremerhaven 1999

67 - DST, Berlin , revised Referenzen / Quellen EN 1050 (ISO 14121), Sicherheit von Maschinen. Prinzipien der Risikobeurteilung. EN :2001, Funktionale Sicherheit von elektrischen/elektronischen/ programmierbar elektronischen sicherheitsrelevanter Systeme. Teil 4: Definitionen und Abkürzungen (IEC : Änderung 1999). EN ISO :2003, Sicherheit von Maschinen. Grundbegriffe, allgemeine Gestaltungsleitsätze. Teil 1: Grundsätzliche Terminologie, Methodologie (ISO :2003). EN ISO :2003, Sicherheit von Maschinen. Grundbegriffe, allgemeine Gestaltungsleitsätze. Teil 2: Technische Leitsätze (ISO :2003). EN ISO :2003, Sicherheit von Maschinen. Sicherheitsbezogene Teile von Steuerungen Teil 2: Validierung (ISO :2003). "eigensichere" elektrische Ausrüstungen (siehe EN 50020); Ergonomische Anforderungen and Maschinenschnittstellen, siehe EN 614-1, ISO 6385, EN und IEC Konstruktion elektrischer Ausrüstungen von Maschinen siehe IEC :1997 IEC :1990, International electrotechnical vocabulary. Chapter 101: Dependability and quality of


Herunterladen ppt "- DST, Berlin 18.3.2005, revised 2008 -1 Prozessorientierte Steuerung von Maschinen Rekonstruktion von Schadenereignissen Prozessorientierte."

Ähnliche Präsentationen


Google-Anzeigen