Application Example: Standalone Pages - WinCC OA Workspace

Standalone workspace that delivers a collection of demo standalone pages for WinCC OA WebUI.

What it does

Five self-contained HMI demo pages, each registered as an independent route:

| Page | Route | Description | | -------------- | ----------------- | ---------------------------------------------------------------------------------------- | | SCADA Demo | /scada-demo | Water treatment process - two-tank flow diagram with live pump/valve controls | | HVAC Control | /hvac-control | Air handling unit - SVG diagram with temperature monitoring and fan/coil controls | | Energy Monitor | /energy-monitor | Power distribution - single-line diagram with circuit breaker controls and trend chart | | Plant Map | /plant-map | Facility monitoring - pan/zoom map with 100 live datapoint markers | | Bottle Line | /bottle-line | Production line showcase - animated conveyor, KPI strip, alarm panel, and history viewer |

All live data is streamed from WinCC OA via OaRxJsApi.

Installation

The package supports two install layouts. The postinstall script auto-detects which one applies.

Option A: Directly into a WinCC OA project

cd {OA-PROJECT}/data/WebUI
npm install @wincc-oa/ae-standalone-pages --omit=peer --omit=dev --foreground-scripts

About --foreground-scripts - npm 8+ runs postinstall scripts in a buffered child process and suppresses their stdout unless this flag is passed. The standalone-pages package only registers menu entries (no extra setup steps), so you will probably not lose anything by omitting it - but the flag is harmless and matches the convention used by the other application examples (ae-tunnel-demo, ae-central-asset-management) where the postinstall has follow-up actions to print.

Why --omit=peer --omit=dev here - this package has no runtime dependencies. Everything it imports (lit, rxjs, tsyringe, @siemens/ix*, @etm-professional-control/oa-rx-js-api, all @wincc-oa/wui-* libs) is a peerDependency and is already served at runtime by the WebComponent Dashboard's import map. Inside an OA project the build is never re-run, so the peer + dev packages would just sit unused (~80 MB of duplicates). The flags keep node_modules/ to just this package.

The pages work without the flags too - npm 8+ will simply install the peer deps that the dashboard then ignores.

The postinstall merges the five menu entries into ../dashboard-wc/menuconfig.json, rewriting each module URL to /data/WebUI/node_modules/@wincc-oa/ae-standalone-pages/dist/pages/<page>.js so bundles stay in node_modules and are served from there. No files are copied.

If ../dashboard-wc/menuconfig.json is missing, the script prints a hint and exits without changes. Create the directory and copy the default menuconfig.json from your WinCC OA installation, then re-run with npm rebuild @wincc-oa/ae-standalone-pages.

Option B: Into a Vite-host workspace

npm install @wincc-oa/ae-standalone-pages

The postinstall:

1. Merges the five menu entries into apps/dashboard-wc/config/menuconfig.jsonc.
2. Creates one shim per page in libs/default-components/src/lib/standalone-pages/ (scada-demo.ts, hvac-control.ts, energy-monitor.ts, plant-map.ts, bottle-line.ts) - each is a single side-effect import that lets Vite include the page bundle as a build entry.

Page registration

The package includes a wui-page.json manifest. When deployed, WinCC OA WebUI registers:

| Property | SCADA Demo | HVAC Control | Energy Monitor | Plant Map | Bottle Line | | ---------- | ------------------ | -------------------- | ---------------------- | ----------------- | ------------------- | | Route | /scada-demo | /hvac-control | /energy-monitor | /plant-map | /bottle-line | | Component | <wui-scada-demo> | <wui-hvac-control> | <wui-energy-monitor> | <wui-plant-map> | <wui-bottle-line> | | Permission | connected | connected | connected | connected | connected |