Wie funktioniert CI/CD für SPS-Entwicklung?

CI/CD für SPS-Entwicklung automatisiert den gesamten Prozess von der Code-Änderung bis zum Deployment auf der Steuerung. Über die Siemens Openness-API lassen sich TIA-Portal-Projekte exportieren, kompilieren und mit PLCSim automatisiert testen. Jenkins, GitLab CI oder Azure DevOps orchestrieren den Workflow — analog funktioniert der Ansatz mit Beckhoff TwinCAT 3 Source Control und CODESYS.

Kann man TIA Portal mit Jenkins automatisieren?

Ja. Die Siemens TIA Portal Openness-API ermöglicht die Steuerung von TIA Portal über externe Skripte. Jenkins kann Projekte öffnen, kompilieren, exportieren und mit PLCSim Advanced automatisierte Tests ausführen. Quality Gates prüfen Code-Qualität und Testabdeckung; das Version Control Interface (VCI) ab TIA V16 macht Git-basierte Reviews reproduzierbar.

Wie versioniert man Steuerungscode mit Git?

Steuerungscode kann nach dem Export aus TIA Portal, CODESYS oder TwinCAT als textbasierte Dateien (XML, L5X, ST) in Git versioniert werden. Branching-Strategien ermöglichen parallele Entwicklung, Code-Reviews über Pull Requests erhöhen die Qualität. Spezielle Diff-Tools visualisieren Änderungen in Ladder-Diagrammen und Funktionsbausteinen.

Was ist Release-Management für die Produktion?

Release-Management für OT-Umgebungen berücksichtigt geplante Wartungsfenster, Safety-Anforderungen und Rollback-Strategien. Releases werden in Staging-Umgebungen validiert, bevor sie kontrolliert auf Produktionsanlagen ausgerollt werden. Automatisierte Smoke-Tests verifizieren die Funktionsfähigkeit nach dem Deployment.

Was ist SPS-Testautomatisierung?

SPS-Testautomatisierung nutzt PLCSim oder PLCSim Advanced, um Steuerungsprogramme ohne physische Hardware zu testen. Unit-Tests prüfen einzelne Funktionsbausteine, Integrationstests simulieren komplette Anlagenszenarien. Die Tests laufen automatisch in der CI/CD-Pipeline bei jeder Code-Änderung.

Wie erfüllt eine CI/CD-Pipeline IEC 62443 im Maschinenbau?

Eine IEC-62443-konforme Pipeline integriert Secret-Scanning, Software Bill of Materials (SBOM), signierte Artefakte und dokumentierte Security-Freigaben als verpflichtende Stages. Die Pipeline erzeugt automatisch die Nachweise, die für eine Zertifizierung nach IEC 62443-4-1 (Secure Development Lifecycle) und -4-2 (Komponenten) erforderlich sind — von der CVE-Überwachung bis zum Audit-Log.

Was ändert sich durch den Cyber Resilience Act für Maschinenbauer?

Der EU Cyber Resilience Act (CRA) wird ab dem 11.12.2027 für Produkte mit digitalen Elementen verbindlich — das schließt Maschinen und Anlagen explizit ein. Hersteller müssen unter anderem SBOMs pflegen, Sicherheitslücken binnen 24 Stunden melden und fünf Jahre Updates bereitstellen. Moderne CI/CD-Pipelines generieren diese Artefakte automatisiert; manuelle Prozesse werden in der Breite nicht skalieren.

Welche Pipeline-Nachweise brauche ich für IEC 61508 Safety?

Für den Nachweis nach IEC 61508 (SIL 1–4) müssen Pipelines die lückenlose Traceability von Anforderung → Design → Code → Test bereitstellen. Konkret: versionierte Lastenhefte, Code-Coverage-Reports, Review-Protokolle, Testergebnisse aus Unit-, Integrations- und HiL-Tests sowie ein unveränderliches Audit-Log. Jenkins-Pipelines archivieren diese Artefakte automatisch pro Release.

Was bringt die native Git-Integration in TIA Portal V21?

TIA Portal V21 SP1 integriert Git nativ in die Engineering-Oberfläche. Das ersetzt die bisherige Brücke aus Openness-API + VCI durch einen Standard-Git-Workflow: Branches, Pull Requests und textbasierte Diffs für SCL/AWL-Bausteine direkt in TIA. Wer jetzt umstellt, spart die Übergangslösung — und kann CI-Pipelines schlanker gestalten, weil weniger Powershell-Glue nötig ist. Comquent unterstützt die Migration bestehender Openness-/VCI-Projekte.

