[Виктория 0]

Чтоб не повторяться - я об этом много писал, вот здесь, например: http://www.isagraf.ru/forum/viewforum.php?...53e4243359fe44e

- хотя даже "те" воззрения уже очень сильно сместились ...

 

Спасибо за ссылку. Не знаю уж, плохо или хорошо, что идеи так разбросаны по форумам :) . Читать и в курсе быть сложновато, зато мнения с разных сторон (и от фирмачей, и от спецов по АСУТП, и от спецов по ОС РВ :) ).

 

Сейчас только кратко смогу (для информации).

Я как-то для себя уже задавался похожими вопросами...

1. в технологии PLC (это же всё пришло из PLC?) что принципиально нового, отличного - это строгая цикличность организации процесса: ... - ввод - обработка - вывод - ...

2. то, что кажется принципиальным - использование языков МЭК 61131-3, по моему мнению, особо принципиальным то и не является...

 

1. угу

2. тоже угу :) . Хотя SFC хорош для описания алгоритмов функционирования ПЛК, а дополнительные элементы FBD, ST и этой компании в виде таймеров, триггеров, PID и т.п. составляют некоторую базисную библиотеку для описания часто используемых в АСУ ТП функций.

Собственно - по поводу языковых средств могу только к Владимиру Зюбину отослать

http://reflex-language.narod.ru/ - предлагаемый им альтернативный язык программирования ПЛК

http://www.softcraft.ru/forum/viewtopic.ph...1a38d66e72e3492 - обсуждение его на форуме softcraft.ru

http://iprog.pp.ru/forum/read.php?f=1&i=34658&t=34658 - тоже в сфере профессиональных программистов ПЛК и АСУ ТП

(извинения всем за многочисленные ссылки и легкий уход в сторону)

 

3. кстати, совсем не очевидно и не на виду то, что для выполнения программ, подготовленных в МЭК 61131-3 - требуется исполняющая система: ISaGRAF || CoDeSys , и они (!) являются интерпретаторами промежуточного языка (хотите, назовите его байт-код)...

4. а это очень сильно настораживает в сочетании с терминологией realtime ...

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

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

 

Вот эта часть вопросов наверно интереснее, актуальнее для нашего форума (electronix.ru)!

ISaGRAF || CoDeSys - точно с интерпретаторами и используют ОС РВ (так они и переносимость обеспечивают между платформами и ПЛК).

Насчет Siemens и его Step7 такой уверенности нет (вроде как без ОС РВ).

И еще, очевидно что подход с интерпретатором TIC-кода для ЦОС и ИИС не подойдет (если только не уйдем куда-нибудь совсем в сторону изменяемой системы команд процессора под свою задачу ...), быстродействие процессоров все-таки это пока не позволяет. А предсказуемость вроде бы обеспечивается, хотя это от уровня программиста и зависит.

 

Evgeny_CD @ Mar 3 2006, 12:44)

 

Основная задача стандарта PLC - сформировать некий простой базис, в рамках которого можно решить все целевые задачи. Т.е. научили технолога АСУ ТП некоей системе программирования - и он в ней все может запрограммить - от кофеварки до ядреного реактора.

 

Это только розовая мечта такая была (где-то в середине 90-х), которая конечно не осуществилась. :)

Произошло только улучшение технологии программирования программистов задач АСУТП (легкое такое улучшение ..)

 

Стандарта языков МЭК - да, стандарта PLC (я бы сказал, скорее "идеологии") - нет.

 

Про идеологию согласна. Хотя когда появились ПЛК и эти языки МЭК - уж такие размахивали флагом "открытых систем". А на вопрос про переносимость и включение своего драйвера - да ОЕМ часть обязательно есть (заплати только огромную сумму)! Ну это off-topic.

Изменено 3 марта, 2006 пользователем Vic1

[Виктория 0]

К сожалению смогу продолжить беседу только вечером или позднее :(

[SM 0]

Почему это вы решили, что достаточно простые (а другими они быть и не могут) "ручные" реализации будут оптимальнее, чем те, которые "обкатаны", скажем, в течении 20-30 лет? Ну и что, станете вы писать адаптивную или спорадическую диспетчеризации параллельных веток вместо round-robin для единоразового использования? И сколько ещё скрытых ошибок вы оставите в "ручной" реализации?

Это я решил, базируясь на собственном опыте (и поверьте, богатом) построения многоканальных систем цифровой обработки сигналов. Где присутствует очень жесткое реальное время. Самый выигрышный вариант оказался построение системы как ряда последовательно вызываемых конечных автоматом в бесконечном цикле. С жесткой оговоркой - сколько тактов процессора разрешено на обработку одного состояния в каждом КА. Все остальные схемы, включая всевозможные самодельные диспетчеры, готовые и опробованные RTOS, и т.п. проиграли.

 

А если ресурсов хватает (впритык),

Если до такой степени впритык - то это признак того, что платформа выбрана неадекватная, и "выбирателя" пора гнать с работы... ;). Такая постановка ещё могла бы быть правомочной ... лет 20 назад.

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

 

P.S. Т.е. такая ваша позиция имеет право быть - но для очень ограниченного круга специфических задач, ЦОС как раз есть такая ниша, но и то - не всё даже, что ЦОС, а только отдельные подклассы задач в ЦОС.

Пока таковыми были ВСЕ решаемые мной задачи ЦОС. Они касались обработки голосовых каналов и каналов цифровой передачи данных (модемы). А также и не совсем ЦОС... Я еще не встретил ни одного чужого (не самодельного) планировщика, который был бы оптимален с моей точки зрения.

 

, или bios (как заметил SM)?

 

Я заметил не bios, а DSP/Bios, что является торговой маркой и названием полноценной RTOS.

[Olej 0]

2. тоже угу :) . Хотя SFC хорош для описания алгоритмов функционирования ПЛК, а дополнительные элементы FBD, ST и этой компании в виде таймеров, триггеров, PID и т.п. составляют некоторую базисную библиотеку для описания часто используемых в АСУ ТП функций.

 

А где я сказал, что языки МЭК это зло?

Но это только одно из возможных технологических средств программирования ... могут быть и другие (там как-раз новый МЭК стандарт подходит) - но это не принципиальная и неотъемлемая составляющая ... "PLC культуры".

Для определённых задач, например, как ничто хорош язык LISP, вопрос: можно эти задачи записать, когда нет LISP реализации, на других языках? Конечно можно...

 

Вот эта часть вопросов наверно интереснее, актуальнее для нашего форума (electronix.ru)!

ISaGRAF || CoDeSys - точно с интерпретаторами и используют ОС РВ (так они и переносимость обеспечивают между платформами и ПЛК).

 

Там ещё интереснее, если быть совсем точным...

Я не знаю как с CoDeSys (не было времени и случая), но с ISaGRAF покопался, и обстоятельно пообсуждал с парнями из "ФИОРД" С.-Петербург: система ISaGRAF может быть "заточена" (пересобрана) под разные исполняющие платформы (в их терминологии это называется "целевая функция"), и получается такая runtime среда исполнения, которая может крутиться:

- под RTOS ... тот же "ФИОРД" собрали "целевую функцию" под QNX;

- OS но не RT ;) - одно из самых частых использований ISaGRAF это под Linux ... последнее время много пишут - под RT Linux, но RT Linux - это что-то вроде "осетрины второй свежести"...

- без всякой операционной платформы - над голым железом...

 

И в той, и в другой, и в третьей конфигурации - в среде ISaGRAF runtime будет выполняться один и тот же TIC-кода реализующий одну программу.

[Olej 0]

Это я решил, базируясь на собственном опыте (и поверьте, богатом) построения многоканальных систем цифровой обработки сигналов. Где присутствует очень жесткое реальное время. Самый выигрышный вариант оказался построение системы как ряда последовательно вызываемых конечных автоматом в бесконечном цикле. С жесткой оговоркой - сколько тактов процессора разрешено на обработку одного состояния в каждом КА. Все остальные схемы, включая всевозможные самодельные диспетчеры, готовые и опробованные RTOS, и т.п. проиграли.

 

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

 

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

 

Да, и это ещё более суженная сфера применения, когда нечто нужно вогнать "под крышку чипа". Но далеко не всем этого хочется ;)...

 

 

P.S. Т.е. такая ваша позиция имеет право быть - но для очень ограниченного круга специфических задач, ЦОС как раз есть такая ниша, но и то - не всё даже, что ЦОС, а только отдельные подклассы задач в ЦОС.

Пока таковыми были ВСЕ решаемые мной задачи ЦОС. Они касались обработки голосовых каналов и каналов цифровой передачи данных (модемы). А также и не совсем ЦОС... Я еще не встретил ни одного чужого (не самодельного) планировщика, который был бы оптимален с моей точки зрения.

 

Пока таковыми были все решаемые вами задачи ЦОС в очень узкой сфере потоковой передачи информации (голос, модем). А вот в хорошо известной мне области - радиолокационных системах, задача потоковой ЦОС (и не менее напряжённой ЦОС) - это только одна из сопутствующих параллельных задач (выделение отметок, целеуказание, и др. и др.) - и при неэффективном их планировании сама задача ЦОС никому и даром не нужна (т.е. с большой вероятностью просто некому уже будет наслаждаться результатами её решения ;)).

 

Так почему вы так категорично считаете, что из "таковости" ВСЕХ решаемых вами задач - вытекает, что и все прочие должны поступать и думать только так?

[Evgeny_CD 0]

...Собственно - по поводу языковых средств могу только к Владимиру Зюбину отослать

http://reflex-language.narod.ru/ - предлагаемый им альтернативный язык программирования ПЛК

http://www.softcraft.ru/forum/viewtopic.ph...1a38d66e72e3492 - обсуждение его на форуме softcraft.ru

http://iprog.pp.ru/forum/read.php?f=1&i=34658&t=34658 - тоже в сфере профессиональных программистов ПЛК и АСУ ТП...

Я чего-то не догоняю. Берем eCos (как пример мощной, но компактной RTOS), пишем C код под библиотеку POSIX Theards - и получаем то же самое. И процессы, и взаимодействие между ними и пр.

 

Возможно, чтобы не перегружать входной буфер технологов АСУ ТП сложными конструкциями языка С, имеет смысл написать свой макро-язык, который бужет потом компилироваться в plain С под описанную выше комбинацию.

 

Кстати, тогда имеет смысл динамически задавать базис языка. Чтобы крилический технолог писал

 

СОСТ

ЕСЛИ

СТАРТ ПРОЦ

 

загнивающий англосакс писал

 

STATE

IF

BEGIN

 

Китаец писал еще как-то, а наш компилятор компилировал все это в виде _tag_0x65454_ (ну и таблицу тегов).

 

Но я не понимаю, зачем вообще городить огород :cranky: Почему нельзя взять Python, LUA, RUBY, написать расширение под целевую задачу (эти языки просто по определению расширяемые) и наслаждаться реультатом? Процессы, нити в этих языках есть, сами языки, мягко говоря, помощнее всех этих мэков и рефлексов вместе взятых будут. Или виновата косность мышления?

 

Пример того, что можно сотворить на LUA

http://www.circuitcellar.com/renesas2005m1...inners/1685.htm - информация

http://www.circuitcellar.com/renesas2005m1...85_abstract.pdf - статья

http://www.circuitcellar.com/renesas2005m1...tries/M1685.zip - исходники

http://www.itc.ua/article.phtml?ID=4114&IDw=33&pid=52 - статья

 

 

http://www.lua.org/ - гнездо LUA

[SM 0]

P.S. Т.е. такая ваша позиция имеет право быть - но для очень ограниченного круга специфических задач, ЦОС как раз есть такая ниша, но и то - не всё даже, что ЦОС, а только отдельные подклассы задач в ЦОС.

Пока таковыми были ВСЕ решаемые мной задачи ЦОС. Они касались обработки голосовых каналов и каналов цифровой передачи данных (модемы). А также и не совсем ЦОС... Я еще не встретил ни одного чужого (не самодельного) планировщика, который был бы оптимален с моей точки зрения.

 

Пока таковыми были все решаемые вами задачи ЦОС в очень узкой сфере потоковой передачи информации (голос, модем). А вот в хорошо известной мне области - радиолокационных системах, задача потоковой ЦОС (и не менее напряжённой ЦОС) - это только одна из сопутствующих параллельных задач (выделение отметок, целеуказание, и др. и др.) - и при неэффективном их планировании сама задача ЦОС никому и даром не нужна (т.е. с большой вероятностью просто некому уже будет наслаждаться результатами её решения ;)).

 

Так почему вы так категорично считаете, что из "таковости" ВСЕХ решаемых вами задач - вытекает, что и все прочие должны поступать и думать только так?

 

Да потому, что область-то может и узкая, но внутри нее очень и очень много всего. Я думаю не многим меньше Вашей радиолокации, а возможно и больше. Там в одной системе есть и сбор данных с обработкой, и формирование ответа на основе результатов обработки, и сохранение аудиоинформации на жестком диске, и передача его в USB/Ethernet, и передача (по аналогии Вашего выделения отметок и т.п.) распознавание сигналов и сохранение/передача результатов этого распознавания, и еще много-много чего. Так что при детальном копании эта область вовсе не узкая в смысле задач. Она узкая в смысле видов обрабатываемых сигналов - но именно эта узость (типы сигналов) к рассматриваемому вопросу не относится. И еще раз повторюсь, что реализация этого всего вкуче на одном микропроцессоре без использования RTOS оказалась наиболее эффективна по моему критерию (минимальности ресурсов -> низкой цене в серии). Я не раз строил системы с использованием RTOS (когда надо было быстро показать результат, например представить на тендер), но потом это приводило ВСЕГДА к оптимизации программы с её выкидыванием. И не надо думать, что если каналы звуковые, то задачи вокруг них очень узкие. И, самое главное, не вижу ни одного преимущества у RTOS для КОНЕЧНОГО продукта. Вижу только на части этапов разработки, возможно при отладке самой алгоритмической части. Перед ее разбиением на "кванты" - состояния конечных автоматов. Ну еще - разве что когда заказчик сказал "мне это надо вчера" и ему не важна цена изделия (единичные экземпляры, ну десятки-сотни максимум).

[Olej 0]

Да потому, что область-то может и узкая, но внутри нее очень и очень много всего. Я думаю не многим меньше Вашей радиолокации, а возможно и больше. Там в одной системе есть и сбор данных с обработкой, и формирование ответа на основе результатов обработки, и сохранение аудиоинформации на жестком диске, и передача его в USB/Ethernet, и передача (по аналогии Вашего выделения отметок и т.п.) распознавание сигналов и сохранение/передача результатов этого распознавания, и еще много-много чего. Так что при детальном копании эта область вовсе не узкая в смысле задач.

 

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

 

И еще раз повторюсь, что реализация этого всего вкуче на одном микропроцессоре без использования RTOS оказалась наиболее эффективна по моему критерию (минимальности ресурсов -> низкой цене в серии).

 

А по критерию надёжности (т.е. отсутствия скрытых ошибок) и живучести? ;)

 

И, самое главное, не вижу ни одного преимущества у RTOS для КОНЕЧНОГО продукта.

 

Я его назвал - абзацем выше. ;)

Многие из ваших устройств/систем работали в режиме 24 х 365 х ... 14 лет, к примеру?

С допустимым коэффициентом готовности ... не хуже 99.99999 - 5 9-ток это max. 5 мин. за 1 год непрерывной работы.

[Olej 0]

Я чего-то не догоняю. Берем eCos (как пример мощной, но компактной RTOS), пишем C код под библиотеку POSIX Theards - и получаем то же самое. И процессы, и взаимодействие между ними и пр.

 

А этого никто не догоняет ;).

Вообще, всё что есть языки МЭК - имеет хоть какой-то смысл только и исключительно для непрограммиста (возможно, технолога).

Во многих RTOS: QNX, pSOS, VxWorks - и изобретать ничего более не нужно, все механизмы взаимодействий POSIX или не POSIX но понятные по духу POSIX - здесь присутствуют.

 

Среди МЭК языков есть ST (структурированный текст) - двоюродный брат BASIC... Изобретать "ишо один язык" ... ? Если какой-то смысл в языках МЭК (5-ти) и есть для технолога (мне трудно влезть в шкуру технолога) - то только в тех, которые далеки именно от языков программирования, например FD (функциональных диаграм) - когда это визуальный построитель зависимостей, или язык .... релейной логики (RL, кажется) - это просто песня ("при чём погребальная"(с) Б.Акунин)... но может логикам-релейщикам так и понятно.

 

Ничего к программированию это не имеет отношения - это только нотации для выражения тем, кто не хочет писать программы.

[Виктория 0]

Olej

Говорить о том, что PLC работают "без ОС" - не приходится: там всегда присутствует runtime среда, присутствующая всегда сверх того, что написал, например, тот же технолог на языках МЭК, и именно и обеспечивающая функционирование "того ..." .

 

Ну я это сразу отметила только другими терминами Target System или bios (хотела как термин, а SM обиделся слегка :) ).

Я за общность в определениях - пусть будет runtime среда и будем ее считать как ОС (с этим я согласна).

 

Мою реплику

Будет ли при этом этот новый case-инструмент альтернативой ОС РВ? Это возможно только на базе ОС РВ или самостоятельный путь развития программных технологий?

трактуем только в отношении существующих ОС РВ общего назначения (QNX, OS-9, ...)

 

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

Сюда же еще одна мысль - естественно ОС тоже может отражать специфику предметной области, только это отражение на уровне концепций ОС, ее внутренней архитектуры, выражающееся через некоторые правила работы в среде ОС путем использования системных вызовов.

И в первом, и во втором варианте - специфика предметной области может быть отражена в базисных примитивах. Зачем? -> Упрощение процесса разработки для конкретной области задач за счет технологичности программирования (вместо ручной дрели - электрическая), опять же за счет технологичности - повышение качества ПО в среднем (не ориентируясь на оч.умелые ручки), может быть немного спорная мысль - повышение эффективности самой программы (по известным критериям быстродействия/памяти или даже соответствия требованиям жесткого РВ и другим условиям исходной предметной области). Может быть немного и загнула :)

 

Сомнения, конечно, всегда остаются насчет возвращения (этапа развития технологии) в предметно-ориентированное русло (всегда хочется универсальности ...)

 

Упоминаемые здесь скриптовые языки (собственно это обсуждение началось ранее в посте "Java in AVR") - все это тоже очень интересно, но runtime самим с нуля писать под предметную область. А как там обстоит дело с возможностью введения новых управляющих конструкций языка, (часто требующих доступа к аппаратному уровню целевой системы)? Один простой пример управляющей конструкции из "PLC культуры" - отработка таймаута.

