Maxime Louvel
email: maxime.louvel@cea.fr

François Pacull
email: francois.pacull@cea.fr

LINC: a compact yet powerful coordination environment

Keywords: Coordination, language, tuplespace, distributed systems

This paper presents LINC, a coordination programming environment. It is an evolution of earlier middlewares (the Coordination Language Facility (CLF) and Stitch). The aim is to provide a more flexible and expressive language correcting several of their limitations and an improved run-time environment. LINC provides a compact yet powerful coordination language and an optimised run-time which executes rules. This paper describes the intrinsic properties brought by the LINC environment and how it helps the coordination aspects in a distributed system. This paper also emphasises on the reflexivity of LINC and its usage at system level. Finally, it illustrates through several case studies, how LINC can manage a wide range of application domains.

Introduction

Today's systems are not only distributed, they are composed of other systems more or less opaque. They have to interact with real world and thus have to consider on the one hand very small embedded systems and on the other end unbounded resources sprayed in the "cloud". Some pieces of work consider that the traditional approaches based on objects and services cannot hold such complexity [START_REF] Edward | Cyber physical systems: Design challenges[END_REF]. In this context, coordination models and languages [START_REF] George | Coordination models and languages[END_REF] are essential to coordinate basic elements as well as systems of systems. The last decades have seen a lot of work in the coordination area [START_REF] Omicini | Coordination models and languages: From parallel computing to self-organisation[END_REF], starting with Linda [START_REF] Gelernter | Generative communication in linda[END_REF]. Linda firstly introduced the notion of tuple-space as the ground for coordination. In Linda, components exchange and synchronise through tuples addition and removal in a shared tuple-space. This approach allows the decoupling of processes both in space and time. Indeed to exchange data between two components, the first one simply puts a tuple in the shared tuple-space. It does not have to worry if another component is currently waiting for this information or how this information should be exchanged. The data is exchanged when another component reads the tuple. The read may come before, at the same time or after the put.

Based on Linda, a number of evolutions have been proposed. Starting in the 2000s, researchers have focused on using tuple-spaces for mobile computing [START_REF] Cabri | Mars: A programmable coordination architecture for mobile agents[END_REF][START_REF] Fok | A lightweight coordination middleware for mobile computing[END_REF][START_REF] Murphy | Lime: A middleware for physical and logical mobility[END_REF][START_REF] Zheng | Mcl: a mobigate coordination language for highly adaptive and reconfigurable mobile middleware[END_REF]. To support mobile environment, one of the main improvement is the use of several tuple-spaces instead of a single one shared by all the processes. Then, from mobile computing, researchers have focused on making applications context aware by the use of tuple-spaces [START_REF] Barbosa | Towards a programming model for context-aware applications[END_REF][START_REF] Bortenschlager | A context-sensitive infrastructure for coordinating agents in ubiquitous environments[END_REF][START_REF] Julien | Egospaces: Facilitating rapid development of context-aware mobile applications[END_REF]. To go a step further with the mobility, toward autonomous systems, researchers considered more intelligent tuples [START_REF] Mamei | Programming pervasive and mobile computing applications: The tota approach[END_REF][START_REF] Viroli | Spatial coordination of pervasive services through chemical-inspired tuple spaces[END_REF]. They have shown the interest of relying on tuple-spaces in nowadays systems. However, there is still a gap between what people express and how the developer will implement it. We believe it is essential to provide means for developers to focus on the coordination of the systems. It is also tremendously important to provide them with a simple programming environment powerful enough to handle the system complexity. The response to the management of complex system should not be a complex programming environment.

This paper presents the full set of LINC features with a special focus on how it eases the coordination tasks. It complements partial description in earlier application domain oriented papers [START_REF] Ducreux | Resource-based middleware in the context of heterogeneous building automation systems[END_REF][START_REF] Louvel | A coordinated matrix of rfid readers as interactions input[END_REF]. LINC is a compact yet powerful coordination environment which relies on the three basic primitives of Linda to read, add and remove tuples in a tuple-space. It uses distributed tuple-spaces called bags. A bag is responsible for storing the tuples and may provide a special implementation of the three primitives. This is very convenient when communicating with the physical world (e.g. sensors or actuators) or when integrating legacy systems. LINC uses production rules to interact on the tuple-space rather than using imperative code to glue the primitives. Actions on the bags are embedded into distributed transactions which simplifies a lot the job of the developer that does not have to worry about writing code to roll back half of the actions done so far when something goes wrong. Transactions also enforce the consistency between the actual system and the software view. This, once again aims at helping developers to focus only on the coordination.

The paper is structured as follows. Section 2 presents the coordination language of LINC. Then, Section 3 describes its main features. Section 4 sketches several concrete case studies where LINC has been used. Section 5 positions our approach with respect to related works. Finally, Section 6 concludes the paper.

LINC coordination language

LINC is the natural evolution of the Coordination Language Facility (CLF) [START_REF] Andreoli | Multiparty negotiation of dynamic distributed object services[END_REF] and Stitch [START_REF] Andreoli | Resource-based scripting to stitch distributed components[END_REF] middlewares initially developed for deploying distributed applications. The three of them share the resource oriented approach manipulated through a high level rule-based language. However, the architecture of LINC has been completely revisited to adapt to the new landscape defined by the combination of the Internet-of-things, the cloud and the Cyber-Physical Systems. The main differences are:

in LINC, the coordination engine has been improved both in term of CPU usage and memory footprint. It is embedded in every object while CLF/Stitch relied on more complex dedicated objects. This allows to better distribute the coordination by delegating some parts to more modest CPU;

