Automatische verificatie van technische specificaties tijdens dynamische modellering

Voortzetting van het thema "Wat is uw bewijs?"Laten we het probleem van wiskundige modellering eens van de andere kant bekijken. Nadat we ervan overtuigd zijn dat het model overeenkomt met de huiselijke waarheid van het leven, kunnen we de hoofdvraag beantwoorden: “wat hebben we hier precies?” Wanneer we een model van een technisch object maken, willen we er meestal zeker van zijn dat dit object aan onze verwachtingen voldoet. Hiertoe worden dynamische procesberekeningen uitgevoerd en het resultaat vergeleken met de eisen. Dit is een digitale tweeling, een virtueel prototype, enz. modieuze kleine jongens die in de ontwerpfase het probleem oplossen hoe we ervoor kunnen zorgen dat we krijgen wat we gepland hebben.

Hoe kunnen we er snel voor zorgen dat ons systeem precies is wat we ontwerpen: zal ons ontwerp vliegen of zweven? En als het vliegt, hoe hoog? En als het drijft, hoe diep?

Dit artikel bespreekt de automatisering van de verificatie van de naleving van de eisen van een technisch gebouw bij het maken van dynamische modellen van technische systemen. Laten we als voorbeeld eens kijken naar een onderdeel van de technische specificatie voor een luchtkoelsysteem voor vliegtuigen.

We beschouwen die eisen die numeriek kunnen worden uitgedrukt en wiskundig kunnen worden geverifieerd op basis van een specifiek rekenmodel. Het is duidelijk dat dit slechts een deel is van de algemene vereisten voor elk technisch systeem, maar het controleren ervan kost tijd, zenuwen en geld om dynamische modellen van het object te maken.

Bij het beschrijven van technische vereisten in de vorm van een document kunnen verschillende soorten verschillende vereisten worden onderscheiden, die elk een verschillende aanpak vereisen voor het vormen van automatische verificatie van de vervulling van de vereisten.

Denk bijvoorbeeld eens aan deze kleine maar realistische reeks eisen:

1. Atmosferische luchttemperatuur bij de ingang van het waterbehandelingssysteem:
   op de parkeerplaats - van min 35 tot 35 ºС,
   tijdens de vlucht - van min 35 tot 39 ºС.
2. De statische druk van atmosferische lucht tijdens de vlucht bedraagt ​​700 tot 1013 GPa (van 526 tot 760 mm Hg).
3. De totale luchtdruk bij de ingang van de SVO-luchtinlaat tijdens de vlucht is van 754 tot 1200 GPa (van 566 tot 1050 mm Hg).
4. Koelluchttemperatuur:
   op de parkeerplaats - niet meer dan 27 ºС, voor technische blokken - niet meer dan 29 ºС,
   tijdens de vlucht - niet meer dan 25 ºС, voor technische blokken - niet meer dan 27 ºС.
5. Koelluchtstroom:
   wanneer geparkeerd - minimaal 708 kg/u,
   tijdens de vlucht - niet minder dan 660 kg/u.
6. De luchttemperatuur in de instrumentencompartimenten bedraagt ​​niet meer dan 60 ºC.
7. De hoeveelheid fijn vrij vocht in de koellucht bedraagt ​​maximaal 2 g/kg droge lucht.

Zelfs binnen deze beperkte reeks vereisten zijn er minstens twee categorieën die anders moeten worden afgehandeld in het systeem:

• vereisten voor bedrijfsomstandigheden van het systeem (artikelen 1-3);
• parametrische vereisten voor het systeem (artikelen 3-7).

Vereisten voor systeembedrijfsomstandigheden
Externe omstandigheden voor het systeem dat tijdens het modelleren wordt ontwikkeld, kunnen worden gespecificeerd als randvoorwaarden of als resultaat van de werking van het algemene systeem.
Bij dynamische simulatie is het noodzakelijk ervoor te zorgen dat de gespecificeerde bedrijfsomstandigheden door het simulatieproces worden gedekt.

Parametrische systeemvereisten
Deze vereisten zijn parameters die door het systeem zelf worden verstrekt. Tijdens het modelleringsproces kunnen we deze parameters als berekeningsresultaten verkrijgen en ervoor zorgen dat bij elke specifieke berekening aan de vereisten wordt voldaan.

