• realizzazione di complesse strutture di controllo
  
• prestazioni dinamiche;
  
• gestione della diagnostica di sistema;
  
• interfaccia utente.

• maggiore flessibilità;
  
• riduzione dei costi hardware (in molti casi).

Contemporaneamente si può anche dire che l' introduzione del software ha aperto un complicato discorso di certificazione del processo produttivo dell' impresa. Si può infatti dire che il software non pone alcun problema di riproducibilità ma viceversa grossi problemi di certificazione nella fase di progetto: si sposta quindi l' attenzione dal prodotto finale al processo di realizzazione. I due problemi quindi confluiscono nella necessità di intervenire in maniera sistematica sul processo produttivo del software e in generale sulla progettazione dell' intero sistema come interazione hardware-software per giungere a una procedura di specifica che tenga conto delle esigenze ora illustrate. Tale situazione ha avuto il suo precedente storico nel settore dello sviluppo dei sistemi informativi, e la conseguenza è stata la nascita di una disciplina che si propone proprio come scopo quello di dare un volto ingegneristico al software e che proprio per questo prende il nome di "ingegneria del software"
(SE "Software Engineering" d' ora in poi). Va però precisato che l'applicazione di nostro interesse presenta caratteristiche peculiari che fanno sì che le tradizionali metodologie proposte dall' ingegneria del software non siano sufficienti a risolvere il problema: è viceversa necessario concentrarsi sui più recenti studi dedicati proprio alle applicazioni in tempo reale cioè a quelle applicazioni in cui la correttezza del software dipende anche dal tempo di esecuzione delle routine. In realtà, comunque, si può dire che la nascita del "problema software" non ha fatto altro che acuire delle problematiche che già erano presenti nella progettazione di un azionamento elettrico. Si può infatti dire che il problema fondamentale sia l'interdisciplinarietà che sta alla base della progettazione di questo settore.

Come è anche sottolineato dalla figura 1, infatti, l' azionamento elettrico è il risultato di un insieme di competenze che devono trovare il miglior modo di collaborare per poter giungere a un prodotto veramente affidabile e di qualità. Si possono infatti individuare le seguenti competenze specifiche:

• progettista di sistema (tipicamente un ingegnere elettrico o elettromeccanico)
  
• progettista di elettronica di potenza
  
• progettista meccanico
  
• progettisti elettronico (microelettronica)
  
• progettista software.

1. da un lato garantire la disponibilità di una ricca libreria di strumenti che permettessero al progettista del controllo di comporre la struttura del sistema controllato partendo da
   "mattoni elementari" precostituiti
   
2. dall'altro fornire una serie di regole pratiche per arrivare ad un'interfacciamento della specifica software con il sistema controllato simulato in SIMULINK.

L' ambiente fornisce poi altri metodi di arricchimento della libreria e cioè:
- MEX file
- MATLAB function scritte nel linguaggio di MATLAB

Allo stato attuale la libreria Azio, composizione dei blocchi sviluppati per lo studio di controlli per azionamenti, è articolata in ulteriori sottolibrerie:

1. motori
   
2. carichi meccanici
   
3. convertitori
   
4. trasformate di coordinate
   
5. algoritmi di regolazione fondamentali. Nell' ambito delle sottolibrerie si possono poi individuare i seguenti blocchi:
   1. Motori
      - motore cc a magneti permanenti
      - motore cc a eccitazione indipendente
      - motore asincrono
      - motore sincrono con eccitazione indipendente
      - motore asincrono a doppia stella
      - motore sincrono brushless sinusoidale
      - motore a riluttanza

   2. Carichi meccanici
      - inerzia pura
      - inerzia più coppia resistente proporzionale alla velocità
      - inerzia più coppia resistente proporzionale al quadrato della velocità

   3. Convertitori
      - chopper senza limiti in frequenza
      - chopper con limite max. sulla frequenza di commutazione
      - inverter monofase a due livelli
      - inverter monofase a tre livelli
      - inverter trifase a due livelli
      - inverter trifase a tre livelli
      - ponte di Graetz

   4. Trasformate di coordinate
      - Trasformata di Park
      - Trasformata di Park inversa

   5. Algoritmi di regolazione
      - PI digitale con saturazione dell' uscita
      - Ricostruttore di flusso per macchina asincrona
      - Controllo V/Hz

   Tale elenco è comunque in continua evoluzione avendo come scopo finale quello di arrivare a coprire il più possibile le varietà di componenti per gli azionamenti.

   Si passa ora al dettaglio di come sono stati implementati i vari modelli delle librerie.

   1. Modelli di motori
      Le teoria della dinamica delle macchine elettriche fornisce l'insieme di equazioni differenziali utili per la costruzione del modello di simulazione. Partendo dalla conoscenza di queste equazioni è abbastanza semplice arrivare a costruire una S-function per MATLAB. Si dovranno definire:
      • variabili di ingresso
        
      • variabili di uscita
        
      • variabili di stato
        
      • equazioni di stato
        
      • relazioni tra le variabili di stato e le varibili di uscita.
      
      La descrizione può essere agevolmente svolta in linguaggio M o viceversa costruendo una S-function in C da integrare come Mex File. Seguendo la prima strada si arriva a uno schema SIMULINK quale quello riportato nella figura successiva:
      

      Nel caso in esame poi, cioè modello di un motore asincrono, la descrizione dei legami matematici può essere fatto con un file m quale quello riportato di seguito.

      function [sys,x0] = asi(t,x,u,flag,mec,stat,rot,ic)
      % input
      % u(1) omega s (velocita assi Park f(t) )
      % u(2) Vds
      % u(3) Vqs
      % u(4) Cr (carico meccanico f(t) )
      % stati (flussi)
      % x(1) Fds
      % x(2) Fqs
      % x(3) Fdr
      % x(4) Fqr
      % x(5) omega
      % parametri
      npoli=mec(1);
      J=mec(2);
      Rs=stat(1);
      Ls=stat(2);
      M=stat(3);
      Rr=rot(1);
      Lr=rot(2);

      D=Ls*Lr-M*M;

      if abs(flag)==1,
      Ids=(Lr*x(1)-M*x(3))/D;
      Idr=(-M*x(1)+Ls*x(3))/D;
      Iqs=(Lr*x(2)-M*x(4))/D;
      Iqr=(-M*x(2)+Ls*x(4))/D;
      Ce=(npoli*M/D)*(x(2)*x(3)-x(4)*x(1));
      sys(1)=([-Rs*Ids+u(1)*x(2)+u(2)]);
      sys(2)=([-Rs*Iqs-u(1)*x(1)+u(3)]);
      sys(3)=([-Rr*Idr+(u(1)-x(5))*x(4)]);
      sys(4)=([-Rr*Iqr-(u(1)-x(5))*x(3)]);
      sys(5)=([(npoli/J)*(Ce-u(4))]);
      else if flag==0,
      sys=[5;0;4;4;0;0];
      x0=ic;
      else if flag==3,
      sys(1)=(Lr*x(1)-M*x(3))/D;
      sys(2)=(Lr*x(2)-M*x(4))/D;
      sys(3)=(npoli*M/D)*(x(2)*x(3)-x(4)*x(1));
      sys(4)=x(5);
      else
      sys=[];
      end
      end
      end

   2. Modelli dei convertitori
      La simulazione della parte convertitore costituisce il caso più complesso da considerarsi ancora in istudio per verificare diverse possibilità. Supponendo di considerare comunque modelli di valvole ideali si arriva a formulare due diverse ipotesi:
      • integrare la commutazione delle valvole all'interno del modello della macchina arrivando così a un modello di motore con convertitore già collegato che riceve come ingresso lo stato da attribuire agli interruttori. Si tratta di un approccio interessante, che consente tra l' altro di approfondire le problematiche di modellizzazione delle valvole.
        
      • un modello separato del convertitore che permette di creare un blocco dedicato alla logica di commutazione delle valvole che genera in uscita le tensioni applicate al motore. Si tratta di un modello più semplice del precedente ma anche in generale più rapido come integrazione.
      
      Nel caso della libreria in esame sono state seguite entrambe le filosofie arrivando a diverse soluzioni ciascuna utilizzabile con diversi vantaggi a seconda dell'applicazione. Nella figura seguente è riportato lo schema SIMULINK di un inverter trifase con pilotaggio del PWM con metodologia a sottoscillazione sinusoidale.
      
   3. Modelli della parte meccanica
      Per questa porzione di sistema si possono ripetere considerazioni già fatte in parte per i motori. Spesso per la parte meccanica si utilizzano addirittura modelli lineari o linearizzati e quindi si può dire che l'ambiente MATLAB mette a disposizione due diverse soluzioni:
      • equazioni di stato come nel caso del motore
        
      • modelli basati su sistemi rappresentati con funzioni di trasferimento in Laplace
      
      
   4. Controllori digitali
      Oltre a sfruttare i blocchi standard di SIMULINK basati sulla trasformata Z si possono pensare soluzioni diverse che tengano conto delle non linearità tipiche del software di utilizzo nei controlli reali. Un semplice esempio può essere utile. Si consideri la seguente routine:
      

      Considerando questo semplice esempio si può facilmente verificare che non esiste una trasformata Z della logica della funzione.Non è quindi possibile dare un modello basato su blocchi standard per questo sistema. Allo scopo è stata sviluppata una logica di interfaccia tra SIMULINK e routine di sviluppo dell'utente per facilitare la specifica di sistemi di controllo digitale.

   
   
6. La specifica di routine di controllo e AUTOC
   Uno dei problemi fondamentali della modellistica è quello di avere modelli il più possibile vicini alla realtà. Nel caso delle routine per il controllo la cosa migliore sarebbe quindi proprio quella di poter utilizzare in simulazione la medesima routine da utilizzarsi poi per il controllo in tempo reale. L' utilizzo di un linguaggio ad alto livello come il "C" garantisce, entro certi limiti, una buona portabilità del codice e quindi la possibilità di pensare il codice indipendentemente dalla macchina su cui si implementa. Questa constatazione ha fatto nascere l'idea di poter implementare in MATLAB le routine che si pensa poi di portare sul target. D'altra parte anche il linguaggio m di MATLAB costituisce un interessante esempio di linguaggio ad alto livello utile per documentare le routine di controllo. Si sono studiati quindi due problemi:
   1. creare una procedura rapida per la compilazione di routine scritte dall'utente
      
   2. creare un interfaccia standard per l'esecuzione di queste routine o di analoghe routine scritte in file m in ambiente SIMULINK.
   Il tool Autoc permette di acquisire un programma "C" e trasformarlo in un comando MATLAB da utilizzarsi per l' ambiente SIMULINK. L' ingresso di questo programma è una qualsiasi funzione C che ammette in ingresso un numero qualunque di parametri e che restituisce poi al termine una variabile. Come si vede all' interno di questa categoria rientrano praticamente tutte le routine di controllo tipiche che in base a determinati ingressi producono un' uscita. La limitazione di avere una sola uscita è da considerarsi transitoria e verrà rimossa nella prossima versione del tool al fine di comprendere una famiglia ancor più vasta di routine. Grazie al lavoro finora svolto è possibile quindi seguire il seguente iter nello sviluppo di un nuovo "blocco" per il controllo:
   1. studiare l' algoritmo in maniera non formale arrivando quindi poi a una codifica puramente matematica
      
   2. traduzione dell' algoritmo in linguaggio C
      
   3. utilizzo di Autoc per ottenere automaticamente il file di tipo DLL (libreria di link dinamico per Windows) che è già a tutti gli effetti un comando di MATLAB
      
   4. realizzazione del blocco da usare in simulazione in ambiente SIMULINK per verificare l' efficacia della routine richiamando il file DLL precedentemente ottenuto. Anche per questa parte del processo si sta lavorando a una procedura di automazione; allo stato attuale esiste una versione prototipale del programma, non ancora completamente testata, e che dovrebbe essere denominata "Mkm". Il concatenamento automatico delle due fasi non comporta alcun problema. Una volta completata questa parte del lavoro si avrà la possibilità di passare direttamente dal file C all' icona in ambiente SIMULINK da utilizzare per la simulazione.
      
   5. test della routine con SIMULINK
   
   L' importanza di questo approccio è quella di creare una corrispondenza biunivoca tra blocchi di SIMULINK e software di controllo da utilizzare sul target così da poter contare su una simulazione il più possibile affidabile e una coerenza che può essere definita completa tra la fase di simulazione del controllo, la specifica software e la codifica finale. Si passa quindi al problema dell'interfacciamento della DLL ottenuta con Autoc o di una generica routine scritta in linguaggio M con l'ambiente SIMULINK. Tale analisi verrà svolta attraverso la guida di un semplice esempio. Il primo passo è chiaramente la scrittura della routine in linguaggio C:
   

   In altre parole questa funzione somma l'ingresso y alla variabile di stato x fino a che non raggiunge il valore di saturazione sat per poi resettare lo stato. La routine viene scritta con un normale editor e memorizzata in un file denominato "proinc.c". Attraverso il programma Autoc si passa alla produzione della DLL "incr.dll". A questo punto si ottiene un nuovo comando per MATLAB denominato incr.
   E' possibile richiamare la funzione a livello di Command Window e verificare il funzionamento per diversi valori degli ingressi. Il protocollo di chiamata sarà:

   [u] = incr[a]

   dove a è il vettore degli ingressi e u quello delle uscite. Il vettore degli ingressi sarà così composto:

   - x: variabile di stato
   - y: ingresso
   - sat: valore di saturazione

   Nel primo elemento del vettore delle uscite si trova il nuovo valore dello stato. Ora il problema è sviluppare un'interfaccia verso SIMULINK che garantisca che la routine si comporti come ci si aspetta e cioè che venga eseguita una volta ogni tanto con un periodo fissato dall'utente pari al tempo di scheduling che si intende fissare sul sistema target. In definitiva si vogliono modellizzare due aspetti:

   • una routine software deve essere chiamata con una precisa frequenza che generalmente è diversa dal passo di integrazione della simulazione

   • l'uscita della routine software non diviene immediatamente disponibile ma si deve attendere un tempo pari al tempo di elaborazione del microprocessore target.
   Allo scopo di modellizzare questi due aspetti è stata sviluppata un'opportuna interfaccia MATLAB.
   Si supponga che la routine sia stata eseguita all'istante tk: si deve ora aspettare tk+1 tale che:
   

   dove Tc è il tempo di ciclo della routine. L'uscita della funzione deve inoltre essere prolungata secondo la relazione qui riportata:

   

   Questa logica è stata integrata in un M file collegato poi a SIMULINK attraverso lo schema riportato nella figura seguente dove si possono anche notare i parametri che l'utente potrà fissare dall'esterno con una tipica maschera SIMULINK. Il blocco di ritardo analogico riportato in uscita serve per poter inserire il tempo di elaborazione come parametro di simulazione da sottoporre a verifica.

   Figura 2 - Figura 3 - Figura 4 (immagine di 16kb)

   Un'altra possibile soluzione, effettivamente adottata in molte situazioni come si vedrà anche nel seguito, prevede di sostituire le retroazioni dirette dell'uscite con l'utilizzo di variabili global.