1. Įvadas
 
Šiuolaikinių informacinių technologijų laimėjimai stebina vis daugiau įvairių sričių specialistų. Inžinerinės programinės įrangos paklausa atsirado vis tobulėjant atliekamų darbų profesionalumui, tikslumui. Jau 1980m. pirmoji HVAC inžinerinio projektavimo programa buvo pristatyta mikrokompiuteriams Elite programinės įrangos koncerno, o 1981m. jau pasirodė Train produktas. Tačiau pagal nūdienos standartus šios programos buvo gana primityvios, sunkiai pritaikomos atskiriems atvejams, ir jas buvo gan sudėtinga valdyti be tam tinkamos vartotojo žinių bazės. 1982m. su IBM koncerno asmeninių kompiuterių eros pradžia tobulėja ir statybinės inžinerijos programinė įranga. Atsiradus ir ištobulėjus tokiems kaip AutoCAD ir VersaCAD vektorinės grafikos paketams, projektuotojo žinių pritaikymas sprendžiant uždavinius, ir modeliuojant šildymo sistemas tapo kaip integracinis pačios programinės įrangos įrankis. Anksčiau kelti šilumos nuostolių skaičiavimo uždaviniai iškėlė poreikį automatizuoti HVAC projektavimo procesą. Atliekant daugiau tyrimų projektuotojų poreikių atžvilgiu ir kuriant naujus algoritmus, per dvidešimt metų statybinės inžinerijos programinės įrangos rinkoje atsiranda vis tobulesnių paketų.

Šiuo metu vis daugiau orientuojamasi į specializuotos programinės įrangos taikymą kuo įvairesnėse statybinės inžinerijos sferose. Savo kuriamoje programoje aš realizuoju interaktyvią neformalizuojamos struktūros kontūro analizę, šildomo grindų kontūro projektavimo automatizavimą ir šilumos nuostolių bei reikalingų kontūro charakteristikų skaičiavimą. Kadangi turiu termoinžinerijos programos energetikos bakalauro laipsnį, žinau kaip tai yra pravartu, nubraižyti tam tikros patalpos grindinio šildymo kontūrus ir sujungti atskirai nagrinėtus elementus į vieną visumą.

1.1.  Tyrimo objektas
 
Savo kuriamoje programoje aš norėčiau pristatyti neformalizuojamos struktūros statybinėje inžinerijoje analizę ir jos pritaikymą šildomo grindų kontūro projektavimo automatizavimui. Pagrindinės sprendžiamos problemos yra nagrinėjamo objekto aplinkos analizavimas, naudojant intelektualų matematinį patalpos parametrų valdymo modelį, patalpų aibės duomenų valdymas, jų duomenų bazės kūrimas ir jos pritaikymas šilumos parametrų ir poreikių skaičiavimui, taip pat ir grindinio šildymo sistemos komponentų vizualizavimui AutoCAD aplinkoje.

1.2.  Darbo tikslas ir uždaviniai
 
Šiame darbe nagrinėsiu studijuojamą objektą, remdamasis keliais naujais įvaldytais darbo įrankiais, aptarsiu jų galimą problematiką ir privalumus.

Taigi mano nagrinėjamas objektas yra neformalizuojamos struktūros analizė, jos identifikuotų parametrų pritaikymas grindinio patalpų šildymo sistemos automatizuotam projektavimui. Vienas iš pagrindinių uždavinių – surasti pritaikymo galimybę ir pasiūlyti tinkamiausius metodus kombinuotame statybinės inžinerijos projektavime. Mano realizuojamos sistemos tikslas turėtų būti kaip integracinė dalis bet kokios jau esančios inžinerinės sistemos, tokios kaip šildymo radiatoriais ar oru. Kitas svarbus momentas - nematomo patalpos prototipo, aprašyto geometrine ir matematine išraiškomis kūrimas, ir  jo savybėmis pagrįsti inžineriniai skaičiavimai. Taip pat nagrinėjama dviejų šildomų kontūrų tipų  konkurencijos problema. Iš šių  kontūrų renkuosi tik vieną iš jų.

Vis labiau gilindamasis į savo uždavinį, turėjau pasirinkti naujų realizavimo įrankių. Struktūrizuojant savo keliamus uždavinius diagramomis ir aprašant būdingus procesus vizualiai, teko pasirinkti UML kalbos pritaikymą. Taip pat dar vienas naudingas įrankis, kurį pasirinkau, – ADO technologija brėžinio komunikacijai su kuriamos programos naudojamomis duomenų bazėmis.

Mano pasirinktas šildymo sistemos projektavimo modelis padeda man ne tik įsisavinti informacinių technologijų galimybes, bet ir pažvelgti kitomis akimis į mokslinį darbą, susidurti su jo sunkumais, ieškoti problemų sprendimo būdų. Išanalizavęs dabartinę situaciją, galiu pripažinti, kad mano pasirinktos temos įgyvendinimas turi ir daug neišspręstų trūkumų, kuriuos ateityje stengsiuosi ištaisyti. Numatyti galimybę naudoti vieną instaliaciją, pritaikyti ją kitiems pastato aukštams, esant vienodam patalpų planavimui. Praplėsti šilumos parametrų skaičiavimo galimybes, įtraukiant daugiau priklausomų kintamųjų.

1.3.  Temos naujumas
 
Grindinio šildymo sistemos projektavimo automatizavimui yra sukurta daug ir gerų komercinių paketų, tiek Autodesk pobūdžio, tiek specifikuotų programų, kurios nagrinėja ir atlieka šilumos nuostolių skaičiavimus, kontūro vizualizavimą. Arčiausiai nagrinėjamos temos aš išskirčiau tokius programinius paketus kaip FlowMaster, MCAD Ceiling Grid, LoopCAD. Pastarojo galimybes ir siūlomus sprendimo metodus esu išnagrinėjęs plačiau.

