Облачные SCADA

[Siluet]

Сдаётся мне, Виталий, что Вы путаете SCADA и MES.
SCADA находится на уровне АСУТП, а MES - уже на уровне АСУПП и АСУП.

С MES я сталкивался, это уже надстройка выше, с планированием и логистикой. Дело в том, что беседуя о SCADA все имеют ввиду SCADA-HMI, такая некая продвинутая панель управления с постоянным управлением ТП через нее. Я же хочу объяснить, что остальные функции скады было бы эффективно отправить в облака. Вполне реально обеспечить режим реального времени (5сек). И пользоваться преимуществами.

И если в облаках не очень-то приживается АСУТП, то MES эффективные манагеры в облако не отпустят уже просто из инстинкта самосохранения

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

[Ryzhij]

Вы писали о сжатии потока данных, поэтому я указал на MES.
Сжатие и выборка из потока данных применимы только начиная с уровня MES, на уровне SCADA и HMI это не применяется.

[Jackson]

И если в облаках не очень-то приживается АСУТП, то MES эффективные манагеры в облако не отпустят уже просто из инстинкта самосохранения

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

Совсем не поэтому.

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

[Jackson]

С MES я сталкивался, это уже надстройка выше, с планированием и логистикой. Дело в том, что беседуя о SCADA все имеют ввиду SCADA-HMI, такая некая продвинутая панель управления с постоянным управлением ТП через нее. Я же хочу объяснить, что остальные функции скады было бы эффективно отправить в облака.

Тогда на руках останется только HMI. О чём и речь, и вроде как понятно.

Вопрос: Если мне нужно собрать 30-50 статистических выборок, по сотне параметров которые регистрируются с частотой 4 раза в секунду периодами по полсуток (12 часов) - пятьдесят таких отчётов мне надо сформировать и потом ещё в них покопаться - мой HMI будет ломиться в облако за этими данным. А где будет делаться выборка - на стороне HMI или в облаке? Сколько я буду ждать результатов каждой выборки? И не сдохнет ли управление от моих запросов? Реальный случай из моей практике - я как приезжаю на объект так начинаю смотреть эти выборки, и я не один туда так езжу, короче там такие пачки выборок практически каждый день делают.
Как, будет работать?

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

[Romcheg]

Вполне реально обеспечить режим реального времени (5сек).

Спасибо, посмеялся. Например, у Газпрома для систем энергоснабжения требование: команда управления должна проходить за 1.5 секунды путь от АРМ оперативного персонала - до ИМ - и обратный сигнал срабатывания до АРМ, не считая времени срабатывания ИМ, но считая динамику обновления графики АРМ. Так, чтобы обеспечить это в локальной сети для систем на 5к-10к точек ввода/вывода народ во многих скада-пакетах прыгает с бубном, а Вы про Интернет, да еще и "реальное время (5сек)", это, простите, тормоз даже не ручной, это уже что-то вроде морского якоря... Еще момент: там же в требованиях у них есть пункт черным по-белому, что время обновления информации (текущие значения, сообщения в журнале событий и прочее) от поля до экрана АРМ оперативного персонала не должно превышать 1.5 секунды, включая время обновления графики АРМ.
Для большинства систем, технологии, которые Вы полагаете использовать, пока еще "витают в облаках". Какие тут 5 секунд...
Кстати, вопрос: а с чего Вы взяли, что транзакция по сети Интернет без дополнительных ухищрений даст Вам эти ГАРАНТИРОВАННЫЕ 5 секунд? мне кажется, Вам надо немного полистать матчасть. Как ни крути, чтобы обеспечить приемлемое буферирование данных с поля перед тем как их в облако передать - не обойтись без серверов сбора и обработки данных на объекте, тот самый "CONTROL And DATA ACQUISITION" иначе SUPERVISORY будет с очень большими потерями этих данных работать в Вашем "облаке".

[Jackson]

Вполне реально обеспечить режим реального времени (5сек).

Спасибо, посмеялся. Например, у Газпрома для систем энергоснабжения требование: команда управления должна проходить за 1.5 секунды путь от АРМ оперативного персонала - до ИМ - и обратный сигнал срабатывания до АРМ, не считая времени срабатывания ИМ, но считая динамику обновления графики АРМ.

Не всё так смешно как кажется.

