Jatketaan teemaa , katsotaan matemaattisen mallinnuksen ongelmaa toiselta puolelta. Kun olemme vakuuttuneita siitä, että malli vastaa elämän kotikuoteltua totuutta, voimme vastata pääkysymykseen: "mitä meillä tarkalleen ottaen täällä on?" Kun luomme mallia teknisestä esineestä, haluamme yleensä varmistaa, että tämä esine vastaa odotuksiamme. Tätä varten suoritetaan prosessien dynaamisia laskelmia ja tuloksia verrataan vaatimuksiin. Tämä on digitaalinen kaksos, virtuaalinen prototyyppi jne. muodikkaita pikkukavereita, jotka ratkaisevat suunnitteluvaiheessa ongelman, kuinka varmistaa, että saamme sen, mitä suunnittelimme.
Kuinka voimme nopeasti varmistaa, että järjestelmämme on juuri sellainen kuin suunnittelemme, lentääkö vai kelluuko suunnittelumme? Ja jos se lentää, kuinka korkealle? Ja jos se kelluu, kuinka syvälle?
Tässä artikkelissa käsitellään teknisen rakennuksen vaatimustenmukaisuuden todentamisen automatisointia luotaessa teknisten järjestelmien dynaamisia malleja. Katsotaanpa esimerkkinä lentokoneen ilmanjäähdytysjärjestelmän teknisen eritelmän elementtiä.
Otamme huomioon ne vaatimukset, jotka voidaan ilmaista numeerisesti ja todentaa matemaattisesti tietyn laskentamallin perusteella. On selvää, että tämä on vain osa minkä tahansa teknisen järjestelmän yleisiä vaatimuksia, mutta juuri niiden tarkistamiseen käytämme aikaa, hermoja ja rahaa kohteen dynaamisten mallien luomiseen.
Kun teknisiä vaatimuksia kuvataan dokumentin muodossa, voidaan erottaa useita erityyppisiä vaatimuksia, joista jokainen vaatii erilaisia lähestymistapoja vaatimusten täyttymisen automaattisen varmistuksen muodostamiseen.
Harkitse esimerkiksi tätä pientä mutta realistista vaatimusjoukkoa:
- Ilman lämpötila vedenkäsittelyjärjestelmän sisäänkäynnissä:
parkkipaikalla - miinus 35 - 35 ºС,
lennon aikana - miinus 35 - 39 ºС. - Ilmakehän staattinen paine lennon aikana on 700 - 1013 GPa (526 - 760 mm Hg).
- Ilman kokonaispaine SVO:n ilmanottoaukon suulla lennon aikana on 754 - 1200 GPa (566 - 1050 mm Hg).
- Jäähdytysilman lämpötila:
parkkipaikalla - enintään 27 ºС, teknisissä lohkoissa - enintään 29 ºС,
lennon aikana - enintään 25 ºС, teknisissä lohkoissa - enintään 27 ºС. - Jäähdytysilmavirta:
pysäköitynä - vähintään 708 kg/h,
lennon aikana - vähintään 660 kg/h. - Instrumenttiosastojen ilman lämpötila on enintään 60 ºС.
- Hienojakoisen vapaan kosteuden määrä jäähdytysilmassa on enintään 2 g/kg kuivaa ilmaa.
Jopa näissä rajoitetuissa vaatimuksissa on vähintään kaksi luokkaa, joita järjestelmässä on käsiteltävä eri tavalla:
- järjestelmän käyttöolosuhteita koskevat vaatimukset (kohdat 1-3);
- järjestelmän parametriset vaatimukset (kohdat 3-7).
Järjestelmän käyttöolosuhteita koskevat vaatimukset
Mallintamisen aikana kehitettävän järjestelmän ulkoiset ehdot voidaan määritellä reunaehdoksi tai yleisen järjestelmän toiminnan tuloksena.
Dynaamisessa simuloinnissa on tarpeen varmistaa, että määritellyt käyttöolosuhteet kattavat simulointiprosessin.
Parametriset järjestelmävaatimukset
Nämä vaatimukset ovat järjestelmän itsensä antamia parametreja. Mallintamisen aikana voimme saada nämä parametrit laskentatuloksiksi ja varmistaa, että vaatimukset täyttyvät kussakin laskennassa.
Vaatimukset tunnistaminen ja koodaus
Vaatimusten kanssa työskentelyn helpottamiseksi nykyiset standardit suosittelevat tunnisteen määrittämistä kullekin vaatimukselle. Tunnisteita määritettäessä on erittäin toivottavaa käyttää yhtenäistä koodausjärjestelmää.
Vaatimuskoodi voi olla yksinkertaisesti numero, joka edustaa vaatimuksen tilausnumeroa, tai se voi sisältää koodin vaatimuksen tyypille, koodin järjestelmälle tai yksikölle, jota se koskee, parametrikoodin, sijaintikoodin ja mitä tahansa muuta, mitä insinööri voi kuvitella. (katso artikkeli koodauksen käytöstä)
Taulukossa 1 on yksinkertainen esimerkki vaatimusten koodauksesta.
- vaatimusten lähteen koodi R-vaatimukset TK;
- vaatimuskoodityyppi E - vaatimukset - ympäristöparametrit tai käyttöolosuhteet
S - järjestelmän tarjoamat vaatimukset; - ilma-aluksen tilakoodi 0 – mikä tahansa, G – pysäköity, F – lennossa;
- fyysisen parametrin tyyppikoodi T – lämpötila, P – paine, G – virtausnopeus, kosteus H;
- vaatimuksen sarjanumero.
| ID Vaatimukset |
Kuvaus | Parametri |
| REGT01 | Ilman lämpötila vesijäähdytysjärjestelmän sisäänkäynnissä: parkkipaikalla - miinus 35ºС. jopa 35 ºС. | |
| REFT01 | Ilmakehän lämpötila ilmapuolustusjärjestelmän sisäänkäynnissä: lennon aikana - miinus 35 ºС - 39 ºС. | |
| REFP01 | Staattinen ilmanpaine lennon aikana on 700 - 1013 hPa (526 - 760 mm Hg). | |
| REFP02 | Ilman kokonaispaine SVO:n ilmanottoaukon suulla lennon aikana on 754 - 1200 hPa (566 - 1050 mm Hg). | |
| RSGT01 | Jäähdytysilman lämpötila: pysäköitynä enintään 27 ºС | |
| RSGT02 | Jäähdytysilman lämpötila: parkkipaikalla, teknisille yksiköille enintään 29 ºС | |
| RSFT01 | Jäähdytysilman lämpötila lennon aikana enintään 25 ºС | |
| RSFT02 | Jäähdytysilman lämpötila: lennon aikana, teknisille yksiköille enintään 27 ºС | |
| RSGG01 | Jäähdytysilmavirta: pysäköitynä vähintään 708 kg/h | |
| RSFG01 | Jäähdytysilmavirta: lennolla vähintään 660 kg/h | |
| RS0T01 | Ilman lämpötila instrumenttiosastoissa enintään 60 ºС | |
| RSH01 | Hienojakoisen vapaan kosteuden määrä jäähdytysilmassa on enintään 2 g/kg kuivaa ilmaa |
Vaatimukset todentamisjärjestelmän suunnittelu.
Jokaista suunnitteluvaatimusta varten on algoritmi, jolla arvioidaan suunnitteluparametrien ja vaatimuksessa määriteltyjen parametrien vastaavuus. Yleisesti ottaen kaikki ohjausjärjestelmät sisältävät aina oletusarvoisesti algoritmeja vaatimusten tarkistamiseksi. Ja jopa mikä tahansa säädin sisältää niitä. Jos lämpötila ylittää rajojen, ilmastointilaite kytkeytyy päälle. Näin ollen jokaisen sääntelyn ensimmäinen vaihe on tarkistaa, täyttävätkö parametrit vaatimukset.
Ja koska varmennus on algoritmi, voimme käyttää samoja työkaluja ja työkaluja, joita käytämme ohjausohjelmien luomiseen. Esimerkiksi SimInTech-ympäristössä voit luoda projektipaketteja, jotka sisältävät mallin eri osia, jotka suoritetaan erillisinä projekteina (objektimalli, ohjausjärjestelmämalli, ympäristömalli jne.).
Vaatimusvarmennusprojektista tulee tässä tapauksessa sama algoritmiprojekti ja se liitetään mallipakettiin. Ja dynaamisessa mallinnustilassa se suorittaa analyysin teknisten eritelmien vaatimusten noudattamisesta.
Mahdollinen esimerkki järjestelmäsuunnittelusta on esitetty kuvassa 1.
Kuva 1. Esimerkki varmennusprojektin suunnittelusta.
Kuten ohjausalgoritmille, vaatimukset voidaan laatia taulukkona. Algoritmien kanssa työskentelyn helpottamiseksi rakennemallinnusympäristöissä, kuten SimInTech, Simulink, AmeSim, käytetään kykyä luoda monitasoisia rakenteita alimallien muodossa. Tämä organisaatio mahdollistaa erilaisten vaatimusten ryhmittelyn ryhmiksi työn yksinkertaistamiseksi useilla vaatimuksilla, kuten ohjausalgoritmeille tehdään (katso kuva 2).
Kuva 2. Vaatimusvarmennusmallin hierarkkinen rakenne.
Esimerkiksi tarkasteltavana olevassa tapauksessa erotetaan kaksi ryhmää: vaatimukset ympäristölle ja vaatimukset suoraan järjestelmälle. Siksi käytetään kaksitasoista tietorakennetta: kaksi ryhmää, joista jokainen on algoritmin lehti.
Tiedon yhdistämiseksi malliin käytetään standardimallia signaalitietokannan generoimiseksi, joka tallentaa dataa projektin osien välistä vaihtoa varten.
Ohjelmistoa luotaessa ja testattaessa ohjausjärjestelmän käyttämien antureiden (todellisten järjestelmäantureiden analogien) lukemat sijoitetaan tähän tietokantaan.
Testiprojektissa mitkä tahansa dynaamisessa mallissa lasketut parametrit voidaan tallentaa samaan tietokantaan ja siten tarkistaa, täyttyvätkö vaatimukset.
Tässä tapauksessa itse dynaaminen malli voidaan suorittaa missä tahansa matemaattisessa mallinnusjärjestelmässä tai jopa suoritettavan ohjelman muodossa. Ainoa vaatimus on ohjelmistorajapintojen olemassaolo mallinnustietojen lähettämiseksi ulkoiseen ympäristöön.
Kuva 3. Varmennusprojektin yhdistäminen monimutkaiseen malliin.
Esimerkki perusvaatimusten varmistuslomakkeesta on esitetty kuvassa 4. Kehittäjän näkökulmasta kyseessä on tavanomainen laskentakaavio, jossa vaatimusten varmistusalgoritmi esitetään graafisesti.
Kuva 4. Vaatimusten tarkistuslomake.
Tarkastuslomakkeen pääosat on kuvattu kuvassa 5. Tarkistusalgoritmi muodostetaan samalla tavalla kuin ohjausalgoritmien suunnittelukaaviot. Oikealla puolella on lohko signaalien lukemista varten tietokannasta. Tämä lohko käyttää signaalitietokantaa simuloinnin aikana.
Vastaanotetut signaalit analysoidaan vaatimusten varmistusehtojen laskemiseksi. Tässä tapauksessa suoritetaan korkeusanalyysi lentokoneen sijainnin määrittämiseksi (onko se pysäköity vai lennossa). Tätä tarkoitusta varten voit käyttää muita signaaleja ja mallin laskettuja parametreja.
Tarkastettavat varmennusehdot ja parametrit siirretään vakiovarmennuslohkoihin, joissa nämä parametrit analysoidaan määriteltyjen vaatimusten mukaisiksi. Tulokset tallennetaan signaalitietokantaan siten, että niistä voidaan muodostaa automaattisesti tarkistuslista.
Kuva 5. Vaatimusvarmennuslaskelman rakenne.
Testattavat parametrit eivät välttämättä käytä tietokannan sisältämiä signaaleja, joita ohjataan simulaatioprosessin aikana lasketuilla parametreilla. Mikään ei estä meitä suorittamasta lisälaskelmia luonnosvaatimusten puitteissa, aivan kuten laskemme todentamisehdot.
Esimerkiksi tämä vaatimus:
Korjausjärjestelmän aktivointien määrä lennon aikana kohteeseen ei saa ylittää 5 kertaa ja korjausjärjestelmän kokonaistoimintaaika ei saa ylittää 30 sekuntia.
Tällöin vaatimusten suunnittelukaavioon lisätään algoritmi käynnistysten määrän ja kokonaiskäyttöajan laskemiseksi.
Tyypillisten vaatimusten tarkistuslohko.
Jokainen vakiovaatimusvalintaruutu on suunniteltu laskemaan tietyn tyyppisen vaatimuksen täyttyminen. Esimerkiksi ympäristövaatimukset sisältävät erilaisia ympäristön käyttölämpötiloja pysäköitynä ja lennon aikana. Tämän lohkon on vastaanotettava mallin ilman lämpötila parametrina ja määritettävä, kattaako tämä parametri määritellyn lämpötila-alueen./p>
Lohko sisältää kaksi tuloporttia, param ja condition.
Ensimmäiseen syötetään tarkistettava parametri. Tässä tapauksessa "Ulkoinen lämpötila".
Boolen muuttuja syötetään toiseen porttiin - ehto tarkistuksen suorittamiselle.
Jos toisessa sisääntulossa vastaanotetaan TOSI (1), lohko suorittaa vaatimuksen varmennuslaskelman.
Jos toinen tulo vastaanottaa EPÄTOSI (0), testiehdot eivät täyty. Tämä on tarpeen, jotta laskentaehdot voidaan ottaa huomioon. Meidän tapauksessamme tätä syötettä käytetään tarkastuksen ottamiseksi käyttöön tai poistamiseksi käytöstä mallin tilasta riippuen. Jos lentokone on simulaation aikana maassa, niin lentoon liittyviä vaatimuksia ei tarkasteta, ja päinvastoin - jos kone on lennossa, seisontatoimintaa koskevia vaatimuksia ei tarkasteta.
Tätä syöttöä voidaan käyttää myös mallia määritettäessä, esimerkiksi laskennan alkuvaiheessa. Kun malli saatetaan vaadittuun tilaan, tarkistuslohkot poistetaan käytöstä, mutta heti kun järjestelmä saavuttaa vaaditun toimintatilan, tarkistuslohkot kytketään päälle.
Tämän lohkon parametrit ovat:
- rajaehdot: ylä- (UpLimit) ja ala- (DownLimit) -alueen rajat, jotka on tarkistettava;
- vaadittu järjestelmän valotusaika raja-alueilla (TimeInterval) sekunneissa;
- Pyynnön tunnus ReqName;
- alueen ylityksen sallittavuus Out_range on Boolen muuttuja, joka määrittää, onko tarkistetun alueen ylittävä arvo vaatimuksen vastainen.
Joissakin tapauksissa testiarvon ulostulo osoittaa, että järjestelmässä on marginaalia ja se saattaa toimia toiminta-alueensa ulkopuolella. Muissa tapauksissa lähtö tarkoittaa, että järjestelmä ei pysty pitämään asetusarvoja alueella.
Kuva 6. Tyypillinen ominaisuustarkistuslohko kaaviossa ja sen parametrit.
Tämän lohkon laskennan tuloksena lähtöön muodostetaan Result-muuttuja, joka saa seuraavat arvot:
- 0 – rEi mitään, arvoa ei ole määritelty;
- 1 – rValmis, vaatimus täyttyy;
- 2 – rVika, vaatimus ei täyty.
Lohkokuva sisältää:
- tunnisteteksti;
- mittausrajojen parametrien digitaaliset näytöt;
- parametrin tilan väritunniste.
Lohkon sisällä voi olla melko monimutkainen looginen päättelypiiri.
Esimerkiksi kuvassa 6 esitetyn yksikön käyttölämpötila-alueen tarkistamiseksi sisäinen piiri on esitetty kuvassa 7.
Kuva 7. Lämpötila-alueen määritysyksikön sisäinen kaavio.
Piirilohkon sisällä käytetään lohkoparametreissa määritettyjä ominaisuuksia.
Lohkon sisäinen kaavio sisältää vaatimustenmukaisuuden analysoinnin lisäksi simulaatiotulosten näyttämiseen tarvittavan graafin. Tätä kuvaajaa voidaan käyttää sekä katseluun laskennan aikana että tulosten analysointiin laskennan jälkeen.
Laskentatulokset välitetään lohkon lähtöön ja kirjataan samanaikaisesti yleisraporttitiedostoon, joka luodaan tulosten perusteella koko projektille. (katso kuva 8)
Esimerkki simulaation tulosten perusteella luodusta raportista on tietyn muodon mukaan luotu html-tiedosto. Muoto voidaan määrittää mielivaltaisesti tietyn organisaation hyväksymään muotoon.
Piirilohkon sisällä käytetään lohkoparametreissa määritettyjä ominaisuuksia.
Lohkon sisäinen kaavio sisältää vaatimustenmukaisuuden analysoinnin lisäksi simulaatiotulosten näyttämiseen tarvittavan graafin. Tätä kuvaajaa voidaan käyttää sekä katseluun laskennan aikana että tulosten analysointiin laskennan jälkeen.
Laskentatulokset välitetään lohkon lähtöön ja kirjataan samanaikaisesti yleisraporttitiedostoon, joka luodaan tulosten perusteella koko projektille. (katso kuva 8)
Esimerkki simulaation tulosten perusteella luodusta raportista on tietyn muodon mukaan luotu html-tiedosto. Muoto voidaan määrittää mielivaltaisesti tietyn organisaation hyväksymään muotoon.
Kuva 8. Esimerkki simulaatiotuloksiin perustuvasta raporttitiedostosta.
Tässä esimerkissä raporttilomake konfiguroidaan suoraan projektin ominaisuuksissa, ja taulukon muoto on asetettu globaaleiksi projektisignaaleiksi. Tässä tapauksessa SimInTech itse ratkaisee raportin asettamisen ongelman, ja tulosten tiedostoon kirjoittamisen lohko käyttää näitä rivejä kirjoittaakseen raporttitiedostoon.
Kuva 9. Raportin muodon asettaminen globaaleissa projektisignaaleissa
Signaalitietokannan käyttäminen vaatimuksiin.
Ominaisuusasetusten työskentelyn automatisoimiseksi signaalitietokantaan luodaan standardirakenne jokaiselle tyypilliselle lohkolle. (katso kuva 10)
Kuva 10. Esimerkki vaatimustarkistuslohkon rakenteesta signaalitietokannassa.
Signaalitietokanta tarjoaa:
- Tallentaa kaikki tarvittavat järjestelmävaatimusparametrit.
- Kätevä nykyisten projektivaatimusten tarkastelu määritetyistä parametreista ja nykyisistä mallinnustuloksista.
- Yhden lohkon tai lohkoryhmän asettaminen komentosarjaohjelmointikielellä. Muutokset signaalitietokannassa johtavat muutoksiin kaavion lohkoominaisuuksien arvoissa.
- Tekstikuvausten, linkkien teknisiin eritelmiin tai tunnisteiden tallentaminen vaatimustenhallintajärjestelmään.
Vaatimusten signaalitietokantarakenteet voidaan helposti konfiguroida toimimaan kolmannen osapuolen vaatimustenhallintajärjestelmän kanssa.Yleinen kaavio vuorovaikutuksesta vaatimustenhallintajärjestelmien kanssa on esitetty kuvassa 11.
Kuva 11. Kaavio vuorovaikutuksesta vaatimustenhallintajärjestelmän kanssa.
SimInTech-testiprojektin ja vaatimustenhallintajärjestelmän välinen vuorovaikutusjärjestys on seuraava:
- Tehtäväehdot on jaettu vaatimuksiin.
- Teknisten eritelmien vaatimukset tunnistetaan, jotka voidaan todentaa teknisten prosessien matemaattisella mallintamalla.
- Valittujen vaatimusten attribuutit siirretään SimInTech-signaalitietokantaan standardilohkojen rakenteessa (esim. maksimi- ja minimilämpötila).
- Laskentaprosessin aikana rakennetiedot siirretään lohkosuunnittelukaavioihin, analysoidaan ja tulokset tallennetaan signaalitietokantaan.
- Kun laskelma on valmis, analyysitulokset siirretään vaatimustenhallintajärjestelmään.
Vaatimusvaiheet 3–5 voidaan toistaa suunnitteluprosessin aikana, kun suunnitteluun ja/tai vaatimuksiin tapahtuu muutoksia ja muutosten vaikutus on testattava uudelleen.
Johtopäätökset.
- Järjestelmän luotu prototyyppi lyhentää merkittävästi olemassa olevien mallien analysointiaikaa teknisten eritelmien vaatimusten täyttämiseksi.
- Ehdotettu testaustekniikka käyttää jo olemassa olevia dynaamisia malleja ja sitä voidaan käyttää jopa kaikissa dynaamisissa malleissa, myös sellaisissa, joita ei suoriteta SimInTech-ympäristössä.
- Erätiedon organisoinnin avulla voit luoda vaatimusten varmistuspaketteja rinnakkain mallikehityksen kanssa tai jopa käyttää näitä paketteja mallikehityksen teknisinä eritelminä.
- Tekniikka voidaan integroida olemassa oleviin vaatimustenhallintajärjestelmiin ilman merkittäviä kustannuksia.
Niille, jotka lukevat loppuun,
Lähde: will.com