Москва ошарашена MES-Системой «MES-T2 2012» для электростанций

boris_mvr пишет:Все намного сложнее, задач таких уже никто не ставит за ненадобностью, никому они не нужны.
Развитие имеет два направления - прогресс и регресс. У нас второе, к сожалению.

Авария не разбирает, в каком настроении находится общество. Она просто ба-бахает.
Если не хочешь иметь головную боль, то будешь предохраняться.
И это не зависит ни от прогресса, ни от регресса. Есть элементарные инстинкты самосохранения. Любое оборудование имеет определённую степень надёжности с такой-то вероятностью.
Скажем квартиры: есть дома с электроплитами и с газовыми плитами.
Дом с газовыми плитами в любой момент может взорваться, т.к. везде есть старенькие с плохой памятью и самоанализом, и с плохим обонянием. Крантик открыл и забыл закрыть, а через несколько часов включил свет. Вот и взрыв. Я в таком доме живу, и не уютно. Но чего проще - установить датчики газа...
Таким образом, АВАРИЯ - это удар ниже пояса...

Полностью согласен.
У меня куча новостей, просмотрел ее работу, отредактировал тезисы, сегодня дочь звонит, что выступление и предзащита будет в Пущино, оппоненты - главы школ. Ее руководитель сказал так. Понимаю, что работа у тебя на уровне открытия, но решение принимают главы школ, а это ее шанс. Кто знает, как повернется судьба? У меня сердце прижало, отлеживаюсь.

boris_mvr пишет:Полностью согласен.
У меня куча новостей, просмотрел ее работу, отредактировал тезисы, сегодня дочь звонит, что выступление и предзащита будет в Пущино, оппоненты - главы школ. Ее руководитель сказал так. Понимаю, что работа у тебя на уровне открытия, но решение принимают главы школ, а это ее шанс. Кто знает, как повернется судьба? У меня сердце прижало, отлеживаюсь.

Я не верю в правдивость этих заседаний. Всё зависит от научного руководителя. По-моему всё происходит формально, т.к. со слуха не возможно уловить всю суть.

От научного руководителя это не зависит, пусть защищает работы, там видно будет. Температура пока держится, но намного лучше.

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

boris_mvr пишет:От научного руководителя это не зависит, пусть защищает работы, там видно будет. Температура пока держится, но намного лучше.

Желаю всем вам здоровья...
Сегодня ходил на прогулку на 7 км после перерыва. Суставы подводят, но борюсь. Раньше в Чехословакии бегал марафон, а сейчас вес 110 кг.
Но мы с женой по врачам не ходим, а регулярно принимает таблетки...

Спасибо! Вес у нас совпадает, лечимся травами по рецептам академика Болотова, к врачам тоже не ходим. Раньше ходил за клюквой, брусникой... В день не меньше 100 км. Марафон никогда бегал. Сегодня только смог умыться и побриться, смешно даже. Уже хожу. Операция у пса прошла успешно, следим, чтобы не вставал. Да, у нас до сих пор продают помидоры и ягоды с полей. 30 на день рождения дочери будет большой арбуз..

При нашем весе (гипертония) и возрасте обязательно утром следует постоянно принимать таблетки от давления. Я принимаю: Индапамид (2,5 мг) и Амлодипин (5 мг) (дешевые). А вечером следует принимать Ацекардол (аспирин 100 мг) для разжижения крови. На ночь я рассасываю Гастал для желудка.
В траву не верю...

Принимаю Арифон ретард, одну на день. Насчет трав, мха и ягод.
Было воспаление легких, это питье поставило меня на ноги в течении тех дней. Это факт.

boris_mvr пишет:Принимаю Арифон ретард, одну на день.

Арифон это торговая марка Индапамида, который на порядок стоит дороже.
Арифон - 300 руб
Индапамид (Россия) - 30 руб

Помогает, правда.

О системе предупреждения аварий.
Сначала немного о прошлом.
1970, выходит монография профессора Полака (Оптимизация. Единый подход) под редакцией академика Никиты Николаевича Моисеева (мой Учитель и Наставник). Полак делит любую разработку (построение) на 3 части:

