Описание функциональных характеристик программного обеспечения CShark

Идентификация предоставляемого экземпляра

1. Назначение

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

Документ описывает функции предоставляемого экземпляра в варианте demo. После установки создаётся вымышленный объект Демо-паркинг «Северный» без реального адреса и реквизитов юридического лица: один уровень, две зоны и 50 мест. В поставку входят Device Gateway, mock APS и необходимые эмуляторы.

2. Состав программного обеспечения

Компоненты поставляются как локальные контейнерные образы и запускаются через Docker Compose. Внутренние сервисы не требуют подключения к внешнему контейнерному registry.

3. Пользователи и разграничение доступа

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

Основные пользовательские контуры:

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

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

4. Топология объекта

Администратор формирует цифровую структуру парковочного объекта:

1. объект;
2. уровни;
3. зоны и пожарные отсеки;
4. парковочные места;
5. группы мест;
6. устройства и их привязки.

Для мест поддерживаются типы: стандартное (standard), для маломобильных групп населения (mgn), мотоциклетное (moto), служебное (service) и выделенное (vip). Возможность зарядки электромобиля задаётся отдельным признаком ev_charging. Для зон предусмотрены режимы: штатный (normal), пожар (fire), укрытие (shelter) и служебный (service). Геометрия мест и подложка уровня используются при отображении схемы.

В варианте demo seed 2026.07.2 создаёт один уровень, зоны Синий сектор и Зелёный сектор, а также 50 мест с кодами DEMO-01–DEMO-50. Среди них имеются места МГН, EV, moto и service. Реальные адреса, реквизиты организаций и кадры камер в базовом demo seed отсутствуют.

5. Операторская схема

Раздел схемы предназначен для контроля текущего состояния объекта. Он предоставляет:

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

Контекст объекта и уровня сохраняется в URL и используется связанными аналитическими представлениями.

6. Прием событий и состояние мест

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

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

Система хранит историю изменения состояния мест и использует снимки занятости для аналитики.

7. Инциденты

Подсистема инцидентов обеспечивает:

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

Действия оператора фиксируются в истории инцидента и журнале аудита.

8. Журнал посещений

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

9. Аналитика

Аналитический раздел отображает:

• сводные показатели по выбранному объекту;
• количество и долю занятых мест;
• динамику занятости;
• исторические снимки состояния;
• показатели по доступному временному диапазону.

Область данных должна быть явно указана: конкретный уровень, объект или совокупность объектов.

10. Оборудование

Реестр оборудования используется для камер, ворот, пожарных входов и эмулируемых устройств. Доступны:

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

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

11. Табло и экраны информирования

Подсистема информирования обеспечивает:

• ведение реестра табло;
• создание и редактирование шаблонов;
• предварительный просмотр шаблона;
• назначение шаблона конкретному табло;
• отображение счетчиков свободных мест и текстовых сообщений;
• приоритетное аварийное сообщение;
• ограниченный токен доступа для экранного клиента;
• обновление состояния назначенного экрана.

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

12. Администрирование

Административный контур включает:

• пользователей, роли и разрешения;
• параметры системы;
• топологию и геометрию;
• реестр устройств и интеграционные ключи;
• правила и Webhook-подписки;
• граф навигации и его версии;
• журнал аудита.

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

13. Интеграционные возможности

Core предоставляет HTTP API по опубликованной OpenAPI-схеме. Device Gateway поддерживает событийные контракты и команды оборудования. Для внешних систем предусмотрены API-ключи, Webhook-доставка и повтор доставки неуспешных сообщений.

Основные типы интеграционных данных:

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

14. Наблюдаемость и диагностика

Система предоставляет:

• endpoint готовности /api/health;
• статусы контейнеров;
• технические метрики Prometheus;
• дашборды Grafana;
• централизованные журналы Loki;
• распределенные трассировки Tempo;
• счетчики доставки и обработки событий.

Наблюдаемость предназначена для диагностики и не заменяет резервное копирование бизнес-данных.

15. Защита и устойчивость

В экземпляре реализованы следующие меры:

• ролевое разграничение доступа;
• отдельные роли базы данных;
• уникальные секреты экземпляра;
• ограниченные права на файлы конфигурации;
• журналирование действий;
• проверка схемы базы данных перед запуском Core;
• постоянная очередь Gateway;
• персистентный поток событий;
• контрольные суммы комплекта и локальных образов;
• резервное копирование базы данных и медиа.

16. Границы текущего экземпляра

Текущий комплект:

• предназначен для Ubuntu Server 24.04 LTS AMD64;
• не поддерживает ARM64;
• устанавливается в локальный контейнерный контур;
• в варианте demo создаёт только вымышленную демонстрационную парковку без реального адреса и реквизитов юридического лица; вариант clean демонстрационные парковки не создаёт;
• не включает промышленную интеграцию с конкретным оборудованием без его настройки;
• не заявляет автоматическое обновление из пользовательского интерфейса;
• не заявляет биллинг и управление зарядными станциями как функции предоставленного экземпляра.

17. Контроль функциональной доступности

После установки проверяют:

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