Savo temos naujumą grindžiu ir tuo, kad ji artima interaktyviam inžineriniam modeliui, taip taupomas projektuotojo laikas ir vartotojo pinigai. Šiuolaikinė inžinerinė programinė įranga yra neatsiejama nuo internetinio ryšio su atnaujinamais programos ištekliais. Savo programoje aš taip pat nagrinėsiu nuotolinio valdymo galimybę, kuri programą praplėstų ne tik naujais duomenimis, bet ir suteiktų naujovišką bendradarbiavimo modelį projektuotojo su inžinerinės sistemos montuotoju nuotoliniu būdu. Projekte panaudotos naujausios ryšio su duomenų bazėmis technologijos, manau, taip pat suteiks patogumo vartotojui.

1.4.  Temos aktualumas
 
Mano nagrinėjama tema yra aktuali statybinės inžinerijos projektavimo firmoms, kurios užsiima tiek rimtais didelių gyvenamųjų ir gamybinių patalpų projektais, tiek nedidelės apimties individualiais projektais. JAV termoinžinierių asociacija ASHRAE, Vokietijos termoinžinerijos specialistai vis labiau vertina grindinio šildymo sistemų panaudojimą įvairios paskirties patalpose ir inžinerinės struktūros automatizuotą valdymą. Lietuvos inžinerinės firmos, užsiimančios grindinio šildymo projektavimu, teigia, kad sąnaudų požiūriu grindinis šildymas sutaupo vartotojui iki 20% energijos sąnaudų, o šildant kietu kuru net daugiau. Tai nėra pigiausiai įdiegiamas šildymo būdas. Tačiau per metus šias instaliacijos išlaidas atsveria eksploatacijos periodu sunaudojamos energijos sutaupymas ir, be abejo, komfortas, kuris pastaruoju laiku ypač svarbus nūdienos vartotojams.

1.5.  Tyrimo metodai
 
Tyrimus atlieku tomis pačiomis kaip ir programos realizavimo priemonėmis. Privalumų ir trūkumų išskyrimas yra prioritetinis tyrimo metodas mano darbe. Visi naudojami algoritmai išbandyti, palygintas jų efektyvumas; kai kuriuos dar reiktų tobulinti, tačiau apskritai remiuosi straipsniais, nagrinėjančiais panašias problemas, lyginu jų realizavimo galimybes ir naudą. Pagal UML schemas sudarinėjami algoritmai padeda išvengti stambių klaidų, kurios dažniausiai pastebimos per vėlai.

2. Problemos analizė ir formulavimas

2.1. Pradinių projekto duomenų unifikacija
 
Šiuolaikinėje statybinėje inžinerijoje vis daugiau dėmesio skiriama vykdomų projektų duomenų mainų standartams CAD sistemoms unifikuoti. Ypač tai susiję su automatizuojamais produktais ir jų valdymo sistemomis. Parametrinių duomenų mainai svarbūs tiek kuriamiems algoritmams, tiek geometrinių operacijų duomenų struktūroms. Komercine prasme duomenų unifikacija atskleistų didesnes galimybes inžinerijos bendradarbiavimo srityje.

Pasaulyje paplitę keletas modeliavimo standartų priklausomai nuo žemynų. Labiausiai taikomi duomenų mainų metodai, patvirtinti inžinerijos komitetų, yra IGES ir STEP [6]. Šie standartai apima daugelį CAD sistemų parametrinių duomenų tipų, tokius kaip vienetų sistema, kūnų geometrinės reprezentacijos modeliai, brėžinio parametrizavimas, terminologija ir kiti. Pastarasis naudojamas integruojant specialią programavimo kalbą. Duomenų unifikacija prilygsta tam tikram optimizacijos procesui, kuriame duomenų tipas yra “perrašomas” – t.y. analizuojami duomenys pakeičiami kito, aprašyto tipo duomenų išvestinėmis. Šis metodas smarkiai skiriasi nuo kitų metodų, kuriuose kiekvienas duomenų tipas ar jų grupė yra unifikuojami ir aprašomi standartiškai.
Vis dėlto tokias sistemas gan sunku pritaikyti praktikoje, kai daugelis inžinerinių firmų, užsiimančių projektavimu, naudoja visuotinai nesistemingas duomenų bazes, skirtingą programinę įrangą, o smulkesnės firmos turi netgi savitų architektūrinių projektavimo standartų. Lietuvoje šildymo ir vėdinimo inžinerijoje naudojami ASHRAE paskelbti standartai, kurie aprašo daugelį parametrizuojamų duomenų tipų. Tačiau inžinerinės programinės įrangos gamintojai negali orientuotis tik į vieną standartą arba tai sprendžia daugiapakope duomenų unifikacija.

Todėl tenka taikyti individualų pradinių duomenų unifikacijos modelį, kuris nustatytų taisyklingą ryšį tarp pradinių duomenų, jiems apdoroti kuriamų algoritmų ir duomenų išvedimo formatų.

2.1.1.  Modeliavimo konstantų sudarymas
 
Norint nepriekaištingai išspręsti modeliavimo uždavinį, labai svarbus nuolatinių duomenų aprašymas ir galimybė tuos duomenis keisti projektavimo metu, jų išstudijavimas ir pritaikymas. Tuo atveju patogu skaičiuojamuosius ir parametrinius duomenis paversti dalinėmis arba absoliučiosiomis konstantomis.

Statybinės inžinerijos struktūrų analizavimo, skaičiavimo ir vizualizavimo standartinės programinės įrangos duomenų konstantų sudarymo principai pagrįsti keliais pagrindiniais metodais. Vienas iš jų pats paprasčiausias – negrįžtamasis metodas, kuris naudojamas tik itin abstrakčioms struktūroms analizuoti. Integruojamų į skaičiavimus duomenų paruošimas vyksta tik priešprocesorėje stadijoje. Kitas pažangesnis metodas -DTF (Data Type Floating) [7] – suteikia pradiniams duomenims dalinės konstantos tipą, kuris programos metu gali kisti arba įgyti kitokias empirines formas vartotojo nuožiūra. Šis metodas suteikia lankstumo uždavinio realizacijos procesui ir rezultatų apdorojimui. Kiti sudėtingesni metodai yra kombinuoti, dažniausiai turintys tik kai kuriems procesams būdingų požymių.

2.1.2. Duomenų bazių struktūros formavimo prioritetai
 
Savo projekte matau plačių galimybių, o daugeliu atveju ir būtinybę kurti duomenų bazių modelius keliems programuojamiems, tiek pavieniams, tiek nuolatiniams procesams. Pagal paskirtį programos duomenų bazių struktūra formuojama iš:

1. Pirminių parametrų - charakteristikos sudaromos pradinėje stadijoje ir numatoma galimybė vartotojui jas redaguoti ir pildyti.

2.  Antrinių parametrų  - užpildoma vartotojo pagal esamą pradinių duomenų situaciją.

3. Interaktyviai kuriamos, naudojant ankščiau minėtą DTF duomenų ruošimo metodą, saugant tarpinius rezultatus ir sudarant galimybę valdyti geometrinius patalpų ir jų savybių parametrus. Plačiau 2.2 skyriuje.

4.  Projekto skaičiavimo rezultatų, kurie skirti nuotoliniam projekto valdymui.

2.2. Interaktyvi nagrinėjamos erdvės geometrinių parametrų analizė
 
Jau nuo 1986m. didelis dėmesys telkiamas į struktūrizuojamų planų CAD sistemose kūrimą [8]. Vis dažniau įprastiniai funkciniai statybinių erdvių modeliai aprašomi tik jiems būdingų savybių turinčiais hierarchiniais komponentais. Kadangi iš esmės pastato ar jo dalies struktūrą apibūdinantys kriterijai yra erdvė ir forma, tai jie turėtų būti neatsiejamai naudojami bendroje inžinerinėje skaičiavimo sistemoje. Plečiant objektiškai orientuotą požiūrį į šiuos kriterijus, atsiranda galimybė nagrinėjamai struktūrai ar jos komponentui priskirti tik jo paties duomenis (visuotinėje projekto padėtyje) arba sukurti elgsenos tam tikrose situacijose modelį. Toks uždavinio sprendimo būdas mano atveju būtų priimtiniausias ir optimaliausias.

Interaktyvaus įrankio modelio pritaikymo reikšmę erdvės geometrinių parametrų analizei aš įsivaizduoju kaip vartotojo žinių bazės poreikio sumažinimą – tiek informacinių technologijų, tiek inžinerijos prasme. Kitas šio įrankio pranašumo aspektas – tai įmanomų klaidų ir paklaidų modeliavimo metu išvengimas, paliekant tiesioginį geometrinį ryšį tarp pradinio brėžinio ir formuojamos prototipinės struktūros, kuri bus naudojama inžineriniams skaičiavimams atlikti ir projektuojamam kontūrui vizualizuoti.

Patalpos erdvę analizuoju ne tik kaip atskirą projektuojamos sistemos elementą, bet ir kaip vieną elementų visumą, aprašytą jų topologinėmis priklausomybėmis. Šioje stadijoje mano sprendžiamas uždavinys įgyja projekto atžvilgiu visuotiną reikšmę, kai visi projektuojami inžinerinės sistemos elementai sujungiami į vieną funkcinį aparatą. Tai galima atlikti tik visiškai išsprendus individualias struktūras (patalpas). Kadangi neintegruoju grįžtamojo aparato, galutiniai rezultatai bus teisingi tik tada, kai bus visiškai išnagrinėti pavieniai sistemos elementai.Šie aptariami algoritmai neegzistuojančią pradinę matematinio modelio išraišką padės paversti į struktūrizuotą inžinerinės sistemos planą, kurį galima naudoti tolesniems inžineriniams skaičiavimams. Tas pats matematinis struktūros modelis bus kaip pagrindas ir atskaita inžinerinių sistemų kontūrų geometrijai vizualizuoti ir gautiems rezultatams įvertinti.

2.2.1. Neformalizuojamos struktūros aplinkos identifikavimas ir aproksimacija
 
Šia tema panagrinėsiu iškylančius uždavinius, sudaromus naudojantis neapibrėžtomis euristinėmis taisyklėmis, kurios atsiranda priklausomai nuo įvesties duomenų reikšmių [11]. Mano numatoma aplinkos identifikavimo metodika naudoja kelis parametrų būvio aproksimacijos etapus.

Gautas rezultatas nelaikomas viena skaitine verte, o vieno parametro skaitinių verčių visuma. Toks mechanizmas leidžia pirminę (įvesties) struktūrą analizuoti kaip naują nepriklausomą parametrų konstrukciją, išlaikant identifikuoto geometrinio modelio sandarą ir formą. Naudojantis šiais identifikavimo algoritmais galima lengviau analizuoti tiek paprastos poligoninės, tiek neformalizuojamos struktūros aplinką.

Parametrų struktūros
identifikacija
Parametrų
identifikacija
Rezultatų modelis
Įvesties duomenys
Rezultatas

2.1 pav. Aplinkos identifikavimo struktūrinė schema
 
2.2.2. Siūlomi identifikavimo realizacijos metodai
 
Neformalizuojamų struktūrų inžinerijos projektavimo sistemose svarbus momentas yra programuotojo požiūris į vartotojo poreikius valdyti brėžinį ir tiksliai parinkti iš jo duomenis. Standartinė inžinerinė programinė įranga dažniausiai siūlo vieną pažangų metodą identifikacijai atlikti, o visi kiti parametrai nustatomi sudėtingu skaičiavimu arba papildoma vartotojo suteikiama informacija. Siekdamas sukurti didesnę pasirinkimų aibę aš integruoju tris struktūros aplinkos identifikacijos modelius. Tai tikslinga ne tik todėl, kad patogu, tačiau ir dėl neišvengiamų architektūrinių brėžinių skirtumų. Nevienodos erdvių dimensijos ir anksčiau aprašyti elementų geometrinės struktūros skirtumai turi įtakos ne tik pačiam identifikavimo procesui bet ir vėliau rengiamam elementų sujungimui.
Pirmuoju atveju yra sudaromas patalpos geometrinių charakteristikų parametrų elementarus masyvas, kurio principas nėra sudėtingas. Kiekvienas parametrų adresas turi po dvi koordinačių reikšmes [9]. Tokiu atveju, kai analizuojama struktūra yra daugiapakopė, trečioji koordinatė (aukščio) yra kaip konstanta visiems nagrinėjamiems elementams. Šis metodas gali būti taikomas tik tokiems poligoniniams objektams, kurie brėžinio atžvilgiu išdėstyti vienu iš keturių įmanomu statumo atveju. Objekto geometrijos realumas netikrinamas. Šiuo algoritmu išanalizavus struktūrą, galimas kontūro charakteristikų optimizacijos procesas.

