Разделы ас в строительстве это

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

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

Работы по развитию АС осуществляют по стадиям и этапам, применяемым для создания АС.

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

Стадии и этапы создания АС

Стадии	Этапы работ
1. Формирование требований к АС	1.1. Обследование объекта и обоснование необходимости создания АС. 1.2. Формирование требований пользователя к АС. 1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС.	2.1. Изучение объекта. 2.2. Проведение необходимых научно-исследовательских работ. 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя. 2.4. Оформление отчёта о выполненной работе.
3. Техническое задание.	Разработка и утверждение технического задания на создание АС.
4. Эскизный проект.	4.1. Разработка предварительных проектных решений по системе и её частям. 4.2. Разработка документации на АС и её части.
5. Технический проект.	5.1. Разработка проектных решений по системе и её частям. 5.2. Разработка документации на АС и её части. 5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку. 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.
6. Рабочая документация.	6.1. Разработка рабочей документации на систему и её части. 6.2. Разработка или адаптация программ.
7. Ввод в действие.	7.1. Подготовка объекта автоматизации к вводу АС в действие. 7.2. Подготовка персонала. 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями). 7.4. Строительно-монтажные работы. 7.5. Пусконаладочные работы. 7.6. Проведение предварительных испытаний. 7.7. Проведение опытной эксплуатации. 7.8. Проведение приёмочных испытаний.
8. Сопровождение АС	8.1. Выполнение работ в соответствии с гарантийными обязательствами. 8.2. Послегарантийное обслуживание.

Проектирование ИЖС. Состав проекта АС.

Основные нормативные документы, регламентирующие порядок создания АСУ ТП.

1.1. Разработка АСУ ТП в целом, в том числе технического проекта, должна соответствовать общим требованиям, установленным ГОСТ 24.104, а также требованиям, содержащимся в техническом задании на ее создание (ГОСТ 34.602).

Обзор раздел АС проектной документации

1.2. Последовательность стадий и этапов работ, связанных с определением целесообразности создания и собственно созданием АСУ ТП, определена в ГОСТ 34.601.

1.4 Виды, комплектность и обозначение документов при создании автоматизированных систем — ГОСТ 34.201.

2.6. Требования к содержанию отдельных документов технического проекта АСУ ТП.

2.6.1. Схема организационной структуры и «Описание организационной структуры» — требования к содержанию по РД 50-34.698-90.

2.6.2. Документы: «Схема структурная КТС», «Описание комплекса технических средств» — оформляются в соответствии с РД 50-34.698-90.

2.6.3. Схема функциональной структуры по РД 50-34.698-90.

2.6.4. Перечень заданий на разработку специализированных (новых) технических средств.

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

2.6.5. Схема автоматизации — в соответствии с РД 50-34.698-90, ГОСТ 21404.

2.6.6. Технические задания на разработку специализированных (новых) технических средств — по ГОСТ 15.001.

2.6.7. Задания на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, связанных с созданием системы — оформляются РД 50-34.698-90.

В ведомость технического проекта «Задания. » не включаются, контрольный экземпляр документа хранится в деле технического проекта.

2.6.8. Ведомость технического проекта.

Требования к содержанию по РД 50-34.698-90.

Ведомости составляют по формам 4 и 4а ГОСТ 2.106.

2.6.9. Ведомость покупных изделий — в соответствии с ГОСТ 2.106.

2.6.10. Перечень входных (выходных) сигналов (документов) и данных по РД 50-34.698-90.

2.6.11. Перечень заданий на разработку строительных, электротехнических, санитарно-технических и других разделов проекта, связанных с созданием системы — составляют в соответствии с требованиями РД 50-34.698-90.

2.6.12. Пояснительная записка к техническому проекту — по РД 50-34.698-90.

2.6.14. Описание информационного обеспечения системы — в соответствии с требованиями РД 50-34.698-90.

2.6.15. Описание организации информационной базы по РД 50-34.698-90.

2.6.16. Описание системы классификации и кодирования — документ должен содержать по каждому классификационному объекту описание метода кодирования, структуру и длину кода, указания о системе классификации и другие сведения по усмотрению разработчика РД 50-34.698-90.

2.6.17. Описание массива информации — по РД 50-34.698-90.

2.6.18. Описание программного обеспечения

2.6.19. Описание алгоритма (проектной процедуры) — в соответствии с РД 50-34.698-90.

2.6.20. План расположения

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

2.6.21. Ведомость оборудования и материалов по РД 50-34.698-90, ГОСТ 21.109.

2.6.22. Локальный сметный расчет по РД 50-34.698-90.

На стадии «Технический проект» основной исполнитель (организация — проектировщик АСУ ТП) разрабатывает локальный сметный расчет затрат с выделением затрат на разработку проектной (рабочей) документации, монтаж и наладку системы.

Требования к содержанию документа по СНиП 1.02.01.

2.6.23. Проектная оценка надежности системы — в соответствии с РД 50-34.698-90.

2.6.24. Чертеж формы документа (видеокадра).

Порядок испытаний и ввод в эксплуатацию АСУ ТП. Перечень документов, необходимых при сдаче системы автоматизации в эксплуатацию.

Виды и порядок проведение испытаний при вводе асу в действие

Настоящий раздел распространяется на все АСУ, кроме создаваемых по заказам Министерства обороны.

3.1. АСУ или отдельно сдаваемая функция АСУ (далее — АСУ) при вводе ее в действие должна пройти предварительные и приемочные испытания, а также испытания, предусмотренные нормативно-техническими документами, действующими в ведомстве заказчика АСУ.

3.2. Приемочным испытаниям АСУ должна предшествовать ее опытная эксплуатация на объекте управления.

3.3. Испытания АСУ проводят в соответствии с документом «Программа испытаний», который готовит разработчик АСУ. Требования к содержанию программы испытаний — по ГОСТ 24.208-80 .

3.4. Испытания АСУ допускается проводить в один или несколько этапов.

По результатам испытаний АСУ составляют «Протокол испытаний». Требования к содержанию протокола испытаний — по ГОСТ 24.208-80 .

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

Предварительные испытания АСУ

3.5.1. Предварительные испытания АСУ проводят для определения ее работоспособности и решения вопроса о возможности приемки АСУ в опытную эксплуатацию.

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

3.5.3. Предварительные испытания АСУ организует заказчик и проводят разработчик АСУ и заказчик совместно.

3.5.4. Комиссию для проведения предварительных испытаний АСУ образуют приказом заказчика. Председателем комиссии назначают представителя заказчика АСУ.

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

Опытная эксплуатация АСУ

3.6.1. Результаты приемки АСУ в опытную эксплуатацию оформляют «Актом приемки в опытную эксплуатацию», составленным на основании «Протокола испытаний» комиссией, проводившей предварительные испытания АСУ. Требования к содержанию акта — по ГОСТ 24.208-80 .

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

3.6.3. Минимальную длительность опытной эксплуатации АСУ (кроме ОАСУ) перед приемочными испытаниями определяют для каждой сдаваемой автоматизированной функции АСУ, она должна соответствовать значениям, указанным в таблице. Если общая продолжительность нарушений непрерывности выполнения автоматизированной функции превышает значение, указанное в таблице, опытная эксплуатация должна быть продолжена до получения результатов, соответствующих таблице, или до принятия решения о ее прекращении.

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

Частота выполнения автоматизированной функции	Минимальная длительность опытной эксплуатации АСУ перед приемочными испытаниями	Допускаемая общая продолжительность нарушений непрерывности выполнения автоматизированной функции АСУ
Непрерывно	1 мес	Не более 3 сут
Один раз в сутки и чаще	То же	Не более 10% планового числа решений
Реже одного раза в сутки до одного раза в месяц	3 мес	То же
Реже одного раза в месяц до одного раза в полгода	Период между двумя последовательными решениями	Нарушения непрерывности выполнения функции не допускаются
Раз в год и реже	Период времени, необходимый для проверки принятой технологии сбора и переработки информации в процессе однократного выполнения функции АСУ	То же

Примечания:

1. Нарушением непрерывности выполнения автоматизированной функции АСУ считают ее невыполнение в предусмотренный технической документацией на АСУ момент времени, если это не вызвано нарушением условий функционирования АСУ или объекта управления.

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

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

3.6.5. По результатам опытной эксплуатации составляют акт о завершении работ по проверке АСУ в режиме опытной эксплуатации. Требования к содержанию акта — по ГОСТ 24.208-80.

Приемочные испытания АСУ

3.7.1. Приемочные испытания АСУ проводят для определения ее соответствия ТЗ на АСУ, требованиям настоящего стандарта и определения возможности ввода АСУ в действие.

3.7.2. В зависимости от важности объекта управления и АСУ приемочные испытания могут быть:

и должны быть проведены соответствующими приемочными комиссиями. Приемочную комиссию образуют приказом министерства (ведомства) заказчика АСУ. Уровень приемочной комиссии должен быть установлен в ТЗ на АСУ.

3.7.3. Председателем приемочной комиссии назначают представителя заказчика АСУ. В состав приемочной комиссии обязательно включают представителей разработчика АСУ.

3.7.4. Работа приемочной комиссии не включает приемку зданий, сооружений и вспомогательного оборудования, создание которых осуществлено в связи с созданием АСУ. Комиссия проверяет только наличие актов о приемке их в эксплуатацию и выполнение требований, содержащихся в заданиях на проектирование в смежных частях проекта объекта, выданных в ходе проектирования АСУ.

3.7.5. Приемочной комиссии заказчик и разработчик предъявляют следующую документацию:

· техническое задание на создание АСУ;

· проект программы приемочных испытаний;

· протокол предварительных испытаний АСУ;

· акт приемки АСУ в опытную эксплуатацию;

· акт (акты) о завершении работ по проверке АСУ в режиме опытной эксплуатации;

· техническую документацию на АСУ (по решению приемочной комиссии).

3.7.6. Перед предъявлением на приемочные испытания АСУ, имеющей измерительные каналы, проводят их метрологическую аттестацию в соответствии с действующими стандартами.

3.7.7. Перед предъявлением АСУ на приемочные испытания система и ее техническая документация должны быть доработаны по замечаниям протокола предварительных испытаний и акта о завершении работ по проверке АСУ в режиме опытной эксплуатации.

Допускается по решению приемочной комиссии доработка технической документации АСУ после ввода ее в действие. Сроки доработки технической документации АСУ указывают в протоколе приемочных испытаний системы.

3.7.8. Приемочные испытания АСУ должны быть проведены на функционирующем объекте управления.

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

3.7.10. По результатам приемочных испытаний комиссия составляет протокол испытаний и акт о вводе АСУ в действие (или заключение о неприемке АСУ с перечнем необходимых доработок и рекомендуемыми сроками их выполнения). Требования к содержанию протокола и акта по ГОСТ 24.208-80 . Требования к содержанию заключения о неприемке АСУ аналогичны требованиям к содержанию акта о вводе АСУ в действие.

3.7.11. В случае поэтапного проведения приемочных испытаний акт о вводе АСУ в действие оформляют на основании актов о вводе в действие отдельных частей системы и (или) «Протоколов испытаний» всех этапов приемочных испытаний АСУ.

3.7.12. Датой ввода АСУ в действие считают дату подписания акта о вводе в действие приемочной комиссией.

3.7.13. Акт о вводе АСУ в действие утверждает министерство (ведомство) заказчика.

Гарантии

5.1. Разработчик АСУ гарантирует соответствие АСУ требованиям настоящего стандарта и ТЗ на АСУ при соблюдении пользователем условий и правил эксплуатации.

5.2. соответствие применяемых в АСУ и поставляемых как продукция производственно-технического назначения технических, программных средств и комплексов средств автоматизации требованиям стандартов и ТУ на них гарантируют изготовители этих видов продукции при соблюдении пользователем условий и правил эксплуатации.

5.3. Гарантийный срок эксплуатации на АСУ исчисляют со дня ввода АСУ в действие.

5.4. Гарантийный срок эксплуатации на АСУ должен быть установлен в ТЗ на АСУ и не может быть менее 18 мес.

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

1. АСУ ТП в промышленности и в непромышленной сфере должна управлять технологическим объектом в целом и снабжать взаимосвязанные с ней системы достоверной технологической и технико-экономической информацией о работе технологического объекта управления (ТОУ).

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

3. АСУ ТП должна выполнять управляющие, информационные и вспомогательные функции.

4. АСУ ТП должна быть совместима со всеми взаимосвязанными с ней автоматизированными системами (АС), указанными в ТЗ на АСУ ТП, в том числе с системами, входящими вместе с данной АСУ ТП в состав гибкого автоматизированного производства, например, САПР технологии, автоматизированными складскими и транспортными системами, АС технологической подготовки производства.

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

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

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

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

9. В качестве основных технических средств АСУ ТП должны быть использованы изделия Государственной системы промышленных приборов и средств автоматизации (ГСП), другие изделия, удовлетворяющие требованиям стандартов ЕССП, и средства вычислительной техники, соответствующие ГОСТ 21552-84.

10. Технические средства АСУ ТП, размещаемые на технологическом оборудовании, должны соответствовать требованиям, предъявляемым к ним условиям эксплуатации.

11. Обязанности между операторами должны быть распределены с учетом:

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

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

12. Каждое лицо, входящее в состав персонала, должен обладать:

· знаниями, объем и глубина которых позволяет ему выполнять действия (взаимодействия), входящее в соответствующие автоматизированные и взаимосвязанные с ними неавтоматизированные функции АСУ ТП, а также принимать правильные решения в аварийных ситуациях или при других нарушениях нормальной эксплуатации;

· отработанными навыками, позволяющими с заданными безошибочностью и быстродействием выполнять все действия и взаимодействия.

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

14. Коды и условные обозначения, используемые в АСУ ТП, должны быть приближены к терминам и понятиям, применяемым технологическим персоналом объекта управления, и не должны вызывать трудностей при их восприятии.

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

Требования к испытаниям АСУ ТП

16.1. Предварительные испытания АСУ ТП проводят на действующем ТОУ.

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

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

Состав проекта АСУ ТП.

Состав рабочей документации на создание АС ТП регламентируется также ГОСТ 21.408-93 СПДС «Правила выполнения рабочей документации автоматизации технологических процессов» и ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем».

общесистемные решения (ОР): концепция автоматизации, задачи АСУ ТП, автоматизируемые функции, функциональная структура АСУ ТП, проектная оценка надежности АСУ ТП, локальный сметный расчет, программа и методика испытаний АСУ ТП;

организационное обеспечение (ОО): организационная структура, права и обязанности пользователей и эксплуатационного персонала АС в условиях функционирования, проверка и обеспечение работоспособности АС;

информационное обеспечение (ИО): формы документов, классификаторов, нормативной базы и реализованных решений по объемам, размещению и формам существования информации, применяемой в АС при ее функционировании;

техническое обеспечение (ТО): структура комплекса технических средств (КТС), общие виды, схемы принципиальные, расположения, соединений и подключений, спецификации материалов и оборудования, инструкции по эксплуатации КТС;

математическое обеспечение (МО): математические методы, модели и алгоритмы, примененяемые в АС;

программное обеспечение (ПО): программы на носителях данных и программные документы, предназначенные для отладки, функционирования и проверки работоспособности АС.

На стадии создания рабочей документации (РД) разрабатываются следующие документы:

1. проектная оценка надежности системы;

2. чертеж формы документа (видеокадра);

3. ведомость держателей подлинников;

4. ведомость эксплуатационных документов;

5. спецификация оборудования;

6. ведомость потребности в материалах;

7. ведомость машинных носителей информации;

8. массив входных данных;

9. каталог базы данных;

10. состав выходных данных (сообщений);

11. локальная смета;

12. методика (технология) автоматизированного проектирования;

13. технологическая инструкция;

14. руководство пользователя;

15. инструкция по формированию и ведению базы данных (набора данных);

16. инструкция по эксплуатации КТС;

17. схема соединений внешних проводок;

18. схема подключения внешних проводок;

19. таблица соединений и подключений;

20. схема деления системы (структурная);

21. чертеж общего вида;

22. чертеж установки технических средств;

23. схема принципиальная;

24. схема структурная комплекса технических средств;

25. план расположения оборудования и проводок;

26. описание технологического процесса обработки данных (включая телеобработку);

27. общее описание системы;

28. программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистемы, систем);

5. Система автоматизированного проектирования (САПР) — это организационно-техническая система, состоящая из совокупности комплекса средств автоматизации проектирования и коллектива специалистов подразделений проектной организации, выполняющая автоматизированное проектирование объекта, которое является результатом деятельности проектной организации.

основные принципы построения САПР.

1. САПР — человеко-машинная система. Все созданные и создаваемые системы проектирования с помощью ЭВМ являются автоматизированными, важную роль в них играет человек — инженер, разрабатывающий проект технического средства.

В настоящее время и по крайней мере в ближайшие годы создание систем автоматического проектирования не предвидится, и ничто не угрожает монополии человека при принятии узловых решении в процессе проектирования. Человек в САПР должен решать, во-первых, все задачи, которые не формализованы, во-вторых, задачи, решение которых человек осуществляет на основе своих эвристических способностей более эффективно, чем современная ЭВМ на основе своих вычислительных возможностей. Тесное взаимодействие человека и ЭВМ в процессе проектирования — один из принципов построения и эксплуатации САПР.

2. САПР — иерархическая система, реализующая комплексный подход к автоматизации всех уровней проектирования. Иерархия уровней проектирования отражается в структуре специального программного обеспечения САПР в виде иерархии подсистем.

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

3. САПР — совокупность информационно-согласованных подсистем. Этот очень важный принцип должен относиться не только к связям между крупными подсистемами, но и к связям между более мелкими частями подсистем.

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

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

4. САПР — открытая и развивающаяся система. Существует, по крайней мере, две веские причины, по которым САПР должна быть изменяющейся во времени системой. Во-первых, разработка столь сложного объекта, как САПР, занимает продолжительное время, и экономи­чески выгодно вводить в эксплуатацию части системы по мере их готовности.

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

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

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

Системный подход к проектированию.

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

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

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

Как и любая сложная система, САПР состоит из подсистем. Различают подсистемы проектирующие и обслуживающие.

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

Обслуживающие подсистемы обеспечивают функционирование проектирующих подсистем, их совокупность часто называют системной средой (или оболочкой) САПР. Типичными обслуживающими подсистемами являются подсистемы управления проектными данными, подсистемы разработки и сопровождения программного обеспечения CASE (Computer Aided Software Engineering), обучающие подсистемы для освоения пользователями технологий, реализованных в САПР.

Виды обеспечения САПР

Структурирование САПР по различным аспектам обусловливает появление видов обеспечения САПР. Принято выделять семь видов обеспечения САПР:

§ техническое (ТО), включающее различные аппаратные средства (ЭВМ, периферийные устройства, сетевое коммутационное оборудование, линии связи, измерительные средства);

§ математическое (МО), объединяющее математические методы, модели и алгоритмы для выполнения проектирования;

§ программное (ПО), представляемое компьютерными программами САПР;

§ информационное (ИО), состоящее из базы данных, СУБД, а также включающее другие данные, которые используются при проектировании; отметим, что вся совокупность используемых при проектировании данных называется информационным фондом САПР, база данных вместе с СУБД носит название банка данных;

§ лингвистическое (ЛО), выражаемое языками общения между проектировщиками и ЭВМ, языками программирования и языками обмена данными между техническими средствами САПР;

§ методическое (МетО), включающее различные методики проектирования; иногда к нему относят также математическое обеспечение;

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

Классификацию САПР осуществляют по ряду признаков, например по приложению, целевому назначению, масштабам (комплексности решаемых задач), характеру базовой подсистемы — ядра САПР.

По приложениям наиболее представительными и широко используемыми являются следующие группы САПР:

§ САПР для применения в отраслях общего машиностроения. Их часто называют машиностроительными САПР или системами MCAD (Mechanical CAD);

§ САПР для радиоэлектроники: системы ECAD (Electronic CAD) или EDA (Electronic Design Automation);

§ САПР в области архитектуры и строительства.

Кроме того, известно большое число специализированных САПР, или выделяемых в указанных группах, или представляющих самостоятельную ветвь классификации. Примерами таких систем являются САПР больших интегральных схем (БИС); САПР летательных аппаратов; САПР электрических машин и т. п.

По целевому назначению различают САПР или подсистемы САПР, обеспечивающие разные аспекты (страты) проектирования. Так, в составе MCAD появляются рассмотренные выше CAE/CAD/CAM-системы.

По масштабам различают отдельные программно-методические комплексы (ПМК) САПР, например: комплекс анализа прочности механических изделий в соответствии с методом конечных элементов (МКЭ) или комплекс анализа электронных схем; системы ПМК; системы с уникальными архитектурами не только программного (software), но и технического (hardware) обеспечений.

По характеру базовой подсистемы различают следующие разновидности САПР:

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

В настоящее время широко используют унифицированные графические ядра, применяемые более чем в одной САПР (ядра Parasolid фирмы EDS Urographies и ACIS фирмы Intergraph).

2. САПР на базе СУБД. Они ориентированы на приложения, в которых при сравнительно несложных математических расчетах перерабатывается большой объем данных. Такие САПР преимущественно встречаются в технико-экономических приложениях, например при проектировании бизнес-планов, но они имеются также при проектировании объектов, подобных щитам управления в системах автоматики.

3. САПР на базе конкретного прикладного пакета. Фактически это автономно используемые ПМК, например имитационного моделирования производственных процессов, расчета прочности по МКЭ, синтеза и анализа систем автоматического управления и т. п. Часто такие САПР относятся к системам САЕ. Примерами могут служить программы логического проектирования на базе языка VHDL, математические пакеты типа MathCAD.

