Industrial security, thermal management and longevity for edge controllers

Greg Philbrook, product manager, AutomationDirect: Hardware-accelerated encryption and TPM 2.0 represent best-practice security for high-assurance environments, and they are important considerations for any edge device pushing sensitive operational data to the cloud or an enterprise MQTT broker. 

Edge controllers often run much hotter than traditional PLCs because of their high-performance processors. Why is it important to know thermal limits?

Greg Philbrook, product manager, AutomationDirect: Thermal management is a real consideration when adding edge compute capability to an industrial control panel or machine enclosure. Higher-performance application processors generate more heat than a typical microcontroller-based PLC CPU, and, if the enclosure thermal design doesn't account for the additional load, you risk shortened component life, intermittent faults or unexpected shutdowns during peak production. Knowing the operating temperature range and worst-case power dissipation of every module in the system is essential for proper enclosure sizing and cooling design.

Machine builders and panel designers should always calculate total system heat load and verify that the enclosure's thermal management keeps all modules within their rated ranges, especially in high-ambient installations like foundries, outdoor enclosures in summer climates or tightly packed machine cabinets.

What environmental and industrial certifications—temperature range, vibration resistance, IP rating, UL/CE compliance—does the hardware need for on-machine deployment on factory floors? What about inside machines?

Greg Philbrook, product manager, AutomationDirect: For factory floor deployment, an edge module needs to meet the same bar as the rest of the control system. IP protection at the module level is typically governed by the enclosure itself for DIN-rail mounted hardware.

Machines can live for 20 years or longer, but software moves much faster. A clear update path is essential to keep the machine from becoming a security liability. What should be the guaranteed long-term support (LTS) window for a Linux kernel and security patches?

Greg Philbrook, product manager, AutomationDirect: This is one of the most important and underappreciated questions in edge device selection, especially for OEM machine builders whose customers expect 15 to 20 year machine lifespans. The Linux kernel and underlying OS on any edge module need a credible LTS roadmap, ideally a commitment to security patches for a minimum of five to 10 years from product release, with a documented end-of-life date and a clear migration path. Without that commitment, a machine shipped today can become a security liability within just a few years as unpatched CVEs accumulate.

Why is it important to know which industrial communication protocols an edge controller natively supports and whether additional protocols be added through software or middleware?

Greg Philbrook, product manager, AutomationDirect: Protocol support is often the deciding factor in whether an edge device can actually connect to the installed base it needs to serve. A machine on a factory floor might need to communicate with Modbus RTU sensors, an EtherNet/IP PLC from another vendor, an OPC UA server on the SCADA system and an MQTT broker in the cloud, all simultaneously. An edge module that natively handles this mix or can be extended to do so through software eliminates the need for separate protocol converters and simplifies the overall architecture considerably.

How does an edge controller handle data buffering and store-and-forward functionality if connectivity to the cloud or enterprise systems is interrupted? What should the local storage capacity be for that data in case of a signal drop?

Greg Philbrook, product manager, AutomationDirect: The default configuration includes SQLite which can be used for store-and-forward. This is a critical capability for any edge device connecting factory machines to cloud platforms over potentially unreliable networks, and it's a native strength of the Node-Red environment. Node-Red flows can be configured to buffer messages locally, in memory or written to local storage, and replay them to the cloud broker once connectivity is restored. The MQTT protocol's QoS levels and persistent session features also support automatic message queuing and redelivery without custom application logic.

For local storage sizing, the right answer depends on the data rate and the expected maximum connectivity outage duration.

Tell us about one of your company’s state-of-the-art product that involves edge computing.

Greg Philbrook, product manager, AutomationDirect: AutomationDirect's Click Plus C2-NRed module is our answer to the growing demand for edge intelligence in industrial automation. This Node-Red intelligent module plugs directly into the Click Plus PLC backplane, giving machine builders and OEMs a purpose-built edge computing environment running alongside, not instead of, their deterministic PLC logic (Figure 1). It runs a full Node-Red runtime on embedded Linux, enabling real-time data flows, cloud connectivity, protocol bridging and lightweight analytics, all within the familiar Click Plus form factor.

The C2-NRed module runs an embedded Linux environment hosting the Node-Red runtime, while deterministic PLC scan-cycle control remains entirely on the Click Plus CPU. The two are architecturally separated by design. This is an important distinction: the C2-NRed does not attempt to run PLC ladder logic itself, which means control determinism is never compromised by the Linux OS. The Click Plus CPU maintains its own fixed scan cycle, and the C2-NRed reads and writes backplane data asynchronously.

For the edge application layer on the C2-NRed, Node-Red executes flows in a single-threaded, event-driven model well-suited to data routing, transformation and communication tasks that don't require hard real-time guarantees. For applications where you need both tight deterministic control and flexible data processing, the Click Plus architecture gives you both in the same DIN-rail footprint, without asking the Linux side to do what a PLC does best.

The Click Plus CPU and the C2-NRed intelligent module are distinct hardware modules, sharing a common backplane bus. This means the CPU's memory, processor cycles and I/O scan are completely isolated from the Node-Red Linux environment on the C2-NRed. There's no risk that a runaway edge application, a heavy data flow or a cloud connectivity issue will starve the PLC scan cycle or cause a watchdog fault. The two domains simply don't share compute resources.

Data exchange between the PLC and the C2-NRed happens over the Click Plus backplane at regular intervals. This gives the Node-Red developer access to live PLC data—inputs, outputs, registers, coils—while the CPU continues executing ladder logic at full speed. It's a clean, well-bounded architecture that mirrors how industrial PC suppliers have historically paired IPCs with PLCs, except here it's all integrated, factory-hardened, and sold as a single system.

The C2-NRed supports TLS/SSL encrypted communications for MQTT and HTTP traffic natively within Node-Red, which protects data in transit for the vast majority of industrial deployments. Customers connecting to cloud platforms like AWS IoT, Azure IoT Hub or an on-premise broker such as Mosquitto can configure certificate-based TLS without additional hardware. Certificate configuration is managed directly within the Click programming software and is saved as part of the project backup file, so security credentials travel with the project and are restored consistently across firmware updates or machine replication.

Beyond encrypted communications, the Click Plus C2-NRed system includes several layers of built-in access control that machine builders can configure without additional software. The allow list—IP whitelist—lets administrators explicitly restrict which devices are permitted to communicate with the C2-NRed, blocking unauthorized hosts at the network level before they can reach the Node-Red editor or dashboard. User accounts add a second layer, requiring username and password authentication to access the Node-Red environment, with all password attempts and allow list rejections captured in the event record for audit and monitoring purposes. Together, these features—allow list, user accounts, certificate management and TLS-encrypted communications—give the C2-NRed a layered security posture that goes well beyond what most entry-level edge devices offer at this price point.

The Click Plus family, including the C2-NRed, carries UL listing and CE marking, and the modules are designed to operate across an extended industrial temperature range suitable for most panel and machine enclosure environments. The system is also rated for the vibration and shock levels typical of DIN-rail mounted control hardware. For inside-machine mounting in tighter spaces, such as a machine tool or packaging equipment electrical compartment, the same ratings apply, and the fanless, sealed module design of the Click Plus platform is a meaningful advantage over edge devices that rely on active cooling or have ventilation requirements.

The Click Plus modules are not rated for direct exposure to coolant or wash-down. For applications requiring IP65 or higher at the device level, the appropriate solution is to house the Click Plus system in a suitably rated enclosure. AutomationDirect offers a broad range of enclosures and thermal management products that complement the Click Plus system for these requirements.

AutomationDirect takes long-term product support seriously. The Click Plus PLC platform has been in continuous production for over a decade, and an upgrade path has been maintained throughout. For the C2-NRed specifically, we work with our hardware development partner to ensure the embedded Linux environment receives security updates, and we communicate end-of-life timelines with customers well in advance.

Get your subscription to Control Design’s daily newsletter.

The C2-NRed is purpose-built around the Node-Red runtime rather than a general-purpose container orchestration platform. This is an intentional design choice for the target market—machine builders and OEM automation engineers who want powerful edge data flows without the operational overhead of managing Docker images, container registries, or Kubernetes clusters on every deployed machine. Node-Red's flow-based programming model covers the vast majority of edge use cases: data transformation, protocol bridging, cloud connectivity, MQTT publishing, alerting and lightweight dashboards.

For storage longevity, the C2-NRed 's embedded storage is managed to minimize unnecessary write cycles. Node-Red flow configurations and persistent data are stored in a controlled manner, and users should avoid configuring high-frequency log writes directly to internal storage. For applications that require high-volume data buffering, such as store-and-forward during connectivity loss, directing that data through Node-Red flows to an external system or a properly managed buffer is the recommended approach. Customers who need full container support for more complex workloads may want to evaluate a more open Linux IPC platform alongside the Click Plus system, though for most machine-builder applications the C2-NRed's integrated approach provides a better cost-to-capability ratio.

The Click Plus C2-NRed architecture naturally supports network segmentation because the C2-NRed module has its own dedicated Ethernet port, separate from the Click Plus CPU's Ethernet port. This means the PLC's control network and the C2-NRed's IT-facing network can be on completely different subnets or VLANs—a straightforward way to establish a functional DMZ between the OT control layer and the enterprise network or cloud. The C2-NRed handles all cloud and MQTT traffic on its interface, while the PLC CPU communicates with HMIs, Click programming software and field devices on the control network with no direct IP path between the two.

For machine builders designing machines that will connect to customer factory networks, this separation is a significant selling point. It allows the customer's IT/OT security team to apply firewall rules, IDS monitoring, or VLAN policies to the C2-NRed's network connection without touching the PLC control network. Formal DMZ configurations with a managed switch or firewall between the C2-NRed Ethernet port and the corporate WAN are straightforward to implement and are consistent with IEC 62443 network segmentation principles.

For the Click Plus C2-NRed architecture, the relevant latency path is from the PLC backplane data exchange to a Node-Red flow and back, not a direct C++ or Python application path. Backplane data between the CPU and the C2-NRed is exchanged on a periodic basis tied to the PLC scan cycle, so the effective latency for any edge application reading PLC data is bounded by the scan rate plus the Node-Red flow execution time. For most edge use cases—data logging, cloud publishing, condition monitoring, alerting—this is entirely acceptable, as these applications tolerate latencies in the tens to hundreds of milliseconds range.

Where this matters most is in setting realistic expectations: the C2-NRed is not designed for closed-loop control with sub-millisecond response requirements. Those use cases belong in the PLC ladder logic on the CPU, where the deterministic scan cycle governs timing. The C2-NRed excels at everything above that real-time control layer, taking production data and moving it to where decisions and analysis happen. Machine builders should architect their systems accordingly: hard control logic in the PLC, data and connectivity in Node-Red.

The C2-NRed sits in a deliberate middle ground—more open than a traditional PLC, more focused than a general-purpose Linux IPC. The Node-Red runtime is an open-source platform with a large community, thousands of pre-built nodes available through the npm registry, and support for connecting to virtually any cloud, database, or protocol target.

The tradeoff is that a more open environment places more responsibility on the user for security hardening, application testing and long-term maintenance of third-party nodes. A fully closed, appliance-style edge device might offer a simpler, more auditable security posture at the cost of flexibility.

Node-Red has native support for MQTT, HTTP/REST, TCP communications, and the npm node library includes purpose-built nodes for Modbus, EtherNet/IP, OPC UA, Siemens S7, BACnet and many other industrial protocols. This means the C2-NRED can act as a protocol bridge, reading data from field devices via industrial protocols and forwarding it to cloud platforms via MQTT or HTTPS, without any additional hardware. For OEM machine builders whose machines land in varied customer environments, this extensibility is a significant practical advantage.

The C2-NRed's embedded storage is not designed for high-volume, long-duration data archiving, so users should design their buffering strategy around reasonable outage windows—hours, rather than days—and configure flows to manage storage use actively, dropping oldest records when buffers are full, for instance. For applications that require extended local data retention, an external database or edge server in the network is the appropriate complement to the C2-NRed's connectivity role.

For all Click projects, any existing Click ladder logic programs continue to run exactly as they do today on the Click Plus CPU. Adding the C2-NRed to a Click Plus system is purely additive: the CPU keeps executing its ladder logic unchanged, and the C2-NRed gains access to the CPU's data through the backplane. This is a meaningful advantage over edge controller platforms that require customers to re-architect or rewrite their control logic to gain edge connectivity.

For customers considering the Click Plus platform for a new machine build, Click programming software provides a familiar, approachable ladder logic environment with a proven track record across hundreds of thousands of installed units. The C2-NRed then extends that investment into the data and connectivity layer without requiring any IEC 61131-3 expertise on the Node-Red side. The two development environments are independent, allowing the controls engineer and the IT/connectivity engineer to work in their own domains simultaneously.