This talk will demonstrate the Internet of Things with Windows Azure. Using embedded devices that interact with Windows Azure cloud technologies, the Internet of Things ideology is enabled with scalable and resilient cloud systems that imbue the resource constrained devices with elastic, on-demand additional computing power that allows any network connected device to achieve amazing computational feats. The talk features three main device/cloud interactions: persisting unbounded data from sensors, communicating through resilient channels and interacting directly with the Windows Azure cloud to provision and control cloud based infrastructure.
7. Device Classifications
Desktop Desktop PC and Laptops
Background processes
User interactions
Background processes
Mobile Push notifications requiring Server
contexts
Location sensitive data
Nike+
Embedded
Intelligent Housing
RFID
11. How does Windows Azure Help Embedded?
Compute provisioned on
Scalable Resource demand
Storage into 100s TBs easily
Geo-locatable
Mobile Services
Infrastructure Services
Media Services
HPC and Big Data
Windows Azure Storage
Architectures
Windows Azure Service Bus
Service Management API
12. This is no Windows Azure Client for
embedded devices. We will have to write our
own.
This integration is only possible if the platform is
truly open and device agnostic. There is no more
evident test of this than consuming and interacting
with Windows Azure from a device which does not
have an operating system.
18. Development, Devices, Delivery
Write in C# or Visual Basic (recent) Open Source Hardware
Use Visual Studio (Express inc) Arduino layouts
Deploy and debug via USB Custom NETMF boards
Debugging WORKS! Breakpoints, Design your own
immediates, watches etc Dotnet Gadgeteer /Netduino GO
When complete, publish your software to a firmware
and distribute to your hardware vendor for delivery
19. NETMF architecture
Who What
You User Code
Microsoft and
community
.net Framework classes
Device vendors
20.
21. Notice the class is standard C#
with typical namespaces.
There are additional using
statements for device specific
libraries.
The class looks almost
identical to a C# console app
– but without args[] on the
Main()
The AnalogInput class will
do most of our work, it takes
a hardware address.
We Read() to get a voltage –
and let whatever is on the pin
do the work of generating this.
22. This class uses an
OuputPort set to
communicate with the on
board LED of the Netduino.
We use the Write method to
send a binary (Digital) signal
to the output device, in this
case the on board LED.
We use familiar
System.Threading
namespace to control the
execution flow, in this case,
pausing for 200ms so that
the LED flashes changing
state 5 times a second
Web ApiNode.jsTime taken (in s)89.9541.65Requests per second1111.692400.89http://mikaelkoskinen.net/post/asp-net-web-api-node-benchmarks.aspxRather silly slide that shows that the number of devices interacting grows
A periodic example may be a greenhouse thermometer. The devices may be configured to report hourly, and with some careful control of clock cycles you could predict exactly when traffic will arrive at your services. Ideally in such a case you’d only provision compute resources at a certain time so that you aren’t overpaying for resources. This is a perfect cloud scenario.A frequent retrieval may be a fridge that wishes to show the news headlines – it has to frequently poll, and this constant growth gives a fast per unit growth pattern to the traffic. This growth pattern is unlike a human computer growth pattern where there are rarely constant usage on the client side.When a Device interacts with humans, a far less predictable usage pattern emerges – if a device responds to milk being taken from it (in order to report a reorder request) then it depends how quickly a user is drinking their milk! Very hard to predict.When devices are reporting periodically and growing fast, a differnet pattern emerges – a predictable burst pattern where there is never a true off state.
SPOT is Smart Personal Objects Technology .net for Devices, not compact!What if you could use .NET on really small devices?.NET Micro Framework is an open source platform that expands the power and versatility of .NET to the world of small embedded applications. Desktop programmers can harness their existing .NET knowledge base to bring complex embedded concepts to market on time (and under budget). Embedded Developers can tap into the massive productivity gains that have been seen on the Desktop..NET Micro Framework DevicesThe typical .NET Micro-Framework device has a 32 bit processor with or without a memory management unit (MMU) and could have as little as 64K of random-access memory (RAM). The .NET Micro Framework supports rich user experience and deep connectivity with other devices.Such devices include: consumer devices, consumer medical, home automation, industrial automation, automotive, sideshow devices / PC peripherals.Why put .NET on small devices?Up to now, embedded devices have been quite effectively created using mostly C and C++, why do we need C#? Certainly there will remain applicaitons for which C and C++ are the right technology to use but there are two reasons to consider using a managed environment for these devices. The first is the efficiency of creating and maintaining devices in managed code. Desktop developers who have made the move to managed code are typically converted by the productivitiy increases that they experience. With the increase in 32 bit processors and the need to support higher level functionality like a TCP/IP stacks, an environment like NETMF can make development much less expensive and risky.This is related to the other reason for .NET on small devices. More and more the devices that we are making are not isolated implementations but parts of much larger solutions that stretch to services and web sites and the cloud. With .NET, you have a programming model and tool chain that spans that entire solution space. There is less need to hire different staff and supporit different tools and operating systems for the various parts of the solutions.
The chart shows device capacity vs.net framework footprint
SHOW THE DEVICESdigital i/o features ● all 20 digital and analog pins: GPIO ● digital pins 0-1: UART 1 RX, TX ● digital pins 2-3: UART 2 RX, TX ● digital pins 5-6: PWM, PWM ● digital pins 7-8: UART 2 RTS, CTS ● digital pins 9-10: PWM, PWM ● digital pins 11-13: SPI MOSI, MISO, SPCK ● analog pins 4-5: I2C SDA, SCLnetworking ● ethernet: 10/100 mbps ● network stack: lwIPstorage ● micro sd (up to 2 GB) ● auto card detectpower ● input: 7.5 - 12.0 VDC or USB powered ● output: 5 VDC and 3.3 VDC regulated ● analog reference: 2.6 - 3.3 VDConly required when using ADC features ● max current: 8 mA per pindigital pins 2, 3, 7: 16 mA per pinanalog pins 0-3: 2 mA per pinmicrocontroller max current: 200 mA total ● digital i/o are 3.3 V--but 5 V tolerant
A GPIO port (hardware) can behave as either an input or an output port. Software is used to configure this, and the hardware is then configured to behave in the correct way.