Azhar Ait Ouassarah
email: aaitouassarah@axway.com

Xavier Fournet
email: xfournet@axway.com

Romain Revol
email: rrevol@axway.com

Nicolas Averseng
email: naverseng@axway.com

Jean-Marc Petit
email: jean-marc.petit@insa-lyon.fr

Vasile-Marian Scuturici
email: vasile-marian.scuturici@insa-lyon.fr

Bi-temporal Query Optimization Techniques in Decision Insight

Keywords: H.4 [Information Systems]: Data management systems-Data model extensions, Temporal data Business activity monitoring, temporal databases, temporal query optimization Historical data, real-time data, materialized views, data reduction

La complexité de l'environnement dynamique dans lequel évoluent les entreprises requiert de la part de leurs managers de prendre des décisions pertinente en un laps de temps très court. Les systèmes de supervision des activités métiers devraient supporter des requêtes bitemporelles complexes qui accèdent aussi bien à des données historiques qu'à des données temps réel afin de détecter des anomalies ou bien des tendances dans l'activité de l'entreprise. Cependant, il s'avère que l'accès à ces deux types de données peut être lent, ce qui ne convient pas aux applications de supervision. Dans ce papier, nous présentons Decision Insight, une plateforme développée par un éditeur de logiciels français pour aborder ce problème. Elle est basée sur un SGBD orienté colonnes qui redéfinit les requêtes bi-temporelles en: 1) un ensemble de requêtes continues pour gérer les données temps réel et dont les résultats sont matérialisés, et 2) une requête qui accède aussi bien aux données historiques qu'aux résultats des requêtes continues. Nous démontrons l'intérêt de notre approche en utilisant une version adaptée du benchmark TPC-BiH qui est une extension bitemporelle du benchmark TPC-H.

INTRODUCTION

Companies operate in very dynamic and complex environments, requiring their managers to possess both agility and ability to make proactive operational decisions, in order to maintain or improve their business [START_REF] Mccoy | Business activity monitoring: Calm before the storm[END_REF]. On the one hand, exploiting historical data is covered by the Business Intelligence (BI) domain [START_REF] Watson | The current state of business intelligence[END_REF], which provides access to past performance indicators by analyzing information stored in data warehouses. This enables users to understand what happened in the past and help them to prevent making mistakes in the future. On the other hand, managers traditionally rely on Business Activity Monitoring (BAM) systems [START_REF] Mccoy | Business activity monitoring: Calm before the storm[END_REF] to make operational decisions, see for instance Splunk1 and Vitria2 . BAM aims to provide real-time access to critical business performance indicators. Thus managers can have a deep insight into what is currently happening in their business before taking rapid and effective decisions. BAM gathers its information in real-time by analyzing data streams from multiple sources. Nevertheless these technologies are limited because they focus on real-time information, ignoring existing historical data. They do not give managers the necessary hindsight to compare the current company activity behavior with its history. Therefore, false positive decisions could be taken by analysts since real-time and historical data are not considered together. To overcome these limitations, BAM tool capabilities could be enhanced with BI features. Managers could then use an hybrid tool to handle both real-time and historical data, allowing them to continually navigate from real-time to historical data. Such hybrid systems approach faces with two main issues: combining real-time and historical systems and the performance issue.

• Handling Two Different Types of Systems: Historical and real-time data are handled by two different types of systems. Historical data require well-known OLAP DataBase Management Systems (DBMS). Real-time data rely on Data Stream Management Systems (DSMS), Complex Event Processing (CEP) or BAM systems [START_REF] Luckham | The power of events[END_REF]. These systems handle transient data streams and can query them thanks to Continuous Queries.

Handling within a unique system those two different types of data is clearly an issue.

• Performance Issue: BI systems are usually used to generate non interactive reports which do not have real-time (or near real-time) requirements. BAM tools however always provide managers with a graphical user interface (GUI) to monitor their business. The GUI is always interactive and offers the possibility to explore real-time data and other analyses computed over them. This means that the underlying system must guarantee fast response time of queries in charge of feeding the GUI with information. This is because GUI display lag can make the system unpractical, thus reducing its interest.

When historical data have to be queried, the main performance bottleneck is on the induced I/O cost which impacts real-time data processing, leading to unacceptable GUI display lag.

As far as we know, Chandrasekran and Franklin [START_REF] Chandrasekaran | Remembrance of streams past: Overload-sensitive management of archived streams[END_REF] and Reiss and al [START_REF] Reiss | Enabling real-time querying of live and historical stream data[END_REF] were the first to address the topic of enhancing DSMS with DBMS capabilities. In [START_REF] Reiss | Enabling real-time querying of live and historical stream data[END_REF], they define bitmap index specially designed to handle these two types of data. In [START_REF] Chandrasekaran | Remembrance of streams past: Overload-sensitive management of archived streams[END_REF], they present a framework using Data Reduction techniques, sampling techniques in their case, to limit I/O overhead induced by accessing historical data. Their approach enables the reduction level to be adapted according to the available resources. They also addressed the issue of when to perform data reduction. Three approaches were explored: data reduction at data arrival, at query execution or both. The framework was implemented on top of PostgreSQL.

In this paper, we focus on queries that access both historical data already existing in the system and live data that had not yet been entered into the system when the query was defined. They are temporal by nature because they access data evolving over time. Such queries support either the valid time dimension [START_REF] Snodgrass | 151r1, iso-ansi sql/temporal change proposal, iso[END_REF] or the transaction time dimension [START_REF] Snodgrass | Adding transaction time to sql/temporal. ISO-ANSI SQL/Temporal Change Proposal[END_REF] or both (bi-temporal query). The support of the transaction time means that the query can access the history of data as it is modified in the DB. The valid time enables access to the history of data as it evolves in the modeled reality. We consider the case of bi-temporal queries. Let us consider the following example:

"What is the average of new revenue achieved by the company every month last year (2014), considering the DB at the instant 1/10/2015 ?" This simple query requires access to all items that have been ordered from 1/1/2014 to 12/31/2014. Depending on the database, this query may induce a large number of I/O operations and can be very long to complete. Whenever this query is executed only once, traditional approaches can be applied. Otherwise, if this query has to be executed several times -for example to frequently refresh some GUI -this is not acceptable.

Paper contribution.

We present Decision Insight [START_REF] Ouassarah | Understanding Business Trends from Data Evolution with Tornado (demo)[END_REF], a platform that deals with historical and real-time data in a unified manner. The project was launched in 2008 under the name of Tornado by Systar, a French software editor. This latter was then acquired in 2014 by Axway, another French software editor and Tornado became Decision Insight. Axway aims to compete with major leading industries in data management worldwide and turns out be the fifth french editor according to a recent study 3 . The project mobilizes about twenty engineers and it has been marketed since 2013. This platform implements an optimization that consists in redefining complex bitemporal queries into: 1) a set of continuous queries in charge of handling real time data streams (whose results are materialized) and 2) a query that accesses both historical and materialized results of the previous continuous queries. Thus, Decision Insight can provide analysts with timely answers through a convenient GUI [START_REF] Ouassarah | Understanding Business Trends from Data Evolution with Tornado (demo)[END_REF]. Decision Insight is based on a column-store bi-temporal DBMS that handles these two types of data and implements a simple and efficient bi-temporal query optimization technique. We demonstrate the interest of our approach using an adapted version of TPC-BiH, a bi-temporal extension of the TPC-H benchmark. Extensive experiments have been conducted, pointing out the interest of Decision Insight for delivering timely information based on historical and real-time data.

Paper organization.

The remainder of this paper is structured as follows: In section 2 we introduce our query rewriting approach. Then in section 3, we address the issue of materialized continuous query computation scheduling. Then in section 4, we point out how the contribution has been implemented within the Decision Insight framework. Experiments are given in section 5 using the TPC-BiH [START_REF] Kaufmann | Tpc-bih: A benchmark for bitemporal databases[END_REF] benchmark. Section 6 is devoted to related works. Then we conclude the paper in section 7.

QUERY REWRITING

In this section, we first describe how aggregate bi-temporal SQL queries are expressed. Then we explain how complex bi-temporal queries are decomposed as a set of materialized continuous queries (CQ) and one special bi-temporal query.

In the rest of the paper, all queries are expressed using a pseudo-SQL formalism based on SQL:2011 supporting temporal features [START_REF] Kulkarni | Temporal features in sql: 2011[END_REF].

Temporal Query Expression for Aggregate Queries

It is well known that the expressiveness of SQL:2011 is limited to defining temporal queries performing aggregations [START_REF] Kulkarni | Temporal features in sql: 2011[END_REF][START_REF] Kaufmann | Comprehensive and interactive temporal query processing with sap hana[END_REF].

Rhythm

To deal with this issue, we introduce the concept of rhythm as a partition of the valid time domain into contiguous and equal-length time intervals. A rhythm is defined by a couple (begin, duration) where begin is the reference time instant to be used for partitioning the valid time domain and duration is the length of each interval. For example, the rhythm (01/01/2014, 1 day) corresponds to the following partition: Clearly, a rhythm is used to define the time range over which the aggregation is performed.

Rhythms can be implemented in SQL:2011 as a relation with two attributes representing the endpoints of each interval of that rhythm. In the sequel, all queries use a one-day rhythm (01/01/1990, 1 day) represented by the relation Rhythm_day. The TPC-BiH database schema [START_REF] Kaufmann | Tpc-bih: A benchmark for bitemporal databases[END_REF] is a bi-temporal extension of the TPC-H database schema. It mainly describes customers, orders and line items of a fictive company. We have slightly adapted the TPC-BiH database schema to fit our needs (Fig. 1). The schema is fully bi-temporal, i.e all tables are extended with both valid time and transaction time.

Temporal Data Schema of the Running Example

Temporal Aggregations

We follow Kaufmann and al's classification of time ranges in temporal aggregations [START_REF] Kaufmann | Comprehensive and interactive temporal query processing with sap hana[END_REF]. They identified four types of time ranges:

• Instantaneous Aggregation [START_REF] Dyreson | A consensus glossary of temporal database concepts[END_REF]

Query Rewriting Technique

Business Activity Monitoring systems usually provide managers with features to build so-called views to monitor their business through user-friendly GUI. Those views use underlying queries to feed them with information to display. Consequently, they are not intended to be executed only once and then deleted as is usually the case in standard applications. Indeed, they can be evaluated several times, as long as the related view needs to be updated.

In this section, we sketch the main idea of our query rewriting technique. Without loss of generality, we are concerned with the following class of bi-temporal queries [START_REF] Snodgrass | Developing time-oriented database applications in SQL[END_REF]: where:

Listing 5: Initial query Qt SELECT A1, A2, ...,
• A1, A2, . . . , An are attributes or derived attributes,

• Agg1, Agg2, ..., Agg k are aggregation functions, e.g., AVG, SUM, MIN.

• The WHERE clause is a conjunction of selection predicates and join predicates: tcj predicates are over temporal attributes while ci are over non temporal ones.

• table1, table2, . . . , tableJ are tables from the accessed database (historical data).

• stream1, stream2, . . . , streamK are data streams (live data)

• Rhythm_T able is the table defined in the previous section.

Such a query is used to feed an underlying GUI whenever it needs to be updated, e.g due to a user interaction. Whenever the amount of data to be processed exceeds some limits, GUI latency deteriorates. Therefore, to address the scalability issue, we rely on data reduction techniques. Intuitively, we compute as soon as possible some partial answers allowing to efficiently answer a query asked by decision-makers. In other words, instead of performing aggregations at query time, we propose to perform them on data arrival. Thus, when a query is executed, it simply accesses the results of the aggregations which requires fewer I/O operations. This approach ensures that the most expensive I/O costs have been performed before information is needed by a decision-maker. Hence, at query-time, the cost will be as low as possible, thus satisfying our major goal.

Given a bi-temporal query, the process is as follows:

• one or more simple continuous queries [START_REF] Arasu | An abstract semantics and concrete language for continuous queries over streams and relations[END_REF] are defined, and their results are materialized. Such queries handle large volumes of data and do not affect historical data. They are referred to as materialized continuous queries;

• one elaborated temporal query, referred to as an on-demand query, in charge of providing decision-makers with results. Such a query accesses both historical and live data, including materialized CQs.

This approach has the advantage of providing a unified way to access both real-time and historical information through temporal queries. The result of this approach is equivalent to the result of the initial query against the same data. The reader is referred to [START_REF] Krämer | A temporal foundation for continuous queries over data streams[END_REF] for equivalence of continuous queries. This is not in the scope of this paper.

Materialized Continuous Queries

For each aggregation Aggi in the initial query, we define one continuous query in charge of reducing input data into pre-computed aggregates. This query is simple and can handle a large volume of data, as in (Listing 6).

Listing 6: A materialized continuous query SELECT A1, A2, ..., An, Agg, vtb, vte FROM stream1, stream2, ..., streamK WHERE tc1 AND tc2 AND ... AND tcn AND c1 AND c2 AND ... AND cm GROUP BY A1, A2, ..., An where:

• Agg is the aggregation operation performed by the query,

• stream1, stream2, ..., streamK is the set of accessed data streams,

• vtb and vte are two time attributes representing the time interval during which the computed result is valid,

• the result of this query is stored in a table, thus becoming historical data.

Each continuous query is bound at its creation to a rhythm. For each interval of the rhythm, the query returns one result that is stored in the DB. The choice of the rhythm depends on the user's needs. The more accurate the expected result, the finer the rhythm's granularity, and the higher CPU cost and memory utilization. Whenever a continuous query is created, some new attributes linked to that query are added dynamically to the database schema. This is intended to store the query results for future use. If we consider the example from the introduction, then our approach requires one continuous query (Listing. 7).

Listing 7: The continuous query sumNewRevenuePerDay

On-demand Queries

An on-demand query is a bi-temporal query executed against the database whenever new information is required by decision-makers through their GUI.

Listing 8: On-demand query SELECT A1, A2, ..., An FROM table1, table2, ..., tableJ WHERE tc1 AND tc2 AND ... AND tcn AND c1 AND c2 AND ... AND cm;

We consider two classes of on-demand queries: time travel and time slice queries.

Data Storage

A database used in BAM applications has to store both real-time data and results of the materialized continuous queries. It thus offers an unified interface to access them all. Since these data are bitemporal, we need a database management system with bi-temporal capabilities. Decision Insight is based on a column-store DBMS [START_REF] Stonebraker | C-store: a column-oriented dbms[END_REF][START_REF] Boncz | Monetdb/x100: Hyper-pipelining query execution[END_REF] which means that a table is stored column by column. We outline below three main reasons motivating our choice.

Performances in Analytical Workloads

The oriented-column databases are intended to perform analytical queries that analyze data and give an insight into the business activity, e.g the number of orders in pending status. The columnoriented database systems outperform row-oriented database systems on analytical workloads such as those found in business intelligence and decision support applications [START_REF] Abadi | Column-stores vs. row-stores: how different are they really[END_REF].

Dynamic Update of the Database Schema

Our query optimization requires adding and removing attributes dynamically. The row-oriented approach is not suitable in our case because addition or deletion of an attribute affects the whole table, with performance impacts on the modified table. However the column-oriented approach does not suffer from this issue since each attribute has its own column.

Dealing with Temporal Attribute Evolution

The database must have bi-temporal built-in support and is intended to handle the history of data as it evolves. In the roworiented approach, the update of an attribute value requires adding a new tuple with the new value. This behavior causes both a storage overhead and an increase in query execution time due to data duplication. As an example, let us consider the table Customer (Table 1) represented using the formalism proposed by Snodgrass [START_REF] Snodgrass | The temporal query language tquel[END_REF]. The update of the attribute balance for the customer "AWM" leads to the insertion of two new tuples in the table 2. In a column-oriented approach, each attribute can evolve independently because it is stored in its own column. This issue has been addressed by Jensen and Snodgrass from a logical point of view [START_REF] Jensen | Temporally enhanced database design[END_REF]. They support the idea that the introduction of temporal dimensions in the data model requires adaptation of the data model design. They propose a handbook of best practices for the design process. However, this is not in the scope of this paper. As shown above, Decision Insight is therefore based on a column-store DBMS.

Computation Scheduling of Materialized Continuous Queries

The use of materialized views requires in general to consider the scheduling strategy to compute its results. This strategy has to reconcile keeping views up-to-date as data is collected and limit the number of refresh so the computation cost overhead is contained. Actually it is unthinkable to compute a view for each single incoming update of entity. It is rather wise to refresh views periodically or by bunch of updates. In the case of a soft real-time 2TDBMS, the maintenance of materialized queries is more complex. The real-time aspect induces computation deadline constraints to ensure fresh information to managers. The bitemporality necessitates to consider the semantics of the two temporal dimensions to choose the adapted computation strategy. Indeed we need to determine the adequate instant when data is supposed to be available in the database to trigger the computation. In the general case the two dimensions are orthogonal, which means that there is no restrictions between the valid time and the transaction time of any fact in the DB. However in many practical applications there is a restriction relationship between them. For example, if we suppose that every event that occurs in the reality is considered as valid when it is inserted in the DB which, then vte = tte. This topic has been addressed by Jensen and Snodgrass in bitemporal relational databases [START_REF] Jensen | Temporal specialization and generalization[END_REF] under the name temporal specialization relations. The authors classify bitemporal relations into 15 classes of specialization. In Decision Insight, we consider three types of events :

• Retroactively bounded events: It is the usual case. For each event, valid time and transaction time have the following interrelationships vte < tte ≤ ∆t + vte with ∆t > 0. In specific terms, the event occurs in reality at vte, then it is recorded in DB at tte. ∆t is fixed by the user and represent the necessary time to collect it, transfer it to the DB and record it.

• Delayed retroactive events: It corresponds to events whose temporal attributes have the following interrelationships ∆t < tte -vte. This type of events occurs in two cases:1) when there is technical issue making difficult to deliver events to the DB. 2) to correct previous events that have been recorded into the DB.

• Predictive events: This case corresponds to events that are recorded in the DB before they occurs in reality (tte ≤ vte), e.g a government tax rate modification which is always announced before it is applied so that concerned people make arrangements.

In order to handle these three types of events, Decision Insight implements two different approaches: Live Mode and Late Data Handler.

