Context-Aware Plug and Produce for Robotic Aerospace Assembly

In a manufacturing sector characterised by market unpredictability, increased global labour costs, and growing consumer demand for highly personalised goods and services, producers are naturally pushed to remain competitive by maintaining shorter times to market, increased product diversity and specialisation, and shorter product lifecycles. This has resulted in a growing body of research into production systems that can incorporate new technologies and provide high levels of robustness, resilience, and responsiveness.

There are a number of approaches to delivering these characteristics, including flexible manufacturing systems [2, 3], reconfigurable manufacturing systems [4], automatic and adaptive control [5], and manufacturing systems modelling and simulation [6]. One specific technology that has been developed in this area is “plug and produce” [7], named by analogy to the concept of “plug and play” in computing. The EU FP7 PRIME project [8] developed a multi-agent approach to plug and produce with commercially available components for simple robotic assembly tasks in a fixed system dealing with dynamic product changes and unexpected disruptions [9‐11].

EPSRC Evolvable Assembly Systems (EAS) [12] was a fundamental research project following on from PRIME. It aimed to deliver adaptable and cost effective manufacture by enabling a compressed product life cycle through the delivery of robust and compliant manufacturing systems that can be rapidly configured and optimised. In turn, this should enable the reduction of production ramp-up times and programme switchovers. In summary the project proposed a multi-agent system [13] to provide manufacturing control systems with the characteristics of agility, multi-functionality, adaptability, and resilience. Further information on the EAS project can be found elsewhere [14‐17], but the remainder of this section focusses on how EAS viewed the concept of context-awareness in terms of intelligent production systems. One product of the EAS project was the concept of a context-aware cyber-physical production system, shown in Fig. 1 and discussed in more detail in [18].

The basis of the concept is that of a shared context for the system, where the context is knowledge about the system and its current state. This context allows all the elements of the system to share the relevant knowledge and information required to accomplish the system function. The foundation of the context is the digital information concerning the system, starting with the information created at design and commissioning (“digital twin”), and added to throughout life by the operation of the system (“digital thread”). This contextual information is gathered and handled by distributed intelligence across a set of modular system components. Pervasive metrology¹ allows for the highest quality information at all times. The information can be used to allow the system to self-adapt and maintain its correct functioning. The final aspect of the concept allows for the human workforce and the automation to work together most effectively by assigning decision-making and operations in a hybrid manner to best allocate responsibilities. In summary, the context-aware cyber-physical production systems concept enables the smart integration of all equipment in order to best leverage the available information and thereby accomplish the production aims in the most efficient manner possible with the available resources.

WingLIFT focusses on a specific instantiation of part of this concept in order to prove its applicability in an industrial environment. The WingLIFT approach involves the aspects of data sharing that enable smart integration of dynamic modular production systems through the use of distributed intelligence. This distributed intelligence is presumed to be based on multi-agent technology, but an agent is not a “hard requirement” for every resource in the system, as will be discussed later. Other parts of the WingLIFT project include some aspects of pervasive metrology, but they will not be included in this paper.

The high-level use case identified in the WingLIFT project for this work is as follows. A semi-automated aerospace assembly cell exists in which a small number of automation platforms (e.g. industrial robots) share a larger number of process end effectors (e.g. end effectors designed to either drill, fasten, seal, or position components). Each end effector may have a large number of possible configurations (e.g. for the drilling end effector, there may be a variety of cutting tool sizes; for the fastening end effector there may be a variety of fastener diameters and lengths; and so on). These configurations may be changed dynamically during operations either by the automation control system, or by the operator. Both the automation platforms and end effectors are expected to be moveable around the cell through the use of automatic tool changers and either rails or moveable platforms. The system therefore requires some method for maintaining knowledge of the current configuration state of the whole system, including the hardware configurations and positions of both automation platforms and end effectors, and the software configuration of the control system.

Further developing the high-level use case described above, the project defines a set of specific use case scenarios. The scenarios are as follows:

For the purposes of this paper, we will describe in detail the end effector pick-up use case and a generalised “configuration change” use case that combines both hardware and software changes. The project utilises a multifunctional UML approach (i.e. according to the Object Management Group’s Unified Modeling Language [19]) to describe the use cases and solution; for this paper we will describe each use case with a table.

Based on the use cases developed in the project discussed in Sect. 3, a generic process flow has been identified and is presented diagrammatically in Fig. 2 using the example of the “end effector pick-up” use case. This generic process flow allows a solution to be designed that will address the range of problem scenarios facing the system, where each use case is a specific example, rather than designing a solution specifically for each use case and then attempting to combine them.

