Thiago Nepomuceno
email: thiago.nepomuceno@scs.fhg.de

Tiago Carneiro
email: tiago.carneiro-pessoa@inria.fr

Paulo Henrique Maia
email: pauloh.maia@uece.br

Muhammad Adnan
email: adnanmd@scs.fhg.de

Thalyson Nepomuceno
email: thalyson.silva@ifce.edu.br

Alexander Martin
email: alexander.martin@fau.de

Thiago Nepomuceno

Thalyson Nepomuceno

Autoiot

AutoIoT: a Framework based on User-driven MDE for Generating IoT Applications

Keywords: Computer systems organization → Sensors and actuators, • Software and its engineering → Software prototyping, Code Generation, User-driven, MDE, IoT application

Developing an Internet of Things (IoT) system requires knowledge in many different technologies like embedded programming, web technologies, and data science. Model-Driven Engineering (MDE) techniques have been used as a concrete alternative to boost IoT application development. However, the current MDE-to-IoT solutions require expertise from the end-users in MDE concepts and sometimes even in specific tools, such as the Eclipse Modelling Framework, which may hinder their adoption in a broader context. To tackle this problem, this work proposes AutoIoT, a framework for creating IoT applications based on a user-driven MDE approach. The proposed framework allows users to model their IoT systems using a simple JSON file and, through internal model-to-model and model-to-text transformations, generates a ready-to-use IoT serverside application. The proposed approach was evaluated through an experiment, in which 54 developers used AutoIoT to create a server-side application for a real-world IoT scenario and answered a post-study questionnaire. The experiment reports the efficacy of AutoIoT and user satisfaction of more than 80% through 6 out of 7 evaluated criteria.

INTRODUCTION

Over the past years, the interest in the Internet of Things (IoT) technologies has grown both in industry and academia due to its wide range of applications, including smart homes, smart healthcare, smart grids, smart cities, and smart factories [START_REF] Shih | Designing CPS/IoT applications for smart buildings and cities[END_REF]. IoT projects usually share some essential features, such as sending and receiving data to/from devices, analyzing and visualizing data, and providing a user management system [START_REF] Al-Fuqaha | Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications[END_REF].

A complete IoT system is composed of four different layers [START_REF] Mora | RapIoT Toolkit: Rapid Prototyping of Collaborative Internet of Things Applications[END_REF]: device layer, gateway, a server-side application, and data analysis. The usual data flow in an IoT system starts when a device sends it's sensor data using low-level communication protocols (e.g., sockets) to a gateway. Then, the gateway transforms the binary data received into a more human readable format (e.g., JSON) and sends it to the server-side application, which is responsible for collecting and storing the data in a database. Additionally, the server application can also provide features like a virtual representation of the devices, a Graphical User Interface (GUI) to visualize the data, a user management system, and ways to share collected data with third-party systems (e.g., via an API or a message queue). Finally, the data analysis subsystem accesses the data stored and produces useful insights to help the users of the IoT system to understand their data and to take decisions accordingly.

In some cases, an IoT system does not need all four layers. Examples include (i) when devices are powerful enough to support internet protocols a gateway is not needed; (ii) in prototypes or simpler systems the data analysis layer is not required; and (iii) in some cases, even the server-side application is not needed, since devices can communicate directly between them autonomously. Developing a complete IoT system requires expertise in many different technologies like embedded programming, web technologies, and data science. Given the complexity of the task, some tools and platforms have been created to support developers. The better well-known solutions are the platforms created by big companies like Google 1 , Amazon 2 , and Microsoft 3 . However, costs associated with the provided services, as well as the vendor lock-in, may hinder the adoption of such solutions for some smaller or more specific IoT projects.

Alternatively, Model-Driven Engineering (MDE) has been gaining attention from both academia and industry in recent years as a concrete solution to ease the development of IoT systems through automatic code generation to different hardware devices [START_REF] Nguyen | FRASAD: A framework for model-driven IoT Application Development[END_REF] and server-side application platforms [START_REF] Brambilla | Model-driven development of user interfaces for IoT systems via domain-specific components and patterns[END_REF][START_REF] Gianni | RapIoT toolkit: Rapid prototyping of collaborative Internet of Things applications[END_REF][START_REF] Morin | Model-Based Software Engineering to Tame the IoT Jungle[END_REF][START_REF] Pramudianto | Connecting the Internet of Things rapidly through a model driven approach[END_REF]. Nonetheless, most of those approaches to build IoT applications present at least one of the following drawbacks: (i) they are based on a strong modeling phase with complex meta-models that are designed to cover a wide range of different scenarios, hence requiring time and modeling expertise; (ii) they generate only boilerplate code of the application, demanding developers to write most of the application logic by hand; and (iii) they require expertise in tools that are standard in the MDE community, but not well known in the industry, like the Eclipse Modeling Framework (EMF) suite.

According to a definition given by Abrahão et. al. [START_REF] Abrahão | User Experience for Model-Driven Engineering: Challenges and Future Directions[END_REF], those work are considered as technology-driven approaches, in which the primary goal is to improve existing MDE techniques, usually making them more general in order to cover a broader range of use cases, and not to improve the usability or to ease the adoption by a general target audience. Most of those works require their audience to became MDE experts, learning theory and techniques commonly used in the MDE field. On the other hand, in a userdriven approach [START_REF] Abrahão | User Experience for Model-Driven Engineering: Challenges and Future Directions[END_REF], the user knowledge and necessities guide the development of the new MDE approach. This way, such approach should provide tools that help to bridge the gap between what its users already know and what is expected from them to know to use the new tools/methods, making the adoption easier.

Previous work have already followed the premise behind userdriven MDE approaches. GenApp [START_REF] Savelyev | GenApp: Extensible tool for rapid generation of web and native GUI applications[END_REF], for example, is a tool for building entirely functioning science gateways and standalone GUI applications from collections of definition files and libraries of code fragments, and Json-GUI [START_REF] Galizia | Json-GUI-A module for the dynamic generation of form-based web interfaces[END_REF] is an AngularJS front-end module that dynamically allows data scientists and web form users to generate form-based web interfaces. However, to the best of our knowledge, we have not found any work that applies the concepts of user-driven MDE for the design and development of IoT applications. This kind of approach would benefit not only experienced IoT developers to boost the application creation by reducing development time, but also introducing new ways to build IoT systems to developers and practitioners by decreasing the technology learning curve.

