• No results found

A Grid for process control

N/A
N/A
Protected

Academic year: 2021

Share "A Grid for process control"

Copied!
13
0
0

Loading.... (view fulltext now)

Full text

(1)

A Grid for process control

Fabrice Sabatier, Supélec, Fabrice.Sabatier@metz.supelec.fr

Amelia De Vivo, Universita di Salerno, amedev@unisa.it

Stéphane Vialle, Supélec, Stephane.Vialle@supelec.fr

Action Concertée Incitative [ACI] Globalisation des Ressources Informatiques

et des Données [GRID]

Long term goals / Why to use a

Grid for process control ?

• To connect a physical process to “computing power” like to electrical power !

• Physical processes are installed where they are needed: • can be far of computing centers,

• can be in computer hostile environment, • can be far of computer maintenance people, • ….

• Embedded large computing power can be: • too much power consuming

• too much expensive

(2)

Long term goals / Why to use a

Grid for process control ?

• Access to:

- large computing power

- redundant computing (for fault tolerance) - remote control and maintenance

- up to date process control libraries (grid services) - unlimited history saving mechanisms

Process control Grid

Small embedded computing units & connection to the Grid

“Step by Step” integrated project

Incremental development and deployment with frequent performance measurements

Project Road Map

A Grid for process control

(3)

Approximate road map

Phase 1 – 2002-2003:

• P2P connection France-Italy across “ssh-link” • Experiment remote control across Internet

(robot server + client applications)

• Performance measurements

• Optimization of the robot control algorithms

(serial optimization, multitreading, hyperthreading, MPI, computation-communication-mechanical move overlapping)

4-proc. PC PC cluster France Italy robot server ssh-link 0 20 40 60 80 100 120 140 date T-localisation (s)

JPEG & Sequential JPEG & overlapping JPEG & overlap+MPI Best local timel

20h 8h 21h

ACI-GRID ARGE

Approximate road map

Phase 2 – 2003-2004:

• Deployment of a light Grid environment across Internet

(Internet/VPN/Corba/GridRPC)

• High-level services implement complex robot commands • Low-level services support redundant and concurrent calls • User friendly API development

• Grid service semantic definition (beginning) • Performance measurements

• Fault tolerance experiment and achievement

multiprocessors cluster robot server DHCP, DNS, LDAP server firewall gateway router router Eth. Gigabit LAN Internet LAN France Italy firewal +server Grid soft. architecture Application RobGrid API DIET-GridRPC CORBA VPN-IPSEC Int/Ethernet ACI-GRID ARGE

(4)

Approximate road map

Phase 3 – 2004-2005:

• Extension of the Grid (still VPN based):

– more sites, with different “internet distances” – several physical processes to control

• Redundancy management policy & Redundancy manager Grid services

• Improvement of socket comm.: TCP àUDT (?) • Performance measurements

Hercule ?

Join us!

new devices

Approximate road map

Phase 4 – 2004-?:

• Deployment of a Globus basedGrid environment

• Grid service portage: VPN/Corba/GridRPCà“Globus/XXX” • API improvement: RobGrid API àProCtrlGrid API

• Monitoring and accounting • Performance measurements

Electrical power (electrical grid) Computing power (process control grid)

(5)

2003-2004 Using DIET on a VPN

Real deployment across France and Italy

Details on phase 2

A Grid for process control

Phase 2

Short term goals

• To be fault tolerant

• To share our robotic system with our (distant) partners • To support special applications

needing extra CPU

• To efficiently process embarrassingly parallel applications

• To dynamically switch to unloaded machines, avoiding to devot machines

(6)

Phase 2

Robot & Grid testbed

Grid of computing resources Robotic environment multiprocessors cluster robot server DHCP, DNS, LDAP server firewall gateway router router Eth. Gigabit LAN Internet LAN France Italy firewal +server Grid middleware Application RobGrid API DIET-GridRPC CORBA VPN-IPSEC Int/Ethernet Phase 2

Software Grid Architecture

Robotic applications on the Grid

Low-level robot commands TCP sockets Buffer control

High level robot commands

TCP Buffer ctrl Serial link Robot server Int/Ethernet VPN (IPSEC) DIET middleware (based on Corba) DIET API (GRidRPC)

High level services

Low level services

Grid middleware

(7)

Phase 2

Secure VPN

IPSEC based Needs :

• Port UDP-500 to be opened

• Protocols ESP (50) and AH (51) to be authorized

• Firewall: to reject msg from PCs without VPN certificate • Gateway:

• to establish authenticated connections • to encapsulate TCP msg in ESP msg DHCP, DNS, LDAP server Gateway Firewall router router Eth. Gigabit LAN Internet LAN France Italy Firewall Computing server

Serial port Camera Turret Wheels Resource directory navigation srv 1 localisationsrv 1 DIET server A navigation srv 2 localisationsrv 2 DIET server B VPN France Italy Client appli Master Agent Local Agent PC on the Grid Robot server Phase 2

Grid deployment & Chain of services

1. VPN-Corba-DIET

2. VPN-Corba-DIET

3. VPN-TCP 4. VPN-TCP

(8)

Phase 2

High Level Grid Interface: RobGrid

Robotic applications on the Grid

Lowlevel robot services DIET & Grid middleware services

High level DIET interface High level Grid services

(localization, navigation, lightness, …)

(Session, LocClient, NavClient, …) RobGrid main features:

• C++ library, based on GridRPC

• Client objects for easy access to high level Grid services • Manages redundant calls to high level Grid services • Hides communication initializations with any service

Phase 2

High Level Grid Interface: RobGrid

Programming new high level Grid services:

One high level Grid service = a set 4 of sub-services: •Connectionto the related service of the robot server •Reset of the resultbufferson the robot server

Robotic operation(ex: navigation, localization, …) •Disconnectionfrom the robot server

Look at

RobGrid library

Implementquickly a new one (calling RobGrid internal objects) Need a high-level

Grid service for robot control ?

(9)

Phase 2

High Level Grid Interface: RobGrid

loc->Call(); Res = loc->GetResult(); Nav->AsyncCall(x,y,theta); While(!nav->Probe()) { light->Call(); ... } loc->Call(); Res = loc->GetResult();

Part of the RobGrid object architecture Adding a new high level Grid service for robot control:

“Lightness measurement” Service has been:

• quickly developed

• quickly included in the Grid

Phase 2

High Level Grid Interface: RobGrid

Session *session = new Session(); NavClient *nav = new NavClient(2);

LightClient *light = new LightClient(1);

LocClient *loc = new LocClient(2);

Session->Start(); loc->Connect(); nav->Connect(); light->Connect(); nav->AsyncCall(x,y,theta); while(!nav->Probe()) { light->Call(); } loc->Call(); Res = loc->GetResult(); delete loc; delete nav; delete light; delete session; Application code example: navigation lightness measurement panoramic scan (localization)

(10)

Phase 2

Performance measurement

Benchmark of localization routine on the Supelec sub-Grid:

• Frequently called (strongly optimized)

0s 8.5s

Unloaded computing server alone

Unloaded computing server across the sub Grid

Sub-Grid with not unloaded servers

Local Grid performances:

no sensible overhead:

local redundant computation hide variations:

Phase 2

Performance measurement

Benchmark on 24h for localization operation across Internet:

20h-9h:

• localization across Internet is OK • slow down < 2

• regular execution time

Usable for redundant computating to achieve fault tolerance …

(11)

Phase 2

Fault tolerance experiment

Running the complete application:

« Localization + navigation + lightness measurement »

The faster localization service stops

The redundant localization service drives the camera

The faster localization service re-start

• Application don’t stop, and go on.

• Slow down is limited to the parts using a slower service. ? Fault tolerance is achieved.

Phase 2

(12)

Phase 2: main results

Design and deployment of a computing resource Grid: • [Internet – VPN – Corba – DIET – API-RobGrid – Appli]

• Low level service support concurrent and redundant calls

Design and implementation of a high-level API: • “Easy-to-use” high-level API (RobGrid)

• High-level Grid service definitions

• Standard Grid service contains and actions (Grid semantic)

Experiment of autonomous robot control across internet: • Overlapping communications, computations and mechanical moves • Fault tolerance achievement (slow-down but go on)

Phase 3 …

Scale the number of sites

Scale the number of processes to control

… to be continued !

… Install on Globus

(13)

Questions ?

References

Related documents

The evolution of this selective collective memory is reflected in the memorials and early museums dedicated to World War II that emerged in France during the immediate postwar

What we see for steel workers in Figure 8 can therefore not be interpreted as a causal impact of bene!t duration on the unemployment in&#34;ow rate, but rather as the consequence of

De este modo, aunque con desigual presencia según las condiciones naturales y la densidad de pobla- miento, las “minutas” cartográficas o los “cuadernos de líneas

Giving training and awareness to educate operatives on handling equipment using in demolition. Demolition permit must approved by

Bilateral Agreement of the KU Leuven, Belgium, and its cooperation with the Universidad de Cuenca, Ecuador. The research was made within the frame of the VLIR- IUC

For instance, rs1990620 is a known LOAD- associated variant in TMEM106B that was identified as genome-wide significant in the DLPFC region from the ROSMAP cohort and was replicated

The Internet services provider risks the loss of customers and loss of money through lawsuits for not being able to guarantee confidentiality or availability or integrity..

prosecutor’s explanation that the juror was excused based on his “young age and lack of maturity”; the prosecution is allowed to “seek jurors who are stable and mature”). 