Cyril Cecchinel
email: cecchine@i3s.unice.fr

Sébastien Mosser
email: mosser@i3s.unice.fr

Philippe Collet
email: collet@i3s.unice.fr

Automated Deployment of Data Collection Policies over Heterogeneous Shared Sensing Infrastructures

Keywords: sensor network, automated deployment, infrastructure reuse

whether they are published or not. The documents may come   L'archive ouverte pluridisciplinaire

I. INTRODUCTION

Physical objects interconnected through the Internet form the Internet of Things (IoT) [START_REF] Gubbi | Internet of Things (IoT): A Vision, Architectural Elements, and Future Directions[END_REF]. According to the Gartner group, by 2020, up to 26 billions of these things could be available, producing huge information flows from diverse and large-scale sensing infrastructures. Smart buildings and smart cities are typical contexts in which many new applications have to be developed by relying on these infrastructures to collect data about their environment [START_REF] Sanchez | Smartsantander: The meeting point between future internet research and experimentation and the smart cities[END_REF], [START_REF]Butler project[END_REF]. In this context, pieces of software that manage and consume such data are extremely specific and dedicated to very different and evolving purposes, e.g., transportation regulations, road traffic analysis, autonomic buildings. These application domains require their stakeholders (e.g., domain experts) to define requirements that will be implemented by software engineers. The main challenge here is the gap that naturally exists between what a software engineer knows about the sensing infrastructures and how the relevant data can be collected [START_REF] Khan | Wireless sensor network virtualization: early architecture and research perspectives[END_REF].

For now, a sensor network needs to be configured at the hardware level and programmed at a low level according to the expressed needs. This activity is extremely tedious for software engineers as they need to understand the diverse architectures of sensor networks and deal with low-level programming languages (e.g., C, nesC [START_REF] Levis | Tinyos: An operating system for sensor networks[END_REF]) to find a common ground. Moreover, sensor network platforms evolve quickly, and it is out of the scope of a given application domain to follow such evolution. Finally, as sensor networks are designed for specific domains, it is not immediate to reuse a given network and adapt it for another purpose. As a consequence, sharing already deployed infrastructure is tedious, and software evolution on top of it is almost impossible when combined with the heterogeneous nature of the devices.

Developing and deploying the data collection architectures of these systems is a challenging problem. The current state of practice and the specificities of the sensor platforms compel software engineers and sensor network experts to work jointly at a very low level of abstraction to perform these tasks. Programming abstractions hopefully exist, but are linked to specific sensor operating systems of dedicated platforms [START_REF] Dunkels | Contiki-a lightweight and flexible operating system for tiny networked sensors[END_REF], [START_REF] Levis | Tinyos: An operating system for sensor networks[END_REF]. However these abstractions do not remove the need for code to embed network specific concerns, which are heterogeneous by nature.

Toolchains for the IoT have also been proposed, but they either focus on the user-centric applications [START_REF] Patel | Enabling high-level application development for the internet of things[END_REF] or the management of the underlying platforms [START_REF] Li | Towards automated iot application deployment by a cloud-based approach[END_REF]. Consequently they are not capable of supporting the composition and deployment of several policies on a shared infrastructures.

On the contrary some other approaches really focus on modeling data collection policies. However some of them do not abstract enough the low-level elements to provide an appropriate support for software engineers interacting with domain experts [START_REF] Mainland | Flask: Staged functional programming for sensor networks[END_REF]. Others abstract too much with activity diagrams and low-level specific code must be written with no support for reuse and no handling of the diversity of sensing infrastructures [START_REF] Fuchs | Uml2 activity diagram based programming of wireless sensor networks[END_REF]. Finally, when the concerns of the different stakeholders are well separated, the expression of data collection policies is not well supported and reuse is impossible [START_REF] Tei | Model-driven-development-based stepwise software development process for wireless sensor networks[END_REF]. With the increasing number of scenarios to be implemented over various infrastructures, the development and deployment activities then become more tedious and timeconsuming.

To tackle these problems, we present in this paper a tooled approach that supports (i) the definition of data collection policies at a higher level of abstraction (for software engineers), (ii) the representation of the diverse platforms and the network topology (for sensor network experts), and (iii) the automatic composition and deployment of the policies on top of heterogeneous sensing infrastructures, following different strategies.

To achieve this envisioned approach in an operational toolchain, we identified the four following requirements (R i ) expected by the different stakeholders. R 1 . A software engineer handles only business concerns.

For now, the sensor network needs to be configured at the hardware level. Thus, software engineers need to understand the underlying infrastructure and use lowlevel programming languages. It is the responsibility of sensor network experts to abstract the complexity of such infrastructures. Such an abstraction also enables a software engineer to reuse her policy across different sensing infrastructures as her code is no more coupled with a specific sensor network. R 2 . A data collection policy must be automatically adapted to the different platforms specificities. The large number of available platforms has led to a large software and hardware diversity making each deployment specific to a single infrastructure. The state of the art already provides some abstractions but they need to be supported by the different platforms and remain dependent on the underlying infrastructure. To assist software engineers in the exploitation of a sensing infrastructure, a data collection policy should be automatically adapted to the specificities of the platforms. R 3 . A data collection policy must be automatically projected over a sensing infrastructure. With regard to the separation of concerns principles [START_REF] Hürsch | Separation of concerns[END_REF], a data collection policy must not be coupled with a sensing infrastructure. Large scale sensing infrastructures make available a multitude of platforms distributed in complex network topologies. A software engineer should not have to deal with this complexity, every concept of the data collection policy should be directly assigned to a sub-set of platforms. Every concept would then, according to a deployment strategy defined by a sensor network expert, be projected and instantiated on a single platform. R 4 . An infrastructure must be automatically shared between different applications. Considering the important investment required by the installation of a sensor network 1 , reusing the infrastructure for multiple applications is necessary. At the time of the deployment of a new policy, several other policies can be already executed on the sensing infrastructure. Because of the separation of the software and network points of view, a software engineer cannot know a priori the other policies she needs to compose. Thus, automated deployment mechanisms should also provide automated composition capabilities.

II. WALKTHROUGH

To demonstrate the need of an automated approach, we introduce here a running example2 inspired from a realistic deployment [START_REF] Cecchinel | An Architecture to Support the Collection of Big Data in the Internet of Things[END_REF]. We consider a software engineer who is in charge of programming an existing sensing infrastructure to implement several policies gathered from domain experts. The example focuses on a first policy that aims at monitoring energy losses in an office, i.e., receiving an alert each time both the door and the window of an office are opened while the air conditioning is powered on. This scenario will be deployed on a sensing infrastructure that is currently executed on an academic campus where offices are equipped with door and window opening sensors, and air conditioning sensors. To simplify the exploitation of sensing infrastructure by software engineer, we advocate that the definition and the deployment of a data collection policy should respect the principles of separation of concerns, i.e., a software engineer only focuses on the application logic while a sensor network expert provide the network logic (cf. requirement R 1 ). In this section, we propose to discuss each step of what would be an appropriate automated toolchain for programming sensing infrastructures while meeting the other three requirements identified in the introduction.

A. Toolchain Overview

As inputs, the toolchain consumes a data collection policy (provided by the software engineer) and a description of the network (provided by the sensor network expert). As output, it provides ready-to-flash code for each platform involved in the realization of the data collection policy.

The data gathering on a sensor network is configured using data collection policies, i.e., sets of operations performed on data to convert them into knowledge [START_REF] Gubbi | Internet of things (iot): A vision, architectural elements, and future directions[END_REF]. As discussed in the introduction, sensing infrastructures are configured at the hardware level using low-level programming languages. This activity is tedious for software engineers as they need to understand the architecture of the network and deal with low-level programming languages [START_REF] Dunkels | Contiki-a lightweight and flexible operating system for tiny networked sensors[END_REF], [START_REF] Levis | Tinyos: An operating system for sensor networks[END_REF]. Other proposed abstractions are also not meeting all identified requirements at the same time [START_REF] Patel | Enabling high-level application development for the internet of things[END_REF], [START_REF] Tei | Model-driven-development-based stepwise software development process for wireless sensor networks[END_REF]. Besides the paradigm of wireless sensor network virtualization seems promising to abstract the complexity of the architecture but the state of the art does not provide a software engineer-oriented language [START_REF] Khan | Wireless sensor network virtualization: early architecture and research perspectives[END_REF].

To meet R 1 , we propose that the software engineer relies on a Domain-Specific Language (DSL) to express her data collection policies over a sensing infrastructure. The software engineer expresses (i) properties of the data collection policy (e.g., name, data-type), (ii) business operations and (iii) data flows between business operations. A graphical representation of this data collection policy for a given office (office 443 in the example) is presented on the left of FIG. 1.

Traditional deployment of such data collection policies is performed by considering (i) the facilities of each platform, (ii) the network topology and (iii) a deployment strategy.

Description of platform facilities. Any platform in a sensor network is built around five main components [START_REF] Karl | Protocols and Architectures for Wireless Sensor Networks[END_REF]: Controller, Memory, Sensors, Communication and Power supply. A data collection policy must be implemented according to these components. Because of the large number of manufacturers available on the market, each of those components can differ from a platform to an other, introducing a multiple variability problem.

The Software Product Line (SPL) paradigm allows one to manage this variability [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF], especially by describing the elements of a family of systems in terms of features [START_REF] Apel | An overview of feature-oriented software development[END_REF], [START_REF] Apel | Feature-oriented software product lines: concepts and implementation[END_REF]. , [START_REF] Paulon | Wireless sensor network uml profile to support model-driven development[END_REF]. We thus capture the variability of the platforms through variability models, using the support of feature models [START_REF] Kang | Feature-Oriented Domain Analysis (FODA)[END_REF] and associated automated analysis on these descriptions [START_REF] Benavides | Automated analysis of feature models 20 years later: a literature review[END_REF]. Figure 2 illustrates the individual configuration from a feature model of each component of a platform. Network topology. The data collection policy must now be deployed over the sensing infrastructure. To automate this task, the toolchain relies on a model describing the network topology. The network topology is assimilated to a graph where vertices represent platforms and edges represent a connectivity between two platforms [START_REF] Schmid | Modeling sensor networks[END_REF]. In our approach, we reuse the concept of directed graphs to model the sensing infrastructure.

