Knowledge-based adaptive agents for manufacturing domains

Abstract

Modern production systems are increasingly using artificial agents (e.g., robots) of different kinds. Ideally, these agents should be able to recognize the state of the world, to act optimizing their work toward the achievement of a set of goals, to change the plan of action when problems arise, and to collaborate with other artificial and human agents. The development of such an ideal agent presents several challenges. We concentrate on two of them: the construction of a single and coherent knowledge base which includes different types of knowledge with which to understand and reason on the state of the world in a human-like way; and the isolation of types of contexts that the agent can exploit to make sense of the actual situation from a perspective and to interact accordingly with humans. We show how to build such a knowledge base (KB) and how it can be updated as time passes. The KB we propose is based on a foundational ontology, is cognitively inspired, and includes a notion of context to discriminate information. The KB has been partially implemented to test the use and suitability of the knowledge representation for the agent’s control model via a temporal planning and execution system. Some experimental results showing the feasibility of our approach are reported.

1 Introduction

The research community in Robotics and Artificial Intelligence has been building sophisticated robots for decades applying many available technologies. Still a limited understanding exist on what are the essential features of a generic artificial robotic agent. Furthermore, today robots are successfully applied in a large spectrum of applications (i.e., from simple washing machines to swarm robots and even humanoids), but it is still unclear how to best integrate different parts and modules into a single entity that can smoothly operate in an environment, understanding the actual situations and acting to achieve some given goals. These problems also hold in the more restricted area of industrial robots, which are built to enhance the productivity at the shop floor, and which operate in controlled, or at least constrained, environments.

In the manufacturing context, an open problem for researchers is the construction of systems that can quickly adapt (and possibly anticipate) changes in the production requirements [1]. Moreover, the concept of Industry 4.0 [2] is pushing manufacturing systems to evolve toward customer-oriented and personalized production, while trying to guarantee the advantages of mass production systems in terms of both productivity and costs [3]. Such systems are being conceptualized counting on the employment of highly flexible and reconfigurable machines [4]. Traditional approaches rely on centralized hierarchical control structures, not easily adaptable to different production settings without strongly affecting the productivity of the shop-floor. Indeed, they usually require major overhauls of their control code each time that any sort of system adaptation and/or reconfiguration is required. This is especially true in dynamic working environments such as Reconfigurable Manufacturing Systems (RMSs) [5] where the actual capabilities of an agent and even the production processes of the factory may change very quickly. Different configurations of the shop-floor (e.g., increasing the number of available working machines) or the introduction of new production capabilities (e.g., considering new type of work-pieces or tool) may affect the type of tasks agents carry out as well as the related production procedures. Artificial intelligence (AI) techniques such as, e.g., plan-based control, usually rely on a once-defined, static model of the world which could become obsolete very soon in dynamic contexts. The model requires a great design effort to capture all the possible configurations and it needs a continuous maintenance which may negatively affect productivity of the plant.

The research goal of this work is to enhance the flexibility of “classical” plan-based control architectures by integrating knowledge representation and reasoning mechanisms into the control loop (i.e., the closed-loop control of high-level activities, goals and states). The pursued approach is that semantic technologies can provide the representation and reasoning functionalities that robotic agents need to dynamically recognize particular production settings and adapt control models accordingly. The paper considers a concrete case study to provide an example of how knowledge representation techniques can significantly improve flexibility and adaptability of AI plan-based architectures by dynamically regenerating the control model according to the specific state of the working environment.

More specifically, this paper presents parts of a new cognitive architecture, suitable for artificial agents such as, e.g., robots, which leverages an ontological approach for knowledge classification and management to smooth the information flow from the knowledge about the environment and robot’s goals (desired states) to the planning and execution module. More precisely, the proposed contribution relates to (1) the structure of a knowledge base (KB) of the robot, (2) a knowledge manager that stores the model of the world and infer new information to recognize operational situations, and how the KB can be exploited to gather the information needed by the agent’s control module where planning and execution take place. Admittedly, this approach takes care of just one of the local properties, the KB module, and one of the global properties, the connection between the KB and the control module. Yet, this connection is today critical: it involves the manipulation of symbolic information at different levels of generality and its translation into state variables for controlling each component of the robot and, consequently, its interaction with the environment.

Structure of the paper: Sect. 2 presents the state of the art on the use of ontologies in robotics. Section 3 presents the structure of the considered KB. Section 4 introduces the DOLCE ontology and then presents specific extensions to cover engineering high-level notions. In the same section, a contextual classification of information is presented. Section 5 describes how the KB is exploited for extracting the information needed by the control module. The general plan-based control loop is presented in Sect. 6 and some tests for the validation of the approach are presented and discussed in Sect. 7. Section 8 concludes the paper.

2 The state of the art

In robotics and more generally in manufacturing, ontologies have been recognized as true enablers of adaptable and flexible systems compared to classic approaches [6, 7] and, consequently, have been exploited in the attempt to design more autonomous, flexible, adaptive, and proactive artificial agents. Since researchers have applied ontologies to solve or at least mitigate a variety of problems, applications differ in their assumptions and goals.

In [8], a robot knowledge framework (OMRKF) is exploited. OMRKF includes a series of articulated ontologies layers, including a robot-centered and a human-centered ontology. Beside a perception layer, enabling sensory data, the system includes an object layer (model), a context layer and an activity layer. The lack of the foundational approach can be seen in the object classification, e.g., “living room” is classified as a space region and not as the role of the region (the problem becomes clear by observing that a region of space is fixed while the living room can be located in different parts of the building at different times, and can even disappear from the building), as well as in the lack of activity vs. functionality distinction, e.g., “avoid obstacle” is not a behavior but a function which can be implemented by different behaviors such as, e.g., moving away or turning around.

Relatively to the connection between the KB and the planning module, Hartanto and Hertzberg [9] exploits a model filtering approach based on a Hierarchical Task Network (HTN). The agent’s knowledge of the environment is stored in a fixed ontology and some filters on this knowledge are set up. Given a planning task, the system selects one of the filters to isolate a suitable subset of the system’s knowledge and uses this subset to constrain the plan by deleting non-reachable constants. While this technique can be efficient in terms of plan adaptation, the knowledge is only filtered, thus cannot be augmented nor modified, not even contextualized to the problem showing a lack in flexibility. It is important to generate planning models tailored to the actual status of the agent and its environment: changes on these can easily make the starting plan obsolete as it happens, for instance, when the capabilities of the agent are affected by a sudden lack of resources or a (perhaps partial) failure of a component.

Behnke et al. [10] also treats tasks within the HTN approach and uses an ontology for the domain knowledge which encodes task information. The goal is to combine procedural knowledge and ontological knowledge. The planning knowledge is modeled by adding task concepts to the ontology and also predefined decomposition methods that are applied to decompose task concepts into executable tasks. New methods can be inferred by reasoning on combinations of executable tasks. The paper focuses on the correspondence between subsumptions among task concepts in the ontology and corresponding decompositions in the planning domain. The starting ontology is assumed to be given and is clearly limited by the expressivity of the chosen language (Description Logic). This makes reasoning feasible at the cost of information quality: even basic ordering information among the tasks must be stored outside the ontology. Other research projects, such as KnowRob [11] and ORO [12] focus on learning and symbol grounding and use ontologies for obtaining an action-based knowledge representation able to support cognitive functionalities. At the ontological level, these knowledge systems show problems similar to those discussed earlier (e.g., functionality is confused with activity so that it is not possible to “discover” new ways of performing functions). A further issue is the lack of stability in the ontology since some parts are developed on demand or depend on the interaction with other agents, that is, the ontology itself is data dependent. This approach can potentially introduce consistency problems that, unfortunately, are hard to detect in a dynamic knowledge base.

Ontologies have been applied to increase flexibility in modeling and planning of, e.g., mechatronic devices [13], resources in collaborative environments and the whole enterprise [14], collaborative robots [15] and navigation robots [16]. Balakirsky [13] uses a fixed ontology to collects static and dynamic information relative to a robot. The basic actions of the robot are hard-coded but the ontological system, which includes a PDDL ontology where knowledge about actions is stored, adds some flexibility such as the possibility to learn articulated actions and to act with partial information, e.g., information about the location of the object to move. In this application, beside the lack of functionality/activity distinction, the robot has very limited knowledge of the environment. Solano et al. [14] describes an ontological model aimed to represent the resource capabilities for the development of products and processes. The model is part of a larger ontology for collaborative and integrated development of products, processes and resources.

This approach is based on the foundational ontology DOLCE, which we introduce in the next section, and takes a general perspective. While this work goes in the right direction, it is not aimed to furnish a knowledge system targeting single artificial agents; the goal is to be able to integrate all the relevant perspectives in the enterprise including the modeling of both engineering and management activities. The approach does not include contextual knowledge. Hristoskova et al. [15] focuses on the scenario of robot guides offering a tour of a building, and develop a system for heterogeneous robot collaboration (e.g., receptionists and companions). The idea is to use ontologies for contextual information: there is an ontology for the user, one for the robot and one for the topic. For instance, the user ontology contains the user’s profile, topics of interests, and prior knowledge. This information is updated during the tour. Since the work concentrates on the collaborative interaction among robots, there is no particular effort toward flexible knowledge modeling. The ontologies are fixed: the topics are preselected and so is the content associated to the levels of detail or the user profiles. In [16], a robotic platform based on contextual knowledge design has been proposed to enhance performance for behavior specialization, perception, navigation, exploration, localization, and mapping tasks. The idea is to use contexts as classes of problem solving situations and to use behavior knowledge to select a suitable plan.

The underlying view is to see high-level information as environment contextual knowledge. Similarly, goal information and agent’s information are distinguished as mission and introspective contexts, respectively. This approach lacks the framework of an ontology and indeed the environment contexts are either left to the designer or built on top of the sensors’ data that the robot itself generates. An ontological approach would help to structure the classification of entities (after all a physical object may be a landmark in a certain context but does not ceases to be a physical object because of this) and to clarify how and when different contexts overlap.

Finally, an ontology-based reconfiguration agent is presented in [17] where an ontology is used to formalize knowledge of the manufacturing environment. The proposal is close to the view we present below but has important differences. First, it uses an ontology developed ad hoc for the given scenario. Second, it does not introduce contexts. Third, it is unclear how it can deal with device’s failures. We improve on the system by adopting a foundational ontology with which it is possible to reason at the functional level and to integrate the system with contextual information.

3 Flexible control architecture

Despite the variety of uses of ontology in robotic applications, the on-line management of information needed for dynamic planning remains an open issue. This is the main considered challenge to deal with to develop adaptive autonomous robots. We propose a radical approach relying on two elements: (1) a foundational ontology to organize the information, and (2) a knowledge-based control loop for updating the data and managing the flow of information to the planning system. The aim is to realize a system that can be actually deployed. Indeed, we consider an industrial case study as a first validation scenario [18].

3.1 A case study

A real pilot plant is considered for validation consisting of a reconfigurable manufacturing system (RMS) for recycling printed circuit boards (PCB). The plant is composed of different automatic and manual machines devoted to perform loading/unloading, testing, repairing and shredding of PCBs and a reconfigurable transportation system connecting them. The transportation system is composed by 15 reconfigurable mechatronic components, called transportation modules (TM). Figure 1 shows an example of the TM used in the pilot plant. The figure shows also the schema of a TM together with the supported transfer service. The set of supported services depends on the configuration of a TM.

Fig. 1

An example of a Transportation Module and the schema of a possible configuration

In general, all the TMs composing the reconfigurable transportation system of the case study can support two main (straight) transfer services. They are the Front transfer service and the Back transfer service, respectively, tagged with F and B in Fig. 1. Then, each TM can support a number of cross-transfer services that range from a minimum of zero to a maximum of three. A cross-transfer service enables Left (LCx) and Right (RCx) transfers between adjacent TMs. The schema in Fig. 1 shows the configuration of a TM equipped with two cross-transfer services that allow, respectively, LC1/RC1 and LC2/RC2 transportation directions.

The destination of a pallet carrying a PCB is computed at runtime, while the production process is carried out (e.g., also depending on the results at the testing station, the repairing station or the loading/unloading cell). Thus, the final destination of a pallet is available only at execution time requiring the transportation system to keep adapting to the newly generated destination. The TMs of the transportation system cooperate to define and optimize the paths the pallets have to follow to reach their destinations [18, 19] overcoming problems due to failures and unresponsive agents.

3.2 Putting knowledge and control in a loop

The foundational ontology, needed to ensure the coverage of the domain and a coherent global management of knowledge, and the context framework for factual knowledge that will be introduced in Sect. 4, form the structure of the knowledge management of the artificial agent. We now need to show how to make an operational use of the knowledge management, that is, we need to articulate the relationship between knowing the world and acting on the world. In particular, we are interested in using the agent knowledge for autonomous behavior to enhance the capability of an artificial agent. To this purpose, we integrate distinct cognitive functions as shown in Fig. 2. The figure shows the overall cognitive architecture resulting from the integration of a Knowledge Manager (top left), which contains the built-in know-how of the agent on its structure and the environment, and a Deliberative Controller, which constitutes a “classical” a plan-based control architecture like those described, e.g., in [20].

Fig. 2

The proposed integration between knowledge management and deliberative control in an agent architecture

Plan-based control architectures realize closed-loop controllers that allow an artificial agent to autonomously take decisions and execute actions needed to achieve some objectives. Such architectures are usually organized in three layers: (1) a deliberative layer which provides the agent with the capability of synthesizing the actions needed to achieve a goal (i.e., the Planning Framework in Fig. 2); (2) an executive layer which executes actions of a plan and continuously monitor their actual outcome with respect to the expected status of the system and the environment (i.e., the Monitor and the Executor in Fig. 2); and (3) the mechatronic system (and its functional processes) which represents the system and the environment to be controlled (i.e., the Mechatronic Module in Fig. 2 and the related transportation system).

Starting from the bottom, the mechatronic system and the environment determine the capabilities of the agent and the internal/external dynamics that must be taken into account to properly perform actions. Given the considered case study, the mechatronic system consists of a particular TM of the plant that must be controlled, the configuration of the overall transportation system (global topology) and the internal configuration of the TM as well as its connections with other TMs of the plant (local topology) are supposed to be known. The Monitor and the Executor are responsible of “physically” interacting with the TM by sending commands and receiving signals about their execution (i.e., feedbacks). Specifically, the Executor sends commands to the TM according to the actions that compose the plan to be executed. The Monitor receives signals about the (either positive or negative) outcome of the execution of such commands from the TM and checks whether the actual status of the mechatronic system complies with the plan or not. The Planning Framework synthesizes a set of “primitive” transportation activities (i.e. actions) that the TM must perform to carry out a set of desired (complex) transportation tasks. The Planning Framework relies on a planning model modeling the actual capabilities of the considered TM and the associated local topology. The deliberative layer synthesizes plans according to this general model. In case the plan execution leads to a failure (i.e., the actual status of the physical system does not comply with the plan) then, a “replanning process” is trigger for the Planning Framework to (re)generate a new plan according to the actual status of the mechatronic system.

The Deliberative Controller in Fig. 2 relies on a static planning model which completely characterizes the capabilities of a TM and the associated working environment. However, such a model is not capable of dynamically capturing changes in the configuration of the transportation system such as, e.g., changes concerning the local topology of a TM or changes concerning the internal configuration of a TM and therefore affecting the associated capabilities. The Knowledge Manager enhances the flexibility of the Deliberative Controller by dynamically generating planning models. In Sect. 3.3 will be shown how the Knowledge Manager leverages an ontological approach to process low-level signals from a TM and dynamically infer its internal configuration, the local topology and active capabilities (i.e., the set of transportation tasks a TM can actually perform). This information is represented and managed through a knowledge base (KB) which is continuously updated according to the signals/events received from the Mechatronic Module in Fig. 2. Then, a model generation process dynamically creates a new planning model every time a change in the KB occurs. Specifically, a new planning model is needed every time a change due by, e.g., a physical reconfiguration, in the actual capabilities of a TM is detected.

3.3 The knowledge-based control loop architecture

The goal is to have a coherent and optimized flow of information from the Knowledge Manager to the Deliberative Controller and to extend the capabilities of the overall system by leveraging knowledge processing capabilities. The Deliberative Controller is a complex component: it realizes a sense-plan-act cycle by means of a Planning Framework (Fig. 2, top right) and an Executor system (bottom right). In our implementation both modules use timeline-based technology [21]. The Planning Framework generates a planning model to synthesize the set of commands and signals for the continuous planning and execution actions of the artificial agent.

The Mechatronic Module (Fig. 2, bottom) is the composition of a Control Software and a Mechatronic Component (not shown in the figure) that are typical in industrial components such as, e.g., transportation modules, robots or working machines. This control software is usually based on standard reference models (e.g., IEC61499) and each mechatronic component is represented by dedicated hardware/software resources encapsulating the module control logic. The planning model contains an abstraction of the device to be controlled, the environment’s parameters in which the device operates, and a number of relevant constraints that guarantee physical consistency during execution. Note that the planning model is a static representation of the domain: it keeps track of just a subset of possible changes of the agent configuration and of the environment that are directly caused by the plan execution.

We call Knowledge-based Control Loop (KBCL) the interaction across these modules that enables the agent to dynamically represent its capabilities, its internal status and its environmental situation, and to automatically infer the set of available functionalities to generate a coherent planning model. Besides a classical sense-plan-act loop, the KBCL continuously monitors the environment collecting information from the agent’s components (via sensors, actuators and interactions with other agents) and updates the state of the environment in the knowledge base.

3.4 The KBCL at runtime

