форум асутп
 На главную                       Здесь может быть Ваша реклама, подробнее...


 Наверх  |  Перейти к теме  |  Поиск  |  Вход  |  Дерево    
 OPC Server for General Database Access
Автор: Жукова Г.В. 
Дата:   11.04.07 08:47

Имеется ли у российских производителей аналогичный MatrikonOPC Server for
General Database Access ?

Конкретно интересует: OPC DA Server с доступом по сети Ethernet (TCP/IP) к
базе данных  Microsoft Oracle для чтения данных.
____________________________________________________________
The MatrikonOPC Server for General Database Access (GDA) supports both
real-time and historical data access to ODBC and Oracle compliant databases.
Users may map the OPC point name, value, quality and timestamp by ODBC
source table column, custom queries or through pre-configured stored
procedures.  Applications that require connectivity to databases can use
this MatrikonOPC Server to access real-time and historical process data that
is archived by an online analyzer, laboratory personnel, etc.
Key features include:

- Support for ODBC compliant databases such as Microsoft SQL, Oracle,
Microsoft Access, Rockwell RSSQL, Citect, Sybase etc.
- Access to both real-time and historical data
- Support for reading and writing
- Connects to multiple databases simultaneously
- Executes database functions and procedures with OPC point values filing in
the parameters.
- Aggregates List: Average, Count, DurationBad, DurationGood, Interpolated,
Maximum, MaximumActualTime, Minimum, MinimumActualTime, PercentBad,
PercentGood, StandardDeviation, TimeAverage, Total, Variance, and more...
Адрес этого сообщения    Ответить на это сообщение
 
 Re: OPC Server for General Database Access
Автор: Alex G. Centner 
Дата:   11.04.07 13:13

----- Original Message -----
From: "Жукова Г.В." <gzhukova@xxxxxxxx.xx>
To: <asutp@yahoogroups.com>
Sent: Wednesday, April 11, 2007 10:47 AM
Subject: [asutp] OPC Server for General Database Access


> Имеется ли у российских производителей аналогичный MatrikonOPC Server for
> General Database Access ?
>
> Конкретно интересует: OPC DA Server с доступом по сети Ethernet (TCP/IP) к
> базе данных  Microsoft Oracle для чтения данных.

база данных Microsoft  Oracle ?!?  я отстал от жизни?.... :)
Может быть что-то из этого заинтересует  (http://www.splitopc.ru/):

      TrendOPC
      Клиентское приложение, предназначено для вывода значений OPC тегов
реального времени (OPC DA) и исторических значений OPC тегов (OPC HDA) в
форме графиков, путем динамического отображения значений тегов через WEB,
имеются броузинг OPC DA и OPC HDA тегов, возможности одновременного
отражения неограниченного числа графиков, масштабирования по осям, указание
любых временных интервалов, возможность <лупы> для конкретных участков
графиков, ф-ия скольжения метки по графику, индивидуальное задание цветов,
сохранение текущих настроек/отображаемых графиков, механизмом cookies, вывод
на печать. Для просмотра результатов требуется Internet Explorer.

      TrendOPC Logger
      Серверное приложение - сервер архивации, предназначенное для
сохранения значений OPC тегов реального времени (OPC DA) в базу данных
исторических значений (OPC HDA). Понятный интерфейс позволяет легко выбирать
сигналы для логгирования с использованием заданных алгоритмов архивации,
указывать предельные значения, частоту записи сигналов в БД. Имеется режим
записи данных <по изменению>. TrendOPC Logger поддерживает все SQL сервера,
имеющие ODBC (OLE DB) драйвера, стандартно используется Microsoft SQL 2000.
Все настройки сохраняются в механизме конфигураций в формате Microsoft
Access (.MDB) файла, что делает возможным импорт/экспорт конфигураций.


-----
Всего хорошего.
Центнер Алексей.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: OPC Server for General Database Access
Автор: Жукова Г.В. 
Дата:   11.04.07 14:06

> Может быть что-то из этого заинтересует  (http://www.splitopc.ru/):

Интересует OPC DA Server с процедурой ЧТЕНИЯ из базы данных посредством
ODBC.
На предлагаемом сайте это отсутствует.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: Sergey Gusev 
Дата:   11.04.07 17:33

Уважаемая Галина.

Наши инженеры сейчас решают, похоже, аналогичную задачу для Нижегородской
ГРЭС.
Технически это стандарный ОРС DA/HDA клиент от ICONICS плюс набор скриптов в
MS SQL.
В результате решается задача одновременного отображения почасовых графиков
реального времени и расчетных (из SQL) с дополнительными анализами,
обработками и т.д.
Если интересно - пишите напрямую, какова задача. Скорее всего мы знаем ее
решение. Или просто позвоните к нам, и попросите соединить с Аней Долговой.
Скорее всего, она сможет Вам помочь.

Если же вопрос просто "академический", из области, "есть ли такие готове
решения", то я знаю онин такой готовый "покупной" компонент. Это BridgeWorX
от ICONICS. Это приложение, являющееся одновременно сервером и клентом OPC,
а также клиентом (со встроенной логикой, расписанием и продвинутым
"визардом" запросов) таких популярных баз данных как MS SQL, Oracle и PI.
Мы его также применяем, правда, для несколько других задач.
Но, опять же, это не Российский производитель...

С уважением,

Сергей Гусев, ООО "Первая Миля"
Тел: +7-495-332-3640

Жукова Г.В.
...
Имеется ли у российских производителей аналогичный MatrikonOPC Server for
General Database Access ?
Конкретно интересует: OPC DA Server с доступом по сети Ethernet (TCP/IP) к
базе данных  Microsoft Oracle для чтения данных.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: OPC Server for General Database Access
Автор: @sutp 
Дата:   11.04.07 20:19

>> В результате решается задача одновременного отображения почасовых графиков реального времени и расчетных (из SQL) с дополнительными анализами, обработками и т.д.

Проблема, с которой столкнулись - изобразить график средствами Genesis32 на будущее время (хотя бы на час вперед), так как Genesis32 оперирует временами, не превышающими текущее время.
Наши специалисты контактируют с Анной Долговой постоянно, однако решение нашей проблемы стандартными средствами Genesis32 пока не найдено.
На настоящее время исхитрились и обманули Genesis32, рисует как надо РДГ и УДГ, при этом используем OPC-сервер собственной разработки.
При вводе в работу графиков ПБР возникла сложность частичной доработки имеющегося OPC-сервера, необходимо написать его заново, при этом человеческих ресурсов не хватает, наша основная работа - сопровождение, а не разработка.
Нужен российский производитель, который предоставит готовый OPC-сервер для чтения базы данных и в короткий срок (до нескольких недель) доработает его под требования Заказчика.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: Ilya Ablin 
Дата:   11.04.07 21:53

Добрый день!

>Конкретно интересует: OPC DA Server с доступом по сети
>Ethernet (TCP/IP) к базе данных  Microsoft Oracle для чтения данных.

Такая функциональность есть у нашей MasterSCADA, но это полная SCADA,
имеющая интерфейс сервера.
Кроме того, подобный сервер мы делали для MS SQL. Думаю, что для
Oracle будет не сильно отличаться.


С уважением,
Аблин Илья
Компания ИнСАТ

(495) 974-0092
mailto:ablin@xxxxx.xx
http://www.insat.ru
Адрес этого сообщения    Ответить на это сообщение
 
 Re: OPC Server for General Database Access
Автор: @sutp 
Дата:   11.04.07 22:55

> Кроме того, подобный сервер мы делали для MS SQL

Самостоятельный OPC-сервер или в объеме MasterSCADA?
Адрес этого сообщения    Ответить на это сообщение
 
 Re: OPC Server for General Database Access
Автор: @sutp 
Дата:   11.04.07 23:03

Демо-версию или руководство по эксплуатации можно посмотреть?
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   12.04.07 08:51

Ничего себе! Как это вы в будущее заглянуть собрались? :)))

> Проблема, с которой столкнулись - изобразить график
> средствами Genesis32 на будущее время (хотя бы на час
> вперед), так как Genesis32 оперирует временами, не
> превышающими текущее время.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: OPC Server for General Database Access
Автор: Жукова Г.В. 
Дата:   12.04.07 08:54

Работа у нас такая - забота о будущем российской электроэнергетики :)



Ничего себе! Как это вы в будущее заглянуть собрались? :)))

> Проблема, с которой столкнулись - изобразить график
> средствами Genesis32 на будущее время (хотя бы на час
> вперед), так как Genesis32 оперирует временами, не
> превышающими текущее время.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   12.04.07 08:57

Да я не спорю :) Просто пытяюсь понять задачу. Зачем? :)

> Работа у нас такая - забота о будущем российской электроэнергетики :)
Адрес этого сообщения    Ответить на это сообщение
 
 Re: OPC Server for General Database Access
Автор: Жукова Г.В. 
Дата:   12.04.07 09:02

Реализация плана балансирующего рынка электроэнергии машинистами
энергоблоков тепловой электростанции.

----- Original Message -----
From: <d_miloserdov@xxxxxxx.xx>


Да я не спорю :) Просто пытяюсь понять задачу. Зачем? :)

> Работа у нас такая - забота о будущем российской электроэнергетики :)
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   12.04.07 09:15

Т.е. план\модель с фактом сравниваете?
Это уже функция MES. Зря вы ее на уровень SCADA спускаете.
Ничего хорошего не получится. В будущем.
Могу подсказать где это реализовано уже давно - Первоуральский новотрубный завод (ПНТЗ)
На этом решении: http://www.korusconsulting.ru/netcat_files/417/250/h_4587c18c4d571223224f74f040bd2550
Сейчас идет процесс реализации на ВМЗ насколько я знаю. Но на другом решении.
И не на SCADA.

>
> Реализация плана балансирующего рынка электроэнергии
> машинистами энергоблоков тепловой электростанции.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: OPC Server for General Database Access
Автор: Жукова Г.В. 
Дата:   12.04.07 09:23

Задача в комплексе работает на нескольких уровнях: ERP, MES, АСУТП. SCADA
отображает графики для начальника смены станции и машинистов энергоблоков.
По ним машинисты ведут режим на энергоблоке.

----- Original Message -----
Т.е. план\модель с фактом сравниваете?
Это уже функция MES. Зря вы ее на уровень SCADA спускаете.
Адрес этого сообщения    Ответить на это сообщение
 
 Re[2]: OPC Server for General Database Access
Автор: Evgueny Tikhonovich 
Дата:   12.04.07 09:27

Приветствую!

   Глядь, а Жукова Г.В. в четверг 12 апреля 2007 г. 9:02 беседует с asutp@yahoogroups.com. А как же я?

ЖГВ> Реализация плана балансирующего рынка электроэнергии машинистами
ЖГВ> энергоблоков тепловой электростанции.

   Просто прогнозирование?


С Уважением, Тихонович Евгений.
Модератор ASUTP, ASUTPTALK, NEWSASUTP.
Письмо модератору - [название_конференции]-owner@yahoogroups.com
--
.... "Как правильно уложить парашют?" Пособие. Издание 2-е, исправленное.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   12.04.07 09:30

Понял. Тогда это просто вопрос интеграции данных MES и АСУ ТП.
Но я бы начальнику смены АРМ на SCADA не стал реализовывать- слишком трудоемко и бесполезно.
СКАДА- только операторам. Это ИМХО - мой подход.
А машинистам план зачем спускать?

> Задача в комплексе работает на нескольких уровнях: ERP, MES,
> АСУТП. SCADA отображает графики для начальника смены станции
> и машинистов энергоблоков.
> По ним машинисты ведут режим на энергоблоке.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Re[2]: OPC Server for General Database Access
Автор: Жукова Г.В. 
Дата:   12.04.07 09:31

Исполнение плана.

----- Original Message -----
From: "Evgueny Tikhonovich"
>   Просто прогнозирование?
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Re[2]: OPC Server for General Database Access
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   12.04.07 09:35

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

>    Просто прогнозирование?
Адрес этого сообщения    Ответить на это сообщение
 
 Re: OPC Server for General Database Access
Автор: Жукова Г.В. 
Дата:   12.04.07 09:43

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

----- Original Message -----
From: <d_miloserdov@xxxxxxx.xx>

Но я бы начальнику смены АРМ на SCADA не стал реализовывать- слишком
трудоемко и бесполезно.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   12.04.07 10:03

ОК. Да, тогда задача нетривиальная в этом случае.
Но все равно я бы так не стал делать изначально - слишком много проблем.
Тут на связке РСУ-MES задача непростая, что уж говорить про обычную SCADA...

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

> Можно сказать, что лично для начальника смены станции АРМа не
> разрабатывали.
> Он так же, как и машинисты энергоблоков, использует тонкий
> клиент сервера Genesis32, который формирует нужные тренды,
> сигнализацию и пр.
> Те же самые графики может смотреть и другой персонал станции.
Адрес этого сообщения    Ответить на это сообщение
 
 Re: OPC Server for General Database Access
