Damien Cassou
email: damien.cassou@inria.fr

Benjamin Bertran
email: benjamin.bertran@inria.fr

Nicolas Loriant
email: nicolas.loriant@inria.fr

Charles Consel
email: charles.consel@inria.fr

A Generative Programming Approach to Developing Pervasive Computing Systems

Keywords: D.2.11 [Software Engineering]: Software Architectures-Domain-specific architectures, Languages, Patterns; D.3.4 [Programming Languages]: Processors-Code generation, Retargetable compilers pervasive computing, generative programming, DSL

Developing pervasive computing applications is a difficult task because it requires to deal with a wide range of issues: heterogeneous devices, entity distribution, entity coordination, low-level hardware knowledge. . . Besides requiring various areas of expertise, programming such applications involves writing a lot of administrative code to glue technologies together and to interface with both hardware and software components.

This paper proposes a generative programming approach to providing programming, execution and simulation support dedicated to the pervasive computing domain. This approach relies on a domain-specific language, named DiaSpec, dedicated to the description of pervasive computing systems. Our generative approach factors out features of distributed systems technologies, making DiaSpec-specified software systems portable.

The DiaSpec compiler is implemented and has been used to generate dedicated programming frameworks for a variety of pervasive computing applications, including detailed ones to manage the building of an engineering school.

Introduction

Pervasive computing systems are being deployed in a rapidly increasing number of areas, including building automation, assisted living, and supply chain management. Regardless of their target area, pervasive computing systems have a typical architectural pattern. They aggregate data from a variety of distributed sources, whether sensing devices or software components, analyze a context to make decisions, and carry out decisions by invoking a range of actuators. Because pervasive computing systems are standing at the crossroads of several domains (e.g., distributed systems, multimedia, and embedded systems), they raise a number of challenges in software development.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. GPCE'09, October 4-5, 2009, Denver, Colorado, USA. Copyright c 2009 ACM 978-1-60558-494-2/09/10. . . $10.00

Heterogeneity. Pervasive computing systems are made of off-theshelf entities, that is, hardware and software building blocks. These entities run on specific platforms, feature various interaction models, and provide non-standard interfaces. This heterogeneity tends to percolate in the application code, preventing its portability and reusability, and cluttering it with low-level details.

Lack of structuring. Pervasive computing systems coordinate numerous, interrelated components. A lack of global structuring makes the development and evolution of such systems error-prone: component interactions may be invalid or missing.

Combination of technologies.

Pervasive computing systems involve a variety of technological issues, including device intricacies, complex APIs of distributed systems technologies, undocumented interfaces, and middleware-specific features. Coping with this range of issues results in code bloated with special cases to glue technologies together.

Dynamicity. In a pervasive computing system, devices may either become available as they get deployed, or unavailable due to malfunction or network failure. Dealing with these issues explicitly in the implementation can quickly make the code cumbersome.

Testing. Pervasive computing systems are complicated to test. Doing so requires equipments to be acquired, tested, configured and deployed. Furthermore, some scenarios cannot be tested because of the nature of the situations involved (e.g., fire and smoke). As a result, the programmer must resort to writing specific code to achieve ad hoc testing.

Software engineering approaches provide developers with general-purpose support, targeting a wide spectrum of areas, from business applications to scientific computing. For example, middlewares like CORBA [START_REF] Omg | The common object request broker: Architecture and specification[END_REF]] offer a profusion of services, large APIs, and abstraction layers to hide low-level intricacies. Yet, they do not cover the specific range of issues involved in developing a pervasive computing system: heterogeneous entities, application structuring, combination of technologies, dynamicity, and testing. Leveraging existing software engineering approaches thus requires the programmer to write code to bridge the gap between generalpurpose support and pervasive computing-specific needs.

Our approach

We propose a generative programming approach to providing support throughout the development of a pervasive computing system: programming, simulation and execution. This approach relies on a domain-specific language, named DiaSpec, dedicated to describing a pervasive computing system. Let us outline the development process underlying DiaSpec. This process revolves around key stages and roles depicted in Figure 1.

Taxonomy. Because of their heterogeneity, entities of pervasive computing environments need to be specified in a high-level manner to abstract over their variations. The number of existing entities also require to characterizing the ones that are relevant to a given area. To address these issues, we provide an area expert with a declarative language to define a hierarchy of building blocks (stage ). Each class of building blocks is characterized in terms of the types of data that are gathered from the environment and the actions that are supported.

Architecture.

A taxonomy definition is used as a basis to declare the architecture of pervasive computing applications. To do so, we introduce a declarative language inspired by architecture description languages (ADLs) [START_REF] Medvidovic | A classification and comparison framework for software architecture description languages[END_REF] but dedicated to an architectural pattern commonly used in the pervasive computing domain [START_REF] Anind | A conceptual framework and a toolkit for supporting the rapid prototyping of contextaware applications[END_REF]]. This architectural pattern consists of context components fueled by sensing building blocks from the taxonomy. These components process gathered data to make them amenable to the application needs. Context data are then passed to controller components that trigger actions in building blocks (stage ).

Development. A DiaSpec description, consisting of a taxonomy definition and architecture declarations, is then passed to a compiler, called DiaGen. This compiler produces a Java programming framework, dedicated to the input DiaSpec description (stage ).

DiaGen generates high-level, DiaSpec-specific operations to support the development of devices and applications (stages and ). In doing so, the generated support abstracts away from underlying technologies. As well, it raises the level of abstraction by implementing a language to query a pervasive computing environment to discover entities. This language is specific to each DiaSpec description.

Simulation. To test pervasive computing applications prior to deploying a real environment, the DiaGen compiler generates simulation support. It produces support to implement the simulated building blocks from a set of predefined behaviors, whenever possible. This generated support is then linked to our pervasive computing simulator, named DiaSim [START_REF] Bruneau | Diasim, a parameterized simulator for pervasive computing applications[END_REF]]. DiaSim provides an editor to build a simulated environment and a 2D-renderer to guide and visualize the simulation (stage ).

Deployment. Last, the system administrator deploys the pervasive computing system. To this end, a distributed systems technology needs to be selected. Currently, DiaGen offers a back-end for the following targets: Web Services [Consortium 2004], RMI [START_REF] Bryan | Java RMI: Remote Method Invocation[END_REF]], CORBA [START_REF] Omg | The common object request broker: Architecture and specification[END_REF] and SIP [START_REF] Rosenberg | SIP: Session Initiation Protocol[END_REF]. In doing so, we close the gap between these general-purpose software layers and the pervasive computing-specific needs (stage ). This targeting does not necessitate any changes in the application code. Furthermore, the simulated environment can be mixed with the actual environment. This form of hybrid simulation enables applications to migrate incrementally to an actual environment, performing unit tests on actual components.

Our contributions

In this paper, we propose a domain-specific approach to supporting the development of pervasive computing systems. We generate a programming framework dedicated to a high-level description of a pervasive computing system. Our contributions can be summarized as follows.

• DiaSpec. We introduce a declarative language dedicated to specifying pervasive computing systems. DiaSpec includes (1) a language to define a taxonomy of the kinds of building blocks relevant to a target area and (2) an ADL-inspired language to describe application architectures. DiaSpec has been designed The rest of this paper is organized as follows. Section 2 introduces DiaSpec throughout an example. Section 3 examines the different elements generated in the dedicated programming framework. This section also describes how to develop on top of a Dia-Gen-generated programming framework. In Section 4, we present the generation of a layer specific to a distribution systems technology. Section 5 discusses the generation of a simulator configuration. In Section 6, we describe our implementation and the evaluation of our approach. Related works are discussed in Section 7 and conclusions are given in Section 8.

DiaSpec

This section introduces the DiaSpec language. First, we examine how to specify the taxonomy of a pervasive computing environment. Then, we present declarations to define the architecture of a pervasive computing application.

Working example

To illustrate our approach, an example of fire management is used throughout this paper. This example is part of a larger project aimed to automate an entire engineering school building. This project is briefly presented in Section 6.

To manage fire situations, we assume fire is detected by analyzing data from smoke and temperature sensors. When a fire occurs the corresponding application must trigger sprinklers and alarms, and unlock doors to allow occupants to evacuate the building.

Specifying a taxonomy

Pervasive computing applications interact with the environment through building blocks. Whether software or hardware, we view these building blocks as devices. A taxonomy is a collection of device declarations, each of which characterizes a set of possible device implementations sharing common functionalities. Device functionalities consist of data sources and actions. A data source specifies values sensed by a device. An action declares a set of operations supported by a device. Device declarations also include attributes, characterizing properties of devices instances. Device declarations are organized hierarchically allowing devices to inherit attributes, sources and actions from other devices.

Let us now describe device declarations in more detail by examining the taxonomy for fire management given in Figure 2. Device classes are introduced by the device keyword. At the root of our taxonomy is the Device node (line 1). It introduces the location attribute. The SmokeDetector device extends the root node and defines the Smoke data source, using the source keyword (lines 3 to 5). Another example of device declaration is Door (lines 15 to 18). Besides a data source giving the door state, Door defines the Locking action interface to operate a door lock. An action interface defines the signatures of methods supported by a device (lines 20 to 22). These methods are triggered by applications. As explained in Section 3, the hierarchy of device classes and the attribute declarations are used to generate support for device discovery. The DiaSpec declarations of the fire management application are presented in Figure 5. The declaration of a context component (the context keyword) consists of a name, a list of context/source names as input, and a type as output. For example, the SmokeDetected context takes a Smoke source as input, produced by the SmokeDetector device class (line 1). The restriction to this device class is expressed by the from keyword. SmokeDetected produces a value of type Smoke. In addition to functionalities, context components are declared as producing data relative to some situation, expressed as an index. For example, the SmokeDetected component produces a boolean value that is relative to the location index, indicating where the smoke is detected. When multiple indices are associated with a given context value, it is relative to all the declared indices. When a context component does not declare an index, its output context data are not relative to any situation.

For another example, consider the FireState context component that produces a value of type boolean indicating whether a fire is occurring. This value is computed from two input contexts, namely SmokeDetected and AverageTemperature, and is relative to the location index.

Note that the declaration of the source of a context does not make explicit how the values are supplied, i.e., push or pull. Indeed, the generated framework provides the programmer with both modes.

The declaration of a controller component (the controller keyword) consists of a name, input context names and action clauses. For example, the FireController controller component takes the FireState context as input and trigger actions defined by device interfaces, namely Locking, OnOff, and Activation (lines 11 to 16). Interfaces may be narrowed down to a device class with the on keyword, just like a source of context may be restricted to a device class with the from keyword.

Once the application architecture is declared, the programmer implements the components. This development is supported by a dedicated framework discussed in the following section.

Dedicated programming framework

DiaGen generates a programming framework with respect to a set of declarations for device classes, context components and controller components. DiaGen produces an abstract class for each entity declaration (device, context and controller), providing methods to support the development (discovery and interactions). It also generates abstract method declarations to allow the developer to program the application logic (e.g., triggering device actions). Implementing a DiaSpec-declared entity is done by subclassing the corresponding generated abstract class. In doing so, the developer is required to implement each abstract method. To facilitate this process, most Java IDEs are capable of generating class templates based on super abstract classes. The developer writes the application logic in subclasses and not in the generated abstract classes.

Generating abstract classes instead of incomplete source code better separates programming support and developer code. As a result, generating a new programming framework, after changes in a DiaSpec description, does not override the code of the developer. However, these changes might modify the generated support, requiring the developer to revise his already-written code.

Let us now describe the dedicated support generated for devices, contexts and controllers.

Device implementation

The compilation of a device declaration produces a dedicated skeleton in the form of an abstract class depicted in Figure 6. Let us examine what is generated for each part of a device declaration: actions, sources and attributes. Actions An action corresponds to a set of operations supported by a device. It takes the form of an interface included by the abstract class generated for a device declaration. Each operation is to be implemented by the device developer. This implementation is aimed to bridge the gap between the declared interface and an actual device instance.

The following code fragment wraps a Door device that is controlled using X10, a protocol commonly used in home automation [X10]. According to the declaration of the Door device (Figure 2, lines 15 to 18), the generated Door class (Figure 6) declares abstract methods lock and unlock (lines 4 and 5). The Door_X10 implementation of these two methods (Figure 7, lines 9 to 19) relies on the X10 library.

Sources A device declares sources that make its state and sensed data available to context components. The generated support provides the developers with dedicated methods to update source data. In the above example, the generated setLockedStatus method (Figure 6, line 3) sets the door state and is called by the developer (Figure 7, lines 12 and 18). This method is generated thanks to the LockedStatus declaration (Figure 2, line 17).

Attributes Devices are characterized by attributes. These attributes can be assigned values at runtime. Attributes are managed by generated getters and setters. For example, the Door device inherits the location attribute from the Device node (Figure 2, line 1), which triggers the generation of a setLocation method (Figure 6, line 2). In Figure 7, the setLocation method is used (line 6) to set the door location to a value passed as a constructor parameter.

Developing application logic

For each context and controller declaration, the DiaSpec compiler generates a skeleton, implemented as an abstract class. The devel-opment of the application logic thus consists of implementing the generated abstract classes.

Implementation of context components

From a context declaration, DiaGen generates support to develop the context processing logic. This support allows distributed devices to be selected through service discovery. Proxies are generated to interact with selected devices.

The code fragment in Figure 8 presents the implementation of the SmokeDetected context declaration. This is done by extending the corresponding generated abstract class named SmokeDetected (not shown here, but similar to the one in Figure 6) with a new class named MySmokeDetector. Because this context is declared as taking a Smoke input source from smoke detectors (Figure 5, line 2), the generated framework provides support to select and interact with instances of this device class. For example, the allSmokeDetectors method is generated in the abstract class SmokeDetector to discover all available smoke detectors and is used in Figure 8 line 4. The subscribeSmoke method is invoked to subscribe to the Smoke input source.

A context may access data from devices using two interaction modes: pulling (line 23) or pushing (line 4 for subscription and line 8 for notification). The implementation of a context component must provide values to its consumers, whether other contexts or controllers. To do so, methods are generated as illustrated by lines 11 and 14 where the context component code pushes a new boolean value to indicate the presence of smoke at a specific location. These interaction modes are further described in Section 3.4.

Implementation of controller components

DiaGen generates support to create a controller component from its DiaSpec declaration. Controllers use the context information to take decisions that are carried out by calling actions on devices.

To do so, support is generated to allow a controller to access context information in both push and pull modes. This is illustrated by the FireController generated abstract class (not shown here, but similar to the one in Figure 6). In this abstract class, and because the FireController depends on the FireState context (Figure 5, line 12), methods have been generated to provide both modes of interaction to access FireState context information. In Figure 9, the implementation of the FireController controller component is done by extending the corresponding generated abstract class named FireController with a new class named MyFireController. The implementation starts by invoking the subscribeFireState method, generated in the abstract superclass FireController to be notified when the FireState information changes (Figure 9, line 4). Correspondingly, the method fireStateChanged, declared abstract in the generated abstract class FireController, is overridden to receive these notifications (Figure 9, lines 7 to 28). Arguments passed to the notification callbacks are always the new context value, followed by the indices characterizing this value.

The controller declaration makes explicit what devices are controlled through what operations. This information is used to generate an abstract class that supports mechanisms to discover target devices. Device discovery is illustrated in line 13 of Figure 9 where methods discover and doorsWhere are called to select all the doors of the building. The implementation of these methods is generated in the abstract superclass FireController.

Methods unlock (line 14), on (line 18) and activate (line 25) are generated in the Door, Sprinkler and Alarm proxies, respectively. A proxy is a generated class representing a local view of a remote device. In doing so, a device invocation abstracts over distribution details.

After having presented the overall programming support given by a generated framework, let us focus on a key mechanism to cope with dynamicity, namely, device discovery.

Device discovery

Our dedicated programming frameworks provide support to discover devices based on a taxonomy definition. Device discovery returns a collection of proxies for the selected devices. Importantly, this collection is encapsulated in a composite object, an instance of the composite design pattern [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF]]. An example of such collection, DoorComposite, is returned in line 13 of Figure 9.

In this design pattern, the developer can process all elements of the collection either explicitly by using a loop or implicitly by invoking a method of the composite that implements an iteration. Line 14 in Figure 9 is an example of an implicit iteration. Lines 24 through 26 illustrate an explicit iteration.

Composites provide a way of factorizing exception handling. The generative approach has the potential of further leveraging this situation by parameterizing the generative process with respect to policies for exception handling and fault tolerance. We are currently investigating this direction.

To help developers express queries to discover devices, DiaGen generates a Java-embedded, type-safe DSL, inspired by the work of [START_REF] Kabanov | Embedded typesafe domain specific languages for Java[END_REF]. This technique makes it possible to keep using a standard Java compiler, instead of augmenting the Java grammar, as is done in Silver [START_REF] Van Wyk | Attribute Grammar-Based Language Extensions for Java[END_REF] and ArchJava [START_REF] Aldrich | ArchJava: connecting software architecture to implementation[END_REF].

An example of the use of our query language is given in the MyFireController class shown in Figure 9. The fireStateChange method selects doors to operate. The call to doorsWhere (line 13) restricts the selection to doors in the building where the fire has been detected. On line 17, the discover method call returns sprinklers specifically located where the fire is occurring.

More complex queries can also be expressed, as illustrated below.

Location room1, room2;

... discover(doorsWhere().location (or(eq(room1),eq(room2))));

This query selects doors that are either located in room 1 or 2.

A method suffixed by Where is available for each device that can be discovered. These methods return a dedicated filter object on which it is possible to add specific filters over attributes associated wth the device class. For example, the FireController abstract class defines a doorsWhere method that returns a DoorFilter. This filter can be further parametrized by adding an attribute filter for the location attribute defined by the Door in the taxonomy. This is done by calling the location() method defined in the generated DoorFilter class. The parameter to this method is either a Location value or a logical expression. If a Location value is passed then the discovered devices must have this location in order to be selected. If a logical expression is chosen, the attributes of the selected devices hold with respect to the logical expression. A logical expression is made of relational and logical operators. New methods can be defined to further enhance the expressiveness of the query language.

Our approach allows developers to specify filters for more than one attribute, as is shown in the following example. This query will select all temperature sensors that are both in room 1 and provide a specified minimum accuracy. Our current implementation does not allow logical expressions across attributes. For example, it is not possible for a query to specify that a device must have a particular value for an attribute or another value for another attribute. We are working on this limitation. This embedded DSL is both expressive and concise. It plays a key role in enabling the developer to handle the dynamicity of a pervasive computing environment without making the code cumbersome.

Interaction modes

As mentioned earlier, an application interacts with a device either to carry out an action or access context data. A generated programming framework supports the former case with the command interaction mode. The latter case is supported by both a push and pull mode.

Command.

A command is a one-to-one asynchronous interaction mode, similar to a remote procedure call. The developer can pass arguments to a command according to signatures included in the DiaSpec taxonomy. Because a command is limited to operate a device, it does not return a value. However, errors can be expressed as exceptions. An example of command invocation is given in line 14 of Figure 9.

Pull. A context can fetch data from devices and other contexts. As well, a controller can fetch data from contexts. To achieve these interactions, the pull mode provides a one-to-one synchronous interaction mode with a return value. Accessing data from a device then consists of invoking the appropriate methods of the device proxy returned by the device discovery mechanism. This is exemplified by line 23 in Figure 8. Accessing data from a context is achieved by calling a method with the required context indices.

Push. This mode corresponds to the asynchronous publish/subscribe paradigm. When a device or a context needs to push some data (e.g., whenever it changes), it calls a set method implemented in its abstract class. This is illustrated by the SmokeDetected context that publishes the Smoke event. To do so, its abstract class implements a setSmokeDetected method that takes a Smoke value as argument, together with an index value characterizing the event. This index value indicates the location where the smoke is detected. An event value is received by all entities that have subscribed to the event type. A subscription method is generated in an abstract class for each input source or context declared in a component.

The management of subscribers and the propagation of events are supported by the generated programming frameworks, easing the development process.

Targeting distributed technologies

A generated programming framework abstracts away from the underlying distributed systems technologies. Besides raising the level of abstraction, this strategy makes the application code portable across distributed systems technologies without any change. Dia-Gen currently offers four back-ends targeting Web Services, CORBA, SIP and RMI. Each of these technologies provides specific features and mechanisms with various benefits for the development of pervasive computing systems. For example, RMI is wellsuited for testing because it requires a light infrastructure. SIP is needed when a pervasive computing system relies on a telephony infrastructure.

Each of these technologies is widely deployed, providing a profusion of existing components. For example, Web Services technology offers services in a wide range of areas (e.g., weather forecasting and electronic commerce). In our approach, these existing components can be re-used as building blocks to develop DiaSpec applications. They are introduced as devices in a taxonomy. From a device declaration, DiaGen generates the configuration and code necessary to integrate device instances in DiaSpec applications.

The rest of this section describes how DiaGen compiles Dia-Spec concepts into Web Services and CORBA. This compilation relies on generative programming tools existing in both distributed systems technologies. These tools allow a generative programming approach to be used throughout the compilation process. In doing so, boilerplate tasks are avoided, making the development of Dia-Spec applications less error-prone.

Web services

The generation of a dedicated Web Services back-end is performed in three stages as illustrated by Figure 10. In stage a , given a DiaSpec taxonomy, DiaGen generates interface descriptions written in the Web Service Description Language (WSDL). A translation is needed to adapt the high-level communication abstractions of our approach into Web Services concepts. For example, DiaSpec actions become operations. Figure 11 shows the WSDL translation of the Alarm device defined in Figure 2. In stage b , from these WSDL definitions, stubs and skeletons are generated using the Axis libraries 1 . Finally, in stage c , DiaGen creates the glue-code to plug the generated Web Services stubs and skeletons with DiaSpec dedicated programming framework.

CORBA

The back-end generation process for Web Services and CORBA are quite similar. The DiaSpec taxonomy is used to generate descriptions written in the Interface Definition Language (IDL). DiaSpec concepts are translated to the IDL constructs. Devices, contexts and controllers become interfaces. Actions are mapped into methods. DiaGen generates the glue-code to fill the gap between CORBA stubs and skeletons and the dedicated programming framework.

Note that DiaGen-generated WSDL and IDL descriptions can be used independently of our approach to develop Web Services and CORBA components. The compliance of these native components is checked by their compiler, enabling their integration in a DiaGen-generated software system.

1 http://ws.apache.org/axis/java/index.html

Generation of the simulation part

Existing simulation tools for pervasive computing applications are usually either general-purpose, or ad hoc. In both cases, application testers have to write a lot of code to model the pervasive computing environment and to dynamically visualize its state. Introducing simulated entities requires the development of tedious and boilerplate code that becomes a major part of the final software system.

In this section, we show how the DiaSpec description is used to generate a simulation support.

Simulated environment

A DiaSpec taxonomy gives information about the physical environment. Device declarations define interactions with the environment. These interaction points are used to produce a simulation support.

