Satoru Noguchi
email: satoru.noguchi@inria.fr

Manabu Tsukada
email: manabu.tsukada@inria.fr

Ines Ben Jemaa
email: ines.benjemaa@inria.fr

Thierry Ernst
email: thierry.ernst@inria.fr

Real-vehicle integration of driver support application with IPv6 GeoNetworking

One of the essential usage of Intelligent Transportation Systems (ITS) applications is to provide road traffic information to vehicle drivers for road safety and efficient drive. For this usage, it is necessary to integrate geographical routing mechanisms in vehicular ad hoc network (VANET) into ITS applications. In this paper, we design and implement an ITS application which relies on IPv6 GeoNetworking; a geographical addressing and routing mechanism developed in the GeoNet project. Our application supports realistic use case scenarios, therefore we integrated it into INRIA's vehicular platform. The system has publicly been demonstrated in realistic scenarios.

I. INTRODUCTION

Intelligent Transportation Systems (ITS) applications aim to provide road users with improved traffic safety, traffic efficiency, and additional value. They run on Application Units (AUs) connected to On-Board Units (OBUs) in vehicles, Roadside Units (RSUs) in roadside infrastructure, and Internet hosts. IPv6 is considered as a mandatory communication protocol in ITS network because of its capabilities of mobility support and huge address space [START_REF] Ernst | The information technology era of the vehicular industry[END_REF]. One of the essential usage of ITS applications is to provide road traffic information with vehicle drivers for safety and efficient drive possibly through in-vehicle Human Machine Interfaces (HMI).

ITS applications are significantly different from regular applications; they need to deliver messages to group of vehicles within a particular area specified with geographical position because most road traffic information is related to the geographical position of the vehicle. For example, if a vehicle detects a road traffic event (e.g. accident, congestion, etc), it reports the event to an ITS centre and the centre assigns a RSU, which locates in relevant area, to inform approaching vehicles of the event. IPv6 GeoNetworking developed in the GeoNet project, an European project started from 2008 and finished in 2010, 1 provides such geographical routing mechanism. It combines IPv6 and Vehicular Ad hoc NETworks (VANETs) and routes packets using geographic position via wireless multihop communication [START_REF]D1.2 Final GeoNet Architecture Design[END_REF].

In order to address benefits, requirements, and issues of exploiting the geographical routing for ITS, we design and implement an ITS application exploiting IPv6 GeoNetworking capabilities. Thanks to its geographical routing functionality, our application effectively delivers location-specific messages 1 The FP7-funded European project GeoNet http://www.geonet-project.eu/ to a certain area instead of regular broadcasting in VANET. We integrate the proposing system into our real vehicle testbed.

The remainder of this paper is organized as follows. Section II overviews the ITS network, existing efforts of developing ITS applications, and IPv6 GeoNetworking completed in the GeoNet project. Section III describes use cases and functional requirements of our application. Section IV is dedicated to our propose system architecture for our application harmonized with IPv6 GeoNetworking. We then present integration and demonstration results in our real vehicle testbed in Section VI. After discussing issues in Section VII, Section VIII finally concludes the paper.

II. RELATED WORK

The ITS network combines VANETs and the Internet. Fig. 1 shows the simplified network topology composed of sets of nodes: OBU, RSU, and AU. Several ITS projects and standards organizations have been developing these nodes (ITS station) conforming to ISO/ETSI's ITS station reference architecture. OBU, which is a device installed in vehicles, and RSU, a device installed along the roadside, behave as mobile routers and access routers that may compose VANETs, whereas AUs run ITS applications. The RSU allows OBUs to access to the Internet. IPv6 works as the network layer communication protocol. Based on the ITS network, a wide variety of ITS applications has been defined in ITS projects and standards organizations. They have been categorized into three types of applications: road safety, traffic efficiency, and others (infotainment or value-added services) [START_REF]CAR 2 CAR communication consortium manifesto, overview of the C2C-CC system, version 1.1[END_REF], [START_REF]Intelligent Transport Systems (ITS), Vehicular Communications (VC), Basic Set of Applications, Definitions[END_REF], [START_REF]CVIS.3.3 Architecture and System Specifications[END_REF].

The GeoNet project has developed a reference specification of IPv6 operating over GeoNetworking and conforming C2CNet specification [START_REF]D1.2 Final GeoNet Architecture Design[END_REF], [START_REF] Tsukada | Experimental evaluation for IPv6 over VANET geographic routing[END_REF]. C2CNet, specified by the CAR 2 CAR Communication Consortium2 , is a communication layer dedicated to car-to-car communication and is located between IPv6 and the link layer. It supports geographical addressing and routing by means of encapsulating IPv6 packet with a new C2CNet header, which contains source and destination C2CNet identifier, source and destination geographic position. Although C2CNet layer itself exchanges packets with non-IP messaging, the GeoNet project has defined how to transmit IPv6 packet over C2CNet ("IPv6 over C2CNet"). This is performed transparently to the upper layers; In IPv6 GeoNetworking-enabled VANETs, each node is assigned a C2CNet identifier. When an originator node constructs an IPv6 packet with destination node's IPv6 address, the C2CNet layer encapsulates the packet with C2C header with the IP next hop's C2CNet identifier. The C2CNet layer thereby makes the routing decision with the C2CNet identifier and nodes' geographic location. IPv6 is thus used in a regular manner; when upper layers issue IPv6 unicast, multicast, and anycast packets, the IPv6 over C2CNet mechanism delivers them with GeoUnicast, GeoBroadcast/TopoBroadCast, and GeoAnycast, respectively [START_REF]D1.2 Final GeoNet Architecture Design[END_REF].

III. DRIVER AWARENESS APPLICATION ENHANCED WITH IPV6 GEONETWORKING

In this section, we define two essential use case scenarios for supporting drivers and discuss the functional requirements of ITS applications for such use cases. They can be categorized into road safety application and traffic efficiency application. The first one is Road traffic event detection and dissemination; when a vehicle detects a particular road traffic event (e.g. accident, approaching emergency vehicle, etc), it reports the description of the event to an ITS centre. The ITS centre shows the occurrence of the event to ITS operators and inform relevant vehicles of the event. The second scenario is Road traffic Information dissemination from ITS centre; an ITS operator in an ITS centre informs about a particular road traffic event (e.g. road congestion) to relevant vehicles, which reside within the relevant area of the event. Both scenarios therefore rely on three types of vehicular communications; Vehicle-Vehicle, Vehicle-Roadside, and Vehicle-Internet communication defined in [START_REF]D1.2 Final GeoNet Architecture Design[END_REF].

In each scenario, dissemination messages are delivered to vehicles within the relevant geographical area (GeoDestination). It covers an appropriate range of roads through which the receivers approach the point of event. The size of the area is configured depending on the type of event, receivers' possible driving speed, and the characteristics of possible destination area. For example, in urban area composed of narrow streets, it is assumed that the driving speed is relatively slow and it may regularly be congested. In such a situation the GeoDestination can be small for saving bandwidth, and vice versa. The functional requirements of ITS applications are defined according to these scenarios. Three types of functions realize the application; (i) detecting and reporting road traffic events (Reporter), (ii) aggregating and disseminating the road traffic event to relevant vehicles (Disseminator), and (iii) receiving messages from the Disseminator and notifying drivers of the event (Receiver). The receiver and reporter shall be integrated into vehicles. On the other hand, the disseminator shall be equipped with AUs in ITS centre.

From the point of view of communication, AUs hosting the ITS application shall be reachable from one another. It means that roadside infrastructures shall provide Internet access to vehicles. The reporter shall know the communication endpoints of an appropriate disseminator (i.e. IPv6 address and port). As vehicles are sets of mobile nodes, the reporter shall be statically configured with a set of appropriate disseminators. Otherwise, it shall have some mechanism to dynamically find an appropriate disseminator.

