Промышленное программирование, или Пара слов об АСУ ТП



    Есть такая профессия — производство автоматизировать. Аббревиатура АСУ ТП означает «автоматизированная система управления технологическим процессом» — это система, состоящая из персонала и совокупности оборудования с программным обеспечением, использующихся для автоматизации функций этого самого персонала по управлению промышленными объектами: электростанциями, котельными, насосными, водоочистными сооружениями, пищевыми, химическими, металлургическими заводами, нефтегазовыми объектами и т.д. и т.п.

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

    Иногда на эту тему проскакивают статьи и на хабре. Обычно они не пользуются особой популярностью, но всё же я хочу написать несколько обзорных статей об АСУ ТП в надежде рассказать хабравчанам что-то интересное (а возможно, кому-то даже полезное) и привлечь на хабр больше своих коллег.

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

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

    Итак, программно-технический комплекс АСУ ТП делится на три уровня: верхний (компьютеры), средний (контроллеры), нижний (полевое оборудование, датчики, исполнительные механизмы). Про нижний уровень рассказывать не буду — слишком уж это далеко от от тематики хабра, да и статья получится слишком большая.

    Верхний уровень


    Верхний уровень — это серверы и пользовательские ПК (у нас они называются АРМ — автоматизированное рабочее место). Сюда выводится состояние технологического процесса, и отсюда при необходимости оператором подаются команды на изменение его параметров. Для упрощения разработки создано большое количество SCADA-систем (от англ. supervisory control and data acquisition — диспетчерское управление и сбор данных). Это в некотором роде расширенный аналог IDE, в котором скомпилированная «программа» и выполняется.

    Системы SCADA

    Вообще, если отбросить академизм, то на предприятии для всех кроме асушников скада выглядит вот так:
    image from wikipedia

    А если совсем не повезёт, то вот так:
    image from The High Perfomance HMI Handbook

    Скады неявно можно разделить на серверную и клиентскую части. Опрос полевых устройств и сбор данных производится сервером (обычно, через ПЛК), с сервера клиенты забирают эти данные к себе на монитор. Сами по себе понятия «серверная» и «клиентская» части условны. Фактически разделение производится по лицензиям на компоненты скады, а политика лицензирования у каждого производителя своя. Вплоть до разделения на: количество обрабатываемых сигналов с поля, драйвера протоколов, количество рабочих станций, возможность создания веб-интерфейса, мобильного интерфейса, да и вообще целые куски функционала могут быть за отдельные денжеки. Чаще проще обратиться к поставщику, предоставив исходные данные по проекту, чтобы помогли с подбором лицензий.

    Подразумеваются два режима функционирования: режим разработки и режим выполнения (runtime). Не обязательно эти режимы взаимоисключающи: можно редактировать проект на одном АРМе, инженерном, заливать его, он обновится на пользовательских. Это очень важно — изменять проект без простоев и отключений, потому что технологический процесс прерывать нельзя, и операторы всегда должны иметь возможность его контролировать. В скаде создаются графические интерфейсы, настраиваются источники данных с полевых устройств, она отвечает за взаимодействие пользователя (оператора, диспетчера, технолога) с происходящим на производстве, а также за архивирование всех нужных данных в БД.

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

    Периодически скада складывает все собранные данные в БД. Их потом можно посмотреть в виде графиков (называем их трендами), а при необходимости, если оговорено в ТЗ на АСУТП, реализуется выгрузка в виде отчётов в эксель или ещё как-нибудь. Архивация сделана по-разному: в MS SQL; MS Access; в ту же MS SQL, но по своему хитрому алгоритму с дополнительной архивацией; а у кого-то вообще в свою собственную бинарную БД.

    Особым пунктом в скадах идёт информирование оператора: текущие сообщения и аварийные. Они тоже обязательно архивируются. В общем виде сообщения делятся на текущие и важные (аварийные). Текущие прячут подальше, но журнал аварийных всегда выводится на экране оператора. К текстовым аварийным сообщениям привязываются звуковые, чтобы кто-нибудь не проспал ЧП :-)

    Рынок SCADA

    Самыми распространёнными, по-моему, считаются скады производства Invensys Wonderware, Iconics, Siemens, Indusoft, AdAstra, Emerson, Rockwell Automation.

    Я лично работал с виндовыми: Invensys Wonderware InTouch и более мощной System Platform, с Iconics Genesis32 — и с (пока ещё?) малоизвестной B&R APROL под SLES (формально, это не совсем скада, а покруче — из-под апрола программируются и сами контроллеры).

    По поисковым запросам, например, SCADA, HMI можно посмотреть примеры интерфейсов и мнемосхем.

    Внешний вид и юзабилити по приоритету, увы, находятся на последнем месте. Причём, это касается не только рантайма, но и разработки. Для разработки в каждой скаде существуют как минимум дефолтные библиотеки символов — от кнопок и прочих контролов до графических изображений насосов, труб, задвижек, ёмкостей. Здесь-то и могли бы умные разработчики SCADA-пакетов (не путать с нами, асушниками — разработчиками проектов в этих пакетах) добиться принципиального преимущества над конкурентами, сделав продуманные библиотеки, из которых бы даже самый далёкий от дизайна и юзабилити инженер при всём нежелании делал бы гуманные интерфейсы и мнемосхемы. К сожалению, сейчас эта сфера идёт по пути экстенсивного развития, по которому развивалась IT до недавнего времени — наращивание функционала, добавление плюшек, больше, выше, сильнее, harder, better, stronger, и о пользователях пока думают мало.

    Средний уровень


    Средний уровень — ПЛК, программируемые логические контроллеры. Здесь всё достаточно просто, чаще всего физически ПЛК состоят из отдельных модулей. Для программирования у каждого ПЛК есть своя среда разработки, иногда она объединена со средой для создания SCADA.

    Состав ПЛК

    Модули бывают такие:
    • блок питания;
    • процессорный;
    • дискретных входов;
    • дискретных выходов;
    • аналоговых входов;
    • аналоговых выходов;
    • температурных входов;
    • интерфейсные/коммуникационные.



    Контроллер B&R серии X20

    Зачем нужен блок питания — понятно. БП сделан отдельным именно модулем, а не устройством, чтобы гарантировать совместимость с данной линейкой ПЛК. Чаще всего входное напряжение у БП 220 В переменного тока, выходное — 24 В постоянного тока.

    Процессорный модуль — это голова ПЛК. Внутри у него, само собой, ЦПУ, ОЗУ и ПЗУ, сервисный порт для прошивки и, возможно, коммуникационный порт (ethernet, RS232/422/485, Profibus, etc). Иногда коммуникационный порт используется и как сервисный. Иногда на модуле есть переключатель (у Allen Bradley ещё круче — там натуральный ключ с замочной скважиной) для перевода ПЛК в различные режимы работы. Отдельной кнопки включения/выключения нет, в лучшем случае — тот переключатель, иначе, если есть питание — ПЛК запускается, а выключается и перезагружается «по-варварски» отключением питания.

    image
    Контроллер Allen Bradley серии CompactLogix

    Дискретные и аналоговые модули обрабатывают соответствующие сигналы. Входные модули принимают эти сигналы с поля, выходные — формируют их.

    Дискретный сигнал — это обычно напряжение цепи 24 вольта. Есть 24 — это «1», нет — «0». Бывают модули на 220В, есть модули с проверкой целостности цепи. Дискретные сигналы, приходящие с поля, могут информировать, например, о состоянии насоса включен/выключен. Управляющие дискретные сигналы могут запускать либо останавливать этот насос. Оптимизация здесь не оправдана, поэтому на запуск будет отдельная цепь, на останов — отдельная.

    Модули I/O одного типа могут быть объединены: например, один модуль с 16 дискретными входами и 16 дискретными выходами.

    Аналоговые входные сигналы — это приходят показания с датчиков. Здесь чаще всего используется токовая петля 4-20 мА, в соотетствие которой ставятся пределы измерения датчика. Начинается от 4 мА для диагностирования обрыва цепи (если меньше 4 мА, значит где-то что-то не в порядке с проводкой).

    Рассмотрим на примере уровня жидкости в резервуаре. Стоит уровнемер, он измеряет уровень от 0 до 2 метров. Тогда: уровень 0 метров — это 4 мА, уровень 2 метра — это 20 мА. Промежуточные значения калибруются по ситуации, не всегда 1 метр соответствует 4+(20-4)/2=12 мА, может быть небольшая погрешность, уровень в 1 метр может быть какие-нибудь 12,7553 мА.

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

    Температурные модули замеряют сопротивление в цепи либо термо-ЭДС. Если на них подключаются термометры сопротивления — при нагревании металла его сопротивление, по законам физики, повышается, соответственно определяется температура. Если подключается термопара (два спаянных проводника из разных металлов, при нагревании стыка возникает разность потенциалов между другими концами), замеряется напряжение.

    Интерфейсные (или коммуникационные) модули предоставляют нам порты под RJ45, DB9, DB15, просто клеммники или что ещё бог производителю на душу положит. Помимо реализации непосредственно интерфейса (физического разъёма под коннектор, физического уровня модели OSI) они также реализуют протокол обмена через этот разъём.

    Протоколы и интерфейсы

    Протоколов напридумывали и используют кучу: ModBus (RTU, TCP, ASCII), Profibus, Profinet, CAN, HART, DF1, DH485 и т.д. Некоторые особо хитрые производители реализуют свои протоколы поверх общепринятых.

    Я достаточно тесно знаком с интерфейсами RS232/485 и протоколами Modbus. RS232 это всем знакомый COM-порт, с тремя основными линиями: Tx (transmit, передача), Rx (recieve, получение) и GND (ground, земля). RS485 это асинхронный полудуплексный последовательный интерфейс по 2 проводам (совмещённые Tx/Rx+ и Tx/Rx-) или 4 проводам (отдельно Tx+, Tx-, Rx+, Rx-) с разностью потенциалов на каждой паре от 2 до 10 вольт.

    А модбас это в общем-то нехитрая штука, с проверкой целостности пакета по чексумме, подтверждением доставки и корректности запроса — или ответом, почему запрос неверен. В сети модбас есть два вида устройств: master — инициирует обмен; slave — выполняет запросы мастера. Пакет от мастера расходится ко всем слейвам, которые сравнивают адрес назначения со своим, если сходится, то смотрят следующие два байта — это команда работы с регистрами памяти — чтение/запись (за исключением нескольких редко используемых служебных команд), потом байты адреса и непосредственно данных, в конце чексумма. Достаточно подробно и понятно расписано на википедии.

    Программная начинка

    Первое, что нужно сказать, программа в ПЛК выполняется циклически с определённой частотой. Возможности зависят от контроллера, обычно это где-то 20, 50, 250 мс, 1, 2, 3, 4, 5 с. Естественно, это не гарантирует выполнение кода именно за такой промежуток времени, нельзя большие программы пихать в цикл 20 мс, к началу следующего цикла предыдущий должен быть завершён.

    Второе, это языки программирования. По идее программируются ПЛК на языках, определённых стандартом МЭК61131:

    1. IL (Instruction List) — низкоуровневый ассемблероподобный язык.
      image
    2. LD (Ladder Diagram) — графический язык, представляет собой программную реализацию электрических схем на базе электромагнитных реле. Придумано в лохматые года для тех асушников, которые больше электрики, чем программисты.
      image
      IL и LD легко конвертируются друг в друга, кажется, всеми средами программирования. Они не очень читабельны, и потому неудобны для разработки, но в ситуациях, когда внутренней памяти контролера немного, приходится писать на них.
    3. ST (Structured Text) — текстовый паскалеподобный язык. По-моему, из всех пяти самый удобный.
      image
    4. FBD (Function Block Diagram) — своего рода графический язык, «блоксхемоподобный». Программа составляется из функциональных блоков, которые представляют собой подпрограммы, написанные на каком-либо из языков стандарта МЭК61131. У каждого ФБ есть входы и выходы, которые соединяются со входами и выходами других ФБ. Кому-то, возможно, удобнее делать так, чем писать всё на том же ST.
      image
    5. SFC (Sequential Function Chart) — графический высокоуровневый язык. Создан на базе математического аппарата сетей Петри. Описывает последовательность состояний и условий переходов. Ни разу не встречал и не слышал, чтобы где-то использовался.
      image


    Это «по идее». Но, например, Siemens придерживается своего наименования языков, а у B&R есть возможность писать на ANSI C.

    Самые используемые контроллеры, безоговорочно, у Siemens и Allen Bradley (последним, к слову, принадлежит Rockwell Automation со своей линейкой SCADA-пакетов RSView). За ними по пятам идут Schneider Electric; ОВЕН; General Electric; AutomationDirect; ICP DAS; Advantech; Mitsubishi Electric; B&R.

    Заключение


    Пост не претендует на полное справочное описание всего — очень уж разное оборудование, софт и подходы к ним в целом. Самым формально безошибочным рассказом об АСУТП было бы перечисление соответствующих ФЗ, ГОСТов, техстандартов и регламентов. Все возможные расхождения с этими документами считать опечатками ;-) С радостью принимаются комментарии, поправки и, если интересно, пожелания для следующих статей.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 112

    • UFO just landed and posted this here
        +2
        Плюсую. Именно графические языки в случае с АСУТП являются прекрасной возможностью наиболее наглядно и структурировано изложить даже весьма комплексный алгоритм. Только вот коллеги почему-то придерживались мнения автора поста =(
        А SFC удобен для структурирования наиболее общего видения алгоритма работы сразу нескольких агрегатов.
          +1
          Попробуйте — вам понравится ;]
            +4
            Не знаю, не знаю, может у вас задачи не очень сложные, но попробуйте на LD написать опрос какого нибудь девайса с экзотическим протоколом, и парсинг его пакетов с преобразованием данных между типами… Мне к сожалению приходится писать для PLC и каждый раз когда я сажусь это делать, я вспоминаю производителей не злым тихим словом… Почему бы не реализовать возможность писать на ANSI C… Если я хочу выстрелить себе в ногу, я найду как это делать даже на LD, а вот когда мне нужно сделать какуюто простую вещь по преобразованию типа данны, вместо *(float*) я должен использовать всякую лабуду… Да а на Mitsubishi нет типа данных byte, там чтобы получить доступ к байту не по четному адресу, нужно такой изврат творить… Короче я надеюсь что в ближайшем времени кто нибудь выпустит таки контроллер с возможностью писать под него на С++/C#/Java…
              +1
              www.icp-das.ru/ тебе в помощь.
              Говорят даже симулинк прикрутить можно.
              Только редко в задачах АСУТП требуется «парсить пакеты», да и экзотика появляется только тогда когда ТЗ не проработаны как следует.
                0
                Да запросто. Модбас с регистрами по 32 бита как вам?
                  0
                  Зачем?
                  Может я конечно не догоняю, но у меня есть 3 типа сигналов в АСУТП (верхний уровень не беру) дискретный, аналоговый, цифра с профибас.
                  Что еще надо для счастья?
                  Зачем Модбас? Пусть живет своей жизнью.
                    +1
                    Какой интересный подход. Ну если вам незачем — то как я смею со своими жалкими делишками навязываться))
                      +2
                      Подходы немного разные просто.

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

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

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

                      Хотя 10 лет назад я думал как Вы (к сожалению не знаю Вашего возраста).
                      Но 10 лет работы по 2мпростым правилам:
                      Первое — Если что-то не работает по твоей вине, то это очень плохо.
                      Второе — Так ребята, тут за 7-8 месяцев надо установочку автоматизировать (да,… а физически мы ее соберем через 6-7 месяцев заодно и скажем как она должна работать), наладить, так чтоб работала и план выполняла, не взрывалась, если что не так. Да и смотри п.1.
                      Так вот работа по этим 2м правилам немного поменяла меня. Стал как в армии — все должно быть параллельно и перпендикулярно. Понятно и просто. И не надо ничего ПАРСИТЬ. Если надо что-то на чем-то парсить, то надо это выкинуть и поставить что-то другое. Чтоб просто работало))))

                      А си, парсинг и все остальное это у меня дома на ардуине))))
                        +2
                        В принципе, я согласен, чем проще и прозрачней, тем лучше. Только вопрос «зачем?»… всякое бывает, я ж не с потолка придумал 32битный модбас, а из жизни)

                        Я так понимаю, вы с атомной энергетикой связаны? Напишите пост =)
                          +2
                          С ней, родимой…
                          Если честно, не знаю, чего я завелся… Наверное привычка с работы — надежность, безопасность, ядерная безопасность, радиационная безопасность, не забыть про водород и так по кругу.
                          Параноиком стал. Хотя наверное в моем случае это хорошо.

                          Каждая задача может иметь свое решение. И мое не панацея.

                          Написать времени нет. Правительство рапортует о новых направлениях в энергетике, а мы «отдуваемся». На работе сейчас много новых установок проектируется. Часть сами делаем, часть отдаем на сторону…
                          +1
                          Это хорошо, когда у вас такие заказчики, а когда автоматизируемый объект содержит в себе зоопарк из оборудования различных производителей(ну не производит Siemens одоризационные установки, и никто не сделал таковой на основе контроллеров Siemens). То тут как не крути, надо парсить… Да и система автоматики в нашем случае больше является точкой интеграции информации с различных подсистем, с бонусом в виде управления некоторыми технологическими процессами.
                          Вот выше написали про IcpDAS, хорошие штуки, мы их используем, но к сожалении заказчики не признают их как основные системы управления… Вот в последнее время они и парсят, на C…
                            0
                            Скажу по секрету мы сами себе заказчики))) вот я тут и разошелся))))
                            • UFO just landed and posted this here
                                0
                                А вы вычислители расхода газа пробовали интегрировать в свои системы?
                                • UFO just landed and posted this here
                                    0
                                    Ключевое слово Modbus RTU, и импортные вычилители. На Украине лобируются отечественные вычислители Флоутек, хорошо если удастся договорится отделом метрологии с УкрТрансГаза и протолкнуть проект на ФлоуИнек(ДаниФлоу)… Все о чем вы говорите — неисполнимые мечты. Но даже это не учит отечественных производителей, www.measure.com.ua/page_b25.html отличная железяка для применения в качестве корректора расхода газа на собственные нужды, но протокол у ни опять таки «велосипед»…
                                    • UFO just landed and posted this here
                          +3
                          Не скажите. А если Вам требуется интеграция с оборудованием стороннего производителя? Ну вот не делает производитель вашего ПЛК, скажем, частотные приводы для двигателей, а по ТЗ он нужен. Слава богам, если привод будет поддерживать какой-либо стандартный протокол обмена, хотя бы и ModBUS.
                          А еще бывает такое: «система должна интегрироваться с существующим оборудованием». А под этим термином подразумевается, скажем (пример из личной практики) чудо-теплосчетчик отечественной разработки со своим, совершенно подкуренным протоколом обмена, да еще и не совсем соблюдающий спецификацию EIA-232. Вот тут становится реально дурно.
                            0
                            Да да:) У нас такие вычислители расхода газа, тоже чудо отечественного приборостроения:) Которые на пине RS-232 Tx выставляют активный уровень только в момент передачи, после того как воспринял запрос как к себе, а так висит этот Tx в третьем состоянии, хотя по стандарту в состоянии MARK там должно быть -12, и клемнички не подписаны… Вот и гадай толи Rx/Tx попутал, толи CRC не так посчитал в запросе, тиоли адрес не тот…
                              0
                              Раскопка схемы того прибора, о котором я писал, показала:
                              Линии GND и Rx порта на компьютере должны подключаться к -Tx и +Tx прибора.
                              Линии Tx и DTR должны быть воткнуты в -Rx и +Rx прибора, причем на DTR должна быть лог. 1.
                              Проще говоря, производитель сделал из 232 этакий недоделаный 485, причем с жесткой привязкой именно к уровням сигналов на COM-порту компьютера (3..15В уровень? Не, не слышал).
                                0
                                На 422 чуть чуть похож…
                                  0
                                  Ну многие производители именуют 422-й как «485 full duplex», так что я его в виду и имел. Но все равно бред же :)
                                  • UFO just landed and posted this here
                                      0
                                      Упоротости везде хватает, когда приходится сопрягаться с «существующим оборудованием» или другую часть системы делает другой подрядчик :(
                              +1
                              Я же сказал, что мы немного «избалованы», да и руководство понимает, что проще выкинуть неугодный привод и купить новый, пусть он и лимон стоит, но чтоб работало без выкрутасов.
                              Мы (наш участок) большую часть времени поддерживаем работоспособность существующего АСУТП, чем создаем новое. Хотя даже если задача по автоматизации заказана «на стороне», то контролируем мы каждый шаг.

                              Когда предприятие работает круглогодично, то вылезают неприятные моменты, такие как переполнения буфера, или память выделяется но не высвобождается.
                              И если ошибка возникает раз в 3-4 месяца, то отловить ее непросто.
                              Как правило у нас все «нестандартное» переделывается на «стандартное» со временем.

                              Тут наверное задачи разные.
                              Многие, кто на сайте подстраиваются под заказчика, который хочет быстрее и дешевле…
                              А у меня задача такая — работа с ураном ошибок не прощает…
                                +1
                                Вне всякого сомнения, в Вашей работе цена ошибки на порядки выше. Отвал вентиляции торгового центра на полчаса, час — это не смертельно, система очень инерционна, большинство посетителей этого даже не заметят. а вот в то же время, на полное разрушение реактора, как показал 86-й год, хватает минуты.
                                  0
                                  Я не реактора обслуживаю. Там такие параноики, что мне до них далеко. Там вообще все свое — свои контроллеры со стократным резервированием, своя ОС на базе Linux, СКАДА своя, и все это, как иногда пишется в интернете, не пострадало при атаке вируса CTUXNET на Иран. Атомная станция в Бушере не была затронута. Только обогатительное предприятие, которое, кстати было на SIEMENS.
                                  У нас просто переработка урана. Так что у нас попроще немного, но все равно надо быть на чеку.
                            0
                            Странная вещь, тем более, что существуют регистры 5x, которые обычно проецируются на ту же область 4x. Если это не оно, то это велосипед, а если оно — то ModBUS 0x03 Read holding register никто не отменял, и сложить из двух word'ов один dword не есть проблема.
                              0
                              Согласитесь, на С этот трюк получится ловчее, чем на ладдах.
                                0
                                Согласен. Вроде как весьма мною любимые немцы из Beckhoff таки сделали в своем TwinCAT 3 поддержку С / С++ для ПЛК, но лично пока не пробовал. По впечатлениям других людей, продукт пока что сыроват.
                                  0
                                  Какая проблема на ладдере сделать шифт?
                              0
                              Регулярно приходится. Многие производители не считают должным придерживаться общепринятых протоколов обмена, либо же протокол-то в их круге общепринятый, но ваш ПЛК его не знает. Как быть? Только писать свою реализацию, т.е. парсить пакеты руками. Как пример: для снятия показаний со счетчиков электроэнергии применяется протокол согласно ГОСТ 61107-2001. Есть хоть один ПЛК с его нативной поддержкой? А вот мне, поскольку работаю я в области автоматизации зданий, он нужен.
                              0
                              но попробуйте на LD написать опрос какого нибудь девайса

                              он попробует и будет лестница… в небо

                              типа такого
                              image


                              Короче я надеюсь что в ближайшем времени кто нибудь выпустит таки контроллер

                              попробуйте B&R там есть си, стреляйте на здоровье…
                                0
                                Сименс вполне позволяет прострелить себе ногу в скольки угодно местах и на ладдере, и на SCL, а уж на STL сам Б-г велел :)
                              +1
                              Мы используем ТОЛЬКО LD и FBD.
                              Соглашусь, что «писать программы» на них не удобно, но описать почти любой техпроцесс почти элементарно.
                              Зато когда на работающем оборудовании возникает проблема, то, подключившись программатором, и посмотрев состояние переменных в онлайн можно достаточно легко и быстро диагностировать неисправность.
                              1. Например не открылся клапан (нет единички с контроллера).
                              2. Смотришь по схеме с какого выхода контроллера идет дискретный сигнал.
                              3. Смотришь по адресу, где в программе этот битек устанавливается.
                              4. Смотришь в программе какие условия не соблюдены.
                              5. Все. Проблема найдена. Осталось ее решить.

                              А когда у тебя установка на 1500 входов-выходов, и не дай бог, что-то пошло не так, то рыться в сишном/паскальном/ассемблерном коде и искать ошибку я врагу не пожелаю.

                                0
                                Вопрос грамотной структуризации кода, я считаю. Про повышение читаемости кода на си/паскале написаны километры статей, и многое из них к тому же ST вполне применимо.
                                  0
                                  А лучший вариант — это комбинация LAD/FBD (ещё лучше, если CFC — это такой продвинутый FBD) с STL/SCL.
                                  Блоки типа мотора, клапана и прочее пишутся на STL/SCL, многократно проверены и отлажены и прекрасно вставляются в ладдер.
                                0
                                SFC… Ни разу не встречал и не слышал, чтобы где-то использовался.


                                Просто повезло наверное. Энергетики в прошлом году «обрадовали», что все программы должны быть именно на нем. Но нас сия участь обошла вместе с контрактом.
                                  +1
                                  SFC используется, в частности в Сургутнефтегазе. Но там своя разработка (ОКО) и своя реализация интерпритатора SFC.
                                  Кстати, действительно удобная штука, главное технологам объяснить как она работает.
                                  +3
                                  Как жаль, что аудитория АСУ ТП на хабре так мала, и дело доходит только до обзорных статей…
                                  • UFO just landed and posted this here
                                      +1
                                      Если есть «открытые» (aka open source) и достаточно дешевые реализации, то о них было бы интересно почитать.
                                      А то Simatic Step 7 и Delta V, распространенные, по крайней мере у нас, нагоняют грусть-тоску одними лицензиями на потенциальных заказчиков, не говоря о цене разработки и наладочных работ, там, как правило, звучит ответ: когда-нибудь потом (никогда).
                                      А ведь АСУТП это ведь не только для больших дядей с многомиллионными ежемесячными оборотами, которых по пальцам можно пересчитать?
                                        0
                                        Достаточно дешевые это типа китайских ICP DAC. Программируются на С и даже на Визуал Бейсике :), т.к. внутри может быть ВинСЕ или Линукс — открытее некуда. Сам не работал, но на профильных форумах пишут, что железяки глючные, поэтому использовать не рискуем.
                                          0
                                          Не стоит на ICP DAS наговаривать. Как и любое сложное оборудование не без особенностей, но годное для применения, кроме того отлично работает без всякого подогрева в шкафах (до -30 точно).
                                          А возможность запрогать контроллер из-под VisualStudio после всяких Ultralogik'ов, TraceMod и WinCC, просто кайф.
                                          Я последнее время я вообще от общепромышленных SCADA отказался — написал свои библиотеки для низа и для верха. Заказчики безумно довольны, т.к. стоимость владения системой и создания новых рабочих мест по сравнению с покупкой лицензий получается вообще копеечная, по NDA все необходимые исходники передаются им, так в случае чего они смогут решить и проблемы с поддержкой системы.

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

                                          Но конечно масштаб систем у меня не очень большой. Самые крупный — комбикормовый завод. Прекрасно понимаю, что для нефти и газа мой подход не подойдёт в том числе и по формальным причинам.
                                            0
                                            Все мечтаю ICP DAS на деле попробовать, только заказчиков подходящих не нашлось. С экономным заказчиком связываться себе дороже обычно выходит. Экономишь на скаде — бесплатная оказывается глючной, экономишь на железе — дешевое и отечественное тоже начинает глючить. А с дорогим оборудованием большая часть проблем случается из-за ошибок проектирования/программирования.
                                              +1
                                              Есть опыт эксплуатации их преобразователей и хабов RS485 типа 7520, 7513. Очень все положительно, за 5 лет из двух десятков умер один, причем это было вызвано попаданием 220В на питание. ПЛК не щупал, к сожалению.
                                                0
                                                Экономия а железе выливается в увеличение геморроя при разработке, что съедает всю экономию разово, и на поддержке и сопровождении (уже регулярный минус).
                                                +1
                                                У нас сыпятся ICP DAS в тяжелых условиях (есть небольшие пары кислоты) иногда подвисают, хотя всего линеек 10-15 стоит.

                                                А из опыта десяти лет эксплуатации SIEMENS (S7-200, 300, 400, и даже 488 есть 2 шт) а это порядка 2000 модулей (процессорные, входа-выхода) вышло из строя всего 3 модуля. Первый это ET-200 модуль, и 2 аналоговых входа (сожгли сами, не так включили).

                                                В общем с учетом того, что у нас остановка оборудования тянет за собой расходов на переработку брака лимона на 2-3 сразу. SIEMENS окупился уже сто раз.

                                                А ICP DAS будем менять скоро на SIMATIC.
                                          +3
                                          Ну почему же, были хорошие статьи по теме и немало. Сходу: серия "Как я скаду писал", про информационную безопасность как надо и как не надо и про функциональную безопасность как есть.

                                          Жаль, хаба под это дело нет.
                                            +1
                                            Вот еще хорошие две свежих работы про ужасное состояние ИБ в скада-системах (по факту — отсутствие в принципе) HARP in Security и SCADA Strangelove.
                                          +1
                                          В крупных АСУ ТП обычно не используют LD или FBD слишком много писать и слишком сложно это.
                                          Пакеты используются более комплексные и более тяжеловесные.
                                          У нас например используют пакет проектирования Siemens PCS 7 v7.1 на части оборудования. (Не Step 7 а PCS, причем 80% его возможностей). Все программы написаны на CFC и SFC (Именно сименсовской вариации).
                                          А еще в более крупных системах используется финская система metsoACN (MetsoDNA/DamaticXDi).
                                          Странно что фирму Metso в статье не упомянули. Одна из крупнейших в России ситем автоматизации построена именно на ее решениях.
                                            0
                                            PCS 7 это вещь…
                                            У нас есть установка на которой стоит прародитель PSC 7 «некий» TELEPERM M.
                                              0
                                              писать на LAD и FBD совершенно несложно, но шаг вправо/влево и задача превращается в сложить слово «вечность» из букв «у», «х», «й» :) В принципе, это справедливо и для CFC и SFC, для каждого языка грабли отличаются.

                                              Опыт показывает, что лучше всего какие-то функциональные блоки написать на STL или SCL, и уже их засовывать в LAD или CFC.
                                              +2
                                              Возможности зависят от контроллера, обычно это где-то 20, 50, 250 мс, 1, 2, 3, 4, 5 с. Естественно, это не гарантирует выполнение кода именно за такой промежуток времени, нельзя большие программы пихать в цикл 20 мс, к началу следующего цикла предыдущий должен быть завершён.

                                              Вот здесь в корне не соглашусь с автором. Весь смысл использования ПЛК для управления технологическими процессами как раз в том, что в отличии от обычных PC они как раз таки гарантируют выполнение кода за определенное кол-во времени.
                                              Кроме того, система проектирования прост не даст положить тяжеловесную программу в организационный блок который выполняется за 20мс.
                                                0
                                                Контрпример — бесконечный цикл. Выполнится «за определенное кол-во времени»?
                                                  +1
                                                  Собственно, если внутри ПЛК сидит РТОС, в которой пользовательская программа выполняется, и при программировании мы выбираем, в какой временной дорожке выполняется та или иная часть программы, то проблем ровно ноль. РТОС сама придушит бесконечный цикл по таймеру и даст выполниться остальной программе. И это справедливо для большинства ПЛК.
                                                    0
                                                    В лохматых 90-х разрабатывал модули для контроллеров. В процессорном модуле было две однокристалки, они обслуживали мелкую периферию (индикацию, обмен с ПК и т.п.) а сам процессор был на рассыпухе — он в каждом такте обрабатывал одну команду РКС (язык релейно контактных схем ;-). Я тогда по молодости стал спорить с его разработчиком по поводу целесообразности, он мне на пальцах доказал, что его нельзя заменить даже продвинутыми (в то время) 386 интелловскими процессорами :-)
                                                    Вот такая РТОС :-)
                                                    +2
                                                    Какой бесконечный цикл? И что вы вообще подразумеваете под циклом (while или for)? :)
                                                    Цикл работы в 20мс, 30мс и так далее заложен в ПЛК аппаратно.
                                                    Он будет прерван в любом случае, выполнена ваша программа или нет.
                                                    Не успела — извините.
                                                      0
                                                      Ну мы спорим об одном и том же, но в разных терминах. Просто я исхожу из того, что прерванная на середине программа не считается выполненной =)
                                                        +2
                                                        Ну это уже на совести разработчика. А ПЛК гарантирует, что цикл будет выполнятся 20мс, не больше, не меньше.

                                                        Здесь нужно идти от обратного. Возьмем обычный ПК. Допустим вы написали программу которая может выполнится за 20мс и по требованиям должна выполнится. Обычный ПК с какой нибудь типичной ОС не даст вам однозначной гарантии. Может выполнит, а может заставит программу подождать, потому что ОС занимается чем то другим.

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

                                                        Вообще же к слову ни каких сложных вычислений и тем более ни каких программных циклов в таких программах там нет.
                                                        Обычно это опрос датчиков и выдача дискретной команды на управление.

                                                        Время вообще один из самых краеугольных камней в автоматизации. В непрерывных технологических процессах оно может стоить как поломки оборудования так и человеческих жизней.
                                                          0
                                                          Насчет ни меньше это вы зря, в плк реализуется циклический пуск процедур с необходимым временем, остальное зависит от объема кода, и если программа влезет в 1мс, то так и будет остальные 19мс страдать ерундой до следующего пуска. Опять же есть другая сторона, превышение времени выполнения… никаких гарантий, если вы творчески расписались, придется резать код или раздвигать цикл.
                                                          Ну и возможны варианты перезапуска по исполнению… сами понимаете время будет колебаться из-за вветвлений.
                                                            0
                                                            не успел поправить. я к чему, с фиксированным циклом вам гарантируется не время выполнения, а время перезапуска. Не уложились получите крестик в диагостике, болт в результате и возможно сваливание из рантайма в зависимости от производителя плк
                                                        0
                                                        Нет. Siemens S7 1200, MITSUBISHI FX, подвисают на while(true); Митсубиши даже не вываливается по ошибке, сименс уходит в стоп и моргает ошибкой. И никакой RT OS там нет, обычная коопаеративная многозадачность в лучшем случае.
                                                          +1
                                                          Не работал с S7 1200, но как пишет сам Сименс:
                                                          SIMATIC S7-1200 представляют собой новое семейство микроконтроллеров, предназначенных для решения самых различных задач автоматизации малого уровня.
                                                          Контроллеры способны обслуживать от 10 до 284 дискретных и от 2 до 51 аналогового канала ввода-вывод


                                                          У нас на предприятии в цеху используются 4 контроллера S7 400H, и обслуживают они в общей сложности порядка 10 000 контуров. В 1200 на сколько я сылшал даже отдельная своя среда разработки и своя ОС, отличная от 300/400 серии.
                                                            0
                                                            Среда разработки на данный момент общая для все — TIA Portal. Ну а колличество входов — если мне надо 16 аналоговых и 100 дискретов — зачем мне S7 400, а вот что касается времени исполнения программы — у любого контроллера, в среде разработке, при присоединении к нему есть такая вкладка — Cicle Time, напишите пустую программу, проверьте, а потом залейте рабочий проект и проверьте еще раз.
                                                              0
                                                              Почему же общая? PCS используется в основном сейчас для 300/400 серии, и ни куда не собирается деваться в ближайшие 10 лет точно. Был весной на курсах в Московоском уечбном центре Siemens. Работали c PCS 7, TIA Portal упоминался лишь вскользь.

                                                              Я не утверждаю что вам нужен 400 контроллер. Я говорю о том, что это разные модели предназначеные для разных вещей. Может 1200 серию вы и подвесите while(true), на счет 400Н не уверен.
                                                                0
                                                                TIA Portal до сих пор не поддерживает S7-400H (Step7) и несколько экранов в WinCC.
                                                              0
                                                              А вы не пробовали на Сименсе вставить OB обработки соотвествующей ошибки? Если его нет, то валится в стоп, да. Если есть — выполняется даже пустой.
                                                          0
                                                          Так как еще нет кармы для того чтобы плюсануть, то просто напишу тут, что:
                                                          Поддерживаю.
                                                            0
                                                            Нет, это может быть в каких то очень крутых контроллерах, но тоже маловероятно, обычно по мере роста программы цикл исполнения увеличивается.
                                                              0
                                                              К слову проверил с загруженным проектом на рабочем S7 400H.
                                                              Минимальное время цикла 17мс. В среднем прыгает пределах 14-20мс не более.
                                                              У нас нет в технологии процессов требующих время реакции менее чем 30мс.
                                                              В скомпилированном состоянии в ПЛК лежит программа в 6 мб.

                                                              На пустом увы проверить пока не могу, так как нет свободного ПЛК в наличии.
                                                              Но как появится, обязательно проверю, и за одно проверю, подвиснет ли он на бесконечной цикле while.
                                                                0
                                                                Цикл прыгает, из за того что программа в PLC идет по разным веткам, из-за чего и изменяется время выполнения. Что полностью подтверждает то что я говорил.Что касается фиксированного времени выполнения, то судя по всему, контроллеры имеют какое-то предустановленное время, при превышение которого, исполнение программы просто останавливается, и контроллер вываливается в ошибку. У каждого контроллера это время разное.
                                                                  0
                                                                  не свалится. Надо только вставить в программу (и загрузить в контроллер) OB80.

                                                                  Их там несколько разных OB на разные ошибки (превышение времени цикла, отвалившаяся периферия и т.д.). Соответственно, если возникает ошибка и в контроллер загружен блок обработки этой ошибки — контроллер выполнит этот OB. Если OB не загружен, то контроллер уйдёт в стоп.

                                                                  Если обработка ошибок должным образом выполнена (или контроллеру дана индульгенция в виде пустых OB обработки ошибок) — уронить сименс в стоп не получится.
                                                              +3
                                                              На что уж я не избалован художественным видением этого мира, но всегда поражался, глядя на интерфейсы СКАДА-систем. Кровь же из глаз идет, даже у меня.
                                                              Ну ведь сама среда разработки позволяет и цвета выбирать, и элементарные «выровнять это по центру, а вот эти элементы распределить равномерно» обычно поддерживает.
                                                              Ан нет. В 90% случаев что-то типа «Вот тут у нас ярко-синим по ярко-красному мы напишем температуру, возьмем это еще в кислотно-зеленую рамочку с убогим бордюрчиком, ну и, конечно, выровняем значение не по центру, а руками и так чуть ниже и левее центра, чтобы уж вообще красиво было. А еще трубу мы до емкости 3 пикселя не доведем, и стык труб у нас будет тоже со смещением на пиксель — я сам видел, там сварщики именно так в реальности и сделали».
                                                              А вы говорите — дизайн, юзабилити… Эх.
                                                                0
                                                                Рисуют это все программисты… Иногда приходится следовать корпоративным порядкам заказчика
                                                                www.fsk-ees.ru/upload/docs/STO_56947007-25.040.70.101-2011.pdf (стр.43)

                                                                Вы еще инструкции операторов не видели :)
                                                                  0
                                                                  Коллега, вы (Vijeo)Citect видели когда-нибудь?

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

                                                                  А если, при этом, требуется сделать какие-то косметические поправки удалённо, через TeamViewer, например… Шоб этим австралийцам в аду гореть :)
                                                                  +1
                                                                  меня всегда удивлял этот мир ПЛК, глядя на него со стороны Сишного пронраммиста МК некоторые вещи кажутся немного непонятными и смешными, хотя я понимаю что отработанные и неглючные решения тоже важны и нужны
                                                                    +1
                                                                    Как человек, который касался и того, и того, могу сказать вот что: у ПЛК уровень абстракции от железа, конечно, выше. Но это и логично: инженер по автоматизации производства должен решать именно задачу автоматизации, а не разбираться с временной диаграммой работы, скажем, АЦП. Ему важнее понимать, что «вот на этот модуль у меня от датчика давления пришел унифицированный сигнал 4-20 мА», а уж как он там конкретно преобразуется в INT — дело, в общем-то, десятое. А инженер по эксплуатации хочет точно знать, что этот модуль не вынесет первым же разрядом, когда весенний первый гром, а как там эта защита конкретно реализована — для него это, опять же, дело десятое.
                                                                    А если развить сравнение, то с таким же удивлением и непониманием на всех нас смотрят программисты, пишущие на еще более высоком уровне: как ни крути, но про ООП мы только слышали, про многопоточность — тоже, и нет у нас ни динамического выделения памяти, ни прочих благ и красот. И им наш мирок тоже кажется непонятным и зачастую смешным (впечатление сложено по итогам разговора с хорошим другом — разработчиком на Java).
                                                                      0
                                                                      смешным и отсталым :)
                                                                      0
                                                                      Интересно. А поподробней?
                                                                      +2
                                                                      Порадовал контраст между интерфейсом на картинке для привлечения внимания и суровыми реалиями на иллюстрациях.
                                                                        0
                                                                        Да уж, выглядит очень стремно.
                                                                        Предлагали мне как то написать программу для ПЛК овен
                                                                        Выглядит как то так ПЛК овен
                                                                        image

                                                                        Я скачал софт CoDeSys, и тут я понял что попал в АД!
                                                                        Выглядит как то так CoDeSys
                                                                        image

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

                                                                        p.s. Интересно, а какова сейчас вилка зарплат для асушников?
                                                                          +2
                                                                          Действительно, есть такая проблема. В основном нет информации в интернете потому, что все вопросы решаются в первую очередь через саппорт. Хорошая техподдержка является не самым последним критерием выбора оборудования и софта (при удовлетворении всех основных критериев, первый их которых — требования заказчика). Приличные интеграторы не гнушаются отправлять сотрудников на платные обучающие курсы, проводимые разработчиками или официальными дистрибьюторами. С одной стороны — если есть курсы и саппорт, лучше через них решать вопросы, а не искать/писать на форумах. С другой — кто ж будет задаром писать всё это на форумах, если они продают эти знания, и их реально покупают.

                                                                          На одних таких курсах мне в ответ на замечание, мол, у вас тут в одном из ключевых диалогов жуткий косяк в юзабилити, на который я всё время попадался и наконец не выдержал и высказался, — кнопка «Отмена» (компиляции проекта) превращается в кнопку «ОК» (закрытия диалога после завершения компиляции и заливки проекта), мне сказали, мол, у нас тут такая охрененная система, а тебе ещё чота не нравится, пф! Так что да, «не интуитивен, непонятен, запутан» это зачастую комплимент в сравнении с остальными))

                                                                          Вилка… субъективно, по хедхантеру, в больших городах (Мск, Спб) в среднем где-то на 30% меньше, чем программистам. Объективно (по нефтегазу) — чем ближе к объекту, тем больше, две крайности для примера: в проектном отделе выпустившийся студент без опыта — от 14к, специалист с опытом на северном месторождении (вахта) — около 100к.
                                                                            +2
                                                                            Вы знаете, CodeSys — это еще далеко не самый плохой вариант.
                                                                            Есть еще куча самодельных сред для всяких ПЛК, производитель которых счел, что он и сам с усами.
                                                                            Вот есть, например, такая EasyTools для контроллеров Carel. Так вот она при попытке скомпилировать такое:
                                                                            int i = 100000;
                                                                            вылетает с синим экраном без сохранения проекта.
                                                                            В той же среде (там один-единственный язык — FBD) при рисовании линий, соединяющих функциональные блоки, нет привязки. То есть: не довел мышь на один пиксель — получи ошибку компиляции. Без детализации. В стиле «у блока № такой-то есть неподключенные линии». Если этих линий штук 40, попытка найти ту, которую плохо нарисовал — крайне нетривиальная задача.
                                                                            Вот еще выше автор упоминал такую поделку, как Indusoft. Тоже склонна при нажатии «compile» вылетать с исключением, не сохраняя проект.
                                                                            Так что — лучше уж CodeSys.
                                                                              0
                                                                              У Carel довольно давно уже 1tool — совершенно менее глючное ПО, что же вы на EasyTool кодите, древние линейки от Carel?
                                                                                0
                                                                                Данный опыт относится примерно к 2008 году. Восхитило настолько, что вряд ли я стану когда-либо еще использовать их ПЛК. Вот их платы для управления фанкойлом — совсем другое дело, удобная, на мой взгляд, штуковина, могут, значит, когда хотят. А вот pCO* — увольте…
                                                                              0
                                                                              Ваш коммент напоминает мне анекдот про то, как Рабинович по телефону Битлз напел :)

                                                                              Оно всё довольно понятно, если иметь представление, что такое LAD(der) и как работает контроллер.
                                                                              Информации на эту тему полно, вы таки плохо искали и мало знали. Тем более, что SCADA — это немного другое. Это визуализация процесса, а CoDeSyS — это среда разработки программы для контроллера.
                                                                              0
                                                                              А с PLC контроллерами компании WAGO приходилось работать? Если да, то как они вам в сравнении с вышеописанными?
                                                                                +2
                                                                                C братьями-близнецами Beckhoff работаем, модели BX, CX. По ассортименту модулей — рулез немереный по сравнению и с Сименсом, и со Шнайдером, и еще с чем-нибудь. На борту ПЛК чистый Ethernet (или еще тысяча интерфейсов на выбор). Модули ввода-вывода начиная от дискретных на разные напряжения (от 5 В) и заканчивая диммерами, ключами на МОСФЕТах и измерителями токов и напряжений, плюс модули сопряжения со всеми популярными полевыми шинами (от 232/485 до KNX, LON, Dali). Так что можно строить абсолютно любые системы, от ЧПУ станка до умного здания, и самое главное — все легко программируется и работает :)
                                                                                  0
                                                                                  Вот наличие modbusTCP и другого, на TCP оканчивающегося, вплоть до отладки по сети и встроенных www визуализаций радует безмерно.
                                                                                  И да, ассортимент модулей-шикарен.
                                                                                    0
                                                                                    на PCS7 от сименса тоже очень быстро и приятно программировать — а главное, строить большие и серьёзные резервированные системы :)
                                                                                    +1
                                                                                    Плюс к вышесказанному — просто нереальная для других ПЛК производительность — есть модели с процессорами вплоть до 2ГГц.
                                                                                    Есть не только полноценные «головы» типа CX, но и просто точки сбора данных (серия BK), которая цепляется с одной стороны к модулям ввода-вывода, а с другой стороны через тот же Ethernet к голове. Программа крутится на голове, а ввод-вывод может быть разнесен по всему объекту. И это все очень просто настраивается.
                                                                                    0
                                                                                    Отдельно хотел бы поблагодарить за статью, хотя бы узнал, чем занимался если пошел бы по специальности, появилась связь между теорией и как это реализуется на практике :)

                                                                                    Тем не менее, возникает ощущение, что рынок систем АСУТП развивается в некотором ваакуме по отношению к другим ИС и игнорирует необходимость развития сред разработки и юзабилити. Особенно впечатлен FBD, ровно то, что мы рисовали на листах в институте, рассчитывали импульсы…
                                                                                      +1
                                                                                      Тоже думал на тему упомянутого развития «в вакууме» и пришел к такому выводу. Технологические процессы в массе своей — штука медленная. Это для нас 50 мс — немало, а среднестатистический вентилятор за это время едва оборот успеет сделать. Время отработки даже аварийных устройств, заслонок, например — всё равно измеряется секундами. А отсюда простой вывод: нет смысла наращивать быстродействие. Числодробилки 80-х годов разработки будет достаточно для 99% и сегодняшних задач.
                                                                                      А второй пункт — повышенные требования к надежности. Тот же Ethernet пришел в АСУТП совсем недавно — когда его уже обсосали со всех сторон в порядке, скажем так, бытовой эксплуатации. И именно из-за этих требований, если вывести на рынок абсолютно новую, передовую и вообще клевую среду разработки, многие инженеры отнесутся с изрядным недоверием — а вдруг оно глючит? Порой ставки слишком высоки, как писал выше тов. Vikond.
                                                                                        +1
                                                                                        Надежность в АСУТП всегда на первом месте.

                                                                                        Тот-же «медленный» профибас ГАРАНТИРУЕТ, что каждое устройство получит возможность передать информацию через заранее известное время.
                                                                                        А вот гарантирует ли передачу информации Industrial Ethernet вопрос. И на него я не мог получить ответа (не мог 2 года назад, больше не интересовался) даже у Сименса.
                                                                                        Я так понял, что гарантия передачи информации по Ethernet зависит напрямую от скорости соединения.
                                                                                          0
                                                                                          Есть у них такая штука — IRT (isichronous realtime) на профинете. Но как мне когда-то объяснила поддержка, оно заточено для синхронизированного управления приводами.
                                                                                      +1
                                                                                      Лично мне бы очень интересно было бы почитать про встроенные средства защиты SCADA — в частности, по методикам проверки корректности поступающих данных, контролю целостности самой себя, средств журналирования, встроенных средств разграничения доступа, возможностях работы из-под пользовательских учетных записей.
                                                                                        0
                                                                                        Окей, хорошая тема.
                                                                                          0
                                                                                          Дык. Сам в это упираюсь регулярно. Я — безопасник по АСУ ТП. И мне остро не хватает взгляда с той стороны.
                                                                                          И наоборот — реальные АСУТПшники не понимают потребностей безопасников напрочь — и не любят их (и в чем-то я их понимаю).

                                                                                          Но законы есть законы, и volens nolens придется дружить и сосуществовать.
                                                                                            +1
                                                                                            А я расскажу, за что АСУТПшникам не любить безопасников.
                                                                                            Во-1, производители средств автоматики очень любят разные проприеритарные протоколы, нестандартные (с точки зрения безопасников) порты, протоколы (UDP всякие, ISO) — а безопасники очень любят блокировать абсолютно всё, без чего могут существовать офисные хомячки. В результате мы имеет то, что связь либо не работает совсем, либо работает с совершенно необъяснимыми глюками. Я уж не говорю о том, что безопасники очень любят блокировать средства удалённого доступа — такие как VPN, TeamViewer, LogMeIn и RDP. А автоматчик к объекту цепью не прикован. И вот, как обычно, случается ЧП ночью в выходные, тебя будят в тёплой постельке, а ты даже масштаб бедствия оценить не можешь. Потому, что со слов эксплуатации — «оно само», а зайти посмотреть логи — никак…

                                                                                            Вот и получается, что безопасники, в сущности, втыкают палки в колёса. Абсолютно все, какие только можно воткнуть. И безопасникам никто за это голову не морочит. А когда автоматика не работает или работает странно (по причине тех самых плавающих глюков) — по голове получают автоматчики, и получают сильно. А безопасникам — хоть бы хрен.
                                                                                          0
                                                                                          Защита от сбоев — дублирование. На некоторых моделях ПЛК есть защита от перепрограммирования по паролю. В серверной части тоже парольная защита, логи свои и системные. В остальном защита навесная — антивирь, изолированные влан, отсутствие физического доступа у посторонних к системным блокам (в том числе и у операторских станций, операторам доступен монитор, да мышка с клавой), ключ от серверной под роспись и т.п.
                                                                                            0
                                                                                            Спасибо, я в курсе, как это делается сейчас. И делается это (чаще всего) с закрытием глаз на половину требований.
                                                                                            Я хочу узнать, как это можно делать.

                                                                                            Потому как, скажем, «Общие требования по обеспечению безопасности информации в ключевых системах информационной инфраструктуры» от 18 мая 2007 года устанавливают требования к КСИИ не ниже 1Г (вплоть до 1Б в ряде случаев), а это, среди прочего, таки контроль целостности и очистка памяти. А АСУТП кое-каких объектов (транспорт, ТЭК, например) — вполне себе КСИИ.
                                                                                            Это можно делать наложенными средствами, да только очистка памяти начинает резко тормозить работу АРМ вплоть до (в сильно отдельных случаях) полного останова. Контроль целостности тоже производительности машине не добавляет.
                                                                                            Антивирус — это прекрасно, да только до обновления баз на боевой системе базы нужно обкатывать на тестовой зоне (чтобы он критичный файл не съел и трафик вдруг не перекрыл) — а в АСУ ТП далеко не каждого объекта есть такие зоны. И в редкие проекты они закладываются.

                                                                                            Я и хочу понять АСУТПшников, что могут сделать они, а что можем сделать мы — чтобы жить вместе долго и счастливо, а не лаяться, как сейчас, и не строить козни друг другу. Потому как ему нужна рабочая система, а мне — выполнение действующих норм. И есть шансы разобраться вместе и договориться полюбовно. Встроенные средства в этом плане лучше наложенных.
                                                                                              0
                                                                                              Может мы друг друга не понимаем, но контроль целостности: есть два сервера, они зеркалят друг друга, нарушение целостности критических фалов скады приведёт к сообщению о потере синхронизации, на которое реагирует сменный персонал. Можно поставить файловый монитор, который будет проверять чексуммы файлов (тех, которые не изменяются). Если пересчитывать чексуммы постоянно изменяющихся файлов (особенно файлы БД), а потом смотреть правило что для этих файлов не показывать ошибку — то конечно будет падать производительность.
                                                                                              Сам проект, алгоритмы в скаде и в ПЛК, есть контроль на уровне какая версия проекта сейчас залита.
                                                                                              А очистка памяти — от чего очищать, если сервер работает годами без перезагрузки, и оперативка используется почти вся.
                                                                                                0
                                                                                                А как Вы будете определять, который из двух несовпадающих конфигов — некорректный? Ручками?
                                                                                                В системах с высокой надежностью обычно ставят три независимых контура, и совпадение по двум контурам считается правдой.

                                                                                                Файловый монитор — это и есть по сути упрощенный контроль целостности. Только для него зеркалирование не нужно. Это иной принцип обеспечения надежности.

                                                                                                Скада свое содержимое проверяет на изменение? Если я перехвачу работу с памятью — она это обнаружит? Если я сяду на канал и начну гнать неверные показания датчиков — она это почувствует?

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

                                                                                                  Если перехватите работу с памятью на одном из серверов и начнёте изменять данные — перехватит как расхождение синхронизации серверов.
                                                                                                  Сядете на канал как? Физически на канал 4-20 мА? Или тоже перепишете память одного из контроллеров — расхождение синхронизации контроллеров. Прогрузить одновременно два контроллера — загрузка новой прошивки много дольше времени исполнения цикла, авария случится. Поэтому проект загружают поочереди на каждый контроллер под звуки соответствующего оповещения, предупреждая оператора чтобы не пугался.
                                                                                                  Поковыряйте архитектуру АСУТП — два сервера, читают данные из двух контроллеров. Между серверами heartbeat, и между контроллерами heartbeat. Что либо перестаёт откликаться — переходим на резерв с оповещением.

                                                                                                  Если обсуждать что это гостребование и хоть разбейся но выполни, то адекватного диалога не получится — требования не адекватны. Готового решения вам тут не скажут, кому охота чтобы надзорные органы знали как обходят их требования.
                                                                                                    0
                                                                                                    Вот в том и проблема, что вы не понимаете, зачем мы лезем в потроха, а мы не уверены, что этих потрохов достаточно.
                                                                                                      0
                                                                                                      Представил я себе, как автор вопроса внедрится в S7-400H, и подменит там программу в обоих контроллерах (3 раза ха) :))

                                                                                                      На всякий случай, разверну мысль. S7-400H — это физически дублированный контроллер. Две половинки, связанные оптической пуповиной. Обновление программы происходит следующим образом: останавливаем один контроллер (пожалуйста, у нас уже без палева в логах есть информация о том, что один контроллер встал), загружаем в него новую программу и просим (именно, никак иначе) систему перейти с одного контроллера на другой. И никогда на 100% заранее не знаешь, что система ответит. А есть 2 варианта: переход возможен (и он выполняется) либо переход невозможен: контроллер, по своим соображениям, считает, что изменения слишком большие и требуется полная остановка, загрузка обеих половинок и рестарт.

                                                                                                      Или внедриться на Profibus (закрытый протокол) и слать левые данные… Конечно, если это получится, я сниму (и, возможно, даже съем) свою шляпу. Но я искренне не понимаю, зачем такие сложности. Есть уйма более простых, надёжных, дешёвых и быстрых способов поставить производство раком. В большинстве случаев это называют человеческим фактором :))))
                                                                                                      0
                                                                                                      ГОСТы и прочие требования очень часто пишут люди, которые не вполне представляют, что осуществимо, а что — нет. Бывает, такого понапишут…
                                                                                              0
                                                                                              Дык. Сам в это упираюсь регулярно. Я — безопасник по АСУ ТП. И мне остро не хватает взгляда с той стороны.
                                                                                              И наоборот — реальные АСУТПшники не понимают потребностей безопасников напрочь — и не любят их (и в чем-то я их понимаю).

                                                                                              Но законы есть законы, и volens nolens придется дружить и сосуществовать.
                                                                                                0
                                                                                                :)))

                                                                                                А я вот категорически не дружу с безопасностью. Мне проще (в самом крайнем случае) снести и переставить к чёрту винду на компе с нуля, намазать офис и VMware и вернуться к работе.

                                                                                                Просто, помимо серьёзного железа приходится иметь дело со всяким дешёвым говном, авторы которого знают толк в извращениях хитрых коммуникациях через любопытный порт, который чем-то не нравится антивиру. А ты сиди и ломай башку полдня, почему ж никак не получается до этой чёртовой железки достучаться…
                                                                                                0
                                                                                                а почему не упомянули LabVIEW? для АСУТП очень широко применяется.

                                                                                                Only users with full accounts can post comments. Log in, please.