Fleet-Wide Proactive Maintenance of Machine Tools

Abstract

Fleet-wide proactive maintenance characterizes all services that are made available to the users to help them to operate, supervise and maintain a fleet of systems. These services can be, for a general manager of a fleet, a dashboard of all the systems’ business indicators or, for a technical manager, a dashboard of all the systems’ maintenance and health status. At the bottom level of the pyramidal hierarchy, a technical operator should have a fast overview of the systems’ status and should be alerted at the right time when a system needs to be checked. Nowadays, more and more data and information are available on machine tools which should be treated and analysed to extract the right information for the right people at the right time. To achieve this goal, a fleet-wide proactive maintenance platform requires several main business services to have an understandable view of the system by all users and, thus, save time for decision-making during diagnosis and prognosis analysis.

1 Introduction

From the capacity of production depending on machine tool availability, it becomes a day-to-day concern for maintenance operator and production manager. Each stop in production constitutes a loss of earning that should be anticipated to allow an efficient planning of maintenance operation and to avoid unscheduled production downtime. Condition-based maintenance solutions at a machine level provide the operator with tools that support monitoring of the machine’s behaviour and highlight behaviour changes. However, machine tools as large engineering systems have multiple sub-systems and equipment of different natures (electrical, mechanical, hydraulics, electronics, etc.) following different fault rates and modes in which behaviour may differ from specific phases of their life cycle due to events and maintenance history. Supporting proactive maintenance at a fleet level provides summarized information and means of comparison and investigation for decision-making.

1.1 Fleet-Wide Approach and Industrial Challenges

Originally referred to a group of ships or aircrafts [1], the term fleet is used in the industrial domain to refer to a set of machines, generally the whole of an owner’s system. Technically, the fleet is considered as set of entities composed of similar sub-systems which behaviours are comparable [2]. From the capacity to process a workpiece being the objective of a machine tool, the objective of a fleet of machine tools is considered as its capacity to process a batch of workpieces. Fleet-wide approach of objectives is then twofold: to provide augmented and synthetized information at a fleet level and to provide higher diagnostics and prognostics capacities.

The condition-based monitoring allows to monitor the global behaviour of the fleet, i.e. its capacity to achieve its objectives, by providing indications of the health state of each sub-system. Monitoring the behaviour at a fleet level aims at informing maintenance operators and managers about the health and availability of each machine, as well as the global fleet by merging and extracting information from indicators.

In addition to the benefits for maintenance management, the fleet-wide approach provides tools to improve and capitalize failure analysis and investigation. Indeed, it allows machine behaviours’ comparison and experience feedback sharing at a fleet level allowing better fault detection and isolation. Both objectives require a well formalized and structured knowledge.

1.2 Building the Fleet-Wide Approach

At the bottom of the fleet, the sub-systems attached to a machine tool such as axis, spindle and auxiliary systems such as hydraulic group, coolant, system, cooling system, could be monitored independently from each other. Using condition-based monitoring, it is possible to build behaviour indicators not biased by the characteristics of other sub-systems, thus being able to respond in real time considering the state of each sub-system. Despite being a powerful tool for maintenance operator to ensure a correct and quick diagnosis, the combinatory explosion caused by each indicator with its own dynamic could lead to a deteriorated legibility. The number of alarms and information on the fleet-wide level would exceed human abilities. It is then recommended to build bottom-up fleet-wide approach [3] by monitoring the machine’s sub-system health, to provide information to monitor the machine’s health and, then, the fleet’s health.

The fleet-wide approach allows maintenance operators and management to get a general view of the state of the fleet and support the decision-making to ensure the fleet mission. This approach also allows to compare sub-systems at different levels and uses the results of maintenance and events history to be reused for upcoming events. The challenge of fleet-wide approach is to build tools that support monitoring health states for each level: fleet, machine and sub-systems, and allow the comparisons while not being invasive for users. A knowledge base uniting semantic and systemic approach of the fleet must be considered.

2 Fleet-Wide Knowledge Base Architecture

Health assessment provides relevant information highlighting abnormal health in the monitored component, sub-system or system, but it does not provide the necessary information to identify the root causes to fix the degradation process. For this purpose, a global modelling of the fleet is required at different levels to formalize both the maintenance knowledge and the processes, mainly monitoring, diagnostic and prognostics, to achieve proactive fleet management.

