• Aucun résultat trouvé

Proposal of an event filtering approach to improve the reactive management of complex industrial systems

N/A
N/A
Protected

Academic year: 2021

Partager "Proposal of an event filtering approach to improve the reactive management of complex industrial systems"

Copied!
24
0
0

Texte intégral

(1)

HAL Id: hal-01876090

https://hal.archives-ouvertes.fr/hal-01876090

Submitted on 18 Sep 2018

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Proposal of an event filtering approach to improve the reactive management of complex industrial systems

Philippe Pesin, Damien Trentesaux, Christian Tahon

To cite this version:

Philippe Pesin, Damien Trentesaux, Christian Tahon. Proposal of an event filtering approach to improve the reactive management of complex industrial systems. Journal Européen des Systèmes Automatisés (JESA), Lavoisier, 1998, 32 (4), pp.487-508. �hal-01876090�

(2)

Proposal of an event filtering approach to improve the reactive management of

complex industrial systems.

Philippe Pesin  Damien Trentesaux   Christian Tahon 

Laboratoire d'Automatique et de Mécanique Industrielles et Humaines, Equipe Génie Industriel et Logiciel, Université de Valenciennes et du Hainaut Cambrésis, Le Mont Houy , BP 311, 59304 Valenciennes Cedex, France

{pesin, trentesaux, tahon}@univ-valenciennes.fr

ABSTRACT. This paper contributes to decision making support for the reactive management of complex industrial systems. In this context, human operator integration is very helpful to manage complexity. Both decision maker and computerized systems must be able to recognize context and system state in fixed time-span. So, it is necessary to provide the best context as possible to decrease adaptation time. But, decreasing adaptation time is useful only if decisions are focused on the most relevant events. This paper focuses on the event management issue. In order to cope with this problem, efficient event characterization and filtering are required. Existing approaches are criticised and a new one is proposed. It is based on the integration of an accurate event typology in an event filter concept. This filter manages a list of events ordered by processing priority. Then, relevance of our proposals is shown in the case of a distributed production activity control structure.

RÉSUMÉ. Cet article contribue à l’aide à la décision pour la gestion des systèmes industriels complexes. Dans ce contexte, l'intégration de l'opérateur humain permet de gérer la complexité. A la fois le décideur et les systèmes automatisés doivent être capables de saisir le contexte en un intervalle de temps fixé pour améliorer la gestion réactive. Ainsi, il est nécessaire de fournir le meilleur contexte pour diminuer le temps d’adaptation. Mais, réduire ce dernier est utile seulement si les décisions sont focalisées sur les événements les plus significatifs. Cet article traite du problème de la gestion des événements. Pour résoudre ce problème, une caractérisation et un filtrage efficace des événements sont requis. Les approches existantes sont critiquées et analysées, et une nouvelle est proposée. Elle est fondée sur l'intégration d'une typologie d'événements détaillée dans le concept de filtre événementiel. Ce filtre gère une liste d’événements ordonnés selon leur priorité de traitement.

L'intérêt de nos propositions est alors montré dans le cadre d'une structure de pilotage distribuée d'un système de production.

KEY WORDS: reactive management, complex industrial systems, decision support, event typology, event filter, production activity control.

MOTS-CLÉS: gestion reactive, systèmes industriels complexes, aide à la décision, typologie d'événements, filtre événementiel, pilotage des systèmes de production.

(3)

1. Introduction

In the field of reactive management, decisions are the interface between data provided by a reporting function and orders transmitted to a control one. One of the most important issues is related to the ability to build decisions compatible with global goals taking into account complexity. In fact, reactivity highly depends on decision quality. Nevertheless, it is hard to reach a satisfying quality level because of numerous constraints and inadequacy of existing tools. This is why a contribution to the improvement of decision quality is proposed.

This paper deals more especially with the event management activity. This activity corresponds to the intelligence stage of the decision process model defined by Simon [SIM 77]. This stage focuses on conditions requiring decision making and selects necessary data for the next stages of the decision process.

This paper consists of sixth parts. The first one describes the general set of problems associated to decision making in a reactive management context.

Importance of the management of events is shown. The second one focuses more especially on the set of problems related to the management of events and on associated requirements. The third one describes existing approaches to manage events. The fourth part analyses these approaches. The fifth one proposes an event management approach based on the integration of a suitable typology to an event filter concept. The last one proposes an application of the concepts proposed. An illustration is given in the context of a specific distributed reactive management structure dedicated to the production activity control.

2. Reactive management and decision making

2.1. Reactive management and complexity

Industrial systems studied are complex ones according to the operational definition of complexity given in [TRE 97]: large number, multiplicity of types of material resources and human components, strong interactions between these resources and components, presence of disturbances (breakdowns or unpredictable events).

Reactive management system is responsible for the real-time industrial system progress, taking into account both scheduled events and dynamic evolution of the industrial system. Industrial system complexity implies to consider the reactive management system as complex if capabilities of the industrial system do not allow to easily reach goals. It is then important to manage complexity, e.g., to use special methods to react in front of unpredictable events, to reach compromises, ... The reactive management system has then to manage numerous decision parameters and

(4)

data and supports highly coupled decision parameters and badly structured data, corresponding to two types of complexity: decision and data complexity [PES 97].

