Lately, we’ve been referring to building “Intelligent Device Networks” in conversations with potential customers and in our marketing content. Seems like it might be a good idea to define more completely what we’re talking about when we use that term.

Maybe a good place to start is to answer the question; what is a non-intelligent network? Normally a network, whether local or online, just consists of the hardware and software directly responsible for moving data from one physical device to another. Whether the information is relayed to a computer across the room or on the other side of the planet, it’s pretty much the same drill.

The network will most often include some sort of authentication/authorization functionality to ensure a level of security, but otherwise it’s pretty much limited to moving the data from one location to another.

Certainly, when the data arrives at its destination, the receiving device may do many intelligent things with it, but the network is typically not involved with that part of the process. Once that handoff occurs, the network has done its job.

When we speak of intelligent device networks, we’re referring to a situation where the network itself has a layer of intelligence between it and the device to which it is delivering data. In traditional local area network terms, think of a situation where a network interface card actually includes an entire computer capable of running its own software programs independent of the device it’s communicating with.

The natural question at this point might be, why would anyone want to do that? There’s no doubt, the current situation has proven itself to be highly effective over the last forty-plus years of network evolution.

We’ve also been talking a lot about building “communities” of robotic devices at our company recently. We have another article about this in our blog so won’t spend much time on robotic device communities here. But in brief, it refers to having a group of otherwise unrelated robotic or automated devices come together in communities to work cooperatively toward common objectives. If one wants to build a robotic community, an intelligent device network might be a great way to implement it.

One of the ideas behind the “community” concept is that the devices making up the community operate completely independent of each other and are normally left to do whatever it is they’re designed to do with no direct interference from the community except in extraordinary circumstances where intervention is required.

In normal circumstances, the community may provide supervisory instructions to a device, but the device will make its own decisions about what it does or doesn’t do with those instructions. In fact, the device will make all its own decisions about what it will do at any given moment and generally how it will spend its time.

In our intelligent device network model, the network endpoint has the logic that decides how the destination device will or won’t respond to data received. This logic can be kept completely separate from whatever logic or intelligence is actually controlling the device. The endpoint acts as an intelligent interface between the device and the device-community the network supports.

The intelligence housed in the network endpoint has the unique perspective of knowing the objectives and rules of the community while also understanding the rules and needs of the destination device. One of its key purposes is to act as an arbiter between the two.

As an example, imagine a situation where a group of order-picking robots in a warehouse participate in a community that also includes an automated conveyor system. The conveyor system uses PLC to provide the logic needed to do its job safely and efficiently. At the same time, each of the robots has some controlling program that includes the logic and intelligence necessary for the robot to perform its tasks safely and efficiently.

A key purpose of the device community/network in this example is to manage the interaction between the robots and the conveyor system. The community might be responsible for things like:

• Knowing the current load on the conveyor system and keeping it from getting overloaded.
• Knowing the list of orders the robots will be picking on a given day.
• Knowing the current location and status of each of the robots.
• Knowing of any anomalous or faulty operation of any of the community “members”.
• Etc...

All the “intelligence” listed above is implemented by the hardware & software for the network endpoints. In addition to knowledge of what’s going on with the community, the endpoints also have a clear understanding of the current status of the devices to which they’re attached. This design allows the devices that make up the community to be independent from it while still being able to participate in achieving its objectives.

The devices receive information from the community, but their network endpoints filter it and decide what actions, if any, the device should take to respond to the information. If the endpoint does decide to pass an instruction to the device, deciding whether to follow it or to override it is ultimately still up to the device.

This is how our framework can support the type of freeform networks and “robotic device communities” we advocate.