The plant already has data. It may simply be trapped in systems that were never designed to talk to one another.

A PLC knows whether a production process is running. A building automation controller knows what an air handler is doing. A smart meter records electrical demand. A lighting system knows which areas are occupied. A process instrument measures pressure, temperature, flow, or level. A maintenance platform knows which assets have open work orders.

Each system may be functioning correctly.

The challenge is seeing the relationships among them.

That is where the Industrial Internet of Things (IIoT), often called industrial IoT, becomes useful.

Industrial IoT is not one protocol, one cloud platform, or one enormous network connecting every device in the facility. It is an architecture that allows useful information from different operational systems to become available where it can support monitoring, analysis, coordination, and better decisions.

Connectivity is the means. Operational insight is the outcome.

Industrial Facilities Already Have Multiple Networks of Things

The phrase “Internet of Things” can make industrial connectivity sound newer than it really is.

Building and industrial-control systems have been networking devices for decades. The difference is that these systems evolved around different operational requirements.

In building automation, BACnet has become the predominant open communication standard for HVAC and building controls. Lighting systems may use specialized technologies such as DALI, or Digital Addressable Lighting Interface, for digital communication, addressing, configuration, and control.

Industrial and process-control environments have another ecosystem.

Modbus is widely used among PLCs, meters, drives, instruments, and other industrial equipment. Technologies such as PROFIBUS, FOUNDATION Fieldbus, and HART address different factory, process, and field-instrumentation requirements. Other facilities may incorporate PROFINET, EtherNet/IP, OPC UA, serial networks, manufacturer-specific protocols, or specialized equipment interfaces.

These systems do not need to speak one universal language to participate in IIoT.

A modern industrial facility is more likely to contain multiple specialized operational networks that exchange selected information at deliberate integration points.

Understanding where those integration points belong is one of the most important decisions in IIoT design.

The strongest industrial IoT solutions begin with those deliberate integration points, not with a requirement to connect everything.

Think in Layers: Field, Supervisor, and Enterprise

A useful way to understand industrial connectivity is to divide the architecture into three broad layers.

Device and field integration connects controllers, PLCs, meters, drives, sensors, actuators, lighting devices, and process instrumentation.

Local supervisory or edge integration brings selected information from those systems into a common platform where it can be normalized, trended, visualized, alarmed, or shared.

Cloud and application integration moves selected information into enterprise systems, remote applications, analytics platforms, maintenance systems, or multi-site environments.

In simplified form:

Field Devices & Controllers
BACnet | Modbus | DALI | HART | PROFIBUS | other field protocols
↓
Local Supervisor / Edge Platform
Integration | normalization | histories | alarms | local applications
↓
Enterprise / Cloud / Analytics
APIs | enterprise applications | analytics | fleet visibility | business systems

This architecture also introduces two useful integration terms.

Southbound integration generally refers to communication from a supervisory or integration layer toward controllers, meters, PLCs, sensors, and other field systems.

Northbound integration generally refers to making selected information available to higher-level applications such as enterprise software, analytics platforms, maintenance systems, or cloud services.

A supervisory or industrial IoT platform can sit between those worlds, translating and normalizing information from multiple southbound systems while exposing selected information northbound.

That separation matters because control and information do not necessarily need to travel the same distance.

Control Locally. Coordinate Regionally. Analyze Globally.

Different information has different timing and reliability requirements. If a controller needs a temperature measurement to operate a cooling sequence, sending that value to a remote cloud application and waiting for a command to return would usually add unnecessary dependencies. If an enterprise energy team wants to compare monthly electrical consumption across 100 facilities, recreating that analysis independently at every controller would be equally impractical.

A useful architectural principle is: Control locally. Coordinate regionally. Analyze globally.

Time-sensitive and mission-critical control generally belongs close to the physical process. Supervisory platforms can coordinate systems, maintain histories, normalize information, and provide local visualization. Enterprise and cloud platforms become valuable where organizations need portfolio-wide visibility, analytics, business-system integration, or computing resources that do not need to reside at every facility.

The boundaries vary by application, but the principle remains useful:

Keep critical control close to the process. Allow useful information to travel farther.

Device-Level Integration: Fast, Local, and Resilient

The closest integrations occur among controllers, gateways, PLCs, meters, drives, and field devices.

A BACnet controller might communicate directly with a VFD.

A PLC might collect information from a Modbus meter.

A gateway might translate information from a specialized field network into an IP-based protocol.

