Cyber-twins Based Approach to Support and Improve the Development of Industrial Iot Applications

CYBER-TWINS BASED APPROACH TO SUPPORT AND IMPROVE THE DEVELOPMENT OF INDUSTRIAL IOT APPLICATIONS THAT UTILIZE INDUSTRIAL INTERNET-OF-THINGS.

 

1.       INTRODUCTION

//an introduction to the research problem, including a concise statement of the research question(s) and/or hypotheses;

• Industrial IoT applications need to support: Digitization of production, automation, horizontal integration of production lines in a comprehensive supply chain

• Boil down the Industrial internet of things to machines, people, products and processes
• IoT devices
• Current support provided for developing Industrial IoT applications that utilize the 4 components.

• Machines- the majority are vendor-specific programming environments, android architecture
• People/ Product – KPIs/ Ontology-based approaches, activity recognition
• Processes- Workflows/ workflow execution engines
• Products – Via instruments (e.g., refractometer for paste consistency), or embedded sensors (e.g., graphene).

• Missing in SoA:

//introduce the concept of cyber twins

This research will propose, design, implement, evaluate and validate a cyber-twins based framework to support and improve the development of industrial IoT applications that utilize the industrial Internet-of-Things. The novel framework will provide:

• Ability to model, emulate and debug, monitor and control the key elements of industrial IoT using the cyber twins.
• Techniques to customize cyber twins to represent specific instances of the key elements.
• Techniques to develop iIoT applications by utilizing cyber twins.
• Methods to test and evaluate cyber-twin based applications.

The rest of this report is organized as follows. In section 2 we discuss the background of the research project and an overview of the current state. Section 3 provides several motivating scenarios that are used to identify the required improvements and the support for developing industrial IoT applications. Section 4 is dedicated to discuss the current state-of-art and evaluate the existing research work. In section 5 we provide the identified research questions and the aim of the research. Section 6 describes the research methodology that is been followed in this research and section 7 provides an overview of the proposed solution. Section 8 provides the significance of the research study and the key contribution of the research project. Finally, section 9 discusses the research plan of the project with its timeline.

2.       BACKGROUND

• Industrial IoT and iIoT applications.

• IoT devices
• Software processes
• The concept of creating cyber representations of physical objects
• Challenges

3.       REQUIRED SUPPORT FOR DEVELOPING IIOT APPLICATIONS THAT UTILIZE IIOT: MOTIVATING SCENARIOS

3.1.  Machines

Industrial IoT applications utilize IoT devices with different levels of complexities. Few examples of such application scenarios are as below.

1. A smart power meter can communicate using a variety of output options, including  Modbus RTU, Modbus TCP/IP, CAN bus, etc. An iIoT application which harnesses the data from the power meter needs to support multiple protocols and needs to be tested against each of it.

• Enable start developing and testing an iIoT application without having the actual hardware device.
• Enable testing of the iIoT application against different protocols in a sophisticated manner.

2. An iIoT application needs to have access to a subset of actuation commands and sensor data that is exposed by a machine. The default interface to the machine exposes set of critical commands and data that should be hidden from the application.  This can be a security concern and needs to be handled.

• Ability to encapsulate functionalities and expose a custom set of actuation commands and sensor data to outside parties.

3. Complex machines have an inner control loop, hence an external request to execute an actuation command on the machine cannot guarantee the successful execution of the request as its execution may depend on the values of multiple other internal variables. An iIot Application needs to make use of external sensor devices or/and machine operators to confirm and verify the successful execution of an actuation command on a particular machine.

• Enable the easy integration of external verification and confirmation methods to verify and confirm the actuation actions.

3.2.  People

Following is a segment of a meat manufacturing scenario which describes the meat processing factory workers and the relevant aspects and behaviours that needs to be captured for an iIoT application.

Meat cutting machine cuts carcasses into large chunks and put the chunks on a conveyer belt. The meat chunks on the running conveyer belt are picked up by the meat processing factory workers. Workers remove the fat from the picked meat chunk and cut it into delivery-ready size pieces and put back to the conveyer.

The following are the activities carried out by a factory worker who works in a normal 8-hour long production shift.

1. Grabs the next available piece of meat.
2. Removing fat and cut into smaller delivery-ready chunks of meat.
3. Return processed meat to the conveyor belt.
4. Performs a knife sharpening activity randomly while waiting for next available meat.
5. Take up to 10 random short breaks of 10 mints during the shift.
6. Randomly take a 1-hour long break during the shift.

IoT device setup and data collection:

• Factory workers wear MetaWear wristbands on both arms (the wrist bands are equipped with an MCU, a battery, memory, Bluetooth Low Energy (BLE) module,  and a variety of sensors including accelerometer producing acceleration along 3 axes, gyroscope).
• Under the workbench of the factory workers, Raspberry Pi devices are placed and the MetaWear sensors communicate with them and send data via BLE.
• A processing server connected to Raspberry Pis (RPis) over a WiFI router performs data analytics on the data sent by all Rpi devices.

The IoT application needs to calculate the KPIs in real-time. A meat manufacturing factory worker is needed to be identified based on the set of activities that the person performs to measure low-level KPI’s and the time spent on each of activity to identify their skill levels to perform higher-level optimization.

3.2.1.      Requirements for modelling people

• Here the iIoT application is only interested in recognized activities but the IoT device does not provide the translated information, thus it needs to be carried out by the application itself. This increases the application development time, and reduce the reusability of a trained model across multiple applications.
• Also, it is important to note that, modelling a factory worker as a simple set of activities is not a very accurate approach due to the unpredictable nature of a person and needs to be handled by the iIoT application itself in this scenario.

3.3.  Products

Production process stages for producing yeast paste from the raw yeast.

Stage 1: Autolysis

Inputs: Raw yeast

Outputs: Autolysate

Stage 2: Separation

Inputs: Autolysate

Outputs: Yeast extract, Residue

Stage 3 : FFT Evaporation

Inputs: Yeast Extract

Outputs: FFTE output

FFTE adjustable machine Settings: Preheat Temperature, Steam Pressure

Quality measurement: Density reading

Stage 4: TF Evaporation

Inputs: FFTE output

Outputs: Yeast paste

TFE adjustable machine Settings: Condensor Pressure, Vacuum Pressure, Preheat Temperature, Rotational Motor Speed

Quality measurement: Density reading

Stage 5: Filling the paste to drums

Inputs: Yeast paste

Quality measurement: A refractometer is used for testing the consistency of the yeast paste during 4 different drum filling states.

Expected final product quality:

Yeast paste ideal consistency range is 62%+-0.5%.

Food safety issue < 61%

Profit loss > 65%

Monitoring and controlling

HMI provides an interface for monitoring and for controlling the adjustable machine settings.

3.3.1.      Requirements for modelling products

The iIoT application needs to adjust the configurable machine settings to handle the variations of yeast paste raw materials at different stages of the production process based on the quality measurement values produced by IoT devices, in order to optimize the production process to achieve the ideal consistency of the yeast paste.

• The ability to model product stages based on the utilized IoT devices, quality standards and configuration settings.

3.4.  Processes

The scenario illustrates a simplified process of a production unit which packs soft drink bottle into boxes of 24 bottles. It consists of 2 main parallel processes.

1. Mainline: The bottles moving through the packing machine.
2. Blank loading: Controls the conveying of blanks for collating bottles to cases.

 

This process is coupled with the data that comes from the packing machine and when data indicate an error operator needs to be acknowledged. Furthermore, its defined set of activities are coupled with the factory workers who are engaged in operations such as blank loading, fixing errors by adjusting the gauges and observing ripped blanks by watching. Currently, this is solely driven by the data produced by the machine.

3.4.1.      Requirements for modelling processes

• The processes heavily utilize and interact with all the key elements of iIoT. Therefore, to accurately identify the current state of an activity using the data produced by people, products or additional IoT devices (i.e. enable adding a machine operator input to verify a fixed error).

3.5.  Requirements for an industrial IoT application development framework.

According to the above scenarios, it can be identified that the key constructs of iIoT people, products and machines are the IoT devices, with different levels of complexity such as RFID tags, smart-power-meter, linear actuators, Metawear wearables, etc. Furthermore, iIoT processes also interact with iIoT products, people and machines and utilize them heavily.

Considering this fact, it is apparent that at a more lower-level, we first need to model the concept of an IoT device based on the functionalities/characteristics/behaviours that are commonly required by the key elements of iIoT. This approach will improve the modularity and reusability of this work. However, in a more abstract level, this model further needs to be customized to cater the characteristics and behaviours that are specific to each of the element in iIoT application development perspective (i.e. activity based-representation for factory workers, handling the machines with inner control-loop, etc).

Therefore the above-identified requirements are further categorized to set of common requirements that need to be handled at the IoT device level and to more specific ones related to higher-level concepts (the key element of industrial IoT that are built using the IoT devices).

3.5.1.      The common set of requirements that are shared by key elements

1. Enable start developing and testing an iIoT application without having the IoT device (i.e. develop an application without a physical smart power meter/ factory worker wearable).
2. If the IoT device supports multiple communication protocols, enable the application to be tested for each of them in a sophisticated manner.
3. Ability to encapsulate functionalities of the IoT device and expose a custom set of actuation commands and sensor data to outside entities.
4. Enable the easy integration of external verification and confirmation methods to verify and confirm the actuation actions on IoT devices.
5. Ability to translate the data from an IoT device if required by the iIoT application.
6. Additionally, an iIoT application might need to utilize more the one industrial IoT element (instance), thus need to provide the interconnection between multiple-element instances.

3.5.2.       Additional specific requirements for key elements.

1. Machines

• Machines have an inner-control loop and the ability to develop an iIoT application without having the physical IoT devices needs to be developed/customized further to cater to this characteristic.

2. People

• Data translations need to be mapped with the set of activities/ skill level KPI’s of a worker.
• The unpredictable nature of a factory worker (i.e. taking random breaks), also needs to be specifically addressed.

3. Products

• Ability to specify different quality standards at different stages of the products life cycle,  mapping quality measurement data taken from IoT devices to product quality standards, ability to model product stages based on the utilized IoT devices and the quality standards needs to be considered.

4. Processes

Enable using the specific characteristics of products, processes, machines and people to accurately determine the state of activity and ensure smooth integration with the rest of the key elements.

4.       THE STATE-OF-ART

4.1.  Describing IoT devices

Semantic Sensor Network (SSN) ontology is a key sensor-specific ontology which is developed by Semantic Sensor Network Incubator group covering four different areas including device discovery and linking, device discovery and selection, provenance and diagnosis, and device operation, tasking, and programming [1]. Due to the wide adaptation of SSN, and with the growing focus on lightweight vocabularies, SSN was identified as a heavy-weight ontology. The concept of actuation was also highlighted with the advancements in IoT, thus the new SSN ontology,  SOSA (Sensor, Observation, Sample, and Actuator) is introduced as a core ontology to cater above requirements by introducing the concepts such as actuation [2]. These ontologies are widely adapted and extended in many works to describe the sensors and actuators [3].

However, the concept of an IoT device, which can be a combination of multiple sensors or/and actuators is not explicitly defined in these ontologies as it is not their key focus. Following sections describe the existing techniques and approaches to model, emulate and debug, monitor and control people, products, processes and machines.

4.2.  Machines

4.2.1.      Handling the control-loop

Even though industrial automation is a separate concept from the focus of this research the approach that is used for modelling and describing the controllers is quite useful and adaptable in our context for creating cyber twins for complex machines, specifically for handling the control-loop of a machine. Therefore it is described in the following subsections.

a.    A Petri Nets (PNs) and matrix-based representation

Polic & Jezernik has proposed a closed-loop matrix-based model for representing the control architecture of machines in aproduction system. The control logic of the system is graphically modelled using a Petri Net graph and then converted to a matrix-based representation for ease of analysis and simulation. In their approach, the system is assumed to be a Discrete Event System (DES) with event-driven dynamics. Discrete state of the system is defined by the specific structure of the system (e.g., valve opened, automatic cycle started, etc.).The system can only be in a single state at a given time and the number of discrete states is finite. State transitions are triggered by specific events occurring in the system (i.e. button push) [4].

b.   A Finite State Machine (FSM) based representation

The concept of function blocks is introduced in industrial automation to create efficient, flexible, reusable code that is vendor and product independent [5]. In the industry, machine manufacturers use a PLCopen based state machine description with the relevant functional blocks for describing the controller logic of the machine [6, 7].

The above-discussed approaches (PN-based and FSM-based) can be utilized to model the machines with an inner control loop.

4.2.2. Dealing with hardware complexities

Machines have diverse and vendor-specific hardware, thus writing iIoT applications can be time-consuming as they need to deal with hardware specifics and lack of code reusability. In the current context following methods are adapted to manage this issue.

a.      Android Hardware Abstraction Layer

Android provides a standard interface to its underlying hardware (camera, sensors, GPS, Audio, etc) which are vendor-specific, through its Hardware Abstraction Layer (HAL). It enables the Android application/framework to make requests to underlying hardware-specific device drivers via the standard HAL APIs.The HAL needs to be implemented by the vendors and utilizes the functions exposed by the underlying Linux kernel to serve the request from the Android application/framework. HAL has structures which specify the HAL type, module type, version detail, and a set of function callbacks (methods) which are registered to android framework layer. At an instance when the Android framework service needs to request the data from a sensor device, and the service will make a call to the corresponding function in sensor in the HAL and it will in turn talks directly with Linux device driver. The driver will trigger the sensor driver and deliver the data back to the HAL sensor module and it will pass back the data to Android application [8].

b.      Standard function blocks

The PLCopen motion standard provides a way to have to standardize application libraries that are reusable over multiple hardware platforms. The standardization is done by defining libraries of reusable components in the form of functional blocks [9]. This facilitates writing the application programs that are less dependent on the underlying hardware and rapidly increase the reusability of the application software. Furthermore, different machine manufacturers can provide their own implementation of the functional blocks and it allows data hiding and encapsulation.

4.2.3.      Debugging and emulation

a.      Android emulators and Android Debug Bridge

The Android emulator enables prototyping, developing and testing Android applications without having a physical device. It utilizes the Quick Emulator [10], hypervisor to emulate the hardware functionalities of the target device. Android Emulators can be configured using the Android Virtual Device (AVD) and AVD enable defining hardware and software options that need to be emulated. Each instance of the Android emulator utilizes an AVD and functions as an independent device, with private storage for user data, SD card, etc.

Android Debug Bridge (ADB) is a command-line tool which communicates over USB that enable installing and debugging the Android applications on the hardware emulators or the actual devices. Android emulator and the ADB together enables testing and debugging the android applications much easier [11].

4.2.4.      Monitoring and controlling

Run time monitoring and controlling of machines are done through Supervisory Control and Data Acquisition (SCADA) systems and Human-Machine-Interfaces (HMIs). The concept of ‘digital twins’, having the digital representations of the machines in cloud/edge, are widely used for diagnosis, prognosis and optimization of the machines [12]. This approach is supported and implemented by a number of major machine manufacturers at different advance levels [13-15].

4.2.5.      Summary