Wie funktioniert GitOps für SPS-Steuerungen?

GitOps für SPS funktioniert hybrid: Edge-Workloads (OPC UA Gateways, Datenpumpen, Container auf Industrie-PCs) werden vollständig per Argo CD oder Flux aus Git ausgerollt. Der eigentliche SPS-Programmstand wird per Pipeline gebaut und versioniert, das Aufspielen erfolgt aber in geplanten Wartungsfenstern mit Approval-Gate, PLCSim-Smoke-Test und Rollback-Brücke. So bleibt die Anlagenverfügbarkeit gesichert und der Audit-Trail nach IEC 62443-4-1 vollständig.

Maschinenbau & SPS/PLC — DevOps für die Steuerungstechnik

CI/CD für TIA Portal, CODESYS und TwinCAT: Git-Versionierung, automatisierte PLCSim-Tests, Jenkins-Pipelines und IT/OT-Kulturwandel — für den Maschinenbau im deutschsprachigen Raum.

Erstgespräch buchen Whitepaper herunterladen

SEIT 2006 · 47+ PROJEKTE · MASCHINENBAU · AUTOMOTIVE · INDUSTRIE

Aktualisiert · 2026-05-01//Autor · Andreas Schönfeld, Comquent GmbH//Lesezeit · 12 min//Standort · Puchheim bei München

// Q3 2026 — News

TIA Portal V21 SP1 bringt native Git-Integration. Wer jetzt umstellt, beschleunigt SPS-CI/CD um Monate.

Migration prüfen

// 01Definition

Was ist CI/CD für
SPS und Maschinenbau?

CI/CD für SPS/PLC automatisiert Build, Test und Deployment von Steuerungscode aus TIA Portal, CODESYS oder TwinCAT über Git und Jenkins. Kernbausteine sind das Version Control Interface (VCI), die Siemens Openness-API und PLCSim Advanced für Hardware-freie Tests.

Comquent etabliert diese Pipelines herstellerübergreifend, ergänzt sie um IEC-62443-Security-Gates und begleitet den IT/OT-Kulturwandel — aus Puchheim bei München, deutschlandweit und in ganz DACH.

178 Tsd.

Fachkräfte-Lücke im deutschen Maschinenbau in 10 Jahren.

Quelle · VDMA/DIHK 2025

133 Tsd.

Prognostizierter Skills-Gap in Digitalisierungsberufen bis 2028.

Quelle · IW Köln 2024

−80 %

Deployment-Zeit in Comquent-Referenzprojekten (Median).

Basis · 6 Projekte 2022–2025

2027

Cyber Resilience Act wird für Maschinen verbindlich.

Quelle · EU 2024/2847

// 02Herausforderungen

Welche Probleme bremsen die
SPS-Entwicklung?

Diese Probleme begegnen uns bei unseren Kunden immer wieder — und wir wissen, wie man sie löst.

/01
Keine Versionskontrolle für SPS-Code
Keine Versionskontrolle für.
SPS-Programme werden auf USB-Sticks oder Netzlaufwerken gespeichert. Es gibt keine Nachvollziehbarkeit, wer wann was geändert hat. Verschiedene Versionen auf verschiedenen Maschinen führen zu Chaos im Feld.
/02
Manuelle Deployments auf Maschinen
Manuelle Deployments auf.
Jedes Update auf einer Maschine wird manuell eingespielt — vor Ort, per Laptop, ohne standardisierten Prozess. Das ist fehleranfällig, zeitaufwendig und nicht skalierbar bei wachsender Anlagenzahl.
/03
Keine automatisierten Tests
Keine automatisierten Tests.
SPS-Code wird erst an der realen Anlage getestet — oft unter Zeitdruck bei der Inbetriebnahme. Simulationsumgebungen wie PLCSim werden kaum genutzt, automatisierte Tests existieren nicht.
/04
IT/OT-Kluft
IT/OT-Kluft.
IT-Teams und SPS-Programmierer arbeiten in getrennten Welten mit unterschiedlichen Tools, Prozessen und Denkweisen. Die fehlende Zusammenarbeit verlangsamt Projekte und führt zu Reibungsverlusten.