Deployment strategy. A sensor network expert can tune the deployment strategy to optimize the data collection policy distribution over the underlying infrastructure. In the toolchain, we define two kinds of deployment strategies: (i) static strategies (S) and (ii) dynamic strategies (D). We define a static strategy as a strategy placing the concepts according to a static representation of the network (e.g., Closest to the sensors strategy). Dynamic strategies deploy the data collection policy according to the current state of the sensing infrastructure (e.g., use in priority free platforms strategy). While the toolchain provides the building blocks to encode different kinds of strategies, we have highlighted several deployment strategies corresponding to some relevant operating scenarios:

• Closest to sensors (S). Data collection policy's concepts are distributed as close as possible to sensors. This strategy allows one to maximize the use of computational resources offered by the sensing infrastructure. • Use in priority mains power supplied platforms (S).

The energy-consumption in sensing infrastructure is a major concern for sensor network expert [START_REF] Ye | An energy-efficient mac protocol for wireless sensor networks[END_REF], [START_REF] Raghunathan | Energyaware wireless microsensor networks[END_REF]. This strategy maximizes the use of mains power supplied platforms in a network composed by both battery and mains powered elements.

• Use in priority free platforms (D). This strategy focuses on the deployment on platforms that have not been already involved in a previous deployment. As an example, figure FIG. 1 illustrates the deployment of a data collection policy using the closest to sensors strategy.

B. Handling Multiple Applications

When reusing a sensing infrastructure, a software engineer may not have the knowledge of previously deployed applications as they might have been defined and deployed by others. A classical way to tackle this issue is to rely on isolation where nodes can execute at same time different applications, as it is achieved in the virtual machine isolation requirement for cloud computing.

Despite the need for infrastructures handling multiple applications simultaneously [START_REF] Khan | Wireless sensor network virtualization: early architecture and research perspectives[END_REF], nodes deployed in sensing infrastructures are most of the time resource-constrained devices and do not support multi-threading operations. To tame the complexity of sharing a sensing infrastructure (requirement R 4 ), the toolchain is able to compose new policies with previously deployed ones in a transparent manner for the software engineers. In our toolchain, a third-party service in charge of deploying policies on top of a given infrastructure, providing a composition mechanism (cf. SEC. III for more details).

III. TOOLCHAIN INTERNALS

A. Separation of Concerns

The toolchain leverages the separation of concerns principle by regrouping software engineers's concerns in a data collection policy and the sensor network experts's concerns in an infrastructure model. a) Data collection policy: As stated in SEC. II, the DSL must only focus on business concerns. In order to meet R 1 , we advocate that workflows are a suitable abstraction as they provide a convenient way to define "a sequence of activities performed in a business that produces a result of observable value to an individual actor of the business" [START_REF] Kruchten | The rational unified an introduction[END_REF]. A policy is then expressed by the software engineer by refining activities as her own concepts, and dependencies as a data flow between these concepts.

A data collection policy d relies on concepts c ∈ C = concepts(d), clustered as sensors (e.g., an electronic device transforming a physical quantity into a measurement, s ∈ S = sensors(d)), collectors (e.g., remote Web service where processed data are sent for storage, l ∈ L = collectors(d)) and operations (o ∈ O = operations(d)). Operations refer to the domain expert's business concerns. A special kind of operation, Process, leverages the hierarchical workflow mechanism and allows software engineer to encapsulate a data collection policy into another, so to ease reuse. A data flow f (c a , c b ) ∈ F = f lows(d) models the flows between a source concept c a and a destination concept c b . We then define a data collection policy as follows:

d = (name, concepts, f lows) ∈ (Symbol × C × F ) b)
Infrastructure model: The infrastructure model needs to describe the features available on each platform, the network topology, and the heuristics to be used to implement deployment strategies.

Platform features description model. We reuse the work of Urli et al. [START_REF] Urli | Handling complex configurations in software product lines: a tooled approach[END_REF] associated with its graphical user interface 3 to capture complex configurations of platforms. The feature description model F D allows a sensor network expert to describe the specificities of a platform P and its connected sensors S (e.g., FIG. 2) while providing a dynamic connection between them. This allows for a more flexible description, which also enables platforms to be changed more easily.

Network topology model. The network topology model I allows a sensor network expert to describe the relationships between platforms P ⊂ F . With this model is provided the accessible operator that returns the subset of sensors S that can be reached from a platform, i.e., accessible : P → S. On FIG. 1, accessible(ConnectedF aculty) returns all the sensors declared in the sensing infrastructure and the function accessible(BRIDGE 1) returns all the sensors excepting those connected to platform ARD 1 444.

Deployment strategy. A deployment strategy implements a place operator that has been defined by the sensor network expert or reused from the provided deployment strategy presented in SEC. II. This operator maps a concept c ∈ C to a platform p ∈ P ⊂ P described in a topology model I. It is defined as follows:

place : C × P + × I → P

B. Decomposition Operator

The decomposition operator (cf. on FIG. 3) is responsible for decomposing and deploying a data collection policy on a sensing infrastructure. This operator relies on the Predeployment process and the deploy operator, both presented below.

1) Pre-deployment process: a) Problem: Each concept involved in a data collection policy relies on data that come from one or different sensors and might only be deployed on a special kind of platform, e.g., a collector concept requires a platform that is connected to the Internet. Therefore, before deploying the data collection policy over a sensing infrastructure, there is a need to identify the potential targets for each concept. This task can be assimilated to workflow enactment on computational grids [START_REF] Deelman | Mapping abstract complex workflows onto grid environments[END_REF].

b) Contribution: We define several operators that operate at the data collection policy level or at the infrastructure model level.

We introduce the req operator working at the data collection policy d level: for a concept c ∈ concepts(d), the req operator returns the subset of sensors S ⊂ sensors(d) needed for the 2) Deployment operator: a) Problem: The pre-deployment process has identified several platforms for each concept. The sensor network expert needs to place concepts on candidates according to the deployment strategy that has been defined for the sensing infrastructure.

b) Contribution: The deploy operator associates each concept with a platform and builds sub-policies for each platform involved in the realization of the data collection policy, such as deploy : D × I → D * . The deploy operator is defined as follows: given a pre-deployed data collection policy d pre over an infrastructure described by the model i and a deployment strategy s, the deploy operator associates with each concept c ∈ concepts(d pre ) a property target that contains the result of the deployment strategy's place operator, i.e., c.target = s.place(c, c.targets, i). Then, for each platform involved in the realization of the data collection policy, i.e., P inv = ∀c∈concepts(dpre) c.target, a platformspecific sub-data collection policy containing all the concepts that are going to be deployed on the platform (with their respective data-flow) is built. If the place operator returns ∅ the deployment is aborted and an alert is sent to the software engineer that the concept c cannot be deployed with respect to the strategy s.

c) Example: On FIG. 1, the data collection policy is projected on the sensing infrastructure with a Closest to the sensors strategy. The deployment operator calls the deployment strategy's place operator to find the platform (among the platforms identified as a result of the pre-deploy process) that matches the strategy.

C. Sharing Service

To enable sharing sensing infrastructures, the toolchain provides a composition operator linked to a proxy acting as a sharing service (cf. on FIG. 3). The sharing service maintains for each platform of the sensing infrastructure a set of sub-policies corresponding to those that are currently running on the platform.

When a new sub-policy is going to be deployed on a platform p, the sharing service maps each platform of the sensing infrastructure to a set of policies currently running on a platform. When a new platform-specific sub-policy need to be deployed on a platform p, the sharing service handles the composition of the new sub-policy with the previous deployed ones producing a global sub-policy.

D. Code Generation

The generation process (cf. on FIG. 3) calls code generators to transform each platform-specific global sub-policy into executable code. One of the main issues to tackle here is to handle the variability existing between the different elements that compose a platform. The appropriate code generator γ for a platform p is selected according to the Programming language Platform Feature Description Model associated to p. The code generator γ has the responsibility to determine the order of generation of each concept and to use the right libraries. To determine the order of generation, γ builds a list Π of constraints between concepts: ∀f ∈ f lows(d) ⇒ f.source < f.destination = Π

The constraints Π are then solved by a third-party constraint solver (in our case, CHOCO) giving the order of concepts generation. The execution of generation produces executable code for each concept and associate the adequate libraries to sensors and communication functions according the features described in the Platform Features Description Model. It must to be noted that platforms not involved in the realization of the data collection policy are flashed with a relay policy forwarding data inside the sensing infrastructure.

IV. EXPERIMENTS

The toolchain prototype named DEPOSIT 4 is available on Github. To evaluate the performance of the toolchain, we have designed and deployed several data collection policies on a simulated sensing infrastructure. The experiments were conducted on a mid-range laptop: 2.5 GHz Intel i7 (quad-core) 16 GB RAM. In the following, we consider 15 minutes as the reference time required by a sensor network expert to write in a low-level programming language the code implementing the example data collection policy for a single office without using any aspect of the toolchain.

We first validate the requirements presented in SEC. I by deploying a data collection policy at the scale of a building. Then, we scale up to a campus infrastructure.

A. Deploying a Smart Building Data Collection Policy