In a concrete environment, performing actions on a device can impact the environment data by changing values. For example, a call to methods activate and deactivate of Alarm devices modifies the noise level around their locations. The application tester chooses and parameterizes the suitable behavior to translate an action into the simulated environment state.

A simulated environment is populated with devices. From a DiaSpec taxonomy, the tester selects devices and places them on a 2D representation of the physical space.

Simulated entities

The test of an application through simulation involves simulated devices. These simulated devices have to link their sources with the simulated environment. Also, their actions must fuel the simulation engine with updated environment data. Simulated devices are built above the same programming framework as the one used to implement contexts and controllers. In doing so, contexts and controllers are able to interact with simulated devices transparently. From a device declaration, DiaSim editor provides the tester with several predefined behaviors (periodical, threshold, etc) for each source. DiaGen generates an implementation of a device bridging the gap between the programming framework and the simulated environment.

Hybrid simulation

Given a device declaration, both real and simulated implementations share the same generated programming framework. Thanks to the framework abstractions, contexts and controllers interact uniformly with devices regardless of their nature. The application tester can include real devices into a simulated environment. The incremental integration of real devices facilitates the development and testing process.

Evaluation

In this section, we present experimentations we conducted using our approach to illustrate its practical benefits. First, we introduce a pervasive computing project developed by our research group to automate an engineering school building. Second, we present an assessment of a practical course we gave to introduce pervasive computing to engineering students using DiaSpec. Finally, we briefly outline the implementation of our tool chain.

Engineering school building

The DiaSpec description presented in Figures 2 and5 is an extract from a larger project2 , whose goal is to manage a 13,500square meters building, hosting an engineering school and research groups. The project features many applications including fire man- view of the first floor of the ENSEIRB engineering school building, the simulated devices deployed (e.g., light and temperature sensors, display screens) and simulated occupants. This view also displays pop-up notifications for information sensed from the simulated environment. The right frame displays detailed information on both an occupant (e.g., name, position) selected in the left frame and its surroundings (e.g., light, temperature). The simulation renderer is interactive; it allows users to alter time, temperature and luminosity, to move occupants around. . . agement, light and air conditioning management, and access control.

This project involves 21 device classes, 13 contexts, 7 controllers, 47 type declarations and 17 action definitions. The Dia-Spec taxonomy represents 200 LOC, the architecture 130 LOC, the generated framework 7,000 LOC and manually written Java code 3,000 LOC.

The engineering school building is simulated using DiaSim 3 . Figure 12 displays part of the simulation rendering of the project. Table 1 lists the number of simulated devices involved in the fire management scenario that have been deployed. At the moment, more than 250 device instances and 300 occupants are simulated (e.g., staff, researchers, students, visitors) with various behavioral patterns. We are planning on deploying part of the project in-situ to study the benefits of the DiaSpec approach for the incremental deployment of pervasive computing applications.

Teaching

We used the DiaSpec language and related tools in a course on pervasive computing system programming. The class consisted of twenty undergraduate computer science students with no prior experience. Their assignment was to develop a meeting manager application whose role was to notify participants of approaching meetings. The notification medium and the delays before starting 3 The simulation of the engineering school building has been presented at the demonstration track of PERCOM'09. Table 1. Numbers of devices simulated in DiaSim involved in the fire situation management scenario of the ENSEIRB demonstration.

the meeting depended on the participant locations and surroundings (i.e., email, voice mail, IM, or SMS).

All student groups designed a working DiaSpec architecture for the meeting manager and most completed the assignment with an implementation. This experience demonstrated that students become fluent in using DiaSpec in a short time.

Implementation of DiaSpec and DiaSim

DiaSpec 4 is a project actively developed and maintained by the IN-RIA Phoenix research group 5 . Its compiler, DiaGen, consists of a tool chain including a parser, a verifier and code generators. The implementation of DiaGen is based on the JastAdd compiler com-piler [START_REF] Ekman | The JastAdd system -modular extensible compiler construction[END_REF]. The modifications to the JastAdd parser and compiler to handle DiaSpec amount for 2,800 LOC, and the code generators have 2,300 LOC. DiaGen was tested by sample applications and approximately 100 unit-tests. The distribution library has 10,000 LOC.

DiaSim6 , our pervasive computing simulator, uses Siafu [START_REF] Martin | A generic large scale simulator for ubiquitous computing[END_REF], an open source context simulator for the 2D rendering of DiaSpec-simulated pervasive computing applications. DiaSim amounts for 15,000 LOC (without counting Siafu). In addition to the simulation renderer (Figure 12), DiaSim comprises a visual editor (Figure 13) to set-up and configure a pervasive computing environment and pre-defined behavior patterns for simulated devices and entities (persons, etc.).

Related Work

In this section, we review existing approaches for the development of pervasive computing applications. As well, we briefly describe how our generative strategy leverages existing approaches.

Middleware. Middleware is a widely used approach to developing distributed applications. Standardized middlewares (e.g., CORBA [START_REF] Omg | The common object request broker: Architecture and specification[END_REF], DCOM [START_REF] Sessions | COM and DCOM: Microsoft's vision for distributed objects[END_REF]], and Web Services [Consortium 2004]) support the development of distributed applications via dedicated mechanisms to perform operations such as event subscription and device discovery. Existing middlewares often provide a variety of interface definition languages (IDLs), mainly to define the type signature of individual entities. These definitions are used to generate communication support, as illustrated by the RPC paradigm [Sun Microsystem 1988]. Our approach leverages this basic support by providing a high-level programming framework encompassing the architectural aspects of the pervasive computing system.

Olympus is a programming framework on top of the Gaia middleware, which is dedicated pervasive computing [START_REF] Manuel Román | A middleware infrastructure for active spaces[END_REF][START_REF] Ranganathan | Olympus: A high-level programming model for pervasive computing environments[END_REF]]. It provides high-level programming interfaces to implement active spaces. However, the framework remains general purpose and thus provides little guidance to the developer and still requires boilerplate code to be written.

Component-oriented programming languages. ComponentJ [Seco and Caires 2000], ACOEL [START_REF] Vugranam | Mixin'up components[END_REF] and ArchJava [START_REF] Aldrich | ArchJava: connecting software architecture to implementation[END_REF]] build a bridge between ADLs and programming languages by adding syntactic constructs to a mainstream programming language such as Java to model architectures. Because these approaches mix architecture declarations with application code, architecture changes can be difficult to make. In contrast, a DiaSpec specification is processed prior to component programming, allowing dedicated programming support to be generated. Of these approaches, ArchJava addresses the distributed setting by allowing users to introduce new connectors [START_REF] Aldrich | Language support for connector abstractions[END_REF]]. However, this approach imposes additional burden on the developer because it requires implementing the new connectors. In contrast, DiaGen provides complete support for built-in connectors, including mappings to various distributed systems technologies.

Architecture Description Languages. Architecture description languages model distributed and non-distributed systems to ensure different properties at compile time and at run time. Some of them also provide a generic framework on top of which developers can implement components and connectors [START_REF] Garlan | Acme: Architectural description of component-based systems[END_REF][START_REF] Allen | A Formal Approach to Software Architecture[END_REF][START_REF] Moriconi | Introduction to SADL 1.0: A language for specifying software architecture hierarchies[END_REF][START_REF] Binns | Domainspecific software architectures for guidance, navigation, and control[END_REF][START_REF] Magee | Dynamic structure in software architectures[END_REF][START_REF] Luckham | Specification and Analysis of System Architecture Using Rapide[END_REF][START_REF] Shaw | Abstractions for software architecture and tools to support them[END_REF]. DiaSpec is an ADL-inspired DSL for modeling pervasive computing systems; it relies on a tool chain for the generation of a dedicated programming framework.

Domain-specific languages. In previous work, we have developed the domain-specific coordination language Pantaxou, which includes a language layer for describing the entities relevant to an application area, and another for implementing services coordinating these entities [START_REF] Mercadal | Pantaxou: a domain-specific language for developing safe coordination services[END_REF]]. The former language layer is inspired by DiaSpec but not as dedicated to the pervasive computing domain. Furthermore, our approach brings the idea of declaring the interactions allowed between distributed components from a domain-specific language to a mainstream programming language, Java.

Conclusion and Future Work

In this paper, we have presented DiaSpec, a DSL for the development of pervasive computing systems. We have shown that the DiaSpec language facilitates the description of pervasive computing applications. We have also demonstrated that our generative programming approach covers the entire development cycle of a pervasive computing system.

The DiaSpec language eases the description of pervasive computing environments by enforcing an architectural pattern commonly used in this domain. DiaSpec provides abstractions to model (1) the process of gathering data from devices, (2) their transformation into context information relevant to making decisions, and (3) the triggering of actions to carry out decisions.

We have shown that the DiaSpec generative approach leverages existing technologies to cover the development cycle of pervasive computing systems. At design time, DiaSpec proposes high-level constructs to describe a pervasive computing system. A DiaGengenerated framework abstracts over the specific features of distributed systems technologies and proposes programming support dedicated to a taxonomy definition and architecture declarations. Moreover, DiaGen makes it possible for applications to easily integrate existing components from various technologies (e.g., Web Services, CORBA, SIP). Finally, our approach allows incremental testing and deployment by generating configuration code for the DiaSim simulation environment.

This work is being actively expanded in various directions; we briefly mention two of them. Because applications are written in Java, the developer can bypass the restrictions imposed by the generated programming framework. To complement the restrictions imposed by the Java language, we plan to annotate a generated framework to enable a model checker to ensure that the implementation is compliant to the DiaSpec specification. In the longer term, we want to widen the scope of DiaSpec by introducing nonfunctional architectural information (e.g., security and fault tolerance).

Figure 1 .

 1 Figure 1. Development cycle

Figure 2 .Figure 3 .Figure 4 .

 234 Figure 2. Extract of the ENSEIRB taxonomy in the DiaSpec syntax

Figure 5 .

 5 Figure 5. Extract of the ENSEIRB fire management application

1Figure 6 .

 6 Figure 6. The abstract class Door generated by DiaGen from the declaration of the Door device (Figure 2, lines 15 to 18)

1Figure 7 .

 7 Figure 7. A developer-supplied implementation of a Door device using the X10 protocol in Java

Figure 8 .

 8 Figure 8. A developer-supplied implementation of the SmokeDetected context in Java

Figure 9 .

 9 Figure 9. A developer-supplied implementation of the FireController in Java

  ().location(room1).accuracy(gt( minAccuracy)));

  Figure 10. Distribution generation

Figure 11 .

 11 Figure 11. Extract of the Alarm WSDL definition

Figure 12 .

 12 Figure 12. DiaSim simulation renderer for the ENSEIRB project on the automation of the engineering school. The left frame displays a 2D

Figure 13 .

 13 Figure 13. DiaSim simulated environment editor for an health care scenario. The middle frame displays a 2D view of a home environment. The devices extracted from a DiaSpec taxonomy are displayed on the left frame and can be placed via drag-and-drop operations in the simulated environment. The right frame summarizes devices deployed in the environment.

  DiaSpec descriptions are processed by a compiler, named DiaGen, that generates dedicated programming frameworks. A dedicated framework guides the development of the application code and raises the level of abstraction by providing the programmer with high-level operations for entity discovery and component interactions.

	• Retargetable compiler. DiaGen leverages existing distributed
	systems technologies. It generates glue code to customize them
	with respect to the needs of pervasive computing, without man-
	ual intervention. Currently, DiaGen offers back-ends for the fol-
	lowing targets: Web Services, RMI, SIP and CORBA.
	• Simulation generation. DiaSpec declarations are also used to
	generate simulation support. It takes the form of predefined
	behaviors for the most common existing building blocks. It also
	generates skeletons to implement the simulation logic of a new
	kind of building block. Finally, code is produced to configure
	our pervasive computing simulator, DiaSim.

• DiaGen.

https://diasim.bordeaux.inria.fr/Examples/Enseirb/

https://diaspec.bordeaux.inria.fr/

http://phoenix.labri.fr/

https://diasim.bordeaux.inria.fr/


Vincent Andrieu
email: vincent.andrieu@gmail.com

Extended-Kalman-Filter-like observers for continuous time systems with discrete time measurements

. The relationship between the Lipschitz constant and the measurement stepsize is exhibited. For second order system, we evaluate the authorized measurement stepsize.

Introduction

We consider a continuous time system of the form: ẋ = f (x, u) , x = (x 1 , . . . , x n ) [START_REF] Deza | High gain estimation for nonlinear systems[END_REF] with the state x is in R n and the input u is in U ⊆ R. The solutions of this system are denoted as 1 x(t). The state of this system is accessible via a discrete time measure

y k = Cx(t k ), (2)
where (t k ) k∈N is a sequence of positive real number defined as:

t k+1 = t k + δ
where δ is a positive real number.

The problem under consideration is an observer problem. How can we estimate the state of the system knowing only the measurements.

This problem has been addressed in [START_REF] Deza | High gain estimation for nonlinear systems[END_REF] (see also [START_REF] Hammouri | Constant gain observer for continuous-discrete time uniformly observable systems[END_REF] and the related filtering problem in [START_REF] Jazwinski | Stochastic processes and filtering theory[END_REF]).

Following what has been done for continuous time measurement in [START_REF] Gauthier | A simple observer for nonlinear systems applications to bioreactors[END_REF], we consider the case in which the system can be written (possibly after a change of coordinates) in the form:

ẋ = Ax + φ(x, u) (3)
with Ax = (x 2 , . . . , x n-1 , 0),

y k = Cx(t k ) = x 1 (t k )
and where the function φ : R n × U → R n satisfies an upper triangular globally Lipschitz condition, i.e. is such that for i in {1, . . . , n} we have:

|φ i (x + e, u) -φ i (x, u)| ≤ c L i j=1 |e j | , ∀ (x, e) ∈ R n × R n , u ∈ U , (4)
where c L is a positive real number named the Lipschitz constant of the nonlinear system.

Inspired by [START_REF] Deza | High gain estimation for nonlinear systems[END_REF] and [START_REF] Nadri | Constant gain observer for continuous-discrete time uniformly observable systems[END_REF], an estimate of the state can be given as any piecewise continuous function x : R + → R n solution of the following continuous-discrete system2 :

           ẋ = Ax + φ(x, u) Ṡ = -θS -A ′ S -SA , t ∈ [kδ, (k + 1)δ) x(t k ) = x(t - k ) -δS(t k ) -1 C ′ C x(t - k ) -y k S(t k ) = S(t - k ) + δC ′ C (5)
with θ a positive real number. Note that compared to what has been done in [START_REF] Deza | High gain estimation for nonlinear systems[END_REF], the Matrix updated law is a Lyapunov like one instead of a a Riccati like one. This one has been used in [START_REF] Nadri | Constant gain observer for continuous-discrete time uniformly observable systems[END_REF] since it allows to study analytically its limit and to give a better approximation on the bound involved in the highgain approach. Compare to [START_REF] Nadri | Constant gain observer for continuous-discrete time uniformly observable systems[END_REF] the only difference is the fact that the gain matrix depends on S which is time varying.

Main Theorem

Inspired by the result of [START_REF] Nadri | Constant gain observer for continuous-discrete time uniformly observable systems[END_REF], the following theorem can be obtain.

Theorem 1 There exists a positive real number ζ (which depends only on the dimension of the system), such that, for all δ < ζ c L there exist two positive real numbers θ 1 < θ 2 such that for any θ in [θ 1 , θ 2 ], the estimate x converges asymptotically to the state of the system [START_REF] Hammouri | Constant gain observer for continuous-discrete time uniformly observable systems[END_REF].

Proof : Let E = Θ -1 (xx) where Θ = diag{1, . . . , θ n-1 } with θ a positive real number larger then 1 to be specified. The scaled error satisfies for t in [kδ, (k + 1)δ):

Ė = Θ -1 A[x -x] + Θ -1 [φ(x, u) -φ(x, u)] ,
and since Θ -1 A = θAΘ -1 , it yields for t in [kδ, (k + 1)δ):

Ė = θAE + ∆ θ φ(x, E) , with ∆ θ φ(x, E) = Θ -1 [φ(x, u) -φ(x, u)] such that |∆ θ φ i (x, E)| ≤ c L i j=1 |E j | since θ > 1.
Moreover, the scaled error satisfies:

E(t k ) = Θ -1 x(t - k ) -δS(t k ) -1 C ′ C x(t - k ) -y k -x(t k ) = I -δ S(t k ) -1 C ′ C E(t - k ) ,
where S(•) = ΘS(•)Θ. Note that S satisfies:

S(t k ) = S(t - k ) + δC ′ C (6)
and for t in [t k , (k + 1)δ):

Ṡ = -θ S -ΘA ′ Θ -1 S -SΘ -1 AΘ , = -θ S -θA ′ S -θ SA . (7)
Note that the sequence (s k ) k∈N such that s k = θ S(t k ) satisfies

s k+1 = exp(-ρ) exp(-A ′ ρ)s k exp(-Aρ) + ρ C ′ C ,
where ρ = θδ. Which gives,

s k = exp(-kρ) exp(-A ′ kρ)s 0 exp(-Akρ) + k-1 ℓ=0 exp(-ℓρ) exp(-A ′ ℓρ)ρ C ′ C exp(-Aℓρ) ,
Following what has been done in [START_REF] Nadri | Constant gain observer for continuous-discrete time uniformly observable systems[END_REF], the following Lemma can be shown (its proof is given in Section 3).

Lemma 1 There exist two continuous function α 1 and α 2 such that for all ρ > 0, the matrix series converges to a limit denoted s ∞ (ρ), formally defined as:

s ∞ = +∞ ℓ=0 exp(-ℓρ) exp(-A ′ ℓρ)ρ C ′ C exp(-Aℓρ) , such that α 1 (ρ)I ≤ s ∞ ≤ α 2 (ρ)I , (8)
where α 1 and α 2 are two strictly positive continuous functions.

The proof is divided in three steps : Part 1: With this lemma in hand, we will first show that for all ρ > 0, there exists t 0 such that for all t > t 0 , the matrix S satisfies:

γ 1 (ρ)I < θ S(t) < γ 2 (ρ)I (9)
where γ 1 and γ 2 are two continuous positive function defined as,

γ 1 (ρ) = exp(-ρ)α 1 (ρ)c Int(ρ) 3 c 1 , γ 2 (ρ) = α 2 (ρ)c 2 c Int(ρ) 4 (10)
where Int(•) denotes the integer part of a positive real number, c 1 and c 2 are two positive real numbers and (c 3 , c 4 ) are two positive real numbers such that c 3 < 1 and c 4 > 1.

Indeed, for k in N and s in [0, δ), S(k + s) is solution of (7), hence, θ S(k + s) = exp(-θs) exp(-A ′ θs)s k exp(-Aθs) .

With Lemma , for k sufficiently large, the matrix s k is definite positive, it yields that for all

v in R n , v ′ θ S(k + s)v = exp(-θs) s 1 2 k exp(-Aθs)v 2 .
Hence, we get for all v in R n :

v ′ θ S(k + s)v ≥ exp(-ρ) λ min s 1 2 k 2 |exp(-Aθs)v| 2 Note that |exp(-Aθs)v| 2 = |exp(-Aθs)v| 2 = |exp(-AInt(θs)) exp(-A[θs -Int(θs)])v| 2 ≥ (λ min {exp(-A) ′ exp(-A)}) Int(θs) |exp(-A[θs -Int(θs)])v| 2 ≥ (λ min {exp(-A) ′ exp(-A)}) Int(θs) c 1 |v| 2
where c 1 = min r≤1 {λ min {exp(-Ar) ′ exp(-Ar)}}. Furthermore, note that Det{exp(-A) ′ exp(-A)} = 1, hence

c 3 := λ min {exp(-A) ′ exp(-A)} < 1. Consequently, |exp(-Aθs)v| 2 ≥ c Int(ρ) 3 c 1
And since, λ min s

1 2 k 2
≥ λ min {s k }, it yields for all k sufficiently large and all

v in R n v ′ θ S(k + s)v ≥ exp(-ρ)λ min {s k } c Int(ρ) 3 c 1 |v| 2
In a same way,

v ′ θ S(k + s)v ≤ λ max s 1 2 k 2 | exp(-Aθs)v| 2
and,

|exp(-Aθs)v| 2 ≤ (λ max {exp(-A) ′ exp(-A)}) Int(θs) c 2 |v| 2
where c 2 = max r≤1 λ max {exp(-Ar) ′ exp(-Ar)}. Hence we get

v ′ θ S(k + s)v ≤ λ max {s k } c 2 (λ max {exp(-A) ′ exp(-A)}) Int(θs) |v| 2
Due to the fact that

c 4 := λ max {exp(-A) ′ exp(-A)} > 1, we get v ′ θ S(k + s)v ≤ λ max {s k } c 2 c Int(ρ) 4 |v| 2
which, with Lemma 2 implies that equation (9) holds and finishes the first part of the proof. Part 2: Let now V (E) = E ′ SE. We will now show that it is strictly decreasing providing θ and ρ satisfy an inequality constraint depending on c L the Lipschitz constant of the nonlinear system. The function V satisfies along the trajectories of the system for t in [kδ, (k + 1)δ):

V (E) = E ′ θA ′ S(t) + θ S(t)A + Ṡ E + 2E ′ S∆ θ φ(x, E) (11) = -θE ′ S(t)E + 2E ′ S(t)∆ θ φ(x, E) . (12)
With Schwarz inequality, we have for all t > 0

E ′ S(t)∆ θ φ(x, E) ≤ |E| | S(t)∆ θ φ(x, E)| ≤ λ max { S(t)}|E| |∆ θ φ(x, E)| , (13)
and we have 3

3 Here we have used the inequality:

(a 1 + . . . a n ) 2 ≤ n a 2 1 + . . . + a 2 n |∆ θ φ(x, E)| 2 = n i=1 |∆ θ φ i (x, E)| 2 (14) ≤ n i=1 c 2 L i j=1 |E j | 2 ≤ nc 2 L n j=1 |E j | 2 ≤ n 2 c 2 L |E| 2
Consequently, we get:

V (E) ≤ λ max { S(t)}2nc L -θλ min { S(t)} |E| 2 . ( 15
)
Note that, due to equation ( 9), we get that if we can select θ and δ such that

θ > 2γ 2 (ρ)nc L γ 1 (ρ) (16)
with ρ = δθ we would get

λ max { S(t)}2nc L -θλ min { S(t)} < 0 ,
for all t sufficiently large. Hence we get V (E) < 0 for all t in [kδ, (k + 1)δ), with k sufficiently large. Moreover, we have

V (E)(t k ) = E(t - k ) ′ I -δ S-1 C ′ C ′ S(t k ) I -δ S-1 C ′ C E(t - k ) = E(t - k ) ′ S(t k ) -2δC ′ C + δ 2 C ′ C S(t k ) -1 C ′ C E(t - k ) = E(t - k ) ′ S(t - k ) -δC ′ C + δ 2 C ′ C S(t - k ) + δC ′ C -1 C ′ C E(t - k ) = V (E)(t - k ) -E(t - k ) ′ C ′ pCE(t - k ) where, p = δ -δ 2 C S(t - k ) + δC ′ C -1 C ′ .
Following [START_REF] Jazwinski | Stochastic processes and filtering theory[END_REF] (see also [START_REF] Deza | High gain estimation for nonlinear systems[END_REF]), note that if we note q = C S(t - k ) -1 C ′ + 1 δ , we have,

