Модернизация внутри объекта уровня BSL-3 или BSL-4 редко ограничивается только тем компонентом, к которому физически прикасались. Прежде чем проектная группа сможет определить, что именно нужно тестировать, ей необходимо установить, что на самом деле изменилось — и именно этот вопрос о границах, а не сам метод тестирования, определяет, насколько обоснованы результаты приемочных испытаний. Неправильное определение этих границ в любом направлении влечет за собой реальные издержки: если границы слишком узкие, непроверенный интерфейс вновь вводится в эксплуатацию с непроверенной функцией локализации; если слишком широкие — в рамках проекта повторно тестируются системы, которые никогда не подвергались изменениям.
В рамки модернизации должны входить как физические, так и функциональные изменения
| Интерфейс модернизации | Вопрос о границах | Принятие — планирование — последствие |
|---|---|---|
| Проходные отверстия и уплотнения | Привела ли эта модификация к нарушению герметичности или пробое в защитной оболочке? | Включить осмотр и испытания поврежденного уплотнения; не следует делать выводов об общем объеме или пределах испытаний на герметичность помещения. |
| Зоны давления | Привело ли это изменение к изменению соответствующей зависимости давления? | Включить проверку направленности воздушного потока для данной взаимосвязи. |
| Траектории выхлопных газов | Изменила ли модернизация траекторию выхлопных газов или их соединительный узел? | Включите затронутую функцию вывода данных в границы теста. |
| Органы управления, сигнализация и блокировки | Изменились ли настройки управления, логика или состояние интерфейса? | Проведите испытания соответствующих органов управления, сигнализации и блокировок при различных состояниях интерфейса. |
| Коммунальные услуги, оборудование для перекачки и системы обращения с отходами | Изменила ли эта работа физическое соединение или функциональную зависимость на одном из этих интерфейсов? | Рассматривайте затронутую функцию как часть границы изменения и выбирайте метод проверки с учетом рисков проекта. |
Модернизация системы локализации редко представляет собой единичное изолированный мероприятие. Работа над одним интерфейсом зачастую затрагивает другие интерфейсы, с которыми он связан физически или функционально, даже если никто не предполагал такого результата. A проходка кабеля или шнура Установка защитной стенки представляет собой физическое изменение, но может также являться функциональным изменением, если она изменяет перепад давления по обе стороны от барьера, через который она проходит. Обновление схемы управления, связанное с дверью или шлюзом, является функциональным изменением даже в том случае, если никакое оборудование не заменялось. Первой задачей проектной группы является не тестирование, а выявление того, какие физические границы и какие функциональные взаимосвязи были нарушены в результате работ по модернизации, независимо от того, насколько незначительным казалось данное вмешательство в тот момент.
Это важно, поскольку эффективность локализации зависит от взаимосвязей. Проход, зона давления, путь отвода, контрольная точка, подключение к инженерным сетям и интерфейс для отходов не функционируют независимо друг от друга; каждый из них зависит от того, что остальные сохраняют свое проектное состояние. Если в ходе модернизации изменяется один из этих элементов, граница “того, что изменилось” должна распространяться на каждую функцию, зависящую от изменившегося состояния, а не только на компонент, который был физически вскрыт или заменен. Изменение зоны давления, вызванное новым проходом, является функциональным следствием физического действия, и оба эти элемента должны находиться в пределах одной и той же границы приемлемости.
Практическое следствие для планирования проекта заключается в том, что границы изменений необходимо определить до составления списка тестов, а не выводить их из него. Если команда начнёт с вопроса “какие тесты мы обычно проводим после подобных работ”, она рискует протестировать только очевидные физические изменения и упустить функциональные последствия, распространяющиеся по всей системе. Если же она начнёт с вопроса “какие интерфейсы — проходы, зоны давления, пути отвода, средства управления, инженерные коммуникации, перекачивающее оборудование, интерфейсы для отходов — были нарушены, физически или функционально, в результате этой модернизации”, список тестов будет вытекать из границ, основанных на фактах, а не на привычках.
Если модернизация ограничивается одним-единственным, хорошо изолированным компонентом, не имеющим общих зависимостей, границы остаются узкими, а приемочные работы — целенаправленными. Если же модернизация затрагивает общий ресурс, общую систему управления или функцию, от которой зависят последующие компоненты, границы должны расширяться, чтобы включить эти зависимые компоненты, даже если сами эти компоненты физически не изменялись. Определение того, какое из этих условий имеет место, является первым решением, которое должна принять проектная группа, и оно должно быть сформулировано явно, а не предполагаться исходя из объема работ, указанного в заказе на техническое обслуживание.
Имеющиеся данные по-прежнему применимы только к неизменённым конфигурациям
| Условие доказательности | Допустимое использование | Импликация принятия |
|---|---|---|
| Конфигурация осталась прежней, и доказательства по-прежнему имеют силу | Сохраните запись в качестве исходного состояния для этой неизменённой конфигурации. | Из материалов дела не следует, что измененный интерфейс был принят. |
| Изменение интерфейса может повлиять на предыдущий или последующий результат | Не следует переносить результат на следующий этап без повторной оценки его применимости. | Включить соответствующий результат в объем повторной проверки. |
| Неясно, соответствует ли конфигурация или применимы ли доказательства | Рассматривайте применимость как неизвестную величину, зависящую от конкретного проекта. | Оставьте соответствующую функцию в пределах области проверки до тех пор, пока связь не будет установлена. |
Документация по квалификации и вводу в эксплуатацию, составленная при первоначальном строительстве объекта или в ходе предыдущей модернизации, служит подтверждением конкретной конфигурации на определенный момент времени. Такое подтверждение остается действительным только до тех пор, пока описываемая в нем конфигурация остается неизменной. Вопрос о приемке результатов модернизации заключается не в том, были ли предыдущие подтверждающие документы адекватными на момент их составления — они почти наверняка были таковыми, — а в том, сохраняется ли описываемая в них конфигурация после завершения текущих работ.
Именно в этом заключается различие между приемом работ по модернизации и вводом в эксплуатацию нового объекта. При вводе в эксплуатацию нового объекта вся документация составляется с учетом окончательной конфигурации, соответствующей фактическому состоянию. При модернизации проект включает в себя смешанную картину: некоторые системы остаются без изменений, другие были непосредственно модифицированы, а третьи находятся в промежуточном положении — они не подвергались непосредственным изменениям, но примыкают к тем, что были изменены, или зависят от них. Проектная группа должна отнести каждую систему к одной из этих категорий, прежде чем определять, какая документация к ней применима.
Самая сложная категория — третья. Изменение интерфейса может привести к утрате действительности соседнего результата даже в том случае, если соседняя система никогда не вводилась в эксплуатацию, поскольку при предыдущей квалификации соседней системы предполагалось наличие определённого условия — соотношения давлений, траектории воздушного потока, состояния системы управления — которое могло измениться в результате модернизации. Использование записи о квалификации без повторной оценки того, сохраняется ли исходное допущение, означает, что унаследованные данные рассматриваются как самообновляющиеся, чего на самом деле не происходит.
Если соответствие конфигурации между фактическим состоянием модернизированного объекта и состоянием, описанным в отчете о квалификации, является очевидным и неизменным, существующий отчет может служить в качестве базового документа, и его не нужно повторять. Если же такое соответствие неясно — если команда не может подтвердить, затронула ли модернизация какое-либо допущение, на котором основывались более ранние данные, — честный подход заключается в том, чтобы рассматривать применимость как открытый вопрос и оставить соответствующую функцию в пределах границ проверки до тех пор, пока эта взаимосвязь не будет установлена, а не по умолчанию переходить к полному принятию или полному повторному тестированию. Это в равной степени вопрос дисциплины ведения документации и технический вопрос: пакет документов по приему модернизации должен показывать для каждой унаследованной записи, почему она была признана по-прежнему применимой, а не просто указывать на её наличие.
Проходные отверстия, уплотнения и взаимосвязь с давлением требуют целенаправленной проверки
| Измененный интерфейс | Целевые доказательства | Что подтверждает чек | Граница доказательств |
|---|---|---|---|
| Кабельный или иной проход через стену | Осмотр и испытание поврежденного уплотнения прохода после замены или ремонта | Доказательства изменения степени проникновения и его герметичности | В нём не устанавливаются универсальные требования к герметичности помещений, фиксированные предельные значения или порядок утверждения продукции. |
| Соединение двери с пневматическим уплотнением | Проверка поврежденной пломбы и всех соответствующих сигналов тревоги или блокировок после замены пломбы или обновления системы управления | Свидетельства изменения функций дверного интерфейса | Он не допускает использования неизменённых систем в других местах. |
| Взаимосвязь давления между затронутыми зонами | Проверка направленности воздушного потока для соответствующей взаимосвязи | Доказательства изменения взаимосвязи между давлением и зоной | Он не проверяет соседние нетронутые зоны. |
После определения границы изменения в ходе приемочных работ необходимо предоставить подтверждающие данные, соответствующие каждому конкретному интерфейсу, а не проводить общие испытания, одинаково применяемые ко всему объекту. Проходные отверстия, уплотнения и соотношения давлений ведут себя по-разному, и данные, подтверждающие работоспособность одного из них, не могут быть перенесены на остальные.
Проход в стене — для кабелей, шнуров или других коммуникаций — оценивается на основе проверка и испытание данного конкретного уплотнения после проведения работ по изменению или ремонту, затронувших данное место. Это служит подтверждением герметичности данного прохода и его уплотнения; при этом не устанавливается степень герметичности всего помещения или универсальный предел, и это не дает представления о состоянии других проходов в той же стене, которые не подвергались вмешательству. Если на объекте используется специальный порт для шнуров и кабелей, как, например, в случае Проникающее устройство типа «Vacu-Pass», целевая проверка касается именно этого конкретного порта и его уплотнительного соединения, а не всей стенной конструкции в целом.
A интерфейс двери с пневматическим уплотнением требует проведения отдельной проверки. Если был заменен уплотнитель двери или выполнено обновление программного обеспечения если было изменено поведение блокировок или сигнализации двери, целевая проверка должна охватывать саму пломбу, а также любые функции сигнализации или блокировки, связанные с новым состоянием этой пломбы. Данные доказательства подтверждают работоспособность интерфейса двери; они не принимают во внимание неизменённые системы в других частях того же шлюза или комплекса, даже если эти системы используют одну и ту же платформу управления.
Взаимосвязь давления между двумя зонами требует проверки направленности воздушного потока, специфичной для данной взаимосвязи. Это отличается как от проверки герметичности прохода, так и от проверки дверей, поскольку взаимосвязь давления представляет собой динамическое состояние на системном уровне, а не статическое состояние герметичности — оно зависит от того, что вытяжной тракт, баланс приточного воздуха и состояние дверей одновременно функционируют в соответствии с проектом. Проверка взаимосвязи для одной затронутой пары зон служит подтверждением для этой пары; она ничего не говорит о соседней, не затронутой паре зон, даже если обе пары имеют общий вытяжной отвод выше по потоку.
На практике это означает, что план приемки работ по модернизации не может опираться на один тип испытаний для охвата нескольких категорий интерфейсов. Если в ходе модернизации одновременно затрагивались проход, дверной уплотнитель и соотношение давлений, для проекта требуются три отдельных набора доказательств, каждый из которых должен охватывать свой собственный интерфейс, причем границы каждого результата должны быть сформулированы достаточно четко, чтобы впоследствии их нельзя было истолковать как охватывающие больше, чем предусмотрено.
Системы управления и блокировки требуют тестирования при переходе между новыми состояниями интерфейса
Системы управления и блокировки представляют собой иную проблему при приемочных испытаниях, чем уплотнения или зоны давления, поскольку их функционирование определяется поведением в различных состояниях, а не одним статическим условием. Система управления или блокировка, прошедшая проверку в одном состоянии — при закрытой двери, в состоянии покоя системы или при нормальном рабочем давлении — не обязательно будет вести себя корректно во всех состояниях, которые могли возникнуть или измениться в результате модернизации.
Если в ходе модернизации изменяется конфигурация системы управления или лежащая в ее основе логика, новая или измененная логика должна быть протестирована для каждого состояния интерфейса, которым она управляет, а не только для того состояния, которое удобно проверить. Например, блокировка двери, связанная с перепадом давления, по замыслу конструкторов должна охватывать как минимум нормальное состояние, переходное состояние, а также любое состояние неисправности или сигнализации. Если проверяется только нормальное состояние, то при приемочных испытаниях модернизации подтверждается, что дверь ведет себя правильно, когда все в порядке, а именно в этом состоянии наименее вероятно выявление ошибки, вызванной внесенными изменениями.
Это особенно важно в тех случаях, когда модернизация заключалась в обновлении логики управления, а не в замене аппаратного обеспечения. Изменение логики может повлиять на то, как оценивается состояние аварийного сигнала, как система блокировки реагирует на предельное состояние или как теперь взаимодействуют два ранее независимых контура управления, при этом без каких-либо видимых физических изменений. Поскольку на аппаратном уровне изменения незаметны, единственный способ убедиться в том, что система ведет себя так, как и предполагалось, — это проверить систему в каждом состоянии, которое должна обрабатывать новая логика, и убедиться, что реакция соответствует задуманному проекту, включая состояния, представляющие отклонение или условие восстановления, а не работу в установившемся режиме.
В данном случае задача проектной группы состоит в том, чтобы для каждого измененного элемента управления или блокировки определить полный набор состояний, которые были введены или изменены в результате модернизации — не только те состояния, которые были предусмотрены в первоначальном проекте, но и любые новые состояния, созданные самой модернизацией, — и подтвердить, что каждое из этих состояний вызывает предусмотренную реакцию. В тех случаях, когда модернизация изменила общую платформу управления, эта обязанность распространяется на каждую функцию блокировки или сигнализации, управляемую этой платформой, даже если целью изменения была только одна конкретная функция.
Ремонтные работы или отклонения могут привести к расширению объема повторной проверки
| Триггер | Почему нынешний объем работ может оказаться недостаточным | Необходимое лечение |
|---|---|---|
| Отклонение при проверке | У данной функции больше нет результата без оговорок для тестируемой конфигурации. | Зафиксируйте отклонение, определите, какую границу оно затрагивает, и задокументируйте все ремонтные работы и повторную проверку. |
| Восстановление работоспособности поврежденного интерфейса | Конфигурация после ремонта отличается от той, при которой были получены предыдущие доказательства. | Зафиксируйте результаты ремонта и повторно проверьте работу соответствующей функции. |
| Изменение, которое может повлиять на соседний результат | Изменение интерфейса может привести к утрате действительности доказательств для связанной функции. | Проведите повторную оценку соседней записи и расширьте сферу повторной проверки в тех случаях, когда она больше не применима. |
| Техническое обслуживание или восстановление после дезактивации, влияющее на функциональность | Состояние восстановления является частью затронутой функциональной границы. | Проведите проверку соответствующей функции восстановления с учетом рисков проекта и зафиксируйте конфигурацию и подтверждающие данные. |
Само приемочное тестирование может привести к появлению новой информации, которая изменит объем того, что ещё предстоит проверить. Отклонение, обнаруженное в ходе проверки, или ремонт, выполненный на интерфейсе В результате такой проверки дело не заканчивается с решением непосредственной проблемы — это сигнал, требующий от проектной группы пересмотреть, по-прежнему ли первоначальные границы тестирования полностью охватывают весь объем того, что требует подтверждения.
Отклонение в ходе верификации означает, что для данной функции больше нет утверждённого результата для тестируемой конфигурации. Это отличается от успешного теста без отклонений: как только возникает отклонение, функция переходит в состояние «неурегулированное» до тех пор, пока она не будет либо успешно протестирована повторно, либо отклонение не будет устранено и задокументировано иным образом. Исправление, выполненное на затронутом интерфейсе, изменяет саму конфигурацию — система после исправления уже не является той же системой, которая была описана в ранее представленных данных, даже если исправление было направлено на восстановление первоначального замысла проекта, поскольку фактическое состояние изменилось в процессе достижения этого результата.
Более серьезный случай возникает тогда, когда отклонение или ремонт показывают, что соседний результат, который ранее считался незатронутым, может больше не быть применимым. Это напрямую связано с поднятыми ранее вопросами о границах и применимости доказательств: ремонт на одном из интерфейсов может сделать недействительным допущение, на котором основывалась соседняя запись об аттестации, даже если соседняя система никогда не подвергалась непосредственному воздействию в ходе модернизации или ремонта. Осознание этого требует от проектной группы рассматривать каждое отклонение и каждый ремонт как повод для пересмотра границ, а не просто устранять непосредственную проблему и двигаться дальше.
Функции технического обслуживания или восстановления герметичности заслуживают такого же внимания в тех случаях, когда их затронула модернизация. Функция восстановления — это способность системы вернуться к предусмотренному проектом состоянию герметичности после мероприятие по техническому обслуживанию или дезактивации — является частью функциональной границы, которая могла быть нарушена в ходе модернизации, даже если это не первая функция, которую команда решает протестировать. Если в ходе модернизации был изменен интерфейс, связанный с восстановлением, сама функция восстановления должна быть проверена с учетом соответствующего риска, а конфигурация и полученные доказательства должны быть зафиксированы вместе с остальными документами пакета приемочной документации.
В записях о выпуске необходимо проводить разграничение между измененными и неизмененными системами
| Раздел «Отчеты о выпусках» | Обязательное поле | Значение решения |
|---|---|---|
| Проверенная конфигурация и граница изменений | Определите физическую и функциональную конфигурацию, на которую распространяются приемочные работы по модернизации. | Определяет, к чему относятся новые доказательства. |
| Проверенные интерфейсы и функции | Перечислите затронутые проходы, уплотнения, соотношения давлений, пути отвода, средства управления, сигнализацию, блокировки или функции восстановления, которые были фактически проверены. | Показывает, какие измененные функции прошли целевую проверку. |
| Имеющиеся доказательства сохранены | Определите более ранние записи, использовавшиеся исключительно для неизменённых конфигураций, в отношении которых данные по-прежнему остаются актуальными. | Разграничивает данные, полученные в ходе исходных испытаний, и результаты новых испытаний, проведенных после модернизации. |
| Отклонения, исправления и повторная проверка | Регистрируйте каждое отклонение или ремонт, а также доказательства, представленные после этого. | Показывает, как исключения повлияли на окончательный объем тестирования и набор доказательств. |
| Незатронутые системы | Определите системы, выходящие за пределы тестируемой области изменений. | Предотвращает использование разрешения на модернизацию в качестве нового подтверждения приемки для систем, в которые не вносились изменения. |
Окончательное заключение по приемочной проверке модернизации объекта уровня BSL-3/4 — это не результат испытаний, а то, как в протоколе сдачи отражена взаимосвязь между тем, что было проверено, и тем, что не проверялось. Протокол сдачи, в котором просто указывается, что объект прошел приемочные испытания, без разграничения проверенных изменений и нетронутых систем, создает пробел в документации, который на неопределённый срок ложится на плечи владельца объекта: любой, кто позже прочитает этот протокол, не сможет понять, на какие именно системы распространяются новые данные.
В протоколе необходимо явно указать тестируемую конфигурацию и границы изменений, чтобы любой, кто будет его изучать позже, точно понимал, какой физический и функциональный объем работ был охвачен при приемочных испытаниях после модернизации. В нём должны быть перечислены конкретные интерфейсы и функции, которые были фактически проверены — проходные отверстия, уплотнения, соотношения давлений, пути отвода отработавших газов, средства управления, сигнализация, блокировки или функции восстановления, подвергшиеся целенаправленной проверке, — а не даваться общее описание работ, которое может быть истолковано как более широкое, чем то, что было выполнено на самом деле. В отчете необходимо указать, какие предыдущие протоколы квалификации были сохранены в качестве исходных доказательств и к каким неизменённым конфигурациям эти доказательства по-прежнему применимы, чтобы различие между новыми испытаниями и унаследованными доказательствами было отслеживаемым, а не подразумеваемым.
Если в ходе процесса приемки возникло отклонение или потребовался ремонт, в отчете должно быть указано, как данное событие было устранено и какие доказательства были представлены впоследствии, чтобы будущий рецензент мог понять, как был определен окончательный объем испытаний, а не предполагать, что первоначальный план был выполнен без исключений. Наконец, в протоколе необходимо указать системы, которые вообще находятся за пределами границ тестируемого изменения — системы, которые не затронула модернизация ни физически, ни функционально, — чтобы впоследствии этот протокол не был ошибочно истолкован как новое доказательство приемки для этих нетронутых систем.
Данная структура в большей степени отвечает долгосрочным интересам владельца объекта, чем непосредственным целям текущего проекта по модернизации: будущая модернизация, аудит или проверка будут зависеть от возможности определить исключительно на основании документации, какие системы содержат актуальные данные, а какие — данные о более ранней конфигурации, которые, возможно, уже не актуальны. Если в рамках коммерческого предложения или анализа проекта QUALIA предоставляются сведения о конфигурации модернизации, затронутых интерфейсах и основе оценки рисков, именно эта информация о границах позволяет оборудованию, такому как двери APR, порты для шнуров и кабелей, или компоненты системы фильтрации на месте должны быть настроены и задокументированы с учетом фактического объема изменений, а не исходя из общих предположений о том, что именно включала в себя модернизация.
Часто задаваемые вопросы
Q: Требует ли каждая модернизация до уровня BSL-3/4 повторного тестирования всего объекта?
A: Объем приемочных испытаний должен начинаться с границ физических и функциональных изменений, а затем расширяться везде, где изменение интерфейса может привести к утрате актуальности данных, подтверждающих работоспособность связанной функции. Неизмененные системы могут оставаться за пределами нового объема испытаний только в том случае, если их конфигурация не изменилась и имеющиеся данные по-прежнему применимы.
Q: Какую информацию о проекте необходимо собрать до того, как будет окончательно утвержден план приемки модернизации?
A: Задокументируйте измененную конфигурацию, затронутые проходы, соотношения давлений, пути отвода, средства управления, инженерные сети, перекачивающее оборудование и интерфейсы для отходов, а также протоколы квалификации, предложенные в качестве базовых. Кроме того, определите известные отклонения, ремонтные работы, мероприятия по техническому обслуживанию и восстановлению, чтобы перед запуском можно было оценить их влияние на границы испытания.
Q: Можно ли повторно использовать запись о квалификации, созданную ранее, после изменения соседнего интерфейса?
A: Только после подтверждения того, что зафиксированная конфигурация осталась неизменной и что данные по-прежнему актуальны. Если изменение интерфейса может повлиять на предыдущий результат, оставьте данную связанную функцию в пределах границ пересмотра до тех пор, пока не будет установлена её применимость или пока она не пройдет повторную проверку.
Q: Является ли успешное испытание измененного кабельного прохода или дверного уплотнителя подтверждением работоспособности окружающей системы локализации?
A: Он подтверждает результаты испытаний на герметичность, уплотнение и любые другие фактически проверенные функции, такие как срабатывание сигнализации, блокировки или соотношение давлений. Его не следует рассматривать в качестве доказательства приемлемости для смежных незатронутых зон или в качестве подтверждения общего предела герметичности помещения.
Q: В каких случаях следует расширить объем повторной проверки в ходе приемных работ?
A: Расширяйте его в случае, если отклонение, ремонт, изменение интерфейса или изменение состояния технического обслуживания или восстановления после дезактивации приводят к тому, что исходные доказательства становятся недостоверными для другой функции. Зарегистрируйте событие, определите новую затронутую границу и свяжите полученные в результате повторной проверки доказательства с окончательной протестированной конфигурацией.
Q: Как покупатель может сравнить предложенные планы приемки работ по модернизации?
A: Убедитесь, что в каждом плане каждый нарушенный интерфейс соотносится с функцией и доказательствами, которые будут проверены, объясняется, как будет проводиться проверка существующих записей на предмет их дальнейшей применимости, а также определяется порядок действий в случае отклонений или исправлений. В пакете выпуска также должны быть отдельно указаны вновь протестированные изменения, сохраненные исходные доказательства, устраненные исключения и системы, которые не подвергались повторному тестированию.
