Pull to refresh

Comments 43

Пытаюсь понять что такое программный алгоритм. Это что-то типа software-defined algorithms? Когда алгоритм — это программа, по которой пишут программы? Мой мозг дымится, пытаясь себе представить абстрактный класс, инстансы наследников которого являются фабриками классов, чьи инстансы являются алгоритмами. Или, лучше, генераторами алгоритмов?
В данном контексте, программный алгоритм — это программная реализация алгоритма.
Звучит как речекряк, честно. И остальное тоже травмирующе. «Приложенный файл» с расширением rar? В 2016 году? Srsly? Без ссылки на github или иной хостинг кода?
Постарался учесть замечания. А на счет хостинга кода, то в данной статье это излишне.
Инженеры, программирующие в МЭК и github? Вы серьезно?
Это другая вселенная. В АСУП обмен архивами в rar — это нормально, а github — наоборот нет.
Низкая культура software engineering, да. Уютное болотце, пока туда не придёт новый дерзкий бизнес, не посмотрит на протекающие мимо деньги с прищуром, и не заменит -цать старых инженеров парочкой хипстеров. Все будут стонать про новый ужас (а-ля докер), но так как своих практик нормальных не придумано, будут вынуждены жрать что дали, или сваливать с рынка по хронической неэффективности.
Вас, видимо, действительно что то травмировало.
Плохие практики — да, травмировали. Версии кода в архивах на почту, редактирование кода прямо на сервере в продакшене, отсутствие малейших следов контролируемой среды исполнения (какие должны быть зависимости? Как сделать такой же сервер с нуля?).

Оно всё «работает, не трогай», пока не приходят новые и дерзкие, которые это дело вжик-вжик, и делают правильнее эффективнее.
Ох уж эти истории про дерзких и дэффективных.
Это на рынке СКАД ещё как-то можно повыделываться и порулить местами как хочется. И то большинство далеко от стандарта OPC не отходят. А это автоматом тащит на себя одеяло винды, разной степени несвежести. Но альтернатива — жёсткий хард-кодинг драйверов под десятки систем и сотни приборов.
А что дерзкий будет делать с замкнутой на саму себя экосистемой железо-софт? Да ещё в условиях тяж. промышленности, госзаказа, дикого распилинга и откатинга с просранным дедлайном?
Эффективность показывать? Мужики засмеют.
Если сверху протолкнули ОВЕН, внедряют его. Если Сименс или Омрон, то нет времени эффективностью меняться. А бывает вообще неведому зверушку в ТЗ прописывают. И только МЭК- совместимость позволяет не заплакать кровавыми слезами.
И тут уж плевать на кривость и убогость среды разработки. Подсветка синтаксиса есть -уже хорошо. Компилит и заливает в прибор без бубна — и то радость.
В условиях госзаказа — ничего не будет делать, всё хорошо. Просто настолько хорошо, что невозможно себе представить.

А вот в условиях открытого рынка может оказаться, что юные резкие дерзкие просто делают кратно дешевле. Или делают такое, что старички всегда говорили что нельзя и слишком много мороки.

Оно всегда происходит, все индустрии в какой-то момент надламываются и меняются. Или просто меняются.

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

Разумеется, Россию в текущем варианте это не касается — я, скорее, про общечеловеческое. Не думаю, чтобы инженеры у Маска пользовались почтой с архивами с исходниками при работе над софтом для gigafactory…
UFO just landed and posted this here
Ну, если мы обсуждаем только отсутствие сложившейся практики версионной разработки в средах программирования приборов АСУП, то это в основном болезнь самих сред разработки. Ну не реализуют компании разработчики этот функционал, хоть и существует большинство из них на рынке не один десяток лет. Беда в закрытой экосистеме. Нет свободы выбрать для разработки прикладного софта приглянувшийся пакет. Нельзя взять VisualStudio или NetBeans или на Eclipse пописать. Пиши там где позволили. Люди, имеющие опыт в программировании, конечно пытаются какую-то версионность организовать хотя бы на уровне бинарных файлов проектов. Но это все костыли.

