РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ: ПРОГРАММА ДЛЯ ЭВМ «ПРОГРАММА РЕШЕНИЯ ЗАДАЧ «ОПТИПОИНТ»
1. Термины и определения
Термины и определения | Описание |
Программа решения задач, Программа | Программа для ЭВМ «Программа решения задач «Оптипоинт» |
API (Application Programming Interface) | Программный интерфейс, с помощью которого пользователь или другая программа могут взаимодействовать с сервисом путём отправки HTTP-запросов и получения ответов в определённом формате. |
RESTful API
| Стиль архитектуры веб-сервисов, в котором для обмена данными используются стандартизированные методы HTTP (GET, POST и т. д.) и форматированный ответ. |
HTTPS (HTTP Secure) | Протокол передачи данных по сети Интернет, использующий шифрование (TLS/SSL) для обеспечения конфиденциальности и целостности передаваемой информации. |
MPS (Mathematical Programming System) | Стандартный текстовый формат задания моделей линейного и целочисленного программирования, содержащий описание переменных, ограничений, правых частей, коэффициентов и целевой функции. |
LP (Linear Programming)
| Задачи линейного программирования, в которых переменные являются непрерывными и целевая функция, а также все ограничения, линейны. |
MILP (Mixed Integer Linear Programming)
| Задачи смешанного целочисленного линейного программирования, в которых часть переменных является целочисленной (в том числе бинарной), при сохранении линейной структуры ограничений и целевой функции. |
CP (Constraint Programming) | Подход к решению комбинаторных задач, где задаются ограничения (в том числе дискретные) и производится поиск решения методами программирования с ограничениями. |
Солвер (Solver) | Программный модуль, который непосредственно обрабатывает задачу оптимизации (или решения системы линейных уравнений) и пытается найти оптимальное решение (или определить, что решение не существует). |
Job ID (идентификатор задачи)
| Уникальный идентификатор, который присваивается задаче после её отправки на сервер для решения. Используется для проверки статуса и получения результатов |
Токен (или ключ) авторизации | Специальная строка, которая подтверждает права доступа пользователя к API. Она передаётся в заголовке HTTP-запроса или другими способами в соответствии с политикой безопасности сервиса. |
Данное программное обеспечение предоставляет облачный сервис (SaaS) для решения задач дискретной оптимизации и систем линейных уравнений. Основные цели и возможности:
2.1 Решение широкого класса задач оптимизации
Поддерживаются линейные (LP), смешанные целочисленные (MILP) и дискретные задачи, формализованные через программирование с ограничениями (CP).
2.2 Высокая масштабируемость
Сервис способен обрабатывать крупные задачи (с сотнями тысяч переменных и ограничений) и динамически увеличивать вычислительные мощности при росте нагрузки.
2.3 Удобное REST-API
Предоставляет стандартные HTTP-методы для отправки задачи, проверки статуса и получения решения, упрощая интеграцию с любыми внешними системами или пользовательскими программами.
2.4 Безопасность
Все запросы выполняются по протоколу HTTPS, применяется аутентификация и авторизация по токенам/ключам, а данные пользователей хранятся и передаются в зашифрованном виде.
2.5 Надёжность и отказоустойчивость
Архитектура предусматривает авто-масштабирование и резервирование, чтобы обеспечить непрерывную работу при сбоях отдельных узлов.
Таким образом, сервис помогает организациям или отдельным исследователям эффективно решать задачи дискретной оптимизации без необходимости развертывать собственную инфраструктуру.
2.1 Решение широкого класса задач оптимизации
Поддерживаются линейные (LP), смешанные целочисленные (MILP) и дискретные задачи, формализованные через программирование с ограничениями (CP).
2.2 Высокая масштабируемость
Сервис способен обрабатывать крупные задачи (с сотнями тысяч переменных и ограничений) и динамически увеличивать вычислительные мощности при росте нагрузки.
2.3 Удобное REST-API
Предоставляет стандартные HTTP-методы для отправки задачи, проверки статуса и получения решения, упрощая интеграцию с любыми внешними системами или пользовательскими программами.
2.4 Безопасность
Все запросы выполняются по протоколу HTTPS, применяется аутентификация и авторизация по токенам/ключам, а данные пользователей хранятся и передаются в зашифрованном виде.
2.5 Надёжность и отказоустойчивость
Архитектура предусматривает авто-масштабирование и резервирование, чтобы обеспечить непрерывную работу при сбоях отдельных узлов.
Таким образом, сервис помогает организациям или отдельным исследователям эффективно решать задачи дискретной оптимизации без необходимости развертывать собственную инфраструктуру.
Все операции с сервисом происходят через RESTful API. Взаимодействие строится по протоколу HTTPS с использованием стандартных HTTP-методов (POST, GET). Ниже кратко описаны ключевые возможности:
3.1 Отправка задачи на решение
Метод: POST /solve
Параметры:
3.2 Проверка статуса задачи
Метод: GET /status/{jobId}
Действие: возвращает текущее состояние задачи: «в очереди», «в процессе решения», «решение найдено», «время вышло», «ошибка» и т. п.
Результат: JSON или другой формализованный ответ, отражающий статус.
3.3 Получение результатов решения
Метод: GET /solution/{jobId}
Действие: если задача успешно решена, этот метод предоставляет решение в машинном формате (например, JSON, XML или иной согласованный формат), включающий найденные значения переменных, оптимальное значение целевой функции и другую полезную информацию (статистику решения, время решения, статус оптимальности и т.д.).
Результат: скачиваемый файл или JSON-объект с результатами.
3.4 Отмена задачи
Метод: POST /cancel/{jobId}
Действие: приостанавливает и отменяет решение указанной задачи, если пользователь понимает, что продолжать решение нет необходимости.
Результат: подтверждение об отмене задачи.
3.5 Настройка приоритетов, квот и ограничений
В рамках организации или аккаунта могут существовать квоты по максимальному количеству одновременно решаемых задач. В методах API это обычно отражается кодами ошибок при превышении лимитов (например, 429 Too Many Requests).
3.6 Журналирование и мониторинг
Пользователь может при необходимости получать логи своих запросов, чтобы анализировать эффективность решения и выявлять проблемы.
Сервис ведёт внутренний журнал (audit log), где фиксируются все ключевые операции (запуск, завершение, отмена задачи, обновления статуса и т.д.). Непосредственный доступ к нему может не предоставляться пользователю, но служба поддержки может использовать эти логи для диагностики.
3.1 Отправка задачи на решение
Метод: POST /solve
Параметры:
- Файл задачи в формате MPS (передаётся как часть тела запроса или как файл).
- Параметры решения (необязательные), например, ограничения на время решения, требуемая точность, выбор алгоритма (LP/MILP/CP) и прочие настройки.
3.2 Проверка статуса задачи
Метод: GET /status/{jobId}
Действие: возвращает текущее состояние задачи: «в очереди», «в процессе решения», «решение найдено», «время вышло», «ошибка» и т. п.
Результат: JSON или другой формализованный ответ, отражающий статус.
3.3 Получение результатов решения
Метод: GET /solution/{jobId}
Действие: если задача успешно решена, этот метод предоставляет решение в машинном формате (например, JSON, XML или иной согласованный формат), включающий найденные значения переменных, оптимальное значение целевой функции и другую полезную информацию (статистику решения, время решения, статус оптимальности и т.д.).
Результат: скачиваемый файл или JSON-объект с результатами.
3.4 Отмена задачи
Метод: POST /cancel/{jobId}
Действие: приостанавливает и отменяет решение указанной задачи, если пользователь понимает, что продолжать решение нет необходимости.
Результат: подтверждение об отмене задачи.
3.5 Настройка приоритетов, квот и ограничений
В рамках организации или аккаунта могут существовать квоты по максимальному количеству одновременно решаемых задач. В методах API это обычно отражается кодами ошибок при превышении лимитов (например, 429 Too Many Requests).
3.6 Журналирование и мониторинг
Пользователь может при необходимости получать логи своих запросов, чтобы анализировать эффективность решения и выявлять проблемы.
Сервис ведёт внутренний журнал (audit log), где фиксируются все ключевые операции (запуск, завершение, отмена задачи, обновления статуса и т.д.). Непосредственный доступ к нему может не предоставляться пользователю, но служба поддержки может использовать эти логи для диагностики.
Пользовательский (или программный) сценарий взаимодействия с сервисом может выглядеть так:
4.1 Подготовка модели
Пользователь формирует задачу в формате MPS. Для этого необходимо использовать подходящие инструменты (например, специализированные библиотеки Python, утилиты преобразования из AMPL, GMPL или другого языка моделирования).
4.2 Аутентификация
o Перед выполнением запросов к API пользователь получает токен/ключ доступа. Способ получения зависит от правил, установленных провайдером (например, регистрация в личном кабинете и генерация ключа).
4.3 Отправка задачи
Выполняется POST /solve с заголовком Authorization: Bearer <ключ> и телом запроса, в которое вложен MPS-файл задачи. Опционально указываются параметры (например, таймлимит и др.).
Система проверяет допустимость модели (размер MPS, отсутствие нелинейных компонентов) и при успехе возвращает jobId.
4.4 Ожидание решения
Пользователь периодически опрашивает GET /status/{jobId} (или использует webhook/уведомления, если они предусмотрены).
В случае крупных задач решение может занять от нескольких секунд до нескольких часов — в зависимости от сложности и доступных ресурсов.
4.5 Получение решения
Когда статус переходит в «решение найдено», пользователь отправляет запрос GET /solution/{jobId}.
В ответ приходит файл (или JSON/другой формат), содержащий значения переменных, целевую функцию и статус оптимальности.
4.6 Обработка и анализ результатов
Пользователь импортирует полученный файл в свою систему или анализирует ответы программно (например, сравнивает различные запуски, проверяет, удовлетворены ли бизнес-требования и т. д.).
4.1 Подготовка модели
Пользователь формирует задачу в формате MPS. Для этого необходимо использовать подходящие инструменты (например, специализированные библиотеки Python, утилиты преобразования из AMPL, GMPL или другого языка моделирования).
4.2 Аутентификация
o Перед выполнением запросов к API пользователь получает токен/ключ доступа. Способ получения зависит от правил, установленных провайдером (например, регистрация в личном кабинете и генерация ключа).
4.3 Отправка задачи
Выполняется POST /solve с заголовком Authorization: Bearer <ключ> и телом запроса, в которое вложен MPS-файл задачи. Опционально указываются параметры (например, таймлимит и др.).
Система проверяет допустимость модели (размер MPS, отсутствие нелинейных компонентов) и при успехе возвращает jobId.
4.4 Ожидание решения
Пользователь периодически опрашивает GET /status/{jobId} (или использует webhook/уведомления, если они предусмотрены).
В случае крупных задач решение может занять от нескольких секунд до нескольких часов — в зависимости от сложности и доступных ресурсов.
4.5 Получение решения
Когда статус переходит в «решение найдено», пользователь отправляет запрос GET /solution/{jobId}.
В ответ приходит файл (или JSON/другой формат), содержащий значения переменных, целевую функцию и статус оптимальности.
4.6 Обработка и анализ результатов
Пользователь импортирует полученный файл в свою систему или анализирует ответы программно (например, сравнивает различные запуски, проверяет, удовлетворены ли бизнес-требования и т. д.).
Так как сервис предоставляется по модели SaaS, глубоких локальных настроек пользователю обычно не требуется. Основные первоначальные шаги и настройки:
5.1 Регистрация и получение учётных данных
В конфигурациях собственного приложения (или скрипта) необходимо прописать URL-адреса методов (например, https://api.example.com/solve) и указать логин и пароль.
5.3 Установка ограничений и параметров по умолчанию
При необходимости пользователь может задать глобальный лимит времени решения (timeout), установить приоритеты обработки задач (если политика сервиса это позволяет) или настроить другие глобальные параметры для своего аккаунта. Параметры по умолчанию конфигурируются по запросу.
5.4 Подготовка инструментов для работы с MPS
Убедиться, что на стороне пользователя есть утилиты или библиотеки для формирования MPS-файлов (к примеру, pulp, pyomo или другая библиотека в Python, AMPL/GMPL и пр.).
5.5 Проверка квот и ограничений
Каждому пользователю может быть назначена квота по объёму загружаемых данных и числу одновременных задач. Рекомендуется ознакомиться с этими лимитами заранее.
5.1 Регистрация и получение учётных данных
- Пользователь регистрируется в системе через менеджера по запросу на solver@mp-co.ru.
- После подтверждения учётной записи он получает логин и пароль.
В конфигурациях собственного приложения (или скрипта) необходимо прописать URL-адреса методов (например, https://api.example.com/solve) и указать логин и пароль.
5.3 Установка ограничений и параметров по умолчанию
При необходимости пользователь может задать глобальный лимит времени решения (timeout), установить приоритеты обработки задач (если политика сервиса это позволяет) или настроить другие глобальные параметры для своего аккаунта. Параметры по умолчанию конфигурируются по запросу.
5.4 Подготовка инструментов для работы с MPS
Убедиться, что на стороне пользователя есть утилиты или библиотеки для формирования MPS-файлов (к примеру, pulp, pyomo или другая библиотека в Python, AMPL/GMPL и пр.).
5.5 Проверка квот и ограничений
Каждому пользователю может быть назначена квота по объёму загружаемых данных и числу одновременных задач. Рекомендуется ознакомиться с этими лимитами заранее.
6.1 Системные требования у пользователя
При массовой отправке задач в сервис (например, в рамках Stress-теста) нужно заранее уведомить провайдера, чтобы избежать превышения квот и избежать временной блокировки за аномальную активность.
- Доступ к сети Интернет с поддержкой HTTPS-протокола.
- Возможность отправлять файлы формата MPS (одним из стандартных HTTP-клиентов или библиотек).
- Файл MPS должен удовлетворять ограничениям сервиса (например, не превышать нескольких сотен мегабайт, если это прописано в тарифном плане).
- Количество переменных и ограничений может быть ограничено доступными ресурсами (оперативная память, время решения). При превышении лимитов сервис может возвращать ошибку или уведомление о невозможности решения.
- Система устойчива к кратковременным сетевым сбоям, однако при длительном отсутствии связи пользователь должен повторно проверить статус задачи.
- В случае аварийного отключения узла задача может быть перераспределена на другой вычислительный узел без вмешательства пользователя.
- Все данные передаются только по защищённому каналу (HTTPS).
- Сервис хранит пользовательские данные во внутреннем репозитории с применением шифрования «at-rest» и политикой резервного копирования.
При массовой отправке задач в сервис (например, в рамках Stress-теста) нужно заранее уведомить провайдера, чтобы избежать превышения квот и избежать временной блокировки за аномальную активность.
7. Авторизация
Для вызовов к API требуется аутентификация, которая обеспечивается путём передачи уникального токена в заголовке HTTP-запроса. Общая схема:
7.1 Получение учетной записи
После регистрации менеджером пользователь получает на электронную почту логин и пароль.
7.2 Использование учетной записи
Пользователю рекомендуется держать токен в надёжном месте (не допускать утечки, не хранить в открытом виде в публичных репозиториях).
7.4 Отзыв токенов
При необходимости администратор может вручную отозвать токен (например, при подозрении на компрометацию). После этого все запросы с ним будут возвращать ошибку авторизации.
7.1 Получение учетной записи
После регистрации менеджером пользователь получает на электронную почту логин и пароль.
7.2 Использование учетной записи
- При отправке запроса к сервису необходимо добавить заголовок: Authorization: Basic <ваши УЗ>
- Сервис проверяет действительность УЗ. Если она просрочена или недействительна, ответит ошибкой (обычно 401 Unauthorized или 403 Forbidden).
Пользователю рекомендуется держать токен в надёжном месте (не допускать утечки, не хранить в открытом виде в публичных репозиториях).
7.4 Отзыв токенов
При необходимости администратор может вручную отозвать токен (например, при подозрении на компрометацию). После этого все запросы с ним будут возвращать ошибку авторизации.
Для связи со службой технической поддержки необходимо отправить письмо с описанием возникшей проблемы / вопросы на электронную почту: solver@mp-co.ru.
Или напишите нам
Сообщение об успешной отправке!