Package google.research.optimization.v1

אינדקס

• Optimization (ממשק)
• DesignShippingNetworkRequest (הודעה)
• DesignShippingNetworkResponse (הודעה)
• SolveMathOptModelRequest (הודעה)
• SolveMathOptModelResponse (הודעה)
• SolveShiftGenerationRequest (הודעה)
• SolveShiftGenerationResponse (הודעה)
• SolveShiftSchedulingRequest (הודעה)
• SolveShiftSchedulingResponse (הודעה)

אופטימיזציה

ממשק API של One Platform שחושף קבוצה של פתרונות אופטימיזציה לבעיות מחקר תפעול ברמה גבוהה. MOE:begin_strip

DesignShippingNetwork

rpc DesignShippingNetwork(DesignShippingNetworkRequest) returns (DesignShippingNetworkResponse) פתרון בעיות העיצוב והתזמון של רשת השילוח של קווים (LSNDSP) משדה ה-DesignShippingNetworkRequest הנתון. רשת LSNDSP היא בעיית אופטימיזציה מורכבת, שמטרתה למצוא את התכנון והתזמון האופטימליים לרשת למשלוחי קווים. המטרה היא לצמצם את העלות הכוללת של תפעול הרשת, ובמקביל לעמוד בביקוש הגדול ביותר למטען בין יציאות. אפשר לפצל את ה-LSNDSP לשתי בעיות משנה עיקריות: עיצוב רשת ותזמון. בעיית המשנה של תכנון הרשת קובעת את קבוצת היציאות שיוצגו על ידי הרשת, את מספר כלי השיט שיש לפרוס בכל מסלול ואת המסלולים של כלי השיט. בעיית המשנה של התזמון קובעת את לוחות הזמנים להפלגות של כלי השיט, תוך התייחסות למשך הזמן של ההפלגה בין היציאות, הזמן שנדרש לטעינת המטען ולפריקת המטען, והביקוש להובלת מטענים בין הנמלים. במילים פשוטות, ה-LSNDSP הוא הבעיה בקבלת ההחלטה אילו יציאות לשרת, כמה אוניות להשתמש ואיך לתזמן את האוניות, כך שעלות התפעול של הרשת תמוזער תוך מיקסום ההכנסה ממענה לביקוש מטענים. רכיב משנה מאתגר של LSNDSP הוא ניתוב המטען, שקובע באילו דרישות לעמוד ואילו מסלולים להקצות למטען כדי למקסם את ההכנסות.

SolveMathOptModel
rpc SolveMathOptModel(SolveMathOptModelRequest) returns (SolveMathOptModelResponse) הפונקציה פותרת את מודל הקלט ומחזירה את התוצאה בבת אחת. אפשר להשתמש באפשרות הזו כשאין לך צורך בקריאות חוזרות (callbacks) או בהמרות מצטברות, ואין לך צורך לעקוב אחר ההתקדמות של פתרון.

SolveShiftGeneration
rpc SolveShiftGeneration(SolveShiftGenerationRequest) returns (SolveShiftGenerationResponse) הפתרון לבעיה של יצירת תזוזה מהSolveShiftGenerationRequest הנתון על ידי יצירת מעברים מתבניות Shift נתונות כדי לתת מענה לביקוש של העובדים.

SolveShiftScheduling
rpc SolveShiftScheduling(SolveShiftSchedulingRequest) returns (SolveShiftSchedulingResponse) פותר בעיה של תזמון משמרות קבוע מהSolveShiftSchedulingRequest הנתון על ידי הקצאת עובדים למשמרות, כך שהעדפות התזמון של העובדים מוגדלות והפרות של מגבלות התזמון מצטמצמות.

DesignShippingNetworkRequest

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

שדות
request_id	string מזהה הבעיה או הבקשה.
solver_parameters	SolverParameters פרמטרים לפותר.
ports[]	Port רשימה של יציאות אפשריות להתקשרות בשירותים של כלי שיט. הבקשה חייבת להכיל רק מזהי יציאות שמופיעים ברשימה הזו.
leg_candidates[]	LegCandidate רשימה של מועמדים פוטנציאליים להוספה לשירותי כלי שיט. הבקשה חייבת להכיל רק את המזהים של המועמדים שרשומים ברשימה הזו.
vessel_classes[]	VesselClass רשימה של קטגוריות כלי שיט לביצוע שירותים בכלי שיט. לתשומת ליבכם: כל כלי השיט מאותה קטגוריה ניתנים להחלפה ביניהם. הבקשה חייבת להכיל רק מזהי מחלקות של כלי שיט שנמצאים ברשימה הזו.
commodity_demands[]	CommodityDemand רשימה של הדרישות לגבי סחורות (כלומר, קונטיינרים) למילוי הזמנות באמצעות שירותים של כלי שיט.
vessel_services[]	VesselService ניתן לספק רשת של שירותי כלי שיט תקפים (בדרך כלל מצב הרשת הנוכחי) שישמש כנקודת התחלה לאופטימיזציה.

DesignShippingNetworkResponse

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

שדות
request_id	string מזהה הבקשה שאליה משויכת התשובה הזו.
vessel_services[]	VesselService רשת של שירותים לכלי שיט. בכל סיווג של כלי שיט, המספר הכולל של כלי שייט לא יכול להיות גדול ממספר כלי השיט שזמינים במחלקה הזו.
commodity_demand_paths[]	CommodityDemandPath רשימה של כל נתיבי הביקוש לסחורות שדרכם נשלחת ביקוש חיובי לסחורות. לתשומת ליבכם, יכול להיות שחלק ממזהי הביקוש למוצרים לא ייכללו אם לא יישלח ביקוש. לחלופין, ניתן למלא את הביקוש לסחורות באופן חלקי. לכל ביקוש לסחורה, הכמות הכוללת שמולאה לא יכולה להיות גבוהה מהביקוש הכולל. לבסוף, commodity_demand_paths תלוי ב-vessel_services (ראו בהגדרה CommodityDemandPath).

SolveMathOptModelRequest

בקשה לפתרון מרחוק של Unary ב-MathOpt.

שדות
solver_type	SolverTypeProto זה שינוי אופציונלי. סוג הפותר כדי לפתור את הבעיה מבחינה מספרית. שימו לב שאם פותר לא תומך בתכונה מסוימת במודל, תהליך האופטימיזציה לא יצליח.
model	ModelProto חובה. ייצוג מתמטי של בעיית האופטימיזציה שצריך לפתור.
parameters	SolveParametersProto זה שינוי אופציונלי. פרמטרים לשליטה בפתרון יחיד. הפרמטר enabled_output מטופל באופן ספציפי. לפותרים שתומכים בקריאות חוזרות (callback) של הודעות, אם מגדירים את הערך True, השרת ירשום קריאה חוזרת (callback) של הודעה. ההודעות שייווצרו יוחזרו ב-SolveMathOptModelResponse.messages. בפותרים אחרים, הגדרת Enable_output כ-true תגרום לשגיאה.
model_parameters	ModelSolveParametersProto זה שינוי אופציונלי. פרמטרים לשליטה בפתרון יחיד שהם ספציפיים למודל הקלט (ב-SolveParametersProto מפורטים פרמטרים בלתי תלויים במודל).

SolveMathOptModelResponse

תשובה לפתרון מרחוק של Unary ב-MathOpt.

שדות
result	SolveResultProto תיאור הפלט של פתרון המודל בבקשה.
messages[]	string אם נעשה שימוש ב-SolveParametersProto.enable_output, ההודעה תכלול הודעות יומן לפותרים שתומכים בקריאות חוזרות (callbacks) של הודעות.

SolveShiftGenerationRequest

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