Knowledge modelling rely, first, on the machinery domain-specific concepts formalization, leading to machine tool fleet detailed description and second, to the structuration of the different concepts by the description of both vertical, i.e. between level, and horizontal, i.e. in a specific level, interactions.

2.1 Machine Tool and Related Concepts Definition

In the process of modelling the fleet level using a semantic approach, each level is defined in a vertical approach while clearing the concepts that allow health status definitions and horizontal comparison of the different levels of the fleet. First, different levels are identified, from each a set of definitions and concepts arises, as depicted in Fig. 13.1.

Fig. 13.1

Machine tool fleet representation of the semantic modelling

Focussing first on the machine tools level, its definition is given by “a machine driven by power that cuts, shapes or finishes metals or other materials” [4]. As a large number of machines and concepts could be included in this definition, this work is focused on the general concepts emerging from modern machines tools powered with electrical power and composed of at least one electro-spindle and at least three axes. At this level, the availability of the machine will be consolidated with information concerning the health status of the sub-systems to describe the general status of the machine [5].

The sub-system level describes the functions of the machine tools that are necessary to manufacture the workpiece. This example focusses on the axis unit sub-system that represents the moving parts of the machine necessary for the positioning of the spindle or the workpiece. The axis unit, depending on machine design, can be composed of at least three linear axis and rotational axes. The technologies and features used for conception can be different depending on the designer choice. Considering the diversity of possibility for the components of this sub-system, it is necessary to define a set of rules based on ontology that eases the horizontal level comparison and expertise sharing between equivalent sub-system of other machine tools and their equipment (axis in this example). Four levels to classify the contextual information are discussed in [6] to provide comparison facilities:

• Technical context is the description of a system in terms of technical features. For instance, the three linear axes are composed of linear motor, sliding system, guideline, cooling system associated, etc. Even if the design and dimensions of the component are different, this description allows comparisons of the features of the linear axis to be considered.

• The service context and operational context are complementary to the technical context.

  • The service context aims at describing the solicitations that the system endures. For example, considering the axes of the same machine, the three linear axes are designed for different purpose. As a common nomenclature, the Z axis is parallel to the spindle, while the X and Y axes form the plane perpendicular to the spindle direction; X being defined as the longest of X and Y. The solicitation will be different depending on machining executed along Z axis (e.g. drilling) or executed along X and Y axes (e.g. boring).

  • The operational context defines the operating condition of a system. Using knowledge and information related to the operational context helps to go through the interactions of the systems and build the approach that isolates the equipment characteristics. The operational context could be used to isolate a comparable behaviour of the axes and overlook the interactions between, for example, one axis moving while the other are maintaining their position.

• The performance context is the description of the ability of the system or equipment to accomplish its mission. Mainly depending of the expected performances of the machine itself, the performances of a sub-system are to be used as complementary information to model the knowledge.

At the equipment level, a general approach knowledge modelling and behaviour indicator can be defined using the descriptions associated with the sub-system and the equipment itself given by the semantic study. However, the information about each equipment is visible only through data, making the data acquisition the key for the study of the equipment. The semantic approach aims here at defining the inputs to build the algorithms that compute the indicators combining both sensor measurements, such as current, temperature and the internal control variables such as spindle machining, not machining, targeted position, targeted speed. It is recommended to anticipate the monitoring plan of the behaviour before defining data collection plan.

The semantic definition, while being indispensable to the fleet description, is not sufficient by itself to describe properly the interactions occurring between the sub-systems at different levels, especially for diagnostic purpose. The representation on Fig. 13.2 summarizes the interactions of an equipment with its environment. The input flow coming from other sub-systems can influence the functions associated with the equipment as the output flows depending of the function influence the functions depending on them. A systemic approach describing for each machine, depending on its conception, the functioning and malfunctioning as well as the interactions between the flows is presented below.

Fig. 13.2

Functions of a sub-system and interactions with its environment

2.2 Functional and Dysfunctional Analysis

Once the knowledge of machine tool domain is defined, these concepts are then integrated and structured in a knowledge base to describe each level of the fleet. A systemic approach [7] is being considered to build a description of the machine and its components by its functions (what the components are supposed to do), their consumed or produced flows (how the components interoperate) and anticipate how they could malfunction. Although the malfunction modelling tends to be sufficient to help the process of decision-making, the functional modelling is the start point to structure the root cause analysis.

