# Industrie 4.0 und Maschinensicherheit



## Safety (31 Dezember 2016)

Hallo,
zuerst ich weiß I 4.0 ist keine Revolution, es ist ein über Jahrzehnte währender Entwicklungsprozess der durch die wachsenden Rechnerleistungen zu schnellem und vernetzten Komponenten führt, also nichts neues und nicht jede Anwendung oder Anwender braucht sowas.
Zweitens was mich stört ist das alles neu sein soll und es nur noch um das eine Thema geht.
Nun zum Thema, da ich durch die Marketingmaschinen der Industrie immer öfter nachfragen bekomme, was I 4.0 für die Maschinensicherheit bedeutet, wollte ich dieses Thema auch im Forum mal aufgreifen und nach euren Erfahrungen Fragen, aber die haben nichts mit I4.0 zu tun da es ja ein über Jahrzehnte andauernder Prozess handelt.
Zu meinen Erfahrungen, was hat sich eigentlich geändert?
Haben wir andere Gefährdungen? Quetschen, Scheren…… Nein.
Spezialanwendungen wie z.B Laser, Röntgen usw. gab und gibt es auch schon länger.
Werden die Maschinenschneller durch I4.0, nein, das liegt zum Teil daran das es bessere Antriebskonzepte gibt, aber das kam auch nicht über Nacht.
Aus meiner Sicht, werden die Komponenten komplexer und Intelligenter und es gibt mehr Software um eine Programmierung oder Parametrisierung durchführen zu können.
Ein paar Beispiele dazu:



SPS, es kommen immer mehr F-SPS zur Anwendung was auch Sinn macht da man viel mehr Möglichkeiten hat um Sicherheitsfunktionen umzusetzen. Dazu kommt das man alles vernetzt. Also kommt hier eine weitere wichtige Fehlerquelle hinzu die SRASW Software, ja es gibt hier normative Vorgaben die nichts weiter fordern als eine Durchgängige Planung und Konstruktion, aber es führt dazu das eine weitere Personengruppe sich mit dem Thema Safety auseinandersetzen muss, die Programmierer. Bei den reinen Hardwarelösungen, waren viel der Konstrukteure mittlerweile Geschult und die gemachten Fehler hielten sich in Grenzen. Nach meiner Erfahrung hat diese Personengruppe in vielen Betrieben noch Schwierigkeiten mit der Umsetzung. Das liegt nicht an den Personen, sondern an der fehlenden Durchgängigkeit von Risikobeurteilung zur Sicherheitsfunktion und dann auch zur SRASW. Es gibt keine bzw. nur unzureichende Vorgaben was die SRASW zu leisten hat. Es bleibt dem Programmierer nichts andere übrig sich die Funktionen aus persönlichen Gesprächen und den Schaltungsunterlagen herauszusuchen und einfallen zu lassen. Das führt dann unweigerlich zu Fehlern. Dies trifft nicht auf alle Firmen zu, aber ich validiere SRASW und finde da oft Fehler, so dass ich aus meiner Erfahrung sagen kann dies ist der zurzeit häufigste Fehler.
Nun der Sprung zu noch mehr Software da I 4.0, wird es so sein das jede Komponente mehr Funktionen bekommt und dann auch noch Software, dann führt das zu mehr Fehlern!?



Antriebsregler mit integrierten Sicherheitsfunktion nach DIN EN 61800-5-2, schön ist das man in der Maschinensicherheit mehr Möglichkeiten hat. Aber auch hier trifft alles was zur SPS gesagt wurde auch zu. Oft fehlen hier die Abnahmen der einzelnen Sicherheitsfunktion komplett.


Also zusammenfassend, ich kann in der Maschinensicherheit die Revolution nicht erkennen da es sich schon über längere Zeit abzeichnet das immer mehr Komponenten mit integrierten Sicherheitsfunktion auf den Markt kommen. Aber durch die Vielzahl von Software und Funktionen kommt es hier bei der SRASW und Parametrisierung zu mehr Fehlern.


----------



## Blockmove (31 Dezember 2016)

Vernetzung bringt eindeutig neue Gefahren.
Ganz simples Beispiel ist der Remotezugriff.

Musste man früher noch vor Ort sein um ein Gerät zu konfigurieren, so kann ich heute von zu Hause die Sicherheitsfunktionen in einem Antrieb ändern.
Viele Passworte sind nur 4stellig und stellen somit kein Problem dar. Jeder Schutztürschalter muss heute mit XYZ-Superspecial-Schrauben vor Manipulation gesichert sein.
Die RJ45-Netzwerkbuchse ist es nicht.

