[733259 0]

Надежностью отличается.

Немного странно, что надёжность железа PLC в этой дискуссии служит аргументом против Рефлекса и др. "новых веяний" ("кавалерийских наскоков" ЭВМ-щиков). Существуют же "нормальные" промышленные компьютеры, неужели они недостаточно надёжны? Интересны аргументы апологетов PLC против (только для примера) http://www.nnz-ipc.ru/cgi-bin/main.pl?mode...&uid=1147065267

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

 

ЗЫ: А вот вообще круть (ИМХО) http://www.nnz-ipc.ru/html.news/lincon.html

Изменено 8 мая, 2006 пользователем 733259

[Olej 0]

посмотрите ПО AutimationX для aXcontroller (soft PLC)

Вот это, что ли http://www.mnrcan.com/xtreme_qa.phtml ? И каким боком это можно назвать PLC?

 

Это вы смотрите совсем что попало ;) ...

Вот:

http://automationx.com/produkte/eprodukte.php?area=3

[Olej 0]

С чем сравниваем Profibus и CAN?

Не надо больше про Modbus, ...

 

Здесь возникла путаница ... которую отчасти я и создал, потому как слишком поспешил вперёд, не объяснив о чём это я...

 

Все СУ, которые попадают под "сферу интересов" PLC можно поделить, чисто условно и по-верхам, на:

1. системы автономные + локальные - когда все алгоритмы управления жёстко описаны на все случаи жизни, вмешательство в работу управляющего алгоритма не требуется и даже вредно, а объект управления целиком локализован ... ну, в пределах нескольких десятков, пусть малых сот, метров.

Примеры:

- СУ металло-обрабатывающего центра;

- СУ автоматизированной конвейерной линии;

2. системы не автономные + локальные, когда есть пульт-мнемосхема оператора, который вмешивается, до противного асинхронно, в работу...

Примеры:

- недавно видел описание в журнале завершённой системы - СУ всеми агрегатами тепловоза, оператор может вмешаться, и одновременно с штатной работой запустить программу полной диагностики, например, тяговых агрегатов;

- то же, наверное, СУ всех силовых агрегатов морского судна, чем занимается, к примеру, НПО "Аврора", которые для этого развили технологию switch-программирования школы Шалыто, о чём здесь упоминали...

3. системы не автономные + не локальные (территориально распределённые), когда расстояния между отдельными узлами сбора и обработки составляют от единиц до десятков и сотен километров.

Примеры:

- СУ всеми береговыми маяками Ирлпндии - сделана под RealFlex;

- СУ безопасности движения тунелей и виадуков Австрии + Швейцарии: 120 тыс. точек управления, ~4000 км. общая протяжённость - сделана под AutomationX;

- СУ безопасности железнодорожного и паромного движения Новой Зелландии: общая протяжённость ~4000 км. ... что интересно: выполнялась отделением Siemens, которое отказалось от использования Siemens продукции, и сделали под RealFlex...

 

Меня интересуют на сейчас системы класса "3".

 

"Вниз" обмен, когда PLC использует для обмена с модулями DIO 16 или 32 точки: Modbus, Profibus, ... CAN, ... что хотите - здесь всё проще, и ... может быть.

 

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

 

Вот здесь и выясняется, что, например, что "мировой бранд" Modicon/Schneider может предложить "вверх" только slave Modbus over TCP/IP... И так будет в любой закрытой PLC архитектуре, потому как:

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

- а если бы и мог ... то опять же не смог ;) - потому что такие взаимодействия требуют очень развитой асинхронности (параллелизма задач), а у производителя так ... пс-с-с-с: MS-DOS, в котором и те что есть фиксированные компоненты и то еле вместе держатся и не разваливаются...

 

А кто реально пользуется этими абстрактными 7-ю уровнями? TCP/IP - нет,

 

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

 

Вот тот же Modbus over TCP/IP: типичный протокол прикладного уровня - Modbus -> TCP -> IP -> MAC.

Когда утверждается, что Modbus обеспечивал евиданную помехоустойчивость, пусть на RS-485 физической среде ... у меня это возбуждает огромное любопытство: какие же это поля в пакете протокола - ответственны за помехоустойчивость? я, в роде, как истоптал этот формат вдоль и поперёк, драйверы его писал ... ну не вижу, не вижу я там форматности, хоть как-то повышающем помехоустойчивость по сравнению с любым пыонэрским протоколом ... может к окулисту надо?

Да и не дело это прикладного протокола - отвечать за помехоустойчивость.

 

А как у QNet-а с доступом к среде MAC уровня? Тут два варианта - либо как у Profibus (что хорошо), либо как у TCP/IP (что плохо), как у CAN не выйдет - физика не позволит.

 

Не понял я здесь ни вопроса, ни утверждения... :(

QNET - протокол уровня транспорта, который может работать (по желанию) хоть над MAC-уровнем, хоть над IP-уровнем.

 

Никто Вам это не мешает сделать ни в Profibus, ни в CanOPEN, например.

 

Мешает, потому как кроме возможности протокола асинхронно (т.е. со slave, если хотите) отправлять сообщения - нужна ещё программная реализация на стороне сервера (того же slave-ва) что уведомлять? на что реагировать? как? - чего в закрытой PLC реализации сделать нельзя.

[Olej 0]

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

 

Я не увидел здесь противопоставление "против" как и "наскоков" особенно... (хотя может не туда смотрел? ;)).

Вопрос немного другой: открытый/закрытый PLC?

Если он закрытый - то принцип один: "жри что дали", и если дали МЭК (или даже его подмножество, что бывает), то ни о чём "сверх" обсуждать не приходится - никакого Рефлекса туда затолкать нет возможности физически, значит не о чем говорить...

 

Существуют же "нормальные" промышленные компьютеры, неужели они недостаточно надёжны?

 

Существуют. И в хорошем исполнении их надёжность не ниже брандовых PLC.

Но здесь есть своя тонкость:

- у любого PC (промышленного или нет) - не может быть "от рождения" каналов для ввода/вывода 1000 дискретных сигналов... (а 1000 - это, в общем, и близкая к минимальной цифра);

- значит их нужно "сделать", например приткнув туда PCI-адаптер Profibus, на который повесить стандартный набор Siemens MIO...

- плюс для них драйверов или сделать или навесить (в лучшем случае - использовать целевые средства типа ISaGRAF, CoDeSys, ... или тех же AutomationX)...

Но вот на этом "приткнуть" и "навесить" ("с миру по сосенке"(с)) - можно сильно растерять всю надёжность.

 

Да, в DOS есть, а в Win нет. И самое страшное это виртуальная память и отложенные прерывания.

 

Нет. И в Win нет, и в DOS нет ;)

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

 

А ошибки есть везде.

 

Конечно. Разница только в том, что в некоторых местах их - мало, в других - много, а в некоторых (DOS тот же) - валом.

 

Завалить с клавиатуры - и пытаться не буду, а ошибкой в программе (той самой - Soft PLC) не сомневаюсь, что можно, и даже QNX4.

 

Вот в том-то и фокус, что для того, чтобы придумать такой способ именно из всего программного арсенала (я про это говорил) - и то нужно предельно досконально знать происходящее в системе, и совсем это неординарная задача. Это вот и есть одно из отличий устойчивой (надёжной) ОС от ... DOS-а ;).

 

Но не в этом дело. Заваливать систему и не надо, достаточно если ядро выгрузит зависшую задачу SoftPLC - внешне от DOS-системы это ничем не отличается.

 

Отличается. Принципиально.

Задача, аварийно завершившаяся по SIGSEGV - это совершенно другое, чем заваливание системы: задача в которой это произошло может быть снова поднята-запущена монитором HAM (посмотрите эту технику), а заваленная система уже ничем (даже сторожевой таймер здесь на 100% не помощник - падающая задача/система могли напакостить в аппаратных установках периферии, и восстановит только сброс питания).

 

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

 

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

 

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

 

=AK=, я же вас просил, а вы не уважили...

Назовите этого "хорошего" брэнда, вы же его знаете ;) - а нас держите в неведении.

 

Я думаю, что потребитель, покупающий что-то типа triconex, которому нужна электромагнитная совместимость, или/и защита от помех, или/и -40+85'C, корпус с каким-нить IP, и управлять ответственным производством, и т.д. - выложит $k и даже смотреть не будет на чем (каком ЦПУ) этот контроллер сделан.

А если пользователю достаточно надежности офисного ПК, то глупо платить за контроллер больше чем за офисный ПК + SoftPLC.

 

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

Вот тот же aXcontroller - стоит порядка 3900 евро, ... это то же самое, что процессорный модуль Schneider Electric, или чуть меньше, чем Siemens...

Только 1-й - хорош, и предоставляет большую гибкость, а 2-е и 3-е - в сравнении с ним - отстой... за те же деньги.

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

[733259 0]

Вопрос немного другой: открытый/закрытый PLC?

Если он закрытый - то принцип один: "жри что дали", и если дали МЭК (или даже его подмножество, что бывает), то ни о чём "сверх" обсуждать не приходится - никакого Рефлекса туда затолкать нет возможности физически, значит не о чем говорить...

Вот-вот, интересно - есть какие-то резоны в пользу того же сименса со Step 7 против более открытых решений типа

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

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

(в то, что процесс ISaGRAF почему-то не получит таймслайса из-за "плохой асинхронности" - "Не верю"(с))

[Andrew2000 0]

Вот:

http://automationx.com/produkte/eprodukte.php?area=3

PC/104 + Windows XP Embedded ?

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

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

 

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

 

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

[Andrew2000 0]

Здесь возникла путаница ... которую отчасти я и создал, потому как слишком поспешил вперёд, не объяснив о чём это я...

Да, замешали мы все и всё в одну кучу :)

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

 

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

 

... выполнялась отделением Siemens, которое отказалось от использования Siemens продукции, и сделали под RealFlex...

еще одна "кучка"? вроде RealFlex это чистая СКАДА, или уже тоже + SoftPLC?

 

"Вниз" обмен, когда PLC использует для обмена с модулями DIO 16 или 32 точки: Modbus, Profibus, ... CAN, ... что хотите - здесь всё проще, и ... может быть.

Совершенно точно.

 

В отношении возможностей и протоколов обменов - я имел в виду обмен "вверх": между различными PLC, входящими в систему...

Вот здесь и выясняется, что, например, что "мировой бранд" Modicon/Schneider может предложить "вверх" только slave Modbus over TCP/IP...

И так будет в любой закрытой PLC архитектуре, потому как:

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

- а если бы и мог ... то опять же не смог

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

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

 

А как у QNet-а с доступом к среде MAC уровня?

Не понял я здесь ни вопроса, ни утверждения... :(

QNET - протокол уровня транспорта, который может работать (по желанию) хоть над MAC-уровнем, хоть над IP-уровнем.

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

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

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

 

Никто Вам это не мешает сделать ни в Profibus, ни в CanOPEN, например.

Мешает, потому как кроме возможности протокола асинхронно (т.е. со slave, если хотите) отправлять сообщения - нужна ещё программная реализация на стороне сервера...

Не мешает. Посмотрите протокол CanOPEN - там это все разрисовано.

[Andrew2000 0]

Нет. И в Win нет, и в DOS нет ;)

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

А я что писал? - "SoftPLC под Win не предлагать!"

 

А ошибки есть везде.

Конечно. Разница только в том, что в некоторых местах их - мало, в других - много, а в некоторых (DOS тот же) - валом.

В DOS ошибки? ну это если только Вы сами их туда привнесете (создатель SostPLC т.е.).

Если я не ошибаюсь - DOS - это загрузчик + сервисы (через прерывания) для работы с диском. точка

 

Вот в том-то и фокус, что для того, чтобы придумать такой способ именно из всего программного арсенала (я про это говорил) - и то нужно предельно досконально знать происходящее в системе, и совсем это неординарная задача. Это вот и есть одно из отличий устойчивой (надёжной) ОС от ... DOS-а ;) .

Вызову какой-нить сервис ОС из обработчика сигнала (например ошибку в лог-файл записать) - ?

 

... внешне от DOS-системы это ничем не отличается.

Отличается. Принципиально.

Задача, аварийно завершившаяся по SIGSEGV - это совершенно другое, чем заваливание системы: задача в которой это произошло может быть снова поднята-запущена монитором HAM (посмотрите эту технику), а заваленная система уже ничем (даже сторожевой таймер здесь на 100% не помощник - падающая задача/система могли напакостить в аппаратных установках периферии, и восстановит только сброс питания).

HAM и WDT - это одно и то же (для системы) - пакость в аппаратуре HAM не восстановит.

 

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

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

Хотя бы для простых, а в SoftPLC и для простых нельзя. (Не простых в смысле управления кофеваркой, а в смысле объема кода).

 

 

 

Вот-вот, интересно - есть какие-то резоны в пользу того же сименса со Step 7 против более открытых решений...

(в то, что процесс ISaGRAF почему-то не получит таймслайса из-за "плохой асинхронности" - "Не верю"(с))

Кому что нравиться.

Про "таймслайса", например в Siemens вообще вопроса не возникнет, т.к. IEC-программу отрабатывает отдельный CPU ничем более не нагруженный.

[=AK= 12]

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

Вот в этом и дело, а не в "мировом сговоре МЭК с мегакорпорациями". Чем выше эта асинхронность (на одном проце), тем ниже надежность. Поэтому PLC стараются ее вообще не допускать, насколько возможно. Синхронно они работают, или почти синхронно. Здесь напрашивается аналогия с синхронным/асинхронным стилями разработки для ПЛИС. Не то чтобы асинхронно нельзя было бы сделать в принципе, можно, однако настоятельно рекомендуется его всеми силами избегать и делать все синхронно.

 

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

 

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

 

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

 

Такие сравнительно простые псевдосинхронные системы, как PLC, могут быть протестированы досконально, и ведут себя предсказуемо. Потому что в синхронных системах "исчезает ось времени", все события происходят "одновременно". В отличие от softPLC и RTOS, что бы там маркетологи ни плели про их надежность.

 

Для верхнего уровня распределенных систем чаще всего не трeбуется та надежность, которaя необходима "внизу", где работают PLC. Xотя бы из-за низкой надежности связи, а также из-за меньшей требуемой реактивности. Однако для них и softPLC непонятно зачем был бы нужeн, там "PLC-шность" и языки МЭК неуместны, имхо.

 

Назовите этого "хорошего" брэнда

Я же явственно назвал Аллен-Брэдли, нарочито обозвав остальных "сбродом". :)

 

PS: Вы так выдeляeтe QNX в плане надежности, объясните, почему это oна надежнее DOS или той же Выни? Или она с открытым кодом (пока что только это выдавалось за волшебную палочку), а я просто не в курсе? C учетом того, что Вынь в ~80% случаев падает за счет хреновых драйверов (написанных бог весть кем, не мелкомягкими), расскажите, как в QNX пишутся драйверы, и за счет чего они будут безошибoчными. Или почему ошибки в драйверах не будут ронять QNX, хотя Линукс от них не то что падает, а частенько даже и не встает :) Может, в QNX все драйверы юзер мод, с кучей проверок? A как же с реактивностью быть? Чем для писателей кернел мод драйверов любая ось отличается от DOS-a (ведь правда не знаю, может, не догоняю чего-то)?

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

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

Большинство программ для ПЛК даже не знают, что такое calloc или malloc. Я уже не говорю про малобюджетный класс ПЛК на 51-х и прочих Atmel-ах, где и диспетчера памяти-то нет... а ОЗУ всего-то

с десяток килобайтов, а то и сотня байтов.

Ладно, приведу Вас полностью:

"

Кстати, Ваши аргументы относительно ООП и ПЛК не вполне соответсвуют реальности. В последнее время появилась куча (от разных производителей) ПЛК со встроенной ява-машиной внутри... CoDeSys также вводит ОО возможности в свои расширения МЭК-языков. Можно посмотреть также текущую реализацию МЭК 61499 (holobloc.com) там все на XML и java.

 

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

"

Так о чем тогда говорим? О "малобюджетный класс ПЛК на 51-х" или типа Logo, или про PLC в которые можно заталкать Java, или про PLC с целым набором сетевых интерфейсов/протоколов?

 

Я лично говорю о реализации функций автоматического управления и использовании при этом средств ООП, в данном случае java.

 

Но опять же вернусь к основной мысли: дело тут не в интерпретаторе, а в соответствии языка (IL)вычислительной платформе. Вернее, в отсутствии такого соответствия.

А как же Speed7 у того же Siemens/Vipa ?

(=AK= еще больше примеров привел)

 

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

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

...Основная проблема не в скриптовости, а в особой специфике класса задач автоматизации:

 

Да, канешно ;)...

Это почти дословно из Ремарка:

- В том что мы проиграли войну - виноваты евреи!