The principal advantage is proximity to the process. Local integration can provide fast response, low latency, continued operation without internet connectivity, direct access to device information, and clear local control authority. That makes it particularly valuable for real-time control, interlocks, equipment coordination, and other functions where response time and availability matter. But local integration creates lifecycle responsibilities. Protocol drivers need to remain compatible. Gateways require configuration. Firmware changes can affect behavior. Devices eventually become obsolete. Point mappings need documentation. Serial networks and older field buses may require expertise that becomes harder to find as systems age. Local integration can provide excellent performance and resilience. It also creates assets somebody must understand and maintain.

Supervisory Integration: Creating a Common Operational Context

A second approach brings different systems together within a local supervisory, edge, or IIoT platform.

Platforms such as Niagara Framework are designed for this role.

Instead of requiring every field device to communicate directly with every other system, a supervisor can use different drivers and protocols to collect selected information, normalize it, maintain histories, create graphics and alarms, and expose appropriate data to higher-level applications.

A supervisory environment might combine:

• • • BACnet information from HVAC controls
    • Modbus data from electrical meters
    • Lighting-system information
    • Selected PLC or process information
    • IT or infrastructure data
    • Environmental measurements
    • Utility information

The original field networks can continue performing the functions they were designed to perform while the supervisor creates a broader operational view.

This approach can provide several advantages. It preserves local visibility and operation even when remote connectivity is unavailable. It can reduce unnecessary cloud traffic by deciding locally which information deserves to move northbound. It can normalize multiple protocols into a structure that operators and higher-level applications can more easily interpret. And it provides a logical boundary between local operational control and broader information exchange. But the supervisor also becomes part of the facility’s technology lifecycle. Drivers need updates. Certificates and credentials need maintenance. Frameworks and operating systems require patching. Databases need management. Graphics, tags, histories, scripts, and point mappings require documentation. Integration that nobody owns eventually becomes integration that nobody trusts.

Cloud and API Integration: Scale Without Moving Control

The third model moves selected information higher in the architecture.

Instead of directly connecting every physical system, industrial IoT applications can expose appropriate information from local platforms through APIs, MQTT, OPC UA, cloud connectors, or other application-level interfaces.

That information can support:

• • • Enterprise analytics
    • Energy-management platforms
    • CMMS and maintenance applications
    • Business-intelligence tools
    • Remote operations centers
    • Multi-site dashboards
    • Data lakes
    • AI and machine-learning applications

This architecture can be extremely powerful for distributed organizations. It is especially useful for distributed organizations using industrial IoT platforms. A cloud application can compare performance across dozens or hundreds of facilities without requiring direct access to every individual controller. Software capabilities can be deployed centrally. Large datasets can be analyzed using computing resources that would be impractical to duplicate at every site. Application-level integration can also reduce the need for every system to understand every underlying field protocol. But the dependencies change.

Cloud and API integrations may rely on WAN availability, authentication services, certificates, subscriptions, vendor APIs, data models, connector versions, cybersecurity policies, and continued support from multiple software providers. An API can change. A connector can become incompatible after an upgrade. Authentication requirements can evolve. A cloud service can be discontinued.

The complexity has not disappeared. It has moved. It has moved within the IIoT software stack.

Choose the Integration Layer Based on the Job

No integration model is universally better.

The right question is:

What does this information need to do?

The cheapest integration on bid day is not necessarily the least expensive integration over its lifecycle.

That is why architecture should consider total ownership, not merely whether two systems can exchange data during commissioning.

Connected Does Not Automatically Mean Useful

Even perfectly connected systems can produce poor information.

One system calls a point AHU-3 SAT. Another identifies the same asset differently. Engineering units are inconsistent. Timestamps do not align. A sensor has drifted. One value is sampled every minute when a daily trend would suffice, while another is sampled hourly even though the event being investigated lasts five minutes.

The systems are connected.

The information still lacks shared meaning.

Useful IIoT therefore depends on more than communication.

Teams need to establish:

• • • Identity: What asset, space, system, or process does the point represent?
    • Meaning: What is being measured or commanded, in what units and under what conditions?
    • Timing: How current is the information, and are timestamps synchronized?
    • Quality: Is the source accurate, commissioned, and communicating normally?
    • Relationship: Which other variables provide context?
    • Ownership: Who is responsible for maintaining the connection and acting on the information?

This is where technologies such as OPC UA, tagging standards, semantic models, and normalized supervisory databases can become increasingly valuable.

Research from the National Institute of Standards and Technology on standard connections for IIoT-enabled smart manufacturing likewise emphasizes the role of connectivity and integration standards in interoperability.

