{"id":41257,"date":"2020-02-06T20:43:44","date_gmt":"2020-02-06T17:43:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya"},"modified":"2020-02-06T20:43:44","modified_gmt":"2020-02-06T17:43:44","slug":"avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya","title":{"rendered":"Automatische controle van de vereisten van het technisch ontwerp tijdens dynamische modellering","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Laten we dit onderwerp voortzetten <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466215\/\">\u00abWat zijn uw bewijzen?\u00bb<\/a><\/noindex>, laten we het probleem van wiskundige modellering vanuit een ander perspectief bekijken. Nadat we hebben vastgesteld dat het model overeenkomt met de rauwe realiteit, kunnen we de belangrijkste vraag beantwoorden: \u00abwat hebben we hier eigenlijk?\u00bb Bij het cre\u00ebren van een model van een technisch object willen we doorgaans zeker weten dat dit object aan onze verwachtingen voldoet. Daarom worden dynamische berekeningen van processen uitgevoerd en worden de resultaten vergeleken met de vereisten. Dit is de digitale tweeling, het virtuele prototype en meer, trendy termen die in de ontwerpfase het probleem oplossen van hoe we krijgen wat we gepland hebben.<\/p>\n<p><\/p>\n<p>Hoe kunnen we snel bevestigen dat ons systeem precies is wat we ontwerpen, zal het vliegen of zal het drijven, onze constructie? En als het vliegt, hoe hoog dan? En als het drijft, hoe diep dan?<\/p>\n<p>\n<img decoding=\"async\" alt=\"Automatische controle van de vereisten van het technisch ontwerp tijdens dynamische modellering\" src=\"\/wp-content\/uploads\/2020\/02\/e26c4b7db4ee148c73586124dacb6025.jpg\" style=\"display:block;margin: 0 auto;\" \/><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>In dit artikel wordt de automatisering van het controleren van de naleving van de technische vereisten bij het maken van dynamische modellen van technische systemen besproken. Laten we als voorbeeld een element uit de technische specificaties voor een luchtkoelsysteem van een luchtvaartuig bekijken.<\/p>\n<p><\/p>\n<p>We bekijken die vereisten die numeriek kunnen worden uitgedrukt en wiskundig kunnen worden gecontroleerd op basis van een specifiek rekenschema. Het is duidelijk dat dit slechts een deel is van de algemene vereisten voor elk technisch systeem, maar aan hun controle besteden we de tijd, zenuwen en geld voor het cre\u00ebren van dynamische modellen van het object.<\/p>\n<p><\/p>\n<p>Bij het beschrijven van technische vereisten in documentvorm kunnen verschillende soorten vereisten worden onderscheiden, elk met verschillende benaderingen voor het vormen van automatische controles van de naleving van de vereisten.<\/p>\n<p><\/p>\n<p>Bijvoorbeeld, laten we eens kijken naar zo'n klein, maar echt stel vereisten:<\/p>\n<p>\n<i><\/p>\n<ol>\n<li> Temperatuur van de buitenlucht bij de ingang van het koelsysteem:<br \/>\nbij stilstand - van min 35 tot 35 \u00baC,<br \/>\nin de lucht - van min 35 tot 39 \u00baC.<\/li>\n<li> Statisch luchtdruk in de lucht - van 700 tot 1013 hPa (van 526 tot 760 mm Hg).<\/li>\n<li> Totale luchtdruk bij de ingang van de luchtinlaat van het koelsysteem in de lucht - van 754 tot 1200 hPa (van 566 tot 1050 mm Hg).<\/li>\n<li> Temperatuur van de koel lucht:<br \/>\nbij stilstand - niet meer dan 27 \u00baC, voor technische blokken - niet meer dan 29 \u00baC,<br \/>\nin de lucht - niet meer dan 25 \u00baC, voor technische blokken - niet meer dan 27 \u00baC.<\/li>\n<li> Verbruik van koel lucht:<br \/>\nbij stilstand - niet minder dan 708 kg\/u,<br \/>\nin de lucht - niet minder dan 660 kg\/u.<\/li>\n<li> De temperatuur van de lucht in de instrumentenruimtes mag niet hoger zijn dan 60 \u00baC.<\/li>\n<li> De hoeveelheid fijnverdeelde vrije vochtigheid in de koel lucht mag niet meer zijn dan 2 g\/kg droge lucht.<\/li>\n<\/ol>\n<p> <\/i><\/p>\n<p>Zelfs binnen deze beperkte set van eisen kunnen we ten minste twee categorie\u00ebn onderscheiden die op verschillende manieren in het systeem moeten worden behandeld:<\/p>\n<p><\/p>\n<ul>\n<li> eisen voor de operationele omstandigheden van het systeem (punten 1-3);<\/li>\n<li> parameter eisen voor het systeem (punten 3-7).<\/li>\n<\/ul>\n<p><\/p>\n<p><i>Eisen voor de operationele omstandigheden van het systeem<\/i><br \/>\nExterne omstandigheden voor het te ontwikkelen systeem kunnen tijdens de modellering worden ingesteld als randvoorwaarden, of als resultaat van het functioneren van het algemene systeem.<br \/>\nBij dynamische modellering moet worden verzekerd dat de opgegeven werkmodi worden gedekt door het modelleerproces.<\/p>\n<p><\/p>\n<p><i>Parameter eisen voor het systeem <\/i><br \/>\nDeze eisen zijn parameters die door het systeem zelf worden geboden. Tijdens de modellering kunnen we deze parameters verkrijgen als resultaten van berekeningen en verifi\u00ebren of de eisen in elke specifieke berekening worden nageleefd.<\/p>\n<p><\/p>\n<h3>Identificatie en codering van eisen<\/h3>\n<p><\/p>\n<p>Voor het gemak van het werken met eisen raden bestaande normen aan om een identificatienummer toe te wijzen aan elke eis. Bij het toewijzen van identificatienummers is het zeer wenselijk om een uniform coderingssysteem te gebruiken. <\/p>\n<p><\/p>\n<p>De code voor de eis kan eenvoudig een getal zijn dat het volgnummer van de eis aangeeft, maar kan ook een code bevatten voor het type eis, de code van het systeem of het aggregaat waarvoor deze geldt, de code van de parameter, de locatiecode en nog veel meer dat een ingenieur zich kan voorstellen. (Voorbeeld van codering zie het artikel)<\/p>\n<p><\/p>\n<p>Tabel 1 geeft een eenvoudig voorbeeld van de codering van eisen.<\/p>\n<p><\/p>\n<ol>\n<li> code van de bron van eisen R - eisen van het technisch ontwerp; <\/li>\n<li> code van het type eisen E - eisen - parameters van de externe omgeving, of operationele omstandigheden<br \/>\n S - eisen die door het systeem worden geboden;<\/li>\n<li> code van de toestand van het vliegtuig 0 - elke, G - stilstaand, F - in de lucht;<\/li>\n<li> code van het type fysieke parameters T - temperatuur, P - druk, G - verbruik, vochtigheid H;<\/li>\n<li> volgnummer van de eis.<\/li>\n<\/ol>\n<p><\/p>\n<table>\n<tr>\n<td><b>ID<br \/>\nVereisten<\/b><\/td>\n<td><b>Omschrijving<\/b><\/td>\n<td><b>Parameter<\/b><\/td>\n<\/tr>\n<tr>\n<td>REGT01<\/td>\n<td>De temperatuur van de omgevingslucht aan de ingang van het SVO: op de grond \u2014 van min 35 \u00baC tot 35 \u00baC.<\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td>REFT01<\/td>\n<td>De temperatuur van de omgevingslucht aan de ingang van het SVO: in de lucht \u2014 van min 35 \u00baC tot 39 \u00baC.<\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>REFP01<\/td>\n<td>De statische druk van de omgevingslucht in de lucht van 700 tot 1013 hPa (van 526 tot 760 mm Hg).<\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>REFP02<\/td>\n<td>De totale luchtdruk aan de ingang van de luchtinlaat van het SVO in de lucht van 754 tot 1200 hPa (van 566 tot 1050 mm Hg).<\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSGT01<\/td>\n<td>De temperatuur van de koellucht: op de grond maximaal 27 \u00baC. <\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSGT02<\/td>\n<td>De temperatuur van de koellucht: op de grond, voor technische blokken maximaal 29 \u00baC. <\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSFT01<\/td>\n<td>De temperatuur van de koellucht in de lucht maximaal 25 \u00baC. <\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSFT02<\/td>\n<td>De temperatuur van de koellucht: in de lucht, voor technische blokken maximaal 27 \u00baC. <\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSGG01<\/td>\n<td>Het verbruik van koellucht: op de grond minimaal 708 kg\/uur.<\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSFG01<\/td>\n<td>Het verbruik van koellucht: in de lucht minimaal 660 kg\/uur.<\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RS0T01<\/td>\n<td>De temperatuur van de lucht in de instrumentencompartimenten maximaal 60 \u00baC. <\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSH01<\/td>\n<td>De hoeveelheid fijne vrije vochtigheid in de koellucht maximaal 2 g\/kg droge lucht.<\/td>\n<td> <\/td>\n<\/tr>\n<\/table>\n<p><\/p>\n<h3>Project van het systeem voor eisencontrole.<\/h3>\n<p><\/p>\n<p>Voor elke berekende eis is er een algoritme voor de beoordeling van de overeenstemming van de berekende parameters met de in de eis gedefinieerde parameters. In grote lijnen bevat elk beheersysteem standaard altijd algoritmen voor eisencontrole. En zelfs elke regelgever heeft deze. Als de temperatuur buiten de grenzen komt, wordt de airconditioning ingeschakeld. Dus de eerste stap van elke regeling is het controleren van de overeenstemming van de parameters met de eis.<\/p>\n<p><\/p>\n<p>Aangezien controle een algoritme is, kunnen dezelfde middelen en tools worden gebruikt die we gebruiken voor het cre\u00ebren van beheerprogramma's. Bijvoorbeeld, de SimInTech-omgeving maakt het mogelijk om projectpakketten te cre\u00ebren die verschillende modelonderdelen bevatten, uitgevoerd als afzonderlijke projecten (model van het object, model van het beheersysteem, model van de omgeving, enz.).<\/p>\n<p><\/p>\n<p>Het project van de eisencontrole wordt in dit geval net zo'n algoritmenproject en wordt aangesloten op het modelpakket. En in de dynamische modeleringsmodus voert het een analyse uit van de overeenstemming met de eisen van de technische specificatie.<\/p>\n<p><\/p>\n<p>Een mogelijk voorbeeld van de opzet van het systeemproject is weergegeven in figuur 1.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Automatische controle van de vereisten van het technisch ontwerp tijdens dynamische modellering\" src=\"\/wp-content\/uploads\/2020\/02\/e57fda1fb5b835a6ac961639db2b1749.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 1. Voorbeeld van de opzet van het eisencontroleproject. <\/i><\/p>\n<p><\/p>\n<p>Even for control algorithms, requirements can be formatted as a set of sheets. To facilitate working with algorithms in structural modeling environments such as SimInTech, Simulink, and AmeSim, the capabilities of creating multi-level structures in the form of submodels are used. This organization allows for grouping various requirements into sets to simplify working with the requirements array, just as is done for control algorithms (see Fig. 2).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Automatische controle van de vereisten van het technisch ontwerp tijdens dynamische modellering\" src=\"\/wp-content\/uploads\/2020\/02\/726ad4d5df1975131e71fc8a14ce71fe.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figure 2. Hierarchical structure of the requirements verification model. <\/i><\/p>\n<p><\/p>\n<p>For example, in the case under consideration, two groups have been identified: requirements for the environment and requirements directly for the system. Therefore, a two-level data structure is used: two groups, each of which is a leaf of the algorithm.<\/p>\n<p><\/p>\n<p>To connect data to the model, a standard signal database formation scheme is used, which holds data for exchange between parts of the project.<\/p>\n<p><\/p>\n<p>During the creation and testing of software, readings from sensors (analogous to the real sensors of the system) are placed into this database, which are used by the control system.<br \/>\n For the testing project, any parameters calculated in the dynamic model can be saved in this same database and thereby be used to verify compliance with requirements.<\/p>\n<p>\nThe dynamic model itself in this case can be implemented in any mathematical modeling system or even as an executable program. The only requirement is the availability of programming interfaces for outputting modeling data to the external environment.<\/p>\n<p><img decoding=\"async\" alt=\"Automatische controle van de vereisten van het technisch ontwerp tijdens dynamische modellering\" src=\"\/wp-content\/uploads\/2020\/02\/ac56799b7a022325f72d0639cd85eba2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figure 3. Connecting the verification project to the comprehensive model. <\/i><\/p>\n<p><\/p>\n<p>An example of a basic requirements verification sheet is presented in Figure 4. From the developer's perspective, it represents a typical calculation scheme, where the algorithm for verifying requirements is graphically depicted.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Automatische controle van de vereisten van het technisch ontwerp tijdens dynamische modellering\" src=\"\/wp-content\/uploads\/2020\/02\/467f3217a65e0b4a1def034ce75c747e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figure 4. Requirements verification sheet. <\/i><\/p>\n<p><\/p>\n<p>The main parts of the verification sheet are described in Figure 5. The verification algorithm is formed similarly to the calculation schemes of control algorithms. On the right, there is a block for reading signals from the database. This block accesses the signal database during modeling.<\/p>\n<p><\/p>\n<p>De ontvangen signalen worden geanalyseerd om de voorwaarden voor verificatie van de vereisten te berekenen. In dit geval wordt de hoogte geanalyseerd om de positie van het vliegtuig te bepalen (of het zich op de grond of in de lucht bevindt). Voor dit doel kunnen ook andere signalen en berekende modelparameters worden gebruikt.<\/p>\n<p><\/p>\n<p>De verificatievoorwaarden en de te verifi\u00ebren parameters worden doorgegeven aan standaard verificatieblokken, waarin de gegevens van deze parameters worden geanalyseerd op overeenstemming met de vastgestelde vereisten. De resultaten worden in de signaaldatabase opgeslagen zodat ze gebruikt kunnen worden voor het automatisch genereren van een checklist.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Automatische controle van de vereisten van het technisch ontwerp tijdens dynamische modellering\" src=\"\/wp-content\/uploads\/2020\/02\/1aa7778f56190bf51c112e29eab8a13c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 5. Structuur van het verificatieblad.<\/i><\/p>\n<p><\/p>\n<p>Het is niet noodzakelijk om als te verifi\u00ebren parameters alleen de signalen te gebruiken die in de database zijn opgeslagen, die worden beheerd door parameters die in het modelleringproces worden berekend. Niets staat een projectteam in de weg om aanvullende berekeningen uit te voeren, zoals we de verificatievoorwaarden berekenen.<\/p>\n<p><\/p>\n<p>Bijvoorbeeld, een dergelijke vereiste:<\/p>\n<p><\/p>\n<p> <i>Het aantal inschakelingen van het correctiesysteem tijdens de vlucht naar het doel mag niet meer dan 5 keer zijn, en de totale werkduur van het correctiesysteem mag niet meer dan 30 seconden bedragen.<\/i><\/p>\n<p><\/p>\n<p>In dit geval wordt een telleralgoritme voor het aantal inschakelingen en de totale werkduur toegevoegd aan het berekeningsschema van het project voor de vereisten.<\/p>\n<p><\/p>\n<h3>Standaard verificatieblok voor vereisten.<\/h3>\n<p><\/p>\n<p>Elk standaard verificatieblok is bedoeld voor het berekenen van de vervulling van een specifiek type vereiste. Bijvoorbeeld, in de omgevingseisen komt een bereik van werktemperaturen van de omgevingslucht voor, zowel op de grond als in de lucht. Dit blok moet de luchttemperatuur in het model krijgen als parameter en vaststellen of deze parameter het opgegeven temperatuurgebied dekt.\n<\/p>\n<p>Het blok bevat twee ingangen, param en condition.<\/p>\n<p><\/p>\n<p>De eerste ontvangt de te verifi\u00ebren parameter. In dit geval 'Temperatuur van de externe omgeving'.<\/p>\n<p><\/p>\n<p>De tweede ingang ontvangt een booleaanse variabele \u2013 de voorwaarde voor het uitvoeren van de verificatie.<\/p>\n<p><\/p>\n<p>Als er TRUE (1) op de tweede ingang binnenkomt, wordt de verificatie van de vereiste uitgevoerd.<\/p>\n<p><\/p>\n<p>Als de tweede ingang FALSE (0) ontvangt, worden de controlevoorwaarden niet uitgevoerd. Dit is nodig om de rekenvoorwaarden in aanmerking te nemen. In ons geval wordt deze ingang gebruikt om de controle in of uit te schakelen afhankelijk van de toestand van het model. Als het luchtvaartuig tijdens de modellering op de grond is, worden de vliegerelatede vereisten niet gecontroleerd, en omgekeerd \u2013 als het luchtvaartuig in de lucht is, worden de vereisten die verband houden met de werking op de parkeerplaats niet gecontroleerd.<\/p>\n<p><\/p>\n<p>Deze ingang kan ook worden gebruikt bij het instellen van het model, bijvoorbeeld in de beginfase van de berekening. Wanneer het model in de vereiste toestand wordt gebracht, zijn de controleblokken uitgeschakeld, maar zodra het systeem in de vereiste werkmodus is, worden de controleblokken ingeschakeld.<\/p>\n<p><\/p>\n<p>De parameters van deze blok worden als volgt gedefinieerd:<\/p>\n<p><\/p>\n<ul>\n<li>grensvoorwaarden: de bovenste (UpLimit) en onderste (DownLimit) limieten van de bereiken die gecontroleerd moeten worden;<\/li>\n<li> de vereiste wachttijd van het systeem op de grensgebieden (TimeInterval) in seconden;<\/li>\n<li>de identificator van de eis ReqName;<\/li>\n<li>toegestaan overschrijding van het bereik Out_range \u2013 een booleaanse variabele die bepaalt of het een schending van de eis is als de waarde buiten het gecontroleerde bereik ligt.<\/li>\n<\/ul>\n<p><\/p>\n<p>In sommige gevallen betekent het overschrijden van de gecontroleerde waarde dat het systeem marge heeft en buiten het werkbereik kan functioneren. In andere gevallen betekent het overschrijden dat het systeem niet in staat is om de opgegeven parameters binnen het bereik te houden.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Automatische controle van de vereisten van het technisch ontwerp tijdens dynamische modellering\" src=\"\/wp-content\/uploads\/2020\/02\/3cd48fd6597d1ee11ecaea9931c3fbbb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 6. Typisch controleblok voor eigenschap in het schema en zijn parameters.<\/i><\/p>\n<p><\/p>\n<p>Als resultaat van de berekening van dit blok wordt de variabele Result aan de uitgang gevormd, die de volgende waarden aanneemt:<\/p>\n<p><\/p>\n<ul>\n<li>0 \u2013 rNone, waarde is niet gedefinieerd;<\/li>\n<li>1 \u2013 rDone, eis wordt vervuld;<\/li>\n<li>2 \u2013 rFault, eis wordt niet vervuld.<\/li>\n<\/ul>\n<p><\/p>\n<p>De afbeelding van het blok bevat:<\/p>\n<p><\/p>\n<ul>\n<li> de tekst van de identificator;<\/li>\n<li> digitale weergaven van de parameters van de meetlimieten;<\/li>\n<li> kleuridentificator van de status van de parameter.<\/li>\n<\/ul>\n<p><\/p>\n<p>Binnen het blok kan een vrij complexe logische afleidingsschema aanwezig zijn.<\/p>\n<p>Bijvoorbeeld, voor de controle van het werkbare temperatuurbereik van het blok dat in figuur 6 wordt getoond, wordt het interne schema gepresenteerd in figuur 7.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Automatische controle van de vereisten van het technisch ontwerp tijdens dynamische modellering\" src=\"\/wp-content\/uploads\/2020\/02\/9ce085c82417fdbc5230056de37af65a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 7. Intern schema van het temperatuur bereikbepalingsblok.<\/i><\/p>\n<p><\/p>\n<p>Binnen het blok worden eigenschappen gebruikt die in de parameters van het blok zijn gedefinieerd.<br \/>\nNaast de analyse van de vereisten bevat het interne schema van de module een grafiek die nodig is om de resultaten van de simulatie weer te geven. Deze grafiek kan zowel tijdens de berekening worden bekeken als voor de analyse van de resultaten na de berekening.<\/p>\n<p><\/p>\n<p>De resultaten van de berekening worden naar de output van de module verzonden en tegelijkertijd geregistreerd in een algemeen rapportbestand, dat wordt aangemaakt op basis van de resultaten van het hele project. (zie fig. 8)<\/p>\n<p><\/p>\n<p>Een voorbeeld van een rapport, gemaakt op basis van de simulatie resultaten, is een html-bestand, dat is aangemaakt volgens een opgegeven indeling. Het formaat kan op willekeurige wijze worden aangepast aan het formaat dat in de specifieke organisatie is aangenomen.<\/p>\n<p><\/p>\n<p>Binnen het blok worden eigenschappen gebruikt die in de parameters van het blok zijn gedefinieerd.<br \/>\nNaast de analyse van de vereisten bevat het interne schema van de module een grafiek die nodig is om de resultaten van de simulatie weer te geven. Deze grafiek kan zowel tijdens de berekening worden bekeken als voor de analyse van de resultaten na de berekening.<\/p>\n<p><\/p>\n<p>De resultaten van de berekening worden naar de output van de module verzonden en tegelijkertijd geregistreerd in een algemeen rapportbestand, dat wordt aangemaakt op basis van de resultaten van het hele project. (zie fig. 8)<\/p>\n<p><\/p>\n<p>Een voorbeeld van een rapport, gemaakt op basis van de simulatie resultaten, is een html-bestand, dat is aangemaakt volgens een opgegeven indeling. Het formaat kan op willekeurige wijze worden aangepast aan het formaat dat in de specifieke organisatie is aangenomen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Automatische controle van de vereisten van het technisch ontwerp tijdens dynamische modellering\" src=\"\/wp-content\/uploads\/2020\/02\/8ff948417d799bce621e34c709154116.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 8. Voorbeeld van een rapportbestand op basis van de simulatie resultaten.<\/i><\/p>\n<p><\/p>\n<p>In dit voorbeeld wordt de indeling van het rapport direct ingesteld in de projectinstellingen, terwijl het formaat in de tabel wordt gedefinieerd als globale signalen van het project. In dit geval bepaalt SimInTech zelf de configuratie van het rapport, en de module voor het registreren van resultaten in een bestand gebruikt deze regels voor het schrijven naar het rapportbestand.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Automatische controle van de vereisten van het technisch ontwerp tijdens dynamische modellering\" src=\"\/wp-content\/uploads\/2020\/02\/bbe363bf1d81d00aebb67ca29a35811b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 9. Configuratie van het rapportformaat in de globale signalen van het project.<\/i><\/p>\n<p><\/p>\n<h3>Het gebruik van een signalendatabase voor de vereisten.<\/h3>\n<p><\/p>\n<p>Voor de automatisering van het werken met de instellingen van eigenschappen voor elke standaardmodule wordt een standaardstructuur in de signalendatabase aangemaakt. (zie fig. 10)<\/p>\n<\/p>\n<p><img decoding=\"async\" alt=\"Automatische controle van de vereisten van het technisch ontwerp tijdens dynamische modellering\" src=\"\/wp-content\/uploads\/2020\/02\/7e20a24ca5dadd2da6542325e964ec00.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 10. Voorbeeld van de structuur van de vereiste controlemodule in de signalendatabase.<\/i><\/p>\n<p><\/p>\n<p>De signalendatabase waarborgt:<\/p>\n<p><\/p>\n<ul>\n<li> Het opslaan van alle noodzakelijke parameters voor de vereisten aan het systeem.<\/li>\n<li> Een handige weergave van de bestaande vereisten in het project op basis van de opgegeven parameters en de actuele simulatie resultaten.<\/li>\n<li> De configuratie van \u00e9\u00e9n module, een groep modules met behulp van een programmeertaal. Wijzigingen in de signalendatabase leiden tot veranderingen in de waarden van de eigenschappen van de module op het schema.<\/li>\n<li> Het opslaan van tekstuele beschrijvingen, verwijzingen naar secties van de specificatie of identificaties in het systeem voor het beheer van vereisten.<\/li>\n<\/ul>\n<p><\/p>\n<p>De database-structuren voor vereisten kunnen eenvoudig worden ingesteld voor het werken met een extern systeem voor het beheer van vereisten. Het algemene interactieschema met vereistenbeheersystemen wordt weergegeven in figuur 11.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Automatische controle van de vereisten van het technisch ontwerp tijdens dynamische modellering\" src=\"\/wp-content\/uploads\/2020\/02\/3f6d67b8160255fd39d0d8bedf8be655.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 11. Schema van de interactie met het systeem voor het beheer van vereisten.<\/i><\/p>\n<p><\/p>\n<p>De interactievolgorde van het testproject SimInTech met het vereistebeheersystem is als volgt:<\/p>\n<p><\/p>\n<ol>\n<li> De technische opdracht wordt opgedeeld in vereisten.<\/li>\n<li> Vereisten uit de technische opdracht worden ge\u00efdentificeerd die kunnen worden gecontroleerd door middel van wiskundige modellering van technische processen.<\/li>\n<li> Attributen van de ge\u00efdentificeerde vereisten worden overgedragen aan de SimInTech-signaaldatabase in de structuur van standaardblokken (bijvoorbeeld maximale en minimale temperatuur).<\/li>\n<li> Tijdens de berekening worden de gegevens van de structuren overgedragen aan de berekeningsschema's van de blokken, wordt er een analyse uitgevoerd en worden de resultaten opgeslagen in de signaaldatabase.<\/li>\n<li> Na voltooiing van de berekening worden de analysemethoden naar het vereistebeheersysteem overgedragen.<\/li>\n<\/ol>\n<p><\/p>\n<p>De stappen 3 tot 5 in het werken met vereisten kunnen herhaald worden tijdens het ontwerpproces, wanneer er veranderingen in de constructie en\/of vereisten plaatsvinden, en er dus een hercontrole van de impact van de aangebrachte wijzigingen nodig is.<\/p>\n<p><\/p>\n<h3>VictoriaMetrics en Thanos pakken vergelijkbare problemen aan, maar op verschillende manieren:<\/h3>\n<p><\/p>\n<ul>\n<li> De gemaakte prototype van het systeem zorgt voor een significante verkorting van de tijd die nodig is voor de analyse van bestaande modellen met betrekking tot de eisen van de technische opdracht.<\/li>\n<li> De voorgestelde testtechnologie maakt gebruik van bestaande dynamische modellen en kan zelfs worden gebruikt voor andere dynamische modellen, ook diegene die niet in de SimInTech-omgeving zijn uitgevoerd.<\/li>\n<li> Het gebruik van batchgegevensorganisatie maakt het mogelijk om verificatiepakketten voor vereisten te cre\u00ebren, parallel aan de ontwikkeling van modellen, of zelfs deze pakketten te gebruiken als technische specificaties voor de ontwikkeling van modellen.<\/li>\n<li> De technologie kan zonder significante kosten ge\u00efntegreerd worden met bestaande vereistebeheersystemen.<\/li>\n<\/ul>\n<p><\/p>\n<p>Voor degenen die tot het einde hebben gelezen, <noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/be9qPox4AXk\">hier is de link naar de video met de demonstratie van het prototype.<\/a><\/noindex><\/p>\n<p>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/486336\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u044f \u0442\u0435\u043c\u0443 \u00ab\u041a\u0430\u043a\u0438\u0435 \u0432\u0430\u0448\u0438 \u0434\u043e\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u0430?\u00bb, \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u043d\u0430 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u043c\u0430\u0442\u0435\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0441 \u0434\u0440\u0443\u0433\u043e\u0439 \u0441\u0442\u043e\u0440\u043e\u043d\u044b. \u041f\u043e\u0441\u043b\u0435 \u0442\u043e\u0433\u043e \u043a\u0430\u043a \u043c\u044b \u0443\u0431\u0435\u0434\u0438\u043b\u0438\u0441\u044c, \u0447\u0442\u043e \u043c\u043e\u0434\u0435\u043b\u044c \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u0435\u0442 \u0441\u0435\u0440\u043c\u044f\u0436\u043d\u043e\u0439 \u043f\u0440\u0430\u0432\u0434\u0435 \u0436\u0438\u0437\u043d\u0438, \u043c\u043e\u0436\u043d\u043e \u043e\u0442\u0432\u0435\u0447\u0430\u0442\u044c \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0439 \u0432\u043e\u043f\u0440\u043e\u0441: \u00ab\u0430 \u0447\u0442\u043e, \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u043e, \u043c\u044b \u0442\u0443\u0442 \u0438\u043c\u0435\u0435\u043c?\u00bb. \u0421\u043e\u0437\u0434\u0430\u0432\u0430\u044f \u043c\u043e\u0434\u0435\u043b\u044c \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043e\u0431\u044a\u0435\u043a\u0442\u0430, \u043c\u044b, \u043a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e, \u0445\u043e\u0442\u0438\u043c \u0443\u0431\u0435\u0434\u0438\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u044d\u0442\u043e\u0442 \u043e\u0431\u044a\u0435\u043a\u0442 \u0431\u0443\u0434\u0435\u0442 \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u043e\u0432\u0430\u0442\u044c \u043d\u0430\u0448\u0438\u043c \u043e\u0436\u0438\u0434\u0430\u043d\u0438\u044f\u043c. \u0414\u043b\u044f \u044d\u0442\u043e\u0433\u043e \u0438 \u043f\u0440\u043e\u0432\u043e\u0434\u044f\u0442\u0441\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":41258,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-41257","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u044f \u0442\u0435\u043c\u0443 \u00ab\u041a\u0430\u043a\u0438\u0435 \u0432\u0430\u0448\u0438 \u0434\u043e\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u0430?\u00bb, \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u043d\u0430 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u043c\u0430\u0442\u0435\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0441 \u0434\u0440\u0443\u0433\u043e\u0439 \u0441\u0442\u043e\u0440\u043e\u043d\u044b.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/nl\/blog\/avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0430\u044f \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0430 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u0439 \u0422\u0417 \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u044f \u0442\u0435\u043c\u0443 \u00ab\u041a\u0430\u043a\u0438\u0435 \u0432\u0430\u0448\u0438 \u0434\u043e\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u0430?\u00bb, \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u043d\u0430 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u043c\u0430\u0442\u0435\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0441 \u0434\u0440\u0443\u0433\u043e\u0439 \u0441\u0442\u043e\u0440\u043e\u043d\u044b.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-02-06T17:43:44+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-06T17:43:44+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Automatische controle van de vereisten van de technische opdracht tijdens dynamische modellering | ProHoster","description":"Voortbouwend op het thema 'Wat zijn uw bewijzen?', bekijken we het probleem van wiskundige modellering vanuit een ander perspectief.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0430\u044f \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0430 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u0439 \u0422\u0417 \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f | ProHoster","og:description":"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u044f \u0442\u0435\u043c\u0443 \u00ab\u041a\u0430\u043a\u0438\u0435 \u0432\u0430\u0448\u0438 \u0434\u043e\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u0430?\u00bb, \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u043d\u0430 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u043c\u0430\u0442\u0435\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0441 \u0434\u0440\u0443\u0433\u043e\u0439 \u0441\u0442\u043e\u0440\u043e\u043d\u044b.","og:url":"https:\/\/prohoster.info\/nl\/blog\/avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-06T17:43:44+00:00","article:modified_time":"2020-02-06T17:43:44+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"41257","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:20:47","updated":"2022-10-01 02:07:44","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/41257","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=41257"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/41257\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/41258"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=41257"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=41257"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=41257"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}