Keywords

1 Introduction

Cyber-Physical Systems (CPSs) represent a new paradigm to describe the close interrelationship between hardware and software components. One motivation for this interconnection is to bring intelligence and smarter functionalities into traditional, hardware-dominated application areas such as embedded systems, robotics, or system networks [1]. As an example, this contribution considers the practically relevant area of Production Automation which can be seen as early CPSs [2]. The most important part to reach the full dimension of CPSs is to integrate communication and information gathering capabilities that allow pursuing goals and functionalities on a global system level [3]. In contrast to that, in traditional production systems information is often not easily accessible. Because here the overall knowledge is only implicitly available in the respective control code as well as the hardware setup. This is a result of the industrial practice to often use only informal specifications for implementing system control [4]. Plants are long-living and constantly evolving over their live span. Therefore, documentation is nearly never up-to-date, which complicates (or even prevents) the task of analyzing the production system [18]. Since, however, each production system is based on the respective companies’ application requirements, it is desirable to make the system analyzable regarding its requirements only by itself. Here, services allow gluing the physical production process together with software-driven capturing functionalities. Further, functionalities captured in services allow forming a self-documenting process as proposed for the need of evolution support in this contribution. Correspondingly, the aim of this contribution is to tackle the lack of documentation with service-oriented methods to integrate production systems into the future world of smart CPSs.

The paper is structured along three questions: (Q1) How can the behavior of joint dynamics between software and hardware be captured in evolvable service-components? (Q2) Can these service-components provide a basis for reducing the lack of documentation? (Q3) How can a comprehensive process for self-documenting be implemented by assembling reusable services? To address these questions, a service-component architecture is presented which is based on event-based monitoring in autonomous service-components. First, the problem of a consistent system state in service-components of a CPS in general and a production system in particular is addressed. Following that, the paper shows how domain-specific models are captured in and managed by service-components to represent the combined hardware and software behavior. Finally, the paper shows how these service-components can be used to implement a self-documenting process. The approach is evaluated by two case studies which demonstrate the proposed concept. Related work and a conclusion close the paper.

2 Service-Oriented Knowledge Management in CPS

The understanding of a CPS is not clearly defined and various kinds of definitions from different domains exist. In this contribution, the architecture for a smart service-oriented CPS is presented based on Sztipanovits et al. [5] who define CPS in three different layers: As shown in Fig. 1, the lowest level is the physical connection layer which consists of physical components and their interactions. In production systems, these are mechanical parts which are pneumatically (thick lines in Fig. 1) or electrically (dashed lines) connected. The other two layers are the cyber layers: first the cyber connection layer which consists of software components embedded in the hardware system. In terms of production systems these are the execution environments and their software code of Programmable Logic Controllers (PLC) which are connected by bus-systems. To control the plant, events of actuators transfer the code behavior into physical behavior while events of sensors transfer the physical results back. The last layer is implemented in ordinary software languages (e.g. object-oriented languages) and capable of CPS functionalities (e.g. network communication). In this paper this layer focuses on smart functionalities of CPSs and especially self-documentation. It is further named the knowledge carrying software layer.

Fig. 1.
figure 1

Service-component architecture for smart CPS

Full size image

For self-documenting, the CPS architecture follows the general guideline from Robinson for a requirement monitoring system [6] by applying it to CPSs and the service-oriented world. Accordingly, the knowledge carrying software layer consists of the event, model and application layer as shown in Fig. 1. Within the event layer events are acquired, (pre-) processed, and stored in a state service (Sect. 2.1). Due to the interdisciplinary interactions of the underlying process in case of a CPS, the model layer holds domain specific models in knowledge service-components to determine process properties (Sect. 2.2). The application layer contains application specific components and is in this contribution discussed with respect to the targeted application of a self-documenting process for evolution support (Sect. 2.3). The visualization layer of Robinson is not discussed here. In a nutshell, this contribution proposes a service-oriented component architecture that captures behavior in models on top of traditional hardware systems so that they become smart within a service-oriented CPS.

2.1 Service-Oriented Event Acquisition in Heterogeneous CPSs

To follow compositional design architectures, elements should communicate homogeneously regarding their composed properties and semantics [5]. But unfortunately, CPSs differ in structure and behavior rather heterogeneously [5]. In addition, production systems are generally written in domain specific languages and always run cyclic in their own program thread and under hard real-time conditions. This implies that only event sequences are shown as an interface towards the upper CPS cyber levels and the actual execution remains as a black box. These facts and the general conservatism of the production industry make it problematic or even impossible to couple the component of the production process directly with the CPS by weaving code into the controlling software like most other monitoring approaches propose [6]. From the authors’ point of view, this difficulty of external access holds for many other domains of CPS as well. Therefore, this paper proposes a service-oriented approach which captures information of event sources externally in a non-invasive way.

Since smart functionalities often require a high level of autonomy, the proposed architecture is based on active service-components (see [7]). In a CPS view, active components are software representations of (hardware) entities which are managed and defined like hierarchical components that communicate with each other via service calls and provide a flexible internal architecture to act autonomously [7]. For event acquisition, the architecture distinguishes between two types of components:

First service-component adapters (SCA) are deployed in a 1-to-1 mapping per available entry points of the CPS (see Fig. 1). They allow event sources to participate in the CPS by providing services within the event-acquisition. These services behave as proxies that allow for a transparent access to the connection layers and encapsulate the generation and propagation of events. To allow a high degree of freedom, they operate autonomously by actively establishing and managing connections to the connection layer with domain specific technologies like process control protocols. Further also pre- and post-processing steps like caching are done. In CPSs it is important to decouple the different layers − although it might affect the performance. Consequently, the utilization of provided service- components reduces the complexity in terms of crosscutting interactions between the layers. Services allow cyber components to browse and register for events out of the event layer. Further, the architecture decouples the rate of the events provided into the CPS (desired rate) with the rate coming from the connection layer (source rate) inside the service. Note that this decoupling implies the assumption that values do not change between two measured events according to the source rate.

The second type of components in the event-acquisition layer are representation service-components (RSC). As shown in Fig. 1 the separately deployed RSCs are in charge of the consistent system state by requiring the services of the SCA. All RSCs in their hierarchical order are further called the system façade. RSCs can run in different computing nodes as SCAs, because in contrast to SCAs, the upper cyber layers of CPSs should follow a business-oriented modularization. Such a modularization can be made per technical resources, but can differ by following, e.g., a business process. Nevertheless, for a consistent system façade each RSC must be responsible for a separated part of the system to have a clear responsibly chain on the cyber layers.

2.2 Domain Specific Models for Joint Dynamics in Service-Components

In complex systems – especially with hardware relations – models play an increasing role for different phases of the lifecycle as Derler et al. stated also for CPSs [1]. Therefore, the employment of models is also necessary for service-oriented CPSs that implement smart functionalities at runtime [2]. For CPSs, generally models of the behavior are considered [1]. The heterogeneity and complexity of these models stresses modeling languages of CPSs [1] and therefore it is problematical to find a uniform architecture to integrate such models. To tackle this difficulty, this paper proposes to encapsulate each model in its own design architecture and execution environment that is only accessible by services. These so-called knowledge service-components (KSC) can exist on each hierarchical level of the system façade as shown in Fig. 1. KSCs describe the CPS behavior and determine high-level properties. The event-acquisition in RSCs and the models in KSCs must be operated by services together. For such an event-based service system this contribution establishes an approach on policy-based evaluated statements for service calls. These statements consist of three parts:

  1. 1.

    Each statement has a state expression which is based on the state service of the RSC. An expression of a service call may consume several events, and the RSC computes the expression’s value. Expressions are evaluated within the RSC to guarantee that evaluation takes place in the safeguarded system facade.

  2. 2.

    Statements use matchers for expressions that check the expression value against a desired result. An expression value is only returned to the service caller when the matcher returns a positive result.

  3. 3.

    Since the evaluation is separated in the RSC and the time when the statement is fulfilled is unknown, statements have an evaluation policy. Policies determine an interval for the evaluation of expressions. This means the RSC asks the policies when the next evaluation should take place by scheduling a task to evaluate and match the expression when a new and consistent state of involved events is available. Intervals can be linear, accelerating or decelerating towards a deadline.

