Форум режимщиков

Как-то тема интерфейса для оценки плавно переехала  совсем в другую: как создать супер-программу, объединяющую все мыслимые возможности и с великолепным интерфейсом (сделанным профессиональным дизайнером ! )Такая программа вообще-то уже есть, называется EMS,   и торгуют ею Siemens, ABB, Areva и некотрые другие фирмы поменьше. И как все знают в ближайшее время СО начнет внедрение полного комплекта от от Simens.  Архитектурно (SOA, ESB, CIM/XML) система самая современная. Хотя считалки и разработчки от АВВ мне показались лучше  - один Vladimir Brandwajn чего стоит.   Презенташки вышеназванных фирм у меня сохранились и могу выложить (хотя видимо надо чье-то разрешение?)Так что никакой концепции  супер-программы и не надо да и не сделать ее СО никогда.Впрочем со всем этим надо в другую ветку. Можно в общих вопросах сконструировать некую виртуальную программу, собрав туда все лучшие решения отдельных разработчиков. Я, собственно, предлагал простое и быстрое решение локальной проблемы - не нравится интерфейс космоса - давайте встроим  в интерфейс растра доступ к его считалке. (сохранив, естественно, и оба комплекса в отдельности). Когда-то давно  нечто подобное было проделано с Дакаром - в него был встроен доступ к считалке УР от Растра (в дос версии) ОДУ Урала заказало и все было сделано меньше чем за 1 человеко-месяц.

Цитата:

Как-то тема интерфейса для оценки плавно переехала  совсем в другую: как создать супер-программу, объединяющую все мыслимые возможности и с великолепным интерфейсом (сделанным профессиональным дизайнером ! )Такая программа вообще-то уже есть, называется EMS,   и торгуют ею Siemens, ABB, Areva и некотрые другие фирмы поменьше.

Зачем мы ракеты в Космос запускаем? Можно заплатить американцам денег они нас на шатле свозят? Или у нас лучше получается?Почему китайцы делают свои ракеты, а не договариваются с нами или американцами полетать?Вопрос ведь можно поставить по разному. Либо своими деньгами развивать интеллектуальный потенциал других стран, либо свой.Если мы себя позиционируем как сырьевой придаток, то и жить будем соответствующим образом. Надо бы определится в каком направлении двигаться.Либо решать текущие задачи. Либо двигаться целенаправленно к глобальной цели.PS: Что то я разошолся...

Про "концепцию построения единого комплекса программных средств для моделирования режимов" писать не буду, т.к. было уже написано много и верно.Поэтому опять про "своих баранов":

Цитата:

Я, собственно, предлагал простое и быстрое решение локальной проблемы - не нравится интерфейс космоса - давайте встроим  в интерфейс растра доступ к его считалке. (сохранив, естественно, и оба комплекса в отдельности). Когда-то давно  нечто подобное было проделано с Дакаром - в него был встроен доступ к считалке УР от Растра (в дос версии) ОДУ Урала заказало и все было сделано меньше чем за 1 человеко-месяц.

!!!Я ЗА!!! Если это будет реализовано в ближайшем будущем.Обоснование: в Космосе есть оценка состояния, но нет "вкусностей" Растра. В Растре есть достаточно развитый инструментарий для режимщика, но нет оценки. В сязи с чем приходится весьма часто заниматься тем, чем любил заниматься всем известный Онан, импортируя режим из Космоса в Растр.

Дошли руки до Технических требований к ОСЭР (О!!!  СЭР!!!! (возглас темпераментной англичанки))...Выражаю свое ИМХО: ЭТО НЕ ТЕХНИЧЕСКОЕ ЗАДАНИЕ, так, пособие (возможно даже неплохое) по задачам оценивания состояния. ТЕХНИЧЕКОЕ задание должно быть ТЕХНИЧЕСКИМ.Про идею ОСЭР опять мое ИМХО: Растр - инструмент режимщика, Космос - инструмент диспетчера и режимщика. Откуда:Растр "заточен" под высококвалифицированного специалиста по режимам".Космос попытались "заточить" под высококвалифицированного специалиста по режимам и под неквалифицированного специалиста по режимам, Получилось не тем и не другим:диспетчерам сложно, режимщикам мало. Надо делать два различных интерфейса (пусть даже они и используют одни расчетные модули). Пусть будет простая тупая программа для диспетчера и "Растр" с оценкой для режимщика.

Цитата:

Я, собственно, предлагал простое и быстрое решение локальной проблемы - не нравится интерфейс космоса - давайте встроим  в интерфейс растра доступ к его считалке. (сохранив, естественно, и оба комплекса в отдельности). Когда-то давно  нечто подобное было проделано с Дакаром - в него был встроен доступ к считалке УР от Растра (в дос версии) ОДУ Урала заказало и все было сделано меньше чем за 1 человеко-месяц.

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

Цитата:

Презенташки вышеназванных фирм у меня сохранились и могу выложить (хотя видимо надо чье-то разрешение?)

А "разрешение" еще не получено?  ;)

Цитата:

Цитата: Как-то тема интерфейса для оценки плавно переехала  совсем в другую: как создать супер-программу, объединяющую все мыслимые возможности и с великолепным интерфейсом (сделанным профессиональным дизайнером ! )Такая программа вообще-то уже есть, называется EMS,   и торгуют ею Siemens, ABB, Areva и некотрые другие фирмы поменьше. Зачем мы ракеты в Космос запускаем? Можно заплатить американцам денег они нас на шатле свозят? Или у нас лучше получается?Почему китайцы делают свои ракеты, а не договариваются с нами или американцами полетать?Вопрос ведь можно поставить по разному. Либо своими деньгами развивать интеллектуальный потенциал других стран, либо свой.Если мы себя позиционируем как сырьевой придаток, то и жить будем соответствующим образом. Надо бы определится в каком направлении двигаться.Либо решать текущие задачи. Либо двигаться целенаправленно к глобальной цели.PS: Что то я разошолся...

Все правильно - надо делать свой EMS, лучший чем у Siemens. Хотя взглянуть как работают буржуи, для всех было бы полезно. Лично меня потрясла на ДШ в Осло одинокая девушка в интересном положении в одиночку (!) управляющая всем конкурентным рынком Норвегии (там и БР и РСВ и тд пересчет у них каждые 15 мин). А у нас число ДИОПов в ЦДУ не поддается измерению ....

Что-то я не пойму логики... То звучит мысль о:

Цитата:

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

То звучит мысль о буржуинских EMS и что ничего придумывать не надо и тем более что СО ни на что не способен...А теперь опять разговор перешел в русло что надо посмотреть что есть у буржуинов и что надо сделать все-таки свое, но лучше...Конструктивно!!! Возразить нечего!!!

Вариантов для голосования маловато.Ведь два это мало - например, "люди бывают злыми и добрыми" - это утопия, ведьесть и промежуточные варианты...Посему предлагаю добавить ещё пункты. К примеру, "ФСЁ ФТОПКУ"  ;D(как всем известного героя - Лазо, которого сожгли японцы) и "Ждать SCADA/EMS".А если серьёзно, то прикрутить DLL было бы неплохо, но вот средств для анализа в Растре маловато для задачи оценивания. Например, вывести на графику измеренное и расчётное значение и прочее...

Цитата:

Куча сумбурных мыслей:1. Если логически развивать идею с Dll в результате можно прийти к такой системе как Анарес (если у меня правильное представление о нем).Встает вопрос. Зачем делать dll для растра?3. О развитии программного обеспечения.Неплохо было бы если ПО режимщиков имело следующую структуру.Модуль отображения результатов расчета УРМодуль отображения результатов расчета динамической устойчивостиМодуль расчета УРМодуль ОцениванияМодуль расчета динамикиМодуль утяжеленияи т.д.Имелось бы четкая спецификация на каждый модуль. Имелись бы описания протоколов обмена между модулями.Любой из модулей может подключаться к любым другим.ПО составлялось бы из модулей, которые могут делать и продавать любые разработчики. СО проверяет модули на соответствие требованиям и сертифицирует модули.Суть в том что Иванов, который занимается динамикой не надо делать расчет УР. Он везьмет его у Нейумина. А графику для УР которую он так и не доделал у другого разработчика и будет спокойно заниматься своим любимым делом - динамикой.Проблемы с переносом и потерей информации отпадают. СО задает спецификацию на программу. Ничего лишнего в модулях реализовывать не надо, т.к. будет невозможно этим воспользоваться. Программа отображения и ввода данных разрабатывается посторонним разработчиком и хотелки в ней отобразить будет невозможно.Если придумали что-то новое например в УР учитывать Р-Q диаграммы, СО выпускает новую спецификацию версии 1.1 и тд. Разработчики клепают модули. сертифицируют. СО выделяет деньги на обновление ПО.Все довольны.

По п.1.(к сожалению не до конца понятно отношение Romanov к такому подходу): :-?В АНАРЭС, в основном, реализован модульный принцип. Есть базовые *.exe- модули , а также DLL. В частности на технологии dll - реализована возможность моделирования ПАА практически любой сложности (другое дело, что dll-модуль сложной автоматики писать всё равно надо). Простые РЗ и ПАА (их число 95-99%) легко программируются средствами внутреннего редактора РЗ и ПАА. Основные приложения АНАРЭС, в принципе, могут работать автономно. Протоколы обмена в основном унифицированы (внутренний универсальный формат). Кроме этого есть другие общие dll, которые используют разные модули АНАРЭС. Достоинство dll - максимальное быстродействие и унификация интерфейса. При желании можно, например, взять блок УР и подцепить его к своей базе данныхи дальше решать все те задачи, где УР является базовой (оптимизация, утяжеление, надёжность и т.д.). То же самое и к БД можно подцеплять свои приложения. К остальным задачам это, как правило, тоже относится. Ну может быть с минимальными адаптационными доработками (вышеперечисленные уже проверены, а другие не до конца). Графический редактор тоже автономен. Можно рисовать любые схемы  (электрические, тепловые, электронные, блок-схемы и т.п.) вообще без привязки к вычислительным задачам. . А можно и с привязкой .Вопросы об обмене данными между разными программами и их унификации обсуждаются в ветви этого форума "Совместимость программных комплексов". Определённые направления развития этой проблемы понятны, но быстрая их качественная реализация, с моей точки зрения, очень проблематична. Это вопрос непонятно скольких лет.