Аналитика АСУ ТП

Сообщение **it-yuko** » 13 дек 2016, 15:07

Уважаемые коллеги! Кто пытался, пробовал, планирует?
В постановке задачи эффективности функционирования автоматизированных систем управления и в частности АСУ ТП, одной из важных проблем является выявление пред аварийных ситуаций при эксплуатации ТА.
Для такой задачи мы рассматриваем методы машинного обучения и системы искусственного интеллекта, как современный механизм математического моделирования при выявлении и прогнозировании таких ситуаций.
В частности всегда можно сформировать вектор, как набор параметров оптимальных для функционирования системы и установить его значения для отнесения ТА в различные области эксплуатации — нормальное, пред аварийное, аварийное, катастрофическое и т.д.
Рассматривая уже формализованные данные, представленные в виде векторов состояний ТА, задача сводится к рассмотрению всех возможных наборов параметров таких векторов и пути возвращения (коррекция) к наиболее оптимальным.
Немаловажной проблемой здесь является так же, что на основе полученных данных и тестовых выборок сделать достоверный прогноз о поведении системы, развитие ее тренда и в дальнейшем предпринимать необходимые изменения для возвращения системы в безаварийное состояние — сигнализировать и дать рекомендации управляющему персоналу о необходимых изменениях в управлении.
Набор и агрегирование таких методов, как классификация, кластеризация, вероятностные оценки и нейронные сети эффективно применяются для таких задач, уменьшая аварийность и повышая эффективность эксплуатации.
Управляющий персонал получает информацию об изменениях на длительном интервале времени по представленным данным различных ситуаций в картах прогноза.
Хоть и рекламы ради, но отражает суть дела.

-------
А реклама у нас запрещена. Админ.

Сообщение **Jackson** » 13 дек 2016, 15:13

Пропустил исключительно из любопытства.

Итог: Вы что-то хотели предложить или просто сообщить?

Сообщение **rwg** » 13 дек 2016, 17:23

it-yuko писал(а): Уважаемые коллеги! Кто пытался?

После окончания учёбы несколько раз перечитал только что вышедшую тогда книгу Химмельблау "Обнаружение и диагностика неполадок в химических и нефтехимических процессах". Всё думал, как бы её применить на производстве аммиака или азотной кислоты. Ничего не придумал. А аналитика тогда диагностикой называлась.

Сообщение **Jackson** » 13 дек 2016, 17:53

rwg писал(а): Обнаружение и диагностика неполадок

А чем "обнаружение" отличается от "диагностики" ? ;)

Сообщение **it-yuko** » 13 дек 2016, 18:44

После окончания учёбы несколько раз перечитал только что вышедшую тогда книгу Химмельблау "Обнаружение и диагностика неполадок в химических и нефтехимических процессах". Всё думал, как бы её применить на производстве аммиака или азотной кислоты. Ничего не придумал. А аналитика тогда диагностикой называлась.

Очень даже не плохо.. Посмотрел только оглавление -- уже уровень..Где ее скачать? Тема та :)
Еще можно назвать применение математических методов, как там. Сути не меняет..

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

Сообщение **rwg** » 13 дек 2016, 18:46

TEB писал(а):А чем "обнаружение" отличается от "диагностики" ? ;)

Обнаружение - того, что уже случилось, а диагностика - того, что случится в ближайшее время. Например предстоящее сгорание двигателя можно диагностировать по поведению температуры его обмоток.

Сообщение **sprohor** » 13 дек 2016, 19:27

Два практически идентичных объекта ... один сделади в 2003-ем году, второй в 2007-ом году.
По АСУ ТП везде даём рекомендуемый срок эксплуатации 15 лет... по АСУ ТП пока нареканий нет.
А вот само железо и кабели на открытом воздухе ведут себя по разному:
по 2003-ему ни у кого претензий нет.
по 2007-му - приняли решение и будет капитальный ремонт ... трещины, расслоение... изоляция многих кабелей в труху* ... и прочие фефекты фикции. (*объективности ради срок эксплуатации кабеля КГ по паспорту 5 лет с даты производства ... но никто это не анализирует :)
В чём разница ?
Умеренный климат Питера, и неумеренный морской климат Белого моря...

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

Всё это от лукавого, в семейных рекламирующего какое то снадобье "А вдруг... а что..."
Если "аналитики" будут рисовать теоретические вектора не имея длительного опыта эксплуатации систем, то это никак не поможет предвидеть и предотвратить аварийные ситуации, как из-за теоретически возможных проблем с компонентами и элементами АСУ ТП, так и собственно с механизмами или оборудованием ТП.
В 2005-м году сдали объект... в 2007-ом эксплуататор позвонил и спросил, что за ..... происходит... система зависла и пришлось полностью её обесточивать... типа как комп дома...
попросил в следующий раз позвонить в момент зависа...
Через неделю позвонили... дистанционно по описанию выяснил, что мигают все светодиоды ошибки связи... вы там разъёмы подёргайте подкрутите... выключи-включи...
Через 5 дней звонок... завис... время есть ? давай попробуй с последнего шкафа пройтись и перевести переключатель штекера Профибус в положение отруба сегмента ON. Выяснил, что проблема начинается со шкафа N-2... BF просто мигает или по особенному ? Три при топа восемь прихлопов... вы там разъёмы подёргайте подкрутите... выключи-включи...
Лезу в инфосеть... на счёт танцевального ПА на станциях ET200S... инфосет ошарашила... по всему миру наблюдается завис именно с этим ПА... аппаратная проблема ?
Через 3 дня звонок... завис... вы там держитесь ... сегодня никак... завтра с утра прилечу с заменой...
Последняя предстукнетовская закладка сработала в 2012-м году.
Аналогично как предотвратить разгильдяйство и всёпохренизм и взаимные козни энергоснабженцев, асушников, киповцев и уборщиц ? Когда каждый отвечает только за своё а в целом ничего у них вместе сделать не получается... это не моё, это не моё, это не моё... ну шваброй провод оторвала... нечего было раскидывать...

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

Сообщение **AGorskiy** » 13 дек 2016, 21:00

rwg писал(а): TEB писал(а):
А чем "обнаружение" отличается от "диагностики" ? ;)

Обнаружение - того, что уже случилось, а диагностика - того, что случится в ближайшее время. Например предстоящее сгорание двигателя можно диагностировать по поведению температуры его обмоток.

Это был сарказм, TEB прекрасно знает различие. Вопрос бы адресован топик-стартеру. С чего он привел ссылку, просто поговорить или что-то предложить.....в этом духе вопрос.

Сообщение **Jackson** » 14 дек 2016, 00:16

it-yuko писал(а): А в целом берут архивы БД и по ним обучают систему, т.е вектор который я описал в первом сообщении привязывают к событиям..

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

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

Эта аналитика находит применение только в масштабных прогнозирующих подсистемах, когда процесс состоит в основном из регулирования по многим входящим переменным и многим же выходящим воздействиям. Пример - ядерный реактор. И там эти вещи с успехом применяются в качестве компонентов ПАЗ, а также на экспериментальных реакторах. Но ядерный реактор - вещь неординарная, это всегда большая и серьезная наука. Тут же, у нас здесь, обычные АСУТП. Пытались применять к системам попроще, на моей памяти это, например, судовой авторулевой - постоянные времени большие, процессы медленные, переменных мало, вычислительных мощностей больших не надо - казалось бы, бери и применяй. И пошли дальше, пробовали анализировать данные регистраторов данных рейсов с целью внесения своевременных навигационных поправок. Но не пошло - говоря нынешним языком, эти алгоритмы играли роль "британских учёных".

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

Тогда здесь вернулись к простой статистике и регламентам, ем и пользуются по сей день.

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

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

Эффективность была доказана практическими внедрениями. Одним из постулатов таких систем стал принцип "Не бывает сложных систем - бывают тёмные специалисты". Звучит это всё, возможно. несвязно и нелепо, но только потому что про сам принцип я умалчиваю - это, пока что, ноу-хау.

Так что, всю эту мою писанину можно резюмировать одним простым вопросом: что эти упомянутые автором вещи делают в обычной АСУТП?

it-yuko писал(а): Очень даже не плохо.. Посмотрел только оглавление -- уже уровень.

Да, только с внедрениями плоховато, как сказали (и я согласен). Так что ценность этой книги для практического применения сомнительна. Может для изысканий подойдёт, но в АСУТП нет научных изысканий, тут голая практика.

rwg писал(а): Обнаружение - того, что уже случилось, а диагностика - того, что случится в ближайшее время.

толковый словарь Ожегова писал(а): ДИАГНОСТИТОВАТЬ, -рую, -руешь; -ованный; сов. и несов., что (спец.). 1.Поставить (ставить) диагноз. Д. болезнь. 2. Установить (-навливать) техническое состояние машин, механизмов. 11 сущ. диагностирование, -я, ср. идиагностика, -и, ж. Техническая диагностика. Мастер по диагностике.

Толковый словарь Даля писал(а): ОБНАРУЖИВАТЬ, обнаружить что, раскрыть, открыть, обнажить; выводить наружу, делать видимым, явным, известным; | *узнавать и открывать тайны. Для верного осмотра дома, надо отодрать тес и обнаружить нижние венцы. Участник крамолы, во хмелю, сам первый обнаружил заговор. Этот человек никогда не обнаружит замыслов своих. -ся, быть обнаружену; | выказаться, объясниться, огласиться; стать явным, гласным. В ней смолоду обнаружился нрав крутой и злобный. В отлив обнаруживается подводное прибрежье. Обнаруживанье длит. обнаруженье окончат. обнаружка ж. об. действие по глаг. Обнаруживатель, -житель, -ница, кто обнаруживает что, открыватель, доноситель, оглашатель, уличитель.

Во-первых, к настоящему или будущему никакого отношения это не имеет, во-2-х, в чём же разница? :) То что Вы назвали - это прогнозирование в чистом виде, но никак не диагностика и не обнаружение. Вот Вы в автосервис на машине приехали на компьютерную диагностику - и каковы её результаты?
Успешность начинается с точных определений, если они изначально неверны то и результат всей работы можно будет нивелировать.

AGorskiy писал(а): Это был сарказм, TEB прекрасно знает различие. Вопрос бы адресован топик-стартеру.

Точно, и от топикстартера хотелось бы ответ и услышать.

it-yuko писал(а): Как раз тогда искусственный интеллект был на подьеме, во времена книги..

Он был на подъёме намного раньше, и с тех пор про него просто периодически вспоминают молодые исследователи, поэтому периодически создается впечатление какого-то подъёма, длительность этого периода - примерно лет 5-7. В техническом прикладном смысле в отношении ИИ ровным счётом ничего не меняется уже лет 40 точно, меняются только практические реализации в силу развития технологий. Но определённого ещё при царе горохе предельного потенциала ИИ эти технологии достигнут ещё очень нескоро, и процесс достижения давно остановился - нужен большой практический технологический опыт для дальнейшего движения, а он - опыт - постоянно меняется вместо того чтобы просто накапливаться. Так что я бы предостерёг от такого небрежного упоминания т.н. ИИ и его прикладного применения.

В общем, второе моё резюме тоже до банальности просто: "Не стоит произносить непонятные слова только потому, что они красивые - мало ли что может случиться." (с) Алиса в стране чудес, детская сказка.

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

Отправлено спустя 1 минуту 7 секунд:

sprohor писал(а): Сегодня новость была - студенты бауманки где то в московском сарае решили испытать какой то ракетный или реактивный движок... он взорвался и его обломок пролетев немерянное расстояние, пробил стену соседнего знания и оторвал кисть непричёмному 54-ти летнему мужику... По всей видимости, из-за ошибки при аналитических расчётах прогремел взрыв.

А это каким боком к топику относится?

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

Меня больше интересуют примеры внедрения.

[Ко всем присутствующим]: А вообще аналитика АСУТП кому-то нужна? Нет, понятно, что нужна. Но за деньги, за миллионы.

Сообщение **alex45** » 14 дек 2016, 09:14

