SIMATIC PCS 7 Plant Asset Management: Resolving _1 Suffix Issues in Diagnostic Screens

The Create/Update Diagnostics Screen wizard in SIMATIC PCS 7 Plant Asset Management (PAM) appends suffixes such as _1, (1), and (2) to picture, folder, and object names whenever it regenerates WinCC runtime diagnostics. The suffix is added to keep picture references unique inside the WinCC picture cache, and it is visible to operators on the Maintenance Station faceplate even when the underlying HW Config object already has a unique name. Because the wizard re-derives these names from hardware and hierarchy data on every run, manual edits inside WinCC Explorer are overwritten the next time the function executes.

This reference explains why the suffixes are produced, how to override them through the plant hierarchy, and which PCS 7 license tier is required for the level of diagnostics you need. The recommendations are valid for PCS 7 V8.2 SP1 through V9.1 SP2 and align with the operator station manual available on the Siemens support portal.

1. Overview of the _1 / (1) Suffix Phenomenon

Two distinct mechanisms generate the suffixes that engineers see in WinCC Explorer and the OS runtime:

The Maintenance OS treats the picture name as a global identifier. WinCC Runtime cannot open two picture windows that resolve to the same .pdl file under the same @ prefix on the same process picture, so the generator resolves the collision by appending a numeric suffix. The numeric suffix is stable until you change the underlying HW Config object name, the plant hierarchy folder, or the picture name override.

2. How "Create/Update Diagnostics Screens" Generates Picture Names

The wizard is launched from SIMATIC Manager → Options → Plant Asset Management → Create/Update Diagnostics Screens. The generation pipeline is:

1. Hardware object enumeration. The wizard reads HW Config data from the active S7 program and identifies every diagnostic-capable object: AS 400 / AS 410 CPUs, CP 443-1, CP 443-5, IM, ET 200 stations, HART / PROFIBUS / PROFINET field devices imported through SIMATIC PDM.
2. Hierarchy mapping. Each hardware object is associated with a Plant Hierarchy (PH) folder using the plant view assignment configured in HW Config (right-click a slave or I/O module → Object Properties → Plant View Assignment).
3. Picture template selection. For every object class the wizard selects a diagnostic picture template. Templates are stored under Siemens\Automation\PCS7\PAM_Lib\<version>\pictures in the engineering station and copied into the OS project as @PG_<ClassName>.pdl.
4. Name composition. The proposed picture name is formed as <HierarchyFolder_PictureName>_<HWObjectName>.<extension>. When the composite name already exists in the OS picture cache, the generator appends _1, _2, ... until uniqueness is reached.
5. OS delta compile. The generated pictures are added to the WinCC OS project. Picture windows inside the parent process picture are updated with the new instance names. The (1), (2) suffix is added at this point to differentiate instances of the same picture template on a single parent picture.

Two engineering decisions feed the generator: the HW Config object name and the Hierarchy folder picture name. Both can be changed, but only the hierarchy-level setting survives subsequent regenerations cleanly because the HW Config name is owned by the hardware project and propagates to NetPro, symbol tables, and PDM.

3. Why the Suffixes Cannot Be Renamed Directly in WinCC

Manual renames in WinCC Explorer are temporary. On the next invocation of Create/Update Diagnostics Screens the wizard performs a reconciliation pass:

• It rebuilds the proposed picture name from HW Config data and hierarchy data.
• It compares the proposed name against the existing OS picture cache.
• It overwrites the picture file, picture window property, and any faceplate tag bindings that referenced the old name.

The override is therefore not done at the picture level but at the Control and Monitoring Attributes of the hierarchy folder. That attribute is read by the generator and becomes the seed of the composite picture name. When the attribute is populated, the generator uses it verbatim and skips the conflict-check on picture suffixing for the affected branch.

4. Renaming Hierarchy Folders for Custom Runtime Names

The supported override path is the Control and Monitoring Attributes tab on a Plant Hierarchy folder. The property is stored in the PH dataset of the master data library and propagated to the OS during the next OS compile.

4.1 Properties of the Override

4.2 Naming Rules That Must Be Respected

• Maximum 24 characters for the picture name portion (WinCC file name limit when combined with prefix and suffix).
• Allowed characters: A–Z, 0–9, _. Avoid spaces, dashes, and national characters; WinCC stores the file as <Name>.pdl and any special character forces a rename on download.
• Names must be unique within the OS picture cache. The generator only checks collisions against the OS it is compiling, so a name that is unique in OS1 can still collide in OS2 if both OS share the same master data library.
• The override applies to the folder and is inherited by all child hierarchy levels unless a child folder has its own override.

