ПНСТ 574-2021 Нефтяная и газовая промышленность. Системы подводной добычи. Интегрированные программно-зависимые системы. Методические указания

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

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

Нефтяная и газовая промышленность

СИСТЕМЫ ПОДВОДНОЙ ДОБЫЧИ

Интегрированные программно-зависимые системы. Методические указания

Издание официальное

Москва Российский институт стандартизации 2022

Предисловие

• 1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Газпром 335» (ООО «Газпром 335»)

• 2 ВНЕСЕН Техническим комитетом по стандартизации ТК 023 «Нефтяная и газовая промышленность»

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

Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТР 1.16—2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: [email protected] и/или в Федеральное агентство по техническому регулированию и метрологии по адресу: 123112 Москва, Пресненская набережная, д. 10, стр. 2.

В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе «Национальные стандарты» и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

© Оформление. ФГБУ «РСТ», 2022

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

Содержание

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

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

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

• 4 Общие положения

• 5 Определение и присвоение доверительных уровней

• 6 Разработка программного обеспечения и интеграция

• 7 Этап концепции

• 8 Этап проектирования

• 9 Этап производства

• 10 Этап приемки в эксплуатацию

• 11 Этап эксплуатации

Библиография

Введение

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

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

ПНСТ 574—2021

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

Нефтяная и газовая промышленность

СИСТЕМЫ ПОДВОДНОЙ ДОБЫЧИ

Интегрированные программно-зависимые системы. Методические указания

Petroleum and natural gas industry. Subsea production systems. Integrated software dependent systems. Methodology guide

Срок действия — с 2022—05—01 до 2025—05—01

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

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

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

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

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

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

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

ГОСТ IEC 61508-3 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению

ГОСТ Р ИСО/МЭК 9126 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению

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

Издание официальное

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

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

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

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

• 3.1.2 архитектура (автоматизированной системы) (architecture): Наиболее абстрактное представление автоматизированной системы, которое включает в себя идеализированные модели компонентов системы, а также модели взаимодействий между компонентами. {Дать перевод на английском языке}

• 3.1.3

валидация (validation): Подтверждение посредством представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены.

[ГОСТ Р ИСО 9000—2015, статья 3.8.13]

• 3.1.4

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

[ГОСТ Р ИСО 9000—2015, статья 3.8.12]___________________________________________________

• 3.1.5 доверительный уровень (confidence level): Мера того, насколько важна функция для работы системы и ее безопасности.

• 3.1.6 имплементация (implementation): Процесс разработки программного обеспечения и сопутствующей программной документации, а также процесс адаптации программного обеспечения к интегрированной программно-зависимой системе.

• 3.1.7 интеграционные испытания (integration testing): Испытания в которых различные модули программного обеспечения, аппаратные компоненты или программно-аппаратные комплексы испытываются для подтверждения корректного взаимодействия между ними.

• 3.1.8

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

[ГОСТ 34.003—90, пункт 1.2]

• 3.1.9 интегрированная программно-зависимая система (integrated software dependent system): Интегрированная автоматизированная система, общее функционирование которой зависит от функционирования ее программного обеспечения.

• 3.1.10

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

[ГОСТ 15971—90, пункт 30]

• 3.1.11

компонент автоматизированной системы: Часть автоматизированной системы, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое.

[ГОСТ 34.003—90, пункт 2.13]

• 3.1.12

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

[ГОСТ Р 50304—92, пункт 15]

• 3.1.13

физическая реализация интерфейса: Совокупность требований к электрическим характеристикам и конструктивной реализации интерфейса.

[ГОСТ Р 50304—92, пункт 17]

• 3.1.14

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

[ГОСТ 34,003—90, пункт 1.3]

• 3.2 Сокращения

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

ДУ — доверительный уровень;

ИПЗС — интегрированная программно-зависимая система;

ПО — программное обеспечение;

СПД — система подводной добычи (углеводородов);

FMECA — анализ режимов, последствий и критичности отказов (failure mode, effects and criticality analysis);

RAMS — надежность, готовность, ремонтопригодность, (функциональная) безопасность [reliability, availability, maintainability, (functional) safety].

• 4 Общие положения

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

  • 4.2 Настоящий стандарт определяет, каким образом системе, ее компонентам и выполняемым функциям автоматизированной системы (далее — функциям) должны быть присвоены доверительные уровни. Доверительный уровень является мерой того, насколько важна функция для работы системы и ее безопасности.

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

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

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

Рисунок 1 —Жизненный цикл ИПЗС

• 4.5 Контрольные точки (МО—М5) разделяют этапы жизненного цикла ИПЗС. Далее представлен последовательный порядок действий, обязательный для дальнейшего перехода на следующий этап.

• а) МО. Старт проекта:

• - определены источники финансирования, участники проекта и зоны их ответственности;

• б) М1. Готовность к началу проектирования и к заключению контрактов:

• - определен доверительный уровень;

• - сформированы потребности;

• - определены основные системные требования и сценарии эксплуатации;

• - определен предварительный проект (главные компоненты и интерфейсы ИПЗС);

• - проведены консультации с потенциальными субподрядчиками;

• - оценена осуществимость проекта.

• в) М2. Готовность производства компонентов ИПЗС (головным исполнителем и его субподрядчиками):

• - выполнен детальный проект компонентов ИПЗС;

• - уточнены требования, а функции распределены по компонентам ИПЗС;

• - проект ИПЗС окончательно утвержден всеми сторонами и верифицирован.

• г) М3. Готовность начать верификационные и валидационные испытания:

• - компоненты ИПЗС были изготовлены (было разработано ПО) и испытаны;

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

• - компоненты ИПЗС были собраны и были произведены интеграционные испытания;

• - подготовлена необходимая техническая документация.

• д) М4. ИПЗС готовы к эксплуатации:

• - ИПЗС прошла верификацию (подтверждено ее соответствие требованиями соответствующих стандартов);

• - ИПЗС прошла валидацию (подтверждена работоспособность ИПЗС и ее соответствие всем требованиям заказчика);

• - ИПЗС смонтирована на месте эксплуатации;

• - проведено обучение персонала.

• е) М5. Система выводится из эксплуатации.

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

Рисунок 2 — Присвоение доверительного уровня

• 4.7 Для оценки того, какие функции, системы или компоненты ИПЗС представляют наибольшую опасность в случае возможной аварии, следует использовать методы анализа риска, например, анализ видов, последствий и критичности отказов (FMECA) или другие.

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

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

• 4.10 При проектировании, производстве и монтаже ИПЗС следует учитывать:

• - что настоящий стандарт не регламентирует детальные требования к компонентам ИПЗС; отдельные компоненты ИПЗС должны соответствовать применимым к ним стандартам;

• - настоящий стандарт указывает требования, обязательные для интеграции системы;

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

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

Примеры ИПЗС, распределения ролей и задач приведены в [1].

• 5 Определение и присвоение доверительных уровней

  • 5.1 Доверительные уровни

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

    • 5.1.2 Основной принцип выбора доверительного уровня состоит в том, что чем выше потенциальные последствия отказа системы или функции управления, тем выше должен быть присвоенный доверительный уровень.

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

  • 5.2 Правила присвоения доверительных уровней

    • 5.2.1 Каждая функция, выполняемая ИПЗС, должна иметь определенный доверительный уровень, основанный на анализе рисков и оценке потенциальных последствий, которые могут быть вызваны отказом данной функции. Доверительные уровни должны быть определены на этапе разработки концепта.

    • 5.2.2 Доверительный уровень, присваиваемый всей ИПЗС как целому, должен быть не менее максимального доверительного уровня функций ИПЗС.

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

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

• 5.2.4 Анализ риска аварий на опасных производственных объектах морского нефтегазового комплекса следует проводить согласно [2].

• 5.2.5 В таблице 1 приведено руководство по выбору соответствующего доверительного уровня.

Таблица 1 — Присвоение доверительных уровней

Доверительный уровень определяется как максимальная величина, определенная в соответствии с таблицей 1.

Примечание — Если анализ социальных и экологических рисков по таблице 1 приводит к доверительному уровню 1, а анализ экономических рисков к доверительному уровню 3, следует выбрать доверительный уровень 3.

• 5.3 Присвоение доверительных уровней компонентам ИПЗС

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

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

• 5.4 Определение доверительного уровня при совмещении функций

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

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

