Siemens WinAC RTX vs Basis on Windows 2000: Platform Selection, Migration, and Configuration Reference

This reference consolidates the engineering decision path for replacing legacy DOS-based HMIs (e.g., Genesis for DOS) with a SIMATIC WinCC HMI plus a WinAC software-PLC backend, while migrating the control program from STEP 5 (S5) to STEP 7 (S7). It covers the determinism, OS support, and I/O architecture differences between WinAC RTX and WinAC Basis, the role of the CP5613 Profibus card, the Windows 2000 SP4 prerequisites for SIMATIC WinCC V5.1 SP1, and the registry-level configuration steps required for stable operation under the Windows 2000/NT family.

1. Application Context and Design Goals

The typical retrofit target is a machine or process line that currently runs on a S5 PLC with a DOS character-mode HMI. The objective is to consolidate HMI and soft-PLC onto a single Windows-based industrial PC, eliminate the DOS HMI's text-mode and storage limitations, and reuse field-proven S5 control logic by converting it to S7. The combined runtime has three named components:

• SIMATIC WinCC — the SCADA/HMI runtime, configuration studio, and operator interface.
• SIMATIC WinAC — a software PLC that executes the S7 control program on the industrial PC instead of a hardware CPU (e.g., S7-300/S7-400).
• STEP 7 — the engineering tool used to author the S7 program that WinAC executes.

Two distinct WinAC product lines exist, and the choice between them governs the Windows 2000 deployment path, the determinism profile, and the recommended Profibus interface hardware.

2. WinAC RTX vs WinAC Basis: Architectural Comparison

WinAC is not a single product; it is a family of soft-PLCs. The two variants that coexist in this generation differ at the real-time layer, not at the S7 language layer.

WinAC RTX sits between the Windows kernel and the VenturCom RTX HAL. The control program runs in RAM, not in NT-managed virtual memory pages that can be paged out, and control interrupts preempt an NT task so the S7 OB1 cycle is serviced on time. NT work is processed in user-defined idle windows of the control cycle. If Windows hangs or faults, the WinAC RTX control engine continues to scan the I/O provided the industrial PC remains powered and the CP5613 retains its Profibus link.

WinAC Basis has no separate real-time layer. It is a Windows process that wakes on a software timer. Cycle jitter is therefore a function of the host OS scheduling policy, DPC behavior, and what else is running on the same machine. Siemens has documented customers running machine-class applications on WinAC Basis under Windows NT, but the determinism budget is tighter and the platform should be free of unrelated workloads.

3. Windows 2000 OS Compatibility Matrix

The Windows 2000 question is not a single yes/no; it is a product-by-product decision. The matrix below is the engineering view of supported combinations in this era.

Where the source material states "WinAC currently does not support Win 2000," this is the RTX variant. WinAC Basis does support Windows 2000 in this release window, having been qualified on it shortly before the discussion. The recommended way to read this is:

1. WinCC on Windows 2000 — supported with the appropriate WinCC service pack.
2. WinAC Basis on Windows 2000 — supported.
3. WinAC RTX on Windows 2000 — not supported in this era; the RTX HAL is bound to Windows NT. RTX support for Windows 2000 is delivered in a later RTX/Windows version combination.

4. CP5613 Profibus Card Integration

The Profibus interface card is the I/O lifeline of the soft-PLC. Two Siemens cards are commonly cited in this era: CP5611 (lower cost, Windows-managed) and CP5613 (onboard processor, hardened for WinAC RTX).

For a WinAC RTX deployment the CP5613 is the right card for three reasons:

1. NT-fault isolation. The card's onboard processor continues Profibus master operation even if the Windows kernel becomes unresponsive. The control program reads fresh process image data on the next RTX cycle.
2. CPU offload. The host CPU is not servicing Profibus interrupts, which keeps the S7 OB1 cycle stable.
3. Direct RTX link. The card maps process data into memory accessible to the RTX subsystem, eliminating the Windows driver stack from the time-critical path.

For a WinAC Basis deployment, CP5611 is acceptable on Windows 2000. The determinism budget is already soft, and the host-CPU overhead of CP5611 fits within that budget for typical machine cycle times.

5. Migration from STEP 5 to STEP 7

The S5 → S7 conversion is not a 1:1 translation. Siemens provides the S5 to S7 Converter (a STEP 7 add-on) which translates a S5 program file (e.g., S5-DOS, *.S5D) into an S7 program source. The converter:

• Translates AW, OW, UW, UW word logic, timers, counters, and most standard blocks.
• Maps S5 data blocks (DB/DX) to S7 DBs.
• Emits a conversion log that lists every construct it could not convert automatically, with block number, network, and reason.

The source's "it is not fully compatible" is precise. The full migration workflow is:

1. Inventory the S5 program: blocks (OB, PB, FB, SB, DB), absolute addresses (I/Q/M/PI/PQ), and the I/O configuration. A 1:1 I/O map is essential because the Profibus DP slave addresses and the S7 process image must line up with the field wiring.
2. Run the converter in STEP 7 on a copy of the program. Review every entry in the conversion log. Each unconverted construct is a manual edit.
3. Resolve unsupported constructs. Common cases include: S5 floating-point formats, certain FB parameter passing patterns, direct byte access on word markers, and the S5 SU subtractor semantics on counter blocks. The remedy is to rewrite the affected network in S7 STL or LAD/SCL.
4. Remap I/O. S5 byte addresses (e.g., IB 0) do not always match S7 process image organization. Use HW Config to assign the Profibus DP slaves to the S7 process image at the correct byte offset, then update the program to use the new I/Q addresses.
5. Build and download to the WinAC station. WinAC consumes the same S7 block container that a hardware CPU would.
6. Dry-run with I/O forced. Before coupling to the machine, force outputs off and step the S7 program in test mode to verify scan order and timer behavior.

6. WinCC V5.1 Installation Prerequisites on Windows 2000

WinCC V5.1 SP1 is the release that qualified Windows 2000 Professional SP4 and Windows 2000 Server SP4. The prerequisites are documented in the Siemens installation guide and reiterated on the Siemens Support entry for WinCC V5.1 SP1 on Windows 2000 SP4. The required preconditions are:

1. Windows 2000 Professional SP4 or Windows 2000 Server SP4, with the latest Windows 2000 post-SP4 security rollup applied.
2. Internet Explorer 6.0 SP1 (WinCC V5.1 SP1's WebNavigator and online help depend on the IE6 runtime).
3. Microsoft Data Access (MDAC) 2.7 or higher (the SQL Server 2000 Desktop Engine bundled with WinCC V5.1 requires MDAC 2.7+).
4. Local administrator account for the installation user; the install cannot run from a roaming profile.
5. WinCC V5.1 SP1 installation media; prior WinCC V5.0 or V5.1 must be upgraded in place — uninstall is not required for SP1.
6. File system: NTFS with the WinCC project directory excluded from the indexer and from real-time AV scanning.
7. Screen resolution 1024 × 768 minimum; XGA (1024 × 768) is the project default.

For V6.0 and later projects, Windows 2000 is not in the supported OS list. The V5.0/V5.1 to V6.0 migration thread documents that projects authored in V5.0/V5.1 on Windows 2000 must be migrated to V6.x running on Windows XP Professional — Windows 2000 cannot host the V6.0 runtime.

The installation prerequisites thread for WinCC V5.1 further details that a clean Windows 2000 install with SP4 integrated is preferred over an in-place upgrade from Windows NT 4.0, because leftover NT service registrations can block the WinCC SQL Server instance from starting.

7. Registry and Security Configuration on Windows 2000

On Windows 2000 Professional, Windows 2000 Server, Windows XP Professional, and Windows Vista, WinCC uses a registry branch to enforce operator-input restrictions (e.g., disabling Ctrl-Alt-Del, Ctrl-Esc, and Alt-Tab for the operator console). If disabling these key combinations does not take effect, the fix is enforced at the registry level. The procedure is documented in the Siemens Support entry on key-combination disabling in WinCC:

1. Open the registry editor: Start > Run..., type regedit, press Enter.
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\SIEMENS\WinCC\WinLogon\Permissions.
3. Verify that the Permissions subkey exists and that the user accounts that run the WinCC runtime and the WinAC service have READ access. If the subkey is missing, recreate it as a REG_SZ value or as the appropriate subkey type per the WinCC installation default.
4. Reboot. The WinLogon key-combination hooks reload at logon; a registry edit alone will not retroactively apply to a logged-in WinCC runtime.

Related security configuration on Windows 2000:

8. Configuration Parameters and Engineering Workflow

The full commissioning sequence on a Windows 2000 industrial PC is:

1. Install Windows 2000 Professional SP4 with the latest rollup; integrate SP4 into the install media with update /s:C:\w2k_sp4 /integrates:C:\w2k_media (deployment) or install SP4 + rollup post-install.
2. Install IE6 SP1, MDAC 2.7+, and any required chipset/network drivers before installing WinCC.
3. Install the CP5613 (or CP5611) Profibus card; confirm the device appears in Device Manager without warnings. Install the Siemens Profibus card driver set shipped with WinAC.
4. Install STEP 7 (engineering).
5. Install WinAC Basis (or WinAC RTX on a Windows NT 4.0 station, if RTX is the choice).
6. Install WinCC V5.1 SP1.
7. Author or migrate the S7 program in STEP 7. Configure the WinAC station in HW Config to match the Profibus topology.
8. Download the S7 program to the WinAC station. Confirm the WinAC control engine is in RUN.
9. Author the WinCC project: tags mapped to the WinAC S7 symbols, screens, alarms, archives.
10. Activate the WinCC runtime. Verify tag updates from the WinAC process image.

A representative subset of parameters to capture in the project documentation:

9. Known Issues and Workarounds

10. Long-Term Platform Considerations

At the time the original question was asked, Windows 2000 was still in the active service-pack/hotfix release cycle. NT 4.0 was past that point. The Siemens engineer's recommendation — "use an OS that is beyond the term of frequent service pack and hotfix releases" — is correct in general, but it must be paired with the WinAC variant. If RTX is required, the OS choice is constrained to what RTX supports. If Basis is acceptable, Windows 2000 SP4 is a valid target until the project moves to a later WinCC version (V6.0+ on Windows XP Professional, or the modern SIMATIC WinCC Unified PC runtime on a current Windows or Linux platform).

For greenfield retrofits today, the modern equivalent is a TIA Portal-based architecture: S7-1500 software controller or a WinCC Unified runtime on a current Windows 10 IoT or Linux industrial PC, with Profinet instead of Profibus. The Windows 2000 + WinCC V5.1 SP1 + WinAC Basis/CP5613 architecture described here remains the correct answer for brownfield retrofits that must preserve the field wiring and I/O topology of an existing S5 line.

11. Verification Checklist

After commissioning, verify the following to confirm the retrofit is stable:

1. WinAC station reports RUN in the WinCC diagnostics view; OB1 cycle time matches the configured value ±5%.
2. Profibus diagnostics show zero slave failures over a 24-hour soak.
3. WinCC archives 24 hours of data without database growth anomalies.
4. Operator can log in, navigate, and acknowledge alarms; Ctrl-Alt-Del is suppressed at the console (verified by attempting the combination and observing no task switcher).
5. A simulated S5-style fault path (e.g., loss of an input that the S5 program treated as a fault) is exercised; the WinAC logic responds within the original S5 cycle budget.
6. A controlled Windows 2000 restart recovers WinAC into RUN automatically; the WinCC runtime re-activates with the operator logged in.
7. The S5-to-S7 conversion log is filed in the project documentation, with each unconverted construct annotated with the manual edit applied.

FAQ