Keywords

1 Introduction

Despite the availability of numerous software tools for digital planning and virtual commissioning, there are only few efficient and usable, ready-to-use platforms for the concept planning of robot-based automation solutions (RAS). One of the reasons for this is that the concept planning is strongly based on the empirical knowledge of the respective system integrators and their employees. In order to digitalize these process steps, a structured knowledge acquisition and preparation is required. Structured methods are mandatory to prepare knowledge in a scalable, standardized and user centered manner. On the other hand, the platform and the knowledge within must be provided in an accessible, usable and scalable way. Thus, a suitable software architecture (e.g. based on microservices) and the appropriate, scalable technologies (e.g. configurators, 3D web viewers and simulation) are utilized.

2 State of the Art

2.1 System Integration of Automation Solutions

For the planning and commissioning of RAS, an interdisciplinary approach is essential [13]. RAS are technically highly interconnected and complex investment goods. Therefore, the cost of the RAS is strongly influenced through the early planning steps. For this reason, expert knowledge and Best Practice (BP) examples, regarding reasonable realizable physical functions and interaction with the product as well as first basic path planning for position and range evaluation of RAS, are necessary. Thereby, BP [14, 21] are modularized and digitalized, successfully implemented RAS.

In order to steer the planning in a sensible direction, most robot manufacturers currently recommend experienced system integrators for their own systems [9, 30]. Usually, potential robotics users contact these integrators initially to clarify the feasibility of their own ideas and to inform themselves which tasks can be automated in an economically beneficial manner. This is a hurdle, especially if the potential user has little experience in working with RAS, because extensive information and coordination effort is required with poor chances of implementation for the user and signing of a sales contract (order) for the system integrator.

Fig. 1
figure 1

Phases of the system integration process and relevant output documents [24]

Full size image

Firstly, they have to define technical specifications for the task. Based on these, the system integrator will derive the requirements to the robotic components. After generating several solutions, one will be chosen, finalized and implemented. All steps after defining technical specifications have to be conducted by the system integrator. One main disadvantage of this is that the process, plant and product knowledge of the user cannot be directly used for the design of the RAS.

In order to digitalize and automate a process like system integration, it is firstly necessary to understand the essential process steps and their results. The system integration process is therefore divided into five phases before serial production of the system starts in the customer’s production facility (Fig. 1). These are used in the following as a scope for the functionalities of the ROBOTOP platform as well as the targeted configuration results.

2.2 Knowledge-Based Engineering Configurators (KBEC) as Tools for Automating the Planning Process of RAS

Knowledge-based configurators which can be developed table-, statement-, rule- or constraint-based [12], are a subgroup within expert systems and Artificial intelligence (AI) [10] and offer an approach to automate knowledge work such as engineering tasks via structured knowledge reuse [28]. Mostly, configurators are used for the individualization of predefined products such as clothes or automobiles [2] rather than new and dynamic engineering tasks. Therefore, we introduced the idea of a real knowledge-based engineering configurator (KBEC) [24], with which new RAS can be created based on BP [21] as well as customized and validated through constraints [15]. KBEC based on constraints[5, 7] provide advantages in transferability, scalability, and maintainability. Constraint models offer a solution description instead of case-specific result description whereas a product configurator (PC) provides existing product knowledge, as mentioned in [2] or [4]. Summarizing, the term engineering configurator is frequently used within literature but implies in most cases a PC e.g. in [4] or [6]. In general, a PC gives automatic access to different existing product variants [2]. Due to the large solution space of RAS planning, the functional scope of a KBEC is less predefined compared to a PC [15, 24], which requires additional development methods.

Existing approaches are either not based on the product to be produced and do not consider interdependencies between product and production system or are too generic or focused on deviating production areas in order to adequately represent the details of specific RAS [6, 11].

2.3 Digitalization of the Engineering Industry by Using Web-Based Platforms and Need for Action for Current Industry

For years, web-based platforms for the configuration of products have successfully offered users the opportunity to find personalized solutions tailored to their own needs. The configuration platforms hereby have the advantage of a significantly lowered inhibition threshold of the customer compared to their conventional equivalents, in the case of the automobile or furniture configurators for the individual configuration in the respective car dealer or furniture store. Systems for configuration and quotation of complex products in the B2B field are called Configure, Price, Quote (CPQ) software [8]. A prominent example for this within the mechanical engineering sector is the company Tacton, which promises high efficiency gains with its application-specific configuration platforms [27].

Production systems as the goods to be configured in the industrial environment lead to much greater challenges than in the customer market. Especially the high complexity of the industrial context with production equipment consisting of numerous components from various globally distributed manufacturers poses a major challenge for web-based configuration platforms.

3 Overcoming Barriers of Web-Based Engineering Configurators

3.1 Need for Action for a Knowledge-Based, Engineering Configurator Platform (ROBOTOP) for Planning of RAS

