⚡ electrical engineering

A Comparative Analysis of the CERN ATLAS ITk MOPS Readout: A Feasibility Study on Production and Development Setups

تحدد هذه الورقة بيئة اختبار ومنهجية تحقق شاملة مصممة لتقييم ومقارنة أداء نموذج أولي لمحاكاة MOPS-Hub القائم على Raspberry Pi مقابل نظام MOPS-Hub النهائي القائم على FPGA، لضمان استيفاء الأخير لمتطلبات زمن الاستجابة والارتعاش وسلامة البيانات الصارمة الخاصة بنظام التحكم في كاشف ATLAS ITk.

المؤلفون الأصليون: Lukas Flad, Felix Sebastian Nitz, Tobias Krawutschke

نُشر 2026-04-06

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Lukas Flad, Felix Sebastian Nitz, Tobias Krawutschke

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

الصورة الكبيرة: سباق تتابع عالي المخاطر

تخيل تجربة "أطلس" (ATLAS) في سيرن (CERN) كأنها سباق تتابع ضخم وعالي السرعة يحدث داخل كهف عملاق مشع. العداؤون (كواشف الجسيمات) يمررون العصا (بيانات تصادمات الجسيمات) إلى المدربين (غرفة التحكم) لكي يتمكنوا من اتخاذ قرارات في أجزاء من الثانية.

بالنسبة للترقية الكبرى القادمة (LHC عالي السطوع)، سيصبح المضمار أكثر ازدحاماً وخطورة. فريق التتابع القديم (الكاشف الحالي) سيتم استبداله بفريق جديد فائق السرعة يسمى ITk.

ومع ذلك، هناك مشكلة: العداؤون الجدد يرتدون دروعاً ثقيلة واقية من الإشعاع، ويتحدثون لغة خاصة ذات جهد منخفض جداً (ناقل CAN بجهد 1.2 فولت). يحتاج المدربون إلى طريقة جديدة للاستماع إليهم دون ارتباك أو فقدان أي كلمة.

هذه الورقة البحثية تدور حول بناء واختبار "محطة الاستماع" الجديدة (التي تسمى MOPS-Hub) للتأكد من قدرتها على سماع كل عداء بوضوح، وفوراً، ودون إسقاط رسالة واحدة.

المتنافسان: "المبتدئ" مقابل "المحترف"

كان على الفريق أن يقرر أي نوع من محطات الاستماع يجب بناؤه. لقد كانوا يقارنون بين خيارين:

"المبتدئ" (نموذج MH المحاكي): يستخدم جهاز Raspberry Pi (كمبيوتر صغير ورخيص قد تستخدمه في المشاريع المنزلية).
- التشبيه: تخيل أن الـ Raspberry Pi هو متدرب ذكي ومجتهد، لكنه رائع للتعلم والاختبار، إلا أنه يضطر للقيام بكل شيء خطوة بخطوة. إذا بدأ خمسة عداء بصرخ في وقت واحد، فعل على المتدرب التوقف عن الاستماع للعداء (أ) ليستمع للعداء (ب)، ثم يعود للعداء (أ). هذا "التبديل" يستغرق وقتاً ويسبب تأخيرات.
"المحترف" (MH): يستخدم شريحة FPGA مخصصة (شريحة متخصصة مصممة للسرعة).
- التشبيه: الـ FPGA يشبه فريقاً من 16 سكرتيراً متخصصاً يعملون في تناغم تام. هم لا يتناوبون الأدوار؛ بل يستمعون جميعاً إلى عداؤيهم المخصصين في وقت واحد. لا يتشتت انتباههم أبداً، ولا يضطرون أبداً لـ "تبديل المهام".

الهدف: لا تكتفي الورقة بالقول إن "المحترف أفضل"، بل تضع اختباراً علمياً صارماً لإثبات مدى تفوق المحترف تحديداً، من خلال النظر في زمن الاستجابة (latency) (الوقت المستغرق لسماع الرسالة) والارتجاف (jitter) (مدى اتساق ذلك الوقت).

المشكلة مع الأدوات القياسية

عادةً، عندما يختبر المهندسون أجهزة الكمبيوتر، يستخدمون كمبيوتراً محمولاً عادياً وكابلات USB. أدرك المؤلفون أن هذه فكرة سيئة لهذه المهمة المحددة.

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

