Динамик загварчлалын үед техникийн үзүүлэлтүүдийн шаардлагыг автоматаар баталгаажуулах

Сэдвийг үргэлжлүүлж байна "Таны нотлох баримт юу вэ?", математик загварчлалын асуудлыг нөгөө талаас нь авч үзье. Энэ загвар нь амьдралын жинхэнэ үнэнд нийцэж байгаа гэдэгт бид итгэлтэй болсны дараа "Бидэнд яг юу байгаа вэ?" гэсэн гол асуултанд хариулж чадна. Техникийн объектын загварыг бүтээхдээ бид ихэвчлэн энэ объект бидний хүлээлтийг хангана гэдэгт итгэлтэй байхыг хүсдэг. Энэ зорилгоор үйл явцын динамик тооцооллыг хийж, үр дүнг шаардлагуудтай харьцуулна. Энэ бол дижитал ихэр, виртуал прототип гэх мэт. Загвар зохион бүтээх шатандаа бидний төлөвлөсөн зүйлээ хэрхэн авах вэ гэдэг асуудлыг шийддэг загварлаг бяцхан залуус.

Манай систем яг бидний зохион бүтээсэнтэй яг таарч байгаа эсэхийг хэрхэн хурдан баталгаажуулах вэ, бидний дизайн нисэх үү эсвэл хөвөх үү? Хэрэв тэр нисдэг бол хэр өндөр вэ? Хэрэв энэ нь хөвж байвал хэр гүнзгий вэ?

Энэ нийтлэлд техникийн системийн динамик загварыг бий болгохдоо техникийн барилгын шаардлагад нийцэж байгаа эсэхийг шалгах автоматжуулалтыг авч үзэх болно. Жишээлбэл, агаарын хөлгийн агаарын хөргөлтийн системийн техникийн үзүүлэлтүүдийн нэг элементийг авч үзье.

Бид тодорхой тооцооллын загвар дээр үндэслэн тоогоор илэрхийлж, математикийн аргаар баталгаажуулж болох эдгээр шаардлагыг авч үздэг. Энэ нь аливаа техникийн системд тавигдах ерөнхий шаардлагуудын зөвхөн нэг хэсэг болох нь ойлгомжтой, гэхдээ бид объектын динамик загварыг бий болгоход цаг хугацаа, мэдрэл, мөнгө зарцуулдаг.

Техникийн шаардлагыг баримт бичгийн хэлбэрээр тайлбарлахдаа хэд хэдэн төрлийн өөр өөр шаардлагыг ялгаж салгаж болох бөгөөд тэдгээр нь тус бүр нь шаардлагын биелэлтийг автоматаар баталгаажуулах өөр өөр хандлагыг шаарддаг.

Жишээлбэл, энэ жижиг боловч бодитой шаардлагуудыг авч үзье.

1. Ус цэвэршүүлэх системийн үүдэнд байгаа атмосферийн агаарын температур:
   зогсоол дээр - хасах 35-аас 35 ºС хүртэл,
   нислэгийн үед - хасах 35-аас 39 ºС хүртэл.
2. Нислэгийн үед атмосферийн агаарын статик даралт 700-1013 ГПа (526-760 мм м.у.б) байна.
3. Нислэгийн үеэр SVO агаарын хэрэглээний орох хаалганы нийт агаарын даралт 754-1200 ГПа (566-1050 мм м.у.б) байна.
4. Хөргөх агаарын температур:
   зогсоол дээр - 27 ºС-аас ихгүй, техникийн блокуудын хувьд - 29 ºС-ээс ихгүй,
   нислэгийн үед - 25 ºС-ээс ихгүй, техникийн блокуудын хувьд - 27 ºС-ээс ихгүй байна.
5. Хөргөх агаарын урсгал:
   зогсоол дээр - дор хаяж 708 кг / цаг,
   нислэгийн үед - 660 кг / ц-ээс багагүй.
6. Багажны тасалгаан дахь агаарын температур 60 ºС-ээс ихгүй байна.
7. Хөргөх агаар дахь нарийн чөлөөт чийгийн хэмжээ нь хуурай агаарт 2 г / кг-аас ихгүй байна.

Энэхүү хязгаарлагдмал багц шаардлагын хүрээнд системд өөр өөр байдлаар хандах шаардлагатай дор хаяж хоёр ангилал байдаг:

