Ahmed Amokrane
email: a_amokrane@esi.dz

A Secure Web Service-based Platform for Wireless Sensor Network Management and Interrogation

Keywords: Web Services, WSN, SOA, AAA, Routing

A Wireless Sensor Network (WSN) is composed of small, low cost and low energy consumption devices called sensors. Those sensors are deployed in a monitored area. They capture measurements related to the monitored phenomenon (temperature, humidity...) and send them through a multi-hop routing to a sink node that delivers them to a Base Station for use and decision making. WSN are used in several fields ranging from military applications to civilian ones, for security, home automation and health care... Up to now, most of the works focused on designing routing protocols to address energy consumption issue, fault tolerance and security. In this paper, we address the issue of secure management and interrogation of WSN through Internet mainly. In our work, we designed and implemented a generic approach based on Web Services that builds a standardized interface between a WSN and external networks and applications. Our approach uses a gateway that offers a synthesis of Web Services offered by the WSN assuring its interrogation and management. Furthermore, Authentication, Authorization and Accounting mechanism has been implemented to provide security services and a billing system for WSN interrogation. We designed our architecture as a generic framework. Then, we instantiated it for two use cases. Furthermore, we designed and implemented a Service Oriented routing protocol for WSN.

Introduction

A Wireless Sensor Network (WSN) is composed of small, low cost and low energy consumption devices called sensors deployed in a monitored area. Those sensors capture measurements related to the monitored phenomenon (temperature, humidity...) and send them by the mean of a multi-hop routing to reach a sink node. The sink delivers them to a more powerful device called Base Station (BS). The BS stores and/or processes data according to the application. WSN can be used in a couple of areas ranging from military tracking and surveillance to civilian applications in home automation (smart home), agriculture, intrusion detection and so on.

This technology has a huge potential application fields in the nearest future and efforts are being conducted to guarantee security services and hence enlarge the spectrum of potential applications. Most of the works focused on energy consumption through designing routing protocols [START_REF] Al-Karaki | Routing techniques in wireless sensor networks: a survey[END_REF] and MAC algorithms [START_REF] Zhang | De-ass: An adaptive mac algorithm based on mobility evaluation for wireless sensor networks[END_REF] that reduce the energy consumption. Also, the security issue has been addressed [START_REF] Wang | A survey of security issues in wireless sensor networks[END_REF].

Today and due to the diversity of applications and the expansion of Internet toward the web of things [W3C], the objectives are slightly moving forward. In fact, the deployed WSNs need to be interconnected with the existing IP networks and mainly Internet. This makes the data they provide accessible for applications and users. Furthermore, those applications are generally heterogeneous and distant. This means that they should cross a couple of networks (Internet) to reach the desired WSN instead of local applications that we usually design for WSN. In this perspective, we have designed a platform based on Web Services [W3C] that offers standardized interfaces for interrogating and managing WSN. Our approach is based on an application level gateway that offers a synthesis of the services offered by the WSN. The platform gives access for users and applications to interrogate and manage the WSN in a secure fashion thanks to the encryption and signature of the exchanged SOAP messages. Furthermore, it offers Authentication, Authorization and Accounting (AAA) services to define who can do what and helps to make a billing system. This is done at the gateway level which helps to save resources in the WSN part.

In a simplified description, our platform offers a set of Web Services for users. Those services give access to interrogate the WSN ("What is the temperature in my bed room"), manage the WSN ("Turn off the sensors in my bed room"), be notified in case of event ("Send me an SMS if someone enters my bed room"), see a summary of who used the platform and add or remove authorization for those services used by the administrators ("Add my son to the list of users", "Add authorization for my son to see what is the temperature in his bed room", "What was the services invoked by my son during this week", "Who used the platform today"...).

Our proposed architecture has been though to be generic. In fact, unlike the existing works in literature, we designed a global architecture independently from any application. We have then instantiated it for two application cases. The first one is an application for meteorology and fire detection where sensors capture the temperature and humidity and send alerts in case of fire detection. The second one deals with the domain of agriculture where sensors capture the air and soil temperature and humidity and help to prevent dryness by sending alerts. Furthermore, we designed and implemented a Service Oriented routing protocol for WSN called Directed Service Oriented Diffusion (DSOD).

The remainder of this article is organized as follows. Section 2 summarizes the existing works that have treated similar problems. Our architecture is described globally in Section 3 and then detailed in Section 4. The instantiation of our framework through the two use cases is presented in Section 5. Section 6 summarizes some of the tests and the obtained results mainly on DSOD performance. Finally, in Section 7 we conclude this paper.

Related works

Few works addressed the issue of interfacing WSN with traditional IP networks. We classified them into two categories. On one side, we have those which use a gateway between the WSN and the external IP network (Internet). In fact, the idea of using application level gateways have been used in [PSL + 06] and [NFH + 08]. Moreover, gateways connected to Internet using GPRS have been introduced in [START_REF] Marin-Perianu | Prototyping service discovery and usage in wireless sensor networks[END_REF]. However, those solutions, in contrary to our framework, don't use SOAs and are based on application messages. Also, D.I.Tapia et al. in [TFR + 09] have introduced proprietary languages based on XML to describe nodes and services. Their problem is the lack of standardization. In [NDMS05, EJ09, CKB06] approaches based on Web Services have been proposed. In the [START_REF] Nada | A sensor-based, web service-enabled, emergency medical response system[END_REF] and [START_REF] Gavin | Applying and extending sensor web enablement to a telecare sensor network architecture[END_REF], the solution is tightly related to the application (emergency medical response, only event driven networks are considered). Dedicated to IEEE 1451 sensors, an architecture based on a gateway implementing Web Services has been introduced in [DHK + 08]. The drawbacks of such an approach is the fact that it cannot be adapted to all applications due to constraints in the WSN. In other works, middlewares have been proposed either in the sensors [START_REF] Fok | Enhanced coordination in sensor networks through flexible service provisioning[END_REF] or implemented in a gateway [THT09, DPR + 05] as well as virtual machines in sensors [START_REF] Muller Rene | A virtual machine for sensor networks[END_REF]. These concepts are interesting to build context aware architectures. However, introducing a middleware or virtual machines is complex and it is generally done in a proprietary way, in response to application needs.

On the other side, we have the other approaches that don't use gateways. They implement the services in the sensing nodes. Those approaches are based on the 6LowPAN [START_REF]Transmission of ipv6 packets over ieee[END_REF], an implementation of IPv6 on top of IEEE 802.15.4. This makes possible the addressing of sensors using IPv6 addresses. However, those works are still in progress. Among them, the authors in [MZP + 09, GCF + 09] have mentioned the possibility of using Devices Profile for Web Services (DPWS) which is still under development [START_REF]Web services discovery and web services devices profile (ws-dd) tc[END_REF]. In a slightly different way, [START_REF] Nissanka | Tiny web services: design and implementation of interoperable and evolvable sensor networks[END_REF] used a reduced implementation of the Web Services through simplifications in WSDL files and the transportation of request messages directly on HTTP instead of SOAP messages. Furthermore, [START_REF] Lars | Towards a zeroconfiguration wireless sensor network architecture for smart buildings[END_REF] and [YNM + 07] used RESTful web services which is an implementation based on HTTP requests instead of SOAP. We note that these simplifications remain proprietary and don't respect the interoperability we are interested in. Unlike these approaches, our framework is based on the standardized Web Services which insures interoperability.

The major problem with the listed works is the fact that they are either tightly related to applications (like [START_REF] Nada | A sensor-based, web service-enabled, emergency medical response system[END_REF]) or they introduce proprietary languages and communication protocols such as [START_REF] Nissanka | Tiny web services: design and implementation of interoperable and evolvable sensor networks[END_REF] and [TFR + 09]. Furthermore, the efforts toward generic approaches are sometimes neglected. However, we have seen that the concept of gateways implementing an SOA (based or not on Web Services) has been introduced. However, no generic approach has been proposed. Therefore, we propose our approach based on a generic architecture including AAA services. To our knowledge, except [YNM + 07], no other work has introduced the AAA to insure security and accounting in WSN.

3 Our architecture

General overview

Our architecture is composed of three main parts:

• WSN Part: it is composed of the deployed sensors that capture the measurements related to the monitored phenomenon.

• The Gateway: it insures the AAA to protect the WSN and insures the translation of the requests (made by the users through Web Services) into requests according to the operating system and technology run by the sensors, and vice versa for the responses. The architecture is summarized in Fig. 1. From an operational point of view, the Gateway offers a set of Web Services classified into five classes described in more details in the following section. The users can list the available Web Services and invoke some of them by sending SOAP requests through the IP network toward the Gateway. The latter implements AAA. If the user is authenticated ans has the authorization to invoke the service, the Gateway translates it into requests sent to the sensors. Then, the answer is sent back in a SOAP massage to the user in the reverse path. If the user is not authorized or not authenticated, an error message is sent back.

Submitted to SAR-SSI 2011

Taxonomy of the offered Web Services

We classified the gateway Web Services into five classes as follows:

• Web Services for WSN real time interrogation: they are services that request a real time data from the sensors or a particular sensor. It could be, for instance, "The mean temperature at home", "The humidity in sensor X", "The temperature in my bed room".... In this case, the request is translated by the Gateway into another one depending on the sensors Operating System and technology and sent to the appropriate sensor. The response, given by the sensor, is sent back to the user.

• Web Services for the WSN management: they are services that deal with the management of the WSN. It could be turning on/off some sensors, modifying the sensing interval of a sensor, launching and stopping the capture-store function (capture data by sensors at regular intervals of time and store them in a database located in the Gateway for further requests and statistics).

• Web Services for archive interrogation (earlier captured data): they are services that request the data that has been captured earlier. It could be the statistics for a period of time, for instance, "The average temperature in my bed room yesterday".

A request for such a service is translated into a request that interrogates a database of the captured-and-stored data. • Web Services for subscription to events: they are services that could be invoked by users or applications that want to subscribe to some events in the WSN. For instance, fire department would be interested in receiving alert messages if a fire is detected by the sensors. Those alerts are sent by the Gateway by mean of SMS or e-mails after receiving a message notifying the occurrence of the event by one or several sensors.

• Web Services for administration: they are services dedicated to the administrators. They help them to set, modify and remove users and authorizations. They focus on the management of the AAA functionalities.

These services are augmented by the AAA. This means that for each service call, the user is authenticated (Authentication), checked against the authorizations (Authorization) and then recorded (Accounting). This insures the establishment of filtering rules. Furthermore, it is done at the gateway level. This helps to save resources in the WSN part since non authenticated or non authorized users are rejected at the gateway level. Moreover, the SOAP messages are encrypted and signed between the user application and the Gateway. This insures the interaction in a secure way.

Detailed architecture

The whole platform is divided into three parts that are independent from each other. They interact through interfaces defined by Web Services (WSDL) for the external part and the Gateway, and by the specific packet format of exchanged messages between the Gateway and the WSN.

The Gateway

We will look at the gateway from two different points of view: in terms of modules representing the main blocks, and in terms of a layered model.

Gateway Modules

The gateway as a whole is divided into four (4) main modules. These modules are interconnected in a mesh structure to simplify the design and for better efficiency. The different modules and the interconnections between them are shown in Fig. 2. They are: In addition, we built a Low Level Services Module which is a registry of the services offered by the sensors in the case where the latter implement a Low Level Service Oriented Architecture (see Section 4.2). The offered Web Services will be built on top of those Low Level Services.

Architecture layered model

We propose a generic model composed of three layers. The model as well as the location of the different modules in the different layers are shown in Fig. 3. The role of the different layers is as follows:

• Web Services Layer: it is the top layer of the model. It insures the interface with the users and handles the SOAP requests. It contains the Web Services Module and the AAA Module since it handles the Web Services and the AAA functionalities.

• Task Layer: it is a set of tasks that are launched by the Web Services Layer to interrogate the WSN or the archives. Each task is in charge of sending the request message (toward the archive or WSN) and wait for the answer. Furthermore, a scheduling mechanism is implemented at this level to insure the priorities for the different requests. This means that some services and/or users have more priority than others, so their tasks are scheduled first. It implements also mechanisms to aggregate requests, for instance, two calls for the same service will send only one message toward the WSN (saving resources in the WSN part).

• Access Layer: it is the bottom layer and it insures the interface with the WSN and the storage platforms. It contains the WSN Access and Archive modules.

From an operational point of view, the incoming requests (SOAP messages of Web Services) are received by the Web Services Layer. The Authentication and Authorization is checked at this level. If the user is not authorized or not authenticated, an error message 6

Submitted to SAR-SSI 2011

The WSN

The WSN part is composed of the deployed sensors. It implements the usual protocol stack of WSNs. It uses a routing strategy that does not impact the way our platform behaves. However, according to the taxonomy of the Web Services we have given earlier (see Section 3.2), it is to note that the routing should be done according to the three ways of collecting data from the WSN: Query Driven (In case of WSN real time interrogation and management services), Event Driven (In case of subscription to events services) and Time Driven (In case of functionalities like capture-store).

Furthermore, according to the capabilities of the sensors, we can design the WSN part in two fashions: the first one as being a usual WSN with nodes that receive and send simple messages. The second one implements a SOA in the sensors.

A Service Oriented WSN and Directed Service Oriented Diffusion

In this section, we present our Service Oriented data gathering scheme for WSN. This scheme is implemented on the WSN side and extends naturally the SOA approach implemented on the gateway. This notion has been introduced also in [START_REF] Jeremie | Service oriented architecture for heterogeneous and dynamic sensor networks[END_REF]. We refer to this approach as being a Low Level Service Oriented Architecture to make a difference with the Web Services and the SOA at the Gateway level (High Level). The sensors in this case offer services (we call them Low Level Services) that could be invoked by other sensors or external nodes by means of Service Invocation Messages (Requests) and the responses (If they do exist) are given in Response Messages. Hence, the exchanged messages carry services invocations and responses as illustrated in Fig. 4.

Through our work, we have designed and implemented a Service Oriented routing protocol. It is a proof of concept of the possibility of implementing an SOA in the WSN part Submitted to SAR-SSI 2011 To our knowledge, no Service Oriented routing protocol have been introduced so far, even if the idea of SOA has been announced in [START_REF] Jeremie | Service oriented architecture for heterogeneous and dynamic sensor networks[END_REF]. DSOD manages Service invocation from sink to nodes and also between nodes in the WSN making possible the composition of Low Level Services in the WSN.

From a general point of view, each nodes maintains three data structures: Inter-est_cache, Data_cache and a Registry. A service invocation (from a sink) toward a node (destination) is translated into a Service Invocation Message. Each node that receives the message checks its local table called Registry. A Registry contains routes (The next hop) toward services in the network. Each service is identified by (Service_Id, Node_Id). If no route exists then the Invocation Message is flooded in the network. Each node that receives the message and sends it to its neighbors, keeps trace of the invocation in its Interest_cache. The Interest_cache is used to find the route back to the sink (source) when a response is given. This is illustrated in Fig. 5. Note that, the same message is forwarded only once (Checked in the Interest_cache before forwarding). When the Response is given, it is sent back through the reverse path of the service invocation thanks to the Interest_cache. Furthermore, the response message is added to Data_cache in each node it passes through to avoid infinite loops and duplication. If a route exists (in the Registry) toward the destination, then the message is sent to the destination through the existing route as illustrated in Fig. 5.

If more than one route exist in the Registry of a node, then only one is chosen, that one having the lowest result of the cost function. The cost function is given by f (next_hop) = amount_of _remaining_energy_in_next_node/number_of _hops_to_destination. The usage of this cost function will help to choose different routes and load balancing between neighbors to save energy in the network as we will see it in Section 6.

Let's recall that the messages are limited in terms of the number of hops. The same holds for the entries in the registries where the routes are dropped if they are not updated for a predefined period of time.

The Registries are maintained in two fashions:

• Implicitly: it is done thanks to the messages that pass through the nodes. Let's recall that each message contains a source and destination service. So each time a message is received by a node, it adds (or updates) the source service to the Registry.

• Explicitly: by mean of explicit messages that a node sends to its neighbors to inform them of the services it offers periodically or after receiving a message asking for that. For instance, the Low Level Services Module in the Gateway sends those explicit messages to build a registry of the available Low Level Service in the WSN.

The user applications

They could be any kind of application that can send, receive and process SOAP messages.

We have designed, for example, applications in Java, C# et PHP. They are much more like user friendly Graphical interfaces. In the context of our work, they are more a proof of concept of interoperability.

5 Instantiation of our generic framework

First instantiation: Fire detection and meteorology

In this use case, the sensors are deployed in a monitored area (forest...) to capture data related to temperature and humidity. They can answer requests for real time data (Temperature and humidity). Approximately they can detect fires but the accuracy of such a detection is out of scope of this paper (see , for instance, [START_REF] Hefeeda | Forest fire modeling and early detection using wireless sensor networks[END_REF]). In the WSN part, the sensors run TinyOS [TIN]. This part is emulated using TOSSIM [TOS], the emulator for TinyOS. It uses Directed Diffusion [START_REF] Chalermek | Directed diffusion: a scalable and robust communication paradigm for sensor networks[END_REF] as a routing protocol.

Second instantiation: Agriculture

The sensors are deployed in agriculture fields to capture data related to temperature and humidity in air and soil. They can answer requests for real time data and detect events like fires and dryness (that help to irrigate at the right time). Again the accuracy of such a detection is out of scope of this paper. The instantiated schema as well as some available services of the five calsses are illustrated in Fig. 6. In the WSN part, the sensors run TinyOS. It is emulated using TOSSIM. The WSN part implements our Service Oriented routing protocol DSOD.

For both of the two applications, the Gateway has been developed using Java. The Web Services are hosted in Apache Axis [AXI], hosted in Apache Tomcat web server [TOM].

Tests and Results

In this section, we present some screenshots of our client applications. They are illustrated in Fig. 7. They represent some of the results of the interaction with the platform. We have also tested our Service Oriented routing protocol DSOD. The results we have obtained are promising for a new paradigm in WSN. We present here some of those tests and results.

Submitted to SAR-SSI 2011

In the first scenario, we consider a grid topology. A number of invocation messages (real time interrogation Web Services) is sent to the Gateway from a user application. The targeted node is always the same as illustrated in Fig. 8. We measure the total number of exchanged messages in all the network and in the nodes located near to the diagonal. The amount of exchanged messages gives us an idea on the load and energy consumption in the WSN. Let's recall that the diagonal is the shortest path in terms of the number of hops between the sink and the destination according to the topology in Fig. 8. For these nodes also, we measured the average number of exchanged messages as well as the standard deviation. These results will help us to get an idea of the load balancing of the routing task between the neighbors.

In terms of the total number of exchanged messages, it is summarized in Fig. 9. We note that it is less than the flooding case and not far from the optimal case. Is is done thanks to the Registries in the nodes helping to route through existing paths instead of flooding. Furthermore, the amount of messages increases in a linear way with the network size. This assures scalability for our protocol.

For the nodes located near to the diagonal, we have recorded the largest number of messages. This is normal since our cost function uses the number of hops to determine the next hop. We have also registered small variances as given in Tab. 1. This illustrates Tab. 2: The results of responding services the load balancing while routing messages between the nodes.

In the second scenario, a client application sends messages to randomly chosen nodes. We measured the amount of lost requests (Services invocations without responses). The results are summarized in Tab. 2. The coverage is around 100% since it is based on flooding to discover the services in the network. Also, no service invocation has been lost even if request messages are lost. This is due to the fact that DSOD takes care of resending the invocation messages through different routes if no answer is received.

Conclusions

Through our work, we have given an architecture that integrates the WSN in IP networks, mainly Internet. Our approach is based on Web Services implemented in a gateway. The usage of Web Services provides opportunities due to the fact that they are standardized and widely used in Internet today. The offered services are augmented by Authentication, Authorization and Accounting (AAA) functionalities to insure filtering clients and requests at the gateway level.

We have given a global overview and detailed decomposition of the design of our framework. Furthermore, it was though to be generic, not limited to some applications. Then, we instantiated it into two applications to provide a proof of concept. We have seen that the interoperability is always insured through the different client applications we developed. Moreover, we have given an implementation of a SOA in WSN which we called Low Level SOA. We have also designed and implemented a Service Oriented routing protocol for WSN called Directed Service Oriented Diffusion (DSOD). It is the first routing protocol in this new paradigm for WSN and the results we obtained are promising.

Fig. 1 :

 1 Fig. 1: Global architecture of our platform

Fig. 2 :

 2 Fig. 2: Gateway Modules

Fig. 3 :

 3 Fig. 3: Our Layered Model for the Gateway

Fig. 4 :

 4 Fig. 4: Message structure in the Low Level SOA in WSN

Fig. 5 :

 5 Fig. 5: DSOD: Principle

Fig. 6 :Fig. 8 :

 68 Fig. 6: Agriculture application instantiation of our generic framework

  Submitted to SAR-SSI 2011 1. Web Services Module: it represents the different Web Services offered by the Gateway. It assures the interface with the Internet and handles the requests coming from the clients (user applications). The first security filtering is done at this level (decrypting and signature checking). Moreover, it encrypts and signs the responses sent back to the clients. It is also responsible for the advertising of the offered Web Services (in UDDI registries). 2. AAA Module: it is responsible for the implementation of the Authentication, Authorization and Accounting functionalities. It is coupled with a dedicated AAA server. It is a critical part in the gateway since it checks the security credentials related to the user, mainly a user name and a password. 3. Archive Module: it is responsible for storing and retrieving the captured data. It assures the interface with the underlying storing technology which could be a relational data base, files, a cloud storage system... 4. WSN Access Module: it is responsible for the interface with the WSN. Depending on the Operating System run in the sensors, it sends the appropriate request messages and handles the response messages.

Submitted to SAR-SSI 2011


Ramzi Debab
email: r_debab@esi.dz

Federated claims based authentication and access control in the vehicular networks

Keywords: Vehicular networks, Federation, claims, SOA, Web Services

The emergence of the vehicular networks has led automakers and researchers to develop connected embedded applications to exchange messages as part of road safety and entertainment. Secondly, the security has become a vital prerequisite for the deployment of such networks. In terms of controlling access to resources, more heterogeneous solutions are proposed based on X.509 certificates, Kerberos tickets, Password techniques, etc. This technologies heterogeneity pushes us to find a solution in order to federate the existing techniques and even future ones. WS-Federation is one of the keys aiming to solve this problem but only suitable for SOAs based on Web Services technology. Consequently, our approach was to integrate native distributed vehicular applications in a SOA and then apply the WS-* security-related Web services specifications while checking the federated access control to resources through WS-Federation and the notion of the claims. The result is a communicative architecture based on the ESB (Enterprise Service Bus) pattern that we baptized VSB (Vehicular Served Bus).

Introduction

Context

Thanks to the ITS (Intelligent Traffic Systems) technology, our cars are able to embed applications that aim to exchange so vital messages in coordination with road infrastructure units in order to ensure the road users safety. It will be possible, also, from his vehicle to consume services in the Internet or the Cloud. Today, we know different schools (American, European and Japanese) in the field of ITS. Thus, many projects are emerging from research laboratories of several car manufacturers and universities. Nevertheless, the technological heterogeneity will be, undoubtedly, one of the thorny issues to resolve in order to build a network of distributed applications to communicate seamlessly [START_REF] Mihail | Inter-Vehicle Communication Systems: A Survey[END_REF]. Furthermore, security is a crucial prerequisite [START_REF] Hubaux | Securing Vehicular Communications[END_REF] for the deployment of vehicular networks and several solutions have been proposed. Access control to resources is a security aspect that has attracted the attention of researchers. Thus, varied and heterogeneous implementations have been developed based on X.509 certificates [START_REF] Rongxing | Security in Vehicular Ad Hoc Networks[END_REF] [HUB07], Kerberos tickets, the Username / Password couples [START_REF] Huaqun | An Anonymous DoS-Resistant Password-based Authentication, Key Exchange and Pseudonym Delivery Protocol for Vehicular Networks[END_REF], etc.

Problematic

Before presenting our problem, let us imagine the case of a vehicle in a country "A" that uses X.509 certificates to consume different services. This same vehicle travels to another country "B" and wants to consume the same services. Yet, in the country "B", Kerberos tickets are rather used. Consequently, our problem is to find a solution that unifies the various access control techniques in the vehicular networks. The solution must be open and agile to incorporate future technologies that do not exist yet. Web services are the best technology to build SOA. This success is due to the richness of WS-* specifications that support different aspects: orchestration, transactions, security, etc. WS-Federation is one of the WS-* security specifications that aims to federate heteregenous authentication and access control protocols. For this reason, we considered WS-Fedeartion as a good candidate to solve our problematic. However, we have to think about how to integrate vehicular applications which are not necessarily Web Services into a SOA (based on Web Services) in such way that we can apply WS-Federation.

Our Approach

Initially, our objective is to develop a technique for integrating vehicular applications into a SOA using the bus pattern. Our inspiration is the Enterprise Service Bus (ESB) [START_REF] Thomas | SOA design Patterns[END_REF]. We have adapted the ESB for the case of the vehicular networks and the new bus architecture is named VSB (Vehicular Service Bus). With VSB, it is possible to consider a vehicular network as a set of mobile and fixed nodes consuming and providing both services.

The second step is to apply the WS-Federation on our VSB architecture to solve the security heterogeneity problem.

Paper Structure

This paper presents the developed solution in three phases. The first one will be dedicated to the communicative architecture of the VSB. The second phase analyses the federated security module. Finally, we will close the paper by presenting some results of our work.

Communicative Architecture

In this section we present, first of all, the vehicular network as a SOA. After that, we describe our solution based on the VSB pattern. The VSB is designed using the WCF 1 technology [START_REF] Ahmed | Performance Evaluation of Windows Communication Foundation's Interoperability[END_REF] allowing LOB (Line Of Business) applications integration into a SOA.

SOA Vision

We have studied a set of vehicular applications and the different communication paradigms (Push model like notifications from traffic lights system to vehicles, Pull model like a STOP command from a police car to an ordinary vehicle and other messaging models). Consequently, the SOA seems to be an excellent candidate to develop vehicular applications. According to our Submitted to SAR-SSI 2011 3 vision, a vehicular network is a set of three domains (see Fig. 1):

• V2Internet: Vehicle to Internet where a vehicle is able to consume Internet or Cloud Services. • V2V: Vehicle to Vehicle where a vehicle exchanges messages with other vehicles in the Adhoc domain. • V2I: Vehicle to Infrastructure where messages are exchanged between the vehicles and the roadside infrastructure nodes.

VSB Structure

To integrate disparate applications and expose them as Web Services, we have designed a communication bus embedded into each vehicular network node. The VSB is based on the ESB pattern and is inspired from the Microsoft Biztalk2 platform [START_REF] George | Pro Biztalk[END_REF].

The diagram (see Fig. 2) shows the different VSB components (and an example of an alert message lifecycle) by defining the following components :

• The VSB runtime: it is the execution environment containing a layer of engines exposed as WCF services (transformation of message formats [based on XSLT, for example], message routing, business rules, orchestration [based on workflows], Pub/Sub engine for notifications and events, resolving endpoints (like resolving a UDDI 3.0 URN into a URI). The VSB runtime is also equipped with a hosting environment for the various WCF services.

• Adapters: they are wrappers for the VSB applications and are exposed as input (input ports) and output (output ports) Web services. Their main role is to adapt the transport protocols, encodings and formats in line with the runtime input and vice versa at the output with the external system.

Internal VSB Architecture

The figure (see Fig. 3) describes the VSB internal architecture that is similar to Biztalk architecture and contains the follwing components :

• Core web services layer: This layer contains the web services that implement the basic functionality of the VSB: the transformation of message formats, the resolution addresses of endpoints, and other customized features.

• Engines layer: this layer contains the different engines as the Pub/Sub engine that handles the registration messages as well as publications.

• VSB application layer: This layer contains a set of VSB applications as input and output Web Services. Each application has endpoints that implement different MEPs (Message Exchange Patterns) as Request / Reply, One Way, Pub / Sub, etc. Each application can be equipped with a discovery endpoint to be discoverable on the network. At each endpoint, there is an adapter, followed by a pipeline defined by an itinerary that is selected according to criteria defined by the rules engine.

• Tools layer: this layer is composed of the service and channel models as well as the WCF LOB SDK provided by Microsoft to create core services, VSB applications, adapters, etc.

Decentralised VSB Architecture

The figure (see Fig. 4) describes an example of a life cycle of an alert message corresponding to the slippery road alert generated by a LOB application of a vehicle (1). This alert message passed by the service road bus (2) is subsequently transmitted to all involved vehicles (3). The retransmission is based on the content of the message after a certain treatment on the service road bus. Finally, the message is transmitted through the bus of each vehicle for potential treatments to be managed through the appopriate application. The same message can be routed to a mobile device for the benefits of interactions with the driver.

Security Architecture

In this section we present the architecture of our security module comprising federated authentication and authorization based on the claims forming the security tokens.

Advantages of claims based access control

In this type of authorization, access control for the called service operations is done according to the content (the claims) of security tokens provided by the service consumers. Thus, access permissions are defined dynamically into security policies.

This model offers more flexibility than others (oriented roles, resources, etc.) for the following advantages [ERL09]:

• Decoupling authentication mechanisms from applications and services. Otherwise, an application consumer has to implement all supported authentication protocols. Nevertheless, the model is abstract and oriented tokens in such way it can support existing authentication mechanisms and even future ones. • All credential types are supported. Just serializing them according to a given format is sufficient. • Possibility of transforming the tokens from one format to another.

• This paradigm is based on defining security policies containing service requested claims. Thus, the service consumer has to deliver just tokens according to the policy and containing the requested claims.

Federated Access Control Architecture

In this section, we propose the architecture of the federated access control applied to our VSB platform. This architecture is based on the actif scenario of WS-Federation (WS-Federation Active Requestor Profile). The choice of this profile is supported by the flexibility of hosting services into different process types instead of just web servers. In addition, the active profile is applied to 'smart' applications, which correspond to the case of vehicular applications. A federated architecture is generally composed of three entities :

• Client: in our case, it is a vehicular network node wishing to consume a service exposed in the same network, the Internet or on the Cloud.

• The service: it is a set of exposed functionalities to consume. Imagine the case of a control traffic light service.

• The Security Token Service (STS): it provides security tokens required by the service to consume via WS-Trust. A trust relationship relies the STS to the exposed service. The following figure (see Fig. 5) shows the federated architecture of an example of two vehicles (ordinary car and police car) trying to update the status of a traffic light service :

A vehicle which is equipped with a VSB, has an application in output (for example) and develops a proxy that is responsible for consuming the service. Thus, the federation active profile follows these steps: the proxy of the vehicle discovers the service through the WS-Discovery and retrieves the security policy set on a federated endpoint via WS-SecurityPolicy and WS-MetadataExchange. This policy expresses the claims to be included in the security token that must be issued by one ore more determinated STSs (1). Then, the native identity of the vehicle which does not correspond to the requested claims is sent to the STS within a security token request message (RST (Request Security Token)) (2). It should be noted, also, that the STS implements the WS-Trust that allows the tokens management. The STS then authenticates the identity of the vehicle and provides the required token (SAML 3 formatted for instance) (3) and generates, therefore, the response to the RST request as a data structure called RSTR (Request Security Token Response) (4) that contains the following :

• The serialized token, signed by the STS and containing the required claims and the proof key encrypted with the public key of the service to consume. The token is also encrypted with the public key of the service to consume. • The proof key for the vehicle application. The RSTR is protected by the policy expressed in the Binding of the STS. The vehicular application retrieves the proof key from the RSTR and sign the message to be sent to the service using the proof key (5). Thus, the service authenticates the token sent with the public key of the STS, retrieves the proof key from the token with its private key to authenticate the vehicle application as a real source of the request. Finally, the service makes a decision in terms of access permissions according to the generated claims (6).

3 Security Assertion Markup Language.

Involved WS-* Specifications

The secured VSB architecture involves so many WS-* specifications in addition to WS-Fedreration.

The following figure (see Fig. 6) defines the involved specifications :

The federated architecture defines foreach entity a set of specifications :

• Client: the proxy implements WS-MetadatExchange to discover services metatdata, WS-Security to protect the exchnaged messages and WS-SecureConversation to maintain a secure session.

• The service: its endpoints implement WS-Federation to support the federation principle, WS-Discovery to get the services discoverable, WS-Eventing to manage the events and the notifications, WS-Policy to define security policies, WS-Trust to manage the generated tokens, WS-Security and WS-SecureConversation.

• The Security Token Service (STS): it implements pratically the same specifications as the service to consume.

Towards a Vehicular Profile for Web Services

Thanks to the VSB architecture, it is possible de define a new profile adpated to the vehicular applications supporting all the necessary security specifications related to the Web Services.

The following figure (see Fig. 7) describes the profile layers which contains in addition to the DPWS (Device Profile for Web Services) components, different WS-* security specifications and supports also all transport protocols related to the vehicular networks as VTP (Vehicular Transport Protocol). It should be noted that we assumed that the architecture is already service oriented. Thus, our POC was designed to demonstrate the feasibility of SOA in the case of vehicular networks and test some important parameters such as time consumption during the message exchange. We used the Visual Studio 2010 tool with C# language, the WCF 4 and WIF Frameworks to develop our POC. The different application processes (vehicles processes, light services and intersection assistance system) were tested on a machine with the following characteristics :

• Model : MacBook of Apple.

• OS : Windows 7.

• RAM : 4Go DDR2 with 667 MHz.

• Processor : Intel Core 2 Duo T7250 with 2.16GHz.

We conducted performance tests on a vehicular application consuming the intersection service for two scenarios: direct and mutual authentication based on certificates. In each scenario, we modify the binding corresponding to the service and the application (transport protocol, security mode, cryptographic algorithms, etc.). After authentication, we record the average time between the date the message was sent and its interpretation at the application level during a cycle of light (green, orange, red). Transport protocols that were subjects of our tests are TCP that has been used in [START_REF] Mihail | Inter-Vehicle Communication Systems: A Survey[END_REF] and HTTP of which a similar protocol was defined in [START_REF] Ahmed | Performance Evaluation of Windows Communication Foundation's Interoperability[END_REF].

Tab 1. Tokens types required by the Traffic light service.

Tab 2.

Messages treatments times

Fig 1 .

 1 Fig 1.Vehicular ntwork domains.

1.

  Fig 2.VSB components

  Fig 3.Internal VSB Architecture

  Fig 5. Federated Access Control Architecture

  Fig 6.Security WS-* Specifications related to the VSB

Submitted to SAR-SSI 2011

http://www.microsoft.com/france/serveur/biztalk/default.aspx

The choice of X.509 certificates is justified by the fact that it is the most common authentication mode in the literature of the vehicular networks security.

The RSA algorithm (asymmetric) is used to generate the symmetric keys used for encryption with AES, while the signature is based with SHA 256.

Submitted to SAR-SSI 2011

We have supposed that all vehicles implement X.509 certificates 4 as native identities. However, the traffic light service requires other types of tokens formatted into SMAL and defined in the following table : Vehicle Type Claims Types Claims Values Emergency Vehicle http://claimsbased.VPWS.dz/samples/2009/06 /claims/role /emergencyvehicle http://claimsbased.VPWS.dz/samples/2009/06 /claims/permission /subscribe http://claimsbased.VPWS.dz/samples/2009/06 /claims/permission /changestate Ordinary Vehicle http://claimsbased.VPWS.dz/samples/2009/06 /claims/role /vehicle http://claimsbased.VPWS.dz/samples/2009/06 /claims/permission /subscribe

Submitted to SAR-SSI 2011 9 4 Performance evaluation

To validate our work, we developed a POC (Proof Of Concept) application to solve the problem of the intersections management. In our POC, only the emergency vehicles are allowed to change the state of traffic light seamlessly. However, all vehicles are allowed to subscribe to the intersection management service in order to receive notifications about the road states. The architecture of our application in terms of components is described by the following figure: Discussion. The real time is, perhaps, the most important criteria in vehicular communications. According to [START_REF] Caveney | Efficient Message Composition and Coding for Cooperative Vehicular Safety Applications[END_REF], latency allowed for the warning signal in case of violation of the red light is 100 ms. According to our tests, the worst time reached is just one-tenth of latency. That is very encouraging. Nevertheless, it is expected that the recorded times in real conditions are greater than those recorded in simulation. Whereas concerning the durations of the federated authentication, the first time is estimated at almost 1.4 sec. However, thanks to WS-SecureConversation, a secure session is maintained between the communicating entities ; which avoids re authentication.

Conclusion

Our work is part of vehicular communications security and tried to answer a dual problem: how to integrate vehicular applications into a SOA? And how to federate different access control or authentication protocols? Submitted to SAR-SSI 2011

To answer the first problem, we developed an integration solution for vehicular applications, following the bus pattern. Our inspiration was the ESB pattern, which gave birth to a bus embedded in any vehicular network node and that we have named VSB (Vehicular Service Bus). To answer the second problem, we have implemented the WS-Federation and many other security-related specifications such as WS-Security. This solution is feasible thanks to the architecture of the VSB based on Web Services and all WS-* specifications.


P Gajardo
email: pedro.gajardo@usm.cl

H Ramírez
email: hramirez@dim.uchile.cl

A Rapaport
email: rapaport@supagro.inra.fr

J Harmand
email: harmand@supagro.inra.fr

Minimal-time bioremediation of natural water resources

Keywords: Environmental engineering, biotechnology, waste treatment, continuous systems, minimumtime control

We study minimal time strategies for the treatment of pollution of large volumes, such as lakes or natural reservoirs, with the help of an autonomous bioreactor. The control consists in feeding the bioreactor from the resource, the clean output returning to the resource with the same flow rate. We first characterize the optimal policies among constant and feedback controls, under the assumption of a uniform concentration in the resource. In a second part, we study the influence of an inhomogeneity in the resource, considering two measurements points. With the help of the Maximum Principle, we show that the optimal control law is non-monotonic and terminates with a constant phase, contrary to the homogeneous case for which the optimal flow rate is decreasing with time. This study allows the decision makers to identify situations for which the benefit of using non-constant flow rates is significant.

Introduction

The fight against eutrophication of lakes and natural reservoirs (excessive development of phytoplankton associated with an excess of nutrients) constitutes a major challenge. Such an ecological question has given rise to many studies over the last 30 years (see, for instance, the surveys [START_REF] Gulati | Lakes in the netherlands, their origin, eutrophication and restoration: state of the art reviews[END_REF] or [START_REF] Sondergaard | Lake restoration: successes, failures and long term effects[END_REF] and references herein). To remediate to eutrophication, many techniques such as bio-manipulation or ecological control have been proposed with mitigated results. A common point of the proposed remediation approaches is that they are usually based on "biotic" actions on the lake trophic chain dedicated to the restoration of the equilibrium of the local ecosystems. To do so, most studies are based on empirical knowledge. However, since the seventies, the use of eutrophication models (from heuristic data-based models at steady state to more recent dynamical mass-balance based models) together with optimal control techniques have been proposed (cf. [START_REF] Estrada | Addressing the control problem of algae growth in water reservoirs with advanced dynamic optimization approaches[END_REF] and references herein).

In the present paper, an alternative to these techniques is studied using a very simple model of the lake. It is assumed that a small bioreactor is available to treat the polluted water in removing a substrate considered as being in excess in the lake water. More particularly, we consider a natural water resource of volume V polluted with a substrate of concentration S l . As underlined above, typical examples of such 1 natural water resources to be treated are lakes or water tables that have been contaminated with diffused pollutant as organic matter or nutrients. The objective of the treatment is to make the concentration of such pollutant/contaminant S l decreasing down, as fast as possible, to a prescribed value S l , with the help of a continuous stirred bioreactor of volume V r . The reactor is fed from the resource with a flow rate Q, and its output returns to the resource with the same flow rate Q, after separation of biomass and substrate in a settler (see Figure 1). The settler avoids the presence of excessive biomass used for the treatment in the natural resource, that could bring undesirable sludge and possibly lead to an increase of the eutrophication. We assume that during the whole treatment, the volume V of the resource does not change. Since the pioneer work by [START_REF] D'ans | Optimal control of bacterial growth[END_REF], the optimization of bioreactors operation has received a great attention in the literature; see [START_REF] Rani | Control of fermenters: a review[END_REF][START_REF] Banga | Dynamic optimization of bioreactors: a review[END_REF][START_REF] Alford | Bioprocess control: Advances and challenges[END_REF] for reviews of the different optimization techniques that have been used in bioprocesses. Among them, the theory of optimal control has proved to be a generic tool for deriving practical optimal rules [START_REF] Van Impe | Optimal adaptive control of biotechnological processes[END_REF][START_REF] Smets | Optimal control of (bio-)chemical reactors: generic properties of time and space dependent optimization[END_REF][START_REF] Smets | Optimal adaptive control of (bio)chemical reactors: past, present and future[END_REF]. Clearly, one can distinguish two different kinds of problems depending on the continuous or discontinuous operation mode of the process. On one hand, if the process is operated in fed-batch, the control objective is usually to optimize trajectories for attaining a prescribed target in finite time or maximizing the production at a given time [START_REF] Hong | Optimal substrate feeding policy for fed batch fermentation with substrate and product inhibition kinetics[END_REF][START_REF] Lim | Computational algorithms for optimal feed rates for a class of fed-batch fermentation: numerical results for penicillin and cell production[END_REF][START_REF] Johnson | The control of fed-batch fermentation processes: a survey[END_REF][START_REF] Irvine | Sequencing batch reactors for biological wastewater treatment[END_REF][START_REF] Kurtanjek | Optimal nonsingular control of fed-batch fermentation[END_REF][START_REF] Shioya | Optimization and control in fed-batch bioreactors[END_REF][START_REF] Tsoneva | Augmented lagrange decomposition method for optimal control calculation of batch fermentation processes[END_REF][START_REF] Moreno | Optimal time control of bioreactors for the wastewater treatment[END_REF][START_REF] Srinivasan | Dynamic Optimization of Batch Processes: I. characterization of the Nominal Solution[END_REF][START_REF] Gajardo | Minimal time sequential batch reactors with bounded and impulse controls for one or more species[END_REF][START_REF] Mazouni | Optimal time switching control for multireaction batch process[END_REF]. On the other hand, the optimal control of continuous processes usually involves a two steps procedure. First, the optimal steady state is determined as a nominal set point, maximizing a criterion [START_REF] Spitzer | Maximization of steady-state bacterial production in a chemostat with ph and substrate control[END_REF][START_REF] Soukkou | Optimal control of a cstr process[END_REF]. The benefit of operating a periodic control about the nominal point can be analyzed [START_REF] Abulesz | Periodic optimization of continuous microbial growth processes[END_REF][START_REF] Ruan | Comparison of several periodic oscillations of a continuous fermentation process[END_REF]. Then, a control strategy that drives the state about the nominal set point from any initial condition is searched for [START_REF] Kittisupakorn | Comparison of optimisation based control techniques for the control of a cstr[END_REF], possibly in the presence of uncertainty on the model using extremum seeking techniques [START_REF] Wang | Optimizing bioreactors by extremum seeking[END_REF][START_REF] Zhang | Adaptive extremum seeking control of continuous stirred-tank bioreactors[END_REF][START_REF] Marcos | Adaptive extremum seeking control of a continuous stirred tank bioreactor with haldane's kinetics[END_REF][START_REF] Bastin | On extremum seeking in bioprocesses with multivalued cost functions[END_REF] Concerning these strategies, the problem studied in the present paper exhibits several original points with respect to the contributions available in the literature. Indeed:

-The actual control problem is dedicated to the optimization of transient trajectories -as in the case of fed-batch processes -while it is actually a continuous process. It is due to the fact that in a standard optimal minimal-time problem of a bioprocess, the volume of water to be processed is completely decoupled from the bioreactor. In other terms, the problem is to process, using a biological reactor, a given volume of "substrate" which is finally released in the environment after processing (whatever it is operated continuously or discontinuously). In the present problem, the treated water is immediately recycled into the lake. From the modelling point of view, this introduces an original coupling via the dilution of the treated water with the polluted one.

-The lake and the reactor are isolated in the sense no biomass is supposed to be present in the water resource. The biomass used as a catalyst in the bioreactor is separated from the treated water and withdrawn from the overall process. Thus, in particular, the quantity of available biomass is not a limiting parameter.

We consider the usual chemostat model for describing the dynamics of the bioreactor:

     Ṡr = -µ(S r )X r + Q V r (S l -S r ) Ẋr = µ(S r )X r - Q V r X r (1)
where S r and X r stand for the concentrations of substrate and biomass, respectively. For sake of simplicity, we assume that the yield coefficient of this reaction is equal to one (at the price of changing the unitary value of the biomass concentration, that is always possible). The growth rate function µ(•) fulfills the properties Assumption A1. a. Function µ(•) is increasing and such that µ(0

) = 0. b. Function µ(•) is concave.
A reasonable hypothesis is to assume that the volume of the resource is much larger than the bioreactor one: V >> V r , and that the possible variations of the manipulated variable Q are slow compared to the time scale of the bioreactor dynamics. Consequently, one can consider that dynamics (1) is fast and its trajectories at the quasi-steady state (S ⋆ r , X

⋆ r ) = (S r (Q), S l -S r (Q))
, where S r (Q) fulfills µ(S r (Q)) = Q/V r (see the usual equilibria analysis of the chemostat [START_REF] Smith | The theory of the chemostat[END_REF]).

Problem:

The optimization problem consists in driving in minimal time the concentration of the resource down to a prescribed value S l > 0, playing with the control variable Q > 0. In Section 2, we assume that this concentration is uniform in the resource, while in Section 3 we study the effect of a spatial inhomogeneity. For each case, we characterize the optimal policy Q ⋆ (resp. Q opt (•)) among constant (resp. feedback controls). Section 4 is devoted to numerical simulations and discussions.

The homogeneous case

The dynamics of the resource concentration is simply

Ṡl = Q V (S r (Q) -S l ). (2)
Notice that under Assumption A1.a, choosing Q is equivalent to choosing S r as a control variable:

Ṡl = αµ(S r )(S r -S l ), S r ∈ (0, S l ) (3)
where we denote α = V r /V .

Proposition 1 Under Assumption A1, the best constant control Q ⋆ is defined as Q ⋆ = V r µ(S ⋆ r ), where S ⋆ r
is the unique minimum of the function

T f (S r ) = 1 αµ(S r ) ln S l (0) -S r S l -S r (4)
on the interval (0, S l ).

Proof. For a constant control, solutions of (2) can be made explicit:

S l (t) = S r (Q) + (S l (0) -S r (Q))e -Q V t , (5)
as well as the time T f (S r ), given in (4), for reaching the target with Q = V r µ(S r ). The function T f (•) tends toward +∞ when S r tends toward 0 or S l . Consequently, its infimum is reached on the interval (0, S l ). Denote by T ⋆ f its minimum, that we fix in the following. Then, for each constant control S r , one has

dS l (T ⋆ f ) dS r = 1 -1 + αµ ′ (S r )T ⋆ f (S l (0) -S r ) e -αµ(Sr)T ⋆ f d 2 S l (T ⋆ f ) dS 2 r = 2µ ′ (S r ) + (αµ ′ (S r ) 2 T ⋆ f -µ ′′ (S r )(S l (0) -S * r ) αT ⋆ f e -αµ(Sr )T ⋆ f
and one deduces with Assumption A1 that the map S r → S l (T ⋆ f ) is strictly convex. Notice that one has necessarily S l (T ⋆ f ) ≥ S l and S l (T ⋆ f ) = S l when S r = S ⋆ r realizes the minimum of the function T f (•). Consequently, the optimal control S ⋆ r is unique. 2

Proposition 2 Under Assumption A1, the optimal feedback fulfills Q opt (S l ) = V r µ(S opt r (S l )) with

S opt r (S l ) ∈ argmax Sr ∈(0,S l ) µ(S r )(S l -S r ) . (6)
Moreover, t → Q opt (t) is decreasing along any optimal trajectory.

Proof. It is straightforward to check that the optimal feedback S opt r is the one that makes the time derivative of S l , given by (3), the most negative at any time. A necessary condition is to have have µ ′ (S opt r )(S l -S opt r ) = µ(S opt r ). Deriving this last expression w.r.t. time, one has Ṡopt

r (2µ ′ (S opt r ) + µ ′′ (S opt r )(S opt r -S l )) = µ ′ (S opt
r ) Ṡl and from Assumption A1, on obtains Ṡopt

r < 0. 2
For usual growth functions, one obtains the expressions:

linear: µ(s) = µs, Monod: µ(s) = µ max s K + s , S opt r (S l ) = S l /2 S opt r (S l ) = K 2 + KS l -K

Consideration of a spatial inhomogeneity

The simplest way to introduce a gradient of concentration in the model of the resource is to consider two 2), that we assume to be large with respect to V r . Water is pumped from the first one while the clean one is rejected in the second one.

compartments of volumes V 1 , V 2 such that V = V 1 + V 2 (see Figure
Denoting

α i = V r /V i (i = 1, 2), one obtains the dynamics Ṡ1 = Q V 1 (S 2 -S 1 ) = α 1 µ(S r )(S 2 -S 1 ) Ṡ2 = Q V 2 (S r (Q) -S 2 ) = α 2 µ(S r )(S r -S 2 ) (7)
and can easily check that the domain

D = {(S 1 , S 2 ) ∈ R 2 + | S 1 ≥ S 2
} is invariant for any control S r (•) such that S r (t) ∈ (0, S 2 (t)] for any t > 0. We shall consider initial conditions in D and define the target For p ∈ [0, 1] and τ ≥ 0, we define the function

T = {(S 1 , S 2 ) ∈ D | S 1 ≤ S l }. bioreactor Q biomass settler Q Q V V V 2 1 Q r resource
A(p, τ ) = e -ατ if p = 0 (1 -p)e -ατ 1-p -pe -ατ p 1 -2p if p ∈ (0, 1 2 ) 1 + α 2 τ e -ατ 2 if p = 1 2 A(1 -p, τ ) if p ∈ ( 1 2
, 1] and for S 0 > S l the function

B(S r ) = S l -S r S 0 -S r , S r ∈ (0, S l ) . Proposition 3 Let p = V 1 /V . For initial conditions such that S 1 (0) = S 2 (0) = S 0 > S l , the best constant control Q ⋆ and time T ⋆ f to reach the target T are defined by Q ⋆ = V r µ(S ⋆ r )
, where S ⋆ r is such that the graph of B(•) touches tangentially the graph of S r → A(p, µ(S r )T ⋆ f ) at S r = S ⋆ r . Proof. The solution of [START_REF] Gajardo | Minimal time sequential batch reactors with bounded and impulse controls for one or more species[END_REF] with constant control S r ∈ (0, S l ) can be made explicit:

S 1 (t) = S r + (S 0 -S r )A(p, µ(S r )t) ,
and the time T f to reach the target fulfills A(p, µ(S r )T f ) = B(S r ). Notice that one has the property

S 1 (t) ≥ S l ⇐⇒ A(p, µ(S r )t) ≥ B(S r ) ,
from which the statement of the proposition follows.

2

If one consider the family of functions A T (S r ) = A(p, µ(S r )T ), parametrized by T > 0, one has a graphical interpretation of the optimum depicted in Figure 3.

B(•) is a concave function and one can check that A T (•) are strictly convex for values of S r large enough (under Assumption A1). Consequently, there cannot exist more than one best constant control S ⋆ r in the domain where A T ⋆ f is convex. Remark 1 Notice that the case of an homogeneous resource can be seen formally as the limiting case p = 0 (although cases when p is close to 0 are not compatible with assuming that V 1 , V 2 are large with respect to V r ). One can easily check that A(p, τ ) < A(0, τ ) for sufficiently large values of τ . Furthermore, times T ⋆ f are increasing with respect to S 0 -S l . Consequently, for initial conditions such that S 0 is far from S l , the time T ⋆ f is larger for an homogeneous resource than for non-homogeneous one, even when the parameter p is unknown and the control S ⋆ r is determined for the homogeneous case. For S 1 > S 2 > 0 and γ > 0, we define

φ(S 1 , S 2 , γ, S r ) = µ(S r ) 1 + γ (S 2 -S r ) (S 1 -S 2 ) , (8)
ψ(S 1 , S 2 , γ) = µ ′ (S 2 ) -γ µ(S 2 ) S 1 -S 2 . ( 9
)
The proof of the following lemma is left to the reader.

Lemma 1 Under Assumption A1, for S 1 > S 2 > 0 and γ > 0, the function φ(S 1 , S 2 , γ, •) is strictly concave on [0, S 2 ] and the property max

Sr ∈(0,S2] φ(S 1 , S 2 , γ, S r ) = φ(S 1 , S 2 , γ, S 2 )
is fulfilled exactly when ψ(S 1 , S 2 , γ) ≥ 0.

Proposition 4 Under Assumption A1, from any initial condition in D \ T , the optimal control Q opt (•) consists in reaching a subset I ⊂ D \ T from which the constant control Q opt = V r µ(S 2 ) is optimal until S 1 (•) reaches S l , where S 2 is the value of S 2 when I is reached. Moreover, t → Q opt (t) is increasing when approaching the set I.

Proof. Recall first that D is invariant. If S 1 = S 2 > S l , the feedback S r = S 2 cannot be optimal (this would imply Ṡ1 = Ṡ2 = 0 at any time). So, any optimal trajectory is such that S 1 (t) > S 2 (t) for any t > 0. Let us write the Hamiltonian, along with the adjoint equations:

H = -1 + max Sr∈[0,S2] µ(S r ) [α 1 λ 1 (S 2 -S 1 ) + α 2 λ 2 (S r -S 2 )] λ1 = α 1 µ(S opt r )λ 1 , λ 1 (T opt ) < 0 λ2 = µ(S opt r )(α 2 λ 2 -α 1 λ 1 ) , λ 2 (T opt ) = 0
One deduce immediately that λ 1 (t) < 0 for any t ≥ 0 and can consider the function

γ(t) = α 2 λ 2 (t) α 1 λ 1 (t) ( 10
) that fulfills γ = µ(S opt r ) [(α 2 -α 1 )γ -α 2 ]
, γ(T opt ) = 0. Notice that γ = 0 implies γ < 0 and then one obtains γ(t) > 0 for any t ∈ [0, T opt ).

When S 1 > S 2 , optimizing the Hamiltonian is equivalent to maximizing φ(S 1 , S 2 , γ, •) (defined in ( 8)), and then Lemma 1 provides the uniqueness of S opt r . A straightforward calculus gives

d dt γ S 1 -S 2 = α 2 µ(S opt r ) S 1 -S 2 γ 1 - S 2 -S opt r S 1 -S 2 -1 .
From γ(T opt ) = 0 we deduce the existence of t ∈ [0, T opt ) such that d dt γ S1-S2 < 0 for all t ∈ [ t, T opt ]. Then, for ψ given by ( 9), one has Proposition 5 Under Assumption A1, for any initial condition in D \ T , the optimal trajectory is unique.

ψ = Ṡ2 µ ′′ (S 2 ) - γ S 1 -S 2 µ ′ (S 2 ) - d dt γ S 1 -S 2 µ(S
Proof. We recall, from the proof of Proposition 4, that along any optimal trajectory, one has S 1 (t) > S 2 (t) and γ(t) > 0 for any t ∈ (0, T f ). Then, one has Ṡ1 < 0 and can re-parametrize the dynamics of variables S 2 and γ, defined in [START_REF] Van Impe | Optimal adaptive control of biotechnological processes[END_REF], in terms of S 1 instead of time t, write the non-autonomous dynamics for optimal trajectories:

dS 2 dS 1 = α 2 α 1 (S opt r -S 2 ) (S 2 -S 1 ) , S 2 (S l ) = S 2 (T opt ) dγ dS 1 = (α 2 -α 1 )γ -α 2 α 1 (S 2 -S 1 ) , γ(S l ) = 0 (11)
where

S opt r is the unique maximum of φ(S 1 , S 2 , γ, •) on [0, S 2 ]. When S opt r < S 2 and γ > 0, one has ∂φ ∂S r = γ S 2 -S opt r S 1 -S 2 - µ(S opt r ) S 1 -S 2 + µ ′ (S opt r ) = 0 (12)
and hence ∂ 2 φ ∂S r ∂γ = -µ(S opt r ) γ < 0. Fix S 1 , S 2 and consider S opt r as a function of γ. From ( 12), one has

∂ 2 φ ∂S r ∂γ + ∂ 2 φ ∂S 2 r ∂S opt r ∂γ = 0
and from the strict concavity of φ(S 1 , S 2 , γ, •), given by Lemma 1, one deduces ∂S opt r ∂γ ≤ 0. The Jacobian matrix of system ( 11) is of the form

  ⋆ α2 α1(S2-S1) ∂S opt r ∂γ -((α2-α1)γ-α2) α1(S2-S1) 2 ⋆  
from which one observes the non-negativity of off-diagonal terms, because (α 2 -α 1 )γ -α 2 = γ/µ(S opt r ) < 0. So, the dynamics (11) is cooperative (in time S 1 ), and since γ(S l ) = 0, one deduces that two solutions of (11) cannot cross in the (S 1 , S 2 ) plane. Finally, one obtains the uniqueness of the optimal trajectory for a given initial condition in D \ T .

2

Remark 2 When S 1 (0) = S 2 (0) = S l , from the expression of the Hamiltonian we obtain that the optimal control S opt r is such that at the beginning it maximizes µ(S r )(S l -S r ). Therefore, it is exactly the same as in the homogeneous case of Proposition 2. Measuring the initial rate of variation of S 2 gives an estimation of the parameter α 2 to fit the model, as one has

Ṡ2 (0) = α 2 µ(S opt r )(S 2 (0) -S opt r ) .
If it is close to α, then the model with one compartment should suit.

For S 0 1 > S l > S 0 2 , we define when α 1 = α 2 :

f 0 (S 0 1 , S 0 2 ) = α 2 1 - S 0 1 -S 0 2 S l -S 0 2 α1-α2 α1 (α 2 -α 1 )(S 0 1 -S 0 2 ) , β = α 1 α 2 α 1 α 1 -α 2 and when α 1 = α 2 : f 0 (S 0 1 , S 0 2 ) = ln S 0 1 -S 0 2 S l -S 0 2 (S 0 1 -S 0 2 ) , β = e.
Proposition 6 The set I, where a constant control is optimal, is given by

I = {(S 0 1 , S 0 2 ) ∈ (S l , +∞) × (0, S l ) s.t. S 0 2 ≤ S2 or µ(S 0 2 )f 0 (S 0 1 , S 0 2 ) ≤ µ ′ (S 0 2 ) }
where S2 is the unique solution in (0, S l ) of

µ( S2 ) = βµ ′ ( S2 )(S l -S2 ) . (13)
Proof. With control Q = V r µ(S 0 2 ), S 2 (•) is equal to S 0 2 and solution S 1 (•) can be made explicit. Then, time T f such that S 1 (T f ) = S l , and solution γ(•) such that γ(T f ) = 0 can be also made explicit. Let f (t) = γ(t)/(S 1 (t) -S 0 2 ). According to Lemma 1, this constant strategy is optimal exactly when

µ ′ (S 0 2 ) ≥ µ(S 0 2 )f (t) , t ∈ [0, T f ] . (14)
One can easily check that ḟ = α 2 µ(S 0 2 )(γ -1)/(S 1 -S 0 2 ), and consequently, ḟ cannot be null more than one time (recall from the proof of Proposition 4 that γ is non-increasing). One has also f (0) > 0, f (T f ) = 0, and f ′ (T f ) ≤ 0.

If f ′ (0) ≤ 0, then condition ( 14) is equivalent to have (S 0 1 , S 0 2 ) below the graph of the curve C defined by µ(S 0 2 )f 0 (S 0 1 , S 0 2 ) = µ ′ (S 0 2 ). A straightforward but lengthy computation gives f (0) = f 0 (S 0 1 , S 0 2 )). One can also check that f ′ (0) ≤ 0 is equivalent to have (S 0 1 , S 0 2 ) below the line L defined by S 0 1 -S 0 2 = β(S l -S 0 2 ). The intersection point ( S1 , S2 ) of C and L is given by S2 solution of [START_REF] Kittisupakorn | Comparison of optimisation based control techniques for the control of a cstr[END_REF], its uniqueness being guaranteed by the concavity of µ. One can easily check that C is below L for any S 2 ∈ [ S2 , S l ]. If f ′ (0) ≥ 0, on can check that max t f (t) = 1/β(S l -S 0 2 ) and then condition ( 14) is equivalent to have S 0 2 ≤ S2 . Moreover, the straight line S 2 = S 2 is below the graph of the curve C in the interval [S l , S 1 ] (see Figure 4). 2

For the Monod law, one can find

S 2 = 1 2 -K(1 + β) + K 2 (1 + β) 2 + 4KβS l .
4 Discussion and numerical simulations

The benefits of our theoretical analysis is to identify efficient pumping strategies and some of their robustness properties. We summarize those contributions in terms of the following rules for the decision makers: 1. The profit of using the optimal feedback strategy compared to the best constant one, can be easily determined numerically (see the simulations below). As expected, the more the resource is initially polluted, the more the improvement of the feedback policy is significant. Depending on the ratio "initial pollution over desired maximal pollution level", the decision maker can then decide whether it worth adopting a timevarying strategy. 2. A spatial inhomogeneity of the pollution concentration improves the treatment time on the condition that the resource is enough polluted. Moreover, applying the best constant strategy as if the resource was perfectly homogeneous is robust with respect to uncertainty on the inhomogeneity parameter in the sense that it provides a guaranteed time (see Remark 1).

3. Measuring the initial speed of variation of concentration at two remote locations in the resource allows to identify the inhomogeneity parameter of the model (see Remark 2). Then, the decision maker can decide if it worth considering a feedback strategy with two measurement points instead of one. 4. The optimal feedback strategy for the inhomogeneous case consists in applying a constant flow rate when the concentration S 2 reaches a prescribed value given by Proposition 6. The concentration S 2 is then maintained constant, without having to measure the concentration S 1 (see Figure 4).

Simulations have been conducted for the Monod law with µ max = 1 s -1 , K = 1 mol.m -3 , and volumes V = 1000 m 3 , V r = 1 m 3 . The initial concentration of pollutant has been chosen equal to 1 mol.m -3 uniformly. Figure 5 shows the comparison of minimal times for different values of S l (the curves corresponds to different values of the parameter p).

On this example, one can see that for S l = 0.01, the minimal time among constant controls is about twice larger than among feedbacks. The influence of inhomogeneity is also quite significant. The optimal feedback (6) for the homogeneous case is a simple law that provides a decreasing flow rate Q w.r.t. time (cf. Proposition 2), contrary to the inhomogeneous case for which it is non-monotonic (cf. Proposition 4). In Figure 6, we compare the optimal policy Q opt (•) for p = 0.4 and S l = 0.1 with Q 1 (•), resp. Q 2 (•) applying the formula (6) on measurement S 1 , resp. S 2 .

The true optimal feedback control, in the model that consider both measurements, is more sophisticated in the sense that it anticipates the approach to the target, increasing the flow rate and freezing it. The study has been made assuming that the steady-state characteristics Q → S r (Q) of the bioreactor is perfectly known. Uncertainty on this map as well as on measurements will be the matter of a forthcoming work.

Figure 1 :

 1 Figure 1: Interconnection of the bioreactor with the resource.

Figure 2 :

 2 Figure 2: Consideration of non-homogeneity in the resource.

Figure 3 :

 3 Figure 3: Graphical determination of S ⋆ r and T ⋆ f .

Figure 4 :

 4 Figure 4: Backward integration of the extremals.

Figure 5 :

 5 Figure 5: Comparison of optimal times.

Figure 6 :

 6 Figure 6: Optimal and sub-optimal policies.

  2 ), which is positive for t ∈ [ t, T opt ]. Since ψ > 0 at T opt , there exists t s ∈ [ t, T opt ) such that ψ ≥ 0 for t ≥ t s . Defining t = inf{t s ∈ [ t, T opt ) : ψ ≥ 0 for t ∈ [t s , T opt ]}, with Lemma 1, one concludes that the optimal S opt r is constant equal to S 2 = S 2 ( t) at any time t ≥ t.

	When t > 0, let us write S opt r Ṡ2 ( t) = 0. This implies to have Ṡopt = uS 2 with u ∈ [0, 1]. The left derivative u( t-) has to be positive and r ( t-) > 0. 2

Acknowledgment

This research was developed in the context of DYMECOS INRIA associated team, being partially supported by INRIA-CONICYT French-Chilean cooperation program and MOMARE SticAmsud project . The first and third author thank the support of FONDECYT projects 1080173 and 1070297, and Fondo Basal, Centro de Modelamiento Matematico -U. de Chile.