Fortsætter temaet , lad os se på problemet med matematisk modellering fra den anden side. Efter at vi er overbevist om, at modellen svarer til livets hjemmespundne sandhed, kan vi besvare hovedspørgsmålet: "Hvad præcist har vi her?" Når vi laver en model af et teknisk objekt, ønsker vi normalt at sikre os, at dette objekt lever op til vores forventninger. Til dette formål udføres dynamiske beregninger af processer, og resultatet sammenlignes med kravene. Dette er en digital tvilling, en virtuel prototype osv. moderigtige små fyre, der på designstadiet løser problemet med, hvordan vi sikrer, at vi får det, vi har planlagt.
Hvordan kan vi hurtigt sikre os, at vores system er præcis det, vi designer, vil vores design flyve eller flyde? Og hvis den flyver, hvor højt? Og hvis det flyder, hvor dybt?
Denne artikel diskuterer automatisering af verifikation af overholdelse af kravene til en teknisk bygning ved oprettelse af dynamiske modeller af tekniske systemer. Lad os som et eksempel se på et element i den tekniske specifikation for et luftkølesystem til et fly.
Vi overvejer de krav, der kan udtrykkes numerisk og verificeres matematisk ud fra en specifik beregningsmodel. Det er klart, at dette kun er en del af de generelle krav til ethvert teknisk system, men det er på at kontrollere dem, at vi bruger tid, nerver og penge på at skabe dynamiske modeller af objektet.
Ved beskrivelse af tekniske krav i form af et dokument kan der skelnes mellem flere typer af forskellige krav, som hver især kræver forskellige tilgange til dannelse af automatisk verifikation af kravopfyldelse.
Overvej for eksempel dette lille, men realistiske sæt krav:
- Atmosfærisk lufttemperatur ved indgangen til vandbehandlingssystemet:
på parkeringspladsen - fra minus 35 til 35 ºС,
under flyvning - fra minus 35 til 39 ºС. - Det statiske tryk af atmosfærisk luft under flyvning er fra 700 til 1013 GPa (fra 526 til 760 mm Hg).
- Det samlede lufttryk ved indgangen til SVO-luftindtaget under flyvning er fra 754 til 1200 GPa (fra 566 til 1050 mm Hg).
- Kølelufttemperatur:
på parkeringspladsen - ikke mere end 27 ºС, for tekniske blokke - ikke mere end 29 ºС,
under flyvning - ikke mere end 25 ºС, for tekniske blokke - ikke mere end 27 ºС. - Køleluftstrøm:
ved parkering - mindst 708 kg/t,
under flyvning - ikke mindre end 660 kg/t. - Lufttemperaturen i instrumentrummene er ikke mere end 60 ºС.
- Mængden af fin fri fugt i køleluften er ikke mere end 2 g/kg tør luft.
Selv inden for dette begrænsede sæt af krav er der mindst to kategorier, der skal håndteres forskelligt i systemet:
- krav til systemets driftsbetingelser (klausul 1-3);
- parametriske krav til systemet (punkt 3-7).
Krav til systemdriftsbetingelser
Eksterne forhold for det system, der udvikles under modellering, kan angives som randbetingelser eller som følge af driften af det generelle system.
Ved dynamisk simulering er det nødvendigt at sikre, at de angivne driftsbetingelser er omfattet af simuleringsprocessen.
Parametriske systemkrav
Disse krav er parametre leveret af systemet selv. Under modelleringsprocessen kan vi få disse parametre som beregningsresultater og sikre, at kravene er opfyldt i hver specifik beregning.
Krav identifikation og kodning
For at lette arbejdet med krav anbefaler eksisterende standarder at tildele en identifikator til hvert krav. Ved tildeling af identifikatorer er det yderst ønskeligt at bruge et samlet kodningssystem.
En kravkode kan blot være et tal, der repræsenterer ordrenummeret på kravet, eller den kan indeholde en kode for kravtypen, en kode for det system eller den enhed, den gælder for, en parameterkode, en lokationskode og alt andet, en ingeniør kan forestille sig. (se artiklen for brug af kodning)
Tabel 1 giver et simpelt eksempel på kravkodning.
- kode for kravkilden R-krav TK;
- kode type krav E - krav - miljøparametre eller driftsforhold
S - krav stillet af systemet; - luftfartøjets statuskode 0 – enhver, G – parkeret, F – under flyvning;
- fysisk parametertypekode T – temperatur, P – tryk, G – flowhastighed, fugtighed H;
- serienummeret på kravet.
| ID Krav |
beskrivelse | Parameter |
| REGT01 | Omgivende lufttemperatur ved indgangen til vandkølesystemet: på parkeringspladsen - fra minus 35ºС. op til 35 ºС. | |
| REFT01 | Atmosfærisk lufttemperatur ved indgangen til luftforsvarssystemet: under flyvning - fra minus 35 ºС til 39 ºС. | |
| REFP01 | Statisk atmosfærisk lufttryk under flyvning er fra 700 til 1013 hPa (fra 526 til 760 mm Hg). | |
| REFP02 | Det samlede lufttryk ved indgangen til SVO-luftindtaget under flyvning er fra 754 til 1200 hPa (fra 566 til 1050 mm Hg). | |
| RSGT01 | Kølelufttemperatur: når den er parkeret højst 27 ºС | |
| RSGT02 | Kølelufttemperatur: på parkeringspladsen, for tekniske enheder ikke mere end 29 ºС | |
| RSFT01 | Kølelufttemperatur under flyvning ikke mere end 25 ºС | |
| RSFT02 | Kølelufttemperatur: under flyvning, for tekniske enheder ikke mere end 27 ºС | |
| RSGG01 | Køleluftstrøm: ved parkering ikke mindre end 708 kg/t | |
| RSFG01 | Køleluftstrøm: under flyvning ikke mindre end 660 kg/t | |
| RS0T01 | Lufttemperatur i instrumentrum ikke mere end 60 ºС | |
| RSH01 | Mængden af fin fri fugt i køleluften er ikke mere end 2 g/kg tør luft |
Krav verifikationssystem design.
For hvert designkrav er der en algoritme til at vurdere overensstemmelsen mellem designparametrene og de parametre, der er specificeret i kravet. I det store og hele indeholder ethvert kontrolsystem altid algoritmer til kontrol af krav som standard. Og selv enhver regulator indeholder dem. Hvis temperaturen går uden for grænserne, tænder klimaanlægget. Den første fase af enhver regulering er således at kontrollere, om parametrene opfylder kravene.
Og da verifikation er en algoritme, så kan vi bruge de samme værktøjer og værktøjer, som vi bruger til at lave kontrolprogrammer. For eksempel giver SimInTech-miljøet dig mulighed for at oprette projektpakker, der indeholder forskellige dele af modellen, udført i form af separate projekter (objektmodel, styresystemmodel, miljømodel osv.).
Kravverifikationsprojektet bliver i dette tilfælde det samme algoritmeprojekt og er forbundet med modelpakken. Og i den dynamiske modelleringstilstand udfører den en analyse for overholdelse af kravene i de tekniske specifikationer.
Et muligt eksempel på et systemdesign er vist i figur 1.
Figur 1. Eksempel på design af et verifikationsprojekt.
Ligesom for kontrolalgoritmer kan krav opstilles som et sæt ark. For at gøre det nemmere at arbejde med algoritmer i strukturelle modelleringsmiljøer som SimInTech, Simulink, AmeSim, bruges muligheden for at skabe multi-level strukturer i form af submodeller. Denne organisation gør det muligt at gruppere forskellige krav i sæt for at forenkle arbejdet med en række krav, som det gøres for kontrolalgoritmer (se fig. 2).
Figur 2. Hierarkisk struktur af kravverifikationsmodellen.
For eksempel skelnes der i den foreliggende sag mellem to grupper: krav til miljøet og krav direkte til systemet. Derfor bruges en datastruktur på to niveauer: to grupper, som hver er et blad af algoritmen.
For at koble data til modellen anvendes et standardskema til generering af en signaldatabase, som gemmer data til udveksling mellem dele af projektet.
Ved oprettelse og test af software placeres aflæsningerne af sensorer (analoger af rigtige systemsensorer), som bruges af kontrolsystemet, i denne database.
Til et testprojekt kan eventuelle parametre beregnet i den dynamiske model gemmes i samme database og dermed bruges til at kontrollere, om kravene er opfyldt.
I dette tilfælde kan selve den dynamiske model udføres i et hvilket som helst matematisk modelleringssystem eller endda i form af et eksekverbart program. Det eneste krav er tilstedeværelsen af softwaregrænseflader til at udstede modelleringsdata til det eksterne miljø.
Figur 3. Forbindelse af verifikationsprojektet til den komplekse model.
Et eksempel på et basiskravverifikationsark er præsenteret i figur 4. Fra udviklerens synspunkt er det et konventionelt beregningsdiagram, hvorpå kravverifikationsalgoritmen er præsenteret grafisk.
Figur 4. Kravkontrolark.
Hoveddelene af kontrolarket er beskrevet i figur 5. Kontrolalgoritmen er dannet på samme måde som designdiagrammerne for kontrolalgoritmer. På højre side er der en blok til aflæsning af signaler fra databasen. Denne blok får adgang til signaldatabasen under simulering.
De modtagne signaler analyseres for at beregne kravverifikationsbetingelser. I dette tilfælde udføres højdeanalyse for at bestemme flyets position (om det er parkeret eller under flyvning). Til dette formål kan du bruge andre signaler og beregnede parametre i modellen.
De verifikationsbetingelser og parametre, der kontrolleres, overføres til standard verifikationsblokke, hvor disse parametre analyseres for overholdelse af de specificerede krav. Resultaterne registreres i signaldatabasen på en sådan måde, at de kan bruges til automatisk at generere en tjekliste.
Figur 5. Opbygning af kravverifikationsberegningsarket.
De parametre, der skal testes, bruger ikke nødvendigvis signaler indeholdt i databasen, som styres af parametre, der beregnes under simuleringsprocessen. Intet forhindrer os i at foretage yderligere beregninger inden for rammerne af kravudkastet, ligesom vi beregner verifikationsbetingelserne.
For eksempel dette krav:
Antallet af aktiveringer af korrektionssystemet under flyvningen til målet bør ikke overstige 5, og korrektionssystemets samlede driftstid bør ikke overstige 30 sekunder.
I dette tilfælde tilføjes en algoritme til imødegåelse af antallet af starter og samlet driftstid til designdiagrammet for kravene.
Typiske krav verifikationsblok.
Hvert afkrydsningsfelt for standardkrav er designet til at beregne opfyldelsen af et krav af en bestemt type. For eksempel omfatter miljøkravene en række omgivende driftstemperaturer, når de er parkeret og under flyvning. Denne blok skal modtage lufttemperaturen i modellen som en parameter og bestemme, om denne parameter dækker det angivne temperaturområde./p>
Blokken indeholder to inputporte, param og condition.
Den første fodres med den parameter, der kontrolleres. I dette tilfælde "Ekstern temperatur".
En boolsk variabel leveres til den anden port - betingelsen for at udføre kontrollen.
Hvis SAND (1) modtages ved den anden indgang, udfører blokken en kravverifikationsberegning.
Hvis den anden indgang modtager FALSK (0), er testbetingelserne ikke opfyldt. Dette er nødvendigt, for at der kan tages hensyn til beregningsbetingelserne. I vores tilfælde bruges dette input til at aktivere eller deaktivere kontrollen afhængigt af modellens tilstand. Hvis flyet er på jorden under simuleringen, så kontrolleres kravene vedrørende flyvning ikke, og omvendt - hvis flyet er under flyvning, så kontrolleres kravene vedrørende drift på standplads ikke.
Dette input kan også bruges ved opsætning af modellen, for eksempel i den indledende fase af beregningen. Når modellen bringes i den ønskede tilstand, deaktiveres kontrolblokkene, men så snart systemet når den påkrævede driftstilstand, tændes kontrolblokkene.
Parametrene for denne blok er:
- grænsebetingelser: øvre (UpLimit) og nedre (DownLimit) områdegrænser, der skal kontrolleres;
- påkrævet systemeksponeringstid ved grænseområderne (TimeInterval) i sekunder;
- Request ID ReqName;
- tilladt at overskride området Out_range er en boolsk variabel, der bestemmer, om en værdi, der overskrider det afkrydsede område, er en overtrædelse af kravet.
I nogle tilfælde indikerer testværdioutputtet, at systemet har en vis margin og muligvis arbejder uden for dets driftsområde. I andre tilfælde betyder en udgang, at systemet ikke er i stand til at holde sætpunkterne inden for rækkevidde.
Figur 6. En typisk egenskabskontrolblok i diagrammet og dets parametre.
Som et resultat af beregningen af denne blok dannes resultatvariablen ved udgangen, som tager følgende værdier:
- 0 – rIngen, værdi ikke defineret;
- 1 – Udført, kravet er opfyldt;
- 2 – rFejl, kravet er ikke opfyldt.
Blokbilledet indeholder:
- identifikationstekst;
- digitale visninger af målegrænseparametre;
- farveidentifikator for parameterstatus.
Inde i blokken kan der være et ret komplekst logisk inferenskredsløb.
For at kontrollere driftstemperaturområdet for enheden vist i figur 6, er det interne kredsløb vist i figur 7.
Figur 7. Internt diagram af temperaturområdebestemmelsesenheden.
Inde i kredsløbsblokken anvendes de egenskaber, der er specificeret i blokparametrene.
Ud over at analysere overholdelse af krav indeholder det interne diagram af blokken en graf, der er nødvendig for at vise simuleringsresultaterne. Denne graf kan bruges både til visning under beregning og til at analysere resultaterne efter beregning.
Beregningsresultaterne overføres til blokkens output og registreres samtidigt i en generel rapportfil, som oprettes på baggrund af resultaterne for hele projektet. (se fig. 8)
Et eksempel på en rapport, der er oprettet baseret på simuleringsresultaterne, er en html-fil, der er oprettet i henhold til et givet format. Formatet kan vilkårligt konfigureres til det format, der accepteres af en bestemt organisation.
Inde i kredsløbsblokken anvendes de egenskaber, der er specificeret i blokparametrene.
Ud over at analysere overholdelse af krav indeholder det interne diagram af blokken en graf, der er nødvendig for at vise simuleringsresultaterne. Denne graf kan bruges både til visning under beregning og til at analysere resultaterne efter beregning.
Beregningsresultaterne overføres til blokkens output og registreres samtidigt i en generel rapportfil, som oprettes på baggrund af resultaterne for hele projektet. (se fig. 8)
Et eksempel på en rapport, der er oprettet baseret på simuleringsresultaterne, er en html-fil, der er oprettet i henhold til et givet format. Formatet kan vilkårligt konfigureres til det format, der accepteres af en bestemt organisation.
Figur 8. Eksempel på en rapportfil baseret på simuleringsresultater.
I dette eksempel er rapportformularen konfigureret direkte i projektegenskaberne, og formatet i tabellen er angivet som globale projektsignaler. I dette tilfælde løser SimInTech selv problemet med at opsætte rapporten, og blokken til at skrive resultater til en fil bruger disse linjer til at skrive til rapportfilen.
Figur 9. Indstilling af rapportformatet i globale projektsignaler
Brug af en signaldatabase til krav.
For at automatisere arbejdet med egenskabsindstillinger oprettes en standardstruktur i signaldatabasen for hver typisk blok. (se fig. 10)
Figur 10. Eksempel på strukturen af en kravkontrolblok i en signaldatabase.
Signaldatabase giver:
- Lagring af alle nødvendige systemkravparametre.
- Praktisk visning af eksisterende projektkrav fra specificerede parametre og aktuelle modelleringsresultater.
- Opsætning af en blok eller en gruppe af blokke ved hjælp af et scripting programmeringssprog. Ændringer i signaldatabasen fører til ændringer i blokegenskabsværdierne i diagrammet.
- Lagring af tekstbeskrivelser, links til tekniske specifikationer eller identifikatorer i kravstyringssystemet.
Signaldatabasestrukturer for krav kan nemt konfigureres til at fungere med et tredjeparts kravstyringssystem. Et generelt diagram over interaktion med kravstyringssystemer er vist i figur 11.
Figur 11. Diagram over interaktion med kravstyringssystemet.
Sekvensen af interaktion mellem SimInTech-testprojektet og kravstyringssystemet er som følger:
- Kommissoriet er opdelt i krav.
- Kravene til de tekniske specifikationer er identificeret, som kan verificeres ved matematisk modellering af tekniske processer.
- Attributter for de valgte krav overføres til SimInTech-signaldatabasen i strukturen af standardblokke (for eksempel maksimum- og minimumtemperatur).
- Under beregningsprocessen overføres strukturdata til blokdesigndiagrammer, analyse udføres og resultaterne gemmes i en signaldatabase.
- Når beregningen er afsluttet, overføres analyseresultaterne til kravstyringssystemet.
Kravtrin 3 til 5 kan gentages under designprocessen, når der sker ændringer i designet og/eller kravene, og virkningen af ændringerne skal testes igen.
Konklusioner.
- Den oprettede prototype af systemet giver en betydelig reduktion i analysetiden af eksisterende modeller for overholdelse af kravene i de tekniske specifikationer.
- Den foreslåede testteknologi bruger allerede eksisterende dynamiske modeller og kan bruges selv til alle dynamiske modeller, inklusive dem, der ikke udføres i SimInTech-miljøet.
- Ved at bruge batchdataorganisering kan du oprette kravverifikationspakker parallelt med modeludvikling, eller endda bruge disse pakker som tekniske specifikationer til modeludvikling.
- Teknologien kan integreres med eksisterende kravstyringssystemer uden væsentlige omkostninger.
For dem, der læser til ende,
Kilde: www.habr.com