Comments 25
дистрибутивы нашего отечественного партнера ArenadataА почему не дистрибутивы от Cloudera? Кроме цены поддержки, которая очевидно ниже, какие есть отличия? Остальной стэк прекрасен. При этом некоторые компоненты имеют корни в Cloudera, а выбор стороннего дистрибутива немного удивляет.
Честно говоря, цена поддержки здесь меньше всего играет роль. Мы очень долго занимались выбором дистрибутива для этих проектов, это был очень не простой вопрос для нас, так как у нас есть проектный опыт и на Cloudera, и на HW, и на Arenadata. Но глобально было три аргумента:
1. Набор продуктов. Когда мы начинали эти проекты, Cloudera еще не анонсировала свой Cloudera DataFlow, а мы видели, что для наших задач прекрасно подходит NiFi. Аналогичная же история с Phoenix. Поэтому вариант c Cloudera не подходил.
2. Мы делаем достаточно инновационные штуки, и в таких случаях очень удобно держать плотный контакт с вендором. При этом HW на тот момент был не очень заинтересован в российском рынке.
3. У многих компаний, для кого мы создавали это решение, есть фокус на импортозамещение. Соответственно, в этих компаниях не получится использовать другой дистрибутив, когда есть отечественный аналог. Невозможно будет пройти архитектурный комитет.
1. Набор продуктов. Когда мы начинали эти проекты, Cloudera еще не анонсировала свой Cloudera DataFlow, а мы видели, что для наших задач прекрасно подходит NiFi. Аналогичная же история с Phoenix. Поэтому вариант c Cloudera не подходил.
2. Мы делаем достаточно инновационные штуки, и в таких случаях очень удобно держать плотный контакт с вендором. При этом HW на тот момент был не очень заинтересован в российском рынке.
3. У многих компаний, для кого мы создавали это решение, есть фокус на импортозамещение. Соответственно, в этих компаниях не получится использовать другой дистрибутив, когда есть отечественный аналог. Невозможно будет пройти архитектурный комитет.
1-2. Вы правы, я забыл, что HW был куплен и начал растворятся в Cloudera лишь год назад.
3. Так и подумал, что импортозамещение — единственное объяснение :-)
PS: если NDA позволит, то было бы круто посмотреть под капот решения (на чем писали в Spark, объем и количество потоков интеграций, интересные примеры кода и т.д.)
3. Так и подумал, что импортозамещение — единственное объяснение :-)
PS: если NDA позволит, то было бы круто посмотреть под капот решения (на чем писали в Spark, объем и количество потоков интеграций, интересные примеры кода и т.д.)
Вот как могут выглядеть отчеты BI
А вот интерфейс SCADA
Вот как может выглядеть кит:
кит.img
А вот табурет:
старый_табурет.img
Время реакции диспетчера на инцидент обычно не должно превышать 30 секунд, но с таким интерфейсом уложиться непросто. Никаким BI здесь и не пахнет.
И не должно там пахнуть BI.
Не буду спорить, многие интерфейсы систем АСУ ТП «режут глаз» сильнее, чем того требуют информативность и обратная совместимость (попробуй объясни 50-ти летней тете Маше что теперь давление в трубопроводе будет отображаться на другой стороне экрана, а после того как объяснишь — попробуй поверить в то, что она точно не перепутает это в критической ситуации), но сравниваются всё-таки разные вещи.
Supervisory Control And Data Acquisition — диспетчерское управление и сбор данных (Wiki).
Когда, в бытность еще студентом, я рисовал интерфейсы для реального заводского участка, были требования по информативности для оператора установки. Если он увидит перед собой интерфейс костюма Тони Старка он, наверное, ахнет (одобрительно при возрасте до 30-ти, матерно в противном случае), но это нисколько не поможет ему принимать решения в процессе работы. Интуитивность интерфейсов хороша, но только до того момента, пока он, интерфейс, предоставляет всю необходимую для принятия решения информацию. А такой информацией могут быть десятые (и меньшие) доли процента от какого-либо показателя или даже комбинация из нескольких параметров. А всего этих параметров могут быть десятки.
BI — уровень принятия решений в бизнесе, а не на технологической установке.
Скорее всего авторы понимали всё это, но в статье акценты расставлены странно.
Идея, что BI подходит только для принятия решений в бизнесе, мне видится не совсем точной. Действительно, это инструмент, который родился из решения задач бизнес-аналитики. Но мне кажется, что идея немного посмотреть вокруг и принести новые практики и инструменты из других отраслей — это то, что сейчас происходит во многих сферах и именно это дает существенный эффект в развитии. И чем более консервативна отрасль, тем больше аргументов это сделать.
Вы довольно удачно подметили: прямое сравнение в лоб BI и SCADA — это не совсем корректно. Но мы действительно сталкивались с ситуациями, когда в весьма современных компаниях, в прекрасно оборудованных диспетчерских на гигантских настенных плазмах отображались настолько неинтуитивные и неинформативные интерфейсы (тут мы сходились с мнениями с диспетчерами), что для нас это выглядело дико. То есть способ отображения информации мешал ее восприятию. BI инструменты сейчас позволяют отображать информационные панели в близком к реальному времени, но самое главное — они позволяют сделать это эргономично для пользователя, что, как мне видится, важно для оперативного реагирования.
Мы не призываем срочно менять одно на другое, если что :) Если тетя Маша всю жизнь эффективно работала с этим интерфейсом, то худшим решением будет идти и перевнедрять его на что-то модное. Но я верю, что за счет новых, часто непривычных подходов можно получать новое value. Если подходить с умом, конечно.
И в любом случае, BI тут — это лишь один из инструментов аналитики промышленных данных. Если вы собрали все промышленные данные в одном месте, интегрировали в эту среду данные из бизнес-систем, то для вас открываются весьма большие возможности, точно не ограничивающиеся их визуализацией.
Вы довольно удачно подметили: прямое сравнение в лоб BI и SCADA — это не совсем корректно. Но мы действительно сталкивались с ситуациями, когда в весьма современных компаниях, в прекрасно оборудованных диспетчерских на гигантских настенных плазмах отображались настолько неинтуитивные и неинформативные интерфейсы (тут мы сходились с мнениями с диспетчерами), что для нас это выглядело дико. То есть способ отображения информации мешал ее восприятию. BI инструменты сейчас позволяют отображать информационные панели в близком к реальному времени, но самое главное — они позволяют сделать это эргономично для пользователя, что, как мне видится, важно для оперативного реагирования.
Мы не призываем срочно менять одно на другое, если что :) Если тетя Маша всю жизнь эффективно работала с этим интерфейсом, то худшим решением будет идти и перевнедрять его на что-то модное. Но я верю, что за счет новых, часто непривычных подходов можно получать новое value. Если подходить с умом, конечно.
И в любом случае, BI тут — это лишь один из инструментов аналитики промышленных данных. Если вы собрали все промышленные данные в одном месте, интегрировали в эту среду данные из бизнес-систем, то для вас открываются весьма большие возможности, точно не ограничивающиеся их визуализацией.
В такой постановке вопроса я полностью согласен с вами!
Все только выиграют если разработчики автоматизации и операторы будут иметь удобные, современные и гибкие инструменты для визуализации процессов, а не только вырвиглазные, громоздкие и несущие на себе тяжесть десятилетий TIA Portal-ы.
Хочется только пожелать вам удачи, т.к. и промышленному ПО давно пора перейти в 21-й век :)
Все только выиграют если разработчики автоматизации и операторы будут иметь удобные, современные и гибкие инструменты для визуализации процессов, а не только вырвиглазные, громоздкие и несущие на себе тяжесть десятилетий TIA Portal-ы.
Хочется только пожелать вам удачи, т.к. и промышленному ПО давно пора перейти в 21-й век :)
Но я верю, что за счет новых, часто непривычных подходов можно получать новое value.
Это какой то сленг вашей области?
Потому как с точки зрения программиста фраза выглядит странно. «Получить новое значение» — и что?
а что старые интерфейсы АСУ ТП выдавали информацию как есть с датчиков, однако можно с внедрением умной аналитики, комбинирования показателей со всех систем и выставления порогов пробоя просто упростить весь интерфейс до одной лампочки — красная=тревога, желтая=обратить внимание, зеленая все хорошо
и показывать именно точечно показатели которые выходят из пределов допустимых значений, а не в норме
и показывать именно точечно показатели которые выходят из пределов допустимых значений, а не в норме
Если интерфейс можно сократить до одной лампочки то оператор там становится лишним, а значит и интерфейс SCADA отпадает, т.к. смотреть на него уже некому :)
Конечно, эта лампочка просто будет показываться на следующем уровне иерархии (если узел не будет отдан под управление программному/аппаратному автомату), рядом с другими лампочками. Но если вдруг трех цветов станет недостаточно то мы опять переходим к численным показателям, т.к. с цветом мозг человеческий работает по правилам, неприменимым для принятия операционных решений с техническими системами.
Хотелось бы, чтобы так было, но на практике все более или менее сложные системы, с которыми я сталкивался, требуют того, чтобы оператор видел точные показатели всегда. Потому что инерциальность и сложность некоторых из них настолько велика, что оператор без «лога» двух последних часов у себя в голове просто не сможет понять что, где и когда пошло не так.
На правах свободного полета творческой мысли, мне кажется что в самом описании проблемы кроется противоречие.
Как только мы сможем сократить вывод до красной/зеленой лампочки — мы автоматически переходим на следующий уровень иерархии и проблема снова восстает уже на нем. Единственным возможным вариантом, при котором можно будет сказать «мы победили» будет только описанная в статье ситуация, доведенная до крайности:
Сидят инженер, менеджер, аналитик и директор и смотрят на красивые и понятные графики, светящиеся всеми цветами радуги, попадающие прямо в подсознание, в котором складывается верная и полная картина происходящего.
Но, к сожалению, это кажется мне скорее зарисовкой для фантастического рассказа, пока что.
Конечно, эта лампочка просто будет показываться на следующем уровне иерархии (если узел не будет отдан под управление программному/аппаратному автомату), рядом с другими лампочками. Но если вдруг трех цветов станет недостаточно то мы опять переходим к численным показателям, т.к. с цветом мозг человеческий работает по правилам, неприменимым для принятия операционных решений с техническими системами.
показывать именно точечно показатели которые выходят из пределов допустимых значений, а не в норме
Хотелось бы, чтобы так было, но на практике все более или менее сложные системы, с которыми я сталкивался, требуют того, чтобы оператор видел точные показатели всегда. Потому что инерциальность и сложность некоторых из них настолько велика, что оператор без «лога» двух последних часов у себя в голове просто не сможет понять что, где и когда пошло не так.
На правах свободного полета творческой мысли, мне кажется что в самом описании проблемы кроется противоречие.
Как только мы сможем сократить вывод до красной/зеленой лампочки — мы автоматически переходим на следующий уровень иерархии и проблема снова восстает уже на нем. Единственным возможным вариантом, при котором можно будет сказать «мы победили» будет только описанная в статье ситуация, доведенная до крайности:
Сидят инженер, менеджер, аналитик и директор и смотрят на красивые и понятные графики, светящиеся всеми цветами радуги, попадающие прямо в подсознание, в котором складывается верная и полная картина происходящего.
Но, к сожалению, это кажется мне скорее зарисовкой для фантастического рассказа, пока что.
ну как сказать, белковые организмы должны делать то, что делают хорошо они (эскалация руководсту, реакция на мониторинг, расследование с ответственными спецами на самом нижнем уровне — работа с людьми по сути)
А кремниевые организмы должны делать то, в чем хороши они — сбор, хранение, обработка и корреляция данных, реалтайм обработка и визуализация и т.д. — то что нужно делать монотонно, аккуратно и всегда, без перерывов на обед и туалет.
и эту работу можно детализировать/аггрегировать по уровням: датчик/оборудование/цех/завод и т.д. и показывать каждому руководителю свои «лампочки» по их зоне ответственности
А кремниевые организмы должны делать то, в чем хороши они — сбор, хранение, обработка и корреляция данных, реалтайм обработка и визуализация и т.д. — то что нужно делать монотонно, аккуратно и всегда, без перерывов на обед и туалет.
и эту работу можно детализировать/аггрегировать по уровням: датчик/оборудование/цех/завод и т.д. и показывать каждому руководителю свои «лампочки» по их зоне ответственности
Кой-чего можно почерпнуть из dark cockpit concept в авионике. Лампочки неподелу не горят. А когда горят — правильным цветом.
Да, заточить так интерфейс — очень много работы.
Интересно, есть гайдлайне по теме? Поделитесь если знаете.
Я не разглядел в статье примеров ваших работ, где видна дружба Big Data и промышленности. Если таковые есть — где можно на них поглазеть? Хочется верить, что у вас есть неплохие результаты =)
Увидел замечательное заглавное фото. С вполне характерными станками. Начал читать. Но, увы, так и не нашёл вменяемой информации на тему Как свести данные промышленных систем (которые толком никто не собирает) куда-нибудь.
Особено, в условиях, когда у станка (например — изображеном на заглавном фото) нет никаких штатных интерфейсов.
Вот какие есть у Вас замечательные кейсы по подключению нештатных датчиков (чтобы получить хоть-какую-нибудь инфомрацию со станка) и прочие низкоуровневые проблемы — и хотелось бы видеть
Особено, в условиях, когда у станка (например — изображеном на заглавном фото) нет никаких штатных интерфейсов.
Вот какие есть у Вас замечательные кейсы по подключению нештатных датчиков (чтобы получить хоть-какую-нибудь инфомрацию со станка) и прочие низкоуровневые проблемы — и хотелось бы видеть
---Не каждое производство дошло до технологического уровня Tesla
Это наверное была шутка?
Несколько недель назад американский телеканал деловых новостей CNBC со ссылкой на «многочисленные» анонимные источники «из числа нынешних и бывших сотрудников Tesla» рассказал о проблемах на Гигафабрике 1 в Неваде. Они рассказали, что сборка на конвейере частично выполняется дедовскими методами — вручную, практически без использования роботов.
habr.com/ru/post/411041
Это наверное была шутка?
Несколько недель назад американский телеканал деловых новостей CNBC со ссылкой на «многочисленные» анонимные источники «из числа нынешних и бывших сотрудников Tesla» рассказал о проблемах на Гигафабрике 1 в Неваде. Они рассказали, что сборка на конвейере частично выполняется дедовскими методами — вручную, практически без использования роботов.
habr.com/ru/post/411041
Spark в контексте near real time смотрится странно. Если это просто спарк, не стриминг, то при запуске на хадупе он попадает в обычные очереди планировщика Yarn, где ни о каком near real time даже близко речи не идет. Можете пояснить?
Конечно, мы используем Spark Streaming, который позволяет работать с относительно небольшой latency. Плюс сейчас уже существует функциональность Continuous Streaming, что позволяет снизить latency еще больше.
Мы еще смотрели в сторону Akka и Flink, но сейчас остановились на Spark. Во многом потому, что на рынке существует много людей с неплохими компетенциями по Spark и нам этот фреймворк был очень хорошо знаком на момент начала этих проектов.
Мы еще смотрели в сторону Akka и Flink, но сейчас остановились на Spark. Во многом потому, что на рынке существует много людей с неплохими компетенциями по Spark и нам этот фреймворк был очень хорошо знаком на момент начала этих проектов.
Советую взглянуть на System 1 от BN (GE), в которую помимо вибропараметров с рэка BN можно заводить и иные данные по технологическому процессу, а уже на основе их писать сценарии. При этом, насколько я помню, у них уже имеются немало заготовок по типовому роторному оборудованию.
Система подразумевает раздельное использование со SCADA, однако паставленную вами задачу вполне решает.
UFO just landed and posted this here
У нас в Казахстане Назарбаев выдвинул лозунг «ЦИФРОВИЗАЦИЯ производства», потом такое же повторил Путин. Думал почитав статью z пойму, что имеется ввиду под старыми подобными коммунизму лозунгами. Вот конвеерное производство Форда понятно сразу, это скорость выпуска продукции, понижение себестоимости продукции.
Но увы так и не понял, что они улучшили засунув свои дашборды в диспетчерcкую, которая не нуждается в графичках с элементами ML/BigData
Вот если бы Ваша система повлияла на скорость и удешевления выпуска продукции
Но увы так и не понял, что они улучшили засунув свои дашборды в диспетчерcкую, которая не нуждается в графичках с элементами ML/BigData
Вот если бы Ваша система повлияла на скорость и удешевления выпуска продукции
Давайте расскажу на примере проектов, на основании которых написана эта статья.
Мы решали задачи двух подразделений – цифровизаторов и производства. Перед цифровизаторами стояла задача сделать систему, в которой агрегированы все данные производства и бизнес-данные. Для чего это нужно – понятно, если вы хотите построить какую-то аналитику, какие-либо ML модели, вам сначала необходимо собрать все данные в одном месте. Но на практике сложно решать задачу цифровизаторов, не дав никакой ценности производству. Такие проекты обязательно должны иметь прикладную часть.
И это как раз это один из бизнес кейсов использования всей этой техники под названием bigdata. Система может мониторить не только показатели оборудования (давление, температуру в печи и т.д.) но и показатели качества как сырья, так и готовой продукции. На текущем шаге мы увязывали эти показатели в рамках технологического процесса, так у операторов есть возможность быстро принимать управленческие решения, и не допускать или снижать % возможного брака продукции и повышать качество. На текущий момент также прорабатывается один из кейсов оптимизации режимов работы оборудования с целью повышения скорости изготовления продукции. В данном кейсе как раз прямой экономический эффект, чем быстрее производиться продукция, тем меньше общехозяйственных затрат приходиться на единицу продукции, соответственно производство становиться эффективнее.
Мы решали задачи двух подразделений – цифровизаторов и производства. Перед цифровизаторами стояла задача сделать систему, в которой агрегированы все данные производства и бизнес-данные. Для чего это нужно – понятно, если вы хотите построить какую-то аналитику, какие-либо ML модели, вам сначала необходимо собрать все данные в одном месте. Но на практике сложно решать задачу цифровизаторов, не дав никакой ценности производству. Такие проекты обязательно должны иметь прикладную часть.
И это как раз это один из бизнес кейсов использования всей этой техники под названием bigdata. Система может мониторить не только показатели оборудования (давление, температуру в печи и т.д.) но и показатели качества как сырья, так и готовой продукции. На текущем шаге мы увязывали эти показатели в рамках технологического процесса, так у операторов есть возможность быстро принимать управленческие решения, и не допускать или снижать % возможного брака продукции и повышать качество. На текущий момент также прорабатывается один из кейсов оптимизации режимов работы оборудования с целью повышения скорости изготовления продукции. В данном кейсе как раз прямой экономический эффект, чем быстрее производиться продукция, тем меньше общехозяйственных затрат приходиться на единицу продукции, соответственно производство становиться эффективнее.
Sign up to leave a comment.
Как подружить промышленность и big data