// 03Unser Ansatz

Wie führt man CI/CD für TIA Portal
ein?

Ein strukturierter, praxiserprobter Ansatz — von der Analyse bis zum messbaren Ergebnis.

Schritt / 01

Git für TIA Portal einführen

Strukturierte Einführung von Git als Versionskontrollsystem für TIA-Portal-Projekte. Branch-Strategien, Merge-Workflows und Code-Reviews — angepasst an die Bedürfnisse von SPS-Programmierern.

Schritt / 02

Jenkins-Pipelines für SPS

Aufbau automatisierter Build- und Deployment-Pipelines mit Jenkins. Vom Commit bis zum fertigen SPS-Programm: kompilieren, Syntax-Check, Quality Gates und automatisierte Dokumentation.

Schritt / 03

Simulation und Test-Automatisierung

Integration von PLCSim Advanced in die CI-Pipeline. Automatisierte Funktionstests, Regressionstests und Integrationstests — bevor der Code auf die reale Anlage kommt. Frühes Feedback, weniger Fehler bei der Inbetriebnahme.

Schritt / 04

Kulturelles Coaching IT/OT

Workshops und Team-Building für IT- und OT-Teams. Gemeinsame Sprache, gemeinsame Ziele, gemeinsame Verantwortung. Wir begleiten den Kulturwandel mit praxisnahen Formaten und messbaren Fortschritten.

// 04Ergebnisse

Welche Ergebnisse bringt DevOps im
Maschinenbau?

Messgröße

Vorher

Nachher

Ergebnis

/01

Deployment-Zeit

Stunden

-80%

→

/02

Fehlerrate

Hoch

-60%

→

/03

Versionskonflikte

Regelmäßig

Eliminiert

→

/04

Inbetriebnahme-Dauer

Tage

Stunden

→

/05

Code-Nachvollziehbarkeit

Nicht gegeben

100%

→

/06

Team-Zusammenarbeit

Isoliert

Integriert

→

// 05Technologien

Welche Tools nutzt Industrial DevOps für
SPS?

Die Tools und Technologien, die wir in diesem Kontext einsetzen — herstellerunabhängig und passend zur bestehenden Infrastruktur.

/01

TIA Portal

/02

Siemens Openness API

/03

TIA Portal VCI

/04

Beckhoff TwinCAT 3

/05

CODESYS

/06

Rockwell Studio 5000

/07

Jenkins

/08

GitLab CI

/09

Azure DevOps

/10

Git

/11

PLCSim Advanced

/12

TIA Test Suite

/13

SonarQube

/14

Docker

/15

Ansible

/16

OPC UA

// 06 — Nächster Schritt

DevOps für Ihre SPS-Entwicklung einführen?

Lassen Sie uns sprechen. In einem kostenlosen Erstgespräch klären wir, wie wir Ihre spezifischen Herausforderungen lösen können.

Erstgespräch buchen→→ Reifegrad-Check starten

// 07Plattform-Matrix

Herstellerübergreifend.
Siemens, Beckhoff, CODESYS, Rockwell.

CI/CD ist kein Siemens-exklusives Konzept. Wir implementieren Pipelines für alle gängigen Steuerungsplattformen — mit deren jeweiligen Eigenheiten.

Plattform

Versionskontrolle

CI-Integration

Test-Stack

/01

Siemens TIA Portal

VCI (ab V16) + Openness API

Jenkins / Azure DevOps

PLCSim Advanced, TIA Test Suite

/02

Beckhoff TwinCAT 3

Source Control ab Build 4026

Jenkins via MSBuild

TcUnit, Virtual Machine

/03

CODESYS

Git-Add-on + Textexport

Python-Scripting + Jenkins

CODESYS Test Manager

/04

Rockwell Studio 5000

L5X-Text-Export + Git

Jenkins via PowerShell

Emulate 3D, FactoryTalk Test

C# als SPS-Programmierumgebung: S7.NET, TwinCAT.NET und Git-Workflows

