Rozenn Bouville
email: rozenn.bouvilleberthelot@irisa.fr

Val Érie Gouranton
email: valerie.gouranton@irisa.fr

Thomas Boggini
email: thomas.boggini@irisa.fr

Florian Nouviale
email: florian.nouviale@irisa.fr

Bruno Arnaldi
email: bruno.arnaldi@irisa.fr

#FIVE : High-Level Components for Developing Collaborative and Interactive Virtual Environments

This paper presents #FIVE (Framework for Interactive Virtual En- vironments), a framework for the development of interactive and collaborative virtual environments. #FIVE has been developed to answer the need for an easier and a faster conception and development of virtual reality applications. It has been designed with a constant focus on re-usability with as few hypothesis as possible on the final application in which it could be used. Whatever the chosen implementation for the Virtual Environment (VE), #FIVE : (1) provides a toolkit that eases the declaration of possible actions and behaviours of objects in the VE, (2) provides a toolkit that facilitates the setting and the management of collaborative interactions in a VE, (3) is compliant with distribution of the VE on different set-ups and (4) proposes guidelines to efficiently create a collaborative and interactive VE. It is composed of several modules, among them, two core modules : the relation engine and the collaborative interaction engine. On the one hand, the relation engine manages the relations between the objects of the environment. On the other hand, the collaborative interaction engine manages how users can collaboratively control objects. The modules that compose the #FIVE framework can be used either independently or simultaneously, depending on the requirements of the application. They can also communicate and work with other modules thanks to an API. For instance, a scenario engine can be plugged to any or both of the #FIVE modules if the application is scenario-based. #FIVE is a work in progress, new core modules will later be proposed. Nevertheless, it has already been used in some VR applications by several persons in our lab. The feedbacks we obtained are rather positive and we intent to further develop #FIVE with additional functional- ities, notably by extending it to the control of avatars whether they are controlled by a user or by the system.

INTRODUCTION

Over the past 25 years, many software systems and tools have been proposed to support the building of virtual reality applications. Since the RB2 system [START_REF] Blanchard | Reality built for two: a virtual reality tool[END_REF], these initiatives have followed the trend to match hardware and network capacities. For that reason, but also whether the solution was more or less generic, some have met a large adoption whereas others have now been forgotten. Despite all of these initiatives, in many cases, people still prefer to build than to reuse. To our point of view, a strong impediment of many of the previous solutions is that they depend on a specific engine or on a third-party library. Indeed, when a solution is tool-dependent, it significantly hampers its usage. For instance, the tool on which the solution depends on could no longer be maintained. Another reason can be that the developer already uses a concurrent tool which he/she prefers to keep. The third-party tool could also become less efficient given hardware and/or network evolutions. These observations led us to design a solution that is totally independent to any third-party tool or engine. Thus, the #FIVE framework is an highlevel toolkit that provides an abstraction layer to support the process of making a virtual environment collaborative and interactive.

The purpose of #FIVE is to support the development of our col- laborative and interactive demonstrators and lower the cost of creating new ones. It focuses on how to define the behaviours of virtual objects and also on interaction in VE, including collaborative interactions. Indeed, one of the main usage of a VE is to immerse users so that they can act in the virtual world. Nevertheless, our work does not focus on AI and Intelligent Virtual Environment such as those described in [START_REF] Lugrin | Making sense of virtual environments: action representation, grounding and common sense[END_REF]. To do so, every possible action and behaviour of interactive objects must be described. This mandatory task is, without an appropriate tool, fastidious and full of redundancy. The relation engine of #FIVE proposes a set of models to support this task; its role is to determine how and which objects of the world can be used. Furthermore, thanks to the broadening of high bandwidth networks and to the possibility of running 3D graphics on a large panel of devices, collaboration in virtual environments has become widely used. Therefore, providing models to ease the implementation of collaborative manipulation and distribution of virtual reality applications is relevant. This is the purpose of the collaborative interaction engine of #FIVE which provides a set of models for the collaborative control of virtual objects. The goal of the collaborative interaction engine is not to describe the semantic of interactions but to abstract the exchange of data for collaborative interaction without preventing the developer from de-ciding how concurrent commands are merged and applied to the object. Eventually, the #FIVE framework comes with guidelines that allows the developer to efficiently use the tools provided by #FIVE. Indeed, as #FIVE does not made any assumption on the implementation choice of the developer, its usage is versatile.

RELATED WORK

Designing and implementing virtual environment (CVE) has long been recognize as a complex and a time-consuming task, especially when they are collaborative. To assist and facilitate the development of these applications, many authors agreed in the fact that the community needs tools [START_REF] Kessler | The simple virtual environment library: an extensible framework for building VE applications[END_REF]. In this section, we present some existing software systems and tools that help in the design and implementation of Collaborative Virtual Environments (CVE). We then present a selection of works that highlights guidelines for designing and implementing VE in general. Finally, we conclude this section with a discussion on requirements for frameworks for CVE.

Frameworks for CVE

In this section, we focus on frameworks that allow collaborative interaction (i.e simultaneous interaction of several users on the same object) for two reasons. First, this is a strong requirement for our own projects. Second, even among widely used and interesting frameworks like MR toolkit [START_REF] Shaw | The decoupled simulation model for virtual reality systems[END_REF], FlowVR [START_REF] Allard | Flowvr: a middleware for large scale virtual reality applications[END_REF] or VRJuggler [START_REF] Bierbaum | VR Juggler: a virtual platform for virtual reality application development[END_REF], it is a very restrictive criterion. Indeed, collaborative interaction is not a mandatory feature of VE but, nonetheless, it is one of the most complex feature to implement because it takes into account, at once, graphics hardware capacities and networks constraints. In addition to the collaboration criteria, we study the existing systems through 4 other criteria :

1. interaction design model, i.e the interaction level allowed by the system (device independence, definition of relations between objects, description of object behaviours, etc. ), 2. distribution, i.e whether the system takes into account simultaneous executions and deployment among different platforms, 3. independence, i.e whether the system is independent from third-party tools, 4. versatility, i.e how much freedom of implementation is offered by the system, 5. factorization, i.e the level of re-usability achieved by the system.

One of the first software system to propose collaborative interactions is DIVE [START_REF] Carlsson | DIVE a multi-user virtual reality system[END_REF]. The DIVE system is more than 20 years old and since its first version, it went through several iterations. These iterations improved the system by adding features while preserving its independence on third-party tools. DIVE succeed in providing versatility in its usage but not in achieving re-usability.

The MASCARET system [START_REF] Buche | Mascaret: pedagogical multi-agents systems for virtual environment for training[END_REF] is another framework for CVE. It focuses on CVE for training, nonetheless, it has already been used for other kind of application. Here, the interaction design model relies on a language to describe behaviours of objects and their relations, allowing an high level of interaction. Moreover, it also takes into account, the semantic of the interaction using ontologies. Even though MASCARET enables multi-user application we could not find information on its distribution capability. Moreover, the modules that compose MASCARET are interdependent hence a little versatility.

Similarly to MASCARET, the GVT [START_REF] Gerbaud | GVT: a platform to create virtual environments for procedural training[END_REF] framework focuses on CVE for training. GVT provides an high interaction level through a description language that allows to precisely described behaviours of objects and their relations. In its last version, GVT relies on the Unity 3D engine and the distribution of an application developed using GVT is managed by Unity 3D. Moreover, the development of an application through GVT is really constrained, the modules of GVT are inter-dependants.

A more recent initiative, called ARTiFICe [START_REF] Mossel | Artificeaugmented reality framework for distributed collaboration[END_REF], proposes a framework to develop both distributed and collaborative applications as well as augmented reality applications. They do not propose a proper interaction design model since they focus more on a solution that can be easily adapted to support novel devices and interaction techniques. Several existing interaction techniques are proposed (VirtualHand [START_REF] Mine | Moving objects in space: exploiting proprioception in virtual-environment interaction[END_REF], Go-Go [START_REF] Poupyrev | The gogo interaction technique: non-linear mapping for direct manipulation in vr[END_REF], ...) but they are not customizable. Besides, ARTiFICe relies on Unity 3D making it dependent from this engine. The distribution model is based on the Unity 3D network layer enabling an efficient deployment on several platforms. Moreover, ARTiFICe allows to run simultaneous executions of a VE application, however, collaborative control of a single object is not possible. The strong coupling to Unity makes this solution not independent and not versatile.

It is worth noting that another initiative called FIVE (Framework for Immersive Virtual Environments) has already been proposed in 1997 by Slater et al. [START_REF] Slater | A framework for immersive virtual environments (FIVE): Speculations on the role of presence in virtual environments[END_REF]. Their work focuses on immersion and presence in VE and the purpose of this framework is to make presence a central concern in VE. Therefore, it does not address the same issues.

Reflecting on an Easier and Faster Development of CVE

The issues raised by the building of VE applications are pointed by several works as in [START_REF] Wingrave | Reflecting on the design and implementation issues of virtual environments[END_REF]. In an exhaustive study, the authors identify no less than 67 issues on VE design and implementation, that they arrange in 3 theme categories: human aspect, design and development. To conclude this study, several research challenges are proposed and two of them are close to the #FIVE concerns. First, they claim that representation and functionality must be divided into layers to narrow their focus since no single tool can address every VE needs. Second, they state that models of systems must be proposed:

A model operates at a higher level of representation; affording easier iterative development, improving reuse, containing complexity, reducing chaos, and addressing many of the issues with callbacks and events. Moreover, in [START_REF] Taylor | Lessons about virtual environment software systems from 20 years of VE building[END_REF], Taylor et al. discussed the lessons learned from 20 years of VE building. The creators of the widely used VRPN library [START_REF] Taylor | Vrpn: a device-independent, network-transparent vr peripheral system[END_REF] for VR peripheral system discuss several topics concerning VE design and implementation. On the topic related to object interaction, they recommend to split application specific interaction behaviours from the general event behaviour in VE systems. Thus, all sorts of interaction techniques can be built and used generally while the application specific behaviour remains the only part to be implemented on a case-by-case basis. This is in accordance with the observations shared by Steed in [START_REF] Steed | Some useful abstractions for re-usable virtual environment platforms[END_REF] who proposes some abstractions to make VE platforms reusable. In this paper, the author justifies his point of view by the fact that over a 15-years period, at least 40 VE software systems have been used in his lab.

Eventually, in [START_REF] Duval | When Model Driven Engineering meets Virtual Reality: Feedback from Application to the Collaviz Framework[END_REF], the authors are especially interested in the development of collaborative VE. They highlight three limitations that must be addressed by CVE frameworks. First, CVE frameworks should provide facilities to focus more on the behaviour of the shared virtual objects than on 3D graphics management or distribution and synchronisation issues. Second, they should allow designers to describe the content of the shared world in order to make the shared virtual objects easier to instantiate and configure. Lastly, CVE frameworks should provide support for the deployment on different rendering devices.

Discussion

None of the frameworks presented in section 2.1 answer all our needs. To our knowledge, there is no existing framework for CVE that covers all our requirements. Yet, these requirements follow the recommendations that can be found in the literature. Indeed, our will to provide an high-level interaction model is in accordance with the statement for systems of model in [START_REF] Wingrave | Reflecting on the design and implementation issues of virtual environments[END_REF], the statement for splitting interaction behaviour from event behaviour in [START_REF] Taylor | Lessons about virtual environment software systems from 20 years of VE building[END_REF] or the statement for focusing more on the behaviour of the shared virtual objects than on 3D graphics management or distribution and synchronisation issues in [START_REF] Duval | When Model Driven Engineering meets Virtual Reality: Feedback from Application to the Collaviz Framework[END_REF].

The three other criteria result from the same idea. Independence ensures that the framework is decoupled from hardware or software issues. In the same way, enabling versatility makes it possible to cover more needs and to answer more technical constraints that developers can met. Furthermore, the factorization concern reflects our will to not rebuild from scratch each time we begin the development of a new VR application. Eventually, we observed that, for the past 5 years, powerful game engines have been released. They propose an all-in-one solution to quickly and easily generate gamelike real-time VE. A framework for CVE should take advantage of this kind of tool while remaining technologically independent.

OVERVIEW OF #FIVE

#FIVE is a novel framework that offers a set of models to ease the development of new VE applications in order to make them: collaborative, interactive and distributed. First, #FIVE provides a model to ease the declaration of possible actions of objects in the VE. We need, for instance, to easily declare that every screw in the virtual world can be involved in a screwing task. Furthermore, we want to easily declare that a relation exists between a screwdriver and a screw that can result in a screwing action. Second, #FIVE gives a model to facilitate the setting and the management of collaborative interactions in a VE. Indeed, being able to collaboratively control an object is an essential task in CVE, therefore, it is relevant to support an easier set-up of how objects can be controlled and how concurrent control order must be managed. Third, the models proposed by #FIVE are distribution-friendly in order to ease the distribution of the VE for multiple users. Given the variety of available setups and use-cases of CVE, it makes sense to take into account the distribution of a VE early in its development. That is why, #FIVE's in- ner models is not only compliant with multiple platforms (desktop, CAVE, tablet, ...) but they also provides support for distribution. Fourth, #FIVE provides guidelines that allow users to be more effi- cient in the development of the VE. In fact, #FIVE can be integrated in a VE in several ways. It lets the developer free of its implementation choices but guidelines are nonetheless proposed based on our experience on CVE design and implementation.

As shown in figure 1, #FIVE is, for now, composed of two core components : the relation engine and the collaborative interaction engine. The Relation Engine computes the possible the actions of objects in the virtual environment whereas the Interaction Engine manages the interactions performed by users (collaborative or single-user ones) in the virtual environment. Both of them provide an API dedicated to communication with the VE as well as communication between each other. For instance, an action triggered by the relation engine can trigger an interaction that uses the collaborative interaction engine.

#FIVE also assists the developer with the distribution of the virtual environment and manages collaborative interaction on the objects of the world.

The main originality of #FIVE is that it lets developers free of their implementation; letting them free to use any engine or thirdparty tool they feel comfortable with. Indeed, recent years have shown us that the VR domain is subject to lots of changes from hardware devices to rendering and interface techniques as well as softwares. Hence, this strong constraint in the design of #FIVE. Thus, the interactions managed by #FIVE are low-level making it possible to use #FIVE with any kind of input device whatever the degrees of freedom enable by the device. Indeed, #FIVE does not describe interactions but rather proposes a system that can hide the complexity of data exchange for collaborative interactions. We do not work on the semantic level, which is why we do not consider protocols for description but it can be added by the developer.

As for the actions and relations of objects, even if #FIVE man- ages their run-ability, the precise action is described by the developer inside the VE.

Besides, #FIVE does not force the developer to use all the modules. Finally, another benefit of #FIVE is that it makes it possible to reuse components from one application to another. Several components developed for a #FIVE-based application can be reused (see figure 2 ): the abilities of objects and their behaviours as well as the descriptions of the interactions. The next two sections present the functioning of the relation engine and of the collaborative interaction engine then the section 6 gives examples of the integration of #FIVE in a virtual environment applications.

THE RELATION ENGINE

The relation engine of #FIVE proposes a set of models to support the definition of actions and behaviours of objects of a VE. Its role is to determine how and which objects of the world can be used. In this section, we present the data model behind the relation engine. Afterwards, we explain how this data model is used by the relation engine and we illustrate this with an example. We conclude this section by a discussion on the benefits of the relation engine.

Data Models of the Relation Engine

The data model of the relation engine is based on two concepts: relational object and relation. First, we call relational object any object of the world that can be involved in a relation. For that purpose, #FIVE types are attached to relational objects. #FIVE types (noted type in the remainder of the paper) are properties that an object has and that is required for involving it in a relation. Each type of an object has an identifier that is unique in the context of the object. Next, we call a relation a template of actions; it is defined using a set of object patterns. Object patterns are patterns of object that are defined by a set of type. Figure 3 illustrates these two main concepts: a relational object O a that has two types (t 1 and t 2 ) and a relation R a that connects two object patterns (X and Y ). For instance, let us suppose that we have a threaded rod with two threaded extremities and a nut in our virtual world. In order to involve them in a screwing action ruled by the relation engine, we must attribute types to both objects. As the threaded rod (noted O Rod ) has two threaded extremities, it can be typed as "male" twice. In the same way, the nut (O Nut ) can be typed as "female" twice. We call the two male types of O Rod "Extremity a" and "Extremity b" respectively and the two female types of (O Nut ) "Side a" and "Side b" respectively : O Rod = (t male : Extremity a, t male : Extremity b) O Nut = (t f emale : Side a, t f emale : Side b) Then, to be able to perform the action "screw" in our virtual environment, we can define a relation screw. This relation connects two objects; one must be typed as female and the other must be types as male. We define the relation R Screw with two object patterns OP x and OP y that define this requirements like this : R Screw = OP x (t male ), OP y (t f emale ) Of course, any other object of the world that possesses the types t male and t f emale can be involved in the relation R Screw . If we want a more specific screwing relation that only takes into account nuts, we must add a type to every nut (t nut ) in our world and define a new relation similar to R Screw except that it also contains the object pattern that defines nuts like this : R Screw-Nut = OP x (t male ), OP y (t f emale ,t nut )

Usage of the Relation Engine

Based on this data model, the relation engine can instantiate relations. We call, the instantiation of a relation a realization. For a relation to be instantiated as a realization, each one of its object pattern must match a relational object of the world. There is a match between a relational object O a and an object pattern OP x when O a possesses at least all types contained in OP x . Using our sample of threaded rod and nut, a possible realization of the relation R Screw could be instantiated with one extremity of the rod and one extremity of the nut. Thus, a possible realization for the relation R Screw Before executing the realization, the actual value of variables that takes part into the action defined by the realization must be checked. Indeed, the developer must specify in the realization on which conditions it can be run, for example, using the state of the world, the parameters of the objects involved or the state of the object. For that purpose, an intermediate step is runned to ensure that the realization can really be runned given data external to the relation engine.

In order to help the developer to trigger realizations from the context of the VE, the API of the relation engine provides methods to trigger realizations. To do so, the API provides a query interface that proposes methods to interrogate the relation engine. The relation engine can actually answer several queries deduced from the completion of its data model. This completion results from the declaration of relational objects and relations. The relation engine can answer three basic queries:

1. What are the realizations where all objects of a given set of objects can be involved ? The figure 4 illustrates all three queries. In our sample VE, we have four objects (0 a ,0 b ,0 c and 0 d ) and one relation (R a ) declared. Query 1 takes a set of objects (0 a and 0 d ) and gives the possible realizations. In our case, only one realization is possible : R1. Query 2 takes a relation, (R a ), and gives all possible realizations. Here, two realizations are possibles : R1 and R2. Finally, query 3 takes a relation (R a ) and a set of objects (0 a and 0 c ) to give all possible realizations. Given our input data, the only possible realization is R2.

Benefits of the Relation Engine