In conclusion, models in KSCs define a pool of statements described by event expressions and transfer them with a policy and matcher to a RSC. An approach that can also be used as an alternative to the often-used pull principle in other event-based domains. For example, test cases of events which occurrence time is unknown can be better defined by this approach. Returned values of statements are processed by so-called mode services that determine how statements can affect a KSC (see Fig. 1). This contribution proposes a not necessarily complete list of four mode services:

  1. 1.

    Learning services provide learning mechanisms within the KSC execution environment which build up the model. Although simpler models like algebraic functions may not require learning, complex models must use learning algorithms.

  2. 2.

    An observation service describes how a model acts during live observation. This is necessary whenever the KSC has statements of the current system state and wants to reflect this state in its model. Further anomalies which are differences between the model and the actual observed state seen in the system can be detected here.

  3. 3.

    An analysis service describes how high level properties necessary, for example, in the self-documenting process are determined based on the model structure and state. Here the advantage of model-based service-components for CPSs shines since formal properties can be expressed as services that can be determined automatically.

  4. 4.

    The last simulation service is the most optional one and can be used in addition to the analysis. Simulation allows the KSC to predict the behavior of models in terms of already observed situations. Therefore, often observed usage scenarios are extracted to replay these scenarios to evaluate the model in typical situations.

2.3 Self-documenting Process for Evolution Support

As an application example, this section shows a self-documenting process for evolution w.r.t non-functional properties. The process is shown in Fig. 2 and allows tackling the problem of constant evolution in long-living systems which often results in non-documented behavior and unknown system properties [18]. To support evolution, event traces of the system are monitored. As a side note, also events from test cases can be used here (see [17]). To provide analysis, events must be enriched with a machine interpretable semantic context. For example, for production systems, each event holds an assigned event-context identifier for the topology and the type of events in a tree structure. The topology part describes from which system part an event stems. The type part tells which information it gives. The behavior is documented in the RSC hierarchy that holds KSCs which consume timed events in mode services as shown previously. When the observation service detects changes, a human in the loop decides if the behavior is desired or undesired. Desired changes are considered as an evolution and undesired as an anomaly. The models are analyzed to find high-level information of the technical process, e.g. invariants of events or (non-functional) properties. Further, simulation of usage scenarios can be used for analysis. In general, the process actively reduces degeneration of documentation by coming from an undocumented system to a system which is documented by a model-based specification.

Fig. 2.
figure 2

Evolution support process to document behavior of production systems

Full size image

The self-documenting process is demonstrated in this paper, but the service-component architecture can be extended to other functionalities. These functionalities are situated in the application layer. To implement the process RSCs are extended with a management service-component (MSC) (see Fig. 1) that also communicates via services. When considering CPSs with high dynamics, a robust goal-based approach seems most favorable. This preference results from the fact that the process is, in general, based on priorities of the mode services whose priorities depend on the current condition of the underlying system. For example, the observation mode is continued until a change occurs and learning is necessary. One suitable architecture is a “goal-based approach with deliberation according to priorities” following a Belief-Desire-Intention architecture [8]. The main goal hierarchy (omitting plans, beliefs, and smaller goals) is shown in Fig. 3 (left). The overall goal to ensure documentation is enhanced by sub-goals for mode services of the KCSs. When a specific condition is fulfilled, a goal deliberation takes place and other mode services can suppress the current service. In this way, the most needed service is always activated. Human interaction is included for decisions. This semi-automated approach is chosen because of domain restrictions, but could also be substituted by adding additional service-components.

Fig. 3.
figure 3

(left) Goal hierarchy of the process; (right) components and services view

Full size image

3 Evaluation

