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

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Постановлением Государственного комитета СССР по стандартам от 26 марта 1984 г. ¹ 973 срок введения установлен

с 01.07 1985 г.

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

Настоящий стандарт следует применять совместно с другими стандартами Единой системы стандартов АСУ.

1. НАЗНАЧЕНИЕ И КЛАССИФИКАЦИОННЫЕ ПРИЗНАКИ ВИДОВ АСУ

1.1. АСУ предназначена для обеспечения эффективного функционирования объекта управления путем автоматизированного выполнения функций управления.

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

1.2. Основными классификационными признаками, определяющими вид АСУ, являются:

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

2. ФУНКЦИИ, СОСТАВ И СТРУКТУРЫ АСУ

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

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

2.3. Функции АСУ в общем случае включают в себя следующие элементы (действия):

• планирование и (или) прогнозирование;
• учет, контроль, анализ;
• координацию и (или) регулирование.

Необходимый состав элементов выбирают в зависимости от вида конкретной АСУ.

2.4. Функции АСУ можно объединять в подсистемы по функциональному и другим признакам.

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

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

2.5.1. В состав информационного обеспечения АСУ входят классификаторы технико-экономической информации, нормативно-справочная информация, форма представления и организация данных в системе, в том числе формы документов, видеограмм, массивов и логические интерфейсы (протоколы обмена данными).

2.5.2. В состав программного обеспечения АСУ входят программы (в том числе программные средства) с программной документацией на них, необходимые для реализации всех функций АСУ в объеме, предусмотренном в техническом задании на создание АСУ.

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

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

2.5.5. В состав метрологического обеспечения АСУ входят метрологические средства и инструкции по их применению.

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

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

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

2.5.8. В состав математического обеспечения АСУ входят методы решения задач управления, модели и алгоритмы.

В функционирующей системе математическое обеспечение реализовано в составе программного обеспечения.

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

При описании АСУ пользуются следующими видами структур, отличающимися типами элементов и связей между ними:

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

3. СОЗДАНИЕ, РАЗВИТИЕ И ПОСТАВКА АСУ

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

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

3.2. При создании АСУ необходимо руководствоваться принципами системности, развития, совместимости, стандартизации и унификации, а также и эффективности.

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

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

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

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

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

3.3. При создании АСУ на систему в целом разрабатывают техническую, в том числе общесистемную документацию.

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

3.5. При создании АСУ научно-исследовательские, проектные, конструкторские и другие организации должны руководствоваться:

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

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

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

3.8. Создание АСУ осуществляют на основании договора между разработчиком и заказчиком системы.

3.9. Развитие АСУ представляет собой процесс расширения состава функций АСУ, базирующийся на результатах анализа функционирования АСУ и объекта управления и направленных и повышение эффективности функционирования объекта управления.

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

4.ФУНКЦИОНИРОВАНИЕ И ВЗАИМОДЕЙСТВИЕ АСУ

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

4.2. Функции АСУ могут быть реализованы в автоматическом автоматизированном режимах, в том числе и в диалоговом.

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

4.4. На объекте, на котором функционируют (создают) АСУ различных уровней и назначений следует осуществлять, по мере необходимости, объединение их в единую АСУ. Например в рамках отрасли могут взаимодействовать АСУ министерств, АСУ разных территориальных объединений, АСУ всесоюзных и республиканский промышленных объединений, АСУ производственных и научно-производственных объединений, АСУ предприятий (организаций).

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

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

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

Переиздание. Май 1986 г.

ГОСТ 24.103-84 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ. ОСНОВНЫЕ ПОЛОЖЕНИЯ" | 2011-12-02 05:25:28 | Super User | Дополнительно | https://сайт/media/system/images/new.png | УДК 65.011.56:006.354 Группа П87 Г О С | журнальный ключ dr.web, настройка windows, защита от записи

ГОСТ 24.103-84
АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ.
ОСНОВНЫЕ ПОЛОЖЕНИЯ

1. НАЗНАЧЕНИЕ И КЛАССИФИКАЦИОННЫЕ ПРИЗНАКИ ВИДОВ АСУ

1.1. АСУ предназначена для обеспечения эффективного функционирования объекта управления путем автоматизированного выполнения функций управления.

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

1.2. Основными классификационными признаками, определяющими вид АСУ, являются:

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

2. ФУНКЦИИ, СОСТАВ И СТРУКТУРЫ АСУ

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

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