1. Принципиальная модель. Это скелет идеи, скелет подхода. Именно здесь делаются все основные выводы и доказательства. Если они нас устраивают, то переходим к остальным частям. На этом этапе и делаются все открытия, если они возможны, разумеется.

2. Развитие принципиальной модели до реализуемой. Это внутреннее наполнение. Здесь тоже делаются открытия, но их никто рассматривать не будет, если не пройден первый этап.

3. Реализуемая модель.

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

Теперь о системе предупреждения, контекст рассмотрения описал. Для примера возьмем одну из служб, одной из обязанностей которой есть предупреждение. Что у них должно быть. По крайней мере, одно приложение для занесения данных и пульт управления (рабочий стол) руководителя для принятия решений. Здесь есть подводный камень. Прежде, чем его описывать приведу материал из информодинамики (Вы это пропустили, наверное). А без этого материала дальнейшее Вам будет непонятно, как и всем остальным руководителям, пока не обожглись на практике [Поляков А.О., Смирнов Ю.М., Турчак А.А. Информодинамические основы организации управления предприятиями и холдинговыми компаниями. СПб: Изд-во СПбГТУ, 2002].

Интеллектуальная система – открытая система, механизм устройства которой существенно основан на контекстном анализе, на накоплении и сопоставлении различных вариантов интеграции сообщений и совокупностей сообщений, причём отображение знания в сообщениях приводит к неизбежной интерпретации человеком всех сообщений, даже полученных на контекстно-независимом языке, как контекстно-зависимых. Казалось бы, создавая любое текстовое или, в общем случае, знаковое сообщение, человек тоже выступает в роли датчика. Это все равно будет физическая посылка, ничем не отличающаяся от всего предыдущего. Однако нет [монографии глав школ, труды, материалы выступлений, работы студентов]. Существует основное отличие всех сообщений человека от сигналов датчиков - они могут быть сделаны только после выработки в «контекстно-зависимой, не алгоритмической машине», каковой является мозг, множества вариантов интерпретации входного сообщения и выбора наиболее приемлемого из них. Только после этого на основе проведенного выбора формируется собственно сообщение. Контекст (от лат. сontextus - сплетение, соединение) приписывается человеком всегда и всему - это один из важнейших моментов в информодинамике для дальнейших рассуждений.

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

[Поляков А.О., Смирнов Ю.М., Турчак А.А. Информодинамические основы организации управления предприятиями и холдинговыми компаниями. СПб: Изд-во СПбГТУ, 2002].

Более подробное изложение надо искать в статьях на сайте.

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

boris_mvr пишет:Полак делит любую разработку (построение) на 3 части:
1. Принципиальная модель. Это скелет идеи, скелет подхода. Именно здесь делаются все основные выводы и доказательства. Если они нас устраивают, то переходим к остальным частям. На этом этапе и делаются все открытия, если они возможны, разумеется.
2. Развитие принципиальной модели до реализуемой. Это внутреннее наполнение. Здесь тоже делаются открытия, но их никто рассматривать не будет, если не пройден первый этап.
3. Реализуемая модель.

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

Можно сколько угодно рассуждать как правильно... Но мы без теорий и без науки разработали инструментарий конкретной направленности, пройдя несколько этапов становления, не подозревая в начале, что это вообще возможно.

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

С 1970 очень много лет этот подход академическим не считался, это для справки.
Некоторые школы до сих его не принимают. Зато лежит в основе управления проектами. Это Вы тоже считаете академическим подходом?

ТЗ с точки зрения информодинамики
Для примера рассмотрим ТЗ для системы предупреждения аварий.
Опишу не научным языком, на пальцах.
Если идти традиционным путем, то ТЗ не напишет никто. Почему? Потому, что ничего неизвестно. Эту ситуацию можно охарактеризовать одним словом: неопределенность. 300 станций разбросанных территориально, станции разнокалиберные, отсюда следует ожидать, что даже для одного смежного подразделения взгляды на работу с одним и тем же приложением будут разные, условия работы и традиции тоже разные. Теперь допустим, что мы смогли описать работу 10 служб, тогда 300х10=3000 описаний. Это целая библиотека описаний, если хотите ТЗ, институт и тот с этим не справится! Но в любом случае работу хотя бы одной службы описать можно, например, службы техники безопасности. Нечто подобное должно быть и у Вас. В дальнейшем будем считать, что хотя бы одно ТЗ на приложение у нас есть.

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

Начинать надо всегда с разработки интеллектуальной системы управления. Почему? Потому, что ей до лампочки с каким приложением и с какой службой иметь дело. Что опишем в конструкторе, то и увидим в приложении, для этого ТЗ на создание приложения и пишутся. Для этого программист не нужен, для внесения изменений в описание тоже.

Структура интеллектуальной системы известна. опишу ее по шагам, как при описании алгоритма, так.
1. WEB-сервер. Станции разбросаны территориально, разные службы одной станции тоже.
2. SQL-сервер. Мы имеем дело не постреляционной, а с реляционной БД.
3. Конструктор. Там мы будем описывать работу приложений согласно ТЗ, и многое другое.
4. Шаблон приложения. Это приложение с открытым кодом, львиная часть работы там уже сделана. Приложения уникальны, поэтому может понадобиться дальнейшее развитие. Приведу пример, будете смеяться. Бабы подняли бунт - подавай им формы веселые, покрашенные в красный, зеленый, желтый и другие цвета! Это жены "очень уважаемых людей", вот и заставили их красить, а зато, что сразу красить не стали - лишили премии, долгое время программисты подвергались репрессиям за это... В качестве шаблона может выступить любое приложение.
5. Рабочий стол (пульт управления) руководителя подразделения. Его можно совместить с приложением. Как сделать лучше? Заранее трудно сказать.
6. ПУЛЬТ УПРАВЛЕНИЯ. Куда стекаются данные со все служб для анализа. Об этом говорить рано.

С чего начинается создание такой системы? С конструктора.. Не углубляюсь дальше.

Как это работает? Появилось ТЗ на разработку нового приложения. Открываем конструктор и описываем там работу приложения согласно ТЗ. Если у шаблона не хватает функциональности, то понадобиться программист. Так кусочек за кусочком создается система предупреждения аварий. Только сейчас до меня дошел смысл высказываний в управлениями проектами: "Слона, мамонта, хобот мамонта надо есть по кусочку".

boris_mvr пишет:ТЗ с точки зрения информодинамики
Для примера рассмотрим ТЗ для системы предупреждения аварий.
Опишу не научным языком, на пальцах.
Если идти традиционным путем, то ТЗ не напишет никто. Почему? Потому, что ничего неизвестно. Эту ситуацию можно охарактеризовать одним словом: неопределенность. 300 станций разбросанных территориально, станции разнокалиберные, отсюда следует ожидать, что даже для одного смежного подразделения взгляды на работу с одним и тем же приложением будут разные, условия работы и традиции тоже разные. Теперь допустим, что мы смогли описать работу 10 служб, тогда 300х10=3000 описаний. Это целая библиотека описаний, если хотите ТЗ, институт и тот с этим не справится! Но в любом случае работу хотя бы одной службы описать можно, например, службы техники безопасности. Нечто подобное должно быть и у Вас. В дальнейшем будем считать, что хотя бы одно ТЗ на приложение у нас есть.

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

Начинать надо всегда с разработки интеллектуальной системы управления. Почему? Потому, что ей до лампочки с каким приложением и с какой службой иметь дело. Что опишем в конструкторе, то и увидим в приложении, для этого ТЗ на создание приложения и пишутся. Для этого программист не нужен, для внесения изменений в описание тоже.

