Нужна консультация по гибким системам

Сообщение **grizzzlly** » 18 окт 2016, 09:59

Добрый день,я работаю программистом на машиностроительном предприятии, некоторое время назад на предприятии появилась необходимость в создании гибких производственных линий, т.е. имеется набор ванн, автооператор и вспомогательное оборудование(выпрямители и т.д).
Требовалось иметь возможность подряд запускать барабаны с деталями, по заданным разным техпроцессам(последовательность ванн, время выдержки в них + параметры для вспомогательного оборудования). Таким образом, заранее просчитать циклограмму для линии не представлялось возможным. Когда я устраивался на работу, мой коллега такую систему уже разрабатывал. В результате у нас получилась программа на C#, которая управляет всем при помощи контроллера через Modbus TCP. Один заказ сдали, но впереди еще много проектов. В данный момент руководство посчитало, что необходимое нам время на каждую новую линию(2 месяца) это очень много, хотя заказы далеко не однотипные(разное количество автооператоров, однорядные/многорядные линии).
В итоге дали задание выяснить не изобретаем ли мы велосипед и нет ли готовых решений, которые позволили бы данные задачи решать в короткий срок(2 недели). Собственно на счет таких решений и требуется консультация.

Опишите, на что потратили 2 месяца. Что за объект автоматизировали (опишите, насколько он сложен)? Входит ли в этот срок проект электрики, железа, закуп, изготовление, монтаж, наладка?..

Сообщение **grizzzlly** » 18 окт 2016, 14:47

В первой строке я написал, что работаю программистом, поэтому 2 месяца в данном случае на переделку под новый проект, программы управления линией.
Пример проекта:
Дано: гальваническая линия многопроцессная: 32 ванны, 2 автооператора, датчики, клапаны. Движением автооператоров(пишем в регистр контроллера, он туда перемещается) и сбором данных управляет контроллер и отдает нам данные по Modbus TCP(хотя скорее мы их у него забираем).
Требуется: иметь возможность запускать барабаны с деталями в любой момент(друг за другом, или через промежуток времени, т.к. один барабан может находиться на линии несколько часов, а может и меньше часа), у каждого барабана может быть свой набор ванн, в которых он должен побывать, со своим временем выдержки(от 10с до нескольких часов), которое необходимо соблюдать, для ванн с малой выдержкой отклонение в несколько секунд может быть критичным.
Проблемы:
1) мы не можем заранее построить весь маршрут перемещения автооператоров, т.к. не знаем с каким набором ванн отправится следующий барабан. Поэтому циклограммы(в которых барабаны движутся по заранее рассчитанному циклу) здесь не работают.
2) сложно сделать универсальный алгоритм(если вообще возможно), т.к. линии бывают, однорядными, многорядными с передачей барабанов с ряда на ряд при помощи передаточных тележек, с накопителями и без, с разным количеством автооператоров и разным количеством ванн, плюс еще некоторые нюансы вроде кунания, когда автооператор поднимает/опускает барабан.
Вот собственно этим программа и занимается. И в силу не серийности оборудования, под каждый проект приходится много переделывать. Со времен когда станут появляться похожие проекты на те которые уже были сделаны, мы конечно сможем использовать старые с минимум переработок. Но руководство хочет здесь и сейчас.
Поэтому вопрос: Есть ли готовые решения, в которых можно данные функции быстро реализовать?

P.s. Там еще управление выпрямителями, клапанами подачи воды и т.д. но это мелочи, т.к. сложность основная именно в движениях автооператоров.

Сообщение **Romcheg** » 18 окт 2016, 15:44

Два типа разработки ПО:
1) Системное, когда все ПО создается с нуля (Ваш случай)
2) Прикладное, когда для разработки используется некая среда, в которой задача формализуется и разрабатывается на основе средств системы разработки (случай применения скада-системы)

2-й вариант позволяет экономить время разработчика на следующих вещах:
1) Разработка графического интерфейса оператора (АРМ)
2) Разработка типовых алгоритмов управления
3) Разработка механизмов информационного обмена между: узлами системы (если архитектура многоузловая и клиент-серверная), внешним оборудованием (типовые протоколы и интерфейсы), внешними задачами (типовые интерфейсы)
4) Разработка информационной структуры проекта - организация логики взаимодействия всех компонентов (графики, алгоритмов, обмена и прочих механизмов) внутри системы
5) Архивация
6) Журналирование событий
7) Отладка всей системы как единого комплекса на объекте

что забыл, меня дополнят...

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

А Ваша задача, как мне видится - решается организацией алгоритма маршрутов, выполняющий batch-процесс прохождения объекта с собственным маршрутом по производственной линии. Похожие вещи делал, когда автоматизировал системы с пошаговыми итерациями в технологии, или последовательностями определенных шагов. Суть в том, что вы не должны закладывать маршруты заранее - они должны быть всего лишь гибкими наборами правил, применимых к некоторому субъекту (барабану). Основной алгоритм на основе этих правил пошагово формирует переходы между стадиями (ваннами) линии и при нахождении в этих стадиях управляет и мониторит основным КИПом, следя за технологией и временем исполнения каждой стадии.

Сообщение **Valerich** » 18 окт 2016, 15:46

Возможно ли создание одной общей программы, обеспечивающей все возможные маршруты, а по флагам (рецептам) включать/отключать выполнение определенного шага программы?
Как пример - железная дорога с её стрелками и перегонами.

Сообщение **grizzzlly** » 18 окт 2016, 16:05

Romcheg писал(а):
А Ваша задача, как мне видится - решается организацией алгоритма маршрутов, выполняющий batch-процесс прохождения объекта с собственным маршрутом по производственной линии. Похожие вещи делал, когда автоматизировал системы с пошаговыми итерациями в технологии, или последовательностями определенных шагов. Суть в том, что вы не должны закладывать маршруты заранее - они должны быть всего лишь гибкими наборами правил, применимых к некоторому субъекту (барабану). Основной алгоритм на основе этих правил пошагово формирует переходы между стадиями (ваннами) линии и при нахождении в этих стадиях управляет и мониторит основным КИПом, следя за технологией и временем исполнения каждой стадии.

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

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

grizzzlly писал(а): Движением автооператоров(пишем в регистр контроллера, он туда перемещается) и сбором данных управляет контроллер и отдает нам данные по Modbus TCP(хотя скорее мы их у него забираем).

Я может что-то не так понял, но Вам нужно переписать программу для контроллера/контроллеров. Это обычная для него/них задача. Что за контроллеры-то?

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

Сообщение **grizzzlly** » 19 окт 2016, 09:02

Михайло писал(а):
grizzzlly писал(а): Движением автооператоров(пишем в регистр контроллера, он туда перемещается) и сбором данных управляет контроллер и отдает нам данные по Modbus TCP(хотя скорее мы их у него забираем).
Я может что-то не так понял, но Вам нужно переписать программу для контроллера/контроллеров. Это обычная для него/них задача. Что за контроллеры-то?

Какая задача обычная для контроллеров? У нас есть только тех процессы(набор ванн и время в них + параметры доп. оборудования), вы говорите что решать куда и в какой момент должны двигаться автооператоры, должен контроллер?

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

Циклограммы не сложные, их вообще нельзя построить, т.к. мы не знаем по какому тех. процессу пойдет следующий барабан, т.к. тех процессы разные и их может быть много. Одновременно на линии может находиться несколько барабанов(например штук 7) и у каждого может быть своя последовательность прохождения ванн.

Сообщение **Romcheg** » 19 окт 2016, 13:40

Вообще-то это нормально, когда всем процессом управляет контроллер. Если он в Вашей системе почему-то только как голое УСО без логики работает - так это целиком и полностью Ваша "ошибка". Верхний уровень в таком деле должен использоваться только как менеджер маршрутов и арбитр хода обработки текущих маршрутов в ПЛК, но никак не ведущая голова, которая и решения принимает и тут же мониторит/управляет всем КИПом.
Если чего-то нельзя формализовать в алгоритме - это значит, что "ОНО" вообще не рабочее и не может никак функционировать. Не хотите же Вы сказать, что у Вас вся технология - сплошная стохастическая кривая с непредсказуемыми ситуациями "сейчас вильнет влево"... Поэтому утверждать, что циклограммы вообще нельзя построить - не верю! (с)

Просто Вы неправильно подходите к методам решения задачи, вот и все...
И дело даже не в гибкости системы - Вашу задачу можно решить даже на обычном процедурном языке ST в ПЛК.

Очень настоятельно рекомендую ознакомиться вот с этим: https://ru.wikipedia.org/wiki/%D0%94%D0 ... 0%B8%D1%8F
Это именно для Вашего случая.

Сообщение **grizzzlly** » 19 окт 2016, 16:18

Romcheg писал(а): Вообще-то это нормально, когда всем процессом управляет контроллер. Если он в Вашей системе почему-то только как голое УСО без логики работает - так это целиком и полностью Ваша "ошибка". Верхний уровень в таком деле должен использоваться только как менеджер маршрутов и арбитр хода обработки текущих маршрутов в ПЛК, но никак не ведущая голова, которая и решения принимает и тут же мониторит/управляет всем КИПом.
Если чего-то нельзя формализовать в алгоритме - это значит, что "ОНО" вообще не рабочее и не может никак функционировать. Не хотите же Вы сказать, что у Вас вся технология - сплошная стохастическая кривая с непредсказуемыми ситуациями "сейчас вильнет влево"... Поэтому утверждать, что циклограммы вообще нельзя построить - не верю! (с) Просто Вы неправильно подходите к методам решения задачи, вот и все...
И дело даже не в гибкости системы - Вашу задачу можно решить даже на обычном процедурном языке ST в ПЛК.

Очень настоятельно рекомендую ознакомиться вот с этим: https://ru.wikipedia.org/wiki/%D0%94%D0 ... 0%B8%D1%8F
Это именно для Вашего случая.

Такое ощущение, что вы мои сообщения кусками читаете.
1. Программу мы написали.
2. Вопрос был о том, есть ли решения в которых подобные задачи можно реализовывать быстрее.
3. Программированием контроллеров мы не занимаемся, тут этим занимаются другие люди. На вопрос почему, могу только ответь: "Ну вот как то так"
4. По циклограммам. Для каждого из возможных вариантов их рассчитать нельзя, потому что слишком долго это делать вручную. Кроме того заказчики требуют, чтобы они могли создавать свои тех. процессы, в которых задавали бы просто наборы ванн и время выдержки в них. Если вы знаете алгоритм или программу, которая на лету может строить/перестраивать циклограммы, очень рад буду если вы поделитесь.

Я могу ошибаться (так как не знаю Вашу систему досконально), но мне кажется, что часть логики нужно переложить на контроллеры. Примерно так: у Вас есть ряд циклограмм обработки изделия, программа на C# должна лишь сообщать контроллерам информацию о текущем шаге циклограммы данного изделия и о параметрах обработки на текущем шаге (температура, время выдержки и т.п.). Контроллер, зная, где сейчас находится изделие и что с ним нужно сделать в плане обработки, выбирает маршрут (скорее всего жадный выбор маршрута - "до ближайшего свободного"), обеспечивает бесконфликтное перемещение по маршруту, управляет процессом обработки, контролирует параметры, время обработки, выдает сигнал готовности программе С#, чтобы произошел переход на следующий шаг циклограммы.
В принципе со мной согласятся все участники форума, это делается обычно именно так. А то получается контроллер у Вас выполняет роль глупого передатчика команд. К тому же программисты контроллеров как-то неоправданно расслабились.

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

Обычно контроллеры не выполняют задачи:
- поисковой оптимизации, перебора
- сложных вычислений в циклах

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

Сообщение **Romcheg** » 19 окт 2016, 21:19

grizzzlly писал(а): Такое ощущение, что вы мои сообщения кусками читаете.
1. Программу мы написали.
2. Вопрос был о том, есть ли решения в которых подобные задачи можно реализовывать быстрее.
3. Программированием контроллеров мы не занимаемся, тут этим занимаются другие люди. На вопрос почему, могу только ответь: "Ну вот как то так"
4. По циклограммам. Для каждого из возможных вариантов их рассчитать нельзя, потому что слишком долго это делать вручную. Кроме того заказчики требуют, чтобы они могли создавать свои тех. процессы, в которых задавали бы просто наборы ванн и время выдержки в них. Если вы знаете алгоритм или программу, которая на лету может строить/перестраивать циклограммы, очень рад буду если вы поделитесь.

