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 relevant exports are PLC tag tables and, on many projects, 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. Its first child is an empty Engineering element whose version attribute names the TIA Portal version, such as V18. A DocumentInfo block usually follows, and then the exported object itself. Each exported document holds one object, so a tag table and a data block are two files. A simplified outline.

<Document>
  <Engineering version="V18" />
  <DocumentInfo>...</DocumentInfo>
  <SW.Tags.PlcTagTable ID="0">...</SW.Tags.PlcTagTable>
</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>Int</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.
• The data type matches the address width. Exported tag tables pair Bool with bit addresses and Int or Word with word addresses such as %IW and %QW. 32-bit types go on double-word addresses. A raw analog channel is a word, so it is Int, and the scaled Real lives elsewhere.
• 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.
• PLC tag names are more permissive than the variable names most PLC platforms accept. Exported tag tables carry names with spaces, commas, hyphens and leading digits, such as TM 2,5 Hz or 80.0. Whatever convention a project uses, keep it consistent, because code refers to the tags by name.

GlobalDB structure

A GlobalDB looks more like a struct definition. Besides its name and number, the block carries a memory layout and an interface whose Static section lists the members.

<SW.Blocks.GlobalDB ID="0">
  <AttributeList>
    <Interface><Sections xmlns="http://www.siemens.com/automation/Openness/SW/Interface/v5">
      <Section Name="Static">
        <Member Name="PV" Datatype="Real"><StartValue>0.0</StartValue></Member>
        <Member Name="RangeLo" Datatype="Real"><StartValue>0.0</StartValue></Member>
        <Member Name="RangeHi" Datatype="Real"><StartValue>1000.0</StartValue></Member>
        <Member Name="HiAlm" Datatype="Real"><StartValue>800.0</StartValue></Member>
      </Section>
    </Sections></Interface>
    <MemoryLayout>Optimized</MemoryLayout>
    <Name>FT_2105</Name>
    <Number>205</Number>
    <ProgrammingLanguage>DB</ProgrammingLanguage>
  </AttributeList>
</SW.Blocks.GlobalDB>

Projects organise data blocks in different ways. Some give each instrument its own global DB holding its engineering values. Others keep instrument data in the instance DBs of library function blocks, or in one DB per area. Code in function blocks reads from and writes to them.

The block number, Number, has to be unique within the CPU. TIA Portal can assign it automatically, which exports show as AutoNumber.

Optimized versus standard data blocks

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

Optimized blocks 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 choice as the block's MemoryLayout, Optimized or Standard, so the receiving project keeps it.

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. Supported on both. Only S7-300 and S7-400 are limited to standard blocks.
• 64-bit integers. LInt, ULInt and LWord are S7-1500 only.
• 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 and Int 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. Moving blocks to an S7-300 or S7-400 means standard access, and the conversion produces warnings that should not be ignored.

Where Tagsight fits

Tagsight exports a reviewed I/O list for TIA Portal as one of its export formats, so the programmer starts from the tags the engineers confirmed. The upstream step of building a clean, column-complete I/O list 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

• I/O list template