Device Stand-by Management Scheme of IoT: A Framework for Dealing with Real-world Device Fault Risk In City Platform as a Service

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Device Stand-by Management Scheme of IoT:
A Framework for Dealing with
Real-world Device Fault Risk
In City Platform as a Service
IMIS2018, Matsue, Japan
Toshihiko Yamakami
CTO Team, ACCESS
Toshihiko.Yamakami@access-company.com
2018/07
Toshihiko Yamakami (ACCESS Confidential)Device Stand-by Management Scheme of IoT: A Framework for Dealing with Real-world D2018/07 1 / 26

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Outline
Background
Related Work
Research Method
Stand-by Mechanism of Edge Computing
Requirements
Stand-by Mechanism
Simulation
Parameters
Simulation Results
Discussion
Advantages of the Proposed Model
Limitations
Conclusion

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Background
Research Purpose
The aim of this research is to develop a framework to enable stand by
mechanism to ensure service availability at a device fault.
Background
The increase of number of smart devices attract attention in edge
computing. Efficient use of resources is an important topic in edge
computing.
There are two types of edge computing: heavy edge computing and
lightweight edge computing. And the growth will present opportunities
of lightweight edge computing because a large part of IoT growth will
be attributed to limited resource devices.
Many real-world IoT applications have challenges of hardware faults. In
the Cyber-Physical system perspective, it is a challenge to deal with.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Related Work
a) task migration algorithms
a resource allocation approach for a hard real-time guarantee automotive system
[Dziurzanski15], complex event processing in operator migration of a
device-to-device system[Dwarakanath16] real time task migration in Apache
Storm[Yang15] task migration for network utilization[Ottenwalder15]
b) migration programming models and middleware
ThingsJS, a Javascript-based middleware platform [Gascon-Samson17], a
fine-grained edge off-loading architecture FADES [Cozzolino17]
c) collaborative processing and system issues
distribute data flow for collaborative processing of devices with different owners
[Giang15]
The originality of this paper lies in its development of a stand-by-based
migration scheme for IoT.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Overview of CPaaS.io
Smart City Innovation is the goal of the CPaaS.io joint R&D project
between Europe and Japan starting from 2016.
To achieve this, the CPaaS.io platform combines the capabilities of
the Internet of Things (IoT), big data analytics and cloud service
provisioning with Open Government Data and Linked Data
approaches.
CPaaS.io hosts multiple projects in different cities in Europe and
Japan, e.g. Utrecht, Amsterdam, Tokyo, Sapporo, and Yokosuka.
URL: https://cpaas.bfh.ch/ CPaaS.io – City Platform as a Service

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Research Method
Identifying real-world IoT migration contexts,
Developing a framework of lightweight edge computing,
Developing a stand-by-based migration scheme for edge computing

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Applicability of task migration of u2 architecture
dynamic static
(real-time, automatic) (planned, semi-
automatic)
Heavy-edge module N.A. N.A.
Migration
Lightweight edge module N.A. u2
Migration
u2 architecture is ucode version 2-based. Ucode is a 128-bit identifier system standardized
ITU-T H.642.1, proposed by University of Tokyo.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Requirements of edge computing
Requirement Description
Load balancing Computational load is distributed among multiple
edge nodes to ensure throughput.
Low latency Computational load is performed at edge nodes not
in the cloud, to ensure low latency.
Privacy preservation Sensitive information is maintained in devices and
edges to ensure protected access.
Off-loading Computational load is distributed to another avail-
able edge node to ensure service availability of
front-end node.
Fault-tolerance Alternate device is provided to ensure continued
service at a fault in a device.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Characteristics of Lightweight Edge Computing
Item Description
Binary migration Migration is done by binary code.
State-less migration Limited or no capability of processing states among
lightweight edge nodes.
Front-end availability it is crucial to maintain front-end availability
Data loss tolerance Data loss is prohibiting, however, it is better than
no front-end availability.
For example, when a fault take places at random and the average interval is 90 days, more
than 1 % fault occurs within 1 day from the previous fault in a Poisson distribution case.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Modified Definition of Task Migration of Edge Computing
Migration Load-balancing or off-loading of computational re-
quirements to multiple available edge nodes
Modified migration Remove the computational requirements from orig-
inal device and relocate them to a stand-by device
in order to secure the continuity of a service.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Stand-by Mechanism
working -
stand-by -
monitor
controller
?
device description
?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Example of Control Flow
device
controller (node)
- log collection
for predictive maintenance
6
calculation of
fault/penalty

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Task and Device Descriptions
Task Description
Internal Requirements
External Requirements
Device Description
- Static
Properties
Dynamic
Properties
Item Description
Availability target Required range of availability ratio as a service
system.
Stand-by Costs Costs (hardware, software, networking, battery)
for stand-by.
Dependency External dependency to execute a task.
Fault characteristics Characteristics (severity, frequency) of faults.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Device Status
Status Description
Normal Normal status. No standby is provided. When at fault,
normal reconfiguration operation will be performed.
Dual Dual working status. Multiple devices are working to
ensure fault tolerance.
Cold Standby A stand-by device is available, but it is not ready for
instant switch.
Hot Standby A stand-by device is available, and it is ready for instant
switch.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Binary Code Allocation
Status Description
On device Multiple binary images are maintained on a device.
On cloud A binary image is maintained in cloud, and transferred
on demand.
On peer device A binary image is maintained on a peer device.
On edge A binary image is maintained in an edge node.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Examples of Down Time Requirements
Application type Description
Chemical plant sen-
sors
Industrial chemical plant sensors require a down
time less than 60 seconds.
Real-time traffic mon-
itors
Real-time traffic monitors require a down time less
than 5 minutes.
Climate logging sen-
sors
Climate logging sensors require a down time less
than an hour.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Simulation Parameters and Output
Item Description
Stand-by number 1
Number of Trial 10000
Battery consumption normal: cold-start: hot-start: dual = 1.0 : 1.1 :
1.6 : 2.8
Switch time normal 15 minutes, cold standby 1 minute
Average fault interval 30 days (Poisson distribution)
Output Description
Latency Average latency to respond a service request.
Availability Average ratio to be ready to serve a request.
Costs Costs of devices and operation to serve a request.
The simulation is done in R-3.3.3 for Windows(64bit).

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Five Cases in Comparison
Case Description
Regular No stand by. When a device fails, an alternative
device is invoked after the detection.
Cold Standby An alternate device is usable, but not ready for
working.
Managed Standby A stand-by is initiated according to observed device
characteristics.
Hot Standby An alternate device is always in standby to replace
a failed device.
Dual Always two devices are working and synchronized.
One fault does not disrupt continuous operation.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Managed Standby Flow
after initiation or a fault, a standby device is in a cold standby status.
according to the previous fault records, a transition time is set.
when the transition time passes, the standby devices becomes a hot
standby status.
when a fault occurs before the transition time, the standby device will
be activated from the cold standby status.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Simulation Conditions
Conditions Description
Switch time The switch times for the hot standby mode and the
dual mode are negligible. tn for the normal mode
and tc for the cold standby mode.
Battery-based defect Battery status is not considered to influence defect
ratios.
Fault ratio Fault ratios are assumed to be random (Poisson
distribution arrival).
The same in all modes (No impact from standby or
dual modes.)
Average fault interval is 30 days.
Operation complexity Operation complexity of the dual mode is negligi-
ble.
Battery overhead Percentage to the normal mode, 1+bc for the cold
standby mode, 1 + bh for the hot standby mode,
1 + bd for the dual mode.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Battery Consumption (normal mode as 100
Relative
Battery
Consumption
100
200
normal cold
standby
hot
standby
dual managed
standby

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Relative Downtime (normal mode as 100)
Relative
Downtime
100
normal cold
standby
hot
standby
dual managed
standby

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Advantages of the Proposed Approach
The author proposes a hybrid approach of managed standby. The approach
uses a combination of cold-standby and hot-standby using data-based
proactive management of devices.
The author performs a preliminary simulation to compare the five modes,
normal, cold-standby, hot-standby, dual, and managed standby.
Initial simulation results are promising to pursue proactive management of
IoT devices.
The use of relatively inexpensive common CPU boards as a hot-standby or
cold-standby for fault situations may be an important consideration in the
future where the IoT computing is indispensable for the society. It is
conceptually similar to RAID (Redundant Array of Inexpensive Disks) in hard
disk.
Depending on a stringent requirement for continuity hot-standby or even a
dual configuration may be requested. But our simulation shows that a
proactive managed standby may bring in a cost-effective solution.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Limitations
This paper is exploratory and at its early stage.
Quantitative evaluation of the proposed method is not enough and requires
further examination. The proposed control mechanism requires further
validation with real-world test data in multiple use cases.
Requirements of maximum downtime vary and require case-by-case
examination.
The parameters of simulation are ad hoc, and not based on the real-world
data.
Penalties of managed standby is context-dependent and requires further
consideration at deployment.
Software-managed fault tolerance of IoT devices is a relatively new field and
requires future evaluation.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Conclusion
For lightweight edge, it is important to deal with device failures rather than
management of complicated computing resources with off-loading. The
author defines the binary-level stand-by management is a part of task
migration in lightweight edge computing.
The author proposes a managed standby mechanism to make hybrid use of
multiple standby mechanisms to dynamically adapt the device management.
It facilitates the use of accumulated fault history data to provide proactive
management of devices.
The author performs a preliminary simulation to evaluate the advantages of
managed standby with combined cold standby and hot standby modes. The
simulation results show the managed standby method is promising
considering the hybrid characteristics of cold-standby and hot-standby.
This is an encouraging result for future exploration of proactive managed
standby in smart city services. The future research include data-mining-based
proactive management and deep learning of long-term fault characteristics
using aggregated use of IoT maintenance history data.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Thank You for Your Attention!
Questions?

Device Stand-by Management Scheme of IoT: A Framework for Dealing with Real-world Device Fault Risk In City Platform as a Service

More Related Content

Similar to Device Stand-by Management Scheme of IoT: A Framework for Dealing with Real-world Device Fault Risk In City Platform as a Service

More from Toshihiko Yamakami

Recently uploaded

Device Stand-by Management Scheme of IoT: A Framework for Dealing with Real-world Device Fault Risk In City Platform as a Service