एक थिएटर के लिए एक स्वचालित नियंत्रण प्रणाली विकसित करने की एक दिलचस्प परियोजना में अभिनेता मॉडल का उपयोग करने के अनुभव के बारे में एक कहानी है। नीचे मैं अपने छापों को बताऊंगा, इससे अधिक नहीं।

इतना समय नहीं है जब मैंने एक रोमांचक कार्य में भाग लिया था: बैटन के झूलों के लिए स्वचालित नियंत्रण प्रणाली (एसीएस) का आधुनिकीकरण, लेकिन वास्तव में यह एक नए एसीएस का विकास था।

एक आधुनिक रंगमंच (खासकर यदि यह एक बड़ा है) एक बहुत ही जटिल संगठन है। कई लोग हैं, विभिन्न तंत्र और प्रणालियां हैं। ऐसी प्रणालियों में से एक है दृश्यों को उठाने और स्थापित करने के संचालन के लिए एसीएस। ओपेरा और बैले जैसे आधुनिक प्रदर्शन, साल दर साल अधिक से अधिक तकनीकी साधनों का उपयोग करते हैं। दृश्यों को सक्रिय रूप से शो के निर्देशकों द्वारा उपयोग किया जाता है और यहां तक ​​कि अपनी महत्वपूर्ण भूमिका निभाते हैं। यह जानना आकर्षक था कि पर्दे के पीछे क्या हो रहा है क्योंकि सामान्य दर्शक दृश्य पर केवल कार्रवाई देख सकते हैं।

लेकिन यह एक तकनीकी लेख है, और मैं एक नियंत्रण प्रणाली लिखने के लिए अभिनेता मॉडल का उपयोग करने के अपने अनुभव को साझा करना चाहता हूं। और C ++: SObjectizer के लिए किसी एक एक्टर फ्रेमवर्क का उपयोग करने के मेरे इंप्रेशन को साझा करें।

हमने यह ढांचा क्यों चुना? हम लंबे समय से इसे देख रहे हैं। रूसी में बहुत सारे लेख हैं, और इसमें अद्भुत दस्तावेज और बहुत सारे उदाहरण हैं। परियोजना एक परिपक्व की तरह दिखती है। उदाहरणों पर एक संक्षिप्त रूप से पता चला है कि SObjectizer के डेवलपर्स समान शर्तों (राज्यों, टाइमर, घटनाओं, आदि) का उपयोग करते हैं और हमें बड़ी समस्याओं की उम्मीद नहीं थी कि वे इसका अध्ययन कर रहे हैं और इसका उपयोग कर रहे हैं। और फिर भी एक और महत्वपूर्ण कारक: सोबिजाइज़र की टीम सहायक है और हमेशा हमारी मदद करने के लिए तैयार है। इसलिए हमने कोशिश करने का फैसला किया।

हम क्या कर रहे हैं?

आइए हमारे प्रोजेक्ट के लक्ष्य के बारे में बात करते हैं। बैटन होइस्ट की प्रणाली में 62 बैटन (धातु ट्यूब) हैं। प्रत्येक बैटन पूरे चरण जितनी लंबी है। वे मंच के सामने के किनारे से शुरू होकर, 30-40 सेमी के अंतराल के साथ समानांतर में रस्सियों पर निलंबित कर दिए जाते हैं। हर बैटन को उठाया या उतारा जा सकता है। उनमें से कुछ का उपयोग दृश्यों के लिए एक शो में किया जाता है। दृश्यों को बैटन पर तय किया जाता है और प्रदर्शन के दौरान ऊपर / नीचे ले जाया जाता है। ऑपरेटरों से आदेश आंदोलन शुरू करते हैं। "इंजन-रस्सी-असंतुलन" की एक प्रणाली आवासीय भवनों में लिफ्ट में उपयोग किए जाने वाले समान है। इंजन को मंच के बाहर रखा जाता है, इसलिए दर्शक उन्हें नहीं देखते हैं। सभी इंजन 8 समूहों में विभाजित हैं, और प्रत्येक समूह में 3 आवृत्ति कन्वर्टर्स (एफसी) हैं। एक समूह में एक ही समय में अधिकतम तीन इंजनों का उपयोग किया जा सकता है, उनमें से प्रत्येक एक अलग एफसी से जुड़ा हुआ है। इसलिए हमारे पास 62 इंजन और 24 एफसी की एक प्रणाली है, और हमें इस प्रणाली को नियंत्रित करना है।

