Многозадачность и языки МЭК

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

ИМХО ставить на кон при проектировании:

На одну чашу весов разработанный группой разработчиков коммерческий продукт обеспечивающий на мой взгляд хорошую среду исполнения прикладных задач (CoDeSys+PLC МЭК) и дать “ограниченные возможностями” средства разработки этого самого прикладного уровня. Скажем полет мысли ограничивает но и круг областей для фатальных ошибок то же извините сужается.

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

ИМХО предлагаемая модель стандартизации не может не вызывать недовольства у кодоваятелей, но она в конечном итоге необходима для крупных объектов, на которых работают множество систем выполняющих разные задачи но нуждающиеся в тесной интеграции, установка единой системы чаще всего натыкается на чисто экономические проблемы, да и на специализацию разработчиков.

Спорить здесь возможно до хрипоты, потому как рассматривается два достаточно разных подхода.

Есть один проект на МЭК нижний уровень обеспечивают два контроллера WAGO-750-841, верхний уровень TraceMode 5.xx. С верхним уровнем пришлось помучиться, к контроллерам никаких нет претензий, четвертый год все крутиться без проблем, наращивать без проблем, контролировать без проблем. За это время Target для WAGO 750-841 прошел от совершенно убогова варианта, с недоделанным конфигуратором, до вполне пристойного. В течении суток, по первому требованию, мне была предложена новая прошивка непосредственно из Германии (03 на 09) решены проблемы с web сервером и DDE обменом, и замечу без моего горячего участия. Ощущается забота не о моем конкретно проекте, а о продукте в целом. То есть некая положительная динамика направленная на совершенствование.

Первоначально опубликовано Dismay <P class=Msonormal style="MARGIN: 0cm 0cm 0pt"><FONT face="Times New Roman" size=3>Собственно, я было уже решил не вмешиваться в дальнейшую дискуссию, ибо, на мой взгляд она приобрела несколько религиозный подтекст. Но собственно мне есть, что добавить к словам Максима, не один (ну пара, не буду показывать пальцем) проект просто умер у меня на руках, тащил как мог три года (эксплуатацию), просто пытка. <P class=Msonormal style="MARGIN: 0cm 0cm 0pt"><FONT face="Times New Roman" size=3>ИМХО ставить на кон при проектировании: <P class=Msonormal style="MARGIN: 0cm 0cm 0pt"><FONT face="Times New Roman" size=3>На одну чашу весов разработанный группой разработчиков коммерческий продукт обеспечивающий на мой взгляд хорошую среду исполнения прикладных задач (<SPAN lang=EN-US style="mso-ansi-language: EN-US">CoDeSys</span>+<SPAN lang=EN-US style="mso-ansi-language: EN-US">PLC</span><SPAN lang=EN-US> </span>МЭК) и дать “ограниченные возможностями” средства разработки этого самого прикладного уровня. Скажем полет мысли ограничивает но и круг областей для фатальных ошибок то же извините сужается. <P class=Msonormal style="MARGIN: 0cm 0cm 0pt"><FONT face="Times New Roman" size=3>На другую чашу <SPAN lang=EN-US style="mso-ansi-language: EN-US">QNX</span><SPAN lang=EN-US> </span>и группу интузиазистов разработчиков из какой нить победившей остальных организации, <SPAN lang=EN-US style="mso-ansi-language: EN-US">microPC</span><SPAN lang=EN-US> </span>от одного производителя карты от другого, расширения ядра от Петровича. Неизменно процесс отладки превращается в бесконечную переписку с группой разработчиков, автоматизируемый объект в полигон для испытаний, сопряжение систем в ад, модернизация обычно выглядит как полная замена.

Собственно ... я не говорил и ни о 1-м и ни о 2-м варианте в вашей классификации . Вы, работая в стабильной фирме, ведь не строите СУ для всё новых отраслей каждую неделю: сегодня управление транспортом, завтра - трубопроводами, послезавтра - гидросооружениями ... а между делом ещё и разнообразные конвейерные производства ... "не верю"(с) Станиславский. Вы годами работаете в одной области.
1. когда вы берёте "хорошую среду исполнения прикладных задач (CoDeSys+PLC МЭК)" (среда хорошая, без сомнения), а ещё более - SCADA "верхний уровень TraceMode 5.xx." ... которые рождались и обкатывались в другой области применения, а потом "натягивались" на как можно более широкий спектр приложений - то вы с этими tools берёте (тянете) ~90% того, что избыточно для вашей сферы приложения...
2. я если и говорил выше о проектировании (QNX, C/C++, ...) то совсем не в том смысле, который вы вкладываете: просто на этих инструментах вы умеренными трудозатратами можете в короткий сок наработать набор своих tools, которые будут на 100% соответствовать специфике вашего класса задач (при этом заимствуя туда всё лучшее архитектурно,что можно заимствовать из коммерческих систем, например RealFlex или AutomationX, или лучших и выверенных технологий, таких как SWITCH - автоматное программирование с явно выделенными состояниями)... В результате вы получаете нечто - хотите называйте это mini-SCADA, заточенное под вашу область, ваши объекты и т.д.
3. я знаю не менее 10 успешных команд по ×USSR, которые прошли именно этим путём - часть из них "озвучивались" и здесь на форуме в разные времена.

Плюс, к "достоинству" универсально-технологических средств нужно отнести и то, что ... а если этот tools уже после сдачи в эксплуатацию - выкажет дефекты внутреннего свойства? что тогда будете делать?
Особенно, если это система из области критических требований: 24 х 365 в необслуживаемом режиме...
P.S. чтоб не быть голословным, пример прошлого года:
- на 2-х новых станциях киевского метрополитена (я хоть знаю каких - и туда не влезу, при случае ;)) СУ напольным оборудованием (а это стрелки, светофоры, ...) - оказалась мёртвой, и была такой почти сутки - выключить/перезагрузить до прекращения движения нельзя (т.е. PLC - работают, а уровень управления SCADA MonitorPro - отшибло - ни рук ни ног...);
- причина? - полное исчерпание RAM в результате системной утечки памяти - спасибо Microsoft Windows + Telematique резработчику MonitorPro (как вы понимаете, при визуальном складывании кубиков проектант не манипулирует памятью)...
- и что теперь? учитывая, что и исполнитель и заказчик понимают - такая ситуация будет воспроизводиться через 20-30 суток непрерывной работы в непредсказуемый момент каждый раз... - теперь они только прикрыли голову руками, и "скооперированно" молчат, чтоб никто не прослышал: что одни сделали - а другие приняли.
Занятная история?

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

C++ превосходен, поскольку не ограничен. Если прикладной проект пишется программистом, который его и будет сопровождать, то никакой МЭК даром не нужен. До 2001 года мы так и делали. У нас нет одной раскрученной области на которой мы сидим, это не основной бизнес. Последние проекты: литьевая машина, пресс макулатуры, несколько типографских машин, геофизическая установка, 2х шпиндельный токарный станок. Все они не очень сложны с позиции программирования. Давно нет желания жениться на каждой работе, нужно просто сделать ее и сдать, научив имеющихся у заказчика людей справляться самостоятельно с текущим сопровождением. С CoDeSys это вполне получается, поэтому суем его даже во встраиваемые системы. Дело даже не столько в самих языках, сколько в специализированных инструментах отладки, протоколирования и др., позволяющих чинить оборудование без написания программ.

Связка АСУТП и языки МЭК это опять же частность. ИМХО Изаграф изначально ориентирован на АСУТП. CoDeSys заточен под машиностроение. Здесь выше требования к программе в контроллере, но не столь важна простата адаптации и обучения. Основные применения –  это разнообразные станки и приборы, где потребитель (не конечный) должен иметь возможность менять алгоритм. Например, Бош ставит CoDeSys в блоки управления впрыском. Они применяются в машинах БМВ, Мерседес и др. Очевидно Бош  считает себя специалистами по блокам управления, а не по настройке двигателей иначе делал бы все прикладное ПО сам для каждого мотора. Аналогичные примеры есть с судовой автоматикой и на жд.

К сожалению, многозадачность в МЭК системах сильно зависит от того, как сделана система исполнения. Так в CoDeSys есть вариант, когда система исполнения (CSP32F) ставится поверх QNX или RT Linux. При этом средства синхронизации задач используются от самой ОС, в МЭК программах для них просто сделан интерфейс в форме библиотеки. Совершенно нет смысла обсуждать правильно ли это. Есть спрос.

Реально больше всего надо для след. целей: есть ряд дополнительных модных штук в комплексе CoDeSys, например встроенная визуализация, web-визуализация, SoftMotion и др. которые написаны прямо в CoDeSys на языке ST и активно нуждаются в нормальной многозадачности. Иначе прикладные программы работают нестабильно. С РТ ОС внизу, все получается легко и работает отлично. Все эти доп. компоненты сделаны разработчиками 3S и контроллеров. Прикладные программисты могут и не знать, что в ПЛК есть ОС.

Однако инструментарий открыт. Грамотно используют его единицы. Но многие имеют нерусскую привычку читать мануал, особенно очень начинающие. Потом применяют все и сразу. Запретить уже нельзя, надо учить использовать. Хотя бы пояснить опасные моменты. Спасибо за ответы и ссылки. Много чего по делу уже подсказали.

Первоначально опубликовано Dismay <P class=Msonormal style="MARGIN: 0cm 0cm 0pt"><FONT face="Times New Roman" size=3> я пришел к выводу, что никакая группа велосипедистов, в лице группы специалистов широкого профиля с узким захватом, не в состоянии за отведенный проектом срок переплюнуть по конечному качеству исполнения надежность узлов многоцелевых платформ разработки.

Что же вы так уничижительно гнобите все ... "группы велосипедистов, в лице группы специалистов широкого профиля с узким захватом" ... а чем отличаются они от специалистов узкого профиля с широким захватом? ;) я знаком с некоторыми из "велосипедистов" из разработчиков RealFlex (кстати - большинство команды RealFlex на сегодня - это российские разработчики)... вот это "велосипедисты" (делая под свои целевые области приложения!) сваяли RealFlex ... с которым уж ни в какое просто сравнение не может идти даже любый вашему сердцу    TraceMode (IMHO !;) ) - из этих, как их бишь ... "многоцелевых платформ разработки" ;).

Гмм. Если это вопрос то непонятно в чем он? Если это мысли вслух то наверное стоилдо помещать их в разделе посвященном этой теме, поднятым _IP_. Хотя впринципе я с автором согласен. В Codesys как нигде просто постичь принципы многозадачности. И сдается мне не так страшен черт как его малюют.
p.s. лично от меня: так хочется увидеть форум только по Codesys...