در این مقاله از سری آموزش‌های تخصصی System Function Block یا SFB در PLC زیمنس در الکترونت، وارد بخشی می‌شویم که SFBها از ابزارهای ساده کنترلی فراتر رفته و مستقیماً با Sequence Control، مدیریت Alarm، Event، ثبت و انتقال داده‌های فرآیندی و ارتباط PLC با سیستم‌های مانیتورینگ درگیر می‌شوند.

این بخش برای پروژه‌های کوچک PLC صرفاً یک آموزش نرم‌افزاری نیست؛ در پروژه‌های EPC نفت، گاز و پتروشیمی، انتخاب و پیاده‌سازی صحیح این قابلیت‌ها می‌تواند روی کیفیت FAT، SAT، Commissioning، Alarm Management، Historian و قابلیت نگهداری سیستم کنترل اثر مستقیم داشته باشد.

در این قسمت سه SFB مهم بررسی می‌شوند:

·  SFB32 – DRUM

· SFB35 – ALARM_8P

· SFB37 – AR_SEND

نکته مهم: شماره و قابلیت SFBها به خانواده CPU و نسخه Firmware/STEP7 وابسته است. بنابراین در پروژه واقعی، قبل از طراحی باید Instruction List و مستندات همان CPU بررسی شود. برای نمونه، مستندات S7-400 زیمنس SFB32 را به‌عنوان Sequencer، SFB35 را ALARM_8P و SFB37 را AR_SEND معرفی می‌کنند. Siemens Industry Support

معرفی: SFB32 – DRUM

SFB32 چیست؟

SFB32 – DRUM یکی از System Function Blockهای خانواده S7-400 است که برای پیاده‌سازی Sequencer یا کنترل توالی مراحل استفاده می‌شود.

زیمنس در Instruction List مربوط به S7-400، عملکرد SFB32 را به‌صورت Implement Sequencer معرفی کرده است. Siemens Industry Support

مفهوم Sequencer در صنعت بسیار مهم است. بسیاری از فرآیندهای صنعتی فقط یک شرط ساده مانند:

Start → Motor ON نیستند.

بلکه فرآیند از چند مرحله تشکیل شده است:

START

   ↓

PREPARATION

   ↓

FILLING

   ↓

HEATING

   ↓

PROCESS

   ↓

COOLING

   ↓

DRAINING

   ↓

COMPLETE

در چنین شرایطی PLC باید بداند:

·  اکنون در کدام مرحله هستیم؟

·  مرحله بعدی چیست؟

· شرط عبور به مرحله بعد چیست؟

· اگر شرط برقرار نشد چه اتفاقی بیفتد؟

· اگر Alarm ایجاد شد Sequence متوقف شود یا ادامه پیدا کند؟

· در صورت Restart سیستم از کدام مرحله شروع شود؟

اینجاست که مفهوم Sequence Control اهمیت پیدا می‌کند.

SFB32 در پروژه‌های نفت و گاز چه کاربردی دارد؟

در صنایع فرآیندی، تعداد زیادی از عملیات به‌صورت مرحله‌ای انجام می‌شوند.

برای مثال:

راه‌اندازی یک سیستم پمپ

ممکن است Sequence به این صورت باشد:

Step 1

بررسی Permissiveها

 ↓

Step 2

باز شدن شیر Suction

↓

Step 3

دریافت Valve Open Feedback

 ↓

Step 4

Start Pump

↓

Step 5

بررسی Motor Running

↓

 Step 6

افزایش تدریجی دبی

↓

Step 7

قرار گرفتن سیستم در Auto

بنابراین Sequence فقط یک Timer نیست؛ بلکه مجموعه‌ای از Step + Transition + Condition + Action است.

مثال عملی SFB32 در واحد فرآیندی

فرض کنید یک سیستم شست‌وشوی تجهیزات یا CIP Sequence داریم.

فرآیند باید به ترتیب زیر اجرا شود:

Step 1

باز کردن شیر آب

Step 2

بررسی Flow

Step 3

فعال کردن پمپ

Step 4

تزریق ماده شیمیایی

Step 5

Circulation

Step 6

Drain

Step 7

پایان سیکل

اگر Flow در Step 2 برقرار نشود، سیستم نباید وارد Step 3 شود.

پس:

Step 2

   ↓

Flow OK?

   ↓ YES

Step 3

اما:

Flow OK?

   ↓ NO

Alarm

   ↓

Sequence Hold

این همان نوع تفکری است که در طراحی سیستم‌های کنترل پروژه‌های EPC باید وجود داشته باشد.

SFB32 و کنترل فرآیندهای چندمرحله‌ای

کاربرد DRUM محدود به یک صنعت خاص نیست.

در پروژه‌های نفت و گاز می‌توان منطق‌های مرحله‌ای برای مواردی مانند:

·  Start-up

·  Shutdown

·  Purging

·  Flushing

·  Draining

· Filling

·  Heating

·  Cooling

· Regeneration

· Backwash

· Batch Processing

طراحی کرد.

در نیروگاه نیز فرآیندهایی مانند:

·  راه‌اندازی تجهیزات

· Sequence مربوط به Boiler

·  سیستم‌های Auxiliary

· Cooling Sequence

· Fuel System Sequence

ماهیت مرحله‌ای دارند.

نکته مهم طراحی SFB32

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

در پروژه‌های EPC بهتر است Sequence از منطق تجهیز تفکیک شود.

برای مثال:

SEQUENCE

   ↓

Equipment Commands

   ↓

FB_PUMP

FB_VALVE

FB_DAMPER

FB_FAN

در این معماری، Sequence تصمیم می‌گیرد چه کاری باید انجام شود و FB تجهیز مسئول اجرای صحیح فرمان تجهیز است.

این تفکیک باعث می‌شود:

· تست ساده‌تر شود.

· Commissioning سریع‌تر شود.

· تغییرات پروژه راحت‌تر اعمال شود.

· Revamp کم‌ریسک‌تر باشد.

·  عیب‌یابی ساده‌تر شود.

معرفی : SFB35 – ALARM_8P

SFB35 چیست؟

SFB35 – ALARM_8P یکی از مهم‌ترین SFBهای مرتبط با Alarm و Event در خانواده S7-400 است.

زیمنس در Instruction List، SFB35 را برای ایجاد Block-related Message با Associated Value برای هشت Signal معرفی می‌کند. Siemens Industry Support

این نکته مهم است:

SFB35 فقط یک بیت Alarm ساده نیست.

می‌تواند بخشی از معماری حرفه‌ای Alarm & Event Management پروژه باشد.

چرا Alarm Management برای پروژه‌های نفت و گاز مهم است؟

در یک واحد پتروشیمی ممکن است هزاران Tag وجود داشته باشد.

اما همه تغییرات وضعیت نباید با اهمیت یکسان به اپراتور نمایش داده شوند.

مثلاً:

Critical

Emergency Shutdown

High

High High Pressure

Medium

Pump Trip

Low

Maintenance Required

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

SFB35 و WinCC

یکی از کاربردهای مهم SFB35 در معماری‌های S7-400، ایجاد پیام‌هایی است که توسط سیستم‌های بالادستی مانند WinCC/SCADA دریافت و نمایش داده می‌شوند.

در یک نمونه مستند زیمنس، SFB35 برای ایجاد Alarm و Event در S7-400 بررسی شده و نمونه فراخوانی آن نیز ارائه شده است. این مستند همچنین اشاره می‌کند که SFB35 در S7-400 در دسترس است و می‌تواند به‌صورت Cyclic در OB1 یا بسته به کاربرد در OB35 و سایر OBها فراخوانی شود. Siemens Industry

این موضوع برای پروژه‌های صنعتی بسیار مهم است.

چرا؟

زیرا طراحی Alarm فقط مسئله PLC نیست.

معماری واقعی می‌تواند چنین باشد:

Field Instrument

      ↓

PLC

      ↓

SFB35

      ↓

Alarm/Event

      ↓

WinCC / SCADA

      ↓

Operator

مثال عملی SFB35 در پالایشگاه

فرض کنید Pressure یک خط فرآیندی از مقدار مجاز عبور کند.

سیگنال:

PT-101

   ↓

Pressure High

   ↓

Alarm Logic

   ↓

SFB35

   ↓

WinCC

اپراتور در سیستم مانیتورینگ می‌تواند پیام مربوط به تجهیز و وضعیت Alarm را مشاهده کند.

اما طراحی حرفه‌ای باید مشخص کند:

· Alarm چه زمانی فعال شود؟

· چه زمانی Reset شود؟

·  آیا نیاز به Acknowledge دارد؟

·  Priority چیست؟

