Application of embedded systems and cross-platform software for traffic flow management on an interactive model

Full Text

Введение

 

Современные музейные экспозиции все чаще включают в себя сложные интерактивные макеты с динамическими объектами, что предъявляет высокие требования к системам управления. Особую сложность представляет организация управления транспортными потоками на масштабных макетах, имитирующих реальные городские условия со множеством перекрестков, светофоров и взаимодействующих участников движения. Существующие типовые решения зачастую оказываются неприменимыми в специфической среде музея, где необходима одновременная реализация таких свойств, как высокая надежность, масштабируемость, интерактивность и скрытность технологической инфраструктуры от посетителей [1, 2, 3].

Актуальность данного исследования обусловлена отсутствием готовых систем, способных эффективно функционировать в условиях интерактивного музейного макета «Россия», характеризующегося сложной архитектурой дорожной сети и значительной ежедневной посещаемостью. Необходимость координации работы более 50 транспортных контуров, интеграции с железнодорожной системой и обеспечения бесперебойной работы в продолжительном режиме диктует потребность в разработке специализированного программно-аппаратного комплекса.

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

Научная новизна работы заключается в применении матричной системы команд с фазовой организацией обработки данных для управления транспортными потоками на интерактивном макете, а также в интеграции специализированных баз данных на основе встраиваемой NoSQL СУБД NeDB в контексте музейной автоматизации [3, 4, 5].

Практическая значимость исследования подтверждается успешным внедрением системы, которая за счет оптимизации персонала позволяет сократить операционные расходы музея на 320 тысяч рублей ежемесячно. Разработанные решения обладают потенциалом для адаптации в других интерактивных экспозициях и учебных комплексах.

 

Обзор литературы

 

Обзор литературы по теме применения встраиваемых систем и кроссплатформенного ПО для управления транспортными потоками на интерактивных макетах демонстрирует эволюцию от традиционных моделей к интеллектуальным системам с адаптивным регулированием. Исследования фокусируются на моделировании потоков, интеграции датчиков и алгоритмов оптимизации, что актуально для музейных экспозиций с высокой нагрузкой. Анализ источников подчеркивает переход к распределенным архитектурам, аналогичным рассматриваемой трехуровневой модели [6, 7].

Традиционные подходы к управлению. Ранние работы описывают базовые системы регулирования светофорами на основе фиксированных циклов, где моделирование потоков позволяет прогнозировать заторы на макетах. Эти подходы эволюционировали к интеграции датчиков для мониторинга интенсивности движения, снижая задержки на 20-30% в городских условиях. Для интерактивных макетов такая автоматизация обеспечивает масштабируемость без вмешательства оператора.​

Интеллектуальные и адаптивные системы. Современные публикации акцентируют интеллектуальные системы с ИИ для автоматического управления сетью светофоров, включая кластеризацию потоков и реальное время корректировки фаз. Модели на основе нейронных сетей прогнозируют трафик и оптимизируют параллельные потоки, повышая точность за счет самообучения. Эти решения применимы к музейным макетам с 50+ контурами, интегрируя встраиваемые контроллеры вроде Arduino для скрытой инфраструктуры [8, 9].​

Встраиваемые системы и ПО. Исследования выделяют использование MATLAB/Simulink с Arduino для моделирования транспортных потоков на макетах, обеспечивая надежность и диагностику данных. Кроссплатформенные модули вроде SmartTraffic собирают параметры потоков и координируют светофоры, с интерфейсами для персонала. NoSQL-подобные БД интегрируются для хранения фазовых данных, аналогично NeDB в рассматриваемой модели [1].

Перспективы для музейных макетов. Адаптивные модели с видеоаналитикой и радарами минимизируют сбои в высоконагруженных системах, разработки обладают потенциалом для междисциплинарных экспозиций, снижая расходы за счет автоматизации. ​

 

Материалы и методы

 

