Automatisk kontrol af krav i teknisk specifikation under dynamisk modelleringsproces

Fortsætter emnet "Hvad er dine beviser?", lad os se på problemet med matematisk modellering fra en anden vinkel. Efter vi har sikret os, at modellen svarer til den nøgne livsand, kan vi besvare det centrale spørgsmål: "Hvad har vi her egentlig?" Når vi skaber en model af et teknisk objekt, vil vi som regel sikre os, at dette objekt vil leve op til vores forventninger. Derfor udføres der dynamiske beregninger af processerne, og resultatet sammenlignes med kravene. Det er her, den digitale tvilling, den virtuelle prototype og andre trends kommer ind, der i designfasen løser opgaven med, hvordan vi får det, vi har planlagt.

Hvordan kan vi hurtigt sikre, at vores system er det, vi designer, om det flyver eller svømmer, vores konstruktion? Og hvis det flyver, hvor højt? Og hvis det svømmer, hvor dybt?

Denne artikel handler om automatisering af kontrol over opfyldelsen af tekniske bygningers krav ved oprettelse af dynamiske modeller af tekniske systemer. Som eksempel vil vi se på et element af teknisk specifikation for et luftkølesystem til luftfartøjer.

Vi ser på de krav, der kan udtrykkes numerisk og kontrolleres matematisk baseret på en konkret beregningsmodel. Det er klart, at dette kun er en del af de overordnede krav til ethvert teknisk system, men det er netop på deres kontrol, vi bruger tid, nerve og penge på at skabe dynamiske modeller af objektet.

Ved beskrivelse af tekniske krav i form af et dokument kan man skelne mellem flere typer forskellige krav, hvor hver kræver forskellige tilgange til oprettelse af automatisk kontrol over opfyldelsen af kravene.

Lad os eksempelvis se på et lille, men reelt sæt krav:

1. Temperaturen af den omgivende luft ved indgangen til SVO:
   ved parkering − fra minus 35 til 35 ºC,
   under flyvning − fra minus 35 til 39 ºC.
2. Det statiske tryk af den omgivende luft under flyvning − fra 700 til 1013 GPa (fra 526 til 760 mmHg).
3. Det samlede tryk af luften ved indgangen til luftindtaget til SVO under flyvning − fra 754 til 1200 GPa (fra 566 til 1050 mmHg).
4. Temperaturen af kølelufte:
   på parkeringspladsen - højst 27 ºC, for tekniske blokke - højst 29 ºC,
   i luften - højest 25 ºC, for tekniske blokke - højest 27 ºC.
5. Forbrug af køleluft:
   på parkeringspladsen - mindst 708 kg/t,
   i luften - mindst 660 kg/t.
6. Lufttemperaturen i instrumentrummene - højst 60 ºC.
7. Mængden af fint dispergeret frit fugt i køleluften - højst 2 g/kg tør luft.

Selv i et så begrænset sæt krav kan der skelnes mellem mindst to kategorier, som skal behandles forskelligt i systemet:

• krav til driftforholdene for systemet (pkt. 1-3);
• parameterkrav til systemet (pkt. 3-7).

Krav til driftforholdene for systemet
De ydre forhold for det udviklede system under modellering kan angives som grænseforhold, eller som et resultat af det samlede systems arbejde.
Ved dynamisk modellering skal det sikres, at de angivne driftsformer dækkes af modelleringsprocessen.

Parameterkrav til systemet
Disse krav repræsenterer de parametre, der leveres af selve systemet. Under modelleringen kan vi få disse parametre som resultater af beregningen og sikre, at kravene er opfyldt i hver specifik beregning.

Identifikation og kodning af krav

For at lette arbejdet med kravene anbefaler eksisterende standarder at tildele en identifikator til hvert krav. Det er meget ønskeligt at anvende et ensartet kodningssystem.

Kravenummeret kan blot være et tal, der afspejler rækkefølgen af kravet, eller det kan indeholde en type kravkode, system- eller enhedskode, til hvilken det gælder, parameterkode, placeringkode og meget mere, som ingeniøren kan forestille sig. (se brugen af kodning i artiklen)

Tabel 1 viser et simpelt eksempel på kravkodning.