Eisen identificatie en codering

Om het werken met vereisten te vergemakkelijken, raden bestaande standaarden aan om aan elke vereiste een identificatie toe te kennen. Bij het toekennen van identificatiegegevens is het zeer wenselijk om een ​​uniform coderingssysteem te gebruiken.

Een vereistecode kan eenvoudigweg een nummer zijn dat het ordernummer van de vereiste vertegenwoordigt, of kan een code bevatten voor het type vereiste, een code voor het systeem of de eenheid waarop deze van toepassing is, een parametercode, een locatiecode en al het andere dat een ingenieur zich kan voorstellen. (zie het artikel voor het gebruik van codering)

Tabel 1 geeft een eenvoudig voorbeeld van het coderen van eisen.

1. code van de bron van eisen R-eisen TK;
2. code type eisen E - eisen - omgevingsparameters of bedrijfsomstandigheden
   S - vereisten van het systeem;
3. vliegtuigstatuscode 0 – willekeurig, G – geparkeerd, F – tijdens de vlucht;
4. fysieke parametertypecode T – temperatuur, P – druk, G – debiet, vochtigheid H;
5. serienummer van de vereiste.

ID Eisen	beschrijving	Parameter
REGT01	Omgevingsluchttemperatuur bij de ingang van het waterkoelsysteem: op de parkeerplaats - van min 35ºС. tot 35ºC.
REFT01	Atmosferische luchttemperatuur bij de ingang van het luchtverdedigingssysteem: tijdens de vlucht - van minus 35 ºС tot 39 ºС.
REFP01	De statische atmosferische luchtdruk tijdens de vlucht bedraagt ​​700 tot 1013 hPa (van 526 tot 760 mm Hg).
REFP02	De totale luchtdruk bij de ingang van de SVO-luchtinlaat tijdens de vlucht is van 754 tot 1200 hPa (van 566 tot 1050 mm Hg).
RSGT01	Koelluchttemperatuur: bij stilstand niet meer dan 27 ºC
RSGT02	Koelluchttemperatuur: op de parkeerplaats, voor technische units niet meer dan 29 ºС
RSFT01	Koelluchttemperatuur tijdens de vlucht niet meer dan 25 ºC
RSFT02	Koelluchttemperatuur: tijdens de vlucht, voor technische eenheden niet meer dan 27 ºC
RSGG01	Koelluchtstroom: bij stilstand maar liefst 708 kg/u
RSFG01	Koelluchtstroom: tijdens de vlucht maar liefst 660 kg/u
RS0T01	Luchttemperatuur in instrumentencompartimenten niet meer dan 60 ºC
RSH01	De hoeveelheid fijn vrij vocht in de koellucht bedraagt ​​maximaal 2 g/kg droge lucht

Systeemontwerp voor vereistenverificatie.

Voor elke ontwerpeis bestaat er een algoritme om de overeenstemming tussen de ontwerpparameters en de in de eis gespecificeerde parameters te beoordelen. Over het algemeen bevat elk besturingssysteem altijd standaard algoritmen om de vereisten te controleren. En zelfs elke regelaar bevat ze. Als de temperatuur buiten de limieten komt, wordt de airconditioner ingeschakeld. De eerste fase van elke regelgeving is dus het controleren of de parameters aan de vereisten voldoen.

En aangezien verificatie een algoritme is, kunnen we dezelfde tools en tools gebruiken die we gebruiken om controleprogramma's te maken. Met de SimInTech-omgeving kunt u bijvoorbeeld projectpakketten maken die verschillende delen van het model bevatten, uitgevoerd in de vorm van afzonderlijke projecten (objectmodel, besturingssysteemmodel, omgevingsmodel, etc.).

Het vereistenverificatieproject wordt in dit geval hetzelfde algoritmeproject en is verbonden met het modelpakket. En in de dynamische modelleringsmodus voert het een analyse uit om te voldoen aan de vereisten van de technische specificaties.

Een mogelijk voorbeeld van een systeemontwerp wordt getoond in Figuur 1.

Figuur 1. Voorbeeld van ontwerp van een verificatieproject.

Net als bij besturingsalgoritmen kunnen eisen worden opgesteld als een set bladen. Voor het gemak van het werken met algoritmen in structurele modelleringsomgevingen zoals SimInTech, Simulink, AmeSim, wordt de mogelijkheid gebruikt om structuren op meerdere niveaus te creëren in de vorm van submodellen. Deze organisatie maakt het mogelijk om verschillende vereisten in sets te groeperen om het werk met een reeks vereisten te vereenvoudigen, zoals wordt gedaan voor besturingsalgoritmen (zie figuur 2).

Figuur 2. Hiërarchische structuur van het vereistenverificatiemodel.

Zo worden in het onderhavige geval twee groepen onderscheiden: eisen aan de omgeving en eisen direct aan het systeem. Daarom wordt een datastructuur op twee niveaus gebruikt: twee groepen, die elk een blad van het algoritme vormen.

Om gegevens aan het model te koppelen, wordt een standaardschema voor het genereren van een signaaldatabase gebruikt, waarin gegevens worden opgeslagen voor uitwisseling tussen delen van het project.

Bij het maken en testen van software worden de meetwaarden van sensoren (analogen van echte systeemsensoren) die door het besturingssysteem worden gebruikt in deze database geplaatst.
Bij een testproject kunnen alle in het dynamische model berekende parameters in dezelfde database worden opgeslagen en zo worden gebruikt om te controleren of aan de eisen wordt voldaan.

In dit geval kan het dynamische model zelf worden uitgevoerd in elk wiskundig modelleringssysteem of zelfs in de vorm van een uitvoerbaar programma. De enige vereiste is de aanwezigheid van software-interfaces voor het verstrekken van modelgegevens aan de externe omgeving.

Figuur 3. Het verificatieproject verbinden met het complexe model.

Een voorbeeld van een verificatieblad voor basisvereisten wordt weergegeven in Figuur 4. Vanuit het perspectief van de ontwikkelaar is het een conventioneel rekendiagram waarop het algoritme voor verificatie van de vereisten grafisch wordt weergegeven.

Figuur 4. Controleblad vereisten.

De belangrijkste onderdelen van het controleblad worden beschreven in figuur 5. Het controlealgoritme is op dezelfde manier gevormd als de ontwerpdiagrammen van besturingsalgoritmen. Aan de rechterkant bevindt zich een blok voor het lezen van signalen uit de database. Dit blok heeft tijdens de simulatie toegang tot de signaaldatabase.

De ontvangen signalen worden geanalyseerd om de vereistenverificatievoorwaarden te berekenen. In dit geval wordt een hoogteanalyse uitgevoerd om de positie van het vliegtuig te bepalen (ongeacht of het geparkeerd staat of tijdens de vlucht). Voor dit doel kunt u andere signalen en berekende parameters van het model gebruiken.

De verificatievoorwaarden en parameters die worden gecontroleerd, worden overgebracht naar standaard verificatieblokken, waarin deze parameters worden geanalyseerd op naleving van de gespecificeerde eisen. De resultaten worden zodanig vastgelegd in de signalendatabase dat ze gebruikt kunnen worden om automatisch een checklist te genereren.

Figuur 5. Structuur van het rekenblad voor de verificatie van de vereisten.

De te testen parameters maken niet noodzakelijkerwijs gebruik van signalen in de database, die worden bestuurd door parameters die tijdens het simulatieproces zijn berekend. Niets weerhoudt ons ervan om in het kader van de ontwerpeisen aanvullende berekeningen uit te voeren, net zoals wij de verificatievoorwaarden berekenen.

Deze vereiste is bijvoorbeeld:

Het aantal activeringen van het correctiesysteem tijdens de vlucht naar het doel mag niet groter zijn dan 5, en de totale bedrijfstijd van het correctiesysteem mag niet langer zijn dan 30 seconden.

In dit geval wordt een algoritme voor het tellen van het aantal starts en de totale bedrijfstijd toegevoegd aan het ontwerpdiagram van de vereisten.

Typisch verificatieblok voor vereisten.

Elk selectievakje voor standaardvereisten is ontworpen om de vervulling van een vereiste van een bepaald type te berekenen. De milieuvereisten omvatten bijvoorbeeld een reeks omgevingstemperaturen tijdens het parkeren en tijdens de vlucht. Dit blok moet de luchttemperatuur in het model als parameter ontvangen en bepalen of deze parameter het opgegeven temperatuurbereik dekt./p>

Het blok bevat twee invoerpoorten, param en condition.

