Arhitecturi ale sistemului de comanda

Arhitecturi ale sistemului de comanda

Tehnica reglarii si planificarii sunt doua metode elementare de prelucrare a informatiilor in sistemele senzori-actuatoare.

Aceste tehnici pot sa comande si sa stabilizeze starea procesului.

Exista doua niveluri pentru a atinge aceste scopuri:

1. nivelul comenzii executiei:

La acest nivel, in sistemele reglate, la momente discrete de timp, se calculeaza marimea de comanda din abaterea erorii in bucla de reglare inchisa. Sistemul de comanda a executiei/de conducere actioneaza direct asupra procesului prin elementul de pozitionare.

La sistemele de planificare reactive se genereaza o actiune sau o secventa de comenzi pentru sistemul de comanda a executie/conducere, intr-o bucla inchisa la momente discrete de timp sau la aparitia unui anumit eveniment, din abaterea dintre starea actuala si starea tinta.

Calculul marimii de comanda din abaterea erorii, respectiv evaluarea regulilor cu interpretorul de reguli se realizeaza intr-o structura determinata de prelucrare a informatiilor. Aceasta structura contine componente de preluare a starii procesului (senzori), informatiile sunt prelucrate (regulator/planificator) si predate la componentele urmatoare (actuatoare) pentru actiunea asupra procesului. Structura sistemului de prelucrare a informatiilor, respectiv arhitectura in sine sunt statice.

2. nivelul de structurare:

La acest nivel se alege, se activeaza o structura de prelucrare a informatiilor, se traduc, respectiv se reproduc in aceste tipuri de structura planele sau comportamentele, cu scop determinat. Aceasta inseamna in tehnica reglarii o modificare dinamica intre structurile de reglare, pentru a putea reactiona la interactiunile dinamice. Analog, sistemele de planificare se adapteaza reactiv. Modificarea arhitecturii sunt procedee discrete si sunt apelate mai intai de catre modulul de supraveghere.

Notiuni de baza ale arhitecturii sistemului de comanda

Sistemele modulare complexe contin multe unitati active care interactioneaza intre ele. Aceste unitati pot sa se autostructureze prin subunitati. Pentru o influenta coordonata a mai multor unitati independente, este necesara a arhitectura a sistemului de comanda.

Arhitectura de comanda descrie, cum unitatile individuale trebuie sa interactioneze, pentru a se obtine un comportament dorit al sistemului complex.

Pentru robotii mobili sau sisteme de fabricatie cooperativa, se poate descrie comportamentul dorit printr-o combinatie intre sarcini de reglare si de conducere simultane.

Cu cat de 'inteligent' trebuie sa fie un sistem, cu atat sistemul trebuie prelucreze mai multe sarcini de situare simultan cu prioritati adecvate dinamic. Fiecare sarcina de situare inseamna atingerea sau stabilizarea: starilor interne ale sistemului, starilor externe ale sistemului sau starilor interactiunilor.

Structura de baza a arhitecturilor de comanda este bucla de reglare cu sincronizarea componentelor, la momente discrete de timp sau la aparitia evenimentelor, pentru supraveghere, planificare/reglare si comanda executiei.

La structura ierarhizata de conducere se realizeaza integrarea starilor procesului, care se obtin din mai multi senzori individuali, respectiv din sistem senzori-actuatoare, intr-o stare globala a procesului, la un nivel supraordonat. Imediat se da, de la nivelul superior, o comanda a executiei, care influenteaza procesul in obtinerea starii tinta si care se poate diviza pentru nivelul inferior, respectiv SSA. Bucla de reglare superioara comanda mai multe bucle de reglare inferioare si de aici mai multe SSA tipice (Fig. 9.1).

Un exemplu pentru comanda ierarhizata este reglarea miscarii varfului sculei pentru un manipulator cu mai multe axe, in coordonate carteziene. Bucla subordonata de reglare a situarii regleaza miscarea fiecarui element al manipulatorului. Din situarea elementelor, prin modelul cinematic direct se calculeaza pozitia varfului sculei. Modificarea dorita a pozitiei in coordonate carteziene trebuie mai apoi, prin modelul cinematic invers, sa calculeze modificarile situarilor tuturor elementelor manipulatorului.

Fig. 9.1 Comanda ierarhizata

Fig. 9.2 Comanda distribuita

La arhitectura de comanda distribuita diferite modele de stare ale procesului vor deriva din aceleasi informatii despre proces. In buclele de reglare distribuite se vor genera marimi de comanda independente pentru a atinge tinte diferite ale procesului si aceste marimi se vor transmite la modulele de executie ale comenzii corespunzatoare. Acestea utilizeaza aceleasi module de conducere respectiv actuatoare pentru a actiona asupra procesului. Un coordonator trebuie apoi sa integreze, pe baza unor stari interne speciale, actiunile generate asupra procesului (Fig. 9.2). In cazul tintelor procesului in concurenta, se va lua o decizie care dintre tinte este necesara sau se va adopta un compromis.

Un exemplu de comanda distribuita este cazul urmaririi unui vehicul, simultan cu reglarea distantei fata de obstacole (Fig. 7.6). Bucla de reglare pentru vehiculul urmaritor si minimizarea coliziunilor utilizeaza aceleasi informatii furnizate de catre scanerul cu laser rotitor de masurare a distantei. In ambele bucle se genereaza modificari ale directiei si vitezei tinta. Comanda motorului trebuie sa poata coordona ambele sarcini impreuna. Aceasta se poate realiza printr-o suma de vectori ponderati, la care sa-si modifice dinamic ponderea sau printr-o alegere simpla cu prioritati.

Arhitecturile descriu de asemenea actiunile concertate ale robotilor intr-o echipa.

Cea mai simpla forma a insumarii actiunilor este distributia componentelor dintr-o bucla de reglare la mai multi roboti (Fig. 9.3). Bucla de reglare se va realiza atunci pentru mai multi roboti si va functiona cu trecerea informatiilor de la un modul la altul, ca pe banda rulanta, pentru prelucrarea acestora, acesti roboti avand rolul a mai multi specialisti.

Fig. 9.3 Distribuirea supravegherii, planificarii si comenzii executiei

Arhitectura sistemului de comanda este considerata de cele mai multe ori statica. Aceasta inseamna ca, fluxul de informatii intre unitatile independente se va realiza printr-o retea fixa de canale de comunicare, intotdeauna cu aceleasi protocoale si modele de interactiuni. Astfel, nu se poate ajunge la un comportament nou, ci numai la cele care au fost conduse deja, respectiv in sistemele deschise, eventual divizate.

Pentru a se putea modifica dinamic arhitectura in timp, este necesara o utilare de baza pentru specificarea arhitecturii. Aceasta specificare este atat pentru instalarea automata cat si pentru adecvarea dinamica in timp a arhitecturii, in functie de necesitati. Descrierea simplicata a unei arhitecturi complexe de comanda ca ierarhica, distribuita sau hibrida este aici insuficienta. Este mult mai necesar sa se specifice formal aici: algoritmii, resursele, sistemele de comunicare, de coordonare si metodele necesare.

Bucle de reglare si modelul procesului

La arhitecturile de comanda, pentru procedeele de reglare, ca si pentru planificarea reactiva are o insemnatate de baza bucla de reglare simpla (fig. 9.4).

Fig. 9.4 Bucla de reglare simpla

Senzorii (modulul S) livreaza informatii despre starea reala a procesului y (k) . Informatiile senzorilor sunt de aici utilizate pentru modelarea starii procesului (inclusiv interactiunile) pe baza informatiilor masurabile x (k Aceasta se poate intampla prin una sau mai multe module de supraveghere/modelare (B/M Modul). Submodelele, care au doar doua marimi de intrare, sunt de multe ori legate cu module de supraveghere ale evenimentelor, astfel incat sa reactioneze la modificarea starii.

Urmatorul modul al comenzii realizeaza comparatia intre starea procesului realizata prin observatie x (k ) si starea tinta dorita x*( k >= N), care trebuie atinsa inainte ca sa fie valabil k >=N. Acest modul de reglare/planificare (R/P-Modul) produce comanda (marimea de comanda) u (k) , cu care se va micsora distanta pana la starea tinta.

Comanda va fi interpretata de urmatorul modul, cel de comanda a executiei (AS-Modul). Pentru comanda executiei, comanda u (k) descrie o stare tinta, care, intr-un interval de timp limitat, trebuie atinsa. In sistemul de comanda ierarhizat, comanda executiei contine bucle de autoreglare, ale caror cicluri subordonate de reglare, sunt prelucrate mai rapid decat bucla de reglare principala.

Se diferentiaza pe nivelurile de stare ale procesului, procedeele de reglare si de planificare reactive, cu precadere prin procedeul de generare al unei comenzi, respectiv al secventei de comanda pentru pentru comanda executiei:

referitor la modulul R/P, ecuatia de mai sus contine succesiunea unei structuri de plane si actiuni, care trebuie transformata de catre comanda executiei intr-un comportament pentru a atinge starea tinta.

Referitor la modul de comanda a executiei (AS), acesta trebuie sa atinga secventa unei structuri ordonate de sarcini tinta (Fig. 9.5).

Fig. 9.5 Interpretarea succesiunii de comenzi din punct de vedere al modulelor R/P si A/S

Arhitecturi cu mai multe sisteme de comanda

In sistemele complexe, formate din mai multe unitati, este posibil sa se genereze o comanda de catre modulul R/P pentru mai multe module AS. Astfel, se va realiza multimea de modificari ale procesului prin mai mult de un modul de comanda a executiei (Fig. 9.6). Aceste modificari contin operatorii de planificare prin cautarea starii, respectiv marimea de comanda de la reglare. In corelatie cu acestea, daca avem module AS pentru modificari de stare redundante, cuplate sau independente, se pot trata modulele in parte, individual sau in totalitate.

Fig. 9.6 Un modul R/P genereaza plane/comenzi/marimi de comanda n pentru mai multe module AS

Pentru doua module AS se prezinta primitivele de comanda urmatoare:

Daca starile procesului, care se pot modifica prin modulul AS, sunt cuplate sau sunt identice, atunci trebuie aduse cunostinte despre modificari la modulul R/P, cunostinte care rezulta din comenzi individuale sau globale.

De aceea sunt necesare modele de modificare suplimentare, care descriu influenta reala a marimii de comanda asupra subprocesului, respectiv procesul global.

Pentru cele doua module AS exista modelul direct, care poate sa contina nu numai influenta asupra procesului, ci si actiunea asupra marimii de comanda:

La cele doua module de comanda ale executiei se vor prelucra parti ale secventei de comenzi prin module AS diferite (Fig. 9.7). Iesirea din modulul AS este deja, la o analiza atenta, o ordonare implicita a comportamentului unitatii conduse si interpretate.

Figura 9.7 arata interpretari diferite ale comenzilor, ca influente asupra procesului la modulul R/P, respectiv ca tinte prestabilite/comportamente tinta din punctul de vedere al modulului AS.

Fig. 9.7 Succesiune de comenzi pentru doua module AS

Interpretarea planului si comanda distribuita a executiei

Atata timp cat modulul R/P trimite comenzile la modulul AS pentru o comanda directa, acestea nu contin nici o cerinta suplimentara pentru sincronizarea comenzii executiei, respectiv sincronizarea modulelor AS, de vreme ce comezile lor sunt primite la momentul de timp corespunzator. Modulul AS poate ca conduca imediat comenzile si sa le transforme in comportamente.

Aceasta nu mai este valabil, daca sunt utilizate secvente universale de comenzi sau de plane, care sunt pregenerate. Comenzile executiei sunt legate in timp in interiorul buclei de reglare de catre desfasurarea prealabila din planificator sau de catre modulul de calcul. Deci trebuie sa fie sincronizata executia comenzilor, prin fiecare modul de comanda a executiei comenzii. De aceea, modulul R/P trimite o structura de comenzi, de exemplu o succesiune de comenzi ca in ecuatia (9.6), la un modul de interpretare a comenzilor/planelor (modul PI). In cazul a doua module AS, modulul PI interpreteaza structura de comenzi si coordoneaza central executia prin ambele module AS, respectiv sincronizeaza executia fiecarei comenzi (Fig. 9.8).

Fig. 9.8 Interpretarea planului si executia in legatura cu planificarea

In locul unui tact de timp fix pentru reglare, respectiv pentru comanda directa la transmiterea si executia comenzilor, coordonatorul poate sa accepte un protocol de coordonare simplu 'astepta semnalul'. Acest protocol se poate utiliza atat intre P/R si PI cat si intre modulele PI si AS.

In robotica este larg raspandita interpretarea planului cu un modul PI, in care aceasta sa fie realizata ca retea Petri conditii/evenimente. In fig 9.9 se arata secventa de comenzi din fig 9.7 ca o retea Petri conditii/evenimente (CEP Condition-Event Petri-Net). Toate comportamentele din fig 9.9 sunt deja ordonate in succesiunea lor. Comportamentele succesive au conditii generale de tranzitii. Executia unui comportament poate incepe imediat ce au fost indeplinite comportamentele/comenzile anterioare. Aceste comportamente sunt sincronizate in CEP prin starile interne (pozitii). Conditii generale de tranzitii sunt totusi rare, pentru ca nu se mai poate face diferenta clara, care dintre conditii de start sau de terminare sa fie in realitate supravegheate.

Fig. 9.9 Retea Petri conditii/evenimente (CEP) pentru exemplul din figura 9.7

Realizarea unui interpretor de plan in aceasta forma cere ca modulul AS sa lucreze nesupravegheat. Modulele AS incheie comanda dupa aparitia conditiei de terminare si informeaza interpretorul de plan despre incheierea executiei comenzii ca si despre anumite atribute ale executiei comenzii.

In acesta forma, sistemul de comanda realizeaza in acelasi timp: tranzitia prin reprezentarea bazata pe timp si reprezentarea bazata pe evenimente a succesiunii comenzilor.

Interpretarea distribuita si descentralizata a planului

In locul interpretarii centrale a planului, se poate introduce si o interpretare descentralizata a planului. In acest scop fiecare modul AS are modulul propriu PI (Fig. 9.10). Reteau Petri nu va fi impartita si distribuita, ci se la transmite intreaga la toate modulele PI. Interpretoarele de plan singulare pot sa prelucreze foarte usor intreaga retea, din care se va interpreta numai acea parte din reteaua intreaga, care coordoneaza direct modulul AS subordonat. Din interpretarea lui CEP se vor activa in plus si receptorul pentru semnalele de sincronizare trimise si emitatorul, ale carui semnale sunt asteptate de catre modulul de conducere urmator.

Pentru o sincronizare descentralizata, trebuie ca modulele PI sa schimbe semnale intre ele. Bineinteles se poate ca intreaga retea sa fie mai intai impartita si apoi transmisa cu scop unui anumit interpretor. Acesta nu este necesar, de vreme ce interpretorul poate sa-si autofiltreze structurile de comanda relevante.

Fig. 9.10 Interpretarea descentralizata de plan prin mai multe interpretoare de plan locale

Pentru realizarea schimbului de semnale intre procesele individuale simultane, care pot sa aiba implementat un calculator de proces distribuit, este necesar un sistem de comunicare transparent. Existenta unor canale de comunicare sau defectarea acestora are influenta in posibilitatea de realizare a diferitelor arhitecturi.

Tabelul urmator arata un exemplu de schimb de semnale intre modulele PI si AS pentru exemplul din figura 9.10.

Tab. 9.1 Comunicarea intre modulele PI si AS

Send=trimite, Wait=asteapta

La aceasta forma de comanda trebuie avut grija, ca interpretorul de plan nu aduce nici o modificare in structura de comenzi, ci interpreteaza o structura de comenzi data si o traduce in comportamente. Verificarea comenzilor de catre modulul de conducere, a mai multor alternative, trebuie mai intai prelucrate in structura de comenzi.

Coordonarea comenzilor la echipe omogene

O retea Petri, respectiv o structura de comanda, care a fost generata de un modul R/P pentru unul sau mai multe interpretoare de plan, poate sa fie atribuita dinamic, in timp la diferite module AS. De aceea, nu trebuie sa existe o atribuire fixa de forma u₁->AS1 si u₂->AS2. In cazul in care este posibil ca module prestabilite AS sa aiba actiuni asemanatoare asupra procesului, exista mai multe alternative in atribuirea de mai sus. Pentru cel mai simplu exemplu, cu doua comenzi ale executiei, acesta inseamna in cel mai bun caz:

In cele ce urmeaza se presupune ca un modul PI la preluarea unei structuri de comenzi va trimite o ordonare fixa a comenzilor la modulul AS si ca aceasta ordonare nu se mai schimba. O ordonare continua dinamica poate totusi sa apara in cazuri singulare, pentru distributia dinamica a sarcinii de incarcare. In general se poate ca fiecare combinatie a ordonarii, pe care conducerea poate sa o realizeze in siguranta, sa fie o echipa omogena pentru conducerea lui CEP in discutie. Daca sunt posibile mai multe constructii de echipe, este bine ca pentru constructie echipei sa se gaseasca atribute optimale ale conducerii. Atributele pot fi costurile conducerii respectiv alte criterii de evaluare. Ordonarea structurilor de comanda pentru conducerea echipei necesita un coordonator de echipa (modul TK). El evalueaza atributele necesare de conducere ale echipei si le imparte la modulul R/P. Numai cand sunt continute atributele ordonarii pentru fiecare cerinta, modulul TK da semnalul pentru executia comenzii (Fig. 9.12).

Coordonatorul echipei poate, in acest scop, sa evalueze atributele de conducere a urmatoarei comenzii a executiei, pentru o combinatie determinata a echipei.

Fig. 9.12 Coordonarea echipei trebuie sa evalueze atributele de conducere ale echipei si sa urmareasca pregatirea lor, inainte ca executia comenzii sa poata fi pornita

Avantajul unei coordonari centrale a echipei, in combinatie cu un interpretor de plan centralizat, ca in figura 9.12 este posibilitatea de a putea evalua mai simplu anumite atribute ale conducerii, care se determina din combinatia a mai multe componente care actioneaza simultan (timp, conditii de comunicare). Acesta permite si comparatia mai usoara a atributelor conducerii pentru combinatii diferite de ordonare ale acelorasi agenti intr-o echipa omogena.

Constructia dinamica a unei echipe

Fie instalat, in loc de un interpretor de plan central (Fig. 9.8), un interpretor de plan descentralizat (Fig 9.10), atunci acesta are influenta asupra ordonarii unei structuri de comenzi, dintr-o echipa omogena.

In fiecare dintre cazuri trebuie, inainte de inceperea executiei structurii de comenzi, trebuie sa se realizeze o ordonare clara a echipei omogene. Trebuie asigurata disponibilitatea unui sistem de comunicare, cu care se poate realiza sincronizarea executiilor.

Interpretarea descentralizata a planului conduce la o constructie dinamica a planului din ordonarea dinamica a structurilor de comenzi. Evaluarea atributelor de conducere unei echipe omogene si ordonarea ulterioara a structurii planului nu se va face ca in figura 9.12, de catre un coodonator central de echipa, ci exista mai multi coordonatori de echipa si interpretori de plan. Constructia echipei (configurarea echipei) va fi realizata atunci pritr-o componenta centrala (modul TB).

Acest modul evalueaza atributele conducerii pentru mai multe combinatii de ordonare, cu interpretorul de plan, respectiv modulul AS (Fig. 9.13).

Aici se vor evalua de catre coordonatorii de echipa locali atributele de conducere pentru urmatoarea comanda a executiei:

Fig. 9.13 Constructia centrala a echipei pentru o conducere si o interpretare descentralizata a planului

Modulul TB evalueaza atributele de conducere ale echipei din atributele de conducere individuale. Sarcinile de conducere vor fi impartite la sfarsit pentru echipa, cu atributele de conducere adecvate.

In anumite cazuri poate sa fie necesar ca sa se modifice ordonarea structurii comenzilor in timpul rularii comenzilor, in modulul AS. Constrangerile pot fi defectiuni ale sistemelor de comanda sau ale actuatoarelor.

Arhitecturi ale sistemelor de comanda complexe

Pentru sarcini de situare mai complexe sunt utilizate totusi module AS, care prezinta bucle de autoreglare sau arhitecturi de comanda complexe (Fig. 9.14).

In cazul sistemelor cu tact al timpului, se utilizeaza in interiorul buclei de reglare interne conducerea cu alta baza a timpului l, fata de bucla de reglare exeterna k. Pentru un interval de timp dat, trebuie asigurata atingerea marimii de comanda u( k) º[x (l ³M)]_AS.

In cazul comenzii directe, modulul AS trebuie sa-si atinga starea tinta inainte ca acest modul sa primeasca urmatoarea marime de comanda, adica M £k

La comanda ierarhizata (Fig. 9.1) este posibil ca, de multe ori ca starea observabila x (l) din modulul AS, sa se utilizeze la supravegherea starii procesului din bucla externa.

In acest caz, modelul de stare din bucla externa se bazeaza pe modelul de stare al comenzii executiei. Acesta este un caz particular.

In general un exista motive de constrangeri pentru o supraveghere directa a starii x (k) pe baza starii conducerii x (l

Fig. 9.14 Supravegherea comenzii executiei ca bucla de reglare interna intr-o cascada (B/M=supraveghere/modelare, R/P=reglare/planificare, AS=comanda executiei/conducere)

Arhitecturi de comanda ierarhizate

Analog modelelor din ecuatiile (6.2-6.5), care sunt utilizate in bucla de reglare externa de catre modulul R/P, trebuie de asemenea, ca modulul R/P al conducerii in bucla de reglare interna sa asigure modele de generare ale comenzilor sau ale structurilor de comanda. Cu aceste modele se poate calcula sau cauta, cum se poate ajunge in starea tinta x (l ³M ) din starea actuala x (l ). Starea tinta cuprinde u( k +1) din bucla de reglare externa (Fig. 9.15).

Fig. 9.15 Continutul comenzilor in bucla de reglare externa si interna

Comenzile vor deveni o structura de comenzi, respectiv secvente:

(9.11)

Bucla de reglare interna trebuie sa asigure ca x (l ºu (k +1) pentru toate l ³M cel putin valabile atata timp, pana cand apare un semnal ready (terminare) de atingere a starii tinta. Comanda executiei structurii de comenzi interne poate fi realizata fie direct prin modulul intern R/P, fie prin modulul PI din bucla de reglare interna. Daca conducerea/comanda executiei contine comenzile numai dintr-un modul R/P, atunci avem o arhitectura cu structura de comanda ierarhizata (Fig. 9.16).

Fig. 9.16 Comanda executiei/conducere ierarhizata in (R/P=Regler/Planer, AS=Ausfhrungssteuerung)

Conditii de coordonare in arhitecturi de comanda

Conditiile de coordonare in arhitecturile de comanda exista atunci cand mai multe module R/P genereaza comenzi pentru acelasi modul AS si cand comenzile generate pot fi comandate simultan cu conflicte (Fig. 9.21).

Fig. 9.21 Comanda descentralizata pentru aceleasi module AS

Comanda executiei este atunci o resursa pentru mai multe module R/P. Aceasta problema a fost deja prezentata in Fig. 9.2. Cea mai simpla solutie este introducerea prioritatilor si comanda executiei comenzilor modulului R/P, cu cea mai inalta prioritate. Toate celelalte module R/P primesc informatia ca modulul AS este temporar blocat (Fig. 9.22).

O alternativa este utilizarea sirului de asteptare, in care se aduna comenzile individuale si apoi sunt executate pe rand. Se poate incerca si o incarcare a comenzilor intr-un spatiu vectorial cu ponderi de prioritate.

Fig. 9.22 Comanda executiei cu prioritati din structura de comenzi, la conducerea directa

De indata ce mai multe module PI vor sa transmita comenzile lor la modulul subordonat AS, este posibil in principiu, sa se recunoasca utilizarea concurentiala a acestui modul AS.

Pentru aceasta, modulele PI trebuie sa schimbe intre ele, la momente de timp corecte, retelele Petri (CEP) asteptate, cu denumirile modulelor AS corespunzatoare. Utilizarea concurentiala este atunci rezolvata de catre coordonatorul de plan. Si la coordonatorul de plan este mai simplu sa se prelucreze semnale de sincronizare suplimentare in structurile de comenzi (Fig. 9.23).

Fig. 9.23 Conduceri cu prioritati ale executiei structurilor de comenzi (conducere nesupravegheata)

La constructia dinamica a echipei nu se poate urmari o coordonare prealabila, pentru ca ordonarea este stabilita mai intai in momentul executiei comenzii. In acest caz trebuie sa se decida, fie de catre o componenta centrala, fie de modulul AS cu mai multe functii, in care echipa si pentru care module R/P, respectiv module PI este condusa comanda. Decizia depinde de estimarea si evaluarea atributelor comenzii executiei. Daca modulele R/P si AS nu sunt in dependenta clara unul fata de celalalt, atunci poate sa apara situatia ca, la o constructie dinamica a echipei cu mai multe module R/P si AS si la atriduirea unui modul R/P pentru un AS, acesta din urma sa decida pentru un alt modul R/P.