Industrial Automation: What It Is, Architecture, Systems, and Engineering Applications

Understand industrial automation, its layers, architecture, OT networks, SCADA, IIoT, cybersecurity, design, testing, and contracting criteria.

Check it out!

Industrial automation is the integration of instrumentation, controllers, industrial networks, supervisory systems, and information platforms to monitor, control, and optimize processes according to defined performance, safety, availability, and traceability criteria. In engineering projects, it goes far beyond PLC programming: it starts with process requirements, moves through control architecture, OT/IT integration, networks, and cybersecurity, and ends with testing, commissioning, documentation, and assisted operation.

What Is Industrial Automation

Industrial automation is the coordinated application of measurement, control, supervision, communication, and software systems to execute or support industrial operations with less dependence on manual intervention and greater operational predictability. The expected result is not simply to “automate a machine,” but to transform process requirements into verifiable control functions.

In a typical architecture, sensors and instruments capture field variables; controllers execute logic and loops; industrial networks transport data; human-machine interfaces and SCADA systems display states, alarms, and histories; and higher layers may integrate production, maintenance, energy, and asset management.

Automation Is More Than a PLC

A recurring mistake is to reduce industrial automation to the programmable controller. The PLC is an important component, but solution performance depends on consistency among the process, instrumentation, network architecture, software, alarm philosophy, interfaces, availability, cybersecurity, and test procedures.

When these disciplines are treated separately, problems arise such as instrumentation points without a functional definition, inconsistent addressing, networks without redundancy where it is needed, excessive alarms, untraceable logic, and difficulty testing the system before startup.

Automation, therefore, is a systems-engineering decision. The selected technology must respond to an architecture and verifiable criteria, not the other way around.

What Are the Main Layers of an Automation Architecture

An industrial automation architecture can be understood through functional layers. The exact division varies with the process and its criticality, but it helps establish responsibilities, interfaces, data flows, and security boundaries.

Field and Instrumentation

The field layer includes sensors, transmitters, switches, meters, valves, drives, relays, actuators, and other devices that measure or directly affect the process. Data quality starts here. An inadequate measurement cannot be corrected by software at higher levels.

Engineering must define range, accuracy, response time, environmental conditions, power supply, protocol, diagnostics, maintenance accessibility, and installation requirements. In critical systems, it must also consider failure modes, fail-safe behavior, and the impact of signal loss.

Another important decision is to distinguish control, protection, operational measurement, and monitoring variables. Treating all points as equivalent can produce an oversized architecture in some areas and an insufficient one in others.

Control

The control layer includes PLCs, PACs, dedicated controllers, RTUs, and distributed control systems. This is where sequences, interlocks, permissives, regulatory loops, and safety logic are executed according to the adopted architecture.

The specification should address processing capacity, I/O quantity and type, redundancy, availability, expansion, time synchronization, diagnostics, and integration with third-party equipment. It should also define application behavior during communication failures, power loss, restart, and switchover between redundant controllers.

Selecting hardware only by the current point count is a fragile approach. Spare capacity, expected growth, processing, memory, module availability, and maintenance strategy must be considered in sizing.

Supervision

HMIs and SCADA systems make states, variables, alarms, trends, and commands accessible to operators. A technically adequate supervisory interface must support operational decision-making rather than merely reproduce colorful screens.

Alarms should have priority, a probable cause, and an expected action; trends must support analysis; critical commands must respect permissives and access levels; and events must be recorded with sufficient time synchronization for later investigation.

The site already contains specific content on SCADA in the power sector and its architecture. In industrial automation, the principle remains the same: supervision and control need clear roles and documented interfaces.

Information and Integration

The upper layer may integrate historians, MES, maintenance, energy, asset management, analytics, and enterprise platforms. Integration must be designed around data models, ownership, protocols, security, and information-quality criteria.

The existence of connectivity does not mean every data item should be exposed to every layer. Engineering must decide which information has operational value, which system is the source of truth, what update frequency is required, and how integration failures will be handled.

From the Process to the Automation System

