STEP 7 SDB Upload: Backing Up System Data Blocks Safely

System Data Blocks (SDBs) are the configuration backbone of every SIMATIC S7 project engineered with STEP 7 V5.x (SIMATIC Manager). Unlike the user-writable DBs that hold process data, SDBs are generated automatically by the configuration editors—HW Config for the hardware layout, NetPro for the communication connections, and the global data editor for cross-CPU data exchange. The SDBs are compiled, downloaded to the CPU's load memory, and re-uploaded whenever the engineer needs to mirror the as-built state of a target station back into the offline project on the programming device (PG).

When you upload from a PLC to the PG, the SDBs come along with every other block. The questions that frequently arise in field service are whether this upload will rewrite the offline HW Config in the project, and whether a project can be safely archived simply by uploading the station. This article answers both questions, explains the warning about missing software packages such as the Moby ASM 475/476, and provides a step-by-step backup procedure that protects the configuration from silent corruption.

What SDBs Contain in STEP 7 V5.x

An SDB is a numbered container (SDB 0 through SDB 2047 in practice) holding structured configuration data compiled by the three configuration editors in SIMATIC Manager:

The user blocks—OBs, FBs, FCs, DBs—do not live in SDBs. Neither do comments, symbols, sources, or STL/SCL/FBD source files. The SDBs therefore capture everything that is not user code plus everything that is not documentation, which is exactly what a system integrator needs for a faithful backup of a running machine. As stated in the source material, "SDB stores HW config, connections (from NET PRO) and global data. In other words, all configurations that were not placed in OB, FB, FC and DB."

When the CPU boots, it reads the SDBs from the load memory (MMC card for S7-300/CPU 31x, integrated FlashC for S7-400 CPUs without MMC) and uses them to parameterize the central rack, the distributed I/O, and the communication stack. Replacing the SDBs is the standard way to change the hardware layout of a running system without re-writing user code.

SDB Memory Layout and Lifecycle

The SDBs live in load memory. On a S7-300, load memory is the Micro Memory Card (MMC); on a S7-400, it is either the integrated FlashC or an external FlashCard, depending on the CPU generation. Work memory holds only the runtime instance of the SDBs needed for the current operating state, plus the user blocks.

When you delete SDBs from the offline project but leave them on the CPU, the CPU continues to run with the original configuration. A subsequent download of the modified (SDB-less) project clears the SDBs on the CPU and the system reverts to default parameterization—this is the most common cause of "the network stopped working after a small change" field reports. The cardinal rule: never delete SDBs from the offline project without an explicit reason.

SDB Upload Procedure

The standard upload path in SIMATIC Manager pulls every block—including the SDBs—from the target CPU. The procedure is identical for MPI, PROFIBUS, or Industrial Ethernet (ISO-on-TCP) as long as the PG can reach the PLC's online interface.

Prerequisites

1. STEP 7 V5.5 SPx (SP2/SP3/SP4) or later installed on the PG.
2. An online connection from PG to PLC—USB/MPI adapter, CP 5512/CP 5621 PROFIBUS card, or standard Ethernet NIC with the right ISO-on-TCP route.
3. The PLC's MPI/DP/PN address known, or a "Accessible Nodes" browse available.
4. Read/write permission in STEP 7 (Settings → Set PG/PC Interface).
5. For S7-400H redundant systems, both CPUs accessible to ensure a coherent SDB upload.
6. Sufficient free disk space on the PG for the resulting project archive.

Step-by-Step Upload

1. Open SIMATIC Manager and connect to the target station. Use PLC → Accessible Nodes if the project is unknown, or navigate to the existing offline project.
2. Select the S7 station (S7-300 or S7-400) in the project tree.
3. Choose PLC → Upload Station to PG (German: PG-Upload von Station). The system prompts for the target project name and folder.
4. SIMATIC Manager compiles the upload: it reads all blocks (OB, FB, FC, DB, SDB, SFB, SFC) plus the system data, then recreates a 1:1 mirror of the CPU's program and configuration in the new project.
5. After the upload completes, double-click Hardware to open HW Config. The rack should be populated identically to the source. If a "Software package not installed" message appears, refer to the Moby ASM 475/476 section below.
6. Open NetPro and verify that the connection list matches the live system. Cross-check OPC, S7, and ISO-on-TCP connections against any external documentation.
7. Archive the project immediately: File → Archive or use the STEP 7 project archiver. A ZIP-based archive (.zap) is the standard interchange format.

Verification

• Compare the uploaded project's block count with the CPU's online view: PLC → Compare Blocks (ONLINE/OFFLINE) should report "Identical" for every block.
• Open Accessible Nodes → [CPU] → Module Information → Diagnostic Buffer and confirm no "Parameter assignment error" entries appeared after the SDB roundtrip.
• Cross-check the rack in HW Config against the physical rack. Slot numbers, module order, and PROFINET device names must match.
• Verify the CPU's firmware version in Module Information → Identification against any project documentation.