To evaluate the concept of a smart service-oriented CPS two case studies are performed: one demonstrates the ability to handle hierarchical event sources and the second applies the incremental documentation process for evolution support. The respective prototype was implemented in Java based on active components of the Jadex platform [7]. Main components and services of the prototype are shown in Fig. 3 (right). The plant connection is done with the industrial M2M standard OPC implemented in a SCA that communicates with RSCs via event services implemented within a stream-oriented programming style based on the Jadex “Future” concept (see [7]). To ensure consistency in the system façade, RSCs follow the BASE principle (for: basically available, soft state, eventual consistency) by using the timestamps of the connection layers. Each component holds a configuration and RSCs hold the analyzed properties of their corresponding plant part. MSCs extend the RSCs via extension services by managing the self-documenting process with an implementation based on the BDI-Kernel of Jadex (see [8]). KSCs have one of two domain models developed to ensure a high degree of expressiveness w.r.t documentation (see [18]). The models are implemented as petri-nets in the Jadex micro-kernel and communicate via state service to the RSCs and via mode services implemented for both models to the MSCs.

  1. A.

    Case Study: Hierarchical Distributed Production System

For evaluation of hierarchical CPSs and distributed event sources, a laboratory plant on the Helmut-Schmidt University was used. It consists of three distinct producing machines, an arm robot, a high rack storage area and a portal crane. An intra-logistics transport system of conveyor belts divided into five subsystems connects the elements. For self-documenting purposes, models for machine states are used in the learning services (see [18]) to create models expressing the state of subsystems. Each RSC creates its own separated state model. Regarding documentation, the case study considers the nominal capacity of the logistic system for each conveyor, subsystem and whole plant as a non-functional property. The analysis service uses a formal algorithm specified on the domain state model and combines the capacity of the whole plant on the parent RSC by an aggregation formula. The results are shown in Table 1. The service-oriented CPS shows that it can ensure a consistent hierarchical system view, because the properties and a detailed formal model documentation are constantly reflected in services. Such properties bound to documenting service-components are useful by themselves, because otherwise they are, if at all, only manually determined.

Table 1. Results of the experiments regarding capacity
Full size table
  1. B.

    Case Study: Evolution of a manufacturing system

A second case study was conducted on a Pick-and-Place-Unit (PPU) at the Technical University in Munich (see [9]). The PPU serves as a demonstrator for automated production plants under evolution. It is capable of processing different workpiece types, namely metallic and plastic workpieces. Metallic workpieces are to be processed by stamping them. The PPU consists of four parts: (1) A magazine that provides workpieces to be processed. (2) A stamp that stamps metallic workpieces. (3) An output ramp for releasing workpieces from the plant. (4) A crane which connects the other plant parts. Evolution scenarios built up the PPU consecutively (names according to [9]). In scenario Sc1, the PPU just consists of the magazine and the crane which is extended by workpiece identification in Sc2. In Sc3, a stamp is added for metallic workpieces and the last considered Sc5 tries to optimize the throughput by a modified crane behavior. In comparison to the previous case study which captured the machine state of the system, here the actual routing of products is captured by filtering events according to the assigned context semantics (see [18]). This case study demonstrates that the self-documenting process based on the RSCs can be fully implemented. The resulting petri net is shown in Fig. 4. Every scenario is presented in different line types. Timing information is shown whenever it changes (just in Sc5). Identifying events are shown in braces. The self-documenting process detects changes in the observation service and then relearns the model per new scenario. The model shows how the KSC prepares the documentation for an engineer and that he is able to analyses the system evolution with formal petri-nets which are often used in the industrial context as documentation.

Fig. 4.
figure 4

Routing petri-net of scenario 1, 2, 3 and 5 of the PPU case study

Full size image

Every time the KSC changes, the process demands an analysis on the model structure. Table 2 shows the result of some typical properties. Here, the benefit of constant relearning in service-components can be seen, because improvements and influences of evolution can be directly inspected. For example, it can be easily seen that Scenario 5 does not improve the mean transportation time as stated in [9] and only reduces the standard deviation. Further on, also the reason for this lack of performance which is a low horizontal crane speed is reflected in the routing model of the KSC. Overall the case studies verify the answers to the given questions of this paper. Because they show that evolvable service-components can encapsulate knowledge of CPSs in models (see Q1) and serve as a documentation for the engineer (see Q2). And the composed self-documenting process of this services (Q3) allows the service-oriented CPS to identify that the evolution change have failed and should be reversed.

