Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Nowadays, the global financial crisis together with the low-cost manufacturing countries, have stressed the need of European SMEs, to re-invent the concept of enterprise joining forces by collaborating with outside partners, in order to continue competitive. Collaborative networks, especially in the form of virtual enterprises are a good way to achieve business goals, enter in new market segments, and answer quickly to business opportunities with special and innovative requirements.

Currently, European SMEs operate in an open, global market, facing strong competition from large companies, and from non-European companies, where, among other things, low labor costs, and more flexible labor legislations represent a strong competitive advantage. Factors like price and quality are no longer a competitive advantage. This reality, together with the global economic crisis, turns innovation, product customization, and quick time to market into key success factors [1]. Therefore, manufacturing has to improve its innovation activities and come up with new ideas to transform old products and processes to new cost effective and efficient ones. However, many of the manufacturing companies are SMEs with only a few of them having capacity to implement innovative manufacturing technologies. SMEs have not benefited the most from the advantages that modern business strategies and sophisticated technologies can offer. These advantages have mostly been limited to major companies so far. The use of manufacturing execution systems among SMEs is rare. Currently, SMEs are mostly component suppliers for leading companies and the complexity of operational processes is limited and in most cases is still paper based. The economic recession has fragmented the market place and the number of SMEs that have lost the links to the OEM’s has continued to grow. This has left many SME’s in a position where they need to find new customers and also reduce their base costs to compete in an open market.

Providing SMEs with tools and methods to build, optimize, monitor, and maintain virtual factories by establishing collaborative manufacturing processes will help them to provide new, highly-developed products, as well as to re-factoring existing manufacturing processes [2]. Manufacturing processes need to be monitored with the objective to successfully control them. In order to control a process, it is necessary to update the real-time process information as are coming from different sources. By integrating information from sensors and other sources commonly known as “Internet of Things”, it is possible to generate a realistic estimation of the current “status of manufacturing” across companies (SMEs) just as within one company as it is today. This information needs to be provided through an open infrastructure which is nevertheless able to constrain data access and handling based on privacy and other concerns. Using Key Performance Indicators (KPIs), processes can be monitored and governed; here, it is necessary to recognize very early if certain constraints cannot be met and initiate adequate countermeasures. In particular, environmental sustainability is becoming a more and more important aspect of manufacturing tasks. The ability to have an overall view of the processes within an organization and have clear information regarding delivery times and dates is a clear advantage for any business. It provides the competitive edge for reducing costs of delivery, reduced stock levels, and eliminating waste [3, 4].

The essential issue tackled in this paper and underlying research question refer to the virtual enterprises manufacturing processes monitoring. In this research, it is of interest to face the following four research questions: (a) what are the requirements for virtual enterprises manufacturing processes monitoring?, (b) what are the functionalities needed to process monitoring?, (c) how to design a loosely coupled process monitoring module, and finally (d) how to integrate it in a virtual enterprise interactive user interface management platform?

This paper is organized as follows. Section 2 reviews the literature about virtual enterprises characteristics, business activity monitoring, and process analytics concepts in order to build a theoretical background and to support the business process monitoring for virtual enterprises specification. Section 3 presents the research methodology. Section 4 contains the main contribution presenting the results of this research with the requirements, functionalities, and design of a loosely coupled collaborative manufacturing process monitoring tool. Section 5 presents the interactive user interface layer to monitor and manage those manufacturing processes. Finally, Sect. 6 concludes the paper.

2 Foundations and Research Topics

2.1 Business Activity Monitoring

Business Activity Monitoring describes the processes and technologies that provide real-time situation awareness, as well as access to and analysis of key performance indicators, based on event-driven sources of data. Business Activity Monitoring (BAM) is used to improve the speed and effectiveness of business operations by keeping track of what is happening now and raising awareness of issues as soon as they can be detected. BAM applications can emit alerts about a business opportunity or problem, drive a dashboard with metrics or status, make use of predictive and historical information, display an event log and offer drill-down features. BAM also “drives the innovation by detecting events, filtering them, and triggering business process management (BPM) solutions”. BAM may enable new ways of performing vertical applications that will result in significantly increased revenue or cost savings for an enterprise [5].

Although the purpose of BAM technology is to provide business users with real-time access to, and analysis about, key performance indicators, the level of complexity in the solution can widely vary. BAM functionality is based on a relatively simple architecture. Alerts and frequently updated displays are driven by a processing and analytic engine that is supplied with a stream of events that is received or collected from a variety of sources working in real time. BAM must address the general requirements and each the basic features of four architectural categories: Event collection, filtering and transformation, Delivery and display, analysis and processing, and Operational databases.

The current challenge is to bring BAM functionalities to the Manufacturing SMEs field, through a web based platform. Thus, SMEs can manage their collaborative processes without the need of large ICT investments as in many cases they are not capable to do such type of investments [6, 7].

2.2 Complex Events Processing in Distributed Systems

Complex event processing (CEP) is an emerging network technology that creates actionable, situational knowledge from distributed message-based systems, databases, and applications in real time or near real time. CEP can provide an organization with the capability to define, manage, and predict events, situations, exceptional conditions, opportunities and threats in complex, heterogeneous networks. Many have said that advancements in CEP will help advance the state-of-the-art in end-to-end visibility for operational situational awareness in many business scenarios. These scenarios range from network management to business optimization, resulting in enhanced situational knowledge, increased business agility, and the ability to more accurately (and rapidly) sense, detect and respond to business events and situations. CEP can be applied to a broad spectrum of information system challenges, including business process automation, schedule and control processes, network monitoring and performance prediction, and intrusion detection. The publish/subscribe mechanisms allow loosely coupled exchange of asynchronous notifications, facilitating extensibility, and flexibility. The channel model has evolved to a more flexible subscription mechanism, known as subject-based addressing, where a subject is attached to each notification [6]. Subject-based addressing features a set of rules that defines a uniform name space for messages and their destinations. This approach is inflexible if changes to the subject organization are required, implying fixes in all participating applications.

2.3 Virtual Enterprise

In recent years, a diversity of new organizations based on collaboration have emerged (the so-called collaborative networks). These coalitions between firms were created to face market challenges and overcome the limitations by joining abilities. Thus, companies with specific knowledge and competencies, seek to align with other companies to meet requirements and thus exploit and quickly answer to emerging business opportunities, forming a Collaborative Network in the form of Virtual Enterprise [1, 5, 8].

The definition of Virtual Enterprise (VE) used in this paper is based on the definition proposed by Camarinha-Matos et al. “A Virtual Enterprise represents a temporary alliance of organizations that come together to share skills or core competencies and resources, in order to answer to a specific business opportunity” [1].

The establishment of a VE is triggered by a new business opportunity. Consequently, partners with the skills needed for product development and manufacturing are selected. After the negotiation of contracts for signature, the virtual enterprise is ready to start its operation [2, 4]. Normally there is an entity which performs the processes of partner search and selection, and configures suitable infrastructures for VE formations and commitment. This entity is normally the one that identifies the business opportunity as is known as the VE Broker [2, 5, 9].

Temporality is an important characteristic of virtual enterprises because it seeks to operate in the short run, and aims to achieve business opportunities in the short and medium term. Virtual enterprises are expected to overcome geographic and temporal barriers, bringing together dispersed firms. The prevailing feature of the virtual enterprise is the complementarity of skills between partners, i.e., each network partner dominates a sub-process or has a specific knowledge about a process or product. All partners have to contribute directly or indirectly in creating value. Thus, the combination of skills provides synergy and greater flexibility to meet customer requirements.

3 Research Methodology

This study followed 4 steps. Firstly, we reviewed the existing literature in areas such as virtual enterprise, business activity monitoring, and complex events processing. Secondly, we analyzed a set of open source and commercial Business Process Management Suites (BPMS), which contain process monitoring functionalities. Thirdly, we carried out a requirement elicitation process, which includes semi-structured interviews to 3 different business enterprises: a machinery manufacturing SME located in north of Portugal (Engineer-to-Order business model), an electronic and automation SME located in United Kingdom (Engineer-to-Order) and a big Assembly-to-Order company located in Finland. The results of these 3 steps conducted the process monitoring requirements list, which answers our first research question and functional specification, answering second research question. The fourth step carried out in a set of discussions with the platform development team to understand the integration and technical requirements. This fourth step answers to the third and last research questions. In next section, we introduce the process monitoring specification for virtual enterprises as well as its integration with a complete VE management platform.

4 Process Monitoring for Virtual Enterprises Approach