C# ist klassisch keine SPS-Sprache nach IEC 61131-3 — wird aber zunehmend relevant für die Brücke zwischen Steuerungstechnik und IT-Welt. Drei Pfade dominieren in der Praxis: Siemens S7.NET als Kommunikations-Library zwischen .NET-Anwendung und S7-Steuerung (Datenaustausch, kein Echtzeit-Code auf der SPS), Beckhoff TwinCAT.NET für die Programmierung der TwinCAT-Runtime mit C# unter Visual Studio, und Rockwell Logix Designer + Component Object Model für die Integration von .NET-Komponenten in Studio-5000-Projekten.

Aus CI/CD-Sicht ist C# der pragmatischere Weg: klassische Git-Workflows, MSBuild-Pipelines, NUnit-Tests, Standard-DevOps-Toolchain. Anders als KOP/AWL-Code lassen sich C#-Module direkt in Jenkins, GitLab CI oder Azure DevOps kompilieren, testen und signieren — ohne TIA-Portal-Lizenz auf dem Build-Agent.

Wann C# nicht ausreicht: alles mit harten Echtzeit-Anforderungen (Lagerregler, Motion-Control) bleibt IEC 61131-3 in TIA Portal, CODESYS oder TwinCAT. Wann C# überzeugt: HMI-Logik, OPC-UA-Gateways, MES-Anbindungen, Edge-Datenvorverarbeitung und herstellerunabhängige Tooling-Layer. Vollständiger Leitfaden: SPS mit C# programmieren →

// 08Pipeline in Aktion

So sieht ein Jenkinsfile für TIA Portal aus.

Jenkinsfile — TIA Portal CI

# TIA Portal CI via Openness-API + PLCSim Advanced
pipeline {
  agent { label 'tia-portal' }
  environment {
    TIA_PROJECT = 'Anlage01.ap18'
    PLCSIM_INST = 'PLCSIM-001'
  }
  stages {
    stage('Checkout') {
      steps { git url: 'https://git.example.com/plc.git' }
    }
    stage('Open & Compile') {
      steps { powershell './scripts/Compile-TiaProject.ps1 -Path $env:TIA_PROJECT' }
    }
    stage('PLCSim Smoke Tests') {
      steps { powershell './scripts/Run-PLCSim-Tests.ps1 -Suite smoke' }
    }
    stage('IEC 62443 Gates') {
      steps { sh 'syft packages . -o cyclonedx-json > sbom.json' }
    }
    stage('Export Artifacts') {
      steps { powershell './scripts/Export-Blocks.ps1 -Out artifacts/' }
    }
  }
  post {
    always { archiveArtifacts 'artifacts/**/*.xml, sbom.json' }
  }
}

“

Vorher haben wir Versionskonflikte im Feld entdeckt. Heute fallen sie im Jenkins durch — nicht an der Maschine.

— Leiter SPS-Entwicklung
Sondermaschinenbauer (Bayern), 2024

// 09GitOps für SPS

GitOps für SPS-Steuerungen —
was geht, was nicht.

GitOps für SPS bedeutet: Der gewünschte Anlagenstand (kompiliertes Programm, Hardware-Konfiguration, Rezepte, Parameter) liegt versioniert in Git, ein Reconciler synchronisiert ihn auf die Steuerung. Bei Drift wird der Soll-Zustand wiederhergestellt — nicht überschrieben, sondern gemergt.

Im Maschinenbau ist das Konzept hybrid: Code-Artefakte und Konfigurationen folgen GitOps, der eigentliche Flash-Vorgang bleibt geplant und revisionssicher. Argo CD oder Flux orchestrieren die Edge-Schicht (Linux-IPC, Kubernetes-Edge), die SPS bekommt Updates über validierte Wartungsfenster.

/01
Was funktioniert: deklarative Edge-Schicht
Konfigurationen, Container, Edge-Workloads (Node-RED, OPC UA Gateways, Datenpumpen) lassen sich vollständig per Git → Argo CD/Flux ausrollen. Drift wird automatisch erkannt und korrigiert.
/02
Was eingeschränkt geht: SPS-Programmstand
Der Programmstand (TIA, CODESYS, TwinCAT) wird per CI gebaut und in Git versioniert. Das Aufspielen erfolgt geplant in Wartungsfenstern — mit Pipeline-Trigger statt automatischem Reconcile, um Anlagenausfälle zu vermeiden.
/03
Was nicht geht: ungeprüfter Sync auf Live-Maschinen
Reines Pull-GitOps gegen Produktions-SPS ist riskant. Comquent koppelt deshalb GitOps mit einem Approval-Gate, einem PLCSim-Smoke-Test und einer Rollback-Brücke — Audit-fähig nach IEC 62443-4-1.
/04
Werkzeuge in der Praxis
Git als Source of Truth, Jenkins oder GitLab CI für Build und Test, Argo CD oder Flux für die Edge-Schicht, Helm und Kustomize für Konfigurationsvarianten, signierte OCI-Artefakte für die OT-Strecke.

