Комментарии 50
Это еще что. Первые процессоры этой линейки были сделаны на советской элементной базе (типа, КР1847). На гетинаксовых платах и местами навесном монтаже. Вот где была жесть и низкая надежность, операционка — DOS 5.0 и системное ПО на ассемблере. Но это работало и поговаривают, что кое-где работает до сих пор. Дублирование и ЗИП творят чудеса.
Авиация, как мы уже знаем, далеко от наземных «ответственных применений» с их особенностями, не ушла.
Самая распространенная — неправильное использование нормально-открытых и нормально закрытых контактов и исполнительных механизмов. Например: датчик верхнего предельного уровня конденсатора. Служит для защиты лопаток турбины в случае подъема уровня конденсата в конденсаторе. Использован нормально-открытый контакт. Т.е, пока датчик не сработает — ток по цепи не течет, реле разомкнуты, входы ПЛК не активны. А это значит, что в случае обрыва кабеля, перегорания реле, да и просто винтика, раскрутившегося от вибрации, сигнал от датчика не дойдет до места назначения. Для таких датчиков допускается использование только нормально-закрытых контактов на всем пути следования сигнала.
Аналогичный случай и с аварийным стопорным клапаном. Пока на катушку этого клапана не будет подано напряжение — он не сработает. А функция этого клапана весьма значительна — остановить подачу пара в случае любой нештатной ситуации.
Зато заменить в ходу любой из аналоговых датчиков нельзя. Отключение любого из них вызывает остановку. Даже второстепенных. И нет никакой возможности ручного отключения этой защиты. Вот и приходится по 2-3 месяца работать с неисправными датчиками.
С нетерпением жду окончания гарантии для исправления всех этих косяков. Регулятор нагрузки уже переписал втихую, так как скачки по 200-300 кВт терпеть не было сил.
Просто в силу сложности отладки и тестирования (попробуйте 100%-но протестировать код для рабочей ГЭС), рефакторинг в таких вещах делается очень редко и только в экстремальных случаях — как говорится "не пытайся улучшить то, что и так работает — можешь сломать".
В тех компаниях, где на процессе тестирования экономят — там в основном и встречаются эти проблемы. Где же не экономят и переходят к новым методам разработки (например тот же Model Based Design) с этим гораздо лучше
Статья от 2013, о чем сказано в самом конце. Комплектующие были закуплены и того раньше.
На новые внедрения — безусловно. Но это уже другие отечественные компании. Сегодня все в разы серьезнее. Разрабатываются не просто свои процессорные модули, но и SoC собственной разработки. Только это не так пиарится, как байкалы с эльбрусами.
Учитывая, что первая центральная электростанция была запущена в 1882 году, не удивительно, что все управление было механическим, довольно продолжительное время до наступления эры электроники.
Нередко на одной станции встречаются несколько поколений одного и того же ПТК. Иногда даже приходится интегрироваться со своим же софтом десятилетней давности.
Такое вот "работает — не трогай" на максимальных настройках.
Насколько я знаю, все шкафы с оборудованием заземляются обязательно. Все, что приходит с поля обязательно гальванически развязывается. Иногда потеря земли или даже некачественная земля приводят к трудно уловимым и невоспроизводимым глюкам в работе. Так что уверен, что все без исключения заземляется, причем не однократно.
Он имеет смысл только при большом числе интеллектуальных датчиков и исполнительных механизмов. Как правило, на крупных локальных объектах автоматизации датчики и ИМ либо аналоговые и связь с ними по меди, либо поддерживают Modbus или Profibus в лучшем случае. Верхний уровень так же в основном по устоявшимся протоколам работает, типа OPC UA. Так что у нас с IIoT не очень развит.
Можете написать подробнее о характеристиках ПЛК в данном применении?
- сколько входных/выходных сигналов он способен обработать и с какой частотой опроса?
- какова длительность рабочих циклов исполнительной программы, сколько их? Какую вообще минимальную длительность цикла данный контроллер способен реализовать?
- какова загрузка процессора на момент сдачи в эксплуатацию
Помимо этого интересно знать — используете ли вы симуляцию, чтобы отладить ПО контроллера до того, как запустить на объекте.
сколько входных/выходных сигналов он способен обработать и с какой частотой опроса?
Давно дело было. Уже плохо помню точные цифры. Если память не подводит, то локальных модулей УСО можно было до 16 добавить + 4 модуля интерфейсной связи с корзинами, в каждой из которых снова до 16 модулей. Максимальное число дискретов (с групповой развязкой) в одном модуле — 16. Максимальное число аналогов — 8. Итого получается 16*5*16 — 1200 дискретов или 640 аналогов. Примерно так, но это не точно.
какова длительность рабочих циклов исполнительной программы, сколько их? Какую вообще минимальную длительность цикла данный контроллер способен реализовать?
Число параллельно исполняемых ресурсов в контроллере не ограничивалось, но разумно их было делать до 4х. Каждый ресурс мог работать с минимальным временем цикла 1 мс. При выполнении порядка 100 ПИД регуляторов, время выполнения было в районе 0,2-0,4 мс. Т.о. в ресурсе с самым быстрым циклом, который выполнял 100 ПИД регуляторов CPU нагружался где-то процентов на 40 прикладной задачей. Все остальные ресурсы могли быть использованы операционной системой, сетью, синхронизацией и т.п. службами.
используете ли вы симуляцию, чтобы отладить ПО контроллера
Безусловно. Существовало понятие виртуального контроллера, который мог полностью имитировать информационный обмен с УСО и межконтроллерные коммуникации (на самом деле все техпрограммы всех контроллеров проекта работали на одном большом сервере моделирования и межконтроллерные взаимодействия выполнялись просто через память). Помимо простой имитации УСО существовали продвинутые средства для написания программ моделирования технологических процессов на тех же самых технологических языках, семейства IEC 61131-3.
Лично слышал мнения — «наелись» Квинта (это ОГК-х), «наелись» Элеси (х-Нефть).
Анатомия одного ПТК