• системийн үйл ажиллагааны нөхцөлд тавигдах шаардлага (1-3-р зүйл);
• системийн параметрийн шаардлага (3-7-р зүйл).

Системийн үйл ажиллагааны нөхцөлд тавигдах шаардлага
Загвар хийх явцад боловсруулж буй системийн гадаад нөхцөлийг хилийн нөхцөл эсвэл ерөнхий системийн үйл ажиллагааны үр дүнд тодорхойлж болно.
Динамик симуляцийн хувьд загварчлалын үйл явцад заасан үйлдлийн нөхцлүүд хамрагдсан эсэхийг баталгаажуулах шаардлагатай.

Параметрийн системийн шаардлага
Эдгээр шаардлагууд нь систем өөрөө өгсөн параметрүүд юм. Загвар хийх явцад бид эдгээр параметрүүдийг тооцооллын үр дүн болгон авч, тодорхой тооцоолол бүрд тавигдах шаардлагыг хангаж байгаа эсэхийг шалгах боломжтой.

Шаардлагыг тодорхойлох, кодлох

Шаардлагуудтай ажиллахад хялбар болгохын тулд одоо байгаа стандартууд нь шаардлага бүрт таних тэмдэг өгөхийг зөвлөж байна. Тодорхойлогчийг хуваарилахдаа нэгдсэн кодлох системийг ашиглах нь зүйтэй.

Шаардлагын код нь шаардлагын захиалгын дугаарыг илэрхийлэх энгийн тоо байж болно, эсвэл тухайн шаардлагын төрлийн код, түүнд хамаарах систем эсвэл нэгжийн код, параметрийн код, байршлын код, болон Инженер хүний ​​төсөөлж чадах өөр бүх зүйл. (кодчлолыг ашиглах нийтлэлийг үзнэ үү)

Хүснэгт 1-д шаардлагыг кодлох энгийн жишээг үзүүлэв.

1. шаардлагын эх үүсвэрийн код R-шаардлага TK;
2. шаардлагын код төрөл E - шаардлага - хүрээлэн буй орчны параметрүүд, эсвэл үйл ажиллагааны нөхцөл
   S - системээс өгсөн шаардлага;
3. онгоцны төлөвийн код 0 – дурын, G – зогсоолд, F – нислэгт;
4. физик параметрийн төрлийн код T – температур, P – даралт, G – урсгалын хурд, H чийгшил;
5. шаардлагын серийн дугаар.

ID шаардлага	Тайлбар	Үзүүлэлт
REGT01	Усан хөргөлтийн системд орох орчны агаарын температур: зогсоол дээр - хасах 35ºС-аас. 35 ºС хүртэл.
REFT01	Агаарын довтолгооноос хамгаалах системийн үүдэнд агаар мандлын агаарын температур: нислэгийн үед - хасах 35 ºС-аас 39 ºС хүртэл.
REFP01	Нислэгийн үед атмосферийн агаарын статик даралт 700-1013 гПа (526-760 мм м.у.б) байна.
REFP02	Нислэгийн үеэр SVO агаарын хэрэглээ рүү ороход агаарын нийт даралт 754-1200 гПа (566-1050 мм м.у.б) байна.
RSGT01	Хөргөх агаарын температур: зогсоол дээр 27 ºС-ээс ихгүй байна
RSGT02	Хөргөх агаарын температур: машины зогсоол дээр, техникийн хэсгүүдэд 29 ºС-ээс ихгүй байна
RSFT01	Нислэгийн үед хөргөх агаарын температур 25 ºС-ээс ихгүй байна
RSFT02	Хөргөх агаарын температур: нислэгийн үед, техникийн нэгжийн хувьд 27 ºС-ээс ихгүй байна
RSGG01	Хөргөх агаарын урсгал: зогсоол дээр 708 кг/цагаас багагүй
RSFG01	Хөргөх агаарын урсгал: нислэгийн үед 660 кг/цагаас багагүй
RS0T01	Багажны тасалгаан дахь агаарын температур 60 ºС-ээс ихгүй байна
RSH01	Хөргөх агаар дахь нарийн чөлөөт чийгийн хэмжээ нь хуурай агаарт 2 г / кг-аас ихгүй байна

Шаардлагыг баталгаажуулах системийн загвар.

