IoT Hub മെസേജ് റൂട്ടിംഗ് vs Event Grid — ടെലിമെട്രിയും ഇവന്റുകളും ഒരേ പ്രശ്നമല്ല എന്തുകൊണ്ട്

ഒരു മെഷീൻ ഓരോ കുറച്ച് സെക്കൻഡിലും താപനില റീഡിംഗുകൾ, വൈബ്രേഷൻ ഡാറ്റ, സൈക്കിൾ എണ്ണങ്ങൾ, വൈദ്യുതി ഉപഭോഗം, പ്രവർത്തന അവസ്ഥകൾ എന്നിവ അയയ്ക്കുന്നു. പിന്നീട് ഗേറ്റ്‌വേ പെട്ടെന്ന് വിച്ഛേദിക്കപ്പെടുന്നു. ഈ സന്ദേശങ്ങൾ എല്ലാം വെറും "ഇവന്റുകൾ" ആണോ? സാങ്കേതികമായി, അങ്ങനെ വിശേഷിപ്പിക്കാം. എന്നാൽ ആർക്കിടെക്ചർ തലത്തിൽ, അത് ഗൗരവമുള്ള പ്രശ്നങ്ങൾ സൃഷ്ടിക്കാം. Azure IoT Hub Message Routing ഉം Azure Event Grid ഉം വ്യത്യസ്ത പ്രശ്നങ്ങളാണ് പരിഹരിക്കുന്നത്. ഒരു പാത പ്രവർത്തന ഡാറ്റ സംരക്ഷിക്കാനും വിതരണം ചെയ്യാനും രൂപകൽപ്പന ചെയ്തതാണ്. മറ്റൊന്ന് എന്തെങ്കിലും മാറിയെന്നും പ്രതികരണം ആവശ്യമായിരിക്കാമെന്നും സിസ്റ്റങ്ങളെ അറിയിക്കാൻ രൂപകൽപ്പന ചെയ്തതാണ്. ഇവ പരസ്പരം മാറ്റാവുന്നവയായി കണക്കാക്കുന്നത് ചെലവേറിയ വർക്ക്ഫ്ലോകൾ സാധാരണ സെൻസർ ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്നതിലേക്കോ, ആരും സജീവമായി നിരീക്ഷിക്കാത്ത ടെലിമെട്രി പൈപ്പ്‌ലൈനിനുള്ളിൽ പ്രധാന സിഗ്നലുകൾ മറഞ്ഞുപോകുന്നതിലേക്കോ നയിക്കാം. M365 FM-ന്റെ ഈ എപ്പിസോഡിൽ, ഒരു യഥാർത്ഥ Azure IoT ആർക്കിടെക്ചറിലൂടെ ഒരു നിർമ്മാണ മെഷീനെ പിന്തുടരുന്നു, കൂടാതെ IoT Hub, Event Grid, Event Hubs, Microsoft Fabric, Power BI, MES, ERP, Functions, Logic Apps എന്നിവ യഥാർത്ഥത്തിൽ എവിടെ ഉൾപ്പെടുന്നു എന്ന് വിശദീകരിക്കുന്നു.

നിങ്ങൾ പഠിക്കുന്നത്:

• മെഷീൻ ടെലിമെട്രിക്കും വ്യത്യസ്തമായ ബിസിനസ് അല്ലെങ്കിൽ ജീവിതചക്ര ഇവന്റുകൾക്കും വ്യത്യസ്ത ആർക്കിടെക്ചർ പാറ്റേണുകൾ ആവശ്യമായിരിക്കുന്നത് എന്തുകൊണ്ട്
• ടെലിമെട്രി ഡാറ്റ പ്ലെയ്നിന്റെ ഭാഗമായി Azure IoT Hub Message Routing എങ്ങനെ പ്രവർത്തിക്കുന്നു
• ഇവന്റ്-ഡ്രിവൺ, റിയാക്ടീവ് ആർക്കിടെക്ചറുകളിൽ Azure Event Grid എവിടെ യോജിക്കുന്നു
• നിർമ്മാണ ടെലിമെട്രിക്ക് സന്ദേശ ക്രമം പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്
• Event Grid നിങ്ങളുടെ പ്രധാന ഉയർന്ന-വോളിയം ടെലിമെട്രി ബസ് ആകരുതാത്തത് എന്തുകൊണ്ട്
• എല്ലാ അറിയിപ്പ് വർക്ക്ഫ്ലോകളിലും IoT Hub റൂട്ടിംഗ് നിർബന്ധമാക്കരുതാത്തത് എന്തുകൊണ്ട്
• IoT Hub ഉം Event Grid ഉം ഒരേ ആർക്കിടെക്ചറിൽ എങ്ങനെ ഒരുമിച്ച് പ്രവർത്തിക്കാം
• സ്വതന്ത്ര സ്ട്രീം-പ്രോസസ്സിംഗ് കൺസ്യൂമറുകളെ Event Hubs എങ്ങനെ പിന്തുണയ്ക്കാം
• ട്രേസബിലിറ്റിക്കും പിന്നീടുള്ള അന്വേഷണത്തിനുമായി റോ ടെലിമെട്രി പലപ്പോഴും സൂക്ഷിക്കേണ്ടത് എന്തുകൊണ്ട്
• തയ്യാറാക്കിയ പ്രവർത്തന ഡാറ്റ Microsoft Fabric ഉം Power BI ഉം എങ്ങനെ ഉപയോഗിക്കാം
• ഉപകരണ ഡാറ്റയ്ക്ക് മാത്രം നൽകാനാകാത്ത സന്ദർഭം MES, ERP, അസറ്റ് മോഡലുകൾ എങ്ങനെ നൽകുന്നു
• ഉപകരണ വിച്ഛേദ ഇവന്റുകൾ ഉൽപ്പാദനം നിലച്ചു എന്ന് സ്വയമേവ അനുമാനിക്കാതെ എങ്ങനെ വ്യാഖ്യാനിക്കണം
• ഡ്യൂപ്ലിക്കേറ്റ് ഡെലിവറി, റീട്രൈകൾ, ടൈംസ്റ്റാമ്പുകൾ, ഐഡംപോട്ടൻസി എന്നിവ വിശ്വസനീയമായ വ്യാവസായിക ആർക്കിടെക്ചറുകളെ എങ്ങനെ ബാധിക്കുന്നു
• കണ്ടീഷൻ മോണിറ്ററിംഗ്, പ്രവചനാത്മക മെയിന്റനൻസ്, ഗുണനിലവാര ട്രേസബിലിറ്റി, ഉൽപ്പാദന തടസ്സ വർക്ക്ഫ്ലോകൾ എന്നിവ എങ്ങനെ രൂപകൽപ്പന ചെയ്യാം
• ഒരു സന്ദേശം ഡാറ്റ പ്ലെയ്നിലാണോ, പ്രതികരണ പാതയിലാണോ, അല്ലെങ്കിൽ രണ്ടിലുമാണോ ഉൾപ്പെടേണ്ടതെന്ന് എങ്ങനെ തീരുമാനിക്കാം

ടെലിമെട്രി എന്നത് കാലക്രമേണയുള്ള ഒരു രേഖയാണ്

ഒരു താപനില റീഡിംഗ് ലഭിച്ചു എന്നതുകൊണ്ടല്ല ടെലിമെട്രി മൂല്യവത്താകുന്നത്. ആയിരക്കണക്കിന് റീഡിംഗുകൾ ഒരുമിച്ച് ചേർന്ന് എന്താണ് സംഭവിച്ചത് എന്ന് വിവരിക്കുമ്പോഴാണ് അത് മൂല്യവത്താകുന്നത്. ഒരു ഉൽപ്പാദന മെഷീൻ തുടർച്ചയായി ഇവ റിപ്പോർട്ട് ചെയ്തേക്കാം:

• താപനിലയും വൈബ്രേഷൻ അളവുകളും
• മോട്ടോർ കറന്റും ഊർജ്ജ ഉപഭോഗവും
• സൈക്കിൾ എണ്ണങ്ങളും ഉൽപ്പാദന കൗണ്ടറുകളും
• റണ്ണിംഗ്, ഐഡിൽ, സ്റ്റോപ്പ്ഡ്, അല്ലെങ്കിൽ ഫോൾട്ടഡ് അവസ്ഥകൾ
• സോഴ്സ് ടൈംസ്റ്റാമ്പുകളും സീക്വൻസ് വിവരങ്ങളും
• ഡയഗ്നോസ്റ്റിക്, ഉപകരണ ആരോഗ്യ വിവരങ്ങൾ

ഒരൊറ്റ താപനില മൂല്യം വളരെ കുറച്ച് മാത്രമേ അർത്ഥമാക്കുന്നുള്ളൂ. ചുറ്റുമുള്ള സീക്വൻസാണ് കഥ പറയുന്നത്. മെഷീൻ ചൂടാകുകയായിരുന്നോ? അത് ഇതിനകം ഉൽപ്പാദിപ്പിക്കുകയായിരുന്നോ? അതേ സമയം വൈബ്രേഷൻ വർധിക്കുകയായിരുന്നോ? സൈക്കിൾ സമയം കൂടാൻ തുടങ്ങിയോ? അതിനുശേഷം താമസിയാതെ മെഷീൻ നിന്നുപോയോ? അതിനാൽ ടെലിമെട്രിക്ക് ക്രമം, റീട്ടെൻഷൻ, റീപ്ലേ, സ്വതന്ത്ര കൺസ്യൂമറുകൾ, ട്രേസബിലിറ്റി എന്നിവയെ ചുറ്റിപ്പറ്റി രൂപകൽപ്പന ചെയ്ത ഒരു പാത ആവശ്യമാണ്.

പ്രതികരണം ആരംഭിക്കാനാണ് ഇവന്റുകൾ നിലനിൽക്കുന്നത്

ഇവന്റിന് മറ്റൊരു ലക്ഷ്യമുണ്ട്. ഒരു ഇവന്റ് പറയുന്നു: എന്തോ മാറി. ഒരു സിസ്റ്റമോ വ്യക്തിയോ പ്രതികരിക്കേണ്ടി വന്നേക്കാം. ഉദാഹരണങ്ങൾ:

• ഒരു പുതിയ ഉപകരണം രജിസ്റ്റർ ചെയ്തു
• ഒരു ഗേറ്റ്‌വേ IoT Hub-ൽ നിന്ന് വിച്ഛേദിച്ചു
• ഒരു ഉപകരണം വീണ്ടും കണക്റ്റ് ചെയ്തു
• ഒരു ഉപകരണം ഇല്ലാതാക്കി
• അന്വേഷണം ആവശ്യമായ ഒരു അവസ്ഥ മോണിറ്ററിംഗ് പ്രോസസ് കണ്ടെത്തി
• ഒരു പരിശോധന പൂർത്തിയായി, മറ്റൊരു വർക്ക്ഫ്ലോ ആരംഭിക്കാം

സ്വീകർത്താവിന് സാധാരണയായി ആദ്യ ഘട്ടം ആരംഭിക്കാൻ മണിക്കൂറുകളുടെ ടെലിമെട്രി ആവശ്യമില്ല. എന്ത് സംഭവിച്ചു എന്ന് തിരിച്ചറിയാനും ഉചിതമായ പ്രതികരണം നിർണ്ണയിക്കാനും മതിയായ വിവരങ്ങൾ മാത്രം മതി. ആ പ്രതികരണത്തിൽ ഇവ ഉൾപ്പെടാം:

• Azure Function ആരംഭിക്കൽ
• Logic App ട്രിഗർ ചെയ്യൽ
• സപ്പോർട്ട് അന്വേഷണം തുറക്കൽ
• അസറ്റ് റെക്കോർഡ് അപ്‌ഡേറ്റ് ചെയ്യൽ
• ഉപകരണത്തിന്റെ നിലവിലെ അവസ്ഥ പരിശോധിക്കൽ
• Webhook വഴി ബാഹ്യ ആപ്ലിക്കേഷൻ വിളിക്കൽ
• ബാധിതമായ സിസ്റ്റത്തിന് ഉത്തരവാദിത്തമുള്ള ടീമിനെ അറിയിക്കൽ

ഇവന്റ് അന്വേഷണം ആരംഭിക്കുന്നു. അന്തിമ പ്രവർത്തന തീരുമാനത്തിന് ആവശ്യമായ എല്ലാ വസ്തുതകളും അത് സാധാരണയായി ഉൾക്കൊള്ളുന്നില്ല.

"എല്ലാം ഒരു ഇവന്റ്" എന്ന രീതി പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്

ഓരോ സെൻസർ അളവും ഇവന്റ്-ട്രിഗർ ചെയ്ത വർക്ക്ഫ്ലോകളിലേക്ക് അയയ്ക്കുന്നത് ഒരു പ്രൂഫ് ഓഫ് കോൺസെപ്റ്റിൽ ആകർഷകമായി തോന്നാം. പിന്നീട് പ്രൊഡക്ഷൻ സ്കെയിൽ വരുന്നു. ഓരോ റീഡിംഗും മറ്റൊരു Function ട്രിഗർ ചെയ്യുന്നു. മറ്റൊരു Logic App എന്തെങ്കിലും വിലയിരുത്തുന്നു. മറ്റൊരു ഇന്റഗ്രേഷൻ മറ്റൊരു സന്ദേശം സ്വീകരിക്കുന്നു. മെയിന്റനൻസ് സ്വന്തം സബ്സ്ക്രിപ്ഷൻ സൃഷ്ടിക്കുന്നു. ക്വാളിറ്റി മറ്റൊന്ന് സൃഷ്ടിക്കുന്നു. എനർജി മാനേജ്‌മെന്റ് മറ്റൊന്ന്. താമസിയാതെ, ഓരോ ടീമിനും അല്പം വ്യത്യസ്തമായ ഫിൽട്ടറിംഗ്, സ്റ്റേറ്റ് മാനേജ്‌മെന്റ്, റീട്രൈ കൈകാര്യം ചെയ്യൽ, സ്റ്റോറേജ് ലോജിക് ഉണ്ടാകുന്നു. ഒരു താപനില അളവ് സ്വയമേവ ഒരു സംഭവമല്ല. പിന്നീട് ഒരു സംഭവത്തിന് കാരണമായേക്കാം, എന്നാൽ തുടർച്ചയായ അളവുകൾ തെളിവായി ലഭ്യമായി തുടരണം. റൂട്ടീൻ ടെലിമെട്രി തുടർച്ചയായ അറിയിപ്പുകൾ സൃഷ്ടിക്കുമ്പോൾ, ഉപയോക്താക്കൾ അലേർട്ടുകൾ അവഗണിക്കാൻ തുടങ്ങാം, കാരണം സിസ്റ്റം അവരെ പ്രവർത്തനക്ഷമമായ വിവരത്തിന് പകരം ശബ്ദത്തിന് ശീലിപ്പിച്ചിരിക്കുന്നു.

Azure IoT Hub യഥാർത്ഥത്തിൽ ചെയ്യുന്നത്

Azure IoT Hub ഉപകരണങ്ങളെ അഭിമുഖീകരിക്കുന്ന ക്ലൗഡ് അതിർത്തി നൽകുന്നു. ഇവ പോലുള്ള മേഖലകളെ ഇത് പിന്തുണയ്ക്കുന്നു:

• സുരക്ഷിത ഉപകരണ ഐഡന്റിറ്റികൾ
• ഡിവൈസ്-ടു-ക്ലൗഡ് മെസേജിംഗ്
• ക്ലൗഡ്-ടു-ഡിവൈസ് ആശയവിനിമയം
• ഡിവൈസ് മാനേജ്‌മെന്റ്
• ഡിവൈസ് ട്വിനുകൾ
• കണക്റ്റ് ചെയ്ത ഉപകരണങ്ങളും Azure സേവനങ്ങളും തമ്മിലുള്ള നിയന്ത്രിത ആക്സസ്

ഒരു പ്രമാണീകരിച്ച ഉപകരണം ഒരു സന്ദേശം അയച്ചു എന്ന് IoT Hub അറിയുന്നു. ആ സന്ദേശം ഉൽപ്പാദനത്തിന് എന്ത് അർത്ഥമാക്കുന്നു എന്ന് അത് സ്വയമേവ മനസ്സിലാക്കുന്നില്ല. ഒരു ഗേറ്റ്‌വേ ഇങ്ങനെ റിപ്പോർട്ട് ചെയ്തേക്കാം: state = running എന്നാൽ "running" എന്നതിന് ഇവ അർത്ഥമാകാം:

• അംഗീകൃത ഭാഗങ്ങൾ ഉൽപ്പാദിപ്പിക്കൽ
• മെറ്റീരിയൽ ഇല്ലാതെ ഡ്രൈ സൈക്ലിംഗ്
• സെറ്റപ്പ് നടത്തൽ
• റീവർക്ക് ചെയ്യൽ
• മെറ്റീരിയൽ ഇല്ലാതെ നീങ്ങൽ

ആ സന്ദർഭം സാധാരണയായി MES, ERP, അസറ്റ് മോഡൽ, അല്ലെങ്കിൽ പ്രൊഡക്ഷൻ ആപ്ലിക്കേഷൻ പോലുള്ള അധിക സിസ്റ്റങ്ങളിൽ നിന്നാണ് വരുന്നത്.

ഈ പോഡ്കാസ്റ്റിന് പിന്തുണ നൽകുക: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.