Andre Dionisio Rocha

Diogo Barata

Giovanni Di Orio

Tiago Santos
email: tp.santos@campus.fct.unl.pt

José Barata

PRIME as a Generic Agent Based Framework to Support Pluggability and Reconfigurability using Different Technologies

Keywords: Multiagent Systems, Standard Technology, Plug and Produce, Reconfigurability, Distributed Systems, Evolvable Production Systems

Presently the manufacturers are facing a challenging and important period. The markets are very different comparatively to the past, with constant changes and facing a big crisis. Hence, with these new characteristics is very important for the companies quick adaptations in order to take advantage of new business opportunities. However on the shop floor is not easy reconfigure the production lines to perform new tasks. The PRIME framework presents an agent based solution capable to rapidly reconfigure and readapt the production line using standard technology. In this paper is demonstrated the usability of this framework with three completely different technologies. With this flexibility, using PRIME it is possible perform plug and produce, reconfigurability and monitoring for all kind of technologies, not obligating the companies to reform all components in the line, avoiding external costs and stoppages.

Introduction

The world and consequently markets are facing a global financial crisis. This crisis is one of the most challenging era in the entire history. With this new challenges, the enterprises need to re-adapt the entire way as they face these new market needs, more specifically, competitiveness, new customer needs and requirements. So, it is important for all the manufacturers, in particular Small and Medium Enterprises (SME), an effective approach, capable to allow these companies higher levels of flexibility, dynamism, and reconfigurability on the shop-floor level. As result of this new world, the manufacturers are constantly trying to solve the problem of volatility.

Nowadays the product life cycle is constantly decreasing and in some cases the companies are not able to re-adapt their production lines to new business opportunities because of the time and costs required for this re-adaptation. In order to allow SMEs to face this problem, recently a lot of production paradigms have been proposed and developed in academic environments. However, a real response for this problem was not acquired and the problem keeps present day-by-day inside companies. The PRIME architecture [START_REF] Antzoulatos | A multi-agent architecture for plug and produce on an industrial assembly platform[END_REF] developed in the scope of PRIME project, funded by the European FP7 program, proposes a new approach, this new approach results in a solution to perform plug and produce on the shop-floor using any kind of computational devices. This means that to run PRIME architecture as an agent based framework [START_REF] Rocha | An Agent Based Framework to Support Plug AndProduce[END_REF] performing plug and produce, in a production line, it is not necessary reformulate the entire system, introducing specific controllers with a minimum computational performance to run a framework capable to offer reconfigurability, adaptability and flexibility. In this document is presented a demonstration of how it is possible run this framework, using different controllers or PLCs, in the same production line, but using the same framework.

This document is divided by six sections. In the next sections is described the PRIME contribution to cloud-based engineering systems. In section three it is possible to see a literature review about this topic. In section four is described the PRIME Multiagent Framework and how this framework can detect and plug a new resource. Section five contains three different test cases, each test case represents a detection, in this case plug, of a specific resource, using different controllers (standard PLC, DPWS controller and Windows based controller). In the last section are compiled the conclusions and further works.

Contribution to Cloud-based Engineering Systems

In the last few decades the computational systems has suffered a huge improvement and development. The IT area is not an exception and as result of those improvements several cloud based solutions have been proposed for all different problems. The manufacturing systems are not an exception and in the last years several solutions have been presented to improve the performance and analyses of the systems. However, the main contributions have not resulted in valid solutions for the most of the current systems, because of the specifications and restrictions of each system, obligating to implementations very rigid and specific for each system. Without a generic way it is impossible for most of the SMEs manufacturers dispend a huge effort to implement an entire collector of data infrastructure, for its specific system. In this document is presented three different test cases using PRIME as a generic framework, capable to work with standard technology to collect all relevant data and store it into a database. Hence, this information can be used to perform data analyses, understanding the evolution of the system and possible changes. With this generic approach, the SMEs are able to quick and without unnecessary effort collect and process relevant data for the entire line.

Related Work

Over the last decades, the way as academics and enterprises look to the production lines has changed a lot. In this section it is described a brief study about some approaches and paradigms designed and developed under these new visions.

Agile Manufacturing

Agile manufacturing (AM) has been first proposed during the 1990s [START_REF] Yusuf | Agile manufacturing:: The drivers, concepts and attributes[END_REF]. During this decade many studies and developments were introduced in this topic. A nonconsensual definition for this concept was achieved but all they are basically related to responsiveness.

In [START_REF] Gunasekaran | Agile manufacturing: A framework for research and development[END_REF] "Agile Manufacturing can be defined as the capability of surviving and prospering in a competitive environment on continuous and unpredictable change by reacting quickly and effectively to changing markets, driven by customer-designed products and services".

Agile Manufacturing is a top down approach that covers the entire firm, is not a new production paradigm itself, but is more a new way to do business. However, the agility on the shop-floor level is not so easy to achieve and some new paradigms to manage the shop-floor behaviours and deal with all complexity have been proposed, such as Holonic Manufacturing Systems [START_REF] Leitão | A holonic approach to dynamic manufacturing scheduling[END_REF], [START_REF] Leitão | ADACOR: A holonic architecture for agile and adaptive manufacturing control[END_REF], Reconfigurable Manufacturing Systems [START_REF] Koren | Reconfigurable Manufacturing Systems[END_REF], [START_REF] Koren | Design of reconfigurable manufacturing systems[END_REF], Evolvable Assembly Systems [START_REF] Frei | Designing Self-Organization for Evolvable Assembly Systems[END_REF], [START_REF] Onori | Evolvable Assembly Systems Basic Principles[END_REF] and Evolvable Production Systems [START_REF] Neves | Evolvable production systems[END_REF], [START_REF] Ribeiro | Re-thinking diagnosis for future automation systems: An analysis of current diagnostic practices and their applicability in emerging IT based production paradigms[END_REF]. Those approaches bring flexibility and responsiveness to the shopfloor. To implement those kind of production paradigms, the enterprises should readapt the hardware in order to run intelligent entities inside each module on the line.

Evolvable Production Systems

The Evolvable Production Systems (EPS) paradigm has been first presented in the scope of EUPASS project [START_REF] Onori | An architecture development approach for evolvable assembly systems[END_REF]. The main idea in an EPS is a re-usage of modules in different or in the same production line constituting different systems with different valences, without any reprogramming effort. First of all it is necessary that all components are abstracted by intelligent entities. Those entities should be inserted in a society of entities (production line) and re-adapt them behaviours accordingly to the existent entities and current physical positions and status.

With this approach, the system has not a central unit to control the entire system, but distributed entities responsible to specific tasks. With this approach, it is possible introduce the concept of plug and produce. This means, plug a new resource (module) in the production line without being necessary stop the line, reconfigure the entire line and reprograming.

In the IDEAS project an architecture was proposed, based on CoBASA architecture [START_REF] De Oliveira | Coalition based approach for shop floor agility -a multiagent approach[END_REF], to perform those kind of behaviours on the shop-floor level [START_REF] Ribeiro | Self-organization in automation -the IDEAS pre-demonstrator[END_REF]. This approach is constituted by generic entities responsible to abstract different modules on the system and manage the availability of functionalities and tasks to be executed.

Although some possibilities were presented, as was described in this section, with the current economic state and needs, it is impossible for the SMEs change the entire hardware of the line to be able to run this kind of system. PRIME proposes a new generic approach, capable to run in hardware with different characteristics, fulfilling the current needs, without obligating the SMEs to change and reform the lines in order to run the previously presented approaches.

PRIME Multiagent Framework

The PRIME Multiagent Framework has been developed under the framework of the FP7 PRIME project. This framework has as main goal provide, in an easy way, reconfiguration, adaptation, plug-ability and monitoring in a shop-floor environment.

The framework provides these behaviours using different hardware and requirements. Hence, PRIME should provide all these behaviours in all possible production lines, such as production lines composed by standard technology or production lines constituted by intelligent devices. The framework is composed by generic agents and each one has a distinct task, as represented in Fig. 1.

Deployment Agent

Provide Data

Fig. 1. PRIME Multiagent Framework

Two databases are used to store relevant information, such as performance and status data, used by the system to perform monitoring, and information related to possible configurations for the resources plugged in the system, according to the production needs, such as product variants and usage of different resources for the same tasks. More specifically, when the operator wants to produce a new variant of products, the system is able to get the most appropriated configurations that should be sent for each component and, in this way, reconfigure the entire line accordingly to the specifications of this new variant.

The proposed framework is composed by eight distinct agents with different responsibilities, some agents are responsible to abstract and monitoring the hardware and other agents are more related to higher level actions, such as combination of different tasks that can be provided by the hardware, each task provided by each resource is described as skill that can be offered to the product. The product is described as a list of skills that must be performed by the system, in order to produce it. The PRIME Multiagent Framework is responsible to match those requested skills and reconfigure the entire line accordingly to those requirements. With this approach it is easier for the operator reconfigure the line, using the description of the necessary skills for a specific product.

• Prime System Agent (PSA) -The PSA is the higher entity in the entire framework. This agent is unique for each instantiation of PRIME, so is the central point of the entire framework. PSA is responsible to manage the PRIME Semantic Model where all the current state of the system, for example, topology and available functionalities, are stored. • Production Management Agent (PMA) -The PMA is responsible to aggregate resources and responsibilities which are localized in the same space, allowing the aggregated area to provide higher tasks orchestrating these aggregated resources. This agent works as a tree, in order to constitute different layers of aggregations and increasing modularity and scalability of the entire systems. • Skill Management Agent (SMA) -Each SMA works in pair with a specific PMA. The SMA is responsible to receive the existent skills in a PMA and combine, according to the defined rules, the higher level skills that the PMA can provide. • Component Agent (CA) -The CA is the lower entity and it is responsible by abstract each physical hardware that constitutes the topology of the system. More specifically, the CA write and read data related to the execution of the entity abstracted by it. The resource has the possibility to be configured by this agent and the CA can extract relevant data as well.