Автор: Жукова Г.В. 
Дата:   12.04.07 10:09

Вижу, что задача всех заинтересовала.
Опишу коротко.
Раз в сутки Администратор торговой системы (НП АТС) направляет на
электростанцию план поставки электроэнергии на сутки вперед, разбитый по
часам. Его называют расчетный диспетчерский график (РДГ). В 0 часов он
вступает в работу. В течение суток РДГ может уточняться в зависимости от
ситуации, складывающейся на рынке электроэнергии или в зависимости от
состояния технологического оборудования электростанции. В результате, имеем
уточненный план на определенный диапазон времени в течение суток. Получается
уточненный график на текущие сутки (УДГ).
Сейчас 4 раза в сутки приходит на станцию график - план балансирующего рынка
(ПБР), который отменяет существующий РДГ до конца суток и заменяет его
новыми показаниями выработки электроэнергии. При этом команды УДГ имеют
приоритет перед ПБР. Возможно, в дальнейшем ПБР будут приходить более
часто...
Задача машиниста энергоблока - максимально приблизиться к текущему рабочему
диспетчерскому графику. Выработает больше плана - пойдет в убыток
предприятию: электроэнергию не оплатят, к тому же будет перерасход газа.
Выработает электроэнергии меньше - на предприятие будут наложены штрафные
санкции, электроэнергия будет стоить меньше.

Вот так и работают машинисты в режиме жесткого контроля плановой выработки
электроэнергии в условиях конкурентного рынка электроэнергии.

----- Original Message -----
From: <d_miloserdov@xxxxxxx.xx>
А машинистам план зачем спускать?
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   12.04.07 10:25

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

> Вижу, что задача всех заинтересовала.
> Опишу коротко.

> Вот так и работают машинисты в режиме жесткого контроля
> плановой выработки электроэнергии в условиях конкурентного
> рынка электроэнергии.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: Ilya Ablin 
Дата:   12.04.07 10:53

Добрый день!

>> Кроме того, подобный сервер мы делали для MS SQL
>
>Самостоятельный OPC-сервер или в объеме MasterSCADA?

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

С уважением,
Илья Аблин
Компания ИнСАТ
(495) 974-0092
mailto:ablin@xxxxx.xx
http://www.insat.ru
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: Ilya Ablin 
Дата:   12.04.07 10:54

Добрый день!

>При вводе в работу графиков ПБР возникла сложность частичной
>доработки имеющегося OPC-сервера, необходимо написать его
>заново, при этом человеческих ресурсов не хватает, наша
>основная работа - сопровождение, а не разработка.
>Нужен российский производитель, который предоставит готовый
>OPC-сервер для чтения базы данных и в короткий срок (до
>нескольких недель) доработает его под требования Заказчика.

Присылайте требования.

С уважением,
Илья Аблин
Компания ИнСАТ
(495) 974-0092
mailto:ablin@xxxxx.xx
http://www.insat.ru
Адрес этого сообщения    Ответить на это сообщение
 
 Re: OPC Server for General Database Access
Автор: Жукова Г.В. 
Дата:   12.04.07 11:26

Извините, ошибка вышла c названием базы данных.

База данных - MS SQL Server !


----- Original Message -----
From: "Жукова Г.В."

> Имеется ли у российских производителей аналогичный MatrikonOPC Server for
> General Database Access ?
>
> Конкретно интересует: OPC DA Server с доступом по сети Ethernet (TCP/IP) к
> базе данных  Microsoft Oracle для чтения данных.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: Кузьмин Юрий 
Дата:   12.04.07 11:56

>В терминах MES это называется- спустить Календарный план на уровень Оперативного планирования. Сравнение Плана (оперативного) с фактом произходит в модуле MES, куда подсасываются данные в риалтайме из АСУ ТП. На этом же уровне (MES) и рекомендуется реализовывать АРМЫ (в т.ч. с помощью тонкого клиента).
>Тогда все получится без излишнего геморроя ибо это задача для планировщика MES- родная. Спускать эту задачу на уровень SCADA - ИМХО в корне не верно. С этим и борюсь.
>В нормальных MES планировщик еще и выполняет автоматизированный перерасчет оперативного плана смотря на данные факта и предлагает несколько вариантов выхода из кризиса. При этом по вариантам показывает какие затраты (время, матресурсы) будут затрачены. Планировщик MES- это аналитическая система. Вы строите принятие решений слишком просто. В будущем придете к варианту, который я описал. Но планирование- задача очень сложная.

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

