АСУ ТП: как мы создавали систему для точного расчета наработки станков большого завода
Особенности формирования сигналов (задержек локальных сигналов автоматики) в системе управления, это создает некоторые трудности при расчете наработки.
Суть задачи очень простая: есть много очень дорогого оборудования, которое требует регулярных технических осмотров и своевременного обслуживания. Последние лет десять оборудование обслуживалось, например, раз в полгода, раз в три месяца и так далее, без корреляции со временем фактической наработки. Смысл был в том, что если на оборудовании произойдёт авария, и при этом оборудование по факту наработало срок больший, чем положено до обслуживания — руководитель сядет.
Садиться никто не хотел, поэтому считали с большим запасом. С другой стороны, делать обслуживание чаще, чем нужно — терять лишние средства на ремонте, работе и простоях. Поэтому требовался точный учёт.
На высокотехнологичных производствах один из методов — поставить специальный контроллер на каждый технический объект, требующий учета его наработки. Это достаточно дорого. Есть станки и прочее высокотехнологичное оборудование, которые считают сами, важно просто правильно забирать данные. В нашем случае учет наработки велся вручную, в журнал с помощью механика типа «станок проработал 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.