А если вести речь о глобальном, то, как говорится, для революции необходимо, что бы верхи не могли, а низы не хотели жить по старому. Пока, на мой взгляд, точка бифуркации не достигнута. Хоть низы и ропщут, но верхи пока в силе.
Кстати по поводу инженеров ГигаФабрик.
Я уверен, что никто инженерные системы проектировать с нуля там не собирается. Зачем изобретать велосипеды и потерять время не успев выйти на рынок первыми. Будут ставить на инженерку готовые промышленные решения. Honeywell'а какого-нибудь или кто там для американцев актуальнее. А исполнительная часть потащит прицепом свою же автоматику. Автоматика потащит софт. И будут Инженеры Маска как миленькие писать так же как и по всему миру пишут. И никто особо кряхтеть не будет. Привыкли уже.
До тех пор, пока их будет мало. А потом один из них придёт к Маску и скажет, что он может сэкономить компании сколько-то много денег, повысив эффективность работы дорогих инженеров, и нужно ему всего-то сколько-то спецов и сколько-то времени.

А потом все спохватятся и будет баззворд и кипеш среди отстающих.

То есть тут простой вопрос эффективности труда. Сопротивляться можно сколько угодно, но если одна практика даёт тот же результат за N часов работы, а другая за N/2, то рынок расставит всех по местам.
Часто там и нельзя иначе. Когда нет кода, а есть проприетарные бинарные форматы или дикий и незамутнённый xml, где перемешано расположение элементов fbd на экране и логические связи между ними, VCS вида cp project project-bkp-`date +%F-%H%M` становится реальностью, к сожалению. И это в лучше случае; часто и этого нет.
А возможно ли бороться с помпажом не отключая двигатель? Что будет, если менять напряжение на том же двигателе, разово или синхронно с паразитными колебаниями?
Можно пойти еще дальше и на первом же пересечении попробовать остановить помпажное состояние, управляя исполнительными механизмами дроссельной заслонки и помпажного клапана.
Бороться с помпажом всегда есть возможность. Но когда программные реализации не успевают отработать начавшийся помпаж и он (компрессор) входит в устойчивые колебания, то со стороны механики щадящим будет отключение, чем вывод компрессора из этого не устойчивого состояния.
К тому же на таких компрессорах редко ставятся управляемые приводы. В основном это высоковольтные двигатели прямого включения в сеть.
останов технологии, работу которой и обеспечивает компрессор, вас вообще не смущает?
Нет, так как в промышленности, на этот случай всегда есть резерв. Второй компрессор, стоящий «под парами», как раз для таких аварийных отключениях основного. Время перехода составляет от нескольких минут до получаса, что на технологии практически никак не сказывается. К тому же ремонт компрессора, может стать дороже небольшого простоя технологии.
Я имел дело с такими компрессорами. Замечания:
1) На выходе компрессора обычно стоит ресивер. Который обеспечивает запас воздуха на 5-10 минут.
2) Всегда в горячем резерве стоят 1-2 резервных турбокомпрессоров. С возможностью немедленного пуска в течении 1-2 минут.
3) У нас стояло несколько поршневых компрессоров для аварийного режима работы. Если по каким-то причинам пуск резервных турбокомпрессоров оказался невозможен — отключение некритических потребителей воздуха + пуск поршневых. Поршневые нередко пускались на момент переключений турбокомпрессоров. Для подстраховки.
4) Турбокомпрессор обязательно имеет байпас. Который при снижении расхода просто приоткрывался. Ручками или регулятором. Загнать в помпаж — это очень постараться нужно. Но можно. А потом получить по ушам…
5) Бороться с помпажем не нужно! В принципе. Загнали в помпаж — отключаем и выводим в ремонт. А резервный стартуем. Без вариантов. Вскрываем и смотрим подшипники. И все остальное. Вам приходилось видеть как разорвало ротор такого турбокомпрессора? Как куски стали/чугуна летали по цеху? Я видел. Не понравилось…
6) Гнать нужно программистов из цеха. Неоднократно убеждался — будет только плохо. Нужен «инженер по автоматизации» с многолетним стажем. И повезет если программер только оборудование угробит, а не людей вокруг. Ибо производство имеет кучу не очевидных нюансов и особенностей, которые просто не принимаются во внимание.
Этак реальная картина на производстве. Я с ней полностью согласен, за исключением:
5) Бороться с помпажем не нужно! В принципе. Загнали в помпаж — отключаем и выводим в ремонт.
На счет бороться, то да смысла нет городить сложные системы, обеспечивающие безпомпажную эксплуатацию во всех режимах, но детектировать начавшийся помпаж необходимо автоматически, с малым временем реакции.Так как реакция машиниста на помпаж может достигать приличных временных отрезков.
а банальное срабатывание АВР, тоже приведёт к срабатыванию блокировки?
Нет, так как просадка и снова всплеск тока будет, но вот колебаний, в 7-8 значений на протяжении небольшого периода 2-3 секунды, не будет.
Антипомпажный клапан с регулятором, при приближении к границе помпажа, подают часть потока с выхода на вход компрессора, КПД падает, но в качестве защиты подходит.
Все остальные типы защит никто не отменял. Все они имеют место быть. Но из-за инертности механизма или его непредвиденной неисправности, такая защита не сработает.
Вы изобретаете велосипед, созданный более полувека назад. Существует метод вибродиагностики под названием анализ огибающей. Если на пальцах, то можно сделать так. Берете сигнал с катушки токового трансформатора приводного двигателя и выпрямляете диодным мостом. Выпрямленный сигнал режете ФНЧ 10 Гц и подаете на простейший спектроанализатор. Который либо «видит» колебания с частотой 1 Гц, либо не видит. Понимаю, что четыре диода, емкость и индуктивность это низкий стиль. Но, это работает.
Понимаю, что аналоговая схемотехника тоже сможет справится с такой задачей, но в современных реалиях, когда АСУ основываются на ПЛК, и сигнал тока обязательный в ней параметр, то использование такого «велосипеда» как защиту компрессора от помпажа вполне обоснованное решение. А на счет стандартного сигнала с токового трансформатора, то мне кажется амплитуды для открытия 2-х диодов будет не достаточно.
Без синхронного детектора не обойтись? Знаю один секретный метод. Добавить витков в токовый трансформатор. И всё откроется.

Вы собирали в детстве простейший детекторный радиоприёмник?
Радио не собирал, я в детстве радиоэлектроникой увлекался только в рамках школьной программы. А добавить витков в готовое устройство, трансформатор тока, например 250/5 А и 10 кВольтовой изоляцией очень проблематично.
Напрасно не собирали. В детекторном радиоприемнике есть и выделение огибающей, и спектроанализатор:)

Следующий вопрос. Вы не пытались получить сигнал прямым измерением? Например, поставить в трубопроводы пару преобразователей давления в ток(solid state pressure transducer, не знаю, как это по-русски)? Как только начнет «хлопать», помпаж и услышите. Не?
И этот способ имеет место быть, но они капризные довольно. И иногда ложные срабатывания частят, например в осенне-весенний период. А в общем дублирование никогда не вредило общей концепции.
Если датчик давления «капризный», значит установлен неправильно. Или сигнальный кабель проложен альтернативно рекомендациям производителя. Вы ведь сигнальные кабеля вместе с силовыми на 10кВ одим пучком не прокладываете?
Вы ведь сигнальные кабеля вместе с силовыми на 10кВ одим пучком не прокладываете?
Нет конечно. Но токовый трансформатор преобразует ток/ток, а датчик давления — давление/ток или напруга. В датчике давления используются различные элементы преобразования, отличные от простого и надежного так сказать трансформатора. Значит и слабых мест у них больше.
Ага. Там в трубе много громких звуков на частотах от 500 до 5000 Гц. И датчик давления может от этих колебаний устать, натурально. Здесь нужно свежее решение! Цифровой фильтр или кусок поролона/войлока. Не?

Кстати, и токовый трансформатор преобразует «всё что слышит», вплоть до 10кГц. Вы это тоже «цифровым фильтром» режете?
10 кГц если они и есть, режет нормализатор (преобразователь) сигналов до аналогового входа ПЛК.
Эмм, а вы случаем ресурсом не ошиблись? (geektimes или другой специализированный ресурс подошёл бы лучше)
Я смотрел на теги на geektimes. Так вот на Хабре эти теги более близки к теме топика. Ближе всего «промышленное программирование».
UFO just landed and posted this here
А это в каких компаниях все такие отделы есть, если не секрет?
UFO just landed and posted this here
Спасибо. Я про то, что если ограничиться таким определением промышленного программирования, то на хабре наверное скучно будет.
А я только за статьи, подобные этой. Не одним интернет-корпоративным-программированием мир держится. На самом деле вся железная часть Хабра и Гиктаймса заканчивается на Ардуино-и-прочие. А, как человек, связанный с автоматизацией систем отопления, я только поприветствую умные статьи о PLC, программируемых реле, CoDeSys, Symens STEP и др.
Sign up to leave a comment.

Articles