Semantic Composition of Optimal Process Service Plans in Manufacturing with ODERU

Purpose Theneed toflexibly reactto changingdemandsandtocost-efficiently manage customized production even for unitary batch size, requires a dynamic and holistic integration of service-based processes within and across enterprises of the value chain. In this context, we present a novel pragmatic approach called ODERU for automatically implementing service-based manufacturing processes at design and runtime within a cloud-based elastic manufacturing platform.


INTRODUCTION
About a decade ago, the fourth industrial revolution, also known as Industry 4.0, has been ushered by the introduction of the Internet of ings and Services into the manufacturing environment.Industry * Dr. Mazzola worked at DFKI during the CREMA project and ODERU development.4.0 is focused on creating smart products and processes exibly in dynamic, real-time optimised and self-organising value chains, and pro tably even down to production lot size of one.To rise up to this challenge, Industry 4.0 applications basically operate on the principles and use of autonomous cyber-physical systems with selfcon guring properties for integrated production across the entire value chain.In particular, the IP-networked and sensor-equipped machinery, systems, vehicles and devices of smart factories are vertically and horizontally integrated with service-based business processes both within a company and inter-company value networks.Besides, cyber-physical production systems are envisioned to not only cooperate with each other but also with humans on a new level of socio-technical interaction.From a holistic perspective, Industry 4.0 connects smart production closely with the areas of smart transport and logistics, smart buildings, and smart energy, while keeping humans in the loop via smart multimodal assistance in modern working environments.e envisioned integration of optimal service-based processes within and across the enterprise of dynamic value chains requires, in particular, smart tool support for an automated generation of process service plans that are optimal with respect to both, functional and non-functional QoS-based requirements at design time and runtime.In addition, the provided process service plans (PSP) should be generated in a way that supports an e ective re-planning at runtime in case an included service is temporarily failing or becomes unavailable.at goes beyond the capability of conventional BPM (business process modeling) systems.
To this end, we developed a novel pragmatic solution called ODERU (Optimization tool for DEsign and RUntime).ODERU computes the set of functionally optimal process service plans based on semantic annotations of executable services and process models, followed by the computation of top-k fully optimal process service plans based on the solving of the embedded COP (constrained optimisation problem) of the process model in extended BPMN.e resulting complete and executable optimal process service plan including the required variable bindings and the environmental variables assignment is encoded back into speci cally developed BPMN 2.0 extensions, thereby bridging the gap between process models and executable process service plans.e remainder of this paper is structured as follows.Section II presents related work, followed by the description of the ODERU solution in terms of the overall architecture, methods and interfaces, and an estimation of its complexity in Section III.Section IV provides an illustrating simple example of using ODERU for optimal composition of process service plans.Section V presents a summary of the use and validation of ODERU in two real-world industrial use cases in the domain of Industry 4.0 that have been adopted in the European project CREMA, and Section VI concludes the paper.

