An overall survey of IoT issues, what needs to considered before embarking on design and developing products for the Internet of things.

1. IoT: An Introduction and
Getting Started Session
Debasis Das
ECD Zone

2. For a successful technology, reality
must take precedence over public
relations, for Nature cannot be
fooled.
—Richard P. Feynman, Physicist
11/20/2015
Debasis Das
debasis@ecdzone.com
2

3. Top Level View of IoT
11/20/2015
Debasis Das
debasis@ecdzone.com
3
Sensors/sensor
networks
Actuators
Processor
Thing or an object
Cloud

4. Internet of Things
• This is an evolving technology, also known as
Internet of Everything.
• Evolved from what used to be known as M2M
• The industrial section of the applications are
being hailed as the 4th industrial revolution
11/20/2015
Debasis Das
debasis@ecdzone.com
4

5. Dimensions of the Complex IoT
Eco-system (by 2020)
• Sensors: 212 bn; location, motion, chemical,
light, heat, sound
• Devices: 50 bn: smartphones, wearables,
automobiles, domestic
• Networks: 2.5 bn, Blu-tooth, NFC, Wi-fi, etc.
connections accessing 4G/LTE networks
11/20/2015
Debasis Das
debasis@ecdzone.com
5

6. Dimensions of the Complex IoT
Eco-system (by 2020) – Cont’d
• APIs: 75%, fortune 1000 companies will offer
public APIs by end 2014, billing, mapping, social,
search, marketing, etc.
• APPs: 4.4 bn, number of app users by 2017, touch
interfaces, gesture tracking, augmented reality,
voice recognition, etc.
• Data:16 ExaBytes, mobile data traffic per month
by end 2014, user data, transaction data, field
data, inventory data, performance data, etc.
11/20/2015
Debasis Das
debasis@ecdzone.com
6

7. Gartner Study
• By 2020
– 25 billion devices are going to be connected
– Causing a $7 trillion opportunity for businesses
11/20/2015
Debasis Das
debasis@ecdzone.com
7

8. Industry 4.0 Opportunity
• IIoT could be $531 billion by 2020 through opportunities like
Connected asset management, connected worker and other never-
before opportunity that develops
• What customer may want
– Operational efficiency
– Move away from product oriented business focus to service oriented
focus
– Unconventional revenues
• From a recent presentation by Accenture
11/20/2015
Debasis Das
debasis@ecdzone.com
8

9. Structure of IoT
Services
Internet
Gateway
Wi-Fi, Mobile, DSL, Fiber
6LowPAN, Zigbee, RFID, NFC
Things- appliances, buildings, smart city systems
Sensors, Actuators
11/20/2015
Debasis Das
debasis@ecdzone.com
9

10. Technologies Involved in IoT
Applications
11/20/2015
Debasis Das
debasis@ecdzone.com
10
Application
OSS & BSS
Analytics Data Security BPM BRM
IoT Management Services
WAN (Wireless) WAN (Wireline))
RFID
Low power
wireless
Gateway functions
Sensors
LAN

11. Classes of Constrained Devices
Class RAM Flash Comments
Class 0 < 1 KB < 100 KB Devices use gateways to communicate, have
rudimentary communication capabilities only
Class 1 ~10 KB ~100 KB Devices use protocols designed for IoT, using
Constrained Application Protocols (CoAP). Can
interact with other devices without going through
a gateway.
Class 2 ~50 KB ~250 KB Devices use regular IP (IPv6) protocols and can
behave as regular network devices
11/20/2015
Debasis Das
debasis@ecdzone.com
11

12. Sensors & Actuators
• Sensors help measuring things and help decide what is
the current status of the environment to be controlled
• Actuators help actuate the controls that can change
these variables in the environment, when necessary
• The direction of control, the amount of control, the
time for which it has to be turned on, etc. are derived
from analyzing the sensory inputs. The analysis will be
carried out at a processor that can be at different
levels. Depending on the volume of data or the
complexity of the control scenario, resources in the
cloud could be used too.
11/20/2015
Debasis Das
debasis@ecdzone.com
12