שדות
solver_config	SolverConfig זה שינוי אופציונלי. פרמטרים לפותר.
shift_templates[]	ShiftTemplate חובה. קבוצה של תבניות Shift שמציינות כללים ליצירת שינויים.
employee_demands[]	EmployeeDemand חובה. הביקוש הכולל של העובדים שצריך לכסות את השינויים שנוצרו על ידי shift_templates.

SolveShiftGenerationResponse

תשובה לבעיה של Shift Generation. אם הערך של solution_status שהוחזר הוא SOLVED, אז קבוצת שינויים חוקיים שנוצרה על ידי הפותר מוחזרת בפונקציה employee_schedules. כדי ליצור לוח זמנים תקין לשינוי, המאפיינים הבאים צריכים להתקיים:

1. כל שינוי שנוצר ב-employee_schedules עומד בכללים המפורטים ב-ShiftTemplate התואם.
2. כל אירוע שנבחר בכל התאמה עומד בכללים המפורטים ב-ShiftTemplate.Event התואם.
3. המספר הכולל של העובדים שהוקצו לקבוצת השינויים שנוצרה מאותה ShiftTemplate לא עולה על maximum_employee_count מהתבנית.
4. קבוצת העובדים המוקצים מכסה את הביקוש בכל מרווח נתון.

שדות
solution_status	ShiftGenerationSolutionStatus הסטטוס של הפתרון שהוחזר. אם solution_status לא SOLVED, השדה employee_schedules יהיה ריק.
employee_schedules[]	EmployeeSchedule קבוצת משמרות שנוצרו על ידי הפותר יחד עם מספר העובדים שהוקצו לכל לוח זמנים.
demand_coverage_violations[]	DemandCoverageViolation הפרות של הכיסוי בביקוש על סמך employee_counts שהוקצה בemployee_schedules הנתון. הערך של employee_demands שצוין בבקשה נצברים. אם שני פרקי זמן של employee_demand חופפים, הביקוש יסוכם לאורך החלק החופף של הקטע.

SolveShiftSchedulingRequest

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

ניתן להגדיר מגבלות נוספות על תזמון לכל עובד כדי להגביל עוד יותר את הבעיה. כל מגבלות התזמון ודרישות הכיסוי מקבלות רמת עדיפות (MANDATORY, high, MEDIUM, LOW). הפותר צריך לעמוד בכל המגבלות עם רמת העדיפות PRIORITY_MANDATORY. הפתרון יכול להפר מגבלות עם כל עדיפות אחרת, אבל ההפרות האלו מצטמצמות לפי סדר העדיפות. ב-enum Priority מופיעים פרטים נוספים על אופן הטיפול ברמות העדיפות של כל אילוץ.

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

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