RELATED WORK
At the core, ODERU follows the paradigm of Semantic Service-Oriented Architectures (SemSOA).Process models are automatically implemented with semantic services by applying techniques of semantic service selection and composition planning.e key idea is to enable automated understanding of task requirements and services by providing semantic descriptions in a standardized machine-understandable way by using formal ontological de nitions [1], for example in OWL2 [2].
To apply this paradigm to business processes, several initiatives and approaches exist and reference architectures as well as frameworks for semantic business process modeling are proposed in literature.In [3], the bene t of adding semantics to BPM (SBPM) is discussed, in particular focusing on the modeling and con guration phases.ey propose to make use of semantics to support the modeling in terms of service selection and composition on task level and by means of semantic validation, which enables consistency checks of e ects (e.g. for parallel execution) among others.A more detailed investigation of this aspect can be found in [4].Similarly, service bindings can be found during con guration using semantic annotations.e authors base their methodology on BPMN, BPEL and WSMO.Along the same lines, the authors of [5] propose a similar SBPM framework, which combines semantic web services and BPM to overcome the problem of automated understanding of processes by machines in a dynamic business environment.e idea is to make use of WSMO in addition to standard BPMN to represent the semantics of a business process and its parts.While both works solve the issue of semantic understanding and provides rationale on the bene t of SBPM, there is no integration into existing standards and multiple representations have to be maintained separately.Similarly, the authors of [6] propose sBPMN, which integrates semantic technologies and BPMN to overcome the obvious gap between abstract representation of process models and actual executable descriptions in BPEL.In particular, they propose an ontology, which is supposed to capture all the required semantic information.While this integrates both views, sBPMN is not suited to be used by existing BPMN tools without additional transformation.[7] follows the same track with the proposal of BPMO, an ontology, which partly is based on sBPMN, while [8] takes sBPMN as basis for the Maestro tool, which implements the realisation of semantically annotated business tasks with concrete services by means of automatic discovery and composition.In [9], a reference architecture for semantic SOA in BPM is proposed, which aims to address the representation discrepancy business expertise and IT knowledge by making use of semantic web technologies.e authors highlight the bene t of this approach by showing capabilities emerging from this combination, like semantic process model composition and auto-completion of process models.Like the other approaches shown before, they do not propose an integrated formalism, but rely on their compiler-like framework and semantic plug-in concept to bridge the representation gap.All of these proposals rely on formalizations di erent from (although based on) BPMN or do not aim for a full integration from a formalism point of view.In contrast, ODERU proposes a set of BPMN extensions, which enable semantic interoperability in a semantic SOA as well as support process model composition, task service selection and process execution.
ODERU applies state of the art semantic service selection technologies [10] for implementing annotated process tasks.Typically, work on semantic service selection can be grouped in terms of the selection criteria and the employed matching approach.Functional service matchmaking considers the service signature (inputs, outputs; IO) and service speci cation (preconditions and e ects; PE) [11].Non-functional criteria, o en referred to as quality of service (QoS) (e.g.costs, execution time, availability), can additionally be considered to nd matching services in terms of functional and non-functional requirements [12][13][14].A lot of work has been dedicated to improve on overall matching precision by not only making use of strict logic-based selection of services given formal descriptions of IOPE, but also text similarity metrics and structural computations or hybrid combinations thereof [15][16][17].While showing very good results in terms of ranking precision, such approaches sacri ce the property of correctness with respect to the formal speci cations as implied by logic-based reasoning.is is not feasible for ODERU, because it makes use of service selection as basis for a pa ern-based functional process service plan composition.erefore, ODERU employs a logic-based con guration of the iSeM matchmaker [18], which is capable of IOPE selection given formal semantic descriptions in OWL2 and PDDL [19].Also, the QoS aspect will not be covered by the service selection component of ODERU directly.Instead, optimality in terms of non-functional QoS speci cations is achieved on the process model level by solving (non-)linear multi-objective constraint optimization problems (COP) as an integrated follow-up to the pa ern-based composition, which utilizes the service selection.
Most existing approaches to process service plan composition do not cover the combination of functional (semantic) aspects and non-functional (QoS-aware) optimization, but rather focus on one of them.Naturally, much e ort has been put into the functional composition, because this is one of the basic requirements to compute executable plans.For example, [8,20,21] consider functional semantic annotations to implement business processes by means of a service composition plan.In contrast, some work focuses on optimizing process service plans with respect to QoS. [22] provides a survey giving an overview of existing approaches and initiatives in this direction and highlights research questions.In [23], a novel approach for QoS-aware work ow optimization is presented, which takes structural orchestration components such as AND, XOR, OR as well as loops and unstructured components into account.e optimization is performed by means of Integer Linear Programming, a er a transformation from a non-linear problem to a linear one.Although the approach can extend to arbitrary QoS types, structurally complex and non-linear problems like solved by ODERU can not be tackled appropriately.Integrated functional and nonfunctional optimization has rarely been considered.One notable exception is the work presented in [24], which also claims that existing methods are restricted to prede ned functionally valid plan options.To overcome this, the authors present an integrated SAT-based cost planning solver, which takes logical reasoning and temporal planning into account, while at the same time optimizing QoS respecting a set of global constraints.While composition typically includes the computation of possible data ows, ODERU additionally nds optimal service variable assignments that are also required for executing the resulting plans.is is a novel feature not yet considered by existing work.Moreover, ODERU performs re-optimization of process service plans at runtime upon request by the runtime environment and based on information about the leasability of services, which is also a novel feature.Finally, ODERU employs means of RDF stream processing to react to service changes (non-functional QoS aspects) reported by the service registry.is information can be used to trigger optimizations proactively, if the RDF stream engine identi es that a previously computed process service plan is a ected.