1.2. Поздравляю, теперь пишите их точно также дальше.Зачем обращаться за помощью, если заранее считаете свой путь самым правильным? Вы не найдете нигде системы, которая решит Вам Вашу задачу быстрее, вернее - систем валом, почти любая, но решить ее в любой из них придется грамотно 1 раз, потом просто тиражировать с минимальным временем переконфигурирования на новый объект.
3. Знаете, у нас есть автомобиль и мы хотим, чтобы он стал гоночным и ездил быстрее, вот только про двигатель нам ничего не надо говорить - им занимаемся не мы и туда лучше не лазить. Просто "ну вот как-то так"...

Пока Вы всю систему как единый комплекс не начнете рассматривать - грош цена любым попыткам ее оптимизировать будет.
4. Вам уже сказали, что не надо их рассчитывать для каждого варианта! Вы снова не стой стороны решать проблему пытаетесь. Вы про "декомпозицию" почитали? Ваша технологическая линия - это набор подсистем, если выделить из общей задачи эти подсистемы, то их потом можно будет легко комбинировать в любые последовательности и виды вариантов, которые Вы пытаетесь просчитывать. А маршруты - это наборы правил перемещения по этим последовательностям подсистем, причем они могут быть гибкими, и задаваться вообще без вмешательства в саму систему.

И не думайте, что кто-то Вам тут исходный код алгоритма, или программу решения Вашей задачи тут выложит. Методы решения - да, посоветуют.

Сообщение **grizzzlly** » 19 окт 2016, 23:16

Romcheg писал(а): 1.2. Поздравляю, теперь пишите их точно также дальше.Зачем обращаться за помощью, если заранее считаете свой путь самым правильным? Вы не найдете нигде системы, которая решит Вам Вашу задачу быстрее, вернее - систем валом, почти любая, но решить ее в любой из них придется грамотно 1 раз, потом просто тиражировать с минимальным временем переконфигурирования на новый объект.

И не думайте, что кто-то Вам тут исходный код алгоритма, или программу решения Вашей задачи тут выложит. Методы решения - да, посоветуют

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

Romcheg писал(а): 3. Знаете, у нас есть автомобиль и мы хотим, чтобы он стал гоночным и ездил быстрее, вот только про двигатель нам ничего не надо говорить - им занимаемся не мы и туда лучше не лазить. Просто "ну вот как-то так"... Пока Вы всю систему как единый комплекс не начнете рассматривать - грош цена любым попыткам ее оптимизировать будет.
.

Скорее есть автомобиль и мы хотим чтобы он ездил сам. Поэтому нам совершенно не обязательно знать, как работает двигатель. Это называется абстракция данных. https://ru.wikipedia.org/wiki/Абстракция_данных

