INDUSTRIAL INTERNET OF THINGS (IIoT)
IDE-2(19BT60318)
Dr. D.GANESH
Associate Professor, Department of CSE
Sree Vidyanikethan Engineering College(Autonomous),
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 1
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 2
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 3
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 4
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 5
UNIT V
Real World IoT Design Constraints and Industrial
Automation
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 6
M2M to IoT: A Market Perspective
• Real World IoT Design Constraints:
• Text book-2 Page numbers:225-231
• Industrial Automation
• Text book-2 Page numbers:245-253
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 7
Real World IoT Design Constraints
• This Unit Mainly outlines the technical design constraints for IoT
• This also Provides illustration of the questions that need to be taken
into account when developing and implementing M2M and IoT
solutions in the real world.
• This also provides some background and thoughts for the use cases.
• The IoT will see additional circuitry built into a number of existing
products and machines from washing machines to meters.
• Giving these things an identity, and the ability to represent
themselves and communicate with applications and other things,
represents a significant, widely recognized opportunity.
• Selection of appropriate communications technologies that can be
integrated with legacy designs (e.g. motherboards) will be relatively
painless.
• The operational environments and the criticality of the information
transmitted to and from these products
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 8
Technical design constraints hardware is popular again
• This will present some unconventional challenges and design
considerations.
• The IoT will, on the other hand, allow for the development of novel
applications in all imaginable scenarios.
• Emerging applications of M2M and wireless sensor and actuator
networks have seen deployment of sensing capabilities.
• These allow stakeholders to optimize their businesses, glean new
insight into relevant physical and environmental processes.
• The technical design of any M2M or IoT solution requires a
fundamental understanding of the specificity of the intended
application and business usage.
• Developing an end-to-end instance of an M2M or IoT solution
requires the careful selection.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 9
Technical design constraints hardware is popular again
• This can be both a difficult conceptual problem and integration
challenge, and requires the involvement of the key stakeholder(s).
• Typically, it can be considered to be a combinatorial optimization
problem.
• This is particularly relevant for organizations wishing to compete
with existing offerings, or for start-up ventures in novel application
areas.
• Typically, capital costs in terms of “commissioning” and operational
costs in “maintenance” must be considered.
• Assuming that the system designer has selected the appropriate
communications technologies to bridge the device and application
domains.
• he or she must consider the application at several levels: the device,
representation etc..
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 10
Devices and Networks
• Devices that form networks in the M2M Area Network domain must
be selected, or designed, with certain functionality in mind.
• At a minimum, they must have an energy source, computational
capability(MCU), appropriate communications interface(RFID),
memory and Sensing Capability.
• These must be integrated in such a way that the functional
requirements of the desired application can be satisfied along with
non- functional requirements.
• Functional requirements:
• Specific sensing and actuating capabilities are basic functional
requirements.
• The device must be capable of sensing or perceiving something
interesting from the environment, which is the basis of the
application.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 11
Devices and Networks
• Functional requirements:
• Sensors, broadly speaking, are difficult to categorize effectively.
• The sensor may directly measure the phenomenon of interest (e.g.
temperature), or may be used to derive data or information about the
phenomenon of interest.
• Sensors may sense a phenomenon that is local (i.e. a meter detecting
total electricity consumption or distributed (e.g. the weather).
• sensing may be prohibitively expensive or unjustifiable at scale, and
thus motivates the derivation of models.
• Air and water quality monitoring systems are typical of this type of
problem.
• There are often numerous sensors capable of detecting the same
phenomenon Ex: temperature sensors.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 12
Devices and Networks
• Functional requirements:
• These characteristics relate to the accuracy, its susceptibility, its
power requirements, its signal conditioning etc..
• Sensing principle and data requirements are also of essence when
considering the real-world application.
• Consider a continuously sampling sensor, such as an accelerometer,
versus a displacement transducer.
• Displacement can be sampled intermittently, whereas if an
accelerometer is duty-cycled, it is likely that data points of interest
may be missed.
• Furthermore, the data requirements of the stakeholder must be taken
into account.
• These requirements tend to change on a case-by-case basis.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 13
Devices and Networks
• Sensing and communications field:
• The sensing field is of importance when considering both the
phenomenon to be sensed and the distance between sensing points.
• The physical environment has an implication on the communications
technologies.
• Devices must be placed in close enough proximity to communicate.
Where the distance is too great, routing devices may be necessary.
• Devices may become intermittently disconnected due to the time
varying, stochastic nature of the wireless medium.
• Certain environments may be fundamentally more suited to wireless
propagation than others.
• For example, studies have shown that tunnels are excellent
environments for wireless propagation .
• where RF shielding can occur communication range of devices can be
significantly reduced
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 14
Devices and Networks
• Programming and Embedded Intelligence:
• Devices in the IoT are fundamentally heterogeneous.
• There are, and will continue to be, various computational
architectures, including MCUs , signal conditioning, communications
media, peripheral components etc..
• In homogeneous devices a variety of sensors and actuators can
actually exist, working collaboratively, but constituting a
heterogeneous network in reality.
• In every case, an application programmer must consider the hardware
selected or designed, and its capabilities.
• Typically, applications may be thought of cyclically and logically.
• Application-level logic dictates the sampling rate of the sensor, the
local processing performed on sensor readings, the transmission
schedule.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 15
Devices and Networks
• Programming and Embedded Intelligence:
• Careful implementation of the (embedded) software is required to
ensure that the device operates as desired.
• For heterogeneous devices, the embedded software will vary by
device.
• The ability to reconfigure and reprogram devices is still an
unresolved issue for the research community in sensor networks,
M2M, and the IoT.
• It relates both to the physical composition of devices, logical
construction of the embedded software, and addressability of
individual devices and security.
• Operating systems are typically used to make programming simpler
and modular for embedded systems.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 16
Devices and Networks
• Power:
• Power is essential for any embedded or IoT device.
• Depending on the application, power may be provided by the mains,
batteries, or conversion from energy scavengers.
• The power source has a significant implication on the design of the
entire system.
• If a finite power supply is used, such as a battery, then the hardware
selected have a major impact on the longevity of the application
• This results in short-lived applications or increased maintenance
costs.
• In most cases, it should be possible to analytically model the power
requirements of the application prior to deployment.
• This allows the designer to estimate the cost of maintenance over
time.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 17
Devices and Networks
• Gateways:
• The Gateway, is typically more straightforward to design if it usually
acts as a proxy.
• There are very few effective M2M or IoT Gateway devices available
on the market today.
• Depending on the application, power considerations must be taken
into account.
• It is also thought that the Gateway device can be exploited for
performing some level of analytics.
• Nonfunctional requirements:
• There are a number of nonfunctional requirements that need to be
satisfied for every application:
• Regulations
• Ease of use, installation, maintenance, accessibility
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 18
Devices and Networks
• Nonfunctional requirements:
• There are a number of nonfunctional requirements that need to be
satisfied for every application:
• Regulations
• Ease of use, installation, maintenance, accessibility
• Physical constraints (from several perspectives)
• Financial cost:
• Financial cost considerations are as follows:
• Component Selection:
• There are research and development costs likely to be incurred for
each individual application in the IoT that requires device
development or integration.
• Developing devices in small quantities is expensive.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 19
Devices and Networks
• Financial cost:
• Financial cost considerations are as follows:
• Integrated Device Design:
• Once the energy, sensors, actuators, computation, memory, power,
connectivity etc are considered , it is likely that an integrated device
must be produced.
• This is essentially going to be an exercise in Printed Circuit Board
(PCB) design.
• some consideration to be paid to the RF front-end design also.
• This means that the PCB design will require specific attention to be
paid to the reference designs of the RFIC manufacturer during
development.
• an additional Integrated Circuit (IC) that deals with the balun and
matching network required.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 20
Data representation and Visualization
• Data that is generated from heterogeneous systems has heterogeneous
visualization requirements.
• There are currently no satisfactory standard data representation and
storage methods that satisfy all of the potential IoT applications.
• Data-derivative products will have further ad hoc visualization
requirements.
• A derivative in these terms exists once a function has been performed
on an initial data set which may or may not be raw data.
• These can be further integrated at various levels of abstraction,
depending on the logic of the integrator.
• New information sources from various logically correlated IoT
applications, will present interesting representation and visualization
challenges.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 21
Interaction and remote control
• To exploit remote interaction and control over IoT applications,
connectivity that spans the traditional Internet.
• From the side of the application manager, or other authorized entity,
to the end-point (i.e. an embedded device), continues to be a
challenging problem.
• Elements of Device Management, specifically reprogramming and
reconfiguration of deeply embedded devices, will be required.
• This requires, among others, reliability, availability, security, energy
efficiency, and latency performance, to be satisfactory.
• Another researched topic is the definition and delivery of end-to-end
quality of service (QoS) metrics and mechanisms in IoT type
applications.
• These will be necessary if Service Agreements (SA) or Service Level
Agreements (SLA) are to be defined in the case of service provisions
for IoT applications.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 22
Interaction and remote control
• which may or may not be desirable to the application owner.
• This will be situation-specific. End-to-end latency, security,
reliability, availability, times between failure and repair,
responsibility, etc., are all likely to feature in such agreements.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 23
UNIT V
Industrial Automation
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 24
Service-oriented architecture-based device integration[245-253]
• The emerging approach in industrial environments is to create system
intelligence by a large population of intelligent, small, networked,
embedded devices at a high level of granularity.
• This increased granularity of intelligence distributed among loosely
coupled intelligent physical objects facilitates
• The adaptability and re-configurability of the system, allowing it to
meet business demands.
• This not foreseen at the time of design, and providing real business
benefits.
• The Service-Oriented Architecture (SOA) paradigm can act as a
unifying technology that spans several layers.
• These are from sensors and actuators used for monitoring and control
at shop-floor level, up to enterprise systems and their processes as
envisioned in Figure 11.1
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 25
Service-oriented architecture-based device integration
• This common “backbone” means that M2M is not limited to direct
(e.g. proximity) device interaction.
• but includes a wide range of interactions in a cross-layer way with a
variety of heterogeneous devices, as well as systems and their
services.
• This yields multiple benefits for all stakeholders involved.
• Such visions have been proposed (Colombo & Karnouskos 2009) and
realized, demonstrating the benefits and challenges involved.
• Internet Protocol (IP)-based, and more specifically web technologies
and protocols constitute a promising approach.
• The fundamental goal of enabling easy integration of device-level
services with enterprise systems overcoming the heterogeneity and
specific implementation of hardware and software of the device
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 26
M2M SOA-based integration
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 27
Service-oriented architecture-based device integration
• Surely industry specific requirements for security, resilience, and
availability of near real-time event information needs to be
effectively tackled.
• The latter are also seen as key enablers for the new generation of
enterprise system applications.
• The SOA-based vision is not expected to be realized overnight, but
may take a considerable time depending on the lifecycle processes of
the specific industry.
• Hence, it is important that migration capabilities are provided so that
we can harvest some of the benefits today and provide a stepwise
process towards achieving the vision.
• The concepts of gateway and service mediator (Karnouskos et al.
2009a), as depicted in Figure 11.2, can help towards this direction
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 28
Non-service-enabled device integration: Gateway vs. Service Mediator
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 29
Non-service-enabled device integration: Gateway vs. Service Mediator
• Dynamic device discovery is a key functionality in the future M2M.
• As an example, Figure 11.3 depicts how Windows 7 can discover
dynamically heterogeneous devices that are SOA-ready.
• A Gateway is a device that controls a set of lower-level
non-service-enabled devices, each of which is exposed by the
Gateway as a service-enabled device.
• This approach allows gradually replacing limited-resource devices or
legacy devices by natively WS-enabled devices.
• This is possible since the same WS interface is offered this time by
the WS-enabled device and not by the Gateway.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 30
Dynamic device discovery via DPWS in Windows 7.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 31
• This approach is used when each of the controlled devices needs to be
known and addressed individually by higher-level services or
applications.
• Originally meant to aggregate various data sources the Mediator
components evolved and are now used to not only aggregate but
possibly also compute/process the data.
• Service Mediators aggregate, manage, and eventually represent
services based on some semantics.
• In our case, the Service Mediator could be used to aggregate various
non WS-enabled devices.
• This way, higher-level applications could communicate to Service
Mediators offering WS instead of communicating to devices with
proprietary interfaces.
• Furthermore, now processing of data can be done at Service Mediator
level, and more complex behavior can be created
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 32
SOCRADES: Realizing the enterprise integrate Web of Things
• Agility and flexibility are required from modern factories. This, in
conjunction with the rapid advances in Information Technology (IT),
both in hardware and software.
• The latter are expected to rely on a large ecosystem of systems where
collaboration at large scale will take place.
• Mashing up services has proven to be a key advantage in the Internet
application area;
• A visionary project that followed this line of thinking was the
Industry-driven European Commission funded project SOCRADES.
• Driven by the key need for cross-layer M2M collaboration an
architecture had been proposed, prototyped, and assessed.
• SOCRADES proposed and realized SOA-based integration, as shown
in Figure 11.2, including migration of existing infrastructure via
gateways and service mediators, as shown in Figure 11.3
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 33
SOCRADES: Realizing the enterprise integrate Web of Things
• To do so, it had to rely on an IoT architecture (depicted in Figure
11.3), whose primary goal was not the Peer-to-Peer (P2P) interaction
among devices.
• with the assist of an infrastructure whose services could be utilized to
enhance M2M operations.
• The SOCRADES Integration Architecture (SIA), as analyzed by
Karnouskos et al. (2010a), enables enterprise-level applications to
interact with and consume data from a wide range of networked
devices.
• a wide range of networked devices using a high-level, abstract
interface that features WS standards (Figure 11.4).
• One can clearly distinguish the various levels such as:
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 34
SOCRADES: Realizing the enterprise integrate Web of Things
• Application Interface:
• This part enables the interaction with traditional enterprise systems
and other applications.
• It acts as the glue for integrating the industrial devices, and their data
and functionalities with enterprise repos and traditional information
stores.
• Service Management:
• Functionalities offered by the devices are depicted as services here to
ease the integration in traditional enterprise landscapes.
• Tools for their monitoring are provided.
• Device Management:
• Includes monitoring and inventory of devices, including service
lifecycle management.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 35
The SOCRADES Integration Architecture (SIA)
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 36
SOCRADES: Realizing the enterprise integrate Web of Things
• Platform Abstraction:
• This layer enables the abstraction of all devices independent of
whether they natively support WS or not, to be wrapped and
represented as services on the higher systems.
• This layer also provides a unified view on remotely installing or
updating the software that runs on devices.
• Devices & Protocols:
• These layers include the actual devices that connect over multiple
protocols to the infrastructure.
• The respective plugins of course need to be in place so that they can
be seamlessly integrated to SIA.
• This prototype was named a Local Discovery Unit (LDU), and would
enable the dynamic discovery of devices on premise and their
coupling with the SIA.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 37
IMC-AESOP: from the Web of Things to the Cloud of Things[250]
• Visionary approaches have been further developed in the
industry-driven project IMC-AESOP (2013).
• There the vision of SOCRADES has been pushed forward by
considering the rapid advances in hardware and software, as well as
IT concepts.
• Therefore, we go beyond WS-enabled devices towards the cloud in
order to harness its benefits, such as resource flexibility, scalability,
etc.
• The result will be a highly dynamic flat information-driven
infrastructure (Figure 11.5) that will empower the rapid development
of better and more efficient next generation industrial applications.
• The infrastructure links many components of a wide variety of scales,
from individual groups of sensors and mechatronic components
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 38
IMC-AESOP: from the Web of Things to the Cloud of Things[250]
• Although today factories are composed and structured by several
systems viewed and interacting in a hierarchical fashion following
mainly the specifications of standard enterprise architectures.
• there is an increasing trend to move towards information-driven
interaction that goes beyond traditional hierarchical deployments and
can coexist.
• With the empowerment offered by modern SOAs, the functionalities
of each system (or even device) can be offered as one or more
services of varying complexity.
• This transition marks a paradigm change in the interaction among the
different systems, applications, and users.
• The traditional hierarchical view coexists, there is now a flat
information-based architecture.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 39
Future industrial system view of cloud-based composition of cyber-physical services
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 40
IMC-AESOP: from the Web of Things to the Cloud of Things[250]
• Next generation industrial applications can now rapidly be composed
by selecting and combining the new information and capabilities
offered to realize their goals.
• The envisioned transition to the future cloud-based industrial systems
is depicted in a Figure 11.6.(Next slide)
• Several “user roles” will interact with the envisioned architecture
either directly or indirectly as part of their participation in a process
plant.
• The roles define actions performed by staff and management, and
simplifies grouping of tasks into categories such as business,
operations, engineering, maintenance, engineering training, etc..
• it is possible to distinguish several service groups for which there
have also been defined some initial services.
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 41
IMC-AESOP cloud-based architecture vision
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 42
IMC-AESOP: from the Web of Things to the Cloud of Things[250]
• All of the services are considered essential, with varying degrees of
importance for next generation, cloud-based, collaborative
automation systems.
• The services are to provide key enabling functionalities to all
stakeholders (i.e. other services, as well) as cyber-physical systems
populating the infrastructure.
• As such, all these systems can be seen as entities that may have a
physical part realized in on-premise hardware, as well as a virtual part
realized in software potentially on-device and in-cloud.
• This emerging “Cloud of Things” has the potential to transform the
way we design, deploy, and use applications and cyber-physical
systems.
• Typical functionalities include alarms, configuration and deployment,
some control, data management, data processing, discovery, lifecycle
management etc..
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 43
IMC-AESOP: from the Web of Things to the Cloud of Things[250]
• It is clear that this is a proposal that will need to be further refined in
real-world scenarios.
• Outsourcing key functionalities to the cloud is challenging, and
further research needs to be done towards the applicability of it for
several scenarios.
• However, several aspects with relation to real-time interactions,
reliability, and resilience, as well as control are still at an early stage.
• Constructing such complex systems additionally bears challenges
with respect to safety, maintainability, and security
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 44
THANK YOU ONE AND ALL
Dr.D.Ganesh 4/30/2022 12:29 PM Slide No. 45