Например в электростанции процессы настолько могут быть растянуты, что и +- 10 секунд погоду не сделают, это нормально. Но когда речь идёт о прямом телеуправлении - там и секунды много. Например на одном объекте обычное управление бегало с быстродействием как раз до 5 сек, но для некоторых сигналов и команд мы бились за каждую миллисекунду, нам 100 мс было катастрофически много (добились 20 мсек, это был физический предел для того случая).

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

Я повторю своё мнение. Виталий рассматривает только HMI, и, видимо, считает что если всё остальное выкинуть куда-то наружу - в облако - то оно перестаёт быть проблемой, а на самом деле проблемы только нарастают. Либо же, интересует исключительно HMI с простым отображением без выборок, отчётов и прямой завязки на управление. И ошибочно назвав всё это "СКАДА" он ввёл нас всех в заблуждение.

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

[Siluet]

Сжатие и выборка из потока данных применимы только начиная с уровня MES, на уровне SCADA и HMI это не применяется.

Я имею ввиду сжатие без потерь, внутри канала. Создаете канал vpn и гоняете по нему modbusTCP. А сжатие происходит на уровне выше. Так работают сетевые com порты, некоторые модемы.

[Siluet]

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

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

[Jackson]

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

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

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

[Siluet]

Вопрос: Если мне нужно собрать 30-50 статистических выборок, по сотне параметров которые регистрируются с частотой 4 раза в секунду периодами по полсуток (12 часов) - пятьдесят таких отчётов мне надо сформировать и потом ещё в них покопаться - мой HMI будет ломиться в облако за этими данным. А где будет делаться выборка - на стороне HMI или в облаке? Сколько я буду ждать результатов каждой выборки? И не сдохнет ли управление от моих запросов? Реальный случай из моей практике - я как приезжаю на объект так начинаю смотреть эти выборки, и я не один туда так езжу, короче там такие пачки выборок практически каждый день делают.
Как, будет работать?

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

Это уже вопросы конкретной реализации и жирности каналов в интернет. В быстрых процессах потребуется сетевой контроллер, который будет аккумулировать выборки сигналов и отсылать (асинхронно) в облако. Дальнейшую обработку можно делать в облаке - нормализацию, поиск максимумов, тренд годовой, месячный и тд. Результаты можно получать по требованию и быстро, т.к., например, годовой тренд будет передаваться не как миллион значений, а пару тысяч значений для отображения. Если нужно произвести анализ, который заранее неизвестен и требует больной вычислительный мощности (спектральный анализ сигналов за 5 лет) то дополнительные колоссальные мощности в облаке могут подключаться автоматически.

Реальный случай из моей практике - я как приезжаю на объект так начинаю смотреть эти выборки, и я не один туда так езжу, короче там такие пачки выборок практически каждый день делают.
Как, будет работать?

- в этом случае ни куда ехать не надо, отчет сам поступает на почту

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

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

Облачная Скада осуществляет диспетчерское управление в реальном времени (пусть даже 5 сек), это не оперативное управление конкретными механизмами, клапанами, вентилями... А, на пример, переключение, включение агрегатов, управление уставками, контроль за параметрами и тд. Она же реализует сбор и хранение данных.

Я не говорю, что надо в нынешних условиях пихать облачные скады везде и всюду, но в них можно увидеть реальные преимущества и перспективы

[Siluet]

Газпрома для систем энергоснабжения требование: команда управления должна проходить за 1.5 секунды путь от АРМ оперативного персонала - до ИМ - и обратный сигнал срабатывания до АРМ, не считая времени срабатывания ИМ, но считая динамику обновления графики АРМ. Так, чтобы обеспечить это в локальной сети для систем на 5к-10к точек ввода/вывода народ во многих скада-пакетах прыгает с бубном, а Вы про Интернет, да еще и "реальное время (5сек)", это, простите, тормоз даже не ручной, это уже что-то вроде морского якоря... Еще момент: там же в требованиях у них есть пункт черным по-белому, что время обновления информации (текущие значения, сообщения в журнале событий и прочее) от поля до экрана АРМ оперативного персонала не должно превышать 1.5 секунды, включая время обновления графики АРМ.

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

Кстати, вопрос: а с чего Вы взяли, что транзакция по сети Интернет без дополнительных ухищрений даст Вам эти ГАРАНТИРОВАННЫЕ 5 секунд? мне кажется, Вам надо немного полистать матчасть. Как ни крути, чтобы обеспечить приемлемое буферирование данных с поля перед тем как их в облако передать - не обойтись без серверов сбора и обработки данных на объекте, тот самый "CONTROL And DATA ACQUISITION" иначе SUPERVISORY будет с очень большими потерями этих данных работать в Вашем "облаке".

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

