**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: demo.kisme@rafi.de.
	- 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 john.doe@controlintech.pl 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. However, due to the use of "–", rule *r* <sup>1</sup> <sup>1</sup> may have four alternative forms:

$$r\_1^1 \in \left\{ \begin{bmatrix} F \\ F \\ F \end{bmatrix}, \begin{bmatrix} T \\ T \\ F \end{bmatrix}, \begin{bmatrix} F \\ T \\ F \end{bmatrix}, \begin{bmatrix} T \\ F \\ F \end{bmatrix} \right\},$$

while rule *r*<sup>2</sup> has two alternative ones:

$$r\_2 \in \left\{ \begin{bmatrix} T \\ T \\ F \end{bmatrix}, \begin{bmatrix} T \\ T \\ T \end{bmatrix} \right\}.$$

This clearly means that there are six rules and the decision table (Table 2.10), and hence the set of rules is incomplete. 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.

Triggers: There are two rules and their triggers are associated with pressing either KIS.BOX 1 Button 1 or KIS.BOX 2 Button 2.

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**

Let us reconsider the two points–one transporter system detailed in Sect. 3.2. The entire system operates within the floorplan presented in Fig. 3.21. The objective of this section is to provide straightforward measures for calculating the performance of such a system. For that purpose, let us assume that all KIS.BOXes, i.e., KIS.BOX Green, KIS.BOX Red and KIS.BOX Transporter, are initialized in such a way that all operational LEDs are black, i.e., they do not illuminate. Under such an initial condition, reconsider the following transportation scenario:


The objective is to visualize and analyze


After analysing the above six-point transportation scenario, it can be concluded that


The above tasks can be conveniently realised using the Datapoint Chart, which can be configured according to the approach presented in Sect. 2.12. Let us start with introducing such a chart inWorkspace 1. Such a configuration can be easily performed


**Fig. 3.34** Datapoint chart for the transportation system

using KIS.BOX Green button1ColorKpiDuration. This process is shown in Fig. 3.34. With the chart, one can easily monitor each time measurement (A or B) visually, as shown in Fig. 3.35. A precise quantitative analysis can also be performed by downloading a CSV file using the Datapoint Chart. The content of the resulting file is presented in Fig. 3.36. The file can be further processed in a number of external computational packages, e.g., Matlab, Excel, etc. However, such data processing is also possible in KIS.MANGER, but this is beyond the scope of this chapter. Indeed, further details are provided in Chap. 4, where the concepts of KPIs are introduced (see Sect. 4.1.2). Nevertheless, one can easily extract three states from Figs. 3.35 and 3.36, while the time duration between them constitutes an answer to the above stated questions (A) and (B).

**Fig. 3.35** Visualization of transportation performance


# **3.6 Training Exercises**

**3.1** Mounting and managing an external sensor

Exercise requirements: The exercise requires access to one KIS.BOX and a sensor, e.g., a photoelectric one, compatible with an M12 connector and a 24 V power supply.


### **3.2** Access control without RFID

Exercise requirements: The exercise requires access to one KIS.BOX and one KIS.LIGHT.

1. Prepare a set of rules which will repeatedly change the color of the KIS.BOX Button 1 operational LED according to the state sequence (cf.Sect. 2.10) presented in Table 3.15. Using the KIS.BOX digital twin, set the initial state to Stat 1.


**Table 3.15** Color transition


$$k^n = 2^4 = 16,\tag{3.2}$$

where *n* is the number of states (see Table 3.15) and *k* is the number of KIS.BOX buttons. Thus, using all possible eight colors (cf. Table 2.2), it is possible to have 256 configurations. Using the rule Optional settings, implement your own access control mechanism with an additional Trigger counter setting.

### **3.3** Hotel floor warehouse

Exercise requirements: The exercise requires access to one KIS.BOX.

	- Red corresponds to the zero towel level;
	- Yellow signifies the towel level which is sufficient for one day;
	- Green stands for the towel level for two days;

### **3.4** Hotel two-floor warehouse

Exercise requirements: The exercise requires access to two KIS.BOXes, e.g., KIS.BOX 1 and KIS.BOX 2.

1. Having a KIS.BOX 1 with an associated single floor towel warehouse implementation, perform an identical implementation for KIS.BOX 2. It will correspond to another floor, which obeys the same rules like the previous one.

### 3.6 Training Exercises 113


# **3.5** Small warehouse with access control

Exercise requirements: The exercise requires access to two KIS.BOXes, e.g., KIS.BOX 1 and KIS.BOX 2.


**3.6** Two points–one transporter revisited

Exercise requirements: The exercise requires access to three KIS.BOXes, e.g., KIS.BOX Point 1, and KIS.BOX Point 2 and KIS.BOX Transporter.


**3.7** Digitalization of an assembly system

Exercise requirements: The exercise requires access to one KIS.BOX.

1. Let us consider a single container that is fed to the assembly system. In particular, the container covers the following parts (digits):

$$C = \left[1, 2, 3, 4, 5, 6, 7, 8, 9, 10\right]. \tag{3.3}$$


**3.8** Digitalization of an assembly system continued

Exercise requirements: The exercise requires access to one KIS.BOX.

1. Let us consider an assembly system which is fed with a set of two containers, required for the assembly process. In particular, the first one is described by (3.3) while the second one is given by

$$C\_l = \left[ a, b, c, d, e, f, \mathbf{g}, h, i, j \right]. \tag{3.4}$$


### **3.9** Monitoring transporters' current position zone

Exercise requirements: The exercise requires two KIS.BOXes, e.g., KIS.BOX Transporter 1 Zone and KIS.BOX Transporter 2 Zone.


### **3.7 Concluding Remarks**

The objective of this chapter was to provide a set of tools which can be used for quick design and integration of logistic applications. In particular, the chapter started with extending KIS.Devices with RFID interfaces, which enable access control regarding the assets being monitored within KIS.MANAGER. Two kinds of access control were introduced, namely, general and individual. Within the former, the users are treated in the same way, i.e., each user having a suitable RFID tag is treated identically. Contrarily, in the latter, each user is uniquely recognized by KIS.MANAGER, which makes it possible to develop a tailored access control hierarchy. The rest of the chapter was concerned with a logistic application. It started with a way of using KIS.Devices for monitoring a small warehouse. Subsequently, a digitalization of one transporter operating between two points was introduced and analysed. In particular, a set decision table was presented, which handles all possible routes between these two points. An alternative concept was introduced for one transporter operating between multiple points. Each point was defined as an assembly station, which has a certain capacity of containers with parts. Such a capacity is required to assure an appropriate and efficient assembly flow. Thus, the task of the transporter was to provide an appropriate container flow between container supermarkets and assembly points. For that purpose, a KIS.ME-based optimization was proposed. Subsequently, the concept was extended to multiple transporters operating in specified zones. Note that each zone was uniquely identified using coordinates (x,y) translated into two colors visible on KIS.BOX, identifying the current position of a transporter. Finally, a set of training exercises was provided, which summarize the knowledge covered within this chapter.

# **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 4 Implementing and Using Essential Statistical Process Control**

# **4.1 Data Processing Definitions**

The objective of the preceding chapters was to introduce essential features of KIS.ME (cf. Chap. 2) and provide a list of typical logistic use cases for which it can be employed (cf. Chap. 3). Irrespective of the kind and structure of the system being developed, it involves a number of KIS.Devices, which provide several Datapoints (see Sect. 2.7). To make this chapter self-contained, let us recall that a Datapoint is a read only variable, which corresponds to a possibly time-varying property of a KIS.Device. It can be also defined as an exchanged value between the KIS.Device and KIS.MANAGER. In the preceding chapters, Datapoints were employed for developing the rules governing system behaviour as well as to graphically visualize it using Datapoint Charts. In this chapter, it will be shown how to process and analyse Datapoints. Let us recall that they are updated based on events associated with their current status. This means that, if the status of KIS.Devices changes, then an appropriate update message is sent to KIS.MANAGER. Having access to Datapoints, one can process them further by using scripts prepared using the FLEX programming language (see Appendix A). Such a processing procedure can be performed either instantly (real time) or over a predefined processing period which can be set to either 15, 30 or 60 min. For that purpose, let us introduce two definitions:

Calculated Datapoints (CDPs): FLEX language-based scripts enabling instant processing of Datapoints,

Key performance indicators (KPIs): FLEX language-based scripts enabling processing of Datapoints over a predefined processing period.

The concept of CDPs is rather straightforward, and as a simple example one can imagine a CDP script transforming frequency of KIS.BOX digital input from mHz to an equivalent period, i.e., *<sup>T</sup>* <sup>=</sup> <sup>1</sup> *<sup>f</sup>* , where *T* stands for the period and *f* is the frequency. Contrarily, the concept of KPIs requires further explanation. For that purpose, let us consider principles for the calculation and analysis of KPIs, which are

**Fig. 4.1** Principles for the calculation and analysis of KPIs

presented in Fig. 4.1. It is possible to define a number of scripts performing a number of calculations based on selected Datapoints (cf. Calculation 1 and Calculation 2 in Fig. 4.1). Such KPI scripts can, of course, be defined over different processing periods while the results of the calculations are available at the and of such periods. Finally, they can be displayed and analysed using various widgets (see Sect. 2.5).

### **KPI: An introductory aggregation example**

Let us consider sample KPIs, which provide some calculation results every 15 min. Such a process is illustrated in Fig. 4.2. The results provided can be further aggregated using various strategies. As can be observed, each KPI is calculated using 15-min processing period. From the start of the process one can observe that there are four such 15 min processing time windows. This clearly means that sample aggregations of the sum and average values of the calculation being considered can be summarized in Table 4.1.

The aggregation mechanism is to be clearly illustrated and explained in the subsequent sections of this chapter.

Furthermore, FLEX language commands available in KIS.ME are divided into five groups, which are given in Table 4.2. As a final conclusion, it can be stated that the Aggregations and Intervals commands are limited to KPIs only (see Appendix A for a detailed explanation).

**Fig. 4.2** Sample KPI aggregation calculations


**Table 4.1** Evolution of a sample KPI as well as its sum and average aggregations




**Fig. 4.3** Transition rule Green→Red for KIS.BOX Red


**Fig. 4.4** Transition rule Red→Green for KIS.BOX Red

### *4.1.1 Calculated Datapoints*

The objective of this section is to provide a practical example concerning the design of sample CDPs. The example is implemented in Workshop 1 and uses KIS.BOX Red. For illustrative purposes, two simple rules were implemented, which are presented in Figs. 4.3 and 4.4. These two rules transfer KIS.BOX Red from one state to another. These states correspond to either the green or the red color of the KIS.BOX Red Button 1 operational LED. The same rules were implemented for KIS.the BOX Red Button 2 operational LED, but they are omitted for brevity. In both cases, the rule trigger is associated with pressing either the first or the second KIS.BOX Red button. Finally, the initial states of are initialized using the KIS.BOX Red digital twin (cf. Sect. 2.6), i.e., the corresponding operational LED colors are set to green. Let us start with employing a sample command, which is called Counter and belongs to the Miscellaneous group (cf. Appendix A.15). The syntax and the functionality of the above command can be summarized as follows:

$$\mathbf{y} = \text{Counter}[\mathbf{x}, b\_p] \tag{4.1}$$

and

$$\begin{aligned} \text{if } \mathbf{x}\_c \ge \mathbf{x}\_p \text{ then } \mathbf{y} = \mathbf{x}\_c - \mathbf{x}\_p, \\ \text{else } \mathbf{y} = \mathbf{b}\_p + \mathbf{x}\_c - \mathbf{x}\_p, \end{aligned} \tag{4.2}$$

where *x* is a possibly varying value while *xc*, *x <sup>p</sup>* signify *x* at *c* > *p* time instances, whilst *bp* stands for a possibly time-varying bias. Let us proceed to defining a CDP employing such a command. For that purpose, KIS.BOX Red should be selected from the available assets (Main menu→Assets). Subsequently, one should select the KPI/Data processing button and use the Create blank option . As a result, a new Data Processing Definition can be formulated as the one presented in Fig. 4.5. The data processing definition was selected to be CDP and is called Counterdmo. Its entire implementation boils down to y=Counter[x,0], with *x* being an input Datapoint button1ColorKpiDuration. According to the above-described rules (cf. Figures 4.3 and 4.4), *x* may have two values only, i.e., 3 (green color) or 5 (red color). Thus, according to (4.2), Counterdmo can return only two values, i.e., either *y* = 5 − 3 = 2 (*xc* = 5, *x <sup>p</sup>* = 3) or *y* = 0 + 3 − 5 = −2 (*xc* = 3, *x <sup>p</sup>* = 5, *bp* = 0). This means that Counterdmo simply calculates the difference between consecutive values of *x*. To visualize this graphically, let us include the Datapoint Chart within the KIS.BOX Red dashboard (see Sect. 2.7). The resulting plot is portrayed in Fig. 4.6.


**Fig. 4.5** Implementation of the Counterdmo CDP

**Fig. 4.6** Variable *x* (red) and Counterdmo CDP calculation (green) for *y* = Counter[*x*, 0]

**Fig. 4.7** Variable *x* (red) and Counterdmo CDP calculation (green) for *y* = Counter[*x*, *x*]

Finally, it is important to underline the fact that, if *x* remains unchanged during a possible reconnection of the KIS.Device, then *x <sup>p</sup>* = *xc*, and hence *y* = 0 is obtained. Let us proceed to a more advanced usage of the Counter command. Counterdmo can be easily redefined with a new syntax, i.e., y=Counter[x,x]. According to (4.2), Counterdmo can return only two values, i.e., either *y* = 5 − 3 = 2 (*xc* = 5, *x <sup>p</sup>* = 3) or *y* = 5 + 3 − 5 = 3 (*xc* = 3, *x <sup>p</sup>* = 5, *bp* = 5). These results are visualized in Fig. 4.7. Let us consider another command, which simply filters the data by permanently returning the last value satisfying a given logical formula. For that purpose, let us define another CDP, which will be called Filterdmo and will employ the following syntax: y=Filter[Equal[x,3]] (or, equivalently, Filter[x==3]). If *x* can be either 3 or 5, then after the first occurrence of 3 the answer of the Filterdmo CDP remains at the level of 3 (see Fig. 4.8). It should be noted that the argument of the Filter command can be any logical relation, e.g., *x* >= 3&&*x* <= 5.

**Fig. 4.8** Variable *x* (red) and Filterdmo CDP calculation (green) for *y* = Filter[*Equal*[*x*, 3]]

### **Plotting workers' idle state**

Let us consider two workers performing identical works at a single assembly station. Both of them use KIS.BOX Red to indicate two states:

Assembly in progress: exemplified by the red color of operational LEDs, Idle: exemplified by the green color of operational LEDs.

This means that Worker 1 uses KIS.BOX Red Button 1 while Worker 2 utilizes KIS.BOX Red Button 2. The rules for switching between assembly and idle states are given in Figs. 4.3 and 4.4. The problem is to indicate the time in which both workers are in idle state, i.e., the Button 1 and Button 2 operational LEDs are green. Let us consider a CDP performing such an action, which is called Idle and is given in Fig. 4.9. It uses input variables *x* and *z*, which are defined with two KIS.BOX Red Datapoints, i.e., button1ColorKpiDuration and button2ColorKpiDuration, respectively. The calculation involving such variables utilizes the If[] command (cf. Appendix A). If both *x* and *z* equal 3, then the KPI returns 1 and 0 otherwise. Note that 1 signifies the fact that both workers are in idle state, while the opposite situation means that at least one of them is performing an assembly process. As a result, Figs. 4.10 and 4.11 present the state evolution of Worker 1 and Worker 2. Finally, Fig. 4.12 clearly indicates the time periods for which both workers are in idle state. In spite of the simplicity of the CDP, it may have various practical applications, i.e., optimization of work distribution, part delivery schedules, etc.

### 124 4 Implementing and Using Essential Statistical Process Control


### **Fig. 4.9** Idle CDP

**Fig. 4.10** States of Worker 1

**Fig. 4.11** States of Worker 2

**Fig. 4.12** Evolution of the Idle CDP

The examples presented in this section are very simple and involve one- line commands. There are, of course, no restrictions behind developing multiple-line CDPs. Moreover, own variables can be used without any prior declarations, i.e., a variable begins its lifetime after assigning to it a value, which is realized by the following program:

### **Sample two-line code**

```
MyVar=x+3;
OutVar=Counter[MyVar,0];
```
# **•** > **CDPs versus the Datapoint range**

Note also that each CDP can operate with Datapoints of one KIS.Device only. It is possible to include Datapoints from different KIS.Devices indirectly, i.e.,


Finally, let us recall that a complete list of the FLEX commands along with representative examples is given in Appendix A.

### *4.1.2 Key Performance Indicators*

As indicated in Figs. 4.1 and 4.2, the functional nature of KPIs is significantly different than the one of CDPs. Indeed, CDPs process incoming data directly without any aggregation mechanisms, e.g., summation (cf. Figure 4.2). Thus, the objective of this section is to provide illustrative design examples pertaining to such aggregations as well as working on data within predefined processing periods.

### **Introduction to KPI design**

Let us consider a worker performing an assembly process (cf. Sect. 4.1.1). KIS.BOX Red is used in this case to indicate two states:

Assembly in progress: exemplified by the red color of the KIS.BOX Red Button 1 operational LED,

Idle: exemplified by the green color of the KIS.BOX Red Button 1 operational LED.

The rules governing transitions between these two states are given in Figs. 4.3 and 4.4. Similarly as in Sect. 4.1.1, one can also easily configure a Datapoint Chart displaying the successive transitions between these two states, which simply includes the values of the button1ColorKpiDuration Datapoint. The objective of this introductory KPI example is to provide a periodic calculation of the number of products being assembled. Thus, under a state transition strategy being used, the KPI should periodically calculate the number of transitions of the KIS.BOX Red Button 1 operational LED from red to green. To settle the KPI implementation, the simple instruction y=Sum[If[x==3,1,0]] is used, where *x* stands for the button1ColorKpi Datapoint (see Appendix B). The remaining KPI parameters are as follows:

Processing period: 15 min;

Processing start: the data of starting calculations of the KPI, which is 09/22/2021; Starting hour: the starting hour is 14.00;

Initial value: no values from previous periods are taken into account.

A new KPI design can be initiated in the same way as that of a CDP, and hence the resulting configuration window is given in Fig. 4.13, whilst the new KPI is called Sumdmo. It should be noted that KPIs cannot be displayed with the Datapoint Chart. This is caused by the fact that they should be aggregated using a desired operation (cf. Fig. 4.2), which can be one of the following:


Such an aggregation can be achieved with suitable widgets (Sect. 2.5), which will be discussed in detail in Sect. 4.3. Following the approach described in Sect. 2.5, let us introduce the Single Value KPI widget, which will accompany the Datapoint Chart displaying the evolution of the button1ColorKpiDuration Datapoint. A sample configuration of the above widget is presented in Fig. 4.14. As can be observed, the aggregation type is SUM. Moreover, the date range of interest is the current

### 4.1 Data Processing Definitions 127


**Fig. 4.13** Implementation of the Sumdmo KPI

day. However, according to Fig. 4.13, the Sumdmo KPI begins its lifetime at 14.00. Figure 4.15 presents the obtained results, which were recorded during one hour. They are summarized in Table 4.3 and can be easily calculated using the Datapoint Chart, i.e., the number of transitions from red to green (5–3). Thus, it is evident that the SUM of KPI values is equal to 10 whilst the MIN and MAX are equal to 2. As a consequence, the AVERAGE is equal to 2.5. Irrespective of the relative simplicity of the example being considered, it may have several practical applications pertaining to production/transportation flow and efficiency monitoring.

The objective of the remaining part of this section is to provide some template KPIs along with their prospective applications, which pertains to


### **Monitoring task realization durations**

Let us reconsider a worker from the previous example, which is equipped with KIS.BOX Red indicating its current working mode, i.e., either assembly or idle periods. The first objective is to implement the KPI which will calculate the sum of the assembly times within a 15-min processing period. Let us start with selecting an appropriate Datapoint, which is simply button1ColorKpiDuration. Thus, during the assembly process, it returns 5, which corresponds to the red color. This means that the implementation of the KPI should boil down to the following steps:

### 128 4 Implementing and Using Essential Statistical Process Control


**Fig. 4.14** Configuration of the single value KPI widget

**Fig. 4.15** Sumdmo KPI aggregation


The implementation covering all the above steps is presented in Fig. 4.16, whilst a detailed explanation behind each command is given in Appendix A. Note that

### 4.1 Data Processing Definitions 129


**Table 4.3** Evolution of the Sumdmo KPI


**Fig. 4.16** Implementation of the Duration KPI

the calculation of the Duration KPI is started at 12.00 and no values from previous processing periods are taken into account. Let us proceed to the second objective, which pertains to calculating


As previously, the above tasks can be easily implemented by installing the KPI Single Value widgets within the dashboard. Each of them should, of course, perform a different aggregation, i.e., SUM, AVERAGE, MAX, and MIN. Finally, a sample implementation along with the obtained results is presented in Fig. 4.17. Note that the maximum sum of durations per a processing period can be equal to 15 × 60 = 900[*s*], which expresses the situation in which the assembly is permanently performed during 15 min. Contrarily, the minimum sum of durations per processing period can be equal to zero, which means that no assembly was performed within a processing period.

**Fig. 4.17** Duration KPI aggregations

### **Number of assembled products per time unit**

The example being considered operates within the same infrastructure as the previous one. Let us imagine that each push of a button corresponds to one product being assembled. Thus, let us start by selecting an appropriate Datapoint, which is button1Pressed and has an alias name *x* within the KPI definition. This Datapoint operates in a very specific way, i.e., it stores the timestamps corresponding to the beginning of pressing actions only. Thus, it is enough to calculate the number of logical true values of *x* within the processing period. Subsequently, the accumulated number of transitions has to be normalized over the time interval spent on realizing a given task. The above-stated objective can be realized with the KPI given by the following program:

### **Product per minute KPI**

```
ProductSum = Sum[If[x,1,0]];
Productivity = Round[ProductSum / (Interval[] / 60000)];
```
The first line is responsible for calculating the number of products, i.e., the total of KIS.BOX touches. The second one normalizes ProductSum over the respective time interval. Finally, the achieved results are given in milliseconds, and hence they have to be further normalized. Note also that the rounding operation is introduced to get a result, which is an integer value.

### **First pass yield**

Let us consider a conventional product quality check point. It has two digital outputs, which are directly connected with KIS.BOX Red digital inputs. They provide a false– true–false sequence when a products passes (Input 1) or fails (Input 2) the quality test. Let us start with noting that Input 1 and Input 2 are represented by two Datapoints, i.e., input1Status and input2Status, respectively. Let us define two variables which are to be associated with these Datapoints, i.e., passed and failed. Let us recall that the percentage FPY is expressed by the ratio

$$\text{FPY} = \frac{p}{p+f} \times 100,\tag{4.3}$$

where *p* and *f* stand for the number of failed and passed products, respectively. Finally, the KPI implementing (4.3) is given by the following:

### **First pass yield KPI**

```
NumberPassed = RisingEdge[passed];
NumberFailed = RisingEdge[failed];
Total = NumberPassed + NumberFailed;
FPY = If[Total>0,Round[NumberPassed/Total*100],0];
```
As in the previous example, the first two lines are responsible for calculating the *p* and *f* underlying (4.3). Subsequently, the total sum of products being tested is obtained. Finally, FPY is calculated according to (4.3) along with suitable rounding.

