// سطح: helix-primary · سفارش 9
HelixOTA in-developmentاجازهنامه: Apache-2.0
منبع
بهروزرسانیهای بیسیم جهانی و کاملاً جداشده — طراحی بدون آجر شدن
Helix OTA یک سیستم بهروزرسانی بیسیم جهانی و عمیقاً جداشده است: یک صف کنترل Go به همراه عاملهای کلاینتی برای هر سیستمعامل، طراحیشده برای ارائه بهروزرسانیهای ایمن و مرحلهای firmware و اپلیکیشن به ناوگانی از یک برد واحد تا میلیونها دستگاه. اولین هدف آن اندروید ۱۵ روی Orange Pi 5 Max است.
Helix OTA یک سیستم بهروزرسانی بیسیم جهانی است — یک صف کنترل Go به همراه عاملهای کلاینتی برای هر سیستمعامل — که برای جلوگیری از خرابی سیستم، اعتبارسنجی آپلودها و انتشار مرحلهای دقیق طراحی شده است. اولین هدف آن اندروید ۱۵ روی Orange Pi 5 Max است و آداپتورهای لینوکس و ویندوز در برنامههای آینده قرار دارند.
Helix OTA یک سیستم بهروزرسانی بیسیم (OTA) جهانی، عمومی و عمیقاً جداشده است که بر پایه یک وعده بیچونوچرا ساخته شده است: یک بهروزرسانی هرگز نباید دستگاه سالم را به آجر تبدیل کند. این سیستم شامل یک صف کنترل سروری Go، SDKها/عاملهای کلاینتی برای هر سیستمعامل و یک داشبورد مدیریتی است و از پایه برای قابلیت تعبیه در *هر* سیستمعاملی از طریق آداپتورهای قابل اتصال طراحی شده است، نه بازنویسی از ابتدا برای هر پلتفرم. اولین هدف پیادهسازی، اندروید ۱۵ (همه نسخهها) روی Orange Pi 5 Max است، جایی که خط تولید، تصاویر فلش را در کنار یک فایل فشرده OTA اعتبارسنجیشده و فایلهای هش اجباری تولید میکند، به طوری که هیچ مصنوعی بدون اثر انگشت قابل تأیید به دستگاه نمیرسد؛ لینوکس، ویندوز و سایر سیستمعاملها در نقشه راه، پشت همان درز آداپتور قرار دارند و تنها منتظر آداپتور خود هستند — نه بازنویسی.
طراحی این سیستم بر اساس تضمینهای سختگیرانهای است که توسط اپراتور تعیین شده و به عنوان ثابتهای غیرقابل مذاکره معماری در نظر گرفته میشوند: صفر خرابی سیستم، اعتبارسنجی اجباری هر مصنوع پیش از استقرار، انتشار مرحلهای دقیق (همهجا یا مرحلهای با گامهای ۵/۱۰/۳۰…۱۰۰٪ و قابلیت توقف و پیشروی)، مشاهدهپذیری کامل ناوگان و مقیاسپذیری خطی از یک برد روی میز تا میلیونها دستگاه در میدان. معماری قفلشده، بهروزرسانیهای بومی اندروید A/B سمت دستگاه — update_engine 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— به این دلیل انتخاب شده که استفاده مجدد از مکانیزمهای تستشدهٔ اندروید برای بهروزرسانی مجازی 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/قرار دارند. - ارقام پوشش تست و تأخیر در مخزن، دفترچهٔ در حال پیشرفت خود پروژه هستند و بهطور مستقل تأیید نشدهاند. شمارههای بندهای HelixConstitution که در فایل README ذکر شدهاند، تأییدنشده هستند.
- مجوز: Apache-2.0.
اولویت سطح: Helix-اصلی.