Elaine Cheong

Jie Liu
email: liuj@microsoft.com

galsC: A Language for Event-Driven Embedded Systems

We introduce galsC, a language designed for programming event-driven embedded systems such as sensor networks. galsC implements the TinyGALS programming model. At the local level, software components are linked via synchronous method calls to form actors. At the global level, actors communicate with each other asynchronously via message passing, which separates the flow of control between actors. A complementary model called TinyGUYS is a guarded yet synchronous model designed to allow thread-safe sharing of global state between actors via parameters without explicitly passing messages. The galsC compiler extends the nesC compiler, which allows for better type checking and code generation. Having a well-structured concurrency model at the application level greatly reduces the risk of concurrency errors, such as deadlock and race conditions. The galsC language is implemented on the Berkeley motes and is compatible with the TinyOS/nesC component library. We use a multi-hop wireless sensor network as an example to illustrate the effectiveness of the language.

I. INTRODUCTION

Networked embedded software designers face issues such as managing computation as well as communications, maintaining consistent state across multiple tasks, handling irregular interrupts, avoiding concurrency errors, and conserving power. These tasks become more challenging when the resources of the hardware platforms are too limited, in terms of CPU speed and memory size, to host a full-scale modern operating system. Traditional technologies for developing embedded software, inherited from writing device drivers and from optimizing assembly code to achieve a fast response and a small memory footprint, do not scale with the growing complexity of today's applications. Despite the fact that "high-level" languages such as C and C++ have recently replaced assembly language as the dominant embedded software programming languages, most of these high-level languages are designed for writing sequential programs to run on an operating system and fail to handle concurrency intrinsically.

Event-driven embedded software is more like hardware, where conceptually concurrent components are activated by incoming signals (or events). Event-driven execution is particularly suitable for untethered devices such as sensor network nodes, since the node can be put into a sleep mode to preserve energy when no interesting events are happening. For many networked embedded systems, there is a fundamental gap between this event-driven execution model and sequential programming languages.

The TinyGALS (Globally Asynchronous and Locally Synchronous) programming model [START_REF] Cheong | TinyGALS: A programming model for event-driven embedded systems[END_REF] aims to fill this gap by providing language constructs to systematically build concurrent tasks (called actors).

At the application level, actors communicate with each other asynchronously via message passing. Within each actor, components communicate synchronously via method calls, as in most imperative languages. Thus, the programming model is globally asynchronous and locally synchronous in terms of transfer of the flow of control. In order to incorporate shared variable semantics where only the latest value matters, a set of guarded yet synchronous variables (called TinyGUYS) is provided at the system level for actors to exchange global information "lazily." Access to these variables is thread-safe, yet components can quickly read their values. In this programming model, application developers have precise control over the concurrency in the system, and they can develop software components without the burden of thinking about multiple threads.

In this paper, we introduce galsC, a language that implements the TinyGALS programming model. This new approach is based on the nesC language and compiler [START_REF] Gay | The nesC language: A holistic approach to networked embedded systems[END_REF], and improves on the design in [START_REF] Cheong | TinyGALS: A programming model for event-driven embedded systems[END_REF] in the following aspects:

• A real compiler backend allows the galsC compiler to perform better type checking and code generation. • A novel global variable (TinyGUYS) handling mechanism does not require special parameter access keywords. This makes galsC compatible with all nesC components. • This paper also contains a deeper discussion on concurrency features of galsC, in comparison to [START_REF] Cheong | TinyGALS: A programming model for event-driven embedded systems[END_REF].

The design of galsC is influenced by the trend of introducing formal concurrency models in embedded software. In particular, synchronous languages try to compile away concurrency executions based on the synchronous (zero-execution time) assumption [START_REF] Halbwachs | Synchronous Programming of Reactive Systems[END_REF]. When it is not possible to compile away concurrency, the portbased object (PBO) model [START_REF] Stewart | Design of dynamically reconfigurable real-time software using port-based objects[END_REF] has a global shared variable space mediating component interaction. Various dataflow models [START_REF] Najjar | Advances in the dataflow computational model[END_REF] use FIFO queues to separate flow of control. The POLIS co-design approach [START_REF] Balarin | Synthesis of software programs for embedded control applications[END_REF] uses an event-driven model for both hardware and software executions. To some extent, galsC is closer to systemlevel hardware/software codesign languages, such as SystemC [START_REF] Bhasker | A SystemC Primer[END_REF] and VCC [START_REF] Larue | Functional and performance modeling of concurrency in vcc[END_REF], than embedded software languages such as nesC. galsC provides basic concurrency constructs and generates executable code, including an application-specific operating system scheduler, from high-level specifications. This generative approach allows further analysis of concurrency problems, such as race conditions, at a high level. Automatically generated code also reduces implementation and debugging time, since the developer does not need to reimplement standard constructs (e.g. communication ports, queues, functions, and guards on variables).

The remainder of this paper is organized as follows. Section II describes galsC syntax and semantics, connection model, type checking, and code generation. Section III discusses concurrency issues in galsC programs. Section IV describes a sample application implemented in galsC. We conclude with directions for future work.

II. THE GALSC LANGUAGE

In this section, we overview the galsC syntax and semantics with a simple sensing application (Figure 1). In this example, a hardware clock triggers the system to update a time tick counter. A downsampled clock signal triggers the system to read the light intensity level from a photoresistor at a lower rate. Reading the sensor may take time. The system tags the resulting sensor value with the latest value of the counter and sends it downstream for further processing.

Counter

A. Language constructs

There are three basic constructs in galsC: components, actors, and applications. Components are the most basic elements of a galsC program and are written in the nesC programming language. Components provide and/or require interfaces, which are collections of methods. A component that provides an interface contains an implementation of the interface method(s), whereas a component that requires an interface expects another component to implement the interface. A component is either a module or a configuration. A module contains executed code, whereas a configuration only contains a list of components and the connections between their interface methods. Figure 2 shows the source code for the TimerC configuration, which contains a module named TimerM that implements the provided interface methods.

Actors are the major building blocks of a galsC program and are written in the galsC programming language. The interface of an actor consists of a set of input and/or output ports and a set of parameters. Parameters are global variables that can be both read and written. An actor contains a list of components and connections. A connection can connect a component interface method to one of the following endpoints: (1) another component interface method, (2) a port, (3) a parameter, or (4) some combination of these. We discuss connections in detail in Sections II-C and III. An actor may also contain an actorControl section which exports the StdControl interface of any of its components to the application level for system initialization (e.g. for initializing hardware components). Figure 3 shows the source code for the SenseActor actor.

A galsC program is created by writing a galsC application file that contains zero or more parameters and a list of actors and connections. A connection can connect application parameters (global names) with actor parameters (local names). A connection can also connect actor output ports with actor input ports, with an optional declaration of the port queue size (defaults to size 1). Figure 3 shows the source code for the SenseTag application.

B. Language semantics

Generally speaking, galsC implements the TinyGALS programming model as described in [START_REF] Cheong | TinyGALS: A programming model for event-driven embedded systems[END_REF], which we summarize here. We have also developed an improved way to handle TinyGUYS (parameters), which differs from the model described in [START_REF] Cheong | TinyGALS: A programming model for event-driven embedded systems[END_REF].

1) Ports: Each input port of an actor has a FIFO queue. Communication between actors occurs asynchronously through these queues. When a component within an actor calls a method that is linked to an output port, the arguments of the call are converted into events called tokens. A copy of the token is placed in the event queue of each input port connected to the output port. Later, the scheduler removes the token from the queue and calls the method that is linked to the input port with the contents of the token as its arguments. Thus, the queue separates the flow of control between the actors; the call to the output port returns immediately, and the component within the actor can proceed. The scheduler processes tokens in the order in which they are generated. Tokens are dropped if the input port queue is full; the programmer is currently responsible for selecting the correct size.

2) Parameters: The TinyGALS programming model has the advantages that actors become decoupled through message passing and are easy to develop independently. However, each message passed will trigger the scheduler and activate a receiving actor, which may quickly become inefficient if there is global state that must be updated frequently. The TinyGUYS (Guarded Yet Synchronous) mechanism provides a way for actors to share global data safely. This is implemented as the parameter feature in the galsC programming language.

With the TinyGUYS mechanism, actors may read a parameter synchronously (without delay). However, writes to the parameter are asynchronous in the sense that all writes are buffered. The buffer is of size one, so that the last writer to the parameter wins. Parameters are updated by the scheduler only when it is safe (i.e., after an actor finishes executing and before the scheduler triggers the next actor).

Parameters have global names that are mapped to the local parameter names of each actor. In the new TinyGUYS mechanism, a component interface method or an actor port can write to a parameter by calling a connected function with a single argument. Parameter values can be read by passing them as arguments to component interface methods or actor ports. In SenseActor in Figure 3, the count parameter is passed as the last argument to the output port. This design does not require parameter names to appear inside the component name space. One can develop components in their own scope, independent of the connected parameters. We no longer require components to use special methods to access global variables, which greatly improves the reusability of components.

C. Connection model within actors

A connection x → y inside an actor consists of a source x and a target y. 1 We use regular expressions to describe possible entities of x and y:

source = (l) * (p | f ) (l) * (1) target = l | p | f ( 2
)
where l is the local name of a parameter, p is an actor port name, and f is a component interface function. A trigger is a port or function that appears as the source of a connection. A port is triggered when the scheduler invokes it with the first token in its queue. A function is triggered when it is called by another function.

A connection x → y is valid if the number of arguments and the types of the arguments of the source match those of the target when the arguments on each side of the arrow are concatenated separately, similar to the notion of record types [START_REF] Wand | Type inference for record concatenation and multiple inheritance[END_REF]. Additionally, a source port must be an input port and a target port must be an output port, and a source function must be a required method and a target function must be a provided method. The return type of a trigger must also match that of the target.

For example, suppose f1 is a required method with exactly two arguments. (f1, l1) → p1 is valid if p1 is an output port that has exactly three arguments whose types match those of the left hand side (i.e., the types of the first two arguments of p1 must match those of f1, and the type of the last argument of p1 must match that of l1) and if the return type of f1 matches that of p1.

Using our regular expression model, we have the following valid types of connections, where l in (t, l) is an abbreviation for any number of parameters appearing before or after the trigger t:

No parameters p1 → p2 p1 → f1 f1 → p1 f1 → f2 Param GET (p1, l) → p2 (f1, l) → p1 (p1, l) → f1 (f1, l) → f2 Param PUT p → l f → l Param GET/PUT (p, l1) → l2 (f, l1) → l2
For connections with no parameters, the trigger will (a) trigger the connected function or (b) pass a token to the connected output port. In a parameter GET connection, the parameter value(s) will be appended to the trigger's argument list and passed to the connected function or port. In a parameter PUT connection, the trigger will write its argument to the parameter. In a parameter GET/PUT connection, the trigger will cause the source parameter to be read and its value stored in the target parameter. Note that for the number of arguments to match, the trigger in a parameter PUT connection must have only one argument, and the trigger in a parameter GET/PUT connection must have no arguments.

What are the semantics of multiple connections (i.e., fanout from a function)? For example, what is the order of computation when you have f1 → l1 and f1 → f2? Or when you have f1 → l1 and f1 → p? In galsC, the write to the parameter occurs first, before any additional computation or transfer of control. The buffered parameter value may then get overwritten in the later computation. This policy gives us a consistent view of ordering in the system.

D. Type inference and type checking

The galsC compiler performs high level type inferencing on the connection graph of an application. There are two parts to the type inference system: connections with ports, and connections with parameters but no ports. 21) Ports: In galsC, ports are untyped. The actual types of ports are inferred from the connection graph of a galsC program. In figure 4, an actor A contains a component which has a call to function f with type signature τ1. The input port of actor B is the target of the concatenation of the output port of A with a parameter with type τ3. The known types (τ1, τ3, τ5, τ8) are shown in bold. We write a type equation for each connection in the system:

τ1 = τ2 (3) τ2 × τ3 = τ4 (4) τ4 × τ5 = τ6 (5) τ6 = τ7 (6) τ7 = τ8 (7)
We can then solve the set of equations to determine the types of the ports. A valid system has a unique solution to the set of equations. The galsC compiler derives types for all ports in the system by matching the return type and the argument types of all connected upstream and downstream functions. The galsC compiler detects a type error when the set of equations conflicts with itself or is unsolvable.

2) Parameters: The type system for parameter connections without ports is straightforward, since there are only two types of connections: (1) connections between a global name and a local name, and (2) connections between a function and a local name. Since the types of all these sources and targets are known, the type checker merely verifies that all the types in a connection match.

E. Code generation

The highly structured architecture of galsC programs enables us to automatically generate the communication and scheduling code, allowing software developers to avoid writing error-prone concurrency control code. We have extended the nesC 1.1.1 toolset [START_REF]nesC compiler[END_REF]. The resulting galsC toolset can compile both nesC and galsC programs and its output can be cross-compiled for any platform used with TinyOS [START_REF]TinyOS: a component-based OS for the networked sensor regime[END_REF], including the Berkeley motes [12].

The TinyGALS code generation tools described in [START_REF] Cheong | TinyGALS: A programming model for event-driven embedded systems[END_REF], were compatible with TinyOS 0.6.1 and were implemented in perl and generated stylized C (using C preprocessor macros). The galsC compiler, on the other hand, takes advantage of a real compiler backend. It uses traditional compiler techniques, including type checking, dead code elimination, and function inlining. We have modified the datarace detection feature of nesC, since the decoupling of execution through ports eliminates some possible sources of race conditions.

galsC provides an improved programming model in exchange for a minimal application-dependent increase in code size for scheduling and communication between actors [START_REF] Cheong | galsC: A language for event-driven embedded systems[END_REF]. For a simple photosensor application, the initialization and scheduling code is 662 bytes compared to 564 bytes for the original nesC code. The get() and put() functions for a port of type uint8_t use 208 bytes. The get() and put() functions for a parameter of type uint16_t use 30 bytes. The scheduler event queue size is equal to the sum of the user-allocated size for each port connection (depends on the size of the data type).

III. CONCURRENCY ISSUES

Concurrency management is a significant concern in event-driven systems. Poorly implemented systems may suffer from deadlock (i.e. where no tasks can proceed due to blocking on a shared resource), livelock (i.e. where the system falls into deadloop and responds to no further interrupts), and race conditions (i.e. where shared variables are accessed by multiple threads at the same time).

In this paper, we only consider concurrency issues on single processor platforms. In galsC, all memory is statically allocated; there is no dynamic memory allocation. A galsC program runs in a single thread of execution (single stack), which may be interrupted by the hardware. An actor A may begin execution when: (1) the scheduler activates A in response to an event in its input port, or (2) an interrupt service component within A is triggered by an external interrupt. The execution triggered by interrupts is called the interrupt context, and the execution activated by the scheduler is called the scheduled context. Interrupt handlers preempt scheduled executions, which is the only source of concurrent execution in galsC. Our system-level concurrency model allows us to manage the concurrency issues discussed earlier.

A. Cross-actor concurrency

Since all scheduled executions of actors are in the scheduled context and controlled sequentially by the scheduler, the only possibility for cross-actor concurrent execution is when one actor is in the scheduled context, and one or more other actors are in an interrupt context.

There are two mechanisms for actors to communicate in galsC: event queues (ports) and guarded global variables. Blocking on shared resources (e.g., a blocking read) is not part of the semantics across actors, which gives us:

Theorem 1: Deadlock is not possible across actors.

In event-driven systems, since there are critical system operations, such as enqueuing and dequeuing events, which are atomic, it is possible for a scheduler to retain control and disable interrupts indefinitely. In Figure 5, the Loop actor is first triggered by an internal interrupt, which produces an event (token) at the output port. The event loops back to the input port where it is inserted into the event queue. Interestingly, there is a direct link between the input port and the output port inside the actor. Can this self-loop prevent further interrupts from entering the system? Once the event is enqueued, the scheduler (1) dequeues the event, with interrupts disabled and (2) calls the function connected to the inside of the input port, in this case the put() function of the output port. Within the put() function, the code that inserts the event back into the event queue is also atomic. So, without a careful implementation of the scheduler, there is a risk of livelock. However, in the galsC scheduler, interrupts are enabled between dequeuing the event and enqueuing the event, so future interrupts will not be blocked, which gives us:

Theorem 2: Livelock is not possible across actors. Race conditions are another major concurrency concern. Since there are shared data between actors, an actor may be in the middle of writing the data when another actor tries to read it. Two actors may also try to write to a shared variable at the same time.

There are two forms of shared data across actors: tokens and parameters. Tokens are stored in event queues, and access to them is atomic and controlled by the scheduler. Parameters, as discussed in the previous section, are always guarded, whose value updates are again controlled by the scheduler (where the last value written wins). Thus, Theorem 3: Race conditions are not possible across actors.

As a result of these claims, concurrency errors will not happen at the application level across actors. So, programmers can focus on concurrency issues within each actor, which is a problem with a much smaller scope.

B. Component-level concurrency

Concurrent execution may occur within actors if multiple threads of control enter the same component through its input ports or interrupt handlers. Problems may occur if they try to change the component state at the same time.

A piece of code is reentrant if multiple simultaneous, interleaved, or nested invocations do not interfere with each other. We assume that interrupts handlers are not reentrant, and that interrupts are masked while servicing them (interleaved invocations of the same interrupt are disabled). However, other (different) interrupts may occur while servicing an interrupt. Hardware interrupts are the only sources of preemption.

A component C may begin execution if: (1) the hardware that C encapsulates interrupts (C is a "source component"), [START_REF] Gay | The nesC language: A holistic approach to networked embedded systems[END_REF] an event arrives on the actor input port linked to one of the interface methods of C ("triggered component"), or (3) another component calls one of the interface methods of C ("called component"). Once activated, a component executes to completion. That is, the interrupt service routine or method finishes.

Reentrancy problems may arise if a component is both a source component and a triggered component. An event on a linked actor input port may trigger the execution of a component method. While the method runs, an interrupt may arrive, leading to possible race conditions if the interrupt modifies internal variables of the same component.

Cycles within actors (between components) are not allowed, otherwise reentrant components are required. 3 Therefore, any valid configurations of components within an actor can be modeled as a directed acyclic graph (DAG). A source DAG is formed by starting with a source component and following all forward links between it and other components in the actor (Figure 6(a)). A triggered DAG is similar to a source DAG but starts with a triggered component instead (Figure 6 to the triggered DAG (C2, C3). Race conditions and reentrancy problems may occur if C3 is running in a scheduled context and an interrupt causes C1 to preempt C3. We can relax the restriction on cycles between components and only disallow cycles in method call chains between components by first separating the methods within a component into separate source and triggered components. If all interrupts are masked during interrupt handling (interrupts are disabled), then we need not place any additional restrictions on source DAGs. However, if interrupts are not masked (interrupts are enabled), then a source DAG must not be connected to any other source DAG within the same actor. Triggered DAGs can be connected to other triggered DAGs, since with a single thread of execution, it is not possible for a triggered component to preempt a component in any other triggered DAG.

Some configurations of connections between component methods and actor ports may lead to nondeterministic component firing order. Let us first assume that both actor input ports and actor output ports are totally ordered (we use the order specified in the port section of the galsC actor file), but that components are not ordered. Then actor input ports may either be associated with one (provided) method of a single component C or with one or more actor output ports. Likewise, outgoing component methods (required) may be associated with either one (provided) method of a single component C or with one or more actor output ports. 4 Provided component methods may be associated with any number or combination of required component methods and actor input ports, but they may not be associated with actor output ports. Likewise, actor output ports may be associated with any number or combination of required component methods and actor output ports. However, if we assume that neither actor input ports nor actor output ports are ordered, then actor input ports and outgoing component methods may only be associated with either a single method or with a single output port.

The components within a single galsC actor must satisfy the following conditions to be well-formed and avoid concurrency problems:

• Source components may not also be triggered components nor called components. • Cycles among components within an actor are not allowed, but loops around actors are allowed. • Input ports may be associated with 1 method of a single component, or with ≥1 output ports.

C. Determinacy

Notice that lacking of concurrency errors does not mean galsC programs are deterministic. The system state of a galsC program consists of (1) the internal state of all components, (2) the contents of the global event queue5 and (3) the values of all global parameters. The question of determinacy is that given a unique initial state of a galsC program and a set of known interrupts (in terms of both interrupt time and value), will the program have a unique state trajectory independent of the execution/CPU speed? Note that single thread sequential programs, where all inputs are read into the system, are determinate. Concurrent models, such as Kahn process networks, which sacrifices real-time properties, can also be determinate [START_REF] Kahn | The semantics of a simple language for parallel programming[END_REF]. However, for event-driven systems, determinacy may be sacrificed for reactiveness.

In general, a galsC program is non-determinate. The source of non-determinacy is the preemptive handling of interrupts. Suppose that while an actor is being iterated, it is interrupted by another actor. If both of these actors produce events at their output ports, the order of events in the global event queue may not be consistent when the system is executed at different speeds. If both of these actors write to a global variable (i.e. parameter), then without exact timing information, we cannot predict the final value of the global variable at the end of the iteration.

IV. EXAMPLE

To illustrate the effectiveness of the galsC language, let us consider a classical sensor network application that detects and monitors pointsource targets. A set of sensor nodes (called motes) are deployed in a 2-D field. To simplify the discussion, we assume that the motes are deployed on a perturbed grid, as shown in Figure 7(a). The goal of the sensor network is to detect moving objects modeled as point signal sources, and to report the detection to a central base station, located at the lower-left corner of the field. Please note that the goal here is to illustrate the language, rather than to develop sophisticated algorithms to solve the problem optimally.

We assume that the motes know their locations on the grid and the grid size. The application primarily consists of two tasks: exchanging local sensor readings to determine the "leader" responsible for reporting a detection, and multi-hop forwarding of the report messages to the base station. For simplicity, the leader election is achieved by having every mote periodically broadcast a packet containing the location of the mote and its sensor reading. These packets also serve as beacons to establish a multi-hop routing structure.

The multi-hop routing is implemented as a routing tree rooted at the base station. Assume that no mote has the global topology of the network; a mote finds out its parent in the tree by eavesdropping on other messages. These messages include sensor reading broadcasts and forwarded report messages. Every message contains the hop count of the sender, which indicates the level of the sender in the routing tree. For example, the mote directly connected to the base station has hop count 0. Whenever it broadcasts a message, everyone who can overhear the message will note that it is probably one hop away from the base station. As illustrated by the dashed line in Figure 7(a), the reachable nodes of a wireless broadcast may have a complicated shape. To compensate for the unreliable and sometimes asymmetric wireless communication links, a mote maintains a list of senders it has heard in the past T seconds and chooses the most reliable one (measured by, for example, a trade-off between low hop count and message repeatability) as its parent node. It then calculates its own hop count from its parent's hop count.

A high-level view of the implementation of the object detection application in galsC is shown in Figure 7(b). All motes run the identical code modular to their locations. The execution of a mote is driven by two event sources -clock interrupts and received messages. Similar to the example in Figure 1, the TimerActor handles clock interrupts and updates the latest timer count in a parameter named timeCount. Every half second, TimerActor emits a token that triggers the SenseAndSend actor.

The MessageReceiver actor receives messages from the radio and chooses an action based on the message type:

• If the message is a local broadcast, it updates the neighborReadings table. Note that since only the latest neighbor sensor reading matters, the overriding semantics of TinyGUYS variables is a natural fit. • Also for each broadcast message, it updates an internal routing table by looking at the repetition frequency of the sender node. Note that it requires the timeCount value to determine the rate of the messages heard. Whenever there is a change of the desired parent node, and thus this node's hop count, it updates the parentNode and hopCount parameters. • If the message is a forwarding message, it sends the content of the message to the downstream MessageForwarder actor. The SenseAndSend actor activates the ADC to get a sensor reading. Once the sensor reading is available, it queues a local broadcast of the sensor reading. It also compares its own reading with the latest values from its neighbors. 6 If this mote has the highest sensor reading (i.e. it is closest to the signal source), SenseAndSend generates a report message and queues it with the MessageForwarder actor.

Both the LocalBroadcast actor and the MessageForwarder actor send out packets with this mote's hopCount so that other motes can use it to build the multi-hop routing tree. The MessageForward actor also takes the parentNode ID as part of the input token, merged with the requests from SenseAndSend and MessageReceiver.

V. CONCLUSION AND FUTURE WORK

This paper describes galsC, a language for event-driven embedded systems that allows developers to use high-level constructs such as ports and parameters to create thread-safe, multitasking programs. We have created a type system for checking connections across synchronous and asynchronous communication boundaries. The galsC compiler automatically generates communication and scheduling code for programs specified in the galsC language, which allows developers to avoid writing error-prone task synchronization code. Our compiler backend also allows traditional type checking, dead code elimination, and function inlining, as well as checking for possible race conditions. The language and compiler are implemented for the Berkeley motes and extend TinyOS/nesC by providing a higher level programming abstraction than the TinyOS primitives.

There are several directions for further research. Currently, developers must use trial and error to find appropriate port queue sizes to avoid token loss when the buffers are full. We could instrument the generated galsC code and scheduler to determine the rate at which tokens are generated and automatically determine the best queue sizes for the application.

Ptolemy II (ptII) [START_REF]The Ptolemy project[END_REF] is a Java-based system for modeling and simulating heterogeneous concurrent systems. We could generate galsC/nesC code from within ptII, allowing programmers to model and simulate within a graphical interface and move seamlessly to running programs in the field. The message passing and parameter semantics of galsC can support many other models of computation in ptII, such as synchronous dataflow, discrete event, Kahn process networks, and Giotto. galsC code generated from ptII could contain a replacement scheduler to implement these other models of computation, while taking advantage of its system-level type system [START_REF] Lee | System-level types for component-based design[END_REF].

The current galsC language and compiler only address programs running on a single node. Communication across multiple nodes is a natural extension of asynchronous communication in galsC between actors on a single node. Developers could then write programs for entire sensor networks, rather than programs for individual nodes, which can be difficult and unintuitive without specialized knowledge about the specific node and its interactions with other nodes.

Fig. 1 .

 1 Photo

Fig. 3 .

 3 Fig. 3. Source code for the SenseActor actor and the SenseTag application.

5 Fig. 4 .

 54 Fig. 4. Type checking example.

Fig. 5 .

 5 Fig. 5. A self-loop actor triggered by an interrupt.

Fig. 6 .

 6 Fig. 6. a) Source DAG b) Triggered DAG c) Source DAG & triggered DAG

•Fig. 7 .

 7 Fig. 7. a) Sensor array for object detection and reporting. b) Top-level, per-node view of the object detection application.

  Fig. 2. Source code for the TimerC and TimerM components.

		actor SenseActor {	application SenseTag {
		port {	parameter {
		in trigger;	uint16_t count = 0;
		out output;	} implementation {
		} parameter {	actor TimerActor, SenseActor,
		uint16_t count;	...;
		} implementation {
		components SenseToInt, Photo;	count = TimerActor.count;
			count = SenseActor.count;
		SenseToInt.ADC -> Photo;
		SenseToInt.ADCControl -> Photo;	TimerActor.trigger =[64]=>
			SenseActor.trigger;
		trigger -> SenseToInt.trigger;	SenseActor.output => ...;
		(SenseToInt.IntOutput.output,	appstart {
		count) -> output;	SenseActor.trigger();
			}
		actorControl {	}
		SenseToInt.StdControl;	}
		}
		}
		}
	configuration TimerC {	module TimerM {
	provides interface Timer[uint8_t id];	provides interface Timer[uint8_t id];
	provides interface StdControl;	provides interface StdControl;
	} implementation {	uses interface Clock;
	components TimerM, ClockC, ...;	...
	TimerM.Clock -> ClockC; ...	} implementation {
	StdControl = TimerM.StdControl;	// Interface implementation...
	Timer = TimerM.Timer;	}
	}

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05)

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE

This model also applies to connections at the application level. However, the discussed port directions must be reversed: a source port must be an output port and a target port must be an input port. Global parameter names should be used instead of local parameter names.

Connections containing only functions are checked with the nesC type checker. Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05)

Recursion within components is allowed. However, the recursion must be bounded for the system to be live. Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE

In the existing TinyOS constructs, one caller (outgoing component method) can have multiple callees. The interpretation is that when the caller calls, all the callees will be called in a possibly non-deterministic order. A combination of the callees' return values will be returned to the caller. Although multiple callees are not part of the TinyGALS semantics, it is supported by our software tools for TinyOS compatibility.

The global event queue is defined as the ordered sequence of tokens in the event queues of all actor ports. Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE

Here, the neighbors are defined as the motes directly above, below, left, and right of this mote in the grid.