Defining a data collection policy: In this experiment, a software engineer is aiming to define the data collection policy presented in SEC. II. Each office is equipped with two hall-effect sensors (used to monitor the door and window positioning and two temperature sensors (used to monitor the ambient temperature and the air conditioning status). To simplify the definition of the data collection policy, the software engineer writes a template data collection policy that will be instantiated for each office. As a matter of practicality, the DEPOSIT source codes are presented on the companion web page. To validate our first requirement (R 1 ) "a software engineer handles only business concerns", we consider that two constraints must be met: a policy can be designed by only using business concepts (C 1 ) and a policy can be deployed without a priori knowledge (C 2 ). As the software engineer handles only high-level concepts to express her needs, C 1 is obtained by design. The reuse of the infrastructure model defined by a sensor network expert abstracts the underlying infrastructure encapsulates the underlying complexity of the sensing infrastructure. This separation of concerns validates C 2 , and therefore requirement R 1 is met.

Deploying the data collection policy: The software engineer reuses the office template to deploy a comprehensive data collection policy at the scale of 50 offices. As the sensing infrastructure is heterogeneous and multi-staged, the data collection policy must adapt to the specificities of the infrastructure (R 2 ) before being automatically projected (R 3 ).

To validate R 2 , we consider that we need to satisfy that the code resulting from the generation should call the right libraries (C 3 ). Using SPL techniques, the code generation of concepts uses the complex configuration of platforms described in the infrastructure model and maps each feature to a specific library. As an example, the generation of the code reading and sending the temperature on the platform described on FIG. 2 uses the Wiring code generator. The calls to the temperature sensor use the GroveTemperature.h library. Finally, the sending of the value is performed by using the ZigBee library. This validates (C 3 ) and thus R 2 .

To validate R 3 , we consider that each concept must be projected automatically on the sensing infrastructure (C 4 ) and that the code generation process must provide ready-to-flash code for each platform required by the data collection policy (C 5 ). The deployment strategies defined by the sensor network expert determines the location of each concept. Then, code generators produce the source code for each platform. At small scale, we have deployed the source code generated from the approach on real hardware to ensure their functional validity. Then, we have scaled up to a larger deployment by simulating a smart building of 50 offices. As shown in TAB. I, DEPOSIT has generated a source code file for each platform involved in the realization of the global policy satisfying both C 4 and C 5 . This finally validates our third requirement R 3 .

B. Deploying Smart Campus Scenarios on a Shared Sensing Infrastructure

To validate our last requirement R 4 , we simulate a smart campus infrastructure (based on a realistic sensor network deployment described as a reference architecture [START_REF] Cecchinel | An Architecture to Support the Collection of Big Data in the Internet of Things[END_REF]) on which we deploy three data collection policies: P 1 Air conditioning warning. This data collection policy raises an alert when door and window are opened while the air conditioning is powered on (cf. SEC. II). P 2 Fahrenheit converter. The deployed temperature sensors return values in degrees Celsius. This policy allows the conversion to be done within the sensing infrastructure and a remote application to collect values in degrees Fahrenheit. P 3 Monitor parking spaces occupancy. This policy allows a remote application to know which parking spaces are available or occupied. Our experimental setup is a blank sensing infrastructure (i.e., no deployed data collections) deployed at the scale of 100 offices (each with 3 sensors) and 250 parking spaces (each with 1 sensor). To ensure data routing within the sensing infrastructure, we introduce 8 relay platforms and 1 borderrouter (bridging the sensor network to the Internet). A sharing service, as presented in SEC. III, handles the deployment of the data collection policies.

As the network is blank, the deployment of P 1 does not trigger any composition with other policies. However, as expected, the deployment of P 2 triggers 101 compositions. Indeed, as both P 1 and P 2 exploit the same platforms located in offices and the same border-router, the sharing service needs to compose each sub-policy deployed on these platforms with the new ones. Finally, the deployment of P 3 triggers only a single composition on the border-router, as this policy only involves the parking sensors (that have not been yet exploited), and the border-router (that hosts the product of the composition of a sub-policy of P 1 and a sub-policy of P 2 ). This experiment shows that the sharing service handles the deployment of multiple applications successfully, validating our last requirement R 4 .

C. Threats to Validity

Testing infrastructure: Our approach has been validated both at small scale (∼ 10 platforms) on real hardware (Arduino and Raspberry based platforms) and at large scale on a simulated infrastructure allowing us to vary parameters such as the number of sensors and platforms and the configuration of each. In order to be closest to the existing infrastructures, we have simulated the SmartCampus [START_REF] Cecchinel | An Architecture to Support the Collection of Big Data in the Internet of Things[END_REF] infrastructure for office platforms and the SmartSantander5 infrastructure for parking platforms. As part of future work, we plan to exploit a real large scale sensing infrastructure and study how the toolchain satisfy the needs of software engineers.

Deployment of new policies: The proposed toolchain handles the composition of data collection policies and code generation. The software engineer and sensor network expert obtain as a result a set of ready-to-flash source files. However, we do not perform a dynamic deployment over all sensing infrastructures as some platforms need to be re-flashed with a new firmware.

Prototype: The toolchain implementation is only a prototype, but it is publicly available and is verified by a large set of unit and integration tests. Still the presented results could have been disrupted by some bugs, but we believe they are close enough from what was expected to consider remaining bugs as not detrimental to results.

V. RELATED WORK

Related case studies: During the development of our toolchain, we have studied recent European projects to reuse their scenarios [START_REF] Sanchez | Smartsantander: The meeting point between future internet research and experimentation and the smart cities[END_REF], [START_REF]Butler project[END_REF]. All the described scenarios bring a need for data collection policies to build new innovative services on top of sensing infrastructures. However, the deployed platforms are flashed with ad-hoc code making them domain-specific and tailored for a particular application [START_REF] Khan | Wireless sensor network virtualization: early architecture and research perspectives[END_REF]. Our toolchain addresses this issue by allowing the sharing of the infrastructure between different applications and by producing code resulting from the composition of the deployed applications.

Modeling of data collection policies: In the process of developing applications for wireless sensor networks, Tei et al. [START_REF] Tei | Model-driven-development-based stepwise software development process for wireless sensor networks[END_REF] propose a "stepwise software developement process for average developers". They identify two types of concerns: network related concerns and data-processing concerns. In order to assist software engineers, they provide a support to reuse network related solutions designed by sensor network experts. However, they do not provide a framework that allows the reuse of an infrastructure as we do with our toolchain.

Low-level data collection support: Most of the time the handling of the hardware heterogeneity in the IoT is performed by using embedded operating systems such as Contiki [START_REF] Dunkels | Contiki-a lightweight and flexible operating system for tiny networked sensors[END_REF] or TinyOS [START_REF] Levis | Tinyos: An operating system for sensor networks[END_REF]. They bring to the developer a hardware abstraction that make a program reusable over different platforms supporting the same OS. If the programming language supported by these OSes encapsulates the specificities of platforms into programming primitives, it remains oriented for sensor network experts as the developer still needs to manually address memory and energy concerns, as well as network communications. This last point also presupposes a deep knowledge of the network infrastructure.

Development toolchains for the IoT: The multi-stage model-driven approach for IoT application development proposed by Patel et al. [START_REF] Patel | Enabling high-level application development for the internet of things[END_REF] focuses on a clear identification and separation of the different stakeholders involved in the development process: domain experts, application designer, application developer, network manager and device developer. Each of them provides an input specification according to their expertise field. Several operators then manipulate these inputs to produce the application. Users in our approach are similar as we can assimilate application designers and application developers as software engineers and network managers and device developers as sensor network experts. However, we differ in the resulting application. They focus on building user-centric application with sensors and actuators whereas we only concentrate on the definition and the deployment of data collection policies for third party applications. More importantly, they do not support the sharing of the sensing infrastructure between several applications.

Generating embedded software: Portocarrero et al [START_REF] Portocarrero | Samson: Self-adaptive middleware for wireless sensor networks[END_REF] introduce a process that manages wireless sensor networks in an automatic way according to context changes, application requirements and adaptation policies. Their approach is interesting as they involve Software architects, Domain experts, WSN experts and WSN developers in the process. They make the assumption that software architects (...) often do not have the knowledge about programming, especially on coding for WSN platforms. To allow software architects to develop for WSN platforms, they introduce model transformations to map an "architecture instance into platform-specific code". If the approach seems similar to ours, they only focus on Contikibased platform while we provide a platform-independent toolchain that exploits variability models for its code generator to adapt to potentially any kind of platform currently available.

Automated toolchains: The approach proposed by Di Cosmo et al. [START_REF] Cosmo | Automated synthesis and deployment of cloud applications[END_REF] relies on a toolchain enabling the development of complex distributed applications with a high level of abstraction. Their toolchain respects the separation of concerns paradigm by taking several inputs: a high-level specification of their application (similar as our data collection policies), a description of the system (similar as our infrastructure model) and a description of the current system. We differ on this last point by providing a sharing service that abstracts the current state of the sensing infrastructure for a software engineer. The deployment phase of their toolchain assumes that all their targeted VMs are empty. In our approach, we support addition of new policies and we ensure that a new data collection policy is composed with the previous deployed ones.

VI. CONCLUSION

In this paper, we have presented a toolchain that allows software engineer to express and deploy data collection policies over heterogeneous shared sensing infrastructure. The toolchain relies on the separation of concerns principle where software engineers only deal with business concerns and sensor network experts provide reusable infrastructure models. Data collection policies expressed by the software engineers are decomposed on the sensing infrastructures and composed with the previous deployed ones. This supports the sharing of infrastructures and enables reuse of data collection policies. The code generation resulting from the decomposition is tailored to the different platforms according to the infrastructure model expressed by a sensor network expert, thus taming the diversity and heterogeneity of sensing infrastructures.

We have successfully modeled and deployed data collection policies on simulated but realistic sensing infrastructures and showed that the sharing operations are performed automatically. Future work will first aim at collaborating with an industrial partner to assess the benefits of our approach on large scale sensing infrastructures. We also plan to work with software engineers in order to get feedback about the definition of data collection policies. We finally plan to introduce a new layer of abstraction that would allow domain experts to interact directly with the toolchain.

Fig. 1 .Fig. 2 .

 12 Fig. 1. Projection of a data collection policy on the CONNECTEDFACULITY topology

Fig. 3 .

 3 Fig. 3. Toolchain architecture overview

TABLE I DEPLOYMENT

 I OF THE RUNNING EXAMPLE (COMPREHENSIVE POLICY: 50 OFFICES)

		DEPOSIT # Generated # Generated # Concepts (before # Concepts (after Deployment time
		source	files	LoC	expansion)	expansion)	(in s)
	Template	19	N/A	N/A	N/A	N/A	N/A
	Single office	19	3	267	5	8	2.5
	Comprehensive policy (without composition)	455	105	11685	250	400	50
	Comprehensive policy (with composition)	19 + 1	105	11685	250	400	52

e.g.,[START_REF] Karl | Protocols and Architectures for Wireless Sensor Networks[END_REF] Me have been invested for the Smart Parking infrastructure in the city of Nice, France (http://enstotoday.com/parking-worth-paying-for/).

More details can be found on a companion web page: https://github.com/ace-design/DEPOSIT/blob/master/publications/apsec16.md

Data collEction POlicies for Sensing InfrasTructureshttps://github.com/ace-design/DEPOSIT

http://www.libelium.com/smart santander smart parking/

Code (Platform 1) Code (Platform 2) Code (Platform n) Generation … with with with


Pierre Thuéry

Jack Harrowfield

Tetrahydrofurantetracarboxylic Acid: an Isomerizable Framework-Forming Ligand in Homo-and Heterometallic Complexes with UO2 2+ , Ag + and Pb 2+

2R*,3R*,4S*,5S*)-Tetrahydrofurantetracarboxylic acid (H4thftc) has been used as a ligand to synthesize five uranyl ion complexes, three of them including additional silver(I) or lead(II) metal cations. The complex [C(NH2)3]2[UO2(H2thftc)2] (1), obtained in water at room temperature, is a discrete mononuclear species in which the uranyl cation is bound to the tridentate coordination site (involving the ether oxygen atom and the two adjoining carboxylate groups) of two ligands, and extensive hydrogen bonding is present. All the other complexes were obtained under (solvo)-hydrothermal conditions giving rise to higher degrees of ligand deprotonation.

) and [Pb2(thftc)(H2O)] (7), devoid of uranyl cations, are both 3D frameworks in which the ligand is bound to 11 or 9 metal cations, respectively. Complex 6 is the single instance in this series in which the ligand, originally in the trans,cis,trans form, has undergone isomerization into the chiral cis,trans,trans (2R*,3S*,4S*,5S*) form through a process probably involving an ene-diol intermediate. Only complexes 1, 2 and 4 display intense and well-resolved emission bands under excitation at 420 nm in the solid state, the uranyl emission of complexes 3 and 5 being largely quenched.

INTRODUCTION

An appealing ligand with a somewhat flexible conformation and four possible degrees of deprotonation, tetrahydrofurantetracarboxylic acid (H4thftc) has not been widely used till now, and virtually all the crystal structures reported for its salts or complexes contain alkali, alkaline-earth, 1,2 or d-block metal cations. [3][4][5][6][7][8][9][10][11][12][13] In the f-element series, the complexation of lanthanide ions by H4thftc was investigated in solution, 14,15 and the complexes formed were shown to be stronger than those with uranyl ion; 15 the weak complexation of the latter cation compared with that of transuranic elements was put to use in a solvent extraction process for nuclear waste reprocessing. 16 However, no crystal structure of a lanthanide or transuranic cation complex with H4thftc has ever been reported, and, apart from the complexes of the cations cited above, the only crystallographically characterized species are three uranyl ion complexes. 17,18 In the overwhelming majority of the known structures containing H4thftc or its anions, either free or complexed, the molecule retains the achiral trans,cis,trans (2R*,3R*,4S*,5S*) isomeric form of the single species shown to be present in the commercially available acid. 14 In principle, six diastereomeric forms are possible and in some early publications 3,19 evidence for the presence of more than one has been noted. More significantly, in a recent study of zinc(II) complexes, mainly mixed-ligand species, obtained by solvothermal syntheses, clear evidence was obtained for the isomerization of the achiral acid to the chiral (2R*,3S*,4S*,5S*) form, isolated in good yield in several complexes. 8 An acid-dependent inversion process, relatively rapid at the temperature of solvothermal methods and involving an ene-diol intermediate, was suggested to be the cause of this isomerization and such a mechanism could also explain the observation of related isomerization processes in other alicyclic polycarboxylic acids used to prepare metal ion complexes by solvothermal methods. [20][21][22][23][24][25] Thus, under acidic solvothermal conditions, H4thftc can be regarded as being in a dynamic equilibrium involving possibly up to 6 diastereomeric species and thus can be considered as a single-molecule dynamic covalent library, 26 open potentially to selective coordination and amplification of a given isomer depending upon the metal and, as shown in the case of crystalline Zn II complexes, 8 any co-ligands. The present work provides one further example of this selective coordination within a precipitated solid, this resulting from our continuing efforts to characterise the influence of the presence of other heavy metal ions on the structure of uranyl ion/polycarboxylate coordination polymers.

Of the known uranyl ion complexes of H4thftc, which all contain the (2R*,3R*,4S*,5S*) isomer,

[Hpip]6[UO2(thftc)]3•9H2O (where pip is N-ethylpiperidine) and

[HNEt3]8[UO2(thftc)]4•2MeOH•2H2O were synthesized in organic solvents (methanol or dimethylsulfoxide) at room temperature, in the presence of an organic base; 17 both are metallamacrocycles, with three and four metal centres, respectively, in which one uranyl ion is chelated by the two carboxylate groups in the positions 2 and 5 and is also bound to the ether oxygen donor in between (a tridentate coordination site analogous to that of oxydiacetate), and another one is chelated by the carboxylate groups in the positions 3 and 4 (analogous to succinate).

Under mild conditions, isomerization of the ligand would not be anticipated but the (2R*,3R*,4S*,5S*) configuration is also found in the heterometallic complex [UO2Cu(thftc)(bipy)(H2O)]•2H2O (bipy = 2,2ʹ-bipyridine), where the tetracarboxylic acid is again fully deprotonated, which was obtained under hydrothermal conditions at a temperature of 180 °C. 18 This compound crystallizes as a two-dimensional (2D) array with the {4 4 .6 2 } point symbol, in which the [Cu(bipy)(H2O)] 2+ cations have no topological role. The coordination mode here is different from that in the homometallic, molecular species since the copper(II) cation occupies the tridentate coordination site. Such differences between homo-and heterometallic complexes of a given ligand are well-known in general and have been explored in the field of uranyl complexes, 27- 35 although principally with the objective there of increasing the dimensionality of the lattice to generate uranyl-organic frameworks (UOFs [36][37][38][39] ) and not for the purpose of selecting different ligand isomers. To explore both issues and in continuation of our recent work on heterometallic complexes of 1,3,5-benzenetriacetic acid involving metal ions with very different coordination preferences, 40 we have now examined the complexes formed by uranyl cations with H4thftc, mainly in the presence of silver(I) or lead(II) cations under (solvo)-hydrothermal conditions, and we report herein the crystal structures and emission spectra in the solid state of three heterometallic complexes, all of them three-dimensional (3D) frameworks, as well as those of four homometallic complexes, containing either uranyl, silver or lead alone, for comparison purposes. The homometallic Ag I complex provides the second example of crystallization of the (2R*,3S*,4S*,5S*) isomer of the ligand.

EXPERIMENTAL SECTION

Syntheses. Caution! Uranium is a radioactive and chemically toxic element, and uraniumcontaining samples must be handled with suitable care and protection. Crystallography. The data were collected at 150(2) K on a Nonius Kappa-CCD area detector diffractometer 41 using graphite-monochromated Mo K radiation ( = 0.71073 Å). The crystals were introduced into glass capillaries with a protective coating of Paratone-N oil (Hampton Research). The unit cell parameters were determined from ten frames, then refined on all data. The data (combinations of -and -scans with a minimum redundancy of 4 for 90% of the reflections)

UO2(NO3)
were processed with HKL2000. 42 Absorption effects were corrected empirically with the program SCALEPACK. 42 The structures were solved by intrinsic phasing with SHELXT, 43 expanded by subsequent difference Fourier synthesis and refined by full-matrix least-squares on F 2 with SHELXL-2014. 44 All non-hydrogen atoms were refined with anisotropic displacement parameters.

The hydrogen atoms bound to oxygen and nitrogen atoms were retrieved from difference Fourier maps, and the carbon-bound hydrogen atoms were introduced at calculated positions; all hydrogen atoms were treated as riding atoms with an isotropic displacement parameter equal to 1.2 times that of the parent atom. In the case of complex 6, 3-component twinning was detected with PLATON/TwinRotMat 45 and taken into account; atom Ag3 is further disordered over two positions (one of them located on an inversion centre), which have been refined with occupancy parameters constrained to sum to unity.

Crystal data and structure refinement parameters are given in Table 1. The molecular plots were drawn with ORTEP-3 46 and the polyhedral representations with VESTA. 47 The topological analyses were conducted with TOPOS. 48 Luminescence Measurements. Emission spectra were recorded on solid samples using a Horiba-Jobin-Yvon Fluorolog spectrofluorometer. The powdered complex was pressed between two silica plates which were mounted such that the faces were oriented vertically and at 45° to the incident excitation radiation. An excitation wavelength of 420 nm was used in all cases and the emissions monitored between 450 and 650 nm.

RESULTS AND DISCUSSION

Synthesis. Complex 1 only was synthesized at room temperature, while the other complexes were obtained under purely hydrothermal (3-5) or solvo-hydrothermal (2, 6 and 7)

conditions, the latter with acetonitrile as a co-solvent, in which cases the crystalline materials deposited during the heating phase (140 °C). All the uranyl complexes with variously deprotonated

H4thftc ligands crystallized at room temperature, either in pure water or in organic solvents, in the present and previous studies 17 are molecular species, whereas all those synthesized by (solvo)hydrothermal methods are coordination polymers (even in the absence of additional metal cations in the final compound, as in the case of complex 2), thus providing a nice illustration of the specific interest of the latter methods for constructing polymeric species.