· Message Class چیست؟

· آیا Alarm در Historian ذخیره شود؟

· در صورت Communication Failure چه اتفاقی می‌افتد؟

مثال پتروشیمی؛ High Temperature

فرض کنید دمای Reactor به حد Alarm رسیده است.

به‌جای پیام ساده:

HIGH TEMPERATURE

می‌توان پیام را به تجهیز و مقدار مربوط کرد.

مثلاً:

Reactor R-101

HIGH TEMPERATURE

PV = 186 °C

LIMIT = 180 °C

در نتیجه سیستم مانیتورینگ اطلاعات کاربردی‌تری در اختیار Operator قرار می‌دهد.

SFB35 در پروژه‌های نیروگاهی

در نیروگاه نیز Alarmها بخش مهمی از سیستم کنترل هستند.

برای مثال:

Boiler

   ↓

High Pressure

   ↓

Alarm

   ↓

SFB35

   ↓

WinCC

یا:

Pump

   ↓

Motor Overload

   ↓

Alarm

   ↓

SFB35

   ↓

HMI / SCADA

در سیستم‌های بزرگ، کیفیت Alarm Management مستقیماً روی قابلیت تصمیم‌گیری اپراتور تأثیر می‌گذارد.

معرفی : SFB37 – AR_SEND

SFB37 چیست؟

SFB37 – AR_SEND یک SFB مرتبط با ارسال داده‌های فرآیندی است.

در مستندات S7-400، SFB37 با نام AR_SEND فهرست شده است و در معماری‌های S7-400H نیز در کنار قابلیت‌های Message و Process Control ذکر شده است.Siemens Industry

کاربرد اصلی آن در سناریوهایی است که داده‌های فرآیندی باید از PLC به سیستم بالادستی منتقل شوند.

این موضوع در پروژه‌هایی که حجم زیادی از داده باید برای:

·  Archiving

· Monitoring

· Historian

· Data Acquisition

·Process Analysis

منتقل شود اهمیت پیدا می‌کند.

چرا انتقال داده در پروژه‌های نفت و گاز مهم است؟

در یک واحد فرآیندی، داده‌های ارزشمند زیادی تولید می‌شود:

·  Pressure

· Temperature

· Flow

· Level

· Valve Position

· Motor Current

· Speed

· Controller Output

·  Alarm Status

·  Equipment Status

اگر معماری انتقال داده صحیح نباشد، داده‌ها ممکن است:

·  ناقص باشند.

·  با Timestamp نامناسب منتقل شوند.

·  حجم زیادی از Communication Load ایجاد کنند.

· برای تحلیل فرآیند مناسب نباشند.

بنابراین Data Architecture باید از ابتدای پروژه مشخص شود.

مثال عملی SFB37 در واحد گاز

فرض کنید یک Compressor Train داریم.

پارامترهای مهم:

Suction Pressure

Discharge Pressure

Temperature

Flow

Speed

Vibration

Valve Position

PLC این داده‌ها را دریافت می‌کند.

سپس بخشی از داده‌های مورد نیاز برای سیستم بالادستی ارسال می‌شود.

Compressor

      ↓

S7-400

      ↓

Process Data

      ↓

AR_SEND

      ↓

Supervisory System

      ↓

Historian

این داده‌ها می‌توانند برای تحلیل عملکرد Compressor و بررسی روند فرآیند مورد استفاده قرار گیرند.

مثال نیروگاهی

فرض کنید Turbine دارای مجموعه‌ای از پارامترهای مهم است:

·  Speed

· Steam Pressure

· Steam Temperature

·  Load

·  Bearing Temperature

· Exhaust Pressure

در چنین سیستمی ثبت روند این پارامترها برای:

·  Performance Analysis

·  Maintenance

· Troubleshooting

·  Commissioning

· Performance Test

ارزش زیادی دارد.

اشتباهات رایج در پروژه‌های صنعتی

1. استفاده از SFB بدون بررسی CPU

شماره و قابلیت SFB را نباید صرفاً بر اساس یک پروژه قدیمی کپی کرد.

ابتدا باید CPU و نسخه STEP7/Firmware بررسی شود.

مستندات Instruction List همان CPU مرجع اصلی هستند. برای نمونه، در مستندات S7-400 V7.0، SFB32، SFB35 و SFB37 در فهرست System Function Blocks آمده‌اند.

2. طراحی Alarm بدون Alarm Philosophy

وجود SFB35 به معنی داشتن یک سیستم Alarm استاندارد نیست.

Alarm باید با Philosophy پروژه هماهنگ باشد.

3. قرار دادن تمام Sequence در OB1

OB1 نباید به یک برنامه عظیم و غیرقابل نگهداری تبدیل شود.

Sequence، Equipment Control و Alarm Management باید معماری مشخص داشته باشند.

4. ارسال بدون برنامه‌ریزی داده

در پروژه‌های بزرگ باید مشخص شود چه داده‌ای:

·  چرا؟

· به کجا؟

·  با چه دوره‌ای؟

· با چه اولویتی؟

·برای چه مدت؟

· با چه ساختاری؟

منتقل می‌شود.

نکات طراحی برای پروژه‌های نفت، گاز و پتروشیمی

برای پروژه‌های EPC پیشنهاد می‌شود پیش از شروع برنامه‌نویسی، موارد زیر در اسناد مهندسی مشخص شوند:

برای SFB32

· Sequence Description

· Step List

· Transition Conditions

· Permissive

· Interlock

·  Hold

·  Abort

·  Restart Strategy

·  Manual Step

·  Auto Sequence

برای SFB35

·  Alarm Philosophy

·  Alarm Priority

·  Alarm Class

·  Message Text

· Acknowledge

· Reset

· Historization

·  Operator Response

برای SFB37

· Data List

· Sampling Strategy

· Destination

· Data Structure

· Communication Load

·Archive Requirement

· Historian Requirement

این کار باعث می‌شود نرم‌افزار PLC مستقیماً با مدارک مهندسی پروژه قابل ردیابی باشد.

جمع‌بندی کاربردی SFB های این بخش

در این بخش از آموزش SFB در STEP7 Classic سه System Function Block مهم را بررسی کردیم که هرکدام بخشی از معماری یک سیستم کنترل صنعتی را پوشش می‌دهند.

SFB32 – DRUM برای کنترل فرآیندهای مرحله‌ای و Sequenceهای چندمرحله‌ای کاربرد دارد.

SFB35 – ALARM_8P برای تولید پیام‌های مرتبط با Alarm و Event با امکان Associated Value برای هشت Signal طراحی شده است. زیمنس در مستندات S7-400 آن را به‌عنوان یک SFB مهم برای Alarm/Event معرفی می‌کند. Siemens Industry

SFB37 – AR_SEND در معماری‌های S7-400 برای ارسال داده‌های فرآیندی مورد استفاده قرار می‌گیرد و در سناریوهای Data Acquisition و انتقال داده به سیستم‌های بالادستی اهمیت پیدا می‌کند. Siemens Industry

برای یک پروژه نفت، گاز، پتروشیمی یا نیروگاهی، استفاده صحیح از این قابلیت‌ها باید بخشی از Software Architecture، Functional Design، Alarm Philosophy، FAT/SAT و Commissioning Strategy باشد؛ نه صرفاً یک تکنیک برنامه‌نویسی PLC.

نکته فنی: در نسخه‌های مختلف S7-300/S7-400، قابلیت‌های SFB و نحوه پشتیبانی آن‌ها می‌تواند متفاوت باشد؛ بنابراین برای پروژه واقعی، شماره CPU، Firmware و نسخه STEP7 باید مبنای انتخاب SFB قرار گیرد. Siemens مستندات رسمی و Instruction List مربوط به CPUهای مختلف را در پورتال پشتیبانی خود ارائه می‌کند. Siemens

در ادامه مسیر مجموعه SFBبه بررسی موارد ذیل می پردازیم:

در ادامه وارد بخش‌های SFB52 – RDREC، SFB53 – WRREC و SFB54 – RALRM شویم؛ یعنی جایی که SFBها به Reading/Writing Data Records، Diagnostic Data و Alarm Information تجهیزات و Distributed I/O نزدیک می‌شوند. این بخش برای پروژه‌های دارای ET200، PROFIBUS/PROFINET، تجهیزات هوشمند و Remote I/O اهمیت ویژه‌ای خواهد داشت. 

آموزش تخصصی SFB52، SFB53 و SFB54 در STEP7 Classic

خواندن و نوشتن Data Record، تشخیص وضعیت تجهیزات و دریافت اطلاعات Alarm در S7-300 / S7-400