ODERU SYSTEM ARCHITECTURE 3.1 Overview
ODERU integrates semantic process service composition with QoSaware plan optimisation for given annotated business process models in extended BPMN 2.0.at is in compliance with the paradigms of XaaS (Everything-as-a-Service) and SemSOA (semantic SOA).In particular, all available resources are assumed to be encapsulated as executable services which, in turn, are semantically annotated with a shared ontology in the standard ontology language OWL2.e overall goal of semantic service composition by ODERU is to assign semantic services to annotated process tasks in a process model such that the resulting process service plan (PSP) is optimal with respect to the given functional and QoS-based optimization constraints.For an input process model (PM) in the semantically enriched extended BPMN format, ODERU computes an executable plan of services implementing the contained process tasks including information on the data ow between the services.In order to provide an optimal solution out of the computed set of possible functionally valid solutions, ODERU has to make particular choices driven by non-functional requirements, which are expressed as functions of the QoS measures provided by the services.Moreover, ODERU computes concrete se ings of service input parameter values, which yield optimal results in terms of the optimisation criteria.Fig. 1 depicts the role of ODERU in the context of a business process modeling and execution application.A process designer speci es process models in BPMN using a graphical editor front end, that support the semantic annotation of IOPE (Input-Output-Precondition-E ect) aspects for each task.Process models are stored in a database which ODERU can access for its process service planning and optimisation.e generated executable process service plans are encoded in another BPMN 2.0 notation extension into the input PM, creating an instance of this process model, and stored in a repository which is accessible by a process execution environment.Services to be used for planning and later on execution are stored in a service repository.For details of the BPMN extensions used by ODERU, we refer to [25].
e incoming BPMN process models are expected to contain semantically annotated task descriptions as BPMN extension elements, which ODERU can map to logically equivalent or semantic plug-in matching services for execution.Analogous to the semantic service descriptions themselves, these annotations are structured in terms of IOPE and refer to domain knowledge speci ed in a shared ontology in OWL2.Moreover, the BPMN should specify which QoS measures have to be optimized and how they are de ned. is is achieved by specifying a constrained optimization problem (COP) at the process model level, whose solutions dictate which services to select from a given set of alternatives and how to optimally set the parameters for executing these services.e COP formulation includes information on how to map optimal parameter values to service inputs and QoS parameters to COP constants.e outputs produced by ODERU are process service plans encoded in the original BPMN itself by making use of BPMN extensions again.Besides the optimal services and input values for calling the services as described above, this also includes possible data ows with parameter bindings among services.Such a process service plan implementing the process model can then be instantiated at runtime by a process plan execution environment under the following assumptions: • Loop structures are unfolded during execution only, while ODERU assumes that service executions are non-exclusive in general (i.e. a single service can be called multiple times without any side e ect).If a service is exclusive, the execution environment should trigger exception handling and ask back ODERU for a new plan implementing the rest of the process model with other equivalent or plug-in services.
• Gateways are handled by ODERU by computing data ow alternatives for each possible execution path depending on the gateway type.Each possible process execution ow is expressed inside a distinct process service plan.e execution environment should retrieve relevant alternatives from ODERU depending on how the gateways are evaluated.
To achieve this, ODERU works as follows in a sequential manner: • Pa ern-based composition using semantic service selection for all semantically annotated process tasks and computation of possible data ows.• QoS-aware non-functional optimization by means of COP solving on the process model level.is step selects particular services out of sets of functionally ing services per tasks and provides the optimal se ings for service inputs.
is work ow can be applied at design time and runtime of a process model execution instance.At design time, ODERU will be called a er a process model has been de ned in order to provide an executable implementation of the model with services for the execution environment (cf.Fig. 1).
e runtime case occurs as soon as a process service plan is being executed.
e execution environment can request ODERU to provide alternative plans in case of an exception during the execution of process service plan that implements a process model (e.g., when services became unavailable).For this, the plan enacting tool should not only provide the process service plan it tried to execute, but also the current state of execution.at contains information on which services have already been executed, how gateways have been evaluated and what services caused errors during execution.e aim of ODERU in the runtime case is to provide the process execution environment with an alternative solution for the given process instance.at is, it tries to patch the current process service plan being stopped in its execution and considers the current state of the world as xed and not undoable.

Semantic Annotation of Tasks and Services
In order to be able to automatically compose functionally valid process service plans given a process model, we assume process tasks to be equipped with structured semantic descriptions.Following the SemSOA approach, IOPE of tasks are described in terms of formalized ontological domain knowledge.For the use cases described in this paper, we developed a reference domain ontology called CDM-Core [26], which provides OWL2 descriptions of concepts from the manufacturing domain, in particular for hydraulic metal press maintenance and car exhaust production.e semantic annotations are embedded in the BPMN model by making use of extension elements at the task level.
Similarly, we assume that all services come with semantic annotations of IOPE.For this, the W3C recommendation OWL-S [27] is used, which provides means for not only IOPE annotations, but also for the QoS aspect required for the non-functional optimization.QoS aspects are not prede ned in OWL-S, but can be adapted exibly to the speci c use case at hand.De nitions for various QoS aspects are de ned in the CDM-Core ontology (or can be de ned based on it, in terms of extensions) and could for example represent monetary costs of using a service, operation cycle time of a machine represented by a service or cumulated probability of failure.

Constraint Optimization Problem Speci cation
We de ned a context-free grammar COPSE2 to represent constrained optimization problems (COPs) by use of antlr41 (cf.Listing 1).e COP speci cation starts with the de nition of the type of the COP (linear vs. non-linear, single vs. multi-objective, etc.) and continues with the declaration of the problem class.
In this part, the variables, constants and functions are indicated, while in the last segment, any complex function can be de ned using operators such as MAX, MIN, SUM, PRODUCT, and IF-ELSE.
e set of constraints is then de ned with respect to the variables, constants and functions already speci ed, and the objective 1 h p://www.antlr.org/function(s) is normally constructed by minimising one or more functions (or functions combination).In case of a multi-objective, it is possible to have many of them, also in combined form of a MIN-MAX COP problem.
e COPSE 2 grammar also allows to map back the achieved value to the produced PSP into a semantic concept.In the second part of the constraint optimisation problem de nition, the current problem instance is indicated: a er de ning the variables domain and the value of the constants, the mapping of variables values that gives the optimal solution is reported back to semantic concepts used as inputs of the used services.
is approach allows the de nition of complex aggregates of QoS and environment variables instead of mere lists of objectives for simple QoS, extending the expressive capability with respect to the non-functional optimisation problem de nition.In [28], we showcased how this exibility can be useful to represent heterogeneous optimisation problems.

Process Service Planning
e computation of the service plan is presented in Algorithm 1, which uses four helper functions.e rst one is SIM (IOPE A , IOPE B ) in line 11, that is used to compute the similarity between two IOPE annotations based on a selected measure.Given the semantic description of a process task (IOPE A ) and a service (IOPE B ) as input, the adopted measures are the followings: Logic-based signature plug-in match of A with B for Inputs and Outputs: Logic speci cation plug-in match of A with B for Precondition and E ects: ese matching lters are inspired by the classical plug-in matching of components in so ware engineering.While a plug-in match is commonly considered near-optimal, we priorize services with semantic descriptions, which are logically equivalent with respect to the requested functionality.A ranking method for logic-based semantic matching lters is proposed in [29].Alternative approaches to semantic service selection learn the optimal weighted aggregation of di erent types of non-logic-based and logic-based semantic matching lters [30].
A second helper function is the COPsolve (Parameters) used in line 24 for computing a set of Pareto-optimal solutions.is is simply a compiler that transform our COP de nition into a running instance of a JaCoP solver2 , using the set of parameters given.A di erent approach can be anyway reimplemented, if required.
At line 27, the call to ComposeVariableBindings (Solution) computes a possible set of variable bindings, which together de ne the data ow.Bindings are determined by checking the semantic compatibility of the semantic variable types.
is ensures a functionally meaningful assignment beyond simple data type compatibility checking.e overall aim of this function is to connect as many service inputs in Solution with outputs of services prior in the execution order determined by the process model de nition.Inputs which can not be bound in that way are considered environmental variables (see Listing 2 for examples of both cases).is ensures the direct executability of the computed service plan.
Please note, that the pseudo code leaves out details on handling of gateways and di erent possible execution paths through the process model for parallel execution and choices.Without loss of generality, the di erent paths can be considered additional options for generating process service plans, each indicating other gateway decisions and a valid data ow given this decision.ODERU is able to handle parallel (AND), choice (OR) and exclusive (XOR) gateways.While the AND gateway just opens up independent parallel paths and is easy to handle, the XOR and OR gateways result in n and n! possible alternative execution paths, thus widening the problem space signi cantly.Structurally however, all these options are handled in an analogous way to what explained.
Eventually, MergePMwithSolution (PM,Plan) takes care of adding the full metadata section into the original process model to create an executable PSP. is happens at line 31.For this purpose, we rely on functionally equivalent exact or plug-in matches [31] limited to direct subclass relationships, in order to have a PSP whose logical properties (in terms of IOPE) are conserved with respect to the given process model.
In the central part of Figure 2, the set of candidates for each task are presented as dashed areas, in which one or multiple services are inserted in descending order of matching.Multiple process service plans can be produced, each di ering in the followed path and the variable bindings.From this set of functionally optimal plan candidates the top-k plans are computed which are optimal with respect to the non-functional requirements encoded in the respective COP speci cation embedded in the process model.

Non-Functional QoS-Based
Optimization.e lower part of Fig. 2 shows an example of a result of the non-functional optimization step.Amongst all the possible combinations of services in the candidate pools of the process tasks, the best (or Pareto-optimal in case of multi-objective problem) option is chosen as part of the overall solution.at requires the solving of the COP problem embedded in the extended BPMN [25] description of the process model by minimizing or maximing the speci ed objective function(s).An extract of a computed valid process service plan is presented in Listing 2, where the results of the COP solution are listed in the section metadata : optimization : result.Instead, in the section metadata : implementation, the services used for the plan execution are stated together with their input bindings, which ensure optimal execution in terms of constraints and objective functions of the COP.Due to given space limitations, only one service is shown here.Figure 3 presents alternative PSPs, as di erent options for the process implementation due to the presence of an exclusive gateway.
• "F030: Approve optimised process service plan" is provided to support the explicit approval (or refusal) of a newly optimised process service plan by the process designer.• "F060: Find matching services for process step" provides a top-k ranked list of functionally optimal (i.e.semantically most relevant) services that are available to implement a given process step.e semantic relevance computation is based on the hybrid semantic comparison of the semantic IOPE descriptions of process step and available services.• "F070: Retrieve service plans for process model at design time" is devoted to return already computed optimal process service plans generated a er the timestamp indicated as last parameter into the URL (1484056833), with their value of the objective function for a given process model ID. e optional ltering parameter approval allows ltering for the given value of the approval tag (possible values are true , 'false and 'null ).• "F080: Retrieve service plans for process instance at runtime" is devoted to return previous computed optimal service plans a er the timestamp indicated as last parameter into the URL (1484056833), with their value of the objective function for a given process instance ID. e optional ltering parameter approval allows ltering for the given value of the approval tag (possible values are 'true , 'false and 'null ).For example of its usage please refer to the previous function F070.e number of results returned is limited by the optional limit ltering parameter.is function can be useful to support rapid consideration of already existing and pre-optimised plan.• "F100: New Semantic Service Noti cation" is a passive interface used to notify ODERU about the availability of a new service service or the update of an existing one (mainly to be used by the marketplace, for implementing a push approach).• "F110: Notify Removal of a Semantic Service" is a passive interface used to notify ODERU about the removal of a previously registered service (mainly to be used by the marketplace, for implementing a push approach).• "F120: Notify availability of new chunk of RDF data stream" is a passive interface to notify ODERU about the availability of new chunk of RDF data stream , in order to allow the internal RDF component to take it into account (to be used by any generic component that wants to communicate stream of data).It is not a streaming interface, due to the limitation of the HTTP protocol, but it emulates a bucket bu ered stream.
Two helper functions (not in Table 1) simplify ODERU usage: • "H510 -Compose Process Service Plan & Optimise Non-Functional Properties for Process Model at Design Time" helps the user by combining (smart pipelining) seamlessly the two functions F010 and F020 for a given process model, in order to create a process service plan optimised both on the functional and non-functional level in a single step.• "H520 -Compose Process Service Plan & Optimise Non-Functional Properties for Process Instance at Run-Time" supports the user by pipelining, instead, F050 and F040 for a given process instance.

31
] , 32 textual : a report for the intervention ?o1 will be avaialble

Computational complexity estimation
ODERU is envisioned to work inside a cloud platform for elastic manufacturing in compliance with the SemSOA and XaaS paradigms and can be deployed on any number of node.However, in its current version it does not make use of any parallel and distributed architecture, but every instance works as a an autonomous entity, isolated from any other.In the following, we discuss the computational complexity of the ODERU (Algorithm 1) and identify bo lenecks.
3.6.1 Computing the alternative process service plans.We start our analysis with the computation of functionally optimal process service plans, sketching its dependency to the following dimensions of the given problem: • T n is the number of tasks in the considered PM • S n is the number of services registered in the repository • G n is the number of gateways in the considered PM, divided into: -G n P is the number of parallel gateways (AND) -G n E is the number of exclusive gateways (XOR) -G n I is the number of inclusive gateways (OR) We have three main parts: Parsing, Matching, and Paths computation, whose complexity is characterized as follows: Pu ing together the previous equations 1,2, and 3, we obtain an estimation of the complexity as follows: under the assumption that the frequency and cardinality of the inclusive and exclusive gateways is comparable, the previous formula can be simpli ed as follows: To summarize, the implemented algorithm is linear in the product T n * S n of the number of tasks in the process model received and the number of services registered in the repository (due to the matching process in the selection step) and linear with respect to the sum of binomial coe cient 3

#(G n I ) i=1
i for inclusive gateways cardinalities (due to the expansion process in the multiple paths computation step).
In general, it is not possible to determine which of the two aspects has more impact on the complexity, as both depend on the user input.Any set of multiple inclusive gateways with relevant cardinality will dominate, otherwise the product of tasks and available services will determine the computation time for the possible alternative process service plans computation.e presented complexity analysis is valid under the assumption that both the model and the service are correctly annotated in their IOPE pro les.A major issue arises whenever the IOPE is underspeci ed in tasks and/or services, since the semantic plug-in matching of annotated services with tasks is sensible to the combinatorial explosion of number for the possible services task assignment.
3.6.2Solving the embedded COP of the process model.A completely di erent subject is represented by the COP treatment: this is generally independent from the possible alternative process service plan computations.In fact, the user can (and should) design its own objective functions that can refer to any number of tasks and use any number of QoS measures from the services available.Besides, the internal complexity of the optimization library used for the practical COP solving has to be taken into account, since ODERU relies on external libraries for this purpose.In section 5, the two real-world use cases to which ODERU has been applied to clearly show two di erent types of COP formulations: the rst one for press maintenance optimization is concerned with computing the optimal and ranked combinations of maintenance and spare part services for a speci c maintenance process instance, while in the second use case for automotive exhaust production, the COP solving by ODERU is done to nd the optimal input value con guration of a welding robot service with respect to the overall OEE (Original Equipment E ciency) of the production line.