• Live Mode : This approach is the usual mode and is in charge of handling both retroactively bounded events and predictive events. Concretely, considering a materialized continuous query, the condition to schedule its execution for an interval of its rhythm is that all input data are available. Thus, for a rhythm interval [vt begin , vt end [, the system supposes that at tt = vt end + ∆t all input data is available and schedules the computation. ∆t must smaller than vt end -vt begin . Otherwise, the computation task queue fill rate will be faster than the computation rate.

• Late Data Handler: This mode is dedicated to retroactive events. When such type of events arrives, the system determines all materialized continuous query and rhythm intervals impacted. Then it schedules a their recomputation.

In the sequel, we restrict ourselves to the live mode.

DECISION INSIGHT

Decision Insight is a comprehensive data-intensive decision support system that combines both BI and BAM capabilities. It uses a dashboard as an user interface primitive, allowing analysts to visualize activity indicators and to navigate in time to understand how they evolve. A dashboard is made up of one or more graphical elements (diagrams, charts, datagrids, . . . ) referred to as pagelets in the sequel. Each graphical element displays data returned by an underlying query. An example of a pagelet is depicted in Fig. 2, where daily revenues for a company are displayed as a curve in a particular time range.

Implementing queries using a SQL-based language can be a very difficult activity, particularly for business managers with limited technical skills. Decision Insight provides an advanced graphical interface for rapid design of the complex queries related to BAM [START_REF] Ouassarah | Understanding Business Trends from Data Evolution with Tornado (demo)[END_REF]. Decision Insight allows to specify in a graphical interface the main steps of the query optimization previously defined. This query rewriting is performed intuitively via the GUI by a decision maker. The process of implementing a pagelet is divided into two phases described below.

Designing Materialized Continuous Queries

First, the manager has to define all analyses on data streams that he wants to use in his pagelet.

Let us consider the following query: "What is the revenue achieved by the company every day from 01/01/1992 to 01/01/1993, considering DB at the most recent state?". The screenshot (Fig. 3) shows a part of Decision Insight's user interface used to create a new analysis corresponding to Fig. 2. (A) indicates which rhythm do we want to link to the attribute. In our case we choose a one-day rhythm as we want to know the company's total revenue per day. (B) indicates the aggregation operation used to generate the analysis. (C) indicates the time-range to consider for the aggregation. In our example we fix at the last day. Finally (D) represents data inputs used to compute the analysis, which is the attribute "extendedPrice" of the LineItem. For each of these attributes, Decision Insight creates attributes via an underlying materialized continuous query in a transparent way for the user.

Designing On-Demand Queries

In the second phase, the manager chooses the form and the content that will be displayed on the pagelet. Fig. 4 is a screenshot of Decision Insight's user interface for implementing a pagelet. (A) indicates the type of graphical element the manager wants to display, namely a historical curve. (B) indicates the time range of information to display on the pagelet. According to the query, we choose to display the whole current month. (C) indicates the information to be displayed. Based on the provided information, Decision Insight creates a pagelet and an underlying on-demand query in charge of updating the pagelet content (Fig. 2).

EXPERIMENTS

Bi-temporal DB Benchmarks

A bi-temporal benchmark can be used in our case since it offers bi-temporal data that can be used to simulate real-time data. To the best of our knowledge, the TPC-BiH [START_REF] Kaufmann | Tpc-bih: A benchmark for bitemporal databases[END_REF] is the most complete bitemporal benchmark. TPC-BiH is an extension of TPC-H [START_REF] Council | Tpc-h benchmark specification[END_REF] and measures the performances of a DBMS used by a decision support system. The benchmark also includes a data generator producing a workload based on 9 categories of business transactions (New Order, Cancel Order, Update Stock, etc).

Database Populating

From the initial data produced by the TPC-BiH data generator, we generate a stream of events < id, data, T >. Each event corresponds to an updating instruction addressed to the database. id is the event type, e.g "insert a new order" or "insert a new customer". data is the information handled by the event and T is the timestamp when the event occurred. The events are ordered according to the attribute T , so we can simulate a real-time workload. The initial TPC-BiH dataset has a size of 400MB. The generated data stream contains 3620761 events (Table 3).

We also introduce a scaling factor "sf " to fix the rate of the data stream. For the initial data stream sf = 1. All data streams with a

Queries

We have implemented two examples of typical queries used in BAM. They are simple so that they can be easily expressed. Those queries are frequently executed by a GUI which requires rapid response times.

Query 1

This first query, (listing 11), aims at answering the following business question: "What is the sum of new revenues for the company every day from 1/1/1992 to now considering the most recent data?". We redefine this query as one materialized continuous query "Q1-Cont" (Listing 12) and one on-demand query "Q1-OnD" (Listing 13).

Listing 11: Q1: New Revenue per day SELECT Ryhthm_1d.vtb as vtb, Ryhthm_1d.vte as vte,

Query 2

The query given in the (listing 14) aims at answering the following business question: "What is the number of orders per status for every day from 1/1/1990 to now considering the most recent data?". We redefine this query as one materialized continuous query "Q2-Cont" (Listing 15) and one on-demand query "Q2-OnD" (Listing 16).

Experimental Results

In this section we present the results of experiments conducted to assess the performances of our approach. To do this, we compare system performances with and without using our optimization. We also present some measures of the overhead induced by our optimization. Experiments were executed on a physical machine which runs an Ubuntu 10.04, equipped with 12GB of RAM, an Intel i7 processor with 8 cores at 2.8GHz and a 4TB of RAID storage.

Response Time

In this test, we point out the interest of our approach in reducing Decision Insight's time response. We run two experiments: in the first, we evaluate the impact of the time range size on the execution time of Q1 and Q2 (sf = 1) while in the second, we vary the value of sf .

Fixed Scalar Factor

We inject stream concerning the period [1/1/1992, 1/1/1999[. At the beginning of each new year of the simulation period, we execute once Q1 and Q2 using a new value of the parameter "[YEAR]". We compare two versions of each query: the optimized version, using our approach based on continuous queries (Q1-OnD and Q2-OnD), and a classical version, where the result is computed whenever the query arrives (Q1 and Q2). We collect the execution times of these queries and represent them on Fig. 5. We can notice that optimized versions of queries outperform the rest by at least a factor of 100. For each day of the query interval, Q1-OnD accesses one value which is the materialized result of the underlying continuous query. Q1, however, accesses the original data, i.e about 200 items for each day.

Varying Scalar Factor

In this experiment, we assess our approach when we vary the data stream rate. The experimental conditions are similar to the previous test. We vary the value of sf from 1 to 6. For each value of sf , we inject the stream that concerns the period [1/1/1992, 1/1/1995[. Following injection, queries Q1 and Q2 are successively executed with and without optimization. The queries are executed with [YEAR]=1995. When the data stream rate increases, the query execution time of the non-optimized queries increases, else it remains stable.

Precomputation Overhead

Previous tests demonstrate the advantage of our approach in reducing the response time of the system. However it induces a CPU and disk storage overhead.

Fixed Scalar Factor The experimental conditions are similar to the test for response time/fixed scalar factor, except that we use only Q1. For each day of the simulated period, we collect the CPU time of Q1-Cont. We also collect the CPU time to execute Q1-OnD and Q1. Fig. 7 shows the results of the experiment: one curve represents the CPU consumption of Q1, while the other is the sum of the CPU consumption of Q1-cont and Q1-OnD. It appears that the optimized approach requires a CPU overhead throughout the simulation time. However, it smooths the CPU consumption curve and avoids peaks at query time and thus system overload. We also notice that as from the 2000th day of simulation, the CPU Q1 cost is at least 100 times greater than the CPU required to compute Q1-cont and Q1-OnD. This means that for a query using a large time interval (6 years), the overhead induced by our approach has no impact on query processing performance.

Varying Scalar Factor In this experiment we assess the cost of our approach as we vary the stream rate using the parameter sf . For each stream, we first inject data stream corresponding to the period [1/1/1992, 1/1/1995[, then we execute Q1 with [YEAR]= 1995. We collect the CPU time to perform Q1 and Q1-OnD. We also collect the average CPU time of Q1-cont per day and the total sum of all CPU time consumption of Q1-cont during the simulation. The results are represented in (Fig. 8). Whenever sf >= 6, our approach does not have any CPU overhead.

Concurrent Query Execution

In this test, we simulate several users interacting with the system. We have performed two experiments: one where we vary the number of concurrent queries and another where we vary sf .

Fixed Scalar Factor

In this experiment, we use a dataset where sf = 1. We first populate the system with data corresponding to the period [1/1/1992, 1/1/1999[. Following system population, we execute concurrently several instances of the query Q1 with [YEAR]=1999. Then we get the CPU time required to execute them all. Fig. 9 shows the results of this experiment where we varied the number of simultaneous executed queries from 1 to 20. As shown in Fig. 9, our approach is quite adapted for execution of concurrent queries.

Varying Scalar Factor In this experiment, we explore the impact of the data stream throughput on the execution of concurrent queries. We first populate the system with data that corresponds to the period [1/1/1992, 1/1/1995[. Then we execute 10 concurrent queries, corresponding to 10 users. As in the previous test, we observe the advantage of the proposed optimization due to the increasing number of queries accessing the results of continuous queries as historical data.

RELATED WORKS

To the best of our knowledge, Chandrasekaran and Franklin were the first to address the topic of combining real-time data with historical data [START_REF] Chandrasekaran | Remembrance of streams past: Overload-sensitive management of archived streams[END_REF] in the academic field. They noted that the main performance issue for those systems was the I/O cost induced by gathering historical data, which decreases drastically live data stream processing performance. They proposed a framework using some data reduction techniques for historical data to limit I/O cost (see also [START_REF] Barbar'a | The new jersey data reduction report[END_REF]). Their framework data reduction level to be adapted with respect to current available resources. They defined three approaches to perform data reduction techniques: OnWriteReplicate, OnRead-Modify and Hybdrid approach. The first approach is based on the fact that random disk I/Os are expensive. Data reduction is performed continuously as soon as data is collected by the system. Thus at query time, the global query can access pre-computed results when needed. Nevertheless, pre-computed results can never be accessed by global queries. The second approach consists in performing the data reduction at query time only. The price to be paid can be very high for delivering timely information. The third approach combines the two previous approaches and shares the work between data arrival and query time. In this approach there is a single copy of the stream stored on disk and divided into separate batches. Each batch is divided into a fixed number of blocks. Tuples are randomly inserted in different blocks of the current batch. Once one block is filled, the entire run is flushed on disk. At query time, the system only accesses a fraction of blocks of runs according to a sampling rate. With respect to our contribution, we use the OnWriteReplicate approach which turns out to be effective for BAM applications. Postponing query processing when the system is at a lower load is not a new idea, see for instance [START_REF] Chaudhuri | An overview of data warehousing and olap technology[END_REF] in a BI context. Load shedding techniques have been investigated in DSMS to come up with high data throughput [START_REF] Tatbul | Load shedding in a data stream manager[END_REF]. Such techniques are quite different from the proposition made in this paper. The application context of Business Activity Monitoring does not fit perfectly into either of those two main areas, i.e. neither the data volume is expected to be as large as in data-warehouse applications, nor the data throughput is expected to cause the system to collapse as in some DSMS applications. BAM applications lie somewhere between these two kinds of applications. The topic of materialized views has been widely discussed in DBMS in general [START_REF] Larson | Computing queries from derived relations: Theoretical foundation[END_REF][START_REF] Schmid | A multi-level architecture for relational data base systems[END_REF] and in real-time DBMS in particular [START_REF] Adelberg | Applying update streams in a soft real-time database system[END_REF], since materialized views are often considered to reduce query execution time. These works mainly suppose the case of snapshot views, i.e views that maintain only the last state of data. This assumption is not sufficient in our case since we need to store its whole history. There were some works concerning temporal materialized views [START_REF] Yang | Maintaining temporal views over non-temporal information sources for data warehousing[END_REF][START_REF] Jensen | Incremental implementation model for relational databases with transaction time[END_REF][START_REF] Jagadish | View maintenance issues for the chronicle data model[END_REF]]. Yet the do not address the real-time case. The concept of rhythm is close to the concept of Granularity that has already been defined in litterature [START_REF] Bettini | A glossary of time granularity concepts[END_REF] and has been implemented in some products. We can quote Teradata' DBMS that extends SQL with the key word "EXPAND ON". There is also Kx System's product KDB+ whose processing language supports such feature. Many commercial products addressing business monitoring exist, among which we quote Kx System4 , spunk and main DBMS players like DB2, Oracle and Teradata. However, as far as we know, no one covers all features offered by Decision Insight. KDB+, for example, handles both real-time and historical data and is based on a column-store database dedicated to handle time-series data. Yet, it only supports valid time dimension.

CONCLUSION

In this paper, we have introduced Decision Insight, a comprehensive data-intensive decision support system that combines both Business Activity Monitoring (BAM) and business intelligence capabilities. Given a bi-temporal query on historical and live data, the optimization technique of Decision Insight is based on a decomposition of the initial query into several continuous queries plus one on-demand query, which accesses the materialized data of previous queries. This technique has been implemented in Decision Insight, and experiments have been conducted on the TPC-BiH benchmark (variant of the TPC-H benchmark). Results show that Decision Insight is able to deliver very fast responses to decision-makers, which is a very strong requirement in BAM applications.

In future works, we aim to study multi-query optimization techniques to share as much as possible the processing of a set of complex bi-temporal queries [START_REF] Sellis | Multiple-query optimization[END_REF][START_REF] Candea | A scalable, predictable join operator for highly concurrent data warehouses[END_REF].

[

  01/01/2014, 01/02/2014[∪[01/02/2014, 01/03/2014[∪ . . .

Figure 1 :

 1 Figure1: Temporal database schema adapted from TPC-BiH[START_REF] Kaufmann | Tpc-bih: A benchmark for bitemporal databases[END_REF]

Figure 2 :

 2 Figure 2: Snapshot of a pagelet displaying the daily evolution of revenues

Figure 3 :

 3 Figure 3: Decision Insight's interface to implement a continuous query

Figure 4 :

 4 Figure 4: Decision Insight's interface for implementing an On-Demand query

Figure 5 :

 5 Figure 5: Query response time while varying window size

Figure 6 :

 6 Figure 6: Query response time while varying data stream rate

Figure 7 :

 7 Figure 7: Continuous query computation overhead

  time cost depending on scale Average CPU time overhead per day Total CPU time cost Q1 (without CQ) CPU time cost Q1 (with CQ) CPU time cost

Figure 8 :

 8 Figure 8: CPU time as a function of scale factor

Figure 9 :

 9 Figure 9: Concurrent query execution

Figure 10 :

 10 Figure 10: Concurrent query execution while varying sf

•

  Time Travel: This consists in acquiring the state, or snapshot, of the DB at a specific time. Here is an example of this class of queries (listing 9): " What is the revenue achieved by the company at vt = 10/13/2014, considering the DB at tt = 10/20/2014T10:30:00.0?".

	Listing 9: A time travel query example
	SELECT aggr
	FROM sumNewRevenuePerDay
	FOR SYSTEM_TIME AS OF TIMESTAMP
	10/20/2014T10:30:00.0
	WHERE vtb <= 10/13/2014 AND 10/13/2014 < vte;
	by the
	company during the interval [10/13/2014, 12/13/2014[ and
	considering the DB at tt=10/20/2014T10:30:00.0?"
	Listing 10: A time slice query example
	SELECT aggr, vtb, vte
	FROM sumNewRevenuePerDay
	FOR SYSTEM_TIME AS OF TIMESTAMP
	10/20/2014T10:30:00.0
	WHERE 10/13/2014 <= vtb AND vtb < 12/13/2014;

• Time Slice: This class of queries is intended to return the historical data according to one temporal dimension. We fix one time dimension at a particular time instant while the other one is fixed at an interval. Here is an example of this class of queries (listing 10): "What is the revenue achieved

Table 1 :

 1 customer before the update

	custid name	balance vtb	vte ttb	tte
	1	Benason 12000	10/16 ∞	10/16 ∞
	2	AWM	2000	10/9	∞	10/10 ∞
	3	Vop	47800	10/13 ∞	10/14 ∞

Table 2 :

 2 customer after the update

	custid name	balance vtb	vte	ttb	tte
	1	Benason 12000	10/16 ∞	10/16 ∞
	2	AWM	2000	10/9	∞	10/10 10/17
	2	AWM	2000	10/9	10/17 10/17 ∞
	2	AWM	6000	10/17 ∞	10/17 ∞
	3	Vop	47800	10/13 ∞	10/14 ∞

Table 3 :

 3 Number of operations per table

	Relation	# of insertions # of updates # of deletions
	Region	5	0	0
	Nation	25	0	0
	Supplier	1000	0	0
	Part	20000	49861	0
	Customer	164668	253430	0
	Partsupp	80000	352391	0
	Orders	348026	681103	8452
	LineItems 939670	699310	22820
	SUM(extendedPrice) as totalRevenuePerDay
	FROM LineItems, Ryhthm_1d
	WHERE
	'01/01/1992'=<Ryhthm_1d.vtb AND
	Ryhthm_1d.vtb < '01/01/[YEAR]' AND
	Ryhthm_1d.vtb <= LineItems.vtb AND
	LineItems.vtb< Ryhthm_1d.vte
	GROUP BY Ryhthm_1d.vtb;
	Listing 12: Q1-Cont: New Revenue per day
	SELECT SUM(extendedPrice) as totalRevenuePerDay,
	[vtInterval].begin as vtb, [vtInterval].end as vte
	FROM LineItems
	WHERE [vtInterval].begin <= vtb AND
	vtb < [vtInterval].end;
	--[vtInterval]: a rhythm interval
	Listing 13: Q1-OnD: New Revenue per day
	SELECT vtb, vte, aggr as newRevenuePerDay
	FROM totalRevenuePerDay
	WHERE '01/01/1992' <= vtb AND
	vtb < '01/01/[YEAR]';

http://www.splunk.com/

http://www.vitria.com/

http://www.infodsi.com/articles/155700/editeurs-francais-contrecourant-conjoncture.html?key=c9fee7a30353fd4a

http://kx.com/


Azhar Ait Ouassarah

Nicolas Averseng

Xavier Fournet

Jean-Marc Petit

Romain Revol

Vasile-Marian Scuturici

Understanding Business Trends from Data Evolution with Tornado

Nowadays, every company could understand how its business evolves from the data (deluge) generated by its activities. Roughly speaking, two types of data co-exist: historical data and real-time data from which business analysts have to take their decisions in a timely fashion. In this context, the notions of time (application time and transaction time) and traceability turn out to play a crucial role to understand what happened in the company and what is currently happening. Tornado offers a fullfledged platform to deal with such data and is based on two key features: 1) a bi-temporal DB specifically designed for handling historical and real-time data, 2) a GUI that aims to facilitate query formulation for business analysts. In this demonstration, we provide the key resources to let the visitors play with the Tornado functionalities to interact with predefined data.

I. INTRODUCTION

Companies are operating in very dynamic and complex environments that require from their managers agility and ability to make proactive operational decisions, in order to maintain or improve their business. Traditionally managers rely on Business Activity Monitoring (BAM) [START_REF] Mccoy | Business activity monitoring: Calm before the storm[END_REF] to take operational decisions. BAM aims to provide real-time access to critical business performance indicators. Thus managers can have a deep insight of what is currently happening in their business and then take rapid and effective decisions. BAM gathers its information in real-time by analysing data streams from multiple sources. BAM solutions often rely on Complex Event Processing (CEP) [START_REF] Luckham | The power of events[END_REF] can also detect interesting patterns of events, e.g if events A and B happen then C happens too. Nevertheless these technologies are limited because they only focus on real time information rather than using existing historical data. Exploiting historical data is covered by the Business Intelligence (BI) domain [START_REF] Watson | The current state of business intelligence[END_REF] which provides access to past performance indicators by analysing information stored in data warehouses. It enables users to understand what happened in the past and help them to prevent the mistakes in the future. Tornado, a platform developped by Systar (http://www.systar.fr/), addresses analyst's needs to cover BI and real-time monitoring use cases. Even if some contributions exist in the Data Stream Management to deal with real-time and historical streams [START_REF] Chandrasekaran | Remembrance of streams past: Overload-sensitive management of archived streams[END_REF], [START_REF] Reiss | Enabling real-time querying of live and historical stream data[END_REF], Tornado is, to the best of our knowledge, the first comprehensive data-intensive decision support system allowing to exploit real-time data streams and historical data in a transparent manner.

Tornado has been designed to be easily deployable. Thus it do does not require specific hardware equipment and can be deployed on commodity hardware at a low cost ownership. Creating or updating applications does not require deep technical knowledge. Tornado embeds a proprietary NoSQL bitemporal and column-oriented database management system (2TDBMS) that is continuously fed with data by external data sources. In order to cope with real-time constraints the query processing engine uses different types of continuous queries. Analysts with limited technical skills can create new analyses, tailor their dashboards and see the results of their modifications immediately on production data. Thus these applications evolve as user's needs evolve to meet the business evolution. As Tornado combines both real-time monitoring and BI functionalities, it enables analysts to consider operational data in the past, present, or future using the same tool. It provides consolidated views of traditional real-time analyses with complete temporal historical analyses. The query engine allows typical user scenarios as:

• Replay of past situations with exactly the same information as when they occurred live; • Investigation for audit and traceability to provide:

-In depth analysis of a situation that occurred in the past, which could include answers to questions such as what happened, when, why and where specific actions are taken; -On demand simulations of the evolution of past situations; -Parallel comparison of the evolution in time of two situations, such as a present time process and the behavior of the same process yesterday;

• Risk assessment evaluations which may be:

-Based on past events and data; -Based on forecasted events and data. Tornado has to face two main performance issues: processing high volume of data generated by business activities and guaranteeing fast response time for users monitoring business activities through a GUI interaction.

In this demonstration we will highlight the two main features of Tornado: 1) An unified GUI to query and visualize both real-time and historical data. 2) A proprietary NoSQL, Bitemporal and column-oriented DBMS (2TDBMS) that is specifically designed to handle both historical and real-time data.

II. TORNADO DESCRIPTION

A. Architecture

Tornado is based on a service oriented, event-driven implementation using Java TM language. It is structured into three loosely coupled functional layers: Absorption Layer, Logic Layer and User Interface Layer. Absorption Layer: Tornado uses unobtrusive, agentless technology to collect, process and analyse real-time data as well as historical data. It is based on the Apache Camel engine that offers a wide range of possibilities to pull data from various types of sources. Logic Layer: The logic layer embeds a 2TDBMS specifically designed and optimized for Tornado. The power of that DBMS is its ability to handle both real-time streams and historical data and provide an unique interface to access to them. User interface layer: The user interface layer allows any web browsers using Adobe Flash technology to display information and from the logic layer. This layer is fully integrated with the logic layer interface to offer seamless and rich interaction with the analysts with visual data manipulation, navigation, as well as analyses (Fig. 1) based on its needs.

B. Bi-temporal and Column-oriented Features

The underlying DBMS is bitemporal, i.e it supports two orthogonal time dimensions: the transaction time [START_REF] Snodgrass | Adding transaction time to sql/temporal[END_REF], or system time, (tt) and the valid time [START_REF] Snodgrass | -96-151r1, iso-ansi sql/temporal change proposal, iso[END_REF], or application time. The support of transaction time enables to maintain a history of all modifications that occurred in the DB. The support of the valid time enables to maintain the history of data as it evolves in the modeled reality.

The DBMS has the particularity of being column-oriented [START_REF] Stonebraker | C-store: a column-oriented dbms[END_REF], [START_REF] Boncz | Monetdb/x100: Hyperpipelining query execution[END_REF] which means that each attribute is stored in a separate column and its values are stored successively on disk. This contrasts with the row-oriented DBMS where attributes of the same tuples are stored consecutively. There are two reasons behind choosing a column-oriented database management system rather than a row oriented one. First, column stores outperform row oriented database system on analytical workloads such as those found in business intelligence and decision support application [START_REF] Abadi | Column-stores vs. rowstores: how different are they really?[END_REF]. Secondly, the column oriented approach enables creation/suppression of columns with limited performance impacts, simplifying the data model update. Tornado stores data in an append-only mode. Each attribute is timestamped with two temporal attributes: 1) a valid time interval, provided by the application, that indicates the time during which the attribute's values are valid, 2) a transaction time, implicitly provided by the system during the transaction commit, that indicates when attribute's values are inserted into the DB.

The query engine integrated in the logical layer is optimized for three classes of temporal queries:

1) Time Travel: Time travel is a feature that enables to build a view of a subpart of the database at a particular state considering a valid time and a transaction time instant. It consists of all valid and accessible data at that state. As an example, a user might be interested in all unpaid orders in September 2nd 2014 midnight as database is currently recorded.

2) Temporal Aggregation: Tornado enables to compute aggregation functions over valid time while the transaction time is fixed to an instant. We consider two cases: aggregations over an instant and over a temporal range. In the first case, termed also Instantaneous Aggregation [START_REF] Dyreson | A consensus glossary of temporal database concepts[END_REF], we aggregate all valid tuples at an instant, e.g what is the number of payments with status='in process' in September 2nd 2014? In the second case, we aggregate all tuples associated to a time range using a temporal predicate. If we consider Kaufmann and al's classification of time ranges in temporal aggregations in [START_REF] Kaufmann | Comprehensive and interactive temporal query processing with sap hana[END_REF] which uses the window concepts from data streams systems [START_REF] Golab | On indexing sliding windows over online data streams[END_REF], Tornado supports three types of time ranges : 1) Tumbling Window, i.e aggregation is performed on non overlapping intervals (e.g the number of new payments per day). 2) Sliding Window (e.g the number of new payments every day for the last 10 days), 3) Landmark Window, i.e the intervals share the same interval begin (e.g the number of new payments from the beginning of the month up to each day).

3) Temporal Join: Tornado implements temporal join that simply extends the classical join with an additional predicate over the valid time intervals. Thus two tuples match if they satisfy two conditions: 1) the predicate over the non temporal attributes is satisfied and 2) the valid time intervals satisfy the temporal predicate. Tornado proposes 7 predicates like A intersects B, A beging during B, ...

C. Temporal Query Engine

Tornado uses a dashboard as an user interface primitive allowing the analysts to visualize analyses and to navigate in time to understand how they evolve. A dashboard is composed of one or several graphical elements (diagrams, charts, datagrids, . . . ) termed pagelets. Each graphical element displays data returned by underlying queries. The use of an interactive GUI requires short response time from the database system to avoid any unpleasant display lags. In order to display a complete dashboard, the update time of associated queries must respect these performance constraints, despite their complexity and the growth of the DB size. In our case, all queries are completely specified once dashboards are created or modified. Our strategy consists in computing all defined analyses as data is collected by Tornado and storing results in the DB for a future use. Thus in Tornado an analytical query, e.g as TPC-H ones, is executed as: 1) Persisted Continuous Queries: For each analysis, one query is implemented and is binded to a rhythm. We define a rhythm as a partition of the valid time domain into contiguous and equal-length time intervals, and a new attribute is added to the data model. For each interval of that rhythm Tornado executes the query on data associated to it considering their most recent state according to the transaction time. The result is valid on the computation interval and is stored in its dedicated attribute in the database for future uses. This type of queries are continuously executed by Tornado's query engine as data is available, i.e either collected by the system from external sources or produced by another analyses.

2) On-demand Queries: This type of queries is executed as long as it is necessary to refresh the pagelet it is bind to. The refresh can either be automatic or caused by the analyst when he interacts with the GUI. The on-demand queries perform time travels and temporal joins against the DB that contain both collected data and the results of the continuous queries.

III. DEMONSTRATION

For our demonstration we use an application inspired by Systar's real-life workloads that was specifically implemented for demonstration and test purposes. It corresponds to a fictive organization in charge of supervising payment transactions between companies (Fig. 2). This application contains a set of dashboards representative for the platform capabilities. Besides it embeds a configurable data generator used to evaluate Tornado's behaviours to handle large data sizes. We use two parameters to set the size of generated data: vt instant start of the simulation and number payments/minute. The simulator works in two successive phases. First it injects into the platform historical data from vt instant start to the present time. Then the generator injects real-time data from vt instant start. At the rate of 250 payments/minute, the total size of data stored in the DB is 1.7GB/day: 0.2GB/day is the data collected by Tornado and the rest are the results of the persisted continuous queries We assume that the application has reached the real-time step at the beginning of the the demonstration. The visitor of the demonstration will have the opportunity to understand Tornado through predefined queries. Then she will be invited to design its own pagelet and then explore analyses. In the second part, we design a pagelet that displays, e.g the number of new payments up to each day for the last 5 days computed every hour. The design of a pagelet is in two steps: 1) implementing analyses 2) designing the pagelet's GUI.

1) Defining Analyses: We implement, using the GUI, all continuous queries that we will need for our pagelet. For each of them we specify the aggregation function to perform, the type of window to use, the rhythm... Considering the previous example, we define one continuous query that computes every hour the number of new payments since the beginning of the day.

2) Designing Graphics: In the second step, we define first the on-demand query in charge of returning results that are displayed on the pagelet. Then we also define the type of graphic to display these analyses.

IV. CONCLUSION

We have introduced Tornado, a platform embedding a column-store bi-temporal database system, devoted to historical and real-time bi-temporal data. Its main feature is to bring on manager's desktop precise and relevant indicators on its business. Tornado relies on two kind of technique: first, the data are summarized with relatively simple continuous queries and second, more elaborated queries providing key indicators to managers.

We plan to conduct experiments of Tornado with the TCP-BiH benchmark [START_REF] Kaufmann | Tpc-bih: A benchmark for bitemporal databases[END_REF], which is a bi-temporal extension of the TPC-H benchmark. We are also working on multi-query optimization techniques, and also incremental pre-computation mechanism introduced in [START_REF] Armbrust | Generalized scale independence through incremental precomputation[END_REF].

Fig. 1 .

 1 Fig. 1. Screenshot of a dashboard

Fig. 2 .

 2 Fig. 2. Graphical data model of the scenario

Fig. 3 .

 3 Fig. 3. Screenshot of the time machine

• several simple persisted continuous queries[START_REF] Arasu | An abstract semantics and concrete language for continuous queries over streams and relations[END_REF].• one more elaborated on-demand query to provide the answer to the pagelet.


Member, IEEE Roberto Mrad

Member, IEEE Gaël Pillonnet

Member, IEEE Florent Morel

Member, IEEE Christian Vollaire

Member, IEEE Angelo Nagari

Predicting the Impact of Magnetic Components Used for EMI Suppression on the Base-Band of a Power Amplifier

Keywords: Ferrite bead, Magnetic material, Hysteresis loop, Jiles -Atherton, THD, Audio amplifier, Class-D amplifier, EMC filter

Class-D audio amplifiers are switching circuits that produce serious ElectroMagnetic (EM) emissions and disturb the surrounding electronics. In order to reduce these emissions, ElectroMagnetic Compatibility (EMC) filters with ferrite beads are used. However, ferrite beads contain magnetic materials that have a nonlinear behavior. Thus, they have an unfavorable impact on the system audio quality. The common ferrite bead models do not take into account nonlinear phenomena. Thus, to predict the impact on the signal quality, this paper models the ferrite bead using the Jiles -Atherton magnetic material theory. The presented model provides the designers with a tool to quantify the effect of EMC filters on the Total Harmonic Distortion (THD) of audio amplifiers. The simulated and measured results show that the tested ferrite bead have a negative effect on the audio signal for a wide range of amplitudes and can increase the THD up to 37 dB. Finally, this paper highlights the impact of the magnetic material type on the audio distortion by simulating the same component with different types of materials.

I. INTRODUCTION

Often in embedded systems, batteries are the only source of energy. Thus, for such applications and for a longer lifetime battery, electronic circuits with a higher power efficiency are carefully chosen. In audio applications, Class-D audio amplifiers present the highest power efficiency compared to other amplifier types [START_REF] Gaalaas | Class D Audio Amplifiers: What, Why, and How[END_REF] and are widely used as audio drivers in battery-powered systems such as smartphones.

The Class-D amplifier has the same switching behavior as a DC-DC buck converter (Fig. 1). The input reference is an audio signal which is modulated by Pulse Width Modulation (PWM) to generate a high frequency pulse train (about a few hundreds of kHz) [START_REF] Berkhout | Class D audio amplifiers in mobile applications[END_REF]. Thus, the output spectrum contains not only the audio frequencies in the audio frequency band [20 Hz -20 kHz], but also the high frequency harmonics due to the PWM switching. Even though, high frequencies are not audible, they produce high frequency ElectroMagnetic (EM) emissions that disturb the surrounding equipments, as well as the nearby circuits on the same Printed Circuit Board (PCB). Many published works focus on reducing these emissions with a circuit solution [START_REF] Cellier | A fully differential digital input class D with EMI spreading method for mobile application[END_REF]- [START_REF] Ming | An advanced spread spectrum architecture using pseudorandom modulation to improve emi in class d amplifier[END_REF]. Many other solutions have proposed filterless Class D amplifiers thanks to the speaker inductive nature [START_REF]Texas Instruments, AN-1497 Filterless Class D Amplifiers[END_REF] and its mechanical frequency response. However, the ElectroMagnetic Interference (EMI) filter is still mandatory in order to reduce the unwanted emissions and prevent any sys- Ferrite bead impedance (inspired from [START_REF] Murata | Understanding Ferrite Bead Inductors[END_REF]).

tem dysfunction, especially the radio communication (GSM, FM, etc.). Technically, the EMI filter has to prevent over the entire frequency band any perturbations from propagating to the speaker while keeping the audio signal in the audio frequency band intact.

For the integrated solutions such as smartphones, Surface-Mounted Technology (SMT) ferrite beads are used due to their impedance behavior along the frequency band. They allow a broadband filtering effect compared to an inductor (Fig. 2). In addition, ferrite beads are mainly resistive at high frequencies, thereby, they can dissipate the high frequency disturbances as heat (Fig. 2). The magnetic material gives the ferrite bead a higher inductance when used in the inductive region (Fig. 2) and a higher dissipation capability when used for EMI suppression. However, due to its saturation and hysteresis characteristics, the magnetic material introduces a non-linear effect into the component behavior. Thus, when used with a Class-D amplifier, besides the EMI suppression capability, ferrite beads have a direct impact on the audio signal quality. Fig. 3 shows an example of a Total Harmonic Distortion (THD) measurements for a Class-D amplifier with and without ferrite beads, for an output signal having a frequency of 1 kHz, an output power of 100 mW and an 8 Ω speaker load. Knowing that the ferrite bead used was chosen for its low THD degradation, it increases the THD from -69 dB to -53 dB which is a significant audio quality degradation. Moreover, Fig. 3 shows an increase in the odd harmonics and slight variation in the even harmonics. Note that the THD is the ratio of the sum of power of all the harmonics in the audio band over the fundamental frequency power.

In previous work [START_REF] Yu | Time-domain analysis of intermodulation distortion of closed-loop class-D amplifiers[END_REF], [START_REF] Koeslag | Analytical modeling of the effect of nonlinear switching transition curves on harmonic distortion in class D audio amplifiers[END_REF], the audio distortion caused by intermodulation or by switching transitions has been studied. However, the effect of the EMI filter was not been taken into account. In [START_REF] Haddad | Ferrite bead effect on Class-D amplifier audio quality[END_REF], measurements were done on a ferrite bead to experimentally quantify its effect in the audio frequency band. The results show a negative impact on the audio signal which can be seen by an increase in the THD, for the entire audio frequency range and for a wide range of amplitudes. However, by the authors best knowledge, there is no publication in the literature that simulate this phenomenon in the audio field. The most common model for ferrite beads is a linear model constructed by impedance matching [START_REF] Rostamzadeh | Modeling SMT ferrite beads for SPICE simulation[END_REF], [START_REF] Zhang | Ferrite bead model extraction and its application in high-performance ASIC analog power filtering[END_REF]. It is used for EMI simulations but is not able to predict the audio quality. Many other papers deal with modeling the magnetic materials for power electronics issues, such as inductors [START_REF] Sato | 3-D optimization of ferrite inductor considering hysteresis loss[END_REF], [START_REF] Cuellar | Characterization and modeling of hysteresis for magnetic materials used in emi filters of power converters[END_REF], transformers [START_REF] Rezaei-Zare | An accurate hysteresis model for ferroresonance analysis of a transformer[END_REF], [START_REF] Liu | Using TACS functions within EMTP to set up current-transformer model based on the Jiles-Atherton theory of ferromagnetic hysteresis[END_REF] or electric machines [START_REF] Woehrnschimmel | A combined hysteresis and eddy-current model developed for a wide frequency range in electric machine applications[END_REF], [START_REF] Cao | Complete parallelogram hysteresis model for electric machines[END_REF]. To study its impact on the audio signal, this paper models the ferrite bead using the Jiles -Atherton theory [START_REF] Jiles | Theory of ferromagnetic hysteresis (invited)[END_REF]. It models the impact on the output voltage with a 1 kHz sinusoidal current and explains the occurring phenomenon. In addition, the THD is calculated and compared to the THD of the measured signals at different amplitude levels.

The paper is organized as follows. It starts by modeling the ferrite bead in section II. Thus, an overview on the magnetic material modeling is presented. Then, it includes the physical architecture of the component. It proceeds to validate the model by comparing the simulation to the measurement in section III. This shows the time domain and the frequency domain results, as well as the THD for different amplitude levels. Section IV studies the influence of the magnetic material type on the audio distortion. Finally, section V summarizes and concludes the paper.

II. FERRITE BEAD MODELING

Modeling a ferrite bead can be separated in two parts: magnetic material modeling and physical architecture modeling. Both are discussed in this section and a simulation is shown in order to explain the occurring phenomenon.

The most common magnetic material models including the hysteresis and saturation are :

• D. C. Jiles and D. L. Atherton model [START_REF] Jiles | Theory of ferromagnetic hysteresis (invited)[END_REF]- [START_REF] Raghunathan | Theoretical model of temperature dependence of hysteresis based on mean field theory[END_REF], known as the Jiles -Atherton (JA) model

• John Chan et al. model [START_REF] Chan | Nonlinear transformer model for circuit simulation[END_REF], known as the Chan et al. model

• Ferenc (Franz) Preisach model [START_REF] Mayergoyz | The Classical Preisach Model of Hysteresis[END_REF]- [START_REF] Charap | Vector Preisach modeling (invited)[END_REF], known as the Preisach model

• C. D. Boley and M. L. Hodgdon [START_REF] Boley | Model and simulations of hysteresis in magnetic cores[END_REF], known as the Hodgdon model In the present work, the JA and the Chan et al. models have been used because they are accurate, practical to implement and widely used for ferrite materials [START_REF] Zhang | Quantification of required multi-segments for accurately computing induced voltage in a ferrite inductor using static and dynamic Jiles-Atherton models[END_REF].The results from both are very similar, however, only the results of the JA model are presented here. The reason is because we have access on JA parameters for different magnetic materials and the parameters of the Chan et al. model were deduced from the JA model simulating a given magnetic material. Thus, only an overview on the JA model is explained in this paper and a possible implementations can be found in [START_REF] Benabou | Contribution à la caractérisation et à la modélisation de matériaux magnétiques en vue d'une implantation dans un code de calcul de champ[END_REF].

A. Jiles -Atherton model

The JA model, in contrary to many other models in the literature, is based on a physical approach to describe the hysteresis loop [START_REF] Jiles | Theory of ferromagnetic hysteresis (invited)[END_REF]. The main idea behind it is to consider the energy related to the wall (known as Bloch wall) movements of the magnetic domains (known as Weiss Domains) inside a magnetic material. The hysteresis phenomenon is described as a friction force due to the wall movement during the magnetization process [START_REF] Benabou | Contribution à la caractérisation et à la modélisation de matériaux magnétiques en vue d'une implantation dans un code de calcul de champ[END_REF].

The JA model is related to two mechanisms. The first is the irreversible domain wall motion represented by M irr [A/m]. The second is reversible domain wall bending represented by M rev [A/m]. The magnetization M [A/m] of the magnetic material can thus be given by [START_REF] Gaalaas | Class D Audio Amplifiers: What, Why, and How[END_REF].

M = M irr + M rev (1)
M irr and M rev are described by ( 2) and (3), respectively.

dM irr dH e = (M an -M irr ) kδ (2)
M rev = c(M an -M irr ) (3)
where, M an [A/m] is the anhysteretic magnetization given by ( 4). H e [A/m] is the effective magnetic field given by [START_REF] Ming | An advanced spread spectrum architecture using pseudorandom modulation to improve emi in class d amplifier[END_REF].

k [A/m] is a parameter linked to the coercive field. If Inductor Resistor (R DC ) V fb V JA I fb V R
M an (H e ) = M sat coth H e a - a H e (4)
H e = H + αM an (5)
with

M sat [A/m] is the saturation magnetization, a [A/m]
is the shape parameter of M an and α [dimensionless] is the domain interaction parameter. Thus, (1) to ( 5) allow us to deduce the JA equation ( 6) that gives the variation of the magnetization M in terms of the magnetic field H.

dM dH = (1 -c) dMirr dHe + c dMan dHe 1 -αc dMan dHe -α(1 -c) dMirr dHe (6)
Finally, the magnetic induction B [T ] can be related to the magnetization M and the magnetic field H by ( 7)

B = µ 0 (H + M ) (7)
where µ 0 = 4πe -7 [H/m] is the magnetic permeability of the vacuum.

Each magnetic material has its own hysteresis characteristics. Thus, JA allows us to configure the model for a given magnetic material using the 5 parameters α, a, k, c and M sat . The determination of these parameters has been widely studied and discussed [START_REF] Hernandez | Identification of the Jiles-Atherton model parameters using random and deterministic searches[END_REF]- [START_REF] Toman | Parameter identification of the Jiles-Atherton hysteresis model using differential evolution[END_REF]. Table I gives some examples for 3 different magnetic materials [START_REF] Benabou | Contribution à la caractérisation et à la modélisation de matériaux magnétiques en vue d'une implantation dans un code de calcul de champ[END_REF].

B. Physical architecture modeling

The ferrite bead is an electric dipole. In the audio frequency band, it can be modeled as shown in Fig. 4. The resistor R DC is the DC resistor of the component. The ferrite bead voltage can be then described by ( 8)

V f b (t) = V JA (t) + R DC • I f b (t) (8)
where the voltage V JA (t) is the inductive part of the component and can be related to the magnetic induction B(t) using ( 9). I f b (t) is the component current and can be related to the magnetic field H(t) using [START_REF] Haddad | Ferrite bead effect on Class-D amplifier audio quality[END_REF].

V JA (t) = N • S • dB(t) dt (9)
I f b (t) = L N • H(t) ( 10
)
where N is the coil number, S [m 2 ] is the component effective section, L [m] is the effective component length, and t is the time.

Finally, the relation between B(t) and H(t) given by the JA model, allows us to have the relation between V JA (t) and

I f b (t).
This model is implemented and simulated in MATLAB environment. In order to expose the occurring phenomenon, a simulation example for a sinusoidal current of 22 mA and for a Ferrite N30 material is presented. Note that the model parameters are presented in Table II and the procedure of parameter extraction is presented in the next section. The hysteresis loop is shown in Fig. 5 and the voltage results are shown in Fig. 6.

As can be seen from Fig. 6, for a sinusoidal current, the product R DC × I keeps the sinusoidal form due to its linearity. However, the hysteresis magnetic loop modeled by the JA model, generates peaks in the voltage V JA (P 1 and P 2 in Fig. 6). These are caused by the high slopes of the hysteresis loop which cause a fast variation in V JA . The peaks occur at the current zero crossing (the same as H zero crossing according to equation [START_REF] Haddad | Ferrite bead effect on Class-D amplifier audio quality[END_REF]). Therefore, according to equation [START_REF] Yu | Time-domain analysis of intermodulation distortion of closed-loop class-D amplifiers[END_REF] the ferrite bead voltage is the sum of the two voltages V JA and R DC × I. As a result, the ferrite bead voltage is a non-sinusoidal signal containing peaks at the zero crossing of the waveform. The next section shows that this distortion occurs in the audio frequency band and causes audio degradation.

III. MEASUREMENTS AND VALIDATION

A. Measurements

The ferrite bead cited in [START_REF] Murata | HK102SN1D[END_REF] has been used for measurements in order to validate the proposed model. This component was chosen because it has a high internal DC resistance R DC (maximum of 1.5 Ω) even though it has a low nominal current (50 mA). This allows us to have a high voltage across the ferrite bead, allowing a better Signal to Noise Ratio (SNR) while measuring this voltage (V f b ). Notice that in industrial Class-D applications, ferrite beads are chosen with a lower internal DC resistance (around 50 mΩ for mobile phones) for better efficiency and a higher rated current (around 2 A for mobile phones) for thermal reasons.

The chosen ferrite bead is mounted on a PCB with an 8 Ω load similar to a speaker. The schematic is shown in Fig. 7 and used to validate the ferrite bead model, also, to evaluate the impact of the chosen bead on the audio distortion. Replacing the loudspeaker by a resistor will change the impedance behavior of the load. However, these changes do not impact the distortion of the electric audio signals. The nonlinear behavior of the loudspeaker and the capacitor are negligible compared to the one of the ferrite bead. This does not change then the analysis on a sinusoidal waveform because the current keeps the sinusoidal shape. The circuit is powered by a linear amplifier instead of a Class-D one. The main reason for this is to remove the high frequencies of a PWM spectrum and study the impact of the ferrite bead only in the audio frequency band. The signal generator delivers burst pulses of 5 sinusoidal periods with a frequency of 1 kHz. The pulses are separated by a delay of one second to avoid heating the component which would change the magnetic material characteristics. For V in = 1 V , the results of the ferrite bead voltage V f b and current I are shown in Fig. 8. It shows a similar voltage behavior as the one obtained by simulation in Fig. 6. This proves that using this model is appropriate for these ferrite beads. Peaks appear at the zero crossing of the signals (around 0 s, 0.5 ms, 1 ms and 1.5 ms). However, slight variations are also seen in the ferrite bead current at the same time as the voltage peaks.

I Supply GND V Gen V in V out

B. Component modeling

To model the ferrite bead [START_REF] Murata | HK102SN1D[END_REF] used for measurements, the following characteristics are needed: the DC resistance R DC , coil number N , effective section S, effective length and the 5 parameters of the JA model that characterize the magnetic material. Nevertheless, this information is not given by the component supplier. Therefore, they are obtained as follows.

First, the DC resistance has been measured by an impedance analyzer, thus, R DC = 1Ω.

A ferrite bead is a coil developed inside a magnetic material as shown in Fig. 9. Thus, the component has been broken in two pieces and seen through a microscope. The picture is shown in Fig. 10, and we see that this ferrite bead has the same physical architecture as the right hand architecture in Fig. 9. The coil number is N = 9 and the coil conductor is a pack of 3 conductors in parallel. It can be seen as well that the effective length is almost that of the component itself and the effective width is almost half that of the component width. Therefore, as the chosen ferrite bead [START_REF] Murata | HK102SN1D[END_REF] is a 0603 (1608 in metric dimension) SMT package, then according to the data-sheet L and S are 1.6 mm and 0.4 × 0.4 mm 2 , respectively. Note that, the effective section is considered as a square section.

The ferrite bead magnetic material reference and characteristics are not given by the supplier. Thus, the 5 parameters of the JA model, as well as the 3 parameters of the Chan et al. model [START_REF] Chan | Nonlinear transformer model for circuit simulation[END_REF] are unknown. As the material of the beads is ferrite, then to reduce the error due to the hysteresis loop characterization, the five JA parameters were assumed to be the same as those of known ferrite material found in [START_REF] Benabou | Contribution à la caractérisation et à la modélisation de matériaux magnétiques en vue d'une implantation dans un code de calcul de champ[END_REF] and presented in the first column of Table I. In conclusion, the required characteristics and parameters for the ferrite bead modeling are summarized in Table II.

C. Time domain simulations

The specified model is now used for simulation in MAT-LAB. The ferrite bead and load are in series connected (see Fig. 7). The load has a higher impedance in the audio band and it is a linear component. As the current is imposed by the higher impedance which is the load, it can thus be considered as a perfect sinusoidal waveform. This can also be seen in Fig. 8 where the current has a slight variation on the zero crossings. This assumption can be particularly valid in industrial applications as the ferrite beads are chosen with lower DC resistance (R DC ≪ R Load ). The ferrite bead model is fed by a sinusoidal current with an amplitude given by ( 11)

I P eak = V in R DC + R Load ( 11
)
where V in = 1 V similar to the measurements, R Load = 8.1 Ω is the measured load resistance and R DC = 1 Ω. Thus, the amplitude of the simulation current is 0.11 A. The latter is higher than the maximum current given in the datasheet which is based on the thermal characteristics of the components. However, as the measurements were made using burst sinusoidal pulses, the maximal current can exceed the rated current (defined for steady state). In addition, at this current level the magnetic material is saturated, but in fact, at current levels lower than the component rated current, the material would also be saturated (saturation appears for currents higher than 20 mA). Note also that in real audio signals, the crest factor (crest f actor = peak value/rms value) is generally higher than the one of a sinusoidal signal [START_REF] Russo | Dynamic voltage scaling for series hybrid amplifiers[END_REF]. The peak value is then considerably higher than the rms current. Therefore, a current level of 0.11 A can be a normal operating condition when using burst pulses. Therefore, this sinusoidal current feeds the model and generates the ferrite bead voltage which is compared to the measurement in Fig. 11. As a result, the simulations are in good agreement with the measurements. However, small differences are observed in the voltage curves. The reasons for this could be the measurement uncertainty or the JA parameters uncertainty which does not refer to the actual magnetic material. From Fig. 7, the output voltage can be given by ( 12)

V out = V in -V f b (12)
Thus, the output voltage across the load contains variations at the zero crossings due to the peaks in the ferrite voltage. As the variations are small and not very visible, the time domain signals are not shown for the sake of simplification.

D. Frequency domain comparison

A Fast Fourier Transform (FFT) is applied to the time domain signals. The frequency domain results are shown in Fig. 12 and Fig. 13. Fig. 12 shows that the simulated ferrite bead voltage V f b matches the measured one in the frequency domain. It therefore allows an accurate computation of the output voltage V out which is shown in Fig. 13. We can see that the fundamental signal is located at 1 kHz and the harmonics are spread over the audio frequency band. Moreover, there is also an increase in the odd harmonics of the output signal. This agrees with the case of a Class-D amplifier which is shown in Fig. 3. This can be explained by the fact that the hysteresis loop is symmetric around zero [START_REF] Metzler | Audio Measurement Handbook[END_REF]. From these results, we can deduce that the ferrite bead nonlinear behavior, due to the magnetic material, is a significant source of audio degradation in the Class-D amplification system.

E. THD comparison

The THD is applied in order to characterize the linearity of the audio systems. Using the spectra presented in the previous subsection, it is possible to deduce the THD of each signal. Therefore, it is calculated on each amplitude level and compared to the measured THD.

The measurements performed on the circuit in Fig. 7 have been repeated, but with different V in amplitude levels. Eleven voltage levels were chosen in the range of [100 mV ; 10 V ] which correspond to the current levels in the range of [10.98 mA; 1.01 A] and to the amplifier output power in the range of [1.1 mW ; 11 W ]. No points have been chosen below 100 mV due to the low measurement SNR of V f b . Hence, the THD has been calculated for V f b , V out and I at all the amplitudes, including the measured and simulated waveforms. In addition, the THD has been measured at V in and V out using an Audio Analyzer (AA) in order to validate the THD calculation procedure. The THD plots over the amplifier output power are shown in Figs. 14, 15 and 16. Note that, the THDs for the simulated V in and the simulated I are not shown because they are assumed to be perfect sinusoidal waves, thus, their THD in the dB scale tends toward -∞.

Fig. 14 shows that the simulated THD of V f b matches with the measured one at all the measuring points. Note that, the audio linearity is quantified by the output voltage THD and not the ferrite bead THD. However, the latter demonstrates that the ferrite bead model is accurate over a wide range of amplitudes. Moreover, a higher impact on the signal linearity can be seen in low signal levels than in high signal levels. This can be explained as follows: in V f b , the linear part R DC × I is greater at high signal levels than the nonlinear part V JA , the signal has therefore a better linearity at high signal levels.

From Fig. 15, three conclusions can be made. First, the simulated THD of V out is in a good agreement with both the THD measured using an AA and the THD calculated using the time domain measurements. Second, it shows an increase in the THD of V out compared with the THD of V in , which demonstrates that this ferrite bead is able to deteriorate the signal linearity up to 37 dB for the amplifier in use. Such degradation is significant on the commercial level, however, further psycho-acoustic investigation is required to evaluate the impact on the human ear. Third, even if the current is lower than the ferrite bead nominal current given by the supplier (which is 50 mA in this case), the nonlinear behavior of the magnetic materials still have a negative impact on the output audio signal.

Fig. 16 shows that the measured current has a noticeable THD which is not as visible in time domain signals. Thus, if a high accuracy is needed from this simulation, the current should not be considered as a perfect sinusoidal waveform. However, this assumption can still be valid if the amplifier is a current source instead of voltage one [START_REF] Sturtzer | Comparison between voltage and current driving methods of a micro-speaker[END_REF]. As the measurements in this paper have been made using a linear amplifier, it proves that the reason for audio degradation is mainly a low frequency phenomenon occurring in the audio frequency band.

In the integrated solutions, Class-D amplifiers are mostly differential systems. Their power stage is made by two switching cells that control the speaker. These generate opposite voltages which create the output audio signal across the speaker load. For such amplifiers, two ferrite beads are needed in the EMI filter. Thus, for the same output audio voltage, the amplifier can have double the effect observed in the case of a single ended amplifier.

IV. INFLUENCE OF MAGNETIC MATERIAL ON AUDIO

DISTORTION

Now that the model has been validated, it can be used for further simulations. What would be the difference on the signal distortion if we change the magnetic material type? This section deals with this issue and answers this question by the following.

We considered the same ferrite bead [START_REF] Murata | HK102SN1D[END_REF] and schematic (Fig. 7) that we used in the previous sections. Afterwards, for a fixed voltage level on V in equal to 100 mV (which means a current of 11.1 mA), we changed the five parameters of the JA model in order to change the material type. Thus, we used the JA parameters of the "Ferrite N30", "Ferrosilicon (Fe-Si)" and "Iron Powder" materials which are available in Table I. Fig. 17 compares the different hysteresis loops obtained by the different magnetic materials. We can see that for a magnetic field of 70 A/m (the bead current is equal to 11.1 mA), the Ferrite N30 would be close to the saturation with B = 0.268 T (at the saturation B ≈ 0.3 T ), the FeSi would not be saturated with B = 0.63 T (at the saturation B ≈ 1.3 T ) and the Iron Powder would not be saturated and is at low magnetization levels with B = 0.025 T (at the saturation B ≈ 1.2 T ). These hysteresis loops generate the V JA voltages presented in the first column of plots in Fig. 18, thus, the bead voltages presented in the second column of plots are obtained. As can be seen, the bead voltages are dissimilar if we change the type of the magnetic material. For an 11.1 mA current, no peaks are observed at the zero crossing of the bead voltage when using the Iron Powder material, however, the peaks are observed in the case of the two other materials. Also, in the FeSi case, the peaks are larger which must be due to the wider hysteresis loop (larger coercivity H c and larger remanence B r ) compared to the one of the Ferrite N30. Indeed, in the frequency domain the harmonic amplitudes are then different which can be seen in Fig. 19. In the case of Iron Powder, very low levels of harmonics are obtained. However, the harmonics are significantly increased when using the other two materials, knowing that, the FeSi has an unsaturated wide hysteresis loop and the Ferrite N30 has a saturated narrow hysteresis loop. Thus, not only the saturation of the magnetic material causes audio distortion, but also the hysteresis loop. Also, using the magnetic material at low levels of magnetization has a low impact on the audio distortion because the nonlinearities are not present yet in the component behavior. Moreover, it can be observed that in the case of the FeSi materials, the first harmonics are higher than those of the Ferrite N30 and the rest are lower. Thus, we can deduce that different magnetic materials can have different influences on the signal distortion.

A sweep of the voltage V in has been made in the voltage range [10 mV ; 10 V ] which corresponds to a current range of [1.1 mA ; 1.1 A] and power range of [9.9 µW ; 9.9 W ]. The THD for these amplitudes has been computed and it is shown in Fig. 20. We can observe that the shape and level of the THD curve strongly depends on the magnetic material type. In addition, when using the FeSi or the Iron Powder materials, the THD curves have a big dissimilarity compared to the one of the Ferrite N30 which is the one that agrees with the measurement as shown in the previous section. Therefore, we deduce that an accurate prediction of the audio distortion requires an accurate description of the magnetic material which has been made by JA modeling in this paper. Note that, a comparison between different materials from the ferrite family would be more interesting in order to improve ferrite beads for audio applications.

V. CONCLUSION

To conclude, using the Jiles -Atherton model for magnetic materials and the component physical architecture, a ferrite bead model has been established. It allows us to simulate these components as well as understand the occurring phenomenon when used in audio applications. This model has been compared to a measured 1 kHz sinusoidal signal for validation. The time domain results show the appearance of voltage peaks at the zero crossing of the ferrite bead current and the frequency domain results show an increase of the signal harmonics all over the audio frequency band. We also observe an increase is the odd harmonics which agrees with the measurement on a Class-D amplifier. The THD has been calculated for the simulated and measured signals. A comparison with the THD measurements using an AA, shows good agreement over a wide range of amplitudes. The ferrite bead in use can generate up to 37 dB of THD degradation in the audio signal. Also, it has been shown that both nonlinearities, the hysteresis and the saturation can generate audio distortion and the choice of magnetic material has a significant impact on the signal distortion.

Thanks to this model, the audio system integrators are able to include the audio quality as a new criterion in the procedure of EMI filter design for switching amplifiers.

Future work will focus on implementing a dynamic magnetic material model [START_REF] Sixdenier | Dynamical models for eddy current in ferromagnetic cores introduced in an fe-tuned magnetic equivalent circuit of an electromagnetic relay[END_REF], [START_REF] Chailloux | Magnetic behavior representation taking into account the temperature of a magnetic nanocrystalline material[END_REF], in order to take into account the frequency and temperature variations that affect the ferrite bead nonlinear behavior.

  Fig. 1. Class-D amplifier architecture.

Fig. 3 .

 3 Fig. 3. Example of Class-D THD and bargraph measurement. Note that, the more the bars are high the more the voltage is small since the scale is an inverted dB scale.

Fig. 4 .

 4 Fig. 4. Ferrite bead model in the audio frequency band.

Fig. 5 .Fig. 6 .

 56 Fig. 5. Hysteresis loop obtained by the JA model and the parameters of the first column in TableI.

Fig. 8 .

 8 Fig. 7. Measurement schematic.

Fig. 10 .

 10 Fig. 9. Ferrite bead physical architectures.

Fig. 11 .

 11 Fig. 11. Ferrite bead current and voltage.

Fig. 12 .Fig. 13 .

 1213 Fig. 12. Measured and simulated ferrite bead voltage.

Fig. 14 .

 14 Fig. 14. V f b THD over the amplitude.

Fig. 15 .Fig. 16 .

 1516 Fig. 15. V in and Vout THD over the amplitude.

  Fig. 17. Hysteresis loops obtained by the JA model, the parameters of Table I and an 11.1 mA peak current.

  Fig. 17. Hysteresis loops obtained by the JA model, the parameters of Table I and an 11.1 mA peak current.

Fig. 18 .

 18 Fig. 18. Bead simulations with the three materials of Table I and a peak current of 11.1 mA (1 mW of audio power on the load).

Fig. 19 .

 19 Fig. 19. Frequency domain output voltages with the three materials of Table I and a peak current of 11.1 mA (1 mW of audio power on the load).

Fig. 20 .

 20 Fig. 20. THD of Vout for different magnetic materials.

TABLE I JA

 I PARAMETERS FOR 3 DIFFERENT MAGNETIC MATERIALS[START_REF] Benabou | Contribution à la caractérisation et à la modélisation de matériaux magnétiques en vue d'une implantation dans un code de calcul de champ[END_REF]

	Parameter	Ferrite N30	FeSi	Iron powder
	α [dimensionless]	9.77e -5	1.31e -4	1.83e -3
	a [A/m]	20.25	59.5	1642
	k [A/m]	55.75	99.2	1865
	c [dimensionless]	0.9	0.54	0.8
	Msat [A/m]	28.2e 4	11.5e 5	11.2e 5

ACKNOWLEDGMENT

The authors gratefully thank Alaa Hillal and Fabien Sixdenier from the Ampere laboratory, Lyon, for the valuable discussion on magnetic material modeling.

Christian Vollaire was born, in 1968. He received his M.S.c in electrical engineering from the University of Saint Jérôme in Marseille (France) in 1992 and a PhD degrees in electrical engineering from the Ecole Centrale de Lyon (France) in 1997. From 1997 to 1998, he worked as graduate research assistant at the Ecole Centrale de Lyon. In 1998, he joined the AMPERE laboratory (UMR CNRS 5005). He carries out its research with AMPERE at the Ecole Centrale de Lyon in the field of the numerical modelling applied to the interaction between electromagnetic field and complex systems. He develops in particular specific formulations and numerical methods for the computation of electromagnetic fields in complex structures. One of the fields of applications relates to electromagnetic compatibility.

Angelo Nagari