Table 2. Results of the incremental analysis
Full size table

4 Related Work

This contribution provides an approach which combines different methods. One way for processing event-traces is complex-event-processing (CEP). As one example, Michelsen proposes data stream processing in decentralized networks [10], but as other CEP approaches do not consider acquisition based on complex models. This is also the case for approaches which use learning techniques to find dependencies between events. Margara, for example, generates rules for event dependencies by using historical traces [12]. However, general approaches for (distributed) event-based system normally rely on query languages and mathematical aggregation and result in event rules. They do not consider the wide range of models needed for CPSs, nor do they consider models in service-components. Runtime monitoring is a commonly used method. An overview is given in [13] and for CPSs it is shown in [14]. Most monitoring approaches of CPSs try to tackle the problem of how provided specifications can be used (see [14]). The approach presented here aims at models which can be learned within a system by service-component. Further, related work also exists for the different mode services of the models. Although these algorithms usually rely on predefined models, our approach is based on similar models and algorithms developed by the authors in these areas. Nonetheless, other algorithms can be integrated as additional KSCs.

Service-oriented CPSs are also mentioned in the literature. But as stated in the survey of Hoang et al. [11] service-oriented CPSs are “typically designed to coordinate the computational and physical parts of a system”. These approaches often use middleware approaches for CPS. For instance, in [19] a semantic middleware is presented that integrates various CPS elements. This often-focused topic of heterogeneity is also present in the here presented approach, but this paper rather enables high-level model analysis and knowledge gathering in component-services. To categorize the approach in the taxonomy of Hoang et al. [11] this contribution follows a distributed architectural topology with a strong focus on the application layer to provide high-level management.

Production systems are considered in service-oriented architectures mainly for accessing control of manufacturing resources. For example, Valilai et al. aim at resource sharing by supporting collaboration and data integration [16]. Also, real-time services are considered. Lin et al. [20], for instance, proposes these for sustainability and predictability of CPSs. Our approach does not consider resource sharing or real-time services with services, but rather capture behavior. Similarity exists here to algorithms of fault detection that create models like discrete event models or process models [15] in order to describe the monitored system. But these approaches do not consider software layers provided by CPSs and approaches are limited to the production automation domain. Four as-a-service (*aaS) models are identified in cloud manufacturing. Cloud is not directly considered in this paper, but on the cyber levels services are comparable to cloud services following mostly a software-as-a-service model. Nevertheless, our research questions regarding services do not aim at typical cloud systems.

In summary, parts of the approach are considered in different areas and the approach partly relies on these methods. Also, service-oriented CPSs are present in the literature. But existing approaches do not consider service-oriented architectures for the automatic gathering of knowledge, nor are these approaches related to the needs of a service-based learning integrating all layers of a CPS. To our best knowledge, architectures for combining distributed event-monitoring, model-based learning and analyzing of CPSs in service-components are not present in the current literature.

5 Conclusion

This paper presented Production Automation as an important application domain in which service-oriented CPSs are worth to be analyzed, tested and implemented. The paper showed specific problems of CPSs, like capturing joined dynamics, building domain-specific models, and implementing smart functionalities. To address these problems, the paper proposed a service-oriented component architecture. The layered CPS architecture can integrate diverse types of event sources by using autonomous service-component adapters while maintaining a service-component façade in a CPS environment. The contribution showed how corresponding knowledge service-components can be managed in the façade and how services modifying the integrated models can be combined to smart CPS functionalities. This was shown by presenting a self-documenting process based on mode services that supports evolution of the underlying system. The approach was evaluated on a distributed as well as evolving production plant.

Future work can consider non-event-based CPSs and service-based synchronization of higher abstracted KSCs. Further, an extended approach can be imagined that exploits the generated documentation by exchanging documentation between different service-based CPSs in order to actively provide recommendations.