The world is «many», not «one», and it will always will be that way. Just as different cars drive on the same side of the road and adhere to the same rules, protocols and solutions in IoT and M2M must come to understandings that make them work beside each other and together. What we see today is efforts on standardizing the «roads» while we really need to standardize on how we «travel» on them. This is really no different then what HTML did for hypertext in the past and which made the world wide web a success. To take an example a temperature sent from a device must always be understood by a receiving device to be useful for it, which means it's coding and its unit must be coded in a standard way. Obvious to us all maybe, but not something the IoT/M2M standardizing groups work with today. VSCP have solution for this and for device discovery, uniform configuration, self contained and serverless functionality, firmware updates and is free and open and will stay that way. It works equally well if communication is through a cable or over the air and it makes sure that the sender and the receiver understands each other. In this presentation, Ake will pinpoint the problems and the trends and present one possible solution to the problem. Åke Hedman, Maintainer, VSCP | Founder, Paradise of the Frog

1. IoT with the best
Paris 2016-01-16
VSCP
Åke Hedman
Maintainer VSCP (Very Simple Control Protocol)
Founder Paradise of the Frog

2. Disclaimer
VSCP is not seeking world domination
Does not handle the 15 second rule well
Stay foolish – Be hungry

3. State of things
● Vertical, vertical, vertical, vertical...
● A lot of transport mechanisms.
● A number of standardization efforts (AllSeen
alliance, IPSO alliance, Tread Group, Eclipse
IoT, etc etc etc )
● IoT???????

4. IoT - What is it?
● INTERNET of THINGS
● INTERNET = INTER + NET
● THINGS
● Not just wireless, not just protocol A, not just...
● Connecting nets together.
● Intranet of things
● In the end its just about Connecting things together
● Enables Big Data mining.

5. Problems

6. Problems
● We must know that a device is there and what it can
do (Discovery).
● Devices from different manufacturers must understand
each other (Message format).
● We need a common way to tell devices what to do
(Configuration).
● We need a common way to update firmware of the
devices (Firmware update).
● SECURITY!!!!

7. Real world
Messages
Measurements

8. Measurements
42

9. Measurements
● “Answer to the Ultimate Question of Life, the
Universe, and Everything.” - The Hitchhiker's
Guide to the Galaxy by Douglas Adams
● The approximate length of a marathon in
kilometres
● The atomic number for Molybdenum
● ...or other things.

10. Measurements
● It's still 42 if sent over a MQTT channel.
● ...or in an UDP packet.
● ...or sent over a highly secured link.
● ...or sent over a wireless mesh network.
● ...or sent from a mainframe.
● ...or received by the smartest person/machine
in the universe.

11. Measurement
● So the conclusion is that the receiver has to
know that “42” is a temperature measurement
for the value to be useful at that receiving end.
● So we have to add “information” to the value.

12. Measurements
So if we know it's a temperature measurement?

13. Measurements
Typically solved as
by JSON
{
“measurement”: {
“type”: “temperature”,
“value”: 42,
}
}
or in XML
<measurement>
<value type=”temperature”>42</value>
</measurement>

14. Measurements
Still not perfect

15. Measurements
Typically solved as
by JSON
{
“measurement”: {
“type”: “temperature”,
“unit”: “kelvin”,
“value”: 42,
}
}
or in XML
<measurement>
<value type=”temperature” unit=”kelvin”>42</value>
</measurement>

16. Measurement
● Wasteful.
● Over air/cable.
● In RAM of low end device.
● On resources on low end device.

17. Measurements - VSCP
Typically solved as
in JSON
{
“measurement”: {
“head”:0,
“class”: 10,
“type”: 6,
“unit”: 0,
“sensorindex”: 0
“coding”:
“value”: 42,
}
}
in XML
<measurement head=”0” class=”10” type=”6” >
<value type=”temperature” unit=”kelvin”>42</value>
</measurement>

18. Measurements
● SI system.
● Well defined data.
● Compare with web.

19. On/Off
● Same thing.
● Some send literal “on” and “off”
● Others send literal/binary “0” and “1”
● Even others send “‫”في‬ and “‫”بعيدا‬
●
Or even “ 上の” and “ オフ”
● Hard to know what a device is expecting and
equally hard to understand what to do when
received.

20. VSCP way
Start with the lowest level

21. How VSCP does it
● Lowest common denominator is the CAN frame
● CAN packet size (8-bytes) .
● Binary

22. How VSCP does it
● Two levels. Level I and Level II. Mainly differ in
packet size.
● What other calls messages we call EVENTS
● VSCP is an application level protocol.
● On,off,TurnOn,TurnOff etc etc etc etc has a well
defined format.
● Events identified by a class (sort of group) and a
type. Temperature for example is
CLASS1.MEASUREMENT, Type=6

23. How VSCP does it
● VSCP Level I have a maximum of 512 classes
defined (alarms, measurements, information,
protocol,.......growing) each with 255 possible
types.
● VSCP Level II have a maximum of 65536
classes and where each can have 65535 types.

24. Turning on “something” in VSCP
● So turning on “something” in VSCP is done by sending
a CLASS1.CONTROL, Type=5 (TurnOn) event.
● Most often the device(s) that is turned on reply with
CLASS1.INFORMATION, Type=3 (On) Event(s).
● Similar CLASS1.CONTROL, Type=6 (TurnOff) event
turn “something” off and expects
CLASS1.INFORMATION, Type=4 (Off) Event(s).

25. Requires content of Level 1 event
● Flags: 7 bits (priority, hardcoded).
● VSCP Class: 9-bits.
● VSCP Type: 8-bits
● Nickname: 8/16/(24/32)-bits.
● Data: 0-8 bytes.

26. CAN4VSCP
● 32-bit id.
● Nickname is 8-bits. Can be discovered or hard
coded.
● 0-8 data bytes.

27. Other events

28. TurnOn Event over CAN4VSCP
● 32-bit id containing priority, class,type and
nickname described here.
● VSCP-Class =30 (CLASS1.CONTROL)
● VSCP-Type=5 (TurnOn)
● Three data bytes
● Byte 0: User specified. Usually set to zero.
● Byte 1: Zone
● Byte 2: Subzone

29. But TurnOn can look like this to
in JSON
{
“vscpevent”: {
“priority”:0,
“vscpclass”: 10,
“vscptype”: 6,
“guid”: “”
“data”: {0,0,0}
}
}
in XML
<vscpevent priority=”0” vscpclass=”30” vscptype=”5” guid=”” data=”” />

30. General VSCP Properties
● Application level protocol.
● No server needed.
● Not addressed.
● Free.
● Open.
● KISS (Keep It Simple Stupid).

31. Discovery

32. Discovery
● How do we know things are available?
● Beacons
● Heart beats

33. How VSCP do it
● Every node send a heartbeat at least once a
minute.
● Possible to scan for nodes.
● When a node identify itself it itself contain the
key to its configuration and usage.

34. Configuration

35. Configuration
● We always need a way to tell things what to do
and how to do it before they become useful for
us.
● Pre Windows and HAL sometimes 30 diskettes
for drivers one for the application. HAL was the
thing that made it happen.
● Just as HAL abstracts hardware we need
abstractions for black boxes.

36. The black box

37. The black box

38. The black box
● And they all are all different inside.
● They (almost) always need a manual to
understand how to configure them.
● “Where is the manual...”
●

39. How VSCP do it

40. How does VSCP do it?
● The IC Circuit is a successful black box In the
real world.
● Scale well
● Can talk to other IC's
● Is configured with “switches” or registers.

41. Register Abstraction Model
● So a VSCP black box have a set of registers.
Standard registers. User registers.
● Every register is 8-bits wide.
● There is 128 registers (Standard registers)
reserved on every node that must be there.
● Level I: 128 * 65536 registers that the maker of
the device can use.
● Level II: 32-bit address pointer.

42. Register Abstraction Model –
Standard registers
● GUID – Globally unique id.
● Pointer to MDF (Module description file).
● Boot loader algorithm.
● Hardware version.
● Firmware version.
●

43. GUID
● GUID is a 128 bit globally unique id that identify
a unit.
● A nickname (8/16 bit) can be used on a local
bus to save bandwidth..
● GUID's can map to many other globally unique
id's. See Specification.
● GUID series can be requested for free from
guid@vscp.org

44. Module Description File (MDF)
● XML-file that describe the module.
● Normally fetched from an Internet location but can be fetched from the
device directly to.
● Defines registers and there content.
● Defines abstractions (high level data types).
● Define events sent by node and there content.
● Define actions the nodes decision matrix can generate.
● Defines setup wizards.
● Firmware update information.
● Points to contact info of maker, manual for device, firmware, pictures, is
multilingual and a lot more.

45. Abstractions
● Present register content as high level data types.
● bool
● string
● long
● float/double
● guid
● Etc etc.

46. Decision Matrix
● Optional.
● Configure what action a node should perform
when it receives an event.
● For example turn on relay one when a TurnOn-
event is received.

47. Decision Matrix
● Optional.
● Configure what action a node should perform
when it receives an event.
● For example turn on relay one when a TurnOn-
event is received.

48. Setup wizards
● A assisted guide to follow, to get a specific
functionality of a device, described in XML.
● Report temperature in degrees Fahrenheit
every minute and alarm me if temperature goes
over 77 degrees or below 32.
● Can be read and served by all UI's
(phones/PC's/tablets/browsers/applications/...)

49. Firmware update

50. Firmware update
● Standard algorithm.
● Device specific algorithms.
● Who can/is allowed to do it.
● Protect copying of products.

51. Implementation
● 2.5K overhead in flash.
● A few bytes of RAM
● Can be implemented alongside proprietary
solution.

52. Security
● SSL (TCP/IP)
● Aes (Multicast, raw ethernet, wireless)
● Other.

53. Multicast
● Used for discovery.
● Used to form subnets/groups.

54. Raw Ethernet
● No need for a tcp/ip stack.
● Very low on recources.
● Do normally not pass a router.

55. For the end user
● A node is discovered.
● Get MDF from it.
● Configure the node.
● Make it interact with other nodes.
● Use wizard to get help to set up a device to do
“something”.
● Same every time.

56. Tools
● The VSCP daemon
● VSCP Works
● VSCP Helper library
● Javascript library with HTML5 widgets (websocket)
● Firmware code for multiple platforms.
● Examples.
● Windows/Linux(Pi/Beaglebone)

57. The VSCP Daemon
● The VSCP “server”.
● TCP/IP interface. This interface is a superset of a general tcp/ip interface that
can be implemented by devices.
● Drivers for everything can be connected. Can be used to abstract non “VSCP
things” to look like they are “VSCP things”. Or the other way around. Many
driver available.
● Multicast interface.
● Advanced internal decision matrix.
● Built in webserver.
● Websocket interface
● REST interface (plain text/CSV/JSON/JSONP/XML).
● Soon built in MQTT and CoAP support.

58. VSCP Works
● Investigate what is happening on local or
remote bus.
● Interact with nodes.
● Discover nodes.
● Configure nodes.
● Load firmware into devices.
● And more...

59. VSCP Helper library
● C library for Windows/Linux
● Bindings for many programming tools available
or on the way.
● Many functions to handle VSCP related tasks.
● Can be used to connect to a remote VSCP
daemon in an easy way.

60. Javascript library
● Interface the efficient websocket interface.
● Buttons.
● Gauges.
● Diagrams
● Tables.

61. ...and more
● A lot more.

62. The End
● Contribute to the project (http://www.vscp.org)
● Vote for VSCP in Postscape IoT Open source award
http://iotawards.postscapes.com/2015-16/top-iot-open-s
ource-project
● Documentation is here http://vscp.org/#documentation
● Getting started guides is here
http://www.vscp.org/wiki/doku.php/howto/start
● Software is here
https://github.com/grodansparadis/vscp/releases
● Thanks