In modern Cyber Physical Production Systems (CPPS) workers interact with hybrid networked cyber and engineered physical elements that record data (e.g., using sensors), analyse them using connected services and support decision making, according to the Human-In-the-Loop paradigm. In this paper we present an approach for modelling Resilient Cyber Physical Production Systems (R-CPPS). The approach is conceived as: (i) data-driven, because recovery actions, modelled in a service-oriented architecture, are activated by sensor data measures collected on the CPPS subsystems and the surrounding production environment; (ii) context-based, since recovery services are associated with the steps of the production process as well as with the hierarchical organisation of the CPPS components involved in the recovery actions. The approach provides runtime selection of services, where the sensor data measures are used as service inputs and service outputs are displayed to the operators who supervise the CPPS subsystem on which recovery actions must be performed, enabling fast and efective resilience also in a HumanIn-the-Loop scenario. The feasibility of the approach is demonstrated in a food industry case study.
Cyber Physical Systems (CPS) are hybrid networked cyber and engineered physical elements
that record data (e.g., using sensors), analyse them using connected services, influence physical
processes and interact with human actors using multi-channel interfaces. Examples of CPS
interacting with humans in industrial production are Cyber Physical Production Systems (CPPS),
where workers supervise the operations of industrial work centers, according to the
HumanIn-the-Loop paradigm [
Recipe Ingredients
Dough preparation Kneading machine
Leavening
Baking
Packaging Production line environment
Dough
Biscuits Leavening chamber and
shaping Leavening chamber measures d—u—ra—tio—n—— …
Conveyor + cChoaomkibnegr belt
Cooked biscuits
Packaging machine Conveyor belt measures —————— rpm …
Cooking chamber measures —————— temperature humidity cooking_time …
Packages Environment measures —————— env_temp env_humidity …
In the process, the dough is prepared by a kneading machine and let rise in a leavening chamber. Once the biscuits are ready to be baked, they are placed in the oven. The oven is composed of a conveyor belt and the cooking chamber. By regulating the velocity of the belt through the rpm of the rotating engine, it is possible to setup the cooking time of the biscuits. The temperature and the humidity of the cooking chamber can be regulated as well. Finally, other measures can be gathered at the shop floor level, such as the temperature and the humidity of the production line environment.
In modern digital factories work centers are fully connected, therefore changes in one of them may require recovery actions on the others. For example, an anomaly on the rotating engine of the conveyor belt might cause the cookies to burn and a possible recovery action can be triggered to modify the temperature of the cooking chamber to face a longer cooking time. Similarly, the efects of environment humidity on the dough entering the oven must be considered. Finally, recovery actions sometimes require an interaction with operators (e.g., the substitution of some parts in the production line should be authorised). Therefore, the efects of recovery services should be visualised nearby the involved work centers only, in order to give useful insights to on-field operators who supervise the involved components.
To address the above mentioned complexity of the domain, we propose a service-oriented
approach for modelling R-CPPS, in line with recent approaches for the design of resilient
CPS [
The paper is organised as follows: in Section 2 related work are discussed; Section 3 describes the context model; in Section 4 the recovery services selection procedure is presented; in Section 5 we describe implementation and experimental validation; finally, Section 6 closes the paper.
A recent ever growing interest has been devoted to resilience challenges in industrial plants,
often related with the notion of self-adaptation, as witnessed by an increasing number of
surveys [
Resilience/self-adaptation specifically designed for CPPS has been addressed in [
In Figure 2 we report a simplified schema of the context model to support resilience in CPPS. In the proposed model, the Context is described by the Product that is being produced (e.g., a certain type of biscuits), the production Process (e.g., biscuits baking process) and the Environment Parameters that may influence the production (e.g., the environment temperature and humidity). A Process is associated with Services and is performed by one or more components, that cooperate to successfully complete the production. For example, the biscuits baking process involves the kneading machine to prepare the dough, the leavening chamber to prepare biscuits, the oven to bake the biscuits. Components can be organised hierarchically (according to the hierarchy levels 1..n
0..n
0..n
CPPS 0..n 1 0..n 1..n 0..n 1..n 1..n
0..n 1 1..n 1..n Service 1..n 1 1 1..n 0..1 0..n
dimension of the RAMI 4.0 reference architectural model, IEC 62264/IEC 61512 standards): for example, the oven is composed of the conveyor belt and the cooking chamber. Services represent recovery actions to be executed on a component or the whole CPPS to ensure resilience. A component is supervised by at least one Operator and can be monitored and controlled through a set of Component Parameters (e.g., the oven temperature). Both Environment Parameters and Component Parameters are used to monitor the behaviour of a CPPS in a given Context.
A recovery service is associated with a CPPS (or one of its components) and is described as a tuple = ⟨ , , , , ⟩ (1) where: (i) is the service name; (ii) is the set of input parameters; (iii) is an optional service output; (iv) is the service type; (v) is the component or the whole CPPS associated with the service. Service I/O can be either Component or Environment Parameters.
Flexibility of service-oriented architectures enables to include and dynamically add diferent types of services. For instance, a recovery service may implement the function that relates one or more input parameters with the output one. We refer to this type of service as “re-configuration”. The following service
setOvenTemperature(ConveyorBelt.rpm) → CookingChamber.temperature represents a re-configuration service to set the cooking chamber temperature when the conveyor belt rpm changes, to avoid cookies overheating. When a re-configuration is not an applicable solution (e.g., if the service returns a cooking chamber temperature out of an acceptable range of values), other recovery actions must be applied, such as to replace or repair the conveyor error
warning radius error
OK
OK Paremeter measures warning
bound warning
Upper
bound
error
error
warning
warning
error
belt. An example of “component substitution” service would be the following:
replaceConveyorBeltRotatingEngine(ConveyorBelt.rpm) → void
that has no output parameter to modify. This service is associated with the conveyor belt. Other
service information (e.g., execution cost, time) can be used to guide the automatic selection of
the proper recovery actions. The examples of recovery service types considered here is not
exhaustive and may be extended [
Once an anomalous event (corresponding to a critical condition) is detected on one of the
CPPS components, the event is used to identify recovery services to be applied on the involved
component or connected ones. Recovery services are automatically identified by inspecting
their inputs. In particular, a recovery service is relevant if one of its input parameters has
been classified in the error (reactive resilience) or warning status (proactive resilience), as
summarised in Figure 3. In order to face the volume of data streams collected from monitored
CPPS and to avoid misleading anomaly detection due to noise and false outliers, that may afect
single measures, anomaly detection is performed by applying the IDEAaS approach described
in [
As an example, the setOvenTemperature service is relevant if an anomaly has been detected
on the values of rotating engine rpm in the conveyor belt. Since the service type in this case
is “re-configuration”, the value of the service output resulting from its automatic execution
must be compliant with parameter bounds of the cooking chamber temperature. The relevant
service is then automatically executed to operate on the component or the whole CPPS (for
re-configuration services) or to proceed with a physical substitution of the afected part (for
component substitution services). The system will present all the necessary information to
guide the maintenance operator during the substitution. In fact, we remark that another feature
of the approach is that the information about the recovery actions to undertake, as results of
recovery services execution, is visualised nearby the involved work center, providing insights to
operators who supervise those components, avoiding information flooding towards operators
that may hamper their working eficiency. A prototype operator interface is detailed in [
The approach described in this paper has been integrated with the IDEAaS anomaly detection module and the resulting architecture is sketched in Figure 4. During anomaly detection, the Context Manager is invoked in order to contextualise the incoming data. To this purpose, the Context Manager will provide the following information: (i) an identifier for the context; (ii) a set of parameters, either Environment or Component parameters, to be analysed; (iii) the observed CPPS; (iv) the product that is being produced; (v) the running process. Such information is extracted from the Context Model database.
Collected measures in the context are properly summarised as syntheses by applying IDEAaS data summarisation techniques. Furthermore, syntheses are processed in order to detect anomalies and are stored in the Data Syntheses database. Summarised data are visualised: (a) on the Designer GUI to let the designer monitor the overall evolution of the CPPS; (b) on the Edge Computing Device of the involved component (operator interface), to let the on-field operator to better understand the behaviour of the component. Moreover, when anomalous conditions are detected, the Context Manager is notified with the identifier of the context and the list of critical parameters on which the anomaly occurred, together with their measures. The Context Manager will search for relevant recovery services, associated with the component in the context. Once relevant recovery services have been identified, the Context Manager launches the execution of the services by interacting with the Service Manager, which is responsible for services registration in the Service Repository and for their execution. The result of the services execution is sent to the operator supervising the component.
A proof-of-concept validation of the approach to demonstrate its applicability is being performed. In particular, processing time required to promptly detect anomalies and activate recovery actions services (a potential bottleneck for the whole approach) is investigated. We run experiments on a MacBook Pro Retina, with an Intel Core i7-6700HQ processor, at 2.60 GHz, 4 cores, RAM 16GB. For measures of parameters collected every 200ms, average response time per measure necessary to apply data summarisation and anomaly detection is within 0.12 ms. We also quantified the capability to detect anomalies on the collected measures using the Pearson Correlation Coeficient (PCC) ∈ [− 1, +1], that estimates the correlation between the real variations and the detected ones. In the experiment, the best PCC value is higher than 0.85, that represents an acceptable correlation.
In this paper, we addressed resilience in Cyber Physical Production Systems, where recovery
services are activated by sensor data measures (data-driven) and are selected according to a
context model, that relates services with the steps of the production process as well as with
the hierarchical organisation of the involved CPPS components. A validation of the approach
is being performed on a real dataset that we should pre-process appropriately (e.g., sensitive
information must be removed or anonymised) before making it available to the community as a
benchmark for future work comparison. Future eforts will be devoted to the improvement of
service selection criteria, for example defining a cost model and using simulation-based modules
to predict the efects of recovery actions on the production process, like the one described
in [