2.3. Функции АСУ в общем случае включают в себя следующие элементы (действия):

• планирование и (или) прогнозирование;
• учет, контроль, анализ;
• координацию и (или) регулирование.

Необходимый состав элементов выбирают в зависимости от вида конкретной АСУ.

2.4. Функции АСУ можно объединять в подсистемы по функциональному и другим признакам.

ГОСТ 24.104-85
Автоматизированные системы управления системы управления
Общие требования

1.1.2. Ввод в действие АСУ должен приводить к полезным технико-экономическим, социальным или другим результатам, например:

• снижению численности управленческого персонала;
• повышению качества функционирования объекта управления;
• повышению качества управления и др.

1.2.1. АСУ в необходимых объемах должна автоматизированно выполнять:

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

1.5.2. Программное обеспечение АСУ должно обладать следующими свойствами:

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

ДОПОЛНИТЕЛЬНЫЕ ТРЕБОВАНИЯ К АСУ ПРЕДПРИЯТИЯМИ, ПРОИЗВОДСТВЕННЫМИ И НАУЧНО-ПРОИЗВОДСТВЕННЫМИ ОБЪЕДИНЕНИЯМИ

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

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

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

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

ГОСТ 34.003-90
Автоматизированные системы
Термины и определения

1. Автоматизированные системы. Общие понятия

Общетехнические термины и пояснения, применяемые в области автоматизированных систем

1. Система :
   Совокупность элементов, объединенная связями между ними и обладающая определенной целостностью.
2. Автоматизированный процесс :
   Процесс, осуществляемый при совместном участии человека и средств автоматизации.
3. Автоматический процесс :
   Процесс, осуществляемый без участия человека.
4. Информационная технология :
   Приемы, способы и методы применения средств вычислительной техники при выполнении функций сбора, хранения, обработки, передачи и использования данных.
5. Цель деятельности :
   Желаемый результат процесса деятельности.
6. Критерий эффективности деятельности :
   Соотношение, характеризующее степень достижения цели деятельности и принимающее различные числовые значения в зависимости от используемых воздействий на объект деятельности или конкретных результатов деятельности.
7. Объект деятельности :
   Объект (процесс), состояние которого определяется поступающими на него воздействиями человека (коллектива) и, возможно, внешней среды.
8. Алгоритм :
   Конечный набор предписаний для получения решения задачи посредством конечного количества операций.
9. Информационная модель :
   Модель объекта, представленная в виде информации, описывающей существенные для данного рассмотрения параметры и переменные величины объекта, связи между ними, входы и выходы объекта и позволяющая путем подачи на модель информации об изменениях входных величин моделировать возможные состояния объекта.
10. Управление :
    Совокупность целенаправленных действий, включающая оценку ситуации и состояния объекта управления, выбор управляющих воздействий и их реализацию.
11. Автоматизированный производственный комплекс :
    Автоматизированный комплекс, согласованно осуществляющий автоматизированную подготовку производства, само производство и управление им.

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

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

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

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

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

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

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

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

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

• приложения двухуровневые, состоящие из клиентской программы и сервера СУБД (никаких трех- и более «уровневых» приложений, никаких Weblogic или JBoss)
• структура таблиц базы данных, будучи описана, даст представление о логической модели данных (то, что между приложением и базой может находиться какой-нибудь Hibernate, тогда казалось нехорошим излишеством)
• пользовательский интерфейс однооконный (а разве бывает другой? А что такое «браузер»?)
• Отчетов в системе немного, все они бумажные и печатаются на матричном принтере
• Разрабатываемая программа ориентирована на решение «задачи обработки информации», которая имеет четкий вход и выход и узко специализирована. В основе обработки информации лежит «алгоритм». Иногда «алгоритмов» бывает несколько. (Объектно-ориентированное программирование тогда делало лишь свои первые шаги и серьезно не рассматривалось).
• администратор базы данных понимает, какая информация лежит в таблицах и активно участвует в редактировании системных справочников (а разве бывает один сервер СУБД для 50 разных приложений?)

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

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

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

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

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

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

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

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

Можно смеяться над тем, что создатели стандартов ничего не знали о java или.NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального сообщества.

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

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

