جداول connection table و pipe data table

پاسخ‌ها (۲)

• استادعلی مانی زاده· ۲ ماه پیش

  سلام و عرض ادب.
  سؤال خیلی خوبی است؛ چون اگر فلسفه این دو جدول روشن نشود، واقعاً به نظر می‌رسد که «خب وقتی Designer می‌تواند خلاف جدول عمل کند، اصلاً چرا Branch Table یا Pipe Data Table بسازیم؟»

  اول یک تفکیک مهم انجام دهیم: Branch Table با Connection Compatibility Table یکی نیست. در AVEVA برای Specification یک Reference به Branch Table وجود دارد (BRREFA) و Pipe Data Table نیز جداگانه به Specification ارجاع داده می‌شود.

  1. کاربرد واقعی Branch Table چیست؟

  فرض کنید در PMS نوشته شده:

  Header Branch روش مجاز انشعاب
  8" 6" Reducing Tee
  8" 4" Reducing Tee
  8" 2" Weldolet
  8" 1" Sockolet

  Branch Table در واقع این منطق انتخاب انشعاب بر اساس ترکیب Header Size × Branch Size را به E3D معرفی می‌کند.

  بنابراین مفهومش این است:

  اگر قرار شد از 8 اینچ، Branch دو اینچ ایجاد شود، روش Preferred تعریف‌شده در این Spec چیست؟

  مثلاً:

  8" × 2" → WOL

  و:

  8" × 4" → TEE

  پس Branch Table بیشتر یک Selection Logic / Engineering Rule است، نه یک Firewall که کاربر دیگر نتواند هیچ Component دیگری بسازد. خود معماری AVEVA نیز Branch/Reducer Tables را در مجموعه Selection Tables قرار می‌دهد.

  و این دقیقاً جواب ابهام شماست:

  بله؛ اگر شما Tee و Weldolet و Sockolet را همگی داخل SPEC قرار داده باشید، ممکن است Designer بتواند به روش دستی Component دیگری را انتخاب و Insert کند.

  این موضوع Branch Table را بی‌فایده نمی‌کند.

  مثلاً PMS می‌گوید:

  10" × 2" Branch = Weldolet

  Branch Table هم می‌گوید:

  10" × 2" → WOL

  ولی چون یک 10"×2" Reducing Tee هم در Spec موجود است، Designer ممکن است دستی آن را انتخاب کند.

  در چنین حالتی Branch Table وظیفه‌اش را انجام داده است؛ ولی قرار نبوده به‌تنهایی دست Designer را ببندد.

  برای کنترل سختگیرانه‌تر باید ساختار Specification، Component Availability و در پروژه‌های حرفه‌ای Rules/Checks و QA روی مدل نیز درست تنظیم شوند.

  Connection Table پس چه‌کار می‌کند؟

  این را هم از Branch Table جدا کنید.

  Connection Compatibility Table بیشتر جواب این سؤال را می‌دهد:

  آیا End Connection این Component می‌تواند به End Connection آن Component متصل شود؟

  مثلاً مفاهیمی مثل:

  BW ↔ BW
  SW ↔ مناسب Socket Weld
  Flange Face ↔ Flange Face مناسب
  Screwed ↔ Screwed

  بنابراین Connection Compatibility درباره سازگاری اتصال P-pointها است، نه اینکه در PMS برای یک Branch خاص Tee استفاده شود یا Weldolet. AVEVA نیز Connection Compatibility Tables را مستقل از Branch/Reducer Tables در ساختار Catalogue معرفی می‌کند.

  پس در ذهنتان این سه مفهوم را جدا کنید:

  SPEC: چه Componentهایی در اختیار Designer هستند؟

  Branch Table: برای هر Header/Branch combination کدام نوع Branch Component ترجیح/تعریف شده است؟

  Connection Compatibility: آیا End Connectionهای دو Component اصولاً قابلیت اتصال به یکدیگر دارند؟

  مفید۰غیر مفید۰

  پاسخ
• استادعلی مانی زاده· ۲ ماه پیش

  1. Pipe Data Table و Schedule چه کاربردی دارد؟

  اینجا فلسفه جدول کاملاً متفاوت است.

  AVEVA صراحتاً Pipe Data Table را برای ذخیره Bore-specific data تعریف می‌کند؛ یعنی اطلاعات مهندسی که با Nominal Bore تغییر می‌کنند. هر Specification می‌تواند Pipe Data Table خودش را Reference کند.

  مثلاً یک PMS ممکن است بگوید:

  NPS Pipe Schedule
  ½" SCH 80
  ¾" SCH 80
  1" SCH 80
  1½" SCH 80
  2" SCH 40
  3" SCH 40
  4" SCH 40
  6" SCH 40
  8" SCH 30

  پس Pipe Class فقط یک Schedule ثابت ندارد.

  Pipe Data Table به E3D می‌گوید:

  برای این SPEC و این Nominal Bore، Wall Thickness Reference چیست؟

  AVEVA برای Pipe Data Table به‌طور مشخص زیرموضوعاتی مانند Wall Thickness Reference، Corrosion Allowance و Flange Allowance تعریف کرده است.

  یعنی مثلاً:

  NPS 1" → SCH 80

  NPS 4" → SCH 40

  NPS 8" → SCH 30

  و Schedule نیز از طریق Wall Thickness Table به یک ضخامت واقعی مرتبط می‌شود.

  مثلاً به‌صورت مفهومی:

  NPS 4" + SCH 40 → t = 6.02 mm

  این اطلاعات دیگر صرفاً «اسم SCH40» نیست؛ یک Engineering Property مربوط به Pipe Class است.

  چرا این اطلاعات را داخل خود Pipe Component نمی‌گذاریم؟

  چون فلسفه Catalogue و Specification متفاوت است.

  Catalogue هندسه و تعریف Component را نگه می‌دارد؛ اما اینکه در این Pipe Class مشخص برای NPS خاص چه Wall Thickness، Corrosion Allowance و Engineering Data‌ای معتبر است، منطقی‌تر است در سطح Specification تعریف شود.

  در نتیجه یک Catalogue Item می‌تواند در Specificationهای مختلف استفاده شود، ولی Engineering Data هر Specification متفاوت باشد.

  مثلاً ممکن است دو Class داشته باشیم:

  Class A:

  4" Pipe → SCH 40

  و:

  Class B:

  4" Pipe → SCH 80

  لازم نیست برای هر بار کل Catalogue Geometry را دوباره بسازیم.

  Pipe Data Table این ارتباط را ایجاد می‌کند.

  مفید۰غیر مفید۰

  پاسخ

پاسخ شما