|
Схема графического программирования для АСУ ТП построенная на принципах схемной эмуляции. / Тематика: Информатика / / Автор: Ковалев Се
Чем вызвана такая немилость?
Дело в том, что давнейшей мечтой проектировщиков АСУ ТП была мысль про единую спецификацию проекта в цепочке «заказчик – технолог - программист». Ее решение позволяло бы представителям разных профессиональных групп – заказчику, технологу и программисту – однозначно понимать друг друга.
Как же обстоят дела сейчас?
Результатом совместной работы заказчика с технологом – есть некий алгоритм, представленный в виде графического рисунка или словесного описания – что выступает основой документа, называемого техническим заданием, которое заверяется печатями организаций. Программисту необходимо проработать неформальную операцию перевода этого документа на язык машинных кодов – программного продукта предоставляемого заказчику. Вот здесь и начинаются все беды. В большинстве случаев переход от алгоритмизации до программирования представляет определенную проблему. Программисту приходится додумывать, как представить ее вычислителю на понятном для него языке – языке программных кодов. Таким образом получается, что программа отображает то, как программист смог понять исходный алгоритм. В конечном итоге образуются два алгоритма: один на бумаге, для отчетности и документирования проектных решений, а другой – в листинге программы.
Часто происходит так, что граф алгоритма, разработаный программистом , не сходится с графом исходного алгоритма. Другими словами, графы оказываются неизоморфными. К чему это может привести? – к тому, что «местами» программа, разработанная программистом, может работать не так, как это было задумано технологом. В чем это выражается? – в затеряных космических кораблях ( радиоантена которого ошибочно была наведена не в ту сторону), высаженных в воздух цехов заводов и фабрик и т.д. и т.п.
С другой стороны, программирование, несмотря на свою массовость, остается искусством. Поэтому каждый программист программирует так, как умеет. На сегодняшний день все попытки полностью формализовать или автоматизировать процесс написания программ оказались неудачными. Поэтому степень затрат времени и средств, выделяемых на проект, напрямую зависят от способностей и амбиций программиста.
К тому же, Он оказывается единым держателем найважнейшей логической информации и человеком, способным разобраться в своем творении и от которого, в конечном счете, зависит судьба всего проекта. Нечего и говорить про случай, когда человек может просто уволиться в разгар проекта.
Кроме пресловутого "человеческого фактора" существует другой, не менее грозный, - это лавинообразный рост программного кода в программных продуктах, связанный с ростом функциональной сложности алгоритмов управления. Поэтому все более усилий нужно от разработчика на написание и налаживание кода, оставляя меньше сил и времени на проработку самого задания и оптимизацию. Сам же процесс исправления ошибок все более напоминает латание дыр.
Согласно данным отчета Национального института по стандартам и технологии, объем экономических потерь от ошибочного ПО только в США достигает нескольких миллиардов долларов в год, что составляет около 1% национального валового внутреннего продукта. (Research Triangle Institute, NIST Planning Report 02-3, May 2002).
Современные SCADA системы – все ли так хорошо?
В наше время среди IT-специалистов широко распространена мысль, что появление всякого рода SCADA и SOFTOGIC систем позволяет решать вышеуказанные проблемы.
В действительности все далеко не так.
Хотя каждая такая система может и не затребовать глубоких знаний аппаратного обеспечения контролеров, одинаково - это достаточно сложные системы, которые требуют достаточно больших усилий и времени на освоение. Это тома документации, и опять же языки программирования, пусть и другого толку, например - последовательных функциональных схем, релейной логики, функциональных блочных диаграмм. Да и от универсальных языков (BASIC, C, Pascal) еще никто не отказывался. Более того, любой уважающий cебя программист, при разработке серьезной АСУ ТП отдаст преимущество именно универсальным языкам, поскольку графическое проектирование пока еще остается больше игрушкой и красивой рекламной упаковкой существующим системам проектирования.
Таким образом, еще рано говорить, что за такие системы уже можно посадить непосредственно технолога. А значит еще рано говорить, что современные средства графического программирования уже позволяют разрабатывать единственную (сквозную) проектную документацию для цепочки: "заказчик - технолог - программист".
Не лишним также будет вспомнить, что успешное внедрение таких систем практически невозможно без предворительной закупки у фирм-поставщиков исследовательских полигонов, интеграция которых намечается на объекте. В противном случае есть риск получить нерабочую систему или, как минимум, неоптимизированую.
К функциональной сложности стоит прибавить еще и проблему ресурсов. Ведь для большинства известных систем нужные ресурсы ПК, что в условиях промышленности автоматически допускает использование дорогих промышленных компьютеров, а не более дешевых микропроцессорных контролеров.
Не следует забывать также о проблеме мультипроцессорной обработки, когда всю "графику" придется откладывать в сторону и вручную приступать к проектированию интерфейсов межпроцесорного обмена. А, побродив по Всемирной Сети, мы обнаружим многочисленные материалы, которые свидетельствуют о том, что проблема эта в целом еще далекая от окончательного решения даже на теоретическом уровне.
К тому же, чтобы полнее увидеть преимущества системы графического программирования, построенной на принципах схемной эмуляции, в сравнении с огромным числом уже известных на сегодня систем, необходимо разобраться - а в чем же заключается идеология работы последних?
А для этого, в первую очередь, нужно четко осознать, что любая известная Система Графического Программирования строится на трех китах: графическом редакторе (редакторе рисования схем), графическом компиляторе и системы выполнения.
Что касается редакторов рисования, то здесь проблем вроде бы нет: даже спроектировать такую "штуку" по силам практически любому программирующему студенту (правда, который учится, а не стоит в очереди за дипломом).
А вот графические компиляторы – вещи намного серьезне.
В "обязанности" этой компоненты входит пересмотр графического рисунка проекта и генерация исходного кода программы, что иначе программисту пришлось набирать бы "ручками". Потом исходный код компилируется в некоторый промежуточный код. Вся эта работа выполняется программистом на рабочей станции (ПК). После этого файл промежуточного кода уже можно загружать в встраеваемый контроллер. Туда же загружается и специальный интерпретатор промежуточного кода – система выполнения.
Для чего нужен промежуточный код? Лишь для того, чтобы максимально упростить интерпретатор (систему выполнения). Делается это с единственной целью - иметь возможность "всунуть" ее в какую-либо микропроцессорную платформу.
В свете сказанного становится понятным, что принципиальной разницы между SCADA системами и обычными системами визуального программирования, такими как DELPHI, Visual C, Visual Basic (и др.) нет. Потому как в обоих случаях исходные тексты программ генерируются по визуальным компонентам, которые были использованы в проекте.
Классическим примером сказанному может быть всенародно известная программа ISAGRAF (от ICS Triplex ISAGRAF Inc.). Здесь при компиляции файла графического проекта генерируется промежуточный, так называемый Tic-код, который потом загружается во встраиваемый контроллер. Туда же догружается т.н. Tic-интерпретатор, который и выполняет функцию системы выполнения.
В не менее народной программе LABVIEW (от National Instruments) згенерованые исходные тексты кодируются в так называемый промежуточный G-код, а после интерпретируется (выполняется) непосредственно на ПК со среды LABVIEW.
Можно обнаружить четкую аналогию, что Tic-интерпретатор для Tic-кода, это то же, что среда LABVIEW для G-кода. Разница заключается только в том, что LABVIEW во встроенный контролер не вместишь, а Tic-интерпретатор - можно!
Справедливости ради, следует отметить, что такого "фокуса" вероятно с легкостью могли бы достичь и разработчики LABVIEW, достаточно им только реализовать возможность выгрузки в управляющую систему (контролер) G-интерпретатор, кторый пока "намертво" встроенный в саму среду. И мне приходилось даже слышать, что в последних версиях программы эта функция даже уже реализована.
На таких же принципах построена широко известная SCADA Delta V.
Параллельно выше рассмотренной идеологии существует немного отличная, это заключается в том, что еще на этапе работы графического компилятора генерируется не промежуточный код, а исполнительный сразу, который и загружается в промышленный компьютер. Правда говорить, в этом случае, о системе выполнения не придется, поскольку в этом случае она подменивается т.н. средой исполнения –«железо»+операционная система, для чего, конечно нужны уже ресусы ПК.
Такая идеология, как правило, также предлагается известными системами графического программирования. В LABVIEW для этого есть дополнение Application Builder for LABVIEW, что позволяет сгенерировать оптимизированый код, подобный программному коду C-компилятора. Такой код еще принято называть - RUN-TIME модулем. Система ISAGRAF также позволяет проводить генерацию обычного C-исходящего кода, откомпилировав который обычным C-компилятором мы получаем "классический" RUN-TIME модуль.
Идея RUN-TIME модулей нашла применение и в других системах класса HMI и SCADA, например в Lookout for Windows (той же фирмы). А также широко известной Ultralogic (Ultralogic), в которой файл, располагается в совмещеных с ПК контролерах типа ADAM.
Аналогично, какую бы другую систему мы дальше не рассматривали - мы увидим все то же.
Не является исключением и программирование языком лестничных диаграмм (LD) для всех известных линеек ПЛК - MODICON, Siemens, Allen-bradley и др. А все по одной простой причине: ни интерпретацию, ни компиляцию, в программировании пока еще никто не отменял.
Вот почему идеология всех современных SCADA – SOFTLOGIC систем основана на стремлении их разработчиков от графики перейти к обычным программным кодам, чем автоматически вызывается к жизни весь тот геморрой, которым страдает программирование как идеология. Однако, невзирая на то, что тема эта уже из области проблем, свойственным самим компиляторам/ интерпретаторам - в следующих параграфах придется ее коснуться в минимально-необходимом объеме.
Справедливости ради отмечу, что в дополнении к двум выше рассмотренным идеологиям, разроботчики системы MASTERSCADA (фирма ИНСАТ, г. Москва) некоторое время назад предложили третий "оригинальный" путь: на микропроцессорной платформе, расположили не символьный интерпретатор промежуточного кода (как во всех), а непосредственно графический интерпретатор... и даже заявили мне, что это и есть та же эмуляция, идею которой я так рьяно буду популяризировать уже который год подряд.
На это могу ответить, что человеку, который внимательно прочитал все выше написаное мной, вероятно, не трудно будет понять, что все эти комбинации с компилюющими/интерпретирующими компонентами скорее напоминают сование кроватями в публичном доме. Но еще лет тридцать тому назад мой дед разъяснил мне, что если в публичном доме падают доходы - то не кровати нужно двигать, а менять руководство. Идея схемной эмуляции именно и является тем новым руководителем для встраиваемых микропроцессорных платформ!
В то же время, присутствие языков программирования, а также компиляторов/интерпретаторов в известных системах графического программирования делает такие системы достаточно сложными и дорогими продуктами. Ну как, например, LABVIEW prof можно считать "настольной" системой инженера, если в Москве за нее "просили" 4900$ (2005 год), а в Киеве - 7000$ (правда еще три года тому назад это было аж 10000$, так что прогресс обычно наблюдается!).
Что уж говорить про системы уровня Delta V?
Ясно, что все они расчитаны на автоматизацию заводов и фабрик , но никак не на уровень малых внедряющих фирм и тем более уровень частного предпринимателя. О стоимости «железа» к таким системам я вообще молчу. Можно только представить сколько сотен миллиардов долларов «крутится» во всем мире в сфере внедрения АСУ ТП. Это, конечно же, не может не нравиться самим внедряющим фирмам. А куда деваться заказчикам? Да никуда! Ну, что то ненамного дороже, что то – дешевле, но в целом альтернативы нет!
Работая однажды на одной малой фирме, специализирующейся на автоматизации производственных процессов мне «посчастливилось» наблюдать попытку автоматизации линии по производству макарон на ADAM-ах. Подсчитали, прослезились...и внедрили «самопальные» контролеры на основе микропроцессоров MSC-51. Получилось дешево и сердито.
Система графического программирования, в основу которой заложен принцип схемной эмуляции, именно и дает уникальный шанс отказаться от исходных кодов, а соответсвенно и от компиляции/интерпретации.
Принцип схемной емуляции лежит только в основе системы исполнения нового типа (скажем так). Это позволяет достигнуть сразу двух важных моментов:
первый – таким компонентам, как «графическому компилятору» и интерпретатору в новой идеологии места нет! Это в свою очередь приводит к разительному упрощению всей системы в функциональном плане, а значит и ценовому. Такой системе не нужны мощности ПК. Она проста в освоении даже для «чайников» ( которыми являются, к примеру те же технологи);
второй – добиться характеристик, принципиально недоступных для всех известных систем графического программирования;
Все что написано ниже – служит целью разьяснить эти два момента.
Что такое схемная эмуляция?
Итак, в основе новой идеологии лежит авторская «программа Схемной Эмуляции». Что надо понимать под этим словосочетанием? Ведь любой электронщик возразит, что нет в природе программ такого класа, и он будет абсолютно прав.
Известны так называемые программы-симуляторы, такие как Micro-CAP от «Spectrum SoftWare», PSpice от «MicroSim Corp.» и т.п. Те, которые в советскую эпоху у нас принято было называть програмами моделирования электронных устройств.
Сразу уточню, программы схемной емуляции традиционно деляться на две группы: моделирование аналоговых устройств и моделирование дискретных, проще говоря, цифровых приборов. Математический аппарат моделирования аналоговых устройств, на мой взгляд, вряд ли косается задач, относящихся к предмету этой статьи, поэтому в дальнейшем рассматриваться мною не будет. Если чей нибудь пытливый ум высмотрит пользу в данном класе программных подуктов – ну что же, с интересом почитаю и Ваши соображения.
А пока я буду апелировать к системам моделирования дискретных приборов. Алгоритмы, используемые в основе программ моделирования таких приборов – самостоятельная и довольно интересная тема. Об этом написано бльшое количество книг (учебных пособий) и если кто нибудь в свое время это пропустил, есть смысл все-таки обратиться к соответсвующей литературе для устранения пробела в знаниях, хотя бы для более полного понимания сути освещаемой в этой статье идей. Более точно такие пограммы назывались «программы логического моделирования дискретных устройств». Были еще программы физического моделирования, проверяющих нагружающую способность каждого вывода микросхемы, токов истока, паразитных емкостей и т.д. Но программы такого класа не имеют отношения к предмету данной статьи, по одной простой причине : алгоритмы, которые мы собираемся в дальнейшем эмулировать, какими бы сложными они не были, всегда будут оставаться программными моделями, а в программной модели не бывает ни истоков тока, ни паразитных емкостей.
Исторически симуляторы появились в ответ на законное желание разработчиков цифровых устройств – проверять работу спроектированой схемы еще до того, как она будет реализована при помощи паяльника. Ведь не очень то и приятно снова и снова за него браться, чтобы исправить ошибки, допущеные на этапе проектирвания. Но речь шла об иследовательских промышленных образцах, включающих до 70 и более корпусов интегральных микросхем на плате.
Моделирование можно считать правильно выполненым в случае, если получены правильные временные соотношения между уровнями сигналов в абсолютно всех цепочках прибора. Результатом моделирования в каждом случае будет какой либо масив состояний уровней сигналов в цепочках схемы, который можно вывести на принтер или на дисплей в виде графиков.
Только такие графики отображают всю динамику смен сигналов в цепочках модели, а не реальной схемы. Поэтому могут рассматриваться как «мертвый» отпечаток событий в реальном устройстве, к тому же очень и очень растянутым во времени.
За единицу условной временой шкалы принимается задержка на том компоненте схемы, которому согласно справочным данным она есть наименьшей. Если выразиться точнее – как правило, берется значение наименьшего кратного для значений задержек сигналов для всех типов компонентов.
Уровни входящих сигналов программа моделирования шаг за шагом «подает» на вход программной модели, выбирая их из так называемого масива входящих потоков. Онятно, что само слово «масив» - это атрибут программистских «штучек» и не имеет ни малейшего отношения к реальным сигналам.
Это и есть моделирование!
А что же тогда эмуляция?
Емуляция –это имитация поведения реального устройства в режиме реального времени. Здесь уместна аналогия "черного ящика" - условно говоря, действительно ящика, в котором находится электрический разъем для подключения реальных входящих и исходящих сигналов от объекта управления. При этом сторонний наблюдатель не сможет сказать ( на путать с –угадать), что в этом ящике находится: реальное электронное устройство или микропроцесорный прибор (ПК), на котором имитируется его работа в режиме реального времени.
Теперь уточним, - а что стоит понимать под « режимом реального времени»? В самом общем случае под этим стоит понимать случай, когда скорость имитации (эмуляции) равна скорости смены процессов в реальном обьекте управления. Иными словами, ,будет ли отклик (снятые сигналы) с программной модели успевать за переменчивыми процессами в реальном обьекте управления.
В нашем случае можно дать и более конкретное определение: если скорость емуляции будет равняться ( и даже выше) скорости выполнения программы управления, что программист обычным способом написал бы в качестве управляющей для данного объекта – можно говорить о режиме реального времени.
Под «обычным» способом подразумевается реализация программного цыкла «считывания сигналов с датчиков, обработка входящих сигналов по определенному алгоритму, формирование управляющих сигналов на исполнительные органы» на каком-нибудь языке программирования. Именно таким способом пишутся программы для систем автоматики.
Теперь попробую показать: какие условия необходимо выполнить, чтобы программу моделирования преобразовать в программу схемной емуляции.
Сначала – о входящих сигналах.
Уже отмечалось, что в программах схемной симуляции уровни сигналов, подаваемых на программную модель цифрового прибора, шаг за шагом выбираются с так называемого масива входящих потоков. Это означает, что «сигналы» подающиеся на программную модель какого-нибудь электронного прибора имеют не физическую, а программную природу.
Уверен, что разработчикам этих самых симуляторов, не составило бы больших трудов дополнить свои программы модулями стыковки с «внешним миром».
Для этого необходимо всего лишь использовать так называемые порты компьютера. Задача абсолютно банальна, но это не преобразует их программы на емуляторы.
Почему? Да потому, что такая программа должна работать еще и в режиме реального времени.
Вот тут и начинаются проблемы. Ведь все известные на сегодняшний день схемные эмуляторы работают исключительно в условной временной шкале, и другого от них пока и не требовалось! Это означает, что моделирование процессов, протекающих в реальном электронном устройстве за несколько микро- или милисекунд, на ПК могут достигать нескольких минут.
Но представим, что и эту проблему Вы все-таки одолели. Это хорошо! Но и этого мало! Почему?
Ведь современным симуляторам нужны еще и ресурсы ПК, и желательно более современного. Под ресурсами стоит понимать объем дискового пространства и объем оперативной памяти. Ну и конечно, мощность процессора.
К моему счастью, говорить о возможностях размещения таких программ в микропроцессорных платформах, которые встраивают, явно преждевременно. И, наконец, всякая известная на сегодня программа цифрового моделирования работает с двумя дискретными значениями уровней логических сигналов в цепях схемы: логическим нулем (0) и логической единицей (1). Но на практике, в самой обычной АСУ ТП, мы имеем дело не только с дискретными сигналами, но и аналоговыми. Это могут быть сигналы, которые снимаются с аналоговых датчиков (скорость, обороты в минуту, температура и тому подобное). Поэтому система должна быть способной выполнять смешанное, аналого-цифровое моделирование.
Если Вам удалось создать программу, в которой соблюдены все перечисленные мной выше требования, то такую программу со всей справедливостью уже можно назвать эмулятором!
Здесь мне хочется отметить, что целью данной статьи является популяризация идеи применения принципов схемной эмуляции в основе систем графического программирования, а не изложение своих собственных алгоритмов. Хотя лично мне, одно время, удалось реализовать все выше изложенные идеи в программе, которую назвал ПУЛЬС.
Осталось только ответить на последний вопрос: а какой вообще может быть связь между программой схемной эмуляции и Системой Графического Программирования?
А все дело только в том, что понимать под словом "схема". Ведь это действительно может быть принципиальная схема некоторого электронного устройства, которое аппаратно реализует некоторый алгоритм управления. Но это может быть и непосредственно функциональная схема алгоритма управления некоторой системы: например, АСУ ТП, системы управления летательным аппаратом, алгоритма функционирования биологической или физической модели.
Это может быть рисунок релейных (LD) или функциональных блочных диаграмм (FBD).
Это может быть рисунок нейронной сети, которая становится все более популярной сегодня для систем АСУ ТП верхнего уровня или граф переходов цифрового автомата для случая автоматного программирования.
Один мой знакомый, работая с ПУЛЬСом, отдавал предпочтение реализации алгоритмов управления исключительно на цифровых компонентах: ему, как прежнему цифровику, ничего не было милее и понятнее родных вентилей, счетчиков, триггеров и мультиплексоров. И к тому же фантазировать можно без ограничений: платы же за компоненты не нужно было – потому что они все виртуальны!
Эмуляция принципиальных схем - это, конечно, отдельный случай. Хотя ничто не запрещает пользователю реализовывать алгоритм управления путем проектирования электронной схемы, просто данный пример наглядно демонстрирует всю мощь метода.
Поэтому можно сказать, что вид графического программирования (метод проектирования рисунка) будет определяться только тем, какими компонентами из общей библиотеки компонентов системы Вы будете пользоваться. Главное, чтобы эти компоненты уже входили в так называемую библиотеку компонентов. Фирма, которая занимается сопровождением такой системы, естественно, должна будет постоянно отслеживать вопрос расширения библиотек компонентов для разных областей, и предусмотреть возможность их загрузки c фирменного сайта.
Ну, а если кто-то решит разрабатывать свои личные - то в программной оболочке должен будет предусмотреть соответствующий инструментарий.
К мысли об использовании алгоритма схемотехнического моделирования в основе системы выполнения меня подтолкнуло (в том числе) – и внешнее подобие графических проектов: те же "квадратики", "ромбики"...и множество линий (цепей), которые соединяют между собой компоненты рисунка.
Вот и зародилась идея, зачем же рисовать алгоритм управления (например), чтобы потом так над ним "глумиться"? - разрабатывать специальные графические компиляторы, чтобы вот так сразу взять и уничтожить всю графику, превратив ее в файлы каких-то (Tic,g и др.) кодов. А затем еще разрабатывать компиляторы или интерпретаторы, которые станут расшифровывать все закодированные инструкции, которые находятся в этих файлах и шаг за шагом выполнять на целевой системе (контролере).
Ведь давней мечтой разработчиков программного обеспечения была то, чтобы программы работали так же надежно, как электронные устройства. Схемная эмуляция именно и позволяет рассматривать программу (представленную в графическом виде) как схему, но в то же время позволяет "не браться за паяльник", а просто имитировать ее работу с помощью программы схемной эмуляции.
Универсальная эмуляционная платформа.
Следовательно, система графического программирования, построенная на принципах схемной эмуляции, состоит только из двух основных компонентов: графического редактора и системы выполнения, работа которой именно и основанная на принципах схемной эмуляции.
Идея использования графического редактора ровно ничем не отличается от уже известных систем. Процесс проектирования какой-либо системы управления выглядит обычно: из библиотеки компонентов выбирается графический образ какого-либо компонента и переносится на рабочую область рисунка графического редактора. После компоненты соединяются между собой необходимыми цепями (линиями связи). Вот и все "программирование"!
Графический компилятор (кит №2) в такой системе отсутствует, поскольку в генерации каких-либо кодов и в последующем их компилировании необходимости нет.
Вместо этого в графическом редакторе используется программный модуль, который "пересматривает" графический рисунок проекта и по нему формирует так называемый "Файл Описания Проекта" (ФОП) - обычный текстовый файл, который содержит всего лишь список всех цепей (линий связи) графического проекта какой-либо системы управления.
В принципе, все так же, как это делается в любом программном симуляторе.
Потом файл ФОП необходимо загрузить во встроенную микропроцессорную платформу по сети или через специальный порт.
Поскольку каждый компонент, используемый разработчиком в проекте, кроме графического образа в среде графического редактора имеет еще и программный модуль в среде выполнения, - то все задействованные в проекте модули необходимо также загрузить в контролер.
А вот в качестве системы выполнения (кит №3) используется программный модуль схемной эмуляции, который целесообразно предварительно разместить в постоянной памяти микропроцессорной платформы.
В самом начале своей работы модуль эмуляции "пересматривает" ФОП и, используя коды готовых программных библиотечных модулей компонент рисунка, разворачивает в оперативной памяти контролера программную модель системы управления.
Входящие потоки для такой модели снимаются с реальных датчиков АСУ ТП, а отзыв из программной модели подается на реальные исполнительные устройства через порты платформы.
Всю библиотеку компонентов, используемую в среде графического редактора на этапе проектирования рисунка проекта, можно условно разбить на два класса. К первому относятся те, которые отображают реальное оборудование: разные датчики и исполнительные органы, например реле. Ко второму – не имеющие "железного" аналога. Это чисто функциональные элементы, такие как нормализаторы сигналов, частотные фильтры, сумматоры, компараторы, логика, и так далее
Поэтому, если на схеме проекта разработчик использовал графический образ, например, датчика температуры, то тогда нужно не забыть подключить соответствующий ему реальный датчик к интерфейсу контролера.
Объем модуля эмуляции составляет менее 30 кбайт и потому он с успехом может быть размещен в эмулирующей платформе. Имеет смысл разместить его в постоянной памяти микропроцессора, закрыть битом секретности и продавать платформу как завершенное аппаратно - программное изделие.
Хочу сразу подчеркнуть, что для того, чтобы максимально оптимизировать работу модуля эмуляции - необходима специальная архитектура самой микропроцессорной платформы, что и дает все основания называть ее - Эмулированной.
Такая платформа будет универсальной, потому что по своим ценовым и функциональным возможностям, а также возможностям масштабирования, она будет годиться для использования в самом широком спектре областей: от лабораторного студенческого или инженерного стенда – к АСУ ТП масштаба предприятия.
Принцип эмуляции просто и эффективно поддерживает идеологию распределенного управления - Dcs-систем (дословно - распределенных систем управления) и мультипроцессорной обработки! Причем, вовсе не нужна разработка каких-либо программных кодов для организации межпроцессорного обмена, разпараллеливання потоков, их синхронизации, и тому подобное.
Реализация эмулированной платформы на основе недорогого микропроцессора (например, серии AVR) будет являть собой недорогой коммерческий вариант, доступный самому широкому кругу пользователей. Применять ее можно будет в тех системах управления, где возможное приложение микропроцессоров само по себе, исходя из условий внешних электрических препятствий и времени отзыва системы.
Не менее интересным представляется вариант "апаратной" реализации алгоритма эмуляции на основе микросхемы програмируемой логики - ПЛИСС для эмуляции быстрых алгоритмов, например - обработки сигналов или реализации скоростных вычислителей.
Осталось только дело за фирмой, которая возьмется за коммерциализацию такого проекта.
Принцип схемной эмуляции позволяет просто и эффективно организовать процедуру визуализации протекают в отлаживаемой АСУ ТП процессов. Для этого достаточно будет присоединить ПК к платформе на время настройки. Визуализация может проводиться как в режиме реального времени, так и в пошаговом режиме - в т.н. режиме циклов.
Програма-визуализатор, установленная на таком ПК, будет исполнять роль многоканального осциллографа, который зеркально отображает уровни сигналов в соответствующих цепях алгоритма управления АСУ ТП.
Для случая двухуровневой (многоуровневой) АСУ ТП, где наличие оператора ПК предусмотрено по штатной конфигурации, визуализатор представляется в виде картинок технологического процесса.
Джерело: http://www.vynahidnyk.org.ua/ru/publications/56/51/ |
| Категорія: | Додав: shevavm (08.08.2010)
|
| Переглядів: 1124
| Рейтинг: 0.0/0 |
|