Я хочу, сказать что пока существет группа MESA и куда их дальше понесет большой вопрос. Вроде уровень вырисовывается, но средства пока не разработаны до конца.

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

Еще можно обосновать внедрение уровней АСУТП-SCADA, хотя бы тем что это современно, круто и вообщем так надо:) И подвести под это бюджет.

С ERP, вообще отдача может быть не то что нулевой, а вообще минус нулевой и это 50/50, ну естесственно здесь декларируется спасительный MES. ДЛя полноты картины он действительно смотрится красиво:))
Убедит ли это заказчика? Я бы сам с удовольствием услышал ответ на этот вопрос и как с обоснованием внедрения MES, так и без нее.

Вот к примеру АСУТП-ДУ-ИУС чем не деление? Весь вопрос кто напишет ИУС с нужным функционалом и вынесет ее на рынок.

С Уважением
Кузьмин Юрий
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   12.04.07 12:10

Посмотри кто у них в клиентах заодно :)

> Я хочу, сказать что пока существет группа MESA и куда их
> дальше понесет большой вопрос. Вроде уровень вырисовывается,
> но средства пока не разработаны до конца.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   12.04.07 12:07

Юра, я описываю реальность!
http://www.bronermetals.ru/solutions/planning.htm

Это тебе лично пример.

> Дима ты описываешь  идеальный вариант, как ситуацию для
> следующего уровня, под который есть софтина и которая должна
> отвечать на эти вопросы.
> Но сам же указал, функционал софтины не до конца разрабтан,
> да и уровень это еще абстрактен. ТОлько пока обставлен
> комитетами и вроде бы спецификациями, где ясности пока нет.
>
> Я хочу, сказать что пока существет группа MESA и куда их
> дальше понесет большой вопрос. Вроде уровень вырисовывается,
> но средства пока не разработаны до конца.
Адрес этого сообщения    Ответить на это сообщение
 
 Нужна ли MES?
Автор: Кузьмин Юрий 
Дата:   12.04.07 12:29

>В терминах MES это называется- спустить Календарный план на уровень Оперативного планирования. Сравнение Плана (оперативного) с фактом произходит в модуле MES, куда подсасываются данные в риалтайме из АСУ ТП. На этом же уровне (MES) и рекомендуется реализовывать АРМЫ (в т.ч. с помощью тонкого клиента).
>Тогда все получится без излишнего геморроя ибо это задача для планировщика MES- родная. Спускать эту задачу на уровень SCADA - ИМХО в корне не верно. С этим и борюсь.
>В нормальных MES планировщик еще и выполняет автоматизированный перерасчет оперативного плана смотря на данные факта и предлагает несколько вариантов выхода из кризиса. При этом по вариантам показывает какие затраты (время, матресурсы) будут затрачены. Планировщик MES- это аналитическая система. Вы строите принятие решений слишком просто. В будущем придете к варианту, который я описал. Но планирование- задача очень сложная.

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

Я хочу, сказать что пока существет группа MESA и куда их дальше понесет большой вопрос. Вроде уровень вырисовывается, но средства пока не разработаны до конца.

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

Еще можно обосновать внедрение уровней АСУТП-SCADA, хотя бы тем что это современно, круто и вообщем так надо:) И подвести под это бюджет.

С ERP, вообще отдача может быть не то что нулевой, а вообще минус нулевой и это 50/50, ну естесственно здесь декларируется спасительный MES. ДЛя полноты картины он действительно смотрится красиво:))
Убедит ли это заказчика? Я бы сам с удовольствием услышал ответ на этот вопрос и как с обоснованием внедрения MES, так и без нее.

Вот к примеру АСУТП-ДУ-ИУС чем не деление? Весь вопрос кто напишет ИУС с нужным функционалом и вынесет ее на рынок.

С Уважением
Кузьмин Юрий
Адрес этого сообщения    Ответить на это сообщение
 
 Нужна ли MES?
Автор: Кузьмин Юрий 
Дата:   12.04.07 12:39

>Юра, я описываю реальность!
>http://www.bronermetals.ru/solutions/planning.htm
>
>Это тебе лично пример.

Чего пример, что это есть?
А где прыгающие заказчики от радости?
ВОт эти
http://www.bronermetals.ru/corporate/implementations.htm