• Local Monitoring and Data Analyses Optimization Agent (LMDAOA) -

Similarly to the PMA and SMA, the LMDAOA works in pair with a CA. In this specific case, each CA has an associated entity of this type. This agent is responsible to receive the relevant extracted data from CA and pre-process it and analyses it, in order to define the first layer of monitoring. • System Monitoring and Data Analyses Optimization Agent (SMDAOA) -Each instantiation of the PRIME Agent Framework runs one SMDAOA. This entity is responsible to collect all relevant data of the system. All this relevant data should be provided by each LMDAOA. With this data, it will compute all the information, store in a global database with all historical data of the system, and perform monitoring analyses. This agent provides this data to the HMIA when requested. • Human Machine Interface Agent (HMIA) -The HMIA works as a gateway to external specific HMI. This agent as the capability to offer services which can be used by other entities to extract relevant information from the entire system. Hence, an external HMI to get relevant information, such as the current or older topologies of the system and data related to the execution of the entire system or a specific resource, should call the service that starts the communications between the agents which provides that kind of information.

• Product Agent (PA) -When the operator wants to launch a new variant of a product or even a new product, a PA should be launched containing all information which describes this new product, such as process plan with the necessary skills. The PA triggers the configuration routines with the PSA, sending the list of necessary skills. • Deployment Agent (DA) -In all the machines (controllers and computers),

where one or more PRIME agents will be launched, is mandatory that a DA is already running in each machine and must be the first agent launched. The DA has the responsibility to deploy (launch) all the necessary PRIME agents as CAs, PMAs, Pas, among others. With this feature is possible to launch any type of PRIME agents, available, in the machines, remotely. These classes enclose and abstracts all the generic interactions between the entities. However, the CA and DA should be extended to incorporate details about specific equipment, because these agents are directly connected to specific hardware.

Detection of New Resource (Hardware)

New physical devices, such as robots, grippers, etc. can be plugged, unplugged and re-plugged in runtime. In Fig. 2 is described all necessary interactions (messages which the agents should send and process) between the agents to provide pluggability. PRIME agents was developed using JADE framework [START_REF] Bellifemine | Developing Multi-Agent Systems with JADE[END_REF] and all performed communications are FIPA compliant [START_REF] Bellifemine | JADE-A FIPA-compliant agent framework[END_REF], more specifically is used the FIPA Request Protocol. Hence, with this functionality PRIME is able to provide plug and produce using all kind of technology.

Test Cases

PRIME, as was described in the previous section, is capable to detect and plug any kind of resource, with different scales of intelligence. Each device is described as one of these groups, accordingly to them capacities:

• Fully-intelligent resources: This type of resources are capable to autonomously run the necessary agents, such as CA, LMDAOA and DA. Usually this kind of resources are composed by Windows or Linux based controllers, capable to run Java environment. • Semi-intelligent resources: These devices are able to autonomously announce the existence of new resources. The device offers the possibility to reconfigure itself but without running locally the agents. • Passive resources: In this case, the device is a fully dummy resource, without any capacity of computation. To manage a device with these characteristics, another machine should run the necessary agents and monitoring the memory and connections with a standard PLC, responsible to control this hardware. Three different demonstrations were created in order to test the detection of these three types of devices by the PRIME Multiagent Framework. The entities which interact with the hardware implement a generic interface that contains all specific interactions with the hardware. The CA and DA implement specific Detection and Communication libraries respectively, for each resource.

Detection and Configuration of Fully-Intelligent Resources

In this case, it has been used an intelligent device. Using a controller from Elrest, running Windows XP Pro for Embedded Systems (Fig. 3), was possible to prove that PRIME is able to manage resources controlled by such devices. This kind of resources are the most suitable to integrate with PRIME, providing all the necessary information in an autonomous way. With a Windows based controller, PRIME agents can run locally, the DA, CA and LMDAOA. To detect resources controlled by these devices, when the controller executes the bootstrapping, automatically launches the DA which detects the current plugged hardware and starts the routines to launch the CA. The CA when launched, launches a LMDAOA. As the agents are running locally, when PRIME decides to configure a resource, the CA is able to write directly to the controller memory, changing the routines performed by it.

Detection and Configuration of Semi-Intelligent Resources

The second demonstration (Fig. 4) is responsible to prove the usability of Semiintelligent resources to detect and reconfigure physical devices in a production environment by PRIME. In this was used an INICO S1000 PLC, running DPWS framework that offers services, capable to run specific routines, as reconfiguration or detection of new components.

To

Detection and Configuration of Passive Resources

Although the usage of more powerful devices, as described in the previous sections, is important because of the natural evolution of manufacturing systems, standard technology still being the most common technology. The last demonstrator, represented in Fig. 5, represents how the PRIME platform is able to manage and interact with this kind of technology. Usually, a PLC is responsible to control a specific resource or a wrap of resources, such as robots or a conveyor belt. Hence, to integrate PRIME with the following structure of resources, it is necessary an external machine to run the agents. This external machine can be a computer or a Windows / Linux based controller, running a Java Virtual Machine and a JADE container. Inside this JADE container lives a DA responsible to detect the existence of new physical resources. In order to detect new resources, the DA extends a specific library for each case, for instance the DA can check the Ethernet ports in a local network or specific variables retrieved by the PLC. When detected a new device, a new CA will be launched to abstract the device. The CA, in this case with a standard PLC, extends a library capable to configure and consult the PLC memory, using standard protocols, such as an OPC connection.

Conclusions and Further Work

The PRIME Multiagent Framework was presented in previous works, with the capacity to perform reconfigurability and plug ability using standard technology. In this document was presented three different test cases that represents three different possibilities of abstractions made by the PRIME Multiagent Framework on the shopfloor using different technologies. The test cases were performed using resources controlled by Windows based controller, DPWS controller and standard PLC. In all the cases were possible to see the detection and reconfiguration of the resources using the different technologies.

With this demonstration, it is possible to say that PRIME effectively perform plug and produce, reconfigurability and monitoring using different technologies. This new proposal results in a new possibility for SMEs in a more flexible and re-configurable approach without wasting time and money adapting the entire line to the recent emerged production paradigms, which required machines with high performance.

In order to use this real advantage, it is now important to create all the tools that will be used by the operator to develop the lower level libraries, such as the detection and communication libraries. It is also important to define and create auxiliary software, capable to allow the operator an easy way to enable a module to run and to be detected by this framework.

Fig. 2 .

 2 Fig. 2. PRIME Agent Interactions during a Plug

Fig. 3 .

 3 Fig. 3. PRIME Agent environment using a Fully-intelligent Resource

Fig. 5 .

 5 Fig. 5. PRIME Agent environment using a Passive Resource

Product Agent HMI HMI Agent System Monitoring Data Analysis And Optimization Agent Deployment Agent Component Agent Local Monitoring Data Analysis And Optimization Agent Production Management Agent PRIME System Agent Skill Management Agent

	Configuration Data Base	Consult / Store Product	Update Topology Description Provide Topology Data	Request Information
		Templates and		Launch New Product
		System Skills
			Confirmation
			Request
		Provide Low Level	Configuration
		Topology	Request
			Configuration	Send Component
		Update		State
		Skills
				Consult /
				Store
		Inform New
		Hardware
			Deploy	Monitoring
				Data Base

  run this demonstration, a central machine such as a computer or a Windows / Linux based controller, should run the DPWS framework which is responsible to detect new INICO PLCs and call the services. The DA extends the libraries necessaries to launch and run the DPWS framework, and in a cyclic way checks if in this local environment was detected new resources (INICO PLCs), if yes, the DA launches a new CA in this central machine and this new CA is capable to send new configurations to the PLC, calling available services for that proposes.

	Computer Running	Deployment Agent	Deploy	Component Agent	Data Provide Hardware
	DPWS Framework	Detection Library		Communication Library	Local Monitoring Data Analysis And Optimization Agent
				DPWS
				Controller
				Physical
				Resource
	Fig. 4. PRIME Agent environment using a Semi-intelligent Resource

A.D. Rocha et al.

Acknowledgments. This research was supported by the EU Frame Work 7 project PRIME (Plug and Produce Multi-agent Environment, Grant Agreement No. 314762).


Lena Herscheid

Daniel Richter

Andreas Polze

Experimental Assessment of Cloud Software Dependability Using Fault Injection

Keywords: fault injection, dependability, distributed systems, cloud systems, availability

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

Introduction

Fault tolerance is an essential dependability requirement especially in distributed and cloud software systems, where components can fail in arbitrary ways, but a high availability or reliability of the service is nevertheless required.

To evaluate the dependability of complex software systems, a sufficiently realistic dependability model of the system needs to be built. Prominent dependability modeling languages such as fault trees or reliability block diagrams originally stem from the hardware domain. Designed for static systems consisting of thoroughly stress-tested hardware components with known error rates, they cannot reflect dynamic software traits [START_REF] Beizer | Software is Different[END_REF]. Since the behaviour of cloud software largely depends on interaction, timing, and environment factors, we believe that experimentation and runtime data is needed to construct such a dependability model.

Runtime software fault injection is a technique for artificially introducing faults, or error states, into the application execution in order to uncover bugs. In contrast to compile-time injection, not the source code, but rather the running system, potentially including its execution environment, is modified. Fault injection experiments are used to gain insights into the system's failure behaviour and its resiliency.

We propose to use a fault injection service for experimentally obtaining dependability data from OpenStack1 applications. We intend to use such data for building more realistic quantitative dependability models from distributed and cloud software, where much of the failure behaviour depends on dynamic and environmental factors. Ultimately, the framework discussed in Sections 0 and 0 will serve to answer the following research questions:

─ How does the unavailability of some nodes affect performance? ─ How does availability and consistency degrade in the presence of faults? With the CAP theorem [START_REF] Brewer | CAP twelve years later: How the" rules" have changed[END_REF] in mind, how are availability and consistency related to network partitions? ─ Which components suffer most from faults? Are there single points of failure?

