स्मार्ट सिस्टम्स डेवलपर मैनिफेस्टो: 15 सिद्धांत

हम आपके ध्यान में व्लादिस्लाव ज़ैतसेव ( vvzvlad ) द्वारा एक लेख लाते हैं , जो हमारे ब्लॉग का आमंत्रित अतिथि है। व्लादिस्लाव लंबे समय से "स्मार्ट घरों" के विषय में लगे हुए हैं और अपने अनुभव को सारांशित करते हुए, वे इस तरह के सिस्टम के डिजाइन के लिए निम्नलिखित बुनियादी सिद्धांत पेश करते हैं।

आज मैं आपके साथ विशेष रूप से स्मार्ट घरों और सामान्य रूप से IoT उपकरणों के बारे में बात करना चाहता हूं। लेकिन यह एक सामान्य लेख नहीं होगा: गीथब पर ग्रंथियों, निर्माताओं के लिंक, कोड के टुकड़े और रिपॉजिटरी नहीं होंगे। आज हम कुछ उच्च स्तर पर चर्चा करेंगे - वे सिद्धांत जिनके द्वारा "स्मार्ट" सिस्टम आयोजित किए जाते हैं।



लेख को पढ़ना जारी रखने से, आप सहमत हैं कि आप निम्नलिखित अस्वीकरण से संतुष्ट हैं।

---

स्मार्ट होम एक ऐसी प्रणाली है जो किसी व्यक्ति की दैनिक चिंताओं का हिस्सा है। यहाँ से पहला और सबसे बुनियादी सिद्धांत निम्नानुसार है:

1. एक स्मार्ट घर को जीवन को आसान और आसान बनाना चाहिए।

एक स्मार्ट होम जीवन के लिए एक प्रणाली है, न कि गीक्स के लिए एक खिलौना। पारंपरिक स्विच की तुलना में ¹ का उपयोग करने के लिए कठिन कोई भी प्रणाली एक स्मार्ट घर नहीं है।

इस सिद्धांत के अनुपालन के लिए किसी भी नए उत्पाद का परीक्षण किया जाना चाहिए। यदि यह जीवन को आसान नहीं बनाता है, और आपको समझ में नहीं आता है कि इसे कैसे आसान बनाया जाए, तो यह स्मार्ट घर में नहीं है। आप इसे एक सीखने की प्रणाली के रूप में कल्पना करने की कोशिश कर सकते हैं।

---

दूसरा सबसे महत्वपूर्ण सिद्धांत यह चिंता करता है कि उपयोगकर्ता सिस्टम के साथ कैसे इंटरैक्ट करता है:

2. एक अच्छा उपयोगकर्ता अनुभव कार्यक्षमता से अधिक महत्वपूर्ण है।

व्यर्थ एक शांत उपकरण है जिसे सामान्य रूप से उपयोग नहीं किया जा सकता है। सीमित कार्यक्षमता वाले सुविधाजनक और विश्वसनीय उपकरण "सभी अवसरों" के लिए परिष्कृत उत्पादों की तुलना में सफल होने की अधिक संभावना है।

2.1। कस्टमाइज़ करने की तुलना में सुविधाजनक इंटरफेस बेहतर हैं।

समझ में नहीं आता कि कार्यों का एक गुच्छा और एक सरल इंटरफ़ेस को कैसे बचाया जाए? आप इस उम्मीद में एक पंक्ति में सभी कार्यों को धक्का देते हैं कि उपयोगकर्ता यह पता लगाएगा कि उसे क्या चाहिए? पेशे से बाहर निकलो!
समझ में नहीं आता कि कैसे सुविधा और सेटिंग्स का एक गुच्छा गठबंधन करने के लिए? सेटिंग्स का दान करें। एक नियमित स्विच की तुलना में कोई भी कार्यक्षमता कूलर होगी, लेकिन अत्यधिक जटिलता आसानी से उपयोगकर्ता को स्विच पर लौटने के लिए मजबूर करेगी।

