TIA Portal Software Units: S7-1500 Multi-User Engineering Guide

Software Units were introduced in TIA Portal V15.1 as a first-class project element for the SIMATIC S7-1500 and ET 200SP CPU families. They let multiple engineers work in parallel on the same CPU project, compile only the changed code segment, and download that segment without disturbing the other developers' sessions. The feature is bound to the project tree, not to a specific block folder, which is why the Software Units group appears in every TIA Portal V15.1+ project for a supported CPU and cannot be removed from the tree.

This reference explains what Software Units are, the firmware prerequisites, the per-CPU limits, why the project group is non-removable, the multi-user engineering workflow, and how to migrate older projects.

1. Overview and Purpose

A Software Unit is a logical compilation and download container inside a TIA Portal project. It groups user code blocks (OBs, FBs, FCs, DBs, UDTs) into a single entity that:

• Compiles independently of other Software Units in the same project.
• Downloads independently of other Software Units.
• Allows exclusive write access for one engineer at a time (multi-user checkout).
• Exposes a defined interface (Published interface) to other Software Units.

The feature is documented in the Siemens guideline Guideline on how to use Software Units in TIA Portal (V1.1, PDF) and is conceptually aligned with the engineering practice of unit-based modular software applied at the PLC project level.

2. CPU and Firmware Prerequisites

Open the device configuration of the S7-1500 CPU, navigate to Properties > General > Catalog information to confirm the firmware version. The Software Units group is hidden from the project tree whenever the CPU firmware is below the required level, so an absent group in a V15.1+ project almost always points to a CPU firmware mismatch.

3. Project Structure and the Non-Removable Group

In a TIA Portal V15.1+ project for a supported CPU, the project tree contains the following fixed node under the CPU device:

PLC_1
  ├── Device configuration
  ├── Online & diagnostics
  ├── Program blocks
  ├── PLC tags
  ├── PLC data types
  ├── Watch and force tables
  ├── Traces
  ├── Receipts
  ├── Software units         <-- ALWAYS present, non-removable
  │     ├── MyUnit_1
  │     │     ├── OB1 (Main)
  │     │     ├── FB_Conveyor
  │     │     └── DB_Recipe
  │     ├── MyUnit_2
  │     └── _DefaultUnit (system-generated)
  └── ...

The Software units group itself is a project-element container created by TIA Portal the first time a supported CPU is inserted into a V15.1+ project. It is not a folder the user can right-click and delete. Three behavioral rules apply:

1. The group is created automatically when the project is opened with a supported CPU in TIA Portal V15.1 or later.
2. The group cannot be removed via the project tree context menu; no Delete option is exposed.
3. The group is hidden (not removed) if the CPU is exchanged for one whose firmware is below the minimum, or if the project is opened in TIA Portal V15.0.

4. Software Unit Limits per CPU Family

The number of Software Units a CPU can host is bounded by both the CPU type and the loaded firmware. The exact ceilings are published in the Siemens guideline PDF referenced above. The table below summarises the public field-tested figures for the S7-1500 standard range; consult the latest Siemens release notes for your exact order number (6ES7-...).

Cross-unit interaction rules

• Calls from one unit into another are allowed only through the Published interface of the called unit. Direct calls into private blocks of another unit generate a compile warning or error.
• Global PLC tags and PLC data types remain shared and are not owned by any unit.
• Instance DBs and multi-instance data must live in the same unit as the owning FB.
• Shared DBs used across units must be marked as Accessible from outside.

5. Creating and Configuring a Software Unit

Prerequisites

• TIA Portal V15.1 Update 4 or later (V15.1, V15.1 Update 1 through 9, V16, V17, V18 all carry the feature).
• S7-1500 / ET 200SP CPU with firmware V2.5 or higher online or offline in the project.
• Optional: TIA Portal Multiuser Server license for true parallel editing.

Step-by-step procedure

