Ansible hat in den letzten Jahren tats\u00e4chlich an Bedeutung in Umgebungen gewonnen, in denen IT- und OT-Infrastrukturen zusammenwachsen. Es ist jedoch eines von mehreren Werkzeugen<\/strong> \u2013 und nicht das einzige. Andere Technologien wie Terraform<\/strong>, Puppet<\/strong>, Chef<\/strong> oder SaltStack<\/strong> werden in \u00e4hnlichen Kontexten eingesetzt, sind aber in der OT oft weniger verbreitet, da sie agentenbasiert oder zu IT-zentriert sind.<\/p>\n\n\n\n Der gr\u00f6\u00dfte Vorteil von Ansible in der OT ist seine Agentenlosigkeit<\/strong> \u2013 es nutzt SSH (Linux) oder WinRM (Windows) \u2013 sowie die deklarative Beschreibung<\/strong> von Zust\u00e4nden in YAML<\/strong>. Das reduziert den Footprint auf den Zielger\u00e4ten und vereinfacht die Integration in bestehende Sicherheitsrichtlinien.<\/p>\n\n\n\n Die Entwicklung der Automatisierungstechnik l\u00e4sst sich grob in folgende Phasen unterteilen:<\/p>\n\n\n\n Die Behauptung, Ansible habe die Grenzen zwischen IT und OT so sehr verschoben wie kein anderes Werkzeug<\/em>, ist aus fachlicher Sicht nicht haltbar<\/strong>. Hier spielen OPC UA, MQTT, Ethernet\/IP, Profinet und Container-Technologien<\/strong> mindestens ebenso gro\u00dfe Rollen.<\/p>\n\n\n\n Ansible findet vor allem in folgenden Bereichen praktische Anwendung:<\/p>\n\n\n\n Netzwerkkomponenten wie Switches, Router und Firewalls lassen sich mit Ansible standardisiert konfigurieren. Unternehmen wie IP Infusion<\/strong> bieten spezifische Collections f\u00fcr Zero-Touch-Provisioning (ZTP)<\/strong> an. Das bedeutet: Ein neuer Switch wird ans Netz angeschlossen, erh\u00e4lt per DHCP eine Grundkonfiguration und wird dann vollautomatisch in die gew\u00fcnschte Topologie eingebunden.<\/p>\n\n\n\n Ein Beispiel ist die Zusammenarbeit von Schneider Electric<\/strong> und Red Hat<\/strong>: Hier wird Ansible genutzt, um den gesamten Technologie-Stack am industriellen Edge zu orchestrieren \u2013 vom Betriebssystem (RHEL) \u00fcber die Container-Plattform (MicroShift) bis zur Steuerungssoftware EcoStruxure Automation Expert<\/strong>. Der Ansatz folgt GitOps<\/strong>-Prinzipien: Der gew\u00fcnschte Zustand wird in Git hinterlegt, Ansible gleicht die physischen Ger\u00e4te ab.<\/p>\n\n\n\n Am CERN werden hunderte SCADA-Systeme betrieben. Im Rahmen eines Upgrades 2024 wurde ein unbeaufsichtigter Upgrade-Workflow<\/strong> mit Ansible implementiert. Das zeigt, dass Ansible auch in sicherheitskritischen, hochkomplexen Umgebungen einsetzbar ist \u2013 allerdings mit entsprechendem Aufwand f\u00fcr Testing, Rollback-Strategien und Freigabeprozesse.<\/p>\n\n\n\n Trotz aller Vorteile gibt es klare Einschr\u00e4nkungen<\/strong>:<\/p>\n\n\n\n Die community.cip<\/strong>-Collection ist ein gutes Beispiel daf\u00fcr, wie die Community die L\u00fccke zwischen Ansible und der SPS-Welt schlie\u00dft. Sie erm\u00f6glicht die Kommunikation mit Ger\u00e4ten \u00fcber das Common Industrial Protocol (CIP)<\/strong>, das bei Rockwell Automation und anderen Herstellern verbreitet ist.<\/p>\n\n\n\n Das zeigt: Ansible kann f\u00fcr bestimmte OT-Aufgaben nutzbar gemacht werden \u2013 allerdings meist mit Einschr\u00e4nkungen<\/strong> (z.\u202fB. keine Zykluszeiten im Millisekundenbereich, keine Sicherheitszertifikate).<\/p>\n\n\n\n Die Automatisierung mit Ansible bringt neue Sicherheitsanforderungen mit sich:<\/p>\n\n\n\n Grunds\u00e4tzlich gilt: Die Automatisierung selbst ist nur so sicher wie ihre Implementierung.<\/strong> Governance, Code-Reviews und Zugriffskontrollen sind unerl\u00e4sslich.<\/p>\n\n\n\n Der eingangs erw\u00e4hnte Feldversuch (Link im Originaltext) zeigt, dass Automatisierung in der realen OT-Welt oft an unvorhergesehenen Problemen<\/strong> scheitert:<\/p>\n\n\n\n Viele Projekte scheitern nicht an Ansible selbst<\/strong>, sondern an der mangelnden Vorbereitung der zugrundeliegenden Infrastruktur. Das ist ein typisches Problem bei der Einf\u00fchrung von DevOps-Praktiken in der OT.<\/p>\n\n\n\n Die Zukunft wird nicht darin bestehen, dass Ansible zur universellen Steuerungsl\u00f6sung wird. Vielmehr zeichnen sich folgende Trends ab:<\/p>\n\n\n\n Der Elektroingenieur wird zunehmend interdisziplin\u00e4r<\/strong> arbeiten \u2013 aber er bleibt weiterhin f\u00fcr die physikalischen Randbedingungen<\/strong> (Sicherheit, Echtzeit, Verf\u00fcgbarkeit) verantwortlich. Die Rolle des Software-Architekten<\/em> ist eher eine erg\u00e4nzende denn eine ersetzende.<\/p>\n\n\n\n Ansible ist ein n\u00fctzliches, aber nicht universelles Werkzeug<\/strong> f\u00fcr die Automatisierung von OT-Infrastrukturen. Seine St\u00e4rken liegen in der Netzwerkautomatisierung, der Edge-Orchestrierung und der Standardisierung von Konfigurationsprozessen. Seine Grenzen sind:<\/p>\n\n\n\n Die erfolgreiche Nutzung von Ansible in der OT erfordert gut durchdachte Prozesse, Teststrategien und Sicherheitsma\u00dfnahmen<\/strong>. Wer das beachtet, kann von erheblichen Effizienzgewinnen profitieren \u2013 ohne sich jedoch von der Vorstellung einer stillen Revolution<\/em> blenden zu lassen.<\/p>\n\n\n\n Quellen<\/strong><\/p>\n\n\n\n <\/p>","protected":false},"excerpt":{"rendered":" Einordnung: Werkzeug oder Wunderwaffe? Ansible hat in den letzten Jahren tats\u00e4chlich an Bedeutung in Umgebungen gewonnen, in denen IT- und OT-Infrastrukturen zusammenwachsen. Es ist jedoch eines von mehreren Werkzeugen \u2013 und nicht das einzige. Andere Technologien wie Terraform, Puppet, Chef oder SaltStack werden in \u00e4hnlichen Kontexten eingesetzt, sind aber in der OT oft weniger verbreitet, da sie agentenbasiert oder zu IT-zentriert sind. Der […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40,42,18,26],"tags":[10187,658,10188,10190,10189,10191,10192],"class_list":["post-6876","post","type-post","status-publish","format-standard","hentry","category-denkwerkzeuge","category-elektrotechnik","category-im-kopf-methoden-werkzeuge","category-mit-den-handen","tag-ansible","tag-automatisierung","tag-betriebstechnik-ot","tag-infrastructure-as-code","tag-it-ot-konvergenz","tag-netzwerkautomatisierung","tag-sps-programmierung"],"_links":{"self":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/6876","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/comments?post=6876"}],"version-history":[{"count":5,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/6876\/revisions"}],"predecessor-version":[{"id":6881,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/6876\/revisions\/6881"}],"wp:attachment":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/media?parent=6876"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/categories?post=6876"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/tags?post=6876"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n\n\n\nAutomatisierung in der Elektrotechnik \u2013 ein historischer Abriss<\/h2>\n\n\n\n
Phase<\/th> Charakteristik<\/th><\/tr><\/thead> Pneumatik & Relaislogik<\/strong><\/td> Festverdrahtete Steuerungen, \u00c4nderungen nur durch Umbau m\u00f6glich.<\/td><\/tr> SPS (ab ~1968)<\/strong><\/td> Programmierung \u00fcber spezielle Ger\u00e4te oder Laptops mit propriet\u00e4ren Umgebungen (z.\u202fB. TIA Portal, RSLogix, Codesys).<\/td><\/tr> IT-Configmanagement-Tools (ab ~2005)<\/strong><\/td> Puppet\/Chef f\u00fcr Serverfarmen, aber kaum OT-tauglich.<\/td><\/tr> Ansible (ab 2012)<\/strong><\/td> Erste breite Nutzung in Netzwerk- und Edge-Umgebungen; in der klassischen SPS-Welt bis heute nur randst\u00e4ndig<\/strong>.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nAnwendungsszenarien \u2013 wo Ansible heute tats\u00e4chlich in der OT eingesetzt wird<\/h2>\n\n\n\n
1. Netzwerkautomatisierung im Energiesektor<\/h3>\n\n\n\n
2. Edge-Infrastrukturen (IT\/OT-Grenzbereich)<\/h3>\n\n\n\n
3. SCADA-Systeme am CERN<\/h3>\n\n\n\n
\n\n\n\nDie Grenzen von Ansible in der OT<\/h2>\n\n\n\n
Bereich<\/th> Problem<\/th><\/tr><\/thead> Echtzeitanforderungen<\/strong><\/td> Ansible ist nicht f\u00fcr zyklische Echtzeitkommunikation geeignet (z.\u202fB. Motion Control, Regelungstechnik).<\/td><\/tr> Sicherheitszertifizierungen<\/strong><\/td> F\u00fcr Ansible gibt es keine Zertifizierung nach IEC 61508<\/strong> oder ISO 13849<\/strong> \u2013 damit ist es in sicherheitsgerichteten Anwendungen nicht zugelassen.<\/td><\/tr> Propriet\u00e4re SPS-Protokolle<\/strong><\/td> Viele Steuerungen verwenden herstellerspezifische Protokolle (z.\u202fB. Siemens S7-Kommunikation). Ansible kann diese nicht nativ ansprechen.<\/td><\/tr> Firmware-Varianten<\/strong><\/td> Unterschiedliche Ger\u00e4teversionen f\u00fchren oft zu inkompatiblen Playbooks \u2013 Automatisierung scheitert dann nicht an der Technik, sondern an mangelnder Standardisierung der Zielger\u00e4te.<\/td><\/tr> Fehlende State-Persistence<\/strong><\/td> Ansible ist deklarativ, aber nicht zustandsbasiert. Es kann nicht eigenst\u00e4ndig erkennen, ob ein Ger\u00e4t seinen Sollzustand verlassen hat \u2013 das muss \u00fcber zus\u00e4tzliche Monitoring-Tools gel\u00f6st werden.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nPraxisbeispiel: community.cip<\/h2>\n\n\n\n
\n\n\n\nSicherheit \u2013 ein zentrales Thema<\/h2>\n\n\n\n
\n
no_log: true<\/code>\u00a0vergessen wird, k\u00f6nnen sensible Daten im Klartext in Logs erscheinen.<\/li>\n\n\n\n
\n\n\n\nFeldversuche \u2013 die Praxis ist komplexer als die Theorie<\/h2>\n\n\n\n
\n
\n\n\n\nAusblick: Wohin entwickelt sich die Automatisierung?<\/h2>\n\n\n\n
Trend<\/th> Beschreibung<\/th><\/tr><\/thead> Adaptive Playbooks<\/strong><\/td> Erste Experimente mit KI-gest\u00fctzter Fehlererkennung und Selbstheilung (AIOps) \u2013 jedoch noch kein Standard.<\/td><\/tr> Containerisierung am Edge<\/strong><\/td> Ansible orchestriert Container-Workloads, nicht die Echtzeitsteuerung selbst.<\/td><\/tr> Standardisierung<\/strong><\/td> Initiativen wie OPC UA over TSN<\/strong> oder MTP (Module Type Package)<\/strong> k\u00f6nnten die Automatisierbarkeit deutlich erh\u00f6hen \u2013 dann profitiert auch Ansible.<\/td><\/tr> Hybride Automatisierung<\/strong><\/td> Kombination aus Ansible f\u00fcr Orchestrierung und spezialisierten Tools (z.\u202fB. SPS-Programmierumgebungen) f\u00fcr die eigentliche Steuerung.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nFazit<\/h2>\n\n\n\n
\n
\n\n\n\n\n