Software-Defined PLC
Control logic
without the hardware lock-in
The EMS Gateway replaces fixed-function PLCs in energy storage plants with a configurable control layer. It acquires data from every device on site, executes operator-defined logic at the edge, and connects to the cloud platform. Reconfigured in hours, not weeks.
Monitoring & control
Field devices
<1day
Typical time to add a new device type
13+
Integrated device brands in production plants
5protocols
Acquisition interfaces across BESS plant equipment
0visits
On-site visits required to update control logic
01 —Why Software-Defined
PLCs were built for
a different problem
Traditional PLCs were designed for deterministic machine control in discrete manufacturing. Energy storage plants have a different requirement: heterogeneous field devices, continuous data flows, cloud connectivity, and control logic that changes with market rules and operating strategy. Fixed-function hardware does not handle this well.
Traditional PLC approach
-
Vendor-locked programming environment
Logic changes require the OEM's IDE, often a paid licence, and an engineer certified in that vendor's toolchain.
-
Separate SCADA layer required
The PLC captures data; getting it to the cloud or an EMS platform requires an additional SCADA or data concentrator layer, another vendor, another integration project.
-
On-site visit to update logic
Updating a control programme typically requires a qualified engineer on site. For a portfolio of plants, logic changes become a scheduling and cost problem.
-
Integration is a project, not a configuration
Adding a new device type, a new inverter brand, or a new meter model to a PLC-based system typically requires a hardware change or a new firmware build.
EMS Gateway
-
Control logic in a text configuration file
Logic is defined in a plain configuration file. Updating it requires no IDE licence, no vendor certification, and no access to proprietary tooling.
-
Acquisition, control, and telemetry in one component
The gateway reads from field devices, executes control logic, and forwards telemetry to the EMS Cloud. One deployed component; no separate SCADA or data concentrator.
-
Logic updates deployed remotely
Configuration changes are pushed remotely via our management platform. No site visit required. Logic is live in minutes across an entire plant portfolio.
-
New device support in under one working day
Adding a new device model is a configuration task, not a firmware project. In production, new device support has been completed in under one working day.
02 —Operational Capabilities
What operators gain
from the field
The gateway answers the questions that matter for a running plant: what is happening at every device, what is the system doing right now, and who is in control when the cloud connection is not available.
01
Full plant visibility from one interface
All connected devices are visible in a single dashboard, accessible directly on the local network without a cloud connection. Device status, live measurements, and connection health are updated continuously.
02
Edge-autonomous control
Control logic runs on the gateway hardware, independent of cloud availability. A cloud setpoint received before a connectivity loss continues to execute. The plant does not go uncontrolled because an internet link dropped.
03
Remote logic reconfiguration
Operating strategy changes, setpoint adjustments, and new control sequences are deployed remotely. For operators managing multiple plants, the same change propagates to the entire portfolio without coordinating site visits.
04
Write control to any device
The gateway sends commands to connected inverters, BMS, and controllers. Setpoints, mode changes, and enable/disable commands are sent from the local dashboard or triggered by the automation engine. Manual override is always available on-site.
05
Modbus relay for existing SCADA
Where a SCADA system or Power Conversion System already polls a Modbus address, the gateway can serve that address. Acquired data from any connected device is mapped to the register layout the SCADA master expects. Existing upstream systems require no modification.
06
Continuous data logging
All telemetry-flagged signals are logged locally to compressed CSV files with configurable rotation. Logs are available for performance analysis and for reconciling metered energy against cloud records without relying on cloud data retention.
03 —Device Compatibility
Works with the equipment
already on site
The gateway has been integrated with equipment from the following manufacturers across production plants. This list reflects current deployments; it is not a ceiling on compatibility.
Battery Inverters
Solar Inverters
Energy Meters
Battery Management
Adding support for a device not on this list is a configuration task. In production, new device support has been completed in under one working day. Nokto engineers handle this as part of the integration service; no action is required from the operator's team.
Any device that speaks a standard protocol
Compatibility is determined by communication protocol, not by brand. If the device communicates over Modbus TCP, Modbus RTU, OPC UA, CAN, or UDP, it can be integrated. The communication map for any new device is derived from the manufacturer's register documentation.
For devices with undocumented or proprietary variants of standard protocols, Nokto engineers perform the reverse mapping as part of the integration engagement. The operator's team is not involved in this process.
04 —Delivery Model
Engineers included.
Not a product to maintain.
The EMS Gateway is delivered as a managed service. Nokto engineers handle integration, commissioning, configuration updates, and ongoing support. The operator's team is not required to have expertise in the underlying platform.
Integration and commissioning
Nokto engineers build and validate the device configuration for the specific hardware on site. This includes register mapping, protocol verification, and testing write commands against live equipment before deployment.
Remote configuration management
Logic updates, new device additions, and parameter changes are handled by Nokto engineers and deployed remotely. Operators raise a request; the update is live without a site visit.
Ongoing monitoring and support
Gateway health, connectivity status, and device data quality are monitored across the portfolio. Issues are identified and resolved before they affect plant operation. Operators are not expected to diagnose the control layer themselves.
05 —Hardware Platform
Fanless industrial compute.
Selected to spec. Standard Linux.
The Gateway runs on fanless industrial MiniPCs selected and field-validated by us for reliability and connectivity in cabinet environments. Hardware is sourced from established industrial compute suppliers, ensuring supply chain continuity and standard component availability. Operating temperature ratings meet the requirements for direct electrical enclosure installation.
Standard configuration
| CPU | Intel Alder Lake-N, fanless |
| Network interfaces | 2× 2.5 GbE RJ45 (field / management) |
| Serial ports | 2× RS-232 / RS-485 (jumper configurable) |
| Storage | M.2 SSD, PCIe or SATA |
| Wireless expansion | M.2 E-Key slot; 4G LTE module optional |
| Power input | DC 12V, 5.5×2.5 mm barrel |
| Operating temperature | 0 to 60°C |
| Dimensions | 148 × 125 × 56 mm |
Extended network configuration
| Network interfaces | 4× 2.5 GbE RJ45 |
| Use case | Separate field bus, management, SCADA, and WAN on dedicated interfaces |
| Serial ports | 2× RS-232 / RS-485 (jumper configurable) |
| Storage | M.2 SSD, PCIe or SATA |
| Power input | DC 12V, 5.5×2.5 mm barrel |
| Operating temperature | 0 to 60°C |
| Dimensions | 148 × 125 × 56 mm |
Platform selection is determined at project scoping. Nokto specifies the appropriate variant based on the number and type of field devices and the network topology of the installation.
06 —Operating System
Fedora Linux.
Fast patches. No downtime.
The gateway runs Fedora Linux. The choice is deliberate: Fedora's rapid release cycle means security patches reach production devices significantly faster than long-term stable distributions. When a CVE is published, we are not waiting for a stable backport.
Updates are staged through our own test infrastructure before reaching field devices. New OS and software versions run on internal hardware first. Only after validation do they deploy to production gateways. Operators see no downtime and are not involved in the process.
Next step
What equipment is
on your site?
Provide the device list and communication infrastructure for the plant. Nokto produces an integration profile showing which devices can be acquired, what data is available, and what the control architecture looks like before any hardware ships.