An interesting feature of the series is the variable degree of deprotonation, the lower corresponding to the room temperature synthesis, in which two carboxylic protons are retained, while one proton is found in complexes 2 and 6, full deprotonation being reached in the other cases (full deprotonation was also achieved in the metallamacrocyclic structures, obtained at room temperature in the presence of organic bases 17 indicates that the electron-withdrawing inductive effects associated with carboxylic and ether groups strongly favour the departure of the first proton. While the most acidic proton is most probably one of either of the two carboxylic groups in the  position with respect to the ether, 1 there is some uncertainty as to the subsequent deprotonation order, with either the protons at positions 2 and 5 being the more acidic, 1 or a 2, 4, 5, 3 deprotonation sequence. 14 However, esterification of H4thftc in methanol gave the 2,5-diester, thus showing that the carboxylic groups at those positions are possibly the most acidic. 50 This does not necessarily mean that these sites must be the ones where a metal ion would most readily replace the proton and it should be noted that coordination to the tetrahydrofuran-O may be an important factor favouring binding to the two adjacent carboxylate units.

Crystal Structures. The complex [C(NH2)3]2[UO2(H2thftc)2]
(1), represented in Figure 1, contains a mononuclear dianionic species in which the unique hexagonal bipyramidal uranium atom, located on an inversion centre, is bound to the tridentate, oxydiacetate-like site of two ligands, both carboxylic groups at the 3 and 4 positions retaining their proton. Formation of two five-membered chelate rings within the tridentate unit must be favoured over that of one seven-membered ring that would result from chelation by the groups in the 3 and 4 positions. 15 The U- [51][52][53][54] The six equatorial donors define a regularly puckered plane with a root mean square (rms) deviation of 0.27 Å. The H2thftc 2-anion is, as expected given the mild preparative conditions, in the achiral trans,cis,trans (2R*,3R*,4S*,5S*) form and the complex crystallizes in a centrosymmetric space group. The ligand adopts an envelope conformation with the carbon atom C1, next to O10, being displaced by 0.555(6) Å from the average plane defined by the four other atoms of the ring (rms deviation 0.015 Å). This is at variance with the conformation possessing mirror symmetry found in the cyclic polynuclear species, in which the ether group is out of the plane defined by the four carbon atoms. 17 Due to the presence of carboxylic groups and proton-rich C(NH2)3 + guanidinium counterions, extensive hydrogen bonding interactions are present. The carboxylic groups are hydrogen bonded to the uncoordinated oxygen atoms of the carboxylate groups from neighbouring complexes [O6O5 j 2.557(5) Å, O6-HO5 j 134°; O8O3 k 2.629(5) Å, O8-HO3 k 164°;

O(
symmetry codes: j = 1 -x, 2 -y, 1 -z and k = 1 -x, 1 -y, 2 -z],
which gives rise to the formation of sheets parallel to (1 -1 -1) with alternating cations and anions arranged into staggered rows, as

shown in Figure 1. The guanidinium counterion is involved in five intra-sheet hydrogen bonds, all with carboxylate oxygen atoms, with one of the protons involved in a bifurcated bond, while two protons bound to different nitrogen atoms are hydrogen bonded to the same oxygen atom. The other two hydrogen bonds formed by the counterion involve carboxylic oxygen atoms (O7 and O9) from an adjacent sheet, so that a 3D network is formed. Overall, the hydrogen bonds with guanidinium are significantly longer than those involving carboxylic donors [NO 2.877(6)-

3.204(6) Å, N-HO 132-162°].

A weak inter-sheet interaction between a carbon-bound proton of the ligand and the oxo atom O1, with a HO distance of 2.27 Å, may also be present. With a Kitaigorodski packing index (KPI, estimated with PLATON 45 ) of 0.73, the packing displays no free space.

Although it was synthesized in the presence of cadmium(II) nitrate and 2,2ʹ-bipyridine, complex 2, [(UO2)3(Hthftc)2(H2O)2]2CH3CN, does not contain these additional species and is a unique case of a polymeric homometallic uranyl complex obtained from H4thftc. The additional species in the reaction mixture could influence the solution equilibria both through nitrate and 2,2ʹbipyridine complexation of uranyl and pH effects, though the acidity of the aqua-Cd(II) cation would presumably counter the basicity of 2,2ʹ-bipyridine and it can only be said that the overall consequence is to enhance the degree of deprotonation of H4thftc. Note that in only three of the present seven cases does the stoichiometry of the isolated solid reflect that of the reaction mixture.

The asymmetric unit of 2 includes two independent uranium atoms, one of them (U1) located on an inversion centre, and one Hthftc 3-anion (Figure 2). Atom U1 is in the same environment as its counterpart in complex 16) Å], so that the latter interactions with the oxo groups may be considered as weak interactions at best, as confirmed by the absence of significant lengthening of the U=O bond lengths bonds, with distances as short as 2.38-2.58 Å, have been reported. [57][58][59] Here again, the ligand is in the trans,cis,trans (2R*,3R*,4S*,5S*) form, and the envelope conformation brings atom C1, next to O12, to 0.612(9) Å from the mean plane defined by the other four atoms of the ring (rms deviation 0.006 Å). The ligand is bound to four uranyl ions, in a similar way as that found in complex 2, the difference arising from replacement of the uncomplexed carboxylic group by a silver-bound carboxylate (Scheme 1). Considering only uranyl cations, a 2D assembly analogous to that in 2 is thus formed, with the V2O5 topological type and parallel to (1 -1 1). Instead of being hydrogen bonded to one another, the layers are united into a 3D coordination polymer by the bridging Ag2 moieties. The coordinated and lattice water molecules are hydrogen bonded to oxo and carboxylato groups, and to one another. The KPI of 0.73 (0.68 with solvent excluded) indicates that no spaces or channels of significant size are present.

Two crystalline complexes combining uranyl and lead(II) cations have been obtained, [UO2Pb(thftc)(H2O)] ( 4) and [UO2Pb(thftc)(H2O)2]H2O (5), their syntheses differing by the additional presence of silver nitrate in that of compound 4. The asymmetric unit in 4 contains one uranyl and one lead(II) cation, and one fully deprotonated thftc 4-ligand (Figure 4). The most prominent difference with the previous cases is that the tridentate coordination site is now occupied by lead(II) (as it was by copper(II) in the previously reported heterometallic complex 18 ), and U(VI) is found exclusively in a pentagonal bipyramidal environment. Å], which gives a nine-coordinate environment of very irregular geometry possibly influenced by the presence of a stereochemically active lone pair. [60][61][62] Holodirected bonding should be favoured in the present case, 60 but it should be noted that all the Pb-O(carboxylate) bond lengths are somewhat long and several of them may correspond to rather weak bonds only, a situation commonly encountered in Pb II complexes. 62 The thftc 4-ligand is in the same form as in the previous complexes, with atom C2, next to O11, deviating by 0.56(2) Å from the average plane defined by the four other atoms of the ring (rms deviation 0.010 Å). The ligand is bound to seven (four lead(II) and three uranyl) metal cations (Scheme 1), and this high connectivity gives rise to the formation of a 3D framework, a situation different from that in the copper(II)-containing complex previously reported, in which the terminal nature of the bipy and water ligands bound to Cu II limited the polymer propagation. 18 Planar sheets parallel to (1 1 0) are apparent, that are connected to one another through lead-carboxylate bonds, a feature reminiscent of that found in complex 3.

However, the sheets here are heterometallic, with alternating rows of uranyl dimers (with double carboxylate bridges) and lead cations directed along the c axis (Figure 4). The KPI of 0.81 is indicative of a very compact arrangement.

With respect to that in 4, the asymmetric unit in significantly lower than that of 3.176(5) Å found in a complex with 1,3,5-benzenetriacetate. 40 Distances for such oxo-cation interactions involving lanthanides are 2.822(4) Å for Ce(III) and 2.792(6) Å for Nd(III); 63 the ionic radius of Pb II being about 0.1 Å larger than that of Ce(III), the present distance seems compatible with the existence of such an interaction, but the absence of significant U=O bond lengthening [U1-O1 1.774(4), U1-O2 1.763(4) Å] indicates however that it is not a very strong one. Pb1 is thus in an irregular nine-coordinate environment that would have a hemidirected character but for the contact with the oxo group. The ligand is in the same form as in the other compounds, but the envelope conformation has atom C4 (in the succinate-like part) displaced by 0.653(8) Å from the mean plane defined by the four other atoms of the ring (rms deviation 0.019 Å), a conformation previously found, for example, in the cesium or calcium salts of partially or fully deprotonated H4thftc, 1 or in the heterometallic uranyl/copper(II) complex of the latter. 18 As in complex 4, the ligand is bound to seven (four lead(II) and three uranyl) metal cations, although they are differently arranged in both compounds (Scheme 1), and this high degree of connectivity results here also in the formation of a 3D framework (KPI 0.78), in which thick layers parallel to (0 0 1) can be discerned (Figure 5). The water molecules are hydrogen bonded to one another and to carboxylate and oxo groups.

Since no structure of a homometallic complex formed by H4thftc with either silver(I) or lead(II) has been reported, it appeared worthwhile to synthesize such compounds so as to compare the coordination modes observed to those in the heterometallic complexes. In the event, this also proved interesting in regard to the selection of isomers of H4thftc apparently present in the solvothermal reaction mixtures. The asymmetric unit in [Ag3(Hthftc)] ( 6) contains three independent silver cations, one of them (Ag3) being disordered over two positions (one of them located on an inversion centre), and one Hthftc 3-ligand (Figure 6). form, with the three carboxylate groups located on one side of the ring and the carboxylic group on the other side. As noted previously, inversion of the ring carbon atoms of H4thftc has been observed in a family of zinc(II) complexes, 8 and the same phenomenon arises with 1,2,3,4cyclobutanetetracarboxylic acid (cis,trans,cis and trans,trans,trans isomers) 18,21,23,24 and with 1,2,3,4,5,6-cyclohexanehexacarboxylic acid (all-cis and all-trans isomers). 20,22,25 The cyclopentane ring is here once more in an envelope conformation, albeit somewhat more distorted than in complexes 1-5, with atom C1, next to O9, displaced by 0.547(12) Å from the mean plane defined by the four other atoms (rms deviation 0.051 Å). With about 11 silver(I) cations bound to the ligand (the value may vary due to the disorder affecting Ag3; only one possible arrangement is shown in Scheme 1), it is unsurprising that the polymer generated is 3D and extremely intricate.

The cations appear to be concentrated into layers parallel to (1 0 0), these layers containing cylindrical channels with a diameter of 5 Å running along the c axis (Figure 6). Notwithstanding these narrow free spaces, the KPI value of 0.79 (calculated for only one position of Ag3) indicates that this compound cannot be considered as really porous, at least for any practical purpose.

Unlike the homometallic Ag I complex but like all other complexes in the present study, the homometallic Pb II complex, [Pb2(thftc)(H2O)] ( 7), contains the ligand in its trans,cis,trans Luminescence properties. Solid state emission spectra have been recorded under excitation at a wavelength of 420 nm, a value suitable for excitation of uranyl, 64 for compounds 1-7, and those for the uranium-containing complexes 1-5 are shown in Figure 8. The spectra of the uranyl-only complexes 1 and 2, and that of the uranyl/lead(II) complex 4 show intense and wellresolved uranyl emission displaying the vibronic progression corresponding to the S11  S00 and S10  S0 ( = 0-4) states. 65 The maxima are at 496, 518, 542, 568 and 596 nm for complex 1, while they are blue-shifted by 2 nm in 2, and red-shifted by 2 nm in 4; some changes in the relative intensities of the peaks are also observed, which could be due at least partly to a very broad single peak seemingly convoluted with the uranyl spectrum in the case of 1 and 4. Weak bands at 477 and 482 nm in the spectra of 2 and 4, respectively, correspond to a shoulder of the first intense band in the spectrum of 1. The positions of the main maxima are very close to those recently measured in an 8-coordinate uranium(VI) complex with 2,5-thiophenedicarboxylate ligands and Ag(bipy)2 + counterions, 66 and also to those in several 7-coordinate complexes, with 4,

