## 3 Semantic Service Description and Context-Based Orchestration
### Context Interpretation for Service Rating and Selection  
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  
Figure 6: Structure of Context Broker used by orchestration system. 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.