שדות
request_id	string מזהה הבעיה או הבקשה.
solve_parameters	SolveParameters פרמטרים לשליטה בפתרון אחד לבעיה.
employees[]	Employee כל העובדים הזמינים לקביעת תורים.
shifts[]	Shift כל המשמרות כדי ליצור את לוח הזמנים.
coverage_requirements[]	CoverageRequirement דרישות כיסוי לכל אופק התכנון. הפרט הזה מציין את מספר העובדים שצריכים לבצע כל תפקיד או שיש להם מיומנות, בחלון זמן מסוים או ברשימה של מזהי משמרת. יש לציין את כל דרישות הכיסוי באמצעות חלונות זמן או רשימה של מזהי שינוי (אבל לא את שניהם). חלונות הזמן (אם הוגדרו) של דרישות הכיסוי לא יכולים להיות חופפים לכל מיקום נתון. רמת העדיפות שמוגדרת כברירת מחדל לכל אחת מהמגבלות האלה היא PRIORITY_MANDATORY לדרישות התפקיד ו-PRIORITY_LOW לדרישות המיומנות. פרטים נוספים זמינים ב-enum Priority.
role_ids[]	string רשימה של כל התפקידים האפשריים ברחבי כוח העבודה. לכל עובד צריך להיות לפחות תפקיד אחד שאפשר להקצות לו למשמרת. 'תפקיד' מתייחס למטלה ספציפית במהלך משמרת (כלומר, אחות רשומה, שף בכיר, מלצרית וכו'). כשעובדים מקבלים משמרת, הם מקבלים גם תפקיד ספציפי אחד.
skill_ids[]	string רשימה של כל המיומנויות האפשריות בקרב העובדים. 'מיומנות' מתייחסת להסמכות נוספות שעשויות להיות לעובד, שאינן קשורות לעבודה ספציפית שניתן להקצות (למשל: הסמכות, שפות מדוברות וכו'). הרשימה יכולה להיות ריקה. כשעובדים מקבלים משמרת, עליהם להשלים את כל המיומנויות שנדרשות לאותה משמרת.
location_ids[]	string רשימה של כל המיקומים האפשריים לקבוצת השינויים בלוח הזמנים. הרשימה יכולה להיות ריקה. ציון מיקומים שונים יכול להיות שימושי כאשר, למשל, מנהל אחות רוצה להזמין אחים רבים ביחידות שונות של בית חולים, או, למשל, מנהל מלון רוצה להזמין עובדים למספר מלונות.
budget_requirements[]	BudgetRequirement מפרט התקציב לבעיה בתזמון. רמת העדיפות שמוגדרת כברירת מחדל לכל אחת מהדרישות האלה היא PRIORITY_LOW. פרטים נוספים זמינים ב-enum Priority.
assignments_hint[]	ShiftAssignment מעבירים מטלות לשימוש כפתרון טנטטיבי (שנקרא גם רמז לפתרון) לבעיית התזמון. אם המטלה סותרת שינוי שלא ניתן להקצאה או בקשה לתזמון, המערכת מתעלמת מרמזים של מטלות.

SolveShiftSchedulingResponse

תשובה לממשק ה-API של תזמון כוח העבודה. בכל תגובה, השדה shift_assignments יהיה ריק אם solution_status שהוחזר הוא NOT_SOLVED_DEADLINE_EXCEEDED או INFEASIBLE. אם הערך של solution_status שהוחזר הוא OPTIMAL או FEASIBLE, תוחזר משימת משמרות חוקית ב-shift_assignments. כדי להקצות משמרת חוקית, צריכים להתקיים התנאים הבאים:

1. כל מזהה עובד נכלל בקבוצת העובדים שצוינה בבקשה.
2. כל מזהה תפקיד שמוקצה לעובד כלול בקבוצה של מזהי התפקידים של העובד הנתון.
3. כל מזהה שינוי נכלל בקבוצת השינויים שמופיעה בבקשה.
4. כל מזהה משמרת הוא לא אחד מהמזהים של העובד הנתון שלא ניתן להקצות להם.
5. עובד אף פעם לא יוקצה לשתי משמרות חופפות.
6. בלוח הזמנים הנתון, אף אחת מהמגבלות או הבקשות ברמת העדיפות PRIORITY_MANDATORY לא מפירה.

שדות
request_id	string מזהה הבקשה שאליה משויכת התשובה הזו.
solution_status	SolutionStatus הסטטוס של הפתרון שהוחזר. אם הפתרון הוא לא FEASIBLE או OPTIMAL, יכול להיות ששדות אחרים ב-Proto יהיו ריקים. אם הסטטוס הוא NOT_SOLVED_DEADLINE_EXCEEDED, הגעת למגבלת הזמן מבלי למצוא פתרון ישים או מבלי לקבוע אם קיים פתרון ישים. ייתכן שלא יהיה אפשר לבצע את הבקשות אם לא ניתן יהיה לעמוד במגבלות של רמת העדיפות MANDATORY.
shift_assignments[]	ShiftAssignment רשימה של כל המטלות. בכל ShiftAssignment מצוין עובד, המשרה שאליה הוא מוקצה והתפקיד שהוקצה לו לבצע במשמרת הזו.
status_message	string אם הערך של solution_status לא אופטימלי, יכול להיות שהשדה הזה מכיל מידע נוסף על הפותר.