Interoperability allows information to move. Context allows people and software to understand it.

Start with the Decision, Not the Dashboard

“Connect our plant” is not an operating objective.

Neither is “put everything in the cloud.”

Start with a question:

• • • Why does electrical demand remain elevated after production stops?
    • Why do environmental conditions drift during second shift?
    • Why does one production area consume more compressed air than another?
    • Why does one data hall require more cooling than another with a comparable IT load?
    • Which systems were operating immediately before a quality excursion?

Once the question is defined, determine:

1. 1. 1. What information is required?
      2. Where does that information currently exist?
      3. How quickly must it move?
      4. Does the recipient need read-only or control access?
      5. Where should the integration occur?
      6. What should happen when the information reveals a problem?
      7. Who will own and maintain the connection?

That produces an architecture around an operational requirement instead of a technology shopping list. This creates a more durable foundation for connected manufacturing.

Building Systems Add Valuable Operational Context

Building automation occupies a particularly useful position within IIoT because the building is not merely a shell around production. It provides the thermal, environmental, ventilation, airflow, pressure, and utility infrastructure that allows people, processes, and equipment to operate.

Consider a temperature increase near a production process. A temperature reading identifies the symptom.

Now compare it with production state, outdoor conditions, supply-air temperature, fan operation, airflow, damper position, cooling-valve position, exhaust status, and space pressure.

The team can begin asking much better questions.

• • • Did production create a larger heat load?
    • Did cooling capacity change?
    • Did exhaust increase without sufficient replacement air?
    • Did a damper fail to respond?
    • Did a schedule or override leave equipment in the wrong operating mode?

The same principle applies to energy.

An electrical demand spike becomes much more useful when it can be viewed beside production activity, compressed-air demand, HVAC operation, lighting, or other facility loads.

This is where IIoT moves from collecting data to explaining operations. It also shows how the internet of things in manufacturing can connect facility and production context.

Open Protocols Create Choice, Not Magic

Open standards reduce unnecessary barriers to integration. BACnet supports interoperability among building automation systems. DALI addresses digital lighting communication. Modbus, PROFIBUS, HART, FOUNDATION Fieldbus, OPC UA, and other standards provide communication mechanisms throughout industrial environments.

But protocols do not automatically establish:

• • • Common naming
    • Engineering units
    • Asset relationships
    • Semantic context
    • Data ownership
    • Alarm priorities
    • Control authority
    • Historical sampling
    • Cybersecurity policies

Those are architectural decisions.

Two devices can communicate perfectly and still produce an integration that is difficult to operate or maintain.

Open protocols create choice. Good architecture turns that choice into lasting interoperability.

Firmware and Software Are Part of the Integration

Connectivity is not finished when commissioning ends.

Controllers, gateways, meters, field instruments, switches, supervisory servers, and other connected assets all contain software or firmware. Vendors may issue updates to correct defects, address cybersecurity vulnerabilities, add capabilities, change certificate requirements, or maintain compatibility with other systems. OT updates require discipline because changes can affect physical processes. A sustainable IIoT architecture should therefore establish a lifecycle pathway for important assets and integrations.

Teams should know:

• • • Which hardware, firmware, and software versions are installed?
    • Who monitors vendor advisories?
    • Who evaluates and tests updates?
    • Which configurations and databases are backed up?
    • What dependencies exist among drivers, devices, and applications?
    • What is the rollback plan?
    • Can the process continue safely during an update or failure?
    • Who owns equipment that has reached end of support?

Cloud integration does not eliminate this responsibility. It changes the objects being maintained from controllers and gateways toward connectors, APIs, certificates, identities, subscriptions, and data models.

Connectivity is not a project deliverable. It is a lifecycle commitment.

Cybersecurity Should Follow the Data Path

Every integration changes the facility’s technology environment. A field network connected to a gateway gains a new communication path. A supervisory server connected to an enterprise network introduces another trust boundary. A cloud API creates an external connection.

None of those conditions makes integration inherently unsafe. They make architecture important.

NIST guidance treats operational technology security as a problem that must account for performance, reliability, and safety requirements as well as conventional security controls.

A sensible IIoT cybersecurity strategy asks:

• • • Which systems actually need to communicate?
    • Which direction should information flow?
    • Is read-only access sufficient?
    • Which users, devices, and applications are authorized?
    • Where should networks be segmented?
    • How are identities, credentials, and certificates maintained?
    • How are communications monitored?
    • What happens if the connection is compromised?
    • What happens if the connection simply disappears?

The last question is particularly important. A physical process should not lose safe local control merely because a WAN connection, cloud service, analytics platform, or enterprise application becomes unavailable.

Local control and connected intelligence serve different purposes.

Open and Secure Are Complementary

There is a persistent misconception that an open building-automation system must somehow be less secure than a proprietary one. These are different architectural questions.

An open protocol defines how systems can exchange information. Cybersecurity determines which systems are allowed to communicate, which actions they may perform, and how those relationships are protected. Obscurity is not a substitute for security. Neither is unrestricted interoperability good architecture.

The more useful objective is controlled interoperability.

• • • Allow legitimate systems to communicate.
    • Limit communication to what is required.
    • Authenticate devices and users.
    • Segment networks appropriately.
    • Apply least-privilege access.
    • Protect sensitive communications.
    • Monitor unusual behavior.
    • Preserve local control.
    • And maintain those protections throughout the system lifecycle.

Where KMC Controls Fits

KMC Controls operates primarily within the building-automation, supervisory, integration, and cybersecurity layers of this broader IIoT architecture.

KMC Conquest^® controllers provide open, BACnet-based control of HVAC and environmental systems while making operational information available through an industry-standard protocol. That information can include temperatures, pressures, environmental conditions, equipment states, schedules, setpoints, alarms, and other values that help explain how the building is responding to facility and production requirements.

KMC Converge™ extends KMC controller configuration and application capabilities into Niagara Workbench environments, allowing KMC Controls products to participate naturally within multi-vendor supervisory architectures. That makes Niagara particularly relevant as a bridge between southbound building-system information and broader northbound applications.

KMC Commander^® provides an IoT and automation layer for remote visibility, trending, alarms, notifications, and connected facility information. Selected data can therefore move beyond the local equipment network without requiring time-sensitive control to move away from the controllers responsible for it.

Where IP-connected building automation requires stronger cybersecurity protection, KMC Dome™ can complement open-system design by adding device identity and restricting unauthorized communications at the building-automation edge. These products occupy different layers because those layers serve different purposes. The objective is not to put every device on one network or send every BACnet object to the cloud.

It is to place control, supervision, integration, analytics, and cybersecurity where each function makes the most operational sense.

IIoT Is an Architecture, Not a Product

A mature IIoT architecture may contain a surprising amount of technology that never communicates directly with the public internet. A process instrument may communicate through HART. A PLC may use PROFIBUS or Modbus. A building controller may communicate through BACnet. Lighting may use DALI. A local supervisor may normalize selected information from several of those systems. An edge platform may expose only the information required by an enterprise application. A cloud platform may analyze performance across dozens or hundreds of sites.

And the underlying control systems can continue operating locally if the WAN disappears.

That is still IIoT.

In many industrial applications, it is a more resilient approach than connecting everything directly to the cloud.

Insight Is the Test of the Connection

The clearest measure of IIoT benefits is not how many devices are online.

It is whether the architecture helps someone understand the operation sooner, make a better decision, or respond more effectively.

• That may mean recognizing that an energy increase followed a production change.
• It may mean connecting environmental drift to an exhaust sequence.
• It may mean comparing thermal performance across data halls.
• It may mean combining BAS, electrical, compressed-air, process, and production information to explain a problem that no individual system could reveal.

Industrial facilities already generate enormous amounts of data.

The opportunity is to move the right information through the right layer, at the right speed, with the right context and authority, to the people and systems that can use it. That is what turns connectivity into industrial intelligence. For a complete overview of how KMC Controls supports energy performance, environmental stability, open integration, cybersecurity, connected operations, and uptime in industrial facilities, explore our Industrial Building Automation Solutions.

Ready to connect building-system intelligence with your industrial operation? Find a KMC Controls Partner to discuss an open, secure integration strategy designed around your facility’s actual operational requirements.

References

• National Institute of Standards and Technology, Guide to Operational Technology Security, SP 800-82 Rev. 3
• National Institute of Standards and Technology, Smart Infrastructure and Manufacturing
• National Institute of Standards and Technology, Standard Connections for IIoT Empowered Smart Manufacturing
• Cybersecurity and Infrastructure Security Agency, Cybersecurity Best Practices for Industrial Control Systems
• BACnet International, About BACnet
• Modbus Organization, Modbus Protocol
• FieldComm Group, HART Technology
• OPC Foundation, OPC Unified Architecture

Many thanks for Jesse Shoemaker, VP of Business Development at KMC Controls, for contributing to this article.