1. kildekode for krav R- krav til specifikation;
2. typekode for krav E - krav - parametre for det ydre miljø eller driftsforhold
   S - krav leveret af systemet;
3. flyets tilstandskode 0 - enhver, G - på jorden, F - i luften;
4. kode for fysiske parameter typer T - temperatur, P - tryk, G - flow, luftfugtighed H;
5. rækkefølgenummer for kravet.

Projekt for kravverifikationssystem.

For hver beregnet krav findes der en algoritme til vurdering af overensstemmelse mellem de beregnede parametre og de angivne i kravet. Generelt indeholder ethvert kontrolsystem i sig selv altid algoritmer til kravverifikation som standard. Selv enhver regulerende instans indeholder dem. Hvis temperaturen overskrider grænsen, tændes klimaanlægget. Således er det første skridt i enhver regulering – verificeringen af, at parametrene opfylder kravet.

Og da verificering er en algoritme, kan de samme værktøjer, som vi bruger til at skabe kontrolprogrammer, anvendes. For eksempel gør SimInTech-miljøet det muligt at oprette projektpakker, der indeholder forskellige dele af modellen, udført som separate projekter (objektmodel, kontrolsystemmodel, miljømodel osv.).

Projektet for kravverifikation bliver i dette tilfælde et projekt med algoritmer og tilsluttes modelpakken. I dynamisk modelleringsmode udfører det en analyse af overensstemmelse med kravene i specifikationen.

Et muligt eksempel på præsentation af projektet for systemet er vist i figur 1.

Figur 1. Eksempel på præsentation af kravverifikationsprojektet.

Ligesom for kontrolalgoritmer kan krav også præsenteres i form af et sæt af ark. For at lette arbejdet med algoritmer i strukturelle modelleringsmiljøer som SimInTech, Simulink og AmeSim, benyttes mulighederne for at skabe hierarkiske strukturer i form af submodeller. Denne organisering gør det muligt at gruppere forskellige krav i sæt for at forenkle arbejdet med mængden af krav, ligesom det gøres for kontrolalgoritmer (se fig. 2).

Figur 2. Hierarkisk struktur af kravtestmodel.

For eksempel er der i det betragtede tilfælde identificeret to grupper: krav til miljøet og krav direkte til systemet. Derfor anvendes en to-niveau datastruktur: to grupper, hvor hver gruppe repræsenterer et ark i algoritmen.

Til at forbinde data med modellen anvendes en standard skema til dannelse af signaldatabaser, hvor data opbevares til udveksling mellem projektdelene.

Når software skabes og tjekkes, placeres sensoraflæsninger (tilsvarende reelle sensorsystemer) i denne database, som anvendes af kontrolsystemet.
For testprojektet kan alle parametre, der beregnes i den dynamiske model, også gemmes i denne database og dermed bruges til at validere kravene.

Selve den dynamiske model i dette tilfælde kan udføres i ethvert system til matematisk modellering eller endda som et eksekverbart program. Det eneste krav er, at der er programmeringsgrænseflader til at videresende data fra simuleringen til den eksterne omverden.

Figur 3. Forbindelse af kravtestprojekt til den komplekse model.

Et eksempel på et grundlæggende kravtestark vises i figur 4. Set fra udviklerens synspunkt udgør det en almindelig beregningsskema, hvor algoritmen til test af krav præsenteres grafisk.

Figur 4. Kravtestark.

De vigtigste dele af kravtestarket er beskrevet i figur 5. Testalgoritmen dannes på samme måde som beregningsskemaerne for kontrolalgoritmer. I højre side findes blokken til at læse signaler fra databasen. I denne blok tilgås signaldatabasen under simuleringen.

De modtagne signaler analyseres for at beregne betingelserne for at kontrollere kravene. I det foreliggende tilfælde udføres en analyse af højden for at bestemme flyets position (om det er stående eller i flyvning). Andre signaler og beregnede parametre fra modellen kan også anvendes til dette formål.

Betingelserne for kontrollen og de kontrollerede parametre overføres til standardiserede kontrolblokke, hvor analysen af disse parametre udføres for at vurdere overensstemmelse med de fastsatte krav. Resultaterne gemmes i signaldatabasen på en måde, så de kan anvendes til automatisk at generere en tjekliste.

Figur 5. Strukturen af kontrolkravets beregningsark.

Det er ikke nødvendigt at bruge signaler, der er indeholdt i databasen, som kontrollerede parametre, der styres af parametre, der beregnes under modelleringen. Der er intet til hinder for at udføre yderligere beregninger inden for kravprojektet, ligesom vi beregner kontrolbetingelserne.

For eksempel, et sådant krav:

Antallet af aktiveringer af det korrigerende system under flyvningen til målet må ikke overstige 5, og den samlede driftstid for det korrigerende system må ikke overstige 30 sekunder.

I dette tilfælde tilføjes en tællealgoritme for antallet af aktiveringer og den samlede driftstid til beregningsskemaet for kravene.

Standardkontrolblok for krav.

Hver standard kontrolblok for krav er beregnet til at beregne opfyldelsen af et krav af en bestemt type. For eksempel, i kravene til omgivelserne er der et område for de omgivende temperaturer under parkering og flyvning. Denne blok skal modtage lufttemperaturen i modellen som parameter og bestemme, om denne parameter dækker det angivne temperaturinterval.

Blokken indeholder to indgangsporte, param og condition.

Den første modtager den kontrollerede parameter. I dette tilfælde "Temperatur i det omgivende miljø".

Den anden port modtager en boolesk variabel – betingelsen for at udføre kontrollen.

Hvis der på den anden indgang kommer TRUE (1), udfører blokken beregningen for kontrolkravet.

Hvis den anden indgang modtager FALSE (0), så opfyldes kontrolbetingelserne ikke. Dette er nødvendigt, så betingelserne for beregningen kan tages i betragtning. I vores tilfælde anvendes denne indgang til at aktivere eller deaktivere kontrollen afhængigt af modellens tilstand. Hvis flyet under modelleringen er på jorden, så kontrolleres de relevante krav til flyvning ikke, og omvendt - hvis flyet er i luften, så kontrolleres kravene vedrørende parkering ikke.

Denne indgang kan også anvendes under indstillingen af modellen, for eksempel i den indledende beregningsfase. Når modellen bringes i den nødvendige tilstand, er kontrolblokke deaktiveret, men så snart systemet når den krævede driftsmode, aktiveres kontrolblokkene.

Som parametre for denne blok angives:

• grænseforhold: den øverste (UpLimit) og den nederste (DownLimit) grænse for de områder, der skal kontrolleres;
• den krævede ventetid for systemet ved grænseområderne (TimeInterval) i sekunder;
• identifikatoren for kravet ReqName;
• tolerance for overskridelse af området Out_range - en boolesk variabel, der angiver, om det er en overtrædelse af kravet, når værdien overskrider det kontrollerede område.

I nogle tilfælde betyder det at overskride den kontrollerede værdi, at systemet har overskud og kan arbejde uden for det arbejdsområde. I andre tilfælde betyder overskridelse, at systemet ikke er i stand til at opretholde de angivne parametre inden for området.

Figur 6. Typisk kontrolblok for egenskaber i diagrammet og dens parametre.

Som resultat af beregningen af denne blok genereres der en variabel Result, som antager følgende værdier:

• 0 - rNone, værdien er ikke defineret;
• 1 - rDone, kravet er opfyldt;
• 2 - rFault, kravet er ikke opfyldt.

Blokdiagrammet indeholder:

• tekstidentifikatoren;
• digitale visninger af målegrænseparametrene;
• farveidentifikatoren for parameterens tilstand.

Inden i blokken kan der være et ret komplekst logisk ræsonneringsschema.

For eksempel, til kontrol af det arbejdsområde af temperaturerne i blokken, der er vist i figur 6, præsenteres det indre schema i figur 7.

Figur 7. Det indre schema for temperaturintervallet.

Inden i blokdiagrammet anvendes egenskaber defineret i blokparametrene.
Udover analysen af kravoverholdelse indeholder den interne blokdiagram en graf, der er nødvendig for at vise resultaterne af simuleringen. Denne graf kan bruges både til visning under beregningerne og til analyse af resultaterne efter beregningen.

Beregningens resultater overføres til blokken og gemmes samtidig i en samlet rapportfil, der oprettes baseret på resultaterne for hele projektet. (se fig. 8)

