A Grid for process control Fabrice Sabatier, Suplec , - - PDF document

▶
a grid for process control
SMART_READER_LITE
LIVE PREVIEW

A Grid for process control Fabrice Sabatier, Suplec , - - PDF document

Mar 17, 2023 412 likes •563 views

A Grid for process control Fabrice Sabatier, Suplec , Fabrice.Sabatier@metz.supelec.fr Amelia De Vivo , Universita di Salerno, amedev@unisa.it Stphane Vialle , Suplec, Stephane.Vialle@supelec.fr Action Concerte Incitative [ACI]

slide-1
SLIDE 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
  • too constraining for the physical process mission
slide-2
SLIDE 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

slide-3
SLIDE 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

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

slide-4
SLIDE 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 based Grid 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)

slide-5
SLIDE 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

slide-6
SLIDE 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 services

slide-7
SLIDE 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 localisation srv 1 DIET server A navigation srv 2 localisation srv 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
slide-8
SLIDE 8

Phase 2

High Level Grid Interface: RobGrid

Robotic applications on the Grid Low level 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:

  • Connection to the related service of the robot server
  • Reset of the result buffers on the robot server
  • Robotic operation (ex: navigation, localization, …)
  • Disconnection from the robot server

Look at RobGrid library Implement quickly a new one (calling RobGrid internal objects) Need a high-level Grid service for robot control ?

slide-9
SLIDE 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

  • bject 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)

slide-10
SLIDE 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 …

slide-11
SLIDE 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

Fault tolerance experiment

slide-12
SLIDE 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

Phase 4 …

slide-13
SLIDE 13

Questions ?

A Grid for process control