A Retrofitting Framework for Self-managed CPS WfMSes

tions, e. g., as shown with our case study in the smart home domain (cf. Chapter 7). More real-time and safety-critical feedback loops in CPS workflows (e. g., for verifi- cation and adaptation in the automotive domain [KGC+12]) have to be more tightly integrated into the corresponding control applications or WfMSes due to possible performance issues with a dedicated SOA-based software component. Goals can still be used to define expected and undesired outcomes for these self-managed sys- tems/workflows [KM07]. A more detailed discussion with respect to the support of time-critical behaviour as well as safety and security-related aspects to be consid- ered in feedback loops and supported by our approaches are given in Sections 7.6.9 and 7.6.10. An extended evaluation of the Feedback Service’s performance in the case of executing multiple feedback loops for multiple process instances and an in- vestigation of their mutual influences have to be part of future work when applying the workflow feedback loops to other CPS domains.

6.12. A Retrofitting Framework for Self-managed CPS

WfMSes

In Section 3.2 a variety of existing WfMSes from industry and academia is presented briefly. Despite a wide variety BPM systems being already used in different contexts and domains, only a few systems possess capabilities that allow self-management to a certain degree. With requirement R8, we identified the need of adding these capabil- ities to existing WfMSes as there are already many systems deployed in industry and academia. In the following, we discuss different ways of Retrofitting existing legacy WfMSes with capabilities towards enabling the self-management of CPS workflows using MAPE-K loops implemented by the Feedback Service [SHA18a].

6.12.1. Retrofitting Process

The main purpose of most existing WfMSes is to enable service orchestration across (enterprise) applications and systems. The WfMSes investigated in Section 3.2 rely on SOA principles to find and invoke external or internal web services. With the Feedback Service as a dedicated web service providing a RESTful service interface to be invoked from within a process or another service, the integration with other WfMSes and existing worfklows is straightforward. The MAPE-K approach serves as basic retrofitting framework. We distinguish between Invasive Retrofitting and Non-invasive Retrofitting with and without the use of Consistency Style Sheets. Invasive Retrofitting

The invasive way of retrofitting legacy WfMSes comprises modifications to the un- derlying workflow metamodel as well as to the internal execution processes of the WfMS. An example for the invasive retrofitting of the basic PROtEUS workflow system is shown in this thesis regarding the modelling of CPS workflows (cf. Sec- tion 4.5) and managed process steps in general (cf. Section 4.5.2), and regarding their execution (cf. Section 6.2). The basic process step classes of the workflow metamodel (activities, subprocesses, processes) have to be extended with new at- tributes or classes to specify goals and objectives as described in Section 4.5. The

corresponding workflow IDE should be adjusted accordingly to provide the designers with the possibility of modelling goals for specific workflow activities and process steps. When executing a (managed or cyber-physical ) process activity augmented with a new goal, the workflow engine has to issue an additional parallel service call containing the relevant goals to the Feedback Service.

Figure 6.10 shows the process of executing a CPS activity by a retrofitted legacy WfMS. Upon executing an instance of the CPS activity or subprocess, its goal is extracted and used as parameter for an implicit parallel call to the Feedback Service. The Feedback Service then executes the MAPE-K feedback loops during the execution of the CPS activity to analyse context data with respect to the defined satisfied and compensation conditions, and to try to reach the goal. The service response including the state of the fulfilment of the goal is reported back to the WfMS. In case of errors or the Feedback Service not being able to fulfil the goal, the workflow system’s internal error handling mechanism or associated process failure branches have to be activated.

Figure 6.11 shows the execution of a CPS activity by a retrofitted WfMS using a Consistency Style Sheet, which contains the goal definitions for the process (cf. Sec- tion 4.7). In this case, the particular Consistency Style Sheet is already known by the Feedback Service as it was submitted by the process designer to the service be- fore. The implicit parallel request invoking the Feedback Service in parallel to the basic process step then only needs to contain the respective process step identifier. The Feedback Service links this identifier to the corresponding goal from the style sheet and executes the MAPE-K loops as described in Section 6.2 in parallel to the “basic” workflow activity. By using the style sheet mechanism, the “original” workflow needs to be only minimally modified by adding a flag that indicates if the Feedback Service should be called for self-management.

