Service-oriented Architecture (SOA) describes a collection of design principles for the development of distributed systems. SOA relies on the paradigm of service-orientation, i.e., the different software components provide their functionalities as loosely-coupled services over a network. This means that services provide functionalities over standardized interfaces independent from the underlying implementation. Web service technologies have emerged as the most prevailing implementation of SOA. XML-based languages like WSDL (Web Service Description Language) are used to describe a service’s interface, functionalities and characteristics. The most important activities in a SOA-based system are discovery and orchestration. The UDDI (Universal Description Discovery and Integration) specification depicts a way to build service repositories, in which services can be published by service providers and searched and discovered by service requesters. The combination of existing web services to more complex services or processes is usually performed using BPEL (Business Process Execution Language).

There are several issues concerning the implementation and usage of systems based on the SOA paradigm using syntactic approaches [7]. Semantic technologies can be used to describe the meaning of service capabilities in a machine-understandable manner by adding a semantic layer to the syntactic service descriptions. In this way, an efficient discovery and dynamic orchestration of services can be realized. In the following sections, semantic technologies and the different approaches for the definition of semantic web services are illustrated.

Semantic technologies allow the formal description of data and support the semantic processing of data by machines, i.e., the interpretation of electronically stored pieces of information with regard to their content and meaning. The formal, explicit representation of knowledge forms the cornerstone of the Semantic Web and includes both the modeling of knowledge and the definition of formal logics, which provide rules to draw inferences over the modeled knowledge base.

While several semantic modeling approaches for the representation of knowledge with different expressional power exist (e.g., taxonomies, thesauri, topic maps), ontologies depict the most popular and the most powerful approach of explicit knowledge representation. Ontologies, often defined as “an explicit specification of a conceptualization” [8], enable the modeling of information as an independent knowledge base consisting of three basic structures, namely classes, relations and instances.

Ontologies facilitate the structured exchange of information among heterogeneous systems, resulting in a semantic interoperability. To this end, special description languages are needed. The Web Ontology Language (OWL) is the ontology description language of the Semantic Web initiative standardized by the W3C [9]. OWL provides formal semantics and an RDF/XML-based syntax. The Resource Description Framework (RDF) is a formal description language for meta data, which describes information by means of so called RDF triples (subject–predicate–object) [10]. RDFS (RDF Schema) extends RDF by properties, domain and range constructs and hierarchical structures. It is already possible to model simple taxonomies using RDFS. However, OWL is the most expressive of these description languages. It provides additional features to describe complex logical expressions, cardinalities and axioms (e.g., disjunction) etc.

The syntactic description of web services and their orchestration results in a semantic gap between the syntactic description of the web service interface and the meaning of the underlying functionality. On the basis of a semantic annotation using semantic technologies, the meaning of a web service definition can be described in a machine-understandable manner. This additional semantic layer helps to enable the efficient discovery and the dynamic orchestration of services to build higher-value services or processes.

Several approaches exist to describe web services, their operations and parameter types semantically [7]. The most common semantic web service technologies include SAWSDL, WSMO and OWL-S.

SAWSDL (Semantic Annotations for WSDL) is a W3C recommendation, which describes a lightweight mechanism to add semantics to web services [11]. It is aimed at annotating certain parts of the web service’s WSDL descriptions by adding references to semantic models. It does not specify any description language for the referenced semantic model, i.e. arbitrary models can be used such as UML or OWL ontologies. SAWSDL uses the modelReference attribute to annotate XML Schema type definitions, element declarations, portTypes, operations, and messages. In addition, the attributes liftingSchemaMapping and loweringSchemaMapping are used for the mapping between the technical representation of parameter types using XML and the corresponding semantic concepts. In contrast to other approaches such as OWL-S, there is no support for the description of preconditions and effects of a service.

WSMO (Web Service Modeling Ontology) provides a conceptional model for the description of different aspects of a semantic web service [12]. Its corresponding description language WSML (Web Service Modeling Language) is used to model WSMO services in a formal manner. WSMO defines four top level concepts, namely ontologies, goals, services and mediators. Ontologies provide the terminology that is used by the other WSMO elements. Goals describe the task a web service is required to solve. Services provide a semantic description of the web service’s functional and behavioral aspects. Mediators are used to resolve mismatches between different WSMO elements.

