Comments 112
UFO just landed and posted this here
Плюсую. Именно графические языки в случае с АСУТП являются прекрасной возможностью наиболее наглядно и структурировано изложить даже весьма комплексный алгоритм. Только вот коллеги почему-то придерживались мнения автора поста =(
А SFC удобен для структурирования наиболее общего видения алгоритма работы сразу нескольких агрегатов.
А SFC удобен для структурирования наиболее общего видения алгоритма работы сразу нескольких агрегатов.
Попробуйте — вам понравится ;]
Не знаю, не знаю, может у вас задачи не очень сложные, но попробуйте на LD написать опрос какого нибудь девайса с экзотическим протоколом, и парсинг его пакетов с преобразованием данных между типами… Мне к сожалению приходится писать для PLC и каждый раз когда я сажусь это делать, я вспоминаю производителей не злым тихим словом… Почему бы не реализовать возможность писать на ANSI C… Если я хочу выстрелить себе в ногу, я найду как это делать даже на LD, а вот когда мне нужно сделать какуюто простую вещь по преобразованию типа данны, вместо *(float*) я должен использовать всякую лабуду… Да а на Mitsubishi нет типа данных byte, там чтобы получить доступ к байту не по четному адресу, нужно такой изврат творить… Короче я надеюсь что в ближайшем времени кто нибудь выпустит таки контроллер с возможностью писать под него на С++/C#/Java…
www.icp-das.ru/ тебе в помощь.
Говорят даже симулинк прикрутить можно.
Только редко в задачах АСУТП требуется «парсить пакеты», да и экзотика появляется только тогда когда ТЗ не проработаны как следует.
Говорят даже симулинк прикрутить можно.
Только редко в задачах АСУТП требуется «парсить пакеты», да и экзотика появляется только тогда когда ТЗ не проработаны как следует.
Да запросто. Модбас с регистрами по 32 бита как вам?
Зачем?
Может я конечно не догоняю, но у меня есть 3 типа сигналов в АСУТП (верхний уровень не беру) дискретный, аналоговый, цифра с профибас.
Что еще надо для счастья?
Зачем Модбас? Пусть живет своей жизнью.
Может я конечно не догоняю, но у меня есть 3 типа сигналов в АСУТП (верхний уровень не беру) дискретный, аналоговый, цифра с профибас.
Что еще надо для счастья?
Зачем Модбас? Пусть живет своей жизнью.
Какой интересный подход. Ну если вам незачем — то как я смею со своими жалкими делишками навязываться))
Подходы немного разные просто.
Мы немного «избалованы» и денег на АСУТП у нас, как привило, не жалеют.
Зато когда оно не работает нам нездоровиться ибо убытки во время простоя начинают исчисляться миллионами в сутки.
По этому все должно быть надежно, просто, понятно, быстро ремонтироваться, и не дай бог где-то чего-то как-то будет парситься, а не ремонтироваться слесарем 6 разряда с калибратором и отверткой)))).
Так что все сигналы, что идут в АСУТП из нее это только по проводам, которые можно померить калибратором или тестером на крайняк… Ну если совсем надежное оборудование, то профибас.
Хотя 10 лет назад я думал как Вы (к сожалению не знаю Вашего возраста).
Но 10 лет работы по 2мпростым правилам:
Первое — Если что-то не работает по твоей вине, то это очень плохо.
Второе — Так ребята, тут за 7-8 месяцев надо установочку автоматизировать (да,… а физически мы ее соберем через 6-7 месяцев заодно и скажем как она должна работать), наладить, так чтоб работала и план выполняла, не взрывалась, если что не так. Да и смотри п.1.
Так вот работа по этим 2м правилам немного поменяла меня. Стал как в армии — все должно быть параллельно и перпендикулярно. Понятно и просто. И не надо ничего ПАРСИТЬ. Если надо что-то на чем-то парсить, то надо это выкинуть и поставить что-то другое. Чтоб просто работало))))
А си, парсинг и все остальное это у меня дома на ардуине))))
Мы немного «избалованы» и денег на АСУТП у нас, как привило, не жалеют.
Зато когда оно не работает нам нездоровиться ибо убытки во время простоя начинают исчисляться миллионами в сутки.
По этому все должно быть надежно, просто, понятно, быстро ремонтироваться, и не дай бог где-то чего-то как-то будет парситься, а не ремонтироваться слесарем 6 разряда с калибратором и отверткой)))).
Так что все сигналы, что идут в АСУТП из нее это только по проводам, которые можно померить калибратором или тестером на крайняк… Ну если совсем надежное оборудование, то профибас.
Хотя 10 лет назад я думал как Вы (к сожалению не знаю Вашего возраста).
Но 10 лет работы по 2мпростым правилам:
Первое — Если что-то не работает по твоей вине, то это очень плохо.
Второе — Так ребята, тут за 7-8 месяцев надо установочку автоматизировать (да,… а физически мы ее соберем через 6-7 месяцев заодно и скажем как она должна работать), наладить, так чтоб работала и план выполняла, не взрывалась, если что не так. Да и смотри п.1.
Так вот работа по этим 2м правилам немного поменяла меня. Стал как в армии — все должно быть параллельно и перпендикулярно. Понятно и просто. И не надо ничего ПАРСИТЬ. Если надо что-то на чем-то парсить, то надо это выкинуть и поставить что-то другое. Чтоб просто работало))))
А си, парсинг и все остальное это у меня дома на ардуине))))
В принципе, я согласен, чем проще и прозрачней, тем лучше. Только вопрос «зачем?»… всякое бывает, я ж не с потолка придумал 32битный модбас, а из жизни)
Я так понимаю, вы с атомной энергетикой связаны? Напишите пост =)
Я так понимаю, вы с атомной энергетикой связаны? Напишите пост =)
С ней, родимой…
Если честно, не знаю, чего я завелся… Наверное привычка с работы — надежность, безопасность, ядерная безопасность, радиационная безопасность, не забыть про водород и так по кругу.
Параноиком стал. Хотя наверное в моем случае это хорошо.
Каждая задача может иметь свое решение. И мое не панацея.
Написать времени нет. Правительство рапортует о новых направлениях в энергетике, а мы «отдуваемся». На работе сейчас много новых установок проектируется. Часть сами делаем, часть отдаем на сторону…
Если честно, не знаю, чего я завелся… Наверное привычка с работы — надежность, безопасность, ядерная безопасность, радиационная безопасность, не забыть про водород и так по кругу.
Параноиком стал. Хотя наверное в моем случае это хорошо.
Каждая задача может иметь свое решение. И мое не панацея.
Написать времени нет. Правительство рапортует о новых направлениях в энергетике, а мы «отдуваемся». На работе сейчас много новых установок проектируется. Часть сами делаем, часть отдаем на сторону…
Это хорошо, когда у вас такие заказчики, а когда автоматизируемый объект содержит в себе зоопарк из оборудования различных производителей(ну не производит Siemens одоризационные установки, и никто не сделал таковой на основе контроллеров Siemens). То тут как не крути, надо парсить… Да и система автоматики в нашем случае больше является точкой интеграции информации с различных подсистем, с бонусом в виде управления некоторыми технологическими процессами.
Вот выше написали про IcpDAS, хорошие штуки, мы их используем, но к сожалении заказчики не признают их как основные системы управления… Вот в последнее время они и парсят, на C…
Вот выше написали про IcpDAS, хорошие штуки, мы их используем, но к сожалении заказчики не признают их как основные системы управления… Вот в последнее время они и парсят, на C…
Скажу по секрету мы сами себе заказчики))) вот я тут и разошелся))))
UFO just landed and posted this here
А вы вычислители расхода газа пробовали интегрировать в свои системы?
UFO just landed and posted this here
Ключевое слово Modbus RTU, и импортные вычилители. На Украине лобируются отечественные вычислители Флоутек, хорошо если удастся договорится отделом метрологии с УкрТрансГаза и протолкнуть проект на ФлоуИнек(ДаниФлоу)… Все о чем вы говорите — неисполнимые мечты. Но даже это не учит отечественных производителей, www.measure.com.ua/page_b25.html отличная железяка для применения в качестве корректора расхода газа на собственные нужды, но протокол у ни опять таки «велосипед»…
Не скажите. А если Вам требуется интеграция с оборудованием стороннего производителя? Ну вот не делает производитель вашего ПЛК, скажем, частотные приводы для двигателей, а по ТЗ он нужен. Слава богам, если привод будет поддерживать какой-либо стандартный протокол обмена, хотя бы и ModBUS.
А еще бывает такое: «система должна интегрироваться с существующим оборудованием». А под этим термином подразумевается, скажем (пример из личной практики) чудо-теплосчетчик отечественной разработки со своим, совершенно подкуренным протоколом обмена, да еще и не совсем соблюдающий спецификацию EIA-232. Вот тут становится реально дурно.
А еще бывает такое: «система должна интегрироваться с существующим оборудованием». А под этим термином подразумевается, скажем (пример из личной практики) чудо-теплосчетчик отечественной разработки со своим, совершенно подкуренным протоколом обмена, да еще и не совсем соблюдающий спецификацию EIA-232. Вот тут становится реально дурно.
Да да:) У нас такие вычислители расхода газа, тоже чудо отечественного приборостроения:) Которые на пине RS-232 Tx выставляют активный уровень только в момент передачи, после того как воспринял запрос как к себе, а так висит этот Tx в третьем состоянии, хотя по стандарту в состоянии MARK там должно быть -12, и клемнички не подписаны… Вот и гадай толи Rx/Tx попутал, толи CRC не так посчитал в запросе, тиоли адрес не тот…
Раскопка схемы того прибора, о котором я писал, показала:
Линии GND и Rx порта на компьютере должны подключаться к -Tx и +Tx прибора.
Линии Tx и DTR должны быть воткнуты в -Rx и +Rx прибора, причем на DTR должна быть лог. 1.
Проще говоря, производитель сделал из 232 этакий недоделаный 485, причем с жесткой привязкой именно к уровням сигналов на COM-порту компьютера (3..15В уровень? Не, не слышал).
Линии GND и Rx порта на компьютере должны подключаться к -Tx и +Tx прибора.
Линии Tx и DTR должны быть воткнуты в -Rx и +Rx прибора, причем на DTR должна быть лог. 1.
Проще говоря, производитель сделал из 232 этакий недоделаный 485, причем с жесткой привязкой именно к уровням сигналов на COM-порту компьютера (3..15В уровень? Не, не слышал).
Я же сказал, что мы немного «избалованы», да и руководство понимает, что проще выкинуть неугодный привод и купить новый, пусть он и лимон стоит, но чтоб работало без выкрутасов.
Мы (наш участок) большую часть времени поддерживаем работоспособность существующего АСУТП, чем создаем новое. Хотя даже если задача по автоматизации заказана «на стороне», то контролируем мы каждый шаг.
Когда предприятие работает круглогодично, то вылезают неприятные моменты, такие как переполнения буфера, или память выделяется но не высвобождается.
И если ошибка возникает раз в 3-4 месяца, то отловить ее непросто.
Как правило у нас все «нестандартное» переделывается на «стандартное» со временем.
Тут наверное задачи разные.
Многие, кто на сайте подстраиваются под заказчика, который хочет быстрее и дешевле…
А у меня задача такая — работа с ураном ошибок не прощает…
Мы (наш участок) большую часть времени поддерживаем работоспособность существующего АСУТП, чем создаем новое. Хотя даже если задача по автоматизации заказана «на стороне», то контролируем мы каждый шаг.
Когда предприятие работает круглогодично, то вылезают неприятные моменты, такие как переполнения буфера, или память выделяется но не высвобождается.
И если ошибка возникает раз в 3-4 месяца, то отловить ее непросто.
Как правило у нас все «нестандартное» переделывается на «стандартное» со временем.
Тут наверное задачи разные.
Многие, кто на сайте подстраиваются под заказчика, который хочет быстрее и дешевле…
А у меня задача такая — работа с ураном ошибок не прощает…
Вне всякого сомнения, в Вашей работе цена ошибки на порядки выше. Отвал вентиляции торгового центра на полчаса, час — это не смертельно, система очень инерционна, большинство посетителей этого даже не заметят. а вот в то же время, на полное разрушение реактора, как показал 86-й год, хватает минуты.
Я не реактора обслуживаю. Там такие параноики, что мне до них далеко. Там вообще все свое — свои контроллеры со стократным резервированием, своя ОС на базе Linux, СКАДА своя, и все это, как иногда пишется в интернете, не пострадало при атаке вируса CTUXNET на Иран. Атомная станция в Бушере не была затронута. Только обогатительное предприятие, которое, кстати было на SIEMENS.
У нас просто переработка урана. Так что у нас попроще немного, но все равно надо быть на чеку.
У нас просто переработка урана. Так что у нас попроще немного, но все равно надо быть на чеку.
Странная вещь, тем более, что существуют регистры 5x, которые обычно проецируются на ту же область 4x. Если это не оно, то это велосипед, а если оно — то ModBUS 0x03 Read holding register никто не отменял, и сложить из двух word'ов один dword не есть проблема.
Регулярно приходится. Многие производители не считают должным придерживаться общепринятых протоколов обмена, либо же протокол-то в их круге общепринятый, но ваш ПЛК его не знает. Как быть? Только писать свою реализацию, т.е. парсить пакеты руками. Как пример: для снятия показаний со счетчиков электроэнергии применяется протокол согласно ГОСТ 61107-2001. Есть хоть один ПЛК с его нативной поддержкой? А вот мне, поскольку работаю я в области автоматизации зданий, он нужен.
но попробуйте на LD написать опрос какого нибудь девайса
он попробует и будет лестница… в небо
типа такого
Короче я надеюсь что в ближайшем времени кто нибудь выпустит таки контроллер
попробуйте B&R там есть си, стреляйте на здоровье…
Мы используем ТОЛЬКО LD и FBD.
Соглашусь, что «писать программы» на них не удобно, но описать почти любой техпроцесс почти элементарно.
Зато когда на работающем оборудовании возникает проблема, то, подключившись программатором, и посмотрев состояние переменных в онлайн можно достаточно легко и быстро диагностировать неисправность.
1. Например не открылся клапан (нет единички с контроллера).
2. Смотришь по схеме с какого выхода контроллера идет дискретный сигнал.
3. Смотришь по адресу, где в программе этот битек устанавливается.
4. Смотришь в программе какие условия не соблюдены.
5. Все. Проблема найдена. Осталось ее решить.
А когда у тебя установка на 1500 входов-выходов, и не дай бог, что-то пошло не так, то рыться в сишном/паскальном/ассемблерном коде и искать ошибку я врагу не пожелаю.
Соглашусь, что «писать программы» на них не удобно, но описать почти любой техпроцесс почти элементарно.
Зато когда на работающем оборудовании возникает проблема, то, подключившись программатором, и посмотрев состояние переменных в онлайн можно достаточно легко и быстро диагностировать неисправность.
1. Например не открылся клапан (нет единички с контроллера).
2. Смотришь по схеме с какого выхода контроллера идет дискретный сигнал.
3. Смотришь по адресу, где в программе этот битек устанавливается.
4. Смотришь в программе какие условия не соблюдены.
5. Все. Проблема найдена. Осталось ее решить.
А когда у тебя установка на 1500 входов-выходов, и не дай бог, что-то пошло не так, то рыться в сишном/паскальном/ассемблерном коде и искать ошибку я врагу не пожелаю.
Вопрос грамотной структуризации кода, я считаю. Про повышение читаемости кода на си/паскале написаны километры статей, и многое из них к тому же ST вполне применимо.
А лучший вариант — это комбинация LAD/FBD (ещё лучше, если CFC — это такой продвинутый FBD) с STL/SCL.
Блоки типа мотора, клапана и прочее пишутся на STL/SCL, многократно проверены и отлажены и прекрасно вставляются в ладдер.
Блоки типа мотора, клапана и прочее пишутся на STL/SCL, многократно проверены и отлажены и прекрасно вставляются в ладдер.
SFC… Ни разу не встречал и не слышал, чтобы где-то использовался.
Просто повезло наверное. Энергетики в прошлом году «обрадовали», что все программы должны быть именно на нем. Но нас сия участь обошла вместе с контрактом.
Как жаль, что аудитория АСУ ТП на хабре так мала, и дело доходит только до обзорных статей…
UFO just landed and posted this here
Если есть «открытые» (aka open source) и достаточно дешевые реализации, то о них было бы интересно почитать.
А то Simatic Step 7 и Delta V, распространенные, по крайней мере у нас, нагоняют грусть-тоску одними лицензиями на потенциальных заказчиков, не говоря о цене разработки и наладочных работ, там, как правило, звучит ответ: когда-нибудь потом (никогда).
А ведь АСУТП это ведь не только для больших дядей с многомиллионными ежемесячными оборотами, которых по пальцам можно пересчитать?
А то Simatic Step 7 и Delta V, распространенные, по крайней мере у нас, нагоняют грусть-тоску одними лицензиями на потенциальных заказчиков, не говоря о цене разработки и наладочных работ, там, как правило, звучит ответ: когда-нибудь потом (никогда).
А ведь АСУТП это ведь не только для больших дядей с многомиллионными ежемесячными оборотами, которых по пальцам можно пересчитать?
Достаточно дешевые это типа китайских ICP DAC. Программируются на С и даже на Визуал Бейсике :), т.к. внутри может быть ВинСЕ или Линукс — открытее некуда. Сам не работал, но на профильных форумах пишут, что железяки глючные, поэтому использовать не рискуем.
Не стоит на ICP DAS наговаривать. Как и любое сложное оборудование не без особенностей, но годное для применения, кроме того отлично работает без всякого подогрева в шкафах (до -30 точно).
А возможность запрогать контроллер из-под VisualStudio после всяких Ultralogik'ов, TraceMod и WinCC, просто кайф.
Я последнее время я вообще от общепромышленных SCADA отказался — написал свои библиотеки для низа и для верха. Заказчики безумно довольны, т.к. стоимость владения системой и создания новых рабочих мест по сравнению с покупкой лицензий получается вообще копеечная, по NDA все необходимые исходники передаются им, так в случае чего они смогут решить и проблемы с поддержкой системы.
И кроме того, доступ ко всем исходником качественно повышает уровень обнаружения дефектов. Как страшный сон вспоминаю переписку с техподдержкой Iconics из-за жутких тормозов Genesis, так и не выяснили в чём причина. Пришлось полностью переустанавливать систему и кучу спец. софта.
Но конечно масштаб систем у меня не очень большой. Самые крупный — комбикормовый завод. Прекрасно понимаю, что для нефти и газа мой подход не подойдёт в том числе и по формальным причинам.
А возможность запрогать контроллер из-под VisualStudio после всяких Ultralogik'ов, TraceMod и WinCC, просто кайф.
Я последнее время я вообще от общепромышленных SCADA отказался — написал свои библиотеки для низа и для верха. Заказчики безумно довольны, т.к. стоимость владения системой и создания новых рабочих мест по сравнению с покупкой лицензий получается вообще копеечная, по NDA все необходимые исходники передаются им, так в случае чего они смогут решить и проблемы с поддержкой системы.
И кроме того, доступ ко всем исходником качественно повышает уровень обнаружения дефектов. Как страшный сон вспоминаю переписку с техподдержкой Iconics из-за жутких тормозов Genesis, так и не выяснили в чём причина. Пришлось полностью переустанавливать систему и кучу спец. софта.
Но конечно масштаб систем у меня не очень большой. Самые крупный — комбикормовый завод. Прекрасно понимаю, что для нефти и газа мой подход не подойдёт в том числе и по формальным причинам.
Все мечтаю ICP DAS на деле попробовать, только заказчиков подходящих не нашлось. С экономным заказчиком связываться себе дороже обычно выходит. Экономишь на скаде — бесплатная оказывается глючной, экономишь на железе — дешевое и отечественное тоже начинает глючить. А с дорогим оборудованием большая часть проблем случается из-за ошибок проектирования/программирования.
Есть опыт эксплуатации их преобразователей и хабов RS485 типа 7520, 7513. Очень все положительно, за 5 лет из двух десятков умер один, причем это было вызвано попаданием 220В на питание. ПЛК не щупал, к сожалению.
Экономия а железе выливается в увеличение геморроя при разработке, что съедает всю экономию разово, и на поддержке и сопровождении (уже регулярный минус).
У нас сыпятся ICP DAS в тяжелых условиях (есть небольшие пары кислоты) иногда подвисают, хотя всего линеек 10-15 стоит.
А из опыта десяти лет эксплуатации SIEMENS (S7-200, 300, 400, и даже 488 есть 2 шт) а это порядка 2000 модулей (процессорные, входа-выхода) вышло из строя всего 3 модуля. Первый это ET-200 модуль, и 2 аналоговых входа (сожгли сами, не так включили).
В общем с учетом того, что у нас остановка оборудования тянет за собой расходов на переработку брака лимона на 2-3 сразу. SIEMENS окупился уже сто раз.
А ICP DAS будем менять скоро на SIMATIC.
А из опыта десяти лет эксплуатации SIEMENS (S7-200, 300, 400, и даже 488 есть 2 шт) а это порядка 2000 модулей (процессорные, входа-выхода) вышло из строя всего 3 модуля. Первый это ET-200 модуль, и 2 аналоговых входа (сожгли сами, не так включили).
В общем с учетом того, что у нас остановка оборудования тянет за собой расходов на переработку брака лимона на 2-3 сразу. SIEMENS окупился уже сто раз.
А ICP DAS будем менять скоро на SIMATIC.
Ну почему же, были хорошие статьи по теме и немало. Сходу: серия "Как я скаду писал", про информационную безопасность как надо и как не надо и про функциональную безопасность как есть.
Жаль, хаба под это дело нет.
Жаль, хаба под это дело нет.
Вот еще хорошие две свежих работы про ужасное состояние ИБ в скада-системах (по факту — отсутствие в принципе) HARP in Security и SCADA Strangelove.
В крупных АСУ ТП обычно не используют LD или FBD слишком много писать и слишком сложно это.
Пакеты используются более комплексные и более тяжеловесные.
У нас например используют пакет проектирования Siemens PCS 7 v7.1 на части оборудования. (Не Step 7 а PCS, причем 80% его возможностей). Все программы написаны на CFC и SFC (Именно сименсовской вариации).
А еще в более крупных системах используется финская система metsoACN (MetsoDNA/DamaticXDi).
Странно что фирму Metso в статье не упомянули. Одна из крупнейших в России ситем автоматизации построена именно на ее решениях.
Пакеты используются более комплексные и более тяжеловесные.
У нас например используют пакет проектирования Siemens PCS 7 v7.1 на части оборудования. (Не Step 7 а PCS, причем 80% его возможностей). Все программы написаны на CFC и SFC (Именно сименсовской вариации).
А еще в более крупных системах используется финская система metsoACN (MetsoDNA/DamaticXDi).
Странно что фирму Metso в статье не упомянули. Одна из крупнейших в России ситем автоматизации построена именно на ее решениях.
писать на LAD и FBD совершенно несложно, но шаг вправо/влево и задача превращается в сложить слово «вечность» из букв «у», «х», «й» :) В принципе, это справедливо и для CFC и SFC, для каждого языка грабли отличаются.
Опыт показывает, что лучше всего какие-то функциональные блоки написать на STL или SCL, и уже их засовывать в LAD или CFC.
Опыт показывает, что лучше всего какие-то функциональные блоки написать на STL или SCL, и уже их засовывать в LAD или CFC.
Возможности зависят от контроллера, обычно это где-то 20, 50, 250 мс, 1, 2, 3, 4, 5 с. Естественно, это не гарантирует выполнение кода именно за такой промежуток времени, нельзя большие программы пихать в цикл 20 мс, к началу следующего цикла предыдущий должен быть завершён.
Вот здесь в корне не соглашусь с автором. Весь смысл использования ПЛК для управления технологическими процессами как раз в том, что в отличии от обычных PC они как раз таки гарантируют выполнение кода за определенное кол-во времени.
Кроме того, система проектирования прост не даст положить тяжеловесную программу в организационный блок который выполняется за 20мс.
Контрпример — бесконечный цикл. Выполнится «за определенное кол-во времени»?
Собственно, если внутри ПЛК сидит РТОС, в которой пользовательская программа выполняется, и при программировании мы выбираем, в какой временной дорожке выполняется та или иная часть программы, то проблем ровно ноль. РТОС сама придушит бесконечный цикл по таймеру и даст выполниться остальной программе. И это справедливо для большинства ПЛК.
В лохматых 90-х разрабатывал модули для контроллеров. В процессорном модуле было две однокристалки, они обслуживали мелкую периферию (индикацию, обмен с ПК и т.п.) а сам процессор был на рассыпухе — он в каждом такте обрабатывал одну команду РКС (язык релейно контактных схем ;-). Я тогда по молодости стал спорить с его разработчиком по поводу целесообразности, он мне на пальцах доказал, что его нельзя заменить даже продвинутыми (в то время) 386 интелловскими процессорами :-)
Вот такая РТОС :-)
Вот такая РТОС :-)
Какой бесконечный цикл? И что вы вообще подразумеваете под циклом (while или for)? :)
Цикл работы в 20мс, 30мс и так далее заложен в ПЛК аппаратно.
Он будет прерван в любом случае, выполнена ваша программа или нет.
Не успела — извините.
Цикл работы в 20мс, 30мс и так далее заложен в ПЛК аппаратно.
Он будет прерван в любом случае, выполнена ваша программа или нет.
Не успела — извините.
Ну мы спорим об одном и том же, но в разных терминах. Просто я исхожу из того, что прерванная на середине программа не считается выполненной =)
Ну это уже на совести разработчика. А ПЛК гарантирует, что цикл будет выполнятся 20мс, не больше, не меньше.
Здесь нужно идти от обратного. Возьмем обычный ПК. Допустим вы написали программу которая может выполнится за 20мс и по требованиям должна выполнится. Обычный ПК с какой нибудь типичной ОС не даст вам однозначной гарантии. Может выполнит, а может заставит программу подождать, потому что ОС занимается чем то другим.
Здесь же, если вы поместили программу в 20мс цикл, то вы уверены, что ПЛК гарантированно выполнит ее за данное время и не отправит ее в режим ожидания, пока обрабатывается другая программа.
Вообще же к слову ни каких сложных вычислений и тем более ни каких программных циклов в таких программах там нет.
Обычно это опрос датчиков и выдача дискретной команды на управление.
Время вообще один из самых краеугольных камней в автоматизации. В непрерывных технологических процессах оно может стоить как поломки оборудования так и человеческих жизней.
Здесь нужно идти от обратного. Возьмем обычный ПК. Допустим вы написали программу которая может выполнится за 20мс и по требованиям должна выполнится. Обычный ПК с какой нибудь типичной ОС не даст вам однозначной гарантии. Может выполнит, а может заставит программу подождать, потому что ОС занимается чем то другим.
Здесь же, если вы поместили программу в 20мс цикл, то вы уверены, что ПЛК гарантированно выполнит ее за данное время и не отправит ее в режим ожидания, пока обрабатывается другая программа.
Вообще же к слову ни каких сложных вычислений и тем более ни каких программных циклов в таких программах там нет.
Обычно это опрос датчиков и выдача дискретной команды на управление.
Время вообще один из самых краеугольных камней в автоматизации. В непрерывных технологических процессах оно может стоить как поломки оборудования так и человеческих жизней.
Насчет ни меньше это вы зря, в плк реализуется циклический пуск процедур с необходимым временем, остальное зависит от объема кода, и если программа влезет в 1мс, то так и будет остальные 19мс страдать ерундой до следующего пуска. Опять же есть другая сторона, превышение времени выполнения… никаких гарантий, если вы творчески расписались, придется резать код или раздвигать цикл.
Ну и возможны варианты перезапуска по исполнению… сами понимаете время будет колебаться из-за вветвлений.
Ну и возможны варианты перезапуска по исполнению… сами понимаете время будет колебаться из-за вветвлений.
Нет. Siemens S7 1200, MITSUBISHI FX, подвисают на while(true); Митсубиши даже не вываливается по ошибке, сименс уходит в стоп и моргает ошибкой. И никакой RT OS там нет, обычная коопаеративная многозадачность в лучшем случае.
Не работал с S7 1200, но как пишет сам Сименс:
У нас на предприятии в цеху используются 4 контроллера S7 400H, и обслуживают они в общей сложности порядка 10 000 контуров. В 1200 на сколько я сылшал даже отдельная своя среда разработки и своя ОС, отличная от 300/400 серии.
SIMATIC S7-1200 представляют собой новое семейство микроконтроллеров, предназначенных для решения самых различных задач автоматизации малого уровня.
Контроллеры способны обслуживать от 10 до 284 дискретных и от 2 до 51 аналогового канала ввода-вывод
У нас на предприятии в цеху используются 4 контроллера S7 400H, и обслуживают они в общей сложности порядка 10 000 контуров. В 1200 на сколько я сылшал даже отдельная своя среда разработки и своя ОС, отличная от 300/400 серии.
Среда разработки на данный момент общая для все — TIA Portal. Ну а колличество входов — если мне надо 16 аналоговых и 100 дискретов — зачем мне S7 400, а вот что касается времени исполнения программы — у любого контроллера, в среде разработке, при присоединении к нему есть такая вкладка — Cicle Time, напишите пустую программу, проверьте, а потом залейте рабочий проект и проверьте еще раз.
Почему же общая? PCS используется в основном сейчас для 300/400 серии, и ни куда не собирается деваться в ближайшие 10 лет точно. Был весной на курсах в Московоском уечбном центре Siemens. Работали c PCS 7, TIA Portal упоминался лишь вскользь.
Я не утверждаю что вам нужен 400 контроллер. Я говорю о том, что это разные модели предназначеные для разных вещей. Может 1200 серию вы и подвесите while(true), на счет 400Н не уверен.
Я не утверждаю что вам нужен 400 контроллер. Я говорю о том, что это разные модели предназначеные для разных вещей. Может 1200 серию вы и подвесите while(true), на счет 400Н не уверен.
TIA Portal до сих пор не поддерживает S7-400H (Step7) и несколько экранов в WinCC.
А вы не пробовали на Сименсе вставить OB обработки соотвествующей ошибки? Если его нет, то валится в стоп, да. Если есть — выполняется даже пустой.
Так как еще нет кармы для того чтобы плюсануть, то просто напишу тут, что:
Поддерживаю.
Поддерживаю.
Нет, это может быть в каких то очень крутых контроллерах, но тоже маловероятно, обычно по мере роста программы цикл исполнения увеличивается.
К слову проверил с загруженным проектом на рабочем S7 400H.
Минимальное время цикла 17мс. В среднем прыгает пределах 14-20мс не более.
У нас нет в технологии процессов требующих время реакции менее чем 30мс.
В скомпилированном состоянии в ПЛК лежит программа в 6 мб.
На пустом увы проверить пока не могу, так как нет свободного ПЛК в наличии.
Но как появится, обязательно проверю, и за одно проверю, подвиснет ли он на бесконечной цикле while.
Минимальное время цикла 17мс. В среднем прыгает пределах 14-20мс не более.
У нас нет в технологии процессов требующих время реакции менее чем 30мс.
В скомпилированном состоянии в ПЛК лежит программа в 6 мб.
На пустом увы проверить пока не могу, так как нет свободного ПЛК в наличии.
Но как появится, обязательно проверю, и за одно проверю, подвиснет ли он на бесконечной цикле while.
Цикл прыгает, из за того что программа в PLC идет по разным веткам, из-за чего и изменяется время выполнения. Что полностью подтверждает то что я говорил.Что касается фиксированного времени выполнения, то судя по всему, контроллеры имеют какое-то предустановленное время, при превышение которого, исполнение программы просто останавливается, и контроллер вываливается в ошибку. У каждого контроллера это время разное.
не свалится. Надо только вставить в программу (и загрузить в контроллер) OB80.
Их там несколько разных OB на разные ошибки (превышение времени цикла, отвалившаяся периферия и т.д.). Соответственно, если возникает ошибка и в контроллер загружен блок обработки этой ошибки — контроллер выполнит этот OB. Если OB не загружен, то контроллер уйдёт в стоп.
Если обработка ошибок должным образом выполнена (или контроллеру дана индульгенция в виде пустых OB обработки ошибок) — уронить сименс в стоп не получится.
Их там несколько разных OB на разные ошибки (превышение времени цикла, отвалившаяся периферия и т.д.). Соответственно, если возникает ошибка и в контроллер загружен блок обработки этой ошибки — контроллер выполнит этот OB. Если OB не загружен, то контроллер уйдёт в стоп.
Если обработка ошибок должным образом выполнена (или контроллеру дана индульгенция в виде пустых OB обработки ошибок) — уронить сименс в стоп не получится.
На что уж я не избалован художественным видением этого мира, но всегда поражался, глядя на интерфейсы СКАДА-систем. Кровь же из глаз идет, даже у меня.
Ну ведь сама среда разработки позволяет и цвета выбирать, и элементарные «выровнять это по центру, а вот эти элементы распределить равномерно» обычно поддерживает.
Ан нет. В 90% случаев что-то типа «Вот тут у нас ярко-синим по ярко-красному мы напишем температуру, возьмем это еще в кислотно-зеленую рамочку с убогим бордюрчиком, ну и, конечно, выровняем значение не по центру, а руками и так чуть ниже и левее центра, чтобы уж вообще красиво было. А еще трубу мы до емкости 3 пикселя не доведем, и стык труб у нас будет тоже со смещением на пиксель — я сам видел, там сварщики именно так в реальности и сделали».
А вы говорите — дизайн, юзабилити… Эх.
Ну ведь сама среда разработки позволяет и цвета выбирать, и элементарные «выровнять это по центру, а вот эти элементы распределить равномерно» обычно поддерживает.
Ан нет. В 90% случаев что-то типа «Вот тут у нас ярко-синим по ярко-красному мы напишем температуру, возьмем это еще в кислотно-зеленую рамочку с убогим бордюрчиком, ну и, конечно, выровняем значение не по центру, а руками и так чуть ниже и левее центра, чтобы уж вообще красиво было. А еще трубу мы до емкости 3 пикселя не доведем, и стык труб у нас будет тоже со смещением на пиксель — я сам видел, там сварщики именно так в реальности и сделали».
А вы говорите — дизайн, юзабилити… Эх.
Рисуют это все программисты… Иногда приходится следовать корпоративным порядкам заказчика
www.fsk-ees.ru/upload/docs/STO_56947007-25.040.70.101-2011.pdf (стр.43)
Вы еще инструкции операторов не видели :)
www.fsk-ees.ru/upload/docs/STO_56947007-25.040.70.101-2011.pdf (стр.43)
Вы еще инструкции операторов не видели :)
Коллега, вы (Vijeo)Citect видели когда-нибудь?
Он сам по себе несколько странный, а вот за графический редактор его авторам точно гореть в аду. Там не предусмотрено возможности задать координаты и размеры элемента в его свойствах, введя конкретные цифры. Только мышкой.
А если, при этом, требуется сделать какие-то косметические поправки удалённо, через TeamViewer, например… Шоб этим австралийцам в аду гореть :)
Он сам по себе несколько странный, а вот за графический редактор его авторам точно гореть в аду. Там не предусмотрено возможности задать координаты и размеры элемента в его свойствах, введя конкретные цифры. Только мышкой.
А если, при этом, требуется сделать какие-то косметические поправки удалённо, через TeamViewer, например… Шоб этим австралийцам в аду гореть :)
меня всегда удивлял этот мир ПЛК, глядя на него со стороны Сишного пронраммиста МК некоторые вещи кажутся немного непонятными и смешными, хотя я понимаю что отработанные и неглючные решения тоже важны и нужны
Как человек, который касался и того, и того, могу сказать вот что: у ПЛК уровень абстракции от железа, конечно, выше. Но это и логично: инженер по автоматизации производства должен решать именно задачу автоматизации, а не разбираться с временной диаграммой работы, скажем, АЦП. Ему важнее понимать, что «вот на этот модуль у меня от датчика давления пришел унифицированный сигнал 4-20 мА», а уж как он там конкретно преобразуется в INT — дело, в общем-то, десятое. А инженер по эксплуатации хочет точно знать, что этот модуль не вынесет первым же разрядом, когда весенний первый гром, а как там эта защита конкретно реализована — для него это, опять же, дело десятое.
А если развить сравнение, то с таким же удивлением и непониманием на всех нас смотрят программисты, пишущие на еще более высоком уровне: как ни крути, но про ООП мы только слышали, про многопоточность — тоже, и нет у нас ни динамического выделения памяти, ни прочих благ и красот. И им наш мирок тоже кажется непонятным и зачастую смешным (впечатление сложено по итогам разговора с хорошим другом — разработчиком на Java).
А если развить сравнение, то с таким же удивлением и непониманием на всех нас смотрят программисты, пишущие на еще более высоком уровне: как ни крути, но про ООП мы только слышали, про многопоточность — тоже, и нет у нас ни динамического выделения памяти, ни прочих благ и красот. И им наш мирок тоже кажется непонятным и зачастую смешным (впечатление сложено по итогам разговора с хорошим другом — разработчиком на Java).
Интересно. А поподробней?
Порадовал контраст между интерфейсом на картинке для привлечения внимания и суровыми реалиями на иллюстрациях.
Да уж, выглядит очень стремно.
Предлагали мне как то написать программу для ПЛК овен
Я скачал софт CoDeSys, и тут я понял что попал в АД!
Мало того что интерфейс не интуитивен, непонятен, запутан, так еще и информации в интернетах по крупинке приходилось собирать.
В рунетах как то не принято писать статей по поводу ПЛК и их программирования, а если и пишутся, то примерно так же как и сама эта CoDeSys, запутанно.
В общем информации очень мало что к чему, форумы в основном закрытые, ресурсов посвященных этому мало.
Вероятно я плохо искал и мало знал, но субъективное мое мнение сложилось очень плохое по поводу всех этих скада.
p.s. Интересно, а какова сейчас вилка зарплат для асушников?
Предлагали мне как то написать программу для ПЛК овен
Выглядит как то так ПЛК овен
Я скачал софт CoDeSys, и тут я понял что попал в АД!
Выглядит как то так CoDeSys
Мало того что интерфейс не интуитивен, непонятен, запутан, так еще и информации в интернетах по крупинке приходилось собирать.
В рунетах как то не принято писать статей по поводу ПЛК и их программирования, а если и пишутся, то примерно так же как и сама эта CoDeSys, запутанно.
В общем информации очень мало что к чему, форумы в основном закрытые, ресурсов посвященных этому мало.
Вероятно я плохо искал и мало знал, но субъективное мое мнение сложилось очень плохое по поводу всех этих скада.
p.s. Интересно, а какова сейчас вилка зарплат для асушников?
Действительно, есть такая проблема. В основном нет информации в интернете потому, что все вопросы решаются в первую очередь через саппорт. Хорошая техподдержка является не самым последним критерием выбора оборудования и софта (при удовлетворении всех основных критериев, первый их которых — требования заказчика). Приличные интеграторы не гнушаются отправлять сотрудников на платные обучающие курсы, проводимые разработчиками или официальными дистрибьюторами. С одной стороны — если есть курсы и саппорт, лучше через них решать вопросы, а не искать/писать на форумах. С другой — кто ж будет задаром писать всё это на форумах, если они продают эти знания, и их реально покупают.
На одних таких курсах мне в ответ на замечание, мол, у вас тут в одном из ключевых диалогов жуткий косяк в юзабилити, на который я всё время попадался и наконец не выдержал и высказался, — кнопка «Отмена» (компиляции проекта) превращается в кнопку «ОК» (закрытия диалога после завершения компиляции и заливки проекта), мне сказали, мол, у нас тут такая охрененная система, а тебе ещё чота не нравится, пф! Так что да, «не интуитивен, непонятен, запутан» это зачастую комплимент в сравнении с остальными))
Вилка… субъективно, по хедхантеру, в больших городах (Мск, Спб) в среднем где-то на 30% меньше, чем программистам. Объективно (по нефтегазу) — чем ближе к объекту, тем больше, две крайности для примера: в проектном отделе выпустившийся студент без опыта — от 14к, специалист с опытом на северном месторождении (вахта) — около 100к.
На одних таких курсах мне в ответ на замечание, мол, у вас тут в одном из ключевых диалогов жуткий косяк в юзабилити, на который я всё время попадался и наконец не выдержал и высказался, — кнопка «Отмена» (компиляции проекта) превращается в кнопку «ОК» (закрытия диалога после завершения компиляции и заливки проекта), мне сказали, мол, у нас тут такая охрененная система, а тебе ещё чота не нравится, пф! Так что да, «не интуитивен, непонятен, запутан» это зачастую комплимент в сравнении с остальными))
Вилка… субъективно, по хедхантеру, в больших городах (Мск, Спб) в среднем где-то на 30% меньше, чем программистам. Объективно (по нефтегазу) — чем ближе к объекту, тем больше, две крайности для примера: в проектном отделе выпустившийся студент без опыта — от 14к, специалист с опытом на северном месторождении (вахта) — около 100к.
Вы знаете, CodeSys — это еще далеко не самый плохой вариант.
Есть еще куча самодельных сред для всяких ПЛК, производитель которых счел, что он и сам с усами.
Вот есть, например, такая EasyTools для контроллеров Carel. Так вот она при попытке скомпилировать такое:
вылетает с синим экраном без сохранения проекта.
В той же среде (там один-единственный язык — FBD) при рисовании линий, соединяющих функциональные блоки, нет привязки. То есть: не довел мышь на один пиксель — получи ошибку компиляции. Без детализации. В стиле «у блока № такой-то есть неподключенные линии». Если этих линий штук 40, попытка найти ту, которую плохо нарисовал — крайне нетривиальная задача.
Вот еще выше автор упоминал такую поделку, как Indusoft. Тоже склонна при нажатии «compile» вылетать с исключением, не сохраняя проект.
Так что — лучше уж CodeSys.
Есть еще куча самодельных сред для всяких ПЛК, производитель которых счел, что он и сам с усами.
Вот есть, например, такая EasyTools для контроллеров Carel. Так вот она при попытке скомпилировать такое:
int i = 100000;вылетает с синим экраном без сохранения проекта.
В той же среде (там один-единственный язык — FBD) при рисовании линий, соединяющих функциональные блоки, нет привязки. То есть: не довел мышь на один пиксель — получи ошибку компиляции. Без детализации. В стиле «у блока № такой-то есть неподключенные линии». Если этих линий штук 40, попытка найти ту, которую плохо нарисовал — крайне нетривиальная задача.
Вот еще выше автор упоминал такую поделку, как Indusoft. Тоже склонна при нажатии «compile» вылетать с исключением, не сохраняя проект.
Так что — лучше уж CodeSys.
Ваш коммент напоминает мне анекдот про то, как Рабинович по телефону Битлз напел :)
Оно всё довольно понятно, если иметь представление, что такое LAD(der) и как работает контроллер.
Информации на эту тему полно, вы таки плохо искали и мало знали. Тем более, что SCADA — это немного другое. Это визуализация процесса, а CoDeSyS — это среда разработки программы для контроллера.
Оно всё довольно понятно, если иметь представление, что такое LAD(der) и как работает контроллер.
Информации на эту тему полно, вы таки плохо искали и мало знали. Тем более, что SCADA — это немного другое. Это визуализация процесса, а CoDeSyS — это среда разработки программы для контроллера.
А с PLC контроллерами компании WAGO приходилось работать? Если да, то как они вам в сравнении с вышеописанными?
C братьями-близнецами Beckhoff работаем, модели BX, CX. По ассортименту модулей — рулез немереный по сравнению и с Сименсом, и со Шнайдером, и еще с чем-нибудь. На борту ПЛК чистый Ethernet (или еще тысяча интерфейсов на выбор). Модули ввода-вывода начиная от дискретных на разные напряжения (от 5 В) и заканчивая диммерами, ключами на МОСФЕТах и измерителями токов и напряжений, плюс модули сопряжения со всеми популярными полевыми шинами (от 232/485 до KNX, LON, Dali). Так что можно строить абсолютно любые системы, от ЧПУ станка до умного здания, и самое главное — все легко программируется и работает :)
Плюс к вышесказанному — просто нереальная для других ПЛК производительность — есть модели с процессорами вплоть до 2ГГц.
Есть не только полноценные «головы» типа CX, но и просто точки сбора данных (серия BK), которая цепляется с одной стороны к модулям ввода-вывода, а с другой стороны через тот же Ethernet к голове. Программа крутится на голове, а ввод-вывод может быть разнесен по всему объекту. И это все очень просто настраивается.
Есть не только полноценные «головы» типа CX, но и просто точки сбора данных (серия BK), которая цепляется с одной стороны к модулям ввода-вывода, а с другой стороны через тот же Ethernet к голове. Программа крутится на голове, а ввод-вывод может быть разнесен по всему объекту. И это все очень просто настраивается.
Отдельно хотел бы поблагодарить за статью, хотя бы узнал, чем занимался если пошел бы по специальности, появилась связь между теорией и как это реализуется на практике :)
Тем не менее, возникает ощущение, что рынок систем АСУТП развивается в некотором ваакуме по отношению к другим ИС и игнорирует необходимость развития сред разработки и юзабилити. Особенно впечатлен FBD, ровно то, что мы рисовали на листах в институте, рассчитывали импульсы…
Тем не менее, возникает ощущение, что рынок систем АСУТП развивается в некотором ваакуме по отношению к другим ИС и игнорирует необходимость развития сред разработки и юзабилити. Особенно впечатлен FBD, ровно то, что мы рисовали на листах в институте, рассчитывали импульсы…
Тоже думал на тему упомянутого развития «в вакууме» и пришел к такому выводу. Технологические процессы в массе своей — штука медленная. Это для нас 50 мс — немало, а среднестатистический вентилятор за это время едва оборот успеет сделать. Время отработки даже аварийных устройств, заслонок, например — всё равно измеряется секундами. А отсюда простой вывод: нет смысла наращивать быстродействие. Числодробилки 80-х годов разработки будет достаточно для 99% и сегодняшних задач.
А второй пункт — повышенные требования к надежности. Тот же Ethernet пришел в АСУТП совсем недавно — когда его уже обсосали со всех сторон в порядке, скажем так, бытовой эксплуатации. И именно из-за этих требований, если вывести на рынок абсолютно новую, передовую и вообще клевую среду разработки, многие инженеры отнесутся с изрядным недоверием — а вдруг оно глючит? Порой ставки слишком высоки, как писал выше тов. Vikond.
А второй пункт — повышенные требования к надежности. Тот же Ethernet пришел в АСУТП совсем недавно — когда его уже обсосали со всех сторон в порядке, скажем так, бытовой эксплуатации. И именно из-за этих требований, если вывести на рынок абсолютно новую, передовую и вообще клевую среду разработки, многие инженеры отнесутся с изрядным недоверием — а вдруг оно глючит? Порой ставки слишком высоки, как писал выше тов. Vikond.
Надежность в АСУТП всегда на первом месте.
Тот-же «медленный» профибас ГАРАНТИРУЕТ, что каждое устройство получит возможность передать информацию через заранее известное время.
А вот гарантирует ли передачу информации Industrial Ethernet вопрос. И на него я не мог получить ответа (не мог 2 года назад, больше не интересовался) даже у Сименса.
Я так понял, что гарантия передачи информации по Ethernet зависит напрямую от скорости соединения.
Тот-же «медленный» профибас ГАРАНТИРУЕТ, что каждое устройство получит возможность передать информацию через заранее известное время.
А вот гарантирует ли передачу информации Industrial Ethernet вопрос. И на него я не мог получить ответа (не мог 2 года назад, больше не интересовался) даже у Сименса.
Я так понял, что гарантия передачи информации по Ethernet зависит напрямую от скорости соединения.
Лично мне бы очень интересно было бы почитать про встроенные средства защиты SCADA — в частности, по методикам проверки корректности поступающих данных, контролю целостности самой себя, средств журналирования, встроенных средств разграничения доступа, возможностях работы из-под пользовательских учетных записей.
Окей, хорошая тема.
Дык. Сам в это упираюсь регулярно. Я — безопасник по АСУ ТП. И мне остро не хватает взгляда с той стороны.
И наоборот — реальные АСУТПшники не понимают потребностей безопасников напрочь — и не любят их (и в чем-то я их понимаю).
Но законы есть законы, и volens nolens придется дружить и сосуществовать.
И наоборот — реальные АСУТПшники не понимают потребностей безопасников напрочь — и не любят их (и в чем-то я их понимаю).
Но законы есть законы, и volens nolens придется дружить и сосуществовать.
А я расскажу, за что АСУТПшникам не любить безопасников.
Во-1, производители средств автоматики очень любят разные проприеритарные протоколы, нестандартные (с точки зрения безопасников) порты, протоколы (UDP всякие, ISO) — а безопасники очень любят блокировать абсолютно всё, без чего могут существовать офисные хомячки. В результате мы имеет то, что связь либо не работает совсем, либо работает с совершенно необъяснимыми глюками. Я уж не говорю о том, что безопасники очень любят блокировать средства удалённого доступа — такие как VPN, TeamViewer, LogMeIn и RDP. А автоматчик к объекту цепью не прикован. И вот, как обычно, случается ЧП ночью в выходные, тебя будят в тёплой постельке, а ты даже масштаб бедствия оценить не можешь. Потому, что со слов эксплуатации — «оно само», а зайти посмотреть логи — никак…
Вот и получается, что безопасники, в сущности, втыкают палки в колёса. Абсолютно все, какие только можно воткнуть. И безопасникам никто за это голову не морочит. А когда автоматика не работает или работает странно (по причине тех самых плавающих глюков) — по голове получают автоматчики, и получают сильно. А безопасникам — хоть бы хрен.
Во-1, производители средств автоматики очень любят разные проприеритарные протоколы, нестандартные (с точки зрения безопасников) порты, протоколы (UDP всякие, ISO) — а безопасники очень любят блокировать абсолютно всё, без чего могут существовать офисные хомячки. В результате мы имеет то, что связь либо не работает совсем, либо работает с совершенно необъяснимыми глюками. Я уж не говорю о том, что безопасники очень любят блокировать средства удалённого доступа — такие как VPN, TeamViewer, LogMeIn и RDP. А автоматчик к объекту цепью не прикован. И вот, как обычно, случается ЧП ночью в выходные, тебя будят в тёплой постельке, а ты даже масштаб бедствия оценить не можешь. Потому, что со слов эксплуатации — «оно само», а зайти посмотреть логи — никак…
Вот и получается, что безопасники, в сущности, втыкают палки в колёса. Абсолютно все, какие только можно воткнуть. И безопасникам никто за это голову не морочит. А когда автоматика не работает или работает странно (по причине тех самых плавающих глюков) — по голове получают автоматчики, и получают сильно. А безопасникам — хоть бы хрен.
Защита от сбоев — дублирование. На некоторых моделях ПЛК есть защита от перепрограммирования по паролю. В серверной части тоже парольная защита, логи свои и системные. В остальном защита навесная — антивирь, изолированные влан, отсутствие физического доступа у посторонних к системным блокам (в том числе и у операторских станций, операторам доступен монитор, да мышка с клавой), ключ от серверной под роспись и т.п.
Спасибо, я в курсе, как это делается сейчас. И делается это (чаще всего) с закрытием глаз на половину требований.
Я хочу узнать, как это можно делать.
Потому как, скажем, «Общие требования по обеспечению безопасности информации в ключевых системах информационной инфраструктуры» от 18 мая 2007 года устанавливают требования к КСИИ не ниже 1Г (вплоть до 1Б в ряде случаев), а это, среди прочего, таки контроль целостности и очистка памяти. А АСУТП кое-каких объектов (транспорт, ТЭК, например) — вполне себе КСИИ.
Это можно делать наложенными средствами, да только очистка памяти начинает резко тормозить работу АРМ вплоть до (в сильно отдельных случаях) полного останова. Контроль целостности тоже производительности машине не добавляет.
Антивирус — это прекрасно, да только до обновления баз на боевой системе базы нужно обкатывать на тестовой зоне (чтобы он критичный файл не съел и трафик вдруг не перекрыл) — а в АСУ ТП далеко не каждого объекта есть такие зоны. И в редкие проекты они закладываются.
Я и хочу понять АСУТПшников, что могут сделать они, а что можем сделать мы — чтобы жить вместе долго и счастливо, а не лаяться, как сейчас, и не строить козни друг другу. Потому как ему нужна рабочая система, а мне — выполнение действующих норм. И есть шансы разобраться вместе и договориться полюбовно. Встроенные средства в этом плане лучше наложенных.
Я хочу узнать, как это можно делать.
Потому как, скажем, «Общие требования по обеспечению безопасности информации в ключевых системах информационной инфраструктуры» от 18 мая 2007 года устанавливают требования к КСИИ не ниже 1Г (вплоть до 1Б в ряде случаев), а это, среди прочего, таки контроль целостности и очистка памяти. А АСУТП кое-каких объектов (транспорт, ТЭК, например) — вполне себе КСИИ.
Это можно делать наложенными средствами, да только очистка памяти начинает резко тормозить работу АРМ вплоть до (в сильно отдельных случаях) полного останова. Контроль целостности тоже производительности машине не добавляет.
Антивирус — это прекрасно, да только до обновления баз на боевой системе базы нужно обкатывать на тестовой зоне (чтобы он критичный файл не съел и трафик вдруг не перекрыл) — а в АСУ ТП далеко не каждого объекта есть такие зоны. И в редкие проекты они закладываются.
Я и хочу понять АСУТПшников, что могут сделать они, а что можем сделать мы — чтобы жить вместе долго и счастливо, а не лаяться, как сейчас, и не строить козни друг другу. Потому как ему нужна рабочая система, а мне — выполнение действующих норм. И есть шансы разобраться вместе и договориться полюбовно. Встроенные средства в этом плане лучше наложенных.
Может мы друг друга не понимаем, но контроль целостности: есть два сервера, они зеркалят друг друга, нарушение целостности критических фалов скады приведёт к сообщению о потере синхронизации, на которое реагирует сменный персонал. Можно поставить файловый монитор, который будет проверять чексуммы файлов (тех, которые не изменяются). Если пересчитывать чексуммы постоянно изменяющихся файлов (особенно файлы БД), а потом смотреть правило что для этих файлов не показывать ошибку — то конечно будет падать производительность.
Сам проект, алгоритмы в скаде и в ПЛК, есть контроль на уровне какая версия проекта сейчас залита.
А очистка памяти — от чего очищать, если сервер работает годами без перезагрузки, и оперативка используется почти вся.
Сам проект, алгоритмы в скаде и в ПЛК, есть контроль на уровне какая версия проекта сейчас залита.
А очистка памяти — от чего очищать, если сервер работает годами без перезагрузки, и оперативка используется почти вся.
А как Вы будете определять, который из двух несовпадающих конфигов — некорректный? Ручками?
В системах с высокой надежностью обычно ставят три независимых контура, и совпадение по двум контурам считается правдой.
Файловый монитор — это и есть по сути упрощенный контроль целостности. Только для него зеркалирование не нужно. Это иной принцип обеспечения надежности.
Скада свое содержимое проверяет на изменение? Если я перехвачу работу с памятью — она это обнаружит? Если я сяду на канал и начну гнать неверные показания датчиков — она это почувствует?
Очистка памяти — это нормативное требование. Программа отдала обратно кусок памяти — в него по определенному алгоритму должна быть записана информация — чтобы по остаточным следам ее добыть было нельзя. Это касается и жестких дисков, и оперативки.
Я тоже не понимаю, зачем оно в КСИИ — но есть требования, утвержденные на федеральном уровне — и хоть тушкой, хоть чучелком, но их надо либо выполнять, либо обходить. И это уже зависит от степени занудности надзорных органов
В системах с высокой надежностью обычно ставят три независимых контура, и совпадение по двум контурам считается правдой.
Файловый монитор — это и есть по сути упрощенный контроль целостности. Только для него зеркалирование не нужно. Это иной принцип обеспечения надежности.
Скада свое содержимое проверяет на изменение? Если я перехвачу работу с памятью — она это обнаружит? Если я сяду на канал и начну гнать неверные показания датчиков — она это почувствует?
Очистка памяти — это нормативное требование. Программа отдала обратно кусок памяти — в него по определенному алгоритму должна быть записана информация — чтобы по остаточным следам ее добыть было нельзя. Это касается и жестких дисков, и оперативки.
Я тоже не понимаю, зачем оно в КСИИ — но есть требования, утвержденные на федеральном уровне — и хоть тушкой, хоть чучелком, но их надо либо выполнять, либо обходить. И это уже зависит от степени занудности надзорных органов
Для определения который из двух несовпадающих конфигов некорректный — у инженера отдельно хранится последняя актуальная версия. Можно использовать систему контроля версий и там защитить по полной.
Если перехватите работу с памятью на одном из серверов и начнёте изменять данные — перехватит как расхождение синхронизации серверов.
Сядете на канал как? Физически на канал 4-20 мА? Или тоже перепишете память одного из контроллеров — расхождение синхронизации контроллеров. Прогрузить одновременно два контроллера — загрузка новой прошивки много дольше времени исполнения цикла, авария случится. Поэтому проект загружают поочереди на каждый контроллер под звуки соответствующего оповещения, предупреждая оператора чтобы не пугался.
Поковыряйте архитектуру АСУТП — два сервера, читают данные из двух контроллеров. Между серверами heartbeat, и между контроллерами heartbeat. Что либо перестаёт откликаться — переходим на резерв с оповещением.
Если обсуждать что это гостребование и хоть разбейся но выполни, то адекватного диалога не получится — требования не адекватны. Готового решения вам тут не скажут, кому охота чтобы надзорные органы знали как обходят их требования.
Если перехватите работу с памятью на одном из серверов и начнёте изменять данные — перехватит как расхождение синхронизации серверов.
Сядете на канал как? Физически на канал 4-20 мА? Или тоже перепишете память одного из контроллеров — расхождение синхронизации контроллеров. Прогрузить одновременно два контроллера — загрузка новой прошивки много дольше времени исполнения цикла, авария случится. Поэтому проект загружают поочереди на каждый контроллер под звуки соответствующего оповещения, предупреждая оператора чтобы не пугался.
Поковыряйте архитектуру АСУТП — два сервера, читают данные из двух контроллеров. Между серверами heartbeat, и между контроллерами heartbeat. Что либо перестаёт откликаться — переходим на резерв с оповещением.
Если обсуждать что это гостребование и хоть разбейся но выполни, то адекватного диалога не получится — требования не адекватны. Готового решения вам тут не скажут, кому охота чтобы надзорные органы знали как обходят их требования.
Вот в том и проблема, что вы не понимаете, зачем мы лезем в потроха, а мы не уверены, что этих потрохов достаточно.
Представил я себе, как автор вопроса внедрится в S7-400H, и подменит там программу в обоих контроллерах (3 раза ха) :))
На всякий случай, разверну мысль. S7-400H — это физически дублированный контроллер. Две половинки, связанные оптической пуповиной. Обновление программы происходит следующим образом: останавливаем один контроллер (пожалуйста, у нас уже без палева в логах есть информация о том, что один контроллер встал), загружаем в него новую программу и просим (именно, никак иначе) систему перейти с одного контроллера на другой. И никогда на 100% заранее не знаешь, что система ответит. А есть 2 варианта: переход возможен (и он выполняется) либо переход невозможен: контроллер, по своим соображениям, считает, что изменения слишком большие и требуется полная остановка, загрузка обеих половинок и рестарт.
Или внедриться на Profibus (закрытый протокол) и слать левые данные… Конечно, если это получится, я сниму (и, возможно, даже съем) свою шляпу. Но я искренне не понимаю, зачем такие сложности. Есть уйма более простых, надёжных, дешёвых и быстрых способов поставить производство раком. В большинстве случаев это называют человеческим фактором :))))
На всякий случай, разверну мысль. S7-400H — это физически дублированный контроллер. Две половинки, связанные оптической пуповиной. Обновление программы происходит следующим образом: останавливаем один контроллер (пожалуйста, у нас уже без палева в логах есть информация о том, что один контроллер встал), загружаем в него новую программу и просим (именно, никак иначе) систему перейти с одного контроллера на другой. И никогда на 100% заранее не знаешь, что система ответит. А есть 2 варианта: переход возможен (и он выполняется) либо переход невозможен: контроллер, по своим соображениям, считает, что изменения слишком большие и требуется полная остановка, загрузка обеих половинок и рестарт.
Или внедриться на Profibus (закрытый протокол) и слать левые данные… Конечно, если это получится, я сниму (и, возможно, даже съем) свою шляпу. Но я искренне не понимаю, зачем такие сложности. Есть уйма более простых, надёжных, дешёвых и быстрых способов поставить производство раком. В большинстве случаев это называют человеческим фактором :))))
ГОСТы и прочие требования очень часто пишут люди, которые не вполне представляют, что осуществимо, а что — нет. Бывает, такого понапишут…
Дык. Сам в это упираюсь регулярно. Я — безопасник по АСУ ТП. И мне остро не хватает взгляда с той стороны.
И наоборот — реальные АСУТПшники не понимают потребностей безопасников напрочь — и не любят их (и в чем-то я их понимаю).
Но законы есть законы, и volens nolens придется дружить и сосуществовать.
И наоборот — реальные АСУТПшники не понимают потребностей безопасников напрочь — и не любят их (и в чем-то я их понимаю).
Но законы есть законы, и volens nolens придется дружить и сосуществовать.
:)))
А я вот категорически не дружу с безопасностью. Мне проще (в самом крайнем случае) снести и переставить к чёрту винду на компе с нуля, намазать офис и VMware и вернуться к работе.
Просто, помимо серьёзного железа приходится иметь дело со всяким дешёвым говном, авторы которого знают толк визвращениях хитрых коммуникациях через любопытный порт, который чем-то не нравится антивиру. А ты сиди и ломай башку полдня, почему ж никак не получается до этой чёртовой железки достучаться…
А я вот категорически не дружу с безопасностью. Мне проще (в самом крайнем случае) снести и переставить к чёрту винду на компе с нуля, намазать офис и VMware и вернуться к работе.
Просто, помимо серьёзного железа приходится иметь дело со всяким дешёвым говном, авторы которого знают толк в
а почему не упомянули LabVIEW? для АСУТП очень широко применяется.
Sign up to leave a comment.
Промышленное программирование, или Пара слов об АСУ ТП