Eric Lafon

Quentin Potié
email: quentin.potie@ign.fr

Guillaume Touya

Salient building detection using multimodal deep learning

Keywords: Human perception, cartographic landmarks, multimodal deep learning

scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Machine learning has been used for decades in the GIS field, either to classify objects or to segment pixels on an image. A machine learning model is usually trained on either an enriched vector database or on images using CNN. A multimodal architecture tries to join both worlds by giving multiple types of data as an input to a unique model [START_REF] Baltrušaitis | Multimodal Machine Learning: A Survey and Taxonomy[END_REF]. Multimodal deep learning techniques have been used to predict the price of houses by using photos of the house in combination with its tabular data such as area, number of rooms, etc. [START_REF] Azizi | Improving Real Estate Rental Estimations with Visual Data[END_REF].

The goal of this work is to explore the possibilities offered by multimodal deep learning for cartography applications. Our use case is to detect salient buildings in an existing cartographic database. This could be helpful in order to improve the symbolization of the derived map, or to create automatic routing instructions for example. In this work, we define salient buildings as "buildings that are salient in their environment in real life, and which can be used to give some navigation indications". As a first step, we built a dataset of salient buildings. We selected a rectangle of 20x30km around the city of Nantes, France, as our study area to cover urban, semi urban and rural areas. For practical reasons we divided the area in 24 smaller rectangles (Figure 1). We retrieved the building vector data from the BD TOPO, the main geographic database produced by IGN, the French national mapping agency.

The protocol consisted in looking around the city within Google Earth. Out of the 300k polygons in our studied area, we annotated 1129 building polygons as salient (Figure 2).

Because the number of salient buildings is imbalanced compared to the total number of buildings, we keep all the salient buildings and randomly select some non-salient buildings to create our training dataset.

Then, for each polygon of the training dataset, we extract an image of Plan IGN (a topographic multi-scale map) which shows the surroundings of the buildings, with the building at the center of the image (Figure 3). Finally, we intend to adapt the multimodal deep learning architecture proposed by [START_REF] Rosenfelder | Multi-Input Deep Neural Networks with PyTorch-Lightning -Combine Image and Tabular Data[END_REF]. Originally designed for predicting housing prices using tabular data (e.g., house location, number of rooms) and corresponding house images, this model has demonstrated superior performance compared to models that rely solely on images, even with small datasets. Our goal is to train this adapted architecture on our dataset to predict whether a building is salient or not (Figure 4). We will compare the results with other machine learning models trained separately on tabular data only and images only to assess the effectiveness of such a multimodal architecture for classification problems. The feature we compute in the tabular data are the following: height, area, perimeter, nature and usage of the building, number of floors, number of housings, geometric granularity, geometry, shape index, mean height of the neighbours, mean area of the neighbours.

Based on the success of multimodal deep learning techniques in predicting housing prices and the potential of leveraging both tabular data and images for building saliency classification, we have strong indications that the results of our work will be highly promising. When it comes to classifying or segmenting cartographic data, we believe that multimodal models can overcome the current limitations of models only based on images or on tabular information.

Figure 1 .

 1 Figure 1. Studied area: the city of Nantes and its surroundings.

Figure 2 .

 2 Figure 2. Selected salient building during the database creation (left) and same building on Google Earth (right).

Figure 4 .

 4 Figure 4. Proposed adaptation of Rosenfelder's multimodal deep learning architecture for our classification problem. Figure 3. Sample of an input image from Plan IGN.

Figure 3 .

 3 Figure 4. Proposed adaptation of Rosenfelder's multimodal deep learning architecture for our classification problem. Figure 3. Sample of an input image from Plan IGN.


Ajay Shanbhag

Francois Grandpierron

Kathia Harrouche

Farid Medjdoub
email: farid.medjdoub@iemn.fr

Physical Insights of thin AlGaN Back Barrier for millimeter-wave high voltage AlN/GaN on SiC HEMTs