13. Sensors
11/20/2015
Debasis Das
debasis@ecdzone.com
13

14. A Sensor Node (mote)
Courtesy Wikipedia
• A sensor node, also known as a mote (North America),
is a node in a sensor network that is capable of
performing some processing, gathering sensory
information and communicating with other connected
nodes in the network
• A wireless sensor network (WSN) (sometimes called
a wireless sensor and actor network WSAN) are
spatially distributed autonomous sensors
to monitor physical or environmental conditions such
as temperature, sound, pressure, etc. and to
cooperatively pass their data through the network to a
central location. The more modern networks are bi-
directional, also enabling control of sensor activity.
11/20/2015
Debasis Das
debasis@ecdzone.com
14

15. WSN/Mote example 1
11/20/2015
Debasis Das
debasis@ecdzone.com
15

16. Typical I/O Configuration of
Zolertia z1
11/20/2015
Debasis Das
debasis@ecdzone.com
16

17. Mote/WSN example 2
11/20/2015
Debasis Das
debasis@ecdzone.com
17

18. WSN/Mote example 3
11/20/2015
Debasis Das
debasis@ecdzone.com
18

19. Mote on a Chip
11/20/2015
Debasis Das
debasis@ecdzone.com
19

20. Sensor Network Characteristics
Courtesy Wikipedia
• The WSN is built of "nodes“; from a few to
several hundreds or even thousands, where each
node is connected to one (or sometimes several)
sensors.
• Each such sensor network node has typically
– A radio transceiver with an internal antenna or an
external one
– A Microcontroller for interfacing with the sensors and
an energy source, usually a battery or an embedded
form of energy harvesting
11/20/2015
Debasis Das
debasis@ecdzone.com
20

21. Sensor Network Characteristics-
cont’d
– The cost of sensor nodes is variable, ranging from a
few to hundreds of dollars, depending on the
complexity of the individual sensor nodes
– Size and cost constraints on sensor nodes result in
corresponding constraints on resources such as
energy, memory, computational speed and
communications bandwidth
– The topology of the WSNs can vary from a simple star
to an multi-hop mesh
– The propagation technique between the hops of the
network can be routing or flooding
11/20/2015
Debasis Das
debasis@ecdzone.com
21

22. Architecture of a Mote
11/20/2015
Debasis Das
debasis@ecdzone.com
22
Memory
Power
Supply
unit
Micro-
processor
Sensor 2
Sensor 1
ADC
Transceiver

23. Multi-hop Sensor Network
Architecture
11/20/2015
Debasis Das
debasis@ecdzone.com
23

24. WSN Hardware
• A WSN has a low cost and small/tiny in size
• Inherent to sensor network adoption is the use of
low power methods for radio communication and
data acquisition.
• A WSN usually communicates with a local area
network or wide area network through a
gateway. The Gateway acts as a bridge between
the WSN and the other network
• This enables data to be stored and processed by
devices with more resources in a remote server
for example
11/20/2015
Debasis Das
debasis@ecdzone.com
24

25. WSN Software
• WSNs may be deployed in large numbers in various
environments, including remote and hostile regions,
where ad hoc communications are a key component.
Usually energy availability is constrained.
• Algorithms and protocols need to address the following
issues
– Increased lifespan
– Robustness and fault tolerance
– Self-configuration
• To conserve power, wireless sensor nodes normally
power off both the radio transmitter and the radio
receiver when not in use in a sleep mode often
11/20/2015
Debasis Das
debasis@ecdzone.com
25

26. WSN OS
• These are typically less complex than general-purpose
operating systems.
• Strongly resemble embedded systems
– These networks are typically deployed in a specific situation
than a general purpose use
– Need for low costs and low power dictates low-power
microcontrollers and thus ruling out mechanisms such as virtual
memory
• Embedded operating systems such as eCos or uC/OS could
be used
• Tiny OS is one of the first operating systems specifically
designed for wireless sensor networks. TinyOS has event
driven programming rather than multi-threading
11/20/2015
Debasis Das
debasis@ecdzone.com
26

27. WSN OS – cont’d
• TinyOS programs are composed of event
handlers and tasks that run-to-completion. When an
external event occurs, such as an incoming data packet
or a sensor reading, TinyOS signals the appropriate
event handler to handle the event. Event handlers can
post tasks that are scheduled by the TinyOS kernel
some time later.
• LiteOS is a more recent OS for wireless sensor
networks, which provides UNIX-like abstraction and
support for the C programming language.
• Contiki is an OS supports C and communication
advances like the 6LowPAN and Protothreads
11/20/2015
Debasis Das
debasis@ecdzone.com
27

28. Online Collaborative Sensor Data
Management Platforms
• Online collaborative sensor data management
platforms are on-line database services that allow
sensor owners to register and connect their devices to
feed data into an online database for storage.
• Developers are able to access the database and build
applications
• Xively and Wikisensing are examples
• These platforms simplify online collaboration between
users over diverse data sets
11/20/2015
Debasis Das
debasis@ecdzone.com
28

29. Data Management Platforms-Cont’d
• Datasets may range from energy and environment data to that
collected from transport services.
• Other services include allowing developers to embed real-time
graphs & widgets in websites; analyze and process historical data
pulled from the data feeds; send real-time alerts from any data-
stream to control scripts, devices and environments.
• The architecture of the Wikisensing lets users to include APIs and
interfaces for online collaborators, a middleware containing the
business logic needed for the sensor data management and
processing and a storage model suitable for the efficient storage
and retrieval of large volumes of data.
11/20/2015
Debasis Das
debasis@ecdzone.com
29

30. Xively-What It Can Do
• Create innovative connected objects using any
software/hardware combination
• Free, open and supported libraries are provided along
with tutorials and documentation to allow you to
connect to Xively using the hardware you want and the
languages you know.
• New hardware platforms are being added from a
variety of vendors.
• The libraries leverage standards-based API over MQTT,
WebSockets and HTTP to make connecting to the
Internet of Things simple, intuitive and fast.
11/20/2015
Debasis Das
debasis@ecdzone.com
30

31. Xively Connectivity
11/20/2015
Debasis Das
debasis@ecdzone.com
31
Hardware
Actuators Sensors Gateways

32. Xively Capabilities
• Connect
– IoT connectivity needs to be fast, secure and scalable. Xively
connects millions of devices
– You can control access for every person, application, or thing
trying to access your IoT data and plug directly into cloud-based
services your business departments rely on for daily workflows.
• Manage
– Allows capturing, managing and interpreting business
information
– Xively manages connected product business in one location by
providing standard methods for defining and managing
connected device users, employees, customers, partners and
their data.
11/20/2015
Debasis Das
debasis@ecdzone.com
32

33. Xively Capabilities-Cont’d
• Engage
– IoT enabled devices are making support and
engagement with customers more satisfying, efficient
and instant
– Xively provides a single interface for your real-time
product deployment lifecycle as well as product usage
and health
– It is then possible for the sales and marketing teams
to identify cross-sell and up-sell opportunities
– Service teams can remotely access and fix connected
products in real-time
11/20/2015
Debasis Das
debasis@ecdzone.com
33

34. Wikisensing
• WikiSensing is a sensor data management
platform
• Developed by the Discovery Sciences Group,
Department of computing, Imperial College,
London
• WikiSensing runs on top of IC Cloud, the
group's cloud computing infrastructure.
11/20/2015
Debasis Das
debasis@ecdzone.com
34

35. Wikisensing – API Capabilities
• A set of RESTful web services, and makes use of the POST, GET and
DELETE methods of the HTTP protocol.
• A user first needs to register to the platform and get a unique
service API key to be able to send data
• Then the user can register new sensors (and their metadata) and
add data to sensors that are under his/her service key.
• To retrieve and query data a user must use service keys. Sensors
that are public have their service key prefixed with Public_ and can
be retrieved using the API
• Users can use the API to query the sensor data of a sensor to get
the latest data, data submitted after a particular timestamp, and
data that matches specific values in one or two fields.
• A user can delete their sensors and their data using the
corresponding web service.
11/20/2015
Debasis Das
debasis@ecdzone.com
35

36. Wikisensing – cont’d
• Sample Code is available for
– Test suite source code in C#
– Script for getting data from Wikisensing in Python
• Sample Application is available for
– viewing a live deployment of a node sensor grid
monitoring office temperature, humidity and lighting
• Data Formats
– Wikisensing accepts data in XML or JSON formats. Sample
for XML and JSON requests and responses for each
function of the web service API is provided
– The content of a request must match the required
structure of the corresponding XML or JSON file.
11/20/2015
Debasis Das
debasis@ecdzone.com
36

37. Simulation of WSNs
• Agent-based modeling and simulation allows
the simulation of complex behavior of wireless
sensors (such as flocking)
• Network simulators like OPNET, NetSim and
used to simulate a wireless sensor network
• Free source Cooja is another tool that lets a
WSN be simulated
11/20/2015
Debasis Das
debasis@ecdzone.com
37

38. Processors
11/20/2015
Debasis Das
debasis@ecdzone.com
38

39. Development Tools
11/20/2015
Debasis Das
debasis@ecdzone.com
39

40. Raspberry Pi
11/20/2015
Debasis Das
debasis@ecdzone.com
40

41. Raspberry Pi Options
• Standard models for use as development
systems
• For developing embedded applications.
Includes Compute IO board, compute
module, display and camera adapter
• Customized boards in large scale can be
ordered for production use
11/20/2015
Debasis Das
debasis@ecdzone.com
41

42. Arduino YUN
(Arduino for IoT applications)
11/20/2015
Debasis Das
debasis@ecdzone.com
42

43. Arduino Options
• Free source hardware, can be replicated at will
for production needs
• Can be combined with other boards to
configure a system for specific use
• Free source software, Linux based ones, are
available.
11/20/2015
Debasis Das
debasis@ecdzone.com
43

44. Intel Galileo
11/20/2015
Debasis Das
debasis@ecdzone.com
44

45. Galileo Options
• Offers a development kit
• Galileo development kit
• Grove sensor kit
• License to Wind River Intelligent device
Platform XT
– Software support for development, integration
and deployment of IoT gateways
– Provides connectivity, management and security
11/20/2015
Debasis Das
debasis@ecdzone.com
45

46. Connectivity
• A range of networking options that can save
development time & cost
• Validated and flexible firmware provides an
extensive network of connectivity choices.
PAN, LAN, and WAN network accesses as well
as a wide range of modem support
11/20/2015
Debasis Das
debasis@ecdzone.com
46

47. Management Features
• Platform customization capabilities available.
Helps stretch the product life and uptime,
helps reduce development time
• Long-term secure remote manageability
features help simplify deployment,
maintenance, and management of remote
devices.
11/20/2015
Debasis Das
debasis@ecdzone.com
47

48. Security features
• Protection for critical data across your device
network
• Secure image, data, and management is
supported
• Encrypted communication is provided
between the cloud-based console and devices.
• Device resources management limits exposure
to untrusted applications.
11/20/2015
Debasis Das
debasis@ecdzone.com
48

49. Whole Range of Microprocessors
• 8 bit to 64 bit architectures
• Whole range of power consumption ratings
• Custom hardware design and development
takes skills & experience
11/20/2015
Debasis Das
debasis@ecdzone.com
49

50. A Looming Problem
• Deployment of solutions using large number of
connected devices, that uses this tiny processors
is set to blow up
• A large number of skilled resources will be
required
• Trying to take care of all the support functions
that are fairly standard could a tough demand
• It’ll be nice if things like GUIs, network
connectivity, touch sensor and other device
configurations could be taken care of by the
development tools in the form of a platform
11/20/2015
Debasis Das
debasis@ecdzone.com
50

51. Mobile Development Scenario
• Developers are able to concentrate on the app
logic and implementation, not the routine stuff
like establishing a call etc.
• These apps are at a higher level and need not
concern with hardware nitty gritty
• Microprocessor based development can take a
page out of that scenario and get the
development work done on platforms like the
mobile situation
• This has started happening
11/20/2015
Debasis Das
debasis@ecdzone.com
51

52. Synergy Development Platform
• Synergy was released by Renesas in Oct this
year
• Supports a family of processors, so that when
an upgraded member is used, the firmware
upgrade is minimal
• Developers need not be skilled in every
specific device to be used.
11/20/2015
Debasis Das
debasis@ecdzone.com
52

53. Synergy Architecture
(Courtesy Renesas)
11/20/2015
Debasis Das
debasis@ecdzone.com
53

54. SysDK Platform from Mentor Graphics
• Platform development solutions help close the
gap between design complexity and available
design talent
• Mentor’s customizable gateway is offered as the
SysDK product that take care of end to end
solution development
• Incudes a hardware reference design and
associated software that support bidirectional
wireless communication is offered
• Communicates with motes on one edge and the
cloud on the other edge
11/20/2015
Debasis Das
debasis@ecdzone.com
54

55. SysDK Block Diagram
(Courtesy mentor Graphics)
11/20/2015
Debasis Das
debasis@ecdzone.com
55

56. SysDK Resources
• Freescale’s iMX6 (ARM Cortex-A9 based)
processor
• Etherenet, 802.15.4, Wi-Fi, BLE
• Mentor’s Nucleus RTOS/ Mentor’s embedded
Linux
• Security based on ARM’s “TrustZone” security
architecture at the device level alongwith Icon
Lab’s Floodgate for McAfee’s EPO (ePolicy
Orchastrator) at the RTOS and Enterprise level
11/20/2015
Debasis Das
debasis@ecdzone.com
56

57. SysDK Hardware Reference Design
11/20/2015
Debasis Das
debasis@ecdzone.com
57

58. End-to-End Security
11/20/2015
Debasis Das
debasis@ecdzone.com
58

59. Intel’s IoT Platform
• Development support provided include
– Security: Helps deliver trusted data with a tight
integration of hardware- and software-based security
– Interoperability: Utilize technologies that seamlessly
communicate to one another, help accelerate time to
market, and reduce the cost of deploying and
maintaining IoT solutions.
– Scalability: Whole range of processor capability
provided to scale performance based on application
need (Quark, Xeon and others)
– Manageability: Helps adavnced data management and
analytics from sensor to datacenter.
11/20/2015
Debasis Das
debasis@ecdzone.com
59

60. Wind River Edge Management
• It connects machines and devices
• Helps manage and collect machine generated
data
• Customers can easily aggregate data off the edge
• Can help offer business intelligence
– To protect investments
– Generate new revenue streams
– Maximize existing infrastructure
– Improve business processes.
11/20/2015
Debasis Das
debasis@ecdzone.com
60

61. Communications
(A review, reference DevNation, Jun 21-25, Boston, MA, USA
IoT Protocols round-up- Brian Ashburn)
11/20/2015
Debasis Das
debasis@ecdzone.com
61

62. Type of Communications
• M2M or machine to machine
• Machine to server
• Server to server
• Humans to Machine
11/20/2015
Debasis Das
debasis@ecdzone.com
62

63. Protocols
• So you are going to need different kinds of
protocols
• Attempt is to keep overheads down as much
as possible
• Developers need to take a call on what’s going
to survive and become popular
11/20/2015
Debasis Das
debasis@ecdzone.com
63

64. An Example Protocol
• A MQTT message format has a fixed header of
2 bytes,
– Byte 1defiunes message type and flags
– Byte 2 contains information on the remaining
message length
• A variable header may/may not be included
after the fixed header
• The payload will contain application data or
protocol specific information
11/20/2015
Debasis Das
debasis@ecdzone.com
64

65. HTTP/REST
• These protocols are based on HTTP/REST as
the base on which they are built
• Many systems provide frameworks to support
REST
• Language independent
• Obviously this support will preclude many full
messaging support
11/20/2015
Debasis Das
debasis@ecdzone.com
65

66. Concern of users
11/20/2015
Debasis Das
debasis@ecdzone.com
66
• Communications makes sure the whole thing
works!
• Best protocol is decided by
– Available communication pathways
– Processing power available on device
– What server can support

67. MQTT
11/20/2015
Debasis Das
debasis@ecdzone.com
67
• Open standard
• It is lightweight
• Good QoS definitions are available
• Persistent message store
• No labelling of content type is available

68. MQTT-SN
11/20/2015
Debasis Das
debasis@ecdzone.com
68
• TCP-less protocol
• Intended for sensor networks
• Improvements over MQTT in terms of error
messages and concise message header
• Complex connection mechanism is mandated
(even if the network is just 2 nodes)
• Stateful endpoints need be used
• Handling of restarts by Brokers or clients not
defined
• Few platforms support it yet

69. CoAP
11/20/2015
Debasis Das
debasis@ecdzone.com
69
• Open standard based on HTTP/REST
• Suited for resource constrained devices
• Communication is based on UDP
• Primarily a point to point protocol

70. AMQP
11/20/2015
Debasis Das
debasis@ecdzone.com
70
• Full featured message protocol
• Supports routing
• Data type encoding defined
• Supports queues and other message patterns
• Quite a heavyweight protocol and better suited
to server to server communications

71. Why Contiki
• Open Source software : can be used for
commercial as well as non-commercial projects
• It runs on a range of low-power wireless devices
• Incorporates Internet standard communication
protocols like the RPL, CoAP, 6LowPAN
• Rapid development: Writing software in standard
C and the ability to emulate sensor network in
Cooja makes for fast development
• Commercial as well as community support
available
11/20/2015
Debasis Das
debasis@ecdzone.com
71

72. Contiki Features
• Designed for tiny system, allocates memory
through multiple mechanisms
– memb: memory block allocation, mmem: managed
memory allocation and malloc: the standard C
memory allocation method
• Full IPv6 networking support: UDP, TCP and HTTP
as well as low power standards 6LowPAN, CoAP
and RPL
• Power awareness: Has mechanisms for
estimating power consumption and where the
power gets spent
11/20/2015
Debasis Das
debasis@ecdzone.com
72

73. Features- Cont’d
• Dynamic module loading and run-time linking
• Many programming example are provided
• Cooja: creates a simulation environment,
helpful in development and debug situation
• Supports sleepy routers, routers or relay
nodes
• Wide ranging hardware platforms supported
that include 8051, MSP 430, AVR and ARM
devices
11/20/2015
Debasis Das
debasis@ecdzone.com
73

74. Instant Contiki
• Entire development system that can be
downloaded straight
• It is a UBUNTU Linux virtual machine, runs in
VMWare player + development tools,
compilers and simulators
• Download the instant version, install the
VMWare player and boot up the instant
Contiki
11/20/2015
Debasis Das
debasis@ecdzone.com
74

75. The Development Process
11/20/2015
Debasis Das
debasis@ecdzone.com
75
Download
Instant Contiki
Install
VM Player
Boot
Ubuntu
Log-in
Start
Cooja
Open a
Terminal window
Specify Application C
source file
Find Contiki
Application
Create new mote
tupes
Add motes
In the simulation
Set simulation
options
Create a
simulation
Start
simulation
Compile Contiki
And application
Create a
Mote type
Add the
motes
Add motes to
simulation
Simulation
Done!

76. Contiki on The Target Hardware
• Connect hardware (Zolertia Z1 mote) connected via USB of
the development PC. Enable the mote through VMWare
player (Removable Devices menu)
• Open a terminal and cd to “examples” directory
• Compile Contiki + z1 example
– make TARGET=z1 hello world
• make TARGET=z1 savetarget, saves the choice for future
compilations
• make hello-world.upload will upload to code to the target
• Make the serial port on the mote ready to display output
with
– make login
11/20/2015
Debasis Das
debasis@ecdzone.com
76

77. Contiki on The Target Hardware –
Cont’d
• If you rest the button on the mote, you should see
– Rime started with address 1.1
– MAC 01:01: 00:00:00:00:00:00 Contiki-2.6 started. Node id
is set to 257.
– CSMAContikiMAC, channel check rate 8 Hz, radio channel
26
– Starting “Hello world process”
– Hello, world
• If you upload broadcast-example from
contiki/examples/ipv6/simple-udp-rpl/ to two devices,
it will be possible to observe them sending low-power
IPv6/UDP message to each other
11/20/2015
Debasis Das
debasis@ecdzone.com
77

78. RIOT
• An OS designed specifically for the Internet of
things
• Well suited for lightweight (1.5 KB RAM)
sensor with 8 bit uC devices to 32 bit devices
with sophisticated hardware
• Designed for hardware with minimal
resources but easy to develop
• Programming in C, C++
• Multi-threading and real-time features
11/20/2015
Debasis Das
debasis@ecdzone.com
78

79. RIOT Design Features of Interest
• RIOT enforces constant periods for kernel tasks (e.g., scheduler run, inter-
process communication, timer operations)
• Static memory allocation in the kernel. Dynamic memory management is
provided for applications.
• A scheduler that works without any periodic events. Whenever there are
no pending tasks, RIOT will switch to the idle thread, which determines
the deepest possible sleep mode
• Only interrupts (external or kernel generated) wake up the system
• Low complexity of kernel functions makes for energy efficiency of an OS.
The duration and occurrence of context switching are minimized. Two
cases: (i) a corresponding kernel operation itself is called, e.g., a mutex
locking or creation of a new thread, or (ii) an interrupt causes a thread
switch.
11/20/2015
Debasis Das
debasis@ecdzone.com
79

80. TinyOS
• Power efficient, Put microcontroller and radio to sleep
• Small memory footprint, Non-pre-emptable FIFO task scheduling
• Efficient modularity, Function call (event and command) interface
between commands
• Application specific, WSN domain
• Concurrency-intensive operation, Event-driven architecture, No
user/kernel boundary
• NesC for programming
11/20/2015
Debasis Das
debasis@ecdzone.com
80

81. Building Connected Devices
• Issues to focus on
– Utilize existing IoT platform
• Developers need to understand programming languages,
sensors, drivers, middleware, OS, project management,
security and encryption, networking protocols, etc. An IoT
platform can take care of many of these issues so that
developers can focus on the application
– Use third party software components
• Drivers and middleware development is time consuming.
Better to go with components available for the complex
micro-controllers of today
11/20/2015
Debasis Das
debasis@ecdzone.com
81

82. 11/20/2015
Debasis Das
debasis@ecdzone.com
82

83. Building Connected Devices – cont’d
– Use proven communication standards only
• Things are fluid here. You could cover the bets by supporting
everything. Building a product around a standard that may
not be around in a few years time, is a risk designers cannot
afford
– Take care of security
• Span of the network increase by orders of magnitude.
Security thereby becomes very important.
– Leverage team strengths/optimize around that
• Strengthening weaknesses in a team is time-consuming
thereby affecting time to market. It is better to work around
by using component or consultants
11/20/2015
Debasis Das
debasis@ecdzone.com
83

84. References
1. Sensor Technologies: Healthcare, Wellness and
Environmental Applications- McGrath, Michael;
Ni Scanaill, Cliodhna, Apress. Kindle Edition.
2. Designing the Internet of Things- Adrian
McEwen, Hakim Cassimally, Wiley, 2014
3. Getting Started with the Internet of Things Cuno
Pfister
4. Getting Started with the Internet of Things:
Connecting Sensors and Microcontrollers to the
Cloud, Maker Media, Inc. Kindle Edition.
11/20/2015
Debasis Das
debasis@ecdzone.com
84