- Да, конечно, ... и велосипедисты.

- ... а почему велосипедисты?

- А почему евреи? (с).

 

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

 

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

[=AK= 12]

в ... PLC реализации сделать нельзя.

Цитаты из NI,

чтобы яснее понимать области применимости:

 

Experts from ARC, Venture Development Corporation (VDC), and the online PLC training source PLCS.net estimate that:

* 77% of PLCs are used in small applications (less than 128 I/O)

* 72%of PLC I/O is digital

* 80%of PLC application challenges are solved with a set of 20 ladder-logic instructions

 

The PC presented three main challenges:

1. Stability: Often, the PC’s general-purpose operating system was not stable enough for control. PC-controlled installations were forced to handle system crashes and unplanned rebooting.

2. Reliability: With rotating magnetic hard drives and non-industrially hardened components, such as power supplies, PCs were more prone to failure.

3. Unfamiliar Programming Environment: Plant operators need the ability to override a system for maintenance or troubleshooting. Using ladder logic, they can manually force a coil to a desired state, and quickly patch the affected code to quickly override a system. However, PC systems require operators learn new, more advanced tools.

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

Отношение такое, что java-машина используется в целой гамме современных сетевых ПЛК от разных производителей. Тенденция такая.

"от разных производителей" - и таких, про которых никто не слышал.

Приведите пример, если можно - прямую ссылку.

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

Еще попадались дипломные работы...

Ни одного известного имени.

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

SNAP, AJILE, NET-MASTER, TINI.

 

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

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

 

Про ООП в средах исполнения - приведите пример, пожалуйста, хотя бы один.

один я уже привел: www.holobloc.com

хотите больше - поисследуйте здесь:

http://www.google.ru/search?hl=ru&q=Java+PLC

(есть ссылки не по теме, но есть и по теме)

На www.holobloc.com я обнаружил только "Function Block Development Kit", про ПЛК ни слова, может плохо искал?

 

Я неверно поставил вопрос - я попросил "Soft PLC под виндами не предлагать" но ниже, а сюда это тоже относиться. Так что повторю вопрос:

Про ООП в средах исполнения - приведите пример, пожалуйста, хотя бы один (Soft PLC под виндами не предлагать).

 

holobloc.com - это сайт по МЭК61499, тут уже не о ПЛК речь идет, а о ГПС на основе ПЛК.

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

 

А вообще, про ПЛК Вы плохо искали, ищите про МЭК 61131-3.

[=AK= 12]

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

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

 

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

[Olej 0]

Вот в том-то и фокус, что для того, чтобы придумать такой способ именно из всего программного арсенала (я про это говорил) - и то нужно предельно досконально знать происходящее в системе, и совсем это неординарная задача. Это вот и есть одно из отличий устойчивой (надёжной) ОС от ... DOS-а ;) .

Вызову какой-нить сервис ОС из обработчика сигнала (например ошибку в лог-файл записать) - ?

 

Не поможет :cheers:

Даже SIGSEGV не вызовет с завершением задачи, не то, чтоб ущерб системе нанести...

P.S. Кстати, в POSIX/UNIX давно уже сигналы используются не только как средства предсмертной экстремальной реакции, но как нормальное средство асинхронного взаимодействия задач, в котором можно очень многое делать, почти всё, особенно в QNX... Это только малых детей перед сном продолжают сигнальными обработчиками пугать по старой памяти...

 

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

 

А "сервисов ОС" в QNX - нет, там микроядерная архитектура: микроядро - критично, его объём что-то не более 64К, отработанных 25 лет, практически не меняется... всё остальное - в том числе и драйверы - это нечто сродни пользовательским задачам... здесь кто-то спрашивал с иронией - так это действительно так.

 

P.S. напомню, что в x86 protected mode есть 4 кольца защиты: 0 - 3, если вы помните, все распространённые ОС считают достаточным использовать из них только 2: 0 и 3 - супервизор и пользователь... В QNX отдельные компоненты и задачи могут использовать все 4 кольца, так что говорить здесь о пользовательском и превилегированном режиме ... это как-то сильно условно.

Но, более того - QNX многоплатформенная ОС, более 10 разных аппаратных архитектур, однотипно (один и тот же код портируется, за исключением микроядра) использующая (ОС) особенности архитектуры (например MMU) на каждой из платформ.