פיתוח מערכת בינה מלאכותית לאופטימיזציה של קווי תחבורה ציבורית

אופטימיזציה של קווי תחבורה ציבורית: היכן התוכנית נשברת

תוכנית רשת הקווים מחושבת כמעט תמיד לפי ממוצעים: מרווח ממוצע, זרימת נוסעים ממוצעת ליממה, מהירות נסיעה ממוצעת. במציאות התמונה אחרת — זרימת נוסעים לא אחידה משמעה ששעת השיא של הבוקר צורכת רבע מהנפח היומי, ובצמתי החלפה העלייה לנוסעים מתבצעת בגלים של 5–7 דקות.

מרווח שאחיד על הנייר מתפורר בשעות השיא: עיכוב אחד בצומת גורר עיכוב נוסף, ואחרי שני סבבים בקו מופיעים יציאות כפולות ופערים של 20 דקות.

סטיות מלוח הזמנים מצטברות במפל, משום שלוח הזמנים אינו מתחשב לא בזמן הסיבוב בתחנה הסופית ולא במשך העצירה בפועל לצורך עליית נוסעים. המוקדן סוגר את הפערים ידנית — מזיז יציאה, מקצר סבב, מציב כלי רכב רזרבי. כל תיקון חי בטבלה נפרדת, הגרסאות מתפצלות, וכעבור עונה איש כבר לא יודע איזו מהן בתוקף.

הנתונים חלוקים עם המציאות לא פחות: חסרים בנתוני המיקום של כלי הרכב, מכשירי תיקוף נופלים, מקדמי עונתיות שחושבו פעם אחת ולא נבדקו מחדש. הטעויות מצטברות מעונה לעונה, ואופטימיזציה של קווי תחבורה ציבורית מידרדרת לעבודה לפי ממוצעים שלא קיימים במציאות.

אנחנו מפרקים כיצד זה נסגר — מאיחוד נתוני אמת למודל אחד ועד חישוב מחדש של מרווחים ולוחות זמנים בהתאם לזרימה בפועל.

מה משתנה לאחר ההטמעה: מרווחים, יציאות, כשלים

ההשפעה של ההטמעה נראית לא בדוח, אלא בלוח הזמנים ובתחנה. להלן נקודות ביקורת שלפיהן אנו משווים את התוצאה: כל אחת מחושבת על נתוני אמת ומשווה למצב לפני ההפעלה.

אנו לוקחים נקודות ייחוס ממדידות ענפיות, לא ממצגות — למשל, מדדי סדירות וזמן המתנה לפי נתוני UITP. אם המדד לא זז, סימן שמודל חיזוי זרימת הנוסעים לא לקח בחשבון גורמים מקומיים, ואנחנו מאמנים אותו מחדש על נתוני הצי הספציפי.

אנחנו בודקים את רשימת הביקורת בקווי פיילוט לפני הרחבה: אם המרווחים והיציאות מתנהגים באופן צפוי בשניים-שלושה קווים, המודל עובר לכל הרשת.

אפשרויות בניית מערכת: מלוחות זמנים ועד תאום דיגיטלי

ההסתעפות בהתחלה היא לא "איזה אלגוריתם מדויק יותר", אלא איזה מעגל ניהול אתם מוכנים לתחזק באופן קבוע. ארבע האפשרויות נבדלות במקור הנתונים, בתדירות החישוב מחדש ובמי שמקבל את ההחלטה האחרונה: המוקדן או המערכת.

האפשרויות אינן סותרות זו את זו: לוח זמנים ידני מתפתח למודל חיזוי, וזה — לתאום דיגיטלי, כשמופיע זרם נתונים יציב. הבחירה נקבעת בשלב הסקר — ממנה תלוי הרכב העבודות ואילו בדיקות ייכללו בקבלה.

כיצד מתבצעת ההטמעה: שלבי העבודה ההנדסית

ההטמעה מתבצעת בגלים: תחילה קובעים על אילו נתונים המערכת תחשב, ורק אחר כך משנים לוחות זמנים. סדר השלבים אינו מתחלף — מודל שהוגדר על נתונים לא עקביים מפיק דוחות יפים ומרווחים שגויים בקו.

1. ביקורת מקורות נתונים. מנתחים יומני מכשירי תיקוף ונתוני מיקום של כלי רכב, סדרי עבודה, לוחות זמנים בתוקף, פניות נוסעים. בודקים שלמות לפי ימי שבוע ועונה, התאמה במספר הנסיעות, סחיפת זמן בכלי רכב שונים, כפילויות וקטיעות רישום. בפלט — רשימת מקורות מתאימים, תדירות העדכון שלהם ורשימת אי-התאמות שצריך לסגור לפני ההתחלה.

2. סכמת רשת הקווים. בונים גרף של תחנות ומקטעי נסיעה, זמן נסיעה לפי מקטעים בחתך שעות היממה, זמן עלייה וירידה, נקודות החלפה ומקטעים משותפים. מקטעים שנויים במחלוקת מתאמים עם המוקדנים — הם יודעים היכן לוח הזמנים חורג מהמציאות.

3. הגדרת המודל. מגדירים פונקציית מטרה: המתנה בתחנה, מספר החלפות, עמידה במרווחים. בנפרד מגדירים אילוצים — מספר כלי רכב לקו, משטר עבודת נהגים, קיבולת.

4. בדיקת החיזוי על חתכים היסטוריים. מריצים את המודל על תקופות עבר ומשווים למציאות, לא לתאוריה. בודקים סטייה מלוח הזמנים, המתנה ממוצעת, שיעור נסיעות עם החלפה; במקום שבו הפער יציב, מרכיבים מחדש את נתוני הקלט.

5. הגדרת לוח הבקרה של המוקדן והדרכה. מראים כיצד לקרוא המלצות, מה לעשות בעת תקלת חיישנים וכיצד לחזור למצב ידני. מקיימים ניתוח מצבים שנויים במחלוקת ומשאירים נהלים קצרים לפי משמרות.

6. מסירה לתפעול. קובעים תפקידים והרשאות, לוח עדכון המודל, סדר בקרת איכות נתונים. בהמשך מלווים: מכווננים משקלים לפי משוב מהקו ומנתחים סטיות שמצטברות בין סקירות לוח הזמנים.

מה נשאר אצל המזמין: מודלים, נהלים, תיעוד

מערכת אופטימיזציה של קווים חיה לא רק בקוד — היא נשענת על נתונים, הרשאות ונהלים. אנחנו מוסרים את כל מה שדרוש לתפעול ולפיתוח עצמאי: שום רכיב לא נשאר "קופסה שחורה" שאי אפשר לבדוק, להגדיר מחדש או להחליף בכוחות הצוות שלכם.

מה בדיוק נשאר אצל המזמין:

• תצורת המערכת — משקלי קריטריונים לחישוב (זמן נסיעה, מספר החלפות, תפוסת תא הנוסעים), אופקי תכנון, כללים ליצירת לוחות זמנים. הפרמטרים מוצאים לקבצים נפרדים, לא מוטבעים בקוד: תיקון אינו דורש בנייה מחדש ושחרור גרסה.
• סכמות רשת הקווים — טופולוגיה של תחנות וקשרים ביניהן, אזורי שירות, מגבלות לפי סוג כלי רכב. בפורמט קריא למכונה עם תיאור הפורמט, כדי שאפשר יהיה לתקן ולבדוק את הרשת אוטומטית.
• מדיניות הרשאות — תפקידי מוקדן, אנליטיקאי ומנהל, גבולות הסמכויות שלהם, סדר מתן ושלילת הרשאה, תיעוד פעולות. ניתן לראות מי ומתי שינה לוח זמנים או פרמטרי חישוב.
• נוהל עדכון נתונים — תדירות טעינת מידע על זרימת נוסעים, גאומטריית רחובות ומצב תנועה, אחראים על המקור, התנהגות המערכת כשאין נתונים או כשהם חלוקים.
• הוראות למוקדנים — כיצד לקרוא סטיות מלוח הזמנים, מתי להפעיל חישוב מחדש ידני, מה לעשות בעת תקלה או אירוע המוני, כיצד לתעד אירוע ולהעביר אותו הלאה.
• תיאור ממשקי החלפה — פורמטים של ייצוא ובקשות למערכות סמוכות (כרטוס, ניווט), דוגמאות לתגובות תקינות ושגיאות טיפוסיות.
• תרחישי שחזור — גיבויים של תצורות ומודלים, סדר חזרה לגרסת לוח זמנים קודמת, קריטריונים שלפיהם החזרה נחשבת מוצלחת.