(
hexafluoroisopropylidene)diphthalate, 67 1,1′-biphenyl-2,2′,6,6′-tetracarboxylate, 68 terephthalate, 69,70 and 2,5-thiophenedicarboxylate, 70 irrespective of the different uranium coordination numbers present here (8 in 1, 7 in 4 and a mixture of both in 2), and they are all redshifted, by 10-20 nm, with respect to the values, measured under identical experimental conditions, generally reported for 8-coordinate uranium(VI) carboxylate complexes. 25,40,[70][71][72][73][74][75][76] Spectra that are nearly identical for 7-and 8-coordinate complexes have also been reported in 4,4′biphenyldicarboxylate complexes, with maxima positions blue-shifted by 6 nm with respect to those for 1. 77 The slightly unsymmetrical shape of the main peaks for complex 2 may be due to the convolution of signals corresponding to these two coordination numbers. Clearly, if the coordination number is a known factor governing the uranyl emission spectra, other factors such as the ligand strength are also at play. 78,79 The spectra of the silver-and lead-containing heterometallic complexes 3 and 5 show strong quenching of uranyl luminescence, attributed to the additional metal cations providing nonradiative relaxation pathways. 80 Such quenching is not general with silver(I), 66,81,82 although it has been previously observed to occur. 40,80 In the spectrum of complex 3, in which 7-and 8-coordination of uranium coexist, only three very weak peaks at 481, 502 and 521 nm are apparent, these values being identical to those measured for several 8coordinate uranyl complexes with carboxylates. 25,40,[70][71][72][73][74][75][76] These three peaks are superimposed upon a broad emission centred near 490 nm; given that the homometallic Ag I complex 6 displays a broad, weak emission centred near 550 nm (Figure S1, Supporting Information), it is assumed that the emission at 490 nm in complex 3 is due to the Ag-carboxylate entity. In a previous study with 1,3,5-benzenetriacetate, lead(II) evinced no major quenching effect, 40 as shown here also by complex 4, but in contrast to what is observed for complex 5. The emission in the latter complex is again extremely weak, with maxima at 483, 499, 521, 545 and 572 nm, very close to those for complex 4 (it is notable that the lead(II) complex 7 is non-emissive, see Supporting Information).

The origin of the emission intensity difference between 4 and 5 may be subtle, since the coordination environment of uranium(VI) is very similar in the two cases, although somewhat more irregular in complex 5, but the bound water molecule in the latter offers an obvious pathway for non-radiative energy loss from uranium(VI) which is not available in complex 4 (although one coordinated water is also present in the strongly emitting complex 2). Assuming that energy loss from excited uranium(VI) could occur by transfer to a nearby metal ion, it is of interest that in the two structures each lead(II) cation is within 5 Å of two uranium(VI), and each uranium(VI) within 5 Å of two lead(II) centres, thus comprising PbUPbU parallelograms with sides of 4.6335(7) and 4.9402(8) Å in complex 4 and 4.6837(5) and 4.7089(5) Å in complex 5, the difference in the minimum separation being clearly rather slight. The average vibronic splitting energies for the S10  S0 transitions are in the range of 852-859 cm -1 for complexes 1, 2, 4 and 5, these values being comparable to that of 852 cm -1 measured in uranyl malonates, 65 as well as to those in uranyl complexes with other polycarboxylates. 66,70,75

CONCLUSIONS

The present work provides further illustration of the fact that the solid-state coordination chemistry of uranyl ion can be radically modified by the presence of other metal ions. Silver(I) and lead(II) provide important examples of this effect in that the origins of their influence appear to be quite different. Thus, Pb II , like Cu II , prevents uranyl ion adopting certain coordination modes, in particular, tridentate coordination involving the ether-O, by preferentially binding in the same manner. Silver(I), in contrast, has a coordination chemistry which is quite different to that of uranyl ion (and Pb II ) and while this does not prevent uranyl ion adopting tridentate coordination of thftc 4- anions and thus may be a reason why the ligand is found still in its trans,cis,trans (2R*,3R*,4S*,5S*) form, binding of Ag2 dimers to the ligand creates an "exotic" unit within the lattice which modifies the way the uranyl entities are connected. The effects of Ag I and Pb II in uranyl-organic coordination polymers are however much dependent on the nature of the ligand, as indicated by recent findings that, in a series of complexes with 1,3,5-benzenetriacetate, Pb II generates less marked changes in the uranyl coordination mode than Ag I , 40 an outcome at variance with that observed here and which seems related to the peculiar nature of the tridentate coordination site of thftc 4-, for the occupation of which uranyl and Pb II are in competition.

The specific coordination preferences of silver(I) may also explain its deposition as the complex of the (2R*,3S*,4S*,5S*) isomer of the ligand when no other metal ion is present. That this is the only isomer so far found in the two cases where isomerization of the starting species can be confirmed may mean that the "library" of equilibrated isomers consists of only two members (R*,R*,S*,S* and R*,S*,S*,S*), or that an unfavourable equilibrium is displaced by precipitation, or that the isolated complexes are simply the least soluble materials (when crystallised at room temperature). Further work is required to characterize the equilibrium achieved under hydrothermal conditions with the acid alone and an interesting further experiment would be to search for a metal precipitating the (2R*,3S*,4S*,5S*) isomer as a racemic mixture ("spontaneous resolution") rather than as a racemic compound.

From a crystal engineering viewpoint, it is notable that the homometallic uranyl complexes obtained up to now are either discrete, molecular species when synthesized at room temperature, as complex 1 in the present study or the metallamacrocycles previously reported, 17 or a 2D coordination polymer when isolated from a solvo-hydrothermally treated solution (complex 2). In contrast to the 2D network observed in the uranyl/copper(II) complex [UO2Cu(thftc)(bipy)(H2O)]•2H2O, 18 in which the terminal bipy ligand plays a role in restricting the dimensionality, all the heterometallic complexes reported here, with silver(I) and lead(II) additional cations, crystallize as 3D frameworks as a result of the high connectivity of the ligand which is bound to seven metal atoms in all cases, and the bridging nature of all cations (the high coordination number of lead(II) cations in particular being conducive to the formation of intricate arrangements). 3D frameworks are also found in the homometallic silver(I) and lead(II) complexes, and the ligand connectivity achieved in these cases is even higher, with 9 (Cu) or 11 (Ag) cations bound to the ligand. The UO2/Pb/Ag/H4thftc system has obviously a rich potential for the building of 3D assemblies, none of those described here presenting significant porosity however. Intense and well resolved solid state emission in the 470-600 nm range showing the vibronic fine structure typical of the uranyl cation is displayed by the homometallic complexes 1 and 2, and the uranyl/lead(II) heterometallic complex 4, while uranyl emission in the silver(I)-and lead(II)containing complexes 3 and 5 is largely quenched.

ASSOCIATED CONTENT Accession Codes

CCDC 1500859-1500865 contains the supplementary crystallographic data for this paper. o = x, 1 -y, z + 1/2; p = x, -y, z + 1/2; q = x, y, z + 1. Middle and bottom: Two views of the 3D framework with all hydrogen atoms omitted. In all views, only one position (and its symmetry equivalents) of the disordered silver cation Ag3 is represented. x + 1, y, z; o = x, 1/2 -y, z -1/2; p = x -1, y, z; q = 1 -x, y -1/2, 3/2 -z; r = -x, y -1/2, 3/2 -z.

Bottom: View of the 3D framework with all hydrogen atoms omitted.

[ 1 .

 1 760(5)-1.776(5) Å]; only the bond with O3 l is shown in Figure3. Much stronger Ag-O(uranyl)

Figure 1 .

 1 Figure 1. Top: View of complex 1. Displacement ellipsoids are drawn at the 50% probability level.

Figure 2 .

 2 Figure 2. Top left: View of complex 2. Displacement ellipsoids are drawn at the 50% probability

Figure 3 .

 3 Figure 3. Top: View of complex 3. Displacement ellipsoids are drawn at the 50% probability level.

Figure 4 .

 4 Figure 4. Top: View of complex 4. Displacement ellipsoids are drawn at the 50% probability level.

Figure 5 .

 5 Figure 5. Top: View of complex 5. Displacement ellipsoids are drawn at the 50% probability level.

Figure 6 .

 6 Figure 6. Top: View of the silver-only complex 6. Displacement ellipsoids are drawn at the 40%

Figure 7 . 2 -

 72 Figure 7. Top: View of the lead-only complex 7. Displacement ellipsoids are drawn at the 50%

Figure 8 .Scheme 1 . 7 Figure 1 32

 8171 Figure 8. Solid state emission spectra of the homometallic uranyl complexes 1 and 2 and the

Figure 2 33

 2 Figure 2

Figure 3 34 Figure 4 35

 344 Figure 3

Figure 5 36 Figure 6 37

 366 Figure 5