IV. SYSTEM ARCHITECTURE

Our application consists of two types of software entities located in AUs: clients in vehicle and a server in an ITS centre. The client acts as the reporter and receiver at the same time, whereas the server acts as the disseminator. To deliver messages to a particular geographical area, applications transparently exploit IPv6 GeoNetworking developed in the GeoNet project. Thanks to the geographical routing mechanism, messages are delivered to GeoDestination independently of routers' wireless communication range. We particularly exploit the GeoBroadcast mechanism that enables to send packets from a node to all nearby nodes located within a particular geographical area [START_REF] Tsukada | Experimental evaluation for IPv6 over VANET geographic routing[END_REF].

!"# $%&' $%&' ()% *+,-./+. #0#1+/ !"# $%&' #0#1+/ !"# !"# $%&' ()% )233+4 256/-. $%&' #0#1+/ !"# !"# $%&' ()% $%&' #0#1+/ !"
While OBUs and RSUs have IPv6 GeoNetworking functionality, the application itself is integrated into AUs, which only have a regular IPv6 stack. Fig. 3 shows the overall protocol architecture of our system. Configurations of each station are described as follows:

Vehicle: Vehicles are equipped with an OBU that has IPv6 GeoNetworking and an AU that contains regular IPv6 stack. For station-internal communication between AU and OBU, regular Ethernet is used. WLAN is used for station-external communication between OBU and other OBUs/RSUs. The client application consists of two main components and one support component: reporter, receiver, and HMI, respectively. The reporter automatically detects road traffic events and reports them to the disseminator via UDP unicast. The receiver receives messages from the disseminator via IPv6 multicast, which are encapsulated to GeoBroadcast packets, and then notify vehicle drivers. Thus AUs join an IPv6 multicast group. Both main components inform drivers of road traffic event detection and message reception though the GUI windows provided by the HMI.

Roadside: The roadside only has a RSU that supports both IPv6 GeoNetworking and regular IPv6 routing. The RSU encapsulates regular IPv6 multicast packets delivered from the Internet and GeoBroadcasts to OBUs via its wireless network interface. Even though a RSU does not cover the necessary range for delivering GeoBroadcast packets, the packets is forwarded by nearby vehicles thanks to the multihop communication mechanism in IPv6 over C2CNet.

Centre: ITS centre contains an AU connected to the Internet. In the AU, the server application has one main component and one support component: disseminator and HMI, respectively. The disseminator aggregates road traffic event reported by clients via regular UDP unicast, and propagates them to other receiver clients via IPv6 multicast. The disseminator also informs ITS operators of road traffic event detection though the GUI window of the HMI.

A. Communication sequence

Messaging sequences shown in Fig. 4 are as follows:

1) RSUs and the disseminator establish an IPv6 multicast tunnel. RSUs are configured for forwarding IPv6 multicast from the Internet to VANET.

V. IMPLEMENTATION

We implemented the proposed system and integrated it into our real vehicle testbed in INRIA rocquencourt that includes three vehicles equipped with one OBU and one AU, two RSUs, and another AU as ITS centre. The system is therefore capable of testing multi-hop communication in VANET. OBUs and RSUs are Alix3d3 embedded PCs equipped with an Ethernet port as an ingress interface which is connected to station-local wired network, and a mini-pci wireless card (Atheros AR5414 802.11 a/b/g Rev 01) used as an egress interface. Ubuntu 9.0.4 (kernel 2.6.29.6) is installed to both of them. They also have capabilities to get their current geographical position; OBUs are connected to in-vehicle GPS receiver (Trimble AgGPS 323), with which gpsd 3 in OBU provides vehicles' current location, and RSUs are statically configured with their position. AUs are conventional PCs.

OBUs and RSUs have an IPv6 protocol stack including a multicast daemon and a C2CNet layer. The multicast daemon enables multicast forwarding and records the multicast groups on their ingress interfaces. The IPv6 multicast tunnel between RSUs and the ITS centre is statically configured for now. Regarding AUs, although our application is able to run on any operating system as long as they support IPv6, MLDv2, and Java, we used Ubuntu 9.0.4 for operational reasons. Each vehicle AU is connected to its OBU through wired Ethernet, on the other hand, an AU in the ITS centre is directly connected the Internet.

The IPv6 GeoNetworking mechanism on OBUs and RSUs is implemented with TUN virtual interface that communicates with IPv6 and C2CNet. OBUs (RSUs) at first receive regular IPv6 packets on their ingress (egress) interface and pass the packets to C2CNet module via the virtual interface. Then subsequent communication is performed in C2CNet layer. The C2CNet layer determines the type of communication (i.e. GeoUnicast or GeoBroadcast) from the first 8 bits of the destination IPv6 address. Regarding the GeoBroadcast generated from IPv6 multicast, the destination area is mapped to a particular IPv6 multicast address, such as "ff02::1" to a radius of 500m. The C2CNet layer in intermediate OBUs and RSUs forward the packets with multi-hop manner. Destination OBUs (RSUs) receive the packets via their egress (ingress) interface and passes them to their ingress (egress) interface via the virtual interface as regular IPv6 packets.

The client application is implemented under JavaSE6 and JavaFX1.2, as shown in Fig. 5: the reporter and receiver components run on JavaSE whereas the HMI component runs on JavaFX. The client HMI displays the vehicle's name, current geographical position, detected road traffic events (reporter's function), and reported messages (receiver's function). As the road traffic event detection mechanism is out of focus of this paper, currently the event detection is statically performed in the application's configuration file by specifying the geographical position where the event is supposed to take place.

The server application is implemented under JavaSE6, JavaFX1.2 and Google Earth; the disseminator is developed under JavaSE and the HMI is composed of JavaFX and Google Earth. The server HMI has a local http server that overlays reported road traffic information on Google Earth by means of generating KML sentences, shown in Fig. 6.

VI. FIELD DEMONSTRATION

We conducted a field demonstration of our system with the scenarios described in Section III. The main goal of this demonstration is to show effectiveness of integrating the ITS application on top of IPv6 GeoNetworking thanks to the following three features: GeoBroadcast generated from IPv6 multicast, Internet-to-Geographical area communication, and receiver vehicle receives the packets as long as it resides within the destination area. Regarding the other scenario, Road traffic information dissemination, the server can also send the traffic information messages (Propagate info) at any time without report from reporters.

The system configuration is in Table I. Through several preliminary tests, we determined Event propagation frequency, which represents the frequency of the transmission of event propagation messages (Propagate event) to 10Hz in order to notify drivers of road traffic events as fast as possible via the clients' HMI. The range of GeoBroadcast is configured to a radius of 150m of the location of RSU. One of our tests showed the average Round Trip Time (RTT) between RSU and OBU using IPv6 GeoNetworking on multi-hop was around 15ms, shown in Fig. 7. It means that even though the GeoBroadcast packets are propagated with multi-hop, it is delivered within 7.5ms from RSU to OBU.

Our system has publicly been demonstrated at the final workshop of the GeoNet project at INRIA premises (January 2010, Rocquencourt, France) [START_REF]D7.1 GeoNet Experimentation Results[END_REF].

VII. DISCUSSION

In this section, we discuss the design issues of ITS applications enhanced with IPv6 GeoNetworking. For large-scale ITS network containing several ITS centres and RSUs, messages sent from reporters should be delivered to an appropriate ITS centre which supports a particular service, organization, or geographical area. According to stringent latency requirements for ITS applications (e.g. from 10ms to 1000ms for road safety [START_REF] Karagiannis | Traffic safety applications requirements[END_REF]), locating such a ITS centre must be done within a few milliseconds or before sending the report. Service Discovery technology, a mechanism to automatically discover communication endpoint from services' name and attributes, may be helpful for this issue [START_REF] Mian | A survey of service discovery protocols in multihop mobile ad hoc networks[END_REF].

ITS centres need to have ability to select appropriate RSUs which disseminate IPv6 multicast packets using GeoBroadcast. One proposal is to send IPv6 multicast to all RSUs. However, it might consume bandwidth in the case of large scale network.

The ITS station reference architecture, as mentioned in Section II, contains multiple access technologies and NEtwork MObilty support protocol (NEMO) [START_REF] Devarapalli | Network Mobility (NEMO) Basic Support Protocol[END_REF]. This architecture comprises the IPv6 GeoNetworking mechanism and is assumed as a foundation of ITS, thus ITS applications must cooperate with the architecture.

VIII. CONCLUSION

In this paper, we designed an ITS application enhanced with IPv6 GeoNetworking developed in the GeoNet project. At first we described the necessity of IPv6 GeoNetworking for ITS applications. After showing typical use cases and requirements of ITS applications based on geographical routing, we designed and implemented our ITS application that consists of two entities; a server in an ITS centre and clients in vehicles. Our system was integrated into outdoor field test environment and successfully worked in realistic scenarios as the final demonstration of the GeoNet project at INRIA.

ACKNOWLEDGMENT

The work reported in this paper has been financed by the European Commission under the GeoNet project (grant agreement 216269). The authors would like to thank all the members of the GeoNet project.

Fig. 1 .

 1 Fig. 1. ITS network

Fig. 2 .

 2 Fig. 2. Road traffic event detection and dissemination scenario

Fig. 2

 2 overviews the Road traffic event detection and dissemination scenario. Regarding the Road traffic Information dissemination scenario, it only uses the dissemination mechanism in this Figure.

Fig. 4 .

 4 Fig. 4. Messaging sequence. Report event is used only in the Road traffic event detection and dissemination scenario.

Fig. 5 .Fig. 6 .

 56 Fig. 5. Components' structure

Fig. 7 .

 7 Fig. 7. Latency between RSU and OBU (multi-hop)

CAR 2 CAR Communication Consortium. http://www.car-to-car.org/

gpsd -a GPS service daemon. http://gpsd.berlios.de/


Keywords: Service discovery, interoperability, pervasive environments

Discovering networked services in pervasive computing environments is problematic as multiple Service Discovery Protocols (SDPs), differing on their services description formats as well as advertisement and request models, have already become (de-facto) standards. This calls for a solution to SDP interoperability, enabling clients to locate networked services independent of the SDP they use to advertise their presence. In this paper, we report on our experience in developing two such solutions: the transparent approach of INDISS based on message translation, and the explicit approach of MSDA based on protocol integration. While efficient and able to support legacy clients and services, INDISS is limited by the basic service information available in existing SDPs, and assumptions about the network protocols used by the SDPs. Advanced discovery features required by pervasive environments, such as context or security management, can only be provided by more complex discovery frameworks like MSDA, but come at a price.

I. INTRODUCTION

The availability of consumer-oriented mobile devices powerful enough to host services, and the deployment of heterogeneous networks based on wireless networking technologies have enabled the emergence of service-rich computational environments aimed at supporting users in their daily life. Discovering the networked services available in such environments is a crucial first step for providing a satisfying experience to the user. Over the years, many academic and industry-supported Service Discovery Protocols (SDPs) have been proposed (e.g., Jini, SSDP, SLP, and UDDI). Maheswaran [START_REF] Maheswaran | Data Dissemination Approaches for Performance Discovery in Grid Computing Systems[END_REF] proposes a taxonomy of discovery protocols based on their organization (i.e., centralized vs. decentralized vs. hierarchical), methods (push vs. pull vs. symmetric), and timing (irregular vs. periodic). One common characteristic of these SDPs is that they have been designed based on specific assumptions about the underlying network (e.g., Internet, home network), the users' behavior, or the applications' needs. While efficient for the targeted environment, they prove inefficient or not This work described herein is funded by the European Commission under the FP6 IST project Amigo contract number 004182, the FP6 IST project UBISEC contract number 506926, and the FP6 IST Project Plastic contract number 026955. applicable in different settings (e.g., network-flooding [START_REF] Ni | The Broadcast Storm Problem in a Mobile Ad Hoc Network[END_REF]). Another characteristic is that they do not directly interoperate with each other's as they employ incompatible formats and protocols for service description, service advertisements, or discovery requests. Furthermore, these SDPs are often integrated in middleware platforms (e.g., SSDP and UPnP), complicating interoperability (i.e., incompatible data types or communication models). In fact, the diverse environment constraints and the de-facto standard status of some of the existing SDPs, make it unlikely for a new and unique SDP to emerge. Several projects are thus investigating interoperability solutions for SDP [START_REF] Friday | Supporting service discovery, querying and interaction in ubiquitous computing environments[END_REF][6] [START_REF] Grace | ReMMoC: A Reflective Middleware to Support Mobile Client Interoperability[END_REF] [START_REF] Koponen | Service Discovery: A Service Broker Approach[END_REF], as requiring clients and services to support multiple SDPs is not realistic. SDP interoperability is typically achieved using intermediate representations of SD paradigms (e.g., service description, discovery request) [START_REF] Friday | Supporting service discovery, querying and interaction in ubiquitous computing environments[END_REF][6] instead of direct mappings [START_REF] Koponen | Service Discovery: A Service Broker Approach[END_REF], as the latter does not scale well with the number of supported SDPs. Two approaches are however possible to interface with the various SDPs: transparent or explicit. In the transparent approach, the interoperability layer is located close to the network and directly translates SDPs messages to/from the various SDPs [START_REF] Koponen | Service Discovery: A Service Broker Approach[END_REF]. Clients and services are unaware of the translation process. In the explicit approach, the interoperability layer is located on top of the existing SDPs, and provides an explicit discovery API to clients (and sometimes services) [START_REF] Friday | Supporting service discovery, querying and interaction in ubiquitous computing environments[END_REF]. While the transparent approach eases the deployment and use of the interoperability solution by legacy clients and services, the explicit approach enables the extension of existing SDPs with advanced features such as context management [START_REF] Koponen | Service Discovery: A Service Broker Approach[END_REF]. In this paper, we detail and compare the SDP interoperability solutions developed in the IST Amigo1 (Section II) and IST UBISEC2 (Section III) projects that are respectively based on the transparent and explicit approaches. The comparison of the two approaches (Section IV) highlights the different networking environments targeted by the two solutions as well as the different methodology for supporting client/service interactions in pervasive environments. We conclude (Section V) by outlining on-going work in both projects as well as in the IST Plastic project3 to support service access in the heterogeneous computing environment, and discussing partial integration of the two solutions. The IST Amigo project aims to improve the usability of home networks, and for that investigates: (i) interoperability issues arising from the use of heterogeneous networking technologies, devices, middleware platforms, and standards, (ii) the automatic discovery of devices and services as well as their composability and upgradeability and self-administration, and (iii) intelligent user interfaces. In the context of the Amigo project, we designed INDISS [START_REF] Bromberg | INDISS: Interoperable Discovery System for Networked Services[END_REF] (Interoperable Discovery System for Networked Services) to overcome SDPs heterogeneity. In this section, we detail the networking environment and the design goals of INDISS leading to the use of the transparent approach. We then present the main components and deployment of the system, and discuss how SDPs messages are translated into sets of events exchanged between the system's components. We then emphasize how the transparent approach enables support for legacy applications and helps future developments.

A. Amigo networking model

Amigo assumes an all-IP networking environment, meaning that clients and services are using communication protocols built on top of IP and that all devices within the pervasive environment (i.e., home network) are IP reachable. While different devices may belong to different subnets, unicast and multicast packets can reach all devices. Due to the environment constraints, SDPs in home environment are multicast based and fully distributed.

B. A transparent approach

Keeping with the goal of usability, and the focus on dynamic home networks, INDISS is specifically designed as a transparent solution minimizing resource usage (i.e., memory, processing and bandwidth), and introduces lightweight mechanisms that may be adapted easily to any platform. The transparent approach is also key to support legacy clients and services, which is crucial in Amigo. INDISS is composed of a set of event-based components and their composition is performed dynamically at run-time according to both the context and the device on which INDISS is deployed. INDISS operates close to the network, capturing and translating network messages without the need for clients or services interactions. As a result, service discovery interoperability is provided to applications without altering them: applications are not aware of the existence of INDISS.

C. INDISS architecture

INDISS main components are the monitor, the parser, and the composer:

• The monitor component detects the SDPs that are used based on network activity on the assigned multicast groups and ports. This component also captures/collects network messages sent by clients and services onto these multicast groups, and forwards them to the appropriate parser components. • The parser component, associated to a specific SDP, transforms the raw data flow (i.e., network messages) into series of events, extracting semantic SDP concepts from syntactic details of the SDP messages. The generated events are delivered to an event bus locally deployed. • The composer component delivers a SDP message understood by the target clients and/or services based on specific sets of events received from the event bus. Parsers and composers are dedicated to specific SDP protocols. In INDISS, the communication between the parser and the composer does not depend on any syntactic detail of any protocol. They communicate at a semantic level through the use of events. A fixed set of common events has been identified for all SDPs, and each SDP has also a set of specific events. For example, a subset of events generated by a UPnP parser are successfully understood by a SLP composer, whereas specific UPnP events, due to UPnP functionalities that SLP does not provide, are simply discarded from the SLP composer, as they are unknown. SDP interoperability comes from the composition of multiple parsers and composers dedicated to different SDPs, and the implicit creation of an event bus. As depicted in Figure 1, the monitor receives a incoming UPnP message from the service, and forwards it to the parser of the UPnP unit. The UPnP parser then translates the message into a set of events. The SLP composer receives the relevant (subset of) events according to its event filters, and composes the adequate SLP messages. This message is then sent onto the SLP multicast group and received by the client. In general, SDP functions like service request, service registration or service advertisements, are complex distributed processes that require coordination between the actors of the specific service discovery function. It follows that the translation of SDP functions that is realized by INDISS is actually achieved in terms of translation of processes and not simply of exchanged messages, further requiring coordination between the parser and composer. This is realized by embedding the parser and composer within a unit that runs coordination processes associated with the functions of the supported SDP. Specifically, the behavior of the unit is specified using finite state machines [START_REF] Bromberg | INDISS: Interoperable Discovery System for Networked Services[END_REF].

D. INDISS deployment

INDISS may be deployed independently on one or more devices in the network. Each instance of INDISS dynamically instantiates parsers and composers for the SDPs it supports, and provides interoperability between these SDPs for all the devices in the network. Multiple instances of INDISS may provide interoperability between different sets of SDPs. While INDISS can be deployed on a home gateway, and translate and forward all messages, it may take into account the CE nature of home networks, where some devices only provide services, while others only accesses them. Indeed, INDISS can be optimized for client-only or service-only devices by reducing the number of messages sent.

E. Unique feature: transparent interoperability

With INDISS, application components continue to use their own native service discovery protocol; interoperability is achieved through a transparent integration of INDISS. Event streams are totally hidden to components outside INDISS, as they are assembled into specific SDP messages through composers. Consequently, interoperability is guaranteed to existing applications tied to a specific SDP without requiring any change to applications. Similarly, future applications do not need to be developed with a specific middleware API to benefit from SDP interoperability.

III. SERVICE DISCOVERY IN UBISEC

The IST UBISEC project investigates the discovery, security, and customization of services in Beyond 3G (B3G) networks. As UBISEC targets a highly heterogeneous networking environment, the Multi-protocols Service Discovery and Access (MSDA) platform [START_REF] Raverdy | Efficient Context-aware Service Discovery in Multi-Protocol Pervasive Environments[END_REF] was designed to provide contextbased enhanced service discovery. In this section, we detail the networking environment and the design goals of MSDA that lead to the use of the explicit approach. We then present the components of the platform, the intermediate representation of service descriptions, and the deployment of the platform in a multi-networks environment. We finally detail how context information is used both for filtering results, but also to control the dissemination of service information.

A. UBISEC networking model UBISEC also considers an all-IP networking environment. However, UBISEC assumes highly heterogeneous, loosely connected networks. Network heterogeneity arises from: (i) the use of different networking technologies, (ii) variations in the sets of IP-level configuration and communication functionality provided by the network (e.g., IP multicast support, DHCP), and (iii) networks belonging to different administrative domains (e.g., public vs. restricted) and management models (infrastructure-based vs. ad hoc). These networks may further target different classes of applications (e.g., sensor networks, home/automation networks, hotspots). One major consequence is that we consider that global IP routing is not guaranteed. In UBISEC, the pervasive environment is modeled as a dynamic composition of heterogeneous networks. Moreover, the Internet and cellular networks are considered as conduits enabling the interconnection of the various networks.

B. An explicit approach

MSDA is an additional layer on top of existing SDPs. MSDA is instantiated independently in each network of the environment, and each instance registers as a service (the MSDA Service) with the active SDPs in the network. The MSDA Service provides a pull-based service discovery interface (i.e., clients issue discovery requests and are returned the matching services). MSDA-aware client applications interact with services that use different discovery and access protocols, or are in different networks, explicitly through MSDA (i.e., using the format and protocols of MSDA). MSDA instances in nearby networks dynamically communicate with each other to disseminate service information and to provide remote service access. Each MSDA instance independently selects with which nearby MSDA instance to connect to, and filters service information and access requests that it receives/sends from/to these MSDA instances.

C. MSDA architecture MSDA main components are (See Figure 2):

• The MSDA Manager that manages discovery and access requests within the network for local and remote clients, • Plugins that interact with specific SDPs to collect service information, register the MSDA service to be used by local clients, and perform service access on behalf of remote clients, • Transformers that extend service descriptions with context information, • MSDA Bridges that assist MSDA Managers in expanding the service discovery and service access to other networks in the whole pervasive environment.

MSDA Bridge

UPnP SLP Plugin

MSDA Manager

UPnP Plugin

SLP

Transf. Transf.

Transf.

MSDA Service

MSDA Bridge

S C

D. MSDA deployment

MSDA can be deployed on one or more devices in a network (one instance per device), and one of the MSDA instances is dynamically elected as the MSDA Manager of the network. We implemented the MSDA Manager as a centralized component, as the size of a network (e.g., subnet) is limited by nature (i.e., its number of devices and services is limited). The MSDA Manager is the main component of MSDA, as it processes, within its network, discovery and access requests from local and remote clients. The MSDA Manager periodically sends presence beacons so that other MSDAaware devices in the network can detect its absence, as well as duplicates, and recover. The elected MSDA Manager then activates its SDA Plugins and transformers. The MSDA Manager may dynamically select some of the MSDA instances in its network to act as MSDA Bridges (if they registered as potential MSDA Bridge) based on several criteria (i.e., connectivity to other networks, expected lifetime, processing power, and cost). An MSDA Bridge disseminates discovery requests between the networks on its different network interfaces. In Figure 2, 3 instances of MSDA have been started in the network (one MSDA Manager and two MSDA Bridges). The MSDA Manager has started an SLP and a UPnP plugin. The MSDA-aware SLP client discovers the MSDA Service with SLP, and accesses it to discover the services advertised in UPnP as well as services in remote networks.

E. MSDA description and request

In MSDA, services are described using the MSDA Description format, which is a generic and modular service description format. In addition to the service information collected from the SDP-specific service description, the MSDA description also contains information to assist the remote access to the service (e.g., network path leading to the destination network, access protocols supported) and information to control the dissemination of the description (e.g., minimum bandwidth requirements). An SDA Plugin first generates an initial MSDA Description based on the SD-specific service description it receives, and forwards it to its Transformers that will extend the MSDA description with service-specific context information. The MSDA Description is then forwarded to the MSDA Manager that adds network-specific context information. Each MSDA Bridge that forwards a description also extends it with context and propagation information. Discovery requests in MSDA are created by MSDA Managers on behalf of client applications and are similar to service descriptions. In addition to the information describing the requested service, the discovery request also contains context information to constrain the dissemination of the request and filter the services returned by the SDPs as well as request processing information that defines how MSDA Managers, both local and remote, should return the result of the MSDA Request (e.g., timeout, partial results).

F. Unique feature: context-aware service discovery

In MSDA, we consider context information of the networking environment, the interacting users, and the service instances. We model context information for these entities as the combination of context parameters and context rules. Context parameters correspond to static and dynamic attributes characterizing the entity. Context rules correspond to control policies expressing preferences, choices, and filters for the control of the discovery process in terms of resources to be used, level of security to be applied, type of services to be selected, and so forth. Context information is stored in MSDA descriptions and requests, and is processed by MSDA Bridges to control the dissemination of MSDA messages, and by MSDA Managers to filter the results of a request.

IV. COMPARISON

Based on the descriptions in Sections II and III, we summarize the two SDP interoperability solutions proposed by the Amigo and UBISEC projects in Table 1. The comparison of the two approaches first highlights that the underlying networking environment does not directly intervene in SDP interoperability (i.e., the conversion of SDP paradigms such as service descriptions), it influences the sets of SDPs targeted and the required features of the interoperability layer. The comparison also highlights the difference between the two approaches is terms of service information conveyed in the intermediate representation and its generation process.

INDISS/Amigo

A. Networking model

Amigo and UBISEC differ on their networking model for pervasive environments, with the interconnection of different networks being managed either at the network level (INDISS), or at the application level (MSDA). The Amigo model is appropriate when considering a single administrative domain (e.g., home environment) but requires global IP routing as well as advanced routing and filtering management solutions in a B3G environment. As this is unlikely (in the short or midterm), an MSDA-like bridging extension to INDISS would be required for such environment. INDISS and MSDA also differ on their deployment models. MSDA requires a strong coordination between its different components (within a network and between neighboring networks). This network overhead is however limited and independent of the number of clients and services. INDISS on the other hand does not provide/ any coordination between multiple INDISS instances and therefore does not generate any control overhead. However, as multiple instances of INDISS in a network operate independently, it may create unnecessary duplication of messages as requests and/or advertisements are translated and reemitted by each instance. We currently investigate a lightweight coordination protocol between INDISS instances to reduce such duplication Network reconfiguration (split/merge) does not affect INDISS as no coordination exists between multiple instances of INDISS. However, a network split may discontinue INDISS support for some devices, and a network merge may introduce message duplication. MSDA detects network reconfigurations and new MSDA Managers and Bridges may be elected following a split/merge, creating a temporary network overhead and potentially canceling ongoing MSDA requests and service access

B. Intermediate representation

The transparent versus explicit approach to SDP interoperability affects the amount of service information used/available. In INDISS, the service information carried over when translating between two SDP corresponds to the intersection of the two sets of service information. In MSDA, as an explicit API is used by clients applications, we designed the MSDA description as an extensible format containing the union of the information contained in the service description formats of existing SDPs, enriched with context information. As more services are deployed in highly heterogeneous environments, selecting the most effective service instance based on context information will be crucial. INDISS and MSDA also differ on how the reconfiguration of the translation process from SDP specific messages to the solution's intermediate representation (INDISS events and MSDA description/request). In MSDA, a new SD plugin (Java class) must be dynamically loaded and instantiated, while in INDISS, the Final State Machine (FSM) that performs the conversion of SPD messages can be dynamically reconfigured at run-time. INDISS approach is therefore more efficient in case of frequent fine-grain updates. More importantly, INDISS approach benefits from the numerous tools available to optimize and validate FSMs.

C. Performance evaluation

Prototypes have been implemented for both solutions and performance results clearly spell out the reactivity of INDISS compared to MSDA. Indeed, discovering an SLP service takes around 40 ms for a UPnP client with INDISS (1.2 ms when INDISS is deployed on the client), while it takes about 320 ms with MSDA. Most of the overhead is however related to the SOAP processing of the service call (the same discovery using a socket-based implementation of the MSDA service takes about 105 ms).

V. CONCLUSION

Performance evaluation highlighted the high cost of service discovery in MSDA compared to existing SDPs and INDISS. This overhead is directly related to the service API of MSDA, which is required for any enhanced service discovery protocol. For local interactions (i.e., within the same administrative domains such as an intranet or home network), the INDISS approach is therefore more appropriate as it supports responsive applications. We are evaluating the combination of the two approaches in the context of the IST Plastic project. A potential integration is to use INDISS for translating service announcements and discovery requests between SD specific format and the MSDA format (i.e., replacing the SDA plugins). Most SDP interoperability projects do not investigate the interoperability of service access protocols [START_REF] Friday | Supporting service discovery, querying and interaction in ubiquitous computing environments[END_REF] [START_REF] Koponen | Service Discovery: A Service Broker Approach[END_REF]. However, addressing this issue is crucial as discovering services that cannot be accessed is inconsistent/incoherent. Interoperability of service access protocols either relies on additional code [START_REF] Allard | Jini Meets UPnP: An Architecture for Jini/UPnP Interoperability[END_REF] or reflection support [START_REF] Grace | ReMMoC: A Reflective Middleware to Support Mobile Client Interoperability[END_REF]. We are now investigating service access for both projects. In Amigo, we reuse event-based parsing techniques to design NEMESIS as an independent layer providing service access interoperability. For the MSDA platform was currently focus on supporting service access in multi-networks configuration. The INDISS/MSDA comparison also highlights the differences in the Amigo and UBISEC approaches for supporting interaction between clients and services. While UBISEC puts forward a integrated platform for context-aware service discovery and access in multi-networks environment, Amigo provides independent solutions for service discovery (INDISS), service access (NEMESIS), or context management. The UBISEC approach enables a better integration of the different facets (discovery, access, context) in its components allowing, for example, the use of context information to limit the dissemination of service information. Amigo however promotes reusability, supports a better distribution of the time-consuming tasks to the appropriate devices in the network, and better supports updates of existing components.

  Figure 1: INDISS Architecture

Figure 2 :

 2 Figure 2: MSDA Architecture

Table 1 :

 1 INDISS and MSDA Comparison

				MSDA/UBISEC
		Networking environment
	Home networks			B3G Networks
	-heterogeneous networks within	-dynamic composition of
	same administrative domain		independent networks
		Interoperability requirements
	Lightweight discovery		Enhanced discovery (context,
	Applicable to CE devices		security)
	No infrastructure building		Multi-networks discovery
	Approach to SD interoperability
	Translation of SDPs messages	Integration of SDPs
	-transparent discovery		-explicit API
	-network messages interception	-enhanced service description
	-event-based	parsing	and	-client-side interoperability
	composition
			Strengths
	Transparent to clients & services	Context-aware discovery
	Limited resources requirements	Multi-network support
	Easy deployment			Controlled dissemination
			Weakness
	Limited network reach		Requires client support
	Intersection of SD information	High processing requirements

IST Amigo project: http://www.amigo-project.org/

IST UBISEC project: http://www.ubisec.org/

IST Plastic project: http://www.ist-plastic.org/


Adolf Abdallah
email: adolf.abdallah@lifl.fr

Abdoulaye Gamatié
email: abdoulaye.gamatie@lifl.fr

Jean-Luc Dekeyser
email: jean-luc.dekeyser@lifl.fr

MARTE-based Design of a Multimedia Application and Formal Analysis

Digital television (DTV) is an advanced broadcasting technology that is spreading fast today. It gives broadcasters the capability to send programs with a better picture and sound quality. Moreover, broadcasters can send several programming choices, called multicasting. DTV consists of a high-performance system combining both control and intensive data processing. In this paper, we first show how the OMG MARTE profile can serve to model such a system. Then, we use the synchronous approach to formally check some temporal properties of the expected system implementation for validation purpose.

I. INTRODUCTION

A. Context and motivation

In distributed multimedia applications, the amount of data computation is exponentially increasing and is becoming more and more complex. One reason to that is the simultaneous streaming video which requires a large amount of computing resources.

To face this challenging design problem, numerous solutions have been proposed. Model Driven Engineering (MDE) is one of them. It has been initiated by the Object Management Group (OMG). In MDE, models are considered as primary engineering artifacts and can be applied to describe various aspects of a system, e.g. software, hardware.

The study presented in this paper deals with the modeling and analysis of high-performance systems according to the MARTE (Modeling and Analysis of Real-time and Embedded systems) profile [START_REF]A uml profile for MARTE[END_REF]. We use the repetitive structure modeling to specify the data-intensive part and the TIME sub-profile to describe the temporal properties of system implementation. In order to formally validate the modeled design, these properties are analysed using the specific notion of affine clocks of the synchronous language SIGNAL [START_REF] Le Guernic | Polychrony for System Design[END_REF]. The whole study is illustrated on a system example consisting of a digital television.

B. Case study: digital television (DTV)

1) Overview of the DTV process: DTV 1 is an advanced broadcasting technology where TV signals are delivered in a much more efficient way than the current analog TV. Clearer picture and sound are one of the advantages of DTV. Other enhancements are the wide screen picture and the multiple channel emission (multicasting) or parallel streaming. An easy way to visualise the great advantage of the DTV is to consider a live sporting event such as a soccer tournament. Some of the soccer fans watching the game on TV prefer to walk 1 http://electronics.howstuffworks.com/dtv.htm.

around the field with their favourite player. Others would like to watch the game from a global view. This kind of interaction is possible in DTV through the parallel streaming technology. DTV allows a variety of screen formats: 640*480 pixels, 1080*720 pixels and 1920*1080 pixels.

Fig. 1 describes the process from the beginning, by taking several pictures per second, to the end by displaying these pictures on the consumer's screen. The process begins with a DTV camera in the field taking approximately 60 pictures per second. Here, four data streams corresponding to four different channels, are processed in parallel. These multiple data streams are then combined into one signal on a shared medium using a multiplexer.

2) Downscaling and compression: A high definition (HD) image emission constitutes a flow of 75 Mbytes per second. The DTV bandwidth is 19.39 Mbytes per second, which is five times greater that the bandwidth of standard TV signals.

A two phase treatment is done on the video image sequence so that the four channels can fit the bandwidth all together. Fig. 1 depicts the different computations that are applied to the HD images. First, a typical downscaler converts the HD video signal (1920,1080) to a standard definition (SD) video signal (640,480). The downscaling process contains two treatments. The first is an horizontal filter, HF, which reduces the number of pixels in a line from 1920 down to 640 by interpolating packets of six pixels. The second is a vertical filter, VF, which reduces the number of lines in a frame from 1080 down to 480 by interpolation packets of six pixels.

Once the video is downscaled, the data streaming must be compressed so that all four channels can fit the bandwidth. Therefore, DTV uses MPEG-2 compression to conserve as much bandwidth as possible.

3) MPEG-2 compression: In MPEG-2, a bit rate reduction system operates by removing redundant information from the signal at the coder prior to transmission.

It then inserts the lost information through the decoder. Nevertheless, MPEG-2 uses the transport stream protocol on the bytes received from the downscaler. This protocol was designed to carry digital video over medias that are possibly lossy (e.g. broadcasting). The basic unit of this protocol is a 188 bytes packet. The MPEG coder receives a flow of 160 bytes payload from the downscaler and adds to it a sync byte, three one-bit flags and a 13-bit PID.

Using this technique, it is possible to transfer several video channels simultaneously over the same frequency channel. Once the consumer receives the numerous packets through the shared medium, a reverse process is applied on these packets. Using a De-multiplexer, the original channels are extracted. These channels, represented as a flow of 188 bit packets, are afterwards decompressed using the MPEG-2 reverse algorithm.

In the next sections, we use the GASPARD design environment [START_REF]GASPARD design environment[END_REF], which is devoted to the development of highperformance embedded systems based on the MDE approach. Several transformation chains provided in the environment for code generation towards different target technologies: synchronous languages for formal validation, SystemC for simulation, VHDL for circuit synthesis, etc.

The remainder of the paper is structured as follows: in Sections II and III, we respectively address the modeling of functional and implementation-related aspects of the DTV example. We mainly use the MARTE repetitive and time structures. In Section IV, we introduce the SIGNAL language, which is used to analyze non functional properties of the DTV model. Finally, we give concluding remarks in Section V.

II. MODELING OF FUNCTIONAL ASPECTS A. Repetitive structure modeling in MARTE

The repetitive structure modeling (RSM) package of MARTE [START_REF]A uml profile for MARTE[END_REF] proposes concepts that enable to describe both data parallelism and task parallelism in embedded systems. It originally relies on the domain-specific language ARRAY-OL dedicated to intensive multidimensional signal processing [START_REF] Boulet | Formal Semantics of ARRAY-OL, a Domain Specific Language for Intensive Multidimensional Signal Processing[END_REF]. Fig. 2 depicts the basic stereotypes associated with the RSM package. Due to lack of space, we only detail the stereotypes that are necessary to understand the model of DTV functionality presented in Section II-B.

According to the execution model of ARRAY-OL, a dataparallel task T is repeated or replicated into several task instances {T i,i∈1..k } that take as inputs subsets of data extracted from the inputs of T , which are multidimensional arrays. These subsets of array elements are referred to as patterns or tiles. For a given task repetition, the number k of task instances T i is given by the repetition space associated with the repetitive task T .

The Tiler stereotype, described in Fig. 2, expresses how multidimensional arrays are tiled by patterns. When applied to a delegation connector, a Tiler connects an external port with a port of an internal part. The shape of the external ports defines the shape of input/output arrays of a task. The port shape of the internal part defines the pattern shape and the shape of the part itself defines the repetition space. A tiler uses three main information (see the attributes of the corresponding stereotype) to define the tiling operation:

• origin vector, which specifies the origin of the reference tile in the array; • fitting matrix, which specifies how the patterns are filled with array elements; • paving matrix, which specifies how an array is covered by pattern elements. The Reshape stereotype extends the UML2 Connector metaclass. It enables to represent complex link topologies in which the elements of a multidimensional array are redistributed in another array. The major difference between the Tiler and Reshape stereotypes is that the former is used for delegation connector (i.e. between the port of a component and the ports of its parts) and the latter is used for connector that link two parts. The InterRepetition stereotype is used to specify a data dependency between repetitive task instances. For a full description of all these stereotypes, the reader may refer to the specification document of MARTE.

B. Modeling of the DTV functionality

A pixel represents the intensity of the three basic colours red, green and blue. The number of colors that can be represented depends on the number of bits that constitute the pixel. For instance, common values are 8 bit per pixel, 16 bpp, 24 bpp and 48 bpp. The latter is used in high quality scanners. In our modeling, we consider that each pixel is composed of 8 bits that can represent 256 colours. Note that since the DTV system aims at providing consumers with multiple channel emission (multicasting), there should be more than one image source. Actually, DTV comprises four synchronized cameras producing image flows that can be potentially displayed on a screen simultaneously according to consumer's demand.

To illustrate how the intensive data processing part is modeled with the MARTE concepts introduced previously in Section II-A, we focus on the MPEG coder specification.

Fig. 3 describes the three processes that compose the MPEGCodingDecoding component. Images are first compressed using the MPEG-2 algorithm and then are sent to the consumer through a transport stream. Once the consumer receives the compressed data, he performs a decompression on them using the MPEG-2 reverse algorithm. The patterns consumed by the MPEGMacro part consist of two-dimensional arrays: a 16*16 pixels array for luminance, and two 8*8 pixels arrays for the red and blue chrominances. The resulting outputs are a two-dimensional array mbout and a mono-dimensional array size. The outputs mbout and size are respectively the resulting compressed image and the size of the image. MPEGMacro consumes patterns from input arrays via tilers. Each tiler contains an origin vector, a fitting matrix and a paving matrix. E.g., the luminance Y is an input array of size (320,240). The MPEGMacro consumes patterns composed of 16*16 pixel arrays. The paving matrix, valued ((0, 16), (16, 0)), enables to determine the origin of each pattern associated with a repeated instance of MPEGMacro. The fitting matrix, valued ((1, 0), (0, 1)), enables to fill compact rectangular patterns with array elements.

The downscaling process is done automatically through an option in the digital camera video. Here, the pictures received by the broadcaster are assumed to have been already downscaled. For more details on the specification of the downscaling process using the repetitive structure modeling, the reader can refer to [START_REF] Boulet | Array-OL revisited, multidimensional intensive signal processing specification[END_REF].

III. MODELING OF TEMPORAL ASPECTS

A. Time specification in MARTE

Time is present in different design activities of an embedded system: specification, design, validation, etc. The sub profile TIME of MARTE has been introduced to model timing aspects during system design [START_REF] André | Modeling time(s)[END_REF]. In MARTE, logical clocks as well as physical clocks can be defined. The main difference between physical and logical clocks is that the former has a reference to physical time while the latter has a reference to events. The occurrences of these events define the clock instants, also referred to as ticks. Fig. 7 depicts the MARTE extension about time modeling in UML. The ClockType stereotype is related indirectly to the Clock stereotype. A ClockType is a classifier of clock which means that the former defines the characteristics of the represented time in the latter through its attributes. The attribute Standard of the clock stereotype is a reference to time system adopted by the clock. It is not defined in logical clocks. The attribute nature of the ClockType stereotype specifies whether the time is discrete or dense. UnitType is the different type of units supported by the ClockType. The Boolean attribute isLogical specifies whether the ClockType stereotype reads a logical time or a physical time. When it is true, the clock reads logical time. Otherwise, it reads a chronometric time. The maxValAttr attribute refers to the maximal value of the associated clock, value at which the clock rolls over. Finally, the resolAttr attribute determines the resolution of the associated clock.

B. Modeling of DTV implementation properties 1) Clock specification using MARTE profile:

In this section, we define for the DTV application logical clocks as well as their associated properties in a high level specification using the TIME sub-profile of MARTE. First, we show how to create logical clocks and then how to make use of them. Each of the different applications composing the DTV system works according to different rhythms. For example, the HD camera (representing the sensor in Fig. 1) emits a flow of pixels continuously in time and over a certain frequency. Therefore, we attach to the sensor the logical clock C1 defined previously. The unit of C1 is the pixel production.

Once the broadcaster receives the image flow, these images are compressed using the MPEG-2 algorithm. Coding and decoding works on the same rhythm and thus are considered as synchronous. The MPEG coding algorithm, the transport stream and the decoding algorithm have the same clock MpegPacketClock. Therefore, we assign the clock C2 to the MpegCodingDecoding component.

On the other hand, a buffer is inserted between the MPEG decoder and the display process so that it gathers the different parts of the picture. Thus, we attach to the Display process the logical clock C3 which is an instance of the DisplayClock clock. Fig. 9 specifies the clock assignment for the whole system. To assign a clock instance to a process, we create a class with the process as its classifier. Then, we stereotype this class with TimedProcessing and we specify the corresponding clock using the meta-attribute on.

2) Constraint specification using MARTE profile: In the previous section, we have instantiated the PixelProduction-Rate and called it C1. The clock C1 has three attributes, resolution with the value 1 which means that its rhythm is the same as the Base clock, an offset with the value 0 and a maximalValue which is infinite. In the same way, the clocks C2 and C3 are assigned to the MpegCodingDeconding and Display processes.

The MPEG coding treats blocks of 16 * 16 pixels. This is equivalent to say that the MpegCodingDeconding component is activated every 16 * 16 th tick of the clock associated with camera1 component. We can deduce an affine relation between C1 and C2 as specified in the clock constraint specified in Fig. 9: C2 = PeriodicOn C1, period = phi 1, offset=d 1. Such a constraint states that each phi 1 th occurrence of C1 there will be an occurrence of C2 and the first occurrence of C2 appears at the d 1 th instant of C1. Here, one may consider that phi 1 = 16*16 if the clock C1 corresponds to the pixel production rate.

In addition, during the execution of the DTV system, an image is displayed only when the buffer inserted between the MPEG decoder and the display contains all pixels that form complete images. This also induces another affine relation between C2 and C3, which is also specified in Fig. 9.

IV. ANALYSIS OF DESIGN PROPERTIES

Now, we address the formal analysis of the temporal properties specified in the previous section. We consider an encoding of the identified the clock constraints using synchronous languages, which offer very suitable tools to deal with logical clock properties in system design. In the next, we first introduce the SIGNAL language. Then, we use its concepts to reason on clock constraints.

A. The synchronous language SIGNAL 1) Overview of basic concepts: The synchronous language SIGNAL [START_REF] Le Guernic | Polychrony for System Design[END_REF] belongs to the family of data-flow languages. It handles unbounded series of typed values (x τ ) τ ∈N , called signals, denoted as x and implicitly indexed by discrete time. At a given instant, a signal may be present, at which point it holds a value; or absent and denoted ⊥. The set of instants where a signal x is present represents its clock, noted ˆx. Two signals x and y, which have the same clock are said to be synchronous, noted x ˆ= y. A process (or node) is a system of equations over signals that specifies relations between values and clocks of the signals. A program is a process. SIGNAL relies on the following six primitive constructs: SIGNAL offers a process frame that enables the definition of sub-processes (see the where part in Fig. 11).

2) Affine clocks: In order to address clock synchronization issues in the DTV application, we consider the affine clock notion of SIGNAL. Affine clocks have been defined as an extension of the usual clock notion of SIGNAL so as to enable the modeling and validation of real time systems with intensive data processing [START_REF] Smarandache | Validation of mixed SIGNAL-ALPHA real-time systems through affine calculus on clock synchronisation constraints[END_REF]. In affine clock systems, two different signals are said to be synchronizable if there is a dataflow preserving way to make them actually synchronous. The SIGNAL clock calculus (i.e. its static analysis phase) has been extended in order to address such synchronizability issues with the associated compiler.

c 1 : tt ⊥ ⊥ tt ⊥ ⊥ tt ⊥ ⊥ tt ⊥ ... c 2 : ⊥ tt ⊥ ⊥ ⊥ tt ⊥ ⊥ ⊥ tt ⊥ ...

B. Dealing with synchronisation issues in DTV

As described in Fig. 9, there are three identified logical clocks in the system: C1, C2 and C3, which are respectively associated with the Camera, MpegCodingDeconding and Display components. The relations between these clocks are affine. Therefore, we can use SIGNAL affine clocks to encode these clock relations in the DTV as follows:

(P 1 ): c 1 (1,ϕ1,d1) → c 2 and (P 2 ): c 2 (1,ϕ2,d2) → c 3 ;
where c 1 , c 2 and c 3 represent respectively the affine clocks corresponding to C1, C2 and C3. The properties (P 1 ) and (P 2 ) expresses the pairwise relations between these clocks.

According to [START_REF] Smarandache | Validation of mixed SIGNAL-ALPHA real-time systems through affine calculus on clock synchronisation constraints[END_REF], various operations can be defined on affine relations. Among them, we can mention the composition operation, noted * . Typically, the above two affine relations could be composed as follows:

c 1 (1,ϕ1,d1) → c 2 * c 2 (1,ϕ2,d2) → c 3 .
The result of this composition yields a direct affine relation relation between c 1 and c 3 . It has been demonstrated that it is equivalent to: c 1 (1,ϕ1+d1ϕ2,d1d2) → c 3 . The above clock relations formally characterize a logical temporal behavior of our DTV system model. This description can be used to reason now about some system requirements as illustrated below. For instance, if a television broadcaster wants to address the quality of service (QoS) of the images sent to the consumers, he may need some particular image production rates that will provide consumers with a very high quality image display. In this context, let us consider a QoS criteria that requires an image display frequency such that the following constraint between the above pixel production rate c 1 and a new image display rate c 4 are satisfied:

(P 3 ): c 1 (1,ϕ3,d3) → c 4 .
We can use affine clocks to check the compatibility of the QoS constraint P 3 with the design constraints P 1 and P 2 . By compatibility, we mean that the respective clocks c 3 and c 4 , associated with image display rate in design and QoS, are synchronizable. The following equivalences allows one to straightforwardly check the synchronizability of these clocks:

ϕ + d 1 ϕ 2 = ϕ 3 and d 1 d 2 = d 3 .
Fig. 11 shows a SIGNAL program that describes the above clock relations in the DTV system: P 1 , P 2 and P 3 . This program called DTV, takes as input a clock c1 representing the pixel production rate (line 3), and generates the other clocks mentioned before: c2, c3 and c4 (line 4). The parameters of the identified affine relations are specified here as static parameters of the SIGNAL program (line 2). The affine relation is encoded by the affine sample sub-process defined from line 10. For more details on this specific process, the reader can refer to [START_REF] Besnard | SIGNAL reference manual[END_REF].

In order to address the previous synchronizability constraint with the SIGNAL compiler depending on particular parameter values, we have to explicitly specify the constraint in the DTV program. The equations of Fig. 12, which encode the constraint, are therefore inserted in the program after line 7. Using the resulting modified program with the SIGNAL compiler, one is able to formally check the compatibility of the design properties and the QoS requirement according to particular values of affine relation parameters.

V. CONCLUSIONS

In this paper, we showed how the concepts of the MARTE standard profile can serve to model high-performance multimedia applications. We used the repetitive structure modeling to describe the data intensive part, and the TIME sub-profile to specify temporal properties of these applications w.r.t. particular implementation choices. This has been illustrated on a simplified case study consisting of a digital television. On the other hand, we showed how synchronous languages, such as SIGNAL, are used to encode and analyze some temporal properties of the resulting model for formal validation purpose.

Beyond the specific topic of this paper, the richness of the MARTE profile in terms of concepts offers an interesting common modeling basis to adequately specify many design features of embedded systems, from both software and hardware viewpoints. As a complement, powerful techniques and tools already exist, which enable to analyze the properties of obtained models. All this favors development frameworks where design exploration is made efficient. This is the major goal of environments such as GASPARD, which already adopts the MARTE profile, and integrates different target technologies for formal verification, system simulation and execution, and circuitry synthesis.

Fig. 1 .

 1 Fig. 1. An overview of the DTV system.

Fig. 2 .

 2 Fig. 2. RSM package specification in MARTE.

Fig. 3 .

 3 Fig. 3. A zoom on the MPEGCodingDecoding component.

Fig. 4 .

 4 Fig. 4. A partial view of the DTV system model.

Fig. 4

 4 Fig.4depicts a partial view of the DTV system model. Only one camera, called Cam, is shown here for the sake of clarity. Note that since the DTV system aims at providing consumers with multiple channel emission (multicasting), there should be more than one image source. Actually, DTV comprises four synchronized cameras producing image flows that can be potentially displayed on a screen simultaneously according to consumer's demand.To illustrate how the intensive data processing part is modeled with the MARTE concepts introduced previously in Section II-A, we focus on the MPEG coder specification.Fig.3describes the three processes that compose the MPEGCodingDecoding component. Images are first compressed using the MPEG-2 algorithm and then are sent to the consumer through a transport stream. Once the consumer receives the compressed data, he performs a decompression on them using the MPEG-2 reverse algorithm.

Fig. 5 .

 5 Fig. 5. Model of the MPEG coder.

Fig. 6 .

 6 Fig. 6. Data-parallelism in the MPEG coder.

Fig. 6

 6 Fig. 6 depicts our specification of the MPEG coder itself using a repetitive task MPEGCoder expressing data parallelism. The execution of MPEGCoder is such that its part, represented by MPEGMacro, is replicated into 20*15 instances. The multiplicity notation [{20, 15}] denotes the repetition space of the MPEGCoder task.

Fig. 7 .

 7 Fig. 7. TIME Sub Profile specification. The clock stereotype is a model element that represents an instance of ClockType and extends the InstanceSpecification of UML. It can be only applied to instance specifications of a class stereotyped by ClockType. A clock is characterised by its resolution, and optionally by an offset and a maximal-Value. The unit type of a clock by default is tick.The ClockType stereotype is related indirectly to the Clock stereotype. A ClockType is a classifier of clock which means that the former defines the characteristics of the represented time in the latter through its attributes. The attribute Standard of the clock stereotype is a reference to time system adopted by the clock. It is not defined in logical clocks. The attribute nature of the ClockType stereotype specifies whether the time is discrete or dense. UnitType is the different type of units supported by the ClockType. The Boolean attribute isLogical specifies whether the ClockType stereotype reads a logical time or a physical time. When it is true, the clock reads logical time. Otherwise, it reads a chronometric time. The maxValAttr attribute refers to the maximal value of the associated clock, value at which the clock rolls over. Finally, the resolAttr attribute determines the resolution of the associated clock.

Fig. 8 (

 8 a) depicts the definition of a logical clock. We have created a class PixelRateClock with ClockType as stereotype. This class has three attributes: MaximalValue, offSet and resolution. MaximalValue specifies the maximal value of the

Fig. 8 .

 8 Fig. 8. Creation of logical clocks.

Fig. 9 .

 9 Fig. 9. Specification of clock properties in DTV.

  Relations. y:= f(x1,...,xn) def ≡ ∀τ ≥ 0 : yτ ̸ =⊥⇔ x1τ ̸ =⊥⇔ ... ⇔ xnτ ̸ =⊥, and yτ = f (x1τ , ..., xnτ ). Delay. y:= x $ 1 init c def ≡ ∀τ xτ ̸ =⊥⇔ yτ ̸ =⊥ and ∀τ > 0: yτ = x k , where k = max{τ ′ | τ ′ < τ and x τ ′ ̸ =⊥}, y0 = c. Undersampling. y:= x when b where b is Boolean def ≡ ∀τ ≥ 0 : yτ = xτ if bτ = true, else yτ =⊥. The expression y:= when b is equivalent to y:= b when b. Deterministic merging. z:= x default y def ≡ ∀τ ≥ 0 : zτ = xτ if xτ ̸ =⊥, else zτ = yτ . Composition. (| P | Q |) def ≡ union of the equations of P and Q. This operator is commutative and associative. Hiding. P where x def ≡ x is local to the process P.

Definition 1 : 1 (

 11 An affine transformation of parameters (n, ϕ, d) applied to a clock c 1 produces a clock c 2 by inserting (n -1) instants between any two successive instants of c 1 , and then counting on this fictional set of instants each d th instant, starting with the ϕ th . Clocks c 1 and c 2 are said to be in (n, ϕ, d)-affine relation, noted as c

Fig. 10 .

 10 Fig. 10. Trace where c 1 and c 2 are in (3, 1, 4)-affine relation.

  Fig. 11. Specification of affine clock relations in SIGNAL.

  Fig. 12. Specification of a clock synchronizability constraint.