1. What is an IoT Device?

Any device that has a unique identifier and which can send/receive data
over a network and can communicate with other devices on the network is called
an IoT Device.

2. Define the use of GPIO pins.

GPIO stands for General Purpose Input/Output. It's a standard interface
used to connect microcontrollers to other electronic devices. For example, it can
be used with sensors, diodes, displays, and System-on-Chip modules.

3. Define Web of Things.

The Web of Things is a refinement of the Internet of Things by integrating
smart things not only into the Internet (network), but into the Web Architecture
(application).

4. Explain Packages and Modules in Python?

● Modules:
○ Python allows organizing the program code into different modules
which improves the code readability and management.
○ A module is a python file that defiines some functionality in the
form of functions or classes.
○ Modules can be imported using the import keyword.
○ Modules to be imported must be present in the search path.

● Packages
○ Python package is a hierarchical file structure that consists of
modules and subpackages.
○ Packages allow better organization of modules related to a single
application environment.

5. Explain about IoT design methodology.

IoT Design Methodology includes:

1. Purpose & Requirements Specification
2. Process Specification
3. Domain Model Specification
4. Information Model Specification
5. Service Specifications
6. IoT Level Specification
7. Functional View Specification
8. Operational View Specification
9. Device & Component Integration
10. Application Development

● Step 1: Purpose & Requirements Specification

• The first step in IoT system design methodology is to define the
purpose and requirements of the system. In this step, the system purpose,
behavior and requirements (such as data collection requirements, data
analysis requirements, system management requirements, data privacy
and security requirements, user interface requirements, ...) are captured.

● Step 2: Process Specification

• The second step in the IoT design methodology is to define the
process specification. In this step, the use cases of the IoT system are
formally described based on and derived from the purpose and
requirement specifications.

● Step 3: Domain Model Specification

• The third step in the IoT design methodology is to define the
Domain Model. The domain model describes the main concepts, entities
and objects in the domain of IoT systems to be designed. Domain model
defines the attributes of the objects and relationships between objects.
Domain model provides an abstract representation of the concepts,
objects and entities in the IoT domain, independent of any specific
technology or platform. With the domain model, the IoT system designers
can get an understanding of the IoT domain for which the system is to be
designed.

● Step 4: Information Model Specification

• The fourth step in the IoT design methodology is to define the
Information Model. Information Model defines the structure of all the
information in the IoT system, for example, attributes of Virtual Entities,
relations, etc. Information model does not describe the specifics of how
the information is represented or stored. To define the information model,
we first list the Virtual Entities defined in the Domain Model. Information
model adds more details to the Virtual Entities by defining their attributes
and relations.
 ● Step 5: Service Specifications
• The fifth step in the IoT design methodology is to define the
service specifications. Service specifications define the services in the IoT
system, service types, service inputs/output, service endpoints, service
schedules, service preconditions and service effects.

● Step 6: IoT Level Specification

• The sixth step in the IoT design methodology is to define the IoT
level for the system. In Chapter-1, we defined five IoT deployment levels.

● Step 7: Functional View Specification

• The seventh step in the IoT design methodology is to define the
Functional View. The Functional View (FV) defines the functions of the IoT
systems grouped into various Functional Groups (FGs). Each Functional
Group either provides functionalities for interacting with instances of
concepts defined in the Domain Model or provides information related to
these concepts.

● Step 8: Operational View Specification

• The eighth step in the IoT design methodology is to define the
Operational View Specifications. In this step, various options pertaining to
the IoT system deployment and operation are defined, such as, service
hosting options, storage options, device options, application hosting
options, etc

● Step 9: Device & Component Integration

• The ninth step in the IoT design methodology is the integration of
the devices and components.

● Step 10: Application Development

• The final step in the IoT design methodology is to develop the IoT
application.

6. Define Raspberry Pi interfaces

● Serial
The serial interface on Raspberry Pi has receive (Rx) and transmit
(Tx) pins for communication with serial peripherals.
 ● SPI
Serial Peripheral Interface (SPI) is a synchronous serial data
protocol used for communicating with one or more peripheral devices.

● I2C
The I2C interface pins on Raspberry Pi allow you to connect
hardware modules. I2C interface allows synchronous data transfer with
just two pins - SDA (data line) and SCL (clock line).

7. Explain Control flows and functions in Python

Control flows:
● Control Flow – if statement
• The if statement in Python is similar to the if statement in other
languages.
● Control Flow – for statement
• The for statement in Python iterates over items of any sequence (list,
string, etc.) in the order in which they appear in the sequence.
• This behavior is different from the for statement in other languages such
as C in which an initialization, incrementing and stopping criteria are
provided.
● Control Flow – while statement
• The while statement in Python executes the statements within the while
loop as long as the while condition is true.
● Control Flow – range statement
• The range statement in Python generates a list of numbers in arithmetic
progression.
● Control Flow – break/continue statements
• The break and continue statements in Python are similar to the
statements in C. • Break --- Break statement breaks out of the for/while
loop
• Continue -- Continue statement continues with the next iteration.
● Control Flow – pass statement
• The pass statement in Python is a null operation.
• The pass statement is used when a statement is required syntactically
but you do not want any command or code to execute.
8. Explain basic building blocks of an IoT device
Basic building blocks of an IoT Device :
○ Sensing -- Sensors can be either on-board the IoT device or attached to the
device.
○ Actuation --- IoT devices can have various types of actuators attached that
allow taking actions upon the physical entities in the vicinity of the device.
○ Communication ---Communication modules are responsible for sending
collected data to other devices or cloud-based servers/storage and
receiving data from other devices and commands from remote
applications.
○ Analysis & Processing -- Analysis and processing modules are responsible
for making sense of the collected data.

9. Explain about Service oriented Architecture based device integration

SOA (service-oriented architecture) is a component model and links

different functional units (called services) of the application through well-defined
interfaces and contracts between these services. Interface is defined by a neutral
manner and it should be independent of implementation services, hardware
platforms, operating systems, and programming languages. This allows the
service to be built in a variety of such systems to interact in a uniform and
general way. The service is the basis of the SOA; thereby, they can be applied
directly and effectively depending on the system and interaction of software
agents.
Typically, business operations running in an SOA comprise a number of
different components, which are often in an event-driven or asynchronous
fashion that reflects the underlying business process needs. In the context of the
IoT, original and emerging resources are in the form of services and are opening
on the Internet. Consequently, the study of SOA-based fusion application
technology is of great value.
SOA architecture consists of five main parts, depicted as below:

(1)Consumer: acquires the information from producers’ entities that provide

services, such as mobile terminals and web clients.
(2)Application: provides application interfaces or different degrees of loosely
coupled services, such as mobile applications, web applications, and rich client.
(3)Service: the implementation of the entities involved in a specific task, such as
data center and enterprise information center.
 (4)Service Support: SOA specific application background support functions, such
as security, management, and semantic analysis.
(5)Producer: an entity to provide specific services or functions.

10. Define Cloud of Things

Cloud of Things(CoT) is an amalgamation of cloud computing technology
and the IoT features in a single unit so that connected devices can use the
advantages of both leading technologies.

11. Socrades:
SOCRADES is a service –oriented based integration architecture which provides
generic components to aid the modelling of well detailed processes. It targets
smart objects in the manufacturing domain, which represents their behaviour as
web services so as to enhance their capabilities. SOCRADES incorporates the
pattern, concept and code of SIRENA to propose and design an integration
infrastructure for web service and a framework for device supervision and life
cycle which is flawed in SIRENA.
SOCRADES is composed of four main parts which are the Device layer,
SOCRADES middle-ware (comprising two sub parts, Application part and Device
Service part), xMII and Enterprise application.
• Device Layer: This layer consists of devices that are web service enabled and
they connect to the SOCRADES middle-ware layer using the Device Profile for
Web Service (DPWS) model.

• SOCRADES Middle-ware: Devices in the device layer can connect to the

Enterprise Application as they support web service. The SOCRADES middle-ware
serves as a bridge between the device layer and the enterprise application. The
main aim of this component is to simplify the management of devices in the
device layer. Some other features and components of the SOCRADES middle-
ware are: access to devices, service discovery, device supervision, service life
cycle management, cross-layer service catalogue, and security support
(optional). The SOCRADES middleware component also extends the functionality
of the xMII component to other components and vice versa.

• xMII Component: This component is a System Applications and Products(SAP)

in Data processing product: SAP xApp Manufacturing Integration and Intelligence
(SAP xMII). It has features for: O. Uviase & G. Kotonya 7 non-web service device
enabled connectivity, visualisation service, graphical modelling, execution of
business rules and connectivity to earlier SAP software via specific protocols.
This component is integrated into the GUI of the Enterprise Application in a
mash-up form by generating rich web content to suit the purpose.

• The Enterprise Application: This component consists of a GUI which exposes

the system to the users. It receives data from the xMII component via specific
protocols or by integrating xMII web content with the Enterprise Application GUI.

SOCRADES is practically a web service integration architecture designed to

support device connectivity and integration into an enterprise application such as
in an ERP system. It is concisely based on the SOA paradigm.
Karnouskos et al.
3.3. A Service-based Architecture

3.3 A Service-based Architecture

The IMC-AESOP project follows a Service-Oriented Architecture, a general overview

of which is depicted at high level in FMC notation (www.fmc-modeling.org) in
Fig. 3.4. On the left side we see the users who interact with the services (depicted
in the middle). The data depicted on the far right side can be accessed with the nec-
essary credentials. Although we consider that the majority of these services will run
on the "Cloud" some of these may be distributed and run in more lightweight ver-
sions on devices or other systems. As long as the SOA-based interaction is in place,
they are considered as part of the general architecture view.

Lifecycle Process
HMI Alarms Business
Management Monitoring
Data
Business

Configuration System
Discovery Simulation
& Deployment Diagnostics Management
Operations

Security
R

Mobility Data Operational

Migration Model
Support Processing Data
Engineering

Data
Integration Topology
Management
Control ...
Maintenance

SCADA/ Mediator / 3rd party

Training DCS Gateway
MES ERP Device
services ...

Fig. 3.4 Architecture overview

3.3.1 User Roles

Several “user roles” are envisioned to interact with the architecture either directly
or indirectly as part of their participation in a process plant. The roles define ac-
tions performed by staff and management, and simplifies grouping of tasks into
categories.
The Business role handles overall plant management and administration and en-
sures long-term effectiveness and strategic planning. From an IT point of view, this
role is operating in the enterprise layer of a process plant, interacting with supporting
systems such as Enterprise Resource Planning (ERP), Enterprise Asset Management
(EAM), Operational Risk Management (ORM) etc.

16
This is a preprint version, which may deviate from the final version which can be acquired from https://www.springer.com/gp/book/9783319056234
Karnouskos et al.
3.3. A Service-based Architecture

The Operations role performs the normal daily operation of the plant, hence it
handles optimisation of the monitor and control processes. It is also responsible
for meeting the production targets while ensuring that the plant is running in the
most efficient, safe, and reliable modes. The tasks performed as part of this role
are located at the operations layer and use supporting systems such as Operations
Control System (OCS) for monitoring and control of the process infrastructure and
Process Optimisation Systems.
The Engineering role is here divided into two categories: Process engineering
and System engineering. The Process Engineer ensures proper design, review, con-
trol, implementation, and documentation of the plant processes. It also designs the
layout of the process and performs optimisation work with Operations. The System
Engineer deals with the deployment of new automation devices, software compo-
nents and machines, manages configurations, infrastructure and networks.
The Maintenance role is responsible for the system operation with optimum per-
formance, and ensures that the the plant’s systems and equipment are in a safe,
reliable, and fully functional state. The maintenance operations are also part of the
operations IT layer of the process plant. The systems that are supporting the tasks
performed within the maintenance role are Risk Based Inspections (RBI) systems,
Systems Monitoring, Diagnostics and Control etc.
Training ensures that all plant personnel have a basic understanding of their re-
sponsibilities as well as safe work practices. Training is performed on a regular ba-
sis by all other roles in order to improve work skills. The training planning for each
employee must be harmonized with the management strategy planning and can be
performed on-site but also using Simulation Training Systems.

3.3.2 Service Group Overview

As depicted in Fig. 3.4, it is possible to distinguish several service groups, namely:

Alarms, Configuration and Deployment, Control, Data Management, Data Process-
ing, Discovery, HMI, Integration, Lifecycle Management, Migration, Mobility Sup-
port, Model, Process Monitoring, Security, Simulation, System Diagnostic, Topol-
ogy. These groups indicate high-level constellations of more fine-grained services.
IMC-AESOP has defined some initial services which are listed in more detail in
Table 3.1.
All of the services are considered essential for next generation Cloud-based col-
laborative automation systems. Table 3.1 depicts a first prioritisation according to
what we consider necessary for future systems. The groups of services have been
rated with high priority (+) if they constitute a critical service absolutely mandatory,
with medium priority (o) if this is not a critical but nevertheless highly needed ser-
vice and lastly with low priority (-), which mainly means “nice to have” services
that enhance functionalities but are optional.
While most of these correspond to specific real-world scenarios we consider,
expanding the potential scenarios may lead to adjustments on the architecture as

17
This is a preprint version, which may deviate from the final version which can be acquired from https://www.springer.com/gp/book/9783319056234
Karnouskos et al.
3.3. A Service-based Architecture

Table 3.1 Detailed Architecture Services and Prioritisation

Service Group Services Priority
Alarms Alarm Configuration +
Alarm and Event Processing +
Configuration and Deployment Configuration Repository +
System Configuration Service +
Configuration Service +
Control Control Execution Engine +
Data Management Sensory data acquisition +
Actuator output +
Data Consistency o
Event Broker +
Historian o
Data Processing Filtering +
Calculation Engine o
Complex Event Processing Service +
Discovery Discovery Service +
Service Registry +
HMI Graphics presentation +
Integration Business Process Management & Execution Service o
Composition Service +
Gateway +
Service Mediator +
Model Mapping Service +
Service Registry +
Lifecycle Management Code Repository -
Lifecycle Management +
Migration Infrastructure Migration Solver -
Migration Execution Service -
Mobility Support Mobile Service Management o
Model Model Repository Service o
Model Management Service o
Process Monitoring Monitoring +
Security Security Policy Management +
Security Management +
Simulation Constraint Evaluation o
Simulation Execution o
Simulation Scenario Manager o
Process Simulation Service o
System Diagnostic Asset Monitor +
Asset Diagnostics Management +
Topology Naming Service +
Location Service +

such. Within the IMC-AESOP project, several of these have been implemented as
proof of concept. There are also several functional requirements which will need to
be further evaluated and may depend on domain-specific scenarios. To what extend
they might impact the proposed approach is avenue for further research.

18
This is a preprint version, which may deviate from the final version which can be acquired from https://www.springer.com/gp/book/9783319056234