Цитата(Vic1 @ Mar 3 2006, 19:22)
Насчет языков программирования, если это тоже интересно (вообще то вопрос взаимосвязанный) мне кажется (крестится не буду
) основное достоинство языков МЭК - введение новых элементов языка, отражающих специфику предметной области, причем не только новых структур данных, но и структур управления (если классически смотреть на язык высокого уровня (ЯВУ)).
Сюда же еще одна мысль - естественно ОС тоже может отражать специфику предметной области, только это отражение на уровне концепций ОС, ее внутренней архитектуры, выражающееся через некоторые правила работы в среде ОС путем использования системных вызовов.
И в первом, и во втором варианте - специфика предметной области может быть отражена в базисных примитивах. Зачем? -> Упрощение процесса разработки для конкретной области задач за счет технологичности программирования (вместо ручной дрели - электрическая), опять же за счет технологичности - повышение качества ПО в среднем (не ориентируясь на оч.умелые ручки), может быть немного спорная мысль - повышение эффективности самой программы (по известным критериям быстродействия/памяти или даже соответствия требованиям жесткого РВ и другим условиям исходной предметной области). Может быть немного и загнула
Языки МЭК вызывают у меня ... какие-то смутные ощущения
, не пойму пока:
1. в объяснение почему их 5 (да ещё ISaGRAF от себя 1 вводит, да ещё всё новые предлагаются, как здесь указывали...) я как-то в одном очень заслуживающем уважения месте вычитал примерно следующее: "... комитет долго спорил, чтоб не отдать предпочтение ни одному из уже установившихся поставщиков PLC в ущерб другим ... поэтому их 5 ..." - тут и задумаешься: мы хотим обсуждать высокотехнологическое средство, или кто, как, почём и больше продаст в рыночной стихии - тогда это мне совсем неинтересно.
2. кто их использует (здесь уже столкнулись с разночтениями в терминологии: технологи / программисты)? я перед собой ежедневно вижу парней, рисующих этими tools системы автоматики... и вот что я наблюдаю:
- ни один настоящий
технолог в это занятие не полезет ... это технологу - чуждо, потому как всё равно по сути деятельности требует ... мышления программистского;
- заказчик всегда говорит: "с таким инструментом - мои эксплуатационщики всегда могут сесть и внести изменения в систему, подкорректировать её ... потом" - это
полный бред: эксплуатационщик
в принципе с таким инструментом, в силу его простоты, может "влезть" ... но единственным результатом такого влезания может быть только полное разрушение системы: исправляя в программе ошибку мы всегда вносим 3 новые, и бороться с этой прогрессией - нужно иметь навыки, и навыки эти - программистские.
- но назвать этих парней, "пишущих" на МЭК языках, программистами ... у меня как-то язык не поворачивается: они, обычно, не сильно задумываются, что такое IP-адрес, и очень удивляются, почему IP-адрес записывается как x.y.z.w, а Modbus-адрес - как x.y
, я обычно этот персонал называю "проектанты" (чтоб каждую вещь хоть как-то называть - нельзя же их называть ни технологи ни программисты).
- начитавшись предисловий, что "... работа такая не требует высокой квалификации и можно привлекать персонал невысокой квалификации..." - наши администраторы хотя бы задумались (хоть вообще об чём-то думали, например, зачем и в чьих интересах такое пишется?): это в наших то условиях? когда хлопчика ещё не закончившего институт и бегающего на занятия между работами - можно нанять за $400, а самого профессионального программиста-"волкодава" - $800 (цифры условные ... региональные
, но соотношение везде сохраняется).
Цитата(Vic1 @ Mar 3 2006, 19:22)
Интересно! Я знала только про портации CodeSys. Конечно, IsaGRAF сразу был ориентирован на различные ОС, а вот без ОС - это в какой-то мере новость.
Вот это интересное место. Дело то в том, что в
циклической алгоритмике управляющего АСУТП процесса: - ввод - обработка - вывод - , когда это принципиально однонитевой циклический процесс - вполне достаточно на все случаи жизни MS-DOS! И никаких особо специфических функций OS (RT или не RT) - особенно не нужно. До тех пор, пока не привносится каким-то образом параллелизм. Это в точности та же история, когда при работе над MS-DOS v.2 компашка Билли Г., в силу своей невежественности к тому времени, молодости и задора - напрочь исключили возможности параллелизмов из ОС (когда в более ранней и лучше CP/M этому уже уделялось внимание, и уже создавались первые версии QNX). А потом все годы "триумфального шествия" MS-DOS - это была борьба и успешные победы тех трудностей, которых нагородили с самого начала: print-spooler, мультиплексор INT 2F, TSR-программирование кто и во что горазд...
Я думаю, что успешная жизнь PLC (более 15 лет с ранних 90-х), когда в первоначальных моделях ничего управляющего более MS-DOS и быть не могло - определяется
кажущейся сверхвысокой надёжностью и устойчивостью, обеспечиваемые, на самом деле, принципиально
однонитевой цикличной природой вычислительного процесса АСУТП.
Вот здесь косвенно тоже это прозвучало:
Цитата(Andrew2000 @ Mar 3 2006, 21:57)
ISaGRAF-у ОС, собственно, и не нужна, ему нужен аппаратный таймер, по которому он будет следить за временем выполнения такта: ввод-обработка-вывод - wait, если быстро, ошибка, если переполнение такта - вот и все реальное время ...
А вот когда появляется задача связи (по Ethernet, например), то тут удобнее ОС: 1 задача - задача связи, вторая задача - интерпретатор TIC-кода (хотя, никто не мешает организовать связь на прерываниях).
Да, 1 принципиально требующая параллельности ветвь - всегда появляется при требовании сетевых средств, или, если шире - любых асинхронных обменных процессов.
Но есть и другой скрытый механизм параллельности, и это гораздо серьёзнее... Когда рассматривают вот тот цикл работы АСУТП процесса: - ввод - обработка - вывод - часто
неявно предполагается, что всё именно так и производится: по циклу ввод
начинаются обменные операции,
после завершения которых - начинается обработка полученных данных и т.д.
Но такое может быть только в крайне примитивных реализациях (которые, кстати, производители нередко именно и стараются "протолкнуть" системному интегратору).
Рассмотрим конкретный пример: 900 бинарных сигналов (это реально одна из последних задач, которую я "мозговал"), ввод каждого - не очень быстрый (RS-485 Modbus + не очень быстрая периферия) - скажем 1 мс. (это, кстати, и не так плохо)... По вот той схеме выше: начинаем читать сигнал 1, через 1 мс., получив данные - сигнал 2, ... i, ... i+1 - через чуть больше 900 мс. (1 сек.!) - начинаем логически перебирать эти сигналы, ещё 300 мс., скажем ... и т.д.
Зачем? Мы можем:
- параллельно с уже идущем циклом обработки (предыдущим)...
- запустить операцию на 1-й переменной, и не дожидаясь её завершения - на 2-й и т.д. ...
- через некоторое время операции 1, 2, ... i,i+1,... начнут завершаться, возможно совсем в другом порядке, чем они запускались...
- и вот когда все 900 операций ввода завершатся - тогда мы имеем право обновить буфер входных переменных, и следующий цикл обработки выгребет эти обновлённые данные...
- а все более ранние циклы обработки, которым придёт время начаться ранее полного завершения цикла ввода (здесь всё определяется соотношениями циклов ввода и обработки) - они спокойно возьмут себе старый комплект переменных, но только полный комплект! считанный предыдущим завершившимся циклом ввода (таким образом несколько последовательных циклов обработки могут работать с одним необновляемым набором входных переменных").
И вот здесь простейшая runtime исполняющая система PLC становится ... "просто беда"
.
Почему нельзя взять Python, LUA, RUBY, написать расширение под целевую задачу (эти языки просто по определению расширяемые) и наслаждаться реультатом? Процессы, нити в этих языках есть, сами языки, мягко говоря, помощнее всех этих мэков и рефлексов вместе взятых будут. Или виновата косность мышления?