The functional modelling describes the interoperability of the components and provides tools to identify the probable root causes of the events. Figure 13.3 shows a simplified example of the functional modelling of the three-dimensional axis unit using KASEM^® knowledge modelling tool. The whole view shows how the function “to move the spindle along the X, Y and Z axes”. Hence, the function of the axis unit is operated. This function is refined in three sub-functions representing the three-axis sub-systems as shown by the green arrows. Each of them could then be refined in sub-levels describing the components of the axis such as linear motor, cooling system, guiding system, etc. The arrows represent the flows consumed and produced by the function. In this example, the main purpose of each axis is to produce a mechanical movement, while consuming electrical energy provided by the plant. Each flow here is defined by characteristics, shown with the colour code. The yellow and black arrows represent electrical energy and the red arrows mechanical energy.

Fig. 13.3

KASEM^® knowledge modelling tool—functional analysis of the three-dimensional axis unit

The malfunction of the system is studied using the HazOp—Hazard and Operability—analysis that identifies the possible deviations of the flows in combination with the study of the possible degradations and criticality of the functions provided by FMECA—Failure Modes, Effects and Criticality Analysis. Each flow deviation and function degradation can be associated with a probable cause and/or effect. The causes can be external, such as human intervention, plant conditions degradation, or internal. Using the same logic, the internal causes could be from another flow deviation or function degradation from another sub-system of the same machine. Following this principle, the interoperability between the sub-systems leads to build a root cause analysis of potential malfunctions. For instance, Fig. 13.4 shows the HazOp of the possible deviations of the flow: “adapted electrical energy entering the motor of the Z axis” of the machine tool. Two possible causes were identified here for the deviation “more current while machining”. None of these causes could be identified as root cause in case of a deviation of the flow. Using the causal chain as depicted in Fig. 13.5, some root causes appear at level 2. Using associated monitoring of the possible root causes and manual procedures, the operator then determines the real cause of the detected flow deviation.

Fig. 13.4

KASEM^® knowledge modelling tool—HazOp view of the axis current while machining flow

Fig. 13.5

KASEM^® knowledge modelling tool—root cause analysis view of current while machining deviation

The functioning and malfunctioning of modelling is implemented in the knowledge base of the platform to structure its inference engine. Each event can lead to supply a common feedback of the fleet that helps diagnostic and decision-making by providing the most common cause and root cause for each event type encountered.

2.3 Combination of the General Concepts and Analysis to Build Fleet-Wide Architecture

The systemic approach is combined with a semantic approach, both providing tools that help the fleet management purpose [3]. The semantic approach aims at defining the general concepts related to each level of the fleet. The ontology-based definitions support the characterization of intrinsic rules for a generic monitoring of machines different regarding the design and the components. It also defines the concepts that are necessary to build the root cause analysis that profits from the feedback provided by the fleet-wide management. The systemic modelling is built using definitions from the semantic modelling. The functional analysis is designed for any specific machine design, using only generic functions and flows to represent its equipment and their interactions. The dysfunctional modelling then profits from the generic deviations and degradations commonly associated with the flows and function. Finally, the root cause diagrams can be automatically generated using the information provided by the systemic modelling and profits from the feedback on functions and equipment regarding their definitions.

3 Maintenance Platform Services

To offer support to maintenance personnel, a set of maintenance-related services must be integrated into a dedicated maintenance platform. KASEM^®—Knowledge and Advanced Services for E-maintenance—which is developed, maintained and improved by PREDICT, is a platform that offers such services and is dedicated to proactive and predictive maintenance to help operators and experts to take the right decision at the right time. The efficiency, flexibility and operability of the platform are mainly based on its service-oriented architecture, as depicted in Fig. 13.6.

Fig. 13.6

KASEM^®, service-oriented architecture (SOA) platform

KASEM^® platform integrates mandatory services such as data storage, as well as administration services that regroup all aspects relative to user management (profile definition, user authentication, user rights). In addition, the platform integrates the following services:

• Data Visualization gathers all the tools and ways to communicate a clear and efficient information to the users (statistical graphics, plots, information graphics, tables, and charts) and to help users to analyse data by providing tools adapted to the type of information to be investigated. It aims at making complex information more accessible, understandable and usable.

• Event management gathers all the tools and ways to generate events relative to systems’ status (fault detection, prognostics, health) and to manage these events (validation, cancellation).

• Analysis and Investigation gathers all the tools and ways to analyse and understand events and to take the right decision. It regroups all the possible actions that help to identify the causes of an event.

• Knowledge sharing gathers all the ways to create and consult system’s documentation and information.

In the following, these four main services are discussed.

3.1 Data Visualization Services

To visualize its data, an end-user has three kinds of tools according to the type of information to be checked, the level of details needed or the profile of the user and its expectations:

• Dynamic time series for the visualization of historical raw and computed data set as well as real-time information.

• Custom reports that show specific view of the data set on a specific period.

• Dashboard that shows specific dynamic views based on real-time data information.

Dynamic time series visualization is available into the KASEM^® platform thanks to its integrated E-Visualization tool, which user interface is represented in Fig. 13.7. This tool aims at performing a detailed expertise on systems by analysing systems’ data. It offers from simplest to more advanced capabilities such as:

Fig. 13.7

KASEM^® data visualization: (left) e-visualization tool, (right) built-in charts

• Collected data visualization as time series. Variable curves can be loaded into a graphical display area. Multiple variables can be loaded into a same view, they can be easily scaled (manual configuration of axis, attached to another variable axis) and manipulated (colour, stroke and point types, display type).

• Reusable contexts creation. Indeed, the tool allows to save all the loaded variables of a graphical display area and their custom setup into a context that is reuseable. By this way, it is possible to load a memorized context into different periods to compare situations.

• Built-in tools to analyse situations such zooming, filtering or comparing variables. Moreover, user can perform histograms and XY graphs.

Hence, KASEM^® e-Visualization offers to a user the capacity to easily manipulate and analyse systems’ historical or real-time data set. It fits well for performing expert analysis on a system but has limited capacity of synthesization.

To this purpose, report or dashboard definition is required. Reports and dashboards allow to visualize information in an organized way and to perform further analysis or point out advanced information built from raw variables. They both aim at having a focus on specific aspects of a dataset, yet they differ from several aspects.

A report is defined as a document that contains information organized in a narrative, graphic or tabular form and aims at being communicated or presented in oral or written form. On the other hand, a dashboard characterizes “a visual display of the most important information needed to achieve one or more objectives”. Table 13.1 summarizes the main differences.

Table 13.1 Report and dashboard differentiation

Examples of specific views that can be extracted from knowledge base data are presented in Fig. 13.8. On the left, a radar chart that is sent each week to specific user is shown. This chart displays an overview of the amount of data collected from its machine tool’s fleet. On the right, an example of dashboard displaying machine tool system usage data.

Fig. 13.8

Examples of advanced data visualizations: collected data report sent periodically by e-mail (left), system usage Web dashboard (right)

Data visualization service is one the most important features for Operation and Maintenance, allowing to create specific static or highly dynamic views per user core business and user level of knowledge about the system. Today, in addition to be user-adaptive, this service must also be device-adaptive to fit all displaying technologies: desktop, laptop, tablet, smartphone and smart watches.

3.2 Event Management Services

An event is a message indicating that something has happened on the monitored system. From Prognostics and Health Management (PHM) point of view, an event can, for example, symbolize that the system behaviour has changed or that there is a high risk of faults [8]. Event management service has, thus, several roles: to generate events and notify users that event occurs, as well as to provide tool to follow event life cycle.

Event generation is the part of the service in charge of running data analysis algorithms on new collected data from monitored systems. Elementary services of data manipulation are orchestrated to build up the platform knowledge and to generate alert as illustrated in Fig. 13.9. In this figure, algorithms are depicted in grey, collected data in green, and white elements represent part of the computed knowledge. The event, illustrated in blue, is generated at the end of the algorithmic chain.

Fig. 13.9

An example of an algorithm chain for event generation, from raw data to proactive event

For a given event, once the sequence is computed and if the event is active, it is necessary to prevent the right users. According to the application, these users can be defined within event level and location. User is alerted that a new event has occurred by e-mail, SMS or thanks to notifications that can be pushed up on a smart mobile device. Then, the users need to have tools to follow-up all events which they are responsible of.