In this realm, this work proposes a framework, called AutoIoT, for generating IoT server-side applications that relies on a userdriven MDE approach. This way, AutoIoT allows users to model their IoT system using a simple JSON file and through internal model-to-model transformation and code generation techniques, to create automatically the IoT server-side application. Furthermore, IoT developers that have some expertise in MDE can extend Au-toIoT by creating specific components, called Specialized Builders, that are responsible for generating the source code of specific IoT applications. The proposed framework is evaluated with users with different backgrounds who modeled and developed a real IoT serverside application. The results indicate that the users were able to create the application correctly and in a short time with no or little knowledge in MDE.

The remainder of this document is organized as follows: Section 2 presents the most related work. Section 3 introduces the AutoIoT Framework, describing the user-driven process and implementation details. Next, Section 4 details the evaluation of AutoIoT in an industrial use case and its findings and Section 5 briefly discuss how to use AutoIoT in more complex use cases. Finally, the conclusions are outlined in Section 6.

RELATED WORK

Previous work have already used MDE technologies to ease the development of IoT server-side applications. We describe some of these approaches as follows.

Brambilla, Umuhoza, and Acerbis [START_REF] Brambilla | Model-driven development of user interfaces for IoT systems via domain-specific components and patterns[END_REF] propose a model-driven approach to design IoT Graphical User Interfaces (GUI). The work defines both specific components and design patterns using a visual modeling language for IoT applications and discusses the importance of having good GUI to improve the acceptance of the IoT system and to model the user interactions with the GUI. The paper discusses the back-end software and how it stores and retrieves information from a database, but it is not clear whether the proposed approach also generates those components or not. The approach requires users to have expertise in MDE and Interaction Flow Modeling Language (IFML).

ThingML (Internet of Things Modeling Language) [START_REF] Morin | Model-Based Software Engineering to Tame the IoT Jungle[END_REF] is an MDE approach that aims to cover a considerable amount of IoT use cases. It is already in a more advanced stage of development when compared with other MDE-to-IoT solutions and is especially attractive to teams with MDE experts. According to the authors, the main contribution of the project is a code generation framework and an associated methodology to give practitioners full control of the code by letting them easily customize compilers for their needs. To accomplish this, expertise in MDE and Domain Specific Language (DSL) is required.

Pramudianto et al. [START_REF] Pramudianto | Connecting the Internet of Things rapidly through a model driven approach[END_REF][START_REF] Pramudianto | IoT Link: An Internet of Things Prototyping Toolkit[END_REF] proposes IoTLink, which aims to hide many of the required expertise to develop an IoT server-side application behind a Flow-Based Programming interface. It targets inexperienced developers entering the IoT development, allowing them to create a ready-to-use application in minutes. While IoTLink makes an important step and is aware of the limited expertise of developers, it still requires developers to learn new skills to get started with the tool, like Flow-Based Programming and the Eclipse Modeling Framework. Additionally, the resulting system lacks some essential features usually requested in an IoT application, like a GUI.

All aforementioned work require some level of MDE expertise to create IoT applications, which may hinder their adoption. In contrast, AutoIoT has been designed based on a user-driven MDE approach and uses only technologies that its target audience already knows, like JSON representation and a general programming language 4 . This way, IoT and Web developers with no or little knowledge in MDE techniques can design and generate ready-touse IoT server-side applications, thus reducing development effort and the technology learning curve. Finally, AutoIoT does not intend to replace more complete MDEto-IoT approaches (e.g., ThingML), since these approaches are designed to cover a broader range of IoT use cases. Instead, it proposes a solution that allows developers to get some of the benefits of MDE without the need of learning new technologies.

AUTOIOT FRAMEWORK

This section presents the proposed framework for generating IoT server-side applications. Initially, a simple motivating example that will be used throughout this section is presented and, subsequently, the user-driven MDE process is described. After that, one type of a Specialized Builder component is detailed. Finally, implementation issues about the framework are presented.

This work focuses on how AutoIoT can be used to create a prototype for the motivating example, but all the concepts presented can be expanded to cover a more complex IoT use case, as discussed in Section 5.

Motivating example

The use case presented in this section consists of smart containers that send information about location, temperature, and filling status (whether the container is empty or not). In this scenario, the IoT device is a hardware module attached to each container, as shown in Figure 1, that sends sensor data to a base station using a proprietary communication protocol called MIOTY, it is similar to LoRa protocol and has a range of 15 kilometers. Then, the base station, which is connected to the Internet and works as a gateway, transmits data to the server-side application through the MQTT protocol. In turn, the server-side application is also in the Internet, hosted on a cloud server. The data sent by the base station is codified in JSON format and contains the location of the box (GPS), temperature, and filling status.

The server software in this scenario needs to (i) create a virtual representation of the container. Additionally, it (ii) receives and processes messages from the base station (using MQTT protocol), and links received data to the correspondent virtual device. Furthermore, it also needs (iii) to store sensor data in a database and (iv) to provide a GUI for easing the user interaction with the system and visualization of data, both historical (from the database) and real-time data. Finally, the system should (v) provide an API that allows project partners (third-party systems) to access the stored data.

The User-driven MDE Process

The MDE process proposed by this work, as shown in Figure 2, is composed of three main phases: modeling the IoT Scenario, generating server-side application code, and extending the source code. The first two phases are mandatory, while the last one is optional. Each phase is detailed as follow.

3.2.1

Modeling the IoT Scenario. The process starts with the developer modeling the IoT scenario, which is defined according to the meta-model depicted by Figure 3. The meta-model defines an IoT project and its components, i.e., devices, sensors and the data sent by them, besides the system communication with devices or third-party applications through communication protocols (MQTT, HTTP, and WebSockets) and the connection to a database. Additionally, it can also describe the data visualization using dashboards and components, such as tables, charts, and maps.

The meta-model has been created based on our experience on developing several IoT projects for both research and industry in Fraunhofer SCS. It can not be considered complete and does not intend to cover all IoT use cases. Its main goal is to provide all information needed by the current Specialized Builders, and when new Builders are created, the meta-model will be updated accordingly.

Figure 3 depicts components represented by either dotted or continuous lines. A valid model that conforms to the proposed meta-model only needs to define the continuous-line components. The dotted-line ones are optional and will be generated by using a model-to-model transformation (M2M). This way, the code attribute in Topic, Endpoint, WebSockets and Dashboard does not need to be defined by the developer in the application model. Only a description of the system is required, removing the need for defining any business logic in the modeling phase.