the rule language has been extended to improve its expressiveness; the environment comes with tools: monitoring, rule analysis (memory, time and dependencies) and a replay mechanism allowing post-mortem re-execution preserving causal order to debug the initial run. Tools are not the focus of this paper, details may be found in the LINC wiki (http://linc.middlewares.info).

LINC roots

We briefly recall here the basics of LINC to make the paper self contained. LINC, like CLF or Stitch, is rooted in Linda-like tuple-spaces (Associative Memory), Production Rules and Distributed Transactions.

Associative Memory: The global tuple-space is composed of several distributed tuple-spaces called bags. Tuples in bags are accessed with the three operations: rd(), get() and put(). The rd() verifies the presence of resources matching some given criteria: resources corresponding to the requested pattern (partially instantiated tuple) passed as parameter. The get() (in in Linda) removes a tuple while the put() (out in Linda) inserts a new tuple in a bag.

Production Rules: In LINC, the rd(), get() and put() primitives are invoked through production rules [START_REF] Cooper | Rule-based Programming with OPS5[END_REF]. This prevents to write a huge amount of imperative code such as Java, C or Python by the use of a coordination language to define how the resources are manipulated in the system. A production rule is decomposed in a precondition and a performance part. The precondition part uses rd() operations combined with an inference engine in order to evaluate distributed conditions in the system. Then, the performance part uses:

rd() to verify that conditions are still valid at performance time; get() to consume resources (e.g. manage critical resources, consume events); put() to generate resources (e.g update the system, command actuator).

A rule typically uses several bags, physically distributed or not, to access the necessary information and update the system accordingly. The particularity of LINC is that the performance part is embedded in Distributed Transactions.

Distributed Transactions: They are used in the performance part to ensure the all-or-nothing [START_REF] Philip A Bernstein | Concurrency control and recovery in database systems[END_REF] property. They group in the same set of operations the verification of some conditions, the consumption of critical resources and the update of the global state of the system. Thus, the performance part is a list of transactions that are executed in sequential order.

The combination of these three paradigms enables to build transactional reactions to complex events. Complex events in a building automation context could be the combination of several events such as people in the room and temperature lower than sixteen degrees and HVAC system is OFF. Transactional reactions consist in put the heating ON, and update the state of the system.

Bags abstraction

The main interest of splitting the global tuple-space into several bags is that each bag may define its own semantic associated to the rd, get and put and the tuples themselves. As a result, bags can encapsulate software or hardware components.

a database: each table of the database can be associated to a bag; rd() and put() corresponds to the reads and writes on the database.

a service: This concerns remote services as well as local services directly embedded in the bag. The partially instantiated tuple composed of the input parameters is passed to the rd(). The concerned service is invoked from the bag, using the legacy protocol imposed by the remote service (e.g. SOAP for a Webservice based approach or a native Remote Procedure Call). The output parameters obtained as the result of the service is added to the input parameters defining the fully instantiated tuple returned by the rd().

an event system: Tuples contain the topic, the ID, the timestamp and a payload; the rd() and put() operations correspond to subscribe and publish of the event system.

a sensor: Data are collected from the gateway and inserted into different bags storing the various relevant information. For instance, for a very simple approach, we can consider the three bags associating the id of the sensor to the sensed value, the type of sensor and its location. Successive values can be obtained through the rd(), changing the location of the sensor is as simple as modifying the resource by consuming it with a get() and inserting the updated information with a put(). The sampling frequency, the type of bag (e.g. set, multiset, FIFO, . . . ) or the precision can be adapted at this stage. The behaviour of the rd() may also be adapted to replace a simple tuple matching by a more complex matching: e.g. interval, fuzzy logic or ontologies.

an actuator: When interacting with the real world, the put operation is typically used to send actuation commands (e.g to set the speed of a motor, the direction of the wheels or to power on or off a subsystem). We can act on the physical actuator through a put() operation with a resource with the id, the command to be applied and the possible parameters p1, p2 into the associated bag. This is enough to trigger action to the actual actuator.

Finally, it is possible to associate bags. For instance, one bag can contain the number of resources contained in the bag it is associated to. More complex associations can be considered such as arithmetic functions (e.g. sum, average, max or min or even a Bayesian filter). The main advantage is to have a direct access to refined information computed from a set of resources. It has been used for instance in the application described in 4.2 to filter outliers values coming from a matrix of Rfid readers.

Coordination language

Bags are grouped into objects for identification purposes, thus objects are a logical decomposition of an application. For instance an object may manage all the sensors communicating with the same protocol or located in the same space. An object may execute rules to coordinate the system by acting on its own bags and the other objects' ones. When an object executes rules, it plays the role of coordinator. Rules can be executed by any object. This means that the programmer is free to distribute them among the different objects of an application.

To illustrate how LINC rules are working Listing 1.1 gives a very simple rule involving two sensors (presence and temperature) and an actuator (heating controller) using three different technologies (e.g. different protocols). This rule adjusts the heating of a room when someone is inside and the temperature is lower than 16 • C. The rule is composed of the precondition (when to trigger the rule) and the performance (what to do) separated by the symbol ::.

ASSERT: temp < 1 6 & { 1 , ! } [ " Techno1" , " l o c a t i o n " ] . r d ( " p r e s 1 " , l o c a t i o n ) & { * , ! } [ " Techno3" , " a c t u a t o r s l i s t " ] . r d ( i d a c t , " h e a t i n g " , l o c a t i o n ) : : { [ " Techno1"
, " s e n s o r s " ] . r d ( " p r e s 1 " , " T r u e " ) ;

[ " Techno2" , " s e n s o r s " ] . r d ( " t e m p e r a t u r e a " , temp) ; [ " Techno3" , " a c t u a t o r s " ] . p u t ( i d a c t , " h e a t i n g " , " 2 " ) ;

} { . . . # o t h e r g r o u p o f a c t i o n s } . Listing 1.1. LINC rule example
Precondition The precondition is composed of tokens processed by an inference engine with a right propagation. Listing 1.1 contains 8 tokens (1 per line).

The first token invokes a rd() operation into the bag "sensors" of the object "Techno1". This object encapsulates the gateway of the first technology. The token looks for the resource ("pres 1", "True") where the first field is the sensor id (generally imposed by the technology) and the second the value "True" meaning that a presence is detected. In a similar way, the second token asks for the temperature currently sensed by the sensor whose id is "temperature a". When the rd is done, all the matching tuples are returned one by one. For every returned tuple, a new branch is created with the value of the instantiated variables temp.

The instantiated variables are right propagated. For instance in the third token this variable is compared to the threshold (16 degrees) thanks to the ASSERT: extension1 . If the condition is false, the rule will not progress. If it is true, the next token asks the bag location, of the object "Techno1" (responsible for the presence sensor), for the location of sensor "pres 1". With this information, the last token can ask the id of the co-located heating system. The tokens in the precondition phase are preceded with modifiers embraced in curly brackets. The first field defines the number of maximum expected replies awaited by the rd() operation. Normally a rd() is blocked waiting for new matching resources that could become available. In this example, we use * for the first 2 tokens since we want to have all the replies. On the contrary, for the 4th we used 1 since a sensor has a single location and it is useless to wait for another resource. The second field is used to define the amount of time a pending rd() is waiting for a reply. Both are used to reduce the size of the inference tree as detailed in Section 3.2.

Performance The performance part may contain several transactions enclosed in curly brackets. The first transaction embeds the verification of the conditions presence and temperature and the operation on the heating system. Indeed, if the presence detector becomes false, this means the person is out of the room and nothing is required from the system. If the temperature has changed, it is not required to react. Indeed another inference will start with the new temperature, and a more accurate heating command will be computed. Finally, the last action of the transaction does the required operation on the heating system. Contrary to the Event-Condition-Action [START_REF] Günter Von Bültzingsloewen | Eca functionality in a distributed environment[END_REF] model, events and conditions are managed in the same way. Moreover, they may be enclosed with actions in a transaction.

The transactions are executed sequentially. If several transactions perform a get() on a same unique resource, they become exclusive. It is explained in context with the guards controlled alternatives (Section 3.3) and the graceful degradation (Section 3.4) mechanisms. The distributed transactions are enforced through a classical 2 Phase-Commit [START_REF] Philip A Bernstein | Concurrency control and recovery in database systems[END_REF] to provide atomicity property (all-ornothing). However, no hypothesis is made on how the bags implement these 2 phases. Thus, it is possible on the one hand to take advantage of the context and to implement a bag fully compliant with the 2PC on small microcontroller if required. On the other hand, it allows for a given bag to relax the 2PC.

Improvement with respect to CLF/Stitch

The explicit usage of the operations rd(), get() and put() in LINC allows to verify in the performance phase only the useful resources while in CLF/Stitch all the resources used in the precondition where systematically verified in the performance phase. The major drawback is that some rd() were verified even if it was not required. Indeed, among the rd() operations done in the precondition a significant part are just informative and not subject to change. Verifying them again in the performance was a waste of time and resources.

Another difference concerns the rd() and get() done in the performance. The presence of the resources returned in the precondition is verified in CLF / Stitch via a unique resource identifier. In LINC, it is not based on this identifier but on the value. This decreases the size of the inference tree and the amount of useless work when we have to deal with multiple resources with the same value (e.g. a sensor returning the same value).

Moreover, CLF considers in the performance a transaction for the rd() and the get() operations and the guaranty that the put() operations are eventually done by re-trying them until completion. This was motivated by the fact a put() was not supposed to fail. Indeed, for a tuple space, it is reasonable to consider that inserting a resource is always possible. However, in LINC we want also to target physical world, such as actuators that may fail when a put() is tried. Thus, LINC enforces a transaction for (rd(), get() and put()) operations allowing a richer transactional model in the performance part.

In addition to a stronger model, we do not restrict the performance to a single transaction but we can have a sequence of transactions. This brings the possibility of alternative treatments sharing the same precondition part. This not only decreases the work to be done by the coordination engine but also offers a better view to the programmer by replacing a set of CLF/Stitch rules by a single LINC rule. Powerful mechanisms using this capability, such as guards controlled alternatives and graceful degradation are described in Section 3.

Finally, the usage of modifiers in the precondition offers the programmer to specify information that helps the inference engine to better optimise the size of its data structures. This reduces both memory footprint and CPU usage.

All these improvements brought the required scale down in the rule management that allows LINC to target smaller computing units such as Raspberry PI, Pandaboard or even ARM9 custom board.

LINC features

This section presents several features offered by the LINC coordination language.

Control the frequency of a rule

In some circumstances it can be useful to control the pace of a rule. For instance, in Listing 1.1 the rule is triggered each time the temperature changes and a presence is detected. This is obviously too much for controlling the heating system. We can modify the rule by adding a new token at the first place of the precondition and at the first place of the performance part (cf. Listing 1.2).

We use a bag of type set called tick in which a new instance of the same resource is regularly inserted. The set property guaranties that a resource with the same value is present only once at a given time even if inserted several times (e.g. every 10 minutes). The precondition waits for the presence of this resource to start the evaluation of subsequent rd operations. If, in addition a token doing a get is added in the performance, it enforces that only one performance of the rule is performed per tick. Indeed, even if several instances of the rule reach the performance point, only one transaction will succeed. For the others, the get action (e.g. in line 5) will fail because the resource is not in the bag anymore.

{ * , ! } [ " C o n t r o l " , " t i c k " ] . r d ( t i c k ) & . . . # t o k e n s o f L i s t i n g 1 . 1 : : { [ " C o n t

Reduction of the inference tree

When a rule is executed, an inference tree is built. Its size, and the number of branches waiting for new resources to appear may become a problem, especially on embedded devices. Hence, it is important to limit the size of this inference tree to limit the memory used and to decrease the CPU load. For this, LINC relies on directives exploiting the knowledge of the developer and on an automatic process (garbage collector pruning useless branches).

Information from the developer: Via the modifiers introduced in Section 2, the developer can:

Limit the number of matching tuples to consider is typically used when the developer knows that only a given number of resources is really useful. For instance in the rule of Listing 1.1, the 4th token asks for the presence sensor location. As a sensor has a single location, we know that we can close the flow of reply to the rd() operation right after the first reply. This can be done by replacing the * in {*,!} with 1, i.e. the number of expected replies.

Limit the time to wait for matching tuples is used to model the expiration of some tuples. For instance, in the modified rule of Listing 1.2 a tick is generated every 10 minutes. A new branch is then started at each generation of a new tick resource. Thus, if no presence is detected during 2 hours, 12 branches will be waiting for the presence detection. When a presence is detected, the 12 branches will be activated, creating useless work. If we replace the ! in {*,!} with 600, the number of seconds to wait, the rd("pres 1","True") operation will be closed after 10 minutes and thus only one branch is active at a time.

Garbage collector When waiting on rd for matching tuples, it might become a point where branches of the inference tree built so far do not make sense any more. For instance here, when the presence sensor becomes "False", the resource ("pres 1","True") disappears from the bag (i.e. it is replaced by ("pres 1","False")). Then, it is not necessary to continue to maintain the branches depending on ("pres 1","True"). Indeed when the performance will be executed it will fail because this resource is not available.

A garbage collector periodically browses the inference tree asking the bags if the tuples are still present. By tuple we do not mean the exact same tuple but one with the same value. If the tuple is not there, the branch of inference tree starting from this node can safely be garbaged. Indeed, continuing the precondition will only lead to failures in the performance phase. If a branch is garbaged and the same value is added again in the bag, this will trigger a new inference. [ " Techno3" , " a c t u a t o r s " ] . p u t ( i d a c t , " h e a t i n g " , " 1 " ) ; } .

Guards controlled alternatives

Listing 1.3. Extension of rule in Listing 1.1 with guards

In the rule of Listing 1.3 we show how to implement a simple guards mechanism in the performance. Here we define how to manage the heating depending on the occupant's presence (i.e. putting the set point to "1" or "2"). Here, we do not test the presence in the precondition since we want to act in both case. We use 2 transactions, one for each case and we place in each of them a rd() respectively on ("pres 1","True") and ("pres 1","False"). Depending on the actual value of the resource, one of them commits and the other aborts.

Graceful degradation

Graceful Degradation is achieved by adding in the transactions a get() on a unique resource (created by the first transaction at line 3 in Listing 1.4). As transactions are tried in sequence, if transaction A succeeds, i.e. the heating command is successfully done, transaction B fails at line 9. If the heating system is not reachable, transaction A fails, transaction B succeeds (the temperature and presence have not changed). The unique is consumed and a SMS is sent to alert the maintenance. If the temperature has changed (or nobody is in the room anymore) at performance time, transactions A and B fail. However, as a new temperature resource is now available it is taken into account by another instance of the rule. Thus, a single rule can define what to do in the normal case and what to do in case of partial failures.

. . .

: :

{ [ " C o n t r o l " , " u n i q u e " ] . p u t ( u n i q u e ) ; } # c r e a t e u n i q u e { # t r a n s a c t i o n A

[ " C o n t r o l " , " u n i q u e " ] . g e t ( u n i q u e ) ;

.

. . } { # t r a n s a c t i o n B

[ " C o n t r o l " , " u n i q u e " ] . g e t ( u n i q u e ) ;

[ " Techno1" , " s e n s o r s " ] . r d ( " p r e s 1 " , " T r u e " ) ; [ " Techno2" , " s e n s o r s " ] . r d ( " t e m p e r a t u r e a " , temp) ;

[ " A l e r t " , " SMS" ] . p u t ( " 5 1 2 1 2 3 1 2 3 " , " H e a t i n g s y s t e m i s b r o k e n " ) ; } { [ " C o n t r o l " , " u n i q u e " ] . g e t ( u n i q u e ) ; } . # g a r b a g e u n i q u e Listing 1.4. Extension of rule in Listing 1.1 with graceful Degradation

