17.1 Introduction

The current manufacturing scenario is characterized by high market unpredictability. Agility is therefore a central challenge for modern companies that need to understand and be proactive toward their product offer in respect to “what is offered, when it is offered, where, how and by whom” (Brown and Bessant, 2003).

The “what” and the “when” are particularly relevant to the research in emerging paradigms because they account for variety, customization, and volume, as well as timing, speed, and seasonality (Brown and Bessant, 2003).

In this scenario, several design approaches and models have been proposed in the last decade to enable reconfigurability and subsequently enhance the companies’ ability to adjust their offer in nature and time.

From a paradigmatic point of view, research has concentrated on the organizational structure of the shop floor and the associated control aspects. Concepts such as reconfigurable manufacturing systems (RMSs)(Koren and Shpitalni, 2010) and fractal factories (FFs)(Montreuil, 1999) support the physical construction of production systems by regulating their layout and making a few assumptions about their logical organization. On the other hand, concepts such as bionic manufacturing systems (BMSs)(Ueda, 1992), holonic manufacturing systems (HMSs) (Van Brussel et al., 1998), and evolvable assembly systems (EAS) (Ribeiro et al., 2010) essentially provide the theoretical guidelines for the logical/computational organization of the system. (See Tharumarajah (1996) for a comparison between BMS, HMS, and FF and Setchi and Lagos (2004) for the rationale supporting the shift from dedicated lines to flexible manufacturing systems and finally RMS.)

While these paradigms provide the conceptual framework and the main design guidelines, their actual interpretation and implementation has led to a wider set of architectures (Monostori, Váncza and Kumara, 2006; Leitão, 2009; Parunak, 2000; Pěchouček and Mařík, 2008).

These architectures align high-level principles with technological offerings and limitations while seeking to address the reconfigurability requirements of the following (Mehrabi et al., 2000; Rösiö and Säfsten, 2013):

• module mobility—modules are easy and quick to move and install;

• “diagnosability”—it is quick to identify the sources of quality and reliability problems;

• “integrability”—modules are easy to integrate into the rest of the system;

• “convertibility”—it is easy and quick to switch between existing products, and it is easy to adapt the system to future products;

• scalability—it is easy to enlarge and downsize the production system;

• “automatibility”—a dynamic level of automation is enabled;

• modularity—all system elements are designed to be modular;

• customization—the capability and flexibility of the production system is designed according to the products to be produced in the system.

Instant deployment, as addressed in the present chapter, directly addresses mobility, integrability, convertibility, scalability, and customization. Mechatronic modularity is a prerequisite and is enforced by the proposed architecture and the considered modular design. Diagnosability was not specifically tackled.

In this context, the chapter analyzes the agent-based architecture related to the Instantly Deployable Evolvable Assembly System (IDEAS) project that is inspired by the eEAS paradigm (Ribeiro et al., 2010) as a mechanism to enable fast deployment of mechatronic modules. EAS advocates the use of process-oriented modules and envisions the production system as a collection of processes and the associated interacting agents.

The architecture and the related test cases are used to draw the main lessons learned in respect to technological and conceptual implications.

In this context, the remainder of this text is organized as follows: Section 17.1 discusses the main deployment challenges; Section 17.2 details the reference architecture and associated concepts; Section 17.3 presents the principal implementation decisions; Section 17.4 features the main lessons learned; Section 17.5 discusses the benefits of the proposed approach; and Section 17.6 reflects on the main conclusions.

17.2 Problem Overview

Deployment is a fundamental activity in the reconfigurability equation. Instantaneous deployment entails several technological and conceptual assumptions in order to be effectively implemented.

The most obvious of such assumptions is the mechatronic compatibility of the modules. Mechatronic compatibility implies that, when a module is plugged into the system, the system should automatically supply: power, hydraulic or pneumatic lines, I/O access, network access, and a proper mechanical infrastructure suitable for the module’s operation.

Different modules have necessarily distinct requirements that render the issue of universal mechatronic compatibility extremely hard to tackle. Assuming that the mechatronic compatibility issue can be solved by adopting specific solutions from a module’s vendors, one should also consider the logic dimension of the deployment problem. The logic dimension presents several challenges and assumptions of its own. In the holonic/multiagent way of designing a system, there is frequently a strong link between a holon/agent and its physical counterpart. If the module has an embedded controller capable of hosting the holon/agent, then it can be straightforwardly located therein. Under different circumstances, the holon/agent must be located in a computational resource that lies somewhere in the production floor but that is able to identify the physical part under control. The direct implication of this is that components should ideally be identifiable by the system at a logic abstraction level that is lower than the one considered by the holonic/agent-based architecture.

If these requisites are met, the mechatronic infrastructure can be theoretically used for instantaneous deployment. By instantaneous deployment, it is meant the plug and produce of a module without any reprogramming action and a minimum of reconfiguration effort.

The challenge from a logical point of view is subsequently to ensure:

• The relocation and existence of the holons/agents and any auxiliary binaries to/in the correct controller.

• The correct reaction of the system (and its holons/agents) during redeployment when:

• Several agents share the same controller but only a few are redeployed.

• Redeployment entails a change in the process previously instantiated in the system.

• The user has a set of tools that enable him to easily reconfigure the platform, and the platform supports reconfiguration in a straightforward way.

These challenges have motivated the development of the ideas agent development environment (IADE) stack, detailed next.

17.3 IADE—Its Architecture and Associated Concepts

The IADE core has six main classes of mechatronic agents (Figure 17.1), as well as some other agents used as IT integration artifacts and whose function falls outside the scope of this chapter.

These classes of agents are instantiated and deployed to cover distinct aspects of shop floor control and reconfiguration. Furthermore, there is a main division concerning the agent’s functions. While some are focused on supporting several production processes (process-oriented agents), others are purely focused on the logistics of handling parts across the system (transport agents). The deployment agent (DA) is an important reconfiguration entity because it acts as the IADE entry point in a controller. IADE agents can be deployed in any controller hosting a DA.

17.3.1 Process-Oriented Agents

17.3.1.1 Resource agents

The most basic unit in the IADE architecture is the resource agent (RA) (Figure 17.1). The RA is responsible for interfacing the agent world with the physical world. The technical architecture of the RA is complex to devise and makes some assumptions regarding the underlying technological infrastructure. The functional requirements in the context of IADE were that:

• An RA should be able to control any equipment, provided that an integration library handling the translation from the agent language to the controllers’ language is available.

• RAs should be able to share computational resources and it should be possible to instantiate them outside a controller and then migrate them to the different controllers.

• Once deployed, RAs become associated with a specific equipment and controller. This means that if the whole is unplugged and re-plugged elsewhere in the system, all the agents in the controller should be able to recognize the new context and assess if they can still operate.

The technological assumptions are therefore:

• The controllers should have enough computational resources to host a given number of RAs and should not accept to deploy an RA if the maximum limit has been reached.

• The language in which the agents are programmed should support the dynamic loading of integration libraries. These integration libraries should exist in the controllers where the agents are deployed.

• The agents should be described using a meta-language that specifies their abilities. This meta-language allows the complete textual definition of an IADE agent and is used as a support for the (de)serialization of the agent’s instances during (re)deployment. Further, this meta-language should support the definition of mappings between the agent’s abilities and the integration libraries so that the agent can dynamically locate and use them.

This results in an RA architecture where there is a generic layer shared among all the RAs in the system and that enables them to interact with all the other agents. This generic layer is able to process serialized agent descriptions, in the aforementioned meta-language, and in runtime, load the integration library, which becomes the non-generic part of the agent (Figure 17.2).

The internal architecture of the RA therefore comprises four main generic blocks. The generic communication block ensures that the RA uses the communication semantics of the rest of the platform. The generic configuration block is able to process the agent description, generate a list of the agent’s abilities, and create a mapping between those and the available low-level integration libraries. These libraries are the latest boundary between the agent environment and equipment and should be developed for each new module that needs to be integrated. The IADE stack leaves it open in regard to who should develop these libraries. In most cases, it should be the module’s provider that sells an agent-ready module, while in other cases it may be the user that develops the library for a very specific case in the system. In any scenario, the library development leaves the self-organizing behavior of the agent platform untouched. The details concerning library design can be found in Ribeiro and Barata (2013).

The negotiation block allows the RA to engage in the negotiation procedure before accepting the execution of a certain task. In the particular case of the RA, it will receive calls for proposals regarding the execution of some of its processes. The RA will reply with the corresponding execution cost.

Finally, the execution block manages the mapping between an agent’s abilities and hardware execution by generically activating functions in the integration library.

17.3.1.2 Coalition leader agents

Coalition leader agents (CLAs) are process-oriented units that, unlike the RAs, do not have any direct link with shop floor equipment and, instead, represent processes and organize the abilities of RAs and other CLAs.

The functional requirements for a CLA were:

• Compositions of CLAs should support different granularity levels of process definitions, theoretically up to an infinite level.

• CLAs should be able to autonomously replace agents under a coalition if they become inoperable, provided that the CLA is able to negotiate a valid replacement.

• CLAs implement user-defined processes. The user should be able to enforce the use of a specific module, which can only be replaced by other modules on a replacement list. If the list is empty, the CLA has the autonomy to negotiate the modules that will be under its coalition.

• CLAs should not bring together modules that are physically incompatible.

The last point is especially complex in the sense that validating whether two agents can work together goes beyond merely comparing their abilities. In the IADE architecture, this is critical if the CLA is managing several RAs. A simple example to illustrate this condition is when a CLA that is managing a pick-and-place operation is informed of a fault in the gripper (RA). It will replace the gripper, but it cannot allocate another gripper (RA) that is not within reach, even if the RA abstracting that gripper has exactly the same ability. To prevent these situations, IADE uses the notion of “area” to define a partition of the system where the agents therein are able to physically interoperate (Figure 17.3).

In the preceding example, areas 1, 2, and 3 prevent CLAs 1, 2, and 3 from exchanging resources. Areas 4 and 5 only contain CLAs. Other CLAs are allowed to allocate the CLAs in these areas as they see fit. In fact, areas 4 and 5 could be considered unique areas. The definition of “area” is necessarily system-specific and serves the purpose of constraining the action scope of agents, either to prevent the allocation of physical resources, as mentioned before, or to restrict the negotiation scope of CLAs and speed up the negotiation process.

Each area has an associated yellow pages agent (YPA). These agents behave as local repositories for the agents’ abilities available therein. Other agents are therefore able to query the YPA for all the agents that implement a certain ability, or for the abilities of specific agents.

From an architectural point of view, CLAs share the same structure as the RAs (Figure 17.2). The main difference is that CLAs do not rely on integration libraries. Their action scope is completely contained within the multi-agent system. Therefore, once a CLA receives its description it will immediately start the process of allocating agents that can fulfill the processes described in that description.

When there is an execution request, the CLA will go, in a stepwise manner, through the process description and invoke the abilities of the corresponding agents according to the defined execution flow.

IADE supports the execution of sequential, parallel, and decision flows. These flows are called skills and they define the agent’s execution abilities (Figure 17.4).

Figure 17.4 shows the distinct flows that can be executed in the IADE context. Each skill starts as a sequence of subskills. It is then possible to create parallel execution flows, such as at the top of the picture (skills 3 and 4). The execution semantic for a parallel flow is that, as in the preceding case, the execution of skills 3 and 4 starts immediately after skill 2, and skill 5 is only executed after 3 and 4 have finished their execution. The IADE stack also supports encapsulation. As detailed in the picture, the composite skill can be reused to define new skills. Although there is normally an identity between a composite skill and a CLA, from the stack’s point of view CLAs can host more than one skill.

Finally, the stack allows the definition of conditional flows whereby the CLA’s execution block evaluates a specific parameter and redirects the execution flow accordingly.

Execution flows are normally defined from left to right and loopbacks are not allowed except for the decision flow that can implement the pattern shown in Figure 17.5. The dashed lines denote the parameter of skill 1 that is being evaluated, and the darker lines denote the execution path.

The execution semantic is, when the decision flow is considered in the loopback form, that a skill (skill 1) is preliminarily executed and produces an output that is evaluated by the decision block. Skill 1 is then continuously executed until the desired output is attained. Under these circumstances, the execution resumes and the other skills (5 and 6) are executed.

17.3.1.3 Product agents

Product agents (PAs) are top-level CLAs and contain the process plan for individual products. PAs behave as clients of the rest of the system. They manage their own production plans, including the selection of the agents that fulfill the different processes. The PA will therefore negotiate both with the transport system’s agents and the process-oriented agents the execution logistics.

The functional requirements for a PA were:

• Each PA establishes an identity relation with one product, part, assembly, or subassembly in the system and manages its production plan.

• PAs are independent from each other. It should be possible to modify individual production plans.

• PAs can be removed from one region of the system and reintroduced elsewhere. After this change, the PA should resume its process plan.

• PAs leave the system at the end of their process plans.

There are some relevant technological assumptions in the case of the PAs. In particular, they require some tracking mechanism. Ideally, PAs would have their own computational infrastructure. While this may be unfeasible due to cost reasons, the alternative lies in using a standard RFID system that can keep track of the PAs using an identity relation and inform the corresponding agent of the relevant changes.

17.3.3 Deployment Agents

The DA is an important piece in an IDEAS infrastructure. It is the DA that enables the instantiation of agents in different controllers. In an IDEAS platform, it should be possible to deploy any agent in any controller running a DA. The DA is therefore able to process the agent description, verify whether or not the agent to be deployed can run on that platform, and if so, create the corresponding agent (Figure 17.6). A detailed description of the deployment procedure can be found in Ribeiro and Barata (2013).

The DA also has the role of ensuring consistent mechatronic redeployment. In this context, if a controller hosting several agents is to be unplugged and replugged, the DA will ensure that all the agents will perform a controlled shutdown and store all the relevant status information. In addition, the DA must update the unplugged agents, once they are replugged, about their new location.

Although the DA can manage any IADE agent, some restrictions apply when it comes to plugging and unplugging agents. In particular, it makes sense to perform these operations in RAs, TEAs, and HUAs because they execute their abilities in a very specific region of the system and they have an identity relation with some equipment. The same is valid for CLAs if they have to manage RAs, because there might be an identity between a CLA and a station that is composed of many RAs.

However, in the case of higher-order CLAs and PAs, the only reason for unplugging them has to do with the need to migrate them to another computational platform. There is no other obvious reason to consider migration otherwise.

Even in the case where a PA is manually removed from the system and relocated, at that different region that PA is still alive. The main difference is that its location is undetermined. In this context, PAs and higher-order CLAs are normally deployed once and rarely redeployed.

17.3.4 Reference Agent Interactions

The aforementioned agents interact according to a set of well-defined generic interactions. These are specified in the class scope of the agent rather than at the instance level. This is an important characteristic to ensure that the system, as a whole, has the ability to self-organize.

For the sake of brevity, only the main interactions shall be analyzed. The interactions follow both the FIPA Request and the FIPA Contract Net Protocols.

The first interaction pattern relates to the process of plugging in any IADE agent (MAC) (see Figure 17.7).

After the agent bootstrapping process, either mediated by a DA or done on its own, the agent will contact the YPA in that area and do a preregistration of its skills. It will then contact the TEA that owns the docking point, whereupon the agent will perform its skills and request authorization to start operating there. Once the authorization is issued, the TEA will request a list of all the agent’s skills from the YPA. The YPA then makes the registration permanent and allows other agents to view the skills of the plugged-in agent as well. If the agent receives a negative reply from the TEA, it will withdraw its registration from the YPA. If the agent is unable to unregister, then the YPA will timeout and automatically remove the preregistration.

As soon as the PAs have the minimum number of process-oriented agents in the system, they can activate their production plans (Figure 17.8).

The PA will contact the TEA that matches its current location and request the transport cost to reach a specific skill. The TEA will return a list with all the agents that implement that skill and the associated transport cost. Recall that these transport costs are being continuously updated so that the PAs are always forwarded to the best route. The PA will then negotiate the potential execution cost with the agents at the different locations. Finally, the PA evaluates both the transport and execution costs and commits to a decision informing both the transport agent and the process-oriented agents. This decision will necessarily affect the status of the system because the process-oriented agents are now anticipating one more “client” and can therefore regulate the execution cost accordingly.

The IADE architecture allows the user to define any metric for the decision process at the agent level. The decisions are generically based on an integer with the “lower the better” semantic. The agents therefore expect a function that is used in the decision process. One possibility is to use a weighted metric that more greatly values the transport cost if the PA is far from the destination, and the execution cost otherwise. The definition of the metric/decision function is an important activity in self-organizing systems because its parameterization changes the behavior of the system.

If the execution locations/modules are enforced by the user, they take precedence over the negotiation procedure.

After the PA commits to a decision, the transporting procedure is started (Figure 17.9).

The entire transport procedure is transparent to the PA. The PA is only responsible for triggering the first interaction by requesting a move request from the TEA associated with its current position. When the PA reaches the head of the conveyor, the TEA outputs it to the HUA that will decide, based on the PA’s final destination, what is the next TEA. Once the final destination is reached, the TEA associated with that location will notify the PA. The PA then requests the execution from the agent at that location (an RA or a CLA).

The negotiation process is then repeated for the next execution step on the PA’s process plan.

17.5 Benefits and Assessment

The proposed architecture was designed above all to ensure instant deployment of mechatronic modules in a wide range of systems. In this direction, its assessment was directly executed through its application on numerous systems. Under the scope of the IDEAS project, the two demonstrators described earlier were considered. Since then, the architecture has been successfully applied in 3 more prototypes that use different modules supported by different technologies. In all these scenarios, it was possible to instantiate and deploy the different components using the described agents. For every system, there is always a small reprogramming effort required when a new module is to be integrated. By new, it means a module that was never “agentified.” The architecture has shown an adequate level of system descriptiveness to tackle the different systems without the need for reassessing the agents or their interactions. The possibility to systematically instantiate it in very distinct systems is one of the main benefits of the architecture. Further, among these different systems, the “agentified” modules become logically interchangeable. We stress logically because in order to unplug and plug a module from one system to another the geometric and mechanic constraints need to be considered. If the systems respect these constraints, the instant deployment is straightforward given the proposed approach.

Under these circumstances, if the modules can be rapidly transported between the two different deployment locations, the bootstrapping time of the module is around 1 min even with the heavy technological stack considered before.

The overall process is extremely safe because there is no reprogramming involved in most cases, and the generic components of the agents that govern all the system-level interactions always remain untouched even if an integration library needs to be developed.

This clear separation between generic interaction logic and component specific logic is also extremely important, because it enables the simulation/emulation of a component in a system without actually activating a physical part of the component. The system can be first tested with the simulation library, and once the response is convergent, this library is simply replaced with the one that activates the component. This was also demonstrated under the IDEAS project and it is an industry-derived requirement that greatly facilitates system integration and testing.

As mentioned before, the control infrastructure lags in performance, but the main concept that the architecture seeks to implement and demonstrate is the full-featured deployment of the modules. This includes control and monitoring aspects. In this respect, this benefit has been clearly demonstrated in different systems.

17.6 Lessons Learned

Technology is still one of the main limiting factors when considering seamless deployment of modules using standard components. The test cases described earlier show two different scenarios where the generic aspects of the agent platform enable high reactiveness to changes by supporting dynamic rerouting under faults, execution renegotiation, plug and produce, and rendering the platform inherently more robust, scalable, convertible, and customizable than traditional automated systems. However, the capacity to support these advanced features comes at the cost of a considerable technological stack that introduces significant performance drawbacks. In particular, while the action of unplugging and replugging a module in the previous test cases takes approximately 2 min, including disconnecting and reconnecting the module and the bootstrapping time of the controller and corresponding agents, the average round trip time of each message, including its processing at the receiver’s end, takes 380 ms on average. When one relates this value to the architecture, it is obvious that functionality encapsulation using several coalition leaders severely impacts the system performance. This performance issue affects, in fact, all the architectures that use some form of functionality encapsulation.

The use of a virtual machine, in the present case the JAVA virtual machine, is of extreme importance from a deployment point of view, because it enables the decoupling between the code and the underlying platform and improves the amount of generic features that can be considered at the agent platform level. In particular, it allows for the generic description of the agents and subsequent instantiation in any Java-enabled platform and provides support for the development of low-level libraries that handle any platform-specific details such as I/O mappings and network interfacing.

From a technological point of view, there is a clear compromise between performance and the ability to deploy the agents across a wide range of controllers in a systematic way. The present architecture explored the latter in using DAs that enable all the agent-ready devices to identify themselves in the system and be ready for deployment. Under these circumstances, it is also possible to develop tools that help users support the migration of agents from one device to another and enable them to proactively move between platforms. Mobility may be a desirable feature to allow the system to self-regulate the computational load on the different controllers. The standard support for mobility varies frequently across different implementations of the technological stack, and often, as in the present case, it has to be implemented in a customized way.

The technological constraints dictate a very strict compromise between functionality (and the ability to reconfigure the system) and performance.

17.7 Conclusions

One of the biggest challenges with the application of concepts that have been inspired by many paradigms is that they are theoretically elegant and work on a conceptual plane, but they are not easily implementable in a mechatronic context, especially when it comes to elusive concepts such as self-organization and emergence. It is somehow easy to visualize that two or more entities can operate together if they just identify themselves, and that together they will generate a new process.

The main fault with this reasoning is that it is not enough that the entities know of each other. They must assess if they can physically interact. This entails verifying operational limits and geometric constraints. Unplugging and replugging a robot at least implies that the module should be reparameterized so it can reach the parts in its new location. This also means that, at the very least, the geometry of the assembly line needs to be defined in respect to a common reference frame and that all the manipulation that is detailed in the products’ production plan is based on that reference frame as well.

It is also not so trivial to generate a new process just by setting two parts together, because this would probably mean getting something out of nothing.

If the approach is top down, as in the present case, the user generates open and generic descriptions of the main processes and then assigns them to the CLAs that are able to allocate valid resources for each step of the process. Further, they can reorganize themselves if the resources fail or leave the system. If the approach is bottom up, the resources must organize themselves into meaningful structures, otherwise it is just random trial and error.

This does not mean, however, that self-organization and emergence are useless. On the contrary, if properly explored, they can enable systems that are highly responsive to changes.

These systems denote behaviors that are fundamentally different from current automation systems. This has misleadingly created an idea of unpredictability.

In their current form, they are unpredictable, mostly because the work on assessment and validation (methods and tools) is still incipient.

The other challenge to be overcome is that such systems have been mainly developed by academia. The result is that the standard industrial equipment is not adapted to operate with multi-agent technology, nor can current multi-agent technology meet industrial performance and safety requirements. A few exceptions exist, but they rely mainly on proprietary technology.

Different industrial players also perceive the advantages of such architectures and technologies from distinct perspectives. The motivation for module providers is to commercialize modules that are interoperable not only from a mechatronic point of view but also from a process perspective. The localized processing power is also an opportunity to add value in the form of maintenance services that become associated with each module’s abilities to self-monitor. System integrators directly benefit from the described approach because these intelligent modules offer ramp-up and operational support, and the general absence of reprogramming render the integration process much safer. End-users benefit from a system that can be easily changed to overcome production disturbances and that enables them to tackle emerging business opportunities. Some players, on the other hand, do not perceive at all the need for the emerging concepts and technologies.

With the continuous technological convergence now reanimated by the developments in cyber-physical systems, the perspectives for the adoption of such systems and architectures at an industrial level are increasing and will hopefully circumvent the set of well-known barriers (Marik and McFarlane, 2005). The proposed work is a small step in that direction.