Each use case follows the following process:

Placing some of the terms used in the previous section into context, the top-level agent-oriented architectural concept, based on that of the EAS project, is shown in Fig. 3. Each resource maintains a local internal model for low-level decision-making and control. All resources in the system are connected to a shared context which forms a “joint model” from the many local internal models. High-level decision-making can be performed on this joint model. The shared context is also the link to the wider enterprise and any additional external data sources or storage locations.

Building on the EAS project, it is assumed that the majority of the resources in the system will be controlled by intelligent agents [13]. In Sect. 4.4, integration cases will be discussed where no agent is present.

The “distributed shared context” in the system is transmitted over a databus that performs the functions of both a Manufacturing Service Bus and of an Enterprise Service Bus (a hybrid “manufacturing/enterprise service bus”). This “shared context” is effectively all relevant data that is collected from the system; it is a joint model of the system context that is generated by the collection of the internal models of all the system elements. Once on the bus, this data can be used as required by the actors in the system, or stored for later use.

In terms of implementation, all inter-agent (or inter-resource) communication in the system is handled by a publish-subscribe databus implemented as a Data Distribution Service (DDS, as specified by the Object Management Group (OMG) DDS standard) [20]. The publish-subscribe approach is one in which, rather than the data publisher sending data to one or more specific recipients, the data is published to a channel. The data subscribers subscribe to a channel and receive data from that channel. This frees publishers from keeping track of who is interested in their data, and subscribers from keeping track of data sources. The channel can also take care of communication implementation details, rather than requiring the agents to do so. Such details may include quality of service requirements, caching or persistence, and so on.

Physical hardware resources in the WingLIFT architecture are usually controlled by intelligent agents deployed on embedded computers. Each agent is connected to the resource using a resource-specific translation layer and to the rest of the system using a DDS. In the EAS project this was the most common type of stack, but WingLIFT aims to address a wider range of resource types. Figure 4 shows this more complete view: the physical resource may provide a software interface, or may require a hardware interface; the system can also interface with humans though software running on portable devices; and the system may include software services running on other computing hardware. There should be no difference to the architecture whether the resource being managed is physical automation, a human, or a software service.

Also shown in Fig. 4 are the data flows from the resources up to the databus, the options for where each piece of functionality is deployed in hardware terms, and the likely division between provided and developed functionality. Resource hardware is controlled by its own controller as normal. That controller then interfaces with the system databus either through an agent on an embedded computer, an agent deployed directly on the controller (in the case of a software PLC for example), or directly through its own network application programming interface (API). In most cases some translation will be required from vendor specific semantics to open common semantics for use on the databus. Some resource hardware will provide an API and open communication standards for interfacing with. Some “legacy” resource hardware may require a more complex translation layer that features hardware technical interconnectivity as well as semantic translation. Human resources communicate with resource agents via human-machine interfaces (HMIs). In the case of resources that directly connect to the databus through their own network API without an agent, they can only act as publishers and/or subscribers of data. If any decision-making takes place, it must either be handled entirely inside the resource, or a separate agent must be deployed on the databus to act on the data published and/or subscribed to by the resource.

In order to validate the proposed solution, we have developed a demonstration scenario based around the project use cases. In this scenario, two robots share a number of end effectors through the use of automatic tool changers as described in Sect. 3.1.

The aim of the demonstrator is to show how the two robots can share the end effectors and how the system can maintain awareness of the current configuration of both the robots and the end effectors in the face of manual changes. A visual representation of an example usage flow of the demonstrator is given in Fig. 5 in the format of a UML activity diagram.

This shows the example of an end effector pick-up: first the use case is triggered by the operator making a selection on the HMI. This is handled by the software once it receives the ChangeEEorToolCmd request. Once the end effector has been picked up, the status is updated locally (by the robot once the task is complete) and at the network level (when the robot publishes the context update). Finally, the operator is notified once the change is complete.

Based on the WingLIFT architecture, databus concept, and integration approaches all described in Sect. 4, Fig. 6 shows the overall logical structure of the demonstration cell described in this section. Each robot is controlled by its own controller, which is in turn connected to a WingLIFT agent that is connected to the DDS databus. Also connected to the databus is an HMI for the operator, and an agent connected to each end effector. The end effector information is transmitted onto the bus through this agent. The bus carries all configuration and state information for all resources in the cell: the location of the robots and end effectors, the configuration state of all end effectors, and which end effector is connected to each robot. The remainder of this section describes the implementation of the cell in some more detail.