A scene common at project acceptance: the platform is open, every device on the list is online, the curves are moving, and all parties treat connectivity as finished. Six months later, when this data is needed for analysis, far less of it is usable than expected.
In IoT engineering, the distance between "seeing numbers" and "numbers that can support a judgment" is widely underestimated. For industrial-grade AIoT to do work on this data, it first has to clear six thresholds. Tongwei Smart lists them here. Each one corresponds to a specific mode of failure.
1. Completeness: is the data from the outage still there?
Network outages are common, especially at outdoor sites networked over 4G. If the gateway does not cache, data from the outage is lost permanently.
The trouble is that this blank stretch is often exactly the period that needs analysis—thunderstorms, high temperature, and voltage fluctuation are conditions that make the network unstable and, at the same time, conditions under which equipment is prone to problems. If trend analysis breaks off there, the precursors of a fault are lost in the gap.
Corresponding capability: offline caching and resume-on-recovery, implemented as configured.
2. Continuity: is the sampling interval stable?
If the sampling interval is sometimes long and sometimes short, the shape of the trend curve is distorted. Threshold judgment is little affected. Trend-anomaly recognition is not—the rate of change cannot be calculated accurately, and the slope has no meaning.
The usual reason this cannot be achieved on site is that the acquisition polling schedule is poorly arranged, or the number of points hung on one gateway exceeds its processing capacity. This is something that should be calculated at the selection stage.
3. Time consistency: are the clocks of the devices aligned?
If each device's local clock is not synchronized, offsets of a few seconds to a few minutes can appear. The order of events then cannot be judged—whether the pump stopped first and caused the temperature to rise, or the temperature exceeded the limit first and triggered a protective shutdown. The two cases look the same in the data.
If cause and effect cannot be judged, root-cause analysis has nowhere to start.
4. Unified definitions: does the same physical quantity have one name at every site?
One site calls it "inlet water temperature," and another site calls it "T1." One reports degrees Celsius, and another reports a raw millivolt value. One splits three-phase current into three points, and another combines it into one.
In that case the data is all there, but cross-site comparison and model reuse cannot be done. Every added site means matching the tag names again, and the engineering effort grows linearly with the number of sites.
Corresponding capability: reuse of protocol templates and device models, so that from the second site onward the data is of the same structure. This is also the key to reducing repeated development on every project.
5. Context: does this value know what it is?
An isolated value has no meaning. It needs to carry the equipment number, installation location, site it belongs to, equipment model, and the current operating-condition tag.
Without context, once the data is in the database it is only a time series. It cannot answer questions such as "which class of problem is most concentrated in this set of equipment" or "how much same-model equipment differs in performance across environments"—and those are exactly the most valuable part after the data has accumulated.
Corresponding capability: a unified ledger of sites and equipment. The ledger is not a management form. It is the source of context for the data.
6. Traceability: can a conclusion be traced back to the raw acquisition?
When the platform gives an anomaly judgment, can it be traced back to the raw acquired value, the acquisition time, and the acquisition channel at that moment?
If it cannot be traced back, there is no way to verify whether the judgment is a real anomaly or an acquisition fault. And problems on the acquisition side—loose wiring, sensor drift, and communication interference—are not rare on industrial sites. A data set that cannot attest to itself, when used for AI training, will learn acquisition faults as equipment faults.
Which layer Tongwei Smart addresses these on
Most of the first five fall on the edge side. The smart IoT gateways and expansion modules developed in-house by Tongwei Smart handle multi-protocol access and protocol conversion, offline caching and local linkage, and remote access and configuration. SG series rack-mount industrial gateways suit wired sites such as equipment rooms, power distribution rooms, and archives as a multi-site acquisition hub. BEC series companion edge gateways suit DIN-rail mounting in a distribution box or installation inside equipment. On the hardware side, the wide-temperature, high surge-protection, and dual-supply hot-standby design also aims to keep acquisition from dropping the link in harsh environments.
The fifth and the sixth fall on the platform side: equipment and data governance, a unified ledger, alarm grading and deduplication, and reports and records on the Tongwei Smart AIoT platform.
The stability capabilities above are all implemented as configured. The specifics are subject to an assessment of the equipment list, protocols, and point tables. We do not replace the customer's core controllers or on-site safety systems.
The thresholds are worth clearing first
These six items sound like engineering details, but together they decide whether this batch of IoT data will be able to support a judgment later. The cost of remediation is far higher than the cost of getting it right at the start—because information lost at the acquisition end cannot be changed back by any later algorithm.
If you have an equipment list in hand, you can give it to Tongwei Smart for an access-feasibility assessment, or apply directly for a sample-unit test, verify data quality once on real equipment, and then decide the volume plan.