[Siluet]

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

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

[dtv]

Виталий, Вы видимо никогда не работали над системами, опрашивающими сотню-другую каналов в "реальном" времени с частотой 20-100 Гц. В таких системах аварийные ситуации обрабатываются отнюдь не "оператором с задержкой 0.3 секунды", а автоматически, с помощью SCADA. Человеку остаётся только наблюдать, как правильно настроенная система предотвращает развитие аварийной ситуации. Не знаю как у других, на моих системах время реакции на аварийную ситуации - 0.1 секунды. Оператору остаётся только прочитать комментарий системы и пойти устранять причину остановки.

[Jackson]

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

Вопрос: Если мне нужно собрать 30-50 статистических выборок, по сотне параметров которые регистрируются с частотой 4 раза в секунду периодами по полсуток (12 часов) - пятьдесят таких отчётов мне надо сформировать и потом ещё в них покопаться - мой HMI будет ломиться в облако за этими данным. А где будет делаться выборка - на стороне HMI или в облаке? Сколько я буду ждать результатов каждой выборки? И не сдохнет ли управление от моих запросов? Реальный случай из моей практике - я как приезжаю на объект так начинаю смотреть эти выборки, и я не один туда так езжу, короче там такие пачки выборок практически каждый день делают.
Как, будет работать?

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

Это уже вопросы конкретной реализации и жирности каналов в интернет. В быстрых процессах потребуется сетевой контроллер, который будет аккумулировать выборки сигналов и отсылать (асинхронно) в облако. Дальнейшую обработку можно делать в облаке - нормализацию, поиск максимумов, тренд годовой, месячный и тд. Результаты можно получать по требованию и быстро, т.к., например, годовой тренд будет передаваться не как миллион значений, а пару тысяч значений для отображения. Если нужно произвести анализ, который заранее неизвестен и требует больной вычислительный мощности (спектральный анализ сигналов за 5 лет) то дополнительные колоссальные мощности в облаке могут подключаться автоматически.

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

Реальный случай из моей практике - я как приезжаю на объект так начинаю смотреть эти выборки, и я не один туда так езжу, короче там такие пачки выборок практически каждый день делают.
Как, будет работать?

- в этом случае ни куда ехать не надо, отчет сам поступает на почту

Надо ехать. Срезанные болты из облака не поменяешь. И ПИД-регулятор из облака не настроишь.
В каком виде придёт отчёт? В виде письма объёмом гигов так 25? И что мне с ним делать? Заново импортировать в ХМИ? При том что ВинЦЦ прекрасно справляется с этой задачей в течение пары минут не имея ни интернета ни почты ни никакого софта кроме себя самой ни - как Вы предлагаете - сетевых контроллеров. Зачем?

[Jackson]

Виталий, Вы видимо никогда не работали над системами, опрашивающими сотню-другую каналов в "реальном" времени с частотой 20-100 Гц. В таких системах аварийные ситуации обрабатываются отнюдь не "оператором с задержкой 0.3 секунды", а автоматически, с помощью SCADA. Человеку остаётся только наблюдать, как правильно настроенная система предотвращает развитие аварийной ситуации.

Вообще-то говоря, СКАДА тоже не будет ничего предотвращать. ПАЗ и СКАДА друг с другом никак не связаны, как космос и Таганрог.

[Ryzhij]

Виталий, Вы видимо никогда не работали над системами, опрашивающими сотню-другую каналов в "реальном" времени с частотой 20-100 Гц. В таких системах аварийные ситуации обрабатываются отнюдь не "оператором с задержкой 0.3 секунды", а автоматически, с помощью SCADA. Человеку остаётся только наблюдать, как правильно настроенная система предотвращает развитие аварийной ситуации.

Вообще-то говоря, СКАДА тоже не будет ничего предотвращать. ПАЗ и СКАДА друг с другом никак не связаны, как космос и Таганрог.

ИМХО, SCADA это не парящая в воздухе массонская пирамида, а и всё то, что под ней.
Короля, как известно, делает свита.
Есть функции, которые удобнее решать на верхнем уровне.
Например, если тех.процесс не терпит резких изменений каких-либо целевых параметров регулирования, значит SCADA обязана "приструнить" чересчур ретивого оператора и дать ему знать об этом сразу же.
А уж события от ПАЗ SCADA должна фиксировать с максимально возможным разрешением по времени.

[Siluet]

Виталий, Вы вообще хоть одну полноценную АСУ создавали? А то у меня такое подозрение что нет. Разговор перевожу в область пустого трёпа, ибо он и есть...

- пару в месяц, иногда частично участвую, иногда полностью, я пишу о том, что знаю и чем спотыкаюсь. Были по 20-30 кило точек с 3мя серверами.

На...зачем это всё надо: контроллеры сетевые с кэшем, каналы резервированные толстенные - зачем, когда один локальный сервер данных всё это делает без интернет-каналов с руку толщиной и без дополнительных колоссальных мощностей? ЗАЧЕМ это всё?

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

...Эти колоссальные мощности кстати откуда возьмутся? Господь бог подарит? Или их кто-то сделать должен, заплатив за это? Сколько это всё будет всё стОить - Вы считали? Посчитайте.

Я пользуюсь самодельной облачной системой сбора, хранения и анализа данных. Из разных объектов она подтягивает нужные мне данные. Она узко специализированная. Красочного интерфейса не имеет, мне достаточно в таблице посмотреть. Мне дискового пространства хватает - 20Гб (данные обрабатываются и обобщаются), и месячного трафика в 1Тб. Итого 2 задублированных сервера (на практике достаточно и одного, 2й больше для эксперементов) по 5$ в месяц (есть и дешевле, российские по 190р/месяц бывают). Итого 300$ за 5 лет, срок службы стационарника. Это дешевле, чем стоимость стационарного компьютера. Если нужны сверхмощности - система может поднять 20 процессорный сервер за 1$/час. В облачных технологиях все гибко - в этом их преимущество.

В виде письма объёмом гигов так 25? И что мне с ним делать?

- Данные не сжаты, или там белый шум. К тому же для построения годовых, месячных трендов не нужны все значения с интервалом 200ms. Нужно определиться какое представление нужно и его запрашивать, нужен максимум - получаем одно значение-максимум, нужен интеграл - получаем интеграл. Скада тоже на запрос - показать тренд не перелопачивает 25 гигов (тогда были бы зависания на пару минут).

Заново импортировать в ХМИ?

- Это уже возможности конкретной скады, может клиент на компьютере, может просто WEB страница, или готовый отчет в pdf.

При том что ВинЦЦ прекрасно справляется с этой задачей в течение пары минут не имея ни интернета ни почты ни никакого софта кроме себя самой

- интернет-обязательное условие, будет ВынСС в облаке будет даже быстрее справляться, и главное - прямо на офисный компьютер.

как Вы предлагаете - сетевых контроллеров. Зачем?

- можно без них, но требуют высокую частоту сбора, да и в контроллере тяжело написать программу взаимодействия с облаком (будет время - по экспериментирую с этим). Для организации прозрачного канала PLC - SCADA, как вариант можно использовать сетевые контроллеры, к примеру cisco vpn. И контроллер не поймет, что он с облаком взаимодействует, а не с рядом стоящем компьютером.
__________________________________________________
Я все это пишу, потому что осознал на сколько это может быть удобно и категорически отрицать невозможность применения не стоит. Не везде, не всегда стоит применять, нужно взвешивать преимущества и недостатки.

[Romcheg]

Ну, пока кто-то размышляет на тему, кто-то уже пробует щупать нишу: http://sky-vent.ru/

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

[Jackson]

Виталий, Вы видимо никогда не работали над системами, опрашивающими сотню-другую каналов в "реальном" времени с частотой 20-100 Гц. В таких системах аварийные ситуации обрабатываются отнюдь не "оператором с задержкой 0.3 секунды", а автоматически, с помощью SCADA. Человеку остаётся только наблюдать, как правильно настроенная система предотвращает развитие аварийной ситуации.

Вообще-то говоря, СКАДА тоже не будет ничего предотвращать. ПАЗ и СКАДА друг с другом никак не связаны, как космос и Таганрог.

ИМХО, SCADA это не парящая в воздухе массонская пирамида, а и всё то, что под ней.
Короля, как известно, делает свита.
Есть функции, которые удобнее решать на верхнем уровне.
Например, если тех.процесс не терпит резких изменений каких-либо целевых параметров регулирования, значит SCADA обязана "приструнить" чересчур ретивого оператора и дать ему знать об этом сразу же.
А уж события от ПАЗ SCADA должна фиксировать с максимально возможным разрешением по времени.

Совершенно с вами согласен, СКАДА все эти функции должна выполнять. Но не функцию ПАЗ саму по себе. СКАДА только зарегистрирует работу ПАЗ, и сделать это она должна - Вы совершенно опять-таки правы - надёжно и быстро.

[Jackson]

ЗАЧЕМ это всё?

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

Это всё хорошо для распределённых объектов. Географически распределённых. И неопасных, когда встал агрегат где-то - можно спокойно потянуться, перелезть через барышню и, сходив на кухню за чайком, вернуться чтобы решить проблему. А в масштабах НПЗ какого-нибудь или ТЭЦ персонал сидел и будет сидеть локально, он никуда не денется. На таких объектах сидение на диване с пивом и поглядывание вплоглаза в планшет за ТП - недопустимо на текущем уровне морального развития человечества (и по этой причине будет так ещё очень долго, т.к. моральный уровень человечества не улучшается последние 400 лет). Дисциплина нужна. Даже в каком-нибудь посёлковом энергоцентре сидит человек и будет сидеть - экстренно крутить гайки автоматика пока не научилась.

В виде письма объёмом гигов так 25? И что мне с ним делать?

- Данные не сжаты, или там белый шум. К тому же для построения годовых, месячных трендов не нужны все значения с интервалом 200ms. Нужно определиться какое представление нужно и его запрашивать, нужен максимум - получаем одно значение-максимум, нужен интеграл - получаем интеграл. Скада тоже на запрос - показать тренд не перелопачивает 25 гигов (тогда были бы зависания на пару минут).

Именно перелопачивает, и я даже упомянул какая именно СКАДА. Потому что нужны все данные за каждую точку и каждый квант времени. И это прекрасно работает.

[Siluet]

Именно перелопачивает, и я даже упомянул какая именно СКАДА. Потому что нужны все данные за каждую точку и каждый квант времени. И это прекрасно работает.

Что бы прочитать 25 Гб данных с диска среднему диску (нагуглил среднюю скорость чтения 120Mb/s) нужно 25 * 1024 / 120 = 213,3 s, т.е. 3,5 минуты минимум, плюс обработка обработка в самой базе (поиск по первичным ключам в таблицах, авторизация пользователя), плюс работа самой системы с текущими данными.
Т.е. скада может хранить все данные, но выдает она позиционно и обобщенно.

[Ryzhij]

3,5 минуты это ещё мало и очень хорошо для прорисовки тренда 3-4 пперьев за пару суток.
Представляю сколько кофе можно успеть выпить пока такой же объём соизволит выпасть из облака! Глаза друг-об-друга стучать начнут.

[Alex question]

3,5 минуты это ещё мало и очень хорошо для прорисовки тренда 3-4 пперьев за пару суток.

Это очень много.
У нас в ПТК за 3,5 минуты отрисовываются тренды за пару-тройку лет.

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

[Siluet]

3,5 минуты это ещё мало и очень хорошо для прорисовки тренда 3-4 пперьев за пару суток.
Представляю сколько кофе можно успеть выпить пока такой же объём соизволит выпасть из облака! Глаза друг-об-друга стучать начнут.

На мониторе нет столько пикселей, что отобразить все данные за год. Скада обрабатывает данные и создает дневные, месячные, годовые срезы (это даже настраивается) и отображает на тренде 2000 значений, а не миллионы. Если нужно посмотреть тренд в течение минуты - тогда да, будут отображены все значения. С облаком абсолютно также, трафик будет не большой.

[Jackson]

Именно перелопачивает, и я даже упомянул какая именно СКАДА. Потому что нужны все данные за каждую точку и каждый квант времени. И это прекрасно работает.

Что бы прочитать 25 Гб данных с диска среднему диску (нагуглил среднюю скорость чтения 120Mb/s) нужно 25 * 1024 / 120 = 213,3 s, т.е. 3,5 минуты минимум, плюс обработка обработка в самой базе (поиск по первичным ключам в таблицах, авторизация пользователя), плюс работа самой системы с текущими данными.
Т.е. скада может хранить все данные, но выдает она позиционно и обобщенно.

Мне нечем парировать. Я держал в руках эту скаду, работал с этими данными неоднократно, знаю как оно там на самом деле и что нужно именно так, а вы мне рассказываете что всё совсем не так. Точно также вы отвечаете и на всё остальное не только мне. Если вы считаете что вам виднее - ну считайте. :) Но говорить тогда просто не о чем - вы же сами всё знаете. Зачем тогда весь этот трёп?