Когда не нужна ОС РВ?, навеяно постом "Я написал RTOS" Опции

[Виктория]

Так как автор поста http://electronix.ru/forum/index.php?showtopic=12972
загубил на корню возможность обсуждения, я и открыла новую тему.

Вопрос может быть поставлен так - автору скорее всего и не нужна ОС РВ. Кругу задач его предметной области (ЦОС) свойственна - цикличность (каждый такт - ввод+обработка+вывод), жесткое РВ, работа с аппаратурой возможна на уровне конфигуривания специализированной библиотеки. Намерено так написала . Чем тогда это не "IsaGraf" (или любой другой пакет языков программирования ПЛК), скажем так "IsaGraf для жесткого реального времени"? Или по другому - нельзя ли применить подход МЭК к АСУТП для другой предметной области (которые также трудоемки, также требуют высокой надежности ПО и у которых уже виден базис свойств). Например, к таким задачам - ЦОС, алгоритмы функционирования информационно-измерительных систем, ...
Будет ли при этом этот новый case-инструмент альтернативой ОС РВ? Это возможно только на базе ОС РВ или самостоятельный путь развития программных технологий?

Приглашаю всех к дискуссии.

[Andrew2000]

Маленькие замечания.

ISaGRAF - интерпретатор.
Других интерпретаторов не знаю. CoDeSys, OpenPCS - компиляторы (т.е. так называемая целевая/управляющая система там присутствует, но пользовательский код (МЭК языки) компилируется).

ISaGRAF-у ОС, собственно, и не нужна, ему нужен аппаратный таймер, по которому он будет следить за временем выполнения такта: ввод-обработка-вывод - wait, если быстро, ошибка, если переполнение такта - вот и все реальное время ...
А вот когда появляется задача связи (по Ethernet, например), то тут удобнее ОС: 1 задача - задача связи, вторая задача - интерпретатор TIC-кода (хотя, никто не мешает организовать связь на прерываниях).

Siemens STEP7 - больше чем уверен, что компилятор. Новые Siemens PLC вообще построены на чипе Speed7 - http://www.speed7.com/ - спец. CPU заточенные под STEP7.

По поводу технологов - их язык FBD - т.е. функциональные блоки (LabView туда же).
Они так видят мир И не надо им мешать.
Еще в МЭК считаю полезным SFC.
А ST там для того, если поймают обычного программиста и скажут - пиши на МЭК языке - ему будет куда спрятаться (шутка).

Рефлекс, как я понял, это еще один вариант SFC+ST.
(поправьте, если я не прав)

Ну приведу еще один язык(пример), который любят наши технологи (тоже аналог SFC+ST):
прог ТАЙМЕР_1 выкл;
сит начало;
переход СЧЕТ;
конец;
сит СЧЕТ;
T_1 = 0; t_1 = 0;
м: t_1 +=1;
переход ДОБАВИТЬ_СЕК если t == 100, //
СЧЕТ.м;
конец;
сит ДОБАВИТЬ_СЕК;
T_1 += 1; t_1 = 0;
переход СЧЕТ.м;
конец;
конец;

А когда им предложили ISaGRAF - они отказались - по-русски писать нельзя

[Olej]

...
Они так видят мир И не надо им мешать.

Когда я разбирал МЭК системы проектирования (ну, простите меня - язык у меня ... не подымается это назвать "программированием") Concept & Unity Pro от Schneider-Electric (это бранд и PLC и эти его пакеты ПО!) - "споткнулся" я в таком месте: в проекте можно организовать несколько задач (в Unity Pro даже - много: по принципу, наверное, чем больше там "рюшичек", тем дороже это можно "втулить"): фоновая задача, периодическая задача, приоритетная задача, ... N таймерных задач, M задач "по событиям" ... вас пока ничего здесь не смущает? :D

Посмотрит CoDeSys:
http://www.prolog-plc.ru/3s/CoDeSys/PT_Task.htm

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

Я не раз спрашивал ... и интеграторов ISaGRAF и CoDeSys ...
Они мне отвечают, но сильно нечленораздельно, что-то типа: ... если CoDeSys выполняется под управлением RTOS, то в системе может выполняться несколько задач...

Но при чём здесь RTOS? или не-RT? если, в силу опримитизивленности средств выражения ("Они так видят мир") - у них (средства МЭК) нет и не может быть ни средств синхронизации ассинхронно развивающихся задач, ни средств защиты (атомарного доступа) данных!
Что будет, как вы предполагаете, если одна задача быдет циклически выполнять нечто:

Код

if( X == 0 ) { /* X исключая экстремальные обстоятельства бывает только 0 и 1*/
   X++;
   ...
   if( X > 1 ) /* а это уже сложилась экстремальная ситуация! */
   { /* пуск стратегической ракеты по той клятой Австралии*/ }
};
else X = 0;

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

Код

X++;

Вот только когда-то ... один раз сложится ... ... вспоминается тот давний анекдот: "... чёрт с ней, с этой Австралией - но дисциплина то хоть какая должна быть?!"(с).
То что это "почти невероятно" ("попасть" 2-й задачей после вычисления if, но ещё до всего прочего) - это не аргумент (учите Э.Дэйкстру)!

Я уже не говорю о том, что каждая задача начинается с фазы "ввод", и читает массив изменённых значений своих входных переменных... Задача А прочитала Х = 1, ... прервавшая её задача Б начинает с того, что читает Х = 2, ... что считать будем Х после завершения Б и возобновления А?

Использователи МЭК говорят: мы будем в задачах А и Б использовать только непересекающиеся подмножества локализованных и внутренних переменных ... реализуя 2 независимые управляющие системы...
Ага, ... АСУТП управления полётами + АСУТП стоящей рядом кофеваркой ...
Но я не хочу управлять кофеваркой!
И не хочу платить за "развитость" средств разработки, позволяющих мне ещё параллельно управлять кофеваркой!

Или как делается hot-stendby резервирование ... в тех же Concept & Unity Pro?
- 1-му PLC мы присваиваем IP (предполагаем Modbus over TCP/IP);
- 2-му PLC автоматически присвается IP ... на 1 больше (?);
- верхний уровень (SCADA) подаёт Modbus команду управления по IP1 ...
- после чего повторяет её по IP2 ...
- состояния PLC1 и PLC2 - эквивалентные (?)...
- и при выходе из строя PLC1 можно преключиться на PLC2.

Вас ничего не смущает???:

п.2 - IP согласно всем 3000 с лихвой RFC не может быть "больше-меньше" ... да и любые сетевые IP не могут быть численно зависимыми, и должны всегда, в произвольный момент - конфигурироваться произвольно и независимо (а ещё лучше - динамически разрешаться через ARP или DNS).

п.4 - 2 абсолютно независимые и последовательно следующие операции обмена по различным IP - считаются "по-совокупности" атомарной и неделимой операцией! а что - обрыв контакта кабельного не может произойти между 1-й и 2-й передачей? а TCP согласно всем RFC-ям не обнаруживает разрыв соединения "на ходу" и не возвратит ошибки...

Это ещё один результат "опримитивливания модели под цели" ... раз это мы не наблюдали (на скольки прогонах? - 10**9? 10**29? ...) - то этого и не может случиться: "мы вам предлагаем уникальные технологии"!