|
|
PLC, многозадачность и другие неприятност |
|
Сотрю как работает народ, над реальным проектом программирования логики PLC: tools Unity Pro (Schneider-Elrctric), то же самое было уже, по-моему и в предыдущем их tools Concept (тогда ещё от Modicon)...
Проект может содержать достаточно великое множество task: MAST, FAST, до 4-х background task, до ... какого-то количества event-task + timer-task. Многие (большинство) из которых может быть periodic, с периодами активации ... ну скажем так: иррациональными относительно друг друга... Которые, в общем, достаточно асинхронно "рвут" друг-друга. Развейте мои сомнения  :
- ... достаточно хорошо зная проблемы асинхронности и многозадачности, я всегда считал, что устойчивость 2-х уровневых систем с PLC "на низу" обеспечивало только то, что PLC выполняет только циклическую задачу: in - proc - out ... - в противном случае - проще было бы реализовать всю на 1-но уровневом процессоре, том же на котором выполняется SCADA система, под управлением, пусть, высоко устойчивой OS, с обслуживанием всё тех же модулей ввода-вывода, но по прерываниям... - я понимаю, что АСУТП-шники не доверяют такой архитектуре, именнов силу её time scheduling и асинхронности, при которых обеспечить экстремально высокий уровень устойчивости становится ... вопросом - в чём я мог бы быть с ними даже солидарен... - но когда на укорне PLC вводится понятия многозадачности, асинхронности ... + всё это при полном отсутствии (вот в тех 5-ти МЭК-овских языках) даже самих понятий о примитивах синхронизации доступа к данным ... ? Та можно такого наворотить... Что это? путь профанации что "и у нас есть много модных фич" - или под всем этим сокрыта некая глубокая сермяжная правда, которую я никак не могу "поймать"? |
||
 |
