Комментарии 14
Речь идет о APC?
Больной для меня вопрос, отвечу подробно :)
В общем и целом, с точки зрения назначения — у APC и наших разработок оно одно и тоже — управлять (по возможности оптимально) процессом производства.
Различия такие:
А вообще, я считаю, что в один прекрасный момент оба подхода должны соединиться в один -наши или аналогичные решения должны перепрыгнуть на контроллер. Или остаться жить на серверах, а контроллеры стать простыми исполнительными механизмами. Но до тех пор, пока будет сильно разниться степень автоматизации промышленности, будут жить оба подхода.
В общем и целом, с точки зрения назначения — у APC и наших разработок оно одно и тоже — управлять (по возможности оптимально) процессом производства.
Различия такие:
- Сигналы управления наших систем носят рекомендательный характер, и, даже если и попадают назад в АСУТП, то не идут на исполнительные контроллеры. В отличие от APC, которые именно там и «живут» и управляют процессом непрерывно — что дает, конечно же, больший эффект. Но почти всегда мы внедряемся там, где степень автоматизации небольшая.
- APC (обычно) вешаются на несколько критичных установок, в то время как наши системы анализируют процесс целиком для выдачи оптимальных режимов, используя в т.ч. данные по стоимости сырья, что далеко не всегда могут APC.
- APC обычно должно быть почти всегда или того же производителя что и АСУТП, или как минимум лицензировано им. Кроме того, оно должно быть лицензировано производителем установки. Нам не требуется ни того, ни другого.
- В APC обычно вшит закон управления установкой, относительно неизменный со временем (в плане адаптации под деградацию оборудования и учет ремонтов). Наш подход другой, описан в статье. Хотя про APC не так все однозначно — тут конечно же надо смотреть уже на конкретных производителей типа Honeywell, Yokogawa и т.д., они же тоже не стоят на месте
- Обычно внедрение APC в силу перечисленных фактов, особенно для предприятий с низким уровнем автоматизации, плюс стоиомость контроллеров — оказывается сильно дороже. Повторюсь, обычно. Нужно считать в каждом конкретном случае.
А вообще, я считаю, что в один прекрасный момент оба подхода должны соединиться в один -наши или аналогичные решения должны перепрыгнуть на контроллер. Или остаться жить на серверах, а контроллеры стать простыми исполнительными механизмами. Но до тех пор, пока будет сильно разниться степень автоматизации промышленности, будут жить оба подхода.
Есть законы, теоретические или эмпирические, системы дифференциальных уравнений и огромный пласт знаний, которые были созданы физиками и химиками. Эти знания используются при проектировании установок и в общем более-менее неплохо описывают производственный процесс.
Было бы интересно посмотреть на практическую реализацию и эффективность по сравнению с APC.
Планируете рассматривать способы слияния APC и ваши алгоритмы для увеличения производительности?
К сожалению, крайне сложно собрать репрезентативную выборку, чтобы иметь численные сравнения. Самому бы хотелось такую иметь. Так что надо сказать честно — пока все рассуждения на уровне заявляемых вендорами и нами эффектов и сопоставления со стоимостью таких внедрений.
И да, как я уже сказал, скорее всего разные подходы должны слиться в один, но пока каких-то конкретных успехов тут нет ни у одной из сторон. Пока есть намерения и декларации :)
И да, как я уже сказал, скорее всего разные подходы должны слиться в один, но пока каких-то конкретных успехов тут нет ни у одной из сторон. Пока есть намерения и декларации :)
… В зависимости от того, какого качества лом мы туда засыпаем, какого размера его куски, можно регулировать силу тока, который подается для нагрева печи…
… Анализируя характеристики конкретного материала, мы понимаем, когда можно насыпать чуть меньше ферросплавов, чтобы получить заданное качество продукта и при этом сэкономить на ферросплавах...
Я, конечно, не настоящий сварщик, но в этих примерах — какие-то очевидные факты.
За таким, по-моему, и должны следить технологи?
При чем тут ML где достаточно элементарной логики?
Есть множество неочевидных параметров за которыми технологи не могут следить, которые влияют на получаемый продукт
Если взять идеально понимающего в процессах человека и посадить его перед монитором и заставить наблюдать и управлять процессом все время — конечно же, никакой ML дополнительно не нужен.
Проблем несколько — а) непрерывный контроль понимающим человеком — утопия, даже раз в полчаса подходить и смотреть/корректиррвать не у всех получается в силу совершенно разных причин, б) понимающий человек крайне быстро, со скоростью пропорциональной уровню понимания, идет вверх по должностям и перестает заниматься оперативным управлением установки, в) регламенты большинства предприятий устроены так, что операторы, которые действительно сидят и смортят на показания датчиков, отвечают за работу вверенной им установки (т.е. по оператору (точнее, обычно нескольким) на установку) только в пределах ее работы в заданных технологических режимах. Оптимальность текущего режима, не говоря уже о всем процессе, их не волнует, если говорить грубо.
Что касается логики работы самого процесса или установки — да, порой она бывает достаточно простая. Но почти всегда даже в самом простом процессе вылезает огромное количество нюансов, если вы хотите не просто смоделировать его работу, а управлять им, по возможности, оптимально. Там вылезают вопросы стоимости сырья (если используется разное), вопросы снижения ресурса оборудования из-за работы вблизи технологических режимов и т.п. Тут фокус сложности смещается с модели самого процесса (который действительно бывает простым) на процесс принятия решений/управления.
Проблем несколько — а) непрерывный контроль понимающим человеком — утопия, даже раз в полчаса подходить и смотреть/корректиррвать не у всех получается в силу совершенно разных причин, б) понимающий человек крайне быстро, со скоростью пропорциональной уровню понимания, идет вверх по должностям и перестает заниматься оперативным управлением установки, в) регламенты большинства предприятий устроены так, что операторы, которые действительно сидят и смортят на показания датчиков, отвечают за работу вверенной им установки (т.е. по оператору (точнее, обычно нескольким) на установку) только в пределах ее работы в заданных технологических режимах. Оптимальность текущего режима, не говоря уже о всем процессе, их не волнует, если говорить грубо.
Что касается логики работы самого процесса или установки — да, порой она бывает достаточно простая. Но почти всегда даже в самом простом процессе вылезает огромное количество нюансов, если вы хотите не просто смоделировать его работу, а управлять им, по возможности, оптимально. Там вылезают вопросы стоимости сырья (если используется разное), вопросы снижения ресурса оборудования из-за работы вблизи технологических режимов и т.п. Тут фокус сложности смещается с модели самого процесса (который действительно бывает простым) на процесс принятия решений/управления.
Правильно ли я понимаю: вы берете «размеченные» технологами завода данные как train и утверждаете, что с помощью ML находите на этих данных новое, более эффективное знание? А оно там есть?! И потом на трейне 105% accuracy?
Предложение нарушить технологию и получить профит напоминает мне предложение переходить улицу на красный свет — если последний год на этом светофоре никого не задавили, то ваш AI будет советовать игнорировать этот светофор.
И еще — если оператор послушал совета — нарушил технологию и тут беда, авария, трагедия — будет ли Zyfra отвечать за свои советы? Или как в СССР были такие — за всё переживают, но ни за что не отвечают- назывались «замполит».
И по O&G тоже сомнения — там всегда можно локально снизить давление в НКТ и получить прибавку дебита, но после обязательно спад или ремонт. Т.е. профит и доля Zyfra за счет качества скважины?
Предложение нарушить технологию и получить профит напоминает мне предложение переходить улицу на красный свет — если последний год на этом светофоре никого не задавили, то ваш AI будет советовать игнорировать этот светофор.
И еще — если оператор послушал совета — нарушил технологию и тут беда, авария, трагедия — будет ли Zyfra отвечать за свои советы? Или как в СССР были такие — за всё переживают, но ни за что не отвечают- назывались «замполит».
И по O&G тоже сомнения — там всегда можно локально снизить давление в НКТ и получить прибавку дебита, но после обязательно спад или ремонт. Т.е. профит и доля Zyfra за счет качества скважины?
Правильно ли я понимаю: ...
Неправильно. Нет цели получить новые знания как таковой. Есть цель построить две модели (в концепции RL они совмещены):
1. Модель процесса, которая а) учитывает известную физику процесса, б) достаточно точно воспроизводит процесс на доступных данных
2. Модель принятия решений с учетом того где мы находимся сейчас и какие возможности нам сейчас доступны, какой ожидаемый reward мы получим от каждого возможного действия.
Предложение нарушить технологию ...
Я изложил ровно обратное — не нарушать технологию. Для этого в т.ч. закладываются границы технологических режимов, за пределы которых рекомендации выходить не должны. Там есть нюансы, конечно же, с тем что если работать долго вблизи технологического предела, то это неизбежно приведет к более ранней поломке. Но обычно это также учитывается, правда чуть более тупо — бизнес-правилами (куда ж без них) в целевой функции модели принятия решений.
И по O&G тоже сомнения — там всегда можно локально снизить давление в НКТ и получить прибавку дебита, но после обязательно спад или ремонт.
Разумеется, что это учтено на уровне физической модели, плюс можно было бы дополнительно перестраховаться, выкрутив long- и short-term reward'ы (но мы пока обошлись без этого).
вы так и не ответили — train это данные технологов завода? Это то, что регистрируют их датчики, журналы и т.д. И оставьте физику в покое, отвечайте на конкретный вопрос.
Если предложенный режим не описан в технологии — это и есть нарушение. Технология выплавки это вам не опенсорс, там нельзя просто так внести изменения.
Если требуемый режим указан в технологии и рабочий у станка им не пользуется — причем тут AI, ИИ, машинное обучение и прочие умные слова?
И по O&G — есть утвержденная технологическая схема и у нее есть авторы и она утверждена в ГКЗ, Росприроднадзоре и Ростехнадзоре и как вы вносите в нее изменения?
ТОлкаете нефтяников на преступление или в ваших рекомендациях нет ничего существенного и их не нужно вносить в техсхему и защищать?
Если предложенный режим не описан в технологии — это и есть нарушение. Технология выплавки это вам не опенсорс, там нельзя просто так внести изменения.
Если требуемый режим указан в технологии и рабочий у станка им не пользуется — причем тут AI, ИИ, машинное обучение и прочие умные слова?
И по O&G — есть утвержденная технологическая схема и у нее есть авторы и она утверждена в ГКЗ, Росприроднадзоре и Ростехнадзоре и как вы вносите в нее изменения?
ТОлкаете нефтяников на преступление или в ваших рекомендациях нет ничего существенного и их не нужно вносить в техсхему и защищать?
Прежде всего, если вы хотите продолжить разговор, пожалуйста, снизьте градус ваших изречений.
Разумеется. Конечно же, это данные того производства, для которого реализуется система. Я лишь дополнительно сакцентировал внимание на том, что есть и другие источники данных, коим является, например, приближенный симулятор процесса.
Я же уже ответил — выхода за пределы установленных технологических режимов, установленных техрегламентами, не осуществляется. Система не может выдавать такие рекомендации в принципе.
Потому что вы, вероятно, путаете «нормы технологического регламента (НТР)» и «технологический режим (ТР)». НТР — это диапазон возможных технологических режимов работы, установленных технологически регламентом для данной установки. ТР — конкретный режим, совокупность управляемых и наблюдаемых параметров, характеризующих работы установки. Конечно же, установка работает в каком-то конкретном ТР (в пределах НТР). Рекомендации системы заключаются в переходах на другие ТР, которые также находятся в пределах НТР. Я не встречал такого, чтобы НТР состоял только из одного ТР.
Уже ответил — рекомендации работают строго в пределах регламента. Бывает, конечно же, и такое, что рекомендации упираются в предельные значения НТР в течение продолжительного времени (это пример не из O&G), в этом случае у самого владельца процесса могут возникнуть мысли или о внесении изменений в регламент, или о пересмотре целевой функции, которая оптимизируются (не учли какие-то долгосрочные эффекты или они имеют малый вес). В любом случае, это повод задуматься.
вы так и не ответили — train это данные технологов завода? Это то, что регистрируют их датчики, журналы и т.д. И оставьте физику в покое, отвечайте на конкретный вопрос
Разумеется. Конечно же, это данные того производства, для которого реализуется система. Я лишь дополнительно сакцентировал внимание на том, что есть и другие источники данных, коим является, например, приближенный симулятор процесса.
Если предложенный режим не описан в технологии — это и есть нарушение. Технология выплавки это вам не опенсорс, там нельзя просто так внести изменения.
Я же уже ответил — выхода за пределы установленных технологических режимов, установленных техрегламентами, не осуществляется. Система не может выдавать такие рекомендации в принципе.
Если требуемый режим указан в технологии и рабочий у станка им не пользуется — причем тут AI, ИИ, машинное обучение и прочие умные слова?
Потому что вы, вероятно, путаете «нормы технологического регламента (НТР)» и «технологический режим (ТР)». НТР — это диапазон возможных технологических режимов работы, установленных технологически регламентом для данной установки. ТР — конкретный режим, совокупность управляемых и наблюдаемых параметров, характеризующих работы установки. Конечно же, установка работает в каком-то конкретном ТР (в пределах НТР). Рекомендации системы заключаются в переходах на другие ТР, которые также находятся в пределах НТР. Я не встречал такого, чтобы НТР состоял только из одного ТР.
И по O&G — есть утвержденная технологическая схема и у нее есть авторы и она утверждена в ГКЗ, Росприроднадзоре и Ростехнадзоре и как вы вносите в нее изменения?
ТОлкаете нефтяников на преступление или в ваших рекомендациях нет ничего существенного и их не нужно вносить в техсхему и защищать?
Уже ответил — рекомендации работают строго в пределах регламента. Бывает, конечно же, и такое, что рекомендации упираются в предельные значения НТР в течение продолжительного времени (это пример не из O&G), в этом случае у самого владельца процесса могут возникнуть мысли или о внесении изменений в регламент, или о пересмотре целевой функции, которая оптимизируются (не учли какие-то долгосрочные эффекты или они имеют малый вес). В любом случае, это повод задуматься.
Мы с вами всё отлично понимаем и ничего не путаем.
— как происходит аугментация трейна?
Попробуйте ответить конкретно и без лирики/физики
— как происходит аугментация трейна?
Попробуйте ответить конкретно и без лирики/физики
Я знаю только один способ «конкретно» — это на примере. Возможно, у меня дойдут руки и я таки опубликую заметку на медиуме c примерами. Так что с «конкретно» вынужден разочаровать.
Тем не менее, попробую ответить не_конкретно. Потому что в каждом конкретном случае свои нюансы, у нас пока недостаточно примеров в этой области, чтобы систематизировать нюансы и говорить о наличии каких-то системных правил и подходов; кустарный метод, если хотите.
Итак, в ооочень грубом приближении подход такой:
Цикл 0.
Выбираем детализацию симулятора моделируемой среды. Представьте себе, что у вас есть эмпирический «закон», для простоты у вас среда элементарная и «закон» один (например, уравнения Навье-Стокса в общем виде для течения вязкой жидкости, или уравнения Жаботинского-Корзухина для описания колебательных химических реакций), в каждом законе есть возможность сделать какие-то допущения и упростить вид «закона», отбросив какие-то слагаемые уравнений. Итак, итерируемся по разным видам «законов».
Цикл 1 внутри Цикла 0.
Шаг 1. Берем трейн-сет Т1, на нем подбираем (тут можно целый пост о том, как именно) такие коэффициенты при компонентах «закона», при которых трейн Т1 описывается с минимальной ошибкой
Шаг 2. Генерируем синтетическую обучающую выборку ТS. Строим сетку в области НТР для управляемых параметров и в области наблюдаемых значений неуправляемых переменных. Далее или равномерно, или учитывая частоту встречаемости данных сочетаний параметров на исторических данных, или по какому-либо другом распределению частоты в этой сетке — семплируем нужное количество синтетических наблюдений при помощи полученного симулятора
Шаг 3. Экспериментируем с моделями — обучаем модели на выборке (или подвыборке) TS и реальных данных T2, генерируем фичи, подбираем гиперпараметры (доля синтетических данных — можно воспринимать как гиперпараметр или задавать жестко как степень «физичности» модели). По факту тут еще целое семейство циклов подбора параметров, но вроде досаточно понятно как мы получим в итоге некоторый набор моделей с лучшими значениями метрик на полусинтетическом трейн-сете. В случае нейронок есть, кстати, смысл обучать вначале на TS, а потом на T2 (только learning_rate нужно подзадрать, если использовался decay)
Шаг 4. Строим скор-борд моделей на данных выборки Т3.
Далее возвращаемся в Цикл 0 и в зависимости от выбранного подхода (от простого к сложному или наоборот) или убираем, или добавляем допущения. Последотвательность отработки допущений и наборы законов строятся человеком, разбирающимся в предметной области.
Как-то так получается модель.
При этом я оставил за кадром вопрос с выбором временного окна агрегации для описания процесса, тоже отдельный вопрос (если он не задан явно из каких-то других соображений).
Как-то так :)
Тем не менее, попробую ответить не_конкретно. Потому что в каждом конкретном случае свои нюансы, у нас пока недостаточно примеров в этой области, чтобы систематизировать нюансы и говорить о наличии каких-то системных правил и подходов; кустарный метод, если хотите.
Итак, в ооочень грубом приближении подход такой:
Цикл 0.
Выбираем детализацию симулятора моделируемой среды. Представьте себе, что у вас есть эмпирический «закон», для простоты у вас среда элементарная и «закон» один (например, уравнения Навье-Стокса в общем виде для течения вязкой жидкости, или уравнения Жаботинского-Корзухина для описания колебательных химических реакций), в каждом законе есть возможность сделать какие-то допущения и упростить вид «закона», отбросив какие-то слагаемые уравнений. Итак, итерируемся по разным видам «законов».
Цикл 1 внутри Цикла 0.
Шаг 1. Берем трейн-сет Т1, на нем подбираем (тут можно целый пост о том, как именно) такие коэффициенты при компонентах «закона», при которых трейн Т1 описывается с минимальной ошибкой
Шаг 2. Генерируем синтетическую обучающую выборку ТS. Строим сетку в области НТР для управляемых параметров и в области наблюдаемых значений неуправляемых переменных. Далее или равномерно, или учитывая частоту встречаемости данных сочетаний параметров на исторических данных, или по какому-либо другом распределению частоты в этой сетке — семплируем нужное количество синтетических наблюдений при помощи полученного симулятора
Шаг 3. Экспериментируем с моделями — обучаем модели на выборке (или подвыборке) TS и реальных данных T2, генерируем фичи, подбираем гиперпараметры (доля синтетических данных — можно воспринимать как гиперпараметр или задавать жестко как степень «физичности» модели). По факту тут еще целое семейство циклов подбора параметров, но вроде досаточно понятно как мы получим в итоге некоторый набор моделей с лучшими значениями метрик на полусинтетическом трейн-сете. В случае нейронок есть, кстати, смысл обучать вначале на TS, а потом на T2 (только learning_rate нужно подзадрать, если использовался decay)
Шаг 4. Строим скор-борд моделей на данных выборки Т3.
Далее возвращаемся в Цикл 0 и в зависимости от выбранного подхода (от простого к сложному или наоборот) или убираем, или добавляем допущения. Последотвательность отработки допущений и наборы законов строятся человеком, разбирающимся в предметной области.
Как-то так получается модель.
При этом я оставил за кадром вопрос с выбором временного окна агрегации для описания процесса, тоже отдельный вопрос (если он не задан явно из каких-то других соображений).
Как-то так :)
мне представляется другая картина.
Сидит оператор за пультом и смотрит на приборы и есть еще программка, которая тоже на эти приборы, и возможно еще какие-то, смотрит.
У оператора есть громадная таблица в виде: -если стрелка этого осциллографа качнулась влево, то вон ту ручку крути вправо и если вот та лампочка зажгласть — крути вот этот вентиль три раза влево. Или когда вот этот датчик загорится синим — подсыпь в домну 100 грамм из вон той мензурки.
И оператор не выбирает сам раздел из этой книги — ему конкретную таблицу из всей этой громадной книги приносит технолог.
Т.е. технолог получает задание сварить сталь «А», достает соответствующую таблицу, лаборант меряет состав того что привезли в сырье и технолог дает команду приготовить нужные компоненты и дает компанду на пуск процесса выдав оператору нужную таблицу — что, когда и как ему нажимать и крутить.
Теперь вопрос
меняет ли Zyfra содержимое этих таблиц? т.е. при синей лампочке лить не 100 грамм, а 98 и так возникает экономия?
Как Zyfra проводит анализ этой информации? Вопрос выше.
Про сказки, как операторы на рабочем месте в помощью калькулятора быстро находят решения нестационарных уравнений Навье–Стокса в естественных переменных и начинают крутить правильно вентили — расцениваю как шутку.
Как следует из цитаты
есть и другой вариант — сначала оператор варит сталь «А» по соответствующей таблице, потом читает рекомендации Zyfra меняет таблицу и начинает варить сталь «Б» и крутит вентили и сыпет добавки в другом порядке, а потом опомнившись, начинает опять варить сталь «А» и в результате получается сталь «АБ» или может «БА», но точно лучше и выгоднее.
Как то вот такой вот вывод из Вашего поста и комментов.
Сидит оператор за пультом и смотрит на приборы и есть еще программка, которая тоже на эти приборы, и возможно еще какие-то, смотрит.
У оператора есть громадная таблица в виде: -если стрелка этого осциллографа качнулась влево, то вон ту ручку крути вправо и если вот та лампочка зажгласть — крути вот этот вентиль три раза влево. Или когда вот этот датчик загорится синим — подсыпь в домну 100 грамм из вон той мензурки.
И оператор не выбирает сам раздел из этой книги — ему конкретную таблицу из всей этой громадной книги приносит технолог.
Т.е. технолог получает задание сварить сталь «А», достает соответствующую таблицу, лаборант меряет состав того что привезли в сырье и технолог дает команду приготовить нужные компоненты и дает компанду на пуск процесса выдав оператору нужную таблицу — что, когда и как ему нажимать и крутить.
Теперь вопрос
меняет ли Zyfra содержимое этих таблиц? т.е. при синей лампочке лить не 100 грамм, а 98 и так возникает экономия?
Как Zyfra проводит анализ этой информации? Вопрос выше.
Про сказки, как операторы на рабочем месте в помощью калькулятора быстро находят решения нестационарных уравнений Навье–Стокса в естественных переменных и начинают крутить правильно вентили — расцениваю как шутку.
Как следует из цитаты
Рекомендации системы заключаются в переходах на другие ТР, которые также находятся в пределах НТР.
есть и другой вариант — сначала оператор варит сталь «А» по соответствующей таблице, потом читает рекомендации Zyfra меняет таблицу и начинает варить сталь «Б» и крутит вентили и сыпет добавки в другом порядке, а потом опомнившись, начинает опять варить сталь «А» и в результате получается сталь «АБ» или может «БА», но точно лучше и выгоднее.
Как то вот такой вот вывод из Вашего поста и комментов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Зачем заводам машинное обучение