1 Introduction

1.1 Motivation

Mass customisation, shorter product lifecycles, smaller production batches, and higher product variability all lead to the requirement for manufacturing systems that are rapidly reconfigurable and self-adaptive in response to disruption [3]. This requires methods to aid in the design and modelling of such systems, both by humans and for automated self-design or self-reconfiguration by an agent control layer. In this work, we take an approach based on considering how system structure and behaviour relate to the intended system functions, drawing on the Function-Behaviour-Structure (FBS) formalisations by Gero, Rosenman, Umeda, and others [14, 16, 27, 34, 40, 48, 49]. The main driver is to be able to identify when a reconfiguration needs to occur and what that reconfiguration should address, and then “design the change” that would accomplish it.

1.2 Literature review—design frameworks

In general, the design process links requirements to components that are either to be freshly designed or selected from a set of existing components. For production systems, these requirements stem from the product and also a range of other quality requirements to optimise or evaluate against.

The range of approaches for design include the axiomatic approach [44], which uses domain models and rules to generate new designs, and the algorithmic approach [30] which goes step-by-step, decomposing the problem, solving the sub-problems, then re-synthesising the sub-solutions to form the final design solution. This allows the problem to be addressed at the correct level of granularity, appropriate to current practices.

The FBS approach of Gero, Rosenman, Kannengiesser, and others [14, 17, 34, 35] forms part of the research area in functional modelling [13, 51]. Functional modelling is concerned with how to represent knowledge about function, and can be applied to systems modelling and design. The FBS approach takes a holistic viewpoint looking at both the socio-cultural and techno-physical aspects of a system, clearly separating the subjective function of a system from its objective structure.

This function-based description of an object allows for a more effective decomposition according to the various uses an object must fulfil at any given time. When this is applied to modular and reconfigurable systems, the decomposition can be directed according to the available modules [23, 24]. Such reconfiguration must take into account the availability and connectivity of existing modules, and this problem is further complicated when a product-process-system view is taken [47]. In such a case, the reconfiguration from currently available capabilities to required capabilities may take place at any level. This requires a clear definition of task decomposition and assignment to modules or processes.

There are a number of integrated approaches for deriving the required process for a product representation. Some examples use graphs or petri nets [43] or a rule-based approach [31], but these often either operate at an abstract level in terms of the system or are extremely knowledge-intensive on the human side [52]. This is due to being focussed towards assisting system designers in system configuration, simulation, and evaluation.

There are some approaches for the computer-aided design and modelling of assembly systems [6, 20, 26, 36, 52] but they generally do not address system qualities such as self-adaptation, self-reconfiguration, and self-healing, more generally called the self-x qualities [28, 29]. Those approaches that do address self-x qualities in an automated manner [10, 25, 46, 50]—for example through agent-based systems—often focus primarily on one aspect, such as the software and configuration side, rather than a complete product-process-system approach that includes a formal description of the system from its function to the physical hardware.

Other works seek to address the design of specific sorts of production system in more specific detail, for example “Assembly 4.0” type systems [9], or large-scale aerostructure assembly [21], or are primarily concerned by the safety and ergonomics considerations at the heart of manual assembly system design [7, 8, 37].

Despite this existing body of work, we can therefore identify three main issues relating to design frameworks:

  1. 1.

    The majority of existing production system design frameworks only address single-product or single-family production, rather than a system that may have to drastically refocus on another product or process entirely, as well as being under a changing set of non-product requirements.

  2. 2.

    Existing FBS approaches do not address adaptive production systems; they focus on creating design artefacts such as the product itself, or a static system. There is a critical requirement for a method applicable to self-x production systems that change over time.

  3. 3.

    Many production system design frameworks are either extremely abstract or knowledge-intensive, making their automated application to self-x systems problematic. The majority of automation-focussed frameworks for self-x systems focus primarily on only one aspect of the system, missing a formal description of the whole system.

With this in mind, we propose a solution that is capable of addressing a wide range of dynamic requirements, takes advantage of the inherent self-x properties of the system components as a “top-level attribute” of the framework, and allows for a formal description of the whole system in order to enable its application to automated—in our case agent-based—control systems.

2 Overall approach

The design process for an adaptive production system starts with the products that are to be manufactured. These are defined in “recipe files” that are the starting point for the system’s functional requirements. Other requirements are also considered: the requirements for adaptation, and the requirements relating to achieving and maintaining system quality. The other main input to the design process is a set of what Gero would call “design prototypes” [14]—the set of possible or available manufacturing resources for use in this system specified as “blueprint files”. From these two main inputs, the design process generates the set of behaviours required of the recipes and generates a solution from the available set of resources that could express those behaviours. An overview of the approach is given in Fig. 1. Section 3 defines the design process and the ontology supporting it in more detail. Specific details of how recipe and blueprint files formalise product characteristics and system structure respectively is described in Section 4, along with an overview of the implementation of behavioural evaluation that forms the core of the approach. Finally, Section 5 describes a real prototype implementation example.

Fig. 1
figure 1

Behavioural design process: overall approach

Full size image

3 General behaviour model

3.1 Views

A key concept in Umeda et al.’s work on FBS diagrams is their use of different “views” or “aspects” [48, 49] that are described as “a collection of all relevant entities, attributes, relations, and physical phenomena of the current interest”.

In essence, this concept formalises the fact that it is not possible or feasible to represent everything about an entity (in our case a product, system, or sub-system) in a single encapsulated description. When you are designing a takeaway coffee cup for example, you are interested in how well it holds liquid—it is unlikely that you are concerned about the permittivity of the material to light. With this in mind, we use the concept of views to allow only the relevant aspects of function, behaviour, or structure to be considered.Footnote 1

Gero et al. also refer to this concept of views (although not by the same terminology), by acknowledging that different actors will be concerned with different aspects of the functions, behaviours, or structure of an object. In [15], they give the example of a mobile phone: the user is interested in the structure as given by the screen, the keys, the size, and so on, resulting in a behavioural analysis on the use of the phone; an electrical engineer may find the electronic circuits of the phone to be relevant structural factors, which can then be used to account for behaviours relating to the operating system, the ring tone, or the ability of the phone to connect to various different kinds of wireless networks.

3.2 Function

Following the consensus in the literature, we maintain the definition of function as a subjective abstraction of purpose [12, 16, 49]. We can consider an Evolvable Assembly System to have a number of simultaneous functions.

As a production system, the main function is to produce a set of products. There are performance requirements associated with that function, both in terms of KPIs and in terms of complying with relevant regulatory frameworks.

In an EAS, there are two additional requirements on the real production system designed to achieve that function. First, the system should be flexible and reconfigurable to accommodate the production of a large and changing set of products. Second, the system should be able to adapt itself in response to disruptions such as failure and unexpected environmental changes.

The function of assembling a product is expressed in terms of the product to be assembled: informally “to assemble a product with this set of features and properties”. Therefore, the function of an assembly system is related to the structure and behaviour of the products it is to assemble. However, the product designers should not be concerned with specifying the processes by which the assembly is carried out. As an example, the product designer would specify a hole should exist at a given location with a given accuracy (among other parameters), but would not be expected to specify the decision-making that occurs in the system in order to choose whether it is drilled, bored, or laser cut, or to ensure the selection of the correct drill bit, or the precision of the motion required to reach that point. These latter issues are related to the behaviour of the system; issues that the product designer should not be burdened with, and in many cases, may not be in a position to know.

In terms of requiring our systems to adapt to changes, this could occur at a high level, for example a change in product to be assembled, the failure or addition of a manufacturing capability, and so on. Alternatively, it could occur at a low level, for example compensating for the uncertainty, variability, deformation, or deflection of a part that is being worked on. This means that the adaptation requirements are defined in a multi-dimensional configuration space, according to the available and configurable variables in the system.

The remaining aspects of the system function encapsulate more traditional system performance indicators; for example, the system should achieve a certain throughput, not exceed a given power consumption, or must perform actions in a certain manner in order to comply with regulations.

With these three aspects in mind, we can define our concept of Function as follows:

Definition 1 (Function)

F = 〈FPr,FA,FQ〉 where FPr = f(RPr) : functions relating to product requirements RPr, FA = f(RA) : functions relating to adaptation requirements RA, and FQ = f(RQ) : functions relating to achieving and maintaining system performance and quality requirements RQ.

Further examining RPr allows us to express the requirements stemming from the product’s behaviour (\(R_{Pr_{B}}\)) and structure (\(R_{Pr_{S}}\)), such that \(R_{Pr} = \langle R_{Pr_{S}}, R_{Pr_{B}} \rangle \). The behaviour of the product PrB should be described using any relevant views. If a product’s flexibility is relevant to the production, for example in the case of large panels that may deflect during assembly, then this should be modelled in PrB. Likewise, if the product is to be machined from a given material, the parameters that determine the deflection response of the material workpiece should be modelled in PrB. Another example is when the product is (or contains) liquids or gases—the behaviours of these substances are highly relevant to the design of the system behaviours and structures that will be used to manipulate and store them.

The structure of the product PrS may be expressed in any format that describes the product features, for example a CAD model. In the case of a product family, there are likely to be two views: one that describes the fixed attributes that are common to all variants (usually some sort of physical description), and one that describes the variables (this can be thought of as the “product recipe”).

3.3 Behaviour

A key concept in behavioural approaches like FBS is the distinction between expected behaviour Be and the actual behaviour expressed by the system’s structure Bs. We maintain this distinction, but while previous work on FBS models was primarily concerned with fixed behaviour in a static system—which in our case would be a system resulting in a fixed assembly process—we are also concerned with adaptive behaviours. We therefore consider three types of behaviour in each case:Footnote 2

Definition 2 (Behaviour)

\(B_{x} = \langle B_{x_{NAP}}, B_{x_{AP}}, B_{x_{R}} \rangle \) where x ∈ {e,s}, Be is expected behaviour—i.e. target behaviour, Bs is structurally expressed behaviour—i.e. behaviour achieved in the real world, \(B_{x_{NAP}}\) is non-adaptive production behaviour, \(B_{x_{AP}}\) is adaptive production behaviour, and \(B_{x_{R}}\) is reconfiguration behaviour.

\(B_{x_{NAP}}\) :

Non-adaptive production behaviour: This is the type of behaviour considered in previous work on FBS models. It covers the “steady state” of production process in an assembly system and is often described as a simple sequence of actions.

\(B_{x_{AP}}\) :

Adaptive production behaviour: The first addition of adaptivity is to the production behaviour above. Our systems are self-adaptive, leading to an adaptive function. This in turn implies adaptive behaviour. Behaviour cannot then be simple action sequences, but must instead encapsulate predictive decision-making.

\(B_{x_{R}}\) :

Reconfiguration behaviour: Finally, we explicitly require our systems to self-configure and self-reconfigure. This requires our systems to be able to integrate the “design process” into their own behaviours—to be able to identify when a reconfiguration needs to occur and what that reconfiguration should address, and then “design the change” that would accomplish it.

In terms of implementation, the production behaviours required of the system for a given product are determined by the set of tasks required to assemble it. In our work, these behaviours are specified as labelled transition systems (LTSs) that describe the flow of activity in each behaviour. For a given product to be produced, these behaviours are compiled into a recipe file that formalises the product recipe and fully captures the decision-making that may have to occur during the adaptive production of that product. To continue the hole-making example, where the function specified that a hole should exist, the behaviour would specify that a hole should be (for example) drilled at a given location, with a given tool, with a given accuracy (among other parameters). These parameters must be defined in relation to the structure of the system, otherwise the behaviour cannot be performed.

With these definitions of function and behaviour, we can see an overlap between the different aspects of each as shown in Fig. 2.

Fig. 2
figure 2

The conceptual overlap between types of function (above) and types of behaviour (below) in an EAS

Full size image

As system behaviour is either derived from function or generated by structure, there are a number of different views that can be taken into consideration, including motion definition based on kinematics [22], high-level production actions given by a Business-to-Manufacturing Markup Language (B2MML) description [42], or a “digital twin” simulation model [33]. Our model allows the designer to use the most appropriate perspective. Later in the paper, we present an example using the views of physical production topology and production processes.

3.4 Structure