Increasing demands on the quality and repeatability of manufacturing processes as well as rising labor costs and a growing shortage of qualified personnel favor the use of robots in industrial production. However, the selection and configuration of robotic applications pose a great challenge, especially for small and medium-sized enterprises (SME), as in most cases they do not have adequate tools or specialized experts.

In this context, SMEs are characterized above all by the problem that they are not sufficiently familiar with the solution process of configuring RAS. Trial and error procedures with trying out and testing individual component combinations are both costly and time-consuming. Moreover, many and potentially the best solution variants remain undiscovered by such a procedure, as they are not known to the inexperienced user. SMEs have the opportunity to use the services of experienced system integrators who are aware of both the procedure as well as possible solution combinations. However, the use of these services is also expensive and characterized by a higher barrier than an internet-based configurator, the greatest challenge of which is to break down the complexity of all interactions. In order to master this complexity, the objective of the approach described in this paper is to develop a web-based platform for the configuration of RAS.

3.2 Challenges Within Data Acquisition and Preparation for Knowledge-Based Engineering Configurators Within a Web Platform

The following findings and results are based on the experiences of the last 3.5 years within the research project ROBOTOP [22]. BP based configuration strongly depends on the accessibility of examples the user can identify with as well as suitable components for customization [3]. Therefore, a sufficient number of already existing RAS must be collected and represented on the platform. In these steps, several challenges need to be overcome:

  1. 1.

    Willingness to share knowledge: Users and owners of already implemented robot-based automation solutions are usually not willing to fully represent their applications on a platform. First of all, they do not want to present their intellectual property and knowledge in manufacturing on a publicly available platform. Secondly, they want to avoid the effort for documenting and preparing the applications in a user friendly and standardized way. Furthermore, companies that already have robotic applications would not be the main profiteers of the platform.

  2. 2.

    Missing templates and data models for knowledge acquisition and preparation: To determine which data is needed, e.g. for BP and how it should be prepared, available templates and data models are missing. These include information about which data is required for the software functions as well as how this data should be prepared for the technologies used, such as the configurator and 3D visualization.

  3. 3.

    High effort of knowledge acquisition and preparation: The obtained BP must be implemented in an interactive 3D environment for a good user-experience. The presentation will be based on CAD data. As the models for a component are usually provided by the manufacturer, he also owns the rights to those models. For the publication of the components’ 3D representation, it would either have to be replaced by similar components with self-designed CAD representations or the component manufacturers would have to join with the operator of the web platform. The second solution would require a certain size and market penetration by the platform. Therefore, CAD data acquisition is a “chicken or the egg” type of problem.

  4. 4.

    Availability of easy-to-use tools for data acquisition: For data acquisition for the knowledge base, usually only expert tools with poor usability are available which lowers the quota of users who feed their applications back to the platform.

4 Platform Architecture and Lessons Learned

4.1 Software Architecture of ROBOTOP

To reduce the number of combination options and to secure the functionality of the configured target RAS, a BP based approach is ideal for KBEC. Due to the existing uncertainty and in order to specify the architecture based on concrete empirical values, various sub-prototypes were created [15, 18,19,20,20, 24]. Through the prototypes a large interdependency becomes obvious, e.g. the BP preparation is necessary for the click-prototype and the click-prototype to validate BP in the overall context [24, 26]. ROBOTOP is based on the scalable and flexible idea of a microservice architecture, firstly introduced in 2006 through amazon [29]. In doing so, the ROBOTOP functions are divided into several independent microservices (MS), such as BP selection, configuration, simulation, AML-data-exchange [1, 14] and spec-sheet generator [21]. The MS can communicate via standardized interfaces. Each MS can be developed by using independent technologies [16]. Thus, frameworks and new technologies can be used as appropriate and functions can be dynamically exchanged and extended. This enables an easy implementation of multi-user configuration of RAS and even more flexible user interfaces via micro front end approaches [17].

In order to solve the problem of overly complex user interfaces, a target group specific front end concept for ROBOTOP was developed based on a user-centered approach [26]. Parallel to this, a specific procedure for the development of user-centered user interfaces for KBECs was developed [23]. Thereby, user-centered front-ends could partly perform tasks of a sales person.

In order to develop consistent back-end semantics as a general data model for the individual microservices, a modeling methodology based on a division of labor was introduced as well [20]. This was implemented using the AutomationML Editor, but can be applied to all modeling tools based on potent modeling languages.

4.2 Constraint and Best Practice Acquisition for KBECs

For purpose of KBEC, we have developed firstly a generic constraint acquisition method and secondly a BP specific knowledge acquisition method.

(1) Generic approach for constraint acquisition

For a general development of KBEC, especially for the structured division of labor preparation of engineering knowledge in the form of constraints, the “150% topology” including a modelling methodology was introduced [15]. For specific identification and selection of knowledge sources a six-step method was created, including a generic table with potential knowledge sources for constraint acquisition [24].

(2) Seven step Best Practice knowledge acquisition method

  1. 1.

    Defining the required BP data for the 3D-configurator: Especially the definition of the required data is an agile and cyclical process. This is an interplay between the development of the click-prototype [23], the 3D-models [19] and needed data in an idealistic configurator [15] and the available real data.

  2. 2.

    Developing concepts to convince partners to provide BP: In order to convince companies to provide the data, various approaches were explored. In particular, the provision of BP for sales support was well received.

  3. 3.

    Finding and convincing system integrators: The first step of every acquisition was to identify a company which is interested in listing their existing RAS on the web platform. To this end, technical questionnaires were sent to contact persons at suitable companies after an initial phone conference.

  4. 4.

    BP data acquisition: In this questionnaire, the company can categorize itself according to its size and its used automation systems and existing tools for the planning of RAS. To collect the BP information, the following subjects are requested:

    • Short description of the application.

    • Implemented degree of automation.

    • Motivation for the automation.

    • Approximate cost for planning and implementation.

    In the further course of filling in the questionnaire, a more detailed description of the task and solution is obtained. In the course of the research project, the input data from the company was validated in a meeting with the contact person at that company and an automation expert from the ROBOTOP team. To ensure a realistic representation on the web platform, the application was observed during operation and a simulation. This way, peculiarities of the implementations can be copied to the BP catalogue if necessary. Finally, measurements are made for a true-to-scale display of the application and photographs are taken as a guide for the implementation in the CAD model.

  5. 5.

    Postprocessing of the collected data: An abstraction of the acquired applications was executed as the first step of the preparation. The aim was to reduce complexity by removing or replacing unnecessary or highly specific components and to avoid the publication of confidential information of the company which provided the example. For example, the workpiece will be altered to one with similar handling and machining properties without being identifiable as the original workpiece.

  6. 6.

    Preparation of BP data as 3D-model: From the simplified representation of the BP, a 3D scene and an attribute table are derived. For the 3D representation of existing applications, CAD models of the components were assembled. These full-models of the application were rendered for the preview pictures in the BP overview.

  7. 7.

    Web platform integration of BP: For the manipulation of the example, the individual components of the models were transferred to the configurator database together with their placement information for each scene. The platform user can manipulate copies of the Best Practices during the configuration process.

5 Validation of the Iterative Development of ROBOTOP Based on Concepts Implementation and Platform Facts

Within ROBOTOP, 34 BP solutions were acquired and prepared to be an input in the web-based configuration. The process to be run through by the user on the platform from the initial identification of a suitable solution to the user-specific adaptation is divided into four steps: BP selection, configuration, simulation and finally overview and specification. For the recording and assignment of user requirements, 118 specific rules were defined to cover interactions.

In the BP selection, the user can choose between eleven different processes in the application area, from assembly to drilling up to testing processes. Here, the BP solutions that do not fit the user’s target application are filtered out first. The user can then filter out other unsuitable BP by entering information about the workpiece. Information includes workpiece shape and dimensions interacting with the BP gripper and weight information interacting with the robot’s payload.

In the subsequent configuration, the user then has the opportunity to adapt the selected BP to his specific application by changing the arrangement and positioning of the individual components. In addition, the configured application can be simulated and provided to the user with detailed specifications.

Initially, in order to integrate existing robotic applications for the BP based configuration, a BP template was developed Figs. 2 and 3, left) as well as the flow for a user-centered configuration. These served as a guideline for the development of the ROBOTOP Platform Figs. 2 and 3, right).

Fig. 2
figure 2

Best Practice Selection: comparison of the click-prototype [23, 26] (left) and the ROBOTOP platform (right) to show the iterative development of the platform

Full size image
Fig. 3
figure 3

Customization configuration: comparison of the click-prototype [23, 26] (left) and the ROBOTOP platform (right) to show the iterative development of the platform

Full size image

6 Conclusion and Outlook

Within ROBOTOP we have shown how the agile development of a knowledge-based engineering configurator (KBEC) platform can be achieved. To this end, we have divided the platform functions such as Best Practice selection, configuration, simulation, AML-data-exchange and spec-sheet generator into different microservices. In addition, the requirements and possible functions of the platform were developed top-down using agile sub-prototypes. In parallel, bottom-up knowledge of Best Practices was gathered. In the process, challenges and possible solutions were identified.

For future research, there is a lack of user-centered tools for data preparation as well as other methods and tools to further scale-up the data acquisition as a primary bottleneck of knowledge-based platforms. BPMN in combination with process engines could be used for process control of data acquisition as well as for coordinating individual user-centric data acquisition tools. BPMN in combination with process engines could be used for the management of data acquisition processes [25] as well as for the coordination of specialized developed user-centered data acquisition microservices [17, 23].