In the last two decades, many reports have shown the capability of Gallium Nitride (GaN) based high electron mobility transistors (HEMTs) to be used for high-frequency power applications [START_REF] Harrouche | High Performance and Highly Robust AlN/GaN HEMTs for Millimeter-Wave Operation[END_REF][START_REF] Moon | W-Band Graded-Channel GaN HEMTs With Record 45 % Power-Added-Efficiency at 94 GHz[END_REF][START_REF] Akso | First Demonstration of Four-Finger N-polar GaN HEMT Exhibiting Record 712-mW Output Power With[END_REF][START_REF] Moon | 360 GHz fMAX Graded-Channel AlGaN/GaN HEMTs for mmW Low-Noise Applications[END_REF][START_REF] Zhou | High-Efficiency Millimeter-Wave Enhancement-Mode Ultrathin-Barrier AlGaN/GaN Fin-HEMT for Low-Voltage Terminal Applications[END_REF][START_REF] Li | Record RF Power Performance at 94 GHz From Millimeter-Wave N-Polar GaN-on-Sapphire Deep-Recess HEMTs[END_REF][START_REF] Micovic | High frequency GaN HEMTs for RF MMIC applications[END_REF][START_REF] Wienecke | N-Polar Deep Recess MISHEMTs With Record 2.9 W/mm at 94 GHz[END_REF][START_REF] Marti | 94-GHz Large-Signal Operation of AlInN/GaN High-Electron-Mobility Transistors on Silicon With Regrown Ohmic Contacts[END_REF][START_REF] Romanczyk | W-Band Power Performance of SiN-Passivated N-Polar GaN Deep Recess HEMTs[END_REF][START_REF] Bahat-Treidel | Al-GaN/GaN/GaN:C Back-Barrier HFETs With Breakdown Voltage of Over 1 kV and Low RON × A[END_REF][START_REF] Santi | Role of carbon in dynamic effects and reliability of 0.15 um AlGaN/GaN HEMTs for RF power amplifiers[END_REF][START_REF] Gao | Deep level effects and degradation of 0.15 m RF Al-GaN/GaN HEMTs with Mono-layer and Bi-layer AlGaN backbarrier[END_REF][START_REF] Gao | Impact of an AlGaN spike in the buffer in 0.15 µm AlGaN/GaN HEMTs during step stress[END_REF][START_REF] Carneiro | Low Trapping Effects and High Blocking Voltage in Sub-This is the author's peer reviewed[END_REF][START_REF] Moon | High-speed graded-channel AlGaN/GaN HEMTs with power added efficiency> 70% at 30 GHz[END_REF][START_REF] Marti | 150-GHz cutoff frequencies and 2-W/mm output power at 40 GHz in a millimeterwave AlGaN/GaN HEMT technology on silicon[END_REF][START_REF] Zhang | Millimeter-wave AlGaN/GaN HEMTs with 43.6% power-added-efficiency at 40 GHz fabricated by atomic layer etching gate recess[END_REF][START_REF] Moon | Power scaling of graded-channel GaN HEMTs with mini-field-plate T-gate and 156 GHz f T[END_REF][START_REF] Romanczyk | Evaluation of linearity at 30 GHz for N-polar GaN deep recess transistors with 10.3 W/mm of output power and 47.4% PAE[END_REF] . In addition, it has been shown that replacing the AlGaN barrier layer with a sub-10 nm AlN barrier can be a potential candidate for millimeter-wave applications due to the availability of higher carrier concentration in the 2-dimensional electron gas (2-DEG) while employing ultra-thin barriers [START_REF] Harrouche | High Performance and Highly Robust AlN/GaN HEMTs for Millimeter-Wave Operation[END_REF] . Hence, AlN/GaN HEMTs with short gate lengths demonstrated state-of-the-art highfrequency power performance [START_REF] Hickman | First RF Power Operation of AlN/GaN/AlN HEMTs With >3 A/mm and 3 W/mm at 10 GHz[END_REF][START_REF] Medjdoub | High-Performance Low-Leakage-Current AlN/GaN HEMTs Grown on Silicon Substrate[END_REF][START_REF] Chabak | High-Performance AlN/GaN HEMTs on Sapphire Substrate With an Oxidized Gate Insulator[END_REF] . However, these applications demand highly robust GaN devices under high bias (e.g. high electric field) while the gate length is shrunk. This, in turn, leads generally to poor electron confinement and high electron trapping due to the large peak electric field. Thus, highly scaled GaN transistors suffer from various secondary effects such as drain-induced barrier lowering (DIBL), current collapse (CC), and self-heating when operated under high drain voltages [START_REF] Harrouche | High Performance and Highly Robust AlN/GaN HEMTs for Millimeter-Wave Operation[END_REF] . Hence, it is necessary to engineer the epitaxial structure and materials to obtain the best performance from the device [START_REF] Harrouche | High Performance and Highly Robust AlN/GaN HEMTs for Millimeter-Wave Operation[END_REF][START_REF] Harrouche | Low Trapping Effects and High Electron Confinement in Short AlN/GaN-On-SiC HEMTs by Means of a Thin Al-GaN Back Barrier[END_REF][START_REF] Shanbhag | Optimized Buffer Stack with Carbon-Doping for Performance Improvement of GaN HEMTs[END_REF] . To address this issue, many new structures have been proposed such as carbon-doped (C-doped) GaN buffer [START_REF] Harrouche | High Performance and Highly Robust AlN/GaN HEMTs for Millimeter-Wave Operation[END_REF][START_REF] Shanbhag | Optimized Buffer Stack with Carbon-Doping for Performance Improvement of GaN HEMTs[END_REF][START_REF] Harrouche | High Power AlN/GaN HEMTs with record power-added-efficiency >70 % at 40 GHz[END_REF] , graded channel HEMTs 2,27,28 , AlGaN back barrier [START_REF] Harrouche | Low Trapping Effects and High Electron Confinement in Short AlN/GaN-On-SiC HEMTs by Means of a Thin Al-GaN Back Barrier[END_REF][START_REF] Medjdoub | Effects of AlGaN back barrier on AlN/GaN-on-silicon high-electron-mobility transistors[END_REF] , and N-polar HEMTs [START_REF] Akso | First Demonstration of Four-Finger N-polar GaN HEMT Exhibiting Record 712-mW Output Power With[END_REF][START_REF] Li | Record RF Power Performance at 94 GHz From Millimeter-Wave N-Polar GaN-on-Sapphire Deep-Recess HEMTs[END_REF][START_REF] Wienecke | N-Polar Deep Recess MISHEMTs With Record 2.9 W/mm at 94 GHz[END_REF] . However, each of these designs comes with its own advantages and drawbacks [START_REF] Moon | W-Band Graded-Channel GaN HEMTs With Record 45 % Power-Added-Efficiency at 94 GHz[END_REF][START_REF] Akso | First Demonstration of Four-Finger N-polar GaN HEMT Exhibiting Record 712-mW Output Power With[END_REF][START_REF] Zhou | High-Efficiency Millimeter-Wave Enhancement-Mode Ultrathin-Barrier AlGaN/GaN Fin-HEMT for Low-Voltage Terminal Applications[END_REF][START_REF] Li | Record RF Power Performance at 94 GHz From Millimeter-Wave N-Polar GaN-on-Sapphire Deep-Recess HEMTs[END_REF] . The most critical issue in all these structures is the limited voltage operation of the short GaN transistors. In this work, we address this issue and show that using a thin AlGaN back barrier layer combined with a C-doped GaN buffer can overcome most of the drawbacks and can be an attractive choice for high-frequency applications with increased voltage operation. We have used TCAD to understand the underlying physical mechanisms improving the device's performance.

In this letter, AlN/GaN HEMTs are fabricated on three different buffer configurations grown on top of a 100 nm AlN nucleation layer using the metal-organic chemical vapor deposition (MOCVD) technique on 4-inch SiC substrates. All three structures have a 150 nm undoped GaN channel with a 3 nm AlN barrier. The device fabrication details are given in [START_REF] Harrouche | High Performance and Highly Robust AlN/GaN HEMTs for Millimeter-Wave Operation[END_REF][START_REF] Harrouche | Low Trapping Effects and High Electron Confinement in Short AlN/GaN-On-SiC HEMTs by Means of a Thin Al-GaN Back Barrier[END_REF] and the cross-sections are shown in Fig. 1(a), (b), and (c). Device D-1 has a C-doped GaN buffer with a doping concentration of 2×10 19 cm -3 while devices D-2 and D-3 have a 100 nm thick AlGaN back barrier layer (BB) with an Al mole fraction of 10% and 25%, respectively followed by a Cdoped GaN buffer of 5×10 18 cm -3 . The AlGaN back barrier has been kept intentionally thin in order to prevent thermal dissipation degradation, especially when using high Alcontent [START_REF] Tsao | Ultrawide-bandgap semiconductors: research opportunities and challenges[END_REF] .The structures are passivated with a 6 nm in situ SiN layer. The gate is defined using e-beam lithography with a length of 100 nm, gate-drain and gate-source distances of 500 nm, and a gate width of 50 µm.

Fig. 1(d), (e), and (f) show the DC characteristic comparison of the three devices. We have used Silvaco Atlas [START_REF] Silvaco | Atlas device user guide[END_REF] to calibrate these devices in the TCAD framework. We have used the inbuilt polarization model to account for the polarization charges at the interfaces. The drift-diffusion equations are solved numerically using the physical models such as doping and high field dependent mobility models [START_REF] Caughey | Carrier mobilities in silicon empirically related to doping and field[END_REF] , thermionic emission, Shockley-Read-Hall (SRH) recombination, and Fermi statistics. As can be seen in Fig. 1 This is the author's peer reviewed, accepted manuscript. However, the online version of record will be different from this version once it has been copyedited and typeset. ibration is obtained both in ON-state and OFF-state. Fig. 2 shows the experimental and TCAD results of the transfer characteristics at different drain voltages (V DS ) with compliance set at 150 mA/mm. We can see a shift in the threshold voltage as V DS increases, reflecting the DIBL. As seen from Fig. 2(a), (b), and (c) the DIBL is quite large in device D-2, while D-1 and D-3 show an excellent DIBL well below 100 mV/V. To understand this more in-depth, we have simulated the punchthrough leakage current under OFF-state with a gate-source voltage (V GS ) at -6 V while the V DS is fixed at 20 V as shown in Fig. 2(d), (e), and (f). We observe a significant amount of current flowing through D-2 even under pinch-off conditions as shown in Fig. 2(e). In this case, the back polarization related to the 10% Al content BB is not sufficient to ensure proper electron confinement under such a high electric field, which yields high DIBL. However, in the case of D-1 and D-3, the punch-through leakage current is negligible as shown in Fig. 2(d) and (f). Hence, using a C-doped GaN buffer of 2×10 19 cm -3 or 25% Al content AlGaN back barrier 150 nm away from the 2-DEG is suitable to provide proper electron confinement under a high electric field. C-doped GaN acts as a p-type causing a field opposite to the applied drain field [START_REF] Uren | Intentionally Carbon-Doped AlGaN/GaN HEMTs: Necessity for Vertical Leakage Paths[END_REF][START_REF] Uren | Buffer Design to Minimize Current Collapse in GaN/AlGaN HFETs[END_REF] . Thus, in the case of D-1, the C-doped GaN layer can prevent field penetration towards the source side, resulting in low DIBL. In the case of D-3, the 25% AlGaN back barrier generates an internal electric field due to the polarization nature of these materials. This internal electric field is in the opposite direction to the applied drain field and consequently prevents the electric field from the drain to affect the source side, resulting also in low DIBL. However, DIBL is not the only factor to be optimized for high-frequency operation. Minimum trapping effects need to be ensured and high breakdown voltages to achieve a high operating voltage device at high frequency.

PLEASE CITE THIS ARTICLE AS

To assess the trapping effects, pulsed DC characterizations using various quiescent bias points have been carried out. Fig. 3(a) and(b) show the pulsed open channel output drain current characteristics of D-1 and D-3, respectively under cold, gate-lag (V GS = -6 V, V DS = 0 V ) and drain-lag (V GS = -6 V, V DS = 20 V) conditions. A significant current collapse is observed in D-1, which is substantially lower in the case of D-3 though in both devices the undoped channel is 150 nm thick. This suggests that the electron trapping is due to the C-doped GaN buffer, which has not only a much higher carbon concentration in D-1 than in D-3 but also is closer to the 2DEG. Furthermore, Table I shows simulations performed on a device similar to the epitaxial structure of D-3 but with various carbon concentrations in GaN buffer. Current collapse, DIBL, and breakdown are thus compared with respect to the different channel thickness / C-doping combinations. It is observed that for an undoped channel thickness of 150 nm, increasing the carbon concentration in the GaN buffer plays no significant role. This implies that the field generated due to the back polarization is sufficient enough to oppose the field due to applied bias, preventing the capture of electrons from the 2-DEG by the deep carbon acceptor traps. Moreover, as we know the current collapse is due to the negative potential developed under pulsing conditions [START_REF] Shanbhag | Compact Modeling of Static and Transient Effects of Buffer Traps in GaN HEMTs[END_REF] , Fig. 3 (c) and (d) show the potential profile within the devices D-1 and D-3. It is clearly visible that the magnitude of the negative potential developed in the case of D-1 in the GaN buffer is much larger than D-3. Fig. 3(e) and (f) show the vector electric field distribution of D-1 and D-3 in OFF-state (V GS = -6 V) with V DS = 20 V. We can clearly see that the electric field under bias within the GaN buffer is affected, which is reflected by the bent vector lines within the GaN buffer. This indicates that the electric field can penetrate inside the GaN buffer thereby resulting in hot electrons generated under operational conditions that can be trapped. That is why, a C-doped GaN buffer can provide proper field confinement resulting in low DIBL, but high current collapse. However, in the case of D-3, the field lines are all directed upwards due to the presence of the in-built polarization of 25% AlGaN back-barrier. The back barrier confines the electric field and thus prevents its penetration inside the GaN buffer. This results in a reduced current collapse in the case of D-3 up to an extended level of energy as compared to more standard short GaN transistors. Therefore, a thin Al-GaN (25% Al) can provide proper electron confinement while preventing the electric field penetration inside the GaN buffer, resulting in both low DIBL and reduced current collapse. Fig. 4 shows experimental results of continuous-wave (CW) and pulsed large-signal measurements at 40 GHz and V DS = 20 V performed on D-1 and D-2 devices using a nonlinear vector network analyzer. Details of the power bench used for these measurements can be found here [START_REF] Kabouche | Power Measurement Setup for On-Wafer Large Signal Characterization Up to Q-Band[END_REF] . An outstanding power-added efficiency (PAE) is achieved in both This is the author's peer reviewed, accepted manuscript. However, the online version of record will be different from this version once it has been copyedited and typeset. devices along with a high output power density (P OUT ). In addition, the gain of both devices is quite similar for a high range of injected power (P inj ). However, Fig. 4 Another aspect of high-voltage and high-frequency devices is the breakdown voltage (BV). The measured OFF-state breakdown voltage (drain voltage corresponding to drain current = 1mA/mm) of D-1 and D-3 is 56 V and 60 V respectively as shown in Fig. 4(c). To make the devices more robust, we need to ensure higher BV, which is generally at the expense of trapping effects. Hence, an optimum channel thickness is required to overcome this trade-off. TCAD simulations with reduced channel thickness down to 100 nm and repeating the variation of carbon concentration in the buffer are shown in Table I. As previously described, significant BV improvement of the devices with a reduction in channel thickness is observed. Additionally, a reasonable current collapse penalty is revealed with an increase of only 6%. However, the channel thickness reduction to 100 nm on a device without an AlGaN back-barrier (similar to D-1) results in a current collapse drastically increased to nearly 40% with a BV close to 120 V as shown in Table II. This BV can be achieved using a 100 nm undoped GaN channel followed by a 25% AlGaN back-barrier with C-doped GaN buffer with a carbon concentration of 2×10 19 cm -3 . Fig. 5 shows a benchmark of the results with the proposed structure in comparison to other structures in the millimeter-wave range. This is the author's peer reviewed, accepted manuscript. However, the online version of record will be different from this version once it has been copyedited and typeset. The performances from the proposed structure are favorably comparable to state-of-the-art GaN HEMTs. In particular, a PAE > 65% combined with a P OUT > 3 W can be achieved.

