# رونوشت کامل گفت‌وگوی «برآورد ظرفیت حمل» - **منبع:** https://chatgpt.com/share/6ab8ff2f-f360-83eb-a54a-ca9b6ce1c0d3 - **تاریخ استخراج:** ۲۰۲۶٫۰۹٫۲۸ (2026-09-28) - **روش:** استخراج مستقیم از DOM صفحهٔ اشتراک‌گذاری‌شدهٔ ChatGPT (رندر جاوااسکریپتی، مجازی‌سازی‌شده) با chrome-devtools-axi، پیام به پیام، بدون خلاصه‌سازی یا ترجمه. متن پیام‌ها عیناً از innerText گره‌های `[data-message-author-role]` گرفته شده است. - **وضعیت:** این گفت‌وگو سند مدل ریاضی و الگوریتمی «موتور تولید، برآورد و بهینه‌سازی ظرفیت حمل بار ریلی» را در طول ۱۶ پرسش کاربر (Prompt 1 تا Prompt 16) می‌سازد. پاسخ به آخرین پرسش (Prompt 16، «یه موکاپ از نمای سامانه... بدی») یک **تصویر تولیدشده** است، نه متن؛ اسکرین‌شات آن در [`assets/chatgpt-generated-mockup-image.png`](assets/chatgpt-generated-mockup-image.png) نگه‌داری شده و صرفاً الهام تصویری غیررسمی است، نه مشخصات محصول یا فرمول. - **محدودیت شناخته‌شده:** فرمول‌های ریاضی در صفحهٔ اصلی با نماد LaTeX درون کروشه (مثلاً `[C_b \rightarrow C_s]`) رندر می‌شدند؛ innerText مرورگر این کروشه‌ها و دستورهای LaTeX خام (`\rightarrow`, `\leq`, `\boxed{...}` و مشابه) را عیناً به‌صورت متن ساده برگردانده است. این متن خام دقیقاً همان چیزی است که مرورگر بازگردانده و بدون تفسیر بازنویسی نشده تا وفاداری منبع حفظ شود؛ هنگام استفاده در پیاده‌سازی، این عبارات باید به‌عنوان فرمول ریاضی خوانده شوند نه متن نمایشی. --- ## Prompt 1 — پرسش کاربر (`conversation-turn-1`) موتور تولید یا برآورد ظرفیت حمل بار ## Prompt 1 — پاسخ دستیار (`conversation-turn-2`) اگر منظورتان «موتور تولید/برآورد ظرفیت حمل بار ریلی» برای همان معماری مرکز نوآوری و سامانه‌های ریلی است، به‌نظر من بهتر است آن را به‌عنوان یک موتور محاسباتی مستقل (Capacity Estimation & Generation Engine) طراحی کنیم، نه صرفاً یک گزارش‌ساز. این موتور می‌تواند از روی وضعیت واقعی شبکه، لکوموتیو، واگن، مسیر، ایستگاه‌ها، گلوگاه‌ها و تقاضای بار، به‌صورت پویا محاسبه کند: ظرفیت نظری → ظرفیت فنی → ظرفیت عملیاتی → ظرفیت قابل عرضه → ظرفیت قابل فروش → ظرفیت بالفعل مورد انتظار معماری پیشنهادی موتور داده‌های زیرساخت ↓ داده‌های ناوگان ↓ داده‌های برنامه حرکت ↓ محدودیت‌های شبکه ↓ تقاضای بار و مبدأ–مقصد ↓ ┌─────────────────────────────┐ │ موتور برآورد ظرفیت حمل │ │ │ │ 1. ظرفیت خط │ │ 2. ظرفیت گلوگاه‌ها │ │ 3. ظرفیت ایستگاه‌ها │ │ 4. ظرفیت لکوموتیو │ │ 5. ظرفیت واگن │ │ 6. ظرفیت بارگیری/تخلیه │ │ 7. ظرفیت زمانی │ │ 8. تعارض مسیرها │ │ 9. محدودیت‌های عملیاتی │ │ 10. تقاضای بازار │ └─────────────────────────────┘ ↓ ظرفیت قابل عرضه ↓ موتور تخصیص / حراج ظرفیت ↓ برنامه قطارهای قابل اجرا نکته بسیار مهم برای پروژه‌ای که قبلاً درباره بازارگاه ریلی و حراج ظرفیت مطرح کردیم، من این موتور را حتی یک لایه بالاتر از موتور تخصیص ظرفیت قرار می‌دهم. یعنی: موتور برآورد ظرفیت می‌گوید: «در این ماه، در این مسیر و با این شرایط، واقعاً چه مقدار ظرفیت حمل بار قابل ایجاد و عرضه است؟» و سپس: موتور تخصیص/حراج می‌گوید: «این ظرفیت محدود را به چه متقاضیانی، در چه زمان‌هایی و با چه ترکیبی تخصیص دهیم؟» این تفکیک معماری بسیار مهم است؛ چون ظرفیت تولیدشده با ظرفیت تخصیص‌یافته و ظرفیت واقعاً استفاده‌شده یکی نیست. اگر بخواهید، قدم بعدی را می‌توانیم خیلی جدی‌تر برداریم و « سند مشخصات فنی موتور تولید و برآورد ظرفیت حمل بار ریلی» را از صفر طراحی کنیم؛ شامل فرمول‌ها، ورودی‌ها، خروجی‌ها، الگوریتم، مدل داده، KPIها، نمونه محاسبه ۳۰۰ قطار/ماه و اتصال آن به موتور حراج ظرفیت. --- ## Prompt 2 — پرسش کاربر (`conversation-turn-3`) کاملا درسته. این رو هم ببین بسمه تعالی مقدمه پیش فرض اول: بلاک مشترک در روت مشترک؛ حداکثر به میزان بهینه‌ترین روت امکان حمل دارد و لذا جذب بار در سایر روت‌های مشترک در این بلاک صرفا به عنوان رقیب خواهند بود و به دلیل بهینه بودن این روت، حمل بار در سایر روت‌های رقیب توجیه ندارد. به همین دلیل در صورتی که میزان بار در طول سال، کفاف ظرفیت این روت را ندهد، یا سیاست حفظ سایر روت‌ها وجود داشته و لذا سهمیه‌ای در طول سال به صورت طولی یا عرضی (موازی یا سریال) گلوگاه خواهد بود. موتور تولید ظرفیت ·         محاسبه ظرفیت تک خطه ·         محاسبه ظرفیت دوخطه ملاحظات: ·         حداکثر سرعت قابل سیر در بلاک (بر اساس مشخصات خط، سازمان، نوع قطار) ·         قوانین تست ترمز ·         سوختگیری ·         حداقل مدت زمان مورد نیاز جهت اعزام قطار بعدی (بر اساس طول بزرگترین بلاک و کوتاه ترین ایستگاه بسته به تک خطه یا دو خطه بودن) محدودیت اعمالی ·         ساعت نماز ·         ایستگاه‌های قابل نماز خواندن گام‌های تولید ظرفیت ·         تعیین مبادی و مقاصد بار بر اساس اطلاعات بار (ورود اطلاعات) ·         تعیین روت‌های مبدا مقصدی (توسط کاربر ادمین). ممکن است برای برخی از مبدا و مقصد بار، بیش از یک روت تعیین شود. o        سرخس- آپرین/ اینچه‌برون-گرمسار-آپرین/ سرخس-آپرین-بافق-بندرعباس/ سرخس-بافق-فولاد/ آپرین-بندرامام/ آپرین-رازی ·         محاسبه حداکثر ظرفیت حمل در هر روت o        تعریف الگوی سرعت (بر اساس تک خطه و دو خطه، خالی و پر) ·         محاسبه حداکثر ظرفیت حمل در مجموع همه روت‌ها (طبیعتا مجموعه‌ای از روت‌های بدون تداخل): موتور حل شبکه ·         تعیین اولویت‌های حمل به ترتیب از حداکثر مجموع قابل حمل لازم به ذکر است که دو خطه شدن مربوط به روت است و روت جدیدی ایجاد نمی‌کند. همچنین یکی از ایده‌های حل مسئله، مواجهه با بخش تک خطه به صورت دو خطه است. میزان فضا و امکانات تجمیع واگن‌های خالی در نقطه دو خطه شدن حد  بهینه این حالت را مشخص می‌کند. مسیر ترکیبی تک خطه و دو خطه به نفع جریان بار تنظیم می‌شود. همچنین وجود بخش آنالیز حساسیت نسبت به ایجاد تغییراتی در شبکه برای فهمیدن اینکه با انجام مقدار مشخصی از هزینه، افزایش قابل قبولی در حمل بار رقم بخورد. نمایش وضعیت روت‌ها در هر مرحله به درک بهتر برنامه‌ریزی کمک می‌کند. لذا تا حد امکان، باید ابزار نمایش هریک از مراحل انجام پذیرد. Show more ## Prompt 2 — پاسخ دستیار (`conversation-turn-4`) بله؛ این متن اتفاقاً یک لایه بسیار مهم را به ایده قبلی اضافه می‌کند. به‌نظر من باید آن را هسته منطقی «موتور تولید ظرفیت» قرار دهیم، اما چند مفهوم در آن باید دقیق‌تر و ریاضیاتی‌تر تعریف شوند تا بعداً بتوان آن را واقعاً به نرم‌افزار تبدیل کرد. مهم‌ترین نکته‌ای که از متن شما می‌گیرم این است که موتور نباید صرفاً بگوید «هر روت چند قطار ظرفیت دارد»، بلکه باید کل شبکه را به‌صورت یک مسئله جریان بار با ظرفیت‌های متداخل، گلوگاه‌های مشترک و سناریوهای مختلف بهره‌برداری حل کند. ۱. تفکیک سه موتور من معماری را این‌طور تثبیت می‌کنم: ┌──────────────────────┐ │ داده شبکه و زیرساخت │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ موتور تولید ظرفیت │ │ Capacity Generation │ └──────────┬───────────┘ ↓ ظرفیت هر روت در شرایط واقعی ↓ ┌──────────────────────┐ │ موتور حل شبکه │ │ Network Optimizer │ └──────────┬───────────┘ ↓ ظرفیت بهینه مجموع روت‌های همزمان ↓ ┌──────────────────────┐ │ موتور تخصیص/حراج │ │ Capacity Allocation │ └──────────────────────┘ این سه موتور نباید با هم مخلوط شوند. ۲. یک اصلاح مفهومی مهم در متن شما عبارت: «بلاک مشترک در روت مشترک؛ حداکثر به میزان بهینه‌ترین روت امکان حمل دارد» ایده بسیار خوبی دارد، ولی برای تبدیل شدن به الگوریتم بهتر است آن را این‌گونه تعریف کنیم: ظرفیت یک بخش مشترک از شبکه، یک ظرفیت محدود و قابل مصرف توسط چند جریان بار رقیب است. بنابراین ظرفیت قابل تخصیص به هر روت مستقل از سایر روت‌ها نیست و باید در سطح شبکه بهینه‌سازی شود. مثلاً: ┌── روت A ── مقصد A │ مبدأ ──[بخش مشترک]┤ │ └── روت B ── مقصد B اگر بخش مشترک بتواند در ماه مثلاً ۱۰۰ قطار عبور دهد، نمی‌توان برای A و B جداگانه ۱۰۰ قطار ظرفیت اعلام کرد. باید داشته باشیم: Capacity(A) + Capacity(B) ≤ Capacity(Common Block) و این همان جایی است که موتور حل شبکه وارد می‌شود. ۳. «ظرفیت» را باید به چند سطح تقسیم کنیم این موضوع برای نرم‌افزار بسیار حیاتی است. من پیشنهاد می‌کنم حداقل این پنج مفهوم را داشته باشیم: سطح مفهوم ظرفیت نظری حداکثر ظرفیت حاصل از هندسه و زمان‌بندی ایده‌آل ظرفیت فنی با درنظرگرفتن مشخصات خط، بلاک، سرعت، ایستگاه و قطار ظرفیت عملیاتی با قوانین واقعی بهره‌برداری ظرفیت قابل عرضه پس از اعمال محدودیت‌ها و سیاست‌های شبکه ظرفیت قابل تخصیص ظرفیتی که پس از رقابت روت‌ها واقعاً می‌توان به بارها اختصاص داد و در نهایت: ظرفیت واقعی حمل بار = ظرفیت قطار × ظرفیت بارگیری مفید × ضریب تحقق عملیاتی این تفکیک باعث می‌شود بعداً اختلاف بین «ظرفیت روی کاغذ» و «تناژ واقعی حمل‌شده» قابل ردیابی باشد. ۴. موتور تولید ظرفیت دقیقاً چه می‌کند؟ برای هر روت: ورودی مبدأ مقصد مسیر طول هر بلاک تک‌خطه/دوخطه طول ایستگاه‌ها فاصله ایستگاه‌ها سرعت مجاز سرعت قطار نوع قطار طول قطار وزن قطار وضعیت لکوموتیو قوانین تست ترمز زمان توقف زمان سوخت‌گیری زمان تعویض/تجمیع محدودیت‌های عملیاتی پنجره‌های زمانی ساعات نماز ایستگاه‌های مجاز توقف محدودیت‌های روزانه/هفتگی جهت حرکت بار/خالی بودن قطار و خروجی: روت X ظرفیت روزانه: 8 قطار ظرفیت ماهانه: 240 قطار ظرفیت سالانه: 2,880 قطار تناژ هر قطار: X تن تناژ روزانه: X تن تناژ سالانه: X تن اما این هنوز ظرفیت مستقل روت است. ۵. نکته بسیار مهم شما درباره تک‌خطه و دوخطه این قسمت متن شما به نظرم باید تبدیل به یکی از قابلیت‌های اصلی سیستم شود: «دو خطه شدن مربوط به روت است و روت جدیدی ایجاد نمی‌کند.» کاملاً درست است که در مدل داده، دوخطه شدن نباید الزاماً به معنای ایجاد یک Route جدید باشد. بلکه: Route R1 │ ├── Segment 1 → تک‌خطه ├── Segment 2 → تک‌خطه ├── Segment 3 → دوخطه ├── Segment 4 → دوخطه └── Segment 5 → تک‌خطه بنابراین Route یک موجودیت ثابت است و وضعیت زیرساختی Segmentهای آن می‌تواند تغییر کند. این موضوع بعداً امکان تحلیل سناریو را فوق‌العاده قوی می‌کند: وضعیت فعلی ↓ دوخطه کردن Segment 3 ↓ محاسبه مجدد ظرفیت ↓ افزایش ظرفیت Route ↓ افزایش ظرفیت شبکه ↓ افزایش تناژ قابل حمل ↓ محاسبه ارزش اقتصادی سرمایه‌گذاری ۶. ایده بسیار مهم «مواجهه تک‌خطه با دوخطه» این قسمت را حتی باید از یک توضیح جانبی به یک ماژول بهینه‌سازی مستقل تبدیل کنیم. فرض کنید: مبدأ │ │ تک‌خطه │ ▼ ═══════ دوخطه ═══════ │ │ تک‌خطه ▼ مقصد در حالت ساده ممکن است فکر کنیم ظرفیت کل تابع ظرفیت قسمت تک‌خطه است. اما اگر در نقطه دوخطه امکان: تجمیع واگن تشکیل قطار انتظار کنترل‌شده سبقت تنظیم حرکت تغییر آرایش قطار آماده‌سازی قطار بعدی وجود داشته باشد، می‌توان بخشی از محدودیت تک‌خطه را با عملیات مناسب جذب کرد. بنابراین باید یک متغیر جدید داشته باشیم: ظرفیت عملیاتی قابل بازیابی یعنی: چه مقدار از محدودیت بخش تک‌خطه را می‌توان با استفاده از امکانات بخش دوخطه جبران کرد؟ این دقیقاً همان چیزی است که شما با عبارت: «میزان فضا و امکانات تجمیع واگن‌های خالی در نقطه دوخطه شدن حد بهینه این حالت را مشخص می‌کند» بیان کرده‌اید. ۷. مسئله اصلی دیگر: الگوی سرعت اینجا به نظرم باید از ابتدا مدل ریاضی نسبتاً دقیقی داشته باشیم. برای هر Segment: سرعت مجاز خط + نوع قطار + بار/خالی + شیب + قوس + محدودیت سازمانی + مشخصات لکوموتیو ↓ سرعت واقعی قابل استفاده و سپس: زمان سیر Segment به دست می‌آید. بعد زمان‌های زیر اضافه می‌شوند: زمان عبور زمان توقف زمان تست ترمز زمان تشکیل قطار زمان سوخت‌گیری زمان تعویض لکوموتیو زمان انتظار زمان تقاطع زمان سبقت زمان عبور از گلوگاه در نتیجه موتور دیگر بر اساس یک «سرعت متوسط فرضی» ظرفیت را محاسبه نمی‌کند. ۸. ساعت نماز؛ این مورد را هم باید مدل کنیم بهتر است ساعت نماز به‌صورت یک Operational Time Window تعریف شود، نه یک عدد ثابت. مثلاً: 08:00 ───────────── 12:00 ↓ پنجره توقف ↓ 12:30 ───────────── 18:00 و سیستم بتواند بگوید: آیا بهتر است قطار قبل از پنجره نماز متوقف شود یا حرکت کند و در ایستگاه بعدی توقف کند؟ این موضوع مستقیماً روی ظرفیت اثر می‌گذارد. بنابراین «محدودیت نماز» باید در موتور زمان‌بندی وارد شود، نه اینکه بعداً از ظرفیت کسر شود. ۹. موتور حل شبکه؛ قلب اصلی سیستم بعد از محاسبه ظرفیت تک‌تک روت‌ها، وارد مرحله‌ای می‌شویم که از نظر من مهم‌ترین بخش کل پروژه است. فرض کنید: Route A → 300 قطار Route B → 220 قطار Route C → 180 قطار Route D → 150 قطار ولی: A و B → بلاک مشترک X B و C → بلاک مشترک Y A و D → بلاک مشترک Z دیگر نمی‌توان ظرفیت‌ها را جمع کرد. باید یک مسئله بهینه‌سازی داشته باشیم: Maximize Total Freight Flow با قیود: Flow on common block ≤ Block capacity Flow on route ≤ Route capacity Flow on station ≤ Station capacity Flow on segment ≤ Segment capacity Flow on time window ≤ Time-window capacity Flow of each OD ≤ Demand Flow ≥ 0 و سپس: خروجی مثلاً: روت ظرفیت مستقل ظرفیت بهینه در شبکه A 300 240 B 220 110 C 180 160 D 150 120 مجموع 850 630 این ۶۳۰ قطار، دیگر ظرفیت خام نیست؛ ظرفیت بهینه شبکه تحت شرایط و رقابت روت‌هاست. ۱۰. «اولویت‌های حمل» را بهتر است بعد از حل شبکه تعریف کنیم در متن شما آمده: تعیین اولویت‌های حمل به ترتیب از حداکثر مجموع قابل حمل من پیشنهاد می‌کنم سیستم صرفاً یک اولویت ثابت نداشته باشد. بلکه بتواند چند سناریو را محاسبه کند: سناریو A — حداکثر تناژ Maximize Ton-km / Ton سناریو B — حداکثر تعداد قطار Maximize Train Movements سناریو C — حداکثر ارزش اقتصادی Maximize Economic Value سناریو D — حفظ حداقل سهم روت‌ها مثلاً: Route A ≥ 20% Route B ≥ 15% Route C ≥ 10% سناریو E — سیاست توسعه منطقه‌ای و این دقیقاً به نکته اول شما برمی‌گردد: اگر بار یک روت کفاف ظرفیت آن را ندهد، آیا باید ظرفیت آزاد آن به روت رقیب داده شود یا بخشی از ظرفیت عمداً حفظ شود؟ این دیگر پارامتر سیاستی سیستم است، نه یک تصمیم محاسباتی. ۱۱. تحلیل حساسیت؛ یکی از باارزش‌ترین قسمت‌های کل محصول این ایده شما را من حتماً در نسخه نهایی نگه می‌دارم. مثلاً سیستم سؤال کند: اگر ۱۰۰ میلیارد تومان برای دوخطه کردن ۳۰ کیلومتر از مسیر هزینه کنیم، ظرفیت حمل چقدر افزایش پیدا می‌کند؟ موتور چند سناریو تولید کند: سرمایه‌گذاری تغییر زیرساخت افزایش قطار افزایش تناژ افزایش درآمد/ارزش ۰ وضع موجود — — — X دوخطه کردن بخش A +۴ +Y +Z 2X دوخطه کردن A+B +۱۰ +Y +Z 3X A+B+C +۱۲ +Y +Z در نتیجه سیستم می‌تواند چیزی شبیه این را تولید کند: هزینه → تغییر زیرساخت → ظرفیت جدید → تناژ جدید → ارزش اقتصادی جدید و این برای تصمیم‌گیری سرمایه‌گذاری بسیار قدرتمند است. ۱۲. نمایش مرحله‌ای که در پایان متن شما آمده، بسیار مهم است من برای نرم‌افزار یک Capacity Planning Map در نظر می‌گیرم. کاربر بتواند مراحل را به‌صورت تصویری ببیند: مرحله ۱ نمایش شبکه ↓ مرحله ۲ نمایش روت‌های OD ↓ مرحله ۳ نمایش بلاک‌های مشترک ↓ مرحله ۴ نمایش گلوگاه‌ها ↓ مرحله ۵ ظرفیت مستقل روت‌ها ↓ مرحله ۶ تعارض روت‌ها ↓ مرحله ۷ حل شبکه ↓ مرحله ۸ ظرفیت نهایی ↓ مرحله ۹ سناریوی سرمایه‌گذاری ↓ مرحله ۱۰ ظرفیت پس از مداخله و روی نقشه بتوان مثلاً دید: قرمز = گلوگاه زرد = نزدیک به اشباع سبز = ظرفیت آزاد جمع‌بندی معماری پیشنهادی بنابراین متنی که فرستادید، به نظرم باید تبدیل شود به این محصول: «موتور تولید، برآورد و بهینه‌سازی ظرفیت حمل بار ریلی» با ۷ ماژول اصلی: موتور محاسبه ظرفیت تک‌خطه موتور محاسبه ظرفیت دوخطه موتور محاسبه ظرفیت ترکیبی تک‌خطه–دوخطه موتور ظرفیت روت و OD موتور حل تعارض و بهینه‌سازی شبکه موتور تحلیل سناریو و حساسیت موتور نمایش و تحلیل جغرافیایی ظرفیت و سپس خروجی آن مستقیماً به موتور تخصیص/حراج ظرفیت که قبلاً درباره‌اش صحبت کردیم متصل می‌شود. به‌نظر من حتی می‌توانیم یک قدم جلوتر برویم: همین متن شما را به «سند مشخصات فنی و الگوریتمی نسخه 1.0» تبدیل کنیم؛ یعنی برای هر ماژول دقیقاً مشخص کنیم ورودی چیست، خروجی چیست، جدول داده چیست، فرمول چیست، قید چیست، الگوریتم حل چیست و روی نقشه چه چیزی نمایش داده می‌شود. این کار عملاً ما را از ایده مفهومی به معماری قابل‌ساخت نرم‌افزار می‌رساند. --- ## Prompt 3 — پرسش کاربر (`conversation-turn-5`) بله. این باید به یک متن مفصل با 7 ماژولی که گفتی کاملا توضیح فنی و مفهومی پیدا کند. ## Prompt 3 — پاسخ دستیار (`conversation-turn-6`) حتماً. پیشنهاد می‌کنم این سند را فقط «توضیح یک نرم‌افزار» ندانیم؛ بلکه آن را به‌عنوان سند مفهومی–فنی موتور تولید، برآورد و بهینه‌سازی ظرفیت حمل بار ریلی تعریف کنیم. در این صورت، هفت ماژول زیر ستون‌های اصلی محصول خواهند بود و بعداً می‌توانیم برای هرکدام الگوریتم، دیتابیس، API و رابط کاربری مستقل طراحی کنیم. سند مفهومی و فنی موتور تولید، برآورد و بهینه‌سازی ظرفیت حمل بار ریلی بسمه تعالی سند مفهومی و فنی موتور تولید، برآورد و بهینه‌سازی ظرفیت حمل بار ریلی Capacity Generation, Estimation & Network Optimization Engine ۱. مقدمه ظرفیت حمل بار در شبکه ریلی یک عدد ثابت و از پیش تعیین‌شده نیست؛ بلکه حاصل تعامل مجموعه‌ای از عوامل زیرساختی، عملیاتی، ناوگانی، زمانی، جغرافیایی، اقتصادی و تقاضایی است. در یک نگاه ساده ممکن است ظرفیت یک مسیر بر اساس تعداد قطار قابل عبور در شبانه‌روز محاسبه شود؛ اما در شبکه واقعی، این رویکرد کافی نیست. یک مسیر ممکن است از چندین بخش تک‌خطه و دوخطه تشکیل شده باشد، چند مسیر مبدأ–مقصد از یک بلاک یا ایستگاه مشترک عبور کنند، ظرفیت یک بخش توسط چند جریان بار به‌صورت رقابتی مصرف شود، محدودیت‌های توقف، تست ترمز، سوخت‌گیری و تشکیل قطار وجود داشته باشد و در نهایت ظرفیت نظری حاصل از محاسبات خط، با ظرفیت قابل تحقق در شبکه تفاوت قابل‌توجهی داشته باشد. از سوی دیگر، هدف اصلی شبکه ریلی صرفاً عبور حداکثری قطار نیست؛ بلکه باید بتوان حداکثر جریان اقتصادی و قابل اتکای بار را از شبکه عبور داد. بنابراین لازم است سامانه‌ای ایجاد شود که از سطح «محاسبه ظرفیت یک بلاک» تا سطح «بهینه‌سازی کل شبکه و تعیین ظرفیت قابل عرضه به بازار» را پوشش دهد. این سامانه در این سند با عنوان: موتور تولید، برآورد و بهینه‌سازی ظرفیت حمل بار ریلی شناخته می‌شود. ۲. فلسفه و هدف اصلی موتور هدف اصلی موتور عبارت است از: تبدیل اطلاعات فنی و عملیاتی شبکه ریلی، اطلاعات ناوگان، برنامه‌های بهره‌برداری و تقاضای بار به ظرفیت قابل محاسبه، قابل تحلیل، قابل بهینه‌سازی و نهایتاً قابل عرضه و تخصیص در بازار حمل بار ریلی. این موتور باید بتواند به پرسش‌های زیر پاسخ دهد: هر مسیر حداکثر چند قطار می‌تواند عبور دهد؟ ظرفیت مسیر در حالت تک‌خطه چقدر است؟ ظرفیت همان مسیر پس از دوخطه شدن یک Segment چقدر افزایش می‌یابد؟ ترکیب تک‌خطه و دوخطه چه اثری بر ظرفیت دارد؟ کدام بلاک‌ها گلوگاه شبکه هستند؟ کدام روت‌ها از ظرفیت مشترک یک گلوگاه استفاده می‌کنند؟ اگر دو روت رقیب باشند، ظرفیت قابل تخصیص به هرکدام چقدر است؟ حداکثر مجموع بار قابل حمل در کل شبکه چقدر است؟ اگر تقاضای یک روت کمتر از ظرفیت آن باشد، ظرفیت آزاد آن چگونه می‌تواند در اختیار روت‌های دیگر قرار گیرد؟ آیا حفظ حداقل سهم یک روت خاص از نظر ظرفیت یا سیاست شبکه ضروری است؟ دوخطه کردن کدام بخش شبکه بیشترین ظرفیت جدید را ایجاد می‌کند؟ برای افزایش مثلاً ۱۰ میلیون تن ظرفیت سالانه، کدام مداخله زیرساختی مناسب‌تر است؟ هزینه هر مداخله چقدر است و ظرفیت حاصل از آن چه مقدار خواهد بود؟ ظرفیت تولیدشده در نهایت چه مقدار قابلیت عرضه در بازار دارد؟ چه مقدار ظرفیت به‌دلیل محدودیت ناوگان، ایستگاه، بارگیری، تخلیه یا تقاضا قابل استفاده نیست؟ ۳. جایگاه موتور در معماری کلان سامانه حمل بار ریلی موتور تولید ظرفیت نباید با موتور تخصیص ظرفیت یا موتور حراج اشتباه گرفته شود. معماری کلان پیشنهادی: داده‌های زیرساخت │ داده‌های ناوگان │ داده‌های برنامه حرکت │ داده‌های تقاضای بار │ داده‌های عملیات ▼ ┌─────────────────────────────┐ │ موتور تولید ظرفیت │ │ Capacity Generation Engine │ └──────────────┬──────────────┘ ▼ ظرفیت مستقل روت‌ها │ ▼ ┌─────────────────────────────┐ │ موتور حل شبکه │ │ Network Optimization Engine │ └──────────────┬──────────────┘ ▼ ظرفیت بهینه کل شبکه │ ▼ ┌─────────────────────────────┐ │ موتور تخصیص ظرفیت │ │ Capacity Allocation Engine │ └──────────────┬──────────────┘ ▼ ┌─────────────────────────────┐ │ بازارگاه / حراج ظرفیت │ │ Rail Capacity Marketplace │ └──────────────┬──────────────┘ ▼ برنامه حمل بار بنابراین سه مفهوم باید کاملاً از یکدیگر جدا باشند: ۳.۱ ظرفیت تولیدشده ظرفیتی که شبکه از نظر فنی و عملیاتی قادر به ایجاد آن است. ۳.۲ ظرفیت بهینه‌شده ظرفیتی که با درنظرگرفتن رقابت روت‌ها و گلوگاه‌های مشترک، می‌توان در کل شبکه به‌صورت همزمان ایجاد کرد. ۳.۳ ظرفیت تخصیص‌یافته ظرفیتی که پس از تصمیم‌گیری درباره تقاضا، مشتریان، قراردادها، مزایده یا سیاست‌های تخصیص به هر متقاضی اختصاص می‌یابد. ۴. اصول بنیادین مدل ۴.۱ روت یک موجودیت مستقل از وضعیت خط است روت مبدأ–مقصد یک مفهوم تجاری و عملیاتی است. وضعیت بخش‌های مسیر ممکن است تغییر کند: Route R1 │ ├── Segment 1 → تک‌خطه ├── Segment 2 → تک‌خطه ├── Segment 3 → دوخطه ├── Segment 4 → دوخطه └── Segment 5 → تک‌خطه بنابراین دوخطه شدن یک Segment الزاماً به معنی ایجاد روت جدید نیست. ۵. اصل ظرفیت مشترک یکی از مهم‌ترین مفاهیم موتور، مفهوم ظرفیت مشترک است. فرض کنیم دو روت A و B از یک بخش مشترک عبور کنند: ┌──── Route A ─── مقصد A │ مبدأ ── Block X ──┤ │ └──── Route B ─── مقصد B اگر ظرفیت Block X برابر ۱۰۰ قطار باشد، نمی‌توان برای هر روت به‌طور مستقل ۱۰۰ قطار ظرفیت منظور کرد. باید برقرار باشد: Flow(A,X) + Flow(B,X) ≤ Capacity(X) این مفهوم پایه موتور حل شبکه است. ۶. ظرفیت روت به‌عنوان تابع شبکه ظرفیت واقعی روت را می‌توان به‌صورت مفهومی چنین نمایش داد: C(Route) = f(Infrastructure, Signaling, Block, Station, Train, Speed, Time, Operation, Fleet, Demand) در نتیجه ظرفیت یک روت مستقل از شرایط سایر روت‌ها نیست. ۷. سطوح مختلف ظرفیت سامانه باید حداقل پنج سطح ظرفیت را از هم تفکیک کند. ۷.۱ ظرفیت نظری حداکثر ظرفیت در شرایط کاملاً ایده‌آل. ۷.۲ ظرفیت فنی ظرفیتی که با مشخصات واقعی خط، بلاک، سرعت، طول قطار و زیرساخت قابل محاسبه است. ۷.۳ ظرفیت عملیاتی ظرفیتی که محدودیت‌های واقعی بهره‌برداری نیز در آن لحاظ شده است. ۷.۴ ظرفیت قابل عرضه ظرفیتی که پس از اعمال سیاست‌ها، حاشیه اطمینان و محدودیت‌های مدیریتی برای بازار قابل عرضه است. ۷.۵ ظرفیت قابل تخصیص ظرفیتی که پس از حل رقابت روت‌ها، تقاضا و محدودیت‌های شبکه می‌توان به متقاضیان تخصیص داد. ۸. معماری هفت‌ماژوله موتور از هفت ماژول اصلی تشکیل می‌شود: ماژول ۱ موتور محاسبه ظرفیت تک‌خطه ماژول ۲ موتور محاسبه ظرفیت دوخطه ماژول ۳ موتور محاسبه ظرفیت ترکیبی تک‌خطه–دوخطه ماژول ۴ موتور ظرفیت روت و مبدأ–مقصد ماژول ۵ موتور حل تعارض و بهینه‌سازی شبکه ماژول ۶ موتور تحلیل سناریو و حساسیت ماژول ۷ موتور نمایش و تحلیل جغرافیایی ظرفیت ماژول اول: موتور محاسبه ظرفیت تک‌خطه ۹. هدف این ماژول ظرفیت عبور قطار در یک مسیر تک‌خطه را با توجه به مشخصات واقعی زیرساخت و بهره‌برداری محاسبه می‌کند. در خط تک‌خطه، دو جریان مخالف نمی‌توانند بدون استفاده از سازوکارهای کنترل ترافیک، ایستگاه‌های عبوری و برنامه‌ریزی دقیق همزمان از یک بخش استفاده کنند. بنابراین ظرفیت به‌شدت به موارد زیر وابسته است: طول بلاک فاصله ایستگاه‌ها طول قطار سرعت قطار زمان اشغال بلاک زمان تخلیه بلاک زمان ورود و خروج زمان عبور از ایستگاه امکان تقاطع جهت حرکت فاصله زمانی ایمن الگوی حرکت قطارها ۱۰. ورودی‌های ماژول مشخصات زیرساخت طول Segment تعداد خطوط طول بلاک محل ایستگاه طول خطوط ایستگاه امکان عبور قطار امکان سبقت نوع علائم وضعیت سیستم سیگنالینگ محدودیت سرعت مشخصات قطار طول وزن تعداد واگن تعداد لکوموتیو بار یا خالی نوع قطار سرعت مجاز توان کشش مشخصات بهره‌برداری فاصله ایمنی حداقل Headway زمان توقف زمان تقاطع زمان تست ترمز زمان تشکیل قطار زمان اعزام ۱۱. زمان اشغال بلاک برای هر قطار باید زمان اشغال بلاک محاسبه شود. به‌صورت مفهومی: Block Occupancy Time = Running Time + Entry/Exit Time + Safety Margin و: Running Time = Distance / Effective Speed اما Effective Speed نباید صرفاً میانگین سرعت اعلام‌شده باشد. بلکه باید از پروفایل سرعت واقعی استخراج شود. ۱۲. Headway یکی از پارامترهای کلیدی: Headway = حداقل فاصله زمانی مجاز بین دو قطار این مقدار باید بر اساس: طول بلاک سرعت قطار سیستم سیگنالینگ جهت حرکت قوانین بهره‌برداری زمان تخلیه بلاک حاشیه ایمنی محاسبه شود. ۱۳. ظرفیت تک‌خطه در ساده‌ترین حالت: Capacity ≈ Available Time / Effective Headway اما در سامانه نهایی نباید به این فرمول ساده اکتفا کرد؛ زیرا خط تک‌خطه به‌خصوص در حرکت دوطرفه، مسئله‌ای زمان‌بندی‌شده و شبکه‌ای است. بنابراین مدل دقیق‌تر باید توالی قطارها را نیز بررسی کند. ۱۴. محدودیت‌های ویژه خط تک‌خطه موتور باید موارد زیر را لحاظ کند: تقاطع قطارهای مخالف محل مناسب تقاطع طول خطوط ایستگاه امکان پذیرش قطار زمان ورود و خروج زمان انتظار تأخیر قطارهای با سرعت متفاوت قطارهای باری و مسافری قطارهای خالی پنجره‌های زمانی ممنوع ماژول دوم: موتور محاسبه ظرفیت دوخطه ۱۵. هدف در خط دوخطه، امکان حرکت همزمان قطارها در دو جهت افزایش می‌یابد؛ اما این امر به معنای دو برابر شدن خودکار ظرفیت نیست. ظرفیت تابعی از: سیگنالینگ Headway سرعت تعداد خطوط جهت حرکت نقاط ادغام ایستگاه‌ها محدودیت‌های عملیاتی نوع قطار است. ۱۶. مدل مفهومی دوخطه خط ۱ A ═══════════════════════════ B خط ۲ A ═══════════════════════════ B ولی ممکن است در نقطه‌ای: Segment 1 → دوخطه Segment 2 → دوخطه Segment 3 → تک‌خطه Segment 4 → دوخطه در این حالت ظرفیت کل روت الزاماً برابر حداقل ظرفیت خام یک Segment نیست، زیرا رفتار عملیاتی قطارها در مرز تک‌خطه/دوخطه اهمیت پیدا می‌کند. ۱۷. ظرفیت دوخطه موتور باید ظرفیت هر جهت را مستقل محاسبه کند: Capacity(Direction A→B) و: Capacity(Direction B→A) سپس در صورت وجود محدودیت مشترک، ظرفیت عملیاتی ترکیبی محاسبه شود. این موضوع برای بارهای رفت و برگشت اهمیت زیادی دارد. ماژول سوم: موتور ظرفیت ترکیبی تک‌خطه–دوخطه ۱۸. اهمیت این ماژول این ماژول از نظر اقتصادی یکی از مهم‌ترین اجزای سیستم است. در بسیاری از پروژه‌های توسعه‌ای، ممکن است دوخطه کردن کل مسیر بسیار پرهزینه باشد، درحالی‌که دوخطه کردن بخشی از مسیر، همراه با ایجاد امکانات مناسب برای تجمع، انتظار و تشکیل قطار، بتواند افزایش قابل‌توجهی در ظرفیت ایجاد کند. ۱۹. مفهوم Segment هر روت باید به Segmentهای عملیاتی تقسیم شود. برای مثال: Route R1 A │ ├── S1: 45 km تک‌خطه │ ├── S2: 30 km دوخطه │ ├── S3: 60 km تک‌خطه │ ├── S4: 25 km دوخطه │ └── S5: 40 km تک‌خطه │ B موتور باید برای هر Segment ظرفیت مستقل و اثر آن بر کل روت را محاسبه کند. ۲۰. نقطه دوخطه شدن به‌عنوان نقطه عملیاتی در محل تبدیل تک‌خطه به دوخطه باید اطلاعات زیر وجود داشته باشد: ظرفیت ایستگاه ظرفیت خط‌های جانبی فضای توقف امکان تجمع واگن امکان تشکیل قطار ظرفیت مانور ظرفیت لکوموتیو زمان مجاز انتظار امکان سبقت امکان تغییر ترتیب واگن‌ها ۲۱. ظرفیت قابل بازیابی یکی از شاخص‌های مهم این ماژول: چه مقدار از ظرفیت محدودشده توسط بخش تک‌خطه را می‌توان با عملیات مناسب در بخش دوخطه جبران کرد؟ به این ترتیب سیستم فقط نمی‌پرسد: «آیا دوخطه کنیم؟» بلکه می‌پرسد: «با چه ترکیبی از توسعه زیرساخت و اصلاح عملیات می‌توان بیشترین ظرفیت را ایجاد کرد؟» ماژول چهارم: موتور ظرفیت روت و مبدأ–مقصد ۲۲. تعریف روت روت عبارت است از مسیر عملیاتی مشخص بین یک مبدأ بار و مقصد بار. مثلاً: سرخس → آپرین اینچه‌برون → گرمسار → آپرین سرخس → بافق → بندرعباس سرخس → بافق → فولاد آپرین → بندرامام آپرین → رازی برای یک OD ممکن است بیش از یک روت تعریف شود. ۲۳. ورود اطلاعات تقاضای بار سامانه ابتدا باید اطلاعات تقاضای بار را دریافت کند: مبدأ مقصد نوع کالا تناژ بازه زمانی تعداد محموله اولویت محدودیت زمانی نوع واگن تناژ هر واگن تناژ هر قطار سپس ODهای واقعی استخراج می‌شوند. ۲۴. نگاشت OD به Route برای هر OD: OD ↓ Route 1 Route 2 Route 3 ... ممکن است یک OD چند مسیر جایگزین داشته باشد. بنابراین سامانه نباید از ابتدا یک Route قطعی را به بار تحمیل کند. ۲۵. ظرفیت مستقل هر روت برای هر روت: Route Capacity = Capacity constrained by its critical resources اما ظرفیت باید با توجه به همه منابع محاسبه شود: زیرساخت + بلاک + ایستگاه + زمان + ناوگان + عملیات + تقاضا ۲۶. روت‌های مشترک و رقیب مثلاً: Route A ────────┐ │ ▼ Common Block X ▲ │ Route B ────────┘ در اینجا A و B رقیب ظرفیت Block X هستند. سامانه باید تمام این روابط را به‌صورت گراف استخراج کند. ۲۷. ظرفیت کل روت‌ها پس از محاسبه ظرفیت مستقل، موتور باید روابط مشترک را شناسایی کند. برای مثال: A = 300 B = 220 C = 180 D = 150 ظرفیت مستقل: 850 قطار ولی به‌دلیل اشتراک گلوگاه‌ها ممکن است ظرفیت قابل تحقق: 630 قطار باشد. بنابراین: مجموع ظرفیت مستقل روت‌ها ≠ ظرفیت شبکه ماژول پنجم: موتور حل تعارض و بهینه‌سازی شبکه ۲۸. قلب سامانه این ماژول مهم‌ترین بخش الگوریتمی محصول است. هدف آن: یافتن ترکیبی از جریان‌های بار و قطار که بیشترین ظرفیت قابل حمل را در کل شبکه ایجاد کند، بدون نقض هیچ‌یک از محدودیت‌های زیرساختی و عملیاتی. ۲۹. نمایش شبکه به‌صورت گراف شبکه به شکل گراف مدل می‌شود: G = (V,E) که در آن: V = ایستگاه‌ها، نقاط عملیاتی، تقاطع‌ها و نقاط کنترلی E = Segmentها، بلاک‌ها و ارتباطات شبکه هر Edge دارای ظرفیت است. ۳۰. محدودیت‌های اصلی مدل محدودیت ظرفیت Segment Flow(e) ≤ Capacity(e) محدودیت بلاک Flow(b) ≤ Capacity(b) محدودیت ایستگاه Flow(s) ≤ Capacity(s) محدودیت زمانی Flow(t) ≤ Capacity(t) محدودیت تقاضا Flow(r) ≤ Demand(r) محدودیت ناوگان Trains ≤ Available Rolling Stock محدودیت واگن Wagons ≤ Available Wagons ۳۱. تابع هدف سیستم باید امکان تعریف چند تابع هدف داشته باشد. حالت اول: حداکثرسازی تناژ Maximize Total Tons حالت دوم: حداکثرسازی Ton-km Maximize Ton-Km حالت سوم: حداکثرسازی ارزش اقتصادی Maximize Economic Value حالت چهارم: حداکثرسازی تعداد قطار Maximize Train Movements حالت پنجم: ترکیبی مثلاً: Objective = α(Tons) + β(Ton-Km) + γ(Economic Value) ضرایب باید قابل تنظیم باشند. ۳۲. سیاست حفظ روت‌ها گاهی بیشینه‌سازی کل تناژ ممکن است باعث شود تمام ظرفیت یک گلوگاه به یک روت اختصاص پیدا کند. اما سیاست شبکه ممکن است حفظ حداقل ظرفیت سایر روت‌ها را ضروری بداند. بنابراین می‌توان قید ایجاد کرد: Flow(Route A) ≥ Minimum Share(A) و برای روت B: Flow(Route B) ≥ Minimum Share(B) این پارامتر باید توسط مدیر سامانه قابل تنظیم باشد. ۳۳. ظرفیت آزاد ناشی از کمبود تقاضا یکی از قواعد مهم: اگر ظرفیت Route A برابر ۳۰۰ قطار باشد اما تقاضای واقعی آن فقط ۱۸۰ قطار باشد، ۱۲۰ قطار ظرفیت آزاد ایجاد می‌شود. سیستم باید بتواند بررسی کند: آیا این ظرفیت آزاد می‌تواند بدون نقض سایر قیود به Route B منتقل شود؟ اگر پاسخ مثبت باشد، ظرفیت شبکه افزایش می‌یابد. ۳۴. اولویت‌های حل سامانه باید بتواند چند حالت را اجرا کند: سناریوی حداکثر بار بیشترین تناژ ممکن. سناریوی حداکثر ارزش بیشترین ارزش اقتصادی. سناریوی حفظ شبکه حفظ حداقل سهم روت‌های مشخص. سناریوی سیاستی اعمال سیاست‌های مدیر شبکه. سناریوی ترکیبی ترکیب چند هدف با وزن‌دهی. ماژول ششم: موتور تحلیل سناریو و حساسیت ۳۵. هدف این ماژول پاسخ می‌دهد: «اگر در شبکه تغییری ایجاد کنیم، ظرفیت چقدر تغییر می‌کند؟» این تغییر می‌تواند: دوخطه کردن خط احداث خط جدید افزایش طول ایستگاه تغییر سرعت مجاز اصلاح سیگنالینگ افزایش ظرفیت ایستگاه ایجاد محل تجمع واگن افزایش لکوموتیو افزایش واگن تغییر برنامه حرکت تغییر زمان توقف باشد. ۳۶. سناریوی Base ابتدا وضعیت فعلی شبکه محاسبه می‌شود: ظرفیت فعلی: X قطار Y میلیون تن Z میلیارد تن-کیلومتر سپس سناریو تغییر می‌کند. ۳۷. سناریوی توسعه مثلاً: سناریو ۱: دوخطه کردن ۲۰ کیلومتر سناریو ۲: دوخطه کردن ۴۰ کیلومتر سناریو ۳: دوخطه کردن ۲۰ کیلومتر + افزایش ظرفیت ایستگاه سناریو ۴: دوخطه کردن ۲۰ کیلومتر + تغییر سیگنالینگ + افزایش ظرفیت ایستگاه ۳۸. شاخص ارزش سرمایه‌گذاری برای هر سناریو: Investment Cost در برابر: Additional Capacity محاسبه می‌شود. سپس: Capacity Gain / Investment به‌عنوان یکی از شاخص‌های مقایسه سناریوها محاسبه می‌شود. همچنین می‌توان: افزایش تناژ افزایش Ton-km افزایش درآمد کاهش زمان سیر کاهش گلوگاه افزایش قابلیت اطمینان را نیز محاسبه کرد. ۳۹. تحلیل حساسیت سیستم باید بتواند نشان دهد اگر یک پارامتر تغییر کند چه اتفاقی می‌افتد. مثلاً: سرعت +۵٪ ↓ زمان سیر -X٪ ↓ Headway -Y٪ ↓ ظرفیت +Z قطار یا: طول ایستگاه +۲۰٪ ↓ افزایش طول قطار قابل پذیرش ↓ افزایش ظرفیت عملیاتی ۴۰. تحلیل گلوگاه یکی از مهم‌ترین خروجی‌های تحلیل حساسیت: اگر فقط یک عامل را اصلاح کنیم، کدام عامل بیشترین ظرفیت جدید ایجاد می‌کند؟ مثلاً: مداخله هزینه ظرفیت جدید دوخطه کردن A X +10 اصلاح سیگنالینگ B Y +7 توسعه ایستگاه C Z +15 افزایش ناوگان W +4 این جدول مبنای تصمیم‌گیری سرمایه‌گذاری قرار می‌گیرد. ماژول هفتم: موتور نمایش و تحلیل جغرافیایی ظرفیت ۴۱. ضرورت GIS ظرفیت شبکه یک مفهوم مکانی است. بنابراین نتایج موتور باید روی نقشه نمایش داده شوند. کاربر باید بتواند وضعیت را در سطح: کل شبکه کریدور روت Segment بلاک ایستگاه مبدأ مقصد مشاهده کند. ۴۲. نمایش گلوگاه‌ها برای مثال: سبز ظرفیت آزاد زرد نزدیک اشباع قرمز گلوگاه بنفش تعارض چند روت آبی مسیر توسعه‌ای هر Segment باید اطلاعات زیر را نمایش دهد: ظرفیت ظرفیت مصرف‌شده ظرفیت آزاد درصد اشباع تعداد روت‌های عبوری تعداد ODهای وابسته تناژ عبوری گلوگاه بودن یا نبودن ۴۳. نمایش مرحله‌ای کاربر باید بتواند فرآیند حل را مرحله‌به‌مرحله مشاهده کند. مرحله ۱ نمایش شبکه پایه مرحله ۲ نمایش ODها مرحله ۳ نمایش Routeها مرحله ۴ نمایش Segmentها مرحله ۵ نمایش ظرفیت مستقل مرحله ۶ نمایش بخش‌های مشترک مرحله ۷ نمایش تعارض‌ها مرحله ۸ اجرای Optimization مرحله ۹ نمایش ظرفیت بهینه مرحله ۱۰ نمایش سناریوی توسعه این قابلیت برای اعتمادپذیری سیستم بسیار مهم است؛ زیرا کاربر باید بتواند بفهمد چرا سیستم به یک عدد مشخص رسیده است. ۴۴. مفهوم Explainable Capacity هر عدد ظرفیت باید قابل توضیح باشد. مثلاً اگر سامانه اعلام کند: Route A = ۲۴۰ قطار در ماه کاربر بتواند روی عدد کلیک کند و ببیند: ظرفیت نظری 320 محدودیت تک‌خطه -35 محدودیت ایستگاه -15 محدودیت زمان نماز -8 تست ترمز -7 سوختگیری -5 محدودیت مشترک -10 حاشیه عملیاتی -0 -------------------------------- ظرفیت نهایی 240 این ویژگی برای پذیرش سازمانی موتور بسیار مهم است. ۴۵. مدل داده پیشنهادی موجودیت‌های اصلی: Infrastructure Railway Route Segment Block Station Yard Signal Passing Loop Rolling Stock Locomotive Wagon Train Type Consist Operation Schedule Time Window Headway Stop Crossing Maintenance Window Demand Origin Destination Commodity Demand OD Pair Capacity Segment Capacity Block Capacity Station Capacity Route Capacity Network Capacity Optimization Scenario Constraint Objective Solution Sensitivity Analysis ۴۶. زنجیره داده فرآیند اصلی: Infrastructure Data ↓ Operational Data ↓ Rolling Stock Data ↓ Demand Data ↓ Route Definition ↓ Segment Definition ↓ Capacity Calculation ↓ Conflict Detection ↓ Network Optimization ↓ Scenario Analysis ↓ Capacity Output ↓ Allocation / Auction ۴۷. خروجی‌های اصلی موتور سامانه باید حداقل خروجی‌های زیر را تولید کند: خروجی شبکه ظرفیت کل شبکه ظرفیت هر کریدور گلوگاه‌ها ظرفیت آزاد خروجی روت ظرفیت روت تعداد قطار تناژ Ton-km درصد اشغال خروجی OD تقاضا ظرفیت قابل تأمین ظرفیت تأمین‌شده ظرفیت کمبود خروجی سرمایه‌گذاری گلوگاه هزینه اصلاح ظرفیت پس از اصلاح ظرفیت افزوده ارزش اقتصادی ۴۸. اتصال به موتور تخصیص و بازارگاه ریلی این موتور باید API مشخصی برای موتور بعدی ارائه کند. برای مثال: GET RouteCapacity GET NetworkCapacity GET AvailableCapacity GET ODCapacity GET Bottlenecks GET ScenarioCapacity و موتور تخصیص بتواند سؤال کند: در بازه زمانی مشخص، برای OD مشخص و با شرایط مشخص، چه مقدار ظرفیت قطار قابل عرضه است؟ پاسخ موتور: Route: A Available Trains: 85 Available Tons: 5,695,000 Time Window: ... Reliability: ... Constraints: ... ۴۹. رابطه با بازارگاه ریلی پس از تولید ظرفیت: ظرفیت شبکه ↓ ظرفیت قابل عرضه ↓ بازارگاه ↓ تقاضای صاحبان بار / فورواردرها ↓ موتور تخصیص ↓ برنامه قطار در نتیجه بازارگاه نباید ظرفیت را خودش محاسبه کند. بازارگاه مصرف‌کننده خروجی موتور ظرفیت است. ۵۰. شاخص‌های کلیدی عملکرد موتور حداقل KPIهای زیر پیشنهاد می‌شود: Capacity KPIs Train Capacity Ton Capacity Ton-km Capacity Utilization Bottleneck Utilization Operational KPIs Average Headway Average Transit Time Delay Reliability Crossing Time Network KPIs Number of Bottlenecks Shared Block Utilization Route Competition Unused Capacity Investment KPIs Capacity Gain Cost per Additional Ton Cost per Additional Train Additional Ton-km Economic Return ۵۱. سناریوی نمونه فرض کنیم: Route A ظرفیت مستقل = 300 قطار Route B ظرفیت مستقل = 220 قطار Route C ظرفیت مستقل = 180 قطار اما A و B از Block X استفاده می‌کنند: Capacity(Block X) = 350 و B و C از Block Y: Capacity(Block Y) = 280 در نتیجه: A + B ≤ 350 B + C ≤ 280 سامانه باید با توجه به تقاضا و تابع هدف، ترکیب بهینه را پیدا کند. اگر: Demand A = 250 Demand B = 150 Demand C = 150 باشد، سیستم می‌تواند بررسی کند که چه ترکیبی بیشترین تناژ یا ارزش اقتصادی را ایجاد می‌کند. ۵۲. سیاست‌های قابل تنظیم مدیر سیستم باید بتواند پارامترهایی مانند موارد زیر را تنظیم کند: حداقل سهم روت حداکثر سهم روت اولویت کالا اولویت کریدور ظرفیت رزرو حاشیه ایمنی ظرفیت اضطراری ظرفیت اختصاص‌یافته به مسافر پنجره‌های تعمیراتی زمان‌های ممنوع سیاست حفظ مسیر این پارامترها نباید در کد نرم‌افزار Hard Code شوند. ۵۳. مدیریت عدم قطعیت ظرفیت واقعی همواره قطعی نیست. بنابراین بهتر است خروجی به شکل: Nominal Capacity و Reliable Capacity ارائه شود. مثلاً: ظرفیت محاسباتی: 300 قطار ظرفیت قابل اتکا: 270 قطار تفاوت ناشی از: تأخیر خرابی محدودیت ناوگان تعمیرات نوسانات عملیات عدم قطعیت زمان سیر است. ۵۴. مفهوم ظرفیت رزرو ممکن است سیستم بخشی از ظرفیت را برای شرایط غیرمنتظره کنار بگذارد: ظرفیت کل 300 ظرفیت رزرو 20 ظرفیت قابل عرضه 280 این موضوع خصوصاً برای بازارگاه اهمیت دارد. ۵۵. خروجی برای مدیریت عالی موتور باید بتواند یک داشبورد مدیریتی تولید کند: ظرفیت کل شبکه ↓ ظرفیت قابل عرضه ↓ ظرفیت مصرف‌شده ↓ ظرفیت آزاد ↓ گلوگاه‌های اصلی ↓ پروژه‌های افزایش ظرفیت ↓ هزینه سرمایه‌گذاری ↓ ظرفیت افزوده ۵۶. مفهوم بسیار مهم «ظرفیت تولید نشده به دلیل گلوگاه» سیستم باید بتواند علاوه بر ظرفیت موجود، ظرفیت از دست‌رفته را نیز محاسبه کند. مثلاً: تقاضای بالقوه 10 میلیون تن ظرفیت زیرساختی 8 میلیون تن محدودیت ایستگاه 1 میلیون تن محدودیت ناوگان 0.5 میلیون تن ظرفیت قابل تحقق 6.5 میلیون تن در این صورت مدیر متوجه می‌شود که مسئله فقط «کمبود خط» نیست. ۵۷. نقشه ظرفیت بالقوه یکی از خروجی‌های مهم سامانه باید: Potential Freight Capacity Map باشد. در آن مشخص شود: کجا ظرفیت آزاد وجود دارد؟ کجا تقاضای پاسخ‌داده‌نشده وجود دارد؟ کجا گلوگاه وجود دارد؟ کجا یک سرمایه‌گذاری کوچک ظرفیت زیادی آزاد می‌کند؟ کجا ظرفیت موجود به دلیل نبود بار بلااستفاده است؟ ۵۸. اصل مهم: ظرفیت شبکه تابع تقاضا نیز هست اگر شبکه ظرفیت ۱۰۰۰ قطار داشته باشد اما تقاضا ۶۰۰ قطار باشد، ظرفیت حمل تحقق‌یافته ۱۰۰۰ قطار نیست. بنابراین باید سه مفهوم جدا شود: Technical Capacity Marketable Capacity Demand-Constrained Capacity این تفکیک برای تحلیل اقتصادی بسیار مهم است. ۵۹. ارتباط ظرفیت با ناوگان حتی اگر زیرساخت ظرفیت ۱۰۰۰ قطار ایجاد کند، ممکن است ناوگان فقط امکان تأمین ۷۰۰ قطار را داشته باشد. بنابراین: Realizable Capacity = min(Infrastructure Capacity, Fleet Capacity, Demand Capacity, Operational Capacity) اما در مدل شبکه‌ای، این Minimum باید در سطح منابع مشترک و زمان‌بندی نیز محاسبه شود. ۶۰. ظرفیت قطار و ظرفیت تناژ موتور نباید فقط تعداد قطار را خروجی دهد. برای هر Train: Train Payload = Number of Wagons × Net Payload per Wagon و سپس: Route Tons = Number of Trains × Payload per Train بنابراین دو روت با ظرفیت یکسان قطار ممکن است ظرفیت تناژی کاملاً متفاوت داشته باشند. ۶۱. ظرفیت در جهت رفت و برگشت سامانه باید ظرفیت را جهت‌دار محاسبه کند: A → B = 200 trains B → A = 140 trains و سپس بررسی کند: آیا واگن برگشتی وجود دارد؟ آیا قطار خالی لازم است؟ آیا ظرفیت برگشت قابل استفاده است؟ آیا عدم تعادل جریان واگن وجود دارد؟ این موضوع موتور را مستقیماً به مسئله بهره‌وری گردش واگن متصل می‌کند. ۶۲. تعامل با موتور واگن در معماری نهایی: Capacity Engine ↕ Wagon Circulation Engine ↕ Locomotive Allocation Engine زیرا ظرفیت زیرساخت بدون ناوگان قابل تحقق نیست. ۶۳. اصل «تولید ظرفیت» در برابر «مصرف ظرفیت» ظرفیت یک محصول قابل مشاهده و قابل معامله است. بنابراین می‌توان آن را به‌صورت: Capacity Supply ↓ Capacity Marketplace ↓ Capacity Demand ↓ Capacity Allocation ↓ Actual Utilization مدل کرد. ۶۴. چرخه بازخورد پس از اجرای برنامه واقعی، داده واقعی باید به موتور برگردد. ظرفیت محاسبه‌شده ↓ برنامه حمل ↓ اجرای واقعی ↓ داده واقعی ↓ مقایسه پیش‌بینی و واقعیت ↓ اصلاح پارامترها ↓ ظرفیت دقیق‌تر در نتیجه موتور به‌مرور کالیبره می‌شود. ۶۵. قابلیت یادگیری و بهبود در مراحل بعدی می‌توان از داده تاریخی برای تخمین: زمان واقعی سیر احتمال تأخیر زمان واقعی توقف احتمال خرابی زمان واقعی تشکیل قطار بهره‌وری ایستگاه احتمال اشغال گلوگاه استفاده کرد. در این حالت موتور از یک سیستم Static به یک سیستم Dynamic Capacity Engine تبدیل می‌شود. ۶۶. معماری نهایی پیشنهادی ┌───────────────────────┐ │ Infrastructure DB │ └───────────┬───────────┘ │ ┌───────────▼───────────┐ │ Rolling Stock DB │ └───────────┬───────────┘ │ ┌───────────▼───────────┐ │ Demand / OD DB │ └───────────┬───────────┘ │ ┌───────────▼───────────┐ │ Route Management │ └───────────┬───────────┘ │ ┌─────────────────────▼────────────────────┐ │ CAPACITY GENERATION ENGINE │ │ │ │ M1 ─ Single Track Capacity │ │ M2 ─ Double Track Capacity │ │ M3 ─ Mixed Track Capacity │ │ M4 ─ Route / OD Capacity │ │ M5 ─ Network Optimization │ │ M6 ─ Scenario / Sensitivity │ │ M7 ─ GIS / Visualization │ └─────────────────────┬────────────────────┘ │ ▼ Network Capacity │ ▼ Available Capacity │ ▼ Capacity Allocation Engine │ ▼ Rail Capacity Marketplace │ ▼ Actual Operations │ ▼ Actual Performance │ └──────► Feedback ۶۷. نتیجه‌گیری این موتور در واقع باید به‌عنوان هسته محاسباتی مدیریت ظرفیت شبکه حمل بار ریلی طراحی شود. هدف آن صرفاً محاسبه تعداد قطار قابل عبور نیست. هدف نهایی عبارت است از: شناخت ظرفیت واقعی شبکه، شناسایی گلوگاه‌ها، کشف ظرفیت پنهان، بهینه‌سازی همزمان روت‌های رقیب، سنجش اثر تغییرات زیرساختی و عملیاتی و تبدیل ظرفیت شبکه به ظرفیت قابل عرضه برای بازار حمل بار. از این منظر، هفت ماژول فوق یک زنجیره منطقی تشکیل می‌دهند: ۱. ظرفیت تک‌خطه ↓ ۲. ظرفیت دوخطه ↓ ۳. ظرفیت ترکیبی تک‌خطه–دوخطه ↓ ۴. ظرفیت روت و OD ↓ ۵. حل تعارض و بهینه‌سازی کل شبکه ↓ ۶. تحلیل سناریو و حساسیت ↓ ۷. نمایش جغرافیایی و مدیریتی و خروجی نهایی این زنجیره: ظرفیت قابل اتکا، قابل عرضه و قابل تخصیص شبکه ریلی در هر بازه زمانی و برای هر مبدأ–مقصد است. این خروجی سپس می‌تواند مستقیماً وارد موتور تخصیص ظرفیت و بازارگاه ریلی شود. ۶۸. گام بعدی توسعه فنی برای تبدیل این سند مفهومی به سند واقعاً قابل ساخت نرم‌افزار، مرحله بعد باید برای هر یک از هفت ماژول این موارد به‌صورت جداگانه تعریف شود: فهرست کامل ورودی‌ها ساختار جداول دیتابیس روابط بین جداول متغیرهای تصمیم پارامترهای ثابت و قابل تنظیم فرمول‌های محاسباتی قیود تابع هدف الگوریتم حل شبه‌کد APIها�� ورودی و خروجی نمونه داده واقعی نمونه محاسبه سناریوهای خطا KPIها خروجی GIS داشبورد مدیریتی ارتباط با سامانه اطلاعات پایه زیرساخت ارتباط با سامانه تعمیرات خط ارتباط با سامانه ناوگان ارتباط با بازارگاه و حراج ظرفیت روش اعتبارسنجی نتایج در این مرحله، سند از یک پروپوزال مفهومی به یک Software Requirements & Algorithm Specification تبدیل می‌شود؛ و به‌نظر من همین باید مبنای طراحی واقعی نرم‌افزار قرار بگیرد. --- ## Prompt 4 — پرسش کاربر (`conversation-turn-7`) یک واژه‌نامه استاندارد برایم اضافه کن ## Prompt 4 — پاسخ دستیار (`conversation-turn-8`) حتماً. برای اینکه سند از نظر فنی و قراردادی هم استانداردتر شود، پیشنهاد می‌کنم واژه‌نامه را در انتهای سند اصلی اضافه کنیم و اصطلاحات فارسی، معادل انگلیسی و تعریف عملیاتی آنها را یکجا تثبیت کنیم. ۶۹. واژه‌نامه استاندارد موتور تولید، برآورد و بهینه‌سازی ظرفیت حمل بار ریلی ردیف اصطلاح فارسی معادل انگلیسی تعریف عملیاتی در سامانه 1 ظرفیت Capacity حداکثر میزان جریان قطار یا بار که یک منبع، مسیر یا شبکه در شرایط مشخص قادر به پذیرش یا عبور آن است. 2 تولید ظرفیت Capacity Generation فرآیند محاسبه ظرفیت قابل ایجاد بر اساس زیرساخت، عملیات، زمان و سایر محدودیت‌ها. 3 برآورد ظرفیت Capacity Estimation محاسبه ظرفیت مورد انتظار بر مبنای داده‌ها و فرضیات مشخص. 4 ظرفیت نظری Theoretical Capacity ظرفیت محاسبه‌شده در شرایط ایده‌آل و بدون بسیاری از محدودیت‌های عملیاتی. 5 ظرفیت فنی Technical Capacity ظرفیتی که بر اساس مشخصات واقعی زیرساخت و تجهیزات قابل دستیابی است. 6 ظرفیت عملیاتی Operational Capacity ظرفیت پس از اعمال محدودیت‌ها و قواعد واقعی بهره‌برداری. 7 ظرفیت قابل عرضه Marketable / Offered Capacity بخشی از ظرفیت عملیاتی که پس از اعمال سیاست‌ها و حاشیه اطمینان برای عرضه به بازار آماده است. 8 ظرفیت قابل تخصیص Allocable Capacity ظرفیتی که پس از حل تعارض‌ها و محدودیت‌های شبکه می‌توان به متقاضیان اختصاص داد. 9 ظرفیت قابل اتکا Reliable Capacity ظرفیتی که با سطح اطمینان مشخص، قابلیت تحقق در عملیات واقعی را دارد. 10 ظرفیت مصرف‌شده Used Capacity مقدار ظرفیتی که عملاً توسط جریان قطار یا بار مصرف شده است. 11 ظرفیت آزاد Available / Spare Capacity ظرفیت باقیمانده پس از کسر ظرفیت مصرف‌شده از ظرفیت قابل استفاده. 12 ظرفیت از دست‌رفته Lost Capacity ظرفیتی که به دلیل گلوگاه، محدودیت عملیاتی، کمبود ناوگان یا سایر عوامل قابل استفاده نیست. 13 ظرفیت پنهان Hidden Capacity ظرفیتی که در شبکه موجود است اما به دلیل ضعف برنامه‌ریزی یا بهره‌برداری به‌طور کامل استفاده نمی‌شود. 14 شبکه ریلی Railway Network مجموعه خطوط، بلاک‌ها، ایستگاه‌ها، گلوگاه‌ها و سایر عناصر مرتبط با حرکت قطار. 15 روت Route مسیر عملیاتی تعریف‌شده بین یک مبدأ و مقصد مشخص که می‌تواند از چند Segment تشکیل شود. 16 روت مبدأ–مقصد Origin–Destination Route مسیر یا مسیرهای قابل استفاده برای انتقال بار از یک مبدأ مشخص به مقصد مشخص. 17 مبدأ Origin نقطه‌ای که جریان بار یا قطار از آن آغاز می‌شود. 18 مقصد Destination نقطه نهایی انتقال بار یا قطار. 19 جفت مبدأ–مقصد OD Pair ترکیب مشخص یک مبدأ و یک مقصد برای تحلیل جریان بار. 20 جریان بار Freight Flow مقدار بار یا تعداد قطارهایی که بین یک مبدأ و مقصد حرکت می‌کنند. 21 کریدور Corridor مجموعه‌ای از مسیرهای ریلی مرتبط که یک جریان اصلی حمل‌ونقل را تشکیل می‌دهند. 22 Segment Segment بخش مشخص و نسبتاً همگن از یک روت که ویژگی‌های زیرساختی و عملیاتی آن قابل تعریف است. 23 بلاک Block بخش کنترل‌شده‌ای از خط که اشغال آن توسط قطار تابع قواعد ایمنی و کنترل ترافیک است. 24 بلاک مشترک Shared Block بلاکی که همزمان در بیش از یک روت یا جریان بار مورد استفاده قرار می‌گیرد. 25 گلوگاه Bottleneck منبع یا بخش شبکه‌ای که ظرفیت آن محدودکننده ظرفیت کل جریان یا شبکه است. 26 گلوگاه مشترک Shared Bottleneck گلوگاهی که چند روت یا جریان بار برای استفاده از آن با یکدیگر رقابت می‌کنند. 27 خط تک‌خطه Single Track مسیری که یک خط اصلی برای حرکت قطارها دارد و حرکت دوطرفه نیازمند مدیریت تقاطع است. 28 خط دوخطه Double Track مسیری که دو خط اصلی برای حرکت قطارها، معمولاً در دو جهت، در اختیار دارد. 29 بخش تک‌خطه Single-Track Segment Segmentای که دارای یک خط اصلی است. 30 بخش دوخطه Double-Track Segment Segmentای که دارای دو خط اصلی است. 31 مسیر ترکیبی Mixed Single/Double Track Route روتی که از ترکیب بخش‌های تک‌خطه و دوخطه تشکیل شده است. 32 دوخطه‌سازی Double-Tracking ایجاد خط دوم در یک بخش تک‌خطه با هدف افزایش ظرفیت یا بهبود بهره‌برداری. 33 Headway Headway حداقل فاصله زمانی مجاز بین حرکت دو قطار متوالی تحت شرایط مشخص. 34 زمان اشغال بلاک Block Occupancy Time مدت زمانی که یک قطار یک بلاک را در اختیار دارد یا آن را از نظر بهره‌برداری اشغال می‌کند. 35 زمان سیر Running / Travel Time زمان لازم برای طی مسیر بین دو نقطه، با توجه به پروفایل حرکت قطار. 36 زمان توقف Dwell Time مدت توقف قطار در ایستگاه یا نقطه عملیاتی. 37 زمان تقاطع Crossing Time زمان لازم برای انجام تقاطع دو قطار در مسیر تک‌خطه. 38 زمان سبقت Overtaking Time زمان لازم برای انجام سبقت یک قطار از قطار دیگر. 39 پروفایل سرعت Speed Profile الگوی سرعت قطار در طول مسیر یا Segmentهای مختلف آن. 40 سرعت مجاز Permitted Speed بیشترین سرعت مجاز بر اساس مشخصات خط، مقررات و شرایط بهره‌برداری. 41 سرعت مؤثر Effective Speed سرعتی که در محاسبات ظرفیت و زمان سیر با درنظرگرفتن محدودیت‌های واقعی استفاده می‌شود. 42 قطار باری Freight Train قطاری که برای حمل بار تشکیل شده است. 43 قطار خالی Empty Train قطاری که بدون بار تجاری یا با بار ناچیز نسبت به ظرفیت اسمی حرکت می‌کند. 44 ترکیب قطار Train Consist آرایش لکوموتیوها و واگن‌های تشکیل‌دهنده یک قطار. 45 طول قطار Train Length طول کلی ترکیب قطار از ابتدای اولین وسیله تا انتهای آخرین وسیله. 46 وزن قطار Train Weight مجموع وزن لکوموتیوها، واگن‌ها و بار قطار. 47 ظرفیت بارگیری قطار Train Payload Capacity حداکثر وزن بار قابل حمل توسط یک قطار تحت شرایط تعیین‌شده. 48 تناژ خالص Net Tonnage وزن بار تجاری حمل‌شده بدون احتساب وزن واگن و لکوموتیو. 49 تناژ ناخالص Gross Tonnage مجموع وزن بار، واگن‌ها و لکوموتیوها. 50 واگن Wagon وسیله ریلی مورد استفاده برای حمل بار. 51 لکوموتیو Locomotive وسیله کشنده قطار. 52 ظرفیت ناوگان Fleet Capacity مقدار ظرفیتی که با توجه به تعداد، قابلیت دسترسی و عملکرد ناوگان قابل ایجاد است. 53 دسترس‌پذیری ناوگان Fleet Availability درصد یا مقدار زمانی که ناوگان برای بهره‌برداری در دسترس است. 54 گردش واگن Wagon Turnaround / Circulation چرخه زمانی و عملیاتی واگن از یک بارگیری تا آماده‌شدن مجدد برای بارگیری بعدی. 55 ایستگاه Station نقطه عملیاتی شبکه که امکان توقف، پذیرش، عبور، تشکیل یا تفکیک قطار در آن وجود دارد. 56 خط ایستگاه Station Track خطی داخل محدوده ایستگاه که برای عبور، توقف یا عملیات قطار استفاده می‌شود. 57 خط عبوری Passing Loop خطی که امکان عبور یا توقف قطار برای فراهم‌کردن حرکت قطار دیگر را فراهم می‌کند. 58 ظرفیت ایستگاه Station Capacity حداکثر میزان عملیات قطار که ایستگاه در یک بازه زمانی می‌تواند انجام دهد. 59 ظرفیت عملیاتی ایستگاه Operational Station Capacity ظرفیت ایستگاه با لحاظ زمان توقف، مانور، تشکیل قطار، تقاطع و سایر عملیات. 60 تشکیل قطار Train Formation فرآیند آماده‌سازی و آرایش واگن‌ها برای ایجاد یک قطار قابل اعزام. 61 تجمیع واگن Wagon Consolidation جمع‌آوری و ترکیب واگن‌ها برای تشکیل جریان یا قطار اقتصادی و عملیاتی. 62 تست ترمز Brake Test فرآیند کنترل و تأیید عملکرد سیستم ترمز قطار پیش از حرکت یا در شرایط تعیین‌شده. 63 سوخت‌گیری Refueling عملیات تأمین سوخت لکوموتیو. 64 پنجره زمانی Time Window بازه زمانی مشخصی که انجام یک عملیات یا حرکت در آن مجاز یا مطلوب است. 65 محدودیت زمانی Time Constraint هر قیدی که انجام حرکت یا عملیات را به زمان خاصی محدود می‌کند. 66 پنجره تعمیراتی Maintenance Window بازه‌ای که به تعمیر، نگهداری یا انسداد بخشی از شبکه اختصاص می‌یابد. 67 محدودیت بهره‌برداری Operational Constraint هر قید ناشی از قوانین، تجهیزات، فرآیندها یا شرایط عملیاتی. 68 ساعت نماز Prayer Time Window پنجره زمانی که بر اساس سیاست بهره‌برداری برای توقف یا تنظیم حرکت قطار لحاظ می‌شود. 69 ایستگاه نماز Prayer Stop Station ایستگاهی که طبق سیاست عملیاتی برای توقف قطار در زمان نماز مجاز یا ترجیح داده شده است. 70 حاشیه اطمینان Safety / Capacity Margin بخشی از ظرفیت که برای جبران عدم قطعیت و افزایش قابلیت اتکا کنار گذاشته می‌شود. 71 ظرفیت رزرو Reserved Capacity بخشی از ظرفیت که عمداً برای شرایط اضطراری یا نیازهای آتی آزاد نگه داشته می‌شود. 72 تقاضای بار Freight Demand مقدار بار یا تعداد قطار مورد نیاز بازار در یک بازه زمانی مشخص. 73 تقاضای بالقوه Potential Demand تقاضایی که در صورت وجود ظرفیت و شرایط مناسب قابلیت تبدیل به حمل واقعی را دارد. 74 تقاضای پاسخ‌داده‌نشده Unserved Demand بخشی از تقاضا که به دلیل محدودیت ظرفیت یا سایر عوامل امکان تأمین آن وجود ندارد. 75 رقابت روت‌ها Route Competition رقابت چند روت برای استفاده از منابع مشترک و محدود شبکه. 76 تعارض مسیر Route Conflict شرایطی که استفاده همزمان یا برنامه‌ریزی‌شده چند جریان از یک منبع شبکه با یکدیگر تداخل دارد. 77 حل تعارض Conflict Resolution فرآیند شناسایی و رفع یا بهینه‌سازی تعارض‌های موجود بین جریان‌های قطار. 78 بهینه‌سازی شبکه Network Optimization یافتن بهترین ترکیب جریان‌های قطار تحت مجموعه‌ای از قیود شبکه. 79 تابع هدف Objective Function معیار ریاضی که سامانه برای بیشینه یا کمینه‌کردن آن مسئله را حل می‌کند. 80 متغیر تصمیم Decision Variable متغیری که مقدار آن توسط الگوریتم بهینه‌سازی تعیین می‌شود. 81 قید Constraint شرطی که هیچ راه‌حل معتبر نباید آن را نقض کند. 82 راه‌حل بهینه Optimal Solution بهترین راه‌حل مطابق تابع هدف و قیود تعریف‌شده. 83 جریان شبکه Network Flow مقدار حرکت بار یا قطار از طریق اجزای شبکه. 84 جریان قابل تحقق Feasible Flow جریانی که تمام قیود زیرساختی، زمانی و عملیاتی را رعایت می‌کند. 85 سناریو Scenario مجموعه‌ای مشخص از فرضیات یا تغییرات برای بررسی وضعیت شبکه. 86 سناریوی پایه Base Scenario وضعیت مرجع شبکه که سایر سناریوها نسبت به آن مقایسه می‌شوند. 87 سناریوی توسعه Development Scenario سناریویی که در آن یک یا چند تغییر زیرساختی یا عملیاتی اعمال شده است. 88 تحلیل حساسیت Sensitivity Analysis بررسی میزان تغییر خروجی در اثر تغییر یک یا چند ورودی. 89 تحلیل گلوگاه Bottleneck Analysis شناسایی منابعی که بیشترین اثر محدودکننده بر ظرفیت شبکه دارند. 90 ظرفیت افزوده Incremental Capacity مقدار ظرفیت جدیدی که در اثر یک مداخله ایجاد می‌شود. 91 مداخله زیرساختی Infrastructure Intervention هر اقدام سرمایه‌گذاری یا فنی برای تغییر ظرفیت یا عملکرد زیرساخت. 92 هزینه ظرفیت افزوده Cost per Additional Capacity هزینه ایجاد یک واحد ظرفیت جدید. 93 GIS Geographic Information System سامانه اطلاعات جغرافیایی برای ذخیره، تحلیل و نمایش داده‌های مکانی شبکه. 94 لایه مکانی Spatial Layer مجموعه عوارض جغرافیایی هم‌نوع در سامانه GIS. 95 گره Node نقطه‌ای در گراف شبکه مانند ایستگاه، تقاطع یا نقطه عملیاتی. 96 یال Edge ارتباط یا بخش خط بین دو گره در مدل گراف شبکه. 97 اشباع ظرفیت Capacity Utilization نسبت ظرفیت مصرف‌شده به ظرفیت قابل استفاده. 98 بهره‌برداری از ظرفیت Capacity Utilization Rate درصد استفاده واقعی از ظرفیت موجود. 99 ظرفیت شبکه Network Capacity حداکثر جریان قابل تحقق در کل شبکه با درنظرگرفتن محدودیت‌ها و اشتراک منابع. 100 موتور تولید ظرفیت Capacity Generation Engine هسته نرم‌افزاری محاسبه ظرفیت فنی، عملیاتی و قابل عرضه شبکه. 101 موتور حل شبکه Network Optimization Engine هسته محاسباتی حل تعارض و تعیین ترکیب بهینه جریان‌های روت‌ها. 102 موتور تخصیص ظرفیت Capacity Allocation Engine سامانه‌ای که ظرفیت بهینه‌شده را میان متقاضیان و جریان‌های بار تخصیص می‌دهد. 103 بازارگاه ریلی Rail Capacity Marketplace بستر عرضه، تقاضا، تخصیص یا حراج ظرفیت حمل بار ریلی. 104 ظرفیت عرضه‌شده Offered Capacity ظرفیتی که رسماً در اختیار بازار یا متقاضیان قرار گرفته است. 105 ظرفیت تخصیص‌یافته Allocated Capacity ظرفیتی که به یک متقاضی، بار یا روت مشخص اختصاص یافته است. 106 ظرفیت استفاده‌شده واقعی Actual Utilized Capacity ظرفیتی که در عملیات واقعی مورد استفاده قرار گرفته است. 107 کالیبراسیون Calibration اصلاح پارامترهای مدل بر اساس مقایسه نتایج محاسباتی با عملکرد واقعی. 108 قابلیت توضیح‌پذیری Explainability امکان مشاهده و توضیح عوامل مؤثر بر یک خروجی محاسباتی. 109 ظرفیت پویا Dynamic Capacity ظرفیتی که با تغییر شرایط شبکه، تقاضا، عملیات یا ناوگان در طول زمان تغییر می‌کند. 110 ظرفیت قطار Train Capacity تعداد قطار قابل عبور یا قابل تخصیص در یک بازه زمانی مشخص. 111 ظرفیت تناژی Tonnage Capacity مقدار بار خالص قابل حمل در یک بازه زمانی مشخص. 112 تن-کیلومتر Ton-kilometer (Ton-km) حاصل‌ضرب تناژ حمل‌شده در مسافت طی‌شده و شاخص مهم اندازه‌گیری عملکرد حمل بار. 113 ظرفیت کریدور Corridor Capacity حداکثر جریان قابل حمل در یک کریدور با لحاظ گلوگاه‌ها و منابع مشترک. 114 منبع محدود Scarce Resource هر منبعی که ظرفیت آن محدود و مورد استفاده چند جریان است. 115 منبع مشترک Shared Resource منبعی که بیش از یک روت یا جریان برای استفاده از آن وابسته است. 116 تخصیص ظرفیت Capacity Allocation فرآیند اختصاص ظرفیت محدود به جریان‌ها، مشتریان یا متقاضیان. 117 حراج ظرفیت Capacity Auction سازوکار رقابتی برای تخصیص ظرفیت محدود بر اساس قواعد از پیش تعیین‌شده. 118 قیمت ظرفیت Capacity Price ارزش یا تعرفه تعیین‌شده برای استفاده از یک واحد ظرفیت. 119 قابلیت اتکای مسیر Route Reliability احتمال یا میزان تحقق برنامه حمل در مسیر در شرایط عملیاتی واقعی. 120 ظرفیت اقتصادی Economic Capacity ظرفیتی که علاوه بر امکان فنی، از نظر اقتصادی و تقاضای بازار نیز قابلیت استفاده دارد. ۷۰. اصطلاحات کلیدی که باید در کل پروژه ثابت بمانند برای جلوگیری از ابهام در اسناد بعدی، پیشنهاد می‌کنم از این پس این اصطلاحات را دقیقاً با همین معانی به کار ببریم: Route = روت Segment = بخش مسیر Block = بلاک OD Pair = جفت مبدأ–مقصد Capacity = ظرفیت Capacity Generation = تولید ظرفیت Capacity Allocation = تخصیص ظرفیت Network Optimization = بهینه‌سازی شبکه Shared Block = بلاک مشترک Bottleneck = گلوگاه Headway = فاصله زمانی مجاز بین دو قطار متوالی Train Payload = ظرفیت بارگیری قطار Freight Demand = تقاضای بار Available Capacity = ظرفیت آزاد/قابل استفاده Offered Capacity = ظرفیت قابل عرضه Allocated Capacity = ظرفیت تخصیص‌یافته Actual Utilization = استفاده واقعی Sensitivity Analysis = تحلیل حساسیت Scenario = سناریو Capacity Margin = حاشیه ظرفیت/اطمینان Capacity Gain = ظرفیت افزوده یک نکته مهم برای تثبیت سند در نسخه نهایی بهتر است Capacity را صرفاً «ظرفیت» ترجمه کنیم و از به‌کارگیری همزمان «توان حمل»، «ظرفیت حمل»، «گنجایش» و «توان عبور» به‌عنوان مترادف‌های بدون تعریف خودداری کنیم. این تفکیک، مخصوصاً در مرحله طراحی الگوریتم و دیتابیس، جلوی بسیاری از ابهامات را می‌گیرد. همچنین در نسخه بعدی می‌توانیم یک «واژه‌نامه ریاضی و الگوریتمی» جداگانه اضافه کنیم که در آن نمادهایی مثل C b ​ ، C r ​ ، F od ​ ، H، T b ​ ، D od ​ ، متغیرهای تصمیم، قیود و تابع هدف دقیقاً تعریف شوند. این بخش برای تبدیل همین سند به مشخصات فنی قابل تحویل به تیم نرم‌افزار بسیار مهم خواهد بود. --- ## Prompt 5 — پرسش کاربر (`conversation-turn-9`) ارائه مشخصات فنی قابل تحویل به تیم نرم‌افزار ## Prompt 5 — پاسخ دستیار (`conversation-turn-10`) بله. در این مرحله بهتر است سند را از حالت «شرح فنی» به یک سند مشخصات فنی قابل تحویل به تیم نرم‌افزار (Software Requirements & Technical Specification) تبدیل کنیم. متن زیر را به‌عنوان نسخه اجرایی و مبنای برآورد، طراحی و توسعه تیم نرم‌افزار تثبیت می‌کنم. مشخصات فنی قابل تحویل به تیم نرم‌افزار — موتور تولید، برآورد و بهینه‌سازی ظرفیت حمل بار ریلی بسمه تعالی سند مشخصات فنی و نیازمندی‌های نرم‌افزار موتور تولید، برآورد و بهینه‌سازی ظرفیت حمل بار ریلی Capacity Generation, Estimation & Network Optimization Engine نسخه: 1.0 وضعیت: مبنای طراحی و برآورد نرم‌افزار ماهیت سند: Software Requirements & Technical Specification کاربرد: تحویل به تیم تحلیل، معماری، Backend، Frontend، GIS، Database و Optimization ۱. هدف سند این سند مشخص می‌کند که تیم نرم‌افزار برای ساخت «موتور تولید، برآورد و بهینه‌سازی ظرفیت حمل بار ریلی» دقیقاً چه چیزی باید طراحی و پیاده‌سازی کند. این سند صرفاً یک معرفی محصول نیست؛ بلکه باید مبنای موارد زیر قرار گیرد: تحلیل سیستم طراحی معماری طراحی دیتابیس طراحی API طراحی موتور محاسبات طراحی موتور Optimization طراحی GIS طراحی داشبورد برآورد زمان و هزینه توسعه تعریف تست‌های پذیرش تعریف MVP تعریف نسخه‌های توسعه بعدی ۲. تعریف محصول محصول یک سامانه نرم‌افزاری تحت وب و مبتنی بر GIS است که با دریافت اطلاعات زیر: زیرساخت ریلی خطوط Segmentها Blockها ایستگاه‌ها سیگنالینگ سرعت‌ها محدودیت‌های عملیاتی برنامه حرکت ناوگان لکوموتیو واگن مشخصات قطار تقاضای بار ODها Routeها تعمیرات و محدودیت‌های موقت ظرفیت حمل بار ریلی را در سطوح مختلف محاسبه می‌کند و سپس با حل تعارض بین مسیرها و منابع مشترک، ظرفیت بهینه شبکه را به دست می‌آورد. خروجی نهایی می‌تواند به: موتور تخصیص ظرفیت بازارگاه ریلی موتور حراج ظرفیت سامانه برنامه‌ریزی قطار داشبورد مدیریت شبکه سامانه تحلیل سرمایه‌گذاری ارائه شود. ۳. اصل معماری محصول چهار مفهوم باید کاملاً از یکدیگر جدا باشند: Capacity Generation ↓ Network Optimization ↓ Capacity Allocation ↓ Actual Utilization یعنی: Capacity Generation محاسبه اینکه شبکه چه ظرفیتی ایجاد می‌کند. Network Optimization حل رقابت منابع مشترک و تعیین حداکثر ظرفیت قابل تحقق همزمان. Capacity Allocation اختصاص ظرفیت به متقاضیان. Actual Utilization آنچه در عملیات واقعی اتفاق افتاده است. این تفکیک باید در معماری نرم‌افزار، دیتابیس، API و گزارش‌ها نیز رعایت شود. ۴. محدوده محصول ۴.۱ در محدوده نسخه اصلی نسخه اصلی باید شامل این هفت ماژول باشد: Single Track Capacity Engine Double Track Capacity Engine Mixed Track Capacity Engine Route / OD Capacity Engine Network Optimization Engine Scenario & Sensitivity Engine GIS & Capacity Visualization Engine ۵. کاربران سیستم سیستم حداقل باید نقش‌های زیر را پشتیبانی کند. ۵.۱ System Administrator مدیریت: کاربران نقش‌ها تنظیمات دسترسی‌ها پارامترهای پایه ۵.۲ Infrastructure Expert مدیریت: خطوط Segmentها Blockها ایستگاه‌ها سرعت ظرفیت زیرساخت ۵.۳ Operations Expert مدیریت: Headway برنامه حرکت توقف تقاطع سبقت محدودیت عملیاتی ۵.۴ Fleet Expert مدیریت: لکوموتیو واگن قطار ظرفیت ناوگان ۵.۵ Demand Analyst مدیریت: تقاضا OD کالا سناریوهای تقاضا ۵.۶ Optimization Expert مدیریت: تابع هدف قیود اولویت‌ها سناریوهای Optimization ۵.۷ Manager مشاهده: ظرفیت گلوگاه سناریو سرمایه‌گذاری داشبورد ۶. معماری کلان نرم‌افزار معماری پیشنهادی: ┌───────────────────────┐ │ Web / GIS Frontend │ └───────────┬───────────┘ │ REST API │ ┌──────────────────────▼─────────────────────┐ │ Application Layer │ │ │ │ Route Management │ │ Scenario Management │ │ Capacity Management │ │ Reporting │ │ User / Access Management │ └──────────────────────┬─────────────────────┘ │ ┌───────────────────▼───────────────────┐ │ Capacity Engine │ │ │ │ M1 Single Track │ │ M2 Double Track │ │ M3 Mixed Track │ │ M4 Route / OD │ │ M5 Network Optimization │ │ M6 Scenario / Sensitivity │ └───────────────────┬───────────────────┘ │ ┌───────────────────▼───────────────────┐ │ Data Layer │ │ │ │ PostgreSQL / PostGIS │ │ Infrastructure │ │ Fleet │ │ Demand │ │ Operations │ │ Capacity │ │ Scenarios │ └───────────────────────────────────────┘ ۷. معماری پیشنهادی سرویس‌ها سیستم باید به‌صورت Modular طراحی شود. پیشنهاد: API Gateway │ ├── Authentication Service ├── Infrastructure Service ├── Route Service ├── Demand Service ├── Fleet Service ├── Operations Service ├── Capacity Service ├── Optimization Service ├── Scenario Service ├── GIS Service ├── Reporting Service └── Integration Service در MVP می‌توان این اجزا را در قالب Modular Monolith پیاده‌سازی کرد؛ اما مرزهای منطقی سرویس‌ها باید از ابتدا مشخص باشد تا در آینده امکان تبدیل به Microservice وجود داشته باشد. ۸. تکنولوژی پیشنهادی تکنولوژی نهایی باید در Design Review تصویب شود، ولی معماری پیشنهادی: Backend یکی از: Python / FastAPI Java / Spring Boot .NET / ASP.NET Core برای موتور Optimization، Python مزیت قابل‌توجهی دارد. Database PostgreSQL + PostGIS Optimization معماری باید Solver-Agnostic باشد. یعنی موتور نباید به یک Solver خاص وابسته شود. Interface پیشنهادی: OptimizationSolver ├── MILP Solver ├── CP-SAT Solver └── Future Solver Frontend یکی از: React Angular Vue GIS ترجیحاً: OpenLayers Leaflet MapLibre یا GIS Enterprise متناسب با معماری سازمان ۹. مدل داده اصلی ۹.۱ جدول RailwayNetwork railway_network ---------------- id code name description status created_at updated_at ۱۰. جدول Route route ---------------- id code name origin_node_id destination_node_id distance_km status priority min_share max_share geometry created_at updated_at ۱۱. جدول Segment segment ---------------- id code route_id from_node_id to_node_id length_km track_type directionality max_speed electrified status geometry مقادیر track_type: SINGLE DOUBLE MIXED اما Track Type مربوط به Segment است، نه Route. ۱۲. جدول Block block ---------------- id segment_id code length_km signaling_type block_capacity headway_min direction status geometry ۱۳. جدول Station station ---------------- id code name station_type passenger_capable freight_capable passing_capable overtaking_capable formation_capable max_train_length yard_capacity geometry ۱۴. جدول StationTrack station_track ---------------- id station_id track_number length_m usable_length_m direction purpose can_hold_train can_cross can_overtake can_form_train ۱۵. جدول SpeedProfile speed_profile ---------------- id segment_id start_km end_km speed_loaded speed_empty speed_passenger speed_freight restriction_type valid_from valid_to این جدول برای محاسبه Effective Speed ضروری است. ۱۶. جدول TrainType train_type ---------------- id code name train_category max_length max_gross_weight max_net_payload loaded_speed empty_speed brake_test_time formation_time refueling_time ۱۷. جدول WagonType wagon_type ---------------- id code name wagon_category tare_weight max_gross_weight max_net_payload length_m availability_factor ۱۸. جدول LocomotiveType locomotive_type ---------------- id code name traction_power tractive_effort max_speed fuel_type reliability_factor availability_factor ۱۹. جدول FleetAvailability fleet_availability ---------------- id date time_from time_to locomotive_type_id available_count reliable_count maintenance_count reserved_count ۲۰. جدول ODPair od_pair ---------------- id origin_id destination_id commodity_id demand_period demand_tons priority wagon_type_id train_type_id time_window_from time_window_to ۲۱. جدول RouteOD برای نگاشت چند Route به یک OD: route_od ---------------- id od_pair_id route_id priority allowed min_share max_share ۲۲. جدول Demand demand ---------------- id od_pair_id period tons trains commodity priority reliability_requirement status ۲۳. جدول OperationalConstraint operational_constraint ---------------- id constraint_type resource_type resource_id start_time end_time direction severity hard_constraint value description انواع Constraint: HEADWAY MAINTENANCE PRAYER BRAKE_TEST REFUELING STATION_CAPACITY SPEED SAFETY CROSSING OVERTAKING FORMATION YARD OTHER ۲۴. جدول CapacityResult capacity_result ---------------- id scenario_id resource_type resource_id capacity_type period train_capacity ton_capacity ton_km utilization reliability created_at capacity_type: THEORETICAL TECHNICAL OPERATIONAL RELIABLE MARKETABLE ALLOCABLE USED ۲۵. جدول Bottleneck bottleneck ---------------- id scenario_id resource_type resource_id bottleneck_type severity capacity_before capacity_after lost_capacity affected_routes affected_od_pairs ۲۶. جدول Scenario scenario ---------------- id code name scenario_type base_scenario_id description status created_by created_at ۲۷. جدول ScenarioParameter scenario_parameter ---------------- id scenario_id parameter_name resource_type resource_id base_value scenario_value unit ۲۸. جدول OptimizationRun optimization_run ---------------- id scenario_id objective_type solver status start_time end_time objective_value optimality_gap solution_count error_message ۲۹. جدول OptimizationDecision optimization_decision ---------------- id optimization_run_id route_id od_pair_id period train_count ton_count assigned_capacity ۳۰. جدول CapacityExplanation این جدول برای Explainable Capacity ضروری است. capacity_explanation ---------------- id capacity_result_id factor_type factor_name resource_id impact_value unit description sequence مثلاً: BASE_CAPACITY +320 SINGLE_TRACK -35 STATION -15 PRAYER -8 BRAKE_TEST -7 REFUELING -5 SHARED_BLOCK -10 FINAL 240 ۳۱. مدل ریاضی پایه تعاریف استاندارد: R = مجموعه Routeها S = مجموعه Segmentها B = مجموعه Blockها V = مجموعه Nodeها E = مجموعه Edgeها OD = مجموعه OD Pairها T = مجموعه بازه‌های زمانی ۳۲. متغیرهای اصلی x[r,t] تعداد قطارهای Route r در بازه زمانی t. x[od,r,t] تعداد قطارهای OD مشخص روی Route مشخص. f[b,t] جریان عبوری از Block b. q[od,r,t] تناژ تخصیص‌یافته. ۳۳. پارامترهای اصلی C[b] ظرفیت Block. C[s] ظرفیت Segment. D[od,t] تقاضای OD. P[r] ظرفیت بارگیری هر قطار. H[r,t] Headway. T[b,r] زمان اشغال Block توسط قطار Route r. ۳۴. قید ظرفیت بلاک برای هر Block: Σ x[r,t] ≤ C[b] یا در مدل دقیق زمانی: Σ Occupancy(r,b,t) ≤ AvailableTime(b) ۳۵. قید تقاضا Σ x[od,r,t] ≤ D[od,t] یا در مدل تناژی: Σ q[od,r,t] ≤ Demand[od,t] ۳۶. قید ظرفیت قطار اگر ظرفیت هر قطار P باشد: q[od,r,t] ≤ x[od,r,t] × P ۳۷. قید حداقل سهم Route Flow[r] ≥ MinimumShare[r] ۳۸. قید حداکثر سهم Route Flow[r] ≤ MaximumShare[r] ۳۹. تابع هدف پایه در حالت حداکثرسازی تناژ: MAX Σ q[od,r,t] در حالت Ton-km: MAX Σ q[od,r,t] × Distance[r] در حالت ارزش اقتصادی: MAX Σ q[od,r,t] × EconomicValue[od] ۴۰. تابع هدف ترکیبی سامانه باید امکان تعریف: Objective = α × Tons + β × TonKm + γ × EconomicValue - δ × Delay - ε × EmptyRunning را داشته باشد. ضرایب باید در پنل مدیریت سناریو قابل تغییر باشند. ۴۱. الگوریتم محاسبه ظرفیت تک‌خطه شبه‌کد اولیه: INPUT: Segment Blocks Stations TrainType SpeedProfile OperatingRules FOR each train type: Calculate effective speed Calculate running time for each block Calculate block occupancy time Calculate minimum headway Generate feasible train sequences FOR each direction: Generate feasible movements Generate crossing combinations Check: station capacity crossing feasibility safety headway time windows maintenance windows Calculate maximum feasible train count RETURN: technical capacity operational capacity reliable capacity ۴۲. الگوریتم ظرفیت دوخطه FOR each direction: Calculate block occupancy Calculate headway Calculate theoretical capacity Apply: station restrictions speed restrictions maintenance operational constraints Calculate: Direction A→B Direction B→A Check shared resources RETURN capacity ۴۳. الگوریتم Mixed Track این بخش باید از ابتدا به‌صورت یک مسئله شبکه‌ای طراحی شود. INPUT: Route Segments TrackType Stations Sidings YardCapacity TrainTypes Split Route into operational segments Calculate capacity of each segment Identify: single-track constraints double-track opportunities transition points consolidation points Generate feasible train sequences Optimize: crossing waiting overtaking staging wagon consolidation RETURN: mixed-route capacity critical segment recoverable capacity ۴۴. الگوریتم Route Capacity FOR each Route: Load all segments Load all blocks Load stations Load train types Calculate segment capacities Calculate station capacities Calculate operational restrictions Calculate route-level capacity Identify critical resources RETURN Route Capacity ۴۵. الگوریتم تشخیص Shared Block برای هر Route، مجموعه Blockهای مورد استفاده استخراج می‌شود. اگر: Blocks(Route A) ∩ Blocks(Route B) ≠ ∅ آنگاه Routeها دارای منبع مشترک هستند. خروجی: Shared Resource ↓ Affected Routes ↓ Capacity Conflict ۴۶. الگوریتم تشخیص گلوگاه برای هر Resource: Utilization = UsedCapacity / AvailableCapacity اگر: Utilization ≥ Threshold منبع به‌عنوان Bottleneck Candidate ثبت می‌شود. اما گلوگاه نهایی باید بر اساس اثر آن بر کل شبکه تعیین شود. یعنی: حذف یا افزایش ظرفیت این منبع باید بتواند ظرفیت شبکه را تغییر دهد. ۴۷. الگوریتم Network Optimization Load Network Load Routes Load OD Demand Load Resource Capacities Load Shared Resources Load Policies Create decision variables Create constraints Create objective function Run solver Validate solution Calculate: total trains total tons ton-km route utilization bottlenecks unserved demand unused capacity Generate explanation RETURN solution ۴۸. Validation Engine هر جواب Optimization باید پس از Solver دوباره Validate شود. حداقل کنترل‌ها: No negative flow No capacity violation No station violation No block violation No demand violation No fleet violation No time conflict No hard operational constraint violation در صورت خطا: Optimization Result = INVALID و جواب نباید وارد بازارگاه شود. ۴۹. مفهوم Hard Constraint و Soft Constraint Hard Constraint نقض آن مجاز نیست. مثلاً: ایمنی ظرفیت فیزیکی طول خط حداکثر سرعت ظرفیت بلاک Soft Constraint قابل نقض است ولی دارای جریمه است. مثلاً: ترجیح یک Route ترجیح یک بازه زمانی ترجیح اقتصادی حداقل تأخیر در مدل: Objective Penalty برای Soft Constraint اعمال می‌شود. ۵۰. زمان نماز این موضوع باید به‌صورت یک Time Window مدل شود، نه یک عدد ثابت که از ظرفیت کم شود. ساختار: PrayerWindow ---------------- date start_time end_time station_id allowed_stop minimum_stop_time موتور بررسی می‌کند که آیا قطار می‌تواند توقف موردنظر را در یکی از ایستگاه‌های مجاز انجام دهد. در نتیجه اثر آن بر ظرفیت به شرایط واقعی حرکت وابسته خواهد بود. ۵۱. تعمیرات پنجره تعمیرات: MaintenanceWindow ---------------- resource_id start_time end_time capacity_factor status مثلاً: 08:00–12:00 Capacity = 0 یا: 08:00–12:00 Capacity Factor = 0.5 ۵۲. تست ترمز برای هر Train Type: BrakeTestTime قابل تعریف باشد. اما محل انجام تست نیز باید مشخص باشد. مثلاً: Station A → Brake Test Allowed Station B → Brake Test Allowed Station C → Not Allowed ۵۳. سوخت‌گیری سوخت‌گیری باید دارای: محل مدت ظرفیت همزمان نوع لکوموتیو محدودیت زمانی باشد. مثلاً: RefuelingStation Capacity = 2 locomotives simultaneously Duration = 20 min ۵۴. قطار Loaded / Empty محاسبات باید برای قطارهای: LOADED EMPTY قابل انجام باشد. زیرا: سرعت وزن زمان سیر مصرف انرژی ظرفیت بار متفاوت است. ۵۵. مدل Train Consist یک قطار باید بتواند از ترکیب زیر ساخته شود: Train ├── Locomotive(s) └── Wagon(s) و مشخصات نهایی آن محاسبه شود: Train Length Gross Weight Net Payload Traction Requirement Brake Requirement Speed Profile ۵۶. کنترل طول قطار اگر: Train Length > Station Usable Length باشد: Station Capacity Violation و چنین قطاری نباید به‌عنوان جواب معتبر پذیرفته شود. ۵۷. APIهای اصلی Infrastructure GET /api/infrastructure/routes GET /api/infrastructure/segments GET /api/infrastructure/blocks GET /api/infrastructure/stations Capacity POST /api/capacity/calculate GET /api/capacity/routes/{id} GET /api/capacity/network GET /api/capacity/bottlenecks Optimization POST /api/optimization/run GET /api/optimization/{id} GET /api/optimization/{id}/solution GET /api/optimization/{id}/explanation Scenario POST /api/scenarios POST /api/scenarios/{id}/run GET /api/scenarios/{id}/compare GIS GET /api/gis/capacity GET /api/gis/bottlenecks GET /api/gis/routes GET /api/gis/shared-resources ۵۸. نمونه Request برای محاسبه ظرفیت { "route_id": 125, "period": { "from": "2027-01-01", "to": "2027-01-31" }, "train_type_id": 12, "include_fleet_constraints": true, "include_operational_constraints": true, "include_reliability_margin": true } ۵۹. نمونه Response { "route_id": 125, "period": "2027-01", "theoretical_capacity": 320, "technical_capacity": 285, "operational_capacity": 265, "reliable_capacity": 240, "marketable_capacity": 225, "train_capacity": 225, "ton_capacity": 5697000, "bottlenecks": [ { "resource_id": 44, "type": "BLOCK", "impact": 10 } ] } ۶۰. API توضیح ظرفیت GET /api/capacity/{id}/explanation Response: { "base_capacity": 320, "factors": [ { "factor": "single_track", "impact": -35 }, { "factor": "station", "impact": -15 }, { "factor": "prayer_window", "impact": -8 }, { "factor": "brake_test", "impact": -7 }, { "factor": "shared_block", "impact": -10 } ], "final_capacity": 245 } ۶۱. رابط کاربری اصلی صفحه اصلی باید شامل: Dashboard │ ├── Network Capacity ├── Route Capacity ├── OD Capacity ├── Bottlenecks ├── Demand ├── Fleet ├── Scenarios ├── Optimization ├── GIS └── Reports ۶۲. داشبورد ظرفیت نمایش: ظرفیت کل ظرفیت فنی ظرفیت عملیاتی ظرفیت قابل اتکا ظرفیت قابل عرضه ظرفیت مصرف‌شده ظرفیت آزاد تقاضای پاسخ‌داده‌نشده ۶۳. صفحه Route کاربر با انتخاب Route باید ببیند: Route Distance Segments Track Type Stations Blocks Train Types Capacity Utilization Demand Bottleneck ۶۴. صفحه Segment با کلیک روی Segment: Segment ID Length Track Type Speed Blocks Capacity Utilization Routes ODs Maintenance Bottleneck Score ۶۵. صفحه Block Block Capacity Headway Occupancy Time Routes Using Block Utilization Conflict Lost Capacity ۶۶. صفحه Bottleneck هر گلوگاه باید مشخص کند: Resource Current Capacity Network Impact Affected Routes Affected OD Lost Capacity Potential Gain Suggested Intervention ۶۷. صفحه Scenario کاربر بتواند: Base Scenario ↓ Create Scenario ↓ Change Parameters ↓ Run ↓ Compare مثلاً: Baseline vs Double Tracking vs Signaling Upgrade vs Station Expansion ۶۸. مقایسه سناریوها خروجی: شاخص Base Scenario قطار ... ... تن ... ... Ton-km ... ... گلوگاه ... ... ظرفیت آزاد ... ... تقاضای پاسخ‌داده‌نشده ... ... هزینه ... ... ۶۹. GIS GIS باید Layerهای زیر را پشتیبانی کند: Railway Network Routes Segments Blocks Stations Yards Bottlenecks Capacity Utilization Demand OD Flows Scenarios Maintenance ۷۰. قابلیت Drill-down کاربر باید بتواند: Network ↓ Corridor ↓ Route ↓ Segment ↓ Block ↓ Train حرکت کند. هر سطح باید به سطح بعدی قابل Drill-down باشد. ۷۱. ارتباط با سامانه اطلاعات پایه زیرساخت سیستم باید قابلیت دریافت داده از: سامانه اطلاعات پایه زیرساخت را داشته باشد. روش‌های پیشنهادی: REST API Web Service Database View Scheduled Data Export روش نهایی بر اساس معماری سامانه مبدأ انتخاب می‌شود. ۷۲. ارتباط با سامانه تعمیرات خط اطلاعات زیر باید دریافت شود: تعمیرات برنامه‌ریزی‌شده خرابی محدودیت سرعت انسداد زمان شروع زمان پایان Segment تحت تأثیر این اطلاعات مستقیماً بر ظرفیت اثر می‌گذارد. ۷۳. ارتباط با سامانه ناوگان اطلاعات: لکوموتیو فعال لکوموتیو تعمیراتی واگن فعال نوع واگن ظرفیت قابلیت اطمینان محل فعلی برنامه حرکت باید قابل دریافت باشد. ۷۴. ارتباط با بازارگاه بازارگاه باید بتواند درخواست کند: OD Date Time Window Commodity Train Type Required Tons Reliability و موتور پاسخ دهد: Available Capacity Route Options Reliable Capacity Constraints Capacity Price Input توجه شود که قیمت در این موتور الزاماً محاسبه نمی‌شود؛ این موتور ظرفیت را تولید می‌کند و بازارگاه/موتور اقتصادی می‌تواند قیمت‌گذاری را انجام دهد. ۷۵. مدیریت نسخه داده تمام محاسبات ظرفیت باید به نسخه داده مشخص متصل باشند. مثلاً: Infrastructure Version = 14 Fleet Version = 8 Demand Version = 22 Operation Rule Version = 5 در نتیجه هر نتیجه قابل بازتولید خواهد بود. ۷۶. Reproducibility اگر کاربر امروز محاسبه‌ای انجام دهد و یک ماه بعد همان Scenario را اجرا کند، باید امکان مشخص شدن علت تفاوت وجود داشته باشد. بنابراین هر Run باید ذخیره کند: Input Version Parameter Version Scenario Version Solver Solver Version Run Time Objective Result ۷۷. Audit Log تمام تغییرات حساس باید ثبت شوند: User Timestamp Entity Old Value New Value Reason مثلاً تغییر: Headway: 8 min → 7 min باید در Audit ثبت شود. ۷۸. الزامات امنیتی حداقل: Authentication Role Based Access Control Authorization Audit Log API Authentication Encryption in Transit Backup Database Access Control ۷۹. کارایی برای MVP، معیار دقیق Performance باید پس از Benchmark داده واقعی تعیین شود. اما معماری باید از ابتدا برای موارد زیر آماده باشد: محاسبات همزمان اجرای Scenarioهای متعدد Job Queue اجرای Optimization در Background نمایش Progress Cache نتایج محاسبات تکراری ۸۰. Job Management محاسبات سنگین نباید درخواست HTTP را تا پایان Solver معطل کنند. فرآیند: POST /optimization/run ↓ Job Created ↓ Queue ↓ Optimization Worker ↓ Result و Frontend وضعیت را دریافت کند: QUEUED RUNNING COMPLETED FAILED CANCELLED ۸۱. مدیریت خطا سیستم باید خطاها را دسته‌بندی کند: Data Error داده ناقص یا نامعتبر. Model Error مدل قابل حل نیست. Constraint Conflict قیود با یکدیگر ناسازگارند. Solver Error خطای Solver. Integration Error خطای ارتباط با سامانه خارجی. ۸۲. مثال Constraint Conflict اگر: Demand = 100 Capacity = 0 Minimum Share = 50 باشد، سیستم باید اعلام کند: INFEASIBLE SCENARIO و علت را نمایش دهد. ۸۳. Feasibility Report قبل از Optimization اصلی، سیستم باید امکان اجرای: Pre-Optimization Feasibility Check را داشته باشد. گزارش: Number of constraints Number of conflicts Affected resources Affected routes Suggested corrections ۸۴. تست نرم‌افزار تست باید در چهار سطح باشد: Unit Test برای هر تابع محاسباتی. Integration Test ارتباط ماژول‌ها. Optimization Test صحت جواب مدل. Acceptance Test بر اساس سناریوهای واقعی شبکه. ۸۵. تست مرجع برای هر مدل حداقل یک Case مرجع با جواب محاسبه‌شده و تأییدشده باید ایجاد شود. مثلاً: Case ST-001 Single Track Expected Capacity = X و: Case MT-001 Mixed Track Expected Capacity = Y تمام تغییرات آینده باید این Test Caseها را مجدداً اجرا کنند. ۸۶. معیار پذیرش اصلی سیستم زمانی قابل تحویل است که بتواند: شبکه را وارد کند. Route تعریف کند. Segment تعریف کند. Block تعریف کند. Station تعریف کند. Train Type تعریف کند. Demand وارد کند. ظرفیت تک‌خطه محاسبه کند. ظرفیت دوخطه محاسبه کند. Mixed Track را محاسبه کند. Route Capacity را محاسبه کند. Shared Resource را تشخیص دهد. Bottleneck را تشخیص دهد. Optimization اجرا کند. سناریو ایجاد کند. سناریوها را مقایسه کند. نتیجه را روی GIS نمایش دهد. Explainable Capacity تولید کند. API خروجی ارائه دهد. نتیجه را ذخیره و قابل بازتولید کند. ۸۷. MVP پیشنهادی نسخه MVP نباید از ابتدا تمام پیچیدگی‌های شبکه ملی را پیاده‌سازی کند. MVP پیشنهادی: M1 Single Track M2 Double Track M3 Mixed Track M4 Route / OD M5 Optimization پایه M6 Scenario پایه M7 GIS پایه با یک محدوده واقعی اما محدود از شبکه. ۸۸. نسخه دوم پس از اثبات MVP: ناوگان گردش واگن لکوموتیو قابلیت اطمینان Maintenance Dynamic Dynamic Capacity Time Expanded Network Advanced Optimization Economic Objective اضافه شود. ۸۹. نسخه سوم در نسخه پیشرفته: پیش‌بینی تقاضا پیش‌بینی تأخیر Predictive Capacity Machine Learning Digital Twin Simulation Real-time Capacity اتصال کامل به بازارگاه ظرفیت‌گذاری لحظه‌ای قابل توسعه خواهد بود. ۹۰. تصمیم مهم معماری در نسخه اول، نباید AI جایگزین مدل ریاضی و قواعد عملیاتی شود. ترتیب صحیح: Operational Rules + Mathematical Model + Optimization ↓ Reliable Deterministic Result ↓ AI Enhancement AI در مراحل بعدی می‌تواند برای: پیش‌بینی زمان سیر پیش‌بینی تأخیر تخمین تقاضا تشخیص الگوی گلوگاه پیشنهاد سناریو استفاده شود. ۹۱. خروجی مدیریتی نهایی مدیر باید بتواند در یک صفحه ببیند: ظرفیت کل شبکه ────────────── XX میلیون تن ظرفیت قابل عرضه ────────────── YY میلیون تن مصرف واقعی ────────────── ZZ میلیون تن ظرفیت آزاد ────────────── AA میلیون تن تقاضای پاسخ‌داده‌نشده ────────────── BB میلیون تن تعداد گلوگاه ────────────── CC بیشترین ظرفیت قابل ایجاد با سرمایه‌گذاری ────────────── DD میلیون تن مداخله پیشنهادی ────────────── ... ۹۲. خروجی قابل تحویل به موتور تخصیص خروجی استاندارد باید شامل حداقل: { "od_pair": "...", "route": "...", "period": "...", "available_trains": 85, "available_tons": 5697000, "reliable_trains": 78, "reliable_tons": 5226000, "constraints": [], "capacity_status": "AVAILABLE" } باشد. ۹۳. اصل تفکیک Responsibility تیم نرم‌افزار باید این مرزها را رعایت کند: Capacity Engine می‌گوید: چه مقدار ظرفیت وجود دارد؟ Optimization Engine می‌گوید: چگونه این ظرفیت مشترک بین جریان‌های مختلف به بهترین شکل استفاده شود؟ Allocation Engine می‌گوید: ظرفیت به چه کسی اختصاص داده شود؟ Marketplace می‌گوید: تقاضا چگونه وارد بازار شود و ظرفیت چگونه معامله/رزرو شود؟ Operations می‌گوید: برنامه واقعی چگونه اجرا شد؟ این تفکیک برای جلوگیری از تبدیل محصول به یک سامانه بسیار پیچیده و غیرقابل نگهداری حیاتی است. ۹۴. تعریف Done برای تیم توسعه یک Feature زمانی «Done» محسوب شود که: Backend پیاده‌سازی شده باشد. Database Migration انجام شده باشد. API مستند شده باشد. Unit Test وجود داشته باشد. Integration Test انجام شده باشد. Frontend متصل شده باشد. GIS در صورت نیاز متصل شده باشد. Error Handling پیاده شده باشد. Audit Log ایجاد شده باشد. مستند فنی تکمیل شده باشد. Case مرجع با نتیجه صحیح اجرا شده باشد. ۹۵. خروجی‌های مورد انتظار تیم نرم‌افزار تیم توسعه باید در پایان طراحی و توسعه حداقل موارد زیر را تحویل دهد: ۱. Software Architecture Document ۲. Database Design Document ۳. API Specification ۴. Algorithm Specification ۵. Optimization Model Specification ۶. GIS Specification ۷. UI/UX Specification ۸. Integration Specification ۹. Security Specification ۱۰. Test Plan ۱۱. Deployment Guide ۱۲. User Manual ۱۳. Admin Manual ۱۴. Source Code ۱۵. Database Scripts ۱۶. API Documentation ۱۷. Test Dataset ۱۸. Benchmark Dataset ۱۹. Acceptance Test Report ۹۶. ساختار پیشنهادی Repository rail-capacity-engine/ │ ├── backend/ │ ├── api/ │ ├── services/ │ ├── models/ │ ├── repositories/ │ └── integrations/ │ ├── capacity-engine/ │ ├── single-track/ │ ├── double-track/ │ ├── mixed-track/ │ └── route-capacity/ │ ├── optimization/ │ ├── model/ │ ├── constraints/ │ ├── objectives/ │ ├── solvers/ │ └── validation/ │ ├── gis/ │ ├── frontend/ │ ├── database/ │ ├── migrations/ │ ├── seed/ │ └── reference-data/ │ ├── tests/ │ ├── unit/ │ ├── integration/ │ ├── optimization/ │ └── acceptance/ │ └── docs/ ۹۷. اولویت توسعه توسعه باید به این ترتیب انجام شود: P0 مدل داده + معماری ↓ P1 Infrastructure + Route + Segment + Block ↓ P2 Single / Double Capacity ↓ P3 Mixed Track ↓ P4 OD + Demand ↓ P5 Network Optimization ↓ P6 Scenario / Sensitivity ↓ P7 GIS ↓ P8 API Integration ↓ P9 Marketplace / Allocation Integration ۹۸. مهم‌ترین نکته طراحی نباید موتور از ابتدا با یک فرمول ساده مانند: Capacity = 24 hours / Headway ساخته شود. این فرمول فقط می‌تواند بخشی از ظرفیت نظری را نشان دهد. محصول نهایی باید بتواند: Infrastructure + Time + Train + Station + Block + Speed + Direction + Operations + Fleet + Demand + Shared Resources + Policy را همزمان مدل کند. ۹۹. تعریف نهایی محصول این نرم‌افزار صرفاً یک Capacity Calculator نیست. محصول نهایی یک: Rail Freight Network Capacity Digital Engine است که از داده خام شبکه تا ظرفیت قابل عرضه به بازار را پوشش می‌دهد. زنجیره نهایی: Raw Data ↓ Network Model ↓ Route Model ↓ Train Model ↓ Demand Model ↓ Capacity Generation ↓ Conflict Detection ↓ Network Optimization ↓ Scenario Analysis ↓ Reliable Capacity ↓ Marketable Capacity ↓ Capacity Allocation ↓ Actual Operation ↓ Calibration ۱۰۰. خروجی نهایی مورد انتظار در نهایت تیم نرم‌افزار باید محصولی بسازد که بتواند برای هر: شبکه کریدور Route OD Segment Block Station Train Type بازه زمانی Scenario پاسخ دهد: چه مقدار ظرفیت وجود دارد؟ چرا این مقدار وجود دارد؟ چه چیزی آن را محدود کرده است؟ چه مقدار ظرفیت آزاد است؟ چه مقدار تقاضا پاسخ داده نشده است؟ اگر یک عامل تغییر کند، ظرفیت چقدر تغییر می‌کند؟ و این ظرفیت چگونه می‌تواند وارد موتور تخصیص و بازارگاه ریلی شود؟ این سؤال، معیار اصلی موفقیت محصول است. ۱۰۱. پیوست A — واژه‌نامه استاندارد اجرایی اصطلاحات زیر باید در کل نرم‌افزار، دیتابیس، API، مستندات و رابط کاربری با یک معنای ثابت استفاده شوند: اصطلاح English تعریف اجرایی ظرفیت Capacity حداکثر قابلیت قابل تحقق برای عبور/حمل در شرایط مشخص تولید ظرفیت Capacity Generation محاسبه ظرفیت ایجادشده توسط شبکه برآورد ظرفیت Capacity Estimation تخمین ظرفیت با استفاده از داده و مدل ظرفیت نظری Theoretical Capacity ظرفیت در شرایط ایده‌آل ظرفیت فنی Technical Capacity ظرفیت مبتنی بر مشخصات واقعی زیرساخت ظرفیت عملیاتی Operational Capacity ظرفیت پس از اعمال محدودیت‌های بهره‌برداری ظرفیت قابل اتکا Reliable Capacity ظرفیتی که با سطح اطمینان مشخص قابل انتظار است ظرفیت قابل عرضه Marketable Capacity ظرفیتی که برای بازار قابل عرضه است ظرفیت قابل تخصیص Allocable Capacity ظرفیتی که امکان تخصیص دارد ظرفیت مصرف‌شده Used Capacity ظرفیت بالفعل مصرف‌شده ظرفیت آزاد Available Capacity ظرفیت باقی‌مانده ظرفیت از دست‌رفته Lost Capacity ظرفیت بالقوه‌ای که به دلیل محدودیت تحقق نیافته ظرفیت پنهان Hidden Capacity ظرفیتی که با اصلاح عملیات یا بهره‌برداری قابل بازیابی است Route Route مسیر عملیاتی مبدأ تا مقصد Segment Segment بخش مشخصی از Route Block Block واحد عملیاتی کنترل حرکت قطار Shared Block Shared Block Block مورد استفاده چند Route Bottleneck Bottleneck منبعی که ظرفیت شبکه را محدود می‌کند OD Pair OD Pair جفت مبدأ–مقصد Headway Headway حداقل فاصله زمانی مجاز بین قطارها Train Payload Train Payload ظرفیت خالص بارگیری قطار Freight Demand Freight Demand تقاضای حمل بار Network Optimization Network Optimization بهینه‌سازی همزمان منابع شبکه Scenario Scenario وضعیت فرضی با مجموعه پارامتر مشخص Sensitivity Analysis Sensitivity Analysis بررسی اثر تغییر پارامتر بر خروجی Capacity Allocation Capacity Allocation تخصیص ظرفیت تولیدشده Capacity Auction Capacity Auction سازوکار رقابتی تخصیص ظرفیت Actual Utilization Actual Utilization میزان استفاده واقعی از ظرفیت ۱۰۲. پیوست B — واژه‌نامه ریاضی نمادهای اصلی پروژه: R مجموعه Routeها S مجموعه Segmentها B مجموعه Blockها V مجموعه Nodeها E مجموعه Edgeها OD مجموعه OD Pairها T مجموعه بازه‌های زمانی x[r,t] تعداد قطار Route r در زمان t x[od,r,t] تعداد قطار OD روی Route q[od,r,t] تناژ تخصیص‌یافته C[b] ظرفیت Block C[s] ظرفیت Segment D[od,t] تقاضای OD P[r] ظرفیت بارگیری قطار H[r,t] Headway T[b,r] زمان اشغال Block U نرخ استفاده از ظرفیت F جریان بار ۱۰۳. پیوست C — اصول غیرقابل نقض طراحی تیم توسعه باید اصول زیر را رعایت کند: اصل ۱ Route با Segment یکی نیست. اصل ۲ دوخطه شدن Segment باعث ایجاد Route جدید نمی‌شود. اصل ۳ ظرفیت مستقل Routeها قابل جمع ساده نیست. اصل ۴ Shared Resource باید در مدل شبکه لحاظ شود. اصل ۵ ظرفیت قطار و ظرفیت تناژی باید جداگانه محاسبه شوند. اصل ۶ Loaded و Empty Train باید قابل تفکیک باشند. اصل ۷ جهت حرکت باید در مدل لحاظ شود. اصل ۸ Hard Constraint و Soft Constraint باید جدا باشند. اصل ۹ پارامترهای سیاستی نباید Hard Code شوند. اصل ۱۰ تمام خروجی‌های مهم باید Explainable باشند. اصل ۱۱ نتیجه Optimization باید Validate شود. اصل ۱۲ هر نتیجه باید به نسخه داده و Scenario مشخص متصل باشد. اصل ۱۳ ظرفیت تولیدشده با ظرفیت تخصیص‌یافته یکی نیست. اصل ۱۴ ظرفیت قابل عرضه با ظرفیت مصرف واقعی یکی نیست. اصل ۱۵ موتور Capacity نباید مسئول تصمیم نهایی تخصیص بازار باشد. ۱۰۴. پیوست D — تعریف محصول برای قرارداد توسعه متن زیر می‌تواند مستقیماً در شرح خدمات قرارداد توسعه نرم‌افزار استفاده شود: «طراحی، پیاده‌سازی، استقرار و مستندسازی سامانه موتور تولید، برآورد و بهینه‌سازی ظرفیت حمل بار ریلی، مشتمل بر مدل‌سازی شبکه ریلی، Route، Segment، Block و Station، محاسبه ظرفیت خطوط تک‌خطه و دوخطه، مدل‌سازی مسیرهای ترکیبی تک‌خطه–دوخطه، محاسبه ظرفیت Route و OD، شناسایی منابع مشترک و گلوگاه‌ها، حل تعارض و بهینه‌سازی ظرفیت در سطح شبکه، تحلیل سناریو و حساسیت، نمایش و تحلیل GIS، ایجاد APIهای استاندارد برای تبادل ظرفیت با سامانه‌های تخصیص و بازارگاه، قابلیت Explainable Capacity، مدیریت نسخه داده و Scenario، ثبت Audit، اعتبارسنجی نتایج و فراهم‌سازی زیرساخت اتصال به سامانه‌های اطلاعات پایه زیرساخت، تعمیرات خط، ناوگان و بازارگاه ریلی.» ۱۰۵. نتیجه نهایی با این مشخصات، پروژه دیگر در سطح «ایده نرم‌افزاری» نیست. تیم نرم‌افزار اکنون باید بتواند بر اساس این سند: معماری را طراحی کند؛ ERD دیتابیس را تهیه کند؛ APIها را مشخص کند؛ موتور محاسبه ظرفیت را پیاده‌سازی کند؛ مدل Optimization را بسازد؛ GIS را طراحی کند؛ سناریوهای تست را ایجاد کند؛ زمان و نیروی انسانی مورد نیاز را برآورد کند؛ MVP را تعریف و اجرا کند؛ و در نهایت سیستم را به موتور تخصیص و بازارگاه ریلی متصل نماید. مرحله بعدی این سند، طراحی «ERD کامل + Data Dictionary + API Contract + مدل ریاضی دقیق M1 تا M5» است. این مرحله باید با جزئیات به سطحی برسد که یک برنامه‌نویس، تحلیلگر داده و متخصص Optimization بتوانند بدون تفسیر مجدد مفهوم، کار خود را آغاز کنند. این نسخه را می‌توان مبنای واقعی جلسه Kick-off با تیم نرم‌افزار قرار داد. گام فنی بعدی که بیشترین ارزش را دارد، شکستن همین سند به ERD کامل دیتابیس و Data Dictionary فیلدبه‌فیلد و سپس تعریف دقیق الگوریتم M1 تا M5 است؛ چون بعد از آن، برآورد نفر-ماه و معماری اجرایی بسیار دقیق‌تر می‌شود. --- ## Prompt 6 — پرسش کاربر (`conversation-turn-11`) در نسخه نهایی بهتر است Capacity را صرفاً «ظرفیت» ترجمه کنیم و از به‌کارگیری همزمان «توان حمل»، «ظرفیت حمل»، «گنجایش» و «توان عبور» به‌عنوان مترادف‌های بدون تعریف خودداری کنیم. این تفکیک، مخصوصاً در مرحله طراحی الگوریتم و دیتابیس، جلوی بسیاری از ابهامات را می‌گیرد. همچنین در نسخه بعدی می‌توانیم یک «واژه‌نامه ریاضی و الگوریتمی» جداگانه اضافه کنیم که در آن نمادهایی مثل C_b، C_r، F_{od}، H، T_b، D_{od}، متغیرهای تصمیم، قیود و تابع هدف دقیقاً تعریف شوند. این بخش برای تبدیل همین سند به svgمشخصات فنی قابل تحویل به تیم نرم‌افزار بسیار مهم خواهد بود. ## Prompt 6 — پاسخ دستیار (`conversation-turn-12`) کاملاً موافقم. این اصلاح از نظر مهندسی نرم‌افزار و مدل‌سازی ریاضی بسیار مهم است و بهتر است از همین الآن به‌عنوان یک قاعده واژگانی الزام‌آور پروژه تثبیت شود. در نسخه بعدی سند، این قاعده را اعمال می‌کنیم: ۱. استاندارد واژه Capacity در کل پروژه: Capacity = ظرفیت و فقط در صورت نیاز، با یک صفت دقیق‌تر تعریف می‌شود: Theoretical Capacity = ظرفیت نظری Technical Capacity = ظرفیت فنی Operational Capacity = ظرفیت عملیاتی Reliable Capacity = ظرفیت قابل اتکا Marketable Capacity = ظرفیت قابل عرضه Allocable Capacity = ظرفیت قابل تخصیص Used Capacity = ظرفیت مصرف‌شده Available Capacity = ظرفیت آزاد در نتیجه، اصطلاحاتی مانند «توان حمل»، «گنجایش»، «توان عبور» و «ظرفیت حمل» دیگر به‌صورت مترادف آزاد استفاده نخواهند شد. اگر یکی از آنها در یک متن تخصصی لازم باشد، باید تعریف مستقل و مشخص داشته باشد. مثلاً: «توان کشش لکوموتیو» یک مفهوم مستقل از ظرفیت (Capacity) است. و: «ظرفیت بارگیری قطار» یک نوع مشخص از ظرفیت است، نه مترادف عمومی Capacity. این تفکیک باید در متن، دیتابیس، API، نام متغیرها، گزارش‌ها و رابط کاربری یکسان باشد. ۲. اضافه شدن واژه‌نامه ریاضی و الگوریتمی در نسخه بعدی، واژه‌نامه فعلی را به دو بخش مستقل تقسیم می‌کنیم: الف) واژه‌نامه استاندارد مفهومی و عملیاتی برای اصطلاحاتی مانند: Route, Segment, Block, Capacity, Headway, Bottleneck, OD, Fleet... ب) واژه‌نامه ریاضی و الگوریتمی که مستقیماً مبنای پیاده‌سازی موتور خواهد بود. برای نمونه: نماد عنوان تعریف C b ​ Block Capacity ظرفیت بلاک b در بازه زمانی مشخص C s ​ Segment Capacity ظرفیت Segment s C r ​ Route Capacity ظرفیت Route r C n ​ Network Capacity ظرفیت بهینه شبکه D od ​ OD Demand تقاضای جفت مبدأ–مقصد od F od ​ OD Flow جریان قطار مربوط به OD F r ​ Route Flow جریان قطار روی Route H Headway حداقل فاصله زمانی مجاز بین قطارها T b ​ Block Occupancy Time زمان اشغال بلاک P r ​ Train Payload ظرفیت بارگیری هر قطار Route U b ​ Block Utilization نرخ استفاده از ظرفیت بلاک x r,t ​ Decision Variable متغیر تصمیم تعداد قطارهای Route r در زمان t q od,r,t ​ Allocation Variable تناژ OD روی Route در زمان مشخص D od,t ​ Time-dependent Demand تقاضای OD در بازه زمانی مشخص و بعد از آن، به‌صورت رسمی تعریف می‌کنیم: Sets Parameters Decision Variables Derived Variables Constraints Hard Constraints Soft Constraints Objective Function Feasible Solution Optimal Solution Infeasible Solution Resource Shared Resource Flow Capacity Utilization Slack Penalty Weight ۳. یک اصلاح مهم‌تر برای نسخه فنی به نظرم بهتر است یک اصل دیگر هم به سند اضافه کنیم: هر واژه‌ای که در مدل ریاضی دارای نماد مشخص است، باید در کل نرم‌افزار فقط با همان معنای تعریف‌شده استفاده شود. مثلاً اگر: C b ​ به معنی ظرفیت بلاک تعریف شد، نباید در بخشی از نرم‌افزار به معنی «توان عبور بلاک» یا «ظرفیت قطارهای قابل عبور از بلاک» استفاده شود. همچنین بین این چهار مفهوم باید صریحاً تفاوت بگذاریم: C b ​  =C r ​  =C n ​  =C alloc ​ یعنی: ظرفیت بلاک ≠ ظرفیت Route ≠ ظرفیت شبکه ≠ ظرفیت تخصیص‌یافته این تفکیک دقیقاً همان چیزی است که بعداً از ایجاد خطا در دیتابیس و الگوریتم Optimization جلوگیری می‌کند. بنابراین نسخه بعدی سند 58321 را بر همین مبنا ادامه می‌دهیم و واژه‌نامه ریاضی و الگوریتمی را صرفاً به‌صورت توضیحی نمی‌نویسیم؛ بلکه آن را به قرارداد مشترک بین تحلیلگر سیستم، طراح دیتابیس، برنامه‌نویس و متخصص Optimization تبدیل می‌کنیم. گام منطقی بعدی هم به‌نظر من ERD + Data Dictionary فیلدبه‌فیلد است؛ چون بعد از تثبیت نمادها و تعاریف ریاضی، می‌توانیم دقیقاً مشخص کنیم هر مفهوم در کدام جدول، با چه Field، چه Data Type، چه Unit و چه Relationship ذخیره شود. --- ## Prompt 7 — پرسش کاربر (`conversation-turn-13`) بله لطفا نسخه بعدی سند رو با تثبیت نمادها و تعاریف ریاضی و هر مقدماتی که لازم هست آماده کنیم بعد بریم سراغ معماری داده ## Prompt 7 — پاسخ دستیار (`conversation-turn-14`) نسخه جدید را طوری تنظیم کردم که مبنای رسمی و قراردادی پروژه باشد. در این نسخه، علاوه بر تثبیت واژه‌ی Capacity = ظرفیت، یک «لایه ریاضی و الگوریتمی» مستقل ایجاد شده و تفاوت بین ظرفیت بلاک، بخش مسیر، مسیر، شبکه، جریان قطار، جریان بار، تقاضا، ظرفیت آزاد و ظرفیت تخصیص‌یافته دقیقاً مشخص شده است. سند مشخصات فنی و ریاضی موتور تولید، برآورد و بهینه‌سازی ظرفیت ریلی بسمه تعالی سند مشخصات فنی، ریاضی و الگوریتمی موتور تولید، برآورد و بهینه‌سازی ظرفیت ریلی Rail Capacity Generation, Estimation & Network Optimization Engine نسخه: مبنای طراحی نرم‌افزار – ویرایش ریاضی و الگوریتمی وضعیت: مبنای ورود به مرحله معماری داده و طراحی ERD دامنه: شبکه حمل‌ونقل ریلی بار زبان مدل: فارسی / English Technical Notation 1. هدف سند این سند، مبنای رسمی طراحی نرم‌افزاری، ریاضی و الگوریتمی موتور: تولید، برآورد، تحلیل، بهینه‌سازی و سنجش ظرفیت ریلی است. هدف این موتور آن است که با دریافت اطلاعات زیرساخت، مسیرها، قطارها، ناوگان، تقاضا، محدودیت‌های عملیاتی، قواعد بهره‌برداری و سیاست‌های تخصیص، بتواند: ظرفیت قابل ایجاد در هر بخش شبکه را محاسبه کند؛ ظرفیت هر مسیر مبدأ–مقصد را برآورد کند؛ ظرفیت مسیرهای دارای بخش مشترک را به‌صورت همزمان محاسبه کند؛ گلوگاه‌های شبکه را شناسایی کند؛ ظرفیت از دست‌رفته و ظرفیت پنهان را مشخص کند؛ اثر تغییرات زیرساختی را بر ظرفیت محاسبه کند؛ تقاضای موجود و بالقوه را با ظرفیت مقایسه کند؛ ظرفیت کل شبکه را تحت سناریوهای مختلف بهینه کند؛ ظرفیت بهینه را برای ورود به موتور تخصیص/بازارگاه آماده کند؛ پس از اجرای واقعی برنامه، داده‌های واقعی را دریافت و مدل را کالیبره کند. 2. اصل بنیادین واژگانی پروژه 2-1. قاعده اصلی در تمام اسناد، نرم‌افزار، پایگاه داده، API، گزارش‌ها و الگوریتم‌ها: Capacity = ظرفیت و «ظرفیت» نباید بدون تعریف مستقل با اصطلاحات زیر مترادف تلقی شود: توان حمل ظرفیت حمل گنجایش توان عبور توان عملیاتی Throughput هر یک از این اصطلاحات، در صورت نیاز، باید دارای تعریف مستقل باشند. بنابراین: Capacity ≠ Hauling Power ≠ Traction Power ≠ Throughput 3. مفاهیم مستقلی که نباید با Capacity خلط شوند 3-1. توان کشش توان یا قابلیت لکوموتیو برای کشیدن قطار تحت شرایط مشخص. نماد پیشنهادی: [ TracPower ] یا در مدل دقیق‌تر: [ F_{tractive} ] این مفهوم تابعی از ویژگی‌های لکوموتیو، وزن قطار، شیب، منحنی مسیر، سرعت و شرایط بهره‌برداری است. 3-2. ظرفیت بارگیری قطار حداکثر مقدار بار قابل حمل توسط یک قطار تحت شرایط مشخص. نماد: [ P_r ] که در این سند: Train Payload = ظرفیت بارگیری قطار است. این مقدار با ظرفیت شبکه یکسان نیست. ممکن است شبکه در یک بازه زمانی ظرفیت عبور 30 قطار داشته باشد، ولی ظرفیت بارگیری هر قطار 3,000 تن باشد. 3-3. جریان جریان، مقدار واقعی یا برنامه‌ریزی‌شده حرکت قطار یا بار در شبکه است. دو نوع جریان اصلی تعریف می‌شود: جریان قطار [ F ] جریان بار [ Q ] بنابراین: [ F \neq Q ] 4. سلسله‌مراتب ظرفیت در این پروژه ظرفیت به صورت یک مفهوم سلسله‌مراتبی تعریف می‌شود: [ C_b \rightarrow C_s \rightarrow C_r \rightarrow C_n ] که به ترتیب عبارت‌اند از: ظرفیت بلاک ظرفیت بخش مسیر ظرفیت مسیر ظرفیت شبکه اما این رابطه به معنی آن نیست که همیشه: [ C_r = \min(C_b) ] است. زیرا ظرفیت مسیر حاصل تعامل چندین عامل است؛ از جمله: بلاک‌ها ایستگاه‌ها تقاطع‌ها سبقت زمان‌بندی نوع قطار ترکیب قطار محدودیت ناوگان محدودیت زمانی مسیرهای مشترک تقاضا قواعد بهره‌برداری سیاست‌های شبکه 5. سطوح مختلف Capacity برای جلوگیری از ابهام، ظرفیت به سطوح زیر تقسیم می‌شود. 5-1. ظرفیت نظری [ C^{theoretical} ] حداکثر ظرفیت بر اساس یک مدل ساده و بدون درنظرگرفتن بخشی از محدودیت‌های واقعی. 5-2. ظرفیت فنی [ C^{technical} ] ظرفیتی که محدودیت‌های فنی زیرساخت و تجهیزات را لحاظ می‌کند. 5-3. ظرفیت عملیاتی [ C^{operational} ] ظرفیتی که قواعد واقعی بهره‌برداری، زمان‌بندی، توقف، تقاطع، سبقت، تشکیل قطار و سایر محدودیت‌های عملیاتی را لحاظ می‌کند. 5-4. ظرفیت قابل اتکا [ C^{reliable} ] ظرفیتی که با لحاظ احتمال اختلال، تأخیر و سطح اطمینان موردنظر قابل اتکا است. 5-5. ظرفیت قابل عرضه [ C^{marketable} ] ظرفیتی که می‌توان آن را برای عرضه به بازار یا متقاضیان ارائه کرد. 5-6. ظرفیت قابل تخصیص [ C^{alloc} ] ظرفیتی که پس از اعمال قواعد تخصیص و سیاست‌های شبکه واقعاً برای تخصیص در دسترس است. 5-7. ظرفیت تخصیص‌یافته [ C^{allocated} ] مقدار ظرفیتی که به متقاضیان اختصاص داده شده است. 5-8. ظرفیت مصرف‌شده [ C^{used} ] مقدار ظرفیتی که در عمل استفاده شده است. 6. ساختار فضایی شبکه شبکه ریلی در مدل ریاضی از مجموعه‌ای از اجزای زیر تشکیل می‌شود: [ G=(V,E) ] که: (V): مجموعه گره‌ها (E): مجموعه یال‌ها در مدل ریلی: گره‌ها می‌توانند شامل: ایستگاه پایانه محل تغییر مسیر محل اتصال نقطه عملیاتی خاص باشند. یال‌ها می‌توانند نماینده بخش‌های خط بین دو گره باشند. 7. Route – مسیر در این پروژه: Route = مسیر و مسیر یک موجودیت عملیاتی مستقل است که می‌تواند از چندین Segment تشکیل شود. مثلاً: [ Route_r = {S_1,S_2,S_3,\ldots,S_n} ] مسیر ممکن است: تک‌خطه باشد؛ دوخطه باشد؛ ترکیبی از تک‌خطه و دوخطه باشد. 8. Segment – بخش مسیر هر مسیر از چند بخش تشکیل می‌شود: [ S_r = {s_1,s_2,\ldots,s_n} ] هر Segment می‌تواند دارای ویژگی‌هایی مانند: طول وضعیت تک‌خطه/دوخطه سرعت مجاز سرعت مؤثر شیب قوس وضعیت خط نوع ریل وضعیت تعمیرات ظرفیت محدودیت‌های زمانی باشد. 9. Block – بلاک بلاک کوچک‌ترین واحد اصلی کنترل حرکت در مدل ظرفیت است که در یک مدل عملیاتی مشخص، اشغال آن توسط قطار قابل تعریف است. مجموعه بلاک‌ها: [ B={b_1,b_2,\ldots,b_n} ] هر بلاک می‌تواند شامل: [ b = (length,\ speed,\ signal,\ occupancy,\ constraints) ] باشد. 10. Shared Block – بلاک مشترک یکی از مهم‌ترین مفاهیم پروژه: Shared Block = بلاک مشترک است. فرض کنیم دو مسیر: [ R_1 ] و [ R_2 ] از یک بلاک مشترک: [ b_x ] عبور می‌کنند. در این صورت: [ F_{R_1,b_x}+F_{R_2,b_x} \leq C_{b_x} ] یعنی مجموع جریان عبوری مسیرهای رقیب از بلاک مشترک نمی‌تواند از ظرفیت آن بیشتر شود. 11. Double Track – دوخطه دوخطه شدن یک بخش: مسیر جدید ایجاد نمی‌کند. بلکه ویژگی Segment تغییر می‌کند. مثلاً: [ S_5: Single \rightarrow Double ] اما: [ Route_1 ] همچنان همان Route باقی می‌ماند. 12. Mixed Single/Double Track یک مسیر می‌تواند ترکیبی باشد: [ R= S_1^{single} + S_2^{single} + S_3^{double} + S_4^{double} + S_5^{single} ] در چنین شرایطی موتور نباید ظرفیت هر بخش را جداگانه محاسبه و سپس ساده‌ترین مقدار را به کل مسیر نسبت دهد. بلکه باید اثر ساختار شبکه را در سطح زمان‌بندی و جریان بررسی کند. 13. مجموعه مسیرها مجموعه مسیرهای تعریف‌شده: [ R={r_1,r_2,\ldots,r_m} ] هر مسیر دارای: مبدأ مقصد Segmentهای تشکیل‌دهنده Blockهای درگیر زمان حرکت نوع قطار ظرفیت قطار محدودیت‌ها است. 14. OD Pair هر جفت مبدأ–مقصد: [ OD=(o,d) ] است. مجموعه جفت‌های مبدأ–مقصد: [ \mathcal{OD} ] خواهد بود. 15. تقاضای بار تقاضای بار برای یک OD در دوره زمانی (t): [ D_{od,t} ] تعریف می‌شود. واحد پایه پیشنهادی: [ ton ] یا در صورت مدل‌سازی جریان: [ ton/day ] [ ton/month ] 16. جریان قطار برای OD، مسیر و زمان: [ F_{od,r,t} ] تعداد قطارهای برنامه‌ریزی‌شده یا تخصیص‌یافته را نشان می‌دهد. واحد: [ train ] یا: [ train/time\ period ] 17. جریان بار مقدار بار حمل‌شده: [ Q_{od,r,t} ] است. رابطه پایه: F_{od,r,t} \times P_{od,r,t} ] که در آن: (F): تعداد قطار (P): ظرفیت بارگیری قطار است. 18. ظرفیت بارگیری قطار ظرفیت بارگیری قطار: [ P_{r,t} ] می‌تواند تابعی از: نوع واگن تعداد واگن طول قطار وزن مجاز توان کشش شیب سرعت محدودیت‌های مسیر مقررات بهره‌برداری باشد. بنابراین: [ P_{r,t} ] الزاماً مقدار ثابتی نیست. 19. Headway فاصله زمانی مجاز بین حرکت دو قطار متوالی: [ H ] یا در مدل دقیق: [ H_{b,r,t} ] است. Headway می‌تواند تابعی از: سیستم علائم طول بلاک سرعت طول قطار زمان اشغال ترمز ایستگاه جهت حرکت باشد. 20. Block Occupancy Time زمان اشغال بلاک: [ T_b ] است. در مدل دقیق: [ T_{b,r,t} ] که می‌تواند شامل: [ T_b = T_{entry} + T_{running} + T_{clearance} ] باشد. 21. ظرفیت بلاک ظرفیت بلاک در یک دوره زمانی مشخص: [ C_b ] است. اما (C_b) باید همیشه همراه با شرایط مدل تفسیر شود. بنابراین مفهوم کامل‌تر: [ C_b^{(scenario,t)} ] است. در ساده‌ترین حالت: [ C_b \approx \frac{T_{available}}{H_b} ] اما این رابطه صرفاً یک مدل اولیه است و در مدل عملیاتی باید محدودیت‌های واقعی نیز لحاظ شوند. 22. ظرفیت بخش مسیر ظرفیت Segment: [ C_s ] است. این ظرفیت حاصل اثر مجموعه بلاک‌ها و محدودیت‌های همان بخش است. در مدل ساده: [ C_s \leq \min_{b\in s}(C_b) ] اما در مدل کامل: [ C_s = f(B_s,Station_s,Headway,Timetable,Constraints) ] خواهد بود. 23. ظرفیت مسیر ظرفیت مسیر: [ C_r ] مقدار ظرفیت قابل دستیابی برای یک Route در یک سناریوی مشخص است. بنابراین: [ C_r= f(S_r,B_r,Stations,TrainType,Fleet,TimeConstraints,Policy) ] و نه صرفاً: [ C_r=\min(C_s) ] 24. ظرفیت شبکه ظرفیت شبکه: [ C_n ] خروجی مسئله بهینه‌سازی شبکه است. در نتیجه: [ C_n \neq \sum_r C_r ] زیرا مسیرها ممکن است منابع مشترک داشته باشند. در واقع: [ C_n = Optimization(G,R,B,OD,Demand,Fleet,Constraints,Objective) ] است. 25. ظرفیت مشترک برای یک منبع مشترک (b): [ \sum_{r\in R_b} F_{r,b,t} \leq C_{b,t} ] که: [ R_b={r|b\in r} ] است. این رابطه یکی از مهم‌ترین قیود موتور بهینه‌سازی خواهد بود. 26. ظرفیت آزاد ظرفیت آزاد یک منبع: [ Slack_b ] و به صورت: [ Slack_b=C_b-F_b ] تعریف می‌شود. که: [ F_b ] جریان استفاده‌شده از بلاک است. اگر: [ Slack_b>0 ] باشد، ظرفیت آزاد وجود دارد. 27. ظرفیت از دست‌رفته ظرفیتی که از نظر فنی یا عملیاتی قابل ایجاد بوده اما به دلیل محدودیت دیگری استفاده نشده است: [ C^{lost} ] نامیده می‌شود. علل ممکن: برنامه‌ریزی ضعیف تقاضای ناکافی محدودیت ایستگاه محدودیت ناوگان تعمیرات زمان‌بندی سیاست بهره‌برداری عدم وجود قطار برگشت محدودیت بازار 28. ظرفیت پنهان ظرفیتی که در ساختار فعلی شبکه وجود دارد اما به دلیل روش بهره‌برداری یا برنامه‌ریزی فعلی آشکار نشده است: [ C^{hidden} ] این مفهوم برای پروژه بهره‌وری بسیار مهم است. مثلاً ممکن است بدون احداث خط جدید، با: تغییر Headway اصلاح برنامه حرکت بهینه‌سازی تقاطع اصلاح توقف‌ها تشکیل قطار استفاده بهتر از دوخطه‌ها ظرفیت افزایش یابد. 29. ظرفیت افزوده اگر سناریوی جدید ظرفیت بیشتری نسبت به Base داشته باشد: C^{scenario} C^{base} ] خواهد بود. 30. سناریو هر اجرای مدل باید در قالب یک Scenario تعریف شود. [ Scenario_k ] مثلاً: Scenario 0 وضع موجود Scenario 1 دوخطه کردن بخش A Scenario 2 اصلاح Headway Scenario 3 تغییر سرعت Scenario 4 ترکیب دوخطه + اصلاح زمان‌بندی 31. متغیرهای مجموعه‌ای 31-1. مجموعه گره‌ها [ V ] 31-2. مجموعه یال‌ها [ E ] 31-3. مجموعه مسیرها [ R ] 31-4. مجموعه Segmentهای مسیر (r) [ S_r ] 31-5. مجموعه Blockها [ B ] 31-6. مجموعه Blockهای مسیر (r) [ B_r ] 31-7. مجموعه ODها [ \mathcal{OD} ] 31-8. مجموعه بازه‌های زمانی [ T ] 31-9. مجموعه انواع قطار [ K ] 31-10. مجموعه ناوگان [ F ] 32. پارامترهای اصلی نماد تعریف (C_b) ظرفیت بلاک (C_s) ظرفیت بخش مسیر (C_r) ظرفیت مسیر (C_n) ظرفیت شبکه (D_{od,t}) تقاضای بار OD (F_{od,r,t}) جریان قطار OD روی مسیر در زمان (Q_{od,r,t}) جریان بار OD روی مسیر در زمان (P_{r,t}) ظرفیت بارگیری قطار (H) Headway (T_b) زمان اشغال بلاک (T_r) زمان سفر مسیر (U_b) میزان استفاده از بلاک (Slack_b) ظرفیت آزاد بلاک (M) مقدار بزرگ در مدل‌های Big-M (A_t) زمان قابل استفاده (D_{od}) تقاضای کل OD (C^{alloc}) ظرفیت قابل تخصیص (C^{allocated}) ظرفیت تخصیص‌یافته (C^{used}) ظرفیت مصرف‌شده 33. متغیرهای تصمیم متغیر تصمیم، متغیری است که الگوریتم باید مقدار آن را تعیین کند. 33-1. تعداد قطار [ x_{r,t} ] تعداد قطارهای اختصاص‌یافته به Route (r) در زمان (t). 33-2. تخصیص قطار به OD [ x_{od,r,t} ] 33-3. جریان بار [ q_{od,r,t} ] در نسخه نهایی پیشنهاد می‌شود برای جلوگیری از اختلاط با جریان قطار از نماد: [ Q_{od,r,t} ] استفاده شود. 34. متغیرهای دودویی برای انتخاب یا عدم انتخاب یک گزینه: [ y_{r,t}\in{0,1} ] مثلاً: [ y_{r,t}=1 ] یعنی حرکت قطار روی مسیر در بازه زمانی مربوطه انتخاب شده است. 35. متغیرهای پیوسته مانند: [ Q_{od,r,t}\geq0 ] که مقدار بار تخصیص‌یافته را نشان می‌دهد. 36. رابطه بین جریان قطار و جریان بار اگر ظرفیت بارگیری هر قطار: [ P_{r,t} ] باشد: [ Q_{od,r,t} \leq P_{r,t} \times F_{od,r,t} ] 37. قید تقاضا مقدار حمل‌شده نباید از تقاضا بیشتر شود: [ \sum_{r,t}Q_{od,r,t} \leq D_{od} ] 38. قید ظرفیت بلاک برای هر بلاک: [ \sum_{r\in R_b} F_{r,b,t} \leq C_{b,t} ] 39. قید ظرفیت مسیر [ F_{r,t} \leq C_{r,t} ] 40. قید ناوگان اگر تعداد لکوموتیو یا واگن قابل استفاده محدود باشد: [ \sum_{r,t}FleetUse_{r,t} \leq FleetAvailable ] 41. قید طول قطار اگر طول مجاز مسیر: [ L^{max}_{r} ] و طول قطار: [ L^{train} ] باشد: [ L^{train} \leq L^{max}_{r} ] 42. قید وزن قطار [ W^{train} \leq W^{max}_{r} ] 43. قید زمان حرکت برای هر قطار: [ t^{departure} + T_r \leq t^{arrival} ] 44. قید تقاطع در خط یک‌خطه در یک بخش تک‌خطه، دو قطار در جهت مخالف نمی‌توانند همزمان از یک منبع تک‌خطه استفاده کنند. به صورت مفهومی: [ Occupancy_{b,r_1,t} + Occupancy_{b,r_2,t} \leq1 ] 45. زمان‌های غیرقابل استفاده برخی بازه‌ها ممکن است به علت: تعمیرات نگهداری انسداد محدودیت ایمنی عملیات خاص قابل استفاده نباشند. بنابراین: [ A_t\in{0,1} ] می‌تواند معرف دسترس‌پذیری زمان باشد. 46. زمان نماز زمان نماز در این پروژه نباید به صورت یک عدد ثابت از کل زمان کسر شود. بلکه: Prayer Time Window = پنجره زمانی عملیاتی نماز مدل می‌شود. یعنی سیستم بررسی می‌کند: زمان حرکت قطار؛ زمان رسیدن به ایستگاه؛ امکان توقف؛ مدت توقف؛ امکان انجام عملیات؛ اثر توقف بر سایر قطارها. 47. سوخت‌گیری سوخت‌گیری نیز یک زمان عملیاتی است: [ T^{fuel} ] و در صورت نیاز: [ T_r = T^{running} + T^{dwell} + T^{fuel} + T^{brake} + T^{other} ] 48. تست ترمز زمان تست ترمز: [ T^{brake} ] است. این زمان می‌تواند در: مبدأ ایستگاه میانی تغییر ترکیب قطار رخ دهد. 49. زمان تشکیل قطار [ T^{formation} ] باید در صورت نیاز در مدل لحاظ شود. این موضوع خصوصاً برای مدل بازارگاه و تجمیع واگن‌ها اهمیت دارد. 50. قطار خالی قطار خالی نیز جریان واقعی شبکه است و نباید از مدل حذف شود. نماد: [ F^{empty} ] زیرا ممکن است یک قطار خالی: ظرفیت بلاک مصرف کند؛ ظرفیت ایستگاه مصرف کند؛ لکوموتیو مصرف کند؛ زمان‌بندی مسیر را تحت تأثیر قرار دهد. 51. تجمیع واگن در نقاط دوخطه در نقاطی که دوخطه هستند، امکان ایجاد عملیات زیر ممکن است وجود داشته باشد: انتظار تجمیع تفکیک تشکیل قطار تنظیم قطار خالی سبقت تغییر برنامه بنابراین دوخطه بودن فقط یک پارامتر ظرفیت خط نیست و می‌تواند یک منبع عملیاتی اضافی ایجاد کند. 52. تابع هدف الگوریتم بهینه‌سازی باید دارای تابع هدف صریح باشد. یک نمونه: [ \max Z ] که: \alpha_5 \sum ResourceConflict ] است. ضرایب: [ \alpha_1,\alpha_2,\alpha_3,\alpha_4,\alpha_5 ] در سناریو یا تنظیمات سیستم تعریف می‌شوند. 53. انواع تابع هدف سیستم باید حداقل قابلیت تعریف این اهداف را داشته باشد: هدف 1 – بیشینه‌سازی بار [ \max \sum Q ] هدف 2 – بیشینه‌سازی تن-کیلومتر [ \max \sum Q\times Distance ] هدف 3 – بیشینه‌سازی ارزش اقتصادی [ \max \sum EconomicValue ] هدف 4 – کمینه‌سازی تأخیر [ \min \sum Delay ] هدف 5 – تابع هدف ترکیبی [ \max Z ] 54. قیود سخت و نرم Hard Constraint قیدی که نقض آن غیرمجاز است. مثلاً: [ F_b>C_b ] غیرمجاز است. Soft Constraint قیدی که در صورت ضرورت می‌توان با جریمه آن را نقض کرد. مثلاً: ترجیح یک مسیر حداقل سهم یک مسیر ترجیح زمانی سطح مطلوب استفاده از ناوگان 55. سهم حداقلی مسیر اگر سیاست شبکه مقرر کند حداقل سهمی برای مسیر (r) حفظ شود: [ F_r \geq MinimumShare_r ] 56. تخصیص ظرفیت آزاد اگر ظرفیت یک مسیر در دوره موردنظر به‌طور کامل استفاده نشود: [ Slack_r>0 ] سیستم می‌تواند، در صورت مجاز بودن سیاست: [ Slack_r \rightarrow R_{competing} ] را بررسی کند. اما انتقال ظرفیت باید مشروط به قیود سیاستی باشد. 57. سهم طولی و عرضی برای گلوگاه‌های حساس می‌توان دو نوع سهم تعریف کرد. سهم طولی حفظ حداقل ظرفیت برای یک مسیر مشخص. سهم عرضی حفظ ظرفیت برای یک دسته از مسیرها یا بازارها. این سیاست‌ها باید در مدل به عنوان Constraint قابل تنظیم باشند، نه اینکه در الگوریتم به صورت Hard-Coded قرار گیرند. 58. گلوگاه گلوگاه: [ Bottleneck ] منبعی است که ظرفیت آن نسبت به تقاضا یا جریان موردنیاز محدودکننده است. مثلاً: [ U_b= \frac{F_b}{C_b} ] اگر: [ U_b\rightarrow1 ] شود، منبع به محدوده اشباع نزدیک شده است. 59. شاخص استفاده [ U_b= \frac{F_b}{C_b} ] و به عنوان: Block Utilization = میزان استفاده از ظرفیت بلاک ثبت می‌شود. 60. حاشیه ظرفیت [ CM_b= C_b-F_b ] که همان ظرفیت آزاد است. در صورت نیاز می‌توان حاشیه نسبی را نیز تعریف کرد: \frac{C_b-F_b}{C_b} ] 61. تقاضای برآورده‌نشده D_{od} \sum_{r,t}Q_{od,r,t} ] در صورتی که مقدار حاصل مثبت باشد. 62. ظرفیت بلااستفاده اگر: [ C^{operational}>C^{used} ] باشد: C^{operational} C^{used} ] 63. ظرفیت پنهان شبکه می‌توان ظرفیت پنهان را به صورت اختلاف بین ظرفیت فعلی و ظرفیت قابل دستیابی پس از اصلاح بهره‌برداری تعریف کرد: C^{optimized\ operational} C^{current\ operational} ] مشروط به اینکه هیچ سرمایه‌گذاری زیرساختی جدیدی در سناریو انجام نشده باشد. 64. ظرفیت افزوده ناشی از سرمایه‌گذاری برای سنجش اثر یک پروژه زیرساختی: C^{development} C^{base} ] 65. هزینه هر واحد ظرفیت افزوده اگر هزینه پروژه: [ Cost_{project} ] و ظرفیت افزوده: [ \Delta C ] باشد: \frac{Cost_{project}} {\Delta C} ] واحد آن بسته به تعریف Capacity می‌تواند مثلاً: تومان به ازای قطار در روز تومان به ازای تن در روز تومان به ازای تن-کیلومتر باشد. 66. اصل مهم در واحدها هر متغیر باید واحد مشخص داشته باشد. مثلاً: [ C_b = train/day ] یا: [ C_b = train/hour ] نباید در بخشی از نرم‌افزار به صورت train/day و در بخش دیگر بدون تبدیل به صورت train/month استفاده شود. بنابراین: Unit Conversion باید یک لایه رسمی در موتور باشد. 67. دامنه زمانی تمام محاسبات ظرفیت باید دارای Period باشند. مثلاً: [ t \in {hour,day,month,year} ] اما مدل محاسباتی پایه بهتر است بر مبنای: Time Horizon + Time Slot ساخته شود. مثلاً: [ T={t_1,t_2,\ldots,t_n} ] 68. ظرفیت روزانه و سالانه اگر ظرفیت روزانه: [ C^{day} ] باشد، ظرفیت سالانه الزاماً برابر: [ 365C^{day} ] نیست؛ زیرا باید مواردی مانند: تعمیرات تعطیلی فصل محدودیت انرژی شرایط جوی تغییر تقاضا ظرفیت قابل اتکا در نظر گرفته شود. 69. ظرفیت قابل اتکا در صورت تعریف ضریب اطمینان: C^{operational} \times ReliabilityFactor ] اما ReliabilityFactor باید بر اساس داده واقعی و روش آماری مشخص شود و نباید یک ضریب دلخواه ثابت باشد. 70. تحلیل حساسیت برای پارامتر (p): \frac{\Delta C}{\Delta p} ] در ساده‌ترین حالت، تغییر ظرفیت نسبت به تغییر پارامتر بررسی می‌شود. پارامترهای مهم: سرعت Headway طول بلاک طول ایستگاه تعداد خطوط ایستگاه دوخطه شدن زمان توقف زمان سوخت‌گیری زمان تشکیل قطار تعداد لکوموتیو تعداد واگن تقاضا 71. سناریوی Base تمام تحلیل‌ها باید یک: [ Scenario_{base} ] داشته باشند. تمام سناریوهای توسعه نسبت به آن مقایسه می‌شوند. 72. سناریوی توسعه [ Scenario_k ] می‌تواند یک یا چند تغییر داشته باشد. مثلاً: [ Scenario_1: DoubleTrack(S_7) ] یا: [ Scenario_2: Headway-10% ] یا: [ Scenario_3: DoubleTrack(S_7)+StationExpansion(S_8) ] 73. مقایسه سناریوها برای هر سناریو باید حداقل این خروجی‌ها تولید شود: ظرفیت مسیر ظرفیت شبکه ظرفیت هر گلوگاه جریان قطار جریان بار ظرفیت آزاد تقاضای برآورده‌نشده تعداد قطار تن-کیلومتر هزینه سرمایه‌گذاری ظرفیت افزوده هزینه هر واحد ظرفیت افزوده 74. اصل Explainable Capacity هر مقدار ظرفیت تولیدشده باید قابل توضیح باشد. مثلاً اگر سیستم اعلام کند: [ C_r=42\ train/day ] کاربر باید بتواند بفهمد: کدام بلاک محدودکننده بوده؛ Headway چقدر بوده؛ زمان سفر چقدر بوده؛ کدام ایستگاه محدودکننده بوده؛ چه تعداد قطار مخالف وجود داشته؛ چه زمانی برای تعمیرات حذف شده؛ چه محدودیت ناوگانی اعمال شده؛ چه Constraint سیاستی فعال بوده است. بنابراین: هیچ خروجی ظرفیت مهمی نباید یک «عدد سیاه» باشد. 75. موتور تولید ظرفیت وظیفه: [ CapacityGenerationEngine ] تولید ظرفیت پایه بر اساس زیرساخت و قواعد عملیاتی است. خروجی: [ C^{technical} ] و: [ C^{operational} ] در سطوح مختلف. 76. موتور بهینه‌سازی شبکه وظیفه: [ NetworkOptimizationEngine ] حل همزمان تعارض‌های شبکه است. ورودی: مسیرها تقاضا ظرفیت بلاک ظرفیت ایستگاه ناوگان زمان‌بندی سیاست‌ها خروجی: [ C_n ] و جریان بهینه. 77. موتور تخصیص ظرفیت این موتور در مرحله بعدی قرار می‌گیرد. [ CapacityAllocationEngine ] وظیفه آن: تخصیص ظرفیت به متقاضیان پس از مشخص شدن ظرفیت قابل عرضه و قابل تخصیص شبکه است. بنابراین: [ Generation \rightarrow Optimization \rightarrow Allocation ] سه مرحله متفاوت‌اند. 78. رابطه با بازارگاه ریلی در معماری نهایی: [ CapacityEngine \rightarrow Marketplace \rightarrow Allocation/Auction ] خواهد بود. موتور ظرفیت نباید از ابتدا در منطق بازارگاه ادغام شود. 79. اصل جداسازی مدل ظرفیت از سیاست سیاست‌هایی مانند: حداقل سهم مسیر اولویت بار اولویت مشتری اولویت منطقه سهمیه رزرو ظرفیت نباید در منطق پایه Capacity به صورت ثابت کدنویسی شوند. بلکه باید: [ PolicyParameter ] باشند. این کار امکان تغییر سیاست بدون بازنویسی موتور ریاضی را فراهم می‌کند. 80. مدل کلی مسئله صورت کلی مسئله: [ G=(V,E) ] با مجموعه: [ R,\ B,\ S,\ OD,\ T,\ K,\ F ] و پارامترهای: [ C,\ D,\ P,\ H,\ T ] است. هدف: [ Optimize(F,Q) ] تحت قیود: [ Capacity ] [ Demand ] [ Time ] [ Fleet ] [ Station ] [ Safety ] [ Policy ] 81. فرم کلی مدل بهینه‌سازی [ \max Z(x,q) ] subject to: [ \sum_r F_{r,b,t} \leq C_{b,t} ] [ \sum_{r,t}Q_{od,r,t} \leq D_{od} ] [ Q_{od,r,t} \leq P_{r,t}F_{od,r,t} ] [ FleetUse_t \leq FleetAvailable_t ] [ StationUse_t \leq StationCapacity_t ] و سایر قیود. 82. نکته مهم درباره روش حل انتخاب Solver نباید در این مرحله به یک فناوری خاص محدود شود. مسئله ممکن است بسته به ابعاد و نوع داده با روش‌های زیر حل شود: Linear Programming Mixed Integer Linear Programming Constraint Programming Network Flow Time-Expanded Network Heuristic Metaheuristic Decomposition Hybrid Optimization انتخاب نهایی Solver پس از مشخص شدن اندازه واقعی شبکه و سطح جزئیات زمانی انجام خواهد شد. 83. مدل Time-Expanded Network برای مدل‌های دقیق زمانی، شبکه می‌تواند به شکل: [ G_T=(V_T,E_T) ] گسترش یابد. در این مدل، یک گره فقط «ایستگاه» نیست، بلکه: [ Station + Time ] است. این روش برای مدل‌سازی: Headway تقاطع عبور زمان انتظار پنجره تعمیرات برنامه حرکت مناسب است. 84. تشخیص تعارض برای دو حرکت: [ Train_i ] و: [ Train_j ] تعارض زمانی زمانی رخ می‌دهد که: [ Resource_i\cap Resource_j\neq\emptyset ] و: [ Time_i\cap Time_j\neq\emptyset ] باشد. در این حالت: [ Conflict(i,j)=1 ] 85. تعارض مسیر دو مسیر زمانی رقیب هستند که حداقل یک Resource مشترک داشته باشند: [ R_i\cap R_j\neq\emptyset ] اما صرف اشتراک مسیر به معنی تعارض قطعی نیست. تعارض واقعی تابع زمان استفاده است. این تفکیک برای الگوریتم بسیار مهم است. 86. ظرفیت اسمی و ظرفیت واقعی سیستم باید دو مفهوم را جدا نگه دارد: ظرفیت اسمی ظرفیتی که صرفاً بر اساس مشخصات فنی به دست می‌آید. ظرفیت قابل تحقق ظرفیتی که پس از شبیه‌سازی/بهینه‌سازی شرایط واقعی حاصل می‌شود. 87. کالیبراسیون مدل پس از اجرای واقعی برنامه: [ ActualData ] با: [ ModelOutput ] مقایسه می‌شود. خطا: [ Error= Actual-Model ] و مدل باید قابلیت Calibration داشته باشد. 88. حلقه یادگیری مدل ساختار نهایی: [ Infrastructure \rightarrow Model \rightarrow Optimization \rightarrow Plan \rightarrow ActualOperation \rightarrow Calibration \rightarrow Model ] خواهد بود. 89. اصل نسخه‌پذیری هر اجرای ظرفیت باید دارای: Scenario ID Model Version Data Version Algorithm Version Run ID Timestamp باشد. تا مشخص باشد عدد ظرفیت چگونه تولید شده است. 90. اصل بازتولیدپذیری اگر: [ DataVersion ] و: [ ModelVersion ] و: [ ScenarioVersion ] یکسان باشند، اجرای مدل باید تا حد امکان نتیجه یکسان تولید کند. 91. اصل ثبت تصمیم الگوریتم سیستم باید بتواند مشخص کند چرا یک تصمیم گرفته شده است. مثلاً: مسیر A انتخاب نشد زیرا ظرفیت بلاک B در ساعت 14:00 تکمیل شده بود. یا: ظرفیت مسیر C کاهش یافت زیرا محدودیت تعمیراتی در Segment S12 فعال بود. 92. حداقل خروجی هر اجرای مدل هر Run باید حداقل این خروجی‌ها را داشته باشد: ظرفیت بلاک‌ها؛ ظرفیت Segmentها؛ ظرفیت مسیرها؛ ظرفیت شبکه؛ جریان قطار؛ جریان بار؛ گلوگاه‌ها؛ ظرفیت آزاد؛ ظرفیت از دست‌رفته؛ تقاضای برآورده‌نشده؛ شاخص استفاده؛ علت محدودکنندگی؛ سناریو؛ نسخه داده؛ زمان اجرای مدل. 93. قرارداد نام‌گذاری در Database و API استفاده از نام‌های مبهم ممنوع است. قابل قبول: capacity block_capacity segment_capacity route_capacity network_capacity train_payload traction_power headway block_occupancy_time نام‌های نامطلوب: power ability capacity_value transport_power مگر اینکه دقیقاً تعریف شده باشند. 94. قرارداد نمادگذاری نهایی در نسخه فعلی، نمادهای اصلی به شرح زیر تثبیت می‌شوند: نماد معنی رسمی (G) شبکه (V) مجموعه گره‌ها (E) مجموعه یال‌ها (R) مجموعه مسیرها (r) یک مسیر (S) مجموعه بخش‌ها (s) یک بخش (B) مجموعه بلاک‌ها (b) یک بلاک (OD) مجموعه جفت‌های مبدأ–مقصد (od) یک جفت مبدأ–مقصد (T) مجموعه بازه‌های زمانی (t) یک بازه زمانی (C_b) ظرفیت بلاک (C_s) ظرفیت بخش (C_r) ظرفیت مسیر (C_n) ظرفیت شبکه (D_{od,t}) تقاضای OD (F_{od,r,t}) جریان قطار OD (Q_{od,r,t}) جریان بار OD (P_{r,t}) ظرفیت بارگیری قطار (H) Headway (T_b) زمان اشغال بلاک (T_r) زمان سفر مسیر (U_b) میزان استفاده بلاک (Slack_b) ظرفیت آزاد بلاک (x) متغیر تصمیم (y) متغیر دودویی تصمیم (Z) تابع هدف 95. قاعده مهم درباره F و Q برای جلوگیری از ابهام: [ F = Flow\ of\ Trains ] و: [ Q = Flow\ of\ Cargo ] بنابراین: F هیچ‌گاه به معنی مقدار بار نیست. و: Q هیچ‌گاه به معنی تعداد قطار نیست. 96. قاعده مهم درباره C هرگاه نماد: [ C ] بدون Subscript استفاده شود، باید نوع Capacity از متن یا Context مشخص باشد. اما در Database و API توصیه می‌شود همیشه نوع آن مشخص باشد. مثلاً: block_capacity segment_capacity route_capacity network_capacity allocated_capacity used_capacity 97. قاعده مهم درباره دوره زمانی هیچ ظرفیت عددی بدون Period معتبر نیست. مثلاً: [ C_r=40 ] به تنهایی اطلاعات ناقصی است. باید مشخص شود: [ C_r=40\ train/day ] یا: [ C_r=40\ train/hour ] 98. قاعده مهم درباره نوع قطار ظرفیت مسیر باید در صورت تأثیر نوع قطار، با Train Type مرتبط باشد. بنابراین: [ C_r^{freight} ] ممکن است با: [ C_r^{passenger} ] متفاوت باشد. حتی برای دو نوع قطار باری نیز ممکن است: [ C_r^{heavy} \neq C_r^{light} ] باشد. 99. قاعده مهم درباره بارگیری ظرفیت مسیر به تن را باید از تعداد قطار جدا کرد. مثلاً: [ C_r=20\ train/day ] و: [ P_r=3000\ ton/train ] در این صورت ظرفیت نظری بار: 20\times3000 60000\ ton/day ] است. اما این مقدار فقط زمانی معتبر است که ظرفیت بارگیری قطار در تمام حرکت‌ها واقعاً قابل تحقق باشد. 100. اصل تفکیک Capacity و Payload رابطه: [ NetworkCapacity \neq TrainPayload ] است. ظرفیت شبکه بیانگر میزان امکان استفاده از شبکه است. ظرفیت بارگیری قطار بیانگر مقدار بار هر قطار است. 101. اصل تفکیک Capacity و Traction توان کشش تعیین می‌کند قطار چه وزنی را می‌تواند بکشد. ظرفیت شبکه تعیین می‌کند چند حرکت و با چه شرایطی می‌توان در شبکه انجام داد. بنابراین: [ Traction \rightarrow TrainPayload ] اما: [ NetworkCapacity \rightarrow TrainFlow ] و سپس: [ TrainFlow\times TrainPayload \rightarrow CargoFlow ] 102. زنجیره رسمی مدل مدل اصلی پروژه به صورت زیر تثبیت می‌شود: [ Infrastructure ] ↓ [ Operational\ Parameters ] ↓ [ Block/Segment\ Capacity ] ↓ [ Route\ Capacity ] ↓ [ Network\ Optimization ] ↓ [ Network\ Capacity ] ↓ [ Available/Marketable\ Capacity ] ↓ [ Capacity\ Allocation ] ↓ [ Actual\ Utilization ] ↓ [ Calibration ] 103. معماری منطقی موتور موتور به پنج لایه اصلی تقسیم خواهد شد: Layer 1 – Data اطلاعات خام و پایه. Layer 2 – Calculation محاسبه پارامترهای فنی و عملیاتی. Layer 3 – Optimization بهینه‌سازی ظرفیت و جریان. Layer 4 – Policy اعمال سیاست‌ها و سهمیه‌ها. Layer 5 – Output گزارش، GIS، API و انتقال به بازارگاه. 104. ماژول‌های اصلی M1 – Infrastructure Capacity Engine محاسبه ظرفیت زیرساخت. M2 – Operational Capacity Engine اعمال شرایط بهره‌برداری. M3 – Route Capacity Engine محاسبه ظرفیت مسیر. M4 – Network Optimization Engine بهینه‌سازی همزمان شبکه. M5 – Scenario & Sensitivity Engine تحلیل سناریو و حساسیت. M6 – Capacity Explanation Engine توضیح علت ظرفیت. M7 – Capacity Visualization Engine نمایش GIS و داشبورد. M8 – Calibration Engine مقایسه مدل با عملکرد واقعی. 105. ترتیب محاسبه در اجرای استاندارد: مرحله 1 دریافت شبکه. مرحله 2 تولید Segment و Block. مرحله 3 دریافت مشخصات قطار. مرحله 4 محاسبه سرعت و زمان حرکت. مرحله 5 محاسبه زمان اشغال. مرحله 6 محاسبه Headway. مرحله 7 محاسبه ظرفیت بلاک. مرحله 8 محاسبه ظرفیت Segment. مرحله 9 تعریف مسیرهای OD. مرحله 10 تشخیص منابع مشترک. مرحله 11 تشخیص تعارض‌ها. مرحله 12 تشکیل مدل شبکه. مرحله 13 اجرای Optimization. مرحله 14 محاسبه ظرفیت مسیر و شبکه. مرحله 15 اجرای سناریوها. مرحله 16 تولید گزارش Explainable Capacity. 106. خروجی نهایی موتور خروجی اصلی موتور باید حداقل شامل: [ {C_b,C_s,C_r,C_n} ] باشد. به همراه: [ {F,Q,D,U,Slack,Lost,Unserved} ] و اطلاعات: [ {Scenario,Constraint,Bottleneck,Explanation} ] 107. معیار موفقیت مدل مدل صرفاً زمانی موفق نیست که یک عدد ظرفیت تولید کند. بلکه باید: قابل توضیح باشد؛ قابل بازتولید باشد؛ قابل کالیبراسیون باشد؛ قابلیت سناریوسازی داشته باشد؛ محدودیت‌های واقعی را لحاظ کند؛ امکان اتصال به GIS داشته باشد؛ امکان اتصال به سامانه‌های عملیاتی داشته باشد؛ امکان اتصال به بازارگاه داشته باشد؛ قابلیت توسعه الگوریتمی داشته باشد؛ بتواند از داده واقعی یاد بگیرد. 108. واژه‌نامه ریاضی و الگوریتمی رسمی A – مجموعه‌ها Set — مجموعه Node (V) — گره Edge (E) — یال Route (R) — مسیر Segment (S) — بخش مسیر Block (B) — بلاک OD — جفت مبدأ–مقصد Time Set (T) — مجموعه زمانی Train Type (K) — نوع قطار B – پارامترها (C_b) — ظرفیت بلاک (C_s) — ظرفیت بخش مسیر (C_r) — ظرفیت مسیر (C_n) — ظرفیت شبکه (D_{od,t}) — تقاضای OD (P_{r,t}) — ظرفیت بارگیری قطار (H) — فاصله زمانی مجاز (T_b) — زمان اشغال بلاک (T_r) — زمان سفر مسیر (A_t) — دسترس‌پذیری زمانی C – متغیرهای تصمیم (x) — متغیر تصمیم (x_{r,t}) — تعداد/انتخاب قطار مسیر (x_{od,r,t}) — تخصیص حرکت به OD (y_{r,t}) — متغیر دودویی انتخاب (Q_{od,r,t}) — جریان بار D – متغیرهای مشتق‌شده (U_b) — میزان استفاده بلاک (Slack_b) — ظرفیت آزاد بلاک (LostCapacity) — ظرفیت از دست‌رفته (UnservedDemand) — تقاضای برآورده‌نشده (\Delta C) — ظرفیت افزوده E – قیود Capacity Constraint — قید ظرفیت Demand Constraint — قید تقاضا Fleet Constraint — قید ناوگان Time Constraint — قید زمانی Station Constraint — قید ایستگاه Safety Constraint — قید ایمنی Policy Constraint — قید سیاستی F – بهینه‌سازی Objective Function (Z) — تابع هدف Decision Variable — متغیر تصمیم Feasible Solution — جواب شدنی Optimal Solution — جواب بهینه Constraint — قید Penalty — جریمه Weight (\alpha) — وزن Scenario — سناریو Sensitivity Analysis — تحلیل حساسیت 109. قرارداد نهایی برای تیم نرم‌افزار از این مرحله به بعد، موارد زیر باید به عنوان قرارداد رسمی پروژه تلقی شوند: قرارداد 1 Capacity فقط «ظرفیت» است. قرارداد 2 (C_b)، (C_s)، (C_r)، (C_n) چهار مفهوم متفاوت‌اند. قرارداد 3 (F) جریان قطار و (Q) جریان بار است. قرارداد 4 (D) تقاضا است، نه جریان. قرارداد 5 (P) ظرفیت بارگیری قطار است، نه ظرفیت شبکه. قرارداد 6 Traction Power با Capacity متفاوت است. قرارداد 7 Route با Segment و Block متفاوت است. قرارداد 8 دوخطه شدن Segment، Route جدید ایجاد نمی‌کند. قرارداد 9 ظرفیت شبکه حاصل جمع ساده ظرفیت مسیرها نیست. قرارداد 10 هیچ ظرفیت عددی بدون واحد و دوره زمانی معتبر نیست. قرارداد 11 سیاست‌های تخصیص نباید در هسته ریاضی Capacity به صورت Hard-Coded قرار گیرند. قرارداد 12 تمام خروجی‌های مهم باید Explainable باشند. قرارداد 13 تمام اجرای مدل باید Version و Scenario داشته باشد. قرارداد 14 مدل باید قابلیت Calibration با داده واقعی داشته باشد. 110. مرحله بعدی پروژه: معماری داده پس از تثبیت این سند، ورود به معماری داده باید دقیقاً بر اساس همین قرارداد انجام شود. مرحله بعد شامل چهار سند فنی خواهد بود: سند D1 – Data Domain Model تعریف موجودیت‌های اصلی: Network Node Station Segment Block Route OD Train Wagon Locomotive Fleet Demand Constraint Scenario Capacity Result Optimization Run سند D2 – ERD طراحی روابط: [ Network \rightarrow Route \rightarrow Segment \rightarrow Block ] و: [ OD \rightarrow Route \rightarrow Demand ] و: [ Train \rightarrow Fleet \rightarrow Capacity ] و: [ Scenario \rightarrow OptimizationRun \rightarrow CapacityResult ] سند D3 – Data Dictionary برای تک‌تک فیلدها: نام فارسی نام انگلیسی نام Database نوع داده طول واحد اجباری/اختیاری کلید اصلی کلید خارجی دامنه مقادیر Validation Rule منبع داده دوره به‌روزرسانی تعریف خواهد شد. سند D4 – API Contract APIهای اصلی: /network /routes /segments /blocks /stations /od-pairs /demand /trains /fleet /scenarios /capacity/calculate /capacity/optimize /capacity/explain /capacity/sensitivity /optimization/runs /results و برای هر API: Request Response Authentication Validation Error Codes Version Pagination Audit Performance مشخص خواهد شد. 111. نقطه کنترل قبل از ورود به معماری داده قبل از طراحی ERD باید این پنج موضوع نهایی شوند: [ 1.\ Vocabulary ] [ 2.\ Mathematical\ Notation ] [ 3.\ Units ] [ 4.\ Time\ Model ] [ 5.\ Entity\ Boundaries ] در این نسخه، چهار مورد اول در سطح پایه تثبیت شده‌اند و در مرحله معماری داده باید به قواعد اجرایی پایگاه داده تبدیل شوند. 112. نتیجه نهایی این نسخه از این مرحله به بعد، مدل رسمی پروژه چنین خوانده می‌شود: [ \boxed{ Infrastructure \rightarrow Capacity \rightarrow Optimization \rightarrow Allocation \rightarrow Utilization } ] و در سطح ریاضی: [ \boxed{ C_b \rightarrow C_s \rightarrow C_r \rightarrow C_n } ] در کنار: [ \boxed{ D_{od} \rightarrow F_{od,r,t} \rightarrow Q_{od,r,t} } ] و تمام این روابط تحت: [ \boxed{ Constraints + Objective + Scenario } ] حل خواهند شد. بنابراین این نسخه، مرجع اصطلاحات، نمادها و منطق ریاضی پروژه خواهد بود و معماری داده، API و کدنویسی باید با آن سازگار باشند. گام بعدی را پیشنهاد می‌کنم مستقیماً روی «معماری داده نسخه D1» ببریم؛ یعنی قبل از رسم ERD، ابتدا موجودیت‌های واقعی سیستم را یکی‌یکی تعریف کنیم و مشخص کنیم مثلاً Route، Segment، Block، Station، OD، Demand، Train، Fleet، Scenario و Capacity Result دقیقاً چه هستند، چه تفاوتی دارند و رابطه‌شان چیست. بعد از آن ERD را طراحی می‌کنیم تا پایگاه داده از ابتدا بر مبنای همین مدل ریاضی ساخته شود. --- ## Prompt 8 — پرسش کاربر (`conversation-turn-15`) لطفا در سندی که آماده کردی نمادهای ریاضی رو تا حد ممکن به صورت مجزا در انتها به صورت دیباچه بیار که متن راحتتر قابل خوندن باشد ## Prompt 8 — پاسخ دستیار (`conversation-turn-16`) بله. این اصلاح از نظر خوانایی کاملاً درست است. بهتر است متن اصلی سند تقریباً بدون نمادگذاری ریاضی سنگین خوانده شود و همه نمادها، روابط، مجموعه‌ها، پارامترها و متغیرهای تصمیم در انتهای سند در قالب یک «دیباچه/پیوست ریاضی و الگوریتمی» متمرکز شوند. در نسخه اصلاح‌شده، در متن اصلی به‌جای نمایش فرمول، ابتدا مفهوم با زبان طبیعی بیان می‌شود و فقط در موارد ضروری به نام مفهومی آن اشاره می‌کنیم. سپس در انتها، «دیباچه ریاضی و الگوریتمی» مرجع رسمی تمام نمادها خواهد بود. سند مشخصات فنی، مفهومی و الگوریتمی موتور تولید، برآورد و بهینه‌سازی ظرفیت ریلی بسمه تعالی سند مشخصات فنی، مفهومی و الگوریتمی موتور تولید، برآورد و بهینه‌سازی ظرفیت ریلی Rail Capacity Generation, Estimation & Network Optimization Engine نسخه: مبنای طراحی نرم‌افزار – ویرایش تثبیت مفاهیم و مدل ریاضی وضعیت: مبنای ورود به مرحله معماری داده و طراحی ERD دامنه: شبکه حمل‌ونقل ریلی بار بخش اول ـ کلیات و فلسفه طراحی 1. هدف سند این سند مبنای طراحی نرم‌افزاری، مفهومی، محاسباتی و الگوریتمی موتور تولید، برآورد و بهینه‌سازی ظرفیت ریلی است. هدف موتور آن است که با دریافت اطلاعات زیرساخت، مسیرها، ایستگاه‌ها، قطارها، ناوگان، تقاضای بار، محدودیت‌های عملیاتی، قواعد بهره‌برداری و سیاست‌های شبکه بتواند: ظرفیت بخش‌های مختلف شبکه را محاسبه کند؛ ظرفیت مسیرهای مبدأ–مقصد را برآورد کند؛ ظرفیت مسیرهای دارای منابع مشترک را به‌صورت همزمان محاسبه کند؛ گلوگاه‌های شبکه را شناسایی کند؛ ظرفیت از دست‌رفته و ظرفیت پنهان را شناسایی کند؛ اثر تغییرات زیرساختی و عملیاتی را بر ظرفیت مشخص کند؛ تقاضای موجود و بالقوه را با ظرفیت مقایسه کند؛ ظرفیت کل شبکه را با توجه به تعارض‌ها و محدودیت‌ها بهینه کند؛ ظرفیت قابل عرضه و قابل تخصیص را برای موتورهای بعدی آماده کند؛ نتایج واقعی بهره‌برداری را دریافت و مدل را کالیبره کند. 2. اصل بنیادین پروژه: Capacity فقط «ظرفیت» یکی از مهم‌ترین تصمیمات واژگانی این پروژه آن است که: Capacity در تمام اجزای پروژه صرفاً «ظرفیت» ترجمه می‌شود. اصطلاحاتی مانند: توان حمل ظرفیت حمل گنجایش توان عبور توان عملیاتی نباید بدون تعریف مستقل به‌عنوان مترادف Capacity استفاده شوند. این قاعده باید در: سند فنی پایگاه داده API رابط کاربری گزارش‌ها الگوریتم‌ها مستندات توسعه داشبوردها رعایت شود. 3. ضرورت تفکیک مفاهیم در یک سیستم حرفه‌ای ظرفیت ریلی، چند مفهوم متفاوت ممکن است در نگاه اول مشابه به نظر برسند. برای مثال: ظرفیت شبکه با ظرفیت بارگیری قطار یکی نیست. ظرفیت شبکه با توان کشش لکوموتیو یکی نیست. ظرفیت مسیر با تعداد قطار قابل برنامه‌ریزی یکی نیست. تقاضای بار با جریان واقعی بار یکی نیست. ظرفیت قابل عرضه با ظرفیت تخصیص‌یافته یکی نیست. این تفکیک باید از مرحله مدل مفهومی تا طراحی Database و کدنویسی حفظ شود. 4. ظرفیت و توان کشش توان کشش لکوموتیو بیانگر قابلیت آن برای کشیدن قطار تحت شرایط مشخص است. این مفهوم به عواملی مانند: توان لکوموتیو نیروی کشش وزن قطار شیب مسیر سرعت شرایط خط تعداد لکوموتیو وابسته است. اما ظرفیت شبکه به امکان انجام حرکت‌های ریلی در شبکه مربوط است. بنابراین ممکن است: یک قطار به دلیل محدودیت کشش نتواند با وزن مشخص حرکت کند؛ ولی خود مسیر از نظر ظرفیت زمانی امکان حرکت قطارهای بیشتری را داشته باشد. این دو موضوع باید در مدل جداگانه نگهداری شوند. 5. ظرفیت بارگیری قطار ظرفیت بارگیری قطار عبارت است از مقدار باری که یک قطار مشخص تحت شرایط مشخص می‌تواند حمل کند. این مفهوم می‌تواند تحت تأثیر موارد زیر قرار گیرد: تعداد واگن نوع واگن وزن مجاز طول قطار توان کشش شیب مسیر محدودیت‌های مسیر مقررات بهره‌برداری بنابراین ظرفیت بارگیری قطار یکی از ورودی‌های مدل ظرفیت شبکه است، نه مترادف آن. 6. جریان قطار و جریان بار در مدل پروژه دو جریان اصلی باید از یکدیگر تفکیک شوند: جریان قطار تعداد قطارهایی که در یک مسیر، برای یک مبدأ–مقصد و در یک بازه زمانی حرکت می‌کنند. جریان بار مقدار باری که توسط آن قطارها حمل می‌شود. این تفکیک در پایگاه داده نیز باید حفظ شود. بخش دوم ـ ساختار مفهومی شبکه 7. مدل شبکه ریلی شبکه ریلی از اجزای فضایی و عملیاتی مختلف تشکیل می‌شود. اجزای اصلی عبارت‌اند از: گره‌ها ایستگاه‌ها بخش‌های خط بلاک‌ها مسیرها مسیرهای مبدأ–مقصد منابع مشترک مدل شبکه باید بتواند وضعیت فعلی و سناریوهای آینده را نگهداری کند. 8. Route ـ مسیر در این پروژه: Route = مسیر مسیر یک موجودیت عملیاتی مستقل است که می‌تواند از چند بخش خط و چندین بلاک تشکیل شود. یک مسیر ممکن است: کاملاً تک‌خطه باشد؛ کاملاً دوخطه باشد؛ ترکیبی از تک‌خطه و دوخطه باشد. Route یک مفهوم مستقل از وضعیت فیزیکی هر Segment است. 9. Segment �� بخش مسیر Segment بخشی از مسیر است که دارای مجموعه مشخصی از ویژگی‌های زیرساختی و عملیاتی است. از جمله: طول وضعیت تک‌خطه یا دوخطه سرعت مجاز سرعت مؤثر شیب قوس وضعیت خط مشخصات ریل محدودیت‌های بهره‌برداری محدودیت‌های تعمیراتی 10. Block ـ بلاک Block واحد عملیاتی مهمی برای کنترل حرکت و محاسبه ظرفیت است. برای هر بلاک می‌توان اطلاعاتی مانند: طول سیستم علائم سرعت زمان اشغال جهت حرکت محدودیت‌های ایمنی محدودیت‌های عملیاتی را ثبت کرد. 11. بلاک مشترک اگر چند مسیر از یک بلاک استفاده کنند، آن بلاک یک منبع مشترک محسوب می‌شود. بنابراین ظرفیت آن بلاک باید میان جریان‌های مختلف تقسیم شود. این موضوع یکی از اصلی‌ترین دلایل آن است که ظرفیت کل شبکه را نمی‌توان با جمع ساده ظرفیت مسیرها محاسبه کرد. 12. گلوگاه گلوگاه هر منبعی است که محدودیت آن باعث محدود شدن جریان شبکه شود. گلوگاه می‌تواند: بلاک Segment ایستگاه خط ورودی یا خروجی ایستگاه محل تقاطع محل سبقت ناوگان زمان ظرفیت تشکیل قطار ظرفیت بارگیری یا یک قید سیاستی باشد. 13. تک‌خطه و دوخطه در مدل پروژه وضعیت خط هر Segment به‌صورت مستقل ثبت می‌شود. دوخطه شدن یک Segment به معنی ایجاد Route جدید نیست. بلکه ویژگی همان Segment تغییر می‌کند. بنابراین Route باید موجودیتی پایدار باقی بماند. 14. مسیرهای ترکیبی تک‌خطه و دوخطه در بسیاری از خطوط ریلی، مسیر از ترکیب بخش‌های تک‌خطه و دوخطه تشکیل شده است. مدل باید این حالت را به‌صورت طبیعی پشتیبانی کند. در چنین مسیری، بخش دوخطه ممکن است علاوه بر افزایش ظرفیت عبور، امکان‌هایی مانند: انتظار سبقت تجمیع واگن تفکیک واگن تشکیل قطار تنظیم قطار خالی اصلاح زمان‌بندی را فراهم کند. بنابراین اثر دوخطه شدن نباید صرفاً به یک ضریب افزایش ظرفیت تقلیل یابد. بخش سوم ـ سطوح ظرفیت 15. ظرفیت نظری ظرفیت نظری، ظرفیت حاصل از یک مدل پایه و ساده است که همه محدودیت‌های واقعی بهره‌برداری را در نظر نمی‌گیرد. این ظرفیت بیشتر برای تحلیل اولیه و مقایسه‌ای کاربرد دارد. 16. ظرفیت فنی ظرفیت فنی با توجه به ویژگی‌های فنی زیرساخت و تجهیزات محاسبه می‌شود. 17. ظرفیت عملیاتی ظرفیت عملیاتی، ظرفیت حاصل از اعمال قواعد واقعی بهره‌برداری است. در این سطح مواردی مانند: برنامه حرکت Headway توقف تقاطع سبقت تشکیل قطار تست ترمز سوخت‌گیری محدودیت ایستگاه تعمیرات محدودیت‌های زمانی در نظر گرفته می‌شوند. 18. ظرفیت قابل اتکا ظرفیتی است که با توجه به قابلیت اطمینان شبکه و احتمال اختلال، بتوان روی آن در برنامه‌ریزی حساب کرد. 19. ظرفیت قابل عرضه ظرفیتی که سازمان بهره‌بردار تصمیم گرفته است برای عرضه به بازار یا متقاضیان ارائه کند. این ظرفیت ممکن است از ظرفیت عملیاتی کمتر باشد. 20. ظرفیت قابل تخصیص ظرفیتی که پس از اعمال قواعد و سیاست‌های تخصیص، برای تخصیص به متقاضیان در دسترس است. 21. ظرفیت تخصیص‌یافته مقدار ظرفیتی که واقعاً به متقاضیان اختصاص یافته است. 22. ظرفیت مصرف‌شده مقدار ظرفیتی که در عمل مورد استفاده قرار گرفته است. بخش چهارم ـ تقاضا و جریان 23. OD هر جفت مبدأ–مقصد یک OD محسوب می‌شود. برای مثال: مبدأ A → مقصد B یک OD مشخص ایجاد می‌کند. 24. تقاضای بار تقاضا بیانگر مقدار باری است که بازار برای یک OD و یک دوره زمانی مشخص درخواست می‌کند. تقاضا لزوماً به معنی حمل واقعی نیست. 25. جریان قطار جریان قطار تعداد حرکت‌های قطاری است که برای یک OD یا مسیر مشخص برنامه‌ریزی یا اجرا می‌شود. 26. جریان بار جریان بار مقدار باری است که توسط جریان قطار جابه‌جا می‌شود. رابطه این دو به ظرفیت بارگیری قطار وابسته است. بخش پنجم ـ زمان و عملیات 27. Headway Headway فاصله زمانی لازم میان حرکت قطارهای متوالی است. مقدار آن به عواملی مانند: سیستم علائم سرعت طول بلاک طول قطار زمان اشغال زمان پاک‌سازی بلاک وابسته است. 28. زمان اشغال بلاک زمان اشغال بلاک مدت زمانی است که استفاده از بلاک توسط یک حرکت قطاری باعث محدود شدن استفاده دیگران از آن می‌شود. 29. زمان حرکت زمان حرکت قطار بین دو نقطه باید بر اساس: سرعت‌های مجاز سرعت‌های مؤثر محدودیت‌ها شیب توقف وضعیت خط محاسبه شود. 30. توقف توقف می‌تواند ناشی از: عملیات مسافری عملیات باری تقاطع سبقت سوخت‌گیری تست ترمز تشکیل قطار نماز انتظار محدودیت شبکه باشد. 31. زمان نماز زمان نماز نباید به صورت یک مقدار ثابت از کل زمان سفر کسر شود. بلکه باید به‌عنوان یک پنجره زمانی عملیاتی مدل شود. سیستم باید بررسی کند که: قطار چه زمانی به ایستگاه می‌رسد؛ آیا امکان توقف وجود دارد؛ کدام ایستگاه برای توقف مناسب است؛ توقف چه اثری بر سایر قطارها دارد. 32. سوخت‌گیری سوخت‌گیری نیز یک عملیات زمانی است و باید در مدل زمان سفر و ظرفیت لحاظ شود. 33. تست ترمز زمان تست ترمز بسته به نوع عملیات ممکن است در: مبدأ ایستگاه محل تغییر ترکیب قطار اعمال شود. 34. قطار خالی قطار خالی نیز مصرف‌کننده ظرفیت شبکه است. بنابراین حذف آن از مدل می‌تواند باعث برآورد غیرواقعی ظرفیت شود. بخش ششم ـ منطق تولید ظرفیت 35. موتور تولید ظرفیت وظیفه موتور تولید ظرفیت آن است که بر اساس داده‌های زیرساخت و قواعد عملیاتی، ظرفیت قابل دستیابی را محاسبه کند. ورودی‌ها: شبکه Segment Block ایستگاه سرعت علائم قطار Headway زمان عملیات تعمیرات محدودیت‌ها خروجی‌ها: ظرفیت بلاک ظرفیت Segment ظرفیت مسیر ظرفیت اولیه شبکه 36. ظرفیت بلاک ظرفیت بلاک از تعامل موارد زیر حاصل می‌شود: زمان قابل استفاده Headway زمان اشغال نوع قطار جهت حرکت سیستم علائم محدودیت‌های زمانی 37. ظرفیت Segment ظرفیت Segment از تعامل بلاک‌های تشکیل‌دهنده و محدودیت‌های آن Segment حاصل می‌شود. در مدل ساده ممکن است محدودترین بلاک نقش تعیین‌کننده داشته باشد، اما در مدل کامل این موضوع باید با زمان‌بندی و عملیات شبکه بررسی شود. 38. ظرفیت Route ظرفیت Route حاصل تعامل تمام اجزای مسیر است. بنابراین ظرفیت Route الزاماً برابر حداقل ظرفیت Segmentهای آن نیست. عوامل مؤثر شامل: بلاک‌ها ایستگاه‌ها تقاطع سبقت زمان‌بندی نوع قطار ناوگان محدودیت‌های زمانی مسیرهای مشترک است. بخش هفتم ـ بهینه‌سازی شبکه 39. ضرورت بهینه‌سازی شبکه پس از محاسبه ظرفیت اجزای منفرد، باید بررسی شود که همه مسیرها به‌صورت همزمان چه میزان ظرفیت می‌توانند ایجاد کنند. زیرا ممکن است چند مسیر از منابع مشترک استفاده کنند. 40. منابع مشترک منابع مشترک می‌توانند شامل: بلاک Segment ایستگاه خط ورودی ایستگاه خط خروجی لکوموتیو واگن زمان پایانه باشند. 41. اصل رقابت مسیرها اگر چند مسیر از یک منبع محدود استفاده کنند، این مسیرها در آن منبع با یکدیگر رقابت می‌کنند. بنابراین موتور باید بتواند: مسیرهای دارای اشتراک را شناسایی کند؛ ظرفیت منبع مشترک را تعیین کند؛ جریان‌های رقیب را محاسبه کند؛ محدودیت‌ها را اعمال کند؛ بهترین ترکیب را پیدا کند. 42. انتقال ظرفیت آزاد اگر تقاضای یک مسیر کمتر از ظرفیت قابل تخصیص آن باشد، ظرفیت آزاد آن مسیر ممکن است برای مسیرهای رقیب استفاده شود. اما این کار فقط در صورت مجاز بودن سیاست شبکه انجام می‌شود. بنابراین انتقال ظرفیت باید یک Rule قابل تنظیم باشد. 43. سهمیه‌های شبکه ممکن است شبکه برای حفظ تعادل، سهمیه‌هایی تعریف کند. این سهمیه‌ها می‌توانند: سهم حداقل یک Route سهم یک گروه OD سهم یک بازار سهم منطقه سهم کالایی باشند. این سیاست‌ها نباید در هسته الگوریتم به صورت ثابت قرار گیرند. بخش هشتم ـ تحلیل سناریو و توسعه 44. سناریوی پایه هر تحلیل باید یک سناریوی پایه داشته باشد که بیانگر وضعیت فعلی شبکه است. 45. سناریوی توسعه سناریوهای توسعه می‌توانند شامل: دوخطه کردن افزایش سرعت اصلاح Headway توسعه ایستگاه تغییر برنامه حرکت افزایش ناوگان اصلاح عملیات باشند. 46. تحلیل حساسیت سیستم باید بتواند بررسی کند که تغییر هر پارامتر چه اثری بر ظرفیت دارد. مثلاً: اگر سرعت 10 درصد افزایش یابد چه می‌شود؟ اگر Headway کاهش یابد چه می‌شود؟ اگر یک Segment دوخطه شود چه می‌شود؟ اگر یک خط ایستگاه اضافه شود چه می‌شود؟ اگر تعداد لکوموتیو افزایش یابد چه می‌شود؟ 47. ظرفیت افزوده اثر هر مداخله باید به صورت ظرفیت افزوده نسبت به سناریوی پایه گزارش شود. همچنین باید مشخص شود این ظرفیت افزوده: ناشی از زیرساخت است؛ ناشی از بهره‌برداری است؛ ناشی از ناوگان است؛ ناشی از اصلاح برنامه‌ریزی است. 48. هزینه هر واحد ظرفیت افزوده برای هر پروژه توسعه‌ای باید بتوان هزینه سرمایه‌گذاری را با ظرفیت افزوده مقایسه کرد. این تحلیل بعداً برای اولویت‌بندی پروژه‌های توسعه ریلی استفاده خواهد شد. بخش نهم ـ قابلیت توضیح‌پذیری 49. Explainable Capacity یکی از الزامات کلیدی محصول: هر عدد ظرفیت باید قابل توضیح باشد. اگر سیستم مثلاً ظرفیت یک مسیر را اعلام کرد، کاربر باید بتواند بفهمد: محدودکننده اصلی چه بوده؛ کدام بلاک گلوگاه بوده؛ کدام ایستگاه محدودکننده بوده؛ Headway چه اثری داشته؛ چه مقدار زمان تعمیرات حذف شده؛ چه محدودیت ناوگانی اعمال شده؛ چه قید سیاستی فعال بوده است. 50. ظرفیت به‌عنوان «عدد سیاه» ممنوع است خروجی صرفاً یک عدد کافی نیست. هر Result باید همراه با: Scenario Data Version Model Version Algorithm Version Run ID Constraints Bottlenecks Explanation ذخیره شود. بخش دهم ـ ارتباط با بازارگاه و تخصیص 51. تفکیک سه موتور اصلی سه مفهوم باید کاملاً از هم جدا باشند: موتور تولید ظرفیت مشخص می‌کند شبکه چه ظرفیتی می‌تواند ایجاد کند. موتور بهینه‌سازی شبکه مشخص می‌کند این ظرفیت چگونه در سطح شبکه و با توجه به منابع مشترک قابل استفاده است. موتور تخصیص ظرفیت مشخص می‌کند ظرفیت به چه متقاضیانی تخصیص داده شود. 52. زنجیره کلی ساختار کلی سیستم: زیرساخت → تولید ظرفیت → بهینه‌سازی شبکه → ظرفیت قابل عرضه → تخصیص ظرفیت → بهره‌برداری واقعی → کالیبراسیون است. 53. ارتباط با بازارگاه ریلی بازارگاه باید ظرفیت قابل عرضه را از موتور ظرفیت دریافت کند. موتور بازارگاه نباید خودش ظرفیت شبکه را محاسبه کند. این تفکیک باعث می‌شود: الگوریتم ظرفیت مستقل بماند؛ سیاست بازار قابل تغییر باشد؛ Solver قابل تعویض باشد؛ سیستم قابلیت توسعه پیدا کند. بخش یازدهم ـ الزامات نرم‌افزاری 54. نسخه‌پذیری هر اجرای مدل باید دارای: شناسه اجرا نسخه داده نسخه مدل نسخه الگوریتم نسخه سناریو تاریخ اجرا باشد. 55. بازتولیدپذیری اگر داده، سناریو، مدل و الگوریتم یکسان باشند، سیستم باید تا حد امکان نتیجه یکسان تولید کند. 56. کالیبراسیون نتایج مدل باید با داده‌های واقعی بهره‌برداری مقایسه شوند. برای مثال: زمان واقعی حرکت زمان توقف تعداد قطار میزان تأخیر مصرف ظرفیت جریان بار با خروجی مدل مقایسه شوند. 57. حلقه یادگیری چرخه سیستم: داده زیرساخت → مدل → بهینه‌سازی → برنامه → بهره‌برداری واقعی → داده واقعی → کالیبراسیون → مدل اصلاح‌شده خواهد بود. بخش دوازدهم ـ معماری منطقی موتور 58. لایه داده داده‌های: زیرساخت ناوگان قطار تقاضا عملیات تعمیرات سیاست را دریافت می‌کند. 59. لایه محاسبات وظیفه آن محاسبه: سرعت زمان Headway زمان اشغال ظرفیت بلاک ظرفیت Segment ظرفیت Route است. 60. لایه بهینه‌سازی وظیفه حل تعارض‌ها و پیدا کردن ترکیب بهینه جریان‌ها را دارد. 61. لایه سیاست قوانین و سهمیه‌های سیاستی را اعمال می‌کند. 62. لایه خروجی خروجی را در اختیار: GIS داشبورد API گزارش بازارگاه سیستم تخصیص قرار می‌دهد. بخش سیزدهم ـ ماژول‌های اصلی M1 – Infrastructure Capacity Engine محاسبه ظرفیت زیرساخت. M2 – Operational Capacity Engine اعمال محدودیت‌های عملیاتی. M3 – Route Capacity Engine محاسبه ظرفیت مسیر. M4 – Network Optimization Engine بهینه‌سازی شبکه. M5 – Scenario & Sensitivity Engine تحلیل سناریو و حساسیت. M6 – Capacity Explanation Engine توضیح ظرفیت. M7 – Capacity Visualization Engine نمایش ظرفیت و گلوگاه‌ها. M8 – Calibration Engine مقایسه مدل و واقعیت. بخش چهاردهم ـ ترتیب اجرای موتور فرآیند کلی اجرا: مرحله 1 دریافت شبکه. مرحله 2 تعریف Segmentها و Blockها. مرحله 3 دریافت اطلاعات ایستگاه‌ها. مرحله 4 دریافت مشخصات قطار. مرحله 5 محاسبه سرعت و زمان. مرحله 6 محاسبه Headway. مرحله 7 محاسبه ظرفیت بلاک. مرحله 8 محاسبه ظرفیت Segment. مرحله 9 تعریف Routeها. مرحله 10 تعریف ODها و تقاضا. مرحله 11 شناسایی منابع مشترک. مرحله 12 تشخیص تعارض‌ها. مرحله 13 تشکیل مدل بهینه‌سازی. مرحله 14 حل مدل. مرحله 15 محاسبه ظرفیت شبکه. مرحله 16 اجرای سناریوها. مرحله 17 تولید گزارش توضیح‌پذیر. بخش پانزدهم ـ خروجی‌های اصلی هر اجرای موتور باید حداقل این خروجی‌ها را تولید کند: ظرفیت بلاک‌ها؛ ظرفیت Segmentها؛ ظرفیت Routeها؛ ظرفیت شبکه؛ جریان قطار؛ جریان بار؛ گلوگاه‌ها؛ ظرفیت آزاد؛ ظرفیت از دست‌رفته؛ تقاضای برآورده‌نشده؛ میزان استفاده؛ علت محدودکنندگی؛ سناریو؛ نسخه داده؛ نسخه الگوریتم؛ شناسه اجرای مدل. بخش شانزدهم ـ قراردادهای قطعی پروژه از این مرحله به بعد، موارد زیر قرارداد رسمی طراحی محسوب می‌شوند: قرارداد 1 Capacity فقط «ظرفیت» است. قرارداد 2 ظرفیت بلاک، Segment، Route و Network چهار مفهوم متفاوت‌اند. قرارداد 3 جریان قطار با جریان بار متفاوت است. قرارداد 4 تقاضا با جریان واقعی متفاوت است. قرارداد 5 ظرفیت بارگیری قطار با ظرفیت شبکه متفاوت است. قرارداد 6 توان کشش با ظرفیت شبکه متفاوت است. قرارداد 7 دوخطه شدن یک Segment، Route جدید ایجاد نمی‌کند. قرارداد 8 ظرفیت شبکه حاصل جمع ساده ظرفیت Routeها نیست. قرارداد 9 هیچ ظرفیت عددی بدون واحد و دوره زمانی کامل نیست. قرارداد 10 سیاست‌های تخصیص نباید در هسته محاسباتی Capacity به صورت ثابت کدنویسی شوند. قرارداد 11 تمام خروجی‌های مهم باید قابل توضیح باشند. قرارداد 12 تمام اجرای مدل باید نسخه و Scenario داشته باشد. بخش هفدهم ـ دیباچه ریاضی و الگوریتمی پروژه این بخش مرجع رسمی نمادها و روابط ریاضی پروژه است. به‌منظور حفظ خوانایی متن اصلی، نمادهای ریاضی تا حد ممکن در این بخش متمرکز شده‌اند. 17-1. مجموعه‌های اصلی نماد تعریف (G) شبکه ریلی (V) مجموعه گره‌ها (E) مجموعه یال‌ها (R) مجموعه مسیرها (r) یک مسیر (S) مجموعه Segmentها (s) یک Segment (S_r) مجموعه Segmentهای مسیر (r) (B) مجموعه Blockها (b) یک Block (B_r) مجموعه Blockهای مسیر (r) (OD) مجموعه جفت‌های مبدأ–مقصد (od) یک جفت مبدأ–مقصد (T) مجموعه بازه‌های زمانی (t) یک بازه زمانی (K) مجموعه انواع قطار (F) مجموعه ناوگان 17-2. پارامترهای ظرفیت نماد تعریف (C_b) ظرفیت بلاک (C_s) ظرفیت Segment (C_r) ظرفیت Route (C_n) ظرفیت Network (C^{theoretical}) ظرفیت نظری (C^{technical}) ظرفیت فنی (C^{operational}) ظرفیت عملیاتی (C^{reliable}) ظرفیت قابل اتکا (C^{marketable}) ظرفیت قابل عرضه (C^{alloc}) ظرفیت قابل تخصیص (C^{allocated}) ظرفیت تخصیص‌یافته (C^{used}) ظرفیت مصرف‌شده (C^{lost}) ظرفیت از دست‌رفته (C^{hidden}) ظرفیت پنهان 17-3. پارامترهای تقاضا و جریان نماد تعریف (D_{od,t}) تقاضای بار OD در زمان (t) (D_{od}) تقاضای کل OD (F_{od,r,t}) جریان قطار OD روی Route در زمان (t) (F_{r,t}) جریان قطار Route (Q_{od,r,t}) جریان بار OD روی Route در زمان (t) (P_{r,t}) ظرفیت بارگیری قطار قاعده مهم [ F = Train\ Flow ] و: [ Q = Cargo\ Flow ] بنابراین این دو نماد هرگز نباید جای یکدیگر استفاده شوند. 17-4. پارامترهای زمانی نماد تعریف (H) Headway (H_{b,r,t}) Headway مرتبط با Block، Route و زمان (T_b) زمان اشغال Block (T_{b,r,t}) زمان اشغال Block توسط حرکت مشخص (T_r) زمان سفر Route (A_t) دسترس‌پذیری بازه زمانی (T^{running}) زمان حرکت (T^{dwell}) زمان توقف (T^{fuel}) زمان سوخت‌گیری (T^{brake}) زمان تست ترمز (T^{formation}) زمان تشکیل قطار 17-5. متغیرهای تصمیم نماد تعریف (x_{r,t}) تعداد یا انتخاب حرکت در Route و زمان (x_{od,r,t}) تخصیص حرکت OD به Route و زمان (y_{r,t}) متغیر دودویی انتخاب Route در زمان (Q_{od,r,t}) مقدار بار تخصیص‌یافته 17-6. متغیرهای عملکردی نماد تعریف (U_b) میزان استفاده از Block (Slack_b) ظرفیت آزاد Block (UnservedDemand) تقاضای برآورده‌نشده (LostCapacity) ظرفیت از دست‌رفته (\Delta C) ظرفیت افزوده (CM) حاشیه ظرفیت 17-7. روابط پایه رابطه جریان بار و قطار [ Q_{od,r,t} \leq P_{r,t}\times F_{od,r,t} ] قید تقاضا [ \sum_{r,t}Q_{od,r,t} \leq D_{od} ] قید ظرفیت Block [ \sum_{r\in R_b} F_{r,b,t} \leq C_{b,t} ] قید ظرفیت Route [ F_{r,t} \leq C_{r,t} ] ظرفیت آزاد [ Slack_b=C_b-F_b ] میزان استفاده [ U_b=\frac{F_b}{C_b} ] ظرفیت افزوده C^{scenario} C^{base} ] تقاضای برآورده‌نشده D_{od} \sum_{r,t}Q_{od,r,t} ] 17-8. قیود اصلی مدل مدل باید حداقل قیود زیر را پشتیبانی کند: قید ظرفیت [ Flow\leq Capacity ] قید تقاضا [ CargoFlow\leq Demand ] قید ناوگان [ FleetUse\leq FleetAvailable ] قید زمانی [ MovementTime\leq AvailableTime ] قید ایستگاه [ StationUse\leq StationCapacity ] قید ایمنی محدودیت‌های ناشی از مقررات و ایمنی. قید سیاستی محدودیت‌هایی که توسط سیاست بهره‌بردار تعیین می‌شوند. 17-9. تابع هدف تابع هدف عمومی: [ \max Z ] است. می‌تواند برای مثال به شکل زیر تعریف شود: \alpha_4\sum Delay ] که ضرایب آن بر اساس سناریو و سیاست تعیین می‌شوند. 17-10. مدل شبکه مدل فضایی پایه: [ G=(V,E) ] است. در مدل زمانی می‌توان شبکه را به یک: [ G_T=(V_T,E_T) ] تبدیل کرد. این مدل برای مسائل دقیق زمان‌بندی، تقاطع، سبقت و تعارض‌های زمانی قابل استفاده خواهد بود. 17-11. تشخیص تعارض دو حرکت زمانی متعارض‌اند اگر: یک منبع مشترک داشته باشند؛ و در زمان‌های متداخل از آن استفاده کنند. به‌صورت مفهومی: [ Resource_i\cap Resource_j\neq\emptyset ] و: [ Time_i\cap Time_j\neq\emptyset ] 17-12. ظرفیت شبکه ظرفیت شبکه از حل همزمان جریان‌های مختلف حاصل می‌شود: [ C_n= Optimization ( G,R,B,OD,Demand,Fleet,Constraints,Objective ) ] بنابراین: [ C_n\neq\sum_r C_r ] 17-13. ظرفیت پنهان برای تحلیل بهره‌وری عملیاتی: C^{optimized\ operational} C^{current\ operational} ] مشروط بر اینکه تغییر زیرساختی جدیدی در سناریو وجود نداشته باشد. 17-14. ظرفیت افزوده سرمایه‌گذاری C^{development} C^{base} ] 17-15. حساسیت برای یک پارامتر (p): \frac{\Delta C}{\Delta p} ] این رابطه برای تحلیل اولیه حساسیت استفاده می‌شود و در نسخه الگوریتمی نهایی ممکن است روش‌های دقیق‌تر مشتقی، عددی یا سناریومحور به کار گرفته شود. 17-16. رابطه سلسله‌مراتب ظرفیت رابطه مفهومی: [ C_b \rightarrow C_s \rightarrow C_r \rightarrow C_n ] است. اما این رابطه یک زنجیره ساده محاسباتی نیست؛ بلکه هر سطح حاصل تعامل محدودیت‌های سطح پایین‌تر و سایر منابع شبکه است. 17-17. زنجیره جریان [ Demand \rightarrow TrainFlow \rightarrow CargoFlow ] به این معنا که: تقاضا، تعداد حرکت موردنیاز را شکل می‌دهد و تعداد حرکت، با توجه به ظرفیت بارگیری قطار، جریان بار را ایجاد می‌کند. 17-18. زنجیره نهایی سیستم [ Infrastructure \rightarrow Capacity \rightarrow Optimization \rightarrow Allocation \rightarrow Utilization \rightarrow Calibration ] این زنجیره، منطق کلان موتور را تشکیل می‌دهد. بخش هجدهم ـ مبنای ورود به معماری داده پس از این نسخه، معماری داده باید مستقیماً از مفاهیم تثبیت‌شده در این سند استخراج شود. موجودیت‌های اصلی پیشنهادی عبارت‌اند از: Network Node Station Segment Block Route OD Pair Demand Train Type Wagon Type Locomotive Type Fleet Operational Constraint Time Window Scenario Scenario Parameter Optimization Run Capacity Result Bottleneck Capacity Explanation Actual Operation Calibration Result بخش نوزدهم ـ اصل طراحی مرحله بعد در مرحله بعد، برای هر موجودیت باید چهار پرسش پاسخ داده شود: 1. این موجودیت چیست؟ 2. چه داده‌هایی درباره آن نگهداری می‌شود؟ 3. با چه موجودیت‌هایی رابطه دارد؟ 4. در کدام محاسبات یا الگوریتم‌ها استفاده می‌شود؟ سپس بر اساس پاسخ این چهار پرسش: Domain Model → ERD → Data Dictionary → API Contract طراحی خواهد شد. جمع‌بندی در این نسخه، متن اصلی عمداً با حداقل نمادهای ریاضی تنظیم شده است تا برای مطالعه مدیریتی، مهندسی و نرم‌افزاری خواناتر باشد. در مقابل، تمام نمادهای اصلی و روابط ریاضی در انتهای سند و در قالب: «دیباچه ریاضی و الگوریتمی پروژه» متمرکز شده‌اند. این دیباچه از این پس مرجع رسمی نمادگذاری پروژه است و هر نماد جدیدی که در طراحی الگوریتم، ERD، Database یا API ایجاد شود، باید به همین بخش افزوده و قبل از استفاده تثبیت شود. این ساختار به نظرم برای سند نهایی بسیار بهتر است: متن اصلی برای خواندن و فهمیدن است؛ دیباچه انتهایی برای ارجاع فنی تیم الگوریتم و نرم‌افزار. در مرحله بعد هم می‌توانیم دقیقاً با همین تفکیک وارد D1 ـ معماری داده شویم و ابتدا «مدل موجودیت‌های کسب‌وکار و روابط آن‌ها» را طراحی کنیم، بدون اینکه هنوز وارد جزئیات سنگین جدول‌ها شویم. --- ## Prompt 9 — پرسش کاربر (`conversation-turn-17`) لطفا یک فایل ورود که کاملترین نسخه رو تا الان شامل همه نکاتی که گفتی باشه بده ## Prompt 9 — پاسخ دستیار (`conversation-turn-18`) حتماً. نسخه Word کامل و یکپارچه آماده شد و ساختار آن را طوری تنظیم کردم که: متن اصلی تا حد ممکن روان و بدون شلوغی نمادهای ریاضی باشد. همه نمادها، متغیرها، پارامترها و روابط ریاضی در انتهای سند در قالب «دیباچه ریاضی و الگوریتمی» متمرکز باشند. قواعد واژگانی، به‌خصوص Capacity = ظرفیت، تثبیت شده باشند. تفکیک ظرفیت / ظرفیت بارگیری قطار / توان کشش / جریان قطار / جریان بار / تقاضا در سند آمده باشد. ساختار Block → Segment → Route → Network، مسیرهای مشترک، تک‌خطه/دوخطه، گلوگاه، سناریو، تحلیل حساسیت، ظرفیت پنهان و ظرفیت از دست‌رفته پوشش داده شود. ارتباط موتور ظرفیت با بهینه‌سازی، تخصیص ظرفیت و بازارگاه ریلی مشخص باشد. سند مستقیماً مبنای مرحله بعد یعنی معماری داده، ERD، Data Dictionary و API Contract باشد. دانلود فایل Word: دانلود نسخه کامل سند مشخصات فنی و ریاضی موتور ظرفیت ریلی به نظرم این فایل را فعلاً به‌عنوان نسخه مرجع M0 نگه داریم؛ در گام بعدی می‌توانیم بدون دست‌زدن به منطق تثبیت‌شده آن، وارد D1 ـ معماری داده شویم و ابتدا مدل موجودیت‌ها و روابط را طراحی کنیم. --- ## Prompt 10 — پرسش کاربر (`conversation-turn-19`) فقط قبلش یه سوال بکنم و ببینم که در طرحی که آماده کردی این رو چطور حل می کنی. مسیر سنگان تا بافق 1 خطه است. از بافق تا فولاد دو خطه. ایده من اینه که در مسیر رفت، قطارهای باردار از سنگان به فولا به صورت پی در پی به مدت 18 ساعت راه بیفتند و حرکت کنند. در مسیر برگشت هم قطار واگنهای خالی با سرعت کمتر از متوسط و طولهای بیشتر از متوسط از فولاد تا بافق بیاییند و در آنجا دپو شوند. پس از عبور آخرین قطار باردار از بافق به سمت فولاد، واگنهای خالی در مسیر بافق به سنگان به صورت پی در پی بروند تا آخرین قطار واگن های خالی و این سیکل ادامه پیدا کند. به عبارت دیگر با مسیر تک خطه به صورت ازاد و بدون نگرانی از تردد قطار از روبرو مواجهه کردیم و در برنامه ریزی لحاظ کردیم. این رو در مدلت چطور لحاظ کردی. به طور خاص همین مثال رو در طرح با جزئیات توضیح بده Show more ## Prompt 10 — پاسخ دستیار (`conversation-turn-20`) بله؛ و اتفاقاً نکته‌ای که مطرح کردید یکی از مهم‌ترین قابلیت‌هایی است که باید در مدل نهایی موتور ظرفیت صریحاً اضافه و پررنگ شود. در مدلی که تا الان طراحی کردیم، «خط یک‌خطه» به‌صورت عمومی با محدودیت عبور قطارهای روبه‌رو، فاصله زمانی، بلاک، ایستگاه، تقاطع و… مدل شده بود. اما ایده شما یک گام مهم‌تر است: در یک مسیر یک‌خطه، به‌جای اینکه الزاماً ظرفیت را بر مبنای رفت‌وبرگشت همزمان و تقابل قطارها محاسبه کنیم، می‌توانیم یک «پنجره بهره‌برداری جهت‌دار» ایجاد کنیم که در آن خط برای مدتی فقط در یک جهت مورد استفاده قرار گیرد. این دقیقاً باید در موتور ما مدل شود. ۱. مثال سنگان–بافق–فولاد بیایید مثال شما را دقیقاً وارد مدل کنیم. شبکه را به سه بخش مفهومی تقسیم می‌کنیم: سنگان │ │ مسیر یک‌خطه │ ▼ بافق │ │ مسیر دوخطه │ ▼ فولاد اما از نظر مدل ظرفیت، این فقط سه نقطه نیست؛ بلکه داریم: Route = سنگان → فولاد Segment A = سنگان → بافق Track = Single Track Segment B = بافق → فولاد Track = Double Track نکته بسیار مهم: دوخطه شدن بافق–فولاد یک Route جدید ایجاد نمی‌کند. همان Route سنگان–فولاد است، ولی وضعیت زیرساختی Segmentها متفاوت است. ۲. ایده شما در واقع چیست؟ ایده شما را می‌توان این‌طور تعریف کرد: «Directional Batch Operation on Single Track» یا در فارسی: «بهره‌برداری دسته‌ای و جهت‌دار از خط یک‌خطه» یعنی به جای اینکه بگوییم: در هر لحظه باید امکان عبور قطار از هر دو جهت را حفظ کنیم، می‌گوییم: در یک پنجره زمانی مشخص، خط یک‌خطه را کاملاً به یک جهت اختصاص می‌دهیم. مثلاً: پنجره اول سنگان ───────────────► بافق قطارهای باردار در این پنجره هیچ قطار خالی از بافق به سنگان وارد خط یک‌خطه نمی‌شود. بنابراین مشکل تقابل رفت و برگشت عملاً حذف می‌شود. ۳. نکته بسیار مهم: این به معنی «ظرفیت نامحدود» نیست این تفاوت را در مدل باید خیلی دقیق نگه داریم. شما تقابل قطارهای روبه‌رو را حذف کرده‌اید، اما هنوز محدودیت‌های زیر وجود دارند: فاصله زمانی ایمن قطارها طول بلاک‌ها سرعت قطار زمان اشغال بلاک طول قطار ترمز و تست ترمز زمان توقف احتمالی ظرفیت ایستگاه‌ها ظرفیت خطوط ایستگاهی محدودیت سرعت زمان تخلیه/بارگیری در مبدأ توان کشش لکوموتیو طول قطار محدودیت‌های بهره‌برداری و مهم‌تر از همه، زمانی که آخرین قطار یک جهت خط را تخلیه می‌کند. پس شما یک محدودیت بزرگ را حذف می‌کنید: Conflict between Opposite-Direction Trains ولی سایر محدودیت‌ها باقی می‌مانند. ۴. مدل شما برای پنجره اول فرض کنیم برنامه به این صورت باشد: Direction 1 سنگان → فولاد و قطارها در سنگان به‌صورت متوالی اعزام شوند. مثلاً: 08:00 قطار 1 10:00 قطار 2 12:00 قطار 3 14:00 قطار 4 16:00 قطار 5 18:00 قطار 6 20:00 قطار 7 22:00 قطار 8 00:00 قطار 9 ... البته در سیستم واقعی ۲ ساعت یک مقدار فرضی است و موتور خودش باید Headway واقعی را از شرایط مسیر محاسبه کند. یعنی ممکن است نتیجه موتور بگوید: Minimum Safe Headway = 93 min در این صورت فاصله دو ساعت فقط یک سیاست عملیاتی است، نه الزام فنی. ۵. نکته کلیدی: قطار اول لازم نیست صبر کند تا قطار قبلی به فولاد برسد این دقیقاً جایی است که مدل شما از مدل ساده «رفت و برگشت» متفاوت می‌شود. قطار ۱: سنگان ───────────────► بافق ───────────────► فولاد قطار ۲ می‌تواند زمانی که قطار ۱ هنوز در مسیر است، از سنگان حرکت کند: قطار 1 ───────────────────────────────► قطار 2 ──────────────────────► قطار 3 ───────────────► به شرط آنکه: Headway(1,2) ≥ H_safe Headway(2,3) ≥ H_safe و بلاک‌های مربوطه نیز اجازه دهند. پس در پنجره جهت‌دار: خط یک‌خطه مانند یک «خط انتقال یک‌طرفه» عمل می‌کند. این نکته باید مستقیماً در الگوریتم M2/M3 ما وارد شود. ۶. اما اتفاق بسیار جالب‌تر در بافق رخ می‌دهد حالا فرض کنیم قطارها به بافق می‌رسند. از بافق تا فولاد دوخطه است: ┌──────────────► فولاد سنگان ─────► بافق ──┤ └──────────────► فولاد در نتیجه محدودیت اصلی Route در این بخش دیگر همان محدودیت یک‌خطه سنگان–بافق نیست. قطارهای باردار می‌توانند در مسیر دوخطه ادامه حرکت دهند. پس بافق تبدیل می‌شود به یک مرز عملیاتی بسیار مهم. در مدل ما بافق فقط Station نیست؛ بلکه می‌تواند یک: Directional Control Point و Buffer / Staging Node باشد. ۷. سپس پنجره دوم شروع می‌شود حالا طبق ایده شما: وقتی آخرین قطار باردار از بافق به سمت فولاد عبور کرد، مسیر یک‌خطه بافق–سنگان برای قطارهای خالی باز می‌شود. پس: پنجره 1 Sangan → Bafq ████████████████████████ قطارهای باردار ████████████████████████ و سپس: پنجره 2 Bafq → Sangan ████████████████████████ قطارهای خالی ████████████████████████ بنابراین: DIRECTIONAL WINDOW │ ┌────────────┴────────────┐ │ │ ▼ ▼ Loaded Window Empty Window سنگان → بافق بافق → سنگان │ │ └──────────┬──────────────┘ │ Repeat این همان چیزی است که من در نسخه نهایی پیشنهاد می‌کنم به‌عنوان یک مفهوم رسمی وارد کنیم: «چرخه بهره‌برداری جهت‌دار مسیر یک‌خطه» ۸. حالا نکته بسیار مهمی که شما گفتید: واگن‌های خالی شما فقط نگفتید قطار خالی برگردد. گفتید: قطارهای واگن خالی با سرعت کمتر از متوسط و طول‌های بیشتر از متوسط از فولاد تا بافق بیایند و در آنجا دپو شوند. این فوق‌العاده مهم است؛ چون در مدل ظرفیت نباید «قطار خالی» را صرفاً یک قطار با بار صفر فرض کنیم. بلکه باید مشخصات عملیاتی آن را وارد کنیم: Train Type = Empty Wagon Recovery Train Payload = 0 Train Length = L_empty Speed Profile = V_empty Gross Weight = W_empty Running Time = T_empty Block Occupancy = T_block_empty و چون شما می‌گویید: سرعت کمتر از متوسط داریم: T_empty > T_loaded و چون می‌گویید: طول بیشتر از متوسط ممکن است: L_empty > L_average بنابراین زمان اشغال بلاک و زمان تخلیه مسیر توسط قطار خالی می‌تواند قابل توجه باشد. ۹. این موضوع در مدل ما چه اثری دارد؟ اینجا مدل باید از یک اشتباه بسیار مهم جلوگیری کند. نباید بگوید: «قطار خالی است، پس ظرفیت کمی مصرف می‌کند.» بلکه باید بگوید: مصرف ظرفیت یک قطار تابعی از زمان و منابعی است که اشغال می‌کند، نه فقط مقدار بار آن. مثلاً: Loaded Train: Length = 750 m Speed = 60 km/h Occupancy = X Empty Train: Length = 900 m Speed = 45 km/h Occupancy = Y ممکن است قطار خالی با اینکه: Payload = 0 است، از نظر ظرفیت زیرساختی مصرف قابل توجهی داشته باشد. این دقیقاً یکی از مواردی است که موتور ما باید محاسبه کند. ۱۰. حالا «دپو در بافق» وارد مدل می‌شود ایده شما حتی یک مرحله دیگر هم دارد. قطارهای خالی الزاماً بلافاصله وارد خط یک‌خطه نمی‌شوند. آنها می‌توانند در بافق جمع شوند. یعنی: فولاد │ │ ▼ بافق ┌─────────────────────┐ │ Empty Wagon Buffer │ │ │ │ Train 1 │ │ Train 2 │ │ Train 3 │ │ Train 4 │ └─────────────────────┘ │ ▼ سنگان بنابراین باید در مدل یک مفهوم جدید داشته باشیم: Empty Wagon Buffer / Staging Capacity یعنی: ظرفیت دپو و آماده‌سازی واگن/قطار خالی در یک گره عملیاتی. و این خودش یک محدودیت ظرفیت است. مثلاً اگر بافق فقط بتواند ۱۰ قطار خالی را در وضعیت مناسب نگهداری/تشکیل دهد، موتور نباید ۲۰ قطار را برای دپو برنامه‌ریزی کند. ۱۱. حالا کل سیکل را ببینیم مدل شما تقریباً این‌گونه می‌شود: فولاد ▲ │ مسیر دوخطه │ │ بافق ▲ │ مسیر یک‌خطه │ │ سنگان مرحله A ـ حرکت قطارهای باردار سنگان │ ├── Loaded Train 1 ───────────► ├──── Loaded Train 2 ─────────► ├────── Loaded Train 3 ───────► ├──────── Loaded Train 4 ─────► └────────── Loaded Train N ───► بافق │ ▼ فولاد در این مرحله: Single Track Direction = Sangan → Bafq و: Empty Train Entry = PROHIBITED ۱۲. مرحله B ـ آزاد شدن مسیر وقتی آخرین قطار باردار از بافق عبور کرد، فقط ورود آن قطار به بافق کافی نیست. موتور باید بررسی کند: آیا بخش یک‌خطه کاملاً برای تغییر جهت آزاد شده است؟ یعنی: Last Loaded Train │ ▼ passes Bafq │ ▼ Single-track section cleared │ ▼ Direction Change Allowed این تفاوت خیلی مهم است. ما نباید صرفاً بر اساس: Arrival at Bafq تصمیم بگیریم. بلکه بر اساس: Clearance of Controlled Single-Track Section تصمیم می‌گیریم. ۱۳. مرحله C ـ بازگشت قطارهای خالی اکنون: Bafq ─────────────────────────► Sangan Empty Train 1 Bafq ─────────────────────────► Sangan Empty Train 2 Bafq ─────────────────────────► Sangan Empty Train 3 و دوباره: Empty Train Entry ↓ Headway Check ↓ Block Occupancy ↓ Station/Block Clearance ↓ Next Empty Train ۱۴. و سپس دوباره سیکل از اول وقتی آخرین قطار خالی عبور کرد: Last Empty Train │ ▼ Sangan │ ▼ Single Track Cleared │ ▼ Direction Change │ ▼ Sangan → Bafq Loaded Trains و چرخه تکرار می‌شود. ۱۵. این یعنی در مدل ریاضی ما چه اتفاقی افتاده؟ اینجا یک تغییر بسیار مهم ایجاد می‌شود. در مدل ساده یک خطه، ممکن بود قید را چیزی شبیه این ببینیم: F S→B ​ (t)+F B→S ​ (t)≤C SB ​ اما در مدل شما، بهتر است حالت عملیاتی مسیر را نیز وارد کنیم. مثلاً: z SB ​ (t)∈{0,+1,−1} که: z=+1: مسیر در اختیار سنگان → بافق z=−1: مسیر در اختیار بافق → سنگان z=0: مسیر آزاد/بدون بهره‌برداری حالا قید بسیار مهم می‌شود: اگر: z SB ​ (t)=+1 آنگاه: F B→S ​ (t)=0 و اگر: z SB ​ (t)=−1 آنگاه: F S→B ​ (t)=0 این دقیقاً همان ایده‌ای است که شما مطرح کردید. ۱۶. ولی حتی بهتر از این: «پنجره جهت‌دار» به‌جای اینکه برای تک‌تک قطارها تصمیم بگیریم، موتور می‌تواند یک متغیر مهم‌تر داشته باشد: W k ​ یعنی: Directional Operating Window مثلاً: W1 = 08:00–02:00 Direction = Sangan → Bafq و: W2 = 03:00–15:00 Direction = Bafq → Sangan و بعد: W3 = 16:00–... Direction = Sangan → Bafq البته این ساعات مثال الگوریتمی هستند و موتور باید آنها را از قیود واقعی بهینه کند. ۱۷. نکته‌ای که باعث می‌شود ایده شما واقعاً قدرتمند شود در اینجا موتور ظرفیت دیگر صرفاً نمی‌پرسد: «یک خطه است یا دو خطه؟» بلکه می‌پرسد: «این خط یک‌خطه تحت چه رژیم بهره‌برداری‌ای استفاده می‌شود؟» مثلاً: حالت ۱ Two-way mixed operation → ← → ← حالت ۲ Directional batch operation → → → → → → سپس: ← ← ← ← ← حالت ۳ Scheduled directional windows → → → | ← ← | → → → | ← ← حالت ۴ Priority directional operation مثلاً در ساعات خاص: → → → → → و ظرفیت جهت مخالف به حداقل سهم مشخص محدود شود. این‌ها باید پارامترهای مدل باشند، نه اینکه الگوریتم فقط یک نوع بهره‌برداری را فرض کند. ۱۸. یک نکته بسیار مهم دیگر: ظرفیت Route دیگر فقط تابع خط نیست در این مثال، ظرفیت واقعی سنگان–فولاد ممکن است توسط یک بخش کوتاه‌تر تعیین شود. مثلاً فرض کنیم: سنگان ───────── بافق Single بافق ─────────────── فولاد Double اگر بخش یک‌خطه بتواند در هر پنجره: 10 قطار باردار عبور دهد و بخش دوخطه بتواند: 20 قطار را پشتیبانی کند، ظرفیت کل Route الزاماً ۱۰ نیست؛ چون باید زمان‌بندی کل شبکه و پنجره‌های جهت‌دار را حل کنیم. مثلاً: C r ​ =f(C single ​ ,C double ​ ,H,T loaded ​ ,T empty ​ ,W,BafqBuffer,StationCapacity,Fleet,Demand,Policy) پس: Cᵣ را نمی‌توان در حالت عمومی صرفاً برابر حداقل ظرفیت یک Segment گرفت. این دقیقاً یکی از دلایلی است که قبلاً روی تفاوت C b ​ ، C s ​ ، C r ​ و C n ​ تأکید کردیم. ۱۹. یک نتیجه بسیار جالب درباره «قطار خالی» ایده شما یک مزیت دیگر هم ایجاد می‌کند. اگر واگن‌های خالی بتوانند در بافق تجمیع شوند، لازم نیست الزاماً هر قطار باردار که به فولاد می‌رود، بلافاصله یک قطار خالی را به سمت سنگان برگرداند. یعنی سیستم می‌تواند: Loaded flow Sangan → Foolad ↓ continuous Empty flow Foolad → Bafq ↓ buffering ↓ Bafq → Sangan ↓ batch flow این باعث می‌شود: «عدم تقارن زمانی جریان بار و جریان واگن خالی» به یک مزیت برنامه‌ریزی تبدیل شود. و این بسیار مهم است. ۲۰. این مفهوم باید وارد نسخه نهایی سند شود من پیشنهاد می‌کنم یک ماژول جدید به سند اضافه کنیم: M9 — موتور برنامه‌ریزی بهره‌برداری جهت‌دار مسیرهای یک‌خطه Directional Single-Track Operation Engine وظیفه M9: شناسایی مسیرهای یک‌خطه مستعد بهره‌برداری جهت‌دار تعریف Directional Window تعیین زمان شروع و پایان هر Window تعیین جهت غالب هر Window جلوگیری از ورود جریان مخالف محاسبه تعداد قطار قابل عبور در هر Window لحاظ کردن سرعت و طول متفاوت قطارها لحاظ کردن زمان اشغال بلاک لحاظ کردن زمان آزادسازی کامل مسیر تعیین زمان تغییر جهت لحاظ کردن ظرفیت دپو/Buffer هماهنگی با بخش‌های دوخطه Route اتصال جریان Loaded و Empty محاسبه ظرفیت کل سیکل مقایسه با حالت بهره‌برداری عادی محاسبه Capacity Gain ناشی از تغییر رژیم بهره‌برداری ۲۱. حتی یک KPI جدید می‌توانیم تعریف کنیم مثلاً: Directional Utilization Efficiency یا: بهره‌وری بهره‌برداری جهت‌دار که بررسی کند: چه مقدار از ظرفیت زمانی خط یک‌خطه واقعاً به قطارهای مفید اختصاص یافته است؟ مثلاً: DUE= Available Directional Window Useful Occupancy Time ​ و یک شاخص دیگر: Direction Switch Loss یعنی: چه مقدار زمان در تغییر جهت از دست می‌رود؟ T loss ​ =T switch ​ +T clearance ​ +T buffer ​ این برای مثال سنگان–بافق بسیار مهم است. ۲۲. و یک شاخص اقتصادی حتی مهم‌تر موتور می‌تواند دو حالت را مقایسه کند: سناریو A بهره‌برداری عادی خط یک‌خطه → ← → ← → ← در مقابل: سناریو B بهره‌برداری دسته‌ای جهت‌دار → → → → → → ← ← ← ← ← → → → → → → سپس بگوید: Capacity – Scenario A = X trains/day Capacity – Scenario B = Y trains/day Capacity Gain = Y - X و مهم‌تر: Additional Tons Additional Ton-km Additional Revenue Potential Infrastructure Cost Avoided این دقیقاً با فلسفه‌ای که برای موتور ظرفیت تعریف کرده‌ایم سازگار است: قبل از اینکه بگوییم باید خط را دوخطه کنیم، بررسی کنیم آیا با تغییر رژیم بهره‌برداری می‌توان بخشی از ظرفیت پنهان خط موجود را آزاد کرد یا نه. ۲۳. اما یک اصلاح مهم در عبارت «بدون نگرانی از تردد قطار از روبرو» از نظر مفهومی حرف شما درست است، اما در سند فنی بهتر است این عبارت را کمی دقیق‌تر کنیم. نگوییم: «بدون محدودیت تردد قطار روبه‌رو» بلکه بگوییم: «با حذف تقابل همزمان جریان‌های جهت مخالف در پنجره بهره‌برداری جهت‌دار» چون هنوز مسئله ایمنی، بلاک، فاصله قطارها، آزادسازی مسیر، ایستگاه‌ها و تغییر جهت وجود دارد. یعنی: ما Conflict را حذف نکرده‌ایم؛ بلکه: نوع Conflict را از «تقابل قطارهای روبه‌رو» به «زمان‌بندی پنجره جهت‌دار» تبدیل کرده‌ایم. این از نظر طراحی الگوریتمی تفاوت بسیار بزرگی است. ۲۴. جمع‌بندی دقیق ایده شما در مدل نهایی در مثال سنگان–بافق–فولاد، موتور باید بتواند چنین چیزی تولید کند: ROUTE SANGAN ───────── FOOLAD │ │ ┌─────┴──────┐ │ │ SINGLE TRACK DOUBLE TRACK Sangan-Bafq Bafq-Foolad │ ▼ Directional Operation │ ├── Window 1 │ Loaded →→→→→ │ ├── Window 2 │ Empty ←←←←← │ ├── Window 3 │ Loaded →→→→→ │ └── ... و در هر Window موتور بداند: Direction StartTime EndTime Headway TrainCount TrainLength TrainSpeedProfile BlockOccupancy ClearanceTime SwitchTime BufferCapacity و در نهایت: C r ​ =Maximum feasible loaded flow over the complete cycle و به نظرم این نکته حتی باید یک اصل بنیادین در سند ما شود: ظرفیت مسیر یک‌خطه صرفاً تابع تعداد قطارهای قابل عبور در حالت رفت‌وبرگشت نیست؛ بلکه تابع رژیم بهره‌برداری، جهت جریان، پنجره‌های زمانی، مشخصات قطارها، زمان اشغال و آزادسازی بلاک‌ها، نقاط تغییر جهت، ظرفیت دپو و تعامل آن با بخش‌های یک‌خطه و دوخطه Route است. این جمله، ایده‌ای که الان مطرح کردید را از یک «ترفند برنامه‌ریزی» به یک قابلیت رسمی موتور تولید و بهینه‌سازی ظرفیت تبدیل می‌کند. و بله، با این نگاه، مدل فعلی سند ما باید در بخش M2/M3/M4 اصلاح شود و M9 به آن اضافه شود؛ چون نسخه قبلی این ایده را به‌صورت عمومی پوشش می‌داد، اما آن را به‌عنوان یک «رژیم بهره‌برداری جهت‌دار» با پنجره‌های زمانی، Buffer بافق و جریان Loaded/Empty به اندازه کافی صریح نکرده بود. --- ## Prompt 11 — پرسش کاربر (`conversation-turn-21`) حالا اگر بخواهیم به واقعیت نزدیک باشیم باید بگم که بخش های کوچکی از مسیر دو خطه هستند. همچنین مسیر عادی بین سنگان و فولاد مبارکه شامل مسیر سنگان → تربت‌حیدریه → جندق → چادرملو → اردکان → سیستان → دیزیچه هست ## Prompt 11 — پاسخ دستیار (`conversation-turn-22`) بله؛ این اصلاحی که گفتید مدل را بسیار واقعی‌تر می‌کند و اتفاقاً نشان می‌دهد که نباید مسیر را به شکل ساده‌ی «سنگان–بافق تک‌خطه / بافق–فولاد دوخطه» مدل کنیم. در نسخه واقعی‌تر، باید کل مسیر به‌صورت یک Route مرکب از تعداد زیادی Segment با وضعیت‌های متفاوت زیرساختی مدل شود. مسیر موردنظر شما را فعلاً به این صورت در مدل می‌گذاریم: سنگان → تربت‌حیدریه → جندق → چادرملو → اردکان → سیستان → دیزیچه → فولاد مبارکه و هر یک از این کریدورها خودش به Segmentهای کوچک‌تر تقسیم می‌شود که ممکن است: تک‌خطه باشند؛ دوخطه باشند؛ بخش کوتاهی دوخطه و سپس دوباره تک‌خطه شوند؛ ایستگاه/خط فرعی یا محل تقاطع داشته باشند؛ محدودیت سرعت متفاوت داشته باشند؛ ظرفیت متفاوتی داشته باشند. نکته بسیار مهم پس دیگر نباید در موتور بنویسیم: «مسیر سنگان تا فولاد تک‌خطه است.» بلکه باید بگوییم: Route سنگان–فولاد مبارکه از مجموعه‌ای از Segmentهای دارای وضعیت زیرساختی و عملیاتی متفاوت تشکیل شده است. و این دقیقاً با معماری‌ای که قبلاً برای موتور طراحی کردیم سازگار است. ۱. درخت واقعی Route ساختار مدل باید تقریباً این‌گونه باشد: OD: سنگان → فولاد مبارکه │ └── Route R1 │ ├── Segment 1 │ سنگان → ... │ Single / Double │ ├── Segment 2 │ ... → تربت‌حیدریه │ ├── Segment 3 │ تربت‌حیدریه → ... │ ├── ... │ ├── Segment N │ ... → جندق │ ├── ... │ ├── Segment M │ ... → چادرملو │ ├── ... │ ├── اردکان │ ├── سیستان │ ├── دیزیچه │ └── فولاد مبارکه اما حتی این هم هنوز کافی نیست. چون هر Segment باید به Blockهای عملیاتی تقسیم شود. مثلاً: Segment S17 │ ├── Block B171 ├── Block B172 ├── Block B173 ├── Block B174 └── Block B175 بنابراین ساختار اصلی موتور می‌شود: Route→Segment→Block ۲. حالا ایده قبلی شما درباره حرکت دسته‌ای بسیار جالب‌تر می‌شود فرض کنید فقط بخشی از مسیر بین سنگان و مقصد تک‌خطه باشد. مثلاً به شکل مفهومی: سنگان │ │ Single ▼ A │ │ Double ▼ B │ │ Single ▼ C │ │ Double ▼ D │ │ Single ▼ E │ │ ... ▼ فولاد مبارکه حالا دیگر نمی‌توانیم یک دستور ساده بدهیم: «تمام Route را برای حرکت قطارهای باردار در یک جهت باز کن.» بلکه باید پنجره‌های جهت‌دار را فقط در قسمت‌هایی که لازم است ایجاد کنیم. ۳. اینجا مفهوم جدیدی وارد مدل می‌شود: Critical Single-Track Segment ممکن است Route صدها کیلومتر باشد ولی فقط چند بخش آن واقعاً عامل محدودکننده باشند. مثلاً: Route ───────────────────────────────────────────── [Single]──[Double]──[Double]──[Single]──[Double] ▲ ▲ │ │ Critical Critical Segment Segment در این حالت ظرفیت کل Route ممکن است بیشتر از چیزی باشد که با نگاه ساده به کل مسیر تصور می‌کنیم. موتور باید تشخیص دهد: کدام Segmentها واقعاً ظرفیت Route را محدود می‌کنند؟ و سپس: آیا می‌توان با زمان‌بندی جهت‌دار، ظرفیت آن Segment را افزایش داد؟ این همان جایی است که ایده شما تبدیل به یک الگوریتم بسیار قدرتمند می‌شود. ۴. حالا مثال شما را واقعی‌تر کنیم فرض کنیم قطارهای باردار: سنگان → فولاد مبارکه حرکت می‌کنند. در حالت ایده‌آل: سنگان │ │ → → → Loaded ▼ تربت‌حیدریه │ │ ▼ جندق │ │ ▼ چادرملو │ ▼ اردکان │ ▼ سیستان │ ▼ دیزیچه │ ▼ فولاد مبارکه اما همزمان واگن‌های خالی باید در جهت معکوس حرکت کنند: فولاد مبارکه │ │ ← ← ← Empty ▼ دیزیچه │ سیستان │ اردکان │ چادرملو │ جندق │ تربت‌حیدریه │ سنگان در مسیرهای دوخطه، این دو جریان می‌توانند تا حد زیادی مستقل باشند. اما در بخش‌های تک‌خطه: Loaded →→→ X Empty ←←← تعارض ایجاد می‌شود. ۵. بنابراین موتور باید «محل تعارض» را پیدا کند، نه اینکه کل Route را محدود کند این یکی از مهم‌ترین اصلاحات معماری است. مثلاً: سنگان ── S1 ── S2 ── S3 ── S4 ── S5 ── ... Single اگر S3 تک‌خطه و بقیه دوخطه باشند، نباید بگوییم: Route تک‌خطه است. بلکه: Route R1 │ ├── S1 Double ├── S2 Double ├── S3 Single ← Bottleneck Candidate ├── S4 Double ├── S5 Double └── ... و موتور باید ظرفیت S3 را با توجه به جریان‌های دوطرفه حل کند. ۶. اما حالا ایده شما می‌تواند حتی بهتر عمل کند فرض کنیم S3 یک Segment تک‌خطه است. می‌توانیم برای S3 بگوییم: Window 1 S3: سنگان → مقصد → → → → → → → Window 2 S3: مقصد → سنگان ← ← ← ← ← اما نکته مهم این است: لازم نیست کل Route در Window 1 فقط در جهت رفت باشد. فقط همان Segment محدودکننده می‌تواند چنین رژیمی داشته باشد. این تفاوت بسیار مهم است. ۷. در نتیجه، «Directional Window» باید در سطح Segment تعریف شود در نسخه جدید پیشنهاد می‌کنم ساختار داده را به این صورت اصلاح کنیم: DirectionalOperationWindow -------------------------------- window_id segment_id direction start_time end_time allowed_train_types max_train_count headway clearance_time switch_time buffer_requirement status یعنی: W=f(Segment,Direction,Time) نه: W=f(Route,Direction,Time) مگر اینکه سیاست بهره‌برداری واقعاً کل Route را یک‌طرفه کند. ۸. حالا یک مثال ترکیبی بسیار جالب فرض کنیم Route چنین وضعیتی دارد: سنگان │ │ Single │ A │ │ Double │ B │ │ Single │ C │ │ Double │ D │ │ Single │ E │ │ Double │ فولاد سه گلوگاه تک‌خطه داریم: S 1 ​ , S 2 ​ , S 3 ​ حالا اگر این سه گلوگاه در زمان‌های مختلف تحت پنجره‌های مختلف قرار بگیرند، موتور باید همزمانی پنجره‌ها را بررسی کند. مثلاً: Time → S1: → → → → | ← ← ← | → → → S2: → → → → | ← ← | → → → S3: → → → → | ← ← ← | → → اینجا دیگر مسئله یک محاسبه ساده ظرفیت نیست. این یک مسئله زمان‌بندی شبکه‌ای است. ۹. و این دقیقاً جایی است که M4 وارد می‌شود قبلاً گفتیم: M2 Operational Capacity Engine M3 Route Capacity Engine M4 Network Optimization Engine حالا مشخص می‌شود که M4 باید بتواند: Directional Windows چندین Segment را همزمان بهینه کند. یعنی تصمیم بگیرد: W s,t,d ​ که در آن: s = Segment t = Time d = Direction و سپس بررسی کند که این Windowها با حرکت قطارها در کل Route سازگار هستند یا خیر. ۱۰. یک مثال بسیار مهم فرض کنید قطار باردار از سنگان حرکت کرده: سنگان → A → B → C → D → فولاد و C یک Segment تک‌خطه است. قطار در C: 10:00 وارد C 10:40 از C خارج می‌شود اگر همزمان یک قطار خالی از جهت مخالف بخواهد وارد C شود: Empty: ←──── C موتور باید آن را رد کند. اما اگر قطار خالی در B منتظر بماند: Empty ↓ [B Buffer] ↓ wait و بعد از آزاد شدن C حرکت کند، برنامه ممکن است کاملاً feasible باشد. پس: «انتظار» لزوماً ظرفیت ازدست‌رفته نیست. اگر انتظار در یک Segment دوخطه یا ایستگاه مناسب اتفاق بیفتد، ممکن است دقیقاً ابزار استفاده از ظرفیت پنهان باشد. ۱۱. این موضوع برای دپوهای شما بسیار مهم است در طرح شما، دپو کردن واگن‌های خالی در بافق یک مثال از این مفهوم است. اما در Route واقعی: ممکن است نقاط دیگری نیز برای Buffering مناسب باشند. موتور باید بتواند شناسایی کند: Potential Buffer Node │ ├── Station tracks ├── Passing loops ├── Yard capacity ├── Formation capacity ├── Empty wagon storage └── Operational feasibility و بعد بگوید: برای افزایش ظرفیت Segment تک‌خطه X، اگر قطارهای مخالف در Node Y منتظر بمانند، ظرفیت Route چقدر افزایش می‌یابد؟ این دقیقاً یک مسئله Capacity Optimization است. ۱۲. یک تفاوت مهم بین «ظرفیت مسیر» و «ظرفیت کریدور» با اطلاعات جدید شما، من پیشنهاد می‌کنم در سند نهایی سه مفهوم را کاملاً جدا کنیم: Route مثلاً: سنگان → فولاد مبارکه Corridor یک بخش بزرگ عملیاتی/جغرافیایی از شبکه که ممکن است چند Route روی آن رقابت کنند. Segment کوچک‌ترین واحد زیرساختی مورد استفاده در محاسبات ظرفیت. پس: Route={S 1 ​ ,S 2 ​ ,...,S n ​ } و: Corridor={Route 1 ​ ,Route 2 ​ ,...} این تفکیک برای مرحله بعدی که می‌خواهیم چند جریان بار مختلف را همزمان روی شبکه تخصیص دهیم، بسیار مهم است. ۱۳. و اینجا «مسیر عادی» شما هم اهمیت پیدا می‌کند مسیر عادی‌ای که گفتید: سنگان → تربت‌حیدریه → جندق → چادرملو → اردکان → سیستان → دیزیچه → فولاد مبارکه باید در دیتابیس به‌عنوان یک Route Candidate / Operational Route ثبت شود. ولی موتور نباید فرض کند که همیشه همین مسیر بهترین مسیر است. چون بعداً ممکن است: Route جایگزین وجود داشته باشد؛ بخشی از مسیر مسدود شود؛ تعمیرات انجام شود؛ ظرفیت بخشی از مسیر کم شود؛ مسیر دیگری ظرفیت آزاد داشته باشد؛ هزینه یا زمان مسیر تغییر کند. در آن حالت: OD(Sangan,Foolad) ممکن است چند Route داشته باشد: R 1 ​ ,R 2 ​ ,R 3 ​ ,... و موتور بتواند آنها را مقایسه کند. ۱۴. یک نکته دیگر که از حرف شما خیلی مهم‌تر بیرون می‌آید ما نباید «دوخطه» را هم یک وضعیت صفر و یک بدانیم. مثلاً ممکن است: Segment S1: Single Segment S2: Double Segment S3: Double فقط در 12 km Segment S4: Single Segment S5: Double Segment S6: Single بنابراین در دیتابیس حتی می‌توانیم داشته باشیم: Track Configuration -------------------- Single Double Partial Double Parallel Single Tracks Passing Loop Temporary Double Under Construction Restricted و حتی بهتر: Track Configuration باید به‌صورت زمانی هم قابل تغییر باشد. مثلاً: S3 2026: Single 2028: Partial Double 2030: Double این برای Scenario & Sensitivity Analysis فوق‌العاده مهم است. ۱۵. در واقع حالا مدل نهایی ما خیلی قدرتمندتر شده من معماری را این‌طور می‌بینم: OD │ ▼ Route Generator │ ▼ Route Candidate Set │ ▼ ┌───────────────────┐ │ Segment Network │ └───────────────────┘ │ ┌───────────┼────────────┐ ▼ ▼ ▼ Single Double Mixed Track Track Track │ │ │ └───────────┼────────────┘ ▼ Operational Model │ ▼ Directional Window Engine │ ▼ Network Optimization │ ▼ Route Capacity C_r │ ▼ Network Capacity C_n │ ▼ Capacity Allocation │ ▼ Actual Operation │ ▼ Calibration و یک نتیجه مهم با اطلاعات جدید شما، من دیگر M9 را صرفاً «موتور بهره‌برداری جهت‌دار مسیرهای یک‌خطه» تعریف نمی‌کنم. بهتر است نامش باشد: M9 — موتور مدیریت رژیم بهره‌برداری و پنجره‌های جهت‌دار شبکه Operational Regime & Directional Window Engine چون ممکن است: یک Segment تک‌خطه باشد؛ Segment بعدی دوخطه باشد؛ Segment بعدی دوباره تک‌خطه باشد؛ قطار در بخش دوخطه منتظر بماند؛ در یک نقطه واگن خالی دپو شود؛ سپس جریان مخالف در یک پنجره مشخص عبور کند. یعنی موتور باید کل زنجیره عملیاتی را به‌صورت یک سیستم پیوسته ببیند، نه اینکه برای هر بخش جداگانه ظرفیت حساب کند. این اصلاح به نظرم برای سند فنی ما ضروری است. در نسخه بعدی باید مثال سنگان–تربت‌حیدریه–جندق–چادرملو–اردکان–سیستان–دیزیچه–فولاد مبارکه را به‌عنوان یک Case Study رسمی داخل سند قرار دهیم و با یک شبکه فرضی از Segmentها، دقیقاً نشان دهیم موتور چگونه پنجره‌های جهت‌دار، قطارهای باردار، قطارهای خالی، Bufferها، بخش‌های دوخطه و گلوگاه‌ها را همزمان حل می‌کند. --- ## Prompt 12 — پرسش کاربر (`conversation-turn-23`) یک بار دیگه از ابتدا ماهیت سامانه تولید ظرفیت جزئی و کلی را مرور کنیم: بسمه تعالی سند توضیحات اولیه موتور تولید ظرفیت پیش‌فرض‌ها دو خطه شدن مربوط به روت است و روت جدیدی ایجاد نمی‌کند. همچنین یکی از ایده‌های حل مسئله، مواجهه با بخش تک خطه به صورت دو خطه است. میزان فضا و امکانات تجمیع واگن‌های خالی در نقطه دو خطه شدن حد  بهینه این حالت را مشخص می‌کند. مسیر ترکیبی تک خطه و دو خطه به نفع جریان بار تنظیم می‌شود. بلاک مشترک در روت مشترک، حداکثر به میزان بهینه‌ترین روت امکان حمل دارد و لذا جذب بار در سایر روت‌های مشترک در این بلاک صرفا به عنوان رقیب خواهند بود و به دلیل بهینه بودن این روت، حمل بار در سایر روت‌های رقیب توجیه ندارد. به همین دلیل در صورتی که میزان بار در طول سال، کفاف ظرفیت این روت را ندهد، یا سیاست حفظ سایر روت‌ها وجود داشته و لذا سهمیه‌ای در طول سال به صورت طولی یا عرضی (موازی یا سریال) گلوگاه خواهد بود. قابلیت‌های سامانه تولید ظرفیت و برنامه‌ریزی سامانه تولید ظرفیت و برنامه‌ریزی باید این قابلیت را داشته باشد که با تعیین پارامترهای مختلف، قادر به برآورد ظرفیت حمل باشد. ·         دریافت ورودی‌های مختلف o        تعیین مبادی و مقاصد بار بر اساس اطلاعات بار (ورود اطلاعات) o        تعیین روت‌های مبدا مقصدی (توسط کاربر ادمین). ممکن است برای برخی از مبدا و مقصد بار، بیش از یک روت تعیین شود. §         سرخس- آپرین/ اینچه‌برون-گرمسار-آپرین/ سرخس-آپرین-بافق-بندرعباس/ سرخس-بافق-فولاد/ آپرین-بندرامام/ آپرین-رازی o        تعیین بچ‌های جهت‌دار o        تغییر طول ایستگاه o        تغییر طول قطار o        تعریف الگوی سرعت (بر اساس تک خطه و دو خطه، خالی و پر) o        ساعت نماز و ایستگاه‌های قابل نماز خواندن ·         خروجی‌ها o        محاسبه حداکثر ظرفیت حمل در هر روت بر اساس پارامترهای دریافتی o        برنامه اعزام قطارها / حداقل مدت زمان مورد نیاز جهت اعزام قطار بعدی در هر روت (بر اساس طول بزرگترین بلاک و کوتاه ترین ایستگاه بسته به تک خطه یا دو خطه بودن) o        محاسبه حداکثر ظرفیت حمل در مجموع همه روت‌ها (طبیعتا مجموعه‌ای از روت‌های بدون تداخل): موتور حل شبکه o        تعیین اولویت‌های حمل به ترتیب از حداکثر مجموع قابل حمل همچنین وجود بخش آنالیز حساسیت نسبت به ایجاد تغییراتی در شبکه برای فهمیدن اینکه با انجام مقدار مشخصی از هزینه، افزایش قابل قبولی در حمل بار رقم بخورد. نمایش وضعیت روت‌ها در هر مرحله به درک بهتر برنامه‌ریزی کمک می‌کند. لذا تا حد امکان، باید ابزار نمایش هریک از مراحل انجام پذیرد. ملاحظات و محدودیت‌های اعمالی ·         حداکثر سرعت قابل سیر در بلاک (بر اساس مشخصات خط، سازمان و نوع قطار) ·         قوانین تست ترمز ·         سوختگیری مورد نیاز لکوموتیوها Show more ## Prompt 12 — پاسخ دستیار (`conversation-turn-24`) بله. با متنی که الان دوباره آوردید، به نظرم بهتر است واقعاً از صفر بازتعریف کنیم؛ چون چند نکته در آن وجود دارد که اگر همین حالا دقیق شوند، بعداً در طراحی الگوریتم، دیتابیس و موتور حل شبکه جلوی ابهام‌های جدی را می‌گیرند. مهم‌ترین نکته‌ای که از مرور دوباره متن شما به دست می‌آید این است که این سامانه اساساً یک «محاسبه‌گر ظرفیت خط» نیست. بلکه باید یک موتور تولید، برآورد و برنامه‌ریزی ظرفیت در شبکه ریلی باشد که از یک ظرفیت محلی شروع می‌کند و به ظرفیت قابل تحقق کل شبکه می‌رسد. ۱. ابتدا ماهیت سامانه را در یک جمله مشخص کنیم پیشنهاد من برای تعریف پایه این است: موتور تولید ظرفیت، سامانه‌ای است که با دریافت وضعیت زیرساخت، مشخصات مسیرها، مشخصات قطار و ناوگان، قواعد بهره‌برداری، تقاضای بار، محدودیت‌های زمانی و سیاست‌های تخصیص، حداکثر جریان بار قابل تحقق را در سطح هر مسیر و سپس در سطح همزمان شبکه محاسبه و برنامه زمانی متناظر با آن را تولید می‌کند. بنابراین خروجی موتور فقط یک عدد نیست. بلکه حداقل این چهار چیز است: ظرفیت+برنامهزمانی+ترکیبجریان+دلایلمحدودکننده ​ مثلاً موتور نباید فقط بگوید: Route A = 2.4 میلیون تن در سال بلکه باید بتواند بگوید: Route A در سناریوی X، با این ترکیب قطارها، این الگوی سرعت، این پنجره‌های جهت‌دار و این محدودیت‌های ایستگاهی، حداکثر N قطار در روز و Q تن در سال قابل تحقق دارد؛ گلوگاه اصلی Segment S17 است و ظرفیت آن توسط رژیم بهره‌برداری جهت‌دار آزادشده است. این تفاوت بسیار اساسی است. ۲. من پیشنهاد می‌کنم «تولید ظرفیت» را دو سطح اصلی کنیم کل سامانه را می‌توان در ابتدا به دو موتور اصلی تقسیم کرد: سطح اول: موتور تولید ظرفیت جزئی Partial / Local Capacity Generation این موتور می‌پرسد: اگر این Route را به‌تنهایی یا در شرایط مشخص بهره‌برداری کنیم، حداکثر چه میزان جریان بار می‌توان از آن عبور داد؟ مثلاً: سنگان → فولاد مبارکه با پارامترهای مشخص: طول قطار طول ایستگاه سرعت وضعیت تک‌خطه/دوخطه Segmentها قطار باردار/خالی Headway تست ترمز سوخت‌گیری زمان نماز بچ جهت‌دار دپو ظرفیت ایستگاه و... خروجی: C r ​ یعنی ظرفیت Route در آن سناریو. ۳. سطح دوم: موتور تولید ظرفیت کلی Network Capacity Generation / Network Optimization حالا سؤال تغییر می‌کند: اگر چندین Route را همزمان فعال کنیم، حداکثر مجموع بار قابل حمل در کل شبکه چقدر است؟ این دیگر با جمع ظرفیت Routeها حل نمی‌شود. مثلاً: Route A = 3 میلیون تن Route B = 2 میلیون تن Route C = 4 میلیون تن نباید بگوییم: C N ​ =3+2+4=9 چون ممکن است هر سه Route در یک Segment یا Block مشترک باشند. پس: C N ​  =∑C r ​ بلکه: C N ​ =Maximum feasible simultaneous flow over the network ​ یعنی حداکثر جریان همزمان قابل تحقق در شبکه. این همان «موتور حل شبکه» است که در متن شما آمده. ۴. بنابراین ساختار اصلی سامانه باید این باشد اطلاعات شبکه │ ▼ ┌───────────────────┐ │ موتور تولید │ │ ظرفیت جزئی │ └───────────────────┘ │ ظرفیت هر Route │ ▼ ┌───────────────────┐ │ موتور حل شبکه │ │ ظرفیت کلی │ └───────────────────┘ │ ▼ ظرفیت همزمان شبکه │ ▼ برنامه اعزام قطار │ ▼ تخصیص ظرفیت این به نظرم باید هسته معماری سامانه باشد. ۵. حالا «دو خطه شدن مربوط به روت است» را دقیق کنیم جمله شما: دو خطه شدن مربوط به روت است و روت جدیدی ایجاد نمی‌کند. از نظر مفهومی درست است، ولی برای مشخصات فنی باید کمی دقیق‌تر نوشته شود. بهتر است بگوییم: دوخطه شدن یک یا چند بخش از مسیر، وضعیت زیرساختی Segmentهای همان Route را تغییر می‌دهد و به‌خودی‌خود Route جدیدی ایجاد نمی‌کند. چرا این اصلاح مهم است؟ چون مثلاً: Route R1: سنگان → فولاد می‌تواند شامل این وضعیت باشد: S1 = Single S2 = Single S3 = Double S4 = Double S5 = Single S6 = Double هنوز: R1=S1+S2+S3+S4+S5+S6 است. دوخطه شدن S3 فقط: State(S3):Single→Double را ایجاد می‌کند. Route جدیدی ساخته نمی‌شود. ۶. اما یک نکته مهم‌تر: دوخطه شدن فقط «افزایش ظرفیت» نیست این قسمت در ایده شما بسیار مهم است. در یک Route ترکیبی: Single → Double → Single → Double بخش دوخطه می‌تواند ابزار بهره‌برداری از بخش تک‌خطه نیز باشد. مثلاً: Double Track ┌─────────────────┐ │ │ Single │ │ Single ───────┤ ├─────── │ │ └─────────────────┘ Bafq/Station بخش دوخطه ممکن است محل: تجمع واگن‌های خالی؛ تشکیل قطار؛ انتظار قطار؛ سبقت؛ تنظیم فاصله؛ تغییر رژیم جهت؛ آماده‌سازی جریان بعدی باشد. بنابراین: ظرفیت بخش دوخطه بخشی از ظرفیت عملیاتی بخش تک‌خطه اطراف خود را نیز تحت تأثیر قرار می‌دهد. این دقیقاً همان چیزی است که در مثال سنگان–بافق مطرح کردید. ۷. «مواجهه با بخش تک‌خطه به صورت دوخطه» را رسمی کنیم این ایده شما به نظرم باید یکی از اصول اصلی موتور باشد. من اسم آن را می‌گذارم: رژیم بهره‌برداری شبه‌دوخطه Pseudo-Double-Track Operating Regime یعنی زیرساخت همچنان: Track=Single است، اما با استفاده از: بچ‌بندی قطارها؛ پنجره جهت‌دار؛ تجمیع قطارهای هم‌جهت؛ دپو واگن‌های خالی؛ نقاط دوخطه؛ زمان‌بندی تغییر جهت؛ رفتار عملیاتی مسیر می‌تواند شبیه یک مسیر دوطرفه با تفکیک زمانی جریان‌ها شود. این نکته خیلی مهم است: ما زیرساخت را دوخطه نکرده‌ایم. بلکه: ظرفیت عملیاتی آن را با تغییر رژیم بهره‌برداری افزایش داده‌ایم. ۸. حالا مفهوم «بچ جهت‌دار» جایگاه بسیار مهمی پیدا می‌کند در متن شما آمده: تعیین بچ‌های جهت‌دار این باید یک موجودیت رسمی در سامانه باشد. مثلاً: Batch B1 Direction: سنگان → فولاد Train Type: Loaded Start: 08:00 End: 18:00 Number of trains: N و سپس: Batch B2 Direction: فولاد → سنگان Train Type: Empty Start: ... End: ... Number of trains: M این دو Batch در بخش تک‌خطه نمی‌توانند همزمان فعال باشند. پس: B 1 ​ ∩B 2 ​ =∅ از نظر زمانی در Segment مشترک. ۹. اما بچ فقط برای تک‌خطه نیست این نکته را هم باید از همین ابتدا ثبت کنیم. Batch می‌تواند برای اهداف مختلف تعریف شود: ۱. Batch جهت‌دار → → → → → ۲. Batch نوع قطار مثلاً قطارهای باردار. ۳. Batch واگن خالی ← ← ← ← ۴. Batch عملیاتی مثلاً گروهی از قطارها که به دلیل یک محدودیت خاص باید پشت سر هم حرکت کنند. بنابراین: Batch=Operational Group of Train Movements و «جهت» یکی از ویژگی‌های آن است، نه تمام تعریف آن. ۱۰. حالا به مهم‌ترین بخش متن شما می‌رسیم: بلاک مشترک شما نوشته‌اید: بلاک مشترک در روت مشترک، حداکثر به میزان بهینه‌ترین روت امکان حمل دارد و لذا جذب بار در سایر روت‌های مشترک در این بلاک صرفاً به عنوان رقیب خواهند بود... این ایده مهم است، اما از نظر ریاضی باید کمی اصلاح شود تا در آینده موتور اشتباه نکند. بهتر است بگوییم: هر منبع مشترک شبکه، از جمله Block، Segment، Station یا سایر منابع عملیاتی، دارای ظرفیت محدودی است. تمام Routeهایی که برای عبور از آن منبع به یکدیگر وابسته‌اند، بر سر بخشی از همان ظرفیت مشترک رقابت می‌کنند. مثلاً: Route A ────────┐ │ Route B ────────┼── Shared Block │ Route C ────────┘ اگر: C b ​ =100 باشد، نمی‌توان: F A ​ =100 و: F B ​ =80 و: F C ​ =50 را همزمان پذیرفت. باید: F A ​ +F B ​ +F C ​ ≤C b ​ باشد؛ البته در صورتی که واحد جریان‌ها و نحوه مصرف ظرفیت یکسان باشد. ۱۱. اما ایده «بهینه‌ترین Route» شما چیست؟ به نظرم این بخش را باید از مفهوم «ظرفیت» جدا کنیم. فرض کنید: Route A → 100 Route B → 70 Route C → 40 و هر سه از یک Block مشترک عبور می‌کنند. اگر ظرفیت Block: C b ​ =100 باشد، Route A می‌تواند کل ظرفیت را مصرف کند. اما اینکه باید کل ظرفیت را به A بدهیم، یک مسئله Policy / Optimization است، نه صرفاً محاسبه ظرفیت. یعنی موتور باید بتواند دو حالت را داشته باشد: حالت بدون سهمیه ظرفیت به جریانی اختصاص پیدا می‌کند که بیشترین ارزش/هدف بهینه‌سازی را ایجاد می‌کند. حالت سهمیه‌ای مثلاً: F B ​ ≥F B min ​ حتی اگر Route A از نظر اقتصادی/فنی جذاب‌تر باشد. این دقیقاً با جمله شما درباره «سیاست حفظ سایر روت‌ها» سازگار است. ۱۲. بنابراین «رقیب» باید یک مفهوم رسمی باشد دو Route وقتی: از یک Block مشترک، Segment مشترک، ایستگاه مشترک، مسیر زمانی مشترک، یا هر منبع ظرفیت‌دار مشترک استفاده کنند، می‌توانند: Competing Routes باشند. ولی دو Route ممکن است: Complementary Routes هم باشند. مثلاً یک Route می‌تواند ظرفیت آزاد را در نقطه‌ای مصرف کند که Route دیگری آزاد کرده است. پس موتور باید فقط «تداخل» را تشخیص ندهد. باید بفهمد: این دو Route رقیب‌اند یا مکمل؟ ۱۳. حالا مسئله سهمیه‌ای که گفتید این قسمت از متن شما بسیار مهم است: اگر میزان بار در طول سال کفاف ظرفیت این روت را ندهد، یا سیاست حفظ سایر روت‌ها وجود داشته و لذا سهمیه‌ای در طول سال به صورت طولی یا عرضی (موازی یا سریال) گلوگاه خواهد بود. من این مفهوم را به دو نوع سهمیه تقسیم می‌کنم: سهمیه زمانی ـ طولی مثلاً: سال │ ├── فصل 1 → Route A ├── فصل 2 → Route B ├── فصل 3 → Route A └── فصل 4 → Route C یا: ماه‌های خاص یعنی ظرفیت در طول زمان تقسیم می‌شود. سهمیه همزمان ـ عرضی مثلاً در یک روز: C b ​ =100 و سیاست می‌گوید: A≥30 B≥20 C≥10 بنابراین ظرفیت مشترک به شکل همزمان بین Routeها تقسیم می‌شود. این دو نوع سیاست باید پارامتریک باشند و داخل کد Hard-code نشوند. ۱۴. حالا «ظرفیت جزئی» را دقیق تعریف کنیم من پیشنهاد می‌کنم ظرفیت جزئی را این‌گونه تعریف کنیم: ظرفیت جزئی، ظرفیت قابل تحقق یک Route یا یک بخش مشخص از شبکه در یک سناریوی مستقل و با مجموعه پارامترهای مشخص است، بدون آنکه تمام رقابت‌ها و وابستگی‌های همزمان سایر Routeها در شبکه الزاماً اعمال شده باشند. مثلاً: C r isolated ​ یعنی: اگر Route R را تحت این شرایط بهره‌برداری کنیم، ظرفیتش چقدر است؟ این ظرفیت برای شناخت توان عملیاتی Route لازم است. اما هنوز ظرفیت شبکه نیست. ۱۵. «ظرفیت کلی» را هم دقیق تعریف کنیم ظرفیت کلی شبکه C N ​ باید این باشد: حداکثر مجموع جریان قابل تحقق مجموعه Routeها در یک بازه زمانی مشخص، با لحاظ تمام منابع مشترک، تداخل‌های زمانی و مکانی، محدودیت‌های عملیاتی، ظرفیت ناوگان، سیاست‌های سهمیه‌ای و هدف بهینه‌سازی. یعنی: C N ​ =max r ∑ ​ F r ​ ​ با قیود شبکه. البته اگر هدف فقط مجموع تن نباشد، تابع هدف می‌تواند چیز دیگری باشد. ۱۶. پس موتور دو سؤال کاملاً متفاوت دارد سؤال اول: این Route به تنهایی چقدر ظرفیت دارد؟ C r ​ سؤال دوم: اگر همه Routeها را با هم فعال کنم، شبکه چقدر می‌تواند حمل کند؟ C N ​ و حتی سؤال سومی داریم: اگر هدف من بیشینه‌کردن یک معیار خاص باشد، کدام ترکیب جریان‌ها بیشترین مقدار آن معیار را ایجاد می‌کند؟ maxZ(F 1 ​ ,F 2 ​ ,...,F n ​ ) این همان موتور حل شبکه است. ۱۷. خروجی «اولویت حمل» را هم باید دقیق کنیم در متن شما آمده: تعیین اولویت‌های حمل به ترتیب از حداکثر مجموع قابل حمل این را من تغییر می‌دهم. نباید صرفاً بگوییم: Routeهایی که ظرفیت بیشتری دارند، اولویت بالاتری دارند. چون ممکن است Route A به‌تنهایی ظرفیت ۵ میلیون تن داشته باشد، ولی استفاده از آن ۵ میلیون تن، امکان حمل ۸ میلیون تن در سایر Routeها را از بین ببرد. پس اولویت باید بر اساس اثر شبکه‌ای محاسبه شود. مثلاً: Marginal Network Capacity r ​ =C N with r ​ −C N without r ​ یا در حالت تخصیص: اضافه کردن این جریان به شبکه، چه مقدار ارزش/ظرفیت قابل تحقق شبکه را تغییر می‌دهد؟ این مفهوم برای موتور حل شبکه بسیار مهم است. ۱۸. بنابراین خروجی موتور بهتر است «رتبه Route» نباشد بلکه یک جدول تصمیم تولید کند: Route ظرفیت مستقل ظرفیت در شبکه مصرف گلوگاه ظرفیت شبکه‌ای ایجادشده محدودیت A ... ... ... ... ... B ... ... ... ... ... C ... ... ... ... ... و سپس بر اساس تابع هدف انتخاب کند. این خیلی علمی‌تر و قابل دفاع‌تر است. ۱۹. حالا ورودی‌هایی که در متن شما آمده‌اند را دسته‌بندی کنیم من ورودی‌های سامانه را به ۶ گروه اصلی تقسیم می‌کنم. گروه ۱ ـ تقاضا مبدأ مقصد مقدار بار بازه زمانی تقاضا نوع بار الگوی زمانی تقاضا مثلاً: D OD,t ​ گروه ۲ ـ شبکه Node Station Segment Block طول Block وضعیت Single/Double ظرفیت خطوط ایستگاهی نقاط تجمیع نقاط دپو نقاط تغییر جهت گروه ۳ ـ قطار طول قطار وزن قطار ظرفیت بارگیری نوع قطار باردار/خالی نوع لکوموتیو توان کشش مشخصات ترمز گروه ۴ ـ بهره‌برداری سرعت مجاز الگوی سرعت Headway زمان توقف تست ترمز سوخت‌گیری زمان تشکیل قطار زمان تغییر جهت زمان پاک‌سازی مسیر بچ جهت‌دار زمان نماز گروه ۵ ـ سیاست سهمیه Route حداقل سهم حداکثر سهم اولویت بار اولویت Route سیاست حفظ مسیر ظرفیت رزروشده گروه ۶ ـ سناریو مثلاً: Scenario 0 = وضعیت موجود Scenario 1 = افزایش طول ایستگاه‌ها Scenario 2 = افزایش طول قطار Scenario 3 = دوخطه شدن Segment X Scenario 4 = ایجاد محل تجمیع واگن خالی Scenario 5 = تغییر رژیم بهره‌برداری ۲۰. حالا «تغییر طول ایستگاه» چرا یک ورودی مهم است؟ چون طول ایستگاه مستقیماً روی: طول قطار قابل پذیرش؛ امکان عبور/تلاقی؛ امکان دپو؛ امکان تشکیل قطار؛ ظرفیت عملیاتی Segment تک‌خطه اثر دارد. مثلاً: L station ​