# **•** > **Sharing CDPs and KPIs**

Using Main menu→Assets, and then selecting the desired KIS.Device, one can choose KPI/Data processing . As a result, a full list of KPIs and CDPs defined for this KIS.Device is displayed. Moreover, each of them can be shared with compatible KIS.Devices of a designed asset group. For that purpose, the Share option should be used and the desired asset group chosen, e.g., Workspace 1. Once the sharing procedure is performed, the selected CDPs/KPIs are visible after using KPI/Data processing within a designated asset group. However, sharing should be interpreted in such a way that a given CDP/KPI is inherited for all assets in a designated asset group. Indeed, Datapoints used within the shared CDP/KPI are taken from the inheriting KIS.Device instead of the original one.

### **4.2 Statistical Measures: Location and Variability**

The objective of this section is to introduce essential concepts of statistical process control (SPC). However, before going into details, its is necessary to define a process [1–3] as follows:

# **•** > **Process**

A process is everything what is needed for transforming an input into an output for a customer.

Thus, SPC can be perceived as a quality control method, which employs statistical approaches to observe and control a process. This may result in keeping the desired process efficiency, assembling the demanded number of products with a desired quality, etc. This means that SPC deals with understanding and managing variability associated with a given process. For that purpose, a process parameter, i.e., a quantitative variable, which reflects the process quality must be selected. Irrespective of the process parameter being observed and controlled, it obeys some distribution, which has three crucial features:


Concerning the shape, the most common approach is to assume that the process parameter is normally distributed. Such a distribution is portrayed in Fig. 4.18. The Central location can be briefly perceived as an expected process parameter value whilst the variability signifies its spread around this value. Let us start with recalling the crucial measure of location, which is simply the mean or average value given by a well known formula:

$$
\bar{x} = \frac{1}{n} \sum\_{i=1}^{n} x\_i,\tag{4.4}
$$

where *xi* is the *i*-th process parameter observation whilst *n* stands for the number of observations and *x*¯ is the mean value. This measure can be easily calculated by forming the KPI incorporating the Mean command (cf. Appendix A). Another useful location measure is a median , which is the parameter value at which half of the observations fall above and half below. However, KIS.ME does not provide a direct command which can be used to calculate that. Fortunately, for that purpose, percentiles, implemented with the Percentile command, can be efficiently employed.

# **•** > **Percentile**

A percentile is simply defined as a statistical measure indicating the process parameter value below which a given percentage of observations in a group of observations fall. Thus, the 50th percentile is the value below and over which 50% of the process parameter observations can be found. As a result, the KPI calculating the median value can be simply implemented as m=Percentile[x,50], where *m* stands for the median whilst *x* is the set of observations being analysed. Note also that all observations *x* are at or below the 100th percentile, i.e., m=Percentile[x,100].

Let us proceed to variability measures. The most common ones are the standard deviation, the variance and the range. The first of those is defined as

$$
\sigma = \sqrt{\frac{\sum\_{i=1}^{n} (\mathbf{x}\_i - \bar{\mathbf{x}})^2}{n-1}},
\tag{4.5}
$$

where σ signifies the standard deviation, which can be calculated by defining the KPI involving sigma=Stdev[x]. The second variability measure is simply a square of the first one, i.e., σ2. Finally, the range is defined as the difference between the maximum and minimum values of *<sup>x</sup>* <sup>∈</sup> <sup>X</sup>. Thus, the resulting KPI should be implemented with range=Max[x,x]-Min[x,x]. Having measures of location and variability, one can distinguished two possible SPC states of the process [1]:

Process in control: 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 X. Process out of control The process is in the out-of-control state if it subject to both common and special cause variations. Thus, apart from the inevitable random and typical fluctuations, other unappealing factors affect process parameters.

A periodical evolution of a sample distribution of the process in control parameter is presented in Fig. 4.19. Even if a given process parameter is at an unacceptable level, e.g., FPY (4.3) is equal to 70%, one can be sure that such results can be expected for the subsequent time periods. Indeed, when one says that the process is in control,

**Fig. 4.19** Periodical evolution of the process-in-control parameter distribution

**Fig. 4.20** Periodical evolution of the process-out-of-control parameter distribution

then this does not mean that it is working perfectly, but simply that it is predictable or periodically stable. Finally, improvements can be achieved by suitable rearrangement or optimization of the process. This is, however, beyond the scope of this section.

If the process parameter distribution changes with each periodically collected set of observations, then one has the process out of control. Such a situation is illustrated in Fig. 4.20. In practice, several processes obey such periodical behaviour. Thus, it is obvious that special cause variations should be identified and removed if possible. Similarly, the influence of common cause variations can be removed by a suitable analysis and improvement of the process.

### **Mean and standard deviation of assembly durations**

Let us reconsider the example presented in Sect. 4.1.2 pertaining to monitoring task realization durations. The worker realizing such tasks is equipped with KIS.BOX Red indicating its current working mode, i.e., either assembly or idle periods. The objective is to implement KPIs calculating the mean and standard deviation of durations corresponding to the assembly mode. Moreover, the calculations should be realized within 15-min processing periods. As previously, the button1ColorKpiDuration Datapoint is used for calculation purposes whilst the results are visualized with the KPI Single Value widget. In particular, the widget should provide the maximum of the mean and standard deviation obtained during the last hour. The configuration of such a widget was described in Sect. 4.1.2, and hence it is omitted. Before going to the KPI implementation, let us also recall that the KIS.BOX Red Button 1 operational LED is governed by two rules, which change its color between red (assembly mode) and green (idle mode) with the trigger associated with pressing the respective button. Thus, during the assembly process the button1ColorKpiDuration Datapoint returns 5 (red color) and 3 (green color). Let us proceed to the KPI implementation, which starts by defining *x* as an alias name of the button1ColorKpiDuration Datapoint. As a result, the KPIs calculating the mean and the standard deviation of the assembly durations are given by the following programs:

### **Mean of assembly durations**

```
t=If[x==5,Duration[x],0];
y=Round[Mean[Filter[t>0]]/1000];
```
**Standard deviation of assembly durations**

```
t=If[x==5,Duration[x],0];
y=Round[Stdev[Filter[t>0]]/1000];
```
Finally, a sample of the performance of the above KPIs is presented in Fig. 4.21.

Taking into account the discussion presented in this section, the results in Fig. 4.21 clearly show that the assembly process is realized with greater duration variability (cf. Max standard deviation). This clearly means that such a process has to be suitably improved to get more predictable and less variable results. For that purpose, a set of widget control charts is to be introduced in the subsequent section.

# **4.3 Understanding process performance with widgets: A practical way to statistical control charts**

The objective of this section is to provide a practical guidance on using four widget control charts:


**Fig. 4.21** Sample maximum mean and standard deviation of assembly durations


They can by associated with any dashboard, which is located either in assets or asset groups (cf. Sect. 2.5). The first option can be accessed via Main menu→Assets→Edit dashboard→Add widget, which results in the view portrayed in Fig. 4.22. The second option is to follow Main menu→Asset groups and then select the desired workspace. Subsequently, Edit dashboard→Add widget have to be chosen, which yield the view presented in Fig. 4.23. Irrespective of the selected design approach, the quadruple of control chart widgets possesses the same functionality, which is to be discussed in the subsequent part of this section.

### **KIS.Device-based data generation**

The control chart widgets being discussed in this section require data obtained with Datapoints of a given KIS.Device. Thus, to perform a unified presentation of all widgets, which can be easily reproduced, the following data generation approach is proposed:

Environment: It is defined with Workspace 1 and the dashboard of KIS.BOX Red. Triggers: The triggers are based on the KIS.BOX Red Button 1 operational LED color, which can be either red or green. Additionally, each trigger is fired after one minute.

**Fig. 4.22** KPI control charts within the asset dashboard

Actions: The associated actions are associated with changing the KIS.BOX Red Button 1 operational LED to an opposite value.

Initial condition: The KIS.BOX Red Button 1 operational LED is initialized with the associated digital twin (see Sect. 2.6), i.e., its color is set arbitrarily to either green or red.

The above functionality can be easily implemented using two rules, which are presented in Figs. 4.24 and 4.25. As a result of employing these, cyclically (every minute) changing values of the button1ColorKpiDuration Datapoint are generated, which are presented in Fig. 4.26. These data are to be used for statistical processing and visualization using the control chart widgets. Although the data presented in Fig. 4.26 looks like a uniform one with each cycle equal to one minute, there are some small discrepancies between cycle durations. This is related to the wireless transmission between the KIS.Device and KIS.MANAGER. Such behaviour is to be statistically analysed in the subsequent part of this section. This, however, requires defining suitable KPIs. In particular, it is proposed to employ two KPIs which will calculate mean values of the KIS.BOX Red Button 1 operational LED color durations over a 15-min processing period. Since there are only two colors, i.e., red and green, these KPIs are implemented as follows (with *x* being an alias of button1ColorKpiDuration):

**Fig. 4.23** KPI control charts within the asset group dashboard


**Fig. 4.24** First rule for KIS.BOX-based data generation

### **Mean of red color durations**

```
t=If[x==5,Duration[x],0];
y=Round[Mean[Filter[t>0]]/1000];
```
4.3 Understanding process performance with widgets … 139

**Fig. 4.25** Second rule for KIS.BOX-based data generation

**Fig. 4.26** KIS.BOX-based data sequence

### **Mean of green color durations**

t=If[x==3,Duration[x],0]; y=Round[Mean[Filter[t>0]]/1000];

# *4.3.1 Single Value Column Chart*

The objective of this section is to provide practical guidelines for using the KPI Single Value Chart, which is simply a bar plot displaying an aggregated value of a selected KPI within a specified aggregation period (cf. Figure 4.2). This widget has the following properties:

Headline: the widget name, displayed on it;

Label: the name of the bar plot;

KPI name: the selected KPI name;

Unit: the KPI unit, e.g., seconds [s];

Date range: the selected, possibly historical, date and time range, e.g., a working shift;

Aggregation type: KPI values calculated within processing periods are aggregated within the date range using one of the following aggregations: sum, average, max, min (cf. Figure 4.2);

Zones: color zones associating the value range of the bar plot with the selected color.

Fig. 4.27 illustrates a sample bar plot. It displays the KPI values corresponding to the mean KIS.BOX Red Button 1 operational LED green color durations. They are aggregated using the average aggregation operator between 8:00–16:00 h on October 13th, 2021.

# *4.3.2 Single Period and Pie Charts*

The section aims at describing the way of using the KPI Single Period Chart, which is a multiple bar plot displaying an aggregated value of selected KPIs within a specified aggregation period (cf. Fig. 4.2). This widget has the following properties:

Headline: the widget name, displayed on it;

KPI name: the selected KPI names, whose values are used to form multiple bar plots;

Label: the name of bar plot;

**Fig. 4.28** Sample KPI single period chart

Color: the color associated with the bar plot;

Unit: the unit of the KPIs, e.g., seconds [s];

Date range: The selected, possibly historical, date and time range, e.g., a working shift;

Aggregation type: KPI values calculated within processing periods are aggregated within the date range using one of the following aggregations: sum, average, max, min (cf. Figure 4.2);

Stack KPI: Defines the display form of bars (either stacked or separated).

Figure 4.28 presents a sample two bar plot. It displays two KPI values corresponding to the mean KIS.BOX Red Button 1 operational LED durations of either the green or red color states, respectively. They were aggregated using an average aggregation operator between 8:00–16:00 h on October 13th, 2021. Note that the same single period is used for all bar plots. Additionally, the units are defined, i.e., seconds [s] are used as units. Finally, the stacked version of the above plot is presented in

Fig. 4.29. Its appealing property is that it allows sum-based grouping of bar plots. Except for the bar plots, KIS.MANAGER provides a KPI pie chart. Apart from the Stack KPI, its properties are the same as those of the KPI Single Period Chart, but instead of using multiple bars a pie-like plot is employed. In particular, pieces of pies are proportional to the values of KPIs. As a result, the KPI pie chart counterpart of Fig. 4.29 is presented in Fig. 4.30. As can be observed, the percentage proportions between the pieces of the pie are displayed as well.

# *4.3.3 Aggregated Chart*

The objective of this section is to show how to exploit the most advanced chart widget, i.e., the KPI Aggregated Chart. Contrarily to the charts presented in the preceding section, this one performs aggregations, which are grouped within a selected time period, e.g., every hour within a specified aggregation period. This widget has the following properties:

Headline: the widget name, displayed on it;

KPI name: the selected KPI names, whose values are used to form multiple plots; Label: the name of the plot;

Color: the color associated with the plot;

Unit: the KPI unit, e.g., seconds [s];

Date range: the selected, possibly historical, date and time range, e.g., a working shift;

Aggregation type: KPI values calculated within processing periods are aggregated within the date range using one of the following aggregations: sum, average, max, min (cf. Figure 4.2);

Stack KPI: defines the display form of the plot either stacked or separated.

Group by: the time spread between consecutive plots, e.g., one hour;

Combined y-axis: determines if either a single or separated y-axis is used for all plots;

Display as: separately determines the style of the plots, i.e., a bar, a line or filled triangles.

Figures 4.31 and 4.35 present the evolution of KPIs calculating the averaged mean durations of the KIS.BOX Red Button 1 operational LED, which can illuminate in

**Fig. 4.31** Sample KPI aggregated chart

**Fig. 4.32** Sample KPI aggregated chart with stacked bars

**Fig. 4.33** Sample KPI aggregated chart with a single y-axis

either green or red, grouped by one hour. In particular, Fig. 4.31 presents a bar plot with individual y-axes. Figure 4.32 portrays the same data but with stacked bars. Subsequently, the data with a single y-axis is given in Fig. 4.33. Finally, Figs. 4.34 and 4.35 present the remaining plot options.

**Fig. 4.34** Sample KPI aggregated chart with a line and bar plots

**Fig. 4.35** Sample KPI aggregated chart with a line and filled triangle plots

### **4.4 Control Charts: Comparison and Analysis**

As already mentioned in Sect. 4.2, SPC requires special measures to check if a given process is in the statistical control state. Thus, if a variable shaping process performance is described by the same distribution, then it is in the statistical control state.

The objective of this section is to introduce selected control charts, which are statistical tools that can be used for monitoring the process. As a result, they can provide suitable alerts pertaining to some disturbance acting on the process, leading to its out-of-control state. Finally, based one such results, one can find and minimize the disturbance cause.

**Fig. 4.36** Sample histogram

### *4.4.1 Histograms*

A histogram can be perceived as a practical tool, which can be used for approximating the distribution of numerical data concerning a given variable (see Fig. 4.36). Its design boils down to dividing the range of values into equal intervals and then determining how many values are in each intervals. Such non-overlapping consecutive intervals of a variable are called bins. The most common approach is to assume that such bins (intervals) have equal widths. KIS.MANGER does not support histograms directly. Thus, the objective of this section is to provide a way of designing them. This can be realized in the following steps:

Step 1: Find the minimum and maximum values of a variable *x*, i.e., *x*min and *x*max. Step 2: Select the number *k* and width w of histogram bins and then determine the bin ranges

$$\boldsymbol{x} \; ; \quad \boldsymbol{x}\_{r,i+1} \; > \; \boldsymbol{x} \ge \boldsymbol{x}\_{r,i} \; , \tag{4.6}$$

$$x\_{r,i} = x\_{\min} + (i - 1)w, \quad i = 1, \ldots, k. \tag{4.7}$$

Step 3: For each bin, implement a KPI counting the values which fall inside it:

### **Histogram bin calculation**

y=Count[Filter[x<xr1 && x>=xr]];

where xr1 stands for *xr*,*i*+<sup>1</sup> whilst xr signifies *xr*,*<sup>i</sup>* .

Step 3: Visualize the KPIs using the KPI Single Period Chart and select summation as the aggregation method (see Sect. 4.3.2).

# **•** > **Grouping histograms**

The above approach allows preparing histograms displaying data distribution inside a selected aggregation. However, by replacing the KPI Single Period Chart with the KPI Aggregated Chart (see Sect. 4.3.3), one can observe an evolution of the data distribution grouped by a specified time period, i.e., an hour or a day.

Figure 4.37 presents the histogram concerning red color durations of the KIS.BOX Red operational LED. A sample bin of this histogram is implemented as follows:

```
t=If[x==3,Duration[x]/1000,0];
y=Count[Filter[t>=61 && t<62]];
```
**Fig. 4.38** KPI aggregated chart-based evolving histogram

For the sake of presentational simplicity, the histogram has three bins only. An evolving histogram, which is grouped by hours, is presented in Fig. 4.38.

# **•** > **Duration versus the processing period**

Each KPI is periodically calculated within a given processing period, which can be set at 15, 30 or 60 min. Moreover, any KPI calculation is started at an full hour, e.g., 9.00 h. Let us reconsider the process of changing the KIS.BOX Red operational LED color every minute, i.e., after one minute the color is changed. Figure 4.30 clearly shows that the mean values of the durations corresponding to either the red or green color is not so close to 60 s. The reason behind such a situation is presented in Fig. 4.39. In this sample case, it can be observed that the KPI calculation ends at 10.00 h, and hence the last red color state duration (red corresponds to the numerical 5) is lower than 60 s. Such cases, as well as similar ones, which may happen at the beginning of the KPI calculation, have considerable influence on both the mean and the standard deviation. One of possible remedies is to eliminate improbable values using the Filter[] command and then calculate the mean and the standard deviation. One can also use different measures, e.g., the proportion between the sum of durations and the processing period time, which can be obtained with

```
s=Sum[If[x==5,Duration[x],0]]/Interval[];
```
Nevertheless, appropriate selection of the processing period is crucial for the correctness of the achieved results.

**Fig. 4.39** Duration versus processing period

### *4.4.2 Control Charts with Limits*

The objective of this section is to introduce crucial control charts:


There are, of course, plenty of different control charts. However, their presentation is beyond the scope of this book, and hence the reader is referred to [1] for a comprehensive explanation. Irrespective of the control chart type, they are used to visualize the evolution of some statistical measure against the so-called lower and upper control limits (LCLs and UCLs). Such a process is portrayed in Fig. 4.40. Apart from the above limit one can observe the center line, which is plotted at the level of the expected value of a given statistic. The only way to plot control charts in KIS.ME is to use the KPI Aggregated Chart, which can group the displayed data within a specified period, i.e., an hour or a day (cf. Sect. 4.3.3). Apart from the grouping 150 4 Implementing and Using Essential Statistical Process Control

period, it is suggested to select an appropriate KPI processing period, which should be lower than the grouping one. Thus, by selecting the average aggregation method in the KPI Aggregated Chart, the mean of a given statistics can be calculated. However, before proceeding to the practical implementation, let us provide calculation rules for all above-listed charts. Let us start with the *x*¯ chart, for which the central line ¯ *x*¯ can be estimated using the data from previous processing period or can be assumed to be known. Subsequently, the control limits can be implemented with the well known three standard deviations rule. For that purpose, is should be recalled that the standard deviation of the mean is related to the standard deviation of the process variable <sup>σ</sup> in the following way: <sup>σ</sup>*<sup>x</sup>*¯ <sup>=</sup> σ/√*n*, were *<sup>n</sup>* is the sample size within the processing period. Note that in usual conditions the σ*<sup>x</sup>*¯ has to be estimated, which can be realized using, e.g., one of the following formulas:

$$
\hat{\sigma}\_{\vec{x}} = \frac{1}{d\_1} \frac{\bar{\mathbf{s}}}{\sqrt{n}},
\tag{4.8}
$$

$$
\hat{\sigma}\_{\vec{x}} = \frac{1}{d\_2} \frac{\bar{r}}{\sqrt{n}},
\tag{4.9}
$$

where


Moreover, *d*<sup>1</sup> and *d*<sup>2</sup> are known constants, which are given in Table 4.4. This can, of course, be realized under the assumption that the process is in the control state for a set of *m* processing periods being considered. Thus, the *x*¯ chart can be summarized as follows:

Center line: ¯ *x*¯, UCL: ¯ *x*¯ + 3σˆ*x*¯, LCL: ¯ *x*¯ − 3σˆ*<sup>x</sup>*¯.

Using a similar line of reasoning, the *R* chart can be described:

Center line: *r*¯, UCL: *D*4*r*¯, LCL: *D*3*r*¯,

where *mr* stands for the mean of the range of *n* measurements of the process variable while *D*<sup>3</sup> and *D*<sup>4</sup> are known constants, which are given in Table 4.4. Note that the constants for larger *n* are available, e.g., in [1]. Let us proceed to the control charts for proportions, which are widely known as *p* charts. One of the popular examples of using the *p* chart is to visualize the ratio between the number of defective items and their total (cf. 4.3). Similarly as in the previous cases, a natural candidate for the central line is the mean *p*¯ proportion calculated over *m* processing periods. Let us also recall that the process used for the calculation of *p*¯ has to be in the statistical control state. Finally, the *p* chart can be summarized as follows:


**Table 4.4** Constants for control chart design

Center line: *p*¯, UCL: *p*¯ + 3σ*<sup>p</sup>* = ¯*p* + 3 *<sup>p</sup>*¯(1− ¯*p*) *<sup>n</sup>* , LCL: *p*¯ − 3σ*<sup>p</sup>* = ¯*p* − 3 *<sup>p</sup>*¯(1− ¯*p*) *<sup>n</sup>* .

Having all necessary ingredients, let us proceed to the implementation of the above control charts. We start with the *x*¯ chart. The variable being controlled is called *x*. Thus, the *x* chart can be implemented using the following steps:

Step 1: Determine ¯ *x*¯ (used as xbar), set up a new KPI and give it the name CLxbar, whilst its implementation is realized as follows:

CL=Max[xbar,xbar];

Step 2: Using either (4.8) or (4.9), determine σˆ*x*¯ (used as sigmax) and then set up two KPIs (UCLxbar and LCLxbar). Implement the LCL and UCL KPIs with the following programs:

```
UCL=Max[xbar+3*sigmax,xbar+3*sigmax];
```

```
LCL=Max[xbar-3*sigmax,xbar-3*sigmax];
```
Step 3: Set up a new KPI and give it the name mx, along with the implementation shaped by

meanx=Mean[x];

Step 4: Visualize CLxbar, LCLxbar, UCLxbar and mx with the KPI Aggregated Chart.

The implementation of the *R* chart can be realized in a similar way:

Step 1: Determine *r*¯ (used as br), and then set up a new KPI and give it the name CLR, whilst its implementation is realized as follows:

```
rbar=Max[br,br];
```
Step 2: Set up two KPIs (UCLR and LCLR). Implement the LCL and UCL KPIs with the following programs:

```
UCL=D4*Max[br,br];
```

```
LCL=D3*Max[br,br];
```
Step 3: Set up the new KPI and give it the name mr, along with the implementation shaped by

meanr=Max[x,x]-Min[x,x];

Step 4: Visualize CLR, LCLR, UCLR and mr with the KPI Aggregated Chart.

Assuming that the variable *p* can be calculated, e.g., in a similar way as (4.3), the implementation of the *p* chart boils down to the following:

Step 1: Determine *p*¯ (used as bp), set up a new KPI and give it the name CLp, whilst its implementation is realized as follows:

clp=Max[bp,bp];

Step 2: Determine σ*<sup>p</sup>* = *<sup>p</sup>*¯(1− ¯*p*) *<sup>n</sup>* (used as sigmap) and set up two KPIs (UCLp and LCLp). Implement the LCL and UCL KPIs with the following programs:

UCL=Max[bp+sigmap,bp+sigmap];

```
LCL=Max[bp-sigmap,bp-sigmap,0];
```
Step 3: Set up a new KPI and give it the name mp, along with the implementation shaped by

meanp=p;

Step 4: Visualize CLp, LCLp, UCLp and mp with the KPI Aggregated Chart.

The objective of this section was to provide recipes for calculating essential control charts with KIS.ME. Note that it is mandatory to use aggregation functions inside a KPI implementation. Thus, the *Max*[v*ariable*, v*ariable*] command is employed, which in the case of a scalar variable returns simply its value.

### **4.5 Practical Example Revisited**

Let us reconsider the data generation example introduced in Sect. 4.3. It pertains to alternately changing the KIS.BOX Red operational LED color from green to red. Each change is realize after one minute. The objective of this section is to provide dedicated implementations which can be directly used for this particular case.

Let us start with the implementation of the *x*¯ chart. Using the historical data from a set of processing periods, the mean ¯ *x*¯ = 61[*s*] and the mean range *r*¯ = 1.5[*s*]

were obtained. Thus, applying these values to (4.9) with *n* = 7 yields σ*<sup>x</sup>*¯ = 0.547[*s*]. Having these values, four KIPs were implemented:

CLxbar: xbar=61;

CL=Max[xbar,xbar];

### UCLxbar:

xbar=61; sigmax=0.547; UCL=Max[xbar+3\*sigmax,xbar+3\*sigmax];

### LCLxbar:

```
xbar=61; sigmax=0.547;
LCL=Max[xbar-3*sigmax,xbar-3*sigmax];
```
mx:

```
d=If[x==5,Duration[x],0];
y=Mean[Filter[d>60000]]/1000;
```
The values of these KPIs are calculated with a 15-min processing period, whilst the KPI Aggregated Chart is grouping and averaging their values every hour. The resulting *x*¯ chart is presented in Fig. 4.41. As can be observed, the mean values (blue line) are inside the control limits (red lines).

Let us proceed to the second chart, i.e., *R*. Using Table 4.4 for *n* = 7 gives *D*<sup>3</sup> = 0.0757 and *D*<sup>4</sup> = 1.9249. Having these values, four KIPs were implemented: CLR:

```
rbar=1.5;
CL=Max[rbar,rbar];
```
### UCLR:

rbar=1.5; CL=1.9249\*Max[rbar,rbar];

### LCLR:

```
rbar=1.5;
CL=0.0757*Max[rbar,rbar];
```
### mr:

```
d=If[x==5,Duration[x],0];
b=Filter[d>60000]/1000;
y=Max[b,b]-Min[b,b];
```
The values of these KPIs are calculated with a 15-min processing period, whilst the KPI Aggregated Chart is grouping and averaging their values every hour. The resulting *R* chart is presented in Fig. 4.42. As can be observed, the mean range fluctuates in a more intense way that the mean value. However, it is close to the mean range (green line) and within the control limits (red lines).

Let us process to the last chart, i.e., *p*. The proportion being considered is defined as the ratio between the sum of red color durations and that of both red and green color durations. In this case, with 15-min processing period, one should expect (on average) *n* = 15, which corresponds to changing the color every minute. As a result, σ*<sup>p</sup>* = 0.129 while *p*¯ = 0.5. Having these parameters, the implementation of the *p* chart boils down to programming the following KPIs:

CLp:

```
pbar=0.5;
CL=Max[pbar,pbar];
```
### UCLp:

pbar=0.5; sigmap=0.129; UCL=Max[pbar+3\*sigmap,pbar+3\*sigmap];

### LCLp:

```
pbar=0.5; sigmap=0.129;
LCL=Max[pbar-3*sigmap,pbar-3*sigmap];
```
### mp:

```
dred=If[x==5,Duration[x],0];
yred=Sum[Filter[dred>60000]];
dgreen=If[x==3,Duration[x],0];
ygreen=Sum[Filter[dgreen>60000]];
y=yred/(ygreen+yred);
```
The values of these KPIs are calculated with a 15-min processing period, whilst the KPI Aggregated Chart is grouping and averaging those every hour. The resulting *p* chart is presented in Fig. 4.43.

As can be observed, the mean values (blue line) are inside the control limits (red lines).

### **4.6 Training Exercises**

### **4.1** KIS.Device data generation revisited

Exercise requirements: The exercise requires access to one KIS.LIGHT.

1. Similarly as in Sect. 4.3, implement a set of rules changing the KIS.LIGHT operational LED color from red to green. Both periods should be equal to one minute.


**4.2** Your own way of calculating the mean and the standard deviation Exercise requirements: The exercise requires access to one KIS.LIGHT and completion of Exc. 4.1.


### **4.3** Median assembly time

Exercise requirements: The exercise requires access to one KIS.BOX.

1. Let us consider a single container that is fed to the assembly system. In particular, the container includes the following parts (digits):

$$C = \{1, 2, 3, 4, 5, 6, 7, 8, 9, 10\}. \tag{4.10}$$


### **4.4** Histograms

Exercise requirements: The exercise requires access to one KIS.LIGHT and completion of Exc. 4.1.


# **4.5** Control charts

Exercise requirements: The exercise requires access to one KIS.LIGHT and completion of Exc. 4.4.


# **4.6** Sharing KPIs

Exercise requirements: The exercise requires access to two KIS.LIGHTs (assigned to the same workspace) and completion of Exc. 4.5.


**4.7** CDP calculation: Idle working time

Exercise requirements: The exercise requires access to two KIS.BOXes (assigned to the same workspace).

1. Let us reconsider two workers performing identical tasks at a single assembly station. Both of them use KIS.BOX 1 to indicate two states:

Assembly in progress: Exemplified by the red color of operational LEDs, Idle: Exemplified by the green color of operational LEDs.

This means thatWorker 1 uses KIS.BOX 1 Button 1 whileWorker 2 utilizes KIS.BOX 1 Button 2.


### **4.7 Concluding Remarks**

The preliminary objective of this chapter was to introduce the concepts of calculating Datapoints and key performance indicators. Both of them can be used for processing data, but in a completely different way. Indeed, CDPs do so in a static way without taking data history into account. Contrarily, KPIs operate within specific processing periods. This means that the entire processing period data set is used for calculating the KPI value. For that purpose, aggregation functions can be used. The periodical values of KPIs can be further aggregated within an arbitrary period. This can be achieved with a set of various KPI chart widgets, which were carefully described. As a result, essential statistical analysis can be realized with the well-known measures of location and variability. Apart from these numerical values, it was also shown how to implement histograms. The final part of the chapter discussed the concept of control charts, which can be efficiently used to keep the process under statistical control. The chapter was concluded with a set of training exercises, which validate the knowledge gathered 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 5 Mastering System Monitoring and Control**

# **5.1 Defining the Performance Cost Function and Its Control**

The objective of this section is to define the performance cost function for the multiple point–single transporter system described in Sect. 3.3. The process starts with providing the availability of the transportation system. Subsequently, the performance cost function is defined over a set of routs. Thus, the entire performance is related with the sum of all cost functions divided by the total run time.

Let us start defining the work environment for the transporter operator:

Routes: The transporter operates within Workpsace 1 according to the routs presented in Fig. 5.3.

KIS.Device: The transporter operator uses KIS.BOX Transporter to signify the start and finish of a given transportation task.

Route assignment: The route assignment is realized by the KIS.MANAGER operator, which is setting KIS.Box Transporter Button 1 operational LED color to the one corresponding to the desired route.

# **•** > **System operators**

It is important to stress the fact that there are two operators within the system:

KIS.MANAGER operator: A human being assigning a transport task within a selected route and monitoring its realization.

Transporter operator: A human being physically realizing transportation tasks.


**Table 5.1** Set of possible routes

S: supermarket point, A: assembly point

Let us start with implementing a single route system, i.e., a blue one, and calculating transporter availability, which is defined as

$$\text{Availability} = \frac{\text{Run time}}{\text{Planned transformation time}},\tag{5.1}$$

where the run time is the amount of time spent on the transportation whilst the planned transportation time is obtained as follows:

$$\text{Planned transportation time} = \text{Shift length} - \text{breaks} \tag{5.2}$$

and signifies the time span in which the transporter can be operational. As an example, let us consider an eight-hour shift with a one-hour break, which gives

$$\text{Planned transportation time} = 480 - 60 = 420 \text{(min)}.\tag{5.3}$$

As can be observed in Table 5.1, the idle state corresponds to the time in which the transporter is not realizing any transportation. However, before proceeding to the implementation, let us define the transportation acknowledgement and realization procedure:



**Fig. 5.1** Sample rule for acknowledging Route 1

Note that, after Step 4 of the above procedure, the KIS.MANAGER operator can arrange a consecutive route by setting the KIS.BOX Transporter Button 1 operational LED color. The implementation of Steps 1–4 can be realized with five rules like the sample one for the blue route, which is given in Fig. 5.1. The rules for different routes can be implemented in a similar way, and hence they are omitted. Finally, the rule implementing Steps 6–7 is given in Fig. 5.2. It is also assumed that each route has an associated ideal route time. These times should be perceived as optimal performance goals on a given route (see Table 5.2). Having these data, one can define a performance cost function over the processing period:

$$J = \frac{1}{t\_r} \sum\_{i=1}^{n\_r} n\_i t\_i,\tag{5.4}$$

where *tr* is the run time within the processing period, *nr* = 5 is the number of routes (cf. Table 5.2), *ti* is the ideal transportation time of the *i*-th route while *ni* is the number of cycles on the *i*-th route. Thus, in the ideal case, this the above function should be equal to 1, which signifies perfect performance of the transporter.

Let us start with the KPI which can be used for the calculation of (5.1) with KIS.BOX Transporter. For that purpose, it is assumed that the planned transportation time is equal to 420 min (cf. 5.3):


**Fig. 5.2** Rule for accomplishing the transportation action


**Table 5.2** Routes and ideal route times

```
d=If[Not[x==2],Duration[x],0];
y=Sum[d]/60000/420;
```
where *x* is an alias name of button2ColorKpiDuration. Note that the KPI starts with determining all durations for a non-idle state, which is equivalent to the black color of the KIS.BOX Transporter Button 2 operational LED. To get a fair assessment of (5.1), the results provided by the above KPI should be aggregated within an eight-hour shift using the sum aggregation mechanism. This can be achieved with the KPI Aggregated Chart, which can group the results in a selected aggregation period, i.e., an hour or a day. An alternative approach is to calculate the availability within a given processing period, which can be realized as follows:

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

```
d=If[Not[x==2],Duration[x],0];
y=Sum[d]/Interval[];
```
Finally, an average availability can be calculated and visualized using KPI charts. Let us proceed to the implementation of (5.4), which should be started with introducing *nr* = 5 ideal transportation times (cf. Table 5.2):

t1=11; t2=4; t3=8; t4=3; t5=9;

The next step boils down to calculating the number of cycles on a given route *ni* , *i* = 1,..., *nr*. For that purpose let us recall the numerical counterparts of colors, which are given in Table 2.2. The implementation consists in calculating the number of KIS.BOX Transporter Button 2 operational LED color changes. This can be realized using led2ColorKpi with an associated alias variable *y*. As a result, the KPI code can be extended as follows:

t1=11; t2=4; t3=8; t4=3; t5=9;

```
n1=Sum[If[y==0,1,0]];
n2=Sum[If[y==1,1,0]];
n3=Sum[If[y==3,1,0]];
n4=Sum[If[y==4,1,0]];
n5=Sum[If[y==5,1,0]];
```
The last stage of the implementation is to calculate the run time *tr* and the current value of the performance function (5.4):

```
t1=11;
t2=4;
t3=8;
t4=3;
t5=9;
n1=Sum[If[y==0,1,0]];
n2=Sum[If[y==1,1,0]];
n3=Sum[If[y==3,1,0]];
n4=Sum[If[y==4,1,0]];
n5=Sum[If[y==5,1,0]];
d=If[Not[x==2],Duration[x],0];
tr=Sum[d]/60000;
J=1/tr*(t1*n1+t2*n2+t3*n3+t4*n4+t5*n5);
```
Let us consider a sample transportation request sequence, which is presented in Fig. 5.4. In particular, there are 15 transportation requests, which are ordered by the KIS.MANAGER operator using the KIS.BOX Transporter Button 1 operational LED color (cf. Sect. 2.6). Association of a given route with the assembly stations (A1–A3) is depicted as well. Using Table 5.2 and Fig. 5.4, one easily see that there are four cycles for route 1, three for route 2, three for route 3, three for route 4 and two for route 5. The objective of the remaining part of this section is to show evolution of the performance and availability of the implemented system, which was calculated using the KPI Aggregated Chart grouped by the hour. Moreover,


were also calculated for KPIs using a 60-min processing period. The obtained results are given in Table 5.3. As can be observed, 0.25 availability in the 5th hour is caused by the scheduled 45-min break. A similar effect is also visible in the 17 h due to a 15-min break. In most cases the performance function is close to its optimal level, which is equal to 1. Note that both availability and the performance cost function can be also interpreted in percents of their maximum respective rates. This can be easily achieved by multiplying them by 100.

**Fig. 5.4** Sample transportation request sequence


**Table 5.3** Availability and performance cost function

# **5.2 Monitoring the Product Rejection Rate**

The objective of this section is to show a sample implementation and analysis concerning two product rejection rate monitoring schemes. In both cases, it is assumed that the number of tested products is not constant within the processing period. Let us start with the first case, which is implemented using the following environment:

KIS.Device: The operator controlling the quality of produced items is equipped with KIS.BOX, which is operating within Workspace 1.

Item rejection/acceptance: If an item is acceptable, then the operator pushes KIS.BOX Button 1 while KIS.BOX Button 2 is pushed otherwise.

Let us start with implementing the KPIs for calculating


The implementation of the first KPI boils down to counting how many times both KIS.BOX buttons were pushed, which can be performed as follows:

dpass=Sum[If[pass,1,0]]; dfail=Sum[If[fail,1,0]]; total=dpass+dfail;

where pass and fail are aliases of button1Pressed and button2Pressed, respectively, while total stands for the total number of tested items. The implementation of the second KPI can be performed by suitably reducing the preceding one, which yields

```
dfail=Sum[If[fail,1,0]];
```
Table 5.4 presents the obtained results concerning 20 consecutive processing periods. Note that in all cases the processing period was equal to one hour. From these results it is evident that there are in total

$$N = \sum\_{i=1}^{20} n\_i = 953\tag{5.5}$$

items, among which

$$N\_r = \sum\_{i=1}^{20} n\_{r,i} = 76\tag{5.6}$$

are of unacceptable quality, and hence they are rejected. Thus, the ratio between the rejected and the total number of items can be obtained as follows:

$$
\bar{p} = \frac{N\_r}{N} = 0.0797.\tag{5.7}
$$

This means that the rejection rate is around 8%.

The objective of the subsequent deliberations is to develop the *p* chart (cf. Sect. 4.4.2), which can be used for statistical process control pertaining to the quality of the manufactured items. Let us recall that the *p* chart is designed according to the following principle:

Center line: *p*¯, Upper control limit (UCL):

$$\text{UCL} = \bar{p} + 3\sigma\_p = \bar{p} + 3\sqrt{\frac{\bar{p}(1-\bar{p})}{n}},\tag{5.8}$$

Lower control limit (LCL):

$$\text{LCL} = \bar{p} - 3\sigma\_p = \bar{p} + 3\sqrt{\frac{\bar{p}(1-\bar{p})}{n}}.\tag{5.9}$$


**Table 5.4** Quality test results

The main assumption concerning the above principle is that the total number of samples is constant in each (*i*-th) processing period. Unfortunately, due to manual testing, such an assumption is too restrictive. Thus, one way out of this problem is to assume an average number of items per processing period. Another solution is to calculate the LCL and the UCL for each processing period separately. The KPIs calculating the UCL and the LCL for a varying *n* and *p*¯ are as follows: UCL:

```
pbar=0.0797;
dpass=Sum[If[pass,1,0]];
dfail=Sum[If[fail,1,0]];
n=dpass+dfail;
sigmap=Power[pbar*(1-pbar)/n,0.5];
UCL=pabr+3*sigmap;
```
### LCL:

pbar=0.0797;


**Table 5.5** Quality test results

```
dpass=Sum[If[pass,1,0]];
dfail=Sum[If[fail,1,0]];
n=dpass+dfail;
sigmap=Power[pbar*(1-pbar)/n,0.5];
LCL=Max[pabr-3*sigmap,0];
```
Note that the LCL cannot be lower than zero, and hence there is a need for using the Max[] function. Finally, the center line (CL) is simply given by (5.7), which implies the KPI below:

pbar=0.0797; CL=Max[pbar,pbar];

while the monitored rejection rate *p* should be calculated using the following KPI:

```
dpass=Sum[If[pass,1,0]];
dfail=Sum[If[fail,1,0]];
n=dpass+dfail;
p=dfail/n;
```
To illustrate the UCL and LCL calculation according to (5.8)–(5.9), let us consider a sample processing period in which *n* = 30. Thus, Eqs. (5.8)–(5.9) yield UCL = 0.228 while LCL = max(−0.069, 0) = 0. Indeed, the rejection rate cannot be negative, and hence the LCL is set to zero.

Finally, using a set of four developed KPIs, one can design the *p* chart. Thus, according to the approach presented in Sect. 4.4.2, the above KPIs should be suitably associated with the KPI Aggregated Chart. The obtained results are presented in Fig. 5.5. For better illustration, the results are also gathered in Table 5.5. As can be observed, for the six processing periods being presented the ratio *p* oscillates around the center line and does not exceed the control limits.

Let us proceed to the second case, i.e., an automatic quality control system. It uses KIS.LIGHT as a communication means between an automatic quality control system and KIS.MANAGER. In particular, KIS.LIGHT Input 1 receives a false–true–false

**Fig. 5.5** Chart *p* for manual quality control

**Fig. 5.6** KIS.LIGHT Input 1

sequence when the controlled item satisfies the quality requirement. Otherwise, a false–true–false sequence is sent to KIS.LIGHT Input 2. Figure 5.6 presents a sample KIS.LIGHT Input 1 sequence forming the basis for calculating the number of items which pass the quality test. As in the manual case, let us start with implementing the KPIs for calculating


Let us proceed to the implementation of the first KPI, which can be realized using the RisingEdge command. It counts the number of false–true sequences, and hence the KPI boils down to

```
dpass=RisingEdge[pass];
dfail=RisingEdge[fail];
total=dpass+dfail;
```
where pass and fail are aliases of input1Status and input2Status while, respectively, total stands for the total number of tested items. As previously, the number of items which do not satisfy the quality test can be easily obtained with the KPI as follows:

```
dfail=RisingEdge[fail];
```
Thus, the rejection rate *p* can be found:

```
dpass=RisingEdge[pass];
dfail=RisingEdge[fail];
n=dpass+dfail;
p=dfail/n;
```
Similarly as in the manual case, after 20 processing periods, the rejection rate was calculated as *p*¯ = 0.098. This means that the center line can be found as in the manual case, but *p*¯ = 0.098 should be used instead. Finally, the control limits are determined using KPIs implemented with

UCL:

```
pbar=0.098;
dpass=RisingEdge[pass];
dfail=RisingEdge[fail];
n=dpass+dfail;
sigmap=Power[pbar*(1-pbar)/n,0.5];
UCL=pabr+3*sigmap;
```
### LCL:

```
pbar=0.098;
dpass=RisingEdge[pass];
dfail=RisingEdge[fail];
n=dpass+dfail;
sigmap=Power[pbar*(1-pbar)/n,0.5];
LCL=Max[pabr-3*sigmap,0];
```
Note that the presentation of the obtained results looks similar to that for the manual case, and hence it is omitted.

# **5.3 Demerit System Control**

The objective of the previous section was to describe a quality control system which can be used for binary decisions concerning product quality, which can be either defective or non-defective. In the quality control nomenclature [1, 2], a product is perceived as a nonconforming one if it has one or more defects. In the case of complex products, several different kinds of defects may occur. It is, of course, evident that they are not equally important and serious. Thus, a suitable classification method is needed, which can handle severity of defects and weight them in a reasonable way. A demerit system [1, 2] can be a good remedy for such a situation. Traditionally, in such a system, there are four classes of defects:

Class A defect—very serious, due to which the product


Class B defect—serious, due to which the product


Class C defect—moderately serious:


Class D defect—minor, due to which the product


Let *n <sup>A</sup>*, *nb*, *nc* and *nd* represent respectively the number of Class A, B, C, D defects within the sample of *n* products or units. The crucial assumption is that each class of defects is independent and obeys Poison distribution [1, 2]. The expected number of defects of each class is expressed by *n*μ*a*, *n*μ*b*, *n*μ*<sup>c</sup>* and *n*μ*<sup>d</sup>* , where μ*<sup>i</sup>* denote the expected defect per unit. Thus, the number of demerits is defined as

$$d = p\_a n\_a + p\_b n\_b + p\_c n\_c + p\_d n\_d,\tag{5.10}$$

where *pi* > 0 stand for the class weight. A commonly used approach for selecting these weight is *pa* = 100, *pb* = 50, *pc* = 10 and *pd* = 1. Note that these parameters can be problem-specific, and hence they can be modified. The control limits for (5.10) can be calculated as follows [1, 2]: Center line (CL):

$$\text{CL} = n\left(p\_a\mu\_a + p\_b\mu\_b + p\_c\mu\_c + p\_d\mu\_d\right),\tag{5.11}$$

Lower control limit (LCL):

$$\text{LCL} = CL - \text{3}\sigma\_d,\tag{5.12}$$

Upper control limit (UCL):

$$\text{UCL} = CL + \text{3}\sigma\_d,\tag{5.13}$$

where

$$
\sigma\_d = \sqrt{n\left(p\_a^2 \mu\_a + p\_b^2 \mu\_b + p\_c^2 \mu\_c + p\_d^2 \mu\_d\right)}.\tag{5.14}
$$

### **Calculation of sample demerit control limits**

Let us consider a sample demerit control system with the parameters given in Table 5.6, along with a sample of *n* = 200 units. Thus, according to (5.12),

$$\text{CL} = 200 \left( 100 \times 0.001 + 50 \times 0.0019 + 10 \times 0.0194 + 1 \times 0.01 \right) = 79.8,$$

while (5.14) yields

$$
\sigma\_d = \sqrt{200 \left(100^2 \times 0.001 + 50^2 \times 0.0019 + 10^2 \times 0.0194 + 1 \times 0.01\right)} = 57.793.
$$

Finally, the LCL (5.12) and the UCL (5.13) are

$$\begin{aligned} \text{LCL} &= 79.8 - 3 \times \text{57.793} = -93.579, \\ \text{UCL} &= 79.8 + 3 \times \text{57.793} = 253.179. \end{aligned}$$

Note that the negative LCL should be replaced with LCL = 0.



# **•** > **Significance of defect per unit**

The above example forms the basis for developing a chart for assuring the control of a given standard, which is shaped by μ*<sup>i</sup>* . This represents the expected quality level, which should take into account the economic balance between service requirements and production costs. As a result, two unappealing situations can be distinguished:


Under the above preliminaries, let us to proceed to the KIS.ME-based implementation. As in the previous section, it is possible to develop either a manual or an automatic demerit quality control system. However, the discussion is limited to the manual case, which employs three KIS.BOXes, i.e., KIS.BOX 1, KIS.BOX 2 and KIS.BOX 3. Once a product quality check is performed, an appropriate KIS.BOX button is pressed, which expresses the class of the product. Table 5.7 presents the association of KIS.BOXes and the defect classes. Note that most products are defect-free, and hence such a class has to be included as well. The resulting demerit system is presented in Fig. 5.7. The objective of the subsequent part of this section is to provide KPIs capable of calculating (5.10)–(5.13). However, KPIs can be implemented for a single KIS.Device exclusively. Thus, it is proposed to use appropriate rules, which will be employed to feed the information about the pressed button to a single KIS.BOX, i.e., KIS.BOX 3. Indeed, as can be observed in Table 5.7, KIS.BOX 3 Button 2 is not used, and hence it will be employed for the communication purpose. A complete set of communication rules is given in Table 5.8. Figure 5.8 presents an implementation of the first rule of Table 5.8. Having such a set of rules, it is possible to proceed to the KPI implementation. Let us start with supplementary KPIs, which can be used for calculating the number of products belonging to the classes presented in Table 5.7:

Class A:

nA=Sum[If[x==5,1,0]];

### Class B:

```
nB=Sum[If[x==4,1,0]];
```
### Class C:

nC=Sum[If[x==7,1,0]];


**Table 5.7** KIS.BOX-based demerit quality control

### Class D:

nD=Sum[If[x==0,1,0]];

Class defect-free:

nfree=Sum[If[y==3,1,0]];

where *x* and *y* are aliases of button1ColorKPI and button2ColorKPI Datapoints of KIS.BOX 3. For the implementation of (5.10)–(5.13), sample quality parameters are presented in Table 5.6. Finally, the center line and control limits of the demerit chart are given by the following KPIs:


### **Table 5.8** Demerit system rule base

**Fig. 5.8** Sample rule of the demerit control system

CL:

```
pa=100;
pb=50;
pc=10;
pd=1
muA=0.001;
muB=0.0019;
muC=0.0194;
muD=0.01;
nA=Sum[If[x==5,1,0]];
nB=Sum[If[x==4,1,0]];
nC=Sum[If[x==7,1,0]];
nD=Sum[If[x==0,1,0]];
nfree=Sum[If[y==3,1,0]];
n=nA+nB+nC+nD+nfree;
```

```
CL=n*(pa*muA+pb*muB+pc*muC+pd*muD);
```
### LCL:

```
pa=100;
pb=50;
pc=10;
pd=1
muA=0.001;
muB=0.0019;
muC=0.0194;
muD=0.01;
nA=Sum[If[x==5,1,0]];
nB=Sum[If[x==4,1,0]];
nC=Sum[If[x==7,1,0]];
nD=Sum[If[x==0,1,0]];
nfree=Sum[If[y==3,1,0]];
n=nA+nB+nC+nD+nfree;
CL=n*(pa*muA+pb*muB+pc*muC+pd*muD);
sd=n*(Power[pa,2]*muA+Power[pb,2]*muB+
   Power[pc,2]*muC+Power[pd,2]*muD);
sigmad=Power(sd,0.5);
LCL=Max[CL-3*sigmad,0];
```
### UCL:

```
pa=100;
pb=50;
pc=10;
pd=1
muA=0.001;
muB=0.0019;
muC=0.0194;
muD=0.01;
nA=Sum[If[x==5,1,0]];
nB=Sum[If[x==4,1,0]];
nC=Sum[If[x==7,1,0]];
nD=Sum[If[x==0,1,0]];
nfree=Sum[If[y==3,1,0]];
n=nA+nB+nC+nD+nfree;
CL=n*(pa*muA+pb*muB+pc*muC+pd*muD);
sd=n*(Power[pa,2]*muA+Power[pb,2]*muB+
Power[pc,2]*muC+Power[pd,2]*muD);
sigmad=Power(sd,0.5);
LCL=CL+3*sigmad;
```


**Table 5.9** KPI-based calculation of quality control results


4 72 95.7600 0 285.6863 5 111 79.4010 0 252.3452 6 53 74.2140 0 241.4139

**Table 5.10** Numerical data of the demerit chart

The developed demerit system was validated using a one-hour processing period. First, the supplementary KPIs were employed to determine the number of products belonging to the classes defined in Table 5.7. The obtained results are presented in Table 5.9. Let us proceed to the results concerning the demerit chart, which are shaped by the monitored demerit number *d*. It should evolve around the center line (CL) and should be bounded by the control limits. The obtained results are presented in Table 5.10 and visualized using the KPI Aggregated Chart, which is portrayed in Fig. 5.9. The results clearly indicate that the monitored process is in the state of control.

### **5.4 Overall Equipment Effectiveness**

The main objective of this section is to show how to use KIS.ME for calculating the performance of given equipment. The discussion starts with recalling the concept of overall equipment effectiveness (OEE) [3, 4], which can be perceived as a key measurement tool for assessing both productivity and efficiency. As indicated in [4],

**Fig. 5.9** Demerit chart for manual quality control

OEE is a hierarchy of measures that exhibit how efficiently a manufacturing operation is performed. This indicator is stated in a very general form, and hence it makes it possible to perform an efficient comparison between manufacturing units in different departments, organizations, etc. The core features of OEE are as follows [3, 4]:


As a result, OEE can be used for


The crucial components of OEE are the following: availability:

$$\mathbf{A} = \frac{t\_P - t\_S}{t\_P} = \frac{t\_R}{t\_P},\tag{5.15}$$

where *tP* is a planned production time, *tS* stands for the unplanned stop or downtime, while *tR* signifies the run time.

### 5.4 Overall Equipment Effectiveness 179

Performance:

$$\mathbf{P} = \frac{t\_i n\_p}{t\_P - t\_S} = \frac{t\_i n\_p}{t\_R},\tag{5.16}$$

where *ti* is the ideal single part manufacturing time and *np* stands for the total number of manufactured parts, i.e., both defective and defect-free ones. Quality:

$$\mathbf{Q} = \frac{n\_p - n\_d}{n\_p} = \frac{n\_g}{n\_p},\tag{5.17}$$

where *nd* and *ng* stand for the number of defective and defect-free parts, respectively. Finally, the OEE indicator is simply given by

$$\mathbf{OEE} = \mathbf{A} \times \mathbf{P} \times \mathbf{Q}.\tag{5.18}$$

The objective of the remaining part of this section is to show how to employ KIS.ME for calculating OEE. It can also be expressed in percents, which can be easily attained by multiplying (5.15)–(5.17) by 100. Note that a world class value of OEE should be at the level of 85% or higher. Let us also note that the calculation of planned production time obeys

$$\mathbf{t}\_P = \mathbf{t}\_A - \mathbf{t}\_B,\tag{5.19}$$

where *tA* and *tB* stand for the available and planned break times.

### **Sample OEE calculation**

Let us consider an example equipment, which is characterized by the parameters given in Table 5.11. According to (5.19), the planned production time *tP* = *tA* <sup>−</sup> *tB* <sup>=</sup> 390[min]. This implies that A <sup>=</sup> *tP*−*tS tP* <sup>=</sup> <sup>350</sup> <sup>390</sup> = 0.897 or 89.7%. Subsequently, the performance can be calculated with (5.16), which is equal to P = 0.952 or 95.2%. The quality is obtained with (5.17), which is equal to Q = 0.99 or 99%, equivalently. Finally, OEE can be calculated according to (5.18), which gives OEE = 0.845 or 84.5%.



**Fig. 5.10** KIS.ME-based OEE data gathering scheme

Before proceeding to the OEE implementation, a KIS.ME infrastructure has to be defined. In particular, it should allow identification and measurement of


The employed infrastructure is portrayed in Fig. 5.10. As can be observed, the system has automatic quality control, which is connected with KIS.BOX digital inputs. The quality control system is actually the same as the one presented in Sect. 5.2, but KIS.BOX is used instead of KIS.LIGHT. Indeed, it employs KIS.BOX as a communication means between an automatic quality control system and KIS.MANAGER. In particular, KIS.BOX Input 1 receives a false–true–false sequence when the controlled item satisfies the quality requirement. Otherwise, a false–true–false sequence is sent to KIS.BOX Input 2. A sample sequence is presented in Fig. 5.6. Subsequently, note that the KIS.BOX Button 2 operational LED color is initially set to green using the KIS.BOX digital twin (cf. Sect. 2.6). This is a normal operation of the equipment.

Let us proceed to the identification of the cause of downtime. First, it is assumed that the equipment operator makes a decision about the current downtime state of the equipment, which may exhibit one of the modes given in Table 5.12. In particular, the state-space model concept (cf. Sect. 2.10) is utilized to change the color of the KIS.BOX Button 1 operational LED according to Table 5.12. This operation depends on the trigger which is related to pressing KIB.BOX Button 1. Once an appropriate color is selected, the equipment operator acknowledges the current state by pressing KIS.BOX Button 2. As a result, its operational LED color is changed into that of the KIS.BOX Button 1 operational LED. Thus, any alteration of the equipment state should be realized in the same way. Note also that one can freely modify or extend the states proposed in Table 5.12.

Let us proceed to the KPI implementation. First, availability has to be calculated according to (5.15). For that purpose it is necessary to assume that the planned production time *tP* is given. Thus, let *tA* = 420(min) and *tp* = 390(min). As a result, the KPI calculating availability within a selected processing period is given by


**Table 5.12** Run and downtime states

```
tp=390;
tr=Sum[If[x == 3,Duration[x],0]]/60000;
A=tr/tp;
```
where *x* is an alias of the button1ColorKpiDuration Datapoint. Finally, to assess the quality, the KPI calculation results should be aggregated with KPI charts using the SUM aggregation method (see, e.g., Sect. 4.3.2) and the *tA* aggregation period. Using a similar way of implementation, one can formulate KPIs calculating the sums of downtimes:

Equipment breakdown:dred=Sum[If[x == 5,Duration[x],0]]/60000; Setup and adjustment:dblue=Sum[If[x == 0,Duration[x],0]]/60000; Minor breakdowns:dyellow=Sum[If[x == 7,Duration[x],0]]/60000;

as well as the occurrence number of such states:

Equipment breakdown: nred=Sum[If[x == 5,1,0]]; Setup and adjustment: nblue=Sum[If[x == 0,1,0]]; Minor breakdowns: nyellow=Sum[If[x == 7,1,0]];

Let us proceed to performance calculation (5.16). The KPI calculating local performance within the *j*-th processing period, i.e.,

$$P\_j = \frac{t\_i n\_{p,j}}{t\_{\mathcal{R},j}},\tag{5.20}$$

can be derived using (with *ti* = 1[min])

```
ti=1;
ng=RisingEdge[y];
nd=RisingEdge[z];
np=nd+ng;
tr=Sum[If[x == 3,Duration[x],0]]/60000;
Pj=ti*np/tr;
```
where *x*, *y* and z are aliases of button1ColorKpiDuration, input1Status and input2Status, respectively. Having *k* processing periods, one can aggregate the results of the above KPI. Unfortunately, there is no aggregation which makes it possible to determine total performance (5.16). A good remedy to such a problem is to define two separated KPIs:

Ideal manufacturing time of the *n <sup>p</sup>* parts:

```
ti=1;
ng=RisingEdge[y];
nd=RisingEdge[z];
np=nd+ng;
tideal=ti*np;
```
Run time *tR*:

tr=Sum[If[x == 3,Duration[x],0]]/60000;

and observe their relation using the KPI Pie Chart with the SUM aggregation method. Similar issues are encountered while calculating quality with (5.17). Indeed, local quality within the *j*-th processing period, i.e.,

$$\mathcal{Q}\_j = \frac{n\_{\mathbf{g},j}}{n\_{P,j}},\tag{5.21}$$

can be calculated with

```
ng=RisingEdge[y];
nd=RisingEdge[z];
np=nd+ng;
Qj=ng/np;
```
Similarly, as the global quality (5.17) cannot be directly calculated, a good remedy is to define two separate KPIs:

```
Number of defect-free parts ng: ng=RisingEdge[y];
Number of parts n p:
```

```
ng=RisingEdge[y];
nd=RisingEdge[z];
np=nd+ng;
```
and observe their relation using the KPI Pie Chart with the SUM aggregation method. Finally, the determination of OEE can be realized directly. Indeed, by substituting (5.15)–(5.17) to (5.18), one can observe that

$$\text{OEE} = \frac{t\_i n\_g}{t\_p},\tag{5.22}$$

which can be directly obtained with the following KPI:

```
ti=1;
tp=390;
ng=RisingEdge[y];
OEE=ti*ng/tp;
```
Finally, OEE can be visualized and aggregated (with the SUM method) using a selected KPI chart.

## **5.5 Training Exercises**

**5.1** Small transportation system

Exercise requirements: The exercise requires access to one KIS.BOX.

1. Let us consider two transportation routes:

Route red:

$$R\_r = \{1, 2, 3, 4, 5, 6, 7, 8, 9, 10\},\tag{5.23}$$

Route green:

$$R\_{\mathfrak{g}} = \{A, B, C, D, E, F, G, H, I, J\}. \tag{5.24}$$


Step 0: set *i* = 1; Step 1: write the *i*-th name of the transportation point on a paper sheet (e.g., A); Step 2: perform virtual transportation by waiting a suitable period of time; Step 3: set *i* = *i* + 1. If *i* > 10, then STOP, else go to Step 1.


$$J = \frac{1}{t\_p} \left( n\_r t\_r + n\_g t\_g \right),\tag{5.25}$$

where *tp* is the processing period. (Hint: Use Interval[] command with transforming its value from milliseconds to minutes);

9. Implement the KPI calculating the availability of the transportation system within a processing period:

$$\mathbf{A} = \frac{t\_r}{t\_p},\tag{5.26}$$

where *tr* stands for the run time, i.e., the duration sum for which the KIS.BOX Button 2 operational LED is not black.


$$R\_{\mathfrak{g}}, R\_{\mathfrak{g}}, R\_r, R\_r, R\_r, R\_{\mathfrak{g}}, R\_r, R\_r, R\_{\mathfrak{g}}, R\_{\mathfrak{g}}\tag{5.27}$$

and realize each transportation task according to Step 3.

12. What can you say about the obtained values of (5.25) and (5.26)?

### **5.2** Manual quality control

Exercise requirements: The exercise requires access to one KIS.BOX.


Exercise requirements: The exercise requires access to one KIS.LIGHT.



**Table 5.13** Run and downtime states of the virtual production system


### **5.4** Overall equipment efficiency of the virtual production system

Exercise requirements: The exercise requires access to one KIS.LIGHT and completion of Exc. 5.3.


### **5.6 Concluding Remarks**

The main objective of this chapter was to utilize the methods and tools described in the preceding parts for designing a practical set of process monitoring and control schemes. All of them are relatively easy to implement and enable intuitive control of the monitored system. The chapter opened with a transportation system that operates on a set of routes. First, it was shown how to communicate the desired transportation actions between KIS.MANAGER and transporter operators. The second objective was to develop suitable measures for assessing the performance of the transportation system. For that purpose, the concept of an ideal rout time was introduced, which forms the basis for the performance cost function. Thus, with appropriate control of the transportation system, one can optimize this function. Additionally, the proposed function is very easy to interpret as its value for the optimal control is equal to 1, which can be perceived as 100% performance. The proposed approach also allows determining the availability of the transportation system, which can be used as an additional measure for performance improvements. The second process which was introduced in this chapter pertains to a quality control system, which can be either manual or automatic. Irrespective of the selected method, it was shown how to determine a set of suitable statistical measures along with the *p* chart. Such a quality control system is capable of making binary quality decisions about the product being controlled. Thus, to overcome this restriction, a demerit quality control system was introduced. It allows indicating various defect classes, and hence, instead of controlling the rejecting rate, it is proposed to monitor the so-called demerit number. For that purpose, the demerit chart was developed, which provides effective measures for controlling the quality of manufactured products. The last process monitoring strategy aimed at calculating and visualizing overall equipment efficiency, which is widely perceived as a key measurement tool for assessing both productivity and efficiency. In particular, it was shown how to efficiently observe availability, performance, and quality of a given manufacturing equipment. Finally, the chapter was summarized with a set of training exercises, which can be considered the master level test concerning KIS.ME-oriented skills.

# **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 6 Towards Advanced Applications**

# **6.1 Modelling Users and Their Interactions**

Unlike automated assembly systems, human operated manufacturing and assembly ones encounter various unappealing effects associated with human behaviour uncertainty. The objective of this section is to provide two examples pertaining to modeling human users and their interactions [1] with the fuzzy logic approach [2–4]. The fuzzy logic paradigm seems to be a natural modelling tool for such a task as its origins stem from human inference behaviour. Indeed, fuzzy logic has been used for modelling human reliability in the process industry [5–7] as well as human error analysis [8]. There are also works utilising fuzzy logic for human factor modelling in preventive maintenance actions [9] and estimating a context-specific human error rate [10].

### *6.1.1 Assembly Process*

Let us proceed to the first case, i.e., modelling human behaviour in the assembly process with fuzzy logic. For that purpose a pair of KIS.Devices is employed, i.e., KIS.BOX and KIS.LIGHT. For the purpose of illustration, let us consider a sample manual assembly process, which involves two phases [11] (see Fig. 6.1):


A general overview of the manual assembly station with the KIS.ME infrastructure is presented in Fig. 6.2. Let us recall that KIS.LIGHT possesses two digital inputs, which can be connected with two photoelectric sensors (see Sect. 3.1 for an illustrative example). Let us imagine that there are to transportation means, e.g., conveyor belts, which provide battery cells and cell controllers. Table 6.1 presents all possible situations related to this. Using KIS.MANAGER Rule engine (cf. Sect. 2.10), one can implement rules governing such behaviour of the KIS.LIGHT operational LED

**Fig. 6.1** Manual battery assembly

**Fig. 6.2** General overview of the manual assembly station with the KIS.ME infrastructure

depending on its digital inputs. As a result, if its color is red, then there are no components. If one of them is available, then the color is green. Finally, if both of them are available, then the color is blue and it alarms the worker that the assembly process can be started. Thus, a necessary condition for mounting the battery is that all components be available. Let us proceed to describe all possible working states, which are listed in Table 6.2. Similarly as in the KIS.LIGHT case, the transition between States 1–5 can be realized using Rule engine. Moreover, as a transition trigger, one can use a KIS.BOX Button 1 pressing action. This action ends the deployment of KIS.Devices to the above assembly station. Note that the structure presented in Fig. 6.2 is very general, and hence it can be tailored to a wide range of assembly tasks. Having the KIS.Device infrastructure, it is possible to monitor the performance of the human operated assembly system using visualization, SPC and OEE strategies, described in


**Table 6.1** KIS.LIGHT states

**Table 6.2** KIS.BOX states


Chaps. 4–5. This is, however, beyond the scope of this section. Indeed, the problem is to obtain a time-driven model of assembly operations, which will include information about human experience and performance related with the working time within the shift.

For that purpose, let us recall that the time evolution of all states can be easily measured within KIS.MANAGER using the Data trend chart widget (cf. Sect. 2.7), which allows real-time analysis of operator performance. The historical data can easily be saved to a CSV file, and hence it can be further processed in external software. Thus, the objective is to model human behaviour taking into account the following issues:


Thus, the crucial problem is to model the realization times of States 2 and 4 in Table 6.2. For that purpose, two general models are introduced:

$$c\_m = f\_m(n\_c, C\_c, m\_p, e\_x, t\_x),\tag{6.1}$$

$$c\_l = f\_l(n\_c, e\_x, t\_x),\tag{6.2}$$

where



**Table 6.3** Fuzzy premise variables


Having all necessary ingredients, it is possible to provide the structure of (6.1)– (6.2). For that purpose, it is proposed to use the Takagi–Sugeno (TS) fuzzy logic approach [12, 13]. TS models are widely used for various modelling tasks (see [13] and the references therein). Their attractiveness is especially important in the case considered since there are two linguistic variables, presented in Table 6.3. They can be directly obtained, and hence they can form the so-called premise variables [13] for the TS counterparts of (6.1)–(6.2). According to the above KIS.Device infrastructure, each worker is associated with KIS.BOX, and hence its experience *ex* can be directly obtained. As can be observed in Table 6.3, fuzzy logic allows smooth transitions between the groups. Indeed, with a degree of membership [13], a worker can be in one group. Similarly, the worker can be in a different group with another membership degree. The same feature pertains to the working time within the shift.

Under these preliminaries, the TS model of (6.1) is as follows:

$$\begin{aligned} \text{IF } t\_s \in \mathbb{T}\_{s,j} \text{ and } e\_x \in \mathbb{E}\_{x,i}, \text{ THEN} \\ c\_m = p\_{1,m}^{i,j} m\_c + p\_{2,m}^{i,j} m\_p + p\_{3,m}^{i,j} C\_c, \quad i,j = 1,\ldots,3, \end{aligned} \tag{6.3}$$

where *p*· · are the model parameters which have to be determined while <sup>E</sup>*<sup>x</sup>*,*<sup>j</sup>* and T*<sup>s</sup>*,*<sup>i</sup>* are fuzzy sets associated with Table 6.3. Each set can be shaped with three membership functions, which can be, e.g., of the Gaussian form:

$$\mathcal{G}^{i}(e\_{x}, m\_{x,i}, s\_{x,i}) = \frac{1}{\sqrt{2\pi s\_{x,i}}} e^{-\frac{(e\_{x} - m\_{x,i})^2}{2s\_{x,i}}}, i = 1, \ldots, 3,\tag{6.4}$$

$$\mathcal{G}^{j}(t\_{\rm s}, m\_{s,j}, \mathbf{s}\_{s,j}) = \frac{1}{\sqrt{2\pi \mathbf{s}\_{s,j}}} e^{-\frac{(t\_{\rm s} - m\_{s,j})^2}{2\mathbf{s}\_{s,j}}}, j = 1, \ldots, \mathfrak{Z},\tag{6.5}$$

where *mx* , *ms* are the centres of Gaussian functions while *sx* and *ss* define their dispersion. Having the membership functions, let us define the normalized rule firing strength:

### 6.1 Modelling Users and Their Interactions 193

$$\mu\_{i,j} = \frac{\mathcal{G}^i(e\_x, m\_{x,i}, s\_{x,i})\mathcal{G}^j(t\_s, m\_{s,j}, s\_{s,j})}{\mathcal{G}\_t}, \quad i, j = 1, \ldots, 3,\tag{6.6}$$

where

$$\mathcal{G}\_l = \sum\_{i=1}^{3} \sum\_{j=1}^{3} \mathcal{G}^i(e\_x, m\_{x,i}, s\_{x,i}) \mathcal{G}^j(t\_s, m\_{s,j}, s\_{s,j}).\tag{6.7}$$

Finally, the model (6.3) can be transformed into

$$c\_m = \sum\_{i=1}^{\mathfrak{d}} \sum\_{j=1}^{\mathfrak{d}} \mu\_{i,j} \left( p\_{1,m}^{i,j} n\_c + p\_{2,m}^{i,j} m\_p + p\_{3,m}^{i,j} \mathcal{C}\_c \right). \tag{6.8}$$

As a result, the TS model can be expressed in the following form:

$$c\_m = \sum\_{i=1}^{3} \sum\_{j=1}^{3} \mu\_{i,j} r\_m^T p\_m^{i,j},\tag{6.9}$$

where *rm* = [*nc*, *mp*,*Cc*] *<sup>T</sup>* and *p i*,*j <sup>m</sup>* = [*p i*,*j* <sup>1</sup>,*<sup>m</sup>*, *p i*,*j* <sup>2</sup>,*<sup>m</sup>*, *p i*,*j* 3,*m*] *<sup>T</sup>* are the regressor and parameter vectors, respectively. The final step boils down transforming (6.9) to the regressor form:

$$c\_m = r\_m^T p\_m,\tag{6.10}$$

where

• *rm* = [μ<sup>1</sup>,1*r <sup>T</sup> <sup>m</sup>* , μ<sup>1</sup>,2*r <sup>T</sup> <sup>m</sup>* ,...,μ<sup>2</sup>,2*r <sup>T</sup> m* ] *T* , • *pm* = [(*p*1,<sup>1</sup> *<sup>m</sup>* )*<sup>T</sup>* , (*p*1,<sup>2</sup> *<sup>m</sup>* )*<sup>T</sup>* ,...,(*p*3,<sup>3</sup> *<sup>m</sup>* )*<sup>T</sup>* ] *T* .

Using a similar line of reasoning, the TS model (6.2) can be derived:

$$c\_l = r\_l^T p\_l,\tag{6.11}$$

where

$$\begin{array}{l} \bullet \ r\_l = [\mu\_{1,1} r\_l^T, \mu\_{1,2} r\_l^{1,2})^T, \dots, \mu\_{3,3} r\_l^T \mathbf{l}^T, \\\bullet \ p\_l = [(p\_l^{1,1})^T, (p\_l^{1,2})^T, \dots, (p\_l^{3,3})^T \mathbf{l}^T. \end{array}$$

with *rl* = *nc*.

One important feature related to the models (6.10)–(6.11) is that they are linear with respect to *pm* and *pl* . This appealing feature makes it possible to use the celebrated least-square algorithm [12, 13] for estimating these parameters.

The objective of the remaining part of this section is to provide a concise outline of the general algorithm for designing (6.10)–(6.11):

KIS.BOX assignment: assign workers with different experience (see Table 6.3) to different KIS.BOXes.

Production plan: determine a strategy for gathering representative and possibly large data sets concerning workers with different experience that operate according to the battery production plan.

Data gathering: perform the data gathering procedure:


Model design: use the recursive least square algorithm to determine (6.10)–(6.11).

# **•** > **Highlights**

The model (6.10)–(6.11) may have several prospective applications. Having a manufacturing plan corresponding to the required number of batteries as well as group of workers performing within the shifts, one can use (6.10)–(6.11) to


### **6.2 Transportation Process**

The objective of this section is to present an approach for modelling forklift operator performance within a warehouse, which has been recently developed by the authors [1, 14]. The proposed framework is designed for a fleet of cooperating forklifts working within a high storage warehouse. A sample part of such a system is presented in Figs. 6.3–6.4. As can be observed, KIS.Devices are used as communication tools. Thus, each forklift is equipped with KIS.BOX while KIS.LIGHTs are installed on each transfer station. The transfer station is defined as a place for storing an item (product, materials, etc.), which has been delivered to it via different transportation means, e.g., automated guided vehicles [15, 16].

Let us start with stating that an item associated with the *k*-th transportation event is identified by

$$\mathbb{L}(k) = \{ \mathbf{s}(k), t(k), d(k), m(k), q(k) \}, \tag{6.12}$$

**Fig. 6.3** Sample part of the warehouse shopfloor (top view)

**Fig. 6.4** Sample part of the warehouse shopfloor (side view)

where


The objective of the remaining part of this chapter is to provide a concise procedure for designing a forklift driver performance model using KIS.ME. Let P denote the set of all require transportation events, which is defined as follows:

$$\mathbb{P} = \{ \mathbb{L}(0), \mathbb{L}(1), \dots, \mathbb{L}(n\_E) \}, \tag{6.13}$$

where *nE* signifies the number of transportation events.

# **•** > **Realization constraints**

For the sake of simplicity, the following is assumed:


Thus, transportation from the transfer stations to the storage places is realized as follows:

Step 0: Set *k* = 1;



**Table 6.4** Aisle assignment to the transfer station


Note that if the condition of Step 3 is not satisfied, then KIS.MANGER Rule engine waits until it is feasible. Moreover, the black and red colors are used for the task identification purpose, and hence they cannot be used for the identification of the transfer stations. Finally, the objective of this data acquisition is to collect measurements associated with


As in the previous section, the data concerning the performance of the above system can be gathered using the Data trend chart. These data include a timestamp which clearly identifies the working time within the shift. Subsequently, the obtained data can be merged with the detailed description of all items (6.13) as well as operator experience, which is associated with the KIS.BOX being used. As a result, *k* = 0,..., *nE* Datapoints are obtained, which can be used for designing a model of the forklift operator's performance:

$$L\_f(k) = \{t(k), s(k), d(k), m(k), q(k), f(k)^m, b(k)^m, e\_x(k), t\_s(k)\},\qquad(6.14)$$

where *ex* (*k*) and *ts*(*k*) are respectively experience and working time within the shift of the forklift operator transporting the *k*-th item.

Similarly as in the preceding section, two TS models will be developed. The fuzzy model is divided into two sub-models:

$$f = f\_f(d, m, q, e\_x, t\_s),\tag{6.15}$$

$$b = f\_b(d, m, q, e\_x, t\_s). \tag{6.16}$$

Finally, *f <sup>f</sup>* (·) and *fb*(·) signify a given model structure used for calculating either *f* (*k*) or *b*(*k*) for the *k*-th item. Owing to safety purposes, the maximum velocity limit can be imposed, e.g., at the level of *v <sup>f</sup>* = 5 km/h = 1.39 m/s:

$$f \geq \frac{1}{\nu\_f}d,\tag{6.17}$$

which is implied by the fact that *distance* = *time* × *velocit y*. The same constraint is imposed on *<sup>b</sup>*, i.e., *<sup>f</sup>* <sup>≥</sup> <sup>1</sup> *v f d*. It is also evident that the mass *m* and volume *q* of an item have a direct impact on *f* .

Similarly as in the preceding section, two fuzzy premise variables are introduced, which are detailed in Table 6.3. Under these preliminaries, the TS model of (6.15) is

$$\begin{aligned} \text{IF } t\_s \in \mathbb{T}\_{s,j} \text{ and } e\_x \in \mathbb{E}\_{x,i}, \text{ THEN} \\ f = p\_{1,f}^{i,j}d + p\_{2,f}^{i,j}m + p\_{3,f}^{i,j}q, \quad i,j = 1,\ldots,3, \end{aligned} \tag{6.18}$$

while (6.16) obeys

$$\begin{aligned} \text{IF } t\_t \in \mathbb{T}\_{s,j} \text{ and } e\_x \in \mathbb{E}\_{x,i}, \text{ THEN} \\ b = p\_{1,b}^{i,j}d + p\_{2,b}^{i,j}m + p\_{3,b}^{i,j}q, \quad i,j = 1,\ldots,3, \end{aligned} \tag{6.19}$$

where *p*· · are the model parameters which have to be determined while <sup>E</sup>*x*,*<sup>j</sup>* and T*s*,*<sup>i</sup>* are fuzzy sets associated with Table 6.3. Using the rule firing strength (6.6), the models (6.18)–(6.19) can be written as follows:

$$f = \sum\_{i=1}^{3} \sum\_{j=1}^{3} \mu\_{i,j} \left( p\_{1,f}^{i,j} d + p\_{2,f}^{i,j} m + p\_{3,f}^{i,j} q \right), \tag{6.20}$$

$$b = \sum\_{i=1}^{3} \sum\_{j=1}^{3} \mu\_{i,j} \left( p\_{1,b}^{i,j} d + p\_{2,b}^{i,j} m + p\_{3,b}^{i,j} q \right). \tag{6.21}$$

The final set boils down to transforming (6.20)–(6.21) to the regressor form:

$$f = r\_f^\mathcal{T} p\_f,\tag{6.22}$$

where

• *rf* = [μ<sup>1</sup>,<sup>1</sup>*r <sup>T</sup> <sup>f</sup>* , μ<sup>1</sup>,<sup>2</sup>*r <sup>T</sup> <sup>f</sup>* ,...,μ<sup>2</sup>,<sup>2</sup>*r <sup>T</sup> f* ] *T* , • *p <sup>f</sup>* = [(*p* 1,1 *<sup>f</sup>* )*<sup>T</sup>* , (*p* 1,2 *<sup>f</sup>* )*<sup>T</sup>* ,...,(*p*<sup>3</sup>,<sup>3</sup> *<sup>m</sup>* )*<sup>T</sup>* ] *T* ,

and *rf* = [*d*, *m*, *q*] *<sup>T</sup>* . The model (6.21) can be formulated in a similar way:

$$b = r\_f^{\mathcal{T}} p\_b,\tag{6.23}$$

where

• *rf* = [μ<sup>1</sup>,<sup>1</sup>*r <sup>T</sup> <sup>f</sup>* , μ<sup>1</sup>,<sup>2</sup>*r <sup>T</sup> <sup>f</sup>* ,...,μ<sup>2</sup>,<sup>2</sup>*r <sup>T</sup> f* ] *T* , • *pb* = [(*p* 1,1 *<sup>b</sup>* )*<sup>T</sup>* , (*p* 1,2 *<sup>b</sup>* )*<sup>T</sup>* ,...,(*p* 3,3 *<sup>b</sup>* )*<sup>T</sup>* ] *T* .

The objective of the remaining part of this section is to provide a concise outline of the general algorithm for designing (6.22)–(6.23):

KIS.BOX assignment: Assign forklifts operators with different experience (see Table 6.3) to different KIS.BOXes.

Transportation plan: Obtain the transportation plan (6.13) consisting of *nE* transportation events.

Data gathering: Perform the data gathering procedure according to the above 8-step strategy:


Model design: Use the recursive least square algorithm to determine (6.22)–(6.23).

# **•** > **Highlights**

The model (6.22)–(6.23) may have several crucial applications. Having a transportation plan (6.13), one can use (6.22)–(6.23) to


# **6.3 Integrating Workers Within a Semi-automatic Assembly System**

A sample general semi-automatic assembly scheme is presented in Fig. 6.2. Indeed, it may be surrounded by conveyor belts or other transportation means that provide suitable components for the assembly process. Let us begin with recalling the fact that the worker can start mounting the next battery iff the previous one is completed. Let as also recall (see Sect. 6.1.1) that the completion time is the sum of


Let us define the following variables (cf. Table 6.2 and Fig. 6.2):


This nomenclature allows formulating a simple formal description pertaining to the evolution of the start time of mounting consecutive batteries:

$$\ln(k+1) = \max\left(\mathbf{x}(k) + c\_m(k) + c\_l(k), \mu\_m(k+1), \mu\_c(k+1)\right),\tag{6.24}$$

where *cm*(*k*), *cl*(*k*) are respectively *cm* and *cl* for the *k*-th battery. This means that the maximum of the times included in (6.24), i.e., in max(·), determines the start time of mounting the *k* + 1st battery.

### **Checking manufacturing feasibility**

Without any loss of generality, let us assume that the starting assembly time is *x*(0) = 0, which may correspond to 8.00 h. Moreover, let the battery cells and the controller be available at that time, i.e., *uc*(0) = 0 and *ul*(0) = 0.

There is a set of 10 different batteries to be mounted. Having the worker experience, as well as required parameters of the batteries described along with (6.1)–(6.2) and the performance model (6.10)–(6.11), one can calculate the expected battery mounting times *cm*(*k*) + *cl*(*k*), which are given in Table 6.5. The cells and the controller are delivered to the assembly station every 19 and 20 min, respectively. The problem is to check if there is a chance to mount all 10 batteries in 200 min. For that purpose, one can use (6.24). As an example let us employ it for calculating *x*(1), i.e., the start time of mounting battery number 1 (Table 6.6):

$$\max(1) = \max(x(0) + c\_m(0) + c\_l(0), u\_c(1), u\_l(1)) = \max(23, 19, 20) = 23.\tag{6.25}$$

As a result, the mounting start time for the last battery is *x*(9) = 184 while its expected assembly time is 20 min, and hence all batteries will be completed in 204 min.




**Table 6.6** Expected battery mounting times

# **•** > **Towards flexible manufacturing**

A direct calculation of the total battery assembly time,

$$T\_{\text{total}} = \sum\_{k=0}^{9} (c\_m(k) + c\_l(k)) = 196 \,\text{[min]},\tag{6.26}$$

clearly indicates that it is possible to perform the above task in 200 min. This, however, requires a different strategy for calculating component delivery times *um*(*k*) and *uc*(*k*). Indeed, there are different types of batteries with different expected assembly times (cf. Table 6.5). Thus, because the employed delivery rate is constant, it prevents attaining optimal assembly performance.

To settle this important issue, it is proposed to extend the scheme presented in Fig. 6.2 with an external device and scheduling software. As a result, the scheme shown in Fig. 6.5 is obtained. The purpose of the external software is to calculate optimal component delivery times *um*(*k*) and *uc*(*k*), which will make it possible to have the components just on time. The software should also take into account inevitable delays which can be caused by the worker. Additionally, such delays should be compensated for as much as possible. For further details the reader is referred to the authors' publications concerning such developments [11, 16, 17]. Indeed, using the fault-tolerance concept, these approaches can also minimize various unappealing phenomena like, e.g., delays. Additionally, the control process involves a cost function, which can take into account a wide range of economic aspects [14].

As can be seen in Fig. 6.5, the hardware is communicated with KIS.BOX through its digital outputs, which provide information about the current assembly status. Finally, the scheduling sequence is employed to control the item delivery process.

**Fig. 6.5** General overview of the manual assembly station with the KIS.ME infrastructure as well as external hardware and software

### **6.4 Scheduling Transportation Actions**

In Chap. 3 and Sect. 5.1, a set of logistic and transportation solutions were proposed along with measures that can be used for assessing their performance. However, in all cases the decisions concerning the required transportation actions were made either by the transporter operator or the KIS.MANAGER operator. In this section, the warehouse transportation system proposed in Sect. 6.2 is extended with a scheduling framework, which makes it possible to deliver the items (cf. Fig. 6.3) just on time. Similarly as in Sect. 6.3, let us introduce the following variables concerning the *i*-th forklift:


The decision variable may have two states:


**Fig. 6.6** General overview of the transportation system with the KIS.ME infrastructure as well as the external hardware and software

A scheme of the proposed general transportation framework is presented in Fig. 6.6. From the KIS.MANAGER viewpoint, the proposed scheme extends the one discussed in Sect. 6.2 by introducing rules of the following form: If a forklift performed transportation of the *k*-th item, then the false–true–false sequence is sent to KIS.LIGHT digital output 1 associated with the *T* (*k*) transfer station. This slight modification allows gathering measurements pertaining to the transportation time of the *k*-th item. Indeed, this process starts from the "None" state (see Table 6.4) of the KIS.LIGHT associated with the *T* (*k*) transfer station and ends with the false–true–false sequence on its digital output 1.

Under the above preliminaries, the time-driven model of the *i*-th forklift is given by

$$\mathbf{x}\_{i}(k+1) = \max\left(\mathbf{x}\_{i}(k) + f\_{d,i}(\mathbf{x}) + b\_{d,i}(k), \boldsymbol{u}(k+1)\boldsymbol{v}\_{i}(k+1)\right),\qquad(6.27)$$

where

$$f\_{d,i}(k) = f\_i(k)\upsilon\_i(k),\tag{6.28}$$

$$b\_{d,i}(k) = b\_i(k)\upsilon\_i(k),\tag{6.29}$$

while *f* (*k*) and *b*(*k*) can be calculated using the model (6.22)–(6.23) developed in Sect. 6.2. This means that, depending on the decision *vi*(*k*), the variables *fd*,*<sup>i</sup>*(*k*) and *bd*,*<sup>i</sup>*(*k*) can be equal to either 0 or *fi*(*k*) and *bi*(*k*), respectively.

### **Two forklifts example**

Let us consider two forklifts and one transfer station located in front of the aisle corresponding to the second forklift. Figure 6.3 shows the second forklift and the transfer station with the KIS.LIGHT operational LED lighting in magenta. The first forklift operates in front of the transfer station with the KIS.LIGHT operational LED lighting in yellow. Let us imagine that the item is delivered to the transfer station (magenta) and it has to be transported by the first forklift. This means that the corresponding KIS.LIGHT digital input is set to the "Left hand side" state (cf. Table 6.4). Based on such information, the external software should set the decision variables in the following way: *v*1(0) = 1 and *v*2(0) = 0, which clearly indicates that the first forklift has to perform transportation of the 0th item. Let us also assume that *x*1(0) = 0 and *x*2(0) = 0, which may correspond to 8.00, i.e., the beginning of the shift. Moreover, let *f*1(0) = 3 and *b*1(0) = 2 minutes. Thus, Eqs. (6.27)–(6.29) imply that

$$
\mu\_1(1) = \max(0 + \mathfrak{Z} + \mathfrak{Z}, \mu(1)\upsilon\_1(k)) = \max(\mathfrak{Z}, \mu(1)\upsilon\_1(1)), \qquad (6.30)
$$

$$
\mu\_2(1) = \max(0, \mu(1)\nu\_2(1)) = \mu(1)\nu\_2(1). \tag{6.31}
$$

From the above results, it is evident that, if the subsequent, i.e., *k* = 1, item should be transported by the first forklift (*v*1(1) = 1 and *v*2(1) = 0), then *u*(1) ≤ 5 guarantees just-on-time performance. Contrarily, if the subsequent, i.e., *k* = 1, item should be transported by the first forklift (*v*1(1) = 0 and *v*2(1) = 1), then *u*(1) = 0 guarantees just-on-time performance.

The above preliminary results formed the basis for formulating the scheduling strategies proposed by the authors [1, 11, 14, 15, 17], which can be efficiently used for various kinds of problems. The crucial element of these strategies is the cost function:

$$J = \sum\_{k=0}^{n\_E - 1} \mu(k),\tag{6.32}$$

which has to be maximized for all *nE* transportation events (6.13) taking into account (6.27) and the related constraints [1, 11, 14, 15, 17]. The process of maximizing (6.32) can be interpreted as finding the just-on-time item delivery times *u*(*k*) for the forklift transportation system.

# *6.4.1 Health-aware and Fault-Tolerant Transportation Scheduling*

The scheduling software presented in Fig. 6.6 can be extended with additional elements, which can settle the following problems:


Before settling the above issues, it is necessary to provide a list of crucial constraints which influence the performance of the transportation system [14]:

Transfer constraint: For the same transfer station, it is possible to deliver a new item iff the previous one has been removed. Thus, for all *l* and *k*,

$$\text{IF } l > k \text{ and } T(k) = T(l) \text{ THEN } u(k) \le u(l) + t(j), j < n\_E,\tag{6.33}$$

where *t*(*j*) > 0 is a unknown time between delivering the *k*-th and *l*-th items to the *T* (*k*) = *T* (*l*) transfer station.

Scheduling constraint: This constraint simply states that all *nE* starting times of transportation events should be bounded:

$$
u(k) \le \mathcal{u}\_E,\tag{6.34}$$

where *uE* > 0 is maximum scheduled time for starting all *nE* transportation events. Energy constraint: It is assumed that each forklift is equipped with the battery management system (BMS), which provides information about the maximum operational time of the *i*-th forklift τ*i*(*k*) for the *k*-th transportation system.

Let us start with analysing potential faulty situations, which will have direct influence on the feasibility of constraints. The delay in taking the *k*-th item will cause *t*(*j*) to be extended, i.e., the delivery of the subsequent *l*-th item will be delayed. Thus, with appropriately large *t*(*j*) > 0, the constraint (6.33) is always feasible. Contrarily, a faulty situation may cause (6.34) to be infeasible. Thus, fault-tolerance can be attained by introducing a relaxation variable *u*¯ ≥ 0, which should be as small as possible. Additionally, if the faulty situation makes the measured transportation times larger than the nominal values, then they should replace them in the model (6.27) of the *i*-th forklift, which suffers from the delay. Thus, to achieve fault-tolerance, the minimized cost function should be given as follows:

$$J = -p\_1 \sum\_{k=0}^{n\_E - 1} u(k) + p\_2 \bar{u},\tag{6.35}$$

where *p*<sup>1</sup> ≥ 0 and *p*<sup>2</sup> ≥ 0, *p*<sup>1</sup> + *p*<sup>2</sup> = 1 are weighting parameters, which can be used for attaining a balance between fault-tolerance and performance.

Let us proceed to health-aware analysis. For simplicity, it is assumed that each forklift is operating in a single aisle. However, more flexibility can be attained by removing this constraint. Thus, one can imagine that the tasks with shorter (smaller *fi*(*k*) + *bi*(*k*)) and less energy-demanding transportation tasks are realized by forklifts with smaller τ*i*(*k*). This can be formally expressed by the following cost function:

$$J\_H = -\sum\_{k=0}^{n\_E - 1} \sum\_{i=1}^{n\_F} (\tau\_i(k) - b\_i(k) - c\_i(k)),\tag{6.36}$$

where *nF* is the number of forklifts. Finally, the minimized cost function takes the form

$$J = -p\_1 \sum\_{k=0}^{n\_E - 1} u(k) + p\_2 \tilde{u} + p\_3 J\_H,\tag{6.37}$$

where *p*<sup>3</sup> ≥ 0, *p*<sup>1</sup> + *p*<sup>2</sup> + *p*<sup>3</sup> = 1.

# **•** > **Economy oriented cost function**

The cost function (6.37) is very general and can be extended with additional components corresponding to the operational cost of the transportation system. This is especially important in the case of a fleet consisting of different forklifts. Thus, each forklift may involve different operational costs.

# **6.5 Training Exercise: Work Scheduling**

### **6.1** Scheduling tasks of three workers

Exercise requirements: The exercise requires access to one KIS.LIGHT, three KIS.BOXes and a photoelectric senor with an M12 8 pin interface (see Sect. 3.1).


**Fig. 6.7** Scheduling tasks of three workers



**Table 6.8** Worker's KIS.BOX Button 2 operational LED states

**Table 6.9** KIS.LIGHT transportation actions


### **6.6 Concluding Remarks**

The main objective of this chapter was to provide a selected list of motivating examples pertaining to potential applications of KIS.ME. Although the presented instances concern a dedicated application study, they can be relatively easily adapted to different applications frequently encountered in various industries. In particular, it was shown how to model human operator performance both in assembly and transportation tasks. The resulting model is particularly important for various kinds of planning and scheduling. Indeed, such models make it possible to obtain transparency and predictability of the controlled and monitored system. Additionally, as most indoor transportation means employ various kinds of accumulators, it is profitable to take into account their health. Thus, it was shown how to include such information in the scheduling procedure. As a result, the overall accumulator health of the transporter fleet can be balanced. Another important aspect is that the human operated system may suffer from various kinds of delays. Thus, it was shown how to attain fault-tolerance which can prevent such a kind of unappealing situations. Finally, the chapter ended with advanced training exercises, which pertain to work scheduling of three workers operating a conveyor belt.

### **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 7 KIS.API: Towards External Communication**

# **7.1 Introduction to KIS.API**

KIS.API is defined as a particular instance of REST API [1–3], which is designed for the purpose of unified and convenient communication with KIS.Devices and the associated environment operating within KIS.MANAGER.

The crucial components of KIS.API are the resources, which can be defined in a very broad sense. In fact, anything having a name can be perceived as a resource, e.g., a user, a workspace, an asset, etc. The crucial information associated with a resource pertains to the service being realized, i.e., the transfer of data as well as the associated actions. A general structure of the resource is given in Table 7.1 [1].

Let us start with the . As an example, one can consider a KIS.Device, which can characterized by, e.g.,


while its possible representation can be given in an intuitive JSON [1] form:

```
{
    "id": 10102,
    "urn": "urn:rafi:sbox:9c65f93cbed6",
    "name": "KIS.BOX 9C65F93CBED6",
    "assetGroupIDs": [
        9757,
        9758
    ]
}
```
© The Author(s) 2023 M. Witczak et al., *Modern IoT Onboarding Platforms for Advanced Applications*, Studies in Systems, Decision and Control 476, https://doi.org/10.1007/978-3-031-33623-2\_7


**Table 7.1** A typical structure of a resource


Now let us proceed to the resource identifier, which provides a unique way to identify the resource at any time instance. In other words, it should provide a full and unique path to the resource. Since the REST structure is based on HTTP, a sample path can look as follows:

```
https://api.kisme.com/kisapi/v1/assets/assetUrn,
```
which uniquely identifies a given KIS.Device using its URN. Having a resource identifier, one can proceed to realize some actions with it. A general set of verbs, which defines specific actions, is given in Table 7.2. Finally, an important standard that is inherited by REST from HTTP pertains to the status code. The most common status codes are given in Table 7.3. Under the above preliminary information, one can proceed to the registration and authorization of a new KIS.API user using KIS.MANGER.

### *7.1.1 User Registration and Authorization*

The primary objective of this part is to define a new KIS.API user along with an appropriate credentials. The process starts with selecting the Main menu → Portal


admin and then pressing the KIS.API icon . Subsequently, a new KIS.API user can be created with . The process is fully automatic and the only information required is to provide a user description, i.e., a name. A sample KIS.API credentials generation process is presented in Fig. 7.1. As a sample, a KIS.API access control triplex is obtained, which can be summarized as follows:


Note that baseUrl is simply the base resource identifier detailed in the preceding section, i.e.,

```
https://api.kisme.com/kisapi/v1/
```
The objective of the subsequent sections is to provide a concise introduction to KIS.API. Thus, to simplify this process, the Postman (https://www.postman.com/) application is employed. It is a dedicated platform for building and using APIs. In other words, Postman can be perceived as an HTTP client for testing web services, which makes it easy to test APIs by providing a simple interface for issuing API requests and viewing responses. The Postman registration and configuration process is very intuitive, and hence it is omitted. The subsequent step is to proceed to the KIS.API documentation (https://docs.kisme.com) and then select Run are Postman button. As a result, KIS.API collection is loaded into the Postman workspace. The final step is to provide the above defined KIS.API credentials using . This process is illustrated in Fig. 7.2. As of that moment, all KIS.API commands can be accessed and tested using the intuitive Postman graphical user interface. This process boils down to selecting an appropriate option and then sending a desired request to KIS.API. Thus, the objective is to provide a concise review of all available KIS.API functionalities.


**Fig. 7.2** Postman configuration with KIS.API credentials

### **7.2 Essential Functionalities**

The objective of this section is to provide essential KIS.API functionalities. This starts from access to assets being simply KIS.Devices, users and asset groups up to the related Datapoints. Finally, a set of recipes concerning an access to calculated Datapoints and KPIs is provided.

# *7.2.1 Obtaining Information About Asset Groups, Assets and Users*

As introduced in Chap. 2, KIS.Devices constitute the core KIS.ME components. Thus, knowing all of them, along with their membership to particular asset groups (see Chap. 2), is of paramount importance. Table 7.4 presents the list of all available KIS.API requests concerning assets along with the designated actions. As can be observed, most requests require additional path variables:


The response pertaining to the request detailed in Table 7.4 may contain the following parameters:

ID: the asset identifier, URN: the asset URN, name: the name of the asset, isOnline: the asset isOnline Datapoint value, hardware: information about the asset hardware, software: information about the asset software, certificate: information about the asset certificate, network: information about the asset network, firmwareUpdate: information about the asset firmware updates,

### 7.2 Essential Functionalities 215


**Table 7.4** List of possible requests associated with an asset

**Table 7.5** List of possible requests associated with an asset group


assetGroupIDs: an array containing numerical values of the asset groups associated with the asset.

Note that most of the above features can be directly accessed through KIS.MANAGER by selecting Main menu → Assets and then choosing a desired asset. Subsequently, the information about the asset can be retrieved by pressing (see Fig. 2.16).

Having all the above information, let us proceed to two simple examples of using the discussed requests.

### **Obtaining a list of assets**

This example concerns a response to the request no. 1 listed in Table 7.4. As a result, the following JSON structure can be obtained:

```
]
    {
        "id": 10102,
        "urn": "urn:rafi:sbox:9c65f93cbed6",
        "name": "KIS.BOX 9C65F93CBED6",
        "assetGroupIDs": [
            9757,
            9758
        ]
    },
    {
        "id": 10153,
```

```
"urn": "urn:rafi:sbox:9c65f93cbeb8",
    "name": "KIS.BOX 9C65F93CBEB8",
    "assetGroupIDs": [
        9757,
        9758
    ]
}
```
As can be observed, the response contains information about two KIS.BOXes, which are assigned to two asset groups (9757 and 9758).

### **Removing an asset from the asset group**

This example concerns a response to the request no. 5 listed in Table 7.4. Let us consider the first asset (KIS.BOX) given in the preceding example. Its URN is urn:rafi:sbox:9c65f93cbed6, and it is assigned to two asset groups 9757 and 9758. The objective is to remove it from the asset group 9757, and hence the assetgroupId parameter should be set to 9757. As a result, the following JSON structure can be obtained:

```
{
    "message": "The operation is in conflict with the
    relationship constraint 'assetsMustBeMemberOfInventory'",
    "code": 409
}
```
which simply means that it is impossible to remove an asset from the list of all available assets (see Table 2.5 for a comprehensive explanation). Thus, let us change the assetgroupId parameter to 9758 (the second available asset group). As a result, the following JSON structure is obtained:

```
{
    "id": 10102,
    "urn": "urn:rafi:sbox:9c65f93cbed6",
    "name": "KIS.BOX 9C65F93CBED6",
    "assetGroupIDs": [
        9757
    ],
    "isOnline": false,
    "hardware": {
    },
    "software": {
```
]

```
},
    "certificate": {
    },
    "network": {
    },
    "firmwareUpdate": {
    }
}
```
As can be observed, the assignment of this asset to the asset group 9758 was removed.

Let us proceed to the asset groups for which the available request list is given in Table 7.5. As can be observed, most requests require an additional parameter assetgroupId, which can be retrieved through the request no. 1 in Table 7.5. The response pertaining to the request detailed in Table 7.5 may contain the following parameters:

ID: the asset group identifier,

assetIDs: an array containing numerical values of asset IDs associated with the asset group,

name: the name of the asset,

isOnline: the asset isOnline Datapoint value,

description: a detailed description of the asset group,

name: the name of the asset group.

Let us proceed to two simple examples explaining the application of the above requests.

### **Obtaining a list of asset groups**

This example concerns a response to the request no. 1 listed in Table 7.5. As a result, the following JSON structure can be obtained:

```
[
    {
         "id": 9757,
         "name": "My Devices",
         "assetIds": [
             10102,
             10153
         ]
    },
    {
         "id": 9758,
```

```
"name": "Workspace 1",
    "assetIds": [
        10153
    ]
}
```
As can be observed, the response contains information about two asset groups and the assets associated with them (IDs: 10102, 10153).

### **Updating the asset group description**

This example concerns a response to the request no. 3 listed in Table 7.5. Let us provide a new description of Workspace 1 (ID 9758) in the JSON form:

```
{
  "name": "Workspace 1",
  "description": "Main Workspace"
}
```
In the case of the Postman application, to provide such a description one should go to the Body tab of the request and enter the above JSON structure. As a result, the following JSON structure can be obtained:

```
{
   "id": 9758,
   "name": "Workspace 1",
   "assetIds": [
       10153
   ],
   "description": "Main Workspace"
}
```
Having access to assets and the associated asset groups, let us proceed to the user management functionalities, which are listed in Table 7.6. As can be observed in Table 7.6, requests no. 2 and 3 require an additional path parameter called accountNumber. Note that in KIS.MANAGER the user is identified by its name and email. Thus, at least one of these parameters should be known while realizing the request no. 1 in Table 7.6. Thus, the obtained response can be used to obtain the associated accountNumber.

]


**Table 7.6** List of possible requests associated with users

### **Displaying all users and their accountNumber**

This example pertains to realisation of the request no. 1 in Table 7.6. As a result, the following JSON structure can be obtained:

```
[
    {
    "name": "Jack Cactus",
    "email": "j.cactus@controlintech.pl",
    "accountNumber": "3d5997bb-f6ee-4681-8adf-0ce7366e2964"
    },
    {
    "name": "Hans Wurst",
    "email": "h.wurst@controlintech.pl",
    "accountNumber": "4f4009c2-1a7b-4531-b780-702a19cd62a1"
    }
]
```
The structure contains information about two users and their associated accountNumber.

### **Deleting a user**

The JSON structure obtained in the preceding example contains information about two users. The objective of the current example is to delete the user identified:

```
"accountNumber": "3d5997bb-f6ee-4681-8adf-0ce7366e2964"
```
For that purpose, the above number has to be provided as a path parameter in the Postman application. Note that, after sending a request to KIS.API, no JSON structure is received (cf. code 204 in Table 7.3).


**Table 7.7** List of possible requests associated with Datapoints

# *7.2.2 Accessing Data Through Datapoints*

The objective of this point is to provide a way of accessing the data associated with Datapoints. For a comprehensive description of Datapoints, the reader is referred to Sect. 2.7 and Appendix. B. The possible requests associated with Datapoints are provided in Table 7.7. It should be also noted that the above requests require the following path parameters:


Additionally, request no. 2 in Table 7.7 can be executed with the following query parameters:


Note that it is not compulsory to use all of the above-listed query parameters simultaneously. For example, the limit parameter can be employed as a standalone one.

### **Obtaining a list of Datapoints**

The example is concerned with the request no. 1 in Table 7.7. As a result of using it, a full list of Datapoints along with their types is returned. A sample form of such a couple is given as follows:

```
{
    "name": "button2Pressed",
    "datatype": "BOOLEAN"
}
```
### **Obtaining five recent Datapoint values**

For the purpose of this example, a set of two rules is implemented (see Sect. 2.9 for more details), i.e.,


Thus, the purpose of the above rules is to switch the KB Button1 operational LED color from red to black (no illumination) and vice versa. This means that the resulting effect should be the KB Button 1 operational LED blinking in red. However, to achieve such an effect, the KB Button 1 operational LED color should be initiated using its digital twin (see Sect. 2.6) by setting the above color to either black or red. Subsequently, the path parameters should be defined, i.e., assetUrn and datapointDefinition. The latter one is set to button1ColorKpi. Finally, the query parameter limit is set to five. As a result, a JSON structure is obtained containing the five recent values of the indicated Datapoint:

```
[
    {
        "timestamp": "2022-08-30T11:50:07.478Z",
        "value": "2"
    },
    {
        "timestamp": "2022-08-30T11:50:06.478Z",
        "value": "5"
    },
    {
        "timestamp": "2022-08-30T11:50:05.524Z",
        "value": "2"
    },
    {
        "timestamp": "2022-08-30T11:50:04.712Z",
        "value": "5"
    },
    {
        "timestamp": "2022-08-30T11:50:03.649Z",
        "value": "2"
    }
]
```
The recorded Datapoint values simply indicate that the KB Button 1 operational LED changes its color from red (5) to black (2) and vice versa. As can be observed, the switching process takes more or less one second. However, this time is data transfer-dependent, and hence its is not uniform.

### **Obtaining five recent Datapoint values from a given time frame**

The objective of this example is to focus on the reader attention to ISO data-time format, which is given, e.g., by

```
2022-08-30T14:02:07.478Z
```
Its construction is obvious: however, it contains characters which are not permitted in a URL construction, i.e. '.', which should be simply replaced by its equivalent equal to '%3A', yielding

```
2022-08-30T14%3A02%3A07.478Z
```
Thus, by setting the from query parameter according to the above form one can obtain:

```
[
    {
        "timestamp": "2022-08-30T14:02:32.304Z",
        "value": "5"
    },
    {
        "timestamp": "2022-08-30T14:02:31.304Z",
        "value": "2"
    },
    {
        "timestamp": "2022-08-30T14:02:30.336Z",
        "value": "5"
    },
    {
        "timestamp": "2022-08-30T14:02:29.507Z",
        "value": "2"
    },
    {
        "timestamp": "2022-08-30T14:02:28.475Z",
        "value": "5"
    }
]
```
# *7.2.3 KPIs and Calculated Datapoints*

This section constitutes a continuation of the preceding one. Indeed, CDPs and KPIs (see Sect. 4.1.2 and Appendices A and B) employ Datapoints as a basis for forming desired answers pertaining to the system state and performance. The CDP requests are similar to those for Datapoints (see Table 7.7), and they are presented in Table 7.8. It should be also noted that the above requests require the following path parameters:


Additionally, the request no. 2 in Table 7.8 can be executed with the following query parameters:


Now, let us proceed to KPI requests available through KIS.API. They are given in Table 7.9, and it is not surprising that they are similar to those presented in Table 7.8. Additionally, they path parameters are given by


Unlike Datapoints and CDP, the KPI request no. 2 (see Table 7.9) has to be executed with the following query parameters:



**Table 7.8** List of possible requests associated with CDPs

**Table 7.9** List of possible requests associated with KPIs


### **Accessing the list of KPIs**

Let us continue with the example presented in Sect. 7.2.2 pertaining to a KIS.BOX associated with two rules. These two rules perform cyclically one after the other. The first one change the KIS.BOX Button 1 operational LED color from black to red while the second one realizes an opposite situation. It is assumed that no KPIs are defined for this KIS.BOX (see Sect. 4.1.2 for a detailed tutorial on KPIs). Thus, let us define the KPI counting the entire time period for which the above mentioned color is red. For that purpose, the following KPI is implemented:

```
y = Round[Sum[If[x == 5, Duration[x], 0]]/1000];
```
where x stands for the button1ColorKpiDuration Datapoint while the number five signifies the red color (see Table 2.2). Finally, let us assume that this KPI is named KBButton1red while its processing period is set to 15 min. Having the above KPI, let us proceed to performing the request no. 1 in Table 7.9. As a result, the following JSON structure is obtained:

```
[
   {
        "name": "KBButton1Red"
   }
]
```
### **Accessing KPI values**

Let us continue with the above example. Now, the task is to obtain KBButton1red (path parameter kpiDefinition) values within the time period defined by the parameters 'from' and 'to' given by

2022-08-31T08:02:50.046Z 2022-08-31T12:22:50.046Z

which, as discussed in Sect. 7.2.2, are formatted according to

2022-08-31T08%3A02%3A50.046Z 2022-08-31T12%3A22%3A50.046Z As a result, the following JSON structure is obtained:

```
{
   "to": "2022-08-31T12:22:50.046Z",
   "from": "2022-08-31T08:02:50.046Z",
   "values": [
       447,
       443,
       448,
       447,
       451,
       451,
       448,
       451,
       450,
       453,
       447,
       454
   ]
}
```
It can be easily observed that there are 12 values corresponding to 15-minute processing periods. It is also straightforward to observe that 15 min are equivalent to 900 s. Thus, it is evident that all the above-presented values should oscillate around 450 s, which is actually the case.

### **Accessing data from CDPs**

The last task of this point concerns obtaining an information about predefined CDPs as well as finding their values. For that purpose, it is assumed that no CDPs are defined. Moreover, the preceding example is continued. Thus, a new CDP is defined according to the approach presented in Sect. 4.1.1 with *x* equivalent to button1ColorKpiDuration Datapoints. The developed CDP aims at bounding the minimum numerical value of *x* to 3, which represents the green color (see Sect. 2.6). As a result, the following simple implementation is obtained:

z=If[x<3,3,x];

while CDP itself is named KBmaxcolorCDP. Let us start with the request no. 1 in Table 7.8, which pertains to obtaining a list of all available CDPs. As a result of using it, the following JSON structure is arrived at:

```
[
   {
       "name": "KBmaxcolorCDP",
       "datatype": "DOUBLE"
   }
]
```
which contains the existing CDP names as well as their data types. Having the CDP name, let us proceed to obtaining its values. In fact this process is identical to the one presented in Sect. 7.2.2. According to the adjustment performed in the preceding examples, *x* can have the values representing either the red or the black color, i.e., *x* = 5 or *x* = 2 (cf. Table 2.2). The request No. 2 in Table 7.8 is executed with the query parameter limit only, which is equal to 10. As a result, the following JSON structure is obtained, which provides the desired results:

```
[
   {
       "timestamp": "2022-09-02T10:45:22.804Z",
       "value": "5"
   },
   {
       "timestamp": "2022-09-02T10:45:22.335Z",
       "value": "3"
   },
   {
       "timestamp": "2022-09-02T10:45:21.554Z",
       "value": "5"
   },
   {
       "timestamp": "2022-09-02T10:45:20.929Z",
       "value": "3"
   },
   {
       "timestamp": "2022-09-02T10:45:20.054Z",
       "value": "5"
   }
]
```


**Table 7.10** List of possible requests associated with rules

# *7.2.4 Accessing Information About Rules*

Rules (cf. Sect. 2.9) constitute the last component which can be accessed through KIS.API. The currently possible requests are provided in Table 7.10.

Additionally, the request no. 2 in Table 7.10 should be executed with the following path parameters:


The parameters that can be accessed through the process of executing these requests are


### **Obtaining information about rules**

The objective of this example is to show how to access information about rules. Let us start with the request no. 1 in Table 7.10, which does not require any path or query parameters while its execution results in the following JSON structure:

```
[
   {
       "name": "rblack2red",
       "assetGroupId": 9758,
       "id": "b92080c3-55aa-410e-a417-9efe90637515",
       "enabledAPI": false
   },
   {
       "name": "rred2black",
       "assetGroupId": 9758,
       "id": "62124944-a606-4b80-b906-94d6d5ae8d38",
       "enabledAPI": false
   }
]
```
Contrarily, having assetGroupId and id signifying the rule, one can obtain the name of the rule and the logical property enabledAPI. Indeed, by using them as the path parameters and then executing the request no. 2 in Table 7.10, one can arrive at the following JSON structure:

```
{
   "name": "rblack2red",
   "assetGroupId": 9758,
   "id": "b92080c3-55aa-410e-a417-9efe90637515",
   "enabledAPI": false
}
```
# *7.2.5 Triggering Rules from External Applications*

The objective of this section is to introduce a very important feature of KIS.API, which makes it possible to trigger a rule from an external application. However, as mentioned in Sect. 7.2.4, such an operation is possible for the rules having the enabledAPI property set to the logical truth. For example, the rule considered at the end of Sect. 7.2.4 should have the following JSON structure:

```
{
   "name": "rblack2red",
   "assetGroupId": 9758,
   "id": "b92080c3-55aa-410e-a417-9efe90637515",
   "enabledAPI": true
}
```
Note that the modification of the enabledAPI property is possible through KIS.MANGER only. For that purpose, one should use the Main menu → Asset groups and then select an appropriate asset group. Subsequently, by going to Rule engine and selecting the desired rule, one can see the property editor called API integration, which is presented in Fig. 7.3. As can be observed, there is another property, which is called Websocket-Action. However, it will be discussed in Sect. 7.5. Finally, the rule triggering request is described in Table 7.11.


**Table 7.11** a requests associated with a rule trigger

# **7.3 KIS.API in Practice**

The purpose of Sect. 7.2 was to introduce to the reader the essential functionalities concerning KIS.API. All of them were carefully described while their practical usage was explained with the Postman (https://www.postman.com/) application. The objective of this section is to provide practical guidelines concerning KIS.API application using some popular software. Indeed, the software selection being used in this section is not accidental. The first candidate is employed widely both in the industry for presenting various kinds of data in tabular order. The second one is commonly used for research, analysis, development and deployment of new practical concepts based on data gathered from a given system. Thus, these two popular software instances are


Both of them have several different and freely-available counterparts, which can provide similar functionalities. Thus, the objective of the subsequent point is to provide a short practical tutorial on feeding MS Excel and Matlab with KIS.ME data. Although the current section is restricted to MS Excel and Matlab, the reader possessing the knowledge about the KIS.ME essential functionalities can integrate it with more advanced and dedicated software. An enterprise resource planning system can be a good example of such software (see, e.g., SAP and its API functionalities at https://api.sap.com/).

# *7.3.1 Feeding MS Excel with KIS.ME Data*

Starting with MS Excel 2013 it is possible access any REST API using the so-called power query. Thus, the entire recipe for accessing data from KIS.API boils down the following steps:



**Fig. 7.4** Result of a KIS.API request in MS Excel


**Fig. 7.5** Result of a KIS.API request presented as a table


### **Obtaining a list of all rules**

The objective of this example is to obtain a list of all rules present in KIS.MANAGER Rule engine. According to Sect. 7.2.4, a URL should be defined as follows:

baseUrl/rules

while the required headers may have the following structure:

```
X-API-KEY 2b84bd4de38b4e92bb7bb283364477e1
X-CLIENT-ID 708ce7cc-fd57-416d-991f-f68704385c22
```
Finally, the desired data request is performed and the obtained result is given in Fig. 7.4. As can be observed, there are three records, which simply correspond to three different rules. To make the obtained result more transparent, the option Convert to Table can be used used, which after suitable expansion yields the view presented in Fig. 7.5.

# *7.3.2 Feeding Matlab with KIS.ME Data*

The objective of this section is to show how to realise the KIS.API GET request with MATLAB. The entire process boils down to the following steps:


data=webread(URL,web\_options,query\_parameters)

### **Accessing Datapoint values**

The primary objective of this example is to obtain twenty recent values of the button1ColorKpi Datapoint of KIS.BOX defined by a given URN. For that purpose the example introduced in Sect. 7.2 is utilized. Let us start with defining an appropriate URL according to Sect. 7.2.2 (Table 7.7), which can be realized as follows:

```
baseUrl='https://api.kisme.com/kisapi/v1';
assetUrn='urn:rafi:sbox:9c65f93cbed6';
DPdef='button1ColorKpi';
finalUrl=strcat(baseUrl,'assets/',assetUrn,+'/',DPdef,
'/datapointValues');
```
Subsequently, the weboptions structure with HeaderFields is defined:

```
opt=weboptions;
content={'Content-Type' 'application/json'};
client={'X-CLIENT-ID' '708ce7cc-fd57-416d-991f-f68704385c22'};
key={'X-API-KEY' '2b84bd4de38b4e92bb7bb283364477e1'};
opt.HeaderFields=[content;client;key];
```
Finally, webread can be executed:

```
data=webread(finalUrl,opt,'limit','20');
```
However, the current example, apart from retrieving data, extracts the values and occurrence times of the KIS.API data. Moreover, such a request is repeated every second and the obtained results are suitably visualized. Such a time-driven loop is repeated until a user presses any key. The code realizing all the above mentioned operations is given as follows:

```
clc; clear; close all;
 baseUrl='https://api.kisme.com/kisapi/v1';
 assetUrn='urn:rafi:sbox:9c65f93cbed6';
 DPdef='button1ColorKpi';
 finalUrl=strcat(baseUrl,'assets/',assetUrn,+'/',DPdef,
 '/datapointValues');
 opt=weboptions;
 content={'Content-Type' 'application/json'};
 client=
 {'X-CLIENT-ID' '708ce7cc-fd57-416d-991f-f68704385c22'};
 key={'X-API-KEY' '2b84bd4de38b4e92bb7bb283364477e1'};
 opt.HeaderFields=[content;client;key];
 h = figure(1);
 while isempty(get(h,'CurrentCharacter'));
   data=webread(finalUrl,opt,'limit','20');
   values=[cellfun(@str2num,{data.value})];
   ind=find(values>7);
   values(ind)=[];
   times=datetime({data.timestamp},'InputFormat',
   'uuuu-MM-dd''T''HH:mm:ss.SSSZ','TimeZone','UTC');
   times(ind)=[];
   stairs(times,values,'LineWidth',2);
   xlabel('Time');
   ylabel(DPdef);
   ylim([0 8]);
   pause(1);
end;
```
The obtained results are given in Fig. 7.6. As can be observed, the value of button1ColorKpi Datapoints is switched between black (2) and red (5) colors.

*Remark 7.1* The example presented in this point corresponds to the so-called polling procedure in which KIS.API requests are repeated every single second. This process is, of course, inefficient as it is executed irrespective of the fact of having new KIS.API data. Indeed, even if there is no new data, the request is still executed. To settle this unappealing phenomenon, KIS.ME provides the so-called websockets, which are discussed in Sect. 7.5.

# **7.4 Triggering Rules from MATLAB**

The objective of this section is to show how to realize a KIS.API POST request with Matlab. For that purpose, an example with triggering the rule is engaged. Generally, the entire process boils down to the following steps:


data=webwrite(URL,web\_options,request\_parameters)

### **Triggering a rule from MATLAB**

The objective of this example is to show how to trigger KIS.ME rule from MATLAB. For that purpose, let us define a new rule. This rule has no triggers or conditions defined in KIS.MANGER. It aims at switching the KIS.BOX Button 2 operational LED color to yellow. Thus, there is only one action which performs the above task. Subsequently, API Integration (see Fig. 7.3) is used to set the enabledAPI property by activating the API-Trigger active option. The remaining information required to formulate the rule triggering request reduces to collecting

Rule ID: 13fcb514-9fe7-44a9-9802-3d972b0fee8a, Asset group ID: 9758.

Having the above information, it is possible to formulate the triggering request according to Table 7.11. Finally, the resulting code is given as follows:

```
clc; clear; close all;
baseUrl='https://api.kisme.com/kisapi/v1';
ruleID='13fcb514-9fe7-44a9-9802-3d972b0fee8a';
assetgroupId='9758';
addpath='rules/';
finalUrl=strcat(baseUrl,addpath,ruleID,+'/',assetgroupId,
'/trigger');
opt=weboptions;
content={'Content-Type' 'application/json'};
 client=
 {'X-CLIENT-ID' '708ce7cc-fd57-416d-991f-f68704385c22'};
 key={'X-API-KEY' '2b84bd4de38b4e92bb7bb283364477e1'};
opt.HeaderFields=[content;client;key];
data=webwrite(finalUrl,opt);
```
### **7.5 Websockets**

In spite of an incontestable appeal of the communication strategies presented in the preceding part of this chapter, they frequently suffer from the lack of efficiency. This is particularly the case when there is a need for observing the changes in system behaviour expressed in the evolution of Datapoints associated with KIS.Devices. Indeed, such a problem was already discussed in Sect. 7.3.2. The example considered in the preceding section concerned the so-called polling procedure, in which KIS.API requests are repeated every single second. This process is, of course, inefficient as it is executed irrespective of the fact of having new KIS.API data. Indeed, even if there is no new data, the request is still executed. To settle this unappealing phenomenon, KIS.ME provides the so-called websockets, which are discussed in this section.

### *7.5.1 Brief Introduction to Websockets*

Websocket [4] can be defined as a communication protocol, which permits bidirectional communication between the client and the web server. In a most common case, if a browser visits a web page, then an HTTP request is sent to the associated server. Subsequently, the web server replies by sending the response to the web browser. A similar strategy was realized in the preceding part of this chapter while using a different kind of applications, i.e., POSTMAN, MS Excel and Matlab. Thus, as was shown in Sect. 7.3.2, if the application wants to receive recently released data, then it must constantly, e.g., every second, send a request to the server. This corresponds to the situation in which the user constantly refreshes the page within the browser. This is also the reason why HTTP is a half duplex, which denotes the fact that the traffic flows in a single direction at a time:


Therefore, it is an obvious fact that it is not an elegant solution, widely called polling. It is defined as a regularly timed synchronous call in which the client releases a request to the server to check if there is any new data available. Such requests are realized using regular time intervals, and the client receives a response irrespective of the availability of the new data. Thus, if there is no new data, then the server replies with a negative response and the connection closes. Hence, polling can be efficient when an exact time interval concerning the release of the new data is known. Unfortunately, as has already been mentioned, KIS.ME is used to model a discrete event system in which the occurrence time of events is not equally distributed over a time horizon. Another communication strategy is called long polling. In this case, the client sends request to the server and opens a connection within some time period. If the server has no new data, then it holds the request and connection open until it has a new data for the client (or a predefined timeout is reached). An alternative communication strategy is called streaming. In this case, the client sends a request to the sever, which maintains an open response that is continually updated. The connection can be open permanently or until a predefined timeout is reached. Note that the server never indicates the completion of the HTTP response, and hence the connection is open continuously.

In order to eliminate the above issues, the concept of websocket was introduced. The websocket is by nature a bidirectional full duplex and single-socket connection. While using it, a single HTTP request is required to open a websocket connection. An appealing property of websocket is that it reuses the same connection in both ways, i.e., client–server and server–client. Owing to the fact that the server can send messages as they are available, the overall latency is reduced. Contrarily to polling, websocket communication is based on a single request, i.e., it is not necessary to wait for another request (along with headers, request parameters, etc.). A concise summary of using the websocket can be formulated as follows:


Similarly to HTTP and HTTPS, the websocket defines two URI schemes, namely, ws and wss, which correspond to standard and encrypted communication between the client and the server. The wss (Websocket Secure) URI scheme corresponds to the websocket connection over transport layer security (TLS). Note that TLS is also known as SSL (Secure Socket Layer). Thus, the same security mechanism is used as the one employed for HTTPS. This means that while constructing websockets one should use a URL of either the ws:// or wss:// form.

### *7.5.2 Obtaining a KIS.ME URI and Identifiers*

The objective of this point is to show how to retrieve a URI and an identifier necessary to construct a websocket. The first step on the way towards the above objective is to select the data of interest, which can be the following:


Thus, the required preliminary data is associated with the property subscribeTo, which may have the following values:


Subsequently, Datapoints and KPIs require a single or a list of assetIds (see Sect. 7.2) while rules require assetGroupIds. Finally, all these properties form a JSON data structure, which may look as follows:

```
{
  "assetIds": [
    37,
    66
  ],
  "assetGroupIds": [
    43,
    6
  ],
  "subscribeTo": "datapoint"
}
```
Having the above data along with KIS.API credentials (see Sect.7.1.1), one can perform a POST request according to Table 7.12. As a result, the following JSON structure can be obtained:


**Table 7.12** Requests of subscribing/unsubscribing to a websocket

```
{
  "subscriptionUris": [
    "wss:///pubsub.api.kisme.com/
     6d574a1f-4c37-4ab4-9fa6-86fb74a66375"
  ],
  "subscriptionId": "6d574a1f-4c37-4ab4-9fa6-86fb74a66375"
}
```
Analogously, the DEL request will unsubscribe from the websocket.

# *7.5.3 Brief Introduction to STOMP*

Messaging [4] stands for an architecture associated with sending asynchronous messages between independent components. Such an appealing property makes it possible to develop relatively loosely coupled systems. The crucial components of messaging are the message broker and the client. In particular, the former can perform such actions:


Note that the broker can also handle such operations as authorization, message encryption, etc. Thus, if clients are connected to the broker, then they can send messages to the broker as well as receive message distributed by the broker. Such a strategy is called publish/subscribe. Therefore, if a message broker publishes a number of messages, then the client can subscribe to either all or a subset of these messages. STOMP (simple text-oriented messaging protocol) is a good representative example of such a publish/subscribe protocol. Its layering relation with the websocket as well as with other protocols is detailed in Fig. 7.7. STOMP was also employed for the communication purposes within KIS.ME. Indeed, the websocket fits very well to a standard messaging architecture, in which there could be a large volume of potential messages distributed at high rates from the broker to the client. A good example is a client subscribing to Datapoints of an asset (see Sect. 7.5.2). Due to the relatively large number of Datapoints as well as their possible high rate of change,

receiving messages in real-time as well as with low latency is extremely important for the final performance of the entire application. STOMP is a very simple protocol, which resembles HTTP in its appearance. Each frame consists of a command, headers, etc. STOMP messages can represent any text or binary data. For further information about STOMP, the reader is referred to the STOMP protocol specification [5]. Additionally, STOMP [5] provides the so-called heart-beating mechanism, which can optionally be employed to verify the healthiness of the underlying TCP connection and to ensure that the remote end is still alive and kicking. Generally, it is defined by two integer values, separated by a comma. The first one represents outgoing heart-beats from the sender:


The second one represents incoming heart-beats, i.e., what sender would like to obtain:


Note that enabling heart-beating is possible by adding a suitable heart-beating header during the beginning of the STOMP session, i.e., to CONNECT [5].

### *7.5.4 Sample Websocket Implementations*

The objective of this section is to provide guidelines for practical implementation of KIS.ME-based websockets. In particular, the NODE.js [1] environment, which employs a widely employed JavaScript (JS) programming language is used. This section is composed of two examples, which aim at

websocket


Moreover, it is assumed that the reader has essential knowledge regarding NODE.js.

### **Reading KIS.ME data using STOMP over a websocket**

Let us start with providing suitable credentials and parameters, which will be located in the .env file:

```
SERVER_URL="https://api.kisme.com/kisapi/v1/websockets"
API_KEY="2b84bd4de38b4e92bb7bb283364477e1"
CLIENT_ID="708ce7cc-fd57-416d-991f-f68704385c22"
ASSET_ID="10102"
ASSET_GROUP_ID="9758"
```
For the purpose of further implementations, the following modules are required:

dotenv: loads environment variables from the .env file into process.env structure; websocket: implements the websocket protocol;

webstomp-client: provides a STOMP client for Web browsers and NODE.js through websockets;

axios: is a promise-based HTTP client for the Web browser and NODE.js.

Note that the application of the above modules is not compulsory and there are several counterparts which can be employed instead. Moreover, their documentation can be easily found at https://www.npmjs.com. After such a preliminary step, it is possible to define suitable request headers and options, which are given as follows:

```
const options = {
    method: "POST",
    url: process.env.SERVER_URL,
    headers: {
    "X-API-KEY": process.env.API_KEY,
    "X-CLIENT-ID": process.env.CLIENT_ID,
    "Content-Type": "application/json",},
    data: JSON.stringify({
      assetIds: [parseInt(process.env.ASSET_ID)],
      assetGroupIds: [parseInt(process.env.ASSET_GROUP_ID)],
      subscribeTo: "datapoint",
    }),
  };
```
while the underlying POST request concerns subscription to a websocket (see Sect. 7.5.2). Thus, the objective is to obtain (cf. subscribeTo) the values of Datapoints and calculated Datapoints of KIS.Devices associated with assetIds and assetGroupIds. Note that the last property is not compulsory for obtaining Datapoint values. Subsequently, let us assume that both incoming and outgoing heart-beating is set to 1000 ms. Having all the above ingredients, the final code is developed, which is mostly included in the getSubscriptionId function:

```
require("dotenv").config();
const WebSocket = require("websocket").w3cwebsocket,
webstomp = require("webstomp-client");
const axios = require("axios");
const heartbeat = 1000;
const getSubscriptionId = () => {
  const options = {
    method: "POST",
    url: process.env.SERVER_URL,
    headers: {
    "X-API-KEY": process.env.API_KEY,
    "X-CLIENT-ID": process.env.CLIENT_ID,
    "Content-Type": "application/json",},
    data: JSON.stringify({
      assetIds: [parseInt(process.env.ASSET_ID)],
      assetGroupIds: [parseInt(process.env.ASSET_GROUP_ID)],
      subscribeTo: "datapoint",
    }),
  };
axios(options)
  .then(function (response) {
      const subscriptionId=response.data.subscriptionId;
      const Server=
      response.data.subscriptionUris[0].replace("///","//");
      const socket = new WebSocket(Server, null);
      const stomp = webstomp.over(socket, {
        heartbeat: {incoming: heartbeat, outgoing: heartbeat},
        protocols: ['v12.stomp'],
      });
    stomp.connect(
      {host: Server},
      function () {
      stomp.subscribe('/topic/${subscriptionId}',
      function (message) {
          const data = JSON.parse(message.body);
          console.log("Message data",data.info);
        });
      },
    );
```

```
})
  .catch(function (error) {
    console.log(error);
  })
  .finally(function () {
    // always executed
});
};
getSubscriptionId();
```
The example considered is a continuation of the ones exploited in this chapter for which the KIS.BOX (assetIds=10102) Button 1 operational LED color switches between red and black. The above KIS.BOX has also associated calculated Datapoint and KPI. After running the above code, one can observe that message.body contains the JSON structure, which may look as follows:

```
{"jsontype":"centersightEvent",
"type":"datapointValuesReceived",
"nodeId":10102,"timestamp":"2022-10-06T10:47:47.833Z",
"info":{"key":"button1Color","value":"#000000",
"timestamp":"2022-10-06T10:47:47.833Z"}}
```
The above JSON structure is self-explained and it can be easily observed that it contains the info property, which covers another JSON structure involving

key: the name of the (calculated) Datapoint, value: the value of the (calculated) Datapoint, timestamp: the timestamp associated with the value of the (calculated) Datapoint,

and hence, this structure is directly displayed in the console. Note that the above code can be easily adapted to the remaining possible settings of subscribeTo, i.e., kpi and rule. However, such an implementation is left out to be featured an exercise listed in the last section of this chapter.

# **•** *>* **Getting information about the rules**

Contrarily, to KPIs and Datapoints, rules are directly associated with asset groups. Indeed, there are designed within each asset group. This implies the necessity of a reduced subscription data:

```
{
   assetGroupIds: [parseInt(process.env.ASSET_GROUP_ID)],
   subscribeTo: "rule",
}
```
while assetIds is excluded.

### **Publishing KIS.ME data with a local Web server**

The objective of this example is to extend the proceeding one in such a way as to provide the following functionalities:


Let us start with selecting an API. Since the purpose of the example is to collect the data in the form of a JSON structure containing three properties (key, value and timestamp) the list of possible candidates is rather long. Thus, due to relative usage simplicity, the Pusher API was selected (https://pusher.com/). As was the case with KIS.API, the first step is to register with Pusher and then collect the list of credentials (App keys). A sample list of Pusher credentials is given as follows:

```
app_id = "1482901"
key = "8e17772867a31d055131"
secret = "b2632afdbd8419d40bf1"
cluster = "eu"
```
Thus, let us extend the .env file with the above data, which yields

```
SERVER_URL="https://api.kisme.com/kisapi/v1"
API_KEY="2b84bd4de38b4e92bb7bb283364477e1"
CLIENT_ID="708ce7cc-fd57-416d-991f-f68704385c22"
ASSET_ID="10102"
ASSET_GROUP_ID="9758"
app_id = "1482901"
key = "8e17772867a31d055131"
secret = "b2632afdbd8419d40bf1"
cluster = "eu"
```
Having the above information, let us simply extend the code from the previous example with a list of commands creating a Pusher instance:

```
const Pusher = require("pusher");
const pusher = new Pusher({
  appId: "1482901",
  key: process.env.key,
  secret: process.env.secret,
  cluster: process.env.cluster,
});
```
Now let us assume that the Datapoint of interest is called button1ColorKpi Duration (see Appendix. B for its description). Thus, the transfer of Datapoint values to the Pusher API reduces to the following:

```
if (data.info.key=="button1ColorKpiDuration")
 pusher.trigger("b1ColorKpiDuration", "b1ColorKpiDuration",
  {
     value: JSON.stringify(data.info),
  });
```
where b1ColorKpiDuration signifies both the so-called channel and event (see https://www.npmjs.com/package/pusher for a detailed explanation). The preparation of the backend concludes with including the code for the local Web server. For that purpose the express module is used, which can be simply characterized as a lightweight NODE.js Web server. The entire code reduces to adding the following lines:

```
const express = require("express");
const app = express();
app.use(express.static(__dirname + '/public'));
app.listen(3000, () => {
  console.log("Server running on: http://localhost:3000/");
});
```
which are responsible for creating an express Web server that will run on port 3000 and will communicate with server static files located in the public directory. Finally, the entire backend code can be implemented as follows:

```
require("dotenv").config();
const WebSocket = require("websocket").w3cwebsocket,
webstomp = require("webstomp-client");
const axios = require("axios");
const Pusher = require("pusher");
const pusher = new Pusher({
  appId: "1482901",
  key: process.env.key,
  secret: process.env.secret,
```

```
cluster: process.env.cluster,
});
const heartbeat = 1000;
const getSubscriptionId = () => {
  const options = {
    method: "POST",
    url: process.env.SERVER_URL,
    headers: {
    "X-API-KEY": process.env.API_KEY,
    "X-CLIENT-ID": process.env.CLIENT_ID,
    "Content-Type": "application/json",},
    data: JSON.stringify({
      assetIds: [parseInt(process.env.ASSET_ID)],
      assetGroupIds: [parseInt(process.env.ASSET_GROUP_ID)],
      subscribeTo: "datapoint",
    }),
  };
axios(options)
  .then(function (response) {
      const subscriptionId=response.data.subscriptionId;
      const Server=
      response.data.subscriptionUris[0].replace("///","//");
      const socket = new WebSocket(Server, null);
      const stomp = webstomp.over(socket, {
        heartbeat: {incoming: heartbeat, outgoing: heartbeat},
        protocols: ['v12.stomp'],
      });
    stomp.connect(
      {host: Server},
      function () {
      stomp.subscribe('/topic/${subscriptionId}',
      function (message) {
          const data = JSON.parse(message.body);
          if (data.info.key=="button1ColorKpiDuration")
          pusher.trigger("b1ColorKpiDuration",
          "b1ColorKpiDuration",
          {
            value: JSON.stringify(data.info),
          });
        });
      },
    );
  })
  .catch(function (error) {
    console.log(error);
```

```
})
  .finally(function () {
    // always executed
});
};
getSubscriptionId();
const express = require("express");
const app = express();
app.use(express.static(__dirname + '/public'));
app.listen(3000, () => {
  console.log("Server running on: http://localhost:3000/");
});
```
Let us proceed to the frontend development by creating the public directory and the index.html file inside it. The presentation of Datapoint values will be reduced to showing its consecutive values in the form of a plot. For that purpose the well known plotly is employed. Thus, the entire frontend reduces to the following code:

```
<!DOCTYPE html>
<html>
<head>
 <meta http-equiv="content-type" content="text/html;
    charset=UTF-8" />
 <script src="https://cdn.plot.ly/plotly-latest.min.js">
 </script>
 <script src="https://js.pusher.com/7.2.0/pusher.min.js">
 </script>
</head>
<body>
 <div id="chart"></div>
<script>
 Pusher.logToConsole = true;
 var my_plot = {
  y: [],
  mode: 'lines+markers',
  name: 'hv',
  line: {shape: 'hv'},
  type: 'scatter',
 };
 Plotly.newPlot('chart', [my_plot]);
 const pusher = new Pusher(
    "8e17772867a31d055131", // Replace with your 'key'
    { cluster: "eu", }
 );
 const channel = pusher.subscribe("b1ColorKpiDuration");
```
The main part of the code starts with creating an empty plot located in the chart section of the HTML document (newPlot). Subsequently, a new Pusher instance is created with the above-defined credentials named key and cluster. This enables forming a new channel b1ColorKpiDuration. Finally, the channel.bind command is responsible for receiving cyclically arriving Datapoint values. It also invokes the extendTrace command, which updates the existing plot with the new data. Note that the plot is restricted to presenting 23 most up to date values, which requires appropriate scaling realized with the relayout command. The graphical result obtained after running the entire application, i.e. the one presented in the browser, is given in Fig. 7.8.

# **7.6 Training Exercises**


### **7.4** Obtaining a list of Datapoints and CDPs


### **7.6** Obtaining values of KPIs


**7.8** Triggering rules from an external application

	- GoRed: with an action setting the KIS.LIGHT operational LED color to red;
	- GoGreen: with an action setting the KIS.LIGHT operational LED color to red;

### **7.7 Concluding Remarks**

The aim of this section was to provide an overview of KIS.API functionalities. It was demonstrated that the software provides an effective way for communicating with external applications. In particular, the chapter started with KIS.API user registration and goes through KIS.API essential functionalities. These functionalities are strictly linked with the content of the preceding chapter. Indeed, it is shown how to prepare request for accessing the information about assets, asset groups, users, Datapoints, CDPs, KPIs as well as the rules. The crucial functionality, which makes KIS.API a fully bidirectional framework is the ability of triggering the rules from external applications. In particular, it was shown how to trigger such rules from Matlab, which is one of the most popular development tools in modern engineering. The last part of the chapter was devoted to the development of efficient websocket-based communication framework, which utilizes STOMP messaging architecture. Indeed, the websocket is an excellent for providing an efficient asynchronous bidirectional communication. It was also demonstrated how to prepare a local Web server for publishing Datapoint values. This crucially example clearly shows that with KIS.API there is an infinite spectrum of possible external extensions of KIS.ME. Finally, the chapter is summarized with a set of training exercises, which verify KIS.API-oriented skills.

# **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.

# **Appendix A KIS.ME Commands and Their Sample Applications**

The objective of this appendix is to provide a comprehensive overview of the KIS.ME commands, which can be utilized while implementing KPIs and CDPs. They are divided into five groups, and their application range is given in TableA.1. This clearly means that Aggregations and Intervals can be used while implementing KPIs only. The list of numeric commands contains essential operations like Plus, Time, Power, Round and Abs, which are very basic, and hence their description is omitted. Similarly, the comparison commands do not require special explanations, either.

### **A.1 Aggregations**

See Table A.2.

$$\mathbf{y} = \mathbf{Count}[x] \tag{A.1}$$



© The Editor(s) (if applicable) and The Author(s) 2023 M. Witczak et al., *Modern IoT Onboarding Platforms for Advanced Applications*, Studies in Systems, Decision and Control 476, https://doi.org/10.1007/978-3-031-33623-2


**Table A.2** Count: input and output arguments

**Table A.3** Count: KPI parameters


Illustrative example: The worker assembles products on a workstation. The fact of a well-assembled product is signalized with a blink of a green light of the KIS.LIGHT operational LED. Contrarily, the fact of an inappropriately assembled product is signalized with the KIS.LIGHT operational LED flashing in red. Note that the idle state color of the KIS.LIGHT operational LED is black. The objective is to calculate the percentage number of well-assembled products within a selected processing period. Hint: See numerical values of the red and green colors in Table 2.2. Solution:

Step 1. Define a new KPI and its parameters according to TableA.3: Step 2. Output calculation:

```
xg=If[x==3,1,0];
yg=Count[Filter[xg>0]];
xr=If[x==5,1,0];
yr=Count[Filter[xr>0]];
total=yg+yr;
y=yg*100/total;
```
See Table A.4.

*y* = **FallingEdge**[*x, n*]*, y* = **FallingEdge**[*x*] (A.2)


**Table A.4** FallingEdge: input and output arguments



Illustrative example: Let us consider a worker performing tasks on a single workstation. If a product assembly is accomplished, then the worker presses KIS.BOX Button 1. The KIS.BOX Button 1 operational LED is normally illuminating in green (numerical value 3), but there is a rule which, after pressing KIS.BOX Button 1, changes this color into black (numerical value 0), and then again to green. The objective is to calculate the number of assembled products within a selected processing period. Solution:

Step 1. Define a new KPI and its parameters according to TableA.5: Step 2. Output calculation:

y=FallingEdge[x,3];

See Table A.6.

*y* = **Max**[*x*1*,..., xn*] (A.3)


**Table A.6** Max: input and output arguments

**Table A.7** Max: KPI parameters


Illustrative example: Let us consider an assembly station with one worker, which is associated with KIS.BOX Button 1. Let us assume that there are suitable rules, and hence, if the worker is in an idle state, then the KIS.BOX Button 1 operational LED is black (it is not lighting, the black color numerical value is equal to 2). Calculate the range (in minutes) of idle state periods, i.e., the difference between the maximum and minimum idle state cycles, within a selected processing period. Solution:

Step 1. Define a new KPI and its parameters according to TableA.7: Step 2. Output calculation:

```
idle=If[x==2,Duration[x],0]/60000;
z=Filter[idle>0];
y=Max[z,z]-Min[z,z];
```


**Table A.8** Mean: Input and output arguments

**Table A.9** Mean: KPI parameters


See Table A.8.

*y* = **Mean**[*x*] (A.4)

Illustrative example: Let us imagine that the KIS.LIGHT operational LED color is used for indicating the state of a worker. In particular, the magenta color (numerical value equal to 4) signifies the fact that the worker is performing some tasks while the black one expresses an idle state. The objective is to calculate an average working time (in minutes) within a selected processing period. Solution:

Step 1. Define a new KPI and its parameters according to TableA.9: Step 2. Output calculation:

```
working=If[x==4,Duration[x],0]/60000;
y=Mean[Filter[working>0]];
```
See Table A.10.

*y* = **Min**[*x,..., xn*] (A.5)


**Table A.10** Min: Input and output arguments

**Table A.11** Min: KPI parameters


Illustrative example: Let us consider an assembly station with one worker, which is associated with KIS.BOX Button 1. Let us assume that there are suitable rules, and hence, if the worker is in an idle state, then the KIS.BOX Button 1 operational LED is black (it is not lighting, the black color numerical value is equal to 2). Calculate the minimum (in minutes) idle state period within a selected processing cycle. Solution:

Step 1. Define a new KPI and its parameters according to TableA.11: Step 2. Output calculation:

```
idle=if[x==2,Duration[x],0];
z=Filter[idle>0];
y=Min[z,z]
```
See Table A.12.

*y* = **Percentile**[*x, n*] (A.6)

Illustrative example: Let us imagine that the KIS.LIGHT operational LED color is used for indicating the state of a worker. In particular, the magenta color (numerical value equal to 4) signifies the fact that the worker is performing some tasks while


**Table A.12** Percentile: Input and output arguments

**Table A.13** Percentile: KPI parameters


the black one expresses an idle state. The objective is to calculate a median working time (in minutes) within a selected processing period. Hint: The median value is the 50th percentile.

Solution:

Step 1. Define a new KPI and its parameters according to TableA.13: Step 2. Output calculation:

> working=If[x==4,Duration[x],0]/60000; y=Percentile[Filter[working>0],50];

See Table A.14.

*y* = **RisingEdge**[*x, n*] **or** *y* = **RisingEdge**[*x*] (A.7)

Illustrative example: A set of parts is supplied to a single workstation by a conveyor belt. Such a situation is indicated be feeding KIS.LIGHT digital input 1 with a false– true–false sequence. The objective is to calculate the number of sets of parts supplied within a selected processing period.


**Table A.14** RisingEdge: Input and output arguments

**Table A.15** RisingEdge: KPI paramters


**Table A.16** Stdev: Input and output arguments


Solution:

Step 1. Define a new KPI and its parameters according to TableA.15.

Step 2. Output calculation:

```
y=RisingEdge[x];
```
See Table A.16.

*y* = **Stdev**[*x*] (A.8)


**Table A.17** Stdev: KPI parameters

**Table A.18** Sum: Input and output arguments


Illustrative example: Let us imagine that the KIS.LIGHT operational LED color is used for indicating the state of a worker. In particular, the magenta color (numerical value equal to 4) signifies the fact that the worker is performing some tasks while the black one expresses an idle state. The objective is to calculate a standard deviation of the working time (in minutes) within a selected processing period. Solution:

Step 1. Define a new KPI and its parameters according to TableA.17: Step 2. Output calculation:

```
working=If[x==4,Duration[x],0]/60000;
y=Stdev[Filter[working>0]];
```
See Table A.18.

*y* = **Sum**[*x*] (A.9)

Illustrative example: Let us imagine that KIS.LIGHT operational LED color is used for indicating the state of a worker. In particular, the magenta color (numerical value equal to 4) signifies the fact that the worker is performing some tasks while the black one expresses an idle state. The objective is to calculate the total working time (in minutes) within a selected processing period.


**Table A.19** Sum: KPI parameters

Solution:

Step 1: Define a new KPI and its parameters according to TableA.19 Step 2: Output calculation

y=Sum[If[x==4,Duration[x],0]]/60000;

# **A.2 Intervals**

See Table A.20.

*y* = **End**[*x*]*, y* = **Start**[*x*] (A.10)

Illustrative example: A worker performs assembly tasks, which are associated with the following KIS.LIGHT operational LED colors:



**Table A.20** Start/End: Input and output arguments


**Table A.21** Count: KPI paramters

**Table A.22** Duration: input and output arguments


Calculate the total mounting time (in minutes) within a selected processing period. Solution:

Step 1. Define a new KPI and its parameters according to TableA.21: Step 2. Output calculation:

> dx=If[x==3||x==5,End[x]-Start[x],0]; y=Sum[dx]/60000;

See Table A.22.

*y* = **Duration**[*x*] (A.11)

Illustrative example: A worker performs assembly tasks associated with the following KIS.LIGHT operational LED colors:


Calculate the ratio between the total cell and controller mounting times within a selected processing period.


**Table A.23** Duration: KPI parameters

**Table A.24** Interval: Output arguments


Solution:

Step 1. Define a new KPI and its parameters according to TableA.23:

Step 2. Output calculation:

```
dg=Sum[If[x==3,Duration[x],0]];
dr=Sum[If[x==5,Duration[x],0]];
y=dg/dr;
```
See Table A.24.

*y* = **Interval**[] (A.12)

Illustrative example: Let us imagine that the KIS.LIGHT operational LED color is used for indicating the state of a worker. In particular, the magenta color (numerical value equal to 4) signifies the fact that the worker is performing some tasks while the black one expresses an idle state. The objective is to find the percentage of the working state within a selected processing period. Solution:

Step 1. Define a new KPI and its parameters according to TableA.25: Step 2. Output calculation:

y=Sum[If[x==4,Duration[x],0]]/Interval[]\*100;


**Table A.25** Interval: KPI paramters

### **A.3 Numeric**

The list of numeric commands contains essential operations like Plus, Time, Power, Round and Abs, which are very basic, and hence their description is omitted.

See Table A.26.

*y* = **Mod**[*x, n*] (A.13)

Illustrative example: Let us imagine that the tasks realized by two machines are indicated via the KIS.LIGHT operational LED that illuminates in task-oriented colors. In particular, the colors with even numeric values (cf. Table 2.2) are associated with the tasks of the first machine. Contrarily, the jobs realized by the second machine are identified by the colors with odd numeric values. The objective is to calculate the ratio between the total number of tasks realized by the machines. Hint: Filter all values, which are numeric values indicated in Table 2.2. Solution:

Step 1. Define a new KPI and its parameters according to TableA.27: Step 2. Output calculation:


**Table A.26** Mod: Input and output arguments


**Table A.27** Mod: KPI parameters

**Table A.28** Bit: Input and output arguments


```
dx=Filter[x<8];
even=Sum[If[Mod[x,2]==0,1,0]];
odd=Sum[If[Mod[x,2]==1,1,0]];
y=even/odd;
```
# **A.4 Miscellaneous**

See Table A.28.

```
y = Bit[x, n] (A.14)
```
Illustrative example: The colors of the KIS.LIGHT operational LED are associated with the tasks realized by two groups of workers. The third bit of the numerical color values associated with the first group is equal to 1. Contrarily, the same bit is equal to 0 for the second group of the color numerical values. The objective is to implement a CDP which will return 1 for the tasks associated with the first group and 0 otherwise. Solution:

Step 1. Define a new CDP and its parameters according to TableA.29: Step 2. Output calculation:


**Table A.29** Bit: CDP parameters

**Table A.30** Counter: CDP parameters


xf=Filter[x<8]; y=Bit[xf,3];

```
y = Counter[x, b] (A.15)
```


Illustrative example: The objective is to calculate the difference between consecutive numerical values of the KIS.LIGHT operational LED colors (Table A.30.). Solution:

Step 1. Define a new CDP according to TableA.30: Step 2. Output calculation:

y=Counter[x,0];


**Table A.31** If: Input and output arguments

**Table A.32** If: CDP parameters


See Table A.31.

*y* = **If**[*x, a, b*] (A.16)

Illustrative example: The colors of the KIS.BOX Button operational LEDs are associated with the tasks realized by two group of workers. Implement a CDP calculating the current minimum of the numerical values associated with these operational LEDs. Solution:

Step 1. Define a new CDP and its parameters according to TableA.32: Step 2. Output calculation:

z=If[x<y,x,y];

See Table A.33.

*y* = **Filter**[*c*] (A.17)


**Table A.33** If: Input and output arguments

**Table A.34** Filter: KPI parameters


Illustrative example: The colors of the KIS.LIGHT operational LED indicate the tasks realized by an assembly station. Calculate the total time of tasks associated with the red color which are longer than two minutes. Perform calculation within a desired processing period. Solution:

Step 1. Define a new KPI and its parameters according to TableA.34: Step 2. Output calculation:

```
d=If[x==5,Duration[x],0];
y=Sum[Filter[d>2*60000]];
```
# **Appendix B KIS.ME Datapoints and Their Sample Applications**

### **button1ColorKPIDuration** (B.1)

Description: A long type Datapoint associated with the KIS.BOX Button 1 operational LED. It contains information about the evolution of the color states of the button as well as their durations. A similar Datapoint is associated with the KIS.BOX Button 2 operational LED and is called button2ColorKPIDuration.

Illustrative examples:

KPI: There are two tasks associated with two colors of the KIS.BOX Button 1 operational LED, i.e., blue (numerical value 0) and green (numerical value 3). The objective is to obtain the durations of states corresponding to these colors and find the maximum one (in minutes) within a selected processing period.

CDP: There are two workers associated with KIS.BOX Buttons 1 and 2. Their idle state is signified by the green color of the respective operational LED. The objective is to implement an indicator routine, which will return 1 when both workers are in the idle state and 0 otherwise.

KPI solution:

Step 1. Define a new KPI and its parameters according to TableB.1:

Step 2. Output definition:

```
blue = If[x==0,Duration[x],0];
green = If[x==3,Duration[x],0];
y = Round[Max[blue,green]/60000];
```


**Table B.1** Maximum duration KPI parameters

**Table B.2** Idle state CPD parameters


CDP solution:

Step 1. Define a new CDP and its parameters according to TableB.2

### Step 2. Output definition:

idle=If[x1==3 && x2==3,1,0]


Description: A long type Datapoint associated with the KIS.BOX Button 1 operational LED. It contains information about the evolution of the color states of the button. A similar Datapoint is associated with the KIS.BOX Button 2 operational LED and is called button2ColorKPI.

Illustrative example:

CDP: It is possible that during the transient between the color states the value of button1ColorKPI may be outside the admissible color range (cf. Table 2.2). The objective is to implement a routine eliminating such values.


**Table B.3** Admissible colors CDP parameters

**Table B.4** Minimum task number KPI parameters


KPI: Use the results provided by the above CDP to calculate the number of realized tasks, which are associated with two colors of the KIS.BOX operational LED. These are blue (numerical value 0) and green (numerical value 3). Finally, determine the minimum number of tasks realized by these two groups within a desired processing period.

CDP solution:

Step 1. Define a new CDP and its parameters according to TableB.3: Step 2. Output definition:

```
res=Filter[x<=7];
```
KPI solution:

:


blue=Sum[If[x == 0, 1, 0]]; green=Sum[If[x == 3, 1, 0]]; y = Min[blue,green];


**Table B.5** Minimum number of tasks KPI parameters


Description: A Boolean type Datapoint associated with KIS.BOX Button 1. It contains information about the states related to pressing this button, which are equivalent to the logical truth. A similar Datapoint is associated with KIS.BOX Button 2 and is called button2Pressed.

Illustrative example: There are two workers which are associated with KIS.BOX Buttons 1 and 2. Each of them presses the respective button after realizing a given task. The objective is to implement a routine calculating the minimum number of tasks realized by either worker within a selected processing period. Solution:

Step 1. Define a new KPI and its parameters according to TableB.5: Step 2. Output definition:

Total=Min[Sum[If[x1,1,0]],Sum[If[x2,1,0]]];

**isOnline** (B.4)

Description: A Boolean type Datapoint associated with a KIS.Device, which contains information about its online states, i.e., connection toWiFi, along with their durations.


**Table B.6** Total online duration KPI parameters

Illustrative example: Calculate the total duration (in minutes) of online states of KIS.Device within a desired processing period. Solution:

Step 1. Define a new KPI and its parameters according to TableB.6: Step 2. Output KPI definition:

```
y = Round[Sum[If[x, Duration[x], 0]]/60000];
```
### **led1ColorKPIDuration** (B.5)

Description: A long type Datapoint associated with the KIS.LIGHT operational LED. It contains information about the evolution of the color states of this LED as well as their durations.

Illustrative example: A machine performs an assembly process, which is signified by the blue color (numerical value 0) of the KIS.LIGHT operational LED. If the assembly is completed, then the color is changed into red (numerical value 5). The objective is to calculate a median duration (in minutes) of realizing the tasks indicated by the blue color within a selected processing period. Hint.: The median value corresponds to the 50th percentile.

Solution:

Step 1. Define the new KPI and its parameters according to TableB.7: Step 2. Output KPI definition:

```
colorBlue=If[x==0,Duration[x],0]/60000;
y=Percentile[Filter[colorBlue>0],50];
```


**Table B.7** Median duration KPI parameters

**Table B.8** Even and odd tasks KPI parameters


**ledColorKPI** (B.6)

Description: A long type Datapoint associated with the KIS.LIGHT operational LED. It contains information about the evolution of the color states of this LED.

Illustrative example: The KIS.LIGHT operational LED indicates tasks realized by two workers. In particular, the colors with even numerical values are assigned to the tasks realized by the first worker while those with odd ones are associated with the second one. The objective is to calculate the ration between the total number of tasks realized within a selected processing period.

Solution:

Step 1. Define a new KPI and its parameters according to TableB.8,

Step 2. Output definition:

```
x=Filter[x1<=7];
even=Sum[If[Mod[x,2]==0,1,0]];
odd=Sum[If[Mod[x,2]==1,1,0]];
y=even/odd;
```


**Table B.9** FPY KPI parameters


Description: A Boolean type Datapoint, which corresponds to the state of KIS.Device digital input 1. A similar Datapoint is defined for the second digital input and is called input2Status.

Illustrative example: Let us imagine a quality control process. If a product passes the quality control test, then KIS.Device digital input 1 is fed with the sequence false– true–false. Contrarily, if the product fails this test, then KIS.Device digital input 1 is fed with such a sequence. The objective is to calculate FPY (cf. (4.3)) related to the quality control process within a selected processing period

Solution:

Step 1. Define the new parameters according to TableB.9:

Step 2. Output KPI definition:

```
NumberPassed = RisingEdge[x1];
NumberFailed = RisingEdge[x2];
Total = NumberPassed + NumberFailed;
FPY = If[Total>0,Round[NumberPassed/Total*100],0];
```
### **output1Status** (B.8)

Description: A Boolean type Datapoint, which corresponds to the state of KIS.Device digital output 1. A similar Datapoint is defined for the second digital output and is called output2Status.


**Table B.10** Total mounting task number KPI parameters

Illustrative example: A worker performs two tasks, i.e., the controller and frame mounting ones. If the first one is completed, then KIS.Device digital output 1 is fed with the false–true–false sequence. Similarly, if the second task is completed, then KIS.Device digital output 2 is fed with the same sequence. The objective is to calculate the total number of realized tasks within a selected processing period.

KPI Solution:

Step 1. Define new KPI parameters according to TableB.10: Step 2. Output KPI definition:

> Frames = FallingEdge[x1]; Controllers = FallingEdge[x2]; y=Frames+Controllers;

# **Appendix C Glossary**



# **Index**

### **A**

Access control, 79 external hardware/software, 82 general, 79 identification command, 82 individual, 79 reset command, 82 Adding a new user, 28 Adding asset groups, 26 Adding dashboard, 39 Admin, 26 Admin and workspaces, 30 Admin user, 24, 72 Aggregation, 118 Agriculture and environmental applications, 6 Assembly line stations, 96 Asset, 277 assigning to a group, 34 binary state, 41 certificate, 39 changing name, 34 device information, 37 digital input, 41 digital output, 41 firmware update, 39 group relationship graph, 37 hardware, 39 info, 34 management, 33 network, 39 software, 39 time drive, 41, 42, 52 Asset group, 25, 277 adding, 26

time drive, 52 Assigning user rights, 28 Assigning users to a group, 32 Associativity of conjunction:, 62 Associativity of disjunction, 62 Automated guided vehicle, 194

### **B**

BaseUrl, 213 Bit, 264 Button1ColorKPI, 270 Button1ColorKPIDuration, 269 Button1Pressed, 272 Button2ColorKPIDuration, 269 Button2Pressed, 272

### **C**

Calculate Datapoints (CDP), 278 sharing, 131 Changing WLAN, 25 Chart *x*¯, 150 Datapoint, 45 Commutativity of conjunction, 62 Commutativity of disjunction, 62 Container capacity, 99 Contraposition law, 62 Count, 252 Counter, 265

© The Editor(s) (if applicable) and The Author(s) 2023 M. Witczak et al., *Modern IoT Onboarding Platforms for Advanced Applications*, Studies in Systems, Decision and Control 476, https://doi.org/10.1007/978-3-031-33623-2

### **D**

Dashboard, 277 Datapoint, 11, 24, 44, 45, 277 Datapoint chart, 45 analyzing data, 48 multiple plots, 45 storing data, 48 Datapoint chart widget, 39 Data sheet widget, 39 Decision table, 61 Defect per unit significance, 173 Demerit number, 171 Demerit system, 171 De Morgan's law, 62 Digital twin, 277 design, 41 Digital twin widget, 39, 41 Discrete event system, 235 Distribution location, 132 shape, 132 variability, 132 Distributivity of conjunction, 62 Distributivity of disjunction, 62 Double negation, 62 Duration, 261

### **E**

End, 260

### **F**

FallingEdge, 253 Fault, 205 Fault-tolerance, 201, 205 Filter, 267 First Pass Yield (FPY), 127 FLEX language, 117 Floorplan, 23, 277 SVG, 50 Floorplan widget, 49 headline, 52 Full duplex, 235

### **G**

General Purpose Input Output (GPIO), 23 Group relationship graph, 37

### **H**

Histogram, 146 bin calculation, 147 grouping, 147 Hospitality and leisure industry, 7 Human–Machine Interface (HMI), 21

### **I**

Idempotency of conjunction, 62 Idempotency of disjunction, 62 If, 266 IF-THEN rules, 23 Industrial applications, 4 Info widget, 39 Initial state, 28 Input1Status, 275 Input2Status, 275 Installer, 26 Interval, 262 Inventory asset group, 26 isOnline, 272

### **J**

Just-in-time strategy, 96

### **K**

Kanban, 98 number, 98 Key Performance Indicator (KPI), 11, 24, 41, 50, 125, 278 sharing, 131 KIS.API, 211, 277 actions, 212 asset group requests, 215 asset requests, 215 calculated Datapoints, 223 credentials, 213

### Index 281

Datapoints, 220 enabledAPI, 229 Excel, 229 identifier, 212 KPIs, 223 Matlab, 231 path variables, 214 registration and authorization, 212 representation, 211 resources, 211 rules, 227 rule trigger, 228 status code, 212 subscription, 237 user requests, 219 KIS.BOX, 277 KIS.Device, 277 KIS.LIGHT, 277 KIS.MANAGER, 277 KIS.ME demo, 25 KPI aggregated chart widget, 41, 135 KPI pie chart widget, 41, 136 KPI single period chart widget, 41, 136 KPI single value column widget, 41, 135 KPI single value widget, 41

### **L**

Led1ColorKPIDuration, 273 LedColorKPI, 274 Linguistic objects, 54 Long polling, 235 Lower Control Limit (LCL), 149

### **M**

M12 8-pin, 23 Material shortages, 98 MATLAB rule triggering, 233 Matlab Datapoints, 231 webread, 232 Max, 254 Mean, 255 assembly durations, 135 Median, 132, 133 Message Queuing Telemetry Transport (MQTT), 24

Messaging, 237 Milk run logistics, 95 Min, 256 Mod, 263 MS Excel power query, 229 My devices, 26

### **N**

Negation, 61 Notification templates, 55 variables, 55

### **O**

Observer, 26 Onboarding, 24, 277 onboarding.zip, 24 procedure, 24 Operator, 26 Output1Status, 275 Output2Status, 275 Overall Equipment Effectiveness (OEE), 11, 177

### **P**

Parts containers, 97 Percentile, 133, 257 Process, 132, 277 in control, 133 out of control, 133 Processing period, 117, 224, 277 Pusher, 242

### **R**

Range, 133 Rights and permissions, 28 RisingEdge, 258 Rule action, 54 antecedent, 54

automatic simplification, 64 consequents, 54 inconsistency, 65 reduction principle, 66 redundancy, 65 Rule base completeness, 67 Rule-based system, 54 Rule engine, 12, 23, 54, 278 actions, 55 conditions, 55 device action, 55 inference, 55 initial condition, 57 rule interactions, 58 triggers, 55

### **S**

Safety stocks, 98 Secure authentication, 24 Security, 24 Simple Text-Oriented Messaging Protocol (STOMP), 237 heart-beating, 238 Standard deviation, 133 assembly durations, 135 State, 278 State-space model, 58 Statistical control state, 145 Status LED, 21 Stdev, 258 Streaming, 235 Sum, 259 Supermarket, 96 Supermarket points, 96 SVG, 50 System, 277 rule-based, 54 state, 58 state-space, 58 state-space model, 58

### **T**

Tautology, 61

Traffic lights, 59 Transfer constraint, 205 Trigger logistic objects, 55 optional settings, 55 Truth tables, 62

### **U**

Unique Resource Name, 19 Upper Control Limit (UCL), 149 User, 278 User group, 24, 25, 278 membership, 26 User group permissions, 32

### **V**

Variance, 133 Variation common cause, 133 special cause, 133

### **W**

Warehouse management system, 89 Websocket, 234, 278 Widget, 39, 278 floorplan, 49 WiFi parameters, 24 WiFi fingerprint, 7 Workspace, 25, 278

### **Z**

Zone, 105 floorplan, 105 identification, 107