О проекте

Разработка открытой библиотеки проведения поэтапного математического моделирования и оптимизации параметров систем при создании цифровых двойников изделий (ссылка на сайт)

Цель проекта

Обеспечить предприятия, инжиниринговые компании, научно-исследовательские институты и ВУЗы доступным инструментом для формирования комплексных математических моделей цифровых двойников изделий за счет создания открытой платформы для решения инженерных задач, связанных с подбором и поиском оптимальных параметров на базе сквозного мультидисциплинарного моделирования с использованием различных параметризированных математических моделей и САЕ продуктов.

Преимущества проекта

Закладываемая архитектура обеспечивает возможности параллельного и распределенного выполнения задач внутри этапа сценария, комбинирования легких и ресурсоемких моделей, использование локальных подпространств имен обеспечит возможность:

переиспользования математических моделей
разработки сложных комплексных моделей (в том числе многопользовательском режиме), задел для:
- вложенных циклов оптимизации
- применения вложенных моделей
- формирования локальных баз для прогнозирования параметров отдельных моделей

Перечень направлений прикладного использования проекта

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

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

Архитектура открытой библиотеки

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

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

БХО (ustep-storage) - База хранения и обмена параметрами
МИС (ustep-player) (текущий репозиторий) - Модуль исполнения сценария
Оптимизатор (ustep-optim) - компонент, обеспечивающий проведение оптимизационных исследований

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

ГИ (ustep-ide) - Графический интерфейс , демонстрирующий использование библиотеки из приложения Electron;
Сценарии (ustep-workers) - Консольные примеры, демонстрирующие использование библиотеки из интерфейса командной строки.

Для использования библиотеки следует загрузить на компьютер репозитории библиотеки (БХО, МИС, Оптимизатор), а также один или оба репозитория, демонстрирующих ее использование (ГИ, Сценарии). Подключение библиотеки к ГИ осуществляется в окне настроек ГИ, в котором указываются пути к БХО, МИС и оптимизатору. Для подключение библиотеки к Сценариям все загруженные репозитории (БХО, МИС, Оптимизатор, Сценарии) должны быть расположены в одной директории, после чего подключение осуществляется автоматически.

Платформа сквозного многодисциплинарного моделирования при использовании ГИ работает по следующему алгоритму:

пользователь готовит в ГИ проект сквозного многодисциплинарного моделирования;
ГИ сохраняет описание и начальные параметры сценария;
ГИ запускает МИС;
МИС считывает начальные параметры сценария, инициализирует и заполняет БХО с помощью помощника БХО;
МИС выполняет запуск МШС в соответствии с полученным описанием сценария;
API внешних модулей получает параметры для выполняемого МШС;
МШС сценария выполняет свой скрипт/сценарий расчета задачи и обменивается расчетными данными с ядром платформы;
API внешних модулей передает статус выполняющегося МШС в БХО;
ГИ получает из БХО информацию о выполнении МШС, отображает ее и позволяет пользователю управлять выполнением сценария;
ГИ отображает результаты выполнения сценария.

Платформа сквозного многодисциплинарного моделирования при использовании Сценариев работает по следующему алгоритму:

пользователь запускает в командном интерпритаторе начальный скрипт (run.cmd для ОС Windows или run.sh для ОС Linux) и выбирает сценарий, который должен быть расчитан;
скрипт запускает МИС, передавая ему параметры выбранного сценария;
МИС считывает начальные параметры сценария, инициализирует и заполняет БХО с помощью помощника БХО;
МИС выполняет запуск МШС в соответствии с полученным описанием сценария;
API внешних модулей получает параметры для выполняемого МШС;
МШС сценария выполняет свой скрипт/сценарий расчета задачи и обменивается расчетными данными с ядром платформы;
API внешних модулей передает статус выполняющегося МШС в БХО;
по окончании расчета управление возвращается в командный интерпритатор, после чего пользователь может проанализировать файлы с результатами выполнения сценария.

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

Описание исполнителя сценария

