lets deep dive for this lecture slides. i want to (2).
md 2026-03-27
Slide 1: What is SCADA?
SCADA stands for Supervisory Control and Data Acquisition. It is a software-based system that allows
engineers and operators to monitor and control industrial processes from a central location — remotely and
in real-time.
Why does it exist? Industries like power grids, water treatment, oil pipelines, and manufacturing span vast
geographic areas. A human cannot physically walk to each pump, valve, or sensor. SCADA brings all that data
and control capability into one screen.
What it does:
Data Acquisition → Collects data from sensors (temperature, pressure, level, flow)
Supervisory Control → Sends commands back to actuators (open valve, trip a breaker)
Alarming → Alerts operators when something is out of range
Trending/Logging → Stores historical data for analysis
Slide 2: Typical Control Room — Legacy vs. New
The slides contrast the legacy control room with the modern control room to show how drastically the
industry has evolved.
Legacy Control Room:
Rows of physical instruments: analog meters, strip chart recorders, knobs, switches
Each instrument was hardwired to a single field device
An operator had to physically read dials and manually operate switches
No centralized data; no remote capability
Very inflexible — changing control logic required rewiring
Modern (New) Control Room:
Large screen displays showing live process diagrams (mimics/synoptics)
Operators interact via keyboard/mouse with a HMI (Human-Machine Interface)
One operator can monitor hundreds of parameters simultaneously
Alarm management, trend views, and historical data on one platform
Remote operation possible — a plant 100 km away can be controlled from a central dispatch center
The key transition: From hardware-defined control rooms to software-defined ones.
Slide 3: SCADA/HMI — Communicating with the
Human Operator
1 / 14
lets deep dive for this lecture slides. i want to (2).md 2026-03-27
HMI (Human-Machine Interface) is the graphical front-end through which a human operator interacts with
the system. It is the "face" of SCADA.
How it works:
Field data (sensor readings) flows from the field → RTU/PLC → communication network → SCADA server
→ HMI display
The operator sees a real-time graphical representation of the process (e.g., a tank filling up, a valve
opening)
If the operator clicks "OPEN VALVE," the HMI sends the command back through the same chain to the
actual valve actuator
Signal flow (simplified):
Sensor → Electrical Signal → RTU/PLC → Protocol → SCADA Server → HMI (operator
sees it)
Operator command → HMI → SCADA Server → Protocol → RTU/PLC → Actuator
(valve/motor)
Why HMI is critical: Without it, SCADA is just data — HMI gives operators situational awareness and a
mechanism to intervene.
Slide 4: Industrial Control Systems — Layers of
Automation
This is one of the most important conceptual slides. The Automation Pyramid (also called the ISA-95 model)
defines the hierarchical layers of industrial control.
From bottom to top:
Layer Name What Happens Here Example Protocols
Level Analog (4–20 mA, 0–10V),
Equipment/Field Physical process — sensors and actuators
0 digital I/O
Level Direct control, local automation, fast loop SPI/I2C, Modbus, CAN
PLC/HMI
1 control bus
Level Supervisory control, remote monitoring, OPC UA, Modbus TCP,
SCADA
2 dispatching DNP3
Level Manufacturing Execution System — production
MES OPC UA, SQL, APIs
3 scheduling
Level Enterprise Resource Planning (e.g., SAP) —
ERP APIs, SQL
4 business management
2 / 14
lets deep dive for this lecture slides. i want to (2).md 2026-03-27
Layer Name What Happens Here Example Protocols
Level
Cloud Big Data, AI/ML, analytics REST APIs, MQTT
5
Why layered? Each layer has different latency requirements, data volumes, and security policies. A PLC
must respond in milliseconds; an ERP can wait seconds or minutes. This separation prevents conflicts.
Communication between layers becomes the central challenge — each layer historically used different
protocols, vendors, and data formats.
Slide 5: Field Data Interface Devices / Remote
Telemetry Units (RTUs)
What is an RTU?
An RTU (Remote Telemetry Unit) is a hardware device placed at a remote field location that acts as the
bridge between physical field devices (sensors/actuators) and the SCADA network.
"Sensors are the eyes and ears of a SCADA system." — Lecture slide
Types of Sensors (What RTU reads)
Sensor Type Measures Signal Type
Level sensor Tank/reservoir water level Analog (4–20 mA)
Flow meter Flow rate of a pipe Analog (4–20 mA)
Position sensor Open/closed state of valve Digital (0V or 24V)
Temperature sensor Temperature of a machine/fluid Analog (RTD, thermocouple)
Pressure sensor Pipe/tank pressure Analog (4–20 mA)
How RTU Handles Signals — Pin States and Logic
Analog Inputs (AI):
The sensor outputs a continuous electrical signal (e.g., 4–20 mA for 0–100% of measured range)
4 mA = 0% (e.g., empty tank), 20 mA = 100% (e.g., full tank)
The RTU has an ADC (Analog to Digital Converter) that converts this current into a digital number
Digital Inputs (DI):
A sensor like a valve position switch outputs either 0V (open/OFF) or +24V (closed/ON)
The RTU registers this as a binary bit: 0 or 1
Example: Valve closed → switch contact closes → 24V applied to DI pin → RTU reads bit = 1 (HIGH)
Example: Valve open → switch contact opens → 0V at DI pin → RTU reads bit = 0 (LOW)
3 / 14
lets deep dive for this lecture slides. i want to (2).md 2026-03-27
Digital Outputs (DO):
The SCADA sends a command to the RTU → RTU activates a relay or transistor output
Relay energized → coil gets 24V → contact closes → pump motor starts
Signal Path:
Physical World → Sensor → 4-20mA / 0-24V signal → RTU input pin → ADC / Digital
buffer
→ Microprocessor in RTU → Packetized data via Modbus/DNP3 → SCADA Server
Why RTU Instead of Direct Wiring?
Field devices are kilometers away from the control room — running individual wires for each sensor is
impractical
RTU aggregates many sensor signals and transmits them over a single communication channel (RS-
485, fiber, radio, cellular)
Protocols like Modbus or DNP3 are used for this transmission
Slide 6: PLCs — Local Control
PLC vs RTU
A PLC (Programmable Logic Controller) is similar to an RTU but is designed for local, high-speed,
deterministic control logic execution, not just telemetry.
Feature RTU PLC
Primary role Remote data acquisition & telemetry Local automation logic & control
Speed Moderate Very fast (deterministic, ms-level)
Programming Limited logic Full ladder logic, function blocks
Location Remote field site Local to machine or panel
Protocol DNP3, Modbus Modbus, Profibus, EtherNet/IP
How PLCs Work in SCADA
PLCs can operate stand-alone (without SCADA) or as a sub-layer feeding data upward to SCADA.
Examples from the lecture:
MIV (Main Inlet Valve) — has its own PLC for fast valve control logic
Governor — turbine speed governor controlled by a PLC
AVR (Automatic Voltage Regulator) — separate PLC maintains generator voltage
Signal chains from lecture:
4 / 14
lets deep dive for this lecture slides. i want to (2).md 2026-03-27
Path A: Sensors → Electrical Signal → PLC → Communication Protocol → SCADA
Path B: Sensors → Electrical Signal → RTU → Protocol → PLC → Protocol → SCADA
Why two paths? Path B exists when a remote RTU aggregates multiple field devices and passes data to a
local PLC that performs logic, before forwarding to SCADA. As the lecture notes: "The separation is
increasingly blurring" — modern smart PLCs can do both.
Slide 7: Communication Networks
Historical: Dedicated Networks
Originally, SCADA systems used private, dedicated communication infrastructure — serial lines (RS-
232/RS-485), leased telephone lines, private radio networks — completely isolated from office IT.
Why dedicated? Security by isolation. No external access = no external attacks. But this was expensive to
build and maintain.
Connecting to Corporate Networks — Advantages
The lecture lists why industries started connecting SCADA networks to corporate (IT) networks:
No additional operator terminals needed — office PCs can view SCADA data
Integration with existing office apps — spreadsheets, work management systems
History databases — engineers can query trends from their desk
GIS (Geographic Information Systems) — map-based visualization of assets
Modelling and simulation tools — plant optimization using live data
Disadvantage: Cyber Vulnerability
Connecting SCADA to corporate networks opens it to the same threats as the internet — malware,
ransomware, unauthorized access.
Real-world example: The Stuxnet worm (2010) attacked industrial SCADA systems via corporate networks,
physically destroying uranium enrichment centrifuges in Iran.
Solution from lecture: Use firewalls as a security boundary between the OT (Operational Technology)
network and the IT (corporate) network.
Slide 8: Issues with Conventional Architecture
This slide sets up the central problem the rest of the lecture solves. The two core problems are:
Problem 1: How to share data FROM equipment (PLCs)?
5 / 14
lets deep dive for this lecture slides. i want to (2).md 2026-03-27
Each PLC vendor (Allen-Bradley, Siemens, Schneider) had their own proprietary protocol (DF1,
Modbus, Profibus)
To connect to SCADA, each vendor wrote their own protocol driver inside the HMI software
If you had 5 different PLC brands, your HMI needed 5 different drivers — inconsistent, unreliable, hard
to maintain
Problem 2: How to share data BETWEEN software programs and PCs?
Even if SCADA collected the data, it was trapped inside one application
Enterprise systems, MES, and reporting tools could not access it without expensive custom
development
Data had to be manually exported as CSV files — slow, error-prone
Slide 9: Original Solution — Vendor-Specific Protocol
Drivers
Before any standard existed:
Vendor A had their HMI with built-in Modbus driver
Vendor B had their HMI with built-in DF1 driver
Each vendor built the driver differently — inconsistent feature support and reliability
No cross-vendor interoperability — Vendor A's HMI couldn't easily talk to Vendor B's PLC
This was the state of the industry before standardization.
Slide 10: DDE — Dynamic Data Exchange
What is DDE?
DDE (Dynamic Data Exchange) was Microsoft's first attempt to solve the data-sharing problem between
applications on Windows. It was developed in the late 1980s/early 1990s.
Architecture
[HMI Application] ←── DDE Topics ──→ [DDE Server (Protocol Converter)] ←──
Modbus/DF1 ──→ [PLC]
Key concept: The protocol driver was moved OUT of the HMI into a separate DDE Server process.
How it works:
The DDE Server holds the driver knowledge (e.g., how to talk Modbus to a specific PLC)
The HMI connects to the DDE Server using simple DDE "Topics" (like spreadsheet cell references)
HMI says "read Tag_101" → DDE Server queries PLC → returns value to HMI
6 / 14
lets deep dive for this lecture slides. i want to (2).md 2026-03-27
HMI says "write 50 to Tag_102" → DDE Server writes to PLC register
Advantages brought by DDE:
HMI vendors could focus on visualization, not driver development
Multiple HMI applications could connect to the same DDE Server
A market for independent DDE Server vendors emerged
NetDDE extended this over local area networks
Slide 11: Issues with DDE
Despite its benefits, DDE had fundamental problems that made it inadequate for industrial use:
DDE Benefit DDE Problem
Decoupled HMI from drivers Performance issues (slow, not real-time)
DDE Server market emerged NetDDE reliability was poor
More driver choices No standard tag database format
HMI vendors focused on core product No tag browsing capability
Accessible to any DDE application No quality flags (is the data good or bad?)
No client control of poll rates
No timestamps on data
No security whatsoever
Difficult to configure over networks
Limited number of client/topic connections
Why are quality flags and timestamps critical?
In SCADA, stale data (data from a sensor that disconnected 10 minutes ago) is dangerous — an
operator must know if the value is fresh or old
Without timestamps, you cannot build trend charts or do post-incident analysis
Without quality flags, the operator cannot distinguish a real low-temperature reading from a broken
sensor reporting 0°C
Slide 12: A Standard Was Needed
The industry recognized that DDE was not sufficient. Requirements for the new standard were:
Software-to-software interface (solving Problem 2)
Keep the Client/Server model (DDE's best feature)
Better performance — real-time, deterministic data exchange
7 / 14
lets deep dive for this lecture slides. i want to (2).md 2026-03-27
Security — authentication and access control
Support complex data types — variants, structures, arrays
Scalable — thousands of tags, hundreds of clients
Internet-capable — future-proof
A standard controlled by the industry, not one vendor
This led directly to OPC.
Slide 13: OPC — The New Standard (1996)
What is OPC?
OPC originally stood for OLE for Process Control (OLE = Object Linking and Embedding, a Microsoft
technology). It was created in 1996 by 6 founding member companies through the OPC Foundation — a
vendor-neutral industry organization.
Key Properties of OPC
Feature Explanation
Open standard Controlled by OPC Foundation, not one vendor
Timestamp support Every data point carries when it was measured
Quality flags Good / Bad / Uncertain — tells client if data is trustworthy
Interoperability Tested and certified between vendors
Client/Server architecture Same model as DDE but far more robust
Scalable Supports enterprise-scale deployments
Flexible data access Read, write, subscribe
Security Uses Microsoft DCOM/COM security framework
OPC Architecture
[HMI/SCADA OPC Client] ←── OPC Calls ──→ [OPC Server A (Modbus driver)] ──→ [PLC
Brand A]
[HMI/SCADA OPC Client] ←── OPC Calls ──→ [OPC Server B (DF1 driver)] ──→ [PLC
Brand B]
[HMI/SCADA OPC Client] ←── OPC Calls ──→ [OPC Server C (Profibus driver)] ──→ [PLC
Brand C]
The key improvement over DDE: The OPC Server has a clearly defined tag database — a structured
namespace of all available data points. The client can browse this namespace (like browsing a file explorer) to
discover available tags.
8 / 14
lets deep dive for this lecture slides. i want to (2).md 2026-03-27
Slide 14: OPC Conventional — DA, HA, A&E
Classic OPC was split into three separate specifications:
Specification Full Name Purpose
OPC DA Data Access Real-time reading/writing of current process values
OPC HA Historical Access Querying past data stored in historians
OPC A&E Alarms and Events Receiving alarm notifications and event logs
Platform dependency: Classic OPC was built on Microsoft's COM/DCOM technology.
This meant it was Windows-only
COM (Component Object Model) — local inter-process communication
DCOM (Distributed COM) — extended COM over a network
Problem: DCOM was notoriously difficult to configure, had firewall issues, and was tied to Windows OS
Slide 15: OPC UA — Unified Architecture (2008)
Why OPC UA?
Classic OPC (DA/HA/A&E) had critical limitations. In 2008, the OPC Foundation released OPC UA to unify and
modernize everything:
What Changed
Feature OPC Classic OPC UA
Platform Windows only (COM/DCOM) Cross-platform (Linux, ARM, embedded)
Security Microsoft Windows security Built-in encryption + X.509 certificates (PKI)
Architecture Bitwise communication Service-Oriented Architecture (SOA)
Interface Object-based COM calls readTag(), writeTag() service calls
Data model Simple tag values Rich information model with metadata, units, configs
DCOM — very firewall-
Firewall Runs on standard TCP/HTTPS ports, firewall-friendly
unfriendly
Unified single namespace — everything in one
Namespace Separate per DA/HA/A&E
place
Internet
No Yes
ready
Rich Information Model — Why It Matters
9 / 14
lets deep dive for this lecture slides. i want to (2).md 2026-03-27
In OPC Classic, a tag "Temperature_Tank1" just gives you a number like 72.5.
In OPC UA, that same tag can include:
Current value: 72.5°C
Engineering unit: Celsius
Current setpoint: 80°C
Alarm limits: High = 90°C, Low = 10°C
Sensor calibration date, manufacturer info
All structured in a machine-readable format
This makes OPC UA the lingua franca for Industry 4.0 machine-to-machine communication.
Slide 16: OPC UA for Industry 4.0
The lecture shows OPC UA positioned as the protocol bridge between the lower automation layers and the
upper business/cloud layers.
Protocol stack shown in lecture:
SPI/I2C → Sensor-level communication (inside circuit boards)
Modbus / Profibus / Profinet → PLC-level field communication
OPC UA → PLC ↔ SCADA ↔ MES integration layer
Ethernet → Physical network carrying all upper layers
However, the lecture notes a challenge:
"OPC-UA can provide data for Industry 4.0, but integration is difficult"
Why difficult?
OPC UA requires hardware vendors to join the OPC Foundation alliance and implement the protocol
OPC UA is heavyweight — it carries legacy/old data structures
Its security and discovery mechanisms add overhead unsuitable for tiny embedded sensors
Not ideal for millions of IoT devices — designed for dozens/hundreds of industrial nodes
Slide 17: Industry 4.0
What is Industry 4.0?
Industry 4.0 is the 4th Industrial Revolution — the digitization and intelligent automation of manufacturing
and industrial processes.
The four industrial revolutions:
1. Industry 1.0 — Steam power, mechanized production (1760s)
10 / 14
lets deep dive for this lecture slides. i want to (2).md 2026-03-27
2. Industry 2.0 — Electricity, mass production, assembly lines (1870s)
3. Industry 3.0 — Electronics, computers, automation, PLCs (1960s–present)
4. Industry 4.0 — Cyber-physical systems, IoT, AI, big data (2010s–present)
What Industry 4.0 means practically:
3rd Automation creates data — PLCs and sensors generate enormous streams of data
Translating data to information — raw sensor readings become insights via analytics
Digital transformation — paper-based processes become digital workflows
IIoT — every machine reports its status, health, and performance in real time
Lecture example of digital transformation:
Paper logbooks → Manual digital entry → Unified digital system → Information/KPIs
Slide 18: IIoT — Industrial Internet of Things
What is IIoT?
IIoT extends IoT concepts into industrial environments — sensors, machines, and systems all connected and
communicating over IP networks, including cloud.
Key Changes IIoT Brings to SCADA
1. Horizontal vs. Vertical Access:
Traditional SCADA: Vertical access — data flows strictly up the automation pyramid (Sensor → PLC →
SCADA → MES → ERP), layer by layer
IIoT SCADA: Horizontal access — a sensor can report directly to the cloud, bypassing intermediate
layers
This reduces latency and infrastructure cost
2. Security Model:
Traditional SCADA used a mix of proprietary protocols at different ISO layers — hard to secure
consistently
IIoT uses open protocols like TLS (Transport Layer Security) — the same encryption used in HTTPS
web browsing
Three properties TLS provides:
Encryption — data cannot be read by eavesdroppers
Authentication — both parties verify each other's identity
Integrity — data cannot be forged or altered in transit
3. Cloud computing benefits:
Reduces on-premise server infrastructure
Makes maintenance easier via cloud updates
11 / 14
lets deep dive for this lecture slides. i want to (2).md 2026-03-27
Enables cross-site analytics (compare 50 plants' performance from one dashboard)
Slide 19: Five Layers of Business Operation + The
Protocol Problem
This slide shows the complete hierarchy with the protocols needed between each layer:
Cloud (Big Data / ML / AI)
↑ APIs
Enterprise Resource Planning (SAP)
↑ SQL / APIs
Manufacturing Execution System (MES)
↑ OPC UA
SCADA — Supervisory Control / Dispatching
↑ OPC UA / Modbus TCP
PLC/HMI — Direct Control / Automation / Factory Floor
↑ Modbus / CAN
Equipment (Sensors / Actuators)
↑ SPI / I2C
The problem: There is no single unifying protocol that works efficiently across ALL these layers.
Requirements for IIoT protocol (what's missing):
Open standard — no alliance membership required
Report by exception — only send data when it changes (not constant polling)
Lightweight — runs on tiny microcontrollers with limited RAM/CPU
OPC UA fails these because it is heavy, requires alliance membership, and retains old data structures
Slide 20: Solution — MQTT
What is MQTT?
MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe messaging protocol
designed specifically for constrained devices and unreliable networks.
Publish-Subscribe Architecture
MQTT has three roles:
Role Who What They Do
Publisher Sensor, Meter, PLC Sends data to the broker under a Topic
Broker Central MQTT Server Routes messages between publishers and subscribers
12 / 14
lets deep dive for this lecture slides. i want to (2).md 2026-03-27
Role Who What They Do
Subscriber PC, Server, Phone, Cloud Registers interest in a Topic and receives its messages
Example from lecture:
A meter publishes power/plant1/meter1 → Value: 230V
A SCADA server subscribes to power/plant1/+ → automatically gets all plant1 meter readings
A mobile phone subscribes to alarms/+ → gets all alarm notifications in real time
Why MQTT over OPC UA for IIoT?
Property OPC UA MQTT
Weight Heavy (XML, large packets) Ultra-lightweight (~2 byte header)
Alliance required Yes No — open OASIS standard
Old data handling Keeps legacy data structures Clean, modern design
IoT suitability Moderate Excellent
Report by exception Limited Native (event-driven)
Cloud integration Complex Native (AWS IoT, Azure IoT Hub)
MQTT decouples publisher and subscriber — they don't need to know each other's IP address, only the
broker address. The broker can also store messages for devices that are temporarily offline, ensuring no data
loss.
Slide 21: Putting It All Together
This slide shows the complete integrated protocol stack for a modern industrial system:
Cloud (Big Data, ML, AI)
↑ API
Enterprise Resource Planning (SAP)
↑ SQL / API
Manufacturing Execution System (MES)
↑ SQL
SCADA — Supervisory Control
↑ OPC UA
PLC/HMI — Direct Control
↑ Modbus / CAN
Equipment
↑ SPI / I2C / MQTT (direct to cloud)
Sensors / Actuators
13 / 14
lets deep dive for this lecture slides. i want to (2).md 2026-03-27
MQTT is the "horizontal shortcut" — sensors can publish directly to the cloud using MQTT, bypassing
intermediate layers for monitoring purposes, while the traditional vertical path through PLC → SCADA remains
for control commands (safety and reliability reasons).
Slide 22: Industry 5.0
Beyond Industry 4.0
Industry 4.0 optimized industrial processes by removing humans from repetitive tasks — maximum
efficiency, but at the cost of human involvement in production.
Industry 5.0 is the next vision:
Uses AI to bring humanity back into the process — collaborative robots (cobots) working alongside
humans, not replacing them
Sustainable — processes designed with environmental impact as a first-class constraint
Efficient — keeps Industry 4.0's efficiency gains
Personalized — mass customization (individual products made efficiently)
Social — technology that enhances human work and wellbeing
Environmental — circular economy, reduced waste, renewable energy integration
The contrast:
Industry 4.0 = Optimize the process, remove the human Industry 5.0 = Use AI to reintroduce human
judgment, creativity, and ethics into the process
Full Lecture Flow — Big Picture Summary
The lecture follows a logical problem-solution narrative:
1. SCADA exists to monitor and control industrial systems remotely
2. It is organized in layers with different protocols at each level
3. RTUs/PLCs bridge the physical world (sensors) to the digital world (SCADA)
4. Connecting SCADA to corporate networks brings benefits but opens security risks
5. Original architecture had two major problems: proprietary drivers (Problem 1) and data silos (Problem
2)
6. DDE was the first solution — decoupled drivers from HMI but had major limitations (no timestamps, no
security, no quality)
7. OPC (1996) solved DDE's issues with a proper standard — timestamps, quality flags, browsing
8. OPC Classic was Windows/COM-only, so OPC UA (2008) replaced it with cross-platform, secure, rich
data models
9. Industry 4.0 demands IIoT connectivity, but OPC UA is too heavy for tiny sensors
10. MQTT fills the gap as a lightweight publish-subscribe protocol for IIoT
11. All protocols are combined in a layered integration stack for the complete modern industrial
enterprise
12. Industry 5.0 is the emerging horizon — AI-assisted, human-centered, sustainable manufacturing
14 / 14