Septic brukertips

Innhold:

  1. Tuning av SmpcAppl
  2. Prioritetshierarki i SmpcAppl
  3. Neste

1. Tuning av SmpcAppl

De viktigste elementene av tuning er tatt med i dette avsnittet, spesielt med tanke på SmpcAppl.

Skalering (Span)

Det viktigste er at Span for de ulike variablene er avstemt i riktig forhold til variasjonsområdet. Den enkleste metoden som også ofte vil gi fornuftig intern skalering er å sette Span til "akseptabel" variasjon. 

  Eksempel:
  MPC med følgende Xvr'er:

    Xvr   Id            Enhet    Akseptabelt avvik
    Cvr:  PropenRenhet  mol%        0.2
    Cvr:  NivaTopp      %           5
    Mvr:  PropenAvdrag  T/H         2
    Mvr:  KokerEffekt   MW          0.2
    Dvr:  FodeMengde    T/H         2

  Hvis du i utgangspunktet er mer opptatt av nivået reduseres Span på denne. Ved å 
  balansere på denne måten og samtidig benytte akseptabelt avvik oppnås at Fulf og 
  MovePnlty bør kunne ligge nær 1 og at du har en "dokumentasjon" av hva som i
  startfasen ble betraktet som fornuftige reguleringskrav.

Selv om Span er online tunbar bør den være urørt etter at initielle simuleringer/tuning er utført, dvs. at senere tuningsendringer gjenspeiles gjennom Fulf og MovePnlty.

Til toppen av dokument

Pådragsblokking (Blocking)

Det er relevant med mer enn en blokk kun for SmpcAppl. Vurder dynamikken i prosessen og andre forhold som kan si noe om hvilke innsvingningstider den regulerte prosessen bør ha. Jo raskere den ønskes i forhold til prosessens egendynamikk, dess viktigere er det at siste pådragsblokk først starter omtrent ved ønsket innsvingningstid.
For de fleste applikasjoner vil 4 - 8 blokker pr. Mvr være tilstrekkelig, med kortest blokklengde i starten. 

  Eksempel:
  Vi tar utgangspunkt i den "lille" MPC'en igjen.

    Xvr   Id            Enhet
    Cvr:  PropenRenhet  mol%
    Cvr:  NivaTopp      %           
    Mvr:  PropenAvdrag  T/H
    Mvr:  KokerEffekt   MW
    Dvr:  FodeMengde    T/H

  Anta at PropenRenhet respons på KokerEffekt og FodeMengde har en tidskonstant 
  på 30 min, og at det er ingen (direkte) sammenheng mellom PropenAvdrag og 
  PropenRenhet. Både PropenAvdrag og KokerEffekt påvirker NivaTopp (integrator). 
  Du ønsker en innsvingningstid på PropenRenhet på ca. 30 min (tidskonstant på 6 - 8 min). 
  Da bør den siste blokken på KokerEffekt tidligst starte 30 min ut i horisonten, 
  slik at den delvis kan kompensere for gjenværende påvirkning fra en endring i 
  FodeMengde. Men en manipulasjon av KokerEffekt så langt ut i horisonten vil også 
  påvirke NivaTopp, dermed bør også PropenAvdrag gis fleksibilitet så langt ut.

Stor fleksibilitet i Mvr parametrisering øker regulatorens evne til å dekople responser i prediksjonen. Dette observeres også ved at en plan som legges ved ett sample i stor grad samsvarer med pådragene som implementeres for påfølgende samples, når modellen er god og forstyrrelsene moderate. Men stor fleksibiltet koster også mer beregningstid.

Blocking kan ikke endres on line. Dette betyr at applikasjonen må stoppes og endringer utføres på konfigurasjonsfil.

Til toppen av dokument

Avviksvekt (Fulf)

Dette er avviksvekten fra Cvr settpunkt og Mvr idealverdi. Straffen på avvik er kvadratisk:
For Mvr erstattes settpunkt med idealverdi i likningen over. Dersom Span er fornuftig balansert som indikert foran er 1 en brukbar startverdi for Fulf.

Fulf økes dersom Cvr'en ønskes bedre regulert mot settpunkt uten at du ønsker at en spesifikk Mvr skal øke sine manipulasjoner. Dersom en spesiell Mvr bør brukes mer for å oppnå bedre Cvr regulering bør du typisk øke noe på Fulf og samtidig redusere noe på MovePnlty til den aktuelle Mvr.

Til toppen av dokument

Pådragsvekt (MovePnlty)

Dette er straffen på endring i pådrag fra ett sample til det neste:
Dersom en Mvr brukes for mye øker du MovePnlty. Når Span er fornuftig balansert som indikert foran er 1 en brukbar startverdi for MovePnlty.

Til toppen av dokument

Relaksasjon Cvr grenser (HighLimit, LowLimit, HighPnlty og LowPnlty)

Disse brukes til å justere "mykheten" på Cvr høy/lav begrensninger. Den eneste mulige kilden til at SmpcAppl ikke greier å finne en gyldig løsning av problemet er for strenge høy/lav-grenser på Cvr.

HighLimit og LowLimit bestemmer hvor mye løsningen tillates å ligge utenfor spesifisert henholdsvis High / Low. Det anbefales å sette HighLimit/LowLimit stor dersom grensen ikke er absolutt og kritisk.

Med HighLimit/LowLimit stor er grensene i utgangspunktet myke. HighPnlty og LowPnlty bestemmer hvor myke. Dette er en kvadratisk straff som virker først utenfor grensen, som illustrert i figuren under.
Dersom variabelen ikke har noe settpunkt vil den kvadratiske HighPnlty/LowPnlty medføre at en optimal løsning som med hard grense ville ligge eksakt på grenseverdien vil ligge litt utenfor, siden straffen starter på 0 akkurat på grensen. 

  Eksempel:
  En regulatorutgang er med som Cvr. Av fysiske årsaker har denne grenser på 
  100 og 0. Likevel bør ikke denne spesifiseres med HighLimit og LowLimit = 0, siden 
  modellene ofte er usikre og forstyrrelser hele tiden virker inn. En HighLimit/LowLimit 
  på 0 kan derfor begrense løsningen unødvendig strengt utover i prediksjonen. 
  Vurder i et slikt tilfelle HighLimit (LowLimit) = 1000 (i praksis myk) og en passende 
  HighPnlty (LowPnlty) (0.5 - 10).

Til toppen av dokument

Modelloppdatering (BiasTfilt og BiasTpred)

Parametrene spesifiserer oppdatering av modellert Cvr fra prosessmålingene.

BiasTfilt angir tidskonstant i minutter for lavpassfiltrert oppdatering av øyeblikksavvik. Med støy på målingen vil et typisk valg ligge i området 2-10 ganger sampletiden.

BiasTpred angir tidskonstant i en første ordens ekstrapolasjon (prediksjon) av forstyrrelsen. Ved en trend i den filtrerte biasen antas at denne fortsetter inn i framtiden, men at stigningen på trenden avtar i henhold til en første ordens respons. Dette gir mulighet til raskere regulering ("derivatvirkning"), men bør samtidig brukes med forsiktighet og definitivt ikke uten et fornuftig valg av BiasTfilt først.

Til toppen av dokument

Simulering

Dette er et viktig hjelpemiddel både i bestemmelse av initiell tuning på deler av eller hele konfigurasjonen, og i trouble-shooting på en applikasjon i drift.

Anta at vi har bygget en konfigurasjonsfil for en applikasjon med tanke på initiell simulering. Modellene er allerede funnet. For enkelhets skyld viser vi bare hovedstrukturen på denne konfigurasjonsfilen under. Legg da modellfilene og konfigurasjonsfilen på samme katalog på PC, og start Septic. Husk å angi Meas på alle variable. 

  // Config file seppro.cfg for Propen (T-4702), simulation.
  System:     Smpc_Propen
  MsgBox:     PropenMsg
  MasterTcip: Master        MasterPort= 1234
  ExprProc:   MPC-PRO
  SmpcAppl:   MPC-PRO
    Cvr:      PropenRenhet
    Cvr:      NivaTopp      Integ= 1
    Mvr:      PropenAvdrag
    Dvr:      FodeMengde
    ExprModl: PropenMod

Når du har funnet en tuning du er fornøyd med lager du en SavedCnfg som så gis navnet som konfigurasjonsfilen til den kjørende applikasjonen skal ha. Overfør denne og modellfilene til den katalogen applikasjonen skal kjøre fra. Erstatt så ExprProc deklarasjonen i konfigurasjonen med det aktuelle prosessgrensesnittet. I tilfellet med en InfoProc vil da den nye hovedstrukturen se slik ut: 

  // Config file seppro.cfg for Propen (T-4702), online control
  System:     Smpc_Propen
  MsgBox:     PropenMsg
  MasterTcip: Master        MasterPort= 1234
  InfoProc:   47+MPC-PRO
    InfoCvr:  PropenRenhet  CvrTag= 47+AY-500
    InfoCvr:  NivaTopp      CvrTag= 47-LIC-110-FL
    InfoMvr:  PropenAvdrag  MvrTag= 47-FIC-114-FV
    InfoDvr:  FodeMengde    DvrTag= 47-FI-100-FL
  SmpcAppl:   MPC-PRO
    Cvr:      PropenRenhet
    Cvr:      NivaTopp      Integ= 1
    Mvr:      PropenAvdrag
    Dvr:      FodeMengde
    ExprModl: PropenMod

Da skal du være klar til å starte opp applikasjonen.

Dersom du har en kjørende applikasjon som du ønsker å simulere er det bare å gå den motsatte veien. Når du lager en SavedCnfg fra en kjørende applikasjon får du med øyeblikksverdien både på målinger, settpunkt og grenser etc., slik at simuleringen kan starte opp fra riktig initialtilstand.

Til toppen av dokument

2. Prioritetshierarki i SmpcAppl

Følgende parametre har betydning for det ekslisitte prioritetshierarkiet: 

  Cvr HighPrio
  Cvr LowPrio 
  Cvr SetPntPrio
  Mvr IvPrio

Alle disse parametrene kan spesifiseres med verdi i området 1-99, der 1 angir høyeste og 99 laveste prioritet.

Prioritetshierarkiet i SmpcAppl aktiviseres ved å skru DoStdSolve ON.

Steady state løseren vil da: 

  1. Respektere MV ROC (rate of change) type begrensninger (MaxUp/MaxDn)
  2. Respektere MV høy/lav type begrensninger (High/Low)
  3. Respektere harde CV-begrensninger (HighLimit/LowLimit)
  4. Sortere CV/MV spesifikasjonene i henhold til stigende prioritetstall på HighPrio, LowPrio, SetPntPrio og IvPrio.
  5. Løse med hensyn på de spesifikasjonene som har lavest prioritetstall, hvis flere på samme nivå vil vekting komme i bildet.
  6. Låse den løsningen som finnes med tanke på CV settpunkt og MV idealverdi samt eventuelt utvide CV grenser.
  7. Gjentar fra punkt 5 fra neste prioritetsnivå inntil alle spesifikasjoner er håndtert.

Til toppen av dokument