Проект "пульс": (описание идеи)
| Вид материала | Программа |
- Программа «Школа волонтеров Пульс», 453.36kb.
- Проект посвящен вопросам эксплуатации кц-1 кс «Игринская», 23.57kb.
- Как начинается проект?, 59.12kb.
- Настоящий Проект перспективного развития школы на 2011-2015 годы продолжает основные, 711.77kb.
- Тематическое планирование уроков в 7 классе, 894.98kb.
- Описание современной модели доступного и качественного образования в Хабаровском крае, 55.82kb.
- Конкурс инновационных проектов «Новый Алтай», 29.46kb.
- Анализ требований к проекту сайта (см табл. 9) 18 Согласование выработанной идеи проекта, 590.25kb.
- В. А. Заботина Утверждаю Начальник своуо в. Г. Кобозева Положение конкурс, 38.14kb.
- Программа производства и сбыта Формирование каналов сбыта продукции. Разработка мероприятий, 1030.06kb.
Ковалев Сергей Эдуардович, г. Киев simula@ukr.net
ИННОВАЦИОННЫЙ ПРОЕКТ - "ПУЛЬС":
(описание идеи)
Система графического программирования - исполнения,
построенная на принципах схемной эмуляции
&
Универсальная платформа эмуляции алгоритмов и систем
&
Архитектура потоковой суперЭВМ построенная на принципах схемной эмуляции.
Сравнительный анализ
с известными архитектурами.
Содержание статьи:
стр.
■ Аннотация ….. 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 платформ на физическом уровне организуется по сетевому интерфейсу.
И во-вторых, составление любых проектов пользователь выполняет исключительно в графическом виде, путем рисования в среде графического редактора схем алгоритмов, графов, структурных схем и т.д. Пользователь полностью освобожден от пользования какими-либо языками программирования, а значит, и от каких-либо инструментальных средств проектирования и отладки программ.