Его и не нужно обсуждать - это как только 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, т.е. превращает сеть в кластер процессоров, прозрачно взаимодействующих...



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



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

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



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

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

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

Ну, во-первых, не 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

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

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

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

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


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

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

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


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

Да, ничего интересного ... тот же
http://www.nnz-ipc.ru/html.news/lincon.html
тот же WAGO ... теперь таких контроллеров много.
Но, появились то они совсем недавно! Когда MHz стали без вентиляторов.
И появилась возможность нагрузить проц и различными протоколами, и многозадачными ОС.
И это хорошо! кому-то такие решения действительно нужны, поэтому, как кто-то здесь писал у Siemens паника
А "брандовые технологии", которые тут приводились в пример, это все же из прошлого века, но и они подтянуться - поменяют 20 или 40 MHz процы на 600-800 MHz, .....
А про OPC Вы загнули - OPC предназначен не для распределенных процессов (тут и CanOPEN прекрасно подходит), а для виндовых СКАДА.
Но, кому-то все равно нужна синхронность, и тут "тяжелые" ОС не подходят.


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

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

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

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

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



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



Нет, не загнул - я просто углубляться не стал. Сама идея OPC как вынесенного набора именованных (периода исполнения) тэгов - стоит внимания, всё здесь же:
http://qnxclub.net/modules.php?name=Forums...=viewforum&f=18
- она обсуждалась и моделировалась.
Но построить её на проприетарном протоколе OLE (который для реализации на фиг не нужен), да ещё позиционировать как панацею для производителей контроллеров, которые не умеют поддержать более стандартные протоколы связи ... при этом подталкивая их как минимум к удвоению трафика - вот ещё одна выхолощенная идея.



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



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



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

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



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

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

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

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

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

Выводы:

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

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

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

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


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

Ага ИЗВЕСТНЫ!!!
Свеженькая Российская АЭС. Для обслуживания в пределах 'ядерного острова'
на БЩУ в уголке стоит 19" стойка с LCD экраном явно WINдозного вида. За пределами 'острова' именно

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

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

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

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


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

Да, задал вопрос там - посмотрите...
http://qnxclub.net/modules.php?name=Forums...&t=165&start=45

+1

подписываюсь под всем...
удивляет похожесть логики в решениях..


с уважением
(круглый)

По результатам обсуждения самым простейшим, "гибким", "управлямым" и главное
_ПОНЯТНЫМ_ инструментом оказался лом.
Ура товарищи!!! :-(

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

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

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

Так вот по отношению к 'старой'. НЕ ИМЕЮЩЕЙ ПРЯМОГО ОТНОШЕНИЯ К ВАШЕЙ.

Если говорить о нетребовательности к ресурсам, то все с точностью до наоборот на самом деле :-(
Для "простейшей циклической" все хорошо обстоит, если ресурсов немеряно (кем-то 'гарантированно' что их ВСЕГДА хватит) и не надо ИХ ДЕЛИТЬ. Как только ресурсов начинает не хватать - проблема.
Предсказуемость тоже на самом деле в 'паркетных' условиях когда кем-то 'гарантируется' достаточнрость ресурсов и поток воздействий не выходящий за зарарнее очерченные рамки. Как только возникает нештатная ситуация с точки зрения предварительных 'договоренностей' - и надо выживать и в этих условиях - проблема. Обвеска 'лома' разными рюшечками для более мягкого падения на ногу не эффективна и как минимум снижает его простоту и предсказуемость в штатных условиях. Особенно больно смотреть на людей создавших 'лом' и вдруг с детским изумлением обнаруживших, что он 'сломался' - ЭТОГО НЕ МОЖЕТ БЫТЬ это-же 'лом', он не может сломаться. Никаких конструктивных мыслей, к сожалению, часто более не присутствует :-(.

'Ломы' - нужный и полезный инструмент, просто их применимость в _реальной_ жизни примерно равна
соотношению реальных ломов и прочих инструментов придуманных человечеством за свою историю.

А что скажете об использовании SDL Z.100 в системах реального времени?

я им не пользовался но каждодневно пожинаю плоды этого творчества, так как поддержка кода компилированного с SDL на С очень трудна .

Абсолютно верное утверждение...
Такое же верное, как "лучше быть здоровым и богатым, чем бедным и больным"(с)
Только беда в том, что все абсолютно верные утверждения - они всегда сродни тавтологии, и ничегошеньки нового не вносят ...
Да, цикличность "сидит" в задачах управления, но ... она с той же плотностью "сидит" во всех вычислительных задачах, хоть минимальным образом взаимодействующих с реальным миром за пределами процессора:
- задачи ЦОС с блочным алгоритмом обработки: блок 1024 отсчётов с той же закономерностью, что и 1024 "локализованных переменных" PLC считывается по такту и так же точно после цикла обработки отдаётся в "выходные переменные"...
- да и задачи ЦОС с потоковой алгоритмикой ... частичное обновление так же создаёт новое пространство "входных переменных"...
- а любые задачи радио-/гидролокации?
- да любой планшетный измеритель координат, который циклически только считывает и "выводит" на матричный индикатор...

Т.е. правктически всё ... если мы только исключим из рассмотрения чисто "оффисную" группу программ, типа "Hello world!" или MS Office...
Хотя ... всяк, кто хоть однажды писал хоть одну оконную (важно не сколько "оконную", сколько "событийную") программку, хоть MS Windows, хоть Х UNIX, хоть Photon QNX ... - знает, что логика любой такой программы:
1. в цикле считать все зарегистрированные события...
2. и отработать на них реакцию...
3. и снова всё то же в цикле...

Так что разговоры о какой-то там особости PLC/АСУТП задач ... это всё та же старая песня "в пользу бедных"(с)...



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

Я не знаю, что такое "тактируемая цикличность" ...
Если это единовременность считывания входов / запись выходов ... то это удобно, и "достаточное" условие, но в принципе не "необходимое". Я знаю фирму (называть никого не буду, чтобы крику не было), которая многие (десятки?) внедрённых АСУТП систем реализовала на QNX штатных средствах, и, в принципе "не подозревая" о тактируемой цикличности, реализовала их асинхронно:
- цикл обработки продолжительности T...
- начинается со считанного значения переменной №1 ...
- но если к T/2 значение переменной №M измениось, то в операциях после T/2 будет использовано это значение...
Да, они именно из-за этой асинхронности много и часто торчат в командировках по рекламациям ... но кто же им доктор?

Здесь - прямая аналогия между потенциальной и синхронной реализацией логики на элементах И-ИЛИ-НЕ (синхронные элементы тоже на них строятся, так что здесь я всё правильно сказал ) о которой я раньше говорил... Может быть и та и другая схема, потенциальная, в принципе, производительнее, но чревата гонками ... и чтоб не искать себе на ж. приключений - в сложных системах почти всегда шли на синхронную реализацию.
Но важна здесь "единомоментность" (синхронность), а не сколько тактируемость...
Да, при неаккуратном использовании асинхронной схемы можно просто в принципиально устойчивую петлю авторегулирования привнести неустойчивость, связанную только с техникой обработки...
Хорошо, примем синхронную схему, но будем при этом помнить, что это "перестраховка" и вопрос удобства.

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

Ещё один миф, связанный с терминами подобными "тактируемой цикличности" (мне просто приходилось его слышать в разных исполнениях ) состоит в том, что вот тот цикл: ... - ввод - обработка - вывод - ... и надлежит исполнять именно так: начали ввод (пассивно ожидая при том реакции медленных внешних устройств, многих и поочерёдно), когда он благополучно закончился - начнём обработку и т.д. Вот отсюда и циклы обработци многих брандовых PLC 200мс, 500мс ... , когда на соизмеримых процессорах soft PLC часто дают цифры 5-10мс.
Так этому мифу мы обязаны нескольким факторам:
- что автоматчики, мотивируясь "особой специфичностью" отрасли, "в лоб" перенесли на процессорную схему выполнения любую их сердцу схему синхронной параллельной логики тех же логических элементов...
- а ещё тем, что они свято убедили себя в том, что ничего кроме "однонитевой" MS DOS для использования здесь не нужно, и ещё ничего более "надёжного", чем a'la MS DOS и в природе придумать невозможно...

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

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

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

Конечно, и этот слой можно выполнить в "тактируемой цикличности", да ещё и разнести его в распределённой системе на километры (я реально знаю умельцев, которые это обсуждают!), как это делается:
1. кроме M=1000, скажем переменных "внешнего мира" существуют N переменных связи с уровнем вверх (их число часто не намного, но меньше M, но, в принципе, может быть и больше: 500-1300, скажем)...
2. теперь к циклу "долбежа" с периодом, скажем 0.2 сек., "вниз" к источнику данных - мы добавим ещё цикл "долбежа" сверху по M переменным с периодном в 0.1 сек... (хорошо, когда это на каналах протяжённостью в несколько километров )
3. которые "тактируемо циклично" будут считываться в качестве входных уровнем PLC...

Хорошая такая ... "тактируемая цикличность" ...

Прошу прощения, что вклинился, но цикличность имеет прямое отношение к Рефлексу. Дело в том, что Рефлекс (как язык), сам строится на базе модели гиперавтомата (простенькая моделька, модифицирующая конечный автомат к задачам управления, имеющая удобопонятный для программиста вид).
Так вот. Там прямо-таки прописана тактируемая цикличность. Уже в модели.

Что касается ресурсов. Их нехватка не может быть решена на уровне ПО, тут надо менять платформу, и эта вещь абсолютно независима от ПО. (разве что от их ресурсоемкости, а тут уж требования "лома" к ресурам гораздо ниже, чем у любой ОС)



Разумеется, есть некие требования к вычислительной платформе в качестве редуцированной perfect synchrony hypothesis (прошу прощения, не знаю перевод на русский): смысл именно в том, что есть ограничение на максимальную ресурсоемкость цикла. Ну, а как иначе, если Вам нужно перевести груз в пять тон, то нужно и выбирать пятитонник, а не полуторку... ну или полуторку, но четыре штуки.

"Лом", кстати, чем хорош, что для него проводить АПРИОРНУЮ оценку ресурсоемкости гораздо проще, чем для случая ОС (тем более закрытых).

И "лом" действительно можно сломать, но сделать это сложнее, чем сложные ажурные паутинки, которые лопаются просто от дуновения ветерка.

Прошу понять меня правильно, я не против ОС, как таковых, просто ОС - это тоже не панацея, и у них свои тонкие места. Правильная стратегия тут - трезво оценить все плюсы и минусы, и принять правильное решение.

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

У Вас плохая ситуация... то же самое, что поддерживать АСМ-код, сгенерированный Си-компилятором, или тот же Си-код, сгенерированный Си++ компилятором. Есть "метауровень", уровень концепции, стратегии, который "вшит" в язык, а есть уровень реализации. И это разные вещи.

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

А я думал, что такое уже давно только в заповедниках


Ну, Вас послушать - все автоматчики дебилы. Я, все-таки, сильно удивлюсь, если мне покажут PLC, который работает не так.
Под циклом ввода и вывода везде (я так думал) понимается именно копирование _среза_ данных из/в системы ввода/вывода в основной (ПЛК) цикл.


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

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


Дело в том, что специфика задач управления цикличностью не ограничивается.


Тактируемая цикличность - это привязка момента начала цикла к физическому времени.
Просто цикличность - это

тактируемая цикличность - это

Примерно так. Вряд ли в какой ОС так забавно обрабатываются команды оператора.


Тоже важный момент. Хотя тут скорее не вопрос "единомоментности", а вопрос фиксации среза системы.
Чтобы всякие там побочные эффекты не вылазили, да и удобство организации обработки - немаловажный момент... на мой взгляд.


Не. Упомянутая тактируемая цикличность это не то.


Ну это вроде как бы стандартное решение. Хотя в ISaGRAFe, я слышал, есть такое дело: пока все сетевые устройства не опросит по RS-485 с места не сдвинется...

Но это не говорит о том, что об обработчиках прерываний в ДОСе не знают. Знают и повсеместно пользуют.


Ну, а что делать? Люди-то разные бывают.


Но это действительно так!


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


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

Обычно используется асинхронный сбор и синхронная обработка (если позволите так выразиться).

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

Только замечу, что:
- что точно по той же нарисованной вами схеме, даже перерисовывать не захотелось , обрабатываются потоки событий (информации) - во многих и многих областях, рядом не лежавших с АСУТП, те же задачи ЦОС с блочными алгоритмами ... да и многие другие;
- а кроме: if (Timer()){ ... - с таким же успехом может быть if(<некоторое внешнее условие>) (например в той же радиолокации: достижение диаграммой ФАР конца диаппазона и начало нового скана), часто такое управляюее событие бывает почти точно привязано к временным интервалам (хотя это и не обязательно)...
- и тогда ещё целые классы задач включаются в область рассматриваемых...

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

"Когда вас уличат в неграмотном написании, говорите: "В моём написании это всегда выглядит так""(с) Д.Хармс .



Да, но только "обрабатыватель прерываний в DOS" - это профессия сродственная сапёру .



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

Но разночтения здесь наши в осоновном связаны с тем, что мы говорим о 2-х разных слоях АСУТП одновременно:
- взаимодействия "вниз" от PLC, где программный опрос + Modbus и еже с ними - вполне допустимое решение, может ничего более и не надо... но только этот слой в единственности своей присутствует только в системах "чёрный ящик", автономных + локальных, как я их разделил: класса 1...
- и взаимодействия "вверх" (и в "стороны" - с другими такими же узлами PLC), без учёта которых нельзя говорить всерьёз о производительности, о её потенциальных потерях, и возможностях эффективной организации взаимодействий в системе...

Но об этов - в другой раз, и так много получилось .

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

Можно еще уточнять и вылизывать определение, но надеюсь, что и это вполне внятно.

Ну, и это не вся специфика алгоритмов управления. Хотя бы даже и не во всех событийных системах такое можно встретить. А вот в цифровых управляющих - повсеместно. Начиная с уровня ПИД-регуляторов.


Ну, не знаю... пока все живы... :-)))


Про распределенные системы... я чего-то не очень понял, что там такого страшного. Сетевые драйверы сидят на прерываниях, да и сидят.

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


Ну, в общем-то Вы правы, я действительно не вижу принципиальной разницы в связи по Модбасу (думаю, Вы имели ввиду все-таки RS-485 на UART а ля IBM PC) и связью по системной магистрали, или CAN (если говорить о Модбас), или Ethernet (если говорить о RS-485)... протоколы, да и протоколы. Одни чуть проще, другие чуть сложнее. В последнее время унификация идет по линии Ethernet... Для того же Modbus - это Modbus(UDP), Modbus(TCP/IP).

Совершенно не согласен! Вы сами для себя делаете инструмент, нравится лом? Пожалуйста! Но для резьбы по дереву я предпочитаю набор фигурных резцов.. если хотите аналогий. И почему-то не хочется покупать циркурярную пилу BOSH, хотя она очень производительная и пилит отличные доски кубометрами за смену.. Решается задача резать из дерева статуэтки, по одной в день...



С каких это пор ручное распределние ресурсов (в ассемблере, например) более затратный процесс чем любая операционная среда? Знаете сколько движений нужно сделать для организации очереди сообщений, самой примитивной? Мне кажется так могут рассуждать люди, которые ОСРВ представляют в виде черного ящика, чудесным образом "распределяющего" эти непонятные "ресурсы". Готовая ОС иногда отлично распредляет головную боль разработчиков на весь период жизни изделия.



Зато когда с задачей не справляется готовая закрытая система всегда есть возможность развести руками и свалить всю вину за _свои_ ошибки на разработчиков ОС.. Собственно говоря, любая программа на 90% это обработчик "нештатных" ситуаций. Обработаете ли вы их сами или свалите на ОС с непредсказуемым результатом -- решайте сами.

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

Надеюсь, понятно излагаю? Предложение простое: примените процессор на 10 долл дороже, решите предметную задачус НУЛЯ и обойдетесь двумя программистами вместо 15 + покупка чужого кода, который решает разные задачи в общем виде.

Приведу пример из практики, когда пришлось написать дизассемблер для Intel 196NP и декомпилировать готовую библиотеку плавающей точки, чтобы исправить ошибки в вычислении функции квадратного корня и обработчике перполнений. Компилятор был куплен официально, но обращение в BSO Tasking так и осталось без внятного ответа, а сроки проекта поджимали... "вот тебе бабушка и Юрьев день!"

)) А я думал я один такой извращенец - занимался тем же, тока Tasking для Infineon Tricore - исправлял CPU_BUG в кишках float библиотеки. Но, слава богу, остальные библиотеки с исходниками.

Так что в тему можно добавить - когда не нужна ОС - когда ее исходники не доступны

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

Все это непосресдвенно касается и написания программ в самом общем смысле, никакой специфики тут нет. Почему ОСРВ и softPLC так рьяно завоевывают западный рынок и так тяжело проходят на нашем? потому что у них выделяются совсем другое количество времени на разработку. Не могут они себе позволитиь тратить столько времени, сколько тратят у нас. Поэтому эффекктивность среды разарботки у них считается одним из важнейших параметров системы.
Когда вы используете НАСТОЯЩУЮ ОСРВ (т.е. прошедшую сертификации, с нормальной историей и success story, то вероятность, что ошибка будет связана с самой ОСРВ - примерно 1% и почти наверняка она уже документирована. Когда вы пишете свой код - вы каждый раз создаете новые ошибки :-)


Насчет объема кода - полностью согласен, но вот насчет уровней абстракции..... сильно сомневаюсь, в противном случае ничего кроме структурного программирования не было бы нужно... чем дальше ваш код от предметной области - тем он менее понятен, его труднее модифицировать, в нем дольше искать ошибки и в итоге он менее надежен.


Не верю (с) Станиславский.
Как два программиста могут с НУЛЯ решить задачу быстрее чем 15, работающих с готовым инструментарием?

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

Хорошо сказал Goroshko Egor - настолько хорошо, что даже цитировать отдельные места не хочется... (жаль, что это не я сказал! ).

Добавить можно бы только то, что при самом поверхностном рассмотрении, желание "всё написать с нуля" - оно проще, за него проще отвечать, но происходит оно ... от страха (именно и только от страха) использования чужих механизмов. Если вас не устраивает (ошибается) в конечном итоге некоторая возможность из операционного окружения, sqrt(), например - то добавьте свою реализацию sqrt() к той же операционной среде (библиотекам etc.), даже не удаляя никаким образоим ту исходную реализацию, которая вас не устроила. Размер? а кого интересует на сегодня размер? вы хорошо представляете тот объём ненужного кода, который прикомпоновывается к вашей системе при использовании любых tools?



Да и в отношении объёма кода ... "слухи сильно преувеличены"© - простейшие функции вы да, можете реализовать "с нуля" в 10-100 строк кода, но ... использование сложнейших моделей поведения, типа "менеджер ресурсов", в операционной среде реализуются в 100-200 строк (только интерфейс), а нечто подобное по функциональности потребует "с руки" - многих тысяч строк кода (с пропорциональным числом привнесенных ошибок!).



Я тоже до определённого времени грешил тем, что дизасемблировать нечто проще... ровно до тех пор, когда начинаешь понимать, что преодолев свой страх, всё делается на порядки производительнее.



И святая вера в наличие исходников здесь - не панацея... об этом давно уже писалось и обсуждалось, и я здесь не первый: в осносной массе их никто не читает, только поддерживает психологически мифическое сознание того, что "можно прочитать"... ну и что из того? внесение исправления в сложный исходный код часто приводит к внесению новых 3-х тонких ошибок, которые выявятся только при массовом и долгосрочном тестировании...
Поэтому панацея - не "открытость кода", а: а). соответствие его выверенным стандартам поведения a'la POSIX + б). массовостью (тысячи пользователей) и долгосрочностью (годы и десятки лет) его испытания и тестирования. Это есть и необходимое и достаточное условия!

А страх, прочно базируется на незнании :-( и нежелании/неспособности постигать новое после
некоторого освоения и изобретения первого "лома".

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

Не только "не читает", а еще и исправлять приходиться. А что делать, если не работает.


Целиком ЗА! Но где это все взять?
Где достать "годы и десятки лет) его испытания" для нового микроконтроллера?
Вот я становлюсь этим "его испытания и тестирования" - а для этого мне исходники нужны.
А у специализированных изделий "тысячи пользователей" не бывает.

О разных областях говорим.

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

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

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

Не хотелось бы, чтобы реальная оценка вопроса подменялась позицией "Я - смелый".

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

В принципе это правильно - имея доступ к отладочной информации того инструментария, с которым работаешь, намного проще анализировать его поведение и свои проблемы. Хотя в конечном счете все упирается в качество инструментария и в первую очередь качество его документированности. Именно это важно в первую очередь, ведь только сами исходники могут мало помочь - взять хотя бы тот же stl - отдельные его места практически не читаемы (хотя на это и есть объективные причины, точнее были на момент написания этой библиотеки). Даже тот же QNX местами имеет весьма загадочные конструкции в заголовочных файлах типа вложеных неименованных структур и unions. И очень помогает в этой ситуации именно документированность и хорошо описанное rationale (как и почему это должно работать).
Т.е. я хочу сказать, что открытость исходников к сожалению часто приводит к бедности документации, что делает систему более непонятной, чем закрытая система, но хорошо документированная.

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



Вернее, столько ДЕНЕГ? Согласен, если у нас на качественную разработку потребительского изделия достаточно потратить в среднем 10-15 тыс. у.е. за пол года времени, то у них это зарплата одного инженера за три месяца примерно...



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



Все зависит от задачи. Могу поспорить, что 15 программистов потратят больше времени на совещания и в результате код будет более объемным. Простой пример: при разработке и вндрении протокола требуется изменить/добавить новые возможности; один прогаммист делает все молча за 15 минут вместе с отладкой, двое перекидываются коротким описанием и структурами за пол часа, 10 -- два часа спорят, какой протокол применить (не выдумывать же новый!?)



Лучше что? Утверждаю: ручной код на ассемблере наиболее быстрый и прозрачный, т.е. с точки зрения машины он лучше. Другой вопрос, нет времени все писать на ассемблере и тем более заниматься "складыванием байтов", когда поколения процессоров сменяются раз в год-полтора.



Знаете, мне действительно страшно использовать компоненты, работу которых нельзя проверить. А вам не страшно будет садиться в самолет, например, если вы не уверены в его надежности? В самолете один двигатель, один бак, одна пара шасси... Хорошо еще если парашюты выдадют!

Бывают приложения в которых беспечность, как крайняя форма смелости не проходит.



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



Скажите пожалуйста, а все эти ОСы не люди написали? Да, объем текста нужен немалый. Для примера, драйвер файловой системы FLASH в ручном исполнении занимает 4540 строк, но в его работе после 550 тыс. часов наработки в различных условиях и изделиях нет сомнений. Как он работает в ЛЮБОЙ ситуации я знаю точно, могу отвечать материално за результаты, а вы готовы заплатить из своего кармана за сбои в работе черного ящика на базе готовой системы? Обычно производители софта стыдливо отгораживаются WARNINGами и "ограниченными лицензиями", когда разговор идет об ответственности.

Вы можете реализовать "с нуля" любые функции, любой сложности. Все остальное есть вопрос желания, времени, терпения и навыка. Более того, заглядывая в чужой код, за который заплачено денег, разве никогда не возникало разочарования типа "Ну кто так строит?" ©

Есть подозрение, что использование чужих "готовых библиотек", где надо и не надо частично происходит от страха перед невыполнимой задачей или нумения огранизовать и поддерживать крупный проект или от лени. Лень родилась раньше нас, эт ясно, а страхи проходят после первой попытки построить нечто крупнее 100 тыс. строк. Попробуйте! "Не пожалеете, если останетесь живы..." © М.Твен



Каменный век в программировании продолжается! Ура!



Чужие механизмы потому и "чужие"... Лучше бы вы сказали: "стандартных механизмов"! А постигать (читай: созерцать и размышлять) занятия по времени бесконечные. К сожалению пока заказчики не готовы платить только за созерцание.

Я Вас понял - самолетами Вы не летаете, поскольку их сделали не Вы и скорее всего перед посадкой
Вам не дали все "проверить" (постучать ногой по стойке шасси и понюхать керосин, а что Вы еще можете 'проверить'?). Понятно.
Но после этого Вы почему-то пишете:

Как-то у Вас все наизнанку вывернуто - использование орудий труда c 'рынка' вместо собственноручного изготовления каменного топора называете 'каменным веком'.

Боюсь вы немного путаете - это называется не каменный век, а натуральное хозяйство. Боюсь история уже наглядно продемонстрировала всю неэффективность такого подхода. В области программирования, что бы вы не говорили :-) натуральное хозяйство осталось исключительно в самых консервативных областях. И дело не в надежности/ненадежности чужого кода, натуральное хозяйство сохраняется там, где это могут себе позволить разработчики. Когда время на разработку достаточно большое, что бы тратить его на создание велосипедов. Когда работа команды разработчиков оплачивается в часах, заказчик никогда невыделит средства на написание вещей, уже существующих.


Любопытная у вас логика. А вы не заметили, что из нее вытекает? Получается, что западные разработчики намного квалифицированнее наших? И могут сделать за три месяца тот же продукт, что наши за пол года? А?
Мне кажется что это не совсем верно, да и практический опыт показывает обратное. Просто у них время - это действительно деньги. И не могут они себе позволить тратить пол года там, где можно потратить всего три месяца. А мы пока что можем себе это позволить, не везде конечно. И именно по этому еще остаюстся у нас подобные дисскусии. Я собственно и занимаюсь тем, что руковожу разработкой СКАДА системы для европейской фирмы - системного интегратора. И требования по надежности этой системы - самые жесткие. Фирма занимается автоматизацией безопасностей автомобильных тунелей - а это уровень безопасности выше чем скажем в метрополитене. Ведь там основная проблема - пожары автомобилей и можете себе представить что творится в многокилометровом тунеле когда там загорается автомобиль.


А вы наверно можете написать вектор или карту, работающую эффективнее stl? Неужели кто-то выделит средства на такую работу?


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


Прозрачный????? Что значит в вашем понимании прозрачный? Мало того что он совершенно не читаем и очень тяжел для понимания, т.е. время на посик ошибок в ассемблерном коде на порядки выше чем на любом более менее высокоуровневом языке, а значит он менее надежен, так и ще и в большинстве случаев, нанаписание ассемблерного кода, сравнимого по производительности с тем, который оптимизирует компилятор также требует очень больших временных затрат.

Маленький офтопик, с вашего позволения...
Анекдот:
приходит заяц к медведю и рассказывает:
Знаешь Миша, я когда вот тут себя почешу, мне так приятненько становится. А вот если я одну лапку за спину заброшу, а потом потянусь, и вот так голову наклоню и здесь себя почешу, такие мурашки приятные по шкурке...
А медведь ему и говрит - Знаешь заяц, а не дофига ли у тебя времени?


Знаете есть еще одна причина. Попробуйте написать нечто работающее оптимальнее и надежнее stl? Или Boost?
А может если вам нужен xml вы пишете свой парсер?
Или свою базу данных, когда надо хранить и обрабатывать большие данные?
Или пишете с нуля свои компиляторы?
Одно могу сказать - я вам завидую, у вас очень щедрые заказчики!

[quote name='zltigo' date='May 25 2006, 20:51' post='117116']
Я Вас понял - самолетами Вы не летаете, поскольку их сделали не Вы и скорее всего перед посадкой
Вам не дали все "проверить" (постучать ногой по стойке шасси и понюхать керосин, а что Вы еще можете 'проверить'?). Понятно.
[/quote]

Минуточку! А вы всегда воздерживаетесь от поступков, когда страшно? По поводу самолетов существует система для поддержания их технического состояния, описания технологических процедур и сертификации компонентов. Чего стоит только запрет на вылеты всех машин определенной марки до выяснения причин аварии, повлекшей человеческие жертвы.
Не припоминаю, чтобы софтверные фирмы хотя бы оповещали ВСЕХ потребителей о существующей проблеме в софте. Не только на своем сайте вешали маленькую кнопочку "поддержка", а оповещали каждого?

[quote name='zltigo' date='May 25 2006, 20:51' post='117116']
Как-то у Вас все наизнанку вывернуто - использование орудий труда c 'рынка' вместо собственноручного изготовления каменного топора называете 'каменным веком'.
[quote]

тут уж как у кого руки стоят! Мне, например, топор не нужен а инстумента всякого за 20 лет деятельности накопилось предостаточно, чтобы не покупать чужой. Может наоборот, продать кому-то?

Позволю себе венуть цитату целиком:

[quote name='Olej' post='116148' date='May 23 2006, 14:43']
И святая вера в наличие исходников здесь - не панацея... об этом давно уже писалось и обсуждалось, и я здесь не первый: в осносной массе их никто не читает, только поддерживает психологически мифическое сознание того, что "можно прочитать"... ну и что из того? внесение исправления в сложный исходный код часто приводит к внесению новых 3-х тонких ошибок, которые выявятся только при массовом и долгосрочном тестировании...
[/quote]

Проявления каменного века я вижу здесь: "внесение исправления в сложный исходный код часто приводит к внесению новых 3-х тонких ошибок". Так происходит из-за того, что "генератор исправлений" был пЪян, сильно торопится, либо код написан криво и не годится для модификации?

Попробуйте отремонтировать "большой и сложный" автомобиль сегодня.
Большинство деталей и инструмента вы найдете стандартными и не станете вколачивать микроскопом саморезы, "внося 3 новых тонких ошибки", не так ли? В нормалной стране вам просто не дадут "вносить ошибки" даже в свой собственный автомобиль, для этого есть обученный специалист и ремонтная база. Конечно, если вы сами автомеханик -- "флаг в руки!", но тогда автомобиль не такой уж и сложный..

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

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

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



Вероятно вы не поняли Разве я сказал, что один их разработчик за три месяца справится?



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



Наверно да, а нужно? Гораздо интереснее решать новые задачи, которые еще никто не решает. А вот на них средства выделяются...



Заказчику разве не наплевать на характер ваших проблемы, если работа стоит или на выходе не то, что он хотел? Где же системный подход к проектированию или на метод "из пушки по воробьям?"



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

Вопрос не в том на каком языке написана ваша программа, вопрос в используемых подходах к проектированию вцелом!



Представляете! Однажды за пол дня написал простейший парсер XML статей в одном краткосрочном проекте на PHP и не жалею. Через полтора года при переносе сайта провайдером на PHP5 решил подправить код "оптимизировать"... В результате два дня бодался с провайдером, чтобы изменили настройки кодировок. Так в чем же дело? Клиенту (торговая фирма) есть дело до того, кем написан парсер? Сайт не работал(бы) два дня, это проблема!

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




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



Вероятно вы не поняли Разве я сказал, что один их разработчик за три месяца справится?



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



Наверно да, а нужно? Гораздо интереснее решать новые задачи, которые еще никто не решает. А вот на них средства выделяются...



Заказчику разве не наплевать на характер ваших проблемы, если работа стоит или на выходе не то, что он хотел? Где же системный подход к проектированию или наш метод "из пушки по воробьям?"



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

Вопрос не в том на каком языке написана ваша программа, вопрос в используемых подходах к проектированию вцелом!



Представляете! Однажды за пол дня написал простейший парсер XML статей в одном краткосрочном проекте на PHP и не жалею. Через полтора года при переносе сайта провайдером на PHP5 решил подправить код "оптимизировать"... В результате два дня бодался с провайдером, чтобы изменили настройки кодировок. Так в чем же дело? Клиенту (торговая фирма) есть дело до того, кем написан парсер? Сайт не работал(бы) два дня, это проблема!

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

Вы меня не поняли. Я не говорил, что заказчик должен платить за инструмент. Заказчки платит за продукт. И выбирает исполнителя исходя из соотношения - качество/стоимость. А стоимость зачастую вплотную связана с временем разработки. А качесвенный инструментарий значительно сокращает время разработки и соответсвенно - стоимость. А где вы берете инструментарий - дело уже отдельное. Можно писать свой инструментарий, а можно купить готовый. Оба варианта - отнюдь не дешовые. В первом случае вы тратите деньги на разработку, во втором - на покупку. Практика показывает что самостоятельная разработка инструмента, по качеству соответсвующего покупному более затратна. Потому что сделать качественный, хорошо оттестированный и документриованный продукт (не программку, которой можете пользоваться не только вы лично), довольно дорого ( в смысле потраченного времени, которое, как известно - деньги :-) ). Лучшая аналогия, это когда строитель сам изгоавливает дрель, пилу, бетономешалку, цемент, кирпичи ну и т.д. :-) Это ведь немного отличается от изготовления раствора используя готовый цемент и готовую бетономешалку :-)



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

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

Тогда это совсем о другом. Естественно для задач, которые не имеют готовых решений надо делать свои :-) Вы же вроде говорили о том, что предпочтительнее писать свое чем использовать чужое. Значит речь идет о ситуации, когда чужи решения уже есть - и пример вектора вполне оправдан. Но в его случае и вы сами спрашиваете - "а зачем?" Именно это вопрос возник и у меня по рочтении ваших постов. Мне тоже интерестнее решать новые задачи, не имеющие аналогов :-) .


Удивительно, зачем же тогда люди придумывают новые языки, спорят о типизации, надежности, о безопастных конструкциях языка? Почему ищут подходы создания языков на который писать программы легче, быстрее и надежнее... Вы сравните временные затраты написания приложений на С# и на С++? Да это обычно задачи из разных областей, но опыт разработки показывает, что временные затраты на сопоставимые задачи у С# в разы меньше чем у С++.

Однако все вышесказанное никак не умаляте важности подходов к программированию... просто делает это проще :-)

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

Насчет ассемблера - поддерживаю, все не так страшно.

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

Основная мысль тут (как я понял): рост затрат на организацию согласованной работы коллектива.
Проблема в том, что затраты растут нелинейно, экспоненциально.
По аналогии с параллельным программированием (многопроцессорным):
Два программиста решают одну и туже задачу не в два раза быстрее, а в полтора, три - в 1,7 раз, и т.д., а потом с ростом числа программистов наступает насыщение... а потом - увеличение времени на разработку. Т.е. наиболее эффективные проекты (с точки зрения КПД) - это минимальные по числу участников (если программисты - одинаковые с точки зрения квалификации).

А в простых задачах будет наблюдаться рост времени сразу же, при появлении уже второго программиста.

Что же касается ОС, то, разумеется, ОС может существенно сократить сроки, и предоставляет всякие полезные штуки в виде кучи драйверов, стеков протоколов, среды разработки, полезных утилит и т.д. и т.п.

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

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

мы тоже обычно пишем на С:
и логику работы проще отлаживать на РС, чем на целевом процессоре (можно организовать вывод в файл, на графики и т.п.) и все остальные преимущества ЯВУ.
а дальше случаи из практики:
1. Кривой компилятор (holtek) - генерит код просто огромных размеров, при этом не умеет использовать особенности процессора. пришлось писать на асме работу с флагами, прерываниями и т.п. (не входило приложение в 8 Кб)
2. В некоторых компиляторах не предусмотрена обработка вложенных прерываний (контекст сохраняется в оверлее).
3. Обработка быстрых прерываний в PIC.
4. Монитор событий с переключением банков РОН в F2MC

в общем, это разговор об одном и том же, к тому же не по теме ветки.

По теме.
Любопытно, что отмечается несколько подходов:
1. Использование автоматной логики.
2. Использование обработки событий.

которые в свою очередь делятся на:
1.1. Реализация автоматов, непосредственно в суперцикле.
1.2. Использование ОС и языка технологического программирования для описания тех же автоматов в суперцикле.

2.1. привязывание обработчиков к монитору или к прерываниям
2.2. привязывание обработчиков срествами ОС к тем же прерываниям.

при этом, споры идут между 1.1 и 1.2 и между 2.1 и 2.2, а это не так интересно, как противопоставление 1 и 2. Т.е. есть ОС, нет ОС - это ерунда. Важно как выбрать модель представления на этапе проектирования, чтобы она сама себя не погребла при развитии системы.

В частности, меня интересует, как, например, olej планировал свою систему управления при обработке событий.

С удовольствием, ... но я не совсем понял что именно вы имеете в виду?
Много о том (если я правильно предполагаю) обсуждалось (-ется) здесь:
http://qnxclub.net/modules.php?name=Forums...viewtopic&t=268
http://qnxclub.net/modules.php?name=Forums...viewtopic&t=279
http://qnxclub.net/modules.php?name=Forums...viewtopic&t=276
http://qnxclub.net/modules.php?name=Forums...viewtopic&t=277
Кроме того, предполагаю, это будет уже совсем другое обсуждение, слабо относящееся к этой теме .

Любопытно еще и то, что некоторые из использующих "автоматный"/FSM подход считают, что они проектируют событийные архитектуры. Т.е. они не видят разницы между автоматной логикой и обработкой событий.



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

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