The Process Monitoring (PM) Component will be an independent component that relies on events as provided by a process execution engine. This way, the PM component can be directly applied to every process engine. This component should provide real time, log ,and performance data relating to the collaborative manufacturing processes. As depicted in Fig. 1, it contains 5 main sub-components: Events Receiver; Real-time Monitoring; Process Analytics; Process Log, and Rules Engine.

Fig. 1
figure 1

Virtual enterprise monitoring components diagram

Full size image

4.1 Events Receiver

The Events Receiver captures the events produced by the Process Execution Engine and stores the relevant event data within the Cloud Storage. The different events may be outlined as follows: Events from the Dashboard and Process Designer will include all activities conducted by brokers regarding the process modeling and optimization. Events from the Process Execution component will include all process execution related aspects. Processes describe the flow of invocation of all other components, including those responsible for gather the raw data related with the manufacturing activities from all partners information systems (e.g., Enterprise resource planning, Manufacturing Execution systems, smart sensors installed on the equipment’s/products which are capable to send information directly to a cloud based data storage).

4.2 Real Time Process Monitoring

The Real-time Monitoring sub-component provides a live view of the ongoing processes, using the same interface as Process Editor Component, so that Virtual Factories brokers may decide to undertake flow adjustments and efficient decisions, in order to improve the performance of the manufacturing processes. Thus, the interface of the Process Model Editor must be extensible, in order to include on click events, change graphic elements properties (e.g., changes the color of a given task depending on its status). In order to provide a graphical representation of the process models, the Process Designer will save the graphical representation of the model into format. In this way the Real-time Monitoring will be able to manipulate and enrich the graphical representation of the model, adding the necessary information to show all the real-time monitoring information as captured by the SPE. The Process Editor will also expose read only behavior mode, and calling interfaces, so that Monitoring can use the SVG option to represent information on top of a specific technology for visualization. Thus, monitoring can show the current execution status of a process model instance.

4.3 Process Analytics

The Process Analytics sub-component provides key performance indicators related to the manufacturing processes and VE partners. Most process analyses are based on the aggregation, correlation, and evaluation of events that occur during the execution of a process. These events represent state changes of objects within the context of a business process. These objects may be activities, actors, data elements, information systems, or entire processes, among others. For example, activities can begin and end, actors can log on and off, the values of data elements may change, and many other events can occur over the typical lifespan of a process instance. The scope of events considered for analysis determines the context envelope of the analysis. In other words, a narrowly scoped process analysis might focus on a single activity, by examining just those events that originated from this activity, its performers, and the resources that are input in and output from the activity. In contrast, a more widely scoped process analysis might include events from multiple instances of a process; involve data sources outside the organization, and events from non-process-centric information systems.

4.4 Process Log

The Process Analytics sub-component allows users to search for finished process instances and visualize historical data in a graphical interface. Serving the needs of both business and IT domain experts to monitor and understand business activities within SOA (Service Oriented Architecture) and Cloud deployments, PM is not only designed to monitor SOA metrics, but can also be configured to monitor KPIs through the Process Analytics sub-component.

4.5 Rules Engine

The embedded Rules Engine may trigger automated actions such as automatic notification of decision makers or automatic reprioritization of work. This configuration allows the automation of certain exception handling mechanisms, and results in the implementation of a simple sense-and-respond environment. Businesses need to measure and evaluate the success of their activities. The user interface allows users to manipulate data and create KPIs, which can be used for performance measurement. First, businesses must define specific tasks, since this allows them to manipulate data and carry out custom data operations. Analyzer tasks are used to organize the flow of functions, It is possible to build KPIs such that they become an inherent part of Process Monitoring. By building KPIs, you build business intelligence.” Once KPIs have been built, this data has to be extracted out of the database.

Rules Engine and Rules Editor sub-components allow the definition of rules based on process execution delays that are evaluated by the Rules Engine. This component throws alerts to the Dashboard, as well as performs actions upon the Process Execution Engine. This Rule engine deals with creating notifications, alerts, and messages that may: Trigger the creation of new process instances, e.g., to write a message that updates an ERP system. Trigger the adaptation of a process, e.g., the automatic selection of a new VE partner/service, to improve delivery time or stop a process and require action from a VE broker.

5 Virtual Enterprise Management Platform Integration

In order to present a visual interface to the VE partners, it is essential to design and develop a user interface component known as ‘Dashboard’. This Dashboard component can be used as the integration platform for monitoring and managing the VE manufacturing processes. This component is supported by other components, such as Data Provisioning and Discovery, Process Designer, and Process Monitoring. All the functionalities are visualized by the Dashboard in four functional groups: Process Design, Process Management, Partner Management, and Application Configuration. The Dashboard serves as a graphical user interface (GUI) to all VE functionalities. By using the Dashboard the user can create process templates and share the best practices with other business partners to improve the Virtual Factory Management process. The Dashboard provides convenience to users through a Web browser based interface, thus enabling users’ access on any device that supports HTML and JavaScript. This component is configurable for VE partners with different roles allowing different views of the VE components.

5.1 Dashboard Overview

The Dashboard will act as a “cockpit” for VE users to see important system information in one single place, right after logging in. After logging in into the Dashboard user interface, the VE users will see a welcome page with an overview of all their manufacturing processes and their status information. Figure 2 presents an ‘Overview of Dashboard Home Page’, where the user can observe the overall high level status information of each of the processes that allows monitoring and controlling the collaborative activities, as needed to run a virtual enterprise successfully. Clicking on the tabs on menu bar will lead to a more detailed view of current processes of a VE user.

Fig. 2
figure 2

Overview of the VE dashboard homepage

Full size image

After logging in into the Dashboard user interface, the VE users will see a welcome page with an overview of all their manufacturing processes and their status information.

According to functional perspective, the Dashboard component can be classified into four functional groups such as Virtual Factory Process Design; Virtual Factory Process Management; Virtual Factory Partner Management and Application Configuration and Setup.

Each group includes different functionalities to realize Virtual Factory Management. For instance, Virtual Factory Process Design contains necessary supportive information related to design a virtual factory. It also provides template suggestions to VE brokers, in order to improve the process design action. This group includes functionalities such as Process Model Management (PMM), Process Model Editor (PME), Process Simulation, and Process Optimization.

The Virtual Factory Process Management deals with the activity that supports the execution, monitoring, and assessment of the business processes. This functionality group includes Real-time Monitoring, Process Log, Process Analytics, and Process Adaptation. When there is any potential risk during the Process Execution, an alert message or notification presents the detailed information to brokers. This alert message includes forecasting of delay or content related information such as “low stock level”. If any process fails, process adaptation should be readily available to overcome it.

The Virtual Factory Partner Management provides basic functionality to maintain the profiles of the Virtual Factory Partners. This profile is populated with both the description of the attributes of the partners related to a specific business service such as capacity and capabilities, production lead-time, price level, KPIs, performance level, etc., and the level of process interoperability that allows them to join in a Virtual Factory successfully. The functionality of this group includes the useful information according to the user needs such as Profile Editor, Partner Finding, and Partner Analytics. The Application Configuration and setup group provides the ability to customize the application, which includes Configurable User Interface, Gateways Configuration, Alarms Configuration, Message Transformation, and Routing Configuration. This allows brokers to customize the process visualization according to their own needs.

5.2 Dashboard Component Structure

The user interface component, ‘Dashboard’ if developed from scratch should include three sub-components such as: content presentation, user navigation, and data manipulation. All these three sub-components can be explained as follows with their corresponding specifications:

  • Content presentation: Developers need to consider the presentation layer of the Dashboard, for instance appropriate chart types, table format, and the content presentation. The display’s parameters such as captions, type of chart or graph, minimum/maximum values, data source, color codes, and others should be defined properly.

  • User navigation: The way the user navigates to other pages and how the pages are linked to each other should be considered. The user navigation affects the usability of Dashboard.

  • Data manipulation: The Dashboard is used to update the Dashboard’s internal database. It is important to ensure the content of Dashboard is up to date, hence the queries must run regularly to deliver information and refresh the data on Dashboard.

The purpose of the Dashboard is to visualize all the functionalities, so it is good to spend the core of implementation time on other design aspects. The Dashboard Component Structure (Fig. 3) gives a basic illustration of the Dashboard architecture. From Fig. 3 it is seen that the core of the Dashboard is the application server. Other sub-components of the Dashboard component can be detailed as in the following paragraphs.

Fig. 3
figure 3

Dashboard component structure