In addition, nowadays managers have to adapt themselves to short term evolutions of the environment (e.g. the market in the case of production systems), increasing the difficulty for the reactive management system to manage goals and, as a consequence, increasing the difficulty to provide an efficient reactive management.

In this context, integration of the human operator solves parts of this issue as enlightened below.

2.2. Relevance of the integration of the human operator

It has been shown that integrating the human operator highly helps to manage reactive management system complexity mainly because [TRE 97]:

 Reactive management system can not handle itself all possible events, although it can be designed to face the most common and possible ones,

 The decision maker owns context-dependant knowledge that can not always be integrated to the management system.

In order to be optimised, this integration should take into account separate abilities of the reactive management system and of the human operator. The reactive management system, when computerized, is more able than the human operator to manage huge quantity of data and to provide high calculation speeds. Nevertheless, contrary to the human operator, this system is not good in reasoning and in recognition of ill-structured states, and, as a consequence, in decision making. This is why those tasks are devoted to the human operator. In this context, the decision maker is confronted with decision management problems entailed by decision complexity.

2.3. Decision management set of problems

The major constraints in our context are the optimisation of the human operator integration and the increasing of responsiveness, so as to provide to the decision maker ability to recognize context and production state in highly constrained time- span [TRE 97]. Now, decision complexity features (i.e. multiplicity, type diversity for objects of decisions, dependencies, non structuring) and decision management constraints (i.e. temporal constraints) are inconsistent with accurate context analysis and problem perception. So, providing the decision maker with the most suitable context decreasing its adaptation time is very relevant because it drastically improves decision circumstances quality. In this context, connecting generic decision contexts with generic decision families could be very fruitful.

Nevertheless, decreasing adaptation time and time devoted to decision making is relevant only if decisions are focused, as a priority, on the most significant data. It implies an efficient data management.

(5)

3. Reactive management and data management

3.1. Data management set of problems

Data management problems are entailed by data complexity. Data complexity corresponds to the upstream part of complexity. In fact, decisions are triggered by particular data: the events. An event describes every situation detected by the reporting system entailing a modification of the system state likely to trigger a decision [ROU 95]. Events are characterized by conditions on state variables or on combinations of state variables [VER 95], are instantaneous and dated [CAU 97]. As a consequence, the set of problems is more especially an event management set of problems entailed by event complexity (i.e. multiplicity, type diversity, dependencies, non structuring). In this context, focusing on the most significant events requires, on the one hand, to characterize the different types of events that may occur and, on the other hand, to filter the most relevant ones according to their features.

3.2. Requirements for an efficient event management

This paragraph lists the main topics that have to be taken into account to get an efficient event management. These topics are arranged in groups according to three categories.

3.2.1. The influence of the event on the system

It is important to evaluate the consequences of an event on the system compared to goals because goals are the reference to reach. So, this comparison contributes to evaluate the consequences on the behaviour of the system. It is advised to process as soon as possible what could be noxious for the system in order to avoid important drifts. For example the detection of a differential between the real processing time and the forecasted processing time for a task is inconsistent with goals.

The influence of a noxious event can be detailed thanks to criticity levels:

 Criticity level related to the origin of the event because some parts of the system are more critical than others. For example, in the case of a nuclear plant, what is related to the reactor is more critical than what is related to elsewhere.

 Criticity level related to the seriousness of a disturbance itself without considering its origin. For example, in the case of job shop scheduling, the bigger the differential between real and forecasted processing time of a task is, the more serious the perturbation is.

(6)

3.2.2. The temporal point of view

Reactivity is linked to the adaptation time of the decision maker. With a view to decreasing adaptation time, temporal informations about events are necessary because they contribute to optimise the scheduling of the processing of events. Three topics have to be considered:

 The occurring time of the event because it allows to situate the event with comparison to others. It is the basic information to perform a scheduling,

 The amount of time available to start the processing of the situation characterized by this event. It is a second information to optimise scheduling because events simultaneous with situations have usually to be taken into account before forewarnings. For example, if a domain tolerance is defined for each machine, the event “beyond tolerance” represents an immediate situation. On the contrary, the event “quality decreasing” represents a future perturbation on the machine,

 The amount of time required to process the event because, with a view to optimising scheduling, this information allow to adapt the scheduling of the processing of events to the workload of the decision maker.

3.2.3. The interface with the decision level

The goal is to reduce adaptation time and time devoted to decision making. This is why it is necessary to establish links between data (the events) and decisions. In this context, two topics have to be considered:

 The decision level usable: it is linked to the knowledge of a known strategy or not to cope with the consequences of the event. In fact, according to situations, the level of knowledge to use is different. For example, according to their seriousness, answers to perturbations on machines can be more or less complex and can require different reasoning modes.

 The ability to take into account problems related to context. Two families of states have to be considered: basic states (e.g. raw resources and operations states in the case of a production system: breakdown of a resource, end of an operation,...) and calculated states or performance indicators (e.g. breakdown rate). Indicators are a quantified data measuring the efficiency of the global system or of a part of this system compared with a standard or a goal [GAL 88]. In fact it is necessary to clearly distinguish objects of decisions and contextual informations.

4. Existing tools for the event management

In this part, some state-of-art tools for the event management are described.

The two introduced aspects correspond to the two subsets of problems entailed by the data management set of problems.

(7)

4.1. Existing event characterization tools 4.1.1. Baillet’s approach

