The ADRC System

Like other disruptive technologies that leapfrog the pack, ADRC might seem like magic. But I assure you it is not magic but is a well conceptualized system whose parts work together harmoniously to achieve a desirable outcome. ADRC has five main parts and these are:

• The application
• Device server
• Device proxy
• RCP
• RML

There are other parts to the system that are introduced during implementation, but these five are the philosophical core of ADRC. 

From the above diagram, you can see how these five parts work together to form a system. Let's look at each part in turn to see what it does.

The Application

Simply put, the application is any entity that wants to interact with devices in the system. At this time the first true ADRC application is a generic client that we call the device browser. The easiest way to think of the device browser is like a kind of special web browser but specifically made to interact with any kind of device, appliance or in fact any entity that has an API. Just like a web browser, you can direct the device browser at a device and it will display its user interface but that is pretty much where the similarity ends. Web browsers are designed to manipulate text, graphics and multimedia content, however device browsers are designed to manipulate control transactions, handle unsolicited events, understand semantic data and provide interfaces for both humans and machines.

Device Server

Again relying on the web analogy, you can think of the device server as being similar to a web server in that it provides content for device browsers and other clients and may provide caching services. However that is where the similarity ends. The device server must deal with a dynamically changing system where devices can appear and disappear. Also devices can emit unsolicited signals that device browsers must be able to receive and interact with. In fact, the  display of a device browser must reflect the true state of a domain of devices as well as the true state of any device that is being browsed. Thus the device server is the heart of a distributed real-time control system; which as you might imagine, is a very difficult function to fulfill well.

Device Proxy

The device proxy has no web counterpart. Its function is to interface any arbitrary device to the rest of the ADRC system and to make this task easy. In networking speak, the correct terminology for the device proxy is a reverse proxy. It provides the native behaviors required by all ADRC complaint devices including:

• enumeration of device structure and metadata
• pairing and unpairing
• security management
• communications transport layer
• file system

Because these core services are provided by the device proxy, the device application does not need to implement them. In fact a device only needs to respond to incoming RCP requests from applications and emit signals when its state changes.

Resource Control Protocol (RCP)

You can think of RCP as similar to HTTP, however it has different features that make it more suitable for controlling devices. It comes in two variants RCP.host and RCP.wire that can be mapped 1:1 to and from each other. The variant you use depends on where you are accessing the system from. RCP.host is used between the application and the device server. It uses an XML syntax to frame documents that form requests to the device server and to deliver responses and signals from the device server to the applications. RCP.wire is used between the device server and devices. It is self-framing, very compact and easy to parse, so it works well with low end microprocessors such as those used by the popular Arduino Uno. You can think of these two variants of RCP as being like XML and JSON. They can express the same data, but one is more light weight than the other.

Resource Markup Language (RML)

RML is an XML based language. You can think of it as being similar to HTML where HTML describes a webpage so that a web browser can draw it on screen, whereas RML describes a device so that a device browser or other ADRC client can control and monitor it and understand the meaning of its data. RML and the device browser implement the Model View Controller (MVC) design pattern. MVC is a powerful paradigm for separating data processing logic, display processing logic and control logic. One of the most interesting things about RML is that it is stored in the device itself, well actually in the file system provided by the device proxy. Because of this, it is possible for applications and devices to interact without connection to the Internet or even a WAN or LAN. RML is of central importance and is used at all layers of the ADRC system including the by the device server.

Now that you have an overview of the core elements that make up the ADRC system, we will look at each one in detail in my next few blogs, beginning with RML.

Until next time... have fun!

Chris Wood
CTO and co-founder