// tier: helix-primary · order 9

HelixOTA in-developmentlicense: Apache-2.0

GoGinKotlin / KMPHTTP/3 QUICPostgreSQLMinIO / S3AOSP update_engine + AVB/dm-verityReactOpenTelemetryPrometheus / Grafana

Source

• HelixDevelopment/helix_ota

// architecture

تحديثات عبر الهواء العالمية المنفصلة — صفر أعطال عن تصميم.

Helix OTA هو نظام تحديثات عبر الهواء عالمي ومنفصل بعمق: يتكون من مستوى تحكم Go ووكلاء عملاء لكل نظام تشغيل، ومصمم لتقديم تحديثات آمنة ومتدرجة للبرامج الثابتة والتطبيقات إلى أساطيل تتراوح من لوحة واحدة إلى ملايين الأجهزة. أول هدف له هو نظام أندرويد 15 على جهاز Orange Pi 5 Max.

Helix OTA هو نظام تحديثات عبر الهواء عالمي — يتكون من مستوى تحكم Go ووكلاء عملاء لكل نظام تشغيل — تم هندسته لضمان عدم تلف النظام، والتحقق من صحة التحميلات، ونشر التحديثات بشكل تدريجي ومرن. أول هدف له هو أندرويد 15 على جهاز Orange Pi 5 Max، مع خطط لتطوير محولات لأنظمة لينكس وويندوز.

Helix OTA هو نظام تحديثات عبر الهواء (OTA) عالمي وعام ومنفصل بعمق، بُني لتحقيق وعد واحد لا يقبل المساومة: ألا يتحول التحديث أبداً جهازاً يعمل إلى قطعة خردة. يتألف النظام من خادم مستوى التحكم Go، ومجموعات تطوير البرمجيات/وكلاء العملاء لكل نظام تشغيل، ولوحة تحكم إدارية، وقد تم تصميمه من الأساس ليتم دمجه في *أي* نظام تشغيل عبر محولات أنظمة قابلة للتوصيل بدلاً من إعادة بنائه من الصفر لكل منصة. أول هدف للتسليم هو أندرويد 15 (جميع إصداراته) على جهاز Orange Pi 5 Max، حيث ينتج خط الإنتاج صوراً قابلة للتفليش إلى جانب ملف OTA .zip مُتحقق منه وملفات تجزئة إلزامية، بحيث لا يصل أي ملف إلى الجهاز دون بصمة قابلة للتحقق؛ بينما تنتظر أنظمة لينكس وويندوز وغيرها في خارطة الطريق خلف نفس واجهة المحول، ولا تحتاج سوى إلى محول خاص بها — وليس إعادة كتابة كاملة.

يعتمد التصميم على ضمانات صارمة يحددها المشغل وتُعامل كمسلمات معمارية غير قابلة للتفاوض: صفر تلف للنظام، والتحقق الإلزامي من كل ملف قبل نشره، ونشر تدريجي مرن (إما دفعة واحدة أو على مراحل بنسبة 5/10/30…100% مع إمكانية التوقف والتقدم)، ومراقبة كاملة للأسطول، وقابلية للتوسع الخطي بدءاً من لوحة واحدة على طاولة الاختبار وصولاً إلى ملايين الأجهزة في الميدان. يجمع الهيكل الثابت بين تحديثات أندرويد الأصلية من جانب الجهاز — محرك تحديث AOSP مع AVB/dm-verity والعودة التلقائية عند فشل الإقلاع — وبين مستوى تحكم Go المخصص والمنفصل، بحيث تتواجد السلامة في مسار الإقلاع القريب من العتاد *وفي* الخادم معاً، وليس في طبقة واحدة هشة. تم الاحتفاظ عمداً بواجهتين قابلتين للاستخراج: واجهة محول النظام التي تحمل وعد العالمية الحقيقية، وواجهة محرك النشر التي تجعل حملات النشر التدريجي مستقلة عن النظام. تم تفكيك النظام بأكمله إلى ستة وحدات فرعية عامة ومستقلة الإصدار باسم ota-* — وهي وحدات بناء قابلة لإعادة الاستخدام بدلاً من كونها كتلة واحدة متجانسة.

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

المحتوى

عادةً ما يُعاد اختراع OTA لكل جهاز ولكل نظام تشغيل، وقد يتسبب تحديث سيئ في تعطيل أسطول كامل من الأجهزة. بُني Helix OTA ليكون نظام تحديث عالمياً واحداً يضع الأمان أولاً، ويمكن لأي نظام تشغيل تبنيه عبر محولات، مع ضمانات الاستعادة والتحقق مدمجة في البنية بدلاً من إضافتها لاحقاً.

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

• طبقتان قابلتان للفصل: طبقة محول النظام وطبقة محرك نشر مستقل عن النظام، مما يحول كلمة "عالمي" من مصطلح تسويقي إلى خاصية بنيوية في قاعدة الشفرة.
• الأمان متعدد الطبقات: نظام A/B الأصلي على الجهاز (update_engine) + AVB/dm-verity + الاستعادة التلقائية عند فشل الإقلاع، متراكبة *فوق* التحقق من صحة القطع البرمجية على الخادم – إذ يجب أن يجتاز التحديث عدة بوابات مستقلة قبل أن يصبح دائماً.
• التفكيك القائم على الكتالوج أولاً: تقسيم إلى ستة وحدات فرعية قابلة لإعادة الاستخدام (ota-*) تُدار إصداراتها بشكل مستقل، ويمكنك استخدامها حسب الحاجة بدلاً من اعتماد نظام متكامل.
• النقل الأساسي HTTP/3 (QUIC) مع العودة التلقائية إلى HTTP/2 والضغط التفاوضي باستخدام Brotli/gzip – نقل حديث منخفض الكمون يتحلّى بالمرونة بدلاً من الفشل.
• هندسة مكافحة التضليل: التصميم والحالة مُعلَّمان بوضوح على أنهما في مرحلة المواصفات، ولا يُدَّعى أبداً أن ما لم يُبنَ قد نُشر – حيث يُفرض الصدق كقيمة هندسية أساسية، وليس كتنويه في الهوامش.

• ضمان ألا يتسبب تحديث سيئ في تعطيل الجهاز أبداً – أصعب وعد في OTA. تم التغلب عليه بفرض نظام A/B الأصلي على الجهاز: حيث يكتب update_engine إلى الفتحة غير النشطة بينما تستمر الفتحة النشطة في العمل، ويتحقق AVB/dm-verity من سلسلة الإقلاع تشفيرياً، وإذا فشلت الفتحة الجديدة في الإقلاع يعود الجهاز تلقائياً إلى الحالة السابقة – وكل ذلك مدعوم بفحص إلزامي للقطع البرمجية قبل النشر بحيث يُكتشف الملف الفاسد قبل مغادرته للخادم.
• نظام واحد للعديد من أنظمة التشغيل – تم التغلب عليه برفض دمج افتراضات أندرويد في النواة. إذ توفر طبقة محول النظام القابلة للتوصيل عزلاً للخصائص الخاصة بالنظام، وتبقي طبقة محرك النشر المستقلة عن النظام منطق الحمل قابلاً للنقل، وكل منهما يُدار كوحدة فرعية منفصلة بحيث يكون إضافة نظام تشغيل جديد مجرد إضافة، وليس عملية جراحية شاملة.
• عمليات النشر المرحلية والقابلة للإيقاف – تم التغلب عليها بمحرك نشر مخصص يعمل على أساس مجموعات نسبية مع عتبات نجاح/خطأ وتحكم صريح في الإيقاف/التقدم، ويُصمم عمداً خالياً من الارتباط بـ HTTP بحيث يمكن لنفس المحرك إدارة الحملات بشكل مستقل عن وسيلة النقل.

المحتوى

• Go + Gin — اختيرت لنموذجها المتزامن وبصمتها الخفيفة في النشر؛ تشغل مستوى التحكم، محرك النشر، ومدققي القطع الأثرية، وتعرض سطح REST الرئيسي /api/v1.
• Kotlin/KMP — اختيرت لتمكين وكيل OTA على أجهزة أندرويد من مشاركة المنطق عبر الأهداف المختلفة؛ تدير دورة الجهاز الكاملة للاستعلام/التنزيل/التحقق/التطبيق/التقرير.
• HTTP/3 (QUIC) → HTTP/2 — اختير QUIC كوسيلة نقل رئيسية لتقديمه منخفض الكمون ومرناً عبر الروابط المتقطعة للشبكات المحمولة، مع العودة التلقائية إلى HTTP/2 لضمان عدم ترك أي جهاز دون اتصال؛ يتم التفاوض على Brotli/gzip لكل طلب لتقليص حجم الحمولة.
• PostgreSQL — اختير لضمان التكامل العلائقي بين سجل الأجهزة، الحملات، والبيانات القياسية، حيث تكون دقة حالة الأسطول أهم من سرعة الكتابة الخام.
• MinIO / S3 — اختيرا كمخزن للقطع الأثرية الكبيرة بحيث تُخزن صور البرامج الثابتة في تخزين الكائنات السلعي، منفصلة عن الطبقة العلائقية.
• AOSP update_engine + AVB/dm-verity + boot_control — اختيرت لأنها تعيد استخدام آليات أندرويد الافتراضية والمختبرة جيدًا لـ Virtual A/B والتحقق من الإقلاع بدلاً من ابتكار أداة تحديث مخصصة؛ تُستخدم لإدارة تبديل الفتحات والتحقق التشفيري من الإقلاع على الجهاز.
• React — اختير لواجهة إدارة لوحة التحكم حيث يقوم المشغلون بتسجيل الدخول، رفع القطع الأثرية، إدارة عمليات النشر، ومراقبة صحة الأسطول في مكان واحد.
• OpenTelemetry + Prometheus/Grafana — اختيرت لأدوات القياس المحايدة للبائعين؛ تُستخدم لجعل كل مرحلة من مراحل النشر قابلة للرصد عبر المقاييس ولوحات التحكم بدلاً من الاعتماد على التخمين.

• الحالة: قيد التطوير. وفقاً لسياسة المشروع الخاصة بعدم المبالغة، لا يوجد حتى الآن خادم إنتاجي أو وكيل عامل — هذه مرحلة تحديد المواصفات والبحث وتوسيع نطاق تغطية الاختبارات. يحتوي المستودع على مجموعة التصميم الرسمية، خط أنابيب تصدير الوثائق، وهياكل الوحدات الفرعية.
• توجد ست وحدات فرعية عامة قابلة لإعادة الاستخدام (ota-protocol، ota-artifact-validator، ota-rollout-engine، ota-update-engine-bridge، ota-android-agent، ota-telemetry-schema) تحت github.com/HelixDevelopment/.
• أرقام تغطية الاختبارات ومؤشرات الكمون في المستودع هي سجل المشروع قيد التنفيذ، ولم يتم تأكيدها بشكل مستقل. أرقام البنود المذكورة في ملف README وفقاً لـ HelixConstitution غير مؤكدة.
• الرخصة: Apache-2.0.

درجة الأولوية: Helix-أساسية.