HQControl
HQControl is the site runtime platform. It loads screen packages, connects devices and tags, and manages menus, permissions, alarms, trends, scripts, APIs, licensing, and operations. When a project needs reports, dashboards, or diagnostics, the custom-page SDK extends pages within controlled scope.
It receives screen assets exported from Designer and brings them into site operation. Data, permissions, alarms, trends, and operation records are managed by the platform; availability, APIs, and scripts are configured by project scope.
Use it when exported screens need to run with tags, access, alarms, alarm sound, trends, custom pages, and scripts.
Centralizes modules, device data, users, licensing, monitoring, federation, and redundancy.
Screen source packages are created through the PowerPoint plugin workflow.
Product Usage Path
Confirm where the product sits in the delivery path, then continue to installation, configuration, extension, and acceptance details.
Install the runtime platform and confirm the service state.
Bring in screens, tags, menus, permissions, alarms, alarm sound, and trends.
Configure menus, permissions, alarms, alarm sound, trends, scripts, APIs, and runtime monitoring.
Use the custom-page SDK when reports or dashboards are needed, while continuing to manage licensing, federation, redundancy, and maintenance.
What the platform carries
HQControl is the runtime and delivery layer for screen assets, tag master data, menus, i18n, permissions, interfaces, and operations.
Screen assets, IO, alarm, alarm sound, trend, event, and script modules run inside the platform.
Access control, licensing, module state, script entries, IO APIs, and custom-page extensions are managed centrally.
Installation, runtime, licensing, deployment, federation, and redundancy land in the platform layer.
Runtime platform capabilities
HQControl first carries site runtime, data governance, and delivery operations. The custom-page SDK then gives project pages controlled data access on top of that platform.
Scripts, IO, alarms, alarm sound, trends, federation, and redundancy are managed by HQControl.
Built-in paths cover Siemens S7, OPC UA, Modbus TCP, and internal variables. Collected values are consolidated into a single real-time data layer for screens, alarms, alarm sound, trends, APIs, and scripts.
Configuration center, access control, module state, and licensing live in one platform.
Scripts, IO, alarms, alarm sound, trends, and third-party integration can evolve by module.
Integration Script provides ReadTag, ReadTags, and WriteTag for HQControl IO, bundles common HTTP, database, and MQTT packages, and can use project-installed third-party Python packages or local package folders for automation.
Third-party systems read collected IO through IO State API HTTP GET and WebSocket subscriptions. MQTT integration belongs in Integration Script.
Custom HTML pages run inside a sandbox iframe and call HQVISU_CUSTOM_PAGE.ready() for controlled APIs. Within the declared page scope, they can read, subscribe, write tags, and query history or alarm data.
The SDK provides a data bridge, language API, and renderTable / bindJsonTable helpers. Projects can build shift reports, energy dashboards, equipment diagnostics, or customer-specific pages instead of relying on a fixed built-in report module.
Install, license, deploy, run, federate, and maintain in one production structure.
PC console, field popups, trends, and custom-page extensions
HQControl first carries runtime configuration, system state, field operation, and trend review. Custom pages are controlled extensions for project reports, dashboards, or diagnostics.
For control rooms, servers, and maintenance PCs to review module state, service state, and runtime information.
View large image
For field inspection, device details, and popup operation with a touch-oriented layout.
View large image
For trend browsing, historical comparison, and runtime-state review so operators can locate data movement quickly.
View large image
Illustrative example of a project HTML page combining declared tags, history, alarms, and table helpers. It is not a screenshot of a built-in report module.
View large image
Custom-page SDK for project reports and dedicated views
The SDK is for custom HTML pages deployed in HQControl runtime. It provides controlled data APIs and page helpers while the project implements its own report, dashboard, diagnostic, or customer-specific view.
The example shows how a custom page can combine realtime tags, history trends, alarm summaries, and table data. It explains possible SDK page forms and is not a fixed built-in report module.
Custom pages run inside a sandbox iframe and do not directly inherit the main application login environment.
The page declares readableTags and writableTags through JSON configuration, and the host mints a page capability from that declaration.
The SDK exposes realtime values, subscriptions, writes, history, alarms, language, and table helpers without fixing the report UI as a platform module.
From HTML page to runtime
Declare scope first, wait for SDK readiness, then read values, subscribe changes, query history, or query alarms for the business view.
Place the hqvisu-custom-page JSON block in the HTML and list readable and writable tags.
Call HQVISU_CUSTOM_PAGE.ready() before accessing runtime data.
Use read, subscribe, history.query, and alarms.* for the data the page needs.
Draw the project report, dashboard, or diagnostic view, using renderTable when a table helper is enough.
Declare page tag access
The host only grants the tag capabilities declared for the page.
<script type="application/json" id="hqvisu-custom-page">
{
"readableTags": ["Line1.Temperature", "Line1.RunState"],
"writableTags": ["Line1.Setpoint"]
}
</script> Combine realtime, history, and alarms
The report or dashboard UI is project code; data comes through controlled SDK APIs.
const api = await HQVISU_CUSTOM_PAGE.ready();
const temp = api.readNumber("Line1.Temperature", 0);
const trend = await api.history.query({
tags: ["Line1.Temperature"],
start,
end,
interval: "1h",
aggregate: "avg"
});
const alarms = await api.alarms.getActive();
api.renderTable("#alarm-table", alarms.items || []); Read historical trends and key tags for a shift window, then format output, energy, and quality summaries for the project.
Organize live values, alarm summary, quality state, and external business context into a customer-specific page.
Aggregate status bits, alarms, trends, and maintenance notes around a single device.
Platforms and delivery forms
HQControl is the production runtime and delivery layer.
Architecture
HQControl is based on C/S architecture and carries scripts, IO, alarms, alarm sound, trends, federation, redundancy, and governance.
Supported platforms
Windows and Linux deployment are covered; cloud servers use the same Linux package.
Licensing and updates
HQControl is licensed as one platform: the license supports update packages, platform features, and later platform extensions without charging each module separately. HQ VISU Designer and HQControl remain separate product licenses.
Supported device connections
Built-in connections include Siemens S7 absolute addressing, S7 symbolic / OPC UA, standalone OPC UA, Modbus TCP, and internal variables. S7 absolute commonly uses 102 with Rack/Slot; OPC UA commonly uses opc.tcp://...:4840; Modbus TCP commonly uses 502.
Supported script abilities
System scripts run as server-side Python. Integration Script provides ReadTag, ReadTags, and WriteTag. Production packages include requests, psycopg, pymysql, pyodbc, paho-mqtt, websocket-client, and cryptography; projects can also install third-party Python packages or configure local package paths.
Integration
Third-party reads use IO State API HTTP GET or WebSocket. MQTT publishing, MES / ERP calls, SQL jobs, and event automation are implemented through Integration Script.
Custom-page SDK boundary
A custom page declares readableTags and writableTags in its HTML configuration. History queries, alarm queries, and subscriptions are limited to readable tags, while writes also require declared write scope and user permission.
Availability
Federation and redundancy help handle multi-site coordination and node failover.
Application scenarios
HQControl acts as the runtime platform when a project moves into field operation, device integration, alarm, alarm sound, trend management, custom pages, access control, and production delivery.
From screen package to site runtime
Bring prepared screens, device data, and tag master data into a deployable runtime system.
Site deployment and lifecycle maintenance
Support installation, module configuration, federation, redundancy, licensing, and operations maintenance.
Project-specific runtime pages
When a site needs shift reports, energy summaries, device diagnostics, or customer dashboards, custom-page SDK can be used within authorized data scope.
Continue
Continue to runtime entries, configuration, delivery, demo, and downloads.