हमारा कार्य इस प्रणाली को नियंत्रित करने और नियंत्रण एल्गोरिदम को लागू करने के लिए एक मानव-मशीन इंटरफ़ेस (HMI) विकसित करना था। प्रणाली में तीन नियंत्रण स्टेशन शामिल हैं। उनमें से दो को मंच के ठीक ऊपर रखा गया है, और एक इंजन रूम में है (यह स्टेशन ड्यूटी पर इलेक्ट्रीशियन द्वारा उपयोग किया जाता है)। इंजन रूम में कंट्रोलर्स के साथ कंट्रोल ब्लॉक भी होते हैं। ये नियंत्रक नियंत्रण कमांड करते हैं, पल्स-चौड़ाई मॉड्यूलेशन (पीडब्लूएम) करते हैं, इंजन को चालू या बंद करते हैं, बैटन की स्थिति को नियंत्रित करते हैं। मंच के ऊपर दो नियंत्रण स्टेशनों में डिस्प्ले डिवाइस के रूप में डिस्प्ले, सिस्टम यूनिट और ट्रैकबॉल हैं। नियंत्रण स्टेशन ईथरनेट के माध्यम से जुड़े हुए हैं। प्रत्येक नियंत्रण स्टेशन RS485 चैनल द्वारा नियंत्रण ब्लॉकों से जुड़ा हुआ है। एक ही समय में सिस्टम को नियंत्रित करने के लिए मंच के ऊपर दोनों स्टेशनों का उपयोग किया जा सकता है, लेकिन केवल एक ही स्टेशन सक्रिय हो सकता है। सक्रिय स्टेशन का चयन एक ऑपरेटर द्वारा किया जाता है; दूसरा स्टेशन निष्क्रिय होगा; निष्क्रिय स्टेशन का RS485 चैनल अक्षम है।

अभिनेता क्यों?

एल्गोरिदम के दृष्टिकोण से, सिस्टम घटनाओं के शीर्ष पर बनाया गया है। सेंसर से डेटा, ऑपरेटर की कार्रवाई, टाइमर की समाप्ति ... ये सभी घटनाओं के उदाहरण हैं। एक्टर मॉडल ऐसे एल्गोरिदम के लिए अच्छी तरह से काम करता है: अभिनेता आने वाली घटनाओं को संभालते हैं और अपनी वर्तमान स्थिति के आधार पर कुछ आउटगोइंग कार्रवाई करते हैं। ये मैकेनिक SObjectizer में केवल बॉक्स से बाहर उपलब्ध हैं।

ऐसी प्रणालियों के लिए मूल सिद्धांत हैं: अभिनेता अतुल्यकालिक संदेशों के माध्यम से बातचीत करते हैं, अभिनेताओं के पास एक राज्य से दूसरे राज्य में स्विच होता है, केवल वे संदेश होते हैं जो वर्तमान स्थिति के लिए सार्थक होते हैं।

यह दिलचस्प है कि एक्टर्स को सोबजाइज़र में कामगार धागे से अलग किया जाता है। इसका मतलब है कि आप अपने अभिनेताओं को पहले लागू कर सकते हैं और डिबेट कर सकते हैं और उसके बाद ही तय कर सकते हैं कि हर अभिनेता के लिए कौन सा वर्कर धागा इस्तेमाल किया जाएगा। "डिस्पैचर" हैं जो विभिन्न थ्रेड से संबंधित नीतियों को लागू करते हैं। उदाहरण के लिए, एक डिस्पैचर है जो प्रत्येक अभिनेता के लिए एक अलग श्रमिक धागा प्रदान करता है; एक थ्रेड-पूल डिस्पैचर है जो श्रमिक थ्रेड्स का एक निश्चित आकार का पूल प्रदान करता है; एक डिस्पैचर है जो सभी कलाकारों को एक ही धागे पर चलाता है।

