RTOS أم لا RTOS هو السؤال

لقد طُلب مني كتابة هذا المقال بواسطة مجموعة طويلة من التعليقات (للأسف لا أستطيع أن أسمي هذه المناقشة) لمقالتي الأخيرة "العالم المتنوع للأنظمة المضمنة ومكان Embox فيه" . لقد تعرضت للتوبيخ في عدة أماكن بسبب الخلط بين RTOS و Embedded OS ، والتي وصفتها LynxOS و QNX و VxWorks وليس RTOS ، رغم أنني في رأيي بالطبع لم أفعل ذلك. اقترحت على مؤلف هذه التعليقات عدة مرات أن يكتب مقالًا يوضح فيه رؤيته لمفهوم "نظام التشغيل في الوقت الفعلي" ، لكنه رفض لسبب ما. حسنًا ، سوف أقدم رؤيتي لهذا المصطلح ، ولنناقش ما يمكن أن يسمى RTOS وما لا يمكن. في النهاية ، يُطرح هذا السؤال غالبًا فيما يتعلق بـ Embox .

يشير مصطلح OS RV (RTOS) إلى مجال التسويق!

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


ولكن يمكنك الذهاب إلى المحكمة لذلك! وهناك سوف تحتاج إلى تقديم الأدلة. ولكن كيف تثبت أنك أسرع في جميع الحالات؟ هذه ليست منافسة جارية. ولكن بطبيعة الحال ، فإن مثل هذه المنافسة غير الصحيحة تمامًا تخرج عن وضع السوق العادي.

يتضمن الوضع العادي تكوين صورة للمستهلك ، وتحديد خصائص المنتج الأكثر طلبًا ، والتركيز على هذه الخصائص. حسنا ، أو يمكنك تشكيل هذه الاحتياجات على المستخدم. على سبيل المثال ، لدى معالجنا هذا التردد ، والهاتف الذكي يحتوي على معالج N-core ، وهكذا.

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

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

كيف يتم تلقيها؟ يوصف بصراحة هذه العملية! نحن هنا نواجه مشكلة نموذج كهذه وكذا ، مثل نظام أساسي للأجهزة وكذا ، ونطبق التأثير. حسنًا ، يمكن للتسويق ، بالطبع ، تبسيط وقت رد الفعل 1 .s فقط. لكننا لا نأخذ هذا في الاعتبار ، نحن نعتقد أن كل شيء موصوف بصدق.

لكن عفوا ، ماذا لو كانت هناك مهمة أخرى؟ 10 مهام ، 100 مهمة؟ وإذا كان مبرمج في حالة سكر أقفال المقاطعات؟ وإذا كان في النظام لم مبرمج لا يعطي الأولوية للمهام بشكل صحيح؟

كانت هناك حالة عندما مرت Embox الاختبارات في الوقت الحقيقي. جلسنا وفكرنا في كيفية إثبات أن هذا نظام تشغيل في الوقت الفعلي. يوجد مختبر ، هناك عميل يريد أن يكون الأمر كذلك. لقد اكتشفنا أن الوقت الحقيقي للعميل يعني أن وقت استجابة النظام هو 1 μs. أسأل عما إذا كانت التجربة التالية ستكون دليلًا:

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

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

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

تعريف مصطلح "نظام التشغيل في الوقت الحقيقي"

الآن سوف أعرض مصطلح "نظام التشغيل في الوقت الحقيقي". لا ، أنا لا أفعل. الحقيقة هي أن هناك الكثير من التعاريف لهذا المصطلح. خذ على الأقل التعليقات على المقال الأصلي:

في أنظمة الوقت الفعلي ، يكون الشخص غير ضروري بشكل عام ، وبالتالي ، يجب مقارنة سرعة النظام في الوقت الفعلي بالعمليات التي يتحكم فيها ، سواء كانت سيارة مستقلة أو نظام تحكم عملية في المصنع.

SRV / RTOS - هذا هو مجرد ترتيب حول إمكانية التنبؤ بالاستجابة للأحداث الحرجة.

RTOS هو مثل نظام التشغيل الذي تتميز فيه صحة المهمة ليس فقط بالصحة المنطقية ، ولكن بالوقت الذي يستغرقه إكمال هذه المهمة.

قم بتعيين معيار تبديل سياق أي مهمة إلى معالج واحد لكل 100 ميجاهرتز باستخدام معالج ثانوي ذو نقطة تعويم مع تحديد 0.1 and وسيوضع كل شيء في مكانه.
سترى بوضوح حيث RTOS وأين لا.

حسنًا ، لا يمكنني تجاهل الرأي الذي تحدثت عنه في مقال تم التعبير عنه في أحد مؤتمرات OSDAY :

يمكن اعتبار النظام نظامًا صعبًا في الوقت الحقيقي إذا لم يكن لديه أماكن حيث توجد ، مع مقاطعة مغلقة ، دورات بها عدد غير معروف من التكرارات.

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

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

