Laurent-Frédéric Ducreux

Claire Guyon-Gardeux

Franc ¸ois Maxime Louvel

Pacull

Raby Safietou

Maria Isabel Thior

Vergara-Gallego

Rapid prototyping of complete systems, the case study of a smart parking

Keywords: Coordination, Prototyping, User interface

This paper details how LINC a coordination middleware, can fasten the development of prototypes that integrate several equipment. A case study of rapid prototyping is presented. It illustrates how a smart parking prototype has been built from several independent and autonomous equipment, coming from different vendors. This has been achieved by parallel development thanks to the resource based approach offered by LINC. This paper also describes how LINC helps building rich user interfaces quickly and easily.

I. INTRODUCTION

Embedded systems have been part of our daily life for decades. Most of the industrial or consumer products embed multiple processors, sensors and actuators. The next step is the opportunity to build new products, systems, and usages, combining together several of these products. In such innovative and quickly evolving context it is necessary to build prototypes to test, validate, and challenge new products usages or solutions. This paper considers prototypes including several equipment, possibly from different vendors. Such prototypes can be used to exhibit demonstrations in a trade fair, to convince investors of the viability of an idea or to verify the adequacy of the solutions for early adopters.

To succeed in today's highly competitive market, a prototype should be more than a few items wired together with a command line interface. Targeted prototypes are real-life demonstrations of new products or technologies with a high end-user experience. Moreover, a prototype should be included in its targeted environment (e.g. a house, a building or a parking). The development of prototypes is vital during the validation stage of new products as they may help to:

1) Reduce the time to market: by testing and validating product functionality; 2) Improve and extend functionality: by opening the way to new scenarios and usages of the product; 3) Create alliances: by integrating products coming from different vendors; 4) Validate segments of clients: by pruning or expending in a early stage the set of segments of clients.

Time and cost being critical, adequate tools are required to fasten prototypes development. Such tools must help to develop in parallel several parts of the prototype and ease their integration in the last stage. They must also be flexible enough to allow up to last minute changes. For instance, when replacing a piece of hardware by another (e.g. cheaper, more powerful or with better availability). Changes in the user interface should also be facilitated to better take into account feedback of early adopters. In addition, tools must simplify the simulation of the equipment still under development. Indeed, very often there is a co-design and co-development of a set of devices and the global application that integrates all of them. Simulating these devices at little cost reduces the length of the critical path. Finally, fast development of rich user interfaces are also needed because they leverage opportunities offered by the prototype and allow to consider several alternatives.

In this paper, we show how we can use LINC [START_REF] Louvel | Linc: A compact yet powerful coordination environment[END_REF] to answer these challenges. LINC is a resource-based middleware which integrates a rule engine. The resource approach provides an abstraction layer to ease the integration of heterogeneous components. The rule engine provides a coordination layer that permits defining interactions between components, through the use of coordination rules.

We illustrate the ability of LINC to deal with rapid prototyping through the case study of a "smart parking". The challenge was twofold: first, the time frame of 3 months to put everything in place and, second, the fact that some of the equipment were themselves prototypes still under development. Several scenarios demonstrating different usages of the smart parking have been put in place: for (i) the car driver, (ii) the people in charge of parking monitoring and control, and (iii) the parking administrator for charging station and parking slot usage optimisation. This paper is organised as follows. First, section II presents an overview of LINC. Then, section III presents the intrinsic properties of LINC that address the challenges of rapid prototyping. Section IV describes the case study, the components and equipment to be integrated, and the scenarios put in place. Then, section V details the implementation of the prototype and section VI describes how user interfaces have been built. Section VII presents related work on rapid prototyping. Finally, section VIII concludes the paper.

II. OVERVIEW OF LINC

LINC is described in detail in [START_REF] Louvel | Linc: A compact yet powerful coordination environment[END_REF], however this section recalls some information to make the paper self contained. LINC provides a uniform abstraction layer to encapsulate software and hardware components. This abstraction layer relies on the associative memory paradigm implemented as a distributed set of bags containing resources (tuples). Inspired by Linda [START_REF] Carriero | Linda in context[END_REF], bags are accessed only through three operations:

• rd(): takes a partially instantiated tuple as input parameter and returns from the bag a stream of fully instantiated tuples matching the given input pattern; • put(): takes a fully instantiated tuple as input parameter and inserts it in the bag;

• get(): takes a fully instantiated tuple as input parameter, verifies if a matching resource exists in the bag and consumes it in an atomic way.

Bags are grouped within objects according to application logic. For instance, all the bags used to manage a set of devices of the same type or technology are grouped in an object.

A. Coordination rules

The three operations rd(), get() and put() are used within production rules [START_REF] Cooper | Rule-based Programming with OPS5[END_REF]. A production rule is composed of a precondition phase and a performance phase.

Precondition phase: The precondition phase is a sequence of rd() operations which detect or wait for the presence of resources in several given bags. The resources are, for instance, values from sensors, external events, or results of service calls. In the precondition phase:

• the output fields of a rd() operation can be used to define input fields of subsequent rd() operations; • a rd() is blocked until at least one resource corresponding to the input pattern is available.

Performance phase: The performance phase of a LINC rule combines the three rd(), get() and put() operations to respectively verify that some resources (e.g. the one(s) found in the precondition phase) are present, consume some resources, and insert new resources.

In this phase, the operations are embedded in one or multiple distributed transactions [START_REF] Bernstein | Concurrency control and recovery in database systems[END_REF], executed in sequence. Each transaction contains a set of operations that are performed in an atomic manner. Hence, we can guarantee that actions belonging to the same transaction, are either all executed or none. This ensures properties such as:

• Some conditions responsible for firing the rule (precondition) are still valid at the time of the performance phase completion; • All the involved bags are effectively accessible. For instance, for a bag encapsulating a remote service we can determine if such service can be actually accessed.

These properties ensure that the set of required objects, bags, and resources, are actually available "at the same time".

B. Bag abstraction

The bag abstraction maps software and hardware components: database: A possible encapsulation is to associate a bag to each table of the database. These bags can be automatically generated from the database meta-data. The rd() and put() operations correspond to the read and write on the database. The rd() operations in the precondition part develops an inference tree, like a SQL request.

remote service: To encapsulate a remote service, partially instantiated tuples are passed to a rd() with input parameters (e.g.: ("4511 45.96", "542 35.81", town) to get the town associated to GPS coordinates). The remote service is queried within the proprietary format and communication protocol. The result is combined with the input parameters to define a fully instantiated tuple (i.e. ("4511 45.96", "542 35.81", "Grenoble")) which is returned by the rd() operation.

event system: An event can be represented as a tuple with the following fields (id, topic, timestamp, payload). To encapsulate an event system, rd() and put() are mapped to publish and subscribe operations on the system.

sensor: To encapsulate sensors, three bags can be used: Sensors to store (id, value), Type to associate sensor type to its id (i.e. (id, type)) and Location to manage the location (i.e. (id, location)). The first two bags are usually filled by the sensor network gateway driver and the last one is managed at the application layer when the binding is done.

actuator: To operate on an actuator, a resource is put in the bag associated to it. The resource contains the id of the actuator, the command to apply and possible parameters. When the resource is added, the command is sent to the actuator through the driver encapsulating the protocol.

user interface: User interfaces follow a Model-View-Controller [START_REF] Krasner | A description of the model-viewcontroller user interface paradigm in the smalltalk-80 system[END_REF] approach implemented above the bag paradigm. Inputs or gestures from users are inserted in the bag MVCControl to indicate to the system what has been done on graphical elements (e.g. clicked, mouse over). This information is used to trigger further actions on the whole system. In return, feedback is given as modifications to be applied to the graphical elements. This is done through resources inserted in the bag MVCStatus. A resource has three fields defining a graphical element, one of its attributes, and the new value. Finally, inserting a resource in the bag MVCRefresh triggers the update of a given part of the user interface. This is described in more detail in the following section.

C. Frameworks

A framework is a group of objects targeting a domain. For instance, the PUTUTU [START_REF] Pacull | Self-organisation for building automation systems: Middleware linc as an integration tool[END_REF] framework integrates more than 20 technologies for sensor/actuator networks. A framework offers ready to use objects and/or template objects to speed up development. We have defined several frameworks dedicated to UI, user notifications (e-mail, SMS), voice recognition and synthesis, light management, and so on.

D. Tools

LINC offers tools to help development and debugging. Firstly, a web based monitor allows to remotely introspect and modify the content of the bags. An analysis tool is provided to observe the rules execution, the amount of resources read, added or removed in bags. Finally, it is possible to restart an application by forcing the rules to be re-executed in the same order than a previous execution. This is useful for debugging purposes, as described in section III-E.

III. LINC AND RAPID PROTOTYPING A LINC application can be decomposed into three layers:

• the external and legacy world encapsulated as bags;

• the user interface, through web browser based interaction following a Model-View-Controller approach; • the application logic, where the application state is kept as resources in the bags, and the state transitions are driven by coordination rules bridging the external world and the users.

LINC provides loose coupling through the resource/bag based approach. This is particularly useful for rapid prototyping as now explained.

A. Parallel development

The bag abstraction provides decoupling in both time and space between the producer and the consumer. Hence to develop several parts in parallel, it is only required to define the resources that will be produced and consumed. This is true for hardware (e.g. sensors or actuators) encapsulated within the bag abstraction. But this is also true at the interface level (e.g. what graphical element have been clicked) and at the application level (e.g. events or state of a process). Indeed, one team can develop the graphical interface, while another can write the code to encapsulate a sensor or an existing product, and another can work on the application logic. The teams only have to agree on the data format that will be exchanged.

B. Simulation

With the resource approach, it is very easy to simulate other parts of the system. Indeed the resources of interest simply need to be added in a bag. This can be done manually or via a coordination rule. This allows to validate the system even if every single part or device is still under design. This is critical for rapid prototyping, where part of the components can be available or stable only in the last stage of the development.

C. Re-usability

The resource approach, coupled with the coordination rules, also increases re-usability which is vital for rapid prototyping. In fact, the decoupling between the modelling (using resources) and the usage (through rules) permits the design of objects that do not depend on the way they are used. This facilitates the reuse of objects in different applications/contexts. For instance, the ModBus object, from the PUTUTU framework, has been reused in 3 demonstrators from different domains: home automation, lift energy management, and smart parking.

D. User Interfaces

LINC provides four types of objects that can be combined to define very flexible and dynamic interfaces.

The first one, Layout defines the global interface as a set of frames. Frames may overlap and accept transparency effects. The association of the frame and its content (URL) is stored in a bag. Thus, it is possible to dynamically change an interface: frames can be moved and their content changed.

The second object MVC (Model-View-Controller) is used, on the one hand, to capture the interactions from the users and, on the other hand, to reflect the current state of the application. This state is the result of the rules execution regardless to what are the causes: user interactions, sensors detection, results of a complex algorithm, events, etc.

The third object Chart is used to directly render as charts information contained in bags. Once the bag name, the type of chart, and the different parameters inherent to the type of chart are known, the object returns a web page containing a chart (in SVG) corresponding to the resources contained in the bag. This allows to manage both a static chart from data collected in the past or a dynamic chart following the changes of one or several values. We consider not only the classical charts (such as plots, histograms, and pies) but also gauges and progression bars when a single value is followed.

Finally, the last object dynamicSVG is used to animate 2D SVG graphical objects into a SVG scene, composed of three main bags. The Sprite bag manages the graphical representation of a sprite. The Location bag manages the place of the sprite within the global scene. The Animation bag associates a sprite, a path to follow, a duration and a type of movement (accelerate, slow down, . . . ). Collisions with other graphical objects are detected and can be used to trigger further actions through rules.

Thus, an elaborated user interface is constructed with one Layout object, and possibly objects of type MVC, Chart and dynamicSVG associated to the frames. In addition, any other HTML element coming from an external source may be included in a frame. It is possible to refresh the frames independently according to what is really required. This decreases the network traffic and the CPU usage of the host running the browser. This allows to target very small devices (e.g. a kindle paper-white from amazon is a perfect device for home automation remote user interface).

As the status is not contained in the user interface but at the objects level, the same data can be used for different interfaces and/or for different sessions of the same interface on different devices. These sessions can be synchronised or not depending on the need. Indeed, triggering the refresh of a browser session is as simple as inserting the appropriate resources in the MVCRefresh bag. This is used when collaboration/sharing among geographically distributed users is required by the application. Another usage, is to propose the user to choose among several alternative representation of a same interface.

The development of an interface may be dispatched to several people with different expertise. The purely graphic part can be done by a designer using standard tools such as Adobe Illustrator or Inkscape without any knowledge of LINC. The result is plain SVG drawing. The instrumentation of this SVG is done by another person for which the knowledge required about LINC is just the generic API needed to insert a resource in a bag when an action on a graphical entity is done. This can be very easily done in an SVG editor such as Inkscape. Chart type interfaces are directly integrated without any code to write. dynamicSVG requires more knowledge of LINC since the animations are coded as a set of LINC rules defining how the sprites move according to contextual conditions.

E. Tools

The tools complete the environment by providing facilities to remove or add resources when the application is running. This allows debugging or verification of sub part of the application without needing to restart everything. The rule analysis tools allow to spot very easily rules that can be optimised. Finally, the controlled re-execution of an application forces a non-deterministic application to behave in the same way as a previous crashed execution. Debugging is easier because otherwise one would have to replay the application several times hoping to recreate the crash condition.

IV. CASE STUDY DESCRIPTION

The case study consists of a "smart parking" that has been developed in the context of the IRT Nanoelec [START_REF] Project | [END_REF] within the PULSE program. This is a french initiative, whose role is to accelerate collaboration between industry and academia. The "smart parking" prototype has been inaugurated during an event called "day of the sustainable mobility" organised at CEA premises in Grenoble.

The target was to develop a prototype integrating products provided by several industrial partners, such as Bouygues and Schneider electric, and off-the-shelve products. The equipment from partners consist of their last prototypes still under development and improvement.

A. Smart parking description 1) Parking spot solution: (prototype): This is a solution promoted by Bouygues, composed of autonomous car sensors. Sensors are embedded in each parking spot and data is aggregated by a gateway called TOTEM. The gateway may be queried via FTP.

2) Charging stations: (prototype): These stations are used to charge electrical vehicles, they are manufactured by Schneider Electric. The charging stations are composed of an RFID reader: for users authentication and two plugs working independently. A station works autonomously, so that it manages the user authentication procedure, as well as the full process to charge a vehicle. Through a ModBusTCP [START_REF]ModBus Application Protocol Specification[END_REF] connection, it is possible to retrieve information such as the current state of the station (e.g a car is plugged, a car is charging, or a user has been identified) and the RFID values detected by the station. It is also possible to send remote commands, to reboot the station, for example.

3) Off-the-shelve products: : These equipment have been added to extend the scenarios with enhanced user experience: Figure 1 shows a picture of the parking. The blue circle highlights the sensors gateway (or TOTEM), the green circle highlights a charging station, and the red circle highlights one of the sensors embedded in a parking spot.

The prototype contains 3 charging stations with 2 plugs each, 5 instrumented parking spots (sensors and light columns), and 3 Video Cameras.

B. Scenarios

Three scenarios have been defined to target respectively the parking manager, the people responsible for the maintenance and the parking users. With LINC, the information are resources in bags, easily manipulated by rules to trigger actions given a specific context. Thus, from the same information (e.g. a car is charged) several actions may be taken: send an SMS to the car owner, store the information in a database, or raise an alert to the parking manager.