डिस्पैचर्स की उपस्थिति हमारी आवश्यकताओं के लिए एक अभिनेता प्रणाली को ट्यूनिंग करने का एक बहुत ही लचीला तरीका प्रदान करती है। हम कुछ अभिनेताओं को समान संदर्भ में काम करने के लिए समूहित कर सकते हैं। हम कोड की सिर्फ एक लाइन द्वारा डिस्पैचर के प्रकार को बदल सकते हैं। SObjectizer के डेवलपर्स का कहना है कि कस्टम डिस्पैचर लिखना कोई जटिल काम नहीं है। लेकिन इस परियोजना में अपने स्वयं के डिस्पैचर लिखने की कोई आवश्यकता नहीं थी; हमें जो कुछ भी चाहिए था वह सबजेक्ट में मिला।

फिर भी एक और दिलचस्प विशेषता अभिनेताओं का सहयोग है। एक सहयोग अभिनेताओं का एक समूह है जो मौजूद हो सकता है और केवल अगर सभी कलाकार सफलतापूर्वक शुरू हो गए हैं। यदि इसके कम से कम एक अभिनेता को शुरू करने में विफल रहा है तो सहयोग शुरू नहीं किया जा सकता है। ऐसा लगता है कि Kubernetes से SObjectizer के सहयोग और पॉड के बीच एक समानता है, लेकिन यह भी लगता है कि SObjectizer के सहयोग पहले दिखाई दिए हैं ...

जब एक अभिनेता बनाया जाता है, तो इसे सहयोग में जोड़ा जाता है (सहयोग में सिर्फ एक अभिनेता हो सकता है) और कुछ डिस्पैचर के लिए बाध्य होता है। सहकारी समितियों और अभिनेताओं को गतिशील रूप से बनाना आसान है और सोबिजाइज़र के डेवलपर्स का कहना है कि यह एक सस्ता ऑपरेशन है।

सभी कलाकार "संदेश बॉक्स" (एमबॉक्स) के माध्यम से एक-दूसरे के साथ बातचीत करते हैं। यह अभी तक एक और दिलचस्प और शक्तिशाली SObjectizer की अवधारणा है। यह संदेश प्रसंस्करण का एक लचीला तरीका प्रदान करता है।

सबसे पहले, एक mbox के पीछे एक से अधिक संदेश रिसीवर हो सकते हैं। यह काफी मददगार है। उदाहरण के लिए, एक एमबॉक्स हो सकता है जो नए डेटा प्रकाशित करने के लिए सेंसर द्वारा उपयोग किया जाता है। अभिनेता उस एमबॉक्स के लिए सदस्यता बना सकते हैं, और सब्सक्राइब किए गए अभिनेताओं को वह डेटा प्राप्त होगा जो वे चाहते हैं। यह एक "प्रकाशित / सदस्यता लें" फैशन में काम करने की अनुमति देता है।

दूसरे पर, SObjectizer के डेवलपर्स ने कस्टम mbox निर्माण की संभावना की परिकल्पना की है। आने वाले संदेशों की विशेष प्रसंस्करण (जैसे संदेश की सामग्री के आधार पर कई ग्राहकों के बीच प्रसार या प्रसार) के साथ एक कस्टम एमबॉक्स बनाना अपेक्षाकृत आसान है।

प्रत्येक अभिनेता के लिए एक व्यक्तिगत बॉक्स भी होता है और अभिनेता उस बॉक्स में अन्य अभिनेताओं को संदेश भेज सकते हैं (जो किसी विशिष्ट अभिनेता को सीधे जवाब देने की अनुमति देता है)।

हमारी परियोजना में हम सभी नियंत्रित वस्तुओं को आठ समूहों (प्रत्येक नियंत्रण बॉक्स के लिए एक समूह) में विभाजित करते हैं। हर समूह के लिए तीन कार्यकर्ता सूत्र बनाए गए थे (यह केवल तीन इंजन एक ही समय में काम कर सकते हैं)। इसने हमें इंजनों के समूहों के बीच स्वतंत्रता की अनुमति दी। यह भी प्रत्येक समूह के अंदर इंजन के साथ अतुल्यकालिक काम करने की अनुमति दी।

यह उल्लेख करना आवश्यक है कि SObjectizer-5 में इंटरप्रोसेस या / और नेटवर्क इंटरैक्शन के लिए कोई तंत्र नहीं है। यह SObjectizer के डेवलपर्स का एक सचेत निर्णय है; वे SObjectizer को जितना संभव हो उतना हल्का बनाना चाहते थे। इसके अलावा, नेटवर्किंग के लिए पारदर्शी समर्थन SObjectizer के पिछले संस्करणों में मौजूद था, लेकिन हटा दिया गया था। यह हमें परेशान नहीं करता था क्योंकि नेटवर्किंग के लिए एक तंत्र एक कार्य, प्रोटोकॉल और अन्य शर्तों पर अत्यधिक निर्भर है। सभी मामलों के लिए एक भी सार्वभौमिक समाधान नहीं है।