Реальность в отрыве от экономических расчетов, это не реальность.

А вот эти ребята по-моему еще дальше продвинулись
http://www.psi-bt.de/fileadmin/downloads/PSI_BT/PSI_BT_Metals_EN.pdf


Кузьмин Юрий
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Нужна ли MES?
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   12.04.07 12:56

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

> Чего пример, что это есть?
> А где прыгающие заказчики от радости?
> ВОт эти
> http://www.bronermetals.ru/corporate/implementations.htm
>
> Реальность в отрыве от экономических расчетов, это не реальность.
>
> А вот эти ребята по-моему еще дальше продвинулись
> http://www.psi-bt.de/fileadmin/downloads/PSI_BT/PSI_BT_Metals_EN.pdf
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Нужна ли MES?
Автор: Кузьмин Юрий 
Дата:   12.04.07 14:15

> Юр, че ты мне моск компостируешь? :)
>Сходи на аглицкий сайт да посмотри или вообще свяжись с конторой.
>Ты сначала утверждаешь что решений нет, потом сам же примеры внедрений приводишь...ты уж определись с позицией :)
>И вообще речь шла не эффективности а о функционале, а ты все передернул.

Примеры по красоте:)). Я их должен игнорировать?
Ну я вообщем коментировать нехочу, если просто говорить о функционале

>И вообще решения металлургии не применимы в непрерывном производстве.
>Я пример привел, а ты на некий конкретный проект свалился.
>Я говорю про то как нужно строить системы- ты про эффект рассуждаешь.
>А люди уже давно все просчитали и денег окучивают. Моя цель была уберечь от возможных ошибок реализации- а твоя какая? Нафлудить?
>

Просто говорить о функционале не говоря о затратах и есть флуд.
Чего за болезненная реакция?
Я еще не сваливался на проект. В металлургии процессы как дискретные, так и непрерывные, пора бы знать:))

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

С Уважением
Кузьмин Юрий

PS Дима твой ответ: MES нужен, потому что там есть новый функционал принят.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Нужна ли MES?
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   12.04.07 15:17

Ну как я затраты могу посчитать им? :)
Галина (верно?) говорила о том, что у них планируется связка- MES -ERP. Значит выбор уже сделан и все подсчитано. Остальное- дело техники.
Я предложил решение проблемы- им выбирать :)
Ну и своего ИМХО добавил. Собственно, проблему я их хорошо понимаю, поэтому встрял.

> А принципиально, просто функционал, без эффекта-это пустой
> звон, ну вроде очевидно.

Ну кто ж будет спорить? :)

> PS Дима твой ответ: MES нужен, потому что там есть новый
> функционал принят.

Не совсем так- Не стоит навешивать на АСУ ТП функции MES ибо в MES это проверенно работает. Это я и хотел сказать и показать на примере.
Никто же не требует от ERP сбор данных в реальном времени :) А еще 3 года назад такииие споры были на эту тему- аж держись.
Здравый разум вроде победил, больше даже не заикаются. Хотя казусы и у нас случаются - техническая политика дело такое...
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Нужна ли MES?
Автор: Кузьмин Юрий 
Дата:   12.04.07 16:17

>Ну как я затраты могу посчитать им? :)
>Галина (верно?) говорила о том, что у них планируется связка- MES -ERP. Значит выбор уже сделан и все подсчитано. Остальное- дело техники.
>Я предложил решение проблемы- им выбирать :)
>Ну и своего ИМХО добавил. Собственно, проблему я их хорошо понимаю, поэтому встрял.
>
Дим в отличие от тебя я встрял потому что не понимаю:)))
Это не у них планируется, а на рынке впаривают эту связку. Вот я только об этом и задумался:)

>
>Не совсем так- Не стоит навешивать на АСУ ТП функции MES ибо в MES это проверенно работает. Это я и хотел сказать и показать на примере.
>Никто же не требует от ERP сбор данных в реальном времени :) А еще 3 года назад такииие споры были на эту тему- аж держись.
>Здравый разум вроде победил, больше даже не заикаются. Хотя казусы и у нас случаются - техническая политика дело такое...

Я в этом очень сильно хочу убедиться. Логичнее было бы не навешивать а надстраивать.Собственно убеждаться что это, работает, что это нужно. И что нужны другие сервера на которых все это будет крутиться.
Достаточно делать выборку, ее анализировать спускать ниже или передавать на верх.
Но вот что привнесет нового именно другой пакет под названием MES я и хочу понять? Предоставит другие средства: моделирования, оптимизации,выбор критерия, расчет ТЭП?
Функционал они и так сделают и именно тот который они видят. Разместят так как захотят и понятно что с мин. затратами. Кривовато? может быть. Зато в голове сложится представление чего надо. И будут сформулиролваны требования к новым пакетам и главное в какие деньги это все будет вылеваться.
Мне кажется так.

Кузьмин Юрий
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: Sergey Gusev 
Дата:   12.04.07 17:29

И я о том же. Есть такое готовое решение. На стыке MES и SCADA. Если просто
использовать покупные компоненты BizViz, то ничего не стоит построить
график, например, реальных почасовых расходов на фоне "взгляда в будущее" из
SQL или Oracle. Причем этот график можно сразу опубликовать на портале и
динамически его обновлять. Стоимость такого решения - десятки К у.е.
Делается это все за 5 минут.

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

С уважением,

Сергей Гусев, ООО "Первая Миля"

-----Original Message-----
Задача в комплексе работает на нескольких уровнях: ERP, MES, АСУТП. SCADA
отображает графики для начальника смены станции и машинистов энергоблоков.
По ним машинисты ведут режим на энергоблоке.

----- Original Message -----
Т.е. план\модель с фактом сравниваете?
Это уже функция MES. Зря вы ее на уровень SCADA спускаете.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Нужна ли MES?
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   12.04.07 17:32

Ты думаешь на эти вопросы я отвечу не видя ни разу предприятия? :)))

> Я в этом очень сильно хочу убедиться. Логичнее было бы не
> навешивать а надстраивать.Собственно убеждаться что это,
> работает, что это нужно. И что нужны другие сервера на
> которых все это будет крутиться.
> Достаточно делать выборку, ее анализировать спускать ниже или
> передавать на верх.
> Но вот что привнесет нового именно другой пакет под названием
> MES я и хочу понять? Предоставит другие средства:
> моделирования, оптимизации,выбор критерия, расчет ТЭП?
> Функционал они и так сделают и именно тот который они видят.
> Разместят так как захотят и понятно что с мин. затратами..
> Кривовато? может быть. Зато в голове сложится представление
> чего надо. И будут сформулиролваны требования к новым пакетам
> и главное в какие деньги это все будет вылеваться.
> Мне кажется так.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: Ilya Ablin 
Дата:   12.04.07 18:44

>И я о том же. Есть такое готовое решение. На стыке MES и
>SCADA. Если просто использовать покупные компоненты BizViz, то
>ничего не стоит построить график, например, реальных почасовых
>расходов на фоне "взгляда в будущее" из SQL или Oracle. Причем
>этот график можно сразу опубликовать на портале и динамически
>его обновлять. Стоимость такого решения - десятки К у.е.
>Делается это все за 5 минут.

Не понимаю, за что такие деньги. Любая нормальная SCADA такое умеет за
те же 5 минут, если умеючи. Включая и нашу MasterSCADA.

С уважением,
Илья Аблин
Компания ИнСАТ
(495) 974-0092
mailto:ablin@xxxxx.xx
http://www.insat.ru
Адрес этого сообщения    Ответить на это сообщение
 
 Re: Нужна ли MES?
Автор: Жукова Г.В. 
Дата:   13.04.07 11:22

>  Не стоит навешивать на АСУ ТП функции MES ибо в MES это проверенно
> работает.

Уточнение: У нас сервер Genesis32 - не АСУ ТП. На нашем предприятии АСУ ТП
для энергоблоков ? 1 и 2 Teleperm XP-R (Интеравтоматика, Siemens) и для
энергоблока ? 3 - Procontrol P POS30 (АВВ Германия).

Genesis32 был когда-то куплен для вывода графических трендов на АРМах
пользователей. Он имеет мощные графические возможности по сравнению с Excel.
Затем его использовали для мониторинга водно-химического режима
энергоблоков. Потом диспетчерские графики выработки электроэнергии.
Последняя работа с использованием Genesis32 - мониторинг АРЧМ
(автоматическое регулирование частоты и мощности) энергоблоков.
Сервер Genesis32 - у нас чисто информационная система без возможности
управления. Он располагается на пару уровеней выше АСУ ТП.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: Sergey Gusev 
Дата:   13.04.07 12:10

