Optimierte vs. Standard-Datenbausteine in S7-1500: Was jeder Migrator wissen muss

Wenn Sie ein STEP-7-Classic-Projekt nach TIA Portal migrieren, kommen alle Datenbausteine als "Standard" (nicht optimiert) an — für Kompatibilität. TIA Portals Standard für neue Projekte ist "optimiert." Das sind nicht nur verschiedene Einstellungen — sie repräsentieren einen fundamentalen Wandel in der Datenspeicherung und -zugriff der S7-1500.

Der Kernunterschied#

Standard-Datenbausteine (Legacy-Modus)#

Jede Variable hat eine feste Byte-Adresse. Zugriff per Name ("DB1".Temperatur) oder per Absolutadresse (DB1.DBW0). Speicherlayout ist sequentiell.

// Standard-DB-Layout:
// Offset 0:   Temperatur   (REAL, 4 Bytes)  → DBD0
// Offset 4:   Druck        (REAL, 4 Bytes)  → DBD4
// Offset 8:   Status       (BOOL, 1 Bit)    → DBX8.0
// Offset 10:  Zaehler      (INT, 2 Bytes)   → DBW10

Das Problem: Fügen Sie eine neue REAL-Variable zwischen Temperatur und Druck ein, verschiebt sich alles darunter um 4 Bytes. Druck wandert von DBD4 nach DBD8. Jede Referenz auf DBD4 im gesamten Programm — und in jeder HMI-, SCADA- und OPC-Verbindung — ist jetzt falsch.

Optimierte Datenbausteine (Moderner Modus)#

Variablen haben keine feste Byte-Adresse. Zugriff ausschließlich per symbolischem Namen. Der CPU-Compiler ordnet sie intern für optimale Zugriffsgeschwindigkeit und Speichereffizienz an.

Der Vorteil: Variable einfügen, entfernen, umordnen — nichts anderes ändert sich. Keine Adressverschiebungen. Keine kaputten Referenzen. Keine HMI-Updates.

Detaillierter Vergleich#

Was bei der Migration passiert#

Bei der Migration eines STEP-7-Classic-Projekts nach TIA Portal:

1. Alle DBs werden auf "Standard" gesetzt — TIA Portal bewahrt die Absolutadressen damit der migrierte Code ohne Änderungen kompiliert
2. Alle FBs und FCs nicht-optimiert — selber Grund
3. Programm funktioniert identisch — korrekter Anfangszustand

NICHT sofort alle DBs auf optimiert umstellen. Das würde jede Absolutreferenz im Programm und jede externe Verbindung zerstören.

Der richtige Migrationspfad#

Phase 1: Migrieren und verifizieren — Alles Standard lassen. Identisches Verhalten verifizieren.

Phase 2: Block für Block konvertieren — Einen FB/FC/DB wählen. Auf optimiert umstellen. Alle Absolutreferenzen durch symbolische ersetzen. Testen. Wiederholen.

Phase 3: Externe Verbindungen aktualisieren — PUT/GET auf OPC UA oder TSEND/TRCV umstellen. HMI-Verbindungen auf symbolische Adressierung.

Wann Standard-DBs beibehalten#

1. PUT/GET-Kommunikation. PUT/GET überträgt Daten per Absolutadresse. Optimierte DBs haben keine.

Workaround: Dedizierter "Kommunikations-DB" im Standard-Modus für PUT/GET. Alle anderen DBs optimiert.

2. OPC DA (klassisch). OPC-DA-Clients greifen per Absolutadresse zu.

Workaround: Auf OPC UA umsteigen (symbolische Namen). S7-1500 hat integrierten OPC-UA-Server.

3. Fremdsysteme mit festem Byte-Offset-Zugriff. Ältere HMI/SCADA/MES.

Workaround: Standard-"Schnittstellen-DB" für das externe System. Daten im SPS-Programm von optimierten DBs in den Schnittstellen-DB kopieren.

Wann immer optimierte DBs verwenden#

• Alle Neuentwicklungen auf S7-1200/1500
• Instanz-DBs für FBs (optimierte Multi-Instanz deutlich schneller)
• Große Datencontainer (>768 KB erfordert optimierten DB)
• Jeder DB bei dem Variablen häufig hinzugefügt/entfernt werden
• Jeder DB der über OPC UA zugänglich ist

Praxisbeispiel: Der Remanenz-Unterschied#

Standard-DB: Remanenz gilt für den gesamten Block. Entweder alle Variablen überleben den Spannungsausfall, oder keine.

Optimierter DB: Jede Variable einzeln als remanent oder nicht-remanent definierbar:

DATA_BLOCK "DB_Maschine"
  VAR
    zyklusZaehler    : DINT := 0;     // Nicht-remanent: Reset bei Spannungswiederkehr
    gesamtTeile      : DINT := 0;     // Remanent: überlebt Spannungsausfall
    aktuellesRezept  : INT := 1;      // Remanent: gewähltes Rezept behalten
    motorLaeuft      : BOOL := FALSE; // Nicht-remanent: sicherer Neustart
  END_VAR

Ein erheblicher Sicherheits- und Funktionalitätsvorteil. In Standard-DBs bräuchten Sie separate "Remanent"- und "Nicht-remanent"-DBs.

Performance-Auswirkung#

Der Siemens Programming Guideline bestätigt: Optimierte Blöcke haben auf S7-1500 keinen Performance-Nachteil. Sie sind typischerweise sogar schneller weil:

• Der Compiler die Speicherausrichtung für die CPU-Architektur optimiert
• S7-1200/1500 intern Little-Endian verwenden — optimierte Blöcke vermeiden den Big-Endian-Konvertierungsaufwand
• BOOL-Variablen als volle Bytes gespeichert werden → schnellerer Einzelbefehl-Zugriff

Was PLCcheck Pro beiträgt#

PLCcheck Pro analysiert Ihr STEP-7-Classic-Programm und identifiziert:

• Jede absolute DB-Referenz die vor dem Optimieren auf symbolisch umgestellt werden muss
• DB-Variablen die per PUT/GET zugegriffen werden (müssen Standard bleiben oder umstrukturiert werden)
• DB-Variablen die von HMI/SCADA zugegriffen werden (externes Schnittstellen-Inventar)
• Empfohlene Block-für-Block-Optimierungsreihenfolge

DB-Zugriffsmuster analysieren →

Häufig gestellte Fragen#

Kann ich Standard- und optimierte DBs in einem Projekt mischen?

Ja. Empfohlener Ansatz während der Migration. Kommunikations-DBs bleiben Standard, alles andere wird optimiert.

Löscht die Umstellung auf optimiert meine Daten?

Keine Daten gehen verloren. Aber alle Absolutreferenzen (DBW0, DBD4) werden ungültig. TIA Portal zeigt Kompilierfehler für jede ungültige Referenz — was tatsächlich hilfreich ist, weil es genau zeigt was geändert werden muss.

Warum werden BOOLs in optimierten DBs als Bytes gespeichert?

Die S7-1500-CPU greift auf ein volles Byte mit einem einzigen Befehl zu, braucht aber Zusatzbefehle für einzelne Bits innerhalb eines Bytes. Mehr Speicherverbrauch aber schnellerer Zugriff. S7-1500 hat reichlich Speicher — der richtige Kompromiss.

Gepflegt von PLCcheck.ai. Letztes Update: März 2026. Keine Verbindung zu Siemens AG.