Fortsetter temaet , la oss se på problemet med matematisk modellering fra den andre siden. Etter at vi er overbevist om at modellen tilsvarer livets hjemmespunnede sannhet, kan vi svare på hovedspørsmålet: "Hva, egentlig, har vi her?" Når vi lager en modell av et teknisk objekt, ønsker vi vanligvis å forsikre oss om at dette objektet vil oppfylle våre forventninger. For dette formålet utføres dynamiske beregninger av prosesser og resultatet sammenlignes med kravene. Dette er en digital tvilling, en virtuell prototype, etc. fasjonable små gutter som på designstadiet løser problemet med hvordan vi skal sørge for at vi får det vi har planlagt.
Hvordan kan vi raskt sørge for at systemet vårt er akkurat det vi designer, vil vårt design fly eller flyte? Og hvis den flyr, hvor høyt? Og hvis den flyter, hvor dypt?
Denne artikkelen diskuterer automatisering av verifisering av samsvar med kravene til en teknisk bygning når du lager dynamiske modeller av tekniske systemer. Som et eksempel, la oss se på et element i den tekniske spesifikasjonen for et luftkjølesystem for et fly.
Vi vurderer de kravene som kan uttrykkes numerisk og verifiseres matematisk basert på en spesifikk beregningsmodell. Det er klart at dette bare er en del av de generelle kravene til ethvert teknisk system, men det er på å sjekke dem at vi bruker tid, nerver og penger på å lage dynamiske modeller av objektet.
Ved beskrivelse av tekniske krav i form av et dokument kan det skilles mellom flere typer ulike krav, som hver krever ulike tilnærminger for dannelse av automatisk verifisering av kravoppfyllelse.
Tenk for eksempel på dette lille, men realistiske settet med krav:
- Atmosfærisk lufttemperatur ved inngangen til vannbehandlingssystemet:
på parkeringsplassen - fra minus 35 til 35 ºС,
under flukt - fra minus 35 til 39 ºС. - Det statiske trykket til atmosfærisk luft under flyging er fra 700 til 1013 GPa (fra 526 til 760 mm Hg).
- Det totale lufttrykket ved inngangen til SVO-luftinntaket under flyging er fra 754 til 1200 GPa (fra 566 til 1050 mm Hg).
- Kjølelufttemperatur:
på parkeringsplassen - ikke mer enn 27 ºС, for tekniske blokker - ikke mer enn 29 ºС,
under flyging - ikke mer enn 25 ºС, for tekniske blokker - ikke mer enn 27 ºС. - Kjøleluftstrøm:
når parkert - minst 708 kg/t,
under flyging - ikke mindre enn 660 kg/t. - Lufttemperaturen i instrumentrommene er ikke mer enn 60 ºС.
- Mengden finfri fuktighet i kjøleluften er ikke mer enn 2 g/kg tørr luft.
Selv innenfor dette begrensede settet med krav, er det minst to kategorier som må håndteres annerledes i systemet:
- krav til driftsforholdene til systemet (klausul 1-3);
- parametriske krav til systemet (klausul 3-7).
Krav til systemdriftsbetingelser
Ytre forhold for systemet som utvikles under modellering kan spesifiseres som grenseforhold eller som følge av driften av det generelle systemet.
Ved dynamisk simulering er det nødvendig å sikre at de angitte driftsforholdene dekkes av simuleringsprosessen.
Parametriske systemkrav
Disse kravene er parametere gitt av systemet selv. Under modelleringsprosessen kan vi få disse parameterne som beregningsresultater og sørge for at kravene oppfylles i hver spesifikke beregning.
Krav identifikasjon og koding
For å lette arbeidet med krav anbefaler eksisterende standarder å tilordne en identifikator til hvert krav. Når du tildeler identifikatorer, er det svært ønskelig å bruke et enhetlig kodesystem.
Kravkoden kan ganske enkelt være et tall som representerer ordrenummeret til kravet, eller den kan inneholde en kode for typen krav, en kode for systemet eller enheten den gjelder for, en parameterkode, en lokasjonskode og alt annet ingeniøren kan forestille seg. (se artikkelen for bruk av koding)
Tabell 1 gir et enkelt eksempel på kravkoding.
- kode for kilden til krav R-krav TK;
- kode type krav E - krav - miljøparametere, eller driftsforhold
S - krav gitt av systemet; - flystatuskode 0 – alle, G – parkert, F – under flyging;
- fysisk parametertypekode T – temperatur, P – trykk, G – strømningshastighet, fuktighet H;
- serienummeret til kravet.
| ID Krav |
beskrivelse | Parameter |
| REGT01 | Omgivelsestemperatur ved inngangen til vannkjølesystemet: på parkeringsplassen - fra minus 35ºС. opptil 35 ºС. | |
| REFT01 | Atmosfærisk lufttemperatur ved inngangen til luftvernsystemet: under flukt - fra minus 35 ºС til 39 ºС. | |
| REFP01 | Statisk atmosfærisk lufttrykk under flyging er fra 700 til 1013 hPa (fra 526 til 760 mm Hg). | |
| REFP02 | Det totale lufttrykket ved inngangen til SVO-luftinntaket under flyging er fra 754 til 1200 hPa (fra 566 til 1050 mm Hg). | |
| RSGT01 | Kjølelufttemperatur: når parkert ikke mer enn 27 ºС | |
| RSGT02 | Kjølelufttemperatur: på parkeringsplassen, for tekniske enheter ikke mer enn 29 ºС | |
| RSFT01 | Kjølelufttemperatur under flyging ikke mer enn 25 ºС | |
| RSFT02 | Kjølelufttemperatur: under flyging, for tekniske enheter ikke mer enn 27 ºС | |
| RSGG01 | Kjøleluftstrøm: ved parkering ikke mindre enn 708 kg/t | |
| RSFG01 | Kjøleluftstrøm: under flyging ikke mindre enn 660 kg/t | |
| RS0T01 | Lufttemperatur i instrumentrom ikke mer enn 60 ºС | |
| RSH01 | Mengden finfri fuktighet i kjøleluften er ikke mer enn 2 g/kg tørr luft |
Krav verifikasjonssystem design.
For hvert designkrav er det en algoritme for å vurdere samsvaret mellom designparametrene og parameterne spesifisert i kravet. I det store og hele inneholder ethvert kontrollsystem alltid algoritmer for å sjekke krav som standard. Og til og med enhver regulator inneholder dem. Hvis temperaturen går utenfor grensene, slås klimaanlegget på. Det første trinnet i enhver regulering er derfor å sjekke om parametrene oppfyller kravene.
Og siden verifisering er en algoritme, kan vi bruke de samme verktøyene og verktøyene som vi bruker til å lage kontrollprogrammer. SimInTech-miljøet lar deg for eksempel lage prosjektpakker som inneholder ulike deler av modellen, utført i form av separate prosjekter (objektmodell, kontrollsystemmodell, miljømodell osv.).
Kravverifiseringsprosjektet i dette tilfellet blir det samme algoritmeprosjektet og kobles til modellpakken. Og i dynamisk modelleringsmodus utfører den en analyse for samsvar med kravene til de tekniske spesifikasjonene.
Et mulig eksempel på systemdesign er vist i figur 1.
Figur 1. Eksempel på design av et verifikasjonsprosjekt.
Akkurat som for kontrollalgoritmer kan krav utarbeides som et sett med ark. For å gjøre det lettere å jobbe med algoritmer i strukturelle modelleringsmiljøer som SimInTech, Simulink, AmeSim, brukes muligheten til å lage flernivåstrukturer i form av undermodeller. Denne organiseringen gjør det mulig å gruppere ulike krav i sett for å forenkle arbeidet med en rekke krav, slik det gjøres for kontrollalgoritmer (se fig. 2).
Figur 2. Hierarkisk struktur av kravverifiseringsmodellen.
For eksempel skilles det mellom to grupper i den aktuelle saken: krav til miljø og krav direkte til systemet. Derfor brukes en to-nivå datastruktur: to grupper, som hver er et blad av algoritmen.
For å koble data til modellen benyttes et standardskjema for å generere en signaldatabase, som lagrer data for utveksling mellom deler av prosjektet.
Ved opprettelse og testing av programvare plasseres avlesningene av sensorer (analoger av ekte systemsensorer) som brukes av kontrollsystemet i denne databasen.
For et testprosjekt kan eventuelle parametere beregnet i den dynamiske modellen lagres i samme database og dermed brukes til å kontrollere om kravene er oppfylt.
I dette tilfellet kan selve den dynamiske modellen kjøres i et hvilket som helst matematisk modelleringssystem eller til og med i form av et kjørbart program. Det eneste kravet er tilstedeværelsen av programvaregrensesnitt for å utstede modelleringsdata til det eksterne miljøet.
Figur 3. Koble verifikasjonsprosjektet til den komplekse modellen.
Et eksempel på et basiskravverifikasjonsark er presentert i figur 4. Fra utviklerens synspunkt er det et konvensjonelt beregningsdiagram der kravverifiseringsalgoritmen er grafisk presentert.
Figur 4. Kravsjekkark.
Hoveddelene av sjekkarket er beskrevet i figur 5. Sjekkalgoritmen er formet på samme måte som designdiagrammene til kontrollalgoritmer. På høyre side er det en blokk for lesing av signaler fra databasen. Denne blokken får tilgang til signaldatabasen under simulering.
De mottatte signalene analyseres for å beregne kravverifiseringsbetingelser. I dette tilfellet utføres høydeanalyse for å bestemme posisjonen til flyet (enten det er parkert eller under flyging). For dette formålet kan du bruke andre signaler og beregnede parametere til modellen.
Verifikasjonsbetingelsene og parametrene som kontrolleres overføres til standard verifikasjonsblokker, hvor disse parametrene analyseres for samsvar med de spesifiserte kravene. Resultatene registreres i signaldatabasen på en slik måte at de kan brukes til automatisk å generere en sjekkliste.
Figur 5. Struktur av kravverifikasjonsberegningsarket.
Parametrene som skal testes bruker ikke nødvendigvis signaler i databasen, som styres av parametere som beregnes under simuleringsprosessen. Ingenting hindrer oss i å foreta tilleggsberegninger innenfor rammen av utkastkravene, slik vi beregner verifikasjonsbetingelsene.
For eksempel dette kravet:
Antall aktiveringer av korreksjonssystemet under flyturen til målet bør ikke overstige 5, og den totale driftstiden til korreksjonssystemet bør ikke overstige 30 sekunder.
I dette tilfellet legges en algoritme for å motvirke antall starter og total driftstid til designdiagrammet for kravene.
Verifikasjonsblokk for typiske krav.
Hver avmerkingsboks for standardkrav er utformet for å beregne oppfyllelsen av et krav av en bestemt type. For eksempel inkluderer miljøkravene en rekke omgivende driftstemperaturer når parkert og under flyging. Denne blokken må motta lufttemperaturen i modellen som en parameter og bestemme om denne parameteren dekker det angitte temperaturområdet./p>
Blokken inneholder to inngangsporter, param og condition.
Den første mates med parameteren som kontrolleres. I dette tilfellet "Ekstern temperatur".
En boolsk variabel leveres til den andre porten - betingelsen for å utføre kontrollen.
Hvis TRUE (1) mottas ved den andre inngangen, utfører blokken en kravverifikasjonsberegning.
Hvis den andre inngangen mottar FALSE (0), er ikke testbetingelsene oppfylt. Dette er nødvendig for at det kan tas hensyn til beregningsforholdene. I vårt tilfelle brukes denne inngangen til å aktivere eller deaktivere kontrollen avhengig av modellens tilstand. Hvis flyet er på bakken under simuleringen, kontrolleres ikke kravene knyttet til flyging, og omvendt - hvis flyet er under flyging, kontrolleres ikke kravene knyttet til drift på standplass.
Denne inngangen kan også brukes når du setter opp modellen, for eksempel ved innledende beregningsfase. Når modellen bringes inn i ønsket tilstand, deaktiveres kontrollblokkene, men så snart systemet når ønsket driftsmodus, slås kontrollblokkene på.
Parametrene til denne blokken er:
- grensebetingelser: øvre (UpLimit) og nedre (DownLimit) områdegrenser som må kontrolleres;
- nødvendig systemeksponeringstid ved grenseområdene (TimeInterval) i sekunder;
- Request ID ReqName;
- tillatelse for å overskride området Out_range er en boolsk variabel som bestemmer om en verdi som overskrider det sjekkede området er et brudd på kravet.
I noen tilfeller indikerer testverdien at systemet har en viss margin og kan operere utenfor driftsområdet. I andre tilfeller betyr en utgang at systemet ikke klarer å holde settpunktene innenfor rekkevidde.
Figur 6. En typisk egenskapssjekkblokk i diagrammet og dets parametere.
Som et resultat av beregningen av denne blokken, dannes resultatvariabelen ved utgangen, som tar følgende verdier:
- 0 – rIngen, verdi ikke definert;
- 1 – rFerdig, kravet er oppfylt;
- 2 – rFeil, kravet er ikke oppfylt.
Blokkbildet inneholder:
- identifikasjonstekst;
- digitale visninger av parametere for målegrenser;
- fargeidentifikator for parameterstatus.
Inne i blokken kan det være en ganske kompleks logisk slutningskrets.
For å kontrollere driftstemperaturområdet til enheten vist i figur 6, er den interne kretsen vist i figur 7.
Figur 7. Internt diagram av enhet for temperaturområdebestemmelse.
Inne i kretsblokken brukes egenskapene spesifisert i blokkparameterne.
I tillegg til å analysere samsvar med krav, inneholder det interne diagrammet av blokken en graf som er nødvendig for å vise simuleringsresultatene. Denne grafen kan brukes både for visning under beregning og for å analysere resultatene etter beregning.
Beregningsresultatene overføres til utgangen av blokken og registreres samtidig i en generell rapportfil, som opprettes basert på resultatene for hele prosjektet. (se fig. 8)
Et eksempel på en rapport laget basert på simuleringsresultatene er en html-fil laget i henhold til et gitt format. Formatet kan konfigureres vilkårlig til formatet som er akseptert av en bestemt organisasjon.
Inne i kretsblokken brukes egenskapene spesifisert i blokkparameterne.
I tillegg til å analysere samsvar med krav, inneholder det interne diagrammet av blokken en graf som er nødvendig for å vise simuleringsresultatene. Denne grafen kan brukes både for visning under beregning og for å analysere resultatene etter beregning.
Beregningsresultatene overføres til utgangen av blokken og registreres samtidig i en generell rapportfil, som opprettes basert på resultatene for hele prosjektet. (se fig. 8)
Et eksempel på en rapport laget basert på simuleringsresultatene er en html-fil laget i henhold til et gitt format. Formatet kan konfigureres vilkårlig til formatet som er akseptert av en bestemt organisasjon.
Figur 8. Eksempel på rapportfil basert på simuleringsresultater.
I dette eksemplet er rapportskjemaet konfigurert direkte i prosjektegenskapene, og formatet i tabellen er satt som globale prosjektsignaler. I dette tilfellet løser SimInTech selv problemet med å sette opp rapporten, og blokken for å skrive resultater til en fil bruker disse linjene til å skrive til rapportfilen.
Figur 9. Innstilling av rapportformat i globale prosjektsignaler
Bruke en signaldatabase for krav.
For å automatisere arbeid med egenskapsinnstillinger lages det en standardstruktur i signaldatabasen for hver typisk blokk. (se fig. 10)
Figur 10. Eksempel på strukturen til en kravkontrollblokk i en signaldatabase.
Signaldatabase gir:
- Lagre alle nødvendige systemkravparametere.
- Praktisk visning av eksisterende prosjektkrav fra spesifiserte parametere og gjeldende modelleringsresultater.
- Sette opp en blokk eller en gruppe blokker ved å bruke et skriptprogrammeringsspråk. Endringer i signaldatabasen fører til endringer i blokkegenskapsverdiene i diagrammet.
- Lagring av tekstbeskrivelser, lenker til tekniske spesifikasjoner eller identifikatorer i kravstyringssystemet.
Signaldatabasestrukturer for krav kan enkelt konfigureres til å fungere med et tredjeparts kravstyringssystem. Et generelt diagram over interaksjon med kravstyringssystemer er presentert i figur 11.
Figur 11. Diagram over samhandling med kravstyringssystemet.
Samhandlingssekvensen mellom SimInTech-testprosjektet og kravkontrollsystemet er som følger:
- Mandatet er brutt ned i krav.
- Kravene til de tekniske spesifikasjonene er identifisert som kan verifiseres ved matematisk modellering av tekniske prosesser.
- Attributter til de valgte kravene overføres til SimInTech-signaldatabasen i strukturen til standardblokker (for eksempel maksimum og minimum temperatur).
- Under beregningsprosessen overføres strukturdata til blokkdesigndiagrammer, analyse utføres og resultatene lagres i en signaldatabase.
- Når beregningen er fullført, overføres analyseresultatene til kravstyringssystemet.
Kravtrinn 3 til 5 kan gjentas under designprosessen når endringer i designet og/eller kravene oppstår og virkningen av endringene må testes på nytt.
Konklusjoner.
- Den opprettede prototypen av systemet gir en betydelig reduksjon i analysetiden av eksisterende modeller for samsvar med kravene i de tekniske spesifikasjonene.
- Den foreslåtte testteknologien bruker allerede eksisterende dynamiske modeller og kan brukes selv for alle dynamiske modeller, inkludert de som ikke utføres i SimInTech-miljøet.
- Ved å bruke batchdataorganisering kan du lage kravverifiseringspakker parallelt med modellutvikling, eller til og med bruke disse pakkene som tekniske spesifikasjoner for modellutvikling.
- Teknologien kan integreres med eksisterende kravstyringssystemer uten vesentlige kostnader.
For de som leser til slutten,
Kilde: www.habr.com