P. Baillet [BAI 94], in the context of production systems, distinguishes perturbations according to the works of A. Cauvin by taking into account three criteria:

 Event understanding by the studied system:

- Known event: the strategy to process the event is completely decided by the system,

- Unknown event: the system is not able to determine a strategy to process the event but can contribute to process it.

 Ability to forecast a known event by the system:

- Forecasted event: its occurrence is consistent with the forecastings and doesn’t disturb the forecasted system progress.

- Unforeseen event: its occurrence is not scheduled and it can disturb the progress of several tasks and even the production goal.

 Impact of the perturbation on the studied system:

- Weakly perturbing: the unforeseen event doesn’t force to modify the schedule of the production system.

- Moderately perturbing: the unforeseen event has only an impact on the production system.

- Strongly perturbing: the perturbation has a detectable impact on the outputs of the production system.

4.1.2. Roubellat and Billaut's approach

F. Roubellat, in the context of the real-time scheduling of a workshop, distinguishes two classes of events [ROU 95]. On the one hand expected events appear as soon as the workshop is in a given state and, on the other hand, unexpected events are related to perturbations in the system.

Those classes allow to group the finite set of states listed by J.C. Billaut and F.

Roubellat [BIL 96] [ROU 95]:

 Expected events are divisible in four types: end of operation processing, end of operation transportation, end of resource breakdown, end of operation blocking.

 Unexpected events are divisible in two types: resource breakdown, operation blocking.

4.1.3. Perraud's approach

F. Perraud, in the context of the event-based modelling of the real-time reactive management of workshops [PER 96], distinguishes, on the one hand, expected events, systematically appearing when the system is in a given state (e.g. at the end of a task, after a repairing activity,...) and unexpected events related to perturbations

(8)

on resources or on operations. On the other hand, she distinguishes external events generated by the environment of the production system (e.g. orders from the clients) and internal events generated by the system itself (e.g. breakdowns on resources).

4.1.4. Neubert’s approach

G. Neubert, in the context of perturbation management, distinguishes two types of events [NEU 96], first, according to their consistency or not with goals and, second, according to the existence or not of a known strategy to cope with them.

According to him, expected events and strategies to manage them are well known (e.g. adding a new order) and they do not endanger the goals and the global strategies. Disturbances endanger the reaching of goals and require the elaboration of new strategies to cope with them (e.g. unexpected breakdowns).

4.1.5. Sachs' approach

In the context of ESCORT [HAT 91] [MIL 88] [SAC 86], an environment dedicated to the design of expert systems managing informations from a continuous process controlled by an operator, two main categories of events are distinguished:

events likely to entail an alarm and the others.

Processing priority between events likely to entail an alarm is based on:

 The criticity of the area from where the event comes,

 The criticity of the alarms the event is associated to.

4.1.6. Other typologies

P. Baillet [BAI 94] describes other existing approaches for perturbations:

 Perturbation approach according to their origins: D. Gendreau [GEN 91], in the context of a flexible cell distinguishes external and internal perturbations.

External ones are divisible according to inputs and outputs. Internal ones consist in problems about the production system.

 Perturbation approach according to their impacts - A. Cauvin's typology: P. Baillet's one is based on it.

- B. Archimède's approach [ARC 91]: He distinguishes four types of problems: incident, intrusion (those perturbations are reported and processed as soon as they appear; moreover, intrusion processing is more difficult than incident one), drift, disruption (these two problems are induced by the deficiencies in the reporting function).

(9)

4.2. Existing event handling tools

4.2.1. The event handling in the ESCORT system

ESCORT [SAC 86] is a decision support system for the alarm management, which applies to the management of events. Three important issues are considered:

the alarms are often a logical combination of events and of perturbations, the waterfall effect of alarms if variables are connected to each other, the establishment of a hierarchy of simultaneous alarms appearing on disjunctive sub-systems.

Four main functions appear in the system [HAT 91] [MIL 88]:

 filtering: events likely to entail an alarm are detected (primary events),

 first priority affectation: affectation of a first priority to the primary events,

 diagnosis: event analysis in order to find their causes and the problems they entail,

 last priority affectation: according to the importance of causes, problems are transmitted to the operator.

4.2.2. The event handling in the ORCA system

ORCA [TUR 94] is an adaptable reasoning system dedicated to the control of autonomous under vehicles. In its first versions, event handling is performed by a simple process described by the functional decomposition of figure 1:

Figure 1. First ORCA event handling system

Turner proposes an improvement of this event handling system to cope with the drawbacks of the sequential organisation of functions. In fact it is inefficient when different levels of diagnosis are possible. The goal is then to make the diagnosis at a level where the selected response will be adapted to the event. Nevertheless he does not consider the case when more than one event occurs at a time.

Event detection Change in input stream Message from an other agent or user Fault/info from lower level architectures

Event diagnosis

Importance assessment

Response selection

No event Not important

End End

fuzzy rules system (default rules + contextual rules)

based on the consequences of the event and on the context

a goal is placed in the agenda manager

(10)

5. Analysis of existing tools

5.1. Analysis of existing event characterization tools

In fact, one can note that existing event characterization tools are typologies.

Nevertheless, they are too general and/or too incomplete regarding our requirements.

The main drawbacks of these typologies are:

 Influence of the event on the system does not clearly appear:

- Goals are not clearly taken into account in [ARC 91], [BAI 94], [BIL 96], [ECH 96], [GEN 91], [ROU 95], [SAC 86] except in [NEU 96] where the notion of goal explicitly appears but without detail. So it is not possible to evaluate if the consequences of an event on the system evolution are positive or negative.

- Criticity of the events relatively to their origin and to their seriousness is not taken into account except in [ARC 91], [BAI 94], [SAC 86]. In the first two cases, it is hard to associate a perturbation to a category; the sharing is open to criticism because it could be more accurate. In the third case, two parameters are used to define a criticity (area and associated alarm). So, in most of the cases, it is not possible to form events into a hierarchy according to the area or the function they are related to.

 Temporal point of view never appears: no temporal indication is given about the information brought by the event and as a consequence no information related to the time available to process the event [ARC 91], [BAI 94], [BIL 96], [ECH 96], [GEN 91], [NEU 96] [ROU 95], [SAC 86]: for instance, does the event anticipate a significant state of the system or is it simultaneous with such a significant state? So informations required to perform an efficient scheduling of the processing of events are not available,

 Weakness of the connection with the decision level:

- In most of the cases, no indication about the existence of different decision levels according to the existence of a known or unknown strategy to cope with the event implications is given [ARC 91] [BIL 96] [ECH 96] [GEN 91] [ROU 95] [SAC 86]. In the other cases it weakly appears. So it is not possible to establish a reliable connection with the decision management problem,

- When listed [BIL 96] [ROU 95], classes of events are too restrictive because they only consider basic states without possible combinations. So, it is not possible to introduce context notions.

Moreover, two other drawbacks appear in these typologies:

 It is not obvious to have a relationship between adequacy of an event with the goals and known or unknown strategy to manage it [NEU 96]. So these features have to be clearly distinguished,

 It is not obvious to have a relationship between the fact that an event is forecasted or not and the fact that it is good or bad for the system [BAI 94]. So these features have to be clearly distinguished.

(11)

5.2. Analysis of existing event handling systems

Two main drawbacks appear with a view to performing an efficient filtering:

 Discrimination of events is based on very weak tools in the two cases. So it is not possible to clearly distinguish the different types of events in term of features,

 The case when more than one event occurs at a time is not considered in the second case. So it is not compatible with data complexity assumptions entailing huge amounts of events to manage and dependencies.

Nevertheless some important issues to consider for the implementation of the event handling system are stressed: detection, influence of context, evaluation of consequences, waterfall effect, forming of events into a hierarchy according to their importance. These issues are very closed to those encountered in the field of alarm management [CAU 97] [MIL 88].

This is why, according to those analysis, we propose in the next part an event management approach compatible with the previously introduced requirements.

6. Proposal of an event management approach

6.1. General assumptions

Three general assumptions are made about the studied system:

 It can be described by a set of observable parameters called state variables [VER 95].

 Its state at time t [VER 95] is defined by the set of the values of the state variables at this moment.

 Events are materialized by conditions on one or more state variables (basic states or performance indicators (calculated states)). Goals are expressed thanks to tolerance domains on one or more state variable(s).

6.2. General approach selected

To help the user to focus on the most significant events, an ordering of events by processing priority is suggested. We propose the design of categories of events to define priority rules. Each category has or does not have a processing priority on the others and is characterized by constraints on a set of selected features. The problem is then to isolate typical features of events. As a consequence, it is necessary to provide a means to characterize events so as to isolate their typical features.

Typology is particularly well suited to isolate typical features of events.

Nevertheless, as shown before, typologies compatible with the described

(12)

requirements do not exist. This is why a typology is proposed to allow the ordering by processing priority.

6.3. Proposal of an event typology

This paragraph describes all the features of the proposed event typology so as to allow an ordering of events by processing priority. Features corresponding to the requirements described before are listed:

 Compatibility / incompatibility with goals: is the event compatible or incompatible with goals? Each of the goals is translated in term of conditions on one or more state variables (see the third assumption). For example, if goals are defined as a tolerance domain on one or more state variables, compatibility with goals means that the state(s) variable(s) is (are) inside the domains.

 Seriousness: it is a more accurate characterization of an event in the case of incompatibility with goals. It allows to estimate its noxious effects on the system.

Several scales of criticity could be chosen. A good one could be of the same type of this one used in FMECA method.

 Level of emergence: is the event is related to the global system or only to a part of the system? In this context, it is possible to consider three level of emergence of the event: global, local and intermediate.

 Physical location: to what physical part(s) of the controlled system the event is related to? In this context, it is assumed that the system is decomposed according to a defined strategy. According to this decomposition, an event can be affected to a part of the system which is more or less neuralgic. It is assumed that a criticity of parts of the system has been established.

 Functional location: to what functional part(s) of the control system the event is related to? In this context, it is assumed that the reactive management system is shared into functions and a criticity is affected to each of the functions distinguished.

 Occurring time: it is a simple but interesting characteristic to do a better distinction between events. It represents the accurate date when the event appears.

 Precedence/simultaneity with situations: is the state variable(s) defining the event is (are) simultaneous or precursor to the situation it is supposed to represent?

Precedence with situations means the event appears during a defined amount of time before the triggering of the situation it represents. Simultaneity means the event appears just when a situation appears or in a restricted domain centred on the occurring time of the situation. In fact it is the result of the comparison between the occurring time of the event and the predicted occurring time of the situation it represents.

 Amount of time to process the event: it represents the estimated amount of time necessary to cope with the event.

 Programmed / non programmed: is the event expected or unexpected?

Expected in our typology means there's a programmed, partially programmed answer to the event, and unexpected the contrary. So it provides keys to know how it will be

(13)

possible to solve the associated problem (automatic solving, man-machine solving,...).

 Decision level: to what level of the decision hierarchy belongs the event?

According to the decision level, the event will require a decision or will describe the context of the decision-making (in the case of a multi-level decision structure).

6.4. Proposal of an event filter concept

The design of an event typology is necessary but not enough to establish an operational ordering of events by processing priority. This is why this part describes its integration in an event management system.

The use of the event filter concept is relevant because, thanks to its use, the typology becomes operational. In fact, events, as soon as they are detected, are automatically ordered thanks to the association of defined features to them.

6.4.1. Event filter principle

The filter is a part of the event management system and consists in three basic functions: acquisition and typing and classification as shown in figure 2:

Figure 2. Operating mode of the event filter

Its originality is more especially based on:

 The existence of a typing function separated from the acquisition one,

 The operating mode of functions based on a detailed event typology.

 Its possible integration in a distributed and multi decision level architecture.

6.4.2. Operating mode of the filter

The description of the operating mode supposes that the three assumptions are verified. Moreover, it is assumed that every type of event that is likely to happen in the system and its generic features have been listed. Two types of features are distinguished. Fixed features explicitly described and non fixed features described through the means to obtain them. Among these features all the features included in the proposed typology appear. Most of the features of the event typology are non- fixed features.

EVENT ACQUISITION

OF THE EVENT

LIST OF EVENTS CLASSIFICATION : INSERTION OF THE EVENT IN THE LIST ACCORDING TO ITS PRIORITY TYPING OF

THE EVENT TYPED EVENT

LIST OF UPDATED

EVENTS

(14)

Acquisition function is specialized in the detection of every event from the complex industrial system. At any time, it tests all the significant changes (i.e.

changes with sufficient amplitude) in state variables associated to events listed. As soon as the changes correspond to conditions for a given event, an occurrence of this event is created. The acquisition function only selects events with level and area features corresponding to the decision level and decision field of the studied filter.

Only the fixed features are known whereas other features will be calculated by the typing function.

Typing function calculates and adds the non fixed features to the occurrence of the event as soon as it is created so as to obtain all the features of the proposed event typology. At the end of this stage the occurrence of the event is completely characterized in term of features.

Classification function receives occurrences of events from the typing one.

Thanks to an expert system approach using rules based on event features, a pending list of events ordered by processing priority is updated. If the priority of the event is higher than the others, it is placed before in the list and will be processed before. The classification strategy is made so as to avoid the worst consequences on the system.

This is why priority is given to the processing of more critical events for the system performance.

When an event occurs, in a first approach, ordering by priority can be performed thanks to a lexicographical approach testing criteria for example in this order:

 Incompatibility or compatibility with goals: this is the first criterion used because an incompatibility with goals endangers directly the global performance of the system. So the processing of events incompatible with goals has priority,

 Seriousness: in the case of incompatibility with goals, processing of events with the highest criticity has priority,

 Criticity of areas or functions: this is the third criterion used because some parts of the system are more critical than others. So the processing of events coming from the areas or functions with the highest coefficient of criticity has priority,

 Tests on simultaneity or precedence of events: it is logical to focus especially on immediate situations rather than on future situations. So the processing of events simultaneous with situations has a higher priority,

 Test on the occurring time of events: the last criterion for the selection is the fact that priority is given to the oldest events.

But this lexicographical approach has drawbacks. In fact, it is very hard to establish a clear priority between criteria. This is why a multicriteria selection would be more effective.

6.5. Advantages of the proposal and associated issues

The main advantages of the use of the proposed event management approach are:

 The power of the integrated typology. In fact it helps focusing on the most significant events because it is a very complete and accurate one. On the one hand, it

(15)

integrates features allowing to define processing priorities between events. On the other hand, the accurate description of events and the integration of the interface with the decision level will facilitate decision making.

 Optimisation of the data management: complexity is reduced thanks to the event list concept,

 Parametrization: it is very easy to operate priority changes between parameters, to add or suppress parameters according to the will of the decision maker,

 Modularity: clearly separation of functions makes the implementation easier,

 The possible integration in a distributed architecture thanks to the simplicity of the event filter concept: one event filter can be associated to each decision centre,

 The possible integration in a multi decision level architecture.

Nevertheless, the application of the filter based on the proposed typology in an industrial context entails some problems:

 The storing of data: it requires the building of a database of events. It requires, first, to make an inventory of all the potential events by questioning users of the future system. Then the difficulty consists in translating the acquired knowledge in the database formality proposed and to manage the huge quantity of data. It will result in a basic database. Through its operational use, it will be necessary to enrich it every time a new event or situation will appear, in order to correct mistakes,

 The time constraints: to cope with time constraints, it will be necessary to experiment the different classification approaches to chose the best one and to focus only on the most significant features.

7. Application of the proposed concepts

7.1. Design of the database