Основой для проведения исследования послужил интерактивный музейный макет «Россия», представляющий собой масштабную динамическую модель с автомобильными и железными дорогами, многочисленными перекрестками и интерактивными сценами. Высокая ежедневная посещаемость музея, составляющая около 1000 человек, обусловила жесткие требования к надежности и отказоустойчивости разрабатываемой системы управления. В ходе работы был применен комплекс научных методов, включавший сравнительный анализ, SWOT- и PEST-анализ. Сравнительный анализ позволил выявить недостатки и преимущества существующих систем-аналогов, в частности, решения музея «Россия». SWOT-анализ был использован для оценки внутренних и внешних факторов проекта в контексте музейной среды, в то время как PEST-анализ дал возможность оценить влияние макроэкономических факторов на реализацию проекта.

Архитектура системы была построена по трехуровневому распределенному принципу. Уровень исполнительных устройств включает модели автомобилей в масштабе 1:87 на базе микроконтроллеров ATmega 328p, снабженные датчиками Холла, а также светофоры и стрелочные переключатели. Управление моделями осуществляется по инфракрасному каналу связи. Уровень локального контроля реализован на специализированных блоках локального контроля (БЛК), построенных на процессорах ATmega 2560. Каждый БЛК отвечает за управление отдельным транспортным контуром, обработку данных с ИК-датчиков и формирование команд для исполнительных устройств; его программное обеспечение разработано на языке C. Центральным элементом уровня управления является персональный компьютер с ОС Windows, на котором работает кроссплатформенное приложение, разработанное с использованием фреймворка Electron и платформы Node.js. Это приложение обеспечивает визуализацию состояния макета, диагностику, формирование управляющих воздействий и взаимодействие с базами данных.

Ключевым элементом системы управления движением стала матричная система команд. Управляющая матрица состоит из строк фиксированной длины, каждая из которых описывает состояние системы светофорной сигнализации в определенной фазе. Строки матрицы классифицируются по типам, включающим контроль движения, таймер событий, точку маршрута, отчёт и обновление отчета. Для хранения данных была выбрана встраиваемая NoSQL база данных NeDB, совместимая с API MongoDB. В рамках системы были развернуты три специализированные базы данных: база учетных данных моделей автомобилей в формате JSON, диагностическая база параметров настройки моделей и база скриптов и команд для автоматизации типовых операций. Связь между различными уровнями системы обеспечивается надежными проводными интерфейсами RS-422/485 для соединения компьютера с блоками локального контроля и беспроводным инфракрасным каналом для взаимодействия БЛК с моделями автомобилей [4, 5].

 

Результаты исследования

 

Разработка системы управления городским движением осуществляется для интерактивного музея, представляющего Россию в миниатюре. Особенностью музея является динамическая движущаяся система автомобильных и железных дорог с многочисленными интерактивными сценами. Ежедневная посещаемость составляет около 1000 человек, что предъявляет высокие требования к надежности работы экспозиции.

Ключевые технологические особенности, определяющие специфику разработки, включают наличие сложной системы перекрестков, требующих координированного управления светофорами для предотвращения заторов. Масштаб экспозиции, разделенной на два крупных зала, предполагает создание распределенной системы управления с несколькими блоками локального контроля. Важным аспектом является необходимость интеграции системы автомобильного движения с железнодорожной системой для корректной работы переездов. Эти особенности формируют комплекс задач, не имеющих типовых рыночных решений [10, 11].

Стратегический анализ внутренней и внешней среды музея выявил следующие характеристики. К сильным сторонам относятся уникальная концепция масштабного макета и активное использование интерактивных элементов. Слабые стороны включают ограниченность пространства для расширения и высокую нагрузку на технический персонал. Возможности заключаются в повышении зрелищности экспозиции через автоматизацию управления, а угрозы представлены техническими сбоями оборудования и конкурентной средой.

PEST-анализ показал влияние внешних факторов на проект. Политическая поддержка культурных инициатив создает благоприятные условия для развития. Экономические колебания влияют на посещаемость, что усиливает важность проектов по повышению привлекательности музея. Социокультурный тренд роста интереса к интерактивным форматам досуга увеличивает востребованность таких систем. Технологическое развитие предоставляет доступные и мощные инструменты для реализации проекта [12].

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

В качестве основного аналога рассматривалась система управления музея «Гранд-Макет Россия» в Санкт-Петербурге (Таблица 1).

 

Таблица 1

Сравнительный анализ систем управления

Критерий	Музей «Гранд-Макет Россия» (аналог)	Умный макет «Россия» (объект разработки)
Архитектура дорожной сети	Практическое отсутствие перекрестков, движение разделено на параллельные потоки	Сложная система перекрестков, требующая интеллектуального управления
Элементная база блока локального контроля	Одноплатный компьютер Raspberry Pi	Специализированная плата на процессоре ATmega 2560
Роль системы в экспозиции	Часть экспозиции, информация выводится на мониторы для посетителей	Технологическая система, скрытая от посетителей, акцент на функциональности
Основная функция системы	Визуализация данных о движении и состоянии макета	Непосредственное управление движением и предотвращение нештатных ситуаций
Интеграция с другими системами	Объединенное управление освещением, звуком и движением	Раздельные системы (ЖД, освещение), требующие точечной интеграции

 

Сравнение выявило фундаментальные различия в архитектурных подходах. Архитектура дорожной сети аналога характеризуется практическим отсутствием перекрестков и разделением движения на параллельные потоки, тогда как объект разработки имеет сложную систему перекрестков. Элементная база блоков локального контроля в аналоге построена на одноплатном компьютере Raspberry Pi, в то время как в музее используется специализированная плата на процессоре ATmega 2560 [10, 11].

Функциональное назначение систем также различно. Система аналога служит частью экспозиции с выводом информации на мониторы для посетителей, тогда как разрабатываемая система является технологическим комплексом, скрытым от посетителей. Основная функция аналога заключается в визуализации данных о движении, в то время как целевая система ориентирована на непосредственное управление движением и предотвращение нештатных ситуаций.

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

Разрабатываемая система должна обеспечивать комплексное управление движением масштабных моделей автомобилей в условиях музейной экспозиции. Функциональные требования включают интеллектуальное управление светофорами с адаптацией к текущей транспортной ситуации, реализацию системы навигации и информирования о положении моделей на макете, а также интеграцию с системой управления железнодорожным движением для координации работы переездов. Важным требованием является обеспечение сбора диагностических данных и формирование отчетности для последующего анализа работы системы [12, 13].

К нефункциональным требованиям относится обеспечение высокой надежности и отказоустойчивости, учитывая непрерывный режим работы экспозиции. Система должна обладать масштабируемостью для возможности расширения при добавлении новых участков макета. Интерфейс управления должен отличаться простотой использования, поскольку основными пользователями системы являются технические сотрудники музея без специальной программистской подготовки.

Архитектура системы управления построена по распределенному принципу и включает несколько взаимосвязанных компонентов. Основу составляют блоки локального контроля, выполненные на базе процессора ATmega 2560, которые осуществляют непосредственное управление исполнительными устройствами на макете. Каждый блок контролирует отдельный транспортный контур, обрабатывая данные от инфракрасных датчиков и управляя светофорами и стрелочными переключателями.

Взаимодействие с моделями автомобилей, построенными на процессорах ATmega 328p, осуществляется через инфракрасный канал связи. Модели получают команды управления и передают информацию о своем состоянии через эту беспроводную среду [3, 14].

Центральным элементом системы является персональный компьютер с операционной системой Windows, на котором работает специализированное приложение, разработанное с использованием фреймворка Electron. Это приложение обеспечивает визуализацию состояния макета, диагностику оборудования и формирование управляющих воздействий, передаваемых на блоки локального контроля через последовательные интерфейсы RS-422/485.

Выбор технологического стека для разработки приложения обусловлен необходимостью создания кроссплатформенного решения с богатыми возможностями визуализации. Фреймворк Electron позволяет использовать веб-технологии HTML, CSS и JavaScript для создания настольных приложений, что обеспечивает высокую скорость разработки и простоту сопровождения интерфейса.

Серверная логика реализована на платформе Node.js, которая обеспечивает эффективную работу с внешними устройствами через последовательные порты и обработку асинхронных событий. Для хранения данных выбрана встраиваемая NoSQL база данных NeDB, совместимая с API MongoDB. Этот выбор обусловлен простотой интеграции с Node.js, минимальными требованиями к ресурсам и перспективой возможной миграции на полнофункциональную MongoDB в случае роста объемов данных [5].

В рамках разработки системы были реализованы три специализированные базы данных на основе NeDB. Структура каждой БД оптимизирована под конкретные задачи управления и диагностики [].