यही कार्य गुणवत्ता पर लागू होता है। एक बटन जो बस प्रकाश को चालू करता है, चमक-समायोजन स्लाइडर से बेहतर होता है, जो कभी-कभी चमकता है:

2.2। कार्यान्वित कार्यों की गुणवत्ता उनकी मात्रा से अधिक महत्वपूर्ण है।

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

2.3। सिस्टम के कार्यान्वयन से काम की सामान्य गति कम नहीं होनी चाहिए।

देरी अस्वीकार्य है क्योंकि वे उपयोगकर्ता अनुभव को नीचा दिखाते हैं। यह भी एक नकारात्मक प्रोत्साहन है। यदि किसी व्यक्ति को पारंपरिक स्विच पर क्लिक करने और प्रकाश को शामिल करने के बीच देरी ^{2 का} ध्यान नहीं आता है, तो उसे आपके सिस्टम में इसे नहीं देखना चाहिए।

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

2.4। सिस्टम को उपयोगकर्ता की पहले से गठित आदतों को नहीं तोड़ना चाहिए।

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

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

तो क्या करें?

2.5। सिस्टम को नया अनुभव लाना चाहिए, और पुराने को बदलने की कोशिश नहीं करनी चाहिए।

यदि आपको लगता है कि घर पर सिस्टम के प्रबंधन का तरीका पुराने से बेहतर है, तो इसे उपयोगकर्ता को पेश करें। यदि यह वास्तव में अधिक सुविधाजनक है, तो वह एक नया (हां, अलग-अलग तरीकों से अलग-अलग लोगों के अनुकूल) का चयन करेगा। आप कर सकते हैं (और चाहिए) उसे एक विकल्प दे।

---

स्मार्ट होम में एक महत्वपूर्ण स्थान काम के तर्क द्वारा कब्जा कर लिया गया है। यह निर्धारित करता है कि यह स्मार्ट होम किन नियमों से काम करेगा। और निम्नलिखित महत्वपूर्ण सिद्धांत इसके बारे में है:

3. उपयोगकर्ता को उसके लिए सुलभ तर्क में सीमित नहीं किया जा सकता है।

यदि उपयोगकर्ता कमरे में तापमान बढ़ने पर केतली ³ चालू करना चाहता है, तो उसे ऐसा करने का अवसर दें। एक स्थिति को बाहर रखा जाना चाहिए जब एक निश्चित कार्रवाई करने के लिए कोई भौतिक या सॉफ़्टवेयर सीमाएं नहीं हैं, लेकिन यह उपलब्ध नहीं है, क्योंकि डेवलपर ने सोचा कि "किसी को भी कभी भी इसकी आवश्यकता नहीं होगी।"

3.1। जितना संभव हो उतना सरल: तर्क लिखने के लिए सिस्टम डिवाइस के बारे में विशेष ज्ञान की आवश्यकता नहीं होनी चाहिए

यदि आपके पास विभिन्न प्रोटोकॉल वाले विभिन्न संस्करणों के उपकरण हैं, तो सुनिश्चित करें कि उपयोगकर्ता इसके बारे में केवल वास्तव में आवश्यक मामलों में जानता है, जब आप इसके बिना नहीं कर सकते। यदि आप उपयोगकर्ता को विशेष ज्ञान प्राप्त करने से बचा सकते हैं, तो डेवलपर्स के समय की कीमत पर, ऐसा करें। डेवलपर दो दिन और प्रति घंटे एक हजार उपयोगकर्ता खर्च करेगा। अड़तालीस घंटे बनाम एक हजार? उत्तर स्पष्ट है।

आप कैसे सोते हैं, जॉन एक सीरियल प्रोग्रामर है?

3.2। समान कार्यों वाले उपकरणों को समान रूप से नियंत्रित किया जाना चाहिए।

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

---

हम सभी भौतिक दुनिया में रहते हैं। मानव शरीर और मस्तिष्क भौतिक वस्तुओं के साथ बातचीत करने के लिए बनते हैं। इसलिए सिद्धांत:

4. भौतिक नियंत्रण उपकरण आभासी लोगों की तुलना में बेहतर हैं।

कोई भी, यहां तक ​​कि आभासी नियंत्रण बटन के साथ फोन पर सबसे अच्छा अनुप्रयोग सही जगह पर सामान्य भौतिक स्विच से हार जाता है।

एक और बात यह है कि स्विच को सही जगह पर स्थित होना चाहिए। इसलिए एक और महत्वपूर्ण नियम:

5. रेडियो तारों से बेहतर है।

वायर्ड सिस्टम विश्वसनीय हैं, लेकिन केवल रेडियो संचार आपको फिर से मरम्मत के बिना दीपक के लिए एक नया स्विच या रिले स्थापित करने की अनुमति देता है। और स्थानांतरण, यदि आप पिछले स्थान से ऊब चुके हैं। लेकिन इस सिद्धांत के अपने अपवाद हैं:

5.1। खराब रेडियो तारों से भी बदतर है।

एक अच्छा रेडियो वह है जो आपको यह सोचने की अनुमति नहीं देता है कि उपकरणों को केंद्रीय नियंत्रक से कितनी दूर रखा जाना चाहिए। एक अच्छा रेडियो मेष नेटवर्क प्रोटोकॉल है: ZigBee, Z-Wave, 6LoWPAN और इतने पर।

अन्य सभी विकल्प खराब रेडियो हैं। वाई-फाई एक खराब रेडियो है। व्यक्तिगत कंपनियों के घर-निर्मित प्रोटोकॉल (वे "433 मेगाहर्ट्ज" नाम से स्व-निर्मित नाम से जाने जाते हैं, हालांकि वे अन्य आवृत्तियों पर हो सकते हैं, और एक-दूसरे से बहुत अलग हो सकते हैं) - खराब रेडियो।

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

---

पूर्ण विश्वसनीयता के साथ और रखरखाव की आवश्यकता के बिना एक प्रणाली बनाना असंभव है। डिवाइस टूट जाते हैं, नेटवर्क में पावर सर्ज होता है, पड़ोसियों के अपार्टमेंट से पानी आता है, बैटरी ड्रेन होती है, प्लास्टिक की दरारें पड़ती हैं, बच्चा लैंप और इतने पर सूप डालता है। लेकिन:

6. मरम्मत, अद्यतन, रखरखाव और निदान सरल होना चाहिए।

बी 2 बी में सब कुछ स्पष्ट है: एक उपयोगकर्ता है, एक डेवलपर है, और एक ऑपरेटर है - एक व्यक्ति या संगठन जो जानता है कि सिस्टम कैसे काम करता है और पेशेवर स्तर पर इसके साथ काम कर सकता है। किसी को 1 सी के तहत प्रोग्रामिंग के एक लेखा ज्ञान की आवश्यकता नहीं है, यह एक विशेष व्यक्ति है। और किसी को भी ऐसे व्यक्ति की आवश्यकता नहीं है जो यह समझने के लिए कार्यालय में किराए पर लेता हो कि उसमें वेंटिलेशन कैसे काम करता है - उसका काम यह कहना है: "यह हमारे कार्यालय में सामान है।"

एक प्रणाली खरीदने का एक सक्षम निर्णय स्वामित्व की कुल लागत की गणना पर आधारित है, जो कि प्रणाली की कीमत और इसके संचालन की लागत का योग है।
उन प्रणालियों में जो एक व्यक्ति घर पर उपयोग करता है, सब कुछ अधिक जटिल है। वहां, ऑपरेटर और उपयोगकर्ता एक और एक ही व्यक्ति हैं, और इसके अलावा अक्सर सिस्टम के बारे में आवश्यक ज्ञान नहीं होता है। दुर्भाग्य से, ये उपभोक्ता बाजार की सीमाएं हैं। इसलिए निम्नलिखित सिद्धांत:

6.1। डिवाइस को काम करना चाहिए या नहीं। कोई तीसरा नहीं है।

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

यदि आप दृढ़ता से आश्वस्त हैं कि कार्यक्षमता में गिरावट स्वीकार्य है, तो आपको उपयोगकर्ता को स्पष्ट संदेश के साथ चेतावनी देनी चाहिए: “दूसरे डिमर चैनल की विफलता का पता चला है। डिमर को बदलना आवश्यक है। पहले डिमर चैनल का उपयोग करना जारी रखें? हां / नहीं

6.2। टूटे हुए उपकरण को बदलना आसान होना चाहिए।

सिस्टम मॉड्यूलर होना चाहिए। यदि उपयोगकर्ता सेंसर को तोड़ता है, तो उसे केवल सेंसर को बदलना होगा। आप नियंत्रण कक्ष के साथ रिले को बदलने की मांग नहीं कर सकते, क्योंकि, आप देखते हैं, यह उत्पादन स्तर पर इसके साथ जुड़ा हुआ है।

आप यह भी नहीं कह सकते हैं कि "केवल हमारा विशेषज्ञ ही एक नया सेंसर स्थापित कर सकता है", क्योंकि, जाहिर है, आपके सिस्टम के विकास के साथ, लाखों संभावित उपयोगकर्ताओं के लिए पर्याप्त विशेषज्ञ नहीं होंगे, जिसका अर्थ है कि समस्याएं किसी बिंदु पर शुरू होंगी। बेशक, उपयोगकर्ता स्वयं डिवाइस की मरम्मत नहीं करेगा, लेकिन एक टूटने की स्थिति में वह उन्हें बदलने में सक्षम होना चाहिए।

6.3। संदेश साफ़ करें।

अगर कुछ गलत हुआ, तो उपयोगकर्ता को इसके बारे में पता होना चाहिए, और यह जानना चाहिए कि वास्तव में क्या गलत हुआ।
उपयोगकर्ता को "त्रुटि # 45" बताना असंभव है, जिसका अर्थ है कि केवल तकनीकी सहायता कर्मचारी इस संदेश को समझेगा। उसे यह कहने की जरूरत है: “डिवाइस जवाब नहीं दे रहा है। इसे रिबूट करने का प्रयास करें, फिर से बांधें या सेवा से संपर्क करें। त्रुटि # 45. "

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

6.4। संदेशों में अनावश्यक जानकारी का अभाव।

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

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

6.5। रखरखाव के लिए विशेष ज्ञान और उपकरणों की आवश्यकता नहीं होती है।

उपयोगकर्ता को फ़र्मवेयर अपडेट करने का अवसर दें - बस इसे एक-दो बटन दबाकर अपडेट करने दें। और यह या तो मानक इंटरफ़ेस (यूएसबी / बीटी / वाई-फाई) के माध्यम से किया जाएगा, या सामान्य रूप से एसपीआई प्रोग्रामर का उपयोग करके फर्मवेयर को अपडेट करने के बारे में उपयोगकर्ता प्रलेखन में उल्लेख नहीं किया जाएगा।

यदि आपको इस कॉन्फ़िगरेशन को सामान्य उपयोग में आवश्यक है, तो आपको डिवाइस कॉन्फ़िगरेशन के लिए बिट मास्क की गणना करने की आवश्यकता नहीं है।

6.6। सिस्टम को चल रहे रखरखाव की आवश्यकता नहीं होनी चाहिए।

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

6.7। सिस्टम में अपडेट या विस्तार करने की क्षमता होनी चाहिए।

सिस्टम के विस्तार की लागत रैखिक रूप से बढ़नी चाहिए। एक नए ब्लॉक को एक नए ब्लॉक की लागत का खर्च उठाना चाहिए।

ऐसी स्थिति नहीं होनी चाहिए जब आपको नया सेंसर जोड़ने के लिए नया नियंत्रक खरीदने की आवश्यकता हो, क्योंकि पुराना छह सेंसर ⁵ से अधिक का समर्थन नहीं करता है।

ऐसी स्थिति नहीं होनी चाहिए जहां एक नया सेंसर फर्मवेयर केवल नियंत्रण इकाई के नए संस्करण के साथ काम कर सकता है।

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

7. आत्मनिर्भरता: बाहरी नेटवर्क एक विकल्प है, आवश्यकता नहीं।

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

8. केंद्रीकरण: एक केंद्रीय हब की कमी उपलब्ध तर्क को सीमित करती है।

हालांकि, अन्य चरम पर जल्दी मत करो - सिस्टम को विकेंद्रीकृत बनाने की कोशिश करें, और इसलिए बिल्कुल विश्वसनीय।

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

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

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

---

9. सिस्टम को उपयोगकर्ता को पुष्टि या सूचना के बिना संभावित खतरनाक कार्यों को अंजाम नहीं देना चाहिए।

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

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

10. प्रणाली को आत्म-नियंत्रण और आत्म-निदान करने में सक्षम होना चाहिए।

एक सच्चे स्मार्ट सिस्टम डेवलपर को थोड़ा पागल होना चाहिए। आप इंटरनेट पर भरोसा नहीं कर सकते, यह गायब हो सकता है। आप कोड पर भरोसा नहीं कर सकते, इसमें कीड़े हो सकते हैं। शायद कम से कम हार्डवेयर पर भरोसा किया जा सकता है? नहीं। आप अपने हार्डवेयर पर भरोसा नहीं कर सकते। रिले छड़ी कर सकते हैं, triacs अनायास खुले, फ़्यूज़ झटका बाहर। अंत में, उपयोगकर्ता किलोवाट केतली को 100 वाट के आउटलेट में प्लग कर सकता है। सेंसर वोल्टेज, करंट, तापमान चाहिए। क्या तापमान सीमा से बाहर है? सब कुछ बंद करें, एक चेतावनी भेजें। वर्तमान से आगे निकल गया है - इसे बंद करें। उन्होंने रिले को बंद कर दिया, लेकिन आउटपुट पर अभी भी वोल्टेज है? अधिसूचना। चालू है, लेकिन कोई वोल्टेज नहीं है? अधिसूचना!

11. सिस्टम को मैन्युअल रूप से नियंत्रित करने में सक्षम होना चाहिए।

और यहां तक ​​कि इन सभी पागल चीजों के साथ, अभी भी एक ऐसी स्थिति होगी जहां चेक विफल हो गए, और कुछ टूट गया। कमरे, राउटर, सेंट्रल हब में स्विच करें। और उपयोगकर्ता शौचालय में प्रकाश चालू करना चाहता है। निष्कर्ष क्या है?

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

12. डेवलपर्स और हैकर्स आम उपयोगकर्ताओं की तरह ही महत्वपूर्ण हैं।

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

13. खुलापन: सिस्टम में अन्य प्रणालियों के साथ एकीकरण के लिए एपीआई होना चाहिए।

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

14. प्रलेखन: प्रलेखन कोड और हार्डवेयर के रूप में प्रणाली का महत्वपूर्ण हिस्सा है।

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

और अंत में, अंतिम सिद्धांत (लेकिन महत्व के मामले में अंतिम से बहुत दूर):

15. आत्मनिर्भरता और आत्मनिर्भरता: सिस्टम को काम करना जारी रखना चाहिए, भले ही कंपनी ने काम करना बंद कर दिया हो

एक व्यक्ति 70-90 साल रहता है, उसके घर में सिस्टम 5-10 साल (सबसे अच्छा) है, और कंपनियां अक्सर छोटी होती हैं। आपको एक सिस्टम नहीं बनाना चाहिए, जिससे आप अपने साथ कब्र पर काम कर सकें। उपयोगकर्ताओं को दया आती है। सिस्टम को डिज़ाइन करें ताकि इसके साथ काम करना संभव हो, भले ही कंपनी और डेवलपर्स लंबे समय पहले गुम हो गए हों।

क्या डेवलपर के सर्वर से टोकन प्राप्त करने के साथ एक नए डिवाइस की बाइंडिंग होती है? "टोकन प्राप्त करना छोड़ें" बटन बनाएं। जब आप पहली बार सिस्टम चालू करते हैं, तो क्या आपको साइट से फर्मवेयर अपडेट करने की आवश्यकता है? सुनिश्चित करें कि साइट उपलब्ध नहीं होने पर डिफ़ॉल्ट फ़र्मवेयर बाढ़ गया है। और इसी तरह।

---

इस लेख में मैंने ऐसे सिस्टम का उपयोग करने, काम करने और डिजाइन करने के सभी अनुभव का वर्णन करने की कोशिश की, जो 15 बुनियादी सिद्धांतों में संकुचित है। उनमें से कुछ दूर की कौड़ी लग सकते हैं, कुछ विवादास्पद हो सकते हैं (और यह सामान्य है), और कुछ सामान्य हो सकते हैं (और यह भी सामान्य है)।

लेकिन अगर आप उनमें से कम से कम एक के बारे में सोचते हैं, तो इसका मतलब है कि लेख व्यर्थ नहीं लिखा गया था।

फुटनोट्स और टिप्पणियाँ

1. जब मैं कहता हूं कि "उपयोग करें," मेरा मतलब कॉन्फ़िगरेशन प्रक्रिया नहीं है, बल्कि सिस्टम के साथ सामान्य बातचीत की प्रक्रिया है।
2. कृपया ध्यान दें कि मैं यह नहीं कह रहा हूं कि "देरी समान होनी चाहिए", लेकिन "उपयोगकर्ता को नोटिस नहीं करना चाहिए"। अभ्यास से पता चलता है कि एक व्यक्ति को लगभग 300 एमएस तक की देरी दिखाई नहीं देती है।
3. शायद वह मध्य एशिया में बड़ा हुआ और मानता है कि गर्मी के लिए सबसे अच्छा उपाय गर्म हरी चाय है।
4. बेशक, जब मैं कहता हूं "जानकारी दिखाने की कोई आवश्यकता नहीं है", इसका मतलब है कि आपको हर बार उपयोगकर्ता को इसके बारे में संदेश नहीं भेजना चाहिए। इसे उपयोगकर्ता के अनुरोध पर दिखाया जाना चाहिए - "शो लॉग" या "डीबगिंग जानकारी दिखाएं" बटन पर क्लिक करके। उपयोगकर्ताओं को बेवकूफ नहीं माना जाना चाहिए, लेकिन उनके समय का सम्मान किया जाना चाहिए।
5. बेशक, एक ऐसी प्रणाली को डिजाइन करना असंभव है जो अनंत उपकरणों का समर्थन करता है। हमेशा प्रतिबंध रहेगा, लेकिन डेवलपर का कार्य यह सुनिश्चित करना है कि वे 99% मामलों में भूमिका नहीं निभाते हैं। छह सेंसर की एक सीमा अस्वीकार्य है। एक नेटवर्क में एक सौ दो सौ डिवाइस स्मार्ट घरों के अधिकांश उपयोगकर्ताओं के लिए पर्याप्त संख्या है।
6. मैं RFC1983 के अनुसार, हैकर के मूल अर्थ में हैकर्स के बारे में बात कर रहा हूं , न कि हैकर्स के रूप में।