Как упростить синтез модели?
Продолжаю рассказывать про структуру имитационного комплекса для моделирования работы ж.-д. инфраструктуры.
Операция в нашем имитационном комплексе задается 16-ю параметрами без учета подключения законов распределений случайных величин.
Если мы захотим описать процесс формирования поездов потребуется n-ное количество операций, где для каждой нужно задать параметр.
Что мы хотим? Создать модель побыстрее и не потерять детали.
Что делать? Использовать шаблон на формирование!
В библиотеках «нетиповых операций» есть шаблоны на «Формирование», состоящие всего из 4 параметров:
- Имя;
- Используемые локомотивы;
- Продолжительность выполнения;
- Вытяжной путь.
Задав эти параметры в процессе моделирования автоматически синтезируется цепочка операций. В результате накопленные вагоны через заданное время оказываются на вытяжном пути.
Как же тогда задаются используемые ресурсы инфраструктуры?
Технологической цепочкой и алгоритмами.
В технологической цепочке перед операцией «формирование» алгоритм найдет среди всех ближайших предков (операции, которые выполнятся раньше формирования) операции «накопления» (об этой операции расскажу в следующем посте). Из этих операций алгоритм вытаскивает значения параметров путей и вагонов. Затем он связывает их с параметрами самой операции «формирование»: продолжительность выполнения и вытяжной путь — для построения маршрутов.
Параметр локомотив в данном контексте не столь интересен, но можно отметить, что он дублирующий. В шаблоне он имеет ссылку для связи устройствами моделируемого объекта, при этом он должен быть в предках операции «формирование». Это нужно для исключения подключения другого алгоритма, связанного с автоматизацией подач и уборок локомотивов.
Таким образом, применение шаблонов и алгоритмов значительно упрощает процесс синтеза модели, позволяя сосредоточиться на ключевых аспектах моделирования.
#Про_ИК
Использовать шаблоны и алгоритмы.
Продолжаю рассказывать про структуру имитационного комплекса для моделирования работы ж.-д. инфраструктуры.
Операция в нашем имитационном комплексе задается 16-ю параметрами без учета подключения законов распределений случайных величин.
Если мы захотим описать процесс формирования поездов потребуется n-ное количество операций, где для каждой нужно задать параметр.
Что мы хотим? Создать модель побыстрее и не потерять детали.
Что делать? Использовать шаблон на формирование!
В библиотеках «нетиповых операций» есть шаблоны на «Формирование», состоящие всего из 4 параметров:
- Имя;
- Используемые локомотивы;
- Продолжительность выполнения;
- Вытяжной путь.
Задав эти параметры в процессе моделирования автоматически синтезируется цепочка операций. В результате накопленные вагоны через заданное время оказываются на вытяжном пути.
Как же тогда задаются используемые ресурсы инфраструктуры?
Технологической цепочкой и алгоритмами.
В технологической цепочке перед операцией «формирование» алгоритм найдет среди всех ближайших предков (операции, которые выполнятся раньше формирования) операции «накопления» (об этой операции расскажу в следующем посте). Из этих операций алгоритм вытаскивает значения параметров путей и вагонов. Затем он связывает их с параметрами самой операции «формирование»: продолжительность выполнения и вытяжной путь — для построения маршрутов.
Параметр локомотив в данном контексте не столь интересен, но можно отметить, что он дублирующий. В шаблоне он имеет ссылку для связи устройствами моделируемого объекта, при этом он должен быть в предках операции «формирование». Это нужно для исключения подключения другого алгоритма, связанного с автоматизацией подач и уборок локомотивов.
Таким образом, применение шаблонов и алгоритмов значительно упрощает процесс синтеза модели, позволяя сосредоточиться на ключевых аспектах моделирования.
#Про_ИК
🔥5👍2✍1
Традиционные методы анализа бизнес-стратегий: ограничения и возможности
Предсказание будущего в бизнесе требует создания репрезентативной модели, что по своей сути является творческим процессом. Выбор подходящего инструмента напрямую зависит от сложности анализируемой задачи. Простой анализ может быть выполнен с минимальными затратами, однако сложные сценарии требуют более мощных методологий. Рассмотрим три традиционных подхода:
1️⃣ Качественный сценарный анализ:
Этот метод основан на описательном анализе, использующем нечисловые данные для понимания поведения сложных систем. Он описывает возможные сценарии развития событий, опираясь на экспертные оценки и качественные факторы. Математически его можно представить как:
S = f(E, Q, C)
где:
S - множество возможных сценариев;
f - функция, описывающая взаимосвязь между факторами;
E - экспертные оценки;
Q - качественные факторы;
C - контекстуальные данные.
Ограничения: качественный сценарный анализ не предоставляет количественных оценок инвестиций, временных горизонтов или уровней риска. Он полезен для генерации идей, но не подходит для принятия конкретных решений, особенно в условиях неопределенности.
2️⃣ Методы, основанные на данных (Data-driven methods):
Этот подход использует исторические данные для выявления корреляций и прогнозирования будущих тенденций. Включает корреляционный анализ, статистическое моделирование и машинное обучение. Самый простой пример — линейная регрессия:
Y = β₀ + β₁X + ε
где:
Y - прогнозируемая переменная (например, доход);
X - объясняющая переменная (например, инвестиции);
β₀ и β₁ - коэффициенты регрессии;
ε - случайная ошибка.
Ограничения: эти методы эффективно работают в стабильной среде. При фундаментальных изменениях на рынке (технологические прорывы, изменения в законодательстве) прогнозы, основанные на исторических данных, могут быть неточными.
3️⃣ Моделирование с использованием электронных таблиц (SPREADSHEET MODELING):
Электронные таблицы являются распространённым инструментом для моделирования бизнес-процессов. Однако их возможности ограничены при описании сложных систем с обратной связью, нелинейностью и временными задержками. Такие системы часто описываются дифференциальными уравнениями, которые не могут быть адекватно представлены в электронных таблицах.
Ограничения: простота электронных таблиц приводит к упрощению модели, что может привести к неточным прогнозам и неадекватной оценке стратегических рисков. Отсутствие возможности учитывать нелинейности и обратные связи существенно снижает качество прогнозирования.
Как имитационное моделирование может помочь создать эффективную бизнес-стратегию?
Ответ на поверхности:
Проигрывание множества сценариев и получение автоматизированной глубокой аналитики.
При этом имитационная модель:
Точнее(если исходные данные собраны нормально и алгоритмы верифицированы)
Проще(только в использовании, создание базовой имитационной модели - самый трудоемкий процесс)
Убедительнее(мультикам верят лучше, чем таблицам. Возможность воспроизводить и анимировать поведение системы с течением времени является одним из преимуществ моделирования)
В копилку убелительности: В имитационной модели вы можете измерить любое значение и отследить любую сущность, которая не находится ниже уровня абстракции. Измерения и статистический анализ могут быть добавлены в любое время. Можно учесть случайность и взаимозависимости, которые характеризуют реальный бизнес и проверить их визуально.
Предсказание будущего в бизнесе требует создания репрезентативной модели, что по своей сути является творческим процессом. Выбор подходящего инструмента напрямую зависит от сложности анализируемой задачи. Простой анализ может быть выполнен с минимальными затратами, однако сложные сценарии требуют более мощных методологий. Рассмотрим три традиционных подхода:
1️⃣ Качественный сценарный анализ:
Этот метод основан на описательном анализе, использующем нечисловые данные для понимания поведения сложных систем. Он описывает возможные сценарии развития событий, опираясь на экспертные оценки и качественные факторы. Математически его можно представить как:
S = f(E, Q, C)
где:
S - множество возможных сценариев;
f - функция, описывающая взаимосвязь между факторами;
E - экспертные оценки;
Q - качественные факторы;
C - контекстуальные данные.
Ограничения: качественный сценарный анализ не предоставляет количественных оценок инвестиций, временных горизонтов или уровней риска. Он полезен для генерации идей, но не подходит для принятия конкретных решений, особенно в условиях неопределенности.
2️⃣ Методы, основанные на данных (Data-driven methods):
Этот подход использует исторические данные для выявления корреляций и прогнозирования будущих тенденций. Включает корреляционный анализ, статистическое моделирование и машинное обучение. Самый простой пример — линейная регрессия:
Y = β₀ + β₁X + ε
где:
Y - прогнозируемая переменная (например, доход);
X - объясняющая переменная (например, инвестиции);
β₀ и β₁ - коэффициенты регрессии;
ε - случайная ошибка.
Ограничения: эти методы эффективно работают в стабильной среде. При фундаментальных изменениях на рынке (технологические прорывы, изменения в законодательстве) прогнозы, основанные на исторических данных, могут быть неточными.
3️⃣ Моделирование с использованием электронных таблиц (SPREADSHEET MODELING):
Электронные таблицы являются распространённым инструментом для моделирования бизнес-процессов. Однако их возможности ограничены при описании сложных систем с обратной связью, нелинейностью и временными задержками. Такие системы часто описываются дифференциальными уравнениями, которые не могут быть адекватно представлены в электронных таблицах.
Ограничения: простота электронных таблиц приводит к упрощению модели, что может привести к неточным прогнозам и неадекватной оценке стратегических рисков. Отсутствие возможности учитывать нелинейности и обратные связи существенно снижает качество прогнозирования.
Как имитационное моделирование может помочь создать эффективную бизнес-стратегию?
Ответ на поверхности:
Проигрывание множества сценариев и получение автоматизированной глубокой аналитики.
При этом имитационная модель:
Точнее
Проще
Убедительнее
В копилку убелительности: В имитационной модели вы можете измерить любое значение и отследить любую сущность, которая не находится ниже уровня абстракции. Измерения и статистический анализ могут быть добавлены в любое время. Можно учесть случайность и взаимозависимости, которые характеризуют реальный бизнес и проверить их визуально.
👍7⚡1🔥1
Избыточный парк вагонов
Новости по анализу избыточности парка вагонов, увеличения оборота вагона, снижения участковой скорости, непроизводительных простоев вагонов на сети ж/д видели?
Министерство транспорта тоже вносит свою лепту в урегулирование ситуации и подготовило интересный проект:
О внесении изменений в Перечень критериев технических и технологических возможностей осуществления перевозок, отсутствие которых является для перевозчика и владельца инфраструктуры железнодорожного транспорта общего пользования основанием отказа в согласовании запроса-уведомления на перевозку порожних грузовых вагонов, утвержденный приказом Министерства транспорта Российской Федерации от 7 июля 2015 г. № 214
Проект интересен тем, что в целях заявлено: обеспечение потребностей грузоотправителей в подвижном составе, рациональное использование инфраструктуры железнодорожного транспорта общего пользования, исключение непроизводительного накопления вагонов на станциях погрузки, регулирование избыточного парка вагонов на сети железных дорог.
Какие изменения?
Главное изменение – расширение списка вагонов, которые учитываются при определении максимального количества вагонов, предоставляемых владельцу. В исходном тексте перечислялись ситуации, когда дополнительные вагоны не учитываются в лимите. Правки добавляют ситуации, когда дополнительные вагоны учитываются, расширяя возможности владельца использовать имеющиеся вагоны.
Дополнения включают три новых типа вагонов:
1️⃣ Вагоны, проверенные при сдвоенных операциях: Это вагоны, которые уже находятся на станции отправления и прошли проверку на техническую пригодность к погрузке в рамках сдвоенных операций (погрузка-выгрузка). Их включают в расчет, чтобы избежать лишних проверок. Там же ссылка на статью 20 Устава ж.-д. транспорта.
2️⃣ Вагоны на путях необщего пользования: Это вагоны, временно хранящиеся на частных путях грузоотправителя. Если они технически и коммерчески пригодны, их также учитывают в лимите, поскольку они доступны для использования. Там же ссылка на статью 36 Устава.
3️⃣ Вагоны от просроченных заявок: Это вагоны, которые оставались на станции после истечения срока действия предыдущих заявок на перевозку. Если они технически и коммерчески пригодны, их тоже учитывают, поскольку они могут быть использованы для новой заявки.
Поможет ли это?
Ответ узнаем после марта 2025 года (планируемый срок вступления в силу).
Публичное обсуждение проекта продлится до 27.11.2024.
Ситуация патовая, но небезвыходная
Новости по анализу избыточности парка вагонов, увеличения оборота вагона, снижения участковой скорости, непроизводительных простоев вагонов на сети ж/д видели?
Министерство транспорта тоже вносит свою лепту в урегулирование ситуации и подготовило интересный проект:
Проект интересен тем, что в целях заявлено: обеспечение потребностей грузоотправителей в подвижном составе, рациональное использование инфраструктуры железнодорожного транспорта общего пользования, исключение непроизводительного накопления вагонов на станциях погрузки, регулирование избыточного парка вагонов на сети железных дорог.
Какие изменения?
Главное изменение – расширение списка вагонов, которые учитываются при определении максимального количества вагонов, предоставляемых владельцу. В исходном тексте перечислялись ситуации, когда дополнительные вагоны не учитываются в лимите. Правки добавляют ситуации, когда дополнительные вагоны учитываются, расширяя возможности владельца использовать имеющиеся вагоны.
Дополнения включают три новых типа вагонов:
1️⃣ Вагоны, проверенные при сдвоенных операциях: Это вагоны, которые уже находятся на станции отправления и прошли проверку на техническую пригодность к погрузке в рамках сдвоенных операций (погрузка-выгрузка). Их включают в расчет, чтобы избежать лишних проверок. Там же ссылка на статью 20 Устава ж.-д. транспорта.
2️⃣ Вагоны на путях необщего пользования: Это вагоны, временно хранящиеся на частных путях грузоотправителя. Если они технически и коммерчески пригодны, их также учитывают в лимите, поскольку они доступны для использования. Там же ссылка на статью 36 Устава.
3️⃣ Вагоны от просроченных заявок: Это вагоны, которые оставались на станции после истечения срока действия предыдущих заявок на перевозку. Если они технически и коммерчески пригодны, их тоже учитывают, поскольку они могут быть использованы для новой заявки.
Поможет ли это?
Ответ узнаем после марта 2025 года (планируемый срок вступления в силу).
Публичное обсуждение проекта продлится до 27.11.2024.
👍4🔥3⚡1🤔1
Одни коллеги обсудили с другими коллегами динамическую модель загрузки инфраструктуры ОАО «РЖД» (ДМ ЗИ).
ДМ ЗИ применяется для автоматизированной оценки возможностей инфраструктуры общего и необщего пользования в процессе согласования заявок на перевозку грузов ф. ГУ-12, запросов-уведомлений, СКПП и ЗУ на порожние полувагоны в адрес З-СИБ.
ДМ ЗИ применяется для автоматизированной оценки возможностей инфраструктуры общего и необщего пользования в процессе согласования заявок на перевозку грузов ф. ГУ-12, запросов-уведомлений, СКПП и ЗУ на порожние полувагоны в адрес З-СИБ.
Telegram
N.Trans Lab
Выступление заместителя председателя Объединенного ученого совета ОАО «РЖД», доктора техн. наук, профессора ОСЬМИНИНА А.Т. «ДИНАМИЧЕСКАЯ МОДЕЛЬ ЗАГРУЗКИ ИНФРАСТРУКТУРЫ ОАО «РЖД» (ДМЗИ) Научно – практические аспекты. Перспективы развития» С 3-ей международной…
👍3🔥2⚡1
Как упростить синтез модели? Дубль 2.
Про формирование было здесь. Изначальная ветка повествования про структуру нашего имитационного комплекса для моделирования работы ж.-д. инфраструктуры - здесь.
Мы помним, что для задания операции требуется16 много параметров. Сегодня на повестке: как упростить описание процесса расформирования поездов.
Используем минимум параметров:
Имя
Используемые локомотивы
Продолжительность выполнения
Связка: Путь/%/Категория
У предка расформирования (вытягивание состава) алгоритм автоматически возьмет ресурс «вытяжной путь» для построения маршрутов. В результате расформирования все вагоны с вытяжного пути в заданном процентном соотношении распределяются по выбранным путям, затем работа с вагонами на каждом пути продолжится в другой категории.
Нюансы модели для учета расформирования:
1. В поступающих поездах задается только количество вагонов и подключается нормальное распределение вагонов, чтобы параметр был более динамичным. Составность поезда не задается.
2. Операции «расформирование» можно подключить в технологический процесс через логическое «или» с заданием вероятности на каждый исход.
#Про_ИК
Про формирование было здесь. Изначальная ветка повествования про структуру нашего имитационного комплекса для моделирования работы ж.-д. инфраструктуры - здесь.
Мы помним, что для задания операции требуется
Используем минимум параметров:
Имя
Используемые локомотивы
Продолжительность выполнения
Связка: Путь/%/Категория
У предка расформирования (вытягивание состава) алгоритм автоматически возьмет ресурс «вытяжной путь» для построения маршрутов. В результате расформирования все вагоны с вытяжного пути в заданном процентном соотношении распределяются по выбранным путям, затем работа с вагонами на каждом пути продолжится в другой категории.
Нюансы модели для учета расформирования:
1. В поступающих поездах задается только количество вагонов и подключается нормальное распределение вагонов, чтобы параметр был более динамичным. Составность поезда не задается.
2. Операции «расформирование» можно подключить в технологический процесс через логическое «или» с заданием вероятности на каждый исход.
#Про_ИК
👍7⚡1🔥1
5 копеек в повышение тарифов
Да, оно необходимо. Да, альтернативные источники финансирования не помогают. Да, сокращается инвестпограмма РЖД (в следующем году на 36,7%). Но под каким соусом повышаются тарифы – это загадочная история… Может планируется системный пересмотр грузовой базы (выдавить с рынка отдельные сектора,о какой отрасли вы больше всего в этом году видели противоречивых новостей ) или преследуются аналогичные цели ЦБ)?
А пока предлагаю взглянуть на контекст повышения тарифов и поискать не состыковки:
1️⃣ Тариф на порожний побег исторически построен для другой технологии работы парка вагонов - когда он находился под управлением РЖД. Сейчас почти весь парк в частных руках. И низкий тариф позволяет отправлять порожние вагоны на дальние расстояния. Это одна из причин почему сегодня ж.-д. сеть плохо работает - много "перевозок воздуха".
Это отчасти верно. Однако это игнорирует тот факт, что частная собственность на подвижной состав должна приводить к более эффективному распределению ресурсов благодаря рыночным механизмам. Низкий тариф на порожние рейсы может быть результатом неэффективности рынка и/или прошлых методов регулирования РЖД, а не только следствием частной собственности. Хотя чрезмерные порожние перевозки неэффективны, простое повышение тарифа не решает проблему автоматически. Первопричиной может быть плохое планирование сети, отсутствие координации между грузоотправителями и владельцами вагонов, а также неэффективная логистика. Повышение тарифа может привести к неэффективности в других сферах, например, к увеличению автомобильных перевозок в обход железных дорог.
2️⃣ Рынок представления вагонов – профицитный и высококонкурентный. Нужно самостоятельно работать в этом конкурентном сегменте над тем, чтобы снизить свои издержки.
Это утверждение вводит в заблуждение из-за значительной рыночной власти РЖД. Рынок не является по-настоящему конкурентным, если РЖД контролирует инфраструктуру. У некоторых компаний может не быть другого выбора, кроме как согласиться на более высокие тарифы, установленные РЖД.
3️⃣ В 2019 году тариф на порожний пробег подняли на 6%, ставка оператора рухнула на 35%. Хороший пример: работа по долгосрочным контрактам с фиксированной стоимостью.
Одного показателя (2019 год) недостаточно, чтобы опровергнуть общую корреляцию тарифа на порожний пробег и ставку оператора. На тарифы операторов влияет множество других факторов. Контракты с фиксированными ценами вряд ли применимы повсеместно; большинство компаний могут не обладать такой же переговорной силой, как крупные игроки.
4️⃣ Новые принципы ценообразования будут использовать промышленную инфляцию вместо потребительской
Конкретная методология и используемые данные остаются неясными. Использование составного индекса допустимо, но состав и вес компонентов имеют решающее значение и должны быть прозрачными. При этом создаются искаженные стимулы: использование сводного индекса стимулирует рост затрат в РЖД, потенциально снижая эффективность и препятствуя инновациям.
5️⃣ Критические последствия: рост инфляции (непосредственно влияющей на потребителей), снижение конкурентоспособности российских отраслей (делающее их менее конкурентоспособными как на внутреннем, так и на международном рынках), усугубление региональных различий (транспортные расходы составляют большую часть производственных затрат в отдалённых районах) и потенциальный переход на менее эффективные виды транспорта (автомобильный). Это непреднамеренное последствие того, что РЖД не решает системные проблемы, а просто перекладывает расходы на потребителей и предприятия. Или я просто загнался?
Вчера повысили тарифы на грузовые перевозки – на 13,8%, на пассажирские — на 11,6%.
Да, оно необходимо. Да, альтернативные источники финансирования не помогают. Да, сокращается инвестпограмма РЖД (в следующем году на 36,7%). Но под каким соусом повышаются тарифы – это загадочная история… Может планируется системный пересмотр грузовой базы (выдавить с рынка отдельные сектора,
А пока предлагаю взглянуть на контекст повышения тарифов и поискать не состыковки:
1️⃣ Тариф на порожний побег исторически построен для другой технологии работы парка вагонов - когда он находился под управлением РЖД. Сейчас почти весь парк в частных руках. И низкий тариф позволяет отправлять порожние вагоны на дальние расстояния. Это одна из причин почему сегодня ж.-д. сеть плохо работает - много "перевозок воздуха".
Это отчасти верно. Однако это игнорирует тот факт, что частная собственность на подвижной состав должна приводить к более эффективному распределению ресурсов благодаря рыночным механизмам. Низкий тариф на порожние рейсы может быть результатом неэффективности рынка и/или прошлых методов регулирования РЖД, а не только следствием частной собственности. Хотя чрезмерные порожние перевозки неэффективны, простое повышение тарифа не решает проблему автоматически. Первопричиной может быть плохое планирование сети, отсутствие координации между грузоотправителями и владельцами вагонов, а также неэффективная логистика. Повышение тарифа может привести к неэффективности в других сферах, например, к увеличению автомобильных перевозок в обход железных дорог.
2️⃣ Рынок представления вагонов – профицитный и высококонкурентный. Нужно самостоятельно работать в этом конкурентном сегменте над тем, чтобы снизить свои издержки.
Это утверждение вводит в заблуждение из-за значительной рыночной власти РЖД. Рынок не является по-настоящему конкурентным, если РЖД контролирует инфраструктуру. У некоторых компаний может не быть другого выбора, кроме как согласиться на более высокие тарифы, установленные РЖД.
3️⃣ В 2019 году тариф на порожний пробег подняли на 6%, ставка оператора рухнула на 35%. Хороший пример: работа по долгосрочным контрактам с фиксированной стоимостью.
Одного показателя (2019 год) недостаточно, чтобы опровергнуть общую корреляцию тарифа на порожний пробег и ставку оператора. На тарифы операторов влияет множество других факторов. Контракты с фиксированными ценами вряд ли применимы повсеместно; большинство компаний могут не обладать такой же переговорной силой, как крупные игроки.
4️⃣ Новые принципы ценообразования будут использовать промышленную инфляцию вместо потребительской
Конкретная методология и используемые данные остаются неясными. Использование составного индекса допустимо, но состав и вес компонентов имеют решающее значение и должны быть прозрачными. При этом создаются искаженные стимулы: использование сводного индекса стимулирует рост затрат в РЖД, потенциально снижая эффективность и препятствуя инновациям.
5️⃣ Критические последствия: рост инфляции (непосредственно влияющей на потребителей), снижение конкурентоспособности российских отраслей (делающее их менее конкурентоспособными как на внутреннем, так и на международном рынках), усугубление региональных различий (транспортные расходы составляют большую часть производственных затрат в отдалённых районах) и потенциальный переход на менее эффективные виды транспорта (автомобильный). Это непреднамеренное последствие того, что РЖД не решает системные проблемы, а просто перекладывает расходы на потребителей и предприятия. Или я просто загнался?
👍8✍3🔥1
Что такое ИИ?
Предлагаю собрать ребус в определения самостоятельно. Ниже приведу примеры ИИ для каждого подхода.
Подход 1-4. Тест Тьюринга.
Подход 1-3. Компьютерное зрение, где результаты нейрофизиологических исследований используются при построении вычислительных моделей.
Подход 2-3. Системы, использующие 4 закона логики.
Подход 2-4. Рациональные агенты, способные поступать в соответствии с целями.
Существует 4 подхода к определению искусственного интеллекта из двух противопоставлений: человекоподобность(1)-рациональность(2) и мышление(3)-поведение(4).
Предлагаю собрать ребус в определения самостоятельно. Ниже приведу примеры ИИ для каждого подхода.
Подход 1-4. Тест Тьюринга.
Подход 1-3. Компьютерное зрение, где результаты нейрофизиологических исследований используются при построении вычислительных моделей.
Подход 2-3. Системы, использующие 4 закона логики.
Подход 2-4. Рациональные агенты, способные поступать в соответствии с целями.
👍4🤔2🔥1
У вас есть 7 рублей на инвестиции в инфраструктуру завода.
Соберите кейс:
– Приобрести новое оборудование – 3 рубля;
– Построить дополнительный склад – 2 рубля;
– Реконструкция путей – 3 рубля;
– Найти «узкие места», обосновать план развития, внедрить it-решения для управления производством – 1 рубль;
– Обеспечить гарантированный доход на новые объемы производства – 4 рубля;
– Привлечь партнёров с опытом в управлении производством – 2 рубля;
– Договориться с новыми дистрибьюторами – 1 рубль;
– Дистрибьюторы и дилеры всегда просят «ещё» и платят вперед, вывоз продукции не имеет внешних ограничений – 15 рублей.
Соберите кейс:
– Приобрести новое оборудование – 3 рубля;
– Построить дополнительный склад – 2 рубля;
– Реконструкция путей – 3 рубля;
– Найти «узкие места», обосновать план развития, внедрить it-решения для управления производством – 1 рубль;
– Обеспечить гарантированный доход на новые объемы производства – 4 рубля;
– Привлечь партнёров с опытом в управлении производством – 2 рубля;
– Договориться с новыми дистрибьюторами – 1 рубль;
– Дистрибьюторы и дилеры всегда просят «ещё» и платят вперед, вывоз продукции не имеет внешних ограничений – 15 рублей.
😱4🔥2👍1
Прогноз, провокация и высокая степень неопределенности
Данные по обороту вагона за ноябрь должны появиться на этой неделе. И пока одни уже декларируют снижение, а другие говорят что это провокация. Даю короткий прогноз:
📍в целом снижение до 2%;
📍под грузовыми операциями будет черный ящик т.к. простой увеличится из-за неприема на пути общего пользования, но сократиться из-за снижения погрузки. Итого: рост до 10%;
📍по инфраструктуре РЖД снижение на 5-6% (как ни как > 70 тыс. вагонов убрали).
Данные по обороту вагона за ноябрь должны появиться на этой неделе. И пока одни уже декларируют снижение, а другие говорят что это провокация. Даю короткий прогноз:
📍в целом снижение до 2%;
📍под грузовыми операциями будет черный ящик т.к. простой увеличится из-за неприема на пути общего пользования, но сократиться из-за снижения погрузки. Итого: рост до 10%;
📍по инфраструктуре РЖД снижение на 5-6% (как ни как > 70 тыс. вагонов убрали).
✍2🤔2👀1
RWS
Прогноз, провокация и высокая степень неопределенности Данные по обороту вагона за ноябрь должны появиться на этой неделе. И пока одни уже декларируют снижение, а другие говорят что это провокация. Даю короткий прогноз: 📍в целом снижение до 2%; 📍под грузовыми…
Данные быстро появились.
В целом оборот вагона: "-2,6%".
Под грузовыми операциями: "+3,3%".
На инфраструктуре ржд: "-7,2%".
Значит, будут посты про статистику.
В целом оборот вагона: "-2,6%".
Под грузовыми операциями: "+3,3%".
На инфраструктуре ржд: "-7,2%".
Значит, будут посты про статистику.
👍5
Статистика может доказать что угодно, даже правду
Как проверить свою гипотезу? Статистика поможет. Всегда можно найти метод, который обоснует вашу гипотезу. А если серьезно, предлагаю укрупненно пройтись по популярным методам статистической проверки гипотез.
1. Одновыборочный t-критерий Стьюдента:
Задача: проверить, значительно ли отличается среднее время задержки поездов на маршруте от целевого значения в 5 минут.
Условия применения: данные должны быть приблизительно нормально распределены. Метод чувствителен к выбросам. Внешние факторы (погода, ремонт путей) не учитываются. При нарушении предположения о нормальном распределении следует использовать непараметрические альтернативы (например, тест знаков).
2. Двухвыборочный t-критерий Стьюдента (независимые выборки):
Задача: сравнить среднюю скорость поездов на двух разных линиях.
Условия применения: данные должны быть приблизительно нормально распределены, дисперсии в группах примерно равны. Метод чувствителен к выбросам. Различия в типах поездов, уклонах и других факторах могут исказить результаты. Если предположения о нормальном распределении или равенстве дисперсий не выполняются, следует использовать критерий Манна-Уитни или критерий Уэлча соответственно.
3. Парный t-критерий Стьюдента (зависимые выборки):
Задача: сравнить расход топлива одним и тем же локомотивом до и после технического обслуживания.
Условия применения: требуется приблизительно нормальное распределение разностей между парами наблюдений (до и после). Внешние факторы, не связанные с техническим обслуживанием, могут исказить результаты. Если предположение о нормальности нарушается, используется критерий Уилкоксона.
4. ANOVA (анализ дисперсии):
Задача: сравнить среднюю задержку поездов на трёх разных маршрутах.
Условия применения: метод более эффективен, чем попарное применение t-критериев, контролируя совокупный уровень значимости. Однако требуется приблизительно нормального распределения данных и равенства дисперсий во всех группах. Если эти предположения не выполняются, следует использовать непараметрический критерий Крускала-Уоллиса.
5. Критерий Хи-квадрат:
Задача: Анализ связи между типом локомотива и частотой поломок.
Условия применения: этот метод используется для анализа категориальных данных и проверки независимости двух категориальных переменных. Однако он не устанавливает причинно-следственную связь и требует достаточно больших ожидаемых частот в каждой ячейке таблицы сопряженности.
6. Корреляция Пирсона:
Задача: исследовать взаимосвязь между средней скоростью движения поездов на определенном участке пути и скоростью износа рельсов на этом участке.
Условия применения: измерение линейной зависимости, чувствителен к выбросам.
7. Корреляция Спирмена:
Задача: проанализировать связь между рейтингом удовлетворенности пассажиров и частотой задержек.
Условия применения: этот метод измеряет монотонную корреляцию, не предполагая нормального распределения данных. Он более устойчив к выбросам, чем корреляция Пирсона, и подходит для порядковых данных. Однако он не измеряет силу нелинейной связи.
Критерий Манна-Уитни, Крускала-Уоллиса, Уэлча, Z-тест, Уилкоксона, F-тест: Условия применения этих методов аналогичны описанным выше, но сосредоточены на ситуациях, когда не выполняются предположения параметрических методов (нормальность, равенство дисперсий, независимость). Они предлагают альтернативы, но часто с меньшей статистической мощностью.
Что еще остается из нишевых методов?
1. Непараметрические тесты:
• Критерий знаков (Sign test)
• Тест МакНемара
• Тест Фридмана
2. Дискретные распределения:
• Гипергеометрическое распределение
• Биномиальный тест
3. Анализ временных рядов
• Тест Дики-Фуллера (ADF)
• Автокорреляция (ACF)
4. Проверка предположений о данных и проверка соответствия распределениям:
• Тесты Бартлетта и Левена
• Тест Шапиро-Уилка
• Критерий Колмогорова-Смирнова
• Тест Андерсона-Дарлинга
5. И др...
Если тематика интересна, то по каждому методу можно сделать пост:
Пример задачи
Требования к выборке
Нюансы использования
Инструменты офлайн/онлайн
🔥10👍3⚡1
Какие станции на участке чаще всего являются причиной простоев поездов?
Казалось бы, просуммировали простои – нашли станцию с наибольшими простоями. Ответ готов.
Но в этом подходе мы не учли:
- размеры движения (может простои выросли из-за объема работы);
- продолжительность простоев (не учли выбросы);
- внешние факторы (ремонт и пр.);
- статистическую значимость (без статистического анализа невозможно определить, являются ли полученные результаты значимыми или просто случайным совпадением).
Что делаем? В основе метод: ANOVA.
1. Предварительно собираем данные:
• Средняя продолжительность простоя на каждой станции.
• Количество простоев на каждой станции.
• Стандартное отклонение простоев для каждой станции.
• Распределение простоев. Строим гистограммы распределения времени задержки на разных станциях, чтобы понять форму распределения и наличие выбросов.
2. Анализируем дисперсии (ANOVA).
• Гипотеза. Мы хотим проверить, являются ли различия в средней продолжительности простоя между станциями статистически значимыми.
• Проверка однородности дисперсий. Перед применением дисперсионного анализа необходимо убедиться, что дисперсии простоев на разных станциях примерно равны. Тест Бартлетта или Левена подойдут.
• ANOVA. Если дисперсии близки, проводим однофакторный ANOVA, где фактором является станция. Если дисперсии значительно различаются, используем подходящий непараметрический аналог, например, тест Краскела-Уоллиса.
• Пост-хок тесты. Если ANOVA выявит значимые различия, необходимо провести пост-хок тесты (например, Туки, Шнидмана-Кени), чтобы определить, на каких именно станциях средняя продолжительность простоя статистически различается.
3. При необходимости проводим тесты ранговой корреляции:
Корреляция с другими факторами. Возможно, продолжительность простоев на станциях коррелирует с другими переменными (например, интенсивностью движения, временем года и др.). Используем тесты ранговой корреляции (например, Спирмена или Кендалла), чтобы оценить эту корреляцию.
Критерии оценки статистической значимости:
• p-значение: важно анализировать p-значение, полученное при проведении дисперсионного анализа и пост-хок тестов. Если p-значение меньше заданного уровня значимости (например: 0,05), различия в средней продолжительности простоя статистически значимы.
• Доверительные интервалы: используем доверительные интервалы для средних значений по каждой станции, что поможет оценить погрешность и точность результатов.
Кратко про использование ANOVA:
Требования к выборке:
1. Независимые наблюдения в каждой группе.
2. Нормальное распределение данных в каждой группе (можно проверить с помощью теста Шапиро-Уилка или Колмогорова-Смирнова).
3. Гомогенность дисперсий (равенство дисперсий) в группах (можно проверить с помощью теста Бартлетта или Левена). Для больших выборок дисперсионный анализ относительно устойчив к небольшим нарушениям этого условия.
4. Количественная зависимая переменная.
5. Качественная независимая переменная (фактор) с несколькими уровнями (группами).
Нюансы использования: нарушение предположений о нормальности и однородности дисперсий может привести к неверным результатам. В таких случаях используются непараметрические аналоги (тест Краскела-Уоллиса).
Инструменты:
Офлайн:
Python: scipy.stats.f_oneway(group1, group2, group3)
R: aov(response ~ group)
Онлайн
Критерий Колмогорова-Смирнова
Python: scipy.stats.ks_2samp(data1, data2)
R: ks.test(x, y)
Тест Бартлетта
Python: scipy.stats.bartlett(group1, group2, ...)
R: bartlett.test(values ~ groups)
Тест Левена
Python: scipy.stats.levene(group1, group2, ..., center='mean')
R: leveneTest(values ~ groups, center=mean) (из библиотеки car).
Коэффициент Кендалла
Python: scipy.stats.kendalltau(x, y)
R: cor.test(x, y, method = "kendall")
Корреляция Спирмена
Python: scipy.stats.spearmanr(x, y)
R: cor.test(x, y, method="spearman")
Критерий Краскела-Уоллиса
Python: scipy.stats.kruskal(*samples)
R: kruskal.test(x, y, z)
Кто-нибудь так искал "узкие места" инфраструктуры?
Интересно больше про инструментарий, логику применения или что-то иное?
#Стат_методы
Казалось бы, просуммировали простои – нашли станцию с наибольшими простоями. Ответ готов.
Но в этом подходе мы не учли:
- размеры движения (может простои выросли из-за объема работы);
- продолжительность простоев (не учли выбросы);
- внешние факторы (ремонт и пр.);
- статистическую значимость (без статистического анализа невозможно определить, являются ли полученные результаты значимыми или просто случайным совпадением).
Что делаем? В основе метод: ANOVA.
1. Предварительно собираем данные:
• Средняя продолжительность простоя на каждой станции.
• Количество простоев на каждой станции.
• Стандартное отклонение простоев для каждой станции.
• Распределение простоев. Строим гистограммы распределения времени задержки на разных станциях, чтобы понять форму распределения и наличие выбросов.
2. Анализируем дисперсии (ANOVA).
• Гипотеза. Мы хотим проверить, являются ли различия в средней продолжительности простоя между станциями статистически значимыми.
• Проверка однородности дисперсий. Перед применением дисперсионного анализа необходимо убедиться, что дисперсии простоев на разных станциях примерно равны. Тест Бартлетта или Левена подойдут.
• ANOVA. Если дисперсии близки, проводим однофакторный ANOVA, где фактором является станция. Если дисперсии значительно различаются, используем подходящий непараметрический аналог, например, тест Краскела-Уоллиса.
• Пост-хок тесты. Если ANOVA выявит значимые различия, необходимо провести пост-хок тесты (например, Туки, Шнидмана-Кени), чтобы определить, на каких именно станциях средняя продолжительность простоя статистически различается.
3. При необходимости проводим тесты ранговой корреляции:
Корреляция с другими факторами. Возможно, продолжительность простоев на станциях коррелирует с другими переменными (например, интенсивностью движения, временем года и др.). Используем тесты ранговой корреляции (например, Спирмена или Кендалла), чтобы оценить эту корреляцию.
Критерии оценки статистической значимости:
• p-значение: важно анализировать p-значение, полученное при проведении дисперсионного анализа и пост-хок тестов. Если p-значение меньше заданного уровня значимости (например: 0,05), различия в средней продолжительности простоя статистически значимы.
• Доверительные интервалы: используем доверительные интервалы для средних значений по каждой станции, что поможет оценить погрешность и точность результатов.
Кратко про использование ANOVA:
Требования к выборке:
1. Независимые наблюдения в каждой группе.
2. Нормальное распределение данных в каждой группе (можно проверить с помощью теста Шапиро-Уилка или Колмогорова-Смирнова).
3. Гомогенность дисперсий (равенство дисперсий) в группах (можно проверить с помощью теста Бартлетта или Левена). Для больших выборок дисперсионный анализ относительно устойчив к небольшим нарушениям этого условия.
4. Количественная зависимая переменная.
5. Качественная независимая переменная (фактор) с несколькими уровнями (группами).
Нюансы использования: нарушение предположений о нормальности и однородности дисперсий может привести к неверным результатам. В таких случаях используются непараметрические аналоги (тест Краскела-Уоллиса).
Инструменты:
Офлайн:
Python: scipy.stats.f_oneway(group1, group2, group3)
R: aov(response ~ group)
Онлайн
Критерий Колмогорова-Смирнова
Python: scipy.stats.ks_2samp(data1, data2)
R: ks.test(x, y)
Тест Бартлетта
Python: scipy.stats.bartlett(group1, group2, ...)
R: bartlett.test(values ~ groups)
Тест Левена
Python: scipy.stats.levene(group1, group2, ..., center='mean')
R: leveneTest(values ~ groups, center=mean) (из библиотеки car).
Коэффициент Кендалла
Python: scipy.stats.kendalltau(x, y)
R: cor.test(x, y, method = "kendall")
Корреляция Спирмена
Python: scipy.stats.spearmanr(x, y)
R: cor.test(x, y, method="spearman")
Критерий Краскела-Уоллиса
Python: scipy.stats.kruskal(*samples)
R: kruskal.test(x, y, z)
Кто-нибудь так искал "узкие места" инфраструктуры?
Интересно больше про инструментарий, логику применения или что-то иное?
#Стат_методы
👍4⚡2🔥2
Forwarded from SIMETRA | Задавать красоту движения
Предложения SIMETRA вошли в Стратегию развития Санкт-Петербурга до 2035 года
В минувшую пятницу, 13 декабря, в Технологическом хабе Сбера состоялась стратегическая сессия по вопросу актуализации целей Стратегии социально-экономического развития Санкт-Петербурга на период до 2035 года.
Соответствующий Закон города был принят в 2018 году, сейчас действует версия с изменениями по состоянию на декабрь 2022 года, и с учётом как накопленного опыта, так и произошедших общих изменений возникла объективная необходимость в корректировке этого документа.
На сессии, в которой приняли участие вице-губернаторы Кирилл Поляков, Николай Линченко, Валерий Москаленко и Евгений Разумишкин, руководители и специалисты всех городских комитетов и крупнейших предприятий, был проведён комплексный анализ всех направлений развития города, включая роль его комплексной транспортной системы в обеспечении комфортной и доступной среды для проживания.
Эксперты SIMETRA также были приглашены для участия в мероприятии.
Генеральный директор Владимир Швецов представил предложения по корректировке и расширению целевых показателей Стратегии на основе метрик математического моделирования. Подобные показатели мы применяем для оценки качества систем общественного транспорта в городах России при составлении Рейтинга.
Директор по решениям в области общественного транспорта Владимир Валдин в процессе обсуждения итогов сессии акцентировал внимание на важности формирования приоритетных коридоров движения магистрального наземного транспорта.
Предложения об использовании показателей Рейтинга в качестве возможных метрик оценки достигаемых результатов, о развитии применения методов математического транспортного моделирования, о замене показателя «доступности станций метро» на «доступность станций и остановок магистрального транспорта», а также о создании коридоров магистрального транспорта вошли в итоговый протокол стратегической сессии.
В минувшую пятницу, 13 декабря, в Технологическом хабе Сбера состоялась стратегическая сессия по вопросу актуализации целей Стратегии социально-экономического развития Санкт-Петербурга на период до 2035 года.
Соответствующий Закон города был принят в 2018 году, сейчас действует версия с изменениями по состоянию на декабрь 2022 года, и с учётом как накопленного опыта, так и произошедших общих изменений возникла объективная необходимость в корректировке этого документа.
На сессии, в которой приняли участие вице-губернаторы Кирилл Поляков, Николай Линченко, Валерий Москаленко и Евгений Разумишкин, руководители и специалисты всех городских комитетов и крупнейших предприятий, был проведён комплексный анализ всех направлений развития города, включая роль его комплексной транспортной системы в обеспечении комфортной и доступной среды для проживания.
Эксперты SIMETRA также были приглашены для участия в мероприятии.
Генеральный директор Владимир Швецов представил предложения по корректировке и расширению целевых показателей Стратегии на основе метрик математического моделирования. Подобные показатели мы применяем для оценки качества систем общественного транспорта в городах России при составлении Рейтинга.
Директор по решениям в области общественного транспорта Владимир Валдин в процессе обсуждения итогов сессии акцентировал внимание на важности формирования приоритетных коридоров движения магистрального наземного транспорта.
Предложения об использовании показателей Рейтинга в качестве возможных метрик оценки достигаемых результатов, о развитии применения методов математического транспортного моделирования, о замене показателя «доступности станций метро» на «доступность станций и остановок магистрального транспорта», а также о создании коридоров магистрального транспорта вошли в итоговый протокол стратегической сессии.
👍3🔥2⚡1
Идея «Анализ выживаемости объекта инфраструктуры»
Выживаемость как показатель возможности сохранения во времени способность выполнять требуемые функции в заданных режимах и условиях применения. Да, определение напоминает понятие «Надежность», но я сейчас про выживаниеи не про геополитику . Почему? Потому что есть идея в применении метода Каплана-Мейера и Лог-ранк теста.
В чем идея?
Моделируем работу объекта в различных условиях до сбоя, когда дальнейшая работа инфраструктурного комплекса невозможна при заданных объемах работы. Получаем количество дней до критического события – N. Вариант развития с наибольшим N – искомый? Вряд ли… На исход могло повлиять множество факторов.
Поэтому о каждому варианту развития объекта производим моделирование с различными техническими и технологическими сбоями (вероятность и частота их наступления в каждом варианте желательно должна быть одинакова для чистоты эксперимента) при равных объемах работы на горизонте года. Количество подвариантов (сценарии со сбоями) должно от 15 для подтверждения статистической значимости. Проводим метод Каплана-Мейера и лог-ранг тест, чтобы определить, есть ли статистически значимые различия в надёжности между вариантами.
Общий лог-ранк тест даст нам p-value. p>0.05 – нет статистически значимого различия, p<0.05 – существует статистически значимое различие между вариантами. Также производятся попарные сравнения. Далее анализируем кривые выживаемости по методу Каплана-Мейера (находим кривую выше остальных). Остаемся довольны результатом.
Инструменты:
Python: lifelines.KaplanMeierFitter, lifelines.logrank_test.
R: survival::survfit, survival::survdiff.
Онлайн
В чем проблема идеи?
Я провел несколько десятков тестов (сравнения выборок выживаемости) и вместо использования этого стат. метода:
1. Провел сортировку значений в каждом варианте с учетом цензурирования данных (событие в рамках наблюдения не произошло).
2. Посчитал средние значения в каждом варианте с цензурированными данными и без, а так же количество ценз. данных.
3. На основе 3 значений выбирал лучший вариант. И он всегда совпадал с результатом стат. метода. Исключение: p-value > 0.05. Но тогда собственно любой результат является неплохим.
p.s. Стат. метод не устойчив к выбросам, а используя собственную логику – можно интерпретировать выброс и выдать правильное решение.
Нужно ли использовать метод Каплана-Мейера и Лог-ранк тест?
#Стат_методы #Идея
Выживаемость как показатель возможности сохранения во времени способность выполнять требуемые функции в заданных режимах и условиях применения. Да, определение напоминает понятие «Надежность», но я сейчас про выживание
В чем идея?
Моделинг до сбоя - Стат.обработка
Моделируем работу объекта в различных условиях до сбоя, когда дальнейшая работа инфраструктурного комплекса невозможна при заданных объемах работы. Получаем количество дней до критического события – N. Вариант развития с наибольшим N – искомый? Вряд ли… На исход могло повлиять множество факторов.
Поэтому о каждому варианту развития объекта производим моделирование с различными техническими и технологическими сбоями (вероятность и частота их наступления в каждом варианте желательно должна быть одинакова для чистоты эксперимента) при равных объемах работы на горизонте года. Количество подвариантов (сценарии со сбоями) должно от 15 для подтверждения статистической значимости. Проводим метод Каплана-Мейера и лог-ранг тест, чтобы определить, есть ли статистически значимые различия в надёжности между вариантами.
Общий лог-ранк тест даст нам p-value. p>0.05 – нет статистически значимого различия, p<0.05 – существует статистически значимое различие между вариантами. Также производятся попарные сравнения. Далее анализируем кривые выживаемости по методу Каплана-Мейера (находим кривую выше остальных). Остаемся довольны результатом.
Инструменты:
Python: lifelines.KaplanMeierFitter, lifelines.logrank_test.
R: survival::survfit, survival::survdiff.
Онлайн
В чем проблема идеи?
Я провел несколько десятков тестов (сравнения выборок выживаемости) и вместо использования этого стат. метода:
1. Провел сортировку значений в каждом варианте с учетом цензурирования данных (событие в рамках наблюдения не произошло).
2. Посчитал средние значения в каждом варианте с цензурированными данными и без, а так же количество ценз. данных.
3. На основе 3 значений выбирал лучший вариант. И он всегда совпадал с результатом стат. метода. Исключение: p-value > 0.05. Но тогда собственно любой результат является неплохим.
p.s. Стат. метод не устойчив к выбросам, а используя собственную логику – можно интерпретировать выброс и выдать правильное решение.
Нужно ли использовать метод Каплана-Мейера и Лог-ранк тест?
#Стат_методы #Идея
👍3🤔3❤1🔥1
🚀 Синхронизация данных: Ключ к эффективному взаимодействию цифровых двойников и имитационных моделей
Цифровые двойники (ЦД) и имитационные модели (ИМ) играют ключевую роль в оптимизации и управлении сложными процессами. Но для их эффективной работы необходима надежная и своевременная синхронизация данных. Почему это так важно? Синхронизация данных обеспечивает:
✔️ Целостность информации: ЦД и ИМ получают согласованную и непротиворечивую картину данных.
✔️ Актуальность: Данные в ЦД и ИМ отражают реальное состояние объекта или процесса в текущий момент.
✔️ Корректное взаимодействие: ЦД и ИМ могут эффективно обмениваться информацией и работать совместно.
✔️ Взвешенные решения: На основе точных и полных данных можно принимать обоснованные и эффективные решения.
Для синхронизации данных междуЦД и ИМ обычно используются три основных подхода:
1️⃣ Прямая Синхронизация. Системы взаимодействуют напрямую для обмена данными. Это может быть в реальном времени (например, через API, WebSockets) или по расписанию (например, через скрипты).
Ключевые технологии: REST API, GraphQL API, WebSockets, очереди сообщений (Kafka, RabbitMQ), скрипты (Python, Bash).
2️⃣ Синхронизация на основе Событий. Системы реагируют на изменения, публикуя и подписываясь на события. Такой подход обеспечивает гибкость и масштабируемость.
Ключевые технологии: Шины сообщений (Apache Kafka, RabbitMQ, Azure Service Bus), Webhooks.
3️⃣ Синхронизация через Хранилище Данных. Данные сначала собираются в централизованное хранилище, а затем синхронизируются с другими системами.
Ключевые технологии: ETL-процессы (Apache Airflow, Apache NiFi), CDC (Debezium, Oracle GoldenGate).
💡 Каждый из этих подходов имеет свои особенности, преимущества и недостатки. Выбор конкретного варианта зависит от конкретных требований проекта, масштаба и типа данных. Планирую написать про каждый вариант.
План такой:
1. Прямая синхронизация
1.1. Реальное время:
1.1.1. API
1.1.1,1. REST API
1.1.1,2. GraphQL API
1.1.2. WebSockets
1.1.3. Message Queues
1.1.4. OPC UA
1.1.5. MQTT
1.2. Запланированная синхронизация
1.2.1. Скрипты
1.2.2. Планировщик задач
1.2.3. Пакетная обработка
2. Синхронизация на основе событий
2.1. Шины сообщений
2.2. Webhooks
3. Синхронизация с использованием промежуточного хранилища данных
3.1. ETL-процессы
3.2. CDC
#ИМ #ЦД #Синхронизация
Цифровые двойники (ЦД) и имитационные модели (ИМ) играют ключевую роль в оптимизации и управлении сложными процессами. Но для их эффективной работы необходима надежная и своевременная синхронизация данных. Почему это так важно? Синхронизация данных обеспечивает:
✔️ Целостность информации: ЦД и ИМ получают согласованную и непротиворечивую картину данных.
✔️ Актуальность: Данные в ЦД и ИМ отражают реальное состояние объекта или процесса в текущий момент.
✔️ Корректное взаимодействие: ЦД и ИМ могут эффективно обмениваться информацией и работать совместно.
✔️ Взвешенные решения: На основе точных и полных данных можно принимать обоснованные и эффективные решения.
Для синхронизации данных междуЦД и ИМ обычно используются три основных подхода:
1️⃣ Прямая Синхронизация. Системы взаимодействуют напрямую для обмена данными. Это может быть в реальном времени (например, через API, WebSockets) или по расписанию (например, через скрипты).
Ключевые технологии: REST API, GraphQL API, WebSockets, очереди сообщений (Kafka, RabbitMQ), скрипты (Python, Bash).
2️⃣ Синхронизация на основе Событий. Системы реагируют на изменения, публикуя и подписываясь на события. Такой подход обеспечивает гибкость и масштабируемость.
Ключевые технологии: Шины сообщений (Apache Kafka, RabbitMQ, Azure Service Bus), Webhooks.
3️⃣ Синхронизация через Хранилище Данных. Данные сначала собираются в централизованное хранилище, а затем синхронизируются с другими системами.
Ключевые технологии: ETL-процессы (Apache Airflow, Apache NiFi), CDC (Debezium, Oracle GoldenGate).
💡 Каждый из этих подходов имеет свои особенности, преимущества и недостатки. Выбор конкретного варианта зависит от конкретных требований проекта, масштаба и типа данных. Планирую написать про каждый вариант.
План такой:
1. Прямая синхронизация
1.1. Реальное время:
1.1.1. API
1.1.1,1. REST API
1.1.1,2. GraphQL API
1.1.2. WebSockets
1.1.3. Message Queues
1.1.4. OPC UA
1.1.5. MQTT
1.2. Запланированная синхронизация
1.2.1. Скрипты
1.2.2. Планировщик задач
1.2.3. Пакетная обработка
2. Синхронизация на основе событий
2.1. Шины сообщений
2.2. Webhooks
3. Синхронизация с использованием промежуточного хранилища данных
3.1. ETL-процессы
3.2. CDC
#ИМ #ЦД #Синхронизация
👍5❤2
1.1.1. API (Application Programming Interfaces):
API позволяют ЦД и ИМ взаимодействовать, обмениваясь данными и командами через стандартизированные интерфейсы.
1.1,1.1. REST API:
Условия использования:
📍 Требуется простота и распространенность. REST является стандартом для веб-сервисов.
📍 Не требуется сложное управление запросами, и достаточно стандартных HTTP-методов.
📍 Нужно взаимодействие между системами, где каждая система представляет собой отдельные веб-приложения.
📍 Важно поддерживать связь с веб-клиентами.
Инструменты:
Flask (Python). Легкий и гибкий фреймворк для создания веб-API. Отлично подходит для прототипирования и если нужно рассчитать ресурс 1 устройства.
Express.js (Node.js). Минималистичный, быстрый и очень гибкий фреймворк для создания веб-приложений и API. Популярен в JavaScript-ориентированных проектах.
Django REST Framework (Python). Мощный и полнофункциональный фреймворк для создания RESTful API. Хороший выбор для крупных и сложных проектов.
ASP .NET Web API (.NET). Так чисто для справки, что есть такой. Фреймворк от Microsoft для создания веб-API на платформе .NET.
Spring Boot (Java). Фреймворк для создания микросервисов и веб-приложений на Java. Популярен в корпоративных и enterprise-проектах.
#ИМ #ЦД #Синхронизация
API позволяют ЦД и ИМ взаимодействовать, обмениваясь данными и командами через стандартизированные интерфейсы.
1.1,1.1. REST API:
Условия использования:
📍 Требуется простота и распространенность. REST является стандартом для веб-сервисов.
📍 Не требуется сложное управление запросами, и достаточно стандартных HTTP-методов.
📍 Нужно взаимодействие между системами, где каждая система представляет собой отдельные веб-приложения.
📍 Важно поддерживать связь с веб-клиентами.
Инструменты:
Flask (Python). Легкий и гибкий фреймворк для создания веб-API. Отлично подходит для прототипирования и если нужно рассчитать ресурс 1 устройства.
Express.js (Node.js). Минималистичный, быстрый и очень гибкий фреймворк для создания веб-приложений и API. Популярен в JavaScript-ориентированных проектах.
Django REST Framework (Python). Мощный и полнофункциональный фреймворк для создания RESTful API. Хороший выбор для крупных и сложных проектов.
ASP .NET Web API (.NET). Так чисто для справки, что есть такой. Фреймворк от Microsoft для создания веб-API на платформе .NET.
Spring Boot (Java). Фреймворк для создания микросервисов и веб-приложений на Java. Популярен в корпоративных и enterprise-проектах.
#ИМ #ЦД #Синхронизация
🔥4👍3⚡2
RWS
1.1.1. API (Application Programming Interfaces): API позволяют ЦД и ИМ взаимодействовать, обмениваясь данными и командами через стандартизированные интерфейсы. 1.1,1.1. REST API: Условия использования: 📍 Требуется простота и распространенность. REST является…
У нас есть две особенные игрушки
Цифровой Двойник (ЦД) – это копия игрушечной машинки, но она находится на экране компьютера. Она показывает всё, что делает настоящая машинка. Если повернёшь настоящую машинку, то и на экране тоже повернётся её копия. Она как зеркало для машинки, только внутри компьютера.
Имитационная Модель (ИМ) – это специальный испытательный полигон для машинки. Мы можем там проверить, что будет, если машинка поедет по горке, врежется в стенку или даже полетит! Это место, где мы можем поиграть с машинкой и посмотреть, что может случиться, не ломая её настоящую копию. Это как умная песочница для проверки твоей машинки на экране.
Как общается копия машинки и песочница?
Они разговаривают не как мы, а с помощью специальных “помощников” – API (это как почтальоны).
• Простые письма (REST API): Когда нужно быстро и просто передать информацию, например:
o “Машинка поехала!” (ЦД говорит ИМ)
o “Ой, машинка врезалась!” (ИМ говорит ЦД)
o Это как простые и быстрые записки, которыми они обмениваются.
Инструменты для написания писем (REST API) – это как разные ручки:
• Ручка “Flask”. Представь, что у нас есть маленькая, лёгкая ручка, которой очень просто писать короткие записки. Она подходит, когда мы хотим быстро сказать машинке: “Поехали!”, или когда песочница говорит: “Всё в порядке!”. Эта ручка для простых сообщений, когда у нас не так много машинок и дел.
• Ручка “Express.js”. Это очень быстрая и ловкая ручка-помощница. Она как будто умеет легко и быстро рисовать много разных картинок и писать много-много записок. Эта ручка маленькая и простая, но при этом очень гибкая – как будто её можно легко настроить, чтобы она делала именно то, что нам нужно. Она как будто волшебная палочка, которая может быстро перестраиваться под разные задачи.
• Ручка “Django REST Framework”. Крутая ручка для больших и сложных записок и даже книг. Она умеет писать много-много разных сообщений и помогает нам держать всё в порядке. Эта ручка нужна, когда у нас много машинок-копий и мы хотим, чтобы всё работало четко и организованно. Это как если бы мы строили большой город с машинками.
• Ручка “Spring Boot”. Эта ручка – очень мощный строительный набор, как швейцарский нож, умеет рисовать маленькие и большие дома для наших машинок-копий. Она очень хорошо умеет все организовывать и следить за тем, чтобы все машинки-копии и песочницы работали слаженно.
Как такой формат? Оставить?
Цифровой Двойник (ЦД) – это копия игрушечной машинки, но она находится на экране компьютера. Она показывает всё, что делает настоящая машинка. Если повернёшь настоящую машинку, то и на экране тоже повернётся её копия. Она как зеркало для машинки, только внутри компьютера.
Имитационная Модель (ИМ) – это специальный испытательный полигон для машинки. Мы можем там проверить, что будет, если машинка поедет по горке, врежется в стенку или даже полетит! Это место, где мы можем поиграть с машинкой и посмотреть, что может случиться, не ломая её настоящую копию. Это как умная песочница для проверки твоей машинки на экране.
Как общается копия машинки и песочница?
Они разговаривают не как мы, а с помощью специальных “помощников” – API (это как почтальоны).
• Простые письма (REST API): Когда нужно быстро и просто передать информацию, например:
o “Машинка поехала!” (ЦД говорит ИМ)
o “Ой, машинка врезалась!” (ИМ говорит ЦД)
o Это как простые и быстрые записки, которыми они обмениваются.
Инструменты для написания писем (REST API) – это как разные ручки:
• Ручка “Flask”. Представь, что у нас есть маленькая, лёгкая ручка, которой очень просто писать короткие записки. Она подходит, когда мы хотим быстро сказать машинке: “Поехали!”, или когда песочница говорит: “Всё в порядке!”. Эта ручка для простых сообщений, когда у нас не так много машинок и дел.
• Ручка “Express.js”. Это очень быстрая и ловкая ручка-помощница. Она как будто умеет легко и быстро рисовать много разных картинок и писать много-много записок. Эта ручка маленькая и простая, но при этом очень гибкая – как будто её можно легко настроить, чтобы она делала именно то, что нам нужно. Она как будто волшебная палочка, которая может быстро перестраиваться под разные задачи.
• Ручка “Django REST Framework”. Крутая ручка для больших и сложных записок и даже книг. Она умеет писать много-много разных сообщений и помогает нам держать всё в порядке. Эта ручка нужна, когда у нас много машинок-копий и мы хотим, чтобы всё работало четко и организованно. Это как если бы мы строили большой город с машинками.
• Ручка “Spring Boot”. Эта ручка – очень мощный строительный набор, как швейцарский нож, умеет рисовать маленькие и большие дома для наших машинок-копий. Она очень хорошо умеет все организовывать и следить за тем, чтобы все машинки-копии и песочницы работали слаженно.
Как такой формат? Оставить?
❤5🔥1
1.1.1,2. GraphQL API: Синхронизация ЦД и ИМ
Традиционные подходы, основанные на REST API, могут оказаться неэффективными из-за избыточности данных и множественных запросов. GraphQL API предоставляет более гибкий и эффективный подход к решению этой задачи.
Ключевые преимущества GraphQL
Передача данных
Только необходимые данные, минимум трафика.
Взаимодействие
Один запрос вместо множества, упрощение логики.
Гибкость
Адаптация под любые требования, единая точка доступа.
Реальное время
Поддержка подписок для актуальных данных.
Комбинация GraphQL и WebSocket позволяет устанавливать постоянное двунаправленное соединение между клиентом и сервером, что идеально подходит для работы в реальном времени
Инструменты GraphQL
GraphQL-core (Python): Простые модели, прототипы.
Graphql-js (JavaScript): Кастомные решения, интеграция с JS.
Apollo GraphQL (JavaScript): Масштабные проекты, кэширование, авторизация.
GraphQL Yoga: Быстрый запуск, демонстрации.
Hasura: Авто API из БД, ускорение разработки.
p.s. Может усложнить запросы при большом количестве связанных данных о ж.-д. инфраструктуре. Избыточная гибкость GraphQL может привести к неоптимизированным запросам и проблемам с производительностью, если не контролировать.
#ИМ #ЦД #Синхронизация
Традиционные подходы, основанные на REST API, могут оказаться неэффективными из-за избыточности данных и множественных запросов. GraphQL API предоставляет более гибкий и эффективный подход к решению этой задачи.
Ключевые преимущества GraphQL
Передача данных
Только необходимые данные, минимум трафика.
Взаимодействие
Один запрос вместо множества, упрощение логики.
Гибкость
Адаптация под любые требования, единая точка доступа.
Реальное время
Поддержка подписок для актуальных данных.
Комбинация GraphQL и WebSocket позволяет устанавливать постоянное двунаправленное соединение между клиентом и сервером, что идеально подходит для работы в реальном времени
Инструменты GraphQL
GraphQL-core (Python): Простые модели, прототипы.
Graphql-js (JavaScript): Кастомные решения, интеграция с JS.
Apollo GraphQL (JavaScript): Масштабные проекты, кэширование, авторизация.
GraphQL Yoga: Быстрый запуск, демонстрации.
Hasura: Авто API из БД, ускорение разработки.
p.s. Может усложнить запросы при большом количестве связанных данных о ж.-д. инфраструктуре. Избыточная гибкость GraphQL может привести к неоптимизированным запросам и проблемам с производительностью, если не контролировать.
#ИМ #ЦД #Синхронизация
👍3🔥3⚡2
1.1.2. WebSockets: Синхронизация ЦД и ИМ
Проблема: Односторонняя связь, задержки при передаче данных.
WebSockets: Двусторонняя связь, минимальные задержки.
Однако, сами по себе, WebSockets не решают всех проблем, связанных с синхронизацией ЦД и ИМ. Например, WebSockets не решают проблему структурирования данных (для этого нужен GraphQL, например). WebSockets не решают проблему хранения данных или управления правами доступа (здесь нужны другие инструменты и технологии).
Ключевые преимущества WebSockets
Связь
Двусторонняя, push-уведомления (ЦД <-> ИМ).
Задержки
Минимальные, для оперативных обновлений.
Соединение
Постоянное, без повторных запросов.
Обновления
Частые, мгновенное отображение изменений.
Инструменты WebSockets
Socket .IO (JavaScript)
Обеспечивает двусторонний обмен данными в реальном времени (положение поездов, состояние стрелок, и т.д.) между ЦД и веб-интерфейсом ИМ.
Websockets (Python)
Используется для обмена данными (статусы датчиков, управление устройствами) между бэкенд-сервером ЦД и ИМ.
WebSocketSharp (.NET):
Подключение WebSockets к компонентам ИМ или ЦД на .NET (например, симуляторы устройств, компоненты управления) для быстрой передачи данных.
p.s. Множество одновременных WebSocket-соединений может перегрузить сервер, особенно при большом количестве датчиков и устройств ж.-д. инфраструктуры. Сложно обрабатывать разрывы соединения, может быть сложно обеспечить порядок доставки данных при высокой частоте обновлений.
#ИМ #ЦД #Синхронизация
Проблема: Односторонняя связь, задержки при передаче данных.
WebSockets: Двусторонняя связь, минимальные задержки.
Однако, сами по себе, WebSockets не решают всех проблем, связанных с синхронизацией ЦД и ИМ. Например, WebSockets не решают проблему структурирования данных (для этого нужен GraphQL, например). WebSockets не решают проблему хранения данных или управления правами доступа (здесь нужны другие инструменты и технологии).
Ключевые преимущества WebSockets
Связь
Двусторонняя, push-уведомления (ЦД <-> ИМ).
Задержки
Минимальные, для оперативных обновлений.
Соединение
Постоянное, без повторных запросов.
Обновления
Частые, мгновенное отображение изменений.
Инструменты WebSockets
Socket .IO (JavaScript)
Обеспечивает двусторонний обмен данными в реальном времени (положение поездов, состояние стрелок, и т.д.) между ЦД и веб-интерфейсом ИМ.
Websockets (Python)
Используется для обмена данными (статусы датчиков, управление устройствами) между бэкенд-сервером ЦД и ИМ.
WebSocketSharp (.NET):
Подключение WebSockets к компонентам ИМ или ЦД на .NET (например, симуляторы устройств, компоненты управления) для быстрой передачи данных.
p.s. Множество одновременных WebSocket-соединений может перегрузить сервер, особенно при большом количестве датчиков и устройств ж.-д. инфраструктуры. Сложно обрабатывать разрывы соединения, может быть сложно обеспечить порядок доставки данных при высокой частоте обновлений.
#ИМ #ЦД #Синхронизация
👍4⚡2🔥2
1.1.3. Message Queues: Асинхронная Синхронизация ЦД и ИМ
Проблема (синхронная): Зависимость систем, риск перегрузок, сложность масштабирования.
Message Queues: Асинхронность, масштабируемость, надежность.
Ключевые преимущества Message Queues
Взаимодействие
Асинхронное (ЦД публикует, ИМ подписывается), без прямой зависимости.
Масштабирование
Распределение нагрузки, отказоустойчивость.
Надежность
Гарантированная доставка сообщений.
Подписчики
Несколько ИМ могут получать данные от одного ЦД.
Инструменты Message Queues
Apache Kafka
Высокопроизводительная платформа для обработки больших потоков данных (события, телеметрия, данные датчиков) для синхронизации ЦД и ИМ.
RabbitMQ
Гибкий брокер для различных типов сообщений (управление, события, статус устройств) в ИМ и ЦД, обеспечивая надежную доставку.
Redis Pub/Sub
Быстрая публикация-подписка, подходит для оперативных уведомлений (например, срочные события, оповещения) между компонентами ЦД и ИМ.
p.s. Некорректная настройка Message Queues может привести к потере сообщений или дублированию данных. Сложно обеспечить порядок доставки сообщений (например, строгое следование временной последовательности событий). Задержки при доставке сообщений могут повлиять на точность симуляции динамических процессов.
#ИМ #ЦД #Синхронизация
Проблема (синхронная): Зависимость систем, риск перегрузок, сложность масштабирования.
Message Queues: Асинхронность, масштабируемость, надежность.
Ключевые преимущества Message Queues
Взаимодействие
Асинхронное (ЦД публикует, ИМ подписывается), без прямой зависимости.
Масштабирование
Распределение нагрузки, отказоустойчивость.
Надежность
Гарантированная доставка сообщений.
Подписчики
Несколько ИМ могут получать данные от одного ЦД.
Инструменты Message Queues
Apache Kafka
Высокопроизводительная платформа для обработки больших потоков данных (события, телеметрия, данные датчиков) для синхронизации ЦД и ИМ.
RabbitMQ
Гибкий брокер для различных типов сообщений (управление, события, статус устройств) в ИМ и ЦД, обеспечивая надежную доставку.
Redis Pub/Sub
Быстрая публикация-подписка, подходит для оперативных уведомлений (например, срочные события, оповещения) между компонентами ЦД и ИМ.
p.s. Некорректная настройка Message Queues может привести к потере сообщений или дублированию данных. Сложно обеспечить порядок доставки сообщений (например, строгое следование временной последовательности событий). Задержки при доставке сообщений могут повлиять на точность симуляции динамических процессов.
#ИМ #ЦД #Синхронизация
🔥3⚡2👍2