Figure 7

 7 Figure 7

  within ten days (22 mg, 50% yield based on H4thftc). Anal. calcd for C18H24N6O20U: C, 24.50; H, 2.74; N, 9.52. Found: C, 24.39; H, 2.71; N, 9.45%.

	[Ag3(Hthftc)] (6). H4thftc (25 mg, 0.10 mmol), AgNO3 (34 mg, 0.20 mmol), acetonitrile
	(0.2 mL), and demineralized water (0.8 mL) were placed in a 10 mL tightly closed glass vessel and
	[(UO2)3(Hthftc)2(H2O)2]2CH3CN (2). H4thftc (25 mg, 0.10 mmol), UO2(NO3)2•6H2O (50 heated at 140 °C under autogenous pressure, giving colourless crystals of complex 6 within two
	mg, 0.10 mmol), Cd(NO3)2•4H2O (31 mg, 0.10 mmol), 2,2ʹ-bipyridine (16 mg, 0.10 mmol), weeks (6 mg, 16% yield based on Ag). Anal. calcd for C8H5Ag3O9: C, 16.90; H, 0.89. Found: C,
	acetonitrile (0.4 mL), and demineralized water (0.6 mL) were placed in a 10 mL tightly closed 17.23; H, 0.99%.
	glass vessel and heated at 140 °C under autogenous pressure, giving light yellow crystals of [Pb2(thftc)(H2O)] (7). H4thftc (13 mg, 0.05 mmol), Pb(NO3)2 (33 mg, 0.10 mmol),
	complex 2 overnight (11 mg, 23% yield based on U). Anal. calcd for C20H20N2O26U3: C, 16.94; H, acetonitrile (0.3 mL), and demineralized water (0.6 mL) were placed in a 10 mL tightly closed
	glass vessel and heated at 140 °C under autogenous pressure, giving colourless crystals of complex
	7 overnight (13 mg, 38% yield). Anal. calcd for C8H6O10Pb2: C, 14.20; H, 0.89. Found: C, 14.13;
	H, 0.94%.
	[C(NH2)3]NO3	were	purchased	from	Prolabo,	and	(2R*,3R*,4S*,5S*)-
	tetrahydrofurantetracarboxylic acid (H4thftc) was from Aldrich. Elemental analyses were [UO2Pb(thftc)(H2O)2]H2O (5). H4thftc (25 mg, 0.10 mmol), UO2(NO3)2•6H2O (50 mg,
	performed by MEDAC Ltd. at Chobham, UK and the Service de Microanalyse of the CNRS at Gif-0.10 mmol), Pb(NO3)2 (33 mg, 0.10 mmol), and demineralized water (1.0 mL) were placed in a 10
	sur-Yvette, France. mL tightly closed glass vessel and heated at 140 °C under autogenous pressure, giving light yellow
	[C(NH2)3]2[UO2(H2thftc)2] (1). H4thftc (25 mg, 0.10 mmol), UO2(NO3)2•6H2O (50 mg, crystals of complex 5 overnight (12 mg, 15% yield). Anal. calcd for C8H10O14PbU: C, 12.39; H,
	1.30. Found: C, 12.97; H, 1.15%.

2•6H2O (depleted uranium, R. P. Normapur, 99%), AgNO3, Pb(NO3)2 and 0.10 mmol) and guanidinium nitrate (24 mg, 0.20 mmol) were dissolved in demineralized water (0.6 mL). The solution was left to evaporate slowly at room temperature, giving light yellow crystals of complex 1 1.42; N, 1.97. Found: C, 17.31; H, 1.45; N, 1.92%.

[(UO2)3Ag2(thftc)2(H2O)2]2H2O (3). H4thftc (25 mg, 0.10 mmol), UO2(NO3)2•6H2O (50 mg, 0.10 mmol), AgNO3 (34 mg, 0.20 mmol), and demineralized water (1.0 mL) were placed in a 10 mL tightly closed glass vessel and heated at 140 °C under autogenous pressure, giving light yellow crystals of complex 3 within two weeks (6 mg, 11% yield based on U). Anal. calcd for C16H16Ag2O28U3: C, 12.12; H, 1.02. Found: C, 12.44; H, 1.48%.

[UO2Pb(thftc)(H2O)] (4). H4thftc (25 mg, 0.10 mmol), UO2(NO3)2•6H2O (50 mg, 0.10 mmol), Pb(NO3)2 (33 mg, 0.10 mmol), AgNO3 (17 mg, 0.10 mmol), and demineralized water (1.0 mL) were placed in a 10 mL tightly closed glass vessel and heated at 140 °C under autogenous pressure, giving light yellow crystals of complex 4 within two days (13 mg, 18% yield). Anal. calcd for C8H6O12PbU: C, 13.00; H, 0.82. Found: C, 12.87; H, 1.07%.

  ). It is notable that the protons retained are located on the carboxylic groups at positions 3 and 4 (see below). The reported pKai (i = 1-4) values determined by titration for H4thftc are 0.95, 3.40, 5.55 and 6.42,49 or in the ranges 1.57-2.08, 2.86-

3.68, 4.08-5.40 and 5.61-7.26,

14,19

depending largely on the ionic strength. The low value of pKa1

  carboxylate) [2.399(3) and 2.447(3) Å] and U-O(ether) [2.640(3) Å] bond lengths are unexceptional, and they are larger by 0.09 Å than those in the metallamacrocycles previously reported 17 as a consequence of the different coordination number, seven in the latter complexes and eight in 1; in particular, these bond lengths are very close to those measured in eight-coordinate uranyl complexes with oxydiacetate (2.36-2.46 Å and 2.62-2.72 Å, respectively).

  of the ring (rms deviation 0.013 Å). Each ligand is bound to four metal atoms, its three carboxylate groups being bridging bidentate (2- 1 : 1 coordination mode) and the carboxylic acid group being uncoordinated (Scheme 1). Only U2 and Hthftc 3-are nodes (three-and four-fold, respectively) in the 2D polymeric assembly parallel to (1 1 0), with the point (Schläfli) symbol {4 2 .6 3 .8}{4 2 .6} (topological type V2O5). As shown in Figure2, this arrangement can be viewed as formed of an alternation of rows of differently sized parallelograms and it is different from the {44 .6 2 } network found in the uranyl/copper(II) heterometallic complex of thftc4-, in which the copper cations have no topological role. A centrosymmetric pair of silver atoms connected through a strong argentophilic interaction[2.7773(13) Å] is trapped between two 2- 1 : 1 carboxylate groups, which is a usual motif, with more than 60 comparable examples reported in the Cambridge Structural Database (CSD, Version 5.37),55,56 giving an

	average AgAg distance of 2.89(10) Å. The Ag-O(carboxylate) bond lengths of 2.169(5) and
	2.186(5) Å are unexceptional [average 2.25(9) Å from the CSD]. Ag1 is involved in three longer
	contacts, one with the carboxylate atom O7 l [2.706(5) Å; symmetry code: l = x -1, y, z] and the
	others with the uranyl oxo atoms O3 l [2.899(5) Å] and O1 ll [2.974(5) Å; symmetry code: ll = x, y
	O(ether) [2.660(3) Å] bond lengths. Atom U2 is chelated by two carboxylic groups in the positions
	2 and 3 (atoms O7 and O8) to give a 7-membered ring, and it is also bound to two more carboxylate 373(4) and
	oxygen atoms from two different ligands and a water molecule, its environment being thus 2.407(5) Å] bond lengths and a U-O(ether) bond length of 2.746(5) Å slightly longer than usual.
	pentagonal bipyramidal with unexceptional U-O(carboxylate) bond lengths [2.321(4)-2.432(4) Atom U1 is chelated by two carboxylate groups in the 2 and 3 positions of one ligand and it is

1, with similar U-O(carboxylate)

[2.386(3)

and 2.447(4) Å] and U-Å]. The ligand retains the trans,cis,trans (2R*,3R*,4S*,5S*) form, with an envelope conformation, the carbon atom C2, next to O12, being at 0.613(8) Å from the average plane defined by the other four atoms

18

The carboxylic proton is hydrogen bonded to the acetonitrile solvent molecule [O11N1 2.720(6) Å, O11-HN1 153°], and those of the water molecule are bonded to either a carboxylate or a carboxylic oxygen atom pertaining to the same or an adjacent layer, respectively [O13O6 i 2.779(5) Å, O13-HO6 i 168°; O13O10 ii 2.748(

6

) Å, O13-HO10 ii 146°; symmetry codes: i = 1 -x, 2 -y, 2 -z and ii = 1 -x, 1 -y, 2 -z]. The oxo atoms O2 and O3 may be involved in weak interactions with carbon-bound hydrogen atoms from a ligand of the neighbouring sheet (HO 2.45 Å) and the acetonitrile molecule (2.69-2.79 Å). The KPI of 0.71 indicates a compact arrangement devoid of free spaces.

The asymmetric unit in the heterometallic complex [(UO2)3Ag2(thftc)2(H2O)2]2H2O (3) contains two uranium atoms, one of them (U2) located on an inversion centre, one silver(I) cation and one fully deprotonated thftc 4-ligand (Figure

3

). Like U1 in complexes 1 and 2, atom U2 is bound to the tridentate site of two ligands, with unexceptional U-O(carboxylate)

