Flavia Felicioni
email: flaviaf@fceia.unr.edu.ar

François Simonot
email: francois.simonot@esstin.uhp-nancy.fr

Françoise Simonot-Lion

Ye-Qiong Song
email: song@loria.fr

OPTIMAL CONTROL WITH PACKET DROPS IN NETWORKED CONTROL SYSTEMS

Keywords: Networked control system, packet drop, (m, k)-firm, stability, performance optimization

The stability and performance of a networked control system are strongly influenced by the network delay and packet drops. In this paper, we consider that late arrived sampling data are dropped, so that we only focus on the analysis of the impact of packet drop sequences on the control loop stability and performance. For any dropping sequence specified by (m,k)-firm model, and considering a simple mono-variable linear system with a proportional controller and zero control action in case of sampling data drop, we derived the stability conditions based on the upper bound of the plant state variance. It has been shown that the stability only depends on the values of m and k but not the pattern of the dropping sequence. In case of network overload, this gives much freedom to actively dropping some packets while still keeping the system stable. An analytic method to determine the optimal control gain for any given packet drop pattern is also derived, providing thus a guideline for optimal control and network resource scheduling co-design.

INTRODUCTION 1

With the progress of networking technology, more and more control systems are now linked by networks, forming a research topic named Networked Control Systems (NCS) where one or more feedback loops are closed via a shared communication network [START_REF] Antsaklis | Technology of betworked control systems[END_REF]. In such systems, the measurements quantized by the sensors are sent to the controller over the network link. After the computation of the controller based on these measurements, the control output is then sent to the actuators that may also be via the network.

Unlike fieldbus design approaches in the past that mainly focused on providing to applications with real-time QoS (Quality of Service) guarantee from network point of view, the design of NCS focuses on the QoC (Quality of Control) optimization from the application point of view. For NCS design, the challenge is how to optimize on the one hand the QoC with the presence of the network induced delay and packet loss, and on the other hand the share of the limited network resources (e.g. network bandwidth). The underlying network of a NCS could be either a fieldbus (e.g. CAN Controller Area Network) or a general-purpose network (e.g. Ethernet, WiFi, or even Zigbee/IEEE802.15.4). As the This work has been partially supported by Safe_NECS project funded by ANR under ANR-05-SSIA-0015-03 network link is often shared among different applications and control loops, the network overload may occur and must be correctly handled. Otherwise excessive network delay and/or packet loss may lead to bad QoC or even to system instability.

For dealing with network overload, three control and implementation (e.g. task and packet scheduling) co-design approaches are available. One is to dynamically change the priority of packets in order to favour the data transfer of some critical control loops to the detriment of the other less critical applications. This approach can be easily implemented on the prioritized bus like CAN [START_REF] Juanole | Using an hybrid traffic scheduling in networked control systems[END_REF] but its generalization to other kinds of networks is far from straightforward. The second approach consists in dynamically changing the control loops' sampling periods by sending less frequently the sampling data to reduce the network load. This approach has been proposed mainly for optimally sharing the processor on which several controllers are executing [START_REF] Seto | On task schedulability in real-time control system[END_REF], [START_REF] Eker | A feedback scheduler for real time control tasks[END_REF], [START_REF] Simon | Robust control/scheduling co-design : application to robot control[END_REF]. However its implementation for the network resource sharing could be difficult for general purpose network. Note that this approach has been proved effective for certain particular networks, as FTT-Can [START_REF] Antunes | Dynamic rate and control adaptation in networked control systems[END_REF]. For instance, at the network overload, the period change decision must still be transmitted to the sensor nodes via network, implying complicated mechanisms. The third approach consists in selectively dropping sample data within a certain tolerated limit during the resource overload period, while still keeping the desired QoC or graceful degraded QoC [START_REF] Ramanathan | Overload management in Real-Time control applications using (m,k)-firm guarantee[END_REF], (Hadjicostis and Touri 2002), [START_REF] Bommannavar | Optimal control with limited control actions and lossy transmissions[END_REF]. Among these three approaches, it is clear that changing packet priority does not reduce the total network load but only re-allocates more network resources to the most important control loops and less resources to the others. While changing the period or dropping packets are more radical solutions to the workload reduction.

In this work, we adopt the third approach since comparing to changing the sampling period it appears easier to implement and more efficient than that of the priority change. However the following problems must be carefully addressed before adopting this approach. The first problem is the choice of the dropping sequence when selective dropping should be implemented. What is the impact of the dropping sequence on the QoC? The second problem is how to design optimal control law when a dropping sequence is effective.

In what follows, we describe in section 2 the NCS architecture we considered, the packet dropping policy based on (m,k)-firm model and then give the analytic relationship between the packet drop sequence and the control system and state what are the considered stability criterion and performance optimisation objective. We particularly show in section 2.3 how the network-induced delay can be incorporated into the discrete-time system model under our "zero control" action assumption. This allowed us to only focus on the study of the data drops. Section 3 states the stability condition under any given dropping sequences. As the dropping sequence is repeated periodically of k-periodic, the traditional stability in variance [START_REF] Aström | Computer-controlled Systems: Theory and Design[END_REF] does not exist when the horizon tends to infinite, so the upper bound of the variance is used instead to assess the system stability. The new metric allows us to upper bound the system output variance. We also give the method to determine the optimal gain for any given dropping sequence. Section 4 provides a numerical application of our analytic results. Through this example we show two points: 1) our analytic results can be easily applied to compute the allowed (m,k)-firm dropping patterns while upper bound the plant state variance; 2) the default value of the controller gain is a tight upper bound of the optimal gain. Section 5 discusses the possible implementation plans of our approach and Section 6 summarizes the new contributions of this work.

SYSTEM MODEL AND PROBLEM STATEMENT

Network Control System (NCS) architecture

The NCS model shown in Fig. 1 consists of a continuous plant (linear, mono-variable) and a digital controller connected onto a networked architecture. The output of the plant is sampled periodically (period h) and has to be transmitted immediately through a network (see signal y i in Fig. 1). This transmission introduces a delay. We suppose that the closed loop system is controllable if this delay is less than a given value δ. A correct sample, for this plant and this controller, is a sample that can be transmitted in less than δ to the controller. Fig. 1. System architecture Therefore, as soon as the network is overloaded and is no more able to transmit in time ( δ < ) the sampled data, the policy that we propose consists in dropping the packet that contains this data since late arrived data is useless for such kind of applications. Note that this strategy, with respect to priority adjustment, allows to keep always an amount of bandwidth for other data flows sharing the network.

Fig. 2. Algorithm of the controller under sample loss.

We assume that the controller node is synchronized with the sensor one (this service is provided in certain network protocol). The signal management in the closed loop system is: a) clock-triggered sampling of plant output (period h); b) clock-triggered controller (periodic task, period h) executing a constant delay control law under a constant skew δ (a similar policy is proposed in [START_REF] Liou | A stochastic regulator for integrated communication and control systems: II-formulation of control law[END_REF]; and c) event-driven actuator, updating the plant-inputs as soon as the controller output becomes available.

If a sensor sample is dropped, it is recognized as vacant sampling by the controller [START_REF] Halevi | Integrated communication and control systems: Part I-analysis[END_REF] and the actuator applies the "zero control" action to the plant. Fig. 2 illustrates both cases. Applying a "zero control" signal to the actuator in case of absence of sampling data is justified by the fact that it would cost the least amount of control energy among all possible control actions (Hadjicostis and Touri 2002), [START_REF] Imer | Optimal control of LTI systems over unreliable communication links[END_REF], [START_REF] Sadjadi | Stability of networked control systems in the presence of packet losses[END_REF]. Of course another way is also possible which consists in applying the "last available control". This last way is equivalent to the zeroorder hold (ZOH) action in continuous time but may lead to more control energy.

Sample Drop Policy

As explained in the former section, the approach considered in this paper to solve network congestion is to selectively drop some instances of systems outputs. Some solutions exist that discard data packets in order to reduce the effective utilization of the system. Among these solutions, the technique often mentioned is (m,k)-firm policy [START_REF] Ramanathan | Overload management in Real-Time control applications using (m,k)-firm guarantee[END_REF] [START_REF] Quan | Enhanced Fixed-priority Scheduling with (m,k)-firm Guarantee[END_REF]. The (m,k)-firm model requires that at least m out of any k consecutive packets must be delivered by the network. In [START_REF] Jia | Analysis of Networked Control System with Packet Drops Governed By (m,k)firm Constraint[END_REF] and [START_REF] Jia | Graceful Degradation of the Quality of Control through Data Drop Policy[END_REF]) was first studied how to choose the value of k and the rate of m over k so that the system remains stable for monoand multiple-variable linear systems. The impact of the packet drops distribution on the QoC has been evaluated but without giving a general relationship.

In this paper, we continue to adopt the (m,k)-firm based dropping policy and give in section 3 the general analytic relationship between a packet drop sequence and the QoC.

System Model

The first order plant is described by the discrete time dynamics ( ( )

f ih is noted i f in the following): 1 , 0 and i i i i i i i x x u q y x p α β β β + = + + ≠ = + (1)
where i x represents the plant state, i u its input; i q and i p , are white noises, assumed to be independent and with zero mean and whose variances will be noted 2 q σ and 2 p σ .

Particularly i p models the quantization noise in an additive way and i q represents the actuator noise.

Considering a proportional controller

i i i u y γ = Π
, where i Π models if the plant state sample is transmitted to the controller or not (

1 i Π = if the th i sample is transmitted and 0 otherwise). i Π is called (m,k)-pattern.
Then the closed loop model is:

1 ( ) ( ) i i i i i i x x p q α β γ β γ + = + Π + Π + (2)
We consider that the delay between the time of each plant output sampling and the time of the corresponding actuation instant is always equal to δ (see section 5 for the possible implementation of this assumption). In order to compensate this skew (figure 3), we use a Prediction-Based Model (Marti and Velazco, 2007) that computes the control signal u, with the estimated state vector at the actuation instant ih δ + .

Fig. 3. Impact of the transmission delay.

During the interval ( ih , ih δ + ), the plant (linear) evolves and the estimated state vector at ih δ + , is ( ) ( )

x ih e x ih αδ δ + = .

If we multiply the terms of the equation ( 2) by the constant e αδ , we obtain:

( ) ( ) ( ) ( 1) ( ) ( ) ( )
( ) ( ) ( ) ( 1) ( ) ( )
( ) i i x i h x ih e p ih q ih αδ δ α βγ δ β γ + + = + Π + + Π +
Then, without loss of generality we can work directly with the model (2) where the noises are and

c c i i
e p e q αδ αδ (same properties as and

i i p q ).

Stability conditions and optimisation issues

First we need to identify the condition on the closed loop control that ensures the stability of an unstable plant under output and process noises and subject to a specific dropping strategy of the sampled plant output. As specified in section 2.2, we apply a proportional controller with a gain γ and the transmission of plant state samples are controlled thanks to a (m,k)-firm policy. For any sequence of k samples, only m are transmitted according to a predefined (m,k)-pattern. So, the packet sequence delivery is k-periodic.

From control theory, the control design goal for a system under noise (or cost criterion) is to determine the controller gain which minimizes the variance of the output (see for example, [START_REF] Aström | Computer-controlled Systems: Theory and Design[END_REF]. In this paper, we consider an infinite horizon and propose to guarantee the closed-loop stability by calculating the gain γ in order that i i sup var( x ) should be finite. This property allows taking into account all the future of the system. Moreover, finding an optimal controller means to determine the parameters of the system that makes this limit as small as possible. More precisely, the optimisation issue consists in finding:

-the parameters of the dropping policy: m, k and the (m,k)pattern, -the gain γ of the controller.

The purpose of the next section is to provide a mathematical support for the specification of the parameters.

ANALYTICAL APPROACH

In the following, we note var( )

i i v x =
. The assumptions made on the noises i p and i q , show that:

1 i i i i v a v b + = + , 0 0 v = , 0 i ≥ (3)
where: We set

2 1 1 1 ... , 0 i k i i k j j i k j i B b b a a i k + - + - + + - = = + ≤ < ∑ and 0 max ( ) i i k B B ≤ < = .
In fact, taking account of the k-periodicity of i a and i b , we have:

( )

1 1 1 1 1 1 1 1 1 1 ... ... ... ( 1
)
i k i i k j j i k j i i k i i j j i k j i i i i i i i k i i i B b b a a b a b a a b a B b a a b A a B + - + + + + = + + - + + - = + + + - = + = + = + - = -+ ∑ ∑
Then i B can be computed by the recurrence relation:

1 (1 ) i i i i B a B b A + = + -, for 0 i ≥ , with 1 0 1 1 0 ... k j j k j B b a a - + - = = ∑
. We obtain the following result.

Theorem 1.

1) If 1

A ≥ , the sequence ( )

n v is unbounded. 2) If 0 1 A ≤ < , then the sequence ( ) n v is bounded and: 0 sup 1 n n B v A ≥ = -
For short, the system is stable if and only if 0 1 A ≤ < Sketch of proof. From equation ( 3), taking into account the kperiodicity of i a and i b , it can be seen that for 0 and 0 i k n ≤ < ≥ :

( 1)

i n k i nk i v Av B + + + = + (4) 1) If 1 A ≥ , the equality (4) shows that 0 0 0 nk v v nB nB ≥ + = .
We note that

1 2 2 0 1 1 1 0 ... 0 k j j k k q j B b a a b β σ - + - - = = ≥ ≥ > ∑ ; therefore, 2 2 nk q v nβ σ ≥
showing that the sequence ( ) n v is unbounded.

2) If 0 1 A ≤ < , from equation (4), we can deduce that ( ) 1 1

n i i i nk i B B v A v A A + = + - - - , for 0 and 0 i k n ≤ < ≥ .
Therefore lim

1 i i nk n B v A + = - .
It can be shown that 1

i i B v A ≤ -
for any i. Due to the k-

periodicity of i B , we have 1 i i nk B v A + ≤ - and therefore sup 1 i i nk n B v A + = - . Finally, sup 1 n n B v A = - .
Let us consider now the optimisation problem. For this purpose, given a (m,k) dropping policy ( )

, , m k Π , the optimisation problem is to find that minimizes 0 ( ) sup ( )

n n M v γ γ ≥ = , bearing in mind that 2 2( ) ( ) m k m A α βγ α - = +
, under the constraint 1 A < . This is equivalent to:

A γ = .
Corollary .

2 2 2 2 2 2 2 0 2 2 ( ) ( ( 1) ) ( 1) ( 1)

N q q p M β σ α γ β σ α σ α α = + - - - -
where 1 Nis the length of the longest run of 0 in the pattern Π (see Fig. 4). A γ = , it turns out that 1

i i i i B a B b + = + . Setting 2 2 2 2 q p c β σ α σ = + , this relation
shows that the sequence is strictly increasing for (see Fig. 4):

-

1 j i j n ≤ < + with j B c = , - 1 1 2 j n i j n n + ≤ < + + with 1 j n B c + = , -…, - 1 1 1 2 ... ... m m j n n i j n n n j k - + + + ≤ < + + + + = + with 1 1 ... m j n n B c - + + + = .
Consequently, ( ) ( ) ( )

1 1 2 0 1 1 1 ( ) max max( , ,..., ) i j n j n n j k j i j k M B B B B γ + - + + - + - ≤ < + = = .
1 2 1 2 2 2 2 1 1 N N N q x c α α β σ α - -   -   = +   -    
which entails the result. M γ is tight. This will be investigated in the next section that presents an experiment.

NUMERICAL APPLICATION

We apply this approach on a classical case study. We consider a plant described by equation ( 1) and whose parameters are:

-3

α = and 1 β = ,
-under the noises p and q, whose variances are 2 1 p σ = and 2 1 q σ = .

In order to avoid a too large dispersion of the plant state, we impose the variance of the plant output to be bounded by a given value 1000

lim v =
. So we have to ensure that the gain γ of the controller is such as

lim M ( ) v γ <
.

The control architecture is distributed as shown in Fig. 1.

We consider that the dropping policy is handled by a dedicated admission controller implemented in the sensor or in a router. The available memory in this device allows representing a pattern whose size is less or equal to 10 ( 10 k ≤ ). The result we obtained is given in Table 1. The two first columns give the (m,k) constraint: m, k, and the pattern Π.

The third and fourth columns provide opt γ that minimises the limit of the plant output variance for this constraint and constraint that is admissible.

γ γ + [ , step d loop M= M ( ) γ ; if (M< lim v ) then if (M< opt M M < ) then opt M M = ; opt γ = γ ; end if end if end loop print(m,k,Π, opt γ , opt M , 0 M ( ) γ );
The smallest limit of the plant state variance is obtained for a (1,2) constraint whose pattern is 10 " " Π = . In this case, the best gain is -2,966667 shows the curve ( ) M γ for this configuration.

The largest limit of the variance corresponds to a (5,10) pattern, 1110100100" " Π =

. The optimal gain is -2,9933 ( 5,10) 1110100100 -2,9933 8,20E+02 8,20E+02 2 0,1% ( 5,10) 1110010100 -2,9733 8,13E+02 8,20E+02 9 0,9% ( 5,10) 1110010010 -2,9933 8,20E+02 8,20E+02 2 0,1% ( 5,10) 1101100100 -2,9933 8,20E+02 8,20E+02 2 0,1% ( 5,10) 1101010100 -2,9667 8,12E+02 8,20E+02 10 1,0% ( 5,10) 1101010010 -2,9667 8,12E+02 8,20E+02 10 1,0% ( 5,10) 1101001100 -2,9667 8,12E+02 8,20E+02 11 1,0% ( 5,10) 1101001010 -2,9667 8,12E+02 8,20E+02 11 1,0% ( 5,10) 1100110010 -2,8933 7,86E+02 8,20E+02 27 4,3% ( 5,10) 1100101010 -2,8333 7,69E+02 8,20E+02 37 6,6%

IMPLEMENTATION ISSUES

As stated above, the goal of our communication and control co-design approach is to optimize both the network bandwidth utilization and the QoC.

The approach we proposed consists in selectively dropping the sampling data packets to reduce the network load while still maintain an acceptable QoC for the application. In fact, as we have shown in section 2 and 3, for a given sampling period, the control loop can tolerate a certain consecutive data packet drops, i.e. the longest run of 0 in the (m,k)pattern. To achieve the selective data dropping in case of network overload, a dropping mechanism should be implemented either in the network and/or at sender nodes (e.g. the sensor node in our control loop), and a trigger condition should also be implemented to know the condition to decide the packet dropping. ).

For the synchronous system considered in Fig. 2, a simple way to if the network is in overload situation or not is the use of a timer at the sender node (sensor) by setting the timeout value to δ -τ sc . Where τ sc is the expected packet transmission delay from the sensor node and the controller node plus a secure margin (e.g. mean value + the variance). This delay can be either estimated on-line (similar to the round trip time estimation in TCP) on fixed off-line when it is possible. If a sample data packet is not transmitted in time (i.e., before δ -τ sc ), it indicates that the network is in congestion and we should reduce the workload by sending the sampling data packet according to a pre-configured (m,k)-pattern (could be implemented using a k-bits register). The system passes thus from the normal mode to a degraded mode. The system can try to return back to the normal mode after a fixed period or by observing that the delay before sending the data packet is much lower than δ -τ sc .

CONCLUSIONS

In this paper we decided to choose a simple mono-variable linear system with a proportional controller to illustrate the approach of control and communication co-design. We assumed "zero control" action in case of sampling data drop. So for dealing with network congestion we proposed to selectively drop sampling data according to (m,k)-firm model.

Following new results are presented: 1) We proved (Eq. 3) that the network-induced delay can be incorporated into the discrete-time system model under our "zero control" action assumption, allowing thus the system stability analysis by only considering the data drops. 2) When periodic dropping pattern is applied to the system output sampling data, classic plant state variance does not converge to a value. In this case the upper bound of the variance can be used instead. 3) We derived that the system stability (upper bound of the variance) only depends on the value of m and k but not (m,k)pattern (theorem 1). Moreover, we identified a gain 0 γ that can easily be computed (even on line) and that provides a tight approximation of the best upper bound of the variance; this gain only depends on the longest run of 0 in the (m,k)pattern (corollary).

Although a very simple system has been chosen in this paper, it is worth noting that the principle of this approach can also be applied to multi-variable linear systems. For instance in [START_REF] Jia | Graceful Degradation of the Quality of Control through Data Drop Policy[END_REF]) and [START_REF] Felicioni | Impact of a (m,k)-firm Data Dropouts Policy on the Quality of Control[END_REF]), a two-variable system has been considered and ZoH has been assumed, the stability as well as the QoC under (m,k)-firm dropping policy have been investigated using LQ cost function. The results are also encouraging.

Our future work aims at extending this approach to handling multiple control loops sharing a same network (wired or wireless) where the design of packet scheduling and selective dropping should significantly contribute to optimizing the resource utilization while still keeping the system stable and with a graceful QoC degradation during network congestion situations.

  equation shows that:

  This shows that A depends only on m and k and not of Π .

Fig. 4 .

 4 Fig. 4. Example of pattern Π.We notice that

//

  Fig. 5. Algorithm for ( ) M γ evaluation.