Исполнитель сценария открытой библиотеки проведения поэтапного математического моделирования и оптимизации параметров систем при создании цифровых двойников изделий

Минимальные технические требования для запуска и использования исполнителя сценария

системные требования:
- процессор с архитектурой x86-64 (Intel с поддержкой Intel 64, AMD с поддержкой AMD64). Желательно использование многопроцессорных или многоядерных машин
- оперативная память не менее 2 Гбайт (рекомендуется 4 Гбайт и выше)
- жесткий диск 40Гб и выше
программные требования:
- ОС Windows 10 x64 /Ubuntu 22.04
- Python 3.11
- дополнительные модули Python и их версии перечислены в файле requirements.txt
- Redis 7.2

Установка дополнительных программных компонент

Исполнитель сценария разработан в виде скриптов на языке программирования Питон и помимо стандартных требует доустановки дополнительных модулей Питона. Доустановка дополнительных модулей возможно с помощью любого пакетного менеджера, например с помощью pip) это можно выполнить с помощью команды pip install -r requirements.txt
Для работы исполнителя сценария требуется установка БД Redis:
- установка БД Redis на ОС Linux возможна либо с помощью менеджера пакетов, либо путем сборки из исходных кодов
- установка БД Redis на ОС Windows возможна либо через WSL2 (Windows Subsystem for Linux) как советуют разработчики Redis, либо загрузки собранных энтузиастами исполняемых файлов

Принцип работы исполнителя сценария

Стартер БД Redis:
- находит свободный TCP/IP порт в диапазоне 1024..65535
- запускает сервер БД Redis и сохраняет в файл ustep_redis.json информацию с:
  - идентификатором процесса сервер БД Redis
  - TCP/IP портом на локальном компьтере, через который осуществляется доступ к серверу БД Redis
Инициализатор БД Redis:
- получает, в качестве входного параметра, имя файла с описанием структуры начальных данных
- загружает в БД Redis начальные данные, необходимые для выполнения сценария
Исполнитель сценария:
- получает в качестве входных параметров:
  - путь в структуре данных до модели главного сценария
  - имя файла сценария
- считывает из текущей директории файл конфигурации, в котором содержиться информация:
  - путь до директории с файлами сценария
  - путь до директории с файлами описаний структур начальных данных
  - пути до директорий с дополнительными модулями, на языке программирования Питон
  - пути до директорий до утилит, необходимых при работе сценария
- выполняет сценарий, состоящий из фреймов, в которых могут быть вызваны, в виде отдельных задач, либо скрипты на языке программирования Питон, либо вложенные подсценарии:
  - для каждой задачи загружает из БД Redis соответствующую секцию данных
  - посылает в поток @statuses БД Redis сообщение о начале расчета задачи
  - сохраняет в обменном файле данные, полученные из БД Redis и передает управление скрипту/подсценарию задачи
  - загружает в БД Redis измененные данные после выполнения каждой задачи
  - посылает в поток @statuses БД Redis сообщение об окончании расчета задачи
  - определяет к какому следующему фрейму переходит выполнение и этот процесс продолжается до тех пор, пока не будет выполнен весь сценарий
- в процессе работы в рабочих директориях появляются дополнительные файлы:
  - файлы с расширением log содержат информацию по работе исполнителя сценария
  - файлы с расширением out содержат информацию, получаемую из стандартных потоков вывода процесса, в котором выполняется задача сценария
- Получатель элементов БД Redis используется для получения измененных данных в процессе расчета сценария
- Завершатель БД Redis посылает БД сигнал о завершении и необходимости сохранить свой контекст в файл dump.rdb

Соглашения по формату начальных данных

Секции объектов

Объекты могут быть объединены в следующие секции: @global, @objects, @types, @connectors.
Секция @global содержит набор вспомогательных объектов не принадлежащих какому-то расчетному объекту, а принадлежащие всей задаче и использующиеся для передачи общих параметров.
Секция @objects содержит набор расчетных объектов, каждый из которых может решать отдельную подзадачу.
Секция @types содержит набор типовых объектов, которые используются для создания расчетных объектов и их подобъектов.
Секция @connectors содержит набор соединений - вырожденных объектов, не имеющих расчетных скриптов или сценариев и использующихся для присоединения подобъектов к объекту. Объект, содержащий коннектор является неполным и не может быть расчитан.

Объекты

Объекты могут содержать: определители, секции параметров, отдельные параметры и подобъекты. По аналогии с древовидной структурой, объект это “узел”, а параметры это “листья”.
Объекты могут быть вырожденными - состоящими из одного параметра. В этом случае, объект-обертка не создается и параметр записывается как отдельный параметр, но подразумевается, что он входит в неименованный вырожденный объект.
Объекты могут иметь следующие определители: @obj_type, @obj_copy, @obj_connector, @link, @const_link.
Определитель @obj_type обозначает, что объект “наследуется” от типового объекта - при создании происходит копирование свойств типового объекта (если типовой объект имеет свой типовой объект, то происходит вложенное копирование), а потом накладываются изменения из текущего объекта, за исключением значения параметра @obj_type - он накапливает список всех типов от которых объект отнаследован.
Определитель @obj_copy обозначает, что объект копируется из другого объекта - при создании происходит копирование свойств другого объекта, а потом накладываются изменения из текущего объекта.
Разница между определителями @obj_type и @obj_copy в операциях с определителем @obj_type, который используется в первую очередь для накопления данных в ROM.
Определитель @obj_connector обозначает, что объект является подобъектом и присоединяется к другому объекту через соединитель - промежуточный объект, который в случае отключения текущего объекта будет содержать все замыкания параметров (входных и выходных).
Определитель @link обозначает, что объект является ссылкой на другие объекты и содержит список ссылок (адреса объектов). Доступ к объектам через ссылки может быть как на запись, так и на чтение, при этом чтение возможно только из одного объекта (первого в списке ссылок), а запись производиться во все объекты, список ссылок на которые содержит определитель.
Определитель @const_link обозначает, что объект является константной ссылкой на другой объект и содержит ссылку (адрес объекта).
Объекты могут иметь следующие секции параметров и подобъектов: @input, @local, @output.
Секция параметров @input содержит входные параметры и подобъекты объекта и используется для передачи входных данных в объект.
Секция параметров @local содержит локальные параметры и подобъекты объекта и используется для передачи данных в подобъекты.
Секция параметров @output содержит выходные параметры и подобъекты объекта и используется для передачи выходных данных из объекта.
Любые не замкнутые входные или локальные параметры и подобъекты означают, что объект является неполным и не может быть расчитан.

Правила разработки модулей шагов сценария (МШС)

МШС должен быть разработан в виде скрипта на языке программирования Python.
МШС должен импортировать модуль ustep_user_utils, содержащий набор пользовательских функций (например, загрузка и сохранение файла входных/выходных параметров) и перечислитель статусов возврата.
МШС должен содержать «обертку», которая обеспечивает:
- получение входных и выходных параметров из файла, указанного в командной строке.
- возвращение статуса выполнения МШС в виде одного из кодов возврата, описанных в перечислителе из модуля ustep_user_utils.

# -*- coding: utf-8 -*-
import sys
from ustep_user_utils import *

def main(input: dict, output: dict)->None:
  # Основная функция МШС 
   pass

if __name__ == "__main__":
  try:
    # Проверяем корректность параметров командной строки
    if 2 != len(sys.argv):
        raise RuntimeError('arguments aren\'t valid')
    # Читаем параметры модели из файла
    parameters = read_json_file(sys.argv[1])
    # Расчитываем параметры модели
    main(parameters['@input'], parameters['@output'])
    # Записываем параметры модели в файл
    write_json_file(sys.argv[1], parameters)
    sys.exit(Status.SUCCESS0)
  except Exception as ex:
    print(ex)
    sys.exit(Status.EXCEPTION)