हमारे मामले में, हमने नेटवर्क और इंटरप्रोसेस संचार के लिए अपनी पुरानी लाइब्रेरी libuniset2 का उपयोग किया। नतीजतन, libuniset2 सेंसर और नियंत्रण ब्लॉकों के साथ संचार का समर्थन करता है, और SObjectizer एक एकल प्रक्रिया के अंदर अभिनेताओं के बीच अभिनेताओं और बातचीत का समर्थन करता है।

जैसा कि मैंने पहले कहा कि 62 इंजन हैं। हर इंजन को एफसी (आवृत्ति कनवर्टर) से जोड़ा जा सकता है; संबंधित बैटन के लिए एक गंतव्य समन्वय निर्दिष्ट किया जा सकता है; बैटन के आंदोलन की गति भी निर्दिष्ट की जा सकती है। और इसके अतिरिक्त, प्रत्येक इंजन में निम्नलिखित अवस्थाएँ होती हैं:

• काम करने के लिए तैयार;
• जुड़ा हुआ;
• काम कर;
• खराबी;
• जोड़ने (एक संक्रमण राज्य);
• डिस्कनेक्टिंग (एक संक्रमण राज्य);

प्रत्येक इंजन को एक अभिनेता द्वारा प्रणाली में दर्शाया जाता है जो राज्यों के बीच संक्रमण को लागू करता है, सेंसर से डेटा को संभालता है और आदेश जारी करता है। SObjectizer में अभिनेता बनाना मुश्किल नहीं है: बस so_5::agent_t प्रकार से अपनी कक्षा का वारिस करें। अभिनेता के निर्माता का पहला तर्क context_t होना चाहिए। अन्य सभी तर्कों को एक डेवलपर के रूप में परिभाषित किया जा सकता है।

 class Drive_A: public so_5::agent_t { public: Drive_A( context_t ctx, ... ); ... } 

मैं वर्गों और विधियों का विस्तृत विवरण नहीं दिखाऊँगा क्योंकि यह एक ट्यूटोरियल नहीं है। मैं सिर्फ यह दिखाना चाहता हूं कि यह सब कितना आसान है SObjectizer (कुछ पंक्तियों में शाब्दिक रूप से)। आपको याद दिला दूं कि SObjectizer के पास उत्कृष्ट दस्तावेज और कई उदाहरण हैं।

एक अभिनेता का "राज्य" क्या है? हम किस बारे में बात कर रहे हैं?

राज्यों का उपयोग और उनके बीच संक्रमण नियंत्रण प्रणालियों के लिए एक "मूल विषय" है। यह कॉन्सेप्ट इवेंट हैंडलिंग के लिए बहुत अच्छा है। यह अवधारणा एपीआई स्तर पर SObjectizer में समर्थित है। राज्यों को अभिनेता की कक्षा के अंदर घोषित किया जाता है

 class Drive_A final: public so_5::agent_t { public: Drive_A( context_t ctx, ... ); virtual ~Drive_A(); //  state_t st_base {this}; state_t st_disabled{ initial_substate_of{st_base}, "disabled" }; state_t st_preinit{ substate_of{st_base}, "preinit" }; state_t st_off{ substate_of{st_base}, "off" }; state_t st_connecting{ substate_of{st_base}, "connecting" }; state_t st_disconnecting{ substate_of{st_base}, "disconnecting" }; state_t st_connected{ substate_of{st_base}, "connected" }; ... } 

और फिर हर राज्य के लिए घटना-संचालकों को परिभाषित किया जाता है। कभी-कभी किसी राज्य में प्रवेश करने या बाहर निकलने पर कुछ करना आवश्यक होता है। यह भी on_enter / on_exit हैंडलर्स के माध्यम से SObjectizer में समर्थित है। ऐसा लगता है कि SObjectizer के डेवलपर्स की नियंत्रण प्रणाली के विकास में पृष्ठभूमि है।

इवेंट हैंडलर

एक ईवेंट हैंडलर एक ऐसी जगह है जहां आपके एप्लिकेशन लॉजिक को लागू किया जाता है। जैसा कि मैंने पहले कहा था, एक विशेष mbox और एक विशिष्ट स्थिति के लिए एक सदस्यता बनाई जाती है। यदि किसी अभिनेता के पास स्पष्ट रूप से निर्दिष्ट नहीं है, तो यह एक विशेष "default_state" में है।

अलग-अलग राज्यों में एक ही घटना के लिए विभिन्न हैंडलर को परिभाषित किया जा सकता है। यदि आप किसी घटना के लिए एक हैंडलर को परिभाषित नहीं करते हैं, तो इस घटना को अनदेखा किया जाएगा (एक अभिनेता को इसके बारे में पता नहीं होगा)।

ईवेंट हैंडलर को परिभाषित करने के लिए एक सरल वाक्यविन्यास है। आप एक विधि निर्दिष्ट करते हैं, और अतिरिक्त प्रकार या टेम्पलेट पैरामीटर निर्दिष्ट करने की कोई आवश्यकता नहीं है। उदाहरण के लिए:

 so_subscribe(drv->so_mbox()) .in(st_base) .event( &Drive_A::on_get_info ) .event( &Drive_A::on_control ) .event( &Drive_A::off_control ); 

यह st_base अवस्था में एक विशिष्ट mbox से घटनाओं पर सदस्यता का एक उदाहरण है। यह उल्लेखनीय है कि st_base कुछ अन्य राज्यों के लिए एक आधार राज्य है और यह सदस्यता व्युत्पन्न राज्यों को विरासत में मिलेगी। यह दृष्टिकोण विभिन्न राज्यों में समान घटना संचालकों के लिए कॉपी-एंड-पेस्ट से छुटकारा पाने की अनुमति देता है। लेकिन विरासत में मिली घटना हैंडलर को किसी विशेष राज्य के लिए फिर से परिभाषित किया जा सकता है या किसी घटना को पूरी तरह से अक्षम ("दबा") किया जा सकता है।

ईवेंट हैंडलर को परिभाषित करने का दूसरा तरीका लैम्बडा फ़ंक्शन का उपयोग करना है। यह एक बहुत ही सुविधाजनक तरीका है क्योंकि इवेंट हैंडलर में अक्सर सिर्फ एक पंक्ति या दो कोड होते हैं: किसी चीज़ को कहीं भेजना या राज्य परिवर्तन:

 so_subscribe(drv->so_mbox()) .in(st_disconnecting) .event([this](const msg_disconnected_t& m) { ... st_off.activate(); }) .event([this]( const msg_failure_t& m ) { ... st_protection.activate(); }); 

यह वाक्य रचना शुरुआत में जटिल लगती है, लेकिन यह सक्रिय कोडिंग के कुछ दिनों के बाद ही परिचित हो जाती है और आप भी इसे पसंद करने लगते हैं। ऐसा इसलिए है क्योंकि कुछ अभिनेता के पूरे तर्क को संक्षिप्त और एक स्क्रीन में रखा जा सकता है। ऊपर दिखाए गए उदाहरण में, st_disconnected से st_off या st_protection में बदलाव होते हैं। इस कोड को पढ़ना आसान है।

सीधे मामलों के लिए BTW, जहां सिर्फ एक राज्य संक्रमण आवश्यक है, एक विशेष वाक्यविन्यास है:

 auto mbox = drv->so_mbox(); st_off .just_switch_to<msg_connected_t>(mbox, st_connected) .just_switch_to<msg_failure_t>(mbox, st_protection) .just_switch_to<msg_on_limit_t>(mbox, st_protection) .just_switch_to<msg_on_t>(mbox, st_on); 

नियंत्रण

नियंत्रण कैसे आयोजित किया जाता है? जैसा कि ऊपर बताया गया है कि बैटन की गति को नियंत्रित करने के लिए दो नियंत्रण स्टेशन हैं। प्रत्येक नियंत्रण स्टेशन में एक डिस्प्ले, एक पॉइंटिंग डिवाइस (ट्रैकबॉल) और गति सेटर होता है (और हम स्टेशन के अंदर एक कंप्यूटर और कुछ अतिरिक्त सामान की गिनती नहीं करते हैं)।

दो नियंत्रण मोड हैं: मैनुअल और "परिदृश्य मोड"। "परिदृश्य मोड" पर बाद में चर्चा की जाएगी, और अब हम मैनुअल मोड के बारे में बात करते हैं। इस मोड में, एक ऑपरेटर एक बैटन का चयन करता है, इसे आंदोलन के लिए तैयार करता है (इंजन को एफसी से जोड़ता है), बैटन के लिए लक्ष्य चिह्न सेट करता है, और जब गति शून्य से ऊपर सेट होती है, तो बैटन चलना शुरू कर देता है।

स्पीड सेटर "पोटेंशियोमीटर विथ ए हैंडल" के रूप में एक भौतिक सहायक है, लेकिन स्टेशन के डिस्प्ले पर एक वर्चुअल दिखाया गया है। जितना अधिक इसे चालू किया जाता है, उच्च गति गति होती है। अधिकतम गति 1.5 मीटर प्रति सेकंड तक सीमित है। स्पीड सेटर सभी बैटन के लिए एक है। इसका मतलब है कि सभी चयनित बैटन एक ही गति से चलते हैं। बैटन विपरीत दिशाओं में आगे बढ़ सकते हैं (यह ऑपरेटर के चयन पर निर्भर करता है)। यह स्पष्ट है कि मनुष्य के लिए कुछ लड़ाइयों से अधिक नियंत्रण करना कठिन है। इसकी वजह से मैनुअल मोड में केवल बैटन के छोटे समूह ही संभाले जाते हैं। ऑपरेटर एक ही समय में दो नियंत्रण स्टेशनों से बैटन को नियंत्रित कर सकते हैं। इसलिए प्रत्येक स्टेशन के लिए एक अलग गति सेटर है।

कार्यान्वयन के दृष्टिकोण से, मैनुअल मोड में कोई विशिष्ट तर्क नहीं है। एक "कनेक्ट इंजन" कमांड ग्राफिकल इंटरफ़ेस से जाता है, एक अभिनेता के लिए एक संबंधित संदेश में तब्दील हो जाता है, और फिर उस अभिनेता द्वारा नियंत्रित किया जाता है। अभिनेता "ऑफ" राज्य से "कनेक्टिंग" में जाता है, और फिर "कनेक्ट" स्थिति में। इसी तरह की चीजें एक बैटन की स्थिति और आंदोलन की गति निर्धारित करने के लिए आदेशों के साथ होती हैं। इन सभी आदेशों को संदेशों के रूप में एक अभिनेता को दिया जाता है। लेकिन यह ध्यान देने योग्य है कि "ग्राफिकल इंटरफ़ेस" और "नियंत्रण प्रक्रिया" अलग-अलग प्रक्रियाएं हैं और आईपीसी के लिए libuniset2 का उपयोग किया जाता है।

परिदृश्य मोड (क्या फिर से अभिनेता हैं?)

व्यवहार में, मैनुअल मोड का उपयोग केवल बहुत ही सरल मामलों के लिए या रिहर्सल के दौरान किया जाता है। मुख्य नियंत्रण मोड "परिदृश्य मोड" है। उस मोड में, प्रत्येक बैटन को परिदृश्य सेटिंग के अनुसार विशेष गति के साथ एक विशिष्ट स्थिति में ले जाया जाता है। उस मोड में एक ऑपरेटर के लिए दो सरल कमांड उपलब्ध हैं:

• तैयार करें, इंजनों के एक समूह को एफसी से जोड़ा जा रहा है);
• गो (समूह का आंदोलन शुरू होता है)।