در ادامه مجموعه آموزش‌های تخصصی System Function Block یا SFB در STEP7 Classic، به بخشی می‌رسیم که اهمیت آن در پروژه‌های صنعتی بسیار بیشتر از یک برنامه‌نویسی معمولی PLC است.

در پروژه‌های نفت، گاز، پتروشیمی و نیروگاهی، PLC فقط وظیفه اجرای منطق کنترلی را ندارد. تجهیزات هوشمند، Remote I/O، درایوها، Motor Management Systemها، تجهیزات PROFIBUS/PROFINET و ماژول‌های توزیع‌شده، اطلاعات بسیار بیشتری از وضعیت ساده ON/OFF در اختیار سیستم کنترل قرار می‌دهند.

این اطلاعات معمولاً در قالب Data Record، Diagnostic Information و Alarm Information در اختیار CPU قرار می‌گیرد.

اینجا سه SFB مهم وارد معماری پروژه می‌شوند:

·  SFB52 – RDREC برای خواندن Data Record

· SFB53 – WRREC برای نوشتن Data Record

· SFB54 – RALRM برای دریافت و ارزیابی اطلاعات Interrupt/Alarm

در مستندات S7-400، زیمنس SFB52 و SFB53 را برای Read/Write Record و SFB54 را برای دریافت Alarm از DP Slave یا IO Device معرفی کرده است. این بلوک‌ها هم در معماری PROFIBUS DP و هم در معماری PROFINET IO کاربرد دارند؛ البته قابلیت دقیق آن‌ها به CPU، Firmware و نوع Interface بستگی دارد. Siemens Industry Support

 معرفی : SFB52 – RDREC

SFB52 چیست؟

SFB52 با نام RDREC یا Read Record برای خواندن یک Data Record از یک DP Slave یا PROFINET IO Device استفاده می‌شود.

در واقع اگر یک تجهیز هوشمند اطلاعاتی را در یک Record مشخص ارائه کند، PLC می‌تواند با SFB52 آن Record را درخواست کرده و اطلاعات دریافت‌شده را در یک ناحیه حافظه قرار دهد.

زیمنس صراحتاً SFB52 را برای خواندن Data Record از یک IO Device معرفی کرده است. Siemens Industry Support

معماری کلی عملکرد را می‌توان این‌گونه در نظر گرفت:

بنابراین SFB52 را باید بیشتر به‌عنوان یک ابزار دسترسی ساختاریافته به اطلاعات تجهیز در نظر گرفت، نه صرفاً یک بلوک Diagnostic.

چرا Data Record در پروژه‌های صنعتی اهمیت دارد؟

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

یک Motor Management Device یا تجهیزات هوشمند ممکن است اطلاعاتی مانند:

· وضعیت تجهیز

· خطاها

· Warningها

·  پارامترهای تنظیمی

·  اطلاعات Diagnostic

· اطلاعات Channel

· اطلاعات Module

· اطلاعات Device

· مشخصات عملکردی

را در Data Recordهای مختلف ارائه کند.

در این شرایط، استفاده از SFB52 اجازه می‌دهد PLC در زمان اجرا اطلاعات مورد نیاز را از تجهیز دریافت کند.

ساختار اصلی SFB52

جدول پارامترهای اصلی SFB52 عبارت‌اند از:

این ساختار در مستندات رسمی SFB52 زیمنس نیز ارائه شده است. Siemens Digital Industries Support

REQ در SFB52

پارامتر REQ شروع یک عملیات Read را درخواست می‌کند.

اما یک نکته بسیار مهم وجود دارد:

SFB52 یک عملیات Asynchronous دارد.

یعنی عملیات لزوماً در همان فراخوانی اول تمام نمی‌شود و CPU ممکن است برای تکمیل درخواست به چند Call نیاز داشته باشد. زیمنس نیز تأکید می‌کند که وضعیت عملیات با BUSY و STATUS پیگیری می‌شود.Siemens Many Manuals

بنابراین طراحی صحیح معمولاً چنین منطقی دارد:

یا در صورت خطا:

ID در SFB52

ID مشخص می‌کند درخواست مربوط به کدام Component یا IO Device است.

در معماری‌های مختلف، نحوه تعیین ID باید بر اساس Hardware Configuration و مستندات CPU/Device انجام شود.

در مستندات زیمنس، ID به‌عنوان Logical Address مربوط به DP Slave یا PROFINET IO Component معرفی شده است. .. Siemens Manymanuals