Elementarus 2D  algoritmas
Random 2D algoritmas
3D algoritmas

Antruoju atveju atliekama intelektuali patalpos kontūro analizė. Jos patalpos parametrų adresai taip pat turi po dvi arba tris koordinačių reikšmes, tačiau šiam algoritmui aprašomos papildomos matematinės sąlygos - objekto egzistavimo sfera. Šiam algoritmui pagal identifikacijos duomenis sudaromos patalpos kraštinių lygtys kiekvienai analizuojamai sienai [7, 12]. Aukščio koordinatės sąlyga yra ta pati kaip ir pirmojo algoritmo, o geometrijos realumas tikrinamas uždaros kilpos principu [19]. Jei pastaroji sąlyga neįvyktų, tolesnis modeliavimas neįmanomas.

Trečiuoju atveju patalpos parametrai interaktyviai iš brėžinio suindeksuojami dinaminiame masyve. Šis algoritmas našiausiai būtų pritaikomas tokioms geometrinėms erdvėms, kurių horizantãlių altitudės vieno elemento lygmenyje skiriasi. Kitu atveju rekomenduojama pasirinkti antrąjį algoritmą.

Dar vienas svarbus momentas – tai interaktyvi užklausa, klausianti vartotojo, ar nurodyta atitvara yra išorinė ar vidinė. Atsižvelgiant į tai, nuostoliai per atitvarą bus skaičiuojami arba neskaičiuojami.

Visi identifikuojami parametrai dinamiškai saugomi projekto duomenų bazėje, nepriklausomai nuo pasirinkto identifikavimo tipo viso projekto mastu. Pagal identifikuotus geometrinius parametrus galima skaičiuoti patalpos šilumos parametrus ir tiesiškai optimizuoti inžinerinės sistemos modelį.

2.2.3. Projekto duomenų bazių ir jų valdymo ypatumai
 
Mano formuojamą projekto duomenų bazės modelį turėtų sudaryti trijų paskirčių duomenų saugojimo aparatai. Pirmasis, jau aprašytas anksčiau, yra skirtas pradiniams duomenims saugoti, antrasis – medžiagų ir normatyvų duomenų bazėms valdyti, o trečiasis skirtas identifikuotų parametrų duomenų bazėms. Pastarasis duomenų bazių aparatas veikia su visais trimis anksčiau išvardytais parametrų identifikavimo algoritmais. Norėdamas pademonstruoti optimaliausios realizacijos aparatą aptarsiu antrojo algoritmo (2D Random) bendradarbiavimo schemą su projekto duomenų baze.

2.5 pav. pavaizduotame identifikacijos duomenų modelyje siūloma skaidyti statybinę struktūrą į paprastesnius geometrinius elementus, kurie vėliau nagrinėjami atskirai, sudarant naujų struktūrų matematinius modelius, surašius topologines priklausomybes. Šis geometrinių duomenų saugojimo principas tinka tik tokioms nagrinėjamoms patalpoms, kuriose nėra bukų vidinių kampų.

2.6 pav. nagrinėjamas mano identifikuojamos patalpos kontūras kiek kitokiais principais. Jis apibrėžiamas interaktyviai programai nežinant galutinių duomenų kiekio (dinaminiais masyvais). Patalpa nedalijama į atskirus segmentus, o nagrinėjama kaip viena bendra taškų sritis. Kiekvienas patalpos kampo taškas turi gana daug aprašomųjų duomenų, kurie vėliau bus naudojami inžinerinės struktūros kontūrui vizualizuoti. Tai yra vienas iš patalpos valdymo algoritmų, kuris savo pobūdžiu tobulesnis už pirmąjį.

Duomenų bazėms valdyti nutariau pasirinkti ADO technologiją, kurios pritaikymo galimybes nagrinėju kitame skyriuje, o eksperimentinėje analizėje aptarti šios technologijos integravimo pranašumai mano programuojamos sistemos aplinkoje.

2.2.4. ADO objektų konkurencijos nagrinėjimas
 
Nagrinėsiu rašymo/skaitymo modelį, įgyvendinamą pasitelkus ADO technologiją. Nagrinėjama konkurencingų prisijungimų prie vienos duomenų bazės keleto ryšių ir studijuojama problematika apie darbo neefektyvumą bei didelių duomenų laikymą transakcijos procese [13]. Siūlomas sprendimo būdas savo ruožtu perša  rimtesnį objektų semantikos analizavimą ir studijavimą. Eksperimentiniais tyrimais įrodyta, kad ADO duomenų bazių valdymo technologija šiuo atveju yra pranašesnė už kai kuriuos kitus įrankius ir spartesnė net iki 10 kartų. Straipsnio autoriai siūlo paprastą “read/write” modelį paversti į “abstract data type” modelį.

Bandymai buvo daryti trims duomenų nuskaitymo modeliams:
1.    Saugojant tarpinius nuskaitymo rezultatus.
2.    Sukuriant naują duomenų bazės modelį rezultatams laikyti.
3.    ADO ryšių su duomenų bazėmis sudarymas.

