1957: The first municipal computer (Norwich, UK)
Just one of 21 cabinets making up the computer.
Jack Jansen, Steven Pemberton CWI Amsterdam
Just one of 21 cabinets making up the computer.
The first computer so cheap that they gave it away on the cover of a magazine
What do you think the relationship is between the speeds of the two computers?
What do you think the relationship is between the speeds of the two computers?
The Raspberry Pi is about one million times faster...
Which means: If they had run the Elliot 24 hours a day for 10 years, it would have done the amount of computing you can do on a Raspberry Pi Zero in about 5 minutes!
Elliot: £85K (1957) (£2M-7M in 2015 money)
Pi Zero: £4
Improvement: ½M-2M
Median take-home wage then:~ £250 (men), £125 (women)
Now: ~ £30000 (men), £25000 (women)
Improvement: 120-200
So the Raspberry Pi is:
A factor of a million million (billion for Europeans, trillion for Anglo-Saxons).
A terabyte is a million million bytes: nowadays we talk in terms of very large numbers.
Want to guess how long a million million seconds is?
Is 30,000 years...
In other words, a really big number...
In fact a million million times improvement is about what you would expect from Moore's Law over 58 years.
Except: the Raspberry Pi is two million times smaller as well, so it is much better than even that.
This talk shares insights from an on-going project coordinating data from Internet of Things (IoT) devices, and using a declarative interface to that data.
REST (REpresentational State Transfer) is the architectural basis of the web. As Wikipedia points out “REST’s coordinated set of constraints, applied to the design of components in a distributed hypermedia system, can lead to a higher-performing and more maintainable software architecture.” So how can you apply the same ideas to the Internet of Things?
The Internet of Things is driven by many tiny low-powered processors that produce data in a variety of different formats, and produce the data in different ways, sometimes on demand (such as thermostats), sometimes by pushing it (such as presence detectors). Traditionally, applications have to be a mash up of accesses to devices and formats. To use the data in a cohesive application, the data has to be collected and integrated; this allows very low demands to be put on the devices themselves.
This project places a thin REST-layer around a diverse collection of Internet of Things devices, hiding the data-format and data-access differences, and updating the devices automatically as needed; this then allows a REST-style declarative interface to access and control the devices without having to worry about the variety of device-interfaces and formats.
Thousands of cheap, tiny devices, with "low" processing power.
Various data formats: text, xml, JSON, ...
Various access methods: on demand, push, in the cloud, ...
Turning the data into applications means programming; and dealing with lots of fiddly detail.
Twenty years ago a typical petrol station had embedded devices in the pumps, the storage tanks, the tills, the vending machines, and these were centrally accessible and controllable.
What is new is the ubiquity, the diversity, the flexibility, the cheapness.
And the S stands for security...
You may have heard of the recent case of a Casino being hacked via its fish tank...
Or of a car being hacked via its radio...
IoT is introducing lots of problems:
Ownership: Who owns the data?
Privacy: Who can see the data?
Security: Who is allowed to do anything with the data?
Creating a system that allows us to
REST (REpresentational State Transfer) is the architectural basis of the web. As Wikipedia says:
“REST’s coordinated set of constraints, applied to the design of components in a distributed hypermedia system, can lead to a higher-performing and more maintainable software architecture.”
In other projects we actually have proof of this claim: it can save around an order of magnitude in time and costs.
Our system uses a REST-style declarative interface to access and control the devices with no worry about the variety of device-interfaces and formats.
Declarative: The square root of a number n is the number r such that r × r = n.
Declarative: The square root of a number n is the number r such that r × r = n.
Procedural:
function f a:
{
x ← a
x' ← (a + 1) ÷ 2
epsilon ← 1.19209290e-07
while abs(x − x') > epsilon × x:
{
x ← x'
x' ← ((a ÷ x') + x') ÷ 2
}
return x'
}
Uses XML.
Repository is kept up-to-date with the devices bi-directionally: if the device changes, the repository is updated to match, and if the data in the repository is changed, the device is updated.
For instance: change the data value for the lights from 0 to 1, and the lights go on.
Thin functional layer around the repository communicates with the devices.
Plug-ins for devices and formats are responsible for knowing how to access the data from the devices:
One or more instances of the system can intercommunicate.
Events can be listened for and reacted to within the repository.
The fundamental event is value changed, which allows event listeners to react.
Other events include timers, and changes in the structure of the repository.
Events travel up the data hierarchy, allowing listening at a collection level rather than an individual value level.
Constraints and relationships specify how values relate to each other.
Ensures that values that depend on each other are automatically updated (in the process possibly changing the state of the related devices).
For instance there is a single value: lights.
When that value is 1, the lights are on, and when it is 0, the lights are off.
It is a two-way relationship: to turn the lights off, you just set the value to 0; if anything changes the value to 1 they go on again.
There is another value: Is jack home? (This is not two-way ;-) )
There are two ways to influence a value in the repository. One is equality "=", which ensures that the equality is always true:
lights = jack-home
However this means that whenever he is home the lights are on, and whenever he isn't home, the lights are off. Upsetting if he wants to sleep.
The other method is "←". This changes the value only when the value of the expression changes.
lights ← jack-home
This ensures the lights are on when he arrives home (they may have already been on), and ensures they are off when he leaves.
Since this only happens at events, it allows an override. For instance a switch on the wall also has a 0/1 value in the repository, and this can be can be bound to the value of the lights:
lights ← switch
Note how switches are no longer hard-wired to their function.
For the purpose of this talk, we treat jack-home as if it were
a single standalone value.
In reality it is part of a structured value, such as
home/people/person[name="Jack"]/presentYou don't want the lights to come on when it is already light, but you can have a sensor that detects whether it is dark or not, with an affiliated value in the store:
lights ← jack-home & dark
This
Note that you could combine the statements into a single one using equality:
lights = (jack-home & dark) or switch
However, the separate statements allow a certain degree of modularity, since, for instance, if you decide to reassign the switch to another purpose, the other statements continue to work.
He carries a mobile phone, that connects to the wifi, maybe a bluetooth watch that a sensor can see, and he has a laptop that also connects. These all get recorded in the repository (along with other details such as IP address assigned). So we could say
jack-home = jack-phone & jack-watch & jack-laptop
However, sometimes he switches his laptop off. How about:
jack-home = jack-phone or jack-watch or jack-laptop
Well, he might accidently leave his phone at home. Then we use
jack-home = count(jack-phone, jack-watch, jack-laptop) > 1
Jack doesn't live alone though. So there is a value that records if anyone we know is home:
someone-home = jack-home or jill-home or jim-home
We can let the central heating automatically activate depending on whether someone is home or not:
heating = someone-home
Of course, the required temperature of the heating is also a value in the repository, as well as the actual temperature, so unlike the lights example, we don't need an extra override.
There is nothing you can do if there is a powercut and no backup power supply, but you don't want to depend on the wifi to be running, or the domain name server to be up, in order to be able to get in to your house.
Therefore individual devices must have as few dependencies on the general infrastructure as possible.
So our system runs on the local devices as well: several copies of the system distributed, and communicating with each other.
There is no requirement that a central version of the system is up and running.
None of the data is visible outside the system, unless explicitly revealed to someone.
Jack can expose that he is home to someone, without revealing details such as his phone identity.
This means the janitor can't also determine if Jack is at the bar down the road.
Since the architecture is primarily state-based, with events a side-effect, in effect it is the reverse of IFTTT-style systems that are quite common nowadays for IoT solutions.
Fine-grained access control in an event-based system like IFTTT would be more difficult, because there would basically have to be access rules for every event/trigger.
State-based gives you:
With this system it can be done on the basis of subtrees.
Data is stored in XML elements and attributes are used for system meta-data, part of which is information about access.
Exact mechanism is still being investigated.
Current preference is for Capabilities [CAP], where to access a part of the structure you have to be in possession of a token.
Since all actions are now controlled by changing data, all we need is a straightforward way to access and change data.
Luckily we have XForms, which has more or less the same structure as the system: a collection of (XML) data, events, and constraints.
On top of that, XForms has a method of binding user interface controls to the data for displaying and updating the data.
See for instance the talk "XML Interfaces to the Internet of Things" (and the paper that it is based on, also available in HTML).
Early stages yet.
We have a system that insulates us from the details of the different devices, how to drive them and the format of the data.
Runs on Raspberry Pi.
It gives us a very simple yet powerful mechanism for reading and controlling devices.
We currently have systems running 24/7 at three locations.
You are welcome to play: https://github.com/cwi-dis/igor