De eerste wordt gevoed met de parameter die wordt gecontroleerd. In dit geval “Externe temperatuur”.

Er wordt een Booleaanse variabele aan de tweede poort geleverd: de voorwaarde voor het uitvoeren van de controle.

Als TRUE (1) wordt ontvangen op de tweede ingang, voert het blok een berekening van de vereisteverificatie uit.

Als de tweede ingang FALSE (0) ontvangt, wordt niet aan de testvoorwaarden voldaan. Dit is nodig om rekening te kunnen houden met de berekeningsvoorwaarden. In ons geval wordt deze invoer gebruikt om de controle in of uit te schakelen, afhankelijk van de status van het model. Als het vliegtuig zich tijdens de simulatie op de grond bevindt, worden de vereisten met betrekking tot de vlucht niet gecontroleerd, en omgekeerd: als het vliegtuig aan het vliegen is, worden de vereisten met betrekking tot de werking op standplaats niet gecontroleerd.

Deze input kan ook gebruikt worden bij het opzetten van het model, bijvoorbeeld in de beginfase van de berekening. Wanneer het model in de gewenste staat wordt gebracht, worden de controleblokken uitgeschakeld, maar zodra het systeem de gewenste bedrijfsmodus bereikt, worden de controleblokken ingeschakeld.

De parameters van dit blok zijn:

• randvoorwaarden: bovenste (UpLimit) en onderste (DownLimit) bereikgrenzen die moeten worden gecontroleerd;
• vereiste systeemblootstellingstijd op de grensbereiken (TimeInterval) in seconden;
• Aanvraag-ID ReqName;
• toelaatbaarheid van het overschrijden van het bereik Out_range is een Booleaanse variabele die bepaalt of een waarde die het gecontroleerde bereik overschrijdt een overtreding van de vereiste is.

In sommige gevallen geeft de uitvoer van de testwaarde aan dat het systeem enige marge heeft en mogelijk buiten het werkingsbereik werkt. In andere gevallen betekent een uitgang dat het systeem de setpoints niet binnen bereik kan houden.

Figuur 6. Een typisch eigenschapscontroleblok in het diagram en zijn parameters.

Als resultaat van de berekening van dit blok wordt aan de uitgang de resultaatvariabele gevormd, die de volgende waarden aanneemt:

• 0 – rNone, waarde niet gedefinieerd;
• 1 – rGereed, aan de vereiste is voldaan;
• 2 – rFault, er is niet voldaan aan de vereiste.

De blokafbeelding bevat:

• identificatietekst;
• digitale displays van meetlimietparameters;
• kleuridentificatie van de parameterstatus.

Binnen het blok kan zich een tamelijk complex logisch gevolgtrekkingscircuit bevinden.

Om bijvoorbeeld het bedrijfstemperatuurbereik van de unit, weergegeven in Afbeelding 6, te controleren, wordt het interne circuit weergegeven in Afbeelding 7.

Figuur 7. Intern diagram van de eenheid voor het bepalen van het temperatuurbereik.

Binnen het circuitblok worden de eigenschappen gebruikt die zijn gespecificeerd in de blokparameters.
Naast het analyseren van de naleving van de vereisten, bevat het interne diagram van het blok een grafiek die nodig is voor het weergeven van de simulatieresultaten. Deze grafiek kan zowel worden gebruikt voor het bekijken tijdens de berekening als voor het analyseren van de resultaten na de berekening.

De berekeningsresultaten worden naar de uitvoer van het blok verzonden en tegelijkertijd vastgelegd in een algemeen rapportbestand, dat wordt aangemaakt op basis van de resultaten voor het hele project. (zie afb. 8)

Een voorbeeld van een rapport dat is gemaakt op basis van de simulatieresultaten is een HTML-bestand dat is gemaakt volgens een bepaald formaat. Het formaat kan willekeurig worden geconfigureerd volgens het formaat dat door een bepaalde organisatie wordt geaccepteerd.

Binnen het circuitblok worden de eigenschappen gebruikt die zijn gespecificeerd in de blokparameters.
Naast het analyseren van de naleving van de vereisten, bevat het interne diagram van het blok een grafiek die nodig is voor het weergeven van de simulatieresultaten. Deze grafiek kan zowel worden gebruikt voor het bekijken tijdens de berekening als voor het analyseren van de resultaten na de berekening.

