دانلود ‫پروژه سیستم عامل های بلادرنگ

دوره کارشناسی

رشته  کامپیوتر    

گرایش   نرم افزار

بهمن 86

مقدمه:

مهمترین کاربرد سیستمهای بلادرنگ در رابطه با عملیات کنترل پردازش است .

خاصیت مهم سیستم عاملهای بلادرنگ این است که هر فعل و انفعال با کامپیوتر بایستی یک پاسخ در مدت زمانی که از قبل تعیین شده است دریافت دارد .

سیستم بایستی بتواند این زمان پاسخ را گارانتی بکند (عواقب زمان پاسخ بد در رابطه با سیستمی که یک هواپیما و یا یک کارخانه شیمیایی را کنترل میکند را میتوان براحتی تصور کرد ) .

مسئله زمان پاسخ  در عمل به این معناست که معمولاً نرم افزار بصورت خاص-منظور است و به کاربرد بخصوصی اختصاص یافته است .

دستگاههای جنبی چنین سیستمهایی نیز به احتمال قوی دستگاههای بخصوصی هستند .

مثلاً ممکن است که از وسایل حس کننده که با سیگنالهای آنالوگ عمل می کنند به جای ترمینالهای عادی استفاده شوند

مشخصات سیستمهای عامل بلادرنگ:

سیستمهای عامل بلادرنگ را میتوان با داشتن ملزومات یگانه در پنج حوزه عمومی زیر مشخص نمود:

·                   قطعی بودن

·                   پاسخ دهی

·                   کنترل کاربر

·                   قابلیت اطمینان

·                   نرمش با خطا

سیستم عاملی قطعی است که عملیات خود را در زمانهای ثابت یا فواصل زمانی از پیش تعیین شده ، انجام دهد.

وقتی چند فرایند در رقابت برای منابع و زمان پردازنده هستند ، هیچ سیستمی نمی تواند قطعی باشد.

در یک سیستم عامل بلادرنگ ، درخواستهای فرایند برای خدمت توسط رخدادها و زمانبندی های خارجی اعمال می شود.

میزان پاسخگویی سیستم عامل به درخواستها ، اولاً به سرعتی که می تواند به وقفه ها پاسخ دهد و ثانیاً به اینکه آیا سیستم ظرفیت کافی برای اداره تمام درخواستها ، در زمان معلوم دارد یا خیر، وابسته است .

یک معیار مفید برای قابلیت عملکرد قطعی سیستم عامل، حداکثر تأخیر از زمان ورود یک وقفه دستگاه با اولویت بالا ، تا زمان شروع خدمت است .

در سیستم های عامل غیر بلا درنگ ، این تأخیر ممکن است در محدوده دهها تا صدها میلی ثانیه باشد ، در حالیکه در یک سیستم عامل بلادرنگ ممکن است این تأخیر حد بالایی از محدوده چند میکرو ثانیه تا یک میلی ثانیه داشته باشد .

یک مشخصه مربوط ولی مجزا ، پاسخ دهی است.

قطعی بودن درباره این است که سیستم عامل پس از تصدیق ، چه مدت صرف خدمت دادن به وقفه می نماید .

موارد پاسخ دهی عبارتند از :

1.           مقدار زمان لازم برای اداره اولیه وقفه و شروع به اجرای روال خدماتی وقفه .

اگر برای اجرای روال خدماتی وقفه نیاز به تغییر متن باشد ، تأخیر بیش از حالتی است که می توانست روال خدماتی وقفه در متن فرایند جاری اجرا گردد .

2.           مقدار زمان لازم برای اجرای روال خدماتی وقفه.

معمولاً این زمان بستگی به سخت افزار دارد.

3.           تأثیر تو در تو بودن وقفه ها .

اگر یک روال خدماتی وقفه با ورود وقفه دیگری دچار وقفه شود، خدمت مربوط به آن دچار تأخیر میگردد.

قطعی بودن و پاسخ دهی به همراه هم ، زمان پاسخ به رخدادهای خارجی را تعیین می کنند.

