Joao Giao

João Sarraipa

CTS, UNINOVA, Dep. Ricardo Jardim-Gonçalves

Joao Sarraipa

Open Modular Components in the Industry Using vf-OS Components

Keywords: Industry, IoT, Sensor, vf-OS

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

An increasing number of heterogeneous smart objects communicate and interconnect through the internet. However, to use the full potential of these smart objects, it is necessary to transcend the interoperability issues between them. In the past years, there has been efforts to overcome this issue at system and network level. At system level, there can be a lack of system's interoperability, which makes necessary rewriting the software code for every new smart component that is inserted into the old system. At the network level, the smart components cannot communicate with each other because they have different interfaces and API protocols to interconnect with the surrounding environment [START_REF] Rosenkranz | A Distributed Test System Architecture for Open-source IoT Software[END_REF].

Nowadays, it has been emerged a transversal discipline called CPS (Cyber Physical Systems), which integrates various intelligent components that has helped software architects and designers to deal with complex and difficult systems. CPS are combinations of computations and physical processes that enable the control of physical processes with computing and communication infrastructures [START_REF] Derler | Modeling Cyber-Physical Systems[END_REF] [START_REF] Jazdi | Cyber physical systems in the context of Industry 4.0[END_REF]. CPS allows sensors and actuators to be controlled by a control unit, usually composed by more than one microcontroller, where physical processes affect computations and in the other way around as well. The design of these systems requires from experts a complete knowledge about the computers dynamics (e.g. software or networks) and the physical processes to deal with big and complex data flows. In order to ease the development and deployment of new services that use such kind of data processes, smaller operating systems have been developed to help in the building of applications that use IoT devices, like the vf-OS (Virtual Factory Open Operating System). The vf-OS system has been developed by the European Commission co-funded project called vf-OS [START_REF]Vf-OS, vf-OS consortium[END_REF]. vf-OS provides the necessary software tools to connect a factory and their internal devices by managing a factory related computer hardware and software resources, providing mutual services for factory computational programs.

Therefore, the main research question that emerges is: Can modular systems contribute to the development and deployment of CPS in manufacturing systems?

One additional motivation is to use open-source software to speed up the software development and minimize the costs. As such, this paper proposes an architecture that explores the potential usage of open source software components applied in the industry, using some of the vf-OS system components already available. Accordingly to the Open Source Initiative [START_REF]Open Source Definition[END_REF], an open source software is a software that can be used without costs, changed and shared with anyone. Additionally, IoT components together with open standard protocols, can both assure interoperability and hence present a unified and a stable software infrastructure.

Related Literature

In smart factories, condition monitoring systems (CMS) represent the business logic that monitor the state variables and create diagnostics of current and future factory' errors. However, most factories have several tasks depending on the associated production machine or process, which results in varying the requirements for cyberphysical computing architectures. Notwithstanding, in [START_REF] Fleischmann | A Modular Architecture for the Design of Condition Monitoring Processes[END_REF] the authors proposed a general processing steps for CMS: (1) State detection -measuring and store machine parameters that represent the current status of the factory. For this stage, sensors are used for monitoring and quality assurance; (2) State comparison -comparison of the current data with predetermined nominal data. After data collection from, eg., sensors from loads, temperatures, machine parameters and environment conditions, these values are compared with the manufacturer machine supervisor. This state relates with CPS, by having multiple types of sensors for perceiving the factory' environment and efficient mechanisms to process information and send events when is necessary; (3) Diagnosis -Specific error diagnostics. Based on the previous states, it is possible to detect potential errors or anomalies.

CPS Architectures

A CPS model contains models of software and physical processes, intelligent computation platforms and networks. It requires a multi-disciplinary development, not only on the distinct computational and physical components, but also on their integration and interaction. Accordingly to [START_REF] Baheti | Cyber-physical Systems, from : The Impact of Control Technology, available at www[END_REF], CPS research has been focused on identifying needs, challenges and industrial sectors opportunities, encouraging multidisciplinary collaborative research between academia and industry. The main goal between this synergy is the development of new engineering techniques and methods to build high-confidence systems, intelligent, secure and integrated at all scales.

In a near future, a factory will have millions of sensors and actuators controlled by thousands of CPUs. To have this sensorial adaptation, the factories' system needs to flexibly adapt to an ever-changing external environment. System's architecture dictates how the passive or active elements can be organized and behave, accordingly to the external environment and the internal conditions defined by controllers [START_REF] Hehenberger | Design , modelling , simulation and integration of cyber physical systems: Methods and applications[END_REF].

Modularity

Modularity allows specialized functionalities that can be achieved through a plug-andplay fashion, opening opportunities for innovation and specialized software that allows developing heterogeneous and complex systems. To have this seamless integration of different components, the interfaces of the components must be standardized to facilitate the interoperability between them [START_REF] Baheti | Cyber-physical Systems, from : The Impact of Control Technology, available at www[END_REF]. Adaptability is one advantage of these modular components. Since factory's machines need to be enhanced over time to add and improve their functionalities, their hardware/software must also adjust to these changes, which can be easily made through changing/adding new components on the process workflow.

Yelamarthi et Al. in [START_REF] Yelamarthi | An application-driven modular IoT architecture[END_REF] present that most of the IoT architectures are not prepared to be used in various domains. To overcome this customization problem, the authors proposed a modular IoT architecture that can be configured for different domains, such as smart home, city, industry for environment control, optimizing energy usage and automating applications, agriculture for soil and temperature monitoring, healthcare for monitoring patient physiological parameters or remote motion tracking.

Warehouse Management Systems

Accordingly to C.K.M. Lee et al [START_REF] Lee | Design and application of Internet of things-based warehouse management system for smart logistics[END_REF], the major challenge in modern warehouse management is the inventory accuracy, space utilisation, process management and optimize when raw materials are ordered. To overcome these challenges, it is necessary an agile supply chain, which can be done with CPS network, that will connect users, objects and physical processes in a warehouse operation. This improvement requires the integration of technological and administrative innovations, which includes the proper selection of CPS technologies, ambient intelligence, timely information flow and agility.

vf-OS

IoT platforms are designed on the aspect of collecting data and using it in edge computing platforms for cloud computing. To be used in real-life scenario, the existing software need to be able to simulate and process parts of the production processes, which can be done through vf-OS. vf-OS system will provide a set of manufacturing applications and tools for manufacturing users and software developers, respectively. Thus, they provide a set of services for factory computational programs, which can be used for managing factory related computer hardware and software resources as well as to provide services for factory computational programs. As an open operating system, it has components that allow industrial users to download and upload the applications (vApps) developed with vf-OS. The vApps, as illustrated by Fig. 1, can use the vf-OS components, as a software layer extended over multiple factories, to acquire sensorial information and use the actuators over them. First, the physical entities need to be sensed by a transducer and the electrical property will be converted into a numeral value, done by the sensorial and actuator layer. Then, through the distributed system layer, this raw data will be acquired from different remote locations in the factory' environment to be filtered and send to a common storage to be processed. This same layer will also be responsible to perform the necessary algorithms and operations that are necessary to give new information and functionalities to the factories, which is done afterwards by the application layer.

vf-OS Modular Components

vf-OS project uses a Service Oriented Architecture (SOA) approach in which all components perform individual functionalities and can connect with each other to create more complex services. This interoperability can be achieved taking into consideration that all components implement and publish a REST interface allowing a common data interface. This has the advantage of being easy to test and modify the service' workflow, by adding/removing components as needed. As presented in [START_REF] Corista | Enablers Framework: an approach to develop applications using FIWARE[END_REF], the vf-OS building blocks were already used in an industrial implementation scenario to orchestrate a vApp through the vf-OS component "Process Designer", a process model in form of a BPMN (Business Process Model and Notation). Some components able to be used in such BPMN component are presented in the following:

• Enablers Framework (EF) -Acts as a bridge between service provider and service consumer, providing support for enablers' integration, installation and management of their instances. The main added value of this component is to ensure an unique interface and common access for all registered enablers, acting as a wrapper engine for the different enablers and the vApps. For the European commission, these enablers, developed from FIWARE, can be used in multiple domains, e.g, connect to IoT devices, process data and media in real-time, perform Big Data analysis [START_REF]FIWARE Foundation: from research to those digital services you will love[END_REF], ensuring portability, interoperability and openness of services across Europe, by contributing to the Digitisation of Europe Industry and European Cloud Initiative [START_REF]The Future Internet platform FIWARE[END_REF]. EF module represents an advantage for the existing enablers due to the fact that it facilitates the enablers' usage through unique and easy REST API;

• Enablers -Open-source software that exposes heterogeneous services. They can be classified as FIWARE Generic Enablers, Manufacturing enablers and vf-OS enablers. The FIWARE enablers were developed under the FIWARE foundation on the context of the Future Internet Private Public Partnership (FI-PPP) that part of the FP7 (Seventh Framework Programme) of the European Commission [START_REF] Corista | An IoT Agriculture System Using FIWARE[END_REF]. Their goal was to provide services in different domains such as IoT, data context management, Cloud Hosting, security platforms, etc [START_REF]D2.1: Global Architecture Definition -version 1.2.2[END_REF]. Manufacturing enablers are enablers that were developed with the purpose of providing functionalities for manufacturing industries, such as the developed enablers under the FITMAN (Future Internet Technologies for Manufacturing Industries) project [START_REF]Fitman project[END_REF]. vf-OS enablers were developed to complement/improve the specific applications developed to be used by the vf-OS users;

• Messaging-Publish/Subscribe (PubSub) -Data infrastructure middleware responsible for the data communication between different components. This component has an open source message broker, RabbitMQ [START_REF]RabbitMQ[END_REF], that creates a distributed communication layer for messaging handling with Advanced Message Queuing Protocol (AMQP) [START_REF]AMQP -Advanced Message Queuing Protocol[END_REF] standard protocol. It also allows to configure the security policies in order to define which modules have access to specific message queues;

• Datastorage -Scalable data storage system that is capable of handling realtime sensor data and events through a common API (REST). It encapsulates a relational database (for structured information), time series database (for sensorial data) and document oriented database (for unstructured information);

• Drivers -This component provides a collection of libraries that allows to collect data from, and send commands to, physical devices such as industrial automation devices (RFID readers, PLCs, smart sensors, etc). This software module can connect to sensors and actuators through physical interfaces, communication protocols or intermediary systems such as field bus controllers, providing a flexible and modular approach to interact with devices [START_REF]D2.1: Global Architecture Definition -version 1.2.2[END_REF].

Proposed Architecture and Prototypical Implementation of an Industrial Scenario

In this paper, a generic architecture to integrate different modules in order to be used by a manufacturing factory, is presented. The developed work presented in this paper is in the context of the vf-OS project, where the PhD student, author of this paper, developed the module "Enablers Framework" and the libraries to use the "Messaging and PubSub" services. These modules are central components that enables integration and interoperability required in system modules. Further information about these components is described in next section.

The goal is to allow two different factories to communicate with each other in order to coordinate their production and verify if the factories have stored enough amount of spare parts for future production, as can be seen by Fig. 2. The required modules for the proposed architecture are the following: (1) data storage, a software component responsible to save the historical data of the factory's sensors. A predictive analytics can be used through historical and current data to predict future outcomes [START_REF] Gandomi | Beyond the hype: Big data concepts, methods, and analytics[END_REF]; (2) drivers, to interact with physical industrial devices to integrate sensors' data and send commands to them; (3) Enablers Framework, Orion & Notification Enablers. Orion is an enabler that is used for a data/context scenario to update context information, queries and subscriptions. This context-aware component allows to model and gain access to context information connected to sensor networks, users and/or existing industrial applications allowing, for e.g., to receive notifications when some pre-defined condition is accomplished. The Notification enabler is a vf-OS enabler that provides the components of the system an easy to use notification system, to alert when the stock is off limits for each spare-part of the factory. To facilitate the usage of enablers, the EF is used by interpreting the enablers' REST and NGSI [START_REF]NGSI-9/NGSI-10 information model[END_REF] protocols into an easy to use and understand REST interface; (4) controller, this module will control the production of the factory, accordingly to the available resources and the output of the other factory; (5) messaging-pub/sub, that will responsible for the communication between the factory' modules and inter-factory communication. By defining a security policy, it is possible to secure the communication channels, granting the access to the authorised components.

Industrial Scenario

The presented industrial scenario is related with manufacturing, automation and logistics, which uses an application named "vfStockPolicies" (Pilot 1, application 3) [START_REF]D1.3 Providers Scenarios Characterisation -version 1.0.1[END_REF]. The main goal of this vApp is to manage spare-parts that each industrial company needs, monitor their stocks and alert when the stock is lower than a minimum defined for each spare-part. Contrarily to other IoT applications described in [START_REF] Yelamarthi | An application-driven modular IoT architecture[END_REF], the goal of this application is not to have a low-power system, but rather having a reliable and wearable devices attached to the existing factory devices. Since this application requires users from different factories, it is crucial that a RBAC (Role based access control) is used. Currently, the messaging-pub/sub component already has integrated an external service which allows the configuration of the authentication (process of ascertaining the user identification though a password) and authorisation (specification of rules that determine who is allowed to use the messaging channels). After the authentication and authorisation permissions, the factory developer must configure the data access of the sensors/PLCs to perform the device integration with the industrial vApp. Taking into consideration that the Driver's module already contains a complete working copy of the IO component binaries as well as many common functionalities for input and output of the sensors and actuators, respectively, the factory developer only needs to develop the software algorithms [START_REF]D4.1.2a: WP4 Virtual Factory I/O Umbrella Deliverable -Vs: 1.0.8[END_REF]. This variant has the advantage of the software being transferable and it doesn't require rewrite of the whole code. Another configuration to be made is to define the context rules on Orion enabler and Notification Enabler, which will be used to evaluate a specific case and later validate if there are materials to create a product inside both factories. The communication channels also need to be configured inside the message and PubSub component for the message channel between factories and between the factory's internal components.

The controller will use the ORION context broker to reason the previously formalized rules for the context and validate if both factories have the required spare parts to create the final product. If the stock of the spare parts is lower than a certain threshold, the Notification Enabler will be used to alert the maintenance manager of the company about this situation in order to acquire new materials.

The future works concentrate on the total experimentation of the proposed architecture in the real industrial environment under the last phase of the vf-OS project, represented on Fig. 3. This application will be executed in different industrial systems in Spain in order to manage the spare parts of two different factories that use materials from each factory to create a new final product.

Another crucial aspect to take into consideration about the implementation of this architecture in a real factory is the security. Factories have sensitive data that must be protected for unauthorized use, so it is mandatory to correctly define a user management to regulate user permissions, especially if there is a communication between different factories.

Conclusions

This paper defines an architecture aimed at the software design using open-source modular components to develop an application to be used in the industrial field. It allows researchers to speed and quickly develop, without monetary costs, their IoT applications, without having to understand how each component works and communicate with each other. This modular component approach provides a flexible way of building industrial applications which decouples the complexity of constructing complex CPS into simpler subsystems. Thus, the proposed architecture works as a building CPS catalyst tool. It facilitates the development of intelligent systems that actuate accordingly to its applied environment. In this case, it was used the proposed architecture with an application to remotely determine which spare parts are available on a different factory and schedule the production accordingly to such lack of materials. Furthermore, the application can be used to warn maintenance managers with sufficient time to prevent stock breakout and the consequent repair delay in forthcoming maintenance operations.

Due to the use of such modular components the presented work contributes directly at the system level, where multiple components with different structures interoperate with each other to perform a workflow of services and is able to be customized for a diverse range of applications. On the other hand, at the network level, the solution proposed just uses a communication standard protocol to facilitate the communication between different systems.

Fig. 1 .

 1 Fig. 1. High-level layers interaction and information flow in a proposed modular architecture for an industrial scenario.

Fig. 2 .

 2 Fig. 2. General overview of the proposed architecture between two different factories and a communication channel for inter-factory resources' planning.

Fig. 3 .

 3 Fig. 3. vfStockPolicies -Pilot 1 -Application 3 from vf-OS project use case.

Acknowledgments. This work was funded in part by the Center of Technology and Systems (CTS) and the Portuguese Foundation for Science and Technology (FCT) through the Strategic Program UID/EEA/00066/2013.


Margarida Gaspar
email: ms.gaspar@campus.fct.unl.pt

Luis Cristovão
email: cristovl@hotmail.com

Alexandra Tenera

Theory of Constraints Thinking Processes on Operational Lean Programs Management Improvement: An Energy Producer Company Case

Keywords: Theory of Constraints, Thinking Processes, Lean programs, continuous improvement

Several theories and associated models are arising in the field of systems' continuous improvement, focused on structured solutions to face the internal or external factors that affect them. Within these theories stands out Theory of Constraints (TOC), proposed to manage the most relevant constraints that exist within an organization. In this case study, the TOC Thinking Processes approach will be applied to the Management of Operational Lean Programs, on a pilot investigation at the organization were the Case Study took place. This application aims to analyze their Lean Program's Management in order to find the constraint that inhibits the system to reach its best level of performance, in order to support the development of robust improvement solutions that can solve the identified restrictions and sustain the proposed changes over time reaching a process of ongoing improvement.

Introduction

Nowadays, companies, whether on production or services fields, focus mostly on their levels of competitiveness on the global markets where they operate. So, they need to adopt strategies to guarantee their success amongst clients and stakeholders. The first step on choosing this strategy is to focus on the perception of the business processes flow [START_REF] Şimşit | Theory of Constraints: A Literature Review[END_REF]. On other hand, in order to step up the operational results, reduce costs and improve operations, it's usual to try implementing a culture of continuous improvement at the company as part of the business plan. One of these continuous improvement approaches is the Theory of Constraints that is considered by some as a management philosophy [START_REF] Gupta | Theory of constraints: A theory for operations management[END_REF], [START_REF] Šukalová | Application of the Theory of Constraints Instrument in the Enterprise Distribution System[END_REF] and by others as a methodology [START_REF] Mabin | Goldratt's "Theory of Constraints" Thinking Processes: A Systems Methodology linking Soft with Hard[END_REF]- [START_REF] Taylor Iii E | Applying Theory of Constraints principles and Goldratt's Thinking Process to the problems associated with inventory control[END_REF].

Theory of Constraints (TOC) was introduced to the scientific field on the 80's. Since then, it has been disseminated as a methodology or a philosophy to solve problems and improve systems' performance on many fields, by applying many structured TOC solutions. The less implemented solution of TOC is the Thinking Processes (TP), which can be verified by the published literature over the years. This solution was constructed to be applied mostly at complex systems, giving managers tools to think structurally about problems and how to solve them, providing sustainable solutions for organizations.

Thus, this research aims to give a contribution to the scientific field, providing a real Case Study developed at a top company, where the Thinking Processes tools were applied, showing their potential on an integrated application. This research effort intends to result on a valuable contribution to TOC-TP, providing increased results, since for the past 5 years, only few researches were published at the scientific level, as it will be exposed further. Notice also that on this Case Study, the application of TOC-TP tools didn't follow its traditional approach, having been adapted to the company's reality, as it is stated further on chapter four. This adaptation proves that Thinking Processes tools can be orchestrated to answer any company's needs, providing adapted solutions with the same level of quality as any other continuous improvement approach. Also, considering all the revisited literature, this is one of the few Case Studies were all the tools were applied, showing the full potential of TOC-TP, not being limited to the application of one or two tools as a complement of a major analysis.

At an organizational level, the Case Study contributes to the company's Operational Lean Programs Management Improvement, introducing a new methodology, new improvement tools and a systematic approach to examine problems, turning this into a pilot investigation at the organization. What is unique about this investigation, regarding to the organization's reality, is the attempt to improve management practices inside a continuous improvement lean program itself. By doing so, it is possible to question why the management of a lean program is not as lean as it should be. As stated by Taveira [START_REF] Taveira | Avaliação da Sustentação da Metodologia Lean numa Organização: Caso de Estudo na EDP Produção[END_REF] on a previous evaluation of the system, the company where the Case Study took place, saw lean as a mean to reduce the expenses and wasn't considering other major benefits on their daily routine and on its implementation and, nowadays, the problem seems to persist. With this research we aim to give the company a systematic reflection approach to analyze an organizational system and come up with robust solutions to improve it, applying all known Goldratt's TOC-TP tools, which rarely are put into practice as a whole.

Therefore, the main research question brought to discussion is: how a lean organization can benefit from TOC, and how it can provide reasonable and logic solutions for the effective and efficient improvement of the Operational Lean Programs Management? In order to answer the question, this paper is divided into five sections. The present section provides general insights about the Case Study, the subject's main highlights and the major research contributions, the following section explains the relationship of the paper to industrial and service systems, followed by a literature review on the TOC-TP topic on section number three. The fourth section details and explains how the Case was conducted and developed. The last chapter provides the discussion and conclusions about the obtained results, ending with some suggestions of further work on the field.

Subject Relationship to Industrial and Service Systems

Planning is the core phase of a Plan-Do-Check-Act (PDCA) cycle, requiring a high level of effort. However, nowadays it is crucial to answer efficiently to the fast changes of global markets, and often organizations act before taking the suitable time to plan. By doing so, many companies fail on their plans and must rework their strategies, wasting resources and losing service quality. Thus, on industrial and service systems, when applying continuous improvement methodologies, such as Lean, Six Sigma or Theory of Constraints (TOC), it is fundamental to follow the inherent cycles of improvement, to assure the follow up of the planning as well as the fulfillment of the other phases of the cycles.

From the Theory of Constraints perspective, one of the most common applied tools among industrial and operations environments is the Drum-Buffer-Rope (DBR), which has been applied on many fields and types of industries. However, the same doesn't happen yet with the reflexive logical tool of TOC, the Thinking Processes, although it is recognized as the TOC tool with more improvement potential [START_REF] Goldratt | The Goal: A process of ongoing improvement[END_REF]. Its application to real industrial and service paradigms is not very wide and its potential as a continuous improvement methodology hasn't been fully explored.

The TOC Thinking Processes reflexive tools, when applied to an organization, imply systematic thinking following cause-effect logic and reflection mechanisms. By doing so, companies can track their organizational problems, think about solutions, construct future realities and come up with possible obstacles that they can discuss and solve before the implementation of the solution. Thus, the planning is all structured beforehand any operational action takes place, so organizations will be aware of which is the most effective plan they must stick to. This approach to planning will require a higher organizational interconnection of the players, to be supported on new levels of creative and intelligent business decision systems, to be able to produce less expensive, faster and valuable decisions for highly smart organizational decision making.

This Case Study tries to contribute to the expansion of Theory of Constraints Thinking Processes (TOC-TP) as a strong player on its methodological field, giving a full and updated analysis of how TOC-TP is applied nowadays and how it can be managed on a real and practical application on a service system. By applying TOC-TP to an energy producer company, that has many years of experience on lean programs, it is intended to show how an organization can benefit from TOC, and how it can provide reasonable and logic solutions for problems that tend to persist over the years, elevating its performance on lean applications.

Theory of Constraints Thinking Processes (TOC -TP)

Theory of Constraints and Thinking Processes review

In 1984, Goldratt published "The Goal" [START_REF] Chaudhari | Application of Theory of Constraints in an integrated poultry industry[END_REF], a novel that introduces TOC to the management field, based on the story of Alex Rogo, his production plant and how he saves it from disaster with the help of his mentor Jonah. The basis of TOC goes by the premise that every system has at least one active constraint, which means, a systemic problem. On TOC way, constraints are seen as positive things, representing an opportunity to improve the given system. As the constraint sets the performance of the system, an improvement of it will improve the system's results.

