Why not send everything to the cloud
The simplest design for a connected sensor is to transmit every measurement to a server and do all the thinking there. For slow-moving values such as a tank level or a room temperature, that works well. For the signals that reveal machine condition, it does not.
Mechanical faults show themselves at high frequencies. Capturing them faithfully means sampling a vibration or acoustic signal thousands of times each second. A single device doing that continuously produces a volume of data that most industrial networks were never designed to carry, and a facility may have thousands of assets worth watching. Multiply the two and the arithmetic stops working long before the analysis begins.
There is also the matter of what the data contains. Nearly all of it describes a machine behaving normally. Transmitting, storing and paying for normal is a poor use of resources when the purpose of the system is to find the exception.
What the edge does
NODE is designed to do the first and most data-intensive part of the analysis itself. In outline, the device is intended to:
- Capture signals at the fidelity the physics requires.
- Extract features, reducing raw waveforms to the measurements that carry diagnostic meaning.
- Learn a baseline for the specific asset it is attached to, across its normal range of loads and conditions.
- Detect change relative to that baseline, across modalities.
- Report findings, with supporting evidence, to AFFERENT Cloud.
The result is a large reduction in what needs to travel over the network, with no reduction in what the device actually observes.
Four reasons the edge matters
Response time
Some conditions develop over months. Others develop in minutes. A device that can recognize a serious change locally does not have to wait for a round trip to a data center before raising it.
Resilience
Remote sites, underground plant rooms and shielded electrical rooms are hard places for radio. Networks at industrial sites are also deliberately restricted. A device that depends on a constant connection is blind whenever the connection drops. A device that analyzes locally keeps working and reports when it can.
Data minimization
Raw acoustic and vibration data from a facility can reveal more than machine condition. Processing it on the device and transmitting conclusions limits what leaves the site. For operators of sensitive facilities, that restraint is a requirement.
Economics
Bandwidth, storage and cloud computation all cost money, and those costs scale with data volume. Doing more at the edge is what makes it reasonable to instrument the many ordinary assets in a facility and not only the few most expensive ones.
What a baseline is
The idea of a baseline is central to edge intelligence and is easy to misunderstand. It is not a single number or a fixed limit. It is a description of how one particular machine behaves when it is healthy, across the range of conditions it normally meets.
A pump runs at different speeds. A motor carries different loads. A cooling unit works harder on a hot afternoon than on a cold night. Each of those states has its own normal pattern of vibration, sound and temperature. A useful baseline captures that variety, so that the device can tell the difference between a machine that is working harder and a machine that is beginning to fail.
Building a baseline takes a period of observation after installation. During that period the device is learning and its findings should be treated with corresponding caution. Machines also change legitimately over time: a repair, a new operating regime or a change of season can shift what normal means. A baseline therefore has to be maintained and not simply recorded once. Deciding when a change is a new normal and when it is a developing fault is one of the harder problems in the field, and it is a place where the edge and the cloud are designed to work together.
What the edge cannot do alone
An edge device sees one asset. It cannot know that the same subtle pattern preceded a failure on a similar machine at another site. It cannot retrain itself on the experience of a fleet. Those are jobs for the cloud.
The architecture is therefore a partnership. The edge handles what must be fast, local and data-heavy. The cloud handles what must be comparative, historical and large in scale. Improved models are designed to flow back to the devices, so that each device benefits from what the whole network has learned. Read about AFFERENT Cloud.
The engineering constraints
Running a model on a small device mounted on a hot, vibrating machine is a constrained problem. Power is limited. Heat must be managed, both for the electronics and so that the device's own warmth does not contaminate its thermal measurements. Memory and computation are a small fraction of what a server offers. Models have to be compact and efficient, and they have to be updatable in the field without interrupting monitoring.
These constraints are the reason AFFERENT designs its hardware and its models together. A model can be shaped for the processor it will run on, and the processor can be chosen for the model it must run. Specific hardware details will be published in the product specifications once they are final.