5. PCS 7 Maintenance Station License Tiers

The Maintenance Station ships in two license configurations. The license determines which diagnostic screen is shown when an operator double-clicks an alarm in the Maintenance OS alarm line.

For detailed information on the licensed functions, refer to the PCS 7 Operator Station manual entry on the Siemens support portal (support.industry.siemens.com, entry ID 35353014). The Maintenance Station functionality is also referenced in the SIMATIC PDM documentation, since field device diagnostics are surfaced through PDM faceplates.

License assignment is per OS project. A multi-OS PCS 7 plant can mix the tiers: the process OS uses only a Standard license for the alarm line, while a dedicated Maintenance OS runs with the Standard or Asset Management license and is reserved for the maintenance crew.

6. Diagnostic Coverage of CP-443-1 and Other Communication Processors

The CP 443-1 is the Industrial Ethernet / PROFINET communication processor for the S7-400 AS. It generates diagnostic events for link status, port errors, TCP / ISO-on-TCP connection failures, and PROFINET station diagnostics. The Maintenance Station surfaces only a subset of these events, and the coverage depends on the license tier and the version of PCS 7.

6.1 What the Maintenance Station Shows for a CP-443-1

• Standard license: A status icon on the maintenance overview, the diagnostic buffer entries that are mirrored from the CP into the CPU diagnostic buffer, and the rack-level status aggregate. No per-port statistics.
• Standard license + SIMATIC PDM: When the CP is configured as a PROFINET IO controller and the connected devices are loaded into PDM, device-level diagnostics for the connected PROFINET devices are available; the CP itself remains a status icon only.
• Asset Management option: Adds electronic nameplate and lifecycle data for the CP, which is useful for replacement planning, but does not add port-level diagnostics.

6.2 Where to Get the Full CP-443-1 Diagnostics

For the full diagnostic picture of a CP 443-1, use one of the following tools in addition to the Maintenance Station:

• NCM S7 Diagnostics (part of STEP 7 / SIMATIC Manager): shows the live status of every port, every TCP connection, and the diagnostic buffer of the CP. Reachable via Start → SIMATIC → NCM S7 → Diagnostics.
• Web server of the CP 443-1 (firmware V3.x and later): accessible from a standard browser once the web server is enabled in HW Config, and provides the same information as NCM S7 Diagnostics plus identification data.
• CPU diagnostic buffer (Online → Accessible Nodes → Diagnostic Buffer in STEP 7): every CP-443-1 event that the CPU is configured to forward appears here with timestamp, event ID, and the associated OB number.
• SIMATIC Automation Tool and PRONETA: useful for network topology and PROFINET device diagnostics but do not show CP-internal TCP connections.

Plan the maintenance workflow accordingly: the Maintenance Station is the right tool for field device and AS-station diagnostics, while a CP 443-1 problem should be triaged with NCM S7 Diagnostics or the CP web server. The Maintenance Station status icon is then used as the alarm trigger, not as the investigation tool.

7. Working with the WinCC Picture Cache and Picture Names

WinCC stores pictures in the OS project database. Picture names that contain a numeric suffix are still valid references, but several subsystems prefer the un-suffixed name:

• OS project editor: when you open the parent picture in Graphics Designer, the picture window object property Picture Name holds the suffixed reference (for example @PG_ET200S_1.pdl). Renaming the source file in WinCC Explorer does not update this property; use Project Documentation to locate the broken reference.
• Tag prefix for the faceplate interface: a picture instance named @PG_ET200S_1.pdl creates an interface tag prefix @PG_ET200S_1#. Operators do not see this prefix, but the prefix is the binding target for internal tags and for user diagnostics blocks FB 126 / FB 127.
• OS server redundancy: in a redundant OS pair, both servers must contain the picture with the same name. Suffixing is per-OS project, so a name change on OS1 is invisible to OS2 until OS2 is also recompiled.

7.1 Where the Suffix Is Added in the OS Project

8. Step-by-Step Configuration Procedure

The procedure below eliminates the _1 / (1) suffix from the operator-visible faceplate caption while keeping the HW Config object name untouched. Run the steps in the engineering station with the master data library and the S7 program both opened.

8.1 Prerequisites

• PCS 7 V8.2 SP1 or later engineering station with the Maintenance Station option installed.
• SIMATIC PDM installed and licensed for the field device count of the project.
• Plant Hierarchy defined at least down to the unit / equipment level (level 4 to 7) and assigned to the corresponding HW Config objects.
• OS project in the master data library, last compiled successfully.
• Authorizations: SIMATIC Manager Plant View Edit, OS Project Edit, Hierarchy Configuration.

8.2 Renaming the Hierarchy Picture Name