Источник: infopedia.su

Нормативные требования СТР-К к аттестации АС/ИС

В статье приведены основные положения документа «Специальные требования и рекомендации по технической защите конфиденциальной информации» (СТР-К), утвержденного Приказом Председателя Гостехкомиссии России от 30.08.2002 № 282. Рассмотрены требования к аттестации, порядок ввода в действие и эксплуатации объектов информатизации, а также порядок контроля за их использованием. Также представлен полный цикл работ по аттестации АС/ИС – от проектирования до ввода в эксплуатацию.

Используемые сокращения

АС — автоматизированная система ВТСС — вспомогательные технические средства и системы
ДСП — для служебного пользования
ИС — информационная система
КЗ — контролируемая зона
ОТСС — основные технические средства и системы
ПО — программное обеспечение
РД АС — Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. (Утверждено решением председателя Государственной технической комиссии при Президенте Российской Федерации от 30 марта 1992 г.)
СВТ — средства вычислительной техники
СЗИ – система защиты информации
СКЗИ – средство криптографической защиты информации
ТЗ — техническое задание

Введение

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

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

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

Объектами защиты при этом являются:

• средства и системы информатизации (СВТ, различного уровня и назначения на базе СВТ, в том числе информационно-вычислительные комплексы, сети и системы, средства и системы связи и передачи данных, технические средства приема, передачи и обработки информации (телефонии, звукозаписи, звукоусиления, звуковоспроизведения, переговорные и телевизионные устройства, средства изготовления, тиражирования документов и другие технические средства обработки речевой, графической, видео и буквенно-цифровой информации), программные средства (операционные системы, системы управления базами данных, другое общесистемное и прикладное программное обеспечение), средства защиты информации, используемые для обработки конфиденциальной информации;
• технические средства и системы, не обрабатывающие непосредственно конфиденциальную информацию, но размещенные в помещениях, где она обрабатывается (циркулирует).

Аттестация АС/ИС по требованиям СТР-К – это комплексная задача, которая включает организационно-технические мероприятия. Весь процесс аттестации АС/ИС по требованиям безопасности представлен на Рисунке 1.

Рисунок 1. Блок-схема аттестации АС/ИС

Процесс от разработки до аттестации АС/ИС по требованиям безопасности с дальнейшей эксплуатацией делится на четыре этапа:

1. Подготовительный.
2. Проектирование и ввод в действие АС/ИС и системы защиты информации, обрабатываемой в АС/ИС.
3. Аттестация по требованиям безопасности АС/ИС.
4. Контроль состояния защиты информации.

Рассмотрим каждый этап.

Этапы аттестации АС/ИС

Подготовительный этап

Организация работ по созданию и эксплуатации АС/ИС проводится в соответствии с локальными нормативными документами организации, в которых должно быть определено следующее:

• Перечень защищаемой информации и разрешительная система на доступ к защищаемой информации.
• Ответственные за организацию и проведение работ по созданию системы защиты информации в АС/ИС.
• Категория АС/ИС (в соответствии с Руководящим документом «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации»). Пересмотр класса защищенности АС/ИС проводится в обязательном порядке, если произошло изменение хотя бы одного из критериев, на основании которого он был установлен.
• Границы контролируемой зоны, где будет размещен аттестуемый объект.
• Оценка ущерба от нарушения свойств безопасности информации.

Рассмотрим аттестацию АС/ИС по требованиям безопасности информации на примере аттестации АС/ИС режимного предприятия. Перечень защищаемой информации формировался задолго до принятия решения об аттестации АС/ИС в организации, потому что работа строилась в тесном взаимодействии с регуляторами (ФСТЭК России и ФСБ России), вся переписка велась с пометками «ДСП» и «Конфиденциально».

Организаторы и ответственные (впоследствии) за проведение работ по созданию АС/ИС в защищенном исполнении были назначены из отдела по защите информации. Поскольку с регуляторами по служебным обязанностям взаимодействовали несколько отделов организации по разным вопросам, категория АС/ИС определялась как многопользовательская и с разными правами доступа, при этом ей была присвоена пометка «Конфиденциально»/«ДСП». Под такие критерии подходит класс защиты в соответствии с РД АС – 1Г. Границы контролируемой зоны очерчивались по периметру здания, в котором размещалась организация. Оценку ущерба в этом случае проводить не обязательно, но для аналитического обоснования и принятия решения руководителя организации необходимо привести доводы в пользу экономической выгоды создания системы защиты информации в АС/ИС.

Проектирование и ввод в действие АС/ИС и системы защиты информации, обрабатываемой в АС/ИС

Этот этап делится на три подэтапа согласно блок-схеме на Рисунке 2.

Рисунок 2. Блок-схема проектирования и ввода в действие АС/ИС и системы защиты информации, обрабатываемой в АС/ИС

На предпроектном подэтапе предусмотрены: сбор информации об объекте защиты и месте размещения ОТСС и ВТСС АС/ИС относительно границ КЗ; моделирование угроз безопасности информации, обрабатываемой в АС/ИС; предъявление требований к СЗИ АС/ИС, направленных на противодействие актуальным угрозам, в соответствии с положениями Руководящего документа «Автоматизированные системы. Защита от несанкционированного доступа к информации.

Классификация автоматизированных систем и требования по защите информации» и СТР-К. Также осуществляется разработка организационно-распорядительной документации, в которой устанавливаются требования к защищаемой информации при ее автоматизированной обработке. По итогам предпроектного подэтапа формируется ТЗ на создание СЗИ АС/ИС.

В ходе следующего подэтапа проектирования на основании ТЗ разрабатывается технический проект, в котором определяется перечень СрЗИ, сертифицированных по требованиям безопасности информации. Проектирование осуществляется в соответствии с ГОСТ Р 51583-2014 «Защита информации. Порядок создания автоматизированной системы в защищенном исполнении.

Общие положения», ГОСТ Р 51624-2000 «Защита информации. Автоматизированные системы в защищенном исполнении. Общие требования». По итогам подэтапа проектирования разрабатывается эксплуатационная документация, в которой описывается архитектура СЗИ АС/ИС с указанием необходимых настроек.

На основании разработанной эксплуатационной документации в подэтапе ввода в действие СЗИ АС/ИС осуществляется:

• опытная эксплуатация средств защиты информации в комплексе с другими техническими и программными средствами в целях проверки их работоспособности в составе АС/ИС и отработки технологического процесса обработки (передачи) информации;
• приемо-сдаточные испытания средств защиты информации по результатам опытной эксплуатации с оформлением приемо-сдаточного акта, подписываемого разработчиком (поставщиком) и заказчиком;
• подготовка АС/ИС к аттестации по требованиям безопасности информации (разрабатывается техническая документация: технический паспорт, описание технического процесса и др.).

Рассмотрим пример. Организация решила создать АС/ИС в защищенном исполнении для дальнейшей аттестации по требованиям СТР-К. Для размещения системы было выбрано режимное помещение, где уже находились АС, обрабатывающие государственную тайну. Наличие таких систем накладывало ряд ограничений: к ним предъявляются требования по противодействию техническим разведкам, направленным на реализацию утечки информации через различные демаскирующие признаки, побочные электромагнитные излучения и наводки (ПЭМИН) электронного оборудования, требования по высокочастотному навязыванию и облучению, а также по электромагнитному и радиационному воздействию. Это значит, что в радиусе оборудования, определенном в заключении специальной проверки и исследования, не должна находиться сторонняя аппаратура, либо должны применяться средства активной защиты информации от утечки по техническим каналам.

После моделирования угроз безопасности было разработано ТЗ с учетом требований к размещению ВТСС АС, обрабатывающих государственную тайну (далее – АС ГТ). Для удовлетворения требований СТР-К и нормативно-методической документации по защите информации, составляющей государственную тайну, было принято решение описать требования по защите информации от ее утечки по техническим каналам.

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

Архитектурное решение выглядело следующим образом (Рисунок 3).

Рисунок 3. Архитектурное решение по созданию СЗИ АС/ИС

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

Благодаря принятым архитектурным решениям, были соблюдены не только все требования СТР-К, но и требования нормативно-распорядительной документации по защите государственной тайны. Произведены соответствующие дополнения в технические паспорта АС ГТ и осуществлен перевод АС/ИС в опытную эксплуатацию.

Аттестация по требованиям безопасности АС/ИС

Этап аттестации проводится в соответствии со стандартами по аттестации ГОСТ РО 0043-003-2012 «Аттестация объектов информатизации. Общие положения» и 0043-004-2013 «Защита информации. Аттестация объектов информатизации. Программа и методики аттестационных испытаний».

При аттестации АС/ИС подтверждается ее соответствие требованиям по защите информации:

• от несанкционированного доступа;
• от компьютерных вирусов;
• от утечки информации по техническим каналам (за счет ПЭМИН, высокочастотного навязывания и облучения, электромагнитного и радиационного воздействия).

Процесс аттестации АС/ИС показан на Рисунке 4.

Рисунок 4. Схема проведения аттестации АС/ИС

Контроль состояния защиты информации

Для поддержания режима обработки защищаемой информации и предотвращения возникновения угроз нарушения ее конфиденциальности, целостности и доступности силами владельца аттестованной АС/ИС или силами организации, имеющей лицензии ФСТЭК России на проведение работ по ТЗКИ, организуется периодический контроль состояния защиты информации (не реже одного раза в год). На периодическом контроле проводится:

• анализ актуальности организационно-распорядительной и эксплуатационной документации, а также состав ОТСС, ВТСС и ПО;
• проверка актуальности категорирования АС/ИС и настроек средств защиты информации в соответствии с эксплуатационной документацией, а также уровень подготовки кадрового состава, обслуживающего СЗИ АС/ИС (администраторы ИБ).

При обнаружении несоответствия комиссия может отозвать действие аттестата соответствия и после устранения замечаний назначить повторные аттестационные испытания АС/ИС.

Выводы

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

Авторы:
Егор Ляпустин, инженер-проектировщик Центра информационной безопасности компании «Инфосистемы Джет»,
Дмитрий Шлей, эксперт группы системной архитектуры Центра информационной безопасности компании «Инфосистемы Джет».

Источник: safe-surf.ru

Методика организации «сквозного проектирования» в Autodesk AutoCAD с использованием ЛОЦМАН:ПГС

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

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

При работе традиционным методом инженеры­сетевики (пять­семь человек) вынуждены ждать генпланиста, пока тот закончит чертеж генплана. На некоторых этапах сетевики могут брать у него промежуточные варианты генплана, копировать их к себе в чертеж и начинать работу (при этом копии совершенно не зависят от источника). При каком­либо изменении в генплане они вынуждены постоянно обновлять данные от генпланиста и заменять их в своих чертежах на новые, регулярно тратя время на то, чтобы отделить «зерна от плевел», испытывая мучения из­за перевода из одного масштаба в другой и т.д. Однако исход при такой методике часто бывает малоэффективным: данные берутся однократно и больше не обновляются, и на определенном этапе у ряда проектировщиков скапливается несколько версий одних и тех же данных, которые начинают развиваться параллельно; в итоге возникает нестыковка частей проекта, следствием чего бывает потеря времени и исправление чертежей в последний момент.

Методика сквозного проектирования позволяет организовать связь между всеми участниками проектирования на уровне графической среды через инструмент AutoCAD Внешние ссылки.

Инструмент AutoCAD Внешние ссылки дает возможность организовать связь между двумя и более чертежами. Таким образом мы можем импортировать (под этим понятием здесь и далее будет подразумеваться команда _attach, она же вставка Внешней ссылки) в свой чертеж фрагмент (после вставки мы можем подрезать внешнюю ссылку — назначать границу отображения) из любого чертежа, который создал другой инженер, даже если он редактирует его в данный момент. При этом фрагмент, вставленный в мой чертеж, будет самостоятельно обновляться при изменении источника данных. Более того, если на данном фрагменте появятся новые слои, которые могут не понадобиться, система проинформирует об этом и мы своевременно сможем отключить их отображение или переопределить их свойства (фильтр согласования новых слоев в диспетчере слоев). Это значит, что мы постоянно будем иметь актуальную информацию, получаемую от других участников проектирования, и сможем приступить к работе раньше — до того, как они закончат свой чертеж полностью, как только увидим, что данных для начала проектирования достаточно.

Основная задача методики «сквозного проектирования» — снижение времени ожидания, повышение оперативности взаимодействия специалистов. Применение этой методики позволяет:

• исключить появление нестыковок между отдельными разделами проекта и в реальном времени отслеживать обновление исходных данных (исключая работу в ненужном направлении);
• исключить ручное обновление исходных данных (данные импортируются однократно и обновляются автоматически, при изменении источника); при данной схеме можно минимизировать совершение ошибок (человеческий фактор), возникающих из­за недостаточной информированности участников проекта о ходе процесса.

Процесс «сквозного проектирования» предъявляет определенные требования к навыкам и стилю работы в AutoCAD, а также к версии самого программного продукта. Проектировщики должны уметь работать с диспетчером свойств и конфигураций слоев, пользоваться набором команд для объектов Внешние ссылки. Что касается стиля работы, проектировщики должны группировать все объекты по слоям, создавая «логистику», удовлетворяющую потребностям специалистов­смежников, обеспечивая возможность переопределения свойств слоев. Кроме того, группа проектировщиков должна иметь единый синтаксис именования слоев (то есть логичнее именовать главные оси здания как «Оси главные», а не «Главные оси», потому как в перечне слоев, отсортированном по алфавиту, «Главные оси» окажутся рядом с любым слоем, начинающимся на букву «Г*», но не рядом со слоем «Оси промежуточные» и «Оси дополнительные»). Версия формата чертежа­источника не может быть более поздней, чем версия чертежа, в который импортируют данные.

Организация «сквозного проектирования»

На условном практическом примере рассмотрим, как организуется описанная выше концепция. Подразумевается, что над каждым чертежом (комплектом) работает отдельный специалист. То есть при правильном подходе весь процесс смело можно назвать автоматизированным групповым проектированием. В качестве среды хранения проектных данных для удобства будет выступать ЛОЦМАН:ПГС, но это может быть и обычная папка на сетевом диске.

Участники проектирования: ГИП, архитектор­строитель, генпланист, инженер ОВИК, инженер ТГВ, инженер­электрик.

Исходные данные

ГИП публикует исходные данные в одноименной папке. В качестве исходных данных в примере будет выступать топографическая съемка (рис. 1).

Рис. 1. Дерево проекта в ЛОЦМАН:ПГС

Раздел АС

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

Он работает в папке «1 АС», расположенной в корневой директории проекта. Остальным участникам проектирования, развивающимся в направлении генерального плана и наружных сетей, из всего комплекта АС нужен только план первого этажа и план подземной части (если в их конфигурации есть различия, которых в нашем примере нет). Чертеж выступит источником данных для ряда дочерних чертежей. В настройках чертежа важно выставить правильный параметр единицы чертежа, на строительных чертежах данного комплекта это, как правило, миллиметры (Меню: Формат —> единицы или команда _UNITS) (рис. 2).

Рис 3. Пространство AutoCAD: а — слои, используемые в чертеже; б — пример плана первого этажа комплекта АС

Раздел ГП

В процесс проектирования параллельно может включаться генпланист. Он работает в папке «2 ГП», расположенной в корневой директории проекта. Его чертеж будет импортером данных: топографии (исходные данные) и плана первого этажа (комплект АС). В настройках чертежа важно выставить правильный параметр единицы чертежа, на чертежах генеральных планов это, как правило, метры (Меню: Формат —> единицы или команда _UNITS) — рис. 4.

Рис. 5. Окно панели файлов проекта ЛОЦМАН ПГС — аналог проводника Windows

Оба чертежа (топография и план первого этажа) подключаются через инструмент вставки внешних ссылок (Меню: Вставка —> Ссылка на DWG или команда _attach), но прежде мы должны узнать пути к файлам. В программе ЛОЦМАН:ПГС это делается, как показано на рис. 5.

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

После определения путей вставляем файл топографии и плана первого этажа на чертеж генерального плана как внешние ссылки (рис. 6а). Точка вставки остается 0,0,0, так как по правилам (де­факто) координаты на крестах топографии должны совпадать с координатами в AutoCAD.

Рис. 6. Окно вставки внешней ссылки: а — топографии; б — плана 1-го этажа здания. Точка вставки — Указать на экране

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

Рис. 7. Топография и план первого этажа совмещены на листе генерального плана

Рис. 8. Меняем цвет и толщину отображения слоя с топографией

Рис. 9. Заморозка ненужных слоев: а — через меню ленты; б — через главное меню

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

Также мы замораживаем ненужные слои. На рис. 9 показаны два разных способа: через меню ленты (а) и через главное меню (б).

Замораживаем слои (просто щелкая по объекту на чертеже):

• двери;
• оси промежуточные;
• размеры дополнительные;
• размеры промежуточные;
• стены несущие;
• стены самонесущие.
• Оставляем слои:
• оси главные;
• размеры главные;
• стены наружные;
• окна;
• входная лестница.

Далее создаем новую конфигурацию слоев с названием двумя разными способами: через меню ленты (рис. 10а) и через главное меню (рис. 10б).

Рис. 10. Создание конфигурации слоев: а — через меню ленты; б — через главное меню

Раздел НВК РАЗДЕЛ (аналогично — прочие наружные сети)

За генпланистом в процесс проектирования может включаться специалист по наружным сетям водопровода и канализации. Он работает в папке «3 НВК», расположенной в корневой директории проекта. Его чертеж будет импортером данных из генерального плана. Повторяем процедуру, описанную на рис. 4, копируем путь к файлу генерального плана аналогично рис.

5. Вставляем файл генерального плана аналогично рис 6. Точка вставки остается 0,0,0, так как по правилам координаты на крестах генерального плана должны совпадать с координатами в AutoCAD. Изображение должно соответствовать примеру на рис. 11.

Применяем конфигурации слоев (на рис.12 показано, как это делается через меню ленты). Через главное меню: Формат —> Диспетчер конфигураций слоев получается аналогично.

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

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

Но по правилам выполнения чертежей наружных коммуникаций мы должны отобразить тонкой линией и другие проектируемые коммуникации. Поэтому подключаем к чертежу файл Сводный план сетей.dwg, который в нашем примере будет лежать в папке «2 ГП» проекта. Вставляем Сводный план сетей.dwg аналогично тому, как это сделано на рис. 6. Точка вставки остается 0,0,0, так как в случае соблюдения всеми участниками проекта жесткой координатной привязки при вставке относительно нулевой точки вставляемые объекты примут верное положение (рис. 15).

Пока файл Сводный план сетей.dwg пуст, но скоро он наполнится ссылками на другие файлы проекта и будет держать нас в курсе изменений в смежных сетях, выполняя роль координатора. Аналогично реализуем планы прокладки сетей коммуникации, комплектов: НВК (остался чертеж «Канализация наружные сети»), ГСН, ЭН.

Сводный план сетей

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

• 3 НВК;
• Водоснабжение наружные сети.dwg;
• Канализация наружные сети.dwg;
• 4ГСН;
• Газопровод наружные сети.dwg;
• 5 ЭН;
• Наружное освещение.dwg.

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

Это не ошибка, а лишь свидетельство того, что файл с нашей конкретной сетью уже присутствует (в качестве внешней ссылки) в файле сводного плана сетей (рис. 17).

Теперь остается поменять в свойствах слоя толщину линии смежных сетей (делаем их тонкими), а толщину проектируемой сети сделать выше (толще). На рис. 18 представлены примеры того, как будут выглядеть планы комплектов НВК, ГСН, ЭН, после настройки слоев.

Рис. 17. Так будут выглядеть планы сетей комплектов: НВК, ГСН, ЭН

Рис. 19. Настройка параметров слоев

Согласование слоев

Согласование слоев — это инструмент AutoCAD, который будет держать в курсе всех изменений в слоях чертежей, вставленных как внешние ссылки. Пример: если генпланист создаст в чертеже генерального плана новые слои, например: отмостка, дорожки и т.д., инженеры, проектирующие наружные сети, будут мгновенно информированы об изменениях после того, как генпланист сохранит свой чертеж (и сохранит изменения на сервер, в случае работы с ЛОЦМАН:ПГС).

Они увидят их в диспетчере свойств слоев, в фильтре Несогласованные новые слои. Чтобы согласовать слой (то есть удалить из фильтра несогласованные новые слои), достаточно правой кнопкой выделить слой и выбрать Согласование слоя. Для того чтобы AutoCAD отслеживал изменение в слоях файлов внешних ссылок, нужно определенным образом настроить параметры слоев (рис. 19).

Выставляем галочки на пунктах: Оценивать новые слои, добавленные в чертеж, Уведомлять о наличии новых слоев (в этом пункте выставляем события, при которых программа будет уведомлять нас о появлении несогласованных слоев). Например, событие Вставить/Перезагрузить внешние ссылки будет уведомлять о появлении новых слоев при обновлении внешней ссылки (рис. 20).

Рис. 20. Уведомление о новом слое, загруженном с чертежа файла ссылки

Преимущества ЛОЦМАН:ПГС при организации сквозного проектирования

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

При использовании ЛОЦМАН:ПГС, перед тем как обновить локальные копии исходных файлов, мы увидим значок в панели файлов: исходный файл обновлен (на сервере) и нуждается в обновлении локальная копия (с которой и работает AutoCAD), то есть мы сами можем инициировать процедуру обновления, сократить мелкие порции обновленной информации, загружая обновления, допустим, не чаще раза в час. Это добавит размеренности в процесс проектирования.

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

Источник: sapr.ru