1.2.3. Пакетная обработка (Batch processing)

Проблема
Необходимость обработки больших объемов данных, медленная обработка, ручная обработка, неэффективное использование ресурсов.

Суть
Batch processing - это метод обработки больших объемов данных, которые накапливаются в течение определенного периода времени, а затем обрабатываются единым пакетом, а не по отдельности.

Ключевые Преимущества
Эффективность. Оптимизация обработки больших объемов данных.
Ресурсоэффективность. Рациональное использование вычислительных ресурсов.
Простота. Легкость реализации для обработки больших наборов данных.
Контроль. Возможность управления процессом обработки.

Недостатки
Задержки в обработке, сложность отладки, не подходит для обработки в реальном времени, зависимость от ресурсов.

Инструменты
Apache Hadoop. Платформа для распределенной обработки больших наборов данных.
Подходит для обработки петабайтов данных, имеет открытый исходный код и большой выбор инструментов.
Apache Spark. Платформа для быстрой обработки данных.
Более высокая скорость обработки, чем Hadoop, особенно для итеративных задач и задач машинного обучения.
AWS Batch. Сервис для запуска пакетных задач в облаке AWS.
Полностью управляемый сервис, легко масштабируется и не требует управления собственной инфраструктурой.
OpenAI Cloud Batch. Сервис для пакетной обработки в облаке Google Cloud.
Аналог AWS Batch, но интегрирован в экосистему OpenAI Cloud.

Ключевая ценность
Оптимизация обработки больших объемов накопленных данных, таких как данные о перемещении составов или использовании инфраструктуры, что снижает затраты и улучшает аналитические возможности, которые часто нецелесообразно обрабатывать в реальном времени. Пакетная обработка позволяет эффективно использовать ресурсы для обработки больших массивов данных, в отличие от методов, которые могут быть неэффективны при больших объемах данных, обеспечивая возможность анализировать исторические данные и получать важные инсайты для улучшения планирования, управления и принятия решений. Это обеспечивает анализ большого объема накопленных данных, необходимый для выявления закономерностей и тенденций, которые могут быть не видны при обработке данных в реальном времени или с использованием других методов.

p.s. Пакетная обработка может вызывать значительные задержки при обработке данных, что делает ее непригодной для задач, требующих немедленной реакции. Отладка пакетных задач может быть сложной из-за большого количества данных и сложных процессов. Неправильная настройка может привести к неэффективному использованию ресурсов и замедлению работы системы.

#ИМ #ЦД #Синхронизация

Оборот вагона. Так быстро мы еще не ездили

Принятые меры в ноябре и тарифы декабря 2024 усилили тендеции в обороте вагона.

Участковая и техническая скорости в декабре показали свои пики (хоть и в пределах 1 км/ч) в рамках 2024 года (а раньше и поезда ездили быстрее).

Хорошо, конечно, что второй месяц подряд значение оборота вагона сокращается ("-2часа" из почти 21 суток на вагон) и инфраструктуру РЖД мы меньше занимаем, но на первое место выходит проблема неприема вагонов на пути общего пользования и это при падающей погрузке.

Больше 1/3 месяца вагон стоит под грузовыми операциями ("+5,5%" декабрь/ноябрь) и это практически половина от всего оборота вагона. И судя по всему в этом месяце проблема только усугубится.

1.2 Прямая синхронизация ИМ+ЦД -> Scheduled

Синхронизация данных происходит через определенные интервалы времени или в заданное время. Подходит для пакетной обработки и ситуаций, когда не требуется мгновенная реакция на изменения.

Плюсы:

Низкая нагрузка. Данные синхронизируются периодически, что снижает нагрузку на системы по сравнению с синхронизацией в реальном времени.

Простота реализации. Обычно проще настроить, чем реальную синхронизацию или сложные event-driven системы.

Хорошо подходит для некритических данных. Подходит для данных, которые не требуют мгновенного обновления (например, архивы данных).

Минусы:

Задержка данных. Данные обновляются с задержкой, что может снизить актуальность цифрового двойника.

Не подходит для критических процессов. Не подходит для ситуаций, где требуется мгновенная реакция на изменения.

Проблемы с согласованностью данных. Если данные изменяются часто, то при периодической синхронизации могут возникать проблемы с их согласованностью.

Краткая сводка:

Скрипты
Для простых задач синхронизации, требующих гибкости и быстрой разработки.

Cron Jobs/Task Schedulers
Для автоматизации запуска задач синхронизации по расписанию.

Batch processing
Для обработки больших объемов данных, требующих масштабируемой и производительной обработки.

#ИМ #ЦД #Синхронизация

2.1. Шины сообщений (Message Buses):

Проблема
Разрозненность систем, зависимость сервисов, сложность масштабирования, неэффективное использование ресурсов.

Суть
Message Buses - это программная инфраструктура, которая позволяет различным приложениям и сервисам обмениваться данными асинхронно, снижая связность между ними.

Ключевые Преимущества
Асинхронность. Независимость отправителя и получателя сообщений.
Масштабируемость. Легкое добавление новых сервисов и устройств.
Надежность. Гарантированная доставка сообщений.
Гибкость. Поддержка различных форматов данных.

Недостатки
Сложность настройки, мониторинга и отладки, задержки при доставке сообщений, требуется дополнительная инфраструктура.

