इंडेक्स
Optimization(इंटरफ़ेस)DesignShippingNetworkRequest(मैसेज)DesignShippingNetworkResponse(मैसेज)SolveMathOptModelRequest(मैसेज)SolveMathOptModelResponse(मैसेज)SolveShiftGenerationRequest(मैसेज)SolveShiftGenerationResponse(मैसेज)SolveShiftSchedulingRequest(मैसेज)SolveShiftSchedulingResponse(मैसेज)
ऑप्टिमाइज़ेशन
One Platform API की मदद से, ऑपरेशन से जुड़ी रिसर्च से जुड़ी हाई-लेवल समस्याओं के लिए ऑप्टिमाइज़ेशन सॉल्वर का एक सेट दिखाया जाता है. MOE:begin_strip
| DesignShippingNetwork |
|---|
|
दिए गए LSNDSP, ऑप्टिमाइज़ेशन की एक जटिल समस्या है. इसका मकसद, लाइनर के शिपिंग नेटवर्क के लिए सबसे सही डिज़ाइन और शेड्यूल तय करना है. इसका मकसद नेटवर्क के काम करने में आने वाली कुल लागत को कम करना है, साथ ही पोर्ट के बीच कार्गो की ज़्यादा से ज़्यादा मांग को पूरा करना है. LSNDSP को दो मुख्य उप-समस्याओं में बांटा जा सकता है: नेटवर्क डिज़ाइन और शेड्यूलिंग. नेटवर्क डिज़ाइन सब-प्रॉब्लम, नेटवर्क के लिए आने वाले पोर्ट के सेट, हर रूट पर डिप्लॉय किए जाने वाले जहाज़ों की संख्या, और वे रूट तय करता है जिन पर जहाज़ों का इस्तेमाल करना है. शेड्यूलिंग सबप्रोसेस में, जहाज़ों के लिए सेलिंग शेड्यूल तय किया जाता है. इसके लिए, पोर्ट के बीच से शिप करने में लगने वाला समय, कार्गो को लोड और अनलोड करने में लगने वाला समय, और पोर्ट के बीच कार्गो ट्रांसपोर्टेशन की मांग को ध्यान में रखा जाता है. आसान शब्दों में कहें, तो एलएसएनडीएसपी यह तय करने की समस्या है कि किन पोर्ट को सेवा देनी है, कितने जहाज़ों का इस्तेमाल करना है, और जहाज़ों को शेड्यूल कैसे करना है, ताकि कार्गो की मांग को पूरा करने के लिए ज़्यादा से ज़्यादा रेवेन्यू जनरेट किया जा सके और नेटवर्क चलाने में आने वाला खर्च भी कम हो. एलएसएनडीएसपी का एक चुनौती भरा सबकॉम्पोनेंट कार्गो रूटिंग है. इससे तय होता है कि रेवेन्यू बढ़ाने के लिए, कौनसी मांग पूरी करनी होंगी और कार्गो को कौनसे रूट असाइन करने होंगे. |
| SolveMathOptModel |
|---|
|
इनपुट मॉडल को हल करता है और तुरंत नतीजा देता है. इसका इस्तेमाल तब करें, जब आपको कॉलबैक, बढ़ोतरी की ज़रूरत न हो, और समाधान की प्रोग्रेस को ट्रैक करने की ज़रूरत न हो. |
| SolveShiftGeneration |
|---|
|
यह कर्मचारी की मांग को पूरा करने के लिए, दिए गए शिफ़्ट टेंप्लेट से शिफ़्ट जनरेट करके, दिए गए |
| SolveShiftScheduling |
|---|
|
कर्मचारियों को शिफ़्ट में असाइन करके, दिए गए |
DesignShippingNetworkRequest
इस अनुरोध में एलएसएनडीएसपी का एक सेट शामिल होता है. इसमें पोर्ट का एक सेट, लेग कैंडिडेट का एक सेट, जहाज़ों की क्लास का एक सेट, और पूरा करने के लिए कमॉडिटी से जुड़ी ज़रूरतें शामिल होनी चाहिए.
| फ़ील्ड | |
|---|---|
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, वैट_services पर निर्भर करते हैं (CommodityDemandPath की परिभाषा देखें). |
SolveMathOptModelRequest
MathOpt में, एक रिमोट समाधान के लिए अनुरोध करें.
| फ़ील्ड | |
|---|---|
solver_type |
ज़रूरी नहीं. सवाल को अंकों में हल करने के लिए, सॉल्वर का टाइप. ध्यान दें कि अगर कोई सॉल्वर, मॉडल में किसी खास सुविधा के साथ काम नहीं करता है, तो ऑप्टिमाइज़ेशन प्रोसेस सफल नहीं होगी. |
model |
ज़रूरी है. इस उदाहरण में, उस ऑप्टिमाइज़ेशन सवाल को गणित के हिसाब से दिखाया गया है जिसे हल करना है. |
parameters |
ज़रूरी नहीं. सिंगल सॉल्वर को कंट्रोल करने के लिए पैरामीटर. सक्षम_आउटपुट पैरामीटर को खास तौर पर हैंडल किया जाता है. मैसेज कॉलबैक के साथ काम करने वाले सॉल्वर के लिए, इसे 'सही' पर सेट करने के लिए सर्वर, मैसेज कॉलबैक को रजिस्टर करेगा. नतीजे के तौर पर मिलने वाले मैसेज के लिए, SummaryMathOptModelResponse.messages दिखाए जाएंगे. अन्य सॉल्वर के लिए, enabled_ तस्वीरें को 'सही है' पर सेट करने से गड़बड़ी हो सकती है. |
model_parameters |
ज़रूरी नहीं. इनपुट मॉडल के लिए खास एक सॉल्वर को कंट्रोल करने के लिए पैरामीटर. (मॉडल इंडिपेंडेंट पैरामीटर के लिए हल पैरामीटर प्रोटो देखें). |
SolveMathOptModelResponse
MathOpt में, सिंगल रिमोट तरीके से समाधान करने का रिस्पॉन्स दिया जाता है.
| फ़ील्ड | |
|---|---|
result |
अनुरोध में मॉडल को हल करने के नतीजे के बारे में जानकारी. |
messages[] |
अगर हल पैरामीटर का इस्तेमाल किया जा रहा है, तो इसमें सॉल्वर के उन लॉग मैसेज शामिल होंगे जो मैसेज कॉलबैक के साथ काम करते हैं. |
SolveShiftGenerationRequest
शिफ़्ट जेनरेशन की समस्या को हल करने के लिए अनुरोध. शिफ़्ट जनरेट करने के नियम हर ShiftTemplate में बताए गए हैं. रिस्पॉन्स में कई शिफ़्ट एक ही ShiftTemplate से जनरेट किए जा सकते हैं. सॉल्वर के जनरेट किए गए और चुने गए शिफ़्ट, ShiftTemplate में बताए गए नियमों के मुताबिक होने चाहिए. साथ ही, ये बदलाव कर्मचारियों की बताई गई मांग के हिसाब से होने चाहिए.
| फ़ील्ड | |
|---|---|
solver_config |
ज़रूरी नहीं. सॉल्वर के लिए पैरामीटर. |
shift_templates[] |
ज़रूरी है. शिफ़्ट जनरेट करने के नियम तय करने वाले शिफ़्ट टेंप्लेट का सेट. |
employee_demands[] |
ज़रूरी है. कर्मचारियों की कुल मांग, जिसमें |
SolveShiftGenerationResponse
शिफ़्ट जेनरेशन समस्या का उत्तर. अगर solution_status फ़ंक्शन SOLVED है, तो सॉल्वर से जनरेट किए गए मान्य शिफ़्ट, employee_schedules में दिखते हैं. शिफ़्ट के मान्य शेड्यूल के लिए, इन प्रॉपर्टी में बदलाव किया जा सकता है:
employee_schedulesमें जनरेट किया गया हर शिफ़्ट,ShiftTemplateमें बताए गए नियमों का पालन करता है.- हर शिफ़्ट में चुना गया हर इवेंट, उससे जुड़े
ShiftTemplate.Eventमें बताए गए नियमों का पालन करता है. - उसी ShiftTemplate से जनरेट किए गए शिफ़्ट के सेट के लिए असाइन किए गए कर्मचारियों की कुल संख्या उस टेंप्लेट के
maximum_employee_countसे ज़्यादा नहीं है. - असाइन किए गए कर्मचारियों का सेट हर दिए गए समय में मांग को पूरा करता है.
| फ़ील्ड | |
|---|---|
solution_status |
लौटाए गए समाधान की स्थिति. अगर |
employee_schedules[] |
सॉल्वर के जनरेट किए गए शिफ़्ट का सेट. इसमें हर शेड्यूल में असाइन किए गए कर्मचारियों की संख्या भी शामिल है. |
demand_coverage_violations[] |
दिए गए |
SolveShiftSchedulingRequest
वर्कफ़ोर्स शेड्यूलिंग एपीआई के लिए अनुरोध. कम से कम, अनुरोध में कर्मचारियों के सेट, शिफ़्ट के सेट, कर्मचारी की संभावित भूमिकाओं का एक सेट, और कवरेज से जुड़ी ज़रूरी शर्तों के बारे में बताया जाता है. कवरेज से जुड़ी ज़रूरी शर्तों में यह बताया जाता है कि किसी समयावधि में हर भूमिका को पूरा करने के लिए कितने कर्मचारियों की ज़रूरत होगी. किसी शिफ़्ट के लिए असाइन किए गए कर्मचारियों को भी उस शिफ़्ट के लिए एक (और केवल एक) भूमिका असाइन की जाती है और कर्मचारियों को दो ओवरलैप करने वाली शिफ़्ट में असाइन नहीं किया जा सकता है. शिफ़्ट असाइनमेंट को मान्य बनाने के बारे में ज़्यादा जानकारी के लिए, नीचे दिया गया SolveShiftSchedulingResponse देखें.
समस्या को और कम करने के लिए प्रत्येक कर्मचारी के लिए अतिरिक्त शेड्यूलिंग सीमाएं तय की जा सकती हैं. शेड्यूल करने से जुड़ी सभी पाबंदियों और कवरेज की ज़रूरी शर्तों को प्राथमिकता लेवल दिया जाता है. जैसे, MANDATORY, HIGH, MEDIUM, LOW. प्राथमिकता लेवल PRIORITY_MANDATORY वाले सभी कंस्ट्रेंट को सॉल्वर से पूरा करना होगा. किसी अन्य प्राथमिकता वाली पाबंदियों का उल्लंघन सॉल्वर कर सकता है, लेकिन प्राथमिकता के क्रम में इन उल्लंघनों को कम कर दिया जाता है. हर कंस्ट्रेंट के प्राथमिकता लेवल को कैसे हैंडल किया जाता है, इस बारे में ज़्यादा जानकारी के लिए Priority एनम देखें.
सॉल्वर, दिए गए कंस्ट्रेंट के लिए, हर कर्मचारी के लिए ShiftPreference.preference वैल्यू को बढ़ाने की कोशिश करेगा. सॉल्वर ज़्यादा प्राथमिकताओं को पूरा करने के लिए कंस्ट्रेंट का उल्लंघन नहीं करेगा. यह कंस्ट्रेंट का उल्लंघन सिर्फ़ तब करेगा, जब दिए गए कंस्ट्रेंट के तहत शेड्यूलिंग असाइनमेंट मुश्किल हो.
समय के बारे में नोट: समस्या में मौजूद सभी समय की जानकारी DateTime मैसेज का इस्तेमाल करके दी जाती है. इस मैसेज में टाइमज़ोन फ़ील्ड शामिल है. टाइमज़ोन को यूटीसी माना जाता है, जब तक कि उपयोगकर्ता इसके बारे में कुछ और न बताएं. तारीख समय के मैसेज सिर्फ़ मिनट तक के होने चाहिए; सभी सेकंड और नैनो को अनदेखा किया जाता है.
| फ़ील्ड | |
|---|---|
request_id |
कोई समस्या है या आईडी के लिए अनुरोध करें. |
solve_parameters |
सवाल के किसी एक हल को कंट्रोल करने के लिए पैरामीटर. |
employees[] |
सभी उपलब्ध कर्मचारियों का शेड्यूल सेट किया जाएगा. |
shifts[] |
शेड्यूल बनाने के लिए सभी शिफ़्ट. |
coverage_requirements[] |
हर प्लान के लिए कवरेज से जुड़ी ज़रूरी शर्तें. इससे उन कर्मचारियों की संख्या का पता चलता है जो एक समयावधि या शिफ़्ट आईडी की सूची के दौरान हर भूमिका को पूरा करते हैं या जिनके पास कोई कौशल होता है. कवरेज से जुड़ी सभी ज़रूरी शर्तों के बारे में टाइम विंडो या शिफ़्ट आईडी की सूची के साथ बताया जाना चाहिए. हालांकि, दोनों को नहीं. कवरेज की ज़रूरी शर्तों के लिए तय की गई टाइम विंडो (अगर दी गई हों), हर जगह के लिए ओवरलैप नहीं हो सकतीं. इनमें से हर एक के लिए प्राथमिकता का डिफ़ॉल्ट लेवल, भूमिका से जुड़ी ज़रूरी शर्तों के लिए |
role_ids[] |
कर्मचारी की सभी संभावित भूमिकाओं की सूची. हर कर्मचारी के पास कम से कम एक ऐसी भूमिका होनी चाहिए जो उसे शिफ़्ट में असाइन की जा सके. भूमिका का मतलब है, शिफ़्ट के दौरान दिए गए किसी काम को असाइन करना. जैसे, रजिस्टर की गई नर्स, एक्ज़ीक्यूटिव शेफ़, वेटर वगैरह. जब किसी कर्मचारी को शिफ़्ट में असाइन किया जाता है, तो उसे भी एक खास भूमिका असाइन की जाती है. |
skill_ids[] |
कर्मचारी के लिए सभी संभावित स्किल की सूची. स्किल का मतलब है, किसी कर्मचारी की ऐसी अतिरिक्त योग्यता जो किसी असाइन की जाने वाली नौकरी से जुड़ी नहीं है. जैसे, सर्टिफ़िकेट, भाषाएं वगैरह. यह सूची खाली हो सकती है. जब किसी कर्मचारी को शिफ़्ट के लिए असाइन किया जाता है, तो उसे उस शिफ़्ट के लिए ज़रूरी सभी कौशल पूरे करने होते हैं. |
location_ids[] |
शेड्यूल में शिफ़्ट के सेट के लिए सभी संभावित जगहों की सूची. यह सूची खाली हो सकती है. अलग-अलग जगहों की जानकारी देना तब फ़ायदेमंद हो सकता है, जब कोई नर्स मैनेजर अलग-अलग यूनिट में कई नर्सों को अस्पताल में शेड्यूल करना चाहता हो या दूसरे उदाहरण के लिए, कोई होटल मैनेजर एक से ज़्यादा होटलों में कर्मचारियों के काम शेड्यूल करना चाहता हो. |
budget_requirements[] |
शेड्यूल करने से जुड़ी समस्या के लिए बजट की जानकारी. इन ज़रूरी शर्तों में से हर एक के लिए, प्राथमिकता का डिफ़ॉल्ट लेवल |
assignments_hint[] |
असाइनमेंट को शेड्यूल करने से जुड़ी समस्या के समाधान (यानी समाधान संकेत) के तौर पर इस्तेमाल करने के लिए शिफ़्ट करें. अगर कोई असाइनमेंट, असाइन न किए जा सकने वाले शिफ़्ट या शेड्यूल करने के अनुरोध से मेल नहीं खाता है, तो असाइनमेंट के संकेतों को अनदेखा कर दिया जाता है. |
SolveShiftSchedulingResponse
Workforce शेड्यूलिंग API के लिए रिस्पॉन्स. अगर solution_status, NOT_SOLVED_DEADLINE_EXCEEDED या INFEASIBLE है, तो हर जवाब के लिए shift_assignments खाली होगा. अगर solution_status, OPTIMAL या FEASIBLE दिखाता है, तो shift_assignments में शिफ़्ट का मान्य असाइनमेंट मिलता है. मान्य शिफ़्ट असाइनमेंट के लिए, इन प्रॉपर्टी में ये शामिल हैं:
- हर कर्मचारी आईडी, अनुरोध में दिए गए कर्मचारियों के सेट में होता है.
- कर्मचारी को असाइन किया गया हर भूमिका आईडी, दिए गए कर्मचारी के लिए भूमिका आईडी के सेट में शामिल होता है.
- हर शिफ़्ट आईडी, अनुरोध में दिए गए शिफ़्ट के सेट में शामिल होता है.
- दिए गए कर्मचारी के लिए, हर शिफ़्ट आईडी, असाइन नहीं किए जा सकने वाले शिफ़्ट आईडी में से एक नहीं है.
- किसी कर्मचारी को कभी भी दो ओवरलैपिंग शिफ़्ट में असाइन नहीं किया जाएगा.
- दिए गए शेड्यूल के लिए, प्राथमिकता लेवल
PRIORITY_MANDATORYवाले किसी भी कंस्ट्रेंट या अनुरोध का उल्लंघन नहीं हुआ है.
| फ़ील्ड | |
|---|---|
request_id |
अनुरोध का वह आईडी जिससे यह जवाब जुड़ा है. |
solution_status |
लौटाए गए समाधान की स्थिति. अगर समाधान सुविधाजनक या ऑप्टिमाइज़ नहीं होता है, तो इस प्रोटो में अन्य फ़ील्ड खाली हो सकते हैं. अगर स्टेटस NOT_SOLVED_DEADLINE_EXCEEDED है, तो कोई कारगर समाधान नहीं मिला या यह तय नहीं किया गया कि समाधान का कोई कारगर तरीका है या नहीं. ऐसा होने पर, समयसीमा खत्म हो गई. अगर प्राथमिकता लेवल 'ज़रूरी' की सभी पाबंदियों को पूरा नहीं किया जा सकता, तो हो सकता है कि अनुरोध काम न करें. |
shift_assignments[] |
सभी असाइनमेंट की सूची. हर |
status_message |
अगर |