מקרה בוחן: כיצד צמצמנו סטיות מלוח הזמנים ברשת עירונית

מפעיל רשת עירונית — כמה עשרות קווים ומאות יציאות ביום. לקראת הערב לוח הזמנים חרג מהמציאות: המוקדנים תיקנו את הגרף ידנית, הסטיות מלוח הזמנים הצטברו עד 6–8 דקות, ויציאות שהופרו לקו כוסו ברכב רזרבי "לפי המצב".

מה מצאנו בנתונים

אספנו טלמטריה למשך חודש עבור כל יציאה: מרווחים בפועל, זמן נסיעה לפי מקטעים, עצירות וזמני שיא בנקודות תפנית. יותר ממחצית הסטיות נבעו לא מפקקים אלא מאי-התאמה בין התוכנית לזרימה — זמן הנסיעה המתוכנן בארבעה מקטעים היה קצר מהמצוי. מודל חיזוי לפי שעה ביממה ויום בשבוע הפריד בין ירידות צפויות לכשלים חד-פעמיים.

מה שינינו ומה הראו המדידות

הרכבנו מחדש את לוח הזמנים לפי פרופילי זמן נסיעה בפועל, הוספנו רזרבה מתגלגלת בקווים עם פיזור מרווחים רחב, והגדרנו התראה למוקדן כאשר נסיעה יוצאת ממסדרון הסטייה. מדדים לפני ואחרי:

• סדירות נסיעות: 82% → 96% בוצעו לפי לוח הזמנים;
• פיזור מרווחים במקטעי שיא: ±7 דקות → ±2.5;
• יציאות שהופרו לקו: 4.1% → 0.8% מכלל היציאות;
• שיעור הנסיעות שכוסו ברזרבה "בפועל" הצטמצם פי ארבעה.

כעבור רבעון התוצאה אושרה במדידה בלתי תלויה: פקחים מרכז לניהול תחבורה עירונית עברו בקווים לפי לוח הזמנים והשוו בין המציאות לתוכנית — הפער נשמר באותה רמה, ולא חזר לאחור כעבור חודש. מקרה הטמעה נחשב סגור כאשר את המדד רואה לא רק המבצע.

במה תאום דיגיטלי של רשת הקווים נבדל ממודל רגיל

מודל סטטיסטי נשען על סטטיסטיקה היסטורית: ממצע זרימת נוסעים לפי שעות, ימי שבוע ועונות, ועל בסיס זה בונה תחזית ביקוש. תחזית כזו מתארת נאמנה ביקוש שכבר התגבש, אך אינה יודעת שהרשת עצמה השתנתה.

הזיזו תחנה, הוסיפו נתיב ייעודי, קיצרו מרווח — המודל ימשיך לחשב לפי הפרופיל הישן עד שיצטבר היסטוריה חדשה.

תאום דיגיטלי הוא העתק דינמי ומקושר של הרשת: קווים, לוח זמנים, יציאות כלי רכב, צמתי החלפה וזרימת נוסעים בפועל חיים במודל אחד ומחושבים מחדש עם קבלת נתונים. הסטטיסטיקה ההיסטורית אינה נזרקת, אלא הופכת לפרופיל בסיס שאותו מתקנים אירועים שוטפים.

ההבדל המרכזי הוא בדיקת תרחישים. התאום מריץ גרסת לוח זמנים או קו חדש לפני היציאה לרחוב ומראה כיצד יתחלקו מחדש הזרימות, היכן יגדל זמן ההמתנה, ואילו צמתים יעומסו יתר על המידה. מודל סטטיסטי אינו יכול להשיב על שאלה כזו: בהיסטוריה אין נתונים על מה שעוד לא היה.

לתאום יש גבולות ישימות. הוא דורש טלמטריה תכופה ומדידות סדירות של זרימת נוסעים: על נתונים דלים או חלקיים המודל מתחיל לדייק את עצמו ומפיק תוצאה בטוחה אך שגויה. אירועים חד-פעמיים — חסימות, תאונות, אירועים המוניים — נכנסים אליו כהפרעות חיצוניות, לא כחלק מהתחזית.