Guten Rutsch
Blockmove


----------



## Safety (31 Dezember 2016)

Hallo Dieter,
ja das Thema Securitiy ist ein Thema welches durch die Vernetzung auch mehr in den Vordergrund rückt, aber das Thema Viren einschleusen kam auch schon über die Programmiergeräte zum Tragen.
Wie viele Fälle von unsicheren Maschinen durch einen Hackerangriff oder Viren und wie viele manipulierte Schutztürschalter sind Dir bekannt, denke daran merkt man auf was zurzeit der Fokus liegt.
Die Möglichkeit einen SRASW oder Software aus der Ferne anzupassen, ist eine Gefährdung die aber zu dem Thema Software Validierung und Abnahme passt.
Auch Dir guten Rutsch.


----------



## Blockmove (31 Dezember 2016)

Safety schrieb:


> Hallo Dieter,
> ja das Thema Securitiy ist ein Thema welches durch die Vernetzung auch mehr in den Vordergrund rückt, aber das Thema Viren einschleusen kam auch schon über die Programmiergeräte zum Tragen.
> Wie viele Fälle von unsicheren Maschinen durch einen Hackerangriff oder Viren und wie viele manipulierte Schutztürschalter sind Dir bekannt, denke daran merkt man auf was zurzeit der Fokus liegt.



Ich denke hier nicht an Viren oder Hacker, sondern an eine ganz einfache menschliche Fehler, Irrtümer und Manipulation.
Bei keinem Sicherheitsgerät muss ich mich anständig "ausweisen" (authentifizieren). Klar ändert sich eine CRC-Prüfsumme ... Und die kontrolliert wer und wann?
Wie bereits geschrieben, haben viele Geräte nur 4 Ziffern. Mir ist selber schon passiert, dass ich STO auf dem falschem Umrichter deaktiviert habe.


----------



## Tommi (31 Dezember 2016)

Hallo Dieters,

es gibt ja Ansätze und Normen, wie sicherheitsgerichtete Software aussehen soll. Da haben Safety
und ich ja vor ein paar Jahren schon mal drüber diskutiert.
Es stimmt, immer mehr Sicherheitsfunktionen kommen aus der Software und viele Programmierer
setzen sie so um, als wäre es Standardsoftware.
Es gibt ja bald sowas hier:
http://www.dguv.de/ifa/praxishilfen/praxishilfen-maschinenschutz/software-softema/index.jsp
aber bis das alle erreicht hat, wird eine lange Zeit vergehen.
Bei kollaborierenden Robotern z.B. ist auch die Funktionssoftware sicherheitsrelevant und die Parametrierung
erst recht.
Ich beobachte, daß das 4-Augen-Prinzip fast völlig unbekannt ist, sowohl in Unternehmen als auch
an Hochschulen. 

Das Thema Security steht noch auf einem ganz anderen Blatt.

Was können wir tun? Beharrlich an der Sache dranbleiben.

Gruß
Tommi

PS: Diejenigen, die hier im Forum über Sicherheitstechnik schreiben, sind die
Spitze des Eisberges aller Programmierer, die, denke ich, die Regeln einhalten

Guten Rutsch mit hohem Performancelevel...:sm24:


----------



## Blockmove (1 Januar 2017)

Tommi schrieb:


> Was können wir tun? Beharrlich an der Sache dranbleiben.



Zuerstmal:
Ein gutes Neues Jahr!

Dran bleiben ja ... Aber letztlich sind wir nur das Plankton im Sicherheits-Ozean.
Egal ob Maschinen- oder Netzwerksicherheit. Wie in jedem Ökosystem gibt es Symbiosen und auch Parasiten 

Gruß
Blockmove


----------



## Tommi (1 Januar 2017)

Hallo Dieter,

ebenfalls Frohes Neues Jahr!

Naja, ich würde sagen, wir sind nicht das Plankton, sondern mindestens eine
Herde Schwertwale.
Und Du hast sogar die Aussicht, dieses Jahr der Leitbulle zu werden. 

Gruß
Tommi


----------



## Blockmove (1 Januar 2017)

Tommi schrieb:


> Naja, ich würde sagen, wir sind nicht das Plankton, sondern mindestens eine
> Herde Schwertwale.
> Und Du hast sogar die Aussicht, dieses Jahr der Leitbulle zu werden.



Tja ... Da lass ich mich einfach mal überraschen 

Aber bei den Themen Sicherheit (egal ob Maschinen oder Netzwerk) wäre ich zwar gerne Schwertwal, bin da aber wirklich nur Plankton


----------



## Ralle (2 Januar 2017)

@Safety

Ich weiß natürlich, dass du das durchaus kritisch hinterfragst.
Aber hier mal ein ganz aktuelles Beispiel: 

https://www.heise.de/newsticker/mel...fiziert-3584043.html?wt_mc=rss.ho.beitrag.rdf

So lange so etwas denkbar ist, ist für mich "Industrie 4.0" (da lach ich schon beim Namen, anders können sich unsere hellen Manager- und Politikerköpfe wohl nicht, merken worum es geht) nicht mal ein Thema, über das ich ernsthaft nachdenken will, schon gar nicht im Bereich Sicherheit.

Ich persönlich kenne jemanden, der bei einem Brand fast nicht aus seinem Haus gekommen wäre, weil alle Fensterläden dicht machten.
Da fehlt dann nur noch der Hacker oder das Scriptkiddy, der die Haustür verschlossen hält und eine Message schickt, dass du eben mal 3 Bitcoin überweisen sollst, um rauszukommen.
Auch in der 'ct 1/2017 gibt es dazu eine schöne literarische Vorlage.


----------



## Safety (2 Januar 2017)

Hallo Ralle,
ich denke aus meinem Beitrag kann man erkennen das wir da Gedanklich nicht so weit auseinanderliegen und ich habe auch klar herausgestellt das die Sache schon über Jahrzehnte geht.
Die aus der Vernetzung und die damit verbundenen vielen Programme sind für mich das Problem, die Technik kann vieles aber man muss dann auch anders mit dem Thema umgehen.
Und was Du ansprichst ist doch eher Security?


----------



## Thomas_v2.1 (2 Januar 2017)

Mit Safety und Security ist das so ein Problem, dafür gibt es im Deutschen nur ein einziges Wort "Sicherheit".

Wenn ich vor einem Bombenangriff in den Bunker flüchten muss, bin ich dort zwar in Sicherheit. Aber ich fühle mich in einem Bunker nicht sicher. In Sicherheit bin ich erst, wenn ich weiß dass Frieden herrscht und ich keinen Bombenangriff erwarte (vgl. Silvester unter Schutz von 1700 mit MGs bewaffneten Polizisten zu feiern).


----------



## Safety (2 Januar 2017)

Hallo,
Ich habe dieses Thema gestartet um ein technisches Problem zu diskutieren und von den Antworten zu lernen, da ich weiß das hier viele erfahrene Konstrukteure und Programmierer unterwegs sind. Sonst nichts!
@ Thomas_v2.1, warum Du jetzt mit Welt- und Tagespolitik kommst entzieht sich meinem Verständnis. Bitte bleibe doch Sachlich.
Zurück zur Technik:
Ja beides Safety und Security können zu Gefährdungen führen, aber man hat es eben in zwei Begriffe aufgeteilt was für mich auch Sinn macht.
Das Thema Security steckt bei vielen, besonderes bei kleineren, Betreibern noch in den Kinderschuhen, die IT Abteilungen werden aber immer mehr eingebunden und es gibt Regeln wie man mit z.B. USB Sticks und Fernwartungen umgegangen werden muss. Mir ist bisher kein Fall bekannt in dem ein Security Problem zu einer direkten Gefährdung an einer Maschine für einen Menschen geführt hat. Wie sind da eure Erfahrungen, wie geht Ihr damit um.
Ist es ein Thema für die Risikobeurteilung? Ich finde ja.


----------



## Ralle (2 Januar 2017)

@Safety

Ja da hast du natürlich Recht.
Um auf deine Frage zurückzukommen, natürlich führt das zu mehr Fehlern und je komplexer die Safety-Mafia (entschuldige bitte diesen rüden Ausdruck) das Ganze macht, umso mehr Fehler können passieren.
Hier noch eine Vorschrift und dort noch ein wenig an den Anforderungen gedreht und schon können wir die Sicherheitschalter von Gestern wegschmeißen und die doppelt so teuren von Heute kaufen.
Das klingt natürlich polemisch, ist aber nicht so weit von der Wahrheit entfernt.
In Summe wird es aber nach meinem Ermessen tatsächlich etwas sicherer, weil wir inzwischen einen dermaßen Overkill in punkto Sicherheit an der Maschine betreiben, dass bei offerner Tür ohnehin kaum mehr etwas bewegt werden kann. Und den "sog.Totmannschalter"  hatten wir schon vor 20 Jahren, da hat der auch schon funktioniert, war aber wesentlich unsicherer!!! Zumindest mathematisch.
Ich bin immer besonders froh, dass unsere Kunden bestimmte Schütze alle 1-2 Jahre austauschen, weil dann die max. zulässigen Schaltspiele erreicht sind. Warum stellen die Teile nicht einfach ihre Arbeit ein, wenn es soweit ist, das wäre mal sicher, besonders im Ozeandampfer oder im Flugzeug. Also insgesamt braucht man inzwischen eigenlich wirklich Leute wie dich oder zumindestens einen Hauptamtlichen der die Arbeit der Programmierer auch prüft. Ich fühle mich jedenfalls mit dem ganzen Kram inzwischen reichlich am Limit, denn das ist ja nicht meine Hauptprofession.


