Так как автор поста http://electronix.ru/forum/index.php?showtopic=12972
загубил на корню возможность обсуждения, я и открыла новую тему.

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

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

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

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

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

IMHO по осям.

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

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

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

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

2. Ось - это средство ограничения "динамического диапазона сознания".
Т.е. вначале мы делаем проект "широкими мазками" - прикидываем,
сколько надо ресурсов. Затем понимаем, каков механизм взаимодействия
частей. Потом берем отдельно каждую часть, и концентрируемся только на
ней, да на ее IO интерфейсах. Без такой декомпозиции решать задачу
написания софта, например, для любого коммуникационного контроллера -
просто мазохизм (_любая_ коммуникационная система имеет много
состояний, и потому очень сложна в действительности)

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

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

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

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

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

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

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

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

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

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

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

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

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

Всем, что такое языки программирования ПЛК (стандарт МЭК) можно, например, здесь посмотреть
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 копеек, другая денежная единица). Может немного ограничим пока обсуждение до моей постановки темы? Или тогда необходимо создать вторую ветку?

Сообщение отредактировал Vic1 - Mar 3 2006, 06:27

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



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

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

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

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

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

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

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

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



Я как-то для себя уже задавался похожими вопросами...
1. в технологии PLC (это же всё пришло из PLC?) что пинципиально нового, отличного - это строгая цикличность организации процесса: ... - ввод - обработка - вывод - ...
2. то, что кажется принципиальным - использование языков МЭК 61131-3, по моему мнению, особо принципиальным то и не является...
3. кстати, совсем не очевидно и не на виду то, что для выполнения программ, подготовленных в МЭК 61131-3 - требуется исполняющая система: ISaGRAF || CoDeSys , и они (!) являются интерпретаторами промежуточного языка (хотите, назовите его байт-код)...
4. а это очень сильно настораживает в сочетании с терминологией realtime ...
5. и как раз не в смысле скорости... здесь в обсуждениях много путаницы вносится, связывая скорость с realtime, а они даже не коррелированы, или даже коррелированы, но отрицательно: realtime по своим качествам система (операционная, целевая, любая), при прочих равных, будет медленнее, чем та, к которой это требование не выдвигается (за счёт более корректного и тщательного переключений контекстов и т.д. и т.п.)...
6. а в смысле детерминированности, предсказуемости ... и далее по цепочке надёжности - вот главные критерии риалтаймовости, ... а не слабоопределённое "гарантированное время отклика", которое все друг за другом повторяют, не очень задумываясь повторяют что .

Вот, хоть сумбурно и в первом приближении, соображения на счёт...

Понимаете, здесь есть путаница терминологическая: что есть "системы программировния PLC" - исполняющая система для программ на МЭК языках? или runtime ядро, реализующее синхронизацию всех ПО составляющих процесса АСУ, да ещё так, чтобы не нарушить принципы теории автоматического регулирования и не влететь в область неустойчивости?

Если 1-е, то, конечно, ничего общего с ОС, тогда его проще с BASIC искать аналогии...
А вот если 2-е - то достаточно много общего с ОС, только применительно к специфичному классу задач, у которого есть свои законы (см. выше), отсутствующие у других программных систем.



Т.е. мы почти об одном и том же и говорим.



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



Весьма дороги ещё и потому, что брэндам этой индустрии было безумно выгодно "закрыть" всё ПО и привязать к себе потребителя... Но в последние годы, как раз, очень широко пошло направление PC-based PLC, на базе открытых ОС, ПО, стандартов и т.д. - которое ну очень теснит вот тех многолетних брэндов.

Чтоб не повторяться - я об этом много писал, вот здесь, например:
http://www.isagraf.ru/forum/viewforum.php?...53e4243359fe44e
- хотя даже "те" воззрения уже очень сильно сместились ...

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

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

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

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

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