Pagpapatuloy ng tema , tingnan natin ang problema ng mathematical modelling mula sa kabilang panig. Matapos nating kumbinsihin na ang modelo ay tumutugma sa homespun na katotohanan ng buhay, masasagot natin ang pangunahing tanong: "ano, eksakto, mayroon tayo dito?" Kapag gumagawa ng modelo ng isang teknikal na bagay, karaniwang gusto naming tiyakin na matutugunan ng bagay na ito ang aming mga inaasahan. Para sa layuning ito, ang mga dynamic na kalkulasyon ng mga proseso ay isinasagawa at ang resulta ay inihambing sa mga kinakailangan. Ito ay isang digital twin, isang virtual na prototype, atbp. mga naka-istilong maliliit na lalaki na, sa yugto ng disenyo, lutasin ang problema kung paano masigurado na makuha namin ang aming pinlano.
Paano natin mabilis na masisiguro na ang ating system ay eksakto kung ano ang ating idinisenyo, lilipad ba o lulutang ang ating disenyo? At kung lumipad, gaano kataas? At kung ito ay lumutang, gaano kalalim?
Tinatalakay ng artikulong ito ang automation ng pag-verify ng pagsunod sa mga kinakailangan ng isang teknikal na gusali kapag lumilikha ng mga dynamic na modelo ng mga teknikal na sistema. Bilang halimbawa, tingnan natin ang isang elemento ng teknikal na detalye para sa isang air cooling system ng sasakyang panghimpapawid.
Isinasaalang-alang namin ang mga kinakailangang iyon na maaaring ipahayag ayon sa numero at ma-verify sa matematika batay sa isang partikular na modelo ng pagkalkula. Malinaw na ito ay bahagi lamang ng mga pangkalahatang kinakailangan para sa anumang teknikal na sistema, ngunit ito ay sa pagsuri sa kanila na gumugugol tayo ng oras, nerbiyos at pera sa paglikha ng mga dynamic na modelo ng bagay.
Kapag naglalarawan ng mga teknikal na kinakailangan sa anyo ng isang dokumento, ang ilang mga uri ng iba't ibang mga kinakailangan ay maaaring makilala, ang bawat isa ay nangangailangan ng iba't ibang mga diskarte para sa pagbuo ng awtomatikong pag-verify ng katuparan ng mga kinakailangan.
Halimbawa, isaalang-alang itong maliit ngunit makatotohanang hanay ng mga kinakailangan:
- Temperatura ng hangin sa atmospera sa pasukan sa sistema ng paggamot ng tubig:
sa paradahan - mula minus 35 hanggang 35 ΒΊΠ‘,
sa paglipad - mula sa minus 35 hanggang 39 ΒΊΠ‘. - Ang static na presyon ng hangin sa atmospera sa paglipad ay mula 700 hanggang 1013 GPa (mula 526 hanggang 760 mm Hg).
- Ang kabuuang presyon ng hangin sa pasukan sa SVO air intake sa paglipad ay mula 754 hanggang 1200 GPa (mula 566 hanggang 1050 mm Hg).
- Temperatura ng paglamig ng hangin:
sa paradahan - hindi hihigit sa 27 ΒΊΠ‘, para sa mga teknikal na bloke - hindi hihigit sa 29 ΒΊΠ‘,
sa paglipad - hindi hihigit sa 25 ΒΊΠ‘, para sa mga teknikal na bloke - hindi hihigit sa 27 ΒΊΠ‘. - Pagpapalamig ng daloy ng hangin:
kapag naka-park - hindi bababa sa 708 kg/h,
sa paglipad - hindi bababa sa 660 kg/h. - Ang temperatura ng hangin sa mga compartment ng instrumento ay hindi hihigit sa 60 ΒΊΠ‘.
- Ang halaga ng fine free moisture sa cooling air ay hindi hihigit sa 2 g/kg ng dry air.
Kahit na sa loob ng limitadong hanay ng mga kinakailangan, mayroong hindi bababa sa dalawang kategorya na kailangang pangasiwaan nang iba sa system:
- mga kinakailangan para sa mga kondisyon ng operating ng system (mga sugnay 1-3);
- parametric na kinakailangan para sa system (mga sugnay 3-7).
Mga kinakailangan sa kondisyon ng operating system
Ang mga panlabas na kondisyon para sa system na binuo sa panahon ng pagmomodelo ay maaaring tukuyin bilang mga kondisyon ng hangganan o bilang isang resulta ng pagpapatakbo ng pangkalahatang sistema.
Sa dynamic na simulation, kinakailangan upang matiyak na ang tinukoy na mga kondisyon ng operating ay sakop ng proseso ng simulation.
Mga kinakailangan sa parametric system
Ang mga kinakailangang ito ay mga parameter na ibinigay ng system mismo. Sa panahon ng proseso ng pagmomodelo, maaari naming makuha ang mga parameter na ito bilang mga resulta ng pagkalkula at siguraduhin na ang mga kinakailangan ay natutugunan sa bawat partikular na pagkalkula.
Pagkilala sa mga kinakailangan at coding
Para sa kadalian ng pagtatrabaho sa mga kinakailangan, inirerekomenda ng mga kasalukuyang pamantayan na magtalaga ng isang identifier sa bawat kinakailangan. Kapag nagtatalaga ng mga identifier, lubos na kanais-nais na gumamit ng pinag-isang coding system.
Ang requirement code ay maaaring isang numero lamang na kumakatawan sa order number ng kinakailangan, o maaari itong maglaman ng code para sa uri ng kinakailangan, isang code para sa system o unit kung saan ito nalalapat, isang parameter code, isang code ng lokasyon, at kahit ano pang maisip ng engineer. (tingnan ang artikulo para sa paggamit ng encoding)
Ang talahanayan 1 ay nagbibigay ng isang simpleng halimbawa ng mga kinakailangan sa coding.
- code ng pinagmulan ng mga kinakailangan R-requirements TK;
- uri ng code ng mga kinakailangan E - mga kinakailangan - mga parameter ng kapaligiran, o mga kondisyon ng operating
S - mga kinakailangan na ibinigay ng system; - code ng katayuan ng sasakyang panghimpapawid 0 β anumang, G β naka-park, F β sa paglipad;
- code ng uri ng pisikal na parameter T - temperatura, P - presyon, G - rate ng daloy, halumigmig H;
- serial number ng kinakailangan.
| ID Kinakailangan sa |
ΠΠΏΠΈΡΠ°Π½ΠΈΠ΅ | Parametro |
| REGT01 | Ang temperatura ng ambient na hangin sa pasukan sa sistema ng paglamig ng tubig: sa paradahan - mula sa minus 35ΒΊΠ‘. hanggang 35 ΒΊΠ‘. | |
| REFT01 | Temperatura ng hangin sa atmospera sa pasukan sa sistema ng pagtatanggol ng hangin: sa paglipad - mula sa minus 35 ΒΊΠ‘ hanggang 39 ΒΊΠ‘. | |
| REFP01 | Ang static na atmospheric air pressure sa paglipad ay mula 700 hanggang 1013 hPa (mula 526 hanggang 760 mm Hg). | |
| REFP02 | Ang kabuuang presyon ng hangin sa pasukan sa SVO air intake sa paglipad ay mula 754 hanggang 1200 hPa (mula 566 hanggang 1050 mm Hg). | |
| RSGT01 | Temperatura ng paglamig ng hangin: kapag naka-park na hindi hihigit sa 27 ΒΊΠ‘ | |
| RSGT02 | Paglamig ng temperatura ng hangin: sa paradahan, para sa mga teknikal na yunit na hindi hihigit sa 29 ΒΊΠ‘ | |
| RSFT01 | Paglamig ng temperatura ng hangin sa paglipad na hindi hihigit sa 25 ΒΊΠ‘ | |
| RSFT02 | Paglamig ng temperatura ng hangin: sa paglipad, para sa mga teknikal na yunit na hindi hihigit sa 27 ΒΊΠ‘ | |
| RSGG01 | Pagpapalamig ng daloy ng hangin: kapag naka-park na hindi bababa sa 708 kg/h | |
| RSFG01 | Pagpapalamig ng daloy ng hangin: sa paglipad ng hindi bababa sa 660 kg/h | |
| RS0T01 | Ang temperatura ng hangin sa mga compartment ng instrumento ay hindi hihigit sa 60 ΒΊΠ‘ | |
| RSH01 | Ang halaga ng fine free moisture sa cooling air ay hindi hihigit sa 2 g/kg ng dry air |
Mga kinakailangan sa disenyo ng sistema ng pag-verify.
Para sa bawat kinakailangan sa disenyo mayroong isang algorithm para sa pagtatasa ng mga sulat ng mga parameter ng disenyo at ang mga parameter na tinukoy sa kinakailangan. Sa pangkalahatan, ang anumang control system ay palaging naglalaman ng mga algorithm para sa pagsuri ng mga kinakailangan bilang default. At kahit na anumang regulator ay naglalaman ng mga ito. Kung ang temperatura ay lumampas sa mga limitasyon, ang air conditioner ay bubukas. Kaya, ang unang yugto ng anumang regulasyon ay upang suriin kung ang mga parameter ay nakakatugon sa mga kinakailangan.
At dahil ang pag-verify ay isang algorithm, maaari naming gamitin ang parehong mga tool at tool na ginagamit namin upang lumikha ng mga control program. Halimbawa, pinapayagan ka ng kapaligiran ng SimInTech na lumikha ng mga pakete ng proyekto na naglalaman ng iba't ibang bahagi ng modelo, na isinasagawa sa anyo ng mga hiwalay na proyekto (modelo ng bagay, modelo ng control system, modelo ng kapaligiran, atbp.).
Ang proyekto sa pag-verify ng mga kinakailangan sa kasong ito ay nagiging parehong proyekto ng algorithm at nakakonekta sa pakete ng modelo. At sa dynamic na mode ng pagmomolde ay nagsasagawa ito ng pagsusuri para sa pagsunod sa mga kinakailangan ng mga teknikal na pagtutukoy.
Ang isang posibleng halimbawa ng disenyo ng system ay ipinapakita sa Figure 1.
Figure 1. Halimbawa ng disenyo ng isang verification project.
Tulad ng para sa mga algorithm ng kontrol, ang mga kinakailangan ay maaaring iguhit bilang isang hanay ng mga sheet. Para sa kaginhawaan ng pagtatrabaho sa mga algorithm sa mga kapaligiran sa pagmomolde ng istruktura tulad ng SimInTech, Simulink, AmeSim, ginagamit ang kakayahang lumikha ng mga multi-level na istruktura sa anyo ng mga submodel. Ginagawang posible ng organisasyong ito na igrupo ang iba't ibang mga kinakailangan sa mga set upang pasimplehin ang trabaho sa isang hanay ng mga kinakailangan, tulad ng ginagawa para sa mga algorithm ng kontrol (tingnan ang Fig. 2).
Figure 2. Hierarchical na istraktura ng modelo ng pag-verify ng mga kinakailangan.
Halimbawa, sa kasong isinasaalang-alang, dalawang grupo ang nakikilala: mga kinakailangan para sa kapaligiran at mga kinakailangan nang direkta para sa system. Samakatuwid, ang isang dalawang antas na istraktura ng data ay ginagamit: dalawang pangkat, ang bawat isa ay isang dahon ng algorithm.
Upang ikonekta ang data sa modelo, ang isang karaniwang pamamaraan para sa pagbuo ng isang database ng signal ay ginagamit, na nag-iimbak ng data para sa pagpapalitan sa pagitan ng mga bahagi ng proyekto.
Kapag lumilikha at sumusubok ng software, ang mga pagbabasa ng mga sensor (mga analog ng tunay na sensor ng system) na ginagamit ng control system ay inilalagay sa database na ito.
Para sa isang pagsubok na proyekto, anumang mga parameter na kinakalkula sa dynamic na modelo ay maaaring maimbak sa parehong database at sa gayon ay ginagamit upang suriin kung ang mga kinakailangan ay natutugunan.
Sa kasong ito, ang dynamic na modelo mismo ay maaaring isagawa sa anumang mathematical modeling system o kahit na sa anyo ng isang executable program. Ang tanging kinakailangan ay ang pagkakaroon ng mga interface ng software para sa pag-isyu ng data ng pagmomodelo sa panlabas na kapaligiran.
Figure 3. Pagkonekta sa proyekto ng pag-verify sa kumplikadong modelo.
Ang isang halimbawa ng isang pangunahing sheet ng pag-verify ng mga kinakailangan ay ipinakita sa Figure 4. Mula sa punto ng view ng developer, ito ay isang kumbensyonal na diagram ng pagkalkula kung saan ang algorithm ng pag-verify ng mga kinakailangan ay graphic na ipinakita.
Figure 4. Requirements check sheet.
Ang mga pangunahing bahagi ng check sheet ay inilarawan sa Figure 5. Ang check algorithm ay nabuo nang katulad sa mga diagram ng disenyo ng mga control algorithm. Sa kanang bahagi mayroong isang bloke para sa pagbabasa ng mga signal mula sa database. Ina-access ng block na ito ang database ng signal sa panahon ng simulation.
Ang mga natanggap na signal ay sinusuri upang kalkulahin ang mga kondisyon sa pag-verify ng mga kinakailangan. Sa kasong ito, isinasagawa ang pagsusuri sa altitude upang matukoy ang posisyon ng sasakyang panghimpapawid (kung ito ay nakaparada o nasa paglipad). Para sa layuning ito, maaari mong gamitin ang iba pang mga signal at kinakalkula na mga parameter ng modelo.
Ang mga kundisyon sa pag-verify at mga parameter na sinusuri ay inililipat sa mga karaniwang bloke ng pag-verify, kung saan ang mga parameter na ito ay sinusuri para sa pagsunod sa mga tinukoy na kinakailangan. Ang mga resulta ay naitala sa database ng signal sa paraang magagamit ang mga ito upang awtomatikong makabuo ng checklist.
Figure 5. Istraktura ng sheet ng pagkalkula ng pag-verify ng mga kinakailangan.
Ang mga parameter na susuriin ay hindi kinakailangang gumamit ng mga signal na nasa database, na kinokontrol ng mga parameter na kinakalkula sa panahon ng proseso ng simulation. Walang pumipigil sa amin na magsagawa ng mga karagdagang kalkulasyon sa loob ng balangkas ng mga kinakailangan sa draft, tulad ng pagkalkula namin ng mga kundisyon sa pag-verify.
Halimbawa, ang pangangailangang ito:
Ang bilang ng mga pag-activate ng sistema ng pagwawasto sa panahon ng paglipad patungo sa target ay hindi dapat lumampas sa 5, at ang kabuuang oras ng pagpapatakbo ng sistema ng pagwawasto ay hindi dapat lumampas sa 30 segundo.
Sa kasong ito, ang isang algorithm para sa pagkontra sa bilang ng mga pagsisimula at kabuuang oras ng pagpapatakbo ay idinagdag sa diagram ng disenyo ng mga kinakailangan.
Karaniwang block sa pag-verify ng mga kinakailangan.
Ang bawat check box ng karaniwang kinakailangan ay idinisenyo upang kalkulahin ang katuparan ng isang pangangailangan ng isang partikular na uri. Halimbawa, ang mga kinakailangan sa kapaligiran ay kinabibilangan ng isang hanay ng mga temperatura sa kapaligiran sa pagpapatakbo kapag nakaparada at nasa paglipad. Dapat matanggap ng bloke na ito ang temperatura ng hangin sa modelo bilang parameter at matukoy kung saklaw ng parameter na ito ang tinukoy na hanay ng temperatura./p>
Ang block ay naglalaman ng dalawang input port, param at kundisyon.
Ang una ay pinapakain ng parameter na sinusuri. Sa kasong ito, "Panlabas na temperatura".
Ang isang Boolean variable ay ibinibigay sa pangalawang port - ang kundisyon para sa pagsasagawa ng tseke.
Kung ang TRUE (1) ay natanggap sa pangalawang input, ang block ay nagsasagawa ng pagkalkula ng pag-verify ng kinakailangan.
Kung ang pangalawang input ay tumatanggap ng FALSE (0), kung gayon ang mga kondisyon ng pagsubok ay hindi natutugunan. Ito ay kinakailangan upang ang mga kondisyon ng pagkalkula ay maaaring isaalang-alang. Sa aming kaso, ang input na ito ay ginagamit upang paganahin o huwag paganahin ang check depende sa estado ng modelo. Kung ang sasakyang panghimpapawid ay nasa lupa sa panahon ng simulation, kung gayon ang mga kinakailangan na may kaugnayan sa paglipad ay hindi nasuri, at kabaliktaran - kung ang sasakyang panghimpapawid ay nasa paglipad, kung gayon ang mga kinakailangan na may kaugnayan sa operasyon sa stand ay hindi nasuri.
Ang input na ito ay maaari ding gamitin kapag nagse-set up ng modelo, halimbawa sa paunang yugto ng pagkalkula. Kapag ang modelo ay dinala sa kinakailangang estado, ang mga check block ay hindi pinagana, ngunit sa sandaling maabot ng system ang kinakailangang operating mode, ang mga check block ay naka-on.
Ang mga parameter ng bloke na ito ay:
- kundisyon ng hangganan: upper (UpLimit) at lower (DownLimit) na mga limitasyon sa hanay na dapat suriin;
- kinakailangang oras ng pagkakalantad ng system sa mga saklaw ng hangganan (TimeInterval) sa mga segundo;
- Request ID ReqName;
- Ang pagpapahintulot na lumampas sa hanay Ang Out_range ay isang Boolean na variable na tumutukoy kung ang isang halaga na lumampas sa nasuri na hanay ay isang paglabag sa kinakailangan.
Sa ilang mga kaso, ang output ng test value ay nagpapahiwatig na ang system ay may ilang margin at maaaring gumagana sa labas ng operating range nito. Sa ibang mga kaso, ang isang output ay nangangahulugan na ang system ay hindi mapanatili ang mga setpoint sa loob ng saklaw.
Figure 6. Isang tipikal na property check block sa diagram at mga parameter nito.
Bilang resulta ng pagkalkula ng bloke na ito, nabuo ang variable ng Resulta sa output, na kumukuha ng mga sumusunod na halaga:
- 0 β rWala, hindi tinukoy ang halaga;
- 1 β rTapos na, ang kinakailangan ay natutugunan;
- 2 - rFault, ang kinakailangan ay hindi natutugunan.
Ang block na imahe ay naglalaman ng:
- teksto ng pagkakakilanlan;
- mga digital na pagpapakita ng mga parameter ng limitasyon sa pagsukat;
- tagatukoy ng kulay ng katayuan ng parameter.
Sa loob ng bloke ay maaaring mayroong isang medyo kumplikadong lohikal na inference circuit.
Halimbawa, upang suriin ang saklaw ng operating temperatura ng unit na ipinapakita sa Figure 6, ang panloob na circuit ay ipinapakita sa Figure 7.
Figure 7. Panloob na diagram ng yunit ng pagpapasiya ng hanay ng temperatura.
Sa loob ng circuit block, ginagamit ang mga katangian na tinukoy sa mga parameter ng block.
Bilang karagdagan sa pagsusuri sa pagsunod sa mga kinakailangan, ang panloob na diagram ng bloke ay naglalaman ng isang graph na kinakailangan para sa pagpapakita ng mga resulta ng simulation. Ang graph na ito ay maaaring gamitin kapwa para sa pagtingin sa panahon ng pagkalkula at para sa pagsusuri ng mga resulta pagkatapos ng pagkalkula.
Ang mga resulta ng pagkalkula ay ipinadala sa output ng bloke at sabay-sabay na naitala sa isang pangkalahatang file ng ulat, na nilikha batay sa mga resulta para sa buong proyekto. (tingnan ang Fig. 8)
Ang isang halimbawa ng isang ulat na ginawa batay sa mga resulta ng simulation ay isang html file na ginawa ayon sa isang ibinigay na format. Ang format ay maaaring arbitraryong i-configure sa format na tinatanggap ng isang partikular na organisasyon.
Sa loob ng circuit block, ginagamit ang mga katangian na tinukoy sa mga parameter ng block.
Bilang karagdagan sa pagsusuri sa pagsunod sa mga kinakailangan, ang panloob na diagram ng bloke ay naglalaman ng isang graph na kinakailangan para sa pagpapakita ng mga resulta ng simulation. Ang graph na ito ay maaaring gamitin kapwa para sa pagtingin sa panahon ng pagkalkula at para sa pagsusuri ng mga resulta pagkatapos ng pagkalkula.
Ang mga resulta ng pagkalkula ay ipinadala sa output ng bloke at sabay-sabay na naitala sa isang pangkalahatang file ng ulat, na nilikha batay sa mga resulta para sa buong proyekto. (tingnan ang Fig. 8)
Ang isang halimbawa ng isang ulat na ginawa batay sa mga resulta ng simulation ay isang html file na ginawa ayon sa isang ibinigay na format. Ang format ay maaaring arbitraryong i-configure sa format na tinatanggap ng isang partikular na organisasyon.
Larawan 8. Halimbawa ng file ng ulat batay sa mga resulta ng simulation.
Sa halimbawang ito, ang form ng ulat ay direktang na-configure sa mga katangian ng proyekto, at ang format sa talahanayan ay itinakda bilang mga pandaigdigang signal ng proyekto. Sa kasong ito, nalulutas mismo ng SimInTech ang problema sa pag-set up ng ulat, at ang bloke para sa pagsusulat ng mga resulta sa isang file ay gumagamit ng mga linyang ito upang magsulat sa file ng ulat.
Figure 9. Pagtatakda ng format ng ulat sa mga signal ng pandaigdigang proyekto
Paggamit ng signal database para sa mga kinakailangan.
Upang i-automate ang trabaho sa mga setting ng ari-arian, isang karaniwang istraktura ang nilikha sa database ng signal para sa bawat karaniwang bloke. (tingnan ang Fig. 10)
Figure 10. Halimbawa ng istraktura ng isang block ng tseke ng kinakailangan sa isang database ng signal.
Nagbibigay ang database ng signal:
- Pag-iimbak ng lahat ng kinakailangang mga parameter ng kinakailangan ng system.
- Maginhawang pagtingin sa mga kasalukuyang kinakailangan ng proyekto mula sa mga tinukoy na parameter at kasalukuyang resulta ng pagmomodelo.
- Pagse-set up ng isang bloke o isang pangkat ng mga bloke gamit ang isang scripting programming language. Ang mga pagbabago sa database ng signal ay humantong sa mga pagbabago sa mga halaga ng pag-aari ng block sa diagram.
- Pag-iimbak ng mga paglalarawan ng teksto, mga link sa mga item sa teknikal na detalye o mga identifier sa system ng pamamahala ng mga kinakailangan.
Ang mga istruktura ng database ng signal para sa mga kinakailangan ay madaling mai-configure upang gumana sa isang third-party na sistema ng pamamahala ng mga kinakailangan. Ang isang pangkalahatang diagram ng pakikipag-ugnayan sa mga sistema ng pamamahala ng mga kinakailangan ay ipinakita sa Figure 11.
Figure 11. Diagram ng pakikipag-ugnayan sa sistema ng pamamahala ng mga kinakailangan.
Ang pagkakasunud-sunod ng pakikipag-ugnayan sa pagitan ng proyekto ng pagsubok ng SimInTech at ang kinakailangan na sistema ng kontrol ay ang mga sumusunod:
- Ang mga tuntunin ng sanggunian ay pinaghiwa-hiwalay sa mga kinakailangan.
- Ang mga kinakailangan ng mga teknikal na pagtutukoy ay natukoy na maaaring ma-verify sa pamamagitan ng matematikal na pagmomodelo ng mga teknikal na proseso.
- Ang mga katangian ng mga napiling kinakailangan ay inililipat sa database ng signal ng SimInTech sa istraktura ng mga karaniwang bloke (halimbawa, maximum at minimum na temperatura).
- Sa panahon ng proseso ng pagkalkula, ang data ng istraktura ay inililipat upang harangan ang mga diagram ng disenyo, isinasagawa ang pagsusuri at ang mga resulta ay iniimbak sa isang database ng signal.
- Kapag nakumpleto na ang pagkalkula, ang mga resulta ng pagsusuri ay ililipat sa sistema ng pamamahala ng mga kinakailangan.
Ang mga hakbang 3 hanggang 5 ng mga kinakailangan ay maaaring ulitin sa panahon ng proseso ng disenyo kapag naganap ang mga pagbabago sa disenyo at/o mga kinakailangan at ang epekto ng mga pagbabago ay kailangang muling suriin.
Mga konklusyon.
- Ang nilikha na prototype ng system ay nagbibigay ng isang makabuluhang pagbawas sa oras ng pagsusuri ng mga umiiral na modelo para sa pagsunod sa mga kinakailangan ng mga teknikal na pagtutukoy.
- Ang iminungkahing teknolohiya sa pagsubok ay gumagamit na ng mga umiiral nang dynamic na modelo at maaaring gamitin kahit para sa anumang mga dynamic na modelo, kabilang ang mga hindi ginanap sa SimInTech environment.
- Ang paggamit ng batch data organization ay nagbibigay-daan sa iyong lumikha ng mga kinakailangan sa pag-verify ng mga pakete kasabay ng pag-develop ng modelo, o kahit na gamitin ang mga paketeng ito bilang mga teknikal na detalye para sa pagbuo ng modelo.
- Ang teknolohiya ay maaaring isama sa mga umiiral na sistema ng pamamahala ng mga kinakailangan nang walang makabuluhang gastos.
Sa mga nagbabasa hanggang dulo,
Pinagmulan: www.habr.com