Структура интеллектуальной системы известна. опишу ее по шагам, как при описании алгоритма, так.
1. WEB-сервер. Станции разбросаны территориально, разные службы одной станции тоже.
2. SQL-сервер. Мы имеем дело не постреляционной, а с реляционной БД.
3. Конструктор. Там мы будем описывать работу приложений согласно ТЗ, и многое другое.
4. Шаблон приложения. Это приложение с открытым кодом, львиная часть работы там уже сделана. Приложения уникальны, поэтому может понадобиться дальнейшее развитие. Приведу пример, будете смеяться. Бабы подняли бунт - подавай им формы веселые, покрашенные в красный, зеленый, желтый и другие цвета! Это жены "очень уважаемых людей", вот и заставили их красить, а зато, что сразу красить не стали - лишили премии, долгое время программисты подвергались репрессиям за это... В качестве шаблона может выступить любое приложение.
5. Рабочий стол (пульт управления) руководителя подразделения. Его можно совместить с приложением. Как сделать лучше? Заранее трудно сказать.
6. ПУЛЬТ УПРАВЛЕНИЯ. Куда стекаются данные со все служб для анализа. Об этом говорить рано.

С чего начинается создание такой системы? С конструктора.. Не углубляюсь дальше.

Как это работает? Появилось ТЗ на разработку нового приложения. Открываем конструктор и описываем там работу приложения согласно ТЗ. Если у шаблона не хватает функциональности, то понадобиться программист. Так кусочек за кусочком создается система предупреждения аварий. Только сейчас до меня дошел смысл высказываний в управлениями проектами: "Слона, мамонта, хобот мамонта надо есть по кусочку".

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

Chernov_VF пишет:

boris_mvr пишет:ТЗ с точки зрения информодинамики
Для примера рассмотрим ТЗ для системы предупреждения аварий.
Опишу не научным языком, на пальцах.
Если идти традиционным путем, то ТЗ не напишет никто. Почему? Потому, что ничего неизвестно. Эту ситуацию можно охарактеризовать одним словом: неопределенность. 300 станций разбросанных территориально, станции разнокалиберные, отсюда следует ожидать, что даже для одного смежного подразделения взгляды на работу с одним и тем же приложением будут разные, условия работы и традиции тоже разные. Теперь допустим, что мы смогли описать работу 10 служб, тогда 300х10=3000 описаний. Это целая библиотека описаний, если хотите ТЗ, институт и тот с этим не справится! Но в любом случае работу хотя бы одной службы описать можно, например, службы техники безопасности. Нечто подобное должно быть и у Вас. В дальнейшем будем считать, что хотя бы одно ТЗ на приложение у нас есть.

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

Начинать надо всегда с разработки интеллектуальной системы управления. Почему? Потому, что ей до лампочки с каким приложением и с какой службой иметь дело. Что опишем в конструкторе, то и увидим в приложении, для этого ТЗ на создание приложения и пишутся. Для этого программист не нужен, для внесения изменений в описание тоже.

Структура интеллектуальной системы известна. опишу ее по шагам, как при описании алгоритма, так.
1. WEB-сервер. Станции разбросаны территориально, разные службы одной станции тоже.
2. SQL-сервер. Мы имеем дело не постреляционной, а с реляционной БД.
3. Конструктор. Там мы будем описывать работу приложений согласно ТЗ, и многое другое.
4. Шаблон приложения. Это приложение с открытым кодом, львиная часть работы там уже сделана. Приложения уникальны, поэтому может понадобиться дальнейшее развитие. Приведу пример, будете смеяться. Бабы подняли бунт - подавай им формы веселые, покрашенные в красный, зеленый, желтый и другие цвета! Это жены "очень уважаемых людей", вот и заставили их красить, а зато, что сразу красить не стали - лишили премии, долгое время программисты подвергались репрессиям за это... В качестве шаблона может выступить любое приложение.
5. Рабочий стол (пульт управления) руководителя подразделения. Его можно совместить с приложением. Как сделать лучше? Заранее трудно сказать.
6. ПУЛЬТ УПРАВЛЕНИЯ. Куда стекаются данные со все служб для анализа. Об этом говорить рано.

