DECUS, Frankfurter Treffen 2004 Wilhelm Uhlenberg

Präsentation zum Thema: "DECUS, Frankfurter Treffen 2004 Wilhelm Uhlenberg"—  Präsentation transkript:

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

2 DECUS, Frankfurter Treffen 2004
Software als kritische Masse 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 - DST, Berlin , revised

3 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 2002 Vortragsskriptum - DST, Berlin , revised

4 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 … - DST, Berlin , revised

5 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. - DST, Berlin , revised

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

7 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? - DST, Berlin , revised

8 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 - DST, Berlin , revised

9 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! - DST, Berlin , revised

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

11 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?) - DST, Berlin , revised

12 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) - DST, Berlin , revised

13 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 - DST, Berlin , revised

14 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 - DST, Berlin , revised

15 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. - DST, Berlin , revised

16 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. - DST, Berlin , revised

17 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) - DST, Berlin , revised

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

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

20 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 - DST, Berlin , revised

21 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. - DST, Berlin , revised

22 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 - DST, Berlin , revised

23 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). - DST, Berlin , revised

24 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 - DST, Berlin , revised

25 DECUS, Frankfurter Treffen 2004
Software als kritische Masse 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 … - DST, Berlin , revised

26 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? - DST, Berlin , revised

27 Das wahre Leben? - DST, Berlin 18.3.2005, revised 2008 -
- DST, Berlin , revised

28 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! - DST, Berlin , revised

29 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? - DST, Berlin , revised

30 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 - DST, Berlin , revised

31 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. - DST, Berlin , revised

32 Anlagenausschnitt - DST, Berlin 18.3.2005, revised 2008 -
- DST, Berlin , revised

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

34 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). - DST, Berlin , revised

35 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 - DST, Berlin , revised

36 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! - DST, Berlin , revised

37 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…. - DST, Berlin , revised

38 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? - DST, Berlin , revised

39 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?) - DST, Berlin , revised

40 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? - DST, Berlin , revised

41 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. - DST, Berlin , revised

42 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. - DST, Berlin , revised

43 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. - DST, Berlin , revised

44 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 - DST, Berlin , revised

45 Regelungskreislauf - DST, Berlin 18.3.2005, revised 2008 -
- DST, Berlin , revised

46 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. - DST, Berlin , revised

47 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) - DST, Berlin , revised

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

49 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. - DST, Berlin , revised

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

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

52 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.” - DST, Berlin , revised

53 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? - DST, Berlin , revised

54 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) - DST, Berlin , revised

55 Häufige begleitende Fehler
DECUS, Frankfurter Treffen 2004 Software als kritische Masse 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 - DST, Berlin , revised

56 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 - DST, Berlin , revised

57 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. - DST, Berlin , revised

58 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 - DST, Berlin , revised

59 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) - DST, Berlin , revised

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

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

62 Kann man prozessorientiert, sicher und effizient steuern?
DECUS, Frankfurter Treffen 2004 Software als kritische Masse 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 Danke für die Zeit - DST, Berlin , revised

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

64 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 - DST, Berlin , revised

65 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 , 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 , , , , , - DST, Berlin , revised

66 DECUS, Frankfurter Treffen 2004
Software als kritische Masse 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 :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 - DST, Berlin , revised

67 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 - DST, Berlin , revised