By using the previous definitions and conventions, it is now possible to specify (see section 2.4.1) how the term “robust” is usually applied in OR-DA. This will then
7. See, for example, [SAL 95, ROU 96, KIM 98, PIC 01, DAM 02].
44 Flexibility and Robustness in Scheduling
lead me to raise some questions (without claiming to have many answers) concerning validating robustness (see section 2.4.2) and conceiving the sets ˆP , ˆV , ˆT (see section 2.4.3).
2.4.1. What must be robust?
I would first like to shed light on the fact that, regardless of what is qualified as
“robust”, robustness involved is relative to the set of pairs(P, V ) considered. Second, I would like to emphasize the fact that this term “robust” is not relevant for qualifying theR(P, V ) product resulting from the application of a single procedure P to a single versionV . On the other hand, it can qualify:
1) A (AP or EP) procedureP by reference to a set ˆV of versions in the case where, for each of these versions,P provides a solution, or a set of solutions, or a statement considered adapted to the version involved, in relation to one or more criteria to define it. Several chapters of this book examine, explicitly or otherwise, the robustness of a procedure, often called an algorithm (for example see Chapters 3, 4, 6 and 9).
2) A solutionS by reference to a set ˆT not reduced to a single pair (P, V ): for example, we will say thatS is robust because it is always admissible or it is always at most% from the optimum in all cases studied; other example: value λ0of parameter λ occurring in a set ˆP of adjustment procedures constitutes a robust solution because, regardless of the versionsV ∈ ˆV considered, the model correctly reports observations.
3) A setS of solutions: this can be qualified as robust, for example:
– in the case where it is built from a set ˆP of procedures applied to a single version V if these solutions are compatible or do not reveal a contradiction in a previously defined sense;
– in the case where it is built applying a single procedure to a set ˆV of versions if,∀V ∈ ˆV , in S there exists at least one solution considered satisfactory, in a well defined sense, for this version (see section 1.3.3.3).
4) A conclusion similar to those illustrated in section 2.3.3 above: qualifying this robustness conclusion means that its validity is recognized in conditions which deserve to be clearly made explicit. Before clarifying this point, I would like to point out that the assertion of robustness of a procedure, a solution or a set of solutions (as it was considered previously) is none other than a relatively familiar form of robust conclusions. I have shown (see [ROY 07, ROY 98]) the usefulness of distinguishing at least three types of validation conditions for a conclusion qualified as robust. They are briefly described below:
Robustness in Operations Research and Decision Aiding 45
– A conclusion is qualified as perfectly robust when it is rigorously validated for all pairs of a well defined set ˆT ⊂ ˆP× ˆV .
– A conclusion is qualified as approximately robust when it is rigorously validated for “almost” all pairs(P, V ) of a set ˆT ⊂ ˆP× ˆV , “almost” meaning that exceptions are relative to pairs(P, V ) which are not necessarily well identified but considered insignificant in the sense that they involve combinations P × V not considered interesting or relevant.
– A conclusion is qualified as pseudo-robust when it makes a statement that is not necessarily rigorously formalized but considered valid for most pairs(P, V ) of a set T ; the validity judgment can for instance rely on the results obtained for a samplingˆ T of ˆT pairs.
5) A methodM : defining the conditions that must be fulfilled to qualify a method as robust can be very different according to contexts (in particular, see Chapter 1 and [VIN 99a, VIN 99b]; [SOR 01]; [SLO 03]). These definitions can in particular be different whether the method must be applied to a single well identified version or to a set of versions. I now propose to qualify a method as robust in relation to a version or a set of versions to which it is applied:
– forAM if solution S or set S of solutions produced is robust in a well defined sense (see 1 and 2 above);
– forEM if it is possible to arrive at validated conclusions (see section 2.3 above) by the expert(s) involved.
These examples shed light on the fact that in all cases, the term “robust” must relate to set ˆT or subset T ⊂ ˆT of pairs (P, V ) considered for validating the type of robustness desired.
2.4.2. What are the conditions for validating robustness?
The considerations in the previous section highlight the variety to which the term
“robust” can be applied to as well as the diversity of validation conditions which can be used to accept of reject robustness. Considering the DAPF and what we want to apply the term “robust” to, choosing these validation conditions greatly depends on the nature of undesirable impacts from which we want to be protected as well as the way in which we must be protected. In order to set these validation conditions, we can attempt to answer questions such as:
a) Will the validation conditions operate by acceptance-rejection (admissibility, respect for a performance threshold, etc.) or by using a degree of robustness (see b
46 Flexibility and Robustness in Scheduling
below) or still by being qualified in different ways (perfectly robust, approximately robust, pseudo-robust, etc.)?
b) When the concept of solution is present8in what the term “robust” must apply to, must undesirable impacts be understood in terms of:
– efficiency: performance level, cost difference (relative or absolute) in relation to an optimum, etc. (see for example Chapters 4, 5 and [SEN 91, RIO 94, ESC 94, KOU 97, VAL 99, HIT 00, JEU 00, AIS 07, KAL 07, ROY 07])?;
– flexibility: possibilities of adaptation, openness to the future, etc. (see for example Chapters 9, 10, 11 and [GUP 72, ALO 01, ROS 01a, ROS 01b, ROS 01c, SEV 02, ALO 07, SOR 07])?;
– stability: performance gap between solutions relative to the different version pairs or between a reference solution or relative to the different versions (see for example Chapters 1, 3, 12 and [SAN 07])?;
– equity: balance of a certain distribution (see for example [PER 03, SPA 03])?
c) Is it necessary to be able to compare the robustness of solutions, of set of solutions, of conclusions or methods: if that is the case, must we define a single criterion or a set of criteria?
d) Must the results relative to those of pairs(P, V )∈ ˆV which, in some respects, seem to be the worst, play a decisive role in the way to understand robustness (see Chapters 4, 6 and 11; [KOU 97])? Since the worst can very well be unlikely, is a more nuanced reasoning possible by combining risk and efficiency (see [SOR 01, HIT 02])?
2.4.3. How can we define the set of pairs of procedures and versions to take into account?
The answer to this question is (except in rare cases) very subjective. Considering the nature of impacts from which the goal of robustness is to protect as well as the way we must be protected, it is useful to begin by considering the following questions:
1) How can we state the definition of a set ˆV of representative versions? Should they be completely formalized?
2) How can we choose a set ˆP of appropriate procedures? Must these procedures be ofAP or EP type?
8. Examples in section 2.4.1 illustrate that this is very often the case, even though “robust” is used to qualify conclusions or a method.
Robustness in Operations Research and Decision Aiding 47
3) Can set ˆT of pairs (P, V ) to consider be restrictive or not (for incompatibility, lack of interest or processing time reasons) to a subset of ˆP× ˆV ?
I think it would be useful at this stage to emphasize the fact that research that is too systematic for frailty points to be affected by vague approximations and/or zones of ignorance may lead to excessive proliferation of versions and/or procedures to consider. On the other hand, an insufficient critical attitude, ignoring the saying “a man who doesn’t know that he doesn’t know thinks he knows”, can lead to reducing this proliferation excessively. In other words, it is advisable to find a compromise in each situation between these two opposite tendencies taking into account expectations of those in whose name decision aiding is occurring.