ILLUSTRATING EXAMPLE AND EVALUATION
As an illustrating example of using ODERU for process optimization, consider a process for the manufacturing of a mechanical metallic part, e.g. a brake disk component (cf. Figure 4). is simple process, a er some initial administrative tasks used to retrieve the correct raw material and the production steps, enacts the actual mechanical operation and is concluded by some other administrative jobs that are necessary to associate all the documentation to the produced piece for the delivery to the client, such as the production report and the transportation bill.
In our example, we concentrate only on the process task for the actual manufacturing of the part, as the rest of the actions are only concerned with information management, and the relevant services are normally not the bo lenecks of manufacturing processes.For the implementation of the task 'Mechanical Component', let us assume that there are at least two di erent services available.e rst one, service S A , wraps a CNC (Computer Numerical Control) equipped machine, is able to directly utilise a CAD/CAM 3 binomial coe cient : BC := n i =1 i = n(n+1)  .e composition of these services generate an equivalent aggregate of the S A , from the functional point of view (see Figure 6).In this way, they are interchangable when computing an optimal functional plan implementation for instances.(Computer Aided Design/Manufacturing) model for executing a complex set of operations without direct human intervention.For its semantic annotations, we refer to Figure 6, while the QoS parameters of this service are described in Table 2.In addition, the set of services (S B 1 ,S B 2 ,S B 3 ) implements the three basic operations of bending, drilling and engraving which are required for the mechanical metallic part building.eir semantic IOPE annotations and QoS parameters are shown in Figure 5 and Table 3, respectively.Please note that the service S A is functionally equivalent with the sequence of services (S B 1 ,S B 2 ,S B 3 ) but not with respect to the nonfunctional QoS parameters, as from the extract in Fragment 4.
Let us now formulate the COP for two di erent instances of the given process model: a rst one with an objective function that is dominated by the cost component (i.e: a standard brake disk for economic cars), and a second one where the quality aspect is predominant (i.e: a special part for high range car or a special spare part for tuning purposes).e di erence between both instances relies on the two aspects of the process, the CAD/CAM model and the COP formulation.We de ne the following helper functions (cf.Equations 6,7, and 8): e high-range production COP can then be speci ed as follows: e encoding of the COP for the dual instance of standard production in the COPSE 2 grammar is shown in Listing 4.  4: Comparison of the objective function values achievable in case where the weights generate a con ict in the assignment for exclusive usage services.

QoS
To test the e ectiveness of our ODERU solution, we solved the depicted model using the two instances presented in the previous section.As shown in Table 5, it optimizes the two instances for highrange and standard production using two di erent functionally equivalent implementations, respectively one with a single service S A and the other with a composed service S B , resulting from the composition of the three elemetary services S B 1 , S B 2 , and S B 3 .
In this case, the result is clearly indicating a preferred assignment for each instance, but in case of di erent weights (such as ϕ = 0.8, χ = 0.1, and ψ = 1.0) both instances will be optimized by using the same services (namely, the composition of {S B 1 , S B 2 , S B 3 }) as reported in Table 4. is is, in case of exclusive usage of resources policy, an issue.However, because the value of the objective function is reported, the user is in condition of deciding which instance to make sub-optimal, maintaining the best global result at the intraprocesses level.Despite not being currently fully supported, the development of a specialized module for this is straightforward, given the fact that our current implementation stores all the possible plans (services, sequences, variable bindings and achievable objective value(s)) computed for an instance in a storage facility.

INDUSTRIAL USE CASES AND VALIDATION
IN PRACTICE 5.1 CREMA Platform and Use Cases in Brief e ODERU solution for integrated functional and non-functional optimisation of semantic service-based processes has been developed in the European research project CREMA as an integral part of the CREMA platform for cloud manufacturing.Figure 7 4 provides an overview of all components of this platform together with the interactions between them and with the users, and the data exchanges that foster the business logic.For more information on the CREMA platform and its components, we refer to the the 4 Image taken from the website of the project: h p://www.crema-project.euListing 4: COP de nition for the PM example in COPSE 2 .project website, in particular the "components" page 5 and the appropriate available deliverables.e implemented use case pilots of this platform including ODERU were successfully tested in two di erent industrial application se ings in practice.