הבחירה כאן אינה "תאום או סטטיסטיקה", אלא "באיזה אופק נדרשת התשובה". ליציאות מתוכננות די במודל היסטורי, ולהחלטות שמשנות את הרשת — בתאום עם בדיקת תרחישים.

ספקות טכניים: נתונים, דיוק, אינטגרציות

ספקות טכניים הם בדרך כלל אותם ספקות: האם יספיקו הנתונים, האם אפשר לסמוך על החיזוי, כיצד לשלב את המערכת במעגל הניהול הקיים. אנחנו מפרקים אותם בבדיקות קונקרטיות, לא בהבטחות.

לקלט נכנסים נתוני מיקום של כלי רכב, לוחות זמנים בפועל, רשומות מכשירי תיקוף, מזג אוויר ואירועים עירוניים. היסטוריה נלקחת מכמה תקופות קודמות, כדי שהמודל יראה ימי חול, סופי שבוע, חופשות ושיאים, ולא יום ממוצע.

כיצד בודקים את דיוק החיזוי אם כיום איש אינו מודד אותו?

בהרצה רטרוספקטיבית: המודל לומד על תקופה ישנה וחוזה את התקופה הבאה, שאנחנו כבר מכירים. את השגיאה מחשבים בנפרד לשעות שיא, בין שיאים ולסופי שבוע. תנודות עונתיות — שנת לימודים, חופשות, חגים, אירועים המוניים — נכנסות כמאפיינים נפרדים, לא כתיקון לפי העין.

כיצד המערכת משתלבת עם חדר המוקד, והאם אפשר להפעיל בחלקים?

דרך שכבת החלפה: המערכת קוראת את המצב הנוכחי ומוסרת המלצות בלי לשבור את המעגל הקיים. המוקדן רואה את ההצעה לצד התמונה בפועל ויכול לדחות אותה — סיבת הדחייה חוזרת למודל. ההרחבה מתבצעת בהדרגה: תחילה מסדרון אחד במצב המלצה, ואוטומציה — לאחר תוצאות יציבות.

נדון במשימה: ממה מתחילה העבודה על המערכת

העבודה מתחילה בפגישה לפני הפרויקט: דנים איזו משימה המערכת צריכה לפתור — לקצר זמן המתנה, לפרוק צמתי החלפה או לחלק מחדש כלי רכב בין קווים. באותה פגישה קובעים אילו נתונים כבר יש לכם ובאיזה פורמט, ומה יהיה צורך לאסוף.

לאחר מכן נדרשת רשימת נתונים — בלעדיה כל הערכה תהיה מקורבת:

• נתוני תנועה: רישומי מעבר בתחנות, היסטוריית עיכובים וסטיות מלוח הזמנים לאורך כמה עונות, כולל תקופות תקלה.
• לוחות זמנים ויציאות לקווים בתוקף — בצורה שבה מוסר אותם שירות המוקד.
• סכמת רשת: תחנות, מקטעי נסיעה, צמתי החלפה, מגבלות על נתיבים ייעודיים, נקודות תפנית וזמני פעילות מקטעים.
• זרימת נוסעים לפי תחנות ושעות ביממה — גם אם מקורבת, היא נחוצה כדי לבדוק השערות לפני תחילת העבודות.
• קריטריוני קבלה: מה בדיוק נחשב שיפור — אחידות מרווחים, זמן נסיעה, שיעור נסיעות שהופרו או קישוריות החלפות.

לפי תמונה זו אנחנו חוזרים עם הערכה ותוכנית עבודה: היקף, סדר שלבים, תלויות וסיכונים. הצעד הראשון — מקטע פיילוט בכמה קווים, שבו ההשערות נבדקות על לוח זמנים חי וניתן לראות השפעה בפועל. סדר ההרחבה לכל הרשת נקבע לפי תוצאות הפיילוט, לא מראש על הנייר.

תארו את המשימה ואת מה שכבר קיים בנתונים — נחזור עם הערכה ותוכנית עבודה.