Ich hab mich mal etwas schlau gemacht diesbezüglich & bin in etwa der meinung von
@Gerhard Bäurle .
Mir wäre noch nie in dem Kontext "Funktionale Sicherheit" ein Bezug auf die Firmenart/-größe untergekommen.
Höchstens im Grad der Standardisierung von Softwarebibliotheken.
Und selbst da heißt "größer" nicht zwingend "besser in Puncto Standardisierung".
Ist mal interessant, hat aber einen recht...theoretischen Ansatz.
Immerhin habe ich neue Vokabeln für das Bullshit-Bingo mit dem Doctore aus der Nachbarabteilung.
"Entwicklung von Sicherheitslebenszyklen für cyber-physische Produktionssysteme"（＾∀＾●）ﾉｼ
Bezieht sich zB darauf.
Hier von B&R:
Wenn ich das richtig verstanden habe, programmieren die einmal den Maximalausbau der Anlage, zertifizieren dieses Programm & schalten dann nurnoch Optionen ein/aus.
Das können eigentlich die meisten Steuerungen.
Bei Sick Flexy bin ich mir grade nicht sicher, Siemens kann es aber auf jeden Fall.
Siehe
"Siemens Safety - Projektieren & Programmieren", Abschnitt 2.5
bzw.
https://support.industry.siemens.co...-1200-bzw-s7-1500-zu-beachten-?dti=0&lc=de-DE
Bei Serien-Maschinen kann man den dafür notwendigen Aufwand durchaus treiben, bei Sondermaschinen schießst man sich damit (meiner bescheidenen Erfahrung nach) mehr selbst ins Bein, weil man nie absolut alles bedenken kann.
Und dann isses nur nei Kleinigkeit & man
muss den Code ändern, prüfen, Abnahme.....
Oder die Programme werden so riesig/komplex, dass die Wartbarkeit die Aufwandseinsparung wieder auffrisst.
Mit Smart Safety meine ich auch das Konzept einer modularen Sicherheitstechnik, welche sich im Baukasten-Konzept, aus der im Baukasten-Konzept konfigurierten Anlage ergibt und sich selbst zertifiziert. (Die Systeme gibt es)
Beispiel aus meinem Bereich: (Sondermaschinenbau)
Ich zerlege meine Maschinen in Funktionen, die immer wieder exakt identisch auftauchen.
Das kann ein Not-Aus-FC mit Status-UDT fürs HMI oder auch eine StateMachine für einen komplexen Prozess sein (z.B. Begasungslogik für einen Härtereiofen mit Aufkohlungsathmosphäre).
Diese werden intern zertifiziert/abgenommen & incl. Funktionsbeschreibung/Flussdiagrammen/Prüfsumme/Inbetriebnahme-Checklisten in der Unternehmensbibliothek abgelegt.
Bei der Projektierung/Inbetriebnahme/Abnahme muss dann lediglich die Funktion mit der dafür definierten IB-Checkliste aus der Doku verifiziert werden, die Funktion an sich ist ja bereits verifiziert.
Sowas spart massiv Aufwand bei der eigentlichen IB.
Konzeptionell sind wir hier aber eher im Bereich "objektorientierte Programmierung".
Ob man das als "Smart Safety" betiteln kann.....
Hätte aber noch nie gesehen, dass irgendein Unternehmen solche Bibliotheken allgemein zur Verfügung stellt (Siemens Safety-Bibliotheken mal ausgenommen).
Entweder ist das so absolut grundlegen, dass es jeder ohne größeren Aufwand hinbekommt oder so komplex, dass es unter Know-how Schutz läuft.
Das wurde bei dem genannten Anbieter in der Logistikbranche dadurch erreicht, dass jede Komponente, welche für eine menschliche Interaktion vorgesehen war (z.B. Klappe/Öffnung) eine eigene Sicherheitssteuerung bekam, welche dann an die übergeordnete kommuniziert hatte
Kann mir nicht vorstellen, dass es einen relevanten Unterschied für den Zertifizierungsaufwand macht ob ich jetzt eine physische Logik mit standardisierter Schnittstelle/Funktion in einem Verbund mit anderen (ähnlichen) physischen Logiken betreibe oder ein Rudel von FCs/FBs mit standardisierter Schnittstelle/Funktion innerhalb einer physischen Logik.
tldr:
"Smart Safety" klingt nach Vertriebs-Vokabular.
