An Agent-based Cyber-Physical Production System using Lego Technology

To cope with the challenges of constructing Cyberphysical Production Systems (CPPS), many studies propose benefiting from agent systems. However, industrial processes should be mostly emulated while agent-based solutions are integrating with CPPS since it is not always possible to apply cyber-based solutions to these systems directly. The target system can be miniaturised while sustaining its functionality. Hence, in this paper, we introduce an agent-based industrial production line and discuss the system development using Lego technology while providing integration of software agents as well as focusing on low-level requirements. In this way, a CPPS is emulated while agents control the system.


I. INTRODUCTION
A DVANCES in networked systems produce new paradigms and new design challenges in the embedded systems. The information processing and computation are merged with communication and control that creates Cyber-Physical Systems (CPS) [1]. This evolution expands the capabilities of embedded technology interacting with the physical world through computation, control and networked communication. In this way, medical devices, transportation vehicles, intelligent highways, robotic systems and factory automation can be instrumented and implemented considering new capabilities that are achieved by CPS. One of the specialized fields of CPS is the Cyber-physical Production Systems (CPPS) which is related to the autonomous and cooperative elements and subsystems that are connected based on the context within and across all levels of production, from processes through machines up to the production and logistics networks [2].
Smart manufacturing considers adapting the embedding software and hardware technologies to the CPS, including intelligent methodologies. It aims at increasing the efficiency in the production as well as improving the conditions in the delivery process. Moreover, it is one of the leading application domains since it can have large scale production in domestic and international marketing that can impact highly economic growth. Industry 4.0 takes a pioneering role to determine manufacturing standards of the future [3]. A highly challenge in manufacturing came forward is flexibility since there are high demands for products. It is very problematic to meet those demands because of safety and complexity that arise from frequent interactions and co-operative requirements between machines, lack of human experts, and absence of an intelligent mechanism that can reason unpredictable behaviours of the system [4]. However, the requirement for intelligence to achieve smart CPS has emerged due to the complexity of these systems and physical unpredictability.
To cope with the challenges of CPS, many studies propose benefiting from the features of multi-agent systems (MAS) (e.g. [5]- [7]). MAS are widely preferred for providing support for smartness, decentralization, autonomy, and socialization of CPS. They increase the effectiveness of CPS providing enhanced functionalities for production and automation. The software agents can decide reconfiguration of the control functions/parameters, monitor transition between processes, and observe the human errors while increasing the system/human safety. Moreover, they can detect module breakdowns, structural changes, and contradictory inputs and materials, then they plan and decide on a suitable solution. In this way, they can enhance product quality and prevent damages during critical processes.
An integration of MAS and CPS may facilitate the use of intelligent agents in various industrial applications [8]. Once agents can control the components of the CPS, the developer can focus on higher-level solutions such as implementing intelligence mechanisms [9], aggregating Big Data and creating Digital Twins [10]. However, industrial processes should be emulated while agent-based solutions are integrating with CPS to address its challenges. Because it is not always possible to apply cyber-based solutions to the operational systems and dangerous environment of the industry directly when requested. Moreover, it is a burden to prototype an actual industrial production system for development purposes. There- fore, the target system can be miniaturised while sustaining its functionality, accuracy and goal-orientedness.
Firstly, a composable and concrete technology to mimic the industrial systems where CPSs are intensively operational is required. One of the technologies commonly used for imitating such systems is Lego (e.g. [11], [12]). Although Lego technology can be supported with tools or languages such as Scratch [13] for programming its hardware devices to control motors and collect data from sensors, it is not possible to integrate software agents and any intelligence mechanism easily. Secondly, a common development environment and language is required to merge Lego technology and agent software. Lastly, the integration should be seamless and built from scratch, and the system should behave as it is developed by the Scratch graphical programming language. Hence, in this study, we introduce an agent-based industrial production line and discuss the design and implementation of this system using Lego technology while providing the integration of the software agents both to address the abovementioned CPS problems and to focus on low-level requirements.
Since CPPS use different controller/computation parts, their relationship should be modelled to reduce their development and design complexity [14]. For this purpose, the analysis and design of both the software and system parts are realized using SysML [15] in our study. Physical implementation is done using Lego technology and Raspberry Pi (with PiStorms hat) while embedded and agent software is coded using Python and Smart Python Agent Development Environment (SPADE) [16], respectively, including RasberryPI-Lego library [17]. This paper discusses all these parts of the system development. In addition, the challenges during the integration of Lego technology and software agents to create a CPPS are discussed, and lessons learned are also given in the paper.
The rest of this paper is organized as follows: Section 2 briefly discusses the related work. Section 3 gives the analysis and design of the smart production line system. The implementation of the software components and the setup of the hardware are all discussed in Section 4. The challenges we faced and lessons learned are reported in Section 5. Finally, the paper is concluded and the future plan is described in Section 6.

II. RELATED WORK
Multi-agent systems are broadly researched and developed for providing modularization of the dynamic systems, decentralization for distributed systems [18], autonomy for production, and re-usability for further development of physical systems [19]. However, before realising such complex operations, agent integration has to be provided [20]. Once agents are implemented into CPS, their control over embedded functions should also be ensured.
In [7], capabilities of agents and CPS challenges are matched while underlining the software agents are generally a good fit for the requirements of the next generation CPS. Therefore, agents can show paramount effects for creating collaboration and integrity when they are distributed, providing smart decisions when physical unpredictability exists during the operation of CPPS. Leitao et al. [7] also emphasize that agents are good at reasoning e.g. using machine learning techniques, providing sustainability and managing human interaction in CPS.
The study in [21] addresses joint characteristics of Industrial Internet-of-Things (IIoT) and CPS while it also provides methodologies about the applicability of IoT-enabled solutions to CPPS considering interoperability principles. Additionally, they also present modelling approaches for IIoT systems.
In [22], the association between CPS and Embedded systems is considered. It is suggested to use a micro-controller board with various communication interfaces such as CAN, UART, WLAN, Ethernet, and BLE. In this way, this microcontroller can provide system-level compatibility with various boards and technological diversity to extend the design space.
Lee [23] discusses the design challenges of CPS in general from various perspectives and proposes a model-based design as a complementary approach. Hence, the process of rewriting the CPS software every time for each system can be shortened or even eliminated.
Similarly, the application of zero defect manufacturing using software agents is studied in [24] to cope with the challenges of CPS in the smart manufacturing domain. The researchers create a four-layer architecture and benefit from IoT solutions to inter-operate it with CPS using an edge-fogcloud methodology. They highly consider earlier detection of anomalies, product quality and data correlation to find the optimal solution without interfering with any control functions.
In [25], an agent-oriented system is proposed for an Automated Guided Vehicle (AGV) with the on-board camera. Xing et al. [25] benefit from the MAS paradigm to provide an effective organisation and communication between system components. They indicate that the MAS paradigm improves the intelligence of the systems by providing an onboard solution while achieving context-awareness for an autonomous AGV.
Queiroz et al. [26] discuss the cognitive requirement of CPS, exhibit the necessity of the distributed intelligence, and envision the usefulness of MAS as they fit the CPS. They indicate that autonomous decisions in a decentralised way can address some of the CPS challenges.
In [27], an ontological classification of CPS is made considering past, present, and future CPS technologies emphasising the requirement of intelligence. Moreover, intelligence level and self-* features of CPS are matched considering both the previous achievements and future projections. The study also focuses on the current research gaps in this domain.
In [6], the authors suggest using an agent development platform, called Tartarus, to implement both cyber-physical and IoT systems. They use a solution to run the software agent on the Intel Galileo and RaspberryPI boards using the Tartarus-Lego Mindstorms NXT robots programming interface. Although the current study also supports our vision to achieve agent-CPS integration using Lego development components, our solution differentiates in the sense that we focus more on integrating agent behaviours with the low-level of embedded control of the system components. This refers to low-level problems of agent-CPS integration from the baremetal embedded libraries to binding them with agent-based programming.
Petrovska et al. [28] propose a domain-independent approach for knowledge aggregation and reasoning of decentralized monitoring in multi-agent smart CPS. According to their logic algorithm, they tackle the uncertainty of partial, faulty and potentially conflicting context observations. Their approach allows capturing uncertainty at run-time on a local level while providing a global decision-making mechanism. They evaluate their approach using multiple rooms cleaning robots implementing MAPE-K feedback loop to their multirobot system.
The study in [5] discusses how a domain-specific modeling language, called SEA_ML++ and its tool [29], [30] are used for the design and implementation of a cyber-physical garbage collection system. The system is first modelled according to SEA_ML++'s graphical concrete syntax. Then a significant portion of the agent-based implementation of the system is automatically generated from these models via a series of model-to-code transformations.
In [31], the use of agents on Raspberry Pi is introduced. The study mostly focuses on the networking of agents and the cyber part of their location-aware and tracking services to establish an indoor person tracking system.
The survey in [32] considers the state of the art of applying agent technologies into the industry. The authors indicate that the industrial systems should be coupled with software logic and software agents to design CPS. They also underline the integration of software agents with physical hardware is both a difficult and a long-term process, and hence the common software patterns and paradigms can be applied to construct industrial agents which control the industrial machines and devices. However, according to their results, there is no uniform way to integrate the software agents to the lowlevel automation functions to create the industrial agents. Our methodology, which will be discussed in the following sections of this paper, may provide a strong alternative on facilitating the related integration within this perspective, specifically by emulating the industrial system before the real implementation and benefiting from both the agents and the embedded software and hardware.
Karnouskos et al. [33] classify the industrial agents according to ISO/IEC SQuaRE standards [34] under 8 categories, namely Usability, Compatibility, Performance Efficiency, Functional Suitability, Portability, Maintainability, Reliability and Security. Considering these 8 categories, an industrial system can be mimicked, and these standards can be applied to test the validity of them before the developed methodologies are adapted to the actual system.
As can be seen, while most research in the literature focuses on providing intelligence, adaptiveness and awareness mechanisms for CPS using agent technologies from a higher level of view, our study contributes to these efforts by providing an underlying infrastructure to merge embedded software with agent programming as well as mimicking the system operations over Lego technology to achieve the physical emulation of the industrial-like systems before their construction. Thus, we believe that once such an infrastructure is provided, then applying high-level solutions via decision making, knowledge extraction or pattern matching as mainly considered in the current studies can become more feasible.

III. SYSTEM SOFTWARE ANALYSIS & DESIGN
In this section, we discuss the analysis and design of our smart manufacturing system using SysML. We provide a multi-agent, multi-layered, multi-process study for such manufacturing systems. At the cyber side, the scalability, reactivity, and communication are merged with the embedded software in order to control a composable, extensible and modular Lego-based physical system.

A. System Overview
During the analysis and design, an efficient, autonomous, and smart manufacturing system is aimed to emulate the industrial requirements and tasks. The different types of input products are sorted in this system and they are processed autonomously according to their features which are similar to the common functionalities in an industrial factory.
The operation of the production line starts from inputting Lego bricks into the system. Then, the system starts to deliver these bricks using conveyor belts and in the next phases, the system decides either to sort or to combine these Lego bricks according to their colours.
The system is represented by a block diagram, which is illustrated in Figure 1, to provide an overview of the design. Considering the achievement of an autonomous and a modular system, the system is designed to be working on two embedded devices which are represented as layer 1 and layer 2. The essential requirement to run the whole system is the agent communication which is established between these two layers using XMPP protocol [35]. Two layers controlled with two PiStorms extension boards and two RaspberryPI3. The first layer controls 4 motors, 1 button, 1 ultrasonic sensor and 2 colour sensors while the second layer controls 3 motors and a limit switch.
Each software agent (shown in the photograph of the created system in Figure 2) has its own tasks and roles inside the subsystems of the production line. In the following subsections, they are discussed in detail. First of all, each agent has specific behaviours and actions to control hardware elements. These actions provide the sustainability to make the system complete its processes successfully. While four of seven agents work with cyclic behaviour, two agents have one-shot behaviour and an agent works based on a finite state machine (FSM) behaviour. To get the system and the agents ready, "Initialize" methods of all agents are triggered at first. Agents act based on their roles. The roles of the system agents are as follows: Drop agent is responsible for delivering products from system input to the Shredder agent. Shredder agent is responsible for shredding products and delivering them to Sort agent. Sort agent should decide about the product and move it to a related process. Push agent removes the brick from the conveyor belt. Lastly, Build agent builds required products according to the current state of its FSM behaviour model. Collaboratively, all agents run and control the whole production process.
In this regard, agents execute their programmed behaviours to achieve their goals. Before they start executing their tasks, each agent awaits a message from the preceding agent. This communication system provides a proper sequence for agent executions in the system.

B. Architectural Design
We designed the system architecture using block definition diagrams. For instance, in Figure 1, hardware layers are represented with root classes, named dev1 and dev2. These classes are specialized to assign specific functions for the goals of agents. These classes are created using Singleton Pattern to constraint the instance creation as only one instance per PiStorms device. We benefit from PiStorms library to program the device-specific features and the functions which are used by the dev1 and dev2 classes. Software agents control the hardware I/O ports via these singleton classes. These classes constraint the cardinality of object creation to one for each hardware element and these device objects are accessed by software agents to use device functions for I/O operations. In this way, agents control the device I/O to achieve their goals and sustain the operation of the production line.

C. Agent Communications
In a MAS, messaging is important for agents to complete tasks collaboratively. In SPADE, Agent Communication Language (ACL) messages have various parameters and commonly used ones are type, receiver, sender, and content. In our system, we use informative messages to establish organization between agents. When certain events occur in the system, agents send messages which include keywords (performatives) and lead triggering an action inside the agent receiving that message. SPADE uses the XMPP protocol to deliver messages and to ease connection creation. The sequence diagram given in Figure 3 represents the messaging between the system agents.

D. Behavioural Design
In this section, behavioural activities of the agents (emulating the product line robots) are discussed. As illustrated in Figure 4, each agent has specific behaviours and actions to control hardware elements.
Overall, while four of seven agents work with cyclic behaviour, two agents have one-shot behaviour and an agent work based on finite state machine (FSM) behaviour. These agents provide actions for the sustainability of the system. Moreover, the process transitions, controlled by the software agents of the system can be visualized as given in Figure 5.

1) Layer 1 Agents and their Behaviors:
Initialize Agent: Unpredictable power cuts and instant system shutdowns may cause positioning problems for the motors. When the power is cut, motors freeze at a position that is unknown by the system. Unknown motor positions cause failures on tasks. The main task of this agent is positioning the motors within mechanical limits. After motors are positioned, the agent sends a "done" message to the Drop Agent. This agent has a one-shot behaviour that works only once a time when the system starts up. There are 2 initializing agents for each layer. The initialize agent in layer1 positions the drop motor with the mechanical limiter.
Drop Agent: Drop Agent is responsible for delivering the product (Lego brick) from system input to conveyor belt. It has a cyclic behaviour so it continuously samples data from 2 sensors while controls a motor. It waits for a "done" message from Initialize Agent or Build Agent, then the user presses the button to run the system continuously. The "done" message refers to the system is ready for the first run or the current process is done so that Drop Agent can deliver a new product to the conveyor belt.
Before Drop Agent runs the motor to drop a brick on the conveyor belt, it checks whether there is any brick in the input using the sensor at the input. If this condition is satisfied, then Drop Agent delivers the brick to the conveyor belt. It rotates the motor 90°clockwise to release the brick and then -90°a nti-clockwise to return its initial position. Lastly, Drop Agent sends "dropped" message to Shredder Agent and Sort Agent to inform these agents about completion of its operation. Shredder Agent: Shredder Agent is responsible for controlling shredding and washing processes. This agent has a continuous cyclic behaviour. The behaviour starts with receiving a "dropped" message from Drop Agent and stops when a "shredend" message is received from Sort Agent. While product shredding, washing and moving to the second conveyor belt, the agent concurrently checks an ultrasonic sensor with a thread. In case of any outside intervention, the system accepts this intervention as an emergency and stops the shredder motor, washing motor and conveyor belt.
Sort Agent: As represented in Figure 7, Sort Agent has major role for making decisions in the system. It executes a Cyclic behavior. After a product is dropped on the conveyor belt, Sort Agent starts waiting for a brick and activates the colour sensor. When the sensor realizes that the brick has arrived, it stops the conveyor belt. If the brick still does not arrive at the sensor after a certain time, the sort agent reverses the movement of the conveyor belt to set free the brick which is stuck. It reads colour sensor to recognize colour of the brick. Sensor sampling starts with receiving a "dropped" message and ends with product recognition. If the sensor recognizes product arrival to the sensor, then Sort Agent reads the colour of the brick and stops the conveyor belt. Then, it has 4 decision options to deliver brick and to inform related agents: • Move brick to the bucket 1 and send "push" message to Push agent.
• Move brick to the bucket 2 and send "push" message to Push agent.
• Move brick to the bucket 3 and send "push" message to Push agent.
• Move brick to the press and send "build" message to Build agent.

2) Layer 2 Agents and their Behaviors:
Init2 Agent: Initializes the push motor, press motor and eject motor to their initial positions. This agent executes a one-shot  behaviour. The agent is created with the system start up and dies after completing its behaviour and related task execution. In the Lego systems, the moving parts are usually limited with mechanical bounds. Therefore, we added an extra limit switch into this configuration for the press motor to obtain a much better initial position performance.
Push Agent: Push agent is an agent that has a cyclic behaviour. After it receives a "push" message, it pushes the mechanical line forward and then back. After, it sends the "done" message to Drop agent to inform the process is completed. When it receives a "push" message, Push Agent turns the motor clockwise with 120°and after a second, it turns counter-clockwise with 120°.
Build Agent: As Figure 6 illustrates, Build Agent controls the pressing process in an FSM manner. The agent starts pressing the first product after it receives the first "build" message. Then, it waits for the second "build" message which means the second product is about to arrive. When the agent receives the first "build" message, then it moves to Press 1 state where it holds the first brick. Once it receives the second "build" message, then it switches to the Press 2 state to combine these two bricks. After the completion of these two consecutive actions, Build Agent ejects the arm and pushes the products to the storage area. Build Agent executes its FSM behaviour continuously until the system shutdowns.

IV. IMPLEMENTATION OF THE PRODUCTION LINE
The software agents work in collaboration to control the heterogeneous parts of our production line which is, in fact, a complex CPS. These agents periodically sense their environment and operate to achieve their goals while keeping the system operational. Agents are self-containing entities that are able to achieve their tasks by providing local control for the different parts of the system. The role distribution to the agents are defined according to process phases to harvest the product and they are programmed to work in harmony with other agents. Their modularity and dynamic deployment also enhance the physical upgrades and changes, in other words, new agents and new hardware can be added to the system easily.
In this section, the implementation of our smart manufacturing system is elaborated including the hardware setup and software agent implementation. The system configuration, the realization of the communication between agents, and the implementation of the corresponding behaviour classes are all discussed in the following subsections. The final structure of the implemented system has been previously shown in Figure  2.

A. System Configuration
The system is controlled by two PiStorms interface boards and two Raspberry Pi 3. Raspbian operating system runs Python 3.7 to interpret both embedded software and agent codes to control the system. SPADE is used for creating agents while PiStorms API is used to control Lego EV3 sensors/actuators.
In addition to the Lego production line pack, some modifications were made to resemble a more realistic industrial system. In the original system, the whole conveyor band had been controlled with only a single motor. Thanks to the modularity of Lego Technology, we separated conveyor bands to make each motor controls a separate conveyor belt so that two conveyor bands became controlled by the individual motors.
Generally, in most industrial production process implementations, limit switches are one of the most necessary hardware components to increase the reliability of the system. Hence, we added a limit switch for reducing the re-positioning error of the pressing process to zero shift. In case of any unexpected power cuts or environmental uncertainty, the system can obtain the initial position accurately using the limit switches.
Moreover, the initial version of the system had some issues about sampling colour value at the intersection point of conveyor 1 and conveyor2. Sometimes there was some noise that effecting colour sampling data due to the moving parts. To fix this, we separated conveyors to find the optimal position for the colour sensor. Lastly, we added some brick parts as limiters to keep the moving bricks on the middle of the conveyors accurately.

B. Embedded Software
As discussed previously, we applied the singleton design pattern to restrict object creation from the class, including the hardware-specific I/O operations. Because the agents should access the same memory address and register so that an agent does not override other agent's access.
Inside the device-specific classes namely dev1 and dev2, we also created inner classes for each hardware component. Inside these inner classes, there are functions specialized for each hardware element. For instance, an excerpt from the ConveyorMotor inner classes is given in Listing 1.
These inner classes can be accessed by an agent to control the hardware. Inside these inner classes, we developed a wrapper to raise the abstraction between the embedded Lego library and class implementation. In this way, wrapped code became more suitable for behavioural programming. In Listing 1, start(), startSlow(), stop(), brickStucked() and runDegs() functions are shown. These functions access the devicespecific functions defined in the PiStorms library and wrap them to make them more usable for agent-based programming. Between lines 2 and 3, the conveyor motor is initialized and set to a certain speed. Lines 5 and 6 describe a lower speed setting for the conveyor motor while lines 8 and 9 instruct the stop function. When the system detects a stuck on the conveyor belt, it calls brickStucked function to reverse the conveyor belt. Lastly, lines between 14 and 16 define the runDegs method to rotate and run the motor according to the desired parameters. Listing  It is the working principle of an agent to operate independently using behaviours and execute them in parallel with other agents. However, considering our I/O blocking situation, it is now possible to en-queue any sensor reading or motor actuating behaviours. Therefore, we need a concurrent system where it can run continuously without any interruption. Moreover, the system should sample data from the sensors while actuating a motor for 3 seconds in parallel with running another motor for 5 seconds. The obvious way to implement this concurrency is to assign a Python thread to each agent. However, there is a need for more parallelism within each agent, because an agent may also be involved in negotiations with other agents and each negotiation should proceed at its own pace while I/O blocking situations exist. In the implemented system, we used traditional threads for reading sensors and actuating motors instead of applying agent behaviours directly. Because sensor sampling is a crucial and continuous activity and agent behaviours can be blocked due to these I/O operations according to their processes considering the sampling rate. This considerably reduces the runtime-slices of each agent behaviour by blocking other operations when an agent reads the sensor inside these behaviours. As a solution, our implementation made each agent starts another thread within its setup and handles I/O operations. template . set_metadata (" performative " , "inform") 7 self .add_behaviour(b, template ) 8 print ("SortAgent :: running") 9 t . start () In Listing 2, an excerpt from one of the created threads for the colour sensor is given. In line 1, the target method is defined. Lines between 2 and 9 describe the setup function of the agent which is also used for the initialization of the interrelated threads.
In Listing 3, a code excerpt from the LimitSwitch class which defines a limit switch is given. In the production line system, the limit switch is used to set the borders of motion of the components. For this purpose, LimitSwitch inner class is specialized for the limit switch hardware. In line 3, the state of the button is checked periodically, then "if/else" statement controls the state of the button. In this way, agents can detect the limit of motion when isPressed() function returns true and then they behave accordingly. To minimize work accidents, many sensors are added to the manufacturing systems for occupational safety and health. These sensors must sense quickly as expected. For better sensor sampling rates and reactions, two threads of execution were implemented in the responsible agents: Shredder Agent executes the thread to check emergency while Sort Agent executes the thread on checking the arrival of bricks to the colour sensor. Colour sensors can be influenced negatively by the noises in the environment. To remove this effect, we implemented a sensor sampler inside the system. The system collects data from samples arriving from the sensor. If the last 15 samples are the same, the system accepts the colour. Otherwise, it continues to sample data (see. Listing 4). Sample videos demonstrating how the implemented system executes the continuous production and manages a stuck event in the production line are available at https://youtu.be/ dRUyXYuDPlY and https://youtu.be/_xgYyaBMv90. V. DISCUSSION CPPS are expected to provide various features such as adaptiveness, awareness, intelligence, and abstraction to meet the requirements of the emerging industrial applications. Agentbased approaches can be a good alternative to support these features. However, an integration of the industrial systems with the agents is still a significant issue for the agentification of such systems as discussed in [33] and [36]. MAS is a paradigm derived from the distributed artificial intelligence field that covers distribution, decentralization, intelligence, autonomy and adaptation. Using these features, MAS provide flexibility, robustness, responsiveness and reconfigurability and create an ecosystem of intelligent, autonomous and cooperative computational entities. Despite the fact that MAS technology has already been integrated into several industrial applications such as smart production, smart power grids, smart logistics and smart healthcare, acceptance and standardisation of industrial agents is still under debate.
Seamless integration of MAS, embedded system and CPS may bring solutions to the abovementioned issues and lead to the realization of the expected features. Since CPS consists of both physical and cyber parts, top-level methodologies cannot be evaluated and shown without low-level architectures to emulate the industrial problems. There is no uniform way to integrate the software agents to the low-level automation functions to utilize them as the industrial agents [32]. Hence, the miniaturisation of the industrial systems, mimicking the process steps and reproducing the problems as described in our study can be a way to ease the burden of developing industrial agents within this context.
To achieve CPS and agent integration, device specific libraries are mostly required. Then, these libraries can be merged with agent development environments. The library can be wrapped to provide behavioral structures. Once the control of the physical components is achieved by the cyber side, the agentification process can be applied. Moreover, the integration process can be facilitated by using software engineering design principles e.g. benefiting from the design patterns. Moreover, the physical construction of the target system is still required because CPS is also a physical entity. To address this requirement, we suggested using the Lego technology, which allows the miniaturisation of the interaction between embedded systems and agents while providing extensibility for applying high-level solutions and mechanisms. When the MAS is integrated into any system, the agents inside can be distributed to the subsystems to achieve the control process distribution while establishing a network for negotiation and messaging. In this way, functionalities of the embedded devices can be encapsulated into the behaviours of the agents. Then, various behaviours can be defined for executing tasks, sending parameters, and controlling the process to achieve the system goals.
After the completion of the agentification process, the system can also be enhanced with the distributed wireless sensors for data acquisition [37], [38]. The edge, fog and cloud computing can be the key enabler technologies for CPPS considering IoT and CPS interoperability. Then, this data can be fed into the Machine Learning algorithms to achieve various computations such as pattern matching to detect system faults, prediction algorithms to avoid human errors and system-level reasoning to apply high-level plans.
During the implementation of the smart production line introduced in this paper, we followed some fundamental industrial application principles. Firstly, to keep the pressing operation calibrated, the limit switch was added to measure the elevation. While the press goes up and down, it touches the limit switch so that it operates between bounded limits. Secondly, we followed the separation of concerns principle and placed an agent for a section of the production line. In other words, only one agent is responsible for a process phase. Lastly, the same principle was also applied to conveyor belts to create layer 1 and layer 2. When the task is finished in the layer 1, it delivers the product to the layer 2 so that layer 1 can receive a new task while layer 2 processing the second step of the previous task operating as pipelined.
We believe that the constructed system based on the Lego technology may be an appropriate tool for education considering the CPS and agent integration. Due to the fact that CPS is a multi-disciplinary field and owns multi-target domains, it is studied by a lot of researchers, engineers and practitioners. However, the recent advancements, open issues and challenges require multi-disciplinary knowledge as CPS has a wide umbrella that unites various engineering fields and disciplines.
Most of the engineering and information technology courses now focus on CPS, agent-based programming and embedded technology and the requirement of autonomy and intelligence mostly becomes a must to achieve and sustain next-generation systems [39]. We need physically easy-to-construct and easyto-modify technologies integrated with easy-to-deploy and easy-to-run programming paradigms. Lego technology provides modular and modifiable structures to meet these requirements while agent-oriented approaches present higherlevel abstraction of programming. Moreover, the nature of the agents paves the way for integrating artificial intelligence, inter-operating IoT solutions, and high-level programming. As a result, multi-disciplinary studies can be taught to the future's talented engineers and students using our proposed approach. As some technical notes, we would like to share that we faced with some challenges during the operation of the system. Due to the power requirement of RaspberryPI, Lego components and PI Storms, the system was fed with two power supplies and each power supply was feeding the system with 9.8 Volts and 3 amps. Alternatively, Li-Po batteries can also be used for short-term tests and mobility. Because the power requirements cannot be fed, then the motors fail, and the system shuts down. Moreover, if the motors get heated, then cold gels of the spray should be applied to cool down the components. To reduce the friction between Lego bricks and moving parts, we used machine oil.
Lastly, during the sensor sampling, we discovered that the colour sensor could not recognize the colour of the Lego bricks accurately due to the speed of the conveyor belt. Instead of reducing the velocity of the conveyor belt, we provided a buffered reading at the cyber part by wrapping the method into the sensor reading method and physical buffered transition by moving the colour sensor between two conveyor belts. Naturally, when Lego bricks are transferred from the first conveyor belt to the second one (layer 1 to layer 2), we benefited from the natural delay caused by the friction between them. This delay and buffered reading raised accurate decisions on the colour of the Lego bricks. This decision can be supported by using pattern matching algorithms, machine learning, and/or dynamic buffer size. Because we are aware that selecting industrially standardised sensors does not guarantee ideal operation and reducing the sensor errors under harsh and corrosive conditions is another challenge [40].

VI. CONCLUSION
In this paper, a system to integrate software agents and CPS is proposed based on SPADE, RaspberryPI and Lego technologies. The design and implementation of this production line system are discussed. With employing agents and encapsulating embedded functions, an agent-based control on the CPPS is achieved. In this way, it is also avoided to deal with low-level details of embedded software for robot programming. Also, the distributed and mobility capabilities of software agents helped to develop heterogeneous components in the system. Our system based on the Lego technology may also assist the education activities especially considering how automation on CPPS can be supported via software agents.
As a future study, we aim to improve the current reasoning and planning capabilities of the agents in our system using belief-desire-intention (BDI) logic [41]. Additionally, we intend to provide a multi-paradigm approach, e.g. by benefiting from the IoT paradigm, so that our system both works with the same system instances (homogeneous infrastructures) and incorporate with different type systems (heterogeneous infrastructures) by establishing a network. For this purpose, both the state-of-the-art on agent-based IoT systems, as well as our past experiences, [42] will be considered. In addition, a modelbased framework can also be developed to support the current development process by automatically synthesizing both agent code and embedded software [43]. To achieve this, modeldriven engineering techniques similar to the ones we used in [44], [45] can be applied again to these systems to reduce the complexity.