Ամսագրի նպատակն է տարածել գիտելիք, փորձ և լավագույն պրակտիկա ճարտարագիտության և արտադրության ոլորտում։ Հոդվածները գրում են Երևանի Engineering City-ի (EC) գործող մասնագետները։ Դրանք լուսաբանում են իրենց նախագծերին, գործունեությանը և կազմակերպություններին առնչվող հարցեր։ Հոդվածներն անդրադառնում են ժամանակի մարտահրավերներին։ Այդպիսով ամսագիրը նաև EC-ի, նրա ընկերությունների և անհատների զարգացման տարեգրությունն է։ Ամսագրի նպատակն է առաջ մղել ինժեներական և արտադրական պրակտիկան, հարստացնել ինժեներական և արտադրական համայնքը և նպաստել ճարտարագիտության և արտադրության վերաբերյալ համաշխարհային երկխոսությանը։
Հրատարակվում է Ինժեներական ասոցիացիայի կողմից
The Engineering City JournalՀամար 19/2025Հրատարակվում է Ինժեներական ասոցիացիայի կողմիցԵրևան, 2025 թ. հոկտեմբերի 15
Հեղինակ՝ Ashot Arzumanyan, 11-րդ դասարանի աշակերտ, պրակտիկանտ EC-ում
Հայերեն թարգմանություն
Նոր նախագիծ սկսելիս BOM ֆայլերի մշակումը շատ ժամանակ և ջանք է խլում։ Դրանք պետք է ստուգվեն՝ գնումների փուլը հաջողությամբ իրականացնելու համար անհրաժեշտ բոլոր տվյալները պարունակելու համար։ Ահա թե ինչու սկսվեց այս նախագիծը։
Ստորև կարող եք տեսնել n8n-ով ստեղծված աշխատանքային հոսքը, որն ավտոմատ կերպով ստուգում է, թե արդյոք BOM-ը ճիշտ է կառուցված և համապատասխանում է բոլոր պահանջներին։
Նկար 1– Աշխատանքային հոսքը սկզբից մինչև վերջ
Այսպիսով, սկսենք գործարկիչից։ Աշխատանքային հոսքը գործարկվում է (շարժման մեջ է դրվում որոշակի գործողությամբ/պայմանով) ձևի ներկայացմամբ։ Այն կարող եք տեսնել ստորև։
Նկար 2 – BOM-ի ներկայացման ձևը
Հենց որ այս ձևը ներկայացվում է, աշխատանքային հոսքն ավտոմատ կերպով ակտիվանում է։ Այն ստուգում է, թե արդյոք ներկայացված BOM-ը համապատասխանում է ձևանմուշին։ Ստորև կարող եք տեսնել ձևանմուշը (Նկար 3) և BOM-ի օրինակը (Նկար 4)։
Նկար 3 - ՁևանմուշՆկար 4 - Ներկայացված BOM-ի օրինակ
Սա կատարվում է 4 փուլով և բաժանված է 2 մասի (ձևանմուշի ստուգում և տվյալների ստուգում)՝
Այնուհետև աշխատանքային հոսքը ստուգում է ֆայլի ներսում եղած տեղեկատվությունը։
Փուլ 3. Ստուգում է, որ BOM-ի վերնագրերի դաշտերը լրացված լինեն, և ստացված լինեն բոլոր անհրաժեշտ տվյալները (տե՛ս Նկար 7)։
Փուլ 4. Ստուգում է, թե արդյոք հիմնական տվյալները, որտեղ ներկայացված են BOM-ի բաղադրիչները, կարող են համարվել ամբողջական (տե՛ս Նկար 8)։
Նկար 7 – BOM-ի վերնագրերի ամբողջականությունՆկար 8 – Հիմնական տվյալների ամբողջականություն
Բոլոր տողերը ստուգվում են, որ դատարկ չլինեն (լրացված լինեն)։ Բացի այդ, որոշ դաշտեր պետք է լրացվեն որոշակի ձևով, ուստի հաշվի են առնվել նաև այդ պայմանները։ Օրինակ՝ Project ID-ն պետք է սկսվի «PI-»-ով, իսկ QTY-ն պետք է թիվ լինի։ Եթե որևէ մեկը դատարկ է կամ չի համապատասխանում պահանջներին, BOM-ը չի անցնի ստուգման գործընթացը։
Այնուհետև բոլոր դիրքերը (փաստաթղթի տողերը) անցնում են ստուգման գործընթացը. անցածներին տրվում է true արժեք, իսկ չանցածները նշվում են որպես false (նշված են կարմիր ֆոնով (տե՛ս Նկար1))։ Դրանք հավաքվում են միասին և բաժանվում խմբերի՝ true և false։ Նախ կատարվում է false ճյուղը։ Եթե կան false դիրքեր, նախագծի ղեկավարին ավտոմատ կերպով էլ. նամակ է ուղարկվում՝ խնդիրները լուծելու և BOM-ը կրկին ներկայացնելու համար։ Այնուհետև աշխատանքային հոսքը կանգ է առնում (տե՛ս Նկար 9)։
Եթե false դիրքեր չկան, կատարվում է true ճյուղը, որը էլ. նամակ է ուղարկում ինժեներին, որը պետք է հաստատի, որ սա ճիշտ BOM է (տե՛ս Նկար 9)։
Նկար 9 – Աշխատանքային հոսքի ավարտը
Եթե ամեն ինչ ճիշտ է, նույն էլ. նամակով ինժեներին ուղարկվում է հետևյալ ձևը՝
Նկար 10 – Ինժեների համար հաստատման ձև
Այս գործընթացը Նկար 1-ում նշված է կապույտ գույնով։
Սակայն մեծ BOM ֆայլում կարող է դժվար լինել գտնել, թե որտեղ է խնդիրը, որպեսզի այն լուծվի։ Ահա թե ինչու այս աշխատանքային հոսքը գրաֆիկորեն ցույց է տալիս խնդրահարույց բջիջները՝ դրանց ֆոնը փոխելով կարմիրի։
Սա կատարվում է առանձին ճյուղում (տե՛ս Նկար 11)։ Այն կատարվում է մի քանի քայլով՝ HTTP հարցումների միջոցով BOM ֆայլին։ Աշխատանքային հոսքն ավտոմատ կերպով ստանում է աղյուսակի ID-ն և թերթի ID-ն՝ ֆայլին մուտք գործելու համար, այնուհետև ջնջում է բոլոր արդեն առկա պայմաններն ու ձևաչափերը, իսկ հաջորդ հանգույցով սահմանում է նորերը, որոնք փոխում են փաստաթղթի դաշտերի գույնը։
Նկար 11– Փաստաթղթի պայմանական ձևաչափման սահմանում
Տե՛ս ստորև, թե ինչպես է դա աշխատում՝
Նկար 12 – Տվյալների ձևաչափման օրինակ
Այսպիսով, այս գործառույթի շնորհիվ նախագծի ղեկավարի համար ավելի հեշտ և արագ կլինի տեսնել, թե որտեղ է խնդիրը, և լուծել այն։
Վերջապես, սա ավտոմատացման ենթակա ամենի միայն փոքր մասն է։ Սակայն նույնիսկ այս փոքրիկ ավտոմատացումը, հավանաբար, արդեն կբարձրացնի YEA Engineering-ի գործընթացների արտադրողականությունը, արդյունավետությունն ու արդյունքայնությունը և կնպաստի նրա հետագա հաջողությանը։
Արդյունաբերական հիմքով տաղանդների զարգացման համակարգ (IB-TDS)
ԱԲ-ն ինժեներական կրթության մեջ
Հեղինակ՝ Grigor Shirinyan, DigiCore
Հայերեն թարգմանություն
Ներածություն
Համատեքստ։ Մեր ավագ դպրոցի աշակերտներն արդեն գիտեն էլեկտրոնիկայի, ծրագրավորման և հուշումների նախագծման հիմունքները։ ԱԲ-ն որպես պատասխաններ տվող մեքենա օգտագործելու փոխարեն՝ մենք ստեղծել ենք ծրագիր, որտեղ ԱԲ-ն գործընթացի գործընկեր էր երկու խմբում՝
Խումբ A՝ ներկառուցված ՄՈՒ սահմանափակ սարքավորման վրա։
Աշակերտները ՄՈՒ տրամաբանությունը տեղակայում են Arduino (Uno, Nano, Pro, Mega) և ESP տախտակների վրա, որոնք ունեն շատ տարբեր CPU/RAM/flash բնութագրեր։
Խումբ B՝ տեղային ԱԲ մեսենջերներում։ Աշակերտները գործարկում են մասնավոր, տեղային մոդելներ, որոնց պատասխանները մատուցվում են WhatsApp, Telegram և Viber բոտերի միջոցով։
Ստորև ներկայացված է մոտեցումը, այլ ոչ միայն արդյունքները։ Այն նախատեսված է կրկնելի լինելու և տարբերվում է «ԱԲ-ն կրթության մեջ» բնորոշ նկարագրություններից. մենք գնահատում ենք գործընթացի ապացույցները, պնդում ենք բացատրելիության վրա և ԱԲ-ն օգտագործում ենք ալգորիթմներն օպտիմալացնելու համար, որպեսզի դրանք կարողանան արդյունավետ աշխատել սահմանափակ սարքավորման վրա։
Մեր կիրառած սկզբունքները
Ուսուցիչը՝ որպես իմաստավորող, ոչ թե պատգամախոս։ Ուսուցիչը փաստեր չի հաղորդում. նա սովորեցնում է, թե ինչպես պարզել, թե ինչպես է ինչ-որ բան աշխատում։
85%-ի կանոնը։ Եթե աշակերտը հասկանում է իր ստեղծածի <85%-ը, նա պետք է ԱԲ-ի միջոցով բացատրություններ ստանա և հետո մեխանիզմը բացատրի ուսուցչին։
«Բացատրիր, որ գործարկես» քաղաքականություն։ Կոդը կարելի է ներբեռնել/տեղակայել միայն մեխանիզմի կարճ նշումով՝ ինչ է անում, ինչու է համապատասխանում սարքին, ինչպես ենք այն ստուգելու։
ԱԲ-ն կրկնողական է, ոչ թե մեկ հուշումով։ Աշակերտներն անցնում են՝ գաղափար → տարբերակներ → ընտրություն → իրականացում → վրիպազերծում → մտորում։
Լռելյայն՝ նախ տեղային։ Հնարավորության դեպքում մոդելներն աշխատում են տեղում/սարքի վրա, բոտերը միայն հաղորդագրություններ են փոխանցում։
Խումբ A՝ ներկառուցված ՄՈՒ Arduino/ESP-ի վրա
Նախագծեր
Երթևեկության կառավարում. սենսորային տվյալների միավորում՝ լուսացույցները իրական երթևեկության օրինաչափությունների հիման վրա փոխարկելու համար։
Օբյեկտների ճանաչում / դասակարգում. սահմանափակ մշակման շղթաներ (օրինակ՝ հատկանիշների վրա հիմնված կամ փոքրիկ CNN տարբերակներ)՝ միկրոկարգավորիչի սահմանափակումներին համապատասխան։
Վիճակագրություն. սահող միջիններ, անոմալիաների դրոշակներ և շեմային մշակում՝ սենսորների վիճակի համար։
Օգտագործված ալգորիթմներ
Աշակերտները փորձարկել են մեքենայական ուսուցման թեթև ալգորիթմներ, ինչպիսիք են լոգիստիկ ռեգրեսիան, k-միջինների կլաստերավորումը և փոքրիկ փաթույթային նեյրոնային ցանցերը (tiny CNN)։ Ընտրությունը կախված էր
սարքի սահմանափակումներից. ավելի պարզ ալգորիթմներ՝ շատ սահմանափակ հիշողությամբ տախտակների համար (Arduino Uno/Nano), և մի փոքր ավելի բարդերը՝ ավելի հզոր սարքավորման համար, ինչպես ESP տախտակները։
Աշակերտների աշխատակարգը՝
Սարքավորման ընտրության մատրից։ ԱԲ-ի օգնությամբ աշակերտները գնահատում են տախտակները ըստ RAM/flash-ի, մեկ եզրակացության ցիկլերի, ուշացման, էներգիայի և գրադարանների աջակցության։ Նրանք պետք է հիմնավորեն, թե ինչու Uno, Mega կամ ESP, և ինչու ոչ մյուսները։
Կազմաձևում և սխեմաներ։ ԱԲ-ն օգնում է ուրվագծել սխեմաները և ստուգել ելուստների քարտեզները, սնուցման բյուջեն և պաշտպանությունը (ռեզիստորներ, դիոդներ)։
Ծրագրավորում։
Աշակերտները նախ ինքնուրույն են գրում կոդը. ԱԲ-ն օգտագործվում է տեղափոխման համար (օրինակ՝ Python → C/C++ Arduino-ի համար) և գործիքաշղթաների հետ համատեղելիությունը ստուգելու համար։
ԱԲ-ն առաջարկում է հիշողության տեսանկյունից անվտանգ փոփոխություններ (բուֆերներ, ստեկի/կույտի սահմանաչափեր) և բացահայտում է «տաք» ցիկլերը միկրոօպտիմալացումների համար։
Վրիպազերծման օրագիր։ Յուրաքանչյուր ներբեռնում պահանջում է կարճ գրառում՝ ախտանիշ → վարկած → փորձարկում → փոփոխություն → կրկնակի փորձարկում։
Տեղակայում և վավերացում։ Աշակերտները կցում են ժամանակի/հիշողության թվեր (օրինակ՝ ցիկլի ժամանակ, ստեկի օգտագործում, FPS, եզրակացության ուշացում) և ճշգրտության/կեղծ դրականների պարզ հաշվետվություն։
Ինչով է տարբեր. սարքի սահմանափակումները դիտարկում ենք որպես ուսուցիչ։ Աշակերտները սովորում են ալգորիթմական փոխզիջումներ (ճշգրտություն – ուշացում – հիշողություն), որովհետև տախտակն ստիպում է վարել այդ զրույցը։
Խումբ B՝ տեղային ԱԲ WhatsApp/Telegram/Viber-ում
Ճարտարապետություն (շահագործվում է աշակերտների կողմից)
Տեղային մոդելը (օրինակ՝ լաբորատոր սերվերի վրա) գեներացնում է պատասխանները։
Յուրաքանչյուր հարթակի բոտերը կատարում են փոխանցումը. գրանցամատյանները նախագծով չեն պարունակում անձնական տվյալներ։
Աշակերտներն իրականացնում են հարցումների հաճախականության սահմանափակումներ, կրկնակի փորձեր և հիմնական մշտադիտարկում։
Ուսուցման խնդիրը, որը տեսանք
Հուշումներին տիրապետող աշակերտները կարող են արագ «գտնել» լուծումներ, բայց միշտ չէ, որ հասկանում են, թե ինչու են դրանք աշխատում։ Մեր պատասխանը կառուցվածքային, բազմաքայլ հոսք է՝ ըմբռնման դարպասներով՝
Գաղափար։ Աշակերտները ԱԲ-ից խնդրում են մի քանի մոտեցում և թվարկում փոխզիջումները։
Ընտրություն։ ԱԲ-ի օգնությամբ նրանք ընտրում են ամենահամապատասխան ուղին (չափանիշներ՝ բարդություն, արժեք, գաղտնիություն, սպասարկելիություն)։
Իրականացում a. Գրադարաններ։ Գտնել, տեղադրել և բացատրել հիմնական API-ները։
b. Հարթակներ և միջավայրեր։ Կազմաձևել WhatsApp/Telegram/Viber ինտեգրումները։ Փաստագրել թոքենները, վեբհուքերը և անվտանգությունը c. Ներբեռնում և գործարկում։ Բոտը միացնել տեղային մոդելին։ Փորձնական գործարկում փորձնական օգտատերերով։
d. Վրիպազերծում ԱԲ-ով։ Մոդելն օգտագործել վարկածներ ձևավորելու համար, ոչ թե պարզապես սխալները տեղադրել։
e. Փաստաթղթավորում։ Պատրաստել հոսքագիծ և կարճ «ինչպես է աշխատում» բացատրություն։
f. Օպտիմալացում։ Պրոֆիլավորել պատասխանի ժամանակը և հիշողությունը. կրճատել համատեքստի պատուհանները. քեշավորել հաճախակի մտադրությունները։ g. Մշտադիտարկում և հետ գլորում։ Հիմնական վահանակներ, սխալների ազդանշաններ և անվտանգ պահուստային տարբերակներ։
Ինչով է տարբեր. գնահատում ենք բացատրության արտեֆակտները (հայեցակարգային քարտեզ, հոսքագիծ) և գործառնական իրականությունը (ուշացում, հուսալիություն), ոչ թե միայն այն, թե արդյոք բոտը «պատասխանում է»։
Իրական ըմբռնումը խրախուսող գնահատում
Մենք չենք գնահատում միայն այն, թե արդյոք նախագիծը «աշխատում է»։ Փոխարենը ստուգում ենք, թե որքան լավ են աշակերտները հասկանում իրենց արածը՝
Գործընթացի աշխատանք (40%)՝ աշակերտները պետք է ցույց տան իրենց կատարած քայլերը՝ սարքավորման ընտրության մատրիցը, վրիպազերծման օրագիրը, բացատրական նշումները և հոսքագծերը։
Բանավոր բացատրություն (20%)՝ յուրաքանչյուր աշակերտ կարճ 3-րոպեանոց ելույթ է ունենում (ինչպես մինի-պաշտպանություն), որի ժամանակ ուսուցիչը հարցեր է տալիս՝ ըմբռնումը ստուգելու համար։
Սարքի արդյունավետություն (20%)՝ չափում ենք այնպիսի ցուցանիշներ, ինչպիսիք են հիշողության օգտագործումը, արագությունը և ճշգրտությունը իրական սարքավորման վրա։
Համակարգի հուսալիություն (20%)՝ հաղորդագրությունների նախագծերի համար ստուգում ենք, թե որքան լավ է աշխատում համակարգը. արագ են գալիս պատասխանները։ Աշխատո՞ւմ են դրանք դեպքերի մեծ մասում։ Կարո՞ղ է համակարգը գլուխ հանել սխալներից։
Աշակերտներն ազատ են ԱԲ օգտագործելու հարցում, բայց դատողությունները պետք է իրենցը լինեն։ Եթե ԱԲ-ն կոդ է գրում, աշակերտը բացատրում է այն։ Եթե ԱԲ-ն բացատրություն է տալիս, աշակերտը ստուգում և ապացուցում է, որ այն ճիշտ է։
Ինչ սովորեցինք (և որտեղ է իրականում նորարարությունը)
Պատասխաններից դեպի մոդելներ։ Աշակերտները դադարում են հարցնել «Ո՞րն է կոդը» և սկսում են հարցնել «Ի՞նչ մոդել է կանգնած այս վարքագծի հետևում»՝ թե՛ ծրագրային, թե՛ ապարատային ապահովման համար։
Տարբեր լեզուների տիրապետում։ Ծանոթ լեզվով գրելը և ԱԲ-ի միջոցով այն միկրոկարգավորիչների համար C/C++-ի տեղափոխելը նվազեցնում է ցածր մակարդակի աշխատանքի հանդեպ վախը՝ պահպանելով խստությունը։
Ձախողումը դառնում է տվյալ։ Վրիպազերծման օրագիրը նորմա է դարձնում վարկածների ստուգումը՝ փորձերի և սխալների փոխարեն։
Ուսուցչի ժամանակը տեղափոխվում է դեպի մտածողություն։ Ավելի քիչ դասախոսություն API-ների մասին, ավելի շատ ուղղորդում որոշումների որակի և մեխանիզմների ըմբռնման վերաբերյալ։
Ռիսկեր և դրանց մեղմում
ԱԲ-ից չափազանց կախվածություն։ Մեղմվում է «Բացատրիր, որ գործարկես» քաղաքականությամբ և բանավոր պաշտպանությամբ։
Օպտիմալացման մարտահրավերներ։ Սկզբում աշակերտները կարող են դժվարանալ ալգորիթմներն արդյունավետ դարձնել սահմանափակ հիշողության և հաշվողական հզորության պայմաններում։ Սա լուծում ենք՝ ուղղորդելով նրանց օգտագործել ԱԲ-ն կոդի օպտիմալացման և արդյունավետության կարգավորման համար։
Սարքավորման անվտանգություն։ Հոսանքի սահմանափակումը, սնուցման ճիշտ դողերը և պաշտպանիչ բաղադրիչները քննարկման ենթակա չեն։
Մակերեսային վրիպազերծում։ Վրիպազերծման օրագրի գնահատման չափանիշները տուգանում են «աշխատեց տեղադրելուց հետո»-ն առանց վարկածների
Ուսուցում անգիր անելուց այն կողմ (ինչու է սա կարևոր)
ԱԲ-ի շնորհիվ աշակերտները սովորեցին ոչ թե մեխանիկորեն անգիր անել նյութը, այլ հասկանալ և ուսումնասիրել իրենց նախագծերի համար անհրաժեշտ հասկացությունները։ Կրթության այս փուլում ուսուցչի դերը պարզապես բացատրելը չէ
«թե ինչպես է ինչ-որ բան աշխատում»՝ որպես փաստ, այլ աշակերտներին ուղղորդելը, որպեսզի նրանք բացահայտեն, թե ինչպես հասկանալ, թե ինչպես են բաներն աշխատում։ Ուսուցման գործընթացում ԱԲ օգտագործող աշակերտներն ավելի ինքնավստահ և անկախ են դառնում, ինչը շատ արժեքավոր որակ է ապագա գործատուների համար։ Երբ նրանք գնան պրակտիկայի կամ մտնեն ընկերություններ, դաստիարակներն ու ղեկավարները ստիպված չեն լինի երկար «գդալով կերակրել» նրանց. նրանք արդեն ունակ կլինեն ինքնուրույն սովորել և խնդիրներ լուծել։
Ինչու՝ ավագ դպրոց
Կարևոր է նշել, որ ԱԲ-ի այսպիսի կիրառումը տրամաբանական և օգտակար է ավագ դպրոցի աշակերտների, այլ ոչ թե ավելի փոքր տարիքի սովորողների համար։ ԱԲ-ով նախագծերի մեջ ներգրավվելուց առաջ աշակերտները պետք է նախ յուրացնեն էլեկտրոնիկայի, ծրագրավորման և խնդիրների լուծման հիմունքները։ Միայն այդ հիմքն ունենալուց հետո ԱԲ-ն կարող է դառնալ իմաստալից գործիք՝ օգնելով նախագծել, փորձարկել և օպտիմալացնել, այլ ոչ թե կարճ ճանապարհ, որը փոխարինում է ուսուցմանը։