• 6 Разработка программного обеспечения и интеграция

  • 6.1 Зоны ответственности

    • 6.1.1 В реализации этапов проектирования, производства и эксплуатации ИПЗС участвуют различные организации. Могут быть выделены пять основных ролей:

• - заказчик;

• - системный интегратор;

• - оператор;

• - поставщик;

• - независимый сертификационный орган.

Заказчик является организацией, которая инициирует и финансирует проект.

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

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

• 6.1.4 Поставщик представляет любого субподрядчика, предоставляющего компоненты системы ИПЗС, под руководством системного интегратора.

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

• 6.2 Необходимый объем работ для различных доверительных уровней

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

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

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

К системам с доверительным уровнем 2 предъявляются дополнительные требования к процессам проектирования, разработки, интеграции, верификации и валидации. На этом уровне должны выполняться мероприятия по управлению рисками. Этот уровень также рекомендует привлекать независимое сертификационное общество (далее — сертификационное общество) к верификации проекта.

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

• 6.3 Фактор новизны

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

• 7 Этап концепции

  • 7.1 Общие положения

Процессы на этапе концепции охватывают предварительное проектирование и формирование технических требований на компоненты и ПО ИПЗС.

• 7.2 Цель

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

Техническое задание разрабатывают согласно требованиям ГОСТ 34.602.

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

По завершении данного этапа:

• - должен быть разработан предварительный проект, включая архитектуру ИПЗС;

• - определены интерфейсы ИПЗС;

• - определены области повышенных проектных рисков;

• - назначено ответственное лицо для контроля интерфейсов и интеграции компонентов ИПЗС.

• 7.3 Обязательные действия

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

Таблица 2 — Обязательные действия (этап концепции)

Окончание таблицы 2

• 7.4 Действия в зависимости от доверительного уровня

Действия на этапе концепции проекта представлены в таблице 3.

Таблица 3 — Действия на этапе концепции проекта

Продолжение таблицы 3

Окончание таблицы 3

• 8 Этап проектирования

  • 8.1 Общие положения

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

• 8.2 Цель

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

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

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

Разрабатывают планы по верификации и валидации. Эти планы должны соответствовать предъявленным техническим требованиям.

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

• 8.3 Требуемые действия

Действия на этапе проектирования системы представлены в таблице 4.

Таблица 4 — Действия на этапе проектирования системы

Продолжение таблицы 4

Продолжение таблицы 4

Окончание таблицы 4

• 9 Этап производства

  • 9.1 Общие положения

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

Разработка программного обеспечения должна удовлетворять требованиям ГОСТ Р ИСО/МЭК 9126 и ГОСТ IEC 61508-3.

Разрабатываемая программная документация должна удовлетворять требованиям группы стандартов ЕСПД.

• 9.2 Цель

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

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

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

• 9.3 Требуемые действия

Действия на этапе производства системы представлены в таблице 5.

Таблица 5 — Действия на этапе производства системы

Продолжение таблицы 5

Продолжение таблицы 5

Окончание таблицы 5

• 10 Этап приемки в эксплуатацию

  • 10.1 Общие положения

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

• 10.2 Цель

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

• 10.3 Действия

Действия на этапе приемки представлены в таблице 6.

Таблица 6 — Действия на этапе приемки

Продолжение таблицы 6

Окончание таблицы 6

Примечание — Знак «х» обозначает «применимо», знак «—» — «не применимо».

• 11 Этап эксплуатации

  • 11.1 Общие положения

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

• 11.2 Цель

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

• 11.3 Действия

Действия на этапе эксплуатации представлены в таблице 7.

Таблица 7 — Действия на этапе эксплуатации

Окончание таблицы 7

Примечание — Знак «х» обозначает «применимо», знак «—» — «не применимо».

УДК 629.12:006.354

Ключевые слова: нефтяная и газовая промышленность; системы подводной добычи; интегрированные программно-зависимые системы

Редактор З.Н. Киселева Технический редактор В.Н. Прусакова Корректор Р.А. Ментова Компьютерная верстка Е.О. Асташина

Сдано в набор 17.12.2021. Подписано в печать 13.01.2022. Формат 60х84¹/₈. Гарнитура Ариал. Усл. печ. л. 3,26. Уч.-изд. л. 2,64.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано в единичном исполнении в ФГБУ «РСТ» , 117418 Москва, Нахимовский пр-т, д. 31, к. 2.