فهرست مطالب
-
Optimization(رابط) -
DesignShippingNetworkRequest(پیام) -
DesignShippingNetworkResponse(پیام) -
SolveMathOptModelRequest(پیام) -
SolveMathOptModelResponse(پیام) -
SolveShiftGenerationRequest(پیام) -
SolveShiftGenerationResponse(پیام) -
SolveShiftSchedulingRequest(پیام) -
SolveShiftSchedulingResponse(پیام)
بهينه سازي
یک API یک پلتفرم که مجموعه ای از حل کننده های بهینه سازی را برای مسائل تحقیقاتی عملیات سطح بالا نشان می دهد. MOE:begin_strip
| DesignShippingNetwork |
|---|
مشکل طراحی و زمانبندی شبکه حمل و نقل لاینر (LSNDSP) را از LSNDSP یک مسئله بهینه سازی پیچیده است که به دنبال یافتن طراحی و زمان بندی بهینه یک شبکه حمل و نقل خطی است. هدف این است که هزینه کل عملیات شبکه را به حداقل برسانیم، در حالی که تا حد امکان نیاز محموله بین بنادر را برآورده کنیم. LSNDSP را می توان به دو زیر مشکل اصلی تقسیم کرد: طراحی شبکه و زمان بندی. زیرمشکل طراحی شبکه مجموعه پورت هایی را که باید توسط شبکه سرویس دهی شود، تعداد کشتی هایی که در هر مسیر مستقر می شوند و مسیرهایی که کشتی ها طی خواهند کرد را تعیین می کند. مشکل فرعی زمانبندی، برنامههای دریانوردی کشتیها را با در نظر گرفتن زمان حرکت بین بنادر، زمان بارگیری و تخلیه محموله و تقاضا برای حمل بار بین بنادر تعیین میکند. به عبارت ساده، LSNDSP مشکل تصمیم گیری در مورد اینکه کدام بنادر باید سرویس دهی شود، از چند کشتی استفاده شود، و نحوه برنامه ریزی کشتی ها به گونه ای است که هزینه عملیات شبکه به حداقل برسد و در عین حال درآمد برای برآورده کردن تقاضای محموله به حداکثر برسد. یکی از اجزای فرعی چالش برانگیز LSNDSP مسیریابی محموله است که تعیین می کند کدام خواسته ها را برآورده کند و کدام مسیرها را به محموله اختصاص دهد تا درآمد را به حداکثر برساند. |
| SolveMathOptModel |
|---|
مدل ورودی را حل می کند و نتیجه را یکباره برمی گرداند. زمانی که نیازی به تماسهای برگشتی، افزایشی ندارید و نیازی به ردیابی پیشرفت حل ندارید از این استفاده کنید. |
| SolveShiftGeneration |
|---|
یک مشکل تولید شیفت را از |
| SolveShiftScheduling |
|---|
یک مشکل زمانبندی شیفت ثابت از |
DesignShippingNetwork Request
این درخواست دارای نمونهای از LSNDSP است و باید شامل مجموعهای از پورتها، مجموعهای از نامزدهای پا، مجموعهای از کلاسهای کشتی و مجموعهای از خواستههای کالا برای برآورده شدن باشد.
| زمینه های | |
|---|---|
request_id | مشکل یا شناسه درخواست. |
solver_parameters | پارامترهای حل کننده |
ports[] | فهرست بنادر احتمالی برای فراخوانی در خدمات کشتی. درخواست فقط باید شامل شناسه های پورت باشد که در این لیست هستند. |
leg_candidates[] | فهرست نامزدهای بالقوه پا برای اضافه شدن به خدمات کشتی. درخواست فقط باید شامل شناسههای نامزدی پا باشد که در این لیست هستند. |
vessel_classes[] | لیست کلاس های کشتی برای انجام خدمات کشتی. توجه داشته باشید که همه کشتی های یک کلاس کاملاً قابل تعویض هستند. درخواست فقط باید شامل شناسه های کلاس کشتی باشد که در این لیست هستند. |
commodity_demands[] | فهرست کالاهای بالقوه (به عنوان مثال کانتینر) که باید توسط خدمات کشتی برآورده شود. |
vessel_services[] | شبکه ای از خدمات کشتی معتبر (معمولاً وضعیت فعلی شبکه) می تواند به عنوان نقطه شروع برای بهینه سازی استفاده شود. |
DesignShippingNetworkResponse
پاسخ، راه حل نمونه LSNDSP را در درخواست نگه می دارد. این شامل یک شبکه معتبر از خدمات کشتی و مسیرهای تقاضای کالا است. مجموع تقاضای کالایی که در هر قسمت میگذرد، نمیتواند از ظرفیت کلاس کشتی که در این قسمت خدمت میکند تجاوز کند. توجه داشته باشید که نداشتن خدمات کشتی بدون تقاضای برآورده شده همیشه یک راه حل عملی برای مشکل طراحی و برنامه ریزی شبکه حمل و نقل خطی است.
| زمینه های | |
|---|---|
request_id | شناسه درخواستی که این پاسخ با آن مرتبط است. |
vessel_services[] | شبکه خدمات کشتی برای هر کلاس شناور، تعداد کل شناورهای مورد استفاده نمی تواند از تعداد شناورهای موجود برای این کلاس تجاوز کند. |
commodity_demand_paths[] | فهرست تمام مسیرهای تقاضای کالا که تقاضای مثبت کالا از طریق آنها ارسال می شود. توجه داشته باشید که در صورت عدم ارسال تقاضا، برخی از شناسههای تقاضای کالا ممکن است گنجانده نشوند. از طرف دیگر، تقاضای کالا می تواند تا حدی برآورده شود. برای هر تقاضای کالا، کل مقدار برآورده شده نمی تواند از کل تقاضا بیشتر شود. در نهایت، commodity_demand_paths به سرویس_رگ ها بستگی دارد (به تعریف CommodityDemandPath مراجعه کنید). |
SolveMathOptModelRequest
درخواست حل یکپارچه از راه دور در MathOpt.
| زمینه های | |
|---|---|
solver_type | اختیاری. حل کننده برای حل عددی مسئله تایپ کنید. توجه داشته باشید که اگر یک حل کننده از ویژگی خاصی در مدل پشتیبانی نکند، روند بهینه سازی موفقیت آمیز نخواهد بود. |
model | ضروری. یک نمایش ریاضی از مسئله بهینه سازی برای حل. |
parameters | اختیاری. پارامترهایی برای کنترل یک حل واحد. پارامتر enable_output به طور خاص مدیریت می شود. برای حلکنندههایی که از تماسهای پیامها پشتیبانی میکنند، تنظیم آن روی true باعث میشود که سرور یک پاسخ تماس پیام را ثبت کند. پیام های به دست آمده در SolveMathOptModelResponse.messages بازگردانده می شوند. برای حل کننده های دیگر، تنظیم enable_output روی true منجر به خطا می شود. |
model_parameters | اختیاری. پارامترهایی برای کنترل یک حل واحد که مختص مدل ورودی هستند (برای پارامترهای مستقل مدل به SolveParametersProto مراجعه کنید). |
SolveMathOptModelResponse
پاسخ برای حل یکپارچه از راه دور در MathOpt.
| زمینه های | |
|---|---|
result | شرح خروجی حل مدل در درخواست. |
messages[] | اگر SolveParametersProto.enable_output استفاده شده باشد، این شامل پیامهای گزارش برای حلکنندههایی است که از تماسهای پیام پشتیبانی میکنند. |
SolveShiftGenerationRequest
درخواست برای حل مشکل Shift Generation. قوانین برای ایجاد شیفت در هر ShiftTemplate مشخص شده است. چندین تغییر در پاسخ را می توان از یک ShiftTemplate ایجاد کرد. شیفت های تولید و انتخاب شده توسط حل کننده باید به قوانین مشخص شده در ShiftTemplate پایبند باشند و تقاضای مشخص شده کارمندان را پوشش دهند.
| زمینه های | |
|---|---|
solver_config | اختیاری. پارامترهای حل کننده |
shift_templates[] | ضروری. مجموعه ای از الگوهای شیفت که قوانینی را برای ایجاد شیفت ها مشخص می کند. |
employee_demands[] | ضروری. کل تقاضای کارکنان که شیفت های ایجاد شده توسط |
SolveShiftGenerationResponse
پاسخ به مشکل Shift Generation. اگر solution_status بازگشتی SOLVED باشد، مجموعهای از شیفتهای معتبر ایجاد شده توسط حلکننده در employee_schedules برگردانده میشوند. برای یک برنامه شیفت معتبر، ویژگی های زیر برقرار است:
- هر شیفتی که در
employee_schedulesایجاد میشود، به قوانین مشخصشده درShiftTemplateمربوطه پایبند است. - هر رویداد انتخاب شده در هر شیفت به قوانین مشخص شده در
ShiftTemplate.Eventمربوطه پایبند است. - تعداد کل کارکنان اختصاص داده شده به مجموعه شیفت های ایجاد شده از همان ShiftTemplate از
maximum_employee_countآن الگو تجاوز نمی کند. - مجموعه کارکنان تعیین شده در هر بازه زمانی معین تقاضا را پوشش می دهند.
| زمینه های | |
|---|---|
solution_status | وضعیت راه حل برگشتی اگر |
employee_schedules[] | مجموعه ای از شیفت های ایجاد شده توسط حل کننده همراه با تعداد کارمندان اختصاص داده شده به هر برنامه. |
demand_coverage_violations[] | نقض پوشش تقاضا بر اساس |
SolveShiftSchedulingRequest
درخواست برای API برنامه ریزی نیروی کار. حداقل، این درخواست مجموعه ای از کارکنان، مجموعه ای از شیفت ها، مجموعه ای از نقش های احتمالی که یک کارمند می تواند انجام دهد و مجموعه ای از الزامات پوشش را مشخص می کند. الزامات پوشش، در یک بازه زمانی، تعداد کارکنان مورد نیاز برای انجام هر نقش را مشخص می کند. کارمندانی که به یک شیفت منصوب میشوند نیز به یک (و تنها یک) نقش برای آن شیفت اختصاص داده میشوند و کارمندان را نمیتوان به دو شیفت همپوشانی منصوب کرد. برای جزئیات بیشتر در مورد اینکه چه چیزی یک انتساب شیفت را معتبر می کند، به SolveShiftSchedulingResponse زیر مراجعه کنید.
محدودیت های زمان بندی اضافی را می توان برای هر کارمند مشخص کرد تا مشکل را بیشتر محدود کند. تمام محدودیتهای زمانبندی و الزامات پوشش دارای یک سطح اولویت (اجباری، بالا، متوسط، پایین) هستند. همه محدودیتها با سطح اولویت PRIORITY_MANDATORY باید توسط حلکننده برآورده شوند. قیود با هر اولویت دیگری می تواند توسط حل کننده نقض شود، اما این تخلفات به ترتیب اولویت به حداقل می رسد. برای جزئیات بیشتر در مورد نحوه مدیریت سطوح اولویت برای هر محدودیت، به شماره Priority مراجعه کنید.
حل کننده سعی می کند مقادیر ShiftPreference.preference را برای هر کارمند بیش از محدودیت های داده شده به حداکثر برساند. حل کننده یک محدودیت را برای ارضای ترجیحات بیشتر نقض نمی کند. تنها زمانی یک محدودیت را نقض میکند که تخصیص زمانبندی تحت محدودیتهای داده شده غیرممکن باشد.
نکته در مورد زمان: تمام زمان های مشکل با استفاده از پیام DateTime مشخص می شود. این پیام شامل یک قسمت TimeZone است. منطقه زمانی UTC در نظر گرفته میشود مگر اینکه کاربر طور دیگری مشخص کرده باشد. پیامهای DateTime فقط باید تا دقیقه مشخص شوند. تمام ثانیه ها و نانوها نادیده گرفته می شوند.
| زمینه های | |
|---|---|
request_id | مشکل یا شناسه درخواست. |
solve_parameters | پارامترهایی برای کنترل یک حل مشکل. |
employees[] | همه کارکنان موجود باید برنامه ریزی شوند. |
shifts[] | همه شیفت ها برای تشکیل برنامه. |
coverage_requirements[] | الزامات پوشش برای کل افق برنامه ریزی. اینها تعداد کارمندانی را که باید هر نقش را انجام دهند یا مهارتی را در طول یک پنجره زمانی یا لیستی از شناسه های شیفت داشته باشند مشخص می کند. همه الزامات پوشش باید با پنجره های زمانی یا لیستی از شناسه های شیفت (اما نه هر دو) مشخص شوند. پنجره های زمانی (در صورت داده شدن) برای الزامات پوشش نمی توانند برای هر مکان معین همپوشانی داشته باشند. سطح اولویت پیشفرض برای هر یک از این محدودیتها |
role_ids[] | فهرست تمام نقش های ممکن در سراسر نیروی کار. هر کارمند باید حداقل یک نقش را داشته باشد که بتوان آن را برای یک شیفت به او اختصاص داد. نقش به یک تکلیف شغلی خاص در طول یک شیفت (به عنوان مثال پرستار ثبت نام شده، سرآشپز اجرایی، پیشخدمت و غیره) اشاره دارد. هنگامی که یک کارمند به یک شیفت منصوب می شود، به یک نقش خاص نیز منصوب می شود. |
skill_ids[] | فهرستی از تمام مهارت های ممکن در سراسر نیروی کار. مهارت به هر نوع صلاحیت اضافی که یک کارمند ممکن است داشته باشد اشاره دارد که به شغل قابل واگذاری خاصی مربوط نمی شود (مثلاً گواهینامه ها، زبان های صحبت شده و غیره). این لیست می تواند خالی باشد. وقتی یک کارمند به یک شیفت منصوب می شود، باید تمام مهارت های مورد نیاز برای آن شیفت را برآورده کند. |
location_ids[] | فهرست تمام مکانهای ممکن برای مجموعه شیفتها در برنامه. این لیست می تواند خالی باشد. تعیین مکانهای مختلف زمانی میتواند مفید باشد، برای مثال، یک مدیر پرستار میخواهد پرستاران زیادی را در واحدهای مختلف در یک بیمارستان برنامهریزی کند یا برای مثال، یک مدیر هتل میخواهد کارمندان را در چندین هتل برنامهریزی کند. |
budget_requirements[] | مشخصات بودجه برای مشکل زمان بندی. سطح اولویت پیشفرض برای هر یک از این الزامات |
assignments_hint[] | تکالیف را تغییر دهید تا به عنوان یک راه حل آزمایشی (با نام مستعار راه حل اشاره) به مسئله زمان بندی استفاده کنید. اگر تخصیص با یک جابجایی غیرقابل تخصیص یا یک درخواست زمانبندی مغایرت داشته باشد، نکات تخصیص نادیده گرفته میشوند. |
SolveShiftSchedulingResponse
پاسخ به API برنامه ریزی نیروی کار. برای هر پاسخ، shift_assignments خالی خواهند بود اگر solution_status بازگشتی NOT_SOLVED_DEADLINE_EXCEEDED یا INFEASIBLE باشد. اگر solution_status بازگشتی OPTIMAL یا FEASIBLE باشد، یک انتساب شیفت معتبر در shift_assignments برگردانده می شود. برای یک انتساب شیفت معتبر، ویژگی های زیر برقرار است:
- شناسه هر کارمند در مجموعه کارمندانی که در درخواست ارائه شده است موجود است.
- هر شناسه نقشی که به کارمند اختصاص داده میشود، در مجموعه شناسههای نقش برای کارمند مشخص میشود.
- شناسه هر شیفت در مجموعه شیفت های ارائه شده در درخواست موجود است.
- هر شناسه شیفت یکی از شناسه های شیفت غیرقابل تخصیص برای کارمند معین نیست.
- یک کارمند هرگز به دو شیفت کاری منصوب نمی شود.
- برای زمان بندی داده شده، هیچ یک از محدودیت ها یا درخواست های دارای اولویت
PRIORITY_MANDATORYنقض نمی شود.
| زمینه های | |
|---|---|
request_id | شناسه درخواستی که این پاسخ با آن مرتبط است. |
solution_status | وضعیت راه حل برگشتی اگر راه حل امکان پذیر یا بهینه نباشد، سایر فیلدهای این پروتو ممکن است خالی باشند. اگر وضعیت NOT_SOLVED_DEADLINE_EXCEEDED باشد، محدودیت زمانی بدون یافتن راهحل امکانپذیر یا تعیین وجود راهحل امکانپذیر به پایان رسیده است. اگر محدودیتهای سطح اولویت اجباری نتوانند همه برآورده شوند، ممکن است درخواستها غیرممکن باشد. |
shift_assignments[] | لیست تمام تکالیف هر |
status_message | اگر |