PHM events are mainly linked to degradation anticipation and degradation detection. Events represent state changes in the spatial discretization of the faults metrics. They can, hence, evolve when metrics increase and decrease, but also disappear. Generally, for a given event, its level is represented by an integer number between 1 and 10 (the highest the level is, the closer of the degradation it is). To follow the status of active events, the KASEM^® events console, reproduced in Fig. 13.10, summarizes all details about the last evolution of each active events:

Fig. 13.10

KASEM^® event console

• Event occurrence and last state dates;

• Location of the equipment (component, sub-system or fleet) attached to the event;

• Description and type of the event;

• Level of the event;

• Additional buttons to visualize event data.

3.3 Analysis and Investigation Service

An event occurs when an abnormal behaviour has been detected. Analysis and investigation service is then necessary to explain what the causes are—diagnostic—and the consequences—prognostic—of this event. This analysis and investigation process is organized in a workflow and results in event analysis and capitalization that improves event feedback.

The KASEM^® workflow process is schematized in Fig. 13.11. It consists in a sequence of interactions and actions between the platform, the system and operators. The different steps are:

Fig. 13.11

KASEM^® event analysis and investigation workflow

• Preliminary analysis: In this step, the event veracity is checked by a user. If a true event has occurred, a diagnostic can be performed for this event. In other cases, the event is rejected.

• Diagnostic: In the field of investigation, this step aims at identifying the potential causes of the event and it can potentially result in consequences identification. This step can be completed by performing analysis to refine the diagnostics. When the diagnostics are accepted, i.e. when the causes have been identified, the event analysis can be finalized.

• Analysis: This phase aims at refining the potential causes by querying complementary analysis. After an analysis, further diagnostic may be performed if needed or the event may be finalized or rejected.

• Finalization: In this step, the most probable cause is selected, event is closed, and the overall analysis is stored into the knowledge base to expand available experience feedback.

The experience feedback is all the accumulated information about causes and consequences that have been held on the different events of a system. It aims, on the one hand, at optimizing the decision-making process when an event appears; and on the other hand, at pointing out recurrent problems towards the objective of continuous improvement of the system.

Experience feedback is improved with fleet dimension as it is shared by all its individuals. Hence, the bigger is the fleet, the greater is the feedback. Nevertheless, to cope with individuals’ heterogeneity a knowledge model based on ontology should be used for better reuse of data, like maintenance history, reliability analysis, failure analysis, data analysis at fleet level to provide knowledge from similar but non-identical systems [6].

3.4 Knowledge and Information Sharing Service

From a system context, the knowledge defines all the documentation, analysis, schemes and any element that make a system more comprehensive. Through KASEM^®, the knowledge storage as well as the knowledge creation is made available. Indeed, it is possible to add documentation relative to a system, a sub-system or a component. Moreover, it is possible to perform and store advanced system analysis like functional and dysfunctional analysis.

Sharing service includes ways to exchange information from the platform. KASEM^® Representational State Transfer—REST—API enables automatic exchange of information with other platforms or tools. The API provides a secure and accredited access to the business-oriented Web services. Information can thus be read or written by executing a simple HTTP request. This offers a high level of interoperability with all conventional languages such as .Net, Java and Python.

Hence, the platform enables to:

• centralize and provide easy-to-access documentation and information for all the users;

• share up-to-date information to all the users by providing direct access to newly created information.

4 Conclusion

This chapter presents advanced services that are required for a fleet-wide proactive maintenance platform to provide the right information at the right time to the right person and to assist this person in decision-making. For this purpose, advanced operation and maintenance services like data visualization service, event management service, analyse and investigation service and knowledge sharing service must be provided. Within Twin-Control project, the platform KASEM^®, developed by PREDICT, has been deployed to centralize data and knowledge on twelve machine tools and several generic algorithms have been developed to evaluate machine health and generate early detection events to anticipate machine failure.

Flexibility is a key point in the SOA platform for operation and maintenance services [9], and there are two levels of flexibility. Service-oriented architecture is the first level with the possibility to only use needed services and thus only pay for the used services. The second level of flexibility corresponds to service itself that must fit with the application constraints.