Inside a TIA Portal Export. Siemens I/O Tags.

A TIA Portal XML export is a structured representation of part of a Siemens project. For I/O tag work, the export usually contains tag tables and one or more GlobalDB blocks. Reading the XML to understand what the export carries is useful when the export is being generated by a tool other than TIA Portal itself, or when the export needs to be tweaked before import. This is a reader's guide to the format.

What gets exported

TIA Portal exports several kinds of artifacts, each with its own XML schema.

• PLC Tag tables. Tag-to-address mappings for physical I/O.
• GlobalDB blocks. Named, typed data blocks for program use.
• Function blocks and functions. Code blocks, out of scope for this post.
• HMI tags and screens. Separate WinCC export.
• Hardware configuration. Rack, slot, and module assignment.

For a controls handover that says "give me the I/O tags," the relevant artifacts are the PLC tag tables and any GlobalDBs that the I/O references.

The XML root and namespace

A TIA Portal export starts with a Document root and an Engineering namespace. The header elements identify the export as TIA Portal v17, v18, v19 or whichever, and pin the schema version. A simplified outline.

<Document>
  <Engineering version="V18">
    <DocumentInfo>...</DocumentInfo>
    <SW.Tags.PlcTagTable ID="0">...</SW.Tags.PlcTagTable>
    <SW.Blocks.GlobalDB ID="1">...</SW.Blocks.GlobalDB>
  </Engineering>
</Document>

The version pin matters. A v18 export imports cleanly into v18 and forward, but importing into v17 sometimes fails on schema mismatch. The receiving project version drives which export version to produce.

Tag tables in detail

A SW.Tags.PlcTagTable element holds a flat list of PLC tags. Each tag carries.

• Name
• Data type
• Logical address
• Comment

A simplified tag entry.

<SW.Tags.PlcTag ID="3" CompositionName="Tags">
  <AttributeList>
    <DataTypeName>Real</DataTypeName>
    <LogicalAddress>%IW100</LogicalAddress>
    <Name>FT_2105_PV</Name>
  </AttributeList>
  <ObjectList>
    <MultilingualText ID="4" CompositionName="Comment">
      <ObjectList>
        <MultilingualTextItem ID="5" CompositionName="Items">
          <AttributeList>
            <Culture>en-US</Culture>
            <Text>Feed flow to V-201, raw analog</Text>
          </AttributeList>
        </MultilingualTextItem>
      </ObjectList>
    </MultilingualText>
  </ObjectList>
</SW.Tags.PlcTag>

A few things to notice.

• The data type is a string drawn from the Siemens type vocabulary, Bool, Int, DInt, Real, LReal, Word, DWord, etc.
• The logical address uses Siemens notation, %I for input bit, %IW for input word, %Q for output bit, %M for memory.
• Comments are multilingual. The default culture is usually en-US but projects in non-English-speaking environments often add de-DE, nb-NO, or whatever the operator language is.
• Tag names follow Siemens identifier rules. No spaces, no leading digits, dot and dollar are reserved.

GlobalDB structure

A GlobalDB looks more like a struct definition. The block has a name, a number, and a hierarchy of members.

<SW.Blocks.GlobalDB ID="10">
  <AttributeList>
    <Name>FT_2105</Name>
    <Number>205</Number>
    <ProgrammingLanguage>DB</ProgrammingLanguage>
  </AttributeList>
  <ObjectList>
    <SW.Blocks.CompileUnit ID="11">
      <AttributeList>
        <NetworkSource>
          <Member Name="PV" Datatype="Real">
            <AttributeList>
              <StartValue>0.0</StartValue>
            </AttributeList>
          </Member>
          <Member Name="RangeLo" Datatype="Real">
            <AttributeList>
              <StartValue>0.0</StartValue>
            </AttributeList>
          </Member>
          <Member Name="RangeHi" Datatype="Real">
            <AttributeList>
              <StartValue>1000.0</StartValue>
            </AttributeList>
          </Member>
          <Member Name="Units" Datatype="String[16]">
            <AttributeList>
              <StartValue>'kPa'</StartValue>
            </AttributeList>
          </Member>
          <Member Name="HiAlm" Datatype="Real">
            <AttributeList>
              <StartValue>800.0</StartValue>
            </AttributeList>
          </Member>
          <Member Name="HiHiAlm" Datatype="Real">
            <AttributeList>
              <StartValue>950.0</StartValue>
            </AttributeList>
          </Member>
        </NetworkSource>
      </AttributeList>
    </SW.Blocks.CompileUnit>
  </ObjectList>
</SW.Blocks.GlobalDB>

