Wdrożenie EMS - hero
Blog

EMS implementation in a manufacturing plant: OT/IT integration with machines and an integrator checklist

September 22, 2026

Before you start OT/IT integration between machines and an EMS, it is worth determining where the system will obtain its data, how that data will travel through the OT infrastructure, and how you will verify its accuracy after commissioning. If you are responsible for production, maintenance, or plant digitalization, before selecting an integrator you need a map of data sources, a communication architecture, and acceptance criteria. We explain these elements below.

EMS integration with machines: what actually needs to be connected?

An EMS can collect data from energy meters, power quality analyzers, PLCs, measuring devices, SCADA systems, and other sources available within the OT layer. The integration method depends on the existing infrastructure. In one plant, the system may read a parameter directly from a meter; in another, the same measurement may be available through a PLC, gateway, or OPC server.

A measurement value alone does not explain the process. If the EMS receives 42 kWh, it also needs to know which device the measurement refers to, what period it covers, and what the machine was doing at the time. The target data flow may look like this:

EMS implementation – data flow infographic

A hypothetical example: a meter assigned to a press transmits energy consumption via Modbus TCP. At the same time, the PLC provides the RUN/STOP status, while the MES provides the identifier of the production order being executed. The EMS can then correlate consumption with machine status and production instead of displaying only an energy consumption chart.

This type of relationship follows the direction developed by the OPC Foundation. Version 1.0.1 of the OPC UA for Energy Consumption Management specification, published on September 1, 2026, defines an information model for data related to energy consumption management.

Prepare an integration point register before requesting a quotation

When discussing the project with an integrator, you need to specify which devices will provide which values, how those values will reach the EMS, and how frequently they should be collected. Ideally, all of this should be documented in a single register.

Field What needs to be defined Example
Asset what the measurement refers to press P-04
Parameter which value is required active energy
Source where the value comes from energy meter
Communication how the parameter is read Modbus TCP
Context what the measurement is correlated with RUN/STOP from PLC
Frequency how often the data is required according to analytical requirements
Communication loss what happens to the data buffering or marking a gap
Acceptance how the result will be verified comparison with the source

Such a document will quickly reveal the limitations of the machine park. An older device may communicate via Modbus RTU, a newer analyzer via Modbus TCP, while some of the required data may already be available in SCADA.

The Modbus Organization publishes separate specifications for the application protocol, TCP/IP communication, and serial communication. A statement in an offer that an integrator supports Modbus does not yet define how your specific device will be connected.

If you are still determining what should be measured and which decisions the measurements should support, this step is premature. We describe that scope separately in this article. A new integration project should begin where the objectives and required data have already been defined.

EMS system: implementation stages from OT inventory to acceptance

Once the required data is known, the technical EMS implementation can be organized into six stages.

1. Inventory of data sources and OT infrastructure. The integrator identifies meters, analyzers, PLCs, supervisory systems, available interfaces, protocols, and network limitations. This stage also reveals where additional metering will be required.

2. Communication architecture design. It must be decided whether the EMS will read data directly from a device or through a PLC, SCADA system, concentrator, or OPC server. The design should specify the direction of data flow and the connections required between infrastructure segments.

3. Data model. Each parameter needs an unambiguous meaning, unit, source, and asset assignment. A register name or tag that is clear to an automation engineer is not yet sufficient for a higher-level system.

4. Integration configuration. Connections and mappings are created, and the EMS begins receiving data. The system’s behavior must be checked during device restarts, communication loss, machine state changes, and missing samples.

5. Validation. The value displayed in the EMS is compared with the reference source. Values, units, timestamps, aggregations, and assignment of measurements to the correct device all need to be verified.

6. Acceptance and documentation. The plant should receive an up-to-date integration point register, communication map, configuration description, and procedures for dealing with a failure or device replacement.

Stage five requires particular attention. Correct transmission does not necessarily mean correct business data. A value may be transmitted without errors while still using the wrong unit, incorrect scaling, or being assigned to another machine. For this reason, the acceptance test must verify the entire chain from the source to the information visible to the user.

Go through every stage of EMS implementation with us with confidence.

Modbus, OPC UA, or SCADA: how should data reach the EMS?

There is no single protocol required for every EMS. Brownfield plants usually need to connect several generations of devices and communication methods.

Direct device reading requires managing a larger number of connections. Retrieving information through SCADA or an existing OPC server makes it possible to use tags that are already configured, but it also makes the EMS dependent on the availability of that layer.

OPC UA can be particularly useful when, in addition to the numerical value itself, you need a structured information model covering the parameter type, its meaning, unit, and relationship with the device. The presence of OPC UA alone, however, does not guarantee correct semantics. What matters is how the data model is built and used. The OPC UA for Energy Consumption Management specification provides a standardized model for energy-related data that can make this work easier.

In an existing factory, there is no reason to replace a stable data source solely because it uses an older standard. The integrator should, however, identify where protocol conversion may be required, who will be responsible for the gateway, and how the system will behave if the connection is lost.

If subsequent analyses require a complete data history, the specification should define buffering, data retransmission, or an unambiguous way of marking gaps. Not every process requires the same level of continuity, so the requirement should be matched to the way the information will be used.

OT/IT integration requires agreed communication rules

Every new connection between a higher-level system and the production network should be agreed with the people responsible for OT and cybersecurity.

In NIST SP 800-82 Rev. 3, NIST recommends segmentation and isolation of OT networks and the use of mapped data flows to determine what communication is actually required between individual segments. Firewalls, gateways, and other boundary devices can then enforce these restrictions.

For an EMS, the following questions therefore should be answered:

If the EMS is expected to send commands to OT, the project scope requires a separate assessment. Monitoring and control should be clearly separated in the documentation, including the expected behavior of the installation when the higher-level system is unavailable.

EMS implementation requires clear communication rules
(photo of an employee by a control cabinet)

How do you evaluate an EMS integrator before signing a contract?

When comparing offers, it is easy to focus on dashboards, the number of reports, or licensing. For successful integration, however, it is more important to determine whether the contractor can describe the data path and responsibility for each of its components.

Before selecting an integrator, check whether:

If a supplier can provide a detailed quotation for a dashboard but does not ask about device models, protocols, and OT architecture before pricing the integration, the technical scope of the project has not yet been established.

EMS, ISO 50001, and a business energy audit are three different scopes

An IT-based EMS can provide the data required for energy management, but implementing the software itself does not constitute ISO 50001 implementation.

ISO 50001:2018 defines requirements for an organization’s energy management system. The standard was confirmed by ISO in 2024, and the ISO 50001:2018/Amd 1:2024 amendment concerning climate change was published in the same year.

The importance of energy management is also reinforced by Directive (EU) 2023/1791. Article 11 requires Member States to ensure that enterprises whose average annual energy consumption over the previous three years exceeds 85 TJ are covered by a certified energy management system. For enterprises consuming more than 10 TJ that do not implement such a system, energy audits are required. The Directive specifies October 11, 2027 as the deadline for energy management systems and October 11, 2026 for the first audit.

If the data is later intended to support a business energy audit, an energy review, or indicators used in an energy management system, data quality, historical availability, and traceability should already be addressed in the integration requirements.

A manufacturing energy management system can therefore support the process with reliable data and analysis, but the ISO 50001 implementation steps cover a broader organizational management system than software deployment alone.

System acceptance should not be signed off by the supplier or IT alone

A technically operational connection may still provide data that production should not accept. For this reason, acceptance requires several perspectives.

An automation engineer confirms the signal source and communication method. The person responsible for energy verifies the meaning and credibility of the measurement. The process owner should confirm that the data corresponds to actual production states. IT or OT verifies the communication architecture and access rules.

This division of responsibilities differs from the project preparation stage, where objectives and the measurement scope are defined. Here, the issue is responsibility for accepting the specific result of the integration.

explitia.EMS can collect data from metering infrastructure and production equipment and, after integration with production systems, correlate energy consumption with a machine, line, or production order. This model is useful when the plant needs industrial energy monitoring in the context of the actual production process rather than a separate collection of energy charts.

The document that should be prepared before sending an RFQ

If you need to prepare one document before starting discussions with integrators, do not begin with a list of system screens. Prepare an integration point register containing the device, required parameter, source, communication method, production context, requirements for missing data, and acceptance criterion.

This makes it possible to compare offers based on a similar scope, identify locations where additional measurements are needed, and separate confirmed information from assumptions made by the contractor.

A properly designed EMS-to-machine integration is complete when the plant can trace the path of a value from the device to the report and verify its accuracy. Only then is the model worth replicating across additional lines.

EMS implementation – what should you do before sending an RFQ?
(photo of a dairy plant employee holding a tablet next to a machine)

FAQ

Does the EMS need to be connected directly to every machine?

No. Data can reach the EMS directly from a device or through a PLC, gateway, SCADA system, or OPC server. The choice depends on the existing infrastructure and the required level of data granularity.

Is OPC UA required for EMS implementation?

No. An EMS can use different communication methods, including Modbus. OPC UA is particularly useful when a structured information model and interoperability between different devices or systems are required.

Does an EMS mean compliance with ISO 50001?

No. ISO 50001 applies to the energy management system of the entire organization. An EMS can support this system with data and analysis, but installing software is not equivalent to ISO 50001 certification.

What should be included in EMS integration acceptance?

Acceptance should confirm the correctness of values, units, timestamps, device assignments, and system behavior in the event of communication loss. Test criteria should be defined before implementation begins.

Still have questions about EMS implementation? We’ll answer them.

Read our latest articles and learn more about IT in manufacturing.

Dedykowane rozwiązania IT - obraz główny
06 10.2026

Custom Software Development: 7 Signs Your Current System Is Limiting Production

AI w ERP - obraz główny
05 10.2026

Generative AI in ERP: 7 Use Cases for an LLM Assistant in Manufacturing

AI w planowaniu produkcji - obraz główny
02 10.2026

AI in production planning: how to access knowledge faster when the plan changes

Migracja systemu SCADA - hero image
01 10.2026

AVEVA SCADA System Migration in the Water and Wastewater Industry. Improve Stability Without Rebuilding the System From Scratch

Analiza przestojów maszyn - hero image
30 09.2026

Machine downtime analysis: how to detect micro stops that spreadsheets miss

Raport produkcyjny bez Excela - hero image
29 09.2026

Production report without Excel: Shift report template and 7 steps to automation

MES a WMS - hero image
28 09.2026

MES vs WMS: 7 Rules for Integrating Production and Warehouse Operations Without Data Silos