Проект "пульс": (описание идеи)

Вид материала

Программа

Содержание Схемная эмуляция и автоматное программирование Рис. 9 Схема цифрового автомата2-й

Подобный материал:

• Программа «Школа волонтеров Пульс», 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.

- никакого исходного кода, в котором можно "закопаться", а значит и "скрытых" ошибок

программирования (!);


- простая верификация проектов;

Для верификации проекта достаточно будет к эмулирующей платформе (или сети платформ)

подключить ПК с программой визуализации.

В этом случае, на экране монитора, можно будет как в режиме реального времени, так и

пошаговом – просматривать временные диаграммы уровней реальных сигналов в любых цепях

рисунка проекта;

- отсутствуют такие явления свойственные программированию как "зависание" программы или

"сбой";

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

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

Если предположить, что в программе используются только двоичные управляющие переменные (флаги), то в этом случае количество состояний будет стремиться к 2ⁿ. Поэтому нет никакой гарантии, что в процессе работы программы не возникнет неожиданное сочетание входных воздействий, тогда программа перейдет в непредусмотренное состояние.

Системе Эмуляции все это не свойственно. Просто потому, что из нее исключен как программист, так и сами программные коды!

- идентификаторы строго привязаны к ветвям рисунка проекта;

Программные переменные (идентификаторы), используемые в Системах Программирования, ни коим образом не привязаны к ветвями алгоритма, а управляются изнутри программных модулей. Располагают же их в отдельных частях программы - в области описания идентификаторов, а исполняет их программа, которая и выделяет каждому из них отдельную область оперативной памяти. Именно этот факт является источником многих ошибок в программировании, потому как позволяет случайно изменить любой идентификатор из любого места программы.

Еще одной типичной ошибкой является обращение к переменной, значение которой не определено или не установлено в данный момент. Все это усложняет этап локализации ошибки.

К тому же, сам факт раздельного хранения команд и данных в архитектуре фон Неймана нарушает главный принцип любой программы – понятие процесса как неделимого целого. Бороться с этим явлением пытались еще на заре компьютерной техники. Одним из путей решения проблемы было предложение перехода к другим архитектурам, в частности, - машинам потоков данных.


Система Эмуляции лишена упомянутых выше недостатков: любая программная переменная или константа строго привязана к определенной ветви рисунка проекта, что позволяет эффективно реализовать принцип распараллеливания потоков и их синхронизацию.

- идея эмуляции органично стыкуется с идеей т.н. SWITCH- программирования;

В самом начале статьи я уже упоминал, что в течении долгого времени программирование обращалось за примерами организации программ к другим инженерным дисциплинам и прежде всего к проектированию электроники. Потому что давней мечтой всех заказчиков и разработчиков ПО была та, чтобы программы работали так же надежно, как и электронные системы. Отсюда и постоянное стремление заимствовать организацию разработок и проектирования устоявшихся в индустрии электроники, а также внедрение формальных методов в технологию программирования.

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

Тут должна стать понятной ценность концепции, что графы переходов автоматов Мура-Мили прекрасным образом имеют изоморфность с обычной SWITCH структурой языка Си, или подобными структурами в любом другом языке программирования

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

Предлагаемая концепция проектирования получила название "автоматного проектирования" и позволяет максимально подробно описывать процессы, которые необходимо автоматизировать, используя при этом формальный язык конечных автоматов. Более того, предлагается четкий и универсальный метод описания, единый для всех стадий проектирования.

В то же время, все то, что было написано мною в этой статье – подчинялось одной идее – показать, что "исходным кодом" для Систем Эмуляции служит графический рисунок проекта! И совершенно неважно, в каком виде он представлен – в виде принципиальной схемы, составленной из цифровых компонент, схемы релейной логики, функциональных блоков, алгоритма управления или структурной схемы проекта.

И в этом смысле представление проекта пользователя в виде графа переходов автоматов Мура-Мили – есть такой же равноправный вид представления проектов, как и все только что упомянутые.


Поэтому вся красота соединения идеи эмуляции и теории автоматов состоит в том, что по окончании проектирования схемы графа переходов совершенно нет необходимости браться за написание программных SWITCH структур - а достаточно просто эмулировать спроектированный граф автомата!!!


7) Позволяет эффективно реализовать систему проектирования и исследования

нейросетей;


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

Такие системы строятся на разного рода скалярных, векторных или сигнальных процессорах. Они достаточно дороги, малодоступны, сложны в освоении и, самое главное, - вряд ли позволят разрешить все проблемы, стоящие перед биологами.