OWL-S is a technology to describe the semantics of a web service based on OWL ontologies [13]. To achieve this, it consists of three types of knowledge about a web service: what does the service do (ServiceProfile), how does the service work (ServiceModel) and how can the service be invoked (ServiceGrounding). As opposed to SAWSDL, which follows a bottom-up approach to annotate services, OWL-S models the semantic service description on a high level of abstraction as an OWL ontology and then links this description to the concrete WSDL file. This approach is very expressive and makes it possible to describe highly powerful semantics of a service. However, at the same time, this increases the complexity of the description process significantly.

OWL-S not only offers ways to describe single web services semantically, but also to model processes composed of single web services. To this end, OWL-S distinguishes between so called Atomic Processes, Composite Processes and Simple Processes. An Atomic Process can be invoked directly as it is connected to a concrete WSDL file. It corresponds to the operation of a WSDL service. A Composite Process can be composed of Atomic Processes or further Composite Processes. The composition is described by OWL-S control constructs like Sequence, Split, and so on. A Simple Process represents an abstract template of a service, i.e., it depicts a semantic description of a service without concrete linking to a WSDL file. However, it can be assigned to an Atomic Process at runtime using the realizedBy reference.

The semantic discovery and context-based orchestration system described in this article builds upon an architectural approach characterized by the concept of service-oriented architectures in production automation. The state of the art of the application of service-oriented architectures in this field is characterized by the technical realization based on web standards. The two outstanding approaches that dealt with the set-up of service-oriented architectures in production automation arise from the EU-founded research projects SOCRADES and PABADIS’PROMISE. In PABADIS’PROMISE, a control architecture was developed that enables a decision responsibility distribution among acting control entities [14]. The ERP system comprises several classes of business functions that are encapsulated as services. The connection to the agent-based MES system is realized through web services. The SOCRADES consortium developed a web service based communication architecture for the industrial automation domain [15]. The focus was the connection of field devices with high-level control systems like MES and ERP systems. Therefore, the communication technologies DPWS and OPC-UA were used.

The use of the paradigm of service-oriented architectures in the context of industrial automation systems is intended to significantly decrease the effort for integration and programming of automation components. The two basic aspects of this approach are the standardization of communication interfaces and the functional encapsulation of mechatronic functions that enable a high flexibility and an improved control of complexity for automation systems. The basic functions of the manufacturing equipment that execute and monitor the production process are represented as basic services. These basic services can be aggregated to composed services that control the production process.

With the evolving usage of service-oriented architectures in production systems, the semantic description of services becomes more important. Particularly, within the scope of the SOCRADES project, concepts for the usage of ontologies in the production domain [16] and for the semantic discovery and orchestration of services to production processes [17] have been developed. However, they only show the feasibility of semantic service implementations in simplified setups or simulations. We put emphasis on the implementation of industry-related experimental setups within a real-world research facility, the SmartFactory^KL. In addition, we believe that clearly defined methodologies for the creation of semantics-supported systems as well as the construction of a fundamental structure of reusable ontologies are necessary in order to make semantic technologies applicable to the production domain.

Concerning the discovery of services, Guinard et al. [18] describe a concept for the discovery and selection of real-world services provided by embedded devices. They build upon the results of the SOCRADES project concerning the DPWS networking discovery mechanism. In addition, they discuss a concept for on-demand provisioning of missing services, which depicts an interesting idea for a future extension of our system. Samaras et al. [19] describe a concept to integrate resource constrained devices into enterprise information systems. To this end, they propose a discovery mechanism based on semantic annotations. The central topic of their work is the adaption of existing web service standards to work with resource restricted devices. Both works do not focus on the usage of semantic services within the domain of factory automation as the basis for a context-based orchestration.