pq = δ -δ 2 C S(t - k ) -1 I + δC ′ C S(t - k ) -1 -1 C ′ C S(t - k ) -1 C ′ + 1 δ = 1
Hence, we get :

V (E)(t k ) = V (E)(t - k ) -E(t - k ) ′ C ′ q -1 CE(t - k )
with q > 0. Consequently the function V is decreasing along the trajectories of the system for t sufficiently large. Its eigenvalues being lower and upper bounded as shown in the first part of the proof, we get convergence of the estimation error to the origin. Part 3: We now show that the constraint we have on θ and ρ can be given in terms of an upper bound on δ depending on c L .

To obtain estimation, we have to find δ and θ such that ( 16) is satisfied and θ > 1. Note that ( 16) is equivalent with :

δ < ϕ(ρ) c L , with ϕ(ρ) = ργ 1 (ρ) 2nγ 2 (ρ)
where γ 1 and γ 2 are defined in (10). Hence, we get:

ϕ(ρ) = ρ exp(-ρ) α 1 (ρ) 2nα 2 (ρ) c 1 c 2 c 3 c 4 Int(ρ) (17)
Note that since α 1 (ρ) ≤ α 2 (ρ) and c 3 < 1 and c 4 > 1 we get:

lim ρ→0 ϕ(ρ) = 0 , lim ρ→+∞ ϕ(ρ) = 0 .
Hence we can define the positive real number κ as :

κ = max ρ>0 {ϕ(ρ)} ,
This function being continuous, we get that for all c L δ < κ, there exists ρ1 (δ) and ρ2 (δ) such that ϕ(ρ) > c L δ , ∀ρ ∈ (ρ 1 (δ), ρ2 (δ)) , and,

ϕ(ρ 2 (δ)) = ϕ(ρ 1 (δ)) = c L δ .
The function ϕ being definite positive, we get that lim δ→0 ρ2 (δ) = +∞. This implies that there exists 0 < c L ζ ≤ κ such that for all 0 < δ < ζ there exist ρ 1 (δ) and ρ 2 (δ) such that we have

δ < ρ 1 (δ) < ρ 2 (δ) , ϕ(ρ) > c L δ , ∀ρ ∈ [ρ 1 (δ), ρ 2 (δ)] .
Hence, this implies

ϕ(ρ) c L > δ , ∀θ ∈ [θ 1 , θ 2 ] , 1 < θ 1 < θ 2 ,
where

θ 1 = ρ 1 (δ) δ and θ 2 = ρ 2 (δ)
δ which concludes the proof.

3 Proof of Lemma 2

We want to show that the sequence

s k = k ℓ=0 exp(-ℓρ) exp(-A ′ ℓρ)ρ C ′ C exp(-Aℓρ) , k ∈ N ,
converges to a limit as k goes to infinity denoted s ∞ and such that

α 1 (ρ)I ≤ s ∞ ≤ α 2 (ρ)I . (18)
First, note that A being nilpotent, it yields 4

C exp(-Aℓρ) = n-1 j=0 C(-Aℓρ) j = r ℓρ S n ,
where S n = diag 1, . . . , 1

(n-1)! and, r ℓρ is a vector defined as :

r l = 1, (-ρℓ), . . . , (-ρℓ) n-1 .
Consequently, we get

s k = ρS n M k (ρ)S n ,
where M k is the symetric positive (at least) semi-definite matrix defined as

M k (ρ) = k ℓ=0
exp(-ℓρ)r ′ ℓρ r ℓρ .

Hence to get the result it is sufficient to work on the sequence M k since we have for all k in N where M k is definite positive:

v ′ s k v = ρ M 1 2 k (ρ)S n v 2 4 In fact we have C exp(-Aℓρ) = r ρℓ S n O
where O is the observability matrix associated to the couple (A, C), i.e.,

O =      C CA . . . CA n-1      = I .
It yields,

ρ λ min {M 1 2 k (ρ)}λ min {S n } 2 I ≤ s k ≤ ρ λ max {M 1 2 k (ρ)}λ max {S n } 2 I or, ρλ min {M k (ρ)} (λ min {S n }) 2 I ≤ s k ≤ ρλ max {M k (ρ)}λ max ({S n }) 2 I Consequently ρ (n -1)! λ min {M k (ρ)}I ≤ s k ≤ ρλ max {M k (ρ)}I
So, provided its limit exists, (18) is satisfied with:

α 1 (ρ) = ρ (n -1)! λ min {M ∞ (ρ)} , α 2 (ρ) = ρλ max {M ∞ (ρ)} (19)
where,

M ∞ (ρ) = lim k→+∞ M k (ρ)
1. We first show that the for all k sufficiently large, the matrix M k is definite positive. First note that:

M k (ρ) ≥ exp(-(n -1)ρ) n-1 ℓ=0 r ′ ℓρ r ℓρ , ∀k ≥ n .
Note that for all v in R n ,

v ′ n-1 ℓ=0 r ′ ℓρ r ℓρ v = n-1 ℓ=0 |r ℓρ v| 2 = |R(ρ)v| 2 ≥ λ min {R(ρ) ′ R(ρ)} |v| 2 ,
where R is a Vandermonde matrix5 R = (r 0 , . . . , r n-1 ) ′ . Hence, we get

M k (ρ) ≥ λ min {R(ρ) ′ R(ρ)} exp(-(n -1)ρ)I , ∀k ≥ n .
which shows that M k is definite positive for all k ≥ n.

2. We now show that M ∞ exists and is a continuous matrix function of ρ. Note that

(M k (ρ)) i,j = k ℓ=0 exp(-ℓρ)(-ℓρ) i+j-2 = (-ρ) i+j-2 ∂ i+j-2 π k ∂ρ i+j-2 (ρ) ,
where π k (φ) = k ℓ=0 exp(-ℓρ). Note that we have

π ∞ (ρ) = lim k→+∞ π k (ρ) = 1 1 -exp(-ρ) Consequently, (M ∞ (ρ)) i,j = (-ρ) i+j-2 ∂ i+j-2 π ∞ ∂ρ i+j-2 (ρ) ,
Note that this function is continuous 6 for all ρ > 0.

Numerical evaluation of ζ

In this paragraph, we try to give the value of ζ in the simple case where the dimension of the system is n = 2.

Computation of M ∞ , α 1 and α 2 : We have,

M ∞ (ρ) =     1 1 -exp(-ρ) -ρ exp(-ρ) (1 -exp(-ρ)) 2 -ρ exp(-ρ) (1 -exp(-ρ)) 2

Conclusion

In this short note, the continuous discrete observer presented in [START_REF] Nadri | Constant gain observer for continuous-discrete time uniformly observable systems[END_REF] has been studied. The maximal time between two measurement has been exhibited as a function of the Lipschitz constant. Even for small dimension, the obtained value seems to be small.

ρ 2 [

 2 exp(-ρ) + exp(-2ρ)] (1exp(-ρ))Note that when n = 2, we have,α 1 (ρ) = λ min {M ∞ (ρ)} , α 2 (ρ) = λ max {M ∞ (ρ)}Employing WolframAlpha website, we are able to give explicitly this eigenvalues as a function of ρ. Computation of c 1 , c 2 , c 3 and c 4 : We have also,exp(-A ′ r) exp(Ar) = 1 -r -r 1 + r 2 , 6 Moreover, it satisfies: lim ρ→0 [ρ(M ∞ (ρ)) i,j ] = (-1) (i+j-2) (i + j -2)! ,Hence, we have: lim ρ→0 α 1 (ρ) > 0

For a time function x(•) the notation x(t - k ) means (when it exists) lim t→t k ,t<t k x(t)

This implies that it is a full rank matrix.

consequently,

and,

Note that r → λ min {exp(-A ′ r) exp(Ar)} is a strictly decreasing function on R + and that r → λ max {exp(-A ′ r) exp(Ar)} is a strictly increasing function on R + . Consequently, we obtain

Note that with these data, the function ϕ defined in (17) can be computed threw matlab. Its maximal value is reached for

Consequently, in this case, ζ = 0.0022. Better approximation of γ 1 and γ 2 : In the particular case of n = 2 a better approximation can be given. Indeed, we have

Hence, we can take:

The function ϕ(ρ) = ργ 1 (ρ) 2nγ 2 (ρ) can be computed threw matlab. Its maximal value is reached for κ = max ρ>0 {ϕ(ρ)} = 0.0148 , ρ opt = Argmax ρ>0 {ϕ(ρ)} = 0.5313 > κ .

Consequently, in this case, ζ = 0.0148. This implies that given the Lipschitz constant of the system c L , the observer which maximizes the time between two measures can be tuned with δ = 0.0148 c L , θ = 35.9 c L .


M Nadri

H Hammouri
email: hammouri@lagep.cpe.fr

C Astorga

Continuous-discrete time observer design for state affine systems up to output injection

Keywords: Affine state systems, output injection, continuous-discrete time observer

By continuous-discrete time affine systems, we mean continuous dynamical systems with discrete-time output measurements. The observability of this class of systems depends on the system inputs and on the output sampling time. In this context, we give sufficient conditions on both output sampling time and system input, which allow to preserve the observability of the system and consequently, guarantee the convergence of the continuous-discrete time observer synthesized in this paper.

In order to validate the theoretical results, the performance of the proposed observer is illustrated through an example dealing with biomass growth and bio-synthesis reactions.

Introduction

By state affine systems up to output injection we mean systems of the form:

       ẋ = A(u, y)x + ϕ(u, y) y = Cx.
(1)

The observer synthesis for these systems is widely investigated in the literature, see for instance [? ? ? ? ]. The proposed observers are obtained by using an approach similar to that of a Kalman filter [? ]. The main difficulty lies in the characterization of inputs for which the observer exponentially converges. Indeed, although system (1) is observable in the sense that it admits an input which renders it observable (universal input, see definition below), there may exist an input which makes it unobservable. Since the convergence of the observer is only guaranteed for inputs which make system (1) "asymptotically" observable, in [? ? ? ], the authors characterized this class of inputs and gave an exponential observer. This observer synthesis concerns continuous state affine systems with continuous time output measurement.

However, in many practical situations the output measurements are discrete-time ones.

On the other hand, for single discrete output systems which are observable for any inputs, the authors in [? ] showed that a continuous-discrete time extended Kalman filter converges exponentially if the sampling time is judiciously chosen. The proposed observer is based on a canonical form of uniformly observable systems ([? ]).

Contrary to the uniformly observable systems, the observability of system (1) depends on the inputs applied to the system (in the sense that it admits an input which makes it unobservable). Now, let us consider the continuous-discrete time state affine systems up to output injection of the form:

       ẋ = A(u, y)x + ϕ(u, y) y(t k ) = Cx(t k ), (2)
Even if an input u makes system (1) observable, there may exist an increasing sequence (t k ) k≥0 , with lim t k = +∞ such that u makes system (2) unobservable (see the counter example given in subsection 2.2). This last remark implies that any observer construction necessarily depends on the input excitation and on the sampling time of the output measurements.

In this paper we give sufficient conditions on both output sampling time and system input, which allow to preserve the observability and permit to design an observer for state affine systems up to output injection with discrete output. This paper is organized as follows: In section 2, we recall some observability properties of state affine systems and we give an observer synthesis for continuous-discrete times affine systems. In section 3, we extend this observer algorithm to continuous-discrete time state affine systems up to output injection. The considered systems are assumed to be disturbed.

