2023.12.25 DVLK-Sber Совещание по ЧТЗ
Дополнительные действия
Участники:
- Кульпин М.А. * Кокунько В.В. * Куликов А.С. * Грачевников А.С. * Глебов Б. * Коржебин О. * Комаров А.
Повестка:
1. VMS
1. Возможности интеграции (вендоры, объем интеграции, планы)
2. Возможности средств отображения в ЕЦС, реализованные кейсы/сценарии
3. Планы, которые можно учитывать при проработке ЧТЗ
2. СКУД
1. Возможности интеграции (вендоры, объем интеграции, планы)
2. Возможности средств отображения в ЕЦС, реализованные кейсы/сценарии
3. Планы, которые можно учитывать при проработке ЧТЗ
3. Демо генерации QR кодов, приглашений (прислать приглашения на один из наших номеров если возможно), возможности по изменению сообщения для резидентов;
4. ST IIOT Devops вопросы исходя из требований ОТЗ по архитектуре:
1. Как и какими средствами реализованы:
1. Масштабирование
1. Вертикальное
2. Горизонтальное
2. Отказоустойчивость
3. Балансировка
2. Вопрос к обучению - Best practice по проектированию и развертыванию платформы, можно несколько кейсов для разных запросов;
1. Например: из описания webui "_Экземпляр_ веб-панели инструментов - это копия панели инструментов, которая запущена или [кэширована](https://docs.iot.sberbank-tele.com/ls_wui_dashboards_caching.htm) в памяти SberMobile Server." правильно ли понимаю, что лучше разделить сервер сбора и обработки данных с серверов webui? в примерах расчета КТС учитывалась только нагрузка с устройств, количество пользователей там не учитывалось
2. Стоит ли разделять на разные сервера BMS и КСБ, сбор, обработку, хранение, сервер отчетов?
1. Если разделять их, то это будет один общий конфиг или несколько разных увязанных друг с другом, и изменяя настройки в одном, придется проходить по всем и вносить доп правки?
2. Рассказать общий подход к разделению модулей по серверам
3. Для чего используется RabitMQ в рамках платформы?
5. Можно ли получить какую-то часть хотя бы роадмап, при этом исходя из ответа понятно, что это не обязательство, а возможность. А после 02.2024 уточнить?
6. Устройства, пример. (вопрос к таблице по КТС, там построено на кол-в устройств и интенсивности обмена)
1. в случае со СКУД что будет устройством? сервер к которому подключаемся по API, контроллеры, точки доступа, все выше перечисленное отдельные устройства ?
2. Шлюз, контроллер у которого 1к сигналов разного типа;
Заметки:
- Предполагают сделать библиотеку экземплярных моделей * Экземплярная модель = шаблон * Взаимодействие с СД - на уровне фронта минимальное необходимых функций на стороне ЕЦС. * Как правило делают два монитора у оператора * Видеостена + 1 монитор оператора * АРМ оператора отдельно, Видеостена отдельно. Оператор управляет только своим АРМом, видеостена неуправляема * Заявка на пропуск создается как минимум с одним ИД. Заявки апрувит УК * Очень не хотят вытаскивать в себя функционал VMS. * Для таллера заложить логику вывода нужного функционала для зака. * Работа с архиво к ЕЦС не относится. исклчюаем из списка * видеостена скорее всего на стороне СВН. * Есть авария, можно провалиться на карточку камеры и попасть на интерфейс камеры. Где можно посмотреть рилтайм поток
Протокол:
- Пропуска (заявки) на резидентов может заводить УК, а также мастер-резидент. В этом случае потребуется валидация СБ (отложенная активация пропуска: ключи записываются в контроллер только после валидации) * Выполнение скриптов операторов происходит на стороне ServiceDesk. На стороне ЕЦС - только изменение статусов аварийных заявок. Функционал по работе с авариями будет уточняться на этапе проектирования, большая часть функционала находится в разработке. * АРМ оператора отдельно, Видеостена ЕЦС отдельно. Оператор управляет только своим АРМом, видеостена - дашборд (преднастроенный, выводит необходимую информацию по событиям) * Заявка на пропуск создается как минимум с одним идентификатором * В текущей итерации ЧТЗ в ЕЦС собираем события от VMS и аналитики, а также НСИ/НТИ в карточках активов. При необходимости можно провалиться к видеопотоку с камеры. * Сценарии по работе с VMS (работа с вендорским решением видеостена, архив) к ЕЦС не относится. исключаем из списка сценариев КСБ. * DVLK постараться выгрузить большую часть материалов по ЧТЗ в ЧТ (28.12) вечером * DVLK смержить перечень сценариев видеоаналитики и отправить в сторону ST * ST согласовать рабочий перечень сценариев КСБ для DVLK, который необходимо выполнить до конца года (перечень направлен через e-mail (19.12) и в TG (25.12) * ST отправить перечень сценариев видеоаналитики на согласование с Колди. * ST отправить перечень сценариев КСБ на согласование с Колди