Keywords

1 Introduction

Digitization by software automation is growing significantly in many organizations. In many companies with no particular background in Software (e.g., in the industrial and manufacturing sector), Software crept into processes and products—first slowly but then with an ever-increasing pace and scope, culminating in the mantra that “every company needs to become a software company”. This mantra comes with an inherently increasing demand for skilled software-engineers. Universities and colleges are unable to satisfy this demand adequately.

In many instances, Software is merely a means of automation, and we have to put the power of controlling automation into the hands of domain experts and the general public to bring digital transformation to its full potential in a way that is beneficial to society. Moreover, rules in automated systems need to be understandable at the conceptual level of human reasoning to be amenable, e.g., to ethical and legal considerations. Putting it bluntly, we need frameworks that enable “programming the real world”, e.g., specifying the behavior of objects on a shop floor using observable events, conditions, and actions.

Classical systems engineering approaches fall short as in these approaches requirements on system behavior are decomposed to subsystems and refined to the level of signals, making the originally expressed intention hard to reconstruct (cf.  [1, 2] for examples). New or changed requirements need to be decomposed and translated from scratch, requiring expensive manual effort, involving domain experts and system developers.

We propose an alternative approach that uses domain-specific languages to bridge the gap between the conceptual level of human reasoning about the world and concrete signals and conditions in complex logistical systems enabling domain experts to write requirements like “if a person carrying a box is within 1 m of the designated storage location then the light will turn green”. Such requirements have a well-defined meaning in a system through domain-specific abstractions, computing the value of predicates like “within 1 m of” in a concrete cyber-physical system. System-wide relations and emergent behavior within cyber-physical systems can be evaluated in the form of natural predicates at runtime by preserving the meaning of requirements in domain-specific abstractions.

In this paper, we report on the results of an exploratory design effort, in which we have developed the generic architecture, languages, and abstractions of a framework that enables domain experts to program the behavior of cyber-physical systems (CPS) in the logistics domain. We present the development of a framework with domain-specific languages that allow to express executable rules about moving things in the real world at an abstract level, akin to human reasoning, e.g., the light should turn green if a person carrying a box is within 1 m of the designated storage location.

The resulting framework relies on three individual connected languages: (1) a language for the definition of requirements, (2) a language defining domain-specific objects, functions, and predicates as well as their interpretations in terms of concrete system signals and data, and (3) an extended first-order logic using arbitrary predicates for monitoring and controlling CPS at runtime.

We demonstrate our approach in a case study from the logistics domain: a scenario on a shop floor that requires human-machine collaboration.

Outline. The paper is organized as follows: Sect. 2 introduces logistics as our problem domain and related work. Section 3 presents our case study with our logistics research lab. Section 4 outlines our framework for the independent specification of domain and requirements. Section 5 describe the monitoring of the requirements at runtime and reports on results from our case study. Section 6 discusses the development of our framework and the results from our case study. Section 7 concludes the paper.

2 Related Work

Logistics is the science of moving things in the real world in a reasonable and efficient manner. Logistics applications permeate throughout the human inhabited world and exist in a plethora of different shapes and forms. Logistics systems scale from simple packaging stations to planetary-wide interdependent supply-chain networks. Although there are almost as many types of logistics systems as there are industries, they all share the same basic primitives of movement.

In order to sustain the pace of digital transformation, these logistics systems need to become programmable by domain experts. Moreover, rules in automated systems need to be understandable at the abstract level of human reasoning in order to be amenable to ethical and legal considerations.

Logistics automation is an engineering discipline with a disposition towards algorithms that use numeric methods for optimizing highly context-specific parameters. As such, it is a very different style of reasoning compared to what the shop floor workers are doing. Typical programming languages of field-level automated systems (i.e. Programmable Logic Controllers (PLCs)) are not usable by domain experts as they are rooted in control engineering. High-level requirements have to be related to the domain of these systems for execution in the real world and monitoring and controlling CPS at runtime. Entities, i.e., objects and predicates, which are used in high-level requirements have to be defined over the available signals and system data.

For this reason, No Code or Low Code platforms, e.g. DIME [3], MendixFootnote 1, CreatioFootnote 2, PegaFootnote 3, among others, have become more and more popular in industry [4]. These platforms aim to facilitate the programming of mobile, Internet of Things (IoT), and are applications by non-technical employees based on domain-specific languages (DSL) [5] and models [6]. However, most solutions predominately target business process automation and user applications but are not suited for the programming of technical systems, e.g., robots.

