في
المقالات السابقة ، ناقشنا وظائف النواة من حيث المهام التي يتم تنفيذها والتفاعل بينها. في هذه المقالة ، نلقي نظرة على ما يمكن أن تفعله النواة ، والذي يتجلى إلى حد كبير في عدد من مكالمات API المتاحة الأخرى. سنجيب أيضًا على السؤال ، ما الذي يحول النواة إلى نظام تشغيل؟
المقالات السابقة في السلسلة:
المادة رقم 5. تفاعل المهام والمزامنةالمادة رقم 4. المهام وتبديل السياق والمقاطعاتالمادة رقم 3. المهام والتخطيطالمادة رقم 2. RTOS: البنية ووضع الوقت الحقيقي
المادة رقم 1. RTOS: مقدمة.
إدارة المهام
بالإضافة إلى جدولة المهام والتفاعل بينهما ، سيشتمل نظام RTOS على وظائف (مكالمات API) لإدارة المهام بطرق مختلفة. دعونا نفكر في بعض الاحتمالات.
إنشاء المهام وحذفهافي نظام RTOS "الديناميكي" ، توجد مكالمات وظيفية تسمح لك بإنشاء المهام (وكائنات RTOS الأخرى) عندما تكون مطلوبة. تتضمن هذه الاستدعاءات مجموعة واسعة من المعلمات التي تحدد المهمة ، على سبيل المثال ، نقطة الدخول ، وحجم المكدس ، والأولوية. تتيح لك استدعاء واجهة برمجة التطبيقات لإزالة المهام المقابلة تحرير الموارد بعد اكتمال المهمة.
في RTOS "الثابت" ، يتم تكوين المعلمات المحددة للمهمة في نوع ملف التكوين أثناء التجميع.
أوقف المهمة واستئنافهاكما رأينا ، معظم RTOS لديها مفهوم حالة "تعليق" المهام. يمكن تحقيق ذلك بطرق مختلفة. واحد منهم هو استدعاء صريح لوظيفة Suspend Task API. يمكن أن يكون سببه نفسه أو مهمة أخرى. تسمح استدعاء "استئناف المهمة" المقابلة للمهمة في قائمة الانتظار مرة أخرى للتخطيط.
حالة النوم المهمةبالنسبة لنظام الوقت الفعلي ، يعد التحكم في الوقت مطلبًا مهمًا ويمكن أن يتخذ أشكالًا مختلفة. وجهة نظر بسيطة هي قدرة المهمة على "النوم" ، أي أن المهمة معلقة لفترة معينة من الزمن. عندما ينفد الوقت ، "تستيقظ" المهمة ويتم ترتيبها مرة أخرى للتخطيط. عادة ما تكون مكالمة API متاحة لهذا الغرض. بالطبع ، تعتمد هذه الوظيفة على توفر المؤقت.
الإعفاءعند استخدام جدولة Round Robin ("carousel") ، قد ترفض مهمة التحكم في المعالج للمهمة التالية في السلسلة. للقيام بذلك ، ستتوفر وظيفة API "Release Release". المهمة غير معلقة ، ستكون متاحة للتخطيط عندما يحين دورها. عند استخدام جدولة شريحة الوقت ، من الممكن أن تحرر المهمة جزءًا من الفاصل الزمني إذا لم يكن لديها عمل مهم للقيام به على الفور. تحرير مهمة ليس له معنى منطقي عند تشغيل جدولة التشغيل حتى الاكتمال أو الأولوية.
إتمام المهمةفي مقال سابق ، وجدنا أنه بالإضافة إلى حالات "جاهزة" أو "معلقة" ، يمكن لـ RTOS دعم حالات المهام الأخرى. يمكن أن تكون المهمة "انتهى" ، مما يعني أن وظيفتها الرئيسية غادرت للتو: لا يلزم استدعاء API خاص. يمكن أن تكون المهمة "تم إنهاؤها" ، مما يعني أنها غير متاحة للتخطيط ويجب إعادة ضبطها لتصبح متاحة للتشغيل مرة أخرى ، راجع "إعادة تعيين مهمة" أدناه. هذا يتطلب مكالمة API خاصة. يختلف توافر حالات المهام الإضافية والمصطلحات المستخدمة وتعريفاتها الدقيقة اعتمادًا على RTOS.
إعادة مهمةتقدم العديد من RTOS مكالمة إلى وظيفة API "إعادة تعيين المهمة" ، والتي تسمح لك بإعادة المهمة إلى حالتها الأصلية. قد تكون في حالة معلقة وتطلب تنفيذ وظيفة "استئناف المهمة" من أجل الوقوف في طابور للتخطيط.
المهام ذات الأولوية ، إلخ.في RTOS "الديناميكي" ، قد تكون مكالمات API متاحة لتكوين العديد من معلمات المهام في وقت التشغيل. تتضمن الأمثلة الأولوية ومدة الفاصل الزمني.
معلومات النظام
في RTOS ، سيكون هناك عدد من مكالمات API لتزويد النظام بمعلومات حول المهمة ، بما في ذلك:
معلومات حول المهام . عدد المهام الموجودة في النظام وتكوينها والحالات الحالية.
معلومات حول كائنات النواة الأخرى. عدد العناصر من كل نوع في النظام وتكوينها ومعلومات حول الحالة الحالية. على سبيل المثال:
- ما السعة الحالية لقائمة الانتظار؟ هل يمكنني إضافة المزيد من الرسائل؟
- كم عدد المهام المعلقة على صندوق بريد معين؟
معلومات حول إصدار RTOS . يمكن أن توفر مكالمة API بيانات مماثلة.
تخصيص الذاكرة
في العديد من التطبيقات ، من المهم أن يتمكن البرنامج بشكل حيوي من التقاط بعض الذاكرة عند الحاجة إليها ، وتحريرها عندما لا تكون هناك حاجة إليها. يحدث نفس الشيء في البرامج الثابتة. ومع ذلك ، فإن الأساليب التقليدية عرضة لمشاكل غير محتملة أو غير ملائمة في تطبيقات سطح المكتب ، ولكنها يمكن أن تكون كارثية لنظام مضمن. ومع ذلك ، هناك طرق لتنفيذ مثل هذه الخدمات ، حتى في RTOS ثابتة.
مشاكل في وظائف malloc () و () مجانية
في برنامج سطح المكتب C ، يمكن للدالة استدعاء
malloc () ، تشير إلى مقدار الذاكرة المطلوبة ، وتعيد المؤشر إلى منطقة التخزين. باستخدام الذاكرة ، يمكن تحريرها عن طريق الاتصال
مجانًا () . يتم تخصيص الذاكرة من منطقة تسمى كومة الذاكرة المؤقتة. تكمن المشكلة في هذا النهج في أنه مع تسلسل غير منسق من المكالمات لهذه الوظائف ، يمكن أن تصبح منطقة الكومة مجزأة بسهولة ، ومن ثم ستفشل عملية تخصيص الذاكرة حتى في حالة توفر ذاكرة كافية ، لأن المناطق المجاورة ليست كبيرة بما يكفي. تستخدم بعض الأنظمة (مثل Java و Visual Basic) مخططات "تجميع البيانات المهملة" المعقدة لإلغاء التجزئة. تكمن المشكلة في أن هذه المخططات يمكن أن تؤدي إلى تأخيرات كبيرة لا يمكن التنبؤ بها في وقت التشغيل والحاجة إلى استخدام مؤشرات غير مباشرة (والتي لا تعمل في C).
إذا تم تنفيذ
malloc () و
free () بطريقة رجعية (عادةً لا) وتم استخدامها من قبل مهام RTOS ، فسيحدث التجزئة بسرعة كبيرة ، وسيكون فشل النظام أمرًا لا مفر منه تقريبًا. في C ++ ، هناك عوامل تشغيل
جديدة وحذف تؤدي بشكل عام نفس الوظائف مثل malloc () و free (). إنهم يخضعون لنفس القيود والمشكلات.
أقسام الذاكرة
لتزويد نظام في الوقت الحقيقي بذاكرة يمكن الوصول إليها ديناميكيًا ، يمكن استخدام نهج كتلة لإدارة الذاكرة. تسمى هذه الكتل عادة "أقسام" ؛ يمكن تخصيص أقسام من "تجمع التقسيم".
يحتوي تجمع الأقسام على عدد معين من الكتل ، لكل منها نفس الحجم. يتم تحديد عدد وحجم الكتل في القسم عند إنشاء تجمع القسم. يمكن أن يكون هذا ديناميكيًا إذا سمح النظام بذلك ، أو بشكل ثابت أثناء التجميع. عادةً ، قد يتضمن التطبيق عدة تجمعات أقسام تقدم كتل بأحجام مختلفة.
إذا كانت المهمة بحاجة إلى ذاكرة ، فإنها تستدعي واجهة برمجة التطبيقات التي تطلب كتلة من تجمع معين. إذا نجحت هذه المكالمة ، فستتلقى المهمة مؤشرًا للكتلة المحددة. إذا فشل المكالمة بسبب لا توجد أقسام متاحة في التجمع المشار إليه ، قد تتلقى المهمة استجابة خطأ. بدلاً من ذلك ، قد يتم حظر المهمة (تعليقها) حتى تقوم مهمة أخرى بتحرير الكتلة في القسم.
عادةً ما تقوم المهمة ببساطة بتمرير المؤشر إلى كتلة من الذاكرة في أي رمز يستخدم الكتلة. هذا يؤدي إلى مشكلة عندما لا تكون هناك حاجة للكتلة. إذا كان الرمز يحتوي على مؤشر فقط للكتلة ، فكيف يمكنه إخبار RTOS من خلال مكالمة API ، من أي تجمع أقسام يريد تحرير الذاكرة؟ الجواب هو أن معظم RTOS يدعم بيانات إضافية في كتلة مخصصة (عادة ما يكون إزاحة سلبية من المؤشر) التي توفر المعلومات المطلوبة. وبالتالي ، لاستدعاء API لتحرير كتلة ، مطلوب فقط عنوانها.
ستحتوي المقالة التالية على مزيد من المعلومات حول أقسام الذاكرة.
الوقت
من المرجح أن تتوفر الوظائف المرتبطة باستخدام الوقت والتحكم فيه في نظام التشغيل في الوقت الفعلي. تختلف الفرص اعتمادًا على RTOS ، ولكننا سننظر في الفرص المتاحة للجمهور. على أي حال ، يعد عداد الوقت الفعلي عنصرًا لا غنى عنه لعمل أي من هذه الخدمات.
وقت النظاموقت النظام البسيط أو "مؤقت الساعة" متاح دائمًا تقريبًا. هذا مجرد عداد (عادة 32 بت) ، والذي يزداد باستخدام روتين خدمة المقاطعة في الوقت الحقيقي ويمكن ضبطه وقراءته من خلال مكالمات API.
مهلة مكالمة الخدمةعادة ، يسمح نظام RTOS بحظر مكالمات واجهة برمجة التطبيقات ، أي يتم تعليق مهمة الاتصال (حظر) حتى يتم توفير الخدمة المطلوبة. عادة ما يكون هذا القفل غامضًا ، ولكن بعض RTOS تقدم مهلة تعود خلالها المكالمة عند انتهاء المهلة إذا استمرت الخدمة غير متاحة. مهلة الاتصال API غير معتمدة من قبل جميع RTOS.
حالة النوم المهمةعادةً ما تتمتع المهام بالقدرة على التوقف المؤقت لفترة محددة من الوقت. نوقش هذا في وقت سابق في قسم إدارة المهام.
موقتات البرمجياتمن أجل مهام البرنامج لأداء وظائف حساب الوقت ، توفر معظم RTOS كائنات عداد الوقت. هذه هي مؤقتات مستقلة يتم تحديثها بواسطة معالج مقاطعة المؤقت في الوقت الحقيقي ، والتي يمكن التحكم فيها بواسطة مكالمات API. مثل هذه المكالمات تكوين ورصد ومراقبة تشغيل الموقت. كقاعدة ، يمكن تعيينها لتشغيل واحد أو إعادة التشغيل التلقائي. عادة ما يتم دعم روتين انتهاء الصلاحية ، وهي وظيفة يتم تشغيلها في كل مرة يكمل فيها الموقت دورة. ستقدم المقالة التالية مزيدًا من المعلومات حول موقتات البرامج ووصفًا لتنفيذها.
المقاطعات والسائقين و I / O
يختلف مدى ارتباط RTOSs بالمقاطعات وإدخال / إخراج. وبالمثل ، تحتوي بعض أنظمة RTOS على بنية واضحة جدًا لمحركات الأجهزة ، والتي يمكن أن تضيف مشاكل عند اختيار منتج معين.
الانقطاعاتتمثل المقاطعات مشكلة لـ RTOS لسببين.
- بدون أي احتياطات ، "معالج المقاطعة" (ISR) "سرقة" وقت المعالج ، وبالتالي تعطيل سلوك RTOS في الوقت الحقيقي.
- إذا قام ISR بإجراء مكالمات API تؤثر على جدولة المهام ، فيجب مراقبة ذلك ، ويجب أن يتمكن RTOS من تشغيل خوارزمية الجدولة الخاصة به.
مثال على استدعاء API هذا هو إجراء إيقاظ مهمة ذات أولوية أعلى من تلك التي تم إطلاقها عند حدوث المقاطعة.
تتحكم بعض وحدات RTOS بالكامل في جميع المقاطعات. تتوفر سلسلة من مكالمات API لـ "تسجيل" برامج ISR. يسمح هذا النهج للجدولة بتحديد متى يتم تمكين المقاطعات ، ويسهل استخدام معظم مكالمات API من ISR.
على سبيل المثال ، تطبق Nucleus RTOS مفهوم معالجات المقاطعة "ذات الأولوية المنخفضة" و "ذات الأولوية العالية" ، والتي توفر إدارة موثوقة للمقاطعة دون زيادة غير ضرورية (أي زيادة في تأخير المقاطعة).
يمكن لـ RTOS الأخرى استخدام وضع "إيقاف التشغيل" التلقائي للمقاطعات ، مما يوفر للمطورين المزيد من الخيارات لضمان عمل معالجات المقاطعة بشكل صحيح. كقاعدة ، يتم توفير بادئة ISR (مقدمة) ولاحقة (خاتمة) إضافية لحماية مكالمات API التي يتم إجراؤها فيه.
تستخدم Nucleus SE روتين مقاطعة خفيف الوزن ، والذي سيتم وصفه في مقال لاحق.
السائقينتحدد معظم أنظمة RTOS بنية برنامج تشغيل الجهاز. قد تختلف التفاصيل اعتمادًا على RTOS ، ولكن عادةً ما يتكون برنامج التشغيل من مكونين متفاعلين: رمز مضمن (مكالمات API) و ISR. عادةً ، ستتوفر مكالمات API أخرى لإدارة برامج التشغيل وتسجيلها.
الإدخال / الإخراجفي الوقت الحالي ، لا يهتم معظم RTOS في السوق بإدخال / إخراج مستوى أعلى ، ولكن بعضها يحدد تدفق الإدخال / الإخراج ، والذي ينشئ أساسًا اتصالًا بين برامج تشغيل الأجهزة المقابلة ووظائف لغة C القياسية ، مثل printf ().
من الناحية التاريخية ، غالبًا ما كانت RTOS تدعم "وحدة التحكم" ، وهي واجهة المستخدم لـ RTOS من خلال قناة تسلسلية. تم استخدام هذا بشكل رئيسي للتشخيص وتصحيح الأخطاء. استخدام المصححات الحديثة التي تدعم تطبيقات التصحيح مع RTOS يلغي الحاجة لمثل هذه الكائنات.
التشخيص
عادةً ، يتطلب RTOS الحد الأقصى من الأداء مع الحد الأدنى من بصمة الذاكرة. لذلك ، فحص السلامة ليس أولوية عالية. بمساعدة تقنيات تصحيح الأخطاء الحديثة التي تأخذ في الاعتبار ميزات RTOS ، يمكن إجراء معظم عمليات الفحص خارج RTOS نفسها.
التحقق من معلمات استدعاء API
يمكن أن تحتوي مكالمات API على العديد من المعلمات المعقدة. قد يسبب هذا أخطاء. توفر العديد من RTOS التحقق من معلمات وقت التشغيل مع إرجاع رمز الخطأ في حالة وجود معلمة غير صحيحة. نظرًا لأن هذا يتطلب رمزًا إضافيًا ، وتؤثر عمليات الفحص نفسها سلبًا على الأداء ، فمن الأفضل التحقق من المعلمات أثناء التجميع أو التكوين.
فحص المكدس
بالنسبة لمعظم أنواع برامج الجدولة (باستثناء Run to Complete) ، لكل مهمة مجموعتها الخاصة ، والتي يتم تحديد حجمها بشكل فردي. في بعض أنظمة RTOS ، يحتوي kernel على مكدس منفصل ؛ وفي حالات أخرى ، يتم "استعارة" حزمة المهام أثناء مكالمة API. من الواضح أن تكامل المكدس مهم لموثوقية النظام بشكل عام. لذلك ، غالبًا ما تقدم RTOSs أدوات للتحقق من تكامل المكدس في وقت التشغيل. هناك عدة خيارات:
- استدعاء API يقوم بإرجاع مقدار مساحة المكدس للمهمة الحالية أو المحددة.
- المعلمات المحيطة للمكدس. يتم تعيين قيمة فريدة (عادة فردية وغير صفرية) ، والتي يتم فحصها بشكل دوري لإعادة كتابتها.
تشخيص التطبيق
على الرغم من حقيقة أن هذه الوظيفة غير مدعومة بشكل مباشر في RTOS ، يمكن تخصيص مهمة تطبيق للتحقق من تكامل النظام بأكمله. قد تكون هذه المهمة مسؤولة عن إعادة ضبط مؤقت جهاز المراقبة. يمكن أن تتلقى المهمة بيانات إدخال دورية (على سبيل المثال ، معلمات الإشارة) من كل مهمة حرجة. لن يتم إعادة ضبط مؤقت جهاز المراقبة (الذي سيمنع إعادة تشغيل النظام) إلا بعد وصول البيانات من جميع المهام.
خدمات غير نواة
يعد نظام RTOS أكثر من مجرد جوهر ركزنا عليه حتى الآن. يختلف نظام تشغيل سطح المكتب هذا اختلافًا كبيرًا عن نظام RTOS المضمّن. عادة ، في نظام تشغيل سطح المكتب ، يتم تجميع جميع المكونات الإضافية أو يمكن تثبيتها (تحتوي جميع أجهزة كمبيوتر سطح المكتب على واجهة مستخدم رسومية ، وبعضها فقط ليس لديها وصول إلى الشبكة). لا يحتوي الكمبيوتر المكتبي على حدود حقيقية للموارد: هناك دائمًا ذاكرة خالية ومساحة على القرص الثابت ومورد وحدة المعالجة المركزية غير مستخدم. في عالم من الأنظمة المدمجة ذات الموارد المحدودة ، قد تكون هناك حاجة إلى مكونات إضافية مثل بطاقات الفيديو ومكونات الشبكة وأنظمة الملفات ، ولكن يجب فصلها وقابليتها لتقليل بصمة الذاكرة.
ميزات الشبكاتترتبط معظم الأنظمة المضمنة إلى حد ما بالشبكات. وبالتالي ، من المتوقع أن يكون هناك اهتمام كبير بحلول الشبكات للأنظمة المضمنة ، والتي يوجد بها عدد كبير من المنتجات في السوق.
TCP / IP هو بروتوكول قياسي يُستخدم على نطاق واسع وهو الخيار الواضح للعديد من التطبيقات. عادة ، يتم استخدام TCP / IP لبروتوكول Ethernet (IEEE802.3) ، والذي يوفر متوسط سرعة 10 ميجا بت / ثانية. اليوم ، 100 ميجابت / ثانية شائعة جدًا ، وعلى النهج 1 جيجابت / ثانية. بالإضافة إلى ذلك ، يمكن استخدام TCP / IP لبروتوكولات أخرى. على سبيل المثال ، PPP (بروتوكول نقطة إلى نقطة) هو تطبيق TCP / IP لنقل البيانات التسلسلية تم تكييفه لاتصالات الإنترنت ذات النطاق العريض.
حتى وقت قريب ، تم استخدام الإصدار v4 من بروتوكول IP (IPv4). ومع ذلك ، يصبح عفا عليه الزمن مع نفاد العناوين المجانية. الحل هو IPv6 ، مما يزيد بشكل كبير من عدد العناوين المحتملة ويوفر أدوات أكثر كفاءة للصيانة والأمن. IPv6 متاح على نطاق واسع ويستخدم في معدات العديد من البلدان ، وكذلك الأنظمة العسكرية حول العالم.
البديل هو بروتوكول مخطط بيانات المستخدم (UDP). يستخدم هذا البروتوكول لأداء أقصى. لا توفر UDP نفس الموثوقية والاتساق مثل TCP ، ولكنها خفيفة الوزن وذات كفاءة عالية.
USB هو الناقل التسلسلي العالمي ، ويستخدم على نطاق واسع في الأجهزة للاتصال بأجهزة الكمبيوتر المكتبية. يوفر واجهة توصيل وتشغيل سهلة الاستخدام للغاية والتي تخفي برامج معقدة إلى حد ما.
يجب تنفيذ الجهاز المضمن الذي يجب توصيله بجهاز الكمبيوتر كوظيفة USB ، والتي تتطلب مجموعة محددة من مكونات البرنامج. إذا كان يجب على الجهاز إدارة الأجهزة الأخرى المتصلة عبر USB (مثل جهاز كمبيوتر عادي) ، فإنه يحتاج إلى مجموعة من البرامج من نوع المضيف.IEEE1394 هو معيار واجهة تسلسلية آخر يستخدم بسرعة لنقل كميات كبيرة من البيانات بين الأجهزة (على سبيل المثال ، لنقل بيانات الفيديو) ، والمعروف أيضًا باسم FireWire و i.Link.البروتوكولات اللاسلكية - أدت الراحة وانتشار التقنيات اللاسلكية المختلفة بين المستهلكين إلى ارتفاع الطلب على القدرات اللاسلكية في الأجهزة المدمجة. توفر شبكة Wi-Fi (مجموعة معايير IEEE802.11) مجموعة كاملة من إمكانات الشبكة ، مما يسمح لك بتنفيذ طوبولوجيا الأقران والبنية التحتية على مسافة كافية. يتزايد الاهتمام بأمان البيانات في مثل هذه الشبكات ، مما يعني أن هذا يجب أن يؤثر على البرامج. توفر تقنيات الراديو الأخرى ، لا سيما Bluetooth و ZigBee ، اتصالات لاسلكية قصيرة المدى من نقطة إلى نقطة.التحقق من البروتوكولنظرًا لارتفاع فرص التواصل ، فهناك العديد من الموردين الذين يقدمون حلولهم. يواجه العملاء تحدي التحقق من جودة المنتجات المتاحة. على عكس نواة RTOS ، فإن التحقق الكامل من وظائف وأداء مكدس البروتوكول ليس مهمة سهلة. لحسن الحظ ، تتوفر مجموعات الأدوات لفحص البروتوكولات (وإن كان بسعر كبير) ، ويمكن للمشتري المحتمل معرفة من المورد الذي حدده للتحقق.الرسوماتأصبحت الواجهة الرسومية أكثر شيوعًا بين الأجهزة المضمنة. يمكن أن تكون شاشة LCD بسيطة للغاية ، وأحادية اللون (مثل الهواتف القديمة ، ومشغلات MP3 ، وأجهزة الإنذار ، وما إلى ذلك). من ناحية أخرى ، يمكن أن يكون لجهاز استقبال التلفزيون الرقمي شاشة HDTV عالية الدقة الخاصة به. تتطلب مثل هذه الشاشة دعم برامج مدمج بالكامل في نواة RTOS.نظرًا لأن الشاشة عادةً ما تحتوي على نوع من أجهزة الإدخال ، غالبًا ما يتم تضمين دعم هذه الأجهزة في حزمة الرسومات. يمكن أن تدعم هذه الحزمة أجهزة التأشير (على سبيل المثال ، الماوس) وشاشات اللمس ولوحات المفاتيح ولوحات المفاتيح الكاملة.يمكن استخدام الرسومات بطرق مختلفة. يمكنه ببساطة توفير مخرجات المعلومات (على سبيل المثال ، مثل لوحة النتائج الإلكترونية). أو يمكن أن تكون الشاشة جزءًا من واجهة مستخدم رسومية جنبًا إلى جنب مع القوائم والنوافذ والرموز والعناصر المماثلة. في أي حال ، هناك حاجة إلى مجموعة محددة من البرامج ، ويجب أن توفر حزمة الرسومات المتوفرة مع RTOS المرونة اللازمة دون زيادة كمية الذاكرة المستخدمة بشكل ملحوظ.أنظمة الملفاتعندما يحتاج تطبيق مضمن إلى تخزين ومعالجة كميات كبيرة من البيانات ، فمن الواضح أنه من المنطقي تنظيم هذه البيانات في نوع من نظام الملفات. يمكن أن تكون البيانات في ذاكرة الوصول العشوائي (RAM) أو في ذاكرة الفلاش المدمجة أو على محرك أقراص USB محمول أو على قرص ثابت عادي أو على قرص ضوئي (قرص مضغوط أو قرص DVD). مرة أخرى ، يجب أن تحتوي هذه الفرصة على دعم برمجي مدمج تمامًا في نظام RTOS. يجب أن يتم تصميم نظام الملفات بعناية لتلبية المتطلبات المتكررة لنظام تعدد المهام.الامتثال مهم بشكل خاص لأنظمة الملفات. على سبيل المثال ، يسمح استخدام تنسيق القرص المتوافق مع MS-DOS للمطورين باستخدام البنية المعمول بها جيدًا ويوفر تبادلًا كاملًا للبيانات مع أنظمة سطح المكتب.