Загварын шаардлага бүрийн хувьд дизайны параметрүүд болон шаардлагад заасан параметрүүдийн тохирлыг үнэлэх алгоритм байдаг. Ерөнхийдөө аливаа хяналтын систем нь анхдагч байдлаар шаардлагыг шалгах алгоритмуудыг үргэлж агуулдаг. Мөн ямар ч зохицуулагч ч гэсэн тэдгээрийг агуулдаг. Хэрэв температур хязгаараас хэтэрвэл агааржуулагч асна. Тиймээс аливаа зохицуулалтын эхний үе шат нь параметрүүд нь шаардлагад нийцэж байгаа эсэхийг шалгах явдал юм.

Баталгаажуулалт нь алгоритм учраас бид хяналтын программ үүсгэхэд ашигладаг ижил хэрэгсэл, хэрэгслийг ашиглаж болно. Жишээлбэл, SimInTech орчин нь тусдаа төслүүд (объект загвар, хяналтын системийн загвар, орчны загвар гэх мэт) хэлбэрээр гүйцэтгэсэн загварын янз бүрийн хэсгүүдийг агуулсан төслийн багцуудыг үүсгэх боломжийг олгодог.

Энэ тохиолдолд шаардлагыг баталгаажуулах төсөл нь ижил алгоритмын төсөл болж, загвар багцад холбогдсон байна. Динамик загварчлалын горимд энэ нь техникийн үзүүлэлтүүдийн шаардлагад нийцэж байгаа эсэхэд дүн шинжилгээ хийдэг.

Системийн дизайны боломжит жишээг 1-р зурагт үзүүлэв.

Зураг 1. Баталгаажуулах төслийн дизайны жишээ.

Хяналтын алгоритмын нэгэн адил шаардлагыг хуудасны багц хэлбэрээр гаргаж болно. SimInTech, Simulink, AmeSim зэрэг бүтцийн загварчлалын орчинд алгоритмтай ажиллахад хялбар болгохын тулд дэд загвар хэлбэрээр олон түвшний бүтцийг бий болгох чадварыг ашигладаг. Энэхүү зохион байгуулалт нь хяналтын алгоритмуудын нэгэн адил олон шаардлагын дагуу ажлыг хялбарчлахын тулд янз бүрийн шаардлагыг багц болгон бүлэглэх боломжийг олгодог (Зураг 2-ыг үз).

Зураг 2. Шаардлагыг баталгаажуулах загварын шаталсан бүтэц.

Жишээлбэл, хэлэлцэж буй тохиолдолд хүрээлэн буй орчинд тавигдах шаардлага, системд тавигдах шаардлага гэсэн хоёр бүлгийг ялгаж үздэг. Тиймээс хоёр түвшний өгөгдлийн бүтцийг ашигладаг: хоёр бүлэг, тус бүр нь алгоритмын хуудас юм.

Өгөгдлийг загварт холбохын тулд төслийн хэсгүүдийн хооронд солилцох зорилгоор өгөгдлийг хадгалдаг дохионы мэдээллийн сан үүсгэх стандарт схемийг ашигладаг.

Програм хангамжийг үүсгэх, туршихдаа хяналтын системд ашигладаг мэдрэгчийн уншилтыг (бодит системийн мэдрэгчийн аналог) энэ мэдээллийн санд байрлуулна.
Туршилтын төслийн хувьд динамик загварт тооцоолсон аливаа параметрүүдийг нэг мэдээллийн санд хадгалж, шаардлага хангасан эсэхийг шалгахад ашиглаж болно.

Энэ тохиолдолд динамик загвар нь өөрөө ямар ч математик загварчлалын системд эсвэл бүр гүйцэтгэх боломжтой програм хэлбэрээр ч хэрэгжиж болно. Цорын ганц шаардлага бол загварчлалын өгөгдлийг гадаад орчинд гаргах програм хангамжийн интерфейстэй байх явдал юм.

Зураг 3. Баталгаажуулах төслийг цогц загварт холбох.

Үндсэн шаардлагын баталгаажуулалтын хуудасны жишээг Зураг 4-т үзүүлэв. Хөгжүүлэгчийн үүднээс авч үзвэл энэ нь шаардлагыг баталгаажуулах алгоритмыг графикаар харуулсан ердийн тооцооны диаграмм юм.

Зураг 4. Шаардлагыг шалгах хуудас.