Furthermore

  provide two information: the first one ( n < ) gives the number of γ tested in [ [

  Fig. 6. Evaluation of opt γ ,

  to provide a tight upper bound of inf ( ) M γ γ .

Fig. 7 .

 7 Fig. 7. M(γ) under a (1,2) constraint ( 10 " " Π =

Fig

  Fig. 8. M(γ) under a (5,10) constraint ( 1110100100" " Π =

Table 1 . opt

 1

		γ γ γ γ ,	M (	γ γ γ γ	opt	)	according to m, k, Π Π Π Π
	( , ) m k	Π	γ	opt			M	opt	0 M ( ) γ	n < ε
	( 1, 2)	10 -2,9667 9,01E+01 9,10E+01 10 1,0%
	( 1, 3)	100 -2,9956 8,19E+02 8,20E+02 3 0,1%
	( 2, 4)	1100 -2,8933 7,86E+02 8,20E+02 26 4,3%
	( 2, 5)	10100 -2,9692 8,13E+02 8,20E+02 15 0,9%
	( 3, 6)	110100 -2,9667 8,12E+02 8,20E+02 11 1,0%
	( 3, 6)	110010 -2,8600 7,75E+02 8,20E+02 32 5,8%
	( 3, 7)	1100100 -2,9954 8,19E+02 8,20E+02 2 0,1%
	( 3, 7)	1010100 -2,9676 8,12E+02 8,20E+02 14 1,0%
	( 3, 8)	10100100 -2,9968 8,19E+02 8,20E+02 3 0,1%
	( 4, 8)	11100100 -2,9933 8,20E+02 8,20E+02 2 0,1%
	( 4, 8)	11010100 -2,9667 8,12E+02 8,20E+02 10 1,0%
	( 4, 8)	11010010 -2,9667 8,12E+02 8,20E+02 11 1,0%
	( 4, 8)	11001010 -2,8400 7,71E+02 8,20E+02 35 6,4%
	( 4, 9)	110100100 -2,9949 8,19E+02 8,20E+02 1 0,1%
	( 4, 9)	110010100 -2,9696 8,12E+02 8,20E+02 10 0,9%
	( 4, 9)	110010010 -2,9949 8,19E+02 8,20E+02 1 0,1%
	( 4, 9)	101010100 -2,9696 8,12E+02 8,20E+02 12 1,0%
	( 4,10) 1100100100 -2,9962 8,19E+02 8,20E+02 2 0,1%
	( 4,10) 1010100100 -2,9962 8,19E+02 8,20E+02 2 0,1%


IDHEAP -Lausanne -November 6, 2009

Sticking one's oar in the "all discursive"

St€phane Narath and Fr€d€ric Varone kindly proposed that I write the chapter "A pragmatic constructivism". I wish to thank them warmly for that. I don't know whether the product is acceptable, but their proposal intrigued me and I wanted to take the opportunity of this wonderful gathering to talk about it. I very much regret not being able to do so directly in your presence.

Trained in a tradition of public policy analysis dominated by so-called "cognitive" approaches, I have always considered that the analytical model developed by Peter and the team surrounding him is particularly interesting because of the pragmatic perspective that it affords. As I had never spoken about this to St€phane or Fr€d€ric, their proposal revealed their talent as mediums! They had guessed my broad adhesion to the model developed by Peter, whom I accompany with much interest and pleasure in running a public policy analysis seminar at the Institut Politiques of Grenoble. That is, unless St€phane and Fr€d€ric, through Peter, had perceived why I found it necessary to import -there where the reference frameworks approach had been produced and taught -a differently instrumented approach whose main merit, in my opinion, is that it does not stop at the threshold of public policies,. This is the very issue that I wish to discuss here, and that I find is not considered adequately in the chapter proposed in the book: the difficulty of cognitive and today discursive approaches to say what policies actually are. Analysing an issue of this nature -probably as incorrect as it is pretentious -warrants long detours into the contexts of production and the underlying theoretical plans of the various approaches concerned. Some have started to do so. In particular I have in mind the highly interesting paper by Barbara Lucas -yet another Swiss colleague! -presented at the congress of the French Political Science Association last September. I will limit myself here to a very brief discussion of discursive approaches in public policy analysis, for one reason mainly.

analysis. As David Howarth and Yannis Stavrakakis have shown, political science in general is doing so, following other disciplines. The reasons put forward to explain this interest relate to the assumption (or the fact, for proponents of discourse theory) that the ascendancy of policy-makers (or public authorities) over the discursive field is essential particularly because the "resources" of policy-makers (in Peter's sense) are weakening. Far more than a strategic accessory in the service of actors' interests (as with Paul Sabatier), political discourse is considered as the main research subject. In recent years many studies have highlighted political language and its normative approach to point out the "hegemony of polity" in governance regimes, or the "polity's role" in the reconstruction of stabilized identities when nation states' capacity for integration is overwhelmed by supranational forms of trade and regulation. From this political and scientific context, the argumentative turn in policy analysis, promoted in the 1990s by authors such as Franck Fischer (but in embryonic form in earlier comparative work such as that of Hugh Heclo on the development of British and Swedish social policies), seems to be an extension of the reference framework approach. It focuses on the place and role of ideas in the framing of public issues as problems, and of possible solutions.

The pragmatic approach that Peter supports seems to be very different, most probably for several reasons. If this is indeed so, I would like to ask Peter to explain why. After reading his writings and watching him lecturing, I wish to say the following.

Research inspired by discursive and previously cognitive approaches (that could be grouped under the term "argumentative approaches") tends to focus a great deal on the analysis of the construction of public problems and their solutions. Yet it makes no reference to concrete public policies and shows little or no interest in their "impacts" and "effects". Hence, between the advocates of these argumentative approaches, and Peter and others (Peter has gathered a following), there is a great divide that is difficult to bridge -a divide between two definitions of what a public policy actually is.

Peter considers that a public policy is a concrete response to a given social problem, whereas the advocates of argumentative approaches believe that public policies are above all a self-realizing (or "performative") discourse (the public policy is the discourse that pronounced it). As far as I know Bruno Dente was the first to have perceived this tendency in the cognitive approach when he warned its French supporters to be careful not to "parler de 'la politique du politique' comme politique publique, avec ses acteurs, ses r'seaux, etc." 1 . Was Bruno, for all that, calling for an analysis of public policy as an action intended to transform supposedly problematical behaviours, that incorporates in its realization a share of political work of integration of contradictory interests (between "target groups" and "beneficiary groups", according to Peter)? I don't know and I would have liked to put the question to him.

It would spoil a festive and not only scientific occasion such as this one to talk of the "war of positions". But when I hear it said, in the wings, that it is a matter of management studies and not of policy analysis to define public policies as "a sequence of intentionally coherent decisions or activities, aimed at altering the behaviour of the social groups supposedly at the origin of the problem politically defined as collective", then I fear the worst!

In any case, we may well wonder whether Peter's definition of public policy does not seriously stick one's oar in the "all discursive" that is unable -in the present state of its applications -to tell us what policies do and therefore what they are. Are policies anything different to what they do to the society on which they act? Disavowing the "problem-solving" orientation, as many argumentative approaches do, changes nothing of the fact that policy analysis also has the objective -even if it is not the main one in some people's eyes -of studying "public decisions" and their "impacts" and "effects". Failing to acknowledge this would make policy analysis meaningless, for what would be the point of an analysis incapable of saying what policy-makers actually produce? Let's hope therefore that those convinced by argumentative approaches are neither flashed by a radar on the road, nor develop Alzheimer's disease, nor experience any other such misfortunes, so that they can carry on believing that the road safety policy, the Alzheimer's plan, and many other policies As we can see, the question is not only one of a "missing link", as Barbara Lucas puts it. It seems particularly complex and even serious, if we consider from this point what the social function of public policy analysis and its teaching ought to be.

We can now conceive that the gap can (partially) be bridged. I will conclude with a few comments and questions in that direction -but this time starting from how the "all discursive" can stick one's oar in Peter's pragmatist approach.

Without going off into grand extrapolations on the philosophical ulterior motives of these two main streams of policy analysis, we can assume that the divide mentioned here is basically the one separating rationalism and relativism. With you, Peter, I wonder whether there is not a fear of relativism, which evokes both the dissolution of critical meaning and the collapse of scientific rigour.

From hanging around in the wings, I have the impression that the main criticism by the proponents of argumentative approaches, levelled at those which in their opinion -but not in mine, as you have seen -resemble a management study, relates to the well-known denunciation of objectivism and the instrumental rationality of public policies. As Barbara Lucas points out, Martin Rein, John Dryzek, Franck Fischer, John Forester and Deborah Stone, to mention but a few, have contributed to denouncing the image of neutrality and objectivity associated with policy analysis, mainly by highlighting their implicit significations and the values they convey. Dear Peter, is there no response to be given to this strong comment, by urging analysts to focus sharply, for example on the categorization of the target groups that influence the definition of the public problem so much? Without giving up anything fundamental, would it not be advantageous, on this product of a policy as on the others, to take more advantage of studying "policy narratives"? The application of your analytical model to environmental policies does not seem to be incompatible with the work of Maarten Hajer who, on this type of policy, has undertaken micro studies of processes of discussion governing the formulation of the general discourse on the definition of the public problem. His approach does not seem to be the goal of policy analysis, but rather an interesting modality for the one that you promote.

Another remark and question. Maarten Hajer and Henk Wagenaar have spoken about "deliberative policy analysis". It is clear that in many countries the state is no longer sovereign, and analyses of "politico-administrative apparatus" attest to that.

Hence, deliberation and the democratization of deliberation through citizens' participation (as "beneficiaries" and, why not, "target groups") in the expertise concerning them is, for some (Hajer and Wagenaar; Dryzek; Fischer; Papadopoulos; etc.), precisely a major solution (or "resource"). Now, in the list of resources that incorporate your model, there are two ("political support" and "consensus") that leave room for deliberation and, through them, for fundamentally argumentative processes.

Of course that has not eluded you, but do those who apply your model take the time to analyse how, right down to discursive processes, these resources effectively act?

Clearly, questions of method and of the required empirical work spare none of our approaches.

But you're certainly not someone that I'll criticize for not telling us to work, work and work even more. For by working on the empirical development of the respective reference frameworks, the gap between them might just be narrowed down a little. Philippe Warin, CNRS, Pacte/IEP Grenoble.

  are basically just discourse! 1 DENTE B. (1995), "Incoh€rence ou €clatement de l'Etat ?", counterpoint to the article by Bruno Jobert, in B. THERET (ed.), L'Etat, la finance et le social. Souverainet• nationale et construction europ•enne. Paris, la D€couverte, coll. "Recherches", pp. 244-252.


Khaled Gaaloul
email: khaled.gaaloul@sap.com

Franc ¸ois Charoy

Andreas Schaad
email: andreas.schaad@sap.com

Modelling Task Delegation for Human-Centric eGovernment Workflows

Keywords: H.4 [Information Systems Applications]: Workflow management, Miscellaneous Management, Security eGovernment, Workflow, Task, Delegation, Access Control

The execution of cross-domain eGovernment applications is a challenging topic. eGovernment organisations are facilitated and conducted using workflow management systems. Workflows automates the management and coordination of organisational or business processes. In the context of eGovernment, what is in many cases described as collaboration appears, however, to be coordination and synchronisation of processes ignoring human-centric interactions. In addition, we observed a tendency, moving away from strict enforcement approaches towards mechanisms supporting exceptions that are difficult to foresee when modelling a workflow. One specific set of mechanisms ensuring human centric interactions and supporting collaboration crossorganisations is task delegation. In this paper we aim to model task delegation for humancentric eGovernment workflows. We do believe that delegation is a solution to support organisational flexibility in human-centric workflow systems, and ensure delegation of authority in access control systems. First, we present a real case study to motivate delegation. Based on this, we define a task delegation model, and analyse its main criteria and requirements within a workflow. In particular, we will focus on the concept of delegation in eGovernment workflows and link it to our case study. Finally, we present delegation protocols to ensure delegation of authority in access control systems based on workflow authorisation constraints.

INTRODUCTION

Electronic government (eGovernment) is the civil and political conduct of government, including services provision, using information and communication technologies. The concept of eGovernment has been gaining ground from initial isolated to extensive research and applications. The prerequisites for an e-Government enactment strategy are the achievement of a technological interoperability of platforms and a deeper cooperation and security at the organisational level. Those requirements are related with the environment in which the public agencies operate, strictly constrained by norms, regulations, and result-oriented at the same time [START_REF] Traunmüller | Government at a Decisive Moment: Sketching a Roadmap to Excellence[END_REF]. Actually, most governmental organisations offer electronic services within a collaborative environment. However, inter-organisational collaboration, especially by means of workflow management systems, is not as widespread. The R4eGov project consists of inter-organisational collaboration between European administrations [START_REF]Towards e-Administration in the large[END_REF]. An example domain for such collaboration is Europol1 (European Police Office) and Eurojust2 (European Judicial Cooperation Unit). It describes an interagency collaboration within the areas of law enforcement and justice. One of the objectives is to establish a collaboration, including information exchange between both parties based on legal constraints, such as European laws, to which they have to comply to, but sustain effective degrees of freedom for each department to solve their issues in the way they think is the most efficient and effective [START_REF] Schaad | SIXTH FRAMEWORK PROGRAMME, Information Society Technologies, R4eGov[END_REF]. Those objectives can be achieved using collaborative workflow systems [START_REF] Schulz | Facilitating cross-organisational workflows with a workflow view approach[END_REF][START_REF] Contenti | A Distributed Architecture for Supporting e-Government Cooperative Processes[END_REF]. Workflow management systems automates the management and coordination of organisational or business processes. In the context of eGovernment, what is in many cases described as collaboration appears, however, to be coordination and synchronisation of processes by ignoring human-centric interactions. In addition, we observed a tendency moving away from strict enforcement approaches towards mechanisms supporting exceptions that make it difficult to foresee when modelling a workflow. One specific set of mechanisms ensuring human centric interactions and supporting collaboration cross-organisations is that of task delegation [START_REF] Schaad | A framework for evidence lifecycle management[END_REF]. Task delegation can be very useful for real-world situations where a user who is authorised to perform a task is either unavailable or too overloaded with work to successfully complete it. This can occur, for example, when certain users are sick or on leave. It is frequently the case that delaying these task executions will violate time constraints on the workflow impairing the entire workflow execution. Delegation is a suitable approach to handle such exceptions and to ensure alternative scenarios by making workflow management systems flexible and efficient. The concept of delegation has not yet been treated in sufficient details in the context of heavily human-centric col-laborative workflows [START_REF] Gaaloul | Collaboration for human-centric egovernment workflows[END_REF], it is the subject of the paper to support heavily human-centric collaborative workflows according to global policies specified in the European law regulations constraints. Subsequently, we need to define a task delegation model to support organisational flexibility in the human-centric workflow systems, and ensure delegation of authority in access control systems. The contributions of this paper are threefold. First, we present a real world scenario supporting delegation and illustrate the working of task delegation in human-centric workflows cross European organisations in R4eGov. We then define a task delegation model within a workflow, and analyse additional requirements to support secure task delegation during workflow execution. To this end, we detail delegation protocols with a specific focus on the involved users to ensure delegation of authority in access control systems based on workflow authorisation constraints. We finally define additional requirements for delegation such as revocation and propose a lightweight implementation of our approach. The remainder of this paper is organised as follows. Section 2 presents a workflow scenario inspired from an R4eGov use case to motivate delegation scenarios. In section 3, we define task delegation model and analyse its main requirements. Section 4 defines workflow authorisations constraints to ensure secure delegation. In section 5, we detail delegation protocols and present revocation as an additional requirement for delegation. Section 6 presents related work. In Section 7, we discuss and conclude our approach, and outline several topics of potential future work.

EGOVERNMENTAL WORKFLOW SCE-NARIO

We introduce an R4eGov workflow scenario related to the European administrations collaboration. Europol and Eurojust are two key elements of the European system of international collaboration within the areas of law enforcement and justice. They carry out very specific tasks in the context of dialogues, mutual assistance, joint efforts and cooperation between the police, customs, immigration services and justice departments of the EU member states [START_REF] Schaad | SIXTH FRAMEWORK PROGRAMME, Information Society Technologies, R4eGov[END_REF]. During their collaboration, Eurojust and Europol are involved and a number of legal instruments are used. A Specific scenario for this collaboration is the Mutual Legal Assistance (MLA)3 .

Mutual Legal Assistance

Mutual Legal Assistance (MLA) defines a process involving two national authorities of different European countries regarding the execution of measures for protection of a witness in a criminal proceeding. Here we describe MLA process in the Eurojust organisations A and B, and detail the different business actors and resources models involved in the process. Basically, the two organisations work consists of receiving the request of assistance from the Europol member in order to process it and send it the concerned authority in country B. Eurojust infrastructure integrates systems such as MLA service and CMS (Case management System) to process data on the individual cases on which Eurojust national members are working in temporary work files. Eurojust defines an organisational hierarchy working together to achieve common goals.

We applied the the Business Process Modeling Notation (BPMN) notation to our MLA process illustrated in Figure 1. BPMN has emerged as a standard notation for capturing business processes, especially at the level of domain analysis and high-level systems design. The notation inherits and combines elements from a number of other proposed notations for business process modeling, including the XML Process Definition Language (XPDL) and the Activity Diagrams component of the Unified Modeling Notation (UML) [START_REF]The Workflow Management Coalition. Process Definition Interface XML Process Definition Language[END_REF]. In our example, we distinguish Prosecutor as the main responsible that collaborates with internal and external employees (Assistant, National Correspondent (NC), Judge and Judicial Authority Officer (JAO)) to process the MLA request. First, Prosecutor A receives the request and checks it in the MLA information service (tasks 1 and 2). If the provided information are correct, the prosecutor will continue to process the request by asking for the preparation of the request document (task 4). Note that depending on the request context, the application process will differ in the users involved and data that need to be considered. In fact, the specific type of legal document requested will have a direct effect on the involved users. For instance, the "Trans-late Request Document" task might be required to carry out the request preparation when exchanged documents are issued in the local language; therefore we need a national correspondent to translate documents (task 3). After the preparation of the required legal documents, the prosecutor will send the request to his Eurojust colleagues in country B (task 5). The next steps define the collaboration interorganisations Eurojust A and B. Activities that need to be taken are the review of the request, the determination of the judicial authority in order to forward the request to the concerned authority in country B for the final approval (tasks 6, 7 and 8).

Problem Statement

Several of the depicted tasks involve human interactions and are possibly time consuming. Tasks taken by the Eurojust organisation A to define the requested assistance might involve several business actors such as a Prosecutor, an Assistant and a National Correspondent. Depending on the current control-flow sequence, workflow actors can evolve and change from the predefined workflow model. For instance, the absence of translated document (task 3) can lead to a new rearrangement of actors in order to optimise the process execution. In addition, unexpected events can happen without being modelled beforehand. For example, a prosecutor delegates a part of his work to a subordinate due to emergency situations. In this scenario, we describe the work of Eurojust collaboration cross organisations. One of the objectives is to establish a collaboration including information exchange between both parties. Those objectives can be achieved using collaborative workflows [START_REF] Schulz | Facilitating cross-organisational workflows with a workflow view approach[END_REF][START_REF] Contenti | A Distributed Architecture for Supporting e-Government Cooperative Processes[END_REF]. However, recent works [START_REF] Jensen | Leadership, Control, and Conflict Negotiation in the NetBeans.org Community[END_REF][START_REF] Wolter | Collaborative Workflow Management for eGovernment[END_REF] presented new requirements such as control and transparency in collaborative workflows. What is in many cases described as collaboration appears to be coordination and synchronisation of processes by ignoring human-centric interactions. One type of transparency and control supporting mechanism in human-centric collaboration is that of task delegation. In the next section, we motivate the concept of delegation as a support for transparency and control within a human-centric collaborative workflow.

DELEGATION IN WORKFLOWS

In this section, we give a brief overview of delegation in workflows systems. We present the main factors that can motivate delegation and link it to our case study. We then define our delegation model that will monitor the delegation control flow within a workflow.

Context and Motivations

Within workflow management systems we observed a tendency moving away from strict enforcement approaches towards mechanisms supporting exceptions that make it difficult to foresee when modelling a workflow. One specific set of mechanisms is that of task delegation. In recent work we presented task delegation as a mechanism supporting organisational flexibility in the human-centric workflow systems, and ensuring delegation of authority in access control systems [START_REF] Schaad | A Framework for Organisational Control Principles[END_REF][START_REF] Gaaloul | A secure task delegation model for workflows[END_REF]. Task delegation can be very useful for real-world situations where a user who is authorised to perform a task is either unavailable or too overloaded with work to successfully complete it. This can occur, for example, when certain users are sick or on leave. It is frequently the case that delaying these task executions will violate time constraints on the workflow impairing the entire workflow execution. Delegation is a suitable approach to handle such exceptions and to ensure alternative scenarios by making workflow systems flexible and efficient. Schaad presented a literature review of the different aspects and motivations for delegation [START_REF] Schaad | A Framework for Organisational Control Principles[END_REF]. Generally, delegation is motivated by three main factors: organisational, business process management and resources. In the following, we detail specific factors that can motivate delegation:

1. Lack of resources: The task cannot be achieved due to a lack of resource. The user holding the task misses one or several necessary resources. He has to delegate to another user possessing the required medium. Examples for such resources could be a lack of time or equipments.

2. Specialisation: A user might be sufficiently competent to achieve a goal, but it is more efficient to delegate to users in specialist positions, such that the achievement is optimised. Specialisation is a part of the business process management factor.

3. Organisational policies: Goals may conflict and specific organisational policies such as the separation of duties (SoD) may require a user to delegate. SoD constraint defines exclusive relation between tasks. For instance, tasks t1 and t2 can not be assigned to the same user. This defines one of the motivation criteria of the organisational factor.

In the next section, we will identify scenarios taken from MLA case study to illustrate the requirements and criteria for each delegation scenario defined.

Link with the Case Study

During the collaboration between Eurojust organisations A and B, several actors are involved in the MLA process (see Fig. 1). Users role memberships are identified to the system as having one or more roles. We define role-based delegation to support human-centric interactions. We are considering a user-to-user delegation where task execution is atomic and delegation is fully assigned to the delegatee with his defined permissions. Therefore, delegation criteria such as cascaded and/or partial are not considered in this paper [START_REF] Zhang | A rule-based framework for role-based delegation and revocation[END_REF].

In the following, we present two scenarios describing local and global delegation.

Local delegation (DS1): Our interest is related to the Eurojust organisation A. The involved actors are responsible for the reception of the request of assistance and the preparation of the required legal document to be sent to the concerned authority in country B. The role Prosecutor is a senior role and has at his disposal subordinates such as NC and Assistant.

Definition 1. We define a task delegation relation RD including the delegated task T, the delegator u1, the delegatee Global delegation (DS2): It defines a delegation crossorganisations. We consider an instance of the process MLA where the request exists already in the CMS system of country B. The specialisation of Prosecutor B (user Claude member of role Prosecutor) will motivate the prosecutor A (Alice) to delegate T2 for his colleague. Task delegation is defined based on role mapping (RM) cross organisations A and B, where external distributed resources with external distributed roles are defined in the global policy. The delegation relation RD = (T2,Alice,Claude,Prosecutor,RM).

Task Delegation Model (TDM)

In recent work we defined a task delegation model (TDM) based on task life cycle specifications in the workflow management coalition [START_REF]Workflow Management Coalition Terminology and Glossary[END_REF][START_REF] Gaaloul | A secure task delegation model for workflows[END_REF]. Figure 2 depicts a UML state diagram that illustrates the life cycle of our TDM in the form of a state transition diagram from the time that a task is created through to final completion, cancellation or failure. It can be seen that there are a series of potential states that comprise this process.

TDM defines the different states and transitions a task can take in a workflow. A task, once created, is generally assigned to a user. The assigned user can choose to start it immediately or to delegate it. Delegation depends on the assignment transition, where the assigned user has the authority to delegate the task to a delegatee in order to act on his behalf. Moreover, we enriched the model with intermediate states supporting delegation features such as:

• Delegation mode: It defines how delegation request is issued. Pull mode assumes that a delegator has at his disposal a pool of delegatees to be selected to work on his behalf. Pull mode assumes that a delegator is waiting for an acceptance from a potential delegatee. Derived transitions from push mode are accept, cancel and revoke.

• Delegation kinds: It may be classified into grant or transfer [START_REF] Crampton | Delegation in role-based access control[END_REF]. A grant delegation model allows an instantiated task to be available for both delegator and delegatee. As such, the delegator is still having the control to validate or revoke the task, and the delegatee to execute it. However, in transfer delegation models, the assigned task is transferred to the delegatee worklist. The is no validation required and the task is terminated by the delegatee. Transfer delegation is used to support administrative delegation.

Intermediate states define controlled delegation within a workflow. For instance, the delegator might want to cancel. Our TDM would then go back to the state in which it was before (Assigned state). The delegation control flow behaviour remains internal according to the task model, where Completed, Cancelled and Failed are the final states. Note that each edge within the TDM is prefixed with either an S or an U indicating that the transition is initiated by the workflow system or the human resource respectively. We define u1 and u2 belonging to the set of users U, where u1 is the delegator and u2 the delegatee.

WORKFLOW AUTHORISATION CON-STRAINTS

A workflow comprises various activities that are involved in a business process. Activities that are part of a process are represented as tasks. Authorisation information is given which authorises users to perform tasks. Such authorisation information may be specified using a simple access control list or more complex role-based structures [START_REF] Crampton | Delegation and satisfiability in workflow systems[END_REF].

Task Execution Model

We define a task execution model based on the TDM state diagram. We define a UML activity diagram including three main activities: Initialisation, Processing and Finalisation.

During the initialisation of the task, a task instance is created and then assigned to a user. During task processing, the assigned user start/delegate the task which gathers all operations and rights over the business objects related to task resources. Finally the task finalisation would notice the workflow management system that the task is terminated, where termination defines completeness, failure or cancellation (see Fig. 2).

Seeing the task as a block that needs protection against undesired accesses, the activity diagram includes an access control (AC) transition that is in charge with granting or not the access to the task. AC checks defines the transition from the creation of a task to its assignment to a user. This assignment will lead to the processing or the cancellation of the task. Cancellation can be triggered when the assigned user doesn't fulfil the required authorisation to proceed the task instance.

Authorisation Constraints

The AC transition defines the on time authorisation supporting task execution. It defines a relationship between user, task instance and authorisation instance. An authorisation instance defines the permission needed to execute operations on business objects to carry out a task. For instance, the task T4 "Prepare Request Document" requires read() and write() functions on the MLA request object as material resources. Therefore, the assigned user "Prosecutor A" need to be authorised to access T4 task resources.

Definition 2. A workflow authorisation schema is a pair (T,U), where A ⊆ T × U ; u is authorised to perform (or execute) t iff (t, u) ∈ A.

As related in the literature review, the workflow is made of tasks, where a task defines a unit of work that at each invocation performs the binding between different resources needed to complete a specific part of the workflow [START_REF] Russell | Workflow resource patterns: Identification, representation and tool support[END_REF]. The resources that may be involved are different. We distinguish material and human resources for business objects and workflow actors (users), respectively. We aim by this AC specifications to motivate to two sides of task requirements, namely material and human resources.

Once the resources are identified an access control has to be defined to check the authorisation of the initiated user that we call it subject. An authorisation makes the explicit binding between a subject, a task resource (object) and his rights over it (action). An access control policy specifies a level of defining access to task resources. Its pseudo formal expression is:

<Authorisation> <Subject>[role] <Resource>[object] <Action>[operation] <Task>[task type] < /Authorisation>

General Control Process

We illustrate the message flow between access controls components involved during task execution. We present a UML sequence diagram that illustrates whenever a subject claims a task instance to perform it. Basically, a task assignment can be defined in the worklist by the workflow system [START_REF]Workflow Management Coalition Terminology and Glossary[END_REF]. In addition, a subject can claim a task access request without being initially assigned, thereby involving dynamic checks of his authorisation credentials. Whenever a subject issues a claim request to perform a task that is that is protected by the control components. All requests are intercepted by an authorisation enforcement point. The authorisation point is not capable of making an access decision on its own. Therefore, the authorisation enforcement point will request a decision from the authorisation decision point. To make a decision, the decision point queries the policy manager for all policies that are affected to this request. Thus, all policies that apply to the identity of the subject, his role, and policies related to the requested task instance in the corresponding workflow are prompted from the policy manager. The policy manager will browse through its policy repository and returns the set of affected policies to the decision point. Some of these policies may contain dynamic constraints depending on the current task state and the process history. To get this information the decision point will ask the Task Service Manager (TSM) for the current process state. The TSM retrieves all relevant state information and returns it to the authorisation decision point. Now the decision point is able to evaluate the static and dynamic policies. Depending on the used rule base (e.g. Deny, Overrides, Permit) the binary authorisation decision is returned, i.e. access denied or access granted. In the case the access request is denied, the enforcement point will mediate this decision to the subject, for instance as some error message. In the case access was granted. The intercepted request is forwarded to the TSM hosting all task instances. The TSM will initialise the task and passes the original request to it. In case that the claimed task is not in the subject worklist, the TSM will update the worklist and the task will be performed and will send back potential results to the subject.

We made some assumptions and simplifications in the task assignment process. For instance, we assume the subject's identity and his role attribute are already known in the control architecture. Otherwise the subject has to identify himself against some trusted authority or authentication mechanisms. The first one could issue some kind of identity cer- tificate that can be verified by the control architecture, the later one would request the actor's password before the access request will be accepted by the authorisation enforcement component. As a simplification we omitted the logging of audit data performed by the TSM while a task is requested, performed, and finished. Nevertheless, this information is mandatory with respect to the enforcement of dynamic separation of duty control, such as operational or history-based separation of duty. This point will be discussed in the next section.

SECURING TASK DELEGATION

In this section, we introduce delegation protocols to support both push and pull mode. Delegation protocols define two different models that depict the dialogue between a delegator and a delegatee during a secure task delegation. We model the different protocols using UML sequence diagrams. Delegation protocols will ensure delegation of authority in access control systems.

Pull Delegation (TDM1)

The pull delegation model (TDM1) is based on a direct allocation of the task through a delegation without any notion of role. This model associates implicitly an authorisation to a subject. When a subject holding a task initiates a delegation process, then the following procedure manages it:

1. First the delegator is sending a request for delegation to the Delegation Component (DC) for a specific task and a specific subject (the delegatee).

2. The DC checks with the help of the Authorisation Component (AC) if the delegator can actually delegate and the delegatee can receive.

• a) The AC first retrieves the attributes affecting the policy and conducts an initial evaluation regarding the delegator's right to delegate. This is due to the fact that certain task assignments are exclusive and are not allowed to be delegated. In the context of an access control policy, it is defined as an obligation to a rule effect. • b) The AC checks then the task status with the Task Service Manager (TSM) component which browse the current task assignment list to check the availability of the task. • c) The AC receives the history list from TSM.

Finally, the AC sends a response to the DC based on the intermediate results received.

3. The Delegation Component then keeps track of the current delegation within internal history records.

4. DC updates the appropriate policy in the policy repository.

5. DC updates the appropriate worklists (delegator and delegatee's) if the delegation is related to a task instance.

6. Then the delegation request is forwarded to the designated delegatee.

In case of transfer delegation, the given authorisation from the delegator's set are removed from the policy repository.

Push Delegation (TDM2)

The model TDM2 is based on an allocation of the task through a delegation to a role and not directly to a subject. When a subject holding a task initiates a delegation process, then in the TDM2 the following procedure manages it:

1. First the delegator is sending a request for delegation to the Delegation Component (DC) for a specific task and a specific role (Role A).

2. The DC checks with the help of the Authorisation Component (AC) if the delegator can actually delegate based on his policy attributes, then with the task Service Manager regarding the delegated task status.

3. The DC notifies all the subjects belonging to the role (Role A) of the availability of the task.

4. The first one to respond is allocated with the task.

5. The DC checks with the help of the AC if the delegatee can actually receive the task.

6. The DC then keeps track of the current delegation within internal history records.

7. The DC updates the appropriate policy in the policy repository.

8. The DC updates the appropriate worklists (delegator and delegatee's) if the delegation is related to a task instance.

9. Then the delegation is forwarded to the designated delegatee.

Figure 6: Task delegation push model

AC enforcement

The access control model handles normally a delegated task and does not need to be modified. The expression of the associated authorisation for delegation is updated in the existing policy. This way provides several advantages:

• In our TDM1 model, the delegatee is not granted with a new role. The delegation process does not need further control of the permission; the access control model handles normally a delegated task and does not need to be modified. The delegatee inherits his own permissions.

• In our TDM2 model, the link of the authorisation with the role is kept. It allows us to reuse our established access control model based-role.

Based on our models and the case study, we exemplify here our work. The TDM1 model delegation answers the requirements defined in the first delegation scenario (DS1). User Bob exists in the delegatees list of user Alice and is directly assigned to the task T4. The formal expression of TDM1 is: If the request is granted by the delegation component then this delegation message will be forwarded to the delegatee that will include the given authorisation to its own set. From this moment on, the delegatee can claim achieving the task as he is provided with the same access rights functions (permissions) as the previous owner of the task (the delegator). The authorisation instance is explicitly related to the role of the first owner of the authorisation to execute an instance of the task (e.g. task T4).

The structure of the delegation and the granularity of our model allow different delegation. A new dimension to classify the delegation can be now characterised by the degree of delegated power. This parameter evaluates how important is the quantity of responsibilities delegated for a task. Additional specifications regarding the authorisation attributes may be added to support different types of delegation [START_REF] Schaad | A Framework for Organisational Control Principles[END_REF].

Revocation

Revocation is an important process that must accompany the delegation. It is the subsequent withdrawal of previously delegated objects such as a role or a task. A vast amount of different views on the topic can be found in literature [START_REF] Hagstrom | Revocations-A Classification[END_REF]. For simplification, our model of revocation is closely related to the task delegation user-to-user model. Actually, the decision of revocation is issued from the delegator in order to revoke the delegated task, or to cancel the current work. Revoking a task defines an access control enforcement on the current authorisation policy. The delegator has to revoke privileges (permissions) granted to the delegatee in order to complete his task. Revocation can ne triggered automatically based on time constraint, where the delegated privileges are limited in time. Delegator has also the right to request revocation manually. For instance, delegator want to retrieve his task while the revocation time constraint is not consumed yet. To this end, a proactive access control system is required to support delegation based on dynamic states changes. This is a part of our future work.

Deploying Task Delegation

The deployment of delegation scenarios in a workflow system requires the development of several components which support TDM specifications. On one hand, we need a workflow system capable of defining and synchronising the delegation process within the workflow process in itself. On the other hand, we need to check the delegatee credentials to authorise task delegation. Intalio Tempo is a set of runtime components that support human workflow within a service-oriented architecture (SOA). The main goal is to provide a complete and extensible workflow solution with a bias towards interoperable technologies (BPEL, BPEL4People, XForms, REST, and web services) as a default implementation [START_REF]Intalio Tempo. Intalio Tempo Architecture[END_REF].

In this context, we developed a delegation framework to deploy our task delegation model. We implemented the TDM by extending the task object model defined in Intalio Tempo in order to support delegation states. Subsequently, additional transitions such as delegate and revoke are extended to the defined transitions in the task object model. We also leveraged the task list web-based user interface for users to monitor the task delegation life cycle. The idea is to monitor the delegation control flow based on the triggered transitions and to be able to cope with the unexpected events such as the cancellation of a delegation. Intalio Tempo seems to offer a suitable solution to support our TDM requirements, however, the proposed security framework do not fulfill all the authorisation requirements for delegation and will need further investigations. Actually, the proposed approach based on RBAC model (Role-based access control) remains basic and does not cover the delegation of authority aspect [START_REF] Rissanen | Administrative Delegation in XACML[END_REF].

RELATED WORK

WebSphere MQ Workflow provides a richer model that allows users to be described in a broader organisational context. It also supports roles and there can be a many correspondence between users and roles [START_REF] Ibm | IBM Websphere MQ Workflow Getting Started with Buildtime[END_REF]. Staffware has a relatively simple model that denotes users (i.e. individual resources), groups and roles, and allows work to be assigned on the basis of these groupings [START_REF] Staffware | Staffware Process Suite Defining Staffware Procedures Issue 2[END_REF]. IBMs WebSphere MQ Workflow and Staffware both allow a task to be delegated to any user, regardless of his access rights. However, this does not necessarily permit the delegatee to perform the task. For instance, suppose a task T2, in our use case, that involves fetching some data from the CMS system. Suppose Bob does not have the access rights for fetching this data. Delegating T2 to Bob will not allow him to perform it since Bob credentials does not fulfill the authorisation requirements related to task T2. Role-based access control (RBAC) is recognised as an efficient access control model for large organisations. In [START_REF] Barka | Framework for role-based delegation models[END_REF], authors extend the RBAC96 model by defining some delegation rules. Barka and Sandhu proposed a role-based delegation model. They deal with user-to-user delegation. However, proposed approaches do not support task delegation requirements described in the MLA case study delegation scenarios.

The eXtensible Access Control Markup Language (XACML) is an XML-based, declarative access control policy language that lets policy editors to specify the rules about who can do what and when. As an OASIS standard, its greatest strength lies in interoperability [START_REF] Moses | eXtensible Access Control Markup Language (XACML) Version 2.0, OASIS[END_REF]. Unlike other applicationspecific, proprietary access-control mechanisms, this standard can be specified once and deployed beyond the boundaries of organisations and countries. In [START_REF] Rissanen | Administrative Delegation in XACML[END_REF], Rissanen and Firozabadi add new structured data-types to express chains of delegation and constraints on delegation. The main result of their research is an administrative delegation. It is about creating new long-term access control policies by means of delegation in a decentralised organisation. However, this approach does not cover ad-hoc interactions and do not support task delegation constraints. Chadwick et al. [START_REF] Chadwick | Adding support to xacml for dynamic delegation of authority in multiple domains[END_REF] proposed a solution based on the XACML conceptual and data flow models supporting dynamic delegation of authority. The proposed architecture offers a flexible and dynamic way to manage user credentials and assert them in the remote credential providers, however this is not enough to support dynamic delegation of authority. We do believe that delegating a task requires more effort and involves additional specifications related to task delegation states. Task delegation model based-states provides the means to determine faithfully delegation polices proactively, thereby ensuring reactive policy decisions when states such as revoked and cancelled are triggered during task delegation process.

CONCLUSION AND FUTURE DIRECTIONS

The execution of cross-domain eGovernment processes need to support more sophisticated interactions of monitoring.

We define this as requirements to support human-centric collaboration for inter-organisational workflows. Collaboration must be done in a controlled and transparent way.

In this paper, we propose a delegation based mechanism to support and control such kind of interactions between governmental organisations. Our primary concern was to define an approach to support organisational flexibility and to ensure delegation of authority in access control systems. To satisfy this need, we first proposed an extended task model supporting delegation. Our model defines the delegation control flow within a process. We then analysed task delegation requirements with regards to workflow invariants such as task, user and resources. In this context, we proposed an extension to an open source workflow framework to support task delegation. Finally, we detailed delegation protocols to ensure delegation of authority in access control systems based on workflow authorisation constraints. We consider this paper as a primer for future related work in the areas of collaboration and security. The next stage is the integration of an access control systems within our framework to fulfil the delegation of authority requirements. Moreover, we plan to further investigate the area of compliancy accordingly to workflows global policies specifications.

Figure 1 :

 1 Figure 1: Mutual Legal Assistance scenario

Figure 2 :

 2 Figure 2: Task delegation model

Figure 3 :

 3 Figure 3: Task execution model

Figure 4 :

 4 Figure 4: Task assignment sequence diagram

Figure 5 :

 5 Figure 5: Task delegation pull model

  <Delegation> <Issuer>[Subject:Alice] <Receiver>[Subject:Bob] <Task>[T4]x[TaskId] <Authorisation>[Authorisation Instance] < /Delegation> The TDM2 model delegation answers the requirements defined in the first delegation scenario (DS2). User Alice need to delegate based on role equivalence. User Claude with role Prosecutor is one of the potential delegatees that may accept this delegation request. User Claude is the first to accept the request. The formal expression of TDM2 is: <Delegation> <Issuer>[Subject:Alice] <Receiver>[Subject:Claude]x[Role:Prosecutor] <Task>[T4]x[TaskId] <Authorisation>[Authorisation Instance] < /Delegation>

http://www.europol.europa.eu/

http://www.eurojust.europa.eu/

This case study has been performed in joint collaboration between Eurpol, Eurojust and Unisys in the context of the EU FP6 IST Integrated Project R4eGov.