И здесь в качестве runtime всегда используется интерпретатор :( . А мне он не во всех предметных задачах нравится ... (предубеждение такое из-за ограничений по памяти/быстродействию).

Хотя может это предубеждение в будущем и развеется само собой по объективным причинам.

 

Там ещё интереснее, если быть совсем точным...

Я не знаю как с CoDeSys (не было времени и случая), но с ISaGRAF покопался, и обстоятельно пообсуждал с парнями из "ФИОРД" С.-Петербург: система ISaGRAF может быть "заточена" (пересобрана) под разные исполняющие платформы (в их терминологии это называется "целевая функция"), и получается такая runtime среда исполнения, которая может крутиться:

- под RTOS ... тот же "ФИОРД" собрали "целевую функцию" под QNX;

- OS но не RT - одно из самых частых использований ISaGRAF это под Linux ... последнее время много пишут - под RT Linux, но RT Linux - это что-то вроде "осетрины второй свежести"...

- без всякой операционной платформы - над голым железом...

 

И в той, и в другой, и в третьей конфигурации - в среде ISaGRAF runtime будет выполняться один и тот же TIC-кода реализующий одну программу.

 

Интересно! Я знала только про портации CodeSys. Конечно, IsaGRAF сразу был ориентирован на различные ОС, а вот без ОС - это в какой-то мере новость.

[SM 0]

Да потому, что область-то может и узкая, но внутри нее очень и очень много всего. Я думаю не многим меньше Вашей радиолокации, а возможно и больше. Там в одной системе есть и сбор данных с обработкой, и формирование ответа на основе результатов обработки, и сохранение аудиоинформации на жестком диске, и передача его в USB/Ethernet, и передача (по аналогии Вашего выделения отметок и т.п.) распознавание сигналов и сохранение/передача результатов этого распознавания, и еще много-много чего. Так что при детальном копании эта область вовсе не узкая в смысле задач.

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

Именно об этом говорю и я. Много задач. Разнородных. И я именно утверждаю, что сам сделаю более оптимально, чем при использовании чего-то готового в большинстве случаев. Это будет дольше, сложнее, но лучше.

Да-да... Худшее заменяется лучшим... Одни скрытые дефекты заменяются другими.

И еще раз повторюсь, что реализация этого всего вкуче на одном микропроцессоре без использования RTOS оказалась наиболее эффективна по моему критерию (минимальности ресурсов -> низкой цене в серии).

А по критерию надёжности (т.е. отсутствия скрытых ошибок) и живучести? ;)

Однозначно лучше то, что сделано полностью самостоятельно. Отладка непонятно кем, непонятно чего и не в моих условиях не гарантирует ничего. И доверия у меня не вызывает. В отличие от самостоятельного проектирования всей системы по принципу разбиения на конечные автоматы с заданным максимальным временем исполнения каждого состояния. Если в диспетчере можно сделать ошибку - то тут ее сделать в принципе нельзя. Так как нет диспетчера. Все задачи вызываются последовательно обычной цепочкой CALL'ов на подпрограммы. Каждая подпрограмма - задача - КА. Тут нет никакого планировщика, никакой ОС - соответственно в ней и не может быть ошибки. И, как следствие, вообще меньше вероятность допустить ошибку. Другое дело, что писать всё в виде конечных автоматов, расписывая на состояния, и делая их такими, что в каждом из них программа не может находиться например более 500 тактов CPU - это не просто и надо иметь привычку и опыт. Ну еще схемы синхронизации - но они просты и стандартны. Так как нет переключения задач в непредвиденные моменты времени.

 

И, самое главное, не вижу ни одного преимущества у RTOS для КОНЕЧНОГО продукта.

Я его назвал - абзацем выше. ;)

 

На мой взгляд введение RTOS в систему только понижает надежность, так как появляется лишний "слой", в котором может быть ошибка.

 

Многие из ваших устройств/систем работали в режиме 24 х 365 х ... 14 лет, к примеру?

С допустимым коэффициентом готовности ... не хуже 99.99999 - 5 9-ток это max. 5 мин. за 1 год непрерывной работы.

 

Они например стоят в составе этой системы

http://www.sl-systems.ru/products/models/sl-avia/

[Виктория 0]

Нет, Olej, я с Вами здесь не соглашусь

А этого никто не догоняет .

Вообще, всё что есть языки МЭК - имеет хоть какой-то смысл только и исключительно для непрограммиста (возможно, технолога).

...

Ничего к программированию это не имеет отношения - это только нотации для выражения тем, кто не хочет писать программы.

 

Скорее - не может из-за громадного объема работ на плечи очень маленькой команды программистов (программистов, нету таких технологов, которые сами свой ТП автоматизируют) и коротких сроков выполнения этих работ. Или Вы под технологами этих программистов и понимаете? Из-за того, что они в предметную область ТП въехали? Чтобы технологи автоматизируемого ТП сами программы писали (или хотя бы легкие изменения вносили при эксплуатации - это мечта, может когда-нибудь и осуществится :)).

 

или язык .... релейной логики (RL, кажется) - это просто песня ("при чём погребальная"(с) Б.Акунин)... но может логикам-релейщикам так и понятно

 

:), респект. Еще насчет языков - удивляют языки программирования ПЛИС (там то наоборот вроде текстовые сейчас превалируют, и из-за этого несуразности другие видны, схемотехники забывают про классические решения своих задач - по вопросам на этом форуме заметила). off-topic

 

SM,

Другое дело, что писать всё в виде конечных автоматов, расписывая на состояния, и делая их такими, что в каждом из них программа не может находиться например более 500 тактов CPU - это не просто и надо иметь привычку и опыт. Ну еще схемы синхронизации - но они просты и стандартны. Так как нет переключения задач в непредвиденные моменты времени.

 

как раз Вам бы - SFC в руки (это правда не совсем конечные автоматы, но зато сети Петри в чистом виде)

 

Evgeny_CD - Вам я вроде тоже ответила (про реализацию предметных примитивов в OC либо ЯВУ). Хотя насчет скриптовых языков я может и ошибаюсь.

 

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

Изменено 3 марта, 2006 пользователем Vic1

[Evgeny_CD 0]

...Упоминаемые здесь скриптовые языки (собственно это обсуждение началось ранее в посте "Java in AVR") - все это тоже очень интересно, но runtime самим с нуля писать под предметную область. А как там обстоит дело с возможностью введения новых управляющих конструкций языка, (часто требующих доступа к аппаратному уровню целевой системы)?...

Возьмите любую книжку по Питону - там подробно описано как встраивать новые сущности.

 

http://www.swig.org/ - тулза для этого.

 

По поводу LUA - есть ее порт eCos. Сайта разработчика его убрали - но у меня есть.

devel.elatec.si/

 

тут интересно

http://lua-users.org/wiki/LuaDirectory

 

IMHO, это будет самая экономичная реализация LUA. eCos живет на многих архитектурах.

ecos.sourceware.org

[SM 0]

Еще насчет языков - удивляют языки программирования ПЛИС (там то наоборот вроде текстовые сейчас превалируют, и из-за этого несуразности другие видны, схемотехники забывают про классические решения своих задач - по вопросам на этом форуме заметила). off-topic

Может и офф-топик (хотя часть задач RT-системы убирать в ПЛИС это очень распространенная практика, и, более того, очень удобное решение - реальное распараллеливание). Но не забываем мы никогда классические решения задач. Может кто-то и забывает, но это их проблемы :) И не называйте это языками программирования - это языки описания аппаратуры (HDL).

 

как раз Вам бы - SFC в руки (это правда не совсем конечные автоматы, но зато сети Петри в чистом виде)

Возможно. Однако кроме того, что я противник всяких ОС, я еще и не люблю языки высокого уровня в embedded. Практически все мои проекты ассемблерные. (или ассемблер (CPU) + HDL (ПЛИС)). Опять же всевозможные библиотеки и компиляторы - это конкретный источник непредвиденных глюков и ошибок.

[Виктория 0]

Evgeny_CD, спасибо почитаю. Если найду, что можно добавить новый цикл (с новыми элементами управления, пусть по таймеру) - все мои сомнения разрешатся.

To SM

Но не забываем мы никогда классические решения задач. Может кто-то и забывает, но это их проблемы И не называйте это языками программирования - это языки описания аппаратуры (HDL).

Молодежь на этом форуме забывает... А название - тоже из раздела форума заимствовала.. Все таки какая то реальность бытия здесь отражена :)