In Academia, various languages and tools have been developed to address the definition of requirement and the automated processing. ASSERT [7] provides the constrained natural language SADL for formalizing domain ontologies and the requirements language SRL to express requirements as conditions over controlled system variables. FRET [8, 9] provides the language FRETISH for specifying the requirements and transforming them into temporal logic formulas. However, these tools still utilize mathematical conditions over system variables in their requirements.

Academia has developed several controlled natural languages, e.g. Processable English (PENG) [10], Controlled English to Logic Translation (CELT) [11], Computer Processable Language (CPL) [12], which are close to natural languages but allow for knowledge representation and reasoning about the textual content. A good overview and classification of controlled languages are given in [13]. Attempto Controlled English (ACE) [14, 15] provides a large subset of the English language to specify requirements which can be transformed unambiguously into a first-order logic [10]. However, ACE aims at knowledge representation and reasoning and does not provide a mechanism for the interpretation of text entities on system data for runtime monitoring and evaluation.

Other solutions for the requirements engineering in natural language aim at transforming natural language into machine-processable formats using fuzzy matching domain-based parsing techniques [16] or natural language processing (NLP) [17]. The problem with these tools is that their interpretation of the requirements within a real-world domain is undefined.

As the authors of [18], we see the importance for integrating multiple models wit specialized focus. We explicitly see the importance for the definition of domain entities and predicates over data of the CPS independent of the specification of requirements. We, therefore, have developed a framework which allows the specification of domain entities and predicates based on system data and their usage in requirements and first-order logic for the runtime monitoring and control.

The following Sect. 3 describe our use case. An overview of our framework with the engineering of the domain and the specification of monitorable requirements is given in Sect. 4.

3 Case Study: Warehouse Logistics

Our case study for the application of our framework has been implemented in a special purpose logistics research lab. This lab is designed as a highly flexible testbed environment for CPS and features a central experimentation area that is free of permanently installed equipment at ground-level. This central area is 22 m long and 15 m wide. It is surrounded by 40 infrared cameras that are part of a Motion Capturing System (MoCap). Additionally, eight laser projectors are installed on the ceiling that can project colored vector graphics on the floor. The graphic shapes can be changed with a very high frame rate and low latency.

Fig. 1.
figure 1

Framework of the research lab

Full size image

Figure 1 shows the framework of the lab. Physical objects are tracked by the MoCap system via uniquely identifiable collections of retro-reflective markers. The generated data streams are sent to the simulation environment. The simulation environment mirrors the perceived objects into a virtual representation of the physical space. The simulation controls the laser projection system and displays virtual objects via a mapping to vector graphics directly in the experimentation area.

For the purpose of the application example, Message Queuing Telemetry Transport (MQTT) has been used as interface to allow the rule engine to generate virtual objects for laser projection to the floor. The incoming data stream of object positions could be either received by a subscription to the MoCap topic on the MQTT server or from the simulation environment. The latter option was used while developing the monitoring framework, as it allowed for faster testing of newly written code.

Our concrete scenario is the manual transports of assembly pieces between workstations, as it can be found in warehouses and plants. Assembly pieces are manually carried in a container between the workstations. The scenario consists of a worker carrying a container KLT_2 for small assembly parts between two workstations AS_1 and AS_3 (cf. Figure 5). Positions of container and workstations are continuously tracked by a Motion Capturing System (MoCap) (cf. position tracking in Fig. 2). The tracking data is sent to a broker using the MQTT protocol [19] from where it is distributed to our rule engine.

The numerical data streams containing the objects’ positions are transformed for the rule engine into abstract interpretations constituting logical constants, properties, and predicates (cf. position abstraction in Fig. 2). The abstract interpretations are used by the rule engine to reason about the relative positioning of container KLT_2 and workstations AS_1 and AS_3.

Based on the evaluation of formulas by the rule engine, actions within these formulas are executed to visualize relative positions of container KLT_2 and workstations AS_1 and AS_3. The rule engine emits the active actions within these formulas. These abstract actions are transformed into concrete visualization objects for the laser projectors of the testbed (cf. visualization abstraction in Fig. 2).

Fig. 2.
figure 2

Data flow at runtime

Full size image

The following Sect. 4 gives an overview about our framework and presents the specification of domain and requirements in our case study.

4 Separation of Domain and Requirements

The behavior of logistics systems can become very complex, as these systems consist of many components with reactive behavior. The specification of emerging behavior in requirements solely based on internal signals and data can be difficult, if not impossible. Our vision is to bridge the gap between natural requirements and monitors or rules on the actual system through code generation and execution.

We want to enable domain experts to specify requirements for logistics systems akin to human reasoning, while directly monitoring and verifying these requirements at runtime. Domain experts do not need any knowledge about programming, language engineering, and formal methods. Otherwise, domain experts would be more concerned with technical or formal details, e.g., the syntax of first-order logic, than specifying the expected system behavior as requirements.

We hold domain experts away from the technical details of the domain and the logistics system by separating the requirements specification in into two main tasks - domain engineering and requirements specification:

  1. 1.

    The domain engineering defines the objects, properties, and predicates within the application domain and interprets these for the data of the CPS, and

  2. 2.

    the requirements specification define the requirements about the CPS using these domain objects, properties, and predicates.

Fig. 3.
figure 3

Overview over the language framework

Full size image

The separation in domain engineering and requirements specification (cf. Figure 4) is also represented by the models \(\mathcal {M}\) in framework. Our framework incorporates three different domain-specific languages for specifying requirements akin to the reasoning of domain experts and executing these requirements at runtime to monitor and control these systems (cf. Figure 3):

  1. 1.

    Domain \(\mathcal {M}_{\text {Dom}}\) describes the domain and its specific terminology which are used in the requirements \(\mathcal {M}_{\text {Req}}\), the first-order logic \(\mathcal {M}_{\text {Log}}\), and the rule engine.

  2. 2.

    Requirements \(\mathcal {M}_{\text {Req}}\) enables specifying requirements akin to human reasoning.

  3. 3.

    Extended first-order logic \(\mathcal {M}_{\text {Log}}\) provides the unambiguous syntax and semantics for monitoring and executing requirements at runtime.

Fig. 4.
figure 4

Development workflow

Full size image

As shown in Fig. 4, each task - domain engineering and requirements specification- requires a different skill sets. We, therefore, distinguish the roles domain engineer and domain expert:

  • The domain engineer possesses sufficient knowledge about the application domain as well as programming and language engineering with domain-specific languages for comprehensively representing the application domain. From this domain specification, the rule engine is instrumented to interpret the entities and predicates in requirements for data from the monitored CPS.

  • The domain expert has deep knowledge about the investigated CPS to exhaustively specify requirements about the system and its behavior akin to their natural reasoning. The natural requirements are automatically transformed into first-order logic for evaluation by the rule engine at runtime.

The domain engineering for warehouse logistics is described in Sect. 4.1, while the specification of requirements and their monitoring for the manual transport of goods in our logistics research lab are presented in Sect. 4.2.

4.1 Engineering the Warehouse Logistics Domain

The development in our use case commences with the definition of the domain \(\mathcal {M}_{\text {Dom}}\) for Warehouse Logistics. The domain \(\mathcal {M}_{\text {Dom}}\) is the central component in our solution and ensures that requirements \(\mathcal {M}_{\text {Req}}\) and formulas \(\mathcal {M}_{\text {Log}}\) reason about the identical application domain.

As shown in Fig. 3, respective interpretations within the domain \(\mathcal {M}_{\text {Dom}}\) are imported into requirements \(\mathcal {M}_{\text {Req}}\) and formulas \(\mathcal {M}_{\text {Log}}\). The data interpretation of objects and predicates are used by the rule engine at runtime to evaluate domain objects and predicates for the current state of the CPS and process a verdict for requirements \(\mathcal {M}_{\text {Req}}\) and in formulas \(\mathcal {M}_{\text {Log}}\) at runtime e (cf. our case study in Sect. 5).

Domain \(\mathcal {M}_{\text {Dom}}\) defines the domain’s objects and predicates as they are used in our case study within our logistics research lab and associates these entities to the data in our logistics research lab. The domain \(\mathcal {M}_{\text {Dom}}\) defines the item container KLT_2, workstations AS_1 and AS_3, and predicates about the geometric relationship between objects, i.e., besides. An excerpt of the domain is shown in Listing 1.1.

figure a

