בניית מודל של לוגיקה עסקית באמצעות מאפייני מעבר

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

לפני שמתחילים

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

מעבר הוא קטע המסלול שמקשר בין מיקום אחד למיקום הבא.

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

• נקודת ההתחלה של המסלול.
• עצירה שבה מתבצע איסוף או משלוח.
• נקודת הסיום של המסלול.

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

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

הדגמה של תרחישים מהעולם האמיתי

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

שיריון מקום חנייה

בתרחיש הזה, הנהג צריך להחנות את הרכב לפני שהוא יכול להגיע למיקום א'. מיקום ב' נמצא בקרבת מקום, והנהג יכול להשתמש באותו מקום חנייה בשני הביקורים. אם הנהג מבקר ב-B מיד אחרי A, הוא חוסך זמן כי הוא לא צריך לצאת מחנייה ולהחנות את הרכב שוב. ב-Route Optimization API, אפשר להשתמש במאפייני מעבר כדי להוסיף זמן חנייה רק כשהנהג עובר ממקום חנייה אחד למקום חנייה אחר.

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

כדי לעשות את זה בבקשה ל-Route Optimization API:

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

2. לכל מקום חנייה ייחודי שמשמש במודל, צריך להשתמש בתג חדש שלא משמש לשום דבר אחר במודל, לדוגמה PARKING_123.

3. מוסיפים את התג הזה לרכיבים הבאים:

   1. ‫VisitRequest.tags בכל בקשות הביקור שמשתמשות במקום החניה הזה.

   2. ‫Vehicle.start_tags אם הרכב מתחיל את המסלול שלו במקום החניה הזה.

   3. ‫Vehicle.end_tags אם הרכב מתחיל את המסלול ומסיים אותו במקום החנייה הזה.

4. לכל תג חנייה חדש, מוסיפים רשומה ל-ShipmentModel.transition_attributes כדי להוסיף עיכוב לחנייה כשמגיעים ממקום חנייה אחר, באופן הבא:

   1. מגדירים את TransitionAttributes.excluded_src_tag ואת TransitionAttributes.dst_tag לערך PARKING_123.

   2. מגדירים את TransitionAttributes.delay לשעה שבה צריך להחנות את הרכב.

   לדוגמה, אם התג של מיקום הוא PARKING_123 ולוקח 150 שניות להחנות את הרכב, מוסיפים את הרשומה הבאה אל ShipmentModel.transition_attributes:

   {
     "excluded_src_tag": "PARKING_123",
     "dst_tag": "PARKING_123",
     "delay": "150s"
   }
   

ניקוי חובה בסוף המסלול

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

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

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

1. בוחרים שני תגים חדשים שלא נמצאים בשימוש בשום מקום במודל, לדוגמה CLEANED ו-ROUTE_END. הראשון הוא למיקומים שבהם הרכב נקי או הופך לנקי, והשני הוא לסוף המסלול.
2. לכל רכב, מוסיפים משלוח חדש מסוג 'משלוח בלבד' שמייצג את הביקור במתקן ניקוי, עם המאפיינים הבאים:
   1. כל מיקום של מתקן ניקוי צריך להיות מיוצג כבקשה לביקור לצורך משלוח.
   2. מוסיפים CLEANED אל VisitRequest.tags של כל בקשת ביקור במשלוח של מתקן הניקוי. הוא מציין שכלי רכב שיוצא מהמיקום הזה הוא נקי. בקשות אחרות לביקור במודל לא צריכות להשתמש בתג הזה, כדי שהרכב ייחשב כ'לא נקי' כשהוא עוזב אותן.
   3. כדי לאפשר לכלי האופטימיזציה לדלג על המשלוח הזה אם הרכב לא נמצא בשימוש, צריך להגדיר את הערך של penalty_cost למספר קטן.

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

4. לכל רכב, מוסיפים ROUTE_END אל Vehicle.end_tags.

5. מוסיפים רשומה חדשה ל-ShipmentModel.transition_attributes שבה נאסר על כלי רכב להגיע לציון הדרך האחרון של כלי הרכב אם הם לא נקיים, עם המאפיינים הבאים:

   1. מגדירים את TransitionAttributes.excluded_src_tag לערך CLEANED.

   2. מגדירים את TransitionAttributes.dst_tag לערך ROUTE_END.

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

   לדוגמה, אם קנה המידה של הזמן במודל הוא יום עבודה אחד, אפשר להשתמש בעיכוב של 24 שעות (86,400 שניות) כדי למנוע את המעבר לסוף המסלול מכל מקום, למעט מתקן ניקוי ותחילת המסלול:

   {
     "excluded_src_tag": "CLEANED",
     "dst_tag": "ROUTE_END",
     "delay": "86400s"
   }
   

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

איך בוחרים בין עיכובים לעלויות

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

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

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

איך מוסיפים מאפיין מעבר שתואם לכל בקשות הביקור

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

אי אפשר פשוט להשמיט את התגים, כי לכל הודעה TransitionAttributes חייב להיות אחד מהתגים TransitionAttributes.src_tag ו-TransitionAttributes.excluded_src_tag, ואחד מהתגים TransitionAttributes.dst_tag ו-TransitionAttributes.excluded_dst_tag.

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

קריאה נוספת

• פרמטרים של מודל עלות