آوردن تفکر شیءگرا به برنامه‌نویسی PLC
طراحی شیءگرا برای PLC با استفاده از مؤلفه‌های کپسوله‌شده، رابط‌های صریح، ترکیب، مدل‌های حالت، آزمون و کنترل نسخه، خطر کپی‌کردن و چسباندن را کاهش می‌دهد—درحالی‌که قابلیت‌های واقعی هر پلتفرم کنترلر ر...
تفکر شیءگرا می‌تواند استفادهٔ مجدد، آزمون و نگه‌داری نرم‌افزار PLC را آسان‌تر کند، اما یک مجموعه‌قابلیت جهانی و یکسان نیست. برخی محیط‌های IEC 61131-3 از متدها، رابط‌ها، ویژگی‌ها، وراثت و چندریختی پشتیبانی می‌کنند. سایر پلتفرم‌های کنترلی، بدون پیاده‌سازی مدل کامل شیءگرا، بلوک‌های تابع قابل‌استفادهٔ مجدد، دستورهای افزوده، انواع دادهٔ تعریف‌شده توسط کاربر یا کتابخانه‌ها ارائه می‌دهند. مهندسان باید دقیقاً بر اساس پلتفرم و نسخهٔ مورد استفاده طراحی کنند.
هدف عملی، تقلید از نرم‌افزارهای سازمانی نیست. هدف این است که هر شیر، موتور، کانال آنالوگ و واحد پکیج را هر بار مانند یک تمرین جدید کپی‌و‌پیست نکنیم. یک مؤلفهٔ نرم‌افزاری با تعریف مناسب، برای هر تجهیز رابط، مدل وضعیت، رفتار هشدار، مسیر شبیه‌سازی و سابقهٔ تشخیصی یکسانی فراهم می‌کند و در عین حال سیم‌کشی خاص ماشین و حدود فرایند را خارج از هستهٔ قابل‌استفادهٔ مجدد نگه می‌دارد.
سخت‌افزار از ابتدا ماژولار طراحی می‌شود؛ نرم‌افزار قابل‌استفادهٔ مجدد نیز باید رابط، وضعیت و رفتار خرابی هر ماژول را به همان اندازه شفاف کند.
با کپسوله‌سازی شروع کنید، نه وراثت
کپسوله‌سازی یعنی قرار دادن وضعیت و رفتار مرتبط پشت یک رابط تعریف‌شده. یک مؤلفهٔ شیر ممکن است فرمان‌ها، مجوزها، بازخورد، حالت و پیکربندی را دریافت کند. همچنین ممکن است وضعیت‌های باز، بسته، در حال حرکت، خراب، اینترلاک‌شده و تشخیصی را ارائه دهد. تایمر داخلی، تشخیص تغییر وضعیت، سیاست تلاش مجدد و منطق هشدار تحت مالکیت خود مؤلفه باقی می‌مانند.
این رویکرد حتی در پلتفرمی که وراثت ندارد نیز ارزشمند است. یک بلوک تابع یا دستور افزوده همچنان می‌تواند از وضعیت داخلی محافظت کند، رفتار را استاندارد سازد و کد تکراری را کاهش دهد. وراثت فقط زمانی مفید است که رابطهٔ واقعی «است-یک» وجود داشته باشد و نوع مشتق‌شده بتواند به رابط پایه پایبند بماند. درخت‌های وراثت عمیق، تشخیص آنلاین را دشوار می‌کنند و ممکن است یک تغییر جزئی در پایه، ماشین‌های بسیاری را تحت تأثیر قرار دهد.
تعریف نوع، دادهٔ نمونه و نگاشت ورودی/خروجی را جدا کنید
یک تعریف قابل‌استفادهٔ مجدد، رفتار را توصیف می‌کند. یک نمونه، وضعیت یک تجهیز فیزیکی یا منطقی را ذخیره می‌کند. نگاشت ورودی/خروجی، آن نمونه را به سیگنال‌های واقعی متصل می‌کند. ترکیب این مسئولیت‌ها، منطق کتابخانه را به آدرس‌های رک وابسته می‌کند و آزمون آفلاین ایمن را ناممکن می‌سازد.
تگ‌های ورودی و خروجی فیزیکی را در مرز یکپارچه‌سازی نگه دارید. سیگنال‌های خام را به مقادیر بولی یا واحدهای مهندسی شفاف تبدیل کنید، مؤلفهٔ قابل‌استفادهٔ مجدد را فراخوانی کنید، سپس درخواست‌های تأییدشدهٔ خروجی را به سخت‌افزار نگاشت دهید. این ساختار از شبیه‌سازی، ورودی/خروجی جایگزین و مهاجرت مرحله‌ای پشتیبانی می‌کند. همچنین باعث می‌شود برنامهٔ سطح بالا به‌جای دست‌کاری مکرر آدرس‌ها، هدف فرایند را نشان دهد.
کنترلرها و خانواده‌های ورودی/خروجی را می‌توان در مجموعهٔ سیستم‌های PLC و PAC بررسی کرد، اما معماری نرم‌افزار انتخاب‌شده باید از زبان‌های پشتیبانی‌شده، مدل حافظه، قوانین تغییر آنلاین و گواهی ایمنی کنترلر پیروی کند.
از رابط‌ها به‌عنوان قراردادهای رفتاری استفاده کنید
هرجا پلتفرم از رابط‌ها پشتیبانی می‌کند، عملیاتی را تعریف کنید که فراخوان‌ها بتوانند به آن‌ها متکی باشند، بدون آنکه جزئیات پیاده‌سازی آشکار شود. برای نمونه، CODESYS بلوک‌های تابع شیءگرا را با متدها، رابط‌ها، ویژگی‌ها، وراثت و فراخوانی متدهای مجازی در مرجع رسمی برنامه‌نویسی شیءگرا خود مستند کرده است. این قابلیت واقعی است، اما نباید آن را به هر محیط PLC تعمیم داد.
یک رابط می‌تواند به پیاده‌سازی‌های مختلف موتور اجازه دهد فرمان‌ها و وضعیت مشترکی ارائه کنند. یک راه‌انداز ساده، درایو فرکانس متغیر و سروو ممکن است همگی از فعال‌سازی، توقف، بازنشانی، حالت، آماده‌به‌کار، در حال کار و اطلاعات خطا پشتیبانی کنند، در حالی که تشخیص‌های داخلی متفاوتی دارند. در این صورت، توالی فراخوانی به قرارداد وابسته است، نه به تک‌تک پارامترهای اختصاصی فروشنده.
برای ماشین‌ها و اسکیدها، ترکیب را ترجیح دهید
بیشتر تجهیزات صنعتی ذاتاً ترکیبی هستند. یک پکیج پمپ شامل موتور، شیرهای ایزوله، مجوزها، اندازه‌گیری‌های آنالوگ و منطق توالی است. یک سیستم مخزن شامل ابزارهای سطح، شیرها، پمپ‌ها، هشدارها و حالت‌های عملیاتی است. این واحدهای بزرگ‌تر را با دربرگرفتن مؤلفه‌های کوچک‌تر و آزموده‌شده بسازید، نه با مشتق کردن هر تجهیز از یک کلاس پایهٔ جهانی.
ترکیب، مالکیت را آشکار نگه می‌دارد. توالی پمپ ممکن است موتور و شیرهای خود را فرمان دهد، اما مؤلفهٔ موتور همچنان مالک بازخورد راه‌انداز، زمان‌انتظار شروع و وضعیت‌های خطای اختصاصی موتور است. مؤلفهٔ آنالوگ، اعتبار سیگنال و مقیاس‌بندی را بر عهده دارد. واحد، آن‌ها را هماهنگ می‌کند و وضعیت خلاصه‌ای را به منطق سطوح بالاتر گزارش می‌دهد.
ترکیب، سلسله‌مراتب تجهیزات را بازتاب می‌دهد و در عین حال به هر مؤلفهٔ موتور، شیر و ابزار اجازه می‌دهد تشخیص‌های خود را حفظ کند.
یک مدل وضعیت صریح طراحی کنید
یک مؤلفه باید وضعیت عملیاتی خود را قابل مشاهده کند. منطق صرفاً بولی فرمان اغلب ترکیب‌های ناممکنی مانند در حال کار و متوقف، خودکار و دستی، یا سالم و خراب را هم‌زمان ایجاد می‌کند. یک مدل وضعیت شمارشی می‌تواند وضعیت‌های بیکار، در حال راه‌اندازی، در حال کار، در حال توقف، خطادار و تعمیرات را با انتقال‌های مشخص بیان کند.
هر انتقال به شرایط ورود، شواهد تکمیل، رفتار زمان‌انتظار و قوانین لغو نیاز دارد. فرمان‌ها باید درخواست باشند، نه انتساب مستقیم به وضعیت. بازنشانی باید فقط زمانی خطای قفل‌شده را پاک کند که شرایط زیربنایی اجازه دهد. حالت دستی باید مشخص کند کدام حفاظت‌ها همچنان فعال می‌مانند و چه کسی مالک خروجی است.
پیکربندی را از وضعیت زمان اجرا جدا نگه دارید
پیکربندی شامل حدود زمانی، بازه‌های مهندسی، آستانه‌های هشدار، گزینه‌های تجهیز و فعال‌سازی قابلیت‌هاست. وضعیت زمان اجرا شامل انباشتگرهای تایمر، حالت فعلی، مالکیت فرمان، سابقهٔ خطا و وضعیت انتقال است. جداسازی این دو، بازبینی تغییرات و حاکمیت دستورالعمل‌ها را شفاف‌تر می‌کند.
هر تنظیمی نباید از HMI قابل‌نوشتن باشد. بررسی محدوده، مجوزهای نقش‌ها، ثبت تغییرات و زمان فعال شدن مقدار جدید را تعریف کنید. داده‌های ماندگار نیز به سیاستی صریح نیاز دارند. مؤلفه‌ای که پس از قطع برق از سر گرفته می‌شود نباید صرفاً به این دلیل که همهٔ متغیرهای داخلی ماندگار تعریف شده‌اند، فرمان ناایمنی را بازیابی کند.
پیش از افزایش تعداد نمونه‌ها، مؤلفه‌ها را آزمایش کنید
مزیت استفادهٔ مجدد فقط زمانی آشکار می‌شود که تعریف مورد اعتماد باشد. یک بستر آزمون بسازید که بازخورد عادی، بازخورد تأخیردار، ورودی‌های متناقض، قطع ارتباط، کیفیت نامناسب آنالوگ، تغییر حالت، تلاش‌های بازنشانی، راه‌اندازی و مرزهای زمان‌انتظار را اعمال کند. خروجی‌ها، هشدارها و انتقال‌های وضعیت را برای هر حالت تأیید کنید.
سپس چند نمونه را آزمایش کنید تا خطاهای وضعیت مشترک آشکار شوند. تأثیر زمان اسکن و حافظه را در مقیاس واقعی بررسی کنید. یک فراخوانی مختصر در سطح بالا به این معنا نیست که پیاده‌سازی از نظر محاسباتی رایگان است. ویرایش‌های آنلاین، ارتقای کتابخانه و مهاجرت داده‌های نمونه باید پیش از استقرار روی کنترلر هدف تمرین شوند.
تغییرات و نسخه‌بندی کتابخانه را کنترل کنید
یک مؤلفهٔ قابل‌استفادهٔ مجدد می‌تواند یک اصلاح را در مقیاس گسترده منتشر کند، اما ممکن است یک نقص را نیز در همان مقیاس گسترش دهد. برای هر نوع منتشرشده، نسخه، رابط مستندشده، سابقهٔ آزمون و تاریخچهٔ تغییرات تعیین کنید. تغییرات را سازگار یا ناسازگار طبقه‌بندی کنید. معنا و مفهوم هشدار، زمان‌بندی پیش‌فرض، رفتار خروجی یا ساختار دادهٔ ماندگار را در یک تعریف تثبیت‌شده بی‌سر و صدا تغییر ندهید.
پروژه‌ها باید ثبت کنند کدام نسخه‌های کتابخانه کامپایل و دانلود شده‌اند. اگر پلتفرم نسخه‌هایی از کد منبع را در خود جای می‌دهد، مشخص کنید به‌روزرسانی‌های تأییدشده چگونه مقایسه و وارد می‌شوند. اگر به یک کتابخانهٔ مدیریت‌شده ارجاع می‌دهد، برای دسترس‌پذیری و بازگشت به نسخهٔ قبلی برنامه‌ریزی کنید. گرافیک‌های اپراتوری و فیس‌پلیت‌ها باید هم‌زمان با رابط کنترل تکامل یابند و فرض نکنند نام اعضای قدیمی همیشه معتبر می‌ماند.
تشخیص‌ها را با لایهٔ اپراتوری یکپارچه کنید
یک مؤلفهٔ مفید گزارش می‌دهد چرا نمی‌تواند عمل کند: نبود مجوز، ناهماهنگی بازخورد، پایان زمان‌انتظار انتقال، مالکیت محلی، پیکربندی نامعتبر، کیفیت نامناسب ورودی یا فعال بودن عملکرد ایمنی. HMI باید این وضعیت ساختاریافته را به پیامی قابل‌اقدام تبدیل کند، بدون آنکه اختیار کنترلر را دور بزند. سخت‌افزار مناسب اپراتور را می‌توان در بخش HMI و رایانش صنعتی یافت، اما قرارداد تشخیصی از کد کنترل آغاز می‌شود.
دیدگاه مهندسی
برنامه‌نویسی شیءگرای PLC بیش از همه به‌عنوان روشی برای ایجاد رابط‌های شفاف، وضعیت کپسوله‌شده، ترکیب، آزمون و استفادهٔ مجدد کنترل‌شده ارزشمند است. وراثت کامل و چندریختی می‌توانند در پلتفرم‌هایی که آن‌ها را پیاده‌سازی کرده‌اند مفید باشند، اما شرط آغاز کار نیستند. با یک نوع تجهیز محدود شروع کنید، رفتار خرابی آن را اثبات کنید، رابطش را مستند سازید و فقط پس از اطمینان از استحکام شواهد آزمون، مقیاس دهید. نتیجه باید راه‌اندازی و عیب‌یابی را برای مهندس بعدی آسان‌تر کند، نه اینکه صرفاً کد منبع را پیچیده‌تر و پیشرفته‌تر نشان دهد.