Устройства для учета наработки оборудования

Автоматизированная информационная система управления производственным предприятием

Системы учета наработки механического оборудования могут разрабатываться компанией как самостоятельные информационные системы управления производственной компанией, так и в рамках создания единой MES-системы.

Основной целью создания автоматизированной информационной системы управления производственным предприятием является предотвращение аварийных ситуаций. Для этого необходимо собирать и обрабатывать данные о техническом состоянии оборудования, которые позволили бы прогнозировать отказы и своевременно выполнять профилактические мероприятия.

Разработка информационной системы управления предприятием предназначена для механослужбы цехов промышленных предприятий и в комплексе выполняет следующие задачи:

ведение структуры оборудования и технических характеристик его составных частей;
учёт наработки оборудования;
перемещение оборудования;
информирование пользователей о скором окончании срока службы оборудования и др.

Основные принципы построения архитектуры информационных систем управления организацией

Поддержка архитектуры «клиент-сервер».
Использование технологии «тонкий клиент» на основе web-браузера для организации рабочих мест конечных пользователей.
Распределенный банк данных на базе СУБД Microsoft SQL Server 2008.
Тесная интеграция с Microsoft Office (выгрузка данных в документы Word, Excel, построение отчетных форм в формате Microsoft Excel).
Разграничение прав доступа пользователей в целях обеспечения безопасности.

В рамках разработки систем учета наработки механического оборудования компания предоставляет следующие услуги:

обследование;
разработка ТЗ на систему;
разработка проектной документации в соответствии с ГОСТ;
разработка программного обеспечения;
пусконаладочные работы и тестирование ПО;
обучение ключевых пользователей;
гарантийная поддержка.

Источник

Счётчики времени наработки в Москве

Счетчики электроэнергии
Производственно-техническое оборудование
Лабораторное оборудование
Аксессуары для лодок, катеров и яхт
Прочие измерительные инструменты
Контакторы и реле
Счётчики газа

Счетчик времени наработки Донконт-1

Счетчик времени наработки Донконт-IP68

Счетчик электроэнергии TDM Electric Марс SQ1105-0004

Счетчик наработки времени Овен СВ01-220.Щ2.Р.RS — счетчик времени

Счетчик времени наработки Донконт-2

Счетчик моточасов HA-SO1 230В для бензогенераторов

Счетчик времени наработки Донконт-1

Счетчик времени наработки Донконт-2

Измерительные приборы Legrand Счетчик времени наработки 24-36 В= (049560)

Счетчик времени наработки оборудования овен СВ01-24.Щ2

Счетчик времени наработки оборудования овен СВ01-220.Н

Счетчик времени наработки оборудования овен СВ01-24.Щ1.Р

СВ01 счетчик времени наработки оборудования от овен

Счётчики времени работы CLG-03

Счетчик времени наработки Донконт-220 (Донконт-3)

Счётчики времени работы CLG-03

Счетчик часов наработки электромеханический Theben BZ 145

Счетчик часов наработки электромеханический Theben BZ 142-1 230V 50Hz

Счетчик моточасов CONTA MODULAR модульный

СВ01 счетчик времени наработки оборудования

E233-230 Электромеханический счетчик часов работы 230В AC ABB, 2CDE100000R1601

Источник

Счетчики времени наработки, моточасов

Предназначен для учета времени наработки оборудования, машин и иных приборов и устройств, на которые он устанавливается.

Напряжение питания: 6-40В
Климатическое исполнение по ГОСТ 15150: У2
Наличие функций обнуления времени наработки и прерывания его счета существенно расширяют их спектр применения.

По требованию заказчика можно изготовить на любое другое напряжение питания.

Напряжение питания: 220 В (50 Гц)
Климатическое исполнение по ГОСТ 15150: У2
Наличие функций обнуления времени наработки и прерывания его счета существенно расширяют их спектр применения.

По требованию заказчика можно изготовить на любое другое напряжение питания.

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

