ТЗ. Приложение № 1 к ЗД-Техническое задание (1). Техническое задание выполнение работ по модернизации опытного образца комплекса программных средств о

• Название: Техническое задание выполнение работ по модернизации опытного образца комплекса программных средств о
• Дата: 01.11.2021
• Размер: 0.84 Mb.
• Имя файла: Приложение № 1 к ЗД-Техническое задание (1).pdf
• Тип: Техническое задание; #260402
• страница: 2 из 5

Диаграмма:
Основные шаги сценария:

16 1) Абонент успешно проходит аутентификацию в Интерфейсе Продукта.
2) В Интерфейсе Продукта Абонент делает изменение тарифа и/или тарифных опций (например: измерение состава абонентского оборудования или увеличение времени хранения видеоархива с камер).
3) Изменения сохраняются в профиле Услуги в ОП (в АСР и ЕЛК изменения не передаются).
4) На основании внесѐнных в профиль Услуги изменений ОП формирует CDR файлы согласно прейскуранту с учетом тарифных классов.
Расширение сценария:
Принципы учета и тарификации:
По прейскуранту
3.3.10
Аутентификация на Интерфейсе Продукта при переходе из ЕЛК.
Действующие лица:
Абонента
Объекты взаимодействия:
ЕЛК, ОП
Примечание:
Предусловия:
У Абонента подключена Услуга, есть учѐтная запись в ЕЛК
Инициируется:
Абонентом
Нефункциональные требования:
Диаграмма:
Основные шаги сценария:
1) Абонент проходит аутентификацию в web-интерфейсе ЕЛК с использование учетной записи
ЕЛК.
2) Переходит в форму управления Услугой
3) Для управления опциями Услуги в интерфейсе ЕЛК должен быть визуальный элемент – ссылка на Интерфейс Продукта
4) При клике на ссылку абонент переходит на страницу аутентификации пользователя в
Интерфейсе Продукта. .
Расширение сценария:
Принципы учета и тарификации:
Не тарифицируется
3.3.11
Аутентификация на Интерфейсе Продукта.
Действующие лица:
Абонента
Объекты взаимодействия:
ЕЛК, ОП
Примечание:
Предусловия:
У Абонента подключена Услуга, есть учѐтная запись в ЕЛК
Инициируется:
Абонентом
Нефункциональные требования:
Диаграмма:
Основные шаги сценария:
1) Абонент открывает Интерфейс Продукта.

17 2) Вводит логин и пароль учетной записи
3) Проводится аутентификация с использованием введѐнных данных
4) В случае успешной аутентификации (логин/пароль верный) Абонент переходит на web- портал Услуги и сразу попадает в свой профиль Услуги.
5) В случае не успешной аутентификации (логин/пароль не верный) Абонент переходит на URL с сообщением об ошибке.
Расширение сценария:
Принципы учета и тарификации:
Не тарифицируется
3.3.12
Регистрация абонентского оборудования Услуги.
Действующие лица:
Абонент
Объекты взаимодействия:
Интерфейс Продукта, ОП
Примечание:
Предусловия:
У Абонента подключена Услуга
Подключение Абонента (мобильное устройство или браузер) и абонентского оборудования
(контроллер или видеокамера) происходит через одну и ту же точку доступа.
Инициируется:
Абонент
Нефункциональные требования:
Диаграмма:
Основные шаги сценария:
1) Абонент подключает контроллер к локальной сети;
2) Контроллер устанавливает соединение с Интерфейсом Продукта;
3) Интерфейс Продукта поддерживает список контроллеров, которые еще не были зарегистрированы Абонентом. Контроллеры в списке идентифицируются по публичному ip- адресу;
4) Абонент успешно проходит аутентификацию в Интерфейсе Продукта;
5) Интерфейс Продукта отображает Контроллер, находящийся в той же локальной сети, что и
Абонент, то есть с таким же публичным ip-адресом.
6) В Интерфейсе Продукта Абонент делает регистрацию абонентского оборудования (в АСР и
ЕЛК изменения не передаются).
7) Изменения сохраняются в профиле Услуги в ОП (в АСР и ЕЛК ничего не передаѐтся).
Расширение сценария:
5.1) Если Интерфейс Продукта не отображает Контроллер (в списке контроллеров нет Контроллера с подходящим ip-адресом), то у Абонента есть возможность добавить Контроллер по mac адресу
Контроллера.
Регистрация видео камер:
На этапе пилотного запуска будут использоваться видеокамеры только одной модели. Факт активации видеокамеры фиксируется на КПС, где Абонент должен согласиться с новым Тарифом для того, чтобы услуга видеонаблюдение для новой камеры стала активной.
Примечание:
У каждого Абонента Услуги в Интерфейсе Продукта может быть зарегистрирован один контроллер.
Принципы учета и тарификации:
По прейскуранту

18

19
4
Требования к системе
4.1
Функциональные требования
КПС должен предоставлять Пользователям следующие возможности:
 доступ к функциям камеры;
 просмотр статусов и событий;
 отображение состояния датчиков, счетчиков;
 управление сценариями и режимами;
 управление подключенными устройствами;
 управления основными функциями КПС с мобильных устройств;
 рассылка уведомлений.
Для выполнения возложенных функций, КПС должен включать в себя следующие функциональные подсистемы:
1) Подсистема авторизации и аутентификации пользователей;
2) Подсистема видеонаблюдения;
3) Подсистема регистрации и хранения событий;
4) Подсистема взаимодействия с управляющим контроллером;
5) Подсистема управления сценариями и режимами;
6) Подсистема регистрации подключенных устройств;
7) Подсистема уведомлений;
8) Веб-интерфейс пользователя;
9) Веб-интерфейс администратора;
10) Интерфейс для взаимодействия с мобильными приложениями;
11) Интерфейс для поддержки провиженинга и биллинга услуги «Умный дом».
4.1.1
Авторизация и аутентификация пользователей
Процесс авторизации пользователей выполняется по логину и паролю в КПС. Смена пароля и иные действия с учѐтной записью проводятся средствами облачной платформы. При успешной аутентификации и авторизации ЕЛК передает на ОП и КПС контактные данные абонента, его л/с в АСР, идентификатор
АСР и аутентификационные данные. Данные передаются по протоколу HTTPS.
В КПС должен быть реализован механизм управления личными данными пользователя.
Пользователь должен иметь возможность редактировать следующие данные:
 E-mail;
 номер телефона.
Подсистемы КПС должны функционировать по мультитенантной модели (одна система на множество пользователей). Под Тенантом подразумевается совокупность данных внутри системы, принадлежащих одному пользователю.
4.1.2
Видеонаблюдение
В КПС должны быть реализованы следующие функции в части доступа к функциям камеры:

20
 регистрация абонентского видео-оборудования (web-камеры установленные на PC и IP камеры) в профиле пользователя;
 выбор элемента видеонаблюдения;
 редактирование названия элемента видеонаблюдения;
 просмотр потокового видео от выбранного источника видеонаблюдения;
 сохранение видеопотока с абонентского оборудования;
 просмотр видеопотока в режиме реального времени;
 доступ к архивам записей с помощью удобного навигатора (календарь);
 выгрузка видеоматериала на устройство клиента в популярных форматах;
 сохранение отдельных кадров видеоматериала на устройство клиента;
 анализ движения и освещенности, уведомление о движении.
Спецификация протокола предоставляется Заказчиком.
4.1.3
Просмотр статусов и событий
В КПС должны быть реализованы следующие функции в части просмотра и управления статусами и событиями:
 отображение статуса соединения Контроллера с сервисом;
 просмотр последних событий с отображением списка сохраненных скриншотов и записей камеры и с возможностью их просмотра;
 возможность группировки событий по дате и времени;
 фильтрация событий по периодам;
 выбор типов оповещений для событий общего типа:

по электронной почте;

смс сообщениями;

push-уведомления.
События должны быть разделены на следующие группы:
 Системные события (включая критические события) – отражают изменения параметров устройств, факт выполнения сценариев и событий, которые требуют срочного внимания пользователя;
 Пользовательские события - отражают изменения, которые сделал пользователь.
4.1.4
Взаимодействие с контроллером
В КПС должны быть реализованы следующие функции в части взаимодействия с управляющим контроллером:
 регистрация управляющего контроллера;
 взаимодействие с управляющим контроллером умного дома посредством прямого постоянно открытого соединения;
 оповещение пользователя о потере связи с управляющим контроллером;
 регистрация датчиков, счетчиков, IP-видеокамер подключенных к Управляющему контроллеру с возможностью автоматического определения типа устройства;
 доступ к функциям датчиков, счетчиков.
4.1.5
Управление сценариями и режимами
В сервисе «Умный дом» должны быть реализованы следующие функции в части управления сценариями:

21
 создание, изменение, удаление и хранение сценариев взаимодействия локальных устройств;
 должна быть реализована возможность выбора следующих элементов сценария:

выбор простых условий;

выбор сложных условий;

выбор режимов, в которых данный сценарий будет выполняться;

выбор дополнительных условий;
 отображение списка сценариев;
 активация и деактивация сценариев;
 хранение базы шаблонов типовых сценариев;
 передача созданных сценариев и настроек в управляющий контроллер.
В части управления режимами в сервисе «Умный дом» должны быть реализованы следующие функции:
 создание, изменение, удаление и хранение режимов работы;
 отображение списка режимов работы;
 возможность переключение между преднастроенными режимами;
 создание пользователем собственного режима.
В сервисе «Умный дом» должны быть реализованы следующие режимы:
 «отключено»;
 «я дома»;
 «вне дома»;
 «персональный»;
 «в отъезде».
Точный список режимов должен быть составлен на этапе разработки промышленного образца комплекса программных средств «Умный дом».
4.1.6
Управление устройствами
Устройства в КПС должны быть разделены на типы, например:
 сенсоры;
 датчики тревоги;
 помещение;
 климат.
Точный список типов должен быть составлен на этапе разработки промышленного образца комплекса программных средств «Умный дом».
Каждое устройство должно быть определено совокупностью признаков. Каждый признак должен быть описан в соответствующем поле. При этом, следующие поля должны быть обязательными для всех устройств:
 идентификатор устройства;
 идентификатор приставки;
 имя устройства;
 расположение устройства;
 производитель;
 идентификатор продукта;
 тип устройства.
Также должна быть реализована возможность изменения списка обязательных и необязательных полей в зависимости от типа устройства.

22
В КПС должна быть реализована следующая функциональность в части управления подключенными устройствами:
 активация устройства;
 деактивация устройства;
 просмотр статусов подключенных устройств;
 просмотр информации о подключенных устройствах;
 подключение новых устройств;
4.1.7
Учет показателей счетчиков ЖКХ
В рамках пилотного проекта требования к учету показателей счетчиков ЖКХ не предъявляются.
4.1.8
Уведомления о событиях
В части рассылки уведомлений должна быть реализована возможность отправки в реальном времени сообщений на электронную почту, смс-сообщений и push-уведомлений а также уведомлений посредством вывода сигнализирующей информации на страницах веб-сервиса.
При этом рассылка уведомлений должна происходить с учетом настроек пользователя (адрес электронной почты, номер телефона) в части получения уведомлений по различным событиям.
Уведомления по электронной почте отправляются через почтовый сервер Заказчика по протоколу
SMTP.
Уведомления в виде смс-сообщений отправляются через смс-шлюз Заказчика по одному из указанных ниже протоколов:

протокол SMPP v.3.4 или выше

HTTP протокол (спецификация протокола предоставляется Заказчиком).
4.1.9
Веб-интерфейс пользователя
Веб-сервис пользователя должен состоять из следующих информационных блоков, предоставляющих доступ к функциям сервиса «Умный дом»:
 Блок «Рабочий стол» должен содержать следующие компоненты:

окно камеры (с элементами управления и доступа к функциям камеры);

просмотр последних событий с фильтром по времени;

блок с отображением состояния датчиков и сигналов, содержащий управляющие элементы и быстрый доступ к устройствам;

блок с возможностью активации и деактивации режимов;

блок с отображением критичных оповещений;
 Блок «События» должен содержать все типы событий с возможностью фильтрации по дате, по типу событий и по устройству:
 Блок «Мои устройства» должен содержать:

информацию о подключенных устройствах;

информацию о статусе подключенных устройств;

возможность добавления новых устройств;

возможность управления подключенными устройствами;

возможность управления названием и расположением подключенных устройств;

информацию с датчиков подключенных устройств;

23

информацию о подключенном абонентском видео-оборудовании, с возможностью добавления новых устройств;

возможность настройки элементов видеонаблюдения;

просмотр потока/скриншотов для выбранного элемента видеонаблюдения.

Блок «Сценарии» должен содержать:отображение списка сценариев с фильтрацией по режимам;

полнотекстовый поиск по списку сценариев;

запуск сценария вручную;

блок с отображением текущих созданных сценариев с указанием статуса
(задействован или не задействован);

управление сценариями (включение, отключение, редактирование и удаление).
 Профиль пользователя;

изменение фотографии;

изменение и добавление номеров телефонов;

изменение и добавление адресов электронной почты;

изменение адреса;

изменение пароля отмена аутентификации пользователя в мобильном приложении.
 Блок «Настройки» должен содержать:

Управление рассылкой уведомлений;

Управление мобильными устройствами для рассылки push-уведомлений;

Управление активными сессиями с возможностью их остановки.
 Блок «Помощь» должен содержать:

Возможность ведения списка часто задаваемых вопросов;

Возможность отображения списка часто задаваемых вопросов.
4.1.10
Веб-интерфейс администратора
Должен быть разработан интерфейс администраторов КПС, обеспечивающий взаимодействие специалистов службы эксплуатации Заказчика с КПС. В интерфейсе администраторы должны быть доступны следующие функции:
 Просмотр верхнеуровнего состояния системы;
 Просмотр параметров подключенных абонентов;
 Просмотр системных событий;
 Просмотр состояния подключенного оборудования.
Веб-интерфейс администраторов должен состоять из следующих разделов:
 Пользователи (тенанты);
 Устройства;
 Состояние системы;
 Настройки.
4.1.11
Интерфейс для мобильных приложений
Основные функции КПС должны быть доступны пользователям через мобильные приложения на устройствах под управлением ОС Android и iOS.
В КПС должен быть реализован следующий интерфейс взаимодействия (API) в части управления функциями с помощью мобильных устройств:

24
 авторизация в КПС;
 добавление контроллера;
 управление контроллером;
 добавление и удаление пользовательских устройств;
 управление подключенными устройствами;
 получение событий;
 получение справочников;
 возможность активации и деактивации режимов работы сервиса;
 отображение трансляции видеокамеры и сохраненных кадров, в том числе в полноэкранном режиме;
 включение и выключение записи видеотрансляции;
 включение и выключение активных сценариев.
4.1.12
Интерфейс для взаимодействия с контроллером
В КПС должен быть реализован следующий интерфейс взаимодействия (API) в части управления контроллером:
 авторизация в КПС;
 управление контроллером; o получение информации о контроллере; o текущее состояние; o версия прошивки; o восстановление конфигурации контроллера.
 добавление/удаление устройств;
 управление устройствами;
 получение информации о изменении состояния устройств;
 работа с режимами;
 работа с сценариями;
4.1.13
Поддержка провиженинга и биллинга услуги «Умный дом»
В КПС должен быть реализован следующий функционал в части поддержки провиженинга и биллинга услуги «Умный дом»:
 Создание/удаление профиля пользователя;
 Блокировка/разблокировка профиля пользователя;
 Получение списка пользователей;
 Получение статуса и данных по профилю пользователя;
 Получение информации о подключенных пользователем устройствах;
 Получение информации об отправленных уведомлениях;
 Получение информации о размере видеоархива.
4.2
Нефункциональные требования
4.2.1
Требования к надежности
Разработка должна выполняться с учетом необслуживаемого функционирования КПС в режиме
24/7/365.

25
Уровень надежности должен достигаться согласованным применением организационных, организационно-технических мероприятий и программно-аппаратных средств.
Надежность должна обеспечиваться за счет:
 применения технических средств, системного и базового программного обеспечения, соответствующих классу решаемых задач;
 своевременного выполнения процессов администрирования;
 соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;
 предварительного обучения пользователей и обслуживающего персонала.
КПС должен сохранять работоспособность и обеспечивать восстановление своих функций при возникновении следующих аварийных ситуаций:
 при сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке ОС, восстановление программы должно происходить после перезапуска ОС и запуска;
 при ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функций возлагается на ОС;
 при ошибках, связанных с программным обеспечением, восстановление работоспособности возлагается на ОС.
В рамках пилотного проекта комплекс программных средств «Умный дом», развернутый на инфраструктуре Заказчика должен обеспечивать функционирование при обслуживании до 2000 абонентов, из расчета на абонента: 1 видеокамера, от 2-х до 10-ти Z-Wave устройств.
Должна быть разработана методика масштабирования решения при увеличении нагрузки до 72 000 пользователей.
На этапе пилота при установке обновлений КПС допускается прерывание сервиса для клиентов. В промышленной эксплуатации установка обновлений не должна приводить к прерыванию сервиса.
На этапе пилота должно быть обеспечено резервное копирование виртуальных машин для всех компонентов КПС. В промышленной эксплуатации резервирование всех компонентов КПС должно обеспечиваться применением кластерных решений. Политики резервного копирования должны быть согласованы с Заказчиком и отражены в эксплуатационной документации.