Effect on Offline HW Config

The answer to the engineer's first question is yes, but with a precise scope: the upload replaces the offline HW Config in the destination project with the configuration that was compiled and downloaded to the target CPU. The previous offline configuration in the project is overwritten; SIMATIC Manager does not merge or reconcile differences. If the offline HW Config was a working A, and the live CPU runs a working B, the result after upload is B. A is gone.

There are two notable edge cases that catch even experienced engineers:

1. CPU operating with default SDBs only. If the CPU was never parameterized—uncommon in production but possible in bench setups or after a full memory reset—the upload yields a minimal SDB 0/1 with no DP, no PROFINET, and no S7 connections. The offline HW Config from the original project is therefore replaced with an essentially empty one. The diagnostic buffer on the CPU will show only startup entries without "Module parametrization" records—this is the reliable indicator.
2. CPU with manually edited SDBs on a MMC. For S7-300 CPUs with an external MMC, it is possible (though not recommended) to swap a project on the card outside of STEP 7. The upload reflects the MMC's SDBs, not the original STEP 7 project. In this case, the upload effectively becomes a "read what's in the card" operation, and the project will not match the original engineering database.
3. SDB regeneration on download. If the offline HW Config is re-compiled with a different STEP 7 service pack or a different S7-CPU support package, the SDB numbers and content may shift. The CPU will accept the new SDBs but module parameter defaults may change. Always pin the PG's STEP 7 service pack version when restoring a long-running system.

Moby ASM 475/476 Software Package Warning

The message "The project contains objects of the software 'Moby ASM 475/476' which cannot be edited because the software package is not installed" originates in HW Config. The Moby ASM 475 and ASM 476 are communication modules from the SIMATIC RF (RFID/Moby) family that interface an S7-300/ET 200S station to RFID readers. They are delivered with a dedicated software package that adds module type definitions, parameter dialogs, and GSD-equivalent information to HW Config.

When you upload a station that contains an ASM 475 or ASM 476, the SDBs come back intact, but the offline project lacks the software package that HW Config needs to render the module. The consequences are:

For a backup-only workflow—upload, archive, do not modify—the missing software package is a nuisance, not a blocker. The SDBs are preserved exactly as found in the CPU, which is the goal of a safety backup. This is the answer to the engineer's second concern: yes, you have a faithful backup of all hardware configuration and program blocks when you upload the SDBs, even with the Moby ASM 475/476 package absent.

Other modules that exhibit the same behavior and should be treated the same way include:

• CP 343-1/CP 443-1 with optional CPs and the associated NCM S7 Industrial Ethernet diagnostics package.
• S7-300 FM (Frequency Measurement) modules and FM 350/351 counter modules.
• S7-400H-specific redundancy objects (H-CPU pairing, Y-Link).
• S7-Distributed Safety F-library hardware objects.
• SIMOTION Scout objects if the project crosses the PLC/motion boundary.

The pattern is identical: the SDB is uploaded intact, but the offline editing capability is gated by the installation state of the corresponding software option. Treat the project as read-only until the package is installed.

Safe Roundtrip Upload/Download Practices

A roundtrip—upload from CPU, then download the uploaded project back to the same CPU without modification—is a recognized housekeeping step and is safe under the following conditions:

1. No software packages are missing on the PG. If HW Config flags a missing package, the SDB regeneration on the download side may strip the affected SDBs. The "roundtrip" then becomes a destructive operation, not a housekeeping one.
2. The CPU is in STOP or RUN with the correct operating mode. For S7-300, a download in RUN is supported only for individual blocks, not for full station re-download. For S7-400, full download in RUN is supported but triggers a re-initialization of the affected modules; some SDBs require STOP to take effect.
3. The SDBs have not been corrupted in the load memory. A diagnostic buffer entry of the form "Parameter assignment error" or "Station failure" should be cleared before the roundtrip.
4. For S7-400H, both CPUs have identical SDB content. Use PLC → Compare FBs/FCs/DBs/SDBs across the H-pair before the roundtrip.
5. PG and CPU firmware are compatible. The SDBs reference module parameters validated against the firmware version. A mismatched PG support package can produce SDBs that the CPU rejects.

The recommended roundtrip procedure:

1. Archive the live CPU's project (upload only—no offline edits).
2. Re-download the archived project to the same CPU from a known-good PG.
3. Verify online/offline identity: PLC → Compare ONLINE/OFFLINE must report "Identical" for all block types including SDBs.
4. Watch the diagnostic buffer for "Module parametrization" entries for 60 s after the download.
5. Run a controlled process start and confirm the system is healthy before handing the line back to production.

PROFIBUS and PROFINET SDB Specifics

