1 Introduction

Driven by both changes in the business world and revolutions in information technology, the nature of information systems is currently going through a major transition. In the past, information systems managing ‘physical processes’ and systems managing ‘administrative processes’ would usually be separated in two different ‘worlds’. As an example, in a typical factory the manufacturing shop floor is managed by a manufacturing execution system (MES), whereas customer details are managed in a customer relationship management system (CRM) - with often very little structural linkage of the two. In a logistics context, typically there are systems managing customer orders and different systems physically tracking the whereabouts of transport vehicles (like trucks). In modern industrial practice, we see that these worlds need to be tightly coupled or even integrated to deal with developments like the transformation of supply chains to demand chains, just-in-time logistics, servitization and mass-customization of products and services – some of which under umbrella developments like Industry 4.0 [8]. In research, this is reflected for instance, in a recent interest in the combination of business process management and the internet-of-things (IoT) [11], and business models and IoT [4].

This transition causes confusion, as positioning systems and approaches underlying these systems with respect to each other is not easy. Concepts and terminologies are different, architectures are different, people are different – both in designing and in managing the systems. Improper positioning may lead to problems when ‘physical’ and ‘administrative’ systems are linked or integrated. These problems can be of two kinds – if the linking or integration succeeds at all. The first kind shows as blind spots in system functionality - resulting in the inability of the resulting system to properly support the entire spectrum of business functionality. The second kind shows as replications of functionality - usually resulting in inconsistency of business functionality and business data (and the obvious unnecessary investment of double functionality).

To address this issue of positioning, this paper proposes a reference framework for advanced flexible information systems (AFIS), in which existing systems and approaches can be positioned, analyzed and compared. We label a system as AFIS if it is built to support advanced business functionality (i.e., crossing functional boundaries) in a flexible way (i.e., reacting to changes in its environment on various time horizons). We apply our reference framework on a small but representative set of research and development efforts for advanced flexible information systems.

This paper is organized as follows. In Sects. 2 and 3, we present the ingredients of the new reference framework: perspectives and layers, respectively functions and control loops. Section 4 discusses the framework. The application of the framework is discussed in Sect. 5. In Sect. 6, we discuss related work and compare it to our framework – we do this at the end of the paper because this enables clearer positioning for the reader. We conclude the paper in Sect. 7.

2 The Perspectives and Layers

In designing the reference framework, we aim at covering the complete functionality spectrum of an AFIS. This has implications for the system perspectives and the system layers that the framework covers.

From a perspective point of view, we distinguish between the design time and the execution time perspectives. In the design time perspective, we cover support for the conception, design and analysis of models that define the desired behavior of the system. In the execution time perspective, we cover support for the execution of these models, including the (real-time) collection of data from this execution.

From the point of view of system layers, we make sure to have a set of meaningful layers in the abstraction dimension of real-time information processing in AFIS. To do so, we distinguish four layers. The physical layer is at the lowest level of abstraction: this is where the physical ‘work’ is executed, i.e., the hardware-oriented layer that is controlled by the upper layers and that generates data about its state. One layer up in the abstraction dimension, we find the event layer: this is where events from the physical layer are processed and commands are passed down to the physical layer. On top of the event layer, we find the process layer, where events are interpreted in the context of business processes. In this layer, the emphasis is on the sequencing of events – or in other words: on the control flow between tasks. The highest layer is the business layer, where the effect of process execution is interpreted in the context of business goals – or in other words: where the mapping of the how of business to the what of business is made [6].

When we combine the two perspectives and the four layers, we get eight areas of possible attention, as shown in Table 1. From the viewpoint of AFIS, we are interested in the interaction with the physical layer (i.e., the execution time), but not in the design of the physical layer, as this concerns hardware design. So we place the design time perspective of the physical layer out of scope for our reference framework.

Table 1. Overview of perspectives and layers of the reference framework
Full size table

3 The Functions and Loops

In our reference framework, we place a set of abstract information system functionalities that are made concrete per layer of the framework. We have chosen a set of seven functionalities – knowing that many variations on this set are possible, but that these do not change the essence and purpose of the resulting framework. The seven functionalities are shown in Fig. 1 with a few example concretizations. Model includes designing or redesigning an enactable model for the behavior of a layer of an AFIS. Adapt covers making a model fit for enactment, e.g. by parameterization (with may also be labeled Deploy). Control supervises the enactment of a model, i.e., select the order and timing of enactment and assigning resources. Perform physically enacts the model, i.e., performs the individual steps as dictated by the Control function. Measure covers obtaining the relevant characteristics of the enactment of a step. Record covers storing the measurements of the Measure function for subsequent use. Finally, Analyze covers processing a set of measurements to make them fit for decision making.