Применение идеи эмуляции к данной теме открывает принципиально новый путь к ее разрешению, потому что позволяет конечному пользователю просто рисовать исследуемые сети. Конечно, нарисовать сеть, состоящую из сотен, тысяч или миллионов нейронов (и большем их числе) – вряд ли представляется возможным. Да этого и делать не надо! Достаточно только создать программные модели используемых в сети типов нейронов и внести их в библиотеку компонентов системы графического программирования. Далее, не вижу принципиальных трудностей, чтобы создать программу, которая автоматически станет генерировать структуру рисунка, используя в качестве исходных данных задание, составленное биологом, на структуру сети и перечень используемых в ней типов нейронов.

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


8) Возможность проектирования саморазвивающихся систем;


Уверен, что в настоящее время вряд ли у кого может вызвать сомнение, что интеллектуальные системы, вроде Экспертных, машин Баз Знаний и других направлений Искусственного Интеллекта могут быть реализованы на должном уровне только при условии, что будут обладать механизмом самообучения.

Современные же программы – это "статический" слепок некоторого алгоритма, который программист в нее вложил. Такие программы никогда не станут умнее своего создателя, потому что исходно не обладают механизмом к саморазвитию. Достаточно длительный этап попыток разрешить проблему проектирования интеллектуальных систем путем развития механизмов вроде эвристик, логики предикатов, нечеткой логики и даже объектно-ориентированного программирования – показал всю несостоятельность подхода.

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

С другой стороны, проведение разработок на уровне схем графических проектов даст возможность участвовать в процессе одновременно специалистам самых разных областей знаний, потому что именно графический способ представления проектов является настоящим языком меж-профессионального общения.

Нет необходимости говорить о важности работ по реализации данного проекта. Потому что на этот раз магическим инградиентом успеха являются знания – "черное золото" – самая мощная скважина ближайшего времени. Они оттеснили землю, труд и капитал, заняв место наиболее важного ресурса современного производства. Знания снижает потребность в земле, труде и капитале, уменьшают расход сырья и энергии, вызывают к жизни новые производства.


9) Единая среда разработки;

Не важно, для какой платформы выполняется разработка проекта – микропроцессорной, на базе ПЛИС или непосредственно PC – пользователь будет работать в среде одного и того же графического редактора, и просматривает процесс эмуляции в среде одного и того же визуализатора.

Нет необходимости осваивать программирование микропроцессоров или учить языки программирования типа AHDL или VHDL для микросхем программируемой логики.

К тому же, никаких средств отладки микропроцессоров, несчетного числа дорогостоящих внутрисхемных эмуляторов и т.д. и т.п.


10) Низкая цена разработки и внедрения проектов;

Такое утверждение основано на свойстве универсальности эмулирующей платформы и отсутствием программирования.

Универсальность обеспечивается тем, что такая платформа годится для самого широкого круга задач: от простейших комплексов сбора и обработки информации - до АСУ ТП масштабов предприятия. От одноплатформенных – до мультиплатформенных сосредоточенных и распределенных систем.

Может с успехом использована школьниками, студентами, инженерами и научными работниками совершенно разных направлений.

Годится для использования от создания лабораторного студенческого стенда - до проектирования любых приложений в области Искусственного Интеллекта. Для создания систем управления (контроллера) стиральной машины и бортовых систем управления.

Относительно невысокую цену на такую систему можно объяснить отсутствием затрат на программирование, массовостью применения (широким кругом решаемых задач) уже готовой платформы, а также применением одних и тех же стандартных (аппаратно-программных) периферийных "кубиков" ввода-вывода сигналов.


11) Возможность эмуляции сложных аппаратно-программных систем еще на стадии

разработки


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

Наверно я не ошибусь, если скажу, что история создания и использования таких систем длится уже более полувека (!), но что самое удивительное – они так и остались системами симуляции электронных устройств в масштабах кристалла или электронной платы.


Представляемая же в этой статье система эмуляции Пульс позволяет выйти за пределы отдельных кристаллов и плат. А также, использовать реальные сигналы ввода-вывода в моделях проектов, проводить эмуляцию (проверки работы в режиме реального времени) сложных аппаратно-программных комплексов находящихся еще на стадии разработки ("рисунков") – от систем управления работой стиральной машины – до бортовых систем управления.


12) Во всей красе позволяет реализовать идею о "единой спецификации проекта"

