**Studies in Systems, Decision and Control 476**

Marcin Witczak Lothar Seybold Eric Bulach Niko Maucher

# Modern IoT Onboarding Platforms for Advanced Applications

A Practitioner's Guide to KIS.ME

# **Studies in Systems, Decision and Control**

Volume 476

### **Series Editor**

Janusz Kacprzyk, Systems Research Institute, Polish Academy of Sciences, Warsaw, Poland

The series "Studies in Systems, Decision and Control" (SSDC) covers both new developments and advances, as well as the state of the art, in the various areas of broadly perceived systems, decision making and control–quickly, up to date and with a high quality. The intent is to cover the theory, applications, and perspectives on the state of the art and future developments relevant to systems, decision making, control, complex processes and related areas, as embedded in the fields of engineering, computer science, physics, economics, social and life sciences, as well as the paradigms and methodologies behind them. The series contains monographs, textbooks, lecture notes and edited volumes in systems, decision making and control spanning the areas of Cyber-Physical Systems, Autonomous Systems, Sensor Networks, Control Systems, Energy Systems, Automotive Systems, Biological Systems, Vehicular Networking and Connected Vehicles, Aerospace Systems, Automation, Manufacturing, Smart Grids, Nonlinear Systems, Power Systems, Robotics, Social Systems, Economic Systems and other. Of particular value to both the contributors and the readership are the short publication timeframe and the worldwide distribution and exposure which enable both a wide and rapid dissemination of research output.

Indexed by SCOPUS, DBLP, WTI Frankfurt eG, zbMATH, SCImago.

All books published in the series are submitted for consideration in Web of Science.

Marcin Witczak · Lothar Seybold · Eric Bulach · Niko Maucher

# Modern IoT Onboarding Platforms for Advanced Applications

A Practitioner's Guide to KIS.ME

Marcin Witczak Institute of Control and Computation Engineering University of Zielona Góra Zielona Góra, Poland

Eric Bulach RAFI GmbH & Co. KG Berg, Germany

Lothar Seybold RAFI GmbH & Co. KG Berg, Germany

Niko Maucher RAFI GmbH & Co. KG Berg, Germany

ISSN 2198-4182 ISSN 2198-4190 (electronic) Studies in Systems, Decision and Control ISBN 978-3-031-33622-5 ISBN 978-3-031-33623-2 (eBook) https://doi.org/10.1007/978-3-031-33623-2

© The Editor(s) (if applicable) and The Author(s) 2023. This is an Open Access publication.

**Open Access** This book is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this book are included in the book's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the book's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.

The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

This Springer imprint is published by the registered company Springer Nature Switzerland AG The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland

*It always seems impossible until it is done. Nelson Mandela*

# **Preface**

Constant cost pressure forces companies worldwide to work continuously on optimizing internal processes, and hence, improve their overall effectiveness and performance. However, to achieve such a challenging goal, the underlying processes have to be measurable and transparent. This means that irrespective of the considered area, i.e., production or logistics, a set of suitable measures has to be introduced. In production companies, the real-time and automatic recording and displaying of parameters related to quality, performance and availability are of paramount importance. Indeed, they enable optimization in manufacturing processes and automatic calculation of overall equipment effectiveness (OEE) indicators. Another common approach is to employ statistical process control (SPC), which makes it possible to get a predictable behaviour of the manufacturing system and keep its crucial parameters under the constrained control limits. Irrespective of the approach being used, the resulting data can be used, e.g., to measure and analyse downtimes, bottlenecks and other causes of inappropriate performance. As a result, a dedicated implementation of the process optimization and efficiency improvements can be applied.

There is no doubt that digitalization solutions from Industry 4.0 and the Internet of Things (IoT) can be perceived as excellent candidate strategies capable of handling the above stated issues concerning measurements and transparency. However, IoT tools themselves can provide appropriate data only while their efficient integration and application are possible using a dedicated onboarding platform only. To settle this issue, the book undertakes the problem of modern IoT onboarding platforms for the advanced applications pertaining to manufacturing and logistics. In particular, instead of deliberating about a possible hypothetic platforms, an existing and efficient one is employed, which is called KIS.ME. KIS.ME (Keep It Simple. Manage Everything), is a complete IoT solution for a simple integration in manufacturing and logistics. It is composed of a set of hardware devices (KIS.BOX, KIS.IO and KIS.LIGHT), which are intuitively integrated with the cloud platform called KIS.MANAGER. Moreover, the entire platform is an open one, and hence, it enables communication with external services using KIS.API architecture. The application range of KIS.ME is extensive. This is due to the intuitive implementation and visualization of a user-defined KPIs (key performance indicators), which constitute effective optimization measures. Thus, the potential areas of application of KIS.ME are, e.g., manufacturing, warehouse management and logistics. Indeed, triggering and/or ordering various tasks can be immediately and efficiently implemented with KIS.ME. Such an approach translates directly to the savings of the time and energy.

The book starts with an introductory IoT overview related to its selected scope of applications. Subsequently, a gradual introduction to KIS.ME platform is presented, which constitutes the base for further advanced applications including logistics, control and maintenance of various processes. Finally, the potential of KIS.API communication framework is utilized for an efficient communication with external services. The book contains also training exercises, which gradually introduce the reader into the arcane details of KIS.ME.

Berg, Germany October 2022

Marcin Witczak Lothar Seybold Eric Bulach Niko Maucher

# **Contents**

### Contents xi

# **Acronyms**

# **Chapter 1 Introduction**

# **1.1 IoT Overview**

The Internet of things (IoT) [1–3] can be formulated as a system of mutually related objects, computing devices, machines, animals, or people, which are equipped with unique identifiers and the possibility of transferring data over a network without the necessity of human-to-human or human-to-computer interactions. Thus, an IoT system consists of connected assets, which can communicate and share information.

The IoT enables assets to observe and interact with the surrounding environment, i.e., they can hear, see, "think" and perform the required actions while sharing information and coordinating decisions. As a result, the IoT transforms the form of these assets from traditional into a smart one. Such a transformation is realized with several important technologies related but not limited to computing, embedded devices, sensor networks, communication strategies as well as Internet protocols. Figure 1.1 illustrates a general IoT structure. The development of the IoT field is persistently stimulated by its application in several domains like the following:

The objective of the subsequent sections is to briefly review application of the IoT in selected areas. In particular, the review should be perceived as a radar of the main trends rather than a complete state-of-the art analysis.

# *1.1.1 Logistics and Transportation*

The section aims at providing a review of selected works concerning logistics and transportation application. The concept of smart logistics [6] and the related tech-

**Fig. 1.1** General IoT architecture

nology can be clearly visualized using Fig. 1.2. As in other areas, the number of IoT applications is proliferating constantly. This can be clearly seen in the recent survey papers [4–6]. Nevertheless, there are general application areas, which can be split into the following categories:

Thus, the objective of the remaining part of this section is to provide a concise overview of the content of those papers. In particular, in [18], the authors show how to integrate a cloud manufacturing infrastructure with the IoT. As a result, a multilevel dynamic adaptation of a smart logistic synchronization control is attained. The problem of optimizing manufacturing time and energy consumption within a reasonable computing time is proposed in [19]. Such an effect is achieved with an IoT infrastructure coupled with self-organizing configuration mechanisms as well as the related data-driven models. An intelligent IoT-based dispatching platform is proposed in [20]. It couples the IoT with a multi-objective optimization model and a two-level optimization algorithm, which uses the celebrated Dijkstra strategy along with an ant colony approach. A method integrating the blockchain with the IoT is proposed in [21]. The paper shows two real-life examples, which tackle the design and deployment of a logistic and transportation system. In [22], a logistic service supply chain coupled with an IoT-based logistic/service, information and fund flow

**Fig. 1.2** Smart logistics components

is analysed. A decomposition strategy of a complex distribution network is presented in [23]. This is attained by splitting it into smaller nodes, communicating via the IoT. In particular, the IoT forms the basis for a digital twin of the real system, which enables its efficient functioning. An IoT-based real-time sensing model of logistic resources is proposed in [24]. It enables dynamic task distribution within a logistic system.

Several interesting strategies are also proposed in the context of vehicle tracking and monitoring. Indeed, the IoT equipped with a combination of GPS and GSM/GPRS technologies is used to transmit vehicle coordinates and store them in a designated database [25]. The IoT is also employed to vehicle traffic congestion monitoring and control [26]. This strategy allows providing the status and density of the traffic, both of which are transmitted using the Bluetooth technology. Apart from vehicle tracking, a cargo monitoring system is proposed in [28], where cargo tracking is realized with real-time data gathering and suitable information processing. Another IoT-based intelligent cargo tracking system is presented in [27]. It overcomes the unappealing effect of losing GPS signals in environments like dense urban areas and underground tunnels. In particular, a combination of radio-frequency identification and a global system for mobile communication is efficiently used to overcome the difficulties with GPS. In [29], an intelligent cargo solution is proposed, which adapts the IoT to spread information processing between mobile and distributed devices. As a result, they are communicating with themselves as well as with a dedicated platform. The services provided by this platform include cargo localization, rerouting and condition monitoring without human intervention.

Another important aspect pertaining to the performance and safety of logistic and transportation systems is human factors. Indeed, it is very important to monitor driver behaviour in real-time. For that purpose, the work [30] proposes a fusion of the IoT and fog computing. In this architecture, all of the driver's influential, environmental, and vehicle factors are analysed using multiple sensors. In [31], a connected car architecture along with an IoT architecture is used for designing a model for driver behaviour analysis. The strategy is implemented with embedded devices, smartphones as well as a dedicated cloud service. A driver style assessment system is presented in [32]. It uses a dedicated IoT to assess of the driving style using vehicle measurements like speed, acceleration, jerking, engine rotational speed as well as driving time.

The last group of logistic and transportation systems concerns warehouse management as well as related forklift performance. In [33], the authors propose an IoT-based warehouse management system with advanced data analysis and computational intelligence. The system aims at increasing productivity and picking accuracy, efficiency as well as robustness to order variability. The work [34] proposes an IoT infrastructure which combines location information with warehouse working procedures. The system uses a proactive tracking architecture employing the iBeacon tag technology and the concept of distributed gateways. There are also several works dealing with forklifts, e.g., [35, 36]. In the first one [35], a forklift is equipped with an RFID transceiver, a pallet cage as well as electromagnetic field measurement. These can then be used for various analytical deliberations. The second work [36] tackles the problem of improving forklift dispatching and reducing a costs associated with the delays of loading/unloading delivery trucks. For that purpose, forklifts are equipped with sensor nodes that enable collecting such data as the forklifts' physical location, usage time, bumping/collision history, and the battery status. Finally, the information acquired is combined with inventory information and fed into a sophisticated stochastic learning system, which generates dispatching recommendations.

### *1.1.2 Industrial Applications*

As in the case of logistics and transportation, the number of industrial IoT application is also proliferating constantly. This can be clearly seen in the recent survey papers [7–10, 37]. Generally, industrial applications can be split into the following categories:

These application areas are rather evident as it is obvious that in any kind of industry one can easily find PLCs and SCADA systems. Thus, in [43], a device called an IoT-PLC is proposed, which can be perceived as a PLC tailored for Industry 4.0. The crucial feature of this device include: regulatory control capabilities, fog-computing functionalities such as filtering and field data storage, and multiple wireless interfaces managed independently. It also uses digital twins of real devices, and hence it can transparently interact with the upper cloud level. As the IIoT can be be implemented for critical infrastructures, while attacks on them may cause significant disruptions. In [54], the authors developed a PLC and IoT-based indoor power line communication system. Subsequently, the work [44] investigates an approach for efficient transmission of data between the PLC and cloud platforms.

As SCADA systems are commonly used to control IIoT, the authors of [45] investigate the results of attacking them and provide some general guidelines for security improvement. In [47], a SCADA system which is based on an open source Thinger platform is proposed. It incorporates IoT-oriented web services with the conventional SCADA. The IoT infrastructure includes several sensors, e.g., current and voltage ones, which are used for control purposes. In [48], the authors investigate security and privacy of SCADA-based IoT critical infrastructures. In particular, a dedicate toolbox is proposed, which can tackle the above issues in an efficient way. The toolbox incorporates such functionalities as cryptography-based access to cloud services using identity-based cryptography and signature schemes at the fog layer. A SCADA system which integrates the IoT technology for real-time water quality monitoring is proposed in [49]. The developed system can determine the contamination of water, leakage in pipelines, and some crucial water parameters, e.g., temperature, flow, color, etc. Subsequently, an IoT platform for real-time production performance analysis and exception diagnosis is proposed in [55]. As a result, a decision tree is used for diagnosing exceptions and providing concise information about them.

Another industrial application concerns the development of widely understood cyber-physical systems. In particular, in [56], the authors proposed a platform and software architecture describing features like semantic device interoperability and entity virtualization. This IoT-oriented strategy allows locating and selecting available resources and devices. A wireless senor network-based process automation monitoring architecture is proposed in [41]. In the approach, the monitoring information is shared in accordance with widely used management standards. In [52], a cyber-physical system which makes it possible to virtualize manufacturing resources is proposed. In the work [57], the authors present an IoT architecture which translates unique identifiers of physical objects to concrete network addresses. As a result, information about an object, e.g. its status, location, etc., can be extracted. An IoT architecture based on the OPC.NET specification which can be employed for both industrial applications and smart buildings is proposed in [58]. A cyber-physical architecture for the Industry 4.0-based power equipment detection system is proposed in [51]. It integrates many kinds of technologies, including virtual instrumentation, detection and measurement, mechanical and electrical devices, network communication and mobile clients. As a result, the cyber-physical system provides coordination among networks and physical layers. This should be realized by a suitable symbiosis of computation, communications and control (3C) technologies. The resulting 3C framework can perform real-time sensing, control and diagnosis of complex industrial systems [59].

Finally, an IoT system capable of localizing mobile robots is proposed in [50]. It employs neural networks (see, e.g., [60, 61]) for image processing purposes. The resulting mechanism uses the topological mapping method to gain orientation in the explored environment.

### *1.1.3 Agriculture and Environmental Applications*

The number of agriculture-oriented applications is also constantly increasing, and hence their optimization with respect to various factors, e.g., water consumption or soil quality, is of paramount importance. Apart from agriculture, we are currently witnessing a significant development of green energy sources. In both, these fields, the IoT technologies [12–14] play crucial roles in fostering their further development. Indeed, the development areas can be roughly characterized of:

In [74], the authors proposed solar tracking system, which eliminates the unappealing shading effect of nearby solar panels, which is encountered in instant positioning of solar panels. They tackle this problem through the use of an IoT-based solution deployed in solar panels, which increases solar energy harvesting efficiency. The work [62] proposes a new energy management strategy for solar-powered devices that intend to power the load directly from the solar cell. This strategy avoids converting and storing the energy, which eliminates losses. Concerning wind turbines, the work [71] uses the IoT for monitoring their behaviour. The authors of [72] analyse recent trends in the application of the IoT in energy generation, specifically in relation to wind energy generation. They investigate potential uses of the IoT pertaining to its integration with energy generation systems, monitoring and control, as well as maintenance and prediction. The interesting work [73] proposes an 8×8 (64) IoT-based wind farm platform which is built using miniaturized wind turbines with wireless connectivity. Such an IoT grid can measure wind speed and wind direction, which is necessary for optimal wind farm management. The work highlights the potential of using an inexpensive wireless, battery-powered IoT rather than a data-logger that has limited data storage and cannot be accessed remotely.

Concerning agricultural applications, an intelligent approach for efficient plant irrigation is proposed in [70]. It utilizes the IoT and a set of sensors for recording plants data as well as their watering requirements. The system is implemented with a mobile phone, and hence it allows continuous monitoring and control of irrigation efficiency. The work [63] proposes a framework for green mobile crowd sensing. The approach is designed in such a way that only a selected set of best performing sensors is used, which allows significant energy savings. An IoT-based real-time microclimate monitoring system is proposed in [64]. The system includes temperature and relative humidity sensors, powered by solar panels. An environmental monitoring system for apple orchards is presented in [65]. Subsequently, a framework for monitoring multi-layer soil temperature and moisture is proposed in [66]. The framework consists of monitoring nodes, a gateway node and a system platform. The authors of [67] propose an IoT solution for water quality assessment through the measurement of conductivity, temperature, and turbidity. In [68], an IoT infrastructure is presented which consists of sensor nodes providing hydrographic information. Finally, an IoTbased water irrigation scheduling platform is proposed in [69]. In particular, the authors develop a decision support system for irrigation scheduling of olive fields.

### *1.1.4 Hospitality and Leisure Industry Applications*

Since the hospitality and leisure industry plays an important role in our lives, the IoT technology also contributes actively to their permanent development [15, 16]. The main trends can be summarized as follows (cf. Fig. 1.3):

The paper [75] proposes a location recognition algorithm for automatic check-in applications. It can be implemented with smartphones and integrated with a designated cloud platform. The system uses GPS and WiFi access points, which results in a new strategy called a WiFi fingerprint. In [76], the authors propose a malicious check-in defense scheme. They also use the concept of the WiFi fingerprint and make it secure against in unpermitted access. Another improvement of the scheme proposed in [75] is given [81]. The contribution enhances the existing strategy and

eliminates the need for using GPS. Another automatic vehicle check-in check-out strategy is proposed in [82]. It eliminates the manual entry process and minimizes the security personal effort by exploiting the image data of the vehicle number plate. The work [77] highlights the application of a wristband (Disney's MagicBand) that serves in Disney World as a credit card, FastPass, hotel key, etc. The authors investigate the IoT impact on enhancing guest experience as well as to better understands guest behaviour and needs. Another IoT cashless payment system for the hospitality industry is proposed in [79]. Subsequently, in [78], the authors explore the influence of demographic factors (education, gender, age, etc.) on consumer attitudes and intentions for using IoT in the hospitality industry. The work [83] proposes an IoT architecture for the hospitality industry located in the so-called smart cities. Finally, an IoT-based authentication system for a remote opening and closing door lock is presented in [84].

### *1.1.5 Healthcare*

Similarly as in the hospitality and leisure industry, the number of IoT applications in healthcare is proliferating [17]. Generally, the applications can be split into two groups:

In particular, the work [85] proposes a new signal quality-aware IoT electrocardiogram telemetry system for continuous cardiac health monitoring. Similarly, IoT electrocardiogram telemetry is used in [91, 92] analysis and classification pertaining to heartbeat diagnosis. An IoT-based e-health monitoring system is proposed in [93]. An appealing property of this approach is that it aims at controlling temperature raising caused by an on-body sensor, which affects skin comfort. An IoT system monitoring cardiac arrhythmia is presented in [86]. Moreover, an IoT-based heart rate monitoring system is proposed in [94].

Concerning patient behaviour, the authors of [87] propose an IoT device in the form of wearable smart glasses, which are able to monitor eye blinks. In [88], a healthcare digital twin of a patient is presented which utilizes the IoT technologies and AI models to diagnose the state of health and provide a set of clinical questions leading to the final diagnosis. The authors of [89] employ a foot movement monitoring strategy for detecting an early stage of the Alzheimer disease. Finally, the work [90] proposes an IoT system which aims at enhancing speech-language capabilities of patients with Parkinson's disease.

### **1.2 Where Does KIS.ME Go?**

Permanent cost pressure rises the need for a continuous optimization of internal processes, and hence, improve their overall effectiveness and performance. To attain such a challenging objective, the underlying processes have to be measurable and transparent. This means that irrespective of the considered application area, a set of suitable measures has to be introduced. Generally, the real-time and automatic recording and displaying of parameters related to quality, performance and availability are of paramount importance. Indeed, they enable optimization in manufacturing processes and automatic calculation of OEE (overall equipment effectiveness) indicators. Another common approach is to employ SPC (statistical process control), which makes it possible to get a predictable behaviour of the manufacturing system and keep its crucial parameters under the constrained control limits. Irrespective of the approach being used, the resulting data can be used, e.g., to measure and analyse downtimes, bottlenecks, and other causes of inappropriate performance. As a result, a dedicated implementation of the process optimization and efficiency improvements can applied.

There is no doubt that digitalization solutions from Industry 4.0 and the Internet of Things (IoT) can be perceived as excellent candidate strategies capable of handling the above stated issues concerning measurements and transparency. Such solutions should be applicable for both humans and the machines. Even more, they should integrate them to make their cooperation as efficient as possible.

Therefore, instead of deliberating about hypothetical IoT onboarding platforms capable of handling the above stated challenges, an existing and efficient one is employed within the framework of this book. The onboarding platform is called

KIS.ME and the remaining part of this section answers all crucial questions pertaining to its practical advanced applications.

KIS.ME (Keep It Simple.Manage Everything) is an IoT platform which was designed under the light of the following sentence:

*Digitization made easy: It can be this easy to optimize your process and increase efficiency.*

The justification of this sentence can be split into four crucial components (Fig. 1.4):

Let us start by stating fundamental questions concerning communication:

To answer these, it is assumed that the processes considered are discrete- event ones [95, 96]. To make the discussion clearer, let us provide the definition of the system state, which is a set of variables that can be used to describe the system's past and future behaviour. Thus, the discrete event system is a discrete-state, event-driven one. This means that its state can only take discrete values from a possibly infinite set. Moreover, its state evolution depends solely on the occurrence of discrete events over time. In the IoT framework, events can be generated using both IoT devices and the cloud platform connected with them. Under these preliminaries, one can quickly figure out that buttons and lights are the most common communication tools used by human operators. Contrarily, machines can be communicated through various inputs and outputs located at their inlets and outlets, respectively. Thus, by finding a common denominator between humans and machines, KIS.ME offers three devices:

KIS.BOX: a two-button box with digital inputs/outputs, KIS.LIGHT: a signal lamp with digital inputs/outputs. KIS.IO: an input/output communication box.

**Fig. 1.4** KIS.ME:

deploy, control

These KIS.Devices are communicated through WiFi and should be perceived as a universal hardware inherently integrated with the cloud application called KIS.MANAGER. Note that both devices can communicate discrete states through both digital inputs/outputs or by illuminating colors with the buttons and a lamp.

Let us proceed to crucial questions pertaining to the development stage:

The answer to the first question is associated with preparing a KIS.Device installation scheme, i.e., it should be located in such a way as to provide appropriate transition of the discrete state. This can be realized through colored lights or digital inputs/outputs of KIS.Devices. The second question is answered by the functionalities of KIS.MANAGER. In particular, it can process the data gathered from KIS.Devices and interact with them through the so-called Rule engine, which should be perceived as a rule base shaping system behaviour. As for third question, it is necessary to explain that the data from KIS.Devices is represented in KIS.MANAGER with the so-called Datapoint. Each numerical or logical Datapoints can be visualized, processed or analysed within a given period. As a result, key performance indicators (KPIs) can be intuitively formulated using a predefined list of commands. Moreover, system transparency can be settled with digital twins of KIS.Devices that can be obtained in KIS.MANAGER. Additionally, digital twins can be located within the floorplan, which is a virtual counterpart of the real system structure. To answer the last question, appropriate KPIs and performance cost functions can be defined. They can be used for the calculation of overall equipment efficiency (OEE) as well as to form control charts to be used for observing and analysing system predictability. Indeed, these control charts form the basis for statistical process control (SPC), which is a commonly used tool for assessing system performance and predictability.

Usually the deployment stage can be a bottleneck on the way towards better performing systems. Indeed, it frequently requires integration of hardware and software provided by different manufacturers. As a result, a third party integrator is usually needed, to make it possible to complete the deployment stage. KIS.ME provides an integrated hardware/software platform, and hence the deployment stage is significantly simplified and does not require extraordinary efforts or costs. In other words, an optimally performed development stage yields smooth realization of the deployment one.

The control stage addresses the following questions:

KIS.ME provides all necessary and sufficient tools for assessing individual or combined processes' availability. This can be achieved with KPIs calculating an exact run time of the associated equipment. Subsequently, it can be compared with the planned time. Similarly, knowing an ideal process cycle time, a KPI can be implemented calculating the total number of process cycles. Finally, by multiplying it by the ideal process cycle time and then comparing the result with the run time one can obtain process performance. Process quality can be measured in a binary way or with multi-valued quality levels. In both cases KIS.ME can provide a suitable set of KPIs capable of assessing process quality in an intuitive and efficient way.

To answer the last question we should clarify when the process in the statistical control state. Namely, the process is in the state of control if it is subject to common cause variations only, which can be expected in any set of observations. These common cause variations are predictable and limited, e.g., the discrepancy between consecutive battery mounting times. Indeed, it varies in time but it is possible to assess the range of its variability. Contrarily, special cause variations can be associated with unexpected and unappealing factors that impair process realization, e.g., an equipment fault, quality issues, human operator-related issues, etc. As a result, it is said that the process is in the out-of-control state if it is subject to both common and special cause variations. Thus, apart from the inevitable random and typical fluctuations, other unappealing factors affect process parameters. All these factors can be communicated to KIS.MANGER using KIS.Devices.

Although KIS.ME was originally intended for logistic and industrial applications, it can be applied to settle various tasks encountered in Industry 4.0 and beyond. Thus, the objective of the subsequent part of this book is to introduce the reader into the arcane details of KIS.ME.

### **1.3 Contents of the Book**

The reminder of the book is divided into six chapters and two appendices. However, the book can be generally divided into two parts. The first one introduces the KIS.ME platform as a modern IoT onboarding one. The second one discusses theoretical and practical aspects of applying such a platform for a wide spectrum of advanced applications ranging from logistics and SPC to advanced process and transportation scheduling algorithms. In particular, Chap. 2 introduces the reader into the KIS.ME IoT platform and its hierarchical overview. It discusses also an intuitive concept of Datapoints, which constitute the main source of knowledge about the current status of an asset. It is also shown how to place assets inside workspaces and associate with them a set of functional rules using Rule engine. In Chap. 3, a set of practical guidelines for implementing various logistics-oriented applications is presented. This part starts with a crucial issue pertaining to access control using KIS.Devices and external RFID readers. The remaining three sections deal with transportation systems as well as their digitization and visualization. Subsequently, Chap. 4 aims at introducing the concepts of calculated Datapoints and key performance indicators, which form the basis of statistical process control. Having such tools, a set of widget charts is introduced, which enable data visualization and analysis. Subsequently, practical examples concerning the development of statistical control charts are presented. Chapter 5 aims at exploiting the methods and tools described in the preceding parts to develop a set of selected process monitoring and control schemes. In particular, it starts with the transportation system, which operates on a set of selected routes. To measure the performance of such a system, a suitable cost function is introduced, which can be monitored and controlled by the designated supervisor. Subsequently, quality control strategies are proposed and described in detail. The last process monitoring strategy aims at calculating and visualizing overall equipment efficiency, which is widely perceived as a key measurement tool for assessing both productivity and efficiency. The objective of Chap. 6 is to provide a list of selected potential applications of KIS.ME. They stem from scientific deliberations of the authors and can be perceived as prospective proofs-of-concept, which can be deployed in various industries. The chapter starts with modelling users and their interactions, which include various important components, e.g., experience and performance. The resulting models make it possible to schedule the work of human operators in a reasonable and predictable way. The chapter discusses also the issues of health-aware and fault-tolerant control and shows a general solution which can overcome these important problems. Subsequently, the objective of Chap. 7 is to provide a concise overview of KIS.API, which can be used for an effective communication with external applications.

All chapters are summarized with a set of exercises motivating the reader to obtain further skills pertaining to practical applications of the modern IoT.

Finally, Appendix A provides a list of KIS.ME commands along with their sample applications. Similarly, Appendix B surveys KIS.ME Datapoints along with their example applications.

### **References**

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Chapter 2 Onboarding and Preliminary Functionality Training**

# **2.1 Preliminaries, Registration and Onboarding**

Let us start with introducing the definition of a system, which is a part of the universe that can be affected and/or monitored by KIS.ME. Consequently, KIS.ME can be divided into two layers:

KIS.Device: hardware capable of performing the desired communication tasks within the system,

KIS.MANAGER: software being a web platform used to affect and/or monitor the system.

Having the system, it is possible to introduce its components, which are defined as assets. They are physical parts of the system and are exemplified by KIS.Devices.

# **•** > **Unique resource name (URN)**

Each KIS.Device is uniquely identified by the URN number, e.g.,

```
urn:rafi:sbox:9c65f93cbf2d.
```
Once assigned, it cannot be further modified.

Thus, an asset group is simply a set of assets. In the current release of KIS.ME, KIS.Devices are divided into

KIS.BOX: a communication push-button box (see Fig. 2.1), KIS.LIGHT: a communication signal lamp (see Fig. 2.2), KIS.IO: an input/output communication box (see Fig. 2.3).

Let us start with defining two kinds of LED lights incorporated within each KIS.Device (see Figs. 2.1 and 2.2):

Status LED: it exhibits the functional state of a KIS.Device and is defined in Table 2.1;

**Fig. 2.3** KIS.IO

**Fig. 2.1** KIS.BOX

**Table 2.1** Status LED colors and their meaning

**Table 2.2** Predefined operational LED colors

Operational LED: it exhibits the individual operational state of a KIS.Device and can be defined by the user using the set of colors provided in Table 2.2.

Note that KIS.IO can be perceived as a simplified version of KIS.BOX without buttons. Subsequently, a general KIS.ME framework overview can be introduced, which is portrayed in Fig. 2.4. Subsequently let us proceed to introduce KIS.Device functionalities. As can be observed in Fig. 2.4, each KIS.BOX can be perceived as a human-machine interface (HMI) with two push-buttons, linked with the KIS.MANAGER via WiFi. Each pushbutton contains an operational LED, which illuminates in an RGB color. However, for the sake of simplicity, the list of colors is limited in KIS.MANAGER to those presented in Table 2.2. Thus, they can be identified by either the RGB HEX code or an integer value. It should be also noted that the black color is used to signify the fact that a corresponding operational LED is not lit. Compared to the KIS.BOX, KIS.LIGHT has limited functionalities as its pri-

**Fig. 2.4** General KIS.ME overview

**Fig. 2.5** KIS.Device M12 connections

mary purpose is to be a signalling lamp with one operational LED only. Finally, the essential technical parameters of KIS.Devices are given in Table 2.3. It can be noted that each KIS.Device is fed with an M12 8-pin A-coded connection terminal, while the purpose of particular PINs is given in Table 2.4. The operating voltages can be either 5 V or 24 V. In the first case, a KIS.Devices are fed through USB, while in the second one, the respective 24 V voltage is fed through PINs 1 and 3. Each KIS.Device possesses a general purpose input output (GPIO) interface, which is available while using a 24 V power supply only. As can be observed in Table 2.4, GPIO is composed of two digital inputs and two outputs. Thus, each KIS.Device enables attaining the functionalities portrayed in Fig. 2.5, which can be further exploited in a large number of practical applications. Finally, it should be noted that a full technical documentation of KIS.Devices is available at https://kisme.rafi.de/en/. Having the hardware layer provided, let us proceed to the software one. As can be observed in Fig. 2.4, the main KIS.MANAGER features can be summarized as follows:

Having a general overview of both hardware and software functionalities, let us proceed to onboarding, i.e., the process of linking KIS.Devices with the KIS.MANAGER. However, a preliminary step towards onboarding is to register at the KIS.MANAGER, which can be easily realized with https://kismanager.rafi.de. Once a user company account is created, a compulsory checklist should be verified:

After completing the compulsory checklist, one can perform the onboarding procedure:

Step 1. Connection:

Step 2. Authentication:

Step 3. Upload onboarding.zip onto the KIS.Device visible as a mass storage device.

### Step 4. Processing onboarding.zip:

Step 5: Onboarding completion:

# **•** > **Changing WLAN**

The WLAN data, and hence the WiFi network, can be changed on demand by simply repeating the above Step 1–Step 5 onboarding procedure.

# **•** > **Accessing the KIS.ME demo**

It is possible to preview KIS.ME performance without having your own KIS.Devices. For that purpose, a KIS.ME demo platform was designed, which can be accessed by performing the following steps:

	- Username<EMAIL_ADDRESS>	- Password: Demo1234!.

# **2.2 Hierarchical Structure: From Assets and Users to Workspaces**

The objective of this section is to provide a general KIS.ME-based system structure overview. For that purpose, let us introduce a suitable nomenclature:

User group: a set of users with a predefined KIS.MANAGER rights level, Asset group: a set of assets,

Workspace: a selected part of the system, which inherits its desired set of assets.

From the above definitions, it is evident that Workspace and Asset group can be somehow perceived as synonyms. Indeed, while going to Main menu → Asset groups, one can see the view which is portrayed in Fig. 2.6. Thus, all system assets associated

**Fig. 2.6** Asset groups

with all KIS.Devices are contained in the inventory asset group My devices. KIS.ME, which makes it possible to arrange five workspaces (see the column Definition in Fig. 2.6) may inherit the assets contained in the inventory asset group.

# **•** > **Adding asset groups**

The current licence model allows six asset groups, i.e., My inventory, Workspace 1–Workspace 5. In the prospective licence models, it will be possible to add new groups.

Once Asset groups are defined, it is possible to proceed to User groups, which can be reached through Main menu → User groups. As can be seen in the column Description in Fig. 2.7, there are four predefined user groups: Admin, Installer, Operator and Observer, possessing various rights and permissions (see Sect. 2.3 for details). Thus, a single user may belong to these groups, which strictly defines rights and permissions. On the other hand, all five workspaces can also be perceived as user groups.

# **•** > **User group membership**

A single user may belong to multiple user groups, which define rights and permissions. This also means that he can belong to multiple user groups associated with workspaces, which clearly determine access to the desired asset groups.

### **Fig. 2.7** User groups

Finally, the KIS.ME hierarchical structure can be expressed using Fig. 2.8. Thus, the objective of the subsequent section is to provide a concise overview pertaining to rights and permissions acting inside this structure.

### **2.3 Rights and Permissions**

Let us start with four predefined user groups (see Fig. 2.7), which are initially called Admin, Installer, Operator and Observer. Their concise overview is given in Table 2.5, which uses the following nomenclature:

Access: the user has access to a given feature; Add/delete: the user is able to add and/or deleted a given feature; Manage: the user is able to manage the properties of a given feature; View: the user is able to view a given feature.

# **•** > **Names and permissions of predefined user groups**

It should be noted that the initial names of predefined user groups can be modified. Alterations can be also performed with respect to their permissions (see Fig. 2.14).

### *2.3.1 User Management*

The process of adding a user is very intuitive but requires access with admin rights (see Table 2.5). Under such a condition, adding a new users and assigning them the desired rights boils down to the following steps:

# **•** > **Initial state**

The Initial state field determines whether the new user must agree (terms of acceptance pending) to an end user license agreement or whether this can be omitted and the user can be active immediately (Active).

### 2.3 Rights and Permissions 29

**Table 2.5** Rights of predefined user groups

# **•** > **Admin and workspaces**

Irrespective of the workspaces being assigned, a user with admin rights has access to all of them (see Table 2.5).

6. After pushing the Save button, the user will receive an e-mail that contains a link which enables providing a password.

Finally, any modification pertaining to an existing user can be realized with the above procedure. However, instead of Step 2, an existing user has to be selected from the available user list.

### 2.3 Rights and Permissions 31

**Fig. 2.10** Creating a new user: user groups

**Fig. 2.11** Assigning a user to user groups

### *2.3.2 User Groups and Workspace Management*

As mentioned in the preceding section, each user can belong to multiple user groups. The permissions of a given user group to another one can also be freely defined. Indeed, while going to Main menu → User management → User groups, one can see the view portrayed in Fig. 2.7. Subsequently, by selecting any group, e.g., admin, one can see the view shown in Fig. 2.12, which contains essential details about this group. By selecting the Edit button , one can see the view presented in Fig. 2.13. As can be observed, there are two tabs:

Info: it contains the name, description and other descriptive parameters of a group; User Groups with Access Permissions: it pertains to the list of user groups for which a given access group has access permission (see Fig. 2.14).

# **•** > **Assigning users to a group**

It should be mentioned that by proceeding to Main menu → User management → User Groups and then selecting a desired group, one can see the view portrayed in Fig. 2.12. By pushing the Assigned Users button , it is also possible to edit the user assignment.

### 2.4 Asset Management 33

**Fig. 2.13** Editing a user group: info

### **2.4 Asset Management**

The objective of the preceding sections was to perform a suitable introduction to the hierarchical KIS.ME structure along with the KIS.Device onboarding procedure. As a result of performing onboarding on a set of assets, one can see a view similar to that presented in Fig. 2.15. Indeed, it can be easily accessed with Main menu → Assets. This sample view indicates that there are eight KIS.Devices, i.e., four KIS.BOXes and

four KIS.LIGHTs. It can be also immediately deduced (see the Connection column) that, except for KIS.BOX 0 and KIS.LIGHT 3, all KIS.Devices are connected with KIS.MANAGER via dedicated WiFi(s). Subsequently, by selecting a sample asset, e.g., KIS.BOX 1, one can see the view presented in Fig. 2.16. The objective of the subsequent part of this section is to perform essential asset management concerning

Let us start with the first task by pushing Data Sheet button . As a result, the view presented in Fig. 2.17 is obtained. Subsequently, the Master Data edit button can be used to change the name of the asset as shown in Fig. 2.18. Let us proceed to the second task, which pertains to assigning KIS.BOX 1 to desired asset groups. For that purpose, the Asset groups tab should be selected as shown in Fig. 2.19. Finally,

### 2.4 Asset Management 35

**Fig. 2.16** Asset view: KIS.BOX 1

the assignment process reduces to pushing the Assign to Asset Groups button and selecting the desired asset groups as depicted in Fig. 2.20. The process of unassigning an asset from the asset group can be performed in a similar fashion. Indeed, it is enough to check a desired checkbox and push the Unassign button.

**Fig. 2.18** Changing the asset name

**•** > **Group relationship graph**

The relationship between an asset and the associated asset groups can be easily visualized. Indeed, in Fig. 2.17, one can find the Group relationship graph button , which can be used to visualize an associated graph. Such a sample graph is portrayed in Fig. 2.21.

The last task pertains to obtaining information about detailed parameters of an asset by pushing the Info button (see Fig. 2.16). The above parameters cover the device information divided into the following groups:

Hardware: type (KIS.BOX/KIS.LIGHT), part number, serial number, data matrix code, MAC address, hardware revision,

Software: OS version, application version, microcontroller firmware version, Network: WiFi SSID, WiFi signal strength, WiFi channel, IP address, subnet, gateway,

Firmware update: a set of detailed parameters including the update status, Certificate: the certificate expiration date of a KIS.Device.

# **2.5 Dashboards and Widgets**

The view presented in Fig. 2.16 is divided in the so-called Dashboards, which are defined as an overview pages for an asset and/or asset groups. Dashboards can be managed by pushing the Edit dashboard button . After selecting this option, one can perform one of the following tasks (see Fig. 2.22):

The first one is very intuitive and does not need any further explanation as it reduces to providing the name of a new dashboard. As a result, the dashboard is automatically created and displayed as a new tab in the asset view. Thus, let us proceed to designing a dashboard. Each one is composed of widgets. A widget is a component of the interface which makes it possible to perform a desired action. There are nine available widget types, which can be characterized as follows (see Fig. 2.23):

40 2 Onboarding and Preliminary Functionality Training

**Fig. 2.22** Dashboard design

**Fig. 2.23** Asset: nine widgets

The first four widgets can be directly used for digitalization of KIS.Devices as well as the monitoring and analysis of their behaviour. The remaining five widgets require suitable prepossessing using KPIs, which are discussed in Sect. 4.1.2.

### **2.6 Digital Twin Design**

The objective of this section is to introduce the Digital twin widget along with its essential functionalities. The digital twin can be defined as a KIS.MANAGER-based virtual counterpart of a KIS.Device, which is connected to the real one through dedicated WiFi. A graphical representation of both KIS.Device digital twins is presented in Fig. 2.24. Now, let us proceed to digital twin design. For that purpose it is necessary to go to Main menu → Assets and select the desired asset, e.g., KIS.BOX 1. Subsequently, the Edit dashboard button should be used and then the Add widget button can be employed, resulting in the view portrayed in Fig. 2.23. Finally, the digital twin design boils down to selecting an appropriate widget and applying the resulting dashboard changes. This produces in the dashboard view presented in Fig. 2.25. The same procedure can be performed for any KIS.LIGHT, e.g., KIS.LIGHT 1. As a result, the digital twin presented in Fig. 2.26 is obtained. Irrespective of the KIS.Device being used, it can be noticed that the actual values of both digital inputs (GPIO 3, GPIO 4) and outputs (GPIO 1 and GPIO 2) are given as well. In particular, a 0 binary state is signified by Off while 1 is denoted by On. Moreover, their switching frequency, expressed in mHz, can be observed as well. As detailed in Sect. 2.1, the possible operational LED colors are limited to the ones provided in Table 2.2. As shown in Figs. 2.27–2.28, the digital twins allow changing the color of the operational LEDs by simply selecting the desired one and then pressing the Set button. Note also that a given operational LED may be flashing or blinking, which can be achieved via the Flashing checkbox. It should be also noted that the digital twins display the current state of the operational LEDs, which can evolve in various ways, e.g., due to the appropriate rules implemented within Rule engine (see Sect. 2.9).

### **Time drive**

Let us perform a simple change of the KIS.BOX 1 state pertaining to its second button operational LED color (cf. Button 2 in Fig. 2.28 ). It can be realized as follows:

### **Fig. 2.24** KIS.LIGHT and KIS.BOX digital twins

**Fig. 2.25** Digital twin of KIS.BOX 1

**Fig. 2.26** Digital twin of KIS.LIGHT 1

After this simple procedure, one can press the Start time drive button . This allows monitoring or reconstructing historical states of KIS.Devices, which can be realized according to Fig. 2.29.

### 2.6 Digital Twin Design 43

### **Fig. 2.27** Changing the KIS.LIGHT operational LED color

**Fig. 2.28** Changing the KIS.BOX operational LED color

**Fig. 2.29** KIS.BOX 1 time drive

The objective of the preceding sections was to introduce the reader into essential subjects related to asset and user management. The subsequent part aims at going into details pertaining to the description of the current asset state using the concept of Datapoints.

### **2.7 Datapoints: Plotting and Storing Data**

Datapoints can be perceived as links between KIS.Devices and KIS.MANAGER. They can be easily accessed through Main Menu → Assets → KIS.Device → DataPoints, and can be of different types, which are listed in Table 2.6.

**Table 2.6** Datapoint types

# **•** > **Important**

From the software engineering viewpoint, Datapoints can be perceived as read only variables, which can be further processed and analysed. The only restrictions are the following:

Datapoints are processed in real time (limited by the data transfer rate), and hence their values depend on the current state of a KIS.Device. A full list of Datapoints along with their simple sample applications is provided in Appendix B. The evolution of Datapoints can be easily observed by going to Main menu → Assets → KIS.Device and then pressing the Datapoints button . As a result, the view presented in Fig. 2.30 is obtained. Subsequently, by selecting the desired Datapoints, their time evolution can be graphically observed in a dedicated plot. This process is illustrated in Fig. 2.31. A similar functionality can be directly obtained within the KIS.Device dashboard. Indeed, by proceeding to the dashboard, i.e., by pressing the Dashboard button and then the Edit dashboard one , it is possible to add one of the widgets (Add widget button) presented in Fig. 2.23. Finally, to achieve the desired functionality, a Datapoint Chart is incorporated within the dashboard. Its configuration requires selecting a Datapoint (see Fig. 2.32), providing a headline of the figure as well as the plotting interval. After this preliminary setup, one can proceed to defining the plot options, which can be realized according to Fig. 2.33. Apart from these, one can set the plot color as well as define the axis properties (cf. Fig. 2.34):

Show axis: enable/disable an axis;

Apart from the above features, it is possible to define Thresholds over/below which the plot color will be changed (see Fig. 2.34).

# **•** > **Multiple plots**

The datapoint Chart widget allows presenting multiple plots, which can be individually managed using options and properties described in this section.

### **Fig. 2.32** Datapoint chart: selecting a datapoint

**Fig. 2.33** Datapoint chart: plot options and their interpretation

**Fig. 2.34** Datapoint chart: axis and colors

### **Practical example**

The illustrative example being considered aims at realizing the following steps:

	- Plot style: shaded stairs,
	- Point style: circle,
	- Lines style: solid.

The obtained results are shown in Fig. 2.35. Let us proceed to check the obtained results with Table 2.2. Initially, the KIS.BOX Button 1 operational LED color was black, and hence one can see the line at the level of 2. Similarly, after a moment of time, the color was set to blue, which corresponds to the 0-valued point.

# **•** > **Storing and analysing data**

As shown in Fig. 2.36, additional features of the Datapoint Chart are as follows :

Download CSV: the data can be stored as a CVS file, with the first column being a time stamp and the remaining columns corresponding to the values of the associated Datapoints;

Analyze in DP-App: this feature moves the user to the Datapoint view like the one presented in Fig. 2.31.

# **2.8 Let Us Go to Workspaces: An Introductory Example with the Floorplan Widget**

The objective of this section is to introduce a crucial feature of asset groups concerning the possibility of visualizing the system floorplan. It can be simply defined as a graphical representation of the workshop. The floorplan is virtually implemented within KIS.MANAGER using the Floorplan widget. To access it, it is necessary to go to Main menu → Asset Groups, which results in the view presented in Fig. 2.37. Subsequently, the desired asset group has to be selected, e.g., Workspace 1.

# **•** > **Floorplan vs. assets**

The floorplan can only contain the assets which are assigned to a given group. For a comprehensive description pertaining to asset management, the reader is referred to Sect. 2.4. Alternatively, it is possible to perform this task directly from a workspace by simply pushing the Assigned Assets button . Subsequently, the following steps should be realized:

**Fig. 2.37** Asset groups

Note that the process of removing assets from a group can be realized in an analogous way.

After selecting the workspace, e.g., Workspace 1, one can see the view presented in Fig. 2.38. Similarly as in Sect. 2.5, dashboards can be managed by pushing the Edit Dashboard button . After selecting this option, it is necessary to push the Add widget button, which results in the view presented in Fig. 2.39. However, the resulting set of widgets is different than the one described in Sect. 2.5 (see Fig. 2.23). Indeed, there are the following nine widgets:

The first three widgets can be directly used for digitalization of asset groups as well as the monitoring and analysis of their behaviour. The remaining five require suitable prepossessing using KPIs, which are discussed in Sect. 4.1.2.

Let us start by selecting the Floorplan widget. This requires an appropriate graphical representation of the real floorplan in the form of an SVG file. Such a kind of

**Fig. 2.39** Workspace: nine widgets

**Fig. 2.40** Floorplan widget: an initial configuration

files employs a two-dimensional vector graphic format created by the World Wide Web Consortium. It expresses images with a text format that is based on XML. There are plenty of free and commercial tools which can be used for preparing a floormap using the SVG format. A good representative example is the freely available Inkscape package [1]. Having an SVG-based floorplan, it possible to use the Floorplan widget. Its initial configuration reduces to providing a desired Headline and the above-mentioned SVG image. As a result, the view portrayed in Fig. 2.40 is obtained. Subsequently, either all or selected assets can be introduced within the floorplan. Let us proceed with selected assets. To perform this action, it is necessary to use the Add widget button (cf. Fig. 2.40). The desired assets can be added as depicted in Fig. 2.41. Finally, the assets (KIS.BOX 1 and KIS.LIGHT 0) can be freely located within the floorplan, which results in the dashboard presented in Fig. 2.42.

# **•** > **Asset group time drive**

Similarly as in Sect. 2.6, it is possible monitor or reconstruct historical states of the asset group. This can be easily realized by pressing the Start time drive button (cf. Fig. 2.38).

**Fig. 2.41** Floorplan widget: adding assets

**Fig. 2.42** Floorplan widget within the dashboard

# **2.9 Let Us Rule: Managing Rules Within a Workspace**

A rule-based system can be perceived as a way of transforming a human expert's knowledge into an automated framework [2, 3]. For the purpose of KIS.ME, such a framework is called Rule engine. On the other hand, it can be seen as a KIS.MANAGER functionality, which makes it possible to implement IF-THEN rules governing interactions between assets. Thus, the rule-based system can be simply designed using a set of assets and a set of rules dictating their behaviour. In KIS.ME, rules are exemplified as a set of IF-THEN statements labelled with a unique name:

$$\text{rule name: IF attendent THEN consequent.}\tag{2.1}$$

Generally, a rule may have multiple antecedents linked by or and/or or operators. Similarly, it may have multiple consequences. For example,

$$\text{rule l: If } \mathbf{A} \text{ is black and } \mathbf{C} \text{ is white or } \mathbf{X} \text{ is green THEN}$$

$$\mathbf{A} \text{ is white, } \mathbf{B} \text{ is black.} \tag{2.2}$$

Note that the antecedent of a rule possesses two parts:

The linguistic object is linked with its value through various operators, e.g., is, or mathematical operators: ≤, <, etc. Since KIS.ME operates on KIS.Devices, LOs can be designed either with KIS.BOXes or KIS.LIGHTs, which yields the following:

KIS.Device | Status | Operating Mode: it expresses functional access of a KIS. Device to WiFi and it can be either Online or Offline;

KIS.Device | GPIO | GPIO No: it corresponds to the logical status of a selected GPIO, either On (High) or Off;

KIS.BOX | Button No | Button No Color: it expresses the color of the button operational LED, which can take a value from Table 2.2 with an additional Booleanvalued Flashing option;

KIS.LIGHT | LED | LED Color: it expresses the color of the operational LED, which can take a value from Table 2.2 with an additional Boolean-valued Flashing option.

There are two operators linking LOs with their values:

EQUAL: checks if an LO has a given value; NOT: checks if an LO does not have a given value.

Subsequently, a consequent can be defined as an Action, which can assign a value to one of the above-listed LOs except for the first one, i.e., KIS.Device | Status | Operating Mode. Another restriction is that only digital outputs can be set, i.e., KIS.Device | GPIO | GPIO 1 and KIS.Device | GPIO | GPIO 2. The above actions should perceived as the ones acting on a device. An action can also be associated with sending a predefined notification e-mail.

# **•** > **Notification templates**

A predefined notification e-mail is based on a notification template. Such a template can be defined by a user with admin rights (cf. Table 2.5) by simply going to Main menu → Portal Admin → Notification Templates. As a result, by using the Create new notification template button , a notification template editor is obtained, which is presented in Fig. 2.43. The crucial features of such a template are as follows:

Name: uniquely identifies a template within Rule engine actions; Subject: stands for the title of a predefined e-mail; Message: constitutes the body text of the predefined e-mail.

Both Subject and Message can be conveniently designed using a set of variables, which can be accessed after pushing the Add variables... button. The meaning of the crucial parameters should be interpreted as follows:

asset.name: the name of a KIS.Device, asset.properties.type: either sBox or sLight, event.key: EMAIL\_ACTION, event.timestamp?datetime: the date and time of an event.

Before proceeding to designing a sample rule, a set of suitable definitions has to be provided:

Conditions: the set of antecedents merged with and/or operators, Triggers: the set of antecedents merged with or operators, Actions: the set of consequents.

Under the above definitions, triggers can be perceived as necessary conditions for performing a Rule engine-based inference. Additionally, triggers can be formed with all of the above-defined logistic objects. However, they can also use a linguistic object associated with pressing the KIS.BOX button. Unlike conditions, triggers verify if the value of a linguistic object has given instants, e.g., a button is pressed. Thus, a full list of triggers for linguistic objects is formed by extending the above-defined one with what follows:

KIS.BOX | Button No | Pressed: it expresses the fact of pressing the KIS.BOX button.

Apart from the above functionalities, triggers have also optional settings:

after x times: the trigger is fired when a given value of a linguistic object has been counted x times;

**Fig. 2.43** Notification templates

**Fig. 2.44** Sample trigger with optional settings

after x minutes: the trigger is fired after x minutes from the time when a given value of a linguistic object has been recorded;

after x hours: the trigger is fired after x hours from the time when a given value of a linguistic object has been recorded.

Figure 2.44 shows a sample trigger, which is fired after pressing the KIS.BOX button two times. It should be also pointed out that this kind of trigger has an internal counter, which is automatically reset after reaching a given threshold. It can be also reset manually after using the Trigger details link along with the Reset button (cf. Fig. 2.45). Finally, let us note that such a manual reset is not available for the after x minutes and after x hours optional settings.

**Fig. 2.45** Trigger reset

### **Sample rule**

The objective of this example is to define a rule which satisfies the following requirements:

Environment: It is defined with Workshop 1 as well as employs KIS.BOX 1 and KIS.LIGHT 0.

Triggers: The triggers are associated with pressing KIS.BOX 1 Button 1 or Button 2.

Conditions: The operational LED color of KIS.LIGHT 0 can be either black or green and its status should be online.

Actions: The associated actions are as follows:

• change the operational LED color of KIS.LIGHT 0 to green;

• send a notification email to<EMAIL_ADDRESS>with the subject and title "Color change" while the body of the message being KIS.Device color has changed.

Let us start with defining an email notification template by going to Main menu → Portal Admins → Notification Templates. As has already been discussed, such a template can be designed according to Fig. 2.46. Before proceeding to Rule engine definitions, it can be observed that the above conditions may have a visible effect if the KIS.LIGHT 0 operational LED color is either black or green. Thus, an appropriate initial condition has to be imposed by going to Main menu → Assets, selecting KIS.LIGHT 0 and using its digital twin to set an appropriate operational LED color (Sect. 2.6). Under the above preliminary setup, triggers, conditions and actions can be intuitively defined by pushing the Rule engine button (cf. Fig. 2.42). Subsequently, the Create rule button should be used to open the Rule engine editor and provide the required ingredients, i.e., the name of the rule, triggers, conditions and actions. As a result, the view presented in Fig. 2.47 is obtained. After saving the rule, it is activated and operates within KIS.ME.

**Fig. 2.46** Notification template: "change color"

# **•** > **Rule interactions**

As can be expected, each asset group/workspace has its own set of rules. However, when sharing assets between workspaces, the users must be cautious about their possible unappealing interactions.

### **2.10 State-Space Modelling**

The objective of this section is to introduce the concept of the system state, which is a set of variables that can be used to describe any past and future system behaviour. Consequently, the system state-space is a space of admissible state values. Subsequently, the state-space model is defined as a set of rules which enables cyclical transition between the consecutive states.

### 2.10 State-Space Modelling 59

**Fig. 2.47** Sample rule

### **Traffic lights state-space model**

To illustrate the concept of the state-space model, let us employ a traffic lights example. In this case, the transition rules can be clearly visualized using Fig. 2.48. The objective of the remaining part of this example is to attain a similar functionality using KIS.ME. In particular, the following features should be achieved:

Environment: It is defined within Workshop 1 and employs KIS.BOX 1, hence the traffic lights system presented in Fig. 2.48 is reduced to one KIS.BOX, which changes the colors of its operational LEDs to mimic the behaviour of the traffic lights system.

Triggers: A trigger is associated with pressing KIS.BOX 1 Button 2.

Conditions: The conditions are simply defined by the current state, which is one of those presented in Table 2.7;

Actions: The associated action is simply a consecutive state.

It should be noted that each state described in Table 2.7 is uniquely defined, which makes it possible to form the state-space model using a set of four rules. A sample rule evolving the system from state 1 to state 2 is provided in Fig. 2.49. Moreover, 60 2 Onboarding and Preliminary Functionality Training

**Fig. 2.48** Traffic lights

**Fig. 2.49** Sample traffic lights rule

the initialization of the system requires that KIS.BOX 1 operational LEDs be in one of the quadruple of states defined in Table 2.7. This can be easily achieved using the KIS.BOX digital twin (see Sect. 2.6).

# **2.11 Mastering Rule Management: Completeness and Consistency**

The objective of the two preceding sections was to provide a concise introduction into Rule engine design and the inference mechanism. However, for more complex systems, the number of rules will proliferate. Thus, it is customary to have a tool capable of checking their completeness and consistency. For that purpose, the celebrated decision table [2] is introduced. It operates on Boolean-valued conditions, and hence it is beneficial to recall the essential logical operators provided in their priority order:

The behaviour of the above operators is explained in Fig. 2.50. It can be also observed that the implication and equivalence can be expressed by

> *a* ⇒ *b* can be calculated with ¬*a* ∨ *b*; *a* ⇔ *b* can be obtained with (*a* ⇒ *b*) ∧ (*b* ⇒ *a*).

Therefore, a typical way of expressing a logical implication is IF a THEN b. Thus, according to the truth table for *a* ⇒ *b*, if *a* is false then it does not matter what *b* is, and hence the implication is true. Similarly, if *a* and *b* are true then the implication is true as well. The last case, i.e., when *a* is true and *b* is false, can be explained using the following example:

$$\text{IF } \sin(z) = 0 \text{ THEN } z = 0.$$

Such an implication is false as *z* = 0 is not the only value for which sin(*z*) = 0. Thus, the implication which is true should be

IF sin(*z*) = 0 THEN *z* = *k*π, with *k* being an integer value.

To summarize these preliminaries, two crucial definitions have to be provided:

Tautology: a statement that is true for every possible interpretation, e.g.,

(KIS.Box|Status|Operating Mode is Offline) or (KIS.Box|Status|Operating Mode is Online);

Contradiction: a statement that is false for every possible interpretation, e.g., (KIS.Box|Status|Operating Mode is Offline) and (KIS.Box|Status|Operating Mode is Online).

Indeed, it is obvious that in the first case the statement is always true as the KIS.BOX status can be either Offline or Online. Contrarily, it is evident that the second state-

**Fig. 2.50** Truth tables

ment is always false as the KIS.BOX status cannot be Offline and Online simultaneously. Thus, it is evident that one should avoid both cases while designing rules with KIS.ME.

### *2.11.1 Transforming Conditions*

A preliminary step for implementing a rule base is to collect all rules and check if it is possible to simplify them. For that purpose, a standard set of transformation strategies can be used:

double negation: ¬¬*a* = *a*, commutativity of conjunction: *a* ∧ *b* = *b* ∧ *a*, commutativity of disjunction: *a* ∨ *b* = *b* ∨ *a*, associativity of conjunction: (*a* ∧ *b*) ∧ *c* = *a* ∧ (*b* ∧ *c*), associativity of disjunction: (*a* ∨ *b*) ∨ *c* = *a* ∨ (*b* ∨ *c*), distributivity of conjunction: (*a* ∨ *b*) ∧ *c* = (*a* ∧ *c*) ∨ (*b* ∧ *c*), distributivity of disjunction: (*a* ∧ *b*) ∨ *c* = (*a* ∨ *c*) ∧ (*b* ∨ *c*), idempotency of conjunction: *a* ∧ *a* = *a*, idempotency of disjunction: *a* ∨ *a* = *a*, De Morgan's law: ¬(*a* ∧ *b*) = ¬*a* ∨ ¬*b*, De Morgan's law: ¬(*a* ∨ *b*) = ¬*a* ∧ ¬*b*, contraposition law: *a* → *b* = ¬*b* ⇒ ¬*a*.

Having the above strategies, one can simply associate logical variables with antecedents (see Sect. 2.9). For that purpose, it is suggested to use the following nomenclature:

$$a \coloneqq \text{LOs EQUAL Value},\tag{2.3}$$

$$
\neg a := \text{LOs NOT Value}.\tag{2.4}
$$

Figure 2.51 presents two sample antecedents which can be associated with a logical variable *a* and its negation ¬*a*. Having such variables, it is easy to write and operate on conditions in a consistent way. Another important aspect pertains to an appropriate use of parentheses. Indeed, due to the operators' priority, *a* ∨ (*b* ∧ *c*) can

**Fig. 2.51** Sample *a* (top) and ¬*a* (bottom)

**Fig. 2.52** Sample *a* ∧ (*b* ∨ *c*) ( *a*: top, *b*: middle, *c*: bottom)

**Fig. 2.53** Implementation of ¬*a* ∨ ¬*b*

be simplified to *a* ∨ *b* ∧ *c*. Contrarily, *a* ∧ (*b* ∨ *c*) differs from *a* ∧ *b* ∨ *c*. This can be clearly observed within Rule engine, which uses different right square brackets for indicating appropriate priorities. Thus, *a* ∧ (*b* ∨ *c*) can be exemplified with the conditions portrayed in Fig. 2.52.

### **Sample simplification**

Let us suppose that there are two logical variables defined as

*a* := KIS.BOX 1| Button 1 | Button 1 Color EQUAL black, *b* := KIS.BOX 1| Button 2 | Button 2 Color EQUAL green,

and an action must be performed when ¬(*a* ∧ *b*) (NAND operation) is true. Unfortunately, such a condition is impossible to implement in Rule engine. However, it is straightforward to observe that by applying De Morgan's law it is possible to simplify it into ¬*a* ∨ ¬*b*, which can be easily implemented in Rule engine (see Fig. 2.53).

**Fig. 2.54** Logical expression simplification with Maxima

**Table 2.8** Decision table

# **•** > **Automatic simplification**

There are several free and commercial packages which can be used for automatic simplification of logical expressions. Maple [4] (package Logic, command BooleanSimplify) and Maxima [5] (package logic, command logic\_simplify) are good representative examples of commercial and freely available tools, respectively. Let us employ Maxima for the purpose of simplifying the expression used in the preceding example, i.e., ¬(*a* ∧ *b*). The Maxima session implementing this task is presented in Fig. 2.54.

To conclude this section, it should be pointed out that the rule

IF antecedent 1 OR antecedent 2 OR... antecedent n THEN Action(s) (2.5)

can be replaced by a set of *n* rules of the form

. . .

$$\text{IF attendent 1 THEN Action(s),} \tag{2.6}$$

$$\text{IF attendent} \text{ n THEN Action(s).}\tag{2.7}$$

### *2.11.2 Decision Tables*

The classical decision table [2, 3, 6, 7] is used to express *k* rules of the form

*ri* : IF Condition 1 and Condition 2, ... and Condition *n* THEN Action 1 and Action 2, ... and Action *m*, *i* = 1,..., *k*, (2.8)

which can be presented using Table 2.8. The internal horizontal line between conditions is perceived as the and conjunction. Additionally, the double horizontal line separates conditions and actions while the vertical ones distinguish the rules. Thus, any rule *ri* can be easily reconstructed from Table 2.8 to (2.8) by reading the column corresponding to *ri* in a top-to-bottom order. The entries of the decision table with respect to the conditions, i.e., *ci*,*<sup>j</sup>* , in Table 2.8 are as follows:

T: if the condition must hold; F: if the condition does not hold; –: if the condition is ignored;

while for the actions *ai*,*<sup>j</sup>* we have

X: if the action has to be executed;

–: if the action has not to be executed.

A set of rules or a decision table have the following important features:

Redundancy: If there is a situation in which conditions of two rules with the same actions hold, then they are called redundant ones.

Inconsistency: If there is a situation in which conditions of two rules with different actions hold, then they are called inconsistent ones.

Completeness: For every situation there is a rule whose conditions will be satisfied.

### **Checking redundancy and inconsistency**

Let us consider three conditions which have to be implemented using Rule engine within Workshop 1 with KIS.BOX 1 and KIS.LIGHT 0:

Condition 1: KIS.BOX 1 | Button 1 |Button 1 Color is black; Condition 2: KIS.BOX 1 | Button 2 |Button 2 Color is blue; Condition 3: KIS.LIGHT 0 | LED Color | Color is green.

There are also two actions:

Action 1: KIS.LIGHT 0 | Set LED | LED Color | is black; Action 2: KIS.LIGHT 0 | Set LED | LED Color | is blue.

Let us suppose that the above conditions and actions were used to implement three rules, *r*1, *r*<sup>2</sup> and *r*3, expressed in the form of the decision table detailed in Table 2.9. Let us consider a situation in which Condition 1 is T (true) while Condition 2 and

**Table 2.9** Decision table with redundancy and inconsistency

**Table 2.10** Decision table with inconsistency

Condition 3 are F (false). In such a case both rules *r*<sup>1</sup> and *r*<sup>2</sup> are active. Since they have identical actions (Action 1), they are redundant, which means that they can be merged into one equivalent rule *r* <sup>1</sup> <sup>1</sup> . The resulting decision table is presented in Table 2.10. Let us consider a situation in which Condition 1 and Condition 2 are T (true) while Condition 3 is F (false). It can be easily observed that rules *r* <sup>1</sup> <sup>1</sup> and *r*<sup>3</sup> are inconsistent because their condition sets are satisfied while they have different sets of actions. The inconsistent rules denote the situation in which different things may happen under the same circumstances. Indeed, two contradictory actions will be initiated:

Action 1: KIS.LIGHT 0 | Set LED | LED Color | is black; Action 2: KIS.LIGHT 0 | Set LED | LED Color | is blue.

To summarize, a simple rule reduction principle can stated as below.

# **•** > **Rule reduction principle**

If there are two rules *l* and *s* with the same actions and identical condition entries *ci*,*<sup>l</sup>* and *ci*,*<sup>s</sup>* except for *c <sup>j</sup>*,*<sup>l</sup>* = *c <sup>j</sup>*,*<sup>s</sup>*, then they are replaced with a single new rule *f* with a condition entry *c <sup>j</sup>*, *<sup>f</sup>* equal to "–". Note that as "–" represents T/F, it should be perceived as equal to both T and F.

**Fig. 2.55** Rule *r*<sup>3</sup> implemented within Rule engine

# **•** > **Implementing decision tables with Rule engine**

Implementation of decision tables within Rule engine can be easily realized using the following procedure:

	- if an entry is equal to "T", then introduce the condition using (2.3);
	- if an entry is equal to "F", then introduce the condition using (2.4);
	- if an entry is equal to "–", then ignore it.

As an example, let us consider rule *r*<sup>3</sup> in Table 2.10, which is exemplified in Fig. 2.55.

The above implementation strategy is applicable to a set of simple conditions in the form of either (2.3) or (2.4) . However, it can be easily extended to more advanced structures. On the other hand, the logical expressions can be simplified using the strategies proposed in the preceding section (see, e.g., (2.5) and (2.7)) or transformed into conjunctive normal form (see, e.g., [2] for a comprehensive explanation).

# **•** > **Rule base completeness**

Having a way of checking the redundancy and consistency, it is possible to provide a strategy for verifying the completeness of a set of rules. Since each condition in a decision table (Table 2.8) is a Boolean-valued one, this simply means that the complete number of rules is equal to

$$k = \mathfrak{I}^n,\tag{2.9}$$

where *k* is the total number of rules while *n* is the number of conditions (cf. (2.8)). Thus, a rule should be defined for every possible situation. As an example, let us consider the decision table presented in Table 2.10. Thus, for three conditions one can easily see that (2.9) implies that there should be *k* = 8 rules. Contrarily, there are two rules in Table 2.10.  Thus, it is possible to verify (2.9) with

$$k\_r = \sum\_{i=1}^{n\_r} 2^{n\_{i-}},\tag{2.10}$$

where *nr* stands for the number of rules in Table 2.8 while *ni*,<sup>−</sup> is the number of instances of "–" in the *i*-th rule, *i* = 1,... *nr*. In the example presented in Table 2.8, one can easily identify what follows

It should be pointed out that there are situations in which rule base completeness is not necessary. Indeed, if it is guaranteed that not all possible situations pertain to input variables, and hence, conditions are possible, then the number of rules can be smaller. Such a situation may occur during the state-space modelling presented in Sect. 2.10. In such a case, the consecutive states are cyclically realized, which implies appropriate rule order execution. Finally, it should be pointed out that triggers may also have influence on the final number of rules. Indeed, they cause that some rules are not fired for a given trigger setting.

### **2.12 Case Study: Trend Plotting and Performance Analysis**

The objective of the preceding three sections was to introduce Rule engine, which makes it possible to bring a given system alive according to a predefined set of rules. Having such features, it is possible to monitor KIS.Device performance with Datapoints and the associated widgets described in Sect. 2.7. For that purpose, let us reconsider the traffic lights example presented in Sect. 2.10. Let us start with transforming Table 2.7 into a decision table assuming that the initial state of the system is (cf. Sect. 2.6)

> KIS.BOX 1 | Button 1 |Button 1 Color is red; KIS.BOX 1 | Button 2 |Button 2 Color is black.

By observing an obvious condition stating that an operational LED cannot have two different colors simultaneously, the resulting decision table is given in Table 2.11. This implies that there is no need for implementing "F"-valued entries, which simplifies the Rule engine structure. For Button 1 Color, T is equivalent to red while F stands for green. Similarly, for Button 2 Color, T is equivalent to black while F stands for yellow. It is straightforward to observed that there are two conditions, and hence (2.9) implies that a complete set of rules should have four rules. This is exactly the case. Moreover, the rules are consistent because each of them pertains to a different set of actions. Finally, a Rule engine-based implementation of *r*1–*r*<sup>4</sup> is provided in Figs. 2.56, 2.57, 2.58 and 2.59. Having a fully functional system, it is possible to design a dashboard containing

button1ColorKpiDuration, button2ColorKpiDuration.

The resulting dashboard is presented in Fig. 2.60. Such a design allows intuitive visualization and analysis of the behaviour of the traffic lights system. Indeed, the plots in Fig. 2.61 correspond to the operational LED colors of the first (green) and the second (yellow) buttons. As can be observed, both of them have two possible values only, which can be recorded and analysed over a specified time period. In particular, the green line switches between the red (5) and the green (3) level. Similarly, the yellow line switches between black (2) and yellow (7).

**Fig. 2.56** Traffic lights rule *r*<sup>1</sup> implemented within rule engine

**Fig. 2.57** Traffic lights rule *r*<sup>2</sup> implemented within rule engine

**Fig. 2.58** Traffic lights rule *r*<sup>3</sup> implemented within rule engine

**Fig. 2.59** Traffic lights rule *r*<sup>4</sup> implemented within rule engine

**Fig. 2.61** Traffic lights datapoint chart

**Table 2.11** Decision table for traffic lights

### **2.13 Training Exercises**

The objective of this section is to provide a set of practical exercises which can be used for validating the knowledge and skills gathered in this chapter. It is assumed that the user realizing these exercises has appropriate rights and permissions. This can be easily verified using Table 2.5.

	- a KIS.Device,
	- an M12-to-USB cable (see Table 2.4),
	- a computer/tablet equipped with a web browser and a USB port,
	- a company account with admin user rights (see Sect. 2.3),
	- WLAN access with permission credentials.

### 2.13 Training Exercises 73

### **2.2** Creating a new user

Using an arbitrary e-mail address at your disposal, perform the following:

**2.3** Dashboard and digital twin design

Exercise requirements: The exercise requires access to one KIS.BOX and one KIS.LIGHT. Proceed according to the following tasks:

button1ColorKpiDuration,

button2ColorKpiDuration.

**2.4** Floorplan widget

Exercise requirements: The exercise requires access to one KIS.BOX and one KIS.LIGHT assigned to a selected workspace.

### **2.5** KIS.LIGHT ruling

Exercise requirements: completed Exc. 2.4.

1. Write a rule called rule b2r:

Triggers: KIS.LIGHT operational LED is black; Conditions: KIS.LIGHT operational LED is black; Actions: KIS.LIGHT operational LED is red.

2. Write a rule called rule r2b:

Triggers: KIS.LIGHT operational LED is red; Conditions: KIS.LIGHT operational LED is red; Actions: KIS.LIGHT operational LED is black.

# **2.6** KIS.LIGHT ruling continued

Exercise requirements: completed Exc. 2.5. Using a similar strategy like in Exc. 2.5, perform the following:

### **2.7** KIS.BOX traffic lights

Exercise requirements: The exercise requires access to one KIS.BOX assigned to a selected workspace.

	- What can you say about *a* ∧ (¬*a*)?
	- What can you say about *a* ∨ (¬*a*)?

# **2.9** Rule simplification II

Exercise requirements: The exercise requires access to one KIS.BOX and KIS.LIGHT assigned to a selected workspace.

1. Let us define the following logical variables:

*a* := KIS.BOX | Button 1 |Button 1 Color EQUAL red, *b* := KIS.BOX | Button 2 |Button 2 Color EQUAL black, *c* := KIS.LIGHT | LED | LED Color EQUAL green.

2. Implement a rule with the following condition:

$$(a \land b \land c) \lor (\neg a) \lor (a \land (\neg b) \land c),\tag{2.11}$$

taking as a trigger the pressing of the first KIS.BOX button event along with an action:

Action: KIS.LIGHT 0 | Set LED | LED Color | is red.

Hint: Use Maxima to simplify the above logical expression.

3. What can you say about the usage of variable *b*?

### **2.10** Decision tables

Exercise requirements: The exercise requires access to one KIS.BOX and KIS.LIGHT assigned to a selected workspace.

1. Let us define three conditions:

Condition 1: KIS.BOX | Button 1 |Button 1 Color EQUAL red, Condition 2: KIS.BOX | Button 2 |Button 2 Color EQUAL black, Condition 3: KIS.LIGHT | LED | LED Color EQUAL green;

along with two actions:

Action 1: KIS.LIGHT 0 | Set LED | LED Color | is red; Action 2: KIS.BOX | Set LED | Button 1 color | is blue; and a trigger associated with pressing the first KIS.BOX button event.

### **2.11** Battery assembly system

Exercise requirements: The exercise requires access to one KIS.BOX assigned to a selected workspace.

**Table 2.12** Initial decision table

**Table 2.13** KIS.BOX states

1. Let us consider the battery system presented in Fig. 2.62. Such a system undergoes manual assembly, which, in simplified form, can be described by two tasks:

Battery mounting should be realized according to the cyclically repeated states described in Table 2.13. Note that the initial state should be State 1.

### **2.14 Concluding Remarks**

The objective of this chapter was to provide a self-contained introduction to the KIS.ME IoT platform. In particular, preliminary information about both the hardware and software layers was introduced along with suitable operating procedures for accessing KIS.MANAGER and onboarding the hardware layer. Subsequently, a hierarchical KIS.ME structure was presented, which associates assets, users and workspaces along with suitable rights and permissions. For that purpose, a systematic set of guidelines concerning users, assets and workspace management was provided. Such essential knowledge enabled introduction of dashboards and widgets, which form the basis for the KIS.ME HMI interface. Concerning the widgets, particular attention was focused on hardware digital twins as well as floorplans exemplifying real life systems with an integrated set of assets. Such a couple was further extended with the Datapoints chart enabling graphical visualization of system performance. The rest of the chapter was devoted to system management using Rule engine. In particular, it started with a concise introduction to the graphical rule building structure. Subsequently, a state-space modelling strategy was proposed, which guarantees cyclical behaviour of the system. Finally, more advanced techniques for managing a set of rules were introduced, which allow their simplification as well as completeness and consistency verification. The chapter was concluded with a series of practical exercises, which certify the knowledge provided within it.

### **References**

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Chapter 3 Towards Logistic Applications**

# **3.1 Access Control**

Irrespective of the application being considered, one of the important features while operating KIS.Devices is to guarantee the desired access control. This simply means that one should provide means for preventing the situation in which persons without appropriate access permissions operate KIS.BOXes installed in the system. In other words, even if they touch the buttons of a given KIS.BOX, there should be no effect associated with such an action. In this section, two kinds of access control are considered:

Irrespective of the selected access control strategy, it is proposed to use the RFID (radio-frequency identification) option as a user identification tool. However, before proceeding to the details, let us provide an introductory example involving KIS.BOX GPIO.

### **KIS.BOX with a photoelectric sensor**

Let us consider a normally open photoelectric sensor, which is connected with KIS.BOX according to the scheme presented in Fig. 3.1. There are several such sensors with light-based binary switching properties. Similarly to KIS.BOX (see Sect. 2.1), they also use an M12 connection as well as a 24 V power supply. Such a sensor works as relay, which simply changes the KIS.BOX digital input value depending on the light condition. With a hardware infrastructure, it is possible to implement sample rules reacting to the changes of the photoelectric sensor.

Environment: It is defined within Workshop 1 and employs KIS.BOX 1. There are two rules which are determined using the settings presented below.

Conditions: If the sensor is exposed to the light, then a logical false state (Off) of Input 1 is obtained. Contrarily, if there is no light, then a logical true state (On) is generated. Having this in mind, the idea is to equip the above-defined rules with a preliminary condition associated with the logical false state (Off) of Input 1. Additionally, the first rule will check if the KIS.BOX 1 operational LED 1 color is red while the second one will verify if the KIS.BOX 1 operational LED 1 color is blue.

Actions The action associated with the first rule causes that the KIS.BOX operational LED 1 color switches to blue. The second rule performs in a similar way, but KIS.BOX1 operational LED 1 transforms into red.

Finally, it should be indicated that the initial state of KIS.BOX operational LED 1 is red. This can be easily realized with the KIS.BOX 1 digital twin (cf. Sect. 2.6). The implementation of the above-defined two rules is presented in Figs. 3.2 and 3.3. As a result of the above hardware–software configuration, a useful light-based access control system is developed. Indeed, if the photoelectric senor is not exposed to the light, then no action is performed.

**Fig. 3.1** KIS.BOX with a photoelectric sensor

**Fig. 3.2** First rule for KIS.BOX with a photoelectric sensor

**Fig. 3.3** Second rule for KIS.BOX with a photoelectric sensor

**Fig. 3.4** RAMO product line

*Remark 3.1* The above system configuration can be adapted to a wide spectrum of input devices and senors. For example, a RAMO product line can be efficiently used for that purpose (see Fig. 3.4).

Following such a preliminary access control example, it is possible to go back to access control with RFID readers. Irrespective of the access control strategy being

**Fig. 3.5** RFID-based access control scheme

**Fig. 3.6** RFID-based access control scheme with feedback from KIS.MANAGER

used (general or individual), the general scheme of the proposed approach is given in Fig. 3.5. It consists of a KIS.Device and an RFID reader including or associated with a processing unit, which, after reading an appropriate RFID tag, may perform the following commands:

Reset command: It sends a false (Off)–true (On)–false (Off) sequence to a KIS.Device;

Identification command: It sends a desired series of false (Off)–true (On)–false (Off) values, which identifies a user.

Let us start with the general access control strategy. The simplest approach which can be employed in this case can be realized in a similar way as the one portrayed in Fig. 3.5. If an appropriate RFID tag is recognized, then the RFID reader (possibly equipped with a processing unit) simply sends an identification command consisting of the following sequence: false–true–false (Off–On–Off). As a consequence, the desired digital input state of the KIS.Device is changed–accordingly. The rest of the configuration has to be realized in KIS.MANAGER. For that purpose, the digital output of the KIS.Device can be employed, which alternates between true (On) and false (Off). This corresponds to two possible situations, i.e., access granted (On) or access denied (Off). An appealing property of such a solution is that, apart from KIS.MANGER, information about the current access control status can be sent to external hardware / software, which is visualized in Fig. 3.6.

### **Access control with KIS.BOX**

Let us consider the scheme presented in Fig. 3.6, with the KIS.Device being KIS.BOX 1 operating within Workshop 1. Moreover, for the sake of communication purposes, digital Input 1 and Output 1 are utilized. For such a configuration, the resulting access control rules are given in Figs. 3.7 and 3.8. Finally, any access control-dependent rule can simply use KIS.BOX 1 Output 1 to identify the current access control status. Note also that the above solution can also be easily realised with KIS.LIGHT.

**Fig. 3.7** Rule for granting access

**Fig. 3.8** Rule for denying access

**Fig. 3.9** RFID-based individual access control scheme with feedback from KIS.MANAGER

Having a strategy for general access control, which is presented in Fig. 3.9, the proposed individual access control obeys the following laws:

A natural constraint of such an approach is associated with the number of available colors indicated in Table 2.2. Thus, if black is excluded, then there are seven colors applicable. However, such a set of available users is usually sufficient for most practical applications. On the other hand, this limitation can be easily tackled by utilizing, e.g., two KIS.LIGHTs working together. Finally, the list of users along with their identification colors and commands are given in Table 3.1. Note that, for the sake of simplicity, the On and Off states are denoted by 1 and 0, respectively. Having all the above ingredients, let us provide the final operational procedure:

Step 0: The KIS.LIGHT operational LED color is set to black and Output 2 is true (On).

Step 1: If the *i*-th user's RFID tag is recognized and the selected KIS.LIGHT Output 2 is true (On), then the RFID-based device sends sequentially the *i*-th identification command to Input 1 according to the following procedure:

If a complete *i*th user identification command is received by the RFID-based device, then go to Step 3.

Step 2: If *i*-th user RFID tag is recognized and the selected KIS.LIGHT 0 Output 2 is false (Off), then go to Step 3.

Step 3: The RFID-based device sends a reset command to KIS.LIGHT Input 2 and then the status of Output 2 is changed to the opposite logical value. Moreover, if Output 2 is true (On), then set the KIS.LIGH 0 operational LED color to black.

Let us start the analysis by noting that Step 0 is performed only once after completing the design of the access control system. Similarly, as in the general access control case, the proposed strategy alternates between two phases, which correspond to granted and denied access. The alternation can be performed by authorized users exclusively. Note also that the color assignment presented in Table 3.1 can be freely modified, while the identification commands should remain as proposed. This will prevent ambiguities when identifying users.

### **KIS.LIGHT-based individual access control for three users**

For presentation purposes, let us consider a set of three users presented in Table 3.2. The proposed strategy is to be implemented using KIS.LIGHT 0 operating within Workshop 1. The implementation starts with Step 0, which pertains to the initial KIS.LIGHT conditions:

**Fig. 3.11** Rule for transferring the off state between input 1 and output 1

The above step is realized only once and can be easily performed using the KIS.LIGHT digital twin (see Sect. 2.6) and/or a dedicated rule performing such an action. Now, let us proceed to Step 1. The first point of this step pertains to transferring Input 1 to Output 1. This task is realized with the two rules presented in Figs. 3.10 and 3.11. The second point of Step 1 concerns changing the KIS.LIGHT operational LED color according to the currently received identification sequence. It is clear from Table 3.2 that there should be three rules governing such a transition. Thus, for a particular user, the transitions, i.e., answers to the identification command, should be as follows:

User 1: Blue, User 2: Blue→Turquoise, User 3: Blue→Turquoise→Green.

To tackle this problem, the rules presented in Figs. 3.12, 3.13 and 3.14 are implemented. Subsequently, the complete Step 2 is realized by the RFID-based device, while by proceeding to Step 3 one can easily observe that the rules alternating the logical state of Output 2 depending on Input 2 can be realized in an analogous way as those presented in Figs. 3.7 and 3.8. Thus, they are simply omitted. Finally, by proceeding to Step 3 one can observe that there is only one rule which has to be carried out, i.e., if Output 2 is true (On), then set the KIS.LIGHT 0 operational LED color to black. This rule is implemented according to Fig. 3.15. Its implementation completes the entire design procedure and the individual access control scheme is ready to use. Finally, it should be pointed out that the extension to seven users presented in Table 3.1 is straightforward and requires four additional rules only, i.e., those for users 4–7.

**Fig. 3.12** Rule for changing the KIS.LIGHT operational LED color from black to blue

**Fig. 3.13** Rule for changing the KIS.LIGHT operational LED color from blue to turquoise

**Fig. 3.14** Rule for changing the KIS.LIGHT operational LED color from turquoise to green

**Fig. 3.15** Rule for changing the KIS.LIGHT 0 operational LED color to black

### *3.1.1 Managing a Small Warehouse*

The warehouse management system design problem can be settled using different approaches and strategies [1]. Irrespective of the hardware and software structure being used, such systems aim at improving performance efficiency and minimizing overall costs. Thus, one should find a balance between the expense of implementing such warehouse management systems and the potential overall cost minimization.

The objective of this section is to provide guidelines for implementing a straightforward strategy for managing a small warehouse. Such warehouses are traditionally divided into segments with shelves for storing dedicates items, e.g., products, components, etc. Thus, it is assumed that, from the economical perspective, implementation of a dedicated warehouse system is not justified. As a remedy, a simple KIS.ME strategy is proposed, which integrates small warehouse shelves with KIS.MANAGER with a straightforward KIS.BOX-based implementation. The proposed strategy is based on the following general principles:

Capacity: Each shelf has the desired capacity of items. Capacity levels: Each capacity is uniformly divided into levels. Light levels: Each capacity level is associated with a given color, e.g., level 1:

green, level 2: yellow, level 3: red.

KIS.BOX implementation:

With the above preliminaries, it is possible to proceed to a simple yet illustrative example.

### **Managing an item level within the shelf**

The example is implemented within Workshop 1 with KIS.BOX 1. Let us consider the item capacity levels presented in Table 3.3. There, it is evident that, when there are three or four items, then KIS.BOX 1 operational LED 1 should illuminate in green. Similarly, if there are one or two items, then KIS.BOX 1 operational LED 1 should be yellow. Finally, the zero item level is indicated with red. The above functionality can be implemented with just two rules, which are presented in Figs. 3.16 and 3.17. They can be efficiently used for decreasing the item capacity with one KIS.BOX button along with its operational LED, i.e., the KIS.BOX 1 Button 1 operational LED color. The reverse, i.e., an increase in the item capacity level, can be realized with KIS.BOX 1 Button 2. Thus, the overall performance of the system can be described by extending Table 3.3 with such a functionality, which yields Table 3.4. This means that the KIS.BOX Button 2 operational LED color indicates the capacity level which is to the reached after refilling the shelf with two items and pressing KIS.BOX Button 2. Indeed, if the shelf is full, then it is impossible to add any item, and hence the KIS.BOX Button 2 operational LED color is black, i.e., the KIS.BOX Button 2 operational LED is not lit. Two sample rules which can be used to achieve this goal are presented in Figs. 3.18 and 3.19. An obvious limitation of the above strategy is that an increase in the item level can be performed right after transferring from one capacity level to another. For example, if the capacity level is 3 and one would like to add two items, then the level should be 5, but not 4. However, all such ambiguities can be resolved by using the above-described counter reset mechanism. It should be also mentioned that the KIS.BOX initial state should be set according to Table 3.4, which corresponds to the actual item capacity level. This can be performed using the digital twin described in Sect. 2.6. The final option which can be also implemented pertains to alerting the user that the zero capacity level lasts too long, e.g., such an item capacity level lasts longer than two minutes. This can be implemented with the after x minutes optional settings, while the resulting rule is presented in Fig. 3.20.

**Table 3.3** Shelf capacity management

**Fig. 3.16** Rule for changing the light level from green to yellow

**Fig. 3.17** Rule for changing the light level from yellow to red

**Table 3.4** Shelf capacity management

**Fig. 3.18** Rule for changing the light level from yellow to green

**Fig. 3.19** Rule for changing the light level from green to black

**Fig. 3.20** Rule for warning about a zero item capacity with a flashing LED color

The above example can be extended to a larger number of capacity levels, which is constrained by the sum of available colors (see Table 2.2). Moreover, the information about the current status of the shelf can be further analyzed using KPIs, described in Sect. 4.1.2.

### **3.2 Two Points–One Transporter**

The practical use case being analysed in this section pertains to a two- point transportation system equipped with one transporter only. This means that the transporter performs the desired transport actions between these two points. It is assumed that the transporter is a human-operated one, but no further details about its functionalities are stated. Transportation points are signified by two colors. In the present use case, green signifies the first point while red stands for the second one. Thus, KIS.Devices being used for a complete implementation are summarized as follows:

The above KIS.Devices are installed in Workshop 1 along with the floorplan presented in Fig. 3.21. Additionally, the black color signifies the fact that there is no need for transportation. Under the above assumptions, the full list of transportation order events is presented in Table 3.5. This means that both KIS.BOX Green and KIS.BOX Red Button 1 operational LEDs are used to signify the transportation order according to Table 3.5. Finally, the ongoing transportation action is signified by the blue color of the respective operational LED. As a result, a decision table is proposed, which is presented in Table 3.6. Thus, the system operates with six rules,*r*<sup>1</sup> − *r*6, and their triggers are given in Table 3.7. Implementation of rules *r*<sup>1</sup> − *r*<sup>3</sup> is presented in Figs. 3.22, 3.23 and 3.24. Rules *r*<sup>4</sup> − *r*<sup>6</sup> can be implemented analogously. Additionally, KIS.BOX Green and KIS.BOX Red Button 2 are used for canceling the transportation command. A sample implementation of this functionality for KIS.BOX

**Fig. 3.21** Two points–one transporter floorplan

**Table 3.5** Possible transportation scenarios

1: transport required, 0: no transportation need

Green is presented in Fig. 3.25. Finally, it should be noted that an initial condition for all KIS.BOXes is that all their operational LED colors should be black. This can be attained by using their digital twins (see Sect. 2.6). Having a complete system with an initial condition, let us consider a sample transportation action:

Finally, it should be noted that another transportation event from the same point can be started if the previous one has been accomplished.

**Table 3.6** Decision table for the two points–one transporter system

### **3.3 Multiple Points–One Transporter**

The objective of this section is to provide practical guidelines for implementing and optimizing multiple points–one transporter logistic systems using KIS.ME. Such a system is usually called a milk run one [2, 3] and comes from the dairy industry. In particular, it covers a network in which all item supply/delivery requirements of several transportation points are covered by one transporter, which visits all of them.

**Table 3.7** Triggers for rules *r*<sup>1</sup> − *r*<sup>6</sup>

**Fig. 3.22** Rule *r*<sup>1</sup> for the two points–one transporter system

Such a transporter operates within a predefined schedule, which is suitably spread over the shift time. A crucial assumption behind the economical justification of such a kind of systems is that each single point item load is smaller than the maximum transporter load volume. Consequently, the milk run strategy is frequently employed in internal plant logistics to transport, among others, items like

According to the just-in-time (JIT) strategy [4, 5], the number of manufacturers using the so-called supermarket concept is proliferating. Such supermarkets can be perceived as decentralised storage areas spread over a floorplan. As a consequence, they serve as storage places for parts required by the nearby assembly lines. Using such a nomenclature, transportation points can be divided into

**Fig. 3.23** Rule *r*<sup>2</sup> for the two points–one transporter system

**Fig. 3.24** Rule *r*<sup>3</sup> for the two points–one transporter system

Thus, transporter operators deliver the desired parts, which are stored in designated containers, to the assembly stations. Additionally, they collect empty containers from the assembly stations and bring them back to the supermarket points. Typically, such a process is realized with a fixed schedule and routes assigned to a given transporter, which serves a selected part of the entire assembly system, i.e., a subset of assembly stations. Such a process is accomplished by the return of the transporter to the supermarket and preparation for the next milk run tour, i.e., refiling with new

**Fig. 3.25** Rule for canceling the transportation command for the green point

containers, etc. Thus, it is obvious that decentralized supermarkets, with storage points spread over the floorplan, can provide more frequent and smaller packages of parts. As a consequence, the inventory at assembly lines can be reduced, along with the elimination of relatively long-travel deliveries from one central store. Irrespective of the transportation strategy used, there are two unwanted situations which have to be prevented by appropriate part delivery [6]:

Material shortage: This causes assembly stops resulting in an idle time; Enlarged safety stocks: This causes space reduction around the assembly point as well as increased inventory costs.

Furthermore, the container of parts may have an associated Kanban [7, 8] card including all important information about them. These cards are used by the Kanban system to provide permanent replacement of the consumed parts. In particular, the inventory level of each part at every assembly station is associated with the so-called Kanban number *k*. Thus, appropriate selection of *k* is crucial for preventing the above listed unappealing situations, i.e., either material shortages or enlarged safety stocks. There are several approaches which can be used to settle determination of *k*. However, all of them involve some heuristics along with a kind of conservativeness. As a representative example, let us recall the celebrated Toyota formula [9]:

### 3.3 Multiple Points–One Transporter 99

$$k \ge \frac{C\_r T\_r (1 + S\_f)}{K},\tag{3.1}$$

where

Irrespective of the replenishment strategy being used, the part consumption rate *Cr*, as well as the replenishment lead time *Tr*, is a time-varying parameter. Thus, the only way to achieve an appropriate replenishment balance is to monitor these parameters constantly.

The objective of the subsequent part of this section is to provide practical guidelines for implementing such strategies using KIS.ME. For the sake of simplicity, the proposed solution involves one transporter only. However, such conservativeness is to be eliminated in the subsequent section. As has already been mentioned, it is assumed that each transportation action is started in the supermarket points and aims at collecting the desired containers and transporting them to the assembly line stations. Sample supermarkets, located at RAFI GmbH & Co. KG, are presented in Figs. 3.26 and 3.27. As can be observed, they differ in their size as well as the transporters being used. Finally, the process is accomplished by collecting empty containers and bringing them back to the supermarket points.

Let us start with providing tools for measuring the container consumption rate. It can be given in containers per time unit. One can also imagine a situation in which it is expressed with a unified set of various container per time unit, which is required to perform a desired assembly process. The proposed strategy is based on the following general principles:

Maximum assembly point capacity: Each assembly station has a maximum level of containers which can be stored for further processing.

Capacity levels: The maximum capacity is uniformly divided into levels.

Light levels: Each capacity level is associated with a given color, e.g., level 1: green, level 2: yellow, level 3: red.

KIS.BOX implementation:

A sample KIS.BOX installed at the assembly system is presented in Fig. 3.28. Note that the strategy is similar to the one used for managing a small warehouse presented in Sect. 3.1.1. Thus, it will be revisited for the purpose of a simple yet illustrative example presented in the sequel.

**Fig. 3.26** A sample large supermarket at RAFI GmbH & Co. KG

**Fig. 3.27** Sample small supermarket at RAFI GmbH & Co. KG

**Fig. 3.28** Sample KIS.BOX installed at the assembly station

The KIS.BOX installed within the transporter is used to provide information about the selected transportation route being chosen. It is assumed that each route has an associated color, which is before the transportation action by the transporter operator. Thus, the general principles are as follows:

Route colors: Each route has an associate color, e.g., route 1: blue, route 2: turquoise, etc.

KIS.BOX implementation:

### **Container usage and replenishment**

Let us consider the floorplan presented in Fig. 3.29, which contains

Both the assembly stations and the transporter are equipped with KIS.BOXes, i.e., KIS.BOX Assembly 1, KIS.BOX Assembly 2, KIS.BOX Assembly 3, KIS.BOX Transporter. Let us consider a sample assembly station, i.e., Assembly station 1, equipped with KIS.BOX Assembly 1, along with the container capacity levels presented in Table 3.8. From the table, it is evident that, when there are three or four containers, then KIS.BOX Assembly 1 operational LED 1 should illuminate in green. Similarly, if there is one or two, then KIS.BOX Assembly 1 operational LED 1 should be yellow. Finally, the zero container level is indicated with red. The above functionality can be implemented with just two rules. These are identical to those presented in Figs. 3.16 and 3.17, and hence they are omitted.

**Fig. 3.29** Floorplan for the one transporter–multiple points system

**Table 3.8** Assembly station container capacity levels

The reverse, i.e., an increase in the container capacity level, can be realized with KIS.BOX Assembly 1 Button 2. Thus, the overall performance of the system can be described by extending Table 3.8 with such a functionality, which yields Table 3.9. This means that the KIS.BOX Button 2 operational LED color indicates the capacity level which is to be reached after refilling the storage place with two containers and pressing KIS.BOX Button 2. Indeed, if the storage place is full, then it is impossible to add any container, and hence the KIS.BOX Button 2 operational LED color is black, i.e., the KIS.BOX Button 2 operational LED is not lit. The above functionality can be also implemented with two rules, which are similar to those presented in Fig. 3.18. Note also that the remaining system parameters are set in the same fashion as those presented in Sect. 3.1.1.

Such an implementation should be performed for the remaining assembly stations. Once it is completed, it is possible to analyse each assembly station's efficiency with respect to container usage per time unit. This is, however, the objective of Sect. 3.5.

Now, let us proceed to details concerning the relations between supermarkets and assembly points. This pertains to the use of containers (sets of containers) from a

**Table 3.9** Container capacity management

**Table 3.10** Relation between supermarket points and assembly stations

x signifies a functional relation

S: supermarket point, A: assembly point

given supermarket point by a given assembly station. Such a relation is detailed in Table 3.10. This, for example, means that the final product development in Assembly station 2 requires a set of two containers, i.e., one from Supermarket point 1 and one from Supermarket point 2. This clearly means that Table 3.10 determines a set of possible routes from a supermarket point to an assembly station and back. Indeed, there is not always a need to supply all assembly stations within a given transportation cycle. Of course, there are plenty of possible replenishment strategies. For example, one can start it when the associated KIS.BOX operational LED is yellow (cf. Table 3.8), which corresponds to having one to two containers (sets of various containers) at a given assembly station. Irrespective of the criterion being used, a set of feasible routes can be determined as the one presented in Table 3.11. This set can also be visualized in the floorplan, which is presented in Fig. 3.30. According to Table 3.11, Route 1 covers all available supermarkets and assembly points, while Routes 2–5 can be perceived as its sub-routes. Thus, using them simply translates to smaller overall transportation costs and greater availability of the transporter. Note that the above set of routes is incomplete. However, it is sufficient for the illustration purposes. Finally, the KIS.BOX transporter obeys the following rules:

Route selection: The operator is pressing KIS.BOX Transporter Button 1 to select an appropriate route color. This is can be realized using a state-space model described in Sect. 2.10 with the states given in Table 3.11.

Transportation start/stop: After selecting an appropriate route the operator pushes KIS.BOX Transporter Button 2 to indicate the start of the transportation action. Once this action is accomplished, the operator pushes the button once again and the KIS.BOX operational LED 1 color turns black (idle state, cf. Table 3.11).

The implementation of the above functionality can be performed using similar mechanisms as those presented in the preceding sections, and hence it is not omitted here.

**Fig. 3.30** Floorplan with a set of routes

# **•** *>* **Transportation decision making**

The transportation decisions are made based on container usage or the consumption rate, which can be directly observed in KIS.MANAGER. Thus, there are a few options which can be used to perform appropriate decisions:

Transporter operator decision: The transporter operator is equipped with a mobile device, which enables displaying the floorplan along with the current container status of each assembly station. Using such knowledge the operator makes an appropriate decision on his/her own.

KIS.MANAGER operator decision: Based on the current container status of each assembly station, the KIS.MANAGER operator sends information to the transporter operator concerning a subsequent transportation action. For example, this can be realized

Dedicated rule-based decision: The rule base in Rule engine can be extended to automatically make the transportation decision. However, such an approach requires a relatively large number of rules, and hence it is recommended for small transportation systems only.

External software decision: The information about the current container status is fed to the external software (e.g., manually or using GPIOs), which returns an appropriate decision, further passed on to the transporter operator.

### **3.4 Multiple Points–Multiple Transporters**

As can be deduced after analysing Fig. 3.30, the number of possible routes proliferates substantially with that of both supermarkets and assembly stations. This situation becomes even more complicated if assembly stations exhibit large efficiency expressed in a significant container consumption rate. Such a situation makes the transportation more intense, and hence a larger number of transporters should be used. Thus, there are two possible strategies which can be employed for tackling multiple transporters:

The first strategy requires external software, which is responsible for providing a realtime schedule [10]. Such a software package should also take into account inevitable transportation delays, which can be present in the system. As a result, the work of transporters should be scheduled in so as to minimize the effect of such delays over the course of time. Since the primary objective of this book is to provide a concise guide to various applications of KIS.ME, the second strategy is to be utilised. Let us start with providing a detailed description of the zones. The floorplan is represented in two dimensions, which can be described with two variables, *x* and *y*. Thus, the floorplan can be considered a two-dimensional colored grid. The maximum resolution in both dimensions *x* and *y* is equal to the number of colors present in Table 2.2, i.e., eight. This means that it is possible to define up to 8 × 8 = 64 zones (Table 3.12).

Each zone is uniquely identified by a couple of colors *(x, y)*. For the purpose of a further discussion, let us assume that the multiple transporter–multiple points system is essentially based on the same KIS.ME-related strategy as the one presented in Sect. 3.3. The only exception is that a set of routes is assigned to a set of zones. This means that the route colors can be repeated in a different set of zones operated by different transporters. The same situation pertains to assembly stations in different zones, which may also have the same identification color. If transporters are assigned to designated zones, then the concept of determining the current zone of the transporter has to be provided as well. For that purpose, each transporter is to be equipped with an additional KIS.BOX, which can be called KIS.BOX Transporter Zone. The principles of such a KIS.BOX are as follows:

**Table 3.12** Floorplan zones along with their identification color

Identification of position *x*: The KIS.BOX Transporter Zone Button 1 operational LED color signifies *x* coordinate of the current zone.

Identification of position *y*: The behaviour of the KIS.BOX Transporter Zone Button 2 operational LED color signifies coordinate *y* of the current zone.

The behaviour of both Button 1 and Button 2 is implemented using the state-space model principle as the one described in Sect. 2.10, while the triggers are associated with pressing either Button 1 or Button 2. As a result, the current zone can be easily set by the transporter operator using just two buttons of KIS.BOX Transporter Zone.

### **Sample multiple transporter system**

In the example being considered, the entire floorplan is divided into 15 zones. Each one is identified by a suitable color, i.e., *x* ∈ {blue*,* turquoise*,* black} and *y* ∈ {blue*,* turquoise*,* black*,* green*,* magenta}. There are two transporters, and each of them has an associated set of zones, which are covered by the black and red borders presented in Fig. 3.31. As can be observed, KIS.BOX Transporter 1 Zone indicates that the associated transporter is within the zone (blue,black). Similarly, KIS.BOX Transporter 2 Zone signifies that the second transporter is within the zone (black,green).

**Fig. 3.31** Floorplan with zones and transporters

# **•** *>* **Physical zone identification**

The implementation of the proposed approach requires appropriate physical zone identification. This can be, for example, achieved by colored indicators on the borders of each zone on a given route. This will enable the transporter operator to provide appropriate modification of the current zone using KIS.BOX Transporter Zone. There are, of course, several other approaches, e.g., indoor WiFi-based position estimation, ZF Openmatics TAG Finder INDOOR [11], etc. Nevertheless, all of them inherit one common drawback, i.e., they require a separate software platform and cannot be integrated with KIS.MANAGER in a straightforward way.

Having sets of zones along with the associated transporters, it is possible to proceed to define positions of supermarkets and assembly points, which are depicted in Fig. 3.32. In the black zone, it can be observed that Supermarkets 1 serves Assembly points 1–3. In the red zone, it is assumed that Supermarkets 2–3 serve Assembly point 4. Finally, Assembly point 5 is served by Supermarket 3 only. With the above configuration, a set of routes for each set of zones can be provided. The resulting set of routes is given in Tables 3.13 and 3.14 for the black and the red set of zones, respectively. The resulting routes are portrayed in Fig. 3.33.

**Fig. 3.32** Floorplan with zones, transporters and supermarket/assembly points

**Table 3.13** Set of routes for black zones

S: supermarket point, A: assembly point

**Table 3.14** Set of routes for red zones

S: supermarket point, A: assembly point

**Fig. 3.33** Floorplan with feasible routes

Finally, it should be pointed out that the transportation decisions can be made in a similar way as those explained in Sect. 3.3. However, in this case, the position of each transporter is known, which may facilitate optimal transportation decisions.

### **3.5 Visualizing the Performance of Logistic Applications**