اختبار الضغط ثلاثي المراحل

للتأكد من جاهزية نظام "المحترف" للسباق الحقيقي، صمموا ثلاثة اختبارات محددة:

1. "الإحماء" (أداء خط الأساس)

السيناريو: عداء واحد، رسالة واحدة.
الهدف: التحقق من أقصى سرعة ممكنة.
القاعدة: يجب أن تمر الرسالة في أقل من 7 ميلي ثانية.
لماذا؟ على الرغم من أن النظام مصمم لـ "التحكم البطيء" (ثوانٍ أو دقائق)، إلا أنهم يريدون هامش أمان ضخم. إذا كان النظام سريعاً الآن، فسيكون بالتأكيد سريعاً عندما تشتد الأمور لاحقاً.

2. "الملعب المزدحم" (اختبار الضغط الكامل على الصندوق)

السيناريو: تخيل 64 عداءً يصرخون بأعلى أصواتهم جميعاً في وقت واحد لمدة 8 ساعات متواصلة.
الهدف: معرفة ما إذا كان النظام سينهار، أو يتجمد، أو يبدأ في إسقاط الرسائل (فقدان البيانات) عند تعرضه للضغط.
"اختبار النقع" (Soak Test): هذا يشبه تشغيل محرك سيارة بأقصى سرعة ليوم كامل لمعرفة ما إذا كان سيسخن أو يسرب الزيت. يريدون التأكد من أن نظام "المحترف" لا يعاني من "تسريب في الذاكرة" (نسيان الأشياء) أو يتعب بعد نوبة عمل طويلة.

3. "فلتر الضوضاء" (اختبار العزل)

السيناريو: يقومون بتشغيل مكبر صوت عالٍ في القناة (A) ويستمعون إلى القناة (B).
الهدف: التأكد من أن الضوضاء من القناة (A) لا تتسرب إلى القناة (B).
لماذا؟ في الكهف المشع، تعتبر الضوضاء الكهربائية أمراً خطيراً. إذا لم تكن القنوات معزولة تماماً، فقد يتسبب خلل في جزء واحد من الكاشف في حدوث سلسلة من التفاعلات التي تؤدي إلى إيقاف النظام بأكمله. يحتاجون لإثبات أن "الجدران" بين القنوات صلبة.

ما يتوقعون حدوثه

المؤلفون واثقون من توقعاتهم:

الـ Raspberry Pi (المبتدئ): من المرجح أن يعاني. نظرًا لأنه يضطر لـ "تبديل المهام" للاستماع لقنوات مختلفة، فسيصبح مثقلاً بالأعباء خلال اختبار "الملعب المزدحم". قد يسقط رسائل أو يصبح بطيئاً جداً. إنه رائع للتعلم، لكنه ليس للسباق النهائي.
الـ FPGA (المحترف): سوف يتألق. نظرًا لأنه يعالج كل شيء بالتوازي، فسيظل سريعاً ومتسقاً، حتى مع وجود 64 عداءً يصرخون. سيثبت أن الشريحة المخصصة هي الخيار الآمن الوحيد للإنتاج النهائي.

الخلاصة

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

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

بناءً على الورقة المقدمة، إليك ملخص تقني مفصل للتحليل المقارن لنظام قراءة ATLAS ITk MOPS.

1. بيان المشكلة

تتطلب عملية ترقية مصادم الهادرونات الكبير عالي السطوع (HL-LHC) استبدال الكاشف الداخلي لـ ATLAS بكاشف داخلي (ITk) جديد يعتمد كلياً على السيليكون. ويعد "مراقبة نظام البكسل" (MOPS) مكوناً حرجاً في نظام التحكم في الكاشف (DCS) الخاص بـ ITk، حيث يقوم بقراءة الجهود الكهربائية ودرجات الحرارة المحلية من وحدات البكسل عبر ناقل CAN بجهد 1.2 فولت.

لقد اتبع تطوير بنية قراءة MOPS نهجاً ذا مرحلتين:

نموذج MH التجريبي (Mock-up): نموذج أولي أولي يستخدم جهاز Raspberry Pi كتحكم مركزي.
MH (MOPS-Hub): بنية الإنتاج النهائية التي تستخدم منصة تعتمد على FPGA.