Система Эмуляции прекрасным образом, наконец-то(!), позволяет реализовать давнюю мечту проектировщиков систем о единой спецификации проекта. Теперь это стало реальным, поскольку в ней, в силу полного отсутствия какого-либо программного кода, разработка любого проекта проводится только на уровне рисунков.

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


13) Прекрасным образом способствует решению проблемы: "Движение за открытую проектную документацию";

Что означает "Движение за открытые исходные тексты" ("Open Source Software") представлять, думаю, никому не надо. Смысл такого движения понятен уже из самого его названия. Но проблема кроется в том, что сегодня уже и этого мало. Объемы программ настолько выросли, что разобраться в любой из них, ковыряясь в мегатоннах исходных текстов, - просто невозможно. В этом случае все проектные решения, задуманные автором проекта, просто растворяются в деталях кодирования. И проблема эта нарастает экспоненциально росту объема кода.

Выходит, что без исходных кодов плохо, но и с ними не очень хорошо. Чего не хватает для счастья? Проектной документации!

В многочисленных статьях, посвященной данной проблеме и путям ее разрешения, не редко проскакивает мысль – вот умеют же выпускать документацию к электронной аппаратуре!


Вот я и задаюсь вопросом - зачем же тратить огромные усилия на поиск какой-то чудо - методики, которая якобы позволит, наконец, решить проблему проектирования программ и выпуска хорошей документации к ним? И которая, еще не известно, будет ли найдена!?


Зачем изобретать велосипед, если он уже давно изобретен и с успехом используется? Это – методики проектирования электронных систем, на которые так любят ссылаться сами же программисты.


Поэтому программы нужно не писать, а проектировать. Так, как сейчас разрабатываются электронные системы – на уровне функциональных и структурных схем. И тогда с программированием ситуация окажется даже более простой и приятной, чем с самой электроникой: начинаться и заканчиваться разработка будет исключительно на рисунках проектов. И нет необходимости "браться за паяльник" и производство печатных плат - потому как Система Эмуляции оживит любой проект, реализованный только до уровня документации.


Схемная эмуляция и автоматное программирование

(система автоматного программирования, построенная на принципах

схемной эмуляции)


В данном разделе рассматривается идея применения принципов схемной эмуляции применительно к "автоматному программированию". Что позволит отказаться от используемого сегодня принципа генерации С-кодов по графу автомата (с последующей их компиляцией в исполняемые коды), а просто эмулировать саму схему графа.

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

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

Но для начала – несколько слов о самой сути т.н. автоматного программирования.

Выше много уже говорилось, что при написании программ программисту каждый раз необходимо выполнить неформальную операцию перевода словесной или графической формы технического задания в язык машинных кодов. Неформально – это значит творчески. А "творчески" означает, что качество такого перевода будет напрямую зависеть от того, насколько он понял задание, а также его профессионального уровня. Но даже с одним профессиональным уровнем два разных программиста напишут разные коды, потому как программирование пока еще есть искусство.

К тому же, как всякий живой человек, он имеет право на ошибки, а поиск ошибок – дело трудоемкое. А если учесть, что никто лучше не сможет разобраться в программном творении, чем сам исполнитель, то можно понять остроту организационных проблем, если специалист решит уволиться в разгар проекта. Вот и пересказу конец.

Как избежать всех этих ужасов? Одной из панацей считается применение ФОРМАЛЬНЫХ методов проектирования программ. Что касается сегодняшнего состояния дел в этом направлении для задач логического управления, то значительный вклад в решение обозначенных выше проблем уже проделан путем переноса достижений теории конечных автоматов на область программирования.


Каким образом теория автоматов может иметь отношение к программированию? Чтобы понять это, достаточно вспомнить общеизвестный факт, что любой алгоритм управления может быть реализован как программно, так и аппаратно. Этот принцип, в свое время, еще Э.Э. Клингманом [1] был назван дуализмом.

В случае реализации алгоритма программными средствами, надо помнить, что неизменными атрибутами любой программы выступают совокупность глобальных и локальных переменных, а также массивы, которые каждый программист создает соответственно своему опыту и вкусам. Значения этой совокупности в каждый момент времени и определяет множество состояний программы. Программу можно считать полностью работоспособной, если на любую комбинацию значений управляющих сигналов программист предусмотрел реакцию. Если же некоторые комбинации оказались непредусмотренными, тогда программа может перейти в непредусмотренное состояние, что проявляется в виде "глюков", связанных исключительно с недопониманием программистом логики реализованного в программе алгоритма, но никак не недостатками самого языка программирования или компиляторов к нему.