Mutual exclusion

Mutual exclusion is not easy to solve with classic programming schemes such as semaphores or monitors. In LINC, the transactions greatly simplify the problem. To illustrate this, we propose our implementation of the classical philosophers dinner. The problem is solved by the two rules of Listing 1.5.

The bag philosopher contains resources associating the philosopher name and the id of his left and right forks. The bag fork manages the critical resources: the forks. When the first rule succeeds, it means a philosopher has gotten its two forks and moved from thinking to eating. If another rule instance wants to get a fork already attributed, it will fail because the resource is not in the bag anymore. The second rule makes the philosophers go from eating to thinking and put back the fork resources in the bag. This will wake up instances of the first rule waiting for available forks. [ " D i n n e r " , " s t a t e " ] . g e t ( name, " t h i n k i n g " ) ;

[ " D i n n e r " , " s t a t e " ] . p u t ( name, " e a t i n g " ) ;

} . # e a t i n g -> t h i n k i n g { * , ! } [ " D i n n e r " ,

{

[ " D i n n e r " , " s t a t e " ] . g e t ( name, " e a t i n g " ) ;

[ " D i n n e r " , " s t a t e " ] . p u t ( name, " t h i n k i n g " ) ;

[ " D i n n e r " , " f o r k " ] . p u t ( f o r k l ) ;

[ " D i n n e r " , " f o r k " ] . p u t ( f o r k r ) ; } .

Listing 1.5. Philosophers dinner problem in LINC

Rules activation / deactivation

One major issue when dealing with rules is how to control them and to ensure some guaranties when we decide to enable or disable some of them. To control the rules execution, we rely on the reflexivity of LINC. Indeed, in LINC everything is a resource in a bag. Naturally, rules are also controlled by resources in a dedicated bag of coordinator objects. This bag is called RulesId and contains tuples shaped as "(rule id, status)". When the rule is compiled, a rd is added at the beginning of the precondition and in each transaction as shown in Listing 1.6. The variable ego, used for object name, refers to the object executing the rule.

[ ego , " R u l e s I d " ] . r d ( " RU0001" , " ENABLED" ) ; Listing 1.6. Control of rules execution Adding these rd allows to stop a rule by simply changing the resource ("RU0001", "ENABLED") to ("RU0001", "DISABLED"). Indeed the rd on the rule status will make the transactions fail. To reactivate the rule, the resource status is put back to "ENABLED". Note that the rd on the rule status is the first rd of the precondition. This has three main interests:

when disabled, no new inference is started; when disabled, the inference tree is completely garbaged because the resource (rule id, "ENABLED") is no longer in the bag; if (rule id, "ENABLED") is put back, a new inference tree is built.

Note that this generic principle used at system level can be easily used at application level to activate and deactivate groups of rules according to application context. For instance, we can use the same principle with a resource controlling a set of rules. This can be used, for instance, to put in place a very sophisticated scenario manager in the building automation domain [START_REF] Ducreux | Resource-based middleware in the context of heterogeneous building automation systems[END_REF].

Dynamic rules generation

For some applications, it can be required to dynamically generate rules corresponding to contextual information. To do so, a resource is added in a dedicated bag, called AddRules. This bag receives resources of the form (package,source) where package is the logical name of a group of rules and source the actual code of the rules (as shown in Listing 1.1 for instance).

When a resource is added in this bag, the rule is dynamically compiled. This compilation includes syntax verifications, and various checks to prevent potential issues at execution time. For instance the coordinator object checks that the bags used by the rule are accessible, and that each variable will be instantiated at some point by a rd() operation in the precondition phase. If the rule contains no detectable error, the coordinator starts to execute it right away.

Registry-based programming

When interfacing with the hardware (very small embedded systems such as complex actuators) it is required to prepare the data in some dedicated registries and then to trigger the global action by acting on the control register. To reproduce this behaviour in a rule is straightforward because actions inside a transaction are executed sequentially. As shown in Listing 1.7, where two bags are used, one to map the data registers and one to map the control one. It is just mandatory to place the action of the control register at the last position in the transaction. Listing 1.7. Registry like programming

Case studies

This section presents case studies where the features of LINC have been used.

Building automation

Building automation is a typical case where coordination is essential and may become very complex. We need to coordinate a high number of sensors (e.g. temperature, light, co2, presence) and actuators (e.g. Heating, Ventilation and Air-Conditioning (HVAC), dimmable spotlights). These devices belong to independent subsystems distributed in the building and using different protocols: BACnet [3], LONWorks [START_REF] Lonworks | [END_REF], KNX [16] or Zigbee, 433Mhz/868Mhz for wireless. These subsystems work autonomously but most of the time cannot cooperate.

In the context of the SCUBA (Self-organising, Co-operative and robUst Building Automation) FP7 project [START_REF] Scuba | [END_REF], LINC has successfully been used to offer the abstraction layer required to make all these devices able to coexist. In addition LINC has provided the coordination in order to allow the binding of devices of different constructors across a set of buildings [START_REF] Ducreux | Resource-based middleware in the context of heterogeneous building automation systems[END_REF]. Several scenarios have been defined to coordinate the HVAC and the lighting systems in order to improve the energy efficiency. The graceful degradation feature of LINC has proven very efficient to handle partial failure of autonomous systems. The application is currently distributed across 6 partners' sites controlling 5 buildings.

Another important role played by LINC was the administration of autonomous subsystems according to context. It has been used to reconfigure the LONWorks bindings in a room that can be either two individual offices or a single larger room, depending on the presence of a removable wall. The binding of the buttons, temperature sensors, motion detectors to the lights, shutter, HVAC have to be reconfigured accordingly. In LONWorks, this would involve the manual intervention of a skilled technician. With LINC we have coordinated the reconfiguration process with rules dynamically generated according to the current context [START_REF][END_REF].

RFID table

To illustrate the capability of LINC to manage complex events detection, [START_REF] Louvel | A coordinated matrix of rfid readers as interactions input[END_REF] describes our experiment with an original hardware. This hardware is a table stacking a 42" LCD screen with a HD 1080p resolution on top of a set of rfid readers organised as a matrix of 6 x 4 tiles, with each tile containing itself a matrix of 4 x 4 rfid readers. As a result there are 24 x 16 (384) rfid readers distributed in the table. The table works with classical rfid tags that can be attached to any physical object. The raw information received is, for each rfid reader, the set of detected tags. In addition, we have encapsulated as LINC bags two software components: a 2D engine able to display arbitrary content on the screen table allowing user interaction and a 3D engine able to render in a virtual world the tagged physical objects placed on the table.

The coordination language of LINC allowed to manage complex events resulting from the manipulation of the tags frequently added and removed from the table. The full application is managed by a dozen of rules distributed on the laptop responsible for displaying the 3D scene on the external display and the Raspberry PI managing the screen embedded in the table.

Smart actuators

In [START_REF] Iris | Smart sensors and actuators: A question of discipline[END_REF] we have designed smart actuators able to directly understand the LINC coordination protocol and thus to be participant to transactions. The actuator is thus able to locally detect that it will not be able to do the requested action. For instance, this may be due to currently insufficient energy or unfeasible physical actuation (e.g. due to an obstacle or an out of range request). This simplifies the error management and allows synchronised physical actions. For instance, we used these smart devices for the obstacle avoidance of an autonomous robot where actions on the motors failed when associated sensors detect obstacles in the considered direction. The bags encapsulating the control of the motor have been implemented on small microcontrollers of type ATmega328 or PIC24.

Since the introduction of tuple-spaces by Linda [START_REF] Gelernter | Generative communication in linda[END_REF] in 1985, many contributions have been proposed to improve, extend and adapt the model.

MARS [START_REF] Cabri | Mars: A programmable coordination architecture for mobile agents[END_REF] extends the Linda tuple-spaces to add reactions. A reaction is implemented by an agent which triggers an operation on a matching tuple. Reactions are implemented with "meta" tuples containing a reference to the agent. In LINC, the reactions are defined by high-level coordination rules which embed actions in distributed transactions.

LIME [START_REF] Murphy | Lime: A coordination model and middleware supporting mobility of hosts and agents[END_REF] (Linda In a Mobile Environment) replaces the globally accessible persistent tuple-space of Linda by transiently shared tuple-spaces. In LIME each agent has its own tuple-space. When agents meets, they form a shared tuple-space and can exchange tuples. Strong reactions (ensuring a transaction) are restricted to a host or an agent. For distributed reactions, Weak reactions are used to ensure that eventually the reactions will be done if connectivity is preserved. LINC always uses distributed transactions in order to maintain the system in a consistent state. A similar approach to LIME is proposed in [START_REF] Fok | A lightweight coordination middleware for mobile computing[END_REF], with a lighter implementation of tuple-spaces.

The Holoparadigm [START_REF] Barbosa | Towards a programming model for context-aware applications[END_REF] is a programming model to build context aware applications which introduces the concept of Being containing an interface, a behaviour and a history. History is a blackboard (similar to tuple-spaces) with Linda-like primitives. Holoparadigm offers the architecture for building agents however it mixes the coordination with the agents' code.

EgoSpaces [START_REF] Julien | Egospaces: Facilitating rapid development of context-aware mobile applications[END_REF] is a middleware targeting development of context aware mobile applications. It defines an agent as a unit of modularity and mobility with its own local tuple-space. EgoSpaces adds the View concept to limit the data seen by an agent (e.g. cost of the communication, physical location, thresholds on data). The view concept is interesting because it allows the developer to define when an agent should react.

The MobiGATE Coordination Language (MCL) [START_REF] Zheng | Mcl: a mobigate coordination language for highly adaptive and reconfigurable mobile middleware[END_REF] insists on the separation between computation and coordination which is a shared approach with LINC. Their approach seems well suited for distributing a stream or a known service in a mobile environment. However, in MCL it seems difficult to focus on the coordination when a very complex and dynamic system is considered. UbiCoMo [START_REF] Bortenschlager | A context-sensitive infrastructure for coordinating agents in ubiquitous environments[END_REF] proposes a coordination model that mainly focuses on accessing data in ubiquitous environments. However, this limits too much UbiCoMo expressiveness to fit into this specific paradigm. MCL and UbiCoMo share with LINC the importance of separation between coordination and computation.

In [START_REF] Fjellheim | A processbased methodology for designing event-based mobile composite applications[END_REF] the authors propose a process-based methodology to design eventbased mobile applications. They aim to translate UML activity diagram to event based models offering more flexibility. As outlined in their conclusion, eventbased approaches does not make synchronisation easy. We believe this issue could be overcome by the transactional guaranties of LINC. We also believe that LINC rules could be generated from the activity diagram. This could be an interesting track to consider.

In [START_REF] Kühn | Peer-based programming model for coordination patterns[END_REF] the authors present a programming model for concurrent coordination patterns targeting highly parallel and distributed applications. Similarly to LINC, they provide a language to focus on the coordination in complex environment. They aim to provide a high level language, relying on a formal language from which LINC could also take advantage of. Finally, their model relies on a tuple-space middleware. LINC seems a good candidate to implement their model. Generating LINC rules from a higher level model is in our future work.

In TOTA (Tuples On The Air) [START_REF] Mamei | Programming pervasive and mobile computing applications: The tota approach[END_REF], tuples are not associated to a specific host, they are injected in the network and can autonomously propagate in the network according to a specified pattern. A tuple is defined by a content and a propagation rule. The TOTA approach might be interesting in some context where the data moves around the network while hosts come and go. However, in other cases this might include an overhead in the traffic because tuples are propagated even if no host is interested in them. On the contrary, in LINC, tuples are exchanged only when a rule is needing them. We believe that the autonomous and self evolution idea of TOTA could be implemented in LINC thanks to its reflexivity. Indeed objects and rules can evolve to reach an emergent behaviour.

Inspired by Gamma [START_REF] Banȃtre | Gamma and the chemical reaction model: Fifteen years after[END_REF], another approach to reach self evolving system is to use chemical inspired tuple-spaces [START_REF] Viroli | Spatial coordination of pervasive services through chemical-inspired tuple spaces[END_REF]. The idea is to rely on the semantic of chemical reactions to build coordination laws. High level information are then given on tuples and they autonomously evolve and move. The goal is to have an emergent behaviour with this approach. For instance, services scarcely used will automatically disappear from the tuple-space. This work only focus on the long run emerging behaviour, they do not allow to directly build coordination for the physical world. Moreover, focus has been on simulation [START_REF] Pianini | Chemical-oriented simulation of computational systems with alchemist[END_REF] even if a middleware is under development in the scope of the SAPERE project [START_REF]SAPERE[END_REF]. Finally, in [START_REF] Viroli | Linda in space-time: an adaptive coordination model for mobile ad-hoc environments[END_REF] the author define a spatial computing coordination language to extend Linda with space and time information in the tuples. As far as we understand, no implementation exists so far. LINC, with its reflexivity, could implement these proposal on large scale distributed systems.

Conclusion

This paper has presented the LINC coordination environment. It provides a compact yet powerful coordination language based on the three paradigms: associative memory, production rules and distributed transactions. This combination provides a language with a high expressiveness. High level coordination rules can be written while relying on the tuple-space to abstract low level implementation and communication details.

In addition, LINC is highly reflexive. Because everything is a resource it is easy to control the execution of rules or group of rules. Coordination rules can be dynamically added, removed or moved to another object. Objects themselves can migrate and independently designed applications can be merged at run-time.

With all these properties and its reflexivity, LINC is a powerful environment to tackle the challenges of the future systems of systems.

{

  * , ! } [ " Techno1" , " s e n s o r s " ] . r d ( " p r e s 1 " , " T r u e " ) & { * , ! } [ " Techno2" , " s e n s o r s " ] . r d ( " t e m p e r a t u r e a " , temp) &

  " , " s e n s o r s " ] . r d ( " p r e s 1 " , " T r u e " ) ; # F i r s t g u a r d [ " Techno2" , " s e n s o r s " ] . r d ( " t e m p e r a t u r e a " , temp) ; [ " Techno3" , " a c t u a t o r s " ] . p u t ( i d a c t , " h e a t i n g " , " 2 " ) ;} . {[ " Techno1" , " s e n s o r s " ] . r d ( " p r e s 1 " , " F a l s e " ) ; # S e c o n d g u a r d [ " Techno2" , " s e n s o r s " ] . r d ( " t e m p e r a t u r e a " , temp) ;

11

 11

#

  t h i n k i n g -> e a t i n g { * , ! } [ " D i n n e r " , " p h i l o s o p h e r " ] . r d ( name, f o r k l , f o r k r ) & { * , ! } [ " D i n n e r " , " f o r k " ] . r d ( f o r k l ) & { * , ! } [ " D i n n e r " , " f o r k " ] . r d ( f o r k r ) & { * , ! } [ " D i n n e r " , " s t a t e " ] . r d ( name, " t h i n k i n g " ) & : : { [ " D i n n e r " , " f o r k " ] . g e t ( f o r k l ) ; [ " D i n n e r " , " f o r k " ] . g e t ( f o r k r ) ;

  " s t a t e " ] . r d ( name, " e a t i n g " ) & { * , ! } [ " D i n n e r " , " p h i l o s o p h e r " ] . r d ( name, f o r k l , f o r k r ) & SLEEP: 1 0 : :

  b j e c t " , " d a t a " ] . p u t ( " r 1 " , v a l u e 1 ) ;[ " o b j e c t " , " d a t a " ] . p u t ( " r 2 " , v a l u e 2 ) ; [ " o b j e c t " , " cmd" ] . p u t ( " s e n d " ) ; } .

The extensions ASSERT:, COMPUTE: and SLEEP: allows to respectively verify a condition, execute simple computation or wait for a given time.

We illustrated this with several real world case studies implemented on top of LINC. This demonstrated the ability of LINC to be used in contexts such as building automation, power efficiency or monitoring network systems.

Future work will focus on providing a high-level language such as automata in order to prove the correctness of the coordination and then to automatically generate the corresponding coordination rules. We envisage to use this mechanism for self-evolving system where we can prove that the evolution will not break the running application.

Acknowledgement. This work has been partially funded by the FP7 SCUBA project under grant nb 288079.


João Eusébio

Luís Luís B Oliveira
email: l.oliveira@fct.unl.pt

Miguel Pires

João P Oliveira

Luís Miguel Pires
email: l.pires@campus.fct.unl.pt

A 0.5 V Ultra-low Power Quadrature Ring Oscillator

Keywords: Quadrature RC oscillator, CMOS circuit, Low voltage, Ultra-low power

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

Introduction

Nowadays there is a huge demand on ultra-low power circuits for portable equipment, in wireless communication applications. Moreover, designers try to reduce the production cost, reducing the circuits die area (avoiding the use of on-chip inductors) and using standard CMOS technology. Thus, they try to obtain high frequency performance, with low supply voltage and low power. This is the motivation for use modern receivers receiver architectures such as Low-IF Intermediate Frequency (IF) or Zero-IF, which can be used to further reduce the cost since they do not require eternal image reject filters and can be designed in a single chip using standard CMOS technology without inductor [START_REF] Razavi | RF Microelectronics[END_REF]- [START_REF] Crols | CMOS Wireless Transceiver Design[END_REF]. Typical applications are in biomedical bands, such as Wireless Medical Telemetry Services (WMTS) and Industrial, Scientific, and Medical (ISM), since the main requirements are low power consumption and low cost [START_REF] Iniewski | VLSI Circuits for Biomedical Applications[END_REF]. The oscillator that is a key block in these systems will be investigated in this paper. Quadrature Ring oscillators are key blocks on the design of these architectures since they can be fully integrated, they do not have inductors and thus occupying very low area. They have higher tuning range (useful to cover several bands) and are able to provide quadrature signals with low quadrature error [START_REF] Oliveira | Analysis and Design of Quadrature Oscillators[END_REF].

In this paper, we present a CMOS ring oscillator [START_REF] Grozing | CMOS Ring Oscillator with Quadrature Outputs and 100 MHz to 3.5 GHz Tuning Range[END_REF] capable to achieve quadrature outputs for very low voltage operation (in our case 0.5 V). A circuit design in a 130 nm CMOS technology proves that changing the voltage of the bulk node in NMOS and PMOS transistors allows the reduction of the transistor threshold voltage (V th ) [START_REF] Nose | Optimization of VDD and VTH for Low-Power and High-Speed Applications[END_REF]. With that change we are able to increase the transistor transconductance (g m ) (in comparison with the original), and therefore, designing a Voltage Controlled Oscillator (VCO) for the GHz range with very low power and high Figure Of Merit (FoM). The tuning of the oscillator in the GHz range can be achieved by changing the bulk voltage, while keeping a low supply voltage, with a FoM of -114.7 dBc/Hz at 10 MHz offset.

In section 2, we describe the contributions of this paper for the conference theme. In section 3, we describe low voltage techniques for CMOS inverter. In section 4, we present the proposed circuit and we present the simulation results, and finally, in section 5 we draw the conclusions.

Contributions for Technological Innovation for Collective Awareness Systems

Nowadays, the emergence of collective awareness systems is pushing the performance of end user interactive objects. These devices are embedded with sensors and actuators with the ability to communicate and exchange information, in a global cloud environment "Internet of the future" or "Internet of Things". The physical communication plays a critical role in portable wireless devices equipped with very low power modern receivers with very low noise, and accurate and stable frequencies signals to ensure a reliable and efficient communication in a crowded channel environment. With this goal in mind the design of Radio Frequency (RF) front-end blocks for low power applications, in CMOS technology, will contribute towards the achievement of more cheap and robust devices. In this paper we will focus on the design of low power wideband CMOS quadrature oscillators.

Low Voltage Technique for a CMOS Inverter

A basic ring oscillator is composed by and odd number of single-ended blocks in a feedback topology [START_REF] Razavi | RF Microelectronics[END_REF]- [START_REF] Lee | The Design of CMOS Radio Frequency Integrated Circuits[END_REF]. In the work proposed in [START_REF] Grozing | CMOS Ring Oscillator with Quadrature Outputs and 100 MHz to 3.5 GHz Tuning Range[END_REF] they combine 4 blocks of 3 inverter stages in a quadrature ring oscillator. In this work we use the circuit topology proposed in [START_REF] Grozing | CMOS Ring Oscillator with Quadrature Outputs and 100 MHz to 3.5 GHz Tuning Range[END_REF], but with the inverter operating in ultra-low power voltage (0.5 V) for very low power consumption. The basic inverter cell is shown in Figure 1. This cell is composed by two MOSFETs. The top MOSFET is a PMOS transistor and the bottom is a NMOS transistor. The bulk is linked to the respective sources, PMOS source is linked to V DD , NMOS source is connected to Vss, reducing the value of the threshold voltage, V th , to V T0 (V th voltage at V BS =0V). Interestingly, this threshold voltage, can be further reduced by directly biasing the bulk-source junction, as shown in [START_REF] Razavi | RF Microelectronics[END_REF]- [START_REF] Lee | The Design of CMOS Radio Frequency Integrated Circuits[END_REF] ( )

0 th T o o BS V V V γ φ φ = -⋅ - - (1)
where F φ is the Fermi potential, γ is the body-effect coefficient, ∆ φ ≈ 6 kT/q and φ 0 = 2 F φ + ∆φ .

The first modification for the basic CMOS inverter is to add a voltage different than zero to the bulk of transistor NMOS, VCTRL, as shown in Figure 2-a). This is possible since we are using CMOS triple well process. The second change is to perform the same modification to the transistor PMOS, as shown in Figure 2-b). Thus, the final circuit is shown in Figure 2-c), with the objective of changing simultaneously both bulk voltages (in the range of 0 to 0.5 V) in order to reduce the transistor's V th . The final configuration of the inverter represented in Figure 2-c), is formed by PMOS transistor with width of 3 µm and a length (L min ) of 120 µ m while for the NMOS transistor the width is set to 1 µm maintaining L min in 120 µm. In every single schematic the results were similar in the sense of reducing the values of V th . But more effective changes are achieved by changing simultaneously the bulk voltages of both devices. In Figure 3 it is shown that the reduction curve of V th varying the bulk voltage between 0 and 0.5 V.

Proposed Circuit for a 0.5 V Ring Oscillator

The proposed low-voltage circuit is shown in Figure 4. It consists of a ring oscillator with quadrature outputs formed with eight inverters, powered by a 0.5 V source voltage with the objective of achieving low power consumption. Low voltage operation is achieved by reducing the V th through the bulk, as explained in section 3. The inverter transistors sizing was done in order to minimize the power consumption and L min has been chosen ensuring that the inverters operate at 1 GHz. Due to the transistors mobility differences in UMC BSIM3V3 130 nm, the PMOS have width three times higher than NMOS transistors.

The simulations revealed that the optimal results were obtained with 0.5 V in bulk VCTRL. PMOS and NMOS respectively have the bulk driven by an external source voltage in a similar process like the work proposed in [START_REF] Nose | Optimization of VDD and VTH for Low-Power and High-Speed Applications[END_REF]. To evaluate the performance of the overall circuit, it is used the accepted FoM given by, 2 core measured FoM 10 log 1