The objects KTL_2 and AS_1 both have the type Object and are identically expressed in the requirements \(\mathcal {M}_{\text {Req}}\) and first-order logic \(\mathcal {M}_{\text {Log}}\) (cf. keywords Requirement and Logic in Listing 1.1). The predicate beside is defined in \(\mathcal {M}_{\text {Req}}\) by the word within and an arbitrary distance dist (cf. keyword Requirement in Listing 1.1). The objects which are compared by the predicate beside are determined by the sentence in which the predicate is used. For the first-order logic \(\mathcal {M}_{\text {Log}}\), the predicate is defined with three parameters; the first two parameters take constants Con1 and Con2 as inputs while the third parameter takes a float value dist for the distance (cf. keyword Logic in Listing 1.1).

At runtime, predicate beside is interpreted and evaluated for the incoming streams of position data from the MoCap System. The data from the MoCap system is provided to the rule engine via the MQTT broker as JSON data [20, 21]. The interpretation of the system data is defined by the data function (cf. keyword Data in Listing 1.1); predicate beside will be evaluated as satisfied if the absolute amount of the distance between the position of object Con1 and the position of constant Con2 is below the given distance dist. Objects Con1 and Con2 are filtered in the list of objects positionObjects in the MQTT data based on their names and their common attribute position is assessed for the position values. These data interpretations are used in the abstraction of the numerical position data to abstract representations in first-order logic (cf. position abstraction in Fig. 2).

For our demonstration, we defined five additional predicates for evaluating the relative position of container and workstations. All six predicates are shown in Table 1.

In addition to the six predicates about the relative position of container and workstations, actions draw rectangle and draw circle are defined in the domain \(\mathcal {M}_{\text {Dom}}\) (cf. Table 1). Action draw circle will result in a circle as laser visualization while action draw rectangle yields to the projection of a rectangle by the laser projectors. Both actions have parameters for position, color, size, duration, and animation of the projected rectangle resp. circle. Positions of the laser visualizations can be defined either as fixed positions in world coordinates or the visualizations can be attached to the positions of objects. Attachments to objects provide the advantages that the visualizations will change their positions according to the movement of these objects.

The following Sect. 4.2 describes how the requirements \(\mathcal {M}_{\text {Req}}\) are defined for our logistics case study using the definitions in domain \(\mathcal {M}_{\text {Dom}}\).

Table 1. Overview of predicates in the domain \(\mathcal {M}_{\text {Dom}}\).
Full size table

4.2 Specification of Requirements

Requirements \(\mathcal {M}_{\text {Req}}\) are specified by domain experts using an almost natural but domain-specific language. Requirements \(\mathcal {M}_{\text {Req}}\) have the basic clause

$$\begin{aligned} \mathbf {if}\; \langle conditions \rangle \; \mathbf {then}\; \langle actions \rangle \end{aligned}$$

where \(\langle \)conditions\(\rangle \) and \(\langle \)actions\(\rangle \) can be conjunctions of multiple conditions resp. actions, e.g., if a package is available in one of the loading areas, then an idling robot has to move to the leading area and pick up the package. Requirements \(\mathcal {M}_{\text {Req}}\) import the specific interpretations of domain-specific entities, i.e., item container KLT_2, workstations AS_1 and AS_3, and predicates about the geometric relationship between objects, from domain \(\mathcal {M}_{\text {Dom}}\) (cf. Section 4.1).

figure b

In our demonstration, we defined three requirements about the position of the container KTL_2 in relation to the workstations AS_1 and AS_3 in the requirements \(\mathcal {M}_{Req}\) using the definition of the domain \(\mathcal {M}_{\text {Dom}}\). The requirements are shown in Listing 1.2. Requirement Req1 will result in the drawing of a magenta rectangle with 6 m edges at the global position \(\{1.0,0.0,0.0\}\) if the container KLT_2 is within 4 m of both workstations AS_1 and AS_3. The second requirement Req2 will result in a yellow rectangle drawn around the workstation AS_1 with edge of 2 m if the distance between container KLT_2 and workstation AS_1 is less than 3 m. Requirement Req3 is identical to requirement Req2 with workstation AS_1 replaced by workstation AS_3.

The following Sect. 5 describe how the requirements \(\mathcal {M}_{\text {Req}}\) are transformed into first-order formulas \(\mathcal {M}_{\text {Log}}\) and monitor in our shop floor scenario in our logistics research lab.

5 Runtime Monitoring and System Control

Requirements \(\mathcal {M}_{\text {Req}}\) are automatically transformed by our framework into formulas \(\mathcal {M}_{\text {Log}}\) in first-order logic for monitoring and controlling the CPS at runtime. Our framework uses classic first-order logic extended by operators for equality \(==\) and the implication \(|>\) between conditions and actions.

