О проекте

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

Цель проекта

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

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

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

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

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

Открытая библиотека позволяет решать инженерные задачи, связанные с подбором и поиском оптимальных параметров на базе сквозного многодисциплинарного моделирования с использованием различных параметризированных математических моделей и 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)