Why ADRC?

The technology

Every technology that we have seen so far for remote control or for IoT has been based on device profiles, e.g. this is a TV or a temperature sensor.

This means that the end user cannot simply produce a completely novel device and have it work with other devices in the system without going back to some industry consortium and arguing that this device category should be added to the standard.

Even within a well defined category of device such as a TV every manufacturer wants to include some differentiating features. With existing systems this was usually catered for by having 'proprietary' fields within a standard profile.

The problem with this approach is that nobody but the manufacturer knows what these extra features are or how to use them.

ADRC takes a radically different approach. Each device describes itself in detail in such a way that a user interface can be rendered or a machine control scheme can be easily constructed.

The shield

One of our first products to market will be an Arduino shield which makes ADRC available to hobbyists (and other developers).

I have tried various wireless communication shields. Bluetooth, wifi etc. None that I have tried provide a complete end to end solution for either providing a user interface or machine to machine communication.

ADRC provides a method for describing a machine and its user interface. It also defines a protocol for 2 way synchronous and asynchronous communication.

Our library for arduino exposes all of this functionality to your code and handles all of the ADRC specific background work.
To use the library, you provide a description of the machine's inputs and outputs in an XML file and write handlers for the state changes in these I/Os.

Our hub enables your smartphone to talk to any number of ADRC shields as well as other products which are becoming available on xped.com and if your phone has NFC then pairing it with any ADRC device is a simple as tapping it to the xped logo.

The future

We have come up with many uses for ADRC which we hadn't even considered when we started and yet they have been easy to implement without modifying the core system.

We believe that ADRC can be used in many (most?) applications where communication with a machine is required and are actively seeking adopters who might be companies or individuals.

We believe that ADRC will herald the a new way of doing things: crowd design and manufacture. Where virtually anyone has the ability to innovate and create new things that can be manufactured and sold worldwide.

In the meantime we will continue to develop new products and applications, some of them pragmatic and some just for fun.

Keep watching this space for more.

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

WHAT IS ADRC?

Before I answer this question it is probably best if you watch this short video first...

In a nutshell, ADRC technology allows a controller to be tapped on a device, causing a graphical user interface for the device to appear on the screen. Thus enabling the user to instantly interact with the device. Imagine if every device in the world was made this way! We would all be able to interact with the things around us to get information, control and do all sorts of things that we can scarcely imagine at the moment.

This is the future that ADRC can deliver. Imagine you are walking down the street and you see a snack food vending machine.Mmmm, the candy looks good but you don't have the right change. In fact it seems like you never have the right change! Well if the vending machine was ADRC enabled, you would simply tap your smartphone on the touch point logo on the machine:

ADRC touch point logo

and the control panel for the vending machine would appear on your phone. Then select the candy that you want, the machine displays the price on your phone and you pay for it using PayWave or PayPass by tapping your phone again and the candy is yours!

I don't know about you but I never seem to have the change for a parking meter or if it takes credit card, it is out of service. So why not put ADRC technology in all the parking meters? Just tap your phone on the meter, select the parking time you want, the machine calculates the charge and displays it on your phone. You pay by PayWave or PayPass by tapping your phone on the meter again to confirm.

Hey I bet you're getting some ideas of your own by now.

One reason that ADRC is so different from all the other solutions out there right now is that you only need one app to handle every device. That's right only one app! Which really is the breakthrough here.You don't need an app for the vending machine, well in fact for every different vendor of vending machine and you don't need an app for the parking meter, in fact every different vendor of parking meter. Everybody that has a smartphone knows the problem of app overload; it is a daily nuisance. ADRC eliminates this in just the same way as the web browser did for the WWW. That is, ADRC delivers device browser technology and a markup language to make the interaction between controllers and the devices totally generic. But more on this in later posts.

We at Xped have already got the ball rolling by making some really useful devices that already have this amazing technology built in. Our IR Blaster will allow you to get rid of all your infrared remote controls forever and control your AV and AC from your phone. Our Ultra Plug allows you to control simple appliances like lamps, fans, heaters right from your phone and even see how much power they are using and their historical energy usage. Our Vari Plug is similar to Ultra Plug but allows you to dim a lamp or change the speed of an electric motor. These are just the first of many products on our road map.You can visit our website www.xped.com to get more information on these

For those of you that are hobbyists and Arduino fans, we have created the ADRC Shield. Just add one of these to your next Arduino project and you will be able to control it from your phone in minutes.Just like in the video.

Well that's it for now. I hope you think ADRC is as wonderful as we do. Stay tuned for my next installment that explains the main parts that make up the ADRC system

Until next time... have fun!

Chris Wood
CTO and co-founder