إنترنت الأشياء (Internet of Things — IoT) منظومة من الأجهزة المادية المتصلة التي تجمع بيانات من العالم الحقيقي، وتنقلها عبر شبكات الاتصال، ثم تستخدمها تطبيقات أو أنظمة معالجة لاتخاذ قرار أو تنفيذ إجراء.
قد يكون "الشيء" حساس حرارة صغيرًا، أو عداد كهرباء، أو ساعة ذكية، أو آلة صناعية، أو سيارة، أو كاميرا، أو نظام ري، أو جهازًا طبيًا. لكن اتصال الجهاز بالإنترنت وحده لا يجعل منه نظام IoT متكاملًا.
فالمنظومة تتكون غالبًا من سلسلة مترابطة تبدأ من العالم الفيزيائي نفسه، حيث تلتقط الحساسات والأجهزة قياسات واقعية كالحرارة والرطوبة والحركة. تعبر هذه القياسات طبقة الاتصال نحو بوابة أو عقدة Edge تجمع البيانات وتنقيها وربما تعالجها محليًا قبل رفعها، ثم تصل إلى منصة سحابية أو محلية تتولى المعالجة والتحليلات، فتحوّل البيانات الخام إلى معلومات ذات معنى. وفي قمة السلسلة يقف التطبيق الذي يترجم هذه المعلومات إلى قرار، والفعل أو الأتمتة التي تنفذ القرار في العالم الحقيقي، فتكتمل الدورة التي بدأت بحساس وانتهت بمحرك أو صمام أو إشعار.
فالقيمة الحقيقية لا تأتي من "ربط الأشياء" فحسب، بل من تحويل القياسات إلى معلومات، ثم إلى قرار أو فعل.
كيف يعمل إنترنت الأشياء؟ حلقة نظام ري ذكي
يتضح منطق IoT حين نتتبع نظام ري ذكيًا خطوة بخطوة. تبدأ الحلقة بـالاستشعار: حساس في التربة يقيس الرطوبة ودرجة الحرارة وربما الإضاءة. ثم تأتي مرحلة التحويل إلى بيانات، حيث تتحول القياسات الفيزيائية إلى قيم رقمية، كأن تكون رطوبة التربة 21% والحرارة 31 درجة مئوية.
بعدها يأتي الاتصال، فيرسل الجهاز بياناته بتقنية مناسبة، سواء كانت Bluetooth LE أو Wi‑Fi أو Zigbee أو Thread أو LoRaWAN أو NB‑IoT أو LTE‑M أو 5G. وتنتقل البيانات إلى المعالجة، فقد تصل إلى بوابة محلية، أو خادم Edge، أو منصة سحابية، أو نظام داخل المؤسسة.
ثم يأتي القرار: فقد يطبق النظام قاعدة بسيطة، كتشغيل الري حين تنخفض رطوبة التربة عن عتبة محددة، أو يستخدم تحليلًا أعقد يجمع حالة التربة والطقس والمحصول واستهلاك المياه والبيانات التاريخية. وأخيرًا التنفيذ: يُرسل أمر إلى صمام المياه لتشغيل الري.
هذه الحلقة، أي الاستشعار ثم الاتصال ثم المعالجة ثم القرار ثم التنفيذ، هي جوهر عدد كبير من أنظمة IoT.
المكونات الأساسية لنظام IoT
الأجهزة والمستشعرات
هي نقطة التماس مع العالم الحقيقي، وقد تقيس الحرارة والرطوبة والضغط والاهتزاز والضوء والموقع والسرعة والتدفق وجودة الهواء والمؤشرات الحيوية. وقد تضم أيضًا مشغلات (Actuators) تنفذ أوامر مثل فتح صمام، أو تشغيل محرك، أو تغيير درجة حرارة، أو إغلاق قفل، أو إيقاف آلة.
المتحكم أو الحاسوب المدمج
يستقبل بيانات المستشعرات ويعالج جزءًا منها، وقد يكون متحكمًا دقيقًا (Microcontroller)، أو نظامًا على شريحة (SoC)، أو PLC، أو جهازًا يعمل بـEmbedded Linux، أو متحكمًا صناعيًا. وليس من الضروري إرسال كل قراءة خام إلى السحابة.
طبقة الاتصال
تنقل البيانات بين الأجهزة وبقية النظام، والاختيار فيها يغيّر استهلاك الطاقة، والمدى، والتكلفة، والسرعة، وزمن الاستجابة، وعمر البطارية، وسهولة النشر.
البوابة (Gateway)
بعض الأجهزة لا تتصل بالسحابة مباشرة. فقد يتصل حساس BLE قصير المدى بـGateway قريبة تستقبل إرسالاته، فتتولى البوابة تمرير البيانات عبر الإنترنت إلى السحابة حيث تُخزن وتُعالج. وبهذا الترتيب يستفيد الحساس من بروتوكول منخفض الطاقة لا يحتمل اتصالًا مباشرًا بالإنترنت، بينما تتحمل البوابة العبء الأثقل من المعالجة وكلفتها الأعلى. كما تستطيع البوابة تجميع بيانات عدة أجهزة، والتحويل بين البروتوكولات، وترشيح البيانات، وتطبيق السياسات الأمنية، وتشغيل منطق محلي.
الحوسبة الطرفية (Edge Computing)
تعالج الحوسبة الطرفية البيانات قرب مصدرها بدل إرسال كل شيء إلى مركز بيانات بعيد، وتفيد حين نحتاج استجابة سريعة، أو تقليل عرض النطاق المستهلك، أو استمرار التشغيل عند ضعف الإنترنت، أو معالجة الفيديو محليًا، أو تقليل إرسال البيانات الحساسة.
السحابة أو الخلفية (Cloud / Backend)
قد تتولى تخزين البيانات، وإدارة الأجهزة، والتحليلات، والتنبيهات، وواجهات APIs، وإدارة المستخدمين، ونماذج الذكاء الاصطناعي، ولوحات المراقبة.
التطبيق
هو ما يراه المستخدم أو النظام الآخر، وقد يكون لوحة معلومات، أو تطبيق هاتف، أو نظام صيانة، أو مركز مراقبة، أو API، أو نظام ERP، أو توأمًا رقميًا، أو محرك أتمتة.
IoT ليس طبقة واحدة
من الأخطاء الشائعة الحديث عن IoT كأنه بروتوكول واحد، بينما هو في الواقع طبقات متراكبة، لكل منها خياراتها:
| الطبقة | أمثلة |
|---|---|
| Application | MQTT / CoAP / HTTP / AMQP / Matter |
| Transport | TCP / UDP / QUIC |
| Network | IPv4 / IPv6 |
| Link / Radio | Wi‑Fi / BLE / Thread / Zigbee / Cellular / LoRa |
ولا تجتمع كل هذه الخيارات في كل جهاز. ولهذا يجب التفريق دائمًا بين تقنية الراديو أو الاتصال، وبروتوكول الشبكة، وبروتوكول التطبيق، ونموذج البيانات.
تقنيات الاتصال في IoT
لا توجد تقنية اتصال واحدة تناسب كل الاستخدامات، ولكل تقنية موقعها الطبيعي.
Wi‑Fi
يناسب Wi‑Fi الحالات التي تحتاج عرض نطاق مرتفعًا نسبيًا، واتصالًا مباشرًا بشبكة IP، في بيئة منزلية أو مكتبية أو منشأة تملك بنية Wi‑Fi، كالكاميرات والأجهزة المنزلية والشاشات والبوابات. أما قيوده المحتملة فاستهلاك طاقة أعلى من التقنيات منخفضة الطاقة، والاعتماد على بنية نقاط الوصول (Access Points)، والمدى والازدحام بحسب البيئة.
Bluetooth Low Energy — BLE
صُمم Bluetooth LE للعمل بكفاءة عالية في استهلاك الطاقة، ويدعم أكثر من نمط اتصال: من نقطة إلى نقطة، والبث (Broadcast)، والشبكات المتداخلة (Mesh). وهو شائع في الأجهزة القابلة للارتداء، والأجهزة الطبية الشخصية، والحساسات، وتطبيقات القرب (Proximity)، وإعداد الأجهزة الذكية. وتشير وثائق Bluetooth SIG الحالية أيضًا إلى دوره المتنامي في Ambient IoT، حيث قد تعتمد بعض الأجهزة المستقبلية على طاقة تُحصد من البيئة بدل البطاريات التقليدية.
Zigbee
Zigbee مبني على معيار IEEE 802.15.4، ويشتهر بالشبكات منخفضة الطاقة والمتداخلة، ويُستخدم في المنازل الذكية والإضاءة والمباني والحساسات والتحكم. وفي نوفمبر 2025 أعلنت Connectivity Standards Alliance عن Zigbee 4.0، الذي أضاف تحسينات في الأمن والتوافق، ودعمًا لنطاقات Sub‑GHz عبر Suzi، إلى جانب تحسينات في الإعداد والتشغيل. فـZigbee لم يتوقف عند النسخ القديمة التي تظهر في كثير من شروحات IoT.
Thread
Thread بروتوكول Mesh منخفض الطاقة مبني على IP ومصمم لإنترنت الأشياء. فهو يعتمد IPv6، ويعمل بشبكة متداخلة لا تعتمد على Hub مركزي وحيد قد يصبح نقطة فشل، ويناسب الأجهزة منخفضة الطاقة، ويُستخدم في منظومات المنزل الذكي الحديثة، ويُعد من أهم طبقات الشبكة التي يعمل فوقها Matter.
LoRa وLoRaWAN
بين المصطلحين فرق مهم: LoRa هي تقنية الراديو والتعديل، بينما LoRaWAN بروتوكول الشبكة الذي ينظم الاتصال بين الأجهزة الطرفية (End devices) والبوابات وخوادم الشبكة.
ويناسب LoRaWAN التطبيقات التي تحتاج مسافات طويلة، وبيانات قليلة، وبطارية طويلة العمر، وإرسالًا غير مستمر، كالزراعة ومراقبة البيئة والبنية التحتية وبعض تطبيقات المدن. وتصف المواصفة LoRaWAN 1.0.4 البروتوكول بأنه محسَّن للأجهزة العاملة بالبطاريات، ثابتة كانت أم متحركة.
NB‑IoT
تقنية LPWAN خلوية تناسب خصوصًا العدادات الذكية، وحساسات البنية التحتية، والأجهزة منخفضة البيانات، مع تغطية خلوية واسعة وعمر بطارية طويل.
LTE‑M
تقدم LTE‑M مرونة أكبر من NB‑IoT لبعض التطبيقات، خصوصًا الأجهزة المتحركة، والتتبع، والأجهزة القابلة للارتداء، والبيانات الأعلى نسبيًا، وبعض حالات الصوت. وبنهاية 2025 تجاوز مجموع اتصالات NB‑IoT وLTE‑M النشطة عالميًا مليار اتصال وفق GSMA، ما يؤكد أنهما ليستا مجرد تقنيات انتقالية انتهى دورها.
5G وRedCap
تكتسب 5G أهميتها لفئات من IoT تحتاج عرض نطاق أعلى، وزمن استجابة أقل في ظروف معينة، وشبكات صناعية خاصة، وكثافة أجهزة كبيرة، وجودة خدمة متقدمة، لكنها ليست ضرورية لكل IoT. أما RedCap/eRedCap فتهدف إلى تقديم جزء من قدرات 5G بتعقيد أقل وطاقة أقل وتكلفة أقل من 5G كامل القدرات.
والعلاقة التفصيلية بين 5G وإنترنت الأشياء تستحق شرحًا مستقلًا، نخصص له مقال 5G وإنترنت الأشياء.
مقارنة تقنيات اتصال IoT
| التقنية | المدى النموذجي | استهلاك الطاقة | حجم البيانات | أمثلة استخدام |
|---|---|---|---|---|
| BLE | قصير | منخفض جدًا | منخفض–متوسط | Wearables وحساسات |
| Wi‑Fi | محلي | متوسط–مرتفع | مرتفع | كاميرات وأجهزة منزلية |
| Zigbee | قصير–متوسط/Mesh | منخفض | منخفض | إضاءة ومباني |
| Thread | Mesh محلي | منخفض | منخفض–متوسط | Smart Home IP |
| LoRaWAN | بعيد | منخفض جدًا | منخفض جدًا | زراعة ومراقبة |
| NB‑IoT | واسع خلوي | منخفض | منخفض | عدادات وبنية تحتية |
| LTE‑M | واسع خلوي | منخفض | منخفض–متوسط | Tracking وWearables |
| RedCap/eRedCap | واسع خلوي | متوسط | متوسط | IoT متوسط المتطلبات |
| Full 5G NR | واسع خلوي | أعلى | مرتفع | فيديو وصناعة وتطبيقات عالية الأداء |
هذه مقارنة مفاهيمية؛ فالأداء الحقيقي يختلف بحسب الجهاز والطيف والتنفيذ والبيئة.
كيف تختار تقنية الاتصال؟
يبدأ الاختيار بأسئلة محددة: كم حجم البيانات؟ وكم مرة سيرسل الجهاز؟ وكم سنة يجب أن تعمل البطارية؟ وما المسافة؟ وهل الجهاز متحرك؟ وهل تتوفر شبكة Wi‑Fi أو خلوية؟ وما زمن الاستجابة المطلوب؟ وكم عدد الأجهزة؟ وما تكلفة العتاد ورسوم الاتصال؟ وما درجة حساسية البيانات؟ وماذا يحدث إذا انقطع الاتصال؟
فحساس رطوبة في حقل لا يُعامل معاملة كاميرا جودة صناعية. الأول قد يحتاج LoRaWAN أو NB‑IoT، وبطارية تدوم سنوات، ورسائل صغيرة؛ والثانية قد تحتاج Ethernet أو Wi‑Fi أو 5G مع معالجة طرفية.
بروتوكولات التطبيق في IoT
فوق طبقة الاتصال تأتي بروتوكولات التطبيق التي تحدد كيف تتبادل الأجهزة والخدمات رسائلها.
MQTT
MQTT 5.0 معيار من OASIS قائم على نموذج Publish / Subscribe. فبدل أن يتصل كل جهاز مباشرة بكل مستهلك للبيانات، ينشر الحساس رسائل حرارته إلى Broker مركزي، ويوزعها الوسيط بدوره على كل المشتركين فيها، كلوحة متابعة وخدمة تنبيهات مثلًا، دون أن يعرف الناشر أحدًا منهم. ويتيح هذا الفصل إضافة مستهلكين جدد دون المساس بالجهاز، وتغيير الجهاز دون تحديث المستهلكين، لأن العقد الوحيد المشترك بينهم هو اسم الـTopic لا العنوان.
ومن مزاياه فصل المنتجين عن المستهلكين، وخفة الرسائل نسبيًا، وثلاثة مستويات لجودة الخدمة (QoS)، وملاءمته للأنظمة الموزعة.
لكن وصف MQTT بأنه "يوفر الطاقة تلقائيًا" غير دقيق؛ فاستهلاك الطاقة يتوقف أيضًا على الاتصال الراديوي، ورسائل الإبقاء على الاتصال (Keep-alive)، ومعدل الرسائل، وTLS، والجهاز، وتصميم الجلسة.
CoAP
صُمم CoAP للعقد والشبكات المقيدة، وهو بروتوكول على طراز الويب يعمل عادة فوق UDP. والنقطة المهمة هنا:
الاعتماد على UDP لا يعني أن CoAP "غير موثوق" ببساطة.
فـCoAP يملك آليات مثل Confirmable Messages وإعادة الإرسال عند الحاجة، ويمكن تأمينه بآليات مثل DTLS أو OSCORE بحسب المعمارية.
HTTP
يفيد HTTP حين نحتاج واجهات ويب، وتكاملًا سهلًا مع خدمات السحابة، وبنية REST، ودعمًا واسعًا في الأنظمة، لكنه قد يكون أثقل من MQTT أو CoAP على الأجهزة شديدة القيود. كما أن اختزاله في أنه "يعمل على TCP" لم يعد دقيقًا لكل إصداراته؛ فـHTTP/1.1 وHTTP/2 يرتبطان عادة بـTCP، بينما يستخدم HTTP/3 بروتوكول QUIC فوق UDP.
AMQP
AMQP بروتوكول رسائل معياري من OASIS يركز على تبادل الرسائل الموثوق، والبرمجيات الوسيطة، والأنظمة المؤسسية، وتبادل الرسائل بين الخدمات. وقد يناسب الخلفيات أو منصات IoT المؤسسية، لكنه عادة أعقد من MQTT بالنسبة إلى عقد IoT الصغيرة جدًا.
MQTT أم CoAP أم HTTP؟
| السؤال | MQTT | CoAP | HTTP |
|---|---|---|---|
| النمط | Pub/Sub | Request/Response شبيه بالويب | Request/Response |
| الأجهزة المقيدة | جيد | ممتاز | يعتمد على الجهاز |
| Broker | عادة نعم | لا يلزم | لا |
| شبكات ضعيفة | مناسب | مناسب جدًا | قد يكون أثقل |
| Web integration | عبر خدمات وسيطة أو WebSockets | يمكن ربطه بالويب | مباشر |
| Push/telemetry | قوي | ممكن | أقل طبيعية |
| APIs التقليدية | ممكن لكن ليس هدفه الأساسي | REST-like | ممتاز |
ولا يوجد "أفضل بروتوكول IoT" بصورة مطلقة.
Matter وقابلية التشغيل البيني
أين يأتي Matter؟
Matter ليس بديلًا عن Wi‑Fi أو Thread أو Bluetooth، بل بروتوكول تطبيق قائم على IP يركز خصوصًا على قابلية التشغيل البيني في المنزل الذكي. فهو يعمل فوق تقنيات شبكية مثل Wi‑Fi وThread وEthernet، ويستخدم Bluetooth LE في سيناريوهات الإعداد (Commissioning). وفي يونيو 2026 صدر Matter 1.6، مضيفًا تحسينات في الإعداد، والإدارة عبر منظومات متعددة، وتبادل قدرات الأجهزة وحالاتها.
وتكمن أهمية Matter في أنه يعالج مشكلة مختلفة عن مشكلة الراديو:
ليس فقط "كيف تصل الحزمة؟" بل "كيف يفهم جهاز من شركة A جهازًا من شركة B بطريقة معيارية؟"
التحدي الذي لا تحله الشبكة وحدها
قد يستخدم جهازان Wi‑Fi ومع ذلك لا يفهم أحدهما الآخر. فقابلية التشغيل البيني تحتاج توافقًا في الاكتشاف (Discovery)، والهوية، ونماذج البيانات، والأوامر، والأمن، والدلالات (Semantics). ومن هنا تأتي أهمية Matter، وملفات Zigbee التعريفية، وThread مع IP، والمعايير المفتوحة، وواجهات APIs ونماذج البيانات. فالمشكلة ليست مجرد وجود اتصال، بل وجود معنى مشترك للبيانات والأوامر.
تطبيقات إنترنت الأشياء
المدن الذكية
يُستخدم IoT في الإنارة والمياه ومواقف السيارات ومراقبة الهواء والمرور والنفايات والبنية التحتية. لكن عبارة "المدينة الذكية" لا تعني شبكة واحدة؛ فقد تستخدم المدينة LoRaWAN للحساسات البسيطة، وNB‑IoT للعدادات، والألياف الضوئية للأنظمة الأساسية، و5G أو Wi‑Fi للفيديو.
الرعاية الصحية
من استخداماتها الأجهزة القابلة للارتداء، والمراقبة عن بعد، وأجهزة القياس المنزلية، وتتبع المعدات، والتنبيهات. لكن البيانات الصحية حساسة، ولا يجوز اعتبار أي جهاز IoT طبي نظام تشخيص لمجرد قدرته على القياس؛ فتطبيقات الرعاية الصحية تحتاج تحققًا سريريًا عند الاقتضاء، وأمنًا عاليًا، وإدارة للهوية، وحماية للخصوصية، والتزامًا بالقوانين المحلية.
الصناعة الذكية
يدعم Industrial IoT مراقبة حالة المعدات (Condition Monitoring)، والصيانة التنبؤية، وتتبع الأصول، ومراقبة الطاقة، وضبط الجودة، والتوائم الرقمية. ومثال عملي يوضح ذلك: حساسات محرك صناعي تبث قياساتها إلى تحليلات تعمل على الـEdge قرب خط الإنتاج، فتكشف هذه التحليلات أنماط الشذوذ في الاهتزاز أو الحرارة لحظة ظهورها، وتدفع النتيجة مباشرة إلى نظام الصيانة الذي يفتح أمر عمل قبل أن يتحول الخلل إلى عطل. فالبيانات الخام لا تسافر إلى مركز بيانات بعيد، والقرار الحرج يُبنى قرب مصدرها.
وهنا تظهر العلاقة المباشرة مع التوأم الرقمي: فبيانات IoT قد تغذي نموذجًا رقميًا لأصل حقيقي لمراقبته ومحاكاته وتحسينه.
النقل واللوجستيات
يشمل إدارة الأساطيل، وتتبع الأصول، وسلسلة التبريد (Cold chain)، وبيانات المركبات عن بعد (Vehicle telemetry)، وأنظمة المرور الذكية.
الطاقة
يشمل العدادات الذكية، ومراقبة الشبكات، والاستجابة للطلب (Demand response)، وإدارة الطاقة داخل المباني، ومراقبة الطاقة المتجددة. وقد أخذ Matter نفسه يتوسع في إدارة الطاقة المنزلية، بإمكانات أضيفت خلال إصداراته الحديثة.
الزراعة
يشمل رطوبة التربة، والطقس المحلي، والري، وتتبع المواشي، ومراقبة المعدات، والزراعة الدقيقة. وفي هذا المجال تكون الطاقة المنخفضة والمدى الكبير والتغطية الريفية غالبًا أهم من السرعة العالية.
AIoT: حين يلتقي إنترنت الأشياء بالذكاء الاصطناعي
AIoT اختصار لـArtificial Intelligence of Things، وفكرته أن IoT يجمع البيانات، والذكاء الاصطناعي يحللها أو يستخدمها لاتخاذ القرارات: كاكتشاف خلل في آلة، أو التنبؤ بفشل محرك، أو رصد شذوذ في استهلاك الطاقة، أو تحليل الفيديو على الحافة، أو توقع احتياج الري، أو تصنيف أحداث الحساسات. ويمكن تشغيل الذكاء الاصطناعي في ثلاثة مواقع:
| الموقع | آلية العمل |
|---|---|
| Cloud AI | تُرسل البيانات إلى السحابة لتحليلها |
| Edge AI | يعمل النموذج قرب الجهاز |
| TinyML | تعمل نماذج صغيرة جدًا على المتحكم الدقيق نفسه |
وكلما اقتربت المعالجة من المصدر، أمكن تقليل زمن الاستجابة وعرض النطاق ونقل البيانات الحساسة، لكن مع تحديات إضافية مثل تحديث النماذج، ومحدودية الذاكرة، وقيود الطاقة، ومراقبة الأداء.
الأمن: جزء من التصميم لا إضافة لاحقة
لماذا يجب التفكير في دورة الحياة كاملة؟
قد يبقى جهاز IoT في الخدمة سنوات طويلة، يتعرض خلالها لثغرات جديدة، وتغير في الملكية، وFirmware يتقادم، وبيانات اعتماد مسربة، وشهادات تنتهي صلاحيتها، وتغير في الخلفية، وهجمات على واجهات APIs. ولذلك يجب أن يراعي تصميم الجهاز دورة حياته كاملة.
ماذا يوصي NIST؟
في أبريل 2026 أصدر NIST مراجعة NISTIR 8259 Rev.1 لتحديث الأنشطة الأساسية التي ينبغي لمصنعي منتجات IoT مراعاتها. كما يحدد NISTIR 8259A خط أساس لقدرات الجهاز، يشمل Device Identification، وDevice Configuration، وData Protection، وLogical Access to Interfaces، وSoftware Update، وCybersecurity State Awareness. وتضيف كتالوجات NIST الحالية قدرات أكثر تفصيلًا، منها Device Security.
قائمة أمنية عملية
| المبدأ | ما يعنيه عمليًا |
|---|---|
| هوية فريدة | يجب أن يمكن تعريف الجهاز بصورة موثوقة |
| لا كلمات مرور افتراضية مشتركة | ولا بيانات اعتماد ثابتة بين آلاف الأجهزة |
| تشفير البيانات | أثناء النقل، وعند التخزين حين يلزم |
| تحديثات آمنة | التحقق من الـFirmware، وتوقيع التحديثات، ومنع الرجوع الخطر إلى إصدارات أقدم، ووضع خطة لنهاية الدعم |
| أقل صلاحية | لا تمنح الجهاز وصولًا يتجاوز حاجته |
| إغلاق الخدمات غير الضرورية | كل واجهة إضافية قد تصبح سطح هجوم |
| إدارة الأسرار | لا تضع مفاتيح حساسة بطريقة يسهل استخراجها |
| السجلات والحالة الأمنية | معرفة ما إذا كان الجهاز محدثًا، وما إذا فشلت محاولات دخول، أو تغيرت الإعدادات، أو ظهرت حالة غير طبيعية |
| خطة ما بعد البيع | تحديد مدة الدعم، وآلية الإبلاغ عن الثغرات، وطريقة التحديث، ونهاية عمر المنتج |
فالأمن لا يقتصر على يوم إطلاق المنتج.
الخصوصية في IoT
قد يجمع جهاز صغير بيانات شديدة الحساسية، كالموقع والصحة والصوت والفيديو والسلوك داخل المنزل ونمط الاستهلاك. ولذلك يجب أن تُطرح أسئلة واضحة: هل نحتاج هذه البيانات أصلًا؟ هل يمكن معالجتها محليًا؟ كم نحتفظ بها؟ من يستطيع الوصول إليها؟ هل يعرف المستخدم ما يُجمع؟ هل يمكن حذفها؟ وهل تُستخدم لغرض آخر؟ ويبقى Data Minimization المبدأ الأساسي:
لا تجمع بيانات لا تحتاجها.
التوسع والموثوقية
التوسع ليس مجرد "عدد أجهزة"
قد يبدو النظام ممتازًا عند 50 جهازًا ثم يفشل عند 50 ألفًا. فقابلية التوسع تشمل تهيئة الأجهزة (Provisioning)، والهوية، والشهادات، والرسائل، وسعة الوسيط، وعمليات الكتابة في قواعد البيانات، والتحديثات عبر الهواء (OTA)، وقابلية المراقبة، وجرد الأجهزة، والتحويل عند الفشل.
ومن الأمثلة الشهيرة على ذلك عودة التيار بعد انقطاع واسع، حين يحاول مليون جهاز الاتصال بالخادم في اللحظة نفسها، فتحدث Reconnect Storm. ولذلك يجب اختبار سلوك النظام عند انقطاع الشبكة، وعودة الكهرباء، وفقدان الوسيط، وفشل منطقة سحابية، والتحديث الجماعي للـFirmware.
ماذا تعني الموثوقية في IoT؟
ليست كل رسالة بالأهمية نفسها. فقراءة حرارة دورية يمكن أن تُفقد إحدى نسخها أحيانًا، لكن أمر إيقاف آلة أو تنبيهًا طبيًا قد يحتاج ضمانات توصيل، وإشعار استلام، وإعادة محاولة، وتكرارًا احتياطيًا، ومهلة زمنية، وتصعيدًا. فالموثوقية تُصمم على مستوى التطبيق، لا بالاعتماد على اسم البروتوكول وحده.
مستقبل IoT: ما الذي يتغير في 2026؟
قابلية التشغيل البيني أكثر أهمية
تبرز في ذلك أمثلة حديثة مثل Matter 1.6 وZigbee 4.0 وThread والبروتوكولات القائمة على IP، إذ يحاول السوق تقليص الجزر المنفصلة بين الأجهزة.
الذكاء الاصطناعي ينتقل إلى الحافة
بدل إرسال كل البيانات إلى السحابة، يجري مزيد من التحليل داخل الجهاز نفسه، أو على البوابة، أو على الحافة.
Ambient IoT
أجهزة تعمل باستهلاك شديد الانخفاض، يعتمد بعضها على حصاد الطاقة (Energy Harvesting) بدل بطارية تقليدية كبيرة، وتعتبر Bluetooth SIG تقنية Bluetooth LE مهمة في هذا المسار.
Massive IoT الخلوي مستمر
تجاوزت NB‑IoT وLTE‑M مليار اتصال نشط عالميًا بنهاية 2025 وفق GSMA، وفي المقابل توسع RedCap/eRedCap خيارات IoT على 5G.
6G / IMT‑2030 ما تزال مستقبلًا معياريًا
في 2026 لا توجد شبكة 6G تجارية ناضجة يمكن الاعتماد عليها أساسًا لمشروع IoT. وتعمل ITU حاليًا على IMT‑2030، وقد أعلنت في مارس 2026 أن مجموعة الخبراء اتفقت على مسودة متطلبات الأداء للجيل القادم، مع استمرار عملية الاعتماد والتقييم. ولذلك لا ينبغي عرض أرقام مثل Terabit/s أو أزمنة دون الميلي ثانية أو ملايين ومليارات الأجهزة كأنها خصائص تجارية نهائية مؤكدة اليوم؛ فالخصائص الدقيقة ستتحدد مع اكتمال المعايير والتقييمات.
كيف تبدأ مشروع IoT بطريقة صحيحة؟
لا تبدأ بشراء حساس أو اختيار سحابة، بل من القرار المطلوب، ثم تدرّج عبر الخطوات التالية:
| الخطوة | ما تحدده |
|---|---|
| 1. حدد المشكلة | مثلًا: نريد اكتشاف ارتفاع اهتزاز المحرك قبل العطل |
| 2. حدد البيانات المطلوبة | الاهتزاز والحرارة وعدد الدورات في الدقيقة (RPM) |
| 3. حدد معدل القياس | كل ميلي ثانية أم كل ثانية أم كل ساعة؟ وهذا يغير المعمارية بالكامل |
| 4. قرر أين تتم المعالجة | في الجهاز، أو البوابة، أو الحافة، أو السحابة |
| 5. اختر الاتصال | بناءً على البيانات والطاقة والمدى والتكلفة والحركة وزمن الاستجابة |
| 6. اختر بروتوكول التطبيق | MQTT أو CoAP أو HTTP أو غيرها بحسب النظام |
| 7. صمم الأمن قبل التنفيذ | الهوية والمفاتيح والتشفير والتحديثات والصلاحيات ودورة الحياة |
| 8. صمم التشغيل | كيف ستعرف أن جهازًا توقف، أو أن الـFirmware قديم، أو البطارية ضعيفة، أو شهادة ستنتهي، أو البيانات غير منطقية؟ |
| 9. اختبر الفشل | لا تكتفِ بالمسار السعيد؛ اختبر العمل دون اتصال، وفقد الحزم، وإعادة التشغيل، وضغط الشبكة، وآلاف الأجهزة، وفشل الترقية |
كيف نختار بين السحابة والحافة؟
| ابدأ بالسحابة حين | ابدأ بالحافة حين |
|---|---|
| لا يكون زمن الاستجابة شديد الحساسية | تكون الاستجابة السريعة مهمة |
| تحتاج تحليلات مجمعة | تكون البيانات ضخمة |
| تحتاج تخزينًا مركزيًا | يكون الاتصال الخارجي ضعيفًا |
| يكون الاتصال مستقرًا | تكون الخصوصية مهمة |
| يجب أن يستمر النظام دون اتصال |
وفي كثير من المشاريع يكون التصميم Hybrid يجمع بين الاثنين.
هل يجب أن يتصل كل جهاز بالإنترنت مباشرة؟
لا. ففي كثير من الأنظمة يكون الأفضل أن يتصل الحساس بشبكة محلية، ومنها إلى بوابة تتولى الاتصال بالإنترنت، بدل أن يتصل الحساس بالإنترنت مباشرة. فالبوابة تستطيع إخفاء الأجهزة الداخلية، وتجميع البيانات، وإدارة البروتوكولات، وتقليل الاستهلاك، وتطبيق السياسات الأمنية، والاستمرار في العمل محليًا عند انقطاع السحابة.
وتجد مثالًا عمليًا على الحلقة المحلية التي تسبق الإنترنت في مشروعنا نظام قياس مستوى الماء في الخزان بمستشعر فوق صوتي، حيث يقرأ Arduino الحساس ويرسل النسبة إلى تطبيق الهاتف عبر Bluetooth دون منصة سحابية؛ وإضافة بوابة أو اتصال Wi‑Fi هي الخطوة التي تنقله إلى منظومة IoT كاملة. وفي تنفيذنا الفعلي لهذا المشروع ظهرت انقطاعات مؤقتة في اتصال Bluetooth عند زيادة المسافة أو وجود تداخل، كما لاحظنا أن عوامل مثل الحرارة والرطوبة قد تؤثر في قراءة الحساس فوق الصوتي، فاحتجنا إلى مراعاة تصحيح القراءات أثناء التطوير.
الخلاصة
إنترنت الأشياء ليس جهازًا ذكيًا ولا بروتوكولًا واحدًا، بل منظومة كاملة تربط العالم الفيزيائي بالبرمجيات من خلال الاستشعار والاتصال والمعالجة واتخاذ القرار والتنفيذ. ويعتمد نجاح النظام على توازن مدروس بين الحساسات، والحوسبة، والاتصال، والبروتوكولات، وتوزيع المعالجة بين الحافة والسحابة، وقابلية التشغيل البيني، والأمن، والطاقة، والتكلفة، ودورة الحياة.
والسؤال الأهم عند تصميم أي مشروع ليس «ما أحدث تقنية يمكن أن نستخدمها؟»، بل:
ما أقل بنية تعقيدًا تستطيع تحقيق متطلبات التطبيق بصورة آمنة وموثوقة وقابلة للصيانة طوال عمر الجهاز؟
المصادر والمراجع
NIST — NISTIR 8259 Series
https://www.nist.gov/itl/applied-cybersecurity/nist-cybersecurity-iot-program/nistir-8259-seriesNIST — IoT Device Cybersecurity Capability Core Baseline (NISTIR 8259A)
https://csrc.nist.gov/pubs/ir/8259/a/finalOASIS — MQTT Version 5.0
https://www.oasis-open.org/standard/mqtt-v5-0-os/IETF / RFC Editor — RFC 7252: The Constrained Application Protocol (CoAP)
https://www.rfc-editor.org/info/rfc7252/IETF / RFC Editor — RFC 9110: HTTP Semantics
https://www.rfc-editor.org/info/rfc9110/OASIS — AMQP Version 1.0
https://www.oasis-open.org/standard/amqp/Bluetooth SIG — Bluetooth Low Energy Primer
https://www.bluetooth.com/bluetooth-le-primer/Connectivity Standards Alliance — Zigbee 4.0
https://csa-iot.org/newsroom/the-connectivity-standards-alliance-announces-zigbee-4-0-and-suzi-empowering-the-next-generation-of-secure-interoperable-iot-devices/Thread Group — Thread
https://threadgroup.org/LoRa Alliance — LoRaWAN 1.0.4 Specification
https://lora-alliance.org/resource_hub/lorawan-104-specification-package/GSMA — One billion NB-IoT and LTE-M connections
https://www.gsma.com/solutions-and-impact/technologies/internet-of-things/billion-lpwan-connections/Connectivity Standards Alliance — Matter 1.6
https://csa-iot.org/newsroom/matter-1-6-enables-more-intuitive-setup-multi-ecosystem-experiences-and-context-driven-control/Connectivity Standards Alliance — Matter specifications
https://csa-iot.org/developer-resource/specifications-download-request/ITU — IMT-2030 technical requirements for the 6G future
https://www.itu.int/hub/2026/03/imt-2030-technical-requirements-for-the-6g-future/
وثائق رسمية ومعايير إضافية
الأسئلة الشائعة حول المقال
ما هو إنترنت الأشياء باختصار؟
هو منظومة من أجهزة مادية تجمع بيانات وتتبادلها عبر الشبكات مع أنظمة معالجة أو تطبيقات بهدف المراقبة أو التحليل أو التحكم أو الأتمتة.
هل كل جهاز متصل بالإنترنت يعتبر IoT؟
ليس بالضرورة. عادة يرتبط مفهوم IoT بأجهزة مادية تستشعر أو تنفذ أفعالًا وتتبادل بيانات ضمن منظومة أوسع.
ما الفرق بين LoRa وLoRaWAN؟
LoRa هي تقنية الراديو/التعديل، بينما LoRaWAN هو بروتوكول الشبكة الذي ينظم اتصال الأجهزة والبوابات والخوادم.
ما الفرق بين MQTT وCoAP؟
MQTT يعتمد غالبًا Publish/Subscribe عبر Broker، بينما CoAP يقدم نموذجًا قريبًا من الويب للأجهزة والشبكات المقيدة ويعمل عادة فوق UDP.
هل CoAP غير موثوق لأنه يستخدم UDP؟
ليس بهذه البساطة. CoAP يوفر Confirmable Messages وإعادة إرسال عند الحاجة، ويمكن اختيار نمط الرسالة المناسب للتطبيق.
هل MQTT هو الخيار الأفضل لكل IoT؟
لا. MQTT ممتاز للTelemetry وPub/Sub، لكن بعض الأنظمة تكون أنسب مع CoAP أو HTTP أو بروتوكولات صناعية أو مخصصة.
ما Matter؟ وهل يحل محل Wi‑Fi؟
لا. Matter بروتوكول تطبيق IP-based للتوافق بين أجهزة المنزل الذكي ويعمل فوق شبكات مثل Wi‑Fi وThread وEthernet.
هل Zigbee ما زالت مستخدمة؟
نعم. أطلقت Connectivity Standards Alliance إصدار Zigbee 4.0 في 2025 مع تحسينات في الأمن والتوافق والمدى.
ما الفرق بين NB-IoT وLTE-M؟
NB‑IoT يركز أكثر على البيانات الصغيرة والطاقة المنخفضة والتغطية، بينما LTE‑M يوفر مرونة أكبر للحركة ومعدل بيانات أعلى نسبيًا لبعض التطبيقات.
هل IoT يحتاج 5G؟
ليس دائمًا. الاختيار يعتمد على الطاقة والبيانات والمدى والحركة والـLatency والتكلفة. كثير من أجهزة IoT تعمل بتقنيات أخرى أكثر مناسبة.
النقاش الهندسي والملاحظات (0)
سجّل الدخول للمشاركة في النقاش والرد على التعليقات والإعجاب بها.
