Fortsätter på temat , låt oss titta på problemet med matematisk modellering från andra sidan. Efter att vi är övertygade om att modellen motsvarar livets hemspunnen sanning kan vi svara på huvudfrågan: "Vad har vi här egentligen?" När vi skapar en modell av ett tekniskt objekt vill vi vanligtvis försäkra oss om att detta objekt kommer att uppfylla våra förväntningar. För detta ändamål utförs dynamiska beräkningar av processer och resultatet jämförs med kraven. Detta är en digital tvilling, en virtuell prototyp, etc. fashionabla shnyags som på designstadiet löser problemet med hur vi ska se till att vi får det vi planerat.
Hur kan vi snabbt säkerställa att vårt system är precis vad vi designar, kommer vår design att flyga eller flyta? Och om den flyger, hur högt? Och om den flyter, hur djupt?
Den här artikeln diskuterar automatisering av verifiering av överensstämmelse med kraven för en teknisk byggnad när du skapar dynamiska modeller av tekniska system. Som ett exempel, låt oss titta på en del av den tekniska specifikationen för ett luftkylningssystem för flygplan.
Vi tar hänsyn till de krav som kan uttryckas numeriskt och verifieras matematiskt utifrån en specifik beräkningsmodell. Det är tydligt att detta bara är en del av de allmänna kraven för alla tekniska system, men det är på att kontrollera dem som vi lägger tid, nerver och pengar på att skapa dynamiska modeller av objektet.
Vid beskrivning av tekniska krav i form av ett dokument kan flera typer av olika krav urskiljas, som var och en kräver olika tillvägagångssätt för bildandet av automatisk verifiering av kravuppfyllelse.
Tänk till exempel på denna lilla men realistiska uppsättning krav:
- Atmosfärisk lufttemperatur vid ingången till vattenbehandlingssystemet:
på parkeringen - från minus 35 till 35 ºС,
under flygning - från minus 35 till 39 ºС. - Det statiska trycket för atmosfärisk luft under flygning är från 700 till 1013 GPa (från 526 till 760 mm Hg).
- Det totala lufttrycket vid ingången till SVO-luftintaget under flygning är från 754 till 1200 GPa (från 566 till 1050 mm Hg).
- Kylluftstemperatur:
på parkeringsplatsen - högst 27 ºС, för tekniska block - inte mer än 29 ºС,
under flygning - högst 25 ºС, för tekniska block - inte mer än 27 ºС. - Kylluftflöde:
vid parkering - minst 708 kg/h,
under flygning - inte mindre än 660 kg/h. - Lufttemperaturen i instrumentfacken är inte mer än 60 ºС.
- Mängden finfri fukt i kylluften är inte mer än 2 g/kg torr luft.
Även inom denna begränsade uppsättning krav finns det minst två kategorier som måste hanteras olika i systemet:
- krav på driftförhållanden för systemet (klausuler 1-3);
- parametriska krav för systemet (klausulerna 3-7).
Krav på systemdriftsförhållanden
Externa villkor för systemet som utvecklas under modellering kan specificeras som randvillkor eller som ett resultat av driften av det allmänna systemet.
Vid dynamisk simulering är det nödvändigt att säkerställa att de specificerade driftsförhållandena täcks av simuleringsprocessen.
Parametriska systemkrav
Dessa krav är parametrar som tillhandahålls av systemet självt. Under modelleringsprocessen kan vi få fram dessa parametrar som beräkningsresultat och se till att kraven uppfylls i varje specifik beräkning.
Krav identifiering och kodning
För att underlätta arbetet med krav rekommenderar befintliga standarder att man tilldelar en identifierare till varje krav. Vid tilldelning av identifierare är det mycket önskvärt att använda ett enhetligt kodningssystem.
Kravkoden kan helt enkelt vara ett nummer som representerar kravets ordernummer, eller så kan den innehålla en kod för typen av krav, en kod för det system eller den enhet som den gäller, en parameterkod, en platskod och allt annat ingenjören kan tänka sig. (se artikeln för användning av kodning)
Tabell 1 ger ett enkelt exempel på kravkodning.
- kod för kravkällan R-krav TK;
- kodtyp av krav E - krav - miljöparametrar, eller driftförhållanden
S - krav från systemet; - flygplanets statuskod 0 – valfri, G – parkerad, F – under flygning;
- fysisk parametertypkod T – temperatur, P – tryck, G – flödeshastighet, fuktighet H;
- kravets serienummer.
| ID Krav |
beskrivning | Parameter |
| REGT01 | Omgivande lufttemperatur vid ingången till vattenkylningssystemet: på parkeringsplatsen - från minus 35ºС. upp till 35 ºС. | |
| REFT01 | Atmosfärisk lufttemperatur vid ingången till luftförsvarssystemet: under flygning - från minus 35 ºС till 39 ºС. | |
| REFP01 | Statiskt atmosfäriskt lufttryck under flygning är från 700 till 1013 hPa (från 526 till 760 mm Hg). | |
| REFP02 | Det totala lufttrycket vid ingången till SVO-luftintaget under flygning är från 754 till 1200 hPa (från 566 till 1050 mm Hg). | |
| RSGT01 | Kylluftstemperatur: vid parkering högst 27 ºС | |
| RSGT02 | Kylluftstemperatur: på parkeringsplatsen, för tekniska enheter inte mer än 29 ºС | |
| RSFT01 | Kylluftens temperatur under flygning inte överstiga 25 ºС | |
| RSFT02 | Kylluftstemperatur: under flygning, för tekniska enheter högst 27 ºС | |
| RSGG01 | Kylluftflöde: vid parkering inte mindre än 708 kg/h | |
| RSFG01 | Kylluftflöde: under flygning inte mindre än 660 kg/h | |
| RS0T01 | Lufttemperatur i instrumentutrymmen inte överstiga 60 ºС | |
| RSH01 | Mängden finfri fukt i kylluften är inte mer än 2 g/kg torr luft |
Krav verifieringssystem design.
För varje designkrav finns det en algoritm för att bedöma överensstämmelsen mellan designparametrarna och de parametrar som specificeras i kravet. I stort sett innehåller alla kontrollsystem alltid algoritmer för att kontrollera krav helt enkelt som standard. Och till och med vilken regulator som helst innehåller dem. Om temperaturen går utanför gränserna slås luftkonditioneringen på. Det första steget i varje reglering är alltså att kontrollera om parametrarna uppfyller kraven.
Och eftersom verifiering är en algoritm kan vi använda samma verktyg och verktyg som vi använder för att skapa kontrollprogram. SimInTech-miljön låter dig till exempel skapa projektpaket som innehåller olika delar av modellen, utförda i form av separata projekt (objektmodell, styrsystemmodell, miljömodell, etc.).
Kravverifieringsprojektet blir i detta fall samma algoritmprojekt och kopplas till modellpaketet. Och i det dynamiska modelleringsläget utför den en analys för att uppfylla kraven i de tekniska specifikationerna.
Ett möjligt exempel på en systemdesign visas i figur 1.
Figur 1. Exempel på design av ett verifieringsprojekt.
Precis som för styralgoritmer kan kraven ritas upp som en uppsättning ark. För att underlätta arbetet med algoritmer i strukturella modelleringsmiljöer som SimInTech, Simulink, AmeSim används möjligheten att skapa flernivåstrukturer i form av delmodeller. Denna organisation gör det möjligt att gruppera olika krav i uppsättningar för att förenkla arbetet med en rad krav, som görs för styralgoritmer (se fig. 2).
Figur 2. Hierarkisk struktur av kravverifieringsmodellen.
I det aktuella fallet skiljer man till exempel på två grupper: krav på miljön och krav direkt på systemet. Därför används en datastruktur på två nivåer: två grupper, som var och en är ett blad av algoritmen.
För att koppla data till modellen används ett standardschema för att generera en signaldatabas, som lagrar data för utbyte mellan delar av projektet.
När man skapar och testar mjukvara placeras avläsningarna av sensorer (analoger av verkliga systemsensorer) som används av styrsystemet i denna databas.
För ett testprojekt kan eventuella parametrar som beräknats i den dynamiska modellen lagras i samma databas och därmed användas för att kontrollera om kraven är uppfyllda.
I det här fallet kan själva den dynamiska modellen exekveras i vilket matematiskt modelleringssystem som helst eller till och med i form av ett körbart program. Det enda kravet är närvaron av mjukvarugränssnitt för att utfärda modelleringsdata till den externa miljön.
Figur 3. Koppla verifieringsprojektet till den komplexa modellen.
Ett exempel på ett grundläggande kravverifieringsblad presenteras i figur 4. Ur utvecklarens synvinkel är det ett konventionellt beräkningsdiagram på vilket kravverifieringsalgoritmen presenteras grafiskt.
Figur 4. Kravkontrollblad.
Huvuddelarna av kontrollbladet beskrivs i figur 5. Kontrollalgoritmen är utformad på liknande sätt som designdiagrammen för kontrollalgoritmer. På höger sida finns ett block för att läsa signaler från databasen. Detta block kommer åt signaldatabasen under simulering.
De mottagna signalerna analyseras för att beräkna kravverifieringsförhållanden. I detta fall utförs höjdanalys för att bestämma flygplanets position (oavsett om det är parkerat eller under flygning). För detta ändamål kan du använda andra signaler och beräknade parametrar för modellen.
Verifieringsvillkoren och parametrarna som kontrolleras överförs till standardverifieringsblock, där dessa parametrar analyseras för att uppfylla de specificerade kraven. Resultaten registreras i signaldatabasen på ett sådant sätt att de kan användas för att automatiskt generera en checklista.
Figur 5. Struktur av kravverifieringsberäkningsbladet.
Parametrarna som ska testas använder inte nödvändigtvis signaler som finns i databasen, som styrs av parametrar som beräknas under simuleringsprocessen. Ingenting hindrar oss från att utföra ytterligare beräkningar inom ramen för utkastkraven, precis som vi beräknar verifieringsvillkoren.
Till exempel detta krav:
Antalet aktiveringar av korrigeringssystemet under flygningen till målet bör inte överstiga 5, och den totala drifttiden för korrigeringssystemet bör inte överstiga 30 sekunder.
I detta fall läggs en algoritm för att motverka antalet starter och total drifttid till designdiagrammet för kraven.
Typiska krav verifieringsblock.
Varje kryssruta för standardkrav är utformad för att beräkna uppfyllandet av ett krav av en viss typ. Till exempel inkluderar miljökraven en rad omgivande driftstemperaturer vid parkerad och under flygning. Detta block måste ta emot lufttemperaturen i modellen som en parameter och avgöra om denna parameter täcker det specificerade temperaturområdet./p>
Blocket innehåller två ingångsportar, param och condition.
Den första matas med parametern som kontrolleras. I detta fall "Extern temperatur".
En boolesk variabel matas till den andra porten - villkoret för att utföra kontrollen.
Om TRUE (1) tas emot vid den andra ingången, utför blocket en kravverifieringsberäkning.
Om den andra ingången tar emot FALSK (0), är testvillkoren inte uppfyllda. Detta är nödvändigt för att beräkningsvillkoren ska kunna beaktas. I vårt fall används denna ingång för att aktivera eller inaktivera kontrollen beroende på modellens tillstånd. Om flygplanet är på marken under simuleringen kontrolleras inte kraven relaterade till flygning, och vice versa - om flygplanet är under flygning kontrolleras inte kraven relaterade till drift vid uppställning.
Denna ingång kan också användas vid inställning av modellen, till exempel i det inledande skedet av beräkningen. När modellen förs in i det önskade tillståndet är kontrollblocken inaktiverade, men så snart systemet når det önskade driftläget slås kontrollblocken på.
Parametrarna för detta block är:
- gränsvillkor: övre (UpLimit) och nedre (DownLimit) intervallgränser som måste kontrolleras;
- erforderlig systemexponeringstid vid gränsområdena (TimeInterval) i sekunder;
- Request ID ReqName;
- tillåtlighet att överskrida intervallet Out_range är en boolesk variabel som avgör om ett värde som överskrider det kontrollerade intervallet är ett brott mot kravet.
I vissa fall indikerar testvärdets utdata att systemet har en viss marginal och kan arbeta utanför sitt driftsområde. I andra fall innebär en utgång att systemet inte kan hålla börvärdena inom området.
Figur 6. Ett typiskt egenskapskontrollblock i diagrammet och dess parametrar.
Som ett resultat av beräkningen av detta block bildas resultatvariabeln vid utgången, som tar följande värden:
- 0 – rInget, värde ej definierat;
- 1 – rKlar, kravet är uppfyllt;
- 2 – rFel, kravet är inte uppfyllt.
Blockbilden innehåller:
- identifieringstext;
- digitala visningar av parametrar för mätgränser;
- färgidentifierare för parameterstatus.
Inuti blocket kan det finnas en ganska komplex logisk slutledningskrets.
Till exempel, för att kontrollera driftstemperaturområdet för enheten som visas i figur 6, visas den interna kretsen i figur 7.
Figur 7. Internt diagram över enheten för bestämning av temperaturområde.
Inuti kretsblocket används egenskaperna specificerade i blockparametrarna.
Förutom att analysera efterlevnaden av kraven, innehåller det interna diagrammet för blocket en graf som är nödvändig för att visa simuleringsresultaten. Denna graf kan användas både för visning under beräkning och för att analysera resultaten efter beräkning.
Beräkningsresultaten överförs till blockets utgång och registreras samtidigt i en allmän rapportfil, som skapas utifrån resultaten för hela projektet. (se fig. 8)
Ett exempel på en rapport som skapats utifrån simuleringsresultaten är en html-fil skapad enligt ett givet format. Formatet kan konfigureras godtyckligt till det format som accepteras av en viss organisation.
Inuti kretsblocket används egenskaperna specificerade i blockparametrarna.
Förutom att analysera efterlevnaden av kraven, innehåller det interna diagrammet för blocket en graf som är nödvändig för att visa simuleringsresultaten. Denna graf kan användas både för visning under beräkning och för att analysera resultaten efter beräkning.
Beräkningsresultaten överförs till blockets utgång och registreras samtidigt i en allmän rapportfil, som skapas utifrån resultaten för hela projektet. (se fig. 8)
Ett exempel på en rapport som skapats utifrån simuleringsresultaten är en html-fil skapad enligt ett givet format. Formatet kan konfigureras godtyckligt till det format som accepteras av en viss organisation.
Figur 8. Exempel på en rapportfil baserad på simuleringsresultat.
I det här exemplet konfigureras rapportformuläret direkt i projektegenskaperna och formatet i tabellen är inställt som globala projektsignaler. I det här fallet löser SimInTech själva problemet med att sätta upp rapporten, och blocket för att skriva resultat till en fil använder dessa rader för att skriva till rapportfilen.
Figur 9. Inställning av rapportformat i globala projektsignaler
Använda en signaldatabas för krav.
För att automatisera arbetet med egenskapsinställningar skapas en standardstruktur i signaldatabasen för varje typiskt block. (se bild 10)
Figur 10. Exempel på strukturen för ett kravkontrollblock i en signaldatabas.
Signaldatabasen ger:
- Lagrar alla nödvändiga systemkravsparametrar.
- Bekväm visning av befintliga projektkrav från specificerade parametrar och aktuella modelleringsresultat.
- Konfigurera ett block eller en grupp av block med hjälp av ett skriptspråk. Ändringar i signaldatabasen leder till ändringar i blockegenskapsvärdena i diagrammet.
- Lagring av textbeskrivningar, länkar till tekniska specifikationer eller identifierare i kravhanteringssystemet.
Signaldatabasstrukturer för krav kan enkelt konfigureras för att fungera med ett kravhanteringssystem från tredje part. Ett allmänt diagram över interaktion med kravhanteringssystem presenteras i figur 11.
Figur 11. Diagram över interaktion med kravhanteringssystemet.
Sekvensen av interaktion mellan SimInTech-testprojektet och kravkontrollsystemet är som följer:
- Uppdraget är uppdelat i krav.
- Kraven i de tekniska specifikationerna identifieras som kan verifieras genom matematisk modellering av tekniska processer.
- Attribut för de valda kraven överförs till SimInTech-signaldatabasen i strukturen av standardblock (till exempel högsta och lägsta temperatur).
- Under beräkningsprocessen överförs strukturdata till blockdesigndiagram, analys utförs och resultaten lagras i en signaldatabas.
- När beräkningen är klar överförs analysresultaten till kravhanteringssystemet.
Kravsteg 3 till 5 kan upprepas under designprocessen när ändringar av designen och/eller kraven inträffar och förändringarnas inverkan behöver testas på nytt.
Slutsatser.
- Den skapade prototypen av systemet ger en betydande minskning av analystiden av befintliga modeller för överensstämmelse med kraven i de tekniska specifikationerna.
- Den föreslagna testtekniken använder redan befintliga dynamiska modeller och kan användas även för alla dynamiska modeller, inklusive de som inte utförs i SimInTech-miljön.
- Genom att använda batchdataorganisation kan du skapa kravverifieringspaket parallellt med modellutveckling, eller till och med använda dessa paket som tekniska specifikationer för modellutveckling.
- Tekniken kan integreras med befintliga kravhanteringssystem utan betydande kostnader.
För er som läser till slutet,
Källa: will.com