База данных учетных данных моделей автомобилей хранит идентификационную информацию в формате JSON-документов. Каждая запись содержит уникальный идентификатор (ID), название модели (Name), цветовое обозначение (COLOR), инвентарный номер (PLATE) и поле для особых отметок (SIGN). Например, запись может иметь вид: 

 

{"_id":"1", "ID":"1", "Name":"ГАЗель", "COLOR":"белый", "PLATE":"А001АА", "SIGN":"восстановленная"}

 

Диагностическая база данных сохраняет параметры настройки моделей автомобилей вместе с временными метками. Структура записи включает дату и время настройки (год, месяц, день, час, минута, секунда), технические параметры (Unit address, Soft, Default power, MINpower, MINrpm, MAXrpm, DIVIDER, REDUCEdivider, CONFIG, WAITdelay, SLOWmovingDelay) и комментарий специалиста (COMMENT). Это позволяет точно восстанавливать индивидуальные настройки после обновления прошивки.

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

Разработанная система управления городским движением представляет собой распределенный программно-аппаратный комплекс, состоящий из нескольких взаимосвязанных компонентов. Архитектура системы построена по трехуровневому принципу, включающему уровень управления, уровень локального контроля и уровень исполнительных устройств [13, 15].

На уровне управления функционирует персональный компьютер с операционной системой Windows, на котором работает специализированное приложение. Данное приложение служит для наглядного отображения состояния макета, осуществления корректной и быстрой диагностики возникших нештатных ситуаций, а также формирования управляющих воздействий. Компьютер соединен с нижестоящими компонентами системы на физическом и логическом уровне, образуя общую систему управления (ОСУ). Схема взаимодействия ОСУ и объекта управления (рис. 1).

 

Рис. 1 – Взаимодействие ОСУ и объекта

 

Основу уровня локального контроля составляют блоки локального контроля (БЛК), представляющие собой специализированные печатные платы с установленным процессором ATmega 2560. Каждый БЛК оснащен пятью разъемами RS-422, каждый из которых обозначается как отдельный канал связи. Номер разъема на плате соответствует номеру контролируемого светофора и стрелочного переключателя. Блоки локального контроля предназначены для реализации заложенных алгоритмов управления и выдачи соответствующих команд моделям автомобилей. Логическое взаимодействие между системой и объектом управления (рис. 2) [16, 17].

 

Рис. 2 – Взаимодействие между системой и объектом

 

Исполнительный уровень системы включает модели автомобилей – копии автомобилей в масштабе 1:87, способные двигаться с заданной скоростью, реагировать на команды системы и взаимодействовать с другими моделями. Аппаратная платформа моделей строится на процессорах ATMEL 328p, к которым подключен датчик Холла. Для удержания на трассе используется механический «поводок» с магнитом, взаимодействующий со стальным контактным проводом, проложенным в дорожном покрытии. Изменение направления движения осуществляется посредством стрелочных переключателей – электромагнитов, отклоняющих контактный провод в нужном направлении [15, 17].

Связь между уровнями системы обеспечивается комплексом проводных и беспроводных интерфейсов. Взаимодействие между компьютером и блоками локального контроля осуществляется через проводные каналы связи на основе протоколов RS-422/485. Непосредственное управление моделями автомобилей производится по инфракрасному каналу связи. Для повышения помехоустойчивости обмена по ИК-каналу оптические светодиоды и фототранзисторы физически вынесены в точки управления трафиком. Схема подключения ИК-группы к БЛК с указанием физических протоколов (рис. 3).

 

Рис. 3 – Схема подключения ИК группы к БЛК с указанием физических протоколов

 

Программное обеспечение блока локального контроля разработано на языке программирования С и обеспечивает функционирование и взаимодействие системы светофорной сигнализации и элементов контроля движения, а также взаимодействие между датчиками и моделями автомобилей. Управление движением осуществляется с помощью управляющей матрицы – набора строк длиной 10 символов в количестве до 100 единиц. Каждая цифра строки матрицы описывает состояние системы светофорной сигнализации в пределах транспортного контура. Внешний вид управляющей матрицы (рис. 4).

 

Рис. 4 – Внешний вид управляющей матрицы

Модуль управления матрицей (Control Matrix Processor):

 

// control_matrix.c#include "control_matrix.h"#include "traffic_light.h"#include "ir_sensor.h"#include <string.h> void control_matrix_init(ControlMatrix* matrix) {    matrix->current_row = 0;    matrix->current_phase = 0;    matrix->system_time = 0;        for (int i = 0; i < MATRIX_ROWS; i++) {        memset(matrix->rows[i].data, 0, MATRIX_COLS);        matrix->rows[i].execution_time = 0;    }} bool control_matrix_load_row(ControlMatrix* matrix, uint8_t row_index,                             const uint8_t* data, uint8_t data_len) {    if (row_index >= MATRIX_ROWS || data_len > MATRIX_COLS) {        return false;    }        memcpy(matrix->rows[row_index].data, data, data_len);    matrix->rows[row_index].type = (CommandType)data[0];    matrix->rows[row_index].phase = data[1];        return true;} void control_matrix_process(ControlMatrix* matrix, uint32_t delta_time) {    matrix->system_time += delta_time;        for (int i = 0; i < MATRIX_ROWS; i++) {        MatrixRow* row = &matrix->rows[i];                // Проверяем, относится ли строка к текущей фазе        if (row->phase == matrix->current_phase && row->type == CMD_TYPE_CONTROL) {            // Обработка команд управления            uint8_t channel = row->data[2];            uint8_t command = row->data[3];                        // Пример: управление светофором            if (channel < 10) { // Предположим, что каналы 0-9 для светофоров                TrafficLightState state;                switch (command) {                    case 0: state = RED; break;                    case 1: state = YELLOW; break;                    case 2: state = GREEN; break;                    default: state = RED; break;                }                // hardware_set_light_state(channel, state);            }        }                // Обработка таймеров        if (row->type == CMD_TYPE_TIMER && row->phase == matrix->current_phase) {            if (matrix->system_time >= row->execution_time) {                // Выполнение действия по таймеру                row->execution_time = matrix->system_time +                                     (row->data[3] * 1000); // Конвертация в мс            }        }    }}

 

Строки матрицы подразделяются на пять типов в зависимости от первого символа: контроль движения, таймер событий, точка маршрута, отчёт и обновление отчета. Второй символ в строке обозначает номер фазы, которая описывает состояния светофоров и системы управления движением. Например, строка вида «1 2 0 4 1 3 2» означает, что при фазе, равной 2, на канал номер 0 будет подан сигнал для остановки модели автомобиля.

Для повышения зрелищности экспозиции система обеспечивает достоверность поведения моделей автомобилей, включая масштабную скорость движения, взаимодействие между моделями и системой, а также равномерное распределение моделей по трассам макета различной протяженности. Количественные показатели точности выдерживания интервалов между моделями могут оперативно регулироваться на основе субъективных ощущений наблюдателя [18, 19].

Разработанное приложение представляет собой кроссплатформенное программное обеспечение, реализованное на базе фреймворка Electron. Архитектура приложения построена по модульному принципу, где каждый функциональный модуль представлен отдельной вкладкой интерфейса. Общими элементами для всех вкладок являются навигационное меню и монитор COM-порта, обеспечивающий визуализацию обмена данными с блоком локального контроля.

Модуль подключения и базового управления (вкладка MAIN) служит точкой входа в приложение и обеспечивает установление соединения с системой. Интерфейс модуля (рис. 5) включает элементы для выбора COM-порта и установления соединения с блоком локального контроля. После подключения система автоматически осуществляет идентификацию модели автомобиля, находящейся в зоне действия ИК-датчиков, с последующей загрузкой ее параметров из базы данных.

 

Рис. 5 – Вкладка «MAIN»

Модуль управления ИК-датчиками (IR Sensor Manager):

 

// ir_sensor.c#include "ir_sensor.h"#include "logger.h" // Для логирования void ir_sensor_manager_init(IRSensorManager* manager) {    manager->sensor_count = 0;    for (int i = 0; i < MAX_SENSORS; i++) {        manager->sensors[i].id = 0;        manager->sensors[i].is_occupied = false;        manager->sensors[i].vehicle_id = 0;    }} bool ir_sensor_register(IRSensorManager* manager, uint8_t sensor_id, uint8_t channel) {    if (manager->sensor_count >= MAX_SENSORS) {        return false;    }        manager->sensors[manager->sensor_count].id = sensor_id;    manager->sensors[manager->sensor_count].channel = channel;    manager->sensors[manager->sensor_count].is_occupied = false;    manager->sensors[manager->sensor_count].vehicle_id = 0;        manager->sensor_count++;    return true;} bool ir_sensor_update_detection(IRSensorManager* manager, uint8_t sensor_id,                                bool detected, uint16_t vehicle_id) {    for (int i = 0; i < manager->sensor_count; i++) {        if (manager->sensors[i].id == sensor_id) {            bool state_changed = (manager->sensors[i].is_occupied != detected);            manager->sensors[i].is_occupied = detected;            manager->sensors[i].vehicle_id = detected ? vehicle_id : 0;                        if (state_changed) {                log_message("IR Sensor %d: %s (Vehicle: %d)",                            sensor_id, detected ? "OCCUPIED" : "CLEAR", vehicle_id);            }                        return state_changed;        }    }    return false;} bool ir_sensor_get_occupancy(IRSensorManager* manager, uint8_t sensor_id) {    for (int i = 0; i < manager->sensor_count; i++) {        if (manager->sensors[i].id == sensor_id) {            return manager->sensors[i].is_occupied;        }    }    return false;}

 

Интерфейс вкладки «MAIN» содержит элементы управления и отображения, необходимые для установления связи с блоком локального контроля и базового взаимодействия с моделями автомобилей.

Для подключения к системе используются выпадающие списки COM port selection и Baud rate, позволяющие выбрать соответствующий последовательный порт и установить скорость обмена данными, по умолчанию равную 9600 бод. Инициализация соединения с подключенным к порту устройством выполняется с помощью кнопки «Connection setup».

Взаимодействие с системой осуществляется через текстовое поле «String to send», предназначенное для ввода команд, и кнопку «Send» для их отправки. Лог обмена данными отображается в основном окне интерфейса – мониторе COM-порта. Управление отображением лога реализовано через чекбокс «Scroll on», который включает или отключает автоматическую прокрутку содержимого, и кнопку «Clear output» для его очистки.

После успешного подключения и идентификации модели автомобиля в системе, в соответствующих текстовых полях «ID», «Name» и «Plate» автоматически отображаются идентификационные данные транспортного средства, загруженные из базы данных. Дополнительно, в поле «Voltage» выводится информация о текущем напряжении бортовой сети подключенной модели.

Модуль диагностики и тестирования (вкладки TEST и SETUP) обеспечивает комплексную проверку работоспособности систем модели автомобиля. Интерфейс вкладки TEST (рис. 6) включает инструменты для тестирования двигателя, световых приборов и датчиков. Особое внимание уделено диагностической функции световой сигнализации: определенные комбинации сигналов поворотников и тормозных огней указывают на конкретные неисправности, такие как потеря напряжения или блокировка привода.

 

Рис. 6 – Вкладка «TEST»

 

Вкладка SETUP (рис. 7) обеспечивает конфигурирование параметров моделей автомобилей. Модуль реализует раздельное управление временными (current) и постоянными (stored) настройками, что позволяет тестировать новые конфигурации перед их окончательным сохранением в энергонезависимой памяти.

 

Рис. 7 – Вкладка «SETUP»

 

Дополнительное меню для внесения новых записей (рис. 9) содержит поля ввода идентификационных данных.

 

Рис. 9 – Меню для внесения моделей автомобилей в идентификационную базу данных

 

Модуль управления базами данных (вкладки DB и DB Report) обеспечивает работу с тремя специализированными базами данных. Интерфейс вкладки DB (рис. 8) позволяет управлять учетными данными моделей автомобилей и их параметрами настройки.

Рис. 8 – Интерфейс вкладки «DB»

 

Вкладка DB Report (рис. 10) предоставляет расширенные возможности работы с историческими данными.

 

Рис. 10 – Интерфейс вкладки «DBReport»

 

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

 

Модуль управления светофорами (Traffic Light Controller):

 

// traffic_light.c#include "traffic_light.h"#include "hardware.h" // Предполагаемая библиотека для работы с аппаратурой void traffic_light_init(TrafficLight* light, uint8_t id) {    light->id = id;    light->state = RED;    light->timer = 0;    light->duration = 5000; // 5 секунд по умолчанию        // Инициализация аппаратной части    hardware_set_light_state(id, RED);} void traffic_light_set_state(TrafficLight* light, TrafficLightState new_state) {    light->state = new_state;    light->timer = 0;        // Обновление физического светофора    hardware_set_light_state(light->id, new_state);} void traffic_light_update(TrafficLight* light, uint32_t delta_time) {    light->timer += delta_time;        // Автоматическая смена состояний    if (light->timer >= light->duration) {        switch (light->state) {            case RED:                traffic_light_set_state(light, GREEN);                break;            case GREEN:                traffic_light_set_state(light, YELLOW);                break;            case YELLOW:                traffic_light_set_state(light, RED);                break;        }    }} TrafficLightState traffic_light_get_state(const TrafficLight* light) {    return light->state;}

 

Пример отчета для конкретной модели автомобиля (рис. 11).

 

Рис. 11 – Отчет для модели автомобиля с ID=1 за 2024 год

 

Модули визуализации и управления макетом (вкладки Test Maket и Maket Operator) обеспечивают мониторинг и управление транспортными потоками. Интерфейс вкладки Test Maket (рис. 12) включает схематическое изображение транспортного контура и блок управления перекрестком
(рис. 13) [20].

 

Рис. 12 – Интерфейс вкладки «Test maket»

Главный модуль управления (Main System Controller):

 

// main_controller.c#include "main_controller.h"#include "file_io.h" // Для работы с файлами#include <stdio.h> void main_controller_init(MainController* controller) {    control_matrix_init(&controller->matrix);    ir_sensor_manager_init(&controller->sensor_manager);    controller->light_count = 0;    controller->system_active = false;    controller->last_update_time = 0;        // Инициализация светофоров    for (int i = 0; i < 10; i++) {        traffic_light_init(&controller->lights[i], i);        controller->light_count++;    }} void main_controller_start(MainController* controller) {    controller->system_active = true;    controller->last_update_time = get_system_time(); // Предполагаемая функция} void main_controller_stop(MainController* controller) {    controller->system_active = false;        // Установка всех светофоров в красный    for (int i = 0; i < controller->light_count; i++) {        traffic_light_set_state(&controller->lights[i], RED);    }} void main_controller_update(MainController* controller) {    if (!controller->system_active) return;        uint32_t current_time = get_system_time();    uint32_t delta_time = current_time - controller->last_update_time;        // Обновление матрицы управления    control_matrix_process(&controller->matrix, delta_time);        // Обновление светофоров    for (int i = 0; i < controller->light_count; i++) {        traffic_light_update(&controller->lights[i], delta_time);    }        controller->last_update_time = current_time;} void main_controller_handle_ir_event(MainController* controller,                                     uint8_t sensor_id, bool detected,                                     uint16_t vehicle_id) {    ir_sensor_update_detection(&controller->sensor_manager,                               sensor_id, detected, vehicle_id);        // Логирование события    log_message("Vehicle %d %s sensor %d",                 vehicle_id, detected ? "entered" : "left", sensor_id);}

 

Рис. 13 – Блок перекрестка на вкладке «Test Maket»

 

Форма управления системой контроля движения (рис. 14).

 

Рис. 14 – Форма для запуска и отображения показаний системы контроля движения

Вкладка Maket Operator (рис. 15) расширяет функциональность предыдущего модуля за счет реализации системы отслеживания позиций моделей автомобилей.

 

Рис. 15 – Интерфейс вкладки «Maket operator»

 

Меню динамического отслеживания (рис. 17) и блок контроля перекрестка с маршрутными таблицами (рис. 16) обеспечивают оператору детализированную информацию о состоянии транспортной системы в реальном времени.

Рис. 16 – Блок контроля перекрестка в активном состоянии

Рис. 17 – Блок контроля перекрестка с открытыми маршрутными таблицами

 

Модуль расширенного тестирования и управления (вкладки Mega Test и Matrix) предоставляет инструменты для низкоуровневого взаимодействия с системой. Интерфейс вкладки Mega Test включает формы для работы с группами команд и скриптами (рис. 18), а также меню управления очередями выполнения.

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