A good project starts with the process. Before selecting a PLC, SCADA platform, protocol, or software platform, it is necessary to understand what must be controlled, which states are acceptable, which variables are critical, and how the system should respond to normal, degraded, and abnormal conditions.

Functional Requirements

Requirements must describe expected behavior in a verifiable manner. Vague expressions such as “the system shall be reliable” are not sufficient. Where applicable, it is necessary to specify availability, redundancy, response time, accuracy, history retention, alarm categories, recovery times, and safety criteria.

The functional specification should also record permissives, interlocks, manual and automatic modes, startup and shutdown sequences, fallback, and behavior during communication or power loss.

When a requirement can be tested, it can be accepted. When it remains only a generic intention, verification during FAT, SAT, and commissioning becomes subjective.

Control Philosophy

The control philosophy connects the process to the logic. It describes how units operate, who can command them, which conditions allow transitions, how failures are handled, and which information must be presented to the operator.

Without this engineering layer, programming tends to incorporate design decisions informally during implementation, creating dependence on the integrator and poor traceability.

Functional Narratives, Permissives, and Interlocks

Functional narratives detail expected sequences and states. Permissives establish conditions required for a given action; interlocks prevent unsafe or incompatible states. These concepts should be defined before programming and traced through testing.

In large systems, a cause-and-effect matrix can consolidate relationships among events, automatic actions, alarms, and safe states. The document reduces ambiguity and creates an objective basis for integrated testing.

ISA-95 and the Organization of Interfaces Between Control and Enterprise Systems

The ISA-95/IEC 62264 series is a useful reference for structuring the relationship among control functions, manufacturing operations, and enterprise systems. It should not be used as a rigid drawing for every plant, but it provides terminology and models that help define responsibility boundaries and information exchange.

The ISA-95 Part 1 update published in 2025 reinforces the discussion about the boundary between enterprise and manufacturing/control domains. For current projects, this is relevant because integration with MES, ERP, asset management, analytics, and cloud services is increasingly common.

The main practical contribution is to avoid improvised integration. Before connecting systems, engineering must define what information crosses the boundary, who is responsible for it, which applications depend on the exchange, and what the impact will be if the integration is unavailable.

Functional Levels Do Not Replace Risk Analysis

Hierarchical models help organize functions, but segmentation and cybersecurity decisions must consider the system’s actual risk. A modern architecture may include lateral flows, edge computing, and distributed services that do not fit perfectly into a simplified pyramid.

Reference models should therefore be used as engineering tools, not as graphic rules reproduced without analysis.

Industrial Networks and Communication

The automation network should not be treated as a simple extension of the corporate network. Control traffic, availability, segmentation, time synchronization, protocol compatibility, and cybersecurity requirements directly affect the system.

The content on industrial networks, protocols, and SCADA integration explores this layer in greater depth. In an automation project, topology, capacity, redundancy, and management need to be defined together with the control architecture.

Technologies such as industrial Ethernet, Modbus TCP, Profinet, EtherNet/IP, OPC UA, and MQTT may coexist, but each serves different roles. Selection should consider function, latency, interoperability, diagnostics, lifecycle, and support for the equipment involved.

Segmentation and Availability

Redundant switches, industrial rings, duplicated power supplies, and independent paths may be necessary when system unavailability would cause a relevant operational loss. However, redundancy without a defined architecture also increases complexity and failure points.

The design should establish topology, VLANs or zones, addressing, synchronization, management, redundancy, and recovery criteria. These elements must appear in the engineering documentation and acceptance tests.

Network Diagnostics and Maintenance

The architecture should make it possible to identify failures without relying on trial and error. Port status, packet loss, errors, utilization, redundancy events, synchronization, and equipment availability should be observable according to the system’s criticality.

This requirement is relevant during operation and commissioning. A network that “communicates” during simple tests may reveal weaknesses only under failure, high load, or loss of a redundant path.

SCADA and Supervisory Systems

SCADA is one of the best-known technologies in industrial automation, but its function must be understood within the architecture. The supervisory system aggregates visualization, alarms, histories, commands, events, and integration, while time-critical control normally remains in field controllers.