Et eksempel på en rapport, der er oprettet på baggrund af simulationsresultaterne, er en html-fil, der er oprettet i det angivne format. Formatet kan tilpasses frit til det format, der er accepteret i den specifikke organisation.

Inden i blokdiagrammet anvendes egenskaber defineret i blokparametrene.
Udover analysen af kravoverholdelse indeholder den interne blokdiagram en graf, der er nødvendig for at vise resultaterne af simuleringen. Denne graf kan bruges både til visning under beregningerne og til analyse af resultaterne efter beregningen.

Beregningens resultater overføres til blokken og gemmes samtidig i en samlet rapportfil, der oprettes baseret på resultaterne for hele projektet. (se fig. 8)

Et eksempel på en rapport, der er oprettet på baggrund af simulationsresultaterne, er en html-fil, der er oprettet i det angivne format. Formatet kan tilpasses frit til det format, der er accepteret i den specifikke organisation.

Figur 8. Eksempel på rapportfil baseret på simulationsresultater.

I dette eksempel udføres indstillingen af rapportens formular direkte i projektets egenskaber, mens formatet i tabellen angives som globale signaler for projektet. I dette tilfælde løser SimInTech selv opgaven med at indstille rapporten, og blokken til optagelse af resultater i filen bruger disse linjer til at skrive til rapportfilen.

Figur 9. Indstilling af rapportformat i projektets globale signaler

Brug af signaldatabasen til krav.

For at automatisere arbejdet med egenskaberne for hver standardblok oprettes en standardstruktur i signaldatabasen. (se fig. 10)

Figur 10. Eksempel på struktur af kravcheckblok i signaldatabasen.

Signaldatabasen sikrer:

• Opbevaring af alle nødvendige parametre for systemkrav.
• Bekvem visning af eksisterende krav i projektet baseret på de angivne parametre og aktuelle simulationsresultater.
• Indstilling af en blok, gruppe af blokke ved hjælp af et scriptsprog. Ændringer i signaldatabasen fører til ændringer i blokens egenskabers værdier i diagrammet.
• Opbevaring af tekstbeskrivelser, links til punkter i kravspecifikationen eller identifikatorer i systemet til kravstyring.

Strukturerne i signaldatabasen for krav kan nemt tilpasses til at arbejde med et tredjepartssystem til kravstyring. Den generelle interaktionsskema med kravstyringssystemer præsenteres i figur 11.

Figur 11. Skema for interaktion med kravstyringssystemet.

Sekvensen for interaktion mellem testprojektet SimInTech og kravstyringssystemet er som følger:

1. Det tekniske dokument opdeles i krav.
2. Der identificeres krav i det tekniske dokument, som kan verificeres gennem matematisk modellering af tekniske processer.
3. Attributterne for de identificerede krav overføres til SimInTechs signaldatabase i strukturer af standardblokke (for eksempel maksimal og minimal temperatur).
4. Under beregningsprocessen overføres data fra strukturerne til beregningsskemaerne for blokkene, analysen udføres, og resultaterne gemmes i signaldatabasen.
5. Ved afslutningen af beregningen overføres analyseresultaterne til kravstyringssystemet.

Trinene i arbejdet med kravene 3 — 5 kan gentages under designprocessen, når der sker ændringer i konstruktionen og/eller kravene, og det derfor er nødvendigt at gentage kontrollen af indflydelsen fra de foretagne ændringer.

Konklusioner.

• Den oprettede prototypesystem sikrer en betydelig reduktion i tiden til at analysere eksisterende modeller for overholdelse af kravene i det tekniske dokument.
• Den foreslåede testteknologi anvender allerede eksisterende dynamiske modeller og kan bruges til enhver dynamisk model, herunder dem, der ikke er udført i SimInTech-miljøet.
• Brugen af batch-databaseorganisering muliggør oprettelse af kontrolpakker for krav parallelt med udviklingen af modellerne, eller endda at bruge disse pakker som tekniske dokumenter til modelludvikling.
• Teknologien kan integreres med eksisterende kravstyringssystemer uden væsentlige omkostninger.

Til dem, der nåede til slutningen, henvisning til videoen med demonstration af prototypearbejdet.

Kilde: habr.com