Напряжение питания: 7. 34 В
Степень защиты: IP54
Оснащен режимом «КОНТРОЛЬ» который позволяет работать и контролировать показания без включения устройства, на котором счетчик установлен (на автономном питании).

По требованию заказчика можно изготовить на любое другое напряжение питания.

Напряжение питания: 220В 50 (Гц)
Степень защиты: IP54
Климатическое исполнение: У1
Оснащен режимом «КОНТРОЛЬ» который позволяет работать и контролировать показания без включения устройства, на котором счетчик установлен (на автономном питании).

По требованию заказчика можно изготовить на 380В (50Гц).

Предназначен для автоматического учета времени наработки двигателя или любого другого оборудования (агрегатов, машин) при соответствии условий эксплуатации требованиям ТУ 25-1865.081087 .

Напряжение питания: 12В постоянного тока
Потребляемая мощность: 0,2Вт
Степень защиты: IP65

Напряжение питания: 27В постоянного тока
Потребляемая мощность: 0,5Вт
Степень защиты: IP65

Предназначен для автоматического учета времени работы оборудования, агрегатов, машин.

Исполнение

Напряжение питания

Мощность

Предназначен для измерения интервалов времени и счета количества измеренных сигналов.

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

Так же применяться для автоматического учета времени наработки оборудования (двигателей, станков, автономных электростанций, компрессоров, холодильных установок, спецтехники и др. оборудования), благодаря чему удается измерить общую продолжительность работы оборудования и своевременно производить профилактические и регламентные работы.

Исполнение:

Напряжение питания:

90….264В переменный ток (47-63 Гц)

80….375В постоянный ток

10,5….30В постоянный ток

Предназначен для учета времени работы электрооборудования (приборов, агрегатов, машин) к которому они подключаются.

Исполнение

Напряжение питания

От 7 до 34В постоянного тока

Основным отличием счетчиков типа СВН-1 от счетчиков СВН-2 являются габаритные размеры и емкость (максимальное значение времени наработки).

Исполнение

Напряжение питания

От 7 до 34В постоянного тока

Предназначен для измерения и отображения в цифровом виде времени наработки двигателя и напряжения бортовой сети автотракторной и строительно-дорожной техники, а также для измерения времени наработки промышленных электроустановок для своевременного проведения их технического обслуживания.

Номинальное напряжение питания: 12 и 24В
Потребляемый ток, не более: 150 мА
Степень защиты: IP54
Диапазон рабочих температур: от минус 40 до +55 о С

Предназначен для измерения и отображения в цифровом виде времени наработки автотракторной и строительно-дорожной техники, различных электроустановок (станков, холодильных агрегатов, компрессоров, автономных электростанций и др.) для своевременного проведения их технического обслуживания и контроля выработки ресурса.

В счетчике СВН-2-3.1 подсчет и отображение времени производится постоянно при наличии напряжения питания.

Диапазон рабочих напряжений: от 10 до 36В (могут применяться в автотранспортной технике с напряжением бортовой сети 12 или 24 В.)
Диапазон рабочих температур: от минус 40 до +70 С
Степень защиты: IP65

Подсчет времени производится только при наличии постоянного или переменного напряжения на дополнительном входе (для подсчета времени наработки только при работающем двигателе или только в определенном режиме работы установки).

Диапазон рабочих напряжений: от 10 до 36В (могут применяться в автотранспортной технике с напряжением бортовой сети 12 или 24 В.)
Диапазон рабочих температур: от минус 40 до +70 о С
Степень защиты: IP65

Подсчет времени производится при наличии только переменного напряжения на дополнительном входе (например, переменного напряжения генератора или датчика оборотов в автомобиле), что затрудняет несанкционированную «намотку» наработки.

Диапазон рабочих напряжений: от 10 до 36В (могут применяться в автотранспортной технике с напряжением бортовой сети 12 или 24 В.)
Диапазон рабочих температур: от минус 40 до +70 о С
Степень защиты: IP65