Finally, the performance of this observer is illustrated through a bioprocess model in order to validate the theoretical results and to demonstrate the usefulness of the proposed estimator in practical situations.

Observer design for state affine systems

Continuous time observer

Our goal here is to extend the well-known observer algorithm for continuous time state affine systems to continuous-discrete time affine systems. Therefore, we begin by recalling some properties concerning the observation of state affine systems. For more details, see [? ? ? ].

State affine systems considered in the following are described by:

       ẋ = A(u)x + b(u) y = Cx x ∈ IR n , u ∈ U ⊂ IR m , y ∈ IR p , (3)
where x(t) is the unknown state, u(t) is a known input, y(t) is a known output, A and b depend continuously on u, and C is a constant matrix.

Contrary to stationary linear systems, for nonlinear systems, the state estimation depends on the input excitations. We say that an input u defined on some interval [t 0 , t 0 + T ] makes system (3) observable on [t 0 , t 0 + T ], or u is a universal input on [t 0 , t 0 + T ], if for every initial state x 0 = x0 ; the associated outputs y(x 0 , u, t) and y(x 0 , u, t) are not identically equal on [t 0 , t 0 + T ]. Now, let φ u (t, t 0 ) be the transition matrix of system (3):

       d dt φ u (t, t 0 ) = A(u)φ u (t, t 0 ) φ(t 0 , t 0 ) = I,
where I is the (n × n) identity matrix.

For every t 1 , t 2 , t 3 , the following equality holds:

φ u (t 1 , t 2 )φ u (t 2 , t 3 ) = φ u (t 1 , t 3 ) (4) In particular, φ u (t, s) = φ -1 u (s, t).
Let us denote by:

G(u, t 0 , t 0 + T ) = t 0 +T t 0 φ T (t, t 0 )C T Cφ(t, t 0 )dt, (5)
the Grammian of observability of system (3). It is not difficult to see that G(u, t 0 , t 0 + T ) is a S.P.D. (symmetric positive definite) matrix if and only if u is a universal input on [t 0 , t 0 + T ].

In [? ? ], the authors designed an observer which exponentially converges for every input satisfying the following property:

Definition: A bounded input u : IR + -→ IR m is called a regularly persistent input if: ∃T > 0; ∃ T 0 ≥ 0; ∃α > 0; ∀t ≥ T 0 , G(u, t, t + T ) ≥ αI (6)
or equivalently, λ min (G(u, t, t + T )) ≥ α

In [? ? ], the authors stated some topological properties of the class of such inputs and showed that for every regularly persistent input, the following system:

       ẋ = A(u)x + b(u) -S -1 C T (C x -y) Ṡ = -θS -A T (u)S -SA(u) + C T C (7)
is an exponential observer for system (3):

∃θ 0 > 0; ∀θ > θ 0 ; ∀S(0) a symmetric positive definite matrix; ∀x(0) ∈ IR n , we have x(t) -x(t) 2 ≤ µe -θt x(0) -x(0) 2 ,
where µ is a positive constant.

Continuous-discrete time observer

As we have mentioned in the introduction, the time discretization of the output measurement may lead to the loss of observability. Indeed, consider the following bilinear system:

               ẋ =     0 u -u 0     x y = x 1 (t) (8)
Noting that every admissible control u : [t 0 , t 0 + T ] → IR which is not identically equal to zero, u renders system (8) observable. In particular, (8) is observable for every constant input u = 0. Now, let u 0 > 0 be any constant input, and let δ = π u 0 be any fixed sampling time constant, then u 0 makes the following continuous-discret time system:

               ẋ =     0 u -u 0     x y(k.δ) = x 1 (k.δ), k = 0, 1, 2, . . . ( 9
)
unobservable.

Indeed, the outputs of (8) are:

y(t) = x 1 (0) cos u 0 t + x 2 (0) u 0 sin u 0 t. (10) Now, let x(0) =     0 x 2 (0)     , with
x 2 (0) = 0, we obtain:

y(k.δ) = 0, ∀k ≥ 0 Thus, the different initial conditions,     0 0     and     0 x 2 (0)   
 yield the same output trajectory. Hence, the input u 0 renders system (9) unobservable although it makes (8) observable.

Consequently, in this section, we will give a sufficient condition on the sampling time which permits to preserve the observability and to extend the observer stated in subsection 1 to continuous-discrete state affine systems.

Let us consider the continuous-discrete state affine system:

       ẋ = A(u)x + b(u) y(t k ) = Cx(t k ) x ∈ R n , u ∈ U ∈ R m , y(t k ) ∈ R p (11)
where (t k ) k≥0 is an increasing sequence such that lim k→+∞ t k = +∞ and δ = sup k≥0 (t k+1 -t k ) < +∞.

Our candidate observer takes the form:

• For t ∈ [t k , t k+1 [        ẋ = A(u)x + b(u) Ṡ = -θS -A T (u)S -SA(u) (12) • For t = t k+1        S(t k+1 ) = S -(t k+1 ) + δ k C T C x(t k+1 ) = x-(t k+1 ) -ρδ k S -1 (t k+1 )C T (C x-(t k+1 ) -y(t k+1 )) (13)
where S( 0) is an arbitrary S.P.D. matrix, x(0) is also arbitrary and x-(

t k+1 ) (resp. S -(t k+1 )) is the limit of x(t) (resp. of S(t)) where t → t k+1 , t < t k+1 , δ k = t k+1 -t k , δ = sup k≥0 δ k and
ρ ≥ 1 is a fixed parameter.

Theorem 2.1: Let u be a regularly persistent input for system (11), then system (12-13) is an exponential observer for system (11). i.e. :

∃ θ > 0; ∃ δ > 0; ∀θ > θ; ∀δ ∈]0, δ]; ∀S(0) a S.P.D. matrix; ∃µ 1 > 0; ∃µ 2 > 0 such that: ∀t ≥ 0, x(t) -x(t) 2 ≤ µ 1 e -µ 2 t x(0) -x(0) 2
where x(t) is an unknown trajectory of ( 11) associated to the input u; x(t) is any trajectory of system ( 12) associated to (u, y)

The proof of this theorem requires the following proposition:

Proposition 2.1: Let u be a regularly persistent input, then ∃ θ > 0; ∃ δ > 0; ∀θ ≥ θ; ∀δ ∈ ]0, δ]; ∀S(0) a S.P.D. matrix; ∃β 1 > 0; ∃β 2 > 0 such that:

∀t ≥ 0, β 1 I ≤ S(t) ≤ β 2 I (14)
In the continuation, we proceed as follows: First we give the proof of theorem 2.1. Next, we prove proposition 2.1.

Proof: (Theorem 2.1)

Setting e(t) = x(t) -x(t), e -(t k ) = lim t→t k t<t k e(t) and S -(t k ) = lim t→t k t<t k S(t), we get:        ė(t) = A(t)e(t) for t k ≤ t < t k+1 e(t k+1 ) = e -(t k+1 ) -ρδ k S -1 (t k+1 )C T Ce -(t k+1 )
Now, consider V (t) = e(t) T S(t)e(t), and

V -(t k ) = lim t→t k t<t k V (t) • For t ∈ [t k , t k+1 [, we have: V (t) = 2e T S ė + e T Ṡe = 2e T SθA(u)e -e T (θS + A T (u)S + SA(u))e = -θV (t).
By simple integration we obtain:

V (t) = e -θ(t-t k ) V (t k ), (15)
in particular,

V -(t k+1 ) = e -θδ k V (t k ), (16)
• For t = t k+1 , the following equalities hold,

V (t k+1 ) = e T (t k+1 )S(t k+1 )e(t k+1 ) = (e -(t k+1 ) -δ k ρS -1 (t k+1 )C T Ce -(t k+1 )) T S(t k+1 )(e -(t k+1 ) -δ k ρS -1 (t k+1 )C T Ce -(t k+1 )) = V -(t k+1 ) + (δ k ρ) 2 (e -(t k+1 )) T C T CS -1 (t k+1 )C T Ce -(t k+1 ) -δ k (2ρ -1) Ce -(t k+1 ) 2 .
From proposition 2.1, we obtain:

V (t k+1 ) ≤ V -(t k+1 ) -δ k ((2ρ -1) - δ k ρ 2 C 2 β 1 ) Ce -(t k+1 ) 2 , ( 17
)
Now we choose δ such that:

δ ≤ (2ρ -1)β 1 ρ 2 C 2 , ( 18
)
¿From ( 16) we get:

V (t k+1 ) ≤ e -θδ k V (t k ). (19)
Combining ( 15) and ( 19), we deduce that

∀ t ≥ 0, V (t) ≤ e -θt V (0).
Finally, using proposition 2.1, we get:

e(t) 2 ≤ µ 1 e -θt e(0) 2
for some constant µ 1 > 0, which depends on θ, S(0).

This ends the proof of theorem 2.1.

Remark: If u is a regularly persistent input, then a sufficient condition permitting to preserve the observability and to guaranty the convergence of the proposed observer (12-13) is given by ( 18).

2

The proof of proposition 2.1 requires some technical lemmas that we well give in the following.

Let a > 0 be a fixed real number and let us consider the functional space:

E a ([a 1 , a 2 ], R l ) = {ϕ : [a 1 , a 2 ] → R l which are differentiable on [a 1 , a 2 ] satisfying sup t∈[a 1 ,a 2 ] dϕ dt (t) ≤ a} Lemma 2.1: For every ε > 0; for every sequence (t k ) 0≤k≤N ; a 1 = t 0 < t 1 < . . . < t N = a 2 , such that sup 0≤k≤N -1 (t k+1 -t k ) ≤ ε a.(a 2 -a 1 )
, we have:

∀ϕ ∈ E a ([a 1 , a 2 ], R l ), a 2 a 1 ϕ(t)dt - N -1 k=0 (t k+1 -t k )ϕ(t k ) ≤ ε
Note that the sequence (t k ) 0≤k≤N does not depend on ϕ.

Proof: It suffices to give the proof for scalar functions.

Let ε > 0 and let us consider any sequence (t k ) 0≤k≤N with a 1 = t 0 < . . . < t N = a 2 and such that sup

0≤k≤N -1 (t k+1 -t k ) ≤ ε a.(a 1 -a 2 ) . Let ϕ ∈ E a ([a 1 , a 2 ], R), we obtain: | a 2 a 1 ϕ(t)dt - N -1 k=0 (t k+1 -t k )ϕ(t k )| ≤ N -1 k=0 | t k+1 t k ϕ(t)dt -(t k+1 -t k )ϕ(t k )|
Using the mean value theorem, we get:

t k+1 t k ϕ(t)dt = (t k+1 -t k )ϕ( tk ), for tk ∈ [t k , t k+1 ], hence: | a 2 a 1 ϕ(t)dt - N -1 k=0 (t k+1 -t k )ϕ(t k )| ≤ N -1 k=0 (t k+1 -t k )|ϕ( tk ) -ϕ(t k )| ≤ a(a 2 -a 1 ) sup 0≤k≤N -1 (t k+1 -t k ) (since ϕ ∈ E a ([a 1 , a 2 ], R)) ≤ ε.

2

Lemma 2.2: Let u be a bounded input on R + and let τ > 0 be a constant, then:

∀t; ∀s, such that |t -s| < τ ; ∀M a S.P.D. matrix, we have:

λ min (M )e -λτ I ≤ φ T u (t, s)M φ u (t, s) ≤ λ max (M )e λτ I ( 20
)
where λ = 2sup Proof:

• Proof of the second inequality of (20):

We know that:

d dt [φ T u (t, s)φ u (t, s)] = φ T u (t, s)[A T (u(t)) + A(u(t))]φ u (t, s), therefore, d dt [φ T u (t, s)φ u (t, s)] ≤ λ φ T u (t, s)φ u (t, s), ( 21
)
where

λ = 2sup s≥0 A(u(s)) .
Hence,

φ T u (t, s)φ u (t, s) ≤ e λ|t-s| I, then, ∀(t, s), |t -s| ≤ τ, φ u (t, s)M φ T u (t, s) ≤ λ max (M )e λ|t-s| I (22)
• Proof of the first inequality of (20):

Using a similar argument as in ( 22), we obtain:

φ u (s, t)M -1 φ T u (s, t) ≤ λ max (M -1 )e λ|t-s| I (23) = e λ|t-s| λ min (M ) I.
Hence,

φ T u (t, s)M φ u (t, s) = [φ u (s, t)M -1 φ T u (s, t)] -1 (24)
≥ λ min (M )e -λ|t-s| I.

2

Now, let us give the proof of proposition 2.1

Proof: Proposition 2.1

From ( 12), ( 13), we obtain:

For t ∈ [t k , t k+1 [, S(t) = e -θ(t-t k ) φ T u (t k , t)S(t k )φ u (t k , t), ( 25
)
For t = t k+1 ,

S(t k+1 ) = e -θδ k φ T u (t k , t k+1 )S(t k )φ u (t k , t k+1 ) + δ k C T C, ( 26
)
where

δ k = t k+1 -t k and φ T u (t k , t) = (φ T u (t, t k )) -1 Let δ = sup k≥0 δ k < +∞.
Combining (25-26) and using lemma 2.2, the proof of inequalities ( 14) of proposition 2.1 can be reduced to the proof of the following:

∃ δ > 0; ∃ θ > 0; ∀θ ≥ θ; ∀δ ∈]0, δ]; ∃β 1 , β 2 > 0 such that, ∀k ≥ 0, β 1 I ≤ S(t k ) ≤ β 2 I ( 27
)
• Proof of the second inequality of ( 27):

From ( 25),( 26), we deduce that:

S(t k+1 ) = e -θt k+1 φ T (0, t k+1 )S(0)φ u (0, t k+1 ) (28) + k i=0 δ i e -θ(t k+1 -t i+1 ) φ T (t i+1 , t k+1 )C T Cφ(t i+1 , t k+1 )
Since u is a bounded input, from lemma 2.2, we have:

φ T u (t i , t k )M φ u (t i , t k ) ≤ M e λ(t k -t i ) I, for 0 ≤ i ≤ k, where M denotes the L 2 -norm of M .
Thus,

S(t k+1 ) ≤ e -(θ-λ)t k+1 S(0) + k i=0 δ i e -(θ-λ)(t k+1 -t i+1 ) C T C I. ( 29
)
Now, taking for θ any constant such that θ > λ, and θ ≥ θ; there exists a constant β 2 > 0 such that:

∀k ≥ 0, S(t k ) ≤ β 2 I,
• Proof of the first inequality of ( 27):

Let u be a regularly persistent input, which means that u is a bounded input satisfying:

t+T t φ T u (s, t)C T Cφ u (s, t)ds ≥ αI, ( 30
)
for every t ≥ T 0 , where T 0 , T, and α > 0 are constants. Now, for every t ≥ 0, denote by u t the mapping:

u t : [0, T ] -→ R s -→ u t (s) = u(t + s).
¿From the definition of φ u , it is easy to verify that:

∀ t ≥ 0, ∀s ∈ [0, T ] φ ut (s, 0) = φ u (s + t, t).
Hence, (30) is equivalent to:

∀ t ≥ T 0 , t+T t φ T u (s, t)C T Cφ u (s, t)ds = T 0 φ T ut (s, 0)C T Cφ ut (s, 0)ds ≥ αI (31) Set k 0 = inf{l/t l ≥ T 0 + T } and for every k ≥ k 0 , set ν(k) = sup{l/t l+1 ≤ t k+1 , t k+1 -t l+1 ≥
T } and finally, set δ = sup k≥0 δ k . We obtain:

T ≤ t k+1 -t ν(k) ≤ T + δ (32)
To prove the first inequality of ( 27), we examine the following two cases:

Case 1: k ≥ k 0
Expression (28) leads to:

S(t k+1 ) ≥ k i=ν(k) δ i e -θ(t k+1 -t i+1 ) φ T u (t i+1 , t k+1 )C T Cφ u (t i+1 , t k+1 ) ≥ k-ν(k) i=0 δi e -θ( tk+1-ν(k) -ti+1 ) φ T u t ν(k) ( ti+1 , tk+1-ν(k) )C T Cφ u t ν(k) ( ti+1 , tk+1-ν(k) )
where ti = t i+ν(k) -t ν(k) and δi = δ i+ν(k) .

Thus,

S(t k+1 ) ≥ e -θT k-ν(k) i=0 δi φ T u t ν(k) ( ti+1 , tk+1-ν(k) )C T Cφ ut ν(k) ( ti+1 , tk+1-ν(k) ) (33) = e -θT φ T u t ν(k) (0, tk+1-ν(k) )   k-ν(k) i=0 δi φ T u ν(k) ( ti+1 , 0)C T Cφ u t ν(k) ( ti+1 , 0)   φ u t ν(k) (0, tk+1-ν(k) )
From (32), we know that T ≤ tk+1-ν(k) ≤ T + δ, where δ = sup k≥0 δ k .

Now combining this last fact with (33) and using lemma 2.2, it follows:

S(t k+1 ) ≥ e -θT e -λ tk+1-ν(k) λ min   k-ν(k) i=0 δi φ T u t ν(k) ( ti+1 , 0)C T Cφ u t ν(k) ( ti+1 , 0)   ≥ e -θT e -λ(T +δ) λ min   k-ν(k) i=0 δi φ T u t ν(k) ( ti+1 , 0)C T Cφ u t ν(k) ( ti+1 , 0)   ( 34
)
where λ min stands for the smallest eigenvalue.

Consequently, to show that S(t k+1 ) ≥ βI, ∀k ≥ k 0 , for some constant β > 0, it suffices to show that:

inf k≥k 0   λ min ( k-ν(k) i=0 δi φ T ut ν(k) ( ti+1 , 0)C T Cφ u t ν(k) ( ti+1 , 0))   > 0 (35)
To prove (35), let us remark that for every k ≥ k 0 , the restriction of

φ T u t ν(k) (s, 0)C T Cφ u t ν(k) (s, 0) to [0, tk+1 ] belongs to E a ([0, tk+1 ], R n 2 ) (defined in lemma 2.1),
where a = λ C T C e λ(T +δ) .

Indeed,

d ds φ T ut ν(k) (s, 0)C T Cφ u t ν(k) (s, 0) = φ T u t ν(k) (s, 0)[A T (u t ν(k) (s))C T CC T CA(u t ν(k) (s))] φ ut ν(k) (s, 0) ,
and by lemma 2.2 we get:

sup s∈[0,t k ] d ds φ T u t ν(k) (s, 0)C T Cφ u t ν(k) (s, 0) ≤ λ C T C e λ tk+1 ≤ λ C T C e λ(T +δ) (since tk+1 ≤ T + δ).
Now, applying lemma 2.1 with ε = α 2 , and α being the constant given in (31), we get:

tk+1 0 φ T u t ν(k) (s, 0)C T Cφ ut k (s, 0)ds - N -1 i=0 (τ i+1 -τ i )φ T ut ν(k) (τ i , 0)C T Cφ ut ν(k) (τ i , 0) ≤ α 2 , for every sequence (τ i ) 0≤i≤N , 0 = τ 0 < τ 1 < . . . < τ N = tk+1 such that sup 0≤k≤N (τ i+1 -τ i ) ≤ ε a. tk+1 = αe -λ(T +δ) 2λ C T C tk+1 .
In particular, this is true for τ i = ti+1 with sup

ν(k)≤i≤k (t i+1 -t i ) ≤ αe -λ(T +δ) 2λ C T C (T + δ) . Thus for δ ≤ αe -λ(T +δ) 2λ C T C (T + δ)
and k ≥ k 0 , (35) is satisfied.

Case 2: k ≤ k 0 :

Clearly, ∀k, S(t k ) is a S.P.D. matrix, hence S(t k ) ≥ β(k)I, where β(k) > 0 is a constant.

Now, taking β k

0 = inf 0≤k≤k 0 +1
β(k) it follows:

S(t k ) ≥ β k 0 I. ( 36
)
Finally, choosing β 1 to be the smallest value of the two constants obtained from case 1 and case 2, we have:

∀k ≥ 0, S(t k ) ≥ β 1 I
This ends the proof of proposition 2.1 2

In the following section, we will give a generalization of the last result in the sense that the state coefficients can depend on the output and the model takes into account the possible presence of a perturbation.

State estimation for disturbed state affine systems up to output injection

The aim here consists in extending the continuous-discrete time estimator given above, to the class of nonlinear continuous-discrete disturbed state affine systems up to output injection taking the form:

       ẋ = A(u, y)x + b(u, y) + d(t, x) y(t k ) = Cx(t k ) x ∈ IR n , u ∈ IR m , y ∈ IR p , ( 37
)
where d(t, x) is a bounded and unknown function.

Earlier, in [? ], the authors gave an exponential observer for the following continuous-time state affine systems up to output injection:

       ẋ = A(u, y)x + b(u, y) y = Cx (38)
And they shown that if (u, y) is a regularly persistent input for the system:

       ξ = A(u, y)ξ z = C.ξ, ( 39
)
then, system (40) forms an exponential for (38) (see [? ]).

       ẋ = A(u, y)x + b(u, y) -ρS -1 C T (C x -y) Ṡ = -θS -A T (u, y)S -SA(u, y) + C T C (40)
This observer design is based on the following claim: Our proposed estimator takes the form:

Claim 1: u is universal input on [0, T ]
• For t ∈ [t k , t k+1 [        ẋ(t) = A(u(t), y(t k ))x(t) + b(u(t), y(t k )) Ṡ(t) = -θS(t) -A T (u(t), y(t k ))S(t) -S(t)A(u(t), (t k ))
(41)

• For t = t k+1        x(t k+1 ) = x-(t k+1 ) -ρδ k S -1 (t k+1 )C T (C x-(t k+1 ) -y(t k+1 )) S(t k+1 ) = S -(t k+1 ) + δ k C T C (42)
where S( 0) is a S.P.D matrix, δ k = t k+1 -t k and ρ is a constant such that ρ ≥ 1.

The convergence of the above estimator is based on the following assumptions:

(H1) There exists a class of bounded inputs denoted by u ∈ U ⊂ L ∞ (IR + , U ) and two bounded sets K 1 ⊂ K 2 of IR n such that for every U and every initial state x 0 ∈ K 1 , the trajectory x(t) of (38) associated to x 0 and u lies in K 2 .

(H2) For every u ∈ U and every initial state x 0 ∈ K 1 , the associated output y is such that (u, y) becomes a regularly persistent input of the system (39). Now, we can state the main result of this section.

Theorem 3.1: Under hypothesis (H1) and (H2), we have:

∃ θ > 0; ∃ δ > 0; ∀δ ∈]0, δ]; ∀θ ≥ θ; ∀S(0) a S.P.D. matrix; ∃γ 1 > 0; ∃γ 2 > 0; ∃γ 3 > 0 such that: ∀t ≥ 0, x(t) -x(t) ≤ γ 1 e -γ 2 t x(0) -x(0) + γ 3 where δ = sup k≥0 δ k , δ k = t k+1 -t k , x(0) ∈ K 1 and x(0) ∈ IR n .
γ 3 becomes small as soon as sup k≥0, t∈[t k ,t k+1 ] y(t) -y(t k ) and sup (x,t) d(t, x) becomes small.

In the sequel, we will denote by ỹ the function defined by ỹ(t) = y(t k ) for t k ≤ t < t k+1 , k = 0, 1 . . ..

The proof of theorem 3.1 requires the following lemma:

Lemma 3.1: Under hypothesis (H1) and ( H2), there exists a δ > 0 such that for every δ ∈]0, δ ], (u, ỹ) becomes a regularly persistent input for system (39).

Proof:

Let u ∈ U and x(0) ∈ K 1 , from (H2), we know that (u, y) is a regularly persistent input:

∃T 0 ≥ 0; ∃α > 0; ∃T > 0; ∀t ≥ T 0 , t+T t ψ T w (s, t)C T Cψ w (s, t)ds ≥ αI, (43)
where,

       d ds ψ w (s, t) = A(w(s))ψ w (s, t) ψ w (t, t) = 0
Using the notations of section 2 (see( 31)), the expression (43) can be rewritten as:

T 0 ψ T w t (s, 0)C T Cψ w t (s, 0)ds ≥ αI, ∀t ≥ t 0 (44)
Let L ∞ ([0, T ], IR N ) denotes the space of the bounded borelian functions from [0, T ] into

IR N , which is induced with the norm v ∞ = sup t∈[0,T ] v(t) . It is not difficult to see that the Grammian map: L ∞ ([0, T ], IR m+p ) -→ IR n 2 w(•) -→ T 0 ψ T w (•, 0)C T Cψ w (•, 0),
is a continuous map. Now, using the mean value theorem and the fact that x(t) ∈ K 2 , ∀t ≥ 0 (hypotheses (H1)), we get:

y t (•) -ỹt (•) L ∞ ([0,L],IR P ) ≤ δ ẏ(•) L ∞ ([0,L],IR P ) , where (δ = sup k≥0 δ k ) = δ CA(u(•), y(•))x(•) L ∞ ([0,L],IR P ) ≤ γ.δ
where γ is a constant which depends on the bounded set K 2 and u. Now, combining this last inequality with (44) and the continuity of the above Grammian map, we can find constants δ > 0 and α > 0, such that for every δ ∈]0, δ ] and every t ≥ T 0 , we have:

T 0 ψ T (u t ,ỹ t ) (s, 0)C T Cφ (ut,ỹt) (s, 0)ds ≥ α I.
Hence (u, ỹ) is a regularly persistent input for system (39) 2

Proof: Theorem 3.1

Set e(t) = x(t) -x(t) and,

∆A = A(u, ỹ) -A(u, y), ∆b = b(u, ỹ) -b(u, y),
we get:

• For t ∈ [t k , t k+1 [,        ė(t) = A(u(t), ỹ(t))e(t) + ∆Ax(t) + ∆b -d(t) Ṡ(t) = -θS(t) -A T (u(t), ỹ(t))S(t) -S(t)A(u(t), ỹ(t))
(45)

• For t = t k+1 ,        e(t k+1 ) = e -(t k+1 ) -ρδ k S -1 (t k+1 )C T Ce -(t k+1 ) S(t k+1 ) = S -(t k+1 ) + δ k C T C (46)
Now, considering the quadratic function V (t) = e(t) T S(t)e(t), we obtain: Applying proposition 2.1 we deduce that there exist two constants β 1 > 0 and β 2 > 0 only depending on δ , θ and (u, y) such that for every δ ∈]0, δ ] we have:

• For t ∈ [t k , t k+1 [, V = -θV + 2e
∀t ≥ 0, β 1 I ≤ S(t) ≤ β 2 I. ( 48
)
Combining ( 47) and ( 48),we deduce that:

V (t) ≤ -θV (t) + 2 β 2 V (t) ∆Ax(t) + ∆b -d(t) 2 ,
or equivalently,

d dt ( V (t)) ≤ - θ 2 V (t) + β 2 ∆Ax(t) + ∆b(t) -d(t) .
Thus,

for t k ≤ t < t k+1 V (t) ≤ e -θ 2 (t-t k ) V (t k ) + 2µ θ β 2 . ( 49
)
where,

µ = sup t≥0 ∆A x(t) + ∆b -d(t) (50) • For t = t k+1 ,
As in the proof of theorem 2.1 (see ( 17)), the following inequality holds :

V (t k+1 ) ≤ V -(t k+1 ) -(δ k (2ρ -1) - δ 2 k ρ 2 C 2 β 1 ) Ce -(t k+1 ) 2 .
Thus, for δ such that δ(2ρ -1) -δ 2 ρ 2 C 2 β 1 ≥ 0, (i.e. δ ≤ (2ρ -1)β 1 ρ 2 C 2 ), we obtain:

V (t k+1 ) ≤ V -(t k+1 ) = e -(t k+1 )S -(t k+1 )e -(t k+1 ) ≤ e -θδ k V (t k ) + 2µ √ β 2 θ (51)
Thus for δ ∈]0, min( (2ρ -1)β 1 (ρ 2 C 2 , δ )], the inequality (49) together with (51) implies that e(t) is attracted by a neighbourhood of the origin which depends on the constant 2µ √ β 2 θ , where µ is given by ( 50). 2

Noticing that this neighbourhood is small if µ is small. This is the case when ỹ(t) -y(t) L ∞ and the perturbation norm d(t) L ∞ are small.

Application to a biological denitrification process

In this section we present an the application of the continuous-discrete observer developed in the section above to the estimation of kinetic reactions in biological denitrification.

Model representation

This process is defined as the dissimilatory reduction, by anaerobic bacteria (Pseudomonas denitrificans (ATCC 13867)), of one or both of the ionic nitrogen oxides: nitrate and nitrite, to gaseous nitrogen products by using organic substrates. The bio-degradation takes place through two principal steps:

N O - 3 -→ N O - 2 -→ N 2
The dynamic model that we use takes into account the accumulation of nitrite and the inhibition by nitrate [? ]. It is built based on the kinetics of substrates consumption and it is given by the following system:

                       ẋ = (µ 1 + µ 2 )x -Dx ṡ1 = -y 11 µ 1 x -D(s 1 -s 1,in ) ṡ2 = (y 12 µ 1 -y 22 µ 2 )x -Ds 2 ṡ3 = -(y 13 µ 1 + y 23 µ 2 )x -D(s 3 -s 3,in ) (52)
where x, s 1 , s 2 and s 3 , represent respectively, the cell mass, the nitrate, nitrite and acetic acid concentrations. D is the dilution rate and s i,in (i = 1, 3) is the concentration of the substrate in the inlet stream. y ij are yield coefficients and are assumed to be constants.

In previous work [? ], it is shown that under some operator conditions the specific growth rates µ i (i = 1, 2) can be modeled using the well known Monod law:

               µ 1 = µ 1m s 1 s 1 + k 1 s 3 s 3 + k 3 µ 2 = µ 2m s 2 s 2 + k 2 k I s 1 + k I s 3 s 3 + k 3 (53)
where µ im (i = 1, 2) are the maximal specific growth rates for the cells grown, k i (i = 1, 2, 3) are, respectively, the nitrate and nitrite half saturation constants and k I is the nitrate inhibition constant. However, it is well-known that for complex bioprocesses, where many components and bioreactions take place, µ i (t) can have a more complex representation and identification results are sensitive to operator conditions. This explains the interest in representing µ i (t) as a state variable which needs to be estimated.

Observer for the bioreactor model

Let us use the following notations:

µ 1 = α 1 s 3 and µ 2 = α 2 s 3
In the following, we show how we can estimate α i (t) (consequently µ i ) using biomass and organic substrate concentrations as the only available discrete time measurements. To do so, we will introduce the following reduced model:

                       ẋ = (α 1 + α 2 )xs 3 -Dx ṡ3 = -(y 13 α 1 + y 23 α 2 )xs 3 -D(s 3 -s 3,in ) y(t k ) =     x s 3     . (54)
It is well known that the parameter α i (t) is not constant, it must be treated as a time varying parameter which can depend on biomass, substrates and operator conditions (see [? ? ? ? ]). Moreover, its dynamics is not well known since it is subject to many causes of disturbances and even theoretical uncertainties. Consequently, system (54) can be extended where ε i (t) are unknown and bounded functions which may depend on the states, the inputs, noise, etc.

System (55) can be rewritten as follows:

Ẋ(t) = A(y(t), u(t))X(t) + b(y(t), u(t)) + d(t) (56)

y(t k ) = CX(t k )
where

X(t) =                     x s 3 α 1 α 2 α1 α2                     A =                     0
                    b(X(t), u(t)) =                     -Dx -D(s 3 -s 3,in ) 0 0 0 0                     d(t) =     ε 1 (t) ε 2 (t)     C = 1 1 0 0 0 0
Now applying the theoretical result of section 3, an continuous-discrete observer for system (56) takes the form:

(i) a prediction step at t ∈ [t k , t k+1 [ given by:

       ˙X(t) = A(

  t≥0A(u(t)) , λ min (M ), (resp λ max (M )) stands for the smallest (resp. largest) eigenvalue of M and I is the identity matrix.

                                                     ẋ = (α 1 + α 2 )xs 3 -Dx ṡ3 = -(y 13 α 1 + y 23 α 2 )xs 3 -D(s 3 -s 3,in )

  Fig.1.

  Fig.2.

  Fig.3.

Table 1 :

 1 y(t k ), u(t)) X(t) + b(y(t k ), u(t))Yields and kinetic parameters during continuous culture.

		(57)
	Ṡ(t) = -θS(t) -A T (y(t k ), u(t))S(t) -S(t)A(y(t k ), u(t))
	(ii) a correction step at t = t k+1 given by:
	   
	  	(58)

X(t k+1 ) = X-(t k+1 ) -ρδS -1 (t k+1 )C T C X-(t k+1 ) -y(t k+1 ) S(t k+1 ) = S -(t k+1 ) + δC T C

where δ is the discrete sampling period and ρ ≥ 1 is a constant.

Simulation results

In order to illustrate the performances of estimators (57-58), we compared the corresponding results with data obtained from simulation, i.e. we simulated the process model ( 52) by considering kinetic expressions given by ( 53). The numerical values of system parameters are given in the Table 1.

We suppose that the reactor works in continuous mode, with the dilution rate D(t) varying between 0.1h -1 and 0.2h -1 as shown in Fig. 1.

The simulations were carried out under the followings initial conditions:

In order to show the effects of the initial estimation of α i , the value of αi is initialized with an error of 30 compared to the initial simulated value. The sampling period is δ = 25 min and the tuning parameter θ given in equations ( 58) can have different values. In our case, θ = 1.56 and ρ = 3 give a satisfactory estimation.

The corresponding results are presented in Fig. 2 and Fig. 3. As can be seen from these figures, the estimator converges after 3h.

Conclusion

In this paper, we gave sufficient conditions on input and sampling time which allow to construct an exponential observer for continuous-discrete time state affine systems up to the output injection. The problem of observer synthesis for these systems is related to the input excitation and the sampling time of the output measurements. We therefore gave a sufficient condition on the sampling time, which allows to preserve some observability properties: In particular, the asymptotic observability of continuous systems, which is induced by regularly persistent inputs, is preserved for continuous-discrete time systems.

The obtained result is then exploited to estimate reaction rates in the biological denitrification process. These promising results could be used in the future using experimental data and/or to create a control system based on nonlinear control laws that allows us to manipulate the variables that take part in the bioreactor.

List of Figures