* This work was supported in part by an Intel Open Collaborative Research Fellowship, PARC (Palo Alto Research Center), and UC Berkeley CHESS (Center for Hybrid and Embedded Software Systems). We would like to thank David Gay (Intel Research Berkeley) for nesC, enabling our extension to the nesC compiler, and contributions to the connection model; Edward A. Lee and members of the Ptolemy Project (UC Berkeley


Tadashi Takeuchi
email: t-takeu@sdl.hitachi.co.jp

OS Debugging Method Using a Lightweight Virtual Machine Monitor

Demands for implementing original OSs that can achieve high I/O performance on PC/AT compatible hardware have recently been increasing, but conventional OS debugging environments have not been able to simultaneously assure their stability, be easily customized to new OSs and new I/O devices, and assure efficient execution of I/O operations. We therefore developed a novel OS debugging method using a lightweight virtual machine. We evaluated this debugging method experimentally and confirmed that it can transfer data about 5.4 times as fast as the conventional virtual machine monitor.

Introduction

Many appliance servers using original real-time operating systems (OSs) and achieving high-performance I/O on PC/AT compatible hardware have been marketed recently. One result of this trend is increasing demand for efficient debugging environments for original OSs to support various I/O devices and efficient debugging mechanisms monitoring the OS status tracing even while the OS is executing high-throughput I/O operations.

Because the vendors of PC/AT-compatible hardware do not provide debugging hardware such as ICE, the only debugging environments available for operating systems running on PCs are a hardware simulator working with a software debugger, a software remote debugger, and a software debugger embedded in the operating system under development. These environments, however, cannot simultaneously assure their stability when the operating system under development does not perform properly, be easily customized for different operating systems and new I/O devices, and assure efficient execution of I/O operations.

We therefore developed a novel OS debugging environment and method that can satisfy the above three demands simultaneously by using a lightweight virtual machine monitor. In this paper, we describe our new environment and method and report the results of experiments comparing its performance with that of conventional debugging environments.

Debugging Method

Our new debugging method provides the debugging environment shown in Fig. 2

Real Hardware Interfaces

Original OS

Indirect access

Other I/O devices

Direct access

Lightweight Virtual Machine Monitor Host Machine Target Machine

Figure 2.1 Architecture of debugging environment

The architecture of our debugging environment is similar to the one used for conventional remote debugging. It consists of a host machine and a target machine. A software remote debugger running on the host machine receives debugging commands (target machine memory/register reference/updating, etc.) from a user and sends the command to the target machine

The target machine architecture differs from that of classical software remote debugging in that a lightweight virtual machine monitor implemented independently of original OSs is embedded in it. The monitor provides remote debugging functions such as reception and execution of the debugging commands. The monitor also provides a partial hardware emulation mechanism. It emulates only the hardware resources used by the remote debugging function (such as the interruption controller or interruption-handling table). The monitor provides the same interfaces as the real hardware, so it can work with any OSs running on PC/AT architectures.

The hardware resources used by the remote debugging functions are accessed by the original OS via the lightweight virtual machine monitor, so stability of the debugging environment can be assured because the real hardware remain in normal states even if the original OS works improperly because it has bugs. The other devices, however, especially high-throughput I/O devices (such as a SCSI controller or Ethernet controller) can be accessed directly by the original OS. This direct access enables I/O operations to be executed efficiently in this debugging environment. The direct access also makes it unnecessary for the monitor to emulate the high-throughput I/O devices, so this debugging environment can be used with various I/O devices without being customized.

This lightweight virtual machine monitor also provides a lightweight mechanism protecting memory regions. Even though x86 architecture provides two level memory protection mechanism, it can provide memory protection at three levels: that of the application on the original OS, that of the original OS, and that of the lightweight virtual machine monitor. This mechanism enables the remote debugging functions to continue working properly even when the application or the original OS executes illegal memory accesses to regions used by the monitor.

Performance Evaluation

We evaluated the performance of the lightweight virtual machine monitor by measuring the I/O performance of our original OS, the HiTactix, running on this monitor.

We ran the HiTactix OS on the following three PC/AT-compatible systems with 1.26GHz Pentium III 1 processors: real hardware, the lightweight virtual machine monitor, and a VMware 2 Workstation 4 [START_REF] Sugerman | Virtualizing I/O Devices on VMware Workstation's Hosted Virtual Machine Monitor[END_REF] for Linux. The VMware Workstation 4 is a typical example of a conventional virtual machine monitor for PC/AT compatible architecture that supports various I/O devices. On each of the systems running HiTactix, we executed a data-transfer application that reads 2MB data from three Ultra 160 SCSI disks at constant rates, splits them into 1024KB segments, and sends all segments via gigabit Ethernet using the UDP protocol. We measured the CPU load variations when we changed the data reading and transferring rates. Comparing the load variations measured for the different systems, we evaluated how much I/O The measurement results plotted in Fig. 3.1 show that our lightweight virtual machine monitor can transfer data 5.4 times as fast as a VMware Workstation 4 , but they also show that our monitor can transfer data at only about one fourth (26%) of the rate it can be transferred by real hardware.

Conclusion

This paper describes a novel OS debugging method and environment that can assure the stability of the debugging environment, be easily customized to a new OS or to a new I/O device, and assures efficient execution of I/O operations.

We evaluated the I/O performance provided by our proposed monitor and confirmed that the monitor can transfer data 5.4 times faster than a conventional virtual monitor.

  Figure 3.1 Measured CPU load

  .1.

			Target Machine
				Original OS
			Indirect		Direct
			access		access
			Real Hardware Interfaces
	Host Machine	Lightweight Virtual Machine Monitor
	Software remote debugger General-purpose OS Software remote debugger General-purpose OS	Remote debugging functions (Stub) Remote debugging functions (Stub)	Interruption-controller emulator Interruption-controller emulator	Timer emulator Timer emulator	CPU-resources emulator Page/ interruption CPU-resources emulator Page/ interruption
	Communi-cation Device Communi-cation Device	Communi-cation device Communi-cation device	Interruption controller Interruption controller	Timer Timer	handling table, etc. handling table, etc.	Other I/O devices
	Debugging commands Debugging commands

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE


Annie Pauzié
email: annie.pauzie@ifsttar.fr

Manuela Quaresma

Evaluation of a collaborative mobile application for driver

Keywords: Human Mobile Interaction, Driver safety, Social network in transport

An increase number of drivers are able to engage activities on their smart phone nowadays. On one hand, road safety issues of driver's distraction and smartphone use are crucial. On the other hand, easy access to real time road critical information could contribute to drivers' safety and comfort. After presenting driving performance decrement in relation to phone use, this paper gathers data from a survey investigating drivers' motivations in using a mobile application informing the driver about road danger or unexpected events. Covered issues are dealing with reliability of the transmitted information via the collaborative service and level of drivers' trust and participation. Results showed that participation level is motivated by willingness to make the collaborative system working in addition to solidarity with the community. Senior drivers are also motivated to use the service. This study allows a better understanding of motivation of smartphone use by the drivers 'community; further research investigations are required to find out how to answer to these needs without interfering with road safety requirements.

Introduction

Mobile phones have recently undergone a substantial change and 'smartphones' have gained popularity and allow users to take part in a much broader range of activities than traditional mobile phones, including browsing the web, emailing, social networking, and browsing and playing personal media. In 2015, there are about 1,91 billion smartphone users worldwide (figure 1). In relation to this deployment of smartphone, there is a corresponding increase access to sophisticated services such as internet and geo-localisation [START_REF] Smith | 35% of American adults own a Smartphone[END_REF]. In this context, with 'smartphones' now becoming common in the commercial marketplace, more and more drivers are able to engage in a broad range of possible activities on their phone. There is a clear potential for motorists to be tempted to conduct these activities whilst driving a vehicle, inducing distraction in managing the main task. On-road studies shown just how salient a factor distraction is in crashes. NHTSA's 100-Car Naturalistic Driving Study showed that engagement in a secondary task contributed to more than 22% of all crashes and near-crashes that were recorded in the study period [START_REF] Klauer | The Impact of Driver Inattention on Near-crash/crash risk: An Analysis using the 100-Car Naturalistic Driving Study Data[END_REF].

Distracting effect of smartphone use while driving

As more in-vehicle and portable devices proliferate the market, there has been growing concern regarding the safety implications of using such devices while driving. In response, a large and rapidly growing body of research has examined the impact of mobile phones on driving performance [START_REF] Young | Driver distraction: A review of the literature[END_REF] and distraction effects, even when using GPS [START_REF] Quaresma | Usability analysis of smartphone applications for drivers[END_REF] Using smartphone while driving has several impacts on the human performance:

• Increased ratings of mental workload [START_REF] Parkes | Conversations in cars: the relative hazards of mobile phones[END_REF][START_REF] Lesch | Driving performance during concurrent cell-phone use: are drivers aware of their performance decrements?[END_REF][START_REF] Burns | How dangerous is driving with a mobile phone? Benchmarking the impairment to alcohol[END_REF][START_REF] Parkes | Car phone use and motorway driving[END_REF] • A reduction in people's perceptual visual fields by up to 10% [START_REF] Maples | The effects of cell phone use on peripheral vision[END_REF] • Longer glances ahead, at the expense of other monitoring behaviors such as checking the mirrors and vehicle instruments [START_REF] Quaresma | Usability analysis of smartphone applications for drivers[END_REF][START_REF] Harbluk | The impact of cognitive distraction on driver visual behaviour and vehicle control[END_REF] • Poorer awareness of and response to the traffic situation [START_REF] Parkes | Conversations in cars: the relative hazards of mobile phones[END_REF][START_REF] Parkes | Internet Forum on 'The safety impact of driver distraction using in-vehicle devices[END_REF] despite longer glances ahead

• Slower detection of and responses to hazards [START_REF] Caird | A meta-analysis of the effects of cell phones on driver performance[END_REF] • A reduction in speed in an attempt to compensate for the perceived impairment caused by using a phone [START_REF] Reed | The effect of text messaging on driver behaviour: a simulator study[END_REF][START_REF] Burns | How dangerous is driving with a mobile phone? Benchmarking the impairment to alcohol[END_REF] Driver performance is impaired by the concurrent smartphone task (the smartphone task can also be affected by driving): unable to maintain a central lane position and this resulted in an increased number of unintentional lane departures, unable to respond as quickly to a lead vehicle gradually changing speed, thus driving at a more variable time headway. Furthermore, research has shown that older drivers' driving performance is impaired to a greater degree than younger drivers when using a mobile phone [START_REF] Alm | The effects of a mobile telephone task on driver behaviour in a car following situation[END_REF][START_REF] Lamble | Mobile phone use while driving: public opinions on restrictions[END_REF]. In this context, compensatory or adaptive driver's behavior can occur at a number of levels ranging from the strategic (e.g., choosing adequate time such as low workload context to use the mobile phone while driving) to the operational level. In this second case, it can be by reducing [START_REF] Poysti | Factors influencing the use of mobile phone during driving and hazards while using it[END_REF], increasing inter-vehicular distance [START_REF] Strayer | A comparison of the cell phone driver and the drunk driver[END_REF][START_REF] Strayer | Driven to distraction: Dual-task studies of simulated driving and conversing on a cellular telephone[END_REF], changing the relative amount of attention given to the driving and non-driving tasks in response to changes in the road environment [START_REF] Brookhuis | The effects of mobile telephoning on driving performance[END_REF][START_REF] Chiang | An experimental study of destination entry with an example automobile navigation system[END_REF] and accepting a temporary degradation in certain driving tasks (e.g., by checking mirrors and instruments less frequently) [START_REF] Brookhuis | The effects of mobile telephoning on driving performance[END_REF][START_REF] Harbluk | The impact of cognitive distraction on driver visual behaviour and vehicle control[END_REF]. Despite these adaptations, the distraction caused by interacting with smartphone while driving has been shown to significantly impair driver's ability and research findings suggest that they are not always aware of the detrimental effects on their driving performance of engaging in secondary tasks [START_REF] Lesch | Driving performance during concurrent cell-phone use: are drivers aware of their performance decrements?[END_REF] and often underestimate the risks involved in performing particular tasks, particularly in relation to their own crash risk relative to their peers [START_REF] White | Risk Perceptions of mobile phone use while driving[END_REF].

Nevertheless, nowadays reality is that mobile applications are used while driving, that some of these applications are theoretically developed to support driving task and that it is important to better understand their context and motivation of use by the population of drivers.

Potential added value of smartphone applications for drivers' information

Among these mobile applications, some of them are aiming at increasing drivers' comfort, ecomobility [START_REF] Ishikawa | Mobile phone application for ecodriving1 SICE Annual Conference 2010[END_REF], ridesharing [START_REF] Lequerica | Drive and share: efficient provisioning of social networks in vehicular scenarios[END_REF] and even safety. For example, some mobile applications can detect and alert drivers to dangerous driving conditions and behavior. This type of system uses computer vision on the phone to monitor and detect whether the driver is tired or distracted using the front-facing camera while at the same time tracking road conditions using the rear-facing camera [START_REF] You | CarSafe app: alerting drowsy and distracted drivers using dual cameras on smartphones[END_REF].

Closely linked to the widespread of the smartphone use, there is a tremendous increase in social networking activities. The mobile media technology allows drivers to communicate and to collaborate in virtual communities and networks [START_REF] Pauzié | Social networking and ecomobility through nomadic devices[END_REF]. Among diversified purposes, networking is also used to make real time transport events circulating among members in a process that can be called " user-generated content », where each member sends information to the others whenever he feels like doing it. There is a drivers' need to be quickly and accurately informed about critical road events in order to anticipate, or even to avoid these events. Therefore, smartphone applications displaying services related to real time information about traffic information and critical zones could bring an added value to road safety, in addition to the traditional media such as Variable Message Signs and radio on motorways.

Social networking and real time road alert

Real time road alerts via networking can be conducted following two types of principle: using an existing social network connecting drivers to each others without any intermediate, or using dedicated road alert mobile services centrally managed. In the first case, the service is free, the number of members is huge but the process is empirical and the reliability of the circulating information is uncertain. In the second case, a fee can be required for the service, the number of members is usually lower than a general social network, but the information circulation is filtered by the community management system according to several criteria in order to get the highest possible level of reliability.

For the dedicated mobile service, the general principle is the following (Figure 2): -a driver identifies a specific road event that can be of interest for the rest of the network (traffic congestion, roadwork disturbing traffic, critical zones of any kind) -he/she decides to inform the community via the management system about this event by touching an easy access button on the tactile screen or by vocal key words -a set of pictograms representing various potential road events is displayed on the screen, allowing to qualify the event more precisely -after answering to this request, the information is sent to the community management system -this information is filtered based upon several criteria such as previous background of this driver in terms of involvement and reliability, similar information coming from other drivers in this area, etc… -if considered as reliable, this information is widespread to the other community members about to enter in this zone -then, any driver receiving the alert has the possibility to confirm or to infirm the reality and the actuality of the event by a simple touch, the answer being transmitted right away to the service management, in order to update the data base.

Figure 2: General principle of "driver-generated content" for road alerts information

An investigation has been conducted among users of a dedicated mobile service centrally managed based upon this principle, in order to understand needs and motivation of drivers involved in this type of network. As previously described, this service allows drivers to inform the members of the community about location and type (accidents, roadwork, obstacle, etc…) of critical road events. Community participation is on a voluntary basis principle for the driver. There is an easy access to the buttons allowing communicating information to the network via the service management system, with touches on tactile screen available anytime on the main screen of the system. The reliability rating of members is represented by a set of stars, with a maximum number of 3, symbolizing the reliability of the member for the community based upon their past inputs in terms of validity, frequency and significance for the community. The main information displayed to the driver by the smartphone service during the regular route is current speed, number of members ahead with their average rating in stars and distance of their location.

The various risky zones (temporal ones) or dangerous zones (permanent ones) are displayed to the driver when entering the critical zone using an alert visual display with red background, symbolising criticity of the situation, completed with vocal messages (Figure 2), or with cartographic background, option available to have an overview of the set of critical zones in a specified area (Figure 3). • Information on member and time confirmation is not required for dangerous zone where the zone is permanent (display on the right). • Several dangerous and risky zones have been identified by the community and displayed on a map for the benefit of any members, allowing to identify location and type of dangerous and risky zones in a specified area • This display allows also knowing that 10 members with an average of 2 stars (on the left and in the middle) or 14 members with an average of 3 stars meaning highly reliable in their contribution to the community database (on the right), are located in a close surrounding.

•

For the risky zone, information is given about the fact that 89 members confirmed the temporary event 4 minutes ago.

Methodology

A survey using internet media has been launch in cooperation with the service provider. This survey was composed by a set of 141 questions, covering various issues such as users' profile, frequency and context of use of the service, understanding of functionalities and interfaces design, evaluation of the type of buttons the driver would use to inform about road events such as obstacle on the road, accident, icy road illustrated by photos, trust in the information displayed by the service. Several questions were dedicated to the social network level of participation to the community, motivation regarding this participation, potential interference and annoyance while driving when informing or validating information for the community, current number of stars symbolizing driver's reliability, trust in the other network members. Most of the questions were closed-ended, some of them were open in order to better understand reasons and motivations regarding answers. Filling the survey required about 20 minutes. The announcement of the survey has been sent by mail to about 20 000 drivers using the smartphone service and selected according to two criteria: an annual subscription to this service and more than 6 months of experience. A total of 988 of these drivers filled in completely the survey.

Results

Drivers are using the mobile service very often, mostly several times per week or every day, with 42,3% on motorway, 38% on national/departmental roads and 19,65% in urban area. The service is considered as being the more comfortable to use in motorway context for 85% of respondents and in urban area for only 1%. The main essential reason for using this application was "to keep points of the driving license" (87%), knowing that, in France, each violation to road code leads to demerit points withdrawn from the 12 original driving license points, and over speeding in a dangerous zone can result to points loss, with 1 demerit point for over speeding under 20 km/h of the speed limit and 2 demerit points for over speeding between 20 to 30 km/h over the speed limit.

Being informed in advance about these zones allowed drivers to adopt the right speed. The other reasons to use the service, far less priority, were "reliability of the information coming from the community" (45%), "size of the community" (44%) and "road safety issue" (44%), in comparison with other issues such as "system easy to use" (28%), "friends recommended the service "(18%), "innovative technology" (15%) and "to belong to the community" (13%).

Generally speaking, efficiency of the social network and reliability of the alert information is closely linked to the size of the community, with the requirement that at least one member has the opportunity to identify a critical road event and the willingness to inform the network about it, for a given area at a given time. In this framework, it is understandable that the choice of this type of service is based upon the item "size of the community". What is interesting is that an analysis of responses according to 3 main age groups (18 to 30 years old, 31 to 60 years old and more than 61 years old, splitting made with a clear objective to contrast generational culture typical of each group), revealed that the senior group is not that much aware about the importance of the "size of the community" and that their main objective in using this service is rather linked to "road safety" (Figure 5).

Figure 5: Reasons for using the mobile service by age groups

Furthermore, "belonging to the community" per se is not a major motivation for the sample of drivers, obviously less important than "road safety" and "system easy to use"; the younger group is the more concerned by the item linked to community belonging.

The impact of the community activity allowing road alert reliability would not be clearly perceived by the seniors. Then, not surprisingly, the level of participation to the community decreases as the drivers' age increases, with a "systematic participation" (which corresponds for the driver to enter systematically information into the collaborative system each time a relevant event was happening) of about 83% for the young drivers and 52% for the drivers over 61 years old (Figure 5). It can be noted that seniors 'participation is still quite high. The main reasons to participate to the community is the willingness to have a good functioning of the system for 68%, and, to a lower extent, by solidarity with the community for 29%. "Gaining stars" or "playing with the service" are very marginal reasons.

Negative impact of this participation to the driving activity is rated "weakly disturbing" for about 50% of the drivers, "a little disturbing" for 44%, "disturbing" for 6% and nobody found it "very disturbing", with similar findings whatever the drivers' age. This result is very important taking into account road safety concern. It is clear that drivers chose if they want to inform the community about an event and when, being then in full control of the interaction with the device, and able to manage any interference with the driving task. Nevertheless, these results are based upon subjective comments and impact of using the system on the driving task would deserve to be evaluated in real road context by recording drivers' behavior, in order to confirm this low level of interference.

Concerning drivers' ranking, half of them did not know their own number of stars, commenting that they were not too much interested to participate to a "competition with award", but nevertheless, they considered it is important to be informed about stars of drivers ahead in order to evaluate the reliability of the information ("very important" for 47%, and "important" for 42%). Regarding drivers' interest to be ranked, 43% are willing to gain stars while 43% did not understand what is the purpose of stars or did not know the exact process to get them. In this last case, surprisingly, an important amount of drivers did not manage to make a clear link between having stars and being considered as reliable in the community. For the group of drivers aware about the stars meaning and purpose, most of them are really motivated to participate and to be well ranked to guarantee the good functioning of the system, "more stars, more reliable information, more confidence of the community". Indeed, confidence in the social network is a crucial issue for a driver community generating content. Taking into account the important ratio of drivers unaware about the logic and the issue linked to get stars, it seems that this process would deserve more pedagogy toward the drivers to increase motivation of participation.

Road alerts displayed by the service are considered as reliable "most of the time" by 86% for "danger zones" corresponding to critical constant zones, and by 73% for "disruption zones" corresponding to temporary critical zones.

Information coming from the community is considered more reliable than the one coming from the variable message sign and from the radio (figure 6). In the same vein, a recent research demonstrated how information on weather warnings coming from social network was efficient to make drivers changing behavior [START_REF] Elevant | Trust-networks for changing driver behavior during severe weather[END_REF].

Figure 7: Drivers' evaluation of reliability for the road alert information by sources of information

In this study, weather warnings information disseminated through network was a powerful tool to convince driver to change decisions such as route planning and trip cancellation. The overall opinion of the service was very positive, especially when compared to other sources of traffic weather information and alerts. Generally speaking, mobile devices are primarily used for personal communication, while traditional road information channels such as VMS, and including radio, are more impersonal and research shows that people remember better information that affects them personally [START_REF] Schneider | Do we know what we've learned from listening to the news?[END_REF].

Conclusion

Social networking in transport could be a powerful tool to contribute to drivers' safety and comfort by allowing quick widespread sharing of critical road information through "driver-generated content". This communication process, based upon application downloaded by smartphone, is easily accessible with usually low cost. Nevertheless, several issues such as reliability of the transmitted information with resulting level of drivers' trust might be critical. The investigation conducted to gather data on a service aiming at informing drivers about dangerous and critical zones in real time showed several main results:

-except a high and general priority in terms of willingness to keep driving license points, reasons to choose this service are different according to driver's age, with a focus on community size and reliability of the information coming from the community for young drivers and a little preference linked to road safety for senior drivers -drivers are motivated to participate actively to the community by informing systematically road events to the other members for young drivers or at least on a regular basis for seniors -motivation to participate to the social network information is first of all pragmatic with an awareness that inputs are required for a good functioning of the system, and is also social with a willingness to be solidary with the community -drivers can be split into two categories: an important amount of drivers did not understand or did not care about the stars ranking principle, meaning that the level of participation for them to the community is not linked to the reward process itself. The other group relied on this information to evaluate reliability of the road information and gaining stars is part of their motivation -road information coming from the social network are more trusted by drivers than any other sources of information

Based upon these results, mobile services can be considered as good candidate to display critical road information to drivers, with a positive context in terms of acceptability and motivation of use, even by seniors drivers who did not have the same generational culture than young ones regarding social networking but can be still active and motivated to participate as other researches already showed [START_REF] Madden | Older Adults and Social Media Social networking use among those ages 50 and older nearly doubled over the past year[END_REF]. Nevertheless, the crucial issue of distracting impact of smartphone use while driving, even with hands-free use (knowing that hand-held use is forbidden in several countries all over the world) still remained. Use of smartphone while driving involved constraints in terms of drivers' perception and cognition, and naturalistic studies showed the direct link between smartphone use and accidents, even if, in most of these cases, the purposes of using the smartphone, such as sending an SMS, was disconnected with the driving task [START_REF] Young | Driver distraction: A review of the literature[END_REF]. So, research investigations have to study how to answer to the drivers' needs of accurate real time road alerts and to their motivation in using social network for this purpose. Researches in human centred design should bring recommendations and guidelines to the developers on how to define adequate modalities for transmitting this information in a safe way without interfering with the driving task.

Figure 1 .

 1 Figure 1. Billion of smartphone users worldwide from 2012 to 2018 Source statistica.com (http://www.statista.com/statistics/330695/number-of-smartphone-users-worldwide/)

Figure 3 :

 3 Figure 3: Display of a risky zone by alert visual display with red background

Figure 4 :

 4 Figure 4: Cartographic display informing about risky and dangerous zones

Figure 6 :

 6 Figure 6: Participation to the community by drivers' age

Acknowledgement:

We would like to thank the Coyote Company and more specifically Jean-Marc Van Laethem for supporting the study in the setting up of the survey and in managing contacts with the users of the service.


Mengmeng Ding
email: dingm@ececs.uc.edu

Ranga Vemuri

A Two-Level Modeling Approach to Analog Circuit Performance Macromodeling

In this paper, we present a two-level modeling approach to performance macromodeling based on radial basis function Support Vector Machine (SVM). The two-level model consists of a feasibility model and a set of performance models. The feasibility model identifies the feasible designs that satisfy the design constraints. The performance macromodel is valid for feasible designs. We formulate the feasibility macromodeling problem as a classification problem and the performance macromodeling as a regression problem and apply SVM algorithm to build the classifier and regressors correspondingly. Our experiment shows that performance macromodels for feasible designs are much more accurate, faster to train and evaluate than those without functional or performance constraints considered.

Introduction

Performance macromodels are mathematical models that relate the controllable design parameters and performance parameters of an analog circuit. Frequently as an alternative to a circuit level simulator for performance parameter acquisition, performance macromodels take much less time to evaluate than that needed by its counterpart. Often a certain analog circuit topology is configured with different design parameters in various applications. This property of an analog circuit topology makes its corresponding performance macromodels reusable for various applications.

A popular approach to performance macromodeling is using regression based techniques, which often use samples of performance parameters obtained from simulation to fit a regressor. This type of technique is challenged by the high nonlinearity relationship between design variables and performance parameters. S. Zazalaand, J. Eckmuller and H. Grab [START_REF] Zizala | Fast calculation of analog circuits' feasibility regions by low level functional measures[END_REF] have shown that by constraining the circuit in the feasible design space, one can build performance macromodels of higher accuracy. Feasible design space is a multidimensional space determined by certain design constraints.

In this paper, we present a similar two-level modeling approach. The two-level model is composed of a feasibility model and a set of performance models. In contrast to [START_REF] Zizala | Fast calculation of analog circuits' feasibility regions by low level functional measures[END_REF], we will construct a feasibility model of much higher accuracy than [START_REF] Zizala | Fast calculation of analog circuits' feasibility regions by low level functional measures[END_REF] by formulating the feasibility modeling problem as a two class classification problem and apply state of the art classification technique, radial basis function Support Vector Machine(SVM) to build the classifier. Performance models in the feasible design space are then constructed by fitting SVM regressor.

Problem formulation

As mentioned in Section 1, feasible design space is a multidimensional space determined by certain design constraints. Given a circuit topology, we can pose three types of constraints: Geometry constraints on the design parameters, primarily device sizes and bias voltages and currents; Functional constraints that insure the functional correctness of the given circuit topology and Performance constraints on the performance measurements depending on the applications. Geometry constraints define the initial design space, usually a hypercube. Feasible design space I is the subspace of the initial design space, in which every design configuration satisfies all the design constraints. While performance constraints have never been used in performance macromodeling, we are enabled to do so by formulating the feasibility modeling problem as a classification problem and thus to handle arbitrary constraints.

Since functional and performance constraints are not directly posed on the design variables, I is not in an analytic form. We thus define a feasibility function y (x) whose output only takes two values {+1, -1} depending on whether x ∈ I .

y (x) = +1 if x ∈ I -1 if x / ∈ I (1)
To build performance macromodels, we use Vapnik [START_REF] Vapnik | The nature of statistical learning theory[END_REF] proposed radial basis function SVM as our regressor. The original SVM regressor uses a ε-insensitive loss function Uniform random samples Active learning scheme which is equivalent to minimizing the maximum error. Minimizing the maximum error is favored here because we want to make sure the models will perform well even in the worst case.

Experimental results

We apply the two-level modeling methodology to build feasbility model as well as performance macromodels for an OTA opamp, schematic shown in [START_REF] Ding | An active learning scheme using support vector machines for analog circuit feasibility classification[END_REF]. Our experiments are conducted on a Sun Blade 1000 machine and computational time is CPU time. The technology is AMI 0.5µm CMOS process and supply voltage is 5V. The functional constraints insure all the transistors are on and in saturation region with some margin. We use a software called libsvm [START_REF] Chang | LIBSVM: a library for support vector machines[END_REF] to train and validate the SVM classifier and regressors.

W 1 = W 2 [6µm, 200µm] W 3 = W 4 [6µm, 200µm] Design variables W 5 = W 6 [6µm, 200µm] W 7 = W 8 [6µm, 200µm] W 9 = W 10 [6µm, 200µm] I bias [6µA, 100µA] Fix design parameters L 1 , ••• , L 10 1.2µm C c 1pF
Table 1. Design variables of OTA op-amp

Functional constraints V gs -V th ≥ 0.1V V ds ≥ V gs -V th + 0.1V V os ≤ 0.01V Performance constraints Phase Margin ≥ 45 • Table 2.

Design constraints of OTA opamp

The feasible design space is only about 2.4% of the entire design space in this particular example. Using a set of uniform random samples to train the SVM, we can get a feasibility model of very high overall accuracy but approximate the feasible design space very poorly. We apply the active learning scheme proposed by [START_REF] Ding | An active learning scheme using support vector machines for analog circuit feasibility classification[END_REF] to solve the problem. The overall accuracy is always above 98.9% due to the powerful classification ability of the SVM. The active learning scheme can approximate the feasible design space much better with the same number of samples.

We construct and validate various performance macromodels using performance parameters of feasible designs.

The training set has 7,000 samples and the validation set has 7,101 samples. In

Conclusion

This paper presents a two-level modeling approach which consists a classifier as a feasibility model and a set of regressors as performance models. Experimental results show that it is an efficient approach to performance macromodeling.

0

  This work was supported in part by the Defense Advanced Research Projects Agency and the Sensors Directorate of the Air Force Research Laboratory, U.S. Air Force, Wright-Patterson AFB, OH, under Contract F33615-01-C-1977, the Dayton Area Graduate Studies Institution (DAGSI) under the DAGSI/AFRL Research Program Project SN-UC-01-08, and the National Science Foundation under award number CCF-0429717.

  in the training set Pecentage of misclassification in estimated feasible designs (%)

Table 3 ,

 3 RMS stands for root mean squared error and MAX stands for the maximal absolute value of training or validation errors.

		Training set	Validation set	T eval	T train
		RMS	MAX RMS	MAX	(s)	(s)
	Gain(db) 0.048 0.215	0.049 0.227	1.0e-4 27.9
	UGF(%) PM( • )	0.55 0.062 0.357 1.27	0.57 0.080 0.917 2.41	1.2e-4 48.2 6.6e-4 2929

Table 3 . Statistics of performance macromod- els of OTA opamp in feasible design space

 3 We also generate performance models without the constraints in Table2. As shown in Table4, these models are less accurate, take much longer time to train and evaluate.

		Training set	Validation set	T eval	T train
		RMS	MAX RMS	MAX	(s)
	Gain(db) 0.053 0.777 0.058 0.618	2.6e-4 101sec
	UGF(%) PM( • )	0.87 0.166	5.09 1.79	0.94 0.35	6.81 4.17	9.8e-4 1.58hr 3.0e-3 5.20hr

Table 4 . Statistics of performance macromod- els of OTA opamp without feasibility con- straints

 4

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05)

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE