نظام تشغيل في الوقت الحقيقي

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

من الخصائص الرئيسية لأنظمة التشغيل في الوقت الحقيقي (RTOS) مستوى اتساقها فيما يتعلق بالوقت اللازم لقبول مهمة تطبيق ما وإتمامها ؛ ويُطلق على هذا التباين اسم " التذبذب ". ^{[ 1 ]} لا يهدف التصميم الأساسي إلى تحقيق إنتاجية عالية ، بل إلى ضمان أداء مناسب، سواء كان أداءً مرنًا أو صارمًا . يُصنف نظام التشغيل في الوقت الحقيقي الذي يستطيع عادةً أو بشكل عام الالتزام بالموعد النهائي كنظام تشغيل مرن في الوقت الحقيقي، أما إذا كان قادرًا على الالتزام بالموعد النهائي بشكل حتمي، فيُصنف كنظام تشغيل صارم في الوقت الحقيقي. ^{[ 2 ]}

يتميز نظام التشغيل في الوقت الحقيقي (RTOS) بخوارزمية متقدمة للجدولة . تتيح مرونة المُجدولة تنسيقًا أوسع لأولويات العمليات على مستوى نظام الحاسوب، إلا أن نظام التشغيل في الوقت الحقيقي غالبًا ما يُخصص لمجموعة محدودة من التطبيقات. من العوامل الرئيسية في نظام التشغيل في الوقت الحقيقي تقليل زمن استجابة المقاطعات وتقليل زمن استجابة تبديل الخيوط ؛ ويُقيّم نظام التشغيل في الوقت الحقيقي بناءً على سرعة استجابته وقابليتها للتنبؤ أكثر من كمية العمل التي يُمكنه إنجازها في فترة زمنية محددة. ^{[ 3 ]}

أكثر التصاميم شيوعاً هي:

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

تُغيّر تصميمات المشاركة الزمنية المهام بشكل متكرر أكثر من اللازم، ولكنها توفر تعدد مهام أكثر سلاسة ، مما يعطي وهمًا بأن عملية أو مستخدمًا لديه الاستخدام الوحيد للآلة.

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

في التصاميم النموذجية، تتكون المهمة من ثلاث حالات:

1. تشغيل (تنفيذ على وحدة المعالجة المركزية)؛
2. جاهز (جاهز للتنفيذ)؛
3. محظور (في انتظار حدث، مثل عمليات الإدخال/الإخراج).

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

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

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

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

يُعرف زمن الاستجابة الحرج، والذي يُسمى أحيانًا زمن الاستعادة، بأنه الوقت اللازم لإضافة مهمة جديدة إلى قائمة الانتظار واستعادة حالة المهمة ذات الأولوية القصوى إلى وضع التشغيل. في نظام تشغيل الوقت الحقيقي المصمم جيدًا، تتطلب إضافة مهمة جديدة إلى قائمة الانتظار من 3 إلى 20 تعليمة، بينما تتطلب استعادة المهمة ذات الأولوية القصوى من 5 إلى 30 تعليمة.

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

يُعد نظام التشغيل متعدد المهام، مثل يونكس، ضعيفًا في التعامل مع المهام الآنية. إذ يُعطي المُجدوِل أعلى أولوية للمهام الأقل استهلاكًا لموارد الحاسوب، ما يجعل ضمان حصول المهام الحساسة للوقت على موارد كافية أمرًا مستحيلاً. يجب على أنظمة تعدد المهام إدارة مشاركة البيانات وموارد الأجهزة بين مهام متعددة. وعادةً ما يكون من غير الآمن أن تصل مهمتان إلى نفس البيانات أو موارد الأجهزة في الوقت نفسه. ^{[ 5 ]} توجد ثلاثة مناهج شائعة لحل هذه المشكلة:

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

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

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

يُعد تخصيص الذاكرة أكثر أهمية في نظام التشغيل في الوقت الحقيقي مقارنة بأنظمة التشغيل الأخرى.

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

سبب آخر لتجنب تخصيص الذاكرة الديناميكي هو تجزئة الذاكرة. فمع التخصيص المتكرر لأجزاء صغيرة من الذاكرة وتحريرها، قد تنشأ حالة تُقسّم فيها الذاكرة المتاحة إلى عدة أقسام، ولا يستطيع نظام التشغيل في الوقت الحقيقي تخصيص كتلة ذاكرة متصلة كبيرة بما يكفي، على الرغم من وجود مساحة كافية من الذاكرة الحرة. ثانيًا، تُعد سرعة التخصيص أمرًا بالغ الأهمية. إذ يقوم نظام تخصيص الذاكرة القياسي بفحص قائمة مرتبطة ذات طول غير محدد للعثور على كتلة ذاكرة حرة مناسبة، ^{[ 6 ]} وهو أمر غير مقبول في نظام التشغيل في الوقت الحقيقي، حيث يجب أن يتم تخصيص الذاكرة خلال فترة زمنية محددة.

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

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

مع أن جميع أنظمة التشغيل في الوقت الحقيقي (RTOS) قادرة على العمل على المتحكمات الدقيقة التي تدعمها، فإن بعضها، مثل Zephyr، قادر على تجريد عدد من برامج تشغيل الأجهزة بشكل أكبر، مثل ذاكرة الفلاش الخارجية، وأجهزة I2C، أو الأجهزة الطرفية الداخلية كأوامر UART وأوضاع السكون. هذا يُغني المطورين عن إنشاء برامج التشغيل بأنفسهم، إذ تُوفّر لهم مجموعة من واجهات برمجة التطبيقات (APIs) لنقل برامج التشغيل غير المدعومة، بينما تكون برامج التشغيل المدعومة جاهزة للاستخدام مباشرةً في كود التطبيق.