Добавлено: Пт 21 Апр, 2006 11:18:52 Заголовок сообщения: Поговорим о принципах создания проектов ControlLogix?
Здравствуйте, коллеги! Здравствуйте, Игорь Аркадьевич!
У нас возник принципиальный спор о программных способах реализации поставленных перед нами задач на базе RSLogix5000.
Есть непрерывный технологический процесс, несколько десятков управляемых электрозадвижек.
Нам предлагают поместить всё (сбор информации, управление, обслуживание SCADA) в циклическую задачу, обосновывая это тем, что:
1. не будет риска повторного запуска задачи до того, как она завершится.
2. обслуживание основных технологических задач должно осуществляться в фоновом режиме.
3. объем заложенной логики выполняется (в отсутствие других задач) достаточно быстро
Выскажите, пожалуйста свое мнение, поделитесь личным опытом построения систем, т.к. мне кажется, что фоновая задача - она и есть фоновая, её приносят в жертву всему остальному. Как бы нам не поиметь проблем с учетом дальнейшего развития системы (появлении периодических задач, которые будут прерывать фоновую, и т.д.). Да и иметь такой функционал, как у RSLogix5000, и не использовать его как то неправильно.
На сколько я знаю такой подход может плохо отразиться на трафике ControlNet, т.е. в SCADA возможны тормоза - правильно ли я думаю?
Начну с конца - с траффика ControlNet. С его точки зрения совершенно безразлично, сколько и каких задач будет "крутиться" в процессоре. Что ему небезразлично - так это сколько рабочих станций будут одновременно запрашивать одни и те же тэги. Самой распространённой ошибкой является решение задачи "в лоб" простым распараллеливанием рабочих станций, что есть неправильно и неминуемо ведёт к проблемам с производительностью системы. Но это - другая тема.
Слава, простите, но обоснования, которые Вам приводят в качестве аргументов, я вряд ли могу назвать состоятельными.
Цитата:
1. не будет риска повторного запуска задачи до того, как она завершится.
Такого риск в мультизадачных системах реального времени исключен по определению. Чкловек, утверждающий, что такой риск есть, попросту не вполне разбирается в предмете. Пусть он Вам объяснит, что он слышал об очередях задач и о реентерабельности исполняемого кода .
Цитата:
2. обслуживание основных технологических задач должно осуществляться в фоновом режиме.
Почему вдруг именно "должно", а не "могло бы"? Совершенно это, знаете ли, неочевидно и нелогично. Если уж основные функции системы должны выполняться в фоновом режиме, то какие же тогда функции должны выполняться на переднем плане?!
Смотрите: основная задача системы - это наиболее динамичная своевременная реакция на события во внешней среде. Поэтому-то мы и называем такие системы системами реального времени, что в них мы имеем возможность реагировать на события не тогда, когда сможем, а тогда, когда надо, совершенно точно зная, когда именно событие будет обслужено и точно планируя приоритетность процессов обслуживания.
Основные принципы таковы:
- если во внешней по отношению к системе среде происходят события различной степени важности и с различной критичностью ко времени обслуживания, то каждому такому событию (или классу событий) должна быть поставлена в соответствие задача, обслуживающая данное событие / класс событий. для этого в контроллере существует многозадачность.
- если события во внешней среде обладают различным приоритетом, то и задачи, обслуживающие данное событие, также должны иметь не одинаковый, а различный приоритетю. Так, формирование массива данных индикации, скажем, имеет более низкий приоритет, чем ПИД-регулирование, а оно - более низкий приоритет, чем обслуживание аварийных блокировок. Не так ли? Для этого в е контроллере ControlLogix и существует 15 уровней приоритета.
- если во внешней среде возникает ссобытие, которое должно быть обслужено немедленно, не дожидаясь, когда до обслуживающего его кода дойдёт "лестница" строчек (а кто сказал, кстати, что это время ожидания обслуживания в однозадачной систем всегда будет одно и то же?), то многозадачная система гарантирует возможность немедленного обслуживания такого события.
- я уж не говорю о том, что многозадачную систему легче писать, олаживать и сопровождать, т.к. куда легче иметь дело с относительно короткими обозримыми кусками кода, чем с одной очень длинной процедурой. Планирование вычислительного процесса тоже получается легче, проще и прияьнее.
- знаете, есть такое утверждение: любую логическую схему можно построить с помощью элементов 2И-НЕ. Действаительно, можно. Но зачем? Зачем строить триггер, а потом из них строить счётчики и сдвиговые регистры, когда естьготовые микросхемы?
Так и тут - зачем думать о последовательности выполнения задач, писать какие-то диспетчеры заданий или задач, вызывая их "руками" в нужный момент из одной в другую, когда такие вещи уже созданы в операционной системе?
А как Вы поступите с задачами, имеющими различную важность, например, с аварийными блокировками и расчётами расхода с коррекцией по температуре и давлению - что, все в очередь?
Ещё одно: как Вы добьётесь хорошего качества ПИД-Регулирования, если расчёт управляющего воздействия будет выполняться нерегулярно, а в зависимости от текущего времени скана, которое варьируется в некоторых пределах, а если задача одна и большая - то и в довольно широких преедлах может? Не проще ли посадить ПИД-инструкции в отдельную задачу, запускаемую в строго отмеренные интервалы времени?
Цитата:
3. объем заложенной логики выполняется (в отсутствие других задач) достаточно быстро
Я вижу здесь противоречие. Простая арифметика показывает, что если задача будет одна, то её время скана будет в несколько раз больше, чем у одной из более коротких задач. А в многозадачной систем время выполнения каждой из задач значительно меньше, чем если их все "слепить" воедино.
Если же речь идёт о "накладных расходах", связанных с диспетчеризацией задач, то они:
- перенебрежимо малы
- аппаратно выполняются всё равно быстрее, чем реализованный программно некий самодельный диспетчер.
Цитата:
фоновая задача - она и есть фоновая, её приносят в жертву всему остальному.
Слава, Вы абсолютно правы. Она именно поэтому так и называется.
Многозадачности бы не было придумано и реализовано, если бы она не была нужна. ControlLogix - это на сегодняшний день самое совершенное творение контроллеростроения, результат многолетнего опыта разработки и эксплуатации, квинтэссенция знаний и передовых технологий. И если мировой лидер в этой отрасли ушёл от однозадачности и реализовал в контроллере многозадачную среду реального времени с детерминизмом и распараллеливанием потоков, то это о чём-то всё-таки говорит.
Цитата:
Как бы нам не поиметь проблем с учетом дальнейшего развития системы
Я думаю, что есть соединить все функции системы в одну задачу, то как раз тогда Вы проблемы и можете поиметь.
Простой вопрос: какую систему проще сопровождать: состоящую из одной необозримо длинной задачи или из разумного количества более коротких задач, имеющих вполне определённые функции?
В какую из этих систем проще в процессе добавлять функции - в качестве заплаток в одну длинную задачу там и сям, долго и нудно вылавливая нестыковки и перекрёстные ссылки, или добавить одну в достаточной степени автономную задачу?
Проще, надёжнее и приятнее - в многозадачную. _________________ Обращайтесь к профессионалам.
Что ему небезразлично - так это сколько рабочих станций будут одновременно запрашивать одни и те же тэги. Самой распространённой ошибкой является решение задачи "в лоб" простым распараллеливанием рабочих станций, что есть неправильно и неминуемо ведёт к проблемам с производительностью системы. Но это - другая тема.
В связи с указанной ремаркой, прошу вас разъяснить, как правильно решается задача визуализации одних и тех же процессов на нескольких автоматизированных рабочих местах, допустим территориально распределенных на объекте управления? Существуют рекомендации по этому поводу?
Мы в своей практике придерживаемся стратегии унификации проектов визуализации в рамках одного объекта управления. Разница между рабочими местами в их функциональном назначении, что в конечном счете приводит к тому, что персонал, для которого эти АРМы разрабатываются, смотрит разные картинки одного и того же проекта. В данном случае, я так понимаю, данные у контроллеров запрашиваются разные.
Но в каждом из проектов обязательно присутствуют различные Log-процессы: DataLogging, AlarmLogging, EventLogging. Регистрация данных дублируется, так как проекты одинаковы. Значит и запрос идет одних и тех же данных из PLC. Единственно, чем отличаются станции, так это настройкой OPC Node в RSLinx (об этом где-то было сказано, что желательно не использовать одинаковые значения параметра Polled Messages msec). На самом деле, честно могу сказать, что глубокого понимания и осознания этих изменений у меня нет (все на уровне "якобы должно быть лучше")
Если у вас есть реальные рекомендации по настройке обмена данными с системами визуализации, просьба их озвучить. Просто странно не использовать одинаковые проекты RSView, например, в одной системе: это проще и обслуживать, и разрабатывать, и исправлять во время наладки, и контролировать версии и т.д.
Просто странно не использовать одинаковые проекты RSView, например, в одной системе: это проще и обслуживать, и разрабатывать, и исправлять во время наладки, и контролировать версии и т.д.
Видите ли, нужно использовать не просто одинаковые проекты RSView, а один и тот же проект RSView, причём не несколько параллельно работающих копий его, а именно один-единственный Правда, не RSView32, а RSViewSE, который именно для этого и предназначен.
Видите ли, с тех пор, как стали применяться контроллеры ControlLogix (и lдругие из серии Logix) с мультизадачной операционной системой и динамическим распределением памяти, принципы организации связи систем HMI с контроллерами изменились.
Дело обстоит так, что если просто механически увеличивать количество одновременно работающих на шине проектов HMI, и при этом пренебречь этими соображениями, то производительность системы может пострадать. Проблемой является то, что при проектировании систем с контроллерами серии Logix люди исходят из тех же соображений и принципов посторения систем, которые применялись раньше, с более простыми старыми контроллерами без мультизадачности и динамического распределения памяти, какими были SLC и PLC-5, и всё ещё выпускаются другими производителями. Кроме того, старые сети с низкой скоростью обмена, работащие по принципу "master-slave" и не имеющие CIP и предсказуемого времени доставки, работали по совершенно другим принципам, не обеспечивающим детерминизма в реальном времени. При этом использовался совершенно другой механизм обслуживания рабочих станций.
RSView32 - это достаточно старый продукт, он был создан в эпоху, когда ещё не было ни тэгов в контроллерах, ни динамического распределения памяти, ни самого ControlLogix, ни встроенной мультизадачности, ни прозрачных благодаря CIP детерминированных сетей. RSView32 широко применяется и сейчас для тех случаев, когда нужен all-in-one stand alone продукт, когда количество компьютеров не превышает 2 или применяются старые контроллеры не-Logix.
Но для вновь проектируемых на базе контроллеров Logix систем рекомендуется всё-таки применять не RSView32, а RSViewSE, т.к. даже если в системе предусматривается только один компьютер с HMI, продукт RSViewSE Stand Alone обеспечивает более оптимизированный обмен с контроллерами.
RSViewSE оптимизирована для мультиклиентского применения и строится на (несколько) иных принципах, которые нужно знать и учитывать при проектировании системы. Поэтому при построении системы с нескольими (3 и более) компьютерами, которые собирают данные по OPC, нужно учитывать вполне определённые вещи, от которыъ непосредственно зависит производительность системы.
В соответствии с веянием времени повысились требования к скоростям передачи информации, к реактивности системы, к детерминизму сетей, что непосредственным образом повлияло на идеологию построения рапределённых систем управления. Принципы построения таких систем отличаются от принципов построения систем с "простыми" контроллерами и сетями", их просто нужно знать.
Коротко: если в Вашей системе не 1 и не 2 компьютера, на которых должны работать проекты HMI, обращающиеся к одному и тому же контроллеру ControlLogix, то:
1. Если Ваша система построена на современных кнотроллерах серии Logix, а количество компьютеров, на которых должны работать средства HMI_ больше двух, то применяйте RSViewSE с выделенными (резервированными) серверами вместо RSView32, которая применялась с SLC или PLC-5.
2. Ставьте один или два сервера (если нужнол резервирование) и столько "тонких" клиентов, сколько нужно. Их колмчество неограничено.
3. Пользуйтесь RSLinx Enterprise, встроенным в RSViewSE вместо RSLinx Сlassic, использующегося с RSView32. Он специально предназначен для работы в конфигурациях с контроллерами Logix и мультиклиент-мультисерверной платформой HMI.
4. Если не хотите или не можете использовать RSViewSE, а компьютеров с HMI должно одновременно работать более. чем 2, то применяйте хотя бы RSLinx Gateway на одном (или двух компьютерах, если нужен резерв), а остальные компьютеры "вешайте" на Ethernet у тому. на котором работает RSLinx Gateway.
5. Не пренебрегайте рекомендациями по планированию производительности системы HMI, описанными в документации. И тогда у Вас получатся красивые, надёжные, "прозрачные" и очень быстродействующие системы
Вот здесь здесь я уже привёл несколько важных документов. _________________ Обращайтесь к профессионалам.
Большое спасибо за быстрый и полный ответ!
У каждого прграммиста есть свой опыт и стиль; главное, чтобы он не стал препятствием при осознании новых технологий. Будем искать понимание...
Цитата:
Пусть он Вам объяснит, что он слышал об очередях задач и о реентерабельности исполняемого кода
Если можно, дайте ссылки на документы, в которых можно об этом почитать.
Спасибо!
Слава, проблемав в том, что вся информация довольно сильно "рассыпана" по интернету.
По реентерабельности копирую Вам из "Википедии":
Цитата:
Реентерабельность
Компьютерная программа в целом или её отдельная процедура называется реентера́бельной, если она разработана таким образом, что одна и та же копия инструкций программы в памяти может быть совместно использована несколькими пользователями или процессами. При этом второй пользователь может вызвать реентерабельный код до того, как с ним завершит работу первый пользователь и это как минимум не должно привести к ошибке, а лучшем случае не должно вызвать потери вычислений (то есть не должно появиться необходимости выполнять уже выполненные фрагменты кода).
Реентерабельность тесно связана с безопасностью функции в многопоточной среде (thread-safety), тем не менее, это разные понятия. Обеспечение реентерабельности является ключевым моментом при программировании многозадачных систем, в частности, операционных систем.
Для обеспечения реентерабельности необходимо выполнение нескольких условий:
* Никакая часть вызываемого кода не должна модифицироваться.
* Вызываемая процедура не должна сохранять информацию между вызовами.
* Если процедура изменяет какие-либо данные, то они должны быть уникальными для каждого пользователя.
* Процедура не должна возвращать указатели на объекты, общие для разных пользователей.
В общем случае, для обеспечения реентерабельности необходимо, чтобы вызывающий процесс или функция каждый раз передавал вызываемому процессу все необходимые данные. Таким образом, функция, которая зависит только от своих параметров, не использует глобальные и статические переменные и вызывает только реентерабельные функции, будет реентерабельной. Если функция использует глобальные или статические переменные, необходимо обеспечить, чтобы каждый пользователь хранил свою локальную копию этих переменных.
Что же касается очереди задач, то я ссылки так навскидку не нашёл. Вкратце поведение ядра операционной системы выглядит следующим образом:
Ядро операционной системы реального времени, располагающее определёнными ресурсами (процессором, памятью, коммуникациями и т.п.) "ведёт" очередь задач, претендующих на ресурс, устанавливая их в очередь к каждому ресурсу в соответствии с определёнными критериями (например, с их приоритетом).
В каждый момент времени ресурс принадлежит тому процессу, который имеет самый высокий приоритет и готов к исполнению. Процесс (задача) готов к исполнению, если выполняется условие его запуска.
Предполжим, что задача "А" запускается по внешнему событию (по дискретному сигналу на входе модуля 1756-IB16. Задача "Б" запускается периодически каждые 100мс и имеет приоритет бОльший, чем задача "А". Предположим, что в данный момент нет более приоритетных задач, претендующих на процессор.
В системе есть ещё фоновая задача, выполняющаяся циклически всё время, пока не выполняются другие более приоритетные задачи.
Теперь смотрите:
1. Ядро операционной системы периодически просматривает списки задач на предмет определения самой приоритетной готовой к выполнению задачи.
2. В данный момент времени есть две более приоритетные, чем фоновая, задачи, но ни одна из них не готова, т.к. обе ждут выполнения событий (сигнала на входе контроллера и истечения интервала времени запуска). Выполняется фоновая задача. Обе приоритетные задачи стоят в очереди к процессору.
3. Приходит сигнал с клеммы входного модуля. Одна из задач. ожидающая этого события, становится готовой.
4. Ядро, просматривая списки, обнаружит, что есть одна задача, имеющая более высокий, чем фоновая, приоритет и что условие её запуска соблюдается. Ядро отберёт процессор у фоновой задачи, сохранит её контекст в стеке этой задачи и передаст управление готовой к выполнению задаче.
5. Задача, ожидающая истечения интервала времени, остаётся в очереди к процессору.
6. Во время исполнения задачи "А" поступает ещё один входной сигнал, являющийся условием запуска той же задачи "А". Ядро ставит копию кода задачи "А" в очередь к процессору, т.к. в настоящий момент одна копия кода "А" уже исполняется, а приоритет у них одинаковый (см. реентерабельность). Копия кода "А" будет исполняться сразу же после выполнения первого "экземпляра" кода "А".
7. Выполняется первый экземпляр кода "А", в очереди к процессору стоит его копия, задача "Б" стоит в списке задач, ожидающих условия выполнения. В этом списке может быть ещё несколько задач, они все стоят в очереди в соответствии с их приоритетом. Предположим, что из всех оствавльных задач "Б" имеет наивысший приоритет и поэтому стоит в очереди первой.
8. Код первого экземпляра "А" ещё не выполнился, а системный таймер уже сказал задаче "Б", что ей пора. Ядро сразу же перемещает её из очереди ожидающих условия выполнения задач в очередь на исполнение к процессору. Поскольку её приоритет больше, чем у уже стоящей в очереди копии кода "А", задача "Б" помещается в очередь к процессору первой, т.е. перед ней.
9. Первый экземпляр кода "А" отработал. Ядро отдаёт процессор первой стоящей в очереди к процессроу задаче - задаче "Б". Она отрабатывается, а затем процессор отдаётся копии задачи "А".
10. Если после окончания исполнения копии "А" интервал задачи "Б" ещё не истёк, а входных сигналов не поступило, в очереди к процессору больше нет готовых к исполнению задач, более приоритетных, чем фоновая. Поэтому ядро достаёт из стека фоновой задачи содержимое регистров в момент отключения, восстанавливает контекст задачи, предшествующий её переходу в пассивное состояние и отдаёт процессор фоновой задаче. Она продолжает работу, как ни в чём ни бывало, даже не замечая, что "потеряла сознание" на какой-то момент времени.
Выводы:
1. Ни одно событие не теряется, а только откладывается на пренебрежимо малое время до того момента, когда подойдёт его очередь обрабатываться процессором.
2. Более важные события обрабатываются сразу же, не ожидая, когда логика фоновой задачи "доползёт" до их обработки.
3. Даже если предположить, что несколько событий во внешнем мире происходит одновременно с точностью до микросекунды (практически невозможно), то они будут обслуживаться одно за другим в порядке "живой очереди".
4. Если во время обслуживания события наступит более важное событие, то процессор бросит всё и обслужит его, а потом вернётся и дообслуживает менее важное событие.
Вот так, вкратце. Это и называется мультизадачная среда реального времени. Т.е. реально реального времени
Если интересно, задавайте вопросы дальше.
_________________ Обращайтесь к профессионалам.
А есть где-нибудь подробное описание этой самой "реально ОС реального времени" Logix-процессора? Так, для общего развития, например: структура ядра ОС, системные процессы, методы межпроцессного взаимодействия, способы синхронизации и диспетчеризации процессов и т.д., чтобы понять, как система отрабатывает возлагаемые на нее задачи.
Большое спасибо! Четко и понятно - приятно работать
Тогда следующий вопрос:
Цитата:
4. Если не хотите или не можете использовать RSViewSE, а компьютеров с HMI должно одновременно работать более. чем 2, то применяйте хотя бы RSLinx Gateway на одном (или двух компьютерах, если нужен резерв), а остальные компьютеры "вешайте" на Ethernet у тому. на котором работает RSLinx Gateway.
Допустим, что две станции ST1 и ST2 подключены к ControlNet, на них установлен RSLinxGateway (одна из станций ST2 - резервный RSLinx Remote OPC Server). На третьей станции ST3 конфигурируем узел, который ссылается на первую станцию ST1 - например OPC_ST1, формируем базу данных тэгов, в имени которых фигурирует название узла OPC_ST1.
Переход на резервный RSLinx Remote OPC Server вижу таким образом:
на станции ST3 конфигурирую узел, который ссылается на станцию ST2 - например OPC_ST2. В базе данных тэгов данного проекта имя этого узла не встречается.
В случае выхода из строя станции ST1, на станции ST3 переименовываю узел OPC_ST1 в OPC_ST1res, а OPC_ST2 в OPC_ST1 соответственно. Т.о. базу данных тэгов перелопачивать не надо - ограничиваемся только переименованием узла.
Является ли правильным данный подход, или это можно делать как-то автоматически, или можно системными средствами переименовывать узлы, а не вручную?
Заранее спасибо!
А есть где-нибудь подробное описание этой самой "реально ОС реального времени" Logix-процессора? Так, для общего развития, например: структура ядра ОС, системные процессы, методы межпроцессного взаимодействия, способы синхронизации и диспетчеризации процессов и т.д., чтобы понять, как система отрабатывает возлагаемые на нее задачи.
Заранее благодарен,
Vitaliy D. Burtsev
Уважаемый Виталий,
К сожалению, я такого документа Rockwell не знаю. Но основные принципы построения операционных систем реального времени можно найти в литературе по системам реального времени. _________________ Обращайтесь к профессионалам.
Последний раз редактировалось: oldDad (Ср 26 Апр, 2006 7:00:43), всего редактировалось 2 раз(а)
Является ли правильным данный подход, или это можно делать как-то автоматически, или можно системными средствами переименовывать узлы, а не вручную?
Заранее спасибо!
Да, в принципе, это правильно. Вообще, это можно сделать средствами VBA в RSView32.
И снова спасибо! Раньше (до этого форума) мы тратили довольно много времени на решение возникающих проблем. Вслепую, часто интуитивно - а теперь кроме того, что даются векторы, так еще и готовые решения. Похоже на работу ученых до и после появления вычислительных средств - просто не убиваем время на "ручные расчеты", а занимаемся "чистой наукой"
К сожалению, я такого документа Rockwell не знаю. Но основные принципы построения операционных систем реального времени можно найти в литературе по системам реального времени.
Очень жаль, однако.
А что касается принципов, описанных в литературе - это понятно.
Интересен сам подход от Rockwell. Интерес академический, основанный на некоторых знаниях о теории систем реального времени. Я не думаю, что разработчики взяли какой-либо учебник по ОСРВ и переняли принципы.
Я не думаю, что разработчики взяли какой-либо учебник по ОСРВ и переняли принципы.
Ну... хм... Я думаю, что разработчики когда-то учились в высшей школе, где им преподавали курс ОС РВ Так что, они в известной степени из учебника почерпнули свои знания _________________ Обращайтесь к профессионалам.
Ну... хм... Я думаю, что разработчики когда-то учились в высшей школе, где им преподавали курс ОС РВ Так что, они в известной степени из учебника почерпнули свои знания
В этом, наверное, и причина отсутствия документа на ОС. Будет ссылка на один единственный учебник, который изучен в высшей школе!
Является ли правильным данный подход, или это можно делать как-то автоматически, или можно системными средствами переименовывать узлы, а не вручную?
Заранее спасибо!
>Да, в принципе, это правильно. Вообще, это можно сделать >средствами VBA в RSView32.
Есть еще вариант: Сделать в RSLinx алиас на 2 топика, которые настроены на 2 машины с GW.
Чего-то я там только с битом управления переключением мудрил - уже не помню =(
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна. Открытие страницы: 0.135 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
как то неправильно.
.