Relationship to Cloud-based Solutions

In the cloud computing community, the need for resiliency testing of production systems has been acknowledged recently [START_REF] Tseitlin | The antifragile organization[END_REF]. There has been a paradigm shift --from trying to avoid failures at all costs to embracing faults as opportunities for making the system more resilient. The rationale behind fault injection testing of deployed software can be summarized as follows [START_REF] Allspaw | Fault Injection in Production[END_REF]: "It's better to prepare for failures in production and cause them to happen while we are watching, instead of relying on a strategy of hoping the system will behave correctly when we aren't watching." Even in the unlikely case that the software itself is bug-free, the infrastructure will eventually break, making resilience mechanisms necessary.

Fault injection can be viewed as the software equivalent to hardware stress testing. Based on the assumption that software systems will unavoidably suffer from external as well as internal faults, fault injection is a means for reducing uncertainty: The deployed system is observed under a realistic "worst case" faultload, and it should maintain a desired level of availability, performance, and service quality despite this faultload. Anecdotal evidence suggests that testing recovery mechanisms under faultload targets a relevant class of cloud software outages [START_REF] Gunawi | Failure as a service (faas): A cloud service for large-scale, online failure drills[END_REF]:

"All these outages began with root events that led to supposedly tolerable failures, however, the broken recovery protocols gave rise to major outages." Such outages can be avoided by routine fault injection experiments. The amount of effort put into the fault tolerance and resilience of cloud applications is often determined by Service Level Agreements (SLAs), and the trade-offs between development efforts, costs for redundancy, availability, and consistency are usually application-specific and based on management decisions. Fault injection can also serve as a tool for testing disaster recovery plans, which are necessary to avoid high losses in revenue in the case of failures. Gunavi et al. [START_REF] Gunawi | Failure as a service (faas): A cloud service for large-scale, online failure drills[END_REF] therefore propose a new kind of (node) "Failure as a Service" (FaaS). This is what we aim at providing.

Related Work

Table 1 summarizes related work in the area of distributed software fault injection. [START_REF] Dawson | ORCHESTRA: A Fault Injection Environment for Distributed Systems[END_REF], [START_REF] Stott | NFTAPE: a framework for assessing dependability in distributed systems with lightweight fault injectors[END_REF], [START_REF] Segall | FIAT-fault injection based automated testing environment[END_REF], [START_REF] Looker | Dependability assessment of grid middleware[END_REF] discuss tools for injecting faults into distributed systems mainly at the operating system and middleware levels. More recent approaches specific to cloud software are printed bold in table 1. Chaosmonkey [START_REF]Netflix: Chaos Monkey[END_REF] is a widely used, Javabased tool for Amazon Web Services (AWS) application resilience testing. The approach of injecting faults into deployed systems was first successfully employed by Netflix and later on adapted by other companies offering cloud-based software 2 .

Further approaches to providing resiliency testing services have been presented [START_REF] Ju | On Fault Resilience of OpenStack[END_REF] [9] [START_REF] Gunawi | Failure as a service (faas): A cloud service for large-scale, online failure drills[END_REF] [15] [15]. Their focus mainly lies on hardware fault models, namely network partitions and latency, as well as node crashes. There are also "fault model agnostic", configurable solutions such as [START_REF] Gunawi | FATE and DESTINI: A Framework for Cloud Recovery Testing[END_REF] [8] [START_REF] Allspaw | Fault Injection in Production[END_REF]. These solutions provide a framework for easily injecting faults, but the fault classes themselves have to be implemented to some extent by the user. Some fault injection testing for OpenStack has also been explored [START_REF] Ju | On Fault Resilience of OpenStack[END_REF]. The toolsets shown in Table 1 can be used with deployed applications with some additional integration effort. Our work is different from these approach in the sense that it aims at providing a standalone OpenStack service, and also targets a broader fault model which includes software faults.

When testing resiliency by means of fault injection, the representativeness of the emulated faults should be of major concern. A recent study [START_REF] Natella | On Fault Representativeness of Software Fault Injection[END_REF] shows that state-ofthe-art fault injectors do not inject faults according to realistic distributions, observed in real-world systems. Our fault injector will therefore inject software faults, based upon anecdotal evidence (e.g., as described in [START_REF] Gunawi | Failure as a service (faas): A cloud service for large-scale, online failure drills[END_REF]), instead of hardware faults only. Figure 1 depicts the architecture we propose for integrating fault injection as a service into the existing OpenStack ecosystem. Providing an API similar to other OpenStack services will make the tool easy-to-use and accessible. The fault injection daemon, which obtains fault scenarios from a database containing "faultload", should access the REST APIs of other OpenStack services in order to inject faults from different classes.

Fault Injection as a Service

OpenStack

OpenStack 3 is a prominent open source "cloud operating system", or cloud management stack. Encompassing a number of independent software projects interacting with each other through REST APIs, OpenStack is frequently deployed as a modular and configurable Infrastructure as a Service (IaaS) solution for web applications.

With an increasing number of applications built on top of OpenStack, a tool for experimentally assessing the dependability of deployed software is desirable. Therefore, we suggest to integrate fault injection into the OpenStack ecosystem as its own REST service. Our approach is targeted at testing a wide range of software artifacts: OpenStack services themselves, as well as applications deployed on top of OpenStack IaaS, get tested.

Implementing Fault Classes

Faults from some classes can be injected by merely using API calls in a non-intrusive fashion, others would require the insertion of custom hooks. In the following paragraphs, we discuss the targeted fault classes at different levels in the software stack: Physical node faults: Since hardware must be assumed to fail at random due to environmental stress or burn-in and wear-out phenomena, this fault class definitely has to be covered by an injection tool. The temporary or permanent outage of physical nodes can be simulated by cutting off messages from those nodes. In the case of compute nodes, API calls may also be used to shut them down. Furthermore, single nodes might suffer from increased CPU utilization (for instance because of other, computeintensive jobs running on them). This fault class can be implemented either using pernode hooks, or by starting more compute jobs via the API.

Virtualization level faults:

Relevant fault classes might be hypervisor service crashes or incorrectness (intrusive), or simply erroneous network configuration. Problems arising from the concurrent hosting of multiple VMs, over-commitment, or violated CPU quotas can be injected at the hypervisor level. Further, environment variables in VMs could be modified to assess their resilience against such robustness threats.

Service level faults:

The interaction between different OpenStack services might be malfunctioning. For instance, the API might be used in unexpected or incorrect ways. Such faults can be introduced by the fault injector daemon directly. Exhausted rate limits can be simulated by re-configuring the compute API 4 .

Network faults: Anecdotal evidence suggests that the assumption of a reliable, unpartitioned network does not hold in modern distributed systems 5 . To represent such network faults, message loss or delay, as well as partial or total network partitions can be introduced into the networking service.

Runtime Dependability Models

shows how we intend to use the fault injection service. The vision is a comprehensive framework which uses various sources to automatically run orchestrated fault injection experiments on a deployed cloud software system. From the observed runtime behaviour under faultload, dependability models, including quantitative data, shall be derived automatically.

and how often?

There is a vast amount of related efforts in the quality assurance domain: literature such as the Orthogonal Defect Classification (ODC) [START_REF] Chillarege | Orthogonal defect classification-a concept for in-process measurements[END_REF], as well as online resources. A recent trend is mining data from bug trackers and using collaborative defect databases such as the Common Weaknesses Enumeration (CWE) 6 . Pretschner et al. [START_REF] Pretschner | A generic fault model for quality assurance[END_REF] propose a fault model tailored for automatic testing. A literature study, with the goal of understanding state of the art software fault models, is currently in progress.

We believe that fault activation and error propagation patterns are of special interest for a broad class of distributed software failures. Understanding such environment-dependent patterns would enable the design of realistic faultloads and injection locations.

Conclusion and Future Work

As we have discussed, fault injection is a promising means for assessing the resilience of cloud software applications. Since the technique is used on deployed software, it yields more realistic failure data than static analysis approaches. We have proposed a draft architecture for "fault injection as a service" within the OpenStack ecosystem. The implementation of the service itself is work in progress.

In order to assess the system's behaviour under faultload, it needs to be observed. Running fault injection campaigns against a deployed system has the advantage that regular monitoring mechanisms can be used to observe how fault tolerant the system is. In the case of OpenStack, the in-built telemetry service Ceilometer7 provides information on the current state of the system. We still need to integrate monitoring into our architecture. Further approaches might be extracting dependability traits from logs, as demonstrated in [START_REF] Pecchia | Improving Log-based Field Failure Data Analysis of multi-node computing systems[END_REF].

A fault injection service would allow for non-intrusive resiliency tests, and can also be harnessed to experimentally assess the importance of single nodes with regard to overall application dependability. Ultimately, our goal is to use it for obtaining cloud software failure data, so that quantitative dependability models can be applied to make predictions.

Fig. 1 .

 1 Fig. 1. Proposed architecture for "fault injection as a service". The fault injection daemon accesses other OpenStack service APIs in order to inject different classes of faults. Monitoring and telemetry data should be gathered in order to evaluate how resilient the software is.

Fig 2 .

 2 Fig 2. Proposed experimental framework: Fault injection is used as a tool for getting runtime behaviour based dependability models. The faultload is designed according to applicationspecific information sources, such as profiler data, configuration, and documentation. A platform-independent fault model, which takes into consideration dynamic information, is needed for cloud software. Such a fault model would answer the question of which faultload is adequate: Which fault classes should be injected,and how often?There is a vast amount of related efforts in the quality assurance domain: literature such as the Orthogonal Defect Classification (ODC)[START_REF] Chillarege | Orthogonal defect classification-a concept for in-process measurements[END_REF], as well as online resources. A recent trend is mining data from bug trackers and using collaborative defect databases such as the Common Weaknesses Enumeration (CWE)6 . Pretschner et al.[START_REF] Pretschner | A generic fault model for quality assurance[END_REF] propose a fault model tailored for automatic testing. A literature study, with the goal of understanding state of the art software fault models, is currently in progress.We believe that fault activation and error propagation patterns are of special interest for a broad class of distributed software failures. Understanding such environment-dependent patterns would enable the design of realistic faultloads and injection locations.

Table 1 .

 1 Related work on distributed software fault injection. Work explicitly dealing with cloud platforms is printed bold.

	2	E.g.	StackExchange:	http://blog.codinghorror.com/working-with-the-chaos-monkey/,
		12/23/2014

L. Herscheid, D. Richter and A. Polze

www.openstack.org, 12/24/2014

www.openstack.org, 12/24/2014

http://docs.openstack.org/trunk/config-reference/content/configuring-compute-API.html, 12/24/2014

https://github.com/aphyr/partitions-post, 12/24/2014 130 L. Herscheid, D. Richter and A. Polze

http://cwe.mitre.org/index.html, 12/24/2014

https://github.com/openstack/ceilometer, 12/24/2014


Rogério Campos-Rebelo

Anikó Costa

Luís Gomes

Analysis and Generation of Logical Signals for Discrete Events Behavioral Modeling

Keywords: Signal Analysis, Modelling Formalisms, Embedded Systems

This paper presents a proposal for structuring logical signals for discrete events behavioral modeling. Graphical formalisms will be used to illustrate applicability of the proposed techniques. Input logical signals are generated based on the analysis of physical signals coming from the environment and other input logical signals. Their analysis is introduced in the flow of the input signal analysis, defined as pre-processing when using a modeling formalism. Their analysis is done in the first step of pre-processing, allowing to put these signals at the same level of the physical ones, enabling its use in the rest of the signals' analysis, and also allowing the generation of events and conditions associated with these signals. Likewise, logical signals are also defined in the flow of post-processing, allowing the definition of output logical signals through analysis and composition of the output signals generated by the model execution. The output logical signals are analyzed in the last step of post-processing in order to allow the use of the signals affected by the events in its analysis. The usage of these signals allows improvements in terms of expressiveness and compactness of the resulted models, both directly due to its use as well as by the increase of the possibilities of analysis provided to the following parts of the development flow.

Introduction

During the last decades, computer systems have experienced an increase in their complexity. The main reasons are related with the development of hardware that supports new functionalities, increasing memory and processing capacity, as well as software frameworks supporting their development. Becoming possible to create more complex systems, it allows the creation of more robust and enjoyable systems with more capabilities. Furthermore, their development becomes more complex and susceptible to failures, both in increase of quantity and variety. To handle these complexity problems, several approaches have been proposed in order to decompose the system development. The Model Based Development approach, as the Model Driven Architecture (MDA) defined by the Object Management Group (OMG) [1], is an example, which uses specific languages for system specification.

There is a wide variety of modeling languages. Among them, graphical languages are distinguished by providing an easier reading by the human user. Some examples of these type of languages are Statecharts [START_REF] Harel | Statecharts: A visual formalism for complex systems[END_REF], state-machines variants [START_REF] Börger | Abstract State Machines: A Method for High-level System Design and Analysis[END_REF], and Petri nets [START_REF] Jensen | High-Level Petri Nets[END_REF][5] [START_REF] Zurawski | Petri nets and industrial applications: A tutorial[END_REF]. They allow a graphical view of the behavioral model, providing a visual representation of the system behavior easily understandable (and analyzed) by a human user. Creation of quite large models makes them confuse and difficult to interpret. Therefore, decomposition of modeling techniques had been proposed, allowing creating less complex models. Some of these techniques allow transferring the signal analysis for pre-and postprocessing, removing them from an explicit representation within the model.

The growing development of the Service Oriented Architecture (SOA) and the Event-Driven Architecture (EDA) [START_REF] Bruns | Event-Driven Architecture[END_REF] combined with the reduction of cost in sensor technology have led, in the last years, to a big development in the use of events in the analysis of signals and system' behavior [START_REF] Eckert | Complex Event Processing (CEP)[END_REF]. Use of event modeling allows the development of more complex systems expressed through a much more compact model, supporting the development of much more user friendly interfaces.

One of the most well-known examples is the Complex Event Processing (CEP). They were first presented by David Luckham in his book The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems [START_REF] Luckham | The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems[END_REF]. They are used in different areas, as an application based in RFID presented in [START_REF] Zang | Complex event processing in enterprise information systems based on RFID[END_REF]. Together with CEP was defined RAPIDE [START_REF] Luckham | Rapide: A language and toolset for simulation of distributed systems by partial orderings of events[END_REF] [START_REF] Luckham | Specification and analysis of system architecture using Rapide[END_REF], a computer language for definition and execution of models of system architectures with CEP.

This paper emphasizes introduction to the pre-and post-processing flows allowing putting the techniques of logical signals analysis within them. This addition allows the modeler to use these techniques to define new signals from which the analysis through events can take advantage.

Relationship to Cloud-based Engineering Systems

Cloud-based engineering service-oriented systems are systems that allow the user to configure the system through services that are available online. In these systems, the software and hardware as services are reconfigured. Event-Driven Systems are similar, where the events are provided like services.

The work proposed in this paper presents the addition of logical signals to the signals analysis flow, in order to improve the detection of behaviors. The use of this flow with events makes it suitable for creation of event-driven systems, allowing an easier analysis of the signals. The use of the events like services in the model makes this proposal interesting to create cloud-based systems. We argue that the use of model-based development strategies within cloud-based systems will benefit from adopting the proposed signal analysis techniques.

Related Work

The analysis of input and output signals on pre-and post-processing is a solution that has been developed to solve the problem of increased complexity of the models. For this purpose, the entire analysis of signals from the environment is made outside the model, communicating with the model through the results of this analysis.

In terms of inputs, two forms are considered to analyze a signal: Condition -the value of the signal is analyzed to verify that a certain equation holds. A condition checks the signal value at a specific point in time. Event -the event analyzes the signal evolution in a time window (at least two points in time, associated with two execution steps) in order to verify if the signal evolution obeys to a specific defined behavior. Previously, signal analysis was also presented in [START_REF] Campos-Rebelo | Enhanced Event Modeling for Human-System Interactions Using IOPT Petri Nets[END_REF], considering not only the evolution of the signal values, but also variations of the signal at consecutive steps, as any difference level of variation of the signal (∆). The first level of variation (∆ 1 ) is defined as a difference of the signal value in two consecutive instants. The second level of variation (∆ 2 ) is defined as a difference of ∆ 1 in two consecutive instants. With these it is possible to define higher order of differences.

> ∆ m X n > k ≤ to > ∆ m X n-1 < k Λ ∆ m X n > k < to > ∆ m X n-1 < k Λ ∆ m X n > k ≥ ∆ m X n ≥ k < to ≥ ∆ m X n-1 < k Λ ∆ m X n > k > to < ∆ m X n-1 < k Λ ∆ m X n > k < ∆ m X n < k > to ≤ ∆ m X n-1 < k Λ ∆ m X n > k < to = ∆ m X n-1 < k Λ ∆ m X n > k ≤ ∆ m X n ≤ k ≥ to < ∆ m X n-1 < k Λ ∆ m X n > k > to = ∆ m X n-1 < k Λ ∆ m X n > k = ∆ m X n = k ≠ to = ∆ m X n-1 < k Λ ∆ m X n > k = to > ∆ m X n-1 < k Λ ∆ m X n > k ≠ ∆ m X n ≠ k = to ≠ ∆ m X n-1 < k Λ ∆ m X n > k = to < ∆ m X n-1 < k Λ ∆ m X n > k

Conditions Closed Events Open Events

In Table 1, the definitions are presented to an m-level variation. Given this set of assumptions, it is possible to define several ways to analyze a signal. The work presented in [START_REF] Campos-Rebelo | Elementary Events for Modeling of Human-System Interactions with Petri Net Models[END_REF] defines a set of elementary events, allowing the definition of a set of behaviors that the signal can have.

In Table 1, these types of events, defined as in [START_REF] Campos-Rebelo | Elementary Events for Modeling of Human-System Interactions with Petri Net Models[END_REF] as open and closed events, are presented, including the conditions that allow their determination. The various conditions are also presented, which allows analysis of a given signal value.

In a similar way, output signals can be affected by two different methods. They can be updated by an action directly over the signal or by creation of an event associated to the output signal that will determine the signal's behavior:

Action -it is an assignment action of the signal, at a certain moment, with a specific value, as in Signal_ID = k. Event -the event is associated with an output signal; when the event is active, generates a defined behavior with which the signal will be affected. The output events are defined in [START_REF] Campos-Rebelo | Output events for human-system interaction modeling[END_REF]. In this work, the behavior associated with the event, with which the signal will be affected are defined taking into account three variables: Evolution Function, Window, and Final Value.

The Evolution Function (f(n)) can be defined as any f(n) function. This function will guide the evolution of the signal, giving, for each execution step, the contribution value of the event to the associated signal. Generically the contribution of the event to the associated signal to each step n+p is equal to the value of f(p).

The Window (w) is an integer value that defines the number of steps following the occurrence of the event where the event contributes to the value of the associated output signal. For example, if the value of the window is 2, the event will contribute for the signal associated value in the execution steps n+1 and n+2.

The Final Value (fv) is the value that the associated signal should have at the end of the event contribution, which means at the end of the window.

To define the evolution behavior, it is necessary to define only two of these three variables (Evolution Function, Window, and Final Value). Therefore, three different types of output events, based on variables which are left free are defined.

Timed Assignment

Guided

Assignment Evolution Evolution Example

In Table 2 the three types of output events are presented. For each one, a graphical representation of a generic evolution is presented.

The Timed Assignment event is based on the definition of the window value and the value for the signal in the last step of the window. In this case, knowing previously the final value of the signal, the function needs to do the approximation to this value in the exact number of steps defined in the window.

The Guided Assignment event, as an assignment event defines the value for the signal in the last step of the contribution. The evolution function is defined as well with the final value of the signal. In this case, the window is not a priori defined. The window value is obtained as the number of steps needed to reach the final value guided by the defined function.

In an Evolution event, unlike the assignment events, the final value of the associated signal is not a priori known. The signal value evolves depending on the defined function associated to the event during the defined time window. The final value will be obtained accordingly, from the computation of the evolution function during the time window.

Signal Analysis

Input and output events, such as the conditions and the actions presented in the previous chapter, are defined as a way to analyze the signals in order to find or generate behaviors in the chosen input or output signal, respectively. As result of such definition the analysis of the input signal and the assignment of the output signals are transferred to pre-and post-processing, respectively. Consequently, the presented events are a result of the flow of pre-or post-processing.

This paper proposes to include, in the flow of pre-and post-processing, the analysis of logical signals, generated from the analysis of the physical signals and other logical signals.

Output Events

Output Signals

Physical Output Signals

Output Actions

Occurred Conditions

Primitive Events

Composed Events

Primitive Conditions

Composed Conditions

Occurred events These logical signals, after defined and calculated their values, will become available for analysis through events and conditions, such as the physical signals.

Input Signals

Although they are placed at the same level for the subsequent analysis, the value of the logical signals may represent quite different amounts.

With this addition the pre-and post-processing of the system, in terms of signals, is defined by the diagram in Fig. 1.

In the pre-processing part (Fig. 1-left) the values of the physical signals from the environment are received at each execution step. Then, based on their values, logical signals are defined and analyzed. They can be used in the analysis of other logical signals. After the analysis of the logical signals, these, together with the physical signals, are provided as a set of input signals for further analysis. In the next step the primitive conditions and events associated to the signals are calculated. Finally, based on primitive events and conditions, the composition of events and conditions are computed. Similarly as for logical signals, the analysis of some composed events and conditions can depend on the analysis of other events or conditions. The results of those analyses are introduced to the system model.

In the post-processing part (Fig. 1-right), the execution of the model generates events and actions associated to the output signals. These actions and events update the output signals by changing their values. Similarly to input signals, the analysis of a logical output signal can depend on the analysis of other logical output signals. After all the logic signals analyzed, the values of the signals generated by the events and actions in conjunction with logic signals are provided as outputs to the environment.

Physical Signals Analysis

Internal representation of a physical input signal is composed by the value received from the environment in the current time step and a series of values previously received during a time window. Associated with this window of values various levels of differences between values are also calculated. This list of values, as shown in Fig. 2, saves a set of consecutive values that the signal had in the past execution steps and the difference between them.

… A n-2 A n-1 A n A n-m

Signal Values

Physical Signal A … ΔA n-1 ΔA n ΔA n-m … Δ 2 A n Δ 2 A n-m … Δ m A n Δ m A n-1

Fig. 2 -Physical Signal Composition

This window with the history of values of the signal allows the analyses of events associated with the signal, and analyze logical signals. To calculate the size of this window is necessary to analyze all events and logical signals associated with that signal.

The number of deltas (steps) to be analyzed is given by the maximum of the largest deltas analyzed in each event associated with the signal.

Regarding the number of values to store in terms of Delta zero (d0), the value depends on delta (∆). The maximum value is given by the results in the following equation for each event associated with signal:

for ∆ n , d0 = n + 1 For instance, for an event that analyzes the ∆ 2 of the signal, the signal needs to hold 3 values (from An to An-2)

In terms of logical signals is necessary to find the oldest value being analyzed in the logical signal to determine how many values to hold.

Exemplifying, if the maximum value analyzed in a logical signal is ∆ 3 An-3, it will be needed to analyze values until the third delta and in the delta zero from An to An-6. The value is obtained by the following analysis: ∆ 3 An-3 = ∆ 2 An-4 -∆ 2 An-3; ∆ 2 An-4 = ∆An-5 -∆An-4; ∆An-5 = An-6 -An-5.

Logical Signals Analysis

A logical signal can represent different things, for example the conversions of the value of a physical signal in radians to degrees, the average value, or even complex values resulting from complex functions, like the FFT of a signal.

… D n-2 D n-1 D n D n-m Signal Values Logical Signal D … ΔD n-1 ΔD n ΔD n-m … Δ 2 D n Δ 2 D n-m … Δ m D n Δ m D n-1 Function f D (signals) Fig. 3 -Logical Signal Composition
In terms of its composition, the logical signal inherits all the characteristics of the associated physical signal. It also has a function (or set of functions) associated (Fig. 3). The values of the logical signal are the results of this function.

In the case of a logical signal, the values from n to n-m may not represent time steps. Although the representation is equivalent, it depends of the following processing steps to know the meaning of the values. At the end of the analysis, physical and logical signals become available to the rest of the analysis at the same level. This means that for the continuation of the flow does not matter if these signals come from the environment or have been generated.

INPUT SIGNALS Physical Input Signals

Logical Input Signals

On the other hand, the output signal analysis flow is accomplished through postprocessing, and the analysis of events and actions affecting the output signals is made in a similar way as for input signals.

After having analyzed all the events and executed all actions, a set of output signals is available. These signals are provided to the environment, but they are also used in the analysis of logical output signals.

The analysis of logical output signals is similar to the analysis of input logical signals. The flow is equivalent to the Fig. 4 where Input physical signals are replaced by Output Signals and Input Signals are replaced by physical output signals.

Thus, the analysis of the logical output signals is performed in the final steps of post-processing immediately before the last step where the output physical signals are available for the environment. The steps of analysis between the Physical Output Signals and Output Signals are similar to those presented previously between Physical Input Signals and Input Signals.

Discussion

This work intends to take advantage from techniques of generation of logical signals in order to improve the performance of the flow presented before, contributing to the compactness of the representation of dependencies on signals, where the analysis of the signals is moved to pre-and post-processing of the model.

The addition of logical signals is intended to get smaller and more readable models, removing complexity from the model to pre-and post-processing, in order to exploit the benefits of graphical modeling formalism and its readability by humans.

The definition of the logical signals in this flow, being analyzed through functions, allows a wide number of applications. It is possible to define functions that only convert a physical signal value into some unit of interest. For example, if there are two temperature sensors, one measuring in Celsius and other one in Fahrenheit, in order to allow the further analysis depending on the measured temperature by both sensors, it is necessary to create at least one logical signal that convert one of the temperature unit into the other one. For example, one can create a logical signal Tc (equivalent value in Celsius) associated to the physical signal Tf (temperature value in Fahrenheit). The function associated to the logical signal Tc is the following: Tc = ( Tf -32 ) * (5/9) This conversion allows in the next processing steps the analysis of the two signals under the same conditions.

Other example is the average value of the signal in the last 5 time steps Ta, or the difference between the present value and the value 5 steps before Td obtained by associate the following functions: Ta = (T0 + T1 + T2 + T3 + T4 ) / 5 Td = T5 -T0

It is also possible to present values resulting from the analysis of more than one signal, obtaining values of other quantities. For example, consider a vehicle inside a factory, controlled from a docking station where it must return to be recharged. It is possible to calculate the distance to the station (Ds), in order to know if it is still inside the control area, using the values that vehicle traveled in latitude (Lt) and longitude (Lg) associating the following function to a logical signal:

Ds = sqrt(Lt 2 + Lg 2 )
In a more complex way, it is possible to calculate values in a transformed space (not analyzed in the time domain), obtaining analysis such as spectral distribution when calculating the FFT of a given signal or even the average value of a set of signals.

Conclusions and Further Work

Moving the analysis of Logical Signals into the pre-and post-processing phases of the modeling flow provides a set of new capabilities for the analysis of signals to be used by the model.

This addition allows acquiring extra information from the signals coming from the environment, so allowing a more detailed analysis and defining more input conditions and output actions.

Moreover, this addition can also allow obtaining certain values without the need to add new hardware that would measure them, since this value could be determined by analysis of other signals. In this way, the number of variables available for use by events and conditions previously defined improves.

Comparing with models produced without these logical signal techniques, these additions will potentially contribute to a significant reduction of the models. In some cases they may even allow a huge compression of models as, for example, complex behaviors can be encapsulated in an event that depends on logical signals.

FCT -Fundação para a Ciência e a Tecnologia" in the framework of projects PEst-OE/EEI/UI0066/2011 and PTDC/EEI-AUT/2641/2012.

Fig. 1 -

 1 Fig. 1 -Pre-and post-processing flow

Fig. 4 -

 4 Fig. 4 -Analysis of Input Logical Signals.

Table 1 -

 1 Events and Conditions Definition

Table 2 .

 2 Output Events definitions.

R. Campos-Rebelo, A. Costa and L.Gomes

R. Campos-Rebelo, A. Costa and L.Gomes

Acknowledgments. The first author was supported by a Grant from project PTDC/EEI-AUT/2641/2012, financed by Portuguese Agency" FCT -Fundação para a Ciência e a Tecnologia". This work was partially financed by Portuguese Agency"


Tiago Ferreira
email: tiago.ferreira@holos.pt

Fábio Miranda
email: f.miranda@campus.fct.unl.pt

Pedro Sousa

José Barata

João Pimentão

Context Classifier for Service Robots

Keywords: Context, Service Robots, Reliability, Fuzzy Sets, Bayes Networks

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

Introduction

Aside from our language and the common understanding of the world and its operation, what contributes to a much more efficient exchange of knowledge between human beings, is the notion of context [START_REF] Dey | Towards a Better Understanding of Context and Context-Awareness[END_REF]. Humans are able to add and take into account situational information (context) in a conversation to better understand the subject, retain more information in a more efficient way and to respond appropriately to it, in other words, to increase the conversational bandwidth as said in [START_REF] Dey | Towards a Better Understanding of Context and Context-Awareness[END_REF]. When interacting with machines or between machines, that awareness can be lost and so can the information richness [START_REF] Dey | Understanding and Using Context[END_REF].