The data model and the capacities of the relation engine make it possible to "annotate" a virtual world in a rather straightforward way. Indeed, the concept of type is close to the way humans apprehend their surrounding environments; mentally arranging the available objects function of their capacities. Thus, the same type can be attributed to several objects if they share the same property. Furthermore, the concept of type and relation is flexible and extensible: as many types as required by the application can be defined. Moreover, types and relations can be re-used in other applications. Thanks to #FIVE, we can not only re-used 3D models but also their behaviours and the actions they may be involved in. Using the standard signature defined in relation engine's API, relations are accordingly hard-coded by the developer, making the link with the VE. Indeed, when simulated by the virtual environment, a nut will always be screw-able in any virtual world and the action of screwing will result in (slightly) the same behavior for this nut.

The usage of the virtual environment is also rather intuitive. Based on our experience in interactive VE, we extract the most useful queries but, if required by a specific application, new ones can easily be added. Besides, the time-response of the queries provided through the API is compatible with real-time VE. The relation engine can be interrogated any time during a simulation, taking into account the context at the time of the query. It allows the developer to propose to users a list of every possible actions at a given time function of the context (state of the world, of objects,...). Thus, the relation engine opens new perspectives and possibilities of interaction in a VE by providing efficient tools to the developer to be aware of every possible actions continually during a simulation.

THE COLLABORATIVE INTERACTION ENGINE

The purpose of the collaborative interaction engine of #FIVE is to provide a set of models for the collaborative control of virtual objects. In this section, we first detail the data model behind our collaborative interaction engine and, afterwards, we explain its usage and its features. To conclude this section, we discuss the possibilities offered by the collaborative interaction engine in a VE.

Data Models of the Collaborative Interaction Engine

With a view to keeping the model as generic as possible, the data model behind the collaborative interaction engine relies on only two distinct entities: interactive objects and interactors (see figure 5). On the one hand, an interactive object can be any object in the virtual world that possesses a set of controllable parameters. Controllable parameters are parameters that can be modified by an interaction. A controllable parameter is defined by an access manager, a data type, a data identifier and a merger. The access manager defines the access rights that rules the controllable parameter. The merger describes the merging policy employed when concurrent modifications are induced by a collaborative interaction. For instance, let us take the nut of the example presented in the previous section. We want the nut to be controlled in two ways: its rotation around the Y axis and its translation on the Y axis. Thus, we can add to the nut two controllable parameters like this :

O Nut = (RotationY : Float (Merger 1 ), TranslationY : Float (Merger 2 ))
On the other hand, an interactor is an entity that can alter a controllable parameter. Each interactor comes with a type that defines the type of parameter it can control. An interactor can be attached to an object if we need to represent it visually in the VE. Besides, an interactor describes how the interaction should be performed given the parameter. For instance, to interact with the nut, we can add an interactor for rotating an object around an axis. Our interactor will only be allowed to control parameters typed as float. We note our interactor like this :

I Rotate = ( f loat)

Usage of the Collaborative Interaction Engine

An interaction managed by the collaborative interaction engine is always initiated by an interactor. Moreover, an interactor is only able to control objects that possess a controllable parameter that matches its own type.

Interactions are made up of 5 steps :

1. The interactor asks permission to an interactive object to access one of its controllable parameter.

2. If the access is granted then the interaction begins. The interactor sends a value to the controllable parameter. The way the value is computed is defined in the interactor and is specific to an interactor. For example, the interactor can be linked to an input device that provides it some values. The interactor processes it before sending a value to the controllable parameter of an object.

3. If the controllable parameter is already being accessed by another interactor, the values received are merged according to the merging policy defined in its merger. For example, when controlling the position of an object, if the merging policy is the mean between the values then the position of the object will be halfway between the position asked by the two interactors.

4. The value of the controllable parameter is actually updated and the state of the interactive object is updated accordingly.

5. The interactor releases its control over the controllable parameter.

Figure 6 summarizes the usage of the collaborative interaction engine when the virtual environment is distributed on two different platforms with one user on each. As shown in the example 1 in figure 6, an interactor can only alter one controllable parameter but one object can be controlled by several interactors; each one of them controlling one controllable parameter. This is useful to make complex interaction that results in complex trajectories for the controlled object. For instance, if we want to simulate a screwing task with our nut by translating it while it rotates, we must use another interactor that will control its translation. The other interactor could be noted like this :

I Translate = ( f loat)

Benefits of the Collaborative Interaction Engine

The API of the collaborative interaction engine provides a set of methods to easily settle how users can collaboratively control objects. The collaborative interaction engine not only takes into account access rights and concurrent interactors but can also merge the commands of several interactors, using a customizable merging strategy. Furthermore, the model of the collaborative interaction engine is independent from what triggers the interaction; it can be any event happening in the VE: proximity, user input as well as a realization launched by the relation engine. In fact, thanks to this model, the interactions managed by the collaborative interaction engine can be independent of the inputs of a specific device, whatever its degrees of freedom. Moreover, by using the model behind the collaborative interaction engine, it is possible to chain interactions. An interactor I a can indeed possess controllable parameters that another interactor I b can control. While I b controls I a , I a can control another object. An example of chained interactions can be a hand that controls a screwdriver that itself controls a screw. Furthermore, interactors can be reused in several application. Indeed, interactors can describe complex interaction (opening a drawer, screwing, ...) so that it is interesting to reuse it in another virtual environment.

INTEGRATION OF #FIVE IN UNITY 3D

In this section, we present the integration of #FIVE in the context of Unity 3D. We only rely on Unity 3D for authoring tools and network data transfer so that other platforms can similarly be used such as Simulator X [START_REF] Latoschik | Simulator x: A scalable and concurrent architecture for intelligent realtime interactive systems[END_REF]. We first discuss about the adaptation of our framework with the 3D engine and the need of a common interface in-between. Motivations and their corresponding applications are addressed step by step. We finally show several demonstrators as concrete implementations based on this work. They focus on this or that aspect of #FIVE to enforce the understanding. However, as it is still an ongoing work, these applications tend to integrate all the features of the framework.

The Unity 3D-#FIVE layer

The core modules of the framework are implemented using C#. They are compiled as DLL. They are distributed in this form coming along with their documentation (i.e. mainly a detailed API and developer guidelines).

Our main concern in the integration process was to transform the Unity 3D editor in a #FIVE authoring interface following the already existing UI philosophy of Unity 3D; each #FIVE entity (e.g. relation, object, interactor, ... ) matches a Component linked to a Game Object of the Scene and it is fully configurable from the Inspector (c.f. Figure 7). This mapping emphasizes the straightforwardness of the model and focuses on the ease-of-manipulation of its concepts. Although this set-up enables authors to script their own #FIVE items from software abstractions, we aimed at providing them essential entities as Unity 3D components off-the-shelf. We are growing this set empirically on the basis of our subsequent implementations of the framework. For instance, we noticed that "take" (i.e. some user can take some object) is a highly common relation, likewise "pull" (i.e. a user moves an object along a predefined axis) is a very frequent interaction. This catalogue considerably speedsup the building of simulations, developers only need to focus their creativity on more specific behaviours.

We were also looking to make #FIVE profit of high level features provided by Unity 3D such as networking. Our integration takes advantage of the Unity 3D networking API to implement the distribution model of #FIVE. For instance, interactions can be performed in different executions of a same simulation, on different platforms and by different users acting simultaneously. This aspect enhances the collaboration capability of #FIVE and makes it available at no extra-effort for the Unity 3D developers.

Finally, we intended to supply a strong information resource to the 3D designers to value this integration intention. The extension on the top of #FIVE and Unity 3D comes along with a reference documentation. This document is an exhaustive index of the Unity 3D components we implemented, their parameters and their authorized values. However the added-value of this manual lies in the listing of the possible usages of the framework. Although the full potential cannot be addressed, we aim at covering many application as a feedback to the developers. For example, we suggest that the running of a relation can trigger an interaction, furthermore a third-party scenario engine can impact the set of allowed relations, etc. In addition, these software engineering guidelines are implemented in demonstrators included in the package which comes with the Unity 3D-#FIVE layer.

The Bolt demonstrator

This minimalist demonstrator consists of a threaded rod with two nuts at its extremities. They can be screwed back and forth along the stem by multiple users at the same time. They can choose to apply concurrent or opposite forces on a same nut to speed-up or to slow-down its movement. Above everything else, this implementation strongly highlights the distributed faculties of the collaborative interaction engine. Indeed, simultaneous interactions are echoed in all the executions of the simulation using the networking feature of the Unity 3D-#FIVE layer. Furthermore the merger function of the engine handles the way concurrent interactions are taken into account.

Since there is a unique relation defined for this demonstrator (i.e. linking of a user, a threaded rod and a nut), the set-up is very limited and there is no dynamicity in the scenario, the simulation does not really benefit from the query interface of the relation engine; the processed realizations are quite expected.

Thanks to the multi-platform export feature of Unity 3D, the interoperability of #FIVE has been put to test and confirmed. Using the MiddleVR middleware, this scene was executed concurrently on different hardware systems: Android tablet, iPad, Oculus Rift DK2 with Razer Hydra, VR rooms (a.k.a. CAVE), desktop and laptop computers (c.f. Figure 8).

The Operating Room demonstrator