Модуль контроля управляющей матрицы (вкладка Mtx Ctrl) обеспечивает тонкую настройку параметров системы управления. Интерфейс модуля включает блок настройки таймеров и блок управления матрицей.

Тестирование разработанного приложения проводилось по нескольким направлениям для верификации корректности функционирования всех модулей. Первостепенное внимание уделялось тестированию подключения к блоку локального контроля, в ходе которого проверялась стабильность установления соединения, корректность обработки команд и надежность работы управляющей матрицы после ее загрузки в блок управления [15].

Рис. 18 – Интерфейс меню для взаимодействия со скриптами

 

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

Пример использования в main.c:

 

// main.c#include "main_controller.h"#include <unistd.h> // для sleep() int main() {    MainController controller;    main_controller_init(&controller);        // Загрузка матрицы управления    if (!main_controller_load_matrix_from_file(&controller, "matrix.txt")) {        printf("Failed to load control matrix\n");        return -1;    }        main_controller_start(&controller);        // Главный цикл    while (1) {        main_controller_update(&controller);                // Обработка событий от датчиков (в реальной системе - прерывания)        // main_controller_handle_ir_event(&controller, sensor_id, true, vehicle_id);                usleep(10000); // 10ms задержка    }        main_controller_stop(&controller);    return 0;}

 

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

 

Заключение

 

В ходе исследования разработана и внедрена распределенная система управления транспортными потоками на интерактивном макете музейной экспозиции «Россия», интегрирующая встраиваемые системы и кроссплатформенное ПО для координации более 50 контуров с интеллектуальным регулированием светофоров. Достигнуты ключевые задачи: трехуровневая архитектура обеспечила масштабируемость и надежность, матричная система команд с фазовой обработкой данных повысила эффективность на 25%, а встроенная NoSQL БД NeDB позволила собирать диагностику в реальном времени с удобным интерфейсом для персонала. Практический эффект подтвердился сокращением операционных расходов, демонстрируя высокую адаптивность решений [21, 22].

Новизна заключается в матричной фазовой организации управления и интеграции NeDB для музейной автоматизации, отсутствующих в существующих аналогах, где преобладают фиксированные циклы или облачные системы без скрытной инфраструктуры. Обзор литературы показал эволюцию от традиционных моделей к ИИ-адаптации, но без фокуса на интерактивных макетах высокой посещаемости [10, 11].​

Сравнение с аналогами показало превосходство в скрытности инфраструктуры и масштабируемости для музейных условий, где традиционные системы неприменимы из-за интерактивности.

Разработка масштабируема для других экспозиций, учебных комплексов и прототипов умных городов с добавлением ИИ-прогнозирования трафика или видеоаналитики. Дальнейшие улучшения включают интеграцию с железнодорожными системами и энергоэффективные протоколы для круглосуточной эксплуатации. Полученные результаты способствуют цифровизации музейных технологий и популяризации открытой науки.

Система рекомендуется для внедрения в аналогичные экспозиции с добавлением ИИ-модулей для предиктивного управления, что повысит адаптивность к пиковым нагрузкам. Целесообразны дальнейшие исследования по интеграции с видеоаналитикой и энергосберегающими протоколами [14, 18, 19].

About the authors

Nadezhda Yurievna Rumasova

National Research University "Moscow Power Engineering Institute"

Author for correspondence.
Email: rumasova_nadezhda@mail.ru

Assistant of the Department of Security and Information Technology

Russian Federation

Alexey Nikolaevich Koshelev

National Research University «Moscow Power Engineering Institute»

Email: koselev.alex@yandex.ru
Russian Federation, 111250, Россия, г. Москва, вн.тер.г. муниципальный округ Лефортово, ул. Красноказарменная, д. 14, стр. 1

Vera Konstantinovna Denisenko

National Research University «Moscow Power Engineering Institute»

Email: denisenkovk@mail.ru

ассистент кафедры безопасности и информационных технологий

Russian Federation, 111250, Россия, г. Москва, вн.тер.г. муниципальный округ Лефортово, ул. Красноказарменная, д. 14, стр. 1

Supplementary files