Требования к асу кратко

Обновлено: 06.07.2024

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

- снижению численности управленческого персонала;

- повышению качества функционирования объекта управления;

- повышению качества управления и др.

1.1.3. Конкретное содержание требований по пп.1.1.2, 1.1.5-1.1.11, 1.2, 1.3, 1.4.2, 1.4.3, 1.4.6, 1.4.9, 1.5.2, 1.5.4, 1.5.6, 1.5.7, 1.6.2, 1.6.6, 1.6.12, 1.7.2, 1.7.3 устанавливают в ТЗ на АСУ.

1.1.4. АСУ должна обеспечивать достижение целей ее создания (развития), установленных в ТЗ на АСУ.

1.1.5. В АСУ должна быть обеспечена совместимость между ее частями, а также с автоматизированными системами (АС), взаимосвязанными с данной АСУ.

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

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

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

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

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

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

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

1.1.12. Любая поступающая в АСУ информация вводится в систему однократно с помощью одного входного канала, если это не приводит к невыполнению требований, установленных в ТЗ на АСУ (по надежности, достоверности и т.п.).

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

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

1.1.15. АСУ должна быть защищена от утечки информации, если это оговорено в ТЗ на АСУ.

1.1.16. Наименование АСУ должно включать наименования вида АСУ и объекта управления.

- АСУТП нагрева металла в методической печи;

- организационно-технологическая АСУ цехом N 5;

- АСУП завода "Серп и молот".

1.2. Требования к функциям АСУ

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

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

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

- снижению численности управленческого персонала;

- повышению качества функционирования объекта управления;

- повышению качества управления и др.

· АСУ должна обеспечивать достижение целей ее создания (развития), установленных в ТЗ на АСУ.

· В АСУ должна быть обеспечена совместимость между ее частями, а также с автоматизированными системами (АС), взаимосвязанными с данной АСУ.

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

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

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

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

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

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

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

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

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

· АСУ должна быть защищена от утечки информации если это оговорено в ТЗ на АСУ.

· Наименование АСУ должно включать наименование вида АСУ и объекта управления.

- снижению численности управленческого персонала;

- повышению качества функционирования объекта управления;

- повышению качества управления и др.

· АСУ должна обеспечивать достижение целей ее создания (развития), установленных в ТЗ на АСУ.

· АСУ должна быть защищена от утечки информации если это оговорено в ТЗ на АСУ.

· Наименование АСУ должно включать наименование вида АСУ и объекта управления.

Текст ГОСТ Р 58675-2019 Автоматизированная система управления данными об изделии. Общие требования

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР 58675— 2019

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

АВТОМАТИЗИРОВАННАЯ СИСТЕМА УПРАВЛЕНИЯ ДАННЫМИ ОБ ИЗДЕЛИИ

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

Москва Стандартинформ 2019

ГОСТ Р 58675—2019

Предисловие

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 21 ноября 2019 г. № 1212-ст

4 ВВЕДЕН ВПЕРВЫЕ

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

Содержание

1 Область применения

2 Нормативные ссылки

3 Термины, определения и сокращения

4 Основные положения

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

данными об изделии с прикладными автоматизированными системами

ГОСТ Р 58675—2019

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

АВТОМАТИЗИРОВАННАЯ СИСТЕМА УПРАВЛЕНИЯ ДАННЫМИ ОБ ИЗДЕЛИИ Общие требования

Automated product data management system. General requirements

Дата введения — 2020—06—01

1 Область применения

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

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

Примечание — Настоящий стандарт не распространяется на техническую документацию, включенную в Единый российский страховой фонд документации.

2 Нормативные ссылки

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

ГОСТ 2.053 Единая система конструкторской документации. Электронная структура изделия. Общие положения

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

ГОСТ Р 50739 Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования

ГОСТ Р 50922 Защита информации. Основные термины и определения

ГОСТ Р 51275 Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения

ГОСТ Р 54088 Интегрированная логистическая поддержка. Эксплуатационная и ремонтная документация в форме интерактивных электронных технических руководств. Основные положения и общие требования

ГОСТ Р 54089 Интегрированная логистическая поддержка. Электронное дело изделия. Основные положения и общие требования

ГОСТ Р 58299 Управление данными об изделии. Порядок представления результатов проектноконструкторских работ в электронной форме. Общие требования

ГОСТ Р 58300 Управление данными об изделии. Термины и определения

ГОСТ Р 58676 Электронная конструкторская документация. Виды преобразований

3 Термины, определения и сокращения

3.1 Термины и определения

В настоящем стандарте применены термины по ГОСТ 34.003. ГОСТ Р 50922 и ГОСТ Р 58300, а также следующие термины с соответствующими определениями:

компьютерная модель (электронная модель): Модель, выполненная в компьютерной (вычислительной) среде и представляющая собой совокупность данных и программного кода, необходимого для работы с данными.

(ГОСТ Р 57412-2017, статья 3.1.7]

математическая модель: Модель, в которой сведения об объекте моделирования представлены в виде математических символов и выражений.

[ГОСТ Р 57412-2017, статья 3.1.4]

информационная модель: Модель, в которой сведения об объекте моделирования представлены в виде совокупности элементов данных и отношений между ними.

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

[ГОСТ Р 57412—2017. статья 3.1.5]

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

АС — автоматизированная система;

АС УДИ — автоматизированная система управления данными об изделии:

ЖЦ — жизненный цикл;

РКР — результат проектно-конструкторских работ;

ЭДИ — электронное дело изделия.

4 Основные положения

4.1 АС УДИ представляет собой вид АС. под управлением которой находятся (см. рисунок 1):

- данные о разрабатываемом (изготааливаемом/эксплуатируемом) изделии, создаваемые в ходе стадий и этапов ЖЦ;

• нормативно-справочная информация, используемая в организации при разработке, производстве и эксплуатации изделия;

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

Читайте также: