SPS mit C#
programmieren.
Wann, wie, wo nicht.
S7.NET, Beckhoff TwinCAT.NET und Rockwell mit .NET — die pragmatische Brücke zwischen Steuerungstechnik und IT-Welt. Inklusive Git- und CI/CD-Workflow.

Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
20 Jahre CI/CD- und Industrial-DevOps-Beratung — Schwerpunkt SPS/PLC-Versionierung, IT/OT-Brücke und Embedded-Toolchains.
SPS-Steuerungslogik schreiben Sie nach IEC 61131-3 — nicht in C#. C# und SPS treffen sich eine Ebene darüber, über drei Pfade: S7.NET für Siemens-Kommunikation, Beckhoff TwinCAT.NET für .NET-Komponenten an der TwinCAT-Runtime, und Rockwell .NET-Integration über Component Object Model. Für HMI, OPC-UA-Gateway, MES-Anbindung und Test-Automation ist das der pragmatischere Weg — Git, CI/CD und Unit-Tests bleiben Standard-IT-Toolchain. Harte Echtzeit bleibt auf der Steuerung.
Ist SPS mit C# bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Wie programmiert man
eine SPS mit C#?
Eine SPS mit C# programmieren heißt 2026 vor allem: einen von drei Vendor-Pfaden nutzen. Keiner ersetzt die Steuerungs-IDE — aber Siemens S7.NET, Beckhoff TwinCAT.NET und Rockwell .NET erlauben C# als Ergänzung für HMI, OPC UA, MES-Anbindung und Test-Automation. Fast jedes Automatisierungsteam landet früher oder später bei dieser Frage — meist dann, wenn das erste MES-Projekt ansteht und die Steuerungstruppe auf die IT trifft.
Siemens
S7.NETPlus / Sharp7
Windows-/Linux-Host, Edge-Device
Datenaustausch S7-1200/1500, LOGO!, S7-300/400 — kein Code auf der SPS
- HMI-Anwendungen
- OPC-UA-Gateway
- MES-Anbindung
- Edge-Daten-Pufferung
Beckhoff
TwinCAT.NET (Beckhoff.TwinCAT.Ads)
TwinCAT-3-Runtime in Visual Studio
.NET-Komponenten in der TwinCAT-Runtime — echte SPS-nahe C#-Logik (nicht-zeitkritisch)
- Daten-Mapping
- OPC-UA-Server
- Logging & Visualisierung
- Fertigungsdaten an Cloud
Rockwell
Studio 5000 Component Object Model / libplctag.NET
Windows-Host neben ControlLogix/CompactLogix
Datenaustausch mit Logix-Steuerungen, .NET-Komponenten in Studio-5000-Add-Ons
- HMI-Plant-Floor
- AS-i / OPC-UA-Bridge
- MES-Integration
- Reporting
Welcher C#-Weg passt zu Ihrer Steuerung?
Für C# an der SPS gibt es je Hersteller einen anderen Weg — von S7.NET bis TwinCAT.NET. Wählen Sie Ihre Steuerung, und Sie bekommen die passende Bibliothek plus den nächsten Schritt.
Welche Steuerung setzen Sie ein?
Welche Programmiersprache
für die SPS?
Die Norm IEC 61131-3 definiert fünf SPS-Programmiersprachen: Kontaktplan (KOP), Funktionsplan (FUP), Anweisungsliste (AWL), Strukturierter Text (ST) und Ablaufsprache (AS). C# steht nicht in dieser Liste — es setzt eine Ebene darüber an, auf dem PC oder Edge-Device neben der Steuerung.
| Sprache | Typ | Typischer Einsatz |
|---|---|---|
| Kontaktplan (KOP / LD) | grafisch | Verriegelungen und Schützlogik. Vertraut für Elektriker, dominiert in der Instandhaltung. |
| Funktionsplan (FUP / FBD) | grafisch | Verknüpfungslogik aus UND-/ODER-Bausteinen, verbreitet in der Verfahrenstechnik. |
| Ablaufsprache (AS / SFC) | grafisch | Schrittketten für sequenzielle Abläufe — Rüsten, Takten, Rezeptsteuerung. |
| Strukturierter Text (ST / SCL) | textbasiert | Berechnungen, Schleifen, Datenstrukturen. Textbasiert und damit diff-bar — erste Wahl für neue Projekte. |
| Anweisungsliste (AWL / IL) | textbasiert | Maschinennahe Befehlsliste aus der Step-7-Zeit. In neuen Projekten kaum noch im Einsatz. |
| C# / .NET | außerhalb der Norm | HMI, OPC-UA-Gateway, MES-Anbindung, Test-Automation — als Anwendungs- und Kommunikationsschicht neben der Steuerung, nicht auf ihr. |
IEC 61131-3 · Zielframework für neue OT-Projekte: .NET 10 LTS — Support für .NET 8 endet am 10. November 2026
Ist C# echtzeitfähig?
Nicht im Sinne harter Echtzeit. .NET läuft unter Windows oder Linux mit Garbage Collection und ohne garantierte Zykluszeit — Jitter im Millisekundenbereich ist normal. Für weiche Echtzeit reicht das aus: Visualisierung, Datenerfassung, MES-Kopplung im 100-Millisekunden-Bereich. Für Motion-Control, Lageregler und Sicherheitsfunktionen bleibt die Logik auf der Steuerung.
Beckhoff bindet .NET über ADS an die TwinCAT-Runtime an — die zyklische, deterministische Task bleibt dabei die SPS-Task. Diese Trennung ist kein Kompromiss, sondern die Architektur: unten Determinismus, darüber die Anwendungslogik, die sich in Git versionieren und im CI testen lässt. Wie Versionsverwaltung für SPS-Code auf der Steuerungsseite funktioniert, zeigt der Vergleich von octoplant, Copia und TIA Portal.
Vier Gründe für
C# in der OT.
Wo C# der pragmatischere Pfad ist — und warum.
Standard-Toolchain
MSBuild, NuGet, dotnet CLI, Roslyn, NUnit, xUnit — alle bekannten DevOps-Tools laufen direkt. Keine TIA-Portal-Lizenz auf dem Build-Agent.
Diff-bar in Git
Anders als KOP/AWL ist C#-Code reiner Text. Pull-Request-Reviews, Branch-Strategien und Merge-Konflikte funktionieren wie in klassischen IT-Projekten. Wer schon einmal zwei Binär-Projektstände nebeneinandergelegt hat, um eine verschwundene Änderung zu suchen, weiß, was das wert ist.
Test-Automation
Steuerungs-Adapter abstrahieren — und Tests laufen ohne reale SPS. Coverage ≥ 70 % auf der Daten-Mapping-Logik ist in jedem Projekt erreichbar.
IT-Talente gewinnen
Junior-Entwickler aus der Hochschule können sofort produktiv sein — sie kennen C# und Visual Studio, aber selten Structured Text oder KOP.
Drei Grenzen.
Ehrlich genannt.
C# ist kein Universal-Hammer. Diese drei Use-Cases bleiben IEC 61131-3.
Harte Echtzeit-Regler
Lageregler, Motion-Control unter 1 ms, Sicherheits-SPS nach IEC 61508/SIL2+ — bleibt in IEC 61131-3 (Structured Text in TIA Portal, CODESYS, TwinCAT PLC).
Steuerungen ohne .NET-Runtime
S7-1200 ohne TwinCAT, klassische CompactLogix ohne Add-On — hier läuft C# nur als externer Kommunikations-Layer auf einem PC/Edge-Device, nicht auf der Steuerung.
Zertifizierungs-Pflicht
SIL-zertifizierte Codebasen brauchen geprüfte Compiler und Toolchains. C# und .NET sind dort meist nicht zugelassen — die Hersteller-IDEs der SPS liefern die zertifizierten Build-Strecken mit.
Read/Write gegen
eine S7-1500.
Minimales C#-Beispiel: Verbindung zur S7-1500, einen DB-Wert lesen, einen Merker setzen. NuGet-Paket S7.NetPlus installieren und in einer Konsolen-Anwendung referenzieren. Dieser Ansatz ist die typische Einstiegsstufe in Industrial DevOps für den Maschinenbau.
Der Code unten läuft auf einem beliebigen Windows-/Linux-Host mit Netzwerkzugriff auf die Steuerung — die SPS selbst bleibt unverändert (kein Code-Deployment auf die SPS).
// dotnet add package S7.NetPlus using S7.Net; var plc = new Plc(CpuType.S71500, "192.168.0.10", 0, 1); await plc.OpenAsync(); // DB1.DBD0 als REAL lesen var temperature = (float)await plc.ReadAsync("DB1.DBD0"); Console.WriteLine($"Temperatur: {temperature:F2} °C"); // Merker M10.0 setzen await plc.WriteAsync("M10.0", true); plc.Close();
S7.NetPlus · NuGet · Open Source (MIT) · S7-1200/1500, S7-300/400, LOGO!
Vom ersten Modul
zur Pipeline.
Empirisch in 4 Wochen umsetzbar — Standard-Toolchain, kein Spezial-Setup nötig. Wie Comquent CI/CD für SPS & TIA Portal im Maschinenbau in realen Projekten aufbaut, zeigt der dazugehörige Anwendungsfall.
Woche 1
Modul-Wahl & Library-Setup
Use-Case festlegen: HMI-Logik, OPC-UA-Gateway oder MES-Anbindung. NuGet-Pakete einbinden — S7.NETPlus für Siemens, Beckhoff.TwinCAT.Ads für TwinCAT, libplctag.NET für Multi-Vendor. Solution-Struktur mit Library-/Test-/Application-Project. .gitignore vorbereiten.
Woche 2
Unit-Tests & Mocking
NUnit oder xUnit konfigurieren. Steuerungs-Adapter über Interface abstrahieren, damit Tests ohne reale SPS laufen. Coverage-Ziel: ≥ 70 % auf der reinen C#-Logik (Daten-Mapping, Protokoll-Adapter). Mocks für DB-Reads, Schreib-Operationen mit Test-Doubles.
Woche 3
Build-Pipeline + statische Analyse
Jenkinsfile oder GitLab-CI mit MSBuild-Stage. Roslyn-Analyzer für Code-Quality, SonarQube für Coverage-Reporting. Signed-Build-Artefakt (Authenticode) für OT-Deployments. SBOM-Generierung mit CycloneDX für IEC-62443-Compliance.
Woche 4
Integration-Tests gegen virtuelle SPS
PLCSim Advanced (Siemens) oder TwinCAT-Runtime im Container starten. Integration-Tests im CI gegen die virtuelle Steuerung — Read/Write-Zyklen, Datentyp-Konsistenz, Edge-Cases. Promotion auf Real-Hardware nur nach Pass. Der erste Lauf, der einen Datentyp-Fehler an der virtuellen Steuerung abfängt, bevor jemand zur Anlage fährt, ist meist der Moment, in dem das Team den Wert der vier Wochen sieht.
.NET-Code in der OT —
was IEC 62443 verlangt.
Sobald C#-Code mit einer Steuerung kommuniziert, wird er zum Bestandteil der OT-Sicherheitszone. IEC 62443 stuft solchen Code als SL-relevant ein — Build, Lieferkette und Deployment müssen nachvollziehbar sein. Spätestens wenn der Auditor wissen will, welche NuGet-Pakete in welcher Version auf dem Gateway laufen, entscheidet die Pipeline, ob die Antwort ein SBOM-Export ist — oder eine Woche Archäologie.
Die fünf Pflicht-Stages, die in jeder CI/CD-Pipeline für .NET-OT-Code laufen sollten, sind unten aufgeführt. Wie CI/CD für SPS-Projekte konkret aufgebaut wird, zeigt der Praxisartikel zu TIA Portal & Jenkins. Mit dem Cyber Resilience Act kommen ab Dezember 2027 zusätzliche SBOM- und Meldepflichten dazu.
- /01
Authenticode-Signatur
Build-Artefakte mit gültigem Code-Signing-Zertifikat signieren. Manipulationsschutz und Lieferanten-Nachweis in einem.
- /02
SBOM (CycloneDX)
Alle NuGet-Dependencies in einer CycloneDX-Software-Bill-of-Materials erfassen. Pflicht ab CRA Dezember 2027.
- /03
Statische Analyse
Roslyn-Analyzer mit Security-Regeln aktivieren (z. B. SecurityCodeScan). SonarQube für zentrale Pflege der Regeln.
- /04
Dependency-Scan
Trivy oder OWASP Dependency-Check gegen alle NuGet-Pakete. CVE-Treffer ab CVSS 7 blocken den Build.
- /05
Verschlüsselte Kommunikation
Wo das Protokoll es zulässt: OPC UA mit X.509-Zertifikaten statt klassische S7-Telegramme über Plain-TCP.
FAQ — C# in der
SPS-Welt.
- /01
- Kann man eine SPS mit C# programmieren?
- Klassischer SPS-Steuerungscode wird nach IEC 61131-3 in KOP, FUP, AWL, ST oder SFC geschrieben — nicht in C#. Mit C# realisieren Sie in der OT typischerweise drei Pfade: (1) Siemens S7.NET / Sharp7 als Kommunikations-Library zwischen .NET-Anwendung und S7-Steuerung (Datenaustausch, kein Echtzeit-Code auf der SPS), (2) Beckhoff TwinCAT.NET zur Anbindung der TwinCAT-Runtime aus .NET unter Visual Studio, (3) Rockwell Studio 5000 mit .NET-Komponenten und Component Object Model. Echte Steuerungslogik mit harten Echtzeit-Anforderungen bleibt in der jeweiligen IEC-61131-3-Umgebung.
- /02
- Welche Programmiersprache für SPS?
- Die Norm IEC 61131-3 definiert fünf SPS-Programmiersprachen: Kontaktplan (KOP/LD), Funktionsplan (FUP/FBD), Anweisungsliste (AWL/IL), Strukturierter Text (ST/SCL) und Ablaufsprache (AS/SFC). C# steht nicht in dieser Liste — es setzt eine Ebene darüber an, auf dem PC oder Edge-Device neben der Steuerung. Wer heute neu anfängt, schreibt die Steuerungslogik meist in Strukturiertem Text, weil er textbasiert und damit in Git diff-bar ist; KOP bleibt in der Instandhaltung verbreitet, AWL wird in neuen Projekten kaum noch eingesetzt.
- /03
- Ist C# echtzeitfähig?
- Nicht im Sinne harter Echtzeit: .NET läuft unter Windows oder Linux mit Garbage Collection und ohne garantierte Zykluszeit, Jitter im Millisekundenbereich ist normal. Für weiche Echtzeit — Visualisierung, Datenerfassung, MES-Kopplung im 100-Millisekunden-Bereich — reicht C# aus. Für harte Echtzeit wie Motion-Control, Lageregler oder Sicherheitsfunktionen bleibt die Logik auf der Steuerung in IEC 61131-3. Beckhoff bindet .NET über ADS an die TwinCAT-Runtime an, die zyklische deterministische Task bleibt dabei die SPS-Task.
- /04
- Was ist S7.NET und wofür wird es eingesetzt?
- S7.NET (auch S7.NETPlus oder Sharp7) ist eine offene C#-Library zur Kommunikation mit Siemens-S7-Steuerungen (S7-300/400, S7-1200/1500, LOGO!) über das S7-Protokoll. Typische Use-Cases sind HMI- und Visualisierungs-Anwendungen, OPC-UA-Gateways, MES-Anbindungen, Datenarchivierung und Edge-Datenvorverarbeitung. S7.NET läuft nicht auf der SPS, sondern auf Windows-/Linux-Hosts oder Edge-Devices und ist Read/Write-fähig gegen DBs, Merker und Peripherie.
- /05
- Was ist Beckhoff TwinCAT.NET?
- TwinCAT.NET (offiziell TwinCAT.NET-Komponenten und Beckhoff.TwinCAT.Ads.NET) ist die offizielle Beckhoff-Library, mit der .NET-Anwendungen über ADS (Automation Device Specification) auf TwinCAT-Runtime und SPS-Variablen zugreifen. In Visual Studio lassen sich C#-Module schreiben, die mit der TwinCAT-3-Runtime zusammenarbeiten — eine vertraute Programmiererfahrung für IT-Entwickler in der Automatisierungswelt. Bei harten Echtzeit-Anforderungen bleibt die Logik in TwinCAT-PLC (Structured Text), .NET-Komponenten ergänzen sie für nicht-zeitkritische Aufgaben.
- /06
- Wann lohnt sich C# statt KOP/AWL/ST in der SPS-Programmierung?
- C# überzeugt für HMI-Logik, OPC-UA-Gateways, MES-Anbindungen, Datenarchivierung, Edge-Datenvorverarbeitung, herstellerunabhängige Tooling-Layer und Test-Automatisierung gegen virtuelle SPS. C# reicht nicht aus für: harte Echtzeit-Regler (Motion-Control, Lageregler unter 1 ms), Safety-relevante Logik nach IEC 61508/SIL2+ (dort bleibt zertifizierter IEC-61131-3-Code Pflicht), und tief integrierte Steuerungslogik auf Steuerungen ohne .NET-Runtime (S7-1200 ohne TwinCAT).
- /07
- Wie versioniere ich C#-SPS-Code mit Git?
- C#-Code für SPS-Anbindung wird wie normaler .NET-Code in Git versioniert: .gitignore mit Standard-VS-Einträgen (bin/, obj/, .vs/), Solution- und Projektdateien getrackt, NuGet-Pakete über PackageReference verwaltet. Trennung in Library (Steuerungs-Adapter), Application (HMI/Gateway) und Tests. Bei TwinCAT.NET-Projekten zusätzlich TcCOM-Komponenten und Generated-Code im .gitignore-Pattern ausnehmen. Pull-Request-Workflows funktionieren analog zu klassischen IT-Projekten — viel einfacher als KOP/AWL-Versionierung, weil diff-bar in Text.
- /08
- Wie baut man eine CI/CD-Pipeline für C# in der OT?
- Standard-Pipeline in vier Stages: (1) Restore: NuGet-Pakete cachen, (2) Build: MSBuild oder dotnet build, (3) Test: NUnit/xUnit + Coverage, (4) Package & Sign: Artefakt signieren (Authenticode), bei TwinCAT.NET zusätzlich TcCOM-Assembly bauen. Build-Agents müssen Windows mit installierten Visual Studio Build Tools haben. Als Zielframework gehört in neue OT-Projekte .NET 10 LTS — der Support für .NET 8 endet am 10. November 2026. Bei Integration-Tests gegen virtuelle SPS (PLCSim Advanced, TwinCAT-Runtime im Container) ist ein separater Test-Agent mit OT-Lizenz nötig.
- /09
- Welche Sicherheitsanforderungen gelten für .NET-Code in der OT?
- IEC 62443 stuft Code, der mit Steuerungen kommuniziert, als SL-relevant ein. Konkrete Pflichten: (1) Signierte Build-Artefakte (Authenticode), (2) SBOM für alle NuGet-Dependencies (CycloneDX-Format), (3) statische Code-Analyse mit Security-Regeln (Roslyn Analyzers, SonarQube Security Hotspots), (4) Dependency-Scanning auf bekannte CVEs (z. B. Trivy, OWASP Dependency-Check), (5) verschlüsselte Kommunikation zur SPS, wo das Protokoll es zulässt (OPC UA mit X.509-Zertifikaten statt klassische S7-Telegramme).
- /10
- Welche Tools und Libraries für C#-SPS-Entwicklung 2026?
- Siemens-Welt: S7.NETPlus (Open Source), Sharp7 (leichtgewichtig), Siemens Openness (für TIA-Portal-Automatisierung). Beckhoff: Beckhoff.TwinCAT.Ads (offiziell), TwinCAT.NET-Komponenten. Rockwell: Studio 5000 Logix Designer mit Component Object Model, libplctag.NET (Open Source, Multi-Vendor). Hersteller-übergreifend: OPC UA via OPC Foundation .NET Standard Stack. Test/Build: NUnit, xUnit, Roslyn Analyzers, SonarQube, Trivy, GitHub Actions oder Jenkins mit Windows-Agents.
C# in der OT.
Pipeline in
4 Wochen.
Wir bauen Ihre erste CI/CD-Pipeline für .NET-Code in der Steuerungstechnik — mit S7.NET, TwinCAT.NET oder Multi-Vendor über libplctag. Standard-Toolchain, signierte Artefakte, virtuelle SPS-Tests. Der Einstieg ist unverbindlich: Ein kostenloses 30-Minuten-Erstgespräch reicht, um den passenden Pfad für Ihre Steuerungslandschaft einzugrenzen.
Wie geht es bei Ihnen mit C# in der OT weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Verwandte Artikel
SPS-Versionsverwaltung: Git für Industrial IT
octoplant, Copia und TIA Portal V21 — Versionskontrolle für SPS-Code in der Praxis.
CI/CD für SPS mit TIA Portal & Jenkins
Build, PLCSim-Tests, Quality Gates: Inbetriebnahmezeit um 40–60 % reduzieren.
Software Defined Automation einführen
DevOps für die SPS-Welt — Pilot in 8 Wochen, 40 % kürzere Lead Time.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance

