Introduction
Manufacturing is transitioning from a mass production model to a service model in which manufacturing facilities ‘bid’ to produce products. In contrast to mass production, where large volumes of known products are produced at a time, in manufacturing as a service, the products to be manufactured are not known in advance, batch sizes are often small, and a facility may produce products for several customers at the same time [Technology Strategy Board2012, Rhodes2015]. This trend towards rapid provisioning of manufacturing resources, e.g., CNC machines and robots, with minimal management effort or service provider interaction has been termed ‘cloud manufacturing’ [Xu2012, Lu, Xu, and Xu2014].
To determine if a novel product can be manufactured, abstract manufacturing tasks in the process recipe specifying how a product is manufactured must be matched against the available manufacturing resources so as to produce a process plan detailing the lowlevel tasks to be executed and their order, the manufacturing resources to be used, and how materials and parts move between resources [Groover2007]. Control software—called process plan controller—that delegates each operation in the plan to the appropriate manufacturing resources is then synthesized. In mass production, process planning is carried out by manufacturing engineers and is largely a manual process. However this is uneconomic for the small batch sizes typical of the manufacturing as a service model, and the time required to produce a plan is too great to allow facilities to bid for products in real time. To fully realize the manufacturing as a service vision, manufacturing facilities must be able to automatically synthesize process plan controllers for novel products ‘on the fly’.
There has recently been efforts to apply AI behavior composition [De Giacomo, Patrizi, and Sardiña2013] to the synthesis of process plan controllers, e.g., [de Silva et al.2016, Felli, Logan, and Sardina2016, Felli et al.2017, De Giacomo et al.2018]. However, this work suffers from two important limitations. First, the approaches are restricted to finite state representations. While adequate for some manufacturing tasks and resources, the resulting discretization is unwieldy and less natural, for example, when representing and reasoning about the potentially infinite number of basic parts, each with a unique bar code or RFID tag. Secondly, existing approaches to modeling abstract manufacturing tasks and the interactions between resources result in somewhat adhoc and inflexible formalisms. For example, the state (and its dynamics) of a given part (e.g., painted, defective, etc.) or of a shared resource (e.g., a conveyor belt) ought to be encoded into operational representations, such as transition systems or automata. Clearly, more declarative representations would be desirable.
In this paper, we address both issues by adopting the Situation Calculus [Reiter2001], a knowledge representation formalism to reason about action and change. We represent process recipes and available resources as highlevel ConGolog programs executing over, respectively, an abstract and a concrete action theory. This yields a principled, formal, and declarative representation of the manufacturing setting. We then define, by means of a suitable simulation relation, what it means to realize the a product process recipe on the available resources. Finally, by leveraging recent work on abstraction, we show how to effectively check the existence of a process plan controller (and how to compute it) for the case of bounded action theories.
Situation Calculus
The situation calculus [McCarthy and Hayes1969, Reiter2001] is a logical language for representing and reasoning about dynamically changing worlds in which all changes are the result of actions. We assume to have a finite number of action types, each of which takes a tuple of objects as arguments. For example, represents the (simple) action of drilling a hole of a certain diameter at a certain speed in a given part. In the manufacturing domain we are concerned with operations that may occur simultaneously. We therefore adopt the concurrent nontemporal variant of the situation calculus [Reiter2001, Chapter 7], where a concurrent or compound action is a, possibly infinite, set of of simple actions that execute simultaneously. For example, represents the joint execution of rotating a part at a given speed while spraying it. Situations denote possible sequences of concurrent actions: the constant denotes the initial situation, on which we assume to have complete information, and the situation resulting from executing a concurrent action in a situation is represented as situation term . Predicates whose value varies from situation to situation are called fluents, and they take arguments of sort object plus a situation term as their last argument. For example, may denote that a part is painted in situation .
A basic action theory (BAT) [Pirri and Reiter1999, Reiter2001] is a collection of axioms describing the preconditions and effects (and noneffects) of actions on fluents. A special predicate is used to state that the simple action is executable in situation , and, for each simple action type, a precondition axiom is given to specify when the action can be legally performed. Such a predicate is extended to compound actions , typically by requiring that each atomic action in is possible, i.e., , although one can further restrict Poss when needed. We also assume that . A successor state axiom is used to specify how each fluent changes as the result of executing (simple or) concurrent actions in the domain. Successor state axioms thus encode the causal laws of the domain being modelled, by encoding the effects of actions. Figures 1 and 2 list examples of precondition and successor state axioms for a manufacturing setting.
A Variant of ConGolog for Manufacturing
Highlevel programs are used to specify complex processes in the domain. We specify programs in (recursionfree) ConGolog [De Giacomo, Lespérance, and Levesque2000]:
compound action
test for a condition
sequence
nondeterministic branch
nondeterministic choice of argument
nondeterministic iteration
conditional
while loop
interleaved concurrency
where is a compound action (instead of atomic action as in the original paper) and is situationsuppressed formula, i.e., a formula in the language with all situation arguments in fluents suppressed. We denote by the situation calculus formula obtained from by restoring the situation argument into all fluents in . We require that the variable in programs of the form range over objects, and occurs in some action term in , i.e., acts as a construct for the nondeterministic choice of action parameters.
The semantics of ConGolog is specified in terms of singlesteps, using the following two predicates [De Giacomo, Lespérance, and Levesque2000]:

: program may terminate in situation ; and

: one step of program in situation may lead to situation with remaining to be executed.
The definitions of Trans and Final for the standard ConGolog constructs are given by:
Note that the conditional and whileloop constructs are definable: and .
In the manufacturing setting, highlevel programs are used to model the logic of manufacturing resources in “isolation”, and synchronized concurrency is needed to represent the operation of two (or more) resources “simultaneously”. For this reason, we introduce a new construct in ConGolog, called synchronized concurrency:
synchronized concurrency
that represents the synchronized concurrent execution of programs and : their next corresponding actions take place in the same next transition step. Its semantics is defined as follows:
where is equivalent to Trans except for the condition which is now , and for that is as above but without check of Poss.
The characterization of Final for synchronized concurrency is analogous to that of interleaved concurrency:
Note the underlying assumption here is that a number of subsystems, manufacturing resources in our setting, can legally perform a joint step if such joint step is deemed possible by the BAT.
Modelling Manufacturing as a Service
In this section we show how the manufacturing as a service setting can be captured by representing both process recipes and manufacturing systems as ConGolog programs.
Resource Programs
We consider a manufacturing system, or simply system, composed of of distinct manufacturing resources, each identified by an index . Each resource is associated to a BAT specifying the fluents, the actions that may be performed, their preconditions and effects. For convenience we assume that actions have the resource index (a constant) as their last argument.
Example.
Consider a manufacturing cell that performs operations on parts (the example is based on the cell described in [Felli et al.2018]). Parts have an ID, and parameters such as size, weight, material, etc. The cell consists of five resources. is a robot that can perform different operations on parts within its operating envelope, by (autonomously) equipping with the appropriate end effector using the action . By equipping a driller it can drill parts; by equipping a rivet gun it can apply rivets, etc. The drilling operation is modeled as the action with arguments for the part ID, the drilling bit ID, the diameter, the spindle speed, the feed rate, and hole position. Fully specified actions are of the form , with 1 as last argument. Similarly for .
We model the other resources in a similar way. is a fixture that can perform an action , with arguments for the part ID and the clamping force. Resource is another robot that can move parts into and out of the cell from an external conveyor, position a part at a given location relative to another part, and, by equipping a flat or hollow end effector, apply pressure to a part that is being worked on by another resource (hollow for drilling or milling, flat for riveting). These operations correspond to the actions , , , , . Note that information about the weight, material and size of parts loaded into the cell is made available by passing this via arguments to . Resource is a upright drilling machine for drilling parts with high precision. Finally, is a human operator, who operates and who can also bring small parts into and out of the cell, and apply glue to parts with . Parts are moved between resources by a parthandling system. For simplicity, we model this using additional actions and for each resource, denoting that a part is moved into or out of the work area of the resource, respectively. We also have a special action that specifies when a resource may remain idle.
To denote that a part is currently in the work area of a resource , that a hole has been drilled in a part by a resource, or that a part has a certain material, etc. we use situation dependent or independent fluents of the form , , , etc. In Figure 1 we list some examples of precondition axioms for theories .
Given the BAT of a resource (which include the possible actions) we can describe all possible sequences of operations that the resource can execute (in isolation) as a ConGolog program with BAT .
The Available Program
The set of BATs is then compiled into a single BAT , for the entire system, in a semiautomated fashion, e.g., by taking into account knowledge about which resources are connected by the parthandling system, which resources can work on the same parts, etc. To be able to represent dynamic worlds that allow the concurrent execution of multiple actions, we consider compound action terms of the form with , where each is a basic action term. As shorthand, we denote by the compound action
with a vector
of arguments (of the right size, and assuming a standard ordering of basic actions). Moreover, to ensure that the resources involved can work on the same parts, we use a special situationindependent predicate specifying that resource can cooperate with resource .Example.
The situation , results from the concurrent execution of two actions: drilling a part with ID f that is held by the fixture . Also, Figure 2 shows a fragment of the resulting BAT for the overall system.
Similarly to the case of a single resource, assuming a set of BATs for each of the available resources, and the resulting BAT for the entire system, we can capture all the possible executions of the system as a ConGolog program.
Definition (Available Program).
Given a set of resource programs , , the resulting available program is the ConGolog program is
Target Program
The product recipe specifying the possible way(s) in which a product can be manufactured is a ConGolog program which we call the target program. has its own BAT , which is distinct from (for any system ). In the manufacturing as a service model, product recipes are resource independent [ANSI/ISA2010], i.e., specified using action terms and fluents understood throughout the manufacturing cloud rather than in the theory of any particular facility.
Example.
An example target program specified using the resource independent BAT is shown in Figure 3. Two parts denoted by b and f are loaded into the cell, then glue is applied to b and it is placed on f, resulting in a composite part denoted by fb. The loading of b and the drilling of f can occur in any order, but glue must be applied to f before b is placed. If the resource used for drilling is not highprecision, a reaming operation is performed. Finally a rivet is applied and fb is stored.
To establish the manufacturability of a product by a given system, we must establish mappings between the resourceindependent BAT and the BAT
of the system. In practice, these mappings are computed for each manufacturing system, automatically or by hand, at the moment of joining the manufacturing cloud
[Felli et al.2018]. Inspired by [Banihashemi, De Giacomo, and Lespérance2017]:
each in is mapped to a (possibly complex) program in , e.g., passing of parts through the parthandling system, equipping effectors etc.;