Fig. 1.
figure 1

Reference framework functions with bimodal control loops (left) and example concretizations (right)

Full size image

To support flexibility, we require a reactive capability in our framework, i.e., means to adapt to changing circumstances. We cover this with the principle of a control (or feedback) loop. We recognize the need for direct, automatic reactions (real-time flexibility, i.e., readjustment of a model) and for reactions that require a redesign of a model (i.e., non-automatic and indirect in execution). This leads to the inclusion of a bimodal pair of control loops in our framework (shown in the left of Fig. 1), supporting both tactic/strategic business (process) redesign and operational (real-time) business (process) readjustment. These loops are shown more explicitly in Fig. 2, in which we distinguish between prescriptive data flows (informing other modules what to do) and descriptive data flows (informing other modules what has been done). We choose the term ‘bimodal’ as the control loops have similar characteristics as bimodal information system development [13]. Bimodal control loops enable bimodal flexibility (on dual time horizons) in advanced information systems.

Fig. 2.
figure 2

Bimodal control loops: redesign (left) and readjust (right) as in Fig. 1

Full size image

4 The Reference Framework

We combine the notion of bimodal control loops and the contents of Table 1 to arrive at the structure (or conceptual architecture) of a multi-layer, bimodal flexibility reference framework for AFIS. This framework is shown in Fig. 3. The framework has eight interconnected cells, corresponding with the cells of Table 1, of which one has been declared out of scope as discussed before. We have placed the model and analyze functions in the design time perspective, as these require intelligent, time-consuming activities (often with human involvement) that have a slower processing cycle (shorter ‘clock tick’) than the execution time perspective. The other five functions are placed in the execution time perspective, as these take place in the same processing cycle and with the same ‘clock tick’ – preferably in an automated fashion. In the physical layer, we have placed the perform and measure functions, as these have a physical semantics. In the upper three layers, ‘measurements’ are provided by the adapt function of the layer below and activities are ‘performed’ by the control function of the level below – these abstract the execution time interface of the level below (as in a strictly layered architecture).

Fig. 3.
figure 3

Reference framework for AFIS

Full size image

The reference framework is an abstract structure for a complete AFIS covering the spectrum from business goal to physical activity execution from both the design and execution perspectives, putting the emphasis on the data flows between the layers and the functions within the layers, operationalizing both descriptive flows for business intelligence and prescriptive flows for operations control. To use the framework in practice, concrete system frameworks (or system architectures) are mapped to it. This mapping has three steps:

  1. 1.

    Trim: remove the functions (or entire layers) from the reference framework that are not covered by the concrete system.

  2. 2.

    Complete: add specific data flows that are not covered by the reference framework (examples are included in Sect. 5).

  3. 3.

    Concretize: replace the abstract function labels in the framework by more concrete function labels that suit the application domain of the concrete system.

Note that steps 2 and 3 represent proper specialization of the reference framework to a concrete case.

5 Application of the Framework

To illustrate the use of the AFIS reference framework, we map a set of large, contemporary system development efforts to it. We pick a set of three recent European projects (from the FP7 and H2020 programs) that all have the characteristics of integrating physical processes and administrative processes in a context with strong real-time characteristics. These projects are from three different application domains: international, synchro-modal logistics (GET Service), high-tech manufacturing (HORSE), and traffic management and mobility services (C-MobILE). As we have been involved or are involved in these projects, we know them well and can provide a mapping with a good deal of certainty - so the precise choice of concrete systems is of a pragmatic nature for the purpose of this paper. We end this section with a short discussion.

GET Service.

In the GET Service project, an advanced planning and control system has been developed and prototyped for synchro-modal logistics, focusing on international container transport [2]. The GET Service system uses advanced event stream processing to process real-time event data from logistics sources (such as ships, trucks and roads) into information used for decision making in inter-organizational logistics processes [3]. The GET Service approach is mapped to the AFIS reference framework in Fig. 4. Note that we have specialized some of the function labels in this figure - correspondence to Fig. 3 is by location in the figure.

Fig. 4.
figure 4

GET Service approach mapped to AFIS reference framework

Full size image

As shown in the figure, the GET Service system mainly concentrates on the three bottom layers. The physical layer contains the transport vehicles and transport infrastructure, which are both sources for IoT measurements, but also receive commands for the execution of physical logistics steps. An example of the latter is the instruction to drive a truck from A to B or to unload a container from a ship. As such, the physical logistics entities can be seen as complex sensors and actuators in an IoT context. The processing of real-time, low-level logistics event streams takes place in the event layer. Here, a complex event engine filters, aggregates and combines events into high-level events that can be used for decision making (the process event stream function in the figure).