PLEASE CITE THIS ARTICLE AS

PLEASE CITE THIS ARTICLE AS

We demonstrate that a 25% C-doped thin AlGaN back barrier can be an attractive choice to achieve both high electron confinement and reduced trapping effects in short GaN HEMTs. TCAD simulations have shown that the back barrier helps prevent punch-through leakage current and field penetration through the buffer layers. The Al-content into the back-barrier needs to be sufficiently high to generate a proper back polarization that prevents electric field penetration under high bias while reducing the current collapse. The breakdown voltage of the devices can be enhanced by reducing the undoped channel thickness. However, in the case of the absence of a back-barrier, although proper electron confinement can be also achieved, a high current collapse is observed, which is not suitable for power applications. Therefore, we can infer that this device design approach including a 25% thin AlGaN back-barrier can be an optimum choice for high voltage mm-wave applications.

The proposed work was performed under the Raman-Charpak fellowship program partially funded by CEFIPRA and DST as well as the national program LABEX GANEX (ANR-11-LABX-0014) and the French Defense Procurement Agency (DGA) under the project called GREAT. The authors would also like to acknowledge the company SOITEC for high material quality delivery and the support of the French RENATECH network.

  FIG. 1. Cross-sectional view of devices: (a) D-1, (b) D-2, and (c) D-3. Transfer characteristics and transconductance at V DS = 10 V (Experiment vs TCAD) of: (d) D-1, (e) D-2, and (f) D-3 respectively.

FIG. 3 .

 3 FIG. 3. Pulsed drain current characteristics of: (a) D-1, and (b) D-3. Potential profile using TCAD under pulsed conditions for: (c) D-1, and (d) D-3. TCAD electric field vector distribution (V GS = -6 V and V DS = 20 V) for: (e) D-1, and (f) D-3.

  (a) shows a large change between CW and pulsed power performance metrics of D-1 unlike D-3 transistors (see Fig.4(b)) delivering much closer CW / pulsed power performance. This is clearly due to high trapping effects in D-1, which are significantly lower in D-3. This translates the benefit of achieving enhanced electron confinement enabling high-voltage operation together with low trapping effects to achieve superior millimeter-wave large signal characteristics.

  FIG. 5. PAE vs V DS benchmark of GaN HEMTs in the millimeterwave band.

TABLE I .

 I Physical Insights of thin AlGaN Back Barrier for millimeter-wave high voltage AlN/GaN on SiC HEMTs 3 TCAD simulated performance metrics with 25% AlGaN back-barrier with varying GaN channel thickness, and GaN buffer carbon concentration.

	Buffer C concentration (cm -3 )	5×10 18	2×10 19	5×10 18	2×10 19
	GaN channel thickness (nm)	150	150	100	100
	DIBL (mV/V)	30	28	27	25
	Current Collapse (%)	11.8	14	18.5	19.1
	Breakdown Voltage (V)	56	60	103	120
	TABLE II. TCAD simulated performance metrics without 25% Al-
	GaN back-barrier by varying GaN channel thickness.
	Buffer C concentration (cm -3 )	2×10 19	2×10 19
	GaN channel thickness (nm)	150	100
	DIBL (mV/V)	30	20
	Current Collapse (%)	22	40
	Breakdown Voltage (V)	58	120

DOI: 10.1063/5.0168918

This is the author's peer reviewed, accepted manuscript. However, the online version of record will be different from this version once it has been copyedited and typeset.PLEASE CITE THIS ARTICLE AS DOI: 10.1063/5.0168918

The authors have no conflicts to disclose.

The data supporting this study's findings are available from the corresponding authors upon reasonable request.


Vlad Nicolicin-Georgescu

Vincent Benatier

Rémi Lehn

Henri Briand

Vlad Nicolicin Georgescu
email: vladgeorgescun@sp2.fr

Remi Lehn

An Ontology-Based Autonomic System for Improving Data Warehouses by Cache Allocation Management

published or not. The documents may come

Introduction

Decision Support Systems are defined as computerized systems whose main goal is to analyze a series of facts and give various propositions for actions regarding the facts involved [Druzdel and Flynn (1999)]. The process of decision making in enterprises based on such systems is also known as Business Intelligence. This concept is very well applied by large enterprises. Via this process, they specifically focus on their data warehouse efforts. The problem is that data warehouses usually become fast very large and complex, thus their performances become rapidly an issue. This is why between 70 and 90% [Frolick and Lindsey (2003)] of the enterprises consider that their data warehouse efforts is inefficient, as in many cases, the large amount of data involved becomes unusable. In many of these cases, the cause is bad management or costs that are too high to sustain.

One of the main problems that lead to this is common resource sharing between data warehouses. The resources are usually limited either by financial costs or by architectural considerations. Consider the following real example, to emphasize the problematic. An enterprise has a special server for its data warehouses. In total, a group of 50 data warehouses that share the same RAM memory is deployed on this server. Each of the data warehouse requires at least 20 GB of RAM to have good performances (i.e. the query average time is under a second). So there is a need for at least 1TB of RAM (ignoring all other RAM requirements of the server). First, the costs of having 1TB of RAM on server are financially high (~ 40000 EUR 1 ). Second, if the enterprise is ready to cover these costs, suppose the server has an architecture that enables a maximum of 16GB to be installed. Also the migration of some data warehouses on another server would be too expensive and too complicated. An option is to compromise, asking each time an expert to re-configure the memory allocation for each of the data warehouse. In a short time after this is done, with the evolution of the data warehouses' size or if new data warehouses are added or some become obsolete, the problem reappears and the same action must be taken, over and over again.

Based on the example above we can intuitively see a simple solution: enable autonomic tasks that reconfigure the memory allocations, instead of asking a human expert each time to intervene (human resources are the most expensive, and not always provide the optimal results). This is easy to be said but it is hard to formalize, due to two main issues.

First, how to formally represent the group of data warehouses along with the knowledge involved in the decisions and actions of the expert? To do this, we differentiated three main types of information that needs to be formalized: a) architectural information (how a group of data warehouse is organized, the number of groups, how are they linked, etc.); b) configuration and performance information (how much memory each data warehouse needs, what performance is achieved with this allocation, etc.); and c) experience information that represents best practices and advices for the memory allocations (coming from editor documents, human experience, etc.). We present in this paper a formalization of the three types into a unified knowledge base, using ontologies [Gruber (1992)] and ontology based rules [Stojanovic et al.(2004)].

Second, having the information formalized, we need an organized form of rendering the autonomic process. To this end, IBM proposes a solution called Autonomic Computing [IBM (2001)]. It consists in the division of the actions that are taken when trying to provide autonomy to a process, corresponding to objective-specific phases and states. Autonomic concepts can be integrated in hierarchical organized systems, so each higher level aggregates what has been done to its sub levels. There are numerous autonomic computing based works that relate especially to problem resolution [Manoel et al.(2005)] or system administration [Barret et al.(2004)]. On the other hand, little has been done on data warehouse improvement.

So, we propose to use autonomic computing on the unified formalized knowledge base. Specifically, we treat a common configuration problem: cache memory allocation for a group of data warehouses (that share the same amount of common available RAM memory). The objective is to reach a better performance (in terms of query response times when extracting data from the data warehouse) with lower costs. The implication is that by increasing the amount of cached data, there are better chances that a request hits the cache; the response times in order to extract the data decrease, which translates in better performances. But, the whole amount of data obviously can't be put in the cache, and then we need a way to automatically determine and adjust the cache parameters.

Section 2 presents a view of data warehouse management through caches in the context of decision support systems. It presents the information that needs to be manipulated and how the division of this information can lead to a unified knowledge base representation. Section 3 presents how autonomic computing is used with managing data warehouse through caches. It presents how the knowledge base is integrated to permit autonomic tasks. It equally proposes two heuristics for cache allocation, based on the problematic described. Section 4 shows how we integrate the elements together using ontologies for the knowledge base representation and ontology based rules for the autonomic process. We provide some results obtained with our approach. In the conclusion we sum the work presented giving future directions and hoping that our work could help enterprises with their data warehouse efforts.

Data Warehouse and Cache Allocations

First of all, when speaking of data warehouse we usually make reference to a definition as a repository of an organization's electronically stored data and is designed to facilitate reporting and analysis [Inmon (2005)]. Managing a data warehouse includes the process of analyzing, extracting, transforming and loading data and metadata. As decisional experts, we know that once data warehouses are put in place, enterprises then base their decisions on the data that is stored within them. So a good organization in start and a good performance in time are the requirements of data warehousing.

We do not put into question the initial organization. We observed that in time data warehouse performances are constantly degrading up to a point where the system is no longer usable. One aspect of data warehouse performance is strongly related to the operation of data extraction which in turn depends on the query response times on the data. Obviously, the larger a data warehouse is, the more information it contains so we expect to have higher response times. Considering that some information is often more demanded than other, data warehouse management systems offer the possibility of keeping frequently accessed data in cache memories with the hypothesis that fetching data from the cache is greatly faster than fetching them from the persistent storage media. The problem occurs when confronted with groups of data warehouse on the same machine that share the same amount of memory. In decision support systems, such groups contain data of up to several thousand gigabytes. They cannot be all put into the cache, so solutions are required.

Although the problematic of performance improvement in data warehouses throughout caches is debated [Malik et al.(2008)], [Saharia and Babad (2000)] the issue is always addressed either through the physical design or the design of algorithms to determine which information is likely to be stored in cache memories. These solutions apply well when we focus on a single data warehouse.

So, what actually happens in enterprises is that the initial cache allocations remain the same throughout time. Whereas the quantity of data in the data warehouse increases, some of them are no longer used; there are new data warehouses that are constructed etc. Therefore there is a need for a dynamic system.

The first aspect of the system we propose and that we approach is knowledge formalization. In the example presented in the introduction, the expert in order to reallocate the memory makes use of several types of information.

We propose to divide this information into three main types, detailing and exemplifying based on the Hyperion Essbase2 business intelligence solution.

Architectural information corresponds to the organization of the groups of data warehouse. Figure 1 shows an example of a possible organization.

Figure 1 -Architectural organization for groups of data

warehouse Based on a decision support system simple organization, we can distinguish on top of the tree a Physical Server as the actual machine. Underneath, there are a number of Applications installed that share the RAM memory available on the server. And, in turn each application contains one or more data warehouses (Essbase cubes or bases), sharing the same memory. Each application is seen as a group of data warehouses, and then memory reallocation is done within each application.

Configuration and performance information contains all the indicators that reflect the actual characteristics and configuration of the data warehouses and the performances obtained with this configuration. For the characteristics and configuration we refer to the Essbase cubes. There are many characteristics, but for our example we take into consideration the following indicators:

• The size of each data warehouse represented by: the Index File size and the Data File size. This corresponds to the actual size that each data warehouse is occupying on a hard disk. A value of tens of GB for the two together is a frequently met characteristic. • The values of three types of caches: Index, DataFile and Data Cache. Corresponding to the sizes presented before, they represent a percentage of the actual data files that can be kept in cache. Ideally, we should have the total of index file size in the index cache, and the total of data file size in the data and data file cache. For the performance aspect, there are many indicators to take into consideration such as: query response times, calculation times, aggregation operation times, etc. We chose the query response time as a performance indicator as this is a frequently used measure [Saharia and Babad (2000)] of the system performance, and, it directly reflects the quality of the user experience in the decision system. It represents the time needed to extract data through a query from the data warehouse.

