FraSCAti, prenez le contrôle sur vos applications

National audienceContrôler les applications en cours d'exécution n'est pas chose aisée. Nous présentons dans cet article différents moyens permettant de reprendre la main sur vos applications grâce à FraSCAti. Dans le numéro précédent, nous avons vu comment SCA simplifie la réalisation d'applications orientées services tout en donnant un cadre architectural (SOA facile avec SCA). Nous allons ici nous intéresser à une autre préoccupation: comment observer une application en cours d'exécution, modifier sa configuration initiale, ou la faire évoluer sans la redéployer ? FraSCAti traite ces différentes problématiques en supportant la reconfiguration dynamique d'assemblages SCA. Nous les mettrons en pratique à l'aide de l'exemple introduit dans l'article précédent: MyWeather. Pour rappel, cet exemple permet d'interroger un compte Twitter afin de récupérer la localisation de l'utilisateur puis d'interroger un service météo pour connaître la météo à cette localisation. Nous compilerons cet exemple avec un script spécifique (compile, fourni avec les sources) afin de pouvoir développer un service technique (intent) intégré dans la plateforme FraSCAti

Une extension de Fractal pour l'AOP

National audienceNous présentons dans ce papier une manière originale de représenter les préoccupations transverses au sein d'une architecture à base de composants Fractal sous forme de liaison que nous nommons liaison transverse. Cette liaison permet de représenter de manière claire les intéractions entre composants et composants d'aspect qui incarnent les préoccupations transverses. Chaque préoccupation tissée à l'architecture logicielle modifie la structure en introduisant un nouveau composite contenant le composant d'aspect et l'ensemble des composants concerné par la coupe qui sont alors partagés dans ce nouveau composite. Notre représentation par liaison du tissage nous permet d'offrir une API d'introspection de coupe suffisament riche pour donner différentes vues sur l'ensemble des coupes s'appliquant sur une application

Scheduling of a Cyber-Physical System Simulation

The work carried out in this Ph.D. thesis is part of a broader effort to automate industrial simulation systems. In the aeronautics industry, and more especially within Airbus, the historical application of simulation is pilot training. There are also more recent uses in the design of systems, as well as in the integration of these systems. These latter applications require a very high degree of representativeness, where historically the most important factor has been the pilot’s feeling. Systems are now divided into several subsystems that are designed, implemented and validated independently, in order to maintain their control despite the increase in their complexity, and the reduction in time-to-market. Airbus already has expertise in the simulation of these subsystems, as well as their integration into a simulation. This expertise is empirical; simulation specialists use the previous integrations schedulings and adapt it to a new integration. This is a process that can sometimes be time-consuming and can introduce errors. The current trends in the industry are towards flexible production methods, integration of logistics tools for tracking, use of simulation tools in production, as well as resources optimization. Products are increasingly iterations of older, improved products, and tests and simulations are increasingly integrated into their life cycles. Working empirically in an industry that requires flexibility is a constraint, and nowadays it is essential to facilitate the modification of simulations. The problem is, therefore, to set up methods and tools allowing a priori to generate representative simulation schedules. In order to solve this problem, we have developed a method to describe the elements of a simulation, as well as how this simulation can be executed, and functions to generate schedules. Subsequently, we implemented a tool to automate the scheduling search, based on heuristics. Finally, we tested and verified our method and tools in academic and industrial case studies

Étude de l'invocation entre objets dupliqués dans un système réparti tolérant aux fautes

This dissertation studies the problems to solve in order to use the invocation paradigm to express replicated object communication in fault-tolerant distributed systems. The ultimate goal is to define abstractions which achieve replication encapsulation, ie which give the illusion that replication is an internal property of objects. Thus, object communication could be always expressed using the invocation paradigm, whether objects are replicated or not. Background The invocation paradigm defines a "request-reply" communication model which matches exactly the client-server model. The latter is generally used to express service interactions in distributed systems. For this reason, the object-oriented approach is well suited to the design of distributed system services. A service can be implemented as a set of objects, located on remote computers (or nodes). Service fault-tolerance is achieved by replicating the objects which implement the service. Most of the previous works about replicated objects consider only server object replication. This study is more general: both client and server can be replicated. Furthermore, replication policies of objects can be different. Four replication policies had been studied: active replication, passive replication, semi-active replication, and coordinator-cohort replication. Replication encapsulation Replication encapsulation means both plurality encapsulation and replication policy encapsulation. Plurality encapsulation consists in hiding from other objects, that a replicated object is actually a set of replicas located on several nodes. Replication policy encapsulation consists in hiding from other objects, the communication protocol to use in order to interact with object replicas without breaking their consistency. The symmetric invocation model Most of the related works are based on an asymmetric invocation model. In this model, the invocation reply follows exactly the reverse of the request communication path. The asymmetric invocation model can not be used to achieve replication encapsulation of client objects. This dissertation proposes a symmetric invocation model which solves this problem. The symmetric invocation model considers the request transmission and the reply transmission as two instances of the same problem: the transmission of a message to a replicated object. Both the analysis of the replication encapsulation problem and the symmetric invocation model were used to define a specification of replicated object invocation. This specification is a set of generic formal properties based on parameters which values depend on replication policies. The properties include object failure semantics which is expressed using the group paradigm and the view-synchronous communication paradigm. Every replicated object is built using an object group which membership changes whenever object replicas fail or restart. The N2M invocation service The main result of this study is the design1 of N2M, an invocation service which supports replicated objects. Objects using N2M are called application objects whereas objects implementing N2M are called communication objects. Communication objects take care of every aspect related to application object replication. Thus, replicated application objects communicate using regular invocations, just as if they were not replicated. There are actually two kinds of communication objects: encapsulators and mailers. Each replicated application object is built using an encapsulator group. Each application object replica is associated with a private encapsulator which acts as an invocation filter for this replica. To communicate with a replicated application object O, every object must interact with O's local mailer. On every node, a replicated application object is represented by a mailer which is responsible for transmitting requests and replies to the application object replicas. The originality of this model is its symmetry: there are both mailers of the server on the client nodes, and mailers of the client on the server nodes. This symmetry is directly inherited from the symmetric invocation model. Each replication policy is implemented using an encapsulator class and a mailer class. These classes replicate objects according to a specific replication policy, while respecting the invocation paradigm. In other words, communication object classes achieve replication encapsulation. The GARF-v2 programming environment The N2M service has been implemented in the context of the GARF project2. The GARF project aimed to provide a programming environment which faciltates the design of fault-tolerant distributed applications. The environment prototype was implemented in Smalltalk. It is based on the group communication layer provided by ISIS toolkit. ---------------------------------------   1this logo refers to the n to m expression which usually names the interaction between n client replicas and m server replicas.   2GARF is the french acronym for automatic generation of fault-tolerant applications

Solutions de stockage de l'énergie éolienne : rapport interne

L’énergie électrique est depuis très longtemps traitée comme une denrée de consommation courante. Elle est omniprésente, transparente et circule autour de nous afin d’être utilisée rapidement, facilement et dans la plupart des cas à moindre frais [FAU 2003]. Mais bien souvent, la production de cette énergie est très délocalisée par rapport à son utilisation. Cette délocalisation ainsi que la pénétration des sources variables et fluctuantes (énergies renouvelables : solaire, éolienne, etc.) augmentent les difficultés de stabilisation du réseau électrique, en raison essentiellement d’un déséquilibre entre production et consommation. Il convient alors de générer cette énergie, de la transporter, de la convertir et si besoin de la stocker

Surveillance du réseau de l'expérience LHCb

In the new experiment for the LHCB CERN, we have a lot of devices to monitor. Especially the system has about 400 hundred of HP Ethernet switches and a TerasCale router switch. These devices are monitored via SNMP. In our application we are using a SCADA system (PVSS) to integrate the monitoring of network in our sub system. With Framework component we can send or receipt information from a server via DIM We have two type of the network. Control network and data's one. Both of them need to be monitored by PVSS that we use with the framework component: especially DIM. This component permits to use information got by a server and may get some action to be applied in this server via command. In LHCB network we have a big number of Ethernet switch's to be monitored. Basically we have a HP 3400 switch's and TerasCale switch this one is the bigger switch to be used in a data acquisition network (1260 ports) and also a lot of PCs. The switch monitoring use SNMP witch must be configured and integrated to lhcb system control using PVSS (SCADA system). The configuration for this device should be programmed using library tools like expect. The all should be integrated to the distributed control system. At the end of my placement we have tested this project using a network processor. We use data base to read all necessary information for all device in network monitoring system