To Andrew2000

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


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


To Olej


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



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

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

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

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

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

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


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


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

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


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

To Vic1

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

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

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

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


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


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


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

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

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

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

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

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

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

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

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

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

To Evgeny_CD

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

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

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


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

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

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

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

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

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

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

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









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

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

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

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

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

Посмотрит CoDeSys:
http://www.prolog-plc.ru/3s/CoDeSys/PT_Task.htm


Я не раз спрашивал ... и интеграторов ISaGRAF и CoDeSys ...
Они мне отвечают, но сильно нечленораздельно, что-то типа: ... если CoDeSys выполняется под управлением RTOS, то в системе может выполняться несколько задач...

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


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


Вот только когда-то ... один раз сложится ... ... вспоминается тот давний анекдот: "... чёрт с ней, с этой Австралией - но дисциплина то хоть какая должна быть?!"(с).
То что это "почти невероятно" ("попасть" 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? ...) - то этого и не может случиться: "мы вам предлагаем уникальные технологии"!

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

Паранойя

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

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

Судя по флейму в СТА, он не знал элементарных вещей, начиная с того, что ST является структурированным языком программирования.
Дык, кто мешает? Неужто стандарт МЭК как таковой? "Несоблюдение стандарта преследуется по закону" (с), что ли?

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

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

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

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

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

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

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

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



В своё время много внимания уделялось простоте для кухарки управлять государством ... теперь вот - простоте освоения языков LD и FBD...



А они там ... "в англоязычных странах" - вообще "ребята простые", не только электрики...



По поводу "глубокого диалектического развития Модулы в ST" ... это уже не первый раз повторяется - а поэтому заслуживает ответа:
- я, в отличие от многих программистов, несколько лет "сидел" в Modula-2 (не потому "в отличие", что я, а потому, что в практике Modula далеко не часто используемый инструмент""), и сдавал несколько проектов, некоторые из которых, наверное, и п сей день эксплуатируются... , кроме того достаточно обстоятельно изучал и "до" и "после": Modula, Oberon, Zenon... (это к вопросу "только не надо мне впаривать" )...
- вся линейка этих языков построена на философии взаимодействующих ветвей...
- безусловно, разработчик ST глядел в открытую книгу "Модула" ... но единственное, что он оттуда извлёк, и что роднит ST с Modula - это то, что зарезервированные ключеве слова Pascal-евские (IF, THEN, ELSE ...) - и там и там пишутся заглавными буквами ;
- ... с таким же успехом можно "сравнить %&@ с пальцем" - на том основании, что они ... формой похожи :D;



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

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

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

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

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



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



Вах-вах-вах... вот 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 исправляли старые, и дополняли механизмами, закрывавшими слабые места...

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



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

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


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


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


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


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


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



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

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

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

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

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

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

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

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

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



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

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


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



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



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



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


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

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

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

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



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

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




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

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

To Olej



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

З.Ы.:
to =AK=


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

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

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

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

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

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

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

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

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

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

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

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

В заключении темы (и для начинающих и для себя, любимых) кратко отмечу
Вопросы, так или иначе затронутые в процессе обсуждения:
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

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

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

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

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

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

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

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

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

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

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

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

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

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

А вот это

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

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

1.

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

2.

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

3.

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

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

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

4.

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

5.

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

6.

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

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

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

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

Нда, надо будет как-нибудь революцию во всем этом 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 а порядка $4K-$4.5K (при чём в узких рамках от множества производителей ... так получилось ).

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