DD OSC I V f L f mW ∆     ⋅   = + ⋅ ⋅         , (2)
where, L measured is the value of the phase noise measured at 10 MHz, ∆f is 10 MHz and I core is the current consumption of the circuit core.

Using the traditional inverter in the quadrature ring oscillator, represented in Figure 1, and varying the supply voltage between 0.3 and 0.5 V, it is possible to see that the FoM has a variation smaller than 1.4 dB, as shown in Figure 5. Other important result is the current consumption that rises when the FoM reach higher values, as shown in Figure 6. The result in Figure 7 was chosen from the range of FoM variations, a range over 3 dB, for the case of schematic in Figure 2-c). Clearly the best situation in Figure 8 is the first one, were the FoM has the best value and the current is the smallest one. In Table 1 is possible to visualize the advantages and disadvantages from each schematic presented previously (Figure 2-a), b) and c)). The best results are obtained using the inverter with both reduced V th , were the FoM varies up to 3 dB. Moreover, this simultaneous V th reduction in both transistors enables the operation of the oscillator at very low voltage supply, with reduced current supply.

Fig. 1 .

 1 Fig. 1. Basic CMOS Inverter.

Fig. 2 .

 2 Fig. 2. Voltage source added to: a) bulk of the NMOS b) bulk of the PMOS c) both NMOS and PMOS.

Fig. 3 .

 3 Fig. 3. V th reduction for the NMOS and the PMOS transistors.

Fig. 4 .

 4 Fig. 4. Quadrature four-stage ring oscillator.

Fig. 5 . 6 .

 56 Fig. 5. FoM versus oscillation frequency Fig. 6. FoM versus current supply

Fig. 7 .

 7 Fig. 7. FoM versus oscillation frequency Fig. 8.FoM versus current supply.

Fig. 9 .

 9 Fig. 9.FOM versus oscillation frequency. Fig. 10. FoM versus current supply.


Joana Correia
email: jm.correia@campus.fct.unl.pt

Nuno Mancelos
email: n.mancelos@campus.fct.unl.pt

João Goes
email: goes@fct.unl.pt

Stability Improvements in a Rail-to-Rail Input/Output, Constant Gm Operational

Keywords: Low-voltage DTMOS technique, Low supply voltage OPAMP, Low-voltage OPAMP stability issues

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

Introduction

The general tendency for reducing the supply voltage in ICs represents a challenge for analog amplifier designers, in terms of maintaining required gain levels, bandwidth (BW) and stability. In terms of stability and frequency compensation, several techniques can be implemented, but the solutions represent an increase of the circuit area, since they often include the need of additional capacitors.

As a starting point for the testing of the DTMOS technique, an operational transconductance amplifier (OTA) was chosen. The choice is based on an original, rail-to-rail Input/Output, constant ܩ OTA, described in [START_REF] Citakovic | A 0.8V, 7µA, Rail-to-Rail Input/Output, Constant G m Operational Amplifier in Standard Digital 0.18µm CMOS[END_REF], and operating at a 0.8 V supply. The technology used for the initial amplifier was the purely-digital 180 nm CMOS, whereas the present implementation, fully supported in the initial study, [START_REF] Citakovic | A 0.8V, 7µA, Rail-to-Rail Input/Output, Constant G m Operational Amplifier in Standard Digital 0.18µm CMOS[END_REF], was simulated using the CADENCE, with an UMC 130 nm, purely-digital, CMOS technology. The change in technology doesn't represent a relevant factor in the overall behavior of the circuit.

The main objective of this work is to improve the gain, GBW and stability of the original amplifier, and to guarantee that the OTA still works, with reasonable performance, when operating at much lower supply voltages.

The DTMOS technique was the technique chosen to reach the objectives, and consists in connecting the bulk of a transistor to its gate terminal. This allows the bulk voltage to be variable, instead of being fixed at ground or V DD (NMOS or PMOS, respectively) [START_REF] Shouri Chatterjee | Analog Circuit Design Techniques at 0[END_REF]. The transistor suffers from body-effect, in this configuration, since the voltage between the source and bulk terminals is not zero. However, the transcondutance that is a result of the body-effect contributes, positively, to the total transcondutance of the transistor, being this contribution an increase of approximately 20-to-30% of the transcondutance of the transistor. This means that in the DTMOS configuration, the body-effect of a transistor is not a degrading factor in its ܩ , but rather an improvement.

The disadvantages of using the DTMOS technique are the increase of the parasitic capacitances in the transistor, which can ultimately lead to a loss of circuit BW, and the possibility of a latch-up problem. In the case of this particular application and circuit, the latch-up situation is not a real problem, because there won't be sufficient voltage to trigger the effect, since the intended test supply voltages will be lower than 0.7 V, which is the typical problematic threshold that allows that effect to be a problem. In terms of the increase of the parasitic capacitances, and consequent decrease in BW, the situation can be dealt with separately, although the changes in the parasitic capacitances are not relevant enough to reflect some problematic difference in terms of the BW.

Relationship to Collective Awareness Systems

Collective Awareness Systems that are capable of harnessing collective intelligence, allowing the creation of a network of distributed knowledge and data from real environments, include a multitude of individual subsystems that must be able to collect and transmit the actual information that is shared in the system. These subsystems may include a wide range of different devices and applications, but they usually consist in wireless and portable devices [START_REF] Bicocchi | Collective Awareness and Action in Urban Superorganisms[END_REF] for which concerns like power consumption and autonomous lifetime are very pertinent.

The DTMOS low voltage technique used in this work is one of the techniques that allow reduction in circuit supply voltage, and consequently power consumption. Moreover, as it will be demonstrated in this paper, the use of DTMOS in certain specific devices can improve the stability of the circuit, which translates into smaller area (there is no need for larger compensating capacitors). The significant supply voltage reductions that can be achieved with this technique are promising for the hardware implementations of Collective Awareness Systems or any other system where power consumption and cost (silicon area) are key factors.

3 Amplifier Description

Initial Amplifier

The 0.8 V, rail-to-rail Input/Output, constant ܩ OTA, whose schematic is presented in Fig. 1, consists of two stages. The rail-to-rail folded-cascode input stage includes two differential pairs in parallel, consisting of the transistors M1, M2 (NMOS differential pair), M3 and M4 (PMOS). This configuration allows rail-to-rail operation at the input. For high common-mode voltages at the input, the NMOS differential pair is on, while for low common-mode voltages it is the PMOS differential pair that is on. For medium levels of the common-mode voltages, both differential pairs are on, increasing the current flowing to the summing circuit and consequently increasing the ܩ . To avoid this increase in the transcondutance, since it is desirable to have it constant for the whole range of common-mode voltages, the current switches M5 to M8 are added. The following folded-cascode configuration is responsible for the summing of the signals (current) coming from the complementary differential pairs.

The class AB output stage features, as stated above, the cascaded-Miller frequency compensation technique, which includes the capacitors CM1 and CM2. Class AB operations are made possible by M19 and M20. These transistors are driven by the signal currents coming from transistors M14 and M16 and are polarized by the diodeconnected transistors M22, M23, M25 and M26. The output transistors M27 and M28 are in common-source configuration to allow rail-to-rail operations at the output. The M27 transistor functions at the positive swing, while M28 takes care of the negative swing. The frequency of non-dominant pole is shifted to higher frequencies by the cascoded-Miller frequency compensation technique.

Proposed Modifications in the Original Amplifier

The low-voltage DTMOS technique was chosen as the approach to use because of the simplicity of the implementation, since it basically consists in disconnecting the bulks of the PMOS and NMOS devices, respectively from ܸ and V SS , and re-connect them to the gate terminal [START_REF] Abdollahvand | Design of Robust CMOS Amplifiers Combining Advanced Low-Voltage and Feedback Techniques[END_REF][START_REF] Abdollahvand | A Low-Voltage CMOS Buffer for RF Applications Based on a Fully-Differential Voltage-Combiner[END_REF].

Many possible configurations have been simulated and evaluated, using the DTMOS technique applied to different sets of transistors. The best results, taking into account simplicity and gain results, were achieved using the DTMOS technique only in the NMOS cascode devices M13 and M14. Notice that the DTMOS technique also has the benefit of reducing the threshold voltage of the transistor. Since NMOS transistors have a higher threshold voltage than PMOS, it is understandable that it is preferable to use the DTMOS technique in the NMOS cascode transistors rather than in the PMOS. This requires fabrication processes either with triple-well or with deep-Nwell but this is clearly the case, for all state-of-the-art deep nano-scale CMOS technologies.

Amplifier Performance

Electrical Simulations of the Original Amplifier Circuit

The simulation results achieved with the initial configuration of the circuit ported into the 130 nm CMOS technology (the original circuit, without the use of the DTMOS technique) are presented in Table 1. The presented results include simulations run under different supply voltages, focusing on the values of DC gain, GBW and Phase Margin (PM). The simulated PM is evaluated at a typical closed-loop gain of 6 dB, for each ܸ value. The presented PM results are lower than 55 o , which leads to the conclusion that the circuit is not stable for any of these supply voltages. In terms of DC gain and GBW, the values decrease as a consequence of the lowering of the ܸ value, as it is expected. However, the decrease in those values is not as substantial as was estimated, revealing that the topology of the circuit is capable of maintaining both the gain and the GBW performance parameters even at lower supply voltages (i.e., below 0.8 V).

Re-Design of the Amplifier Using DTMOS

For the circuit amplifier including the proposed changes, the same simulations have been carried-out, under the same conditions (common-mode voltages at 55 % of ܸ , the PM measured with a closed-loop gain of 6 dB). The results are summarized in Table 2. As it can be observed in Table 2, there are just minor improvements in the DC gain and in the GBW. The most significant improvement is the PM parameter, particularly at very low supply voltages below 0.6 V. Since the values are superior to 55 o , the OTA circuit is now stable for those ܸ values and can operate down to 0.3 V.

The gain and phase plots are presented in Fig. 2 and in Fig. 3, for a 0.4 V supply voltage. This ܸ value was chosen as a reference example because it is half the value of the supply voltage for which the original circuit was designed (which constitutes, by itself, a significant reduction in the supply voltage) and because it presents good gain, GBW and PM results, in comparison to the results achieved by the original circuit, for that same ܸ .

Conclusions

It has been demonstrated in this paper that, using DTMOS in a couple of specific devices of a two-stage rail-to-rain Input/Output, constant G m OTA can improve its stability whilst operating at very low supply voltages. The proper choice of specific transistors in which the technique should be used has been presented, as well as the resulting improvements. The implemented changes allow the circuit to be stable at low voltage operations without requiring any increase in the cascoded-Miller compensation capacitors, saving circuit area and, consequently, cost.

The significant supply voltage reductions that can be achieved with this DTMOS technique are, therefore, quite promising for the hardware implementations of Collective Awareness Systems, in which amplifiers are of paramount importance, and where power consumption and cost (silicon area) are limiting factors.

Fig. 1 .

 1 Fig. 1. Initial operational amplifier.

Fig. 3 .

 3 Fig. 3. Gain trace.

Fig. 3 .

 3 Fig. 3. Gain and Phase traces.

Table 2 .

 2 Simulated results for the initial configuration of the amplifier circuit.

	V DD (V)	Gain (dB)	GBW (kHz)	Phase Margin (⁰)
	1.2	82.62	857	> 56
	0.8	82.58	864	> 56
	0.7	81.16	824	> 56
	0.6	81.44	833	52
	0.5	78.5	818	56
	0.4	72.15	878	53
	0.3	57.7	794	51

Table 2 .

 2 Results for the new circuit configuration (DTMOS).

	V DD (V)	Gain (dB)	GBW (kHz)	Phase Margin (⁰)
	1.2	80.37	887	> 60 (higher)
	0.8	79.54	844	> 60 (higher)
	0.7	79.14	902 (higher)	> 60 (higher)
	0.6	79.5	872 (higher)	57 (higher)
	0.5	77.14	909 (higher)	61 (higher)
	0.4	72.45 (higher)	924 (higher)	60 (higher)
	0.3	58.82 (higher)	794 (same)	59 (higher)


Fábio Querido
email: f.querido@campus.fct.unl.pt

João P Oliveira

Touch Interactive Matrix LED Display for the Collective Awareness Ecosystem

Keywords: Light Emitting Diode, LED Matrix, Bidirectional LED, Air Touch, Remote Touch, Multi Touch, Interactive LED, Touch Sensor, Display Devices

Nowadays, the devices have the role to be user-friendly with the touch interfaces. In this paper it is presented an interactive touching device fully supported in LED technology. This is achieved through the use of an array of LEDs where each one works as a light emitter and as a sensor. The implementation uses a microcontroller to control the LED operation. Also it is proposed a new LED unit matrix configuration that avoids the use of an external light source to detect any touch. This new architecture only needs two microcontroller input/output to each row plus column which provides a userfriendly interactive contactless interface. Also it is explained how to aggregate these unit modules into a bigger LED display panel, reducing implementation costs.

Introduction

Light Emitting Diodes, or LEDs, are nowadays a very common source of light due to their higher energy efficiency, and easy dimming light control through standard Pulse With Modulation (PWM). In addition, this device can also be used as a photosensor [START_REF] Dietz | Very low-cost sensing and communication using bidirectional LEDs[END_REF], which can operate as a light emitter in one phase, and as a light sensor in other phase, all without hardware modifications. This coordinated operation can transform a large LED display, like advertising panels or queuing information panels, into a bidirectional interface with, basically, the same hardware. Moreover, the LED sensing capability can also be explored as a wireless two-way communication port [START_REF] Dietz | Very low-cost sensing and communication using bidirectional LEDs[END_REF].

Considering a matrix of LEDs, by quickly switching them between forward-biased (light-emitting) and reverse-biased (light-sensing) modes, it is possible to create dynamic images while measuring the lighting level, at the same time. In [START_REF] Hudson | Using light emitting diode arrays as touch-sensitive input and output devices[END_REF], some techniques to sense a touch finger with an LED matrix are presented, which can measure the reflected light through finger proximity. The operation can be managed by a master controller which controls each desired pixel intensity, while a slave module is dedicated to forward and reverse bias the LEDs.

In this paper, techniques will be studied with the objective to implement a display that can produce an image, while measuring the ambient environment. A master controller, using a dedicated protocol, controls its operation but at the same time transform it into an interactive contactless input interface. For instance, each frame defines all intensity to each pixel followed by the setup of one of three modes, only light emission, sense, or at the same time sense and light emission.

Each module only completes the cycle when all LEDs provide the desired operation requested by master controller. For the light emission stage, the microcontroller ( ) can provide at the same time the complete LED row, and finishes the cycle when all rows are completed. In case of sensing only the ambient lighting level, the microcontroller read all columns in the row at the same time, and after finishes all rows, send each value of each to the master controller, and wait for other cycle mode. In the sense and light emission mode, all LED in the same row in odd columns are emitting. In the neighbor row, sensing light in even-numbered columns are accomplished. The cycle is completed when all pixels generated a proper value of intensity light, received the feedback light of each one and sent the feedback values to the master controller.

With this methods, the touch display implementation have low cost and low complexity hardware. It can also be used to sense multiple lasers with different wavelengths which are pointed by distinct users at the same time allowing the differentiation of the remote touch of each user, being similar to [START_REF] Pasquariello | Remote-Touch: A Laser Input User-Display Interaction Technology[END_REF] in remote touch parameter.

Contribution to Collective Awareness Systems

Nowadays, the emergence of collective awareness systems is pushing the performance of end user interactive objects. The support framework based in interconnected objects and things (IoT) is the bridge that combines technologies and components from micro-systems (miniaturized electric, mechanical, optical and fluid devices) with knowledge, technology and functionality from several areas of research. In other words, the devices have to have embedded capacity to integrate a system, to be capable to interact dynamically having into account proprieties like lower resources and multi-functionality. This paper will focus on the functionality of the smart touching devices for a wide range of dynamic and creative interactive applications, combining low cost and, in some cases, the usage of the same hardware with only a software update.

Related Works

Normally, the touch screens have separated technologies for imaging and touching functionality, [START_REF] Nichols | New Interfaces at the Touch of a Fingertip[END_REF]. The latter is can be embedded in the display using capacitive or resistive membranes. Alternatively, a lateral infrared strip can be used [START_REF] Lee | The multi-touch system with high applicability using tri-axial coordinate infrared LEDs[END_REF] or standard external cameras with sophisticated image recognition can detect the fingertips.

The novelty in this paper is the possibility to transform a standard LED display into a multi-touch, contactless touch and distance touch (e.g., using lasers) with almost no additional costs beyond the display itself, while maintaining a low system complexity, since it needs software modifications and only a few ones in hardware.

Using an LED as an Emitting/Sensing Light Device

Light emitting diodes have a similar exponential current-voltage curve when compared with a normal diode. The main property of an LED is the emission of light with a certain wavelength profile. Interestingly, this device also reacts to incoming photons with the same wavelength, enabling the use of the LED to measure the intensity of that radiation. One of the techniques is to measure a tinny voltage across the LED that is proportional to the intensity radiation. The other one, used in this paper, is based on the behavior of reverse biased pn junction under radiation conditions. When reverse biased, the radiation charges the LED intrinsic capacitor inverse to the radiation, this means that the equivalent capacitor is smaller in high light conditions, and bigger in low light conditions.

To measure the charge in the capacitor after the inverse biased phase, it is important that the measuring current is small. One method mentioned in [START_REF] Dietz | Very low-cost sensing and communication using bidirectional LEDs[END_REF] is using a digital comparison input, counting from the moment that the I/O_1 changes to Highimpedance until a threshold that the microcontroller assumes a LOW value. That count is related to the incoming light intensity on the LED.