1) Parking maintenance scenario: This scenario focuses on the parking maintenance and administration. It allows to monitor and control all the equipment in the parking remotely, from a single interface. The interface offers a schematic view of the real parking with the current state of the equipment. This interface may be used for instance to display alerts caused by possibly faulty devices. The interface allows also to control manually some of the equipment such as lights or cameras independently from their usual behaviour.

2) Parking manager scenario: The parking manager is interested by statistics on parking spots and charging stations usage. The scenario provides an interface presenting the analysis of the usage of the charging stations and the parking spots. In this case, all the information from the equipment (i.e. sensor values, events from charging stations, etc) is logged in a database. Then, when the user requests it, statistics are computed and represented. Presenting these statistics in a unified manner will bring value to the parking manager. For instance, it may show that some users park on a charging station spot even though they never charge their car. Such information could be used to warn the parking user or increase the parking price when this situation happens. Another usage could be to detect cars parked for a long time, i.e. still connected to the charging station after the charge has ended. The manager can also learn from these statistics and adopt new strategies when planning future infrastructures. For instance, it is possible to determine which type of plugs are the most used.

3) User scenario: This scenario focuses on the user of the parking. The colour of the light column beside a parking spot is used to give information about the parking spot (e.g. busy or free) and the charging station (e.g. available, connected, or charging). The colour informs the user if his/her vehicle has been correctly connected, if it is charging, or if the charge has finished. Besides, this scenario also manages the authentication of users and the accounting for the parking usage. For instance, the identity of the user can be retrieved from the RFID reader; therefore, it is possible to associate the utilisation of a station with a user and an account. In addition, the user can be informed about the state of his/her account or charge through notification mechanisms such as SMS or e-mails.

4) Software components added to implement the scenarios:

• A database containing information about users (e.g. name, phone number), parking spots and charging stations usage (e.g. duration, tariff, user); • Simulators for products not available yet. This allowed earlier integration of the products into the application in order to speed up the development process; • Notifications to users and the parking manager.

V. IMPLEMENTATION

The case study raises several challenges:

• equipment were not all available at the beginning, or not with all their functionality;

• some of the equipment have an autonomous behaviour (they have not been designed to be integrated into a bigger product/system); • high level information must be built by merging information of different equipment; • time frame: this case study has been implemented in 3 months, with interfaces, equipment and scenarios evolving up to the last week.

This section presents how LINC has been used to face these challenges. In the proposed architecture, LINC has been used both for communication and coordination.

A. Software architecture This allowed the integration of equipment still under development into scenarios before they were installed.

The database has been designed from scratch but it is now available as a ready to use framework that we already have used in another development in the field of connected health.

Most of the equipment integrated in the demonstrator are sensors and/or actuators or at least can be considered as such. We thus relied on the PUTUTU framework which already contained objects for some of the required technologies (e.g. Modbus used in the charging station, the IP based relay used for the column lights, and user notifications). For the missing parts, the templates coming with this framework reduced the development time and effort (e.g. the technology used for the car detectors has been added in a couple of days).

The coordination layer ensures, through LINC rules, the consistency of the system and implements the scenarios. The coordination rules define the core of the application, they decide which are the actions to take after the detection of an event (the presence of a resource in a bag).

B. LINC coordination rules

Several rules to implement the different scenarios were written. The rules are divided in four groups:

• 10 rules to control the equipment. They control, for example, the colour of the light columns according to the state of the associated spot and charging station; • 12 rules to manage charging cycles of the different stations ; • 9 rules to log information into the database for statistics purpose; • 10 rules to control the user interfaces. They update the user interfaces according to values from equipment and they send events generated by the user to the different components of the application. Listing 1. Rule to detect end of charge Listing 1 shows an example of a simplified rule used to coordinate the charging cycle. The bag CCState refers to the state of the charging cycle associated to a charging station (st_id) and a user identity (badge). For each plug on a charging station, a unique charging cycle (identified by cc_id) can be active at a time. The precondition first asks the bag CCState of the App (Application) object for existing charging cycles. The second line waits for the resource modelling the end of charge event of the corresponding station. Finally the third line reads the user phone number. Then the performance part (after ::) is triggered. Line 6 consumes the current state of the process (i.e. charging) and line 7 inserts the new state (i.e. charged). Then line 8 adds a resource in the SendSMS bag of the Alerts object to notify the user about the end of the charge. Finally the last line of the performance stores the end of charge event in the database (note that primary key information and time-stamp have been removed to make the rule more readable).

Regarding the application interfaces, they are developed on top of the UI Manager layer, and they rely on the coordination layer to interact with the physical equipment. The interfaces are described in the next section.

VI. USER INTERFACES

This section presents the graphical interfaces developed for the first two scenarios. The Live interface allows to monitor and control the parking in real time. The Statistics interface displays statistics about the parking usage.

A. Live interface

Figure 3 shows the live interface provided by a Layout object with three frames (highlighted by a rectangle in the figure). The main frame (provided by an MVC object) shows the actual parking and the current state of the different equipment. This frame is an SVG file where each graphical element of interest can be managed through resources inserted in the bag MVCStatus. [ " L i v e I n t " , " MVCStatus" ] . put( c , " v i s i b i l i t y " , " v i s i b l e " ) ; [ " L i v e I n t " , " MVCRefresh" ] . put( " frame1" , " r e f r e s h " ) ;

Listing 2. Rule to set car visibility attribute

Listing 2 shows the rule to show on the interface when a car is parked. The precondition consists of a rd on the bag Sensors of the parking object and a rd on the bag map of the LiveInt object. When a new resource is added in the bag Sensors, the rule reads the graphical entity associated to the spot and the performance is triggered. The performance checks that the sensor value did not change and updates the bags MVCStatus and MVCRefresh of the LiveInt object. This will automatically update the visibility attribute of the graphical entity in the live interface.

The live interface also shows further information about the parking spots, the charging stations, and the users currently using the stations. It triggers alerts to inform about abusive use of a charging station or faulty equipment. Then, the parking manager can interact with the different components. For instance, a click on a camera in the live interface opens the stream of the corresponding camera and a click on the red light of a column forces its state to red to indicate its unavailability to the parking customers.

Listing 3. Rule to force column colour

Listing 3 shows the rule to force the colour of a light column from the interface. The precondition contains one rd that triggers the performance when a resource indicating a click on a column is added. The performance consumes the resource and updates the model, here by sending the command with the correct colour to the object encapsulating the light column. Note that this change will then trigger a rule (similar to rule 2) that will update the MVCStatus and thus the interface.

These two examples of rules show how the physical world (sensors) triggers feedback to the user interface and how the user interface triggers actions on the physical world (actuators). The display part is composed of four frames. The bottom right square displays the schematic view of the parking already seen in the live interface. However, even if it contains the same graphical elements, the context allows to use them for a different purpose. The user action is the same: click on a given graphical object. Information inserted in the bag is the same; however, the context, which is different, forces the execution of a different set of rules. This simplifies the re-usability.

B. Statistics interface

If the user clicks on a plug or a parking spot statistics of the clicked element, for the selected period, are displayed. Finally the last three squares (top-left, bottom-left and topright) display several statistics such as:

• ratio of occupied/free time per spot;

• ratio charging time/parking time;

• number of charges per hour, day, week, or month (according to the selected period).

VII. RELATED WORK Several software approaches that provide rapid prototyping, targeting fast integration of heterogeneous equipment, have been proposed in the literature [START_REF] Barraquand | The omiscid 2.0 middleware: Usage and experiments in smart environments[END_REF], [START_REF] Weis | Rapid prototyping for pervasive applications[END_REF], [START_REF] Côté | Robotic software integration using marie[END_REF]. Similar to the work presented in this paper, these solutions propose the use of middlewares to facilitate the integration of new components and provide interactions between these components. However, most of these middleware solutions have been thought for a specific application domain lacking of flexibility. In addition, the encapsulation procedure being closely coupled with the application, reduces the possibility of code reuse.

