Подход позволяет разделить работу, а самое главное ответственность между Заказчиком (Технологом), Разработчиком и Программистом в случае, когда они представляют разные организации, а тем более страны, так как в противном случае возникают существенные языковые, а, в конечном счете, и экономические проблемы. Подход позволяет снять с Программиста необходимость знания особенностей технологического процесса, а с Разработчика — особенностей программирования. При этом появляется возможность общения между Заказчиком, Разработчиком, Программистом и Пользователем не традиционным путем в терминах технологического процесса (например, не "идет" режим экстренного пуска), а на промежуточном полностью формализованном языке (своего рода техническом эсперанто). Например, "в третьем графе переходов в пятой вершине на четвертой позиции изменить значение 0 на значение 1", что не вызывает разночтений, характерных даже для одного естественного языка, как, например, это имеет место в такой фразе как "косой пошел с косой" [17], и не требует привлечения специалистов, знающих технологический процесс, для корректного внесения изменений. Более того, если для Разработчика программирование является "открытым", что, правда, не всегда имеет место в особенности при работе с некоторыми зарубежными фирмами, то у него появляется возможность и вовсе отказаться от услуг функционального Программиста и перейти к автопрограммированию.

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

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

Подход в настоящее время успешно апробирован при создании НПО "Аврора" совместно с фирмой Norcontrol (Норвегия) системы логического управления судовым дизель-генератором [18], и при создании системы управления дизель-генератором того же типа, построенной на основе аппаратуры "Selma-2" фирмы ABB Stromberg (Финляндия) [19]. При этом в первом случае программирование выполнялось на языке высокого уровня PL/M, а во втором — на специализированном языке функциональных блоков. В последнем случае автором совместно с В.Н. Кондратьевым (НПО "Аврора") было предложено использовать только такие функциональные блоки библиотеки (цифровые и логические мультиплексоры), которые обеспечивают изоморфизм между согласованными с Заказчиком графами переходов и получаемой функциональной схемой. Этот подход принципиально отличается от традиционного, при котором добиваются только функциональной эквивалентности функциональных схем и спецификации (если последняя имеется), но не обеспечивается их изобразительная эквивалентность, позволяющая проводить верификацию сверкой изображений. Функциональная схема при традиционном подходе реализует заданное поведение, но описывает его в форме, не отображающей динамику переходов из состояния в состояние и динамику изменения значений выходных переменных автомата.

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

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

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

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

Предложенный подход позволяет обеспечить программирование с единых позиций в базисе различных языков, входящих в состав программного обеспечения современных программируемых логических контроллеров, таких как, например, программируемые логические контроллеры [20], для которых программирование может выполняться, во-первых, с помощью языков, рекомендуемых международным стандартом IEC 1131 — последовательных функциональных диаграмм (Sequential Function Chart — SFC), функциональных блоков (Function Blok Diagram — FBD), лестничных схем — (Ladder Diagram — LD), инструкций (Instruction List — IL), а, во-вторых, с помощью таких языков как Ассемблер и Си.

Изложенный подход идеологически близок к использованному при разработке в Институте проблем управления (Москва) под руководством д.т.н. О.П. Кузнецова языка "Ярус" [21] и его модификаций [22] и может рассматриваться как его осмысление и дальнейшее развитие [23]. Подход соответствует основным тенденциям, развиваемым в настоящее время для построения автоматизированных систем управления сложными энергетическими системами [24].