Similar to the requirements \(\mathcal {M}_{\text {Req}}\), the specific interpretations of entities in domain \(\mathcal {M}_{\text {Dom}}\), i.e., item container KLT_2, workstations AS_1 and AS_3, and predicates about the geometric relationship between objects, are imported into the formulas \(\mathcal {M}_{\text {Log}}\). The semantics of formulas \(\mathcal {M}_{\text {Log}}\) are given by the interpretation of these domain-specific entities for the data of CPS.

As shown in Listing 1.3, three formulas \(\mathcal {M}_{\text {Log}}\) are generated in first-order logic from the three requirements in Listing 1.2. The requirement Req1 in Listing 1.2 is transformed to formula Req1 in Listing 1.3.

figure c

The container KTL_2 and workstations AS_1 and AS_3 are equally used in requirements \(\mathcal {M}_{\text {Req}}\) as well as formulas \(\mathcal {M}_{\text {Log}}\). Therefore, representations of these objects in requirements \(\mathcal {M}_{\text {Req}}\) are directly transformed into corresponding representations in formulas \(\mathcal {M}_{\text {Log}}\) using the definitions in domain \(\mathcal {M}_{\text {Dom}}\). The predicate within in \(\mathcal {M}_{\text {Req}}\) maps to the predicate beside in formulas \(\mathcal {M}_{\text {Log}}\). The container KTL_2, workstation AS_1 resp. AS_3, and constraint 4 m are assigned to the parameters Con1, Con1, and dist respectively. The preceding verbs is and resides for the predicate within in requirements \(\mathcal {M}_{\text {Req}}\) are syntactic sugar and are not considered for the transformation of predicate within into the formulas \(\mathcal {M}_{\text {Log}}\).

The action in the action part of requirements Req1 in Listing 1.2 is transformed in the predicate rectangle in \(\mathcal {M}_{\text {Log}}\) with its parameters derived from the additional constraints in the action part, e.g., at position {−1.0,0.0,0.0} and in magenta color. Requirements Req2 and Req3 are transformed into formulas similar to the transformation of requirement Req1. The semantics of these three formulas in Listing 1.3 is consistent with the semantics of their original requirements in Listing 1.2.

Results from runtime evaluation of the three formulas in Listing 1.3 for the manual transport of container KLT_2 between the two workstations AS_1 and AS_3 are shown in Fig. 5. The rule engine for this demonstration has been instrumented for evaluating the three formulas in Listing 1.3 at runtime using the definition of the domain in Listing 1.1.

Fig. 5.
figure 5

Demonstration of logistics scenario.

Full size image

In Fig. 5a, the container KLT_2 is at the workstation AS_3. The formulas Req1 and Req3 are satisfied in this situation while requirement Req2 fails due to the large distance to workstation AS_1. As result, a large magenta rectangle and a small yellow rectangle around workstation AS_3 are drawn according to the satisfied formulas Req1 and Req3 (cf. Listing 1.2).

After carrying the container KLT_2 over to the workstation AS_1, the yellow rectangle around workstation AS_3 disappears while a new yellow rectangle appears around workstation AS_1. This behavior is consistent with formulas Req2 and Req3 (cf. Listing 1.2) because the predicate beside in formula Req3 is now invalid while it is now true for formula Req2. Formula Req1 is satisfied in both situations. Therefore, the large magenta rectangle is drawn throughout the complete transition of container KLT_2 from workstation AS_3 to workstation AS_1.

Our lessons from the development and application of our framework are presented in the following section.

6 Discussion

The work presented in this paper is highly explorative. We have aimed for a first technical prove-of-concept.

While the current implementation of our framework is a prototype, we can draw some initial conclusions from its development, the conducted application.

Remark 1:

Separation of languages seems to support the distribution and reuse in system development.

Our case study has provided first indications that the separation of domain engineering and requirements specification has a positive impact in the development of logistical CPS. Requirements \(\mathcal {M}_{\text {Req}}\) and domain \(\mathcal {M}_{\text {Dom}}\) seem to be reusable in another context independent of each other. Requirements can be used for CPS in other domains by just redefining the objects and predicates in requirements for the new domain. The development of new systems, may reuse an existing domain \(\mathcal {M}_{\text {Dom}}\) in its new requirements \(\mathcal {M}_{\text {Req}}\) of the new system. There is no need to adapt the objects and predicates in the domain \(\mathcal {M}_{\text {Dom}}\) to the new system.