grizzzlly, Вам нужна концепция, а не инструменты. Я предлагал выделить все действия в рамках одного шага циклограммы (=понятный завершенный шаг технологического процесса) в отдельную функцию, исполнение которой возложить на контроллер (ну если хотите пусть это крутится в отдельной функции программы С#).

P.S. Romcheg Вам продаст инструмент SCADA+, попробуйте им гвозди забивать.

P.P.S. Практика показывает, что инженеры/программисты/электрики АСУТП лучше декомпозируют системы, чем сишно-паскалевские программисты. Причина в том, что сишные программисты не привыкли работать с системами реального времени, то есть нет задачи - нет опыта. У них и обработка инструкций и функций производится последовательно, а не как в контроллерах - параллельно (псевдопараллельно).

Умилительно. Руководство говорит, что 2 месяца долго. Ок. А вы хотите получить волшебный инструмент (я бы даже сказал немного САПР), который позволит делать тоже но за 2 недели. Ок.
А не приходит ли руководству в голову, что этот волшебный инструмент нужно создать? И что трудозатраты на его создание, будут на порядок, скорее даже несколько порядков, больше, чем вы тратите на одну систему сейчас. Что это потребует жёсткой внутренней стандартизации (то есть никакой истории, что заказчик попросил его любимую ванну от времён НЭП встроить в процесс, не будет)? Что после обкатки этой системы вас можно уволить? ведь для внедрений такой системы нужны наладчики, а не программисты. Что постановкой задачи, выбором подходов и инструментов, декомпозицией должен заниматься ГИП, или архитектор системы, или тех дир, или собственник, а не программисты?
А ещё такой инструмент можно гипотетически купить. Чисто гипотетически :) И стоить он будет не как самолёт, а как авиа несущий крейсер Адмирал Кузнецов?
Что в любом случае это кап вложения. Готовы собственники их финансировать?
Полагаю, что схожие вопросы решены у поставщиков систем для перемещения багажа крупных авиа-хабов. Думаю, что люди шли к этим внедрениям десятилетиями. И вряд ли у истоков таких историй стояло "руководство", которое говорило своим программистам: что-то долго вы тут возитесь.

Сообщение **Romcheg** » 20 окт 2016, 08:25

grizzzlly писал(а):Скорее есть автомобиль и мы хотим чтобы он ездил сам. Поэтому нам совершенно не обязательно знать, как работает двигатель. Это называется абстракция данных. https://ru.wikipedia.org/wiki/Абстракция_данных

Вот - именно здесь и кроется Ваша основная ошибка! Вы пытаетесь подойти к решению задачи как программист...
Вам очень правильно на это обратил внимание Михайло. И очень верно все разложил по полочкам alex_ugrumov.

Сообщение **grizzzlly** » 20 окт 2016, 10:00

Михайло писал(а): Вам нужна концепция, а не инструменты. Я предлагал выделить все действия в рамках одного шага циклограммы (=понятный завершенный шаг технологического процесса) в отдельную функцию, исполнение которой возложить на контроллер (ну если хотите пусть это крутится в отдельной функции программы С#).

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

grizzzlly писал(а): В итоге дали задание выяснить не изобретаем ли мы велосипед и нет ли готовых решений, которые позволили бы данные задачи решать в короткий срок(2 недели). Собственно на счет таких решений и требуется консультация.

Михайло писал(а): P.P.S. Практика показывает, что инженеры/программисты/электрики АСУТП лучше декомпозируют системы, чем сишно-паскалевские программисты. Причина в том, что сишные программисты не привыкли работать с системами реального времени, то есть нет задачи - нет опыта. У них и обработка инструкций и функций производится последовательно, а не как в контроллерах - параллельно (псевдопараллельно).

Ну вообще то сишарпные, и не только, программисты, давно используют многопоточность. Вы видимо плохо знакомы с современным программированием.

P.s. В общем то требовался ответ либо, да есть такая система, так то называется, либо то что написал alex_ugrumov

Сообщение **Dotarev** » 20 окт 2016, 12:08

Вам нужно что-то типа такого?

grizzzlly писал(а): Ну вообще то сишарпные, и не только, программисты, давно используют многопоточность. Вы видимо плохо знакомы с современным программированием.

Почему? Я и с таким сталкивался. Это не то! У нас тут в контроллерах код в пределах одного программного модуля выполняются параллельно, распараллеливание выполняется само собой. На самом деле ничего особого, просто гораздо нагляднее.

Сообщение **shula638** » 30 ноя 2016, 11:04

Работая на нескольких объектах на монтаже у немцев подсмотрел интересную идею- есть скада в частности ВИНСС в ней реализованы куча окон под вызываются только те что нужны для конкретного механизма там же можно делать и рецепты да в принципе любой алгоритм на С и визуал бейсике Также и в контролерах линии куч блоков которые не вызываются программой в данном механизме.
По этому и проще адаптировать надо одни функции и комплектация линии на тебе одни окна управления и блоки программы,
надо другая комплектация вот тебе другие.
Я понял что у вас участки технологической цепи однотипные только последовательность и количество меняется то почему бы вам не пойти тем же путем.