Was ist S7.NET und wofür wird es eingesetzt?
S7.NET (auch S7.NetPlus oder Sharp7) ist eine offene C#-Library, mit der .NET-Anwendungen über das S7-Protokoll mit Siemens-Steuerungen (S7-300/400, S7-1200/1500, LOGO!) kommunizieren. Der Code läuft nicht auf der SPS, sondern auf einem Windows-/Linux-Host oder Edge-Device und liest bzw. schreibt Datenbausteine, Merker und Peripherie — typisch für HMI-Anwendungen, OPC-UA-Gateways, MES-Anbindungen und Edge-Datenvorverarbeitung.
SPS mit C# programmieren — S7.NET, TwinCAT.NET, CI/CDS7.NET ist eine offene .NET-Bibliothek, die das von Siemens verwendete S7-Kommunikationsprotokoll in C# implementiert. Sie spricht über TCP/IP mit den Steuerungsfamilien S7-300, S7-400, S7-1200, S7-1500 und LOGO! und liest oder schreibt dort Datenbausteine, Merker, Eingänge und Ausgänge. Verbreitet sind drei eng verwandte Varianten: das ursprüngliche S7netplus (NuGet-Paket S7.NetPlus) und das besonders leichtgewichtige Sharp7, das ohne externe Abhängigkeiten auskommt. Allen gemeinsam ist, dass sie nicht auf der SPS laufen, sondern auf einem PC, Server oder Edge-Device daneben.
Diese Abgrenzung ist der wichtigste Punkt: S7.NET ersetzt keine Steuerungslogik nach IEC 61131-3. Die eigentliche Echtzeit-Regelung bleibt im TIA Portal in KOP, FUP oder Strukturiertem Text; S7.NET ist die Datenbrücke daneben, die Werte aus der Steuerung in die IT-Welt holt und gezielt zurückschreibt. Genau deshalb ist die Library der typische Einstieg, wenn HMI-Anwendungen, OPC-UA-Gateways, MES-Anbindungen oder Edge-Datenvorverarbeitung gebaut werden sollen, ohne in das validierte SPS-Programm einzugreifen.
Aus DevOps-Sicht ist S7.NET attraktiv, weil der Code reiner C#- und damit reiner Text ist: Er lässt sich in Git versionieren, in Pull-Requests reviewen und in einer CI/CD-Pipeline mit MSBuild, NUnit und statischer Analyse bauen und testen — ohne TIA-Portal-Lizenz auf dem Build-Agent. Steuerungs-Adapter lassen sich hinter einem Interface abstrahieren, sodass Unit-Tests ohne reale SPS laufen und Integrationstests gegen eine virtuelle Steuerung wie PLCSim Advanced erfolgen. Sobald der Code mit einer Steuerung kommuniziert, gehört er nach IEC 62443 jedoch in die OT-Sicherheitsbetrachtung — mit signierten Artefakten und Dependency-Scanning der NuGet-Pakete.
Temperaturwert aus einer S7-1500 lesen
Eine C#-Konsolen- oder Service-Anwendung öffnet mit S7.NetPlus eine Verbindung zur S7-1500, liest zyklisch einen REAL-Wert aus einem Datenbaustein und stellt ihn normalisiert per MQTT bereit — ohne das laufende Steuerungsprogramm zu verändern.
OPC-UA-Gateway als Edge-Workload
Auf einem Linux-Edge-Device bündelt eine S7.NET-Anwendung Werte mehrerer S7-Steuerungen, reichert sie an und veröffentlicht sie über einen OPC-UA-Server — versioniert in Git und über eine CI/CD-Pipeline mit signiertem Artefakt ausgerollt.
- Läuft S7.NET-Code auf der SPS?
- Nein. S7.NET läuft auf einem Windows- oder Linux-Host bzw. Edge-Device neben der Steuerung und kommuniziert über das S7-Protokoll mit ihr. Die SPS selbst bleibt unverändert und behält ihr nach IEC 61131-3 programmiertes Steuerungsprogramm — S7.NET liest und schreibt nur Daten, ersetzt aber keine Steuerungslogik.
- Worin unterscheiden sich S7netplus, S7.NetPlus und Sharp7?
- Es ist im Kern dieselbe Idee in verwandten Ausprägungen: S7netplus ist die ursprüngliche Open-Source-Library, S7.NetPlus das gängige NuGet-Paket dazu, und Sharp7 eine besonders schlanke Single-File-Variante ohne externe Abhängigkeiten. Für neue Projekte wählt man meist S7.NetPlus über NuGet; Sharp7 eignet sich, wenn maximale Schlankheit oder einfache Einbindung gefragt sind.
- Ist S7.NET für sicherheitskritische Steuerung geeignet?
- Nein. Für harte Echtzeit-Regelung und Safety-Funktionen nach IEC 61508/61511 bleibt zertifizierter IEC-61131-3-Code in der jeweiligen Steuerungs-IDE Pflicht. S7.NET ist für Datenaustausch, Visualisierung und Anbindung gedacht. Sobald es mit einer Steuerung kommuniziert, ist es dennoch nach IEC 62443 abzusichern — etwa mit verschlüsselter Kommunikation über OPC UA statt klassischer S7-Telegramme.
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