Предназначен для учета времени наработки оборудования (станций катодной защиты, машин, приборов и т.д.).

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

Источник

Система учета отработанного времени оборудования

Каждый инженер прекрасно знает, что любое оборудование нуждается в профилактическом ремонте, осмотре, выполнении регламентных работ, необходимых для поддержания его в рабочем состоянии, предотвращении поломок. Работы необходимо выполнять согласно рекомендациям завода-изготовителя.

Завод-изготовитель прописывает, через какое время нужно выполнить те или иные работы для каждого оборудования. Например, замена подшипников в редукторе производится через 10 тыс. часов работы. Можно провести параллель по выполнению ТО на автомобиле — отъездил 15000 км — нужно менять масло и определенные расходные материалы.

Стоит вопрос — каким образом отсчитать это время работы на элеваторе? Есть несколько вариантов выхода из ситуации.

Первый — указать определенные часовые рамки. Например, каждые полгода менять клиновые ремни, каждые три месяца смазывать подшипники и раз в год их менять.Но в такой системе есть свои минусы.

Работы выполняются либо с перерасходом запчастей и комплектующих, либо с просрочкой по обслуживанию или замене. Ведь одно оборудование может не выключаться 24 часа в сутки на протяжении месяца, а другое — включиться на протяжении 10 дней по одному часу.

Кроме того, запчасть может не выработать гарантийного срока, или просто выйти из строя в самый не подходящий момент – в разгар заготовки зерна.

Есть еще один вариант. Можно задаться целью точно посчитать время работы каждой единицы оборудования. Но это не реально.

Несколько лет назад я задал вопрос — а может ли система автоматизированного управления элеватором подсчитывать время работы оборудования? Оказалось, может. Для этого необходимо прописать дополнительную программу.

Я составил техническое задание для разработки данной подпрограммы. Указал необходимые функции:

автоматизированный учет реально отработанного времени каждой единицы оборудования;

выдача рекомендаций по срокам проведения обязательных регламентных работ;

контроль сроков выполнения обязательных регламентных работ;

прогнозирование плановых замен частей оборудования.

Целью внедрений данной системы было снижение коммерческих потерь элеваторного комплекса за счет предупреждения поломок оборудования.

Был составлен исчерпывающий перечень периодичности выполнения работ по ТО, видов работ — ЕТО, ТО1, ТО2 и т.д.

Мы обозначили количество часов работы для каждого вида оборудования ( при наработке которого необходимо выполнение того или иного вида ТО) и перечень необходимых работ.

Рассмотрим, как ставится задание, на примере нории.

Ежедневное ТО: проверка на посторонние шумы, нагрев подшипников, редуктора, электродвигателя.

ТО-1, через каждые 100 часов работы необходимо проверить центровку норийной ленты; уровень масла в редукторе; электроподключение, а также объем работ ЕТО, и т.д.
В качестве пилотного проекта данная программа была установлена на одном из элеваторов структуры. Полгода она работала в тестовом режиме, вносились изменения, дополнения, устранялись выявленные ошибки.

На сегодняшний день такие программы установлены практически на всех элеваторах, где есть система АСУ ТП. Не могу сказать, что все рекомендации и требования выполняются вовремя и в полном объеме, но есть положительные результаты. Теперь затраты на ремонтные работы сократились более чем на 10%. Оборудование стало меньше простаивать из-за аварий и поломок.

Расскажу случай из нашей практики. Весной программа выдала информацию, что подшипники на нориях отработали больше 9 тыс. часов. Завод-изготовитель обозначил ресурс подшипника в 10 тыс. часов. Встал вопрос — менять или не менять? Внешних признаков скорого выхода из строя подшипника не было видно. Может быть, он еще отработает сезон, а может выйдет из строя в самый неподходящий момент, в разгар приемки зерна?

