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

[Виктория]

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

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

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

[=AK=]

Чтобы лучше понять суть МЭК-овских языков, настоятельно рекомендую ознакомиться с историей создания ПЛК. Лучше всего читать первоисточник, http://www.barn.org/FILES/historyofplc.html

Я бы выделил следующие существенные моменты:
-- ПЛК изначально создавался как средство замены релейных шкафов автоматики. Первые языки программирования ПЛК "имитировали" релейные схемы. Our customers treated the programmable controller as a box of relays, and well they should. Language theory is neither necessary not desirable for most of the customers to know. The customers, instead, understand their problem, and are indeed much smarter than the design engineers because the dimensions of their problem far exceed the relatively simple problem of designing a computer software system and language. Языки ST и SFR - это более поздние добавки.
-- Языки создавались на сравнительно бедной базе вычислительной техники 70-х ... 80-х годов, как аппаратной, так и программной. "Если нет гербовой бумаги - пишем на простой" (с) Поэтому имитация релейных схем изначально была достаточно условной.

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

Программы на МЭК-овских языках надежны прежде всего потому, что представляют пользователю очень простую и понятную модель поведения: все операторы в идеале исполняются "одновременно". А заморочки неодновременного исполнения - это уже нюансы реализации, исторические "родимые пятна". В конечном счете, надежность программ зависит прежде всего от человека, а именно - от того, насколько он хорошо представляет, что делается, и насколько он "держит в голове" что происходит в его программе. То есть, насколько хорошо он моделирует систему. Если порядок исполнения операторов неважен (пусть даже условно), это сильно упрощает моделирование и, соответственно, повышает надежность программы. Средства программирования ПЛК являются тому подтверждением.

[Olej]

Я бы выделил следующие существенные моменты:
-- ПЛК изначально создавался как средство замены релейных шкафов автоматики. Первые языки программирования ПЛК "имитировали" релейные схемы. Our customers treated the programmable controller as a box of relays, and well they should. Language theory is neither necessary not desirable for most of the customers to know. The customers, instead, understand their problem, and are indeed much smarter than the design engineers because the dimensions of their problem far exceed the relatively simple problem of designing a computer software system and language. Языки ST и SFR - это более поздние добавки.
-- Языки создавались на сравнительно бедной базе вычислительной техники 70-х ... 80-х годов, как аппаратной, так и программной. "Если нет гербовой бумаги - пишем на простой" (с) Поэтому имитация релейных схем изначально была достаточно условной.

Если уж быть совсем точным, то таких "эпох" было не 2: релейные - PLC, а 3: релейные (...50-60г.г.) - жёсткая логика (70-е) - PLC ...
Я по-молодости ещё участвовал в разработке 1-й (потом были новые поколения) СССР-ской АСУ управления пуском-остановом турбин АЭС, которые многие годы экспортировались в массу стран мира... Там было ... миллион элементов И-ИЛИ-НЕ, которые "кроссировались" на разъёмных колодках (чем и "программировались") под алгоритм регулирования - это нам сейчас пригодится...

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

Программы на МЭК-овских языках надежны прежде всего потому, что представляют пользователю очень простую и понятную модель поведения: все операторы в идеале исполняются "одновременно". А заморочки неодновременного исполнения - это уже нюансы реализации, исторические "родимые пятна". В конечном счете, надежность программ зависит прежде всего от человека, а именно - от того, насколько он хорошо представляет, что делается, и насколько он "держит в голове" что происходит в его программе. То есть, насколько хорошо он моделирует систему. Если порядок исполнения операторов неважен (пусть даже условно), это сильно упрощает моделирование и, соответственно, повышает надежность программы. Средства программирования ПЛК являются тому подтверждением.

Модель "одновременного" выполнения предоставляют никак не сами МЭК-овские языки, а циклическая организация процесса - ввод - обработка - вывод - ... особенно хорошо это видно, если эти циклы "разбить" вот так: - обаботка - вывод - ввод - ... Идея в том, что все N входных и M выходных локализованных переменных должны сменить свои значения одномоментно... а потом может идти, скажем, 1 сек. обработки, и если сигнал Ni сменит своё значение через 1мкс. после "ввод" - то это новое его значение никак не отразится на "обработка", и даже не станет этой фазе доступно ... а если до следующей фазы "ввод" Ni восстановит своё прежнее значение - то мы никогда и не узнаем, что значение "мигнуло"...