High-level events can be used to adapt a logistics task that is currently being managed – in the real-time control loop – or be used to redesign the event processing model (such as aggregation or combination rules) – in the redesign loop. High-level events are also passed to the process layer, where they are used to trigger replanning of logistics processes – in the (near) real-time loop – or to remodel logistics processes from process snippets – in the redesign loop. The GET Service approach clearly supports the bimodal flexibility perspective in its control loops.

The GET Service framework includes business models that explain why several parties collaborate in inter-organizational business processes to achieve which business goals. This implies the model function in the business layer. This function is not explicitly connected to the process layer, however – making this an isolated element in the framework. Consequently, the GET Service system explicitly supports real-time, agile business processes, but not agile business models.

HORSE.

The HORSE project focuses on the development of an integrated manufacturing control system that integrates manufacturing process management with real-time control of hybrid manufacturing tasks [7]. Here the term ‘hybrid’ indicates that tasks can be executed by robots, humans, or combinations of these. The HORSE approach is mapped to the AFIS framework in Fig. 5.

Fig. 5.
figure 5

HORSE approach mapped to AFIS reference framework

Full size image

In the physical layer, we find the physical work cells in factories in which robots and/or humans perform manufacturing steps that are part of tasks. What happens in these work cells is measured by various sensors and controlled by a step supervisor software module. The tasks and steps in work cells are controlled in the event layer. In this layer, the real-time control loop is used to manage exceptions in the execution of tasks (such as possible collisions between humans and robots) in the context of the work cell. The execution of the event layer is driven by a local execution model that is constructed in design time – but there is no general-purpose explicit data feed from execution time to design time for this purpose (there are some specific exceptions, though, such as teaching a step to a robot by instruction, i.e., designing a script by physically manipulating a robot). Events about the execution of tasks are sent to the process layer, where a manufacturing process is executed. The real-time control loop is used to manage exceptions at the global level, i.e., across a set of work cells that form a manufacturing line. Like in the event layer, a process model is designed for this purpose, but without explicit feedback from the execution time environment. Like in the GET Service case, collaborative business models are included in the HORSE approach, but they are isolated with respect to data feeds.

The analysis in the AFIS framework clearly shows that the HORSE approach supports flexibility, but focuses strongly on the real-time loop in the bimodal perspective.

C-MobILE.

The C-MobILE project focuses on the development of an approach and system framework for the support of integrated mobility services [12]. The addressed mobility services focus on automotive transport, but also include public transport. The mapping of the C-MobILE approach to the AFIS framework is shown in Fig. 6. Note that this mapping includes data flows that are not included in the reference model – this is a case of specialization as explained in Sect. 4.

Fig. 6.
figure 6

C-MobILE approach mapped to AFIS reference framework

Full size image

As shown in Fig. 6, the C-MobILE system has a focus on the physical and event layer of our framework. In the physical layer, we find vehicles with on-board units (OBU) and infrastructure (roads) with road-side units (RSU) that function as IoT objects – they are event sources. Commands are sent to the physical layer either through these OBUs or RSUs, or through mobile devices (typically smartphones) to vehicle drivers using mobile networks. On the event layer, traffic management and mobility management services perform traffic control operations to orchestrate vehicles – this has a strong real-time character. The way this is done is modeled in the design time aspect – recorded traffic information can be used to redesign the control models.

Like in the previous two cases, there is attention for collaborative business models in the C-MobILE approach, but this is not covered by technical systems. They are analyzed, however, and used as a basis for modeling business processes – for which no automated execution support is covered, however. These business process models can be related to event processing models, mainly for designing sequencing issues.

The focus on the lower levels of our framework is typical for the application domain, which currently is rather device-centric (as in OBUs, RSUs and interface devices). The non-automated coverage of functionality in the top-left corner of our framework shows an increase of interest for the higher levels as well. The C-MobILE approach covers a bimodal control approach, but at a low level of abstraction from the application domain point of view (concentrated in the physical and event layers).

Discussion.

