أنا منخرط في تطوير وتنفيذ وتشغيل أنظمة التحكم التلقائي في العمليات (ACS TP). في البداية ، كان يعمل مع أنظمة سكادا. ثم تحول بسرعة إلى العمل مع البروتوكولات لتبادل الأجهزة الصناعية. برامج تشغيل ذاتية الكتابة وإعداد أنظمة جمع البيانات. في الوقت الحالي ، يمر عملي بجو Modbus-s و IEC-101/104-s و OPC والبروتوكولات الأخرى.
شكل 1. مجموعة متنوعة من بروتوكولات الاتصال المستخدمة في أنظمة التحكم الصناعيةباختصار حول كيفية عمل نظام نموذجي لجمع البيانات (بسيط بعض الشيء).
شكل 2. نظام الحصول على البياناتبرنامج خاص يسمى خادم استطلاعات OPC للأجهزة المتصلة بواجهة RS-485. خادم OPC هو نوع من الطبقة بين نظام SCADA والأجهزة ، مما يترجم اللغة التي تتواصل بها الأجهزة إلى لغة مفهومة لنظام SCADA. يُستخدم محول Ethernet / RS-485 لتحويل حزم TCP / IP إلى حزم تنتقل عبر البيئة المادية لـ RS-485.
هذا المخطط له العديد من العيوب:
- عيّن ، على سبيل المثال ، في خادم OPC مهلة لانتظار استجابة 200 مللي ثانية. في الحالة المثالية ، عندما تذهب الحزم إلى Ethernet دون تأخير ، يكون التواصل مع الأجهزة بسرعة جيدة (شدة). ولكن إذا تأخرت الحزمة التي تحتوي على الاستجابة ، على سبيل المثال ، بمقدار 300 مللي ثانية (هذا أكثر من مهلة الاستجابة البالغة 200 مللي ثانية) ، فإن خادم OPC يعتبر أن استجابة الطلب لم تصل وترسل الطلب التالي. في هذا الوقت ، تصل إجابة الطلب السابق ، لكن خادم OPC يعتقد أن هذا هو الرد على الطلب الحالي ويرسل البيانات الخاطئة إلى الأعلى. نتيجة لذلك ، فإن البيانات الموجودة على محطة العمل "القفز". للابتعاد عن مثل هذه الحالات ، سنضع مهلة أكثر. خذ بهامش 3000 مللي ثانية. إذا وصلت الإجابة قبل 3000 مللي ثانية ، فلا ننتظر الوقت المتبقي ، ننتقل إلى الطلب التالي. حتى الآن ، كل شيء يسير على ما يرام ، ولكن بمجرد توقف العديد من الأجهزة عن الاستجابة ، هناك تأخير قدره 3000 مللي ثانية لكل جهاز. وقت الاقتراع يتزايد.
- تعتمد معظم البروتوكولات المستخدمة في أنظمة التحكم في العمليات (Modbus ، عدادات الكهرباء) على الاستقصاء المتسلسل لنفس المعلمات. بالنظر إلى أن قيم المعلمات تبقى في معظم الوقت دون تغيير ، يتم استخدام شبكة البيانات لنقلها. هذا غير عقلاني إذا كانت وسيلة الإرسال هي GPRS ، وتكلفة المرور تكلف مالاً. بالإضافة إلى ذلك ، في وسيط إرسال GPRS ، يمكن أن تصل تأخيرات الرزم إلى عدة ثوان. لماذا تضيع الوقت والموارد في نقل الشيء نفسه؟
بالنسبة للحالات المذكورة أعلاه ، يكون البروتوكول أكثر ملاءمة حيث يتم إرسال البيانات إلى الأعلى عن طريق التغيير (بشكل متقطع) ويتم تجميعها حسب عدة قيم في حزمة TCP واحدة. هذه البروتوكولات هي IEC-60870-5-104 و OPC UA. يعد ModBus-TCP مناسبًا أيضًا ، ولا يوجد فيه تغيير في الإرسال ، ولكن إذا لم يكن هناك الكثير من البيانات ، فيمكن تعبئته في حزمة واحدة. سيكون من الجيد أن يكون لديك نوع من وحدات التحكم التي يمكن تعليقها على سكة DIN ، وتوصيل الأجهزة بها عبر RS-485 ونقل البيانات عبر الإيثرنت إلى نظام SCADA.
بشكل عام ، هناك بعض بوابات الأجهزة بأعداد كبيرة. ولكن في شكل حلول غير قابلة للتجزئة جاهزة. الكل في واحد. وأنا لا أحب ذلك حقًا. كنت بحاجة إلى بوابة لتحويل بروتوكولات SET-4TM إلى OPC UA مع ستة منافذ RS-485 واثنين من الإيثرنت. لدى إحدى الشركات المصنّعة بوابة تدعم بروتوكولات التبادل الضرورية ، ولكن يوجد عدد قليل من منافذ RS-485 ، والآخر لديه العدد الصحيح من منافذ RS-485 ، لكن لا يوجد منفذين Ethernet. الثالث لديه اثنين من منافذ إيثرنت ، ولكن ليس كل بروتوكولات الاتصال. يحتوي الرابع على كل شيء تقريبًا ، ولكن لا يوجد OPC UA ، وهو متاح على متن IEC-60870-5-104 أو ModBus-TCP يتطلب خادم OPC لهذه البروتوكولات.
وكم سيكون رائعًا: شراء جهاز تحكم أو كمبيوتر شخصي صغير يعمل بنظام التشغيل من مصنع واحد. شراء برنامج للتحكم من آخر. إذا كانت إحدى الشركات المصنعة للبرنامج لا تدعم شيئًا ما ، فقم بشراء أحد البرامج من جهاز آخر ، وقم بدمج مكونات البرنامج من خلال واجهة البرنامج القياسية. يبدو أنه هنا مستقبل مشرق!
هذا هو السبب في استخدام بوابات البروتوكول بشكل متكرر أقل من خادم OPC وحزمة محول Ethernet إلى RS-485 بسبب عدم قابليتها للتجزئة في المكونات.
أحد الأسباب وراء تخلف SCADA لنظام التشغيل Linux: SCADA متاح ، وعدد قليل من بروتوكولات التبادل مدعومة فيه ، ولا توجد خوادم OPC للاتصال بالمعدات. SCADA يترك متكامل واحد على واحد مع الأجهزة.
قد يطرح القارئ بالفعل سؤالًا: ماذا يمكنك أن تقدم؟ ما هو بالفعل هناك؟ هناك خوادم OPC UA لنظام Linux للبروتوكولات التالية:
من أجل نقل البيانات إلى المستوى العلوي ليس فقط من خلال بروتوكول OPC UA ، تم إنشاء "
OPC UA إلى Modbus Converter و IEC 60870-5-104 ". بالإضافة إلى وظيفة نقل البيانات لهذه البروتوكولات ، يحتوي "المحول" على خادم ويب مضمن. باستخدام محرر خاص ، يمكنك رسم رسم تخطيطي ، وعرض قيم العلامات عليه ، ثم فتحه في مستعرض. اتضح مصغرة SCADA مباشرة في وحدة تحكم. كيف تعمل الرسوم المتحركة للدائرة ، كتبت بالفعل
هنا ، حول المحرر
هنا . في المستقبل ، تم تصميم "OPC UA to MQTT Converter".
تعمل خوادم ومحولات OPC UA على أبنية x64 و ARMv7 و AARCH64.
وبالتالي ، بالنسبة للجهاز ، يمكنك استخدام كل من الحلول التي تم اختبارها وفقًا للوقت استنادًا إلى أجهزة الكمبيوتر الصناعية الصغيرة ، وجميع أنواع أجهزة الكمبيوتر المصغرة ARM "التوتية المتوافقة مع التوت". يمكن قراءة كيفية تثبيت البرنامج وتكوينه مع أمثلة
هنا أو
هنا .
بشكل عام ، تبدو بنية المجمع كما يلي:
النظام قابل للتطوير. يتم استخدام المكونات الضرورية فقط لحل المشكلة الحالية.
باستخدام خادم OPC UA ، تم تحويل مخططنا:
لدينا ما يلي:
- يقوم خادم OPC UA بجمع البيانات من الأجهزة عبر RS-485 دون تأخير كبير بين الطلبات ؛
- يتم إصدار البيانات في SCADA في عدة قطع في حزمة TCP واحدة للتغيير ؛
- يمكنك توصيل العديد من محطات العمل المكونة بشكل متساوٍ بخادم OPC UA. مفيد إذا كان هناك حاجة إلى الازدواجية.
وبالتالي ، بدلاً من حزمة خادم OPC و "Ethernet to RS-485 Converter" ، نحصل على جهاز واحد يجمع بين وظائفها. أنا أحب هذا المخطط أكثر. ماذا عنك