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 имел смысл. А Вы с Зюбиным как глухари на току, право слово: "ах, защита мега-корпораций", "ах, рекламная кампания", "фи, убогие языки", "где привычные нам фигурные скобки", "где сообщения, семафоры и мютексы".
Впрочем, справедливости ради: у в Вас можно увидеть и здравые суждения, тогда как Зюбин только протяжно бредит, упиваясь собственным невежеством.

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

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