الأحياء والمدن الذكية
من يملك البيانات ويديرها في المنطقة
كيف يتم تخصيص الحقوق والأدوار والوصول إلى بيانات المنطقة بين المالكين والمحتلين والمشغلين والموردين.
حدد الحد الأدنى من المعلومات التي يجب على كل مبنى توفيرها لاتخاذ قرار مشترك، واحتفظ بكل مبنى مستقلاً.

الجواب المغري هو ربط كل مبنى بمنصة المنطقة والسماح له بقراءة ما يحتاج إليه. والأفضل هو مجموعة من الواجهات المتفق عليها، تحمل كل منها مجموعة محددة من المعلومات مع الحفاظ على معناها وجودتها وقواعد الوصول إليها. ينشر كل مبنى ما يتطلبه الغرض المشترك، وتستهلكه المنطقة، ويظل المبنى حرًا في تغيير أنظمته الخاصة طالما استمر في احترام الواجهة.
مكان البدء هو القرار المشترك، أي ما تحتاج المنطقة إلى معرفته أو فعله بالفعل. عندها فقط يجب على أي شخص تحديد الحد الأدنى من المعلومات التي يجب على كل مبنى توفيرها لدعمه.
الوثيقة الأساسية عبارة عن عقد معلومات، يسمى أحيانًا مواصفات مشاركة البيانات، ويتم الاتفاق عليه بين المنطقة وكل مبنى. ويبدأ بمعرفات المواقع والمباني والمساحات والعدادات والأصول، بحيث يكون للشيء نفسه نفس الاسم في كل مكان. ثم يحدد ما يعنيه كل حقل: ما تمثله القيمة، وبأي وحدة وعلى أي فترة زمنية. أخطأ في فهم هذا الأمر وستُضلل المقارنات دون سابق إنذار؛ يصبح إجمالي المنطقة بلا معنى إذا أبلغ أحد المباني عن قدرة لحظية وأبلغ آخر عن الطاقة المتراكمة على مدار ساعة تحت نفس اسم الحقل.
يحتاج العقد أيضًا إلى تحديد الطوابع الزمنية والمنطقة الزمنية، وما إذا كانت القيم يتم قياسها أو تقديرها أو حسابها. ويجب أن تحمل مؤشرات الجودة التي تميز القيم الجيدة والمشكوك فيها والمقدرة والمفقودة، وتعيين تكرار التحديث وزمن الاستجابة الذي يمكن للمنطقة الاعتماد عليه. وأخيرًا، فهو يعمل على إصلاح قواعد الوصول، أي من يمكنه قراءة كل مجموعة بيانات ولأي غرض، والتحكم في التغيير: كيف يقترح أي من الجانبين التغيير ومقدار الإشعار الذي يتم تقديمه.
| نمط | كيف يعمل | يناسب |
|---|---|---|
| ينشر المبنى إلى واجهة برمجة تطبيقات المنطقة | يرسل نظام كل مبنى البيانات إلى واجهة برمجة التطبيقات (API) التي تديرها المنطقة | العديد من المباني والمعايير التي تقودها المنطقة |
| المنطقة تسحب من واجهات برمجة التطبيقات (API) الخاصة بالمباني | تقرأ منصة المنطقة واجهة برمجة التطبيقات (API) الخاصة بكل مبنى | عدد أقل من المباني ذات الأنظمة الناضجة |
| وسيط الرسائل | تقوم المباني بنشر الأحداث أو القراءات للمواضيع؛ المنطقة تشترك | الخدمات المستندة إلى الأحداث، والإنذارات، والبيانات في الوقت الفعلي تقريبًا |
| تبادل الملفات بشكل دوري | التصدير المقرر للقراءات | بيانات الفواتير، التقارير ذات التردد المنخفض، المواقع البسيطة |
وأيًا كان النمط الذي يتم اختياره، يجب توثيق الواجهة رسميًا. تعد مواصفات OpenAPI، التي تحتفظ بها مبادرة OpenAPI، طريقة مستخدمة على نطاق واسع لوصف واجهات برمجة تطبيقات HTTP في شكل يمكن قراءته بواسطة الآلة؛ تم تقديم السطر 3.2 في سبتمبر 2025، وتبعه أحدث إصدار للتصحيح، 3.2.1، في سبتمبر 2026، بينما يظل السطران 3.1 و3.0 السابقان منشورين وقيد الاستخدام.
تعد أسماء الحقول المشتركة بمثابة البداية، لكن المناطق الأكبر حجمًا تستفيد من النموذج الدلالي المشترك. تم تصميم SAREF (علم الوجود المرجعي للتطبيقات الذكية) من ETSI كنموذج أساسي مشترك يتيح لنماذج البيانات المختلفة الارتباط ببعضها البعض دون تعيين مخصص لكل زوج، ويقوم SAREF4CITY بتوسيعه ليشمل مجال المدينة الذكية. في النظم البيئية لبيانات المدن، تحدد آليات الحد الأدنى من قابلية التشغيل البيني (MIMs) لشبكة المدن الذكية المفتوحة والمرنة مستوى أدنى وكافي من قابلية التشغيل البيني، بما في ذلك إتاحة البيانات من خلال واجهات برمجة التطبيقات وتمثيلها في تنسيقات قائمة على المعايير؛ فهو يشير إلى NGSI-LD كمعيار حديث لمشاركة المعلومات حول كيانات العالم الحقيقي بطريقة مشتركة ومتسقة.
لا شيء من هذه يضمن إمكانية التشغيل البيني من تلقاء نفسه. لا يزال يتعين على الأطراف الاتفاق على الإصدار والمجموعة الفرعية التي سيستخدمونها، وكيفية التحقق من المطابقة.
يجب ألا يصبح الوصول إلى المنطقة أبدًا اعتمادًا على عناصر التحكم الخاصة بالمبنى. يجب أن تكون معظم التبادلات للقراءة فقط. حيث يمكن للمنطقة تقديم طلبات تغير العملية، مثل طلب تخفيض الطلب، يجب أن يحدد الترتيب من الذي يأذن لهم، والحدود التي يحددها كل مبنى، وكيف يرفض المبنى الطلب أو يتجاوزه وماذا يحدث إذا تم فقدان الرابط.
البيانات المفقودة تحتاج إلى نفس التفكير. يجب أن يظهر المبنى الذي يتوقف عن إعداد التقارير مؤقتًا على أنه غير متوفر أو قديم. ويجب ألا يساهم المبنى بصمت بقيمة قديمة في إجمالي المنطقة الحالية.
يصف عقد المعلومات البيانات. يحتاج الطرفان أيضًا إلى اتفاق حول العلاقة، خاصة عندما يكون للمباني مالكين مختلفين. ويجب أن يذكر الغرض من استخدام البيانات المشتركة، وأن أي استخدام جديد يحتاج إلى اتفاق جديد. يجب أن يذكر من يقوم بتشغيل منصة المنطقة، ومن المسؤول عن تغذية كل مبنى ومن يتصل به كل طرف عندما يتعطل شيء ما.
تحتاج البيانات الشخصية والتجارية الحساسة إلى عناية خاصة. يمكن أن يرتبط الاستهلاك الخاص بإيجار صغير، أو أحداث الوصول، بأشخاص يمكن التعرف عليهم أو يكشف عن نشاط تجاري. السؤال الأول هو ما إذا كانت هناك حاجة لمثل هذه البيانات على الإطلاق؛ حيثما يسمح الغرض، يجب تجميعها، وحيثما تبقى البيانات الشخصية، يجب على مستشاري الخصوصية تأكيد أدوار والتزامات كل طرف.
يتعين على الاتفاقية أيضًا تسوية الأموال والاعتماد: من يدفع مقابل الاتصال من جانب المبنى، والمنصة والتغييرات اللاحقة، وأي استخدامات تعتمد على صحة البيانات (إعادة تحميل التكلفة، على سبيل المثال)، وما هو مستوى الخدمة والمعالجة المطبقة عندما لا تكون كذلك. يجب أن يوضح كيفية انضمام مبنى جديد، وماذا يحدث لتاريخ المبنى عند بيعه أو سحبه، وعدد مرات مراجعة الترتيب وكيفية حل الخلافات.
في العقارات المُدارة بشكل خاص، قد تكون هذه الشروط موجودة في اتفاقيات إدارة العقارات أو عقود الإيجار؛ في الحرم الجامعي العام، في اتفاقية الخدمة الداخلية. وفي كلتا الحالتين، يقوم المستشارون القانونيون بصياغة الوثيقة. وتتمثل مهمة الفريق الفني في التأكد من أنه يصف ما ستفعله الأنظمة فعليًا.
يبدأ العمل بالقرار المشترك والمالك المسمى له، متبوعًا بقائمة صادقة لما يمكن أن يقدمه كل مبنى اليوم وبأي جودة. يغطي الإصدار 1 من عقد المعلومات الحد الأدنى من مجموعة البيانات فقط، والنمط الفني هو النموذج الذي يمكن أن يدعمه المبنى المشارك الأقل نضجًا. يأتي طيار ذو مبنيين أو ثلاثة، بما في ذلك المباني الأضعف عمدًا، قبل أن ينضم الباقي إلى الموجات المخطط لها.
يجب أن يتم هذا الاختبار من البداية إلى النهاية، مع بيانات تمثيلية من العديد من المباني. يحتاج إلى إظهار أن:
بعد الدخول في الخدمة، يجب أن يمتلك شخص ما عقد المعلومات. تتحلل الواجهات بهدوء عندما لا يفعل أحد ذلك.
يرتبط هذا المقال بعملنا في تصميم المخطط الرئيسي.
يمكننا مناقشة كيف يدخل هذا الموضوع في موجز المشروع.
تواصل مع Pagin Consulting