இயந்திரத் தரவு Microsoft Fabric-ஐ எவ்வாறு அடைகிறது - OPC UA முதல் நேரடி பகுப்பாய்வு வரை

ක්‍රියාකාරී යන්ත්‍ර සංඥා, සංවේදක අගයන්, නිෂ්පාදන ගණකයන් සහ දෝෂ සිදුවීම් වලාකුළට ගෙන යාම පෙර වඩා පහසු වී ඇත. OPC UA යන්ත්‍ර සංඥාව නිරාවරණය කරයි, edge ස්ථරය එය එකතු කරයි, MQTT එය දේශීයව බෙදා හැරිය හැකි අතර, Microsoft Fabric හට ලැබෙන ප්‍රවාහය ආදානය කර විශ්ලේෂණය කළ හැක. දුෂ්කර කොටස ආරම්භ වන්නේ දත්ත පැමිණීමෙන් පසුවය: නිශ්චිත තීරණයකට සහාය වීමට ප්‍රමාණවත් නිෂ්පාදන සන්දර්භයක් අමු telemetry දත්ත වලින් ලබා ගන්නේ කෙසේද?

මෙම කථාංගය කර්මාන්ත පිටියේ සිට Microsoft industrial data stack හරහා එක් යන්ත්‍ර සංඥාවක් අනුගමනය කරයි. එය OPC UA වලින් ආරම්භ වී, edge සහ MQTT හරහා ගමන් කර, Azure සහ Microsoft Fabric වෙත ආරක්ෂිතව ගමන් කරයි, ඉන් පසු Eventstream, Eventhouse, KQL, Lakehouse, Power BI, MES, ERP, නඩත්තු දත්ත සහ නිෂ්පාදන සන්දර්භය එකිනෙක ගැලපෙන ආකාරය පරීක්ෂා කරයි. අරමුණ සරලව තවත් telemetry pipeline එකක් පෙන්වීම නොවේ. යන්ත්‍ර දත්ත නිෂ්පාදනය, නඩත්තුව, guණාත්මකභාවය සහ සැලසුම්කරණය සඳහා ප්‍රයෝජනවත් වීමට පෙර සිදු විය යුතු දේ පැහැදිලි කිරීමයි.

යන්ත්‍ර නැවතීමේ සිට නිෂ්පාදන ප්‍රතිවිපාකය දක්වා

පාලක මට්ටමින් යන්ත්‍ර නැවතීමක් සරල ලෙස පෙනේ. තත්වය ධාවනයෙන් දෝෂ සහිත තත්වයට වෙනස් වේ, දෝෂ කේතයක් දිස්වේ, කොටස් ගණකය නතර වන අතර, එම මොහොතේ වටා වෙනත් අගයන් ද වෙනස් විය හැක. මෙම තොරතුරු ප්‍රයෝජනවත් නමුත්, නිෂ්පාදනය සාමාන්‍යයෙන් වෙනස් ප්‍රශ්නයක් අසයි: කුමන වැඩ ඇණවුම බලපායිද, ඉතිරි ප්‍රමාණය කීයද, වෙනත් යන්ත්‍රයකට ඉඩ තැබිය හැකිද, මෙම ප්‍රමාදය බෙදාහැරීමකට තර්ජනයක් වේද?

යන්ත්‍රය තමාගේ තත්වය තේරුම් ගනී, නමුත් ව්‍යාපාර ප්‍රතිවිපාකය ස්වයංක්‍රීයව තේරුම් නොගනී. MES හට මෙහෙයුම සහ වැඩ ඇණවුම දැන සිටිය හැක. ERP හට නියමිත දිනය සහ ඉල්ලුම දැන සිටිය හැක. නඩත්තුව උපකරණ ඉතිහාසය තේරුම් ගත හැක. Quality මගින් ප්‍රතිදානය තවමත් භාවිතා කළ හැකිද යන්න තීරණය කළ හැක. එබැවින් වේගවත් telemetry pipeline එකක් ආරම්භය පමණි, සම්පූර්ණ ගෘහනිර්මාණය නොවේ.

OPC UA — සංඥාව දත්ත මාර්ගයට ඇතුළු වන ස්ථානය

OPC UA මගින් සෑම cloud යෙදුමක්ම proprietary controller protocols තේරුම් ගැනීමට අවශ්‍ය නොවී උපකරණවලින් තොරතුරු ප්‍රවේශ වීම සඳහා සම්මත කර්මාන්ත අතුරුමුහුණතක් සපයයි. සේවාදායකයක් variables, යන්ත්‍ර තත්වයන්, alarms, events, methods, timestamps, quality තොරතුරු සහ සමහර විට ව්‍යුහගත උපකරණ ආකෘති නිරාවරණය කළ හැක.

මෙම ව්‍යුහය වැදගත් වන්නේ ප්‍රයෝජනවත් කර්මාන්ත සිදුවීමක් සංඛ්‍යාත්මක අගයකට වඩා වැඩි දෙයක් රැගෙන යා යුතු බැවිනි. මූලාශ්‍ර timestamps, server timestamps, quality තත්වය, ඒකක, මූලාශ්‍ර අනන්‍යතාවය සහ මුල් OPC UA node තොරතුරු පසුව වැදගත් විය හැක, එනම් අංකයක් කොහෙන් ආවාද හෝ නිෂ්පාදන ගණනය කිරීමක් වැරදි ලෙස පෙනෙන්නේ ඇයි කියා කෙනෙක් ඇසූ විට.

tag නමක් දත්ත ආකෘතියක් නොවන බවද කථාංගය අවධාරණය කරයි. "temperature" හෝ "machine state" යන නමක් තවමත් asset, engineering unit, අනුමත පරාසය, තත්ව නිර්වචනය සහ සංඥාව නිරීක්ෂණය කළ නිෂ්පාදන තත්වය වැනි සන්දර්භය අවශ්‍ය කරයි.

OT සීමාව පාලනය කරන්න

යන්ත්‍ර සම්බන්ධතාවය නිෂ්පාදන ජාලය සමාගම හෝ cloud පරිසරයේ දිගුවක් බවට පත් නොකළ යුතුය. කර්මාන්ත ජාල සඳහා සාමාන්‍යයෙන් කොටස් බෙදීම සහ industrial DMZ ඇතුළුව පාලිත සීමා අවශ්‍ය වන අතර, අනුමත edge පද්ධති නියන්ත්‍රක වෙත සෘජු ප්‍රවේශයක් නොමැතිව උද්‍යෝගී යෙදුම් වලට සම්බන්ධ විය හැකිය.

නිර්දේශිත රටාව සාමාන්‍යයෙන් outbound-oriented වේ. edge ස්ථරය අනුමත OPC UA endpoints වෙත සම්බන්ධ වී, පාලිත ගමනාන්ත, ports, protocols සහ අනන්‍යතා හරහා cloud සේවා වෙත තෝරාගත් තොරතුරු යවයි. විශ්ලේෂණ වේදිකා නිෂ්පාදන පද්ධති පිරික්සීමට හෝ වෙනස් කිරීමට පුළුල් අයිතිවාසිකම් නොමැතිව දත්ත ලබා ගත යුතුය.

සහතික, firewall නීති, විශ්වාස සම්බන්ධතා, කල්ඉකුත්වීම හැසිරවීම සහ හිමිකාරිත්වය ද එක් වරක් වින්‍යාස කිරීමේ කාර්යයක් නොව මෙහෙයුම් ක්‍රියාවලීන් ලෙස සැලකිය යුතුය.

Edge මගින් දත්ත වැඩිදියුණු කළ යුතුය — ව්‍යාපාර අර්ථය නිර්මාණය නොකළ යුතුය