Experience and best practices information represent a more delicate subject in comparison with the first two information types. The main reason is that it comes from several different sources. Therefore the challenge is how to combine these sources into a single unified knowledge base. For instance, how to combine practices taken from an Essbase support document with practices that are part of the human experience and that are only known by the expert. We present here the formalization aspect, that is revised and validated by a human expert. In order to formalize the experience and best practices, we have found a completely different approach to knowledge representation, which is the rule based representation. Basically, we translate the pieces of advice and best practices into Event Condition Action (ECA [Huebscher and McCann (2008)]) rules. Such rules are often associated with business intelligence practices, and integrating different rules at different timelines (via the autonomic aspect) proved to be a good choice for our proposition. ECA rules have certain drawbacks, such as it is hard to prove the coherence and the no contradiction. But for the rules in our system, this aspect is not currently an issue.

Driving the data warehouse -Autonomic Computing

Once the principal knowledge types are well separated and formalized, they have to be 'put to life'. We refer of course at the second aspect of the improvement system: rendering it autonomic. Autonomic systems have been present within our everyday lives. A very intuitive example of an autonomic system that manages itself is the human body. Reflexes like breathing, digestion, heart pulsation etc. are part of the autonomy the human body provides (we don't control these we just know they are continually present and moreover they function). Starting from this idea, the first approaches were especially towards self-healing systems, the survey of [Ghosh et al.(2007) From this to applying autonomic computing to enable improvement in IT infrastructures was just a small step. The subject proved to be of great interest to enterprises. Works have been done in this area and put into practice for improving database performance by IBM [Markl et al.(2003)], [Lightstone et al.(2002)] and Microsoft [Mateen et al.(2008)]. IBM specifications link autonomic computing with the notion of autonomic manager as the entity that coordinates the activity of the autonomic process. An autonomic manager (ACM) is an implementation that automates the self-management function and externalizes this function according to the behavior defined by management interfaces. The autonomic manager is a component that implements an intelligent control loop. For a system component to be self-managing, it must have an automated method to collect the details it needs from the system (Monitor); to analyze those details to determine if something needs to change (Analyze); to create a plan, or sequence of actions, that specifies the necessary changes (Plan); and to perform those actions (Execute) [IBM (2001)]. Similar alternatives to autonomic computing were made in real BI [Nguyen et al.(2005)] but the idea is the same: to be able to analyze and improve (in our case) a given system through a closed loop that differentiates a series of states.

We propose the usage of autonomic managers to enable data warehouse self-improvement. Figure 2 shows the transformation of the architecture from Figure 1, with the implementation of autonomic managers on each of the entities (or component of the architecture) involved.

Figure 2 -Autonomic Computing Managers on each of

the architectural levels We notice that each of the entities has its own individual loop. The autonomic managers communicate only with the ones from the superior levels, and not between the same level. This way, each entity has two responsibilities: one strictly related to its individual self management and the other related to the management of its descendants. The idea is that the two can function independently of each other. For instance, consider an Application that has 2GB of RAM allocated to its data warehouses. So each data warehouse uses the allocated RAM and self-improves itself with what it has. Now suppose that at a certain point the Application receives another 1GB of RAM. If the new information is not integrated then the data warehouses continue to function with the already allocated 2GB. Once the application runs the management of its descendants, a reallocation of the memory is done also for the data warehouses. In order to simulate the two behaviors, we have elaborated two heuristics.

Data warehouse Self-improvement heuristic

This concerns only the individual loop at a data warehouse level. Its role is to describe how cache allocations vary with the query response times. The idea is the following: starting from a given maximal cache configuration we try to decrease the values of the caches and study the impact this decrease has on the data warehouse query response times. The algorithm stops when the difference between the current and the last average query response time is greater than a specified threshold. This is done independently for each data warehouse. So, we define two parameters for this heuristics:

Step -represents the amount with which each cache value is decreased. The following formula shows how a cache value modifies with step:

CV 1 = CV 0 -(CV max -CV 0 )*step where CV 0 represents the old cache value, CV 1 the new calculated value and CV max the maximum possible value . A frequent value of step we used in our experiments was 10% based on the recommendation of our human experts.

Delta -represents the threshold accepted for the difference between the current and the last average response time. It can be seen as the accepted impact that a cache modification has. If (RT 1 -RT 0 )/RT 0 < delta then we accept the new cache proposition (where RT = average response time for the respective data warehouse). A frequent value we used for delta was 5%, based on our clients' average performance acceptance specification (i.e. for a value of x, an fluctuation in performance with 5% is accepted). Table 1 illustrates the self-improvement heuristics with a timeline, based on the autonomic manager loop phases. At t 0 we have the initial configuration. At t 1 we have made the first cache adjustment, and validated it. At t 2 , the second cache modification has an impact too great on the response time so we leave the cache value as it is.

Group of data warehouses cache reallocation heuristic

The first heuristics was individual data warehouse based. Each of the data warehouses was independent and each was in a state of self-improvement in time. But, taking it into consideration alone makes no sense as the performances on individual data warehouses are expected to decrease as the caches decrease. To explain how it results in an actual improvement at group level, we introduce the group of data warehouses heuristic. Its purpose is to reallocate periodically the memory that the individual data warehouse heuristics saved from the self-improvement process. And it is here where the 'catch' is: by a small sacrifice (delta) of some data warehouses, we can gain an important performance on others. The core of the heuristic is to differentiate the non performing from the performing data warehouses in a group. The idea is the following: a data warehouse is considered performing if its average response time is below the average value of the response time for the whole group. Otherwise, it is considered as non-performing. This performance indicator can be equally made more complex by taking into account the applications priority or importance. This way scaled mixed performance indicators can be obtained and used. The specification of priorities and importance is usually part of Service License Agreements and is one of the future directions in our work.

So in this case, we take the memory from the performing data warehouse and give it to the non-performing. Relating with the architecture in Figure 1, the Application level is responsible for the implementation of this heuristic. The Application decides how to redistribute the memory between the data warehouses it concerns.

Table 2 shows this heuristics. The example is based on a group of two data warehouses that are part of the same application and share the same amount of memory for their caches. In start at s 0 we have a given cache allocation along with the available memory for each data warehouse. At s 1 the heuristic is run the first time. It takes all the available memory from the performing data warehouse (DW1) and redistributes it to the non performing (DW2). So DW2 gains all the free memory (20MB) from s 0 . As the differences in response times are still important, it goes further at s 2 . Here, it takes some memory from DW1 by force, leading to a decrease in performance for DW2. But as seen, we gain an important amount of performance for DW2, and now the response times for the two data warehouses are close.

It is important to note that this heuristic is independent from the previous one, and in addition the two heuristics are mutually exclusive. This means that in the moments when this heuristic is considered, the other does nothing. This is why between the two tables we differentiate between "Time" and "Step". An example of usage is to run the individual self-improvement heuristic once each day (from Tuesday to Friday), and the group reallocation heuristic once at the beginning of each weak (Monday).

Combining the elements

Having the two main aspects, knowledge formalization and autonomic capabilities, the final and innovative stage in our approach is to combine them. In order to do this we base on the preliminary works presented in [[Nicolicin-Georgescu et al.(2009)]]. The solution proposed the application of ontologies and ontology based rules (describing business rules) with autonomic computing for improving average query response times in data warehouse. The concept is the same, but in this previous work we only described how can simple businesses rules can be used to improve data warehouse performance. There is no indication to how heuristics are used within the autonomic manager loop.

System implementation

In previous works, we were proposing a division of the knowledge in the system into static knowledge and dynamic knowledge. Based on this organization we implement the new presented elements. The means of knowledge formalization do not change, static knowledge being implemented with the help of ontologies and OWL 3 whereas the dynamic aspect is expressed with ontology based rules via the Jena Rules 4 formalization. The ontology contains over 150 concepts and 250 axioms, whereas a number of 30 rules are based on it. From what we have presented, we focus on the dynamic aspect, as it includes the two heuristics projected on the phases of the autonomic computing.

The first step in order to understand how rules are organized is to understand how the autonomic managers on the different hierarchical levels communicate. As seen the group heuristic reallocates memory and excludes the individual heuristic. In order for the autonomic managers to communicate, we propose a hierarchy of the autonomic phases, corresponding to the architectural structure. Figure 3 show how the four phases of autonomic manager are projected on the architectural levels.

We notice how the monitor phases ascends, starting from the lowest level (data warehouse). This means that first the data regarding the data warehouses are gathered, then the application, and then the physical server. Then the analysis is made top down from the physical server to the data warehouse level. Retaking the memory allocation example, first the server allocates memory between its applications, then each application allocates in turn to its data warehouses etc. Then the planning stage ascends again, the changes are planned from the analysis level starting with the data warehouses and finishing with the physical server. Last, the execution phase makes changes top down similar to the analyze phase. A change in the RAM memory is first done to the physical server, then the applications receive the new memory and then the data warehouses change their memory (now possible because the memory has already been changed at application level). We exemplify below how the system is implemented on each of the four phases.

Monitor

For the monitor phase, in order to obtain the cache values and average response times, we use SQL data bases that are filled with the help of vbscripts via the api provided by Hyperion Essbase. Then, to transform and load this knowledge in the ontology, we pass via a java program using the Jena API and a set of correspondences that links the data from the SQLdbs to ontology concepts. Table 3 shows how some parts of how a data warehouse is represented in the ontology: We can see two classes, the DataWarehouse and the PhysicalApplication. Each of these classes consist from multiple instances as OWL individuals. The ?dw is one such individual that is linked to an ?app individual by the OWL object property isChildOf . This property establishes the hierarchical relations between individuals from the different hierarchical levels. Then, there are two OWL data type properties that are linked to the ?dw and express the current and previous average response time for ?dw. The values for these properties are filled from the SQL dbs that contains to the data warehouse monitor information.

Analyze

Once this phase of monitoring and pre-processing of information is done, the system passes to analyze. We present below two rules that formalize a cache decrease.

Rule

Description (?dw cp:hasPrevAvgResponseTime ?prevt) (?dw cp:hasAvgResponseTime ?avgt) (?dw cp:hasAlgorithm ?alg) (?alg cp:hasDelta ?delta) quotient(?t, ?avgt, ?prevt) le(?t, ?delta) -> (?dw cp:hasState cp:DecreaseCache) Validate a cache decrease via the individual heuristic (?dw cp:hasState cp:DecreaseCache) (?dw cp:hasIndexCacheMin ?ic_min) (?dw cp:hasIndexCache ?ic) (?dw cp:hasAlgorithm ?alg) (?alg cp:hasStep ?step) product(?p, ?ic, ?step) difference(?ic_new, ?ic, ?p) ge(?ic_new, ?ic_min) -> (?dw cp:hasIndexCache ?ic_new) If the decrease of cache is requested, test if the new value is not under the minimal value. If not enable the new change.

The first rule test to whether the cache values for a single data warehouse can be decreased, accordingly with the individual heuristic. We have again the ?dw individual, an instance of the DataWarehouse class, with the two data type properties from Table 4. In addition we have a new object property that related the ?dw with an the individual heuristic algorithm. The rule compares the rapport between the two average times (current and previous) with the delta of the algorithm. If the rapport is lower than delta, the ?dw becomes into a new state, in which it is allowed to decrease its cache. Otherwise, nothing changes.

The second rule makes use of the results of the first rule. If the DecreaseCache state has been generated by the first rule, then it tries to see whether or not the operation is possible. Two new data type properties are introduced for the ?dw: hasIndexCacheMin and hasIndexCache, which represent the values of the minimum threshold and the current value of the cubes index cache. These values are equally filled from the monitor phase. The rule retakes the individual heuristic algorithms' parameters (step this time) and tests if by modifying the index cache with its formula, the new index cache value is greater than the minimum one. If so, it changes directly the current index cache value to the newly computed one.

Plan and Execute

The plan and execute phases are linked to each other. As the new cache values are calculated, there is a preparation of VBscripts that will be run via the program. These scripts will change the values of the caches in the Essbase cubes, according to the new values proposed by the analyze phase. At the end of the execution phase, practically the inverse monitor operation of data processing is made. The cache values are passed from the ontology to the SQLdbs and then to the modification scripts.

Experimentation and Results

For our experiments we considered the following scenario: on an existing server, we created an Essbase application with two cubes. The cubes contain in average 11 principal axes and 27 level 2 axes and the data file has an average size of 300MB. With this configuration, we carried several tests, simulating a period of 14 days (time stamps period). Each time-stamp, a series of random queries (from a given set) was executed so that activity on the application was simulated. The individual data warehouse self improvement heuristic is running each day, whereas the group heuristic is running once each 4 days. Figure 4 shows the evolution of the response times for the two data warehouses with the evolution of their total cache allocation: First what we notice is that at the end of 5 days we already have a good ratio response time/cache allocation. The data warehouses improve themselves fast, and then once reaching a good point, they oscillate around this point. This oscillation is shown by the peaks on DW2 that tries each time to improve more its performances, but it can't due to the heuristic constraints in terms of delta. Their impact on the system is felt in terms of the performance drops the days where the peaks are noticed. By limiting the number of peaks (i.e. after one or two peaks the system should no longer try to optimize under the same circumstances) we avoid the risk of such drops. But, we also have to take into consideration that by limiting the number of peaks (by forcing the algorithm to stop for instance at a certain point) we risk to miss some needs of improvement due to reconfiguration aspects. The ideal would be to leave the heuristic running as usual and not to force the algorithm to stop, but not to accept the cache decreases once a certain level of performance is reached. One of the future directions and improvements is the introduction of attenuation mechanisms in the loop.

So, in numbers, at the end of the sixth day: DW1 looses very little in performances (~2%), DW2 gains substantial performances (~80%), and the total cache used by the application is decreased by ~60%. So the sacrifice of DW1 was worth from the perspective of the entire system. These results prove how an efficient way of improving the data warehouse group performances can be achieved in an autonomic manner, without the intervention of a human expert.

Conclusions

This article presented a way of using ontologies and autonomic computing for improving query response times in data warehouses groups by modifying cache memory allocations. It has presented this applied to the problematic of shared resource allocation in groups of data warehouses. Also, the article presented a proposition of replacing some of the human expert's work by introducing autonomic and human independent ways of managing data warehouses.

We have proposed a division and formalization of the knowledge used for configuring groups of data warehouses by using ontology and ontology based rules. Also, we have proposed an organization of this process based on the autonomic computing considerations. It is not the first attempt to combine the two [Stojanovic et al.(2004)], but the novelty is from using such techniques in the domain of decision support systems and especially in the groups of data warehouse improvement.

Our future directions are to expand the data warehouses described above so that our prototype can prove its efficiency on a larger spectrum of rules and indicators. Our purpose is to integrate the prototype presented here with more than one aspect (data warehouse cache allocations based on response times) of decision support systems. We also intend to approach the notions of Service License Agreement (SLA) and Quality of Service (QoS), by introducing the QoS as a performance indicator in the system. SLA considerations such as application priority and importance depending on utilization periods, are two aspects that are little approached and equally very important in a decision support system. Also in terms of autonomic loop control, we take into consideration the usage of mechanisms for avoiding peaks and unnecessary loop passages.

As the domain is relatively new we try to bring as much support as possible for future development in the direction of autonomic knowledge based decision support systems. We follow the changes with the new technologies and hope that our work will be useful in this expanding environment.

  ] summing up this evolution. And, as expected the concept developed, and in 2001, IBM proposed a formalization of the self-x factor by introducing the notion of Autonomic Computing (AC)[IBM (2001)]. Most of the IT organizations spend a lot of time reacting to problems that occur at the IT infrastructure component level. This prevents them from focusing on monitoring their systems and from being able to predict and prevent problems before end users are impacted[IBM (2005)]. Autonomic computing is the ability for an IT infrastructure to adapt and change in accordance with business policies and objectives. Quite simply, it is about freeing IT professionals to focus on highervalue tasks by making technology work smarter, with business rules guiding systems to be self-configuring, self-healing, self-optimizing and self-protecting[IBM (2001)].