In 1994, Goldratt also published "It's Not Luck", another novel which introduces the Thinking Processes and associated tools, trying to provide a systematic way to address the identification and resolution of problems concerning management policies [START_REF]Theory of constraints Handbook[END_REF]. According to Cox and Robinson [START_REF] Cox | TOCICO Dictionary[END_REF], Goldratt proposed Thinking Processes as a way to apply the scientific method to the resolution of business problems, seeking to identify and analyze the inherent simplicity of a system through cause-effect logic. So, the use of the Thinking Processes tools should contribute to achieve system's improvements, to search for a graphical perception of its logical relations and to adopt a simple method to identify, analyze, understand and communicate problems, as well as develop logical solutions.

The identification of the constraint is very important, particularly when it is a nonphysical/intangible one because physical constraints are more tangible and much easier to identify and address. Also notice that many times just by changing relevant policies or performance measures, the existing main constraints can disappear, which results on exponential benefits towards the system's goal [START_REF] Tenera | Contribuição para a melhoria da gestão da incerteza na duração dos projectos através da teoria das restrições[END_REF]. So, for this to happen, and to ensure a significant state of improvement on a system, we should answer three Goldratt's basic improvement questions, i.e. the TOC fundamental questions [START_REF] Goldratt | The Goal: A Process of Ongoing Improvement[END_REF][START_REF] Schragenheim | Manufacturing at Warp Speed: Optimizing Supply Chain Financial Performance[END_REF]: What to change? What to change to? How to change?, which later were expanded by Cox et al. [START_REF] Cox Iii E | Applying Goldratt's thinking processes to prevent mistakes[END_REF] to the current five: Why to change? What to change? What to change to? How to change? How to measure and sustain the change? So, while answering these questions, TOC's continuous improvement actions should be developed according to the identified main constraint of the system [START_REF] Tenera | Contribuição para a melhoria da gestão da incerteza na duração dos projectos através da teoria das restrições[END_REF], thought a prescribed process of continuous improvement (POOGI), consisting in Five Focusing Steps (5FS): 1) identify the system constraint, 2) decide how to exploit the constraint, 3) subordinate the rest of the system to the identified constraint, 4) elevate the constraint and 5) return to step one and don't allow inertia to become the constraint [START_REF] Goldratt | The Goal: A Process of Ongoing Improvement[END_REF]. As the three basic improvement questions evolved, on the TOC's 5FS were added two pre-requisites processes to implement improvement actions, as it will be considered at the present research. So, according to Pass and Ronen [START_REF] Pass | Management by the Market Constraint[END_REF], before the identification of the constraints we should also: 1) Stablish what is the organization's goal and 2) Define global performance metrics.

Overview of Thinking Processes' (TP) recent literature

The TOC Thinking Processes unlikely other TOC tools, as DBR, isn't so deeply developed in terms of practical and real situations. As referred at section one, to check the scientific current research level of the TOC-TP approach, a bibliography study was conducted, using research engines such as B-ON and Scopus. This research was developed considering the periods of time between 2008-2013 and 2014-2019 and defining a set of terms to conduct the investigation, using quotation marks to restrict joint terms such as "Thinking Processes". Also, to identify the scientific works directly related to the main subject (TOC) and the Goldratt term was also added to each research term. On Table 1, the results are identified on the research terms by "terms" and "Goldratt" search results. Also, in the scope of this search all sources and all types of information available were included, regarding to keywords and titles of conferences, papers, academic and scientific journals, reports and books. 1, regarding to B-ON search, it's possible to verify that, generically, Theory of Constraints has been more explored on recent years, unlikely Thinking Processes, which numbers decreased over the past few years. Regarding Case Studies, they have been more publication between 2014 and 2019 than between 2008-2013, but when adding the term "Goldratt" the number of available publications decreased to less than half on most cases. The same happens seems to happen for Thinking Processes Case Studies. Overall, although with few results were found, the research conducted by B-ON shows some consistency on the number of publications related to Theory of Constraints and Thinking Processes over the past 10 years, even though there's no results on some cases, according to the researched terms.

Regarding to the investigation conducted in the research engine Scopus, it is possible to find that numbers aren't much different from the scenario provided by B-ON, although Scopus provides a bigger amount of publications on every aspect (possibly because of research options provided by both engines). Generically, the number of publications also increased over the recent years as on the case of Case Studies publications. Although TOC publications numbers are still low, comparing to other continuous improvement methodologies, as Lean or Six Sigma. Concerning the identified Case Studies on Thinking Processes we could highlight the "Revolutionizing blood bank inventory management using the TOC thinking process: An Indian case study" (2017) by Lowalekar and Ravi [START_REF] Lowalekar | Revolutionizing blood bank inventory management using the TOC thinking process: An Indian case study[END_REF], "The thinking process of the theory of constraints applied to public healthcare" (2019) by Bauer, Vargas, Sellitto, Souza and Vaccaro [START_REF] Bauer | The thinking process of the theory of constraints applied to public healthcare[END_REF], "A process improvement approach based on the value stream mapping and the theory of constraints thinking process" (2014) by Librelato, Lacerda, Rodrigues, Veit [START_REF] Librelato | A process improvement approach based on the value stream mapping and the theory of constraints thinking process[END_REF].

Although Scopus provides a higher number of publications on most cases and having in consideration the cited publications, the reduced research on TOC-TP remains, providing the need to increase research and applications on this subject and on TOC area in general.

Overview of Thinking Processes tools

Goldratt developed a set of Thinking Processes tools to put TOC-TP on practice. The following tools were developed in a format of logic trees and a cloud: Current Reality Tree (CRT), Evaporating Cloud (EC), Future Reality Tree (FRT), Negative Branch Reservation (NBR), Prerequisite Tree (PRT) and Transition Tree (TT). Later, Dettmer [START_REF] Dettmer | The logical thinking process a systems approach to complex problem solving[END_REF] also added the Goal Tree (GT) and Goldratt as well added, the Strategic and Tactic Tree (S&T), which is today the last contribute for the TP tools and it is also considered the last tool of the sequence that should be implemented. Figure 1 represents the existent connection between the five questions, the inherent application of the five steps and the TP tools and how they all work together to establish a full practical investigation on the Theory of Constrains Thinking Processes.

Fig. 1. Framework of the TOC-TP tools application

Concerning to the roles of TP tools, the Goal Tree answers the first question "Why to change?", identifying the organizational model proposed to achieve the goal. Before a company can focus, it is necessary to have in mind what is the goal. Once the answer gets clear, the Necessary Conditions (NC) and Critical Success Factors (CSF) to achieve the goal are defined to identify which actions will be used to manage the progress. For the second question, CRT answers the question "What to change?", which allows to diagnose what, in the system, needs to be changed [START_REF] Mabin | Goldratt's "Theory of Constraints" Thinking Processes: A Systems Methodology linking Soft with Hard[END_REF], which is a logical structure designed to illustrate the actual state of the system, isolating what needs to change, identifying the major problems (the undesirable effects, UDE) and draw the path to the root causes and the core problem.

Once the CRT is fully designed, the constraint emerges and the best way to manage it is through commitment. So, in order to solve the core problem, TOC defines that behind every problem there is a conflict that blocks any robust solution. In order to evaporate this conflict and get plausible solutions (the injections) Goldratt suggests the EC as the perfect TP tool to serve this purpose, answering the question "What to change to?" [START_REF] Mabin | Goldratt's "Theory of Constraints" Thinking Processes: A Systems Methodology linking Soft with Hard[END_REF].

The fourth tool of the TP set is the Future Reality Tree (FRT) which allows to construct a solution that, when implemented, replaces the Undesirable Effects (UDE) that are the basis for the CRT, by Desirable Effect (DE) in the FRT. The FRT is designed to ensure that all UDE will be eliminated by the solutions founded at the Evaporating Cloud (EC), providing a valid alternative for the future. However, when trying to get buy-in of the system's owners it's crucial to make sure that there is no potential resistance related with the proposed solutions. This type of thought is considered when referring to the Negative Brunch Resolution (NBR), which determines if there are negative branches on the new solutions. By trimming these branches with new injections, should be possible to come out with a more robust solution for the system we are trying to improve.