We have discussed several requirements for modelling the machines under section 3. Such as the ability to encapsulate functionalities of the machine and expose a custom set of actuation commands and sensor data to outside entities, enabling the easy integration of external verification and confirmation methods to verify and confirm the actuation actions on the machines, etc. From the discussion provided above it is evident that some of the requirements are handled in software architectures such as Android and in industrial automation.

4.3.  Products

Products go through different lifecycle phases starting from ideation and definition (designing and planning) where the product ideas are been prototyped and tested (engineering). The successful prototypes are used for making the products (execution) and are used by the consumers (service) and are finally been disposed of [16]. A product is required to meet different quality standards defined based on safety, costs, etc at different stages of its lifecycle.

Major companies provide vendor-specific digital-twin based software solutions for managing different phases of a product’s lifecycle and they are explicitly used for product prototyping and testing [17-19].

Volkswagen employs augmented reality and 3D models for modelling and prototyping their products and product components. This ensures the compatibility of the product components with each other and increases the smoothness of the production process that is happening worldwide. Also, the virtual twin of a product twin serves as a safety net for ensuring further development [20]. For modelling and testing the virtual models of the self-driving vehicles Cognata has introduced a cloud-based simulation platform that removes the hardware barriers for testing the products. The environment provides dynamic traffic simulation models, utilises artificial intelligence and computer vision to provide a sophisticated testing environment for self-driving car models. Sensors such as cameras, lidar, telemetry data from GPS sensors and accelerometers are recreated in the simulation[21].

In academic research number of solutions have been proposed for product modelling by mainly employing ontological approaches, Computer-Aided-Designs (CADs) and object-oriented approaches.

Ontological approaches are heavily proposed for enabling data interoperability in product lifecycle management. These models are not limited to product data modelling but they are used as a basis for developing ontology-based applications [22-24]. They provide technical support for developing the products in terms of data interoperability and capturing and reuse of the knowledge between different product development systems. The product-service ontology model is proposed by Jung et al. for facilitating information retrieval and knowledge extraction during the product lifecycle. Their aim is to provide a flexible and modular approach to knowledge sharing in an IoT environment. The solution proposes the use of domain-specific concepts related to vehicle life cycle management and related services in the given example [25]. Barbau et al. have proposed an ontology the OntoSTEP for semantically modelling CAD designs of products and to enable the interoperability among them.  The key goal of this research is to consolidate product information to build a coherent knowledge base. The authors have introduced a semantically enriched product model that can be easily integrated with OWL ontologies. This is proposed for manufacturing systems that need to be dealing with complex product lifecycle information [22].

An object-oriented-template based product modelling approach is proposed by Wang et al. for modelling the assembly modelling of a complex product. To facilitate assembly modelling, Initially product family is defined using a high-level template that contains classes of the parts and assembly topologies and connections. The classes in this template model can be further extended to define more specific concepts as it employs an object-orient approach. The object-oriented approach encapsulates the objects in the product template, improve the reusability of assembly components and provide modularization in the design [26].

4.3.1.      Summary

In Section 3 we have discussed several requirements for modelling iIoT products, some of them being the ability to specify different quality standards at different stages of products life cycle,  mapping quality measurement data taken from IoT devices to product quality standards, ability to model product stages based on the utilized IoT devices and the quality standards. It is not evident that these requirements are supported by the above-discussed approaches.

4.4.  People

In multiple research studies, shopfloor workers are modelled as a set of activities and ontological approaches are utilized to formally capture, store and deduce information from the shopfloor data to help in making decisions.

An evaluation tool is proposed by Arena et al. for analysing the expertise level of shop floor workers and identifying the skill level improvements after training. A domain-specific ontology is proposed for identifying the shop floor oriented semantic enrichment that covers processes and assets at shop floor level and is used for integrating the large volume of data from heterogeneous sources. It is then extended to a set of more specific concepts such as  KPIs for worker expertise to support the evaluation of the data, based on Kirkpatrick’s evaluation model [27].

Arena et al. have proposed a human resource optimisation (HRO) engine for managing shop floor operations, using ontological modelling techniques and conditional random field (CRFs) probabilistic model. It is proposed to optimize the decisions made for identifying the right person for the right-job in real-time shopfloor operations. The work is derived based activities that need to be carried out in planned and unplanned shop floor operations and included in the static information model along with asset information and pre-defined worker skill-level information. They have created a dynamic information model for capturing parameters that are taken from shopfloor sensors. Data from the Computerized Maintenance System(CMMS) and Supervisory Control and Data Acquisition (SCADA) are integrated represented as in RDF using the SatisFactory ontology. A performance evaluation index is defined and used together with the RDF data set to provide optimization suggestions for worker allocation[28].

Forkan et al. have proposed an industrial IoT solution for monitoring and assessing the productivity of the factory workers in large manufacturing plants where the majority of production activities are performed by workers using tools and operating machines. The solution uses a machine learning model to identify the activities of workers from the sensor data collected from worker wearable devices. Activities include hours spent on working, time spent on each of the defined activities, etc. This information is used to calculate the worker-related Key Performance Indicators. Additionally, proximity sensors are utilized to identify the individual workers and their association with a particular workstation at a given time. This provides the flexibility to adapt to situations where workers randomly change their work stations during their shifts [29].

//FSM++

4.4.1.      Summary

It is evident that the activity-based modelling of factory workers are commonly used across industrial IoT solutions.  However, a framework level functionality for modelling factory worker activities based on IoT data is not supported by any existing framework discussed above. Furthermore, handling the unpredictable behaviour of a worker is a common requirement for these applications and needs to be considered when providing a modelling mechanism at the framework level.

4.5.  Processes

Industrial applications often need to interact with different business processes some of being crucial for the functionality of the business such as the production process of a manufacturing plant. These processes are commonly modelled, implemented and automated using Workflow Management Systems (WFMS). For managing a process using a WFMS, the process needs to be captured using a workflow specification using a workflow model and a workflow modelling language. The workflow model describes a set of concepts that are useful for describing, the processes, tasks, task dependencies, and the required roles. A workflow specification language can consists of rules, constraints, and/or graphical constructs which enables defining the control flow (task structure), data flow (information exchange between tasks), exception handling (i.e. actions to be taken in task failures), task durations and priority attributes for task scheduling.

For testing and debugging the processes, WFMSs provide testing tools to simulate the workflow processes by allowing input of sample data and triggering events such as task completion, deadline expiration, and exceptions. Once a workflow is implemented or instantiated, its progress needs to be monitored (i.e. for checking the status of a workflow, or determining bottlenecks). WFMSs provide GUIs that can present different views of workflow execution [30].

Apache Airflow is an open-source, Python-based programming framework for programming workflows. It manages a workflow as a Directed Acyclic Graph (DAG) of the related tasks. The Airflow’s inbuilt scheduler can execute the tasks sequentially according to the DAG while following the dependencies. It is possible to test the DAGs using the scheduler and Airflow supports real-time monitoring of workflow execution via the web browser-based UI [31].

AWS Step Functions is a WFMS. It models the workflows as state machines. The step function server performs the state transitions based on the task results, other inputs and timers and further handles task failures according to the specified retries and error messages. A graphical console is available for viewing the state machine structure and monitoring the real-time status of the steps along with a centralized detailed audit trails. Thus, makes it easy to diagnose and debug the issues [32].

//++ DG paper for FSM based approach for integrating processes from different enterprises.

//++

4.5.1.      Summary

The industrial processes heavily utilize and interact with industrial machines, people, and products each of them having their specific characteristics and behaviours as discussed in section 3. Thus a mechanism needs to be provided for enabling smoother interactions with the rest of the key elements and these characteristics need to be utilized to accurately identify the status of the currently executing activities.

4.6.  Platforms and frameworks for developing industrial IoT applications

Industrial platforms exist for developing industrial IoT applications [33-38]. Predix Platform is an asset-centric platform provided by General Electrics. It delivers capabilities for, maintaining asset connectivity, utilizing edge technologies, applying analytics and machine learning, and creating asset-centric digital twins to reflect the past and present conditions, and future predictions on the assets [17]. MindSphere is a cloud-based platform introduced by Siemens to connect the products, plants, systems, and machines, to provide monitoring of the system and to harness the information using the advanced analytics which supports the development of industrial IoT applications. This software suite provides simulation tools such as Simcenter and Tecnomatix for creating the simulation models of the products and production [39]. IBMs Watson IoT platform provides the ability to optimize industrial operations with their enterprise asset management which enables connection, tracking and assessing of the enterprise assets in cloud. These capabilities can be utilized to develop industrial IoT applications. IBM digital twin capabilities enable visualizing the performance of equipment in operations to identify potential problems thereby to perform predictive maintenance of the assets [36].

In academia, industrial automation systems have been explored in a number of researches [40]. However, very limited literature explores the area of industrial IoT application development. Tu et al. focus on IoT application modelling for Production Logistics and Supply Chain systems (PLSCs). They have proposed a novel framework to model the supply chain process and the different production stages by employing a combination of ontological and Petri Net (PN) based technique. The framework separates the IoT system design into three layers. At the top of the framework is the ontology-modelling layer. An ontology concept model is used by the second layer, the process-modelling layer. There the PN approach is employed to construct its structure. Object-modeling layer is at the bottom and represented using a Colored Petri Net (CPN) modelling scheme. These layers collectively provide a method to model an IoT application. The CPN model produced by the framework can be leveraged to implement the actual system. The study assumes an IoT-based PLSCs to be discrete-event processing system [41].

An agent-based smart factory framework has been proposed by Wang et al. for industry 4.0 scenario prototyping. In the proposed framework the smart floor objects such as machines, conveyors and products are classified and mapped to a predefined set of agents that are supported by central coordinating agents in the cloud with big data analysing capabilities. The predefined set of agents are the machining agents (machines that perform operations and testing), conveying agents (conveyor belts, robots for conveying the product), product agents (products that are manufactured by the system) and supplementary agents (acts as buffers and temporary holds the product agents). The central agents in the cloud receive the data on machines states and sensor data from various distributed sensors. The central agent process provided data to coordinate the behaviours of the distributed agents and to provide the feedback performance indicators to the autonomous agent system. Here the global state of the smart factory is maintained in the cloud. [42].