Workshop — ArgoCD & GitOps mit KI

// 10Normen & Compliance

Audit-ready Pipelines für
IEC 62443 und den CRA.

Security und Funktionale Sicherheit werden nicht am Ende aufgeklebt — sie laufen als Pipeline-Stage mit. Jedes Release liefert seine Nachweise automatisch.

/01
IEC 61131-3
Struktur- und Syntaxprüfung
Automatisierte Prüfung des Bausteine-Exports aus TIA Portal, TwinCAT oder CODESYS auf IEC-61131-3-Konformität in der CI-Stage — vor jedem Merge.
/02
IEC 61508 / IEC 61511
Functional Safety Nachweise
Safety Lifecycle mit CI-getriggerten Testnachweisen: Code-Coverage, Review-Protokolle, Trace-Matrix Anforderung → Test — als Pipeline-Artefakt archiviert.
/03
IEC 62443 (ISA)
OT-Security-Gates
Secret-Scanning, SBOM-Erstellung, CVE-Monitoring und signierte Artefakte direkt in der Pipeline. Audit-ready für Zertifizierung nach IEC 62443-4-1 und -4-2.
/04
Cyber Resilience Act
EU-CRA (ab 11.12.2027)
Verpflichtende SBOM, Vulnerability-Handling und 5-Jahre-Support für Maschinen mit digitalen Komponenten. Comquent-Pipelines erzeugen die Nachweise automatisch.

DevSecOps & IEC 62443 → Blog SBOM erstellen → Anleitung Cyber Resilience Act → Maschinenbau

// 11Für wen genau?

Drei Rollen.
Drei Blickwinkel.

Industrial DevOps ist kein Tool-Rollout, sondern eine Entscheidung, die in der Produktionsleitung, beim SPS-Ingenieur und auf C-Level gleichzeitig fällt.

/01 · Stillstandszeit, Rollback, Wartungsfenster

Produktionsleitung / OT

Weniger Überraschungen in der Inbetriebnahme, reproduzierbare Anlagenstände und kontrollierte Release-Fenster — statt „es hat gestern noch funktioniert".

Mehr erfahren

/02 · Git-Workflow, weniger manuelle Arbeit

SPS- / Automatisierungsingenieur

Branches statt Projekt_v7_final_final. Code-Reviews statt Copy-Paste. PLCSim-Tests statt Debug an der Maschine. Mit moderner Toolchain ohne Schnellschüsse.

Mehr erfahren

/03 · Skalierung, Compliance, TCO

CTO / Head of Engineering

Eine Pipeline für die gesamte Anlagenflotte. Nachweisbare IEC-62443- und CRA-Konformität. Messbare DORA-Metriken statt Bauchgefühl.

Mehr erfahren

// 12Häufige Fragen

Was Maschinenbauer
wirklich fragen.