ویژگی زمان پاسخ در سیستم های بلادرنگ بسیار حساس است ، زیرا چنین سیستم هایی باید نیازهای زمانی اعمال شده توسط افراد ، دستگاهها و جریان داده ها در خارج از سیستم را رعایت کنند.

عموماً کنترل کاربر در یک سیستم بلادرنگ بسیار وسیع تر از کنترل کاربر در سیستم عامل عادی است .

در سیستم عامل عادی، کاربر یا هیچ گونه کنترلی بر عمل زمانبندی ندارد یا فقط می تواند رهنمونهای کلی ارائه کند.

مثلاً کاربران را از نظر اولویت طبقه بندی نماید .

ولی در یک سیستم بلادرنگ لازم است به کاربر اجازه کنترل دقیق اولویت وظیفه داده شود.

کاربر باید بتواند میان وظیفه های سخت و نرم تفاوت قائل شود و اولویتهای نسبی در هر طبقه را تعیین نماید .

همچنین یک سیستم بلادرنگ به کاربر اجازه می دهد تا مشخصاتی مثل استفاده از صفحه بندی یا مبادله فرا یند ، کدام فرایندها باید در حافظه اصلی مقیم باشند ، کدام الگوریتم های انتقال از دیسک به کار گرفته شوند و اینکه فرایندهای در اولویتهای متفاوت چه حقوقی داشته باشند را تعیین نماید .

قابلیت اطمینان :

قابلیت اطمینان نوعاً در سیستم های بلادرنگ بسیار مهمتر از سیستم های عادی است .

یک خرابی گذرا در سیستم غیر بلادرنگ ممکن است تا تعمیر یا تعویض آن ، منجر به سطح خدمت دهی پایین تر گردد .

ولی در سیستم بلادرنگی که در حال پاسخ دهی و کنترل رخدادها در زمان حقیقی است ، از دست رفتن یا کاهش کارآمدی یک پردازنده می تواند عواقب فاجعه آمیزی (از ضرر مادی گرفته تا آسیب دیدگی کلی دستگاهها یا حتی ازدست رفتن جانها  )داشته باشد.

همانگونه که در سایر موارد نیز دیده می شود .

تفاوت سیستم عامل بلادرنگ و غیر بلادرنگ در یک درجه است .

حتی یک سیستم بلادرنگ نیز باید به گونه ای طراحی شود که به حالات مختلف خرابی ، پاسخ دهد.

نرمش با خطا:

 به مشخصه ای اشاره دارد که با خرابی سیستم ، تا حد ممکن قابلیتها و داده های آن حفظ شود .

مثلاً یک سیستم سنتی UNIX ، وقتی خراب شدن داده ها در هسته سیستم عامل را تشخیص دهد ، یک پیام شکست بر روی میز فرمان متصدی ارائه کرده ، محتویات حافظه را برای تجزیه و تحلیل بعدی شکست ، بر روی دیسک تخلیه می کند و به اجرای سیستم پایان می دهد .

در مقابل، یک سیستم بلادرنگ سعی بر این دارد که یا اشکال را تصحیح کندیا در حالیکه به اجرا ادامه می دهد تأثیرات اشکال را حداقل سازد .

نوعاً ، سیستم به کاربر یا فرایند کاربر اطلاع می دهد که باید عمل اشکال زدایی را آغاز کند و سپس به عملیات خود (احتمالاًدر سطح پایین تری از خدمت دهی ) ادامه می دهد.

در صورتی که خاموش کردن سیستم لازم باشد ، برای حفظ سازگاری پرونده و داده ها نیز تلاش خواهد شد.

یکی از موارد مهم نرمش با خطا به عنوان پایداری شناخته می شود.

یک سیستم بلادرنگ پایدار در مواردی که ارضای تمام مهلتهای زمانی وظیفه غیر ممکن باشد ، مهلتهای زمانی وظیفه های بسیار حساس و اولویت بالاتر را (حتی با عدم رعایت مهلتهای زمانی وظیفه های با حساسیت کمتر  ) برآورده می کند.

برای برآوردن نیازهای ذکر شده ، سیستمهای بلادرنگ امروزی نوعاً شامل خصوصیات زیر هستند :

·        تعویض سریع فرایند یا نخ

·        اندازه کوچک

·        قابلیت پاسخ سریع به وقفه های خارجی

·        عملکرد چند وظیفه ای با ابزارهای ارتباط بین فرایندها ،از قبیل راهنماها ، علائم و رخدادها

·        استفاده از پرونده های ترتیبی خاصکه می توانند داده ها را با نرخ سریعی انباشته کنند.

·        زمانبندی یا قبضه کردن بر اساس اولویت

·        حداقل سازی فواصل زمانی که طی آن وقفه ها غیر فعال می شوند.

·        اولیه هایی جهت تأخیر انداختن وظیفه ها برای یک مدت ثابت و برای توقف یا از سرگیری وظیفه ها

·        هشدارها و علائم پایان مهلت زمانی خاص

قلب یک سیستم عامل بلادرنگ زمانبند کوتاه مدت وظیفه هاست برای طراحی چنین زمانبندی، عدالت و حداقل سازی متوسط زمان پاسخ مهم نیست.

آنچه مهم است تکمیل (یا شروع) کلیه وظیفه های بلادرنگ سخت در مهلت زمانی آنها و همچنین تکمیل (یا شروع) حداکثر وظیفه های بلادرنگ نرم در مهلت زمانی آنهاست.

اغلب سیستمهای عامل بلادرنگ امروزی قادر نیستند مستقیماً با مهلتهای زمانی مقابله کنند.

در عوض، به گو نه ای طراحی شده اندکه تا حد امکان به وظیفه های بلادرنگ پاسخگو باشند.

به طوری که وقتی یک مهلت زمانی نزدیک می شود ، یک وظیفه به سرعت زمانبندی گردد.

از این دیدگاه ،کاربردهای بلادرنگ، نوعاً نیاز به زمانهای پاسخ قطعی (در محدوده چندین میلی ثانیه تا زیر میلی ثانیه ) تحت شرایط بسیار متفاوت دارند.

کاربردهای سریعتر(مثلاًدر شبیه ساز هواپیمای نظامی) محدودیتهایی در حدود10 تا100 میکرو ثانیه دارند.

شکل1-1 طیفی از موارد ممکن را نشان می دهد.

در یک زمانبند با قبضه کردن که زمانبندی ساده نوبت گردشی را به کار می گیرد ، یک وظیفه بلادرنگ به صف آماده افزوده می شودتا برهه زمانی بعدی را بدست آورد(شکل 1-1 الف) .

در این مورد معمولاً مدت زمانبندی برای کاربردهای بلادرنگ قابل قبول نیست .

به طور جایگزین، در یک زمانبند بدون قبضه کردن ، می توانیم از یک راهکار زمانبندی اولویت دار استفاده کنیم و به وظیفه های بلادرنگ اولویت بالاتری دهیم.

وظیفه بلادرنگی که آماده باشد، به محض اینکه فرایند جاری مسدود گردد یا به پایان برسد ،زمانبندی خواهد شد(شکل1-1 ب) .

اگر یک وظیفه کند و با اولویت پایین در بخش بحرانی خود در حال اجرا باشد،این عمل می تواند به تأخیر چندین ثانیه ای منجر گردد.

پس این رویداد هم نمی توندقابل قبول باشد.

یک رویکرد امید بخش تر ترکیب اولویتها و وقفه های بر پایه ساعت است.قبضه کردنها در فواصل منظم رخ می دهند،وقتی یک نقطه قبضه کردن می رسد ، اگر وظیفه با اولویت تری در انتظار باشدوظیفه جاری قبضه می گردد، حتی اگر شامل وظیفه هایی باشد که بخشی از هسته سیستم عامل هستند.

چنین تأخیری می تواند در حد چندین میلی ثانیه باشد(شکل1-1 ج).

اگرچه رویکرد آخر می تواند برای برخی از کاربردهای بلادرنگ کافی باشد، ولی برای کاربردهایی که انتظارات بیشتری دارند کافی نخواهد بود و در این موارد رویکرد انتخاب شده گاهی به نام قبضه کردن فوری خوانده می شود.      

در این رویکرد، سیستم عامل تقریباً بلافاصله به وقفه پاسخ می دهد، مگر اینکه سیستم در بخش قفل شده بحرانی قرار داشته باشد.

به این ترتیب تأخیر زمانی برای یک وظیفه بلادرنگ می تواند به 100 میکروثانیه یا کمتر کاهش یابد.

منابع

[1] M.

A.

Tsoukarellas, V.

C.

Gerogiannis and K.

D.

Economides, “Systemically Testing a Real-Time

Operating System”, IEEE Micro, Vol.15, pp.50-60,

1995.

[2] EIA/TIA-232-C, Interface Between Data Terminal

Equipment and Data Circuit-Terminating Equipment

Employing Serial Binary Data Interchange, EIA

(Electronic Industries Alliance), 1991.

[3] A.

Sung, B.

Choi and S.

Shin, “An Interface Test

Model for Hardware-dependent Software and

Embedded OS API of the Embedded System”, Journal

of Computer Standards and Interfaces, ELSEVIER,

2006, to be published.

[4] R.

Demillo, R.

J.

Lipton and F.

G.

Sayward, “Hints

on Test Data Selection: Help for the practicing

programmer”, IEEE Computer, Vol.11, pp.34-31, 1978.

[5] A.

Offutt, “Investigations of the Software Testing

Coupling Effect”, ACM Transactions on Software

Engineering and Methodology, Vol.1, pp.5-20, 1992.

[6] M.

E.

Delamaro, J.

Maldonado and A.

P.

Mathur,

"Interface Mutation: An Approach for Integration

Testing", IEEE Transactions on Software Engineering,

vol.27, pp228~247, 2001.

[7] Technical Report SERC-TR-41-P, Design of Mutant

Operators for the C Programming Language, Software

Engineering Research Center, Purdue University,

Rev.1.04, 2006.

[8] R.

T.

Alexander, J.

M.

Bieman, S.

Chosh and B.

Ji.,

"Mutation of Java Objects", in the Proc.

of

International Symposium on.

Software Reliability

Engineering, pp.341~351, 2002.

[9] H.

Yoon, and B.

Choi, “Effective Test Case Selection

for Component Customization and Its Application to

EJB”, The Software Testing, Verification and

Reliability Journal, vol.14, pp.45~70, 2004.

[10] A.

Jerraya and W.

Wolf, “Hardware/Software Interface

Codesign for Embedded Systems”, IEEE Computer,

Vol.38, pp.63~69, 2005.

[11] IEEE Standard 1003.1-2001, IEEE Standard for

Information technology – POSIX (Portable Operating

System Interface), IEEE, 2001.

[12] J.J Labrosse, MicroC/OS-II, The Real-Time Kernel,

CMP Books, 1999.

[13] A.

Mader, “A Classification of PLC Models and

Applications”, in the Proc.

of International Workshop

on Discrete Event Systems -- Discrete Event Systems,

Analysis and Control, Kluwer Academic Publishers,

pp.239-247, 2000.

[14] TMS320C32 Digital Signal Processor available in

http://www.ti.com/, Texas Instrument, 1998.

[15] IEC, International Standard for Programmable

Controllers: Programming Languages, Technical

Report IEC 1131 part 3, IEC (International Electro

technical Commission), 1993.

[16] KNICS-PLC-SDS331-01, Software Design

Specification for the PLC Processor Module, KAERI

(Korea Atomic Energy Research Institute), 2006.

[17] S.

Chodrow, F.

Jahnian,and M.

Donner, “Run-Time

Monitoring of Real-Time Systems”, in the Proc.

of

Run-Time Systems Symposium, IEEE, pp.74-83, 1991.

[18] S.

Ricardo and Jr.

R.

de Almeida, “Run-Time

Monitoring for Dependable Systems: an Approach and

a Case Study”, in the Proc.

of International Symposium

on Reliable Distributed System, IEEE, pp.41-49, 2004.

[19] SPRU296, Code Composer User’s Guide, Texas

Instrument, 1999.

[20] J.H.

Andrews, L.C.

Briand and Y.

Labiche, “Is

Mutation an Appropriate Tool for Testing

Experiments?”, in the Proc.

of International

Conference on Software Engineering, pp.

402~411,

2005