Supervisory engineering involves more than screen design. It is necessary to specify navigation hierarchy, graphic standards, alarm philosophy, users, permissions, retention, server redundancy, backups, and integration with other systems.

Alarms as a Decision System

An alarm should require attention and guide action. If thousands of events are presented without rationalization, the operator loses the ability to distinguish priority and cause. Automation design should therefore separate event, state, and alarm, and define priorities and acknowledgment criteria.

Histories and Traceability

Histories make it possible to reconstruct process behavior, investigate failures, and validate performance. The specification should define which variables are stored, temporal resolution, retention, data quality, synchronization, and backup policy.

OT and IT Integration

Convergence between operational technology and information technology increases data availability, but it also creates new interfaces and risks. Production data may feed KPIs, maintenance, energy, and analytics, while enterprise services may provide identity, backup, virtualization, and monitoring.

This integration must respect separation of responsibilities. The network controlling a process should not depend on enterprise services unless the impacts of unavailability, latency, and security have been evaluated.

OPC UA and Interoperability

OPC UA is frequently used for standardized integration between platforms, with information models and communication and security mechanisms. It does not automatically replace every industrial protocol; its role should be defined according to the architecture and communication requirements.

The OPC Foundation positions the specification from sensors and actuators through MES, ERP, IIoT, and cloud integration. For engineering, the central point is interoperability with known semantics and communication contracts rather than undocumented proprietary integrations.

Modbus and Integration with Legacy Equipment

Modbus RTU and Modbus TCP remain common in industrial equipment. The protocol’s simplicity facilitates integration, but it does not eliminate the need to map registers, scales, quality, timing, fault handling, and network security.

IIoT and Industrial Data

Industrial Internet of Things expands data collection and distribution through sensors, gateways, edge computing, and analytics platforms. In industrial environments, IIoT must coexist with availability, security, lifecycle, and physical-impact requirements that differ from consumer IoT applications.

An IIoT project must answer where the data originates, where it is processed, which decisions depend on it, how devices are authenticated, what happens if the cloud is unavailable, and how firmware, certificates, and assets will be managed over the years.

The subject deserves its own architecture and is explored in dedicated content, without confusing IIoT with industrial automation as a whole.

Cybersecurity in Industrial Automation

Connectivity increases the attack surface. OT networks should therefore be designed with segmentation, access control, hardening, account management, logging, backup, patching, and controlled remote access.

NIST SP 800-82 Rev. 3 highlights that OT has its own performance, reliability, and physical-safety requirements. IEC 62443 complements this approach with requirements and processes specific to industrial automation and control systems.

Zones and Conduits

IEC 62443-3-2 establishes a risk-assessment approach that includes defining the system under consideration, dividing it into zones and conduits, and determining target security levels. In practice, this helps transform “segment the network” into a traceable decision based on assets, functions, risk, and permitted communications.

Security Cannot Be Added Only at the End

When cybersecurity is introduced only after the system has been programmed, architecture decisions have already been made. Common findings then include open communication between segments, shared accounts, unnecessary services, and remote access without adequate governance.

Designing security from the requirements stage reduces late changes and facilitates validation before operation.

Remote Access and Vendor Support

Remote access is often necessary for maintenance, but it should not mean a permanent uncontrolled connection. Identity, authentication, authorization, access windows, logging, approval, and revocation must be defined.

Projects that depend on multiple vendors also need to establish who holds administrative credentials and how the owner regains control of the system at the end of the contract.

How an Industrial Automation Project Works

A robust project organizes technical decisions before implementation. The sequence may vary, but it normally includes surveys, requirements, architecture, detailing, development, testing, deployment, and commissioning.

Survey and Diagnostic Assessment

In existing facilities, the survey must identify equipment, networks, software versions, addressing, panels, I/O, licenses, interfaces, available backups, and operational constraints. Existing As-Built documentation should be validated in the field because documentation inconsistencies are common in systems modified over many years.

Conceptual Design and Architecture

At this stage, architecture alternatives, redundancy levels, system boundaries, network principles, integration criteria, and operating philosophy are defined. It is also the appropriate time to assess risks and avoid choices based solely on vendor preference.

Basic and Detailed Engineering Design

Detailing transforms the architecture into implementable documents: diagrams, I/O lists, topology, addressing, server architecture, equipment lists, specifications, design description, interface matrix, and test criteria.

Development and Configuration

Controller programming, screens, databases, alarms, and integrations should follow defined standards and version control. Changes must be traceable to requirements, drawings, or approved decisions.

FAT, SAT, and Commissioning

The Factory Acceptance Test anticipates verification before field mobilization. The Site Acceptance Test confirms behavior in the installed environment. Commissioning integrates equipment, signals, logic, interfaces, and actual operating conditions.

Industrial commissioning should test normal and failure scenarios, not merely prove that equipment powers up and communicates. Acceptance should rely on predefined criteria rather than the perception that “the system is working.”

FAT: What Should Be Verified Before Going to the Field

FAT reduces the risk of discovering structural problems only during a plant shutdown. Depending on the scope, it may verify architecture, configuration, screens, alarms, permissives, sequences, redundancy, simulated integration, backups, and documentation.

A useful FAT must have a procedure, prerequisites, expected results, evidence, and a process for handling open items. Vendor-led demonstrations without an approved script tend to show only favorable scenarios.

Simulation and Test Coverage

Not every real signal will be available at the factory. Simulators, drivers, and test benches can therefore reproduce enough states to verify logic. Engineering must identify what was actually tested and what remains for SAT or commissioning.

SAT and Testing in the Installed Environment

SAT confirms that the installed system preserves the behavior verified at the factory and correctly integrates infrastructure, equipment, and real signals. It should also verify aspects that cannot be demonstrated during FAT, such as physical networks, fiber optics, power supply, grounding, real interfaces, field devices, and behavior during interventions.

Open items should be recorded and classified. Partial approval of a stage should not erase items that still prevent final acceptance.

Essential Automation Documents

Documentation varies by project, but it normally includes artifacts such as:

• system architecture;
• network diagrams;
• I/O and point lists;
• control philosophy;
• functional narratives and sequences;
• cause-and-effect matrix where applicable;
• alarm and event lists;
• equipment and license list;
• addressing and inventory;
• technical specifications;
• FAT and SAT procedures;
• commissioning plans and records;
• backups and approved versions;
• As-Built and handover documentation.

Documentation quality is part of the asset. Without it, maintenance, expansion, troubleshooting, and future procurement become more dependent on the original vendor.

Backups Do Not Replace Documentation

Having program files is necessary but insufficient. A backup may make it possible to restore an application, but it does not explain requirements, process logic, interfaces, credentials, compatible versions, licenses, or operating criteria.

Handover must bring together both digital assets and documents that make it possible to understand and govern the system.

How to Specify Automation Without Locking the Solution to One Vendor

An engineering specification should focus on performance, interfaces, and verifiable requirements. Brands and models may be used as references when justified, but the scope should not replace requirements with catalog descriptions.

Performance Requirements

It is preferable to establish availability, capacity, redundancy, response time, protocols, environmental conditions, diagnostic resources, and integration criteria. These requirements make technical comparison of alternatives possible.

Interfaces and Responsibilities

Automation projects cross electrical, instrumentation, process, telecommunications, IT, mechanical, and operations disciplines. The interface matrix should clearly state who provides signals, infrastructure, power, network, licenses, configuration, testing, and documentation.

When an interface has no owner, it normally reappears in the field as an open item.

Licensing and Lifecycle Cost

The initial price of hardware and software does not necessarily represent solution cost. Licenses per server, client, tag, protocol, driver, redundancy, history, or expansion can substantially alter future cost.

The specification and commercial proposal need to make clear which licenses are included, which are perpetual or recurring, how support works, and what will be required for a foreseeable expansion.

Automation in Brownfield Projects

Modernizing an existing facility is different from designing a greenfield system. There are legacy devices, restricted windows, incomplete documentation, old protocols, and a need to keep production running.

The article on brownfield projects explores this context in greater depth. In automation, the transition must consider hardware and software simultaneously.