Q.01
Wie funktioniert CI/CD für SPS-Entwicklung?: CI/CD für SPS-Entwicklung automatisiert den gesamten Prozess von der Code-Änderung bis zum Deployment auf der Steuerung. Über die Siemens Openness-API lassen sich TIA-Portal-Projekte exportieren, kompilieren und mit PLCSim automatisiert testen. Jenkins, GitLab CI oder Azure DevOps orchestrieren den Workflow — analog funktioniert der Ansatz mit Beckhoff TwinCAT 3 Source Control und CODESYS.
Q.02
Kann man TIA Portal mit Jenkins automatisieren?: Ja. Die Siemens TIA Portal Openness-API ermöglicht die Steuerung von TIA Portal über externe Skripte. Jenkins kann Projekte öffnen, kompilieren, exportieren und mit PLCSim Advanced automatisierte Tests ausführen. Quality Gates prüfen Code-Qualität und Testabdeckung; das Version Control Interface (VCI) ab TIA V16 macht Git-basierte Reviews reproduzierbar.
Q.03
Wie versioniert man Steuerungscode mit Git?: Steuerungscode kann nach dem Export aus TIA Portal, CODESYS oder TwinCAT als textbasierte Dateien (XML, L5X, ST) in Git versioniert werden. Branching-Strategien ermöglichen parallele Entwicklung, Code-Reviews über Pull Requests erhöhen die Qualität. Spezielle Diff-Tools visualisieren Änderungen in Ladder-Diagrammen und Funktionsbausteinen.
Q.04
Was ist Release-Management für die Produktion?: Release-Management für OT-Umgebungen berücksichtigt geplante Wartungsfenster, Safety-Anforderungen und Rollback-Strategien. Releases werden in Staging-Umgebungen validiert, bevor sie kontrolliert auf Produktionsanlagen ausgerollt werden. Automatisierte Smoke-Tests verifizieren die Funktionsfähigkeit nach dem Deployment.
Q.05
Was ist SPS-Testautomatisierung?: SPS-Testautomatisierung nutzt PLCSim oder PLCSim Advanced, um Steuerungsprogramme ohne physische Hardware zu testen. Unit-Tests prüfen einzelne Funktionsbausteine, Integrationstests simulieren komplette Anlagenszenarien. Die Tests laufen automatisch in der CI/CD-Pipeline bei jeder Code-Änderung.
Q.06
Wie erfüllt eine CI/CD-Pipeline IEC 62443 im Maschinenbau?: Eine IEC-62443-konforme Pipeline integriert Secret-Scanning, Software Bill of Materials (SBOM), signierte Artefakte und dokumentierte Security-Freigaben als verpflichtende Stages. Die Pipeline erzeugt automatisch die Nachweise, die für eine Zertifizierung nach IEC 62443-4-1 (Secure Development Lifecycle) und -4-2 (Komponenten) erforderlich sind — von der CVE-Überwachung bis zum Audit-Log.
Q.07
Was ändert sich durch den Cyber Resilience Act für Maschinenbauer?: Der EU Cyber Resilience Act (CRA) wird ab dem 11.12.2027 für Produkte mit digitalen Elementen verbindlich — das schließt Maschinen und Anlagen explizit ein. Hersteller müssen unter anderem SBOMs pflegen, Sicherheitslücken binnen 24 Stunden melden und fünf Jahre Updates bereitstellen. Moderne CI/CD-Pipelines generieren diese Artefakte automatisiert; manuelle Prozesse werden in der Breite nicht skalieren.
Q.08
Welche Pipeline-Nachweise brauche ich für IEC 61508 Safety?: Für den Nachweis nach IEC 61508 (SIL 1–4) müssen Pipelines die lückenlose Traceability von Anforderung → Design → Code → Test bereitstellen. Konkret: versionierte Lastenhefte, Code-Coverage-Reports, Review-Protokolle, Testergebnisse aus Unit-, Integrations- und HiL-Tests sowie ein unveränderliches Audit-Log. Jenkins-Pipelines archivieren diese Artefakte automatisch pro Release.
Q.09
Was bringt die native Git-Integration in TIA Portal V21?: TIA Portal V21 SP1 integriert Git nativ in die Engineering-Oberfläche. Das ersetzt die bisherige Brücke aus Openness-API + VCI durch einen Standard-Git-Workflow: Branches, Pull Requests und textbasierte Diffs für SCL/AWL-Bausteine direkt in TIA. Wer jetzt umstellt, spart die Übergangslösung — und kann CI-Pipelines schlanker gestalten, weil weniger Powershell-Glue nötig ist. Comquent unterstützt die Migration bestehender Openness-/VCI-Projekte.
Q.10
Wie funktioniert GitOps für SPS-Steuerungen?: GitOps für SPS funktioniert hybrid: Edge-Workloads (OPC UA Gateways, Datenpumpen, Container auf Industrie-PCs) werden vollständig per Argo CD oder Flux aus Git ausgerollt. Der eigentliche SPS-Programmstand wird per Pipeline gebaut und versioniert, das Aufspielen erfolgt aber in geplanten Wartungsfenstern mit Approval-Gate, PLCSim-Smoke-Test und Rollback-Brücke. So bleibt die Anlagenverfügbarkeit gesichert und der Audit-Trail nach IEC 62443-4-1 vollständig.