Kurgan-Telecom Ru | Информационные технологии

После проведения HAZOP и формирования контуров безопасности ПСБ с определением целевого уровня полноты безопасности, нам, как инженерам реализующим систему безопасности прислали исходные данные: технологическая схема с КИП, перечень контуров безопасности, матрица причинно-следственных связей, значение целевого УПБ. Мы, как подготовленные инженеры, понимаем из чего могут быть построены контура безопасности, отвечающие заданному целевому УПБ. Осталось подобрать оборудование, собрать контура,  посчитать результирующее значение УПБ и сравнить его с целевым.

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

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

Весь перечень контуров безопасности сразу делим на две части: контура с целевым УПБ1 и ниже, и контура с целевым УПБ2,3. При объективно проведенном анализе рисков контуров УПБ3 будет очень ограниченное количество, обычно несколько единиц. Подобрать оборудование для обеспечения УПБ3 контура в целом достаточно сложно.

тут 30 станиц текста с формулами и графика

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

Можно выделить следующие слои безопасности:

- совершенствование технологического процесса с целью исключения опасных факторов – уменьшить давление в системе, снизить объем опасных веществ, изменить технологическую схему, уменьшить количество оборудования…;

- ОСУП (организация системы управления процессом) – контроль состояния оборудования, контроль за технологическим процессом, уменьшить количество персонала в потенциально опасной зоне, построить эффективную систему обучения и инструктажей …;

- система сигнализации о приближении к опасным границам и квалификация операторов – наладить полноценную систему сигнализации, выделить сигнализации приоритета 1, которые требуют незамедлительных действий от операторов, постоянно и квалифицированно вести анализ срабатывания сигнализации, максимально исключить ложные срабатывания, наладить систему постоянных тренингов для поддержания необходимой квалификации операторов (в правильно построенной системе, сигнализации уровня 1 срабатывают крайне редко при реальной угрозе аварии, количество параметров для крупного объекта не превышает 10-50, каждое ложное срабатывание детально исследуется, программа подготовки и квалификация операторов должны обеспечивать корректные действия персонала при срабатывании сигнализации). В правильно построенной системе, сигнализации должны быть разделены на аварийные и информационные, с разной схемой визуализации и разными журналами, но на практике все сигнализации собирают в один перечень, называют «Перечень сигнализаций и ПАЗ», и в системе управления нет разницы между сигнализацией о перегреве реактора и сигнализацией о низкой температуре теплофикационной воды в операторной. В результате в общий журнал сигнализаций каждый день пишется по 1000 записей, 999 из которых не имеют какого-то смысла.

Читать далее

В данной статье на примерах попробуем разобрать порядок построения системы безопасности технологического процесса на основе анализ рисков. Поскольку цель статьи постараться объяснить «нормальным инженерных языком» назначение и порядок создания системы безопасности технологических объектов на основе анализа рисков, придерживаться «процедур в соответствии с ГОСТ-МЭК..» и описывать процедуры я не буду.

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

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

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

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

- если технологическими и организационными решениями снизить риск до приемлемого не удается, переходим к созданию приборной системы безопасности (ПСБ), определяем контура безопасности, оцениваем требуемый уровень полноты безопасности (SIL) контуров, строим систему аварийного останова (ESD);

Читать далее

Различие в подходах: нормы или анализ рисков.

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

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

В бывшем СССР сложилась система норм и правил, которые жестко регламентировали требования, как организационные, так и технические. Эта система была унаследована и РФ. Достаточно посмотреть «Общие правила взрывобезопасности для взрывопожароопасных химических, нефтехимических и нефтеперерабатывающих производств» утверждены приказом Федеральной службы по экологическому, технологическому и атомному надзору от 15 декабря 2020 года № 533. Документ содержит 70 страниц ценных указаний. И таких «нормативных документов» у нас бесконечное количество, при желании можно найти «нормативку» на все случаи жизни. Соответственно проектировщику не надо понимать процесс, детально знать все особенности технологии, иметь опыт эксплуатации, достаточно просто найти нужную «нормативку» и выполнить все требования. Эксперт при проведении экспертизы проектной документации также проверяет технические решения на соответствие «нормативке», и инспектор Ростехнадзора тоже будет проверять объект на соответствие этой же «нормативке». При этом никого не волнует, на сколько обеспечена реальная безопасность технологического процесса (технологической установки), эффективность и достаточность принятых решений, возможность устойчивой работы оборудования и т.д. Соответствие нормам снимает ответственность за конечный результат со всех – проектировщиков, экспертов, инспекторов, и перекладывает всю ответственность на эксплуатацию, людей, которые непосредственно работают на технологической установке и реально рискуют своей жизнью.

действительно интересно?

Что такое безопасность технологического процесса или технической системы (устройства), что такое риск и вообще зачем все это?

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

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

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

для тех, кому это интересно

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

Для работы с данными внутри Kafka есть Kafka Streams — библиотека, которая помогает строить потоковые приложения. С ее помощью можно обрабатывать события в реальном времени, например, выполнять ETL-процессы без использования внешних систем.

В статье рассказываем, как устроен Kafka Streams, и разбираем практические примеры его применения. 

Читать далее

Собеседование по проектированию систем — одно из самых сложных испытаний для IT-специалиста. Здесь нет единственно верных ответов, зато есть десятки подводных камней: масштабируемость, отказоустойчивость, компромиссы между скоростью и надежностью. А если речь идет о машинном обучении, сложность возрастает в разы.

Как подготовиться? Изучать реальные кейсы, разбирать популярные вопросы и тренироваться мыслить как архитектор сложных систем. В этом помогут три книги, которые мы собрали в этой подборке! Читать дальше →

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