1. Open the project in TIA Portal V15.1+.
2. In the project tree, right-click Software units > Add new software unit.
3. Assign a unit name that matches the machine subsystem (e.g. Unit_Conveyor, Unit_Packaging).
4. Right-click the new unit and choose Properties > General to set the unit author, version, and comment.
5. Switch to the Published interface tab and declare the FCs, FBs, UDTs and DBs that other units are allowed to call.
6. Move or create OBs, FBs, FCs, and DBs inside the unit. Anything placed under the unit's branch becomes part of that unit's compilation.
7. Compile only this unit via Right-click > Compile > Software (only this unit). Use Compile > Software (all) for a full project rebuild.
8. Download with Right-click > Download to device > Software unit selection to push only the changed unit.

6. Multi-User Engineering Workflow

Software Units are the building block of the TIA Portal multi-user workflow. The following SVG summarises the lifecycle of a unit under multi-user edit:

Key behavioural rules

• Only the engineer who has checked out a unit can write to it; the project server blocks the others.
• Two engineers may compile their respective units independently, in parallel, without interfering.
• Cross-unit calls go through the published interface, so a refactor of a private block in unit A does not break compilation in unit B.
• The first download after a server merge is a full project download; subsequent edits can use unit-only download.

7. Compilation and Download Behaviour

When you compile all software, TIA Portal walks the dependency graph across units, validates the published interfaces, and produces a single .out download container. When you compile only this unit, the IDE skips the dependency walk and produces an incremental download for that unit only.

8. Migration from Pre-V15.1 Projects

Projects created in TIA Portal V15.0 do not contain a Software units group. The following decision path is the recommended one:

1. Open the V15.0 project in TIA Portal V15.1+ and run Project > Upgrade. The blocks remain under the old Program blocks node.
2. Open the upgraded project. The Software units node will be created automatically because a supported CPU is present.
3. Existing program blocks are not migrated into units. You must manually move them into a new unit, or leave them in a default unit.
4. If the CPU firmware is below V2.5, upgrade the firmware first, then perform a full download to the new firmware, then proceed with unit restructuring.

9. Best Practices and Field Notes

• One machine subsystem per unit. Map a unit to a real-world function (conveyor, robot cell, dosing) rather than to a developer or a date.
• Keep the published interface minimal. Declare only the FCs, FBs, UDTs and DBs that other units must call. The smaller the interface, the fewer cross-unit regressions.
• Use a default unit for shared utilities. Put logging, alarm helpers, and common UDTs in one well-named unit (e.g. Unit_Common); do not duplicate them across units.
• Tag units as restart-free where possible. This enables unit-only downloads to a CPU in RUN and minimises production interruptions.
• Compile all before merging. A merge on the multi-user server does not re-compile. Force a full compile on the merged server project to catch interface mismatches before download.
• Reserve one unit for HMI handshake DBs. DBs read by WinCC should live in a stable, rarely-changed unit to keep HMI reconnection logic deterministic.

10. Troubleshooting Matrix

11. Field-Proven Edge Cases

• Firmware gate. Even when the project is opened in V15.1+, an S7-1500 CPU with firmware V2.0 keeps the Software units node hidden. Upgrading the CPU firmware requires a full download to the new firmware before units become visible.
• Device exchange. Exchanging the CPU for one from the S7-1200 family hides the group but does not break compilation of existing program blocks. Reverse exchange restores the group and forces the IDE to reclassify blocks.
• Library reuse. A master copy of a software unit can be created in the project library and instantiated into multiple CPU projects. The version of the master copy is independent of the consumer's units.
• Re-entrancy. A unit marked Re-entrant can be downloaded without disturbing the running program. Re-entrancy fails if any block in the unit uses a non-re-entrant system function (e.g. legacy SFC calls).
• Online diff. The online/offline compare honours the unit boundary. Diff reports are produced per unit, which simplifies change approval on a multi-engineer project.

12. FAQ