Machinery Maintenance Use
Case. e rst use case in the domain of preventive maintenance was concerned with conditionbased optimal maintenance of metal presses with focus on their clutch-brake mechanism without which the presses break down.A special monitoring component continously controls the condition of sensor-equipped press and clutch-brake based on appropriate, expert-de ned rules for critical pressure, cooling, friction disc wear, spring fatigue, and braking angle overshootings.In the event of an alarm, the CREMA system obtains the non-functional constraints such as price, warranty and time from the manager and adds the appropriate functional requirements such as needed maintenance skills, tools and spare parts based on the alarm type.e general maintenance process model for the metal press has to be properly instantiated with optimal services for maintenance assistance and spare part provision for these given constraints.In this respect, the process tasks in the model are automatically annotated based on functional requirements with concepts from shared ontology CDM-Core in OWL2, while the non-functional requirements are encoded as constrained optimisation problem and embedded into the extended BPMN speci cation of the process model instance.ODERU is then used to nd the best process service plan for this 5 h p://www.crema-project.eu/components/process model instance based on available and relevant services in the service repository in the cloud.In fact, the objective is to suggest the maintenance manager the optimal combination of assistance teams and of spare parts with minimal costs and time considering potentially competing assignments and respecting hard and so constraints provided by the client.e manager decides on whether the computed optimal plan gets executed including the tasks of billing and customer feedback at the end othe model instance.

Automotive Use
Case. e other process model guides the production of car exhaust ltering systems, by assembling a set of partially-nished parts with the ing tooling and, eventually, testing the result for product conformity to the client quality requirements.
e most relevant process part for ODERU outcome is the selection of the best matching robot cell and operator skills, in order to maximise the OEE (Overall Equipment E ectiveness).is guarantees that the solution performs optimally with respect to measurements for three main aspects of OEE (i.e: availability,performance and quality), where each one of them represents the fraction of normal (good) machine operation given the maximum possible operation time, taking into account the loss caused by several types of problems, usually called the "Six Big Losses" in literature [32,33].

Validation
Model. e validation of the CREMA use case pilots based on the V-model, which integrates the waterfall model of the ESA Board of So ware Standardisation and Control [34] and the ANSI/IEEE de nition of V&V (ANSI/IEEE Std 1012-2004) [35].e V-model is shown in Fig. 8, where the le part refers to the standard waterfall model of so ware development, while the right part denotes the processes of veri cation and validation.e validation of the use case pilots including ODERU in the CREMA project tasks (T7.3, T8.3) refers to the top-level validation process of this model, namely the user acceptance testing with respect to given user-speci ed functional and business requirements.e integration and system testing was performed during the incremental development process of the CREMA platform components.
e satisfaction of user-speci ed functional requirements by the use case pilot was tested in respective test scenarios and cases with user-de ned criteria of success.e values of business-social performance indicators (BSPI) that were targeted by the industrial user partner for machinery maintenance comply with corresponding user-speci ed business requirements (cf.Table 6): • Up to 60% reduction of unscheduled machine downtimes on customers due to a be er tracking of critical machine components performance.• Up to 50% reduction of the intervention time on customers since GOIZ will be able to manufacture components in advance that need to be replaced.• 25% reduction of intervention costs by a be er coordination between customers, spare part suppliers (GOIZ), and TAS companies.e criteria of success have been de ned by the user partner as well: e targeted BSPI value has been either fully achieved [pass, P] or partially achieved with 5% tolerance [partial pass, pP], or not at all otherwise [failure, F].All BSPIs in this industrial use case signi cantly depend on the capabilities of ODERU to perform its integrated maintenance process optimisation.e BSPIs for the automotive use case together with their achieved status are shown in Table 7 and their success were measured in terms of human expert-based assessments.

Validation
Results. e user acceptance testing of the CREMA use case pilot with ODERU for press maintenance process optimisation was quite successful with respect to the satisfaction of both functional and business requirements.In particular, it succeeded in all test cases during its testing at the FAGOR production site in Spain.From 10 user-speci ed functional requirements with 33 test cases for 12 test scenarios, 10 were completely satis ed (with no partial pass or fail).Notably, the pilot passed 31 (partial pass: 2, fail: 0) test cases completely.In particular, from the 4 user-speci ed business requirements 3 (1, 0) were completely (partially, not) satised.Notably, the corresponding three BSPI values were exceeded with the pilot by quite some extent, while the one BSPI value for the partially satis ed requirement is very close (with less than 1% di erence) to the targeted value.e computed BSPI values that are achievable by using the pilot with ODERU for all selected main types of metal press clutch break faults based on the computation of the relevant costs and times over historical data from 2014 until 2017.In addition, the analysis of the users feedback on the pilot gathered from the test users at the FAGOR site was positive; this was reinforced by the impression of other people to whom the pilot has been demonstrated at a CREMA event.e business validation outcomes are shown in Table 6.
e testing of the second CREMA use case pilot that uses ODERU to optimise the welding process of the car exhaust production line at the TENNECO site in the UK turned out to be quite successful as well: 17 of the test cases were marked as Passed, and 4 were marked as Partially Passed, while none of the test cases failed.In particular, out of 5 functional requirements, 3 were completely satis ed and 2 were mostly satis ed; the pilot passed only few test cases partially.Finally, out of 8 BSPIs, 5 were marked as Passed, and 3 were marked as Partially Passed, while none of the corresponding business requirements was not satis ed (cf.Table 7).
For more details including the test environments of both CREMA use case pilots including ODERU, we refer to the respective validation reports which are available from the project website6 .

CONCLUSIONS
In this paper, we presented ODERU, a novel solution for the semantic composition of process service plans for annotated process models that are optimal with respect to given functional and nonfunctional requirements, and showcased the practical bene ts of its use in manufacturing.In particular, ODERU computes the set of functionally optimal process service plans in two steps: rstly using the semantically best matching annotated services with respect to the process tasks; and cascade, relying on the computation of top-k fully optimal process service plans based on the solving of an embedded constrained optimisation problem of the process model instance, represented in an extended BPMN format.Finally, the user has to decide on the actual execution of a selected complete and executable optimal process service plan by the process execution environment.
e three main advantages of our pragmatical approach are the integrated combination of functional and non-functional optimization, the complete enactability, thanks to the inclusion also of data ow and optimal variables assignment into the plan, and the fast recomputation capability, enabled by the storage of the plan into extensions of the BPMN formalism.
ere are several aspects of potential advancements of ODERU in the future.First, the e ciency and scalability of ODERU may be improved by means of dynamically interleaving both functional and non-functional optimisation.e potentially very large set of computed candidates of functionally optimal process service plans for their subsequent QoS-based optimisation and ranking can result in overall response times that might not be acceptable in practice.Second, the challenge of a proactive event-based triggering of process service plan re-optimization by ODERU could be addressed by integrated means of semantic sensor data stream analysis.Finally, the parallel and distributed computation of process service plans in the cloud based on the model of Hadoop MapReduce [36] 7 could speed up the optimisation process of ODERU as well.
e actual version of ODERU is publicly available for download in form of a Docker [37]

Figure 1 :
Figure 1: ODERU in a BPM and execution architecture

Figure 2 :
Figure2: An example of the combined functional and non-functional optimized process service plan: the sequential selection and composition process is shown: for each task all functionally equivalent services are assigned, and then amongst all the possible combinations, the best one is selected based on the result of the COP solving.In case of a request with multiple objectives, one of the Pareto-optimal solutions is returned.Each process service plan is equipped with the relevant variable bindings and optimal service input values for execution.

Figure 3 :
Figure 3: Alternative branches e ect: Two possible instances following di erent paths for the same process models are depicted, as part of the computed solution from ODERU.

Figure 4 :
Figure 4: e Disk Brake example production model used.

Figure 5 :
Figure 5:e IOPE semantic annotation for the services S B 0 (Extract Required Operations), S B 1 (Bending), S B 2 (Drilling), S B 3 (Engraving).e composition of these services generate an equivalent aggregate of the S A , from the functional point of view (see Figure6).In this way, they are interchangable when computing an optimal functional plan implementation for instances.

Figure 6 :
Figure 6: e semantic IOPE annotation of the S A service based on an ontology O#

Figure 7 :
Figure 7: ODERU in context of the CREMA execution architecture.

Figure 8 :
Figure 8: V-model Algorithm 1: e pseudocode for the process service plan composition Input: PM: a semantically annotated BPMN model Input: S: the set of available services from the repository parameter : Sim min : minimal similarity value accepted Output: PSP: the computed process service plan 1 % Preparing the data structure 2 forall s ∈ S do 3 IOPE s → IOPE S ; 11 if SI M(IOPE t , IOPE s ) >= Sim min then 12 s → CAN DIDAT ES t ; 17 forall t ∈ T do 18 forall s ∈ CAN DIDAT ES t do 19 forall QoS ∈ T do 20 QoS → Parameters s t ;

Table 1 :
e RESTful interfaces of ODERU (all the URL are pre xed by the ODERU deploy address, e.g: h p://ODERU.example.org/).ird and forth columns represent JSON encoded payload and JSON answer payload.All the IDs refers to repositories.

Table 3 :
e QoS measured for the three basic services (bending, drilling, engraving)

Table 6 :
8self-contained image under AGPLv3 license at h ps://oderu.sourceforge.io/.Business validation results for di erent BSPIs of the CREMA pilot use case "Machinery Maintenance".e last column evaluates the relevance levels of the ODERU process optimisation for this use case of machine maintenance.B5 CREMA controls products movement to Area, avoiding that wrong products are sent to the client.P -UC2-B6 CREMA messages the operator with instructions about next steps, helping avoiding human errors.

Table 7 :
Business validation results for di erent BSPIs for the pilot of the CREMA use case "Automotive".elast column evaluates the relevance levels of the ODERU process optimisation for this use case of car exhaust welding.agreement637066, and the German Federal Ministry of Education and Research (BMBF) in the project INVERSIV.