ПНСТ 574-2021
ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Нефтяная и газовая промышленность
СИСТЕМЫ ПОДВОДНОЙ ДОБЫЧИ
Интегрированные программно-зависимые системы. Методические указания
Petroleum and natural gas industry. Subsea production systems. Integrated software dependent systems. Methodology guide
ОКС 75.020
Срок действия с 2022-05-01
до 2025-05-01
Предисловие
1 РАЗРАБОТАН Обществом с ограниченной ответственностью "Газпром 335" (ООО "Газпром 335")
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 023 "Нефтяная и газовая промышленность"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 15 декабря 2021 г. N 67-пнст
Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16-2011 (разделы 5 и 6).
Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: [email protected] и/или в Федеральное агентство по техническому регулированию и метрологии по адресу: 123112 Москва, Пресненская набережная, д.10, стр.2.
В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе "Национальные стандарты" и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)
Введение
Создание и развитие отечественных технологий и техники для освоения шельфовых нефтегазовых месторождений должно быть обеспечено современными стандартами, устанавливающими требования к проектированию, строительству и эксплуатации систем подводной добычи. Для решения данной задачи Министерством промышленности и торговли Российской Федерации и Федеральным агентством по техническому регулированию и метрологии реализуется "Программа по обеспечению нормативной документацией создания отечественной системы подводной добычи для освоения морских нефтегазовых месторождений". В объеме работ программы предусмотрена разработка национальных и предварительных национальных стандартов, областью применения которых являются системы подводной добычи углеводородов.
Целью разработки настоящего стандарта является предоставление рекомендаций по порядку действий для управления разработкой, поставками, эксплуатацией и техническим обслуживанием интегрированных программно-зависимых систем, входящих в состав оборудования систем подводной добычи углеводородов.
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 Контрольные точки (M0-M5) разделяют этапы жизненного цикла ИПЗС. Далее представлен последовательный порядок действий, обязательный для дальнейшего перехода на следующий этап.
а) M0. Старт проекта:
- определены источники финансирования, участники проекта и зоны их ответственности;
б) M1. Готовность к началу проектирования и к заключению контрактов:
- определен доверительный уровень;
- сформированы потребности;
- определены основные системные требования и сценарии эксплуатации;
- определен предварительный проект (главные компоненты и интерфейсы ИПЗС);
- проведены консультации с потенциальными субподрядчиками;
- оценена осуществимость проекта.
в) M2. Готовность производства компонентов ИПЗС (головным исполнителем и его субподрядчиками):
- выполнен детальный проект компонентов ИПЗС;
- уточнены требования, а функции распределены по компонентам ИПЗС;
- проект ИПЗС окончательно утвержден всеми сторонами и верифицирован.
г) M3. Готовность начать верификационные и валидационные испытания:
- компоненты ИПЗС были изготовлены (было разработано ПО) и испытаны;
- процедуры монтажа, а также программы верификационных и валидационных испытаний четко определены;
- компоненты ИПЗС были собраны и были произведены интеграционные испытания;
- подготовлена необходимая техническая документация.
д) M4. ИПЗС готовы к эксплуатации:
- ИПЗС прошла верификацию (подтверждено ее соответствие требованиями соответствующих стандартов);
- ИПЗС прошла валидацию (подтверждена работоспособность ИПЗС и ее соответствие всем требованиям заказчика);
- ИПЗС смонтирована на месте эксплуатации;
- проведено обучение персонала.
е) М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 - Присвоение доверительных уровней
Риски (возможные последствия отказов/аварий) | Доверительный | ||
Социальные | Экологические | Экономические | уровень |
Функция, не работающая должным образом, не оказывает влияния на безопасность людей | Потеря функции никак не влияет на окружающую среду | Отказ оказывает минимальное влияние на эксплуатацию. Функция может привести к потере вспомогательных процессов, но не влияет на основную систему | 0 |
Социальный риск может считаться несущественным | Отказ может привести к минимальному загрязнению | Отказ может привести к временному отключению некритических систем, которые легко ремонтируются. Может привести к увеличению рабочей нагрузки оператора. Потеря функции может привести к минимальным финансовым потерям | 1 |
Отказ может привести к серьезным травмам или смертельному исходу | Отказ может привести к сильному загрязнению | Отказ может привести к продолжительной потере главной функции системы. Происшествие может привести к крупным финансовым потерям или серьезному повреждению системы. Ухудшение репутации компании | 2 |
Отказ может привести ко множеству смертельных случаев | Отказ может оказать серьезное влияние на окружающую среду | Отказ может привести к катастрофическому ущербу эксплуатируемой системе и серьезным финансовым потерям. Потеря репутации компании | 3 |
Доверительный уровень определяется как максимальная величина, определенная в соответствии с таблицей 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 - Обязательные действия (этап концепции)
Роль | Тип действий | Действие |
Заказчик | Разработка требований | Подготовить технические требования |
Заказчик | Дополнительные действия | Определить риски |
Определить требуемый доверительный уровень ИПЗС | ||
Системный интегратор | Разработка требований | Проработать технические требования заказчика |
Дополнительные действия | Определить риски | |
Поставщик | Дополнительные действия | Определить риски |
Оператор | Дополнительные действия | Определить риски |
7.4 Действия в зависимости от доверительного уровня
Действия на этапе концепции проекта представлены в таблице 3.
Таблица 3 - Действия на этапе концепции проекта
Роль | Тип действий | Действие | Доверительный уровень | ||
1 | 2 | 3 | |||
Заказчик | Разработка требований | Подготовить технические требования | х | х | х |
Определить цели, сроки и концепцию проекта | - | х | х | ||
Проработка технического решения | Определить баланс между запросами и их осуществимостью, ценой и ожидаемыми эксплуатационными характеристиками | - | х | х | |
Выработка стратегии управления устареванием технических решений | - | х | х | ||
Разработка | Согласовать проект концепции с заинтересованными организациями | х | х | х | |
Закупки | Согласовать объем предполагаемых закупок с поставщиками | х | х | х | |
Валидация | Использовать прототип или имитаторы для валидации концепта | - | х | х | |
Дополнительные действия | Определить все вовлеченные организации | х | х | х | |
Согласовать со всеми вовлеченными организациями общий план проекта | х | х | х | ||
Определить уровень необходимых затрат (сроки, финансы) | х | х | х | ||
Определить стратегию управления рисками | - | х | х | ||
Определить действия для снижения рисков | - | х | х | ||
К концу этапа концепта определить основные требования к закупаемому оборудованию | х | х | х | ||
Определить основные роли и зоны ответственности | х | х | х | ||
Выбрать сторону ответственную за верификацию/сертификацию проекта | - | х | х | ||
Выбрать сертификационное общество для верификации проекта | - | - | х | ||
В конце этапа концепта подтвердить выбранный доверительный уровень | х | х | х | ||
Системный интегратор | Разработка требований | Согласовать требования заказчика | х | х | х |
Транслировать требования заказчика в требования к ПО и техническим средствам | х | х | х | ||
Разработать сценарий выполнения проекта в части порядка взаимодействия всех вовлеченных сторон, согласовать его со всеми вовлеченными сторонами | - | х | х | ||
Определить функциональную архитектуру ИПЗС | - | х | х | ||
Определить распределение функций по компонентам ИПЗС | х | х | х | ||
Составить матрицу требований (соответствие требований заказчика и функций компонентов ИПЗС), проконтролировать, что ни одно из требований заказчика не было упущено | х | х | х | ||
Проработка технического решения | Рассмотреть возможные технические решения построения ИПЗС, выбрать решение на основе анализа требований заказчика и возможностей различных решений | - | х | х | |
Определить архитектуру ИПЗС | х | х | х | ||
Провести анализ предполагаемых поставщиков | - | х | х | ||
Определить баланс между требованиями заказчика, ценой проекта и предполагаемыми техническими решениями | - | х | х | ||
Выработать стратегию управления устареванием компонентов ИПЗС | - | х | х | ||
Разработка | Задокументировать системный дизайн ИПЗС | - | х | х | |
Согласовать концепцию со всеми заинтересованными сторонами | х | х | х | ||
Имплементация | Разработать симуляторы или прототипы для валидации концепта | - | х | х | |
Закупки | Провести консультации с предполагаемыми поставщиками | х | х | х | |
Провести анализ предложений поставщиков на предмет целесообразности внесения изменений в архитектуру ИПЗС | - | х | х | ||
Интеграция | Определить роли, зоны ответственности и необходимые мероприятия по интеграции для каждого компонента ИПЗС | х | х | х | |
Верификация | Проверить полноту предъявленных заказчиком требований | х | х | х | |
Проверить полноту распределения требований по компонентам | х | х | х | ||
Валидация | Согласовать концепцию ИПЗС с оператором (пользователями) | - | х | х | |
Подтвердить работоспособность концепции на прототипах/симуляторах | - | х | х | ||
RAMS | Определить список норм, правил, стандартов (стандарты организаций, отраслевые, государственные), которым должна следовать ИПЗС в плане требований RAMS | - | х | х | |
Согласовать все требования в части RAMS с заказчиком | - | х | х | ||
Дополнительные действия | Разработать план выполнения проекта | х | х | х | |
Определить все вовлеченные стороны | х | х | х | ||
Согласовать план выполнения проекта со всеми вовлеченными организациями | х | х | х | ||
Разработать стратегию управления рисками | - | х | х | ||
Определить возможные риски | х | х | х | ||
Определить действия для снижения рисков | - | х | х | ||
Определить необходимые процессы для управления проектом | х | х | х | ||
Выбрать сторону, ответственную за верификацию/сертификацию проекта | - | х | х | ||
Поставщик | Закупки | Провести консультации с предполагаемыми поставщиками (второго уровня) | х | х | х |
Транслировать предложения потенциальных поставщиков системному интегратору и провести их оценку соответствия требованиям | х | х | х | ||
Интеграция | Определить роли, зоны ответственности и необходимые мероприятия по интеграции для каждого компонента ИПЗС | х | х | х | |
Дополнительные действия | Согласовать план выполнения работ со всеми вовлеченными организациями | х | х | х | |
Определить необходимые процессы для управления проектом | х | х | х | ||
Оператор | Разработка требований | Рассмотреть технические требования | х | х | х |
Рассмотреть концепцию выполнения проекта и назначенные цели | - | х | х | ||
Проработка технического решения | Определить соответствие потребностей и сценариев эксплуатации предполагаемой реализации ИПЗС | х | х | х | |
Выработать стратегию управления устареванием компонентов ИПЗС | - | х | х | ||
Имплементация | Согласовать концепцию со всеми заинтересованными сторонами | х | х | х | |
Закупки | Провести консультации с предполагаемыми поставщиками | х | х | х | |
Валидация | Согласовать представленную концепцию ИПЗС | х | х | х | |
Проконтролировать проверку работоспособности концепции на прототипах/симуляторах | - | х | х | ||
Дополнительные действия | Согласовать план выполнения проекта со всеми вовлеченными организациями | х | х | х | |
Определить действия для снижения рисков | - | х | х | ||
Определить необходимые процессы для управления проектом | х | х | х | ||
Сертифи- кационное общество | Верификация | Произвести независимую оценку всей концепции проекта ИПЗС | - | - | х |
Примечание - Знак "х" обозначает "применимо", знак "-" - "не применимо".
| |||||
8 Этап проектирования
8.1 Общие положения
На этапе проектирования должны быть окончательно утверждены технические требования и начато проектирование ИПЗС и ее подсистем. На данном этапе принимают решение о приобретении компонентов ИПЗС и с поставщиками заключают договоры.
8.2 Цель
На данном этапе на основе предварительного проекта создается подробный проект ИПЗС. Архитектура ИПЗС должна быть закончена, а все интерфейсы и взаимосвязи - определены. Следует определить доверительный уровень для всех функций системы и проектные риски.
Проект оценивают на соответствие предъявляемым требованиям. Особое внимание должно быть уделено возможности проведения испытаний всех функций системы и подтверждения ее работоспособности.
Интерфейсы между подсистемами должны быть определены и задокументированы достаточно подробно, чтобы не требовалась дополнительная информация для процесса производства и разработки ПО.
Разрабатывают планы по верификации и валидации. Эти планы должны соответствовать предъявленным техническим требованиям.
Разрабатывают планы интеграции и развертывания. Они должны включать требования к испытаниям, требования к оборудованию и персоналу, процедурам, зона ответственности и графику работ.
8.3 Требуемые действия
Действия на этапе проектирования системы представлены в таблице 4.
Таблица 4 - Действия на этапе проектирования системы
Роль | Тип действий | Действие | Доверительный уровень | ||
1 | 2 | 3 | |||
Заказчик | Закупки | Определить головного исполнителя | х | х | х |
Валидация | Определить стратегию валидации | - | х | х | |
Дополнительные действия | Пересмотреть и, при необходимости, обновить перечень рисков | х | х | х | |
Определить действия для снижения рисков | - | х | х | ||
Контролировать существующие процессы | х | х | х | ||
Утвердить план выполнения проекта | х | х | х | ||
Контролировать план проекта | х | х | х | ||
Системный интегратор | Разработка требований | Транслировать требования к системе в требования к компонентам | - | х | х |
Отслеживать применение сформулированных требований, в том числе с внесенными правками | х | х | х | ||
Проработка технического решения | Утвердить технические решения и представить их реализацию на физическом уровне | - | х | х | |
Проконтролировать соответствие технического решения сценариям эксплуатации | - | х | х | ||
Контролировать этапы разработки ПО и проектной документации | - | х | х | ||
Согласовать протоколы передачи и хранения данных | х | х | х | ||
Разработка | Задокументировать интерфейсы компонентов ИПЗС | - | х | х | |
Вести независимую разработку компонентов (например, дублирующих) для предотвращения однотипных отказов | - | - | х | ||
Имплементация | Разработать прототипы для валида-ции с целью снизить риски возможных отказов при интеграции оборудования | - | х | х | |
Закупки | Выбрать поставщиков | х | х | х | |
Выбрать используемые коммерчески доступные серийные компоненты | х | х | х | ||
Заключить контракты с поставщиками | х | х | х | ||
Заключить контракты с поставщиками серийных компонентов | х | х | х | ||
Произвести выбор серийных компонентов (в том числе ПО) с учетом их возможного устаревания (прекращения поддержки) в будущем | - | х | х | ||
Интеграция | Проверить соответствие интерфейсов компонентов ИПЗС | - | х | х | |
Разработать стратегию интеграции | - | х | х | ||
Верификация | Проверить полноту представленного проекта ИПЗС на соответствие техническим требованиям и стандартам | х | х | х | |
Определить стратегию верификации | - | х | х | ||
Валидация | Определить стратегию валидации | - | х | х | |
Провести валидацию применяемых технических решений на прототипах | - | х | х | ||
RAMS | Определить риски, нарушающие выполнение требований RAMS | х | х | х | |
Определить корректирующие действие для наиболее значимых рисков | - | х | х | ||
Провести анализ FMECA для критически важных функций системы | - | - | х | ||
Провести независимый анализ критически важных функций системы | - | - | х | ||
Дополнительные действия | Согласовать общий план проекта с планами подрядчиков и поставщиков | х | х | х | |
Пересмотреть и обновить возможные риски | х | х | х | ||
Продумать корректирующие действия для минимизации рисков | - | х | х | ||
Предусмотреть необходимые ресурсы для проведения интеграции, верификации и валидации | х | х | х | ||
Контролировать процесс проектирования | - | х | х | ||
Разработать план выполнения проекта | х | х | х | ||
Контролировать выполнение плана проекта | х | х | х | ||
Поставщик | Разработка требований | Транслировать требования к системе в требования к компонентам | - | х | х |
Отслеживать применение сформулированных требований, в том числе с внесенными правками | х | х | х | ||
Проработка технического решения | Утвердить технические решения и представить их реализацию на физическом уровне | - | х | х | |
Согласовать протоколы передачи и хранения данных | х | х | х | ||
Имплементация | Разработать прототипы для валида-ции с целью снизить риски возможных отказов при интеграции оборудования | - | х | х | |
Разработка | Разработать компоненты ИПЗС | - | х | х | |
Задокументировать интерфейсы компонентов ИПЗС | - | х | х | ||
Подготовить конструкторскую и программную документацию на каждый компонент ИПЗС | - | х | х | ||
Поставщик | Закупки | Заключить контракты с поставщиками | х | х | х |
Произвести выбор серийных компонентов (в том числе ПО) с учетом их возможного устаревания (прекращения поддержки) в будущем | - | х | х | ||
Интеграция | Проверить соответствие интерфейсов компонентов ИПЗС | - | х | х | |
Дополнительные действия | Оценить сроки выполнения работ по каждому компоненту | х | х | х | |
Пересмотреть и обновить возможные риски | х | х | х | ||
Продумать корректирующие действия для минимизации рисков | - | х | х | ||
Контролировать процесс проектирования | х | х | х | ||
Разработать план выполнения проекта | х | х | х | ||
Контролировать выполнение плана проекта | х | х | х | ||
Оператор | Разработка требований | Уточнить сценарии эксплуатации для каждого компонента | - | х | х |
Валидация | Определить стратегию валидации ИПЗС | - | х | х | |
Дополнительные действия | Пересмотреть и обновить возможные риски | х | х | х | |
Дополнительные действия | Продумать корректирующие действия для минимизации рисков | - | х | х | |
Контролировать процесс проектирования | - | х | х | ||
Разработать план выполнения проекта | х | х | х | ||
Контролировать выполнение плана проекта | х | х | х | ||
Сертифи- кационное общество | Верификация | Произвести независимую проверку проектирования ИПЗС или отдельных ее компонентов (критически важных) | - | х | х |
Провести независимую проверку технических условий (спецификаций) на ИПЗС и ее компоненты | - | - | х | ||
Провести независимую проверку конструкторской и программной документации | - | - | х | ||
Верификация | Проверить корректность принятого протокола передачи (хранения) данных | - | х | х | |
RAMS | Провести независимый анализ критических компонентов и функций | - | - | х | |
Дополнительные действия | Независимо контролировать проектирование ИПЗС | - | х | х | |
Примечание - Знак "х" обозначает "применимо", знак "-" - "не применимо".
| |||||
9 Этап производства
9.1 Общие положения
На данном этапе компоненты ИПЗС изготавливают, закупают и интегрируют на основе документации, разработанной на предыдущем этапе. На этом этапе также может производиться параметризация и конфигурация компонентов. Затем проводят испытания компонентов. Проверяют согласованность интерфейсов, а затем выполняют интеграцию компонентов ИПЗС и проводят соответствующие интеграционные испытания.
Разработка программного обеспечения должна удовлетворять требованиям ГОСТ Р ИСО/МЭК 9126 и ГОСТ IEC 61508-3.
Разрабатываемая программная документация должна удовлетворять требованиям группы стандартов ЕСПД.
9.2 Цель
Целью данного этапа является выполнение задач по производству, закупке и сборке в соответствии с проектной документацией и графиком проекта.
Компоненты ИПЗС испытывают согласно соответствующим программам испытаний. Все интерфейсы компонентов ИПЗС испытывают на предмет подтверждения корректности коммуникации на имитаторах. Объем испытаний определяют пропорционально требуемому доверительному уровню компонентов: чем выше доверительный уровень, тем больший объем испытаний требуется. Объем испытаний должен быть определен системным интегратором и согласован поставщиком.
Все подсистемы и компоненты ИПЗС должны быть собраны, а интеграционные испытания проведены. В ходе интеграционных испытаний испытывают устойчивость ИПЗС к нарушениям в передаче сигналов или отказам отдельных компонентов. ИПЗС должна корректно детектировать внесенные неисправности. Необходимо подтвердить работу ИПЗС при последовательном отключении дублирующих систем.
9.3 Требуемые действия
Действия на этапе производства системы представлены в таблице 5.
Таблица 5 - Действия на этапе производства системы
Роль | Тип действий | Действие | Доверительный уровень | ||
1 | 2 | 3 | |||
Заказчик | Разработка требований | Контролировать возможные изменения в технических требованиях | х | х | х |
Валидация | Подтвердить работоспособность ИПЗС на прототипе | - | х | х | |
Дополнительные действия | Контролировать возможные риски | х | х | х | |
Определить действия для снижения рисков | - | х | х | ||
Контролировать процесс производства | х | х | х | ||
Контролировать план производства | х | х | х | ||
Системный интегратор | Разработка требований | Контролировать возможные изменения в технических требованиях | х | х | х |
Контролировать применение технических требований (трансляцию технических требований от поставщиков первого уровня к поставщикам следующих уровней) | х | х | х | ||
Проработка технического решения | Отслеживать возможные изменения в технических решениях | х | х | х | |
Имплементация | Определить цели в стратегии качества и отслеживать их достижение | - | х | х | |
Проконтролировать, корректно ли работают интерфейсы, не существует ли последовательности команд, приводящей к нарушению корректного обмена данными между компонентами | - | х | х | ||
Устранить все возникающие ошибки на этапе отладки ПО | - | х | х | ||
Проконтролировать, используют ли компоненты ИПЗС. 100% команд, которые могут быть отправлены источником, должны быть правильно интерпретированы приемником | - | х | х | ||
Закупки | Отслеживать процесс выполнения закупок поставщиками | х | х | х | |
Контролировать возможные изменения в договорах с поставщиками | х | х | х | ||
Контролировать, прослеживается ли ход работ поставщиков | - | х | х | ||
Контролировать промежуточные итоги деятельности/отгрузки поставщиков по мере их готовности | - | х | х | ||
Провести приемку оборудования/ПО от поставщиков | х | х | х | ||
Провести приемку передаваемых поставщиками серийно изготавливаемых компонентов/ПО сторонних производителей | х | х | х | ||
Интеграция | Подготовить все необходимое (имитаторы, инструменты, ПО) для интеграции, верификации и валидации ИПЗС | - | х | х | |
Начать интеграцию компонентов после их приемки | х | х | х | ||
Интеграция | Контролировать готовность компонентов к интеграции перед сборкой (в форме контрольного листа) | - | х | х | |
Провести сборки/монтаж компонентов | - | х | х | ||
Провести интеграционные испытания | - | х | х | ||
Контролировать возможные изменения в протоколах передачи/хранения данных | х | х | х | ||
Верификация | Проводить промежуточный контроль разработки ПО и технической документации | - | х | х | |
Разработать программу верификационных испытаний | - | х | х | ||
Выполнить верификацию разработанного ПО и компонентов | - | х | х | ||
Выполнить верификацию ИПЗС в сборе | - | х | х | ||
Убедиться, что объем испытаний покрывает все заявленные требования | - | х | х | ||
Убедиться, что программа тестирования ПО и программно-аппаратных комплексов покрывает все возможные комбинации входных параметров и проверяет достижимость всех выходных состояний системы (modifed condition/decision coverage - тестирование) | - | - | х | ||
Провести анализ программного кода | - | х | х | ||
Валидация | Провести валидацию ИПЗС на прототипе | - | х | х | |
RAMS | Проверить выполнение требований RAMS для всех компонентов ИПЗС | - | х | х | |
Убедиться, что функции ИПЗС с низким ДУ не оказывают потенциальное негативное влияние на функции с высоким ДУ (cross-contamination) | х | х | х | ||
Убедиться, что сеть передачи данных между компонентами ИПЗС защищена от блокирования при зависании одного из компонентов | - | х | х | ||
Проверить, дублируются/замещаются ли другими средствами критически важные функции системы | - | - | х | ||
Дополнительные действия | Утвердить спецификацию конфигурации/комплектности ИПЗС | х | х | х | |
Контролировать комплектность поставки | х | х | х | ||
После сборки/интеграции выпустить подробную спецификацию с описанием примененных компонентов и установленного ПО | х | х | х | ||
Контролировать процесс производства/сборки | х | х | х | ||
Поставщик | Разработка требований | Контролировать возможные изменения в технических требованиях | х | х | х |
Проработка технического решения | Отслеживать возможные изменения в технических решениях | х | х | х | |
Разработка | Внести изменения в проектную документацию, если такая необходимость возникла на этапе имплементации | х | х | х | |
Имплементация | Разработать/изготовить компоненты согласно технической документации | х | х | х | |
Разработать необходимую документацию (описания, инструкции, программы обучения) | - | х | х | ||
Имплементация | Провести предварительные испытания компонентов до начала их верификации | х | х | х | |
Определить цели в стратегии качества и следить за их выполнением | - | х | х | ||
Проконтролировать, используют ли компоненты ИПЗС при коммуникации одинаковый и понятный взаимодействующим компонентам набор команд. 100% команд, которые могут быть отправлены источником, должны быть правильно интерпретированы приемником | - | х | х | ||
Интеграция | Контролировать возможные изменения в протоколах передачи/хранения данных | х | х | х | |
Закупки | Контролировать возможные изменения в договорах с поставщиками | х | х | х | |
Провести приемку оборудования/ПО от поставщиков | х | х | х | ||
Проконтролировать комплектность получаемого оборудования/ПО от поставщиков и передачу системному интегратору | х | х | х | ||
Верификация | Проводить промежуточный контроль разработки ПО и технической документации | - | х | х | |
Выполнить верификацию разработанного ПО и компонентов | - | х | х | ||
Убедиться, что объем испытаний покрывает все заявленные требования | - | х | х | ||
Убедиться, что программа тестирования ПО и программно-аппаратных комплексов покрывает все возможные комбинации входных параметров и проверяет достижимость всех выходных состояний системы (modifed condition/ decision coverage - тестирование) | - | - | х | ||
Провести анализ программного кода | - | х | х | ||
RAMS | Проверить выполнение требований RAMS для изготавливаемых компонентов ИПЗС | - | х | х | |
Дополнительные действия | Контролировать возможные риски | х | х | х | |
Определить действия для снижения рисков | - | х | х | ||
В сопроводительной документации указать актуальную конфигурацию каждого поставленного компонента ИПЗС (отличия от серийных изделий, версия ПО и т.д.) | х | х | х | ||
Контролировать процесс производства | х | х | х | ||
Контролировать план производства | х | х | х | ||
Оператор | Разработка требований | Контролировать возможные изменения в технических требованиях | х | х | х |
Валидация | Проконтролировать валидацию ИПЗС на прототипе | - | х | х | |
Дополнительные действия | Контролировать возможные риски | х | х | х | |
Определить действия для снижения рисков | - | х | х | ||
Контролировать процесс производства | х | х | х | ||
Контролировать план производства | х | х | х | ||
Сертифи- кационное общество | Верификация | Провести независимый анализ программного кода | - | - | х |
Провести независимую квалификацию компонентов ИПЗС | - | - | х | ||
Дополнительные действия | Независимо контролировать процесс производства и разработки ПО | - | х | х | |
Примечание - Знак "х" обозначает "применимо", знак "-" - "не применимо". | |||||
10 Этап приемки в эксплуатацию
10.1 Общие положения
На данном этапе должны быть выполнены все действия, необходимые для подтверждения заявленных технических требований на ИПЗС. Этап приемки в эксплуатацию также включает в себя монтаж/развертывание, интеграцию и испытание на месте до передачи системы в эксплуатацию.
10.2 Цель
Целью данного этапа является контроль действий от завершения интеграционных испытаний до момента передачи системы в эксплуатацию. На данном этапе требуется показать, что компоненты ИПЗС и вся система целиком функционируют согласно заявленным требованиям. Интеграционные испытания могут быть проведены как на производственной площадке, так и на месте эксплуатации. Во время испытаний помимо штатных режимов должны имитироваться возможные нештатные режимы эксплуатации.
10.3 Действия
Действия на этапе приемки представлены в таблице 6.
Таблица 6 - Действия на этапе приемки
Роль | Тип действий | Действие | Доверительный уровень | ||
1 | 2 | 3 | |||
Заказчик | Разработка требований | Контролировать возможные изменения в технических требованиях | х | х | х |
Дополнительные действия | Зафиксировать конфигурацию системы после установки (система должна быть защищена от несанкционированного изменения конфигурации) | х | х | х | |
Контролировать процесс приемки | х | х | х | ||
Контролировать план выполнения работ | х | х | х | ||
Контролировать возможные риски | х | х | х | ||
Определить действия для снижения рисков | - | х | х | ||
Системный интегратор | Разработка требований | Контролировать возможные изменения в технических требованиях | х | х | х |
Проработка технического решения | Отслеживать возможные изменения в технических решениях | х | х | х | |
Имплементация | При необходимости вносить изменения в ИПЗС контролируемым образом (системы и функции, на которые влияют вносимые изменения, должны быть испытаны) | х | х | х | |
Закупки | Провести приемку оборудования у поставщиков | х | х | х | |
Верификация | Провести верификацию компонентов ИПЗС и системы целиком | х | х | х | |
Валидация | Провести валидацию на подтверждение работоспособности ИПЗС во всех ожидаемых сценариях | - | х | х | |
Проанализировать результаты валидации на соответствие поставленным целям по качеству | - | х | х | ||
Провести тестирование ИПЗС методом "черного ящика" | - | х | х | ||
RAMS | Проконтролировать выполнение требований RAMS | - | х | х | |
Дополнительные действия | Задокументировать конфигурацию системы перед вводом в эксплуатацию | х | х | х | |
Зафиксировать конфигурацию системы после установки (система должна быть защищена от несанкционированного изменения конфигурации) | х | х | х | ||
Контролировать возможные внесения изменений (обновлений) в конфигурацию системы | х | х | х | ||
Контролировать процесс приемки | х | х | х | ||
Контролировать план выполнения работ | х | х | х | ||
Контролировать возможные риски | х | х | х | ||
Определить действия для снижения рисков | - | х | х | ||
Поставщик | Разработка требований | Контролировать возможные изменения в технических требованиях | х | х | х |
Проработка технического решения | Отслеживать возможные изменения в технических решениях | х | х | х | |
Имплементация | При необходимости вносить изменения в ИПЗС контролируемым образом (системы и функции, на которые влияют вносимые изменения, должны быть испытаны) | х | х | х | |
Верификация | Провести верификацию компонентов ИПЗС и системы целиком | х | х | х | |
RAMS | Проверить выполнение требований RAMS для изготавливаемых компонентов ИПЗС | - | х | х | |
Дополнительные действия | Задокументировать конфигурацию системы перед вводом в эксплуатацию | х | х | х | |
Зафиксировать конфигурацию системы после установки (система должна быть защищена от несанкционированного изменения конфигурации) | х | х | х | ||
Контролировать процесс приемки | х | х | х | ||
Контролировать план выполнения работ | х | х | х | ||
Контролировать возможные риски | х | х | х | ||
Дополнительные действия | Определить действия для снижения рисков | - | х | х | |
Оператор | Разработка требований | Контролировать возможные изменения в технических требованиях | х | х | х |
Валидация | Проконтролировать валидацию на подтверждение работоспособности ИПЗС во всех ожидаемых сценариях | - | х | х | |
Проанализировать результаты валидации на соответствие поставленным целям по качеству | - | х | х | ||
Дополнительные действия | Зафиксировать конфигурацию системы после установки (система должна быть защищена от несанкционированного изменения конфигурации) | х | х | х | |
Контролировать процесс приемки | х | х | х | ||
Контролировать план выполнения работ | х | х | х | ||
Контролировать возможные риски | х | х | х | ||
Определить действия для снижения рисков | - | х | х | ||
Сертифи- кационное общество | Валидация | Провести независимую валидацию и верификацию ИПЗС | - | - | х |
Осуществлять независимый контроль выполнения работ | - | х | х | ||
Примечание - Знак "х" обозначает "применимо", знак "-" - "не применимо".
| |||||
11 Этап эксплуатации
11.1 Общие положения
Данный этап включает все операции по эксплуатации, в том числе техническое обслуживание, плановые и внеплановые модернизацию и ремонт. Он также распространяется на действия по выводу системы из эксплуатации. На данном этапе ответственность за выполнение задач может лежать на поставщике или операторе.
11.2 Цель
Цель состоит в том, чтобы управлять работой системы от первого запуска до вывода из эксплуатации. Задача заключается в том, чтобы установить процедуры, управляющие процессом эксплуатации системы, проведением периодических испытаний, техническим обслуживанием, аудитом и поддержкой пользователей. Помимо того должен быть разработан структурированный способ анализа проблем, а также контроля за вносимыми изменениями. При необходимости следует разработать план по выводу системы из эксплуатации.
11.3 Действия
Действия на этапе эксплуатации представлены в таблице 7.
Таблица 7 - Действия на этапе эксплуатации
Роль | Тип действий | Действие | Доверительный уровень | ||
1 | 2 | 3 | |||
Заказчик/ собственник | Разработка требований | Вносить дополнения в технические требования (в случае необходимости) | х | х | х |
Закупки | Контролировать "устаревание" применяемых компонентов (снятие с производства, прекращение поддержки) | - | х | х | |
Валидация | Осуществлять мониторинг соответствия ИПЗС сценариям эксплуатации | - | х | х | |
Дополнительные действия | Передать полномочия по отслеживанию изменений конфигураций системы (ремонт, модернизация, обновление и настройка ПО) оператору | х | х | х | |
Оценивать запросы о необходимости внесения изменений/модернизации и принимать решение о ее проведении | х | х | х | ||
Контролировать процесс эксплуатации | х | х | х | ||
Контролировать план выполнения работ | х | х | х | ||
Контролировать возможные риски | х | х | х | ||
Определить действия для снижения рисков | - | х | х | ||
Системный интегратор | Разработка требований | Контролировать возможные изменения в технических требованиях | х | х | х |
Проработка технического решения | Отслеживать возможные изменения в технических решениях | х | х | х | |
Имплементация | При необходимости вносить изменения в ИПЗС контролируемым образом (системы и функции, на которые влияют вносимые изменения должны быть испытаны) | х | х | х | |
Верификация | Провести верификацию (компонентов ИПЗС или системы целиком) при внесении изменений | х | х | х | |
Дополнительные действия | Передать полномочия по отслеживанию изменений конфигураций системы (ремонт, модернизация, обновление и настройка ПО) оператору | х | х | х | |
Определить план и процедуры проведения технических работ | х | х | х | ||
Оценивать запросы о необходимости внесения изменений/модернизации и давать рекомендацию о ее проведении | х | х | х | ||
Поставщик | Разработка требований | Контролировать возможные изменения в технических требованиях | х | х | х |
Проработка технического решения | Отслеживать возможные изменения в технических решениях | х | х | х | |
Закупки | Контролировать "устаревание" применяемых компонентов (снятие с производства, прекращение поддержки) | - | х | х | |
Дополнительные действия | Оценивать запросы о необходимости внесения изменений/модернизации и принимать решение о ее проведении | х | х | х | |
Верификация | Провести верификацию поставляемых на модернизацию ИПЗС компонентов | х | х | х | |
Оператор | Разработка требований | Контролировать возможные изменения в технических требованиях | х | х | х |
Закупки | Контролировать "устаревание" применяемых компонентов (снятие с производства, прекращение поддержки) | - | х | х | |
RAMS | Контролировать эксплуатацию и отчитываться об инцидентах | - | х | х | |
Дополнительные действия | Принять полномочия по отслеживанию изменений конфигураций системы (ремонт, модернизация, обновление и настройка ПО) | х | х | х | |
Дополнительные действия | Определить план и процедуры проведения технических работ | х | х | х | |
Проводить испытания после модернизации/ремонта | х | х | х | ||
Оценивать запросы о необходимости внесения изменений/ модернизации и принимать решение о ее проведении | х | х | х | ||
Проводить аудит состояния системы | х | х | х | ||
Контролировать процессы на этапе эксплуатации | х | х | х | ||
Контролировать график проведения работ | х | х | х | ||
Отслеживать риски | х | х | х | ||
Принимать действия для минимизации рисков | - | х | х | ||
Примечание - Знак "х" обозначает "применимо", знак "-" - "не применимо".
| |||||
Библиография
[1] | DNVGL-RP-D201-2017* | Интегрированные программно-зависимые системы - Практическое руководство (Integrated software dependent systems - Recommended practice) |
[2] | Руководство по безопасности | Методика анализа риска аварий на опасных производственных объектах морского нефтегазового комплекса (утверждено Приказом Федеральной службы по экологическому, технологическому и атомному надзору от 16 сентября 2015 г. N 364) |
УДК 629.12:006.354 | ОКС 75.020 |
Ключевые слова: нефтяная и газовая промышленность; системы подводной добычи; интегрированные программно-зависимые системы | |
