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

[Виктория]

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

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

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

[SM]

Мое мнение однозначно - ОС РВ нужна тогда, когда лень писать качественный софт (или нет на это времени) и есть лишние ресурсы у железа. Во всех остальных случаях не нужна. Качественный софт это такой, который при выполнении заданных требований потребляет минимум ресурсов (всех, байтов, тактов, и т.п.)

[Harbour]

Ну в пользу ОС РВ можно упомянуть переносимость приложений на другие архитектуры и легкость повторного использования кода. Прогресс в данный момент таков что встраиваемую платформу менее чем с 8Mb RAM и 200MIPS'ов уже не закладывают - по стоимости они все сравнимы с меньшими, а по трудоемкости кодирования ...

[zltigo]

Мое мнение однозначно - ОС РВ нужна тогда, когда лень писать качественный софт (или нет на это времени) и есть лишние ресурсы у железа. Во всех остальных случаях не нужна. Качественный софт это такой, который при выполнении заданных требований потребляет минимум ресурсов (всех, байтов, тактов, и т.п.)

Столь усеченно-однобокую трактовку "качественно софта" оставлю на Вашей совести.
А вот по поводу "лишних ресурсов у железа" для RTOS дело обстоит с точностью до наоборот -
RTOS позволяет делить ресурсы в случае их нехватки. А когда ресурсов "завались" можно и бездумно и беcсистемно заниматься чем-нибудь другим.

[Evgeny_CD]

IMHO по осям.

1. Ось - это совокупность стандартов и методологических подходов,
которая обеспечивает:

* разработку кода силами команды (>1 человека), причем код, написанный
одним человеком, с небольшими усилиями используется другим

* повторное использование кода от проекта к проекту

* переносимость между целевыми платформами и средами разработки

2. Ось - это средство ограничения "динамического диапазона сознания".
Т.е. вначале мы делаем проект "широкими мазками" - прикидываем,
сколько надо ресурсов. Затем понимаем, каков механизм взаимодействия
частей. Потом берем отдельно каждую часть, и концентрируемся только на
ней, да на ее IO интерфейсах. Без такой декомпозиции решать задачу
написания софта, например, для любого коммуникационного контроллера -
просто мазохизм (_любая_ коммуникационная система имеет много
состояний, и потому очень сложна в действительности)

3. Ось - это средство использования чужого кода, написанного в рамках
стандарта ОСи. Крайне полезно не изобретать велосипед в области IP
стеков, файловых систем, GUI и прочего, а сконцентрироваться на
целевой задаче - ибо именно за нее деньги платят, а не за гуй (хотя
это мало кто понимает).

4. Качество софта - понятие очень сложное и многоплановое. К байтам и
тактам оно имеет слабое отношение.

Не забываем, что софт - это часть проекта, он не сам по себе живет. И
портируемость, например, часто важнее свехкомпактности кода,
написанного на асме - вот снимут проц, и что делать - все
переписывать заново?

Я бы сказал так. Качественный софт - это софт, созданный в рамках
некого набора правил, который обеспечивает максимизацию профита конторы
в рамках заданной метрики.

Метрики могут быть разными:

* создали - продали - разбежались, пока не догнали не добавили

* много лет работали, вышли на новый рынок, проявили себя - продали
контору вместе с наработками мощному конкуренту. Поскольку стоимость
конторы в таком случае состоит почти полностью из интеллектуальность
собственности, т.е. софта в нашем времени, вот тут-то следование
единым стандартам на протяжении многих лет и окупится - разница в
цене может быть 10 и более раз (либо Вашу гениальную собственность
никто не купит - ибо только Вы можете разобраться в помойке на Вашем
сервере).

* многие другие.

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

[SM]

А вот по поводу "лишних ресурсов у железа" для RTOS дело обстоит с точностью до наоборот -
RTOS позволяет делить ресурсы в случае их нехватки.

Нет. Это не так. Если ресурсов не хватает для задачи, дели их, не дели, а реалтайм-программа уже никак не получится. Ибо будет иметь отклик больший, чем допустимо. А если ресурсов хватает (впритык), то в 99% выгоднее их поделить самому исходя из особенностей задачи, платформы и т.д., чем использовать готовую RTOS, в которой для каждой задачи найдется что-то излишнее.

Да, еще RTOS полезна, когда надо быстренько накатать алгоритм, проверить работоспособность, отладить. А потом, в процессе оптимизации, ее выкинуть, как лишнюю деталь, и написать оптимальный планировщик для данной задачи. Для этого я ее и использую (в моем случае это DSP/BIOS).

[zltigo]

Нет. Это не так.

Просто Вы очевидно рассматриваете достаточно нишевый круг задач с достаточно ровным и
ограниченным (конечным числом каналов с жестко ограниченной пропускной способностью) потоком внешних воздействий. А реальность и "реальное время" ими не исчерпывается.

[SM]

(конечным числом каналов с жестко ограниченной пропускной способностью) потоком внешних воздействий.

Это точно. Систем с бесконечным числом каналов с неограниченной пропускной способностью делать не приходилось.

[Виктория]

Всем, что такое языки программирования ПЛК (стандарт МЭК) можно, например, здесь посмотреть
http://www.codesys.ru/3s/index.htm
(как профессионалам советую обратить внимание (дополнит. ссылки)- http://www.codesys.ru/3s/SP.htm, http://www.codesys.ru/3s/CoDeSys/Supp_pl.htm, http://www.codesys.ru/3s/OEM1.htm)
Можно еще эту книгу почитать (не слишком доверяя автору, но и не слишком критикуя)
http://www.natahaus.ru/2006/02/17/programm...ontrollery.html

Это все давно известно для задач АСУТП (их основное отличие от задач ЦОС - "мягкое" реальное время, в остальном - много похожих свойств).
Т.е. хотелось бы рассмотреть возможность использования подобной технологии для "ограниченного" круга задач ЦОС и ИИС. Чем и насколько ограничены? Или это все-таки большой круг, который тоже требует лучшей технологии программирования? Эта же идея уже витает в массах и у фирм-разработчиков (по крайней мере National Instruments (Labview - другой монстр case-технологий) в публикациях отмечает эти особенности РВ для задач ЦОС). Обязательно ли наличие ОС РВ в этом случае (для обеспечения переносимости, мобильности и надежности)? Или можно (лучше) обойтись минимальным ядром РВ (Target System), или bios (как заметил SM)?
Мне этот вопрос интересен в какой-то мере в плане общего развития, интересно куда же технологии развиваются. (.. а может быть и для практики)

To Evgeny_CD
Я думаю, что после моего уточнения (с ссылками) Вы заметите, что все п.п.1-4 распространяются и на эту технологию, т.е. с точки зрения технологичности программирования оба подхода на одном уровне.

To All
Вопрос "Когда не нужна ОС РВ" вообще очень обширен. Я думаю, что каждый разработчик мог бы внести "свои 5 копеек" (и это даже не 5 копеек, другая денежная единица). Может немного ограничим пока обсуждение до моей постановки темы? Или тогда необходимо создать вторую ветку?

Сообщение отредактировал Vic1 - Mar 3 2006, 06:27

[Olej]

Нет. Это не так. Если ресурсов не хватает для задачи, дели их, не дели, а реалтайм-программа уже никак не получится. Ибо будет иметь отклик больший, чем допустимо. А если ресурсов хватает (впритык), то в 99% выгоднее их поделить самому исходя из особенностей задачи, платформы и т.д., чем использовать готовую RTOS, в которой для каждой задачи найдется что-то излишнее.

Да, еще RTOS полезна, когда надо быстренько накатать алгоритм, проверить работоспособность, отладить. А потом, в процессе оптимизации, ее выкинуть, как лишнюю деталь, и написать оптимальный планировщик для данной задачи. Для этого я ее и использую (в моем случае это DSP/BIOS).

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

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

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

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

[Evgeny_CD]

Системы программировния PLC и ОС - это разные вещи, хотя иногда они и решают схожие задачи.

В принципе стандарт на PLC можно рассматривать как некую очень узкоспециализированную ОС сограниченными (по отношению к обычной ОС) возможностями.

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

Не стоит также забывать, что обычно такие системы весьма дороги, и посему реализация простейшего PLC поверх WinCE в "том" мире вполне нормальное явление, хотя я как-то с этим не очень согласен (хотя тут я становлюсь на позицию "зачем мне ОСь - я все на асме напишу", которую я не разделяю)

Не знаю, я мало знаком с миром стандартов PLC- так что есть что почитать! Спасибо за ссылку на книгу!

[Olej]

Всем, что такое языки программирования ПЛК (стандарт МЭК) можно, например, здесь посмотреть
http://www.codesys.ru/3s/index.htm
(как профессионалам советую обратить внимание (дополнит. ссылки)- http://www.codesys.ru/3s/SP.htm, http://www.codesys.ru/3s/CoDeSys/Supp_pl.htm, http://www.codesys.ru/3s/OEM1.htm)
Можно еще эту книгу почитать (не слишком доверяя автору, но и не слишком критикуя)
http://www.natahaus.ru/2006/02/17/programm...ontrollery.html

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

Т.е. хотелось бы рассмотреть возможность использования подобной технологии для "ограниченного" круга задач ЦОС и ИИС. Чем и насколько ограничены? Или это все-таки большой круг, который тоже требует лучшей технологии программирования? Эта же идея уже витает в массах и у фирм-разработчиков (по крайней мере National Instruments (Labview - другой монстр case-технологий) в публикациях отмечает эти особенности РВ для задач ЦОС). Обязательно ли наличие ОС РВ в этом случае (для обеспечения переносимости, мобильности и надежности)? Или можно (лучше) обойтись минимальным ядром РВ (Target System), или bios (как заметил SM)?

Я как-то для себя уже задавался похожими вопросами...
1. в технологии PLC (это же всё пришло из PLC?) что пинципиально нового, отличного - это строгая цикличность организации процесса: ... - ввод - обработка - вывод - ...
2. то, что кажется принципиальным - использование языков МЭК 61131-3, по моему мнению, особо принципиальным то и не является...
3. кстати, совсем не очевидно и не на виду то, что для выполнения программ, подготовленных в МЭК 61131-3 - требуется исполняющая система: ISaGRAF || CoDeSys , и они (!) являются интерпретаторами промежуточного языка (хотите, назовите его байт-код)...
4. а это очень сильно настораживает в сочетании с терминологией realtime ...
5. и как раз не в смысле скорости... здесь в обсуждениях много путаницы вносится, связывая скорость с realtime, а они даже не коррелированы, или даже коррелированы, но отрицательно: realtime по своим качествам система (операционная, целевая, любая), при прочих равных, будет медленнее, чем та, к которой это требование не выдвигается (за счёт более корректного и тщательного переключений контекстов и т.д. и т.п.)...
6. а в смысле детерминированности, предсказуемости ... и далее по цепочке надёжности - вот главные критерии риалтаймовости, ... а не слабоопределённое "гарантированное время отклика", которое все друг за другом повторяют, не очень задумываясь повторяют что .

Вот, хоть сумбурно и в первом приближении, соображения на счёт...

[Olej]

Системы программировния PLC и ОС - это разные вещи, хотя иногда они и решают схожие задачи.

Понимаете, здесь есть путаница терминологическая: что есть "системы программировния PLC" - исполняющая система для программ на МЭК языках? или runtime ядро, реализующее синхронизацию всех ПО составляющих процесса АСУ, да ещё так, чтобы не нарушить принципы теории автоматического регулирования и не влететь в область неустойчивости?

Если 1-е, то, конечно, ничего общего с ОС, тогда его проще с BASIC искать аналогии...
А вот если 2-е - то достаточно много общего с ОС, только применительно к специфичному классу задач, у которого есть свои законы (см. выше), отсутствующие у других программных систем.

В принципе стандарт на PLC можно рассматривать как некую очень узкоспециализированную ОС сограниченными (по отношению к обычной ОС) возможностями.

Т.е. мы почти об одном и том же и говорим.

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

Стандарта языков МЭК - да, стандарта PLC (я бы сказал, скорее "идеологии") - нет.
Тем более, что никто технолога с МЭК языками к реактору не подпустит, хотя PLC в системе безопасности того же реактора - вполне может найтись место.

Не стоит также забывать, что обычно такие системы весьма дороги, и посему реализация простейшего PLC поверх WinCE в "том" мире вполне нормальное явление, хотя я как-то с этим не очень согласен (хотя тут я становлюсь на позицию "зачем мне ОСь - я все на асме напишу", которую я не разделяю)

Весьма дороги ещё и потому, что брэндам этой индустрии было безумно выгодно "закрыть" всё ПО и привязать к себе потребителя... Но в последние годы, как раз, очень широко пошло направление PC-based PLC, на базе открытых ОС, ПО, стандартов и т.д. - которое ну очень теснит вот тех многолетних брэндов.

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

[Evgeny_CD]

...Весьма дороги ещё и потому, что брэндам этой индустрии было безумно выгодно "закрыть" всё ПО и привязать к себе потребителя... Но в последние годы, как раз, очень широко пошло направление PC-based PLC, на базе открытых ОС, ПО, стандартов и т.д. - которое ну очень теснит вот тех многолетних брэндов...

IMHO, менеджеров, который _сейчас_ принимают решение о закупке "закрытых" систем для новых больших проектов (Газпром, РЖД, РАО ЕС), надо судить за вредительство.

Своет отношение к х86 в embedded системах я выразил давно и однозначно

"Членомер" производительности микроконтроллеров
http://www.telesys.ru/wwwboards/mcontrol/1...es/104416.shtml
http://www.caxapa.ru/mcu/wwwboard.html?id=...do=full&hilite=
http://electronix.ru/forum/index.php?showtopic=6279&hl=

ТЕОРЕМА о ненужности и бесполезности ((С) на название - великий VLV) x86 архитектуры во встраиваемых приложениях
http://www.telesys.ru/wwwboards/mcontrol/1...es/105243.shtml
http://electronix.ru/forum/index.php?showtopic=6352&hl=

http://www.telesys.ru/wwwboards/mcontrol/1...es/105467.shtml
http://www.telesys.ru/wwwboards/mcontrol/1...es/105965.shtml

хорошее обсуждение х86
http://electronix.ru/forum/index.php?showtopic=23

[Olej]

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

Хороший вопрос...

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

Другой вопрос - что там используется в качестве runtime?
Для PLC от брэндов (Modicon/Schneider Electric, Alan Bredley, Siemens, ...) - ответ на этот вопрос хранится покрепче "тайн мадридского двора" ... но есть у меня такое си-и-и-ильное подозрение, что там - нечто не многим более MS DOS расширенного режима (по памяти).

С другой стороны, можно категорически такую runtime среду не относить к ОС, но это уже вопрос терминологии ... и упорства . И чем вам не ОС система программирования Modula от Вирта, которая realtime ну куда более, чем Win-CE? Или система Forth, которую здесь кстати рядом в теме упомнили, и на которой в своё время (не знаю сейчас) реализовывалось 70% (!) законченных проектов в робототехнике?

[Виктория]

Чтоб не повторяться - я об этом много писал, вот здесь, например: 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.

Сообщение отредактировал Vic1 - Mar 3 2006, 10:56

[Виктория]

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

[SM]

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

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

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

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

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

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

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

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

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

[Olej]

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

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

[quote name='Vic1' date='Mar 3 2006, 14:53' post='91994']
Вот эта часть вопросов наверно интереснее, актуальнее для нашего форума (electronix.ru)!
ISaGRAF || CoDeSys - точно с интерпретаторами и используют ОС РВ (так они и переносимость обеспечивают между платформами и ПЛК).
[quote]

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

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

[Olej]

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

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

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

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

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

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

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

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

[Evgeny_CD]

...Собственно - по поводу языковых средств могу только к Владимиру Зюбину отослать
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_ (ну и таблицу тегов).

Но я не понимаю, зачем вообще городить огород Почему нельзя взять 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]

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

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

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

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

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

[Olej]

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

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

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

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

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

Я его назвал - абзацем выше.
Многие из ваших устройств/систем работали в режиме 24 х 365 х ... 14 лет, к примеру?
С допустимым коэффициентом готовности ... не хуже 99.99999 - 5 9-ток это max. 5 мин. за 1 год непрерывной работы.

[Olej]

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

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

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

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

[Виктория]

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]

