[=AK= 12]

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

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

 

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

 

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

 

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

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

[Evgeny_CD 0]

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

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

[Andrew2000 0]

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

Ясно, спасибо за информацию.

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

т.е. наверное Step 5 подобен IL :)

[Olej 0]

Я бы выделил следующие существенные моменты:

-- ПЛК изначально создавался как средство замены релейных шкафов автоматики. Первые языки программирования ПЛК "имитировали" релейные схемы. 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 3]

Я согласен с 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.

[Виктория 0]

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 с этой точки зрения лучше все-таки на базе ОС).

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

Вопросы все-равно какие-то остаются, выводы не закончены, мысли вертятся, со скриптовыми языками разбираюсь...

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

[=AK= 12]

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

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

[Виктория 0]

AlexandrY, а какими-нибудь ссылками на русскоязычное описание

iCon-L и I-Logix не можете поделиться?

 

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

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

[Andrew2000 0]

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

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

 

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

Или я чего-то не понимаю, или одно из двух...

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

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

 

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

Вроде, не заменяется, а дополняется. Кстати, ни у кого нет стандарта?

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

[Andrew2000 0]

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

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

 

 

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

[AlexandrY 3]

To Vic1

 

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

[Evgeny_CD 0]

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

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

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

[Olej 0]

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

 

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

[=AK= 12]

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

Не вижу оснований для введения новой "эпохи".

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

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

 

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

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

 

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

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

 

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

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

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

Изменено 8 марта, 2006 пользователем =AK=

[one_man_show 0]

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

 

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

 

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

 

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

 

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

 

Обобщаю:

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

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

 

Пытаюсь ответить на вопрос "Когда не нужна ОС РВ?":

- когда не знаешь, что это такое (долго изучать "новые рельсы", ...)

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

- когда знаешь, но не можешь её использовать (не хватает ресурсов, ...)

 

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

После чего ветка просто плавно перейдет в раздел "Общение".

 

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