## 3 Semantic Service Description and Context-Based Orchestration
### Semantic Discovery and Context-Based Orchestration  
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  
Figure 5: Orchestration system architecture. 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.