[2.

bound to two more carboxylate donors from two more ligands [U-O(carboxylate) bond lengths 2.315(2)-2.453(4) Å] and to a water molecule, as for U2 in complex 2. + 1, z]. The Ag-O bond lengths reported in the CSD range approximately from 2.0 to 3.1 Å [average 2.45(

  5 contains two additional water molecules, one coordinated and one free, but the connectivity is different. The uranium atom is once more

chelated by two carboxylate groups in 2 and 3 positions, and is bound to two more carboxylate donors from two different ligands and one water molecule [U-O(carboxylate) bond lengths in the range 2.283(4)-2.417(3) Å]. The tridentate coordination site is here again occupied by the lead(II) cation, with a Pb-O(ether) bond length [2.675(4) Å] shorter than that in 4. The lead(II) cation is bound to six carboxylate oxygen atoms [2.580(4)-2.759(4) Å, with a longer contact at 3.031(5) Å with the bridging atom O9, part of an unsymmetrical chelating group] and to a water molecule [2.502(4) Å]. It is also possibly bonded to the uranyl oxo atom O1, at 2.999(4) Å, a value

  in the heterometallic complexes. The ligand ring conformation is here again of the envelope type and an atom in the succinate-like part (as in complex 5), C3, is at 0.623(9) Å from the average plane defined by the four other atoms (rms deviation 0.040 Å). All nine O-donors of the ligand are involved in coordination, through chelating and bridging interactions (with in particular a regular 3- 1 : 2 : 1 coordination mode for the two carboxylate groups of the succinatelike part), to nine Pb II centres (Scheme 1). The water molecule is hydrogen bonded to carboxylate oxygen atoms [OO distances 2.903(6) and 2.738(6) Å, O-HO angles 151 and 168°]. The complex is a 3D coordination polymer in which layers of ligand molecules parallel to (0 1 0) can be considered to be linked within and bridged by layers containing both Pb1 and Pb2. The high KPI value of 0.86 is indicative of a dense arrangement.

	to that found
	2R*,3R*,4S*,5S*) form. There are two inequivalent metal atoms, with Pb1 bound to the tridentate
	site of the ligand, and an 8-membered chelate ring formed on Pb2 through binding of just the
	carboxylate-O donors on ring positions 2 and 5 (O1 and O3) and not of their intervening ether-O
	atom. Pb1 is also bound to four more carboxylate oxygen atoms (among which O7 and O8 pertain
	to a chelating group), and to two water molecules [Pb1-O(water) bond lengths 2.813(5) and
	2.962(5) Å]. Pb2 has no water ligand, and it is bound to nine carboxylate oxygen donors, all but
	O2 being involved in chelation through either one or two carboxylate groups. All the chelating
	interactions are quite unsymmetrical, and both Pb1 and Pb2 are 9-coordinate with an irregular
	geometry, probably best described as holodirected. The Pb1-O9(ether) bond length of 2.729(4) Å
	lies between those found in complexes 4 and 5. The Pb-O(carboxylate) bond distances vary
	considerably [2.451(5)-3.000(5) Å for Pb1, 2.369(4)-3.089(5) Å for Pb2] but over a similar range

Table 1 . Crystal Data and Structure Refinement Details

 1 Thesedata can be obtained free of charge via www.ccdc.cam.ac.uk/data_request/cif, or by emailing data_request@ccdc.cam.ac.uk, or by contacting The Cambridge Crystallographic Data Centre, 12,

	Union Road, Cambridge CB2 1EZ, UK; fax: +44 1223 336033.

82. Yu, Y.; Zhan, W.; Albrecht-Schmitt, T. E. Inorg. Chem. 2007, 46, 10214-10220.

Supporting Information

The Supporting Information is available free of charge on the ACS Publications website at DOI:. Emission spectra of complexes 6 and 7. (PDF)

AUTHOR INFORMATION

Corresponding Authors

*E-mail: pierre.thuery@cea.fr (P. T.) *E-mail: harrowfield@unistra.fr (J. H.)

Notes

The authors declare no competing financial interest.

For Table of Contents Use Only

Tetrahydrofurantetracarboxylic Acid: an Isomerizable

Framework-Forming Ligand in Homo-and Heterometallic Complexes with UO2 2+ , Ag + and Pb 2+

Pierre Thuéry and Jack Harrowfield

Seven homo-and heterometallic complexes formed by tetrahydrofurantetracarboxylic acid with either uranyl, silver(I) or lead(II) cations or mixtures thereof display arrangements of various dimensionality, among which three-dimensional frameworks are dominant. The ligand is found to have undergone isomerization into one of its chiral forms in the silver-only complex.


Rennan Dantas

Frédéric Havet

Rudini M Sampaio

Identifying codes for infinite triangular grids with a finite number of rows

Extended Abstract

Let G be a graph G. The neighborhood of a vertex v in G, denoted by N (v), is the set of vertices adjacent to v i G. It closed neighborhood is the set

N [v] = N (v) ∪ {v}. A set C ⊆ V (G) is an identifying code in G if (i) for all v ∈ V (G), N [v] ∩ C = ∅, and
(ii) for all u, v ∈ V (G), N [u] ∩ C = N [v] ∩ C.
The identifier of v by C, denoted by C[v], is the set N [v] ∩ C. Hence a identifying code is a set such that the vertices have non-empty distinct identifiers.

Let G be a (finite or infinite) graph with bounded maximum degree. For any non-negative integer r and vertex v, we denote by

B r (v) the ball of radius r in G, that is B r (v) = {x | dist(v, x) ≤ r}. For any set of vertices C ⊆ V (G), the density of C in G, denoted by d(C, G), is defined by d(C, G) = lim sup r→+∞ |C ∩ B r (v 0 )| |B r (v 0 )| ,
where v 0 is an arbitrary vertex in G. The infimum of the density of an identifying code in G is denoted by

d * (G). Observe that if G is finite, then d * (G) = |C * |/|V (G)|, where C * is a minimum-size identifying code in G.
The problem of finding low-density identifying codes was introduced in [START_REF] Karpovsky | On a new class of codes for identifying vertices in graphs[END_REF] in relation to fault diagnosis in arrays of processors. Here the vertices of an identifying code correspond to controlling processors able to check themselves and their neighbors. Thus the identifying property guarantees location of a faulty processor from the set of "complaining" controllers. Identifying codes are also used in [START_REF] Ray | Robust location detection with sensor networks[END_REF] to model a location detection problem with sensor networks.

Particular interest was dedicated to grids as many processor networks have a grid topology. There are three regular infinite grids in the plane, namely the hexagonal grid, the square grid and the triangular grid.

Regarding the infinite hexagonal grid G H , the best upper bound on d * (G H ) is 3/7 and comes from two identifying codes constructed by Cohen et al. [START_REF] Cohen | Bounds for Codes Identifying Vertices in the Hexagonal Grid[END_REF]; these authors also proved a lower bound of 16/39. This lower bound was improved to 12/29 by Cranston and Yu [START_REF] Cranston | A new lower bound on the density of vertex identifying codes for the infinite hexagonal grid[END_REF]. Cukierman and Yu [START_REF] Cukierman | New bounds on the minimum density of an identifying code for the infinite hexagonal graph grid[END_REF] further improved it to 5/12.

The infinite square grid G S is the infinite graph with vertices in Z×Z such that N ((x, y)) = {(x, y ± 1), (x ± 1, y)}. Given an integer k ≥ 2, let [k] = {1, . . . , k} and let S k be the subgraph of G S induced by the vertex set {(x, y) ∈ Z × [k]}. In [START_REF] Cohen | Improved identifying codes for the grid[END_REF], Cohen et al. gave a periodic identifying code of G S with density 7/20. This density was later proved to be optimal by Ben-Haim and Litsyn [START_REF] Ben-Haim | Exact minimum density of codes identifying vertices in the square grid[END_REF]. Daniel, Gravier, and Moncel [START_REF] Daniel | Identifying codes in some subgraphs of the square lattice[END_REF] showed that d * (S 1 ) = 1 2 and d * (S 2 ) = 3 7 . They also showed that for every k ≥ 3,

7 20 - 1 2k ≤ d * (S k ) ≤ min 2 5 , 7 20 + 2 k .
These bounds were recently improved by Bouznif et al. [START_REF] Bouznif | Minimum-density identifying codes in square grids[END_REF] who established

7 20 + 1 20k ≤ d * (S k ) ≤ min 2 5 , 7 20 + 3 10k
.

They also proved d * (S 3 ) = 3

The infinite triangular grid G T is the infinite graph with vertices in Z × Z such that N ((x, y)) = {(x, y ± 1), (x ± 1, y), (x -1, y + 1), (x + 1, y -1)}. Given an integer k ≥ 2, let [k] = {1, . . . , k} and let T k be the subgraph of G T induced by the vertex set {(x, y) ∈ Z × [k]}. Karpovsky et al. [START_REF] Karpovsky | On a new class of codes for identifying vertices in graphs[END_REF] showed that d * (G T ) = 1/4. Trivially, T 1 = S 1 . Hence d * (T 1 ) = 1 2 In this paper, we prove the following results regarding the density of an identifying code of T k , k > 1.

Theorem 1 • d * (T k ) = 1 4 + 1 4k for every odd k. • d * (T 2 ) = 1 2 and d * (T 4 ) = d * (T 6 ) = 1 3 . • 1 4 + 1 4k ≤ d * (T k ) ≤ 1 4 + 1 2k
for every even k.

The upper bounds are obtained by showing periodic identifying codes with the desired density. Consider the sets (see Figure 1)

C 2 = {(x, 1) | x ≡ 1, 3 mod 5} ∪ {(x, 2) | x ≡ 1, 2, 4 mod 5}; C 2k-1 = {(x, y) | x | x, y odd and 1 ≤ x, y ≤ 2k -1}; C 4 = {(x, 2) | x ≡ 0, 3 mod 3} ∪ {(x, 3) | x ≡ 0, 1 mod 3}; C 2k = {(x, y), (x, y) | x, y odd , 1 ≤ x ≤ 2k and 1 ≤ y ≤ 2k -3} ∪ {(x, 2k -1) | x ∈ Z}.
It is easy to check that the above defined sets C 2 is an identifying codes of T 2 with density 1/2, C 3 is identifying codes of T 3 with density 1/3, C 4 is an identifying code of T 4 with density 3/10. and C 2k-1 is an identifying code of T 2k-1 with density 1 4 + 1 4k and C 2k is an identifying code of T 2k with density 1 4 + 1 2k . Our lower bounds are obtained via the Discharging Method. The general idea is the following. We consider any identifying code C of T k . The vertices in C receive a certain value q k > 0 of charge and the vertices not in C receive charge 0. Then we apply some local discharging rules. Here local means that there is no charge transfer from a vertex to a vertex at distance more than d k for some fixed constant d k , and that the total charge sent by a vertex is bounded by some fixed value m k . Finally, we prove that after the discharging, every vertex v has final charge chrg * (v) at least p k for some fixed p k > 0. We claim that it implies d(C, G) ≥ p k q k . Since a vertex sends charge at most m k to vertices at distance at most d k , a charge of at most

m k • |B r+s (v 0 ) \ B r (v 0 )| ≤ 2d k • k • m k enters B r (v 0 ) during the discharging phase. Thus |C ∩ B r (v 0 )| = 1 q k v∈Br(v0) chrg 0 (v) ≥ 1 q k   v∈Br(v0) chrg * (v) -m k • |B r+s (v 0 ) \ B r (v 0 )|   ≥ p k |B r (v 0 )| -2d k • k • m k q k . But |B r (v 0 )| ≥ 2(k + 1)r -k 2 , thus d(C, S k ) ≥ lim sup r→+∞ p k q k - 1 q k • 2d k • k • m k 2(k + 1)r -k 2 = p k q k .
This proves our claim. As the claim holds for any identifying code, we have d * (T k ) ≥ p k /q k .

Acknowledgements

This research was supported by FAPERJ, Capes (Project STIC-AmSud 2012), CNPq (Project Universal/Bolsa de Produtividade), and the FUNCAP/CNRS project GAIATO INC-0083-00047.01.00/13.