The SDBs for PROFIBUS DP and PROFINET IO contain a denser structure than the central-rack SDBs, because the distributed I/O configuration carries slave/device addresses, GSD-derived module lists, and watchdog timers. A typical S7-316 with one PROFIBUS DP slave line and one PROFINET IO line generates SDBs in the 100-400 range:

When the upload comes back with a corrupt PROFIBUS SDB, the most common cause is a partial download interrupted by a power loss on the CPU side. The CPU retains the SDBs in load memory but the work-memory copy may be inconsistent. A full STOP → MRES → re-download of the offline SDB set is the standard recovery.

S7-400H Redundancy Considerations

For S7-400H redundant systems, the SDBs exist twice—once on each H-CPU. The redundancy SDBs (typically SDB 70-79) describe the H-pair linkage, the synchronization link, the master/standby role, and the Y-Link or other redundant I/O configuration. When you upload from an H-station, the upload reads the SDBs from the CPU you are connected to (the master by default). The redundancy SDBs on the standby CPU are not uploaded in the same operation.

When comparing an H-system's uploaded SDBs against the live H-system, use PLC → Compare Blocks on each CPU separately, then diff the two comparison results. Identical SDB sets across both H-CPUs are the steady-state condition; any divergence is a fail-over artifact and should be investigated.

Firmware and Version Compatibility

SDBs reference module parameters validated against the CPU's firmware version. A few important version-dependent behaviors:

When restoring a long-running system, always pin the PG's STEP 7 service pack version, the S7-CPU support package version, and the version of any optional packages (Moby, F-library, etc.). A "clean install" of STEP 7 on a fresh PG often produces subtly different SDBs and may surprise the engineer on the first download.

Comparing SDBs Across Projects

STEP 7 V5.x does not expose a user-friendly SDB diff tool. The most common ways to detect a configuration drift between the offline project and the live CPU are:

• Compare Blocks (ONLINE/OFFLINE): PLC → Compare Blocks. This compares every block class including SDBs. SDBs that differ are listed in the "Different" column with timestamps and checksums. The tool provides a one-click reconciliation: either upload to bring the offline project up to date, or download to push the offline project to the CPU.
• SDB container export (TIA Portal path): If a migration to TIA Portal is planned, the SDBs can be exported from the STEP 7 project and imported into a TIA Portal V21 (or later) project as a System Data Container. The portal then offers a structured comparison. See the TIA Portal V21 comparing PLC programs documentation for the general comparison workflow and the data types involved.
• SDB printout/dump: HW Config → Station → Print produces a textual representation of the configuration that can be diffed externally. This is the lowest-tech but most thorough method for audit purposes, especially when the engineer needs to prove configuration identity across multiple sister machines.
• SDB raw export (advanced): PLC → Save Service Data on the online CPU dumps the SDBs to a folder in raw binary form. The dumps can be compared with a binary diff tool if checksum-level equality is required.

When comparing SDBs across two offline projects—for example, to verify a backup integrity or to validate a sister machine's configuration—open both projects in SIMATIC Manager and use Options → Compare Projects (Offline/Offline). The tool reports block-level differences and can produce a delta list exportable to CSV. Note that the comparison is structural, not semantic: an SDB that is logically identical but stored in a different internal format (e.g., after a STEP 7 service pack change) will still show as "Different".

Diagnostic Buffer Interpretation for SDB Issues

When an SDB problem manifests on the CPU, the diagnostic buffer is the first place to look. Common entries and their meanings:

The diagnostic buffer is cleared on CPU restart, MRES, or manually via PLC → Clear Diagnostic Buffer. Always capture the buffer before clearing, and after every SDB-related download wait 60 s for the buffer to settle before reading it.

Backup and Restore Best Practices

Migration to TIA Portal

Engineers maintaining long-lived STEP 7 V5.x projects often need to compare the SDBs against a TIA Portal project after a partial migration. The workflow uses the Migrate Project tool in TIA Portal (V13 SP1 and later) to lift the STEP 7 project into a TIA Portal device. The System Data Container that results can be compared structurally with the TIA Portal project. For an audit-grade comparison, the TIA Portal V21 comparing PLC programs documentation outlines the data types, block types, and comparison scope the portal tool supports.

Three caveats apply to the SDB portion of a STEP 7 → TIA Portal migration:

1. Some SDBs (notably PROFIBUS FMS and FDL) are dropped in the migration because TIA Portal does not support them on newer CPUs.
2. Global Data SDBs (SDB 10/11) are migrated to the TIA Portal "Global Data" mechanism, but the migration is one-way; do not expect to roundtrip back to STEP 7 with full GD fidelity.
3. H-system SDBs for S7-400H migrate only if the TIA Portal target device is an H-CPU with the matching support package installed.

Troubleshooting Matrix

FAQ