Each instrument typically gets its own GlobalDB on Siemens projects following the standard library style. The DB carries the engineering values, range, units, alarm setpoints and the working PV. Code in function blocks reads from and writes to these DBs.

The block number, Number has to be unique within the project. The standard practice is to assign block numbers programmatically based on the tag, so FT-2105 becomes DB 2105 or DB 21050 by some deterministic rule.

Optimized versus standard data blocks

S7-1500 supports optimized data blocks where members are addressed by name only. S7-1200 and older S7-300, 400 use standard blocks where members have explicit byte and bit offsets.

Optimized blocks, Optimized="true" are smaller, faster, and friendlier to refactor. Standard blocks expose offsets that older code may rely on for direct address access.

The export carries the flag, so the receiving project preserves the choice. A v18 export from an S7-1500 project with optimized blocks importing into an S7-1200 project requires conversion to standard blocks, which TIA Portal does on import but with warnings.

Data type catalog

Common Siemens data types that appear in I/O exports.

For HART secondary variables, the standard library expects Real for the value and a Bool for the validity flag. Multi-variable HART devices often produce four Real plus four Bool per device.

Hardware configuration

The hardware configuration export pins the rack, slot, and module assignment for the controller. It is a separate artifact from the tag tables, but the I/O addresses in the tag table only make sense in the context of the hardware configuration.

A typical export structure includes.

• Station definition, CPU type, firmware version
• Rack and module list
• Module-by-module address assignment
• Network interface configuration, PROFINET, PROFIBUS
• Device-level configuration for connected drives, HMIs, and remote I/O

If you receive a tag table without the matching hardware config, the addresses are only useful if you already know the hardware layout.

Differences between S7-1500 and S7-1200 exports

A few practical differences.

• Optimized DBs. Standard on S7-1500, not supported on S7-1200.
• LReal. S7-1500 only. S7-1200 uses Real for floating point.
• Block size. S7-1500 supports much larger DBs and FBs. An export sized for S7-1500 may not import cleanly into S7-1200.
• Instruction set. S7-1500 has richer instructions for math, motion, and communication. The hardware-config export reflects this.
• PLC tag count. S7-1500 supports tens of thousands of tags. S7-1200 is more constrained.

For an I/O tag export that targets both controllers, sticking to Real, Bool, Int, and standard DBs keeps the export portable.

What an exported instrument tag actually looks like

Following the convention in this post, a single field instrument like a pressure transmitter typically appears in three places in the export.

1. A PLC tag entry mapping FT_2105_RAW to the physical analog input address.
2. A PLC tag entry mapping FT_2105_PV to a memory address holding the scaled engineering value, or the optimized DB member.
3. A GlobalDB FT_2105 carrying range, units, alarm setpoints, and the working PV.

Naming conventions vary by project. Some use underscores between elements, some use camelCase, some use dollar-sign delimiters in older projects. The export captures whatever the source project uses.

Common errors importing the XML

A few patterns that cause imports to fail or import incorrectly.

• Schema version mismatch. Exporting from v18 and importing into v17 without re-export usually fails on schema version.
• Block number collisions. Two GlobalDBs with the same Number cannot coexist. Renumbering before import is usually unavoidable when merging two projects.
• Reserved word collisions. Tag names like Output or Input are reserved in some contexts. The export carries them, the import rejects them.
• Inconsistent culture entries. Comments in cultures the receiving project does not have configured silently drop on import.
• Optimized to standard conversion warnings. Imports between controllers with different DB philosophy work but produce warnings that should not be ignored.

How tag-extraction tooling produces TIA Portal exports

A P&ID extraction tool that targets TIA Portal output has to.

• Map ISA signal classes to Siemens data types
• Generate Siemens-compliant tag names from project tag identifiers
• Assign block numbers deterministically from the tag
• Produce GlobalDB definitions that match the project's standard library style
• Pin the schema version to the receiving TIA Portal version

Tagsight produces TIA Portal XML as one of its eight export formats. Block numbers are derived from tag numbers, data types are chosen to remain portable across S7-1500 and S7-1200, and the schema version is selectable at export time. The upstream step of building a clean, column-complete I/O list before exporting to TIA Portal is covered in the I/O list creation guide.

The TIA Portal export is the final controls output on Siemens projects. When it is well-structured, the programmer imports it and starts writing logic. When it is malformed, every tag is a manual cleanup. Reading the XML once, understanding what the elements mean, and validating exports against the receiving project version is a small upfront cost that compounds across every handover for the life of the project.

Further reading

• Siemens TIA Portal documentation
• Siemens Application Programming Guide for SIMATIC S7-1200, S7-1500
• Siemens Standard Library for Process Automation
• TIA Portal Openness API documentation, for programmatic generation of the XML