Особенности формирования сигналов (задержек локальных сигналов автоматики) в системе управления, это создает некоторые трудности при расчете наработки.
Суть задачи очень простая: есть много очень дорогого оборудования, которое требует регулярных технических осмотров и своевременного обслуживания. Последние лет десять оборудование обслуживалось, например, раз в полгода, раз в три месяца и так далее, без корреляции со временем фактической наработки. Смысл был в том, что если на оборудовании произойдёт авария, и при этом оборудование по факту наработало срок больший, чем положено до обслуживания — руководитель сядет.
Садиться никто не хотел, поэтому считали с большим запасом. С другой стороны, делать обслуживание чаще, чем нужно – терять лишние средства на ремонте, работе и простоях. Поэтому требовался точный учёт.
На высокотехнологичных производствах один из методов – поставить специальный контроллер на каждый технический объект, требующий учета его наработки. Это достаточно дорого. Есть станки и прочее высокотехнологичное оборудование, которые считают сами, важно просто правильно забирать данные. В нашем случае учет наработки велся вручную, в журнал с помощью механика типа «станок проработал 3 дня плюс-минус 4 часа». В итоге было принято решение подцепиться к управляющему софту и снимать данные с него. Сейчас расскажу, что случилось дальше и какое к этому имеет отношение картинка выше.
Архитектура
Функциональная архитектура системы расчета наработки станков
Суть работы — мы берём данные обо всех событиях на производстве, которые уже есть из АСУ ТП. В идеальном мире там все сигнальные схемы идеально показывают, что и как — нужно только забрать образы оборудования (что это и как работает) из системы уровнем выше и наложить сигнальные схемы, а потом рассчитать по алгоритму наработку и вернуть в системы ТОиР. Но мы с вами в реальном мире, поэтому так прямо просто не получилось. Начнём с того, что в идеальном мире у каждого станка есть детальная инструкция, она точно соответствует реальности. В нашем мире пришлось выявлять характер работы многих вещей опытным путём.
Например, на картинке до ката вы видите самый простой случай того, как служебная сигнализация (два бита – сигнал «ВКЛ» и сигнал «ВЫКЛ») внезапно превращаются из триггера в нечто куда более монструозное. Такова жизнь. И считать наработку станка приходится уже не по данным сигналам, а (в этом конкретном случае) по нагрузке. Были и другие ситуации веселее, но, увы, углубляться не имею права, уж больно специфическое производство.
Как шла работа
Итак, у нас есть сервер, который анализирует данные АСУ ТП (диспетчерский контроль и управление), считает наработку (точнее — различные переключения состояний, и остальные события, сводящиеся в итоге к числам наработки) и отдаёт её дальше в ERP (ТОиР), где планируются профилактические ремонты. Мы получаем снизу, грубо говоря, данные о состоянии оборудования, а сверху — его иерархию.
Схема расчёта есть выше; в целом это известный технический процесс, который в виде абстракций поддерживается 4 разными производителями промышленного софта (в том числе есть опенсорсное решение), но, как обычно – когда речь заходит о конкретном объекте, нужна доработка напильником. Мы создали не только общую архитектуру, но и конкретные алгоритмы коррекции данных, поскольку, как я уже говорил, особенности работы систем управления таковы, что способны с корнем поломать всю логику софту. Здесь нужно пояснить, что данные о состоянии оборудования поступают в виде трех сигналов – сигнала «включено», сигнала «выключено» и текущей нагрузки оборудования. Для нагрузки задается пороговое значение, при превышении которого считается, что оборудование включено и работает на номинальном режиме. В идеале эти сигналы должны изменяться согласовано друг с другом. Но реальность оказалась такова, что сигналы изменяются не всегда так, как это ожидалось. Что создает дополнительные трудности. Плюс надо было добавить часть сигналов, поскольку они были плохо описаны, отличались в реализации или изначально не поддерживались протоколом.
Затем потребовалось восстановить исторические данные на случай сбоя связи между компонентами системы и разработать схему расчёта наработки при длительном обрыве этой связи. Мы фиксировали, пересчитывали и создавали инструменты для учета таких ситуаций. Сложность в том, что при физическом обрыве связи мы просто не видели событий, но не знали про сам факт потери сигнала. Таковы особенности протокола. В результате на уровне системы АСУ ТП пришлось создать «пульс» — некую виртуальную задвижку, которая сдвигалась раз в секунду. Благодаря этому «датчику» мы знали, что сигнал идёт. Если он «щёлкал» неправильно или с искажениями – мы отмечали период как недостоверный. Если по недостоверному периоду восстановить данные из логов (или пересчитать руками) было нельзя– то уровнем выше он, скорее всего, отмечался как наработка, поскольку основная задача – не перешагнуть за предел без ТО.
Дополнительную сложность вносили проблемы с передачей данных, что отражалось на их доступности и качестве. При кратковременном пропадании связи с источником данных можно сделать обоснованное предположение, что состояние оборудования не изменялось на этом отрезке времени, но при длительном отсутствии данных состояние оборудования могло измениться, и в этом случае система не может дать однозначного ответа на вопрос – что происходило за то время, за которое данные отсутствуют. В результате реализации проекта были выработаны и согласованы с заказчиком алгоритмы, способные обрабатывать эти и другие нестандартные ситуации.
Потом была ещё одна итерация работы с «плохими» данными, чтобы не было ошибок недоучёта. Затем — уже опытная эксплуатация. Запустились мы после двух этапов испытаний. На каждом участке производства были свои особенности. Самое интересное было играть в детектив пополам с работой врача – нужно было составить картину сигналов, получить данные об особенностях оборудования, пообщаться со всеми диспетчерами… Мужики на заводе очень помогали: эксплуатационщики сразу поняли, что именно мы делаем, очень обрадовались, что не трогаем нижний уровень и их железо руками, и стали делиться опытом. Много проверяли вручную расчёты системы, гонялись за причиной каждого расхождения. В результате были выработаны и согласованы алгоритмы, способные обрабатывать разные нестандартные ситуации. Для учета различных типов оборудования в алгоритмы вводились дополнительные настроечные параметры, такие как время нечувствительности, допустимая ошибка и т.п. Для нового оборудования пользователь может сам выполнять тонкую настройку алгоритмов как на уровне системы в целом, так и на уровне отдельной единицы оборудования или группы — потому что отдельные единицы тоже могут вести себя по-разному.
В результате сейчас точность — до долей секунды, что очень и очень круто и для нас, и для производства. Следующий шаг — проверка масштабируемости уже без нашего непосредственного участия, самостоятельно силами диспетчеров.
На конкретном производстве станок начинает опрашиваться сразу после появления в SAP. В целом, такие системы можно строить вообще не трогая ERP — у нас, как видите, в системе есть свои отчёты. Просто в данном случае заказчику удобнее перераспределять и нагрузки, и ремонты именно в ERP. По ходу пьесы, кстати, пару раз менялись требования к передаче данных ТОиР — но у них шёл плановый апгрейд, и это, в целом, нормально.
Конечно, очень здорово, что мы вообще не лезли на нижний уровень, где идёт служебная сигнализация до физических узлов – это сделало проект куда дешевле типовых подобных.
Результат сложно оценить в деньгах, но заказчик точно знает, что уже не будет бесполезных ремонтов по планам.
Резюме
В целом, повторить такой опыт можно на любом производстве. В этом проекте в качестве основы обмена данными мы использовали платформу PI System плюс ряд наших разработок. Например, нам пришлось самим разработать сервисы взаимодействия нашей системы с ТОиР, а также средства визуализации диагностической информации и построения отчетов (АРМ).
Но в целом подобные вещи можно делать также на базе решений от таких вендоров как WonderWare (платформа Wonderware System Platform), Iconics (платформа ICONICS Genesis), Tibbo (тайванско-российский вендор, платформа называется Aggregate). Но главная особенность, конечно, в том, что для успешного завершения проекта крайне желательно наличие опыта алгоритмизации не всегда полных и согласованных данных служебной сигнализации, плюс фактического опыта работы с крупным производством.
Повторюсь, на наших объектах уже были ТОиР-модули. Но в целом это не обязательно, например, вместо выгрузки данных в них можно пользоваться и нашими веб-отчётами (пользователь может мониторить состояние системы, формировать отчеты, принимать и загружать данные, контролировать наличие тегов для сбора, выполнять ручные отправки и настраивать систему) — эта часть решения создана на Microsoft .NET Framework на основе ASP.NET, язык C#. Front-end — на HTML5.
Итог:
- Сбор исходных данных, необходимых для выполнения расчетов;
- Расчет наработки на основе собранных из АСУ ТП данных;
- Передача параметров по наработке в установленные регламентные сроки;
- Получение данных из системы ТОИР, необходимых для конфигурирования нашей системы;
- Предоставление администратору системы возможности контроля ошибок получения данных от АСУ ТП и SAP, диагностики программно-технических средств системы, а также интерфейса для формирования отчетов, сбора и просмотра статистики.
В общем, мы поставили свой сервер рядом с их серверами, а они получили точные расчёты по наработке станков. Дальше — куча всего по консолидации данных, их обработке и т.п., — в общем, детективы и алгоритмизация. Итог — точный источник данных про наработку, который взаимодействует с положенными системами автоматизации производства и управления предприятием. Было много боли, связанной с тем, что это всё-таки большая производственная группа с положенными бюрократическими особенностями, но это по нашим проектам, скорее привычный рабочий процесс. Сюрпризов, в общем, не было, если не считать ряд показаний оборудования и отсутствие в ряде случаях техдокументации, которую, фактически, надо было реверсить – но это предполагалось ещё в самом начале.
Вот, вроде, всё. Если у вас есть вопросы, не касающиеся специфики производства (тут не имею права рассказывать даже где заводы) — с удовольствием отвечу в комментариях. Если же вопрос не для комментариев — пишите на почту sbannikov@croc.ru.
Комментарии (19)
Muzzy0
03.09.2015 22:42+2Сложилось впечатление, что это первый опыт работы с промышленной автоматикой.
Делать такие вещи даже не через SCADA, а через MES — это шедеврально. Я в своих проектах счётчики наработки всегда прямо в контроллере делаю. Чем ближе к железу — тем лучше.
Самое простое — отталкиваться от обратной связи. Точно насчитаешь не меньше, чем фактическая наработка.
В вашем случае, самый лучший вариант считать наработку — это условие ИЛИ вкл ИЛИ НЕ выкл ИЛИ нагрузка. Тогда все эти жёлтые зоны будут учтены, как наработка, что принципиально верно.
И да: делать такие вещи надо в контроллере, в SCADA архивировать (например, раз в день), а в MES — считать отчёты.
Я, в основном, программирую на Siemens. У меня есть свой готовый блок, который описывает мотор. Собственно, его можно для любой электрической нагрузки использовать. Среди прочего, у меня реализован учёт наработки — с точностью до миллисекунд :) Такая точность, конечно, ни к чему. Считаю так потому, что самый простой способ — вычислять время цикла и каждый раз прибавлять его к счётчику. Время цикла — единицы (в крайнем случае — десятки) миллисекунд. Когда накопится 3600 секунд, прибавляется единица к счётчику часов и счётчик миллисекунд обнуляется.
Собственно, почему это надо делать в контроллере. Он ближе всего к железу и потеря связи с объектом означает, что нарушена проводка. А вот потеря связи компьтера со SCADA или MES — это куда как более вероятное событие. И то, на ответственных объектах сервер SCADA должен быть резервирован.
А сочетание всякого АСП, си шарп и производственного железа — это редкое извращение.
С одной стороны, радость эксплуататоров понятна. Если б ко мне на производство пришли считать наработку (или чего ещё делать) господа, которые знакомы с си шарп, а ладдера/ассемблера в глаза не видали — я б их на пушечный выстрел к контроллерам не подпустил. Это я не с целью обидеть. Промышленная автоматика — это, вообще, другой мир.
Когда я сам начал этим заниматься чуть более 10 лет назад, некоторые вещи просто взорвали мой мозг. А недавно пришлось провести курс молодого бойца новичку. Элементарные, базовые вещи у него либо вызывали восторг, либо взрывали мозг. Если не ошибаюсь, DI HALT писал: представьте, что в вашей программе все строки исполняются одновременно :)
Но в целом подобные вещи можно делать также на базе решений от таких вендоров как WonderWare (платформа Wonderware System Platform), Iconics (платформа ICONICS Genesis), Tibbo (тайванско-российский вендор, платформа называется Aggregate)
Эти решения называются общим словом SCADA.
Из перечисленного внимания достоин только GENESIS, wonderware — ерунда, а tibbo — нечто неизвестное совершенно.
При этом, автор по совершенно непонятным причинам не упомянул лидеров рынка — таких, как Siemens, Schneider, Allen-Bradley, General Electric.
Опять же, статья наводит на размышления — на каком железе выполнены системы управления столь ответственными процессами? Неужели на Advantech или подобном?
Iceg
04.09.2015 02:38Wonderware — ерунда? Ннню…
Muzzy0
04.09.2015 09:20Ну уж точно это не GENESIS и не WinCC.
Главный недостаток Wonderware (и, кстати, Genesis) — что им ни один контроллер не родной.
jov
06.09.2015 22:21Если интерфейс связи выполнен верно, не виду проблемы, в том, что нет «родных» контроллеров.
Muzzy0
07.09.2015 08:30-1при том, что большинство современных контроллеров поддерживают Modbus, это не столь актуально, но OPC при большом количестве тегов безбожно тормозит.
Родной протокол всегда лучше. Достаточно один раз попробовать вытянуть из сименса уйму экземплярных блоков данных по Modbus
Kanava
11.09.2015 22:22берд! OPC всем родной! Если вы о реализации драйверов, то завязывайте с сименсом. Наверно оттуда предрассудки у вас взялись
Muzzy0
11.09.2015 23:30OPC — это надстройка над OLE. Оно просто тормоз, независимо от скады. Есть у меня kepware с несколькими тысячами тегов. Тормозит само по себе. А в модбасе тормозить нечему, его хоть на 8086 можно поднять.
Orioner
04.09.2015 12:57+2Коллеги, вы абсолютно верно описываете один из возможных вариантов реализации данной задачи. У каждого варианта есть свои плюсы и минусы, в том числе и финансовые.
В нашей ситуации были внешние условия и предпосылки, ввиду которых мы реализовали систему именно так. Давайте я их приведу и, думаю, все встанет на свои места:
— Объекты территориально распределены по всей стране;
— Большое количество оборудования;
— Нельзя вмешиваться в локальные и объектовые системы управления, либо вмешательство должно быть минимальным. Соответственно, вмешательство в PLC и «головы» станков – табу;
— Платформа выбрана с учетом того, что в перспективе на нее пойдут и другие данные от распределенных объектовых систем и будут решаться дополнительные задачи уровня MES, а не только расчет наработки.
Поэтому, как видите, задача — не только посчитать наработку с учетом всех внешних условий и финансов, но и заложить базу для дальнейшего развития. Отсюда и отсутствие Siemens, Schneider, Allen-Bradley и General Electric, которые очень хороши как объектовые SCADA, но могут не подойти как MES-платформа. Хотя, есть чудесный продукт Siemens WinCC OA, но это уже совсем другая история… Про Wonderware, вы заблуждаетесь, это довольно мощная и гибкая платформа.
По поводу, квалификации и опыта сильно распаляться не буду, скажу лишь, что у нас есть сотрудники, которые прекрасно знают КИП, PLC, DCS-системы, SCADA-системы ведущих мировых производителей и соответствующие промышленные протоколы, свободно программирующие как на языках группы МЭК 61131-3, так и на общих языках программирования и скриптовых языках. Естественно, сотрудники, которые программируют на C#, не лезут в контроллеры (хотя есть парни, которые и то и то умеют), а те, кто программирует PLC, не занимаются разработкой собственных верхнеуровневых приложений.
Так что к заказчику приходят именно те парни, которые нужны и делают именно то, что нужно с учетом всех внешних условий и предпосылок.Iceg
04.09.2015 14:54>Объекты территориально распределены по всей стране
Собственно, этой инфы посту очень не хватает. Перечитал пост — да, из того что там «производствА» и «объектЫ» не очевидно, что их действительно много и они далеко друг от друга. Это совсем другая история)
Почему решение о проведении ТО не по месту принимается? Зачем тащить инфу куда-то далеко, с кучей проблем, чтобы там принимать решения вроде как местного значения?
Хотя бы область можете очертить, где всё это сделано? Нефтегаз, энергетика, ВПК, транспорт, ...? Интересно ж :)
А вот вы упоминали Aggregate, есть интересные кейсы интеграции этой платформы?
Muzzy0
04.09.2015 17:08+1— Объекты территориально распределены по всей стране
Это никак не влияет на задачу сбора первичной информации.
Отсюда и отсутствие Siemens, Schneider, Allen-Bradley и General Electric, которые очень хороши как объектовые SCADA, но могут не подойти как MES-платформа.
Вы SCADA и MES не путаете? У того же сименса есть и SCADA (WinCC), и MES (IT Historian).
SCADA и MES решают разные задачи. SCADA — графическое отображение процесса для удобства оператора, текущее управление, архивирование данных. Одна из функций MES — агрегация данных. Например, если вы с некоторой периодичностью архивируете время наработки, то MES вам рассчитает, какова была наработка оборудования за заданный период.
— Платформа выбрана с учетом того, что в перспективе на нее пойдут и другие данные от распределенных объектовых систем и будут решаться дополнительные задачи уровня MES, а не только расчет наработки.
Функций у MES много, но конкретную описанную задачу вы решали таки далеко не самым рациональным способом
Iceg
04.09.2015 02:40+5>эксплуатационщики сразу поняли, что именно мы делаем, очень обрадовались, что не трогаем нижний уровень и их железо руками
Ещё бы :D
>В целом, такие системы можно строить вообще не трогая ERP
В целом, такие системы делаются таймером на ПЛК и вообще никак не затрагивают ERP. Туда через скаду нужно только утягивать значение.
Кроме того, зачем точность до долей секунды — из текста не понятно. Если оборудование вкл/выкл даже раз в час (страшно представить что за железка может так колбаситься), то за год будет погрешность 365*24*х, где х — жёлтая зона со второй диаграммы (ну не больше пары секунд). Итого плюс-минус несколько часов в год. Не существенно никак.
Вобщем, гланды через ж — или ну очень конспиративная статья, потому что причины таких сложностей не освещены.Muzzy0
04.09.2015 09:18+1В целом, такие системы делаются таймером на ПЛК
Именно что. Тем более, что во всей системе контроллер-SCADA-MES контроллер — единственный, кто работает в реалтайм.
Вобщем, гланды через ж
Это точно.
или ну очень конспиративная статья, потому что причины таких сложностей не освещены.
Причины такой сложности несложно предположить. Во-1, ответственное производство, во-2, кто ж десктопников к железу пустит? Они ж совершенно его не понимают. А п.1 — это дополнительная причина их не пускать.Iceg
04.09.2015 11:47>Причины такой сложности несложно предположить
Ну, это блог Крока, а не ООО СтройГуляйМонтажФуфлоСолюшнсМобайлДевелопмент. Думаю, в Кроке и асушники есть. Вопрос, почему заказчик выбрал такой путь.
Muzzy0
04.09.2015 09:25Кроме того, зачем точность до долей секунды — из текста не понятно. Если оборудование вкл/выкл даже раз в час (страшно представить что за железка может так колбаситься), то за год будет погрешность 365*24*х, где х — жёлтая зона со второй диаграммы (ну не больше пары секунд).
Само собой, что такая точность — избыточна. Для ясности считать жёлтую зону наработкой и не морочить голову.
В целом, такие системы делаются таймером на ПЛК и вообще никак не затрагивают ERP. Туда через скаду нужно только утягивать значение.
Насчёт точности мне нравится фишка у сименса в связке 400 контроллера и WinCC — быстрые архивы. В программе контроллера подготавливается пачка данных (в сущности, массив из пары метка времени-значение) и отправляется в WinCC. А WinCC уже само запихивает эти данные в архив.
bardex
А как это увязывается с юридической стороной вопроса? Не дай бог, произошла авария, приходят ребята в синих пиджаках, поднимают договора или акты на ремонт (профилактику) и говорят: «а что это у вас он год не обслуживался? Какие графики?»
Orioner
Должен быть регламент обслуживания, который всеми согласован. В нашем случае в нем будет прописано, что обслуживание нужно осуществлять по достижению оборудованием определенной наработки, что естественно должно быть согласовано с производителем оборудования. Т.е. на уровне предприятия и производителя есть согласованный документ, что нужно обслужить станок, если он проработал столько-то часов с предыдущего ТО. Там же прописаны и операции по обслуживанию. Если данный документ не соблюдается, то будут проблемы.