Ковалев Сергей Эдуардович, г. Киев simula
ИННОВАЦИОННЫЙ ПРОЕКТ - "ПУЛЬС":
(описание идеи)
Система графического программирования - исполнения,
построенная на принципах схемной эмуляции
&
Универсальная платформа эмуляции алгоритмов и систем
&
Архитектура потоковой суперЭВМ построенная напринципах схемной эмуляции.
Сравнительный анализ
с известными архитектурами.
Содержание статьи:
стр.
Аннотация ….. 2
Предисловие ….. 2
Недостатки современных методов проектирования аппаратно-программных ….. 4
систем
Программа схемной эмуляции "Пульс" ….. 6
Графическое программирование: миф о SCADA системах ….. 7
Универсальная платформа эмуляции ….. 10
Преимущества эмуляции ….. 13
Схемная эмуляция и автоматное программирование ….. 23
Архитектура потоковой суперЭВМ, построенной на принципах схемной
эмуляции. Сравнительный анализ с известными архитектурами. ….. 27
I Архитектура фон Неймана ….. 28
I - I Архитектура многопроцессорной ЭВМ с жесткими связями ….. 29
I - II Архитектура кластерных структур ….. 30
II Архитектура реконфигурируемых вычислительных структур ….. 31
III Архитектура традиционной машины потоков ….. 35
IV Архитектура машины потоков, построенной на принципах схемной
Эмуляции ….. 38
V Архитектура кластерной системы, построенной на принципах схемной
Эмуляции ….. 44
Немного истории ….. 45
Вместо эпилога ….. 45
"… если вы хотите добиться настоящего успеха в бизнесе, вы должны иметь такую идею, которой нет у других".
Г.Форд
Аннотация
Представляемая к рассмотрению аппаратно-программная система "Пульс" позиционируется мною как альтернатива существующей в настоящее время широкой номенклатуре микропроцессорных платформ, а также средствам и методам их программирования.
Так исторически сложилось, что до настоящего времени реализовать любой алгоритм представлялось возможным только двумя способами: аппаратным или программным. Авторская идея схемной эмуляции алгоритмов и систем впервые открывает новый путь реализации алгоритмов - их эмуляцией в авторской среде схемной эмуляции.
В основе проекта лежит авторский программный модуль схемной эмуляции, позволяющий создать принципиально новую среду исполнения – систему эмуляции графических образов проектов пользователей, как альтернативную среду традиционным системам исполнения, построенных на принципах компиляции или интерпретации исходных программных текстов.
С одной стороны, целью проекта есть стремление приблизить средства разработки различных аппаратно-программных систем к широкому кругу конечных пользователей, дав им в руки инструментарий, позволяющий реализовывать задуманные ими системы из готовых аппаратно-программных "кубиков" и освободив их, тем самым, от посредничества электронщиков и программистов. Инструментарий, позволяющий просто эмулировать проекты, представленные в графическом виде, на PC- платформах или на т.н. Универсальной Платформе Эмуляции алгоритмов и систем: от простейших систем автоматики - до АСУ ТП масштаба предприятия, от систем сбора и обработки информации – до диагностических комплексов и систем моделирования различных процессов и т.д.
С другой стороны, представляемая Система Эмуляции позволяет использовать язык графического программирования так называемого уровня структурных схем, соответствующий уровню системотехнического проектирования электронных систем. Такой язык обладает гораздо большей функциональной мощностью представления проектов, чем известные языки программирования, как текстовые, так и графические. Проектирование различных задач на языке такого уровня позволит создавать проекты, реализовать которые в рамках парадигмы современных языков программирования крайне затруднено, а то и вообще невозможно. Что, безусловно, придаст новый импульс к развитию таких направлений искусственного интеллекта, как: Системы Понимания, Базы Знаний, Экспертные Системы и т.д. Представляемая к рассмотрению система эмуляции позволяет также с легкостью строить кластерные системы, состоящие практически из любого числа PC- платформ.
Тем не менее, идеальной средой, в которой все важнейшие свойства авторского модуля схемной эмуляции могут быть раскрыты, является не среда современных микропроцессоров, а аппаратная среда параллельного действия т.н. вентильных массивов микросхем программируемой логики (ПЛИС). Именно соединение принципа многопоточности авторского алгоритма с принципами параллельного действия микросхем ПЛИС является источников создания принципиально новой мультипроцессорной вычислительной архитектуры – потокового суперкомпьютера.
Предисловие
В статье раскрывается идея использования авторской программы схемной эмуляции в основе Системы Графического Программирования и организации среды исполнения алгоритмов и систем, представленных в графическом виде. Представляемую систему следует рассматривать как альтернативу широко известным на сегодня SCADA и SoftLogic – системам. А поскольку по своему функциональному назначению такие системы предназначены для программирования встраиваемых платформ автоматики, то дальнейшее изложение возможностей своей системы я начну проводить именно под углом зрения АСУ ТП. Но здесь я особо хочу подчеркнуть, что если область применения современных SCADA ограничивается исключительно тематикой автоматизации, то для предлагаемой к рассмотрению Системы Эмуляции – это только начало!
В представляемой системе программирование аппаратно-программных устройств любой сложности замещается этапом составления проектов пользователей на уровне их графического представления, путем рисования необходимых схем (алгоритмы, графы и т.д.) в среде графического редактора. Однако на этом все сходство с известными системами заканчивается. Потому что основополагающим принципом работы всех без исключения SCADA основано на дальнейшем этапе банальной перекомпиляции графического образа проекта в последовательность программных кодов. Да по-другому, в принципе, и быть не могло – ведь использование любого микропроцессора (как системы исполнения) предполагает наличие программного обеспечения. В свою очередь, создание программ подразумевает использование каких-либо языков программирования, а также сопутствующих им средств разработки, включающие в себя компиляторы или интерпретаторы.
До некоторого времени это было нормально, пока мировая техническая мысль все более настойчиво не стала сталкиваться с пониманием того факта, что архитектура современных ЭВМ, основанная на принципах фон Неймана, все слабее стыкуется с парадигмой современных языков программирования, известного как семантический разрыв.
Идея использовать принцип схемной эмуляции в основе системы исполнения открывает принципиально новый путь к созданию аппаратно-программных управляющих, вычислительных и интеллектуальных систем. Для такой системы исполнения представление проектов пользователей на уровне графических схем представляется естественной формой и не требует каких-либо перекодировок.
Главным ее преимуществом является то, что отказ от использования программных текстов и переход непосредственно к эмуляции (имитации) работы графического рисунка проекта несет в себе целый ряд преимуществ, которые не доступны традиционным системам программирования. Одно из них – возможность составлять проекты на гораздо более высоком уровне графического представления, чем это допускают существующие SCADA - на т.н. уровне Структурных Схем, что соответствует уровню системотехнического проектирования сложных электронных систем. В свою очередь, это влечет за собой поразительные возможности при проектировании - от простой, но эффективной реализации принципа масштабирования промышленных систем автоматики – до проектирования такого уровня сложности систем, как Экспертные Системы, Системы Понимания, Базы Знаний и т.д.
В статье последовательно проводится идея, что проектирование упомянутых систем, по сути являющихся "черным золотом" XXI века, до конца не может быть реализовано в рамках парадигмы существующих языков программирования. Только проектирование на уровне Структурных Схем, способно привнести по настоящему действенный импульс в развитие упомянутых направлений информатики, которые, по существу, давно находятся в состоянии застоя.
Представляемая к рассмотрению Система Эмуляции в самом полном объеме позволяет реализовать давнюю мечту проектировщиков о единой (сквозной) спецификации проектов для всех стадий разработки: общепринятый цикл любого технологического процесса - "заказчик технолог электронщик программист электронщик технолог заказчик" – она полностью отменяет. Такая система впервые предоставляет возможность самому пользователю, как специалисту в своей области знаний (физику, математику, биологу, лингвисту и т.д.), непосредственно сосредоточиться над реализацией своего проекта, не прибегая при этом к услугам, как электронщиков, так и программистов.
Другим, принципиально важным свойством представляемой системы эмуляции, есть то, что в основу ее работы положен механизм параллельного действия. Конечно же, в среде PC платформ или встраиваемых микропроцессоров, принцип многопоточности может только имитироваться. Для наиболее же полного раскрытия свойств алгоритма требуется и среда параллельного действия. К счастью, в настоящее время такая среда уже существует – это т.н. матрицы вентильных массивов FPGA (Field-Programmable Gate Arrays) микросхем программируемой логики (ПЛИС).
Именно соединение этих двух компонент – авторского алгоритма схемной эмуляции (реализованного на принципах многопоточности), и матрицы вентильных массивов (как устройства параллельного действия), открывает широчайшие возможности для проектирования таких систем, как потоковых суперЭВМ.
К слову сказать, идея потоковых машин – "стара как мир". Ежегодно относительно этого, в целом по миру, печатается огромное число статей и монографий, благополучно защищаются диссертации, тратятся миллионы долларов на изготовление прототипов. Но то, что архитектура фон Неймана по-прежнему "правит миром" – говорит о глубоком системном кризисе, поразившем эту область знаний.
Другим, активно развиваемым направлением, сегодня можно считать проектирование суперЭВМ на основе т.н. реконфигурируемых вычислительных систем (РВС), которые по сути также можно назвать потоковыми. Но, не смотря на все интеллектуальные усилия в этом направлении за последние десятилетия, дальше разработки экспериментальных образцов дело также пока не дошло.
Данная статья преследует целью показать, что использование идеи Схемной Эмуляции в основе потоковой суперЭВМ способно кардинально изменить ситуацию. Потому что всех тех проблем, которые присущи традиционным архитектурам – здесь просто нет!
Разработка архитектуры потоковой суперЭВМ, основанной на принципах схемной эмуляции, – это еще один пример, служащий подтверждению универсальности идеи схемной эмуляции, другими словами – широкому спектру областей, в которых она может с успехом быть применена.
Время показало, что копирование западных технологий – путь бесперспективный, только оставляющий нам право пожизненно находится в роли догоняющих. В свою очередь, внедрять новые технологии под видом так любезно предоставляемых нам готовых инвестиционных проектов - значит "посадить" себя на "технологическую иглу" на длительный исторический период. Поэтому со всей уверенностью можно сказать, что только развитие и использование отечественного потенциала изобретений и ноу-хау есть путь единственно верный.
Целью данной статьи является популяризация авторской идеи использования принципов схемной эмуляции в основе системы графического программирования-исполнения. Идея является абсолютно оригинальной и не имеет аналогов в мире. И как я попытаюсь показать – обладает уникальным потенциалом к развитию во многих областях знаний.
Реализация (коммерциализация) проекта "Пульс" придаст мощный импульс к развитию таких направлений как системы автоматики, АСУ ТП, интеллектуальные системы и суперЭВМ. Что, в свою очередь, послужит надежной базой для качественного развития большого числа различных отраслей знаний. Это позволит нам со всей справедливостью занять лидирующие позиции в мире в деле построения постиндустриальной державы, совершить качественный рывок в этом направлении. И это в то время, когда мы пока далеки еще даже от уровня развитого индустриального государства, сохраняя пока имидж сырьевой базы для мировой экономической системы. Именно развитие собственных высокоинтеллектуальных и высокопроизводительных вычислительных систем способны стать локомотивом развития всей отечественной экономики. Другого пути просто нет.
Недостатки современных методов проектирования аппаратно-программных систем
Поскольку я собираюсь говорить далее о недостатках, присущих существующим методам и средствам проектирования аппаратно-программных систем, то придется говорить как о проблемах аппаратного обеспечения, так и проблемах, привносимых непосредственно программированием.
Главная аппаратная проблема – это трудноперечислимое количество микропроцессорных кристаллов и платформ, построенных на их основе. С появлением первых микропроцессоров возникло было мнение, что наконец-то разработчики ситем получили в свое распоряжение универсальное устройство, которое, в случае изменения алгоритма задачи, достаточно будет просто перепрограммировать. Однако, функциональные ограничения, накладываемые на кристалл со стороны его регистровой структуры, внутренней памяти и каналов ввода – вывода, показали, что говорить об абсолютной универсальности пока еще рано. Поэтому перед любым специалистом, приступающим к разработке микропроцессорной системы, с первых шагов встает вопрос выбора кристалла и средств его программирования. Важным фактором при выборе выступает сама задача. Чем объемнее и сложнее реализуемый ею алгоритм – тем мощнее должен быть микропроцессор. Затем наступают этапы изготовления платформы, ее отладки и дальнейшего доведения в составе системы, включающего в себя как устранение ошибок, допущенных электронщиком на этапах проектирования и изготовления, так и ошибок программирования.
К тому же, современные средства отладки выполняют функции замещения только для процессора и памяти, и не являются конструкторами для всей системы. Задача проектирования и отладки подсистемы ввода-вывода целиком ложится на разработчика. Да и проектирование самого процессорного ядра с точки зрения схемотехники и топологии нетривиальна даже для опытного разработчика.
Справедливости ради нельзя не согласиться, что в настоящее время немалое число как отечественных, так и зарубежных фирм предлагают готовые системы в виде разного рода отладочных плат и плат развития, которые нужно только запрограммировать. Но говорить об универсальности и тут не приходится, потому как всякая из них "заточена" на конкретную область применения, а также на удовлетворение определенных узких интересов фирм производящих такие платформы.
Определенный вопрос вызывает факт наличия компонентов, в особенности, что касается ремонта уже эксплуатируемого оборудования, для которого ключевые компоненты могут уже не производиться. Проблема компонентов, как и вопрос замены морально устаревшего оборудования, зачастую приводит к банальной необходимости начинать с нуля разработку новой системы.
В целом, общество несет большие накладные расходы, занимаясь производством громадного количества систем, которые через несколько лет эксплуатации попросту выбрасываются на свалку.
Что касается проблем программирования, то про это, как говориться, исписаны тома. В специальной литературе и всемирной Сети этому явлению дано определение как кризис программирования. Сегодня принято выделять несколько проблем, которые, собственно, и превращают программирование в кризис:
Первая – это лавинообразный рост программного кода в программных продуктах, связанный с ростом функциональной сложности прикладных программ. Все больше усилий требуется от разработчика на написание и отладку кода, оставляя меньше сил и времени на проработку самой задачи, поиск ошибок и оптимизацию. Сам же процесс исправления ошибок все более напоминает латание дыр.
Вторая – это все более растущее число логических ошибок в программах. Это объясняется тем, что любая программа способна правильно реагировать только на ту комбинацию событий, которые предусмотрел программист. Вне зависимости от методов разработки у любой программы есть состояния, в каждый момент времени определяемое значениями всех ее переменных. Тогда изменение значения одной из управляющих переменных будет означать изменение состояния программы, а число состояний программы будет определяться максимально возможным количеством комбинаций значений управляющих переменных, возникающим при ее работе.
Если предположить, что в программе используются только двоичные управляющие переменные (флаги), то в этом случае количество состояний будет стремиться к 2n. Поэтому нет никакой гарантии, что в процессе работы программы не возникнет неожиданное сочетание входных воздействий, когда программа перейдет в непредусмотренное состояние.
Такие состояния Фредерик Брукс назвал "невизуализированными". "Сложность служит причиной перечисления, а тем более понимания всех возможных состояний программы, а отсюда возникает ее ненадежность... " [Брукс Ф. Мифический человеко-месяц или как создаются программные системы. СПб.: Символ, 2000. 304 с.]
На заре компьютерной техники программы решали сравнительно несложные задачи, поэтому и были сравнительно невелики. Естественно, и в таких объемах появлялись ошибки, но для их поиска не надо было перелопачивать мегатонны кода.
Согласно данным отчета Национального института по стандартам и технологии, объем экономических потерь из-за ошибочного ПО только в США достигает нескольких миллиардов долларов в год, что составляет около 1% национального валового внутреннего продукта. (Research Triangle Institute, NIST Planning Report 02-3, May 2002).
Третья – это отсутствие явных методов формализации. Результатом совместной работы заказчика и технолога является некий алгоритм, представленный в виде графического рисунка или описания – что выступает основой документа, называемого техническим заданием.
Затем программисту необходимо проделать неформальную операцию перевода этого документа в язык машинных кодов – программного продукта предоставляемого заказчику. Вот тут-то и начинаются все беды. В большинстве случаев переход от алгоритмизации к программированию представляет определенную проблему. Программисту приходится додумывать, как представить ее вычислителю на понятном ему языке – языке программных кодов. По существу получается, что программа отображает то, как программист смог понять исходный алгоритм. В конечном счете, появляются два алгоритма: один на бумаге, для отчетности и документирования проектных решений, второй – в листинге программы.
Зачастую получается так, что граф алгоритма, разработанного программистом, не совпадет с графом исходного алгоритма. Другими словами, графы оказываются не изоморфными. К чему это может привести? – к тому, что "местами" программа, разработанная программистом, может работать не так, как изначально было задумано. В чем это выражается? Известна история про то, как при испытаниях некоей навигационной системы периодически происходил ее сброс. После долгих разбирательств выяснилось, что при переходе уровня моря (уровня Мирового океана) происходила ошибка "деление на ноль". В другом случае перестала работать географическая система, когда ее решили использовать на другой территории. Как выяснилось, ошибка была связана с переходом через широту 90o.
Э. Дейкстра по этому поводу писал: "Я знал, что программы могут очаровывать глубиной своего логического изящества, но мне постоянно приходилось убеждаться, что большинство из них появляются в виде, рассчитанном на механическое выполнение, и что они совершенно не пригодны для человеческого восприятия..." [Дейкстра Э., Дисцмплина программирования. М: Мир, 1979.]
В дополнение к сказанному можно сказать, что программирование, несмотря на свою массовость, по-прежнему остается искусством. На практике это, попросту говоря, означает, что каждый программист программирует так, как умеет. Вот почему степень затрат времени и средств, выделяемых на проект, до сих пор находятся в прямой зависимости от способностей и амбиций программиста. К тому же, Он оказывается единственным держателем важнейшей логической информации и человеком, способным разобраться в своем творении и от которого, в конечном счете, зависит судьба всего проекта. Нечего уже и говорить про случай, когда человек может просто уволиться в разгар проекта.
Четвертая - уровень современных, все более сложных задач, все настойчивее ставит перед разработчиками аппаратно-программных систем применения все более сложных механизмов их реализации. Прежде всего, тут можно упомянуть про задачи параллельной обработки информации и параллельных сосредоточенных и распределенных вычислений.
И здесь вся трудоемкость процесса выявления в алгоритме задачи мест, которые могут быть разделены на отдельные потоки, их синхронизацию и т.д. - целиком и полностью ложится на плечи программиста. Но мало того, что задача эта способствует добавлению в программу большого объема кодов, напрямую не связанных с выполнением главной задачи, но также существенным образом увеличивает издержки на тестирование и, в конечном счете, снижает надежность программного продукта.
----------------------------------------------------------
А что же предлагает взамен названных проблем представляемая в данной статье идея эмуляции алгоритмов и систем? Резюмирую пока вкратце наблюдаемые преимущества, оставив более полное их раскрытие по ходу статьи.
Ну, во-первых, как альтернатива всему многообразию микропроцессорных платформ идея эмуляции предлагает универсальную (единую и полнофункциональную) платформу, называемую далее – Универсальной Платформой Эмуляции алгоритмов и систем. Универсальность ее проявляется в том, что в случае, когда мощности одной платформы окажется недостаточной для размещения в ней всего рисунка проекта пользователя, проблема решается простым добавлением в систему некоторого (необходимого) числа точно таких же платформ. Тогда весь исходный рисунок необходимо разбить на N частей, каждая из которых затем загружается в отдельную платформу.
При этом, объединение всех фрагментов в функциональном плане, происходит на уровне обобщенной программной модели проекта, которая формируется благодаря совместной работе программных модулей схемной эмуляции, аппаратно прошитых в каждую платформу. А выявление и синхронизация всех параллельных процессов в модели происходит автоматически. То есть, система не нуждается в написании каких-либо программных кодов по организации межплатформенного обмена (служебной информации и данных задачи). Соединение же всех N платформ на физическом уровне организуется по сетевому интерфейсу.
И во-вторых, составление любых проектов пользователь выполняет исключительно в графическом виде, путем рисования в среде графического редактора схем алгоритмов, графов, структурных схем и т.д. Пользователь полностью освобожден от пользования какими-либо языками программирования, а значит, и от каких-либо инструментальных средств проектирования и отладки программ.
Программа схемной эмуляции "Пульс"
Итак, в основе предлагаемой к рассмотрению идеи лежит авторская программа Схемной Эмуляции. Что следует понимать под этим словосочетанием? Ведь любой электронщик возразит, что нет в природе программ такого класса. В качестве примера он упомянет так называемые программы-симуляторы, такие как Micro-CAP от "Spectrum SoftWare", PSpice от "MicroSim Corp." и т.д. и т.п., то, что в советскую эпоху у нас принято было называть программами моделирования электронных устройств.
Исторически симуляторы появились в ответ на законное желание разработчиков электронных устройств иметь возможность проверять работу спроектированной схемы до того, как она будет реализована с помощью паяльника.
В таких программах уровни входных сигналов, выбираемые из так называемого массива входных воздействий, шаг за шагом "подаются" на вход программной модели. Разумеется, что само слово "массив" – это атрибут программистских "штучек" и не имеет ни малейшего отношения к реальным сигналам. Проектирование можно считать выполненным правильно в случае, если получены правильные временные соотношения для уровней сигналов во всех цепях устройства.
Результатом моделирования становится некий массив уровней сигналов в цепях схемы, который можно затем вывести на принтер или дисплей в виде графиков. Только вот, такие графики отображают динамику изменений сигналов в цепях модели, а не реальной системы.
А что же тогда есть эмуляция? Эмуляция – это моделирование, выполняемое в режиме реального времени и в реальной среде окружения периферийных устройств.
Для того чтобы программа схемотехнического моделирования превратилась в программу схемной эмуляции необходимо выполнение некоторых условий.
Первое - добиться того, чтобы программа моделирования работала не с программными массивами, а с реальными сигналами. В этом случае на вход программной модели должны подаваться не комбинации входных событий, выбираемые из программного массива, а уровни сигналов, снимаемых с реальной системы. В тоже время, отклики, снимаемые с программной модели, опять-таки, должны подаваться на реальные исполняющие устройства.
Второе - добиться того, чтобы программа моделирования работала в режиме реального времени, а не какой-либо условной временной шкале. Потому что эмуляция – это имитация поведения какого-либо реального устройства, как будто его схема уже реализована с помощью паяльника.
Под "режимом реального времени" следует понимать случай, когда скорость имитации становится соизмеримой со скоростью изменения процессов в реальном объекте управления. Другими словами, когда отклик, снимаемый с программной модели, будет поспевать за процессами, протекающими в реальной среде окружения.
Третье – сделать так, чтобы программа моделирования не требовала ресурсов PC. Соблюдение этого условия позволит размещать ее не только на PC платформах, но и во встраиваемых контроллерах. Выполнение этого условия позволит существенно сократить показатели стоимости на внедряемые системы.
Программу схемотехнического моделирования, удовлетворяющую выполнению вышеперечислен-ных условий, уже по праву можно назвать – Программой Схемной Эмуляции. В основу предлагаемой мною системы положен авторский алгоритм схемной эмуляции, реализованный в авторском программном продукте - схемном эмуляторе “Пульс” (автоpское свидетельство ПА No 214 от 12.08.96, Госудаpственное Агенство Укpаины по Автоpским и Смежным Пpавам).
В тоже время, разработанный и программно реализованный мною алгоритм, успешно выполняет еще одно условие – в основу его работы положен принцип параллельных потоков.
Конечно же, в среде PC платформ или встраиваемых микропроцессоров, принцип многопоточности может только имитироваться. Для наиболее же полного раскрытия свойств алгоритма требуется и среда параллельного действия. К счастью, в настоящее время реализация такой среды известна – это т.н. матрицы вентильных массивов FPGA (Field-Programmable Gate Arrays) микросхем программируемой логики (ПЛИС).
Именно соединение этих двух компонент – авторского модуля схемной эмуляции (реализованного на принципах многопоточности), и матрицы вентильных массивов (как устройства параллельного действия), открывает широчайшие возможности для проектирования таких систем, как потоковой супер-ЭВМ (машины потоков).
Осталось только ответить на последний вопрос: а какая вообще может быть связь между программой схемной эмуляции и эмуляцией алгоритмов или систем?
А все дело только в том, что понимать под словом "схема". Ведь это действительно может быть принципиальная схема некоторого электронного устройства, аппаратно реализующего некоторый алгоритм, но это может быть и непосредственно структурная схема управления некоторой системы: к примеру, АСУ ТП, системы управления летательным аппаратом, биологической или физической модели разрабатываемой конечным пользователем и т.д. В конце концов, это может быть рисунок релейных диаграмм (LD), функциональных блоковых диаграмм (FBD) или схема алгоритма.
По сути, уровень составления проекта пользователя (рисования схемы) определяется видом использованных в нем библиотечных компонент.
Эмуляция принципиальных схем – это, конечно, частный случай. Хотя ничто не запрещает пользователю реализовывать алгоритм управления путем использования электронной схемы, просто данный пример наглядно демонстрирует всю мощь метода.
Однако самым важным преимуществом системы эмуляции состоит в том, что она дает пользователю возможность проектировать на уровне Структурных Схем. Именно такой уровень представления проектов, с одной стороны, способен стать настоящим графическим языком межпрофессионального общения и с другой – позволит проектировать системы такой сложности, которые невозможно создать в средах существующих систем графического программирования и программирования вообще!
В завершении, не могу не коснуться вопроса терминологической путаницы, сложившейся в последнее время вокруг фразы "схемная эмуляция" и захлестнувшей нынче как специальную литературу, так и весь интернет. Под нею ныне сплошь и рядом почему-то стали подразумевать средства отладки микропроцессорных систем. По этому поводу так и хочется сказать – Господа хорошие, авторы статей – не путайте себя и не вводите в заблуждение доверчивых читателей! Потому что то, про что Вы пишите, называется, все-таки, средствами "внутрисхемной эмуляции". А это, как говорится, - уже совсем другая история.
Графическое программирование и миф о SCADA системах
Справедливости ради нельзя не сказать, что в настоящее время уже существует множество инструментальных средств, в которых программирование некоторых систем также выполняется путем рисования схем. Это так называемые SCADA системы, предназначенные для программирования встраиваемых платформ систем автоматики.
Собственно говоря, наличие графического редактора рисования схем в какой-либо инструментальной среде разработки ныне и служит приметой – относится ли она к системе графического программированию или нет.
Поэтому, чтобы полнее увидеть преимущества системы графического программирования, построенной на принципах схемной эмуляции, в сравнении с огромным числом уже известных на сегодня систем, необходимо разобраться – а в чем же состоит идеология работы последних.
А для этого надо четко уяснить, что любая известная т.н. Система Графического Программирования строится на трех китах: графическом редакторе рисования схем, графическом компиляторе и системе исполнения.
Что касается редакторов рисования, то тут проблем вроде как бы и нет: даже спроектировать такую "штуку" под силу практически любому программирующему студенту.
А вот графические компиляторы – вещи гораздо более серьезные.
В "обязанности" этой компоненты входит просмотр графического рисунка проекта и генерация по нему исходного кода программы, который иначе программисту пришлось бы набирать "ручками". Затем исходный код компилируется в некоторый промежуточный код. Вся эта работа выполняется программистом на рабочей станции (ПК).
После этого файл промежуточного кода уже можно загружать во встраиваемый контроллер. Туда же загружается и специальный интерпретатор промежуточного кода – система исполнения.
Для чего нужен промежуточный код? Да лишь для того, чтобы максимально упростить интерпретатор (систему исполнения). Делается это с целью достичь возможности "всунуть" его в какую-либо микропроцессорную платформу, а также ускорить исполнение программы пользователя.
После сказанного должно стать понятным, что принципиальной разницы между SCADA системами и обычными системами визуального программирования, такими как DELPHI, VC или Visual Basic в принципе нет. Потому как в обоих случаях исходные тексты программ генерируются по визуальным компонентам, что были использованы в проекте.
Классическим примером сказанному может служить всенародно известная программа IsaGRAF (от ICS Triplex ISAGRAF Inc.). Здесь при компиляции файла графического проекта генерируется промежуточный, так называемый TIC-код, который затем загружается во встраиваемый контроллер. Туда же подгружается т.н. TIC-интерпретатор, который и выполняет функцию системы исполнения.
В не менее народной программе LabVIEW (от National Instruments) генерируемые исходные тексты кодируются в так называемый промежуточный G–код, который затем интерпретируется (исполняется) непосредственно на PC из среды LabVIEW.
Параллельно выше рассмотренной идеологии существует несколько отличная, заключающаяся в том, что еще на этапе работы графического компилятора генерируется не промежуточный код, а сразу исполняемый, который и загружается в промышленный компьютер.
Такая идеология, как правило, также предлагается известными системами графического программирования.
В LabVIEW для этого имеется приложение Application Builder for LabVIEW, которое позволяет сгенерировать оптимизированный код, сравнимый с программным кодом C-компилятора. Такой исполняемый код принято называть - RUN-TIME модулем.
Система IsaGRAF также позволяет проводить генерацию обычного C-исходного кода, откомпилировав который обычным C-компилятором мы получаем "классический" RUN-TIME модуль.
Идея RUN-TIME модулей нашла применение и в других системах класса HMI и SCADA, например в LookOut for Windows, (той же фирмы). А также широко известной UltraLogic (UltraLogic), где исполняемый файл располагается в PC-совместимых контроллерах типа ADAM.
И так далее, и тому подобное…
Какую бы другую систему мы далее не рассматривали - мы увидим все то же самое.
Не являются исключением и программирование на языке лестничных диаграмм (LD) для всех известных линеек ПЛК – MODICON, Siemens, Allen-Bradley и др.
А все по одной простой причине: ни интерпретацию, ни компиляцию в программировании пока еще никто не отменял.
Таким образом, можно сказать, что в идеологии всех без исключения современных SCADA систем прослеживается упорное стремление возвратиться от графики к обычным программным кодам, чем автоматически вызывается к жизни весь тот "геморрой", которым страдает программирование как парадигма. Поэтому, говорить о том, что все они являются системами графического программирования – не совсем корректно!
Ну не назвали же разработчики DELPHI, VC и прочих систем графическими! Они назвали их системами Визуального Программирования.
Поэтому, на мое глубокое убеждение, правильнее было бы и SCADA/SoftLogic системы также назвать системами визуального программирования.
Недостатком современных SCADA/SoftLogic систем можно также считать и то, что они "заточены" всего-лишь на облегчение труда программистов и не направлены на конечного пользователя. Поэтому даже при их использовании программист остается ключевой фигурой любого проекта, что ведет к последствиям, которые в начале статьи уже рассматривались.
Система графического программирования, в основу которой положен принцип схемной эмуляции, как раз и предоставляет уникальный шанс отказаться от исходных и исполняемых кодов, а значит и от этапов компиляции/интерпретации. Потому что программный модуль схемной эмуляции, положенный в основу всей системы, по своей сути является системой графического исполнения, позволяющий непосредственно "оживить" графический рисунок любого проекта пользователя.
Таким образом, этапы программирования и исполнения в представляемой системе полностью согласованы. "Общим знаменателем" такой согласованности выступает работа с графическим образом проекта, как на этапе проектирования, так и на этапе исполнения.
Потому именно такая система по полному праву может называться Системой Графического Программирования.
Использование идеи схемной эмуляции в основе системы графического программирования позволяет достичь сразу двух важных моментов:
первый – таким компонентам, как "графическому компилятору" (кит №2) и исполняемому интерпретатору (кит №3) – в новой идеологии места нет!
Что, в свою очередь, ведет к поразительному упрощению всей системы в функциональном плане, а значит и ценовом.
второй - позволяет достичь многих характеристик, принципиально недоступных для всех известных SCADA/SoftLogic систем: программирование на уровне Структурных Схем, поразительные возможности по масштабированию, простота реализации мультиплатформенных и потоковых вычислений и т.д. Все дальнейшее содержание статьи, по сути, и направлено на рассмотрение этих преимуществ.
Причин, по которым SCADA системы так и не стали массовым инструментарием сборки аппаратно-программных систем из готовых "кубиков" можно назвать несколько:
- Такие системы чрезвычайно дороги и рассчитаны не на уровень простого студента, инженера, частного предпринимателя или даже малого предприятия, а рассчитаны на "жирных" клиентов. Другими словами - на автоматизацию заводов и фабрик. Там, где клиент способен выложить от сотен тысяч – до миллионов долларов.
В 1998-2000 годах мне посчастливилось стать свидетелем строительства линии по производству макарон одним частным предприятием. Желание сэкономить на программистах и на разработке аппаратной части проекта у руководства было столь велико, что (начитавшись рекламных проспектов) решили строить систему из готовых "кубиков". В качестве ПО разработки была выбрана система графического программирования UltraLogic, а в качестве аппаратных "кубиков" – устройства типа ADAM.
Только вот, ознакомившись поближе - посчитали, прослезились. И построили всю систему на "самопальных" контроллерах на процессорах типа AVR. И дешево вышло, и сердито!
- Все известные SCADA – это довольно сложные системы в освоении и работе. И заверения разработчиков, что такие системы рассчитаны на технологов, есть не более чем рекламный трюк. Пока что профессиональные коллективы, состоящие из программистов и электронщиков, в состоянии эффективно эксплуатировать такой продукт.
- Возможность составлять проекты в графическом виде – это тоже, по-большому счету, – красивая рекламная упаковка на SCADA системы. Потому что, в силу примитивности используемых в них графических языков программирования (языка релейных диаграмм [LD] или функциональных блоковых диаграмм [FBD]), ни один серьезный проект таким образом составляться не будет. Для таких случаев нужен будет опытный программист, который будет программировать путем привычного написания программных операторов в среде текстового редактора.
- В силу (как уже было сказано выше) примитивности современных языков графического программирования, современные SCADA системы предназначены для реализации достаточно простых, с функциональной степени сложности, проектов. Задачи автоматизации – как раз и попадают в такой класс сложности. Да на большее, понимая это, разработчики SCADA систем и не претендуют! А как быть с широким кругом пользователей – физиков, биологов, лингвистов, специалистов в области Искусственного Интеллекта и др. – которые тоже хотели бы строить свои проекты на понятном каждому человеку уровне графического представления проектов, не пользуясь при этом услугами, как электронщиков, так и программистов? На этот счет SCADA молчит!
----------------------------------------------------------
Можно сказать, что перечисленные выше недостатки, свойственные SCADA системам – лежат на поверхности и потому должны стать понятными широкому кругу специалистов. Но вот их источник – скрыт глубоко в недрах нынешней идеологии построения всех без исключения Систем Графического Программирования.
А источник всех проблем кроется в том, что следуя реализации насущной для общества проблемы – предоставить пользователям возможность составлять проекты в графическом виде – сами разработчики SCADA систем сами-то и не поняли, а что дальше делать с этой графикой?
Ведь ни один микропроцессор в "голом виде" никакой графики не понимает. Им подавай последовательности кодовых инструкций, а "добывать" такие инструкции человечество научилось пока только одним способом – путем компиляции или интерпретации исходных программных текстов, составленных программистом.
Вот и не придумали пока разработчики SCADA систем ничего лучшего, как вставить в свои системы программный модуль, который можно назвать – модулем графической компиляции. "Просматривая" графический рисунок проекта, он генерирует по нему исходные программные тексты, те самые, которые в противном случае, программисту пришлось бы набирать ручками. А поскольку алгоритм работы такого редактора до абсурдности прост – просматривать рисунок в направлении "слева-направо" и "сверху-вниз", то должна стать понятной и причина примитивности используемых в настоящее время языков графического программирования. Сложный рисунок никакой компилятор просто не сможет "переварить".
Недостатки такого подхода очевидны. Ведь практически с появлением первых компьютеров в мире крепло осознание того, что наиболее полным способом программирования есть представление проектов на графическом уровне. Ведь именно на этапе перехода от графики к текстовому представлению программ, теряется множество параметров функциональности, первоначально присутствующих в проекте. Чем автоматически вызываются к жизни все те недостатки, которые присущи программированию как парадигме: трудность выявления неявных признаков параллельных потоков и их синхронизацию, трудности масштабирования (разбиения большой задачи на несколько вычислителей, когда мощности одного вычислителя недостаточно) и другие.
Универсальная платформа эмуляции
Итак, система графического программирования, построенная на принципах схемной эмуляции, состоит только из двух основных компонент: графического редактора рисования схем и системы графического исполнения, работа которой, собственно говоря, и основана на принципах схемной эмуляции.
Идея использования графического редактора здесь ровным счетом ничем не отличается от уже известных. Процесс проектирования какой-либо системы управления выглядит обычно: из библиотеки компонентов выбирается графический образ какой-либо компоненты и переносится на рабочую область рисунка графического редактора. Затем компоненты соединяются между собой необходимыми цепями (линиями связи). Вот и все "программирование"!
Графический компилятор (кит №2) в такой системе отсутствует, поскольку в генерации каких-либо кодов и в дальнейшей их компилировании необходимости нет. Вместо него в графическом редакторе используется программный модуль, который "просматривает" графический рисунок проекта и по нему формирует так называемый "Файл Описания Схемы" (ФОС). Затем ФОС необходимо загрузить во встраиваемую платформу. Поскольку каждая компонента, используемая разработчиком в проекте, кроме графического образа в среде графического редактора имеет еще и программный модуль в среде исполнения, – то все задействованные в проекте модули необходимо также загрузить во встраиваемую систему исполнения.
А вот в качестве системы исполнения (кит №3) используется программный модуль Схемной Эмуляции. На этапе коммерциализации проекта он с успехом может быть размещен непосредственно на платформе и закрыт битом секретности. Поэтому продаваться такая платформа будет как законченное аппаратно-программное изделие.
В самом начале своей работы модуль эмуляции "просматривает" ФОС и разворачивает в оперативной памяти встраиваемой платформы программную модель системы управления. Входные воздействия для такой модели снимаются с реальных датчиков АСУ ТП, а отклик с программной модели подается на реальные исполнительные устройства.
Модуль Эмуляции может быть запущен и непосредственно на ПК. Тогда, чтобы превратить обычную PC платформу в платформу эмуляции, в один из PCI-слотов необходимо будет вставить интерфейсную плату стыковки.
Всю библиотеку компонентов, используемую в среде графического редактора на этапе проектирования рисунка проекта, можно условно разбить на два класса. К первому относятся те компоненты, которые отображают реальное оборудование: различные датчики и исполнительные органы, например термодатчики и реле. Ко второму – не имеющие "железного" аналога. Это чисто функциональные элементы, такие как нормализаторы сигналов, частотные фильтры, сумматоры, компараторы, логика и т.д.
Поэтому, если на схеме проекта разработчик использовал графический образ, к примеру, датчика температуры, то тогда нужно не забыть подключить соответствующий ему реальный датчик к интерфейсу контроллера.
Хочу сразу подчеркнуть, что для того чтобы максимально оптимизировать работу модуля эмуляции – микропроцессорная платформа должна иметь специальную архитектуру.
Потому и назвать ее можно – эмулирующей.
Такая платформа будет еще и универсальной, потому что по своим ценовым и функциональным возможностям, а также возможностям масштабирования, она будет годиться для использования в самом широком спектре областей: от лабораторного студенческого стенда – до АСУ ТП масштаба предприятия.
Потоковый принцип, положенный в основу работы модуля эмуляции, позволяет просто и эффективно поддерживать идеологию распределенного управления – DCS-систем (дословно – распределенных систем управления)! Причем, без дополнительной аппаратной поддержки и разработки каких-либо дополнительных программных кодов для организации межплатформенного обмена, распараллеливания потоков, их синхронизации и т.д.
Это значит, что если для загрузки проекта пользователя в платформу эмуляции, мощности одной платформы окажется недостаточной, – проблема решается простым разбиением общего рисунка на некоторое число фрагментов. Под "недостаточностью мощности" следует понимать случай, когда ресурсов одной платформы окажется недостаточным, чтобы полностью вместить в себе файл описания схемы и все процедуры, сопутствующие компонентам всего рисунка пользовательского проекта. Тогда каждый фрагмент загружается в отдельную платформу. Этап разбиения может выполняться автоматически, без участия самого пользователя. А на этапе исполнения связывание и синхронизация потоков во всех платформах будет выполняться автоматически на уровне программной модели рисунка проекта. Для организации процесса межплатформенного обмена потребуется только соединить задействованное число платформ посредством общей информационной шины или сетевого концентратора.
В то время, когда архитектура обычных микропроцессорных платформ в каждом случае проектируется под конкретное приложение или сходную группу приложений, архитектура Платформы Эмуляции "заточена" исключительно под "комфортное" размещение в ней программного Модуля Эмуляции. Всю дальнейшую "заботу" по стыковке платформы с другими платформами эмуляции и окружением периферийных устройств цифро-аналогового ввода-вывода берет на себя Модуль Эмуляции.
Таким образом, сборка любой системы конечным пользователем ведется методом "складывания" из готовых "кубиков": необходимого числа Платформ Эмуляции и модулей ввода-вывода.
Интересным представляется вариант исполнения эмулирующей платформы на основе микросхемы программируемой логики (ПЛИС). Учитывая, что алгоритм эмуляции, положенный в основу работы программного Модуля Эмуляции, построен на потоковом принципе, то среда ПЛИС, как устройства параллельного действия, является наиболее оптимальной для его размещения. В среде фон Неймана (любого микропроцессора) такая многопоточность может только эмулироваться (имитироваться).
Микросхемы ПЛИС представляют собой некоторую матрицу логических ячеек, за счет программирования и коммутации которых можно создавать аппаратные реализации различных вычислительных структур. Другими словами – это "полуфабрикат" микросхемы, внутреннюю структуру которой определяет сам пользователь.
Особенностью архитектуры эмулирующей платформы на основе кристалла ПЛИС есть то, что в распоряжение пользователя предоставляется не "голый" кристалл, который еще каким-то образом необходимо запрограммировать. А такой, в котором FPGA область уже предварительно "отформатирована" структурой Модуля Эмуляции и в которую пользователю достаточно только загрузить файл описания схемы проекта пользователя.
Для пользователя переход на такую платформу ни коим образом не станет ущербным, поскольку разработка пользовательских проектов по-прежнему будет вестись в среде того же самого Графического Редактора, а верификация – в среде того же самого Графического Визуализатора.
Преимущество очевидно: нет необходимости осваивать, к примеру, такие пакеты программирования, как MAX+PLUS II или EXCALIBUR, а значит, не надо будет осваивать и соответствующие языки микропрограммирования - AHDL, VHDL или Verylog, методы верификации проекта и т.д.
Но это - даже не самое главное в вопросе выбора аппаратного метода реализации модуля эмуляции. Главный козырь в вопросе перехода на ПЛИС платформу – существенное повышение скорости исполнения проектов и существенное повышение надежности всей системы. Что касается скорости, то тут как бы все ясно. Что касается надежности – то достаточно вспомнить о высокой зависимости любого микропроцессора от температурных режимов работы, источников питания и случайных всплесков напряжения от окружающего оборудования. Оба названных преимущества являются чрезвычайно полезными в вопросе использования эмулирующей платформы в разного рода ответственных приложениях – например, бортовых компьютерах.
Идея масштабирования для DCS- систем применительно к вопросу проектирования эмулирующей платформы на основе ПЛИС особо подчеркивает красоту и высокую функциональность идеи схемной эмуляции. Ведь проектирование больших решающих полей на нескольких микросхемах программируемой логики традиционными способами является достаточно сложной задачей, требующей преодоления ряда проблем. Одна из которых – т.н. негативный эффект страниц, возникающий на стыках отдельных кристаллов программируемой логики. Но без ее разрешения не обойтись, когда приложение (задача) пользователя по своему объему превышает ресурсы одного кристалла.
Ситуация существенным образом меняется, если в основу функционирования ПЛИС – платформы положить авторский модуль схемной эмуляции, по своей сути который выполняет роль цементирующей среды для всех "ПЛИС – кирпичиков".
Положительный эффект здесь достигается тем, что объединение фрагментов схемы проекта пользователя, разнесенного по нескольким микросхемам программируемой логики, осуществляется не на физическом уровне (как в случае традиционного программирования), а на уровне программной модели всего проекта.
Представляется естественным первоначальную разработку платформы эмуляции выполнить на стандартных микросхемах ПЛИС. В дальнейшем, следуя активно развиваемой в настоящее время идеологии SoC (Sistem on Chip), станет целесообразной разработка специализированной микросхемы, архитектура которой будет полностью "заточена" под Систему Эмуляции. Это уже позволит говорить об эмулирующем кристалле, а не платформе. Скажу более того, что фирма, реализовавшая такой проект, совершит революционный прорыв в вопросе превращения микросхем программируемой логики в по-настоящему массовый продукт, поскольку овладеть работой с таким кристаллом под силу будет даже школьникам. Реализация идеи, с одной стороны, будет ценна для использования в том сегменте рынка, где сейчас используются системы на базе 8- и 16- разрядных микропроцессорных контроллеров. С другой – при организации мощных вычислительных матриц.
Принципы схемной эмуляции, положенные в основу работы Системы Эмуляции, позволит без проблем организовать этапы тестирования и верификации отлаживаемых проектов. Для этого достаточно будет подсоединить ПК к платформе на время отладки. А программа-визуализатор, установленная на таком ПК, позволит отображать уровни сигналов в любых ветвях схемы проекта.
Осталось только дело за фирмой, которая возьмется за коммерциализацию данного проекта.
Область применения Платформы Эмуляции уже сегодня видится мне для достаточно широкого круга приложений, к примеру:
- комплексы диагностики, сбора и обработки информации;
- системы автоматики и АСУ ТП масштаба предприятия;
- бортовые системы управления;
- системы диспетчеризации и принятия решений;
- организация мощных вычислительных матриц;
- универсальная среда проектирования нейрокомпьютеров;
- проектирование интеллектуальных систем нового поколения:
Экспертных Систем, систем понимания, машин Баз Знаний и других направлений
Искусственного Интеллекта (ИИ);
Как видно из приведенного списка, Универсальная Платформа Эмуляции рассчитана на применение в достаточно широком спектре приложений, но, по большому счету, она может быть применена везде, где необходимы какое-то управление, вычисление или моделирование процессов (вернее даже сказать – их эмуляция в режиме реального времени).
Ниже в статье будет уделено внимание рассмотрению той идеи, что проектирование по настоящему сложных систем станет возможным благодаря, во-первых - возможности разработки пользовательских проектов на уровне Систем и во-вторых – непосредственному и совместному участию в проектах специалистов разных специальностей без посредничества программистов, когда графический язык проектирования уровня структурных схем станет основой не только самих проектов, но и языком межпрофессионального общения.
Преимущества эмуляции
Итак, принципиальное различие между известными системами графического программирования (ниже, для краткости, – Систем Программирования) от системы, основанной на принципах схемной эмуляции (Системы Эмуляции), состоит в том, что в последней – отсутствует этап генерации исходных/исполняемых кодов с последующими этапами их компиляции или интерпретации.
Это явный признак, который "лежит на поверхности". Тем не менее, именно идея отказа от всякого рода кодов и работа Системы Исполнения непосредственно по рисунку проекта – служит источником большого числа положительных возможностей, которые принципиально недоступны Системам Программирования. А именно:
1) Система Эмуляции позволяет проектировать на уровне Структурных Схем;
Не лишним будет еще раз напомнить, что работа любого графического компилятора в графических Системах Программирования состоит в просмотре рисунка проекта (притом, достаточно тривиальным способом, в порядке - "слева-направо" и "сверху-вниз") и генерации по нему программных кодов. А раз мы возвращаемся к программированию, то совершенно очевидно, что на каком бы графическом языке мы не рисовали схему - будь-то язык последовательных функциональных блоков (SFC), релейных диаграмм (LD) или функциональных блоковых диаграмм (FBD) - она непременно будет приведена к обычному рисунку алгоритма программы.
Иначе никакой компилятор или интерпретатор не сможет ее обработать, другими словами, - привести к последовательности программных операторов исходного, промежуточного или исполняемого кода. Поэтому назовем, для краткости, такой уровень графического представления проектов – Уровнем Алгоритмов.
Графическое программирование для Системы Эмуляции может быт выполнено на уровне языка Структурных Схем (СС). Такой язык обладает гораздо большими функциональными возможностями по отношению к Уровню Алгоритмов и по сложности он соответствует уровню разработки электронных систем при системотехническом проектировании. Назовем такой уровень представления проектов – Уровнем Систем.
Средой, в которой проекты такого уровня могут быть исполнены, может быть исключительно среда программы схемной эмуляции, но никак не среды компилирования или интерпретации.
К тому же, проектирование на уровне структурных схем позволит поднять степень представления рисунков проектов на более высокий уровень, действительно понятному самому широкому кругу специалистов. Потому что, будучи даже графическими, такие языки как SFC, LD или FBD - все равно остаются языками программирования (да еще и с ограниченными возможностями) и требуют участия в проекте программиста.
Ниже я попытаюсь показать, что язык СС – соответствует более высокому уровню представления проектов, чем Уровень Алгоритмов и что CASE - SoftLogic системам вообще не под силу компиляция и исполнение проектов, представленных на уровне СС.
Для этого, для начала, выделю всего три параметра определения сложности графической схемы. Это - наличие и вид обратных ветвей (цепей, связей) примененных в проекте, сложность временных соотношений сигналов в разных ветвях рисунка проекта по отношению друг к другу, а также сложность вида сигналов в каждой отдельной ветви.
обратные связи и их виды
Обратные связи (ОС) – есть важнейший атрибут любых проектов, составленных в виде принципиальных, функциональных или структурных схем. Существуют ли обратные связи в программировании? В общепринятом смысле – их там нет! То, что обычно можно увидеть на рисунках алгоритмов программ, приближенно напоминающих обратные связи, – это всего лишь изображения т.н. циклов. Примеры, характерных для программирования видов циклов, приведены на рис.1а, б.
Они наглядно демонстрируют, что ветви a, b и c – это т.н. "указатели" на адрес компоненты, с которой программу следует повторить, пока в компонентах k2, k5 и k6 (соответственно) будут соблюдаться определенные условия.
Указателями такие ветви называются потому, что всего лишь соответствуют команде на загрузку в регистр адреса процессора адреса команды, с которой последовательное выполнение некоторой цепочки программных операторов будет повторена.
Но всякие ли даже циклы способны "переварить" современные компиляторы? Под словом "переварить" следует однозначно понимать ситуацию, когда, встретившись с такой "штукой", каждый из них будет в состоянии ее распознать и грамотно вставить сгенерированный блок операторов в тело программы. Оказывается, что современные компиляторы в состоянии распознать и закодировать только простые и вложенные циклы, подобно изображенным на рисунке 1а и 1б.
А все от того, что основной принцип программирования для архитектуры фон Неймана гласит, что прерывания для процессора могут быть только вложенными. Потому как внутри самих процессоров они реализуется стековыми регистровыми структурами.
рис. 1а Простые циклы.
рис. 1б Простые вложенные циклы
Поэтому абсолютным нонсенсом, с точки зрения программирования будет выглядеть, к примеру, проект, содержащий т.н. перекрестные обратные связи, изображенные на рис. 2.
a)
б)
рис. 2 а, б Примеры перекрестных обратных связей.
Принцип схемной эмуляции, конечно же, не нарушает основополагающих принципов программирования, свойственных архитектуре фон Неймана, но он позволяет смоделировать среду, в которой такие "нарушения" имитируются.
Я употребил слово "имитировать" потому как любая программа, в том числе и схемной эмуляции, попав в среду современных процессоров, должна мириться с ее особенностями – регистровой структурой – идеологией, которая остается неизменной на протяжении всей истории ее существования.
Это касается случая, когда Модуль Эмуляции будет запущен на PC- или иной микропроцессорной платформе. К тому же, скорость эмуляции в этом случае будет соизмерима со скоростью исполнения обычных программ, что годится для случая управления относительно медленными технологическими процессами.
Понятно, что "родной" для него средой, в которой ему не надо будет чего-либо "нарушать" может быть среда микросхемы программируемой логики.
учет временных соотношений сигналов в цепях проекта
Как уже много раз подчеркивалось мною в этой статье, все проекты, представленные на каких-либо известных графических языках Систем Программирования непременно сводятся к простому списку программных операторов, которые могут быть исполнены процессором последовательно.
Поэтому, первейшей задачей любого графического компилятора в СП является определение порядка размещения программных модулей (Mn) в теле программы, согласно связям (ветвям) соединяющих графические образы соответствующих им компонент (Kn) на рисунке проекта.
К примеру, на рис. 3а представлена схема проекта на уровне языка FB. На рис. 3б представлен вариант ее программной реализации, представленной в виде последовательности сгенерированных компилятором программных модулей.
Рис. 3а Проект системы содержащий параллельные ветви
Рис. 3б Порядок выполнения программных модулей для рис. 3а.
Графические Компиляторы в Системах Программирования просматривают схему (рисунок) проекта по правилу: "слева – направо", "сверху – вниз". В результате - формируется статическая цепочка программных модулей исходных кодов. И ситуация здесь может доводиться до абсурда: когда вид сгенерированного программного кода может зависеть даже от места расположения определенной компоненты на экране дисплея!!! Этим недостатком графических компиляторов умело пользуются, к примеру, программисты, поднаторевшие в среде IsaGraf.
Как показано на рис. 3б, модуль М3 может быть расположен только в конце тела программы, поскольку оба входных его параметра (идентификаторы -, ) должны быть определены к началу его исполнения.
О какой же динамичности процессов в таком случае может идти речь?
В свою очередь, в Системе Эмуляции вычисление значений в каждой ветви рисунка проекта осуществляется параллельно, соблюдая при этом всю динамику распространения процессов между ветвями. Если проектирование системы управления будет вестись на уровне Структурной Схемы (уровне систем), то в проект, представленный на рис. 3а может быть вложен совершенно другой смысл, к примеру, как на рис. 4. Здесь подразумевается, что при изменении сигнала на входе компоненты К1 с уровня логического нуля ("0") до уровня логической единицы ("1"), на выходе К3 формируется строб (импульс).
Рис. 4 Фрагмент проекта на уровне структурной схемы (уровень системы)
Приведенный на рис.4 фрагмент наглядно показывает, что сложный во времени вид сигнала на выходе компоненты К3 может формироваться в результате "гонки" сигналов, проходящих одновременно по параллельным ветвям 1 и 2 схемы, что есть совершенно нормальным явлением для уровня схем электронных систем. Но представляется абсолютным нонсенсом для схем алгоритмов, составленных в среде Систем Программирования.
Сложный вид сигналов в Системах можно получить не только путем организации гонок сигналов по разным цепям, но и применением обратных связей на одной компоненте, как это показано на Рис. 5
Рис. 5 Фрагмент структурной схемы представленной на уровне СС.
Формирования строба – пример, конечно, частный и примитивный. Но сама идея учета временных соотношений сигналов между различными ветвями схемы проекта может с успехом применяться, к примеру, в цепях селекции паттернов (цепочек импульсов) тех же самых нейронных сетей.
сложный вид и природа сигналов в каждой цепи
Программные переменные (идентификаторы), используемые в Системах Программирования, ни коим образом не привязаны к ветвям алгоритма. Располагают их в отдельных частях программы - области описания идентификаторов, а при исполнении этой самой программы каждому из них выделяется отдельная область оперативной памяти. Управляются (изменяются) идентификаторы изнутри программных модулей.
И даже тогда, когда идентификатор – не константа, а описывает какую-либо переменную (например, температуру в объекте управления) – природа его все равно остается достаточно статичной. Потому что за один цикл любой программы - "считывание сигналов с датчиков обработка входных сигналов по определенному алгоритму формирование управляющих сигналов на исполнительные органы" - он (идентификатор) может быть изменен программой только один раз и только из одного места.
Потому как современные языки программирования не позволяют иного, а нарушение этого правила может привести программу в непредсказуемое состояние, другими словами – к аварии.
В Системе Эмуляции любая программная переменная строго привязана к определенной ветви рисунка и за полный цикл эмуляции может гарантированно изменяться столько раз, сколько этого будет требовать логика работы спроектированной схемы.
В то же время, кардинальным отличием Системы Эмуляции от всех известных Систем Программирования является способность работать с такими атрибутом схем как сигнал.
В течении полного цикла эмуляции сигналы могут перемещаться по ветвям рисунка проекта ( как на рис. 4). Естественно, что поскольку каждый сигнал перемещается по своей цепи, то на определенных компонентах схемы могут быть выявлены сколь угодно сложные их смещение друг относительно друга. Все это – и служит источником формирования сигналов любой по форме сложности.
Более того, в Системе Эмуляции самим компонентам разрешается генерировать сигналы любой формы сложности, как, например, паттерны - для случая нейронной сети. Или последовательности импульсов - для случая генератора тактовых импульсов.
Особо подчеркну, что Системе Эмуляции под силу так называемое многозначное кодирование состояний сигналов в ветвях схемы. Это значит, что по ветвям графической схемы проекта могут передаваться не только сигналы дискретной логики или аналоговые сигналы, но также значение импеданса и т.д. Что является чрезвычайно полезным при проектировании, опять-таки, нейронных структур, а также – организации двунаправленных потоков данных.
Более того, в Системе Эмуляции допускается многовекторность сигнала в каждой цепи!
Под этим следует понимать, что по одной и той же цепи могут одновременно передаваться как уровни аналогового сигнала, так и дискретного. Реализация такого наложения (модуляции) может стать весьма полезной, к примеру, при проектировании таких систем – как тех же самых нейронных сетей.
Все это дает разработчику возможность разрабатывать в среде эмуляции не только простые алгоритмы управления, соответствующие уровню Систем Программирования, но и представлять проекты на системном уровне в виде Структурных Схем.
2) Простое распараллеливание и синхронизация процессов;
При традиционном программировании на программиста возлагается задача выявления всех параллельных участков в программе и организации процесса синхронизации всех ее ветвей посредством, к примеру, механизма семафоров. Практически с появлением первых языков параллельного программирования возникло и стремление как можно больше таких операций переложить на компилятор, уменьшив, таким образом, зависимость этапа программирования от субъективного фактора (читай – программиста).
Тем не менее, задача эта еще настолько далека от окончательного разрешения, что ей можно было бы еще уделить тома трудов и годы работы… если бы не рождение идеи использования схемного эмулятора как среды исполнения. Именно эта идея все потуги по развитию инструментария параллельного программирования превратила в бессмысленное занятие, потому что всех тех проблем, которые свойственны традиционным системам, в ней просто не существует.
В принципе, можно сказать, что отличительной чертой любого схемного симулятора от обычных программ есть: во-первых – работа непосредственно по графическому рисунку схемы и, во-вторых, - формирование всех параллельных потоков в программной модели устройства, с соблюдением условий распространения сигналов в ветвях рисунка проекта.
Авторская программа схемной эмуляции отличается от обычных симуляторов еще и тем, что делает все это в режиме реального времени и реальном окружении периферийной среды.
3) Простое масштабирование;
Под масштабированием следует понимать возможность наращивания суммарной мощности системы эмуляции путем простого добавления в нее некоторого числа однотипных плат – Универсальных Платформ Эмуляции.
Идея масштабирования в Системе Эмуляции основана, всего лишь (!), на механизме разбиения рисунка проекта на фрагменты и размещения каждого такого фрагмента в отдельной платформе.
Хотелось бы указать на три варианта фрагментации:
вариант первый – "фрагментация вширь". Это случай, когда один большой проект условно делится на N частей, каждая из которых, к примеру, будет локально управлять своим объектом (рис.6).
Рис. 6 Фрагментация рисунка проекта "вширь"
В этом случае графический рисунок алгоритма управления разбивается на фрагменты и каждый фрагмент размещается на отдельной платформе. Каждая платформа управляет локально только тем станком, алгоритм управления которым соответствует фрагменту рисунка в нее загруженному. И все! Межплатформенный обмен синхронизирующими сигналами по сетевому интерфейсу организовывается Системой Эмуляции автоматически и основывается на естественном принципе многопоточности алгоритма эмуляции.
Еще раз подчеркну, что Система Эмуляции, находящаяся в среде фон Неймана
(микропроцессорной платформе), только имитирует всякую параллельность. Тем не менее, уже это позволяет реализовать распараллеливание процессов, не прибегая к традиционным методам организации межпроцессорного обмена и синхронизации процессов (использования разного рода "флагов", "семафоров" и т.п.).
Современным Системам Программирования такое не под силу. В случае распараллеливания общего процесса всю "графику" необходимо отложить в сторону и "вручную" (средствами языков программирования) разрабатывать программное обеспечение межпроцессорного обмена и синхронизации процессов.
вариант второй - "фрагментация вглубь". Это соответствует случаю, когда ресурсов
одной платформы недостаточно для размещения в ней всего алгоритма управления
одним объектом управления (станком). В этом случае общий рисунок проекта, опять же,
разбивается на фрагменты, каждый из которых загружается в отдельную платформу. Все
платформы, в этом случае, находятся на одном объекте управления и физически также
объединены с помощью сетевого интерфейса (рис. 7).
Рис. 7 Фрагментация рисунка проекта "вглубь"
вариант третий - смешанный, когда задействованы одновременно оба предыдущих варианта.
4) Система Эмуляции – это, по сути, "машина потоков";
Механизм масштабирования, приведенный выше, основывается на естественном принципе алгоритма эмуляции – многопоточности.
Многопоточность процессов поддерживается как на уровне самой платформы, так и вне ее. Примеры рассмотренные на рис. 6 и 7 касаются как раз второго случая, которое назовем – межплатформенной многопоточностью. Тогда принцип многопоточности в пределах самой эмулирующей платформы можно назвать – внутриплатформенной многопоточностью.
И если во втором случае разделение ресурса программной модели проекта пользователя происходит на межплатформенном уровне, то в первом – может быть использовано на межпроцессорном уровне самой платформы. Данное свойство Системы Эмуляции может с успехом быть использовано при создании мультипроцессорной системы.
Выше я уже говорил, что программные симуляторы не нарушают основополагающих принципов программирования, свойственных архитектуре фон Неймана, но они определяют среду, которая позволяет имитировать такие "нарушения".
Поэтому, для полного раскрытия свойств алгоритма эмуляции – многопоточности процессов, – необходимо поместить его в "родную среду". Под этим словосочетанием следует понимать, что речь идет про среду, в которой алгоритм эмуляции будет реализован на аппаратном уровне.
Сделать это можно либо использовав заказные микросхемы, что есть чрезвычайно дорогостоящий путь, либо использовав микросхемы так называемой программируемой логики.
Микросхемы ПЛИС со структурой FPGA подходят для этих целей наилучшим образом, потому как изначально являются устройствами параллельного действия и поэтому наилучшим образом соответствуют реализации концепции потоков.
Таким образом, центральным элементом такой платформы будет являться микросхема программируемой логики, в которую аппаратно прошит модуль схемной эмуляции. Разворачиваемая им в среде той же микросхемы программная модель проекта пользователя формирует множество потоков, которые, собственно и управляют порядком обработки компонент графической схемы проекта.
На множество процессоров, находящихся на такой платформе, будет возлагаться только выполнение элементарных арифметико-логических операций над операндами, подаваемых на их входы вместе с потоками программной модели.
Для роли наиболее подходящего звена, связующего потоки программной модели с процессорными элементами, подходит сетевой концентратор (switch), который по своей природе также является устройством параллельного действия.
Реализованная на таком уровне эмулирующая платформа будет лишена фоннеймановских атрибутов: раздельного хранения команд и данных, счетчика команд и многочисленных регистров процессора, а значит и последовательного выполнения команд.
Среда, в которой порядок выполнения задачи пользователя определяется не счетчиком команд, а движением потоков данных в программной модели задачи пользователя, придает архитектуре платформы эмуляции все атрибуты машины потоков.
Здесь нелишне было бы напомнить, что мировое развитие теории и практики машин потоков данных, так и не вышло дальше экспериментальных образцов. Причиной этому стало упорное стремление сохранить такую архитектуру, в которой программа пользователя представляла бы собой последовательную запись команд, пусть даже управляемую данными, а не счетчиком команд, как в среде фон Неймана.
В данной статье приводится описание машины потоков, построенной на принципах схемной эмуляции, и показывается, что такая архитектура свободна от недостатков, свойственных машинам потоков традиционной архитектуры.
5) Отсутствует эффект "узкого горлышка" для мультипроцессорных систем;
Под этим термином в вычислительной технике подразумевается эффект ограничения мощности мультипроцессорной системы, приводящий к замедлению ее работы, вызванный ограниченной пропускной способностью канала память – процессоры. Из-за этого эффекта решение мультипроцессорной обработки, в традиционных вычислительных системах, приводит лишь к частичному успеху. Согласно гипотезе Минского (Minsky), ускорение, достигаемое при использовании параллельной системы, пропорционально двоичному логарифму от числа процессоров. То есть, при использовании 1000 процессоров на одной платформе возможное ускорение оказывается равным всего 10 (!).
Мультипроцессорная система, построенная на принципах схемной эмуляции, свободна от этого недостатка, потому что, как об этом уже не раз говорилось, центральным местом архитектуры системы эмуляции является программная модель пользовательского проекта, основанная на принципах многопоточности. В среде аппаратной реализации авторского модуля эмуляции – микросхемы программируемой логики – такая много поточность трансформируется в потоки непересекающихся сигналов, каждый из которых посредством сетевого концентратора (являющегося по своей природе также прибором параллельного действия) "находит" свободный процессорный элемент.
Процессоры в архитектуре платформы эмуляции не управляют процессом обработки информации, а лишь реализуют операции над поступающими на их входы операндами.
При такой архитектуре возможна лишь обратная ситуация, когда количество активированных потоков, в какой-то момент времени, окажется больше числа свободных процессоров. В таком случае на уровне программной модели всего-лишь произойдет "притормаживание" некоторых связанных процессов до появления свободного процессорного элемента.
6) Существенно повышается надежность управляющих систем;
Напомню, в начале статьи говорилось, что результатом совместной работы заказчика с технологом является некий алгоритм, представленный в виде графического рисунка или словесного описания – что выступает основой документа, называемого техническим заданием. Программисту необходимо проделать неформальную операцию перевода этого документа в язык машинных кодов – программного продукта предоставляемого заказчику.
До чего доводит такое "неформальное" участие – также говорилось. Резюмирую это только одной фразой – наличием практически в любом ПО, выдаваемого заказчику, скрытых ошибок. Ошибок, которые не удалось выявить на этапе разработки и тестирования.
К чему приводит наличие скрытых ошибок тоже говорилось. К тому, что "местами" программа может работать не так, как изначально было задумано.
Надежность проектов, разработанных на уровне Системы Эмуляции, повышается в сравнении с проектами, разработанными в среде Систем Программирования благодаря следующему:
- проект разрабатываемой системы создается в рисунке непосредственно прикладным специалистом - технологом, химиком, физиком, биологом и т.д.;
Это позволяет, наконец-то, реализовать во всей красе давнюю мечту проектировщиков о единой спецификации проекта в цепочке всех специалистов, участвующих в реализации проекта.
Возможность составлять проекты исключительно в виде графических схем и позволит представителям различных профессиональных групп работать с единой сквозной документацией и однозначно понимать друг друга.
Проектирование систем на уровне рисунков функциональных, структурных и прочих схем - более информативно, наглядно, понятно всем и позволяет быстрее провести разработку.
Система Эмуляции рассчитана на конечных пользователей совершенно не владеющих какими-либо языками программирования и требует от них только способности выразить свои мысли в рисунке проекта на функциональном уровне.
