Когда не нужна ОС РВ?, навеяно постом "Я написал 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? ...) - то этого и не может случиться: "мы вам предлагаем уникальные технологии"!

[=AK=]

у них (средства МЭК) нет и не может быть ни средств синхронизации ассинхронно развивающихся задач, ни средств защиты (атомарного доступа) данных!

Прям-таки "нет и не может быть"? Например, задачи могут исполняться кооперативно, это гарантирует атомарность доступа к данным. Управление исполнением ("синхронизация") обеспечивается на уровне языка SFC.

есть и ... вещи и спорные, по крайней мере: вопрос вкуса, к чему относятся и сами языки МЭК ...

Хоть о вкусах и не спорят (с), хочу обратить Ваше внимание еще на один факт, а именно - на общеизвестную простоту освоения языков LD и FBD непрограммистами. Имхо, именно в этом же кроется причина нынешней популярности LabView. Такая информация для размышления: в англоязычных странах значительный (порядка 5%) процент обычных электриков в порядке повышения квалификации заканчивают курсы программирования PLC, где осваивают LD (в Германии, наверное, FBD). После этого они успешно программируют простые системы управления на небольших PLC. Заставьте их программировать на С, так наверняка результат будет нулевой (а уж если попытаться "навесить" на них RTOS-ные заморочки, так вас просто прибьют, ведь электрики - ребята простые). По той же причине выбор более близкой к естественному языку Модулы (а не абстрактных каракулей С) в качестве основы языка ST имел смысл. А Вы с Зюбиным как глухари на току, право слово: "ах, защита мега-корпораций", "ах, рекламная кампания", "фи, убогие языки", "где привычные нам фигурные скобки", "где сообщения, семафоры и мютексы".
Впрочем, справедливости ради: у в Вас можно увидеть и здравые суждения, тогда как Зюбин только протяжно бредит, упиваясь собственным невежеством.

Сообщение отредактировал =AK= - Mar 12 2006, 04:56

[Olej]

Прям-таки "нет и не может быть"? Например, задачи могут исполняться кооперативно, это гарантирует атомарность доступа к данным. Управление исполнением ("синхронизация") обеспечивается на уровне языка SFC.

Ага ... только "кооперативная многозадачность" (FIFO дисциплина) - это на-вроде "осетрина второй свежести" ... с которой известно как дело обстоит, асинхронностью здесь и не пахло : всё, что можно выразить в кооперативной многозадачности - можно с тем же успехом выразить и в цепочке функциональных вызовов.

Хоть о вкусах и не спорят (с), хочу обратить Ваше внимание еще на один факт, а именно - на общеизвестную простоту освоения языков LD и FBD непрограммистами.

В своё время много внимания уделялось простоте для кухарки управлять государством ... теперь вот - простоте освоения языков LD и FBD...

Такая информация для размышления: в англоязычных странах значительный (порядка 5%) процент обычных электриков в порядке повышения квалификации ...
...
ведь электрики - ребята простые).

А они там ... "в англоязычных странах" - вообще "ребята простые", не только электрики...

По той же причине выбор более близкой к естественному языку Модулы (а не абстрактных каракулей С) в качестве основы языка ST имел смысл.

По поводу "глубокого диалектического развития Модулы в ST" ... это уже не первый раз повторяется - а поэтому заслуживает ответа:
- я, в отличие от многих программистов, несколько лет "сидел" в Modula-2 (не потому "в отличие", что я, а потому, что в практике Modula далеко не часто используемый инструмент""), и сдавал несколько проектов, некоторые из которых, наверное, и п сей день эксплуатируются... , кроме того достаточно обстоятельно изучал и "до" и "после": Modula, Oberon, Zenon... (это к вопросу "только не надо мне впаривать" )...
- вся линейка этих языков построена на философии взаимодействующих ветвей...
- безусловно, разработчик ST глядел в открытую книгу "Модула" ... но единственное, что он оттуда извлёк, и что роднит ST с Modula - это то, что зарезервированные ключеве слова Pascal-евские (IF, THEN, ELSE ...) - и там и там пишутся заглавными буквами ;
- ... с таким же успехом можно "сравнить %&@ с пальцем" - на том основании, что они ... формой похожи :D;

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

Так ... это мы оставим без ответа ... т.к. это само по себе больше говорит об утвержающем, чем о субъекте утверждения, и в ответе не нуждается...

[=AK=]

только "кооперативная многозадачность" (FIFO дисциплина) - это на-вроде "осетрина второй свежести" ... с которой известно как дело обстоит, асинхронностью здесь и не пахло

Некошерно, религия не позволяет? Хотите асинхронности - юзайте прерывания.