Перечень компьютеризированных систем

Между первым и нынешним постом миновал почти год. Помимо традиционной нехватки времени на анонсированный ранее перечень КС (компьютеризированных систем), я получил ещё и новую информацию, главным образом на форуме ISPE GAMP CoP (Community of Practice). Я помимо пассивного сканирования данного ресурса таки решился прямо поставить там вопрос о том, какая категория согласно приложения М4 GAMP5 может быть присвоена для подавляющего большинства промышленных КС, которые “инервируют” технологическое оборудование – 90 % КС от общего количество на среднестатистической фирме. По той простой причине, что групповая упаковка с её PLC и HMI – это отдельная КС. Система управления реакторами приготовления, система управления воздухотехникой для чистых помещений (PLC, HMI, SCADA) – тоже отдельные КС. Могу сказать, что в какой-то мере мое сообщение на форуме в соотв. ветке было не то, чтобы полностью ошибочным, но немного поспешным и неполным. В чём вопрос.
Начну с ответов зарубежных коллег. Первый ответ был безаппеляционным – софт для PLC – это либо категория 4 (конфигурируемое ПО), либо категория 5 (индивидуальный код). По моим уточнениям у группы авторов (англичане, немцы преимущественно) было дано следующее разъяснение. Да, мол, могут простые встроенные PLC (simple ’embedded’ PLC systems – кстати, мне интересно, какие могут быть примеры таких простых встроенных PLC?) могут относится к категории 3 (не конфигурируемое ПО), однако в большинстве случаев все же даже при сомнении – категория 3 это или 4 – следует делать выбор в пользу более высокой, оговаривая, что есть элементы и 3-й и 4-й категорий. Но, как оказалось, не это важно.
По словам зарубежных коллег, сами по себе категории не стоит воспринимать, как догму и не только и не столько сами по себе категории ПО определяют валидационный подход. На более ранних этапах развития GAMP был условно такой подход:

Категория 1 – делай это
Категория 2 – делай то (не используется более, конечно)
Категория 3 – делай также это
Категория 4 – делай вдобавок ещё и вот то
Категория 5 – выполни это, то, также то и в довершение ещё что-то

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

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

В дополнение уже немецкий коллега дописал следующее:

категория 3 – это редакторы, IDE etc. Это означает, что, например в случае Siemens 3-й категорией является среда разработки Step 7, WinCC Flexible – вот их версию и нужно записать – это по сути COTS (Commercial-of-the-Shelf) ПО.
категория 4 – элементы библиотек из коммерчески доступных / валидированных библиотек, если они только конфигурируются, CFC – тут мне труднее прокомментировать, т.к. я не специалист в этой предметной области. Единственное, что могу только догадываться, что аббревиатура CFC – это, очевидно, ColdFusion Components – вот тут я рассчитываю на помощь посетителей форума – IT-специалистов, а “языка” я “взял” 🙂
категория 5 – если индивидуальный код (bespoke code) – то это однозначно. Или изменение существующих функциональных блоков.

И завершающая фраза от немецкого коллеги, чью трактовку я тоже рассчитываю получить на форуме. Для систем SCADA и DCS вендор поставляет (должен поставлять?) GMP Engineering Manuals, in which they also describe PTC regarding software categorization and test methodology. Т.е., в этих руководствах поставщик описывает PTC (что это есть? Не CAD-контора? Если да, то причем тут она?) относительно категоризации ПО и тестовой методологии.

В ближайшие полгода я смогу очно побеседовать с немцами по части этих самых GMP Engineering Manuals и по части GAMP5 в целом.

Резюмируя, могу предложить следующий шаблон обобщенного перечня КС:


А теперь почему я вцепился в этот самый перечень? Помимо абстрактного, но вполне резонного и логично желания “осмотреться в отсеках” и просто понять объем и фокус работ? Читаем Приложение 11 GMP, п. 4.3: “Должен быть актуализированный перечень (реестр) всех систем, которые имеют отношение к делу и их функциональности с точки зрения GMP.
Для критических систем должно быть в наличии актуализированное описание с детальными данными про физическое и логическое устройство, передачу данных и подключение к другим системам или процессам, любые ограничения (предварительные требования) и мероприятия по защите.

Подписывайтесь на каналы PHARM COMMUNITY:

   
Поделитесь с коллегами:

7 коментарів до “Перечень компьютеризированных систем”

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

    • Сообщение давнее, тем не менее, отвечу – нежелающие заниматься “подобной фигнёй” главным образом при проектировании новых систем теряют деньги 🙂 Кривоработающие приложения уровня ERP – это только постоянный затык, а не оптимизация работы.

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

      А при компьютеризированных системах часто почему-то считается, мол, “да нам это студент напишет и/или сконфигурирует”, а “технические требования к системе по скайпу напишем” 🙂 Или, обратный полярный пример – работает серьёзный интегратор, осваиваются солидные бюджеты, а получаются на выходе кривые продукты, позволяющие, как это часто бывает, отгрузить сырье или продукцию в статусе карантин. Потому что интегратор/разработчик с точки зрения ИТ всё сделал неплохо, система работает устойчиво, но прежний опыт интегратора/разработчика в сфере энергетики или нефтепереработки малорелевантен для фарма. Это не упрощает работу, а наоборот вносит путаницу. Часто такие “поделки” потом проще снести, чем довести до ума. Ещё чаще выбрано “типа стандартное решение”, а не информатизирован реальный бизнес-процесс предприятия (мы выполнеяем процедуру так не потому, что нам так надо, а потому, что используется стандартный функционал продукта).

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

  2. CFC в данном случае скорее всего библиотека функциональных блоков Continuous Function Chart. Блоки используются для графического программирования(проектирования) систем управления.

  3. Спасибо автору, не боящемуся выкладывать свой личный опыт.

    Для меня эта тема все больше подходит под определение: “как вы это себе определите, так и будет”. Хорошо будет иметь тот или иной подход, потому что мы (команда квалифицированных специалистов) так считаем (и это мы где-то подробно письменно обосновали).

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

    • Microb, собственно мне вроде как нечего боятся при выкладывании собственного опыта. Тем более, что это делается с целью обмена этим самым опытом. Тем более, что коммерческой тайны этот опыт не содержит (все данные обезличены и соотв. образом изменены) – так, общие рассуждения, призванные вызвать дискуссию профессионалов. Другое дело, что за этот год у меня дискуссии на эту тему главным образом получаются на зарубежных (западных) площадках вроде упомянутого форума ISPE GAMP CoP.

      Вы правы, что у нас (в широком смысле, т.к. примерно представляю себе ситуацию и в Украине и в РФ по данному вопросу) это направление пока в самой зачаточной фазе. А по Приложению 11 нас уже можно экзаменовать в полный рост.

      Вот только два документа, которые об этом говорят подробнее, чем само Приложение 11:

      1. Интерпретация Приложения 11 со стороны ISPE GAMP CoP (есть в бесплатном доступе статья).

      2. Памятка для инспекторов PIC/S (на сайте этой почтенной организации также в бесплатном доступе) – там просто есть варианты опросников при инспекции, помимо прочей и достаточно подробной (порядка 50 стр.) информации.

Залишити коментар