Siemens TIA Portal V16: I/O Mapping and Data Block Best Practices

Overview: S7 Project Architecture in TIA Portal V16

When commissioning an S7-1200 or S7-1500 controller, the choice of how I/O is scanned, how symbols are organized, and how Data Blocks (DBs) are allocated determines long-term maintainability. TIA Portal V16 (and the V16 SP1 update released January 2021) introduces additional options for symbolic structuring, multi-instance block calls, and dynamic symbol re-binding that are not available in the classic STEP 7 V5.x range. Before applying any pattern, identify the controller family because addressing semantics differ between the classic range (S7-300/S7-400 with STEP 7 V5.x) and the current range (S7-1200/S7-1500 with TIA Portal). The recommendations below apply to the current range; legacy notes are provided where behavior diverges.

Three structural decisions must be made up front:

1. Whether to consume the I/O through the automatic process image (PII/PIQ) or to read/write directly via peripheral access (PEW/PAB) inside the user program.
2. Whether to centralize tag names in a PLC tag table, in a global DB, or in User-Defined Data Types (UDTs/PLC data types).
3. Whether function blocks (FBs) are called as single-instance (each FB gets its own background DB) or as multi-instance (FBs share one parent instance DB).

The Siemens S7-1500 system manual, the S7-1200 system manual, and the TIA Portal programming and operating manual provide the full reference for the rules summarized here:

• S7-1500 Automation System System Manual
• S7-1200 Programmable Controller System Manual
• S7-1500 Programming and Operating Manual (S7-1500/ET 200MP)
• SIMATIC TIA Portal V16 Manuals Collection (SIOS)
• STEP 7 Basic/Professional V16 in TIA Portal - Function Manual

Prerequisites

• TIA Portal V16 (or V16 SP1) installed; the matching firmware version on the S7-1500 CPU is V2.6.x or higher. See the S7-1500 CPU firmware update description for supported combinations.
• Configured device network: S7-1500 CPU and any distributed I/O (ET 200SP, ET 200MP, SINAMICS drives, third-party PROFINET devices) on the same PROFINET subnet.
• PLC tag table created automatically by TIA Portal from the hardware configuration. To reach the editor: Project tree → PLC_x → PLC tags → Default tag table.
• A working watch table for verification: Project tree → PLC_x → Watch and force tables → Add new watch table.

I/O Scanning Behavior in S7-1200 and S7-1500

By default, the local I/O of an S7-1200/1500 CPU is updated synchronously with the OB1 cycle. The CPU copies the physical inputs into the Process Image of the Inputs (PII) at the start of OB1 execution, and writes the Process Image of the Outputs (PIQ) back to the physical outputs at the end. This decouples the application program from the duration of the physical I/O update and gives deterministic scan semantics.

You can override the default in the device configuration: Devices & networks → CPU → Properties → Process images → Overview. The "Update of the process image" column accepts three settings per I/O region:

• Automatic update — the CPU refreshes the area on every OB1 cycle. Default for the first 1024 bytes on the S7-1500.
• Manual update — the application program is responsible for refreshing the area using the system function block UPDAT_PI (update PII) or UPDAT_PO (update PIQ). Use this for I/O areas accessed only from interrupt OBs.
• No update — the area is excluded from the automatic process image. Reads must use direct peripheral access: %IW0:P (input word, peripheral) or %QW0:P (output word, peripheral). The :P suffix is the TIA Portal syntax for direct access.

Is I/O Mapping Mandatory?

In the classic range, I/O mapping was effectively mandatory because the only way to keep the program readable was to mirror the raw addresses (I0.0, Q4.1, IW64, QW80) into a DB and operate only on the mirrored tags. In the current range, TIA Portal's symbolic I/O capability makes explicit I/O mapping optional in most cases.

Symbolic I/O works because TIA Portal treats the address %I0.0 as both an absolute and a symbolic tag. The symbolic name (for example CONVEYOR_START_PB) is edited directly in the PLC tag table and is updated everywhere in the program when reassigned. Re-mapping an input to a different terminal block is therefore a single-line edit in the tag table, not a project-wide search-and-replace.

I/O mapping into a Data Block is still valuable in three situations:

1. Repeated structures — a bank of identical drives, valves, or I/O slices. A DB_MAPPING_DRIVE containing an array of UDTs is easier to scale than a flat tag table.
2. Forcing time-updated I/O into scan-cycle semantics — if a hardware interrupt OB reads direct peripheral access, copy the value into a DB variable that the OB1 cycle can consume deterministically.
3. Cross-program exchange — the HMI, the SCADA OPC UA server, and a remote CPU exchange values through a named DB rather than through overlapping tag tables.

Data Block Architecture: Global, Instance, and Multi-Instance

DBs in S7-1200/1500 fall into two physical categories, each generated by a different code path in TIA Portal:

To enable optimized block access, open the DB or FB editor, right-click the block in the project tree, choose Properties → Attributes, and tick Optimized block access. Optimized blocks store only the tags that are actually used, eliminate type-alignment padding, and unlock retentive tag granularity.

Global DB example: HMI faceplate parameters

The pattern for an HMI faceplate is a global DB whose tags are exposed to WinCC Unified/Professional through the HMI tag connection. The DB holds the parameters and status of one device; the HMI references the same DB tags symbolically:

// DB "DB_HMI_Pump_01" - optimized block access, retentive for setpoints
TYPE "UDT_Pump_Params"
VERSION : 0.1
  STRUCT
    SpeedSetpoint_RPM : Real;    // 0.0 .. 3000.0
    SpeedActual_RPM   : Real;    // 0.0 .. 3000.0
    Current_A         : Real;    // 0.0 .. 999.9
    RunRequest        : Bool;    // command from HMI
    FaultActive       : Bool;    // status to HMI
    OpHours           : DInt;    // hours, retentive
  END_STRUCT;
END_TYPE

DATA_BLOCK "DB_HMI_Pump_01"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
NON_RETAIN
  Pump : "UDT_Pump_Params";

The HMI then binds to DB_HMI_Pump_01.Pump.SpeedSetpoint_RPM symbolically. With optimized access, the tag does not occupy a fixed offset, so reordering the UDT members later does not break the HMI connection as long as the symbol names are preserved.

Multi-instance pattern for modular code

A multi-instance call embeds the FB as a STATIC variable of a parent FB. The parent FB holds one DB; all child FBs share that DB. This is the canonical pattern for repeated function blocks — for example, ten motor starters in a single DB:

FUNCTION_BLOCK "FB_MotorStarter"
VERSION : 0.1
VAR_INPUT
  Start : Bool;
  Stop  : Bool;
  Overload : Bool;
END_VAR
VAR_OUTPUT
  Running : Bool;
  Fault   : Bool;
END_VAR
VAR
  State : Int;       // 0=Idle, 1=Starting, 2=Running, 3=Stopping
  T_Start : TON;     // on-delay instance, multi-instance
END_VAR
BEGIN
  // latching start logic, overload trip, etc.
END_FUNCTION_BLOCK

FUNCTION_BLOCK "FB_MCC_TenMotors"
VERSION : 0.1
VAR
  M1 : "FB_MotorStarter";   // multi-instance, no separate DB
  M2 : "FB_MotorStarter";
  M3 : "FB_MotorStarter";
  M4 : "FB_MotorStarter";
  M5 : "FB_MotorStarter";
  M6 : "FB_MotorStarter";
  M7 : "FB_MotorStarter";
  M8 : "FB_MotorStarter";
  M9 : "FB_MotorStarter";
  M10: "FB_MotorStarter";
END_VAR
END_FUNCTION_BLOCK

Calling FB_MCC_TenMotors once in OB1 generates a single instance DB IDB_MCC that contains all ten motor starters. Memory consumption is lower than ten independent instance DBs because the multi-instance shares headers, and the online view groups all starters under one parent block for diagnostics.

User-Defined Data Types (UDT) in TIA Portal V16

TIA Portal renamed the UDT concept to PLC data type. The two terms are equivalent. A PLC data type lives in Project tree → PLC_x → PLC data types and can be referenced by any DB, FB, or FC. In V16, PLC data types support:

• Nested structures (a UDT containing another UDT)
• ARRAY of UDTs with explicit bounds, e.g. ARRAY[1..32] OF "UDT_Valve"
• Direct HMI binding; the HMI imports the UDT and binds once to the array, propagating to all elements
• OPC UA exposure: the S7-1500 OPC UA server can publish a UDT as a complex data type

Use a UDT when three or more instances of the same logical structure exist. Below four, the marginal complexity of a UDT outweighs the benefit.

HMI Communication Block Pattern

It is common to see a dedicated DB named DB_HMI or DB_Communication in S7 projects. This is a global DB whose only purpose is to expose the values the HMI needs. A clean pattern groups all HMI data into one DB per HMI panel, with sections divided by UDTs:

DATA_BLOCK "DB_HMI_MP277"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
NON_RETAIN
  STRUCT
    System   : "UDT_SystemStatus";     // 32 bytes
    Motors   : ARRAY[1..10] OF "UDT_MotorStatus";  // 10 * 64 bytes
    Valves   : ARRAY[1..32] OF "UDT_ValveStatus";   // 32 * 16 bytes
    Recipes  : ARRAY[1..20] OF "UDT_RecipeRecord";  // 20 * 128 bytes
  END_STRUCT;
END_DATA_BLOCK