Savo modelyje apsistoju ties trečiuoju studijuotu duomenų bazių komunikavimo modeliu – ADO, kuriuo naudojantis visus duomenis galime išrinkti nesudėtingu algoritmu interaktyviai bendradarbiaudami su brėžinio parametrais ir vartotojo papildomais nuostačiais. Identifikavimo procese ir tolesniame intelektualaus kontūro valdyme  svarbus ne tik analizuojamas taškas, bet ir prieš jį ir po jo esantys taškai. Tokią konkurencingą nuskaitymo technologiją įgyvendinti tikiuosi ADO ryšiais su duomenų bazėmis. Mano atlikti eksperimentiniai tyrimai pateikti 4.4.1 poskyryje.

Taigi čia kalbama apie specifikacijų sudarymą, tačiau ateityje ruošiuosi pasinaudoti ADO ryšiais su duomenų bazėmis, modeliuojant “intelektualią” kontūro analizę, kur periferinė CAD sistema dirba su dinaminiais masyvais, kuriamais interaktyviai bendraujant su brėžiniu, ir kur reikalingi dideli kiekiai informacijos to kontūro intelektualiam valdymui sukurti.

2.3. Skaičiuojamųjų schemų sudarymas ir jų optimizavimas
 
Savo tiriamajame darbe pagrindiniu akcentu pasirinkau neformalizuojamos inžinerinės struktūros projektavimo ypatumus, integruodamas grindinio šildymo kontūro modeliavimą pagal apskaičiuotą identifikuotą architektūrinį matematinį patalpos modelį ir šiluminius parametrus, ir nesutelkdamas dėmesio į patį termoinžinerijos objektą. Daugiau dėmesio norėčiau skirti į pačios aplinkos santykį su modeliuojamos sistemos parametrais. Supaprastintas šilumos poreikio skaičiavimo modelis gali būti vienas iš kriterijų grindinio šildymo kontūro optimizacijai, į ką ir bus orientuoti skaičiuojamųjų schemų sudarymo algoritmai.

2.3.1. Šilumos poreikių skaičiavimas
 
Pasirinktas šilumos nuostolių skaičiavimo algoritmas, patvirtintas ASHRAE inžinierių organizacijos ir pavadintas CLTD metodu [15]. Kadangi egzistuoja be galo daug algoritmų ir būdų, kaip skaičiuoti šilumos nuostolius ir pritekėjimus, integruodamas jį į savo kuriamą programą šiek tiek supaprastinu šį modelį neįskaičiuodamas nuostolių ir pritekėjimų viršijančių 2% nominalaus šilumos deficito. Nuostoliai per vidines atitvaras taip pat neskaičiuojami. Lietuvos sąlygoms šis modelis yra visiškai priimtinas [18].

Pradiniai skaičiavimo parametrai siunčiami iš ankstesnių vartotojo nustatytų parametrų ir identifikuotų patalpos geometrinių rodiklių. Skaičiuojamajam modeliui sudaryti reikalingi šie pradiniai duomenys:
1. Nagrinėjamo objekto geografinės lokacijos pagal miestą nustatymas. Pagal šį kriterijų parenkama tinkama normatyvų duomenų bazė.
2. Nagrinėjamos patalpos topologinis ryšys su šiaurės kryptimi, taip sudarant temperatūrų interpoliavimo formulę šiuo atveju.
3. Patalpos pageidautina temperatūra, nustatyta pagal patalpos paskirtį.
4. Identifikuotos patalpos langų ir durų geometriniai parametrai.
5. Patalpos topologinė priklausomybė nuo absoliutaus nagrinėjamo objekto.

Pagal šiuos duomenis sudaromas matematinis nuostolių skaičiavimo modelis atskirai kiekvienai patalpai. Nepriklausomai nuo bendro modeliavimo proceso eigos šie skaičiavimai gali būti atlikti kiekvienoje projektavimo stadijoje.

Šilumos poreikių skaičiavimui atlikti reikalingos statybinių medžiagų šiluminių varžų charakteristikos. Kadangi nuostoliai per vidines atitvaras neskaičiuojami, reikalingos tik išorinių atitvarų ir perdangų arba stogo šiluminių varžų kombinuotos reikšmės. Langų ir durų geometriniai parametrai leidžia apskaičiuoti nuostolius ir pritekėjimus per juos. Vėdinimo ir infiltracijos nuostolių skaičiavimas atliekamas naudojant supaprastintą šilumos nuostolių skaičiavimo metodą [19]. Jis remiasi tik patalpos paskirties charakteristika ir patalpos tūrio reikšme.

2.3.2. Kontūro charakteristikų parinkimas optimizacijos metodu
 
Norint tobulai ir ekonomiškai suprojektuoti inžinerinę sistemą ir parinkti tinkamas medžiagas – neužtenka vien tik apskaičiuotų geometrinių ir šilumos parametrų. Savo kuriamoje programoje noriu įvesti optimizacijos metodu paremtą modulį, kuris lygintų preliminariai projektuojamą sistemą su sistema, kurios ekonominiai eksploatacijos rodikliai būtų glaudžiai susieti su paties šildymo kontūro geometrine forma, išdėstymu ir siūlytų optimaliausią variantą projektuotojui [17]. Taikant mano pasiūlytą pirmąjį patalpos identifikacijos algoritmą, galima taikyti šį optimizacijos modulį, taip įgalinant sumažinti išlaidas instaliacijai, detalėms ir visam eksploatacijos periodui. Formalus metodo aprašymas pristatomas teorinio pagrindimo dalyje.

2.4. Neformalizuojamos struktūros kontūro vizualizavimas ir specifikavimas
 
Išanalizavus ir realizavus visus reikalingus iki šiol aptartus algoritmus, visi reikalingi duomenys neformalizuojamai struktūrai yra vizualizuoti. Kalkės (patalpos prototipo) vizualizacija vykdoma jau ankstesniojoje stadijoje, tačiau skaičiuojamųjų schemų sudarymui neturi įtakos, kadangi tos struktūros reikalingos tik objekto egzistavimo sferai nustatyti ir vizualiai patikrinti geometrijos teisingumą. Vykdant skaičiuojamųjų schemų sudarymą šis sluoksnis iš viso panaikinamas, kadangi reikalingi parametrai yra jau surašyti į projekto duomenų bazę ir reikalui esant gali būti vėl atkurti vizualia išraiška [25; 26].
Priklausomai nuo šildymo tipo pasirinkimo pradinių projektavimo duomenų nustatymo stadijoje, galimi keli šildymo kontūro vizualizavimo tipai, kuriuos projektuotojas gali pasirinkti savo nuožiūra (2.8 pav.). 
 
Šildymo kontūro vizualizacija atliekama apskaičiavus ir parinkus reikiamas medžiagas inžinerinei sistemai projektuoti. Žemiau esančiuose paveikslėliuose nurodyta, kaip turėtų atrodyti vizualizuotas kontūras abiem šildymo tipams.
 
Kitas etapas - individualių schemų sujungimas, kurio metu sudaromos bendros projekto specifikacijos ir parenkami šaltinio įvadai ar stovai, priklausomai nuo nagrinėjamos sistemos tipo.

2.5. Projekto nuotolinio valdymo galimybių analizė
 
Nuotolinio projekto valdymas vis populiarėja tarp rimtesniais projektais užsiimančių įmonių. Vienintele duomenų bazės (pvz.:MySQL) sąsaja galima sukurti vieną aparatą tiek struktūrizuotiems projekto duomenims siųsti, tiek naudotis nuotolinėmis duomenų bazėmis modeliavimo metu. Šį integruojamą algoritmą savo projekte priskirčiau kaip rezonuojantį į šiuolaikines informacines technologijas ir bendrus inžinerinės programinės įrangos standartus.
Šių galimybių analizė vis dar apmąstoma – ieškau tinkamo mano atvejui veikimo principo, kuris turėtų vientisinį pritaikymą mano analizuojamoje programoje.

2.6. UML priešprocesorės integracijos nagrinėjimas
 
Šioje analizėje pateikiamas objektiškai orientuoto projektavimo požiūris ir galimybės UML kalbos aplinkoje [5]. Tai daugiau yra mokslinio tyrinėjimo objekto modelis, kurį vis daugiau norima integruoti į švietimo aplinką kaip labai būtiną įrankį, kadangi objektiškai orientuotame programavime programuotojas kiek galima ilgiau tikisi išlikti nepriklausomas nuo pagrindinės funkcinės programos aprašymo, nes tiek nauji algoritmai gali tai pakeisti, tiek senieji tapti visai nereikalingais, ypač dirbant su objektais naujoje mažai ištirtoje sferoje. Nagrinėjau ir lyginau du CAD modeliavimo algoritmus.

Pirmasis apima pastatų renovacijos ir permodeliavimo aspektus. Naudojama turimo brėžinio analizė, pagal kurią visi išnagrinėti duomenys analizuojami ir pateikiami tolesniam apdorojimui arba jų integracijai į naują brėžinį, naują modelių pritaikymą esamoje brėžinio terpėje. Savo darbe aš taip pat nagrinėju pasirinktos patalpos kontūrą trimis atvejais: kai ji yra visiškai elementari (stačiakampė), vadinamąjį “intelektualios” kontūro analizės pritaikymą (kai patalpos kontūras sudaromas interaktyviai) ir 3D analizę.

Antrasis algoritmas nagrinėja HVAC brėžinio komponentus (pavyzdžiui, ventiliacijos kanalus) ir jiems pridedami papildomi parametrai. Tai skirta ne tik brėžinio informatyvumui, bet ir bendram vizualizuotų objektų supratimui. Tai ypač būdinga mano tyrinėjamui objektui, kadangi pagrindiniai duomenys vizualizavimui yra perduodami iš CAD sistemos. Kaip vieną iš nagrinėjamų tolyginių pavyzdžių galiu pateikti savo atveju šildymo kontūro tarp sujungimo realumą  ir bendrinių siūlomų sprendimų – ventiliacijos kanalų sujungimo realumą.

Nagrinėju UML schemų pritaikymo galimybes objektiškai orientuoto projektavimo algoritmuose, kurie yra tiesiog sukonstruojami pagal užduočių ir logines diagramas. Taigi tuo pačiu sistemos modeliavimo metu rekomenduojama kuo daugiau integruoti UML kalbą ar diagramomis aprašytų funkcinių savybių, esą tai padėtų realizuoti savo uždavinius efektingiau ir išvengti bet kokių neracionalumo klaidų, pasitaikančių modeliuojant inžinerinę sistemą.
Remiantis savo UML patirtimi tenka pripažinti, kad tai yra ne tik teisybė, tačiau ir būtinybė. Konstruojant savo nagrinėjamą objektą programiškai, vizualiai nematant jo komponentų ir sąveikų struktūrų, daug sunkiau pasiekti efektyvių rezultatų negu konstruojant logiškas objektų sąveikos schemas. UML yra labai galingas įrankis tiek savo informatyvumu šiuolaikinėse programavimo kalbų aibėse, tiek savo technika ir pritaikymu. Man pavyko ištirti labai nedidelę dalį tų galimybių, kurias siūlo UML.

3. Programos struktūros modeliavimas

3.1. UML – unifikuota modeliavimo kalba
 
Unifikuota modeliavimo kalba (UML), pasirodžiusi 1997 metais, yra bendrinė kalba skirta specifikuoti, vizualizuoti, konstruoti, ir apibendrinti programinės įrangos sistemas bei modeliuoti komercinę veiklą ir kitas neprogramines sistemas. UML yra labai svarbi dalis, tiek kuriant objektiškai orientuotą programą, tiek konstruojant jos kūrimo etapus. Taigi tuo pačiu sistemos modeliavimo metu rekomenduojama kuo daugiau integruoti UML kalbą ar diagramomis aprašytų programos funkcinių savybių, kas padėtų realizuoti savo uždavinius efektingiau bei išvengti bet kokių neracionalumo klaidų, pasitaikančių modeliuojant sistemą. Konstruojant savo nagrinėjamą objektą programiškai, vizualiai nematant jo komponentų bei sąveikų struktūrų, daug sunkiau pasiekti efektyvių rezultatų konstruojant logiškas objektų sąveikos schemas.

Mano modeliuojamas UML projektas paremtas tradiciniu “Waterfall” modeliu [27], pagal kurį kiekviena iš žemiau išvardintų stadija turi būti realizuota, prieš prasidedant sekančiai.
 
Analizė
Modeliavimas
Įgyvendinimas
Testavimas
Išdėstymas 
 
Toliau aprašau svarbiausius programos algoritmus, naudodamas nuoseklų analizės metodą, aprašantį kiekvieną procedūros veikimo konstrukciją, bei duomenų paruošimo principus.

3.2. Programos vizija
 
Norėdamas bendrai išsiaiškinti keliamus uždavinius, visų pirma sukuriu UML panaudojimo atvejų diagramą. Mano kuriamos programos koncepcija yra grindinio šildymo sistemos modeliavimas, naudojant identifikuotus patalpų parametrus iš brėžinių. Pagrindinis vartotojas  bendradarbiauja su programa per kompiuterį, kuris realizuoja 3.2 pav. pavaizduotus uždavinius.

Inicijuojamas pradinių duomenų įvedimo dialogas, kurio pagalba pradedamas pastato modelio sudarymas, vėliau jame esančių patalpų identifikavimas iš brėžinių vartotojo pagalba. Pagal gautus identifikacinius duomenis vykdomi visi tolesni programoje numatyti algoritmai, kaip nuostolių skaičiavimas, šildymo sistemos parametrizavimas (patalpos kontūro apibrėžimas), kuriame parenkami SS bei kontūro tipai. Pagal turimus parametrus, taip pat vykdomas šildymo kontūro vizualizavimas CAD sistemoje. Išvedami rezultatai bei sudaroma specifikacija. Žemiau esančioje diagramoje pavaizduotas naudosimų duomenų bazių kompleksinis modelis. 

3.3. Bazinių projekto duomenų modeliavimas
 
Norint išsiaiškinti keliamiems uždaviniams naudojamus objektus ir jų klases, sukuriu UML koncepcinį modelį. Tam naudoju UML klasių diagramą, kurios pagalba aprašau pagrindinius modeliavimo funkcijų tikslus vartotojo atžvilgiu. Ta pačią diagramą naudosiu ir programos konstravimo stadijoje.

Vienas svarbiausių programos komponentų sąveikos aspektas – projekto duomenų bazės modeliavimas, kurio metu reikia tinkamai parinkti kokius duomenis kur saugoti, norint išvengti nepatogumų juos naudojant ateityje (3.4 pav.). Taigi pagal projekto duomenų bazės hierarchiją, pagrindinė yra projekto duomenų lentelė ir patalpų duomenų lentelė. Pastarosios duomenyse bus saugomi vienetiniai duomenys apie patalpą. Tuo tarpu kiekvienai patalpai su jos pasikartojančiais (kampų) parametrais irgi bus kuriama atskira lentelė. Kadangi bazės duomenys bus dažnai naudojami ir įrašomi įvairių algoritmų (priedas 7.2.1) sukuriu būsenos valdymo modelį, kurio paskirtis yra įkelti analizuojamą projektą arba patalpą (priedas 7.2.21). Būsenos tranzitiniai duomenys saugojami išorinėse konfigūracinėse rinkmenose plėtiniu ‘ini’. Tokiu būdu programos eigą vartotojas gali pasirinkti pats, nes tuo metu analizuojami duomenys paprastai po kiekvienos procedūros išsaugomi ir programa atsimena ties kokia projektavimo vieta vartotojas baigė savo darbą. Neatsiejamas ryšis identifikacijos aplinkoje yra ir tarp architektūrinių pastato brėžinių ir įrašomų išanalizuotų parametrų į projekto duomenų lenteles.
 
Sekantis žingsnis, formuojant programos struktūrą, apsprendžia šildymo sistemos projektavime dalyvaujančius objektus ir jų vykdomas procedūras. Skaičiavimai ir kontūro vizualizavimas atliekami panaudojant identifikuotus duomenis iš projekto duomenų bazės. Šilumos poreikių skaičiavimui naudojamos atitvarų ir normatyvų duomenų bazės. Pagal išskaičiuotą šilumos poreikį parenkamas šildomojo kabelio galingumas ir kiti šildymo sistemos elementams būdingi parametrai. Kiekvienos procedūros analizuojami duomenys yra matomi tik toje procedūroje, išskyrus atvejus kai jie siunčiami kitiems algoritmams. Toks uždaras duomenų naudojimas pagrįstas kompiuterio atminties taupymu, kadangi egzistuoja tiesioginio duomenų saugojimo mechanizmas. Medžiagų parinkimas vykdomas ne tik vartotojo bet ir pačios programos siūlančios kai kuriuos optimalius variantus konkrečiam atvejui.

3.4. Algoritmų analizė
 
Modeliavimo etape programą laikau kaip “black box”. Tai reiškia, kad sistemą aprašau tik aktorių užklausų ir atsakymų joms schema, nesigilinant kaip sistema iš tikrųjų atlieka jai pavestas užduotis.
Algoritmų analizės etapą, beje kaip ir modeliavimo, dalinu į dvi dalis – inžinerinės platformos identifikavimo ir inžinerinės sistemos projektavimo. Pirmojoje dalyje – projekto duomenų bazė sudarinėjama, kai tuo tarpu antrosios metu duomenys iš jos tik nuskaitomi (išimtis – šilumos poreikio, įvado kampo ir kontūro tipo įrašymas). Žemiau esančioje eiliškumo schemoje pavaizduota kokia seka objektai dalyvauja minėtos pirmosios dalies procedūrose.
 
Vartotojui įvedus pastato pradinius parametrus sukuriama duomenų bazė, kurioje kuriamos lentelės patalpų duomenims laikyti. Iškart po patalpos sukūrimo vykdoma jos geometrijos identifikacija ir apskaičiuojama absoliuti padėtis pastate. Šioje stadijoje kryptis pasaulio šalių atžvilgiu neįvertinama. Kadangi numatytas ir “bulk” patalpos  modelio kūrimas (be identifikacijos duomenų) labai svarbi detalė yra aiškus apibrėžimas kuris objektas yra nagrinėjamas duotuoju laiku. Dėl to aktyvios patalpos būsena yra automatiškai nustatoma tik ją sukūrus. Taipogi numatau kuriamų objektų valdymo algoritmą, pagal kūrį pats vartotojas galėtų įkelti į analizuojamą aplinką norimą objektą. Panašaus pobūdžio algoritmas numatytas ir projekto kūrimo atveju.

3.5. Procedūrų modeliavimas
 
Išnagrinėjus objektų procedūrų eiliškumą, pereinu prie objektų bendradarbiavimo schemų, kuriose nagrinėju objektų sąveikos ypatumus. Kiekvienas konstruojamas algoritmas vadovaujasi dominuojančios procedūros (projekto duomenų valdymo) rezultatais ir jais remiantis naudoja vienokias ar kitokias individualias priemones skaičiavimo ir vizualizavimo uždaviniams spręsti.

3.6. Procedūrų detalizavimas
 
Išnagrinėjus bendrą programos struktūrą ir joje dalyvaujančių objektų paskirtį bei jų tarpusavio ryšius, analizuoju kiekvieną algoritmą detaliau, atsižvelgdamas į papildomos problematikos iškilimo galimybę.
Aprašau kokiais algoritmais yra apibrėžiamas patalpos kontūras, kaip valdomi duomenys, ir kur yra jų rezidavimo vieta. Šiame etape sprendžiama intelektualaus kontūro valdymo problemos dalis – identifikacijos tipų taikymas įvairiems patalpos modeliams. Sekančioje aktyvumo schemoje pavaizduotas grindinio kontūro vizualizavimo algoritmas.

3.7. Programos naudojami komponentai
 
Programos komponentų modelis aprašo kokiais išoriniais ir vidiniais ištekliais naudojasi programa ir koks yra jų ryšys su programos realizuojamais algoritmais.
 
Išorinius programos išteklius sudaro dvi MS Access duomenų bazių rinkmenos – medžiagų ir normatyvų. Kiekvienas naujai kuriamas projektas taip pat saugomas į duomenų bazės rinkmeną. Tranzitinė ‘ini’ rinkmena saugo projekto ir patalpos būsenos duomenis.

Prie vidinių programos išteklių galima priskirti ADO technologijos naudojamą Jet duomenų jungtį AutoCAD programoje, be kurios įkėlimo, vykdomų procedūrų metu, DB valdymas būtų neįmanomas.

4. Programa inžinerinės sistemos projektavimui
 
Programos GSS (toliau GSS) veikimas ir naudojimas suskaidytas į dvi dalis – topologinio modelio sudarymo ir šildymo sistemos projektavimo. Pirmojoje dalyje apskaičiuoti duomenys naudojami antrosios dalies procedūrų.
Pastato topologinį modelį vartotojas sudaro pats iš pastato architektūrinių brėžinių. Kuriant programą, vadovavausi ASHRAE asociacijos numatytais brėžinių standartais taikomais visoje Europoje, todėl programa naudoja SI vienetų sistemą. GSS pastatą užpildo vartotojo identifikuotomis patalpomis, suteikdama galimybę pasirinkti iš trijų identifikacijos tipų, taip užtikrindama geometrinių duomenų tikslumą, bei laisvę naudoti įvairių tipų brėžinius. Nesvarbu kokiu tipu identifikuojama patalpa, GSS sukuria 3D patalpos modelį, be langų ir durų koordinačių, o tik su jų plotais, ko pilnai užtenka šilumos nuostoliams ir projektinei šilumos galiai skaičiuoti. Sukurtas GSS projektas gali būti lengvai įkeliamas arba ištrinamas, taip pat kaip ir pačios patalpos atskirai, esančios tame projekte. Taip pat vartotojas turi galimybę vizualiai pasitikrinti ar sukurtame pastato modelyje nėra klaidų, ir reikalui esant jas ištaisyti.

Sekanti GSS nagrinėjama projekto dalis yra grindinio šildymo sistemos projektavimas. Vartotojas savo nuožiūra kiekvienai patalpai nurodo įvadų padėtį patalpoje, nuo kurių bus pradedamas šildomojo kontūro vizualizavimas. Pats kontūras gali būti kelių tipų, priklausomai nuo patalpos geometrijos sudėtingumo, kurį GSS gali parinkti pati arba leisti tai apspręsti vartotojui. Šilumos nuostolių skaičiavimo eiga vartotojui nėra demonstruojama ir tarpiniai rezultatai neišvedami. Pasitikrinimui vartotojas gali palyginti tik galutinius rezultatus, pagal kuriuos ir skaičiuojami šildymo kontūro sudedamieji parametrai.

Grafiniai rezultatai išvedami į aukšto brėžinius, tolygiai sudarinėjant specifikaciją kiekvienai aukšto patalpai. Bet kuriame programos etape vartotojas gali keisti pradinius pastato duomenis, iš naujo identifikuoti patalpas, perskaičiuoti šilumos poreikį visoms ar tik vienai patalpai. Kiekvienos procedūros metu GSS kreipiasi į projekto duomenų bazę, todėl ir įmanomas toks paprastas ir lankstus projekto valdymas.

Kaip vienas iš įdomesnių sprendimų programoje yra pagalbinis meniu (priedas 7.2.2 ir 7.2.22). Kadangi vartotojui tenka dažnai rinkti duomenis arba juos tiesiog pasitikslinti iš brėžinių, GSS numatytas pagalbinių komandų meniu, kuris yra integruotas beveik į kiekvieną programos dialoginį langą (4.1 pav.).
 
Šio meniu dėka vartotojas gali laikinai paslėpti aktyvų dialoginį langą brėžinio peržiūrai, nenutraukiant paties jau pradėto proceso. Papildomos funkcijos yra taško arba atstumo pagal pasirinktus parametrus (bendrus arba pagal ašį) nuskaitymas iš brėžinio

 © Visos straipsnio teisės saugomos
Kopijuoti be autoriaus sutikimo griežtai draudžiama