[Evgeny_CD 0]

Бука по промавтоматике - может кому пригодится в свете затронутых тут МЭК языков

http://electronix.ru/forum/index.php?showtopic=13906

[=AK= 12]

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

[Виктория 0]

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

 

В заключении темы (и для начинающих и для себя, любимых) кратко отмечу

Вопросы, так или иначе затронутые в процессе обсуждения:

1. Проблемно-ориентированные языки программирования ПЛК стандарта МЭК. Является ли это новым шагом в развитии технологии программирования (новым уровнем ее развития)?

2. Есть ли ограничения этой технологии применительно к задачам ПЛК? Или какова область применения?

3. Можно ли подобный (проблемно-ориентированный) подход применить к другой предметной области

(ЦОС, информационно-измерительные системы)?

4. Какими средствами кроме языков МЭК возможно решить эти задачи предметной области?

5. И собственно, заголовок темы "Когда не нужна ОС РВ" в задачах ПЛК или в задачах ЦОС, если там будут использоваться похожие case-технологии?

 

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

 

З.Ы.: для начинающих и не очень - дополняю ссылки на скриптовые языки (может повторюсь немного)

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

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

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

 

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

 

- Цены на hardware падают драматически - сегодня ARM стоит

столько, сколько вчера 8051, и эта тенденция обостряется.

 

- Проекты становятся большими. Когда работают несколько

человек, только OS (любая из надежных) и ЯВУ(тоже любой)

делают проект управляемым и отлаживаемым (замечу, что проекты SM с

этой точки зрения - небольшие. В больших проектах даже выдающиеся

инженеры просто физически неспособны выполнить проект в одиночку).

 

- Жизненный цикл проекта - люди приходят и уходят, а проекты

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

новыми людьми.

 

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

[Виктория 0]

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

 

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

 

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

 

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

[MikhailZ 0]

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

 

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

 

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

 

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

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

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

Несколько комментариев:

1. С точки зрения системного уровня не определено, в каком контексте используется ПЛМ

a) Integration entity

B) Design entity

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

 

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

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

 

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

[Виктория 0]

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

 

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

1) Проблемно-ориентированные языки программирования ПЛК стандарта МЭК - как этап развития, критика, есть ли альтернатива ...

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

 

А вот это

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

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

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

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

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

 

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

...Основная проблема не в скриптовости, а в особой специфике класса задач автоматизации:

1) гомеостатика, открытость, наличие внешнего объекта (т.н. объекта управления);

2) цикличность исполнения алгоритма (управляющее воздействие-реакция объекта, и т.д. по циклу);

3) событийность, постоянные изменения алгоритма, т.н. событийный полиморфизм;

4) синхронизм, активная работа с временными сущностями (таймаутами, задержками, паузами);

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

 

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

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

 

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

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

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

 

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

 

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

[Olej 0]

Я согласен, что в "чистом" виде С/С++/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

[Olej 0]

Вспомнилось - решил добавить:

 

Конечно, вместо внедрения нормальных технологий программирования проще построить искуственный мир, основанный на каких-то дурацких правилах, а всем конкурентам, приходящим со стороны, говорить "Со своим уставом в чужой монастырь не ходят".

 

- так оно того стоит! (как поётся в одной старой песне: "... за это можно всё отдать"(с)):

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

[Kopa 0]

Вспомнилось - решил добавить:

 

Конечно, вместо внедрения нормальных технологий программирования проще построить искуственный мир, основанный на каких-то дурацких правилах, а всем конкурентам, приходящим со стороны, говорить "Со своим уставом в чужой монастырь не ходят".

 

- так оно того стоит! (как поётся в одной старой песне: "... за это можно всё отдать"(с)):

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

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

Net и Forth, а многие используют nncron скриптовый планировщик.

http://szgroup.narod.ru/NetForth/

 

Переизобретать велосипед не всегда имеет смысл.

[=AK= 12]

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

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

Конечно не следует. ООП в PLC почти не применяется по совсем иным причинам.

 

сделать несложный транслятор с этого языка в нечто ООП. И метаязык, и транслятор надо стандартизовать, и тогда это PLC

Нет, от стандартизации мало что зависит. Устройство можно назвать PLC только если оно работает надежно. ООП в смысле надежности имеет не только плюсы (программу писать/отлаживать быстрее), но и минусы (требует больше памяти и производительности проца, а "вкусности" ООП вроде сборки мусора вообще загоняют надежность и предсказуемость поведения в болото). Минусов больше, поэтому в PLC обычно не применяется.

 

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

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

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

 

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

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

 

Какие из моих утверждений, Вам кажутся бредовыми?

Долго перечислять, много их. Про "тайные мотивы" МЭК и PLCopen пишите бред, про МЭК языки - бред, про ООП в PLC - бред (см. выше), про языки программирования "вообще" - тоже бред, часто противоречивый (то можно С/С++/Паскаль и пр. применять для автоматизации, то нельзя), и т.п.

 

Вы, например, про то, что IL произошел от STEP5, пишите начиная с 1997 года, но ни разу не назвали источник этой информации. Вот и сейчас не назвали, вместо этого зубы заговариваете, перескакивая на похожесть. Вам что, Armin Steinhoff сказал году так в 96-м при личной встрече, что МЭК взял IL из STEP5, проигнорировав соответствующие языки других производителей? А он откуда это знает, он же специалист по QNX, а не по истории создания МЭК языков? Давайте, признавайтесь, где эту сплетню подхватили, и почему она заслуживает доверия.

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

Можно ли удалять свои сообщения? Лишнее после правки появилось.

Изменено 6 мая, 2006 пользователем Владимир Е. Зюбин

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

...Основная проблема не в скриптовости, а в особой специфике класса задач автоматизации:

1) гомеостатика, открытость, наличие внешнего объекта (т.н. объекта управления);

2) цикличность исполнения алгоритма (управляющее воздействие-реакция объекта, и т.д. по циклу);

3) событийность, постоянные изменения алгоритма, т.н. событийный полиморфизм;

4) синхронизм, активная работа с временными сущностями (таймаутами, задержками, паузами);

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

 

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

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

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

 

Согласен. Рефлекс, кстати, и есть такой специализированный язык. По синтаксису похожий на Си.

Более того, текущий транслятор языка на выходе генерирует файла ня языке Си.

Написан транслятор на Си. А может быть написан и на Си++ или другом языке, да и генерировать выходные файлы он тоже мог бы на любом другом языке, хоть на Питоне. Даже интерпретатором мог бы быть. Это дело вкуса того, кто захочет реализовать язык Рефлекс.

 

Могу пояснить, почему был выбран Си: это первый платформонезависимый язык, который появляется на микроконтроллерах. Практически на всех, даже на "хилых", типа 51-го.

 

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

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

 

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

 

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

 

На мой взгляд, МЭК61131-3 - это типичный пример использования процесса стандартизации в конкурентной борьбе. Случай не единичный. Основные признаки такого трюка - несколько продуктов объединяются в одном стандарте (в нашем случае - пять языков), ну и члены комитета - сплошь представители мегакорпораций (в нашем случае - Сименс, АББ, Аллен-Бредли и т.д.) Со стандартом Профибас та же история... наши зарубежные коллеги его даже переименовали из Profibus в ProfiTbus.

;-)

 

Но, справедливости ради, нужно отметить, что сами по себе языки МЭК могут быть приемлемы и удобны. Хоть на них сложного алгоритма и не реализовать, но, недавно слышал, программы 80% ПЛК

содержат не более двадцати операторов. Такая вот специфика, в которой револючию придется делать.

Изменено 6 мая, 2006 пользователем Владимир Е. Зюбин