Инструменты
RabbitMQ. Популярный брокер сообщений с открытым исходным кодом.
Гибкость настройки и поддержка различных протоколов, надежная доставка сообщений.
Kafka. Платформа для потоковой обработки данных.
Высокая пропускная способность и отказоустойчивость, подходит для обработки больших объемов данных.
ActiveMQ. Мультипротокольный брокер сообщений.
Поддержка широкого спектра протоколов и функций, что делает его универсальным решением.
ZeroMQ. Библиотека для обмена сообщениями с открытым исходным кодом.
Высокая производительность и минимальные накладные расходы, подходит для создания кастомных решений.

Ключевая ценность
Асинхронный обмен данными между различными системами, такими как системы управления движением, контроля состояния инфраструктуры и управления ресурсами, что повышает гибкость и отказоустойчивость производственной программы. Шины сообщений позволяют интегрировать различные компоненты, снижая их зависимость друг от друга, что обеспечивает возможность масштабировать систему, не влияя на уже работающие сервисы. Это обеспечивает более надежную и гибкую интеграцию разнородных систем, что снижает риск сбоев и упрощает модернизацию. В отличие от систем с прямой синхронизацией, где отказ одного компонента может вызвать цепную реакцию, шина сообщений позволяет системам работать независимо друг от друга, что повышает общую устойчивость инфраструктуры.

p.s. Сложная настройка и мониторинг шины сообщений могут привести к трудностям при внедрении и обслуживании. Задержки при доставке сообщений могут повлиять на работу систем, требующих быстрой реакции. Неправильная конфигурация может привести к потере данных или дублированию сообщений.

#ИМ #ЦД #Синхронизация

2.2 Webhooks

Проблема
Необходимость постоянных запросов API для получения новых данных, неэффективное использование ресурсов, задержки, высокая нагрузка.

Суть
Webhooks - это механизм, позволяющий ЦД отправлять уведомления в ИМ при наступлении определенного события, вместо того чтобы постоянно опрашивать API.

Ключевые Преимущества
Реактивность. Мгновенная доставка уведомлений о событиях.
Эффективность. Снижение нагрузки на сервер за счет отказа от постоянных опросов.
Простота. Легкость настройки и использования.
Асинхронность. Независимость отправителя и получателя уведомлений.

Недостатки
Сложности с доставкой уведомлений, ограниченный контроль над процессом доставки, проблемы с безопасностью, сложность отладки.

Инструменты
Любой веб-сервер (Apache, Nginx). Для приема HTTP-запросов от Webhooks.
Базовая возможность для приема запросов.
Веб-фреймворки (Flask, Express.js, Django). Для создания API-эндпоинтов, принимающих Webhook-запросы.
Управление HTTP-запросами, маршрутизация, обработка данных, проверка подписи запроса.
GitHub Webhooks. Для автоматизации процессов в репозиториях GitHub.
Интеграция с сервисами CI/CD, уведомления об изменениях в репозиториях.
Slack Webhooks. Для отправки уведомлений в каналы Slack.
Уведомления о событиях, интеграция с внутренними системами.
Zapier. Платформа для автоматизации задач и интеграции приложений.
Универсальная интеграционная платформа, гибкая настройка.
IFTTT (If This Then That). Платформа для автоматизации задач и интеграции приложений.
Простота в настройке для интеграции личных приложений и устройств.

Ключевая ценность
Мгновенное получение уведомлений об изменениях в ЦД, таких как результаты тестирования новых элементов инфраструктуры или изменения в планах реализации проектов, что позволяет своевременно корректировать планы развития, избегать задержек и минимизировать риски при реализации производственной программы развития. Webhooks обеспечивают быструю доставку критически важных уведомлений без постоянных опросов API, что позволяет снизить нагрузку на сервер и обеспечивает немедленную реакцию на важные изменения в проекте, в отличие от систем, которые работают по принципу опроса и могут запаздывать с получением важной информации. Это позволяет быть в курсе всех изменений, что способствует более эффективному управлению и своевременной адаптации к изменениям в производственной программе развития.

p.s. Проблемы с доставкой уведомлений могут привести к потере важных данных и задержкам в работе. Сложности с отладкой Webhooks могут потребовать дополнительного времени и усилий. Неправильная настройка безопасности может привести к несанкционированному доступу к данным.

#ИМ #ЦД #Синхронизация

3.1 ETL-процессы (Extract, Transform, Load)

Проблема
Разнородные источники данных, несовместимость форматов, некачественные данные, сложность анализа.

Суть
ETL-процесс - это последовательность шагов, включающая извлечение данных из ЦД, их преобразование (очистка, форматирование) и загрузку в целевое хранилище (ИМ) для дальнейшего использования.

Ключевые Преимущества
Консолидация. Сбор данных из разных источников в одном месте.
Преобразование. Очистка и стандартизация данных.
Аналитика. Возможность проведения комплексного анализа данных.
Качество. Повышение качества данных для принятия решений.

Недостатки
Сложность настройки, длительное время обработки, требуется дополнительная инфраструктура, проблемы с масштабированием.

Инструменты
Apache NiF. Потоковая обработка и интеграция данных.
Визуальный интерфейс, удобство интеграции с различными источниками.
Apache Airflow. Планирование и оркестрация рабочих процессов.
Мощный инструмент для сложных ETL-процессов, работа с DAG.
Informatica PowerCenter. Коммерческое решение для интеграции данных.
Широкий набор функций, но требует лицензирования.
Talend Open Studio. Открытый инструмент для ETL-процессов.
Удобный интерфейс, открытый исходный код.

Ключевая ценность
Консолидация данных из различных источников, таких как системы управления инфраструктурой, планирования ресурсов и финансовой отчетности, обеспечивая единую картину для анализа эффективности и принятия стратегических решений в рамках производственной программы развития. ETL-процессы позволяют привести разрозненные данные к единому формату, что позволяет проводить комплексный анализ и получать полезную информацию. Это позволяет отслеживать прогресс производственной программы развития, выявлять узкие места и оптимизировать распределение ресурсов, в отличие от работы с отдельными источниками данных, которые могут не давать полной картины.

p.s. Сложность настройки и длительное время обработки могут привести к задержкам в получении аналитических данных. Неправильная настройка ETL-процессов может привести к потере или искажению данных. Для поддержки ETL-процессов может потребоваться дополнительная инфраструктура.

#ИМ #ЦД #Синхронизация

3.2 CDC (Change Data Capture)

Проблема
Необходимость отслеживать изменения данных в реальном времени или с минимальной задержкой, неэффективность полных загрузок, риск потери изменений.

Суть
Отслеживание изменений.

Ключевые Преимущества
Реальное время. Отслеживание изменений с минимальной задержкой.
Эффективность. Снижение нагрузки на источники данных.
Точность. Гарантированная доставка изменений данных.
Актуальность. Поддержка актуальных данных в целевой системе.
Недостатки. Сложность настройки, требуется дополнительная инфраструктура, проблемы с масштабированием, сложность отладки.

Инструменты
Debezium. Открытая платформа для захвата изменений данных.
Поддержка различных баз данных, легко масштабируется, хорошо интегрируется с Kafka.
Apache Kafka Connect. Инструмент для потоковой передачи данных.
Поддержка CDC-коннекторов, высокая пропускная способность, масштабируемость.
AWS DMS (Database Migration Service). Сервис миграции и захвата изменений данных от AWS.
Полностью управляемый сервис, простота использования, поддержка различных баз данных.
Oracle GoldenGate. Коммерческое решение для CDC.
Широкий спектр функций, но требует лицензирования, используется для гетерогенных сред.

Ключевая ценность
Обеспечение своевременного и точного обновления данных в целевых системах, таких как аналитические платформы, системы управления ресурсами и системы мониторинга инфраструктуры, позволяя иметь целостную и актуальную картину. CDC позволяет отслеживать изменения в данных с высокой точностью и минимальными потерями, что позволяет оперативно получать полную и достоверную информацию о всех изменениях.

p.s. Сложная настройка и управление CDC могут потребовать значительных усилий и ресурсов. Неправильная конфигурация CDC может привести к потере или некорректной доставке изменений данных. CDC может создавать дополнительную нагрузку на базы данных источников.

#ИМ #ЦД #Синхронизация

Оценка методов синхронизации для транспортой инфраструктуры: как выбрать решение, обеспечивающее масштабируемость, безопасность и простоту интеграции

Какие методы рассматривались?

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 (Change Data Capture)

Критерии оценки (бальная оценка от 1 до 5):

1. Скорость синхронизации: задержка передачи данных.
2. Масштабируемость: легкость добавления новых компонентов.
3. Надежность: гарантия доставки данных.
4. Сложность настройки: трудоемкость внедрения и обслуживания.
5. Гибкость: поддержка разных форматов и систем.
6. Применимость к производственной программе развития: Насколько метод подходит для задач, связанных с развитием, а не только с операционной деятельностью (например, интеграция данных для аналитики, планирования, принятия стратегических решений).
7. Уникальная ценность для транспортной инфраструктуры: уникальный вклад.
8. Безопасность: защита от угроз.
9. Стоимость: общая стоимость владения.
10. Простота интеграции: насколько легко интегрировать метод с существующими системами и технологиями.
11.Обрабатываемые объемы данных: эффективность при разных объемах данных.
12. Требуемые ресурсы: требования к вычислительной мощности.
13. Совместимость с существующей инфраструктурой: легкость интеграции с текущими системами.
14. Потенциальные риски: уровень потенциальных рисков, связанных с внедрением.
15. Долгосрочная перспектива: актуальность в будущем.
16. Влияние на общие бизнес-процессы: оценка влияния каждого метода на общую эффективность бизнес-процессов, производительность, время принятия решений.
17. Жизненный цикл: оценка полного жизненного цикла внедрения и использования метода.

Какие у меня получились результаты?

1.1.1,1. REST API: 3.70
1.1.1,2. GraphQL API: 3.78
1.1.2. WebSockets: 3.41
1.1.3. Message Queues: 4.29

Хорошо подходит для асинхронного обмена данными, обеспечивает надежность, но может иметь задержки

1.1.4. OPC UA: 3.41
1.1.5. MQTT: 4.04

Подходит для интеграции данных от IoT-устройств, обеспечивая эффективность при низкой пропускной способности, но может иметь задержки при передачи больших объемов данных.

1.2.1. Скрипты: 3.41
1.2.2. Планировщик задач: 3.48
1.2.3. Пакетная обработка: 3.67
2.1. Шины сообщений: 4.00

Идеальны для интеграции множества систем и источников данных для цифровых двойников, но требуют сложной настройки.

2.2. Webhooks: 3.67
3.1. ETL-процессы: 3.67
3.2. CDC: 3.74

Будущее имитационного моделирования: рост рынка до 24 миллиардов долларов.

Объем рынка программного обеспечения для моделирования оценивается в 13,58 млрд долларов США в 2024 году (ощущаете объем и перспективу?) и, как ожидается, достигнет 24 млрд долларов США к 2029 году, а среднегодовой темп роста составит 12,06% в течение прогнозируемого периода 2024-2029 гг.

В России многим знакома компания The AnyLogic Company. Их флагманский продукт Anylogic – программное обеспечение по имитационному моделированию для бизнес-приложений. Является универсальным инструментом поддержки принятия решений для любой отрасли. Поддерживает все существующие методы имитационного моделирования: системная динамика, дискретно-событийное, агентное.

Предполагаемый годовой доход компании AnyLogic в настоящее время составляет 25,4 млн долларов в год.

Ближайшие конкуренты:
- MathWorks - преполагаемая выручка $1267,3 млн;
- AVEVA - $1132,9 млн;
- Wolfram Research - $148,8 млн;
- Maplesoft - $26,8 млн;
- Famic Technologies - $17,5 млн;
- Lanner - $11,2 млн;
- Flexsim Software Products - $7,8 млн;
- 5Simio - $7,2 млн;
- Phoenix Integration - $6,7 млн;
- TETCOS - $6 млн;
- Sparx Systems - $4,2 млн;
- CYME International TandD - $3,9 млн;
- INCONTROL Simulation Software - $2,6 млн;
- Plexim - $2,6 млн;
- Ingrid Cloud - $2,5 млн;
- Ventana Systems - $2,5 млн;
- Northwestern University - $1,6 млн;
- Imagine That - $0,5 млн;
- SIMUL8 Corporation - $0,5 млн;
- Azore Software - $0,3Млн.

Ранее писал о нюансах при создании имитационной модели в AnyLogic касаемо ж.-д. инфраструктуры.

Накопление: Операция, Условие или Барьер? 🤔

Бывает нужно накопить сил для выполнения работы. Чем является это “накопление”? В симуляции процессов мы тоже сталкиваемся с накоплением, и что это на самом деле – операция, условие или барьер?

📌 Операция vs. Условие:

Операция – это задача для выполнения, требующая времени и ресурсов.
Условие – это необходимое требование для начала операции.
Накопление — это и то, и другое! Как операция — её можно измерить, а как условие — оно определяет начало следующих действий.

🚧 Накопление как Барьер:

Накопление – это место в технологической цепочке, где накапливаются ресурсы.
Оно не тормозит процесс напрямую, а препятствует началу следующей операции и запускает новый виток по технологической цепочке.
Это своего рода “бутылочное горлышко”, требующее правильного управления.

Получается это и первое, и второе, и третье - полноценный обед.

Для пользователя накопление - это конечно в первую очередь операция, мы задаем её параметры в исходных данных и собираем по ней статистику.

Для алгоритмов симуляции - это в первую очередь условие. Хотя стоит отметить, что в алгоритмах накопление появляется в различных расписаниях для операций (предварительном и модельном - интересно про них узнать ставьте задумчивые смайлики) с пометкой о вариантности.
Кстати о вариантности. Для качественной симуляции накопление стоит задавать в нескольких вариантах (разное количество ресурса можем копить) и для каждого варианта нужно прописать свое окончание по технологической цепочке.

Ну и финально мы подходим к тому, что накопление “философски?” можно воспринимать и как барьер. Да? Нет? Пишите 👇.

#Про_ИК #накопление

Мы впереди планеты всей? Или топ-10 самых дорогих планов ж.-д. строительства!

В 2024 году в мире развернулось масштабное железнодорожное строительство с общим объёмом капиталовложений почти в $390 млрд на 205 проектов.
Хотя в 2023 году было запущено 250 проектов стоимостью ~$250млрд.

Вашему вниманию предоставляется топ-10 самых дорогостоящих проектов:

10 место: Высокоскоростная ж/д Чжанчжоу — Шаньтоу (Китай) стоимостью $5.65 млрд. Новая линия длиной 176 км сократит время в пути и усилит транспортную инфраструктуру региона. Ожидаемое завершение — 2028 год.

9 место: Расширение ж.-д. сети BART в Кремниевой долине (США) — $6.8 млрд. 9.7 км новой линии с четырьмя станциями и 8-километровым тоннелем через Сан-Хосе. Завершение запланировано на 2037 год.

8 место: Железнодорожная линия Лагос — Калабар (Нигерия) стоимостью $7.82 млрд. Проект протяженностью 1402 км свяжет столицу с южным портовым городом. Ожидаемое завершение — 2028 год.

7 место: Транзитный коридор Западного отделения Санта-Аны (США) — $8.5 млрд. 31 км новой легкорельсовой линии в Лос-Анджелесе. Завершение запланировано на 2036 год.

6 место: Высокоскоростная ж/д Вэйфан–Суцянь (Китай) — $8.85 млрд. 324 км новой линии в провинции Шаньдун. Завершение планируется к концу 2027 года.

5 место: Высокоскоростная ж/д Хэфэй–Ухань (Китай) — $11.28 млрд. 360 км высокоскоростной магистрали между двумя столицами провинций. Завершение ожидается к середине 2028 года.

4 место: Высокоскоростной ж.-д. коридор в Неваде (США) — $12 млрд. 350 км двухпутной линии свяжут Лас-Вегас и Лос-Анджелес. Завершение запланировано на 2028 год.

3 место: Линия 19 Шанхайского метрополитена (Китай) — $13.14 млрд. 46 км новой линии метро разгрузит перегруженные участки города. Завершение ожидается к концу 2030 года.

2 место: Юго-восточный высокоскоростной ж.-д. коридор (США) — $16 млрд. Масштабный проект улучшит железнодорожное сообщение в нескольких штатах, включая модернизацию путей и новые мосты. Завершение запланировано на конец 2026 года.

1 место: Высокоскоростная ж/д Москва — Санкт-Петербург — $24.25 млрд. 680 км высокоскоростной магистрали соединят две столицы. Завершение ожидается к 2028 году.

RWS

Какую методологию управления использует успешный проект?

Skolkovo представило результаты масштабного исследования современных практик управления проектами, охватившего период с 2022 по 2024 год. 320 экспертов проанализировали 341 проект из 23 отраслей, чтобы выявить главные тренды и факторы успеха. Но что на самом деле делает проект успешным?

Что такое “успех” проекта?
В рамках исследования, успешность проекта определялась как его завершение в срок, в рамках бюджета и с достижением запланированных целей.

Исследование выявило неожиданного лидера:
1. Kanban: 59,2% успешности
2. Своя методология на основе Agile-принципов: 57,3%
3. Scrum: 54%
4. Корпоративная методология, общая для всех проектов: 53,3%
5. Своя методология, разработанная на основе итеративной разработки продукта: 52,6%
6. Своя методология, разработанная на основе предиктивного подхода (Waterfall): 47%
7. Никакая методология не использовалась: 33,3%

Почему Kanban?
Эксперты связывают успех Kanban с его простотой внедрения, высокой степенью визуализации процесса и фокусом на непрерывной поставке ценности. Kanban особенно эффективен в проектах с четко определенными задачами и высокой степенью прозрачности, где важна гибкость в управлении потоком работ.

Секрет “своей” Agile-методологии:
Интересно, что второе место занимает “своя методология на основе Agile-принципов”. Это говорит о том, что компании все чаще адаптируют Agile-фреймворки под свои конкретные нужды, используя лучшие практики из Scrum, Kanban и других подходов. Ключевым фактором успеха является частая обратная связь с заказчиком и итеративная разработка.

Разрушение мифов:

Исследование также разрушает несколько устоявшихся мифов об управлении проектами:
• Миф: “Чем больше регламентов и инструкций, тем успешнее проект.” Результаты показывают, что жесткие корпоративные стандарты часто сковывают инициативу и снижают скорость работы, в то время как гибкие и адаптивные подходы позволяют командам быстрее реагировать на изменения.

• Миф: “Предиктивные подходы (Waterfall) устарели.” Несмотря на низкий процент успешности по сравнению с Agile, Waterfall все еще может быть эффективен в проектах с четкими требованиями и стабильной средой.

Конечно не существует универсального рецепта успеха, и компании должны постоянно экспериментировать, адаптировать и улучшать свои практики управления проектами. Какую методологию управления проектами вы используете и почему?

Моделирование как искусство решения конфликтов

Считаем, что конфликт – это требование одного и того же ресурса в разные операции.
Какой операции отдать ресурс, а какой ждать освобождения ресурса?

Такие задачи возникают в управлении производственными линиями, конечно и в управлении движением на транспортной инфраструктуре, в планировании IT-инфраструктуры и даже в повседневном планировании.

Существуют десятки эвристик и методов распределения ресурсов. Но все они ломаются на простом примере. О нем позже.

Для своего имитационного комплекса у меня разработаны 3 алгоритма.

1. Матрица враждебности. Определяет все (!) враждебности– ищет оптимальное решение.
Алгоритм плох тем, верхняя и точная границы асимптотической временной сложности зашкаливают. Бывало на сутки оставлял просчитать модель. Может в будущем при наличии ресурсов можно будет подключить нейронки.

2. Два других хорошо совмещают в себе большинство эвристик и дают прогнозируемые погрешности. Алгоритмы сортируют операции и захватывают ресурсы согласно эвристикам упорядочивания (назову этот так... В целом суть захвата в том, чтобы не все ресурсы сразу присвоить, а по частям - для уменьшения количества циклов проверки враждебных операций). При этом используется 2 буфера для сбора операций и производится только бинарное рассмотрение враждебности. Чем хороши и плохи эти алгоритмы? Они очень быстрые и дают хорошо прогнозируемые погрешности.

Итак, что за пример где начинает все ломаться?

У нас есть 4 операции: 1, 2, 3, 4.
Ресурсы, которые может использовать операция (операция-ресурс):
1-а, 2-а или 2-б, 3-б или 3-в, 4-в.
Да, всего 4 операции и 3 ресурса! Все операции хотят реализоваться, но не получиться...Кого задержим?

Немного деталей:

Операций с одинаковым значением приоритета и времени заявки – нет. При этом считаем, что операции при реализации имеют общий интервал времени (т.е. в определенный интервал времени требуется занятие всех ресурсов: а, б, в).
Приоритет – условная важность операции, а время заявки – момент, когда операция заявляет о своей потребности в ресурсах.

Как распределить ресурсы между операциями?

Возьмем для примера ситуацию №1 (можно менять условия для того, чтобы любое правило можно было сломать; поломка - недостижение очевидного результата для человека).

Упорядочивание операций по времени заявки (от самой ранней операции к самой поздней): 3, 4, 2, 1.
Упорядочивание операций по приоритету (от операции с наибольшим приоритетом к операции с наименьшим): 3, 2, 1, 4.

Матрица враждебности в этой и аналогичной ситуации справляется на 100% (но на сложных моделях устраивает перекур в процессе расчетов). Алгоритмы эвристик справляются в 33% случаев так же, в других могут задержать более приоритетную операцию (из примера - 1ую), что в целом не так значительно, хоть и на предельных объемах данных могут выдавать много некритичных ошибок. При этом открывается поле возможностей по оптимизации распределения ресурсов от учета человеческого фактора до адаптивной системы управления, которая оптимизирует использование ресурсов по различным критериям.

Есть идеи как распределить ресурсы?👇

p.s. Мы то с вами понимаем, что все операции можно реализовать параллельно друг другу и только операцию 4 – задержать. Алгоритмы и эвристики заранее не знают, что к ним попадает на вход.

Доверие к результатам

Можно ли доверять имитационному моделированию? Здесь писал про 8 шагов к точной и достоверной имитационной модели. В симуляциях, где используются миллионы вычислений, даже небольшие ошибки округления могут накапливаться и приводить к неверным результатам. Поэтому важно понимать, как работают наши инструменты и насколько им можно доверять.

Давайте сегодня проверим доверие к привычным вещам. Доверяете ли вы своему калькулятору?

Проверьте у себя в телефоне: (10^13)+1-(10^13)
🔥 – если результат «0», ❤️ – если «1».

В некоторых андроидах можно получить верный результат. Почему?
Все благодаря работе Ханса-Юргена Бёма с рекурсивной вещественной арифметикой (RRA).
Главная идея заключается в том, что для быстрого и точного результата необходимо использовать следующее окончательное представление чисел: рациональное, умноженное на вещественное, где вещественное — это RRA-вещественное или символьное вещественное.

Здесь можно ознакомиться со статьей Ханса-Юргена Бёма про создание API для работы с реальными числами, обеспечивающего точные и понятные результаты. Исследование направлено на улучшение точности и математических свойств вычислений.

Защита данных связанных с безопасностью движения поездов для имитационной модели

Данным, описывающим инфраструктуру ж/д, расписание движения поездов и др. критическую информацию, утечка которой может поставить под угрозу безопасность движения необходима защита как от внешних, так и от внутренних угроз.

В главных ролях:
📍 ЦУП: Центр управления перевозками, источник данных, связанных с безопасностью движения поездов. Данные будет отправлять не прямо ЦУП, а определенный сервер, но в пояснениях ниже будет фигурировать именно эта аббревиатура.
📍 ИМ: Имитационная Модель, использующая эти данные для моделирования и анализа.

Подходы к защите данных:

1. Trusted Execution Environment (TEE):
Использование защищённых анклавов TEE для хранения и обработки конфиденциальных данных ЦУП. Основной принцип – изоляция кода и данных в защищенной аппаратной среде.

Как гарантировать целостность данных?
Проводим аттестацию TEE для верификации кода ИМ, которая включает в себя проверку хеша кода, выполняемого в анклаве, и подписи производителя TEE.

Недостаток: Зависимость от конкретного производителя TEE. Возможные решения:
- Использование аппаратных модулей безопасности.
- Децентрализованные решения для аттестации.

2. Oblivious Transfer (OT):
Использование протокола OT для передачи данных ЦУП к ИМ без раскрытия конфиденциальной информации.

Реализация OT 1 out of 2 на основе протокола Диффи-Хеллмана (Меркла):

1. ЦУП отправляет ИМ A = g^a (mod p), где g – порождающий элемент циклической группы, a – секретное случайное число, p - простое число.

2. ИМ, в зависимости от бита c ∈ {0, 1}, отправляет ЦУП B = g^b (mod p) (если c = 0) или B = Ag^b (mod p) (если c = 1), где b – секретное случайное число.

3. ЦУП вычисляет K_0 = B^a (mod p) и K_1 = (B/A)^a (mod p).

4. ЦУП шифрует m_0 ключом K_0 и m_1 ключом K_1, отправляя x_0 = Enc_{K_0}(m_0) и x_1 = Enc_{K_1}(m_1) ИМ.

5. ИМ вычисляет K = A^b (mod p) и расшифровывает x_c, получая m_c.

Реализация OT 1 out of n:
Наивный подход: n раз OT 1 out of 2. Сложность O(n).
Более сложные схемы: log_2(n) OT 1 out of 2.
OT Extensions: “Предварительная зарядка” энтропией для быстрого выполнения OT 1 out of n.

Использование OT в сервисе ИМ:
Групповой запрос: ИМ формирует запрос, включающий индекс j (номер запрашиваемого параметра) и N-1 случайных индексов (N > 1). ЦУП, используя данные, соответствующие всем N индексам, возвращает соответствующие значения.
OT 1 out of n для выбора истинных данных m_j из возвращенного множества.

3. Secret Sharing
Разделение конфиденциальных данных ЦУП на доли (shares) между несколькими компонентами (возможно, распределенными между несколькими экземплярами ИМ).

Используем схему Шамира: чтобы разделить секрет s на n долей, необходимых для восстановления k долей (k <= n):

1. Выбирается случайный полином степени k-1:
f(x) = s + a_1*x + a_2*x^2 + ... + a_{k-1}*x^{k-1} (mod p)
где s - секрет, a_i - случайные коэффициенты, p - простое число больше чем s и все возможные значения x.