The design should establish a migration strategy, temporary coexistence, rollback, contingency, staged testing, and configuration freezes. The analysis should include not only “what to replace,” but how to transition without introducing unacceptable unavailability.

Cutover and Rollback

Cutover is the moment when functions effectively migrate to the new solution. Each relevant transition should have a sequence, assigned responsibilities, start conditions, success criteria, and a return point.

Rollback is not pessimism; it is risk engineering. If the new configuration does not meet minimum criteria within the available window, the team must know how to safely restore the previous condition.

Operational Indicators and Performance

Automation can generate large volumes of data, but value depends on transforming data into decisions. Availability, cycle time, recurring alarms, failures, energy consumption, quality, and equipment performance can be monitored when the data architecture has been considered from the design stage.

It is important to distinguish a useful indicator from mere collection. Data without context, quality, and ownership increase storage without improving decisions.

Industrial Data Quality

Data may be present and still be inadequate. Incorrect scaling, inconsistent timestamps, lost samples, degraded sensors, unit changes, and duplicate tags compromise analyses.

If KPIs or analytics models depend on these data, quality requirements must be part of engineering and commissioning.

When to Hire an Industrial Automation Company

Hiring makes sense when the organization needs to structure a new architecture, modernize legacy systems, integrate subsystems, review specifications, oversee deployment, or solve recurring failures that cross several disciplines.

Before contracting, the owner should define requirements, boundaries, responsibilities, acceptance criteria, and minimum documentation. Comparison based only on price tends to hide important differences in architecture, licensing, redundancy, engineering, testing, and support.

Independent Engineering and Owner’s Engineering

In significant projects, an Owner’s Engineering function can help structure requirements, review proposals, oversee development, witness tests, and verify documentation. This reduces dependence on the solution presented by each integrator and preserves the owner’s technical interests.

Independence is particularly useful when candidate vendors work with different architectures, licenses, and ecosystems. The owner’s function is not to select a brand by preference, but to ensure comparability, scope compliance, and objective acceptance criteria.

Main Risks in Automation Projects

The most recurring risks are not limited to software. They arise from incomplete requirements, undefined interfaces, weak documentation, poorly sized networks, lack of a testing strategy, and changes made directly in the field.

Consistent management should address configuration, versions, backups, access, changes, test evidence, open items, and acceptance criteria throughout the lifecycle.

Risk	Typical consequence	Engineering control
Vague requirement	Non-comparable solutions	Verifiable functional specification
Interface without an owner	Deployment open item	Interface matrix
Uncontrolled change	Divergence between field condition and documents	Configuration management
Superficial FAT	Defects discovered in the field	Test procedure and coverage
Network without analysis	Instability and intermittent failures	Network design and testing
Informal remote access	Cyber exposure	Access governance
Incomplete handover	Dependence on the integrator	Data Book, backups, and As-Built

How to Assess the Maturity of an Automation Solution

A mature solution has traceable requirements, documented architecture, defined responsibilities, configuration control, verifiable testing, and enough documentation to support operation and maintenance independently of the integrator.

The central question is not how many screens or features exist, but whether the system can demonstrate that it meets operational requirements with safety, availability, and traceability.

Verification Questions Before Acceptance

A technical assessment can start with simple, objective questions:

• does every critical requirement have a test and evidence?
• does the installed architecture match the As-Built?
• were backups restored in a controlled environment or merely copied?
• were licenses and administrative credentials handed over to the owner?
• was redundancy tested through an actual failure or only observed under normal conditions?
• were alarms, histories, and timestamps validated?
• is remote access documented and controlled?
• does each open item have an owner and a due date?

If these answers cannot be demonstrated, the system may be functioning and still not be ready for technical acceptance.

Final Considerations

Industrial automation is a systems-engineering discipline applied to industrial processes. Its value appears when process, instrumentation, control, networks, supervision, data, cybersecurity, testing, and documentation are treated as a single architecture.

Technically well-structured projects reduce improvisation during deployment, make proposals comparable, anticipate integration risks, and leave objective acceptance criteria. For the owner, this means greater control over performance, lifecycle, and future system expansions.

