معدات مختبر المحاكاة الهجينة. تُظهر الصورة لوحة التحكم SDS 9300 ، والتي ، إلى جانب العديد من أجهزة الكمبيوتر التمثيلية ، أعدت محاكاة لوحدة الأوامر ووحدة القمر.قبل سنوات من تشغيل Apollo 11 ، عندما تم تطوير نظام التحكم ، فكروا في البرنامج المضمن كشيء يمكن القيام به أخيرًا: "هال سيفعل ذلك" ، على حد تعبيرهم. في الواقع ، كان العشرات من الأشخاص ومئات من موظفي الدعم يقومون بذلك ، ولكن كان على Hal Laning أولاً معرفة كيفية تنظيم العديد من وظائف البرنامج بحيث يمكن القيام بها في وقت واحد تقريبًا في الوقت الفعلي على الكمبيوتر الموجود على متن المركبة الفضائية ، والذي له حجم وسرعة محدودان .
تجنبت هندسة هال العثرات في نظام التشغيل حيث يجب تقسيم الحسابات بوضوح بين الفترات الزمنية. يصعب تطبيق مثل هذه الأنظمة ، لأن المهام يمكن أن تتغير بشكل تعسفي. عند إضافة المهام أو تغييرها أثناء عملية التطوير ، قد يلزم إجراء تغيير في تخطيط المهام. أسوأ شيء هو أن نظام التشغيل الحالي للكمبيوتر الموجود هش للغاية ، بمعنى أنه فشل تمامًا إذا استغرقت المهمة وقتًا أطول من الوقت المخصص.
بدلاً من ذلك ، طورت Leining نظامًا يتم فيه توزيع وظائف البرنامج في شكل "مهام" ، والتي يمكن أن تكون بأي حجم تكون مطلوبة لأداء هذه الوظائف. يتم تعيين أولوية لكل مهمة. يقوم نظام التشغيل دائمًا بالمهمة ذات الأولوية القصوى. إذا تم تنفيذ مهمة ذات أولوية منخفضة ، وتم تعيين مهمة ذات أولوية عالية في هذا الوقت ، فسيتم تعليق المهمة ذات الأولوية المنخفضة حتى يتم الانتهاء من المهمة ذات الأولوية العالية. مثل هذا النظام يعطينا الوهم بأن المهام يتم تنفيذها في وقت واحد ، على الرغم من أنه في الواقع ، يتم تنفيذ المهام بدورها. مثل هذا النظام ليس حاسمًا ، لكن وظائفه مفهومة ويمكن التحقق منها ، ويزيد من الموثوقية والأمان والمرونة في الاستخدام ، وخاصة سهولة التطوير.
تنفيذي (
نظام التشغيل في الوقت الفعلي AGC و LGC. الترجمة التقريبية. ) نظّم تنفيذ المهام بطريقة احتفظت كل مهمة بحالتها في شكل مجموعة من السجلات ، وتمت المحافظة على الحالة أثناء تنفيذ المهمة مع إعطاء أولوية عالية. يحتوي LGC على مجموعة من ثماني مجموعات من 12 سجل لكل منها ، 15 بت لكل سجل. تكفي مجموعة من السجلات بهذا الحجم لأداء العديد من المهام ، لكن المهام التي تستخدم المترجم الشفهي (
لغة ترجمة مضمنة للمهام التي تعمل بأرقام مزدوجة الدقة. الترجمة التقريبية. ) لإجراء حسابات متجهية ومصفوفة تتطلب مساحة أكبر. لهذه المهام ، يتم تخصيص مجموعة منفصلة من 43 سجلات. LGC يحتوي على خمسة من هذه الصفائف (Vector Accumulator ، VAC).
مع هذه المجموعة المحدودة من المصفوفات للحفاظ على سياق المهام ، يجب أن يتم إطلاق مهام التنفيذ بعناية فائقة. تم دمج الوظائف التي يتم تنفيذها بالتتابع واحد تلو الآخر في مهمة واحدة. كانت المهمة الكبيرة لـ SERVICER نشطة خلال مرحلة الهبوط بأكملها والمراحل الأخرى من الرحلة مع تشغيل المحرك ، وشملت الملاحة باستخدام مقاييس التسارع ومعادلات الحركة والتحكم في دواسة الوقود للمحرك وبيانات عن موضع السفينة وبيانات أخرى على الشاشة وكل تستخدم وظيفة إخراج السابقة.
يحد عدد صفيفات السجل المتاحة و VAC من عدد المهام التي يمكن وضعها في قائمة الانتظار للتنفيذ بثمانية ، منها ما يصل إلى خمسة يمكن استخدام صفيفات VAC. أثناء التشغيل العادي ، يظل عدد المهام قيد التشغيل ثابتًا ، على الرغم من أن المهام التي يتم تشغيلها لتنفيذ واحد ، أو بشكل غير متزامن ، يمكن أن تسبب تقلبات في تحميل النظام.
ومع ذلك ، إذا كان عدد المهام التي تم البدء فيها أكثر من إكمال ، فسيزيد عدد صفيفات التسجيل المستخدمة و VAC. إذا استمر هذا الموقف لفترة طويلة بما فيه الكفاية ، فإن عددهم ينفد ، ولا يمكن تلبية طلب بدء المهمة التالية.
سنعود قبل عام ، قبل إطلاق Apollo 11 ، عندما اعتقدنا نحن مهندسو البرمجيات أن لدينا بالفعل ما يكفي من الأشياء ، وقد طلبوا منا أن نكتب برنامجًا للهبوط على سطح القمر بطريقة يمكن إيقاف تشغيلها حرفيًا وإعادة تشغيلها دون مقاطعة عملية الهبوط وغيرها من المناورات الحيوية! كان هذا يسمى "إعادة تشغيل الحماية". بالإضافة إلى تداخل الطاقة ، يمكن أن تؤدي عوامل أخرى إلى إعادة تشغيل النظام. تحدث إعادة التشغيل إذا ظن الجهاز أن البرنامج تعطل في حلقة لا نهائية ، أو إذا حدث خطأ تماثل أثناء قراءة ROM ، أو لعدة أسباب أخرى.
تم تنفيذ الحماية من إعادة التشغيل عن طريق تسجيل "نقاط الطريق" في نقاط مناسبة في البرنامج ، مرتبة بطريقة لم تتسبب فيها العودة إلى "نقطة الطريق" الأخيرة ، كما هو مبين في المثال التالي:
NEW_X = X + 1
X = NEW_Xمن الواضح أنه بدون تسجيل نقطة الطريق ، فإن تنفيذ هذه الكود مرة ثانية سيؤدي إلى زيادة X.
بعد إعادة التشغيل ، يستأنف هذا البرنامج عمله. تبدأ كل مهمة بنقطة الطريق الأخيرة المسجلة. إذا كانت هناك عدة نسخ من نفس المهمة في قائمة الانتظار ، فسيستأنف آخر نسخة فقط. بعض المهام ليس لها حالة حيوية ، وليست محمية من إعادة التشغيل. يختفون فقط.
عملت إعادة تشغيل الحماية بشكل جيد للغاية. على لوحة التحكم الخاصة بمحاكاةنا المختلطة في كامبريدج ، كان هناك زر تسبب في إعادة تشغيل AGC. عند اختبار البرنامج ، قمنا أحيانًا بالضغط على هذا الزر في أوقات عشوائية ، على أمل أن يؤدي الفشل إلى حدوث خلل آخر. دائمًا ، في كل مرة يتم فيها تشغيل الحماية من إعادة التشغيل ، استمر العمل دون توقف.
(احتوى جهاز المحاكاة الهجينة على كمبيوتر رقمي SDS 9300 وجهاز كمبيوتر تمثيلي من Beckmann ، وجهاز كمبيوتر AGC حقيقي ، ونماذج قمرة القيادة الواقعية لوحدات القيادة والقمر.)
إعداد Prelaunch من أبولو.ليس فقط الحديد يمكن أن يتسبب في إعادة التشغيل ، بل يمكن أن يطلق عليه برمجيًا إذا وصل البرنامج إلى نقطة لم يعرف الكمبيوتر فيها كيفية متابعة تنفيذ البرنامج. حدث هذا عند نقل التحكم تحت علامة BAILOUT في وحدة الإنذارات والإحباط. كانت المكالمة مرفقة برمز خطأ.
تم تنفيذ هذه الإجراءات من قبل النظام التنفيذي إذا تم استنفاد الموارد. إذا تعذر تعيين المهمة بسبب عدم وجود صفائف مجانية لحفظ السجلات ، فدعت Executive باسم BAILOUT برمز الخطأ 1202. إذا لم يكن هناك VAC مجاني ، فسيتم استدعاء BAILOUT بالكود 1201.
لم يتم تنفيذ جميع الوظائف التي يؤديها LGC كـ "مهام". بالإضافة إلى ذلك ، كانت هناك مقاطعات الأجهزة التي يمكن أن تحدث في أي وقت (إذا لم تكن محظورة بشكل صريح) التي تؤدي وظائف ذات أولوية عالية ، تم تعيين المقاطعات لأجهزة معينة ، بما في ذلك الطيار الآلي الرقمي ، "الوصلة الصاعدة" و "الوصلة الهابطة" (
جهاز الإرسال والاستقبال) البيانات على قناة الراديو مع الأرض. الترجمة تقريبا. ) ولوحة المفاتيح.
يمكن استخدام المقاطعات الأخرى لتنفيذ أجزاء من التعليمات البرمجية التي يجب تنفيذها في وقت محدد. مثل هذه الوظائف كانت تسمى المهام ، وكان من المقرر في روتين فرعي يسمى WAITLIST. "المهام" كان من المفترض أن يكون لها مهلة قصيرة جدا.
بينما تم التخطيط لتنفيذ "المهام" مع إعطاء أولوية معينة ، تم التخطيط "للمهام" لبدء التشغيل في وقت معين. تم مشاركة المهام والمهام في كثير من الأحيان. يمكن بدء المهمة لقراءة قراءات المستشعر ، والتي يجب قراءتها في وقت محدد بدقة ، والمهمة بدورها أطلقت مهمة ذات أولوية معينة لمعالجة هذه القراءات.
عندما قام Hal Lane بتصميم Executive and Waitlist في منتصف الستينيات ، فعل كل شيء من البداية ، دون الاعتماد على أي أمثلة. ومبادئه صحيحة اليوم. توزيع الوظائف بواسطة عدد محدود من العمليات غير المتزامنة ، تحت سيطرة بيئة تنفيذية مع تعدد المهام الاستباقية على أساس الفواصل الزمنية والأولويات ، كل هذا لا يزال أساس أنظمة الكمبيوتر الحديثة في الوقت الحقيقي للتطبيقات الفضائية.
تجميع الجيروسكوبات.* * *
لفهم السبب الجذري للإنذارات على أبولو 11 أثناء الهبوط ، من الضروري النظر في إجراء التقريب مع وحدة القيادة ، والتي تتبع بعد صعود الوحدة القمرية من سطح القمر إلى مدار القمر. مثلما نستخدم رادار الهبوط لقياس الارتفاع والسرعة بالنسبة لسطح القمر عند الهبوط على سطح القمر ، يتطلب اقتراب وحدة القيادة في مدار القمر قياس المسافة والسرعة والاتجاه بالنسبة للسفينة الثانية باستخدام رادار الاقتراب.
يحتوي رادار القرب على العديد من أوضاع التشغيل التي تم ضبطها بواسطة مفتاح الوضع. هذه الأوضاع كالتالي: SLEW و AUTO و LGC. في أوضاع SLEW و AUTO ، يعمل الرادار تحت سيطرة الأمر ، بغض النظر عن LGC. يمكن استخدام وضع التشغيل هذا أثناء الإقلاع والنهج في حالة فشل نظام الملاحة الرئيسي. في وضع SLEW ، يتم توجيه هوائي الرادار يدويًا ، وبقية الوقت ثابت. عندما يستهدف الهوائي الهدف ، يمكنك تبديل الوضع إلى AUTO (التتبع التلقائي) وسيتتبع الهدف. يقيس رادار القرب المسافة والسرعة ، ويتم عرض زوايا دوران الأعمدة التي يدور فيها الهوائي على شاشات قمرة القيادة وعلى المؤشرات في شكل موازين رأسية. أيضًا ، دخلت بيانات المسافة والسرعة إلى نظام توجيه الإجهاض (AGS) ، وهو جهاز كمبيوتر يحتوي فقط على 6144 كلمة من الذاكرة ، مما أدى إلى تكرار نظام PGNS الرئيسي عند الهبوط على سطح القمر والإقلاع من القمر.
(كانت أسماء أنماط تشغيل رادار التقارب الثلاثة مصدرًا لإحراج بعض المعلقين. بناءً على طلب الطاقم ، تم تغيير التعيينات بعد المهمة LM-1 وقبل المهمة التي هبطت على سطح القمر. كان يطلق عليه AUTO على Apollo 11 ، الذي كان يُطلق عليه سابقًا MANUAL. ظل اسم وضع SLEW دون تغيير ، وعلى الرغم من أن هذا لم يساهم بأي حال في المشكلة على Apollo 11 ، إلا أن وثائق LUMINARY الداخلية في القسم المتعلق بالقناة المنفصلة 33 ، في ذلك الوقت ما زالت تسمى re معيار LGC مع تشغيل رادار القرب بواسطة RR AUTO-POWER ON.)
إذا كان نظام PGNS يعمل (كما كان بالفعل) ، يتحكم LGC في الرادار ، وفي هذه الحالة تم ضبط مفتاح وضع الرادار عن قرب على LGC. سمحت إلكترونيات واجهة الرادار للبرنامج بالحصول على بيانات عن المسافة والسرعة المقاسة بالرادار ، وكذلك زوايا عمود دوران الهوائي ، حيث يمكن العثور على الاتجاه إلى الهدف. استخدم برنامج LGC هذه المعلومات لجعل LGC أقرب إلى وحدة الأوامر.
اتضح أن نهج الرادار يمكن أن يعمل أيضًا أثناء الهبوط ، وقد تم ذلك خلال نزول أبولو 11. تتطلب تعليمات الطاقم تشغيل الرادار مباشرة قبل بدء مرحلة P63 والبقاء في وضع SLEW أو AUTO لكامل مناورة الهبوط.
تم تقديم تفسيرات كثيرة حول سبب ضبط الرادار بهذه الطريقة للهبوط على سطح القمر. على سبيل المثال ، ربما يكون بعض الأشخاص في هيوستن قد فكروا في خطة مراقبة الهبوط الهائلة من خلال مقارنة بيانات الرادار مع رسم بياني للقراءات المتوقعة. ومع ذلك ، هناك تفسير أبسط: تم تشغيل الرادار قبل الهبوط فقط من أجل البقاء دافئًا في حالة وقوع حادث أثناء الانقطاع ، وكان في وضع AUTO (إذا كانت الوحدة القمرية في وضع يسمح لك بتتبع وحدة القيادة) أو SLEW (في أوقات أخرى) ، فقط لمنع حركة عديمة الفائدة من الهوائي.
الشكل 7.
PGNS ، ATCA ، والواجهات رادار القربغالبًا ما تُعزى هذه المشكلة (بما في ذلك بواسطة المؤلف سابقًا) ببساطة كخطأ في قائمة التحقق. هذه عبارة غير دقيقة ، تمامًا كما هو غير دقيق لاستدعاء إيقاف تشغيل الشاشة قبل الأوان
محرك دلتا الخامس من الوحدة القمرية هو "خطأ في الكمبيوتر" ، بينما في الواقع كان الخطأ في الوثائق. في الواقع ، لا ينبغي أن يكون موضع مفتاح الرادار Apollo 11 بالقرب من أي مشكلة. ولكن من هنا يمكنك تتبع حالة أخرى من الأخطاء في الوثائق.
قبل سنوات ، تم كتابة الوثائق على وثيقة التحكم في الواجهة (ICD) ، والتي تحدد الواجهة الكهربائية بين PGNS والإلكترونيات ATCA (مجموعة مراقبة الموقف والترجمة) ، والتي تم توفيرها من قبل Grumman Aerospace ، الشركة التي قامت ببناء وحدة الهبوط. قرر التصنيف الدولي للأمراض أن محاذاة دوائر الإمداد بالطاقة بجهد 28 فولت بتردد 800 هرتز في نظامين يجب محاذاتها بتردد ، لكن لم تتم كتابتها على أنه يجب مزامنتها في الطور. في الواقع ، كان النظامان محاذاة التردد مع إشارة "تزامن التردد" المرسلة من LGC. كان لديهم علاقة مرحلة ثابتة. ومع ذلك ، كانت المرحلة بين الفولتية متغيرًا عشوائيًا تمامًا ، اعتمادًا على اللحظة التي بدأت فيها LGC ، التي كانت تعمل دائمًا بعد ACTA ، في إرسال إشارة التزامن. وتظهر هذه الواجهات في الشكل. 7.
تم اكتشاف مشكلة في المرحلة 800 هرتز عند اختبار وحدة الهبوط LM-3 وتم توثيقها ، ولكن لم يتم حلها مطلقًا. ونتيجة لذلك ، عندما كان مفتاح وضع الرادار في وضع AUTO أو SLEW ، كانت الآلية الدوارة للرادار متحمسة بإشارة 800 هرتز من ATCA ، والتي مع احتمال كبير لا يتزامن في الطور مع إشارة 800 هرتز ، والتي يتم استخدامها كمرجع في وحدات CDUs التي تحول الإشارات من آلية للتحول إلى بيانات للكمبيوتر ، وتناقص (أو تقليل) العدادات في الكمبيوتر التي تخبر البرنامج كيف يتم تدوير الهوائي.
على أبولو 11 ، ومع ذلك ، عملت CDUs بشكل مختلف. نظرًا لأنهم أخذوا الجهد الكهربي الذي تم إنشاؤه بشكل منفصل كإشارة مرجعية ، فقد أظهرت إشارات استشعار زاوية الهوائي التي استقبلها CDU زاوية غير معروفة. كان الخطأ أكبر إذا كان فارق الطور يقترب من 90 أو 270 درجة ، ومن الواضح أن Apollo 11 بلغ إحدى هذه النقاط المثيرة للاهتمام. ردا على ذلك ، بدأ CDU بزيادة أو إنقاص عدادات LGC بسرعة ثابتة تقريبًا ، حوالي 6400 نبضة في الثانية لكل من الزوايا. حدث هذا في كل مرة كان فيها المفتاح في وضع SLEW أو AUTO ، بغض النظر عما إذا كان رادار القرب قيد التشغيل أم لا.
تمت زيادة عدادات CDU في LGC أو تقليلها بواسطة إشارات خارجية تمت معالجتها في الكمبيوتر. كان هذا مضيعة للوقت ، في هذه الحالة دورة ذاكرة 11.7 .7 لكل منهما. إذا كانت العدادات تزداد بسرعة قصوى ، فقد استغرق الأمر حوالي 15٪ من إجمالي الوقت (يطلق على هذا الوقت الضائع TLOSS). نحن نقدم حاليًا تقديرًا متحفظًا للوقت الذي تستغرقه 13٪ ، وهو ما يتماشى مع السلوك الملحوظ.
بعد رحلة أبولو 11 ، أجرى مهندسو غرومان اختبارات في محاولة لإعادة إنتاج سلوك الكمبيوتر الذي لوحظ في الرحلة. وأكدوا أنه حتى في أسوأ الحالات ، لم تتمكن وحدات CDU من إرسال نبضات بأقصى سرعة. لقد توصلوا إلى استنتاج مفاده أن الحمل الأقصى للكمبيوتر باستخدام هذه العدادات (TLOSS) يمكن أن يكون 13.36٪. أثناء المحاكاة ، تم استنساخ أخطاء مشابهة لتلك التي حدثت في الرحلة. وبالتالي ، فإن قيمة TLOSS المقتبسة هي أفضل تقدير موثق لحمل كمبيوتر Apollo 11. [Clint Tillman ، "محاكاة واجهة RR-CDU عندما يكون RR في وضع SLEW أو AUTO (وليس LGC) في مختبر FMES / FCI ،" 9 أغسطس ، 1969]
أنا مدين لخبير نظام التوجيه وحدة القمر جورج سيلفر لتفسيره المريض واجهة وحدة رادار نهج القمر. لعب دوراً رئيسياً في مهمة Apollo 11. في وقت الإطلاق ، كان في Cape Canaveral ، ثم سافر إلى بوسطن ، إلى كامبريدج ، لتولي مهمة مراقبة الإقلاع من القمر. شاهد القمر وهو يهبط في المنزل على شاشة التلفزيون في 20 يوليو. لقد سمع أصوات الإنذارات ، خمّن أن هناك شيئًا ما يستغرق وقت الكمبيوتر ، وتذكر حالة رآها أثناء اختبار أنظمة LM-3 ، عندما تسبب رادار القرب في نشاط محموم للعدادات. بعد إجراء بعض التحليلات الإضافية من قبل فريق مراقبة مهمة كامبريدج ، اتصل Silver أخيرًا بممثلي معهد ماساتشوستس للتكنولوجيا في هيوستن صباح يوم 21 يوليو ، قبل أقل من ساعة من الإقلاع من القمر.
جزء التحكم اليدوي* * *
كان الهبوط على سطح القمر هو المرحلة الأكثر كثافة في الرحلة. كان على نظام التحكم في الهبوط أن يحقق هدفًا مع إحداثيات معينة ، له سرعة معينة ، تسارع ، درجة من الرجيج (درجة التغيير / التسارع). أطلق كلومب على معدل تغيير النطر "المفاجئة" ، وتم تسمية المشتقين التاليين "الخشخشة" و "البوب". في مرحلة الرؤية (
أي عندما يكون سطح القمر مرئيًا في رصيف السفينة. تقريبًا. ) سمح البرنامج للطاقم بتغيير موقع الهبوط ، وتم التحكم في الخانق بشكل مستمر ، وشمل التنقل قياسات باستخدام رادار الهبوط. يظهر الشكل 8. ملف تعريف حمل نموذجي بين اختيار المرحلة P63 ولمس سطح القمر.
التين. 8:
الحمل أثناء الهبوط (بيانات المحاكاة)حتى في ظل هذه الظروف ، حاولنا جعل برامجنا سريعة بما يكفي لتوفير وقت كافٍ في حالة وجود TLOSS كبير. كان القيد الرئيسي هو الفترة الثانية ، والتي تم دمجها في برنامج "متوسط G" المستخدم خلال مرحلة الطيران.
كانت هذه هي الفترة التي قرأت فيها مهمة READACCS قراءات مقاييس التسارع وأطلقت مهمة SERVICER ، التي استخدمت هذه القيم كبيانات أولية لتكرار جديد لحسابات المسار ، اختناق المحرك ، وتحديد موضع السفينة وعرضها على الشاشة. أثناء الهبوط ، أظهرت درجة تحميل الكمبيوتر ببساطة مقدار الوقت الذي تم إنفاقه على المهام والانقطاعات خلال كل فترة من الثانية.خلال مرحلة الكبح ، حتى رأى رادار الهبوط السطح ، كان الوقت الاحتياطي 15٪ على الأقل. بعد تشغيل الرادار ، تبدأ حسابات إضافية ، مرتبطة بنقل الإحداثيات من نظام مرجع الرادار إلى نظام الإحداثيات للملاحة ، مما يقلل الهامش بنسبة 13٪. عندما تبدأ الشاشة (الفعل 16 ، الاسم 68) ، ينخفض الهامش إلى 10٪ أو أقل. كان باز الدرين مدركًا عندما قال بعد الإشارة 1202 ، "يبدو أنه ظهر عندما دخلنا عام 1668" [16].عندما يكون الهامش 10٪ و 13٪ مأخوذ ، لا يوجد لدى LGC وقت معالج كافٍ لتنفيذ جميع الوظائف المطلوبة. بسبب مرونة التصميم التنفيذي ، وعلى عكس ما يمكن أن يحدث مع الهندسة المعمارية الصلبة ، لم تكن هناك كارثة.الجدول 1. المهام النشطة عند الهبوط على سطح القمر.
يسرد الجدول 1 المهام النشطة عند الهبوط في Apollo 11. يكون SERVICER هو الأفضلية الأدنى ، ويدير أطولها. يمكن للمهام ذات الأولوية العليا إيقاف الخادم ، ولكن لديها مهلة زمنية قصيرة نسبيًا.نظرًا لأن SERVICER كانت لها أولوية منخفضة نظرًا لحجمها الكبير ، فقد تعطلت بسبب نقص وقت الحوسبة. مع وجود هامش سلبي في الوقت المناسب ، لم يتمكن SERVICER من تقديم إجابة عندما بدأت READACCS ، التي بدأت وفق جدول زمني ، وبدأت تشغيل SERVICER مرة أخرى. نظرًا لأن النسخة السابقة من SERVICER لم تنته من الحساب ، فإنها لم تحرر صفيفات السجل و VAC ، ودعا READACCS FINDVAC إلى Executive لتخصيص سجل جديد ومجموعة VAC وبدء SERVICER. هذا الخادم أيضا لم ينته المهمة في الوقت المحدد. بعد دورة قصيرة من هذه العمليات ، انتهى السجل ومصفوفات VAC. عندما جاء الطلب التالي إلى Executive ، تم استدعاء BAILOUT بالرمز 1201 أو 1202.
صورة 9: تشغيل SERVICER بدون TLL ومعهالتين.
يوضح الشكل 9 كيف يتصرف SERVICER مع TLOSS قوي ، وفي الشكل. يوضح الشكل 10 مقارنة بين السجلات ومجموعات VAC أثناء التشغيل العادي ومع TLOSS القوي ، والذي يحدث أثناء إعادة التشغيل.
التين.
10. التأثير الناتج عن TLOSS على الموارد التنفيذية وقائمة الانتظار أثناء الهبوط على سطح القمر (تبدأ بيانات المحاكاة بالمرحلة P63 قبل استلام بيانات السرعة من الرادار وتنتهي بالهبوط [17].)تأثير مثير للاهتمام لهذا التسلسل للأحداث أثناء المرحلة P63 ، أن المشكلة قضت على نفسها. تمت إعادة تشغيل البرنامج لاستعادة أحدث نسخة من مهمة SERVICER ، وحذف جميع النسخ غير المكتملة من SERVICER. بالإضافة إلى ذلك ، أكمل جميع الوظائف التي ليس لديها حماية ضد إعادة التشغيل لأنها ليست حرجة ، بما في ذلك شاشة DELTAH (الفعل 16 ، الاسم 68). تسبب هذا في تبديل الشاشة من "الاسم 68" إلى "الاسم 63" بعد إنذارين في P63.تم تطوير نظام حماية إعادة التشغيل في الأصل نظرًا لوجود أعطال محتملة في الأجهزة وتوفير انخفاض في الحمل الحسابي باستخدام TLOSS كبير. تحول نظام الوقت الفعلي الذي قمنا بتطويره إلى تحمل الأخطاء في ظروف معينة.خلال مرحلة P64 ، كان الوضع مختلفًا. بالإضافة إلى معادلات الحركة المعتادة ، تمت إضافة معالجة إضافية شملت القدرة على إعادة تعيين موقع الهبوط. تترك ميزات البرامج الإضافية بهامش وقت أقل من 10٪. استمرت الإنذارات في الظهور. وقعت ثلاث منبهات من 1201 و 1202 في غضون 40 ثانية. في كل مرة ، يتم إعادة تشغيل البرنامج ، محو قائمة انتظار المهام ، لكنه لم يستطع تقليل التحميل.وقت المهمة 102: 43: 08 ، متوقعًا التنبيه التالي ، قام Armstrong بتحويل الطيار الآلي من وضع AUTO إلى وضع ATT HOLD ، مما أدى إلى إضعاف الحمل الحسابي ، ثم دخل في وضع P66 شبه اليدوي ، حيث كان حمل الكمبيوتر منخفضًا. بعد دقيقتين و 20 ثانية من المناورة في المرحلة P66 ، جلس النموذج القمري.