یک مرکز پزشکی خودکار از دستگاه های مختلفی استفاده می کند که عملکرد آنها باید توسط سیستم اطلاعات پزشکی (MIS) کنترل شود و همچنین دستگاه هایی که دستورات را نمی پذیرند، اما باید نتایج کار خود را به MIS منتقل کنند. با این حال، همه دستگاه ها دارای گزینه های مختلف اتصال (USB، RS-232، اترنت و غیره) و راه های تعامل با آنها هستند. پشتیبانی از همه آنها در MIS تقریبا غیرممکن است، بنابراین لایه نرم افزار DeviceManager (DM) ایجاد شد که یک رابط واحد برای MIS برای اختصاص وظایف به دستگاه ها و به دست آوردن نتایج ارائه می دهد.
برای افزایش تحمل خطای سیستم، DM به مجموعه ای از برنامه های واقع در رایانه های مرکز پزشکی تقسیم شد. DM به یک برنامه اصلی و مجموعه ای از پلاگین ها تقسیم می شود که با یک دستگاه خاص تعامل دارند و داده ها را به MIS ارسال می کنند. شکل زیر ساختار تعمیم یافته تعامل با DeviceManager، MIS و دستگاه ها را نشان می دهد.
ساختار تعامل بین MIS و DeviceManager 3 گزینه را برای افزونه ها نشان می دهد:
- این افزونه هیچ داده ای را از MIS دریافت نمی کند و داده های تبدیل شده به فرمتی قابل فهم را از دستگاه ارسال می کند (مطابق با نوع دستگاه 3 در شکل بالا).
- این افزونه یک کار کوتاه (از نظر زمان اجرا) از MIS دریافت می کند، به عنوان مثال، چاپ روی چاپگر یا اسکن یک تصویر، آن را اجرا می کند و نتیجه را در پاسخ به درخواست ارسال می کند (مطابق با نوع دستگاه 1 در شکل بالا). ).
- این افزونه یک وظیفه طولانی مدت از MIS دریافت می کند، به عنوان مثال، برای انجام یک نظرسنجی یا اندازه گیری شاخص ها، و در پاسخ وضعیت پذیرش کار را ارسال می کند (در صورت وجود خطایی در درخواست، ممکن است این کار رد شود). پس از تکمیل کار، نتایج به فرمتی قابل فهم برای MIS تبدیل می‌شوند و در واسط‌های مربوط به نوع آنها آپلود می‌شوند (مطابق با دستگاه نوع 2 در شکل بالا).
برنامه اصلی DM شروع می شود، مقداردهی اولیه می شود، در صورت توقف غیرمنتظره (خراش) مجدداً راه اندازی می شود و در صورت خاموش شدن، همه افزونه ها را خاتمه می دهد. ترکیب پلاگین ها در هر رایانه متفاوت است؛ فقط موارد ضروری راه اندازی می شوند که در تنظیمات مشخص شده اند.
هر افزونه یک برنامه مستقل است که با برنامه اصلی تعامل دارد. این تعریف از یک پلاگین به دلیل استقلال تمام نمونه های افزونه و هد از نظر رسیدگی به خطا، عملکرد پایدارتری را امکان پذیر می کند (اگر خطای بحرانی رخ دهد که باعث خرابی افزونه شود، این امر بر سایر پلاگین ها و هد تأثیری نخواهد گذاشت) . یک پلاگین به شما امکان می دهد با دستگاه های یک نوع (اغلب یک مدل) کار کنید، در حالی که برخی از افزونه ها فقط با یک دستگاه تعامل دارند، در حالی که برخی دیگر می توانند با چندین دستگاه تعامل داشته باشند. برای اتصال چندین دستگاه از یک نوع به یک DM، چندین نمونه از یک پلاگین را راه اندازی کنید.
جعبه ابزار Qt برای توسعه DM مورد استفاده قرار گرفت زیرا به ما امکان می دهد در بیشتر موارد از یک سیستم عامل خاص انتزاع کنیم. این امکان پشتیبانی از کار با رایانه های مبتنی بر ویندوز، لینوکس و MacOS و همچنین دستگاه های تک برد Raspberry را فراهم کرد. تنها محدودیت در انتخاب یک سیستم عامل هنگام توسعه افزونه ها، در دسترس بودن درایورها و/یا نرم افزار ویژه برای یک دستگاه خاص است.
تعامل بین پلاگین ها و هد از طریق یک QLocalSocket دائما فعال با نام یک نمونه پلاگین خاص، طبق پروتکلی که ایجاد کردیم، رخ می دهد. اجرای پروتکل ارتباطی در هر دو طرف به عنوان یک کتابخانه پویا طراحی شده بود که امکان توسعه برخی پلاگین ها توسط شرکت های دیگر را بدون آشکار کردن کامل تعامل با هد فراهم می کرد. منطق داخلی سوکت محلی به هد اجازه می دهد تا با استفاده از سیگنال قطع اتصال، فوراً در مورد سقوط مطلع شود. هنگامی که چنین سیگنالی راه اندازی می شود، پلاگین مشکل ساز دوباره راه اندازی می شود، که به شما امکان می دهد شرایط بحرانی را بدون دردسرتر مدیریت کنید.
تصمیم گرفته شد تا تعامل بین MIS و DM بر اساس پروتکل HTTP ایجاد شود، زیرا MIS بر روی یک وب سرور کار می کند، که ارسال و دریافت درخواست ها را با استفاده از این پروتکل آسان تر می کند. همچنین می توان مشکلاتی را که ممکن است هنگام تنظیم یا انجام وظایف با دستگاه ها بر اساس کدهای پاسخ ایجاد شود، تشخیص داد.
در مقالات بعدی با استفاده از مثال چند اتاق مرکز تشخیص، عملکرد DM و برخی پلاگین ها مورد بررسی قرار می گیرد.
منبع: www.habr.com