تحديث واجهات HMI لنظام Bailey INFI 90 Symphony العاملة على OpenVMS Alpha
دليل عملي لاستبدال محطات تشغيل Bailey Symphony القديمة التي تعمل على OpenVMS Alpha. يقارن بين محاكاة Alpha، وترحيل OpenVMS إلى x86، وإعادة اعتماد OPC على منصة جديدة، والتحديث التدريجي لأنظمة ABB.
تحديث واجهة HMI دون استبدال نظام INFI 90 بأكمله
تواصل العديد من أنظمة Bailey INFI 90 العمل بموثوقية بعد مرور عقود على تركيبها الأصلي. وقد تظل وحدات التحكم، ووحدات الاتصال، ووحدات الإنهاء، ووحدات الإدخال والإخراج الميدانية فيها تؤدي وظائف التحكم المطلوبة.
غالبًا ما تكمن مشكلة دورة الحياة الأكثر إلحاحًا فوق طبقة وحدات التحكم.
قد تعتمد محطات المشغّلين على أجهزة AlphaStation قديمة، ومهايئات رسومات غير مدعومة، وأجهزة تخزين متقادمة، وبيئات برامج OpenVMS Alpha قديمة. ويصبح الحصول على قطع الغيار أمرًا صعبًا، في حين يقل توافر المهندسين ذوي الخبرة في OpenVMS وBailey Symphony.
يتضمن المثال المدروس هنا أربع محطات عمل AlphaStation 255. وتشغّل كل محطة OpenVMS Alpha وتستضيف وظائف واجهة المشغّل لنظام Bailey Symphony للتحكم الموزع Bailey INFI 90.
ليس الهدف بالضرورة استبدال نظام DCS بأكمله. فالهدف العملي أكثر هو إزالة الاعتماد على أجهزة AlphaStation القديمة مع الحفاظ على وحدات التحكم المستقرة، وأسلاك التوصيل الميدانية، ووحدات الإدخال والإخراج، ومنطق التحكم، وعمليات التشغيل.
ويغيّر هذا التمييز استراتيجية التحديث.
المشروع هو في الأساس عملية ترحيل لواجهة المشغّل ومنصة الحوسبة. ولا يصبح ترحيلًا كاملًا لنظام DCS إلا عندما تبرر دورة حياة وحدات التحكم، أو متطلبات الأمن السيبراني، أو أهداف الإنتاج، أو ظروف الدعم استبدال طبقات التحكم الأدنى.
توجد عدة مسارات ممكنة للتحديث. لكنها تحافظ على أجزاء مختلفة من النظام القائم.
يمكن لمحاكي Alpha الحفاظ على بيئة البرامج شبه الكاملة. وتحافظ عملية ترحيل OpenVMS إلى x86 على عائلة نظام التشغيل، لكنها تتطلب ترحيل التطبيقات. أما استبدال واجهة HMI القائم على OPC فيحافظ على طبقة وحدات التحكم مع إعادة بناء واجهة المشغّل. ويمكن لاستراتيجية التطوير لدى ABB تحديث بنية Symphony الأوسع على مراحل.
لا ينبغي وصف أي مسار بأنه مجرد استبدال للحاسوب الشخصي.
الشكل 1. يمكن لثلاثة مسارات رئيسية للتحديث الحفاظ على أجزاء مختلفة من الاستثمار القائم في Bailey INFI 90 وSymphony.
لماذا لا يكفي استنساخ قرص AlphaStation
يفيد استنساخ القرص في الحفاظ على بيئة OpenVMS Alpha المثبتة. إذ يمكنه التقاط نظام التشغيل، وملفات التطبيقات، وتكوين الأجهزة، وحسابات المستخدمين، وبرامج Bailey، وقواعد البيانات، والرسومات، والإعدادات الخاصة بالموقع.
ومع ذلك، لا يحوّل استنساخ القرص برامج Alpha إلى برامج x86.
لا يزال نظام التشغيل المستنسخ يحتوي على تعليمات خاصة بمعالجات Alpha. وقد صُمِّمت نواته، ومحمل الإقلاع، ومكتبات النظام، والتطبيقات، وبرامج تشغيل الأجهزة لبنية Alpha.
يستخدم الحاسوب الشخصي الحديث العادي معالج x86-64. كما يعرض وحدات تحكم تخزين، وأجهزة شبكة، وبُنى مقاطعات، وأجهزة رسوميات، وواجهات برامج ثابتة، وناقلات أجهزة طرفية مختلفة.
تعمل VMware وVirtualBox وHyper-V وبرامج مراقبة الأجهزة الافتراضية التقليدية الخاصة بـ x86 على محاكاة أجهزة متوافقة مع x86. لكنها لا تترجم عادةً تعليمات معالج Alpha إلى تعليمات x86.
ولذلك، فإن وضع صورة قرص OpenVMS Alpha داخل آلة افتراضية عادية تعمل بنظام x86 لا يجعل تلك الصورة قابلة للإقلاع.
قد توفر الآلة الافتراضية قرصًا افتراضيًا، ومهايئ شبكة افتراضيًا، وجهاز رسوميات افتراضيًا. لكن OpenVMS Alpha يظل يتوقع معالج Alpha وأجهزة مدعومة من حقبة Alpha.
ولهذا يجب إبقاء المفهومين منفصلين:
وعادةً ما تعرض المحاكاة الافتراضية أجهزة افتراضية باستخدام بنية المعالج نفسها التي يستخدمها المضيف.
تُعيد المحاكاة عبر البنى إنتاج معالج وبيئة أجهزة أخرى برمجيًا.
يتطلب OpenVMS Alpha النهج الثاني عندما يجب أن تظل ملفات Alpha الثنائية الأصلية ونظام التشغيل دون تغيير.
ولذلك يكون استنساخ الأقراص ممكنًا في ثلاث حالات محدودة.
أما الخيار الأول فهو الاسترداد على طراز AlphaStation نفسه باستخدام وحدات تخزين وأجهزة طرفية متوافقة.
أما الخيار الثاني فهو الاسترداد على نظام Alpha آخر مدعوم بعد إكمال تغييرات الأجهزة والتكوين المطلوبة.
أما الخيار الثالث فهو الاستعادة داخل محاكي Alpha يعيد إنتاج بيئة متوافقة مع AlphaServer أو AlphaStation.
لا يحل الاستنساخ وحده مشكلة البنية. فما زال يتعين على البيئة المستهدفة فهم تعليمات آلة Alpha وتنفيذها.
تحافظ محاكاة Alpha على الجزء الأكبر من الاستثمار الحالي
عادةً ما تكون محاكاة Alpha المسار الأقل إحداثًا للتغييرات عندما يلزم أن تظل برامج Symphony الحالية قيد التشغيل من دون تغييرات في الشفرة المصدرية.
يعمل محاكي Alpha على أجهزة x86 حديثة، لكنه يعرض لنظام OpenVMS نظام Alpha افتراضيًا. ويواصل نظام التشغيل والتطبيقات الأصليان رؤية بيئة أجهزة متوافقة مع Alpha.
صُممت منتجات مثل CHARON-AXP لهذا الغرض. إذ يستبدل المحاكي معالج Alpha الفعلي، وبنية الذاكرة، ووحدات التحكم بالتخزين، ومهايئات Ethernet، والأجهزة الأخرى المدعومة، بنظائر محددة برمجيًا.
يعمل خادم x86 بنظام Windows أو Linux بوصفه بيئة المضيف. ويعمل محاكي Alpha فوق ذلك المضيف. ثم يعمل OpenVMS Alpha داخل نظام Alpha المُحاكى.
يختلف هذا النهج عن نقل OpenVMS إلى x86.
يبقى تثبيت OpenVMS Alpha الأصلي تثبيتًا لـ Alpha. وتبقى ملفات Bailey Symphony الثنائية ملفات ثنائية لـ Alpha. ويترجم المحاكي سلوك أجهزة Alpha المطلوب أو يعيد إنتاجه.
يمكن لهذا الحفاظ على:
• نظام التشغيل OpenVMS Alpha المثبّت.
• تطبيقات Bailey Symphony الحالية.
• رسومات المشغّلين وقواعد بيانات العرض.
• تهيئات الإنذارات والملفات التاريخية.
• حسابات المستخدمين وإجراءات الأوامر.
• الأدوات الحالية الخاصة بالموقع.
• واجهات التطبيق التي تعتمد على بيئة Alpha.
• إجراءات عمل المشغّلين التي كانت ستتطلب، لولا ذلك، إعادة تدريب.
تتضمن عملية الترحيل العملية عادةً إنشاء صورة أو نسخة احتياطية موثّقة لأقراص Alpha الأصلية. وتُستعاد تلك البيانات إلى حاويات أقراص افتراضية يستخدمها المحاكي.
يجب أن يعيد تكوين المحاكي إنتاج خصائص مناسبة للمعالج والذاكرة والقرص والشبكة والأجهزة الطرفية. وقد يحتاج الفريق أيضًا إلى ربط المنافذ التسلسلية أو واجهات الشبكة المادية عبر النظام المضيف.
يمكن لمحاكاة Alpha أن تقلل بدرجة كبيرة من الاعتماد على الأجهزة المادية المتقادمة. كما يمكنها تبسيط النسخ الاحتياطي، لأن ملفات الأقراص الافتراضية يمكن نسخها باستخدام بنية التخزين الحديثة.
ومع ذلك، ينبغي استخدام مصطلح «صفر تغييرات» بحذر.
قد تظل شيفرة التطبيق دون تغيير، لكن البيئة لا تزال تتطلب هندسة. يجب التحقق من تعيينات الأجهزة. كما يجب تكوين واجهات الشبكة. وينبغي مراجعة تراخيص OpenVMS وتراخيص التطبيق.
ويجب أيضًا اختبار المحاكي باستخدام واجهة اتصالات Bailey المستخدمة في الموقع.
قد يعمل تطبيق OpenVMS عام بشكل صحيح، بينما تتعطل واجهة DCS متخصصة لأنها تعتمد على محوّل شبكة معيّن أو واجهة ناقل أو جهاز تسلسلي أو سلوك توقيت محدد.
لذلك يجب جرد إعداد AlphaStation 255 الدقيق قبل اختيار ملف تعريف المحاكي.
واجهة اتصالات Bailey هي الاختبار الحاسم للمحاكاة
لا يتمثل أهم سؤال في محاكاة Alpha في ما إذا كان OpenVMS يصل إلى موجه تسجيل الدخول.
السؤال المهم هو ما إذا كانت المحطة المُحاكاة تتصل بشكل صحيح بنظام Bailey INFI 90 في ظل ظروف التشغيل الكاملة.
قد تعتمد الواجهة على Ethernet أو الاتصال التسلسلي أو واجهة شبكة Bailey أو أجهزة اتصال متخصصة. ويمكن أن تختلف إعدادات المواقع اختلافًا كبيرًا.
قبل الالتزام بمحاكاة Alpha، ينبغي على المهندسين توثيق ما يلي:
• واجهة الشبكة المادية المثبّتة في كل AlphaStation.
• بروتوكول الاتصال المستخدم بين Symphony وINFI 90.
• أسماء الأجهزة المعيّنة داخل OpenVMS.
• عناوين الشبكة وتعريفات العقد.
• خدمات DECnet أو TCP/IP أو LAT أو الخدمات المملوكة المطلوبة.
• إعدادات المنافذ التسلسلية، حيثما ينطبق ذلك.
• أي مفاتيح ترخيص خارجية أو وحدات حماية مادية.
• سلوك التكرار والتبديل عند التعطل بين محطات المشغّلين.
• متطلبات مزامنة الوقت.
• وظائف الرسومات ولوحة المفاتيح التي يستخدمها المشغّلون.
قد يدعم مورّد المحاكي أجهزة Alpha الشائعة الخاصة بشبكات Ethernet والتخزين. لكن ذلك لا يؤكد تلقائيًا دعم كل واجهة Bailey مملوكة.
إذا كانت واجهة HMI الحالية تعتمد على محوّل مادي متخصص لا يمكن تحويله إلى محاكاة افتراضية، فقد يتطلب مسار المحاكي بوابة اتصال بديلة.
ولذلك ينبغي أن يتضمن المشروع اختبارًا على منصة تجريبية باستخدام محطة مستنسخة وإمكانية الوصول إلى شبكة Bailey تمثيلية.
ويجب ألا يقتصر الاختبار على قراءة الوسوم الثابتة. ينبغي للمشغّلين التحقق من القيم الآنية، والأوامر، والإنذارات، والإقرار بها، والاتجاهات، والتنقل بين شاشات العرض، والطباعة، ومعالجة الأحداث، واستعادة المحطة.
ينبغي أيضًا اختبار الأداء أثناء اندفاعات الإنذارات وارتفاع معدل تحديث الوسوم.
OpenVMS x86-64 هو مسار مختلف للترحيل
يتوفر OpenVMS الحديث لبنية x86-64. ويمكنه العمل في بيئات افتراضية مدعومة على خوادم حديثة.
وهذا يوفّر خيارًا إضافيًا للترحيل لم يكن متاحًا خلال كثير من المناقشات السابقة حول تحديث INFI 90.
ومع ذلك، لا يشغّل OpenVMS x86-64 ثنائيات OpenVMS Alpha مباشرةً كما لو كانت تطبيقات x86 أصلية.
يجب ترحيل بيئة التطبيق.
قد يلزم نقل الشيفرة المصدرية ومراجعتها وإعادة ترجمتها وربطها واختبارها لـ x86-64. كما يجب أن تتوفر مكتبات الجهات الخارجية والمنتجات الإضافية لإصدار النظام المستهدف.
السؤال الأساسي هو ما إذا كان برنامج Bailey Symphony المثبت يملك إصدارًا من OpenVMS متوافقًا مع x86.
إذا لم يُصدر مورّد البرنامج هذا التطبيق مطلقًا لـ OpenVMS x86-64، فإن نقل نظام التشغيل وحده لا يحافظ على واجهة HMI.
قد تكون البرامج المطوّرة في الموقع قابلة للنقل عندما تظل شيفرتها المصدرية وبيئة بنائها متاحتين. أما التطبيقات التجارية المغلقة فلا يمكن عادةً إعادة بنائها من دون دعم المورّد.
قد يظل هذا المسار عمليًا لخوادم البيانات المخصصة، والمؤرشفات، والأدوات المساعدة، والتقارير، وتطبيقات التكامل التي تعمل إلى جانب واجهة HMI الخاصة بـ Symphony.
تقل احتمالية الحفاظ على بيئة المشغّل القديمة المملوكة Symphony من دون إصدار مدعوم من التطبيق.
ينبغي أن يحدد تقييم ترحيل OpenVMS إلى x86 ما يلي:
• كل ملف تنفيذي مثبت وكل منتج إضافي.
• الشيفرة المصدرية المتاحة وإجراءات البناء.
• الاعتماديات على المترجم وبيئة التشغيل.
• منتجات قواعد البيانات وتنسيقات الملفات.
• مكتبات الاتصال المملوكة.
• الاعتماديات على الرسومات أو نظام النوافذ.
• توافر التراخيص لـ x86-64.
• التغييرات المطلوبة بسبب اختلافات البنية.
• افتراضات الأداء والتوقيت.
يتمتع هذا المسار بإمكانات طويلة الأجل أقوى من الانتقال من Alpha إلى بنية عتاد أخرى أُوقِفَت. ويمكنه نقل أعباء عمل OpenVMS المتوافقة إلى بنية تحتية مدعومة للمحاكاة الافتراضية على x86.
ومع ذلك، ينبغي وصفه بأنه مشروع لترحيل التطبيقات، وليس مشروعًا لاستنساخ الأقراص.
لماذا يُعد ترحيل Itanium عادةً خيارًا انتقاليًا
كما أُصدر OpenVMS لخوادم HPE Integrity التي تستخدم بنية Itanium.
تتوفر أدوات للترحيل وأساليب هندسية لنقل بعض تطبيقات Alpha إلى OpenVMS Integrity. وقد وفّر هذا المسار سابقًا خيارًا مدعومًا للابتعاد عن عتاد Alpha المتقادم.
ومع ذلك، فإن عتاد Itanium نفسه أصبح الآن منصة قديمة.
قد يزيل الانتقال من Alpha إلى Integrity تبعية واحدة لأجهزة قديمة، لكنه ينشئ تبعية أخرى. وستصبح الخوادم وقطع الغيار وواجهات التخزين والخبرات المتخصصة الملائمة أقل توافرًا بمرور الوقت.
قد يظل Itanium مناسبًا عندما يمتلك الموقع بالفعل بنية Integrity أساسية مدعومة. وقد يكون مناسبًا أيضًا عندما يتوفر منتج طبقي مطلوب لـ Integrity ولا يتوفر لـ x86-64.
وبالنسبة إلى مشروع تحديث جديد، ينبغي عمومًا تقييمه باعتباره مسار توافق وسيطًا.
يجب أن يوضح مبرر المشروع لماذا يُفضَّل الانتقال إلى Integrity على محاكاة Alpha أو ترحيل OpenVMS إلى x86 أو إعادة بناء منصة HMI.
إعادة بناء المنصة عبر OPC تحافظ على طبقة التحكم
تعيد إعادة بناء المنصة عبر OPC طبقة واجهة المشغّل، مع الإبقاء على وحدات التحكم INFI 90 ووحدات الإدخال/الإخراج الميدانية الحالية.
يربط خادم اتصالات نظام Bailey ويتيح علامات العمليات لمنصة HMI أو SCADA حديثة.
تتولى HMI الجديدة إدارة الشاشات والإنذارات والاتجاهات والأمان وأوامر المشغّلين والتقارير وخدمات محطات العمل.
يلغي هذا المسار الاعتماد على تطبيق المشغّل الأصلي Symphony. كما يتجنب الحاجة إلى تشغيل OpenVMS Alpha على محطات المشغّلين الجديدة.
تتضمن البنية عادةً:
• وحدات التحكم ووحدات الإدخال/الإخراج الحالية من Bailey INFI 90.
• واجهة اتصال متوافقة مع Bailey.
• خادم بيانات OPC DA أو OPC UA أو خادم خاص بالمورّد.
• منصة HMI أو SCADA حديثة.
• محطات عمل المشغّلين والمهندسين.
• خدمات اختيارية للتأريخ وإعداد التقارير وتحليل الإنذارات.
استخدم مثال ميداني ورد في المادة المصدرية خادم RoviSys OPC مع GE CIMPLICITY. وقد عمل النظام المُبلّغ عنه بنجاح، لكن المشروع تطلّب إعادة إنشاء شاشات المشغّل ومنطق الحركة.
ينبغي ألا يُفسَّر هذا المثال على أنه توصية تلقائية بمنتج لكل عملية تركيب لنظام INFI 90.
يجب أن يدعم الخادم المحدد شبكة Bailey ووحدات الاتصال والجيل المحدد من وحدات التحكم وعدد العلامات ومعدل التحديث ومتطلبات التكرار ووظائف الأوامر الخاصة بالموقع.
وينطبق الأمر نفسه على منصة HMI.
يُعد GE CIMPLICITY إحدى منصات HMI/SCADA المؤسسية الممكنة. وقد تكون أنظمة أخرى صالحة أيضًا عندما توفّر اتصال OPC المطلوب، والرسومات، والإنذارات، والبرمجة النصية، والتكرار، والأمان، ودعم دورة الحياة.
الشكل 2. تحافظ عملية الترحيل المستندة إلى OPC على طبقة التحكم INFI 90، مع استبدال بيئة المشغّل القديمة Symphony.
اتصال OPC لا يحوّل الشاشات الحالية
يوفّر خادم OPC اتصالًا بالبيانات. ولا يحوّل عادةً شاشات HMI القديمة إلى تنسيق HMI جديد.
قد تحتوي شاشات Symphony الأصلية على رسومات ثابتة، ورموز ديناميكية، وتغييرات في الألوان، وقيم رقمية، ورسوم بيانية شريطية، ومؤشرات إنذار، وأزرار تنقّل، وعناصر تحكم بالأوامر، واتجاهات، وقوالب وظائف مخصصة.
يجب إعادة إنشاء هذه العناصر في واجهة المستخدم والآلة المستهدفة.
يمكن إعادة رسم الشاشات البسيطة مباشرةً. وقد تحتوي الشاشات المعقدة على نصوص أو تعبيرات مخفية لا تظهر فورًا.
يجب على المهندسين فهم كيفية حصول كل كائن متحرك على بياناته ومعالجته لها.
قد لا يتبع رمز الصمام وسم خرج واحدًا ببساطة. فقد يعتمد لونه وموضعه على تغذية راجعة تفيد بالفتح، وتغذية راجعة تفيد بالإغلاق، وحالة الأمر، وحالة التعشيق، وجودة الاتصال، ووضع المعدات.
قد يستخدم رمز المحرك وسومًا منفصلة لأمر التشغيل، وتغذية راجعة تفيد بالتشغيل، وحالة التوقف، والفصل الوقائي، والتحكم المحلي، وحالة الصيانة، وشروط السماح، وحجب الإنذار.
لذلك فإن نقل الرسومات المرئية فقط قد ينشئ واجهة مستخدم وآلة تبدو صحيحة، لكنها تعمل بصورة غير صحيحة.
يجب على فريق الترحيل توثيق المعنى الوظيفي الكامن وراء كل عنصر من عناصر الشاشة.
يشمل هذا العمل:
• ربط كل كائن ديناميكي بمصدر بياناته.
• إعادة إنشاء تعبيرات الحركة.
• التحقق من تأكيد الأوامر وأمانها.
• إعادة بناء هياكل التنقل والعرض.
• إعادة إنشاء فئات الإنذارات وأولوياتها.
• تأكيد وحدات القياس الهندسية ودقة المنازل العشرية.
• إعادة بناء الاتجاهات التاريخية والآنية.
• اختبار حالات الاتصال غير الصالحة وغير المؤكدة والفاشلة.
• إعادة إنتاج رسائل المشغل وإرشاداته.
• استبدال الخطوط والرموز غير المدعومة.
لذلك يتحدد الجهد بتعقيد الشاشة، وليس بعدد الشاشات فقط.
ينبغي ألا تنسخ واجهة المستخدم والآلة الحديثة كل شاشة قديمة بصورة عمياء
تتيح إعادة الإنشاء اليدوية فرصة لتحسين واجهة المشغل.
غالبًا ما تستخدم رسومات واجهة المستخدم والآلة القديمة ألوانًا زاهية للمعدات العادية، ومخططات عمليات كثيفة، وأنابيب زخرفية، وإشارات إنذار غير متسقة.
قد تكون هذه الاصطلاحات معقولة عند تطوير النظام الأصلي. لكنها ليست دائمًا مثالية لممارسات غرف التحكم الحالية.
ينبغي أن يراجع مشروع التحديث:
• تسلسل عرض المعلومات.
• وضوح الإنذارات.
• اتساق التنقل.
• عرض حالة المعدات.
• استخدام الألوان.
• سهولة الوصول إلى الاتجاهات.
• متطلبات استجابة المشغل.
• دقة الشاشة وتخطيط محطة العمل.
• إمكانية الوصول وقابلية القراءة.
ينبغي أن تظل ظروف التشغيل العادية هادئة بصريًا. وينبغي أن تحدد الألوان القوية الحالات غير الطبيعية التي تتطلب الانتباه.
ينبغي أن يتمكن المشغلون من الانتقال من نظرة عامة على المصنع إلى الوحدة المتأثرة، وواجهة المعدات، والاتجاه، وسجل الإنذارات، وشاشة التشخيص دون تنقل مفرط.
ومع ذلك، قد تؤدي إعادة التصميم المفرطة إلى خلق خطر آخر.
قد يكون المشغلون قد استخدموا الشاشات الأصلية لسنوات عديدة. وقد يؤدي تغيير كل رمز ولون ومسار تنقل ضمن المشروع نفسه إلى زيادة متطلبات التدريب ومخاطر التحويل.
يحتفظ النهج المتوازن بعلاقات العمليات المألوفة، مع تحسين عرض الإنذارات والتنقل.
يجب التعامل مع استخراج الوسوم على أنه حزمة عمل هندسية
يثير المصدر احتمال تصدير بيانات وسوم Bailey إلى CSV، لكنه لا يقدّم إجراءً عالميًا مؤكدًا.
ولذلك، لا ينبغي افتراض أن أمر تصدير واحدًا سينتج قاعدة بيانات HMI كاملة ونظيفة.
تشمل المصادر المحتملة لمعلومات الوسوم ما يلي:
• قواعد بيانات تهيئة Symphony.
• تعريفات الشاشات الحالية.
• سجلات تهيئة وحدات التحكم والهندسة.
• قواعد بيانات خادم اتصالات Bailey.
• وظائف تصفح خادم OPC.
• ملفات تهيئة الإنذارات.
• قواعد البيانات التاريخية.
• قوائم الوسوم المطبوعة أو المؤرشفة.
• جداول البيانات الهندسية للموقع.
يمكن أن يوفر تصفح OPC نقطة بداية عملية بعد أن ينشئ الخادم اتصالًا بنظام Bailey.
فقد تكشف أسماء الوسوم، ومعرّفات العناصر، والأوصاف، والجودة، والقيم الحالية. كما تدعم بعض الخوادم تصدير مساحة الأسماء التي تم تصفحها.
ومع ذلك، قد لا تتضمن مساحة أسماء OPC كل الحقول اللازمة لواجهة HMI الجديدة.
قد تكون أولويات الإنذارات، والحدود الهندسية، وتجميعات العرض، وملاحظات المشغّلين، وأمان الأوامر، وعلاقات المعدات مخزّنة في أماكن أخرى.
تكشف بعض خوادم OPC الوسوم باستخدام أسماء مُولّدة تختلف عن أسماء Symphony الأصلية.
ينبغي للمشروع إنشاء سجل رئيسي مضبوط للوسوم يتضمن على الأقل:
• اسم الوسم الأصلي.
• اسم وسم HMI الجديد.
• معرّف عنصر OPC.
• الوصف.
• نوع البيانات.
• صلاحية القراءة أو الكتابة.
• وحدات القياس الهندسية.
• معلومات القياس.
• حدود الإنذار وأولويته.
• معدل التحديث.
• الشاشة المرتبطة.
• حالة التحقق.
• نتيجة الاختبار.
سيصبح هذا السجل الرئيسي سجل التسوية بين النظامين القديم والجديد.
عدد الوسوم ليس متطلب الاتصال الوحيد
لا يثبت نجاح اختبار التصفح أن بنية OPC قادرة على دعم واجهة HMI الكاملة.
يجب على المهندسين تقييم عدد الوسوم النشطة، ومعدل التحديث المطلوب، وتكرار التغييرات، ونشاط الإنذارات، وحركة الأوامر، وتكرار الخوادم.
قد يحتوي النظام على عشرات الآلاف من الوسوم المُهيّأة. وقد يكون جزء منها فقط نشطًا على شاشات المشغّلين في وقت واحد.
ينبغي اختبار الخادم وواجهة HMI في ظل ظروف واقعية.
تشمل فحوصات الأداء المهمة ما يلي:
• الوقت المطلوب لفتح شاشة معقدة.
• التأخير بين حدوث تغيير ميداني وظهوره في حركة واجهة HMI.
• تسليم الإنذارات أثناء تدفقات الأحداث الكثيفة.
• جمع الاتجاهات بمعدل أخذ العينات المطلوب.
• زمن تنفيذ الأمر والتغذية الراجعة.
• الاسترداد بعد انقطاع الشبكة.
• التحويل بين الخوادم المتكررة.
• السلوك بعد إعادة تشغيل وحدة التحكم.
• حالة الجودة أثناء فشل الاتصال.
• تحميل وحدة المعالجة المركزية والذاكرة والشبكة.
تتطلب الأوامر عناية خاصة.
قد تكون قراءة القيم عبر OPC بسيطة نسبيًا. أما كتابة القيم بأمان فتتطلب التحكم في الوصول، والتحقق من الأوامر، وتأكيد التغذية الراجعة، والتعامل الصحيح مع أعطال الاتصال.
ينبغي للفريق اختبار كل نوع من أوامر المشغّل، وليس وسمًا تمثيليًا واحدًا فقط.
توفّر ABB Symphony Plus مسارًا أوسع للتطور
استبدال OPC ليس المسار الوحيد لنظام Bailey مثبّت.
تواصل ABB تقديم Symphony Plus بوصفه منصة تطورية لتركيبات Bailey وINFI 90 وHarmony Rack وSymphony الأقدم.
قد يحافظ تحديث ABB المرحلي على أجزاء من بنية التحكم والإدخال/الإخراج المثبّتة، مع إدخال مكوّنات أحدث للمشغّلين أو الهندسة أو الشبكات أو وحدات التحكم أو الإدخال/الإخراج.
يمكن أن يكون هذا المسار جذابًا عندما ترغب المؤسسة في استراتيجية لدورة حياة مدعومة من المورّد بدلًا من استبدال HMI مستقل.
قد يحدّث المشروع بيئة المشغّل أولًا. ويمكن أن تظل وحدات التحكم ووحدات الإدخال/الإخراج قيد الخدمة إلى أن تبرر دورة حياتها أو قيمتها التشغيلية استبدالها.
يمكن أن تتناول المراحل اللاحقة الاتصالات، ووحدات التحكم، وأدوات الهندسة، وواجهات الحقل.
تعتمد بنية الترحيل الدقيقة على جيل النظام المثبّت.
لا تستخدم تركيبات Bailey INFI 90 وINFI 90 OPEN وNetwork 90 وHarmony وSymphony وSymphony Plus الواجهات نفسها جميعًا.
يجب التحقق من أسماء الوحدات ومصطلحات الشبكة من مخططات الموقع وقوائم جرد الأجهزة.
يمكن للمؤسسات التي تحافظ على طبقة التحكم الحالية أيضًا مراجعة مكوّنات ABB Bailey INFI 90 وNetwork 90 المتاحة عند التخطيط لتغطية قطع الغيار، ودعم دورة الحياة، والتحديث المرحلي.
هذا الرابط الداخلي ذو صلة لأن مشاريع التحديث غالبًا ما تتطلب بقاء النظام القديم قيد التشغيل أثناء الهندسة والاختبار والتحول المرحلي.
يمكن أن يؤدي الحفاظ على وحدات تحكم احتياطية مناسبة، ووحدات اتصالات، ومزوّدات طاقة، ووحدات إدخال/إخراج إلى تقليل المخاطر أثناء ذلك الانتقال.
نظام HMI مخصص أو مفتوح المصدر ممكن، لكنه يتطلب تحمّل المسؤولية
يمكن تطوير نظام HMI مخصص باستخدام أطر برمجية مفتوحة المصدر أو تجارية.
تذكر المواد المصدرية خادمًا مقيمًا على VMS مع عميل حديث قائم على Qt. ويمكن لبنى من هذا النوع فصل اتصال البيانات من جانب الخادم عن عميل المشغّل.
يمكن أن يوفر هذا المسار مرونةً وتجنب الاعتماد على مورّد واحد لأنظمة HMI.
وقد يتحول ذلك أيضًا إلى التزام طويل الأمد بتطوير البرمجيات.
يجب أن تمتلك المؤسسة ما يلي أو تتولى صيانته:
• خادم الاتصالات.
• قاعدة بيانات الوسوم.
• تطبيق العميل.
• إطار الرسومات.
• معالجة الإنذارات.
• التكامل مع المؤرشف.
• مصادقة المستخدمين.
• تحديثات الأمن السيبراني.
• النشر والتحكم في الإصدارات.
• التوثيق والتدريب.
يمكن لـ Qt وPython وC++ وتقنيات الويب أو أطر العمل الأخرى إنتاج واجهات صناعية قادرة. ولا تكمن الصعوبة في رسم مخطط للعملية.
تكمن الصعوبة في إنشاء نظام تشغيل موثوق يتصرف بصورة صحيحة أثناء أعطال الاتصالات، وإعادة تشغيل الخوادم، وتدفّق الإنذارات، وتغييرات المستخدمين، وظروف المصنع غير الطبيعية.
ينبغي اختيار منصة مخصصة فقط عندما تكون لدى المؤسسة جهة هندسية مستدامة أو مُكامل موثوق على المدى الطويل.
يمكن أن يحدد الترخيص ما إذا كان المسار التقني عمليًا
غالبًا ما تستخدم البرامج الصناعية القديمة آليات ترخيص مرتبطة بمعرّفات الأجهزة أو عناوين Ethernet أو قواعد بيانات التراخيص أو مفاتيح الحماية أو مفاتيح التفويض الصادرة عن المورّد.
قد يقلع النظام المستنسخ بصورة صحيحة، لكنه يرفض بدء تشغيل تطبيق Symphony لأن هوية العتاد الافتراضي قد تغيرت.
ينبغي أن تتضمن جردة الترحيل ما يلي:
• تراخيص نظام التشغيل OpenVMS.
• تراخيص تطبيق Bailey Symphony.
• تراخيص قواعد البيانات.
• تراخيص الشبكات والاتصالات.
• تراخيص المحاكي.
• تراخيص عدد نقاط HMI وOPC.
• تراخيص المؤرشف.
• خيارات التكرار.
• تراخيص العملاء الهندسيين.
• تراخيص عملاء وقت التشغيل.
ينبغي الحصول على تأكيد خطي قبل اختيار المنصة النهائية.
التوافق التقني، من دون توافر التراخيص القانونية، لا ينتج حلًا قابلًا للنشر.
يجب تصميم الأمن السيبراني ضمن عملية الاستبدال
غالبًا ما ثُبّتت أنظمة AlphaStation القديمة قبل أن تصبح ممارسات الأمن السيبراني الصناعي الحديثة معيارًا.
قد تعمل هذه الأنظمة على شبكات معزولة مع وصول محدود عن بُعد. واستبدالها بخوادم Windows وعملاء SCADA حديثين وخوادم OPC وبنية تحتية قائمة على Ethernet يغيّر سطح الهجوم.
ينبغي أن تحدد البنية الجديدة مناطق منفصلة لشبكات التحكم والخوادم والهندسة والمؤسسة.
ينبغي ألا تسمح جدران الحماية إلا بمسارات الاتصال المطلوبة. وينبغي أن يستخدم الوصول عن بُعد مصادقة مُدارة وتسجيلًا للجلسات.
ينبغي أن تتبع حسابات المشغلين أذونات قائمة على الأدوار. ويجب ألا تكون وظائف الهندسة متاحة من كل عميل HMI.
ينبغي تقييد صلاحية الكتابة في OPC على الوسوم والمحطات التي تتطلبها فقط.
ينبغي أن يعالج التصميم أيضًا ما يلي:
• تصحيح نظام التشغيل.
• مكافحة الفيروسات أو التحكم في التطبيقات.
• النسخ الاحتياطي والاسترداد.
• مزامنة الوقت.
• تسجيل أحداث الأمان.
• ضوابط الوسائط القابلة للإزالة.
• الدعم عن بُعد من المورّد.
• إدارة شهادات OPC UA.
• إدارة دورة حياة الحسابات.
يجب ألا تمنع ضوابط الأمن السيبراني المشغلين من الاستجابة أثناء أحداث المصنع. وينبغي أن يوازن التصميم بين الحماية والتوافر والتشغيل الحتمي.
يجب أن تبدأ عملية الترحيل بجردة مستندة إلى الأدلة
قبل اختيار مسار، ينبغي للمهندسين توثيق النظام الحالي بالتفصيل.
يجب أن تتضمن الجردة محطات AlphaStation الأربع جميعها، وأن تحدد ما إذا كانت تكويناتها متطابقة حقًا.
سجّل:
• طراز AlphaStation وتكوين المعالج.
• سعة الذاكرة.
• نوع الأقراص ووحدات التخزين المنطقية.
• إصدار OpenVMS ومستوى التصحيحات.
• إصدارات برنامج Bailey المثبتة.
• المنتجات وقواعد البيانات متعددة الطبقات.
• أجهزة الرسومات ودقة العرض.
• محولات الشبكة.
• الواجهات التسلسلية.
• أجهزة اتصالات Bailey.
• أسماء العقد وعناوينها.
• إجراءات أوامر بدء التشغيل.
• ملفات التراخيص.
• إجراءات النسخ الاحتياطي.
• التكرار في محطات التشغيل.
• الطابعات المتصلة والأجهزة الخارجية.
• الاحتفاظ بالبيانات التاريخية وبيانات الإنذارات.
ينبغي للفريق أيضًا جمع لقطات شاشة لكل عرض. وينبغي التقاط الحالات الديناميكية كلما أمكن.
سجّل حالات التشغيل العادي، والتوقف، والتشغيل، والإنذار، والمنع، والمحلي، واليدوي، والتلقائي، وفشل الاتصالات.
هذه الأدلة ضرورية عند اختبار الشاشات الجديدة.
وجود نظام منصة اختبار إلزامي
لا ينبغي اختبار أي مسار تحديث للمرة الأولى على نظام الإنتاج المباشر.
ينبغي لبيئة منصة الاختبار أن تعيد إنتاج قدر كافٍ من البنية المثبتة للتحقق من الاتصالات ووظائف المشغل.
بالنسبة إلى مشروع محاكاة، ينبغي أن تتضمن المنصة بيئة OpenVMS Alpha مستنسخة وتكوين المحاكي المقترح.
بالنسبة إلى مشروع OPC، ينبغي أن تتضمن منصة الاختبار خادم الاتصالات المحدد، وبرنامج HMI، ورسومات تمثيلية، وإمكانية الوصول إلى عقدة اختبار آمنة لنظام Bailey أو مصدر بيانات محاكى.
ينبغي أن يتحقق اختبار منصة الاختبار من:
• إقلاع النظام وبدء تشغيل التطبيق.
• الاتصال بنظام Bailey.
• إجمالي عدد الوسوم التي يمكن الوصول إليها.
• عمليات القراءة والكتابة.
• تحجيم الوسوم ووحدات القياس الهندسية.
• إنشاء الإنذارات والإقرار بها.
• جمع الاتجاهات.
• حركة العرض.
• أمان الأوامر.
• وظائف الطابعة والتقارير.
• سلوك النظام عند إعادة تشغيل الخادم.
• سلوك النظام عند فشل الشبكة.
• التكرار والتحويل عند التعطل.
• استعادة النسخ الاحتياطية.
• زمن استجابة المشغل.
ينبغي أن يشهد ممثلو التشغيل وهندسة التحكم والصيانة والأمن السيبراني نتائج الاختبار.
التشغيل المتوازي يقلل مخاطر التحويل
ينبغي أن تظل محطات AlphaStation الأصلية متاحة أثناء النشر الأولي للنظام البديل.
يمكن لواجهة HMI الجديدة أن تعمل بالتوازي بينما يقارن المهندسون القيم والإنذارات والاتجاهات والأوامر.
يتيح التشغيل المتوازي تحديد حالات عدم التطابق قبل إزالة المحطة القديمة.
ينبغي للفريق مطابقة ما يلي:
• قيم العملية المعروضة.
• مؤشرات الحالة.
• أولويات الإنذارات.
• الطوابع الزمنية للإنذارات.
• نتائج الأوامر.
• قيم الاتجاهات.
• وضع المعدات.
• جودة الاتصالات.
• أذونات الأمان.
لا يمثل كل اختلاف خطأً. فقد يستخدم النظام الجديد تحجيمًا محسّنًا أو عرضًا محسّنًا للإنذارات.
ومع ذلك، ينبغي تفسير كل اختلاف والموافقة عليه.
ينبغي أن تظل المحطات القديمة قابلة للاسترداد إلى أن تجتاز واجهة HMI الجديدة اختبار قبول الموقع بحضور الشهود، وإلى أن تنقضي فترة تشغيل متفق عليها.
اختيار مسار الترحيل الصحيح
اختر محاكاة Alpha عندما:
يجب أن يظل تطبيق Symphony الحالي دون تغيير. الكود المصدري غير متاح. الرسومات التشغيلية معقدة. ويجب تقليل إعادة التدريب إلى أدنى حد. ويمكن دعم واجهة اتصال Bailey من خلال بنية المحاكي.
اختر ترحيل OpenVMS إلى x86 عندما:
التطبيقات المطلوبة متاحة لإصدار x86-64 أو يمكن إعادة بنائها. يظل الكود المصدري والمعرفة الهندسية متاحين. وترغب المؤسسة في الاحتفاظ بـ OpenVMS مع الانتقال إلى بيئة x86 مدعومة.
اختر إعادة بناء المنصة باستخدام OPC عندما:
تظل وحدة تحكم INFI 90 وطبقات الإدخال والإخراج موثوقة. وترغب المؤسسة في منصة HMI حديثة. وتتوافر الموارد الهندسية لإعادة إنشاء الشاشات والإنذارات والوسوم ومنطق الأوامر والتحقق منها.
اختر مسار التطور من ABB عندما:
ترغب المؤسسة في برنامج تحديث أوسع تدعمه جهة مورّدة. وقد تشمل المراحل المستقبلية أنظمة المشغلين وأدوات الهندسة وواجهات الشبكة ووحدات التحكم ووحدات الإدخال والإخراج.
اختر HMI مخصصًا عندما:
تكون لدى المؤسسة متطلبات متخصصة، وتستطيع دعم تطوير البرمجيات والاختبار والأمن السيبراني وصيانة دورة الحياة على المدى الطويل.
احتفظ بالنظام الحالي مؤقتًا عندما:
لا تزال واجهات الترحيل غير واضحة. والنسخ الاحتياطية غير مكتملة. والترخيص لم يُحسم. وقواعد بيانات الوسوم غير متاحة. ولا يمكن لاختبارات منصة الاختبار حتى الآن إعادة إنتاج مسار اتصال Bailey.
خطة عملية للتحديث على مراحل
المرحلة 1: حافظ على البيئة الحالية.
أنشئ نسخًا احتياطية موثّقة للصور لكل جهاز AlphaStation. وسجّل تفاصيل العتاد والبرمجيات والشبكة والترخيص وبدء التشغيل. واختبر الاستعادة كلما أمكن.
المرحلة 2: حدّد بنية الاتصالات.
وثّق بدقة كيفية اتصال كل محطة Symphony مع INFI 90. وتحقق مما إذا كان يمكن محاكاة الواجهة أو استبدالها بخادم مدعوم.
المرحلة 3: أنشئ إثبات مفهوم.
اختبر محطة مستنسخة واحدة على محاكي Alpha، أو صِل خادم OPC واحدًا بعقدة Bailey تمثيلية.
المرحلة 4: أنشئ السجل الرئيسي للوسوم.
طابق وسوم وحدات التحكم، ومعرّفات عناصر OPC، ووحدات القياس الهندسية، والأوامر، والإنذارات، واستخدامات العرض.
المرحلة 5: أعد إنشاء شاشات تمثيلية.
اختر عدة شاشات تتضمن متطلبات مختلفة للرسوم المتحركة والإنذارات والأوامر والاتجاهات.
المرحلة 6: أكمل قبول الاختبار على منصة الاختبار.
اختبر تحميل جميع الوسوم، وفشل الاتصال، وإعادة تشغيل الخادم، وتدفقات الإنذارات، وسلوك الأوامر، واستعادة النسخ الاحتياطية.
المرحلة 7: انشر النظامين بالتوازي.
شغّل واجهتي HMI الجديدة والقديمة معًا. قارن القيم واستجابات المشغلين.
المرحلة 8: نفّذ التحويل بحضور الشهود.
استخدم إجراء اختبار معتمدًا. أبقِ أجهزة AlphaStation متاحة كخيار احتياطي.
المرحلة 9: أخرج العتاد القديم من الخدمة تدريجيًا.
لا تتخلص من الصور الأصلية أو سجلات التهيئة أو التراخيص أو العتاد حتى يكتمل القبول طويل الأمد.
الأسئلة الشائعة
هل يمكن استنساخ قرص OpenVMS AlphaStation مباشرةً إلى حاسوب حديث؟
لا. تحتوي الصورة على تعليمات آلة Alpha وتتطلب عتادًا متوافقًا مع Alpha. لا يمكن لحاسوب x86 حديث إقلاعها مباشرةً. يجب استعادة الصورة على عتاد Alpha متوافق أو على محاكي Alpha.
هل يمكن لـ VMware أو VirtualBox تشغيل OpenVMS؟
يمكنها تشغيل إصدارات OpenVMS x86-64 المدعومة. لكنها لا تحوّل تثبيت OpenVMS Alpha قديمًا إلى تطبيق x86. يتطلب OpenVMS Alpha محاكاة Alpha.
هل يمكن الحفاظ على شاشات Symphony الأصلية؟
يمكن عادةً الحفاظ عليها عندما تعمل بيئة Alpha الكاملة ضمن محاكي متوافق. أما عند الانتقال إلى منصة HMI أخرى، فعادةً ما تتطلب إعادة إنشائها يدويًا.
هل يُصدّر خادم OPC تلقائيًا كل وسم من وسوم Bailey؟
ليس بالضرورة. قد يوفر تصفح OPC مساحة أسماء مفيدة، لكن قد يتطلب تكوين الإنذارات، وعلاقات الشاشات، والأوامر، والأوصاف، والبيانات الوصفية الهندسية استخراجًا وتسويةً إضافيين.
هل تُعد GE CIMPLICITY واجهة HMI البديلة الوحيدة؟
لا. إنها منصة ممكنة، وقد وردت في المثال الميداني المقدم مع المصدر. وينبغي أن يعتمد الاختيار النهائي على دعم الاتصالات، والتكرار، والتراخيص، والأمن السيبراني، وموارد الهندسة، ومتطلبات المشغّلين.
هل لا يزال الترحيل من Alpha إلى Itanium مجديًا؟
قد يكون ذلك مبررًا عندما لا يتوفر البرنامج المطلوب إلا لأنظمة Integrity، أو عندما تكون البنية التحتية الحالية لـ Integrity مدعومة بالفعل. لكنه عمومًا مسار انتقالي وليس استراتيجية التحديث الأقوى على المدى الطويل.
هل يمكن الإبقاء على وحدات التحكم وأجهزة الإدخال/الإخراج INFI 90 مركّبة؟
نعم، عندما تظل موثوقة وتدعم بنية الاتصال المختارة ذلك. ويمكن إكمال تحديث واجهة HMI بشكل منفصل عن استبدال وحدات التحكم ووحدات الإدخال/الإخراج.
هل ينبغي إزالة أجهزة AlphaStation القديمة فورًا بعد التحويل؟
لا. ينبغي أن تظل متاحة كخيار احتياطي مُختبَر إلى أن تجتاز بيئة المشغّل الجديدة اختبارات القبول الوظيفي والأدائي والتشغيلي.
يعتمد الحل الصحيح على ما يجب الحفاظ عليه
الخطأ التقني الرئيسي في كثير من خطط واجهات HMI القديمة هو التعامل مع محطة المشغّل باعتبارها حاسوبًا شخصيًا عاديًا.
إن جهاز AlphaStation الذي يشغّل OpenVMS Alpha وBailey Symphony هو بيئة متكاملة من العتاد والبرمجيات. وترتبط بنيته المعالجية، ونظام تشغيله، وواجهات اتصاله، وثنائيات تطبيقاته، وتراخيصه، ورسوماته، واتصالاته بنظام التحكم، بعضها ببعض.
تحافظ استنساخة القرص على البيانات، لكنها لا تترجم تلك البيئة إلى بنية أخرى.
توفر محاكاة Alpha المسار الأكثر مباشرة عندما يجب أن يستمر تثبيت Symphony بالكامل دون تغيير.
يوفر OpenVMS x86-64 مسارًا لنظام تشغيل حديث عندما يمكن ترحيل التطبيقات أو إعادة بنائها.
توفر إعادة بناء منصة OPC مسارًا عمليًا عندما تظل طبقة التحكم INFI 90 ذات قيمة، لكن ينبغي استبدال طبقة المشغّل.
يمكن لتطور ABB Symphony Plus أن يوفر استراتيجية مرحلية أوسع عندما ترغب المؤسسة في التحديث بما يتجاوز واجهة HMI.
ينبغي أن يستند القرار النهائي إلى جرد مُتحقَّق منه، ودراسة لواجهات الاتصال، ومراجعة التراخيص، وإثبات مفهوم، واختبار على منصة اختبار، وقبول تشغيلي بحضور الشهود.
لا يوجد استبدال بلا جهد. ومع ذلك، توجد عدة مسارات مُدارة للترحيل يمكنها حماية الاستثمار الحالي في التحكم بالعمليات مع إزالة الاعتماد على أجهزة AlphaStation المتقادمة.