Проектування - основні технічні рішення, орбіта-союз

Проект на систему технічних засобів безпеки можна зробити в самому різному вигляді.

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

По-перше, оскільки система технічних засобів безпеки є частиною слабкострумових систем будівель і споруд, до неї застосовні ГОСТ серії 21 (система проектної документації в будівництві) і все СНиП (будівельні норми і правила), особливо що стосуються монтажу електрообладнання та систем автоматики.

По-друге, оскільки сучасні системи безпеки, як правило, є досить високоавтоматизованими, до них застосовні ГОСТ серії 24 ( «Автоматизовані системи управління») та більш пізня і більш загальна серія ГОСТ - 34 (просто «Автоматизовані системи»).

По-третє, якщо до складу системи входить програмне забезпечення (а як інакше, якщо кожне робоче місце оснащене двома-трьома комп'ютерами), то ваш проект в частині програмного забезпечення повинен задовольняти ще й ГОСТ серії 19 (єдина система програмної документації).

По-четверте, оскільки створювана вами система безпеки є виробом (нехай виконаним в єдиному екземплярі і зібраному безпосередньо на місці експлуатації), до неї в повній мірі відносяться і ГОСТ серій 2 (єдина система конструкторської документації) і 15 (система розробки і постановки продукції на виробництво).

Нарешті, побіжно питання проектування систем порушені і в спеціалізованих ГОСТах:

- ГОСТ Р 50776-95 (Системи тривожної сигналізації),

- ГОСТ Р 51241-98 (Засоби і системи контролю і управління доступом),

- ГОСТ Р 50571 (Електроустановки будівель).

Нарешті, у багатьох випадках вам доведеться мати на увазі і ряд РД, виданих Гостехкомиссией (нині реорганізованої у ФСТЕК) щодо захисту інформації.

А тепер головний міф. Думаєте, в процесі проектування приймаються принципові технічні рішення? Як би не так. Основні рішення були прийняті, коли укладався договір з обраним підрядником. Тепер в процесі проектування будуть лише уточнюватися деталі, і, ймовірно, будуть зекономлені чималі гроші (основна вартість системи лежить зовсім не в основному обладнанні, а в кабелях і інших допоміжних матеріалах), але основні рішення будуть ті ж самі, що і на попередньому проекті , виконаному тією ж фірмою. Саме за те, що підрядник зміг виконати схожий проект, його і вибрали. Що ж дивного, що він знову застосує ті ж основні рішення. Більш того, якщо замовник спробує наполягти на внесенні змін, вийде гірше, дорожче і довше, ніж, якби змін і не намагалися вносити. Справа ще й у тому, що прийняття принципових технічних рішень - дуже трудомістка справа. Одного разу отримані, перевірені рішення - вони і повинні копіюватися багаторазово. Істотні зміни в основних рішеннях, наприклад, зміна основного обладнання, призведе до суттєвих змін у всіх розділах проекту. А в результаті ймовірність припуститися помилки (або просто не оптимально розрахувати використання допоміжних матеріалів) зростає неймовірно.

Проте, деяка свобода вибору при проектуванні є.

Проектування, в ідеалі, складається з декількох етапів. Формально (по ГОСТу) більшість етапів необов'язкові, і якщо проект невеликий, вони, звичайно ж, не оформляються як окремі етапи робіт за договором, і не завершуються оформленням заключних красивих документів. Однак, подібно до того, як тендер на виконання робіт завжди є, навіть якщо не називається таким словом (і фактично виглядає як особисте відвідування замовником потенційних підрядників і переговори з кожним окремо), так подібно до цього і етапи проектування завжди присутні. Це корисно пам'ятати, навіть якщо етап «ескізний проект» полягає в 20-хвилинному малюванні схем олівцем на шматку пакувального паперу.

За ГОСТ 34.601 етапи проектування автоматизованої системи такі:

- формування вимог;

- розробка концепції;

- технічне завдання;

- ескізний проект;

- технічний проект;

- робоча документація.

Згідно зі СНиП 3.01.01 до складу робочої документації на етапі монтажу та пусконалагодження повинен увійти комплект виконавчої документації.

Згідно ГОСТ 24.209 до складу робочої документації на етапі «введення в експлуатацію» повинна увійти також експлуатаційна документація.

Розберемо все це по порядку.

Перші три етапи - включно із розробкою ТЗ на проектування - для невеликих завдань нерідко виконуються в рамках переговорів перед укладанням договору, причому безкоштовно. Результатом є ТЗ, яке відразу йде додатком до договору. Вони виконуються, як правило, спільно замовником і підрядником, бо лише замовник може сформулювати чого він хоче, і лише підрядник може допомогти перевести ці «хотілки» в чіткі формулювання технічних вимог. Уже на цьому етапі бажано, щоб в переговорах брали участь не тільки менеджери з продажу, а й інженери-проектувальники.

Другий етап (також зазвичай неявно виконується ще до укладення договору) - розробка концепції. Він теж обговорювалося вище, бо в 99% випадків зводиться до питання підходить чи типова концепція, що застосовується підрядником X для вирішення проблем замовника Y.

Третій етап - формування формального технічного завдання - іноді (на жаль дуже рідко, тільки для порівняно великих проектів) виконується в рамках першого етапу робіт вже за договором. Дуже рекомендую і замовникам і підрядникам (тобто якщо навіть замовник не бажає оплачувати написання ТЗ) - скласти і погодити (підписати у замовника) можливо більш детальне технічне завдання. Це технічне завдання в результаті повинно лягти в основу найважливішого документа, яким є Програма і Методика проведення приймально-здавальних випробувань. При відсутності такого документа в момент підписання заключного акту і замовник, і підрядчик будуть себе відчувати незадоволеними.

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

Наступні три етапи - ескізний, технічний проект і робоча документація. Ескізні проект виділяється окремим етапом договору тільки на великих об'єктах, а випадки поділу техноробочого проекту на окремо технічний і окремо робочу документацію мені поки що не зустрічалися. Ймовірно, це має сенс тільки в договорах ціною мільярд безумовних одиниць і вище.

Ескізний проект повинен містити перерахування всього основного і значної частини допоміжного обладнання, орієнтовна вказівку, де воно розташоване, а також загальні описи алгоритмів функціонування системи. У разі виконання робіт на підставі «акту обстеження», роль ескізного проекту виконує той самий «акт обстеження», в якому відразу, під час огляду об'єкту, замовник і підрядник спільно вказали «в яких кімнатах які датчики передбачається розмістити». А без робочої документації в такому випадку можна обійтися.

Технічний проект повинен в подробицях описувати структуру і алгоритми роботи системи, а робоча документація - всю інформацію, необхідну для поставки і монтажу системи. Зазвичай їх об'єднують в один техноробочий проект. Основні складові частини - специфікація обладнання, відомість матеріалів, креслення установки (розміщення) технічних засобів, план розташування проводок, таблиці з'єднань і підключень (кабельні журнали). В ідеалі, до складу РД повинні входити і план розгортання, план проведення робіт, графік поставки матеріалів і устаткування під монтаж.

Виконавча документація. Проект - добре. Хороший детальний проект - ще краще. Однак те, що вийде в результаті, напевно буде дещо відрізнятися від проекту. Хоча б тому, що в процесі монтажу з'ясується, що передбачувана гіпсокартонна перегородка виявилася несучої залізобетонною плитою, а розташування перегородок і дверей, ретельно виміряний проектувальниками перед початком роботи, чомусь за час проектування змінилося (граничний випадок, який зустрічався мені - коли, приїхавши на монтаж ми виявили, що 3-поверхова будівля, на яке намальований проект, знесено, а поруч з'явилося нове 6-поверхова, і господар, не бентежачись, пропонує нам «як-небудь розвісити все на перші 3 поверхи нового зд ня »). Так ось виконавча документація - це розумне назву для тих примірників проектної документації, на яких монтажники позначають зламаним фломастером «як вони зробили насправді». В пристойних випадках потім це переноситься в Автокад або на кульман. В непристойних - виконавча документація залишається в головах монтажників, і вивітрюється звідти через пару місяців, так що в разі ремонту всі кабелі доведеться видзвонювати заново.