U6 Flashcards
In general, IIoT primarily focuses on ?
business scenarios integrating vertically (i.e., from machines to cloud), horizontally (i.e., among supply networks), or along the life cycle of the product.
There exist some significant challenges that are unique to the IIoT architecture implementation, including:
(1) achieving productivity gains in terms of higher throughput and efficiency and eliminating non-value-adding activities;
(2) failure prevention and poor product quality;
and (3) flexible design through hiding complexity, low configuration, or reconfiguration effort, plug and produce, and avoiding technology gaps.
IIoT represents a special case of the general IoT reference architecture so that the operational technology (OT) layer and the IT layer in a manufacturing context can?
be easily integrated.
The IIoT reference architecture consists of three main layers:
edge, plant, and cloud/enterprise.
Before delving into the IIoT reference architecture, it is worth mentioning that the three-layer approach emerges from the need for ?
the individual factory to continue operation even if external connections to enterprise and cloud systems should fail.
In other words, stopping the production lines for an external connection failure is unacceptable.
In addition to IIoT, the three-layer approach is also common in other IoT scenarios such as:
smart buildings, where a local entity must continue operating smoothly even if connectivity to centralized IT systems fails.
The above figure demonstrates a scenario from automotive manufacturing for?
monitor production equipment and tools for various performance metrics.
In this scenario, analytics is to be performed both at the edge (applying the emerging edge analytics architecture) on?
edge devices and at the enterprise layer.
At the edge, the equipment associated with production operations is to be continuously monitored by ?
various sensors.
Examples of these equipment include :
production machines, smart devices, robots used for welding, and handling equipment, e.g., conveyors, palletizers.
Such devices and production machines are typically managed by SCADA systems, which can be integrated by industry protocols such as:
Profibus,
OPC,
and MODBUS.
Some newer equipment is embedding technology that allows it to?
communicate with the outside world through IT protocols such as MQTT.
The sensory data from intelligent devices and production machines can be communicated up through?
the layers with appropriate filtering and aggregation along the way.
As it can be seen above, gateways are typically utilized to integrate with?
the existing systems and equipment.
The gateways also become more capable of ?
running edge analytics,
applying rules,
and even storing data locally to support operations at the edge.
Accordingly, the edge completely handles an interaction with equipment with no involvement of?
the plant or enterprise layers.
In other scenarios, the sensory data may flow up from the edge through the plant or to the enterprise where?
plant and enterprise analytics is performed in a similar way.
To account for possible connection-failures, the edge and plant need to be able to ?
operate as a stand-alone unit from the enterprise,
therefore some capabilities of the platform need to be in both the plant and the enterprise.
In the automotive scenario, sensory data is collected from the equipment and tools initially by?
programmable controllers connected to the equipment through proprietary equipment interfaces.
The controllers can be configured to pass the sensory data to the?
upper layers of the architecture via standard IT protocols like MQTT.
Such data transfer can be performed periodically or ?
based on conditions.
The data can also be transformed into different formats as?
needed before it is passed on to the subsequent layer.
Edge Analytics is typically performed on?
the outbound information in the OT/IT hub.
Depending on the result of the Edge Analytics, command data is?
sent back down to the equipment.
This reverse flow into the edge issues the command and transform it into?
the specific protocol and data needed by the equipment.
A Broker component of the Edge controller forwards events, based on?
configuration, to the Plant Service Bus, e.g., IBM Watson IoT Platform.
In some cases, plant data is not allowed to leave the premises for?
security reasons.
Operational data is collected at?
the plant level after normalizing and cleansing to support plant-level analytics.
An information model, based on the ISA-95 industry standard, is utilized to?
support the analytics and is also used for dashboards and reporting as well.
Within the Plant Service Bus, analytics and rules determine?
the required actions for each event.
The required actions can be in the form of feedback, but they can also?
include triggering actions represented in a workflow.
In general, Data Analytics can be simple in the form of threshold monitoring or trending, but it could also be?
model-based analytics, looking at the performance of a production device, a tool, or a production process.
In other situations, additional tools can be incorporated such as:
predictive maintenance,
predictive quality,
and plant performance analytics.
Based on the result of the analytics and rules, information may flow back to the Edge and to the production equipment. Such information may result in?
dynamic reconfiguration of the manufacturing process.
In general, smart agriculture applications require?
the large-scale collection and processing of sensor-derived data for optimizing crop management.
To this end, appropriate reports are created and offered to bio-plant experts, which accordingly can?
interpret the measure for crop optimization.
In particular, the OpenIoT platform employs the SSN ontology as?
a standards-based model for the semantic unification of diverse IoT systems and data streams.
In addition, OpenIoT exploits cloud-computing concepts, e.g.,?
on-demand, utility-based, pay-as-you-go access to resource with sensing/IoT concepts.
Thanks to these features, several organizations (notably OpenIoT partners) have successfully built and deployed applications based on?
OpenIoT, while other organizations and projects evaluate the platform for their own purposes.
Before delving into the smart agriculture application, we introduce?
the main components and data flow in the OpenIoT architecture.
As depicted below, the OpenIoT platform consists of ?
seven main elements that belong to three different logical planes.
Such planes are:
the utility/application plane,
the virtualized plane,
and the physical plane.
In the utility/application plane, there exit three components:
request definition,
request presentation,
and configuration and monitoring.
The request definition component is used to create service requests to?
the OpenIoT platform through a Web 2.0 interface.
Specifically, it comprises a set of services for specifying and formulating such requests, while also?
submitting them to the global scheduler.
The request presentation component is used to?
facilitate a service presentation in a Web 2.0 interface.
To visualize these services, the request presentation component communicates directly with?
the service delivery and utility manager to retrieve the relevant data.
The third component enables the management and configuration of ?
functionalities over the sensors.
Moreover, it enables users to monitor the health of the different deployed modules.
In the virtualized plane, there are also three components:
scheduler,
cloud data storage,
and service delivery and utility manager (SDUM).
The scheduler processes all requests from?
the request definition and ensures their proper access to the required resources, e.g., sensor data streams.
First, it discovers ?
the sensors and the associated data streams that can contribute.
Afterward, it manages a service and selects/enables the resources involved in?
service provision.
The second component, referred to as linked stream middleware light (LSM-Light), is used to?
store the data streams generated from the sensor middleware, thus acting as a cloud database.
The third component combines the data streams, as indicated by ?
service workflows, to deliver the requested service to the request presentation.
To this end, SDUM utilizes the service description and resources identified and reserved by?
the Scheduler component.
Additionally, SDUM acts as a service metering facility, which keeps track of ?
utility metrics for each individual service.
In the Physical plane, the Sensor Middleware, referred to as?
the Extended Global Sensor Network (X-GSN) collects,
filters,
combines,
and semantically annotates data streams from virtual sensors or physical devices.
It acts as a hub between ?
the OpenIoT platform and the physical world.
Based on the architecture demonstrated above, the data flow within?
OpenIoT systems is as follows.
At the outset, X-GSN nodes announce the available sensors to a directory service, before?
starting to publish their data in SSN-compliant RDF format based on each X-GSN local configuration.
A user typically sends a request to?
the scheduler component to retrieve all the available sensor types that satisfy specific attributes.
To fulfill the user request, the scheduler sends the directory service a request to?
retrieve the available sensor types.
The reply is forwarded to the request definition UI from ?
the scheduler and the retrieved information is prov ided to the user.
CSIRO
This is the Commonwealth Scientific and Industrial Research Organization in Australia.
In agriculture, analyzing the size, growth, and performance of plants in a greenhouse or field site can be?
a time-consuming and expensive task.
Therefore, the main objective of smart agriculture systems is to?
collect this information from remote locations and send it back to the laboratory in real time.
In this realm, CSIRO has initiated the Phenonet project in which an autonomous WSN is deployed to?
record environmental conditions and wirelessly transfer data to a data store.
The collected data is then used to evaluate the effect of sheep grazing on?
crop re-growth through looking at root activity, water use, crop growth rate, and crop yield.
The experiment tries to compare trade-offs between?
grazed and un-grazed setup for a particular variety of crop.
This experiment is supposed to last for nine months. The animals come in the first six months and after that they are removed from the site.
To compute the root activity and water usage, a soil moisture sensor is———–.
deployed
Sensors at one depth level do not tell the entire story. Multiple depths are needed in order to?
observe behavior of the root system and the water available to the crop at any particular time.
The target functionalities include:
(1) efficiently and effectively managing the water resource;
(2) efficiently and effectively administering the timing of using fertilizers;
and finally (3) increasing crop yield by efficiently utilizing the resources (water and fertilizer) while allowing livestock to feed on healthy crop leaves.
The phenonet architecture has primarily five high-level stages, i.e.,?
field,
data store,
data analysis,
visualization,
and end user. Specifically, the field is an area comprising different types of crops varieties.
The WSN is deployed in the field to measure various environmental features such as :
soil temperature, crop canopy temperature, humidity, and wind speed.
Through collecting this data, the crops’ growth, performance, and size can be?
continuous computed in real time.
The second stage of the system involves:
storing all captured data in a safe location.
At the storage state, both sensor measurements and metadata information, e.g.,?
sensor types, serial numbers, MAC address, experimental treatment, crop sowing date, are to be stored.
In the data analysis stage, all the computations, data modeling, data cleansing, and linear aggregation models are ——————. When it requires data from a particular —————-, the data analysis component directly contacts the data store ————–. To ensure a highly responsive interaction with the system, the data analysis component also performs ————————— and applies proprietary algorithms.
performed
stream
layer
extensive caching
The data analysis component is ?
accessible through HTTP RESTful API.
The response to any request received by this component is?
in the format of JSON object.
The fourth stage is data visualization in which the output of the data analysis layer is rendered by ?
the front end and appropriate visualization components. This layer typically uses HTML5 for rendering and visualization.
Finally, the end user layer may comprise ?
a plant biologist or a farmer.
Based on the phenonet-OpenIoT integration, a farmer or scientist can perform an experiment through?
discovering relevant sensor data.
For instance,
an end-user searches for soil moisture sensors at different depths and composes an experiment/service for each of the discovered sensors.
The location of the sensor is mapped to the ?
node location of existing Phenonet application.