[Виктория 0]

Так как автор поста http://electronix.ru/forum/index.php?showtopic=12972

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

 

Вопрос может быть поставлен так - автору скорее всего и не нужна ОС РВ. Кругу задач его предметной области (ЦОС) свойственна - цикличность (каждый такт - ввод+обработка+вывод), жесткое РВ, работа с аппаратурой возможна на уровне конфигуривания специализированной библиотеки. Намерено так написала :) . Чем тогда это не "IsaGraf" (или любой другой пакет языков программирования ПЛК), скажем так "IsaGraf для жесткого реального времени"? Или по другому - нельзя ли применить подход МЭК к АСУТП для другой предметной области (которые также трудоемки, также требуют высокой надежности ПО и у которых уже виден базис свойств). Например, к таким задачам - ЦОС, алгоритмы функционирования информационно-измерительных систем, ...

Будет ли при этом этот новый case-инструмент альтернативой ОС РВ? Это возможно только на базе ОС РВ или самостоятельный путь развития программных технологий?

 

Приглашаю всех к дискуссии. :)

[SM 0]

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

[Harbour 0]

Ну в пользу ОС РВ можно упомянуть переносимость приложений на другие архитектуры и легкость повторного использования кода. Прогресс в данный момент таков что встраиваемую платформу менее чем с 8Mb RAM и 200MIPS'ов уже не закладывают - по стоимости они все сравнимы с меньшими, а по трудоемкости кодирования ...

[zltigo 1]

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

Столь усеченно-однобокую трактовку "качественно софта" оставлю на Вашей совести.

А вот по поводу "лишних ресурсов у железа" для RTOS дело обстоит с точностью до наоборот -

RTOS позволяет делить ресурсы в случае их нехватки. А когда ресурсов "завались" можно и бездумно и беcсистемно заниматься чем-нибудь другим.

[Evgeny_CD 0]

IMHO по осям.

 

1. Ось - это совокупность стандартов и методологических подходов,

которая обеспечивает:

 

* разработку кода силами команды (>1 человека), причем код, написанный

одним человеком, с небольшими усилиями используется другим

 

* повторное использование кода от проекта к проекту

 

* переносимость между целевыми платформами и средами разработки

 

2. Ось - это средство ограничения "динамического диапазона сознания".

Т.е. вначале мы делаем проект "широкими мазками" - прикидываем,

сколько надо ресурсов. Затем понимаем, каков механизм взаимодействия

частей. Потом берем отдельно каждую часть, и концентрируемся только на

ней, да на ее IO интерфейсах. Без такой декомпозиции решать задачу

написания софта, например, для любого коммуникационного контроллера -

просто мазохизм (_любая_ коммуникационная система имеет много

состояний, и потому очень сложна в действительности)

 

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

стандарта ОСи. Крайне полезно не изобретать велосипед в области IP

стеков, файловых систем, GUI и прочего, а сконцентрироваться на

целевой задаче - ибо именно за нее деньги платят, а не за гуй (хотя

это мало кто понимает).

 

4. Качество софта - понятие очень сложное и многоплановое. К байтам и

тактам оно имеет слабое отношение.

 

Не забываем, что софт - это часть проекта, он не сам по себе живет. И

портируемость, например, часто важнее свехкомпактности кода,

написанного на асме - вот снимут проц, и что делать - все

переписывать заново?

 

Я бы сказал так. Качественный софт - это софт, созданный в рамках

некого набора правил, который обеспечивает максимизацию профита конторы

в рамках заданной метрики.

 

Метрики могут быть разными:

 

* создали - продали - разбежались, пока не догнали не добавили

 

* много лет работали, вышли на новый рынок, проявили себя - продали

контору вместе с наработками мощному конкуренту. Поскольку стоимость

конторы в таком случае состоит почти полностью из интеллектуальность

собственности, т.е. софта в нашем времени, вот тут-то следование

единым стандартам на протяжении многих лет и окупится - разница в

цене может быть 10 и более раз (либо Вашу гениальную собственность

никто не купит - ибо только Вы можете разобраться в помойке на Вашем

сервере).

 

* многие другие.

 

В любом случае, не однозначного ответа на все вопросы сразу. Надо

приучить себя к тому, что каждый ответ - это сумма ответов с весовыми

коэффициентами, причем веса динамически меняются

[SM 0]

А вот по поводу "лишних ресурсов у железа" для RTOS дело обстоит с точностью до наоборот -

RTOS позволяет делить ресурсы в случае их нехватки.

 

