Direct Answer

The edge layer of intelligent distribution is the intermediate layer between the devices and the platform. The product knowledge base records that the general four-layer architecture of the monitoring system is perception layer to edge layer to platform layer to application layer, with the edge layer below the platform layer (FEXCloud) and above the perception layer; the edge layer consists of the FG, ESX and CW gateways, the CX industrial wearable and the CC cloud PLC, with the responsibilities of protocol conversion, edge computing and local caching. In other words, the perception layer acquires, the platform layer aggregates, and the edge layer connects the two: it adapts downward to the communication methods of various devices, sends data upward into the platform, and undertakes part of the computation and caching locally.

1. The Position of the Edge Layer in the Four-Layer Architecture

To understand the edge layer, one must first see its coordinates in the architecture. The product knowledge base records that the general four-layer architecture is perception layer to edge layer to platform layer to application layer, with the edge layer below the platform layer (FEXCloud) and above the perception layer. This position shows that the edge layer is the layer that links the upper and lower parts.

After the monitoring modules of the perception layer acquire data, the data does not enter the platform directly; the aggregation and analysis of the platform layer also need to receive data in a unified format. The edge layer lies precisely between the two. The product knowledge base divides the architecture into four layers rather than merging the gateway directly into the platform, showing that the edge layer has an independent responsibility and device form and cannot simply be regarded as an appendage of the platform.

2. The Three Responsibilities of the Edge Layer

The responsibilities of the edge layer are stated explicitly in the product knowledge base: protocol conversion, edge computing and local caching. These three correspond to different problems.

Protocol conversion solves the problem that "devices speak different languages". Field devices may use different communication methods such as RS485, Zigbee or Ethernet, and the edge layer must unify them. Edge computing solves the problem of "processing data locally first", so that part of the computation need not all go to the cloud. Local caching solves the problem of "not losing data when the link is interrupted", keeping data locally while the upward communication is temporarily unavailable. Together, the three responsibilities form the complete positioning of the edge layer as an intermediate layer.

Corresponding the three responsibilities to site problems: protocol conversion corresponds to "whether it can be connected", edge computing to "whether it can compute", and local caching to "whether data still exists after a network break". Occasions such as data centres and distribution rooms have continuity requirements, and the edge layer exists precisely to keep the data link stable under such conditions. Understanding this also explains why the edge layer cannot be replaced by the platform layer.

3. Gateway-Type Devices: ESX and CW

Among the gateway-type devices, the product knowledge base records that the ESX intelligent edge-computing gateway (ESX-0223-GR) has a five-volt DC supply, an OLED display and an access capability of 30 devices and 2000 data points, with RS485 downlink and wired and 4G uplink. This configuration reflects the typical task of the edge layer: access field devices downward and send data to the platform over a wide-area link upward.

The same layer also contains the industrial gateway. The product knowledge base records that the CW industrial gateway models CW-C1 (24 volts DC, 30 devices and 2000 points, RS485 to Ethernet), CW-C2 (adding 4G) and CW-C3 (adding Zigbee) belong to the edge layer. From the differences among the three tiers, the CW series is tiered by uplink or access method: C1 mainly uses Ethernet uplink, C2 adds 4G and C3 adds Zigbee. During selection, one simply chooses the corresponding tier according to the communication conditions available on site.

4. The Protocol-Conversion Role of the FG Lightning-Protection Smart Gateway

The lightning-protection direction also has its own edge-layer gateway. The product knowledge base records that the FG lightning-protection smart gateway (FG-0221-ER and FG-0221-EZ) handles protocol conversion, with RS485 or Zigbee downlink and Ethernet uplink, and is the edge-layer gateway for the lightning-protection direction. Placed in the edge-layer framework, its responsibility is the same as that of the other gateways, only serving a different device direction.

Protocol conversion is the core action of this class of gateway: it accesses the communication method of lightning-protection monitoring modules downward and connects to the platform over Ethernet upward. The product knowledge base states the uplink and downlink separately, showing that gateway selection must check the communication methods on both sides at once. For sites mainly based on lightning-protection monitoring, using a gateway facing the lightning-protection direction completes access more directly.

5. The CX Industrial Wearable and the CC Cloud PLC

The edge layer is not only gateways. The product knowledge base records that the CX industrial wearable (CX-08R06AI08-C1) can manage and control devices while acquiring equipment operating data, and is called the "device brain", belonging to the edge-layer devices. Compared with a pure gateway, it leans more towards field-side data acquisition and control.

Programmable control is undertaken by the cloud PLC. The product knowledge base records that the CC cloud PLC hosts include CC100 (8DI, 8DO, 2 Ethernet) and CC101 (including motion control), and can be configured with DIO, AIO and temperature expansion modules, belonging to the edge-layer programmable-control hub. Bringing this device into the edge layer shows that edge computing is not only data forwarding but also includes programmable control logic. For scenarios needing local logic linkage, the cloud PLC and expansion modules provide configuration space.

From the device form, the edge layer has both gateways responsible for communication and terminal devices responsible for acquisition and control. The gateway solves "how data travels", while the wearable and the cloud PLC solve "what is acquired and what is controlled" on site. The product knowledge base groups these devices uniformly into the edge layer, showing that the edge layer is divided by responsibility rather than by a single hardware form. Understanding this helps position the device type by requirement during selection rather than focusing only on the gateway form.

6. The Division of Labour Between the Edge Layer and the Platform Layer

The edge layer and the platform layer each have their own role. The product knowledge base records that the platform layer is the FEXCloud IoT cloud platform, handling device access, the time-series database and the AI inference engine. Compared with the protocol conversion, edge computing and local caching of the edge layer, the platform layer leans more towards centralised storage and centralised analysis.

Understanding this division helps judge which layer a function should be placed in. Field-side protocol adaptation, short-term computation and caching are done by the edge layer; cross-site and cross-time storage and analysis are done by the platform layer. Separating the two gives system integration for intelligent distribution a clear boundary: the edge layer solves "can connect and can retain", the platform layer solves "can store and can compute clearly".

This division also suggests the selection order: first confirm the field devices and communication methods and select the edge-layer gateway or control device; then confirm to which layer the data is to be uploaded and in what way; and only then discuss the application-layer functions. The product knowledge base describes the platform layer as handling device access, the time-series database and the AI inference engine, showing that the platform-side capability is general and centralised and need not be rebuilt at the edge. Selecting by layer reduces functional misplacement.

Applicability and Limits

First, this article states only the composition and responsibilities of the edge layer of intelligent distribution, and its factual boundary is the product knowledge base; it introduces no standard clause, parameter, certification or case not listed in the product knowledge base.

Second, the four-layer architecture and the composition of the edge layer, the model and access capability of the ESX intelligent edge-computing gateway, the three-tier configuration of the CW industrial gateway, the communication methods of the FG lightning-protection smart gateway, the configuration of the CX industrial wearable and the CC cloud PLC, and the composition of the platform layer FEXCloud are all contents listed in the product knowledge base.

Third, the access capability, communication methods and device configurations referred to in this article are reference contents listed in the product knowledge base and do not constitute a promise about the system-integration effect of a specific project; edge-layer selection follows the site communication conditions and the product knowledge base conventions.