Рабочая ситуация
Сеть пунктов выдачи расходует упаковочные материалы, пополнение идёт с задержкой, а сведения об остатках поступают не сразу. Простое правило «заказывать, когда мало» приводит то к дефициту, то к переполнению складов.
Студент строит модель движения запаса во времени, уточняет ограничения у ИИ-операционного менеджера и настраивает правило управления по наблюдаемому запасу с учётом поставок в пути. Затем сценарий вводит скачок спроса и задержку сведений: нужно проверить дефицит, излишки, стоимость и колебания на заданных сценариях и пересмотреть управление.
Рабочее место
- Блок-схемы и симуляция по логике Scilab Xcosмодель, параметры, графики динамики.
- Сценарии возмущенийвоспроизводимые наборы спроса, задержек и сбоев данных.
- Рабочий мессенджеруточнение ограничений, стоимости хранения и допустимого уровня сервиса.
В модели обязательно присутствуют изменение состояния во времени, наблюдение, задержки и управляющее воздействие.
Как проходит работа
- Описать систему: пункты, потоки, задержки поставки и наблюдения.
- Построить модель и проверить её на базовом сценарии.
- Настроить правило управления и критерии: дефицит, излишки, стоимость, колебания.
- Прогнать скачок спроса и задержку сведений; зафиксировать поведение.
- Пересмотреть управление и описать границы применимости результата.
ИИ-команда
- Операционный менеджерзадаёт уровень сервиса, допустимый дефицит и правила работы пунктов.
- Руководитель логистикизнает реальные сроки поставок, партии и ограничения перевозки.
- Инженер по даннымобъясняет, как и с какой задержкой поступают сведения об остатках.
Что проверяется
| Итоговый артефакт | Автоматическая проверка в заданных границах | Оценка преподавателя |
|---|---|---|
| Динамическая модель, правило управления и протокол экспериментов | Численный расчёт с воспроизводимыми возмущениями: дефицит, переполнение, стоимость и колебания | Пригодность модели, выбор обратной связи и границы применимости результата |
Связанные дисциплины
Тренажёр подходит для дисциплин по моделированию систем и теории управления; расширенный кейс может использоваться в курсах о цифровых экосистемах производства.
Общая механика серии
- Рабочая ситуациясинтетические документы, данные, сроки и противоречия образуют конкретную задачу, а не свободную беседу.
- Ролевой мессенджерзаказчик, оператор, разработчик или эксплуатация располагают только сведениями своей роли; допустимые факты сценария заданы заранее.
- Первый результатстудент создаёт спецификацию, схему, код, модель или прототип, который можно сохранить и проверить.
- Изменение условийсценарный движок вводит новую версию контракта, ограничение, возмущение или новые данные; ИИ не придумывает эти события самостоятельно.
- Пересмотрстудент обновляет решение, повторяет проверки и объясняет, почему изменил или сохранил первоначальный подход.
- Безопасное исполнениепользовательский код и SQL запускаются только в изолированной среде; реальные секреты, персональные данные и производственные системы не нужны.
Ролевые ИИ-персонажи не получают скрытый ключ проверки и не выставляют итоговые баллы: вычисляемую часть результата проверяет программное ядро, открытое инженерное решение оценивает преподаватель по заранее известной рубрике.
Статус описания: Проектируется. На странице описан проектируемый тренажёр — целевой учебный сценарий, а не готовое приложение. Состав воспроизводимых сред, механика и критерии проверки согласуются с вузом; реализация и приёмка выполняются отдельно.
Названия и логотипы сторонних платформ обозначают учебные профили интерфейсов и операций и не означают поставку оригинальных продуктов, интеграцию с ними, партнёрство или одобрение правообладателей. Упоминание программ Топ-ИТ и «Приоритет-2030» обозначает область применения тренажёра, а не официальное включение в эти программы.
