Adja Ndeye Sylla
email: adjandeye.sylla@cea.fr

Maxime Louvel
email: maxime.louvel@bag-era.fr

Eric Rutten
email: eric.rutten@inria.fr

Gwenaël Delaval
email: gwenael.delaval@inria.fr

Modular and Hierarchical Discrete Control for Applications and Middleware Deployment in IoT and Smart Buildings

Keywords: Discrete Event Systems, Application, Software Systems, Smart Building

come

I. INTRODUCTION

A. Internet of Things and Smart Buildings

Today's computer-based systems (e.g., smart buildings and homes) must adapt to their changing environment in order to remain operational and achieve their objectives. For this purpose, they continuously collect data, make decisions and execute reconfiguration commands. Depending on the collected data, the commands executed by a system are related to its applicative functional logic and also to the management of the computing system itself, typically the deployment of software objects on an execution platform.

Such management systems have to be self-adaptive w.r.t. different concurrent aspects. Applications have to adapt their functionalities to the environment conditions (e.g., temperature, presence). Software tasks implementing them have to be deployed on the execution platform, adapting on available resources (e.g., starting/stopping or migrating objects). The execution platform itself has to adapt to variations in workload or availability (e.g., switching on/off nodes, fault tolerance). Therefore, managing these different concurrent adaptations in order to hold a well-mastered and safe behaviour of the overall system is a complex control problem.

The design and the implementation of such a system raises problems of avoiding decisions that can be conflicting, useless or violate other target objectives. In the literature, solutions have been proposed for the design and the implementation of reliable adaptive systems [START_REF] Guillet | Correct by construction security approach to design fault tolerant smart homes for disabled people[END_REF], [START_REF] Kolokotsa | Predictive control techniques for energy and indoor environmental quality management in buildings[END_REF], [START_REF] Zhao | Discrete control for the internet of things and smart environments[END_REF], [START_REF] Nabih | Modeling, simulation, and control of smart homes using petri nets[END_REF], [START_REF] Niu | A smart home context-aware model based on uml and colored petri net[END_REF]. However, they focus either on the systems application logic or on the software deployment but not on both together. The work in [START_REF] Nabih | Modeling, simulation, and control of smart homes using petri nets[END_REF], [START_REF] Niu | A smart home context-aware model based on uml and colored petri net[END_REF] use Petri nets and perform model checking, we propose a supervisory control based approach.

B. Application of DES control with Heptagon/BZR

To overcome these problems, we propose a generic control support for reliable adaptive systems. We apply techniques from the area of Supervisory Control for Discrete Event Systems (DES), where the space of configurations at the different levels (application, deployment, execution platform) are modelled with transitions systems, particularly automata.

We use programming language support tools, Heptagon/BZR [START_REF] Delaval | Integrating discrete controller synthesis into a reactive programming language compiler[END_REF] and ReaX [START_REF] Berthier | Discrete Controller Synthesis for Infinite State Systems with ReaX[END_REF], and their Discrete Controller Synthesis (DCS) capabilities, to generate correct executable controllers. These can be integrated in the underlying middleware, based on the transactional rule-based framework LINC [START_REF] Louvel | Development tools for rule-based coordination programming in linc[END_REF], to build up a design environment for our application domain. This allows to (i) ensure the behavioural reliability of systems (absence of conflicting or incorrect decisions), (ii) handle their heterogeneity and (iii) guarantee their execution reliability (absence of inconsistencies). An inconsistency is due to a hardware failure or a communication error and it occurs when the system assumes that a command is executed but it actually is not for instance due to a hardware failure.

We are following the same approach of DES model-based design of reconfiguration controllers on different classes of computing systems. We consider small, embedded hardware systems, such as FPGA [START_REF] Mak Karé Gueye | Autonomic management of missions and reconfigurations in FPGA-based embedded system[END_REF] as well as larger, more distributed software systems like web servers in the Cloud [START_REF] Delaval | Distributed execution of modular discrete controllers for data center management[END_REF], [START_REF] Berthier | Logico-numerical control for software components reconfiguration[END_REF], or heterogeneous platforms, composed of numerous devices with very different computation power, operating systems and communication protocols, like in the domain of the Internet of Things (e.g., smart buildings [START_REF] Sylla | Design framework for reliable multiple autonomic loops in smart environments[END_REF]). These works are distinguished by their very different target computing systems, w.r.t. execution platforms and application domains: therefore they bring complementary experience, towards the identification of generic modelling methods, in order to pose and solve logical control problems in computing systems.

C. Contributions of the paper

This paper contributes in the following points: 1) behavioural automata-based modelling, and objectives formalisation, for the coordination of the applicative and deployment mangers of smart building systems; 2) applications of Discrete Controller Synthesis to design monolithic or modular and hierarchical controllers; 3) an implemented case study for a smart office, including controller execution in a reactive autonomic loop, a transactional runtime and an abstraction layer. The paper is structured as follows. Section II gives the background notions. Then, Section III presents the target domain of smart buildings. Section IV describes behavioural models and objectives. Section V presents a case study. Finally, Section VI discusses and gives the perspectives.

II. BACKGROUND A. Internet of Things and Smart buildings

The application domain we target is smart buildings, in the context of the Internet of Things (IoT), equipped with heterogeneous devices and managed by a software system.

1) Considered aspects: a smart building system consists of two managers that interact to achieve a set of objectives. An applicative manager handles the sensors and the actuators of the building and provides applicative functionalities e.g., presence detection, access control and luminosity control. This manager is implemented as a set software entities that achieve applicative objectives. A deployment manager handles these entities, and their deployment on the execution platform of the building. It consists of a middleware that switches on/off computing devices, starts/stops/migrates software entities and installs software resources if required. The aim is to achieve a set of deployment objectives (e.g., minimize the energy consumption of the execution platform).

These two managers can interact in four ways. The application can affect the deployment: for instance, providing a new applicative functionality, with a specified Quality of Service (QoS) level, can require switching on additional computing devices. The deployment can affect the application: for instance, the overload of a computing device can require decreasing the QoS provided by the application. The application can change without affecting the deployment: for instance, the application can request for a functionality that is provided by a set of software entities already deployed (for another functionality). The deployment can change without affecting the application: for instance, the deployment can switches off unused computing devices for energy savings.

This paper models each manager to handle their coordination and solve the logical control problems they raise.

2) Logical control problems encountered: for both aspects, to achieve its target objectives, a smart building system computes and executes at each step a set of commands that could be conflicting or violate other target objectives. A conflict occurs when a device or a software entity receives at the same instant contradictory commands. An objective is violated when it is not met due the execution of one or several commands. For the applicative aspect, both conflicts and objectives violations can be caused by environment dependencies and are in this case, difficult to detect. For instance, opening the window of a room for natural ventilation can introduce noise and violate an objective that consists in maintaining the noise level below a given threshold. Conflicts and objectives violations could lead to unsafe or undesired states that should be avoided. The smart building system must also autonomously adapt to its environment by reacting to changes. We follow the approach of autonomic computing [START_REF] Kephart | The vision of autonomic computing[END_REF] for performing self-configuration, self-optimization, self-healing or self-protection, through a control loop. In this paper, to deal with the logical control problems, we use Discrete Controller Synthesis (DCS) [START_REF] Ramadge | The control of discrete event systems[END_REF] through a reactive language and tool, and allow for executable code generation.

B. Reactive language for Discrete Controller Synthesis

The reactive language used is Heptagon/BZR (H/BZR) [START_REF] Delaval | Integrating discrete controller synthesis into a reactive programming language compiler[END_REF]. It is based on a contract mechanism and allows for declarative design of controllers trough discrete controller synthesis.

1) Design and synthesis of a controller: A H/BZR program is first written, for the considered system, as a set of hierarchical blocks called nodes. Each node declares input and output flows, i.e., sequences of values taken by inputs and outputs on a discrete scale of time. A node can contain equations and control structures on these equations, like automata. Each automaton models an entity of the system and they can be composed in parallel or in hierarchy. A node can be provided with a contract that define objectives to be enforced in the program through DCS. Once designed, the program is compiled to generate the system controller.

a) Equations: they define outputs, and possible local variables, in terms of other variables (inputs, outputs, local variables). Equations can be composed of memorised values, introduced by the pre delay operator: pre e holds the value of e at the previous instant. Memories can be initialized with the -> operator: c -> pre e holds the value c at the first instant, and the previous value of e at following ones.

b) Automata: they are control structures contained in nodes and allowing to associate equations (or hierarchically, sub-automata) to states of the system. An automaton has a set of states, one of them being the initial state, and transitions between them. States are associated to equations that give values to the output flows of the node that contains the automaton. At each instant, one state is activated and a value must be defined for each output flow. A transition goes from one state to another and is associated to a boolean expression that is related to one or more flows of the automaton node.

Fig. 1a, presents an automaton designed for the control of a computing device. This automaton is contained in a node that has two input flows (c1, c2) and two output flows (on, cmd). The automaton has two states (Off, On) and two transitions. Each state is associated to two equations that give values to the output flows of the node. In the state Off, the output flow on is equal to false. This meaning that the computing device is off. In the state Off, the output flow cmd is equal to s off (switch off) when this state is newly reached and nothing otherwise. The reason is twofold. First, the value of an output flow must be defined at each instant. Second, this prevents from, continuously, sending cmd = s off while the computing device is already switched off.

The initial state of the automaton is Off. When the input flow c1 is false, the automaton goes to the state On and the output flows takes the values given by the equations of this state. Otherwise (c1 is true), the automaton remains in Off. c) Contract: it allows for DCS through a tool called the ReaX [START_REF] Berthier | Discrete Controller Synthesis for Infinite State Systems with ReaX[END_REF], and consists of three parts: assume, enforce and with. The assume defines the hypotheses of the considered system. The enforce defines the target objectives (invariance properties). The with declares the controllable variables, that will be used to enforce the objectives. From a contract, the DCS algorithm computes the possible values of the controllable variables. This is done by exploring the state space of the model and inhibiting all the behaviours that violate the target objectives. The aim is to enforce all the objectives whatever the uncontrollable variables values. After the synthesis, several solutions can be possible regarding the target objectives. However, one solution must be selected. This selection is done by the backend of the H/BZR compiler by favouring the value true to false for each boolean controllable variable following the order of their declaration.

Fig. 1b presents an example of node with contract to switch on both computing devices of a room when a presence is detected. This node defines two instances of the computing device node (Fig. 1a) and composes, in parallel, their automata using the operator ;. The contract defines no hypothesis (assume true), one objective and four controllable variables that are the input of the computing device nodes. The objective specifies that when c is true (a presence is detected in the room), both computing devices must be on.

d) Cost of the controller synthesis: the DCS algorithm has a cost exponential in the number of variables used in the model of the system [START_REF] Delaval | Integrating discrete controller synthesis into a reactive programming language compiler[END_REF]. These variables consists of the state variables, the controllable and the uncontrollable variables. Hence, for a system that consists of a high number of entities, the controller synthesis can take a lot of time or not succeed due to CPU and/or RAM limitations. For such systems, H/BZR allows for performing the controller synthesis modularly to reduce the related synthesis cost.

2) Modular design and synthesis of a controller: this consists in dividing the system into subsystems and defining for each subsystem, a node with a contract. This node instantiates and composes relevant automata and enforce a subset of the target objectives. In this case, DCS is performed on each subsystem instead on the whole system. This decreases the DCS execution time and its resources consumption. This also allows for the generation of several controllers, one for each subsystem, instead of a single one for the whole system.

Fig. 1c shows an example of modular design and synthesis of a controller. The Room node (Fig. 1b) is instantiated twice, to model a building of two rooms. This Building node takes as input two flows pr1 and pr2, that model the value of a presence sensor in each room. Then, this node is provided with a global contract, to achieve the following objective: for each room, both computing devices must be switched on when a presence is detected by the associated sensor. The contract defines two objectives and two controllable variables. This enables the modular synthesis of a controller.

3) Execution of a controller: the compilation of a H/BZR program (e.g., Fig. 1) generates a step function. In case of modular DCS, several step are generated (one for each node with a contract) but one of them is the main step. The step takes as parameter the inputs, computes the outputs and updates the state of the automaton modelling the system. One execution of the step corresponds to one reaction of the system. Hence, the step must be executed each time a relevant event occurs. Executing the step requires consistency between the automaton state and the actual system automaton. For this, a transactional middleware (LINC [START_REF] Louvel | Linc: A compact yet powerful coordination environment[END_REF]) is used and the step is invoked in a LINC rule as detailed in [START_REF] Sylla | Combining transactional and behavioural reliability in adaptive middleware[END_REF], for its execution in the form of a reliable autonomic loop [START_REF] Sylla | Design framework for reliable multiple autonomic loops in smart environments[END_REF]. Fig. 2 illustrates this loop, with an abstraction layer that hides the heterogeneity of the system, the controller to execute and a transactional execution mechanism that avoids inconsistencies. Data are first collected through the abstraction layer. Then, they are analysed by the controller which computes correct and coherent commands that are executed by the transactional mechanism through the abstraction layer.

III. DESCRIPTION OF A SMART BUILDING SYSTEM

This section identifies informally, for both the applicative and deployment aspects of a smart building system, the controlled entities, the relevant events and the target objectives. 2) Relevant events: they consist of data that are produced by the sensors of the building. These data are related to the states of the actuators (e.g., opening of a window or a door) or the building (e.g., presence) and to the environment parameters (e.g., temperature, noise, CO 2 ). The events also consists of information about meetings (e.g., feature), about time (e.g., 7 AM) and requests for maintenance of actuators.

3) Target objectives: an applicative objective specifies, depending on the events that occur in the system, the value that must be taken by an environment parameter or by the state of an actuator. Applicative objectives are of three types

• a obj T1 : keep the value of an environment parameter in a specified interval (delimited by th min and th max ); • a obj T2 : avoid the situation where an actuator that is requested to be idle for a maintenance operation, can be not used but remains used by the application; • a obj T3 : decrease (resp. increase) the value of an environment parameter when its actual value (measured by a sensor) is below (resp. above) a specified threshold.

B. Deployment aspect 1) Controlled entities: they consist of the software entities, implemented to offer the target applicative functionalities, and the execution platform of the considered building.

The software entities consist of tasks, objects and rules. A task offers one or more applicative functionalities, using Input/Output (I/O) resources. Each task has a set of versions, with different QoS (High, Medium, Low), and transitions specifying the changes of versions that are possible. For instance, let us consider a task with three versions V 1 , V 2 and V 3 . For this task, it can be valid to go from V 1 to V 2 and from V 2 to V 3 but not from V 1 to V 3 , for instance for sequencing reasons. A task version consists of rules and configurations of objects. A rule communicates with one or several objects and is executed by an object. An object can have required I/O resources and a set of configurations. Both a rule and an object configuration have a CPU (resp. a RAM) load, that is either negligible or expressed as a percentage (resp. in MB).

The execution platform is composed of a set of computing devices and I/O resources. A computing device consists of a host and a set of I/O resources. Hosts are heterogeneous, they have different capacities in terms of CPU and RAM. An I/O resource is either software or hardware. Both have a type (e.g., USB dongles, OpenCV) and a hardware I/O resource has a usage mode that specifies an usage constraint. The usage mode of a resource is equal to R (reading), 1W (writing by one entity) and nW (writing by several entities).

2) Relevant events: they consist of data related to load variations, to the execution platform and those measured by the sensors of the building. Examples of events are failures of hardware I/O resources, maintenance requests of computing devices or their loads. The events can also be related to time.

3) Target objectives: they are related to the considered building execution platform and to the deployment of the software entities. Deployment objectives are of five types

• d obj T1 : allocate to objects, the computing devices and the hardware and/or software I/O resources they require. This means that when an object is started, its computing device must be on and must have its required resources; • d obj T2 : ensure the constraints related to the usage modes (exclusive ot not) of the hardware I/O resources; • d obj T3 : avoid the situation where a computing device that is requested for maintenance is not switched off; • d obj T4 : if possible, decrease the load of a computing device when its actual load, that is measured, is above a maximum threshold. Similarly, increase the load of a computing device or switch it off when its actual load is below a minimum threshold. The aim is to avoid both overloading and under-loading the computing devices; • d obj T5 : minimize the execution platform energy consumption, by using the minimum of computing devices.

C. Coordination of both aspects

To handle their interactions, the applicative and the deployment managers must be coordinated. The coordination scheme and its objectives are presented in the followings.

1) Coordination scheme: it consists of three points

• when the applicative manager requests the starting of a functionality, with a given QoS, a task version is first selected among those that offer the functionality and have a version with the requested QoS. Then, a notification is sent to the deployment manager which deploys the objects and rules of the selected task version on the execution platform. The selection of the task version is done based on information about the tasks (offered functionalities, versions and their QoS) and on the status of the execution platform (computing devices and I/O resources). These objects and rules are kept deployed as long as the functionality has to be provided; • when the deployment manager can no longer provide the requested QoS or functionality due to the lack of computing or I/O resources in the execution platform, it sends a notification. In this case, the application manager can, for instance, ask for a another QoS or functionality that has a cheaper resource consumption; • when the application managers requests the stopping of a functionality, the deployment managers is first notified. Then, it stops the associated objects and rules. The deployment manager can also switch off the computing devices that are no longer used, for energy savings.

2) Coordination objectives: they consist of three types

• c obj T1 : when a functionality is requested to be provided, one version of a task among the set of tasks that offer this functionality must be active, if this is possible; • c obj T2 : for a functionality, when no task that offers it is active, its applicative objectives must not be achieved; • c obj T3 : when a task version is active, its objects must be started and its rules must be activated and executed. This section presents how the coordination of a smart building managers is written as a discrete control problem and how it is solved to generate an executable controller.

A. Behavioural modelling

Each controlled entity is modelled as an automaton with points of controllability (variable starting with c by convention). A preference can be defined between the states of an automaton, through the declaration order of these variables.

1) Applicative aspect: Each actuator is modelled as an automaton contained in a H/BZR node. Such an automaton specifies the different states of the modelled actuator, its states transitions and its effects on the environment. For this, a set of environment parameters (e.g., luminosity, noise, air) are first defined. Then, the effects of each actuator on these environment parameters are identified and specified. This is done in the form of equations that are encapsulated in the states of the automaton. These equations have boolean or numerical variables and define their values. In the followings a set of automata modelling different actuators are presented.

a) Shutter modelling: Fig. 3a presents an automaton modelling a shutter. This automaton is contained in a node that has two input flows (c, o lum) and three output flows (cmd, lum, air). The automaton has two states (Closed, Opened) and two transitions. Each state is associated to three equations to produce the command of the shutter (cmd) and specify its effects on the environment (lum, air). In Closed, the command is equal to close (resp. nothing) if this state is (resp. not) newly activated. This prevents from continuously sending the command close while the shutter is already Closed. In this state, the shutter provides a luminosity equal to zero (lum = 0) and does not allow outdoor air to pass (air = false). In Opened, the shutter provides a luminosity equal to the outdoor luminosity (lum = o lum) and allows outdoor air to pass (air = true). The transitions going from a state to a different one are associated to not c, to open/close the shutter only when necessary.

b) Reversible Air-Condition (RAC) modelling: Fig. 3b presents an automaton modelling a RAC. Each state is associated to three equations to produce the command of the RAC and also specify its effects on the environment. For instance, in Off, the RAC does not cool nor heat the room. This automaton is contained in a node that has two input flows c1 and c2. The reason is that, at each state, three transitions can be triggered (i.e., two transitions that leave the state and one that allows to stay). To associate a different boolean expression to each of the three transitions of a state, at least two variables are needed. Here, when the state Off is activated, if the input c1 flow is false, the RAC automaton goes to the state Cooling. If c2 is false, it goes to Heating. If both c1 and c2 are true, it remains in the state Off. Finally, if both c1 and c2 are false, at the same instant, the transition that was first declared is chosen. Associating not c1 and not c2 (resp. c1 and c2) to the transitions leaving (resp. coming to) the state Off means that it is preferred to maintain the RAC Off for energy savings.

We similarly define models for lamps (and their luminosity), Mechanical Ventilation (MV) (affecting CO 2 ), windows (affecting heating, cooling, ventilation, pollution and noise), doors (affecting noise). These models are detailed in [START_REF] Sylla | Design framework for reliable and environment aware management of smart environment devices[END_REF].

2) Deployment aspect: An automaton is designed for task, object, rule, I/O resource, host and computing device.

a) I/O resources modelling: the automaton of a hardware or a software I/O resource has three states (Unavailable, Unused, Used) and is contained in a node that has five inputs (avail, fail, c1, c2 and c3). The input avail (resp. fail) allows to know if the I/O resource is available (resp. failed). The inputs c1, c2 and c3 are points of controllability that enable changing the state of the I/O resource. For a software resource, the input fail is a constant that is equal to false (a software does not fail). The input c2 allows installing the software when it is equal to false. For a hardware resource, c2 is a constant equal to true because a hardware resource cannot be installed.

Fig. 4 presents the automaton of a hardware I/O resource that is a dongle. The outputs of the automaton node respectively correspond to state of the dongle and its command. . This automaton has six inputs (avail, fail, rmaint, c1, c2, c3). The first three inputs respectively specify if the host is available, if it is failed or if a maintenance request is sent by the maintenance team to no longer use it. The inputs c1, c2, c3 are points of controllability. They allow for starting the host, stopping it or bringing it in the state Wait (upon the occurrence of a maintenance request that cannot be satisfied). In the state Wait, the host goes to the state Unavailable when it is failed or can be no longer used (allowing its maintenance). Fig. 5 presents the automaton of a host (H1). The outputs of the node that contains this automaton are the status of the host (on, available) and the command to send (cmd). • a host automaton for associated with the associated host;

• a hardware I/O resource automaton for each hardware I/O resource that is local to the computing device; • software I/O resource automaton for each one of the considered software I/O resource in order to install it if it is not available on the computing device, if needed. Fig. 6 presents an automaton modelling a computing device (D1) that has a dongle (dongle1). This automaton is the parallel composition of two automata modelling the host H1 (Fig. 5) and the hardware resource dongle1 (Fig. 4). D1(avail_H1, fail_H1, rmaint_H1, c1_H1, c2_H1, c3_H1, avail_dongle1, fail_dongle1, c1_dongle1, c3_dongle) = on_D1, available_D1, cmd_D1, available_dongle1, used_dongle1, cmd_dongle1 (on_D1,available_D1, cmd_D1) = H1(avail_D1, fail_D1, rmaint_D1, c1_D1, c2_D1, c3_D1); (available_dongle1, used_dongle1, cmd_dongle1) = Dongle_dongle1(avail_dongle1, fail_dongle1, c1_dongle1, true, c2_dongle1)

Fig. 6: Computing device model example

We similarly define models for tasks (that can be activated), objects (that can be migrated), rules (that can be deactivated). These models presented in details in [START_REF] Sylla | Design framework for reliable and environment aware management of smart environment devices[END_REF].

3) Coordination of both aspects: here, the fact that each applicative functionality can be requested to be provided with a given QoS or stopped is modelled. For this, an automaton is designed for each functionality, with a state for each QoS level, and an input for requesting it, as well as points of controllability for changing the current QoS or stopping. Fig. 7 presents an example of automaton modelling a luminosity control functionality, with QoS High or Medium, points of controllability (c1, c2) and requests (req H, req M). When req H is true, depending on the values of c1 and c2, the functionality is provided appropriately. The fact that c1 is declared before c2 allows for choosing the Medium QoS only if the High cannot be provided when requested. where param_compValue is the value computed for param in the current instant, pre param_compValue is the value computed in the previous instant. param_measuredValue is an input giving the actual measured value (from the environment). Objective a obj T3 is logico-numerical, as it involves a numeric input (param_measuredValue) and a numeric state (pre param_compValue). Achieving an objective of this type requires the use of advanced discrete control techniques, involving abstract interpretation on abstract domains such as intervals or convex polyhedra [START_REF] Berthier | Discrete Controller Synthesis for Infinite State Systems with ReaX[END_REF].

2) Deployment objectives: from Section III-B.3 are e.g.,

• d obj T1 : for obji in objects set. for avoiding under-load : possible ⇒ ((devi.measuredLoad < devi.thLoadmin) ⇒ (devi.estimatedLoad > pre devi.estimatedLoad or devi.on = false)).

The deployment objective d obj T4 is logico-numerical, as devi.measuredLoad is a numerical input and pre devi.estimatedLoad a numerical state.

3) Coordination objectives: from Section III-C. and composed, in parallel, all the behavioural models and was compiled to generate one controller, for the whole system that is a building. To enable the generation of several controllers, that can be distributed, and reduce the synthesis cost, the control was done modularly and hierarchically.

C. Modularity and hierarchy

The system is first divided in two sub-systems: one for the applicative aspect and one for the deployment. Then, as shown in Fig. 8, a node with a contract is designed for each sub-system and a third node is built for their coordination:

• Applicative node: it composes the behavioural models of the applicative aspect and achieves the related objectives. This node has a set of inputs that are allows for its control by a node with a higher level of hierarchy. Such an input makes the applicative node achieve (or not) the objectives of the functionality related to it; • Deployment node: it composes the behavioural models of the deployment aspect and achieve its objectives. This node has inputs that are allows for its control. Such an input makes the node activates a task and deploying its objects and rules, to provide a functionality, or stop it; • Room node: it composes the applicative node, the deployment node and the behavioural models that are related to their coordination. It defines a contract in order to enforce the coordination objectives defined in Section III-C.2 with controllable variables that are inputs of the applicative and the deployment nodes. To allow for different levels of hierarchy and considerably reduce the synthesis cost, each aspect of the system can be decomposed in sub-systems and controlled modularly. For instance, for the applicative aspect, the set of actuators are first divided into several sub-sets, depending one the target objectives. Then, the sub-sets are controlled as done in [START_REF] Sylla | Design framework for reliable multiple autonomic loops in smart environments[END_REF].

D. Dynamic reconfiguration of a controller

The controller of the system can be reconfigured, to deal with changing objectives. Indeed, a building, generally, have a set of configurations in which different objectives. For instance, the objectives to achieve during working time (e.g., comfort) are different from those to achieve during holidays (e.g., energy savings). To enable the reconfiguration, we propose a concrete solution which consists in first designing separately several controllers that achieve different objectives, and then, designing a reconfiguration controller that switches between the controllers. The switch consists in deactivating the current controller and activating the appropriate one upon the occurrence of specific events.

Activating a target controller requires ensuring that current state of the building is valid for this controller, for it to work. This is not an easy task because a state is valid for a controller only if it belongs to the controller state space, it does not violate its objective and, does not lead, through one or several uncontrollable transitions, to a state that violates an objective. For this, in the simplified case of our application domain, we first define a reconfiguration state the considered building. Then, we design the controllers of the building in such a way that they have the same initial state that is the reconfiguration state. This allows for activating any of the controllers when the building is in its reconfiguration state. Finally, we design the reconfiguration controller using H/BRZ. This is done by defining an automaton with a state for each controller of the building and and transitions among them. Such a state invokes the H/BZR node the corresponding controller. When this state is reached, the associated controller is automatically activated, all its variables and equations are reinitialised. This means that the controller starts in its initial state which is the reconfiguration state.

As an example, let us consider a building with two sets of objectives (working time, holidays) and a state night in which it is not occupied, not cooled, not heated and not ventilated. This state is first taken as the building reconfiguration state and a controller is designed for each set of objectives. Both controllers have night as initial state. The automaton defined to design to enable the reconfiguration of the controllers is presented in Fig. 9. It has two states (WorkingTime, Holidays) and two transitions. The initial state is WorkingTime meaning that the working time controller is the one that is active. When holidays started is true and the night state is reached, the automaton goes to Holidays. This deactivates the workingTime controller and activates the Holidays one from its initial state that is night. This automaton is compiled and the generated step function is invoked in a LINC rule to enable its execution.

V. PHYSICAL IMPLEMENTATION

The demonstrator presented in Fig. 10 was built to validate our contribution. It consists of an office that has a shutter (emulated by a graphical interface), a lamp (connected to a plugwise circle that allows for sending commands to it), a presence sensor (emulated by an EnOcean switch), an The objectives to be achieved in this office are (i) keep the luminosity between 500 and 600 lux when a presence is detected, (ii) keep the shutter closed during a confidential meeting and (iii) prefer natural lighting for energy savings.

a) Controller synthesis: Two automata, for the shutter and the lamp, and contract, define the luminosity and the confidentiality objectives. The energy savings objective is expressed by declaring the controllable variable of the shutter after the on of the lamp. This allows for using the lamp only when the office must be lighted and the shutter cannot be used. The generated controller was executed by on the Raspberry Pi. It takes as input the presence sensor data and information related to meeting (the outdoor luminosity is set to 600 lux) and executes commands of the lamp and shutter.

b) Controller behaviour: Fig. 11 presents the controller behaviour. The variables time, i presence and confidMeeting respectively correspond to the time, the presence sensor value and an information specifying if there is a confidential meeting. The variables shutter opened and lamp on correspond to the state of the shutter and the lamp. At 7 AM, a presence is not detected in the office, the outdoor luminosity is equal to 600 lux (it is fixed) and there is no confidential meeting. In this case, the shutter is closed and the lamp is off. At 8, a presence is detected (one office member arrives), the controller opens the shutter to achieve both the luminosity and the energy savings objectives. At 11, the presence is still detected and there is a confidential meeting. In this case, the controller switches on the lamp and closes the shutter, for the confidentiality objective. At 12, the presence is not detected, it switches off the lamp.

VI. CONCLUSION

We present an application of Discrete Event Systems Control techniques to the domain of smart buildings in the context of IoT. Our contributions are: behavioural automatabased modelling, and objectives formalisation, for the coordination of the applicative and deployment managers of Perspectives are in: exploiting the genericity of our models by designing a Domain Specific Language for developers to specify their systems, without needing expertise in formal models; exploring extensions in expressiveness in the control problems modelled and solved, for example advanced adaptive discrete control for reconfigurable controllers.

Fig. 1 :

 1 Fig. 1: Example of H/BZR program

Fig. 2 :

 2 Fig.2: Architecture of a reliable loop

Fig. 3 :

 3 Fig. 3: Shutter and RAC models

  fail not avail and not c2 or (not avail and not c3)

Fig. 4 :

 4 Fig. 4: Hardware resource model example b) Host modelling: the automaton of a host has four states (Off, On, Wait, Unavailable). This automaton has six inputs (avail, fail, rmaint, c1, c2, c3). The first three inputs respectively specify if the host is available, if it is failed or if a maintenance request is sent by the maintenance team to no longer use it. The inputs c1, c2, c3 are points of controllability. They allow for starting the host, stopping it or bringing it in the state Wait (upon the occurrence of a maintenance request that cannot be satisfied). In the state Wait, the host goes to the state Unavailable when it is failed or can be no longer used (allowing its maintenance).

Fig. 5 :

 5 Fig. 5: Host model example

B. Objectives formalisation 1 )d o r n o t c 1 Fig. 7 :

 117 Fig. 7: Functionality model example

Fig. 8 :

 8 Fig. 8: Hierarchical node

  enforce with (c1,c2) Room(holidays_started, workingTime_started, night) = active_workingTime = WorkingTime_ctrl(c1); active_holidays = Holidays_ctrl(c2); assume not (holidays_started and workingTime_started) (holidays_started and night) => active_holidays_ctrl (workingTime_started & night) => active_workingTime_ctrl target_ctrl target_ctrl = if active_holidays then Holidays else if active_workingTime then WorkingTime else None;

Fig. 9 :Fig. 10 :

 910 Fig. 9: Reconfiguration controller design

Fig. 11 :

 11 Fig. 11: Controller behaviour

  obji.device_dest.on is the computing device selected to start or migrate obji:

	obji.started ⇒ (obji.device_dest.on and
	obji.requiredResources areContainedIn
	obji.device_dest.availableResources) ;
	• d obj T4 : for every device devi, it consists of two objectives : for avoiding overload : possible ⇒
	((devi.measuredLoad > devi.thLoadmax) ⇒
	(devi.estimatedLoad < pre devi.estimatedLoad))

  Ti Ti.Vj.active ⇒ (Ti.Vj.objectsConfigurations.started and Ti.Vj.rules.activated and Ti.Vj.rules.objects = None) for any of task Ti and its version Vj.Once formalised, the objectives were defined in the contract part of a main H/BZR node. This node instantiated

	Room(time, avail_D1, fail_D1, rmaint_D1, measuredLoad_D1,..,
	i_temp, i_CO2, o_temp, ,...) = (cmd_O1, device_dest_O1, ...,
	cmd_shutter1, cmd_lamp1, cmd_window1, cmd_RAC)
	contract
	assume not devices.all.unavailable and not dongles.all.unavailable
	enforce time > 8 => activate_Ta and
		activate_Ta => obj_app
	with	(c_coord_dep, c_coord_app)
	Deployment(c_coord_dep, avail_D1,.., avail_D2)
	= (cmd_O1, device_dest_O1, ..., activate_Ta)
	contract
	assume not devices.all.unavailable and not dongles.all.unavailable
	enforce obj_dep and activate_Ta
		activate_Ta = c_coord_dep => (Ta.active and O1.started)
		obj_dep = dongle1.usersNb() <= 1 and ...
	with (c_O1, c_O2, device_O1, device_O2, c1_D1, c2_D1, c3_D1,....)
	# Deployment behavioural models
	Application(c_coord_app, i_pres, i_temp, i_CO2, o_CO2,...)
	= (cmd_shutter1, cmd_lamp1, cmd_window1, obj_app)
	contract
	assume true
	enforce c_coord_app => obj_app
		obj_app = i_pres => (lum >= 500 and lum <= 600) and ...
	with (c_lamp1, c_shutter1,c1_RAC,c2_RAC,c3_RAC, c_door,...)
	# Applicative behavioural models
		2 are
		QoStoProvide = None ⇒ Ti.Vj.active, where Ti.Vi is a task version offering the requested • c obj T1 :
		functionality with the specified QoS;
		• c obj T2 : for each functionality fi with a set of applica-tive objectives : a_objij, not fi.tasks.active ⇒
		not (a_obji1 and a_obji2 and ... a_objij);

• c obj T3 :


archive ouverte pluridisciplinaire HAL, est destinée au dépôt

L'

French Managers and their subordonates' Well-Being

Bernard Gangloff, N. Malleh

To cite this version:

Bernard Gangloff, N. Malleh. French Managers and their subordonates' Well-Being. International Journal of Social, Behavioral, Educational, Economic, Business and Industrial Engineering, 2016, 10 (12), pp.3416-3419. hal-01863011 daimon eudemonia Positive and Negative Affect Schedule Maslash Burnout Inventory Satisfaction with Life Scale Index of Psychological Well-Being Scale of Psychological Well-Being Measurement Scale of Psychological Well-being Events A. On Managers (N = 128) B. On Students (N = 176: 134 Women and 42 Men) C. On Employees (N = 307) Du bien-être au travail: fondements théoriques, conceptualisation et instrumentation du construit Gestion Bien-être et performance au travail American Psychologist Sens du travail, santé mentale et engagement organisationnel Management Review Journal of Organizational Behavior Consulting Psychology Journal: Practice and Research Psychological Bulletin Journal of Applied Psychology Journal of Applied Psychology Journal of Occupational and Organizational Psychology 2004, vol. Journal of Business and Management Journal of Occupational Health Psychology Human Relations Handbook of industrial work and organizational psychology Human Resource Management Journal Management Revue Work and Stress Journal of Personality and Social Psychology Psychological Inquiry, Journal of Conseling Psychology Annual Review of Psychology Psychological Review Client-centered therapy: its current practice, implications and theory American Psychologist, Journal of Personality and Social Psychology Maslach burnout inventory Journal of Personality Assessment Journal of Business and Psychology Revue Canadienne de Santé Publique via Proc. 5 th International Conference of Applied Psychology, Journal of Personality and Social Psychology Journal of Applied Psychology Human Performance, Les déterminants psychologiques de la performance au travail : un bilan des connaissances et proposition de voies de recherche


And Sebastian, he practically always takes it into account. He also shares my opinion: it's the owners that help us make a living, and we have to respond to their demands.

Opportunistic Allegiance

Especially Sebastian, whom I've noticed that practically always respects my decisions.

And Sebastian, he practically always takes it into account. His goal: to look good in my eyes in order to get a promotion quickly.

Moral Rebellion

However, I've noticed that Sebastian practically always challenges certain decisions I make.

But Sebastian, he practically never takes it into account. He believes that he doesn't have to obey me if my decisions go against his principles. Handbook of organizational justice Academy of Management Perspectives , ° Journal of Applied Psychology , International Review of Industrial and Organizational Psychology Comportement Organisationnel. . Psychologie du Travail et des Organisations Academy of Management Journal Journal of Organizational Behavior Academy of management executive The quest for the justice on the job. Essays and experimentations Academy of Management Journal Journal of Business to Business Marketing Journal of Organizational Behavior Journal of Applied Psychology Group and Organization Studies Strategic Management Journal Handbook of organizational justice. . Journal of Organizational Change Management Journal of Vocational Behavior, Journal of Management, Social Justice Research Advances in experimental social psychology Social exchange: advances in theory and research The social psychology of procedural justice Procedural justice: a psychological analysis Advances in organizational Justice Research on negotiation in organizations Organizational justice and human resource management Handbook of organizational justice Handbook of organizational justice Journal of Applied Psychology The cultural boundedness of organizational behavior constructs: the case of procedural and distributive justice Administrative Science Quarterly Handbook of Industrial and Organizational Psychology Administrative Science Quarterly, n° Academy of Management Journal Journal of Social Issues Distributive justice Academic of Management Review Justice in social relations Journal of Abnormal and Social Psychology Advances in experimental social psychology International Encyclopedia of the Social Sciences. American Sociological Review Social behavior: its elementary forms Interpersonal Relations: a theory of Interdependence Lincoln Electric Justice in the workplace: approaching fairness in human resources management Social Justice Research Trust in organizations: frontiers of theory and research Journal of Organizational Behavior Advances in organizational justice Injustices, l'expérience des inégalités au travail International Review of Social Psychology International Journal of Psychology The cross-cultural challenge of social psychology. Journal of Personality and Social Psychology, Organizational Behavior and Human Decision Processes, Zeitschrift für Rechts-Soziologie International Journal of Psychology, European Journal of Social Psychology, Lincoln Electric Culture's Consequences Cultures and Organisations Journal of Cross-Cultural Psychology, , Personality and Social Psychology Review Advances in organizational justice Academy of Management Journal Research in personal and human resources management Applied Psychology: an International Review Journal of Cross-cultural Psychology Journal of Personality and Social Psychology Journal of Management Journal of Experimental Social Psychology Principles of Social Justice Psychologie et de Psychométrie, Revue de Langue Française, Psychologie et recrutement L'allégeance et l'internalité dans le travail d'aide à l'insertion


Zied Elloumi

Laurent Besacier

Olivier Galibert

Benjamin Lecouteux

Analyzing Learned Representations of a Deep ASR Performance Prediction Model

This paper addresses a relatively new task: prediction of ASR performance on unseen broadcast programs. In a previous paper, we presented an ASR performance prediction system using CNNs that encode both text (ASR transcript) and speech, in order to predict word error rate. This work is dedicated to the analysis of speech signal embeddings and text embeddings learnt by the CNN while training our prediction model. We try to better understand which information is captured by the deep model and its relation with different conditioning factors. It is shown that hidden layers convey a clear signal about speech style, accent and broadcast type. We then try to leverage these 3 types of information at training time through multi-task learning. Our experiments show that this allows to train slightly more efficient ASR performance prediction systems that -in addition -simultaneously tag the analyzed utterances according to their speech style, accent and broadcast program origin.

Introduction

Predicting automatic speech recognition (ASR) performance on unseen speech recordings is an important Grail of speech research. In a previous paper [START_REF] Elloumi | Asr performance prediction on unseen broadcast programs using convolutional neural networks[END_REF], we presented a framework for modeling and evaluating ASR performance prediction on unseen broadcast programs. CNNs were very efficient encoding both text (ASR transcript) and speech to predict ASR word error rate (WER). However, while achieving state-of-the-art performance prediction results, our CNN approach is more difficult to understand compared to conventional approaches based on engineered features such as TransRater 1 for instance. This lack of interpretability of the representations learned by deep neural networks is a 1 https://github.com/hlt-mt/TranscRater general problem in AI. Recent papers started to address this issue and analyzed hidden representations learned during training of different natural language processing models [START_REF] Mohamed | Understanding how deep belief networks perform acoustic modelling[END_REF][START_REF] Wu | Investigating gated recurrent neural networks for speech synthesis[END_REF]Belinkov and Glass, 2017;[START_REF] Shi | Does string-based neural mt learn source syntax?[END_REF]Belinkov et al., 2017;[START_REF] Wang | What does the speaker embedding encode? In Interspeech[END_REF].

Contribution. This work is dedicated to the analysis of speech signal embeddings and text embeddings learnt by the CNN during training of our ASR performance prediction model. Our goal is to better understand which information is captured by the deep model and its relation with conditioning factors such as speech style, accent or broadcast program type. For this, we use a data set presented in [START_REF] Elloumi | Asr performance prediction on unseen broadcast programs using convolutional neural networks[END_REF] which contains a large amount of speech utterances taken from various collections of French broadcast programs. Following a methodology similar to (Belinkov and Glass, 2017), our deep performance prediction model is used to generate utterance level features that are given to a shallow classifier trained to solve secondary classification tasks. It is shown that hidden layers convey a clear signal about speech style, accent and show. We then try to leverage these 3 types of information at training time through multi-task learning. Our experiments show that this allows to train slightly more efficient ASR performance prediction systems thatin addition -simultaneously tag the analyzed utterances according to their speech style, accent and broadcast program origin.

Outline. The paper is organized as follows. In section 2, we present a brief overview of related works and present our ASR performance prediction system in section 3. Then, we detail our methodology to evaluate learned representations in section 4. Our multi-task learning experiments for ASR performance prediction are presented in section 5. Finally, section 6 concludes this work.

Several works tried to understand learned representations for NLP tasks such as Automatic Speech Recognition (ASR) and Neural Machine Translation (NMT). [START_REF] Shi | Does string-based neural mt learn source syntax?[END_REF] and (Belinkov et al., 2017) tried to better understand the hidden representations of NMT models which were given to a shallow classifier in order to predict syntactic labels [START_REF] Shi | Does string-based neural mt learn source syntax?[END_REF], part-of-speech labels or semantic ones (Belinkov et al., 2017). It was shown that lower layers are better at POS tagging, while higher layers are better at learning semantics. [START_REF] Mohamed | Understanding how deep belief networks perform acoustic modelling[END_REF] and (Belinkov and Glass, 2017) analyzed the feature representations from a deep ASR model using t-SNE visualization [START_REF] Van Der Maaten | Visualizing data using t-sne[END_REF] and tried to understand which layers better capture the phonemic information by training a shallow phone classifier. Also relevant is the work of [START_REF] Wang | What does the speaker embedding encode? In Interspeech[END_REF] who proposed an in-depth investigation on three kinds of speaker embeddings learned for a speaker recognition task, i.e. i-vector, d-vector and RNN/LSTM based sequence-vector (s-vector). Classification tasks were designed to facilitate better understanding of the encoded speaker representations. Multi-task learning was also proposed to integrate different speaker embeddings and improve speaker verification performance.

ASR performance prediction system

In [START_REF] Elloumi | Asr performance prediction on unseen broadcast programs using convolutional neural networks[END_REF], we proposed a new approach using convolution neural networks (CNNs) to predict ASR performance from a collection of heterogeneous broadcast programs (both radio and TV). We particularly focused on the combination of text (ASR transcription) and signal (raw speech) inputs which both proved useful for CNN prediction. We also observed that our system remarkably predicts WER distribution on a collection of speech recordings.

To obtain speech transcripts (ASR outputs) for the prediction model, we built our own French ASR system based on the KALDI toolkit [START_REF] Povey | The kaldi speech recognition toolkit[END_REF]. A hybrid HMM-DNN system was trained using 100 hours of broadcast news from Quaero2 , ETAPE [START_REF] Gravier | The etape corpus for the evaluation of speech-based tv content processing in the french language[END_REF], ESTER 1 & ESTER 2 [START_REF] Galliano | The ester phase ii evaluation campaign for the rich transcription of french broadcast news[END_REF] and REPERE [START_REF] Kahn | A presentation of the repere challenge[END_REF] collections. ASR performance was evaluated on the held out corpora presented in table 2 (used to train and evaluate ASR prediction) and its averaged value was 22.29% on the TRAIN set, 22.35% on the DEV set and 31.20% on the TEST set (which contains more challenging broadcast programs).

Figure 1 shows our network architecture. The network input can be either a pure text input, a pure signal input (raw signal) or a dual (text+speech) input. To avoid memory issues, signals are downsampled to 8khz and models are trained on six-second speech turns (shorter speech turns are padded with zeros). For text input, the architecture is inspired from [START_REF] Kim | Convolutional neural networks for sentence classification[END_REF] (green in Figure 1): the input is a matrix of dimensions 296x100 (296 is the longest ASR hypothesis length in our corpus ; 100 is the dimension of pre-trained word embeddings on a large held out text corpus of 3.3G words). For speech input, we use the best architecture (m18) proposed in [START_REF] Dai | Very deep convolutional neural networks for raw waveforms[END_REF] (colored in red in Figure 1) of dimensions 48000 x 1 (48000 samples correspond to 6s of speech).

For WER prediction, our best approach (called CNN Sof tmax ) used sof tmax probabilities and an external fixed WER V ector which corresponds to a discretization of the WER output space (see [START_REF] Elloumi | Asr performance prediction on unseen broadcast programs using convolutional neural networks[END_REF] for more details). The best performance obtained is 19.24% MAE3 using text+speech input. Our ASR prediction system is built using both Keras (Chollet et al., 2015) and Tensorflow4 .

In the next section, we analyze the representations learnt in the higher layers (3 blocks colored in yellow and dotted in Figure 1) for pure text (TXT), pure speech (RAW-SIG) and both (TXT+RAW-SIG).

Evaluating learned representations 4.1 Methodology

In this section, we attempt to understand what our best ASR performance prediction system [START_REF] Elloumi | Asr performance prediction on unseen broadcast programs using convolutional neural networks[END_REF] learned. We analyze the text and speech representations obtained by our architecture. Alike (Belinkov and Glass, 2017), the joint text+speech model is used to generate utterance Figure 1: Architecture of our CNN with text (green) and signal (red) inputs for WER prediction level features (hidden representations of speech turns colored in yellow in Figure 1) that are given to a shallow classifier trained to solve secondary classification tasks such as:

• STYLE: classify the utterances between (spontaneous and non spontaneous) styles (see table 1),

• ACCENT: classify the utterances between native and non native speech (see also table 1, we used the speaker annotations provided with our datasets in order to label our utterances in native/non native speech),

• SHOW: classify the utterances in different broadcast programs (as described in table 2, each utterance of our corpus is labeled with a broadcast program name).

As a more visual analysis, we also plot an example of hidden representations projected to a 2-D space using t-distributed Stochastic Neighbor Embedding (t-SNE) (Maaten and Hinton, 2008).5

Shallow classifiers

We built three shallow classifiers (SHOW, STYLE, ACCENT) with a similar architecture. The classifier is a feed-forward neural network with one hidden layer (size of the hidden layer is set to 128) followed by dropout (rate of 0.5) and a ReLU non-linearity. Finally, a sof tmax layer is used for mapping onto the label set size. We chose this simple formulation as we are interested in evaluating the quality of the representations learned by our ASR prediction model, rather than optimizing the secondary classification tasks.

The network input size depends on which layer to analyze (see figure 1). Training is performed using Adam (Kingma and Ba, 2014) (using default parameters) over shuffled mini-batches in order to minimize the cross-entropy loss. The models are trained for 30 epochs with a batch size of 16 speech utterances. After training, we keep the model with the best performance on DEV set and report its performance on the TEST set. The classifier outputs are evaluated in terms of accuracy.

Data

A data set from [START_REF] Elloumi | Asr performance prediction on unseen broadcast programs using convolutional neural networks[END_REF] The TEST set contains unseen broadcast programs that are different from those present in TRAIN and DEV [START_REF] Elloumi | Asr performance prediction on unseen broadcast programs using convolutional neural networks[END_REF].

Category

Results

For each classification task, we build a shallow classifier using the hidden representations of TXT, RAW-SIG and TXT+RAW-SIG blocks as input.

The experimental results are presented in table 4 for both DEV and TEST sets separated by two vertical bars (||).

Classification performance is all above a random baseline accuracy (>50% for STYLE and ACCENT and >20% for SHOW). This shows that training a deep WER prediction system gives representation layers that contain a meaningful amount of information about speech style, speech accent and broadcast program label. Predicting utterance style (spontaneous/non spontaneous) is slightly easier than predicting accent (native/non native) especially from text input. One explanation might be that speech utterances are short (< 6s) while accent identification needs probably longer sequences. We also observe that using both text and speech improves the learned representations for the STYLE task while it is 6 For the SHOW classification task, the FRANCE3-DEBATE shows were finally removed since they represent a too small amount of speech turns. less clear for the ACCENT task (for which improvement seen on DEV is not confirmed on TEST). Finally, text input is significantly better than speech input whereas we could have expected better performance from speech for the SHOW task (speech signals convey information about the audio characteristics of a broadcast program). It means that text input contains correlated information with broadcast-program type, speech style and speaker's accent. In case of SHOW task, our performance prediction system is able to capture information (vocabulary, topic, syntax, etc.) about a specific broadcast program type, based on textual features and to differ it from others (radio programs, TV debate programs, phone calls, broadcast news programs, etc.). Likewise, the textual information captured is very different between spontaneous/non-spontaneous speech styles and native/non-native speaker's accents.

Among the representations analyzed, the outputs of the CNNs (A1,B1) lead to the best classification results, in line with previous findings about convolutions as feature extractors. Performance then drops using the higher (fully connected) layers that do not generate better representations for detecting style, accent or show. We visualize an example of utterance representations from C2(TXT+RAW-SIG) layer in figure 2 using the t-SNE. For a fixed utterance duration 4s≤D<5s (716 speech turns) and 5s≤D<6s (489 speech turns), non spontaneous utterances are plotted in blue while spontaneous ones are in pink. The C2 layer produces clusters which shows that spontaneous utterances are in the upper-left part of the 2D space. This suggests that C2 hidden representation captures a weak signal about speaking style.

Finally, figure 3 is the confusion matrix produced using C2(TXT+RAW-SIG) layer. The classifiers very well predicted TELSONNE category (Accuracy of 82%), which contains many phone calls from the radio listeners. This show is rather different from the 4 other shows in DEV (broadcast debates and news). We have seen in the previous section that, while training an ASR performance prediction system, hidden layers convey a clear signal about speech style, accent and show. This suggests that these 3 types of information might be useful to structure the deep ASR performance prediction models. In this section, we investigate the effect of knowl-edge of these labels (style, accent, show) at training time on prediction systems qualities. For this, we perform multi-task learning providing the additional information about broadcast type, speech style and speaker's accent during training. The architecture of the multi-task model is similar to the single-task WER prediction model of Figure 1 but we add additional outputs: a sof tmax function is added for each new classification task after the last fully connected layer (C2). The output dimension depends on the task: 6 for SHOW and 2 for STYLE and ACCENT tasks.

We use the full (unbalanced) data set described in tables 1 and 2. Training of the multitask model uses Adadelta update rule and all parameters are initialized from scratch (8.70M). Models are performed for 50 epochs with batch size of 32. MAE is used as the loss function for WER prediction task while cross-entropy loss is used for the classification tasks.

In the composite (multitask) loss, we assign a weight of 1 for MAE loss (main task) and a smaller weight of 0.3 (tuned using a grid search on DEV dataset) for cross-entropy (secondary classification task) loss(es).

After training, we take the model that lead to the best MAE on DEV set and report its performance on TEST. We build several models that simultaneously address 1, 2, 3 and 4 tasks. The models are evaluated with a specific metric for each task: MAE & Kendall7 for WER prediction task and Accuracy for classification tasks.

Table 5 summarizes the experimental results on DEV and TEST sets, separated by two vertical bars (||). We considered the mono-task model described in [START_REF] Elloumi | Asr performance prediction on unseen broadcast programs using convolutional neural networks[END_REF] (and summarized in section 3) as a baseline system.

We recall that we evaluated the SHOW classification task only on the DEV set (TEST broadcast programs are new and were unseen in the TRAIN).

First of all, we notice that performance of classification tasks in muti-task scenarios are very good: we are able to train efficient ASR performance prediction systems that simultaneously tag the analyzed utterances according to their speech style, accent and broadcast program origin. Such multitask systems might be useful diagnostic tools to analyze and predict ASR on large speech collections. Moreover, our best multi-task systems dis- Table 5: Evaluation of ASR performance prediction with multi-tasks models (DEV ||T EST ) computed with MAE and Kendall -secondary classification tasks accuracy is also reported play a better performance (MAE, Kendall) than the baseline system, which means that the implicit information given about style, accent and broadcast program type can be helpful to structure the system's predictions. For example, in 2-task case, the best model is obtained on WER+SHOW tasks with a difference of +0.41%, +2.25% for MAE and Kendall respectively (on DEV) compared to the baseline on WER prediction task. However, it is also important to mention that the impact of multitask learning on the main task (ASR performance prediction) is limited: only slight improvements on the test set are observed for MAE and Kendall metrics. Anyway, the systems trained seem complementary since their combination (averaging, over all multi-task systems, predicted WERs at utterance level) leads to significant performance improvement (MAE and Kendall).

Conclusion

This paper presented an analysis of learned representations of our deep ASR performance prediction system. Experiments show that hidden layers convey a clear signal about speech style, accent, and broadcast type. We also proposed a multi-task learning approach to simultaneously predict WER and classify utterances according to style, accent and broadcast program origin.

  was employed in our experiments, divided into three subsets: training (TRAIN), development (DEV) and test (TEST). Speech utterances come from various French broadcast collections gathered during projects or shared tasks: Quaero, ETAPE, ESTER 1 & ESTER 2 and REPERE.

Figure 2 :

 2 Figure 2: Visualization of utterance representations from C2 layer for different speech styles (S spontaneous -NS non spontaneous) -(a) utt. length is 4s≤D<5s and (b) 5s≤D<6s

Figure 3 :

 3 Figure 3: Confusion matrix for SHOW classification using C2(TXT+RAW-SIG) layer as input, evaluated on DEV

Table 1 :

 1 Distribution of our utterances between non spontaneous and spontaneous styles, native and non native accents Tables1 and 2show the whole data set in terms of speech turns available for each classification task. We clearly see that the data is unbalanced for the three categories (STYLE, ACCENT, SHOW). Since we are interested in evaluating the discriminative power of our learned representations for

		TRAIN DEV TEST
	Non Spontaneous	54250	6101	3109
	Spontaneous	13277	1403	3728
	Native	44487	4945	5298
	Non Native	23040	2559	1539

Table 3 :

 3 Description of our balanced data set for each category

http://www.quaero.org

Mean Absolute Error (MAE) is a common metric to evaluate WER prediction ; it computes the absolute deviation between the true and predicted WERs, averaged over the number of utterances in the test

set. 4 https://www.tensorflow.org

https://lvdmaaten.github.io/tsne/ code/tsne_python.zip

Correlation between true ASR values and predicted ASR values