Kovalenko et al. have proposed a multi-agent-based control for improving the flexibility of a manufacturing system. The system consists of Product Agents (PAs) and Resource Agents (RAs). The study has proposed a finite state-machine based model to be used by the RAs to represent their resource capabilities. This reduces the communication overhead among RAs as RA share a subset of its capabilities with their neighbouring RA’s. Product Agents (PAs) has a process plan and it is maintained as an ordered list of physical properties. When a resource performs an action on a part relevant PA will be informed using the associated RFID information. In the actual implementation, the agent system communicates with the PLC system where the state transitions in RAs are mapped to PLC tags in the system and PLC handles communication with the field-level devices. For the implementation of an actual system all the system states, trigger events, product physical properties need to be accurately captured in this method [43].

4.6.1.      Summary

In section 3 we identified a set of key requirements that need to be provided for developing iIoT applications in general and more specifically to model the key element types. They can be provided at a framework level. According to the above analysis, it is apparent that most of the frameworks proposed do not deal with the identified set of requirements.

4.7.  A discussion on the different techniques used for modelling iIoT elements

Even though using domain-specific ontological modelling can be seen as a promising technology which ensures the data interoperability the development and maintenance can be costly and time-consuming and also require expert knowledge. Furthermore, in a highly dynamic and evolving area such as the industrial context, the domain-specific ontological models need to continuously evolve to provide reliable services. In contrast, the domain-independent ontological models are capable of offering a higher level of semantic query support for developing IoT applications in terms of describing the sensing and actuation capability of devices and can be considered reusable across domains as they are not bounded to domain-specific contexts.

A common issue with the autonomous agent-based approaches is the inability to directly influence the agent’s behaviours and decisions and agents relying on locally available data to make their decisions which can limit the ability to achieve system-wide optimum performances and goals [42]. Also, the implementation of this kind of models is highly time-consuming and requires an in-depth analysis of specific system capabilities to create an actual system. Furthermore, the implementation can be highly specific to a given system, thus lacks the reusability of the implemented system in a situation such as production line equipment change. Thus, these concerns can limit the ability of these models to provide IoT application development support requirements such as enabling application code reusability and loose coupling with underlying hardware systems. Additionally, most of the studies are focused on fully automated environments that only consist of machines and products as the common agent types. However, it also needs to be considered that the factory workers are still a part of many manufacturing systems. It is visible that there exists a lack of a framework which can model and describe iIoT for supporting the development of industrial IoT applications.

5.       RESEARCH AIM AND QUESTIONS

The aim of this research project is,

“to propose, design, implement, evaluate and validate a cyber-twins based framework to support and improve the development of industrial IoT applications that utilize the industrial Internet-of-Things.”

1. How cyber twins can model and describe the key elements of industrial Internet-of-Things?

This question identify and categorize the key elements of industrial Internet-of-Things that are utilized in industrial IoT applications. Furthermore, it identifies the important aspects and behaviours that need to be captured with related to each of the element to support the development of industrial IoT applications and explores the existing standards and programming paradigms that can be used to describe and model the above aspects.

2. How to use cyber twins for industrial IoT application development?

This question explores the novel programming primitives/constructs that underpin the development of a cyber-twin based industrial IoT application and explore how the application can be designed, implemented and tested using the cyber twins.

3. How to test and evaluate the cyber-twin based industrial IoT applications?

This question will address the tools and techniques for evaluating the industrial IoT applications developed using the cyber-twins framework.

6.       RESEARCH  METHODOLOGY

The focus of the research is to propose, design, implement, evaluate and validate a cyber-twins based framework to support and improve the development of industrial IoT applications that utilize the industrial Internet-of-Things. The Design Science Research Methodology (DSRM) model is chosen to follow during this research. This is an iterative methodology and consists of six steps. The steps are identifying the problem and the motivation, defining objectives of a solution, design and development of an artefact that solves the problem, demonstration of the use of the artefact, evaluating the artefact and communicating the results.

As the initial step first we conducted a systematic review of the existing literature and identify the research gaps that need to be addressed and justify the need for providing a solution. The lack of support and existence of a need to improve the support for iIoT application development is identified in general. Then the cyber-twin based framework is proposed to provide the identified development support for developing iIoT applications. The fundamental concept, the IoT device will be initially described, modelled, and implemented using the cyber-twins and a proof of concept implementation will be provided for it. The created artefact would then be demonstrated and evaluated and communicated. Then we will customize the IoT device model to design and develop more high-level concepts (i.e. the key elements of industrial IoT) and the framework which enables the development of iIoT applications which utilize the four elements. We will use experimental methodologies for evaluating the framework. Then the entire comprehensive solution would be communicated through publications.

7.       PROPOSED SOLUTION

7.1.  Cyber Twins

7.2.  Key Components of the Cyber-Twin Based Framework

7.2.1.   Key elements of industrial IoT

The machines, people, products and processes are the four key elements of the iIoT that are utilized in industrial IoT applications. Therefore, the cyber-twins based framework need to be able to describe and model each element. The cyber twin for a particular element needs to support the emulation and debugging, and monitoring and controlling of the modelled cyber twin to support the application development.

 