The KBCL supports a Setup phase (Point 1 in Fig. 2), when the mechatronic device is activated, generating the initial KB of the agent. More specifically, the Monitor (Fig. 2, bottom left) collects the raw data from the Mechatronic Module with which a knowledge processing mechanism (1) initializes the KB by adding the instances that represent the actual state of the device (Point 1 of Fig. 2) and (2) dynamically generates the control model providing a first planning specification (Point 2). Then the planning system generates a production plan (Point 3) and the plan execution is performed through the executive system (Point 4). When the Monitor detects a change in the structure of the agent and/or its collaborators (due, for example, to a total or partial failure of a sensor/actuator or of a neighbor), the KBCL process starts a Reconfiguration phase (Point 5) entailing the update of the KB, e.g., adding/removing instances, and starting a new iteration of the overall loop.

The KB is updated only when the detected changes prevent or possibly deteriorate (depending on the plan rules) the execution of the plan. It is worth underscoring that the Reconfiguration phase is activated in case of failures or when new capabilities are added. For instance, when a collaborating agent enters a maintenance period, its presence and capabilities are first deleted when entering the maintenance and re-inserted in the KB when operative again.

4 Modeling knowledge with ontology and contexts

We have seen different applications of ontology and context highlighting some drawbacks crucial to our goal, namely to provide a framework suitable to dynamically manage and control generic artificial agents. The aimed generality pushes us to look for a structure that is neither tailored to a specific type of agent nor to a specific type of situations, it is not based on an information model at the enterprise or shop floor level nor developed for some specific type of action.

To put it positively, we aim to build knowledge frameworks that should be evaluated in terms of flexibility. By flexibility we mean that the same framework can be used for different kinds of robots applied in different industrial scenarios and for different goals provided these scenarios and goals fall within the usual human common-sense perspective (this, e.g., excludes robots operating within a quantum perspective as needed in specialized domains). That is, one should be able to upload the same knowledge framework in different types of agent without compromising the quality of their functionalities, behaviors and reliability relatively to the available hardware. It follows that such knowledge framework must be independent from specific sensors and actuators, and can have only generic information on what could be in the environment. The advantage, if we succeed, is the design of robots with a new level of autonomy and adaptability compared to today’s standards. Before building the knowledge structure, the ontological approach helps us to analyze the types of information that an industrial robot could face.

The first result of this analysis is the separation of two layers of information: organizational knowledge and factual knowledge. Organizational knowledge is the foundational knowledge, i.e., knowledge about the basic assumptions in the domain such as the notion of object, agent, and production. including their relationships. This knowledge fixes what kind of entities, events and interactions there can be in general. Factual knowledge, instead, identifies how the actual scenario is out of all the possible configurations: which objects are present and where, which actions are executed and by which agent, which changes occur and to which object. Factual knowledge can be extended (without changing the foundational knowledge) as needed, e.g., to include knowledge about new devices (tools, machines) or changes in the shop floor layout. Changes in these two parts of the knowledge framework follow different principles and have different consequences. By keeping them apart, we can make them interoperate covering all the knowledge needed in production systems [22].

For the organizational knowledge, we start with the foundational ontology DOLCE, the Descriptive Ontology for Linguistic and Cognitive Engineering [23]. This is a domain-independent top-level ontology that has been exploited at different levels in the engineering and industrial domains, e.g., [14, 24,25,26]. DOLCE furnishes the basic structure of our knowledge system which we will enrich with domain knowledge, for instance adding the notions of artificial agent and of engineering function. The knowledge framework that we make available to an agent will be an extension of this ontological system. Since DOLCE is based on a first-order language with formal semantics, the ontology and the resulting knowledge base can be exploited via automatic reasoning.

4.1 DOLCE

The DOLCE ontology is a formal system built according to an explicit set of philosophical principles that guide its use and extension [23]. Our first interest is to introduce in DOLCE engineering notions which are central to our application concerns. Since DOLCE is a large and complex system, we cannot introduce it in detail but describe the minimal elements relevant to our work. We refer the interested reader to [23, 27] for motivations and technical aspects. DOLCE (Fig. 3) focuses on particulars, as opposed to universals. Roughly speaking, a universal is an entity that is instantiated or concreted by other entities (such as the property “being a tool” or “being a production process”). A particular, an element of the category PARTICULAR, is an entity that is not instantiated by other entities (such as the Eiffel Tower in Paris or Donald Trump). PARTICULAR includes physical entities, abstract entities, events and even qualities as we will see below.

Fig. 3

The DOLCE taxonomy of particulars

The DOLCE ontology formalizes the distinction between things such as a car and an organization (this category is called ENDURANT), and events such as transporting by means of a car and resting (category PERDURANT), see again Fig. 3. The term ‘object’ is used in the ontology to capture a notion of unity as suggested by the partition of the category PHYSICAL ENDURANT (a subcategory of ENDURANT) into categories AMOUNT OF MATTER, like the plastic with which my water bottle is made, PHYSICAL OBJECT, like my car, and FEATURE. Features are entities that existentially depend on other objects, e.g., a bump on a road or the workspace for a robotic arm. We will also exploit two subcategories of PHYSICAL OBJECT, namely, AGENTIVE PHYSICAL OBJECT, e.g., a person, and NON-AGENTIVE PHYSICAL OBJECT, e.g., a drill.

DOLCE also provides a structure for individual qualities (elements of the category QUALITY like the weight of a given car), quality types (weight, color, and the like), quality spaces (spaces to classify weights, colors, etc.), and quality positions or qualia (informally, locations in quality spaces). These, together with measure spaces (where the quality positions get associated to a measure system and to numbers), are important to describe and compare devices and processes. The exact list of qualities may depend on the entity: shape and weight are usually taken as qualities of physical endurants, duration and direction as qualities of perdurants. An individual quality, e.g., the weight of my hammer, is associated with one and only one entity; it can be understood as the particular way in which that hammer instantiates the general property “having weight”. That individual weight quality is what we measure when we put the hammer on a scale (if we put another hammer, no matter how similar, we would measure another individual quality, i.e., that of the second hammer even if the scale indicates exactly the same value). The change of an endurant in time is explained in DOLCE through the change of some of its individual qualities. For example, with the substitution or damaging of a component, the value of the weight quality of my car may change. DOLCE’s taxonomic structure is pictured in Fig. 3. Each node in the graph is a category of the ontology. A category is a subcategory of another if the latter occurs higher in the graph and there is an edge between the two. PARTICULAR is the top category. The direct subcategories of a given category form a partition. In the graph, dots indicate that not all the subcategories of that category are listed.

Some relations are particularly relevant for our work, e.g., the parthood relation: “x is part of y” (written: ${\textsf{P}}(x,y)$), with its cognates the proper part (written: ${\textsf{PP}}( x,y )$) and overlap relations (written: ${\textsf{O}}(x,y)$). These apply to pairs of endurants (e.g., the joint is part of the robotic arm) as well as to pairs of perdurants (e.g., riveting is part of the assembling process). On endurants, parthood has an additional temporal argument since an endurant may lose or gain parts throughout its existence (e.g., after substituting a switch in a radio, the old switch is not part of the radio). Another important relation is constitution, indicated by ${\textsf{K}}{:}\;\;{\textsf{K}}(x,y,t)$ stands for “entity x constitutes y at time t”, e.g., the amount of iron x constitutes the robot y at time t (this relation allows to say that part or all the iron x may be substituted over time without changing the identity of robot y like when substituting a worn out component).

4.2 An ontological view of artificial agents and their environment

Recently there has been increasing interest in the ontological modeling of artificial agents, and robots in particular [25], which led to an IEEE standard [28]. Today’s approaches to robot modeling are the result of long reflections on the difference between types of agency but further work is needed. For instance, we find problematic the proposal to model a robot mixing the notions of object and of role taken in [28]. According to the standard, a robot is “an agentive device [...] in a broad sense” while a fully autonomous robot is “[a] role for a robot performing a given task in which the robot solves the task without human intervention [...]”. The intention of the standard is to discriminate between the different ways the robot can act: autonomous, automated, tele-operated etc. In this view, the notion of robot that emerges is that of an agentive entity whose actual actions are limited by the role it plays. However, being in the “automated role” does not prevent an agent from acting autonomously like playing the “teacher role” does not prevent a person from making non educational acts. Most likely, the intention of the standard was to model the ontological notion of phase: being in an automated phase does prevent an agent from acting autonomously because the phase determines what the agent can do. The notion of phase is used in ontology to distinguish important changes in entities like the caterpillar and the butterfly. If we take the DNA perspective, these are the very same entity but the possible actions of the caterpillar are very different from those of the butterfly: which actions are possible is determined by the phase in which the entity is. Similarly, a robot in an autonomous phase has different possibilities than a tele-operated robot, for instance the latter does not make plans. The notion of role is not suitable to model this kind of change and we favor a revision of the standard in this sense.