The ambition of this demonstrator is to train nurses to prepare an operating room prior to a surgery. The trainee is mainly asked to move objects to their target location. A scenario develops the procedure giving visual hints using a colour-based code; take-able surgical instruments are highlighted in blue, handles of the movable apparatus are yellow, scenario targets are green and so on. (c.f. Figure 9). The application demonstrates an eventual conjunction of #FIVE with an external scenario module, here, the #SEVEN scenario engine [START_REF] Claude | Short Paper: #SEVEN, a Sensor Effector Based Scenarios Model for Driving Collaborative Virtual Environment[END_REF]. This narrative engine defines the whole of the relations at every key moment of the scenario. Once a relation is introduced, the objects of the scene which are potentially involved in it are tinted; in blue whether they contribute to the "take" relation, in yellow if they are involved in "move", etc.

This implementation also makes an extensive use of the query interface of the relation engine. It is interrogated each time the scenario engine updates the set of the relations in order to determine the objects to highlight in the scene. It is questioned anew when the type of a relational object is modified. For instance, when the nurse participates to a realization she can no longer be involved in any other relation.

There are numerous possible interactions in this scene: the user can open and close drawers, push and pull appliances on the floor, open and close doors, etc. As well, this demonstrator is a proof-ofconcept which reveals that various interactions can be implemented with very few predefined generic components from our suite: moving along an axis, moving on a plane, rotating along an axis, etc.

The Bar demonstrator

In this demonstrator, the user finds himself in a bar with many items. Some of them have no real use, they can just be taken and thrown on the ground. Some others can be combined in order to make a tool which can repair the flawed light system of the place.

Building this application was the opportunity to experiment different graphical metaphors to highlight the interactive objects of the scene. Besides the Operating Room demonstrator, this implementation introduces a visual representation of the relations: when the user targets an object with a pointing device, it is linked with semi-transparent rays to the other objects which it is related (c.f. Figure 10).

This application also proves that our system can dynamically handle the updates of the world: combination, introduction, destruction and modification of relational objects. In our combination use-case, the query interface of the relation engine is used to determine and to recompute the impacted relations.

DISCUSSION AND CONCLUSION

In this paper, we present #FIVE, a framework that provides a set of models to support the development of collaborative and interactive virtual environments. Its particularity resides in the fact that #FIVE has been conceived with no assumption on the implementation of the final virtual reality application. Indeed, it is not dependent on a specific rendering engine nor on any hardware configuration. In fact, #FIVE gives to the developer, an abstraction layer that support the process of making a VE interactive, collaborative and distributed. Thanks to the two core module of #FIVE, the relation engine and the collaborative interaction engine, the developer is given a versatile tool to precisely describe the behaviours of the object of the world, the relations between the objects as well as how an object can be manipulated. Besides, the models proposed by #FIVE allows the user to develop customizable components that can be reused from an application to another.

The development of the framework is a work in progress. We are currently looking forward to release a second version. Firstly, this will introduce a user model: their role, their ability, their knowledge, etc. This way, the system will filter the interaction options of real and/or virtual users. Secondly, an all-knowing observer will analyse and evaluate the actions of the users in real time or retrospectively for pedagogical reasons. This will offer to #FIVE a training orientation and make it ready for CVET. Lastly, a porting to another 3D engine is under consideration, in order to demonstrate the independence of the framework regarding virtual environments.

Figure 1 :

 1 Figure 1: Architecture of #FIVE : collaborative interaction between several instance of the same simulation are supported by #FIVE. #FIVE also supports the definition of action of objects of a VE.

Figure 2 :

 2 Figure 2: The VE and the #FIVE engines (blue) can use at once custom reusable components (red) and application specific elements (green).

Figure 3 :

 3 Figure 3: The 2 main concepts used by the relation engine. The object O a has two #FIVE types : t 1 and t 2 . The relation R a connectstwo object patterns : one describing objects that possess at once t 1 and t 2 at least, and another for objects that possess t 4 at least.

  can be realized with Extremity a of O Rod and the Side a of O Nut : R Screw = (O Rod (Extremity a), O Nut (Side a)) Indeed Extremity a of O Rod matches the first object pattern of R Screw and side a of O Nut matches the second object pattern. Another possible realization is : Re Screw = (O Rod (Extremity a), O Nut (Side b))

2 .

 2 What are the possible realizations of a given relation ? 3. What are the possible realizations given a relation and a set of objects ?

Figure 4 :

 4 Figure 4: Given the relational objects and the relations declared for the VE through #FIVE, the relation engine can answer 3 types of queries to check what are the possible actions anytime during the simulation runned by the VE.

Figure 5 :

 5 Figure 5: In order to use the collaborative interaction engine, objects of the VE are given controllable parameters of different types (0 1 has 2 controllable parameters CP 1 and CP 2 ). Besides, interactors are defined along with a type that specifies which type of controllable parameters they can modify.

Figure 6 :

 6 Figure 6: Collaborative interactions with the collaborative interaction engine. In the first case, interactor I 1 is controlling CP 1 whereas I 3 is controlling CP 2 . Their values (respectively (v 1 ) and (v 5 )) are send to the object 0 b . In the second case, two interactors (I 1 and I 2 ) access CP 1 , sending value v 2 and v 3 respectively. A merged value (v 4 ) is send to O a according merger M 1 .

Figure 7 :

 7 Figure 7: The selected Game Object stands for a relational object which can be involved in a relation; it has a UF Object Component. Its type states it has the ability to be grabbed; it has the S3PM Grabbable Component.

Figure 8 :

 8 Figure 8: The Bolt demonstrator is running simultaneously on various platforms: a CAVE in the background, a laptop computer on the left, the video capture of an Oculus DK2 on the right, an iPad and an Android tablet in the foreground.

Figure 9 :

 9 Figure 9: The user must move the appliance to match its green ghost. He can grab it from the yellow handle. Then he can bring it to its target.

Figure 10 :

 10 Figure 10: The user points the hammer. The rays show that it can take part in a relation with the right hand and/or the left hand and/or the switch, etc. It gives the user indications of what can be performed.

ACKNOWLEDGEMENTS

This publication is supported by the S3PM project of the Comin-Labs Excellence Center and the FUI PREVIZ.


T Hamiti

T Lubin

A Rezzoug

A simple and Efficient Tool for Design Analysis of Synchronous Reluctance Motor

This paper presents an efficient tool for design analysis of a Synchronous Reluctance Motor (SynRM). The Winding Function Analysis (WFA) is used instead of the Finite Element Analysis (FEA). With WFA approach, parameters sensitivity analysis and the impact on the machine design can be evaluated very rapidly (under linear condition). The effect of rotor skewing, stator winding chording, pole arc and interpolar air-gap length on average torque and torque ripple is investigated. The results obtained by WFA are compared with those obtained by two-dimensional FEA. It is shown that the two methods give approximately the same results but require different computation time.

I. INTRODUCTION

S YNCHRONOUS reluctance motor is an interesting solu- tion for variable frequency drives and servomechanisms [START_REF] Boldea | Reluctance Synchronous Machines and Drives[END_REF], [START_REF] Vagati | The Synchronous reluctance solution: a new alternative in A.C. drives[END_REF]. In its cut-outs rotor version, despite poor efficiency and power factor, its cost manufacturing, ruggedness and synchronism with power supply frequency can constitute a good challenge, while an optimal design for maximum torque and minimum torque ripple must be achieved. To maximise average torque and power factor of a line-start SynRM, an Authors are with the Groupe de Recherche en Electrotechnique et Electronique de Nancy, GREEN-CNRS UMR -7037, Université Henri Poincaré, BP 239, 54506 Vandoeuvre-lès-Nancy Cedex, France (Phone: 33 3 83 68 41 28; e-mail: tahar.hamiti@green.uhp-nancy.fr.)

Manuscript received June 15, 2007.

analytical design model is proposed in [START_REF] Chabu | A new design technique based on a suitable choice of rotor geometrical parameters to maximise torque and power factor in synchronous reluctance motors: Part I and II[END_REF]. However, it does not take into account torque ripple which is a serious drawback especially when position control is needed. Furthermore, the motor was designed for self starting operation, thus it contains a squirrel cage which adds an other constraint for the design task, and is subject to additional losses. Vector control permits synchronous self starting without damping bars. X. Bomela and M.J. Maarten have done a consisting study on stator chording and rotor skewing effect on average torque, power factor and torque ripple [START_REF] Xola | Effect of Stator Chording and Rotor Skewing on Performance of Reluctance synchronous Machine[END_REF]. This study has been evaluated with FEA which is, as known, very time consuming. Broadly, very much attention is given for high anisotropy normally or axially laminated flux barrier SynRM [START_REF] Vagati | Design of Low-Torque-Ripple Synchronous Reluctance Motors[END_REF], [START_REF] Miller | Design of a Synchronous Reluctance Motor Dive[END_REF]. With this type of structure, high performance drives can be achieved but the manufacturing simplicity is lost.

We have shown in [START_REF] Lubin | Comparison between Finite Element Analysis and Winding Function Theory for Inductances and Torque Calculation of a SynRM[END_REF] that accurate shapes of inductances and electromechanical torque can be obtained using the winding function theory. The computation quickness of this method constitutes its main advantage when several stator and rotor geometries are to be tested, also when a refined model of the machine must be inserted within a complex simulation control scheme.

This paper proposes a use of Winding Function Analysis to design an optimized SynRM in terms of average torque and torque ripple. The cross-section of the stator and the rotor structure of the studied SynRM is shown in Fig. 1. The rotor presents a simple and robust structure without damper bars. The stator is the same as the one of an induction machine and has 3 phases distributed winding within 36 slots. The machine dimension details are given in table I.

II. COMPUTATION PROCEDURE AND RESULTS

A. Winding Function Analysis (WFA)

Winding function theory [START_REF] Tabatabaei | Modeling and simulation of a salient-pole synchronous generator with dynamic eccentricity using modified winding function theory[END_REF], gives the self and mutual inductances expression as:

L ij = µ 0 RL 2π 0 1 e s (θ) + e r (α -θ) N i (α) N j (α) dα. (1)
In this expression, N i (α) is called the winding function i and represents in fact the magnetomotive force distribution along the air-gap per unit current flowing in the stator winding i. The rotor an stator air-gap length functions e r (αθ) and e s (α) of the studied SynRM have been defined in [START_REF] Lubin | Comparison between Finite Element Analysis and Winding Function Theory for Inductances and Torque Calculation of a SynRM[END_REF].

The instantaneous torque computation is obtained by:

Γ = 1 2 [I] t ∂L ∂θ [I] , (2)
with:

[L] =   L a (θ) L ab (θ) L ac (θ) L ab (θ) L b (θ) L bc (θ) L ac (θ) L bc (θ) L c (θ)   , (3)
and:

[I] =   i a (θ) i b (θ) i c (θ)   . (4)
For a given structure of the machine, ( 1) is numerically integrated after the definition of winding and air-gap functions [START_REF] Lubin | Comparison between Finite Element Analysis and Winding Function Theory for Inductances and Torque Calculation of a SynRM[END_REF]. For each rotor position, (2) is computed with the following imposed currents:

i a = √ 2I rms cos (θ + φ) ; i b = √ 2I rms cos θ -2π 3 + φ ; i c = √ 2I rms cos θ + 2π 3 + φ . (5)
To avoid saturation I rms is fixed to 2A and the electrical current phase φ is fixed to 45 • in order to develop the maximum average torque.

B. study of parameters sensitivity

To minimize the ratio of the torque ripple ∆Γ to the average torque Γ avg , the skewing angle δ, the chording factor k, the pole arc β and the interpolar air-gap length e2 have to be considered (Table I).

Every parameter influence is studied by calculating

Γ avg = 1 N p Np i=1 Γ (i); (6)
∆Γ = max (Γ) -min (Γ) Γ avg , (7)
N p is the number of points over one computation period. 3600 points ensure a satisfying precision.

1) Effect of rotor skewing (δ)

To reduce the ripple torque caused by the slots, the well known technique is the skewing. To simulate the 3D effect generated by the skewing, multiple 2D unskewed submachines are considered as shown in Fig.2 [START_REF] Eastham | Finite Element Analysis of an Interior-Magnet Brushless D.C. Machine, with a Step-Skewed Rotor[END_REF]. With WFA, thanks to the refined path resolution (N p = 3600), computing only the average value over N s points of the unskewed inductances, we obtain the skewed inductances as:

L ski = 1 N s -Ns 2 r=-Ns 2 L i (r), (8)
M skij = 1 N s -Ns 2 r=-Ns 2 M i (r), (9)
N s is the integer number of the skewing angle/path resolution (0.1 • ) ratio. After computing ( 8) and ( 9), the torque is obtained by [START_REF] Vagati | The Synchronous reluctance solution: a new alternative in A.C. drives[END_REF]. With FEA software [START_REF] Meeker | Finite Element Method Magnetics[END_REF], because of the required time computation, the path angle resolution is 1 • , we can't obtain the skewed torque by averaging. Hence, to compute correctly the skewed torque, 10 slices must be taken. Figs 3 and4 show the inductances and the instantaneous torque for unskewed and one slot pitch (10 • ) skewed rotor. Differently of flux barrier rotor SynRL [START_REF] Vagati | Design of Low-Torque-Ripple Synchronous Reluctance Motors[END_REF], the salient poles SynRL becomes free of slots ripple torque with exactly a full stator slot pitch. The residual torque ripple is due to the distributed winding and the rotor saliency.

The influence of the skewing angle on both average and ripple torque is shown in Fig. 5. It illustrates the optimum skewing angle (δ = 10 • ) that is pointed on above. In this case we denote a reduction of torque ripple from 130% up to 26% and a decrease of average torque by only 3%.

2) Effect of stator winding chording (k)

The effect of stator winding chording on the torque ripple and average torque is investigated by varying the fractional pitch windings. Fig. 6 represents the winding functions of the phase "a" in the cases of full pitch winding and 7 9 chorded winding. It has been shown in [START_REF] Xola | Effect of Stator Chording and Rotor Skewing on Performance of Reluctance synchronous Machine[END_REF] that chording the stator of a flux barrier SynRL has a very little effect on the torque ripple. That is false in our case. Indeed, Fig. 7 shows an important reduction of torque ripple without a sensitive drop on the average torque for a chording factor of 8 9 whatever β.

3) Effect of the pole arc (β)

The saliency angle is a deterministic parameter for a cutouts rotor SynRM. In [START_REF] Chabu | A new design technique based on a suitable choice of rotor geometrical parameters to maximise torque and power factor in synchronous reluctance motors: Part I and II[END_REF], an optimum angle of 45 • was found. However, no attention has been given to the influence of this parameter on torque ripple. Fig. 8 shows the effect of the pole arc (β) on both the average and ripple torque. The optimum β for maximum average torque is 43 • and for minimum torque ripple is 44 • . With FEA, the optimum angle is 40 • for both ripple and average torque. However, we can observe that the curves are relatively flat in the interval [40 • , 45 • ], we can thus choose an angle within this interval. It is important to note that even not 1 minute is required to compute the whole skewed torque with WFA against more than 2 hours with FEA.

4) Effect of the interpolar gap length (e2)

The interpolar gap length has been defined in Fig. 1. Its influence is also studied and the results are shown in Fig. 9. We can observe that beyond the value of approximately 20 for the ratio e2 e1 the average and ripple torque are not subject to sensitive variation. Moreover, this low value is beneficial for mechanical ruggedness and for a judicious choice of rotor yoke length to avoid flux path undersizing.

III. EFFECT OF THE MAGNETIC SATURATION

In order to check if the magnetic saturation have an influence on the optimized parameters obtained by WFA, FEA is used by considering a nonlinear magnetic B(H) characteristic and an I rms value of 6A. Fig. 10 shows the superposed results of the two methods and leads to the following observations. Firstly, the optimum pole arc stay the same for both linear and nonlinear cases. Secondly, as commonly known, the average produced torque is strongly decreased by the saturation.

IV. PROTOTYPE REALIZATION

The prototype reluctance motor is designed on the basis of a standard 4-pole, 3kW squirrel cage induction motor. The stator of the considered motor contains 36 slots with three phase full pitch winding (k = 9 9 ). The skewing angle of the rotor bars being equal to 13 • determines the direction of milling to obtain the rotor salient poles. The manufactured rotor is shown in Fig. 11. It has the following parameters : β = 45 • , e2 = 10mm and δ = 13 • . To avoid damping effect, the rotor end-rings are cut-off. As demonstrated previously, the best values of the chording factor k and skewing angle δ are respectively 8 9 and 10 • . One can observe in Fig. 5 that the curve representing the torque ripple versus δ is relatively flat between δ = 10 • and δ = 15 • , so the chosen skewing angle is suitable to verify the theory. To investigate the chording effects on the torque ripple, in addition to the original stator with k = 9 9 , another one having k = 8 9 is currently under construction. Experimental tests will be done in futur work in order to validate the theoretical results.

V. CONCLUSION

An entire study of a four pole, 36 slots and three phases SynRM is done with a simple and fast computation method based on Winding Function Theory. The improvement of the method is verified with Finite-Element Analysis. It is shown that to obtain minimum torque ripple and maximum average torque, the rotor must be skewed by a stator slot pitch, a chording factor of 8 9 ensure a good compromise, no necessity to have a very large interpolar air-gap length (a value of 20 times e1 is sufficient) and the optimal pole arc is around 45 • . An optimized rotor prototype has been manufactured by milling the one of an existing induction machine. Futur work consists on experimental validation of the theoretical results. Furthermore, as the proposed method is not time consuming, it can be easily used within a global design optimization task. For that, one can use for example genetic algorithms or sequential quadratic programming.

  NOMENCLATURE R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rotor outer radius (m). L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Active axial length (m). N e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Number of stator slots. W . . . . . . . . . . . . . . . . . . . Number of turns in series per phase. α . . . . . Angular position along the stator inner surface (rad). θ . . . . . . . . . . . . . Electrical angular position of the rotor (rad). e s (θ) . . . . . . . . . . . . . . . . . . . Rotor air-gap length function (m). e r (αθ) . . . . . . . . . . . . . . . Stator air-gap length function (m). i a , i b , i c . . . . . . Currents of phase a, b and c respectively (A). L a , L b , L c . . . . . . . . . Self inductance of phase a, b and c (H). L ab , L ab , L bc . . . . . . . . . . . . . . . . . . . . . Mutual inductances (H). Γ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instantaneous torque (N.m). Γ avg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Average torque (N.m). ∆Γ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Torque ripple (%). e1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Air-gap length (mm). e2 . . . . . . . . . . . . . . . . . . . . . . . . . Interpolar air-gap length (mm). β . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pole arc (degree). δ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Skewing angle (degree). k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chording factor.

Fig. 1 .

 1 Fig. 1. Cross-section of the studied SynRM.

Fig. 2 .

 2 Fig. 2. Axial view of the skewed rotor.

Fig. 3 .Fig. 4 .

 34 Fig. 3. Self-and mutual-skewed (δ = 10 • )inductances, with β = 0.5, e2 = 10mm, not chorded winding, skewed rotor.

Fig. 5 .Fig. 6 .

 56 Fig. 5. Average torque and torque ripple vs skewing angle.

Fig. 7 .

 7 Fig. 7. Average torque and torque ripple vs chording factor of the skewed (δ = 10 • ) machine.

Fig. 8 .

 8 Fig. 8. Average torque and torque ripple vs β of the skewed (δ = 10 • ) machine.

Fig. 9 .

 9 Fig. 9. Average torque and torque ripple vs interpolar gap length e2 to air-gap length e1 ratio of the skewed (δ = 10 • ) machine.

Fig. 10 .

 10 Fig. 10. Average torque and torque ripple vs β of the skewed (δ = 10 • ) machine.

Fig. 11 .

 11 Fig. 11. Photography of the prototype rotor.

Abderrezak Rezzoug (MŠ79) is Professor in Electrical Engineering at the University Henri Poincaré, Nancy, France. He is currently the Dean of the Groupe de Recherche en Electrotechnique et Electronique de Nancy, France. His main subjects of research concern electrical machines, their identification, diagnostics and control, and superconducting applications.


Thierry Lubin

Tahar Hamiti

Hubert Razik

Abderrezak Rezzoug

Comparison Between Finite-Element Analysis and Winding Function Theory for

published or not. The documents may come   L'archive ouverte pluridisciplinaire

Index Terms-Inductance coefficients, electromagnetic torque, winding function, finite element analysis.

I. INTRODUCTION

N accurate self-and mutual inductances calculation is necessary to improve the accuracy of the analysis of the Synchronous Reluctance Motor (SynRM). Because of rotor saliency and stator windings distribution, the self-and mutual inductances of a SynRM are not sinusoidal [START_REF] Chiba | Inductances of Cageless Reluctance-Synchronous Machines Having Non-sinusoidal Space Distributions[END_REF]. The electromagnetic torque produced by this machine presents a pulsating component in addition to the dc component when it's fed by sinusoidal currents [START_REF] Toliyat | Analysis and Simulation of Five-phase Synchronous Reluctance Machine Including Third Harmonic of Airgap MMF[END_REF]. The rotor position dependence of electromagnetic torque and machine inductances can be evaluated by a variety of methods including analytical method, finite element analysis [START_REF] Lee | Efficiency evaluation of synchronous reluctance motor using FEM and Preisach modeling[END_REF]- [START_REF] Vagati | Design refinement of synchronous reluctance motor through finiteelement analysis[END_REF] or winding function theory [START_REF] Tabatabei | Modeling and simulation of a salient-pole synchronous generator with dynamic eccentricity using modified winding function theory[END_REF]- [START_REF] Neti | Determination of effective air-gap length of reluctance synchronous motors from experimental data[END_REF]. Finite element method gives accurate results. However, this method is time consuming especially for the simulation of a controlled machine fed by a PWM inverter. In winding function approach, the inductances of the machine are calculated by an integral expression representing the placement of winding turns along the air-gap periphery [START_REF] Tabatabei | Modeling and simulation of a salient-pole synchronous generator with dynamic eccentricity using modified winding function theory[END_REF].

This paper compares finite element method and winding function method in terms of precision and computation time for electromagnetic torque and inductances calculation for a SynRM.

Manuscript received February 7, 2006. Authors are with the Groupe de Recherche en Electrotechnique et Electronique de Nancy, GREEN-CNRS UMR -7037, Université Henri Poincaré, BP 239, 54506 Vandoeuvre-lès-Nancy Cedex, France (phone : 33 3 83 68 41 27 ; e-mail: thierry.lubin@green.uhp-nancy.fr).

II. WINDING FUNCTION ANALYSIS

A. Description of the machine

The cross-section of the stator and the rotor structure of the studied SynRM is shown in Fig. 1. The rotor presents a simple and robust structure without damper bars. The stator is the same as an induction motor and has single layer, concentric-3 phases distributed winding with 36 slots. The machine dimensions details are given in Table I.

It is assumed in winding function analysis that the iron of the rotor and stator has infinite permeability and magnetic saturation is not considered.

B. Flux density in the air gap

The flux density in the air gap due to the current flowing in phase "a" is defined to be product of the winding function Na() and the inverse air gap function e -1 ( -) [START_REF] Krause | Analysis of Electric Machinery[END_REF]:

    a a 1 0 a i α N θ α e μ ) ( B     (1)
where  is the angular position of the rotor with respect to the "a" winding reference,  is a particular position along the stator inner surface and ia is the phase "a" current.

The term Na() represents in effect the magnetomotive force distribution along the air-gap for a unit current flowing the winding. The winding function of the phase "a" for the studied SynRM is shown in Fig. 2. The winding function of the phase "b" and phase "c" are similar to that of phase "a" but are displaced by 120° and 240° (electrical degrees) respectively.

The inverse air-gap function e -1 ( -) is computed by modeling the flux paths through the air-gap regions using straight lines and circular arc segments [START_REF] Krause | Analysis of Electric Machinery[END_REF]. The flux paths due to the rotor saliency are shown in Fig. 3 and the corresponding length of the flux lines is given by:

                                         cos 2 sin sin 2 R E r (2)
The flux paths due to the stator slots are shown in Fig. 4 and the corresponding length of the flux lines is given by:

                                               2 b b h arctan 2 with 2 / R h for ) 0 h R ( R 2 e h R 0 for R 2 e E 0 1 1 0 0 s (3)
where the slot dimensions are h0 =0.9mm, h1 = 0.4 mm, b0 = 2.5 mm and b1 = 4.3 mm. The total slot depth is 13.6 mm and the value of the slot opening is  = 2.5 mm. The inverse air-gap function of the SynRM is computed by [START_REF] Vagati | Design refinement of synchronous reluctance motor through finiteelement analysis[END_REF] and is shown in. Fig. 5 (for  = 0°).

 

) ( E ) ( E 1 e r s 1           (4)
Based on the previous equations, the air gap flux density distributions of radial direction obtained respectively with dand q-axis excitation are shown in Fig. 6 and Fig. 7. The flux density waveforms present higher harmonics caused by stator slots opening.

C. Calculation of stator inductances

According to the winding function theory, the general expression for mutual inductance between two windings "a" and "b" is given by the following expression [START_REF] Tabatabei | Modeling and simulation of a salient-pole synchronous generator with dynamic eccentricity using modified winding function theory[END_REF]:

           π 2 0 b a 1 0 ab dα α N α N θ α e R L μ ) ( L (5)
The self-and mutual inductances of the studied machine has been computed at different rotor positions and are shown in. Fig. 8. The ripple which is present in the inductance profile clearly exhibits the slot effects.

D. Calculation of the electromagnetic torque

The machine electromagnetic torque Tem is obtained from the magnetic co-energy Wco:

) t tan cons Is ( co em W T           (6)
In a linear magnetic system, the co-energy is equal to the stored energy:

        s t s co i L i 2 1 W   (7)
Therefore, the electromagnetic torque is:

        s t s em i L i 2 1 T            (8)
where [L()] is the inductance matrix. The precise knowledge of the inductance matrix is essential for the computation of the electromagnetic torque.

In order to achieve maximum torque per rms current, the stator windings are fed with sinusoidal currents (Irms = 3A) with an electrical current phase  of 45°. The electromagnetic torque has been computed at different rotor positions and is shown in. Fig. 9. As it appears in Fig. 9, the torque characteristic contains an important pulsating torque component mainly due to stator slots opening.

III. COMPARISON WITH FINITE ELEMENT ANALYSIS

A. Air gap flux density distribution

A 2-D finite element analysis of the SynRM has been performed using the parameters identical to that of the winding function analysis. Highly permeable linear materials were used in the structure in order to match the winding function model which considers infinite permeability. The free software FEMM was used in the simulations [START_REF] Meeker | Finite Element Method Magnetics[END_REF]. In Fig. 10 we present the d-axis field distribution obtained with the rotor d-axis aligned with the phase "a" axis and the windings excited according to ia = 1A and ib = ic = 0A. The qaxis field distribution is shown in Fig. 12. The corresponding d-and q-axis air gap radial flux density waveforms are shown in Fig. 11 and Fig. 13. Comparison with Fig. 6 and Fig. 7 indicates a good agreement with the results obtained by the winding function method.

B. Calculation of the stator inductances

The numerical calculation of the winding "a" self inductance is performed by:

A 0 i i and A 1 i with dv AJ ) ( L c b a v aa       (9)
where ia is the current flowing through the winding "a". A and J are the magnetic vector potential and current density.

The mutual inductance between winding "a" and winding "b" is evaluated by: A 0 i and A 1 i i with

) ( L ) ( L dv AJ 2 1 ) ( M c b a bb aa v ab                   (10)
The results obtained with the FE method are shown in Fig. 14. These results can be compared with those of Fig. 8 obtained by the winding function method. The significant harmonic terms of the self-and mutual inductances for the two methods are given in Table II and Table III. These comparisons indicate a good agreement between the two methods except on the dc-value of the self inductance. That is due to the stator slots flux leakages which are not taken into account in winding function analysis.

Computation of the self-and mutual inductance profile by finite element analysis at a resolution of 1° (360 points) takes around 8 hours with a 3-Ghz Pentium IV processor running on Windows XP with 512 MB RAM. Using winding function analysis with C language programming, the same PC computes all the inductance profiles and the electromagnetic torque with a resolution of 1/10° within 1 minute.

C. Calculation of the electromagnetic torque

The electromagnetic torque Tem is calculated by integrating the Maxwell stress tensor along a closed contour of radius R situated in the air gap. The mesh was constructed to keep the number of nodes as low as possible so as to reduce computational time. However, enough elements were used in the air gap to properly compute the electromagnetic torque by the Maxwell stress tensor [START_REF] Meeker | Finite Element Method Magnetics[END_REF]. For two-dimensional electromagnetic fields models, the torque is given by: The electromagnetic torque has been computed at different rotor positions and is shown in. Fig. 15. The machine exhibits important torque ripple mainly due to slot effect. The result is close enough to those found by the winding function method (Fig. 9). The torque calculation requires about 4 hours of simulation time (360 points) whereas less than 1 minute is required with the winding function method.

           d B B L R T

IV. CONCLUSION

Two methods for inductances and electromagnetic torque calculation were compared in terms of precision and computer times. It has been shown that the two methods give similar values of inductances and electromagnetic torque. However, it was clearly shown in this work that the winding function method offers considerable simplicity and lower computational costs. With this approach, parameters sensitivity analysis and the impact on the machine design can be evaluated rapidly (under magnetic linear condition). Winding function method can also be used for motor drive simulations.



  Abstract-This paper compares the prediction of two independent methods for calculating electromagnetic torque and inductances of a Synchronous Reluctance Machine under linear condition. One method is based on Winding Function Analysis (WFA) and the other on Finite Element Analysis (FEA). The rotor geometry, the stator slot effects and the stator winding connections are taking into account. The simulation results obtained by the WFA are compared with the ones obtained by two-dimensional FEA. It is shown that the two methods give approximately the same results but require different computation time.

Fig. 1 .

 1 Fig. 1. Cross-section of the studied SynRM.

Fig. 4 . 2 eFig. 3 .Fig. 2 .Fig. 5 .

 42325 Fig. 4. Flux lines distribution due to the stator slot.

Fig. 6 .Fig. 7 .-Fig. 8 .Fig. 9 .

 6789 Fig. 6. Air gap radial flux density in d-axis with ia = 1A and ib = ic =0A.

Fig. 10 .Fig. 11 .

 1011 Fig. 10. Flux distribution in d-axis.

Fig. 12 .Fig. 13 .Fig. 14 .

 121314 Fig. 12. Flux distribution in q-axis.

  Bt are the normal and tangential components of the flux density along the contour.

BIOGRAPHIES

Hubert Razik (M'98, SM'03) received the Ph.D. degree from the Polytechnic Institute of Lorraine in Electrical Engineering, Nancy, France, in 1991. He currently works as a lecturer with the University Henri Poincaré. His fields of research include the modelling, the control and the condition monitoring of multi-phase induction motor.

Abderrezak Rezzoug (M'79) is Professor in Electrical Engineering at the University Henri Poincaré, Nancy, France. He is currently the Dean of the Groupe de Recherche en Electrotechnique et Electronique de Nancy, France. His main subjects of research concern electrical machines, their identification, diagnostics and control, and superconducting applications.


hal-00556409

Abstract-Experimental results on the magnetic saturation effects on the control of a small synchronous reluctance machine (600W) are presented in this paper. A new model of the machine, including saturation effects and cross magnetization is first developed. An approach based on total and mutual inductances is followed instead of the traditional approach via magnetizing and leakage inductances. All the electrical and mechanical parameters measurement required for the simulations are given. A rotororiented vector control of the synchronous reluctance machine is achieved with a DSP board (TMS320C31) and experimental results are presented. When the magnetic circuit is saturated, the simulation with the developed model shows a good accuracy of the results when they are compared to the experimental ones.

Index Terms-synchronous reluctance machine, saturation, vector control.

I. NOMENCLATURE usd, usq:

d-and q-axis stator voltages, isd, isq: d-and q-axis stator currents, ia, ib: d-and q-axis damper currents, Ψsd, Ψsq: d-and q-axis total stator flux linkages, Ψrd, Ψrq: d-and q-axis total rotor flux linkages, Rs, Rr:

stator and rotor resistances, Ld, Lq: d-and q-axis stator unsaturated inductances, LD, LQ: d-and q-axis rotor unsaturated inductances, Md, Mq: d-and q-axis unsaturated mutual inductances,

D d 2 d d L . L M 1 - = σ : d-axis total leakage coefficient, Q q 2 q q L . L M 1 - = σ : q-axis total leakage coefficient, r D D R L T = : d-axis rotor time constant, r Q Q R L T = :
q-axis rotor time constant, ωe: electrical speed of the rotor reference frame, p: number of pole pairs.

II. INTRODUCTION

S known, an important part of electrical machines is made of ferromagnetic materials. These materials have non-linear magnetic characteristics. When the total magnetomotive force (which depends on the stator and rotor currents) in the machine increases, saturation of the ferromagnetic parts appears. The result of the saturation effects is a variation of the stator and rotor inductances. These parameters are used in the mathematical model of the machine and particularly in the electromechanical torque expressions. As a consequence, the control of the machine is drastically affected in terms of precision and dynamics.

A lot of researchers have studied the effects of magnetic saturation for a long time and have integrated it into the mathematical models of the electrical machines [START_REF] Vas | Generalized transient analysis of saturated a-c machines[END_REF]- [START_REF] Vagati | High-performance control of synchronous reluctance motors[END_REF]. The generalized analytical treatments of the main flux saturation in the orthogonal axis models of smooth air-gap ac machines have first been developed in [START_REF] Vas | Generalized transient analysis of saturated a-c machines[END_REF]- [START_REF] Boldea | Unitary treatment of core losses and saturation in the orthogonal-axis model of electric machines[END_REF]. The influences of the saturation on the leakage inductances values have been investigated in [START_REF] Lipo | Modeling and simulation of induction motors with saturable leakage reactances[END_REF]. Several authors have studied the consequence of saturation on the transient responses of a fieldoriented controlled induction machine [START_REF] Lorenz | Saturation effects in field-oriented induction machines[END_REF]- [START_REF] Lemaire-Semail | Modelling of vector controlled cage induction motor with FEM[END_REF]. For the synchronous reluctance machine (SynRM), different models have been proposed to take into account the effects of the magnetic saturation. The study developed in [START_REF] Harley | Comparative study of saturation methods in synchronous machine models[END_REF] have suggested a model using d and q saturation factors, which are a function of the flux in their respective axes. However, experimental results have shown the importance of the cross magnetizing effect in saturated synchronous machines [START_REF] El-Serafy | Experimental study of the saturation and the cross magnetizing phenomenon in saturated synchronous machines[END_REF] and the necessity to include this phenomenon in the mathematical representation of the synchronous reluctance machines [START_REF] Levi | State-space d-q axis models of saturated salient pole synchronous machines[END_REF]- [START_REF] Vagati | Impact of cross saturation in synchronous reluctance motor of the transverselaminated type[END_REF]. The impacts of saturation on the performance of vector controls of synchronous reluctance motors are shown in [START_REF] Xu | Vector control of a synchronous reluctance motor including saturation and iron loss[END_REF]- [START_REF] Vagati | High-performance control of synchronous reluctance motors[END_REF] and in [START_REF] Tounzi | Vector control of a smooth stator reluctance machine taking into account saturation and damping effects[END_REF].

In this paper, experimental results of magnetic saturation effects on the control of a small synchronous reluctance machine (600W) are presented. A new saturated model of the machine including only measurable parameters and using a single saturation factor is first developed. An approach based on total and mutual inductances follows in place of the traditional approach with magnetizing and leakage inductances. Electrical and mechanical parameters measurement required for the simulation are given. Using a DSP board (TMS320C31), a rotor-oriented vector control is achieved. Experiments are carried out for transient operations Magnetic saturation effects on the control of a synchronous reluctance machine Thierry Lubin, Hubert Razik, Member, IEEE, and Abderrezak Rezzoug, Member, IEEE A and are compared with the simulation in the case of both unsaturated and saturated conditions. The simulation show the importance of using a saturated model to obtain a good agreement of results when they are compared to the experimental ones.

III. MODELING

The cross section of the stator and rotor structure of the studied synchronous reluctance machine is shown in Fig. 1. The stator is made with symmetrical three phase windings and the rotor contains a squirrel cage. For the modeling, magnetic hysteresis, the skin effect (in the rotor bars) and iron losses are neglected. The air-gap magnetomotive forces are assumed to be sinusoidally distributed. The two-axis representation of the electrical equivalent machine is given in Fig. 2.

The voltage equations of the two-axis representation written in the rotor reference frame are:

sq e sd sd s sd . dt d i . R u Ψ ω - Ψ + = (1) sd e sq sq s sq . dt d i . R u Ψ ω + Ψ + = (2) dt d i . R 0 rd a r Ψ + = (3)
dt d i . R 0 rq b r Ψ + = (4)
The stator and rotor flux linkage in equations ( 1) to ( 4) are related to the currents as follows:

a d sd d sd i . M i . L + = Ψ (5) b q sq q sq i . M i . L + = Ψ (6) sd d a D rd i . M i . L + = Ψ (7) sq q b Q rq i . M i . L + = Ψ (8)
Fig. 1 Cross section of the studied machine. Introducing magnetizing currents Imd and Imq in the two axis, stator flux linkages become:

d m d sd I . L = Ψ with a d d sd d m i L M i I ⋅ + = (9) q m q sq I . L = Ψ with b q q sq q m i L M i I ⋅ + = (10)
Usually, total inductances are split up into a leakage and a magnetizing component. Magnetizing inductance changes with the saturation level and the leakage one are supposed to remain constant. We don't make this distinction in this paper for several reasons. Firstly, we want to obtain a saturated model with only measurable parameters and we know that it is difficult to obtain stator and rotor leakage inductances separately by tests. Secondly, the hypothesis of constant leakage inductances with saturation is very disputable in ac machine as it is shown experimentally in [START_REF] Boldea | Leakage reactance saturation in induction motors[END_REF].

A single factor saturation is used here to take into account the effects of magnetic saturation [START_REF] Pierrat | Models unification for the saturated synchronous machines[END_REF]. This saturation factor is a function of an equivalent magnetizing current obtained by converting an anisotropic machine into an equivalent isotropic one. This method has been applied in the case of main flux path saturation [START_REF] Levi | State-space d-q axis models of saturated salient pole synchronous machines[END_REF][START_REF] Tahan | A two-factor saturation model for synchronous machine with multiple rotor circuit[END_REF]. For the model that we develop, equivalent magnetizing current Im is defined as follows where k is the saliency factor.

2 q m 2 2 d m m I . k I I + = ( 11
) d q L L k = (12)
It is assumed that the d-axis and the q-axis inductances (total and mutual inductances) saturate to the same level under all operating conditions. The saturation factor Ks is defined by the ratio between saturated inductance and the unsaturated one.

      ⋅ σ - σ - ⋅ σ - ⋅ = sq q q q m q m s rq i 1 I 1 1 I K I (17)
Currents Ird and Irq defined in equations ( 16) and ( 17) are an image of the saturated rotor flux linkage and will be used next in this paper as state space variables.

Saturation factor variation can easily be measured from the no-load test or the d-c test at standstill [START_REF] Kaminosono | New measurement of synchronous machine quantities[END_REF]. The results obtained for the machine studied in this paper are shown in Fig. 3. As shown in [START_REF] Widger | Representation of magnetisation curves over extensive range by rational fraction approximations[END_REF], a close estimate for the saturation factor is obtained by using a rational fraction [START_REF] Kaminosono | New measurement of synchronous machine quantities[END_REF]. The values of coefficients are given in the appendix.

()

4 m 3 m 2 m m 4 m 3 m 2 m m m s I . h I . g I . f I . e 1 I . d I . c I . b I . a 1 I K + + + + + + + + = (18)
The new model of the saturated synchronous reluctance machine is given below. The choice of Ψsd, Ψsq, Ird and Irq as state-space variables allows to obtain a model where the first derivative of Ks(Im) is not necessary and where parameters are all measurable thanks to classical tests. The unsaturated model is easily obtained with Ks = 1 ( )

sd rd d s d s sq e sd d d s s sd u I . K 1 . R L . . K R dt d + ⋅ σ σ - + Ψ ⋅ ω + Ψ ⋅ σ - = Ψ (19)
( )

sq rq q s q s sq q q s s sd e sq u I . K 1 . R L . . K R dt d + ⋅ σ σ - + Ψ ⋅ σ - Ψ ⋅ ω - = Ψ ( 20
) rd D d s sd D d d s rd I T . . K 1 T . L . . K 1 dt dI ⋅ σ - Ψ ⋅ σ = ( 21
) rq Q q s sq Q q q s rq I T . . K 1 T . L . . K 1 dt dI ⋅ σ - Ψ ⋅ σ = (22)
All the parameters which appear in equations ( 19) to ( 22) have been measured under unsaturated conditions [START_REF] Lubin | Modeling and identification of a synchronous reluctance machine with a squirrel cage[END_REF] and are summarized in Table I. The equation of motion and the expression of the electromechanical torque are written as:

r em T T f dt d J - = Ω ⋅ + Ω ⋅ (23) ( ) sd sq sq sd em i . i . . p T Ψ - Ψ = ( 24
)
where J is the moment of inertia, f the friction coefficient and Tr the load torque. The values of J and f are given in the appendix.

IV. CONTROL

A functional block diagram of the synchronous reluctance machine vector control is given in Fig. 4. The SynRM is fed by a voltage-source PWM inverter. The control is achieved with a DSP board (TMS320C31). The constant d-axis current strategy is used [START_REF] Betz | control of synchronous reluctance machines[END_REF]. Conventional PI controllers (25) are used for current loops (d-axis and q-axis current controllers) with a sample time of 200µs.

1 id pd d z 1 K K ) z ( C - - + = and 1 iq pq q z 1 K K ) z ( C - - + = (25)
The results of the calculation of the PI controllers gains are given in Table II. These controllers allow to obtain good dynamic performances for current loops (a response time of 3ms in both d-axis and q-axis current loops). For the speed loop, an IP controller with an integrator antiwindup is used. IP algorithm is executed to generate the needed Isqref current reference. The simulation algorithm is written in C language and we use a standard fourth-order Runge-Kutta integration routine.

A. Test under unsaturated conditions

A first experimental test has been made under unsaturated conditions. Low values of Isd (Isdref = 1.5A) and Isq have been chosen (a small range of change in speed reference allows to obtain a low value for Isq). Simulation tests have been made with both the saturated model by using Ks(Im) defined in equation ( 18) and the unsaturated one (by using Ks=1) and the same results have been obtained (Fig. 6 and Fig. 6b). Other simulation results have been obtained by using the unsaturated model with the value of the saturation factor that corresponds to the rated operating conditions (Ks=0.6).

The results of the experimental test for the q-axis current, the speed and the phase current are shown in Fig. 5 and Fig. 5b. We observe a good accuracy between the experimental and the simulation results (with Ks(Im) or Ks=1). The speed, the q-axis current and phase current waveforms are almost the same in shape as predicted by simulation studies. The conclusion of this test is that under unsaturated conditions, both the classical model (Ks=1) and the saturated model of the synchronous reluctance machine are adequate to predict the dynamic responses (speed and q-axis current) of the control with a high precision.

B. Test under saturated conditions

The second experimental test has been made under saturated conditions. The value of Isd has been fixed to 2.5A and the value of Isq is high (a large range of change in speed reference allows to obtain a high value for Isq). The results of the experimental test and of the simulation one for the d-axis current, the q-axis current, the speed and the phase current are given in Fig. 7 and Fig. 7b and in Fig. 8 and Fig. 8b . We can observe important differences between experimental and simulation results when the unsaturated model is used (Ks=1). The essential main difference between the test and simulated waveforms is a longer time of the transient for the speed in the experimental results. This difference can be explained as the impact of the magnetic saturation on the torque value during the transient. Considering that damper winding currents ia and ib are equal to zero after a fast transient, the electromagnetic torque can be written as follows in (26). The value of Ks is estimated near to 0.48 (see Fig. 3) for this test and explains the differences.

() (

)

sq sd q d m s em I . I . L L . I K T - = (26)
As one can observe in Fig. 8 and in Fig. 8b, the use of the saturated model in the simulation gives a much better agreement of computed results with the experimental ones and justifies the model of the synchronous reluctance machine developed in the first part.

V. SENSITIVITY ANALYSIS

In order to show the influence of the saturation factor on simulation results, we are going to take the previous study with saturated conditions (Isdref = 2.5A) while modifying the value of the saturation factor slightly. To do that, we use two new saturation factors Ks1(Im) and Ks2(Im) defined below: The variations of these saturation factors with the equivalent magnetizing current are given in Fig. 9. We can observe that the new saturation factors allow to obtain a variation of the saturation curve around the one defined in the first part of this paper.

The simulation results obtained by using the saturated model with different saturation factors are displayed in Fig. 10. This test is made under saturated conditions with Isdref = 2.5A. One can observe that the transient responses on the speed and on the q axis current are close to each other and almost follow the uncertainty on the saturation factor .

Fig. 2

 2 Fig. 2 Two-axis model in the rotor reference frame.

  saturation factor defined above, we obtain the expressions of the saturated stator and rotor flux linkage (including cross magnetizing).

Fig. 3

 3 Fig. 3 Saturation factor of the studied machine.

Fig. 4

 4 Fig. 4 Block diagram of the experimental system.

Fig. 5

 5 Fig. 5 Experimental results under unsaturated conditions.

Fig. 6

 6 Fig. 6 Simulation results under unsaturated conditions: (1) saturated model and unsaturated model with Ks=1, (2) unsaturated model with Ks=0.6.

Fig. 5b

 5b Fig. 5b Experimental results under unsaturated conditions.

Fig. 7

 7 Fig. 7 Experimental results under saturated conditions.

Fig. 6b

 6b Fig. 6b Simulation results under unsaturated conditions: (1) saturated model and unsaturated model with Ks=1, (2) unsaturated model with Ks=0.6.

Fig. 8

 8 Fig. 8 Simulation results under saturated conditions: (1) unsaturated model with Ks=1, (2) saturated model, (3) unsaturated model with Ks=0.6.

Fig. 7b

 7b Fig. 7b Experimental results under saturated conditions.

  Fig. 8b Simulation results under saturated conditions: (1) unsaturated model with Ks=1, (2) saturated model, (3) unsaturated model with Ks=0.6.

Fig. 9

 9 Fig. 9 Saturation Factors: (1) Ks=1, (2) Ks(Im), (3) Ks2(Im), (4) Ks1(Im).

Fig. 10

 10 Fig. 10 Simulation results under saturated conditions: (1) unsaturated model with Ks=1, (2) saturated model with Ks(Im), (3) saturated model with Ks2(Im), (4) saturated model with Ks1(Im),

Poincaré, Nancy, France. As the head of the Groupe de Recherche en Electrotechnique et Electronique de Nancy, his main subjects of research concern electrical machines, their identification, diagnostis and control, and superconducting applications. He is a member of IEEE.

BIOGRAPHIES