An Evolvable Assembly System is an example of a modular, flexible, reconfigurable manufacturing system, and also a complex, context-aware, collective adaptive system of systems [38]. With this in mind, we must modify the definition of structure from the literature. The structure should deliver behaviours that will fulfil the desired system functions, and is defined by the components, modules, or sub-systems that comprise it, the connections between them, and the states that the system may be in. However, we must also consider a number of additional things:

  • The system structure may change over time. System components may be added or removed, connections between components may change, and the system state will change. Although this last aspect of changeable state is not strictly new to the FBS literature—[49] notes that “structure” is informally just state that does not change very often—the changeability of the system components and connections is not explicitly addressed as a top-level object in existing frameworks.

  • The system may have a set of “configurations” that it may be in at any given time. These configurations will encapsulate a set of components and connections and will often also include specific system state. For example, in a flexible and reconfigurable manufacturing system, the connections between system modules may change depending on the product to be manufactured, and the associated control code (which is part of the system state) may change to reflect this. The structure is a set of possible configurations, and the system must select a single configuration to be used at any given moment.

For the non-adaptive production process, the definition of structure from the literature given above is still mostly suitable. At this level of behaviour, we are only interested in the static assembly of a single product with a stable system in a fixed configuration. However, the addition of adaptivity to the process requires us to consider the other aspects of the system: that it is an open dynamic system made up of loosely coupled distributed autonomous resources. We must therefore consider the potential addition or removal of resources, that the connections between resources may change, and that a resource may even change its structure. As the structure of a system includes the hardware and software configuration of the system, the variables that make up the settings are part of our concept of structure for the system.

In terms of our hole-making example, the structure of the system needs to specify some resources that can exhibit the behaviours that we require. Therefore, it will need to have a drill and bits that are suitable for the material our product is made of (taking into account the system behaviours implied by the product behaviours). Along with this, it will also need some method of manipulating either the drill or the product such that the holes can be made in the correct positions with sufficient accuracy. Perhaps some metrology system could also be necessary to ensure this positional accuracy, or perhaps the manipulator and drill combined will have sufficient accuracy on their own—this is something to be decided either during the design process itself, or during operation.

We can therefore define structure as follows:

Definition 3 (Structure)

S = {C0,…,Cn} where Ci = 〈M,Conn,State〉 is a configuration, M is the set of system modules, components, or sub-systems, Conn is the set of connections between elements in M, and State is the state of the system.

As with function and behaviour, structure can also be described using different views. For example, each mi ∈ M may be described with a physical description of the hardware (most appropriate for traditional machining equipment), or in terms of its software architecture (most appropriate for a cloud manufacturing or agent-based control system). Likewise, where the State of the system contains the “layout”, this could be described topologically (in terms of the connections Conn between modules), or geographically (in terms of the relative or absolute locations of modules). Similarly the State may be concerned with the settings, or “configuration state”, of a module, which for a software system may be the code being run or the values in a set of fixed variables, and in a hardware system may be various settings on the equipment.

3.5 Design process

The FBS framework of Gero et al. [14] describes both an ontological framework for Function, Behaviour, and Structure and a process for design using those concepts. We extend and adapt this process for the design of adaptive production systems. This is not only what Gero would call “creative design”—where all variables and their ranges can be modified, with no limits on the hardware that can be designed or included in the system—but also “innovative design” in terms of integration of existing hardware. In this case, the variables in RA limit the adaptation by fixing some of the variables in the process and allowing some to be modified.

We can now consider the fully modified design process shown in Fig. 3:

  1. 0.

    Requirements gathering takes the set of product requirements (RPr based on the product behaviour and structure \(Pr_{B} \rightarrow R_{Pr_{B}}, Pr_{S} \rightarrow R_{Pr_{S}}\)) and system adaptation and quality requirements (RA and RQ), and generates the system function (F) from them.

  2. 1.

    Formulation converts the required system function (F) into a set of behaviours (Be) that are expected to result in the required function.

  3. 2.

    Synthesis generates a structure (S) containing a set of configurations (C) that are expected to exhibit the desired behaviours (Be) and selects an initial configuration for the system.

  4. 3.

    Analysis is the process of observing or deriving the actual behaviour (Bs) exhibited by the currently chosen configuration of the structure (S).

  5. 4.

    Evaluation compares the two behaviours to determine whether the actual behaviour (Bs) matches the expected behaviour (Be). The result of this comparison determines whether or not the “design” will be accepted, or if a reformulation is required.

  6. 5.

    Documentation involves the production of a design description or document (D) that describes the design to be implemented. This would be carried out if the result of the evaluation process is favourable. In our process, the output of this stage is a description of the changes to be implemented, in terms of the structure and configuration of the system.

  7. 6–11

    Reformulation is the process by which changes can be made to the design if the result of the evaluation process is unfavourable. During reformulation, the process “loops back” to make a change to one of the properties of the design before the design process continues. Reformulation can take five forms:

    1. 6.

      Type 1S uses changes to the structure or set of configurations to address unsatisfactory behaviour.

    2. 7.

      Type 1C selects an existing configuration to address unsatisfactory behaviour.

    3. 8.

      Type 2 uses changes to the (expected) behaviour to address unsatisfactory behaviour.

    4. 9.

      Type 3Pr uses changes to the functional product requirements to address unsatisfactory behaviour or to respond to changes in product requirements.

    5. 10.

      Type 3A uses changes to the system adaptation requirements to address unsatisfactory behaviour or to respond to changes in adaptation requirements.

    6. 11.

      Type 3Q uses changes to the system quality requirements to address unsatisfactory behaviour or to respond to changes in quality requirements.

Fig. 3
figure 3

EAS operational design process (see Section 3.5 for labels)

Full size image

4 Implementation methodology

There are three main implementation challenges to address when considering our framework, as described in the following sections.

4.1 System functional requirements

The first challenge is formalising system functional requirements in a format that is machine-readable (stage 0 in the design process). The system requirements \(R_{Pr_{S}}\), \(R_{Pr_{B}}\), RA, and RQ are given as schemas defining a set of constants and variable attributes with associated ranges: R = 〈{constants}, {〈variable,range〉}〉. The schema in \(R_{Pr_{S}}\) represents physical forms of the set of products that may be produced by the system: their shared attributes (the constants) and the ways in which they vary (the variables), as well as how much they can vary (the ranges). \(R_{Pr_{B}}\) represents the relevant aspects of product behaviour that should be considered—for example the flow characteristics of a liquid, or the relevant parameters for determining workpiece deflection during machining. Where \(R_{Pr_{S}}\) and \(R_{Pr_{B}}\) express potential product variation, RA expresses allowable system variation in a similar manner. In the case of RQ, these attributes are actually quality constraints on the system; the constants are binary invariants and the variables express ranged constraints. All of these schemas can be directly translated into XML schemas for machine readability. When it comes to producing a given product at a given time, the system function can be reduced to a single-product recipe. This is implemented as a recipe file that specifies the parts and operations required by the final product, the quality inspection tests to be carried out, and the possible responses to each test (i.e. rework, discard, etc). This recipe file is generated through stages 0–1, thereby corresponding to the required production behaviours of the system \(B_{e_{NAP}}\) and \(B_{e_{AP}}\), and takes the form of a labelled transition system that is stored in data structures specified in ANSI/ISA-95 [1] using B2MML (e.g. [2]). The reconfiguration behaviours \(B_{e_{R}}\) are specified in the internal workings of the control system using a form of BDI architecture [11, 32].

4.2 System structure

The second challenge is formalising system structure in a format that is machine-readable. As described in Section 3, structure S is a set of configurations C where each Ci = 〈M,Conn,State〉: the production system is made up of a set of production resources (M: modules, components, or sub-systems) with state (State) connected together in some topology by their connections (Conn). Both the resources and topology are represented as labelled transition systems. Any previously existing resources are specified to the system by blueprint files, implemented using the same ANSI/ISA-95 and B2MML standards as the recipe files. Both the resources and topology can then be modified if necessary due to system adaptation.

4.3 Synthesis and evaluation of behaviour

The third challenge is around implementing methods for representing system behaviour during the design process. Stage 2 in the design process is the synthesis of a set of behaviours Be that are expected to fulfil the system requirements. This is accomplished by a process of task simulation and controller synthesis [41] resulting in an annotated labelled transition system (mapping the recipe to the topology) that is then unfolded into an AND-OR tree. This AND-OR tree is represented by a B2MML “Operations Schedule” made up of several “Operations Requests” that can be interpreted by the agent control layer for execution on industrial hardware. While this controller is executed, the system tracks all attributes mentioned in F (Stage 3 of the design process, Analysis). As part of Stage 4, Evaluation, the system checks these attributes do not violate any associated ranges or constraints. A further pre-emptive check via virtual task simulation is done to compare the predicted system behaviour to the required system behaviour before actual execution [4]. This helps prevent a “try it and see” approach to the synthesis and reformulation steps. Likewise, once a suitable configuration is found by simulation, it can be saved for later use without having to generate from scratch.

5 Prototype implementation

The proposed design process has been verified using industrial data. To illustrate the approach, we present one use case based on an implemented proof of concept demonstrator at the University of Nottingham shown in Fig. 4. In this case, the view we are considering is that of the physical production processes, taking into account the production capabilities and topology of the cell. The cell’s function is to inspect and assemble a variety of aerospace rib and skin components: this leads to requirements to handle the components, apply fasteners and sealant, and inspect the resulting products. Starting with some existing hardware, we use the presented approach in an “innovative design” manner to design the control approach and reconfigure the cell. The demonstrator consists of two ABB IRB6700 robots, a shared central workspace, a tool rack accessible by one robot, and both a shared tool/part rack and a part loading conveyor belt accessible by the other robot and by a human operator at a manual workstation. Each robot has access to a number of different end effectors on their respective rack and is equipped with an automatic tool changer.

Fig. 4
figure 4

Assembly cell layout

Full size image

The modules and connections of the structure can be seen diagrammatically in Figs. 4 and 5. Note that the end effector connections are ignored in Fig. 5 and will be presented in a simplified form here for clarity. This is because they can physically change location (in the rack or on the robot) and connection based on the reconfiguration behaviours. These different sets of connections, along with any drastic changes in state, result in the set of configurations C for the system.

Fig. 5
figure 5

Assembly cell connections

Full size image

This “first pass” over the system structure results in the set of processes (behaviours) shown in Table 1. Note that some behaviours are shared behaviours that require multiple modules to collaborate; for instance when robot 1 holds a part and robot 2 scans it or applies sealant. The structure and behaviour identified for each module is then used to generate an LTS for that module, as shown in Figs. 6 and 7 for example.

Table 1 Behaviours available to each module in the cell
Full size table
Fig. 6
figure 6

Example labelled transition system for the cell conveyor generated from module structure and behaviour. Solid lines are processes and dotted lines indicate interaction with other resources

Full size image
Fig. 7
figure 7

Simplified example labelled transition system for robot 1 generated from module structure and behaviour. Solid lines are processes, dashed lines are configuration changes, and dotted lines indicate interaction with other resources. For readability, some labels have been combined and some states and transitions have been elided

Full size image

The final cell structure is given by 〈M,Conn,State〉 for each configuration, where the set of modules M and the interconnections Conn are as follows:Footnote 3

$$ M = \left\{\begin{array}{l} \text{Conveyor}, \\ \text{Workstation}, \\ \text{Robot 1}, \\ \text{Robot 2}, \\ \text{Part rack}, \\ \text{Tool rack}, \\ \text{Workspace}, \\ \text{Pneumatic rivet gun}, \\ \text{Sealant gun}, \\ \text{Laser line scanner}, \\ \text{Pallet gripper},\\ \text{Rib gripper}, \\ \text{Skin gripper}, \\ \text{Parts} \end{array}\right\} $$
$$ Conn = \left\{\begin{array}{l} \left( \text{Workstation}, \text{Conveyor}\right), \\ \left( \text{Conveyor}, \text{Robot 1}\right), \\ \left( \text{Robot 1}, \text{Part rack}\right), \\ \left( \text{Robot 1}, \text{\textit{end effectors}}\right), \\ \left( \text{Part rack}, \text{\textit{end effectors}}\right), \\ \left( \text{Robot 1}, \text{Workspace}\right), \\ \left( \text{Robot 2}, \text{Workspace}\right), \\ \left( \text{Robot 2}, \text{Tool rack}\right), \\ \left( \text{Robot 2}, \text{\textit{end effectors}}\right), \\ \left( \text{Tool rack}, \text{\textit{end effectors}}\right) \end{array}\right\} $$

The State of the cell contains the program code and associated variables for each module, for example program pointers, functional attributes, and generated data such as inspection results. This state will be distributed throughout the resource controllers, the Programmable Logic Controllers (PLCs), and the agent control system.

We will now sketch an example of how the design process is used to accommodate new products. To start, the system will be in a given configuration Ci to perform a sealant application on a rib. In this case, Ci will encompass the sealant gun, rib gripper, and pallet gripper (to place the rib on the pallet in the part rack to cure) in mi but has no requirement for the skin gripper. This allows the system to continue functioning if the skin gripper needs to be reassigned to another cell if necessary, or removed for maintenance tasks. If the system then receives a new requirement in RPr to operate on skins, then type 3Pr reformulation will trigger and the system will switch to the existing configuration, say Cj, that encompasses the skin gripper in mj. As the set of behaviours already includes a skin gripper, no change in B should be required. In the case of a new skin geometry, this would entail behavioural analysis and evaluation to check that the existing gripper was capable of picking the skin. If a completely novel product is added to RPr, for example a spar, then the synthesis stage of the process will fail to generate a suitable structure and attempt to source a spar gripper by triggering type 1S reformulation. In our real instantiation, this would notify an operator of the need for a spar gripper, and reject the operations request.

6 Conclusions

6.1 Discussion

The reported research addresses the need for behavioural approaches to the design and modelling of flexible and reconfigurable production systems of the sort studied in the Evolvable Assembly Systems project. A novel design process and associated definitions have been proposed for such systems, taking into account how system structure and behaviour relate to the intended system functions. The process has been developed in such a way as to enable automatic implementation by an agent control system. This has been demonstrated through a real example instantiation in the aerospace assembly domain.

The main advantages of the approach are that it enables a wide range of dynamic requirements, takes advantage of the inherent self-x properties of the system components, and can be applied to automated agent-based control systems. In order to aid robustness and applicability, the approach has a formal foundation in both design theory (functional modelling) and automated reasoning (labelled transition systems and task simulation), combined with a standards-compliant approach to implementation (using ANSI/ISA-95 data structures in B2MML).

6.2 Contribution and further work

The paper presents a novel extension of the Function- Behaviour-Structure (FBS) frameworks of Gero, Rosenman, Umeda, and others from the field of functional modelling. The presented approach extends the theoretical FBS frameworks not only to fully accommodate self-adaptive systems but also to accommodate production systems whose function is determined by the FBS of other artefacts (i.e. the products to be produced). This novel theory is supported by practical application on real industrial hardware through a standards-compliant implementation to demonstrate automatic design, integration, and reconfiguration in response to changing product requirements.

As discussed in this paper, new approaches based on functional and behavioural models are particularly suited to addressing the challenges of disruptive production environments resulting from Industry 4.0 and similar trends. Consequently, the contributions described here are highly relevant to the manufacturing industry. High-value manufacturing, such as in the aerospace domain, is of particular relevance. The ability of the system to reconfigure according to changing requirements allows for an increase in utilisation, and a reduction in cost and change over time resulting in increased productivity. The example instantiation is in a research demonstrator designed to be a “relevant environment” [5] representative of a real industrial environment, and work is ongoing to further develop and apply the approaches described here to industrial demonstrations at higher Technology Readiness Levels [5, 39].

Our future theoretical research focus will be on more complex integration of hybrid human-machine decision-making through a joint cognitive systems approach [18]. This should provide for easier integration of automated and manual operations in a production environment. A potentially interesting avenue of review is the automatic generation of certain aspects of the control or test code for the system, followed by the comprehensibility by a designer, tester, or operator of the system; previous work in the area has highlighted a number of challenges [19, 45].