2. Генерируются n долей, вычисляя значения полинома в разных точках:
share_i = f(i) для i = 1, 2, …, n

3. Для восстановления секрета необходимо собрать k долей и использовать интерполяцию Лагранжа:
s = f(0) = Σ (share_i * L_i(0)) для i = 1, 2, …, k
где L_i(x) - полином Лагранжа, определяемый как:
L_i(x) = Π [(x - x_j) / (x_i - x_j)] для всех j ≠ i, где x_j - координаты собранных долей.

Для восстановления данных необходима комбинация достаточного количества долей. Еще можно использовать Multi-Party Computation для вычислений над долями без их восстановления. Это позволит ИМ проводить вычисления над данными без прямого доступа к исходным значениям, хранящимся у ЦУП.

Ну и дежурная фраза: "выбор конкретного подхода зависит от требуемого уровня безопасности, производительности, сложности реализации и затрат." А в комментариях я написал эксперементальную версию для объяснений за бутылкой. И помните про риски, связанные с зависимостью от конкретных технологий (vendor lock-in) и потенциальные атаки на систему защиты, в контексте взаимодействия между ЦУП и ИМ.

Все данные о ж/д в руке

Буквально можно записать все данные о ж/д на несколько дисков, которые поместятся в руке.

Такое хранилище данных назвали «5D optical data storage». Концепция конечно не нова, она экспериментально продемонстрирована в 2013 году.

Хранилище представляет собой экспериментальное наноструктурированное стекло для постоянной записи цифровых данных с помощью фемтосекундного лазерного письма. Диски, использующие эту технологию, могут хранить до 360 терабайт данных (на 12-сантиметровом диске) в течение миллиардов лет.

Название связано с тем, что для записи по всему объёму носителя используются два оптических измерения и три пространственные координаты: 3 измерения (X, Y, Z) – позиция точки внутри кристалла (обычное трёхмерное пространство); 4-е измерение – ориентация поляризации (под каким углом светил лазер); 5-е измерение – интенсивность лазерного импульса (насколько сильное изменение структуры произошло). Таким образом, информация кодируется сразу по 5 параметрам, и это позволяет записывать огромные объёмы данных в крошечном объёме.

Сейчас идет коммерциализация технологии оптического хранения данных компанией OpteraData. Они утверждают, что сделают оптические диски с ёмкостью 10 ТБ за 1 доллар к 2030 году.

Перспективы конечно захватывают, надеюсь на удачные реализации проектов.

Разделяй и властвуй

Алгоритмы, составляющие фундамент современной IT отрасли, часто кажутся плодом новейших разработок. Однако, если присмотреться внимательнее (или просто загнаться как я собственно и сделал), то принципы увидим и в древних писаниях.

В качестве примера предлагаю вспомнить сортировку слиянием, быструю сортировку и бинарный поиск. Это проявления парадигмы “Разделяй и властвуй”: разбить задачу, рекурсивно решить подзадачи, объединить результаты.

Сортировка слиянием Джона фон Неймана (1945) - один из первых алгоритмов, формализовавших этот принцип. А использование рекурсии при разделении предложил еще Евклид (300 г. до н.э., хотя задача про нахождение наибольшего общего делителя двух целых чисел, но я про сам принцип).

Идея разделения сложного на простое стара как мир. В политике и военном деле “Разделяй и властвуй” применялась тысячелетиями. Трактат Сунь Цзы “Искусство войны” (IV век до н.э.) пронизан этой идеей: дробление сил, использование противоречий:

📍 Избегай сильного, атакуй слабое. Сунь Цзы запротоколировал нам о необходимости тщательно выбирать момент и место для атаки, чтобы не столкнуться с превосходящими силами противника. Он рекомендует искать уязвимости и разделять врага (задачи), чтобы затем поражать его по частям. Что из "современного" сюда еще подходит?

A/B-тестирование в маркетинге. Выбираем наиболее эффективный вариант рекламного сообщения, "атакуя" тех, кто готов "купиться".

📍 Познай врага и познай себя, и тогда в ста битвах не будет опасности. Сунь Цзы призывает нас использовать любые разногласия, конфликты и слабые места внутри вражеского лагеря для ослабления его и облегчения победы.

Алгоритмы машинного обучения для анализа данных. В КБ алгоритмы анализируют сетевой трафик и выявляют аномалии, чтобы "познать" структуру и поведение атакующих и эффективно защитить сеть.

📍 Когда поднимаешься, не показывай вида; когда двигаешься, наноси удар по его слабостям. Существенным элементом стратегии “Разделяй и властвуй” является нарушение связи и координации между частями вражеской армии. Сунь Цзы доносит до нас важность дезинформации, саботажа и других методов, направленных на создание хаоса и неразберихи в рядах противника.

Использование криптографии для защиты коммуникаций. Шифрование скрывает смысл передаваемых сообщений, затрудняя противнику понимание наших намерений и координацию своих действий.

Хотите разобраться с алгоритмами, понять фундаментальный подход? Читайте классиков)

Что влезет - то влезет: Создание реалистичного входящего потока в имитационных моделях

В настоящее время активно занимаюсь переработкой своего имитационного комплекса для моделирования транспортной инфраструктуры необщего пользования (нп).

Ключевая цель проекта – радикально ускорить и повысить эффективность моделирования. В ближайшие 3 года стоит задача создания любой транспортной модели нп за одну неделю, а через 6 лет стремлюсь к моментальному синтезу имитационной модели.

Что мы сейчас делаем?
Занимаемся оптимизацией алгоритмов, автоматизацией логики построения моделей, расширением и детализацией функционала, а также улучшаем дизайн комплекса.

Одним из элементов симуляции является создание входящего потока в транспортную систему. Детерминированные потоки, конечно, важны, но сегодня я хочу поделиться опытом работы со стохастическими потоками.

Входящие стохастические потоки в транспортную систему достаточно достоверно можно описать с помощью распределения Пуассона для водного транспорта и распределения Эрланга для автомобильного и железнодорожного транспорта.

В данном посте делюсь результатами тестирования Эрланговского распределения для железнодорожного транспорта.

В процессе тестирования я исследовал влияние различных параметров Эрланговского распределения на загрузку инфраструктуры, точность и прозрачность имитации (отсутствие черных ящиков с точки зрения пользователя).

Остановился на варианте, который я условно называю «что влезет – то влезет», где приоритетом является анализ влияния случайности, а не максимальная пропускная способность.

Это подразумевает, что само распределение Эрланга некорректируется в симуляции. Вместо этого,отслеживаются смещения заявок и решения враждебностей, что позволяет исследовать влияние случайности, заложенной в распределении на пропускную способность объекта топологии. Такой подход позволяет получить более реалистичную картину работы системы и выявить проблемные места, требующие особого внимания при проектировании и управлении.

На чем решил остановиться по итогам тестирования:

1. Номера операций в отчетах по результатам симуляции должны идти не по порядку, а в соответствии принадлежности к временно́му диапазону Эрланговского распределения (например, с 1 до 10) из исходных данных.
Помогает понять, что произошло при имитации, для последующих настроек модели.

2. Расчетные интервалы по Эрлангу между поездами могут выбивать поезда из своих временных диапазонов. Хотя и можно уместить все заявки в исходных диапазон, но это уже не случайность тогда.
Случайность в первую очередь, пропускная способность во вторую.

3. При наложении операций в подводе (решаем враждебность, а не корректируем распределение) используем изменение подвода. Типо на предыдущей станции сначала хотели отправить, потом передумали, и это «передумали» на всякий случай записываем в отчет как изменение подвода.

Итого: создаем Эрланговское распределение по исходным данным, сортируем заявки в предварительном расписании, в модельном расписании распределяем ресурсы под заявки.

Пример учета решений: 1 категория поездов, состоящая из 10 заявок на интервал с 1 до 12 и 10 заявок на интервал с 12 до 23. По итогам симуляции мы можем увидеть 20 последовательно выполненных заявок (и последующих за ними операций). Но если заявки выпадают из интервала, хотелось бы это знать наверняка. Поэтому в ПР даем нумерацию заявок 1-10 в интервале [1-12] и 11-20 в [12-23]. При выходе заявок 1-10 из 1-ого интервала и попадании во 2-ой интервал мы можем увидеть последовательность: «…6, 12, 7, 13 …», что явно укажет на то, что заявки сместились даже на большом количестве данных. 6 заявка может при этом подвинуть 12 заявку в соответствии с решением враждебности и важно мы не меняем само распределение, а корректируем расписание в ходе симуляции. По факту конечно разницы нет, но результат корректировки записывается в отчет, а следовательно, принцип «учет и контроль» сохранён.

В комментариях приложил файлы:
График исполненной работы в *.noscript (открывается в браузере)
Занятие ресурсов под операции в *.xlsx.
ЛИКБЕЗ.

4️⃣ из 8️⃣ проектов РЖД, реализуемых в рамках ИЦК «Железнодорожный транспорт и логистика», полностью завершены. Об этом сообщил заместитель гендиректора компании Евгений Чаркин в ходе Демо-дня ИЦК на транспорте.

Завершенные проекты:
🔹ЕМД ПП - автоматизированная система оперативного управления перевозками; к ней подключено уже 11800 пользователей;
🔹АС ЭТРАН НП - автоматизированная система централизованной подготовки и оформления перевозочных документов; к ней подключено порядка 60 тыс.пользователей, ежемесячно оформляется более 5 млн перевозочных документов;
🔹ПКМПП - программный комплекс для моделирования и прогнозирования пассажиропотоков;
🔹АСУ ЭКСПРЕСС НП - основная билетная система железнодорожного транспорта, которая обеспечивает все бизнес-процессы пассажирского комплекса; к ней подключено 10600 пользователей.

В работе находятся еще 4️⃣ железнодорожных проекта:
🔸ЕС ПУЛ - система пономерного учета локомотивов;
🔸ЕАМ - система управления железнодорожной инфраструктурой;
🔸ТОРО П - подсистема управления текущим отцепочным ремонтом;
🔸ТОР ЭК - система управления вагонным хозяйством.

Кроме того, 5️⃣ информационных систем РЖД, реализуемых в рамках особо значимых проектов ИЦК, зарегистрированы в Едином реестре российского ПО.

🔜 В планах компании:
▪️Тиражирование проектов. Например, система «Экспресс» работает уже в 7 дружественных администрациях;
▪️Внедрение ИИ. В частности, в программном комплексе ПКМПП реализована функциональность анализа данных и моделирования с помощью искусственного интеллекта;
▪️Достижение технологического лидерства. Системы «ЭТРАН» и «Экспресс» по совокупности бизнес-функций превосходят зарубежные аналоги.