В принципе, не лучшим образом обстоит дело и с реализацией проектов аппаратными способами, когда схема, реализующая алгоритм управления, проектируется разработчиком "творчески". В свое время, я имел "счастье" наблюдать со стороны за ходом разработки одного своего молодого коллеги. Процесс проходил в том порядке, что сначала на листе ватмана карандашом был набросан кусок схемы, состоящий их счетчика и дешифратора. По замыслу автора, такая комбинация должна была стать ее основой. Затем, вокруг этого "ядра", стали рисоваться другие цифровые компоненты – вентили, триггеры, опять вентили... После некоторых раздумий и выпитой чашки чаю часть схемы удалялась ластиком, а на ее месте появлялось что-то новое. В общем, процесс совсем даже был похож на то, как программисты пишут программы, а художники – рисуют картины, с каждым мазком доводя их до "совершенства". К концу недели ватман местами был истерт до дыр и, что не менее удивительно, другой специалист, получивший задание перерисовать схему на чисто – даже не смог с ним справиться, потому как уже не представлялось возможным разобраться в схеме, в виду большого количества беспорядочных обратных связей на ней и не меньшего числа пересечений проводников. Понятно, что проверить правильность реализации задуманного алгоритма мысленно не представлялось возможным. Не удивительно, что такая схема так никогда и не заработала.

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

Как тут не вспомнить слова классика, что "... надо только выучить все то, что наработало до тебя человечество". Программирование же пока не может похвастаться подобным багажом знаний, потому как отрасль еще молодая и больше похожа не на науку, а на обычное ремесло, вроде обжигания горшков. По крайней мере, до тех пор, пока я буду слышать фразу – "...мне легче написать самому программу заново, чем разобраться в том, что написал тут мой предшественник..." – никакая сила не заставит меня изменить свое мнение.

Но возникает вопрос: какая вообще может быть ценность от методов аппаратной реализации алгоритмов управления, если, в принципе, речь идет о разработке программного обеспечения для микропроцессора?

Вот тут должна стать понятной ценность концепции, высказанной А. А. Шалыто и Н.И. Туккель, что, оказывается, графы переходов автоматов Мура-Мили прекрасным образом имеют изоморфность с обычной SWITCH структурой языка Си, или подобными структурами в любом другом языке программирования.

Получается, что начинать разработку программы специалист должен не с попытки обозвать массивы и написать первые операторы, а формализации задачи и проектирования под нее цифрового автомата. Только по окончанию проектирования ему предлагается браться не за паяльник, чтобы реализовать проект в виде электронной платы, а всего лишь воспользоваться методикой SWITCH технологии и формальным образом получить текст программы.

Предлагаемая концепция проектирования получила название "автоматного проектирования" и позволяет максимально подробно описывать процессы, которые необходимо автоматизировать, используя при этом формальный язык конечных автоматов. Более того, предлагается четкий и универсальный метод описания, единый для всех стадий проектирования.


Наиболее полную информацию по теории автоматного программирования и последним достижениям в данной отрасли знаний можно найти на сайтах А. Шалыто (д.т.н., профессор, зав. кафедрой Технологии Программирования Санкт-Петербургского Государственного Универститета Информационных Технологий, Механики и Оптики) - ссылка скрыта и А. Легалова (д.т.н., доцент, профессор кафедры НейроЭВМ Красноярского Государственного Технического Университета) - ссылка скрыта

Будет ошибочным полагать, что данная методика ограничена только разработкой программ логического управления. Потому как "цифра" с каждым днем находит все новые области применения: сегодня теория автоматов лежит в основе операционной системы UNIX, с успехом пишутся драйвера для компьютерных систем, фирма Boeing использует ее в основе построения автопилотов... Список этот, на самом деле, уже сегодня гораздо более длинный. Внушает оптимизм тот факт, что, как оказалось, и само объектно-ориентированное программирование (ООП) – столп современных технологий программирования прекрасным образом подходит для формализации упомянутой технологией. Один только этот факт внушает оптимизм, что не за горами день, когда программы станут такими же надежными, как электронные системы, а их разработка превратится из искусства в строгую науку.


Как выглядит технология автоматного программирования?

Я попытаюсь выразить идею буквально одним обзацем: специалист, опираясь на исходные данные проекта и математический аппарат теории автоматов, разрабатывает граф-схему (рисунок) переходов некоторого автомата. Затем (внимание!) ему предлагается использовать специальный компилятор, который по этой граф-схеме автоматически сгенерирует C/C++ исходный текст программы. А затем уже, используя обычный компилятор, по исходному тексту программы (полученному автоматически) сгенерировать исполняемый exe-файл. Конечно, можно написать коды программы по графу и "руками", что не меняет сути идеи.


Суть моего предложения состоит в том, чтобы отказаться от использования этих самых генераторов исходного кода и компиляторов, а просто эмулировать рисунок спроектированной граф-схемы автомата. Эмулировать – значит имитировать работу, другими словами – моделировать работу автомата в динамике.


Конечно же, идея эмуляции рождалась как необходимость "программирования" функциональных схем со сложной динамикой процессов, другими словами, сложными временными соотношениями сигналов в разных ее ветвях (цепях). Такие проекты просто невозможно "запрограммировать" обычными программными системами – известными языками программирования и компиляторами для них. Необходимость появления программ схемотехнического моделирования – яркое тому доказательство! Заставьте хоть раз, хоть одного программиста "запрограммировать" даже несложную схему цифрового устройства – чтобы раз и навсегда отбить у него охоту заниматься этим впредь.


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

Таким образом, можно сказать, что автоматное программирование можно рассматривать как один из методов подготовки проектов (рисунков) к эмуляции, но, безусловно, позволяющий создавать действительно надежное "ПО", представленного в виде формально разработанных графов.

Рассмотрим теперь конкретнее, каким образом автоматы можно эмулировать. Поскольку (каюсь) я не есть теоретик автоматного программирования, то представлю только два способа. Профессионалам, быть может, удастся развить эту тему глубже.


1-й способ. Собственно говоря, он "лежит на поверхности". Воспользуюсь готовым рисунком графа (рис. 8) переходов из работы [2]. Подразумевается, что человек его нарисовавший как бы предварительно получил задание на разработку в виде словесного описания, временных диаграмм или алгоритма. Конечно, мы его рассматриваем только как пример, поскольку графы реальных разработок несравненно сложнее.




Рис. 8 Граф схемы цифрового автомата


К сожалению, операция эта абсолютно "ручная", то есть пока не существует программ, строящих такие диаграммы по входному описанию. На одном из упомянутых сайтов я даже прочитал, что составление графов – это уровень кандидата наук. Может быть, именно этот фактор сдерживает широкое распространение метода?

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

Уточнюсь, что прежде чем формировать файл описания проекта (ФОП), надо прежде привести схему, изображенную на рисунке 9 к виду стандартных цифровых компонент.




Рис. 9 Схема цифрового автомата


2-й способ. Это эмуляция непосредственно графа переходов (рис. 8). Только для этого необходимо доработать саму программу эмуляции. Дело в том, что основополагающий принцип любой программы моделирования цифровых устройств состоит в отыскании "активных" цепей. Активной считается та цепь, на которой произошло изменение уровня логического сигнала. Таким образом, связь ("дуга", если проводить аналогию с графом) – первична, а компонент ("вершина") – вторичен.

В каждый момент времени активными могут стать любое количество цепей. Согласно исследованиям, до 30% цепей меняет свое состояние на каждом такте работы реальных цифровых систем. Но может статься так, что ни на одной цепи не произойдет изменений.

Для графов же все обстоит в точности наоборот. Здесь основа – вершины. С каждой из них можно соотнести только одно состояние автомата и в каждый момент времени активна только одна. Смена состояния графа происходит путем переноса признака активности на соседнюю вершину по одной (опять-таки) только дуге. Как видно, алгоритм функционирования схем графов ничем не сложнее, чем схем цифровых устройств.

Однако полезным будет не просто написание программы эмуляции графов, а совместной эмуляции графов и функциональных схем. Это позволит эмулировать на одной платформе смешанные схемы проектов, в которых модуль логического управления системы будет представлен графом переходов автомата, а вся остальная схема проекта в виде привычной функциональной схемы, компонентами которой будут, например: датчики, нормализаторы, компоненты цифровых систем (компараторы, коммутаторы, дешифраторы, триггеры, вентили...), исполнительные органы (заслонки, задвижки, нагреватели...).


Литература:


[1] - Дейкстра Э. Дисциплина программирования. М: Мир, 1979


[2] – Шалыто А.А. Реализация алгоритмов логического управления программами на языке функциональных блоков. ж-л "Промышленные АСУ и контроллеры".2000 №4.