As described before, the filter requires the design of a database (or of several databases linked to different filters) containing the different types of events that are likely to appear in the system with their generic features. Fixed features are explicitly described whereas non fixed features are described through the means to obtain them. To make easier the use of data in the context of the filtering, a practical description of events thanks to objects with basic attributes is proposed. The notion of object corresponds to the notion of occurrence and the notion of attribute corresponds to the notion of feature.

The list of generic attributes to consider is build on the basis of the works of [BON 95] [LOR 96] and contains:

 The name of the event (1),

 The textual definition of the event (2),

 The state variable(s) on which the event is based (3),

The state variables are also described with objects grouping basic attributes:

(16)

- Name,

- Textual definition, - Use of this state variable, - Goals (value and date), - Reference (value and date), - Level,

- Updating mode: event based (when the state variable changes) or periodic (according to a given period T),

- Calculation formula, - Unit,

- Location of the data required for the calculus of the state variable, - Definition domain (discrete or continuous),

 The condition(s) on the state variable(s) entailing the triggering of the event (4),

 The domain of compatibility with goals for the state variable(s) (5),

 The list of physical area potentially affected by the event (6),

 The list of functional area potentially affected by the event (7),

 The seriousness level according to the value(s) of the state variable(s) (8),

 The type of event: precedence or simultaneity with a given system state and the estimated amount of time between the occurring time of the event and the occurring time of the situation it represents according to the value(s) of state variable(s) (9),

 The estimated amount of time to cope with the event according to its features (10),

 The fact that there are programmed or non programmed answers according to the value(s) of state variable(s) triggering the event (11),

 The decision level affected by the event (12).

Features 1 to 3 are general informations about the event and features 4 to 12 correspond to the features of the event typology.

Assuming the existence of such a database, an illustration is proposed.

7.2. Illustration

In the chosen context, the complex industrial system studied is a job-shop scheduling system. As a consequence, production activity control function corresponds to the reactive management function.

7.2.1. Context

The illustration is performed on the platform designed by D. Trentesaux [TRE 96] simulating distributed production activity control. Here, production activity control structure is shared between a set of cooperative agents. Each agent is composed of different sub-systems such as decision, communication, interface,

(17)

information and control sub-systems and is called Integrated Management System (IMS). Each IMS controls a set of production resources and the tasks are processed on products. Two kinds of cooperation control can be defined: horizontal (between agents) and vertical (between agent and the human operator as a supervisor). The human operator has the responsibility for decision making (vertical cooperation through a Decision Support System (DSS)). Each IMS has the responsibility for the local production control and for the communication with other IMS (horizontal cooperation through a communication means), as shown in figure 3. A communication protocol has been developed and is based upon negotiation when manufacturing orders are to be exchanged. The basic principle is the following:

when a task (operation), which is part of a manufacturing order is performed, the IMS sends a request about the next operation of this manufacturing order to be executed. Each of the IMS able to perform the next operation returns an acceptance and local real-time data. The requesting IMS selects one of the proposed IMS through cooperation with human-operator, dialogue and decision making supported by a DSS, and it sends a reservation to the selected IMS and releases the others.

Decision making is based upon data returned by agents that have sent an acceptance.

A discharge concludes the protocol. More details can be found in [TCH 94].

Figure 3. Distributed production control structure

Decision making is already achieved through an event typology based on a decomposition according to the human operator point of view of the production process, i.e., queue in management, production management and queue out management. It can be specialized both to the communication system (message exchange) and to the control system (production progress). This refers to the physical and functional location attributes introduced before.

7.2.2. Problem to solve

The platform is dedicated to the reactive management of job-shop production systems by dynamic task allocation. The goal of the experiment described in this paper is the dynamic scheduling (because of the presence of disturbances) of 20 jobs of 10 operations each on 10 machines (the problem is described in [STO 92]).

The complexity of the problem appears through the detailed final scheduling provided by the computer and described in figure 4.

Users

Agents level Agent 1

Resource Resource

Resource

Agent 2

Resource

Agent 3

Resource Resource Production

resources level

Horizontal Control

Users Users

Vertical control Users level

Horizontal Control

Vertical control Vertical control

(18)

Figure 4. Detailed scheduling provided by the platform

7.3. Justification of the application of the proposals

In order to justify the use of the previously introduced concepts, events are studied in the platform context.

7.3.1. Events in the case of a distributed production activity control structure

In the case of the studied platform, a list of potential events has been built.

Thanks to the proposed typology and the proposed database model, a simplified characterization of those events is done through selected features. Figure 5 shows the list of events and the associated features. This figure shows the possibility to distinguish different types of events and to associate features to them.

Event Compatibility Simultaneity

Location: Queue In Control System

Manufacturing Order arrival Yes, if expected MO, else no No (anticipation of MO) Manufacturing Order departure Yes, if loaded by IMS, else no

(e.g., re-allocation)

Yes, if loaded by IMS, else no

Unexpected Absence of MO No Yes

Unexpected presence of MO No Yes

Location: Queue Out Control System

Manufacturing order arrival Yes, if unloaded by IMS after production process, else no

Yes

Manufacturing order departure Yes, if unloaded by IMS after production process, else no

No (anticipation of production process)

Unexpected departure of MO No Yes

Unexpected presence of MO No Yes

Location: Local management of production resource

(19)

Starting production process Yes Yes Ending production process Yes, if process is completed,

else no

Yes

Unexpected end of production process (breakdown, re- allocation, etc.)

Yes, if re-allocation, else no No if re-allocation, else yes

Unexpected start of production process

No Yes

Location: Queue In Communication System

Coming Request Message Yes Yes

Coming Acceptance Message Yes, with respect to acceptance waiting time, else no

Yes

Coming Reservation Message Yes, with respect to reservation waiting time, else no

No(anticipation of Manufacturing Order (M.O.))

Coming Relaxation Message Yes, with respect to relaxation waiting time, else no

Yes

Coming Discharge Message Yes, with respect to discharge waiting time, else no

No (anticipation of M.O.)

Communication Network problem (bad message, target mistake, etc.)

No Yes

Physical Location: Queue Out Communication System

Sending Request Message Yes Yes

Sending Acceptance Message Yes Yes

Sending Reservation Message Yes No (anticipation of M.O.)

Sending Relaxation Message Yes Yes

Sending Discharge Message Yes No (anticipation of M.O.) Communication Network

problem (returned message, etc.)

No Yes

Location: Local management of communication state Modification of state Yes, with respect to waiting

times, else no

Yes

Unexpected modification of state

No Yes

Unexpected non modification of state

No Yes

Figure 5. Events and their features in the case of a distributed production activity control structure

7.3.2. Justification of the introduced typology and filter approaches

(20)

On the basis of the proposed typology, a detection of events has been done on the described platform. This detection of events shows the interest of the event filter and, as a consequence, of the typology proposed because there is a huge amount of potential events. For example, 28 events appear between date 2.3s and date 2.9s for the global system (a mean of 46 events per second for the global system) and 6 between date 2.7s and date 2.9s for IMS number 5 (a mean of 30 events per second for this particular IMS). A total amount of 6459 events during the global simulation time has been detected. (3648 events related to production progress and 2811 events related to communication). So it is obvious that it is very hard for the human operator to manage all these events and especially to define processing priorities;

filtering will provide to the human operator the ability to focus on the most relevant events. In order to make decisions easier, an event management system is being developed. This helps to provide an automatic, manual or interactive control of each IMS through the DSS.

8. Conclusion and prospects

In a first step, this paper has shown the complexity of the reactive management of complex industrial systems when goals are hard to be reached. Then the interest of providing the best context so as to decrease the adaptation time of the decision maker has been enlightened. Nevertheless, decreasing adaptation time increases significantly global performance of production activity control system only if the decisions are focused on the most relevant data. In order to do that, it has been proposed an ordering of events by processing priority thanks to a typology of events based on several significant features. This typology is integrated in an event filter concept. This filter detects events from the system and updates a list of events ordered by processing priority. The interest of such a typology and filter has been shown on the example of a distributed production activity controlsystem.

Another advantage of the event filter concept is that it provides a conceptual framework allowing the analysis of most current events, leading to the design of reactive management systems able to manage with efficiency priority, redundancy, conflict, obsolescence, causality, etc. of every detected event.

So this is helpful when the management system is designed for both automatic and manual control: the sharing of the responsibility between the computer and the human operator can be easily based upon this management.

The prospects of these works will be integrated in the next papers:

 The development in the same way of the concept of decision typology and of decision filter. In fact they will allow to obtain groupings in order to associate generic decision contexts to generic decision families ,

 The study of connections between the two filters to ensure the consistency.

(21)

9. References

[ARC 91] Archimède B.: “Conception d'une architecture réactive, distribuée et hiérarchisée pour le pilotage des systèmes de production”, PhD Thesis, Université de Bordeaux 1, France, 1991.

[BAI 94] Baillet P., “Contribution à l'amélioration de la réactivité dans les systèmes de production notamment par la mise en oeuvre des concepts de décentralisation des fonctions de décision”, PhD Thesis, Université de Aix Marseille III, France, 1994.

[BIL 96] Billaut J.C., Roubellat F., “A new method for workshop real time scheduling”, International Journal of Production Research, Taylor & Francis, Vol. 34, n°6, p. 1555- 1579, 1996.

[BON 95] Bonnefous C., “Indicateurs de mesure et de pilotage d'un système de production:

éléments de réflexion pour une approche non financière”, La modélisation systémique en entreprise, Coordinators: Christian Braesch & Alain Haurat, Hermès, p. 179-189, 1995.

[CAU 97] Cauvin S., Cordier M.-O., Dousson C., Deflandre G., Laborie P., Lévy F., Montmain J., Porcheron M., Servet I., Travé-Massuyes L., “Surveillance et interprétation d'alarmes en milieu industriel”, Proceedings of the sixth national days of PRC-GDR Artificial Intelligence, coordinators: Sylvie Pesty & Pierre Siegel, Hermès, 1997.

[GAL 88] Gallois P.M., “Les indicateurs de performance, Pilotage et évaluation de la performance industrielle”, Publication of the works of the performance indicators group of the French Association of Industrial Management (AFGI), 1988.

[GEN 91] Gendreau D., “Génération automatique des procédures de pilotage d'une cellule flexible de production”, PhD Thesis, Ecole Centrale des Arts et Manufactures, Paris, France, 1991.

[HAT 91] Haton J.P., Bouzid N., Charpillet F., Haton M.C., Lâasri B., Lâasri H., Marquis P., Napoli A., Le raisonnement en intelligence artificielle: modèles, techniques et architectures pour les systèmes à bases de connaissances, InterEditions, 1991.

