Атомарная функция, прикладная функция - вроде бы вполне понятные понятия будут🙃

ни разу не встречал в литературе по РЗА понятие "атомарная функция".

Function - не является атомарной сама по себе, так как в ней могут быть SubFunction. По этому function - обьединение  ln в группу по какому то общему функциональномк признаку. Application - структурно - функциональная схема.

так же не стоит забывать про EqFunction и SubEqFunction

Ну как в любой области надо понимать с какой точностью надо отменять функциональность :)

А почему бы функцию в Вашей трактовке не назвать "задачей"? Тем более, что в ГОСТ уже и определение есть.
"Задача автоматизированной системы; задача АС: Функция или часть функции АС, представляющая собой формализованную совокупность автоматических действий, выполнение которых приводит к результату заданного вида." ГОСТ 34.003-90 Автоматизированные Системы. Термины и определения

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

Андрей Сергеевич, можно назвать ДЗЛ задачей?

SCL - это язык описания электронной документации, по этому необходимо применять понятия из проектирования

В том же ГОСТ 34.003-90 Автоматизированные Системы. Термины и определения есть определение: "простая функция автоматизированной системы управления технологическим процессом; простая функция АСУТП: Функция АСУ технологическим процессом, не разложимая на другие функции системы."
Это конечно не "атомарная функция", но смысл тот же как мне кажется

Communication - структурная схема АСУ ТП
Substation - схема ИТС
Apllication - структурно функциональная схема
Function - группа функций. Надо делать язык SCL  понятным, в первую очередь для проектировщиков. ИМХО. Когда вы заходите на сайт, то видите не html, а понятную страницу для любого пользователя. В нашем случае надо предоставлять и визуализировать информацию как ОТР, ПД и РД

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

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

Communication это только про физическую связность оборудования?
А где DataFlow увидеть?

Сам посыл: "Надо делать язык SCL  понятным, в первую очередь для проектировщиков."
Оочень холиварный. SCL язык не должен быть user-friendly, не для людей он и, надеюсь пройдет это время, когда все туда лезут блокнотом.

Изначально мой вопрос, кстати, не касался SCL

Так речь не про язык, а про инструменты которые его используют.

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

Так что, Application — это будет у нас "структурно-функциональная схема"?

нет, это пикладная часть скорее.