Kapitel 2:

Ein Oktett hat 8 Bits. Jedes Bit ist „an“ (1) oder „aus“ (0). Durch Addieren der gesetzten Bit‑Werte entsteht die Dezimalzahl des Oktetts (0–255).

Die Bit‑Gewichtung im Oktett ist (von links nach rechts): 128, 64, 32, 16, 8, 4, 2, 1 (jeweils „an“ oder 0 „aus“). So kann jede Zahl von 0 bis 255 dargestellt werden, indem du die aktiven Bit‑Werte addierst.

Beispiel aus Abbildung 2‑1:
Das erste Oktett ist 5, weil nur 4 und 1 aktiv sind (0+0+0+0+0+4+0+1).
Das zweite Oktett ist 39, weil 32, 4, 2 und 1 aktiv sind (0+0+32+0+0+4+2+1).
Als Übung kannst du prüfen, ob du mit derselben Logik das dritte und vierte Oktett aus Abbildung 2‑1 berechnen kannst.

Was NAT konkret tut

NAT ordnet privaten IP‑Adressen für ausgehenden Internet‑Verkehr öffentliche IP‑Adressen zu. In der Praxis übernimmt das meist der Router.

Private IP‑Bereiche im Überblick (für die Praxis) 

• Bereich 1:10.0.0.0 – 10.255.255.255 → sehr große Netze (über 16 Mio. Hosts möglich).
• Bereich 2:172.16.0.0 – 172.31.255.255 → mittlere bis große Netze (ca. 1 Mio. Hosts möglich).
• Bereich 3:192.168.0.0 – 192.168.255.255 → kleine bis mittlere Netze (ca. 65.000 Hosts möglich).

Der weltweite Vorrat an eindeutigen IPv4‑Adressen war 2016 ausgeschöpft.
Viele Unternehmen stellen deshalb zunehmend auf IPv6 um.
IPv6 nutzt eine 128‑Bit‑Hexadezimaladresse und bietet 3,4 × 10^38 eindeutige Adressen – also über 340 Undezillionen.

Was „Cloud“ ursprünglich meinte – und wie NIST sie definiert

Ursprünglich stand „Cloud“ für das Netzwerk‑„Drumherum“, das LAN‑Internet‑Verbindungen ermöglicht (im Diagramm oft als Wolke dargestellt). Nach NIST umfasst Cloud Computing fünf Merkmale: On‑Demand‑Self‑Service, breiter Netzzugang, Ressourcen‑Pooling, schnelle Elastizität und gemessener Service.

Cloud‑Servicemodelle (Web‑kompatibel erklärt)

• IaaS (Infrastructure as a Service): Bereitstellung von Rechen‑, Speicher‑ und Netzwerkressourcen; Betriebssysteme und Anwendungen werden vom Kunden genutzt, die Cloud‑Infrastruktur selbst bleibt außerhalb seiner Kontrolle (z. B. AWS).
• PaaS (Platform as a Service): Bereitstellung einer Plattform zur Ausführung/Deployments unterstützter Anwendungen; Infrastrukturverwaltung bleibt beim Anbieter (z. B. IBM Bluemix).
• SaaS (Software as a Service): Zugriff auf Anwendungen, die in der Cloud laufen; keine Kontrolle über die Infrastruktur (z. B. Gmail).
• CaaS (Connectivity as a Service): Inter‑Netzwerk‑Konnektivität als Dienst – skalierbar und wirtschaftlich insbesondere für KMU, ohne komplexe Multi‑Vendor‑Beziehungen (z. B. Ewon Talk2M).

Zum Verständnis hilft dieses Bild: Das Internet ist die Route, die Cloud (und das Web) sind die Ziele, die über diese Route erreichbar sind.

Protokollvielfalt ist Realität – Interoperabilität ist die Aufgabe

In industriellen Umgebungen gibt es viele Protokolle, weil die Anwendungen stark spezialisiert sind.
Viele dieser Protokolle sind jedoch proprietär und nicht standardisiert, was die Interoperabilität in vernetzten Industrieumgebungen erschwert.

Ethernet hilft – und TCP/IP transportiert transparent

Gut für die Praxis: Die meisten Automatisierungsgeräte verfügen inzwischen über Ethernet‑Ports. Dadurch lassen sich SPS‑/Automatisierungsprotokolle (wie in Tabelle 2‑1) dank TCP/IP häufig transparent über Router übertragen.

Wenn Geräte „alt“ sind: Seriell statt Ethernet

Ältere Automatisierungsgeräte ohne Ethernet‑Port besitzen meist serielle Schnittstellen – typischerweise RS232 oder RS485.
Für den Fernzugriff auf solche Geräte sollte der LAN/WAN‑Router idealerweise zusätzlich als Protokoll‑Gateway fungieren und Ethernet‑Protokolle in serielle Pendants übersetzen.
Daraus folgt: Ein Automatisierungsrouter sollte Gateway‑Funktionalität integriert anbieten und die in Tabelle 2‑1 genannten Protokolle unterstützen.

Unterstützte SPS‑Protokolle

• Allen Bradley – Rockwell Automation: DF1 (seriell) / Ethernet Industrial Protocol, EIP (Ethernet)
• Siemens, VIPA: MPI/Profibus (seriell) / ISOTCP (Ethernet)
• Schneider: Modbus/Unitelway (seriell) / Modbus (Ethernet)
• Omron: Fins Hostlink (seriell) / Fins TCP/UDP (Ethernet)
• Mitsubishi: Programming‑Protokoll (seriell) / MC‑Protokoll (Ethernet)
• Hitachi: H‑Protokoll (seriell) / H‑Protokoll (Ethernet)

Warum SPS überhaupt erfunden wurden

SPS sind heute branchenübergreifend etabliert, doch die ersten SPS‑Systeme wurden für US‑Automobilhersteller entwickelt.
Vor der Einführung von SPS wurden Fertigungsprozesse durch viele fest verdrahtete Relais und Zeitschaltuhren gesteuert.
Diese Technik funktionierte, aber bei jeder Prozessänderung mussten oft Tausende Komponenten neu verdrahtet werden – ein kosten- und zeitintensiver Aufwand.

Historischer Auslöser (1968)

1968 suchte die Automatikgetriebe‑Abteilung von General Motors nach einer besseren Möglichkeit, Änderungen in Produktionsprozessen umzusetzen.
Bedford Associates aus Massachusetts erhielt den Auftrag und entwickelte die erste SPS, die als Modular Digital Controller (Modicon) bekannt wurde.
Dick Morley, einer der Entwickler, wird von „Manufacturing Automation“ als „Vater“ der SPS bezeichnet.

Programmierung damals und heute

Merke: Frühe SPS nutzten Kontaktplan‑Logik (Ladder Logic), angelehnt an die Schaltpläne der zuvor verwendeten analogen Steuertechnik. 
Moderne SPS lassen sich auf unterschiedliche Weise programmieren – ihr Zweck bleibt jedoch die zuverlässige, programmierbare Steuerung von Fertigungsprozessen.