Edge ස්ථරය යන්ත්‍ර පරිසරය සහ පුළුල් දත්ත වේදිකාව අතර පිහිටයි. එහි පළමු වගකීම සම්බන්ධතාවය වුවද, එය දත්ත ඇතුළත් කිරීම, සම්මත කිරීම, බෆර කිරීම, පොහොසත් කිරීම සහ මාර්ගගත කිරීම ද කළ හැක.

ප්‍රයෝජනවත් edge වගකීම්:
• නිර්වචනය කළ භාවිත අවස්ථා සඳහා අවශ්‍ය සංඥා පමණක් තෝරාගැනීම
• අනවශ්‍ය ඉහළ-සංඛ්‍යාත දත්ත පෙරීම
• එකඟ වූ ඒකක පරිවර්තන යෙදීම
• මූලාශ්‍ර timestamps සහ quality දර්ශක ආරක්ෂා කිරීම
• ස්ථාවර site, line සහ asset අනන්‍යතා එකතු කිරීම
• cloud බිඳවැටීම් අතරතුර බෆර කිරීම
• retry සහ back-pressure හැසිරීම හැසිරවීම
• connector සහ queue සෞඛ්‍යය නිරාවරණය කිරීම
• ප්‍රමාදය හෝ විසන්ධි වූ මෙහෙයුම අවශ්‍ය වන විට තෝරාගත් දේශීය ගණනය කිරීම් හෝ AI inference කිරීම

වැදගත් සීමාව නම්, edge ස්ථරය විශ්වාසයෙන් දන්නා කරුණු පමණක් එකතු කළ යුතුය. පැරණි තොරතුරු මත පදනම්ව ක්‍රියාකාරී නිෂ්පාදන ඇණවුම අනුමාන නොකළ යුතු අතර, MES, ERP, සැලසුම් හෝ quality පද්ධති සඳහා අයත් ව්‍යාපාර සන්දර්භය නිහඬව නිර්මාණය නොකළ යුතුය.

Azure IoT Edge එදිරිව Azure IoT Operations

කථාංගය කර්මාන්ත edge වැඩ ක්‍රියාත්මක කිරීම සඳහා Microsoft ප්‍රවේශ දෙකක් සසඳයි.
Azure IoT Edge gateway හෝ තනි උපාංගය වටා නිශ්චිත අවශ්‍යතාවයක් ඇති විට හොඳින් ක්‍රියා කරයි. containerized modules දත්ත එකතු කළ හැක, දේශීය තර්කනය යෙදිය හැක, තොරතුරු බෆර කළ හැක, සහ Azure IoT Hub හරහා upstream යැවිය හැක. සංවිධානයට සැහැල්ලු මෙහෙයුම් පියසටහනක් අවශ්‍ය වන විට නිශ්චිත cell එකක් හෝ කුඩා වැඩ බරක් සඳහා මෙය ප්‍රායෝගික තේරීමක් විය හැක.

Azure IoT Operations වඩාත් site-level කර්මාන්ත දත්ත පරිසරයක් ලෙස ස්ථානගත වේ. එය Azure Arc-enabled Kubernetes පරිසරයක ක්‍රියා කරන අතර OPC UA connectivity, MQTT, data flows සහ asset හෝ device කළමනාකරණය වටා හැකියාවන් ඇතුළත් කරයි. සයිට් එකක රේඛා කිහිපයක්, බහු උපකරණ විකුණුම්කරුවන්, දේශීය පාරිභෝගිකයන් සහ governed edge රටාව කම්හල් අතර පුනරාවර්තනය කිරීමේ අවශ්‍යතාවයක් ඇති විට මෙය වඩාත් සුදුසු විය හැක.

තීරණය වැඩිම feature ලැයිස්තුව ඇති වේදිකාව මත පදනම් නොවිය යුතුය. එය පදනම් විය යුත්තේ සංවිධානය සහාය දැක්වීමට සූදානම් මෙහෙයුම් ආකෘතිය මත ය. Azure IoT Operations පුළුල් site-level හැකියාවන් සපයන නමුත්, එය Kubernetes, Arc, cluster මෙහෙයුම්, අධීක්ෂණය, storage, patching සහ recovery වගකීම් ද හඳුන්වා දෙයි.