Видел я подобную систему, только в меньших масштабах.
Когда я работал на ТЭЦ, там стояло оборудование, которое контролировало состояние щёточно-контактного аппарата генератора паровой турбины и выдавало рекомендации по обслуживанию (отрегулировать, заменить, и т.д.). Была ли от неё польза - не знаю, т.к. работать с этой системой не довелось.
ИМХО, систему эту внедрили только для того, чтобы освоить деньги, выделенные на ремонт оборудования.

Сообщение **Jackson** » 14 дек 2016, 10:30

sprohor писал(а): по 2003-ему ни у кого претензий нет.
по 2007-му - приняли решение и будет капитальный ремонт ... трещины, расслоение... изоляция многих кабелей в труху* ... и прочие фефекты фикции. (*объективности ради срок эксплуатации кабеля КГ по паспорту 5 лет с даты производства ... но никто это не анализирует :)
В чём разница ?
Умеренный климат Питера, и неумеренный морской климат Белого моря...

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

Отправлено спустя 1 минуту 20 секунд:

Михайло писал(а): [Ко всем присутствующим]: А вообще аналитика АСУТП кому-то нужна? Нет, понятно, что нужна. Но за деньги, за миллионы.

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

Отправлено спустя 13 минут 39 секунд:
У нас же перед глазами недавний пример - специалисты по ИБ, провели серьезный анализ АСУТП на ИБ и теперь рассказывают как нужно АСУТП, по их мнению, строить. Не беда что они (аналитики) явно подтасовывают результаты своего анализа и откровенно врут - зато какой анализ!

Сообщение **it-yuko** » 14 дек 2016, 16:53

rwg писал(а):
TEB писал(а):А чем "обнаружение" отличается от "диагностики" ? ;)
Обнаружение - того, что уже случилось, а диагностика - того, что случится в ближайшее время. Например предстоящее сгорание двигателя можно диагностировать по поведению температуры его обмоток.

Вы четко уловили суть аналитики и ее применения в соей терминологии. Я бы назвал диагноз-прогноз.
Определение в данном случае по ряду параметров температуры- тренд понятен..
Чисто фантазирую в постановках- что нужно чтобы температура не росла, не росла так быстро и т.д. ? То есть задача вполне для ИИ- перебора параметров вектора для возврата вектора в допустимые режимы.. Как то так..(Это скорее для нас черный ящик этого решения)
И как еще один способ многокритериальная постановка в оптимизации параметров при условии температуры на минимум, т.е один из способов нахождения этого вектора параметров (поддержание таких режимов)..Для нас понятен этот алгоритм..
Забавно при выполнении таких условий проблема просто сводится к мягкому останову- выдачей рекомендаций по изменению параметров.

Сообщение **it-yuko** » 14 дек 2016, 17:12

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

[Ко всем присутствующим]: А вообще аналитика АСУТП кому-то нужна? Нет, понятно, что нужна. Но за деньги, за миллионы.

Вообще тут озадачился посмотрел просто поиском:) Так вот на кафедре АСУ ТП учебная задача..

Каждый зарегистрированный участник соревнования получает доступ к описанию данных, тренировочному набору с заполненным откликом (признаком, является ли кредит (ТА) «плохим») и тестовым набором с незаполненным откликом. Задачей участника является разработка алгоритма прогнозировании вероятности возврата кредита (безотказной работы ТА)
http://www.asutp-mpei.ru/novosti/sorevn ... lizudannyh

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

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

Сообщение **rwg** » 14 дек 2016, 17:26

Где то видел закон "Система диагностики всегда первой выходит из строя и выводит из строя все остальные системы". Никак не могу найти первоисточник. Ближайший аналог у Мэрфи: "Система обеспечения надежности всегда портит то, что защищает ".

Сообщение **it-yuko** » 14 дек 2016, 17:27

TEB писал(а): Пропустил исключительно из любопытства.

Итог: Вы что-то хотели предложить или просто сообщить?

Суть сообщения в том числе..
1.Поиск материала для диссертации в такой постановке, сейчас это пока выглядит в рамках спец. 05.13.11 , как "Разработка моделей мониторинга.... мех. агрегатов по ряду признаков для динамических объектов". Для меня не все там понятно в плане таких объектов как САУ самолетом и возврат его в работоспособное состояние, но в постановке для АСУ ТП и ТА более менее понятно.
2. Подписать контракт на такие работы исследования тысяч так на 500:)
3. Еще можно жениться в процессе
Так что всех заинтересованных по 1 и 2 вэлком:)

Сообщение **it-yuko** » 14 дек 2016, 17:40

TEB писал(а): В общем, второе моё резюме тоже до банальности просто: "Не стоит произносить непонятные слова только потому, что они красивые - мало ли что может случиться." (с) Алиса в стране чудес, детская сказка.

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

Я посмотрел, вам просто надо подучиться в проблемах которыми занимается аналитика, а в которых логика, что бы не было каши в голове. Никогда не зазорно.. и меньше будет разговоров про лженауку и якобы гаданий..
Обычно когда не видят актуальности, то трех этажные посты не пишут это так про адекватные состояния если...:)
Новизна - скажем снять показания системы агрегатов и сказать где и в каком состоянии находится система по факту (типы состояний я указал в первом сообщении ). В режиме он-лайн еще интереснее, если распространять не только на САУ, но и вспомогательное и технологическое оборудование еще лучше.. Возможно вы это все делаете, мы пока нет..

Сообщение **it-yuko** » 14 дек 2016, 17:56

sprohor писал(а): Всё это от лукавого, в семейных рекламирующего какое то снадобье "А вдруг... а что..."
Если "аналитики" будут рисовать теоретические вектора не имея длительного опыта эксплуатации систем, то это никак не поможет предвидеть и предотвратить аварийные ситуации, как из-за теоретически возможных проблем с компонентами и элементами АСУ ТП, так и собственно с механизмами или оборудованием ТП.

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

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

Сообщение **it-yuko** » 14 дек 2016, 18:55

TEB писал(а):
it-yuko писал(а): А в целом берут архивы БД и по ним обучают систему, т.е вектор который я описал в первом сообщении привязывают к событиям..
Во времена моей аспирантуры, популярность этой идеи уже прошла свой пик. Хотя отдельные молодые таланты тащили эту тему и раскручивали, но ничего принципиально нового в их работах я не видел.
Причина бума популярности - очередная волна популярности нечёткой логики, адаптивных и обучающихся систем. Причина спада популярности - отсутствие сначала эффективных внедрений, а потом и просто полное отсутствие внедрений.

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

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

Аналитика не используется, где есть логическое управление..Оно идет поверх или вне эти контуров, это надо как-то понимать

Эта аналитика находит применение только в масштабных прогнозирующих подсистемах, когда процесс состоит в основном из регулирования по многим входящим переменным и многим же выходящим воздействиям. Пример - ядерный реактор. И там эти вещи с успехом применяются в качестве компонентов ПАЗ, а также на экспериментальных реакторах. Но ядерный реактор - вещь неординарная, это всегда большая и серьезная наука. Тут же, у нас здесь, обычные АСУТП. Пытались применять к системам попроще, на моей памяти это, например, судовой авторулевой - постоянные времени большие, процессы медленные, переменных мало, вычислительных мощностей больших не надо - казалось бы, бери и применяй. И пошли дальше, пробовали анализировать данные регистраторов данных рейсов с целью внесения своевременных навигационных поправок. Но не пошло - говоря нынешним языком, эти алгоритмы играли роль "британских учёных".

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

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

Статистика и есть аналитика:)

it-yuko писал(а): Как раз тогда искусственный интеллект был на подьеме, во времена книги..
Он был на подъёме намного раньше, и с тех пор про него просто периодически вспоминают молодые исследователи, поэтому периодически создается впечатление какого-то подъёма, длительность этого периода - примерно лет 5-7. В техническом прикладном смысле в отношении ИИ ровным счётом ничего не меняется уже лет 40 точно, меняются только практические реализации в силу развития технологий. Но определённого ещё при царе горохе предельного потенциала ИИ эти технологии достигнут ещё очень нескоро, и процесс достижения давно остановился - нужен большой практический технологический опыт для дальнейшего движения, а он - опыт - постоянно меняется вместо того чтобы просто накапливаться. Так что я бы предостерёг от такого небрежного упоминания т.н. ИИ и его прикладного применения.

В общем, второе моё резюме тоже до банальности просто: "Не стоит произносить непонятные слова только потому, что они красивые - мало ли что может случиться." (с) Алиса в стране чудес, детская сказка.

Да какая разница какими алгоритмами мы будем диагностировать состояние ТА как плохое или вероятность его отказа.. ?
Вот именно за эту точность в математике машинного обучения и идет борьба, соревнование, по крайне мере в других областях.. Ну если конечно у вас там данные не со специфическим запахом, в чем я сомневаюсь. Надо просто разобраться в этом и не озадачиваться письмом о контексте искусственного интеллекта и правомерности его употребления..
Есть алгоритмы и они могут быть достаточны интеллектуальны и работают с голыми цифрами.. У кого нет желания применять новые зания у кого-то есть..
В вашей области скорее всего подозреваю, что то скомкали и выдали за аналитику и не продвинулись..

Отправлено спустя 1 минуту 7 секунд:
sprohor писал(а): Сегодня новость была - студенты бауманки где то в московском сарае решили испытать какой то ракетный или реактивный движок... он взорвался и его обломок пролетев немерянное расстояние, пробил стену соседнего знания и оторвал кисть непричёмному 54-ти летнему мужику... По всей видимости, из-за ошибки при аналитических расчётах прогремел взрыв.
А это каким боком к топику относится?

[/quote]

Вообще-то это и был сарказм:)

Сообщение **sprohor** » 14 дек 2016, 23:34

Вы всё врёте про вероятность предсказания отказов... производство вечно по нашим жизненным меркам... Сименс обещает 20680 лет между двумя отказами 6ES7120-1AH00-0AA0 :) и 70 лет для процессора S7-300
а для приведённой выше головы ET200S 3-ей версии 91 год... до второго отказа... ну и как эти данные реально пригодятся для аналитики ?
https://support.industry.siemens.com/cs ... n&lc=ru-RU

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

Сообщение **Ryzhij** » 15 дек 2016, 08:00

it-yuko писал(а):
Статистика и есть аналитика:)

Угу. Есть мелкое враньё, есть чудовищная ложь и есть статистика.

Сообщение **Ryzhij** » 15 дек 2016, 08:07

sprohor писал(а): Вы всё врёте про вероятность предсказания отказов... производство вечно по нашим жизненным меркам... Сименс обещает 20680 лет между двумя отказами 6ES7120-1AH00-0AA0 :) и 70 лет для процессора S7-300
а для приведённой выше головы ET200S 3-ей версии 91 год... до второго отказа... ну и как эти данные реально пригодятся для аналитики ?

Право же, не стоит так вульгарно трактовать термины из теории вероятностей.
Надо просто ещё раз освежить этот раздел прикладной математики в памяти.
И потом, интенсивность отказов сильно меняется со временем и очень зависит от условий эксплуатации.
А "вероятность предсказания отказов" - это вообще не знаю что...

Сообщение **Jackson** » 15 дек 2016, 09:09

it-yuko писал(а): 2. Подписать контракт на такие работы исследования тысяч так на 500:)

Сделать чтоли вход на форум платный?

на нас такие деньги зарабатывают!

Отправлено спустя 12 минут 3 секунды:

it-yuko писал(а): Статистика и есть аналитика

И после таких фраз Вы, молодой человек, еще отправляете меня подучиться? Вам не стыдно?

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

Сообщение **sprohor** » 15 дек 2016, 11:36

Ryzhij писал(а):
sprohor писал(а): Вы всё врёте про вероятность предсказания отказов... производство вечно по нашим жизненным меркам... Сименс обещает 20680 лет между двумя отказами 6ES7120-1AH00-0AA0 :) и 70 лет для процессора S7-300
а для приведённой выше головы ET200S 3-ей версии 91 год... до второго отказа... ну и как эти данные реально пригодятся для аналитики ?

Право же, не стоит так вульгарно трактовать термины из теории вероятностей...

Надо просто понимать смысл "умных" терминов
MTBF = Mean Time Between Failures = time between two consecutive failures of a component.
MTBF = среднее время между отказами = время между двумя последовательными отказами компонента.
То есть предположение через сколько лет будет повторное сгорание полена в печке после его первого сгорания в печке