Figure 3 -

 3 Autonomic Manager phases projection on the architectural levels 3 http://www.w3.org/2007/OWL/wiki/OWL_Working_Grou p 4 http://jena.sourceforge.net/inference/#rules

Figure 4 -

 4 Figure 4 -Average Response Time evolution with cache allocations Again, the objective is to obtain better average response times with lower cache values.First what we notice is that at the end of 5 days we already have a good ratio response time/cache allocation. The data warehouses improve themselves fast, and then once reaching a good point, they oscillate around this point. This oscillation is shown by the peaks on DW2 that tries each time to improve more its performances, but it can't due to the heuristic constraints

Table 1 -

 1 Individual Data Warehouse Self-Improvement Heuristics on the autonomic manager phases

	Time AML Phase	Action
	0	Monitor	step = 0.1, delta = 0.05, CV max =1GB
			CV 0 =500MB, RT 0 =5s
		Analyze	N(ot)/A(vailable)
		Plan	CV 1 =450MB
		Execute	Change script for DW with CV 1
	1	Monitor	CV 1 =450MB, RT 1 =5.2s
		Analyze	(RT 1 -RT 0 )/RT 0 =0.04 < delta
		Plan	CV 2 =395MB
		Execute	Change script for DW with CV 2
	2	Monitor	CV 2 =395MB, RT 2 =6s
		Analyze	(RT 2 -RT 1 )/RT 1 =0.15 > delta
		Plan	CV 3 =395MB
		Execute	No change for DW

Table 2 -

 2 Group of Data Warehouse Improvement Heuristic -Cache Evolution Exemple

	Step DW	Cache	Memory to	Free	RT
			Value	allocate	Memory
	0	DW1 130 MB	140 MB	10 MB	5s
		DW2 80 MB	90 MB	10 MB	7s
	1	DW1 130 MB	130 MB	0 MB	5s
		DW2 100 MB	100 MB	0 MB	6s
	2	DW1 120 MB	120 MB	0 MB	5.3s
		DW2 110 MB	110 MB	0 MB	5.5s

Table 3 -

 3 Data Warehouse ontology representation

	Subject	Predicate	Object
	?dw	rdf:type	DataWarehouse
	?app	rdf:type	PhysicalApplication
	?dw	isChildOf	?app
	?dw	hasAvgResponseTime	?avgt
	?dw	hasPrevAvgResponseTime	?prevt

http://download.oracle.com/docs/cd/E10530_01/doc/epm.9

31/html_esb_dbag/frameset.htm?dstcache.htm