• Эскизный проект (ЭП)
• Технический проект (ТП)
• Разработка рабочей документации (РД)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Полное и точное следование стандарту . Добровольно никто, естественно, такую тучу документов писать не будет. Поэтому полный комплект документов готовится только по настоятельной просьбе заказчика, которую он закрепил в ТЗ и еще договором сверху придавил. В таком случае требуется понимать все буквально и отдать заказчику физические «книжки», на которых будут стоять названия документов из таблицы 2 ГОСТ 34.201-89 за исключением совсем уж ненужных, перечень которых вы обязательно должны обговорить и закрепить письменно. Содержание документов также должно без всякой фантазии соответствовать РД 50-34.698-90, вплоть до названия разделов. Для того, чтобы у заказчика взорвался мозг, иногда большую систему делят на подсистемы, и для каждой подсистемы выпускают отдельную проектную документацию. Выглядит это устрашающе и нормальному контролю при помощи земного разума не подлежит. Особенно в части интеграции подсистем. Что значительно упрощает приемку. Главное, чтобы вы сами при этом не запутались и чтобы ваша система все-таки заработала как надо.
2. Мы просто любим ГОСТы . В серьезных больших компаниях любят стандарты. Потому, что они помогают людям лучше понимать друг друга. Если ваш заказчик замечен в любви к порядку и стандартизации, постарайтесь придерживаться стандартной идеологии ГОСТ при разработке документов, даже если этого не требует ТЗ. Вас лучше поймут и одобрят согласующие специалисты, а вы сами не забудете включить в документацию важную информацию, лучше будете видеть целевую структуру документов, точнее планировать работы по их написанию и сэкономите себе и коллегам массу нервов и денег.
3. Нам плевать на документацию, лишь бы все работало . Исчезающий вид безответственного заказчика. Подобный взгляд на документацию пока еще можно встретить у небольших и бедных заказчиков, а также в оставшихся со времен перестройки авторитарных «идиотократиях», где босс окружен верными друзьями - директорами, и все вопросы решаются в личных беседах. Вы вольны в подобных условиях забивать на документирование вообще, но лучше, все таки, прицел не сбивать и хотя бы схематично наполнять содержимым документацию. Если не этому заказчику, так следующему передадите (продадите).

Заключение

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

Без применения автоматизации технологических процессов в современном обществе не обходится ни одна отрасль производства. Наибольшее распространение получило внедрение и проектирование АСУ ТП в нефтяной и газовой промышленности, но в последнее время АСУ ТП затрагивает такие сферы как ЖКХ, энергетика, металлургия и многие другие.

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

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

Основные функции АСУ ТП:

Основными функциями автоматизированных систем управления технологическими процессами являются:

• контроль и управление;
• обмен данными;
• обработка, накопление и хранение информации;
• формирование сигналов тревог, построение графиков и отчетов.

Согласно ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания», процесс создания АСУ ТП представляет собой совокупность работ, упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы, выполнение которых необходимо и достаточно для создания системы, соответствующей заданным требованиям.

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

Рекомендуемая последовательность стадий по созданию АСУ ТП:

• Формирование требований к АСУ ТП
• Разработка концепции АСУ ТП
• Техническое задание
• Эскизный проект
• Технический проект
• Рабочий проект (Рабочая документация)
• Ввод в действие
• Сопровождение АСУ ТП.

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

Разработка концепции АСУ ТП

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

Проектирование АСУ ТП

Проектирование АСУ ТП осуществляется в соответствии с Постановлением Правительства РФ от 16.02.2008 г. №87 «О составе разделов проектной документации и требованиями к их содержанию», региональными строительными нормами и требованиями технического задания. При проектировании АСУ ТП учитываются требования существующего законодательства и нормативных документов по экологии, охране труда и пожарной безопасности.

Техническое задание АСУ ТП

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

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

Технический проект АСУ ТП (стадия «ПД»)

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

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

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

Рабочая документация АСУ ТП (стадия «РД»)

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

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

Цели и выгоды от создания АСУ ТП

Создание систем автоматизации технологических процессов имеет следующие цели и выгоды:

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

Для определения стоимости разработки технических заданий на создание АСУ ТП и документации по общесистемным решениям, организационному, информационному, техническому, математическому и программному обеспечению АСУ ТП ЗАО «Научно-производственный центр «ВНИПИ САУ-40» и ТП «ЦЕНТРИНВЕСТпроект» был разработан «Справочник базовых цен на разработку технической документации на автоматизированные системы управления технологическими процессами (АСУ ТП)», который утвержден Министерством промышленности Российской Федерации 14 марта 1997 г. по представлению Министерства строительства Российской Федерации (письмо от 27.01.97 г. № 9-4/8).