التحدي الجوهري: قبل الإنتاج واسع النطاق، يجب تأهيل بنية MH النهائية القائمة على FPGA بدقة مقابل النموذج الأولي. إن أدوات القياس القياسية القائمة على الحاسوب (مثل محولات USB-to-CAN على أنظمة Linux/Windows) تسبب تأخيرات غير حتمية (Jitter) نتيجة لجدولة نظام التشغيل وعبء ناقل USB، وهذه الأخطاء تقع في نفس مقياس أداء النظام المتوقع بمستوى الميلي ثانية، مما يجعل من المستح المستحيل مقارنة البنيتين بدقة أو التحقق مما إذا كانتا تلبيان متطلبات التوقيت الصارمة لبيئة كافير ATLAS.

2. المنهجية

تقترح الورقة منصة اختبار مخصصة عالية الدقة وخطة تقييم ثلاثية المراحل للقضاء على آثار القياس وقياس الأداء.

أ. منصة اختبار "مركز القراءة" (Readout Hub)

للتغلب على قيود الأدوات القائمة على الحاسوب، صمم المؤلفون منصة اختبار مخصصة تتمحور حول متحكم دقيق واحد من نوع STM32F767ZIT6 (معالج ARM Cortex-M7).

بنية الساعة الواحدة: يتم إنشاء جميع الطوابع الزمنية بواسطة مصدر ساعة واحد عالي التردد (يصل إلى 216 ميجاهرتز)، مما يلغي أخطاء التوقيت النسبية بين نقاط القياس.
التوصيل غير التدخلي: تستخدم منصة الاختبار "محول قراءة CAN" للاستماع سلبياً إلى ناقل 1.2V CAN دون التداخل مع الإشارة.
سلسلة القياس:
1. $t_1$ (المدخل): يسجل STM32 الوقت الدقيق لاستلام رسالة CAN من الناقل.
2. $t_2$ (المخرج): يستمع STM32 إلى منفذ تصحيح الأخطاء (UART) للجهاز تحت الاختبار (DUT) ويسجل وقت إخراج البيانات المعالجة.
3. حساب التأخير: $\Delta t = t_2 - t_1$ .
مسار البيانات: يتم تدفق البيانات الخام إلى حاسوب مضيف للتحليل الآلي باستخدام لغة Python، لحساب متوسط التأخير، والانحراف المعياري (Jitter)، وفقدان الحزم.

ب. خطة التقييم ثلاثية المراحل

تحدد المنهجية ثلاث حالات اختبار محددة لتقييم جوانب مختلفة من موثوقية النظام:

حالة الاختبار 1: الأداء الأساسي:
- الهدف: تحديد زمن استجابة الأمر الأساسي تحت الحد الأدنى من الحمل.
- المعيار: زمن الرحلة الذهاب والإياب لطلب SDO واحد.
- القبول: صفر فقدان في الحزم؛ متوسط التأخير $\le$ 7 مللي ثانية (مشتق من الحد الأدنى النظري للناقل وهو 2.2 مللي ثانية $\times$ عامل أمان قدره 3).
حالة الاختبار 2: اختبار الإجهاد الكامل للصندوق (Full Crate):
- الهدف: تقييم القابلية للتوسع والاستقرار تحت أقصى حمل.
- الإعداد: نموذج MH Mock-up (4 دوائر CIC/8 قنوات) مقابل MH (8 دوائر CIC/16 قناة/64 عقدة).
- المدة: "اختبار نقع" (Soak test) لمدة 8 ساعات للكشف عن تسرب الذاكرة أو التدهور الحراري.
- المعيار: صفر فقدان في الحزم؛ متوسط التأخير < 3.3 مللي ثانية؛ والنسبة المئوية 99.9 لزمن التأخير < 7 مللي ثانية.
حالة الاختبار 3: اختبار وظائف CIC والعزل:
- الهدف: التحقق من العزل الكهربائي بين القنوات لمنع حلقات الأرضي (Ground loops) والضجيج.
- الإجراء: حقن إشارات عالية التردد (200 هرتز) في القناة A مع مراقبة القناة B للكشف عن التداخل (Crosstalk).
- القبول: عدم اكتشاف أي حزم في القناة غير النشطة.

