Информационная система
поддержки проверки
блока связи
ВКР: анализ процесса, проектирование, реализация
и тестирование
Практическая реализация показана на примере блока Б7-21
01
Проблема и цель работы
Почему потребовалась информационная система
• проверка выполняется как набор ручных
действий и рабочих заметок
• результат трудно сопоставить с объектом,
сценарием и временем запуска
• повторная проверка требует заново
восстанавливать контекст
• цель — формализовать маршрут: выбор
объекта → запуск → результат → журнал
Результат работы
система, которая связывает оборудование, сценарии,
результаты и журнал в один маршрут проверки
02
Объект, предмет и границы разработки
СПГУ-21 используется как документированный предметный пример
ОБЪЕКТ АВТОМАТИЗАЦИИ
процесс проверки
работоспособности блока связи
ПРЕДМЕТ РАЗРАБОТКИ
методы и программные средства
формализации проверочного маршрута
ГРАНИЦА РАБОТЫ
• не заменяет штатный контроль СПГУ-21
• работает как внешний программный контур
• реализация показана на Б7-21
Каталог связывает конкретный объект проверки с
параметрами запуска
03
AS-IS: текущий порядок проверки
Ручной процесс до введения единого программного контура
ПРОБЛЕМЫ AS-IS
• сведения об объекте и сценарии
разнесены
• подготовительные действия
повторяются вручную
• результат фиксируется
неодинаково
• сложно восстановить условия
прошлой проверки
Вывод: автоматизировать нужно не
физическую проверку, а маршрут
подготовки, запуска, приема
результата и журналирования.
04
От узких мест к проектным изменениям
Каждая функция системы закрывает конкретную проблему AS-IS
Разрозненные сведения → единый каталог оборудования
Ручной выбор сценария → шаблоны проверок
Неоднозначный итог → структурированный ответ result_table
Разные журналы и заметки → централизованный журнал запусков
Слабая повторяемость → связь: объект + сценарий + пользователь + время
Так формируется TO-BE: пользователь выбирает объект и шаблон, система проверяет допуск,
формирует команду, принимает результат и сохраняет его в журнале.
05
TO-BE: целевой маршрут проверки
Информационная система выступает механизмом процесса
ЧТО МЕНЯЕТСЯ
• объект выбирается из каталога
• сценарий задается шаблоном
• запуск проходит через сервисную
логику
• результат разбирается
автоматически
• журнал хранит историю и детали
запуска
IDEF0 показывает функции процесса, а
программная структура раскрывается
далее через UML, ERD и API.
06
Роли и сценарии работы
Пользовательские роли отделены от технических участников
• инженер-исполнитель: выбор оборудования,
запуск, просмотр результата, журнал
• администратор: карточки оборудования,
параметры связи, шаблоны проверок
• Б7-21 / встроенное ПО: технический участник,
не пользователь системы
Доступ к внутренним сервисам идет через
gateway: пользовательский уровень отделен от
сервисной логики.
Это снижает риск случайного изменения справочных
данных и отделяет запуск проверки от
администрирования.
07
Архитектура информационной системы
Сервисная структура соответствует функциям TO-BE
ОТВЕТСТВЕННОСТИ СЕРВИСОВ
• equipment_service — карточки
оборудования
• booking_service — занятость и допуск
• shorttest_service — запуск и разбор
результата
• block_adapter_service — обмен с Б7-21
• journal_service — история проверок
Gateway является единой точкой входа для
интерфейса и маршрутизирует запросы во
внутренние сервисы.
08
Данные: объект, шаблон, запуск, результат
ERD фиксирует связи, необходимые для повторяемой проверки
КЛЮЧЕВАЯ СВЯЗЬ
test_run связывает оборудование,
шаблон, пользователя, время
запуска и итоговый результат.
• equipment — параметры блока и связи
• test_template — сценарий проверки
• test_result — шаги и признаки
прохождения
• journal — повторный просмотр истории
В прототипе используется SQLite; для
промышленного варианта описана
возможность перехода на Postgres Pro.
09
Почему выбран такой стек
Выбор связан с веб-интерфейсом, REST API, обработкой JSON и журналированием
React + TypeScript
сложные формы, таблицы и типы API-моделей
Python + FastAPI
REST API, валидация данных, OpenAPI
SQLAlchemy
изолированный слой работы с данными
SQLite / Postgres Pro
прототип / отечественная реестровая СУБД
Сервисная структура
отдельно: оборудование, запуск, адаптер, журнал
Стек выбран под требования проекта: быстрый интерфейс, понятные API-контракты, обработка result_table и
возможность перехода на промышленное хранилище Postgres Pro.
10
Реализация пользовательского маршрута
Скриншоты показывают прохождение TO-BE в интерфейсе
1. выбор оборудования 2. запуск проверки
3. журнал 4. детализация результата
11
Обработка результата проверки
Демонстрационный режим подтверждает программный маршрут без реального блока
Важно для защиты: успешный результат на скриншоте сформирован в режиме UI test, а не заявляется
как фактическое подтверждение состояния физического Б7-21.
12
Тестирование и итог работы
Проверены пользовательские сценарии, обмен и журналирование
• проверен выбор оборудования, бронирование и
запуск сценария
• проверена обработка структурированного ответа
result_table
• проверено сохранение истории и повторное
открытие детализации
• проверена связка frontend → gateway → сервисы
→ журнал
Итог
Разработана информационная система, которая
формализует маршрут проверки блока связи и
сохраняет результат в воспроизводимом виде.
13