To model the IoT scenario, users can write the JSON file manually or use a Web GUI that will generate such a file. Independently of the chosen method, the final result of the modeling phase is always a JSON file containing the model representing the system, and that is in accordance with the meta-model presented in Figure 3.

Considering the example of the smart container, a model used as input to AutoIoT can be seen in Listing 1. In this example, the developer only gives information about the continuous-line components: the project, database, MQTT broker configuration, and the device and its sensor. The device's fields in line 19 represents attributes of the device itself and are not supposed to change very often. The same happens for the sensor's fields in line 26. However, in addition to fields, sensors can have data_fields that represents the data that is regularly sent by this kind of sensor to the server application.

The JSON file is the only artifact created by the user during the modeling phase and the only expertise required is knowing the JSON syntax (if the file is written manually, without the GUI). Developers extensively use JSON to exchange data between systems and most of the General Programming Languages have native support to JSON. After the modeling is completed, AutoIoT loads the content of the model file using a function. The first step is to validate and transform the JSON file into Python objects using the Pydantic5 library. After that, the framework finally delivers these objects to the appropriated Builder that will generate the application code.

3.2.2

Generating server-side application code. After the modeling phase is finished, the created model is used as input to a Specialized Builder that starts an M2M transformation. Then, the extended model goes to an M2T transformation phase that generates the source code of an IoT server-side application. The type of application generated depends on the Builder used. This work implements the Prototype Builder (PB), a Specialized Builder that produces an IoT system to manage IoT devices. The PB, the M2M, and the M2T transformations are detailed in Section 3.3. Listing 2 presents a small example of the AutoIoT Framework being used to load a project.json file and shows how to generate the IoT server-side application using a Specialized Builder.

The build method is responsible for applying the M2M and M2T transformation to the model created by the load_project method. In turn, the parameters of the build method are the chosen Specialized Builder, the output folder and a dictionary with additional configuration. In this example the Prototype Builder is used, and the Docker6 deployment is set to false.

3.2.3

Extending the generated code. After the source code generation, the developer has the choice to extend it to fulfill further requirements of the project or use the generated application as is. The generated application is already ready-to-use, and it can be executed locally or deployed on a cloud server.

Prototype Builder

AutoIoT provides an implemented Specialized Builder called Prototype Builder (PB). It has been chosen as the first Specialized Builder due to its wide use as a server-side application in several IoT projects, since every project usually needs a prototype and most IoT scenarios need to communicate with and manage IoT devices. The PB generates a Flask application 7 written in Python, HTML, CSS, and Javascript. The generated server-side application communicates with IoT devices and third-party system through MQTT, Rest API, and WebSockets. Moreover, the generated application manages IoT devices (creates, edits and deletes them), stores and visualizes sensor data sent by them. Additionally, it also provides a user management feature that controls access to the stored data.

Figure 4 outlines more Specialized Builders that are planned for future work. Each Specialized Builder should follow the metamodel proposed by this work. However, the set of components that are mandatory (continuous line) or optional (dotted-line) can vary from one Builder to another. Each Builder has to implement an M2M transformation that extends the input model adding custom components (dotted-line components) and an M2T transformation that generates the final application source code.

To create the PB, the abstract class Builder is extended as shown in Figure 4. The Builder class has a set of abstract methods that need to be implemented by the Prototype Builder class. The most important ones are extend, which performs the M2M transformation, and generate that is responsible for the M2T transformation Each triggered function receives as input a component defined in the model and generates part of the IoT application source code. For example, whenever the search finds a Device type component, the found_device function is triggered. It receives the Device object as input and generates a Python class that represents this type of Device. Furthermore, the found_device function also generates a controller class to feed the GUI with information from the database concerning this type of device. Additionally, it also generates HTML files that list the devices stored in the database and performs the CRUD operations (Create, Read, Update and Delete). However, in case the graph search finds a Dashboard instead of a Device, it triggers a different function that generates HTML, CSS, and Javascript files that compounds the GUI.

At the end of the M2T transformation process, the PB generates the source code of a Flask project. This project is written in Python, HTML, CSS, and Javascript, communicates with IoT devices, and stores its sensor data in a database. The Flask project supports different communication protocols (e.g., HTTP, Web Sockets and MQTT) that allows third-party systems to communicate using various web technologies. Furthermore, it provides a GUI that can be used to manage the IoT devices, and visualizes sensor data using tables, charts, and maps updated in real time. Finally, it also provides a user management system to allows different levels of access to the stored data. Figure 5 depicts a dashboard page of the system generated for the smart container motivating example.

Implementation Details

AutoIoT Framework is implemented using Python 3 and uses the Pydantic library to provide model (JSON file) validation and processing.

The Jinja is the default template engine used for the M2T transformation (but other options can be used). It is the standard template engine used by the Flask framework, which is used to render HTML pages. Since developers are already familiar with its syntax, they can easily change the templates if there is a need for it.

To help developers implement both transformations (M2M and M2T), the Builder class provides a function that goes through the whole model and triggers functions depending on the type of the component found during the search as already described in Section 3.3. After the implementation of the callback functions, which are triggered when the search find each type of component, the Specialized Builder became very simple as shown in Listing 3. Listing 3: A simplified example of a Specialized Builder class. This is not a working source code, some parts like libraries importing and inheritance specific details were removed to increase the overall readability.

Other Specialized Builders can be created by developers and incorporated to AutoIoT (as shown in Figure 4). The only restriction is that it receives as input a JSON object containing a model that follows the proposed meta-model as shown in Listing 2. There are no restrictions about the type of system the Specialized Builder can generate (Web, Mobile or Desktop) or the underlying programming language used to implement it. Even that anyone can create a Builder and incorporate to AutoIoT, in a normal workflow developers do not need to create any Specialized Builders since most of the Builders are provided by the AutoIoT Framework itself or its community, similar to how it happens when choosing a third-party programming library.

EVALUATION

To evaluate the AutoIoT framework an experiment has been conducted. It consists of using AutoIoT to generate the server-side application of an IoT use case, extracted from one of our industrial projects. After trying AutoIoT, the developers answered a poststudy questionnaire to evaluate their experience. This helps us to understand what technologies should be used when developing tools for this target audience: IoT and Web developers.

In the rest of this section the use case, the experiment, and the results are detailed.

Experiment