पूरा परिदृश्य "एजेंडा" में विभाजित है। एक "एजेंडा" में बैटन के एक समूह के एकल आंदोलन का वर्णन किया गया है। इसका मतलब यह है कि एक "एजेंडा" में कुछ बैटन शामिल हैं और उनके लिए लक्ष्य गंतव्य और गति शामिल हैं। वास्तव में, एक परिदृश्य में कृत्यों का समावेश होता है, जिसमें चित्र होते हैं, चित्र में एजेंडा होता है, और एजेंडे में लक्ष्य के लिए लक्ष्य होते हैं। लेकिन नियंत्रण के दृष्टिकोण से, इससे कोई फर्क नहीं पड़ता, क्योंकि केवल एजेंडा में बैटन के आंदोलन के सटीक पैरामीटर होते हैं।

अभिनेता मॉडल उस मामले को पूरी तरह से फिट करता है। हमने एक "परिदृश्य खिलाड़ी" विकसित किया है जो विशेष अभिनेताओं के एक समूह को जन्म देता है और उन्हें शुरू करता है। हमने दो प्रकार के अभिनेताओं को विकसित किया है: निष्पादक अभिनेता (वे बटन्स की गति को नियंत्रित करते हैं) और समन्वयक अभिनेता (वे निष्पादकों के बीच कार्यों को वितरित करते हैं)। निष्पादनकर्ता मांग पर बनाए जाते हैं: जब कोई मुफ्त निष्पादक नहीं होते हैं, तो एक नया निष्पादक बनाया जाएगा। समन्वयक उपलब्ध निष्पादकों के पूल का प्रबंधन करता है। नतीजतन, नियंत्रण लगभग इस तरह दिखता है:

• एक ऑपरेटर एक परिदृश्य लोड करता है;
• आवश्यक एजेंडा तक इसे "स्क्रॉल" किया जाता है;
• उपयुक्त समय पर "तैयार" बटन दबाएं। उस समय एक समन्वयक को एक संदेश भेजा जाता है। इस संदेश में एजेंडे से हर बैटन के लिए डेटा है;
• समन्वयक अपने निष्पादकों के पूल की समीक्षा करता है और मुक्त निष्पादकों के बीच कार्यों को वितरित करता है (यदि आवश्यक हो तो नए निष्पादक बनाए जाते हैं);
• प्रत्येक निष्पादक एक कार्य प्राप्त करता है और तैयारी क्रियाएं करता है (एक इंजन को FC से जोड़ता है, फिर "go" कमांड का इंतजार करता है);
• ऑपरेटर उपयुक्त समय पर "गो" बटन दबाता है;
• "गो" कमांड समन्वयक के पास जाता है, और यह उन सभी निष्पादकों के बीच कमांड वितरित करता है जो वर्तमान में उपयोग में हैं।

एजेंडा में कुछ अतिरिक्त पैरामीटर हैं। जैसे "N सेकंड की देरी के बाद ही आंदोलन शुरू करें" या "ऑपरेटर से अतिरिक्त कमांड के बाद ही आंदोलन शुरू करें"। उसके कारण, एक निष्पादक के लिए राज्यों की सूची काफी लंबी है: "अगले कमांड के लिए तैयार", "आंदोलन के लिए तैयार", "आंदोलन की देरी", "ऑपरेटर कमांड का इंतजार", "चलती", "पूरा", "विफलता"।

जब एक बैटन सफलतापूर्वक लक्ष्य चिह्न तक पहुँच गई है (या कोई विफलता है) तो कार्य पूरा होने के बारे में समन्वयक को निष्पादक रिपोर्ट करता है। समन्वयक इंजन को बंद करने के आदेश के साथ उत्तर देता है (यदि बैटन अब एजेंडे में भाग नहीं लेता है) या निष्पादक को एक नया कार्य भेजता है। निष्पादक या तो इंजन को बंद कर देता है और "प्रतीक्षा" स्थिति में बदल जाता है या नई कमांड को संसाधित करना शुरू कर देता है।

क्योंकि राज्यों के साथ काम करने के लिए सोबिजाइज़र के पास काफी विचारशील और सुविधाजनक एपीआई है, कार्यान्वयन कोड काफी संक्षिप्त हो गया है। उदाहरण के लिए, आंदोलन से पहले एक देरी कोड की एक पंक्ति द्वारा वर्णित है:

 st_delay.time_limit( std::chrono::milliseconds{target->delay()}, st_moving ); st_delay.activate(); ... 

time_limit विधि राज्य में रहने के लिए समय की मात्रा को निर्दिष्ट करती है और किस राज्य को तब सक्रिय किया जाना चाहिए (उस उदाहरण में st_moving )।

संरक्षण कर्ता

निश्चित रूप से, विफलताएं हो सकती हैं। इन विफलताओं को सही ढंग से संभालने के लिए आवश्यकताएं हैं। ऐसे कार्यों के लिए भी अभिनेताओं का उपयोग किया जाता है। आइए कुछ उदाहरण देखें:

• अधिक सुरक्षा;
• सेंसर की खराबी से सुरक्षा;
• विपरीत दिशा में आंदोलन से सुरक्षा (यह हो सकता है अगर सेंसर या एक्ट्यूएटर्स में कुछ गड़बड़ है);
• सहज आंदोलन (एक आदेश के बिना) से सुरक्षा;
• कमांड निष्पादन नियंत्रण (एक बैटन के आंदोलन की जाँच की जानी चाहिए)।

हम देख सकते हैं कि वे सभी मामले आत्मनिर्भर हैं, लेकिन उन्हें एक साथ, एक ही समय में नियंत्रित किया जाना चाहिए। इसका मतलब है कि कोई भी विफलता हो सकती है। लेकिन हर चेक का अपना तर्क होता है: कभी-कभी टाइमआउट की जाँच करना आवश्यक होता है, कभी-कभी सेंसर से कुछ पिछले मूल्यों का विश्लेषण करना आवश्यक होता है। उस वजह से, संरक्षण छोटे अभिनेताओं के रूप में लागू किया जाता है। इन अभिनेताओं को मुख्य अभिनेता के सहयोग से जोड़ा जाता है जो तर्क को नियंत्रित करते हैं। यह दृष्टिकोण नए सुरक्षा मामलों को आसान बनाने के लिए अनुमति देता है: बस सहयोग के लिए एक और रक्षक अभिनेता जोड़ें। ऐसे अभिनेता का कोड आमतौर पर संक्षिप्त और समझने में आसान होता है, क्योंकि यह केवल एक फ़ंक्शन को लागू करता है।

रक्षक अभिनेताओं के कई राज्य भी हैं। आमतौर पर, वे तब चालू होते हैं जब एक इंजन चालू होता है या जब एक बैटन अपना आंदोलन शुरू करता है। जब एक रक्षक विफलता / खराबी का पता लगाता है तो यह एक अधिसूचना (सुरक्षा कोड और कुछ अतिरिक्त विवरण के साथ) प्रकाशित करता है। मुख्य अभिनेता उस अधिसूचना पर प्रतिक्रिया करता है और आवश्यक कार्य करता है (जैसे इंजन को बंद करना और संरक्षित राज्य में स्विच करना)।

निष्कर्ष के रूप में ...

... यह लेख निश्चित रूप से एक सफलता नहीं है। अभिनेता मॉडल का उपयोग कई अलग-अलग प्रणालियों में काफी लंबे समय से किया जा रहा है। लेकिन यह एक छोटी सी परियोजना में एक स्वचालित नियंत्रण प्रणाली के निर्माण के लिए अभिनेता मॉडल का उपयोग करने का मेरा पहला अनुभव था। और यह अनुभव काफी सफल रहा। मुझे उम्मीद है कि मैंने दिखाया है कि एक्टर्स नियंत्रण एल्गोरिदम के लिए एक अच्छा फिट हैं: हर जगह एक्टर्स के लिए स्थान हैं।

हमने पिछली परियोजनाओं में कुछ इसी तरह से लागू किया था (मेरा मतलब है कि राज्यों, संदेश विनिमय, कार्यकर्ता धागे का प्रबंधन, और इसी तरह), लेकिन यह एकीकृत दृष्टिकोण नहीं था। SObjectizer का उपयोग करके हमें एक छोटा, हल्का उपकरण मिला है जो बहुत सारी समस्याओं को हल करता है। हमें अब (स्पष्ट रूप से) निम्न-स्तरीय सिंक्रोनाइज़ेशन तंत्र (जैसे म्यूटेक्स) का उपयोग करने की आवश्यकता नहीं है, कोई मैनुअल थ्रेड प्रबंधन नहीं है, कोई अधिक हस्तलिखित स्टेटचर्स नहीं है। इन सभी को फ्रेमवर्क द्वारा प्रदान किया गया है, तार्किक रूप से जुड़ा हुआ है और सुविधाजनक एपीआई के रूप में व्यक्त किया गया है, लेकिन आप विवरण पर नियंत्रण नहीं खोते हैं। तो यह एक रोमांचक अनुभव था। यदि आप अभी भी संदेह में हैं, तो मैं आपको विशेष रूप से अभिनेता मॉडल और सोबिजाइज़र पर एक नज़र डालने की सलाह देता हूं । यह सकारात्मक भावनाओं को छोड़ देता है।

अभिनेता मॉडल वास्तव में काम करता है! खासतौर पर थिएटर में।

मूल लेख रूसी में