Legacy WFMS

CPS Activity/ Subprocess

Feedback Service Call

Goal from P rocess Step _{Goal State}

Feedback Service

Service Request

MAPE-K Check and Try to

Reach Goal

Service Response

Figure 6.10.: Retrofitting Process for Existing WFMSes with Self-* Capabilities via the Feedback Service.

Non-invasive Retrofitting

The non-invasive way of retrofitting involves extending existing process models with explicitly modelled additional activities to call the Feedback Service. It does not re- quire modifications to the workflow metamodels or engines–compared to the invasive

6.12. A Retrofitting Framework for Self-managed CPS WfMSes Legacy WFMS CPS Activity/ Subprocess Feedback Service Call Generate from

Process Step ID Goal State

Feedback Service

Consistency Stylesheet Service Request

Match Process Step

ID with Goal Lookup

MAPE-K Check and Try to

Reach Goal

Goal

Service Response

Figure 6.11.: Retrofitting Process for WFMSes with Consistency Style Sheets.

retrofitting. As the invocation of the Feedback Service is a simple additional service call, the WfMS’s metamodel element for modelling a service invocation within a process and the WfMS’s internal mechanism for calling the specified service can be used. The Feedback Service Call process activities shown in Figures 6.10 and 6.11 can be viewed as explicitly modelled process activities to be executed in parallel to the activity/subprocess to be managed. Goals and process instance information can be specified as input parameters for the service call to the Feedback Service. This service call then only has to be modelled as an additional process step to be executed in parallel to the “original” process activity that should be managed by the Feedback Service. The Consistency Style Sheets can be used similar to the invasive retrofitting as shown in Figure 6.11.

Invasive vs. Non-invasive Retrofitting

The invasive retrofitting process requires more modifications to the existing WfMS and its underlying metamodel. However, it provides a more intuitive integration into the existing WfMS and process landscape. Only a few new properties have to be added to the existing workflows. The workflow IDE can help to assist the process designer with specifying the goals of the managed process activities. As not all WfMSes are open source software or easily modifiable, this approach may not always be feasible to be implemented, though.

On the other hand, the non-invasive retrofitting approach requires more modifi- cations to the existing process models and is less intuitive w. r. t. the modelling of a workflow as new process activities have to be added to the existing processes, which increases the complexity of the process models and possibly leads to concurring or blocking process executions due to the communication with the Feedback Service in parallel. However, the additional process steps and modified processes are still com- patible with–but also limited to–the original WfMS and workflow language. Within the invasive retrofitting approach, modifications to the execution behaviours can be more diverse and less complex to realize in case adjustments or special process exe- cutions are required for specific use cases. Within the invasive approach, developers and process designers are limited to the expressiveness of the underlying workflow notation and to the capabilities of the corresponding WfMS.

6.12.2. Application to Existing WFMSes

The necessary steps for the invasive retrofitting process to add the capability of self- management to WfMSes are shown throughout this thesis–especially in Sections 4.5 and 6.2–for the basic PROtEUS WfMS. In this section, we briefly discuss the appli- cation of the non-invasive retrofitting approach to three of the existing open source WfMSes presented in Section 3.2. With Activiti, the YAWL Engine and Apache ODE, we have three complete WfMSes that use different underlying workflow lan- guages, namely BPMN 2.0, YAWL and WS-BPEL (cf. Section 2.3.3). For all three WfMSes we show the retrofitting process of modifying the “basic” process with an additional service invocation containing the particular goals as parameters to call the Feedback Service in parallel to the invocation of the IoT (openHAB) middle- ware service for switching on the lamp in the Morning Routine scenario process. The results of the corresponding experiments using the three legacy WfMSes in combi- nation with the Feedback Service in a non-invasive way and using PROtEUS with the Feedback Service in an invasive way to execute the Smart Lighting processes can be found in Section 7.5. Smart Ho me FBSInvoke LightInvoke input

Start process End

Figure 6.12.: Retrofitted Smart Lighting Process with Activiti.

