Web documentation v0.1#99
Conversation
| * **SS (Start–Start)**: `S(B) ≥ S(A) + лаг`. | ||
| * **FF (Finish–Finish)**: `F(B) ≥ F(A) + лаг`. | ||
| * **IFS (Inseparable Finish–Start)**: неразрывная FS — B сразу после A без разрывов; узлы образуют слитную цепочку. | ||
| * **FFS (LagFinishStart)**: поточная связь; потомок стартует после выполнения предком части объёма, равной лагу. |
|
|
||
| * **Лаг** — сдвиг ограничения: | ||
|
|
||
| * Для FS/SS/FF — числовой сдвиг во времени (обычно `0`). Знак: `>0` — задержка, `<0` — «лид». |
| * **Лаг** — сдвиг ограничения: | ||
|
|
||
| * Для FS/SS/FF — числовой сдвиг во времени (обычно `0`). Знак: `>0` — задержка, `<0` — «лид». | ||
| * Для FFS — лаг в единицах объёма предка (например, км). Движок делит работу на стадии; старт потомка — после стадии |
There was a problem hiding this comment.
В данном случае должен быть приведён пример, так как понятие лага для планировщика - часть понятия связи.
Лаг - это "длина связи". В случае с FS лаг - минимальная временная задержка между финишем родителя и стартом потомка. Например, если мы имеем родителя с финишем x, то ограничение на минимальное время старта потомка, накладываемое данной FS связью, будет равно x + lag.
В FFS написано вроде бы нормально... но только если знаешь, о чем говоришь. Тут нужна картинка и детальное пояснение того, какой физический (в реальном проекте) смысл данной связи и как работает реструктуризация FFS.
|
|
||
| > «Что за задача и что ей нужно». | ||
|
|
||
| * **WorkerReq** — требование к ресурсу: `kind`, `min_count`, `max_count`, `volume` (норма для расчёта длительности). |
| * **Сложные ограничения и ресурсы** | ||
| — учёт предшествования и альтернативных маршрутов, параллельных/альтернативных ресурсов, сменных календарей, | ||
| навыков/квалификаций (skills), окон доступности, ограничений мощностей, переналадок/переконфигураций и логистических | ||
| задержек. |
There was a problem hiding this comment.
Это вообще... без комментариев
| — пересчёт расписания при изменении входных данных (WorkGraph, ресурсы Contractor, дедлайны, веса критериев) за счёт | ||
| модульного SchedulingPipeline (пайплайн построен из независимых, заменяемых шагов) и настраиваемых оценщиков | ||
| времени/ресурсов. Поддерживается автоматическое перепланирование «на лету» при задержках, сбоях, изменении ресурсов, | ||
| приоритетов или поступлении новых работ. |
| — устойчив к крупным графам (порядка **2 000–10 000** работ) при поиске качественных решений. | ||
|
|
||
| * **Адаптация под домен** | ||
| — возможность подключать свои парсеры, модели оценки времени/ресурсов, критерии качества и политики диспетчеризации. |
There was a problem hiding this comment.
Свои парсеры подключать нельзя. Строго говоря, у нас всего три парсера - для графа, для подрядчиков и для истории планирования. И у них фиксированный формат.
| - *HEFT/HEFTBetween* — жадные эвристики *Heterogeneous Earliest Finish Time*, минимизирующие время завершения. | ||
|
|
||
| > HEFT/HEFTBetween — метод планирования, который идёт по задачам и назначает каждую туда, где она закончится | ||
| быстрее всего, учитывая зависимости и разную скорость ресурсов. |
There was a problem hiding this comment.
Продублировано описание HEFT/HEFTBetween
| .finish()[0]) | ||
|
|
||
| print(f"Project duration: {project.schedule.execution_time}") | ||
| ``` |
There was a problem hiding this comment.
Очень жаль, но этот пример не заработает. В графе 6 типов ресурсов, а у подрядчика - всего один.
# Conflicts: # docs/source/guidebook/contractors.md
2 participants
No description provided.