Хяналтын хуудасны үндсэн хэсгүүдийг Зураг 5-д дүрсэлсэн болно. Шалгалтын алгоритм нь хяналтын алгоритмуудын дизайны диаграммтай ижил төстэй байдлаар хийгдсэн. Баруун талд мэдээллийн сангаас дохио унших блок байдаг. Энэ блок симуляцийн үед дохионы мэдээллийн санд ханддаг.

Хүлээн авсан дохиог шинжилж, шаардлагыг баталгаажуулах нөхцлийг тооцдог. Энэ тохиолдолд агаарын хөлгийн байрлалыг (зогсоолд эсвэл нислэгт байгаа эсэх) тодорхойлохын тулд өндрийн шинжилгээ хийдэг. Энэ зорилгоор та бусад дохио, загварын тооцоолсон параметрүүдийг ашиглаж болно.

Шалгалтын нөхцөл, параметрүүдийг стандарт баталгаажуулалтын блокуудад шилжүүлж, эдгээр параметрүүдийг заасан шаардлагад нийцэж байгаа эсэхийг шинжлэх болно. Үр дүнг дохионы мэдээллийн санд бүртгэж автоматаар хяналтын хуудас үүсгэх боломжтой.

Зураг 5. Шаардлагын баталгаажуулалтын тооцооны хуудасны бүтэц.

Туршилт хийх параметрүүд нь мэдээллийн санд байгаа дохиог ашиглах шаардлагагүй бөгөөд симуляцийн явцад тооцоолсон параметрүүдээр хянагддаг. Баталгаажуулах нөхцлүүдийг тооцдог шиг бид төслийн шаардлагын хүрээнд нэмэлт тооцоо хийхэд юу ч саад болохгүй.

Жишээлбэл, энэ шаардлага:

Зорилтот руу нисэх үед залруулгын системийг идэвхжүүлэх тоо 5-аас хэтрэхгүй байх ёстой бөгөөд залруулгын системийн нийт ажиллах хугацаа 30 секундээс хэтрэхгүй байх ёстой.

Энэ тохиолдолд эхлэх тоо болон нийт ашиглалтын хугацааг эсэргүүцэх алгоритмыг шаардлагын дизайны диаграммд нэмж оруулсан болно.

Ердийн шаардлагыг баталгаажуулах блок.

Стандарт шаардлагыг шалгах хайрцаг бүр нь тодорхой төрлийн шаардлагын биелэлтийг тооцоолоход зориулагдсан. Жишээлбэл, хүрээлэн буй орчны шаардлагад зогсоол болон нислэгийн үед орчны ажлын температурын хүрээ багтдаг. Энэ блок нь загвар дахь агаарын температурыг параметр болгон хүлээн авах ёстой бөгөөд энэ параметр нь тогтоосон температурын хязгаарыг хамарч байгаа эсэхийг тодорхойлох ёстой./p>

Блок нь параметр ба нөхцөл гэсэн хоёр оролтын портыг агуулдаг.

Эхнийх нь шалгаж буй параметрээр тэжээгддэг. Энэ тохиолдолд "Гадаад температур".

Булийн хувьсагчийг хоёр дахь порт руу нийлүүлсэн - шалгалт хийх нөхцөл.

Хэрэв хоёр дахь оролт дээр ҮНЭН (1) хүлээн авбал блок нь шаардлагын баталгаажуулалтын тооцоог хийнэ.

Хэрэв хоёр дахь оролт нь ХУДАЛ (0) хүлээн авбал туршилтын нөхцөл хангагдаагүй болно. Тооцооллын нөхцлийг харгалзан үзэхийн тулд энэ нь зайлшгүй шаардлагатай. Манай тохиолдолд энэ оролт нь загварын төлөв байдлаас шалтгаалан чекийг идэвхжүүлэх эсвэл идэвхгүй болгоход ашиглагддаг. Хэрэв загварчлалын үеэр онгоц газар дээр байгаа бол нислэгтэй холбоотой шаардлагыг шалгахгүй, харин эсрэгээр - хэрэв онгоц нисч байгаа бол зогсоол дээр ажиллахтай холбоотой шаардлагыг шалгахгүй.

Энэ оролтыг жишээ нь тооцооллын эхний үе шатанд загварыг тохируулах үед ашиглаж болно. Загварыг шаардлагатай төлөвт оруулах үед шалгах блокууд идэвхгүй болох боловч систем шаардлагатай үйлдлийн горимд хүрмэгц шалгах блокуудыг асаана.

Энэ блокийн параметрүүд нь:

• хилийн нөхцөл: шалгах ёстой дээд (дээд хязгаар) ба доод (доош хязгаар) хязгаарын хязгаар;
• Хилийн мужид (TimeInterval) шаардлагатай системийн өртөлтийн хугацаа секундээр;
• Хүсэлтийн ID ReqName;
• мужаас хэтрэх зөвшөөрөгдөх байдал Out_муж нь шалгагдсан мужаас хэтэрсэн утга нь шаардлагыг зөрчсөн эсэхийг тодорхойлох Булийн хувьсагч юм.

Зарим тохиолдолд туршилтын утгын гаралт нь системд тодорхой хэмжээний маржин байгаа бөгөөд үйл ажиллагааны хүрээнээсээ гадуур ажиллаж байгааг харуулж байна. Бусад тохиолдолд гаралт нь систем тогтоосон цэгүүдийг хязгаарт байлгах боломжгүй гэсэн үг юм.

Зураг 6. Диаграмм дахь ердийн шинж чанарыг шалгах блок ба түүний параметрүүд.

Энэ блокыг тооцоолсны үр дүнд үр дүнгийн хувьсагч гаралт дээр үүссэн бөгөөд энэ нь дараах утгыг авна.

• 0 – rҮгүй, утга тодорхойлогдоогүй;
• 1 – rДууссан, шаардлага хангасан;
• 2 – rFault, шаардлага хангаагүй.

Блокны зураг нь:

• таних бичвэр;
• хэмжилтийн хязгаарын параметрүүдийн тоон дэлгэц;
• параметрийн төлөвийн өнгө тодорхойлогч.

Блок дотор нэлээд төвөгтэй логик дүгнэлтийн хэлхээ байж болно.

Жишээлбэл, 6-р зурагт үзүүлсэн нэгжийн ажиллах температурын хязгаарыг шалгахын тулд дотоод хэлхээг 7-р зурагт үзүүлэв.

Зураг 7. Температурын хязгаарыг тодорхойлох нэгжийн дотоод диаграмм.

Хэлхээний блок дотор блокийн параметрт заасан шинж чанаруудыг ашигладаг.
Блокийн дотоод диаграмм нь шаардлагад нийцэж байгаа эсэхийг шинжлэхээс гадна симуляцийн үр дүнг харуулахад шаардлагатай графикийг агуулна. Энэ графикийг тооцооллын явцад харах, тооцоолсны дараа үр дүнд дүн шинжилгээ хийхэд ашиглаж болно.

Тооцооллын үр дүнг блокийн гаралт руу дамжуулж, нийт төслийн үр дүнд үндэслэн үүсгэсэн ерөнхий тайлангийн файлд нэгэн зэрэг бүртгэнэ. (8-р зургийг үз)

Симуляцийн үр дүнд үндэслэн хийсэн тайлангийн жишээ бол өгөгдсөн форматын дагуу үүсгэсэн html файл юм. Форматыг тодорхой байгууллагын хүлээн зөвшөөрсөн форматаар дур мэдэн тохируулж болно.

Хэлхээний блок дотор блокийн параметрт заасан шинж чанаруудыг ашигладаг.
Блокийн дотоод диаграмм нь шаардлагад нийцэж байгаа эсэхийг шинжлэхээс гадна симуляцийн үр дүнг харуулахад шаардлагатай графикийг агуулна. Энэ графикийг тооцооллын явцад харах, тооцоолсны дараа үр дүнд дүн шинжилгээ хийхэд ашиглаж болно.

Тооцооллын үр дүнг блокийн гаралт руу дамжуулж, нийт төслийн үр дүнд үндэслэн үүсгэсэн ерөнхий тайлангийн файлд нэгэн зэрэг бүртгэнэ. (8-р зургийг үз)

Симуляцийн үр дүнд үндэслэн хийсэн тайлангийн жишээ бол өгөгдсөн форматын дагуу үүсгэсэн html файл юм. Форматыг тодорхой байгууллагын хүлээн зөвшөөрсөн форматаар дур мэдэн тохируулж болно.

Зураг 8. Загварчлалын үр дүнд үндэслэсэн тайлангийн файлын жишээ.