Activiti Figure 6.12 shows the basic smart lighting process from our running exam- ple augmented with the additional call to the Feedback Service in BPMN 2.0. The input process step is used to provide input parameters. The basic process activity is the LightInvoke service task to call a custom service deployed on the Activiti system to trigger the dimmer switch via the openHAB middleware. In parallel, the invocation of the FBSInvoke service task calling the Feedback Service with the goal parameters to execute the MAPE-K feedback loops is specified. Activiti relies on intermediate services that are locally deployed for executing external functionality. In our example, these services are custom implementations that delegate the calls to the actual RESTful services provided by the IoT middleware and Feedback Service. YAWL Engine Figure 6.13 shows the basic smart lighting process from our running example augmented with the additional call to the Feedback Service in the YAWL notation, which is based on Petri nets [vdAtH05]. The YAWL system also relies on custom services that are deployed in a local repository to execute functionality and invoke other external applications. We implemented custom services for each step of the process. The input and output services print input and output parameters for debugging purposes. The LightInvoke step is the basic process activity that calls the

6.12. A Retrofitting Framework for Self-managed CPS WfMSes

Figure 6.13.: Retrofitted Smart Lighting Process with YAWL.

openHAB middleware delegated via our custom service to activate the light dimmer. The FBSInvoke service is the “retrofitting” process step that invokes the Feedback Service delegated via our custom service in parallel. Goals are provided as input parameters for the FBSInvoke call. YAWL uses SOAP as internal communication protocol. We see that also with the YAWL system, additional custom services need to be implemented and deployed locally as intermediate services to call the external services. PROtEUS shows advantages with this regard as it as able to invoke external RESTful and SOAP-based web services directly.

Figure 6.14.: Retrofitted Smart Lighting Process with Apache ODE.

Apache ODE Figure 6.14 shows the basic smart lighting process from our running example augmented with the additional call to the Feedback Service in graphical

WS-BPEL notation. The first process step is used to receive input data and as- sign it to the following service requests. The LightCall branch on the right side of the process contains the assignment of input parameters to the following basic LightInvoke step, which calls a custom service to then call the IoT middleware to switch on the light. In the parallel FBSCall branch, the FBSInvoke process step invokes a custom service to execute the MAPE-K loops via the Feedback Service with goals provided as input parameters from the previous process step. The replies are provided as output parameters. Similar to the previous examples, Apache ODE assumes SOAP-based communication with external services. It requires a WSDL description of the respective service requiring us to also provide intermediate services to delegate the service calls to the actual REST-based services of the middleware and Feedback Service.

6.12.3. Limitations

The examples for non-invasive retrofitting of the existing WfMSes show that usu- ally only one additional process activity is required to add the capability of self- management based on the MAPE-K framework to individual workflow steps. How- ever, the focus of most of the existing WfMSes is still on the SOAP-based invocation of custom services to implement a company’s business processes and integrate en- terprise applications. In contrast to that, the IoT and CPS increasingly rely on more light-weight service implementations and communication based on the REST protocol [GIM11]. This technology is also one the basic principles of the IoT mid- dleware (cf. Section 5.3) and Feedback Service (cf. Section 6.2.1) to provide service based remote APIs. For that reason, we have to provide and deploy intermediate services to enable the communication between the SOAP-based WfMSes and the RESTful IoT services. A better support of direct REST service invocations would be a desirable feature for future developments of these WfMSes. The PROtEUS system already supports this kind of service calls. An alternative would be to add support for the more heavy-weight SOAP protocol to the existing IoT services and Feedback Service, which would probably be not always feasible due to resource con- straints. In general, we assume that WfMSes are capable of service invocations and parameter passing to apply the MAPE-K framework for self-management with the help of Feedback Service, which is a dedicated standalone web service. In case the workflow system is not capable of establishing a service-based communication with the external Feedback Service or stricter performance requirements, the Feedback Service has to be integrated as additional software component and coupled more tightly to the basic WfMS as internal component. Running the Feedback Service as external micro-service introduces additional overhead due the hosting, operation and communication costs for the service.

Software or process engineers have to decide about which retrofitting process to choose based on the impact of the retrofitting process–either extending the meta- model and execution behaviour of the “basic” WfMS or extending the existing pro- cess models, which would maintain compatibility with the original WfMS. The selec- tion of an appropriate “basic” WfMS depends on features and properties the WfMS has to provide and fulfil (e. g., formal verification or scalability) in the respective application domain or enterprise.