DSL для конфигурации компонентов автоматики.
Intro
Всё началось с топика на одном программерском форуме, мимо которого я, как киповец и фанат языков программирования, не смог пройти :) К сожалению мы с топик стартером разошлиcь во мнениях, но сама идея меня заинтересовала, я тогда подумал: такой инструмент был бы весьма полезен в моей работе!
DSL
Domain-specific language(предметно-ориентированный язык) это язык программирования(ЯП), как например Pascal(диалект которого используется в CoDeSys). Но в отличии от Pascal'я и других языков общего назначения, которые могут быть использованы для программирования чего угодно, DSL предназначен для некоторой, области применения. Эта область может быть как очень узкой, например ЯП для программирования кондиционеров, так и весьма широкой, например ЯП для любых компрессорных машин.
Заточка ЯП под определённую область применения позволяет сделать его простым и "естественным"(в рамках этой области), а также защитить программиста от многих ошибок, благодаря тому что среда разработки(IDE, например такая как OWEN Logic) "знает" о том какие действия, в рамках предметной области являются недопустимыми.
DSL для описания логики локальных регуляторов и программируемых реле
Собственно об инструменте: думаю хорошо было-бы иметь DLS для описания логики простых устройств вроде программируемых реле и локальных регуляторов с RS485(в качестве альтернативного стандартному, варианта). В случае регуляторов это позволило бы сократить количество дополнительных компонентов(промежуточные реле, реле времени и т.п.) и упростить их конфигурацию. Для программируемых реле это мог бы бить альтернативный графическому, способ представления программ в OWEN Logic(возможно кому-то будет удобней разрабатывать программы в текстовом виде). Ну и плюс к этому плюшки от собственно предметного подхода и возможность быстрой адаптации почти готовых решений, например из интернета.
Как это могло-бы выглядеть
Образно программу можно представить как блок имеющий вход-выходы, и некоторою логику внутри. Один такой блок мог бы быть конфигурацией для одного физического регулятора, или мог бы быть представлен в OWEN Logic как отдельный виртуальный компонент, что позволило бы собирать более сложные схемы и унифицировать набор регуляторов(т.е. можно было бы использовать одну и ту же программу, как на реальном регуляторе, так и в составе виртуальной схемы в программируемом реле).
Реально программа представляет из себя простой текстовый файл, состоящий из пяти секций:
1.Заглавие:
Указывает базовый компонент, который адаптируется под конкретную задачу, это может быть например "регулятор температуры", "контроллер системы отопления" и т.п. Базовый компонент определяет какие возможности(входы-выходы, переменные, функции, параметры) будут доступны в рамках этой конкретной программы, а также указывает IDE алгоритм проверки программы.
2.Параметры:
Содержит набор параметров, конфигурирования базового компонента, заданных программистом. Например значения ПИД-регулятора, тип датчика(для л. регуляторов) и т.п.
3.Входы-выходы:
Здесь программист может назначить входам-выходам базового компонента более удобные имена, например "температура_бойлера" вместо просто "температура",
а также добавить дополнительные входы-выходы(если это возможно).
4.Определения:
В этой секции специфические функции и переменные определённые программистом.
5.Текст программы:
Состоящий из выражений вида <действие> if <условие при котором выполняется действие>. При это последовательность записи выражений не имеет значения. Т.е. действие выполнятся когда его условие выполняется. Если условие выполняется одновременно для нескольких выражений - выполняется одновременно несколько действий, если не одно условие не выполняется и выполняются противоречивые(например, включить и выключить один и тот же выход) - ничего не происходит.