From the above analysis of the three example projects, we see that none of the research efforts cover the entire field of functionality covered by the AFIS reference framework. They are all strongly ‘rooted in technology’, i.e., they mostly cover the functionality in the lower two layers of the framework. The GET Service and HORSE projects have good coverage of the process layer. They have the logistics and manufacturing domains as their target, where the notion of ‘process’ comes naturally (logistics process, manufacturing process) - be it sometimes at a low level of abstraction. The C-MobILE project hardly covers this layer - in the mobility domain, process thinking is not (yet) widely accepted. The coverage of the business layer is in general sparse in the projects. This is not surprising, as this layer requires a high level of abstraction and aggregation in data processing. On the other hand, the sparsity of this level may be highly undesirable, as many markets are moving towards business agility, which requires a (near) real-time feedback loop between operational events and processes and business decisions at a higher level. We believe that our framework can help in addressing this gap.

An interesting line of thought - that still requires further elaboration, though - is how the AFIS framework can be used to ‘mix and merge’ solutions from projects. As we have seen, GET Service has proper support for the process layer, whereas C-MobILE almost completely lacks this. Nevertheless, both projects are concerned with real-time support of physical transport services - focusing on goods respectively people - and have an event-oriented basis. Consequently, a question may be whether the process layer of GET Service might be ‘transplanted’ to the C-MobILE framework. Similarly, the better populated business layer of C-MobILE may be ‘transplanted’ to GET Service. In doing so, better functional coverage of projects can be achieved and reinvention of the wheel can possibly be avoided.

6 Related Work

The need for reference models to manage complexity and interoperability has been acknowledged widely in the information systems domain. We find them in the form of conceptual reference models, reference architectures and reference frameworks. We discuss related work in these three classes of reference models below.

A well-known reference model from the business process management domain is the Workflow Management Coalition (WfMC) Reference Model [15]. The model has some characteristics of a reference architecture, but is incomplete as an architecture specification. Though it has partially the same objectives as the framework of this paper, i.e. positioning functionality, its scope is much smaller: it is limited to the process layer only.

Reference architectures for information systems have been proposed in many ‘forms and colors’. A more architectural counterpart of the WfMC model is for example the Mercurius reference architecture [5]. This reference architecture can also be positioned in the framework we propose, but like the WfMC model, it is limited to the process layer. A reference architecture for traffic management – related to the C-MobILE case discussed in Sect. 5 – was developed in the USA [10]. This reference architecture is domain-specific and focuses on the event layer and physical layer of our framework. A reference architecture for the Internet of Things also addresses the bottom two layers of our framework – a comparison of four competing architectures is presented by the Open Group [14]. An approach for the analysis and design of reference architectures [1] allows for the general classification of individual architectures. It does, however, not provide a tool to position concrete systems and approaches with respect to the functionality they cover in a spectrum.

In the field of reference frameworks, we find for example business frameworks that do not describe the structure of information systems, but of the business organization that should be served by these systems. A nice example is the IEC hierarchy for manufacturing [9], which defines a set of organizational aggregation levels in a manufacturing company, which can be mapped to specific types of information systems. It can be used in structuring systems, but only in an indirect way. A different kind of framework can be found in an overview of benefits and challenges for the combination of the IoT and business process management [11]. This overview contains a control model that has similarities with our redesign control loop (see Fig. 2) – and partly inspired our thinking. This control model is not layered, however, and does not make an explicit distinction between design time and execution time aspects. Its main purpose is to be the ‘anchor’ for a list of research problems and opportunities.

7 Conclusion

Positioning systems and approaches in the turbulent world or advanced flexible information systems (AFIS) is not an easy thing – given many concurrent developments like IoT, Industry 4.0, servitization, etcetera. Improper positioning hinders integration of approaches, exchangeability of parts of approaches, or simply interfacing between modules of different approaches.

In this paper, we have shown the design of a reference framework for AFIS that helps in proper positioning. We think that it is essential to both cover multiple abstraction layers in such a framework and include a bimodal control loop mechanism. The abstraction layers allow for a separation of concerns in complex decision making – and hence a separation in concerns towards business intelligence functionality. The bimodal character supports a separation between real-time, on-line reacting and non-real-time, potentially off-line redesign.

The practical application of the framework to a small set of complex AFIS cases in this paper shows that the framework is a proper tool for the analysis of these cases. The three case studies show that the business layer is sparsely covered in general - certainly where it comes to structured (automated) linking with the layers below. We expect this to be the case in many other projects as well. Given the attention to the business layer (both from practice and from research programs), we consider this an omission in current practice and an opportunity for future research in AFIS.

We plan to use the framework to position a larger set of cases to obtain a more complete overview of the developments in AFIS from a technical point of view and the match to application domain requirements. In other words, we aim at using the framework as a tool for analyzing technology push and requirements pull forces in the AFIS domain.