De berekeningsresultaten worden naar de uitvoer van het blok verzonden en tegelijkertijd vastgelegd in een algemeen rapportbestand, dat wordt aangemaakt op basis van de resultaten voor het hele project. (zie afb. 8)

Een voorbeeld van een rapport dat is gemaakt op basis van de simulatieresultaten is een HTML-bestand dat is gemaakt volgens een bepaald formaat. Het formaat kan willekeurig worden geconfigureerd volgens het formaat dat door een bepaalde organisatie wordt geaccepteerd.

Figuur 8. Voorbeeld van een rapportbestand op basis van simulatieresultaten.

In dit voorbeeld wordt het rapportformulier rechtstreeks in de projecteigenschappen geconfigureerd en wordt het formaat in de tabel ingesteld als globale projectsignalen. In dit geval lost SimInTech zelf het probleem van het opzetten van het rapport op, en het blok voor het schrijven van resultaten naar een bestand gebruikt deze regels om naar het rapportbestand te schrijven.

Figuur 9. Het rapportformaat instellen in globale projectsignalen

Gebruik van een signaaldatabase voor vereisten.

Om het werken met eigenschapsinstellingen te automatiseren, wordt voor elk typisch blok een standaardstructuur in de signaaldatabase gemaakt. (zie afb. 10)

Figuur 10. Voorbeeld van de structuur van een vereistecontroleblok in een signaaldatabase.

Signaaldatabase biedt:

• Opslaan van alle noodzakelijke systeemvereistenparameters.
• Gemakkelijk bekijken van bestaande projectvereisten op basis van gespecificeerde parameters en huidige modelleringsresultaten.
• Eén blok of een groep blokken instellen met behulp van een scriptprogrammeertaal. Veranderingen in de signaaldatabase leiden tot veranderingen in de blokeigenschapswaarden in het diagram.
• Opslaan van tekstbeschrijvingen, koppelingen naar technische specificaties of identificatiegegevens in het eisenbeheersysteem.

Signaaldatabasestructuren voor vereisten kunnen eenvoudig worden geconfigureerd om te werken met een vereistenbeheersysteem van derden. Een algemeen diagram van de interactie met vereistenbeheersystemen wordt weergegeven in Figuur 11.

Figuur 11. Diagram van interactie met het eisenbeheersysteem.

De volgorde van interactie tussen het SimInTech-testproject en het eisenbeheersysteem is als volgt:

1. De taakomschrijving is onderverdeeld in eisen.
2. De eisen van de technische specificaties worden geïdentificeerd die kunnen worden geverifieerd door wiskundige modellering van technische processen.
3. Attributen van de geselecteerde vereisten worden overgebracht naar de SimInTech-signaaldatabase in de structuur van standaardblokken (bijvoorbeeld maximale en minimale temperatuur).
4. Tijdens het berekeningsproces worden structuurgegevens overgebracht naar blokontwerpdiagrammen, analyses uitgevoerd en de resultaten opgeslagen in een signaaldatabase.
5. Zodra de berekening is voltooid, worden de analyseresultaten overgebracht naar het eisenbeheersysteem.

De eisenstappen 3 tot en met 5 kunnen tijdens het ontwerpproces worden herhaald wanneer er wijzigingen in het ontwerp en/of de eisen optreden en de impact van de wijzigingen opnieuw moet worden getest.

Conclusies.

• Het gemaakte prototype van het systeem zorgt voor een aanzienlijke vermindering van de analysetijd van bestaande modellen om te voldoen aan de eisen van de technische specificaties.
• De voorgestelde testtechnologie maakt gebruik van reeds bestaande dynamische modellen en kan zelfs voor alle dynamische modellen worden gebruikt, inclusief modellen die niet in de SimInTech-omgeving worden uitgevoerd.
• Door batchgegevensorganisatie te gebruiken, kunt u pakketten voor verificatie van vereisten creëren parallel aan de modelontwikkeling, of deze pakketten zelfs gebruiken als technische specificaties voor modelontwikkeling.
• De technologie kan zonder noemenswaardige kosten worden geïntegreerd met bestaande eisenbeheersystemen.

Voor degenen die tot het einde lezen, link naar een video die laat zien hoe het prototype werkt.

Bron: www.habr.com