Introduction to VSCP (multilingual)

VSCP stands for Very Simple Control Protocol and it is, as the name implies, a very simple protocol. It is simple because it has been developed for use on low end (read low cost) micro controllers.

But VSCP is actually more then just a protocol. Collected in a package described as VSCP and friends its a complete solution for measurement and control. The protocol was placed in the public domain in year 2000 when the project first was started and is therefore free to use and implement for everyone.

VSCP uses a very well specified message format and supports global unique identifiers for nodes making a node identifiable wherever it is installed in the world. It has a register model to give a flexible common interface to node configuration and a model for controlling node functionality.

VSCP does not assume anything about the lower level system. It works with different transport mechanism such as Ethernet, TCP/IP, Wireless, Zigbee, Bluetooth, CAN, GPRS, RS-232, USB.

Every control situation can be described and implemented using VSCP.

• Free and open for commercial and other use
• Have two levels. Level I and Level II where level I is designed with CAN as the least common denominator. Can be used for TCP, UDP, RF, Mains communication, etc etc.
• Has globally unique id's for each node.
• Has a mechanism to automatically assign a unique id to a newly installed node and inform other nodes and possible hosts that a new node is available and ready.
• Use “registers” as a uniform way to configure nodes.
• Can use a “decision matrix” to program nodes with dynamic functionality.
• Has a common specification language “MDF” that describe a module in a uniform way that can be used by set up software and such.
• Has software and drivers for Windows and Linux. More added all the time.

VCSP is designed to be used where other solutions are to expensive to implement. This can typically be in code overhead where most other protocols use more resources (flash/ram) on a micro-controller then the actual “application” adding a lot of cost to the project.

VSCP can work with a typical lowest cost dumb nodes like the Microchip MCP250xx series, to a 1K-2K flash micro controller module up to a full implemention with all features in about 5K flash.

VSCP is both free and open. Everyone can join the project and help to add features and functionality to the protocol. There is free firmware and driver code available for most micro-controllers which uses many communication techniques. Anyone can use this code with no demand to share back any new code added even if most users do just that.

VSCP is an event based system. Nodes generate events and nodes react on events. Normally events is not addressed but instead they are broadcasted on the bus. Its up to the receiving end to decide if its interested in the event or not.

All events got a originating address for the node they are sent from. This is a GUID consisting of 16 bytes but a shorter, typically, one byte nickname id is used on most system. It is always possible to deduce the full GUID from the nickname.

Events are divided into groups. First there is Level I and Level II events. Level I events are limited to a maximum of eight bytes of data while Level II events can have up to 488 bytes of data. The low maximum data count for Level I comes from that CAN has been used as the least common denominator. This does not limit VSCP Level I to be used only over CAN.

Both Level I and Level II events are divided into a class and a type. The class defines a group of events of a specific type. Typical examples are classes for measurements, information and control.

As mentioned above events are not addressed. This is not entirely true as one class in each level (CLASS1.PROTOCOL and CLASS2.PROTOCOL) have events that are addressed. These classes defines protocol functionality that all nodes must implement. Typical examples found here is event typse for boot loader, register access and status information.

Most of the events can use a zone/subzone definition to define a group of different nodes beloging for instance to one room or specific machine or what ever (geographical, logical, functional grouping beyond class and type).

Each node has a specified number of byte wide registers defined. This is the second interface to the black box the node represents. The register space of a node is 256 bytes divided in two halves. The lower part (0×00-0x7f) is application specific. The upper part content is mandatory and specified by VSCP. This space hold, among many other things, the firmware and hardware version of the node. The GUID, user module id, alarm status and similar registers.

In the top of the mandatory register space is a 32 byte string stored, the MDF, which contains an URL that points to a location where to find an XML file that describe this module its registers and its functionality.

The lower part of the register space is used to define control and status registers and more complex structures. The area is mapped and 65535 pages can be used if needed allowing for very complex scenarios if needed.

The MDF file describe the module in a high level way. It gives information about the maker of the module, what events can be expected from it and the definition of its register content. The MDF looks at the module from a high level perspective and can see floating point values, bit arrays, option tables in register space and thus give application software a way to present registers in a much more user friendly way.

There is two way to obtain the MDF after getting it from the module by reading the registers holding it . As VSCP is designed for low end nodes it is normally to much for such a node to have the MDF stored internally. In this case the string points to a web server from which the XML can be downloaded and processed. In a more capable module with more resources the MDF is stored internally in which case the read string has zero length and in this case the MDF data can be fetched from the module itself. The node constructor decide which method he/she wants to use.

The MDF also point out where drivers for different environments and systems for the module and user manuals etc can be found.

All nodes can optionally implement a decision matrix. This matrix is used to define one or a group of events that should trigger a predefined functionality at the module. In VSCP this is called the Event-Decision-Action mechanism from the predecessor of the project which was called EDA.

A typical examples can be to trigger a relay. The module got one action that set the relay and another action that reset it. Typically this could be implemented hard coded so that the relay would be set when an ON-event was received and reseted when an OFF-event was received. With the use of the DM it is easy to use any event to trigger the action not just the ON/OFF events.

Physically the DM is located in register space just as any other parameters of the module so register access functions are used to changed it.

A special class is used for measurements and events for all SI units and derived units is defined. The class will grow over time when new types are needed. This means that for example a temperature measurement is normally sent as a Kelvin temperature. Celsius and Fahrenheit is also possible in this case and similar alternatives is available for other types but the SI unit is always the default.

How the measurement is presented in the frame is also well specified. Bit field, string, integer, normalized integer (decimal) and floating point values are possible. The normalized integer is especially well suited for a low end system to send decimal data. As the event and its content is well specified it is very easy to interpret the data on the receiving end where it should be processed, stored in a database, logged or displayed.

As VSCP is event based one often need to think a bit differently when constructing a system. A typical example is a tank with a level sensor and a pump which together construct a self contained system. A traditional system system would have used a master to control the pump and the sensor. In VSCP we allow for this also but try to distribute as much of the intelligence as possible to the nodes themselves.

So what we do is to tell the level sensor to send level information with a predefined interval. Possibly having several sensors for redundancy.

We tell the pump that it should start to fill up the tank when the tank reach a low level and stop at a high level. This might be dangerous as the sensor may stop working, the cable get cut or whatever. In this case the we also program the pump goes to its safe state == pump off and alarming this state to the rest of the system when it does not receive sensor measurements any more.. This “safe state“ is often possible to find for most control situations.

As the transport mechanism is unknown to the application, timing must be very lose for VSCP. We cannot be certain when an event arrives or if it arrives. Many transport mechanisms, such as CAN and TCP/IP, makes delivery more certain while other solutions like UDP, RF and PLC can be problematic. It is therefore very important that a sent event always get a confirmation event back.

For some nodes this might not be important. A temperature node or the level sensor node above just send there measurements and don't care if someone uses them or not. This thinking is central. The node that originate an event should – if possible - know as little as possible about how the event it sends out will be used. This make the system very flexible.

A software package called VSCP & Friends is available to support VSCP users. This package can be downloaded and used for free and contain a lot of application and code. Everything is available both for Windows and Linux based systems.

First and possibly most important it contain the VSCP daemon. This is a server software that makes it possible to control several VSCP segments over the Internet.

The server expose a secure Internet interface and makes it possible to add drivers for segments of nodes or special equipment. A driver can communicate with the server using the CANAL interface for a Level I driver and the TCP/IP interface for a Level II driver.

CANAL stands for CAN Abstraction Layer and was initially developed as a software layer between application software and CAN equipment. For the VSCP it is not limited to interface CAN equipment but CAN drivers for most CAN adapters such as PEAK, IXXAT, PORT etc is included in the package as many CAN users use the system.

A lot of code is available that confirms to the CANAL interface. This same code can be used to communicate directly to a device that use the CANAL driver as can be used to talk to the daemon. This makes, among many other advantages, it easy to build simulated systems that use the same code base as the resulting system.

The daemon can do a lot more such as remotely replace/install drivers, remotely handle users and permissions, set up and handle an internal decision matrix to set up a self contained control system etc.

VSCP Works is a client application that is included in the package. This application can be used to send/receive VSCP events to/from every segment/device that export a CANAL interface and also talk to a remote VSCP daemon. VSCP Works can be used to investigate register space on any VSCP node and will also have support for remote firmware upgrade.

Server and client application is released under the GPL license. Libraries and classes is released under a modified LGPL license that make sure they can be used in proprietary projects.

Maybe the most important aspect of the VSCP & Friends package is that it can be used as an abstraction for interfacing other technologies and protocols. One just need to build a driver that translate the systems functionality to/from VSCP events and then install this driver for the VSCP daemon and then remote control functionality, software interface etc is directly available.

This way one application interface can be constructed to control several technologies using different protocols. One can compare this to the situation for printers before windows was announced. Each application needed to distribute a stack of disks with printer drivers. Windows ended this by introducing the printer API abstraction for printers. VSCP & Friends does the same for SECO (SEensor/COntrol) devices .

A web interface named OHAS is under development that will make it possible to build dynamic control interfaces with drag and drop technology. Summary

VSCP makes it easy and very cost effective to build systems with distributed intelligence. The protocol is placed in the Public Domain so it is therefore free for anyone to use and modify to there own needs. VSCP can be used all the way from the application down to the device but it can also be used as an abstraction to other technologies so one application can be written that transparently use several different technologies..

More information and downloads is available at http://www.vscp.org