Full size image
  1. a.

    Web Browser: The Client-Side Engine of Vaadin manages the rendering in the Web browser using Google Web Toolkit (GWT). It communicates user interaction and UI changes with the server-side using the User Interface Definition Language (UIDL), a JSON-based language. The communications are made using asynchronous HTTP or HTTPS requests.

  2. b.

    VE Portlet: The VE Portlets are reusable and pluggable UI modules that are managed and displayed in the VE Dashboard. Portlets provide access to other VE Components. A portal page is displayed as a collection of non-overlapping Portlet windows, where each window displays a Portlet. Hence a Portlet (or collection of Portlets) resembles a Web-based application that is hosted in a portal. Some examples of Portlet applications in VE are Order Summary, Stock Levels, Notification, Process Status, etc. The Portlet can be collapsed, removed, and edited. The Portlet can be placed in different position by using drag and drop technique.

  3. c.

    VE Portlet Container: The VE Portlet Container is responsible for aggregating a set of Portlets that are to appear on any particular page. That means, a page can contain multiple Portlets and when the user interacts with one Portlet, it may need the other Portlets to react to the change immediately. The VE Portlet Container executes Portlets and manages their life cycle. It is the runtime environment for Portlets using the JSR 168/286 or WSRP specifications, in which Portlets are instantiated, used, and finally destroyed. The VE Portlet Container is responsible for aggregating the set of Portlets that are to appear on any particular page.

  4. d.

    Component with UI: Several components within the VE need a UI. For instance, Process Designer, Process Monitoring, Process Optimization, Process Forecasting and Simulation, Process Execution, and Process Adaption. For each such component the UI can be designed and decomposed into several Portlets. Although these Portlets are responsible for different functionalities, they cooperate with each other. Therefore, a portal page contains a collection of non-overlapping Portlets.

  5. e.

    User Management: User accounts within the VE platform will be managed. This Dashboard provides a UI to create, edit, and delete users. Roles with different privileges are created to manage the users.

  6. f.

    Session Management: User sessions within the VE platform will be managed. User login information, user actions, and running Portlets will be tracked. Once the client requests are sent to the Web server, they are interpreted into user events for a particular session. Sessions are tracked using cookies.

  7. g.

    Template Management: The configurable VE Dashboard will have a flexible UI to support the needs of different users, which means a portal page may display different Portlets to different users. Therefore, Template Management will allow users to create a role-or user-based view on the VE integration platform.

  8. h.

    Synchronization: The User Management, Session Management, and Template Management need to be synchronized and managed together. The data will be directly loaded from and saved into Dashboard Data store, which could be integrated with Cloud Storage.

  9. i.

    Dashboard Data store: The Dashboard Data store will be used to store all the related data to running a VE. For instance user information, login information, and application setting information, etc.

All the VE functionalities are presented through the Dashboard.

6 Conclusion and Further Research

This paper presents a complete loosely coupled tool capable of supporting Virtual Enterprise brokers in monitoring and controlling their collaborative manufacturing processes by using a holistic monitoring dashboard which uses a set of advanced technologies in order to gather, aggregate and thus, show real time information about their business at the operational level. This Monitoring tool is part of a broader platform developed in the scope of a European project. We propose a loosely coupled solution for the monitoring based on complex events processing and key performance indicators definition based on the overall stakeholder’s point of view. Adopting this solution, VE’s Brokers become capable to have real time information in a flexible way so that it can be used as pillar for decision makers.

Five modules compose this tool: Events Receiver; Real-time Monitoring; Process Analytics; Process Log; and Rules Engine. Events Receiver will be responsible for receiving the events published by the process execution engine and storing them in the Cloud Storage, so that all data will be available for future aggregation and analysis. The Real Time Monitoring will show the actual status of process instances using a holistic collaborative process live model. This way, it will be easy for the user to identify and track the process instances. Process Analytics will be an independent service that just queries finished process instances and show them to the user. The Business Activity Monitoring will be an independent service that will rely on the data stored by the Events Receiver in the Cloud Storage. The purpose is to allow the user to configure KPIs related to the manufacturing processes and then provide a graphical display in the Dashboard in order to track the KPIs. The Rules Engine will allow the user to define rules and associated actions. For that purpose, a graphical rules editor should be developed.

As next steps, we intend to implement this approach as part of a complete collaborative manufacturing environment management platform being developed in the scope of a European project. This platform will then be applied in the case studies identified before.