TIA Portal Openness: automating engineering work too

When we talk about industrial automation, we usually think of machines, sensors, and PLCs. Yet the work of the people who program those systems also involves repetitive tasks: preparing project variants, copying information, or making similar changes across many elements.
That raises an interesting question: can we automate some of the work we do inside TIA Portal?
Siemens provides a tool for this: TIA Portal Openness.
What is TIA Portal Openness?
Openness is an application programming interface, or API, that lets a custom application control TIA Portal and access its engineering data. In this context, an API is a set of functions that another program can use to perform structured operations.
Instead of carrying out every step manually in the editor, we can write an application that reads, creates, or modifies project data through the available operations. Siemens describes this external access in its official introduction to Openness.
The focus of this tool is the engineering project. If we want to collect production data continuously, we need to evaluate the control system's communication interfaces; understanding Openness alone does not solve that integration.
What can it be used for?
Siemens describes Openness as an integrated API for STEP 7 and WinCC, with applications such as generating PLC software blocks and HMI content. The specific functions depend on the version, the product, and the objects exposed by the API. See its explanation of automated engineering.
With that foundation, we can consider building our own tools to:
- Prepare project variants, using a common structure and parameters specific to each machine.
- Exchange engineering data, through the available import and export functions.
- Review project information, applying our own rules to the data we can query.
These are potential development goals. Openness provides access; we still need to build the logic that determines what to generate, what to check, and how to handle an error.
An example: machines with a common structure
Imagine a family of machines that shares much of its program but varies in the number of modules and installed options.
A custom tool could receive those parameters and use Openness to prepare the corresponding variant from a base project. The workflow would be:
Machine parameters → custom application → TIA Portal → project ready for review.
Siemens documents this type of generation for modular machines in its Openness manual.
This is a hypothetical example: it does not demonstrate a specific time saving. Its usefulness would depend on how often the work is repeated, the quality of the base project, and the effort required to develop and maintain the tool.
What do you need to get started?
You need to understand TIA Portal and learn to develop applications that use its API. C# is a common approach: Siemens uses examples in that language throughout the documentation.
You also need to check the installation and requirements for the version you plan to use. For example, the V20 requirements documentation specifies that a TIA Portal-based product and the Openness component must be installed. Check the requirements for your particular version rather than assuming that all environments are equivalent.
Access requires permissions. Siemens describes the local Windows group Siemens TIA Openness and application connection authorization in its Openness access control documentation.
To explore code, there is also an official Siemens repository of V20 examples. Its snippets are intended for learning and experimentation; they are not a finished application or a comprehensive set of tests of its behavior.
Where to begin
A useful first exercise would be to query a copy of a project and produce a small inventory of accessible information. This lets us become familiar with the API's structure before introducing automated changes.
Then choose a narrowly defined task: specify its input, the expected result, and how to verify it. Automation can repeat an incorrect rule just as quickly as a correct one. A generated project still needs review and testing before it is used on a machine.
The appeal of Openness lies in applying our software tools to the engineering process itself. When a task repeats and its rules are clear, it is worth exploring whether we can turn it into a reproducible procedure.
We automate machines. We can also start automating some of the tasks needed to build them.