To evaluate the proposed framework an experiment was conducted. First, 5 developers from both academy and industry were invited to use AutoIoT to develop the application for the use case described in Section 3.1 and answer the post-study questionnaire (available on Google Forms9 ). This initial phase was used to improve both the experiment and the questionnaire itself.

In the second phase of the experiment, developers from different companies and research labs around the world were invited to try AutoIoT. The only requirement needed was to have previous experience with IoT or Web development. In total, 54 developers finished the experiment and completed the questionnaire. The evaluation was performed by 17 -56 years old participants (Mdn = 28.81, Std = 7.56), with qualification ranging from Doctorate to no technical qualification at all. The two most common qualification levels have a Bachelor and Master degree, corresponding to of the total of participants (17 participants has each qualification). Most of the participants declared to have between 5 to 8 years of experience in programming (38.89% of the participants).

The experiment consisted of downloading a zip file containing AutoIoT, a device Simulator software and a tutorial that describes the same scenario introduced in Section 3.1. This very simple scenario was chosen to make the evaluation process simpler, since some of the participants are Web developers with no expertise in IoT, a simpler use case allows them to understand and evaluate the framework better. In Section 5 is discussed briefly how to use AutoIoT in more complex IoT use cases.

The tutorial also describe the steps required to accomplish the task. The task consists of (i) using AutoIoT to generate the application source code for the given scenario, (ii) running the generated software and (iii) simulate the smart containers through the provided Simulator software.

After completing the tutorial, the participants were asked to answer a post-study questionnaire. The questions are presented as statements (S1-7) and are divided into two groups. The first group evaluates AutoIoT itself, and the participants should choose the answer from a five-point Likert scale ranging from agree to disagree.

• S1 -The system generated by AutoIoT cover the requirements of the scenario. • S2 -After reading the project description file I could easily change the configuration to cover a scenario with different IoT devices. • S3 -I would spend more than 40 working hours to manually codify the same system generated by AutoIoT.

• S4 -The code generated by AutoIoT is well organized and easy to understand. • S5 -If I had to change the generated code and change the way that the sensor data is handled, I would know which file I should change. (Example: Instead of just store the received data in the database, inspect it and check if the "filling_status" is equal to zero, if so send an email/message to administrators informing that the container is empty). • S6 -Use AutoIoT to generate the server application was easy.

• S7 -I could use AutoIoT to generate the server-side application in some of my IoT projects in the future.

The questionnaire was designed to evaluate whether the code generated by AutoIoT works and cover the requirements of the proposed scenario (S1). Additionally, it was evaluated whether the developers could use AutoIoT to cover different IoT scenarios, whether the generated source code was easy to understand, and whether developers were able to extend the code to fulfill further project requirements (S2, S4, and S5, respectively). One of the main benefits of using an MDE approach with code generation is to save development time, this aspect was also evaluated (S3). Finally, developers were asked if their experience using AutoIoT was easy and if they could use the framework to develop future IoT projects (S6 and S7, respectively).

The main objective of this work is to provide a tool that uses technologies that developers already know, removing the need for having a long learning phase and easing its adoption. Additionally to the evaluation of AutoIoT itself, it is important to know the expertise of the developers regarding different technologies. Therefore, the second group of questions asked how much experience the participants had regarding the following technologies.

• General Programming Language (e.g. Python, Java, C++, etc.) • Internet of Things Development (e.g. MQTT Protocol, IoT projects, etc.) • Domain Specific Languages (e.g. WebRatio, OCL, ThingML, etc.) • Flow-Based Programming (e.g. Node-RED) • Model Driven Engineering (e.g. models, system modeling, model transformations, etc.)

After gathering feedback from the participants, the evaluation of the results was conducted.

Results

Since the group of developers that participated in the experiment consists of professional Web developers and IoT researchers, it was expected that most of them show expertise in General Programming Languages and Internet of Things technologies as depicted in Figure 6. Few developers reported expertise in Domain Specific Languages and Model-Driven Engineering. This finding supports our choice of not including any of these technologies, at least not in a way visible to developers. Results also show that few developers have expertise in Flow-Based programming, a technology commonly employed to quickly model the behavior of a system (used by Pramudianto [START_REF] Pramudianto | IoT Link: An Internet of Things Prototyping Toolkit[END_REF] and Node-Red, for example). To better understand the groups with different expertise, the participants were divided in three groups (with possible intersections): (i) participants with no expertise in MDE, (ii) participants with expertise in MDE and (iii) IoT experts.

The participants with no expertise in MDE represent 86% of the total and reacted positively to all aspects evaluated. 97% of the participants agreed that the system generated by AutoIoT cover the requirements of the scenario (S1) and all of them agreed that using AutoIoT to generate the server application was easy (S6), as can be seen in Figure 7. In turn, 71.73% of the participants agreed that it is easy to use AutoIoT in a different IoT scenario (S2) and 84.78% agreed that they could use AutoIoT in a future IoT project (S7). Only 4.34% and 6.52% of the participants had difficulties in understanding the generated code (S4) and changing the behavior of the generated system (S5), respectively. Finally, 93.47% of the participants agree that AutoIoT saves development time and that replicating the software produced by AutoIoT manually would cost them more than 40 hours of work (S3).

No participants of the group containing MDE experts disagreed with S1, S4, S6, and S7, but 12.5% of them disagree about the time necessary to create the same application generated by AutoIoT (S3), the easiness of change the JSON file for a different scenario (S2) and about how easy would be to change the behaviour of the generated system (S5).

In the last group (Figure 9), containing participants with expertise in IoT development, 96.55% of them agreed that the generated application cover all requirements of the scenario (S1). All of them agreed that develop the generated system manually would take more than 40 hours (S3) and that use AutoIoT was easy (S6). 93.10% of them agreed that they would easily apply AutoIoT in a scenario with different devices (S2) and 89.65% agreed that they could use AutoIoT in future IoT projects (S7). Finally, only 3.44% thinks that the generated code was not well organized (S4), and 6.89% of them were not able to extend the generated system (S5).

Discussion

Overall, all participants were satisfied with the system generated by AutoIoT and its easy(and ready)-to-use feature. The results of the evaluation show that the user-driven approach proposed by this work and the AutoIoT framework accomplish its goals, providing a tool that helps developers quickly create IoT server-side applications with no need to learn new technologies, as shown by the group with no MDE expertise (Figure 7).