some fluents correspond to formulas over the fluents in , i.e., to establish the value of f one needs to observe the situation of the underlying theory of . Hence we say that these fluents model “observations”, and use of a special unary predicate Obs to distinguish them.
This gives a set of mapping rules of the form:
For example, a rule that maps the resourceindependent drill action in Figure 3 to a program specifying the possible ways in which a drilling operation can be executed in a specific system might be:
Crucially, a number of preliminary actions are required for these loading actions to be executable (e.g. equipping the right end effectors, clearing the working space, etc.) but these are not explicitly listed, as it is one of the objectives of the composition. Each stands for : each resource can perform any of their actions. We can write similar mapping rules for fluents, e.g., specifying how the precision of a drilled holes is observed.
In modelling a manufacturing domain, it is often natural to consider that the target and available programs are bounded [De Giacomo et al.2016]. In practice, this means that the information of interest in each moment, corresponding to the parts that are being manufactured, the possible operations executed, their possible parameters and the data produced, are not arbitrarily large but are bounded by a known bound. E.g., resources have bounded capacity, a product recipe consists of finitely many parts and requires finitely many operations. This assumption will be used to give a decidable technique to synthesize controllers.
Orchestration via Simulation
To define the conditions under which a target program can be realised by executing the available program , we relate their execution. Extending the definition in [Sardiña and De Giacomo2009] to our setting, we define the notion of simulation between programs:
where iff and Final is substituted with FinalObs, defined as:
if with  
otherwise. 
Intuitively, we use the situation for theory for testing the situation suppressed fluents in the theory which correspond to observations of the underlying situations . Moreover, is used to establish that there exists a complete execution of the program from to .
The relation above specifies the following property: for every possible step from situation , in which the target program evolves from to by executing , there exists an execution of the concurrent program in situation , from to (and through a complete execution ), for which the same property holds. Also, whenever the target program can terminate, also the available program can. Through FinalObs, we allow the target program to assess the values of fluents on the situation : the process recipes can specify conditions to be checked by observing the system. E.g., the value of in the program in Figure 3 must be observed after the drilling operation.
Moreover, note that we could not simply replace each action in the target program by its corresponding program and then apply known approaches such as that of [Sardiña and De Giacomo2009]: to satisfy the simulation requirement it is enough to find at least one way in which can be executed so that the simulation property is maintained, whereas a syntactical substitution we would require that all such evolutions must be possible in the system.
Essentially, the simulation captures the fact that can implement the execution of , subject to the mapping rules.
Definition (Realizability).
The target program is realizable by the available program if .
When is realized by then, at every step, given a possible ground action selected by , one can select the corresponding program , execute it, and then return the control to the target program for the next action selection. Notice, however, that the execution of is not deterministic, as ConGolog programs include in general choices of arguments and nondeterministic branching. Nonetheless, the existence of the simulation guarantees that this is possible, but it does not detail how. Similarly to [Sardiña and De Giacomo2009], we assume to have total control on the interpreter executing the available concurrent program , whose nondeterminism is ‘angelic’, and define here the notion of controller: the unit responsible for orchestrating the system, hence the available resources, at each step. Intuitively, this requires to consider any possible execution of and , as commented above, which are infinite.
First, in order to isolate the source of such infiniteness into the program data only, for each program (target and available) we separate the assignments of pick variables to objects in the domain from the control flow of the programs, namely their program counter. This is the approach of [De Giacomo et al.2016], which we adapt here to our framework. Hence, we equivalently represent a program as the couple , where merely denotes its current program counter, and is a tuple of object terms so that each is the current value of th pick variable of . We call the (current) environment. Importantly, this is merely a syntactic manipulation: as showed in [De Giacomo et al.2016], we can reconstruct the original program by replacing the free pick variables of by those object terms to which variables are assigned. This is denoted by writing . Nonetheless, assuming programs without recursion, this simple technique allows one to obtain a finite set of possible program counters for a given program, which we define next (the possible environments remain infinite).
Definition (Syntactic closure of a program).
Given a program , it is the set inductively defined as follows: ; if and then and ; if then ; if then ; if then ; if and and then ; if and and then .
Denoting the finite set of all possible environments of a program as , so that is the number of its pick variables, we call a triple a (complete) configuration of . Denoting the set of possible configurations as , we can finally define our notion of controller which, intuitively, given the current configurations and for the target and system programs, and a new configuration for the target, selects a sequence of configurations for the system so that the simulation relation is recovered.
Definition (Controller).
Given a target program realizable by an available program , a controller for that realizes is a function s.t.:

is defined whenever and there exist s.t. ;

if returns the sequence then:

for , , with , and , namely the sequence is executable in the available system; and

, i.e., the simulation between the resulting programs is preserved. Note that, by the definition of simulation, this implies that the sequence of system configurations returned by the controller correspond to a complete execution of .

Controller Synthesis
To check whether a simulation exists and, if so, build a controller, we resort to model checking for a variant of the (modal) calculus in [Calvanese et al.2018], interpreted over game arenas (GA), i.e., special (labelled) transitions systems (TS) capturing turnbased game rules. We show that when such systems are statebounded, computing winning strategies becomes decidable.
Model checking over game arenas
For a set of fluents and an object domain , we denote by the set of all (standard) FO interpretations over of the fluents in .
Definition (Game arena).
Let be a set of fluents including the special ary fluents (i.e., propositions) and , and an object domain. A game arena over and is a tuple , where:

is the object domain;

is the set of GA states;

is the GA initial state;

is the GA transition relation;

is a labeling function, associating to each state an interpretation , s.t. exactly one among and is true.
represents the moves available to two players, Target and System, in a game, but not the game’s goal. The arena is turnbased: Target and System can move in states where, respectively, and hold. Turns are not strictly alternating. Wlog, we assume that in it is Target’s turn.
Goals are expressed through calculus formulas. The language we use, called ( indicates that we use only closed FO formulas), is:
were is a FO sentence with predicates from and constants from (under uniquename assumption, we can safely use objects from as constants); the modal operator denotes the existence of a transition from the current state to a state where holds; we use the abbreviation for ; is a secondorder (SO) predicate variable over sets of states, and and denote the least and greatest fixpoints, respectively, with seen as a predicate transformer with respect to . By the language semantics below, one can see that the only interesting formulas are those that are closed wrt to SO (in addition to FO) variables. In fact, SO variables are needed only for technical reasons, to make the fixpoint constructs available.
Given a GA , the semantics of a formula over is inductively defined as follows, where is an assignment to SO variables:
A state is said to satisfy a formula (under a SO assignment ), if . We say that satisfies if . Observe that when is closed wrt SO variables, as are formulas of practical interest, becomes irrelevant. When not needed, we omit from , thus using .
model checking is the problem of checking whether a GA satisfies a formula . When the GA is finite, this can be solved by direct application of the semantics. Thus one can compute the set , called the winning set, of states of that satisfy the formula . On the other hand, the problem can be shown to be undecidable in the general case (by reduction from the halting problem). In [Calvanese et al.2018], decidability is proven under sufficient conditions, including genericity and stateboundedness. We recall these notions and relevant results.
Given two FO interpretations and over a set of fluents and an object domain , write if
Comments
There are no comments yet.