Technical References

[1] 1. INTERNATIONAL SOCIETY OF AUTOMATION. ANSI/ISA-95.00.01-2025 (IEC 62264-1 Mod), Enterprise-Control System Integration — Part 1: Models and Terminology. Research Triangle Park: ISA, 2025. Available at: [https://www.isa.org/products/ansi-isa-95-00-01-2025-iec-62264-1-mod-enterprise](https://www.isa.org/products/ansi-isa-95-00-01-2025-iec-62264-1-mod-enterprise)

[2] 2. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Guide to Operational Technology (OT) Security. NIST SP 800-82 Rev. 3. Gaithersburg: NIST, 2023. Available at: [https://csrc.nist.gov/pubs/sp/800/82/r3/final](https://csrc.nist.gov/pubs/sp/800/82/r3/final)

[3] 3. INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 62443-3-2:2020 — Security for industrial automation and control systems — Part 3-2: Security risk assessment for system design. Geneva: IEC, 2020. Available at: [https://webstore.iec.ch/en/publication/30727](https://webstore.iec.ch/en/publication/30727)

[4] 4. INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 62443-3-3:2013 — Industrial communication networks — Network and system security — Part 3-3: System security requirements and security levels. Geneva: IEC, 2013. Available at: [https://webstore.iec.ch/en/publication/7033](https://webstore.iec.ch/en/publication/7033)

[5] 5. OPC FOUNDATION. OPC Unified Architecture — Part 1: Overview and Concepts. Available at: [https://reference.opcfoundation.org/specs/OPC-10000-1/4.1](https://reference.opcfoundation.org/specs/OPC-10000-1/4.1)

Frequently Asked Questions

What is industrial automation?

It is the integration of instrumentation, controllers, networks, supervision, and software to monitor and control industrial processes according to defined performance, safety, availability, and traceability requirements.

What is the difference between industrial automation and a PLC?

A PLC is only one component of the architecture. Industrial automation also involves process, instrumentation, networks, SCADA, interfaces, data, cybersecurity, testing, documentation, and integration with other systems.

What is SCADA in industrial automation?

SCADA is the supervisory layer used to visualize states, alarms, trends, and events, issue authorized commands, and integrate operational data, while time-critical control normally remains in the controllers.

What documents are needed in an automation project?

Common documents include system architecture, network diagrams, I/O lists, control philosophy, functional narratives, interface matrices, alarm lists, specifications, FAT/SAT procedures, commissioning records, and As-Built documentation.

When should an industrial automation company be hired?

When there is a need to design or modernize the architecture, integrate systems, structure requirements, implement control and supervision, conduct testing, or reduce the technical risks of a complex deployment.

What changes in brownfield industrial automation?

Existing facilities require field surveys, As-Built validation, migration strategy, coexistence with legacy systems, contingency planning, rollback, and intervention-window planning.

What is the difference between FAT, SAT, and commissioning?

FAT verifies the solution before field mobilization; SAT confirms behavior in the installed environment; and commissioning integrates systems and verifies requirements, interfaces, operating scenarios, and failure conditions through acceptance.

Complementary Technical Materials

Related Solutions

• SCADA Systems: supervision, control, alarms, and operational data
• Digital Supervision and Control Systems (SDSC): automation and integrated operation

Related Services

• Industrial Automation Engineering Design: control, supervision, OT networks, and integration
• Owner’s Engineering: technical governance, oversight, and acceptance

Main Content on the Topic

• Industrial Networks: what they are, protocols, architecture, security, and SCADA integration
• SCADA in the Power Sector: what it is, architecture, and application in substations

Related Technical Content

• OPC UA: what it is, how it works, security, and integration with SCADA, Modbus, and MQTT
• Modbus: what it is, differences between Modbus RTU and TCP, and industrial security
• Industrial Ethernet: what it is, how it works, protocols, topologies, and security
• Industrial Commissioning: pre-commissioning, start-up, cold testing, and hot testing
• Brownfield Projects: engineering in existing facilities, surveys, As-Built, and retrofit