С чего начинается создание такой системы? С конструктора.. Не углубляюсь дальше.

Как это работает? Появилось ТЗ на разработку нового приложения. Открываем конструктор и описываем там работу приложения согласно ТЗ. Если у шаблона не хватает функциональности, то понадобиться программист. Так кусочек за кусочком создается система предупреждения аварий. Только сейчас до меня дошел смысл высказываний в управлениями проектами: "Слона, мамонта, хобот мамонта надо есть по кусочку".

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

Обоснования не будет - будут бить, это Закон.

boris_mvr пишет:

Chernov_VF пишет:

boris_mvr пишет:ТЗ с точки зрения информодинамики
Для примера рассмотрим ТЗ для системы предупреждения аварий.
Опишу не научным языком, на пальцах.
Если идти традиционным путем, то ТЗ не напишет никто. Почему? Потому, что ничего неизвестно. Эту ситуацию можно охарактеризовать одним словом: неопределенность. 300 станций разбросанных территориально, станции разнокалиберные, отсюда следует ожидать, что даже для одного смежного подразделения взгляды на работу с одним и тем же приложением будут разные, условия работы и традиции тоже разные. Теперь допустим, что мы смогли описать работу 10 служб, тогда 300х10=3000 описаний. Это целая библиотека описаний, если хотите ТЗ, институт и тот с этим не справится! Но в любом случае работу хотя бы одной службы описать можно, например, службы техники безопасности. Нечто подобное должно быть и у Вас. В дальнейшем будем считать, что хотя бы одно ТЗ на приложение у нас есть.

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

Начинать надо всегда с разработки интеллектуальной системы управления. Почему? Потому, что ей до лампочки с каким приложением и с какой службой иметь дело. Что опишем в конструкторе, то и увидим в приложении, для этого ТЗ на создание приложения и пишутся. Для этого программист не нужен, для внесения изменений в описание тоже.

Структура интеллектуальной системы известна. опишу ее по шагам, как при описании алгоритма, так.
1. WEB-сервер. Станции разбросаны территориально, разные службы одной станции тоже.
2. SQL-сервер. Мы имеем дело не постреляционной, а с реляционной БД.
3. Конструктор. Там мы будем описывать работу приложений согласно ТЗ, и многое другое.
4. Шаблон приложения. Это приложение с открытым кодом, львиная часть работы там уже сделана. Приложения уникальны, поэтому может понадобиться дальнейшее развитие. Приведу пример, будете смеяться. Бабы подняли бунт - подавай им формы веселые, покрашенные в красный, зеленый, желтый и другие цвета! Это жены "очень уважаемых людей", вот и заставили их красить, а зато, что сразу красить не стали - лишили премии, долгое время программисты подвергались репрессиям за это... В качестве шаблона может выступить любое приложение.
5. Рабочий стол (пульт управления) руководителя подразделения. Его можно совместить с приложением. Как сделать лучше? Заранее трудно сказать.
6. ПУЛЬТ УПРАВЛЕНИЯ. Куда стекаются данные со все служб для анализа. Об этом говорить рано.

С чего начинается создание такой системы? С конструктора.. Не углубляюсь дальше.

Как это работает? Появилось ТЗ на разработку нового приложения. Открываем конструктор и описываем там работу приложения согласно ТЗ. Если у шаблона не хватает функциональности, то понадобиться программист. Так кусочек за кусочком создается система предупреждения аварий. Только сейчас до меня дошел смысл высказываний в управлениями проектами: "Слона, мамонта, хобот мамонта надо есть по кусочку".

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

Обоснования не будет - будут бить, это Закон.

Когда нечего терять - это самое страшное для другой стороны, т.к. она это не знает и воспринимает это за нечто неординарное... В этом её слабость...

Chernov_VF пишет:

boris_mvr пишет:

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

Обоснования не будет - будут бить, это Закон.

Когда нечего терять - это самое страшное для другой стороны, т.к. она это не знает и воспринимает это за нечто неординарное... В этом её слабость...

Дураков там нет...