Requirements and domain seem to be easily developed independent of each other, providing organizations with the opportunity to efficiently employ domain engineers within the development of these systems. As critical resource due to their technical knowledge, domain engineers may concentrate on the definition of domain \(\mathcal {M}_{\text {Dom}}\) while domain expert with limited technical knowledge can define the relevant requirements akin to their natural reasoning. This approach enables organization to introduce more non-technical domain experts to the development of these technical systems.

Remark 2:

Designing a domain-specific language for natural requirements, akin to human reasoning, is expensive.

The specification of requirements has to feel as natural as possible for domain experts—akin to their usual reasoning of these logistical systems—in order for domain experts to adapt languages and tools into their work. Otherwise, domain expert are more occupied with the expression of requirements in a specific language grammar than comprehensively representing the systems in their requirements.

English and other natural language provide various clauses that allow for different sentence structures with identical semantic meaning in requirements. Replicating this grammatical flexibility in domain-specific languages is difficult and expensive. The majority of clauses from the natural base language have to be defined in the requirements language to suggest grammatical flexibility. Furthermore, all these clauses have to be mapped to expressions in the first-order logic for the evaluation at runtime. However, clauses often contain similar sentence structure which can cause problems for parser generators, i.e., ANTLR [22]. Clauses with similar sentence structure hinder the parser to associate corresponding parts of requirements deterministically to a single clause for building an abstract syntax tree. As a result, the grammar of the requirements language has to be carefully specified for these parser generators to work correctly. There exist some controlled natural languages, e.g., Attempto Controlled English (ACE) [14, 15], Processable English (PENG) [10], and Computer Processable Language (CPL) [12] among others, which provide the grammatical flexibility of English, but these languages miss the mapping of objects and predicates to real system data.

Remark 3:

Temporal Constraints are an essential part of today’s technical requirements in logistics.

Within our case study, we have recognized that many technical requirements in logistics are time-dependent, but our requirements and logic are currently not able to express such temporal expressions. We neglected temporal constraint in our framework because we focused on the architectural combination of the three models, i.e., requirements, domain, and logic, to enable the specification of monitorable requirements at runtime. It is essential that we address temporal expression in our requirements and extend the logic by temporal operators as they are used in, e.g., metric first-order temporal logic [23], in future work.

Remark 4:

System data has to be provided in sufficient quantity and quality.

An important part for monitoring requirements at runtime is the data provided by the CPS. This system data defines the scope of domain and requirements, which can be evaluated by the rule engine at runtime. The CPS has to provide data in the appropriate form, quantity, and quality to sufficiently represent the real application domain in domain \(\mathcal {M}_{\text {Dom}}\). Objects and predicates without any processable data function in domain \(\mathcal {M}_{\text {Dom}}\) could be potentially used in requirements \(\mathcal {M}_{\text {Req}}\) to form syntactic correct requirements, but these requirements cannot be interpreted by the rule engine at runtime. There exist two possibilities for evaluating an object or predicate for the data from the CPS, if (1) the provided data contains a corresponding data item or (2) the object and predicate can be calculated from the available data items. For example, the rule engine will evaluate the velocity of a robot, only if the provided data from the robot does include a data item about the robot’s velocity or the remaining data items allow to calculate the velocity.

7 Conclusion

We have presented a framework for the development of domain-specific languages that express executable rules about CPS in logistics at the conceptual level, akin to the reasoning of domain experts. The framework defines three individual languages: (1) the domain language allows to specify the application domain with its entities, and predicates over these entities, (2) the requirements language provides the grammatical flexibility to define requirements akin to human reasoning, (3) the first-order logic provides clear syntax and semantics for monitoring and controlling CPS at runtime. We have demonstrated our framework in a logistics scenario with human-machine collaboration. The case study shows that the control and monitoring of CPS in logistics is viable and beneficial under the separation of requirements and domain specification. The separate definition of domain entities, i.e., objects, their proprieties, and predicates, over the system data is essential for specifying requirements akin to human reasoning. However, the development of our framework has also shown that the design of an almost natural language for the requirements specification is very costly and difficult.

One point to consider for the future is the consideration of existing and proven controlled natural languages, e.g. ACE or PENG, for the specification of requirements. Additional future improvements for our framework to consider: (1) temporal expressions in our requirements language and formal logic, (2) different languages than standard English, and (3) the integration of our framework in a requirements engineering workflow. We also envisage a potential of our work in other domain than logistics and want to harden the expressive power within our framework through application in more diverse domains.