Yazid Benazzouz

Oum-El-Keir Aktouf
email: oum-el-kheir.aktouf@lcis.grenoble-inp.fr

Ioannis Parissis

A fault fuzzy-ontology for large scale fault-tolerant wireless sensor networks

Keywords: Wireless sensor networks, fault tolerance, fault diagnosis, Web Ontology Language, fuzzy logic, Internet of things ;

Fault tolerance is a key research area for many of applications such as those based on sensor network technologies. In a large scale wireless sensor network (WSN), it becomes important to find new methods for fault-tolerance that can meet new application requirements like Internet of things, urbane intelligence and observation systems. The challenge is beyond the limit of a single wireless sensor network and concerns multiple widely interconnected sub networks. The domain of fault grows considerably because of this new configuration. In this context, the paper proposes a fault fuzzy-ontology (FFO) for large scale WSNs to be used within a Web service architecture for diagnosis and testing.

Introduction

New trends in wireless technologies aim to connect wireless sensor networks (WSNs) to Internet and mobile networks such as the infrastructure developed in [START_REF] Hughes | Looci: a loosely-coupled component infrastructure for networked embedded systems[END_REF] . This leads to large virtual wireless sensor networks incorporating multiple WSNs with different locations. Application scope for this technology includes environmental parameters observation and measurement, Internet of things, urban intelligence and intelligent transportation systems. Either more, fault tolerance for wireless sensor networks had taken a growing interest due to the importance of dependability and reliability in these systems and their applications. Nevertheless, no deep attention has been paid to fault tolerance in a large scale domain where fault tolerance is not limited to a single wireless sensor network. Many challenges act as a significant brake on the development of a fault tolerance mechanism for large scale wireless sensor networks (LS-WSN). First, LS-WSN often employs multiple networks where protocols, sensors and configurations are very heterogeneous. In addition, WSN are dynamic which means that the topology of the network, sensors and protocols may change by time. However, Fault tolerance technics are generally dependent to the network specifications and fault domain. Besides, in a large scale context there is a need for implicit monitoring that supports automatic composition of diagnosis and testing. Finally, fault tolerance in large scale wireless sensor networks should be addressed as an overall problem instead of focusing on local fault tolerance for each WSN.

The aim of this work is to propose a fault fuzzy-ontology to be used in a web services based framework for LS-WSN fault tolerance. It intends to:

• facilitate testing and diagnosis of large-scale WSNs,

• use ontologies to describe the area of faults, • design machines that can understand the situations of faults, • decide on the types of diagnostics to be performed, • support the self-test and diagnostics for fault tolerance, • permit adaptive testing and diagnosis in dynamic LS-WSNs. These points will be covered more in depth in the rest of this paper. This paper starts by giving the basics that have led to the development of fault fuzzy-ontology for large scale WSNs. Then, it presents the fundamentals of this ontology which is followed by a detailed example of service oriented architecture (SOA) supporting this ontology. The architecture is described from the fault tolerance side and does not address the network specifications like the topology, communication and so on.

An overview of service oriented architecture for sensor networks

Service Oriented Computing has emerged as a design paradigm for distributed execution environments. Services for these environments are generally considered as variants of Web services and have adopted their functioning principle. They are capable to communicate and provide modularity, scalability, composability and reusability to the architecture. Furthermore, services are used to overcome higher costs of development resulting from human intervention, evolution of services and dedicated design solutions.

In the area of wireless sensor networks, Web service-oriented architecture is proven to be an efficient design. It was proposed as an architecture model in 2 , 3 and, [START_REF] Klopfer | an open service architecture for sensor networks[END_REF] . Integration of sensors into service oriented architecture is usually done via software bridges that are managed by a gateway. These bridges provide access to different sensors from anywhere in the distributed environment. Accordingly, several network configurations might be imagined to design a large scale network using heterogeneous sensor protocols and gateways. An example of implementation is presented in [START_REF] Benazzouz | Sharing user iot devices in the cloud[END_REF] .

Sensors are often used to provide information on the physical environment such as temperature, humidity, pollution and noise level, user location, etc. In fact, sensors fault tolerance is supposed secondary despite the fact that it is necessary to avoid side effects, mainly when applications are critical, for example, in the case of an erroneous inundation information sent by a sensor to the city management system or the lack of presence sensor information in the building elevator. In both cases, this will conduct to a wrong decision. In fact, a research effort was done in [START_REF] Gwynne | Developing a fault ontology engine for the testing and evaluation of service-oriented architectures[END_REF] to include fault tolerance capabilities into service oriented architectures. The authors present an interesting fault ontology engine for testing and evaluating the architecture but this research does not cover the domain of wireless sensor networks. Further research effort might be directed towards fault modeling using ontology to better examine its adequacy to the area of wireless sensor networks. The following section provides additional details on such a proposal.

Why a fault fuzzy-ontology?

There are two main reasons for developing fault fuzzy-ontology for large scale wireless sensor networks. The first one is related to the choice of the ontology and the second one concerns the use of fuzzy logic within this ontology.

The choice of ontology in WSNs has been widely defended in the literature but the notion of faults is treated from the security point of view and not as a fault tolerance problem. The authors in 2 addressed the challenge in designing and managing complex sensor networks over heterogeneous communication infrastructures and presented ontology as efficient tools to describe the assets and services deployed in a sensor network infrastructure. Many ontologies have been proposed for sensor networks. The well-known ontologies were deeply studied in 7 and [START_REF] Compton | A survey of the semantic specification of sensors[END_REF] . It results that semantic representation for sensors uses descriptions of sensors, networks and domain concepts to aid in searching, querying and managing the network and data. Each ontology depends on its description capabilities and the purpose for which it has been developed, for example adaptive and heterogeneous networks support. However, no one of these ontologies covers the fault domain of wireless sensor networks. Thus, the goal of this study is not to develop sensor network ontology but to complete existing ones by integrating the fault domain concepts. The final report of the W3C Semantic Sensor Network Incubator Group1 recommends for organisations deploying sensors to monitor their assets to detect the possible occurrences of faults and the degradation in the quality of measurement over time (drift). To this end, the authors in [START_REF] Gwynne | Developing a fault ontology engine for the testing and evaluation of service-oriented architectures[END_REF] argue that ontologies are appropriate means for describing the fault, error and failure domains of systems. They can be used to enable machines to acquire the kind of knowledge necessary to develop their own strategies for testing and evaluating unfamiliar or large distributed systems. However, this latter work has not been addressed in the context of complex sensor networks and thus it does not take into account the infrastructure network particularities or the faults types' domain.

Regarding the use of fuzzy logic, Rolf Isermann 9 presented a study showing that fuzzy logic is a good method for fault diagnosis but it necessitates much design efforts. Since the ontology already needs some design efforts, it becomes interesting to pool both fuzzy logic and ontology together. In addition, observations in presence of faults in WSNs are uncertain. The use of approximate reasoning seems more adequate.

The development of a fault fuzzy-ontology for LS-WSNs will permit an interactive control of fault tolerance management through reasoning based diagnosis mechanism's and automated and composed testing procedures. The diagnostics procedure is based on the observed symptoms, expert knowledge and monitoring users experiences. In such system, the user is aware of types of faults the system is able to diagnosis. Diagnosis in fact is able to infer more information about detected faults. In addition, FFO (Faul Fuzzy-Ontology) for LS-WSNs will support heterogeneity of faults, devices and networks.

Fault fuzzy-ontology representation

An ontology is a model describing a domain concepts, their relationships and their properties. On the basis of this statement, fuzzy ontology extends the model with fuzzy annotations and fuzzy functions to support blurred and vague knwoledge.

In this study, a major part of fault domain knowledge is extracted from Abhinav study [START_REF] Abhinav | Sensors failure mode detection and self-validation[END_REF] . Then, a fuzzy faultontology (FFO) is developped using the fuzzy-ontology representation introduced by F. Bobillo and U. Straccia in [START_REF] Bobillo | Fuzzy ontology representation using owl 2[END_REF] and implemented under Protégé version 4.1 [START_REF] Ibbotson | Sensors as a service oriented architecture: Middleware for sensor networks[END_REF] and Fuzzy OWL2 Protégé plug-in [START_REF] Ibbotson | Model-driven soa for sensor networks[END_REF] . Figure 1 shows major concepts of sensors faults. The focus on these faults, rather than others like network faults, aims at showing by example the process of fault tolerance starting from ontology modeling to testing and diagnosis.

In the following, the description of the fault fuzzy-ontology is given in more details.

Fault categories

A fault is the cause of an error; an error is a part of the system state and can leads to a failure. A failure breaks down the system and should be repaired. Fault types can be classified into four categories: crash, measurement, transmission and byzantine faults. They are presented below.

Crash faults are common in wireless sensor networks. They occur when a sensor stops functioning or continue to operate without coming back to a stable state. The authors in [START_REF] De Souza | A survey on fault tolerance in wireless sensor networks[END_REF] have studied this type of faults giving some reasons behind crash fault such as battery-limitation and high environmental temperature. This fault occurs at four levels: node [START_REF] Taleb | A technique to identify and substitute faulty nodes in wireless sensor networks[END_REF] , cluster-head [START_REF] Gupta | Fault-tolerant clustering of wireless sensor networks[END_REF] , sink [START_REF] Saleh | Network fault tolerance in networked sensor systems[END_REF] and gateway [START_REF] Gupta | Fault-tolerant clustering of wireless sensor networks[END_REF] .

Measurement faults concern observable values sent by a sensor. These values can be invalid due to software and hardware failures, or to environmental conditions; for example, the deviation of an antenna. This type of fault occurs at the node level. Some methods were developed for measurement fault's recovery such as those based on testing in [START_REF] Koushanfar | On-line fault detection of sensor measurements[END_REF] and spatiotemporal correlation in [START_REF] Chen | Distributed fault detection of wireless sensor networks[END_REF] . Transmission faults are due to radio transmission failure or existence of obstacles for example. These faults occur at the network level. The authors in [START_REF] Boukerche | A fast and reliable protocol for wireless sensor networks in critical conditions monitoring applications[END_REF] propose multi-paths routing mechanism and those in [START_REF] Lazaridis | Fault tolerant evaluation of continuous selection queries over sensor data[END_REF] employ an intelligent acknowledgment technique.

Finally, byzantine faults are arbitrary faults happened usually when the behavior of the sensor becomes unpredictable. They occur at the node level. The work in [START_REF] Herbert | Detection and repair of software errors in hierarchical sensor networks[END_REF] presents a method to detect and to repair software errors that can lead to byzantine faults.

These categories form four class concepts in the ontology. They are used to classifying faults and identifying their related errors and testing methods.

Faults conceptual vocabulary

In this paper, faults domain is restricted to some hardware and software faults according to the those mentioned by Abhinav in [START_REF] Abhinav | Sensors failure mode detection and self-validation[END_REF] .

• Hardover refers to sudden change in the sensor output. The most common reason for Hardover fault includes deterioration of sensor components, total loss of power, and surface contamination. • Bias is discrepancies between measured and true values of plant output and input. Bias fault may exist when some of the electric components of the sensor are ageing, resulting in mismatch between the electric circuits. • Spike arises as a result of an unexpected disturbance in a hostile environment.

• Stuck is no variation in the sensor output, not even a sign of tolerable noise. Stuck fault would be reflected at the sensor output after the sensing line of sensor is fully blocked due to presence of impure materials. • Erratic refers to the increase in deviation of the sensor reading. Erratic fault may exist due to ageing of the sensing elements or external noise • Drift is a disturbance acting on the plant, which are normally zero and cause a shift in plant outputs independent of measured inputs.

Figure 2 presents these concepts structure in the hierarchy of the fault fuzzy-ontology.

Faults symptoms

Symptoms are indicators of faults. The sensor fault detection schema proposed in 10 is taken as an example to show how a fault fuzzy-ontology can be defined. This schema is based on statistical features extraction. Fault free data out of sensor is used to create threshold standards that are later used to detect sensor faults by comparing them with the one extracted out of online faulty sensor data. Main features are called limit, mean and standard deviation. For example, a Hardover indicator is positive if x(i) > X 4 , where X 4 is the high parameter threshold of the feature limit. Figure 3 shows the fuzzification of this indicator. This function is called xHigh and it is defined in the FFO as a fuzzy datatype.

In the same way, spike indicator is negative if vvk >= mk neg2 and vvk < mk neg1 where mk neg1 , mk neg2 are both threshold for mean limit for negative spike and mean limit for negative spike. The fuzzy membership function corresponding to this axiome is presented in Figure 3. This function is called MLNBSupMLNS and it is defined in the FFO as a fuzzy datatype. The rest of faults are defined according to this principle.

Faults fuzzification

The fuzzification of fault is described in the ontology using "class equivalence" and fuzzy datatypes as it is shown by Figure 4

WSNs errors

WSN errors are defined as fuzzy concepts. They are defined in the ontology using the annotation property fuzzyLabel. For example, the Component Ageing is described as a weighted sum concepts. It means that Component Ageing error induces an ErraticHigh fault at 50% and a BiasPositive fault at 50%. For this example, the estimation is chosen arbitrary.

<fuzzyOwl2 fuzzyType="concept"> <Concept type="weightedSum"> <Concept type="weighted" value="0.5" base="ErraticHigh" /> <Concept type="weighted" value="0.5" base="BiasPositive" /> </Concept> </fuzzyOwl2>

In the same way, Surface contamination is described by the following annotation.

<fuzzyOwl2 fuzzyType="concept"> <Concept type="weightedSum"> <Concept type="weighted" value="0.2" base="HardoverPositive" /> <Concept type="weighted" value="0.8" base="Stuck" /> </Concept> </fuzzyOwl2>

FFO based diagnosis and testing for LS-WSN

Diagnosis allows fault location and confinement. It is complementary to testing which consists of the execution of test units to detect malfunction by comparing obtained results with expected ones. In the literature, the study in [START_REF] Rodrigues | Diagnostic tools for wireless sensor networks: A comparative survey[END_REF] shows that WSN diagnosis covers the node level despite of the behavior of other nodes in a large network.

In addition to a previous investigation done by Hamdan et al. [START_REF] Hamdan | Test and diagnosis of wireless sensor networks applications[END_REF] , the proposed approach combines test and diagnosis to ensure dependability within WSNs. The idea consists of combining the usage of a fault fuzzy-ontology that describes each considered fault type with test execution and approximate-reasoning based diagnosis. The ontology includes task structure of diagnostic task and diagnostic process. It results in a web services based architecture that integrates different modules. They interact together to enhance dependability of WSNs by services provided through the WSN management interface. From the implementation view, large scale WSN is seen as a multiple number of gateways interconnected via Internet. Each one provides access to sensors, as well as gathering and disseminating data. LS-WSN gateway is implemented as an OSGi platform composed of three layers: -Sensors layer that cloud support one or multiple protocols like ZigBee, 6LowPan, etc.; -Middleware layer providing access to sensors. For each used protocol, a software bridge is developed and integrated into OSGi; -Fault diagnosis and testing management services (diagnosis reasoning service, test composition engine). In addition, a semantic transformation component is used to provide functions for ontology query and update. The general architecture is represented by Figure 5. The next two sections explain main components, namely diagnosis and test achievement.

Diagnosis

Fault diagnosis has been widely studied thus leading to many approaches. A short attention is given to these approches followed by a description of the proposed diagnosis process. Iman Saleh et al. [START_REF] Saleh | A fault tolerance management framework forwireless sensor networks[END_REF] , and Mahapatro et al. [START_REF] Mahapatro | Fault diagnosis in wireless sensor networks: A survey[END_REF] have studied different schemes for fault-tolerance in wireless sensor networks. The study shows clearly the lack of generality in fault-tolerance schemes. There is no solution that covers all types of faults, and likewise there is no fault tolerance method for a particular fault type. In this context, Rolf Isermann [START_REF] Isermann | Fault-Diagnosis Systems and An Introduction from Fault Detection to Fault Tolerance[END_REF] , defines a fault diagnosis task as the determination of the fault type with as many details as possible. The author goes further by comparing fault diagnosis methods separated in two groups: classification and inference methods. The author pleads for a mixture method using both sources of information: Expert or domain (structured) knowledge on the one hand and measured data from fault experiments on the other hand. Particularly, fuzzy logic presents at most better or equal characteristics such as transparency, use of explicit knowledge and good performance, but it necessitates much design efforts.

According to [START_REF] Kitamura | An ontological analysis of fault process and category of faults[END_REF] , the ontology of faults provides a conceptual vocabulary to describe the scope of a diagnostic activity performed by a reasoning mechanism and enables the user to control the diagnostic system by relaxing diagnostic assumptions interactively. Moreover, the ontology spcifies the underlying assumptions of faults, thus the reasoning could explain the occurred fault in more details. For example, it is not enough to find a fault such as "battery limitation of the node X" in a sensor network. The reasoning process is able to provide more information about the cause of this fault; for example, battery limitation of the node X is due to the oldness of the sensor.

In this paper, fuzzy diagnosis system is composed of set of rules described in fuzzyDL. fuzzyDL is a description logic reasoner supporting fuzzy logic and fuzzy Rough set reasoning. The authors in 1 proposed a parser translating a fuzzy-ontology into the languages supported by two fuzzy DL reasoners : fuzzy DL and DeLorean. Thus, FFO has to be translated into fuzzyDL language for reasoning. An example of the translation process is given hereafter.

• (define-fuzzy-concept MLPBInfMLPS triangular(0.0, 1000.0, 2.0, 2.5, 3.0) ) • (define-fuzzy-concept MLNBSupMLNS trapezoidal(0.0, 1000.0, 0.0, 1.0, 4.0, 5. Moreover, fuzzyDL allow multiple query expressions but first it is necessary to make a defuzzification of the individual variables. Variables in this case are individual instances of symptoms limit, mean and deviation presented in section 4.3. Three defuzzification methods are allowed: largest, smallest or middle of the maxima method. The rules bellow show a defuzzification example. The final part of the diagnostic process is the reasoning part using appropriate queries. The following example shows how faults and corresponding causes could be determined using indicator values which have been defined individually in the FFO. Figure 6 gives the results obtained for the complete scenario of the above examples. Among multiple conclusions, diagnosis indicates a stuck fault which has been likely caused by a surface contamination of the sensor components.

Test

Before explaining the testing part of this work, it is better to understand the testing goal to motivate this procedure. In the case of software systems, Miller [START_REF] Miller | Tutorial: Software testing & validation techniques[END_REF] argues that the principle of testing is to affirm software quality by systematically exercising the software in carefully controlled circumstances. Lu Luo 28 mentioned that a good test is one that has a high probability of finding undiscovered errors. Regarding SOA architecture, testing of wireless sensor networks deals with specific methods for ascertaining the end-to-end quality of sensors in real conditions, i.e., with real data and under real (or simulated) circumstances. Testing could be done at each level of the wireless sensor networks: node, sink, gateway, and network level. A potential technique should allow composition and automation of testing procedures like those performed when two or more tested levels are involved. More generally, the test often includes both the functional/requirement specification of each level and non-functional quality attributes, such as reliability, security, and maintainability.

In this approach, the novel idea that is adopted for the testing phase consists in the creation of new tests using atomic testing procedures by composition like web service composition style. Let's consider a scalable distributed execution environment which employs high number of continuous running sensors which are used to provide information on the physical environment such as temperature, pollution and noise level, etc. Two temperature sensors are installed in different zones of a building. Each sensor, belongs to its local WSN. The temperature was regulated to have the same level in the two zones. A Data Aquisition Errors test service is used to check for sensor faults that may be due to the presence an anomaly in the observed sensors reading. This test clould be done using services composition.

In this paper, the composition process is guided by a set of basic relation restrictions associated to services. The set of basic primitive relations is suitable to characterize the composition commitments. Relationships are expressed in the form: R(S r , S r ), where R is the composition relation (dependon, replacedby). Dependon defines service needs for other services to achieve its task while replacedby expresses similarity of services capabilities i.e., a service can replace another one for a specific task. The test example presented by the figure 7 This knowledge could be statically defined or specified by the administrator of the network. Accordingly, Service composition selects and composes services which satisfy the test query, i.e., the test for Data Acquisition Errors in this case. This knowledge is very elementary but additional relationship could be defined to make more complex composition processes.

Conclusion

Fault tolerance is strongly recommended for large scale wireless sensor network applications, particularly with the growing interest to the Internet of things and Smart Cities. This paper has addressed this requirement and motivated a service oriented approach to build diagnosis and test services for wireless sensors. The proposal includes an ontology model to describe fault, error and failure domain and to allow machines developing their own strategies for testing and diagnosis. This work gave birth to a first prototype which is not yet totally integrated but reflects potential application scenarios. It is however sill difficult to evaluate the impact of this approach in real cases due to the lack of development achievement. However, benefits are always here to permit further research investigation.

Fig. 1 .

 1 Fig. 1. Fault fuzzy-ontology structure.

Fig. 2 .

 2 Fig. 2. Hardware faults.

Fig. 3 .

 3 Fig. 3. (a)MLNBSupMLNS; (b) xHigh.

Fig. 4 .

 4 Fig. 4. HardoverPositive.

  for HardoverPositive fault. Each fault has an equivalent class written in the form of a rule as follows. HardoverPositive ≡ ∃hasLimit.xHigh SpikePositive ≡ ∃hasMean.MLPBInfMLPS ErraticHigh ≡ ∃hasDeviation.sHigh Stuck ≡ ∃hasDeviation.sMean BiasPositive ≡ ∃hasMean.MLPBSup

Fig. 5 .

 5 Fig. 5. LS-WSNs fault-tolerance platform.

  0) ) • (define-fuzzy-concept xHigh right-shoulder(0.0, 1000.0, 3.0, 4.0) ) • (define-concept Loose of Power (0.2 HardoverPositive) ) • (define-concept Surface Contamination (w-sum (0.2 HardoverPositive) (0.8 Stuck) ) ) • (define-concept Component Ageing (w-sum (0.5 ErraticHigh) (0.5 BiasPositive) ) ) • (define-primitive-concept Sensor Components WSN Error) • (define-primitive-concept Signal Conditioning WSN Error) • (define-concept HardoverPositive (some hasLimit xHigh) ) • (define-concept SpikePositive (some hasMean MLPBInfMLPS) )

•

  (instance m Mean 1.0) • (instance d Deviation 1.0) • (instance l Limit 1.0) • (instance m (= hasMean 1.3) 1.0 ) • (instance d (= hasDeviation 1.2) 1.0 ) • (instance l (= hasLimit 3.6) 1.0 ) • # • (defuzzify-som? HardoverPositive l hasLimit) • (defuzzify-som? ErraticHigh d hasDeviation) • (defuzzify-som? Stuck d hasDeviation) • (defuzzify-som? BiasPositive m hasMean) • (defuzzify-som? SpikePositive m hasMean)

Fig. 6 .

 6 Fig. 6. Scenario results.

Fig. 7 .

 7 Fig. 7. Test composition example.

  asserts that Data Aquisition Errors service depends on two other services: Loose o f power and Loose Connection; formulated as follow: Dependon(Data Aquisition Errors, Loose o f power), Dependon(Data Aquisition Errors, Loose Connection)

http://www.w3.org/2005/Incubator/ssn/wiki/Main Page

protege.standford.edu

gaia.isti.cnr.it/ straccia/software/FuzzyOWL/index.html


Le Roux
email: leroux@merl.com

J ; Vincent

Jonathan Le Roux

Emmanuel Vincent
email: emmanuel.vincent@inria.fr

A categorization of robust speech processing datasets

Speech and audio signal processing research is a tale of data collection efforts and evaluation campaigns. While large datasets for automatic speech recognition (ASR) in clean environments with various speaking styles are available, the landscape is not as picture-perfect when it comes to robust ASR in realistic environments, much less so for evaluation of source separation and speech enhancement methods. Many data collection efforts have been conducted, moving along towards more and more realistic conditions, each mak-ing different compromises between mostly antagonistic factors: financial and human cost; amount of collected data; availability and quality of annotations and ground truth; natural-ness of mixing conditions; naturalness of speech content and speaking style; naturalness of the background noise; etc. In order to better understand what directions need to be explored to build datasets that best support the development and evaluation of algorithms for recognition, separation or localization that can be used in real-world applications, we present here a study of existing datasets in terms of their key attributes.

This technical report aims to provide a list of speech datasets with detailed attributes and links to software baselines and evaluation results. Each dataset may be used for one or more applications: automatic speech recognition, speaker identification and verification, source localization, speech enhancement and separation... The core of the report is Table 1, which compares a wide range of datasets for robust speech processing based on their key attributes [START_REF] Crawford | Design, collection and analysis of a multi-simultaneous-speaker corpus[END_REF] . A list of links relevant to each dataset (to download/purchase, obtain baselines and results, etc.) is provided separately in Table 2.

Only datasets that are publicly available, (at least partially) annotated, suitable for research on robustness, and longer than 5 min are listed. Other relevant datasets are listed in Section 2.

The list of considered attributes and their meaning is detailed below.

General attributes

• year of release • scenario: car, cocktail party, domestic, lecture, meeting, office, public space, TV...

• total duration (h) (multiple channels counted only once)

• sampling rate (kHz)

• number of distant or noisy microphones

• number of video cameras

• cost for non-members of ELRA and LDC (cost for members is lower or free)

• links: download data, reference papers, software baselines, evaluation results...

Speech attributes

• duration of speech (h) (overlapping speech counted only once)

• number of unique speakers

• language

• number of unique words (differs from assumed vocabulary size, which is somewhat arbitrary)

• speaking style: digits, command, read, spontaneous...

• number of speakers present in the room

• type of speaker overlap: no overlap, simulated overlap, dialogue, meeting, full overlap...

Channel attributes

• channel type: none, simulated room impulse response, convolution by a recorded room impulse response, reverberant recording...

• speaker radiation: loudspeaker, dummy head with mouth simulator, human...

• speaker location: at a fixed position in the room, at a quasi-fixed position (e.g., seated), at different positions...

• speaker movements: no movement, head movements, walking...

Noise attributes

• noise type: stationary background noise (e.g., air-conditioning), car noise, meeting noises, domestic noises, outdoor noises...

Available ground truth

• reference speech signal: original (at the mouth), headset or lapel (slightly differs from the signal at the mouth), spatial image (at the microphones)...

• speaker location and orientation

• words uttered

Other datasets

The following datasets were considered but not included in the table for the reasons described below:

• BABEL [START_REF] Tanaka | Design and data collection for a spoken dialog database in the Real World Computing (RWC) program[END_REF] (not yet available)

• Broadcast news, HUB43 (no noise and 4.5 % speaker overlap, less than ETAPE)

• CIAIR In-Car Speech Database [39] (availability unknown)

• Dyrholm/Sawada/Parra4 (about 1 min long)

• NEMISIG [40] (unavailable)

• RATS 5 (not yet available)

• Rich Transcription (RT) (dataset gathered from other sets, e.g. CHIL, ICSI, ISL, AMI...)

• Settlers of Catan6 [41] (unannotated)

• Flying MEMS microphone array7 [41] (unannotated)

1

  Jonathan and Vincent, Emmanuel}, title = {A categorization of robust speech processing datasets}, institution = {Mitsubishi Electric Research Labs}, List of robust speech processing datasets

Table 1 :

 1 • paralinguistic attributes: nodding, gaze, communication intent, emotion... • noise events: type and time of individual noise events Comparison of robust speech processing datasets

	General attributes

Table 2 :

 2 Miscellaneous links for each dataset http://spandh.dcs.shef.ac.uk/chime_ challenge/chime2_task2.html HTK: http://spandh.dcs.shef.ac.uk/chime_challenge/ chime2_task2.html#tools Kaldi: http://spandh.dcs.shef.ac.uk/chime_challenge/ WSJ0public/CHiME2012-WSJ0-Kaldi_0.03.tar.gz results: http://spandh.dcs.shef.ac.uk/chime_challenge/ track2_results.html ETAPE download: http://www.afcp-parole.org/etape.html GALE purchase: https://catalog.ldc.upenn.edu/search?q% 5Bname_cont%5D=GALE REVERB SimData purchase: http://reverb2014.dereverberation.com/ HTK: http://reverb2014.dereverberation.com/tools/ REVERB_TOOLS_FOR_ASR_ver2.0.tgz Kaldi: http://www.mmk.ei.tum.de/ ˜wen/REVERB_2014/ kaldi_baseline.tar.gz results: http: //reverb2014.dereverberation.com/result_se.html results: http: //reverb2014.dereverberation.com/result_asr.html Sheffield Wargames Corpus download: http://mini.dcs.shef.ac.uk/data-2/ DIRHA download: http://shine.fbk.eu/resources/dirha-iisimulated-corpus

	Datasets	Links
	ShATR	download:
		http://spandh.dcs.shef.ac.uk/projects/shatrweb/
	LLSEC	download: https://www.ll.mit.edu/mission/cybersec/
		HLT/corpora/SpeechCorpora.html
	RWCP Spoken Dialog	download:
	Corpus	http://research.nii.ac.jp/src/en/RWCP-SP96.html
	Aurora-2	purchase (incl. HTK): http://catalog.elra.info/product_
		info.php?cPath=37_40&products_id=693
		features: http://aurora.hsnr.de/download.html
	SPINE1, SPINE2	purchase: https://catalog.ldc.upenn.edu/search?q%
		5Bname_cont%5D=SPINE
	Aurora-3 (subset of	purchase (incl. HTK):
	SpeechDat-Car)	http://catalog.elra.info/index.php?cPath=37_40
	RWCP Meeting Speech	download:
	Corpus	http://research.nii.ac.jp/src/en/RWCP-SP01.html
	RWCP Real	download:
	Environment Speech and	http://research.nii.ac.jp/src/en/RWCP-SSD.html
	Acoustic Database
	SpeechDat-Car	purchase: http://catalog.elra.info/search.php
	Aurora-4	purchase:
		http://catalog.elra.info/index.php?cPath=37_40
		HTK: http://www.keithv.com/software/htk/
	TED	purchase: https://catalog.ldc.upenn.edu/LDC2002S04
	CUAVE	download: http://www.clemson.edu/ces/speech/cuave.htm
	CU-Move Microphone	purchase: http://crss.utdallas.edu/
	Array Data
	CENSREC-1	download:
	(Aurora-2J)	http://research.nii.ac.jp/src/en/CENSREC-1.html
	AVICAR	download: http://www.isle.illinois.edu/sst/AVICAR/
	AV16.3	download: http://www.idiap.ch/dataset/av16-3/
	ICSI Meeting Corpus	purchase: https://catalog.ldc.upenn.edu/search?q%
		5Bname_cont%5D=ICSI
		info: http://www1.icsi.berkeley.edu/Speech/mr/
	NIST Meeting Pilot	purchase: https://catalog.ldc.upenn.edu/search?q%
	Corpus Speech	5Bname_cont%5D=NIST%20Meeting
	CHIL Meetings	purchase: http://catalog.elra.info/search.php
	SPEECON	purchase: http://catalog.elra.info/search.php
	CENSREC-2	download:
		http://research.nii.ac.jp/src/en/CENSREC-2.html
	CENSREC-3	purchase:
		http://research.nii.ac.jp/src/en/CENSREC-3.html

A maintained version of this table is available on the wiki of ISCA's Special Interest Group (SIG) on Robust Speech Processing: https://wiki.inria.fr/rosp/. This report is frequently updated to reflect changes on the wiki.

http://www.iarpa.gov/index.php/research-programs/babel

https://catalog.ldc.upenn.edu/byproject

http://bme.ccny.cuny.edu/faculty/parra/bss/

http://www.darpa.mil/Our_Work/I2O/Programs/Robust_Automatic_Transcription_ of_Speech_%28RATS%29.aspx

http://meetingdiarisation.wordpress.com/2013/05/09/ready-for-recordingsettlers-of-cattan-with-the-dmma-2-and-dmma-3/

[START_REF] Nakamura | Acoustical sound database in real environments for sound scene understanding and hands-free speech recognition[END_REF] http://meetingdiarisation.wordpress.com/2014/08/11/flying-digital-memsmicrophone-array-dmma-3/