هناك نوع آخر من نظام الوقت الفعلي وهو نظام الوقت الفعلي الناعم ، والذي يكون فيه تحديد مهلة زمنية غير متوقعة ، رغم أنه غير مرغوب فيه ، مقبولًا ولا يسبب أي ضرر دائم. تقع أنظمة الصوت أو الوسائط المتعددة الرقمية في هذه الفئة. الهواتف الرقمية هي أيضا أنظمة في الوقت الحقيقي لينة.

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

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

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

كيفية تحقيق خصائص في الوقت الحقيقي

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

دعونا نفكر في كيفية تحقيق ذلك.

سيكون من الواضح إزالة جميع الأشياء غير الضرورية من النظام الحرج. من غير المرجح أن يكون النظام العالمي مستقراً. حتى الرفيق Tanenbaum تحدث عن هذا ، يعني ، عندما تحدث عن eCos.

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

يجب أن يضمن المطور نجاح جميع المهام في إكمال شريحة وقتهم. للقيام بذلك ، يُقترح إجراء تحليل ثابت للمهمة الحرجة وتحديد قيمها. وضعت هذه الطريقة في معيار ARINC-653. المعيار للأنظمة على متن الطائرة ، وأنت تفهم نفسك ، إذا لم يكن هناك شيء فجأة لديه وقت للعمل على متن الطائرة ، يمكن أن تحدث كارثة.

النهج التالي هو جدول ثابت ، ولكن على أساس الأولويات. بمعنى ، يجب على المطور تحليل جميع المواقف مرة أخرى ، وبعد تعيين جميع المهام في أولويات النظام ، تأكد من إكمال المهام الهامة في وقت معين.

لا أريد المتابعة لأن هناك نسخة أصلية! إنه مكتوب ، بالطبع ، أفضل مما يمكنني فعله ، وبالإضافة إلى ذلك ، يمكن اتهامهم مرة أخرى بتشويه الحقائق. لقد ذكرت على وجه التحديد هذه الأساليب من أجل إظهار أنه على أي حال ، يتحمل مطور النظام النهائي مسؤولية ضمان خصائص النظام. وينبغي أن يوفر نظام التشغيل فقط القدرات المناسبة.

مواصلة المناقشة حول طرق لزيادة القدرة على التنبؤ ، أريد أن أعطي تعليق آخر

"يمكنك تحقيق وقت حقيقي على التوت ، ولكن ليس مع RTOS ، ولكن مع اقتحام جهاز صغير في ذاكرة التخزين المؤقت."

هنا أريد أن أنبه إلى النقاط التالية:

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

مع انخفاض مقدار عدم القدرة على التنبؤ في حالة انخفاض عدد سطور التعليمات البرمجية ، أعتقد أن الجميع يتفقون. على الرغم من أنني ، كما هو الحال دائمًا ، لا أوافق ، لكنني أوافق على ذلك لاحقًا.

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

تمثيل البرنامج كجهاز دولة ، أود أن أقترح النظر فيه من جانب غير واضح. وهي أنه يمكن تحليل برنامج القدرة على التنبؤ. ونظرًا لأننا نتحدث عن جميع الظروف ، فيجب تحليلها ، وبشكل ثابت ، لجميع المواقف الممكنة. حسنًا ، نظرًا لأن لغات البرمجة الوظيفية مناسبة تمامًا للتحليل الثابت ، فمن الممكن تطوير برنامج بلغة خاصة أو إضافة استخدام لغات برمجة خاصة. يتم استخدام الطريقة الأولى ، على سبيل المثال ، في seL4 kernel الذي تم التحقق منه. مثال على النهج الثاني هو نفس معيار ARINC-653 ، مع تشكيله الإلزامي للمتطلبات في XML.

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

هل يوجد RTOS على الإطلاق؟

بعد أن استقرت على العبارة الواردة في القسم السابق والتي تشير إلى وجود أخطاء في أي كود ، أريد أن أقدم أطروحة أكثر استفزازية. هل يوجد RTOS على الإطلاق؟

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

ولكن ليس لدينا شك في وجود أنظمة في الوقت الحقيقي. وبالطبع ، RTOS أيضا. إذا لم يكن الأمر كذلك ، فإن أول نقار الخشب الطائر يدمر الحضارة ، فلن يكون هناك إلكترونيات طيران ، وفضاء فضاء ، وإنسان آلي ، ACS-TP وأكثر من ذلك بكثير.

كيفية الخروج من الوضع. الأمر بسيط للغاية ، على الرغم من أن المشكلة بشكل عام غير محتملة على الأرجح ، لكن بالنسبة لمشكلة معينة ، من الممكن فرض قيود تجعلها قابلة للحل ، مع وجود نوع من الاحتمال المعقول للخطأ.

على سبيل المثال ، يتم تقديم المعايير: POSIX الفعلي ، ARINC-653 ، ITRON . هذه المعايير ، في الواقع ، تميز فئة من المهام التي يمكن حلها إذا كنت تلتزم بهذا المعيار. أو يتم إجراء الدراسات من قبل مختبرات مستقلة تدرس ما إذا كانت خصائص نظام تشغيل معين مناسبة لحل المشكلة المستهدفة.

لذلك Embox RTOS أم لا RTOS؟

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

سكرتير خاص في وقت كتابة هذا التقرير ، لم تتأثر RTOS واحد.