Я не случайно упомянул раньше логические элементы И-ИЛИ-НЕ... Все логические схемы (большие) могли строится на 2-х принципах: потенциальные и синхронные. Нас здесь интересуют именно синхронные реализации: все логические входя всей схемы - фиксировались (считывались) только на момент фронта синхроимпульса. Этим и достигалась "одномоментность" и и сильно снижалась вероятность "гонок" (хотя потенциальные схемы, в принципе - производительнее).

Так вот "классическое" программирование, а большинство участников разговора, мне кажется, принадлежат именно к этому миру - подобно потенциальной реализации логики: мы привыкли, что когда нам нужно значение переменной - тогда мы её и считываем (или когда оно изменяется - нас уведомляют прерыванием, и мы всё равно считываем ). Системы АСУТП, PLC, всё, что напрограммировано в МЭК языках... - ведёт себя (и должно!) как синхронные логические схемы: только в 1 момент синхроимпулься обновляются все внешние (локализованные) переменные.

И это - обязательное условие, но никто не обязывает вас реализовывать логику на языках МЭК ... рисуйте её на здоровье на С/С++ или чём хотите - обеспечьте только синхронное обновление всех внешних данных. И вы получите надёжность не хуже, чем обещанную производителями PLC (нет там других аргументов для надёжности!), а на самом деле - лучшую, потому как в смысле семантики и "тонких" неожиданностей - классические языки программирования проанализированы и проработаны на порядки лучше!

Думаю, в свете всех этих PLC языков программирования будет интересна эта книга
http://www.natahaus.ru/2006/03/05/SWITCH__tekhnologija.html
А.А. Шалыто
SWITCH - технология
Алгоритмизация и программирование задач логического управления
Издательство: Наука
Год: 1998
Формат: DjVu
http://rapidshare.de/files/14697466/SWITCH.rar.html
без пароля

Вот, кстати, "школа Шалыто" (НПО "Аврора") и предложенная ими SWITCH-технология - это действительно одна из блестящих техник для классического программирования по обеспечению надёжности (которая на самом то деле является - безошибочностью ). И не только эта книга ... там где-то на сайте НПО "Аврора" было много интереснейших статей с примерами реализации всеми привычных программных подсистем в SWITCH-технологии (и это именно не "программирование", а "сквозная технология": и документирование, и верификация, и ... - готовый продукт). Так что вот здесь вы:

"Излашается технология алгоритмизации и программирования задач логического управления на основе теории автоматов." Ладно, пускай "излашается"

- в корне не правы!

Первыми производителями ПЛК были Модикон и Аллен-Брэдли, Сименс стал делать ПЛК на несколько лет позже (когда точно - не знаю, но позже, это точно). Поэтому еще до того как появился Step5, контроллеры Модикон и Аллен-Брэдли использовали нечто подобное IL. Пусть они в отличие от Step5 не оформляли свой промежуточный код как язык, на котором пользователь мог бы писать программы, но он был.

Я вот как-раз знаю состояние с МЭК по Modicon (сейчас это Schneider Electric) и их tools программирования в МЭК Concept & Unity Pro ... и образца не "первых производителей", а в версиях 2005 года... Да-а-а-а ... это "что-то с чем-то"(с) . Кстати, сами они и не пропогандируют "одновременность" происходящего (в техдокументации), а отчётливо объясняют "слева-направо и сверху-вниз" ... Когда я смотрю на несколькоэкранные диаграммы, понарисованные проектировщиками ... я просто балдею - так всё таки левее или выше? находится эта переменная от той? Не говоря уже о том, что о каких-то там возможностях синхронизаций разработчики просто не слышали (а возможны ли вообще синхронизации? ... того, что слева вверху, с тем что справа вверху ...).

P.S. Вот те парни, которых я "наблюдаю" проектируют системы СПД (системы обеспечения безопасности движения) в метрополитене, и эти системы уже внедрены на 3-х крупных станциях ... Хорошо, я знаю на каких - с тех пор меня не заманишь на ветку, проходящую черех них.