بنابراین یکی از اشتباهات رایج این است که مهندس فقط آدرس فیزیکی تجهیز را به‌عنوان ID در نظر بگیرد.

در پروژه واقعی باید بررسی شود که:

ID مورد نیاز SFB52 چیست؟

و این مقدار از Hardware Configuration و ساختار آدرس‌دهی همان سیستم استخراج شود.

INDEX در SFB52 چیست؟

INDEX مشخص‌کننده شماره Data Record است.

این پارامتر اهمیت بسیار زیادی دارد.

فرض کنید یک تجهیز هوشمند چند Record مختلف دارد:

· Record مربوط به Configuration

· Record مربوط به Diagnostic

· Record مربوط به Channel

· Record مربوط به Device

·Record مربوط به Parameter

هرکدام می‌توانند Index متفاوتی داشته باشند.

بنابراین:

ID مشخص می‌کند از کدام تجهیز بخوانیم.

و:

INDEX مشخص می‌کند کدام Record را از آن تجهیز بخوانیم.

این دو مفهوم نباید با هم اشتباه شوند.

MLEN چیست؟

MLEN حداکثر تعداد Byteهایی است که می‌خواهیم دریافت کنیم.

در نتیجه حافظه‌ای که برای RECORD در نظر می‌گیریم باید ظرفیت کافی داشته باشد.

زیمنس صراحتاً اعلام می‌کند که طول ناحیه RECORD باید حداقل به اندازه MLEN باشد. Siemens Manymanuals

برای مثال:

اگر:

MLEN = 100

باشد، ناحیه مقصد باید ظرفیت حداقل 100 Byte را داشته باشد.

VALID در SFB52

VALID یکی از مهم‌ترین خروجی‌های SFB52 است.

وقتی:

VALID = TRUE

شود، یعنی Data Record با موفقیت دریافت شده و اطلاعات موجود در RECORD معتبر است.

در این حالت LEN نیز طول واقعی اطلاعات دریافت‌شده را مشخص می‌کند.Siemens Industry

بنابراین در طراحی Diagnostic بهتر است فقط به BUSY نگاه نکنیم.

منطق مناسب:

·BUSY →  آیا عملیات هنوز در حال اجراست؟

·  VALID → آیا داده معتبر دریافت شده؟

·  ERROR → آیا عملیات با خطا مواجه شده؟

· STATUS → خطا دقیقاً چیست؟

· LEN → چند Byte واقعاً دریافت شده؟

مثال صنعتی SFB52؛ تشخیص وضعیت SIMOCODE

یکی از کاربردهای واقعی SFB52 در تجهیزات Motor Management مانند SIMOCODE pro است.

در مستندات زیمنس، نمونه‌ای برای خواندن Diagnostic Data Record از SIMOCODE pro V PN ارائه شده است. در آن نمونه، Data Record مربوط به Diagnostic توسط INDEX مشخص شده و اطلاعات در RECORD دریافت می‌شود.Siemens Industry

معماری پروژه می‌تواند چنین باشد:

در چنین معماری، سیستم کنترل می‌تواند اطلاعاتی فراتر از یک Motor Fault ساده دریافت کند.

مثال نفت و گاز؛ Motor Management

فرض کنید یک پمپ فرآیندی P-101 توسط Motor Management Device کنترل می‌شود.

اپراتور فقط باید بداند:

P-101 Trip

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

مثلاً:

· علت Trip

· وضعیت حفاظتی

· خطای Channel

· وضعیت Communication

·  وضعیت موتور

·  اطلاعات Diagnostic

در اینجا SFB52 می‌تواند برای خواندن Data Record مربوط به Diagnostic مورد استفاده قرار گیرد؛ البته Record Number و ساختار داده باید بر اساس مستندات همان تجهیز تعیین شود و نباید Indexها را بدون بررسی از یک تجهیز به تجهیز دیگر منتقل کرد.

SFB52 و Diagnostic در ET200

در معماری‌های Distributed I/O مانند ET200 نیز Data Recordهای Diagnostic می‌توانند اطلاعات جزئی‌تری از وضعیت Module، Slot یا Channel ارائه کنند.

زیمنس در مستندات Diagnostic مربوط به PROFINET IO، SFB52 را برای خواندن Diagnostic Data Records معرفی می‌کند و نمونه‌هایی از Recordهای مربوط به Submodule، Slot، Channel و Device را توضیح می‌دهد.Siemens Industry Support