Энэ жишээнд тайлангийн маягтыг төслийн шинж чанарт шууд тохируулсан бөгөөд хүснэгтийн форматыг дэлхийн төслийн дохио болгон тохируулсан болно. Энэ тохиолдолд SimInTech нь тайланг тохируулах асуудлыг өөрөө шийддэг бөгөөд үр дүнг файлд бичих блок нь тайлангийн файлд бичихдээ эдгээр мөрүүдийг ашигладаг.

Зураг 9. Глобал төслийн дохионууд дахь тайлангийн форматыг тохируулах

Шаардлагад дохионы мэдээллийн санг ашиглах.

Үл хөдлөх хөрөнгийн тохиргоотой ажиллах ажлыг автоматжуулахын тулд ердийн блок бүрийн хувьд дохионы мэдээллийн санд стандарт бүтцийг бий болгодог. (10-р зургийг үз)

Зураг 10. Дохионы мэдээллийн сан дахь шаардлагыг шалгах блокийн бүтцийн жишээ.

Дохионы мэдээллийн сан нь дараахь зүйлийг хангадаг.

• Системийн шаардлагатай бүх параметрүүдийг хадгалах.
• Заасан параметрүүд болон одоогийн загварчлалын үр дүнгээс одоо байгаа төслийн шаардлагыг хялбархан харах боломжтой.
• Скрипт програмчлалын хэлийг ашиглан нэг блок эсвэл бүлэг блокуудыг тохируулах. Дохионы мэдээллийн сангийн өөрчлөлт нь диаграм дахь блокийн шинж чанарын утгыг өөрчлөхөд хүргэдэг.
• Текстийн тайлбар, техникийн үзүүлэлтүүдийн холбоос эсвэл шаардлагын удирдлагын систем дэх танигчийг хадгалах.

Шаардлагын дохионы өгөгдлийн сангийн бүтцийг гуравдагч талын шаардлагын удирдлагын системтэй ажиллахаар хялбархан тохируулж болно.Шаардлагын удирдлагын системтэй харилцах ерөнхий диаграммыг Зураг 11-д үзүүлэв.

Зураг 11. Шаардлагын удирдлагын системтэй харилцах диаграмм.

SimInTech туршилтын төсөл болон шаардлагын хяналтын систем хоорондын харилцан үйлчлэлийн дараалал дараах байдалтай байна.

1. Ажлын даалгаврыг шаардлагын дагуу хуваана.
2. Техникийн үйл явцын математик загварчлалаар баталгаажуулж болох техникийн үзүүлэлтүүдийн шаардлагыг тодорхойлсон.
3. Сонгосон шаардлагын шинж чанаруудыг стандарт блокуудын бүтцэд SimInTech дохионы мэдээллийн санд шилжүүлдэг (жишээлбэл, хамгийн их ба хамгийн бага температур).
4. Тооцооллын явцад бүтцийн өгөгдлийг блок дизайны диаграммд шилжүүлж, дүн шинжилгээ хийж, үр дүнг дохионы мэдээллийн санд хадгалдаг.
5. Тооцоолол дууссаны дараа шинжилгээний үр дүнг шаардлагын удирдлагын системд шилжүүлнэ.

Дизайн ба/эсвэл шаардлагад өөрчлөлт орж, өөрчлөлтийн нөлөөллийг дахин шалгах шаардлагатай үед 3-аас 5 хүртэлх шаардлагын алхмуудыг дизайн хийх явцад давтаж болно.

Дүгнэлт.

• Системийн бүтээгдсэн прототип нь одоо байгаа загваруудыг техникийн үзүүлэлтүүдийн шаардлагад нийцүүлэн шинжлэх хугацааг мэдэгдэхүйц бууруулах боломжийг олгодог.
• Санал болгож буй туршилтын технологи нь одоо байгаа динамик загваруудыг ашигладаг бөгөөд SimInTech орчинд хийгдээгүй бүх динамик загварт ч ашиглаж болно.
• Багц өгөгдлийн зохион байгуулалтыг ашиглах нь загвар боловсруулахтай зэрэгцэн шаардлагын баталгаажуулалтын багцуудыг үүсгэх, эсвэл эдгээр багцуудыг загвар боловсруулах техникийн үзүүлэлт болгон ашиглах боломжийг олгодог.
• Энэ технологийг одоо байгаа шаардлагын удирдлагын системтэй их хэмжээний зардалгүйгээр нэгтгэх боломжтой.

Эцсээ хүртэл уншсан хүмүүст Прототип хэрхэн ажилладагийг харуулсан видеог линк.

Эх сурвалж: www.habr.com