Дальше простая арифметика: подшипник стоит, к примеру, 15 тыс. грн., а час простоя работы элеватора в пик сезона 30 тыс. грн и больше. Замена подшипника займет больше 2 часов, в лучшем случае, при условии, что такой подшипник есть на складе. Было принято решение закупить и произвести замену всех отработавших свой ресурс подшипников до начала сезона.

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

Наша программа, как и любая другая, не имеет предела совершенству. В нее постоянно вносятся дополнения и новшества.

Следующий этап доработки заключается в создании информационных каталогов запасных частей и расходных материалов, которые используются на данной единице оборудования (в формате: номенклатура, тип, марка, характеристика, количество).

На основании указанных данных появится возможность:

формировать общую таблицу из перечня запасных частей по видам оборудования, типу, марке, количеству;

формировать список расходных материалов на каждый вид регламентных работ;

при получении сообщения про необходимость выполнения регламентных работ, автоматически формировать таблицу с перечнем расходных материалов на данный вид работ;

создать таблицу с общим перечнем запасных частей, в которой будут колонки с марками, количеством и стоимостью запасных частей, а также автоматическим подсчетом общей стоимости, как по отдельным позициям, так и общих сумм на каждый вид запчастей, и общей суммой на весь перечень.

На сегодня такая программа уже работает, правда, в тестовом режиме на одном из элеваторов.

Но и это не все. При условии автоматизации склада ТМЦ и совмещении этих двух программ появится возможность отслеживать количество запасных частей на складе, а также:

вести автоматический контроль использования и закупки запасных частей и расходных материалов;

при выдаче наряда на проведение работ в базе склада ТМЦ автоматически отнимать от общего количества выданную запчасть;

при достижении остатка, например, в две единицы автоматически генерировать сообщение с предупреждением;

возможность экспорта таблиц баз данных в таблицу Microsoft Excel с поддержанием формата данных (текст, числа, дата и время);

возможность пользователя редактировать списки и создавать новые и т.д.

Источник

АСУ ТП: как мы создавали систему для точного расчета наработки станков большого завода

Особенности формирования сигналов (задержек локальных сигналов автоматики) в системе управления, это создает некоторые трудности при расчете наработки.

Суть задачи очень простая: есть много очень дорогого оборудования, которое требует регулярных технических осмотров и своевременного обслуживания. Последние лет десять оборудование обслуживалось, например, раз в полгода, раз в три месяца и так далее, без корреляции со временем фактической наработки. Смысл был в том, что если на оборудовании произойдёт авария, и при этом оборудование по факту наработало срок больший, чем положено до обслуживания — руководитель сядет.

Садиться никто не хотел, поэтому считали с большим запасом. С другой стороны, делать обслуживание чаще, чем нужно – терять лишние средства на ремонте, работе и простоях. Поэтому требовался точный учёт.

На высокотехнологичных производствах один из методов – поставить специальный контроллер на каждый технический объект, требующий учета его наработки. Это достаточно дорого. Есть станки и прочее высокотехнологичное оборудование, которые считают сами, важно просто правильно забирать данные. В нашем случае учет наработки велся вручную, в журнал с помощью механика типа «станок проработал 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, диагностики программно-технических средств системы, а также интерфейса для формирования отчетов, сбора и просмотра статистики.

В общем, мы поставили свой сервер рядом с их серверами, а они получили точные расчёты по наработке станков. Дальше — куча всего по консолидации данных, их обработке и т.п., — в общем, детективы и алгоритмизация. Итог — точный источник данных про наработку, который взаимодействует с положенными системами автоматизации производства и управления предприятием. Было много боли, связанной с тем, что это всё-таки большая производственная группа с положенными бюрократическими особенностями, но это по нашим проектам, скорее привычный рабочий процесс. Сюрпризов, в общем, не было, если не считать ряд показаний оборудования и отсутствие в ряде случаях техдокументации, которую, фактически, надо было реверсить – но это предполагалось ещё в самом начале.

Источник