The experiment also shows that the group with MDE expertise is slightly more resistant to the AutoIoT approach (as shown in Figure 8), 12.5% of them had difficulties changing the model (the JSON file) and extending the generated source code. This probably happens because they are used to other kind of model representation and it is not common, in a traditional MDE approach, to ask users to change the generated source code. Usually the user rarely update the generate code and, if a different output is desired, the models or the transformation usually need to be changed.

While working with models is natural to system designers and MDE experts, it is mainly avoided by common developers. Mostly of the participants of the experiment showed no modeling expertise and are used to work in the source code directly (Figure 6), using AutoIoT as a tool to speed up the development in the initial phase of the project. Additionally, 12.5% of the participants with MDE expertise disagree that they would take more than 40 hours of work to manually develop the system generated by AutoIoT.

It is possible that the participants were already considering tools that they know that could speed up the development process. This is a preliminary result, only 8 out of the 54 participants that participated in the experiment declared to have expertise in MDE. This is expected since MDE experts are not the target audience for this work. To better understand this group, further studies including more MDE experts are needed.

The group with expertise in IoT mostly contains no MDE experts, so its evaluation is very similar to the first group. The main difference between both groups is that IoT developers are familiar with the difficulties of developing the application to the proposed scenario. All of them agreed that they would take more than 40 hours of work to implement the application generated by AutoIoT.

This work also shows that Web and IoT developers do not have expertise in many of the technologies required to use conventional MDE-to-IoT approaches. This finding goes in accordance with [START_REF] Gorschek | On the use of software design models in software development practice: An empirical investigation[END_REF], which found that less than 11% of a total of 3785 surveyed professional developers use any form of modeling (even sketches in a whiteboard) during the development, and most of them do not know or do not remember formal notations, like UML.

Finally, it is important to highlight that none of the developers had any assistance other than the step-by-step tutorial provided during the experiment. Personal assistance or further documentation about AutoIoT were not provided. The lack of documentation may be the reason behind some of the participants (7.40% of all participants) were not sure about how to extend the generated code (S5).

MORE COMPLEX USE CASES

The system generated by the Prototype Builder (PB) is excellent for prototyping development or scenarios that are very similar to the one presented in Section 3.1, but since it is based on a monolith architecture, it would be hard to adapt its source code to more complex IoT scenarios.

In bigger IoT projects, it is common to use a microservice architecture [START_REF] Vandikas | Microservices in IoT clouds[END_REF], in which the complete system is composed of multiple small independent services that communicate to each other using lightweight mechanisms. In those scenarios, AutoIoT could be used to generate some of these services, like a Device Twin Service, MQTT Message Processing Service, Report Generator Service or a GUI, for example. This way, the complete solution would be composed by manually written software in conjunction with the ones generated automatically by AutoIoT.

The main advantage in use AutoIoT compared to hand-written software is that AutoIoT automatically adapts to the characteristics of the devices and sensors that are going to be used in the new project. This means that changing one file (the JSON file that contains the model) AutoIoT is able to generate multiple readyto-use microservices that can be automatically incorporated into the new project, with little-to-no change in the generated source code. Without AutoIoT, either the microservices would need to be implemented or previous source code would need to be adapted, increasing the cost of the project.

Furthermore, the microservices created by the Specialized Builders could also work in collaboration with other open-source projects like Node-RED, Eclipse Hono and Eclipse Ditto, for example.

CONCLUSION

With the growth of IoT applications, new IoT-specific technologies have also arisen. In order to avoid the overload of such technologies, many approaches have advocated the adoption of MDE with a promise of long term benefits, but most of these work achieved limited success due to the use of tools and concepts very well known in the MDE community, but less used outside of it [START_REF] Sánchez Cuadrado | Applying model-driven engineering in small software enterprises[END_REF][START_REF] Hamou-Lhadj | The Impact of the Model-Driven Approach to Software Engineering on Software Engineering Education[END_REF][START_REF] Hutchinson | Model-driven engineering practices in industry: Social, organizational and managerial factors that lead to success or failure[END_REF]. This work proposed AutoIoT, a framework based on a user-driven MDE approach to develop IoT server-side applications. By using it, users can model their IoT scenarios either graphically (Web GUI) or textually (manually writing a JSON file) and, through internal M2M and M2T transformations carried by Specialized Builder components, the source code of the IoT application is automatically created. During the modelling developers only need to use technologies that they are used to work with (JSON representation and a general programming language), thus decreasing the learning phase and easing the framework adoption.

According to the initial evaluation, AutoIoT can successfully be used to speed up the development of IoT server-side applications and has been well received by Web and IoT developers. The participants of the evaluation reported more than 80% of satisfaction in 6 out of 7 evaluated criteria. Due to lack of documentation about the framework and the system generated by it during the experiment, only 74% of the participants reported being able to extend the generated system. This problem will be addressed in future versions.

This work shows how to design an user-driven MDE approach with very simplified modeling phase, while still giving users some freedom and control over the system to be generated. Additionally, it demonstrates that hiding MDE concepts behind technologies that users already know has a great impact on user satisfaction and adoption of the approach. Furthermore, it does not intend to replace existing MDE-to-IoT approaches. Instead, it gives developers an option to get some benefits of MDE methods without the need of learning MDE theory or using very specific MDE tools. Finally, this work does not tackle all layers of a complete IoT system development, but rather focuses only on developing the serverside application part. It does not generate device, gateway or data analysis source code in the current stage.

As future work it is planned the release of more Specialized Builders that will allow AutoIoT to be used to create IoT systems following the microservice architecture and tackle more complex IoT use cases. Additionally, it is intended to create a better AutoIoT ecosystem, publishing the source code of the framework at the Github and creating a website where users can share information and custom created Specialized Builders.

Further information about AutoIoT Framework and its related projects can be found on Github10 .

ACKNOWLEDGEMENT

The research was partially supported by the Bavarian State Ministry of Economic Affairs, Regional Development and Energy (StMWi) through the Center for Analytics -Data -Applications (ADA-Center) and as part of the lead project "Technologies and Solutions

Figure 1 :

 1 Figure 1: The hardware device and its sensors are attached to a container. The device includes a temperature, position (GPS) and filling status sensors. This picture shows a prototype of the smart container where all sensors are visible, not the final product.

FieldFigure 3 :

 3 Figure 3: The meta-model that defines an IoT project and its components. Components represented by continuous line are obligatory and need to be present in the model created based on this meta-model. Components represented by dotted line are optional and will be generated using a model-to-model transformation (M2M) (explained in Section 3.2).

1 { 2 "project": { 3 " 4 " 12 " 13 " 15 "Listing 1 :

 12341213151 name": "Container Management Project", description": "The Container Management Project.", hostname": "iot.eclipse.org", devices": [ "name": "Container", 18 "description": "An IoT device that sends temperature, position and filing status.", Example of a model represented in JSON format

from autoiot import AutoIoT 1 from 6 Listing 2 :

 162 ('project.json') 5 autoiot.build(PrototypeBuilder, 'output/project', {'docker': False}) Using AutoIoT to load a model file and generate an IoT server-side application

1 from

 1

Figure 5 :

 5 Figure 5: A dashboard page of the prototype application generated by the Prototype Builder for the motivating scenario. It allows visualisation of the data sent by a container, including basic information about the container and its sensor data (temperature, position and filing status).

Figure 6 :

 6 Figure 6: The percentage of developers that declared to have experience 4 or 5 (in a 1-5 scale) in a given technology.

Figure 7 :

 7 Figure 7: Questionnaire results from the participants with no expertise in MDE.

Figure 8 :

 8 Figure 8: Questionnaire results from the participants with expertise in MDE.

Figure 9 :

 9 Figure 9: Questionnaire results from the participants with expertise in IoT.

  Figure2: The developer starts the process by creating the model that represents the IoT scenario. It can be done using a GUI, programming library or a simple JSON file. The defined model is the input for a Specialized Builder that, through M2M and M2T transformation, generates the IoT server-side application source code. Optionally, the developer can also extend the generated application to fulfill further requirements.

		Generate the application
		code using a Specialized
		Builder
	the	M2M
	IoT Scenario	Transformation
	Developer
		Transformation	Need to the generated system?	No	IoT Server-side Application
			Yes
			Extend the source
			code of the
			generated system
			Project
			+ name : EString
			+ description : EString
			+ app_port : EInteger
			Device
			+ name : EString
			+ description : EString
			Sensor
			+ name : EString

  Device component in the original model, it creates a Topic, HTTP API, WebSocket and Dashboard components and includes them in the original model.3.3.2 M2TTransformation. Similar to the process described in the M2M transformation (Section 3.3.1), in the M2T transformation the PB also visits each node of the graph and checks its type. For each different type, it triggers a different function that generates source code for the application using the templating technique. The default templating engine used by AutoIoT is Jinja 8 , commonly used inside the Flask Framework to render HTML content.

	(Section 3.3.1 and Section 3.3.2). Following the transformations
	executed by the PB are detailed.
	3.3.1 M2M Transformation. When the model defined by the user
	is loaded by AutoIoT (line 5 of Listing 2) it is validated, processed
	and stored in memory as a graph, whose nodes are components
	of the model. The M2M transformation consists of visiting each
	node of the graph and checking its type. Examples of types include
	Project, MQTT, Database, Device and Sensor. For each type of com-
	ponent, the transformation creates specific dotted-line components
	and attaches them to the input model. For example, whenever the
	transformation finds a
		«abstract class»
		Builder
	Specialized Builders
	Prototype	Device Twin	Flutter App
	Builder	Builder	Builder
	Prototype application to manage different IoT devices	A microservice that provides a REST API and create an abstraction of IoT devices	Flutter App source code that can be compiled to Android or iOS
	Figure 4: A developer can create Specialized Builders extend-
	ing the abstract class Builder provided by AutoIoT. Each
	Builder receives the same model but produces different ap-
	plications. The generated application can follows a mono-

7

http://flask.pocoo.org/ lith architecture like the application generated by the Prototype Builder, a microservice architecture like one generated by the Device Twin Builder or even create a complete mobile application if the Flutter App Builder is used.

https://cloud.google.com/iot-core/

https://aws.amazon.com/iot/

https://azure.microsoft.com/en-us/services/iot-hub/

Currently the AutoIoT framework is available only in Python, but ports to other programming languages are planned

https://github.com/samuelcolvin/pydantic

Docker is a tool designed to make easier to deploy, run and maintain applications by using containers technology.

http://jinja.pocoo.org/

https://forms.gle/m2BBKmWJfNxiiexA6

https://github.com/AutoIoT for Digitalized Value Creation" within the framework of "BAYERN DIGITAL II"


Stéphane Caro
email: stephane.caro@ls2n.fr

Jean-Pierre Merlet

J-P Merlet

Failure Analysis of a Collaborative 4-1 Cable-Driven Parallel Robot

Keywords: cable-driven parallel robot, cable sagging, failure, safety, collaborative

Cable-Driven Parallel Robots (CDPRs) have been little used so far for collaborative tasks with humans. One reason is the lack of solutions to guarantee the safety of the operators in case of failure. Therefore, this paper aims to determine the possible failures of CDPRs when they are used for collaborative work with humans and to provide technical solutions to ensure the safety of the operators. A translational three degrees-of-freedom CDPR composed of four cables connected to a point-mass end-effector is considered as an illustrative example. The cables are supposed to be ideal, namely, they are not elastic and do not exhibit sagging.

Introduction

Cable-driven parallel robots (CDPR) are a special class of parallel robot where the rigid legs/links of a classical parallel robot (CPR) are substituted by cables that can be wound or unwound. This type of actuation offers a lower mechanical complexity (passive joints may not be used) compared to CPR and, more importantly, a wider range of leg lengths, thereby allowing for a larger workspace. In this paper we will consider a specific CDPR, the so-called N -1 CDPR, having N cables that are all attached to the same point B on the platform, whose center of mass is below this point. The cable lengths L 0 are changed by using rotary winches, whose rotations are measured by encoders. Provided that N ≥ 3, such a CDPR is a 3-dof robot allowing only translational motion of the load, which is appropriate for many tasks [START_REF] Alikhani | Design of a large-scale cable-driven robot with translational motion[END_REF][START_REF] Borgstrom | Discrete trajectory control algorithms for NIMS3D, an autonomous underconstrained three-dimensional cabled robot[END_REF], e.g. for 3D printing [START_REF] Barnett | Large-scale 3d printing with a cable-suspended robot[END_REF] or metrology [START_REF] Williams | 3D cable-based cartesian metrology system[END_REF]. Basic control of the CDPR is based on a feedback loop on the L 0 that are estimated by using the measurement of the rotation angle of the winches. In the scope of this paper, the cables are supposed to be ideal, namely, they are not elastic and do not exhibit sagging. They are made up of synthetic material and, as a consequence, do not exhibit the dangerous whip effect of steel cables. As the winches are assumed to be irreversible, there won't be any change in cable lengths if they are not actuated.

Furthermore, the winch dynamics is supposed to be not sufficient to correct the fast motion of the load during a failure. F 0 (x, y, z) denotes the reference with z the vertical axis.

This paper aims to determine the possible failures of CDPRs when they are used for collaborative work with humans, especially failures that may lead to a danger for the human operators. Failures of parallel robots have been addressed in [START_REF] Notash | On the design of fault tolerant parallel manipulators[END_REF][START_REF] Roberts | Characterizing optimally fault-tolerant manipulators based on relative manipulability indices[END_REF][START_REF] Ukidve | Parallel manipulators, Towards new applications, chap. Quantifying and optimizing failure tolerance of a class of parallel manipulators[END_REF] and for CDPR in [START_REF] Moradi | Stiffness analysis of cable-driven parallel robot[END_REF][START_REF] Notash | Failure recovery for wrench capability of wire-actuated parallel manipulators[END_REF], but not with the purpose of ensuring the safety of co-workers.

Kineto-static analysis of a 4-1 CDPR

Being given the platform pose of a CDPR the lengths of the 4 cables are uniquely determined. On the other hand as soon as the lengths of 3 cables under tension are fixed, then the platform pose will be fully determined. As the cable lengths are never exactly measured we are not able to reach a platform pose, for which the four cables are in tension. While performing a trajectory the CDPR will usually have at most three cables in tension, possibly going temporarily through poses where all four cables are in tension, but we are not able to determine such a case. If A i denotes the winch output point of cable i we will consider the convex hull H of the A i points in the plane z = 0 and A ip will denote the projection of A i in this plane and if M is a pose, then M p will be its projection in the plane. It is easy to show that if M p is strictly inside the triangle A ip , A j p , A kp (denoted as (i, j, k) for short), then a static equilibrium will be obtained when cables i, j, k are in tension while cable l = i, j, k is slack. However, there will be another cable configuration i, j, l with k slack that also leads to a mechanical equilibrium of the platform. Hence for a given platform pose two possible cable configurations, named the main cables, that share two cables (i, j) and only differ by the third cable, lead to a static equilibrium of the platform. In what remains, the Cartesian coordinates of points A i expressed in meter are the following: OA 1 (-8,5,5), OA 2 (-8,-5,5), OA 3 (8,-5,5), OA 4 [START_REF] Notash | Failure recovery for wrench capability of wire-actuated parallel manipulators[END_REF][START_REF] Lesellier | A Bounding Volume of the Cable Span for Fast Collision Avoidance Verification[END_REF][START_REF] Lesellier | A Bounding Volume of the Cable Span for Fast Collision Avoidance Verification[END_REF]. The four points have the same height and lead to a rectangular workspace.

Possible failures

The failures that are considered in this paper and may occur for a CDPR are the following:

1. the breaking of a cable; 2. failure of an encoder or of a motor or its control module: such failure may easily be detected as the integration of the voltage sent to the motor combined with a simple motor model will provide information of the expected motion of the encoder. If this information is not coherent with the measurement either because of a failure of the encoder or of the motor, we may stop the CDPR and because of the usual high resolution of the encoder, the displacement of the platform will minimal; 3. the loop effect: uncoiling an already slack cable may lead to a loop at the winch level that reverts the normal coiling process. Consequently, the cable length may decrease instead of increasing and therefore the altitude of the load will increase. This failure cannot be detected by using only the estimation of the L 0 based on the measurement of the winch rotation angles. 4. the winch may have a mechanical failure, e.g. break or losing the clutch that couples the drivetrain to the coiling unit. 5. depending on the velocity of the platform before an emergency stop, the robot may undergo significant sway motion, often putting two cables under tension and making the third cable loose. 6. cables can get stuck in the winch or on guiding pulleys. Cables leaving the pulleys may also slide about nearby elements.

Our objective is to ensure the safety of the operator. There are several means for this purpose:

• immobilize the robot • move the robot at a low speed toward a safe pose • move the load from its current pose along the vertical to a safe altitude to avoid any contact with the workers or environment • put the load as quickly as possible on the ground to limit its motion There are no general strategies that may be applied for each case and In this paper, it is assumed that this safety will be guaranteed if the unexpected motion of the CDPR is such that the load cannot reach an altitude that is lower than a given value z l and higher than a threshold z h because the cable tensions increase with the altitude of the platform and may lead to damages on the CDPR. Note that this assumption is not restrictive and the proposed methods can be extended to deal with other safety definition such as the avoidance of a given region.

Cable breaking

With only the measurement of the L 0 the breaking of a cable cannot be detected. Hence the safety has to be ensured by the robot design and by restricting its workspace. As seen in Sec. 2, we have for a given pose in most cases three cables only in tension. The corresponding cable configurations are i, j, k or i, j, l. The breaking of k (l) will not affect the CDPR behaviour that much because the cable configuration will switch to i, j, l(k) with a little displacement of the platform. On the contrary, the robot behaviour will be highly affected if one of the main cables i, j breaks down. Let us assume that H is a rectangle whose corners are numbered 1,2,3,4 and assume that at its current pose such that M p is located both in the triangle 123 and 124 leading to two possible cable configurations having 1,2 as main cables. If the CDPR is in the configuration 123 and cable 1 (2) breaks down, then the load will swing around the A 2 A 4 (A 1 A 3 ) line meaning that the load will move on a circle in a vertical plane that is perpendicular to A 2 A 4 (A 1 A 3 ) whose radius can be obtained as a function of the lengths of cables 2,4 (1,3). It is easy to show that if M lies in the cylinder with axis A 2 A 4 (A 1 A 3 ) and radius z az l , then the load will not go below z l during the swinging motion after the breakage of cable 1 (2). However we have also to limit the load height to z h in this cylinder. A fully safe zone is therefore obtained as the intersection of these two cylinders that lie below the altitude z h . Figure 2 shows the full safe zone obtained for z l = 1, z h = 4. From Figs. 1(a) and 2, it is noteworthy that this safety consideration drastically shrink the CDPR workspace.

Adding measurements

As seen previously the measurement of the L 0 is not sufficient to ensure the safety of CDPRs. Therefore it is necessary to consider other measurements with the objective to detect an abnormal behavior for the cables or for the whole CDPR, that may occur very quickly (e.g. during a cable breakdown). For this purpose we may measure at a high rate the cable tensions, the cables angles with respect to the horizontal at A or B (with an optical sensor [START_REF] Merlet | An experimental investigation of extra measurements for solving the direct kinematics of cable-driven parallel robots[END_REF] or an IMU located close to B), or the load altitude Fig. 2 3D and top view of the safe zone when one cable breaks (with a vertical distance sensor). Tension measurement is not satisfactory because it will be very difficult to distinguish between a normally slack cable or a broken cable. Measuring the z coordinate of the platform, which has an interest for control, is appropriate except in the case of a non-main cable breakage while measuring the angles covers all failure cases. In summary there are multiple sensor possibilities to detect a failure of such a CDPR.

Zones covered by the cables

In order to avoid any collision between the human operator and the cables, it is possible to prevent the human operator from getting into zones spanned by the cables with intangible barriers. For that matter, the zone spanned by each cable should be determined first. Some approaches are proposed in the literatureare to determine the the cable span of CDPRs [START_REF] Farzaneh Kaloorazi | Collision-Free Workspace of Parallel Mechanisms based on an Interval-based Approach[END_REF][START_REF] Lesellier | A Bounding Volume of the Cable Span for Fast Collision Avoidance Verification[END_REF][START_REF] Pott | Determination of the Cable Span and Cable Deflection of Cable-driven Parallel Robots[END_REF] For instance, Fig. 3(a) shows the area spanned by cable 1 (red cable) when the end-effector covers the rectangular parallelepiped of size 8 m × 5 m × 2.5 m. Fig. 3(b) the area spanned by the four cables when the end-effector covers the same regular shape. Accordingly, the white areas are free of collision with cables and can be travelled by the human operator while being sure that he/she will not get in contact with cables as long as there is no cable breakage. From Fig. 3, it is apparent that no human operator is allowed to approach the robot because most of the space is spanned by the cables. In this case, a typical safety measure is a fence or technical solutions must be adopted to allow interaction between human operators and the cables for low speed operations. Fig. 3 On the left the area spanned by cable 1 (red cable) when the end-effector covers the rectangular parallelepiped of size 8 m × 5 m × 2.5 m. On the right the area spanned by the four cables when the end-effector covers the same regular shape. Cables 1, 2, 3 and 4 are red, green, blue and cyan, resp. The white areas are free of collision with cables.

Ensuring safety

A complete safety for the CDPR may be obtained by doubling each cable with a passive auxiliary cable as shown in Fig. 4. This cable goes from the load to an output point close to A and has a counterweight at its free end. The cable goes through a pulleys circuit, which is designed in such way that when the main extend from its minimal to its maximal length, then the counterweight moves from the bottom to the top of the mast. On the last branch of the cable loop, a clamping mechanism allows one to stop the cable motion. The mass of the counterweight is just sufficient to overcome the friction in the pulleys and the tension in the auxiliary cables. Therefore, this mass does not modify the platform pose, although it will usually decrease the tensions in the four main cables. As an example we assume that at time 0 the CDPR is at pose (-6,-3,2) (which is outside of the safe zone) when cable 2 breaks down. At time 0.1s the controller detects that cable 2 has broken down, stops the winches of all cables and clamps the auxiliary cable 2, whose stiffness is 10 000 N/m and has a damping factor of 200 Ns/m. Figure 4 shows the evolution of the z of the load as a function of time. It may be seen that the load quickly converges toward a safe position.

It may be noted that the auxiliary cables may be very close to the main cables, so that cable interference will not be an issue.

It may be tought that adding 4 cables, even passive ones, induces an increasing complexity. Hence we have investigated the use of a single auxiliary cable that will release a counterweight after a failure detection in order to raise the load at a safe height. However it has appeared that it is very difficult to determine the location of the output point of this cable and the mass of the counterweight so that the CDPR may be put in a safe position whatever the initial breakdown pose is. The dynamics of such a system is relatively simple but is very sensitive to the mass of the counterweight: if the mass is too low the system may fail to raise the load, while for a larger mass we obtain a very large upward motion of the load before reaching the Fig. 4 On the left the principle of safety ensured by auxiliary cables. On the right the evolution with respect to time of the z-coordinate of the load after cable 2 breakdown. static equilibrium. Such a motion will put a large stress on the CDPR structure that will lead to additonal safety issues.

Conclusion

This paper dealt with the possible failures of CDPRs when they are used for collaborative work with humans and provided some technical solutions to ensure the safety of the operators. There is no general strategy that can be applied in each case for ensuring this safety. We have considered a translational three degrees-offreedom CDPR composed of four cables connected to a point-mass end-effector as an illustrative example. Failure possibilities have been identified, together with sensory means to detect the failute. The behaviour of the CDPR was studied in case of cable breakage and failure of an actuator and the loop effect was also investigated. Some technical solutions were proposed to ensure the safety of the human operator working in collaboration with the CDPR. For instance, a concept based on auxiliary cables and a clamping device was introduced to ensure safety in case of cable breakage.

Fig. 1

 1 Fig.1On the left the static workspace of the CDPR. On the right the static workspace of the CDPR after cable 3 (blue cable) breakage.

Figure 1 (

 1 Figure 1(a) shows the area where the platform can be in a static equilibrium for the CDPR at hand. Figure 1(b) illustrates the static workspace of the manipulator after one cable breakage.Let us assume that H is a rectangle whose corners are numbered 1,2,3,4 and assume that at its current pose such that M p is located both in the triangle 123 and 124 leading to two possible cable configurations having 1,2 as main cables. If the CDPR is in the configuration 123 and cable 1 (2) breaks down, then the load will swing around the A 2 A 4 (A 1 A 3 ) line meaning that the load will move on a circle in a vertical plane that is perpendicular to A 2 A 4 (A 1 A 3 ) whose radius can be obtained as a function of the lengths of cables 2,4 (1,3). It is easy to show that if M lies in the cylinder with axis A 2 A 4 (A 1 A 3 ) and radius z az l , then the load will not go below z l during the swinging motion after the breakage of cable 1 (2). However we have also to limit the load height to z h in this cylinder. A fully safe zone is therefore obtained as the intersection of these two cylinders that lie below the altitude z h . Figure2shows the full safe zone obtained for z l = 1, z h = 4. From Figs. 1(a) and 2, it is noteworthy that this safety consideration drastically shrink the CDPR workspace.

Acknowledgements This work was partly supported by the ANR CRAFT, grant ANR-18-CE10-0004.