MQTT — කර්මාන්ත සිදුවීම් පසුබිම ලෙස

බහු පාරිභෝගිකයන්ට එකම යන්ත්‍ර සිදුවීම් අවශ්‍ය වන විට, MQTT මගින් ගෘහනිර්මාණය විශාල වශයෙන් සරල කළ හැක. යන්ත්‍ර connector එක broker වෙත එක් වරක් publish කරන අතර, නඩත්තු යෙදුම්, දේශීය historians, cloud data flows, හෝ වෙනත් අනුමත පාරිභෝගිකයන් ස්වාධීනව subscribe වේ.

එය බොහෝ point-to-point යැපීම් ඉවත් කරයි. නව යෙදුමකට PLC හෝ OPC UA server වෙත තවත් සෘජු සම්බන්ධයක් නිර්මාණය නොකර අනුමත topic එකකට subscribe විය හැක.

Topic නිර්මාණය තවමත් වැදගත් වේ. උසස් මට්ටමේ ධුරාවලියකට site, area, line, cell සහ asset නිරූපණය කළ හැක, නමුත් topic එක සම්පූර්ණ දත්ත ආකෘතිය බවට පත් නොවිය යුතුය. සිදුවීම් අනන්‍යතාවය, මූලාශ්‍ර timestamp, asset ID, quality, contract version සහ event type වැනි වැදගත් කරුණු message payload තුළ තබා ගත යුතුය, එවිට සිදුවීම ගබඩා කළ, නැවත ධාවනය කළ, හෝ වෙනත් තැනකට යොමු කළ විට පවා තේරුම් ගත හැකි වේ.

Unified Namespace යනු ගිවිසුමකි — topic ගසක් පමණක් නොවේ

Unified Namespace රටාව කර්මාන්ත පද්ධති අතර බෙදාගත් මෙහෙයුම් ගිවිසුමක් සැපයිය හැක. ප්‍රයෝජනවත් කොටස වන්නේ එක් විශාල MQTT ධුරාවලියක් තිබීම පමණක් නොවේ. වටිනාකම ලැබෙන්නේ asset අනන්‍යතා කෙසේ හඳුනාගන්නේද, සිදුවීම් කෙසේ හැඩගස්වන්නේද, දත්ත හිමිකාරිත්වය කාටද, schema වෙනස්වීම් කෙසේද, සහ විවිධ කරුණු සඳහා කුමන පද්ධති අධිකාරී වන්නේද යන්න එකඟ වීමෙනි.

හොඳ Unified Namespace එකක් මූලාශ්‍ර පද්ධතිවලට තම වාර්තා වලට හිමිකාරිත්වය තබා ගැනීමට ඉඩ දෙමින්, asset අනන්‍යතා හඳුනා ගැනීමට සහ පාලිත මෙහෙයුම් සිදුවීම් ප්‍රකාශයට පත් කිරීමට ස්ථාවර ක්‍රමයක් සැපයිය හැක.

එම ගිවිසුම පහත දේවල් නිර්වචනය කළ යුතුය:
• Asset අනන්‍යතාව
• සිදුවීම් වර්ග
• Message ආකෘතිය
• Timestamp නීති
• Quality තොරතුරු
• හිමිකාරිත්වය
• ආරක්ෂාව
• Versioning
• වෙනස්කම් කළමනාකරණය

MQTT මගින් ගිවිසුම ප්‍රවාහනය කළ හැක, නමුත් MQTT ගිවිසුම නිර්මාණය නොකරයි.

OPC UA දැනුම්දීමේ සිට MQTT සිදුවීම දක්වා

OPC UA දැනුම්දීමක් MQTT සිදුවීමක් බවට පරිවර්තනය කිරීම protocol පරිවර්තනයකට වඩා වැඩිය. Connector එක ... (ඉහත පෙළ අවසන් වේ)