Comments 20
А как это увязывается с юридической стороной вопроса? Не дай бог, произошла авария, приходят ребята в синих пиджаках, поднимают договора или акты на ремонт (профилактику) и говорят: «а что это у вас он год не обслуживался? Какие графики?»
Должен быть регламент обслуживания, который всеми согласован. В нашем случае в нем будет прописано, что обслуживание нужно осуществлять по достижению оборудованием определенной наработки, что естественно должно быть согласовано с производителем оборудования. Т.е. на уровне предприятия и производителя есть согласованный документ, что нужно обслужить станок, если он проработал столько-то часов с предыдущего ТО. Там же прописаны и операции по обслуживанию. Если данный документ не соблюдается, то будут проблемы.
гос завод какой-то))) бабла некуда девать.
Сложилось впечатление, что это первый опыт работы с промышленной автоматикой.
Делать такие вещи даже не через SCADA, а через MES — это шедеврально. Я в своих проектах счётчики наработки всегда прямо в контроллере делаю. Чем ближе к железу — тем лучше.
Самое простое — отталкиваться от обратной связи. Точно насчитаешь не меньше, чем фактическая наработка.
В вашем случае, самый лучший вариант считать наработку — это условие ИЛИ вкл ИЛИ НЕ выкл ИЛИ нагрузка. Тогда все эти жёлтые зоны будут учтены, как наработка, что принципиально верно.
И да: делать такие вещи надо в контроллере, в SCADA архивировать (например, раз в день), а в MES — считать отчёты.
Я, в основном, программирую на Siemens. У меня есть свой готовый блок, который описывает мотор. Собственно, его можно для любой электрической нагрузки использовать. Среди прочего, у меня реализован учёт наработки — с точностью до миллисекунд :) Такая точность, конечно, ни к чему. Считаю так потому, что самый простой способ — вычислять время цикла и каждый раз прибавлять его к счётчику. Время цикла — единицы (в крайнем случае — десятки) миллисекунд. Когда накопится 3600 секунд, прибавляется единица к счётчику часов и счётчик миллисекунд обнуляется.
Собственно, почему это надо делать в контроллере. Он ближе всего к железу и потеря связи с объектом означает, что нарушена проводка. А вот потеря связи компьтера со SCADA или MES — это куда как более вероятное событие. И то, на ответственных объектах сервер SCADA должен быть резервирован.
А сочетание всякого АСП, си шарп и производственного железа — это редкое извращение.
С одной стороны, радость эксплуататоров понятна. Если б ко мне на производство пришли считать наработку (или чего ещё делать) господа, которые знакомы с си шарп, а ладдера/ассемблера в глаза не видали — я б их на пушечный выстрел к контроллерам не подпустил. Это я не с целью обидеть. Промышленная автоматика — это, вообще, другой мир.
Когда я сам начал этим заниматься чуть более 10 лет назад, некоторые вещи просто взорвали мой мозг. А недавно пришлось провести курс молодого бойца новичку. Элементарные, базовые вещи у него либо вызывали восторг, либо взрывали мозг. Если не ошибаюсь, DI HALT писал: представьте, что в вашей программе все строки исполняются одновременно :)
Эти решения называются общим словом SCADA.
Из перечисленного внимания достоин только GENESIS, wonderware — ерунда, а tibbo — нечто неизвестное совершенно.
При этом, автор по совершенно непонятным причинам не упомянул лидеров рынка — таких, как Siemens, Schneider, Allen-Bradley, General Electric.
Опять же, статья наводит на размышления — на каком железе выполнены системы управления столь ответственными процессами? Неужели на Advantech или подобном?
Делать такие вещи даже не через 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 или подобном?
Wonderware — ерунда? Ннню…
Ну уж точно это не GENESIS и не WinCC.
Главный недостаток Wonderware (и, кстати, Genesis) — что им ни один контроллер не родной.
Главный недостаток Wonderware (и, кстати, Genesis) — что им ни один контроллер не родной.
Коллеги, вы абсолютно верно описываете один из возможных вариантов реализации данной задачи. У каждого варианта есть свои плюсы и минусы, в том числе и финансовые.
В нашей ситуации были внешние условия и предпосылки, ввиду которых мы реализовали систему именно так. Давайте я их приведу и, думаю, все встанет на свои места:
— Объекты территориально распределены по всей стране;
— Большое количество оборудования;
— Нельзя вмешиваться в локальные и объектовые системы управления, либо вмешательство должно быть минимальным. Соответственно, вмешательство в PLC и «головы» станков – табу;
— Платформа выбрана с учетом того, что в перспективе на нее пойдут и другие данные от распределенных объектовых систем и будут решаться дополнительные задачи уровня MES, а не только расчет наработки.
Поэтому, как видите, задача — не только посчитать наработку с учетом всех внешних условий и финансов, но и заложить базу для дальнейшего развития. Отсюда и отсутствие Siemens, Schneider, Allen-Bradley и General Electric, которые очень хороши как объектовые SCADA, но могут не подойти как MES-платформа. Хотя, есть чудесный продукт Siemens WinCC OA, но это уже совсем другая история… Про Wonderware, вы заблуждаетесь, это довольно мощная и гибкая платформа.
По поводу, квалификации и опыта сильно распаляться не буду, скажу лишь, что у нас есть сотрудники, которые прекрасно знают КИП, PLC, DCS-системы, SCADA-системы ведущих мировых производителей и соответствующие промышленные протоколы, свободно программирующие как на языках группы МЭК 61131-3, так и на общих языках программирования и скриптовых языках. Естественно, сотрудники, которые программируют на C#, не лезут в контроллеры (хотя есть парни, которые и то и то умеют), а те, кто программирует PLC, не занимаются разработкой собственных верхнеуровневых приложений.
Так что к заказчику приходят именно те парни, которые нужны и делают именно то, что нужно с учетом всех внешних условий и предпосылок.
В нашей ситуации были внешние условия и предпосылки, ввиду которых мы реализовали систему именно так. Давайте я их приведу и, думаю, все встанет на свои места:
— Объекты территориально распределены по всей стране;
— Большое количество оборудования;
— Нельзя вмешиваться в локальные и объектовые системы управления, либо вмешательство должно быть минимальным. Соответственно, вмешательство в PLC и «головы» станков – табу;
— Платформа выбрана с учетом того, что в перспективе на нее пойдут и другие данные от распределенных объектовых систем и будут решаться дополнительные задачи уровня MES, а не только расчет наработки.
Поэтому, как видите, задача — не только посчитать наработку с учетом всех внешних условий и финансов, но и заложить базу для дальнейшего развития. Отсюда и отсутствие Siemens, Schneider, Allen-Bradley и General Electric, которые очень хороши как объектовые SCADA, но могут не подойти как MES-платформа. Хотя, есть чудесный продукт Siemens WinCC OA, но это уже совсем другая история… Про Wonderware, вы заблуждаетесь, это довольно мощная и гибкая платформа.
По поводу, квалификации и опыта сильно распаляться не буду, скажу лишь, что у нас есть сотрудники, которые прекрасно знают КИП, PLC, DCS-системы, SCADA-системы ведущих мировых производителей и соответствующие промышленные протоколы, свободно программирующие как на языках группы МЭК 61131-3, так и на общих языках программирования и скриптовых языках. Естественно, сотрудники, которые программируют на C#, не лезут в контроллеры (хотя есть парни, которые и то и то умеют), а те, кто программирует PLC, не занимаются разработкой собственных верхнеуровневых приложений.
Так что к заказчику приходят именно те парни, которые нужны и делают именно то, что нужно с учетом всех внешних условий и предпосылок.
>Объекты территориально распределены по всей стране
Собственно, этой инфы посту очень не хватает. Перечитал пост — да, из того что там «производствА» и «объектЫ» не очевидно, что их действительно много и они далеко друг от друга. Это совсем другая история)
Почему решение о проведении ТО не по месту принимается? Зачем тащить инфу куда-то далеко, с кучей проблем, чтобы там принимать решения вроде как местного значения?
Хотя бы область можете очертить, где всё это сделано? Нефтегаз, энергетика, ВПК, транспорт, ...? Интересно ж :)
А вот вы упоминали Aggregate, есть интересные кейсы интеграции этой платформы?
Собственно, этой инфы посту очень не хватает. Перечитал пост — да, из того что там «производствА» и «объектЫ» не очевидно, что их действительно много и они далеко друг от друга. Это совсем другая история)
Почему решение о проведении ТО не по месту принимается? Зачем тащить инфу куда-то далеко, с кучей проблем, чтобы там принимать решения вроде как местного значения?
Хотя бы область можете очертить, где всё это сделано? Нефтегаз, энергетика, ВПК, транспорт, ...? Интересно ж :)
А вот вы упоминали Aggregate, есть интересные кейсы интеграции этой платформы?
Почему решение о проведении ТО не по месту принимается? Зачем тащить инфу куда-то далеко, с кучей проблем, чтобы там принимать решения вроде как местного значения?
На самом деле в больших организациях решение о ТО проводят на месте, но руководство в головном офисе хочет видеть что это решение обосновано, и никто не занимается как «приписками» часов работы, так и не выжимает из дорогостоящего оборудования последнее здоровье, в угоду выполнения плана(который срывается по каким-то другим причинам), именно поэтому статистика о наработке собирается в централизованную mes/erp/и др.
— Объекты территориально распределены по всей стране
Это никак не влияет на задачу сбора первичной информации.
Отсюда и отсутствие Siemens, Schneider, Allen-Bradley и General Electric, которые очень хороши как объектовые SCADA, но могут не подойти как MES-платформа.
Вы SCADA и MES не путаете? У того же сименса есть и SCADA (WinCC), и MES (IT Historian).
SCADA и MES решают разные задачи. SCADA — графическое отображение процесса для удобства оператора, текущее управление, архивирование данных. Одна из функций MES — агрегация данных. Например, если вы с некоторой периодичностью архивируете время наработки, то MES вам рассчитает, какова была наработка оборудования за заданный период.
— Платформа выбрана с учетом того, что в перспективе на нее пойдут и другие данные от распределенных объектовых систем и будут решаться дополнительные задачи уровня MES, а не только расчет наработки.
Функций у MES много, но конкретную описанную задачу вы решали таки далеко не самым рациональным способом
>эксплуатационщики сразу поняли, что именно мы делаем, очень обрадовались, что не трогаем нижний уровень и их железо руками
Ещё бы :D
>В целом, такие системы можно строить вообще не трогая ERP
В целом, такие системы делаются таймером на ПЛК и вообще никак не затрагивают ERP. Туда через скаду нужно только утягивать значение.
Кроме того, зачем точность до долей секунды — из текста не понятно. Если оборудование вкл/выкл даже раз в час (страшно представить что за железка может так колбаситься), то за год будет погрешность 365*24*х, где х — жёлтая зона со второй диаграммы (ну не больше пары секунд). Итого плюс-минус несколько часов в год. Не существенно никак.
Вобщем, гланды через ж — или ну очень конспиративная статья, потому что причины таких сложностей не освещены.
Ещё бы :D
>В целом, такие системы можно строить вообще не трогая ERP
В целом, такие системы делаются таймером на ПЛК и вообще никак не затрагивают ERP. Туда через скаду нужно только утягивать значение.
Кроме того, зачем точность до долей секунды — из текста не понятно. Если оборудование вкл/выкл даже раз в час (страшно представить что за железка может так колбаситься), то за год будет погрешность 365*24*х, где х — жёлтая зона со второй диаграммы (ну не больше пары секунд). Итого плюс-минус несколько часов в год. Не существенно никак.
Вобщем, гланды через ж — или ну очень конспиративная статья, потому что причины таких сложностей не освещены.
В целом, такие системы делаются таймером на ПЛК
Именно что. Тем более, что во всей системе контроллер-SCADA-MES контроллер — единственный, кто работает в реалтайм.
Вобщем, гланды через ж
Это точно.
или ну очень конспиративная статья, потому что причины таких сложностей не освещены.
Причины такой сложности несложно предположить. Во-1, ответственное производство, во-2, кто ж десктопников к железу пустит? Они ж совершенно его не понимают. А п.1 — это дополнительная причина их не пускать.
Кроме того, зачем точность до долей секунды — из текста не понятно. Если оборудование вкл/выкл даже раз в час (страшно представить что за железка может так колбаситься), то за год будет погрешность 365*24*х, где х — жёлтая зона со второй диаграммы (ну не больше пары секунд).
Само собой, что такая точность — избыточна. Для ясности считать жёлтую зону наработкой и не морочить голову.
В целом, такие системы делаются таймером на ПЛК и вообще никак не затрагивают ERP. Туда через скаду нужно только утягивать значение.
Насчёт точности мне нравится фишка у сименса в связке 400 контроллера и WinCC — быстрые архивы. В программе контроллера подготавливается пачка данных (в сущности, массив из пары метка времени-значение) и отправляется в WinCC. А WinCC уже само запихивает эти данные в архив.
Only those users with full accounts are able to leave comments. Log in, please.
АСУ ТП: как мы создавали систему для точного расчета наработки станков большого завода