Direct Answer

"Normalizing 40+ protocols into one unified data model" does not mean forcing every device to speak the same protocol. It means performing two layers of standardization on the platform side: the ingestion layer first parses the frames of dozens of protocols — Modbus, MQTT, OPC UA, IEC 60870-5-104, BACnet, DL/T 645, and others — into an internal unified frame; the object-model layer then maps the heterogeneous point labels onto one unified measurement-point data model. Once these two layers are in place, the higher-level analytics (such as the Qianzhi and Wanxiang engines in FEXLINK's Taiyi Intelligent Control system) only ever see the unified model; they neither know nor care which protocol the data originally came from. Adding a new protocol then only requires adding one ingestion adapter — the upper layers remain untouched. This is the structural precondition for platform-level capabilities such as "99.9% data ingestion success" and "end-to-end processing under 2 seconds."

In one sentence: protocol normalization = ingestion adapters × unified frame × unified data model, with the decoupling point placed between the ingestion layer and the object-model layer — not by translating dozens of protocols individually into each upper-layer algorithm.

---

1. Why "One Parse Routine per Protocol" Ends in a Dead End

Many projects start with "whatever protocol the device vendor gives us, we write a parser for it." With a few dozen devices and two or three protocols, that is the most direct approach. But when a site simultaneously has energy meters, busway temperature sensors, SPD monitors, environmental sensors, EV chargers, PV inverters, and storage BMS units, the situation changes completely:

  • Each protocol has its own frame structure, byte order, addressing model, and data format;
  • The same quantity is named differently across protocols — the same phase voltage appears as `Ua`, `phase_voltage_a`, or is hidden inside a status word and can only be extracted with bit operations;
  • Each vendor defines its own point table (register/object semantics); even with the same protocol, point tables can differ.

If every new protocol adds its own adaptation logic to the upper layers, the platform rapidly becomes a "patch stack": every new vendor device means touching algorithms, reports, and alarm logic, with an ever-growing regression surface and exponentially rising maintenance cost. This is coupling in its purest form: business logic and protocol details are welded together. Normalization exists to cut that coupling at the structural level.

2. The Ingestion Layer: Individual Parse Adapters for 40+ Protocols

The first layer of normalization is ingestion. Each protocol gets its own independent parse adapter, responsible for exactly one thing: converting that protocol's frames into the platform's unified internal frame.

In FEXLINK's Taiyi back-end, the ingestion layer covers 40+ protocols, broadly grouped by communication profile:

| Protocol family | Representative protocols | Typical devices | |---|---|---| | Serial / bus | Modbus RTU, DL/T 645, LoRa private frames | Energy meters, busway temperature nodes, SPD monitors | | Network / industrial | Modbus TCP, OPC UA, IEC 60870-5-104 | PLCs, edge gateways, substation RTUs | | Messaging / IoT | MQTT, CoAP, HTTP/HTTPS | Sensors, EV chargers, cloud-to-cloud feeds | | Building / automation | BACnet, KNX | BAS, HVAC | | Proprietary / vendor | Vendor custom frames, PLC private protocols | Inverters, storage BMS, various OEM devices |

Typical problems handled inside each adapter include: frame fragmentation and coalescing, CRC/checksum validation, byte order and endianness conversion, extraction of data bits and status bits, address/object resolution, timeout and retransmission, and disconnect/reconnect handling. All of this is encapsulated inside the adapter; outward, it emits only the unified frame.

The unified frame does not care what the original protocol looked like. It defines five elements only: point identifier, timestamp, value, quality flag (is the data trustworthy), and device identifier. Whatever a protocol yields, it lands on these five elements — the equivalent of translating letters in different languages into one internal "official document format" before handing them further down the line.

3. The Unified Data Model: Abstracting Voltage, Temperature, and Leakage into Standard Measurement Points

The ingestion layer answers "can the frame be read"; the unified data model answers "how is what was read described."

The electrical world looks complex but converges: voltage, current, power, energy, temperature, leakage current, harmonics, insulation resistance, lightning current, switch state — all of it can be abstracted into standard measurement points. A standard point is described by a fixed set of attributes:

  • Point code: a globally unique identifier, e.g., "device – circuit – physical quantity";
  • Quantity type: voltage / current / temperature / leakage / harmonic / state, etc.;
  • Dimension and unit: V, A, kW, kWh, °C, mA, %, etc.;
  • Precision: decimal places, resolution;
  • Sampling mode: instantaneous / periodic average / cumulative / event;
  • Device context: which device, which circuit, which physical location it belongs to.

For example, a busway joint temperature, a circuit's residual current, and an SPD's discharge count are three completely different point formats on devices speaking three different protocols; once mapped into the unified data model, they become "a temperature point with context," "a leakage point with context," and "a counter point with context," with identical field structures.

The significance: upper layers no longer need to know that "Modbus register 40001 is temperature"; they only face one language: point – value – time.

4. Object-Model Mapping: Translating Heterogeneous Point Labels into the Unified Model

The ingestion layer turns frames into unified frames, but the unified frame still carries the vendor's point labels. Turning point labels into standard measurement points requires the mapping layer.

Mapping typically proceeds in two steps:

  1. Templating: devices of the same vendor and model usually share a point-table structure. The platform maintains a "point-table mapping template" per device model, predefining the correspondence "register address / object ID → standard measurement point." A new device of the same model simply applies the template — no per-point manual configuration.
  2. Instantiation: when a device is onboarded, the template is applied to the concrete device to generate its measurement-point instances and bind device context (installation location, circuit, asset ID).

Mapping is not always one-to-one. Three situations are common in practice:

  • One-to-many: a single register's status word is split into multiple Boolean points (overvoltage, undervoltage, phase loss in an alarm word);
  • Many-to-one: multiple phase powers aggregate into one total power point (or are computed platform-side);
  • Derived computation: the raw value is not the target quantity and needs a formula conversion (power factor from voltage and current, energy from pulse counts).

Mapping configuration is metadata, not code — operators complete it through a configuration UI, with no programming involved. This turns "onboarding a new device" from a development task into a configuration task.

One point deserves emphasis: mapping correctness directly determines upper-layer analytics quality. A large share of "the data just looks wrong" issues at industrial sites ultimately traces to mapping errors — shifted register addresses, a missed scaling factor, or reversed status-word bit order. Engineering practice therefore applies two levels of validation: at onboarding, point-by-point verification (compare field readings against platform values to confirm voltage, current, temperature, and other critical points agree in value, unit, and direction); during operation, plausibility checks (use the range and association rules of the unified model to automatically flag mapping-induced jumps or dimension errors). Treating mapping as a first-class citizen is the most underrated — and most decisive — part of making protocol normalization work in the field.

5. Why the Upper Layers Become Protocol-Agnostic

The biggest payoff of normalization sits in the upper layers.

The upper-layer analytics of FEXLINK's Taiyi Intelligent Control system include: the pre-processing layer (L3 SAR red-line pre-check), the Qianzhi engine (V4.1, recognition layer, 50 sub-models × 7 perception dimensions, answering "what is abnormal"), the Wanxiang engine (V4.0, situational layer, an 18-level scenario tree with 49 association rules, answering "why and where it is abnormal"), and the Tianyan engine (prediction layer). These engines consume measurement-point sequences under the unified data model — not frames of any one protocol.

The direct consequences of decoupling:

  • Algorithms are protocol-independent: Qianzhi sub-models and Wanxiang scenario rules say "voltage trend of point A is abnormal" or "point B correlates with point C"; they never ask whether the data came from Modbus or MQTT;
  • New protocols do not touch the upper layers: onboard a new vendor device, complete the adapter and point mapping, and the algorithms, alarm rules, and reports all work automatically;
  • Cross-device analysis becomes possible: only when all data lives in one model can analyses such as "busway temperature vs. load current correlation" or "leakage current vs. harmonic linkage" be implemented with unified logic.

In engineering terms: protocol adaptation is a wiring problem; upper-layer analytics is a meter-reading problem. Normalization separates the two for good.

6. Why the Marginal Cost of Adding a Protocol Keeps Falling

After normalization, the cost structure of adding a protocol changes fundamentally:

  • Development scope shrinks: you only build "ingestion adapter + point-table mapping template" — nothing in the upper layers. Adapters sit on a mature framework (unified frame parsing, validation, reconnect, buffering), so a new protocol is mostly "filling in the blanks," not writing a new stack from scratch;
  • Test scope shrinks: regression only needs to prove "this protocol's data reaches the unified model correctly"; the upper layers are unaffected, so no full regression of algorithms, alarms, or reports;
  • Existing templates are reused: many "new protocols" are actually different point tables of an existing protocol — reuse the adapter, add a point-table template;
  • Operational cost drops: protocol problems are localized to the ingestion layer; alarm and analytics problems to the upper layers. The problem domain is clean.

This is also what moves an industrial IoT platform from "project customization" to "productization": when ingestion cost is the core cost of a platform, protocol normalization is the structural lever that drives the marginal cost of each new connection toward decreasing returns. The 99.9% data-ingestion-success figure rests precisely on standardized ingestion, converged unified frames, and reconnect/backfill mechanisms (company-disclosed data, for reference; not a performance commitment).

7. Where the Four-Stage Cleansing Sits: After Normalization, Before Analysis

Between "the data is readable" and "the data is usable" lies one critical stage: cleansing. In the seven-stage pipeline of FEXLINK's Taiyi back-end, the position is:

L1 ingestion (40+ protocol normalization) → L2 four-stage cleansing → L3 SAR red-line pre-check → L4 Qianzhi analysis → L5 Wanxiang situational assessment → L6 fused decision → L7 persistence and push

L2 four-stage cleansing (the G5 data-cleansing scheme) comprises denoising, deduplication, anomaly flagging, and interpolation:

  • Denoising: removes communication glitches and transient spikes;
  • Deduplication: handles duplicate frames and duplicate point reports caused by retransmission;
  • Anomaly flagging: flags clearly out-of-range bad data by setting the quality bit rather than deleting it — the quality bit travels with the point into downstream analysis, telling algorithms "this value is not trustworthy";
  • Interpolation: fills short acquisition gaps according to rules so that missing samples do not interrupt analysis.

The order — cleansing after normalization and before analysis — is deliberate: you normalize first so you can cleanse with one set of rules. If cleansing logic also had to be written per protocol, the coupling problem would simply be relocated. One set of cleansing rules under the unified model (which value ranges are physically plausible, which jumps are abnormal) covers data from all protocol sources — this is the underlying reason "one data-governance logic manages the whole site."

8. End to End: The Full Journey of One Data Sample from the Field to the Algorithm

Putting all the layers together, trace one sample through its complete journey (illustrative scenario, not a specific project):

  1. A busway temperature node in a park's switch room reports temperature over a LoRa private frame (ingested by the LoRa adapter);
  2. A circuit energy meter reports voltage and current over DL/T 645 (ingested by the 645 adapter);
  3. Both samples are parsed into unified frames (point identifier, timestamp, value, quality flag, device identifier);
  4. The point-table template maps them into "temperature point" and "voltage point" under the unified model, bound to device context;
  5. L2 four-stage cleansing: denoise, deduplicate, flag anomalies, interpolate;
  6. L3 SAR red-line pre-check: if a red line is hit (e.g., temperature above the standard's allowable value), the highest-level alarm fires immediately;
  7. Otherwise L4 Qianzhi recognizes "busway temperature is abnormally rising";
  8. L5 Wanxiang, correlating the load-current point, assesses it as "temperature rise caused by overload";
  9. L6 fused decision outputs a composite health score; L7 persists the result and pushes the alarm and report.

At no step does the upper layer need to know whether the data came from LoRa or DL/T 645 — the protocol difference is fully absorbed inside the L1 ingestion layer and the mapping layer. That is the complete engineering meaning of "normalizing 40+ protocols into one unified data model."

Scope and Limitations

  • This article describes the normalization architecture based on FEXLINK's Taiyi Intelligent Control system product capabilities (Taiyi back-end with 40+ protocol ingestion, G5 four-stage cleansing, Qianzhi/Wanxiang/Tianyan engines, and the FEXCloud IoT cloud platform); the exact protocol support list is subject to the latest product documentation.
  • "40+ protocols" refers to the count of protocols supported by the platform's ingestion layer; the protocols actually enabled in a given project depend on its point table.
  • "99.9% data ingestion success" and "end-to-end under 2 seconds" are company-disclosed platform capability metrics, provided for selection reference only; they are not a performance commitment for any specific project. Actual results depend on site networking, device quality, and deployment architecture.
  • Protocol normalization unifies data *inside* the platform; it does not change protocols on the device side. On-site protocol selection should still follow the relevant standards (e.g., GB/T 19582 for Modbus applications, DL/T 645 for energy metering, IEC 62541 for OPC UA, IEC 60870-5-104 for power telecontrol) and project specifications.
  • For integration work on a specific project, qualified integration engineers must design the solution against the actual site conditions; this article is not an integration implementation specification.