Core Concepts

Read this page once. Then build. It defines the product structure, the main objects, and the data path.

What You Need to Understand First

If you only remember six things on day 1, remember these:

1. Editor is for engineering. Vision is for runtime.
2. A project contains your tags, views, alarms, scripts, and settings.
3. A channel defines device communication.
4. A tag is one data point, such as temperature, pressure, or motor state.
5. A view is the screen an operator sees.
6. Historian and Data Management solve different storage problems.

Product Structure

AI SCADA uses a client-service-data model:

Layer	Component	What it does
Client	Editor	Create and edit projects, tags, views, alarms, scripts, and tests
Client	Vision	Run a finished project for operators and site users
Service	Host	Handles project services, users, alarms, processing, and APIs
Service	SIOT	Handles device communication, tag acquisition, and real-time control
Data	MySQL	Stores structured data such as project configuration, alarms, logs, and business tables
Data	InfluxDB	Stores time-series history for tags and trends

Engineering Objects You Will Use in the First Project

Project

A project is the top-level container of your application. In practice, one project usually represents one machine, line, station, cell, utility system, or customer solution.

A project can include:

• tags and communication settings
• views and operator screens
• alarm rules
• historian and data settings
• scripts and automation logic
• users, roles, and permissions

Channel

A channel defines how AI SCADA talks to a device or tag source.

Typical channel settings include:

• protocol driver
• IP address or endpoint
• port or station parameters
• timeout and scan behavior

Examples:

• Modbus TCP channel for a controller
• S7 channel for a Siemens PLC
• internal or memory channel for testing without a device

Tag Group

A tag group is an engineering container inside a channel. Use it to organize tags by function, equipment area, or process step.

Examples:

• Station1
• TemperatureSensors
• MotorStatus

Tag

A tag is one readable or writable data point.

Examples:

• Temperature
• Pressure
• MotorRunning
• TargetSpeed

Tags can be:

• external tags connected to a real device
• internal tags used for testing, logic, calculations, and simulated values

To learn the full tag model, see Understanding Tags.

View

A view is a visual screen used for monitoring, operation, or analysis.

Typical first views include:

• a machine overview page
• a station status page
• a trend and KPI dashboard
• an alarm summary page

To learn the interface layout, see Understanding Views.

Alarm

An alarm monitors a condition and creates an event when that condition becomes true.

Simple example:

• tag: Temperature
• condition: > 80
• result: show an alarm to the operator and record it

To continue, see Creating Alarms.

Data Table

A data table is a custom business table in Data Management.

Use it when you need row-based records such as:

• one row for each completed part
• one row for each shift summary
• one row when a machine state changes
• one row when an alarm or quality event happens

Each table is built from:

• fields: the columns you want to store
• sources: each field links to a tag or uses a formula
• trigger rules: define when a new row should be recorded

Typical trigger styles include:

• a variable expression becoming true
• a state or field change
• a schedule
• an alarm event

After data is recorded, bind the table to a Table component or a Chart component in a view.

To continue, see Understanding Data Management.

How Data Moves Through the System

The first project is easier when you understand the data path:

1. A device sends data through a protocol such as Modbus, S7, or OPC UA.
2. SIOT reads the value and updates the tag.
3. Host uses that value for runtime logic, alarms, and services.
4. Editor or Vision displays the value in a view.
5. If configured, the value is archived to Historian or recorded into a Data Management table.

That same path is why troubleshooting usually starts in this order:

1. channel communication
2. tag address and data type
3. service status
4. view-to-tag binding
5. history or alarm configuration

Development Mode vs Runtime Mode

In Editor

Use Editor to:

• create a project
• configure channels and tags
• build views
• bind tags to view components
• configure alarms and storage
• test before deployment

In Vision

Use Vision to:

• open a finished project
• run the operator interface
• monitor live data
• handle alarms and user actions

If you are new to the product, keep this rule in mind:

• If you are building, stay in Editor.
• If you are operating, stay in Vision.

Historian vs Data Management

New users often confuse these two modules. Use this rule:

Use case	Choose	Why
High-frequency tag history, trend charts, time ranges	Historian	Use it when the main question is "how did this tag change over time?"
Production records, traceability, custom tables, trigger-based event records, chart-driven dashboards	Data Management	Use it when the main question is "what business event should be recorded as a row?"

If your first goal is to show a trend chart for tag values, start with Historian.
If your first goal is to store production records, orders, inspection results, or state-change snapshots, use Data Management.

To learn more:

• Configuring Historian
• Understanding Data Management

If You Do Not Have a Device Yet

You can still complete the first project.

Recommended for first-time users:

• start with internal tags first
• use Static Simulation only when you want to keep an external-channel structure and PLC-style addressing

Use one of these options:

• create internal tags and use them as test values
• create an external device channel and tags, then enable Static Simulation in the channel advanced settings
• start with a customer tag list even if the hardware is not connected yet

This is the recommended order for a zero-to-one trial:

1. create a blank project
2. start with internal tags, or choose an external channel with Static Simulation if you need the final channel structure from day 1
3. build a screen with those tags
4. replace simulated values with real device communication later

How to Adapt the Same Workflow to Your Scenario

The same engineering pattern works across industries. Only the inputs change.

Scenario	Start with	First deliverable
OEM machine	one controller, one machine tag list, one overview page	status, setpoints, alarms, basic trend
System integration	one line section, one naming standard, one customer tag map	line view, alarm summary, historian baseline
Utility / process	one pump, tank, valve, or skid	running page, process values, alarms, history
Factory dashboard	one area or workshop KPI set	overview dashboard with trends and alarm summary

What usually changes per customer:

• protocol and connection settings
• naming rules
• tag list
• alarm limits and categories
• required pages and navigation
• storage and integration needs

Next Step

Continue in this order:

1. Download and Install
2. First Launch and Workspace Tour
3. Build Your Project