Keywords

1 Introduction

The manufacturing industry is an ecosystem full of changes and variations where production conditions are never the same. As an example, the raw materials received from suppliers differ from one another, though within tolerances. Because of these differences, using the Asset Administration ShellFootnote 1 (AAS) [1] for each component/part is not feasible. And similar variations appear in all areas of manufacturing, such as tool wearing, the statuses of production machines, and even operator decisions

(Fig. 1).

Fig. 1
A graphic presents the variations in all areas of manufacturing including operator decisions. Scheduling, Theoretical dimensions, Real dimensions, Grinding wheels, Assembly information, and Previous experience.

Variables affecting operator decisions

On top of that, operator decisions are, most of the time, based on intuition and experience, not based on data analysis. One of the reasons is that manufacturing industry data are stored locally in departments and in silos, so the operator does not have access to them. Some of these data and their storage locations are as follows:

  1. 1.

    Scheduling data related to production orders, quantities, delivery times, etc. are usually stored in the enterprise resource-planning (ERP) system.

  2. 2.

    Raw material suppliers, their characteristics, their arrival times, their quantities, etc. are usually stored in the suppliers’ departmental repositories.

  3. 3.

    Nominal product characteristics can be found in the engineering department’s drawings and repositories.

  4. 4.

    Quality-control results are usually stored either in the quality-control machine’s memory or in the quality-control department’s repositories.

This paper suggests that an improvement to production must balance various choices, not only technical but also economic. In existing production environments, several criteria are included and considered as part of determining the best solution to problems like storage size (e.g., economic costs, logistic costs), operator costs, production time, energy consumption, and more. When applying artificial intelligence (AI) in the manufacturing process, the criteria should be similar: Several agents with different goals should interact to determine the most holistic solution.

To this end, this paper illustrates that the multiagent method, based on a framework of distributed examples, leads to interactions between these agents in ways that improve the entire plant production system. Although the agents could work in isolation, the MAS4AI (the multiagent system for AI) is tasked with making them work together seamlessly and providing a better solution than they would produce by working separately.

The second goal is to address scalability in the implementation of AI solutions in the manufacturing industry: Agents need to be customized and specific to each manufacturing process (i.e., grinding) yet at the same time be generic enough for all machines and industries using this manufacturing process (i.e., all grinding machines in all shop floors). The MAS4AI proposal is for an agent-based Asset Administration Shell (AAS) approach to be deployed in every industry that wants to use a particular agent. In this way, an agent is composed of agent logic and the AAS. See the specifics for a case of using it at the Fersa plant, as depicted in Fig. 2.

Fig. 2
A chart lists the DATA Repositories. It includes machine, tooling, pre-scheduling, scheduling, and machine agents, and JANUS F W. JANUS F W includes BASIX W W, DIMOFAC F W, and PYTHON F W.

Implementation of the agent-based AAS

1.1 Fersa’s Pilot Plant

Fersa Bearings is a company that specializes in the design, manufacturing, and commercialization of bearings, mainly for the automotive market, but a minor percentage is dedicated to the industrial market. For the automotive market, Fersa Bearings manufactures bearings both for new vehicles (few references and production cases in long batches) and as spare parts, which implies many references and production cases in much-shorter batches.

The use case implemented at the Fersa plant focuses on the Z0 line, which is fully dedicated to manufacturing spare parts (short batches). In this line, one reference is composed of two sections manufactured in parallel that have to be assembled into one part. Therefore, quality is critical in these processes to ensure that the different parts perfectly match, meeting the final requirements.

The multiagent system improves Fersa’s control over the processes in this manufacturing line, which improves end quality, communication and process coordination despite the variability among raw materials, tooling, and processes. Today, different actors interact in the physical world to optimize production holistically. The goal has been to apply AI in the manufacturing process—in a virtual world where several agents with different goals interact to determine the most holistic solution, as depicted in Fig 3.

Fig. 3
A diagram lists the link between the physical and virtual worlds. It includes a tooling agent resembling a valve, a machine unit, and a scheduling agent with a set of commands.

Relationship between physical and virtual worlds at Fersa

At Fersa’s pilot plant, we are considering having three agents interact: a tooling agent that optimizes the tooling selection, a machine agent that improves the machine parameters, and a scheduling agent that evaluates the manufacturing time for a production batch under certain circumstances, such tooling selection and machine parameters. This is presented in Fig. 4.

Fig. 4
A circular model lists the A I agents. Raw material, tooling, machine, quality control, assembly, and scheduling.

Relation among agents at Fersa

2 Experimental Development

2.1 Data Aggregation

The challenge was that the Fersa use case generated a wide variety of heterogeneous data from different data sources. The decisions must take the following factors, among others, into consideration:

  • Raw material characteristics

  • BEAIN12 and RIFA6 machine parameters and historical data

  • Quality-control stations’ data

  • Assembly stations’ data

  • Sensors’ data

  • Scheduling plans

    These data sources also appear in different types of formats:

  • Portable data formats (PDFs)

  • Comma-separated values (CSVs)

  • Tabular data formats such as Extensible Markup Language (XML) and Excel (XLS)

On top of that, the data come from various locations:

  • Shop floors (e.g., machine parameters)

  • Suppliers (e.g., raw material characteristics)

  • Management tools (e.g., ERPs and scheduling tools)

The first step in implementing Fersa’s MAS4AI is to ensure that the data are properly connected, aggregated, and filtered.

Figure 5 presents the proposed solution to aggregating all the data sources: a—machine data, including ranges and grinding-wheel parameters; b—raw material data, including nominal and real data; c—other agents’ data; and d—assembly and control stations’ data. The central part shows the repositories where the aggregation takes place in MAS4AI for Fersa.

Fig. 5
A framework defines how the BEAIN 12, RIFA 6, raw material info, info about references, L M S scheduler, and tecnalia scheduler connect the databases that include elastic search, posture S Q L, and M S Q L. Assembly and control stations are externally linked to the databases.

Data aggregation

2.2 Tooling Agent

One of the main challenges is to find the most suitable griding wheel (GW) for a certain production process (reference and quantity). On one hand, a too-big GW will not be completely used; it will return to the warehouse as partially worn and be difficult to reuse. On the other hand, a too-small GW will stop functioning before the production cycle has finished, forcing a GW change, which stops production.

Our solution is to have the tooling agent check the Fersa GW warehouse in order to select the most suitable GW for the current production cycle (see selection criteria in 2.4). Most of the information needed by the agent is provided by the grinding machine agent, which receives and optimizes the machine parameters of the current production cycle. Figure 6 shows the current workflow of this part of the Fersa system.

Fig. 6
A flow diagram defines how the info for scheduled agents is retrieved from the item number and catalog number. It includes a RIFA 6 machine agent, G W-related parameters, and a tooling agent with a G W Warehouse. The tooling agent output is feedback to the RIFA 6 machine agent.

Agent interaction logic

The reference for the production order and the suggested machine parameters for that production should be followed to determine the optimal grinding wheels. The length of change time for the GWs should always be minimized. The AAS type for the Fersa system was the resource one.

The main content of this agent can be found in the AAS of the GW agent, specifically in the submodel’s production information. Figure 7 illustrates the reference for the production, the inputs used for the execution of the agent, and the list of GWs obtained for the tooling agent ASS.

Fig. 7
A screenshot of the expanded view of the A A S grinding wheel agent V 1 menu. The main folders under it are S M Production Information, S M C inputs, S M C outputs, and S M C grinding wheels selected.

Tooling agent AAS

2.3 Machine Agent

Another challenge is manufacturing the highest number of good-quality parts (i.e., without burns; without derivatives; without conicity, ovality, or obliquity problems; and with Ha-T-1Footnote 2 diameters within tolerances) in the shortest amount of time. To accomplish this objective, the proposed solution takes into account the following actions that illustrate the agent’s logic:

  • It determines the GW diameter by taking into account the current parameters of the production. This determination is made in the short term, over periods of seven, fifteen, and thirty minutes.

  • It provides critical values from the production cycle. These values are provided in the short term, over periods of seven, fifteen, and thirty minutes.

  • It optimizes the initial machine parameters according to the batch reference.

  • It detects deviations from the machine parameters during the execution of production.

All these objectives contribute in different ways to minimizing the time that a batch needs to be finished.

During the pilot operations at Fersa, assembly and quality stations fed the agent with information such as nominal and real values and the tolerances of the raw materials. The Fersa use case features two machine agents. While the real-time agent is related to the BEAIN12 machine, this machine agent relies on the RIFA6 machine. This agent calculates by using a series of machine-learning and deep-learning models. At the time when this chapter was written, the testing process involved three neural network structures with different numbers of hidden layers (two, three, and four), different numbers of neurons per layer (20, 15, and 10), and different optimization algorithms (Adam and Stochastic gradient descent (SGD)). The metrics used were mean absolute error (MAE) and mean squared error (MSE). For example, while deep-learning short-term prediction models for the Grinding Wheel (GW) diameter and positions have been fully developed and are in a testing phase, the optimization model for the initial parameters is still undergoing testing because it still needs historical data for past batch references that were not collected by Fersa before the project started. For the same reason, the model that predicts deviations from the machine parameters for a fixed batch is also still undergoing testing. Data are currently being collected to enable new models to be added and tested over the following months.

The main content of this agent can be found in the machine agent’s AAS, specifically in the submodel’s production information. Figure 8 presents the reference for the production, the inputs used for the execution of the agent, and the outputs obtained for the machine agent ASS.

Fig. 8
A screenshot of the expanded view of the A A S grinding wheel agent V 1 menu. The S M C outputs model is highlighted under the S M C outputs.

Machine agent AAS

2.4 Prescheduling Agent

In this case, the challenge is to determine the time required to produce a certain batch by factoring in the material, the tooling, and the machine parameters. Additional parameters to be considered include the number of wheel changes needed and the estimated time to complete these changes. The proposed solution considers all these inputs. Such inputs refer to item information: the item number and the catalog reference for the batch, the number of pieces to make (included in the production table from the Microsoft SQL Server (MSSQL) repository), Fersa’s current inventory, the batch schedule, and information on the production once the item has entered the machine. The agent applies two logics: one in real time featuring the current status of the machine and another that was calculated before production. The output of the agent is based on the estimated time required to finish a production. The AAS for preschedule agent is the production-planning type.

The main content of this agent can be found in the prescheduling agent’s AAS, in the submodel’s production information. Figure 9 presents the reference of the production order, the inputs used for the execution of the agent (e.g., the cone reference and the quantity), and the outputs obtained (e.g., the number of GW changes or the estimated time required to produce the batch) for the prescheduling agent ASS.

Fig. 9
A screenshot of the expanded view of the package menu. The S M BEAIN 12 submodel is highlighted under the A A S BEAIN 12 A A S.

Prescheduling agent AAS

2.5 Holon

The complete implementation of MAS4AI architecture is based on the concept of a holon as an abstraction in that it groups multiple agents and coordinates both control and information flow. A holon is also used in JANUSFootnote 3 [2]. The theoretical presentation of a holon is illustrated in Fig. 3, while its practical implementation at Fersa is presented in Fig 10.

Fig. 10
A dataflow model defines how the agents in the Basyx, MAS, and machines access the Python framework. The Python framework includes tooling, scheduling, and machine agents. Basyx includes a machine holon A A S and machine A A S with the other agents. M A S includes a scheduling and machine Holon.

Holon implementation at Fersa

3 Conclusion

This paper presents the ontology, semantics, and data architecture that permits multiagent interaction, and the RAMI 4.0 model was selected as the basis for designing and implementing the presented approach.

The presented data architecture, depicted in Fig 11, permits the data analysis of raw materials, finished products, tooling characteristics and statuses, machine parameters, and external conditions, to minimize the influence of intuition and personal bias on decision-making in manufacturing and to improve production quality, throughput, and efficiency.

Fig. 11
A framework depicts how the M A S Janus and Basyx are mapped via the configuration and execution services with algorithms, information modeling, and system integration. The services include R D F store, registry with agents descriptors and A A S descriptors, and U I.

MAS4AI FW and RA

Figure 12 presents the generic MAS4AI Framework (FW) and Reference Architecture (RA) adapted for the Fersa pilot.

Fig. 12
A block diagram consists of Siste plant server, L M S server, Dimofac server, Basyx server, Tecnalia server, databases, node red connected using A A S connection, A P I rest, and BDs connections.

MAS4AI FW and RA in Fersa

The pilot is scalable to many other sectors: From its use in the grinding process, MAS4AI RA and its framework can be easily moved and applied to manufacturing processes such as stamping, machining, compounding, and extruding, where the decisions are based on balancing factors such as tooling, machines, and scheduling requirements.