DECUS, Frankfurter Treffen 2004 Wilhelm Uhlenberg wu@sv-uhlenberg.de Software als kritische Masse 1.10.2004 Prozessorientierte Steuerung von Maschinen Rekonstruktion von Schadenereignissen „Maschinensicherheit und Steuerung!“ Diametraler Widerspruch? Wilhelm Uhlenberg wu@sv-uhlenberg.de SPS, PLC, CNC, NC, MC, DCS Vortrag zum Deutschen Sachverständigentag 18.3.2005 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 - www.itexpert.de

DECUS, Frankfurter Treffen 2004 Software als kritische Masse 1.10.2004 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 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 - www.itexpert.de

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 www.it-schlichtung.de Mitglied der Fachgruppe Elektronik und EDV im BVS seit 2002 http://www.sv-edv.de/member/pdf/uhlenberg.pdf Vortragsskriptum http://www.sv-uhlenberg.de/artikel.htm http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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 … http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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. http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Was wünschen wir? - DST, Berlin 18.3.2005, revised 2008 - http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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? http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Orientierung (2) 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! http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Warum Steuerungen? Die selektive Wahrheit ... Funktionieren, sicher und schnell Einfach und flexibel anpassbar durch Programmierung Wirtschaftlich durch Standardisierung Pflegbar und erweiterbar http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Warum Steuerungen? 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?) http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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 12100-2 (war EN 292-2), EN 60204 [elektrische Ausrüstung], EN 1050 [Gefährdung/Risiko]). Habe fertig … (Giovanni Trappatoni, 1998) http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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

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 61508 zu beachten. (Prozesstechnische Anlagen mehr IEC 61511, [hoch]mathematischer Ansatz). EN ISO 13849 (ab 9 2005) und EN IEC 62061 geben Anleitungen spezifisch für die Sicherheit von Maschinensteuerungen (meist elektronischen). EN ISO 13849-1 soll zukünftig die anwendbare Symbiose aus EN 954-1 und IEC 61508 für elektrisch basierte Steuerungssystem darstellen. http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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 62061 und EN ISO 13849-1. Die Bemessungsgröße für diese Abstufung ist bei EN IEC 62061 (wie in IEC 61508) der Safety Integrity Level (SIL) und bei EN ISO 13849-1 der Performance Level (PL). Bei umfangreichen Projektrealisierung solcher Anteile/Anlagen ist Risikomanagement nach IEC 62198 weiterführen. http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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) http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Wie werden Risiken analysiert? http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Wann muss man was machen? http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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. http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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 13861 und IEC 61310-1. http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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). http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Problembewusstsein 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 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

DECUS, Frankfurter Treffen 2004 Software als kritische Masse 1.10.2004 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 … http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 - www.itexpert.de

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? http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Das wahre Leben? - DST, Berlin 18.3.2005, revised 2008 - http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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! http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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? http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

1. 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 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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. http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Anlagenausschnitt - DST, Berlin 18.3.2005, revised 2008 - http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

2. Beispiel (Siemens S7-315) Problem mit der Sollposition des Greifers Bosch-Rexroth ECUDRIVE03 Positioniersteuerung Betriebsarten Umschaltung (sicher?) http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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). http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

3. Beispiel (SPS Siemens S7 413-2) 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 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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! http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

4. 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…. http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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? http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Kernfragen aller Beispiele 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?) http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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? http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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 9241-11) 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. http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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. http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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. http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Regelungskreislauf - DST, Berlin 18.3.2005, revised 2008 - http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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. http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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) http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Was wirkt, wenn kein Vertrag? http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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. http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Was bestimmt die Auswahl? Umfrage aus 8 2001 unter 6008. Rücklauf 603 (Bewertungsbasis) http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Was sind die Kosten? - DST, Berlin 18.3.2005, revised 2008 - http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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 10000 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 1.600 -10.000 € Testaufwand! Das bekannte Produkt Windows-95 hatte etwa zehn Millionen Programmzeilen. Wäre die Software „GUT“  enthielte das Produkt statistisch 20.000 bis 30.000 Fehler Mindset-Problem?? Bill Gates im FOCUS (Nr.43, 23. Oktober 1995, Seite 206-212) ”There are no significant bugs in our released software that any significant number of users want fixed.” http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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? http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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) http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Häufige begleitende Fehler DECUS, Frankfurter Treffen 2004 Software als kritische Masse 1.10.2004 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 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 - www.itexpert.de

Wie kann es besser werden? Prozessablauf der EN 954-1 bzw. EN ISO 12100-1 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 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Wie kann es besser werden? 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. http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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) http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Fehler – Einfluss Bewertung Konzept Betrieb http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Ein paar Anmerkungen Wenn prEN ISO 13849-1:2004 die EN 954-1 ersetzt (vermutlich dieses Jahr) Performance Level einer Maschine oder Anlage Wann nimmt man wann? http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

Kann man prozessorientiert, sicher und effizient steuern? DECUS, Frankfurter Treffen 2004 Software als kritische Masse 1.10.2004 F a z i t Kann man prozessorientiert, sicher und effizient steuern? - Mit der räumlichen sowie geistigen Distanz zu Problemen nimmt der Enthusiasmus zur Fehleinschätzung zu - Ja! Fragen und ein kleines praktisches Beispiel Vortragsskriptum http://www.sv-uhlenberg.de/artikel.htm Danke für die Zeit http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 - www.itexpert.de

Kleine Belohnung Optimal prozessorientiere Steuerung Vortragsskriptum http://www.sv-uhlenberg.de/artikel.htm Optimal prozessorientiere Steuerung http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

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, http://www.uni-mainz.de/~pommeren/Artikel/stmed.pdf , 22.06.2003 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: http://members.pingnet.ch/gamma/junit.htm Herbert Klaeren, Die artifiziellen Paradiese der Informatik ComputingCases http://www.computingcases.org/case_materials/therac/case_historyurl/Case%20History.html , 18.06.2003 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 http://www.safety.com , http://www.iso.ch/ , http://web.ansi.org/ , http://www.din.de/ http://www.zh1.de/ , http://www.sfk-taa.de/ , http://www.bsi-global.com/ http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 -

DECUS, Frankfurter Treffen 2004 Software als kritische Masse 1.10.2004 Referenzen / Quellen Nuefelder, A. M., Ensuring Software Reliability, Marcel Dekker, New York, NY, 1993. Goble, W. M., Control Systems Safety Evaluation and Reliability, ISA, Research Triangle Park, NC, 1998. Software Bug Contributed to Blackout By Kevin Poulsen, SecurityFocus Feb 11 2004 3: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 http://www.exida.com ‘Critical Infrastructure Security and You’, Rik Farrow, Network Magazine, October 5, 2002 -http://www.networkmagazine.com/article/NMG20020930S0008 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 http://www.sv-uhlenberg.de/ - DST, Berlin 18.3.2005, revised 2008 - www.itexpert.de

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