DRAKON.SU

Асинхронные конвейерные алгоритмы в Фабуле

Эта задача излагается в порядке и по ходу освоения среды Фабула
в рамках общей Дракон-концепции.
И то и другое предстоит осваивать и адаптировать их применение в определенной прикладной системе.
Пока вникал в эти аспекты в порядке общих просмотров многократными проходами,
с вниканием в частные вопросы по мере обнаружения и необходимости.
Далее нужно будет "вчитываться" и все пробовать систематически - по мере наличия времени.

Первые итоги - вкратце:

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

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

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

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

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

Кстати говоря - сразу не обратил внимание:

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

А Фабула позволяет делать такие построения - это хорошо.
Но надо с этим специально поработать - какого типа возможны здесь такие структуры.

==========================================

Далее закладывается тема асинхронных конвейерных алгоритмов управления
обработкой потоков продукции РТК (роботизированных технологических комплексов).

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

В этом сообщении приводится только постановка задачи.

==========================================

Объект управления - штамповочный РТК, который включает в себя:
ШП: Штамповочный пресс - с коротким циклом обработки (штамповки) деталей:
порядка 60 двойных ходов ползуна в мин. (1 двойной ход в сек.).
ПР1, ПР2 - загрузочный и разгрузочный промышленные роботы:
они представлены на мнемосхеме своими схватами.
Конкретная конфигурация технологической схемы может быть разная:
с прямоходовой и поворотной кинематикой и т.п.

Задача:

1)
Представить алгоритм, обеспечивающий исключение длительных простоев ползуна пресса
на ожидание загрузки заготовок в матрицу штампа и ее разгрузки.
Матрица не отображена (условно прозрачная).
Это должен быть РТК с достаточно шустрыми роботами.

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

2)
Обеспечить взаимную блокировку устройств,
то есть исключить возможность взаимного столкновения:
свата 1 и ползуна, схвата 2 и ползуна, двух схватов.

Это задачи типа попарного взаимного исключения доступа устройств к общим ресурсам:
общим их ресурсом является (некоторая по конфигурации и по габаритам) рабочая зона РТК.

------------------------
Порядок формирования (синтеза) схемы алгоритма не приводится.
Далее приводится конечный вариант схемы:

На схеме алгоритма видны

1)
Вверху циклы технологических переходов
A1' = Z11-Z12-Z3-Z14 - вспомогательный переход загрузки штампа
A2' = Z2 - основной переход штамповки (1 двойной ход ползуна с остановкой в верхней позиции)
A3' = Z31-Z32-Z33-Z34 - вспомогательный переход разгрузки штампа

2)
Внизу видны циклы взаимной парной блокировки устройств.

3)
Все циклы замыкаются по операции конъюнкции & (логической операции И, And):
при единичных начальных условиях на входах в циклы.
Это условно обозначается номерами связей со штрихами (в черных узлах).

4) Схема обеспечивает работу по следующей ориентировочной циклограмме:

На циклограмме видно следующие особенности начала производственного цикла обработки партии деталей:
-- первая итерация цикла проходит без задержек;
-- в последующих итерациях появляются прерывания технологического цикла
(на ожидание разрешения на его продолжения);
-- интервалы времени прерываний нарастают и с 4-й итерации стабилизируются.

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

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

Основное учебное назначение модельной системы:
1) Демонстрации разных аспектов асинхронного конвейерного управления - по самым разным поводам.
2) Ознакомление со схемами такого типа и ее конкретное изучение.
3) Ознакомление с общим порядком построения (синтеза) таких алгоритмов.
4) Изучение способов программной реализации конвейерных алгоритмов такого типа
в среде Scratch (и есть на Питоне) и т.п.

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

=====================
Появляется задача построить такую схему средствами Фабулы.
Возможны разные варианты.

Вами по сути затронут целый широкий пласт вопросов, далеко выходящий за границы "традиционного" использования ДРАКОНа.

Появилась одна важная вещь - циклограмма.

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

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

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

Я всегда имел в виду (с 1986 года), что применительно к системам реального времени (для бортового компьютера Бисер) должны совместно использоваться два графических средства:

1. язык ДРАКОН
2. формализованная циклограмма бортовых паралельных процессов.

Зачем нужна формальная циклограмма?

Для организации параллельных процессов она не нужна, так как с этим прекрасно справляется ДРАКОН.

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

1. Для независимого (от ДРАКОНа) ввода формальных сведений о точных временных соотношениях. То есть для дублирования важной бортовой информации в виде двух электронных документов: а)комплекта дракон-схем и б) комплекта формальных циклограмм.

Это значит — для повышения надежности бортовых программ. Надежность бортовых (и не только бортовых) программ — исключительно важная проблема.

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

2. Для автоматического поиска ошибок в программах путем сравнения информации, поступившей из двух независимых источников: а) из дракон-схем и б) из формальных циклограмм.

3. Для наглядности. На циклограммах параллельные процессы человек видит гораздо лучше, чем на дракон-схемах.

====================

К сожалению, эту задачу у нас реализовать не удалось из-за недостатка ресурсов.

Вопрос на засыпку - не в бровь, а в глаз.
Я бы сказал - супер-важная, без которой как без воды, ... .

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

Правда - указанная выше задача рассматривается
(если взять ее в предположении - небольшое число логических условий протекания реального дискретного процесса)
на уровне одного автоматизированного (автоматического) рабочего места:
типа гибкого производственного модуля - станок (обработка давлением) + 2 сервисных робота
(на загрузке - разгрузке).
А если взять, например, многомодульную гибкую автоматическую линию (ГАП) или гибкий производственный участок?
Куча всяких условий, да еще с переменной длительностью обработки разных деталей (например, резанием).

-------------------------------------------
Вот с такой задачей я как раз столкнулся в последний раз где-то в 1986-1987 г.
Мы разрабатывали варианты ГАП для нефтяников - по изготовлению запчастей нефтяного оборудования.
Наша задача была - обкатка разных предпроектных решений
для выхода на переговоры с немецкими фирмами (Сименс, Бош, Хайнеман и др.).
Деньги были (у нефтяников).
Как оказалось потом - это были пресловутые нефтедоллары.
Они скоро кончились, и мы остались без работы (и все кругом стало рушиться).

А тогда мы днем прикидывали разные конструктивные варианты компоновок ГАП и модулей
(с промежуточными накопителями).
А вечером я лично оставался в КБ (почти до утра) - строил очередные циклограммуы - на миллиметровке:
ширина - на всю нижнюю сторону формата А2 (книжный формат), высотой до 20-30 см - в мелком масштабе.
Это было еще пол-беды (ужасно медленно и кропотливо).

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

Если бы была возможность делать хотя бы какие-то ориентировочной прикидки, но быстро - это была мечта.
Вот тогда стала необходима система оперативного моделирования дискретных процессов.
Хотя до этого тоже упражнялись на ЭВМ:
в плане обычной автоматизации проектирования - по железу, схемам управления и т.п.

===========================================
К чему я такую конкретную ностальгию развел?
Это реальный неформальный пример из прошлой жизни.
Какие тут Дракон-блок-схемы, казалось бы?

Бросаем все к чертям и переходим к объемным методам оперативно-календарного планирования:
классические задачи АСУП на внутрицеховом уровне.
Как в старом добром ручном производстве.

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

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

------------------------------
Так чё нам делать то?


Продолжение следует

Продолжение следует

У меня, вкратце говоря, складывается такой план.
Могут быть и другие подходы.

1.
Есть довольно-таки хорошо наработанная в учебном процессе
общая вводная часть
в прикладную (структурную) теорию параллельных (и последовательных) алгоритмов.

2.
Начальная база - ориентация на простые вычислительные примеры
(всем все понятно).
Но без выхода на реальные параллельные вычисления:
нет смысла реально параллелить простые задачи в программной реализации.

Хотя, если зацикливать задачи на обработку больших массивов
(порядка миллионов циклов и более)
то можно экспериментировать на 2-х-ядерных компах.
Были 2 старых 4-х-ядерных компа, но весной их списал.

В этом плане есть разные задачи на OpenMP/С
(в OpenMP/С++ не выходил - не хватает учебного времени,
да и для ускорения вычислений это, в принципе, не нужно).

3.
Основная целевая ориентация - на автоматизацию технологических процессов
и промышленную робототехнику:
простые учебные задачи по старой памяти - условно реальные по верхнему уровню.
Есть интерес к расширению на прочую современную робототехнику.
Но это пока реально только в плане образовательной робототехники.
Начинаю раскручивать это направление в разных отношениях.

4.
Что включается в себя общая вводная часть в параллельную алгоритмику.

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

4.1.1
Обильные демонстрации на проекторе (на любой подходящей стене):
на лекциях, на практике, на сопровождении лабораторных работ:

1) Динамические мнемосхемы условно реальных технологических и роботехнических задач:
приспособился быстро набрасывать действующие примеры на детском Scratch-е
(оперативно - за один два вечера),
но есть на Питоне, где-то там на разных других языках
(если порыться в компакт-дисках).

2) Автоматизация документирования параллельных алгоритмов (базисного класса)
по заданным структурным формулам:
строятся структурные схемы, временные диаграммы, разные псевдокоды алгоритмов.
Это задумывалось еще как подсистема алгоритмического обеспечения
в составе САПР автоматизированных (роботизированных) технологических систем.

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


------------------------------------------------------------
5.
Вот здесь и начинается самое интересное и проблемное:
по обсуждаемой тематике с логическими условиями.

Но это надо будет завтра кратко рассмотреть отдельным постом - на свежую голову.

Стоит только отметить:
на основе базисных структур решается огромный ворох вопросов общего значнения.

==================================
А пока есть такое замечание.
Все это есть в условно кусочно-системном виде:
вставками кусками в разные подходящие и неподходящие учебные дисциплины.

Ситуация такая.
Если официально оформлять по совместительству (ст. преп.),
то тебе начинают сбрасывать всякие выбратки - что на кафедре никто не хочет читать.

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

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

Сейчас такая лафа по разным причинам кончилась.
Зато появилось время все приводить, между делом, в связный системный порядок.

Тут, наверно. опечатка.
Последовательные алгоритмы — это не только линейные, но и разветвленные, и циклические.

Нет, все правильно.
Здесь используется двух-уровневая классификация:
простое 2-уровневое дерево
или
в пересечении 2-х оснований классификационного деления - классификационная таблица 2х2

1.
Исходно алгоритмы разделяются на 2 структурных класса:

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

ПрАл: Параллельные алгоритмы:
допускают (в общем случае) совмещение во времени 2-х и более действий,
то есть их одновременное или параллельное во времени выполнение
(в разных многих вариантах совмещения).

2.
Второе (поперечное) классификационное деление по структурным признакам:

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

2.1.
Базисные последовательные алгоритмы - это и есть линейные алгоритмы, типа:

A = (Z1-Z2-Z3-...-Zn)

2.2.
Базисные параллельные алгоритмы - это двухполюсные параллельные алгоритмы без условных ветвлений и циклов, типа:

A = (Z1-(Z12 || Z13 || ...)-Z3-(Z41 || Z42 || ...)-Z5-...

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

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

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

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

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

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

Здесь все не так (точне не все так, как в последовательных алгоритмах).
Но в исходных своих основах - это ДП (ДитЯм Понятно):
поскольку все дети отродясь включаются в реальных параллельный мир
одновременно существующих, действующих и взаимодействующих объектов и субъектов.
И поэтапно интуитивно осваиваю его,
как, например, обучаются ходить (двумя ногами, махать двумя руками и вертеть головой), бегать, прыгать, драться, играться и т.п.

--------------------------------------------------------------------
Базисные структуры алгоритмов позволяют сделать
первичны мощный качественный прорыв в это реальный алгоритмический мир
(по сравнению с классической школьной алгоритмикой).

И да помогут нам роботы !!!
Аминь.
(Торжественное обещание)

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

Кто автор этой классификации? Насколько он авторитетен? Можно ли указать литературу, где это написано?

Здесь две объединенные классификации.

1.
Последовательные алгоритмы и параллельные алгоритмы - это общеизвестная и всем понятная классификация.

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

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

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

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

1.3
Разделение на последовательные и параллельные структуры алгоритмов:
это относится к управляющим структурам алгоритмов (и программ) - к потоку управления.
Это наш основной алгоритмический хлеб - явно виден визуально на схемах алгоритмов (и программ).

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

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

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

2.
Последовательные алгоритмы разделяются на два структурных класса:

2.1.
Линейные последовательные алгоритмы или, короче, линейные алгоритмы - это общеизвестная сущность.
Это независимо от авторитетов.
Если очень нужно, то, конечно, можно найти.

Основная их общая классификационная характеристика:
1) Двух-полюсные структуры по потоку управления:
это последовательное соединение двух-полюсных операторов команд - один вход по передаче управления и один выход по передачи управления:
2) Постоянные (фиксированные, жесткие, не переключательные) структуры - без условных ветвлений.
3) Ациклические структуры.

В излагаемой технике полиморфных структурных построений
линейные алгоритмы определяются как базисный класс последовательных структур алгоритмов.
Имеем право - независимо от наличия или отсутствия авторитетов.

2.2. Все прочие классы последовательных алгоритмов:
получаются "автоматически" - как дополнение класса линейных алгоритмов.
Независимо от авторитетов.

3. Параллельные алгоритмы также разделяются на два класса:
независимо от авторитетов.

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

3.2. Все прочие (ныне известные и не известные) структуры параллельных алгоритмов.

4. Итоговое классификационное деление:
4.1. Базисные последовательные и базисные параллельные структуры алгоритмов
объединяются в общий класс:
базисные структуры алгоритмов - ключевая сущность излагаемой техники полиморфных структурных построений.
Независимо от авторитетов - имеем право.
4.2. Отсюда "автоматически" образуется дополнение до общего класса всех алгоритмов:
все прочие структурные классы алгоритмов.
Это тем более независимо от авторитетов.

--------------------------------
С авторитетами разобрались (кажется).
Теперь по поводу двух-полюсников, много-полюсников и, вообще, полюсников в алгоритмах.

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

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

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

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

Вы сказали, что формулировка дана на основании классификации. Я спросил об авторе этой классификации.

Ваши слова не позволяют мне прояснить вопрос.

По-видимому, Вы являетесь автором фразы, а также классификации? Или нет? Если нет, желательно привести точные цитаты с указанием источников. Спасибо.

1.
Фраза:
Базисные последовательные алгоритмы - это линейные алгоритмы.

2.
Линейные алгоритмы - это самая простая разновидность последовательных алгоритмов:
первичный подкласс класса последовательных алгоритмов.
Набрал в каком-то поисковике фразу "последовательные алгоритмы"
Выпала подсказка:

Дальше я не смотрел.
Но это показывает, что этот термин хорошо известен, и не я его автор.

1.2
Я принимаю это класс в качестве исходной основы (базиса)
в составе техники (системы) полиморфных структурных построений
(в рамках класса последовательных алгоритмов - данном случае).
И обозначаю его термином:
базисные последовательные алгоритмы.
Это мой термин - некоторый синоним исходного термина:
имею право оттенить смысл его применения:

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

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

1.5
Вот только я нелегально называю прочие последовательные алгоритмы
как "нелинейные последовательные алгоритмы".
Тогда получается удобное первичное деление:
линейные и нелинейные последовательные алгоритмы.

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

Мы отвлеклись от остроактуального вопроса
в отношении реального практического применения
(и, вообще, применимости с массовой практической пользой)
прикладной (структурной) теории параллельных алгоритмов.
В данном случае
для приложений в автоматизированных и роботизированных технологических системах:
http://forum.oberoncore.ru/viewtopic.php?p=93407#p93407
Это вопрос на засыпку.

Актуальность этого вопроса подтверждает пост - в космических сферах в данном случае:
http://forum.oberoncore.ru/viewtopic.php?p=93408#p93408

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

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

1.
У меня (по моему опыту) есть такая гипотеза:
авторитеты нам здесь пока не помогут - не подошло еще то золотое авторитетное время.

Хорошо бы, если бы ее (эту гипотезу) кто-то доказательно опроверг.
Готов понести заслуженное, может быть, порицание.
Но и сам могу аргументированно побоксировать
(с позиций реальной массовой прикладной пользы).

Только это должно быть не в приведении к разным классическим дискретным моделям:
-- параллельные конечные автоматы (разные варианты), сети Петри, сетевые графики и т.д.:
с достаточно развитой теоретической базой;
-- бесчисленные сейчас графические системы,
начиная со структурного анализа (IDEF-0), UML, ... (с попытками их теоретического обоснования) и т.п.

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

Ключевыми аспектами структурной теории алгоритмов являются концепции:
управляющая структура алгоритма или поток управления алгоритма
и управляемая информационная структура алгоритма или поток данных алгоритма.

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

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

3.
Чтобы самостоятельно (и авторитетно) ориентироваться в этом запутанном клубке вопросов
надо знать ответ на следующий вопрос на засыпку:
что такое прикладная (структурная) теория параллельных (и последовательных) алгоритмов?
А чтобы иметь возможность удовлетворительно отвечать на него
надо знать ответ на другой вопрос на засыпку:
откуда она есть пошла?

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

Я такую подготовку на форуме уже начал (проявил инициативу - чем это закончится?).
Это, наверное, заметно.
Но поскольку мы уже ввязываемся в частные обсуждения,
предлагаю все начать снова да ладом - что бы не терять время:
начать с вопросов по п. 3.

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

---------------------------
А пока можно показать первый неожиданный результат - получил такую ссылку:
http://habrahabr.ru/company/makeitlab/blog/253357/

3D робосимулятор V-REP, от швейцарской компании Coppelia Robotics.
Virtual robot experimentation platform.


Что-то на что-то похоже.

Там есть модели реальных промышленных роботов, в частности.
В Википедии еще нет информации по это системе.

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

Здесь есть чуть-чуть про V-REP
http://www.coppeliarobotics.com/helpFil ... ndLine.htm

Большое спасибо за документа.
Там надо запустить сцену, чтобы работать с командной строкой.
Этим я займусь позже.

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

В общем - предварительное системное обследование потенциального объекта применения
(по-ученому говоря):

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

Вспоминаются футболисты:
вот бы к каждому динаму приделать.
Но и виртуальный кине-арт - это тоже подходящее дело для молодежи.
Здесь даже можно состязаться в самых невероятных сценариях.

2.
Но есть один, по крайней мере, достаточно реальный видеоролик
со сварочным промышленным роботом.
С первого взгляда - сделано с понятием.

У меня есть в разработке алгоритмическая задачка:
РТК с двумя роботами для сборки простого узла (из двух деталей),
их сварки по контуру, ну и загрузка-разгрузка.
Хороший относительно простой пример, но синтез условно в 2 раза сложнее,
чем приведенный выше пример со штамповочным РТК.
http://forum.oberoncore.ru/viewtopic.php?p=93402#p93402

Скачал этот реальный пример из интернета - рекламный деморолик.
Запросил технологическую документацию - посмотреть как она сейчас пишется.
Пока не договорились.

3.
Вчера просмотрел документацию на симулятор:
в принципе, с первого прикида, пока все нормально (без пробы).
Есть многоязычный переводчик.
Кликаешь русский - ничего не меняется.
Переводчика пока нет.

Правда в переводе может быть непонятнее, чем в английском.
Но для подготовки описаний - это большая помощь.

Есть информация к размышлению - в отношении немедленного внедрения в школе.
В общем случае нужна локализация.
Принимаем на заметку.

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

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

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

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

Потом можно доводить задачи и до 3D-графики - условно реальные проекты.
Но это уже на уровне курсовых и дипломных проектов.

-------------------------
Текущие выводы.
1) Быстренько внедрить в школьную образовательную робототехнику не получится
(по параллельной алгоритмике - имеется в виду).
2) Тоже, практически и для первых курсов вуза.
3) Но перспективы очень заманчивые.
4) Надо докопаться до 2D-графики (или ее имитации).
5) Спокойно возвращаемся:
-- к учебному конструктору мультимедийных игр и презентаций Scratch;
-- к лего-комплектам ScratchDuino - но пока в доступности не имеются.
6) Тем более, что (по непроверенным слухам) там появился векторный графический редактор.
7) Работаем дальше с V-REP-ом:
надо выходить все-таки на действующие примеры (готовые, например)
под применение Дракона + Фабулы.

Параллельные алгоритмы возможно большое практическое прикладное применение имеют в махатронике.

http://forum.oberoncore.ru/memberlist.php?mode=viewprofile&u=5413,
http://forum.oberoncore.ru/viewtopic.php?p=87111#p87111

Спасибо, уважаемый LKom, за ссылки.
Правда там нет конкретных ссылок на параллельные алгоритмы в мехатронике.
Но Вы затронули интересный вопрос в соотношении алгоритмов и мехатроники.
Это ситуация типа:
не проходите мимо.

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

1
Здесь есть:
-- "высшая механика" - 3-х-мерная и многомерная статика, кинематика, динамика;
-- разные задачи автоматического управления отдельными движениями
по отрезкам прямой, кривым, на стыках ломаных траекторий и т.п.:
описания на дифурах, передаточных функциях и т.п.

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

3
Например, в приведенном в начале этой темы штамповочном РТК:
viewtopic.php?p=93402#p93402

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

3.2
В крайнем случае в оперативном управлении основным производством
могут привлекаться разностные уравнения:
есть сходство с дифференциальными уравнениями, но есть и принципиальные различия.

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

4
Здесь нужна дискретная мехатроника:

1) На уровне, по крайней мере, дискретных систем логического управления.
Предпринимаются усилия по привлечению дискретных моделей:
конечных автоматов, сетей Петри и т.п.
Это идет на уровне статей и учебников - еще с 70-х - 80-х гг.
Но до массового применения в повседневной практике
разработчиков и, особенно, пользователей РТК
(технологов, наладчиков, операторов, операторов-плановиков)
до сих пор это дело не дошло.
Представляет интерес выявление причин данного обстоятельства.

2) Управляющие программы (числового и циклового) программного управления
это машинные алгоритмы - алгоритмы, пригодные для выполнения машинами
(компьютерами, станками, роботами и т.п.).
Здесь, в принципе, более естественным представляется привлечение
обобщенной прикладной (структурной) теории алгоритмов.

Причем, в общем случае - теории параллельных алгоритмов (и, в частности, последовательных).
Но где она, та теория параллельных алгоритмов, систематически изложена?
Вот в чем вопрос.

5
Фактических для промышленной робототехники и в ее расширениях на общую робототехнику
в нужны системы (сети) алгоритмов группового управления
множествами независимых и взаимодействующих объектов:
станков, роботов, их агрегатов и узлов, разных подсистем таких систем и т.д. и т.п.
Это по идее.
Легко сказать, но трудно реализовать - по многим разным причинами.

6
Недавно попалась статья:
СИСТЕМА ГРУППОВОГО УПРАВЛЕНИЯ БЕЗЭКИПАЖНЫМИ МАЛОТОННАЖНЫМИ СУДАМИ
http://web.snauka.ru/issues/2013/12/29539
В данной работе рассматривается задача автономного (без участия оператора) маневрирования малотоннажных безэкипажных судов (МБС) с целью выхода на заданные параллельные курсы при старте из произвольных начальных условий.
При этом один из объектов является «ведущим».
Алгоритмы управления движением МБС получены на основе управления по выходу и воздействиям с учетом ограничений на ускорения МБС [1-3]

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

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

6.3
В данном случае алгоритмами называются системы уравнений движения
роботов-катеров - заданные своими производными и т.п.

Решаться такая система уравнений должна, видимо,
какими-то методами решения дифференциальных уравнений.
В данном случае это задача совершенно неподъемная,
и она заменяется методами моделирования таких систем уравнений.

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

7
Но как быть с уравнениями движения объектов нашим детям,
которые, например, программируют групповое управление в среде Scratch.

Предположим - это подводные роботы-рыбы:
разведчики и один контр-разведчик.
Дети прекрасно обходится без дифференциальных уравнений движения объектов.
Есть и посложнее программы в Scratch-е.

============================
Есть информация к размышлению
относительно алгоритмов группового управления в мехатронике.

Появилась задача для моделирования параллельных (и последовательных) алгоритмов в 3D-графике.
В кратком представлении (пока еще без согласования с дракон-концепцией):





Верхний ряд автомобилей cars-2 движется влево задом-наперед.
Только сейчас заметил (может быть это какая-то старая версия программы).
Но работает исправно и так.

----------------------------
Можно проводить разные эксперименты.
Использовал программу:
-- для демонстраций по разным поводам;
-- для описания разными способами простого алгоритма переключаемого типа
(с условными переходами).

На самом деле 1-й ряд персон-1 имеется в наличии.
Но я сначала поленился вписывать им правила перехода улицы.
Они ведут пока себя безалаберно.
Но потом оставил:
при наезде автомобиля персоны исчезают.
Постепенно выбивается весть поток.
Это очень занимает студентов.

==========================
Эта задача пригодна на перевод в среду V-REP - в 3D-графике.
Есть два шагающих робота - можно организовать в 2 потока роботов
(при желании можно организовать потоки шагающих фигурок людей).
Видел, кажется, пару мобильных роботов-автомобилей.
Тоже можно организовать в потоки.

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

Сначала прикидывал такое моделирование в натуре лего-комплектами - хотя бы по минимуму.
Становилось скучно - потенциальная осуществимость в чистом виде.
А теперь руки развязаны:
это пока только в принципе (реально могут возникнуть разные проблемы.

Для конкретики далее приводится дополнительная информация

Причины - в широком плане:



Краткое заключение.

1
По разнообразному опыту есть такое персональной мнение:

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

2
Это особенно остро обстоит в области
потенциальных технических, технологических и робототехнических приложений этой теории.

3
Здесь не следует отождествлять:
-- систематическое изложение изложение такой теории и ее (технических, желательно) приложений;
-- многочисленные сборники примеров применения параллельных алгоритмов
(как правило в разных разделах математики или символьной обработки данных):
там могут отражаться разные теоретические аспекты,
но это еще не систематическое изложение теории параллельных алгоритмов;
-- разработки отдельных частных задач, направлений и методов в области параллельной алгоритмики
(здесь есть огромный материал - в том числе и в технических приложениях).

4
У нас есть такая болезнь: мы западным умом крепки.
Если что-то появляется за бугром, мы быстро подхватываем
и можем даже стать впереди планеты всей.

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

5
В то же время в отечественных (во многом уже забытых) разработках
есть множественные собственные ключевые идеи и средства.
По разным причинам они не пошли в массовую практику.
Но их целесообразно на забрасывать, а концентрировать, систематизировать и продвигать
под новые прикладные условия.

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

Хорошо было бы, если бы кто-то аргументированно и с конкретикой
доказал бы нам здесь обратное.

==========================================================
Мы снова подошли к пункту 3 в посте:
viewtopic.php?p=93421#p93421
(3)
Чтобы самостоятельно (и авторитетно) ориентироваться в этом запутанном клубке вопросов
надо знать ответ на следующий вопрос на засыпку:
что такое прикладная (структурная) теория параллельных (и последовательных) алгоритмов?
А чтобы иметь возможность удовлетворительно отвечать на него
надо знать ответ на другой вопрос на засыпку:
откуда она есть пошла?

--------------------------------------
При этом надо различать применение параллельных алгоритмов:
-- в параллельных вычислениях и, вообще, в математических приложениях;
-- в технических, технологических и робототехнических приложениях.

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

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

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

В отношении логико-временных схем.
Это интересное замечание.
Не очень понял такой переход, но остановлюсь на этом позднее.

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

Есть еще потоковый метод
(я с ним мало знаком, но немного попробовал - он реализован в среде MS Robotics Developer Studio).

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

----------------------------
В отношении вариантов поведения дискретных систем - могу дать свои представления
применительно к промышленной автоматике
(не просто аппаратурной автоматике, а автоматизированной механике).
Здесь такая замысловатая картина.

1
Есть принципиальные различия в исторических траекториях развития:
-- вычислительных (и вообще математических) алгоритмов:
алгоритмов управления дискретными вычислительными (и математическими) процессами;
-- технических, технологических (и робототехнических - в технологии) алгоритмов.

1) Общий порядок развития математической алгоритмики (Рис. 9.12, "пунктирная" траектория):
• от жестких (непереключаемых) последовательных (линейных) структур;
• к гибким (переключаемым) последовательным структурам;
• и далее к гибким (переключаемым) параллельным структурам.

2) Общий порядок развития технической алгоритмики (Рис. 9.12, "сплошная" траектория):
• от жестких (непереключаемых) последовательных (линейных) структур;
• к жестким (непереключаемым) параллельным структурам;
• и далее к гибким (переключаемым) параллельным структурам.

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

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

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

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

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

Круговая диаграмма (циклограмма) работы механизма распредвала:

Типичная линейная циклограмма механического (специального) станка-автомата

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

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

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

4) Уже на этом уровне стали появляться встроенные системы автоматического контроля деталей:
на входе в обработку или / и на выходе из обработки:
-- с разделением их на Годно и Брак (Брак исправимый и Брак неисправимый);
-- с отбраковкой деталей из основного потока.
Но это еще существенно не влияло на общий жесткий (параллельный по существу) алгоритм.

3
Примерно такая же ситуация имела место в автоматических линиях массового производства
(в основном, в автопроме).
Здесь было меньше параллелизма на отдельных станках
(хотя для корпусов, например, могла быть многоинструментальная обработка).
Использовался синхронный конвейерный режим.
Пример циклограммы блок-схемного типа:

Здесь возможен скрытый параллелизм:
в одном месте включается какой-то процесс, в другом места выключается и т.п.

4
Постепенно стали осваиваться системы числового (и циклового) программного управления
основным и вспомогательным технологическим оборудованием.
Началась комплексная автоматизация серийного производства,
пошла промышленная робототехника, гибкие производственные модули и системы.
И здесь возникла такая ситуация - почти полный пробел в описании работы таких систем.
Например:

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

---------------------------
Вот с такими делами пришлось вплотную столкнуться - в начале 80-х гг.
Правда уже были кое-какие заделы по параллельным алгоритмам - еще с начала 70-х годов.
И одновременно стали появляться разные материалы по разным логикам времени.
Это помогало сразу же немного сориентироваться в логико-временной интерпретации параллельных алгоритмов.
Еще где-то в 1973 г. задепонировал 1-ю часть отчета по операторной форме временных булевых функций.
Вторую часть оформить не успел - пришлось заниматься другими делами.
С тех пор сильно не продвинулся, но идеология отрабатывалась.
Текущие планы по этому вопросу (в направлении образовательной робототехники) отражаются в статье:
Логико-временная интерпретация параллельных алгоритмов робототехнических систем
http://paralg.ucoz.com/g4140/v5-g4144-s ... terpre.pdf

В языке ДРАКОН есть операторы порождения параллельных процессов и все остальное, что нужно для алгоритмов реального времени http://drakon.su/_media/biblioteka_1/03 ... itmy_1.pdf см. стр. 222-226