[LOR 96] Lorino P., Méthodes et pratiques de la performance: le guide du pilotage, Les éditions d'organisation, 1997.

[MIL 88] Millot P., Supervision des procédés automatisés et ergonomie, Hermès , Traité de nouvelles technologies, Série Automatique, 1988.

[NEU 96]: Neubert G., Campagne J.P., “Gestion des aléas: vers une approche méthodologique”, GI5, 5th International Congress on Industrial Engineering, Grenoble, April, 2-3-4, Vol. 3, p. 137-145, 1996.

[PER 96] Perraud-Echalier F., Vitry G., Chebeane H., “Modélisation événementielle (objets/réactifs) du pilotage temps réel d’atelier”, GI5, 5th International Congress on Industrial Engineering, Grenoble, April, 2-3-4, Vol. 2, p. 161-168, 1996.

[PES 97] Pesin P., Trentesaux D., Tahon C., “The event filter concept: a way to improve the reactive management of complex industrial systems”, IEPM'97, International conference on Industrial Engineering and Production Management, Lyon, France, October 20-24, p.

581-591, 1997.

(22)

[ROU 95] Roubellat F., Billaut J.C., Villaumie M., “Ordonnancement d'atelier en temps réel:

d'ORABAID à ORDO”, Revue d'Automatique et de Productique Appliquée, Hermès, Vol.

8, n°5, p. 683-713,1995.

[SAC 86] Sachs D.A., Paterson A.M., Turner M.H.M., “ESCORT, an expert system for complex operations in real time”, Expert Systems, Vol.3, n°1, January, p. 22-28, 1986.

[SIM 77] Simon H.A., The new science of management decision, Prentice Hall, Englewood Cliffs, New Jersey, 1977.

[STO 92] Storer R.H., Wu S.D., Vaccari R., “New search spaces for sequencing instances with application to job shop scheduling”, Management Science, n°38, p. 1495-1509, 1992.

[TCH 94] Tchako J.F.N.,Beldjilali B.,Trentesaux D., “Modelling with coloured Petri nets and simulation of a dynamic and distributed management system for a manufacturing cell”, International Journal of Computer Integrated Manufacturing, Vol.7, n°6, p. 323-339, 1994.

[TRE 96] Damien Trentesaux, “Conception d’un système de pilotage distribué, supervisé et multicritère pour les systèmes automatisés de production”, PhD Thesis, Institut National Polytechnique de Grenoble, Grenoble, France, 1996.

[TRE 97] Trentesaux D., Moray N., Tahon C., “Integration of the Human Operator into Responsive Discrete Production Management Systems”, 7th Mini Euro Conference, Bruges, Belgium, March 24-27, 1997.

[TRE 98] Trentesaux D., Tahon C. et Ladet P., “Hybrid production activity control: a JIT distributed-based structure for FMS”, Artificial Intelligence in Engineering, n°12, p. 49- 67, 1998.

[TUR 94] Turner R.M., Eaton P.S., Dempsey M.J., "Handling unanticipated events in single and multiple AUV systems", OCEANS'94, IEEE Oceanic Engineering Society Conference, Vol. 2, p. 125-130, 1994.

[VER 95] Vernadat F., "Modélisation systémique en entreprise: métamodélisation", La modélisation systémique en entreprise, Coordinators: Christian Braesch & Alain Haurat, Hermès, p. 242-261, 1995.

Philippe Pesin is an engineer graduated from the EIGIP of Valenciennes, France, an industrial and computer engineering school. He is currently a PhD student at the University of Valenciennes in the domain of decision support for the activity control of complex industrial systems, using multi-agents methods.

Damien Trentesaux is an engineer graduated from the ENSIEG of Grenoble, France, an electrical and control engineering school. He is currently assistant professor at the University of Valenciennes, France. His PhD thesis proposed a distributed and supervised production control system. His current research works deal with activity control of complex industrial systems and multicriteria decision support.

(23)

Christian Tahon is an engineer graduated from the ESTP engineering school of Paris, France. He is currently professor at the University of Valenciennes. His current research works deal with project management, decision support and performance evaluation.

(24)

ANNEX

Proposition d’une approche fondée sur le filtrage des événements pour améliorer la gestion réactive des systèmes industriels complexes

Références

Documents relatifs

[2] Abrehet Mohammed Omer, Alexander Schill, Dependency Based Automatic Service Composition Using Directed Graph, Next Generation Web Services Practices, International Con- ference

The supervision is aimed at guaranteeing the respect of a strict duration constraint for a heating process without impacting significantly the production rate of the

We then solve variants of the problem for reachability, safety, B¨ uchi, coB¨ uchi, parity, Rabin, Streett and Muller objectives when the rationality of processes is modeled using

In this paper we study the problem of fault detection and isolation by model-based diagnosis methods in the context of timed discrete event systems modeled as networks of

These systems compile CEP languages into some form of deterministic or non- deterministic automata. An Automaton consists of states set and conditional transitions between them.

Identification methods yield a mathematical model from data representing the behaviour exhibited during the system functioning; in the case of discrete event systems (DES)

Given a plant P , the aim of the synthesis of a controller is to find a process C called a controller which, when supervising P forces it to satisfy a control objective, given that

We have proposed a flexible event modeling language and a novel event recogni- tion algorithm to describe and recognize complex video events with probabilistic reasoning to handle