Виктория 0 2 марта, 2006 Опубликовано 2 марта, 2006 · Жалоба Так как автор поста http://electronix.ru/forum/index.php?showtopic=12972 загубил на корню возможность обсуждения, я и открыла новую тему. Вопрос может быть поставлен так - автору скорее всего и не нужна ОС РВ. Кругу задач его предметной области (ЦОС) свойственна - цикличность (каждый такт - ввод+обработка+вывод), жесткое РВ, работа с аппаратурой возможна на уровне конфигуривания специализированной библиотеки. Намерено так написала :) . Чем тогда это не "IsaGraf" (или любой другой пакет языков программирования ПЛК), скажем так "IsaGraf для жесткого реального времени"? Или по другому - нельзя ли применить подход МЭК к АСУТП для другой предметной области (которые также трудоемки, также требуют высокой надежности ПО и у которых уже виден базис свойств). Например, к таким задачам - ЦОС, алгоритмы функционирования информационно-измерительных систем, ... Будет ли при этом этот новый case-инструмент альтернативой ОС РВ? Это возможно только на базе ОС РВ или самостоятельный путь развития программных технологий? Приглашаю всех к дискуссии. :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 2 марта, 2006 Опубликовано 2 марта, 2006 · Жалоба Мое мнение однозначно - ОС РВ нужна тогда, когда лень писать качественный софт (или нет на это времени) и есть лишние ресурсы у железа. Во всех остальных случаях не нужна. Качественный софт это такой, который при выполнении заданных требований потребляет минимум ресурсов (всех, байтов, тактов, и т.п.) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Harbour 0 2 марта, 2006 Опубликовано 2 марта, 2006 · Жалоба Ну в пользу ОС РВ можно упомянуть переносимость приложений на другие архитектуры и легкость повторного использования кода. Прогресс в данный момент таков что встраиваемую платформу менее чем с 8Mb RAM и 200MIPS'ов уже не закладывают - по стоимости они все сравнимы с меньшими, а по трудоемкости кодирования ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 2 марта, 2006 Опубликовано 2 марта, 2006 · Жалоба Мое мнение однозначно - ОС РВ нужна тогда, когда лень писать качественный софт (или нет на это времени) и есть лишние ресурсы у железа. Во всех остальных случаях не нужна. Качественный софт это такой, который при выполнении заданных требований потребляет минимум ресурсов (всех, байтов, тактов, и т.п.) Столь усеченно-однобокую трактовку "качественно софта" оставлю на Вашей совести. А вот по поводу "лишних ресурсов у железа" для RTOS дело обстоит с точностью до наоборот - RTOS позволяет делить ресурсы в случае их нехватки. А когда ресурсов "завались" можно и бездумно и беcсистемно заниматься чем-нибудь другим. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 2 марта, 2006 Опубликовано 2 марта, 2006 · Жалоба IMHO по осям. 1. Ось - это совокупность стандартов и методологических подходов, которая обеспечивает: * разработку кода силами команды (>1 человека), причем код, написанный одним человеком, с небольшими усилиями используется другим * повторное использование кода от проекта к проекту * переносимость между целевыми платформами и средами разработки 2. Ось - это средство ограничения "динамического диапазона сознания". Т.е. вначале мы делаем проект "широкими мазками" - прикидываем, сколько надо ресурсов. Затем понимаем, каков механизм взаимодействия частей. Потом берем отдельно каждую часть, и концентрируемся только на ней, да на ее IO интерфейсах. Без такой декомпозиции решать задачу написания софта, например, для любого коммуникационного контроллера - просто мазохизм (_любая_ коммуникационная система имеет много состояний, и потому очень сложна в действительности) 3. Ось - это средство использования чужого кода, написанного в рамках стандарта ОСи. Крайне полезно не изобретать велосипед в области IP стеков, файловых систем, GUI и прочего, а сконцентрироваться на целевой задаче - ибо именно за нее деньги платят, а не за гуй (хотя это мало кто понимает). 4. Качество софта - понятие очень сложное и многоплановое. К байтам и тактам оно имеет слабое отношение. Не забываем, что софт - это часть проекта, он не сам по себе живет. И портируемость, например, часто важнее свехкомпактности кода, написанного на асме - вот снимут проц, и что делать - все переписывать заново? Я бы сказал так. Качественный софт - это софт, созданный в рамках некого набора правил, который обеспечивает максимизацию профита конторы в рамках заданной метрики. Метрики могут быть разными: * создали - продали - разбежались, пока не догнали не добавили * много лет работали, вышли на новый рынок, проявили себя - продали контору вместе с наработками мощному конкуренту. Поскольку стоимость конторы в таком случае состоит почти полностью из интеллектуальность собственности, т.е. софта в нашем времени, вот тут-то следование единым стандартам на протяжении многих лет и окупится - разница в цене может быть 10 и более раз (либо Вашу гениальную собственность никто не купит - ибо только Вы можете разобраться в помойке на Вашем сервере). * многие другие. В любом случае, не однозначного ответа на все вопросы сразу. Надо приучить себя к тому, что каждый ответ - это сумма ответов с весовыми коэффициентами, причем веса динамически меняются Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 2 марта, 2006 Опубликовано 2 марта, 2006 · Жалоба А вот по поводу "лишних ресурсов у железа" для RTOS дело обстоит с точностью до наоборот - RTOS позволяет делить ресурсы в случае их нехватки. Нет. Это не так. Если ресурсов не хватает для задачи, дели их, не дели, а реалтайм-программа уже никак не получится. Ибо будет иметь отклик больший, чем допустимо. А если ресурсов хватает (впритык), то в 99% выгоднее их поделить самому исходя из особенностей задачи, платформы и т.д., чем использовать готовую RTOS, в которой для каждой задачи найдется что-то излишнее. Да, еще RTOS полезна, когда надо быстренько накатать алгоритм, проверить работоспособность, отладить. А потом, в процессе оптимизации, ее выкинуть, как лишнюю деталь, и написать оптимальный планировщик для данной задачи. Для этого я ее и использую (в моем случае это DSP/BIOS). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 2 марта, 2006 Опубликовано 2 марта, 2006 · Жалоба Нет. Это не так. Просто Вы очевидно рассматриваете достаточно нишевый круг задач с достаточно ровным и ограниченным (конечным числом каналов с жестко ограниченной пропускной способностью) потоком внешних воздействий. А реальность и "реальное время" ими не исчерпывается. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 2 марта, 2006 Опубликовано 2 марта, 2006 · Жалоба (конечным числом каналов с жестко ограниченной пропускной способностью) потоком внешних воздействий. Это точно. Систем с бесконечным числом каналов с неограниченной пропускной способностью делать не приходилось. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Виктория 0 3 марта, 2006 Опубликовано 3 марта, 2006 (изменено) · Жалоба Всем, что такое языки программирования ПЛК (стандарт МЭК) можно, например, здесь посмотреть http://www.codesys.ru/3s/index.htm (как профессионалам советую обратить внимание (дополнит. ссылки)- http://www.codesys.ru/3s/SP.htm, http://www.codesys.ru/3s/CoDeSys/Supp_pl.htm, http://www.codesys.ru/3s/OEM1.htm) Можно еще эту книгу почитать (не слишком доверяя автору, но и не слишком критикуя) http://www.natahaus.ru/2006/02/17/programm...ontrollery.html Это все давно известно для задач АСУТП (их основное отличие от задач ЦОС - "мягкое" реальное время, в остальном - много похожих свойств). Т.е. хотелось бы рассмотреть возможность использования подобной технологии для "ограниченного" круга задач ЦОС и ИИС. Чем и насколько ограничены? Или это все-таки большой круг, который тоже требует лучшей технологии программирования? Эта же идея уже витает в массах и у фирм-разработчиков (по крайней мере National Instruments (Labview - другой монстр case-технологий) в публикациях отмечает эти особенности РВ для задач ЦОС). Обязательно ли наличие ОС РВ в этом случае (для обеспечения переносимости, мобильности и надежности)? Или можно (лучше) обойтись минимальным ядром РВ (Target System), или bios (как заметил SM)? Мне этот вопрос интересен в какой-то мере в плане общего развития, интересно куда же технологии развиваются. (.. а может быть и для практики) To Evgeny_CD Я думаю, что после моего уточнения (с ссылками) Вы заметите, что все п.п.1-4 распространяются и на эту технологию, т.е. с точки зрения технологичности программирования оба подхода на одном уровне. To All Вопрос "Когда не нужна ОС РВ" вообще очень обширен. Я думаю, что каждый разработчик мог бы внести "свои 5 копеек" (и это даже не 5 копеек, другая денежная единица). Может немного ограничим пока обсуждение до моей постановки темы? Или тогда необходимо создать вторую ветку? Изменено 3 марта, 2006 пользователем Vic1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Olej 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Нет. Это не так. Если ресурсов не хватает для задачи, дели их, не дели, а реалтайм-программа уже никак не получится. Ибо будет иметь отклик больший, чем допустимо. А если ресурсов хватает (впритык), то в 99% выгоднее их поделить самому исходя из особенностей задачи, платформы и т.д., чем использовать готовую RTOS, в которой для каждой задачи найдется что-то излишнее. Да, еще RTOS полезна, когда надо быстренько накатать алгоритм, проверить работоспособность, отладить. А потом, в процессе оптимизации, ее выкинуть, как лишнюю деталь, и написать оптимальный планировщик для данной задачи. Для этого я ее и использую (в моем случае это DSP/BIOS). Нет. Это не так. :tongue: Почему это вы решили, что достаточно простые (а другими они быть и не могут) "ручные" реализации будут оптимальнее, чем те, которые "обкатаны", скажем, в течении 20-30 лет? Ну и что, станете вы писать адаптивную или спорадическую диспетчеризации параллельных веток вместо round-robin для единоразового использования? И сколько ещё скрытых ошибок вы оставите в "ручной" реализации? А если ресурсов хватает (впритык), Если до такой степени впритык - то это признак того, что платформа выбрана неадекватная, и "выбирателя" пора гнать с работы... ;). Такая постановка ещё могла бы быть правомочной ... лет 20 назад. P.S. Т.е. такая ваша позиция имеет право быть - но для очень ограниченного круга специфических задач, ЦОС как раз есть такая ниша, но и то - не всё даже, что ЦОС, а только отдельные подклассы задач в ЦОС. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Системы программировния PLC и ОС - это разные вещи, хотя иногда они и решают схожие задачи. В принципе стандарт на PLC можно рассматривать как некую очень узкоспециализированную ОС сограниченными (по отношению к обычной ОС) возможностями. Основная задача стандарта PLC - сформировать некий простой базис, в рамках которого можно решить все целевые задачи. Т.е. научили технолога АСУ ТП некоей системе программирования - и он в ней все может запрограммить - от кофеварки до ядреного реактора. Не стоит также забывать, что обычно такие системы весьма дороги, и посему реализация простейшего PLC поверх WinCE в "том" мире вполне нормальное явление, хотя я как-то с этим не очень согласен (хотя тут я становлюсь на позицию "зачем мне ОСь - я все на асме напишу", которую я не разделяю) Не знаю, я мало знаком с миром стандартов PLC- так что есть что почитать! Спасибо за ссылку на книгу! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Olej 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Всем, что такое языки программирования ПЛК (стандарт МЭК) можно, например, здесь посмотреть http://www.codesys.ru/3s/index.htm (как профессионалам советую обратить внимание (дополнит. ссылки)- http://www.codesys.ru/3s/SP.htm, http://www.codesys.ru/3s/CoDeSys/Supp_pl.htm, http://www.codesys.ru/3s/OEM1.htm) Можно еще эту книгу почитать (не слишком доверяя автору, но и не слишком критикуя) http://www.natahaus.ru/2006/02/17/programm...ontrollery.html Ссылки хорошие, спасибо. А вот книга (я её давненько знаю) ... она годится только для первого поверхностного знакомства, хотя автор на большее и не претендовал. Что более интересно - что кроме этой 1-й книги нет больше ни одной по такому обширному, да и не очень новому предмету... (потенциальные авторы: дарю идею - пишите книгу, определённо будет пользоваться спросом, не всё же писать о чайниках да для чайников ;)). Т.е. хотелось бы рассмотреть возможность использования подобной технологии для "ограниченного" круга задач ЦОС и ИИС. Чем и насколько ограничены? Или это все-таки большой круг, который тоже требует лучшей технологии программирования? Эта же идея уже витает в массах и у фирм-разработчиков (по крайней мере National Instruments (Labview - другой монстр case-технологий) в публикациях отмечает эти особенности РВ для задач ЦОС). Обязательно ли наличие ОС РВ в этом случае (для обеспечения переносимости, мобильности и надежности)? Или можно (лучше) обойтись минимальным ядром РВ (Target System), или bios (как заметил SM)? Я как-то для себя уже задавался похожими вопросами... 1. в технологии PLC (это же всё пришло из PLC?) что пинципиально нового, отличного - это строгая цикличность организации процесса: ... - ввод - обработка - вывод - ... 2. то, что кажется принципиальным - использование языков МЭК 61131-3, по моему мнению, особо принципиальным то и не является... 3. кстати, совсем не очевидно и не на виду то, что для выполнения программ, подготовленных в МЭК 61131-3 - требуется исполняющая система: ISaGRAF || CoDeSys , и они (!) являются интерпретаторами промежуточного языка (хотите, назовите его байт-код)... 4. а это очень сильно настораживает в сочетании с терминологией realtime ... 5. и как раз не в смысле скорости... здесь в обсуждениях много путаницы вносится, связывая скорость с realtime, а они даже не коррелированы, или даже коррелированы, но отрицательно: realtime по своим качествам система (операционная, целевая, любая), при прочих равных, будет медленнее, чем та, к которой это требование не выдвигается (за счёт более корректного и тщательного переключений контекстов и т.д. и т.п.)... 6. а в смысле детерминированности, предсказуемости ... и далее по цепочке надёжности - вот главные критерии риалтаймовости, ... а не слабоопределённое "гарантированное время отклика", которое все друг за другом повторяют, не очень задумываясь повторяют что ;). Вот, хоть сумбурно и в первом приближении, соображения на счёт... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Olej 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Системы программировния PLC и ОС - это разные вещи, хотя иногда они и решают схожие задачи. Понимаете, здесь есть путаница терминологическая: что есть "системы программировния PLC" - исполняющая система для программ на МЭК языках? или runtime ядро, реализующее синхронизацию всех ПО составляющих процесса АСУ, да ещё так, чтобы не нарушить принципы теории автоматического регулирования и не влететь в область неустойчивости? Если 1-е, то, конечно, ничего общего с ОС, тогда его проще с BASIC искать аналогии... А вот если 2-е - то достаточно много общего с ОС, только применительно к специфичному классу задач, у которого есть свои законы (см. выше), отсутствующие у других программных систем. В принципе стандарт на PLC можно рассматривать как некую очень узкоспециализированную ОС сограниченными (по отношению к обычной ОС) возможностями. Т.е. мы почти об одном и том же и говорим. Основная задача стандарта PLC - сформировать некий простой базис, в рамках которого можно решить все целевые задачи. Т.е. научили технолога АСУ ТП некоей системе программирования - и он в ней все может запрограммить - от кофеварки до ядреного реактора. Стандарта языков МЭК - да, стандарта PLC (я бы сказал, скорее "идеологии") - нет. Тем более, что никто технолога с МЭК языками к реактору не подпустит, хотя PLC в системе безопасности того же реактора - вполне может найтись место. Не стоит также забывать, что обычно такие системы весьма дороги, и посему реализация простейшего PLC поверх WinCE в "том" мире вполне нормальное явление, хотя я как-то с этим не очень согласен (хотя тут я становлюсь на позицию "зачем мне ОСь - я все на асме напишу", которую я не разделяю) Весьма дороги ещё и потому, что брэндам этой индустрии было безумно выгодно "закрыть" всё ПО и привязать к себе потребителя... Но в последние годы, как раз, очень широко пошло направление PC-based PLC, на базе открытых ОС, ПО, стандартов и т.д. - которое ну очень теснит вот тех многолетних брэндов. Чтоб не повторяться - я об этом много писал, вот здесь, например: http://www.isagraf.ru/forum/viewforum.php?...53e4243359fe44e - хотя даже "те" воззрения уже очень сильно сместились ;)... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба ...Весьма дороги ещё и потому, что брэндам этой индустрии было безумно выгодно "закрыть" всё ПО и привязать к себе потребителя... Но в последние годы, как раз, очень широко пошло направление PC-based PLC, на базе открытых ОС, ПО, стандартов и т.д. - которое ну очень теснит вот тех многолетних брэндов...IMHO, менеджеров, который _сейчас_ принимают решение о закупке "закрытых" систем для новых больших проектов (Газпром, РЖД, РАО ЕС), надо судить за вредительство. Своет отношение к х86 в embedded системах я выразил давно и однозначно "Членомер" производительности микроконтроллеров http://www.telesys.ru/wwwboards/mcontrol/1...es/104416.shtml http://www.caxapa.ru/mcu/wwwboard.html?id=...do=full&hilite= http://electronix.ru/forum/index.php?showtopic=6279&hl= ТЕОРЕМА о ненужности и бесполезности ((С) на название - великий VLV) x86 архитектуры во встраиваемых приложениях http://www.telesys.ru/wwwboards/mcontrol/1...es/105243.shtml http://electronix.ru/forum/index.php?showtopic=6352&hl= http://www.telesys.ru/wwwboards/mcontrol/1...es/105467.shtml http://www.telesys.ru/wwwboards/mcontrol/1...es/105965.shtml хорошее обсуждение х86 http://electronix.ru/forum/index.php?showtopic=23 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Olej 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Будет ли при этом этот новый case-инструмент альтернативой ОС РВ? Это возможно только на базе ОС РВ или самостоятельный путь развития программных технологий? Хороший вопрос... Говорить о том, что PLC работают "без ОС" - не приходится: там всегда присутствует runtime среда, присутствующая всегда сверх того, что написал, например, тот же технолог на языках МЭК, и именно и обеспечивающая функционирование "того ..." ;). Другой вопрос - что там используется в качестве runtime? Для PLC от брэндов (Modicon/Schneider Electric, Alan Bredley, Siemens, ...) - ответ на этот вопрос хранится покрепче "тайн мадридского двора" ... но есть у меня такое си-и-и-ильное ;) подозрение, что там - нечто не многим более MS DOS расширенного режима (по памяти). С другой стороны, можно категорически такую runtime среду не относить к ОС, но это уже вопрос терминологии ... и упорства ;). И чем вам не ОС система программирования Modula от Вирта, которая realtime ну куда более, чем Win-CE? Или система Forth, которую здесь кстати рядом в теме упомнили, и на которой в своё время (не знаю сейчас) реализовывалось 70% (!) законченных проектов в робототехнике? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться