[Olej 0]

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

 

Его и не нужно обсуждать - это как только 1 из примеров...

Насколько продуктивнее могло бы быть использование связей "вверх", если их не "вжимать" в подмножество косных протоколов PLC.

 

Ссылка (просили?), посмотрите здесь:

http://qnxclub.net/modules.php?name=Forums...e=viewforum&f=6

http://qnxclub.net/modules.php?name=Forums...=viewforum&f=10

http://qnx.org.ru/viewtopic5.html

 

Рассказать? не место здесь, как я уже сказал, но в 2 слова:

 

1. протокол не столько закрытый, как вы заметили, (не стоит труда его посмотреть tcpdump и всё рассмотреть), сколько проприетарный, т.е. он имеет смысл применительно только к QNX и вот почему...

 

2. QNET - протокол доставки вот тех сообщений (и возвратов) микроядра, а поскольку в микроядерной ОС любой (почти ;)) вызов ОС API - это пересылка сообщения через микроядро, то QNET просто распространяет "пространство определния микроядра" на всю сеть, доступную по QNET, т.е. превращает сеть в кластер процессоров, прозрачно взаимодействующих...

 

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

Т.е. интересует - что использует QNET для разрешения коллизий в сети; Profibus - логическое кольцо, CAN - случайный доступ с разрешением.

Поэтому Profibus и CAN называют промышленными, а Ethernet с TCP/IP - нет (про Ethernet можно вспомнить EtherCAT).

 

3. а поскольку он "транспорт", вы его можете заставить работать над любой средой, которая обеспечит вам доставку MAC: Ethernet (непосредственно на MAC уровне), IP, RS-232/485 с PPP над ними, есть отдельный сетевой драйвер devn-fd.so - позволяющий непосредственно QNET трафик через любой природы последовательные каналы...

 

Ну, Siemens тут Profinet (открытый) у B&R свой протокол (забыл как называется), кто-то использует TCP или UDP, многие ModbusTCP...

А чем тут Qnet лучше? (ну, этот вопрос я уже выше задал).

 

TCP/UDP - это уже надстройка достаточно высокого уровня, да и для "прозрачного" взаимодействия потребуется ещё и над ним надстройка, что-то типа RPC и т.д.

Modbus over TCP - ... это уродство ещё то, я уже говорил - хотя бы в силу его master/slave, если даже все прочие "вкусности" ;) сбросить со счёта...

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

Вы слишком зациклены на надежности....

В общем, не надо про надежность. Особенно в таком смехотворном стиле: "Главное - надежность, это окупает все". Для меня это прямое указание на то, что ни одно реальное ТЗ Вы в глаза не видели.

Также это указывает на то, что Вы не разу технико-экономическое обоснование не составляли, а в ВУЗе, если и был у Вас предмет по экономике, то преподавался он из рук вон плохо.

Ну, теперь прояснилось :) Встретились =АК= - человек, у которого всегда на готове банка вазилина, припасенная для встречи с заказчиком, по-поводу сбоя контроллера (и чего-то) на реальном объекте,

и Зюбин - умеющий писать ТЗ, статьи, а главное - технико-экономическое обоснование, и ни разу не видевшего реальный конвеер, останов которого на 1 час окупит не один ПЛК ценой в несколько $k.

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

 

Вы ошибаетесь, насчет моего бэкграунда.

 

не нагнетайте панику на пустом месте. Про взрывы НПЗ и АЭС. И про сверхнадежные ПЛК.

Лучше полистайте последние номера журналов. Весь мир движется в сторону ПЛК на основе Wintel.

Это гораздо на порядок дешевле и не уступает в надежности закрытым решениям от Сименс.

гораздо на порядок дешевле - "стоит-то оно стоит, так никто-ж его не покупает" (с) к/ф Формула Любви

мир движется в сторону ПЛК на основе Wintel - а куда еще? это проще для производителя ПЛК класса "радиолюбитель" и они отберуть рынок неответственных применений у Siemens и т.д.

А в ПЛК главное предсказуемость и еще раз предсказуемость, чего в Win нет.

 

Непонятно, почему серийно изготавливаемые решения Вы называете "ПЛК класса радиолюбитель"...

а в общем-то и без разницы.

 

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

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

Есть предложение - может Владимир Зюбин создаст на форуме отдельную ветку для обсуждения Рефлекса? У меня есть желание задать вопросы по языку.

 

Пожалуйста:

http://electronix.ru/forum/index.php?showtopic=15909 (Cистемный уровень проектирования > Вопросы системного уровня проектирования)

[Olej 0]

PC/104 + Windows XP Embedded ?

Ну, тогда это то же самое, что и

http://www.nnz-ipc.ru/html.news/lincon.html

 

Пардон, но расскажите, пожалуйста, что конкретно Вас здесь привлекло - я ничего интересного не обнаружил :(

 

А то тоже получается, что старье "700MHz PIII CPU" пытаются впарить за $k :)

 

Ну, во-первых, не Windows XP Embedded ... а альтернативно на выбор:

- Windows XP Embedded

- Linux

- QNX (на сайте информации этой нет, устарела - но он также равнозначно как другие альтернативы, это можете мне пока на слово поверить).

 

А во-вторых, что должно быть "интересного"?

Как сравнивать будем?

МОжно как в теории множеств: есть множества "свойств" любого брандового PLC и AX ... если каждому свойству из 1-го множества можно сопоставить взаимно-однозначный элемент из 2-го, а во 2-м ещё останутся "непокрытые" элементы, то мощность 2-го множества выше ;)... Поехали?

 

1. аппаратная надёжность ... не хуже, для AX даётся расчётное (а другим оно не бывает) значение MTBF - 23 года, это выше большинства производителей hard PLC...

2. климатика ... -10 - +60 ... и по другим параметрам тоже - уровень PLC; в тех же австрийских тонелях АХ просто висят под открытым небом, в достаточно большом количестве, и за 5 лет эксплкатации нет ни 1-го вышедшего из строя; но это и не единственное изделие AutomationX, там есть линейка на гораздо более жёсткую климатику;

3. I/O ... AX работает в реально сделанных проектах со всем множеством MIO от известных производителей: Siemens, Allan Bredley, Schneider Electric, ...

3. ПО - программирование в 5-ти языках МЭК...

4. устойчивость и надёжность ПО, по области применения в crirical mission? очень спорный критерий ... но АХ работают в учебных полётных иммитаторах пилотов, с центрифугой и барокамерой, принятые как штатное изделие сначала ВВС Австрии, потом ещё несколькими европейскими странами, затем - Китаем... здесь сбой чреват тем, что на 1-го дорогостоящего в обучении пилота в ВВС становится меньше, когда центрифуга пойдёт вразнос...

5. время цикла ..., ну, это сильно зависит от задач, но для средне-небольших задач время цикла PLC Schneider Electric нередко: 200-500мс., для АХ - 6-10мс.

6. отсутствие движущихся частей? ... кого-то умиляло - так вот же оно и есть...

Ну, что ещё есть у PLC? ("ну чем, чем ещё грузины лучше чем армяне?"(с) ;)).

 

А вот то, что ни один hard PLC не обеспечивает:

1. многозадачная ОС QNX, в которой могут даже помимо PLC работать любые пользовательские процессы, и уж гарантированно оставляя столько таймслайсов PLC, чтоб он "залился"...

2. как следствие - все протоколы, алгоритмы и архитектуры взаимодействий 2-х и более PLC как между собой, так и "вверх"...

3. просто "безумная" масштабируемость:

- для систем класса 1, как я их разделил раньше (автономных + локальных) всё как и с PLC - я не вижу различий, если вы их мне внятно не покажете...

- для малых систем класса 2 (не автономных + локальных) на 1-м АХ могут работать как параллельные процессы и PLC логика, и SCADA/HMI визуализация, взаимодействуя по IP loopback ... я представляю какой вой сейчас подымут поборники "PLC девственности"... не надо, господа, в такой ОС это не будет менее надёжно, чем просто логика PLC...

- для средних систем класса 2 - HMI-формирование может происходить как АХ задача, но визуализация - на скольки угодно рабочих станциях, выполняющих только функции Х-сервера, в любых ОС, как-угодно мобильных, лишь бы они по любым каналам были доступны по IP...

- о системах класса 3 (распределённых) - здесь просто говорить не приходится, потому что здесь брандовые технологии просто ничего внятного предложить не могут ... разве что кроме ещё одного уродства - OPC сервера, которое не только "узаконивает" тот безумный трафик по всей распределённой системе, но ещё и удваивает его (трафик к OPC + трафик от OPC).

4. возможность ПО от любого 3-го производителя: если меня по каким-то причинам не устраивает МЭК-транслятор от AutomationX, я легко могу его сменить на ISaGRAF или CoDeSys или т.д.

 

Я думаю, что это ещё далеко не все свойства, которые обеспечивает гибкость (которая, в свою очередь, обеспечивается открытостью).

 

Вот например (мне это кажется настолько значащим, что забыл - но дописал позже):

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

 

P.S. а вот из числа WAGO реализаций

http://www.wago.com/wagoweb/documentation/...at/d287000e.pdf

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

Примеры тут ни при чем, тут надо стандарт смотреть, и там отыскивать фразу типа "ассемблером ПЛК должен быть язык IL"

Отсутствие какой-то фразы не может служить оправданием ваших домыслов. Идите с такими аргументами, мелкомягким доказывайте, что MSIL не имеет права на существование, т.к. .NET исполняется на машинах, ассемблером которых MSIL не является.

 

Отсутствие этой фразы в стандарте свидетельствует о том, что это Вы бредите, утверждая, что IL в рамках МЭК 61131-3 - это ассемблер.

 

Также на досуге попытайтесь разобраться в отличиях IL и MSIL. Перечитайте МЭК61131-3, в конце-то концов, и уясните, что там и никакой IL-машины не предполагается.

 

Алексей, прошу прощения, но должен честно признаться, что Вы утомили меня своим уровнем общения. Да и уровень Вашей аргументации тоже невысок. Так что, не обижайтесь, но большинство Ваших постов я буду игнорировать.

[Andrew2000 0]

Надеюсь, Вы не будете обижаться, если я только ключевые слова дам:

SNAP, AJILE, NET-MASTER, TINI.

"никто не слышал" я лично воспринимаю как признание, что просто Вы не слышали.

Страусиная позиция, пардон.

Конечно, за информацию обижаться не буду, спасибо скажу.

Пойду посмотрю - как обсуждаются эти "ключевые слова" на форумах по АСУТП...

 

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

А образованием я и не просил заниматься, я просил _конкретный_ пример, хотя бы один ... нет его.

Ну и ладно :)

[Andrew2000 0]

Ссылка (просили?), посмотрите здесь:

Я просил конкретно про Qnet...

покопавшись нашел там же - tcpip-qnx.pdf - спасибо!

 

Кстати, а чем закончилась история с синхронизацией тактов ОС?

Меня этот вопрос тоже интересунт - это еще одна причина (правда не главная), по которой я не оспользую QNX в PLC.

 

1. протокол не столько закрытый, как вы заметили, (не стоит труда его посмотреть tcpdump и всё рассмотреть), сколько проприетарный, т.е. он имеет смысл применительно только к QNX и вот почему...

Вот! Это его главный недостаток. Т.е. его можно использовать только для обмена сообщениями между контроллерами с QNX - тут он, конечно, замечательно подходит.

[Andrew2000 0]

А во-вторых, что должно быть "интересного"?

... Поехали?

...

- о системах класса 3 (распределённых) - здесь просто говорить не приходится, потому что здесь брандовые технологии просто ничего внятного предложить не могут ... разве что кроме ещё одного уродства - OPC сервера,

Да, ничего интересного ... тот же

http://www.nnz-ipc.ru/html.news/lincon.html

тот же WAGO ... теперь таких контроллеров много.

Но, появились то они совсем недавно! Когда MHz стали без вентиляторов.

И появилась возможность нагрузить проц и различными протоколами, и многозадачными ОС.

И это хорошо! кому-то такие решения действительно нужны, поэтому, как кто-то здесь писал у Siemens паника :)

А "брандовые технологии", которые тут приводились в пример, это все же из прошлого века, но и они подтянуться - поменяют 20 или 40 MHz процы на 600-800 MHz, .....

А про OPC Вы загнули - OPC предназначен не для распределенных процессов (тут и CanOPEN прекрасно подходит), а для виндовых СКАДА.

Но, кому-то все равно нужна синхронность, и тут "тяжелые" ОС не подходят.

 

Вот например (мне это кажется настолько значащим, что забыл - но дописал позже):

5. возможность вести весь технологический цикл разработки, отладки, тестирования - на стандартном PC оборудовани

Ну, это обеспечивается любым ISaGRAF-ом или CoDeSys-ом и никакого отношения к контроллерам не имеет.

[=AK= 12]

Отсутствие этой фразы в стандарте свидетельствует о том, что это Вы бредите, утверждая, что IL в рамках МЭК 61131-3 - это ассемблер.

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

 

Вырисовывается определенная закономерность. Вы превратно понимаете то, что вам говорят, выхватываете какие-то слова из контекста, перевираете их, а затем спорите с тем, что сами напридумывали. Точно на такой же основе построены ваши бредовые статьи про МЭК. :maniac:

 

Я буду только рад, если вы перестанете отвечать на мои посты, т.к. никакой полезной информации в ваших ответах нет. Тратить свое время на то, чтобы втолковать вам прописные истины, я тоже не намерен, потому как не верю, что это может привести к положительным результатам. Судя по тому, что вы несете свой бред уже 8 лет подряд, вразумить вас невозможно. Чтобы ваши глупые пространные сообщения, состоящие по большей части из ненужного цитирования, не мозолили глаза, посылаю вас в игнор.

[Olej 0]

Да, ничего интересного ... тот же

http://www.nnz-ipc.ru/html.news/lincon.html

тот же WAGO ... теперь таких контроллеров много.

 

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

От LinCon-8000, который представляет "Ниеншанц" отличается только тем, что в качестве УСО использует MIO из комплекта любого брандового производителя PLC, в отличии от LinCon-8000, у которого 3-7 слотов специфических расширений, и эти расширения могут мне, например, не подходить а).по характеристикам б).по максимальному числу.

А так - всё это устройства одного класса...

 

А "брандовые технологии", которые тут приводились в пример, это все же из прошлого века, но и они подтянуться - поменяют 20 или 40 MHz процы на 600-800 MHz, .....

 

Сами по себе мегагерцы ничего не решают, для многих задач и 20MHz было бы достаточно... главный "ущерб" их лежит не в скорости, а в закрытости, и тем самым навязывании потребителю "только наших tools".

 

А про OPC Вы загнули - OPC предназначен не для распределенных процессов (тут и CanOPEN прекрасно подходит), а для виндовых СКАДА.

 

Нет, не загнул ;) - я просто углубляться не стал. Сама идея OPC как вынесенного набора именованных (периода исполнения) тэгов - стоит внимания, всё здесь же:

http://qnxclub.net/modules.php?name=Forums...=viewforum&f=18

- она обсуждалась и моделировалась.

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

 

Вот например (мне это кажется настолько значащим, что забыл - но дописал позже):

5. возможность вести весь технологический цикл разработки, отладки, тестирования - на стандартном PC оборудовани

Ну, это обеспечивается любым ISaGRAF-ом или CoDeSys-ом и никакого отношения к контроллерам не имеет.

 

В этих средствах - конечно обеспечивается, но вы не обратили внимание, что сами выделили только независимых производителей? ;) А в брандовых средствах для закрытых PLC - не обеспечивается: начинайте с того, что монтируйте стенд, а потом начинайте отработку (про иммитаторы не надо мне рассказывать ;)).

 

Вот! Это его главный недостаток. Т.е. его можно использовать только для обмена сообщениями между контроллерами с QNX - тут он, конечно, замечательно подходит.

 

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

 

Кстати, а чем закончилась история с синхронизацией тактов ОС?

 

Это я не понял о чём? - о синхронизации времён процессоров распределённой системы, которая там обсуждалась? или нет? Но это - совсем частный вопрос - и лучше продолжить его обсуждение там где начали, чтобы не засорять...

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

Надеюсь, Вы не будете обижаться, если я только ключевые слова дам:

SNAP, AJILE, NET-MASTER, TINI.

"никто не слышал" я лично воспринимаю как признание, что просто Вы не слышали.

Страусиная позиция, пардон.

Конечно, за информацию обижаться не буду, спасибо скажу.

Пойду посмотрю - как обсуждаются эти "ключевые слова" на форумах по АСУТП...

 

А они пока никак не обсуждаются. АСУ ТП - это очень консервативная область. Думаю, они пока применяются только в малой автоматизации/научных исследованиях. А на рынке АСУТП появятся через пару лет. Ну, может, в связи с реформой ЖКХ (будь она неладна) будет некий всплеск применения, например, при автоматизации автономных котельных (личные предположения)... за рубежом возможно применение в рамках концепции умный дом...

 

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

А образованием я и не просил заниматься, я просил _конкретный_ пример, хотя бы один ... нет его.

Ну и ладно :)

 

Дело в том, что Вы пытаетесь использовать меня в качестве справочника, а это меня не устраивает.

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

[zetvictory 0]

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

 

------

Теперь по порядку.

1. Лет 10 назад, когда еще было туго с Интернетом (в плане информации и доступности чужих решений) пришлось написать некое подобие ОСРВ с основными атрибутами -- менеджером процессов, системой управления памятью, каналами связи между процессами, динамической линковкой ресурсов и кода. Времени было потрачено довольно много, хотя система используется до сих пор и выполняет свои функции. Накладные расходы на системные функции были относительно невелики (ассемблер), но некоторые особо критические участки кода все равно пришлось писать вне общей системной канвы (спектрометрия, непериодические аналоговые импульсные сигналы с темпом до 60000 в секунду).

 

2. Немного позже, для других задач, была создана система с возможностью дистанционного изменения кода. Она имела виртуальный стековый процессор, интерфейсное ядро и другие атрибуты байт-код-интерпретатора. Был написан простой ассемблер, встроенный отладчик и множество прикладных программ. Учитывая специфику передачи кода через СМС все работало нормально, но для оптимизации выполнения сложных процессов приходилось расширять систему команд виртуального процессора, т.е. системе не хватало гибкости. Использовать ее случаях, когда объем кода не ограничен сотнями байт, не имеет смысла.

 

3. В последующих проектах стал использоваться другой подход -- простейший цикл обработки потоков данных, все асинхронные события обрабатываются в прерываниях. Процессы представляют собой автоматы состояний с ограниченным количеством времни нахождения в обработчике события. Память в 90% случаев распределена статически. Связи между процессами реализуются либо в статике, либо через простые интерфейсные вызовы. Преимуществом такого построения является полнный контроль над потоком выполнения команд и отсутствие сюрпризов, связанных с готовыми библиотеками. Также в любой ситуации можно легко гарантировать время отклика.

 

Выводы:

 

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

 

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

 

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

[zetvictory 0]

Одна маленькая история из сегодня к теме:

мир движется в сторону ПЛК на основе Wintel - а куда еще?

 

Всем известны автоматические системы пожарного наблюдения/тушения и пр.

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

[zltigo 1]

Одна маленькая история из сегодня к теме:

мир движется в сторону ПЛК на основе Wintel - а куда еще?

 

Всем известны автоматические системы пожарного наблюдения/тушения и пр.

Ага ИЗВЕСТНЫ!!!

Свеженькая Российская АЭС. Для обслуживания в пределах 'ядерного острова'

на БЩУ в уголке стоит 19" стойка с LCD экраном явно WINдозного вида. За пределами 'острова' именно

железный ящик и никаких лишних ручек

Так вот, этот "железный" зараз задул четыре помещения всяким дерьмом и никаких концов и никаких

гарантий, что не повторится - "жутко надежная" система. Тоже похоже пользует

простейший цикл обработки потоков данных....

но толи не успел, толи не срослось что-то....

:-)

 

Вот такая история.

[Stanislav 0]

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

.................................................................

3. В последующих проектах стал использоваться другой подход -- простейший цикл обработки потоков данных, все асинхронные события обрабатываются в прерываниях. Процессы представляют собой автоматы состояний с ограниченным количеством времни нахождения в обработчике события. Память в 90% случаев распределена статически. Связи между процессами реализуются либо в статике, либо через простые интерфейсные вызовы. Преимуществом такого построения является полнный контроль над потоком выполнения команд и отсутствие сюрпризов, связанных с готовыми библиотеками. Также в любой ситуации можно легко гарантировать время отклика.

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

Заниматься программированием системы с закрытым ПО считаю просто мазохизмом...

 

 

...Выводы:

 

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

 

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

Тоже так считаю. Для задач DSP это уж наверное.