Нет. Это не так. Если ресурсов не хватает для задачи, дели их, не дели, а реалтайм-программа уже никак не получится. Ибо будет иметь отклик больший, чем допустимо. А если ресурсов хватает (впритык), то в 99% выгоднее их поделить самому исходя из особенностей задачи, платформы и т.д., чем использовать готовую RTOS, в которой для каждой задачи найдется что-то излишнее.

 

Да, еще RTOS полезна, когда надо быстренько накатать алгоритм, проверить работоспособность, отладить. А потом, в процессе оптимизации, ее выкинуть, как лишнюю деталь, и написать оптимальный планировщик для данной задачи. Для этого я ее и использую (в моем случае это DSP/BIOS).

[zltigo 1]

Нет. Это не так.

Просто Вы очевидно рассматриваете достаточно нишевый круг задач с достаточно ровным и

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

[SM 0]

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

Это точно. Систем с бесконечным числом каналов с неограниченной пропускной способностью делать не приходилось.

[Виктория 0]

Всем, что такое языки программирования ПЛК (стандарт МЭК) можно, например, здесь посмотреть

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]

Нет. Это не так. Если ресурсов не хватает для задачи, дели их, не дели, а реалтайм-программа уже никак не получится. Ибо будет иметь отклик больший, чем допустимо. А если ресурсов хватает (впритык), то в 99% выгоднее их поделить самому исходя из особенностей задачи, платформы и т.д., чем использовать готовую RTOS, в которой для каждой задачи найдется что-то излишнее.

 

Да, еще RTOS полезна, когда надо быстренько накатать алгоритм, проверить работоспособность, отладить. А потом, в процессе оптимизации, ее выкинуть, как лишнюю деталь, и написать оптимальный планировщик для данной задачи. Для этого я ее и использую (в моем случае это DSP/BIOS).

 

Нет. Это не так. :tongue:

Почему это вы решили, что достаточно простые (а другими они быть и не могут) "ручные" реализации будут оптимальнее, чем те, которые "обкатаны", скажем, в течении 20-30 лет? Ну и что, станете вы писать адаптивную или спорадическую диспетчеризации параллельных веток вместо round-robin для единоразового использования? И сколько ещё скрытых ошибок вы оставите в "ручной" реализации?

 

А если ресурсов хватает (впритык),

 

Если до такой степени впритык - то это признак того, что платформа выбрана неадекватная, и "выбирателя" пора гнать с работы... ;). Такая постановка ещё могла бы быть правомочной ... лет 20 назад.

 

P.S. Т.е. такая ваша позиция имеет право быть - но для очень ограниченного круга специфических задач, ЦОС как раз есть такая ниша, но и то - не всё даже, что ЦОС, а только отдельные подклассы задач в ЦОС.

[Evgeny_CD 0]

Системы программировния PLC и ОС - это разные вещи, хотя иногда они и решают схожие задачи.

 

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

 

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

 

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

 

Не знаю, я мало знаком с миром стандартов PLC- так что есть что почитать! Спасибо за ссылку на книгу!

[Olej 0]

Всем, что такое языки программирования ПЛК (стандарт МЭК) можно, например, здесь посмотреть

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]

Системы программировния 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]

...Весьма дороги ещё и потому, что брэндам этой индустрии было безумно выгодно "закрыть" всё ПО и привязать к себе потребителя... Но в последние годы, как раз, очень широко пошло направление 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]

Будет ли при этом этот новый case-инструмент альтернативой ОС РВ? Это возможно только на базе ОС РВ или самостоятельный путь развития программных технологий?

 

Хороший вопрос...

 

Говорить о том, что PLC работают "без ОС" - не приходится: там всегда присутствует runtime среда, присутствующая всегда сверх того, что написал, например, тот же технолог на языках МЭК, и именно и обеспечивающая функционирование "того ..." ;).

 

Другой вопрос - что там используется в качестве runtime?

Для PLC от брэндов (Modicon/Schneider Electric, Alan Bredley, Siemens, ...) - ответ на этот вопрос хранится покрепче "тайн мадридского двора" ... но есть у меня такое си-и-и-ильное ;) подозрение, что там - нечто не многим более MS DOS расширенного режима (по памяти).

 

С другой стороны, можно категорически такую runtime среду не относить к ОС, но это уже вопрос терминологии ... и упорства ;). И чем вам не ОС система программирования Modula от Вирта, которая realtime ну куда более, чем Win-CE? Или система Forth, которую здесь кстати рядом в теме упомнили, и на которой в своё время (не знаю сейчас) реализовывалось 70% (!) законченных проектов в робототехнике?