Leaving aside these modeling choices, there are doubts whether robots should qualify as agentive entities in the strong sense since they lack intentional states. For most of today the so-called robots even the qualification of robot in the weak sense seems unjustified since often they have only a conventional stimulus–response behavior. On the other side, we tend to distinguish a robotic arm from a can opener: they are both artifacts [29] but we have a strong intuition that the second is a tool and the first a robot. Up to today, any attempt to draw the line between tools and robots has met important criticisms.

In this part of the paper, we propose an extension of the DOLCE ontology to include robots, robotic parts and tools. The goal of this extension is to start from the notions of artifact and of agent, as introduced in foundational ontologies, and to propose a way to discriminate among types of artifacts as needed to model industrial scenarios. Although we would like to achieve a wide characterization, in this paper our analysis is heavily influenced by the focus on robots used in industrial settings. Ontologically speaking, following the analysis in [30], a robot is an artifact: it is intentionally selected (via construction) and has attributed technical capacities. Technical capacities can vary considerably depending on the robots: they can be quite limited, like in ant robots, or flexible and multipurpose like in industrial or humanoids robots. Since we focus on industrial settings, thus on robotic arms, transportation modules and the like, the robots we aim to model are actually technological artifacts [29]: they are manufactured by following precise production plans and selected via dedicated quality tests. Thus, from the formal viewpoint we classify industrial robots as (technological) artifacts, i.e., elements of the ${\textsf{ARTIFACT}}$ subcategory of NON-AGENTIVE PHYSICAL OBJECT [30].

The typical robots in the production scenarios are rational, reactive and may present some degree of autonomy. Today they are rarely adaptive and embedded although these are desirable features. They can also be proactive: they have goals, typically provided by the production system to which they belong, and can sometimes choose, or at least reschedule, plans to optimize their achievements. In short, these robots are artifacts whose behaviors resemble agents’ behavior for the same goal(s). Since this behavior is expected from them, we propose to see a robot as an artifact whose attributed quality is to behave agent-like. Note that this modeling choice keeps agents and robots apart: a member of the latter group just mimics agents. The behavior can range from basic stimulus–response actions to activities controlled by sophisticated planning and goal adaptations, depending on what kind of agentivity the robot can behaviorally simulate. This is definitely acceptable for today’s robots and it does not exclude that future generations of robots might be considered as full-fledge agents. Note that we will continue to talk informally about robots as agents in the rest of the paper.

Let us use ${\textsf{ROBOT}}$ for the predicate ‘being a robot’ and ${\textsf{BehSp}}$ for the generic space of behaviors. Using the language of DOLCE from [23, 27, 30], we can formally model the ontological status of robots as follows:

$${\textsf{ROBOT(r)}} \to {\textsf{ARTIFACT(r)}}$$

(1)

$$\begin{aligned} &{\textsf{ROBOT(r)}} \wedge {\textsf{AttribCap(a)}} \wedge \\ &{\textsf{qt(a,r)}} \wedge {\textsf{ql(v,a,t)}} \to {\textsf{Loc(v,BehSp)}} \end{aligned}$$

(2)

The first formula says that a robot is an artifact. The second states what distinguishes a robot from other artifacts: the capacity attributed to the robot $({\textsf{AttribCap}}( a) \wedge {\textsf{qt}}(a,r))$ has values $({\textsf{ql}}(v,a,t ))$ that belong to the space of behaviors $({\textsf{Loc}}(v,{\textsf{BehSp}}))$.¹

Robot’s parts are themselves artifacts, thus elements of the ${\textsf{ARTIFACT}}$ category. These are typically not robots, so their attributed qualities are of different types. The main distinction here is between the parts that are components, i.e., that constitute the robot such as the engines that move the robotic arm structure and the structural pieces that are moved by the engines; and the parts that are tools used by the robot such as the different types of gripper that can be substituted depending on the task to execute. These types of parts are isolated for their functional or structural contribution. Following DOLCE, we use part (of an artifact) as a generic term to indicate any arbitrary portion of the artifact. We call component any part of the artifact which is itself an artifact and whose behavior contributes to the behavior of the larger artifact. These parts, following [31], are also called functional parts. We also assume that components are persistent parts, i.e., they are always present in the artifact exceptions being typically limited to maintenance time. One could further distinguish structural vs. operational components. In the first class there are elements such as shafts, in the second devices such as electric engines and sensors, that is, elements that can take some type of input and transform it into a different type of output (see the ontology of function in the next section). Note that these are not disjoint classes since an operational component can also be a structural component. However, there are structural components which are not operational like a shaft used to transfer torque. Finally, a tool is an artifact which can be a functional part of another artifact but is however not a necessary part for that artifact. In other words, a tool is an optional functional part of an artifact. Thus, the categories of tool and component are disjoint. For practical purposes, we require that a tool has been at least for some time part of an artifact. There are, of course, also arbitrary parts such as the upper half of the skeletal frame, which do not have special properties or functionalities and thus are not relevant in terms of knowledge and planning. Components (tools) can be in an active/inactive (available/non-available, respectively) state for the robot. Sensors are listed among the components but note that we do not distinguish between sensors and actuators since these are seen as roles of the agent’s components (a drill can play both of them at the same or at different times). Finally, an object that is a component is such until substituted (or dismantled) while a tool may remain such even if substituted. A richer classification of functional parts in genuine, replaceable, persistent, and constituent is presented in [32].