As the matter of environment (as a subset of context) regards the physical world, there is also uncertainty associated with its sensing. That uncertainty can be caused, for example, by inaccuracy or incompleteness of sensed information [START_REF] Haghighi | Reasoning about context in uncertain pervasive computing environments[END_REF]. There is a need for models that manage and take into account that uncertainty [START_REF] Bettini | A survey of context modelling and reasoning techniques[END_REF]. Fuzzy logic is used to set transitions of an element between membership and non-membership in linguistic terms and it involves ambiguity [START_REF] Zadeh | Fuzzy Sets[END_REF]. It can be used to describe subjective contexts and perform a multi-sensor fusion between those contexts.

Bayesian networks consist in nodes (that represent events) and arcs (representing relationships/conditional dependencies). Nodes not connected represent variables that are conditionally independent. Bayesian networks are used to process data sets and to deduce high level information [START_REF] Bettini | A survey of context modelling and reasoning techniques[END_REF], assigning the most likely class to a given observation, described by a set of attributes. According to [START_REF] Russell | Artificial intelligence: a modern approach[END_REF] this technique is best suitable for a factored state representation in which a state consists of a vector of attributes.

Relationship to Cloud-based Solutions

The presented architecture was developed using Robotic Operating System (ROS) [START_REF] Quigley | ROS: an open-source Robot Operating System[END_REF] on top of the Servrobot platform (servrobot.holos.pt). ROS allows for the exchange of information between software modules within the system using a messaging protocol. These software modules need not to be in the same machine or system and may send messages across the Internet. As the architecture is a software module itself it can receive and send information to other modules or robots. In this sense this architecture is scalable to receive inputs from several service robots. This is a typical application scenario for Cloud-based technologies use thus it can be used by a community of service robots contributing with their own contextual experience to dynamically improve the classification architecture and it's performance. Robotearth is an example of cloud-based technologies use in robotics [START_REF] Kehoe | A Survey of Research on Cloud Robotics and Automation[END_REF].

State of the Art

Context has been used in the robotic field in many applications using several context models and or techniques [START_REF] Miranda | Review on Context Classification in Robotics[END_REF]. A detailed review was made focusing on the application of context in the field. The most relevant results are presented in Table 1.

Table 1. Overview of context models in robotic systems their application purpose

Application Purpose Context Model/Reasoning Technique

Object Recognition Markov Random Field (probabilistic classifier) [START_REF] Varvadoukas | Indoor Furniture and Room Recognition for a Robot Using Internet-Derived Models and Object Context[END_REF], Ontologies [START_REF] Wang | Ontology Modeling and Storage System for Robot Context Understanding[END_REF][START_REF] Choi | Ontology-Based Semantic Context Modeling for Object Recognition of Intelligent Mobile Robots[END_REF] Safety Dempster-Shafer [START_REF] Nienhiiser | A Situation Context Aware Dempster-Shafer Fusion of Digital Maps and a Road Sign Recognition System[END_REF], Ontologies [START_REF] Schlenoff | A robot ontology for urban search and rescue[END_REF] Human-machine interface Polynomial classifiers [START_REF] Trovato | Generation of Humanoid Robot's Facial Expressions for Context-Aware Communication[END_REF], Hidden Markov Model [START_REF] Mou | Context-aware assisted interactive robotic walker for Parkinson's disease patients[END_REF] Localization Ontologies + Bayesian model [START_REF] Yi | Bayesian robot localization using spatial object contexts[END_REF] Navigation Ontologies [START_REF] Provine | Observations on the use of ontologies for autonomous vehicle navigation planning[END_REF] Smart Environments Ontologies + Logic [START_REF] Mastrogiovanni | Context assessment strategies for Ubiquitous Robots[END_REF], Ontologies [START_REF] Hristoskova | Heterogeneous Context-Aware Robots Providing a Personalized Building Tour[END_REF] As it can be understood from Table 1, ontologies seem to be the most used technique to support machine learning in the robotics field. Applications include several areas and reliability seems overlooked.

Implementation

Problem Approach

As it was stated before there are several applications for context analysis in the robotics field but context can be integrated in other applications as well. It is believed that the reliability field hasn't explored context in complete way. Context can and should be integrated in the reliability field allowing reliability calculation optimization.

A classification hierarchy is proposed, in which the context is first classified as indoor environment or outdoor environment and then there will be another computational model created to sub-classify in more detail the type of environment present. In Fig. 1 the reliability context architecture is presented. It will first receive the sensor inputs and process its signals in order to reduce any noise and outlier values as well as to perform any necessary sensor fusion. In the knowledge base the information from sensors and sensor fusion are stored. A context classifier is created that will provide contextual information to the reliability calculation. Those classifications will be also stored in a context history module. This history can be re-fed to the classification module to improve performance. From that history the last state will be considered for the current classification.

Architecture Overview

It is believed that the environmental conditions will influence a great deal the reliability calculation and estimation. The key elements present in the surroundings may be crucial for optimizing reliability assessment, for example if a mobile robot is working under a very dusty outdoor environment it may be more prone to have mechanical failures thus reducing its reliability.

Architecture Implementation

Managing Input Sources.

The physical sensors taken into account in the architecture and their fuzzy linguistic terms are:

• Thermometer for temperature ("very hot", "hot", "comfortable" and "cold"); • Hygrometer for humidity ("very high", "high", "comfortable" and "dry");

•

Photosensor for light ("very high", "high", "medium", "low" and "very low");

• GPS module for the number of satellites ("high", "medium", "low" and "none"); • IMU for the soil type ("concrete", "pavement" or "smooth"); • GAS detector for gas level ("dangerous" or "non-dangerous" atmosphere);

• Time used to distinguish the "day" and "night" formalisms.

Fuzzy Logic Membership Functions.

Fuzzy logic was implemented to transform a sensed numeric value into a linguistic term (a qualitative semantic), therefore fuzzification was used to aggregate the sensor inputs. This will increase the flexibility and modularity of the overall algorithm over the slight changes in the sensor values (also decreasing its complexity and load).

The fuzzification was applied to temperature, humidity and light intensity. For each of them tests were conducted during various times of the day and weather conditions to achieve the necessary linguistic terms and membership functions. In this work the functions were chosen with no specific form, but there are many forms that can be assigned (triangular, trapezoidal, Gaussian, etc.).

Choosing the Classification Model.

Since ontologies are often specialized to some domain-specific applications (although they are used for many different purposes), it was preferred not to model the world around the robot "statically" by describing its relations "manually" in the beginning. Instead, the main interest is in one technique that could be taught and that can adapt to new situations.

The environment is partially observable because the robots sensors cannot give access to all the complete state of the environment at each point in time. Since its being dealt with a stochastic environment, the classification task is a sequential activity, a single classification at a time considering the previous state is performed, there is a dynamic environment and can be considered discrete, a factored representation is present the technique should support probabilities and uncertainty. Therefore the most suitable technique for classification is a Bayes classifier (Bayes network). It seemed to be a good start since it has good performances, even with less training data, is highly scalable, can adapt to a wide variety of classification tasks and is appropriate for a factored representation of data.

Field Tests and Experiment Results

From the first dataset collected, an 87.5% of correctly classified instances were obtained, using a 10-fold cross-validation evaluation on the training dataset. The confusion matrix represents TP (true positives), FP (false positives), FN (false negatives) and TN (true negatives). From Table 2 it can be understood that 119 instances were correctly classified as "indoor" out of a total of 121 indoor instances (true positives). A more detailed accuracy table is presented below (Table 3). TPR (True Positive Rate), also known as sensitivity or recall measures the proportion of positives that are correctly classified as such. FPR (False Positive Rate), also known as false alarm rate or fallout it's the complementary with the specificity (1specificity). Precision represents the positive predictive values. Specificity (also known as TNR -True Negative Rate) measures the proportion of negatives, which are correctly identified as such (complementary of FPR). F-measure a combined measure for precision and recall.

It was found that the number of GPS satellites is the most relevant attribute, although all other attributes are needed to increase systems consistency and accuracy.

A mixed environment test including the "previous state" attribute was done. In Fig. 3, a mixed testing path is presented. The indoor path is represented in blue color, the outdoor path is represented in red color and the transition areas are represented in orange. In Table 4, the obtained confusion matrix is presented. In this test the percentage of correctly classified instances was increased to 92.66% of overall accuracy. From the incorrectly classified instances, the 2 FP cases are located on step 6 of the Fig. 3 and they occurred due to the presence of a glass wall in the room. Near the glass wall, the classifier can be deceived. Regarding the 19 false negative cases, 2 of them occurred on the step 5 of the path (Fig. 3) which is the transition step, 6 of them occurred in step 18 due to the presence of a porch and the fact that the GPS attribute is slower to acquire satellites when moving from indoor to outdoor environments. The majority of the FN cases (11) occurred in step 17, which is another transition step. It's now possible to remake all the calculations for the real application scenario. In Table 5, those calculations are presented. Very good results were achieved in specificity and sensitivity (a perfect classifier should be 100% specific and 100% sensitive) as well as a decrease in the FPR. Considering the "previous state" attribute in the classification, the most relevant attributes where: "light", "GPS satellites", "previous state" and "temperature web".

As can be seen by these results this architecture is able to achieve similar results to those in [START_REF] Zhou | IODetector: A generic service for indoor outdoor detection[END_REF] even without the previous state optimization (around 88%). When the previous state is included the results improve by approximately 5% in comparison.

Conclusions and Future Work

There are several context models, techniques and frameworks. From all of those possibilities the ones based on ontologies seem to be the ones with most widespread use. From all existing frameworks and for the intent of this architecture, machine-learning techniques, particularly Bayesian networks, seemed to be the more appropriate method for solving the systems classification problem. This is verified by the good results achieved by this system. One big reason for the good results in the system was the inclusion, in the architecture, of the previous state in the Bayes network. Future experiments should be considered with more linguistic terms in the fuzzy sets (for example, "morning", "afternoon", "late afternoon" or "night" instead of just "day" or "night" for the time). Increasing the attribute quantity can add a valuable improvement in the overall performance. However, increasing the number of attributes doesn't necessarily improve the systems accuracy.

It is believed that a good base was created for a more complex and detailed classification. As knowing if the robot is indoor or outdoor with good accuracy allows a detailed context sub-classification.

Fig. 1 .

 1 Fig. 1. Reliability context integration architecture

Fig. 2 .

 2 Fig. 2. Bayes Network

Fig. 3 .

 3 Fig. 3. Holos mixed testing path

Table 2 .

 2 Confusion Matrix

	Indoor	Outdoor	Classified as
	119	2	Indoor
	17	14	Outdoor

Table 3 .

 3 Detailed performance measures

	TP Rate	FP Rate	Precision Specificity	F-Measure	Class
	0.983	0.548	0.875	0.452	0.926	INDOOR

Table 4 .

 4 Confusion Matrix from the mixed testing path

	Indoor	Outdoor	Classified as
	119	19	Indoor
	2	146	Outdoor

Table 5 .

 5 Detailed performance measures

	TP Rate FP Rate Precision Specificity F-Measure Class
	0.862	0.014	0.885	0.986	0.873	INDOOR

In this work the WEKA [22] framework was used to generate the Bayes network for this classification. In Fig. 2 the Bayes network is represented with the different attributes and relations to the proposed output classification.

Reliability.

To integrate this work in reliability calculation a context factor must be added in the calculation.

Where is the reliability, is the module hazard rate, is the terrain factor and is the time. The terrain factor can be calculated by:

Where is the terrain factor asserted to terrain x and is the total percentage of the operating time in terrain x. The proposed architecture results can be integrated in this factor by substituting the terrain concept by the context concept.


Hugo Cordeiro

Carlos Meneses
email: cmeneses@deetc.isel.ipl.ptjmf@uninova.pt

José Fonseca

Continuous Speech Classification Systems for Voice Pathologies Identification

Keywords: Voice Pathologies Identification, Continuous Speech, Gaussian Mixture Models, Support Vector Machines

Voice pathologies identification using speech processing methods can be used as a preliminary diagnostic. The aim of this study is to compare the performance of sustained vowel /a/ and continuous speech task in identification systems to diagnose voice pathologies. The system recognizes between three classes consisting of two different pathologies sets and healthy subjects. The signals are evaluated using MFCC (Mel Frequency Cepstral Coefficients) as speech signal features, applied to SVM (Support Vector Machines) and GMM (Gaussian Mixture Models) classifiers. For continuous speech, the GMM system reaches 74% accuracy rate while the SVM system obtains 72% accuracy rate. For the sustained vowel /a/, the accuracy achieved by the GMM and the SVM is 66% and 69% respectively, a lower result than with continuous speech.

Introduction

Voice pathologies are caused by different factors such as the extensive or incorrect use of voice, stress, tobacco smoke inhalation, gastric reflux or hormonal problems. These pathologies typically affect the vocal folds and are detectable by direct laryngoscopy, which is the visualization of the vocal folds using a camera. However, this method is invasive, uncomfortable for the patient and may, depending on the equipment used, require a local anesthetic. The diagnostic equipment is also expensive and has high maintenance costs, requiring sterilization between diagnoses.

The use of an efficient, non-invasive, easy and fast method in pathologies recognition may be useful as an initial evaluation or as a complementary method for the diagnosis of voice pathologies. A method of voice pathologies diagnosis based in speech signals is especially useful in screening situations because it doesn't involve specialized equipment.

Several works in pathological voice identification discriminate between healthy and unhealthy subjects, without the identification of the pathology. Some works in pathological voice identification [START_REF] Lieberman | Some acoustic measures of the fundamental periodicity of normal and pathologic larynges[END_REF][START_REF] Iwata | Periodicities of pitch perturbations in normal and pathological larynges[END_REF][START_REF] Shama | Study of harmonics-to-noise ratio and critical-band energy spectrum of speech as acoustic indicators of laryngeal and voice pathology[END_REF][START_REF] Cordeiro | Spectral Envelope and Periodic Component in Classification Trees for Pathological Voice Diagnostic[END_REF] use features like pitch jitter, shimmer, harmonic-to-noise ratio (HNR) and energy spectrum to discriminate unhealthy subjects. Other works use features like MFFC [START_REF] Dibazar | A system for automatic detection of pathological speech[END_REF] and wavelet analysis [START_REF] Fonseca | Wavelet time-frequency analysis and least squares support vector machines for the identification of voice disorders[END_REF]. In [START_REF] Sáenz-Lechón | Methodological issues in the development of automatic systems for voice pathology detection[END_REF] a comparison between different systems and features in pathological voice identification can be found.

There are few works in voice pathologies identification and all use the sustained vowel /a/ as speech signal. In this task, features like jitter and shimmer alone are not sufficient to discriminate pathologies [START_REF] Scalassara | Relative entropy measures applied to healthy and pathological voice characterization[END_REF]. In [START_REF] Markaki | Using modulation spectra for voice pathology detection and classification[END_REF], spectral modulation and SVM are used to detect polyps pathology among three pathologies and healthy voices, using the vowel /a/ from the MEEI corpus [START_REF] Elemetrics | Elemetrics Disordered Voice Database[END_REF]. The system achieves an average recognition rate of 90%. The features are obtained by spectral modulation where the discrete spectrum of the signal is modeled in sub-bands. The signal obtained from patients with polyps presents a higher energy in the pitch band. After feature extraction, an algorithm based on principal component analysis is used for dimensionality reduction. Finally, feature selection based on mutual information is used to sort only the most relevant characteristics.

In [START_REF] Markaki | Voice Pathology Detection and Discrimination Based on Modulation Spectral Features[END_REF], the authors compare the results obtained in previous work [START_REF] Markaki | Using modulation spectra for voice pathology detection and classification[END_REF] with those obtained with the MFCC as parameters. The results obtained are approximately 25% lower than the results obtained by spectral modulation.

In [START_REF] Muhammad | Automatic voice disorder classification using vowel formants[END_REF] five different pathologies are identified, assuming that the voice is pathologic. Two Arabic vowels equivalent to /a/ and /i/, where tested from a corpus consisting of numbers from 1 to 10, with 72 patients, thus generating 720 speech signals, where 80% are used for training and 20% for testing. From each vowel the value of the first and second formant are extracted taking 4 or 5 frames in the middle of the speech signal (where it is more stable). Using these four features a neuronal network achieves a recognition rate of 67.8% for male patients and 52.5% for female patients. Tests were also conducted with a classifier based on vector quantization but the results were inferior to those obtained by the neural network. It is reported in that work that, in some diseases, a deviation in the formants mean values allows the discrimination of the pathologies. In [START_REF] Fonseca | Normal versus pathological voice signals[END_REF] wavelets are used in a MLP (Multi Layer Perception) neural network for identification between nodules and Reinke's edema. The accuracy reaches 87% for Reinke's edema and 86% for nodules using 80% of the data for training and 20% for independent testing. In [START_REF] Carvalho | Wavelet transform and artificial neural networks applied to voice disorders identification[END_REF] the authors use jitter in the wavelets components with SVM (Support Vector Machines) to perform distinction between nodules and Reinke's edema. Using a similar dataset as in [START_REF] Fonseca | Normal versus pathological voice signals[END_REF], 82% accuracy has been achieved. Also for this database SVM classifiers were used to evaluate the impact of the first peak bandwidth presented in [START_REF] Cordeiro | Edema and Nodules Identification in vowels using spectral features and jitter[END_REF], pitch jitter and pitch in Reinke's edema vs. nodules identification. With the vowel /a/ the results obtained using the first LPC spectral peak achieves an overall accuracy 84.6% and do not improve by using additional features like pitch jitter. The results obtained are in line and sometimes overlap the results reported in previous publications with the same corpus, but in this work the test uses 50% of the data.

In the previous referenced works the vowel /a/ speech signal was used in pathological voice classification. In [START_REF] Dibazar | A system for automatic detection of pathological speech[END_REF], continuous speech signals were also used and the results are compared with the obtained with the vowel /a/. The classifiers use MFCC and HMM and show 99.5% accuracy for the vowel /a/ and 98.6% for continuous speech. In this work, it was found that pathological voice recognition can be done based on continuous speech. However, continuous speech signals analysis has never been tested for voice pathologies identification.

The main objective of this work is to evaluate which voice signal has higher potential for voice pathologies identification: the vowel /a/ or continuous speech. The latter assumes that voice pathology have speech characteristic that are phoneme independent. To inspect that, the two signals are evaluated using MFCC as speech signal features, applied to SVM and GMM classifiers.

Relationship to Cloud-based Solutions

As mentioned in the previous section, the area of pathological voice recognition is growing but there are few works on pathologies identification. One of the reasons is the lack of a reference database for the area development. Pathological voice recognition has numerous advances and in many cases recognition rates over 90% are achieved. However, for pathologies identification there is a considerable lack of data, since it must be divided by pathologies. The data shared in the cloud make possible to have more data and more important provide the same data to define strategies for studies comparison. For that, it is possible to establish a criterion for the acquisition of speech signals from subjects with pathologies. This can be done in innumerous institutions that can disseminate and share this information in the cloud. The Research from this topic always involves multidisciplinary teams and sharing information in the cloud will certainly produce important advances in the automatic diagnostic of voice pathologies.

Database

For training and testing the systems the MEEI database [START_REF] Elemetrics | Elemetrics Disordered Voice Database[END_REF] was used. It contains 53 healthy subjects and 724 subjects with voice disorders. For these two set of subjects, the sustained vowel /a/ and a continuous speech excerpt, "rainbow passage" are available. Of all subjects with pathologies, only 477 have the information about the pathologie. This work uses the nodules, edema, unilateral vocal folds paralysis pathologies diagnostics and healthy subjects. The signals were recorded with a sampling rate of 25 kHz or 50 kHz. For this work all the files were down sampled to 25 kHz. There are 17 files from healthy subjects from the "rainbow passage" (continuous speech) recorded at 10 kHz that have been removed, resulting in a total of 36 healthy subjects.

For this work, two sets of pathologies were defined. A first set with subjects diagnosed with the physiological disorders edema and nodules. A second set was created with subjects diagnosed with unilateral vocal fold paralysis, a neuromuscular disorder. Each of these sets contains 59 files. A third set have 36 healthy subjects. Table 1 shows the database distribution by gender.

Nodules

Vocal fold nodules are benign lesions that can occur in both vocal folds, in places where friction is higher. Its location is usually at the junction of the anterior third and the posterior two thirds. When the vocal folds vibrate, impact zones exist and it is precisely in these areas where the lesions that cause nodules appear. This disease is common in people who intensively use their voice, as politicians, teachers, singers and children that often yell. The nodules are small, about the size of a pinhead and can appear over a given area on groups. The main symptoms are dysphonia, with the change in the voice tone, via a variable hoarseness. In extreme cases it may be possible to achieve a complete aphonia. Nodules do not allow complete closure of the vocal folds thus adding noise to the speech signal. To compensate for this effect the subjects tend to increase the tension in the muscle, further increasing collision that forces the vocal folds.

Vocal folds Edema

The vocal folds edema increases the volume of the vocal folds. Causal factors are the use and abuse of the voice in which in some cases the subject may suffers from nodules. This pathology can be also due to the use of tobacco or drugs, excessive coughing, menstruation, menopause or pregnancy. The increase in the volume of the vocal folds causes changes in its elasticity with the consequent change in the voice timbre.

Vocal folds Paralysis

The vocal folds paralysis is a peripheral neurology disorder. The tension and position of the vocal cords are controlled by the laryngeal muscles, which in turn are controlled by the nervous system. The vocal cord paralysis arises when these muscles cannot perform its function. The paralysis is in the muscle although the vocal folds can continue to vibrate in a not controlled way. The paralysis can be caused by various phenomena, such as compression of muscles due to infections, tumors or intoxications. The paralysis typically affects only one vocal fold. This implies that each fold vibrates at a different frequency. In these cases, the voice has a bimodal sound and the patient cannot speak loudly losing the power of vocal amplification. In this work, only unilateral paralysis is evaluated.

Implemented Systems

In this section the systems implementation and the data organization used to perform the tests between the sustained vowel and continuous speech signals are described. In the end results are presented.

As previously mentioned, speech signals used on this study were acquired with a sampling frequencies of 25 kHz or 50 kHz. To normalize the training set, all samples were down sampled to 25 kHz. The features extracted from the speech signal were MFCC, energy and delta-energy. MFCC coefficients were estimated using filter banks scale 25-mel in 20 ms frames with 10 ms overlap. Several tests were conducted from order 8 th to 24 th . All the data was normalized with zero mean and unit variance. In the vowel /a/, with a duration between 3 and 5 seconds, all frames are analyzed. In the continuous speech, the silence zones were removed using the endpoint algorithm proposed in [START_REF] Lamel | An Improved Endpoint Detector for Isolated Word Recognition[END_REF].

Dataset Organization

Two classes of pathologies were created: physiological lesions composed of edema in the vocal folds in a total of 59 subjects; and neuromuscular disorder with 59 subjects with unilateral paralysis of vocal folds; a third class with 36 healthy subjects is used.

The systems were trained with 75% of the data and tested with the remaining 25%, resulting in approximately 15 test subjects in classes with pathologies and 8 speakers in the healthy subjects. The k-fold cross-validation method [START_REF] Kohavi | A study of cross-validation and bootstrap for accuracy estimation and model selection[END_REF] was used. In total 4 systems were created in order to rotate the train and test set and evaluated all data set.

SVM System

Support Vector Machines (SVM) classifiers are typically used has a two class classifier. In order to have a multiclass classifier, three SVM models were trained. This approach his known as one-against-one [START_REF] Chih-Wei | A comparison of methods for multiclass support vector machines[END_REF] and in this technique for N classes N(N-1)/2 SVM classifiers are trained. In this case, classifier #1 compares physiological pathologies vs. healthy, classifier #2 computes neuromuscular pathologies vs. healthy and classifier #3 computes physiological pathologies vs. healthy.

The test is done by single frame classification with both classifiers #1 and #2 classifying all frames as healthy/unhealthy. If the percentage of frames classified as healthy by classifier #1 averaged with classifier #2 is higher than 50% the subject is classified as healthy. Otherwise, the subject is classified as unhealthy and the classifier #3 identifies the pathology.

Gaussians Mixtures Models

Gaussians Mixtures Models (GMM) allows the train of N independent models. These systems had great impact on solutions for speaker recognition [START_REF] Reynolds | Speaker identification and verification using Gaussian mixture speaker models[END_REF]. The system implemented for this work consists in one model for each class. Each model is represented by M Gaussian mixtures with covariance diagonal matrix. In this case, it was found that the best results are obtained with 16 Gaussian mixtures for each class. For each test segment the likelihood is computed in each class and classified in the class that maximizes this value.

Metrics and Results

As described above, tests with the sustained vowel /a/ and with continuous speech used SVM and GMM classifiers. The systems evaluation was performed by the overall system ACC (accuracy) [START_REF] Lieberman | Some acoustic measures of the fundamental periodicity of normal and pathologic larynges[END_REF], the class sensitivity TPR (True Positive Rate) [START_REF] Iwata | Periodicities of pitch perturbations in normal and pathological larynges[END_REF] and the class precision PPV (Positive Predictive Rate) (3). These measures are computed using the TP (True Positive), FP (False Positive), FN (False Negative) and TN (True Negative) approach. Table 2 and3

In general, the system implemented with continuous speech using GMM achieved better results (74% accuracy), as well as best average precision and sensitivity rates (76.2% and 77.9% respectively).

The systems that used the sustained vowel /a/ achieved about 20% in absolute value less precision rate for healthy subjects. These results are particularly important since the unhealthy subjects are not diagnosed with any of the pathologies what can be considered an important disadvantage of these systems.

Continuous speech based systems have typically better results than the vowel /a/ based systems. Only in two instances the results obtained with the sustained vowel are better. In the first case, in table 2, the sensitivity rate in unilateral paralysis using the SVM classifier is 69.4% against 56% for continuous speech. With the GMM classifier the precision rate is 61%. In the second case, the precision for nodules and edema is 66.6% when used the vowel /a/ in the SVM classifier. However, when using continuous speech in the GMM classifier this value is 66.2%, decreasing only 0.4%.

Conclusions and Future Work

This work presents two voice pathologies identification systems using continuous speech and the sustained vowel /a/. Three classes were created: healthy subjects, subjects diagnosed with vocal fold edema and nodules (physiological disorders) and subjects diagnosed with unilateral vocal folds paralysis (neuromuscular disorder).

The main objective was to compare the performance of voice pathologies identification using continuous speech with the sustained vowel /a/ typically used in these applications. Two classifiers systems were created, using SVM and GMM, both using MFFC parameters as speech signal features. The results showed that continuous speech allows better results for the two systems and that GMM models classifier overcame the SVM classifier. In particular GMM and continuous speech have better precision values in the identification of healthy subjects. However, the sustained vowel /a/ has the best results in the sensitivity for unilateral vocal fold paralysis. Considering this fact, some research in system fusion will be done in the future to verify if, this way, it is possible to improve the overall performance. Continuous speech shows high potential for voice pathologies identification. In the future this performance may be improved using other speech signal features and different classifiers.

There are few studies in pathological voice identification. Different databases and pathologies studied make the comparison with other woks inconsistent. For that a cloud sharing database approach certain will bring relevant improvements in this task.

  show the obtained results. ACC = ( TP + TN ) / ( TP + TN + FP + FN ) (1) TPR = TP / ( TP + FN )(2)PPV = TP / ( TP + FP )

Table 1 .

 1 Database gender distribution

	Pathology	Males	Females	Total
	Healthy	14	22	36
	Nodules	1	18	19
	Vocal Fold Edema	9	31	40
	Vocal Fold Unilateral Paralysis	29	30	59

Table 2 .

 2 SVM system best results for continuous speech and Vowel /a/ in parentheses. ACC: 72% (69%), both systems use MFCC 20 th order.

	Classification Original	Healthy	Nodules and Vocal Fold Edema	Unilateral Paralysis	Sensitivity (TPR)
	Healthy	34 (33)	0 (1)	2 (2)	94.4% (91.6%)
	Nodules and Vocal Fold Edema	1 (9)	44(32)	14 (18)	74.5% (54.2%)
	Unilateral Paralysis	2 (3)	24 (15)	33 (41)	56% (69.4%)
	Precision ( PPV )	91.8% (73%) 64.7% (66.6%) 67.3% (67.2%)

Table 3 .

 3 GMM system best results for continuous speech and Vowel /a/ in parentheses. ACC: 74% (66%), systems use MFCC 12 th order for continuous speech and 8 th order for the vowel /a/.

	Classification	Healthy	Nodules and	Unilateral	Sensitivity
			Vocal Fold	Paralysis	(TPR)
	Original		Edema
	Healthy	33 (30)	3 (2)	0 (4)	91.6% (83.3%)
	Nodules and Vocal Fold Edema	1 (10)	45 (32)	13 (17)	76.2% (54.2%)
	Unilateral Paralysis	1 (4)	20 (15)	36 (40)	61% (67.7%)
	Precision ( PPV )	94.2% (68%) 66.2% (65.3%) 73.4% (65.5%)

Acknowledgments. The authors would like to thank Prof. Ana Mendes from Polytechnic Institute of Setúbal for sharing the database used in this study and the High Institute of Engineering of Lisbon by the scholarship that allowed the work progress.