With this structure, the HMI imports DB_HMI_MP277.Motors as an array, and any tag added to the UDT propagates to all HMI screens automatically. Retention is set on the UDT elements that need to survive a CPU restart (for example Recipes[1].Parameters[5].Setpoint).

Recommended Program Block Layout

A typical S7-1500 project with TIA Portal V16 follows this block organization. The grouping is created with Program blocks → Add new group in the project tree:

Step-by-Step: Building a Clean Project in TIA Portal V16

1. Configure hardware first. Drag the CPU, I/O modules, and any PROFINET devices into the network view. Do not write any program code until the hardware compiles successfully. This forces the PLC tag table to reflect the real I/O addresses.
2. Set process image defaults. Open CPU properties → Process images and decide for each I/O area whether it uses automatic, manual, or no update. For most digital inputs and outputs, leave the default. For analog inputs sampled in a hardware interrupt, switch to "Manual update" and call UPDAT_PI in the OB40.
3. Create PLC data types before DBs. Go to PLC data types, right-click, Add new data type. Build UDT_MotorStatus, UDT_ValveStatus, and any other repeated structure first. This forces a clean separation between data shape and data instance.
4. Create the HMI DB. Add a single global DB named DB_HMI_Panel1 with optimized access. Place an ARRAY[1..N] OF "UDT_X" for each repeated entity that the HMI must show.
5. Build function blocks. Add the FB for one motor starter. Use VAR_INPUT, VAR_OUTPUT, VAR (static), and VAR_TEMP correctly. Enable optimized block access. Add a retain attribute on VAR elements that need to survive restart (for example RunHours).
6. Wrap FBs into multi-instance parents. Create FB_MCC_ZoneA with static instances of FB_MotorStarter. Inside FB_MCC_ZoneA, expose each motor's Running and Fault to the HMI by writing to DB_HMI_Panel1.Motors[i].
7. Wire OB1. Open OB1, drag a single call to FB_MCC_ZoneA. Pass symbolic tag names from the PLC tag table. Avoid absolute addresses in OB1; they should appear only in the FB input connections.
8. Configure the HMI connection. In the HMI project, add a connection to the PLC. The HMI tag list should import DB_HMI_Panel1 once; the array members are then available as HMI tags.
9. Compile and download. Project tree → right-click PLC → Compile → Software (rebuild all blocks). Resolve any warnings before download. The most common warning is "Tag used but not assigned" caused by an I/O module not being mapped in the hardware configuration.
10. Verify with a watch table. Create a watch table with the HMI DB tags, the OB1 cycle time, and one or two input bits. Trigger each input, observe the corresponding tag update. Force a few HMI tags to verify the data path both ways.

Verification Checklist

Troubleshooting Matrix

Performance and Memory Notes for S7-1500

The S7-1500 stores the program in work memory and loads blocks into load memory on demand. Optimized block access reduces the work memory footprint by storing only tags that are actually used. Multi-instance DBs reduce the per-instance header overhead and can cut instance-DB memory by 30–50% when many small FBs are used. PLC data types and arrays of PLC data types are stored as contiguous blocks and are cached as a whole, which is faster than reading individual DB members from a non-optimized DB.

For a project with approximately 50 motors, 100 valves, and 30 analog signals, a typical optimized project consumes 200–300 KB of work memory on an S7-1515-2 PN. The non-optimized equivalent of the same logic typically consumes 400–600 KB. Exact numbers depend on the number of FBs and the size of each UDT.

When to Re-introduce I/O Mapping into a DB

Re-introduce a mapping DB when any of the following appear:

• The HMI driver (for example, a legacy WinCC flexible 2008 tag import) cannot bind symbolically and requires fixed offsets.
• A third-party OPC UA client reads the data as a flat namespace and cannot traverse nested UDTs.
• The project is being re-engineered from a STEP 7 V5.x project with a fixed DB layout, and the conversion tool generates a mapping DB to preserve offset compatibility.
• A regulator or FAT test procedure references a specific absolute DB offset (for example, "DB200.DBX4.0 = command").

Field-Commissioning Procedure

1. After hardware commissioning, download the project with PLC in Stop state.
2. Open the watch table; force each output off first, then sequentially enable outputs and verify the physical actuator.
3. Run the OB1 in single-step mode (online → Block → Single-step) and verify the program flow. Note the cycle time in the diagnostics buffer.
4. Trigger each hardware interrupt source; verify the corresponding OB40..OB47 fires by checking the OB count in the online diagnostics.
5. Pull one PROFINET module; verify OB83 (pull/plug) fires. Re-insert and verify the module returns to operation without a CPU restart.
6. Trigger a diagnostic fault on one channel; verify OB82 fires and that the diagnostic buffer records the channel with the correct slot and channel number.
7. Set a recipe value in DB_Recipes; stop the CPU, then run; verify the value persists.

FAQ