This document discusses using Microsoft Orleans grains as software agents or "avatars" to represent physical IoT devices in the cloud. An example railway simulation app is described that uses grains to represent trains. Each train has a corresponding "physical train" device that can detect its proximity to stations and rails using Bluetooth beacons and communicates with its grain avatar using MQTT. The frontends use SignalR for the web UI and MQTT for machine-to-machine communication. Physical trains are programmed using .NET Micro Framework and detect beacons using BLE, with an MQTT/iBeacon gateway and feedback simulator implemented in Node-Red.

1. IoT & Microsoft Orleans
Software Agents living on cloud as Avatars for physical
devices living…in real world!
Lorenzo Maiorfi – Innovactive - MVP

2. Grains as Device «Avatars»
Mentally mapping a Grain (type) to a Device (type)
is easy, since:
• Both work in a parallel, asynchronous and independent
way
• Both interact by exchanging structured data by mean of
well-known channels, schemas, formats, messaging
patterns
• Both are replicated in many, many instances, each
producing and consuming an impressive amount of
messages
• Both maintain a persistent state, either in nature
(devices physical state) or through persistent storage
(grains)

3. Orleans Railway Sample
• Sample implements a fictitious railway network,
inspired by real-world systems
• Railway graph is made of nodes (Stations) and
directed edges (Rails), the latter featuring a traversal
cost (simulated by time needed to cross and
represented graphically by color scale: brownslow,
cyanfast)
• Each Train features a “buddy” Grain that represents its
“Avatar” living on cloud
• Sample leverages an external “notification engine”
that processes signals coming from Trains in order to
provide synthetic feedback coming from real-world
(i.e. telling Trains they’re near to a certain Station/Rail
after routing system sends them command to get
there as part of a end-to-end optimal path)

4. Orleans Railway Sample #2
In order to «validate» system with physical devices
we need «Physical Train» :
• Process commands received by its «avatar» Grain
• Raise notifications (through M2M front-end, not
Web one) toward its «avatar» Grain
• Interact with physical world!
• «feel» Stations/Rails proximity
• «move» along railway graph

5. How did we do it?
• Web front-end UI has been implemented with SignalR
(over OWIN) and plain HTML+JavaScript
• M2M front-end has been implemented as an MQTT
client (publishing move commands and subscribed to
proximity messages)
• Proximity detecting for «physical Trains» has been
implemented by BLE iBeacons
• «Physical Trains» device firmware has been
implemented with .NET Micro Framework (by mean of
M2Mqtt and NetMFBLE open projects)
• iBeacon/MQTT gateway, as well as «feedback»
simulator, has been implemented with Node-Red