By environment one usually understands an area (a location) and the elements in it. In the case of agents, this is the area of interest in which the agent could act. For artificial agents, the environment might also include the requirements and specifications about the software components and their development. Since we will deal with languages and software constraints in terms of contexts (see Sect. 3.4), the notion of environment that we use focuses on the notion of location. Given our aims, we start from a general understanding of the term. The choice has essentially two motivations: the notion of environment should be sufficiently broad to include at least the usual scenarios and possibly more, and it should be sufficiently flexible to make it reusable via specializations. Thus, at each point in time, we take the robot’s environment to be the location where the robot is (it's area of movement) including the elements it contains plus the entities that, even though not in the location, can interact (positively or negatively) with the robot’s activities and goals within a relevant temporal span.

This view is fairly general and assumes that the environment depends on the robot’s features as well as on the features of other entities, possibly not in the vicinity of the robot. It is crucial to us to understand that the environment can change whenever the robot or its location or the entities there change. While our notion suffices for robots interacting wirelessly with other robots, we leave aside the characterization of environment in robots connected to internet since their environment is potentially much richer. In the case of production scenarios, the robot’s environment can be identified with the collection of physical entities that are within a certain range from the robot (where the range may be bounded by physical barriers such as floor, walls, ceiling, fences, etc.). As said, the environment is not necessarily limited to a precise region of space; it includes also entities with which the robot can interact via, say, radio communication and signaling in general. In ontological terms, the environment is a physical object obtained by the mereological sum of all the physical objects that are within the interaction range (workspace) of the robot. The location of the environment corresponds to the location of the objects in the environment plus the locations reachable by the robot itself.²

4.3 Ontology and engineering of functions

The classifications of the robots, the physical entities that may interact with them and their environments take care of the “static” part of our modeling problem. Since a robot is supposed to act to reach its goals, it must also have the conceptual machinery to know what it can do and how, thus to plan its actions. For this, reasoning on (engineering) functions is unavoidable. The formalization of functions in robotics is unfortunately rarely addressed and is too often confused with the notion of action, i.e., the performance of a function.

To overcome this problem, we extend the DOLCE ontology with an ontology of high-level functions. This function ontology is integrated, via DOLCE, with the ontology of the robot and robot’s parts making possible to model what a robot can do and how. We adopt a notion of function-as-effect (Fig. 4) which we adapt borrowing from well-known functional approaches in engineering design like the FOCUS/TX [33] (for the distinction “what to” vs. “how to” and the notion of behavior), the Functional Basis [34, 35] (for the idea of a function list), and the Function Representation [36] (for the distinction between environment-centric and device-centric function). The guiding idea is to make possible the identification of the high-level function (or sequence of functions) that needs to be executed to reach a given goal. For this, one explores the difference between the actual state and the desired state, and isolates the changes to be made. From this information, the robot can travel the taxonomy to identify the effects of the high-level functions and find a suitable combination.

Fig. 4

A (partial) ontological taxonomy of functions and its rationale

Figure 4 shows our top-level ontology of functions organized in 5 branches: functions to collect information, functions to change the operand(s) integrity, functions to change the operand’s qualities, functions to change the quality relationships, and functions to share information. For instance, “reclassify” stands for the function to change the classification of an operand, e.g. when, after a test, a workpiece is classified as malfunctioning; “change-over” applies when, e.g., a robot acts on itself to activate/deactivate some component; “channel” stands for the moving of an operand (change of its location); “stabilize” for maintaining relational parameters such as when tuning electronic components to regulate the input–output relationship; “sense” for the operand testing function, i.e., to acquire information without altering the status or the qualities of the operand; finally, “send” stands for the function to output information like a signal that a workpiece is going to be transferred or that a failure occurred.

Of course, this information is not enough since it would model just the ideal capacities of the robot. Aiming to have a robot adapting its plan at run-time, we have to model the actual capacities of the robot, which implies to take into account malfunctioning and/or missing parts or even deteriorated behaviors. This information depends on the capacities of self-inspection built-in in the robot as well as on the possibility to compare the “ideal actions” descriptions and the actual performances.

4.4 The use of contexts in industry

As said, an ontology is a conceptual tool used to structure information. Ontologies deal mainly with necessary information such as the properties that an object must manifest (shape, weight, mass etc.) or the types of event (states, actions, processes, and so on). Factual information, being information that depends on contingent data (such as spatio-temporal location, agent’s setting, goals, etc.), is generally characterized at the level of knowledge-bases. While this distinction might not be fully justified (and not even sharp), it remains important not to structure the ontology relying on factual knowledge. Unfortunately, this principle is rarely recognized in applications and in particular in the development of ontologies for industrial application.

Note that we insist on the distinction between necessary and contingent information only relatively to the development of the ontology structure: it is important that factual information finds its place in the factory information system. Our solution to this problem is to include factual information in the KB (built on top of the ontology) via contexts. This allows the system to classify and reason on factual information, for example, to understand the actual scenario and possible evolutions, to evaluate optimal production plans out of those that are actually possible, and even to establish the status of the resources or maintenance schedule. To act in real and evolving scenarios, factual information is thus essential. Contextualization allows us to manage it with an ontologically sound approach. Contextualization gives also an advantage at the reasoning level: it allows to differentiate types of information depending on their usefulness in reasoning on a situation or task.

After an ontological analysis based on [27, 37, 38], we identified three contextual models dedicated to factual knowledge, and use them on a par with the ontological framework. In particular, these contexts provide the time-dependent information needed to select how to execute high-level functions in the actual scenario. However, we do not exclude to expand the number of contextual models in the future since the use of factual classification is only partially explored at this stage of the work. Finally, note that our setting of the context framework makes possible to distinguish relevant consequences of the available knowledge depending on the type of the agent. The three context types are called global, local and internal, respectively. The global context collects information the agent cannot control nor modify like the shared language of the system, the agents present in the system, the system’s performance parameters. The local context collects information on the relationship between the agent and its neighbor elements (typically the human and artificial agents directly interacting with it), thus providing a local view of the topological setting. Finally, the internal context collects the information the agent has about itself as well as its capabilities toward itself (change-over) and toward the environment (communication and manipulation) [39].

We have so far described the KB we use for our artificial agents. We started from a foundational ontology which was already constructed from a cognitive stand and showed how we extended it to cover other kinds of knowledge, from artificial agents to functions. We also indicated how knowledge can be contextualized, thus allowing the KB to use a classification feature largely exploited by humans.

4.5 Applying ontology and contexts to the manufacturing case study

Given a particular application like the manufacturing scenario of the case study [18], it is necessary to define the relevant knowledge for a KBCL process to dynamically infer the specific capabilities of an agent and adapt the control model accordingly. Thus, we have extended the DOLCE ontology including the type of needed information by applying the context-based analysis and the functional characterization described in the previous sections.

The extended ontology aims at characterizing the knowledge concerning the general structure of a TM part of the plant, the related working environment and the general functional capabilities of TMs. This information represents the general knowledge (i.e. the TBox) that a KBCL process instantiates according to the specific features of the TM to be controlled, to generate the specific KB of a particular TM (i.e., the ABox). Figure 5 shows the extension of the DOLCE taxonomy of particulars with respect to the ${\textsf{NON}}{\text{-}}{\textsf{AGENTIVE PHYSICAL OBJECT}}$ category.

Fig. 5

Extension of DOLCE ontology

According to our extension of the DOLCE ontology, robots and their parts are modeled as subcategories of ${\textsf{TECHNICAL}}{\text{-}}{\textsf{ARTIFACT}}$. As described in Sect. 4.2, both robots and their components are artifacts but they differ in terms of the types of attributed qualities. Parts can be further distinguished into components, and parts that are only used by the robot to perform its tasks without constituting its structure, i.e., tools. Thus, the set of elements belonging to the ${\textsf{ROBOTPART}}$ category can be partitioned into elements belonging to the ${\textsf{COMPONENT}}$ category and elements belonging to the ${\textsf{ROBOTOOL}}$ category. Components have a spatial location within the robot structure (this would not be enforced for tools since they can be external to the robot), have an active state and functional capabilities. Let ${\textsf{COMPONENT(x, y, t)}}$ mean that ${\textsf{x}}$ is a component of ${\textsf{y}}$ at time ${\textsf{t}}$ and ${\textsf{ROBOTOOL(x)}}$ mean that x is a tool, then we have:

$$\begin{aligned} &{\textsf{COMPONENT(x,y,t)}} \to \\ &{\textsf{ROBOTPART(x,y,t)}} \wedge {\textsf{Artifact(x)}} \wedge {\textsf{ROBOT(y)}} \end{aligned}$$

(3)

$${\text{COMPONENT}}\left( {{\text{x}},{\text{ r}},{\text{ t}}} \right) \to {\text{COMPONENT}}\left( {\text{x}} \right),$$

(4)

$${\textsf{COMPONENT(x,r,t)}} \to {\textsf{COMPONENT(x)}}$$

(5)

$$\begin{aligned} &{\textsf{ROBOTOOL(x)}} \to \\ & \exists \,{\textsf{y,t(ROBOT(y)}} \wedge {\textsf{ROBOTPART(x,y,t)}}) \end{aligned}$$

(6)

Thus, the general class axiom characterizing the ${\textsf{COMPONENT}}$ category can be formally defined as follow:

(7)

where ${\textsf{ROBOTPART(p,r, t)}}$ is a predicate asserting that ${\textsf{p}}$ is a part of a robot ${\textsf{r}}$ and the formula states that when a part of a robot has a functional capacity (${\textsf{f}}$) and is in active state, then the part must be a component of ${\textsf{r}}$.

In our case study, considering the internal structure of a TM, it is possible to define three different types of component: (1) the conveyor component; (2) the port component; and (3) the cross-transfer component. Thus, we have extended the ${\textsf{COMPONENT}}$ category by introducing the ${\textsf{PORT}}$ category, the ${\textsf{CONVEYOR}}$ category and the ${\textsf{CROSS}}{\text{-}}{\textsf{TRANSFER}}$ category. The main distinction among the elements of these categories is the type of function the associated component can perform. Conveyors are the engines composing the structure of a TM that enable movements of pallets. These elements has channel capabilities that allow a TM to actually move pallets between two adjacent spatial locations connected through conveyors. The formula below formally characterizes the ${\textsf{CONVEYOR}}$ category:

(8)

where elements of the ${\text{CHANNEL}}$ category represent functions whose effect changes the spatial location quality of an operand (i.e., a pallet). The execution of a channel changes the location of the pallet from the start location to the end location. Cross-transfers are another type of engines that allow a TM to change its physical configuration. These elements have change-over capabilities that change the internal connections of a TM. Different configurations (i.e., internal connections) enable different directions of movements of pallets within a TM (i.e., different paths). The ${\textsf{CROSS}}{\text{-}}{\textsf{TRANSFER}}$ category can be formally defined as follows:

(9)

Finally, ports are structural elements that allow a TM to be connected with other TMs. These elements have communication capacities that allow a TM to send and receive pallets to and from other TMs of the plant. The ${\textsf{PORT}}$ category can be formally defined as follow:

(10)

Channel functions can be combined together to realize complex channels. Components that collaborate to perform channel functions must be spatially connected. Thus, the internal structure for this kind of functionality is determined by the connections of the components’ locations.³ The choice of modeling the elements of a TM with different categories rather than using the general ${\text{COMPONENT}}$ category relies on the different properties that these elements bring to implement functional capabilities. Their contribution to infer the functional capabilities of the TM will be discussed in Sect. 5.

The ${\textsf{ROBOT}}$ category has been extended by introducing the ${\textsf{TRANSPORTATION}}{\text{-}}{\textsf{MODULE}}$ category in a similar way to the ${\textsf{ROBOTPART}}$ category. It characterizes TMs from a functional point of view. TMs are modeled as a particular type of robot capable of performing channel functions by collaborating with other agents (i.e., other TMs or working machines) of the plant. The collaborators of a TM constitute the (working) environment of a TM and therefore they are part of the local context of a TM. The general class axiom characterizing the elements that belong to the ${\textsf{TRANSPORTATION}}{\text{-}}{\textsf{MODULE}}$ category can be formally defined as follows:

$$\begin{aligned} & {\textsf{ROBOT(r)}} \wedge {\textsf{ROBOT(c)}} \wedge {\textsf{hasCollab(r,c,t)}} \wedge \\ & {\textsf{CHANNEL(f)}} \wedge {\textsf{hasCapacity(r,f)}}\\ & \to {\textsf{TRANSPORTATION}}{\text{-}}{\textsf{MODULE(r)}}. \end{aligned}$$

(11)

It is important to point out that, in this context, a collaborator is a relative concept which depends on the particular configuration of the considered TM. It represents a relationship between a TM and other directly connected agents that could be either other TMs or working machines in the shop floor. Thus, the concept of ${\textsf{COLLABORATOR}}$ is modeled as a role that an agent may play according to local connections (i.e. local context) of a TM.

5 Connecting knowledge and control

The Knowledge Manager module (KM) in Fig. 2 is responsible for managing the lifecycle of the knowledge base (KB) within the KBCL process. In the specific context of the manufacturing case study, each KB models a particular TM of the transportation plant by specifying the associated internal structure, the connections with other TMs and the resulting functional capabilities. The management of such a KB relies on a knowledge processing mechanism implemented by means of a Rule-based Inference Engine which leverages a set of inference rules to generated and updated a KB of an agent.

The knowledge processing mechanism dynamically builds the KB by elaborating raw data received from the Diagnosis Module and infers knowledge concerning the structure, the working environment and the functional capabilities of the agent. This mechanism involves two reasoning steps, depicted in Fig. 6, that are (1) the low-level reasoning step and (2) the high-level reasoning step. Specifically, these two reasoning steps refine the knowledge about the agent by combining a set of dedicated inference rules with the general information of contexts and functions of the ontology described in the previous section.

Fig. 6

The knowledge processing mechanism

The first reasoning step, called the low-level reasoning, aims at characterizing a TM in terms of the components that actually compose its structure such as e.g., ports, conveyors, etc., and the associated collaborators. It relies on the internal and local contexts of the ontology and a set of classification rules. The resulting KB, named kb⁰ in Fig. 6, characterizes the structure of the TM and the related local working environment. This initial KB describes the agent in terms of its internal and local contexts.

The second reasoning step, called high-level reasoning, starts from the KB elicited after the previous step (i.e., the kb⁰) and further refines it by inferring knowledge about the functional capabilities of the TM. Specifically, the high-level reasoning step relies on the taxonomy of functions and the capability inference rules to complete the knowledge processing mechanism. The KB on which the high-level reasoning works encodes the particular internal and local context of the agent. Thus, the inference mechanism can determine the set of functions that the agent can actually perform by analyzing its structure and the associated working environment. The outcome of this second reasoning step (and the overall knowledge processing mechanism) is the final KB encoding a complete interpretation of the structure of the agent, the working environment (from the agent perspective) and the functional capabilities the agent can actually perform. Such knowledge is then exploited to generate the plan-based control model of the deliberative controller. The next two subsections provide a more detailed discussion of the two reasoning steps constituting the knowledge processing mechanism.

5.1 The low-level reasoning

The low-level reasoning process is responsible for inferring information concerning the internal and local contexts of the TM. Namely the result of this inference step is an initial KB describing the operating devices that compose the TM (i.e., the components) and the available collaborators. Namely it builds an initial version of the KB by classifying data received from the Diagnosis Module on the basis of contexts categorization. The input data represents a set of individuals concerning the parts that compose the TM, their connections and their capabilities. Figure 7 provides a (partial) graphical representation of a possible set of individuals and predicates the knowledge processing mechanism receives as input from the Diagnosis Module. In particular, the figure shows the different contexts the individuals belong to, the reasoning step exploits to provide these data with additional semantics.

Fig. 7

Raw data received from the Diagnosis Module

Given this set of data, the first rule applied by the low-level reasoning aims at identifying the set of active parts the TM can actually use to perform functions. These set of active parts are represented as TM’s components. According to axiom (7), an element of the ${\textsf{COMPONENT}}$ category is a structural part of a robot, it has an operative state and some functional capabilities. The inference process exploits this functional characterization of components to interpret input data and identify the components of the TM. According to the axiom (7), being ${\text{p}}$ a structural part of a robot ${\textsf{r}}$, with the capability of performing some function ${\textsf{f}}$, it is possible to infer that ${\textsf{p}}$ is an element of the ${\textsf{COMPONENT}}$ category. Therefore, due to axioms (4), the predicate ${\textsf{COMPONENT(p)}}$ is true.

The applied ontological approach models the different types of components that may compose a TM (see Fig. 5) according to the different types of functional capabilities. Leveraging this interpretation, the low-level reasoning process applies axioms (8)–(10) to classify inferred components and identify the different types of component that actually constitute the TM. As soon as the components are classified, the low-level reasoning process ends by inferring the set of available collaborators of the TM. Collaborators are TMs of the plant that are in operative state and are directly connected to the TM. Namely collaborators are TMs of the plant that can actually receive/send pallets from/to TM. This, collaborators are inferred by applying the following rule:

$$\begin{aligned} &{\textsf{ROBOT(r)}} \wedge {\textsf{PORT(p)}} \wedge {\textsf{hasLoc(p,l}}{_{\textsf{p}}}{\textsf{,t)}} \wedge \\ &{\textsf{ROBOTPART(p,r,t)}} \wedge {\textsf{hasOpStat(p,active, t)}} \wedge \\ & {\textsf{ROBOT(c)}} \wedge {\textsf{hasLoc(c,l}}{_{\textsf{c}}}{\textsf{,t)}} \wedge {\textsf{connection(l}}{_{\textsf{p}}}{\textsf{,l}}{_{\textsf{c}}}{\textsf{,t)}} \\ & \to {\textsf{hasCollab(r,c,t)}}, \end{aligned}$$

(12)

where ${\textsf{connection(l}}{_{\textsf{p}}}{\textsf{,l}}{_{\textsf{c}}}{\textsf{,t)}}$ is a predicate asserting that the location of the TM’s port ${\textsf{p}}$ is connected with the robot ${\textsf{c}}$. Figure 8 provides a (simplified) graphical representation of a possible KB resulting from the applications of rule (12) (the dotted arrows represent the inferred properties concerning collaborations).

Fig. 8

Inferring collaborators of a TM

5.2 The high-level Reasoning

The high-level reasoning step extends the KB elicited from the previous step inferring the capabilities the TM is actually able to use on the basis of its current status and current production environment.

Given the information about the components and collaborators of a TM, the first rule applied by the high-level reasoning aims at inferring the primitive channels the TM can perform according to its internal structure. Indeed, active components can be used by a robot to perform functions. For instance, a conveyor allows a TM to perform channel functions. According to this interpretation it is possible to define a rule to infer the set of primitive channels a TM can perform as follows:

(13)

where asserts that ${\textsf{c}}_1$ is a conveyor component of the TM whose operative state is active at time ${\textsf{t}}$. Namely, the conveyor ${\textsf{c}}_1$ is an active component of the TM and therefore, can be actually used to perform functions. Figure 9 shows a (simplified) graphical representation of the KB resulting from the application of rule (13). In particular, the figure represents predicates (i.e., the dotted arrows) and the individual (the channel-1 node) inferred and added to the KB.

Fig. 9

Inferring primitive channels of a TM

The rationale of rule (13) relies on the functional interpretation of the CONVEYOR category as the set of components that can perform channel functions. Thus, if a conveyor component connects two components of the TM through its spatial location, see the clause (${\textsf{connection(l}}{_2}{\textsf{,l}}{_1}{\textsf{,t)}} \wedge {\textsf{connection(l}}{_1}{\textsf{,l}}{_3}{\textsf{,t)}}$) in (13), then the conveyor can perform a primitive channel function between the components’ locations. Moreover, the ${\textsf{cConnect(l}}{_2}{\textsf{,l}}{_3}{\textsf{)}}$ is a transitive predicate which allows to connect different channel functions. Indeed, if two spatial locations are connected through the ${\textsf{cConnect}}$ predicate then there exists a composition of primitive channel functions that “connect” them.

A primitive channel involves components of one TM. However, the knowledge process mechanism aims to infer the channel capabilities that involve the collaborators of a TM. Namely, channel functions that allow a TM to exchange pallets with other TMs of the plant. We call such functions complex channel and they are inferred by applying the following rule:

(14)

Figure 10 graphically shows part of the KB resulting from the application of the rule (14). A key point of the rule (14) is that a complex channel function is interpreted as the composition of some primitive channels a TM can internally perform. This is a quite flexible and general interpretation of a channel function. If one or more parts of a TM stop working (i.e., their operational state passes to inactive), then a TM will no longer be able to perform the associated primitive channels and the high-level reasoning step will not be able to infer the associated complex channel functions that depend from these parts. Similarly, if new components are added to the TM, the high-level reasoning step will be able to infer additional complex channel functions according to the resulting structure. Finally, note that we do not add the converse formulas of (13) and (14) since these would prevent the discovery of alternative ways to perform the functions.

Fig. 10

Inferring complex channels of a TM

5.3 Implementation notes

Although the ontology is provided in first-order logic, at this stage only preprocessing (primarily to ensure conceptual consistency) is done in that language. Most of the inferences at runtime are done in the Web Ontology Language (OWL) version of the KB where we exploit primarily the contextual classification and relationships. The ontology editor Protégé⁴ has been used for KB design and testing. For runtime reasoning in the Knowledge Manager, we have used the Ontology and RDF APIs and Inference API provided by the Apache Jena Software Library⁵. Finally, the Deliberative Controller has been realized by means of the GOAC architecture [21] whose deliberative features are implemented by means of APSI-TRF [40]. A more detailed description of how the KBCL has been implemented goes beyond the scope of this paper.

6 Plan-based control loop

The Planning Framework element in Fig. 2 endows the KBCL process with deliberative capabilities by exploiting a timeline-based planner [41]. The planner relies on a timeline-based planning model automatically generated from KB’s information. Before describing the details of the process which generates the planning domain, this section provides a brief description of timeline-based planning and the pursued modeling approach.

6.1 Planning with Timelines

The timeline-based approach to planning has been introduced in early 1990s [42] and takes inspiration from the classical control theory. It models a complex system by identifying a set of relevant features that must be controlled over time. This approach has been successfully applied to real-world contexts (especially in space applications) and several planning frameworks have been developed for the synthesis of timeline-based P&S applications, e.g., EUROPA [43], ASPEN [44], and APSI-TRF [45].

Broadly speaking, timeline-based planning applications aim at controlling a complex system by synthesizing temporal behaviors of its features in shape of timelines. A timeline consists of a sequence of states/actions the related domain feature (e.g., a component of the device to control) may assume/perform over time. Every value on a timeline is temporally allocated and represents the value/action the feature assumes/performs during the related temporal interval. Temporal flexibility allows to allocate values to flexible temporal intervals, i.e., intervals with flexible start time and end time. The resulting timeline represents an envelope of possible temporal evolutions of the related feature. Thus, a timeline-based plan, which consists of the union of all the timelines of the domain, represents the sets of all the possible temporal evolutions of the domain features. It is important to point out that the temporal flexibility in such a plan can be exploited at execution time by an executive system to gain robustness [46].

6.1.1 Modeling approach

State Variables model the features of a system that must be controlled over time. A state variable describes the temporal behaviors of a specific feature by means of causal and temporal constraints. More specifically, it describes the values the feature can assume over time, their duration constraints and the allowed transitions. In this regard, starting from the ontological analysis of the functional capabilities and the structure of agents described above, we define a modeling methodology of timeline-based planning domains.

The key idea is that the planning domain is to describe the functional capabilities of the system we want to control, the features of the elements that compose the system and the features of the working environment that must be taken into account to successfully carry out the desired functionalities. From the control perspective, it is possible to identify three different classes of state variables: (1) functional state variables; (2) primitive state variables; and (3) external state variables. Functional state variables model a physical system as a whole in terms of the high-level functions it can perform (notwithstanding its internal structure). Primitive state variables model the physical and/or logical elements that compose a physical system. In particular, these state variables model the elements we must actually control to execute high-level functions. External state variables model elements of the domain whose behavior is not directly under the control of the system. For example, these variables model conditions that must hold to successfully perform operations.

The behavior of state variables must be further constrained by specifying inter-component causal and temporal requirements, called synchronization rules. These rules specify additional constraints that allow to coordinate the behaviors of the domain features to perform high-level functions (i.e., planning goals). Following a hierarchical approach, synchronization rules map the values of functional state variables into a set of constraints among the values of primitive and/or external state variables that guarantee the proper functioning of the overall system and its elements. Namely, synchronization rules specify how high-level functions are implemented by an agent. These rules describe dependencies between the different variables of a planning domain and therefore may determine a hierarchy among them. A comprehensive formalization of timeline-based planning is provided in [47].

6.2 The model generation process

Key role for the dialog between the Knowledge Manager and the Deliberative Controller is the Model Generation process (Step 2 of Fig. 2). The KB generated by the Knowledge Manager provides an abstract representation of the capabilities, the structure and production environment of an agent. The Model Generation process analyzes such a KB to dynamically generate a timeline-based planning domain for the Deliberative Controller.

The process encodes the hierarchical modeling methodology described in the previous section and builds the model by leveraging the context-based characterization of the KB. The information concerning the global context and the taxonomy of function allow to define the functional state variables that provide a functional view of the agent as a whole. These state variables indeed describe the high-level tasks the agent can perform over time.

The internal context contains structural information about the agent and therefore it is suited to generate the primitive state variables of the domain. These variables describe the physical/logical features that compose the agent. Usually, the values of this type of variables directly correspond to states or actions that may assumed/performed over time by the related feature.

The local context manages information concerning the working environment of the agent and therefore it is suited to build the set of external state variables of the model. These variables model the collaborating agents (e.g., the directly connected TMs of the plant in the case study) whose behavior may affect the capabilities of the agent, even if not directly controllable.

The Algorithm in Fig. 11 describes the general procedure of the model generation process. The procedure consists of four specific sub-procedures that analyze different areas of the knowledge about the agent to generate different parts of the control model. The procedure starts by extracting information related to the agent and initializing the P&S model (rows 3–4). According to the hierarchical approach described above, a set of functional, primitive and external state variables is generated (rows 6–8). Finally, the hierarchical decomposition of functional values (i.e., the values of the functional state variables) is described by means of a suitable set of generated synchronization rules (row 10). The resulting timeline-based model is then composed and returned as the outcome of the procedure (rows 12–13).

Fig. 11

The model generation procedure

Then, the buildControlModel procedure allows the model generation process to automatically build the timeline-based specification by leveraging the knowledge about the agent. As described in [48], every time a change occurs in the KB, a new instance of the model generation process is triggered to generate an updated control model of the agent. The next subsections provide some details about the sub-procedures of the process as well as an example of a possible timeline-based control model that can be generated for a TM in the case study plant.

6.2.1 Building state variables from contexts

The functional state variable generation procedure creates a set of state variables concerning the functional capabilities of the agent. The procedure relies on the set of capabilities the knowledge processing mechanism has inferred through application of rules (13) and (14). The procedure generates a state variable for each function of the taxonomy (see Fig. 4) the agent can perform. Namely given a particular function f of the taxonomy, if the KB contains at least one individual for that function f (i.e., if the knowledge processing mechanism has inferred at least one way for the agent to perform f), then a state variable sv for f is created. The individuals of f in the KB represent all the possible implementations of f that the agent can perform (i.e., all the capabilities of the agent with respect to f). Thus, for each inferred individual of f the procedure adds a value to the related (functional) state variable sv.

The Algorithm in Fig. 12 shows the pseudo-code of the buildFunctionalComponents procedure. The procedure first initializes the set of functional state variables of the domain (row 3). Then, the procedure reads the taxonomy of function from the KB and, for each function, checks the available capabilities of the agent (rows 6–20). Given a function, if the KB contains at least one capability for that function, then the procedure creates a functional state variable (rows 9–11). Each capability found in the KB is modeled as a value of the state created variable (rows 12–15). The procedure ends by returning the set of obtained variables.

Fig. 12

The functional variable generation procedure

The primitive state variable generation procedure creates a set of state variables concerning the structural components of the agent. The procedure relies on a functional interpretation of components as elements that allow the agent to perform functions. The procedure creates a primitive state variable to the model for each component found in the KB. According to the rules (8)–(10) the components of the agent are modeled in terms of their capabilities. Thus, the values of these state variables represent the primitive functions of the agent.

The Algorithm in Fig. 13 shows the pseudo-code of the buildPrimitiveComponents procedure. The procedure first initializes the set of primitive state variables of the domain (row 2). Then, the procedure reads the set of inferred components from the KB (row 4). Given a component, if the KB contains at least one primitive function the agent can perform through that component, then a primitive variable is created (rows 5–10). The values added to the variable model the capabilities of the related component. Namely, the values model all the primitive functions the agent can perform by means of the considered component (rows 11–16). The procedure ends by returning the set of generated state variables. The external state variable generation procedure creates the set of external variables composing the timeline-based model. The procedure generates the set of state variables representing the collaborators of the agent. Specifically, a state variable is created for each individual found in the KB that, according to the inference rule (12), has been classified as collaborator. The values of these state variables represent the operative states the collaborators may assume over time.

Fig. 13

The primitive variable generation procedure

The Algorithm in Fig. 14 shows the pseudo-code of the buildExternalComponents procedure in Fig. 11. The procedure first initializes the set of external variables of the domain (row 2). Then, the procedure reads the set of inferred collaborators from the KB (row 4). For each collaborator found, a state variable is created (rows 5–7) and for each operative state the collaborator may assume over time, a value is added to the created variable (rows 9–14). The procedure ends by returning the set of generated variables.

Fig. 14

The external variable generation procedure

6.2.2 Building decomposition rules from inference trace

When all the state variables and their values have been generated, it is necessary to build the synchronization rules of the domain to coordinate the behaviors of the different components of the agent and achieve the desired goals. Thus, given the general procedure in Fig. 11, the buildSynchronizationRules procedure generates the decomposition rules by leveraging the inference trace of the KB.

The inference trace represents internal knowledge generated by the application of the inference rules. Such knowledge manages intermediate information which is necessary to complete the knowledge processing mechanism and therefore build the KB. For instance, besides primitive channels, the inference rule (13) generates cConnect properties. These properties do not represent specific information about the agent but are necessary to generate the set of complex channels, as shown in rule (14). These properties encode functional dependencies among the components of a TM. In particular, they encode these dependencies in terms of primitive channels needed to implement complex channels.

The inferred cConnect properties can be analyzed to build a particular data structure, called functional graph, that correlates functional dependencies among components, primitive and complex channels. The graph is built according to the inferred cConnect properties. Thus, the possible implementations of complex channels can be found by traversing the functional graph. This set of information is necessary to build the set of synchronization rules specifying how the agent must execute complex channels. Indeed, synchronization rules are generated by analyzing the paths on the functional graph that connect the start with the end locations of complex channels. These paths can be easily expressed in terms of precedence constraints between primitive channels of the involved components.

The Algorithm in Fig. 15 shows the pseudo-code of the buildSynchronizationRules procedure. The procedure first initializes the set of rules (row 2) and then analyzes the KB to build the functional graph concerning channel functions (row 4). For each complex channel the procedure extracts the available implementations from the functional graph (rows 6–9). Each implementation encodes a set of temporal constraints between the primitive channels of the agent. Thus, given a possible implementation of a complex channel, a new synchronization rule is created (rows 10–14). The procedure ends by returning the set of generated synchronizations.

Fig. 15

The synchronization rule generation procedure

6.2.3 The resulting timeline-based control model

The described procedures encode a model generation process which relies on a context-based characterization of the KB. According to this structure, the process generates a hierarchical domain description modeling the complex functions of the agent in terms of primitive functions internal components can directly handle. Figure 16 shows a partial timeline-based model generated for a TM which is endowed with a single cross-transfer unit. The model provides a functional characterization of the TM according to the functional, primitive and external hierarchical levels.

Fig. 16

A (partial) timeline-based model generated for a TM equipped with one cross-transfer unit

The primitive state variables (the green ones in Fig. 16) model the active parts of the TM that can actually perform some (primitive) functions. These state variables model the functional capabilities of the elements that compose the TM. For example, the component Conveyor1 can perform the primitive channel ChannelF-Down to move a pallet between the location of component PortF and the location Down of component Cross1. Similarly, the component Cross1 can perform the primitive channel ChannelDown-Up to move a pallet from the location Down to the location Up of the same component Cross1.

The external state variables (the gray ones in Fig. 16) model the inferred collaborators that can directly interact with the considered TM. The values of these variables represent the operative states that collaborators may assume over time. Figure 16 shows the external state variables concerning two of four collaborators available. Specifically, the state variables model the temporal behaviors of CollaboratorF and CollaboratorR, i.e., the collaborators connected to the TM through the components PortF, and PortR, respectively.

The functional state variables (the blue ones in Fig. 16) model the inferred channel functions the TM can perform by combining the internal (i.e., the primitive) channel functions. For example, according to this interpretation, ChannelF-R can be seen as the composition of the following primitive channels: ChannelF-Down, ChannelDown-Up, ChannelUp-R. Such a composition represents a particular implementation of the complex channel function ChannelF-R. Implementations are modeled by means of synchronization rules that specify a suited set of temporal constraints (see red arrows in Fig. 16). These temporal constraints encode also the functional dependencies between the TM and its collaborators. Indeed, CollaboratorF and CollaboratorR must be available (i.e., operative) during the execution of the complex channel function ChannelF-R.

The generated timeline-based planning model provides a functional characterization of TMs of the plant where planning goals represent high-level functions a TM can perform. These functions are described in terms of the atomic operations (i.e., primitive functions) a TM is able of performing by means of its components and the available collaborators.

7 Experimental evaluation

To validate the architecture and the Knowledge-based Control Loop described above, the whole system has been deployed in the manufacturing case study.

A set of tests has been run for the KBCL with different TM configurations. Specifically, all the different physical configurations of a TM have been considered, i.e., from zero to three cross-transfer modules, referring to them as simple, single, double, and full configuration, respectively. A different configuration also entails a different number of connected TM neighbors. Clearly, the more complex scenario is the one with the highest number of both cross-transfers (the full configuration) and neighbors. Moreover, reconfiguration scenarios have been addressed considering different external events, i.e., an increasing number of TM neighbors momentarily unable to exchange pallets, or internal failures, i.e., a cross-transfer engine failure or a local failure for a specific port.

The experiments were carried out to evaluate the performance of the following aspects of a single TM agent: (1) the knowledge processing mechanism; (2) the planning model generation; and (3) the synthesis of plans to manage a set of pallet requests. The final aim is to show that the latency of the KBCL is compatible with execution latencies of the RMS. Figure 17 shows the timings⁶ in the Setup phase for the KBCL module operation, i.e., to build the KB exploiting the classification and capability inference process, and to generate the timeline-based planning specification for the TM. On the one hand, the results show that an increase in the complexity of the TM configurations does not entail a performance degeneration of the knowledge processing mechanism: the inference costs are almost constant (around 1.3 s). This behavior was expected since the number of instances/relationships in the KB is rather low independently of the physical configuration of the TM; thus, the performance of the inference engine deployed here is not particularly affected by this aspect. On the other hand, the model generation is linearly affected by the increasing complexity, spanning from 0.8 s in the simple configuration, up to a maximum of 2.2 s in the full configuration.

Fig. 17

KB inference and planning domain generation times

The model generation process entails a combinatorial effect on the number of instances/relationships needed to generate components and synchronizations leading to larger planning models and, thus, to higher process costs. When a reconfiguration scenario occurs, the knowledge processing costs are negligible. Among all the considered reconfiguration cases, the time spent by the knowledge processing mechanism to (re)infer the enabled functionalities is just a few milliseconds. In fact, both the classification and capability inference steps are applied to a KB only slightly changed after the reconfiguration. The small changes in terms of functionalities can be quickly inferred in the system and represented in the current KB. As for the planning model generation cost, the considered reconfiguration scenarios (either external or internal) lead to a reduction of functionalities and the related costs are relatively small. For instance, in the case of the full TM configuration, the cost for the model generation is always below 0.8 s.

Finally, we evaluate the planning costs when facing both setup and reconfiguration scenarios with an increasing number of pallet requests (randomly generated in the specific case), i.e., planning goals, to be fulfilled. Planning costs span from few seconds up to nearly 30 s when planning for 10 pallet requests within a 15 min’ time horizon. In general, the more complex the planning model, the harder the plan synthesis problem. Thus, the planning costs follow the complexity of the configurations of the specific TM agent.

7.1 Discussion

The experimental results show the practical feasibility of the KBCL approach in increasingly complex instances of a real-world manufacturing case study. The collected data for the initialization (or the update) of a generic agent’s KB (considering both knowledge processing and model generation) and the cost for planning synthesis have a rather low impact on its performance during operation. In fact, to face production periods of 15 min—and the management of 10 pallet requests—no more than 5 s are required by the Knowledge Manager while less than 30 s are required by the Planner to generate a suitable plan. These performances are compatible with the system usual latency in this type of manufacturing applications [19]. It is worth reminding how the role of the KBCL is to avoid major overhauls of the control policies (e.g., control code revisions deployed too often in concrete cases) to cope with adaptation to variations or plant reconfigurations.

8 Conclusions

In most architectures for artificial agents the knowledge of the world is distributed across different parts of the system. This may lead to information redundancy (jeopardizing consistency), planning-knowledge misalignment, inconsistent knowledge update, etc. We have proposed to use a single foundational ontology to coherently organize knowledge on the entities and relationships in the agent’s world (objects, functionalities, states including the agent and its components) augmented with context modules that store the factual knowledge of the agent on these entities. We then have described how the knowledge manager extracts information for the planning and execution module of the agent. With this setting, the agent can reason on its own capabilities and adapt its plans in case of failures or sudden changes in the world. To validate the approach, we provided an implementation of the knowledge control loop and showed that it has performances compatible with the settings of a realistic industrial scenario. The validation is promising but admittedly limited: a full implementation in a large industrial scenario is needed to compare our work with other approaches.

Several issues remain to be explored. First, it is important to have a fairly amount of common knowledge on the environment to take advantage of the knowledge in the ontology and the context modules. It is also unclear how to optimize reasoning by taking advantage of the expressivity of the available languages (first-order logic and OWL), since reasoning in languages such as OWL leads to ignore basic information about, e.g., activity ordering and functionality constraints. Second, we have to expand the connection between the ontology of functions and the constraints on the agents’ state variables: these constraints are crucial to execute the functions and control the changes in the environment. Finally, our verification scenario is still quite limited.