Several coordination middlewares can be found in the literature, such as EgoSpace [START_REF] Julien | Egospaces: Facilitating rapid development of context-aware mobile applications[END_REF], LIME [START_REF] Murphy | Lime: A coordination model and middleware supporting mobility of hosts and agents[END_REF], TOTA [START_REF] Mamei | Programming pervasive and mobile computing applications: The tota approach[END_REF] and Reo [START_REF] Arbab | Reo: a channel-based coordination model for component composition[END_REF]. As LINC, these middlewares rely on a resource approach, making space and time decoupling easier. However, when rapid prototyping is concerned, they do not offer development tools, ready to use frameworks, and user interfaces development framework.

Concerning the development of graphic interfaces, in most of the cases they are developed manually. Through the use of available tool-kits it is possible to use some predefined objects, such as buttons and menus, but most of the development is application dependent and cannot be reused. Mashups [START_REF] Lorenzo | Data integration in mashups[END_REF] are one example of approaches trying to integrate presentation components in a unique user interface. However, the lack of proper tools and models, increases complexity of Mashups requiring advanced programming skills. Yu et al. [START_REF] Yu | A framework for rapid integration of presentation components[END_REF] propose a framework for graphic interfaces based on a very simple middleware; in this case the middleware allows the interaction between existing presentation components. LINC goes further by providing a method to define lightweight user interfaces with the same paradigm as the one used for the application logic itself. Thus, development of user interface is simpler, since once the graphic design has been done, it is only required to write the appropriate rules.

VIII. CONCLUSION

This paper has presented how LINC has been used to accelerate system prototyping. The prototypes targeted in this paper are applications that integrate several equipment from different vendors, with possibly some of the equipment still under development. Such prototypes are used to validate usages, demonstrate products at a fair or convince investors.

LINC provides a loosely coupled approach and a transactional rule engine. This characteristics permit to develop in parallel the integration of the different software and hardware components, the application logic and the user interfaces. High re-usability and simulation of not available components speed up the development. The transactional rule engine allows the programmers to focus on the application design without taking into account faulty equipment. This makes application easier to develop, faster to debug and more upgradable.

A case study of smart parking prototype including several equipment (some still under development), coming from different vendors, using different protocols, has been presented. The equipment were not designed to work together or even to be integrated in a more global system, since they have their own independent embedded behaviour. This prototype has been developed in three months and demonstrated as part of a quite large event with several thousands of attendees. It is now used, on the one hand, for demonstration by the IRT Nanoelec and, on the other hand, as an open infrastructure in which other equipment can be integrated or other usages can be validated. We are currently working on the integration of a more elaborated lighting system and the validation of algorithms to adapt lighting, according to pedestrian detection. This paper has also presented how rich user interfaces can be quickly built with LINC starting with standard designer tools such as Inkscape or Adobe Illustrator. Different interfaces have been provided for maintenance, parking exploitation, and customers on top of the same application objects and data. This kind of fast development are of tremendous interest to reduce time to market, validate product during early stage, and anticipate commercial activities. Future work focuses on high level modelling and verifiable languages which can generate directly LINC rules. This will go one step further to decrease the prototype development time.

•Figure 1 .

 1 Figure 1. Picture of the parking

Figure 2 .

 2 Figure 2. Software architecture

1 [ 3 [ 7 [

 137 " App" , " CCState" ] . r d ( c c i d , s t i d , badge, " c h a r g i n g " ) & [ s t i d , " S t a t e " ] . r d( " VEHICLE CHARGED" ) & " App" , " U s e r I n f o " ] . r d( badge, phone) & : : { [ " App" , " CCState" ] . g e t ( c c i d , s t i d , badge, " c h a r g i n g " ) ; " App" , " CCState" ] . put( c c i d , s t i d , badge, " charged" ) ; [ " A l e r t s " , " SendSMS" ] . put( phone, " V e h i c l e charged" ) ; [ " DB" , " Charge" ] . put( s t i d , bagde) ; } .

Frame 3 MagnifierFigure 3 . 4 {

 334 Figure 3. Live Interface

[ 2 : : { 4 [

 24 " L i v e I n t " , " MVCControl" ] . r d ( column id , " c l i c k " , c o l o u r ) & " L i v e I n t " , " MVCControl" ] . g e t ( column id , " c l i c k " , c o l o u r ) ; [ " Column" , " command" ] . put( colum id , c o l o u r ) & 6 } .

Figure 4 .

 4 Figure 4. Statistics Interface

ACKNOWLEDGE

This Work was supported by the French national program "Programme Investissements d'Avenir IRT Nanoelec" ANR-10-AIRT-05.


Kira Seleznyova

Mark Strugatsky

Janis Kliava
email: janis.kliava@ubordeaux.fr

Modelling the magnetic dipole

Keywords: magnetic dipole, uniformly magnetised sphere, circular current loop, pair of magnetic monopoles, magnetic field lines

Three different models of a magnetic dipole, viz., a uniformly magnetised sphere, a circular current loop and a pair of fictitious magnetic charges, have been systematically analysed within the formalism based on the vector potential of the magnetic field. The expressions of the potentials and magnetic fields produced by each dipole model have been obtained. A computer code has been put forward in order to visualise magnetic field lines for different dipole models. It has been shown that the magnetic field outside the uniformly magnetised sphere coincides with that of a point dipole. The other two models give considerably different results at distances small or intermediate in comparison with the dipole size.

Introduction

In electrostatics, the primary source of the electric field is an electric charge. In contrast, in magnetostatics, insofar as 'magnetic charges' magnetic monopoles have not been found in nature, the same fundamental role of primary source of the magnetic field is played by the magnetic dipole. Therefore, adequate modelling of the magnetic dipole is of paramount importance, both in teaching and scientific research.

As far as a point dipole is only an abstract idea, in teaching magnetostatics as well as in research in the field of magnetism, it is useful to consider dipole models more realistic physical systems yielding the same magnetic field as the point dipole, at least, at distances much larger than their own size. Most often, as such a model in magnetostatics one considers a circular current loop or, by analogy with electrostatics, a pair of fictitious magnetic charges of opposite sign. Meanwhile, there is the third possibility, that to model the magnetic dipole as a uniformly magnetised three-dimensional body of a simple, e.g., spherical shape. Usually, the uniformly magnetised sphere is considered in a different context, viz., as an illustration of a boundary-value problem in magnetostatics [1, p 198 ff], or an example of application of the vector potential [2, p 236], thus overlooking the opportunity of using it as one more model of the magnetic dipole. Below we shall compare in detail all three dipole models.

Of course, the magnetic field produced by a dipole model at intermediate and shorter distances will differ from that of the point dipole; moreover, the predictions of different models can be quite different. This issue is of importance, e.g., in studying magnetic dipole dipole interactions between paramagnetic ions in solid state, in which case a comparison with experimental observations allows choosing the most adequate description of a given magnetic source.

In teaching electromagnetism, the analogy between electrostatics and magnetostatics suggests that the electric and the magnetic dipole should be introduced in an analogous manner. This can be implemented in two different ways: (i) by calculating the electric and magnetic dipole fields through the Coulomb and Biot Savart laws, respectively and (ii) by deriving them from scalar and vector potentials, respectively. The first way has been explored in detail by Bezerra et al [START_REF] Bezerra | How to introduce the magnetic dipole moment[END_REF]. We have chosen the second way, more sophisticated from the conceptual viewpoint but allowing to considerably simplify certain computations.

In one form or another, the models considered below have been described in a number of textbooks and/or research papers. Meanwhile, we have tried to present them systematically within the same formalism and comparing exact analytical expressions with Taylor expansions to higher-than-first order, providing simple expressions of potentials and fields valid not only at large but also at intermediate distances. A computer code has been put forward, allowing to visualise magnetic field lines computed using both exact expressions and Taylor expansions.

We believe that this paper will be interesting and useful to people involved in teaching both undergraduate and graduate courses as well as in research work in the field of electromagnetism.

Point dipole: an overview

According to the Biot Savart law of magnetostatics, the magnetic field B(r) produced in a point of space r x y z , , ( ) = by an arbitrary distribution of steady currents in a volume V′ is (e.g., see [1,

p 175 ff], [2, p 215 ff]): B r j r r r r r V 4 d . 1 V 0 3 ( ) ( ) ( ) | | ( ) ò m p = ¢  -¢ -¢ ¢ ¢
The same expression is obtained with the help of the relation B r A r , ( ) ( ) =   A r ( ) being the corresponding vector potential:

A r j r r r V 4 d . 2 V 0 ( ) ( ) | | ( ) ò m p = ¢ -¢ ¢ ¢
In equations (1) and (2) 0 m is the permeability of vacuum, j r ( ) ¢ is the current density in a point r

x y z , , ( ) ¢ = ¢ ¢ ¢ of the magnetic source, and the integration is performed over the whole distribution of currents. The corresponding analysis, outlined below, can be found, e.g., in Jacksons' and Landau and Lifshitz's textbooks ([1, p 184 ff], [4, p 103 ff]). Equation (2) can be expanded in powers of r 1 -(the multipole expansion):

A r j r r r P V 4 1 cos d , 3 n n V n n 0 1 0 ( ) ( ) ( ) ( ) ò å m p a = ¢ ¢ ¢ + = ¥ ¢
where P n are the Legendre polynomials and a is the angle between r and r . ¢ The first term of this development

(n 0 = ) A jr r V 4 d , 4 V m 0 ( ) ( ) ò m p = ¢ ¢ ¢
is the vector potential of the magnetic monopole, A m , and it is shown to vanish. The second term in equation (3), n 1, = the magnetic dipole term A r rjr r V 4 d , 5

V d 0 3 ( ) ( ) ( ) ò m p = ⋅ ¢ ¢ ¢
¢ can be put in the following form:

A m r 4 1 , 6 d 0 ( ) m p = -  
where m is the magnetic dipole moment:

m r jr V 1 2 d . 7 V ( ) ( ) ò = ¢ ¢ ¢ ¢
Taking the curl of A d , applying the product rule and keeping in mind that m is a fixed vector, for the magnetic field produced by a point dipole one gets:

B m r r m r r 4 3 . 8 d 0 2 5 ( ) ( ) m p = ⋅ -
According to the Curie symmetry principle [START_REF] Curie | Sur la symétrie dans les phénomènes physiques, symétrie d'un champ électrique et d'un champ magnétique[END_REF], the effects generated by a cause can have only higher and not lower symmetry than the cause itself. We put the dipole at the origin O (in subsequent sections, O will be chosen in the centre of the dipole model). As far as the dipole field is invariant with respect to rotation about its axis denoted as Oz, the use of cylindrical coordinates z , , r j and the corresponding unit vectors e e e , , z r j is the most appropriate, and all calculations can be restricted to a plane containing Oz. The position of a point in this plane can be defined either by the radius r and the polar angle J or by the distance r sin r J = and the height z r cos ; J = below we are thoroughly using the former definition. Thus, equations [START_REF] Arfken | Mathematical Methods for Physicists 7th edn[END_REF] We consider the magnetised sphere of radius R and magnetic dipole moment m M R

4 3 3 p =
where M is the magnetisation vector supposed to be uniform, as an assembly of elementary dipoles. Taking into account equation (6), the vector potential produced by such a sphere in a point of radius vector r can be calculated as a sum of contributions of all volume elements dV ¢ of radius vector r′ and dipole moment dm = MdV′:

A M r r V 4 1 d . 11 V 0 | | ( ) ò m p = -  ¢ -¢ ¢ ¢
For a uniform M, the latter expression can be rewritten as

A M r r V 4 d . 12 V 0 | | ( ) ò m p = - ¢  -¢ ¢ ¢
In accordance with a well-known theorem of vector analysis, the volume integral in this expression can be transformed to an integral over the surface S¢ of the sphere:

r M n r r S A 4 d , 13 S 0 ∮ ( ) | | ( ) m p =  -¢ ¢ ¢
where n r r = ¢ ¢ is the unit vector normal to S¢ and S R d s i n d d .

2 J J j ¢ = ¢ ¢ ¢ A comparison between equations (2) and (13) shows that the latter describes the vector potential of a surface current of density j r M n S ( ) ¢ =  . We choose the space origin in the centre of the sphere and the z axis parallel to r, r e r z = (such a choice allows simplifying the calculation, see [2, p 236 ff]). One can see from figure 1 that r R sin cos , sin sin , cos

( ) J j J j J ¢ = ¢ ¢ ¢ ¢ ¢ and r r r R rR 2 cos . 2 2 1 2 | ( ) J -¢ = + - ¢
Because of the rotational symmetry about M, without loss of generality M can be confined in the xz plane, forming an angle J with r, M M sin , 0, cos , ( )

J J = so that
M n M sin sin cos , sin cos cos cos sin , sin sin sin . 14

( ) () J j J J j J J J J j J  = - ¢ ¢ ¢ ¢ - ¢ ¢ ¢
Making these substitutions in equation (13), we remark that integrating over the range 0 2  j p ¢ < will eliminate contributions of all dependent j¢terms in equation (14). The remaining integral over J¢ yields:

z z int 0 3 ext 0 3 2 ( ) ( ) ⎡ ⎣ ⎢ ⎤ ⎦ ⎥ m p m p J J = = + - r
One can see that inside the uniformly magnetised sphere the magnetic field is uniform, as known from magnetostatics. Most interestingly, outside this sphere the magnetic field at any distance coincides with that of the point dipole, see equations ( 16) and (10).

Circular current loop

Most often, in magnetostatics one takes a circular loop of electric current (Ampérian current) as a basic model of the magnetic dipole. Let us consider a loop of radius R and area S R , 2 p = placed in the xy plane and centred at the origin, see figure 2. The loop is carrying a current I supposed to flow in counterclockwise direction as seen from above the xy plane; so, by definition, its magnetic moment is m R I.

2 p =
An element of current Idl, where dl is an elementary vector tangent to the loop in a point M, produces an elementary vector potential in an arbitrary point in space P:

A l m R MP d 4 d . 1 7 0 2 | | ( ) = m p p
Because of rotational symmetry about the z axis, without loss of generality P can be positioned in the yz plane. In polar coordinates we get dl = Rdj′e j′ . From figure 2

A e m Rk r k K k E k 4 8 1 1 2 19 0 2 2 ( ) ( ) ( ) ⎜ ⎟ ⎡ ⎣ ⎢ ⎛ ⎝ ⎞ ⎠ ⎤ ⎦ ⎥ m p p = - - j +
where K(k) and E(k) are, respectively, complete elliptic integrals of the first and second kind. From this equation we derive the cylindrical components of the magnetic field vector:

B m R r r r R E k r K k B m R r r R r E k r K k 4 2 cot , 4 2 . 2 0 z 0 2 2 2 2 2 0 2 2 2 2 2 [( ) ( ) ( )] [( ) ( ) ( )] ( ) m p p J m p p = + - = - - r + - - + - +
As one can see, in the model of a current loop, the vector potential and the magnetic field can be analytically expressed only through the elliptical integrals. In order to obtain simpler expressions valid at intermediate distances, we have applied expansions in Taylor series to the sixth order in the small parameter R r. ( )

⎜ ⎟ ⎜ ⎟ ⎛ ⎝ ⎞ ⎠ ⎛ ⎝ ⎞ ⎠ m p e

Pair of fictitious magnetic charges

The third model represents the magnetic dipole as an assembly of two fictitious magnetic monopoles, or 'magnetic charges' q  a distance d apart, see figure 3. By analogy with electrostatics, the magnetic dipole moment is defined as m qd, = so that in order to calculate the magnetic field produced by such a model, one is tempted to introduce a scalar magnetic potential, see [1, p 196 ff]. However, for the sake of consistency, we prefer using here a vector potential, and, in accordance with the superposition principle, it can be taken as a sum of the vector potentials of two magnetic monopoles of opposite signs.

The vector potential of a magnetic monopole introduced by Dirac yields a correct expression of the magnetic field expected to be produced by a magnetic monopole. However, it is not quite satisfactory from both mathematical and physical

⎛ ⎝ ⎜ ⎞ ⎠ ⎟ ⎛ ⎝ ⎜ ⎜ ⎜ ⎞ ⎠ ⎟ ⎟ ⎟ m p J m p J J = - = - - + r
Note that the latter equations can be immediately obtained from the corresponding expressions for the electric dipole by substituting the electric dipole moment and the permittivity of vacuum 0 e by the magnetic dipole moment and , 0 1 mrespectively. These expressions are simpler in comparison with those obtained for the model of a current loop. Yet, we still provide the corresponding expansions in the Taylor series, useful for a direct comparison between these two models. In the same approximation as in the previous section, redefining the small parameter as d r, e = equations (25) and (26) become, respectively: ( ) z The model sizes and the distances are scaled in relative distance units (rdu). As one can see, for the uniformly magnetised sphere of radius R, B z remains uniform at R, r < has a discontinuity at R r = and follows the corresponding dependence for the point dipole at R. r >

⎜ ⎟ ⎜ ⎟ ⎛ ⎝ ⎞ ⎠ ⎛ ⎝ ⎞ ⎠
The analogous dependence for the current loop of radius R has a singularity at R, r = and for the pair of magnetic charges B z has a minimum at 0. r = Thus, at small and intermediate distances in comparison with the model size, the behaviour of all three models is very different. At large distances, see inset in figure 4, the magnetic fields produced by different magnetic dipole models match that of the point dipole, as expected.

A still better insight in the behaviour of different models at small and intermediate distances can be achieved by visualising magnetic field lines. By definition, the elementary vector of the tangent to the field line, dL, in each point of this line is parallel to the field vector. The vector product for parallel vectors vanishes, so, for the magnetic field where ρ inf and ρ sup are, respectively, the smallest and the largest value of r for a given field line, and z

, inf sup [ ] r r Î
is a dummy variable. We have put forward a FORTRAN 77 computer code for calculating the magnetic field lines for different dipole models according to both the exact expressions and their Taylor expansions, see the appendix. Visualisation of the field lines calculated using the Taylor expansions allows to estimate contributions of various expansion terms and the general convergence of the Taylor series for different models.

In the current loop model the exact expressions of the magnetic field components, equation (20), are very complicated, so, we have chosen to compute them by numerical integration over the angle j¢ of the elementary field components expressed through the Biot Savart law, see equation (1) and figure 2:

B m R z R R z B m R R R R z
( ) ( ) ( ) ( ) ⎡ ⎣ ⎢ ⎢ ⎢ ⎢ ⎤ ⎦ ⎥ ⎥ ⎥ ⎥ J J J e J J e J J J e = -+ + - - - + - + + r
and for that of a pair of magnetic charges we get:

B B 2 3
1
⎡ ⎣ ⎢ ⎢ ⎢ ⎢ ⎤ ⎦ ⎥ ⎥ ⎥ ⎥ J J J e J J e J J Je = -- + - - - - + r 2 6 ( ) ( ) ( ) ( )
We remind the reader that in equations (31) and (32) e has different meaning. In all cases, the numerical integration over r in equation (29) has been performed using the Runge Kutta method [START_REF] Atkinson | An Introduction to Numerical Analysis 2nd edn[END_REF]. With the aid of this programme we have visualised the field lines for all models, see figure 5. The calculations have been made using the exact expressions, vide supra, and the modelling parameters have been chosen in such a way that all the field lines ostensibly merge at the maximal distance r max from the source. As one can see, at distances comparable with the model size, the appearance of the field lines predicted by each model is totally different. The lines produced by a uniformly magnetised sphere are parallel to the dipole axis inside the sphere and coincide with those of the point dipole outside the sphere. The lines due to a current loop close on themselves inside the loop while those of a pair of magnetic charges diverge from the positive charge and converge towards the negative one. In all cases, at small distances the behaviour of the field lines has nothing in common with that expected for the point dipole, in which case the field lines close on themselves in the space origin.

In certain applications, e.g. in calculating the interaction energy between magnetic moments embedded in a condensed matrix, one needs a good approximation for the magnetic field produced at intermediate distances from the magnetic source. Obviously, in such cases in the multipole expansion, see equation (3), higher-order terms (quadrupole etc) should be maintained. Figure 6 compares the magnetic field lines calculated using the exact expressions = All the lines merge at the maximal distance r 2.0 max = .

6. Magnetic field lines in the models of a current loop (a) and of a pair of magnetic charges (b) calculated using the exact expressions of the magnetic fields (continuous lines) and the Taylor expansions to the 0th, 2nd, 4th and 6th order in the corresponding small parameters. All the lines merge at the maximal distance r 2.0 max = rdu. With increasing the expansion order, in (a) each subsequent field line remains confined inside the previous one, while in (b) it passes alternately from inside to outside of the exact field line profile.

and Taylor expansions to different orders in the corresponding small parameter for the models of a circular current loop and a pair of fictitious magnetic charges. One can see that in the model of a current loop the expansion up to the 6th order in R r e = provides a good approximation for R r 3 4, max  and in the model of a pair of magnetic charges the same expansion in d r e = already for d r 3 4 max = yields a result practically indistinguishable from of the exact calculation.

Conclusions

In this work we have presented a consistent approach, based on the vector potential formalism, to the calculation of the magnetic field produced by different models of the magnetic dipole. Of course, exactly the same results could be obtained with the scalar magnetic potential. However, using the vector potential for calculating the magnetic field is more acceptable from the methodological and educational points of view. Indeed, in teaching electrostatics and magnetostatics, it is preferable to respect a certain 'symmetry', viz., to preserve 'parenting relationships' from the scalar potential to the electric field and from the vector potential to the magnetic field.

We have seen that all three models of the magnetic dipole considered in this study yield identical results at large distances. Indeed, the first terms of Taylor expansions of the magnetic field for both the models of a current loop and of a pair of magnetic charges coincide with the exact expression of the magnetic field outside the uniformly magnetised sphere. Therefore, such a sphere represents not only a perfect but also a quite physically realistic model of the point dipole.

However, starting from the second term in the Taylor series, the magnetic field in the models of a current loop and of a pair of magnetic charges totally diverge. Interestingly, for these models this divergence goes in opposite directions, so that the characteristics of the magnetic dipole models at small and intermediate distances become quite sensible to the choice of the dipole model. Our computer code allows visualising these discrepancies; besides, it gives the possibility of comparing the aspect of the magnetic field lines calculated using the exact expressions of the magnetic field and the corresponding approximate expressions obtained by expanding in Taylor series of different order.

Appendix. Computer code for visualising field lines produced by different magnetic dipole models

Figure 1 .

 1 Figure 1. Magnetic dipole modelled by a uniformly magnetised sphere.

r

  Here for brevity we are using Legendre polynomials P cos n ( ) J and associated Legendre polynomials P cos n m ( ) J shortened to P n and P , n m respectively (see [6, p 716 ff and 741 ff]).

Figure 2 .

 2 Figure 2. Magnetic dipole modelled by an Ampérian current.

Figure 3 .

 3 Figure 3. Magnetic dipole modelled by an assembly of two 'magnetic charges'.

6 .Figure 4

 64 Figure 4 compares radial dependences of B z in the equatorial plane 2 J p = for different dipole models. The calculations have been made using the exact expressions for B .z The model sizes and the distances are scaled in relative distance units (rdu). As one can see, for the uniformly magnetised sphere of radius R, B z remains uniform at R, r < has a discontinuity at R r = and follows the corresponding dependence for the point dipole at R. r >The analogous dependence for the current loop of radius R has a singularity at R, r = and for the pair of magnetic charges B z has a minimum at 0. r = Thus, at small and intermediate distances in comparison with the model size, the behaviour of all three models is very different. At large distances, see inset in figure4, the magnetic fields produced by different magnetic dipole models match that of the point dipole, as expected.A still better insight in the behaviour of different models at small and intermediate distances can be achieved by visualising magnetic field lines. By definition, the elementary vector of the tangent to the field line, dL, in each point of this line is parallel to the field vector. The vector product for parallel vectors vanishes, so, for the magnetic field lines we get L B 0 d .  = In cylindrical coordinates this reduces to z B B d d ,

  Figure 4 compares radial dependences of B z in the equatorial plane 2 J p = for different dipole models. The calculations have been made using the exact expressions for B .z The model sizes and the distances are scaled in relative distance units (rdu). As one can see, for the uniformly magnetised sphere of radius R, B z remains uniform at R, r < has a discontinuity at R r = and follows the corresponding dependence for the point dipole at R. r >The analogous dependence for the current loop of radius R has a singularity at R, r = and for the pair of magnetic charges B z has a minimum at 0. r = Thus, at small and intermediate distances in comparison with the model size, the behaviour of all three models is very different. At large distances, see inset in figure4, the magnetic fields produced by different magnetic dipole models match that of the point dipole, as expected.A still better insight in the behaviour of different models at small and intermediate distances can be achieved by visualising magnetic field lines. By definition, the elementary vector of the tangent to the field line, dL, in each point of this line is parallel to the field vector. The vector product for parallel vectors vanishes, so, for the magnetic field lines we get L B 0 d .  = In cylindrical coordinates this reduces to z B B d d , z r = r and we get the following equation for the magnetic field lines: z B y z B y z y , , d , 29 y

  The corresponding exact expressions for the model of a pair of magnetic charges have been given in the previous section, see equation (26).The Taylor expansions of the field line equation in the computer code have been obtained by expanding in the Taylor series the ratio B z over B .r For the model of a current loop this results in

Figure 4

 4 Figure 4. B , 2 z ( ) r J p = dependences for a uniformly magnetised sphere of radius R 0.3 = rdu (circles, grey online), a circular current loop of radius R 0.3 = rdu, (diamonds, blue online) and a pair of fictitious magnetic charges, d 0.3 = rdu apart, (dashed, red online) compared do that of the point dipole (continuous, green online). The inset: shows a zoom in the behaviour of B z at larger distances.

Figure 5 .

 5 Figure 5. Magnetic field lines for different dipole models scaled in rdu. The external line (red online) corresponds to a pair of magnetic charges d 0.75 = apart. The intermediate dashed (green online) and continuous (grey online) lines refer to a point dipole and uniformly magnetised sphere of radius R 0.20, = respectively. The internal line (blue online) is due to a current loop of radius R 0.40. = All the lines merge at the maximal distance r 2.0 max = .

CC

  Calculates magnetic field lines for the current loop and pair of charges models C with both exact expressions and Taylor expansions up to 6th order C ******************************************************************* IMPLICIT DOUBLE PRECISION (a h,p z) DIMENSION zp( 10001: 10001), zn( 10001: 10001) COMMON/Parametres/me, N, y ( 10001: 10001), Pi, d,nea, nT COMMON /Angulaire/Sphi(1000), pas ang, Na Pi = dacos( 1d0) C ******************************************************************* C m e = 1: Current loop; me = 2: Pair of charges C nea = 1: Exact calculation;nea = 2: Taylor expansion C n T = 0, 2, 4, 6: order of Taylor expansion C ******************************************************************* (Continued.) me = 1 nea = 1 nT = 2 C d = loop radius for me = 1 and d = charge separation for me= 2. d = 1.5d0 C y sup: maximal distance between the dipole and the observation point. y inf = 0.d0 y sup = 2.0d0 C Na: number of angles used in integrating the magnetic field over the loop Na = 90 pas ang = 0.5d0 * Pi/dble(Na) C ******************************************************************* C Preparing the integration DO i = 1, Na phi = 36d1/dble(Na) * dble(i) Sphi(i) = dsind(phi) ENDDO C ******************************************************************* C Discretising y N = 1000 dN = dble(N) pas y = (y sup y inf)/dN DO j = N, N y (j) = dble(j) * pas y ENDDO C ******************************************************************* C Calculating the field line with Runge Kutta method j = N C Choosing an initial value of z (z > 0d0) to get a smooth aspect of the field line z = 0.01d0 1 z p (j) = z zn(j) = z zp( j) = z zn( j) = z y1 = y (j) z1 = z CALL Ratio(y1, z1, a) z2 = z1 0.5d0 * pas y * a y2 = y1 0.5d0 * pas y CALL Ratio(y2, z2, b) z3 = z1 0.5d0 * pas y * b CALL Ratio(y2, z3, c) z4 = z1 pas y * c y3 = y1 pas y CALL Ratio(y3, z4, dd) z = z pas y * (a + 2d0 * b + 2d0 * c + dd)/6d0 C Continue calculating 2 I F(j. gt. 0. and. z. gt. 0d0) THEN j ******************************************************************* C Creating output file. zp and zn are the upper and lower parts of the field line. C Give an appropriate file name! OPEN(2,file = 'Cur loop d = 1.5 exact.txt') DO j = N, N WRITE (2, 3) y (j), zp(j), zn(j***************************************************************** SUBROUTINE Ratio (y, z, rat) C Implements the Runge Kutta procedure C ******************************************************************* IMPLICIT DOUBLE PRECISION (a h, p z) DIMENSION rT(0: 6) COMMON/Parametres/me, N, y ( 10001: 10001), Pi, d, nea, nT COMMON/Angulaire/Sphi(1000), pas ang, Na C ******************************************************************* IF (nea. eq. (1)) THEN C Exact calculation IF (me. eq. (1)) THEN C Current loop: integrating the magnetic field over the loop By = 0d0 Bz = 0d0 DO i = 1, Na rpm = (y ** 2 + z ** 2 2d0 * d * y * Sphi(i) + d ** 2) ** 1.5 dBy = 1d0/Pi/d * z * Sphi(i)/rpm dBz = 1d0/Pi/d * (d y * Sphi(i))/rpm By = (By + dBy * pas ang) Bz = (Bz + dBz * pas ang) ENDDO C ******************************************************************* ELSEIF (me. eq. (2)) THEN C Pair of charges rm = ((z 0.5d0 * d) ** 2 + y ** 2) ** 1.5 rp = ((z + 0.5d0 * d) ** 2 + y ** 2) ** 1.5 Bz = (z 0.5d0 * d)/rm (z + 0.5d0 * d)/rp By = y * (1d0/rm 1d0/rp) C ******************************************************************* ENDIF rat = Bz/By C ******************************************************************* ELSEIF (nea. eq. (2)) THEN C Taylor expansion z2 = z * z z4 = z2 * z2 y2 = y * y y4 = y2 * y2 r2 = y2 + z2


Ludovic Claudepierre

Rémi Douvenot

Alexandre Chabory

Christophe Morlaas
email: morlaas@recherche.enac.fr

Assessment of the Shadowing Effect Between Windturbines

Keywords: VOR, RADAR, windturbines, shadowing

At VOR or radar frequencies, the field scattered by a windturbine can illuminate nearby windturbines. This depends on the distance between the two windturbines and also on the This paper proposes an assessment of the shadowing effects between two windturbines at VOR and radar frequencies for typical distances. The interactions between the windturbines is shown to be negligible at VOR frequency while at radar frequencies, it is not the case.

I. INTRODUCTION

Due to the fast-growing of green energy, projects of windfarms are planed closer and closer to the minimum regulation distances of radio navigation devices (radar, VOR, ...). To assess the impact of this windfarms close to radio-navigation devices, modelling tools are in developments [START_REF] Vega | Impact of wind farms on radiocommunication services[END_REF]- [START_REF] Morlaas | Propagation model for estimating VOR bearing error in the presence of windturbines -hybridation of parabolic equation with physical optics[END_REF].

Generally, robust modelling methods (MoM) are used to compute the field scattered by the windturbines [START_REF] Algar | Application of asymptotic and rigorous techniques for the characterization of interferences caused by a wind turbine in its neighborhood[END_REF], [START_REF] Morlaas | Wind turbine effects on VOR system performance[END_REF]. However, assumptions must be done to save memory and computation time and different modelling methods are based on RCS computation [START_REF] Jenn | Wind turbine Radar cross section[END_REF], physical optics [START_REF] Casanova | Modeling windmill interference via hybrid parabolic equation and Equivalent Current approximation methods[END_REF], [START_REF] Morlaas | Propagation model for estimating VOR bearing error in the presence of windturbines -hybridation of parabolic equation with physical optics[END_REF] or UTD [START_REF] Algar | Application of asymptotic and rigorous techniques for the characterization of interferences caused by a wind turbine in its neighborhood[END_REF].

Besides, the following assumptions are found in literature: blades are sometimes considered metallic [START_REF] Vega | Impact of wind farms on radiocommunication services[END_REF], [START_REF] Casanova | Modeling windmill interference via hybrid parabolic equation and Equivalent Current approximation methods[END_REF], and interactions between windturbines are always neglected. This paper investigates the relevance of the latter.

Indeed, to lower their impact, a simple idea would be to place windturbines behind the one closest to the transmitting antenna to take advantage of the shadowing effect. Therefore, the shadowed windturbine scattering would be reduced. Nevertheless, this effect mainly depends on the distance and the frequency. Here, the necessity to account for the shadowing effect between windturbines is established to notify windenergy developer about the shadowing effect of windturbines.

In section II, the configurations of the studied problems are given. In section III, the shadowing effect for a windturbine mast at VOR frequency (114 MHz) is studied. In section IV, the same study is performed at radar frequencies (1.3 GHz and 2.7 GHz). Finally, conclusions and discussion are in section V.

II. GEOMETRIC AND ELECTROMAGNETIC CONFIGURATION

The modelled windturbine is an ENERCON-E66. The mast is a metallic cone (height = 64.17 m, top diameter = 2.18 m, bottom diameter = 4.17 m). The rotor blades diameter is 70 m. The windturbines are commonly separated of 2 to 5 rotor diameters. In this study a separation distance of 2 rotor diameters is used (140 m) to consider a worst case (the most significant shadowing effect).

Only one windturbine mast is considered located at 2000 m from the VOR station and the scattered field is calculated up to 1000 m behind the illuminated mast. Fig. 1 gives an illustration of the scenario. The terrain between the VOR station and the windturbine mast is considered flat and perfectly conductor. The incident field is computed with a parabolic equation method (PE). Physical optics (PO) is used to compute the electromagnetic scattering from the windturbine. For the sake of conciseness, the validation of PO with MLFMM is not shown in this paper and can be found in [START_REF] Morlaas | Propagation model for estimating VOR bearing error in the presence of windturbines -hybridation of parabolic equation with physical optics[END_REF] at the VOR frequency. For radar frequencies, as the object dimension with respect to wavelength is larger, the PO accuracy is improved. The scattered field is computed in a plane behind the illuminated windturbine.

III. SIMULATIONS AND RESULTS FOR VOR DEVICES

The source is a C-VOR antenna at 114 MHz in horizontal polarisation with the following parameters: a half-wavelength magnetic antenna at 0.5 m above a counterweight of 3 m diameter at 3 m above the ground.

The rotor blades are not considered due to their dielectric composition which generates a lower scattering field compared to the one of the mast for this frequency [START_REF] Morlaas | Wind turbine effects on VOR system performance[END_REF], [START_REF] Morlaas | Propagation model for estimating VOR bearing error in the presence of windturbines -hybridation of parabolic equation with physical optics[END_REF].

In Figs. 2 and3, the incident field in the absence of windturbine and the field scattered by the windturbine are displayed. The scattered field rapidly decreases behind the windturbine mast. Thus, it rapidly becomes negligible compared to the incident field. In a vertical cut at 140 m behind the mast (distance= 2140 m, the scattered field is compared with the incident field (in the absence of the mast) and with the total field (incident plus scattered field) (Fig. 4). The difference between the total field by a mast and the incident field is plotted in Fig. 5 at 140 m from the mast. The difference is lower than 2 dB and decreases for higher altitudes. Then, at two rotor distance between two windturbines, no shadowing effect can be considered for VOR system.

IV. SIMULATIONS AND RESULTS FOR RADAR DEVICES

The radiation pattern of a TRAC2000 antenna at 1.3 GHz and a STAR2000 at 2.7 GHz, both in horizontal polarisation at 20 m above the ground. Antenna tilts of 1.2 o and 2.3 o are considered, respectively.

A. Radar at 1.3 GHz

The same simulation as for the VOR device is performed for a primary radar at 1.3 GHz. In the vertical cut at 140 m behind the mast, the scattered field is compared with the incident field (in the absence of windturbine) and with the total field (incident plus scattered field) in Fig. 6. The difference between the total field and the incident field is plotted in Fig. 7 at 140 m behind the mast. The maximum difference is less than 5 dB and greater than 2 dB below the mast height (64m). Then, at two rotors distance between windturbines, the shadowing effect should be considered between successive windturbines.

B. Radar at 2.7 GHz

At 2.7 GHz, in a vertical cut at 140 m behind the mast the scattered field is compared with the incident field (in the absence of windturbine) and with the total field (incident plus scattered field) (Fig. 8). The difference between the total field and the incident field is also plotted in Fig. 9 at 140 m behind the mast. The maximum difference between the total field and the incident field is less than 7 dB and greater than 2 dB below the mast height (64m).

Then, at two rotors distance between windturbines, the shadowing effect must be considered between successive windturbines and the alignment of windturbines may be an efficient strategy to reduce the windturbines effects. Moreover, at this frequency, the rotor-blade may increase the shadowing effect and should be taken into account in further works.

V. CONCLUSION

The assessment of the shadowing effect behind a windturbine for the windturbine alignment has been addressed at VOR (114 MHz) and radar frequencies (1.3 GHz and 2.7 GHz).

For the VOR system, no significant shadowing effect is observed. Thus, windturbines alignment is not efficient to reduce their impact. Moreover, windturbine interactions can be neglected in electromagnetic simulation tools.

For radar, the difference between the incident field and the total field is around 5 dB and 6 dB for 1.3 GHz and 2.7 GHz, respectively. Hence, it could be relevant to align windturbines to reduce their impact. Besides, the windturbine interactions must be accounted in electromagnetic simulation tools.

Fig. 1 .

 1 Fig. 1. Geometry of the simulations.

Fig. 2 .Fig. 3 .

 23 Fig. 2. Incident field (dBv/m) from a VOR station at 0 m in the absence of windturbines.

Fig. 4 .Fig. 5 .

 45 Fig.[START_REF] Jenn | Wind turbine Radar cross section[END_REF]. Electrical fields (dBV/m) for the VOR device in the visualisation plane (z is the altitude). Scattered field (red), incident field (blue), and total field (green)

Fig. 6 . 3 Fig. 7 .

 637 Fig.6. Electric fields (dBV/m) in a vertical cut (z is the altitude); Scattered field (red), Incident field (blue), and total field (green) at 1.3 GHz

Fig. 8 .

 8 Fig.8. Electric fields (dBv/m) for a radar device at 2.7 GHz in a vertical cut (z is the altitude). Scattered field (red), incident field (blue), and total field (green).

Fig. 9 .

 9 Fig.9. Difference (dB) between the total field (dBv/m) and the incident field (dBv/m) in the visualisation plane (z is the altitude) at 2.7 GHz.

ACKNOWLEDGMENT

The authors wish to acknowledge the DGA/DSNA/DTI for supporting this work.