Читать далее

«Зачем вообще писать программу, меняющую код в процессе выполнения? Это же ужасная идея!»

Да, всё так и есть. Но это и хороший опыт. Такое делают только тогда, когда хотят что-то исследовать, или из любопытства.

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

Предупреждение: в этом посте активно используется язык ассемблера x86_64, в котором я ни в коем случае не являюсь специалистом. Для написания статьи мне пришлось изучать приличный объём материалов, и, возможно (почти наверняка), в ней есть ошибки. Читать дальше →

Привет! Меня зовут Абакар, я работаю главным техническим лидером разработки в Альфа-Банке.

Сегодня мы поговорим на тему, связанную с корутинами, а именно погрузимся чуть глубже в недра компилятора Kotlin. На данную тему мы с Александром Гиревым готовили доклад на «Мобиус».

В рамках подготовки доклада нам пришлось заглянуть в святая святых для всех «андроидеров», а именно в исходники компилятора Kotlin. Ну что ж, поглядим, что мы там накопали. Поехали!

Читать далее

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

Макс Тегмарк предложил использовать механистический подход к интерпретируемости, но применять его не к алгоритмам внутри LLM, а к самим знаниям. То есть попробовать выяснить, есть ли внутри моделей какая-то закономерность запоминания или даже понимания. Сразу спойлер (а на самом деле — название статьи) — модели умны от “голода”, это  “intelligence from starvation”. Причем это общий вывод для разных моделей.

Читать далее

Эксперт отдела перспективных исследований компании «Криптонит» Никита Габдуллин предложил методику, которая поможет снизить частоту ошибок ИИ при смене данных за счёт более точного прогнозирования поведения нейросетей.

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

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

Другой показательный пример — история пользователя Reddit, который следовал рекомендациям ИИ от Google и попытался приготовить оливковое масло с чесноком. Казалось бы, ну какие тут могут быть последствия, кроме невкусного блюда? Однако ИИ предложил метод, который привёл к образованию культуры Clostridium botulinum — возбудителя ботулизма, опасного для жизни заболевания. Такие истории предостерегают от слепого доверия к ИИ даже в бытовых задачах.

Читать далее

Большие языковые модели (LLM) звучат впечатляюще, но всегда ли нужно их использовать? Разберемся, в каких случаях стоит использовать LLM, а когда использование малых языковых моделей (SLM) окажется более разумным и экономичным решением без потери качества.

Читать далее

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

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

Читать далее

Microsoft удивила ИТ-сообщество, возродив текстовый редактор Edit — впервые он появился в MS-DOS 5.0 в 1991 году. Edit предлагает простоту, открытый исходный код и возможности, сравнимые с Linux-редакторами вроде vim. Давайте разбираться, что такое Edit, зачем Microsoft его вернула и почему он может стать находкой для разработчиков.

Читать далее

ERC-2981 стал важным шагом к тому, чтобы NFT-авторы действительно получали справедливые роялти с перепродаж. Но работает ли это в реальности? В статье разбираемся, как устроен этот стандарт, какие задачи он решает, как его поддерживают маркетплейсы — и почему даже с его появлением вопрос с роялти остаётся открытым.

Читать далее

Всем привет! Меня зовут Дмитрий, и я занимаюсь веб-разработкой в IT-компании Intelsy, работая как на аутсорс-, так и на аутстафф-проектах. В своей работе я постоянно сталкиваюсь с задачами, связанными с датами и временем, и давно заметил, что стандартный объект Date в JavaScript часто доставляет много неудобств.

Мне захотелось разобраться, почему так происходит и какие современные решения помогают упростить эту работу. Это привело меня к изучению нового API Temporal — перспективного инструмента для более точной и удобной работы с датой, временем и часовыми поясами.

Читать далее

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

Всем привет! Меня зовут Лев, я специалист продуктовой поддержки в Selectel. Под катом расскажу, как проводят ремонт подводных оптических кабелей: кто этим занимается, как ищут обрыв на километровой глубине и каким образом восстанавливают оптическое волокно посреди моря. Читать дальше →

Привет, меня зовут Вадим Медяник, я технический директор ИТ-компании BPA. Я регулярно участвую в реализации проектов, где используется машинное обучение и компьютерное зрение — от первых обсуждений с заказчиком до вывода решения в прод. Со временем накопилось достаточно практики, чтобы выделить повторяющиеся этапы, типичные ошибки и решения, которые реально работают.

Это практическое руководство собрал для коллег и команд, кто работает с подобными проектами — или только планирует. Здесь нет задач про state-of-the-art или подбор идеальных архитектур. Скорее хочу пройтись по каждому этапу — с чего начать, о чём спросить бизнес, где обычно «сыпется» проект, и что помогает пройти до конца. Рассчитано на тех, кто хочет разобраться в базовой структуре CV/ML-проекта, будь то инженер, аналитик или управленец. Если понадобится — можно будет углубиться в технические детали отдельно. Для удобства разделил весь путь подготовки CV-проекта на несколько основных этапов.

Читать далее

С вами снова Кирилл Богатов, дизайнер разговорных продуктов в KODE. В прошлом году я записался на курсы по театральной импровизации. Там мы разыгрывали сценки, работали с зажимами и учились не бояться выглядеть нелепо. Наши занятия часто заканчивались игрой в «Принцессу, Дракона, Рыцаря» — это как «камень-ножницы-бумага», только вместо фигур в ней нужно изображать фэнтезийных персонажей. Своего рода мини-спектакль на пару секунд.

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

Читать далее