C135 PCS 7 (PCS7)
6C
6 Cielo Ciencia y Tecnología
·Publicada en C135 PCS 7 (PCS7)

Troubleshoot an Unexpected OS PO License Count After a PCS 7 Compile

Troubleshoot an Unexpected OS PO License Count After a PCS 7 Compile

When PCS 7 reports a large OS PO count after compilation and WinCC enters demo mode, first identify the requested license category and reproduce the count in a project copy. Do not treat an AS RT PO total as proof of OS runtime capacity. In the reported V8.0 SP1 configuration, the unusually high count also existed in older archives, and no confirmed repair was established; preserve the working redundant server while collecting evidence.

Table of Contents

Separate the Reported Counts

The affected installation is PCS 7 V8.0 SP1 with reported WinCC V7.0, a CPU 416-5H and redundant OS servers. After an OS compile and standby download, runtime enters demo mode with a reported demand of 42,045 POs against 2,300 licensed OS RT POs.

The observations include 1,762 POs on the unchanged master and 2,017 on a backup engineering station. These are different project states, not interchangeable measurements of one verified configuration. The high count was later found in older archives; the latest compile is therefore not established as its origin.

Check the License Category

Siemens' V8.0 SP1 licensing manual distinguishes AS RT PO for AS downloading from OS RT PO for operator-station runtime. Do not compare a multiproject AS count directly with an OS runtime requirement and conclude that OS capacity is sufficient.

Record each value with its category, project/archive revision, selected compilation scope and target computer. Keep private license identifiers out of shared diagnostic material. The opened documentation does not explain the anomalous 42,045 value.

Inspect Runtime License Diagnostics

The reply proposes WinCC License Analysis. The opened WinCC V7.2 manual independently documents SIMATIC > WinCC > Tools > License Analysis, showing required and installed licenses and highlighting missing or insufficient items in red. This is a V7.2 reference; verify the corresponding tool and location on the reported V7.0 installation.

  1. On the affected standby, locate the installed license diagnostic function without changing licenses.
  2. Record which exact license category is requested and which requirement is unsatisfied.
  3. Compare that category with the locally available license capacity.
  4. Retain the diagnostic result alongside the OS project revision and compile record.

Do not move license keys from the operating partner as an exploratory fix.

Isolate the Compile Contribution in a Project Copy

A reported investigation deselected all four AS sources, then added them individually; the count increased when either of two particular AS sources was included. Repeating this comparison is a diagnostic experiment, not a documented repair.

  1. Work on a preserved engineering copy, without downloading to production.
  2. Record the starting OS count and compilation selections.
  3. Add one AS source at a time and record the resulting count using the same procedure.
  4. Compare the affected sources and archives with the backup engineering project.
  5. Preserve a reproducible example for manufacturer investigation.

A correlation with an AS source narrows the scope; it does not identify a corrupt database or a specific faulty block.

Verification

A resolved case needs a reproducible, justified OS PO requirement and confirmation that the intended runtime project operates within its appropriate license capacity. Compare both redundant servers' deployed project revisions and diagnostics before accepting recovery.

No successful correction is documented. A lower count from an old archive does not prove that restoring that archive preserves the required current application.

Limitations and Operational Precautions

The count discrepancy, its internal cause and a safe correction remain unresolved. The actual installed WinCC service pack/update also needs confirmation. Do not edit license or project database internals, purchase additional capacity solely to match an unexplained count, or restore an old AS program to address an OS symptom.

Preserve the operating server while investigating the standby. Review the redundancy state, backup and rollback before any deployment. Whether a particular restore or download requires CPU STOP must be established from its actual changes rather than inferred from this licensing symptom.

Engineer FAQ

Are AS RT PO and OS RT PO the same check?
No. The V8.0 SP1 manual identifies separate purposes.

Is the last compile proven to have created the bad count?
No. The reported high value also appeared in earlier archives.

Is there a verified quick repair?
No confirmed repair was established.

Technical References

Related Articles

Related Tags

20 respuestas