# سؤالی که با نقشه جواب داده نمیشود
هر تصمیم شهری — یک خیابان جدید، یک چراغ راهنمایی، یک خط اتوبوس — یک اثر زنجیرهای دارد. این اثر را نمیتوان با نگاه کردن به نقشه پیشبینی کرد، چون ترافیک نتیجه تعامل هزاران تصمیم مستقل رانندههاست، نه یک ویژگی ثابت خیابانها.
سؤالهایی که باید جواب بدهیم چیزی شبیه اینهاست:
تقاطعها
- آیا یک تقاطع خاص قفل میکند؟
- تغییر زمان چراغ چه اثری دارد؟
مسیرها
- آیا ترافیک فقط جابهجا میشود؟
- رانندهها کدام مسیر را انتخاب میکنند؟
شرایط سخت
- اگر باران ببارد چه؟
- اگر یک خیابان بسته شود چه؟
فشار بیشتر
- ۲۰ هزار خودروی اضافه؟
- ساعت اوج پیک؟
ابزار این کار شبیهسازی شهری است. یک شبیهساز شهری فقط یک نقشه سهبعدی زیبا نیست؛ خیابانها، خودروها، چراغها، مسیرها و رفتار رانندهها به مجموعهای از قوانین و محاسبات تبدیل میشوند و کامپیوتر ثانیهبهثانیه شهر را جلو میبرد. SUMO — یکی از ابزارهای متنباز و شناختهشده این حوزه — یک شبیهساز میکروسکوپی و گسسته از نظر زمان است که خودرو، عابر، حملونقل عمومی و چراغهای راهنمایی را مدل میکند.
# شهر را نمیتوان یکجا شبیهسازی کرد
اولین تصور اشتباه را کنار بگذاریم: کامپیوتر قرار نیست «شهر» را مثل یک بازی سهبعدی بارگذاری کند و دکمه Play را بزند. شهر برای کامپیوتر یک موجود واحد نیست؛ یک شبکه عظیم از سیستمهای کوچک است:
شهر
سیستم کلی از سیستمهای کوچکتر
خیابانها و لاینها
هر خیابان چند Lane با جهت مشخص
تقاطعها و قوانین عبور
هر تقاطع اولویت و محدودیت گردش خودش
چراغهای راهنمایی
فازها، زمانبندی و کنترل
خودروها و عابرها
عاملهای تصمیمگیرنده با مدل رفتاری
حملونقل عمومی
خطوط، ایستگاهها و زمانبندی
در SUMO، حداقل برای یک شبیهسازی ترافیکی دو چیز لازم است: شبکه راه و تقاضای سفر. شبکه شامل جادهها، لاینها و تقاطعهاست و تقاضا مشخص میکند چه وسیلهای، چه زمانی و در چه مسیری حرکت کند. پس اولین قدم این نیست که «ماشینها را بسازیم» — اول باید دنیایی بسازیم که ماشینها در آن حرکت کنند.
# قدم اول: تبدیل شهر واقعی به شبکه قابلمحاسبه
فرض کنید منطقهای از تهران را انتخاب کردهایم. چیزی که روی Google Maps میبینیم برای شبیهساز کافی نیست. کامپیوتر باید بداند کدام نقاط تقاطعاند، کدام خطوط خیاباناند، هر خیابان چند لاین دارد و هر لاین چه جهتی دارد. این ساختار در زبان گراف بسیار طبیعی است:
| مفهوم شهری | معادل در گراف | اطلاعات همراه |
|---|---|---|
| تقاطع | Node | مختصات، قوانین اولویت |
| خیابان (بین دو تقاطع) | Edge | طول، محدودیت سرعت، شکل |
| لاین حرکت | Lane | جهت، عرض، اجازه عبور کلاسها |
| اتصال تقاطع | Connection | کدام لاین به کدام لاین میرسد |
ایده کلیدی: برای کامپیوتر، شهر اول از همه یک تصویر نیست؛ یک گراف است. یک شهر کامل به گرافی بسیار بزرگ تبدیل میشود که روی آن میتوان محاسبه انجام داد.
چطور نقشه واقعی را وارد شبیهساز کنیم؟ SUMO میتواند دادههای خیابانی OpenStreetMap را وارد کند و از آن شبکه قابل استفاده بسازد. مستندات رسمی SUMO نیز همین مسیر را پیشنهاد میکنند: دریافت داده از OpenStreetMap و تبدیل آن به شبکه شبیهسازی.
1
OpenStreetMap — داده خام خیابانها
2
netconvert — تبدیل به شبکه شبیهسازی
3
city.net.xml — گراف قابلمحاسبه
4
sumo-gui — مشاهده و اجرا
اگر شبکه ایرادی داشته باشد، با netedit میتوان آن را اصلاح کرد: تعداد لاینها، جهت حرکت، چراغها، محدودیت گردش و مسیرهای ممنوع. SUMO حتی در مستندات سناریوسازی خود هشدار میدهد که شبکه واردشده از داده خام میتواند نقصهایی داشته باشد و ممکن است لازم باشد تقاطعها، لاینها و چراغها اصلاح شوند. شبیهسازی فقط به اندازه داده ورودی خوب است.
# مشکل بعدی: شهر بدون ماشین
اگر دقیقاً همان خیابانهای دنیای واقعی را روی کامپیوتر بسازیم ولی هیچ ماشینی واردشان نکنیم، شهر کاملاً خلوت است. پس باید چیزی به نام Traffic Demand بسازیم. تقاضای ترافیک در سادهترین شکل یعنی: چه کسی از کجا میآید و به کجا میرود؟ برای هزاران وسیله، این مسیرها به مجموعهای از سفرها تبدیل میشوند. در SUMO میتوان این تقاضا را با Vehicle، Flow، Trip و Route تعریف کرد.
| Flow | مبدا | مقصد | شدت | نوع وسیله |
|---|---|---|---|---|
| Flow A | edge-east | edge-west | 1000 veh/h | سواری |
| Flow B | edge-north | edge-south | 700 veh/h | سواری و ون |
| Flow C | edge-west | edge-north | 300 veh/h | کامیون سبک |
اما همه ماشینها مثل هم نیستند. یک پراید، کامیون، اتوبوس و موتورسیکلت رفتار یکسانی ندارند؛ حتی دو راننده با دو خودروی مشابه هم الزاماً یک رفتار ندارند. بنابراین برای وسیله نقلیه میتوان ویژگیهایی مثل Maximum Speed، Acceleration، Deceleration، Length، Vehicle Class و Preferred Speed تعریف کرد. حالا وقتی ۱۰ هزار وسیله وارد شهر میشوند، یک حرکت تصادفی ساده نداریم؛ هر خودرو طبق مجموعهای از قوانین تصمیم میگیرد.
# راننده داخل کامپیوتر چطور تصمیم میگیرد؟
کامپیوتر لازم نیست یک انسان کامل را شبیهسازی کند و بداند «این راننده امروز صبح چه حسی دارد». کافی است یک مدل رفتاری داشته باشد:
| شرایط | واکنش مدل | نام در ادبیات شبیهسازی |
|---|---|---|
| خودروی جلویی نزدیک شد | کاهش سرعت و حفظ فاصله | Car-Following |
| چراغ قرمز بود | توقف در خط توقف | Junction Model |
| مسیر جلو متراکم شد | تغییر لاین یا مسیر جایگزین | Lane-Changing / Re-routing |
| اولویت با طرف مقابل بود | توقف و واگذاری حق عبور | Right-of-Way |
در شبیهسازیهای میکروسکوپی، حرکت هر خودرو جداگانه محاسبه میشود. مدلهای Car-Following رفتار خودرو را بر اساس فاصله و سرعت وسیله جلویی و ویژگیهای رانندگی تعیین میکنند. این یعنی شهر ما حالا از چند هزار «نقطه متحرک» تشکیل نشده؛ از چند هزار عامل تصمیمگیرنده تشکیل شده است.
# حالا شهر شروع به «زندگی» میکند
فرض کنیم شبیهسازی با گام زمانی یک ثانیه اجرا میشود. SUMO بهطور پیشفرض شبیهسازی را با گام یکثانیهای اجرا میکند، هرچند اندازه گام قابل تغییر است. در هر گام، این چرخه تکرار میشود:
1
خواندن وضعیت — موقعیت و سرعت همه خودروها
2
تصمیم رانندهها — شتاب، ترمز، تغییر لاین
3
بهروزرسانی چراغها — تغییر فاز در لحظه درست
4
حرکت — موقعیت و سرعت جدید هر وسیله
↻
گام بعدی — t = t + 1 تا پایان شبیهسازی
اگر ۱۰ هزار خودرو داشته باشیم، کامپیوتر در هر لحظه باید وضعیت تعداد زیادی از آنها را محاسبه کند. به همین دلیل، «همه شهر با یک اندازه دقیق شبیهسازی نمیشود» — و این موضوع بخش بعدی است.
# سطوح جزئیات: از جریان تا موتور خودرو
شاید فکر کنید برای واقعی بودن شبیهسازی باید تکتک حرکات تمام خودروها را دقیق حساب کنیم. اما همیشه این کار لازم نیست. در شبیهسازی ترافیک معمولاً چند سطح جزئیات وجود دارد و مستندات SUMO دقیقاً این سطوح را تفکیک میکند:
Macroscopic
بهجای تکتک خودروها، جریان ترافیک مدل میشود؛ مثلاً ۷۰۰ خودرو در ساعت روی یک لاین.
هزینه محاسبه: کم
Mesoscopic
ترکیبی از جریان و رفتار فردی؛ خودروها در «سلولهای» مسیر حرکت میکنند.
هزینه محاسبه: متوسط
Microscopic
هر خودرو جداگانه مدل میشود — سطح پیشفرض SUMO برای سناریوهای شهری.
هزینه محاسبه: زیاد
Sub-microscopic
جزئیات داخلی خودرو هم وارد مدل میشود؛ مثل رفتار موتور یا ترمز.
هزینه محاسبه: بسیار زیاد
قاعده طلایی: شبیهسازی خوب لزوماً دقیقترین شبیهسازی نیست؛ شبیهسازیای است که در سطح مناسب، سؤال درست را جواب بدهد. اگر میخواهیم اثر یک بزرگراه را روی کل شهر بررسی کنیم، شاید لازم نباشد رفتار موتور هر خودرو را مدل کنیم.
# حالا یک سؤال واقعی بپرسیم
فرض کنید میخواهیم بدانیم بستن یک خیابان اصلی چه اثری دارد. دو نسخه از شهر میسازیم — نسخه فعلی و نسخهای که مسیر A → B در آن بسته است — و هر دو را با تقاضای یکسان اجرا میکنیم:
معیار
خیابان باز
خیابان بسته
میانگین زمان سفر
8.2 min
11.6 min
میانگین سرعت
31 km/h
22 km/h
زمان انتظار در تقاطع C
24 s
71 s
طول صف در مسیر جایگزین
~40 m
~180 m
اینجا شبیهسازی واقعاً ارزش پیدا میکند، چون دیگر فقط انیمیشن نمیبینیم؛ داریم دو آینده احتمالی را با هم مقایسه میکنیم.
# یک خیابان جدید همیشه ترافیک را کم نمیکند
این قسمت از همه جالبتر است. فرض کنید یک خیابان جدید ساختهایم تا ترافیک منطقه کمتر شود. در نگاه اول جواب باید مثبت باشد. اما ممکن است تعداد زیادی راننده مسیر کوتاهتر را انتخاب کنند و نتیجه برعکس شود:
خیابان جدید
←
جذب رانندههای بیشتر
←
تقاضای بیشتر
←
ازدحام در نقطهای دیگر
↺ چرخه تکرار میشود
در تحقیقات ترافیکی حتی مسئلهای به نام User Assignment وجود دارد؛ وقتی همه رانندگان به دنبال بهترین مسیر شخصی خودشان میروند، ممکن است مجموع این انتخابهای فردی به ازدحام شدید در بعضی مسیرها منجر شود. SUMO برای این مسئله مدلهای Dynamic User Assignment دارد. یعنی: بهترین مسیر برای یک راننده لزوماً بهترین حالت برای یک شهر نیست — این یکی از تفاوتهای مهم «بهینهسازی فردی» و «بهینهسازی سیستم» است.
# چراغ راهنمایی هم خودش یک سیستم است
فرض کنید یک چهارراه داریم. چراغ راهنمایی میتواند زمانبندی متفاوتی داشته باشد و هر تغییر، کل رفتار تقاطع را عوض میکند:
برنامه ۱ — متقارن
سبز مساوی برای هر دو محور؛ مناسب تقاطعهای با تقاضای متقارن.
برنامه ۲ — نامتقارن
سبز بیشتر برای محور شلوغتر؛ صف محور کمتردد بلندتر میشود.
SUMO اجازه میدهد چراغهای واقعی را با جزئیات مدل کنیم و حتی الگوریتمهای کنترل چراغ را بهصورت سفارشی به شبیهسازی متصل کنیم. پس میتوانیم واقعاً آزمایش کنیم: بهترین زمانبندی این چراغ برای این تقاطع چیست؟
# اینجا Python وارد میشود
SUMO فقط یک نرمافزار تصویری نیست. میتوانیم از طریق TraCI در زمان اجرای شبیهسازی با آن ارتباط برقرار کنیم. TraCI یک رابط TCP است که به برنامه خارجی اجازه میدهد وضعیت اشیا را بخواند و رفتار آنها را در حین اجرا تغییر دهد:
Python
↔
TraCI (TCP)
↔
SUMO
↔
شبیهسازی شهر
یعنی میتوانیم برنامهای بنویسیم که شبیهسازی را اجرا کند، تعداد خودروها و طول صفها را بخواند، چراغ را تغییر دهد و دوباره نتیجه را بررسی کند. این دیگر یک انیمیشن نیست؛ یک آزمایش علمی قابلبرنامهریزی است. مثلاً یک کنترلکننده تطبیقی ساده برای چراغ:
adaptive_signal.py
import traci
traci.start(["sumo", "-c", "city.sumocfg"])
while traci.simulation.getMinExpectedNumber() > 0:
# خواندن طول صف در دو محور تقاطع
q_ns = sum(traci.lane.getLastStepHaltingNumber(lane)
for lane in ["n_0", "s_0"])
q_ew = sum(traci.lane.getLastStepHaltingNumber(lane)
for lane in ["e_0", "w_0"])
# محور شلوغتر سبز بیشتری میگیرد
if q_ns > q_ew:
traci.trafficlight.setPhase("junction_C", 0) # NS green
else:
traci.trafficlight.setPhase("junction_C", 2) # EW green
traci.simulationStep()
traci.close()
همین ایده ساده را میتوان با الگوریتمهای پیچیدهتر یا حتی AI ترکیب کرد. در چنین حالتی یک حلقه بازخورد شکل میگیرد:
داده ترافیک
→
کنترلکننده
→
چراغ راهنمایی
→
وضعیت جدید ترافیک
↺ بازگشت به کنترلکننده
# و ناگهان میتوانیم AI را هم وارد شهر کنیم
فرض کنید میخواهیم بهترین زمانبندی چراغها را پیدا کنیم. میتوانیم هزاران حالت را اجرا کنیم و برای هرکدام معیارهایی مثل زمان سفر، زمان انتظار، طول صف، مصرف سوخت و انتشار آلاینده را اندازه بگیریم. بعد یک الگوریتم بهینهسازی یا AI به دنبال ترکیبی میگردد که نتیجه بهتری دارد. شهر تبدیل میشود به یک محیط آزمایش برای الگوریتم:
| سناریو | سبز NS / EW | زمان سفر | انتظار | صف بیشینه |
|---|---|---|---|---|
| #1 | 30s / 30s | 11.6 min | 96 s | 180 m |
| #2 | 40s / 20s | 10.4 min | 78 s | 142 m |
| #3 | 45s / 15s | 9.8 min | 61 s | 118 m |
| #4 | 50s / 10s | 12.9 min | 124 s | 205 m |
دقت کنید: سناریو #۴ سبز بیشتری به محور شلوغ میدهد ولی نتیجه بدتر میشود، چون محور کمتردد عملاً قفل میشود. این نوع بینشهایی است که فقط از اجرای مکرر شبیهسازی به دست میآید.
# کالیبراسیون با داده واقعی
فرض کنید داده واقعی داریم اما مدل ما چیز دیگری میگوید. پس مدل ما بیش از حد خوشبین است و باید پارامترها را تغییر دهیم تا به رفتار واقعی نزدیکتر شود. این فرایند Calibration است:
شهر واقعی
→
داده واقعی
→
شبیهسازی
→
مقایسه
→
اصلاح مدل
↺ تکرار تا همگرایی
این بخش بسیار مهم است، چون یک شهر دیجیتال خوب صرفاً «واقعی به نظر نمیرسد»؛ باید بتواند رفتار مشاهدهشده شهر واقعی را بازتولید کند.
# Digital Twin دقیقاً همینجا معنی پیدا میکند
اگر فقط یک شهر فرضی ساخته باشیم، یک Simulation داریم. اما اگر مدل دیجیتال با شهر واقعی ارتباط مداوم داشته باشد و داده واقعی دریافت کند، وارد قلمرو Digital Twin میشویم:
Simulation
مدل ایستا با ورودی ثابت
- یکبار ساخته و اجرا میشود
- جواب «اگر-آنگاه» میدهد
- برای مقایسه سناریو
Digital Twin
مدل پویا متصل به شهر واقعی
- داده زنده از سنسورها دریافت میکند
- مدام کالیبره میشود
- برای تصمیم لحظهای و بلندمدت
پژوهشهای جدید در حوزه Urban Digital Twins دقیقاً روی همین اتصال به دادههای پویا تمرکز دارند، چون یک مدل ثابت نمیتواند رفتار دائماً در حال تغییر شهر را بازنمایی کند. دادههای جمعسپاری موبایلی و سایر منابع متحرک یکی از راههای افزایش این پویایی هستند.
# اما چرا اصلاً انسانها را شبیهسازی کنیم؟
یکی از جدیدترین مسیرهای پژوهش شهری دقیقاً روی این بخش تمرکز دارد. در ژوئن ۲۰۲۶، پژوهشی در npj Complexity چارچوبی Agent-Based برای شبیهسازی الگوهای زندگی شهری ارائه کرد که برنامههای روزانه افراد را از ترکیب فعالیتهای اجباری مثل کار و مدرسه و فعالیتهای انعطافپذیر مثل خرید و تفریح مدل میکند و نتایج را با دادههای واقعی سفر مقایسه میکند. ایده جذاب این است: بهجای اینکه بگوییم «۱۰۰ هزار سفر»، بگوییم:
| عامل | برنامه روزانه | سفرهای تولیدشده |
|---|---|---|
| Person 1 | خانه → کار → خرید → خانه | 3 trips |
| Person 2 | خانه → مدرسه → خانه | 2 trips |
| Person 3 | خانه → کار → باشگاه → خانه | 3 trips |
بعد رفتار جمعی این افراد، الگوهای شهری را ایجاد میکند. یعنی ترافیک شاید در سطح شهر یک پدیده بزرگ باشد، اما میتواند از جمع هزاران تصمیم کوچک انسانی ساخته شود.
# یک نکته بسیار مهم: شبیهسازی آینده را نمیبیند
این شاید مهمترین بخش علمی مطلب باشد. شبیهسازی پیشگویی نیست. اگر مدل، شهر فردا را اشتباه پیشبینی کند، لزوماً به این معنی نیست که نرمافزار خراب است:
ورودی غلط
- داده تقاضا قدیمی یا ناقص
تغییر رفتار
- الگوی سفر انسانها عوض شده
مدل بیش از حد ساده
- فرض رفتاری غیرواقعی
رویداد خارج از مدل
- اتفاقی که در مدل وجود نداشت
پس فرمول درست چیست؟ شبیهسازی ≠ آینده. شبیهسازی = «اگر این فرضها درست باشند، احتمالاً این اتفاق میافتد.» این تفاوت، مرز بین مدل علمی و پیشگویی است. دشمن اصلی شبیهسازی، ساده بودن مدل نیست؛ اعتماد کردن به مدلی است که اعتبارسنجی نشده.
# چرا مدل ساده گاهی از مدل پیچیده بهتر است؟
تصور کنید میخواهیم بفهمیم یک خیابان جدید چه اثری روی زمان سفر دارد. لازم نیست موتور خودرو را شبیهسازی کنیم، لاستیک را مدل کنیم یا احتراق موتور را محاسبه کنیم. این اصل در شبیهسازی خیلی مهم است: جزئیاتی را محاسبه کن که برای سؤال تو مهماند. به همین دلیل شبیهسازی شهری خوب، لزوماً شبیهسازیای نیست که بیشترین جزئیات را داشته باشد؛ چیزی است که با هزینه قابلقبول، سؤال درست را پاسخ بدهد.
| سؤال | سطح مناسب | دلیل |
|---|---|---|
| اثر بزرگراه جدید بر کل شهر | Macro / Meso | مقیاس بزرگ، جزئیات فردی مهم نیست |
| زمانبندی یک چراغ خاص | Micro | رفتار صف و شروع حرکت مهم است |
| مصرف انرژی یک ناوگان برقی | Sub-micro | جزئیات دینامیک خودرو وارد محاسبه میشود |
# اگر بخواهیم واقعاً یک شهر آینده را طراحی کنیم
مسیر کامل یک پروژه جدی شبیهسازی شهری چیزی شبیه این است:
1
OpenStreetMap — نقشه واقعی منطقه
2
شبکه راه — گراف قابلمحاسبه
3
تقاضا و مدل خودرو — سفرها و ویژگیها
4
شبیهسازی — اجرای گامبهگام
5
کالیبراسیون — نزدیککردن به داده واقعی
6
AI / بهینهسازی — جستوجوی بهترین سناریو
و اگر این سیستم به داده زنده شهر متصل باشد، حلقه کامل میشود: سنسورها داده تولید میکنند، Digital Twin بهروز میماند، شبیهسازی سناریوها را میآزماید، تصمیم گرفته میشود و نتیجه دوباره به مدل برمیگردد. اینجا دیگر با «نقشه سهبعدی شهر» طرف نیستیم؛ با یک نسخه محاسباتی از شهر طرفیم.
# شهر را نمیسازیم؛ اول فرضیهاش را آزمایش میکنیم
برگردیم به سؤال اول: چگونه یک شهر را قبل از ساخته شدن اجرا میکنند؟ با ساختن یک بازی کامپیوتری از شهر نه — با ساختن یک مدل محاسباتی. خیابان را به شبکه تبدیل میکنیم، ماشینها را به عامل تبدیل میکنیم، رانندهها را با مدلهای رفتاری تقریب میزنیم، چراغها را به قوانین زمانی و کنترلی تبدیل میکنیم و جمعیت را به الگوهای سفر تبدیل میکنیم. بعد ساعتها، روزها و سناریوهای مختلف را اجرا میکنیم تا ببینیم اگر شرایط تغییر کند، سیستم چه واکنشی نشان میدهد.
در روش سنتی: ایده ← ساخت ← مشاهده نتیجه. اما در شهر دادهمحور: ایده ← شبیهسازی ← صدها سناریو ← انتخاب ← ساخت ← اندازهگیری ← بازگشت داده به مدل. یعنی قبل از اینکه یک تصمیم شهری هزینه واقعی داشته باشد، میتوان نسخه دیجیتال آن را امتحان کرد — و بعد از ساخت هم کار تمام نمیشود، چون شهر واقعی داده تولید میکند و مدل اصلاح میشود.
takeaway.txt
آینده شهرسازی این نیست که اول شهر را بسازیم و بعد ببینیم چه اتفاقی میافتد.
آینده این است که هزار نسخه از یک شهر را قبل از ساختن، در کامپیوتر شبیهسازی کنیم؛
هر بار با یک تغییر کوچک، یک سناریوی تازه بسازیم و در نهایت، بهترین نسخه را به دنیای واقعی بیاوریم.
آینده این است که هزار نسخه از یک شهر را قبل از ساختن، در کامپیوتر شبیهسازی کنیم؛
هر بار با یک تغییر کوچک، یک سناریوی تازه بسازیم و در نهایت، بهترین نسخه را به دنیای واقعی بیاوریم.
