Skip to content
Back Industrial HMI / SCADA Runtime

Mingcedar

Mingcedar is an industrial HMI / SCADA platform that brings device data into a shared Tag model for screens, alarms, trends, calculations, and scripts. It connects independent Sites by capability and device scope, with collection-source and runtime-status checks.

Configure devices and screens in the browser, inspect data quality, alarms, and trends, then connect the runtime capabilities needed from other Sites.

Multi-protocol acquisition S7 / S7Plus · OPC UA · Modbus TCP · TCP/IP
Federated site aggregation Remote runtime data by capability and device scope
Collection ownership and status Applied configuration · responsible node · Tag quality
Devices and TagsScreens, alarms, and trendsSite collaboration and collection diagnostics
Connected data

One data model, across the runtime.

Connect field devices, organize their Tags, and use collected values in screens, alarms, history and project logic.

Field devices

Protocol settings and device addresses

  • Siemens S7
  • S7Plus
  • OPC UA
  • Modbus TCP
  • TCP/IP

Collected Tag state

Value · Quality · Timestamp

  • Operator screens
  • Alarms & trends
  • Calculated Tags
  • Python projects
  • IO sharing API
  • Custom-page SDK

Reuse collected state

Screens, alarms and trends consume collected values without polling each PLC independently.

Keep the source visible

Device references and data quality accompany the value through the runtime.

Control each write

Tag write settings, user permissions and the target protocol determine which operations are allowed.

Explore devices and Tags

From one site to connected operations

Keep each site autonomous. Bring remote screens, IO, alarms and trends into one workspace as your operation grows.

Site federation Deployment relationships

Site A

Local devices & services

Site B

Local devices & services

Select remote sources

  • Screens
  • IO
  • Alarms
  • Trends

Aggregated workspace

One view across your sites

Choose sources by capability. Define the device scope.

Collector redundancy

Same runtime unit · Shared PostgreSQL / Redis

Active owner Eligible standby

An eligible standby in the same runtime unit takes over

Lease & version fencing

One active collector per PLC definition

Federation connects independent sites. Collector takeover is scoped to one runtime unit; see the guide for deployment requirements.

Explore federation & redundancy

Product capabilities

Connect devices, run screens, coordinate Sites, and extend project logic. Tag data retains its source, quality, and timestamp.

Connect devices and import Tags

Connect Siemens S7, S7Plus, OPC UA, Modbus TCP, configurable-frame TCP/IP, and internal values. Import Tags in CSV, JSON, or NDJSON with a preview; supported points allow controlled writes.

Build screens and site navigation

Publish Mingcedar Studio screen packages or custom HTML pages, with menus, popups, video channels, and multilingual text. Runtime pages use a separate origin and read data within their declared scope.

Inspect Tag quality and calculate values

View device connection, collection progress, Tag freshness, and quality separately. Calculated tags build read-only numeric or Boolean results from collected local values and can feed screens, alarms, and trends once published.

Configure alarms and follow their status

Detect exceptions with threshold, quality, deviation, rate-of-change, deadband, and delay rules; acknowledge, shelve, review history, and configure alert sounds. Set category number, name, color, and execution priority separately. Non-GOOD readings do not clear existing value alarms.

Record and compare trends

Record Tags on change, on a cycle, or both. Align historical periods by elapsed time, or compare samples received in the current session within the last 15 minutes. Use lines, steps, or data tables, with horizontal or vertical comparison layouts. Export CSV or chart PNG; invalid samples remain gaps.

Aggregate Sites by scope

Select remote screens, collection, alarms and trends independently, and choose a device scope for remote collection. Tags retain their source identity. Remote alarms over ordinary LAN connections are read-only; sign in to the source to acknowledge or shelve.

Inspect collection ownership and recovery

Inspect configuration application, PLC connectivity, collection status and the responsible node in Device details. Verify quality, timestamps and values after recovery. One runtime unit coordinates ownership of its PLC definitions; independent Sites do not automatically exclude each other.

Extend project logic with Python

Organize scripts and shared functions under scripts/ and common/, and distribute reusable code as a Wheel across projects. Projects include common bundled modules and accept offline Wheels or Wheel ZIP bundles, with dependency versions, updates, and removals managed per project.

IO sharing: connect external applications

IO State API V2 lets external applications read collected state and receive snapshots and incremental updates over WebSocket. Profiles organize shared signals; Access Keys authorize IO domains, devices, or Tags. Data retains quality and timestamps. The API provides reads and subscriptions only.

Custom-page SDK: build dedicated interfaces

Combine live Tags, historical trends, and alarm queries in HTML, JavaScript, or built Vue pages. The SDK provides typed reads and writes, navigation, device popups, and language resources, within page declarations and current user permissions.

Manage user roles and operation permissions

Assign roles with separate screen-access and operation permissions. Tag writes also require page scope, Tag control permission, and runtime checks, with confirmation according to policy.

Diagnose runtime issues and trace events

System Status brings together services, device connections, continuously collected Tags, and CPU, memory, and disk use. Filter and export event records by time, source, and type. Script Status adds an overview and worker details, with execution results available in Records.

Compare past changes. Follow live operation.

Choose two Tag groups to compare historical periods or follow live changes on one timeline. Compare changes in charts, inspect values, timestamps and quality in tables, and export CSV data or PNG charts.

Historical comparison

Read the comparison guide

Choose Tags and periods independently for two groups. Compare changes by elapsed time, with linked zoom and each period’s dates visible.

Groups A and B align by elapsed time while retaining each period’s dates. Curves use example data.Click to enlarge

Realtime comparison

Read the comparison guide

Follow samples received during the current session in a rolling 15-minute window on one timeline. Pause to inspect a change, then resume live updates.

Both groups share one time window and can be paused for inspection. Curves use example data.Click to enlarge

Choose how to read the data

Use side-by-side or stacked layouts, linear or step lines, or a data table to inspect values, timestamps and quality. Export data as CSV or charts as PNG.

Explore views and exports

Rules for the process. Context for the data.

  1. Alarms retain their context

    Poor-quality readings hold the existing state of value alarms. Separate quality rules can identify unavailable data.

  2. Tune rules to the process

    Configure thresholds, deviation or rate of change, with deadband and delay. Category numbers and execution priority are configured separately.

  3. Review change over time

    Choose Tags and time ranges independently for historical comparison, with side-by-side or stacked panels. Inspect line or step charts and data tables, then export CSV or PNG.

Explore alarm configuration
Alarm rule editor · click to enlarge

Across devices

At the desk. On the floor.

Review the whole system on desktop, carry inspections onto a tablet, and check services on a phone. The same runtime information, in your browser.

01 Desktop 1440 × 1100
02 Tablet 820 × 1180
03 Mobile 390 × 844

Click an interface to enlarge it; click the image again to close.

IO State API V2

Share IO state with external applications

Give each client scoped access to collected state, with on-demand reads and continuous updates for connected applications.

Collected IO state

Value · Quality · Timestamp

Scoped authorization

Profile · Access Key

External applications

HTTPS reads · WSS subscriptions

Choose what to share

Publish signal sets as Profiles. Assign each client an Access Key with access limited by IO domain, device or Tag.

Read current state

Read exact signals by stable SignalRef. Quality and its reason accompany each result; available state includes value, type and timestamps.

Follow state changes

Use a single-use Ticket to start a secure WebSocket subscription: a complete snapshot followed by incremental updates and heartbeats.

Extend the logic. Shape the interface.

Use Python for project logic and external services. Connect custom pages to live values, history and alarms through the page SDK.

Python projects

Reuse shared functions, manage dependencies per project, and inspect execution results and errors.

Project code

scripts/main.py common/quality.py

Entry points & shared functions

Project dependencies

Standard library Bundled modules & offline Wheels

Preview dependencies, install per project

Run on
  • A schedule
  • Tag changes
  • Signed HTTP requests
Execute project logicCPython 3.13
  • Return values
  • Output & errors
  • Execution records

Custom-page SDK

Build project dashboards, reports and diagnostic views with HTML, JavaScript or built Vue pages, connected to the host’s runtime data.

HTML · JavaScript · ESM

Declare the page scope

Identify the data and operations used by this page.

Host authorization

Apply page scope and current user permissions.

  • Live reads & subscriptions
  • Historical queries
  • Alarm queries

Use the current user session, navigation, device popups and shared language resources.

Typed reads and controlled writes

ReadTag / WriteTag methods support typed data and bit operations. Writes are checked against page scope, user permissions and Tag control rules, with confirmation by policy.

Pages run on a separate Screen Origin. The host provides scoped capabilities without exposing administrative credentials.

From screen package to site acceptance

Four steps establish a site runtime that is operable, traceable, and maintainable after handover.

01 Deployment and services

Select the release package and configure the runtime unit, dependencies, certificates, and license.

02 Devices and data

Connect devices, configure Tags, and verify applied configuration, collection, and quality.

03 Runtime and integration

Configure alarms, trends, screens, media, access, and required Python projects and APIs.

04 Acceptance and maintenance

Validate the target platform, load, and recovery procedures, retaining version and handover records.

Deployment and operation

Review the runtime unit, deployment platforms, and maintenance needs. Consult the release notes for supported platform and driver combinations.

Five runtime services

Web/App, IO, Alarm, Trend, and Script run separately and share the unit's data and configuration. System Status shows the health of each service.

Platforms and installers

Windows and Linux installers and a Linux container deployment are available. Check the current release package for target architecture, protocol drivers, and Python environment.

Plan capacity against field load

Plan resources and operating headroom against active collection points, PLC requests, history writes and client subscriptions, then check the load in the target environment.

Site and deployment limits

Multiple PCs can host independent Sites and share capabilities through federation. Dedicated IO nodes use PostgreSQL and Redis on the same machine. Standard installers do not support connecting them to another PC’s database for cross-machine primary/standby acquisition.

Versions and backups

Retain the database, configuration, screen assets, Python source and dependencies, media settings, and version records for project recovery.

Runtime workflows

Bring screens, Site collaboration, and project extensions into one flow around device data.

Device data in runtime screens

Screens display device and process state. Alarms and trends reuse collected Tags, with permissions controlling writes to supported points.

Sites collaborate by scope

View remote data by capability and device scope while each Site retains its own devices and runtime responsibilities.

Extend project logic and pages

Python runs project tasks, read-only APIs share authorized state, and the custom-page SDK supports reports and device diagnostics.

Continue

Continue to runtime models, configuration procedures, deployment requirements, and project acceptance.

Click the image again or press Esc to close