Figure 1 shows how to drive a simple LED with two input/output of the microcontroller to enable the switching between emitting and sensing light. To understanding the full behavior of LED when reverse biased, the charge reading process is equivalent to a Resistor-Capacitor (RC) circuit, that the R is the input impedance of the microcontroller, and C the intrinsic capacitor of the LED, and including a parallel of a current source, equivalent to a small leakage current. The electric equivalent in each state is shown in Fig. 2, andin c) shows a resistor that can be added (in grey) to have shorter time constant. This technique has the same power consumption, because the main contribution comes from the forward biasing phase. The operation can be analyzed as a first order RC circuit with a time constant given by, [START_REF] Dietz | Very low-cost sensing and communication using bidirectional LEDs[END_REF] where is the equivalent of the current limiting resistor in series with the parallel of input impedance of microcontroller and the pull-down high-impedance resistor (if needed) to allow the adjustment of , and consecutively due to equation [START_REF] Dietz | Very low-cost sensing and communication using bidirectional LEDs[END_REF], and the intrinsic LED capacitance.

The implementation using an RGB LED has to enter, firstly, into a pre-calibration step to adjust the sensitivity in relation to each color. The lenses in some types of LEDs are used to mix colors, which introduce an additional degradation factor to sense light. The pre-calibration step will adapt the firmware of the microcontroller to adjust the sensing sensitivity when red, green or blue lights are within the detection range, or the combination of them.

Bidirectional LED Array for an Interactive Interface

When the goal is to have the largest possible number of LEDs with just one microcontroller, a non-inverter driver can be used drive at the same time an entire row. This is needed because the microcontroller outputs are not capable to drive all LEDs in a row. However, to allow emitting and sensing light at the same instant, only two rows are used, while the others must be in high-impedance to not interfere in the measurements, meaning that the driver can be a tri-state type (Fig. 3).

ENB

Out [START_REF] Dietz | Very low-cost sensing and communication using bidirectional LEDs[END_REF] I/O [START_REF] Dietz | Very low-cost sensing and communication using bidirectional LEDs[END_REF][START_REF] Hudson | Using light emitting diode arrays as touch-sensitive input and output devices[END_REF] An issue to take into account is the refresh rate of the total LED matrix, which has to be higher than 100 Hz to be undetectable by the human eye. On lower light conditions (bigger time constant), it should be defined a fixed maximum time to each operation and if the time constant is still too high a proper resistance value has be selected to obtain shorter discharges (grey in Fig. 2. c)). In higher light conditions, the precision depends on the comparison rate of the microcontroller.

The matrix in Fig. 4 is a model that can be configured depending on inputs/outputs available on microcontroller, wherein two outputs are used for each row and an I/O for each column. The time for each cycle goes from the beginning of the frame received from master controller, Fig. 5, until light emission mode, receive mode, or both be completely performed for each LED.

For the first case, light emission mode, the controller output that controls the row through the tri-state driver puts the logical HIGH value, while the outputs directly connected to current limiting resistors generate a PWM with the desired Duty-Cycle for a certain time. The cycle ends when all rows are covered.

In the case that only is needed to measure the ambient light, the process is similar, but now it is necessary to impose the LOW value in the row, and HIGH value in each column to charge the intrinsic capacitor. Only after, the measurement of the charge accumulated in the junction of each LED in that row is taken. Note that the measuring light occurs from all LEDs in the row at the same time, and when some finishes, the microcontroller waits a programmed guard time. The cycle finishes when all LEDs are measured and that values are sent to a master controller.

When the microcontroller enters into a emit and read modes, first it has send the frame containing all PWM values for each LED, and after that, the first row is taken HIGH, while the odd columns are generating PWM. The sensing is made in the LED in the diagonal immediately at lower right position, while the other rows are in highimpedance state. After that, the other rows should have the same behavior, until the last one does not have any LED around in a sensing state, because that row is emitting (odd columns), and the first one is sensing (even-numbered columns)., This is made keeping in mind that the LED matrix can be surrounded by another one, in large display structure. Yet it is necessary to maintain the same behavior, but now emitting in even-numbered columns and sensing in odd columns. Finally, each value sensed should be sent to a master controller. Figure 5 shows how to connect multiple modules, creating an interactive display controlled by a master controller or a simple computer, all this through a serial communication link.

Out[1] Out[2] LED1_6 LED1_5 LED1_4 LED1_3 LED1_2 LED1_1 LED2_6 LED2_5 LED2_4 LED2_3 LED2_2 LED2_1 Out[3] Out[4] LED3_6 LED3_5 LED3_4 LED3_3 LED3_2 LED3_1 LED4_6 LED4_5 LED4_4 LED4_3 LED4_2 LED4_1 Out[5] Out[6] LED5_6 LED5_5 LED5_4 LED5_3 LED5_2 LED5_1 LED6_6 LED6_5 LED6_4 LED6_3 LED6_2 LED6_1 I/O[1] I/O[2] I/O[3] I/O[4] I/O[5] I/O[6]

Experimental Evaluation of the Proposed Matrix

To validate the proposed LED matrix, a single array of six basic red LEDs of three millimeters were designed and implemented. The green LED also was tested, and have basically the same behavior. The microcontroller used was the ATmega328, from Atmel. Figure 6 shows the schematic assembly of the LED array prototype, in which 'Out_1' is driven by a noninverter similar to Fig. 3, but without ENABLE since an Hi-Z state is not need for a one row configuration. The setup used is similar to Fig. 5, but having just one module. A serial communication to a virtual environment, created in Matlab, was used to demonstrate the user interactivity.

Remember that the microcontroller only finishes the phase of sensing when all LEDs reaches the threshold voltage, meaning than if one LED arrives at the threshold value the microcontroller waits until the last one, allowing a measured with an oscilloscope than the voltage across the LED measured drops much faster because the ten megohm input impedance.

To determine the time constant, measurements where performed with a digital oscilloscope. Figure 7 shows the measurement results of each phase. In Fig. 7 a), the time constant is the time that the voltage across LED drops from to , but the threshold voltage of microcontroller is around . Through the proportionality rule, which is the value obtained in each measure of Fig. 7, and time constant is 3.5ms and 120ms for high and low light conditions, respectively.

Since the input impedance of microcontroller is in the range of some megohm, these experimental results show that the capacitor is in the range of a few picofarad and near nanofarad in high and low light conditions, respectively. We cannot change this intrinsic values, but adjusting a proper resistor like in Fig. 2 c) in grey, the time constant can be manipulated to boost higher refresh rates. However, for lower refresh times, a faster microcontroller may be needed. Note that these values depends on LED, and microcontroller features.

A real time interactive interface was created to view the values determined by the microcontroller from which a synthetized a musical tone proportional to the proximity distance of a finger, was generated. For example, Fig. 8 b) shows a finger proximity in the third LED. The Matlab demo application consists of a piano synthesizer, in which each LED corresponds to a musical tone, and giving an indication to the user of the tone touched by changing the corresponding LED light intensity (amplitude of the sound level is proportional to the light intensity).

Conclusion

The techniques presented in this paper allows the implementation of contactless LED based matrix smart interactive interface that can operate in a robust way for each application. The information processing may be performed by a computer or a master controller, which enables the setup of large area displays. In each module, each slave microcontroller can be replaced by a System on Chip (SoC) capable of producing the desired outputs for driving each LED, read ambient light and transm. In smaller applications, only one microcontroller can be used to generate their own interactivity.

With this architecture of touch displays, the global cost is almost the same as a normal LED matrix display, with practically the same complexity and a software modification, not forgetting that the consumption remains practically equal due to the small intrinsic capacitors that have to be charged and uncharged to measure light.

Through this system, we expect a touch interface as the important component in these days to provide the high quality of services to users for applying to a variety of applications easily and giving the intuitive interface.

Fig. 1 .

 1 Fig. 1. Schematic of a bidirectional LED.

Fig. 2 .

 2 Fig. 2. Different stages of biasing LED with equivalent electric behavior. a) as light emitting variable. b) reverse bias to charge capacitor. c) read received light.

Figures 2 a

 2 Figures 2 a) to c) show the sequence of emitting and measuring light steps. The case in Fig. 2 b) is needed to charge the LED junction that is related with the incident light.The operation can be analyzed as a first order RC circuit with a time constant given by,

Fig. 3 .

 3 Fig. 3. Schematic of driver for multiple LED array (Tri-State).

Fig. 4 .

 4 Fig. 4. Example model of an LED matrix.

Fig. 5 .

 5 Fig. 5. Interconnection between the LED and master controller through a serial communication.

Fig. 6 .

 6 Fig. 6. LED array setup with MCU.

Fig. 7 .

 7 Fig. 7. Measure of reading time of received light (CH1 cathode of LED, CH2: anode of LED). a) case with high light conditions b) case with low light conditions.

Fig. 8 .

 8 Fig. 8. Measure ambient light (lower value means higher light). a) without light obstruction (ground level). b) with a finger on third LED.