Рассмотрено применение микросервисного подхода к построению программно-аппаратного комплекса САПР электронной компонентной базы. Этапы маршрута проектирования представлены как самостоятельные сервисы, связанные шиной сообщений. Проанализировано распределение вычислительной нагрузки по этапам и показано, что независимое масштабирование наиболее тяжёлого этапа повышает пропускную способность маршрута. Предложена структура взаимодействия сервисов и согласования проектных данных.
САПР, микросервисы, маршрут проектирования, электронная компонентная база, программно-аппаратный комплекс, шина сообщений, масштабирование, верификация, проектные данные
Введение
Системы автоматизации проектирования (САПР) электронной компонентной базы исторически строились как монолитные программно-аппаратные комплексы: набор тесно связанных модулей маршрута проектирования работает с общим хранилищем и собирается в единую установку. По мере усложнения изделий и роста объёма проектных данных у такой организации проявляются ограничения. Тяжёлые этапы — логическое моделирование, синтез, размещение и трассировка — нельзя масштабировать по отдельности; обновление одного модуля требует переустановки всего комплекса; отказ одного компонента способен остановить весь маршрут. Состав и комплексирование технического обеспечения САПР, а также этапы маршрута проектирования подробно рассматриваются в работах [2, 4, 5].
В разработке прикладного программного обеспечения схожие проблемы решает микросервисная архитектура: систему разбивают на самостоятельные сервисы, которые разрабатываются, развёртываются и масштабируются независимо. Применение этого подхода к комплексу САПР выглядит естественным, поскольку маршрут проектирования уже представляет собой последовательность относительно обособленных этапов с чётко определёнными входами и выходами.
Цель работы — рассмотреть построение программно-аппаратного комплекса САПР на основе микросервисного подхода: представить этапы маршрута проектирования как самостоятельные сервисы, проанализировать распределение вычислительной нагрузки по ним и оценить, какой выигрыш в пропускной способности маршрута даёт независимое масштабирование наиболее тяжёлого этапа.
Маршрут проектирования как объект декомпозиции
Маршрут проектирования электронной компонентной базы включает ряд последовательных этапов: ввод и редактирование схемы, логическое моделирование, логический синтез, размещение и трассировку, верификацию топологии и электрической схемы (контроль проектных норм DRC и сверка топологии со схемой LVS). Каждый этап принимает результат предыдущего, выполняет свою обработку и передаёт результат дальше. Именно эта естественная обособленность этапов и делает маршрут удобным объектом для декомпозиции на сервисы.
Границы сервисов целесообразно проводить по этапам маршрута: за каждым этапом стоит самостоятельный инструмент со своими алгоритмами, форматами данных и требованиями к вычислительным ресурсам. Такое разбиение совпадает с предметной логикой и не создаёт искусственных связей. Отдельно выделяется служба проектных данных, отвечающая за хранение и версионирование проекта, поскольку к данным обращаются все этапы и их согласование требует единой точки ответственности.
Микросервисная архитектура комплекса САПР
Предлагаемая структура комплекса показана на рисунке 1. Пользователь работает через веб-клиент со схемным и топологическим редактором. Запросы проходят через шлюз, который выполняет маршрутизацию и аутентификацию, и попадают на шину сообщений. Этапы маршрута оформлены как отдельные сервисы, обменивающиеся через шину событиями о завершении обработки.
Рисунок 1 – Структура программно-аппаратного комплекса САПР на основе микросервисов
Служба проектных данных владеет хранилищем проекта и предоставляет остальным сервисам доступ к данным через свой интерфейс, а не напрямую.
Состав сервисов и их назначение сведены в таблицу 1. Для каждого сервиса указаны выполняемая функция и характер требований к ресурсам, что важно при размещении сервисов по вычислительным узлам комплекса.
Таблица 1 – Состав сервисов комплекса и их назначение
|
Сервис |
Функция в маршруте |
Ресурсы |
|
Проектных данных |
Хранение и версионирование проекта |
память, диск |
|
Логического моделирования |
Проверка функции по схеме |
процессор |
|
Логического синтеза |
Преобразование в вентильный базис |
процессор |
|
Размещения и трассировки |
Формирование топологии |
процессор, память |
|
Верификации DRC/LVS |
Контроль норм и сверка топологии |
процессор, память |
Такая организация даёт привычные для микросервисов преимущества применительно к САПР: отдельный этап можно обновлять и проверять, не затрагивая остальной маршрут; сбой одного сервиса не обрушивает весь комплекс, а лишь приостанавливает соответствующий этап; наконец, ресурсоёмкие этапы можно размещать на более мощных узлах и запускать в нескольких экземплярах.
Распределение нагрузки и масштабирование
Чтобы понять, какой этап ограничивает производительность маршрута, на учебном наборе проектов измерялось распределение вычислительного времени по этапам (рисунок 2). Наибольший вклад вносит размещение и трассировка — около 35 % времени маршрута, далее следуют синтез и верификация. Именно тяжёлый этап определяет пропускную способность всего маршрута, когда через комплекс проходит поток проектов или вариантов одного проекта.
Рисунок 2 – Распределение вычислительного времени по этапам маршрута проектирования
Микросервисный подход позволяет запускать наиболее тяжёлый этап в нескольких экземплярах и обрабатывать проекты параллельно. Если доля времени, приходящаяся на масштабируемый этап, равна f, а число его экземпляров — p, то относительное время обработки потока проектов оценивается по соотношению, аналогичному закону Амдала [1]:
T(p) = T₀ · ( (1 − f) + f / p ) (1)
где T₀ — время при одном экземпляре каждого этапа. Из выражения (1) видно, что выигрыш ограничен немасштабируемой частью (1 − f): сколько бы экземпляров тяжёлого этапа ни запускалось, время не опустится ниже доли остальных этапов. Для измеренного значения f ≈ 0,35 запуск трёх экземпляров этапа размещения и трассировки сокращает время прохождения потока примерно на 23 %, а дальнейшее наращивание даёт всё меньший прирост. Это позволяет осознанно выбирать число экземпляров тяжёлого сервиса, не расходуя ресурсы на масштабирование, которое уже не окупается.
Взаимодействие сервисов и согласование данных
Поскольку этапы маршрута связаны по данным, ключевым вопросом становится организация их взаимодействия. Применяется обмен событиями через шину: завершив обработку, сервис публикует сообщение о готовности результата, а заинтересованный сервис следующего этапа его получает и продолжает маршрут. Такой асинхронный обмен ослабляет связанность: сервисы не вызывают друг друга напрямую и не обязаны быть одновременно доступными. Вопросы системного моделирования и разработки протоколов информационного взаимодействия блоков в комплексе САПР рассматриваются в работе [3].
Особого внимания требует согласование проектных данных. Все этапы работают с общим проектом, поэтому за его целостность отвечает служба проектных данных: она хранит версии, фиксирует, какой результат каким этапом получен, и не допускает одновременного несогласованного изменения. Это снимает риск «распределённого монолита», когда сервисы формально разделены, но через общее хранилище остаются жёстко связанными. Доступ к данным только через интерфейс владельца сохраняет независимость этапов и делает маршрут прослеживаемым.
Обсуждение
Микросервисное построение комплекса САПР согласуется с самой природой маршрута проектирования и, как и архитектурный анализ прикладных систем [6], даёт практические выгоды: независимое обновление и проверку этапов, устойчивость к отказу отдельного сервиса и возможность масштабировать ресурсоёмкие этапы. Анализ распределения нагрузки и оценка по выражению (1) позволяют направлять ресурсы туда, где они действительно увеличивают пропускную способность, а не равномерно по всем этапам.
Следует учитывать и издержки подхода. Разбиение на сервисы усложняет развёртывание и сопровождение комплекса, добавляет накладные расходы на обмен сообщениями и требует продуманного согласования данных и версий инструментов. Для небольших задач, выполняемых одним проектировщиком, монолитная организация может оставаться проще и эффективнее. Поэтому микросервисный подход оправдан прежде всего для комплексов с потоком проектов, требованиями к масштабированию и частыми обновлениями отдельных этапов.
Заключение
Рассмотрено построение программно-аппаратного комплекса САПР электронной компонентной базы на основе микросервисного подхода. Этапы маршрута проектирования представлены как самостоятельные сервисы, связанные шиной сообщений, с выделенной службой проектных данных. Анализ распределения вычислительной нагрузки показал, что маршрут ограничивается тяжёлым этапом размещения и трассировки, а независимое масштабирование этого этапа в соответствии с выражением (1) повышает пропускную способность комплекса с понятным пределом выигрыша. Предложенная структура взаимодействия сервисов и согласования данных сохраняет независимость этапов и прослеживаемость проекта, что делает микросервисный подход применимым к построению комплексов САПР.
1. Морозов, Н. Д. Введение в управление микросервисами / Н. Д. Морозов, Д. Д. Романов, К. В. Пугин // Современные проблемы лингвистики и методики преподавания русского языка в ВУЗе и школе. – 2022. – № 40. – С. 689-702. – EDN DMLLTW.
2. Комплексирование технического обеспечения в САПР / М. И. Конча, А. С. Мещеряков, М. А. Махиборода [и др.] // Моделирование систем и процессов. – 2025. – Т. 18, № 4. – С. 39-47. – DOIhttps://doi.org/10.12737/2219-0767-2025-18-4-39-47. – EDN CVAQJW.
3. Системное моделирование и разработка протоколов информационного взаимодействия блоков в программно-аппаратном комплексе САПР / К. В. Зольников, Д. В. Шеховцов, М. А. Махиборода [и др.] // Моделирование систем и процессов. – 2025. – Т. 18, № 2. – С. 53-62. – DOIhttps://doi.org/10.12737/2219-0767-2025-18-2-53-62. – EDN XKOLNC.
4. Начальный этап маршрута проектирования в программно-аппаратном комплексе САПР по разработке электронной компонентной базы и радиоаппаратуры / К. В. Зольников, Д. В. Шеховцов, М. А. Махиборода, О. В. Оксюта // Моделирование систем и процессов. – 2025. – Т. 18, № 2. – С. 40-53. – DOIhttps://doi.org/10.12737/2219-0767-2025-18-2-40-53. – EDN BQPFDK.
5. Методы разработки электрической принципиальной схемы в программно-аппаратном комплексе системы автоматизации проектирования / К. В. Зольников, Д. В. Шеховцов, М. А. Махиборода [и др.] // Моделирование систем и процессов. – 2025. – Т. 18, № 3. – С. 52-62. – DOIhttps://doi.org/10.12737/2219-0767-2025-18-3-52-62. – EDN MOYIZF.