Several works dealing with the orchestration of services in factory automation propose a pure syntactical orchestration of services based on BPEL [20,21]. Indeed, these approaches are rather suited for static workflows than for a dynamic orchestration of services [22]. In particular, Ferrándiz-Colmeiro et al. [23] propose a concept closely-related to our vision of a context-based orchestration of services to adapt production processes. They describe an orchestration system, which uses ontologies to transform abstract process models to concrete BPEL processes tailored to the capabilities of the respective industrial plant, which are represented as services in a UDDI repository. This work depicts an important basis for the future research on semantic orchestration of services in the production domain. In this article, we build on the results of this approach, but focus on the construction of a fundamental structure of reusable ontologies, the creation of a methodology for the semantic discovery and context-based orchestration of services in factory automation and the implementation of industry-related experimental setups within the SmartFactory^KL.

Manufacturing companies have been under pressure recently due to shorter product life cycles and greater product individualization. In order to stay competitive in this environment, processes and systems need to become more flexible and agile [24,25]. This new requirement poses a great challenge for today’s automation systems because changing a production process for example from one product to a new product generation is usually associated with a high amount of programming and configuration. Three exemplary use cases illustrate different aspects of changing production processes and are used to deduce requirements for a dynamic context-based orchestration and the underlying semantic models with the goal of creating flexible automation systems.

The first use case is that of a field device in the production process being replaced with a new possibly better (e.g., resource-efficient) device that can fulfill the same task. This can often be the case in production plants because of component failure or the need to improve some process parameter by installing a better device. With traditional automation systems, this device has to be manually integrated into the programming environment of the PLC (programmable logic controller). This requires the configuration of the communication interface and adaption of the PLC program to the new devices’ functional interface (often on signal-level), which depicts a time-consuming process that requires on-line testing to verify the correctness of the new program and thus expensive down-times of machinery. In order to achieve an improvement of this problem, we envision a plug-and-play-like replacement of components that automatically integrates the device into the automation system.

The second use case which describes the lack of flexibility in today’s production environments and which we want to address with our approach focusses on the need to change the production process because some component is not available on short notice. In some cases this could be countered with rerouting the current product to another production station (e.g., if there are several equivalent welding robot cells) or changing the sequence of production steps. This ad-hoc reaction to changes in component availability can keep the production process running and reduce down-time losses. The problem that needs to be solved in order to achieve this dynamic process rerouting is finding a device or production unit that can fulfill the same task or a new sequence of process steps that result in the same outcome.

The third problem that we want to focus on results from the need for greater product individualization because of consumer demand. For each product variant a concrete program needs to be specified for each production station and executed once the product reaches this station. Changes in the product specification result in the need to modify each program at the decentralized stations. Recent research offers a new possibility of dealing with this challenge: a product-mediated communication within a production system [5] allows a product to carry information about the customer order or the status of its production. Extending this idea beyond merely carrying status and order information, a product could also carry an abstract representation of the manufacturing processes needed for its completion. Enabling automation systems to read this representation and automatically choose and execute appropriate concrete process steps for each abstract stage can lead to a greatly improved flexibility in production processes and new possibilities for product individualization.

Having discussed the three use cases, the following requirements can be derived that must be met by a semantic discovery and context-based orchestration system to achieve flexible manufacturing control:

Based on the requirements derived from the use cases described in the last section, we developed a structure of modular ontologies, which depict the basis for the semantic description of services provided by field devices and which are used for semantic reasoning in matching and selection processes. In the following sections, this ontological structure is illustrated and the different contained ontologies are described in detail.

The modeled ontologies described in Section 3.2 can be used for the semantic description of the web services provided by field devices based on OWL-S. Because OWL-S itself is based on OWL, it allows an easy integration with our domain and application ontologies. For each operation of a web service, an OWL-S AtomicProcess is created using Protégé 3.2.1 and the OWL-S Editor plugin. Thereby, the WSDL2OWL-S Tool is used initially to create the basic structure and the grounding of the OWL-S AtomicProcess. In the next step, the OWL-S description of a service operation is connected to the device ontology by referring to the respective device instance using the OWL-S serviceCategory attribute. The semantic description of the input and output parameters is integrated in the OWL-S Grounding, which basically describes a mapping between syntactical descriptions of a web service (e.g., WSDL files) and the parameter concepts of our parameter ontology. The semantic annotation of further functional and non-functional service properties are modeled using the OWL-S serviceParameter reference. By modeling each aspect as a subclass of ServiceParameter, we are able to utilize arbitrary semantic mappings to our sub ontologies. In this way, instances such as the consumed resource or provided function can be referenced, but also numeric values can be assigned (e.g., operating hours of a device).

In addition to the direct annotation of our services in OWL-S, further implicitly assigned knowledge about the service can be used in the later matching, selection and orchestration processes using a reasoning system. For instance, as the OWL-S description of a service is assigned to its corresponding device ontology, which is again connected to the plant ontology, structural knowledge about the plant can be used to determine if the present service is dependent on other services in the plant. The same holds true for domain-specific knowledge modeled in the equipment ontology, for example.

The efficient discovery of services provided by field devices depicts the basis for a context-based orchestration for control of manufacturing processes. To this end, mechanisms for the registration and advertising of services on the network level as well as for the capability-based search and discovery of services are needed. For the automatic registration of devices and their services, we make use of the discovery mechanism of DPWS (Device Profile for Web Services) [37], which specifies a reduced web service stack (e.g., WS-Discovery, WS-Eventing) designed for the implementation of web services on resource-constrained devices such as embedded systems. Our approach is based on the implementation of DPWS services on microcontrollers, which are connected to the respective field devices. In addition to the web service implementation and its syntactic interface definition, the semantic description of the service (as discussed in Section 3.3) is stored on these microcontrollers as an OWL file. As soon as a field device is available, it broadcasts a hello message on the network, which is recognized by a java program (Service Monitor) running on a server (step a in Figure 5). This program can also send an initial probe message to find all services currently available. The Service Monitor retrieves the semantic description of the service and passes it to the Repository Manager (step b in Figure 5), which extracts all information about the service and stores it in the Semantic Service Repository (step c in Figure 5). We implemented the Semantic Service Repository based on the OWLIM triple store, which can be used to store and retrieve mass data in an efficient way. In this repository, information about a service is represented as RDF triples. The Repository Manager not only extracts the necessary information from the device ontologies and OWL-S descriptions of a service, but also provides high-level methods for adding and removing services to or from the Semantic Service Repository based on SPARQL queries.

Our approach for a context-based orchestration of services is based on the concept of deriving the concrete process used to control the manufacturing process from an abstract process description specific to the product to be produced. This abstract description of the product-specific production process is modeled as an OWL-S CompositeProcess, which consists of abstract OWL-S SimpleProcesses, which do not have groundings to executable web services. These SimpleProcesses could represent either basic operations or high-level functions of our function ontology described in Section 3.2. The abstract process description could be directly attached to the product (e.g., stored on an RFID tag). By doing so, the product carries knowledge about its own production process.

The concrete instance of the process is generated depending on the actual structure of the production plant and the capabilities of its field devices making use of our semantic discovery and service selection system. The orchestration of the concrete process happens ad-hoc, i.e., right at the moment the product enters the production plant. Even more, the orchestration system could adapt the process at runtime (e.g., in case of a faulty component) by finding components that provide an equivalent or similar service.

Figure 5 depicts the system architecture of our context-based orchestration framework, which is divided into three layers: the service registration (already discussed in Section 3.4), the service discovery and selection and the service orchestration. The numbers represent the steps of the overall orchestration process. In the first step, the abstract process description of the current product (OWL-S CompositeProcess) is passed to the Process Decomposition, which decomposes the CompositeProcess into SimpleProcesses. For each SimpleProcess, the Discovery Manager is asked to find a matching AtomicProcess, i.e., a concrete web service provided by a field device or component in the plant (step 2). To this end, the Discovery Manager requests all the web services that are currently available in the plant (step 3). The Repository Manager queries the Semantic Service Repository to get back all the services including their additional information, which are sent back to the Discovery Manager (step 4). The retrieved set of OWL-S AtomicProcesses acts as input for the Matchmaker (we used iSeM [38] in our implementation), which performs a functional matchmaking based on input/output parameters of the services (step 5). The Matchmaker generates a list of hypothetically matching services (on a functional level) and delivers it to the Context-based Rating Component (step 6). In the next step, contextual information (e.g., current state of products, machines, resource consumptions), which is queried from a Context Broker (compare Section 3.6) is used to influence the rating of the hypothetically matching services. In addition to contextual information, the rating process is influenced by both domain and application knowledge inferred from our different ontologies (e.g., plant ontology, equipment ontology, functional ontology). The Rating Component assigns weights to different matching criteria (e.g., provided operation, equipment category, consumed resource, Quality of Service attributes) and calculates a total score for each service. The service with the highest score is selected and sent to the Process Orchestration (step 8), which performs a re-composition of the process taking the input/output annotations of the single services but also knowledge from the function ontology and the equipment ontology into account. The procedure from step 1 to 8 is repeated until a concrete AtomicProcess is found for each SimpleProcess contained in the abstract process description. In the last step (step 9), the resulting concrete OWL-S CompositeProcess is forwarded to the OWL-S Engine, which invokes the contained services following the respective control constructs in order to control the manufacturing process for the present product in the plant.

The developed system for semantic discovery and context-based orchestration can not only be used to realize an ad-hoc orchestration tailored for the present product (or product variant), but also for the plug-and-play integration of new field devices and the adaption of the manufacturing process in response to unforeseen events (e.g., device failures, changed requirements with respect to resource consumption). The former use case can be handled by the registration of the newly integrated service by means of its semantic description. The latter one is addressed with the context-based rating and selection of services and with the possibility to perform a re-orchestration at runtime (if necessary).

The classical definition, as proposed by [6], describes context as “any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves.” This definition from the field of context-aware mobile computing research needs to be adapted to reflect the different focus of context-awareness in the industrial domain and its use in the orchestration of web services to create flexible production processes: not the interaction between a user and the current application is the most important aspect but rather the production process and the associated task that needs to be fulfilled. All production entities that are relevant to the execution of this task, either by actively participating in the process or supplying relevant input (e.g., material, information) can supply information about themselves, providing the context of the actual process and task.

In an additional processing step, these separate pieces of context information can be aggregated to a so-called situation using predefined knowledge and rules. A situation is always tightly associated with an object and focused on a certain question (situation of X with regard to Y, e.g., “situation of production unit 2 with regard to energy” or “situation of robot cell with regard to safety”). Using situations offers a better way of integrating the contextual information into applications without having to deal with each piece of information separately. Furthermore, the logic of how a specific situation is determined is not implicitly contained in the application’s code but is represented explicitly in a re-usable and extendable ontology.

A dynamic adaptation of a production process to achieve a certain optimization goal (e.g., resource consumption) can only be realized if the actual situation of the process and its components is known in as much detail as possible. Using only information directly from the process often does not accurately represent the actual status with respect to the orchestration goal, leading to not optimal decisions. To achieve this context-based process orchestration a central server (so-called Context Broker) serves as a provider of the context information and the resulting situation made-up by the exact pieces of context information (see Figure 6).

This Context Broker uses different client libraries to continuously call various information sources within the production environment (e.g., via OPC UA), read the enabled variables and store the values in the internal data storage. Applications (in this case the orchestration system) can request the current situation with regard to a certain question by making a HTTP request to the context broker’s RESTful interface. The interpretation component then selects all context information that is relevant to determine the requested situation type from the internal database and inserts the current values into the situation ontology. This ontology contains concepts for all specified situations and rules describing which combination of separate pieces of information make up these situations. Using a reasoning algorithm on the ontology with the current values, the current situation can be classified and served back to the application as a response to the HTTP request. Alternatively, just the set of relevant context information can be sent back to the client for evaluation.

The proposed orchestration system uses the Context Broker as a source of information during the service rating process to yield more accurate results regarding the appropriateness of a concrete web service for a certain process step. In addition, the orchestration system itself subscribes to the interpretation of the current plant situation by the Context Broker. This approach guarantees a tight integration of the orchestration process with the actual physical environment and its status.