||
|
Странно мне, что никакого ответа...
Я не для флейма красивого, и не в качестве провокации вопрос такой поставил: это ведь одна из составных частей вопроса о целесообразности вообще "тянуть" 2-х уровневую архитектуру с PLC в проектах АСУТП автоматизации... Хоть бы кто высказался в смысле "автор, мол, лох - ни хрена не понимает в высоком штиле нашей автоматизации" ... и аргументированно так изложил - как он сам этого "до хрена" понимает... Или вопросы системотехнического анализа будущих принимаемых решений - нас не занимает, нам бы "подсесть" на технологию кого из титулованных производителей, и "лабать" на ней значки в конструкторе SCADA системы... А засомнематься есть основания: 1. первой "красивой легендой" ещё со времён ранних 90-х была - дешевизна решений PLC для задач промышленной автоматики (PLC я здесь употребляю в достаточно узком смысле: классический PLC без OS, или со встроенным ядром от производителя, выполняющим ущербные функции последней, полностью закрытым "в интересах производителя"). Если на начало 90-х эта легенда может и соблюдалась, но на сегодня... : - процессорный модуль (один только) от того же Schneider-Electric (линии Modicon серии Quantum) стоит несколько K$ (5-7), ... полновесный promPC PC104+ millitary климатического исполнения, обвешанный каналами Ethernet,RS-485, CAN, видеоподсистемой и др. - стоит раз в 2-3-5 меньше... и это иногда вместе с встроенной runtime устойчивой OS, какой-нибудь RTOS QNX... - аргументировалось, что мол PLC не нужны такие производительные мощности, процессоры можно использовать на порядок проще - потому и дешевле... И что мы находим?: те же линейки PLC Quantum или Premium - используют процессор x86 класса P2-4 (еле разыскал на задворках много-тысячно-страничной, но совершенно пустой документации)... только обвязан этот P4 совершенно уродливым chipset... да и сам процессор x86, как вы понимаете - самый уродливой из всех наличных архитектуры для задач обработки данных... - но ведь это далеко не вся стоимость!: - из-за "уникальной" процессорной архитектуры - программирование PLC можно осуществлять только из "фирменных" пакетов (Concept | Unity Pro), стоимостью ~5-7K$, а поскольку загрузку рабочего проекта можно производить тоже только из этой среды, то добавьте эту стоимость к каждому экземпляру PLC... - но и это не всё: GUI интерфейсную часть извольте проектировать на SCADA Monitor Pro (+ ~5-7K$), ... - а поскольку "фирменная политика лицензирования" не позволяет перенести экземпляр ПО с разработческой станции на целевую, то всё это ещё раз умножаем на х2..., как минимум... Это что?: "развод лохов"? или в этом есть некоторая сермяжная правда, которую я не могу увидеть? 2. 2-й "красивой легендой" является экстремальная устойчивость PLC уровня управляющей системы - именно из-за того, что он выполняет однозадачную циклическую задачу... , но и этот аргумент - фикция, с чего я начал "разборки полётов": просто однозадачность - это была изначально как "болезнь младенчества"... Такое мы уже проходили: когда в начале эпохи personal PC были начисто отброшены давно уже сделанные наработки mainframe-ов (разделение времени, многозадачность, ... C/C++, Ada ...) - и начали на BASIC успешно преодолевать ("по-новой") проблемы, которые сами же себе наворотили... 3. ... когда в отчёте Siemens (как ведущего лидера идеологии PLC) за отчётный период 2002г. читаем: компания плнирует на ближайшие 3 года изменить соотношение PLC/promPC в своих интегральных проектах с 60%/40% на 40%/60%... 4. Да, в "интегрированных" системах разработки АСУТП от производителей - несомненным (единственным?) достоинством есть возможность всего проектирования не выходя за рамки 5-ти языков МЭК... Но кто мешает в точнсти это же делать в ISaGRAF - и исполнять в качестве runtime ISaGRAF, выполняющегося как одна из задач стандартной RTOS на стандартной архитектуре promPC. И что тогда уже мешает (см. п.2) при необходимости на том же хосте и SCADA-интерфейсную задачу, как ещё одну задачу round-robin многозадачной OS? Или наоборот - SCADA-сервер выполнить на том же promPC, а сколько угодно и сколь угодно удалённых станций визуализации - под Windows и только в качестве визуальных клиентов этого сервера? |
||
|
||
|
1.трудно с Вами согласиться - никогда решения на базе PLC не были дешевыми. Этим, кстати, обстоятельством во многом объясняется широкое распространение в странах ex-СССР решений на основе РС-based ну, может быть, за исключением некоторых отраслей, где денег по началу не считали... Сейчас мы наблюдаем существенное увеличение доли (цифры надо смотреть на сайте Control) контроллеров свободнопрограммируемых (DOS,QNX,OS9,WinCE и т.д.), которые выполняются как на х86, так и на других платформах. Эти решения позволяют существенно сокращать затраты (в том числе и на ПО), однако поскольку за ними, как правило не стоит всемогущий бренд, то разработчики при таком выборе, конечно, слегка нервничают. В свою очередь (нормальная конкурентная борьба) бренды заинтересованы в сохранении status quo - ведь в традиционные структуры систем автоматизации на "закрытых" PLC вложены гигантские средства и весь мощный маркетинг фирм-производителей направлен на его поддержание. 2.эту легенду нет смысла рушить, однако, надо знать, что: а. около 80% PLC используются в небольших приложениях - до 128 точек ввода/вывода; б. около 70% PLC используют только дискретный ввод/вывод; в. около 80% PLC используют программы с числом шагов до 20. 3. менеджеры компании не могут не замечать тенденций, складывающихся на рынке. 4. все имеет право на жизнь и это тоже, хотя есть в этом какая-то искуственность что-ли |
||
|
||
Это не со мной - это я вычитал не в одном (!) источнике, что и вызвало у меня интуитивный протест ;)... А вцелом - спасибо вам за разъяснения, они много разъясняют.
Если не затруднит, назовите некоторые (модели - производители) для образца, чтоб стало понятнее о ком речь. |
||
|
||
|
Без претензий на общепланетарный охват - из того, что представлено у нас в России: OCTAGON (практически во все карты CPU и микроконтроллеры 6000-й серии встраивается QNX, по умолчанию установлен DOS, на старшие модели можно ставить ХР Embedded), Fastwel (аналогично), ICP DAS (WinCon - WinCE.Net, LynCon - кто-то из Lynux'ов). Кстати, появился даже новый термин - PAC Programmable Automation Controller и кое-что по данной теме есть у GE Fanuc. Вообще, запустите поиск по QNX Embedded/OS/9/WinCE/PAC - много чего увидите.
|
||
|
||
Там, в исходном варианте, перечислением прописано много ... "деталей реализации", что-ли ... Интересно было бы выслушать ваше менение (оценку) - какой элемент из этого перечисления вы считаете искусственным: - использовать, например, runtime ISaGRAF на том, что вы назвали ;) PAC Programmable Automation Controller, с тем, чтобы целевую логику записывать не на С/С++, а на одном или нексольких языках МЭК 61131-3? - использовать на этом же хосте SCADA систему (или SCADA сервер без самой визуализации)... , пожалуй, в таком "совместительстве" есть некоторая избыточность (от жадности ;)), ... но есть ли в таком решении принципиально "вредные" иные свойства? - использовать на раздельных хостах саму SCADA систему (сервер) и сами экраны для её визуализации? ... так эта идея "списана" мной с реальной SCADA системы FLEX... P.S. И ещё: прокомментируйте (рсширьте), пожалуйста свою фразу:
- в каком смысле они "нервничают"? 
|
||
|
||
|
Речь шла о выполнении на одном promPC раздельных задач - работы с I/O (runtime ISAGRAF) и собственно SCADA в режиме robin-round, поскольку на promPC используется ОС РВ. Вообще, применение SCADA, работающих именно в ОС РВ достаточно экзотично, а в случае PC-based (как в рассматриваемом) и вовсе предполагает непосредственное взаимодействие с I/O без посредников в виде runtime ISAGRAF. Собственно, это и подразумевало пресловутую искусственность Ну а уж как и сколько делать станций визуализации в сильной степени зависит от решаемой задачи и, бесспорно, от бюджета проекта. |
||
|
||
|
Ах да, про душевное спокойствие разработчиков. Когда разработчик систем автоматизации выполняет проект с использованием PLC, средств их программирования и SCADA от бренда, он спокоен - для заказчика это как успокоительная пилюля, типа - "... да, не дешево, но работать то будет! Вон у людей работает! Бренд таки и не денется он никуда в одночасье!". Когда разработчик в искренном желании снизить издержки и сделать создаваемую систему доступной для широкого круга потребителей выбирает в качестве платформы свободнопрограммируемые контроллеры, то тут же его начинает одолевать обратная сторона этой самой свободы. Какую ОС использовать, писать на С или применить что-нибудь типа того же ISOGRAF, какие протоколы обмена использовать сейчас/в перспективе, какие функции и до какой степени открыть заказчику, чтобы не бегать туда/сюда, а кто и как это все будет развивать-поддерживать и т.д. и т.п. И, наконец, согласится ли с выработанным подходом "средний" заказчик? Будешь тут спать спокойно |
||
|
||
Мне, как и вам, гораздо-гораздо ;) ближе именно такое решение... и технологии программирования традиционные для PC-based... мне лично - гораздо проще прописать несколько тысяч C/C++ операторов, и гарантированно знать ("спокойно спать" в вашей терминологии ;)) как оно себя поведёт в любых экзотических ситуациях, чем разбираться в МЭК 61131-3 и прописать на его языках 10 действий. Но! - здесь на форуме как-то давно шла длиннющая дискуссия: "МЭК 61131-3 vs C/C++" ;), и при том всём, что я "не из того лагеря", в аргументациях сторонников есть одна неубиенная сторона: - для некоторых действительно сложных (громоздких) управляемых систем, в давно устоявшихся областях применения, да ещё если результат отягощён требованиями critical mission (я имею в виду, например: железнодорожный транспорт, метрополитен и т.д., СЦБ)... - ... для них давно сложились принципы (и специалисты!) проектирования, построенные на принципах релейных схем, и изначальные проектные решения прописываются в этой терминологии; - этап "объяснить" прикладнику-проектанту алгоритмику такой схемы на неформальном языке (на пальцах) классическому С-шнику - это nonsens, одно это обсуждение через "промежуточный этап" более трудоёмкое, чем сесть и самому прописать, ... и вносит столько искажений, что нивелирует всю многлетнюю традицию проектирования. - да и эксплуатационщики понимают такую терминологию описания, ... даже до степени того, что могут "по-живому" сделать небольшие корректировки уже на этапе сопровождения. Резюме: логика таких проектов должна выписываться именно в такой нотации - языки МЭК (при всех сопутствующих сомнениях в самой надёжности таких языковых конструкция с вложных условиях, см. выше - не будем испоьзовать "сложные условия" ;)). Какие могут быть варианты разрешения этой диллемы???
|
||
|
||
Вот другое мнение: И.В.Петров "Программируемые контроллеры. Стандартные языки и приёмы прикладного проектирования", под ред. проф. В.П.Дьяконова, М.: СОЛОН-Пресс, 2004 :
- я это процитировал вовсе не "в ущерб" книге, книга хорошая и полезная, но вот: имеет право быть и такое мнение. |
||
|
||
Ответить 
|
Страница 12> |
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
.
.
.