Да потому, что область-то может и узкая, но внутри нее очень и очень много всего. Я думаю не многим меньше Вашей радиолокации, а возможно и больше. Там в одной системе есть и сбор данных с обработкой, и формирование ответа на основе результатов обработки, и сохранение аудиоинформации на жестком диске, и передача его в 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/

[Виктория]

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

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

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

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

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

SM,

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

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

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

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

Сообщение отредактировал Vic1 - Mar 3 2006, 15:53

[Evgeny_CD]

...Упоминаемые здесь скриптовые языки (собственно это обсуждение началось ранее в посте "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]

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

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

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

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

[Виктория]

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

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

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

[Evgeny_CD]

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

Я не возьмусь Вас консультировать - но то, что такое туда добавляется - у меня сомнений нет!

[SM]

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

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

Она, молодежь, не забывает. Она еще не знает Это стандартно для тех, кто все время работал с МК, решил поработать с ПЛИС.

[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]

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

Языки МЭК вызывают у меня ... какие-то смутные ощущения , не пойму пока:

1. в объяснение почему их 5 (да ещё ISaGRAF от себя 1 вводит, да ещё всё новые предлагаются, как здесь указывали...) я как-то в одном очень заслуживающем уважения месте вычитал примерно следующее: "... комитет долго спорил, чтоб не отдать предпочтение ни одному из уже установившихся поставщиков PLC в ущерб другим ... поэтому их 5 ..." - тут и задумаешься: мы хотим обсуждать высокотехнологическое средство, или кто, как, почём и больше продаст в рыночной стихии - тогда это мне совсем неинтересно.

2. кто их использует (здесь уже столкнулись с разночтениями в терминологии: технологи / программисты)? я перед собой ежедневно вижу парней, рисующих этими tools системы автоматики... и вот что я наблюдаю:
- ни один настоящий технолог в это занятие не полезет ... это технологу - чуждо, потому как всё равно по сути деятельности требует ... мышления программистского;
- заказчик всегда говорит: "с таким инструментом - мои эксплуатационщики всегда могут сесть и внести изменения в систему, подкорректировать её ... потом" - это полный бред: эксплуатационщик в принципе с таким инструментом, в силу его простоты, может "влезть" ... но единственным результатом такого влезания может быть только полное разрушение системы: исправляя в программе ошибку мы всегда вносим 3 новые, и бороться с этой прогрессией - нужно иметь навыки, и навыки эти - программистские.
- но назвать этих парней, "пишущих" на МЭК языках, программистами ... у меня как-то язык не поворачивается: они, обычно, не сильно задумываются, что такое IP-адрес, и очень удивляются, почему IP-адрес записывается как x.y.z.w, а Modbus-адрес - как x.y , я обычно этот персонал называю "проектанты" (чтоб каждую вещь хоть как-то называть - нельзя же их называть ни технологи ни программисты).
- начитавшись предисловий, что "... работа такая не требует высокой квалификации и можно привлекать персонал невысокой квалификации..." - наши администраторы хотя бы задумались (хоть вообще об чём-то думали, например, зачем и в чьих интересах такое пишется?): это в наших то условиях? когда хлопчика ещё не закончившего институт и бегающего на занятия между работами - можно нанять за $400, а самого профессионального программиста-"волкодава" - $800 (цифры условные ... региональные , но соотношение везде сохраняется).

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

Вот это интересное место. Дело то в том, что в циклической алгоритмике управляющего АСУТП процесса: - ввод - обработка - вывод - , когда это принципиально однонитевой циклический процесс - вполне достаточно на все случаи жизни MS-DOS! И никаких особо специфических функций OS (RT или не RT) - особенно не нужно. До тех пор, пока не привносится каким-то образом параллелизм. Это в точности та же история, когда при работе над MS-DOS v.2 компашка Билли Г., в силу своей невежественности к тому времени, молодости и задора - напрочь исключили возможности параллелизмов из ОС (когда в более ранней и лучше CP/M этому уже уделялось внимание, и уже создавались первые версии QNX). А потом все годы "триумфального шествия" MS-DOS - это была борьба и успешные победы тех трудностей, которых нагородили с самого начала: print-spooler, мультиплексор INT 2F, TSR-программирование кто и во что горазд...

Я думаю, что успешная жизнь PLC (более 15 лет с ранних 90-х), когда в первоначальных моделях ничего управляющего более MS-DOS и быть не могло - определяется кажущейся сверхвысокой надёжностью и устойчивостью, обеспечиваемые, на самом деле, принципиально однонитевой цикличной природой вычислительного процесса АСУТП.

Вот здесь косвенно тоже это прозвучало:

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

Да, 1 принципиально требующая параллельности ветвь - всегда появляется при требовании сетевых средств, или, если шире - любых асинхронных обменных процессов.

Но есть и другой скрытый механизм параллельности, и это гораздо серьёзнее... Когда рассматривают вот тот цикл работы АСУТП процесса: - ввод - обработка - вывод - часто неявно предполагается, что всё именно так и производится: по циклу ввод начинаются обменные операции, после завершения которых - начинается обработка полученных данных и т.д.
Но такое может быть только в крайне примитивных реализациях (которые, кстати, производители нередко именно и стараются "протолкнуть" системному интегратору).
Рассмотрим конкретный пример: 900 бинарных сигналов (это реально одна из последних задач, которую я "мозговал"), ввод каждого - не очень быстрый (RS-485 Modbus + не очень быстрая периферия) - скажем 1 мс. (это, кстати, и не так плохо)... По вот той схеме выше: начинаем читать сигнал 1, через 1 мс., получив данные - сигнал 2, ... i, ... i+1 - через чуть больше 900 мс. (1 сек.!) - начинаем логически перебирать эти сигналы, ещё 300 мс., скажем ... и т.д.
Зачем? Мы можем:
- параллельно с уже идущем циклом обработки (предыдущим)...
- запустить операцию на 1-й переменной, и не дожидаясь её завершения - на 2-й и т.д. ...
- через некоторое время операции 1, 2, ... i,i+1,... начнут завершаться, возможно совсем в другом порядке, чем они запускались...
- и вот когда все 900 операций ввода завершатся - тогда мы имеем право обновить буфер входных переменных, и следующий цикл обработки выгребет эти обновлённые данные...
- а все более ранние циклы обработки, которым придёт время начаться ранее полного завершения цикла ввода (здесь всё определяется соотношениями циклов ввода и обработки) - они спокойно возьмут себе старый комплект переменных, но только полный комплект! считанный предыдущим завершившимся циклом ввода (таким образом несколько последовательных циклов обработки могут работать с одним необновляемым набором входных переменных").
И вот здесь простейшая runtime исполняющая система PLC становится ... "просто беда" .

[Olej]

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

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

ISaGRAF - интерпретатор промежуточной формы TIC, в которую компилируются программные компоненты, созданные на любом из МЭК языков.

В этом смысле и Java - интерпретатор, а уж .NET - и подавно ...
Тот же считающийся повсеместно интерпретатор (скриптовый язык ) Perl в релизе после 5-го - в значительно большей степени компилятор в промежуточный код, чем интерпретатор этого кода.

CoDeSys, OpenPCS - компиляторы во что? в систему команд целевой платформы ... в чистом виде, "окончательно и бесповоротно"? Сильно сомневаюсь!
Даже те же С/С++ системы имеют достаточно развитую исполняющую систему: активация, прологи, эпилоги, обработчики исключительных ситуаций, сигналов... всё управление динамической памятью - это всё "интерпретирующие компоненты".

[Andrew2000]

Перечитал вниметельнее - выскажу свои мысли.

Evgeny_CD:
"
1. Ось - это совокупность стандартов и методологических подходов,
которая обеспечивает:
* разработку кода силами команды (>1 человека), причем код, написанный
одним человеком, с небольшими усилиями используется другим
* повторное использование кода от проекта к проекту
* переносимость между целевыми платформами и средами разработки
"
Нет, извините, Переносимость - да, а остальное к Оси отношение не имеет.
Грамотные "черные ящики" - сила любого проекта.

А с остальным я полностью соглашусь.

===

Vic1:
"
Можно еще эту книгу почитать (не слишком доверяя автору, но и не слишком критикуя)
http://www.natahaus.ru/2006/02/17/programm...ontrollery.html
"
_не слишком доверяя автору_ - а можно подробнее? книгу читал, а где надо не доверять?

"
Это все давно известно для задач АСУТП (их основное отличие от задач ЦОС - "мягкое" реальное время,
в остальном - много похожих свойств).
"
Я думаю, "мягкое" реальное время и задачи АСУТП связывать не надо - "мягкое реальное время" -
это как систему построить, а АСУТП разные бывают.

====

Vic1:
"
Насчет Siemens и его Step7 такой уверенности нет (вроде как без ОС РВ).
И еще, очевидно что подход с интерпретатором TIC-кода для ЦОС и ИИС не подойдет
(если только не уйдем куда-нибудь совсем в сторону изменяемой системы команд процессора под свою задачу ...)
"
Вот Siemens как раз сюда и ушел - см Speed7 - http://www.speed7.com/
А Vipa (брат-близнец Simatic) ставит на свои контроллеры eCOS.
Только одно _но_ - у них в одном контроллере 3 CPU: Speed7 для выполнения технологического алгоритма,
х86 (видимо он с eCOS) для связи с верхним уровнем по Ethernet и какой-нить SAB+ASPC2 для сети Profibus.
(Не уверен на 100%, но общая картина такая)

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

===

Olej:
"
Там ещё интереснее, если быть совсем точным...
Я не знаю как с CoDeSys ...
"
А точно так же как и с ISa, только CoDeSys компилятор, и надо смотреть поддерживает-ли он платформу.

===

Evgeny_CD:
"
имеет смысл написать свой макро-язык, который ...
"
Так МЭК стандарт так и создавался
Только фирмы, создавшие языки были крупными и сделали из внутрифирменного решения IEC.
(И как Siemens свой Profibus сделал МЭк-овским)

===

SM:
"
Кол-во ресурсов - это площадь - это доллары и центы.
"
"
Да потому, что область-то может и узкая, но внутри нее очень и очень много всего ...
"

Все-таки, тут обсуждается два разных подхода. Назовем их "ЦОС" и "АСУТП", условно.
1. "ЦОС" - Вы разрабатываете _изделие_, как правило, массовое, и сдаете его заказчику.
Сперва у Вас присутствует ОС, затем, после оптимизации уходит (а может и остается,
а может видоизменяется, не важно).
(Честно говоря, я так и живу Сначала работают несколько задач под ОС,
а в релизе - одни прерывания и ОСь с одной задачей .... для диагностики)
Такие системы, узкоспециализированные _в конечном итоге_, выжимают из аппаратуру ~100%.
2. "АСУТП" - Вы сдаете заказчику _конструктор_, на базе которого он (а может и Вы сами)
строит систему управления производством - здесь многократный запас по производительности,
и "живая" (т.е. ПО меняется) система (добавь еще две ложки .... как в к/ф "33").

===

Vic1:
"
основное достоинство языков МЭК - введение новых элементов языка, отражающих специфику
предметной области, причем не только новых структур данных, но и структур управления
"
?????

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

====

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

[Andrew2000]

Языки МЭК вызывают у меня ... какие-то смутные ощущения , не пойму пока:

2. кто их использует (здесь уже столкнулись с разночтениями в терминологии: технологи / программисты)?

Но есть и другой скрытый механизм параллельности, и это гораздо серьёзнее... Когда рассматривают вот тот цикл работы АСУТП процесса: - ввод - обработка - вывод - часто неявно предполагается, что всё именно так и производится: по циклу ввод начинаются обменные операции, после завершения которых - начинается обработка полученных данных и т.д.

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

Под циклом ввода и вывода в МЭК системых подразумевается отображение входных/выходных данных на внутренние переменные. т.е. как этот ввод/вывод происходит - дело разработчика контроллера (в параллельной задаче, или параллельно аппаратурой, ...)

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

Интерпретатор TICкода, т.е. пользовательской программы - ISaGRAF.
Компилятор в машинные коды (тоже пользовательской программы) - CoDeSys

[Olej]

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

Так не пишите ...
Или пишите "на асм/С/С++" быстрее .
Я, например, на это так и смотрю: хотите - я на С/С++ вам это сделаю, не хотите - пусть другие на МЭК "лабают", а я посижу в сторонке, посмотрю...

И из множества предпринятых попыток "подходов" к этому классу задач, я вынес и осмелюсь сделать такие предположения:
- каждая комерческая система проектирования логики + SCADA - хороша применительно только для той области, для которой она изначально разрабатывалась... , да ещё и лучше всего в руках именно тех, кто её и разрабатывал ;
- если "идти" на целую цепочку проектов в однотипной области использования - то лучше не использовать ничего из коммерческих tools, а, проанализировав, по образу и подобию ... сделать свой набор tools для наиболее общих случаев или элементов своей области, на тех же С/С++ (asm я сознательно исключаю, т.к. приобрёв в нём весьма приличный опыт - пришёл к выводу, что ничего в asm нельзя сделать того, чего нельзя в С, а если можно - то это только от неумения )...
- и потом уже с использованием этого tools - лепить проекты в своей прикладной области.

Под циклом ввода и вывода в МЭК системых подразумевается отображение входных/выходных данных на внутренние переменные. т.е. как этот ввод/вывод происходит - дело разработчика контроллера (в параллельной задаче, или параллельно аппаратурой, ...)

Всё так, только в том то и дело, что "в зависимости от" :
- цикл на одном и том же оборудовании может отличаться на порядок (не переходя никуда в более производительные платформы);
- уровень/степень надёжности (ошибок, или обратно - уровень тщательности и квалификации) для реализации вот этого "на порядок больше" - тоже может потребоваться на порядок больше.

И это не совсем дело "разработчика контроллера", т.е. в прямолинейной как у носорога US-действительности, когда "разработчик" пишет: делай-раз, делай-два, и т.д. - и "всё гарантируется ОК" - можно и так подходить ... только мне хотелось бы знать а чем конкретно вот тот "разработчик контроллера" это гарантирует?

Пример: меня очень радует документация Modicon/Schneider Electric ... особенно в том месте, когда они предлагают в пакете разработки логики PLC Unity Pro ... наличие целых до 7-ми, кажется, параллельных задач в логике - ввод - обработка - вывод - ... (приоритетная задача, таймерные процедуры etc.). Вы хорошо себе представляете, что такое асинхронно возбуждаемая таймерная задача, которая начинает с чтения входных переменных (с уже начатой, возможно, обработкой фоновой задачи с прежними значениями переменных), да ещё когда они все написаны на МЭК, в которых в принципе даже не задумывались над синхронизацией значений переменных... На такой провокационный вопрос служба техподдержки Schneider Electric мычит что-то нечленораздельное, что мол, набор переменных одной задачи, и другой задачи - это непересекающиеся наборы, ... только на кой хрень мне параллельные задачи на непересекающихся наборах данных - я не собираюсь делать 7 независимых систем управления на одном PLC: кофеваркой, летательным аппаратом, уличным освещением ... и ещё одним ЦОС .
Так что - не так всё там просто!

[=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 - процессов) не играет роли. А МЭК-овские языки реализованы намного проще, они несут в себе "родимые пятна" императивного программирования, где последовательность написания операторов все-таки играет роль. Вернее, сам МЭК-стандарт не требует этой "императивности", но из прагматических соображений допускает ее. Поэтому критика МЭК-овских языков с позиций императивного программирования в сущности не имеет под собой оснований.

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

[Evgeny_CD]

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

Читая все эти материалы материалы по МЭК и дгуим подобны ужасам, мне, с одной стороны, становится страшно (есть еще заповедники "непуганных идиотов" (я не хочу обижать приверженцев МЭК) - и как только все эти заводы & фабрики работают?), с другой стороны, я наполняюсь оптимизмом - рано или поздно, когда знания по "нормальным подходам" к программизму станут широко доступными - придет время революции в мире PLC. Как следствие, для меня и других разработчиков будет БОЛЬШОЕ поле для деятельности. Разумеется, "старое" будет отчаянно сопротивляться - но кто его, "старого" спросит...

Одним из моих выводов (IMHO) - ждем появления аналого Micro$oft (или самих мелкомягких) в области PLC. Не завтра, но рано или поздно он появится. Ибо, с моей точки зрения, терпеть дальше все это безобразие с Бейсик-подобными языками - "держаться больше нету сил" ((С) "Тайна 3 планеты"). А кто привнесет стройную и ясную концепцию, дополненную высокопрофессиональным PR - тот и победит. Стоимость аппаратуры и софта тут не так важна. Т. е. по сути нужны:
* новый хороший язык
* несколько хороших книжек
* GPL реализация всего этого, желательно на любой аппаратной платформе для учебно-ознакомительных целей (ограниченная реализация)
* нормальный коммерческий продукт за вполе нормальные $$$
* и главное, главное - маркеторлоги и PR-щики, которые все это пропихнут.

Надо будет присмотреться к миру PLC более внимательно!

Нет, извините, Переносимость - да, а остальное к Оси отношение не имеет.
Грамотные "черные ящики" - сила любого проекта.

Да. Но проще взято готовый и продуманный стандарт на такие "черные ящики" (медололгия проектирования под выбранную ОС называется), и пополнить его по своему усмотрению, чем все "изобретать с нуля".

Сообщение отредактировал Evgeny_CD - Mar 5 2006, 10:25

[=AK=]

Думаю, в свете всех этих PLC языков программирования будет интересна эта книга
http://www.natahaus.ru/2006/03/05/SWITCH__tekhnologija.html

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

Читая все эти материалы материалы по МЭК и дгуим подобны ужасам, мне, с одной стороны, становится страшно (есть еще заповедники "непуганных идиотов" (я не хочу обижать приверженцев МЭК) - и как только все эти заводы & фабрики работают?), с другой стороны, я наполняюсь оптимизмом - рано или поздно, когда знания по "нормальным подходам" к программизму станут широко доступными - придет время революции в мире PLC... ждем появления аналого Micro$oft (или самих мелкомягких) в области PLC

Угу. "Мы наш, мы новый мир построим..." (с) Не разбираясь, навесим на реально работающую технологию "правильные" ярлыки, выкинем на помойку, а потом будем изобретать свой велосипед, пусть изначально кривой, но зато за отдельные деньги. Это и есть стиль мелкомягких, истинная правда...

[Andrew2000]

Читая все эти материалы материалы по МЭК и дгуим подобны ужасам, мне, с одной стороны, становится страшно ... - и как только все эти заводы & фабрики работают?), ... - рано или поздно, когда знания по "нормальным подходам" к программизму станут широко доступными
...
Одним из моих выводов (IMHO) - ждем появления аналого Micro$oft (или самих мелкомягких) в области PLC. Не завтра, но рано или поздно он появится. Ибо, с моей точки зрения, терпеть дальше все это безобразие с Бейсик-подобными языками -
...
Стоимость аппаратуры и софта тут не так важна. Т. е. по сути нужны:
* новый хороший язык
* GPL реализация всего этого, ...

Начнем с ужасов.
Настоятельно _не_ рекомендую читать эту статью:
К ПЯТИЛЕТИЮ СТАНДАРТА IEC 1131-3. ИТОГИ И ПРОГНОЗЫ Copyright 1998, Vladimir Zyubin.
1998г - немного устарела, а _главное_ - получите неверное представление о МЭК языках.

Что Вы понимаете под ""нормальным подходам" к программизму"? Чего Вам не хватает в МЭК языках?
Это всего _языки_, а подходы - это Ваше дело.
"безобразие с Бейсик-подобными языками" - может Вы эту статью уже прочитали?
Откуда про Бейсик?!?!

МЭК языки:
- SFC - Sequential Function Chart - можно назвать диаграммой состояний - каркас программы управления.
- FBD - Functional Block Diagram - как я уже писал, это то, что любят технологи. Это совсем другой подход к программированию. Это не структурный подход и не объектно-ориентированный - это язык, управляющий потоками данных.
Это аналог MATLAB, LabView, и т.д., мне, например, очень тяжело было "переключить" мозги на этот стиль со структурного подхода. Но, есть много людей успешно работающих с MATLAB/LabView/FBD, может Вам и удасться предложить им свой "нормальный подход".
- ST - Structured Text - это Паскаль/Бейсик/С - как его только не называют. Я, когда с ним познакомился, увидел в нем Fortran А собственно, что тут удивительного ...
Не нравиться Вам FBD - вот Вам ST. Кстати, объектно-ориентированные зачатки в МЭК языках тоже есть - это Функциональные Блоки (Function Blocks) - не путать с языком FBD.
- IL - Instruction List - "универсальный" Ассемблер, происхождение - STEP5. Нужен был для переноса программ со STEP5. Современное назначение этого языка - организация PLCOpen сертифицирует ПО программирования ПЛК на соответствие стандарту МЭК - и это _единственный_ язык на соответствие которому сертифицированы все известные системы программирования ПЛК (см. http://www.plcopen.org/). Изучать/писать на этом языке, я думаю, уже никто не будет.
- LD - Ladder Diagram - язык релейно-контактных схем, кстати, у технологов до сих пор пользуется спросом.

"ждем появления аналого Micro$oft"? А что Micro$oft сделали в "нашем" мире? кроме Бейсик-а
Свой Micro$oft в мире PLC и так есть - это Siemens со своим STEP5/7 - для тех же целей но не мэк, я свой собственный.

"новый хороший язык" - не спорю, никогда не помешает, ждемс
"GPL реализация всего этого" - на sourceforge можно найти - какой-то Чех или Словак написал (не помню) - язык документации похож на украинский (только латинскими буквами), тяжело, но читать можно
Кроме того - http://linuxplc.org/


Теперь по теме ветки
Когда в ПЛК ОС не нужна - когда у Вас работает только одна задача (POU "Program"), т.е. единственный цикл/такт ввод-обработка-вывод с фиксированным/заданным временем такта, а ввод/вывод данных можно обеспечит параллельно на прерываниях или аппаратно.
Если Вам потребуется более одного цикла (кстати ISaGRAF версии 3 это не поддерживает, только ISaGRAF Pro), например, когда нужно разное время реакции для управления двумя объектами - тут без ОС тяжело.

[=AK=]

Настоятельно _не_ рекомендую читать эту статью:
К ПЯТИЛЕТИЮ СТАНДАРТА IEC 1131-3. ИТОГИ И ПРОГНОЗЫ Copyright 1998, Vladimir Zyubin.
1998г - немного устарела, а _главное_ - получите неверное представление о МЭК языках.

Это не статья, а бред.

- ST - Structured Text - это Паскаль/Бейсик/С - как его только не называют. Я, когда с ним познакомился, увидел в нем Fortran

ST происходит от благородной Модулы. Паскалем его еще можно назвать с большой натяжкой, но уж Бэйсиком, С или Фортраном ST обзывать могут только люди совсем несведущие.

- IL - ... происхождение - STEP5.

Не надо повторять зюбинские бредни.

[Andrew2000]

ST происходит от благородной Модулы. Паскалем его еще можно назвать с большой натяжкой, но уж Бэйсиком, С или Фортраном ST обзывать могут только люди совсем несведущие.

Да, видимо, Вы правы. Паскаль я совсем не знаю и ничего сказать не могу. А вот Фортран мне вспомнился по индексам в массивах, по FUNCTION и FUNCTION_BLOCK, еще чего-то, не помню...

А по-поводу IL - поправте, почему бредни? была у меня когда-то документация на STEP, видел я там такое (правда давно, может память изменяет) или корни еще дальше?

[Evgeny_CD]

"Вредная" статья
http://www.msclub.ce.cctpu.edu.ru/plc/iec1131.htm
будет время - почитаю, помня все, что тут было сказано.

Да, стоит признать, что в PLC я профан. Но меня _интуитивно_ смущает другое. Возникает ощущение искуственности созданного мира. Т.е. есть мир "обычного" программизма - от 51 однокристалки до кластера на AMD64, который живет по одним, в общем-то, законам. И есть мир PLC, где сущность "обычного" программизма старательно спрятана за масками МЭК и пр. "языков программирования".

Но PLC'шники не одиноки в старании спрятать "отпугивающее мурло" системного программизма. Для этого были изобретены скриптовые языки (Perl, Python, LUA, RUBY, ...), которые
* переносимы с платформы на платформу
* гибки: можно предельно просто писать на "начальном" уровне, а можно использовать язык "на всю катушку", существенно экономя ресурсы на этапе разработки.

Для меня так и остается загадкой, почему PLC'шники не использовали богатый мир скриптовых языков "в своих целях". Одна мысль есть - тот же Python "повзрослел" как раз в 98-99 годах, когда МЭК исполнилось 5 лет... LUA, RUBY еще более молодые языки.

[=AK=]

А по-поводу IL - поправьте, почему бредни? была у меня когда-то документация на STEP, видел я там такое (правда давно, может память изменяет) или корни еще дальше?

Зюбин - единственный, кто утверждает, что IL произошел от STEP5. При этом не приводит никаких оснований для такого утверждения. Поскольку практически любое самостоятельное утверждение Зюбина является тяжким бредом, то это, очевидно, следует отнести туда же.

Первым языком ПЛК, разработанным в 70-х, был "ладдер диаграм", из которого впоследствии произошел LD. Это графический язык, который инструментальной системой транслировался в промежуточный код. Промежуточный код затем исполнялся (интерпретировался) в PLC. Вот этот промежуточный код и был предтечей IL.

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

Для меня так и остается загадкой, почему PLC'шники не использовали богатый мир скриптовых языков "в своих целях". Одна мысль есть - тот же Python "повзрослел" как раз в 98-99 годах, когда МЭК исполнилось 5 лет...

PLC появились в конце 60-х, т.е. когда еще не было даже ни С ни Паскаля. МЭК только к началу 90-х свел воедино и оформил то, что к моменту выхода стандарта существовало более двух десятков лет. Сама работа над МЭК-овским стандартом заняла 15 лет. Так что загадкой должно быть другое, почему современные скриптовые языки не использовали богатый опыт PLC...

[Evgeny_CD]

PLC появились в конце 60-х, т.е. когда еще не было даже ни С ни Паскаля. МЭК только к началу 90-х свел воедино и оформил то, что к моменту выхода стандарта существовало более двух десятков лет. Сама работа над МЭК-овским стандартом заняла 15 лет. Так что загадкой должно быть другое, почему современные скриптовые языки не использовали богатый опыт PLC...

Сильно! Беру свои слова обратно!

[Andrew2000]

Зюбин - единственный, кто утверждает, что IL произошел от STEP5.

Ясно, спасибо за информацию.
На сайте Фиорда в презенташке нашел: "IL - Подобен SIEMENS (Step 5)"
т.е. наверное Step 5 подобен IL

[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-х крупных станциях ... Хорошо, я знаю на каких - с тех пор меня не заманишь на ветку, проходящую черех них.

[AlexandrY]

Я согласен с Evgeny_CD в плане его определения RTOS.
Чета никто не упоминает, что сторонние библиотеки которые юзаются даже не в очень сложных проектах бывают гигантских размеров в соотношении с силами одного программера.
Там без RTOS просто нечего делать.
Итак ограничивая круг ответов на корневой вопрос утверждаем - RTOS может отсутствовать только в несложных системах.
Со всем уважение к многоканальным системам звукозаписи их никак сложной системой не назовешь, даже если они умудряются выдавать звук через Ethernet (с хардварным TCP/IP , все знают, что SM использует для этого Wiznet ).
Я знаю нескольких разработчиков которые делают подобные устройства тоже без всяких RTOS, это показательно.
А вот сложные системы такие как современный мобильный телефон (50 и более разных задач), современный фотопринтер (около 40 разных задач), автомобильный центральный контроллер и т.д. без RTOS сделать не реально. При чем realtime в этих устройствах совсем не на первом месте. Буквы RT в слове RTOS означают лишь только, что эту OS при некоторых усилиях можно заставить работать детерминировано. Но профайлинг RTOS почему-то очень редко встречаеться в инете даже у самих производителей RTOS, это означает, что настоящий детерминизм в RTOS мало кому нужен и добиться его очень трудно при использовании RTOS. Всегда остаеться вероятность, что что-то выполнится не за то время на которое расчитывали.
Отсюда второе наблюдение - RTOS навярняка не нужна в простых, детерминированных программных системах. Это и будут простые PLC и DSP алгоритмы.
Тот же CoDeSys работает без RTOS, продвигаемый мной iCon-L тоже не требует RTOS.
Известный всем стандарт IEC61131-3 для PLC уже заменяется новым стандартом IEC61499 который сам определяет событийно управляемую модель поведения и тоже не нуждаеться в RTOS. Без RTOS могут обходиться и среды разработки управляемые моделью, как I-Logix.

[Виктория]

To Andrew2000

"
Можно еще эту книгу почитать (не слишком доверяя автору, но и не слишком критикуя)
http://www.natahaus.ru/2006/02/17/programm...ontrollery.html
"
_не слишком доверяя автору_ - а можно подробнее? книгу читал, а где надо не доверять?

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

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

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


To Olej

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

Я бы поостереглась насчет школы. Достаточно материал на сайте посмотреть (об использовании этой технологии в современных case-пакетах, фокусники ). Может это мелочи по отношению к глобальному подходу, но навредили себе капитально.

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

Абсолютно согласна (от схемотехников кстати слышала о предпочтених их схемных реализаций - ЗА тактовый генератор и ПРОТИВ использования одновибраторов - тоже из-за надежности)

To All
Собственно эта мысль (или похожая) уже вроде как прозвучала (у Olej и AlexandrY):
При возрастании сложности системы необходима концепция ввода/вывода, учитывающая разнообразность модулей ввода/вывода (непонятно все-таки как Siemens может справиться без ОС в Simatic-ах при большом ассортименте модулей), и их техническое развитие (появление новых функций, ...). Концепция ввода/вывода может и не базироваться на ОС, но постепенно в своем развитии вытягивает (или вытянет) на применение универсальной ОС РВ (т.е. runtime с этой точки зрения лучше все-таки на базе ОС).
Во-вторых, сложность системы зависит от сложности задачи автоматизации (при требовании увеличения производительности в рамках той же аппаратной платформы ПЛК возможно придется отказаться от МЭК). Эту возможность некоторые ПЛК и не исключают (на Си в рамках ОС РВ). Этот недостаток (невозможность применения МЭК) вроде и не недостаток, а ограничение (граница применимости) класса решаемых задач (так как МЭК - ПО проблемно-ориентированное, а не универсальное).
Вопросы все-равно какие-то остаются, выводы не закончены, мысли вертятся, со скриптовыми языками разбираюсь...

Сообщение отредактировал Vic1 - Mar 7 2006, 11:28

[=AK=]

Но идея с Рефлексом привлекательна.

Тогда посмотрите nesC http://nescc.sourceforge.net/papers/nesc-pldi-2003.pdf

[Виктория]

AlexandrY, а какими-нибудь ссылками на русскоязычное описание
iCon-L и I-Logix не можете поделиться?

=AK=, спасибо.

Сообщение отредактировал Vic1 - Mar 7 2006, 11:38

[Andrew2000]

Модель "одновременного" выполнения предоставляют никак не сами МЭК-овские языки, а циклическая организация процесса - ввод - обработка - вывод - ... особенно хорошо это видно, если эти циклы "разбить" вот так: - обаботка - вывод - ввод - ...

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

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

Или я чего-то не понимаю, или одно из двух...
Синхронизация нужна именно в фазах ввод/вывод, т.е. перенос данных в/из подсистемы ввода-вывода в управляющую задачу, чтобы не получить данные из разных циклов (старые и новые). Но в некоторых задачах даже это не принципиально - можно просто иметь на входе текущее значение (проблема здесь, например, как получить правильное 32bit значение в системе с 16bit процессором - надо обеспечить атомарную операцию записи 32bit переменной из подсистемы ввода и чтения ее управляюшей задачей в фазе "ввод/вывод").
А вот в фазе "обработка", действительно, нужно "слева-направо и сверху-вниз". А как иначе? Здесь нет ни ввода ни вывода, и если вы в FBD диаграмме несколько раз пересчитаете локальную переменную, то это или "программный трюк" или "сам дурак" и последним будет именно "правое-нижнее". Или как-то еще. И функциональный блок должен иметь право выполниться, только если вычислены все его входы именно в этом такте - это должна обеспечить сама система МЭК программировани, или "тихо" внутри себя, или подсказывая разработчику путем автоматической расстановки блоков в редакторе "слева-направо и сверху-вниз".

Известный всем стандарт IEC61131-3 для PLC уже заменяется новым стандартом IEC61499 который сам определяет событийно управляемую модель поведения ...

Вроде, не заменяется, а дополняется. Кстати, ни у кого нет стандарта?
На сайте Фиорд-а есть презенташка, но это маловато...

[Andrew2000]

... (непонятно все-таки как Siemens может справиться без ОС в Simatic-ах ...

С наступающим праздником!!! Хорошего настроения и весны!


Siemens-у без ОС хорошо ... Зачем ОС? - распараллелить задачи, а у них в контроллере несколько процессоров (CPU) каждый для своей задачи ... вот здесь и не нужна ОС

[AlexandrY]

To Vic1

http://aly.projektas.lt/Projects/OpenPLC/OpenPLC.htm

[Evgeny_CD]

AlexandrY, как всегда, на высоте.

Если вы хотите использовать iCon-L для своей встраиваемой системы, то один из обычных сценариев таков. Сначала разработчик встроенных систем покупает лицензию на среду разработки iCon-L и адаптирует визуальную оболочку iCon-L для будущих задач, используя средства разработки на языке C. Для этого он создает дополнительные специализированные библиотеки функциональных блоков (ФБ) для визуальной оболочки и целевой платформы. Затем разработчик создает саму целевую платформу или подготавливает уже имеющуюся. После этого разработчик передает подготовленные устройство и визуальную среду разработки iCon-L конечному пользователю, который в дальнейшем разрабатывает свои программы, используя только графическую нотацию среды iCon-L.

Интересно, а сколько это стоит - "лицензия на среду разработки"? Она есть где-нибудь в "препарированном" виде?

[Olej]

Я бы поостереглась насчет школы. Достаточно материал на сайте посмотреть (об использовании этой технологии в современных case-пакетах, фокусники ). Может это мелочи по отношению к глобальному подходу, но навредили себе капитально.

Я не знаю детально что за материалы на этом сайте, но я хорошо знаю нескольких авторов (по публикациям) из "школы Шалыто", может не на этом сайте, а на соседних в С.-Петербурге ... если найду URL - кину... но это очень интересно и продуктивно, тем, что это именно сквозная технология, обеспечивающая "контроль качества" и высочайшие надёжностные характеристики. Кроме того и практически выполненные в этой технологии работы: там несколько автоматизированных систем управления корабельным дизельным оборудованием - это "не игрушечные" задачки.

[=AK=]

Если уж быть совсем точным, то таких "эпох" было не 2: релейные - PLC, а 3: релейные (...50-60г.г.) - жёсткая логика (70-е) - PLC ...

Не вижу оснований для введения новой "эпохи".
Во-первых, "жесткая логика" принципиально не отличается от реле. Недаром же в ходу термин "твердотельное реле", хоть это формально и не то же самое, что "жесткая логика", но мысль, надеюсь, понятна.
Во-вторых, 70-е были началом эпохи PLC, которые появились в конце 60-х - начале 70-х. Системы управления на "жеской логике" были "последей отрыжкой" релейных шкафов управления.

хотя потенциальные схемы, в принципе - производительнее

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

никто не обязывает вас реализовывать логику на языках МЭК ... рисуйте её на здоровье на С/С++ или чём хотите - обеспечьте только синхронное обновление всех внешних данных.

Это будет не языком С/С++, а неким принципиально иным языком с синтаксисом, похожим на С/C++. Тогда как убрав требование "слева направо, сверху вниз" мы никак не изменим сущность языков МЭК, но просто уберем "заморочку" конкретной реализации.

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

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

В чем, если не секрет? Это всего лишь цитата с малым комментарием.

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

[one_man_show]

Совсем не желая подлить масло в огонь спора про РТОС, просто добавлю и свои 5 копеек рассказом про два прозрения.

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

В то время по долгу службы приходилось самому делать проекты, в которых есть и верхний уровень (на СКАДе или самодельный) и низкий уровень на МК. Ни в одном из них на тот период не применял РТОС. Но по мере появления опыта, реализуя новые проекты, стал-таки применять РТОС.

Тут вдруг первое прозрение: я же тогда дизассемблировал приложение на РТОС! Стало понятно, почему тот проект был так тяжел в понимании, опыта с РТОС тогда не было, идеалогия была неизвестна и пр.

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

Обобщаю:
- если хочу получить переносимость, совместимость и многое другое, о чем говорилось в постах ранее в пользу РТОС, обязательно её использую
- если не_хочу/не_могу использовать РТОС, а пользуюсь супер-петлей, тем не менее, результат ассимптотически приближается к тому, как-будто я ее использую

Пытаюсь ответить на вопрос "Когда не нужна ОС РВ?":
- когда не знаешь, что это такое (долго изучать "новые рельсы", ...)
- когда знаешь, но не хочешь её использовать (упрусь и сделаю всё сам, ...)
- когда знаешь, но не можешь её использовать (не хватает ресурсов, ...)

Остальные миллион вариантов на мой взгляд будут напоминать ответы в спорах: "Какой процессор лучше INTEL или AMD?", "Какие ПЛИС лучше ALTERA или XILINX?", "Какая среда разработки лучше...", "Какой МК лучше...", "На чем лучше писать, на Си или на АСМе?" и т.п.
После чего ветка просто плавно перейдет в раздел "Общение".

А хотелось бы, чтобы начинающему было легче в наших постах (на нашем опыте) уловить ответ на поставленный вопрос и самому принять решение "нужна или не нужна и в каких случаях"

[AlexandrY]

To Evgeny_CD

Ребята из Pro-Sign вообще-то до недавнего времени не продавали лицензии за пределами Германии.
У них даже нет документации на английском.
В Германии они за это берут что-то около десятка тыс. евро.
Но партнерам могут дать и бесплатно.

[Evgeny_CD]

Обобщаю:
- если хочу получить переносимость, совместимость и многое другое, о чем говорилось в постах ранее в пользу РТОС, обязательно её использую
- если не_хочу/не_могу использовать РТОС, а пользуюсь супер-петлей, тем не менее, результат ассимптотически приближается к тому, как-будто я ее использую

Пытаюсь ответить на вопрос "Когда не нужна ОС РВ?":
- когда не знаешь, что это такое (долго изучать "новые рельсы", ...)
- когда знаешь, но не хочешь её использовать (упрусь и сделаю всё сам, ...)
- когда знаешь, но не можешь её использовать (не хватает ресурсов, ...)

- добавить нечего!

Ну а насчет "прозрения" - каждый инженер прошел через это. И не раз

Ребята из Pro-Sign вообще-то до недавнего времени не продавали лицензии за пределами Германии.
У них даже нет документации на английском.
В Германии они за это берут что-то около десятка тыс. евро.
Но партнерам могут дать и бесплатно.

Нада, почти халява. . Знать придется для своих девайсов более простые решения использовать - типа портированной под eCos LUA.

[zltigo]

Пытаюсь ответить на вопрос "Когда не нужна ОС РВ?":
- когда не знаешь, что это такое (долго изучать "новые рельсы", ...)
- когда знаешь, но не хочешь её использовать (упрусь и сделаю всё сам, ...)
- когда знаешь, но не можешь её использовать (не хватает ресурсов, ...)

Абсолютно согласен с вышеизложенным. Других причин дейстительно нет. При этом
ОБЬЕКТИВНАЯ только одна-единственная - третья.

[Evgeny_CD]

Пытаюсь ответить на вопрос "Когда не нужна ОС РВ?":
- когда не знаешь, что это такое (долго изучать "новые рельсы", ...)
- когда знаешь, но не хочешь её использовать (упрусь и сделаю всё сам, ...)
- когда знаешь, но не можешь её использовать (не хватает ресурсов, ...)

Абсолютно согласен с вышеизложенным. Других причин дейстительно нет. При этом
ОБЬЕКТИВНАЯ только одна-единственная - третья.

Я бы переформулировал так:

если после подсчета совокупной стоимости проекта стало ясно, что имеет смысл использовать более слабый (и дешевый) процессор (память) ценой

* усложнения поддержки кода (вот уволится программер, который все это написал - кто ковыряться будет?)
* отказа от использования кода этого проекта в других проектах
* отказа от использования готовых модулей сторонних разработчиков в проекте

то да, тогда имеет смысл отказаться от OS (или RTOS как разновидности OS). Но перед этим надо крепко подумать.

[Olej]

Зюбин - единственный, кто утверждает, что IL произошел от STEP5. При этом не приводит никаких оснований для такого утверждения. Поскольку практически любое самостоятельное утверждение Зюбина является тяжким бредом, то это, очевидно, следует отнести туда же.

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

А вот в отношении предмета статьи (которая, может, и не так интересна, и изобилует неточностями) - так куда интереснее самой статьи дальнейшее обсуждение, развернувшееся на форуме журнала "СТА":
http://forum.cta.ru/forum_posts.asp?TID=10...C%F3&PN=0&TPN=2
- которое растянулось на 53 (! ) форумных страниц, и куда чётче выразило основную точку зрения Зюбина и его сторонников, не так уж и малочисленных:

В МЭКе решались (скорее всего) задачи защиты
мега-корпораций (см. список участников) посредством
стандартизации. PLC Open декларирует построение
"открытых" систем на базе МЭК 61131-3, а по сути
разрабатывает некий параллельный стандарт.

Отвечаю. Цель статьи была сгладить возможный пик
эйфории от рекламной кампании по раскручиванию
МЭК 61131-3... сделать так, чтобы русскоязычный
пользователь прежде, чем выложить килобаксы за
какой-нибудь продукт на базе стандарта МЭК 61131-3,
семь раз подумал...

Я не думаю, что люди, писавшие эту отсебятину
про кросс-платформенную переносимость и
независимость от производителя, не читали стандарт
и не знают текущего положения с _полной_
несовместимостью продуктов на базе МЭК 61131-3...

но мне не интересен ни IEC 61131-3,
ни PLCopen, т.к. ПО на базе языков стандарта (в силу
убогости этих языков) не позволяет решать
задач, которые мне приходится сталкиваться в жизни.
И это хроническое состояние стандарта, которое
невозможно исправить интеллектуальными и материальными
затратами на CASE-оболочки и прочие WIMP-интерфейсы.

И кое-что меня (IMHO и только!), после знакомства (в разной мере) с некоторыми МЭК tools: ISaGRAF, CoDeSys, Concept, Unity Pro - "греет" в таком восприятии МЭК ...
Во всех этих tools есть 2 ключевых вещи, которые нужно обеспечить при прораммировании логики любой АСУТП (и это "классическому" программисту может быть на первый взгляд неочевидно):

1. цикличность фаз: - ввод - обработка - вывод ... и "единомоментности" фаз ввод/вывод, которые, на самом деле, скорее даже не будут реальными вводом и выводом, а - обменной буферизацией с посдсистемой реального ввода-вывода;

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

После этого - можете прописывать логику в чём угодно, хоть МЭК, хоть С/С++, хоть ... что знаете.

[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=]

объявить чьё-то мнение бреднями, особенно хорошо работает в отсутствии этого кого-то ...

Вы уверены в этом самом "отсутствии"? Отсутствие постов не всегда является верным тому признаком.

В МЭКе решались (скорее всего) задачи защиты мега-корпораций (см. список участников) посредством стандартизации.

Паранойя

Отвечаю. Цель статьи была сгладить возможный пик эйфории от рекламной кампании по раскручиванию МЭК 61131-3... сделать так, чтобы русскоязычный пользователь прежде, чем выложить килобаксы за какой-нибудь продукт на базе стандарта МЭК 61131-3, семь раз подумал...

Сомнительно, особенно с учетом того, что Зюбин не предлагает взамен ничего реального. Его собственные поделки "доступны" только в виде пустых статей всевдонаучного вида.

Я не думаю, что люди, писавшие эту отсебятину про кросс-платформенную переносимость и
независимость от производителя, не читали стандарт и не знают текущего положения с _полной_
несовместимостью продуктов на базе МЭК 61131-3...

Бред. МЭК 61131-3 - это стандарты на языки, а не на продукты. Человек, освоивший программирование на этих языках, без особых проблем будет использовать продукты разных производителей, соответствующие стандарту. Неужто анархия "до-МЭКовских времен" хоть чем-то лучше?

ПО на базе языков стандарта (в силу убогости этих языков) не позволяет решать задач, которые мне приходится сталкиваться в жизни.

Судя по флейму в СТА, он не знал элементарных вещей, начиная с того, что ST является структурированным языком программирования.

После этого - можете прописывать логику в чём угодно, хоть МЭК, хоть С/С++, хоть ... что знаете.

Дык, кто мешает? Неужто стандарт МЭК как таковой? "Несоблюдение стандарта преследуется по закону" (с), что ли?

[Olej]

Дык, кто мешает? Неужто стандарт МЭК как таковой? "Несоблюдение стандарта преследуется по закону" (с), что ли?

Я только хотел сформулировать своё мнение (IMHO), что в "культуре PLC", которую здесь затронули, есть "фундаментальные" находки - вот те 2 позиции, которые я называл раньше, и которые совсем не очевидны "классическим" программистам, а есть и ... вещи и спорные, по крайней мере: вопрос вкуса, к чему относятся и сами языки МЭК ... по крайней мере и такое мнение имеет право быть.

[=AK=]

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

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

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

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

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

[SM]

если после подсчета совокупной стоимости проекта стало ясно, что имеет смысл использовать более слабый (и дешевый) процессор (память) ценой

* усложнения поддержки кода (вот уволится программер, который все это написал - кто ковыряться будет?)
* отказа от использования кода этого проекта в других проектах
* отказа от использования готовых модулей сторонних разработчиков в проекте

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

Отказ от использования в других проектах - с какого бодуна? Я как пользовалься одними и теми же подпрограммами для разных проектов на совместимых процах, так и буду.

Готовые модули - так они обычно к конкретной ОС не привязаны. Если сделаны корректно. И никто не мешает их подключить к проекту без ОС (но, конечно, 100 раз подумав, можно ли доверять разработчикам, как там с поддержкой, на сколько оптимальное решение, и т.п.)

P.S. Для AlexanderY - И что, что визнет? Ну понадобился бы еще один уровень - TCP/IP - но это все равно бы не послужило причиной поставить OS в том конкретном девайсе Для добавления задачи мне достаточно врезать еще один (или несколько) конечных автоматов в цепочку. Тем более, что единственной RTOS была бы DSP/Bios, от которой толку, как от козла молока для решения этих задач.
Про мобилы и аналогичное - согласен - там OS нужна (в первую очередь пользовательский интерфейс, запуск приложений сторонних производителей). Но вот RT вовсе не обязательно. За RT там отвечает не тот, кто за юзерскую шнягу.

[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 дисциплина) - это на-вроде "осетрина второй свежести" ... с которой известно как дело обстоит, асинхронностью здесь и не пахло

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

[Evgeny_CD]

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

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

Отказ от использования в других проектах - с какого бодуна? Я как пользовалься одними и теми же подпрограммами для разных проектов на совместимых процах, так и буду.

Готовые модули - так они обычно к конкретной ОС не привязаны. Если сделаны корректно. И никто не мешает их подключить к проекту без ОС (но, конечно, 100 раз подумав, можно ли доверять разработчикам, как там с поддержкой, на сколько оптимальное решение, и т.п.)

Про это уже хорошо написали:

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

Обобщаю:
- если хочу получить переносимость, совместимость и многое другое, о чем говорилось в постах ранее в пользу РТОС, обязательно её использую
- если не_хочу/не_могу использовать РТОС, а пользуюсь супер-петлей, тем не менее, результат ассимптотически приближается к тому, как-будто я ее использую

В общем, решение задачи "Быть ли не быть" применительно к ОСи утекло в область философии, к ресурсам, процам и пр. отношение имеющую слабо.

[SM]

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

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

Ну почему же принципиальная. Я эту программу не один пишу на самом деле, даже больше - я там пишу довольно малую часть. Но не суть важно - я про "в принципе" (и это один частный случай, я думаю можно догадаться, о чем именно речь - АОНы Русь ). Но по-другому именно там нельзя, конкурренция больно уж жестокая и война за центы. И с поддержкой у нас все в полном порядке аж с начала 90-х. И, кстати, в этот проект точно РТОС не попадет. Ибо считаем каждый байт. Хотя, по идее, ей там самое место быть бы.

[Olej]

И вот в этой области RTOS уж точно не нужна. На нее только время терять.

Я так и не пойму: из-за чего же вы так копья то ломаете?
Понятно же: для определённого класса задач вполне может быть даже оптимальным никакую OS среду. И как ничто под этот класс попадают все задачи циклического "перелопачивания" потока данных, и задачи PLC и задачи ЦОС, которые здесь упоминались - лучшие образцы того.
Второй критерий: число и разнородность подзадач, составляющих систему - как только или число или разнородность превышает некоторый предел ... всё, сосуществование их в среде OS становится оптимальнее (да вы это и сами говорите, далее, когда об "мобиле" говорите).

Готовые модули - так они обычно к конкретной ОС не привязаны. Если сделаны корректно. И никто не мешает их подключить к проекту без ОС (но, конечно, 100 раз подумав, можно ли доверять разработчикам, как там с поддержкой, на сколько оптимальное решение, и т.п.)

А что тогда "готовые модули" и что тогда OS, и где между ними проходит такой радикальный водораздел? Т.е. если вы статически компонуете задачу с ... модулем шедулера, стеком сетевых протоколов, ... и т.д. и т.п - то это "готовые модули", а если ... (что?) ... они связываются динамически, DLL или что? - так это OS?
Вон в realtime продуктах фирмы OneTarget (я их наблюдаю больше 10-ти лет) - целевая система всегда и во всех компонуется статически со всеми нужными причандалами, и только после этого только загружается на целевую платформу... (хотя OneTarget и избегает тщательно термина RTOS). Или тот жк pSOS, где всё происходит примерно так же.

P.S. Для AlexanderY - И что, что визнет? Ну понадобился бы еще один уровень - TCP/IP - но это все равно бы не послужило причиной поставить OS в том конкретном девайсе Для добавления задачи мне достаточно врезать еще один (или несколько) конечных автоматов в цепочку.

Вах-вах-вах... вот TCP/IP в качестве примера вы выбрали напрасно...
Тем более, это действительно актуально, здесь кто-то уже говорил "... я сначала посмотрю есть ли там TCP/IP..." (прошу прощения за неупоминание автора и со своих слов - чтоб долго не искать).
И какой же это вы стек TCP/IP писать станете в конечных автоматах? (я не о том, как вы его станете писать, я вам поверю, что вы его напишите - а о функциональности, о том что вы туда станете включать-писать)... Ведь единственным легитимным "законом" для IP есть RFC, их на сегодня больше 3000, некоторые до нескольких сот страниц... и написаны все так: "... в этой части настоящий RFC отменяет действие RFC XXX, YYY, ZZZ ...". Давайте посмотрим:
- разрешение адресов ARP - будем писать? или статически привяжем соответствие MAC - IP?
- протокол ICMP - будем писать? или уведомление об ошибках будем делать "своим способом"...
- а если "да" - то какие запросы ICMP будем реализовывать? - всех их там очень дохрена, вплоть до диагностики состояния физического канала - оно нам нужно?
- а маскирование IP и бесклассовую маршрутизацию - будем делать? или ну её...
- а в TCP поверх IP - алгоритм Нэйгла станем прописывать? а отсроченные подтверждения ACK? а ведь алгоритм Нэйгла с и без отсроченных подтверждений ... это, как говорят в Одессе "две большие разницы"(с), и работает совсем по-разному - можем что-то не то получить, что хотели...
- вам UDP больше люб для потоковых передач? а что, UDP будем сегментировать под размер пакета MAC? а что ARP разрешение будем запрашивать для каждого IP сегмента (что создаст проблемы, см.У.Стивенса) или на весь UDP один раз запросим ARP (так это смешение функций уровней, и дальше породит ещё многократ больше проблем, чем в 1-м случае)...
- а бродкастинг? а мультикастинг? ...
Это я так, "слегка пожонглировал" ... а в 3000 RFC x ~100 стр. (на самом деле больше) - представьте сколько там ... миллионв вопросов? и не зря RFC - >3000, потому что за более 25 лет ошибок новые RFC исправляли старые, и дополняли механизмами, закрывавшими слабые места...

Так что писать будем?

Про мобилы и аналогичное - согласен - там OS нужна (в первую очередь пользовательский интерфейс, запуск приложений сторонних производителей). Но вот RT вовсе не обязательно. За RT там отвечает не тот, кто за юзерскую шнягу.

С RT вообще нужно поаккуратнее быть...
Почитайте вот здесь одно из мнений:
http://qnxclub.net/files/articles/RemarksO...TheMargins.html
- о том, что realtime применительно к OS - это вообще скорее рекламно-рыночный термин, чем какой другой (от себя добавлю для справки, что пишет это человек, в своё время работавший в "ядре" разработчиков систем безопасности АЭС xUSSR, а сейчас представляющий не последнее место в славной инженерной мысли города Монреаля).
Не путать с realtime целевой системой, а вот realtime OS ... ?
В гораздо большей мере OS может быть хорошо или плохо сделанной (и ещё есть самый широкоизвестный класс OS "очень плохо сделанный" - распространённость которого и дало возможность рекламно педалировать "риэлтаймовость" OS) - и это хорошо/плохо в гораздо большей мере определяет вот ту степень "риэлтаймовости".

[Andrew2000]

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

Смысл фразы теряется без этого многоточия. Изначально было:
"По поводу технологов - их язык FBD - т.е. функциональные блоки (LabView туда же).
Они так видят мир И не надо им мешать."
Я писал именно про языки функциональных блоков.

... Concept & Unity Pro от Schneider-Electric ...: в проекте можно организовать несколько задач (в Unity Pro даже - много: ...: фоновая задача, периодическая задача, приоритетная задача, ... N таймерных задач, M задач "по событиям" ... вас пока ничего здесь не смущает? :D
...
Я не раз спрашивал ... и интеграторов ISaGRAF и CoDeSys ...
Они мне отвечают, но сильно нечленораздельно, что-то типа: ... если CoDeSys выполняется под управлением RTOS, то в системе может выполняться несколько задач...

Ничего не смущает. Многозадачность предусмотрена стандартом МЭК, значит имеет право быть.
А как ее реализовал Schneider или как ей пользуетесь Вы - другой вопрос.

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

Если нет "средств защиты" - не пользуйтесь этой системой - возьмите другую МЭК систему, где это есть.

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

Не хотите - не платите: покупайте, например, не ISaGRAF Pro, а ISaGRAF v3.x - он однозадачный.

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

Смущает, поэтому у нас делается так: у ведущего PLC IP-адрес N, а у резервного _всегда_ N+1. SCADA видит только 1 PLC (про второй она вообще ничего не знает, точнее знает, но только для контроля, что на адресе N+1 кто-то есть - живой).
В фазе "ввод" после собственно ввода ведущий PLC "сбрасывает" значения входов в резервный контроллер и новый такт они начинают синхронно. Если "умрет" ведущий потеряется максимум один такт.

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

IP может быть _любой_ из допустимого диапазона. Я могу его назначать "руками", автоматически по определенному алгоритму (как позволит фантазия) или через _DHCP_ (BOOTP).
ARP, если память не изменяет, определение MAC адреса по IP адресу.
DNS - определение IP адреса по доменному имени.

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

Управление исполнением может и обеспечивается SFC, но только в пределах одной задачи.
Если говорить про POU Program (кажется так это называется), то они должны выполняться под управлением ОС (РТОС). А точкой входа каждой Program может уже быть программа на SFC (или любом другом МЭК языке).

[Evgeny_CD]

...Ну почему же принципиальная. Я эту программу не один пишу на самом деле, даже больше - я там пишу довольно малую часть. Но не суть важно - я про "в принципе" (и это один частный случай, я думаю можно догадаться, о чем именно речь - АОНы Русь )...

Вау! Так у Вас там вполне нормальная групповая технология разработки, а Вы тут нас ужасами пугаете.

Малость : а что, в современных АОН TCP/IP есть? Я как-то давно не отслеживаю "мир АОНов". И второй нескромный вопрос: а что за процессор, для которого Вы так тщательно байты считаете - если это не секрет, конечно?

Немного сбоку, но все же.

Тут несколько раз упоминали Modula, Modula-2. Я, к стыду своему, не знаком с этим языком (и стоящей за ним философией). Но вот нарыл интересную статью - может, кому она тоже пригодится.
http://www.computer-museum.ru/histussr/kronos.htm

Интересно, какой все-таки кайф в этой Модуле ?

[Olej]

Интересно, какой все-таки кайф в этой Модуле ?

В Modula кайф несомненно большой
Это одна из ступенек развития линейки языков Н.Вирта, и стоит того, чтобы в ней поковыряться...
Но это имеет гораздо больше смысла относительно именно "классического" программирования, с высокой степенью параллелизма (особенно Oberon - Zenon развития этой линии), но не к предмету нашего обсуждения...

[Evgeny_CD]

В свете обсуждения это будет интересно
http://electronix.ru/forum/index.php?showt...t=0&#entry94271

[Olej]

В свете обсуждения это будет интересно
http://electronix.ru/forum/index.php?showt...5533;entry94271

Цитата оттуда , чтоб разговор поддержать :

Интересно, это что - начало новой эры - PLC со скриптовыми языками? Более того, начало эпохи сенсорных сетей. Ибо на таких коробченках систему мониторинга для большого дома сваять - самое то. Zigbee опять же есть.

Возможно и начало новой эры, только начало это не сегодня началось - 2-3 последних года много из не последнего эшелона производителей, почувствовав здесь нишу, начали теснить брандов, см. напр. WAGO, VIPA и др. - даже новый термин сложился PC based PLC. Но и большой "эры" в том нет - просто внутреннюю архитектуру PLC сделали открытой и на базе универсальных архитектур, чипсетов etc. - а когда "открыто", то заходи и пользуйся любыми tools: хоть от изготовителя, хоть от 3-й стороны, хоть сам изобретай...

[SM]

Второй критерий: число и разнородность подзадач, составляющих систему - как только или число или разнородность превышает некоторый предел ... всё, сосуществование их в среде OS становится оптимальнее (да вы это и сами говорите, далее, когда об "мобиле" говорите).

Скорее не число и разнородность, а требование к запуску задачи пользователем и добавлении новых (и возможно) сторонней разработки приложений. Если количество задач определено, и все они собраны статически, то РТОС в большинстве случаев жесткого реалтайма только жрет ресурсы, а пользы не несет. (про асутп я ничего не знаю, не был там)

А что тогда "готовые модули" и что тогда OS, и где между ними проходит такой радикальный водораздел? Т.е. если вы статически компонуете задачу с ... модулем шедулера, стеком сетевых протоколов, ... и т.д. и т.п - то это "готовые модули", а если ... (что?) ... они связываются динамически, DLL или что? - так это OS?

Готовые модули - это модули, решающие какую-то реалтайм (контексте вопроса) - задачу. Например аудио-кодек G.723.1. ОС - это совокопнусть из какого-то API (может быть очень и очень разным), якобы упрощающего жизнь программистам, и диспетчера задач и прерываний. А как связывать готовые модули с программой - личное дело программиста. Но динамически думаю излишне.

P.S. Для AlexanderY - И что, что визнет? Ну понадобился бы еще один уровень - TCP/IP - но это все равно бы не послужило причиной поставить OS в том конкретном девайсе Для добавления задачи мне достаточно врезать еще один (или несколько) конечных автоматов в цепочку.

Вах-вах-вах... вот TCP/IP в качестве примера вы выбрали напрасно...
....
Так что писать будем?

Вот не надо мне тут объяснять, из чего TCP/IP состоит и что такое RFC. Я все равно остаюсь того-же мнения, что принцип программирования на КА эффективнее, чем шедулер с сохранением контекстов (если оно, конечно, не аппаратное). Писать я буду тот минимум, который необходим задаче. ARP, ICMP, броадкастинг,... короче функциональный аналог визнета, чтобы оно просто подключилось к имеющимся работающим с визнетом dhcp и собственным протоколом обмена данными. И совершенно ни на грамм не сложнее писать TCP/IP под какую-то ОС, чем сделать то же на КА.

С RT вообще нужно поаккуратнее быть...
Почитайте вот здесь одно из мнений:
http://qnxclub.net/files/articles/RemarksO...TheMargins.html
- о том, что realtime применительно к OS - это вообще скорее рекламно-рыночный термин, чем какой другой (от себя добавлю для справки, что пишет это человек, в своё время работавший в "ядре" разработчиков систем безопасности АЭС xUSSR, а сейчас представляющий не последнее место в славной инженерной мысли города Монреаля).
Не путать с realtime целевой системой, а вот realtime OS ... ?

Вот именно, что одно из мнений. Я же придерживаюсь исключительно определения, отталкиваясь от реалтайм целевой системы. Что RTOS обязана обеспечивать отклик системы за заданное время. И, кстати, та RTOS, с котороя я изредка имею дело (это DSP/Bios от TI) полностью соответствует этому.

Малость : а что, в современных АОН TCP/IP есть? Я как-то давно не отслеживаю "мир АОНов". И второй нескромный вопрос: а что за процессор, для которого Вы так тщательно байты считаете - если это не секрет, конечно?

Процессор у нас самодельный. http://www.venus.ru/news.php?id=67&arc=0&sct=1
TCP/IP в АОНах нет. Не одними АОНами

Вау! Так у Вас там вполне нормальная групповая технология разработки, а Вы тут нас ужасами пугаете.

Да не совсем она там нормальная. Всего два человека делают. И я только ЦОС-куски. И никто более точно в коде не разберется, хотя бы потому, что процессор имеет модифицированную систему команд.

[Evgeny_CD]

Процессор у нас самодельный. http://www.venus.ru/news.php?id=67&arc=0&sct=1

Вот это да! Аоностроители доросли до своего процессора (пусть и на 51 архитектуре)! Интересно, и вправду сами весь кристалл проектировали, или что-то покупали | тырили? Особенно это

синтезатор звука совместимый с Yamaha YM2149F и AY-3-8910 фирмы General Instruments – 3 генератора чистого тона и формирователь шумовых эффектов;

Вызывает искреннее уважение! Интересно, какие объемы надо иметь, чтобы на свой кристалл замахиваться (пусть даже по скромной технологии 0.5)?

[Olej]

А что тогда "готовые модули" и что тогда OS, и где между ними проходит такой радикальный водораздел? Т.е. если вы статически компонуете задачу с ... модулем шедулера, стеком сетевых протоколов, ... и т.д. и т.п - то это "готовые модули", а если ... (что?) ... они связываются динамически, DLL или что? - так это OS?

Готовые модули - это модули, решающие какую-то реалтайм (контексте вопроса) - задачу. Например аудио-кодек G.723.1. ОС - это совокопнусть из какого-то API (может быть очень и очень разным), якобы упрощающего жизнь программистам, и диспетчера задач и прерываний. А как связывать готовые модули с программой - личное дело программиста. Но динамически думаю излишне.

Я не о том говорил: а чем тогда RTOS (не-RT-OS) отличается от большого набора готовых модулей (планировщик, стек сети, файловые системы, ... много-много) - из которых в целевую систему мы можем выбрать только те ... готовые модули , которые требуются в этой системе.
Чем принципиально отличается одно от другого?

Вот не надо мне тут объяснять, из чего TCP/IP состоит и что такое RFC.
...
Писать я буду тот минимум, который необходим задаче. ARP, ICMP, броадкастинг,... короче функциональный аналог визнета, чтобы оно просто подключилось к имеющимся работающим с визнетом dhcp и собственным протоколом обмена данными. И совершенно ни на грамм не сложнее писать TCP/IP под какую-то ОС, чем сделать то же на КА.

Я и не собирался вам ничего объяснять... тем более что обстоятельно это "объяснять" заняло бы несколько тысяч страниц, и явно не для форума занятие ...
И вовсе не высказывал сомнения, что вы напишете стек протоколов...
Я как-раз и хотел услышать, что "писать я буду тот минимум," - а это значит, что в этом неполном (логически неполном!) минимуме всегда вылезут внутренние противоречия, и если сегодня "оно просто подключилось к имеющимся работающим" ... то это ни на грамм не увеличивает гарантии, что завтра в других условиях оно тоже подключится...
Именно поэтому, во многих TROS есть несколько стеков TCP/IP: tinny (без транзитного форвардинга, например), IPv4, IPv6, ... - и потребитель уже из компромисса требуемых ресурсов и возможностей в целевую систему скомпонует тот, который его устраивает ... но что самое интересное: если через 1 год окажется, что функциональности не хватает всё-таки - то перекомпоновать с другим стеком можно целевую систему за 10 минут.

Сообщение отредактировал Olej - Mar 13 2006, 08:44

[SM]

Я не о том говорил: а чем тогда RTOS (не-RT-OS) отличается от большого набора готовых модулей (планировщик, стек сети, файловые системы, ... много-много) - из которых в целевую систему мы можем выбрать только те ... готовые модули , которые требуются в этой системе.
Чем принципиально отличается одно от другого?

Тем, что файловые системы, стеки сетей, и т.п. - это не есть часть RTOS. Это системные задачи, которые под ней крутятся. Другое дело, что они могут быть либо встроены в ОС (худший случай), либо идти дополнительным пакетом (как например NDK для TI DSP). А к самой ОС относится только ядро и сервисы вокруг него - синхронизация, доступ к I/O, интерфейс к драйверам, и т.п. То есть собственно ядро.

Вот не надо мне тут объяснять, из чего TCP/IP состоит и что такое RFC.
...
Писать я буду тот минимум, который необходим задаче. ARP, ICMP, броадкастинг,... короче функциональный аналог визнета, чтобы оно просто подключилось к имеющимся работающим с визнетом dhcp и собственным протоколом обмена данными. И совершенно ни на грамм не сложнее писать TCP/IP под какую-то ОС, чем сделать то же на КА.

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

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

[Виктория]

Да ... И разрослась вроде ветка, но что то не по существу много. Хотя этот упрек больше в мою сторону как автору темы (дискуссия вышла из под контроля ). В оправдании только - праздник, работа, нет I-neta, не было форума 1 сутки!

To Olej

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

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

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


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

X++;


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

Собственно, слегка повторяюсь (за уже выступающими). Все-таки в МЭК реализован только минимум необходимых средств для решения задач автоматизации ТП. Используется принцип бритвы Оккама ("То, что можно объяснить посредством меньшего, не следует выражать посредством большего", вот бы этот принцип применить к нашему обсуждению -> останется не больше страницы, наверно , и без личных оскорблений, главное)
Olej, по существу Ваших замечаний. Мне представляется, что все эти таймерные задачи, задачи по событию все равно реализованы через принцип синхронного управления (т.е. проверка событий жестко привязана к такту системного времени, в отличие от ОС). Поэтому одна задача в Вашем случае (или ее логическая часть - сегмент в FBD, шаг в SFC), не сможет изменить данные у другой. Или по другому - сегменты FBD и шаги SFC - это возможности для реализации критических секций.
Еще раз повторяюсь - МЭК не идеал. Может быть в заключении все-таки нащупать ограничения применимости хотя бы в области АСУТП..., а лучше бы и возможности использования и в других областях...

З.Ы.:
to =AK=

(Olej @ Mar 11 2006, 23:19)

объявить чьё-то мнение бреднями, особенно хорошо работает в отсутствии этого кого-то ...

Вы уверены в этом самом "отсутствии"? Отсутствие постов не всегда является верным тому признаком.

Можно и пригласить, Владимир Евгеньевич со всеми корректен при обсуждении. Боюсь, только что ничего нового он для себя из нашей "дискуссии" не почерпнет

[Olej]

Тем, что файловые системы, стеки сетей, и т.п. - это не есть часть RTOS. Это системные задачи, которые под ней крутятся. Другое дело, что они могут быть либо встроены в ОС (худший случай), либо идти дополнительным пакетом (как например NDK для TI DSP). А к самой ОС относится только ядро и сервисы вокруг него - синхронизация, доступ к I/O, интерфейс к драйверам, и т.п. То есть собственно ядро.

Это неверно ... т.е. для какой-то 1-й конкретной ОС - верно, для какой-то 2-й - верно, но с очень большими оговорками, для какой-то 3-й - и вовсе не соответствует...
Вот RTOS QNX, например: у неё ядра (там это микроядро называется) - меньше 64К, и операций (примитивов API) микроядра <128, да и примитивы то уровня такого: передать сообщение уровня микроядра от одного адресата к другому... Что проку прикладнику от этих примитивов, и какие накладные ему издержки от 64К микроядра? А всё остальное, и "синхронизация, доступ к I/O, интерфейс к драйверам" ... вообще всё что есть в ОС - это всё "набор отдельных компонентов" ... любой из них - хотите прикрутите, хотите выбросьте.
В точности та же картина будет в любой микроядерной ОС (а их не так и мало), но и в моноядерной - тоже степень "интегрированности" будет меняться радикально "от-раза-к-разу" ... вон в тех же статически компонуемых tools от OneTarget будет та же история...

Сообщение отредактировал Olej - Mar 13 2006, 12:23

[SM]

Это неверно ... т.е. для какой-то 1-й конкретной ОС - верно, для какой-то 2-й - верно, но с очень большими оговорками, для какой-то 3-й - и вовсе не соответствует...

Я не претендую на какое-то верное или неверное определение. Я просто сказал такое определение, в рамках которого я нахожусь, ведя все разговоры про RTOS. Что подразщумеваю под RTOS, а что под остальными модулями. И от этого определения не отклоняюсь, четко поделив, чьи задачи где. А уж какая из реальных ОС как собрана и из чего состоит - это совсем другой вопрос. Это вопрос выбора. А не "нужна-не-нужна"

[Olej]

Да ... И разрослась вроде ветка, но что то не по существу много. Хотя этот упрек больше в мою сторону как автору темы (дискуссия вышла из под контроля ). В оправдании только - праздник, работа, нет I-neta, не было форума 1 сутки!

Это потому, что нельзя тему обсуждения так расплывчато формулировать: в одной области приложения - свои будут особенности, в другой - совсем напротив .

"Когда не нужна ОС РВ?"

Я когда яму копаю, например, в саду - мне в это время точно не нужна ОС РВ, и без РВ - тоже ...

[Виктория]

Это потому, что нельзя тему обсуждения так расплывчато формулировать: в одной области приложения - свои будут особенности, в другой - совсем напротив .

Заголовок темы. Надо было бы так "ОС РВ или проблемно-ориентированный язык программирования?" или еще уже
"Достоинства и недостатки проблемно-ориентированного ПО"

Прокол понятен - смотрят по заголовку и последней странице (оптимизация такая ). Первый пост не читают - где собственно тема и формулируется

Сообщение отредактировал Vic1 - Mar 13 2006, 14:58

[Виктория]

Готовлю выводы по обсуждению (потом, наверно, тему закрою как автор).
Со скриптовыми языками что-то пока нулевой эффект.
Как они смогут помочь в создании такой конструкции (пример от Andrew2000)?

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

Если использовать скриптовые языки, то только путем введения новых классов, объектов и методов? Что-то тяжеловатый подход. Что мне даст этот подход кроме семантической проверки на уровне ООП? Или я до конца все-таки не понимаю. По описанию Java и Питона не вижу простых путей, а примеров внедрения подобных конструкций в I-net тоже что-то нет

[Evgeny_CD]

Бука по промавтоматике - может кому пригодится в свете затронутых тут МЭК языков
http://electronix.ru/forum/index.php?showtopic=13906

[=AK=]

Че-то я там про МЭК языки не нашел. Собственно, не нашел там вообще ничего кроме пустого трепа.

[Виктория]

А хотелось бы, чтобы начинающему было легче в наших постах (на нашем опыте) уловить ответ на поставленный вопрос и самому принять решение "нужна или не нужна и в каких случаях"

В заключении темы (и для начинающих и для себя, любимых) кратко отмечу
Вопросы, так или иначе затронутые в процессе обсуждения:
1. Проблемно-ориентированные языки программирования ПЛК стандарта МЭК. Является ли это новым шагом в развитии технологии программирования (новым уровнем ее развития)?
2. Есть ли ограничения этой технологии применительно к задачам ПЛК? Или какова область применения?
3. Можно ли подобный (проблемно-ориентированный) подход применить к другой предметной области
(ЦОС, информационно-измерительные системы)?
4. Какими средствами кроме языков МЭК возможно решить эти задачи предметной области?
5. И собственно, заголовок темы "Когда не нужна ОС РВ" в задачах ПЛК или в задачах ЦОС, если там будут использоваться похожие case-технологии?

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

З.Ы.: для начинающих и не очень - дополняю ссылки на скриптовые языки (может повторюсь немного)
(это если пойти по пути разработки собственных case, путь который может и не даст ничего нового )
Lua - http://www.botik.ru/~rldp/mysql/mysqldev/glava04.htm (рус)
http://club.shelek.com/print.php?id=77 (рус)
http://www.lua.org/pil/ (англ)
CScript - http://wvsoft.com/cscript/index.html

[yuri_t]

Понимаю, что тема несколько остыла, но тем не менее...

При всем уважении к SM, ассемблер и No OS - путь тупиковый.

- Цены на hardware падают драматически - сегодня ARM стоит
столько, сколько вчера 8051, и эта тенденция обостряется.

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

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

Котлован копают экскаватором, а не лопатой.

[Виктория]

Понимаю, что тема несколько остыла, но тем не менее...

Не поостыла, а необходимо время для полного осмысления для ее дальнейшего развития

З.Ы.: к тому же и по работе завал (как всегда бывает перед летними отпусками - хвосты по основной + подготовка докладов на конференции, и студенты, как всегда не кстати.

З.Ы. ii : тема не закрыта, если по делу - пожалуйста, высказывайтесь.

[DogZ]

Понимаю, что тема несколько остыла, но тем не менее...

Не поостыла, а необходимо время для полного осмысления для ее дальнейшего развития

З.Ы.: к тому же и по работе завал (как всегда бывает перед летними отпусками - хвосты по основной + подготовка докладов на конференции, и студенты, как всегда не кстати.

З.Ы. ii : тема не закрыта, если по делу - пожалуйста, высказывайтесь.

Постановка вопроса более чем актуальна, с одной лишь оговоркой - точка зрения, с которой рассматривается проблема, не была определена. Мне кажется, именно в этом кроется причина, почему не покрыты вопросы, связанные с применимостью обозначенных технологий в других предметных областях. Другими словами, областями в которых ПЛМ не используются для управления технологическими процессами.
Сразу оговорюсь, не имел возможности прочитать все сообщения, но как мне показалось, проблема была рассмотрена изнутри. Очевидно, для определения трендов в технологиях необходимо посмотреть на проблему с верху (Системный уровень, а не уровень разработчика как в подавляющем количестве сообщений).
Несколько комментариев:
1. С точки зрения системного уровня не определено, в каком контексте используется ПЛМ
a) Integration entity
Design entity
В первом случае поддержка одного или нескольких МЭК языков является потребительским свойством продукта, дающим некоторую не зависимость от производителя ПЛМ интегратору и возможность сэкономить определенное количество ресурсов производителю. Все счастливы. Должно работать одно правило, все решения должны быть экономически обоснованы. Нужна RTOS или нет вопрос в данном случае неуместен.

Второй случай сложнее, принцип все тот же (все решения должны быть экономически обоснованы).
Именно в этом случае возникает вопрос какое HW использовать и использовать или не использовать RTOS, также как и решение вопроса о том стоит или нет имплементировать поддержку одного или боле МЭК языков по причинам описанным выше. (подробности, мне кажется out of scope и относятся системному проектированию и управлению проектами)

Как показал опыт и исследования, использования технологий промышленной автоматики, в общем случае, в областях не связанных с поддержкой технологических процессов не удовлетворяет критерию экономической целесообразности. Тренды в этой области надо искать в источниках посвященных R&D ( ACM, IEEE к сожалению платных)

[Виктория]

Постановка вопроса более чем актуальна, с одной лишь оговоркой - точка зрения, с которой рассматривается проблема, не была определена. Мне кажется, именно в этом кроется причина, почему не покрыты вопросы, связанные с применимостью обозначенных технологий в других предметных областях. Другими словами, областями в которых ПЛК не используются для управления технологическими процессами.

Согласна с критикой. Тема оказалась тяжеловесной из-за того, что фактически рассматривалисиь две разные проблемы
1) Проблемно-ориентированные языки программирования ПЛК стандарта МЭК - как этап развития, критика, есть ли альтернатива ...
и 2) Можно ли подобный (проблемно-ориентированный) подход применить к другой предметной области (ЦОС, информационно-измерительные системы)? Константирую - почти не раскрыли.

А вот это

Как показал опыт и исследования, использования технологий промышленной автоматики, в общем случае, в областях не связанных с поддержкой технологических процессов не удовлетворяет критерию экономической целесообразности. Тренды в этой области надо искать в источниках посвященных R&D ( ACM, IEEE к сожалению платных)

лучше все таки доказать (или первоисточниками, или их вольным пересказом). Раз уж с системных позиций решили посмотреть.

[Владимир Е. Зюби...]

Всем привет! Отдельное спасибо Виктории за то, что дала мне ссылку на эту ветку.
С интересом просмотрел ветку, увидел для себя много интересно, старых знакомых и несколько вопросов по Рефлексу, на которые посчитал уместным ответить.

1.

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

Дело тут не в косности мышления, а в проблемной ориентированности. Вы можете настроить Си или Си++ под решение задач управления, но: 1) появляется дополнительная сложность, связанная с реализованной стратегией управления (которая не связана с базовым языком напрямую), б) появляются семантические "дырки", т.е. появляются ситуации, которые сематически корректы с точки зрения Си++, но ошибочны в рамках выбранной концепции. Например, решено определять состояния процесса (автомата) через константы (как это делается в реализации автоматов на Си, тем же проф. Шалыто в т.н. switch-технологии), а вот контролировать корректность употребления этих констант нет никакой возможности. Для Си/Си++ - это просто константы, в) в МЭК языках активно используется искусственныя метафоризация: посмотрите, например, на язык релейно-контактных схем - LD, с исторической точки зрения психологические преимущества этого языка очевидны (использование метафоры "реле"), но ввести такую метафоризацию в Ruby... увы, невозможно.

2.

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

В некотором смысле это так. Рефлекс действительно и обладает свойствами алгоритмических языков (как и ST), и обеспечивает манипуляции с потоками управления (порождение, схлапывание, логический параллелизм), как SFC. Другое дело, логический параллелизм реализован в Рефлексе более изящно, чем в SFC. Например, в SFC конвергенция (схождение) параллельных потоков управления обеспечивается исключительно пользователем, сторонними средствами, флажками и т.д., а в Рефлексе это делается нативными средствами языка (есть операции проверки окончания выполнения потока управления (процесса)). Есть и еще некоторые плюсы, так что Рефлекс покрывает возможности SFC+ST.

3.

Для меня так и остается загадкой, почему PLC'шники не использовали богатый мир скриптовых языков "в своих целях". Одна мысль есть - тот же Python "повзрослел" как раз в 98-99 годах, когда МЭК исполнилось 5 лет... LUA, RUBY еще более молодые языки.

Основная проблема не в скриптовости, а в особой специфике класса задач автоматизации:
1) гомеостатика, открытость, наличие внешнего объекта (т.н. объекта управления);
2) цикличность исполнения алгоритма (управляющее воздействие-реакция объекта, и т.д. по циклу);
3) событийность, постоянные изменения алгоритма, т.н. событийный полиморфизм;
4) синхронизм, активная работа с временными сущностями (таймаутами, задержками, паузами);
5) логический параллелизм исполнения, отражающий независимость и параллелизм процессов на технологическом объекте, активная работа с потоками управления, конвергенция, дивергенция и т.д.

К сожалению, ООП для этого класса задач просто не подходит.

Кстати, тому же LD из МЭК 61131-3 лет шестьдесят... он старее, чем Си и Питоны вместе взятые. Первые работы по нему - 40-е годы прошлого века. МЭК - это попытка стандартизации, причем, многие говорят, что при этом еще присутствовало и желание законсервировать текущее положение, т.е. конкурентная борьба - главная причина появления МЭК 61131-3. Возможно, что Сименс, АББ и т.д. (см. список авторов МЭК) как раз ООП-"революции" испугались...

4.

На (=AK= @ Mar 6 2006, 14:42) "Зюбин - единственный, кто утверждает, что IL произошел от STEP5."

Ясно, спасибо за информацию.
На сайте Фиорда в презенташке нашел: "IL - Подобен SIEMENS (Step 5)"
т.е. наверное Step 5 подобен IL

Ремарка: =АК= не совсем прав, утверждая, что родство IL с STEP5 от Сименс это исключительно мои фантазии.
Разумеется, это не я придумал, а так заявляют многие наши зарубежные коллеги, например, глава "Steinhoff Automation" Armin Steinhoff. Это же утверждают и наши специалисты, и это видно по приведенной ссылке с сайта Фиорда. Хотя, возможно, мы все ошибаемся, указывая причины появления IL в стандарте МЭК61131-3.

5.

Известный всем стандарт IEC61131-3 для PLC уже заменяется новым стандартом IEC61499 который сам определяет событийно управляемую модель поведения ...

Это не совсем так. МЭК61499 - это скорее событийная надстройка над МЭК61131-3. В настоящее время по крайней мере. Внутренности блоков программируются на МЭК61131-3. Сайт - http://www.holobloc.com/ кстати, автор - небезызвестный Кристенсен, бывший глава МЭК 61131-3.

6.

Зюбин только протяжно бредит, упиваясь собственным невежеством.

Ремарка: 1) Нельзя ли конкретизировать Ваше утверждение? Какие из моих утверждений, Вам кажутся бредовыми? 2) Нельзя ли представиться? Мне кажется, что Ваша анонимность мешает Вам вести конструктивный диалог... Например, об "общеизвестной простоте освоения LD и FBD", что, если быть кратким, - просто фикция.

[Evgeny_CD]

...Основная проблема не в скриптовости, а в особой специфике класса задач автоматизации:
1) гомеостатика, открытость, наличие внешнего объекта (т.н. объекта управления);
2) цикличность исполнения алгоритма (управляющее воздействие-реакция объекта, и т.д. по циклу);
3) событийность, постоянные изменения алгоритма, т.н. событийный полиморфизм;
4) синхронизм, активная работа с временными сущностями (таймаутами, задержками, паузами);
5) логический параллелизм исполнения, отражающий независимость и параллелизм процессов на технологическом объекте, активная работа с потоками управления, конвергенция, дивергенция и т.д.

К сожалению, ООП для этого класса задач просто не подходит...

У меня нет опыта работы с PLC, но из всего Вами описанного не следует неприменимость ООП в том или ином виде для решения задач PLC.

Я согласен, что в "чистом" виде С/С++/Python могут быть неудобны для технолога. Но никто не мешает сделать метаязык, который будет оперировать "правильным" объктами, и сделать несложный транслятор с этого языка в нечто ООП. И метаязык, и транслятор надо стандартизовать, и тогда это PLC приложение пойдет на чем угодно - как, как Вы заметили, этого вся и боятся.

Кстати, тому же LD из МЭК 61131-3 лет шестьдесят... он старее, чем Си и Питоны вместе взятые. Первые работы по нему - 40-е годы прошлого века. МЭК - это попытка стандартизации, причем, многие говорят, что при этом еще присутствовало и желание законсервировать текущее положение, т.е. конкурентная борьба - главная причина появления МЭК 61131-3. Возможно, что Сименс, АББ и т.д. (см. список авторов МЭК) как раз ООП-"революции" испугались...

Вот где собака зарыта во всей это МЭК философии!!!

Конечно, вместо внедрения нормальных технологий программирования проще построить искуственный мир, основанный на каких-то дурацких правилах, а всем конкурентам, приходящим со стороны, говорить "Со своим уставом в чужой монастырь не ходят". Ну а поскольку конкуренты умаются переводить всего это громадье на нормальные технологии, то задача решена - можно продавать за 5k$ простенький 386EX контроллер с убогой софтиной, зато типа "супернадежный и проверенный", и, главное, с логотипом Siemens.

Нда, надо будет как-нибудь революцию во всем этом PLC мире устроить. А то они там "прижукались" и думаю, что все можно...

[Olej]

Я согласен, что в "чистом" виде С/С++/Python могут быть неудобны для технолога. Но никто не мешает сделать метаязык, который будет оперировать "правильным" объктами, и сделать несложный транслятор с этого языка в нечто ООП. И метаязык, и транслятор надо стандартизовать, и тогда это PLC приложение пойдет на чем угодно - как, как Вы заметили, этого вся и боятся.

А на самом деле это и происходит:
1. если в начальный период бранды предоставляли средства разработки МЭК только по принципу: "вот вам tools, ... который работает только на моём железе, внутри которого что - я вообще не скажу"...
2. то дальше появились tools, которые работают на любой открытой процессорной архитектуре (универсальной), самые известные из которых - упоминавшиеся здесь ISaGRAF & CoDeSys...
3. но - большинство МЭК tools именно и работают как трансляторы исходного МЭК-изображения программы ("исходным кодом" назвать это у меня рука не подымается ) в некий промежуточный код, интерпретируемый runtime системой (некоторое исключение здесь составляет CoDeSys, который компилирует под целевой процессор, но это тоже относительно ... CoDeSys так же нуждается в runtime поддержке, хотя бы в "локализации" внешних переменных-объектов: как вы понимаете компиляция/интерпретация - это не чёрное/белое, а непрерывная шкала, и конкретная реализация всегда "где-то между")...
4. ... представьте, гипотетически, что вот тем промежуточным кодом был бы выбран java байт код (стадартизированный), который интерпретировался бы JVM (множественными), тогда языком промежуточного уровня мог бы быть java ...
5. но кому это нужно! - ведь здесь важднейшее же условие - игрища!
6. кстати, вот некоторым направлением движения, разрывающим эту порочную практику и являются открытые архитектуры PLC, или PC based PLC, или soft PLC, их достаточно много за последние 3-4 года, см. например:
http://www.automationx.com/produkte/eprodukte.php?area=3
- не сколько сам комплекс оборудования, как то, как он обвязан сопутствующим tools.

P.S. кстати, "философия", сложившаяся за 15-20 лет в этом сегменте, она "обратным концом палки" уже ударила по тем же брэндам: тот же Сименс несколько последних лет теряет ежегодно объёмы в сегменте PLC, и внутри корпорации это порождает состояние близкое к панике, которое только не выносится внаружу ... из-за чего они последние годы хватаются за любой "комплексный проект" вместо системных интеграторов, лишь бы чем подпереть объёмы...

P.P.S. многое из сказанного выше - это не мои суждения (а то тут крик начнётся: бредни, бредни...) а позиции из вчерашнего обстоятельного обсуждения с президентом вот того же AutomationX, на который я выше ссылался.

Вот где собака зарыта во всей это МЭК философии!!!

Вот где собака и зарыта ... при чём тело начало уже сильно смердеть

Ну а поскольку конкуренты умаются переводить всего это громадье на нормальные технологии, то задача решена - можно продавать за 5k$ простенький 386EX контроллер с убогой софтиной, зато типа "супернадежный и проверенный", и, главное, с логотипом Siemens.

Ну, вы здесь чуть-чуть не угадали: от самых разных производителей это стоит не $5K а порядка $4K-$4.5K (при чём в узких рамках от множества производителей ... так получилось ).

P.P.P.S. Лирическое отступление, но в ту же тему...
В том же обсуждении, о котором я упоминал выше, директор (генеральный ) успешной АСУТП компании (интеграторов) сказал дословно следующее:
"Хорошего железнодорожника (имелся в виду ж/д специалист по СЦБ - автоматике систем безопасности) можно выучить компьютерным технологиям, но из компьютерщика нельзя сделать железнодорожника".
Я его на этом поправил, что точнее было бы сказать так:
"Хорошему железнодорожнику может показаться, что его выучили компьютерным технологиям, ..." ну а далее по тексту.
Это очень имеет касательство к обсуждаемой МЭК-автоматизации!
Кое что по "близким вопросам" можно глянуть здесь:
http://qnxclub.net/modules.php?name=Forums...viewtopic&t=294