Инженерная записка что это

Документирование по ГОСТ 34* — это просто

Что такое стандарты на документацию?

В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:

Самый любимый и популярный стандарт по разработке ТЗ. Единственное, не стоит забывать, что он крепко связан с другими стандартами серии и если вы получили ТЗ, выполненное по данному стандарту, крайне желательно придерживаться и других стандартов, даже если об этом нет прямых требований. Хотя бы в плане общей идеологии (о которой ниже)

Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.

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

Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.

К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.

Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.

Минусы стандартов

Основной минус всем очевиден — стандарты старые. В них заложено устаревшее представление об архитектуре автоматизированной системы. Например:

5.8. Чертеж формы документа (видеокадра)
В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения.

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

«Видеокадр» — это тоже документ, который выводился на текстовый дисплей. Дисплеи не всегда поддерживали нужные символы и нужное количество символов по горизонтали и строк по вертикали (а графику вообще не поддерживали). Поэтому тут тоже надо было дополнительно согласовывать формы всех экранных документов.

Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.

Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.

Что в стандарте хорошо

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

А стандарты ГОСТ 34 хороши еще и тем, что они составлялись умными людьми, обкатывались годами и у них есть четкая цель — максимально полно описать на бумаге сложную абстрактную сущность, которую представляет собой любая АСУ.

Когда вам требуется грамотно поставить задачу западным подрядчикам, которые про наши ГОСТы слыхом не слыхивали, можно также опираться на эти стандарты, а точнее на их контент, смысловую составляющую. Потому что, повторюсь, гарантия полноты информации дорогого стоит. Как бы мы себя не тешили высоким уровнем своего профессионализма, мы можем забыть включить в состав наших требований элементарные вещи, тогда как тот же ГОСТ 34.602-89 «помнит» обо всем. Если вам непонятно, как должен выглядеть результат работы западных подрядчиков, посмотрите на требования к документированию, к рекомендуемым разделам. Уверяю вас, лучше не придумать! Скорее всего, есть западные аналоги наших стандартов, в которых все может быть полнее, современнее и лучше. К сожалению, я с ними не знаком, так как не было пока ни одного случая, чтобы наших ГОСТов было бы недостаточно.

Как читать и понимать стандарты документации по ГОСТ серии 34

Стандарт делит все документы по двум осям — время и предметная область. Если посмотреть таблицу 2 в ГОСТ 34.201-89, то хорошо видно это деление (колонки «Стадия создания» и «Часть проекта»

Стадии создания АСУ

Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к документированию из них три:

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

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

Части (разделы) проектной документации по созданию АСУ

Предметная область разделена на «Обеспечения». Поначалу кажется, что такое деление избыточно и ненужно. Но когда начинаешь на практике работать этим инструментарием, постепенно доходит вложенная в него идеология.

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

Для того, чтобы полностью описать этот «автомат», сделаны следующие разрезы (как в черчении):

Математическое обеспечение (МО), отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?

Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса — почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.

Информационное обеспечение (ИО). Еще один срез системы. На этот раз делается прозрачным черный ящик нашей системы и мы смотрим на циркулирующую в нем информацию. Представьте себе модель кровеносной системы человека, когда все остальные органы невидимы. Вот что-то подобное и есть Информационное обеспечение. В нем описываются состав и маршруты прохождения информации внутри и снаружи, логическая организация информации в системе, описание справочников и систем кодирования (кто делал программы для производства, тот знает, как они важны). Основная описательная часть приходится на этап ТП, но в этап РД перетекают некоторые «рудименты», наподобие документа «Каталог баз данных». Понятно, что раньше он содержал именно то, что написано в названии. Но сегодня попробуйте для сложной комплексной системы сформировать такой документ, когда очень часто в составе системы используются покупные подсистемы со своими загадочными информационными хранилищами. Я уж не говорю о том, что этот документ не особенно сейчас и нужен.

Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?

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

Программное обеспечение (ПО). Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю.

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

Техническое обеспечение (ТО). Не менее любимая всеми часть проектной документации. Радужную картину омрачает только обилие документов, которые требуется разрабатывать. Всего по стандарту требуется разработать 22 документа, из них 9 на стадии ТП.

Дело в том, что стандарт предусматривает описание всего технического обеспечения, включая компьютерное «железо» и сети, инженерные системы и даже строительную часть (если потребуется). А это хозяйство регламентируется громадным количеством стандартов и нормативных актов, согласуется в разных организациях и поэтому удобнее все дробить на части и согласовывать (править) по частям. В то же время стандарт позволяет объединять некоторые документы друг с другом, что имеет смысл делать, если всю кучу согласует один человек.

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

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

На стадии ТП раздел содержит всего один документ «Описание организационной структуры», в котором мы должны рассказать заказчику, к чему он должен готовиться в плане изменения оргштатной структуры. Вдруг требуется организовать новый отдел для эксплуатации вашей системы, ввести новые должности и т.п.

На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.

Руководство пользователя. Комментарии излишни, я думаю.

Методика (технология) автоматизированного проектирования. В этот документ при необходимости можно поместить описание процесса сборки ПО, управления версиями, тестирования и т.п. Но это если в ТЗ заказчик желает самолично осуществлять сборку ПО. Если он этого не требует (и не платит за это), то вся ваша внутренняя кухня не его ума дело, и этот документ делать не нужно.

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

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

Технологическая инструкция является прослойкой между ОРД и руководством пользователя. РП подробно описывает как нужно делать те или иные действия в системе. Технологическая инструкция говорит о том, какие действия необходимо выполнять в тех или иных случаях, связанных с эксплуатацией системы. Грубо говоря, технологическая инструкция это краткий дайджест по РП для конкретной должности или роли. Если у заказчика роли не сформированы или он хочет, чтобы вы сами сформировали роли и требования к должностям, включите в документ самые базовые роли, например: оператор, старший оператор, администратор. Замечания заказчика на тему, «а у нас не так» или «а нам не нравится» должны сопровождаться перечнем ролей и описанием должностных обязанностей. Потому что бизнес-процессы мы не ставим. Мы эти бизнес-процессы автоматизируем.

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

Описание технологического процесса обработки данных (включая телеобработку). Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик. Эта инструкция — для них. Что в нее писать в XXI веке — я вам точно сказать не могу. Выкручивайтесь сами. Самое лучшее, это просто забыть про этот документ.

Общесистемные решения (ОР). Стандартом предусмотрено 17 документов раздела ОР. Во-первых, это почти все документы предварительной фазы Эскизного проектирования. Во-вторых, это всевозможные сметы, расчеты и краткие описание автоматизируемых функций. То есть, информация для людей не с основного ИТ-производства, а для вспомогательного персонала — менеджеров, сметчиков, специалистов по закупкам, экономистов и т.п.

А в-третьих, в состав ОР входит мега-документ под названием «Пояснительная записка к техническому проекту», который по задумке представляет собой некий Executive Summary, а по факту многие проектанты пихают в него вообще все полезное содержание стадии ТП. Подобный радикальный подход бывает оправдан и даже взаимно выгоден и заказчику и исполнителю работ, но в определенных случаях.

Варианты использования ГОСТ 34

Заключение

Эта статья была о наших ГОСТах на документирование АСУ. ГОСТы старые, но, как оказалось, до сих пор очень даже полезные в хозяйстве. Не считая некоторые явные рудименты, структура документации обладает свойствами полноты и непротиворечивости, а следование стандарту снимает многие проектные риски, о существовании которых мы можем по началу не догадываться.

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

Источник

Документация об открытом аукционе (стр. 2 )

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4

к информационной карте

Инженерная записка должна быть составлена в следующем порядке:

-Номер конкурса и наименование темы, указанной в Извещении на проведение конкурса.

-Краткий обзор состояния проблемы (сравнение с отечественным и зарубежным уровнем).

-Обоснование предлагаемого направления решения проблемы.

-Характеристика исследуемой научно-технической продукции.

-Основные технические характеристики базового варианта (сравнение с отечественными и зарубежными аналогами), перспектива улучшения характеристик и адаптации под требования Заказчика.

-Ожидаемые эксплуатационные характеристики перспективного образца (надежность, необходимость специального обучения персонала, безопасность, ресурсосбережение, ремонт, модульные решения и эксплуатация в различных условиях, ограничения при эксплуатации).

-Ожидаемые экологические характеристики (безотходная эксплуатация, утилизация отходов, отсутствие отложенных экологических проблем).

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

-Основные экономические эффекты от результатов проведения ОКР.

-Описание основных методов решения задачи.

-Законодательные и правовые проблемы использования новой техники в Российской Федерации и МВД России, предлагаемые направления их решения и возможности Участника размещения заказа содействовать их решению (в перспективе).

Для раскрытия существа заявляемой ОКР Участник размещения заказа должен представить ответы на выше поставленные вопросы в сжатой форме (не более 4 машинописных листов). В Инженерной записке Участник размещения заказа может представить дополнительные сведения, отражающие специфические подходы к решению задачи.

Инженерная записка подписывается руководителем организации и заверяется печатью.

Участником размещения заказа предоставляются копии лицензий, заверенные установленным порядком:

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

к Информационной карте

на проведение работ по теме: «Разработка техно-рабочего проекта распределённой системы видеонаблюдения, отвечающей требованиям программы «Безопасный город».

1.1 Наименование работы – ОКР «Разработка техно-рабочего проекта распределённой системы видеонаблюдения, отвечающей требованиям программы «Безопасный город»

2.Цель работы, назначение изделия.

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

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

2.2 Разработка технического решения для создания современной, перспективной СВН, обеспечивающей решение следующих основных задач:

· обеспечение немедленного реагирования силами органов внутренних дел на возникновение криминальных происшествий в зонах города, охваченных СВН;

· обеспечение контроля над своевременностью и правомерностью работы органов внутренних дел, а также других городских служб в зонах города, охваченных СВН;

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

· возможность ограниченного санкционированного доступа и совместного использования видеоинформации, другими заинтересованными организациями (банками, охранными службами и т. п.);

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

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

3. Основание для разработки.

3.1 Основание для выполнения работы:

Поручение Президента Российской Федерации по итогам заседания Государственного совета в г. Казани 26 сентября 2005 года № Пр-1564 и решение совещания при главе города Владимира от 01.01.2001 г. и.

3.2 Сроки выполнения работ:

— окончание – IV квартал 2007 г.

4. Заказчик и Исполнитель работ

4.1 Заказчик – Администрация г. Владимира.

4.2 Исполнитель – определяется на конкурсной основе.

5. Тактико-технические требования

5.1 В результате ОКР должны быть разработаны:

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

5.1.1. Технический проект распределённой системы видеонаблюдения должен быть выполнен в соответствии с ГОСТ 34.201-89 и содержать следующие документы:

анализ существующих технических решений по реализации распределённого видеонаблюдения;

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

описание и обоснование выбора технического решения;

основные тактико-технические характеристики и состав выбранного технического решения для создания распределённой системы видеонаблюдения;

описание способов сопряжения оборудования распределённой системы видеонаблюдения с оборудованием действующих проводных сетей (телефонных, передачи данных и т. д.), обеспечивающих интеграцию действующих сетей видеонаблюдения в единую систему;

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

5.1.2 В рамках работ по проектированию распределённой системы видеонаблюдения в соответствии с ГОСТ 21.101-97 должна быть разработана, следующая проектная документация:

· рабочие чертежи, предназначенные для производства строительных и монтажных работ;

· спецификации оборудования, изделий и материалов;

· сметную документацию, выполненную в соответствии с требованиями сборников федеральных единичных расценок (ФЕР-2001) и государственных элементных сметных норм (ГЕСН-2001);

· сметную документацию, необходимую для закупки оборудования распределённой системы видеонаблюдения, производства строительно-монтажных работ и работ по вводу оборудования в эксплуатацию;

· расчеты по определению санитарно-защитной зоны (СЗЗ) и зоны ограничения застройки (ЗОЗ) для выбранных мест установки комутационного и серверного оборудования в соответствии с требованиями СанПиН 2.1.8/2.2.4.1190-03.

5.2 Требования к СВН.

5.2.1 Общие требования.

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

5.2.1.2 В состав СВН должно входить:

· центральный диспечерский центр (ЦДС);

· объектовое оборудование видеонаблюдения (ООВ);

· абонентское оборудование пользователей системы.

Список объектов наблюдения приведен в Приложении 1 к Техническому заданию.

5.2.1.3 Организационно СВН должна быть территориально распределена, чтобы авария, произошедшая на одном участке СВН, не приводила к отказу системы в целом или потере накопленных данных.

5.2.1.4 Энергопитание устройств должно быть зарезервированным на время не менее 3 часов штатной работы для периферийного оборудования и круглосуточной работы пультов контроля/управления, систем администрирования и хранения данных.

5.2.1.5 Система должна иметь возможность подключения других модулей, информационных подсистем сходного назначения (например, устройств оперативной видеосвязи граждан с ОВД, организации видео-«горячей линии» между гражданами в территориальных пунктах милиции и руководством ОВД, и других сходных случаев внешней подачи видеопотока) к системе транзита и регистрации видеоинформации.

5.2.1.6 СВН должна является средством документирования видеоинформации с точной фиксацией даты и времени каждого кадра.

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

5.2.1.8 Математические алгоритмы распознавания и анализа, запрограммированные в СВН, должны позволять производить слежение за объектами с автоматическим определением скорости, автоматически фокусировать поворотные камеры для получения крупных планов объектов (в т. ч. и людей), определять номера автомобилей, производить поиск видеокадров в архиве по параметрам цвета, размера и геометрии объекта.

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

5.2.2 Требование к аппаратуре ЦДС.

5.2.2.1 В аппаратуре ЦДС должна быть реализована аппаратура:

· серверы и дисковые массивы;

· автоматизированные рабочие места операторов и администраторов;

· аппаратура связи, коммутации и сопряжения.

5.2.2.2 Серверы и дисковые массивы должны обеспечивать:

· ежесуточный сбор и хранение видеоинформации в цифровом виде с локальных территориально удаленных видеорегистраторов для долговременного хранения не менее 1 месяца (уточняется на этапе технического проектирования);

· доступ к видеоинформации операторов и других абонентов в соответствии с назначаемыми правами;

· функции поиска по дате, объекту наблюдения, гос. номеру и типу транспортного средства и т. д.;

· управление видеокамерами: включение-выключение записи, индивидуальную настройку параметров изображения для каждой камеры: яркость, цвет, контраст, а также временного интервала записи предтревоги и послетревоги;

· управление исполнительными устройствами видеокамер;

· мониторинг работоспособности компонентов системы: обработка и хранение событий, генерируемых видеорегистраторами, нарушения связи, параметров видеорегистраторов;

· видеоинформация должны сохраняться в единой базе для всех регистраторов;

· параметры должны сохраняться в единой базе для всех регистраторов с определенной заданной периодичностью;

· возможность синхронизации событий на центральный сервер событий при разрыве связи, неработоспособности центрального сервера и при других нештатных ситуациях (локальная копия событий за определенный период должна храниться на каждом видеорегистраторе);

· возможность управления работой удаленного локального видеорегистратора (перезагрузка компьютера, запуск ПО) и обновления конфигураций и версий программных модулей;

· возможность расширения списка типов событий и типов параметров;

· оперативный мониторинг событий на рабочем месте администратора распределенной системы видеонаблюдения;

· просмотр архива событий (фильтрация по типу событий, дате, видеорегистратору и другим параметрам);

· автоматическое и ручное удаление данных при превышении длительности хранения;

· возможность экспорта видео данных на внешние носители;

· возможность распечатки видео данных на принтере;

· администрирование системы: назначение прав пользователей, разграничение доступов, ведение протоколов работы пользователей;

· спряжение с информационными подсистемами (электронная карта города Владимира (масштаб не менее 1:, система «Поток» или аналог, система «Портрет-поиск» или аналог)

5.2.2.3 Автоматизированные рабочие места операторов и администраторов должны обеспечивать:

· Прием и обработку потока информации, поступающей от объектового оборудования.

· Разрешение для цифровых устройств отображения видеоинформации не хуже 1024×768 элементов изображения.

· Обработку цветного изображения.

· Управление отображением видеоинформации.

· Формирование мультиэкранного изображения с возможностью одновременного просмотра не менее 16 видеокамер.

· Возможность распечатки или экспорта выбранного кадра («стоп-кадр»).

· Взаимодействие со средствами архивирования видеоинформации для просмотра архивов.

· Возможность просмотра изображения с видеокамер или архива в полноэкранном режиме.

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

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

· Возможность дистанционного управления исполнительными устройст­вами.

· Протоколирование всех действий оператора на АРМ.

· Сохранение работоспособности при кратковременном пропадании электропитания.

· Отображение на электронной карте города Владимира мест установки видеокамер и объектов наблюдения.

5.2.2.4 Аппаратура связи, коммутации и сопряжения должна обеспечивать:

· Связь между компонентами системы и другими структурными единицами должна осуществляться круглосуточно.

5.2.2.5 Размещение технологического оборудования, оборудования жизнеобеспечения и безопасности, организация автоматизированных рабочих мест (АРМ) ЦДС оп­ределяется на стадии проектирования в соответствии:

· ГОСТ 12.2.006 «Система стандартов безопасности труда»; ГОСТ 17.1005-88 «Санитарные нормы по безопасности труда»; Сан П и Н 2.2.2.542-96 «Гигиенические требования к видеодисплейным терминалам, персональным электронным вычислительным машинам и ор­ганизация работ»;

· СН и П «Естественное и искусственное освещение»; СН и П 2.08.01-89 и СН и П 2.08.02-89 «Электрооборудование жилых и общественных зданий и сооружений»;

· ГОСТ 27.570.0 «Электробезопасность»;

· СН и П «Пожарная безопасность зданий и сооружений».

5.2.2.6 Требования к технологическим помещениям ЦДС:

Технологические помещения ЛЦМ должны соответствовать следующим условиям:

· Площадь не менее 16 кв. м.

· Влажность не более 70%.

· В помещение не должен попадать прямой солнечный свет.

· Необходимо предусмотреть аварийное освещение.

· По периметру помещения должна быть уложена шина заземления, соединенная с контуром заземления, выполненным в соответствии с ПУЭ;

· Все металлические конструкции (батареи и др.) должны быть закрыты экранами из электроизоляционных материалов.

· Полы в помещениях должны быть антистатическими.

· Помещения должны быть оборудованы средствами пожаротушения.

· В помещениях должны быть установлены пожарная и охранная сигнализация.

· Напряжение 220В, 50 Гц, необходимое для электропитания кондиционе­ров, освещения и розеток (2 шт.), должно быть подано от отдельного автомата.

· На окнах должны быть установлены решетки.

· Входные двери должны быть металлическими.

· В помещение для электропитания технологического оборудования должно подводиться напряжение 220 В, 50 Гц общей мощностьюкВт. Должен быть установлен электрощит с вводными автоматами (по 40 А каждый) электропитания на нагрузку 10-30 кВт подаваемого от двух лучей и выходными автоматами (ориентировочно на 20 автоматов).

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

5.2.2.7 Требования к техническим средствам охраны ЦДС

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

Работы по подготовке помещения для ЦДС, в соответствии с требова­ниями к ЦДС, выполняются подрядной организацией.

5.2.2.8 Общие требования к аппаратно-программным средствам ЦДС

Аппаратно-программные средства ЦДС должны обеспечивать функ­ционирование в составе локальной вычислительной сети.

Специализированное программное обеспечение должно функциониро­вать в среде операционных систем Linux или Windows или других ОС.

Программное обеспечение должно содержать средства диагностики:

· Несанкционированного доступа извне.

5.2.3 Требования к аппаратуре объектового оборудования видеонаблюдения (ООВ).

5.2.3.1 Состав объектового оборудования определяется на этапе проектирования в зависимости от индивидуальных характеристик объекта наблюдения и в общем случае может состоять из:

· цветные стационарные видеокамеры;

· цветные управляемые поворотные камеры;

· средства дистанционного управления исполнительными устройствами;

· линии связи с видеокамерами;

· аппаратура сопряжения с линиями связи и каналом передачи информации;

· аппаратура дополнительного освещения;

· аппаратура резервного питания.

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

5.2.3.2 Технические требования к видеокамерам:

· тип видеокамеры (аналоговая или цифровая) определяется при проектировании;

· управляемые поворотные цветные камеры с разрешением не менее 540 твл. Чувствительность не менее 0,04 лк. При недостаточности освещения должна быть обеспечена возможность переключения камеры в черно-белый режим («ночь»). Камера должна быть оборудована оптическим трансфокатором с кратностью не менее 20;

· цветные стационарные видеокамеры разрешением не менее 470 твл. Чувствительность не менее 0,1 лк. При недостаточности освещения должна быть обеспечена возможность переключения камеры в черно-белый режим («ночь»);

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

Выбор места установки видеокамер следует производить, по согласованию с УВД г. Владимира, из расчета:

· обеспечения максимальных углов обзора и отсутствия непрозрачных помех (препятствий);

· при организации освещения в зоне видеонаблюдения недопустима избыточная освещенность (блики, тени) или недостаточная освещенность;

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

5.2.3.3 Технические требования к исполнительным устройствам и средствам
дистанционного управления:

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

· исполнительные устройства должны позволять управлять дополнительным освещением.

5.2.3.4 Технические требования к видеорегистраторам:

· Запись и хранение принятой цифровой видеоинформации не менее 3 суток. Скорость записываемого цифрового видеопотока от каждой камеры должна быть не ниже скорости аналогичного потока, выводимого на АРМ оператора, но не менее 1 кадр/с. Должна быть предусмотрена возможность установки скорости записи видеоинформации от выбранной видеокамеры не менее 25 кадр/с, при сохранении скорости записи видеопотока от прочих видеокамер не менее 1 кадр/с.

· Оцифровку сигнала, поступающего от аналоговых видеокамер, при скорости до 25 кадр/с и разрешении от CIF(352×288) до 4CIF(704×576).

· Обработку и сжатие оцифрованного видеосигнала.

· Индивидуальную настройку параметров изображения для каждой камеры: яркость, цвет, контраст, а также временного интервала записи предтревоги и послетревоги.

· Передачу обработанной видеоинформации для дальнейшего анализа и хранения.

· Сохранение работоспособности при кратковременном пропадании электропитания.

· Аутентификацию при доступе к настройкам средств обработки.

5.2.4 Технические требования к аппаратуре абонентского оборудования пользователей системы аналогичны требованиям к автоматизированным рабочим местам операторов.

5.2.5 Требования к характеристикам взаимосвязей СВН со смежными системами:

· информационное взаимодействие между СВН и другими системами может осуществляться по выделенным каналам передачи информации. Каналы передачи информации должны быть согласованы с Заказчиком на этапе проектирования СВН.

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

· средства передачи данных должны предоставлять технические ресурсы для сопряжения со средствами СВН.

· перечень смежных ведомственных информационные системы» href=»/text/category/avtomatizirovannie_informatcionnie_sistemi/» rel=»bookmark»>автоматизированных информационных систем г. Владимира, а также других ведомств и организаций, с которыми нужно обеспечить информационное взаимодействие, уровни, права и регламенты доступа потребителей к необходимым информационным ресурсам согласовываются и утверждаются Заказчиком.

· удаленный доступ заинтересованных организаций и ведомств к информации, хранимой в СВН, контролируется и осуществляются через ЦДС на основе определенных регламентом прав доступа.

5.2.6 Требования к единому стандарту интерфейсов сопряжения компонентов СВН.

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

5.2.7 Требования к защите от помех и электромагнитной совместимости.

Система должна быть устойчива к воздействию электромагнитных помех и соответствовать:

· ГОСТ Р 51318.22-99 «Совместимость технических средств электромагнитная. Радиопомехи индустриальные от оборудования информационных тех­нологий».

· ГОСТ Р 51318.24-99 «Совместимость технических средств электромагнитная. Устойчивость оборудования информационных технологий к электро­магнитным помехам».

5.2.8 Конструктивные требования:

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

5.2.9 Требования к условиям эксплуатации:

Подсистемы СВН должно сохранять работоспособность при следующих значениях климатических факторов:

· Оборудование СВН должно сохранять работоспособность при вибрационных нагрузках в диапазоне частот от 5 до 35 Гц при максимальном ускорении 0,5 g (5 м/с2).

· Оборудование СВН должно сохранять работоспособность после воздействия одиночных механических ударов (значение пикового ускорения 50 м/с2).

Оборудование СВН в упаковке должно выдерживать при транспортировании:

· Транспортную тряску с ускорением 30 м/с2 при частоте от 10 до 120 ударов в минуту.

· Относительную влажность 95±3% при 308 °К (35°С).

Линии связи и оборудование СВН должны сохранять требуемую работоспособность в условиях грозы и других неблагоприятных природных явлений.

5.2.10 Требования к диагностированию.

При создании СВН должно быть предусмотрено автоматизированное диагностирование работоспособности ее технических и программных средств.

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

Требования по диагностированию СВН могут быть уточнены по согласованию Заказчика и Исполнителя в процессе создания системы.

5.2.11 Направления развития и модернизации системы

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

Перспективное развитие (модернизация) СВН и ее составных частей должны осуществляться без нарушения работоспособности всей системы.

Возможности взаимодействия с существующими и разрабатываемыми информационными системами.

Трансляция изображения с видеокамер на электронные рекламные щиты и по каналам кабельного телевидения.

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

Подключение квартир граждан на охрану (пожар, вторжение) по согласованию с ГУВД, УВО, ГУ ГО ЧС.

Внедрение считывателей идентификационных электронных ключей на объектах социально-культурной сферы.

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

Внедрение индивидуальных тревожных кнопок (радиобрелков) с опре­делением местонахождения владельца с точностью не менее 10 м при приеме тревожного сигнала и передачу сигнала квитанции о принятом тревожном сигнале.

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

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

5.2.12 Требования к численности и квалификации персонала

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

Штатная численность эксплуатационного персонала СВН определяется и обеспечивается Пользователем с учетом проектных рекомендаций.

Первичная подготовка и обучение персонала эксплуатации и использова­нию средств СВН должны осуществляться Исполнителем до ввода сис­темы в опытную эксплуатацию в рамках заключенных с Заказчиком догово­ров.

Допуск персонала к самостоятельной эксплуатации средств СВН, а также текущий контроль знаний и навыков персонала, должен осуществляться Пользователем.

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

5.2.13 Требования к надежности

Коэффициент технической готовности для аппаратно-технических и про­граммных средств, установленных в ЦДС, должен быть не ниже 0,95 при среднем времени восстановления 60 минут.

Для периферийного оборудования среднее время восстановления опреде­ляется в процессе опытной эксплуатации, при этом выход из строя от­дельных узлов и модулей этого оборудования не должен приводить к од­новременной потере более чем 3% информационных возможностей СВН.

Время наработки на отказ подсистем СВН должно составлять не менее 9000 часов.

Плановый срок эксплуатации СВН должен составлять не менее 9 лет.

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

Состав ЗИП определяется Исполнителем в рабочем проекте системы.

5.2.14 Требования к эргономике и технической эстетике

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

Места размещения технических средств в ЦДС определяет Ис­полнитель на этапе проектирования и согласовывает с Пользователем и Заказчиком.

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

5.2.15 Требования безопасности

При проектировании и создании СВН должно быть обеспечено выполнение требований по безопасности при монтаже, наладке, эксплуатации, об­служивании и ремонте аппаратно-технических средств системы.

Требования к обеспечению безопасности при наладке, эксплуатации, об­служивании и ремонте аппаратно-технических средств системы должны быть изложены в соответствующей эксплуатационно-технической докумен­тации, разрабатываемой Исполнителем.

5.2.16 Требования к электропитанию и заземлению

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

Помещения для размещения ЦДС должны быть оборудованы защит­ным заземлением в соответствии с ГОСТ 464-79 «Заземления для ста­ционарных установок проводной связи, радиорелейных станций, радио­трансляционных узлов и антенн систем коллективного приема телеви­дения» М. 1987 год.

5.2.17 Требования к эксплуатации, техническому обслуживанию и ремон­ту

Оборудование СВН должно быть рассчитано на длительную непрерывную круглосуточную работу.

Технические средства СВН должны эксплуатироваться в соответствии с эксплуатационно-технической документацией, разрабатываемой Ис­полнителем.

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

Техническое обслуживание средств, входящих в состав СВН, и объектового оборудования осуществляет организация, аттестованная и Исполнителем системы.

Состав запасных частей, инструмента и принадлежностей (ЗИП), необходимых для обеспечения эксплуатации СВН, определяется Исполнителем и согласуется с Пользователем и Заказчиком на этапе рабочего проектирования.

5.3 Требования к видам обеспечения

5.3.1 Требования к техническому обеспечению.

Применяемые в СВН технические средства должны соответствовать требова­ниям к функциональным, конструктивным и эксплуатационным характеристикам технических средств, определяемым настоящим ТЗ.

5.3.2 Требования к лингвистическому обеспечению.

Пользовательский интерфейс программных средств ИСОБГ должен быть на русском языке.

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

5.3.3 Требования к организационному обеспечению.

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

При передаче информации СВН по каналам связи должна обеспечиваться защита информации.

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

Требования по обеспечению информационной безопасности СВН могут быть изменены или уточнены по согласованию Заказчика и Пользователя в процессе создания сис­темы

5.5 Требования к обеспечению патентной чистоты

При создании СВН должна быть обеспечена патентная чистота в в соответствии с действующим законодательством Российской Федерации.

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

5.6 Требования к стандартизации и унификации

При создании СВН должны приниматься к руководству действующие в Российской Федерации государственные и отраслевые стандарты.

Технические средства, используемые при создании СВН, подлежащие обязательной сертификации в соответствии с действующим законода­тельством Российской Федерации, должны иметь соответствующие сер­тификаты.

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

5.7 Требования к документальному оформлению работ

Документальное оформление работ по СВН должно соответствовать:

ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на АС. Виды, комплектность и обозначение документов при создании автоматизированных систем.

ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на АС. Техническое задание на создание автоматизированной системы.

ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на АС. Автоматизированные системы. Стадии создания.

ГОСТ 34.003-90. Информационная технология. Комплекс стандартов на АС. Термины и определения.

РД 50-34.698-90. Методические указания. Информационная техно­логия. Комплекс стандартов и руководящих документов на АС. Требования к содержанию документов.

ГОСТ 2.601-95. Единая система конструкторской документации. Эксплуатационные документы.

ГОСТ Р 51.. Системы охранные телевизионные. Техниче­ские требования и методы испытаний.

Источник