----------



## Bernd_Otter (2 Januar 2017)

Hallo an Alle und ein Frohes Neues,

hier einmal ein aktueller Artikel zu dem Thema:
http://www.industr.com/A-und-D-Magazin/de_DE/themen/Panorama/safety-durch-security-1975764

Ich  denke es ist unbestreitbar, dass ein fehlerhaftes Security-Konzept  Auswirkungen auf das Sicherheitskonzept haben kann. Hier nochmal ein  älterer Link zu der Manipulation eines Straßenbahnsystems durch einen  Teenager mit einigen Verletzten. Durch eine bessere Absicherung der  Kommunikation hätte das vermieden werden können.
http://www.theregister.co.uk/2008/01/11/tram_hack/

Mir  stellt sich nur die Frage wie bzw. wer die notwendigen Security und  Safety-Maßnahmen bewertet und festlegt. Macht die Safety-Abteilung die  normale Arbeit und gibt die Auswertung an die Security-Abteilung, die  dann auf dieser Basis die Security-Maßnahmen auslegt? Oder sollte  bereits während der Risikoanalyse der Safety-Abteilung die  Risikoerhöhung durch mögliche Cyberattacken mit berücksichtigt werden?




Safety schrieb:


> Ist es ein Thema für die Risikobeurteilung? Ich finde ja.



Abschließend finde ich also auch, dass das Thema zweifelsohne in die Risikobeurteilung gehört. Der Umfang muss diskutiert werden.

Viele Grüße


----------



## Blockmove (2 Januar 2017)

Bernd_Otter schrieb:


> Abschließend finde ich also auch, dass das Thema zweifelsohne in die Risikobeurteilung gehört. Der Umfang muss diskutiert werden.



Wie üblich in Europa wird auch dieses Thema in Normen gepackt 
Das Problem ist hier aktuell aber anderer Natur:
Die Gefahren sind bekannt.
Die Gegenmassnahmen auch.
Aber es fehlen an allen Ecken eund Enden die Spezialisten hierfür.
Egal ob die Security nun im S7-CP oder im Cisco-Switch steckt, es gibt nicht genügend Fachleute.
Nimmt man die ganzen Kommunikationsbeziehungen, die in einer vernetzten Fertigung stecken und will diese in ein vernünftiges Security-Konzept packen, dann ist man damit nicht nur 10 Minuten beschäftigt.

Gruß
Blockmove


----------



## Bernd_Otter (2 Januar 2017)

Blockmove schrieb:


> Wie üblich in Europa wird auch dieses Thema in Normen gepackt
> Das Problem ist hier aktuell aber anderer Natur:
> Die Gefahren sind bekannt.
> Die Gegenmassnahmen auch.
> ...



Das ist natürlich korrekt. Momentan sprießen neue Studiengänge die speziell den Securitybereich der Industrie abdecken wie Pilze aus dem Boden.

Ein weiteres Problem ist meiner Meinung nach im von Dir angesprochenen Bereich der Normung zu suchen. Hier treffen Maschinenbauer (eher safety) und Informatiker (eher security) aufeinander, die in einigen Punkten einfach komplett unterschiedliche Denkweisen haben. Das Kompetenz- und Sichtweisengerangel wird hier glaube ich noch einiges an Zeit kosten.


----------



## Safety (2 Januar 2017)

Hallo, sehe ich auch so, wenn ich mit einem IT Speziallisten über das Thema Maschinensicherheit spreche versteht der erstmal nicht worum es geht, der sieht die Funktion und will wie auch immer verhindern das an dem System unerlaubte Änderungen vorgenommen werden können.
Eigentlich hat er ja auch Recht, den ein Sicherheitssystem das Funktioniert (hiermit meine ich die Sicherheitsfunktionen richtig ausführt) ist ja auch sicher.
Nur eine Veränderung, Hacker, Viren was auch immer bringt da eine mögliche Gefährdung. Wie geschrieben habe ich das Szenario noch nicht erlebt, aber es ist ohne große Schwierigkeiten möglich.
Ich denke auch das die Safety und Security Menschen da mehr zusammenarbeiten müssen.
In der Risikobeurteilung muss man erst einmal die Gefährdung der Veränderung erkennen und dann braucht es einen weiteren Speziallisten der Analysiert und dann die Maßnahmen vorschlägt, ob bei der schnelllebigen IT Welt eine Norm die schon 10 Jahre bis zur Erstellung braucht eine Chance hat, mal sehen. Ja die Fachleute wachsen auch da nicht auf den Bäumen.


----------



## Blockmove (3 Januar 2017)

Safety schrieb:


> Hallo, sehe ich auch so, wenn ich mit einem IT Speziallisten über das Thema Maschinensicherheit spreche versteht der erstmal nicht worum es geht, der sieht die Funktion



Ein IT-Spezialist muss von Maschinensicherheit nichts verstehen. Den Kollegen geht es wie uns ... Mit was soll man sich noch alles rumschlagen 
Letzlich brauchen die Kollegen auch nur wenige Informationen:
Wer darf mit wem sprechen und wie sicher muss die Verbindung sein.
Ist die entsprechende Infrastruktur (Hardware, Software und vorallem entsprechende Organisation, Richtlinien und Doku) vorhanden, dann ist es kein großes Problem.
Momentan sind wir nur in einer Phase, in der einfach einer oder mehrere dieser Punkte fehlen.

Gruß
Blockmove


----------



## det (3 Januar 2017)

Moin,
 und frohes neues Jahr noch Euch allen.
Ich würde mal folgendes in den Ring werfen.
Warum  wird bei Schutztüren ein manipulations(sicherer) Schalter eingesetzt?  Früher war es der Rollentaster, dann kamen die mit spezieller  Schaltzunge, heute mit codiertem spezial Schaltstück. Bei Bedarf auch  mit Zuhaltung.
Warum schalten die Schutztürschalter nicht banale Relais sondern einen geprüften Sicherheitsbaustein, F-SPS?
Warum werden in großen Anlagen teilweise Laserscanner für Anwesenheitsmeldung ein gesetzt?
Welchen Aufwand treiben wir bei Roboteranlagen für die Sicherheit?
Das Not Aus Modul wird 2 kanalig mit Querschlusserkennung angeklemmt, für jeden Taster manchmal sogar ein eigenes Modul.
Das sind nur ein paar Möglichkeiten um Maschinen SICHERER zu machen. Heute wird vieles davon in einer F-SPS realisiert.

Und, was macht die Maschinen heute so sicher? Die _Manipulationssicherheit_ und Zuverlässigkeit der Sensoren und Aktoren !!

Und diese Sicherheit wollen wir aufgeben, weil jetzt JEDER _manipulieren_  kann der irgendwie Zugang zur Maschine hat? Ich meine nicht den  Programmierer vor Ort, der mit Kabel an der CPU hängt. Fernwartung ist  super, sollte aber auf die normale SPS beschränkt sein.
Für mich  gehören Sicherheitsbausteine, egal welcher Art nicht ans Netz. Die  müssen manipulationssicher bleiben, und das kann im Netz keiner  sicherstellen.

Grüße Detlef


----------



## holgermaik (3 Januar 2017)

> Für mich  gehören Sicherheitsbausteine, egal welcher Art nicht ans Netz.  Die  müssen manipulationssicher bleiben, und das kann im Netz keiner   sicherstellen.


dann heist es aber die Leittechnik muss alle Infos haben um den Techniker per SMS zu informieren wo ein Not Halt betätigt wurde. Also wird eine Ethernet Anschaltung nachgerüstet.
usw. usw.

Eines Tages kommt man um die Ecke und im CPU Display leuchtet ein schöner F-20 Fehler (nicht autorisierter Zugriff) nur weil ein Dödel die IP verwechselt hat. Gut das die Hersteller mitgedacht haben.

Da bin ich ganz bei Safety, dass wir Regeln brauchen. Ich bin aber dagegen alles auf die Schultern des Programmierers zu laden. 
Eine Vernetzung werden wir nicht aufhalten können.
Holger


----------



## det (3 Januar 2017)

Hallo Holger,

gegen einen Netzanschluss für Meldungen oder Diagnosen spricht nichts. Ich darf über diesen Anschluss aber nicht in die Sicherheit eingreifen können. Nur lesen halt.
Nichts gegen die Programmierer, aber ein Prog ist nur so gut wie der Mensch denkt. Prog's sind immer wieder anders, wie die Programmierer. Also sind auch vielfältige Fehler möglich.
Erprobte Hardware (z.B. Not Aus Modul) ist sicher. Manipulationssichere und eigensichere Harware halt.

Grüße Detlef


----------

