بنت Dropp منصة Hypernyx البرمجية منذ مرحلة التصميم والبحث والتطوير، من جميع خدمات Backend والاتصال اللحظي بالأجهزة إلى لوحات الإدارة ومراقبة الإنذارات والويب.
ناقش نظامك معناHypernyx نظام ذكي للإنذار ضد السرقة يعتمد على إنترنت الأشياء، ومصمم للمنازل والشركات والمؤسسات الكبيرة. تتيح تطبيقات الهاتف للمستخدمين مشاهدة حالة الجهاز لحظيًا، وتسليح النظام أو إلغاء تسليحه، وإدارة المناطق وأجهزة التحكم والمرحّلات، ومنح مستويات وصول مختلفة للمستخدمين.
عندما بدأت Dropp تعاونها مع Hirkania Technologies في عام 2021، كان المشروع لا يزال في مرحلة التصميم والبحث والتطوير. لم تكن المنصة البرمجية قد بُنيت بعد، ولم يكن حتى النموذج النهائي الأول للجهاز موجودًا. لذلك لم تكن مهمة Dropp إضافة خصائص إلى تطبيق جاهز أو تحديث نظام قديم، بل المشاركة في تحديد وبناء الأساس البرمجي لمنتج يعتمد سلوكه على التنسيق الوثيق بين العتاد وFirmware وخدمات Backend وتطبيقات المستخدمين.
صممت Dropp وطورت جميع الخدمات العاملة على الخادم، ولوحة الإدارة، ولوحة مركز مراقبة الإنذارات، وموقع Hypernyx. تولى فريق Hypernyx تطوير تطبيقات الهاتف وUI/UX وضمان جودة المنتج، وعمل الفريقان معًا في البحث والتطوير وتصميم الاتصال بين Firmware وخدمات Backend والتطبيقات.
تدعم المنصة اليوم أكثر من 1000 جهاز نشط وتجريبي. وعند توفر اتصال مستقر، ينتقل الأمر من تطبيق الهاتف إلى الجهاز خلال أقل من 800 مللي ثانية.
وحتى 17 سبتمبر 2026، كانت المنصة تعالج أكثر من 10 آلاف Event مرسل من الأجهزة يوميًا؛ وهو حجم تشغيلي فعلي يستمر في النمو مع زيادة مبيعات Hypernyx وعدد الأجهزة المركبة. يصف هذا الرقم النشاط الحالي في Production، وليس السعة القصوى للمنصة.
في مشاريع البرمجيات التقليدية، تكون خصائص المنتج والقيود التقنية معروفة إلى حد كبير قبل بدء التنفيذ. أما في Hypernyx، فكان على العتاد والبرمجيات أن يتطورا معًا. لم يكن من الممكن اتخاذ القرارات بمعزل في Backend أو Firmware، لأن كل قرار كان يؤثر في استهلاك البيانات، وزمن وصول الأوامر، وأمان الاتصال، وسلوك الجهاز، وتجربة المستخدم النهائية.
كان على المنصة أيضًا أن تعمل في ظروف لا يكون فيها اتصال الجهاز مثاليًا دائمًا. فقد تتصل بعض الوحدات عبر شبكة 2G، ومع ذلك يجب أن تنقل الأوامر والأحداث الأساسية بأقل تأخير واستهلاك ممكن للبيانات. ولأن المنتج مرتبط بأمن المنازل وأماكن العمل، كان يجب أن يكون الاتصال آمنًا وموثوقًا وقابلًا للإدارة التشغيلية.
لم يكن التحدي الحقيقي إنشاء مجموعة من APIs أو لوحة إدارة، بل بناء الطبقة البرمجية المركزية التي تنسق بين المستخدمين وتطبيقات الهاتف والفنيين ومراكز مراقبة الإنذار وأجهزة الأمن الفعلية.
نفذت Dropp وHypernyx البحث والتطوير الخاص بالتكامل بين البرمجيات والعتاد بصورة مشتركة منذ بداية المشروع. جرى تصميم سلوك الأجهزة، وبنية الرسائل، ومسارات الأوامر، ومعالجة Events، وإدارة حالة الاتصال وتحسينها من خلال تعاون مستمر بين الفريقين.
اختير MQTT بوصفه أحد البروتوكولات القياسية لاتصالات إنترنت الأشياء. وكان تصميم الاتصال مطالبًا بالعمل بكفاءة على الشبكات البطيئة، وضبط استهلاك البيانات، والحفاظ على الأمان، وتوفير مسار واضح لزيادة عدد الأجهزة المتصلة من دون إعادة بناء المنصة من الصفر.
جرى التعامل مع Firmware وBackend باعتبارهما جزأين من نظام منتج واحد. وكانت التغييرات في أي طرف تُراجع وفق أثرها في التجربة الكاملة، بينما تدخل الخصائص الجديدة إلى المنتج من خلال تنسيق فرق العتاد وBackend وتطبيقات الهاتف وضمان الجودة.
صُمم Backend الخاص بـHypernyx وفق مبادئ Microservices وEvent-driven Architecture. فُصلت مسؤوليات مثل المصادقة، والاتصال بالأجهزة، وإدارة الأحداث، والإشعارات، والرسائل في خدمات مستقلة، بحيث يمكن تطوير كل جزء مع تقليل المخاطر والاعتماديات على بقية المنتج.
يتيح هذا الفصل إضافة الخصائص تدريجيًا، وتطوير المكونات ذات الحمل الأعلى بصورة مستقلة، واحتواء الأعطال المحتملة ضمن نطاق تشغيلي أصغر. ولم تُصمم المعمارية للحمل الأولي للمشروع فقط؛ بل كان عليها دعم النمو المستمر في عدد الأجهزة والمستخدمين والأحداث وقدرات المنتج.
لا تُنشر تفاصيل البنية الداخلية وضوابط الأمان الدقيقة وتصميم اتصالات الأجهزة لأسباب أمنية. وعلى المستوى الممكن مشاركته، صُممت المنصة للاتصال اللحظي، والأحمال المتزايدة، والتطوير المستمر لخدمات قابلة للنشر بصورة مستقلة.
من أهم مقاييس تجربة المستخدم في Hypernyx المدة بين إصدار الأمر في تطبيق الهاتف ووصوله إلى الجهاز الفعلي. فالمستخدم الذي يريد تسليح نظام أمني أو إلغاء تسليحه يجب ألا يواجه حالة غامضة أو تأخيرًا غير مبرر.
من خلال تحسين مسار الرسائل، وتقليل عبء الاتصال، وتصميم تدفقات الأوامر بعناية، خفضت Dropp زمن وصول الأمر من التطبيق إلى الجهاز إلى أقل من 800 مللي ثانية عند توفر اتصال مستقر. وفي الوقت نفسه، كان على النموذج نفسه أن يظل قابلًا للاستخدام عبر اتصالات محدودة مثل 2G، حيث يصبح حجم الرسائل وعدد الرحلات الشبكية غير الضرورية عاملين حاسمين.
هذا الرقم يعكس مسار الاتصال الحقيقي بين التطبيق والمنصة والجهاز، وليس اختبارًا معزولًا في المختبر. وقد تؤثر جودة شبكة المستخدم أو الجهاز في النتيجة النهائية، ولذلك يرتبط هذا القياس صراحةً باتصال مستقر ومناسب.
إضافة إلى Backend، طورت Dropp لوحة إدارة Hypernyx ولوحة مركز مراقبة الإنذارات. وتستخدم الفرق التشغيلية هذه الواجهات لإدارة المستخدمين والفنيين والأجهزة وحالات الاتصال ومستويات الوصول وEvents الواردة من الأجهزة.
تمكّن لوحة مركز المراقبة المشغلين من مشاهدة التنبيهات والأحداث المرتبطة بالأجهزة ومتابعتها. وفي منتج أمني، لا يكفي عرض البيانات الخام؛ بل يجب تنظيم المعلومات بطريقة تساعد المشغل على فهم الحالة واتخاذ الإجراء المناسب.
أدى تولي الفريق الهندسي نفسه تطوير Backend واللوحات التشغيلية إلى الحفاظ على اتساق قواعد العمل في جميع أجزاء المنصة. فنُفذت صلاحيات الوصول وإدارة الأحداث وسلوك الخدمات باعتبارها قدرات مترابطة داخل المنتج.
لا يمكن لمنتج متصل بأجهزة فعلية ويرتبط بأمن المستخدمين أن يؤجل الجودة إلى مرحلة الاختبار النهائية قبل الإصدار. لذلك تشمل عملية تطوير Backend في Hypernyx اختبارات Unit وIntegration، ومراجعة الشفرة، والتحليل الثابت، وتتبع الأخطاء.
تتجاوز تغطية اختبارات Backend حاليًا 80٪. وتسمح هذه الضوابط الآلية للفريق بتعديل الخدمات وإضافة قدرات جديدة مع تقليل مخاطر Regression، واكتشاف كثير من المشكلات قبل وصولها إلى Production.
يتولى فريق Hypernyx ضمان جودة المنتج والتحقق من سيناريوهات الاستخدام الكاملة. وبهذا تتشكل منظومة جودة متعددة الطبقات: تركز Dropp على الصحة التقنية والاختبارات الآلية وجودة الشفرة، بينما يتحقق فريق Hypernyx من السلوك النهائي للمنتج عبر التطبيقات والأجهزة الفعلية.
قاد CTO في Dropp تطوير البرمجيات، ونفذه مهندسون Senior في Backend وFrontend. ولم يقتصر دور الفريق على تنفيذ قائمة خصائص محددة مسبقًا؛ بل شارك في القرارات المعمارية، والبحث والتطوير لاتصالات الأجهزة، وتصميم الخدمات، وتحويل متطلبات العتاد إلى سلوك برمجي.
بدأت الشراكة في عام 2021 ولم تنتهِ مع الإصدار الأول. فمع تطور العتاد، واتساع الاختبارات الميدانية، ودخول المنتج إلى التشغيل التجاري، تطورت خدمات Backend واللوحات التشغيلية بالتوازي. وما زالت Dropp مسؤولة بصورة فعالة عن إضافة خصائص جديدة وتحسين المكونات البرمجية الواقعة ضمن نطاقها.
الفريق الذي يعرف أسباب القرارات المعمارية الأولى هو نفسه الذي يطور المنتج اليوم. وبذلك يبقى النمو ضمن اتجاه هندسي متماسك بدل أن يتحول إلى مجموعة من الإصلاحات قصيرة الأمد.
• تصميم وتطوير جميع خدمات Backend من الصفر • تطوير لوحة الإدارة ولوحة مركز مراقبة الإنذارات وموقع Hypernyx • معمارية Microservice وEvent-driven لتطوير الخدمات وتوسعتها بصورة مستقلة • تصميم مشترك للاتصال بين Firmware والأجهزة وخدمات Backend • اتصال قائم على MQTT ومحسن لأحمال إنترنت الأشياء • دعم الاتصالات المحدودة، بما فيها شبكة 2G • وصول الأوامر من التطبيق إلى الجهاز خلال أقل من 800 مللي ثانية عند توفر اتصال مستقر • معالجة أكثر من 10 آلاف Event مرسل من الأجهزة يوميًا حتى 17 سبتمبر 2026 • تغطية اختبارات Backend تتجاوز 80٪، إلى جانب مراجعة الشفرة والتحليل الثابت وتتبع الأخطاء • دعم برمجي لأكثر من 1000 جهاز نشط وتجريبي
النتيجة ليست Backend عاملًا ومجموعة من اللوحات التشغيلية فحسب. انتقلت Hirkania Technologies من فكرة أولية، قبل وجود نموذج نهائي للجهاز، إلى منتج أمني ذكي تجاري تدعمه منصة برمجية موثوقة.
تسمح المعمارية الحالية لـHypernyx بإدارة نماذج مختلفة من المنتج على أساس مشترك، والنمو مع زيادة مبيعات الأجهزة، وإضافة قدرات جديدة من دون إعادة كتابة النواة البرمجية.
يمثل Hypernyx بالنسبة إلى Dropp تطوير البرمجيات المخصصة في أحد أعمق أشكاله: برمجيات لا تعيش فقط في المتصفح أو الهاتف، بل يجب أن تتناغم مع عتاد فعلي وشبكات محدودة ومتطلبات أمنية والعمليات اليومية لمنتج تجاري.
إذا كنتم تصممون منتجًا لإنترنت الأشياء، أو نظامًا متصلًا بالعتاد، أو منصة ذات متطلبات اتصال لحظي، فيمكن لـDropp العمل مع فريقكم من المعمارية والبحث والتطوير إلى تطوير Backend واللوحات التشغيلية والبنية التحتية ودعم Production طويل الأمد. ابدأوا بمراجعة للمنتج ومعمارية البرمجيات.