Регистрация | Последние сообщения | Персональный список | Поиск | Настройка конференции | Личные данные | Правила конференции | Список участников | Top 64 | Статистика раздела | faq | Что нового v.2.3 | Чат
Skunk Forum - Техника, Наука, Общество » АСУТП »
Необходимые программные инструменты в ПТК (страница 3)

Версия для печати (настроить)
Страницы: 1 2 3 4 5

Новая тема | Написать ответ

Подписаться

Автор Тема:   Необходимые программные инструменты в ПТК
Avsha
Junior Member

Сообщений: 21
Регистрация: Июль 2005

написано 18 Августа 2005 13:38ИнфоПравкаОтветитьIP

Спасибо за ответ, появились дополнительные вопросы:

1.Что используется в качестве архива у менеджера сводок (реляционная БД, специфический архив)?
2. Как вы действуете (в смысле восстановления информации) при простое контроллера с расчетными параметрами (накоплениями, усреднениями).
3. Есть ли механизмы корректировки расчетных параметров в контроллерах и в архиве менеджера сводок.

Наша стратегия расчетов следующая:
1. Контроллер формирует среднеминутные значения по всем параметрам и передает в SCADу. Контроллер не имеет архива, только держит текущие значения расчетных параметров.
2. SCADA архивирует в реальном времени данные в “свой” специфический архив HTRDATA, который можно просмотреть в графиках на АРМ. Но он не очень удобен для формирования по нему сводок и отчетов, он не позволяет в себя писать сторонними средствами.
3. Поэтому каждую минуту SCADA сбрасывает среднеминутные значения на сервер в реляционную базу, где специальная станция – вычислитель проводит обработку и опять же складывает в архив.

Хотя есть реализации расчетов накопления в контроллере, а некоторые расчеты возможны только в контроллере по быстродействию, точности и по функциям обработки.

Anatol_K
unregistered
написано 18 Августа 2005 16:50  ПравкаОтветитьIP

Отвечу на ваши вопросы
1. В состав ПТК входит единый архивный сервер, в котором грубо говоря крутятся следующие задачи сбора и обработки информации: сбор в реальном времени всех параметров с контроллера по которым разрешено архивирование и их усреднение (включая и дискретные параметры), есть задача сбора списка тревог и событий, которые также забираются с сервера тревог контроллера и задача сбора информации менеджера сводок. Все это на сервере прокручивается, пакуется и сваливается в архивную базу данных через Interbase. Достается из этой базы информация стандартными SQL средствами и выдается в удобном виде.
2. Насчет восстановления информации при простое контроллера мы уже с вами беседовали. Восстановлению подлежат только наиболее важные параметры, касающиеся например коммерческого учета. При восстановлении накопительных счетчиков действуем так: вводим три режима восстановления, которые выбираются метрологами на этапе пуско-наладочных работ: первый - в случае простоя доращиваем сумму на величину времени простоя умноженному на заранее заданную договорную величину, второй - тоже самое, но в качестве домножителя используется число, пробитое в конфигурационной базе данных, как начальное значение и третье - в качестве домножителя используются данные, сохраненные во флэш памяти, как значения предыдущего часа, суток, месяца, поделенные на соответствующий временной интервал. Точно также мы восстанавливаем усредненные значения, поскольку в их состав также входят накопительные усреднительные счетчики и их тоже нужно сохранять. Все эти накопительные величины сохраняются контроллером в энергонезависимой памяти с меткой времени.
3. Расчетнные параметры контроллера можно корректировать любым способом, была бы методика и алгоритм такой корректировки. Если это накопительный счетчик, то его можно всегда предустановить или сбросить, если это математика, то можно из АРМ вводить нужные нам коэффициенты или режимы расчета. Поскольку менеджер сводок тянет данные из контроллера, апотом через архивный сервер валит все в архивную базу данных, то коррекция сводок возможна шпионскими методами путем работы с SQL Explorer/ То есть архивы, в принципе можно править, но кому это надо лишние проблемы на свою голову. И еще, посколку сводки и отчеты выдаются в виде текстовых файлов, можно прямо в текстовом редакторе их и править.
Я хотел бы у вас поинтересоваться, каким образом контроллер усредняет значения. Как известно среднее есть сумма, деленная на количество измерений. Понятно что до бесконечности число измерений мы довести не можем, поэтому при мгновенном усреднеиии есть два подхода - непрерывный и интервальный.При непрерывном к текущему среднему всегда прибавляется входная величина и все это делится на коэффициент , пропорциональный времени усреднения. Это трудно назвать усреднителем в классическом смысле. Это фильтр нижних частот первого порядка. Интервальный усреднитель работает честнее, где накопительный счетчик среднего сбрасывается и возобновляет свою работу через заданные интервалы времени, например каждую минуту. При усреденении текущее среднее и входная величина делится на величину кратную количеству измерений, как и предполагается в классической формуле вычисления мгновенного среднего.
А вот в архиве усреднение делается совсем честно, поскольку там вычисляется не мгновенное среднее, а просто среднее по классической формуле арифметики - сумма делить на эн. Данные могут быть взяты из любого временного отрезка.

Павел Мощицкий
Member

Сообщений: 1022
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 18 Августа 2005 20:34ИнфоПравкаОтветитьIP

Anatol_K
если несколько контроллеров, то один (под NT) является как бы отдельной системой сбора и обработки со своей базой данных и скадой, а нижние контроллеры имеют уже свою базу данных и свои скады.
1. Интересное у Вас понимание термина SCADA.
2. На сколько хватает БД на контроллере? Ведь ее нужно скидывать в архив на ПК.
3. Если Вас почитать, то АРМ у Вас мало функций выполняет, все находится в контуре САУ.

Anatol_K
unregistered
написано 18 Августа 2005 21:37  ПравкаОтветитьIP

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

Avsha
Junior Member

Сообщений: 22
Регистрация: Июль 2005

написано 19 Августа 2005 06:38ИнфоПравкаОтветитьIP

Про усреднение в контроллере:

Усреднение у нас интервальное по вашей классификации.
Контроллер работает с циклом ~20 мс, на каждом цикле считаем сумму и количество тактов (n), затем каждую минуту делим сумму на n и формируем среднеминутное значение, на этом же цикле заводим счетчик для новой минуты.
Такой расчет достаточно точный - n=60000/20=3000 измерений.
В итоге получаем среднеминутное значение, которое изменеяется раз в минуту, оно нас устраивает. Соответственно взяв 60 среднеминутных значений за 1 час получим часовое значение и т.д., т.е. дальнейшие расчеты мы ведем по среднеминутным.

Anatol_K
unregistered
написано 19 Августа 2005 09:29  ПравкаОтветитьIP

Да нет , по моей классификации - это третий способ, первые два способа вычмсляют текущее среднее, которое постоянно меняется от такта к такту, а в вашем случае это "честное среднее", которое меняется раз в минуту. А вы, как восстанавливаете в данном случае счетчики сумм и восстанавливаете ли по всем параметрам?

Avsha
Junior Member

Сообщений: 23
Регистрация: Июль 2005

написано 19 Августа 2005 11:14ИнфоПравкаОтветитьIP

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

Anatol_K
unregistered
написано 19 Августа 2005 11:39  ПравкаОтветитьIP

Как ни странно, но в данный момент я занимаюсь тем же самым

Павел Мощицкий
Member

Сообщений: 1024
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 19 Августа 2005 13:12ИнфоПравкаОтветитьIP

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

Anatol_K
unregistered
написано 19 Августа 2005 14:14  ПравкаОтветитьIP

1. Да внутри контроллера выполняются задачи, присущие задачам скады - это сервер тревог и первичная обработка параметров. Зачем два раза дублировать одно и тоже при формировании тревог, если можно все сделать в одном месте и зачем скаде заниматься первичной обработой параметров, если это стандартная операция и контроллер под QNX сделает ее значительно быстрее. Что здесь неразумного?
2. "под который пишется спецальное ПО
а нижние контроллеры имеют уже свою базу данных и свои скады". Здесь я допустил неточность. ПО на всех контроллерах, работающих под QNX - одинаковое. А база данных и скада в данном контексте имеют отношение к прилагаемым портативным ПК.
3. Если связь рвется, ну что ж это плохо, но в самом контроллере архив значений и тревоги тем не менее накапливается, не в таком масштабе конечно, как на архивном сервере. При восстановлении связи все это скидывается на архивный сервер.
4. "Хотя есть врианты и без панельного компьютера
Тогда что будете делать, если разорвется связь с верхним уровнем?" - ждать пока восстановится связь и при восстановлении перекачать внутренний архив контроллера и историю тревог. А пока связь потеряна, контроллер работает в автономном режиме по заданным алгоритмам.
5. "в виде архивных трендов, архива событий, архива сводок
Прекрасно. Оператору нужно за ТП следить, а тут технолог анализ истории смотрит." - замечание не в тему, поскольку у технолога свой ПК. А оператору нужны и тренды и события и сводки. Это зависит от конкретного объекта и организации где стоит САУ. Например при сдаче смены оператор обязан распечатать среднесуточный тренд давления и положить аккуратненько в специальную папочку.
Да и при разборе полетов, когда объект остановился, где посмотреть историю? Да наверное лучше это сделать тут же из АРМ оператора.
6. "Слабая мат. обработка. И АРМ-у присущи, не свойственные функции." - раскройте замысел этого замечания, поясните то бишь, насчет мат обработки и несвойственных функций.
7. "где хранятся архивы? Надеюсь, не на АРМ-е?". Правильно надеетесь, не на АРМе, а на специально отведенном архивном сервере, даже двух, один в горячем резерве. Но системы то разные бывают. Есть и такое, что на одном ПК запускается и АРМ и архивный сервер и NT контроллер. Почему бы нет, если система не очень громоздкая да и необходимости в дополнительных ПК нет.

Avsha
Junior Member

Сообщений: 25
Регистрация: Июль 2005

написано 19 Августа 2005 15:44ИнфоПравкаОтветитьIP

Такие системы, где реализуются расчеты (алгоритмы) мы называем – системами сбора и обработки данных.
Любая такая система может содержать следующие элементы:
1. Источники данных
2. Сервер данных
3. Вычислитель данных
4. Клиент данных
5. Администратор данных

6. Данные реального времени
7. Данные исторические
8. Модули расчетов (алгоритмов)
Может что забыл?
Каждый из элементов может представлять в жизни как физическое устройство, так и программный компонент, в любом случае на каждом элемент возлагаются определенные функции. Вот эти функции и необходимо реализовать для решения главной задачи – организации системы сбора и обработки данных. И не только функции, но и определить структуру системы, принять обозначения переменных, разработать типовые блоки расчетов (алгоритмов).

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

Интересно было узнать ваше мнение по решению данной задачи?
И можно ли рассматривать реализацию системы сбора и обработки данных на разных уровнях ПТК (контроллеры, SCADA и выше)?

Павел Мощицкий
Member

Сообщений: 1027
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 19 Августа 2005 16:31ИнфоПравкаОтветитьIP

Anatol_K
это сервер тревог и первичная обработка параметров
Первичную обработку обычно и делают на контроллере, а вот сервер тревог, что-то новенькое. Видимо связано с тем, что у Вас ПТК с базовой фиксированной конфигурацией аппаратуры по функционалу, как я понимаю. Если бы Вам пришлось каждый раз под разные заказы собирать сбороную солянку, об этом и не думали бы.
А база данных и скада в данном контексте имеют отношение к прилагаемым портативным ПК.
Вот теперь все понятно. Спасибо.
архив значений и тревоги тем не менее накапливается
Так вот сколько времени выдержит контроль 2-го уровня, пока верхний отрублен, если нет подключенной вспомогательной портативной ПК?
поскольку у технолога свой ПК
Вот этого я у Вас нигде и не нашел.
когда объект остановился
Да наверное лучше это сделать тут же из АРМ оператора.
Боюсь, что Вы работаете в тепличных условиях, если разбор полета происходит при остановленном объекте. Вот и ограничения на Ваше ПТК. Нет выделения отдельного сервисного ПО просмотра истории.
поясните то бишь, насчет мат обработки и несвойственных функций.
1. Для большей гибкости, даже если оператору нужно распечатать какие-то отчеты, делать это не из МРВ.
2. Мат. обработка - вторичная мат. обработка технологической информации для последующей визуализации и автоматического или ручного принятия решения о управляющих воздействиях на объект.
Есть и такое, что на одном ПК запускается и АРМ и архивный сервер и NT контроллер.
Ну наконец-то. Конечно может быть, если маленький объем точек ввода-вывода. Но по Вашим предыдущим постам возникает впечатление, что ПТК используется Вашими покупателями, в большей части, именно для таких случаев. Психологически выделяете их, как основные. Странно, ПТК, а для маленьких ТП.

Avsha
Такие системы, где реализуются расчеты (алгоритмы) мы называем – системами сбора и обработки данных.
Любая такая система может содержать следующие элементы:
1. Источники данных
2. Сервер данных
3. Вычислитель данных
4. Клиент данных
5. Администратор данных
6. Данные реального времени
7. Данные исторические
8. Модули расчетов (алгоритмов)
Может что забыл?

Спасибо. Даже слишком подобно объяснили вопрос о том, что такое мат. обработка. А уж из каких частей состоит, у каждого по своему.
мы как пользователи, желающие организовать расчеты на готовом программном продукте, а вы как разработчики программного продукта, который содержит в своем составе подсистему расчетов.
Нет. Просто у меня такое впечатление, что Anatol_K говорит больше теории, чем практики.

Anatol_K
unregistered
написано 19 Августа 2005 18:05  ПравкаОтветитьIP

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

Павел Мощицкий
Member

Сообщений: 1028
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 19 Августа 2005 19:02ИнфоПравкаОтветитьIP

Anatol_K
Эта утилита может быть запущена и на АРМ оператора в составе контроллера, который работает на этом же АРМе под ОС NT. И контроллер этот выполняет мат. обработку параметров для управления технологическими объектами.
Давайте предположим такую классическую ситуацию, что есть контроллер на 2-м уровне, который аккумулирует технологическую информацию с УСО и проводит первичную обработку данных. И есть АРМ оператора без контроллера, где проводится вторичная обработка. Где будет находится у Вас сервер тревог?
Приходит инженер, подключает свой ПК к сети, запускает АРМ оператора или архивный АРМ и качает себе на здоровье архивы.
Да, мы друг друга не понимаем. У Вас фирма-разработчик ПТК или Вы конечный пользователь? Я считаю, что при хорошем ТП хранить архивы на АРМ-е оператора не получится. Только на отдельном сервере history. Вы его называете архивным АРМ-ом, не важно, спор терминологий.
я уже говорил об обработке средних значений в скаде для формирования архивной информации, кроме того в скаде идет вторичная обработка для задач анимации
Извините, не увидел, значит не на этой странице.
Если вы назовете ЛПДС в составе одной подпорной, трех магистральных станций, резервуарного парка, системы пожаротушения и системы контроля энергоснабжения и кучи другой мелочи маленьким ТП, то что тогда немаленькое?
Замечательно. И сколько АРМ-ов оператора и архивных с контроллерами на одном ПК, с учетом, что все это автоматизировано?

Ваш ответ:

Коды форума
Смайлики


Ник:    Пароль       
Отключить смайлики
Страницы: 1 2 3 4 5

Все время MSK

Склеить | Разбить | Закрыть | Переместить | Удалить

Новая тема | Написать ответ
Последние сообщения         
Перейти к:

Свяжитесь с нами | skunksworks.net

Copyright © skunksworks.net, 2000-2018

Разработка и техническая поддержка: skunksworks.net


Рейтинг@Mail.ru Яндекс.Метрика