Gaiarekin jarraituz , ikus dezagun beste aldetik modelizazio matematikoaren arazoa. Eredua bizitzaren etxeko egiari dagokiola sinetsita, galdera nagusiari erantzun diezaiokegu: "zer daukagu, zehazki, hemen?" Objektu tekniko baten maketa sortzerakoan, normalean, objektu horrek gure itxaropenak beteko dituela ziurtatu nahi dugu. Horretarako, prozesuen kalkulu dinamikoak egiten dira eta emaitza eskakizunekin alderatzen da. Hau biki digital bat da, prototipo birtual bat, etab. modan dauden mutil txikiak, diseinu-fasean, aurreikusitakoa lortzen dugula ziurtatzeko arazoa konpontzen dutenak.
Nola ziurta dezakegu azkar gure sistema diseinatzen duguna dela, gure diseinuak hegan egingo du edo flotatuko du? Eta hegan egiten badu, noraino? Eta flotatzen badu, zenbat sakonera?
Artikulu honek sistema teknikoen eredu dinamikoak sortzerakoan eraikin tekniko baten eskakizunak betetzen direla egiaztatzearen automatizazioari buruz eztabaidatzen du. Adibide gisa, ikus dezagun hegazkinen airea hozteko sistema baten zehaztapen teknikoaren elementu bat.
Zenbakiz adierazi eta matematikoki egiazta daitezkeen eskakizunak kontuan hartzen ditugu kalkulu-eredu zehatz batean oinarrituta. Argi dago hori edozein sistema teknikoren eskakizun orokorren zati bat baino ez dela, baina horiek egiaztatzean denbora, nerbioak eta dirua gastatzen ditugu objektuaren eredu dinamikoak sortzeko.
Baldintza teknikoak dokumentu moduan deskribatzean, hainbat baldintza mota bereiz daitezke, eta horietako bakoitzak planteamendu desberdinak eskatzen ditu eskakizunak betetzearen egiaztapen automatikoa eratzeko.
Adibidez, kontuan hartu eskakizun multzo txiki baina errealista hau:
- Airearen tenperatura ura tratatzeko sistemaren sarreran:
aparkalekuan - minus 35-tik 35 ΒΊΠ‘,
hegaldian - minus 35-tik 39 ΒΊΠ‘. - Hegaldiko aire atmosferikoaren presio estatikoa 700 eta 1013 GPa artekoa da (526 eta 760 mm Hg artekoa).
- Hegaldian SVO aire-hartunearen sarreran dagoen aire-presioa 754tik 1200 GPa artekoa da (566tik 1050 mm Hg-ra).
- Hozteko airearen tenperatura:
aparkalekuan - 27 ΒΊΠ‘ baino gehiago, bloke teknikoetarako - 29 ΒΊΠ‘ baino gehiago,
hegaldian - 25 ΒΊΠ‘ baino gehiago, bloke teknikoetarako - 27 ΒΊΠ‘ baino gehiago. - Hozteko aire-fluxua:
aparkatuta dagoenean - gutxienez 708 kg/h,
hegaldian - 660 kg/h baino gutxiago. - Tresnen konpartimentuetako airearen tenperatura ez da 60 ΒΊΠ‘ baino gehiago.
- Hozte-airean dagoen hezetasun finaren kopurua ez da 2 g/kg aire lehor baino gehiago.
Baldintza multzo mugatu honen barruan ere, sisteman modu ezberdinean kudeatu behar diren bi kategoria daude gutxienez:
- sistemaren funtzionamendu-baldintzen baldintzak (1-3 klausulak);
- sistemaren eskakizun parametrikoak (3-7 klausulak).
Sistemaren funtzionamendu-baldintzen eskakizunak
Modelizazioan garatzen ari den sistemaren kanpoko baldintzak muga-baldintza gisa edo sistema orokorraren funtzionamenduaren ondorioz zehaztu daitezke.
Simulazio dinamikoan, simulazio-prozesuak zehaztutako funtzionamendu-baldintzak estaltzen dituela ziurtatu behar da.
Sistema parametrikoen eskakizunak
Baldintza hauek sistemak berak emandako parametroak dira. Modelizazio prozesuan, parametro hauek kalkuluaren emaitza gisa lor ditzakegu eta kalkulu zehatz bakoitzean baldintzak betetzen direla ziurtatu.
Baldintzak identifikatzea eta kodetzea
Eskakizunekin lan egiteko, dauden estandarrek eskakizun bakoitzari identifikatzaile bat esleitzea gomendatzen dute. Identifikatzaileak esleitzerakoan, oso desiragarria da kodeketa sistema bateratua erabiltzea.
Baldintza-kodea eskakizunaren eskaera-zenbakia adierazten duen zenbaki bat izan daiteke, edo eskakizun motaren kode bat, aplikatzen zaion sistema edo unitatearen kodea, parametro-kode bat, kokapen-kode bat eta eduki ditzake. ingeniariak imajina dezakeen beste edozer. (ikusi artikulua kodeketa erabiltzeko)
1. taulak eskakizunen kodeketaren adibide sinple bat eskaintzen du.
- eskakizunen iturriaren kodea R-eskakizunak TK;
- kodea eskakizun mota E - eskakizunak - ingurumen-parametroak, edo funtzionamendu-baldintzak
S - sistemak emandako eskakizunak; - hegazkinaren egoera kodea 0 - edozein, G - aparkatuta, F - hegaldian;
- parametro fisiko mota kodea T - tenperatura, P - presioa, G - emaria, hezetasuna H;
- eskakizunaren serie zenbakia.
| ID Baldintzak |
Description | Parametroa |
| REGT01 | Giro-airearen tenperatura ura hozteko sistemaren sarreran: aparkalekuan - 35ΒΊΠ‘-tik behera. 35ΒΊΠ‘ arte. | |
| REFT01 | Airearen defentsa-sistemaren sarreran atmosferako airearen tenperatura: hegaldian - minus 35 ΒΊΠ‘-tik 39 ΒΊΠ‘-ra. | |
| REFP01 | Airearen presio estatikoa hegaldian 700 eta 1013 hPa bitartekoa da (526 eta 760 mm Hg artean). | |
| REFP02 | Hegaldian SVO aire-hartunearen sarreran dagoen aire-presioa 754tik 1200 hPa bitartekoa da (566tik 1050 mm Hg-ra). | |
| RSGT01 | Hozteko airearen tenperatura: aparkatuta dagoenean 27 ΒΊΠ‘ baino gehiago | |
| RSGT02 | Hozteko airearen tenperatura: aparkalekuan, unitate teknikoetarako 29 ΒΊΠ‘ baino gehiago | |
| RSFT01 | Hozteko airearen tenperatura hegaldian 25 ΒΊΠ‘ baino gehiago | |
| RSFT02 | Hozteko airearen tenperatura: hegaldian, unitate teknikoetarako 27 ΒΊΠ‘ baino gehiago | |
| RSGG01 | Hozteko aire-fluxua: 708 kg/h baino gutxiago aparkatuta dagoenean | |
| RSFG01 | Hozteko aire-fluxua: hegaldian 660 kg/h baino gutxiago | |
| RS0T01 | Airearen tenperatura tresnen konpartimentuetan 60 ΒΊΠ‘ baino gehiago | |
| RSH01 | Hozte-airean dagoen hezetasun finaren kopurua ez da 2 g/kg aire lehor baino gehiago |
Eskakizunak egiaztatzeko sistemaren diseinua.
Diseinu-eskakizun bakoitzerako algoritmo bat dago diseinu-parametroen eta eskakizunean zehazten diren parametroen bat datozenak ebaluatzeko. Orokorrean, edozein kontrol-sistemak beti ditu lehenespenez eskakizunak egiaztatzeko algoritmoak. Eta edozein erregulatzaile ere baditu. Tenperatura mugetatik kanpo joaten bada, aire girotua pizten da. Hala, edozein araudiren lehen fasea parametroek baldintzak betetzen dituzten egiaztatzea da.
Eta egiaztapena algoritmo bat denez, orduan kontrol programak sortzeko erabiltzen ditugun tresna eta tresna berberak erabil ditzakegu. Adibidez, SimInTech inguruneak ereduaren hainbat atal dituzten proiektu-paketeak sortzeko aukera ematen du, proiektu bereizietan exekutatuta (objektu-eredua, kontrol-sistema-eredua, ingurune-eredua, etab.).
Kasu honetan eskakizunak egiaztatzeko proiektua algoritmo-proiektu bera bihurtzen da eta eredu-paketearekin konektatzen da. Eta modelizazio dinamikoan zehaztapen teknikoen eskakizunak betetzeko analisia egiten du.
Sistema baten diseinuaren adibide posible bat 1. irudian ageri da.
1. irudia. Egiaztapen-proiektu baten diseinuaren adibidea.
Kontrol-algoritmoetarako bezala, eskakizunak orri-multzo gisa egin daitezke. SimInTech, Simulink, AmeSim bezalako egiturazko modelizazio-inguruneetan algoritmoekin lan egiteko erosotasunerako, azpieredu moduan maila anitzeko egiturak sortzeko gaitasuna erabiltzen da. Antolaketa honek hainbat eskakizun multzotan biltzea ahalbidetzen du, eskakizun sorta batekin lana errazteko, kontrol algoritmoetarako egiten den bezala (ikus 2. irudia).
2. irudia. Eskakizunak egiaztatzeko ereduaren egitura hierarkikoa.
Esaterako, aztergai dugun kasuan, bi talde bereizten dira: ingurumenaren eskakizunak eta sistemaren eskakizunak zuzenean. Beraz, bi mailatako datu-egitura erabiltzen da: bi talde, bakoitza algoritmoaren hosto bat dena.
Datuak ereduarekin konektatzeko, seinaleen datu-base bat sortzeko eskema estandar bat erabiltzen da, proiektuaren atalen artean trukatzeko datuak gordetzen dituena.
Softwarea sortzean eta probatzean, kontrol-sistemak erabiltzen dituen sentsoreen irakurketak (sistema errealaren sentsoreen analogoak) datu-base honetan jartzen dira.
Proba-proiektu baterako, eredu dinamikoan kalkulatutako edozein parametro datu-base berean gorde daiteke eta, horrela, baldintzak betetzen diren egiaztatzeko erabili.
Kasu honetan, eredu dinamikoa bera modelizazio matematikoko edozein sistematan exekutatu daiteke edo baita programa exekutagarri baten moduan ere. Baldintza bakarra kanpoko ingurunera modelizazio datuak igortzeko software interfazeak egotea da.
3. Irudia. Egiaztapen-proiektua eredu konplexuarekin lotzea.
Oinarrizko eskakizunak egiaztatzeko orri baten adibidea 4. Irudian aurkezten da. Garatzailearen ikuspuntutik, kalkulu-diagrama konbentzionala da, non eskakizunak egiaztatzeko algoritmoa grafikoki aurkezten den.
4. irudia. Baldintzak egiaztatzeko orria.
Egiaztapen-orriaren zati nagusiak 5. Irudian deskribatzen dira. Egiaztapen-algoritmoa kontrol-algoritmoen diseinu-diagramen antzera eratzen da. Eskuineko aldean datu-baseko seinaleak irakurtzeko bloke bat dago. Bloke hau seinaleen datu-basera sartzen da simulazioan zehar.
Jasotako seinaleak aztertzen dira eskakizunak egiaztatzeko baldintzak kalkulatzeko. Kasu honetan, altitudearen analisia egiten da hegazkinaren posizioa zehazteko (aparkatua edo hegaldian dagoen). Horretarako, ereduaren beste seinale eta kalkulatutako parametroak erabil ditzakezu.
Egiaztatzen ari diren egiaztapen-baldintzak eta parametroak egiaztapen-bloke estandarretara transferitzen dira, eta horietan parametro horiek zehaztutako baldintzak betetzen diren aztertzen dira. Emaitzak seinaleen datu-basean erregistratzen dira, kontrol-zerrenda automatikoki sortzeko erabil daitezkeen moduan.
5. Irudia. Eskakizunak egiaztatzeko kalkulu-orriaren egitura.
Probatu beharreko parametroek ez dituzte zertan datu-basean jasotako seinaleak erabiltzen, simulazio-prozesuan kalkulatutako parametroek kontrolatzen dituztenak. Ezerk ez digu eragozten zirriborroaren eskakizunen esparruan kalkulu osagarriak egitea, egiaztapen-baldintzak kalkulatzen ditugun bezala.
Adibidez, baldintza hau:
Helbururako hegaldian zehar zuzenketa-sistemaren aktibazio-kopurua ez da 5 baino handiagoa izan behar, eta zuzenketa-sistemaren funtzionamendu-denbora osoa 30 segundokoa izan behar da.
Kasu honetan, abiarazte-kopurua eta guztizko funtzionamendu-denbora kontratatzeko algoritmo bat gehitzen zaio eskakizunen diseinu-diagramari.
Eskakizunak egiaztatzeko bloke tipikoa.
Baldintza estandar baten kontrol-lauki bakoitza mota jakin bateko eskakizun bat betetzen dela kalkulatzeko diseinatuta dago. Esaterako, ingurumen-eskakizunek giro-funtzionamendu-tenperatura sorta bat barne hartzen dute aparkatuta eta hegaldian. Bloke honek modeloko airearen tenperatura jaso behar du parametro gisa eta parametro honek zehaztutako tenperatura-tartea betetzen duen zehaztu behar du./p>
Blokeak bi sarrera-portu ditu, parametroa eta baldintza.
Lehenengoa egiaztatzen den parametroarekin elikatzen da. Kasu honetan, βKanpo tenperaturaβ.
Bigarren atakari aldagai boolearra ematen zaio - egiaztapena egiteko baldintza.
Bigarren sarreran TRUE (1) jasotzen bada, blokeak eskakizunak egiaztatzeko kalkulua egiten du.
Bigarren sarrerak FALSE (0) jasotzen badu, orduan ez dira proba-baldintzak betetzen. Hori beharrezkoa da kalkulu-baldintzak kontuan izan daitezen. Gure kasuan, sarrera hau ereduaren egoeraren arabera egiaztapena gaitzeko edo desgaitzeko erabiltzen da. Simulazioan hegazkina lurrean badago, hegaldiari lotutako eskakizunak ez dira egiaztatzen, eta alderantziz; hegazkina hegaldian badago, standean funtzionamenduarekin lotutako baldintzak ez dira egiaztatzen.
Sarrera hori eredua konfiguratzerakoan ere erabil daiteke, adibidez kalkuluaren hasierako fasean. Eredua behar den egoerara eramaten denean, egiaztapen-blokeak desgaitu egiten dira, baina sistema behar den funtzionamendu-modura iritsi bezain laster, egiaztapen-blokeak aktibatu egiten dira.
Bloke honen parametroak hauek dira:
- muga-baldintzak: egiaztatu behar diren goiko (UpLimit) eta beheko (DownLimit) barrutiaren mugak;
- beharrezkoa den sistemaren esposizio-denbora muga-tarteetan (TimeInterval) segundotan;
- Eskaera ID ReqName;
- Barrutia gainditzeko baimentasuna Out_range aldagai boolearra da, egiaztatutako barrutia gainditzen duen balio bat eskakizuna urratzen den ala ez zehazten duena.
Zenbait kasutan, proba-balioaren irteerak sistemak marjina bat duela eta bere funtzionamendu-tartetik kanpo funtzionatzen duela adierazten du. Beste kasu batzuetan, irteera batek esan nahi du sistemak ezin dituela setpointak barrutian mantendu.
6. Irudia. Diagramako propietate egiaztatzeko bloke tipiko bat eta bere parametroak.
Bloke honen kalkuluaren ondorioz, Emaitza aldagaia sortzen da irteeran, eta balio hauek hartzen ditu:
- 0 β rNone, balioa ez da definitu;
- 1 β rEginda, betekizuna betetzen da;
- 2 β rFats, baldintza ez da betetzen.
Blokearen irudiak honako hauek ditu:
- identifikatzaile-testua;
- neurketa-mugen parametroen pantaila digitalak;
- parametroaren egoeraren kolore-identifikatzailea.
Blokearen barruan inferentzia logikoko zirkuitu konplexu samarra egon daiteke.
Adibidez, 6. irudian ageri den unitatearen funtzionamendu-tenperatura-tartea egiaztatzeko, barne-zirkuitua 7. irudian ageri da.
7. irudia. Tenperatura-tartea zehazteko unitatearen barne-diagrama.
Zirkuitu-blokearen barruan, bloke-parametroetan zehaztutako propietateak erabiltzen dira.
Baldintzak betetzen diren aztertzeaz gain, blokearen barne-diagramak simulazioaren emaitzak bistaratzeko beharrezkoa den grafikoa du. Grafiko hau kalkuluan zehar ikusteko eta kalkulu ostean emaitzak aztertzeko erabil daiteke.
Kalkuluen emaitzak blokearen irteerara transmititzen dira eta aldi berean txosten orokorreko fitxategi batean erregistratzen dira, proiektu osoaren emaitzetan oinarrituta sortzen dena. (ikus 8. irudia)
Simulazioaren emaitzetan oinarrituta sortutako txosten baten adibide bat formatu jakin baten arabera sortutako html fitxategi bat da. Formatua arbitrarioki konfiguratu daiteke erakunde jakin batek onartutako formatuan.
Zirkuitu-blokearen barruan, bloke-parametroetan zehaztutako propietateak erabiltzen dira.
Baldintzak betetzen diren aztertzeaz gain, blokearen barne-diagramak simulazioaren emaitzak bistaratzeko beharrezkoa den grafikoa du. Grafiko hau kalkuluan zehar ikusteko eta kalkulu ostean emaitzak aztertzeko erabil daiteke.
Kalkuluen emaitzak blokearen irteerara transmititzen dira eta aldi berean txosten orokorreko fitxategi batean erregistratzen dira, proiektu osoaren emaitzetan oinarrituta sortzen dena. (ikus 8. irudia)
Simulazioaren emaitzetan oinarrituta sortutako txosten baten adibide bat formatu jakin baten arabera sortutako html fitxategi bat da. Formatua arbitrarioki konfiguratu daiteke erakunde jakin batek onartutako formatuan.
8. Irudia. Simulazio-emaitzetan oinarritutako txosten-fitxategi baten adibidea.
Adibide honetan, txostenaren inprimakia zuzenean konfiguratzen da proiektuaren propietateetan, eta taulako formatua proiektuaren seinale global gisa ezartzen da. Kasu honetan, SimInTech-ek berak konpontzen du txostena konfiguratzeko arazoa, eta emaitzak fitxategi batean idazteko blokeak lerro hauek erabiltzen ditu txostenaren fitxategian idazteko.
9. Irudia. Txosten formatua ezartzea proiektu globalaren seinaleetan
Eskakizunetarako seinaleen datu-base bat erabiltzea.
Propietateen ezarpenekin lana automatizatzeko, seinaleen datu-basean egitura estandar bat sortzen da bloke tipiko bakoitzeko. (ikus 10. irudia)
10. Irudia. Seinaleen datu-base batean eskakizunak egiaztatzeko bloke baten egituraren adibidea.
Seinaleen datu-baseak honako hau eskaintzen du:
- Sistemaren beharrezko parametro guztiak gordetzea.
- Dauden proiektuaren eskakizunak erosoa ikusteko parametro zehaztuetatik eta egungo modelizazio emaitzetatik.
- Bloke bat edo bloke talde bat konfiguratzea scripting programazio-lengoaia erabiliz. Seinaleen datu-basearen aldaketek diagraman blokeen propietateen balioetan aldaketak eragiten dituzte.
- Testu-deskribapenak, zehaztapen teknikoen elementuetarako estekak edo identifikatzaileak eskakizunak kudeatzeko sisteman gordetzea.
Eskakizunetarako seinaleen datu-basearen egiturak erraz konfigura daitezke hirugarrenen eskakizunak kudeatzeko sistema batekin lan egiteko.11. Irudian eskakizunak kudeatzeko sistemekiko elkarrekintza-diagrama orokor bat aurkezten da.
11. Irudia. Eskakizunak kudeatzeko sistemarekiko elkarrekintzaren diagrama.
SimInTech proba proiektuaren eta eskakizunen kontrol sistemaren arteko elkarrekintza-sekuentzia honako hau da:
- Erreferentzia-baldintzak eskakizunetan banatzen dira.
- Prozesu teknikoen modelizazio matematikoaren bidez egiaztatu daitezkeen zehaztapen teknikoen eskakizunak identifikatzen dira.
- Hautatutako eskakizunen atributuak SimInTech seinaleen datu-basera transferitzen dira bloke estandarren egituran (adibidez, tenperatura maximoa eta minimoa).
- Kalkulu-prozesuan zehar, egitura-datuak blokeen diseinu-diagrametara transferitzen dira, azterketa egiten da eta emaitzak seinaleen datu-base batean gordetzen dira.
- Kalkulua amaitutakoan, analisiaren emaitzak eskakizunak kudeatzeko sistemara eramaten dira.
Baldintzen 3tik 5era bitarteko urratsak diseinu-prozesuan zehar errepika daitezke diseinuan edo/eta eskakizunetan aldaketak gertatzen direnean eta aldaketen eragina berriro probatu behar denean.
Ondorioak.
- Sortutako sistemaren prototipoak lehendik dauden ereduak aztertzeko denbora nabarmen murrizten du, zehaztapen teknikoen eskakizunak betetzeko.
- Proposatutako proba-teknologiak lehendik dauden eredu dinamikoak erabiltzen ditu eta edozein eredu dinamikotarako ere erabil daiteke, SimInTech ingurunean egiten ez direnak barne.
- Loteen datuen antolaketa erabiltzeak eskakizunak egiaztatzeko paketeak sortzeko aukera ematen du ereduen garapenarekin batera, edo baita pakete hauek ereduak garatzeko zehaztapen tekniko gisa erabiltzeko.
- Teknologia lehendik dauden eskakizunak kudeatzeko sistemekin integra daiteke kostu handirik gabe.
Bukaera arte irakurtzen dutenentzat,
Iturria: www.habr.com