The next TP tool is the Prerequisites Tree (PRT) that aims to answer the question "How to cause the change?" by identifying the obstacles that prevent the chosen injection(s) from being implemented [START_REF] Mabin | Goldratt's "Theory of Constraints" Thinking Processes: A Systems Methodology linking Soft with Hard[END_REF]. The transition Tree (TT) is also used to give specific actions to the injections implementations i.e. combining each provided effect successively with the subsequent specific actions to produce new improved effects, contributing to answer the same question as a PRT. According to Dettmer [START_REF] Dettmer | The logical thinking process a systems approach to complex problem solving[END_REF][START_REF] Dettmer | Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement[END_REF], the PRT can be combined with the TT. Together they should be capable to provide a more powerful and robust tool to structure the injections that are going to be implemented on the future reality of the system, having into account the possible obstacles on the way and eliminating them.

The Strategic and Tactic tree (S&T) is used to identify and communicate the identified strategies and tactics to ensure Management's attention at all levels to be synchronized and focused on the highest priority changes. This last tool has been specially designed to help Top Management prevent common mistakes that result in failures of change initiatives within organizations. It is possible to verify that for each strategy (S) there must be a tactic (T), so an S&T tree consists of a number of pairs S and T, presented at various levels, each level represents one layer of responsibility within the organization [START_REF] Schragenheim | Manufacturing at Warp Speed: Optimizing Supply Chain Financial Performance[END_REF].

Applying TOC-TP to Operational Lean Programs Management

Background to the Case Study

According to Saunders [START_REF] Saunders | Research methods for business students[END_REF], the strategy to develop this investigation was defined as a Case Study, suiting the definition given by Robson [START_REF] Robson | Real World Research: A Resource for Social Scientists and Practitioner-Researchers[END_REF]. This author defines a Case Study as a strategy for doing research which involves an empirical investigation of a particular contemporary phenomenon within its real-life context using multiple sources of evidence.

Thus, the company where the Case Study took place is part of a Group which the main business is the production, distribution and commercialization of energy. This company in specific is responsible to manage the production of thermic and hydric energy, on Production Centers across Portugal. Being decentralized, with more than 40 production points, it is difficult to manage all the operations. To avoid resources' waste (money, time, quality) and to be as more efficient as possible, in 2006, the company launched the Lean Program. First, this Program was a pilot on a chosen Center and then it was replicated to many others. Nowadays the Local Programs are at the sustention phase, being often monitored and evaluated, answering to the KPI that are suggested by the managers.

To evaluate the system "as-is" was necessary to interview the company staff based on a design thinking approach and on brainstorming. This evaluation, which details are referred at Table 2, was carried out by the company on a lean event. The evaluation was based on the steps of a lean initiative life cycle to understand both positive and negative opinions of the lean practitioners at each stage, also considering all the geographies where exists a Lean Program. Based on this empirical data, the first analysis to the system was made, based on the given negative feedback in order to analyze, at a first stage, the main problems of the system.

The data collected comes from various sources, which were combined to analyze the system, in order to get a fully understanding of it. They may include, for example, interviews, observation, documentary analysis and questionnaires [START_REF] Saunders | Research methods for business students[END_REF].

Using tools such as Pareto Diagram and Ishikawa Diagram, it was possible to scrutinize a large amount of data. These tools allowed to group the main issues identified by the staff, in categories such as, Difficulty and Resistance to apply Lean, Unavailability of staff, Communication problems, which are the main concerns of the company. Later, these topics where addressed on the application of TOC-TP. The following subsections show some diagrams that represent the trees and clouds developed for his problem as well as its explanation.

Why to Change? The Application of the GT

After the empirical analysis done to the data provided by the company, the main goal of the investigation was set to start the development of the TOC-TP logical tools. This is also considered the first step to develop the first Thinking Processes tool, the Goal Tree. Thus, with the agreement of the company, the main goal of the Case Study was defined as to identify the main actions to follow "to improve the effectiveness and efficiency of the Operational Lean Programs Management (OLPM)". In fact, the Goal Tree shows the main actions to have into account when trying to reach the proposed goal. The many inputs given by the company were crucial to identify which were the Critical Success Factors (CSF) and the Necessary Conditions (NC) that needed to exist to achieve the Goal. These factors and necessary conditions are defined to represent how the company must perform if the goal was achieved (although it hadn't been, due to the undesirable effects that create the gap between the reality and the desired state). The CFS are the fundamental aspects that are considered crucial to achieve the proposed Goal and the NC are the conditions that must exist to enable the Critical Success Factors. The organization's staff had an active role helping to construct the Goal Tree, as their opinions, feelings and inputs were collected from a brainstorming session. By actively construct the Goal Tree with the company, this tree can provide an accurate answer to the question to "Why to change?", giving the perception that the problem really exists and there's a need and a reason to create a positive change on the system. As the desired reality was constructed, the same session was used to inquire the participants about what is preventing the organization from achieving the Goal, constructing a list of 18 UDE. This list confirmed the main issues revealed on the first analysis to the system and those inputs were the basis of the following step: What to Change? That is explained in detail on the following section.

What to Change? The Application of the CRT

The reverse line of thought was taken into account to think about the undesirable effects (UDE) that prevent the system from achieving the desired state. Between the eighteen UDE identified on the system, the CRT (Figure 2) shows the situation as perceived at the time, answering to the question "what to change?". This diagram was constructed, from top-down and its read bottom-up, linking all the intermediate effects to the UDE, using inputs like the data analysis and team brainstorming, to develop logical cause-effect connections. At CRT, these cause-effect connections use "IF…THEN" statements, for example IF "Lean Programs aren't included in the QMS" OR "Improvement is seen as a time consumer" THEN "Improvement isn't considered as a management system".

Analyzing the CRT is possible to state that the intermediate effects that connect UDE are numbered above the boxes and UDE are identified by their numbers (e.g. UDE 1.2). Therefore, the entities "A", "B", "C" and "L" represent long connections between entities. For example, entity "A" means that UDE 5.2 is connected to the UDE 1.1 by the ellipse (which represent an "AND"). However, "L" means that there is a negative reinforcing loop at the tree, meaning that when connecting those effects, repeated negative consequences occur at a faster pace.

From Figure 2 it is also possible to see that the main problems on the system are related to "Training", "Means to report lean initiatives" and "Alignment of metrics" factors, which are the identified Critical Root Causes (CRC). These CRC can identified by spotting the UDE that have no entry connections (UDE 4.1) and by counting which UDE connects with most of other entities at the tree, for example, UDE 5.2 and UDE 5.3. These CRC are the problems that mainly contribute to the existence of core problem identified at the CRT. Therefore, these CRC must be scrutinized to be evaporated by EC. Not surprisingly, the major problem (core problem) that worried all participants including managers was, still, the "Lack of Commitment with Lean and Lean's culture", which is consistent with the problem found by Taveira [START_REF] Taveira | Avaliação da Sustentação da Metodologia Lean numa Organização: Caso de Estudo na EDP Produção[END_REF]. This entity is represented at the bottom box of the CRT (box 55), has no entry connections and leads to most of the UDE (directly or indirectly) from bottom to top until reaching the Goal (the upper entity).

By developing the CRT, it is possible to conclude that a major and transversal problem has been affecting the company and the management of Lean Programs over the years and there wasn't no solution at that time. How can an organization be Lean and have a healthy Lean Program if it isn't felt on their culture and on a daily basis? How can a long term Lean Program have such structural problems as training, reporting and metrics? These paradigms were taken into consideration from the application of the CRT until the end of the research to suggest ways to solve it. The identified core problem becomes the focus of the cloud EC, revealing the dilemmas. After the analysis of the CRT we are now able to study more deeply each of the main problems identified on the system applying the EC, NBR and FRT. The combination of these tools answers the third question "What to Change to?", giving a possible reality of the system after the change. Also, on this phase it is possible to come up with suitable new injections to mitigate the systemic problems.

To apply the Evaporating Cloud and to clearly point the dilemmas or conflicts regarding to the TOC-TP language, four clouds were developed, one of them to the core problem and the others to each of the identified CRC. Figure 3 represents the relationship between all the developed clouds, which focus is identical and represents the proposed Goal exposed at the first diagram. So, it is possible to state that entity A is the same for every cloud, representing the "Effective and efficient management of Operational Lean Programs".

Fig. 3. Evaporating Clouds (EC)

As constructing each cloud, we can identify the weakest necessity cause linkage in the EC by creating assumptions that would be able to break it. These assumptions are created by necessity logical relations as "In order to have A, we need B". When having some assumptions for a given link it is necessary to find one statement weak enough to be broken by an injection that will dissolute the conflict. So, after the selection of the link to break, possible injections are created to evaporate the conflict and the cloud.

The "CP" cloud at upper left corner of Figure 3 represents the EC for the core problem. Its dilemma can be interpreted as: to have an "effective and efficient management of Operational Lean Programs" we need "willingness to include Lean in daily operation".

In order to have a "willingness to include Lean in daily operation" we need to obtain "a clear commitment with Lean and Lean Culture". On the other hand, for an "effective and efficient management of Operational Lean Programs" we need "the current resources to be appropriate to have control over the quality of Programs". And for this should be "little commitment to Lean and Lean culture" (since the current resources aren't considered enough). This is in direct conflict with the lower branch, which is represented by an elbow double arrow. Hence, we can't have much and low commitment with Lean at the same time.

At this Case Study, a total of 14 injections were brought to discussion with the representative organization manager to validate the findings. This process was repeated for every cloud and all the injections were analyzed with the support of an Efficiency/Difficulty matrix elaborated for the purpose, which was crucial to study the impact of each injection on the system. By this analysis, two injections were declined, four injections were approved by the organization to mitigate de training problem, four injections for the metrics issue and tree injections were proposed for the reporting. Although these injections will have an indirect effect on the core problem, contributing to its mitigation, one more injection was approved to directly mitigate the core problem.

Even though we are analyzing the EC, by chance, this application converged to what is called the Three Clouds Method, that is an alternative approach to the conventional application of the CRT [START_REF] Burton-Houle | Field guide to the Theory of Constraints Thinking Process[END_REF]. At this investigation we chose to apply the conventional method of the CRT as we consider that is the most robust solution for the purpose. The advantage of having the architecture of the three-cloud method applied to the EC, as is represented at Figure 3, is that we can study the system as a whole by linking the entities on the clouds to each other's by their common points, as is shown by the arrows that converge from entity "D" to the entity "D" at the "CP" cloud.

The analysis of the EC concludes, as expected from the previous feedback, that the system needs a relevant improvement on what concerns to Lean commitment and cultural change. This change should be wider and deeper than just to mitigate the identified problems to align visions, practices, and to work in harmoniously on a Lean organization. However, we expect the proposed injections to help substantially on this matter.

After the final selection of the eligible injections to be implemented, the organization's manager selected the more volatile injection being "Linking programs and goals that translate into financial rewards/other benefits". This injection was scrutinized using the NBR as this tool that can induce negative side effects to the system. Next, NBR was trimmed by the division of the volatile injection into two "Use only non-financial and career progression benefits" and "Use other company benefits", that placed strategically at the NBR, could invalidate the negative effects, preventing the system from new UDE and the change, possibly, from failing.

The last step to finish answering the basic question "What to change to?" is the application of the Future Reality Tree. This tree comes up through the positive effects generated on consequence of the injections proposed at the EC, showing what would change if the system improved its effectiveness and efficiency on the management of Operational Lean Programs. Usually, these effects are the opposite of the negative effects identified at the CRT. So, the FRT shows, by drawing the logical paths, how the injections implemented on the system can create positive effects that will converge on the goal's achievement.

How to Change? The Application of the PRT+TT

After the definition of the future reality it is necessary to induce the change by the application of the PRT and the TT, answering the question "How to change?". These two trees will be applied as a single tool, as justified by Dettmer [START_REF] Dettmer | The logical thinking process a systems approach to complex problem solving[END_REF], since the extension and complexity of the Case Study doesn't justify its independent utilization. Ideally, this tree would be constructed for each injection created previously, to analyze the details of its implementation on the system. However, on this paper we give only one example to illustrate how an injection can be explored by TOC-TP. Later, it is expected the company to construct the rest of the PRT+TT diagrams, to plan the implementation of the improvement actions.

Thus, a list was created to specify the intermediate objectives (IO) on the implementation of the injection. These intermediate objectives are the steps to follow to achieve the execution of the injection. Reading the diagram bottom-up, the IO are represented by boxes with curved edges, on a necessary condition thinking: "In order to have A we need B''. For example, on Figure 4, "In order to analyze comparatively Lean tools with EDP Lean tools we need to Detail Lean tools according to using criteria". Then, another list was created to identify the obstacles regarding to the implementation of the chosen injection. These obstacles are assigned to the links that may have associated negative effects and can be interpreted as obstacles that prevent the system from the correct execution of the action. After, the PRT was created by linking the obstacles with the corresponding IO, as shown at Figure 4.

But, as stated before, this isn't the final stage of the tree, the next step is to trim those obstacles with specific actions (SA) to finish the implementation plan. These actions are necessary in order to prevent the improvement to fail and to avoid inertia. For example, to prevent the Obstacle 1 (O1) "Unawareness of the detail of the performance of functions" from happening the Specific Action 1 (SA1) "Contact the company and clarify any doubts that may exist" must be executed. Regarding the structure of the PRT+TT (see Figure 4), a plan of implementation for this specific injection was defined for the organization to follow. It is expected the organization to implement the rest of the injections taking into account the example given on the research and in order to promote a sustainable change, closing the first cycle of change by TOC-TP.

How to Measure and Sustain the Change?

To answer this question, at first, we would have to build a S&T tree. But, considering the lack of enough knowledge by the research team about companies grounding on this subject to develop this tree, the research team decided not to pursuit with its construction. The S&T tree was idealized to be implemented by managers, on project management subjects, as a tool to help them on the definition of the organizational strategy, which action is outside of the main scope of the present study. Nevertheless, S&T should be implemented on projects and should be orchestrated by top management as a macro tool to manage the main lines of a bigger strategy.

Main Conclusions and Further Work

This research allowed to consider solutions for an organizational problem that persists over the past years on a lean based company. The problem, lack of enough commitment with Lean and Lean's culture, is a long-term issue at the organization that is felt at the modus operandi of staff and at the organizational culture. In order to solve this problem, twelve injections were approved by the organization to put in practice. As an example, one of them was structured and prepared for the organization to implement.

The research allowed to implement GT to find the goal, the CRT to find the core problem, the EC to come up with injections, the NBR plus the FRT to structure and prepare the future reality, and the PRT+TT to give a figure of what one of the implementations could be. Given the full implementation of TOC-TP, the organization has now a systematic ground to promote the resolution of major problem that affects the Management of their Lean Programs. However, this Case Study doesn't validate the Theory and its suppositions, it just represents a contribution to the empirical application. Although the systematic method to apply Thinking Processes is concrete and has strict rules, its application is empirical and mostly qualitative, which produces qualitative results, that can have many interpretations. The lack of investigation on the field, doesn't provide yet a solid ground of exploration, giving few examples of application to better analyze systemic problems.

It is considered that the research question was mainly answered on its purpose as the research allowed to put into practice a full framework of basic TOC-TP tools, giving a sense of full accomplishment of the process of ongoing improvement, by using causeeffect logic and reflecting about what could be improved on a given system. However, the present investigation stills lacks on giving proof and analysis of the implementation of the injections on the company, measuring its results and, perhaps, starting another cycle of improvement to find if the problem sustains. Another limitation of this research approach is that the case study results can't be extrapolated to other realities since every company has a different reality. Due to the type of data collected and to the exposed problem on the Case Study, tools such as S&T tree, TOC's Throughput Accounting and the verification of KPI weren't considered on this case study report, which could be developed in order to assure that, company could continually monitor the change and the solutions implementation impacts. Also, it is recommended to continually measure the satisfaction indexes of the staff regarding to lean, especially after the implementation of the improvement actions.

On this Case, TOC was used to provide a framework for the change needed on the system, regarding to the identified core problem and to provide a clear logic-based argument for the changes proposed, which are essential to ensure the sustainability of the Lean Programs. Also, this Case Study contributed with an innovative problemsolving method for the company and to increase TOC-TP exploration on the scientific field, contributing to encourage pairs to further explorations of TOC-TP. This research also adds to verify the potential and robustness of this method on smart organizational improvement, by giving unique and maybe out of the box solutions to organizations which require new levels of creative and intelligent business decision tools in order to be able to produce less expensive, faster and valuable decision i.e. highly smart organizational decision making,

Fig. 2 .

 2 Fig. 2. Current Reality Tree

Fig. 4 .

 4 Fig. 4. PRT+TT

Table 1 .

 1 Theory of Constraints publications of the last seven and five years

	Research Engine	Research Term	Number of Publications 2008-2013 2014-2019 By keywords By title By keywords	By title
		Theory of Constraints/ * Goldratt	2735/*141	160/*47	2453/*47	170/*72
		Theory of Constraints Case Study/ *Goldratt	2/*0	6/*4	1/*0	8/*2
		Theory of Constraints
		Thinking Processes/	1/*0	2/*2	0/*0	0/*0
	B-ON	*Goldratt
		Thinking Processes Case Study/ *Goldratt	0/*0	2/*1	0/*0	3/*0
		Thinking Processes/ *Goldratt	3/*0	32/*3	3/*0	28/*1
		Thinking Processes Tools/ *Goldratt	1/*0	12/*3	0/*0	8/*1
		Theory of Constraints/ *Goldratt	310/*205	201/*86	253/*184	95/*74
		Theory of Constraints Case Study/ *Goldratt	2/*2	5/*5	4/*3	10/*8
		Theory of Constraints
		Thinking Processes/	17/*15	5/*5	10/*9	4/*4
	Scopus	*Goldratt
		Thinking Processes Case Study/ *Goldratt	2/*1	3/*2	4/*3	3/*1
		Thinking Processes/ *Goldratt	174/*18	53/*10	124/*14	75/*10
		Thinking Processes Tools/ *Goldratt	36/*11	13/*7	19/*3	11/*3
	Analyzing Table

Table 2 .

 2 Details of the Lean event

		Lean Day
	Date November 2017
	Duration One day
	People Approx. 10 teams of 10 company employees (different roles)
	Roles	Multiskilled employees (managers, technicians, engineers, operational collaborators)
	Purpose	Evaluate the status of Operational Lean Programs, based on staff opinions

Acknowledgements

This work has been partially supported by UNIDEMI -Research and Development Unit for Mechanical and Industrial Engineering by the Portuguese FCT-PEST program UID/EMS/00667/2019.The authors are grateful to the supporter research company's collaborators which the researcher had the pleasure to work during the development of this research work.


Koorosh Aslansefat
email: koorosh.aslansefat@uninova.pt

Francisco Marques

Ricardo Mendonça

José Barata

A Markov Process-based Approach for Reliability Evaluation of the Propulsion System in Multi-Rotor Drones

Keywords: Markov models, Mission planning, Decision Making, Reliability evaluation, Flight control, UAV

Autonomous multirotor drones as a popular type of Unmanned Aerial Vehicles (UAVs) have a tremendous potential to facilitate activities such as logistics, emergency response, recording video, capturing special events, and traffic management. Despite the potential benefits the possibility of harming people during operation should be considered. This paper focuses on modeling the multirotor drones' propulsion system with Markov chains. Using the proposed model, both reliability and Mean Time To Failure (MTTF) of the propulsion system are evaluated. This study proposes a fault detection and recovery system based on a Markov Model for mission control of multirotor drones. Concretely, the proposed system aims to reduce potential injuries by increasing safety.

Introduction

Reliability can be defined as the probability of multirotor functioning correctly during a given timespan. Safety, on the other hand, is the probability that a multirotor either functions correctly or stops its operation in a safe manner without causing injuries. To design a system that is safe and reliable, multirotor faults and failures need to be studied. Furthermore, performance modeling of the multirotor in the presence of faults and failures needs also to be done. By modeling multirotors for performance and functionality evaluation, bottlenecks and weak points of the system can be determined and strengthened. Having the Markov model of the multirotor is not only beneficial for reliability evaluation. But also, for proposing a mission control and diagnostics system to reduce possible injuries caused by faults and failures in multirotors' systems and subsystems. As failures in the propulsion system can potentially cause a complete loss of control of the UAV it was chosen as the focus of this paper. In the following paragraphs, a brief literature survey on the research of faults and failures in UAVs is provided. In [START_REF] Murtha | Evidence Theory and Fault-tree Analysis to Cost-effectively Improve Reliability in Small UAV Design[END_REF] an FTA based procedure is proposed for reliability improvement in a cost-effective way. Dempster-Shafer Theory is also used to reduce the uncertainty in failure data. However, while the aforementioned references have used FTA that is limited to modeling static characteristics of the systems we propose to cover the dynamic behavior of the multirotors by leveraging on a Markov model. Furthermore, while in [START_REF] Olson | Qualitative Failure Analysis for a Small Quadrotor Unmanned Aircraft System[END_REF], only the qualitative failure analysis for the Michigan UAV has been addressed we will focus on the quantitative failure analysis. In this paper, the remaining useful life (RUL) of the UAV is estimated through fault tree analysis and has been used for health-based task allocation (Shi, Yang, & Quan, 2016), based on the controllability degree, the reliability of multirotor with different configurations have been studied. In (Belcastro, Klyde, Logan, Newman, & Foster, 2017) experimental flight test techniques with different possible sets of hazardbased test scenarios are proposed in order to evaluate the safety of sUAS operations. In spite of intensive research conducted so far, there is no published work that we are aware of on Markov modeling for fault detection and recovery for multirotor robots. This paper introduces the Markov model of a hexacopter and evaluates its reliability and MTTF. The organization of this paper is as follows. In section 2, the relationship to industrial and service systems will be addressed briefly. Section 3 introduces Markov modeling of the propulsion system in multirotors and section 4 illustrates numerical results obtained from introduced Markov models. In section 5, a brief discussion on the idea of Markov-based fault detection and recovery is briefly explained. The paper ends with some concluding remarks and possible future avenues.

Relationship to Industrial and Service Systems

Nowadays, multirotors and small unmanned aircraft systems (sUAS) are being developed for consumer and commercial applications in urban areas that encompass logistics, emergency response, filming, traffic monitoring, agriculture monitoring, search and rescue, railway surveillance, and corrosion inspection in bridges (B. Klyde, et al., 2017). Many applications entail operating in populated areas where a failure of the multirotor can endanger humans. Therefore, reliability and safe landing of multirotors are important and challenging because of their dynamic behavior and complex models (Sadeghzadeh, Mehta, & Zhang, 2011).

Markov Modelling of the UAV's Propulsion Systems

In this section, the proposed Markov model and its solution will be provided for reliability and MTTF calculation. In addition, the simplification of Markov model for multirotors will be introduced.

Simple Markov Model and Its Continuous-Time Solution

Figure 1 shows the Markov reliability model of a simple system with one operational and one failure states. States and transitions between states are first recognized, and the rates of transitions are allocated. With exponential failure rate distribution function, the reliability of a system after period of time is then expressed by (1), and its unreliability (failure probability) is given by [START_REF] Belcastro | Hazards Identification and Analysis for Unmanned Aircraft System Operations[END_REF].

𝑒 -𝑛𝜆𝑡 = 1 -𝑛𝜆Δ𝑡 + 𝑛 2 𝜆 2 Δ𝑡 2 -⋯ (1) 1 -𝑒 -𝑛𝜆𝑡 = 1 -(1 -𝑛𝜆Δ𝑡 + 𝑛 2 𝜆 2 Δ𝑡 2 -⋯ ) → 𝑛𝜆Δ𝑡 (2)
Thus, the probability of the system at the first state after elapsingΔ𝑡 time is given by:1 -𝜆Δ𝑡. In this figure, Lambda stands for the rate of failure.

Reliability Evaluation

Based on the Markov model illustrated in Figure 1 and according to the Markov theorem, (3) can be written as follows [START_REF] Dubrova | Fault-Tolerant Design[END_REF].

𝑃(𝑡 + Δ𝑡) = 𝑀. 𝑃(𝑡) ( 3
)
where P is the "probability states vector" Error! Reference source not found. and M is the discrete state transition matrix Error! Reference source not found..

𝑃(𝑡) = [𝑃 𝑂𝑃 (𝑡), 𝑃 𝐹 (𝑡)] 𝑇 (4)
𝑀 = [ 1 -𝜆Δ𝑡 𝜆Δ𝑡 0 1 ] (5)
Equation ( 3) can be recursively solved if as an initial probability vector is known. The result for different times is given by [START_REF] Murtha | Evidence Theory and Fault-tree Analysis to Cost-effectively Improve Reliability in Small UAV Design[END_REF].

𝑃(𝑛Δ𝑡) = 𝑃 𝑛 . 𝑃(0) (6)
Equation ( 7) is the continuous form of (3).

𝑃 ̇(𝑡) = 𝐴. 𝑃(0) ( 7
)
where A is the continuous Markov transition matrix in the form of [START_REF] Sadeghzadeh | Fault/Damage Tolerant Control of a Quadrotor Helicopter UAV Using Model Reference Adaptive Control and Gain-Scheduled PID[END_REF].

𝐴 = ∂𝑀 𝑇 ∂Δ𝑡 = [ -𝜆 0 𝜆 0 ] (8)
Solving [START_REF] Olson | Qualitative Failure Analysis for a Small Quadrotor Unmanned Aircraft System[END_REF] gives the probability of system states at any time t.

𝑃 𝑂𝑃 (𝑡) = 𝑒 -𝜆𝑡 (9)

𝑃 𝐹 (𝑡) = 1 -𝑒 -𝜆𝑡 (10)
The reliability of a system can be obtained from the probability of states in Markov model those which represent the operational condition of the system. Hence, the reliability of a simple system is now calculated as equations and (11). In this figure, each Lambda stands for the failure rate of a motor. For example, Lambda a stands for the failure rate of the motor a. (11)

MTTF Calculation

Same Markov model for Mean Time To Failure (MTTF) calculation can be used as in Figure 1. This Markov model is an arbitrary absorbing Markov chain which is described by a transition matrix P. If there are r absorbing states and t transient states, the transition matrix will have the following canonical form. The MTTF Markov model has only one absorbing state and so in this case (I = 1).

𝑃 = [ 𝑄 𝑅 0 𝐼 ] (12)
Consider 𝑁 = (𝐼 -𝑄) -1 as the fundamental matrix of 𝑃 and Let 𝑡 𝑖 be the expected number of steps before the chain is absorbed (goes to state 𝐴), given that the chain starts in state 𝑠 𝑖 and let 𝑇𝑇𝐹 be the column vector whose 𝑖 𝑡ℎ entry is 𝑇𝑇𝐹 𝑖 . The column vector of TTF can be written as follows:

𝑇𝑇𝐹 = [𝑡(𝑁𝐴 1 ) 𝑡(𝑁𝐴 2 ) … 𝑡(𝑁𝐴 𝑛 )] 𝑇 = 𝑁𝐶 ( 13
)
where 𝐶 is a column vector all of whose entries are one. Once the system starts from state Op (Operational), the expected number of steps to be in the failure state (F) can be achieved by ( 14).

𝑀𝑇𝑇𝐹 = 𝑇𝑇𝐹(𝑂𝑝) (14)

Simple Markov Model and Its Continuous-Time Solution

Fig. 3 illustrates a simple hexacopter configuration with rotors labeled from a to f. In this configuration, motors are PNPNPN. P stands for positive clockwise direction and N stands for negative anti-clockwise direction (Shi, Yang, & Quan, 2016).

Model Simplification

Assuming that "the failure rates of all rotors are the same" the model presented in Fig. 4 can be simplified into the one depicted in Fig. 5 the first state in this model labeled with "6" and "M" means that in this state all six rotors are operational. In case of having only four rotors operational, two states can be considered. The star state demonstrates the system with operational rotors in a quadcopter configuration while the second one covers the other possible configurations. With the assumption of having same failure rates of all rotors, the 19 states Markov model is simplified to an understandable and less complicated 6 states Markov model.

Numerical Results

For understanding the system's behavior in terms of reliability and MTTF, numerical results are provided in this section. Fig. 6 shows the evaluation of the reliability of a quadcopter and hexacopter with two kinds of rotors configuration versus time. In this figure, the failure rate of each rotor is assumed as 0.04 failures per hour. The reliability of hexacopter with PNPNPN configuration is higher than the reliability of hexacopter with PPNNPN configuration and both are higher than the reliability of quadcopter. In (Shi, Yang, & Quan, 2016), the reliability of hexacopter with both configurations and without yaw control has been considered with the same expression. However, the result achieved from Markov model shows that they have different values of reliability vs. time in PPNNPN configuration.

Discussion

Markov modeling of multirotors is the first step in designing the fault detection and recovery system. A fault diagnosis module will be needed to specify the current state of the multirotor in its Markov model. Hence, it is assumed that there is a fault detection and diagnosis module that can detect the failure of each rotor. Based on the proposed Markov model and detection of a failed rotor, the mean time to failure and the probability of failure from a related state can be estimated. If both probabilities of failure and MTTF are less than desired value, the robot will continue the mission. However, if the probability of failure or MTTF is more than the desired value the robot will abort the mission or perform a safe landing.

Conclusions

The higher maneuverability of multi-rotors compared with other types of UAVs makes them very popular. However, safety when operating multi-rotors in populated areas remain one of the most important challenges. In this sense, a Markov model was herein proposed as a fault detection and recovery module for the propulsion system of multirotors and was validated through Monte Carlo simulations. Reliability and MTTF of the robot were also evaluated via the developed models. In particular, it was shown that the reliability of a hexacopter configuration is higher than a quadcopter. Moreover, between the two hexacopter configurations studied, the PNPNPN configuration has higher reliability and MTTF when compared to the PPNNPN.

Fig. 1 .

 1 Fig. 1. Reliability Markov model of a simple system.

Fig. 2 .

 2 Fig. 2. Reliability Markov model of a Quadcopter Having the Markov model for a quadcopter, the reliability expression of the system can be obtained easily by (12). 𝑅 𝑄𝑢𝑎𝑑𝑐𝑜𝑝𝑡𝑒𝑟 (𝑡) = 𝑃 𝑂𝑃 (𝑡) = 𝑒 -(𝜆 𝑎 𝑡+𝜆 𝑏 𝑡+𝜆 𝑐 𝑡+𝜆 𝑑 𝑡)(11)

Fig. 3 .

 3 Fig. 3. A simple hexacopter with rotors labeled from a to f (PNPNPN configuration). Based on the hexacopter illustrated in Fig. 3, the Markov model of Fig. 4 can be obtained. In this model, 19 states are considered. The first state in this model is "a b c d e f" where all rotors are fully operational. If during the mission one of the rotors fails (for example the one labeled "a"), then with the failure rate of 𝜆 𝑎 Δ𝑡the system goes to the "b c d e f" state. In the state: b c d e f", if the rotor "f" or "b" fails, then the systems goes to the "Failure" state. With all these possible failures in the hexacopter, the following model will be constructed. (For more information about the operational and failure modes based on the controllability theory please refer to (Shi, Yang, & Quan, 2016)).

Fig. 4 .

 4 Fig. 4. Reliability Markov model of a hexacopter with PNPNPN configuration.

Fig. 5 .

 5 Fig. 5. Simplified reliability Markov model of Hexacopter with PNPNPN configuration.

Fig. 6 .

 6 Fig. 6. Reliability evaluation of Multirotors (Quadcopter and Hex-copter) vs. time with failure rate of 0.04 failure/hour