1. In SIMATIC Manager, switch to the Plant View and navigate to the unit folder that contains the hardware object you want to rename. Example: Plant → Area 1 → Unit 10 → ET200S_Reactor_Inlet.
2. Right-click the hierarchy folder and choose Properties.
3. Open the Control and Monitoring Attributes tab.
4. Locate the field Picture name for OS. The current value follows the pattern PG_<FolderName>. Replace it with the desired operator-visible name, for example PG_Reactor_Inlet_ET200S. Observe the 24-character limit and the allowed character set.
5. Click OK to apply. Repeat for every hierarchy folder that currently has a suffixed name.
6. Optional: also set Picture name in picture tree if the picture-tree caption should differ from the OS faceplate caption (for example, to keep a short caption in the tree and a longer one in the faceplate header).

8.3 Removing the (1) / (2) Instance Suffix

1. Open the parent process picture in WinCC Graphics Designer.
2. Locate the picture window that holds the diagnostic faceplate. Its Picture Name property shows the suffixed reference such as @PG_Reactor_Inlet_ET200S_1.pdl.
3. Confirm that no other picture window on the same parent picture references the same underlying picture template. If a collision exists, the (1) / (2) counter is the only legal way to keep both instances; in that case, leave the suffix in place and fix the collision by moving one of the instances to a different parent picture.
4. If there is no collision, edit the Picture Name property to remove the trailing _1 / (1) and save the picture.
5. Recompile the OS. The compiler validates the picture reference and will surface any collision that was not detected visually.

8.4 Regenerating the Diagnostic Screens

1. In SIMATIC Manager, select the S7 program in the Plant View.
2. Choose Options → Plant Asset Management → Create/Update Diagnostics Screens.
3. In the wizard, enable Update existing screens and disable Reset manual changes. The second option is important: it preserves the picture-name overrides applied in step 8.2.
4. Click Finish. The wizard walks the hierarchy, applies the new picture names, and reports the count of created, updated, and skipped pictures.
5. Open the OS project, run OS Project Editor → Compile with the Delta compile profile, and download to the OS server / OS client pair.

8.5 Hiding the Hierarchy Folder Name (Optional)

Operators who navigate the picture tree see the hierarchy folder caption, not the picture file name. To keep the tree clean:

• Set Control and Monitoring Attributes → Picture name in picture tree to a short mnemonic, for example REACTOR_INLET.
• Set Picture name for OS to the longer, descriptive name used on the faceplate, for example PG_REACTOR_INLET_ET200S_FULL.
• Compile and verify on the OS Runtime that the caption matches the expectation.

9. Verification and Commissioning Checks

After the regeneration, run the following checks before signing off the change:

10. Troubleshooting Matrix

11. Best Practices for Large PCS 7 Plants

For plants with several hundred HW Config objects and multiple Maintenance OS clients, the following engineering rules keep the picture cache clean and the suffix collisions rare.

• Standardise the hierarchy picture-name pattern. Adopt a project-wide convention such as PG_<AREA>_<UNIT>_<DEVICE>. This is the single most effective way to avoid _1 / _2 suffixes.
• Decouple HW Config names from operator names. HW Config names should describe the hardware role (for example ET200S_RIO1); the hierarchy picture name should describe the process role (for example PG_Reactor_Inlet_RIO).
• Document the override in the master data library, not in the S7 program. The override propagates with the master data library; the S7 program is regenerated from hardware data on every project migration.
• Reserve one picture template per device class on a single parent picture. If two PROFINET devices of the same class are visible on the same process picture, prefer two parent pictures over a single parent picture with two suffixed instances.
• Run a full OS compile after every bulk rename. A delta compile updates pictures and tags, but tag prefix and authorization assignments are reconciled only on a full compile.
• Use a dedicated Maintenance OS for CP diagnostics. The Maintenance OS can host the NCM S7 Diagnostics view as an embedded C script, so the operator can drill from a CP-443-1 status icon straight into the CP diagnostic buffer without leaving the OS client.

The same diagnostic naming model also appears in asset-management standards. For a reference architecture of asset-management concepts (asset register, asset hierarchy, lifecycle data) and how they map to industrial control systems, the EPA Fundamentals of Asset Management PDF provides a useful high-level overview, while the Yokogawa PRM technical report on unified diagnoses management is a useful cross-vendor reference for the diagnosis data model. ABB's 800xA Asset Optimization brochure documents an alternate implementation of the same maintenance-station concept. The cross-vendor context is helpful for engineers who must integrate PCS 7 with an EAM system such as SAP PM, IBM Maximo, or Infor EAM.

12. Frequently Asked Questions