Figure 0‑1: Key elements of the cyber-twins based framework

 

7.3.  IoT devices: A semantic schema for describing IoT devices

Industrial IoT applications utilize IoT devices with different levels of complexities as people, products and machines. As the initial step, we propose an extension to an existing ontological schema to be able to describe the concept of an IoT device and it’s hardware and software composition.

The simple IoT device depicted in Figure 3 consists of a GPS sensor and an LED that is connected to a Raspberry Pi board which has the ability to connect to the network via the inbuilt WiFi module.

 

Figure 3: A simple IoT device and its composition

 

There exist standard and widely accepted ontologies such as SOSA[2] and SSN[1] which describes different aspects of sensors, actuators and related concepts. We propose the following extensions and changes to the SOSA/SSN ontology to be able to describe the additional concepts that need to be captured with related to an IoT device.

 

Figure 4: Semantic description of the IoT device using SOSA/SSN and the extended concepts

The software stack of an IoT device generally comprises multiple layers.

Operating System(OS) Software:

IoT devices with embedded systems do not run a separate comprehensive OS but provide a bare-metal software interface for IoT application to use the underlying hardware resources and others utilize existing kernels such as Linux.

IoT device software:

Some of the devices/machines needs to have a supporting software/hardware layer to enable the IoT application to access sensor readings or send control signals. The IoT device software includes the software components that are used by the IoT application to, communicate with the device hardware.

WiFi/ BLE enabled OBDII adaptors that are used to retrieve the data from a car run software which can read from the relevant OBDII protocols (i.e. ISO ) and made the data available over BLE/Wifi. These can also be called IoT device software as they enable the IoT application to communicate with the IoT device to retrieve data or perform actuation actions.

IoT application:

Harvest the data from, and/or perform actuation using an IoT device by interacting with IoT device software or its operating system software.

IoT device:

The IoT devices usually have computational power, storage capacity, sensing/actuation capabilities and the ability to establish the connectivity with a network to send/receive data. They utilize both hardware and software components to support this functionality.

8.       SIGNIFICANCE OF THE RESEARCH AND CONTRIBUTION

//an argument for the relevance and significance of the study, including the potential impact of the work beyond academe;

//++ Existing methods overview

This research address the much-needed support for developing industrial IoT applications by proposing a cyber twin based framework for modelling iIoT. This approach essentially simplifies the development of industrial IoT applications. The novel framework will provide,

• The ability to model, emulate and debug, monitor and control the key elements of industrial IoT.
• Techniques to customize cyber twins to represent specific instances of the key elements.
• Techniques to develop iIoT applications by utilizing cyber twins.
• Methods to test and evaluate cyber-twin based applications.

Furthermore, the approach will improve the code reusability, provides modularity that will increase the code reusability for applications and provide standardization via extending widely accepted and standard ontologies to describe its core concepts.

9.       TIMELINE AND SCHEDULE

//a proposed schedule and timeline for the phases of the study, based on the normal duration of candidature for the student’s program;

References

1. Compton, M., et al., The SSN ontology of the W3C semantic sensor network incubator group. Journal of Web Semantics, 2012. 17: p. 25-32.

2. Janowicz, K., et al., SOSA: A lightweight ontology for sensors, observations, samples, and actuators. 2019. 56: p. 1-10.

3. García-Castro, R., Haller,Armin ,Mihindukulasooriya,Nandana On the usage of the SSN ontology. 2019  [cited 2019; Available from: https://w3c.github.io/sdw/ssn-usage/.

4. Polic, A. and K. Jezernik, Closed-loop matrix based model of discrete event systems for machine logic control design. IEEE Transactions on Industrial Informatics, 2005. 1(1): p. 39-46.

5. B&R, PLCopen Motion Control. 2017, B&R.

6. Parker PLCopen State Machine. 2019.

7. Kollmorgen, PROGRAMMABLE AUTOMATION SOLUTIONS, in Automation and Motion Control 2017, KOLLMORGEN. p. 220.

8. Levin, J., Android Internals: A Confectionaer’s Cookbook. Vol. Volume I: The Power User’s View. 2015: Technologeeks.com.

9. PLCopen, IEC 61131-3: a standard programming resource. 2016.

10. QEMU. QEMU. 2019; QEMU is a generic and open source machine emulator and virtualizer.]. Available from: https://www.qemu.org/.

11. Inc, G. Run apps on the Android Emulator. 2019; Available from: https://developer.android.com/studio/run/emulator.

12. Cai, Y., et al., Sensor Data and Information Fusion to Construct Digital-twins Virtual Machine Tools for Cyber-physical Manufacturing. Procedia Manufacturing, 2017. 10: p. 1031-1042.

13. Seebo. Rapid deployment of Digital Twin software. 2019  [cited 2019 2019.07.07]; Available from: https://www.seebo.com/digital-twin-software/.

14. Siemens. Digital Twins. 2019  [cited 2019 01 Febuary 2019]; Available from: https://www.plm.automation.siemens.com/global/en/our-story/glossary/digital-twin/24465.

15. Bosch, Industry 4.0 at Bosch. 2019.

