fk0, легенда (22.06.2017 13:14, просмотров: 5041)
Почему есть FBD и т.п. языки, но нет языков (или картинок, графов, если говорить об FBD) основанных на конечных автоматах? По-моему для задач логического управления конечные автоматы подходят существенно лучше. Попробуй-ка запрограммировать http://softcraft.ru/auto/
сколько-нибудь сложную логику на кубиках FBD или реле -- умаешься без какого-либо формального подхода, из головы выдумывать-то. Для решения некоторых задач головы только не достаточно, нужна методика их решения.
Как пример, тут про пароходы детскую задачу давали. А она без составления системы линейных уравнений, по наитию, просто не решается. А составив уравнения решается в лоб несколькими известными методами. Так же и с задачами управления. Какие должны быть компоненты (реле, например, или логические элементы, или функциональные блоки), как их соединить? Отдельные моменты вроде прекрасно понятны, а в целом картина складывается плохо. Или чаще складывается, но потом работает не всегда корректно и начинается бесконечный багфикс и со сроками уходящими в бесконечность.
Вообще решение сколько-нибудь сложная задачи на уровне самых мелких элементов (лог. элементы, ассемблер, отдельные функции или классы в ЯВУ) видится плохо. Слишком детально, за деревьями леса не видно, нужен другой уровень абстракции. На уровне архитектуры -- он есть, всем известен: более крупные функциональные блоки, крупные классы или функции в ЯВУ. Диаграмма связей. Но это на уровне архитектуры.
Но зачастую видя устройство с точки зрения архитектуры логика работы все равно остается непонятной. Причем проблемы начинаются с более низких уровней, на самом верхнем как правило есть общее представление, чем должна заниматься управляющая система. Особенно это заметно в плохо делимых крупных блоках обладающих большим числом различимых внутренних состояний. Или в совокупности отдельных функциональных блоков тесно связанных между собой, имеющих в какой-то мере независимые внутренние состояния. Анализ работы такой системы, видя лишь диаграмму связей, практически невозможен. Нужно понимание, как работает тот или иной функциональный блок в различных состояниях.
Хорошо, если состояние блока искусственно выделено (в одну переменную состояния, например). Или не обладает внутренним состоянием (памятью), или оно очевидно, или не существенно -- случай тривиальный, это когда FBD действительно хорошо работает, например, в обработке сигналов. Если состояние выделено -- это, практически, и есть конечный автомат. Помимо памяти состояния он обладает логическими условиями, реагирующими на входные данные и приводящими к смене состояния и выходных сигналов. Такая абстракция понятна, может быть отображена графически или в виде таблицы, работа автомата может быть относительно легко проанализирована (при ограниченном числе состояний, иначе следовало бы пытаться разбить сложный автомат на систему связанных более простых автоматов).
Плохо, если блок представляет из себя набор более мелких блоков, каждый из которых обладает своим внутренним состоянием. Причем картина может носить фрактальный характер и сложность может нарастать практически до бесконечности, пока не остановится на уровне отдельных лог. элементов, реле, регистров процессора и ассемблере. В таком случае анализ системы человеком крайне затруднен, по крайней мере без какой-то методики работы с такими системами. Ответом здесь может быть иерархическая организация системы с явным выделением состояний и постепенное деление системы на более крупные логические блоки (состояния конечного автомата, виртуального, физически не существующего) по признаку их внутреннего состояния, являющегося суперпозицией состояний составляющих блоков. Имея логические условия на которые реагирует более крупный автомат, входные-выходные сигналы, и набор состояний можно анализировать его работу.
Хотел высказать тезис, что сколько-нибудь сложная система логического управления неизбежно скатится конечным автоматам. Здесь ключевое слово не автомат, а явное выделение состояний и переход между состояний согласно заданным логическим условиям. То, что понятно на уровне человека, что может быть как-то верифицировано, включая работу автомата в целом. На уровне отдельных битов или реле это невозможно. Даже при программировании на "естественных языках" (например, C++) сложно решать задачи управления в терминах потока инструкций программы, бессвязного набора функций или классов. Сколько-нибудь сложные задачи неизбежно потребуют двух вещей: 1) явного создания архитектуры, выраженной диаграммой связей, списком компонентов и их свойств (методов, функций), 2) определения внутреннего состояния компонентов и логики работы исходя из внутреннего состояния компонента и поступающих данных. Обычно, правда, "большие программисты" про второй пункт в лучшем случае забывают, а то и не знают, и не хотят знать вовсе. И логика программы создается по наитию, что обычно кончается бесконечным багфиксом.
Конечно не обязательно представлять алгоритм автоматом, можно блок-схемами, например (но практически это будет то же автомат, только блок-схема окажется более громоздкой и трудной для понимания). Можно диаграммами на языке Дракон. Это уже не столь существенно. Идея в том, чтоб разделить архитектурное деление (диаграмма связей) и какое-то понятное для анализа человеком описание логики (автоматы, блок-схемы). И дальше можно запросто чисто механически закодировать большую систему практически без ошибок на уже не важно каком языке, хоть через последовательность инструкций ассемблера, хоть через реализацию конечных автоматов на реле.
Но почему языки для ПЛК дают использовать естественного для задач логического управления механизма -- конечный автомат. Почему нужно его строить вручную из отдельных битов?
[ZX]