#VSCP Register Abstraction Model (VSCP-RAM)

The single most important part of a VSCP system is the Register Abstraction Model.  With it you can describe anything that are real (or even not real) in this universe.  Quite a piece of a powerful super tool to have in your arsenal.

In the IoT world people often say that MQTT,  CoAP,  etc is IoT servers/protocols. For me they are transport mechanisms. Good ones, at least in the case of MQTT.  Useful for IoT? Yes. But IoT severs no?

Now what!?

To explain my point. Look at a web server. It serve content using the HTTP protocol. Simple enough. Works good. Quite similar to MQTT in fact.


this was not the reason the world-wide web was a success.  If everyone started to serve different non standardized content with the http protocol it would have been a mess of it all. Very hard to cope with for the web readers at least.  Yes, it would have been useless. Well this was more or less the case also pre HTML.  But what HTML did was to specify a common format for the content. That was the killer that made everything moving. Not the web server which is just the transport mechanism just as MQTT and others are in IoT.

VSCP try to be more than a transport mechanism for m2m and IoT. A common way to look at and handle “things”.  (yes MQTT can transport it just as CoAP and others can)

In the picture above is a view on how VSCP look at a “thing“.  A “thing“can be a TV,  a refrigerator,  a car,  a lamp,  a human or whatever. Everything can be described in this way. Yes, everything. Hardware as well as software or a some abstract non existing life form. ANYTHING is the world.

To describe anything is of course not a problem. One just describe the anything in a way that comes up in one’s mind. So if we ask 999 people to describe the anything object there will be 999 different descriptions. That is actually OK. The problem is rather that there will be 999 different ways to interpret the descriptions of the anything. Hard work.

If we instead came up with a common way to look at the anything,  an abstraction of it,  we could all use that abstraction to describe every the anything and after that we do not need to come up with so many new ways to interpret the descriptions nor ways to interact with the anythings of the world. We could even use this abstraction on top of any of the 999 description from above as it is useful for describing anything. Good if we love our “description” and don’t want to throw away our lovely description and interpretation of it.

Of course, the abstraction would be most useful if it was available for a high-end system or user as well as for low-end system or user.  Low end can actually be really  low-end.  So we better start there.  But a high-end user or system demands handling of great complex things so we need to take this into account as well.

VSCP solve this in the following way

  • Everything can be described by a collection of  8-bit registers.
  • To know whats inside an 8-bit register you need the ability to read it.
  • To change the content of an 8-bit register you need the ability to write it.

So VSCP can describe everything in the universe,  yes everything from a flower,  a person,  a car or anything else with a set of 8-bit registers. The only thing needed to interact with the resister set is that registers can be read and written.


  • Read a byte.
  • Write a byte.

is all that is needed for  VSCP to work with “anything” on its lowest level.

In VSCP this is called the Register Abstraction Model.

VSCP’s register abstraction model demands that all “anything” objects have a set of registers that contain specific information. Same on all. The two most important parts is GUID, ett globally unique id  a 16 byte world unique if for “the anything“,  and a 32-byte area which contains a pointer to a  Module Description File.  The GUID identifies “the anything” much the same way as an Ethernet MAC does for Ethernet device.  They can actually be coupled. The MDF pointer can point at a local location or to a file on the Internet. The content is a well-defined XML description of “the anything”.

One thing that is described is of course the registers of “the anything“.  But to handle things on a register level can be to hard sometimes. For instance is a floating point value stored in eight registers. If this floating point value for instance represent a temperature of “the anything”  and this is what the application or user is interested in there should be no need to know how it is actually stored on “the anything“.

So to make life easier for high-end systems or users the MDF often also contains abstractions. Abstractions specify higher end type such as strings, floats, integers, booleans and tell in what registers they are stored and also how many bytes they use.  So a high en user just handle these higher end objects, reading and writing them,  even if the system still only read and write bytes.

Both registers and abstractions describe the same “anything“,  just on different levels.

At this point it would be possible to build an application that can configure any device, “anything“,  just by read/write byte operations and by reading and interpreting the MDF of the unit. The user (or machine) just fill in the values. The same application can be used to configure a car,  a TV,  a clock radio etc.

The MDF can also contain wizards. A wizard can guide a human user, step by step through a specific setup of a device. They are also described in an abstract way and can be interpreted by C/C++, JavaScript and other higher end programing languages alike.  So it is as easy to make an app. that goes through the wizard steps as it is to make an HTML page that do the same.

It is of course possible to use XML/JSON on the higher level to “set register/abstractions”.  A read and a write byte operation is still all that is needed.

The fact is that the register abstraction model is so light weight that it easily can live alongside a more proprietary solution

But way?

That you have to think about yourself… ,-)

ps VSCP is of course a lot more than this. There are events, classes/types, bootloaders, decision matrices and a lot of other clever things. ds.