16. Stark, J.a., Product Lifecycle Management (Volume 3): The Executive Summary. 1st ed. 2018.. ed, ed. SpringerLink. 2018: Cham : Springer International Publishing : Imprint: Springer.

17. GE, Predix Platform. 2019.

18. Siemens, Electronics Works Amberg Digitalization Practices. 2017.

19. Siemens. Industry 4.0 Pioneer. 2019  [cited 2019 2019.10.02]; Available from: https://new.siemens.com/global/en/company/stories/research-technologies/digitaltwin/digital-twin.html.

20. Volkswagen. How Volkswagen is Developing the Car of the Future Virtually. 2019; Available from: https://www.volkswagenag.com/en/news/stories/2017/03/how-volkswagen-is-developing-the-car-of-the-future-virtually.html.

21. Rootman, S. Cognata Builds Cloud-Based Autonomous Vehicle Simulation Platform with NVIDIA and Microsoft. 2018  [cited 2018; Available from: https://www.cognata.com/cognata-builds-cloud-based-autonomous-vehicle-simulation-platform-nvidia-microsoft/.

22. Barbau, R., et al., OntoSTEP: Enriching product model data using ontologies. Computer-Aided Design, 2012. 44(6): p. 575-590.

23. Yoo, M.-J., C. Grozel, and D. Kiritsis, Closed-Loop Lifecycle Management of Service and Product in the Internet of Things: Semantic Framework for Knowledge Integration. Sensors (Basel, Switzerland), 2016. 16(7): p. 1053.

24. Yoo, M., et al. Semantic Model for IoT-Enabled Electric Vehicle Services: Puzzling with Ontologies. in 2016 IEEE 4th International Conference on Future Internet of Things and Cloud (FiCloud). 2016.

25. Min-Jung, Y., C. Grozel, and D. Kiritsis, Closed-Loop Lifecycle Management of Service and Product in the Internet of Things: Semantic Framework for Knowledge Integration. Sensors (14248220), 2016. 16(7): p. 1053.

26. Wang, C., Z. Bi, and L.D. Xu, IoT and Cloud Computing in Automation of Assembly Modeling Systems. IEEE Transactions on Industrial Informatics, 2014. 10(2): p. 1426-1434.

27. Arena, D., et al., Human resource optimisation through semantically enriched data. International Journal of Production Research, 2017: p. 1-23.

28. Arena, D., et al., Human resource optimisation through semantically enriched data. International Journal of Production Research, 2018. 56(8): p. 2855-2877.

29. Forkan, A.R.M., Montori, Federico, Georgakopoulos,Dimitrios,  Jayaraman,Prem Prakash, Yavari, Ali, Morshed, Ahshan, An Industrial IoT Solution for Evaluating Workers’ Performance via Activity Recognition, in 2019 IEEE 39th International Conference on Distributed Computing Systems (ICDCS). 2019, IEEE: Dallas, Texas, United States.

30. Georgakopoulos, D., Hornick, M. & Sheth, A, An overview of workflow management: From process modeling to workflow automation infrastructure. Distrib Parallel Databases (1995) 3: 119, 1995.

31. Airflow, A. Apache Airflow Documentation. 2019; Available from: https://airflow.apache.org/.

32. Amazon. Build distributed applications using visual workflows AWS Step Functions 2019; Available from: https://aws.amazon.com/step-functions/.

33. Oracle Digital Twins for IoT Applications 2017.

34. Microsoft. Azure Digital Twins. A service for building advanced IoT spatial intelligence solutions 2018; Available from: https://azure.microsoft.com/en-us/services/digital-twins/.

35. AG, S. Functionality within Cumulocity. Introduction to Cumulocity 2019  [cited 2019 2019.08.13]; Available from: https://cumulocity.com/guides/concepts/introduction/.

36. IBM. IBM launches Digital Twin capabilities for Design and Development. 2019; Available from: https://www.ibm.com/blogs/internet-of-things/new-digital-twin-capabilities/.

37.  ; Available from: https://www.plm.automation.siemens.com/global/en/our-story/glossary/digital-twin/24465.

38. KaaIoT. Configuration management. 2019  [cited 2019 2019.08.13]; Available from: https://docs.kaaiot.io/DOC/docs/current/Features/Configuration-management/.

39. AG, S. Digitalization in industry: Twins with potential. 2019  [cited 2019; Available from: https://new.siemens.com/global/en/company/stories/industry/the-digital-twin.html.

40. Vyatkin, V., Software Engineering in Industrial Automation: State-of-the-Art Review. IEEE Transactions on Industrial Informatics, 2013. 9(3): p. 1234-1249.

41. Tu, M., IoT-based production logistics and supply chain system – Part 1. Industrial Management &amp; Data Systems, 2018. 118(1): p. 65-95.

42. Wang, S., et al., Towards smart factory for industry 4.0: a self-organized multi-agent system with big data based feedback and coordination. Computer Networks, 2016. 101: p. 158-168.

43. Kovalenko, I., et al., Dynamic Resource Task Negotiation to Enable Product Agent Exploration in Multi-Agent Manufacturing Systems. IEEE Robotics and Automation Letters, 2019. 4(3): p. 2854-2861.