Буферное хранение видеоданных от 150 камер в течение 30 суток

В проекте подсистемы хранения видеоданных было задано конкретное функциональное требование: обеспечить буферное хранение данных от 150 камер в течение 30 суток. Экспертная проверка подтвердила именно эту проектную функцию — количество источников видеоданных и установленную глубину хранения.

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

Проектное требование к видеоархиву

Предметом работы была подсистема хранения видеоданных вычислительного комплекса. В рассматриваемом проектном решении для неё были одновременно установлены два параметра: обслуживание 150 камер и глубина буферного хранения 30 суток.

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

Поэтому проверочный вопрос относился не к отдельной цифре, а к проектной связке «150 камер — 30 суток». Именно эта связка определяет подтверждённое функциональное требование к подсистеме хранения.

Связка «150 камер — 30 суток»

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

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

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

Техническое заключение как основание подтверждения

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

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

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

Расчётная ёмкость при конкретных параметрах видеопотока

Требование «150 камер в течение 30 суток» ещё не является численным подтверждением фактически необходимого объёма дискового пространства. Для такого расчёта требуется знать характеристики данных, которые создают камеры в выбранной конфигурации.

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

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

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

Эксплуатационная проверка глубины архива

После ввода системы в работу возникает другой проверочный вопрос: обеспечивается ли заявленная глубина хранения фактически. Здесь документального подтверждения требования уже недостаточно. Необходимо установить, как система работает при реальной загрузке и какой объём видеоданных сохраняется в используемой конфигурации.

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

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

Поэтому итоговая доказательная граница точна: установлена проектная функция хранения данных от 150 камер в течение 30 суток; фактически достигнутая ёмкость и реальная глубина архива в эксплуатации требуют отдельного подтверждения.

Отличие хранения видеоданных от интеграции систем безопасности

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

В кейсе «Интеграция СКУД нескольких производителей в системе ситуационного контроля» проверяется другая зависимость. Там существенна архитектура объединения нескольких систем контроля доступа в единой информационной среде, а не глубина видеоархива.

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

Применение результата в аналогичной системе

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

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

Такое разделение позволяет не превращать проектное требование в неподтверждённую характеристику работающей системы. Для другого объекта количество камер, период хранения и условия эксплуатации должны оцениваться заново по его документации и фактической конфигурации. Другие примеры технических проверок представлены в разделе «Кейсы».