Warum Data2Unified bei VBScript scheitert – und wie man Skripte sauber migriert

Mit dem schrittweisen Auslaufen der bewährten SIMATIC WinCC Comfort Panels und des zugrundeliegenden Betriebssystems Windows CE stehen Maschinenbauer und Automatisierer vor einer der größten Paradigmenwechsel der letzten zwei Jahrzehnte: Der Umstieg auf SIMATIC WinCC Unified und das Linux-basierte Industrial OS.

Siemens stellt für diesen Schritt das Migrationstool Data2Unified bereit. Während statische Bildschirmelemente, Variablenanbindungen und Textlisten weitgehend automatisiert konvertiert werden, scheitert das Tool regelmäßig an einer entscheidenden Hürde: VBScript.

In diesem Artikel analysieren wir, warum eine 1:1-Übersetzung von VBScript nach JavaScript architektonisch unmöglich ist und wie Sie typische VBScript-Muster in robuste, nicht-blockierende TypeScript/JavaScript-Architekturen überführen.

---

1. Das Problem: Zwei Welten – Zwei Concurrency-Modelle

Die Windows CE & VBScript-Vergangenheit

Unter WinCC Comfort (Windows CE / WEC 2013) lief VBScript in dedizierten Worker-Threads des Runtime-Kerns. Wenn ein Entwickler eine synchrone Warteschleife programmierte, wurde lediglich dieser spezifische Thread blockiert:

' Typisches Alt-Muster in WinCC Comfort (VBScript)
Sub TriggerMotorSequence()
    SmartTags("DB_Motor.CMD_Start") = True
    
    ' Synchrone Blockadeschleife bis Rückmeldung ansteht:
    Do While SmartTags("DB_Motor.STAT_Running") = False
        ' Wartet synchron - blockiert nur den Script-Thread
    Loop
    
    SmartTags("DB_Feeder.CMD_Start") = True
End Sub

Für den Bediener blieb die Benutzeroberfläche meist bedienbar, weil der Grafik-Thread separat lief.

Die WinCC Unified Realität: V8 Event-Loop auf Embedded Linux

WinCC Unified basiert auf einer modernen Web-Architektur. Das Panel rendert die HMI in einer Chromium-Instanz, und Skripte werden von der V8-JavaScript-Engine ausgeführt.

Die V8-Engine arbeitet mit einem Single-Threaded Event Loop. Wenn Sie in JavaScript eine synchrone Schleife ausführen:

// FATALER FEHLER auf WinCC Unified:
function triggerMotorSequence() {
    Tags("DB_Motor.CMD_Start").Write(true);
    
    // TÖDLICH: Friert die gesamte GUI und Runtime ein!
    while (!Tags("DB_Motor.STAT_Running").Read()) {
        // Blockiert den Single Thread des V8 Event-Loops!
    }
}

Die Konsequenz:

1. Der Render-Thread blockiert sofort.
2. Touch-Eingaben werden nicht mehr registriert.
3. Der Linux Watchdog meldet nach wenigen Sekunden einen Panel-Freeze oder startet den Chromium-Container neu.

---

2. Der architektonische Lösungsansatz: Asynchrone Event-Driven Migration

In WinCC Unified muss jede Interaktion mit SPS-Variablen (Tags) asynchron oder über Event-Abonnements (Subscriptions) gedacht werden.

Muster 1: Von Polling zu Tag-Subscriptions

Statt auf eine Variable aktiv in einer Schleife zu warten, abonnieren wir die Wertänderung des S7-Datenbausteins über das Tag-Set oder direkte Callback-Mechanismen:

/**
 * Asynchrone Schrittkette mit Timeout-Überwachung
 */
async function startMotorSequenceAsync(timeoutMs = 5000): Promise<boolean> {
    const motorStartTag = Tags("DB_Motor.CMD_Start");
    const motorRunningTag = Tags("DB_Motor.STAT_Running");
    const feederStartTag = Tags("DB_Feeder.CMD_Start");

    // 1. Befehl absetzen
    await motorStartTag.Write(true);

    // 2. Promise-basierte Wartebedingung ohne Loop-Blockade
    return new Promise((resolve, reject) => {
        const timer = setTimeout(() => {
            subscription.Unsubscribe();
            reject(new Error("Timeout: Motor meldet keine Betriebsbereitschaft!"));
        }, timeoutMs);

        const subscription = motorRunningTag.CreateSubscription();
        subscription.OnDataChanged = (tagValue) => {
            if (tagValue.Value === true) {
                clearTimeout(timer);
                subscription.Unsubscribe();
                
                // Folgeschritt triggern
                feederStartTag.Write(true);
                resolve(true);
            }
        };
    });
}

---

3. Vergleichstabelle: VBScript vs. WinCC Unified JavaScript

Anforderung	WinCC Comfort (VBScript)	WinCC Unified (JavaScript ES2020+)
Architektur	Multi-threaded Windows Native	Single-threaded V8 Event-Loop
Variablenzugriff	SmartTags("Name") (synchron)	Tags("Name").Read() / .WriteAsync()
Wartezeiten	Sleep(ms) (blockierend)	await new Promise(r => setTimeout(r, ms))
Schleifen & Polling	Do While ... Loop	Tag Subscriptions (OnDataChanged)
Fehlerbehandlung	On Error Resume Next	try { ... } catch (err) { ... }
Typisierung	Keine (dynamische Variants)	TypeScript Interfaces via TIA Openness

---

4. Best Practices für Migrationsteams

1. Keine Business-Logik in der HMI: Schrittketten und Interlocks gehören in die S7-1500 (Graph7, SCL), nicht in HMI-Skripte. HMI-Skripte sollten ausschließlich für Visualisierungszustände, dynamische Einblendungen und Custom Web Controls genutzt werden.
2. Asynchrone Methoden konsequent einsetzen: Nutzen Sie niemals synchrone Dateizugriffe oder blockierende Web-Requests.
3. Typisierung erzwingen: Nutzen Sie TypeScript im Build-Prozess Ihrer Custom Web Controls, um Zugriffsfehler auf Datenbaustein-Eigenschaften bereits beim Kompilieren abzufangen.

---

Fazit: Die Chance hinter dem Paradigmenwechsel

Data2Unified kann Skripte nicht magisch in asynchrone Architekturen verwandeln. Doch der Umstieg von VBScript auf JavaScript/TypeScript eröffnet gewaltige Potenziale: Sie erhalten Zugriff auf das gesamte moderne Web-Ökosystem, modulare Komponenten, Canvas-Rendering und standardisierte Testwerkzeuge.

Benötigen Sie Unterstützung bei der Modernisierung Ihrer HMI-Architektur oder der Refaktorisierung kritischer Skripte? Kontaktieren Sie Boris Kotov direkt.