3. المساهمات الرئيسية

تصميم منصة اختبار مخصصة: تقديم نظام يعتمد على متحكم دقيق ذو ساعة واحدة قادر على قياس التأخير (Latency) والارتجاف (Jitter) دون الميلي ثانية مع عدم يقين منهجي أقل بكثير من 10 ميكروثانية، متجاوزاً قيود أدوات الحاسوب القياسية.
إطار تحقق مهيكل: خطة شاملة ثلاثية المراحل (أساسي، إجهاد، عزل) تتجاوز مجرد فحص التأخير لتتحقق من القابلية للتوسع، والاستقرار طويل الأمد، ومتطلبات سلامة الأجهزة.
مسار تحليل مؤتمت: سير عمل كامل يتضمن التقاط إشارات الأجهزة، والتقاط بيانات البرامج الثابتة (Firmware)، وسكريبتات Python للتحليل الإحصائي والتصور، مما يضمن قابلية التكرار.
استراتيجية مقارنة كمية: منهجية واضحة للمقارنة الموضوعية بين نموذج Raspberry Pi الأولي ووحدة إنتاج FPGA، مستهدفةً تحديداً مخاطر "عنق زجاجة البرمجيات" في النموذج الأولي.

4. النتائج المتوقعة

بينما توضح الورقة المنهجية (مع عرض النتائج التجريبية في ورقة مرافقة)، إلا أنها تقدم توقعات نظرية قوية:

نموذج MH Mock-up (Raspberry Pi): من المتوقع أن يفشل أو يقل أداؤه في سيناريوهات الحمل العالي. الاعتماد على تبديل السياق القائم على البرمجيات (Multiplexing) ونظام Linux غير الحتمي من المتوقع أن يسبب فقدان البيانات وزيادة في الارتجاف عند التعامل مع عدة نواقل CAN في آن واحد.
MH (FPGA): من المتوقع أن يظهر أداءً فائقاً. تسمح بنية FPGA بالمعالجة المتوازية الحقيقية، مما يعني أن التأخير سيكون محدوداً فقط بسرعة النقل الفيزيائية لناقل 125 kbit/s (حوالي 2.2 مللي ثانية للرحلة الذهاب والإياب) بدلاً من عبء المعالجة.
النتيجة: من المتوقع أن يستوفي MH القائم على FPGA جميع معايير القبول (صفر فقدان في الحزم، ارتجاف منخفض، استقرار عالٍ)، مما يجعله صالحاً للإنتاج، بينما سيُعتبر النموذج الأولي غير مناسب للنشر النهائي.

5. الأهمية

بالغة الأهمية لـ HL-LHC: يعد هذا التحقق شرطاً مسبقاً لإنتاج وتركيب نظام DCS الخاص بـ ITk، والذي يجب أن يعمل بموثوقية في بيئة إشعاعية قاسية ذات معدلات بيانات عالية.
سد الفجوة: يعمل هذا العمل على ملء فجوة حرجة بين ضمان الجودة على مستوى المكونات وبين تشغيل النظام الكامل. فهو يوفر معياراً قابلاً للتكرار والقياس الكمي للتحقق من أداء الاتصال، والذي غالباً ما يتم تجاهله في أوراق التشغيل الأوسع.
السلامة والموثوقية: من خلال الاختبار الصارم للارتجاف، وفقدان الحزم، والعزل الكهربائي، تضمن المنهجية أن النظام النهائي لن يعاني من أخطاء التوقيت أو حلقات الأرضي التي قد تعرض سلامة ونزاهة البيانات في تجربة ATLAS للخطر.
قابلية التطبيق العامة: تقدم تصميم منصة الاختبار والمنهجية مخططاً لتأهيل أنظمة التحكم في الوقت الفعلي الأخرى في فيزياء الطاقة العالية حيث يكون التوقيت الحتمي أمراً بالغ الأهمية.

باختصار، تضع هذه الورقة "قواعد الاشتباك" الصارمة لتأهيل قراءة ATLAS ITK MOPS، مما يضمن أن الانتقال من النموذج الأولي إلى أجهزة الإنتاج يستند إلى بيانات صلبة وقابلة للتكرار بدلاً من الافتراضات النظرية.