Если это на самом деле интересно, я готов отдельно (можно лично Вам)
рассказать, за что берутся эти деньги.
Если "вдаваться в детали" нет желания/времени, то просто поверьте:) Ни одна
SCADA в мире из известных мне (а Мастер_скаду я знаю неплохо, и давно слежу
за ее прогрессом) не может этого. Более того, ни одна MES или СУБД или
существующие "портальные" решения не могут этого. Для этого, собственно,
BizViz и придумывался:)
А задачка с перемещением графиков "назад в будущее" - всего лишь один из
"воробьев", по которым можно стретять из этой "пушки":)
Заметьте, я этого не предлагал, и для своих клиентов, у которых задач
"макро-вмзуализации" нет, мы решаем это именно в рамках SCADA, естественно,
немного "умеючи"...:)

С уважением,
Сергей Гусев, ООО "Первая Миля"

-----Original Message-----
>И я о том же. Есть такое готовое решение. На стыке MES и SCADA...
>......- десятки К у.е.
>Делается это все за 5 минут.

Не понимаю, за что такие деньги. Любая нормальная SCADA такое умеет за те же
5 минут, если умеючи. Включая и нашу MasterSCADA.

С уважением,
Илья Аблин
Компания ИнСАТ
Адрес этого сообщения    Ответить на это сообщение
 
 RE: OPC Server for General Database Access
Автор: Ilya Ablin 
Дата:   13.04.07 14:14

Добрый день!

>Если это на самом деле интересно, я готов отдельно (можно
>лично Вам) рассказать, за что берутся эти деньги.

Интересно. Можно лично мне.

>А задачка с перемещением
>графиков "назад в будущее" - всего лишь один из "воробьев", по
>которым можно стретять из этой "пушки":)

Перемещать графики "назад в будущее" несложно - у нас для этого
достаточно установить параметрам, отправляемым в тренд, временные
метки из этого будущего.

С уважением,
Илья Аблин
Компания ИнСАТ
(495) 974-0092
mailto:ablin@xxxxx.xx
http://www.insat.ru
Адрес этого сообщения    Ответить на это сообщение
 
 Re: OPC Server for General Database Access
Автор: @sutp 
Дата:   13.04.07 16:02

Когда выбирали Скаду, показалось, что функциональность у всех почти одинаковая. Genesis выбрали, так как у нее самые красивые визуальные элементы :)
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Нужна ли MES?
Автор: Кузьмин Юрий 
Дата:   13.04.07 16:25

>Ты думаешь на эти вопросы я отвечу не видя ни разу предприятия? :)))
>

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

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

Кузьмин Юрий
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Нужна ли MES?
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   16.04.07 08:05

Юр, гы :) а ты хоть одну систему у нефтяников построил чтобы так заявлять? :)

> Ну так известный подход, люди не задумываясь назывют
> какой-либо уровень MESом и ищут там функционал
> соответствующий одинадцати пунктам MESA и этот подход
> выработан ассоциацией MESA независимо от отрасли,
> предприятия.
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Нужна ли MES?
Автор: Кузьмин Юрий 
Дата:   17.04.07 11:05

>Юр, гы :) а ты хоть одну систему у нефтяников построил чтобы так заявлять? :)
>

Я строительством не занимаюсь:)

А вообще умных дядек читаю, потом думаю....
http://www.sql.ru/forum/actualthread.aspx?bid=53&tid=388372&pg=1&hl=mes#3704103

Юрий
Адрес этого сообщения    Ответить на это сообщение
 
 RE: Нужна ли MES?
Автор: d_miloserdov@xxxxxxx.xx 
Дата:   18.04.07 09:30

:)) и с Сахаватом и с Равилем я много общался. Они никогда не строили MES в нефтянке.
Мужики весьма умные, не спорю. Но мою тематику не знают.

>
> А вообще умных дядек читаю, потом думаю....
> http://www.sql.ru/forum/actualthread.aspx?bid=53&tid=388372&pg
> =1&hl=mes#3704103
Адрес этого сообщения    Ответить на это сообщение
 Список форумов    


 Список форумов  |  Нужен логин? Регистрируйтесь здесь 
 Логин пользователя
 Имя пользователя:
 Пароль:
 Помнить пароль:
   
 Забыли ваш пароль?
Введите имя пользователя или e-mail, и новый пароль будет послан на email, указанный в вашем профиле.

Рейтинг@Mail.ru