این موضوع در پروژه‌هایی که تعداد زیادی Remote I/O دارند اهمیت ویژه‌ای پیدا می‌کند.

نکته مهم: SFB52 را در هر جایی فراخوانی نکنید

SFB52 Asynchronous است.

در مستندات زیمنس برای Diagnostic Data Record، استفاده از SFB52 در اجرای Cyclic توصیه شده و استفاده از آن در Interrupt OB یا Timed Interrupt OB توصیه نشده است. Siemens Industry Support

برای همین در پروژه‌های EPC باید معماری Diagnostic به‌گونه‌ای طراحی شود که عملیات Read Record:

· قابل مدیریت باشد.

· درخواست‌ها روی هم نیفتند.

· BUSY کنترل شود.

· ERROR ثبت شود.

· STATUS ذخیره شود.

·  تعداد درخواست‌های هم‌زمان کنترل شود.

معرفی SFB53 – WRREC در سیماتیک منیجر:

SFB53 چیست؟

SFB53 – WRREC یا Write Record عملکرد معکوس SFB52 را انجام می‌دهد.

یعنی به‌جای خواندن Data Record، اطلاعات را از PLC به DP Slave یا PROFINET IO Device ارسال می‌کند.

زیمنس SFB53 را برای نوشتن Data Record در IO Device معرفی کرده است. Siemens Industry Support

معماری:

کاربرد SFB53 در تجهیزات هوشمند

SFB53 زمانی اهمیت پیدا می‌کند که بخواهیم پارامتر یا Data Record قابل تغییر یک تجهیز را در زمان Runtime تنظیم کنیم.

برای مثال در یک معماری صنعتی ممکن است نیاز باشد:

· پارامتر تجهیز تغییر کند.

· Configuration خاصی ارسال شود.

· Parameter Record به Remote I/O منتقل شود.

· تنظیمات یک تجهیز هوشمند در Runtime تغییر کند.

اما یک اصل بسیار مهم وجود دارد:

هر Data Record الزاماً قابل نوشتن نیست.

اینکه یک Record با SFB52 قابل خواندن است به این معنی نیست که همان Record با SFB53 قابل نوشتن است.

قابلیت Write باید در Manual همان Device مشخص شده باشد.

جدول پارامترهای اصلی SFB53

این پارامترها در مستندات SFB53 زیمنس مشخص شده‌اند. Siemens Manuals

مثال کاربردی SFB53 در پروژه نفت و گاز

فرض کنید یک Remote I/O یا تجهیز هوشمند در واحد فرآیندی دارای پارامتر قابل تنظیم است.

معماری:

قبل از ارسال باید بررسی شود:

·   آیا تجهیز Online است؟

·   آیا Record قابل Write است؟

·  آیا Index صحیح است؟

· طول Data صحیح است؟

·  مقدار پارامتر در محدوده مجاز است؟

· آیا عملیات در حال انجام دیگری وجود دارد؟

· نتیجه Write چگونه تأیید می‌شود؟

این موضوع مخصوصاً در پروژه‌هایی که Online Parameterization دارند اهمیت دارد.

یک نکته مهم برای پروژه EPC

نوشتن Parameter به تجهیزات در Runtime باید تحت کنترل مهندسی باشد.

نباید اجازه داد اپراتور بدون محدودیت هر Data Record را به هر تجهیزی ارسال کند.

بهتر است در معماری پروژه:

·  پارامترهای مجاز مشخص باشند.

· Range Check انجام شود.

· Access Level مشخص باشد.

·  تغییرات Log شوند.

· عملیات Write دارای Interlock نرم‌افزاری باشد.

·  نتیجه Write بررسی شود.

این موضوع از منظر Commissioning و Functional Safety نیز اهمیت پیدا می‌کند؛ البته SFB53 به‌خودی‌خود Safety Function محسوب نمی‌شود.

مثال کاربردی؛ تغییر پارامتر یک Remote Device

فرض کنید یک تجهیز دارای یک Parameter Record قابل تغییر است.

ابتدا:

این معماری بسیار بهتر از این است که یک بیت ساده M10.0 مستقیماً باعث Write شدن Data Record شود.

SFB52 و SFB53 در کنار یکدیگر

یکی از معماری‌های حرفه‌ای این است که Write را با Read Verification همراه کنیم.

یعنی: