Средство для программирования контроллера: Си или МЭК 61131?

Первоначально опубликовано Дмитрий Милосер Первоначально опубликовано Владимир Е. Зюбин Ну и я про это же говорю. МЭК не позволяет обеспечить достаточный уровень безопасности... Я ведь не зря по клапан говорю... клапан закрыть - это целая история даже в самом упрощенном виде: убедиться, что клапан можно закрывать (если нельзя - сформировать диагностику оператору, сформировать реакцию на действие) подать сигнал, убедиться, что за заданное время он закрылся, если не закрылся - сформировать диагностическое сообщение оператору и предпринять спец.действия (например, кучу других клапанов перекрыть). Опять повторюсь, при этом все решения должны приниматься и отрабатываться локализовано, а не быть разбросаны по системе. Плюс программа должна сохранять гибкость, модифицируемость, иметь адекватную наглядную структуру, позволять общаться с заказчиком в терминах тех.процесса, а не реле и микросхем 2И-НЕ и т.д. и т.п. Это и есть по моему мнению современный уровень автоматизации, принципиально недостижимый средствами МЭК. Я сам лично реализовывал подобные алгоритмы как в LD (несколько дольше и не так наглядно, но он-лайн можно контроллировать входа-выхода) и в FBD (просто и наглядно и в он-лайн все параметры видны).

Очень хорошо. Мы уже согласились с тем, что эти алгоритмы сложны в реализации и ненаглядны в LD. Теперь можно поговорить и о "наглядности" в FBD. Будем?

Первоначально опубликовано Дмитрий Милосер И не только в РСУ, но и ПАЗ. И я могу привести десятки примеров, где на МЭКовских языках разрабатывались ОЧЕНЬ опасные объекты, такие как завод по уничтожению хим. оружия, такие суперкритические установки как синтезирование трициклогексанона, гидрогенизация, гидроформилирование, алкилационные установки, этерификация для химических производств, не говоря уже про попроще: изомеризацию, каталитический риформинг и пр...

Что значит "разрабатывались ОЧЕНЬ опасные объекты, такие как завод"?! 8-) Выражайтесь поточнее... Что там было конкретно автоматизировано и какими средствами... а то из Ваших слов следует на LD АСУП построили...

Первоначально опубликовано Дмитрий Милосер Более того- в FBD я могу или взять готовый блок из библиотеки (это стандарный алгоритм в нашей системе) или, если не понравится- модифицировать библиотечный или накидать свой. Что касатся этого- убедиться, что за заданное время он закрылся, то в случае если позиционер интеллектуальный я могу вообще контроллировать реальное положение клапана, считать его "пробег", знать когда нужно заменить шток или отремонтировать (клапан сам "скажет"). И все это- в течение нескольких минут разработки. Мало того- я могу иметь защищенный доступ к настройке клапана, вести его (и не только для клапанов) журнал (чертежи, описания, даты поверок, ремонтов, калибровок и кучу подобных вещей). Составлять прогнозы по обслуживанию, эксплуатации, смотреть графики отрабоки, в общем все то, что Вы на Си будуте реализовывать кучу времени.

Ну я смотрю разговор плавно переходит в русло "интеллектуальных" КИП... ПО которых, и об этом не следует забывать, написано на Си. Кстати, в сотый раз, специально для Вас, повторяю: я не считаю, что все и вся
нужно писать на Си. Более того, собственно Си я лично
при автоматизации использую достаточно редко... Хотя и считаю это вполне допустимым.

Религиозными фанатиками тут являются как раз приверженцы
МЭК 61131.3 в его понимании а ля ISaGRAF, предлагающие
использовать FBD, IL, и LD.

Моя же точка зрения - из всего МЭК 61131.3 имеет смысл изучать и использовать только SFC+ST. Несмотря на их убогость и ограничения, это парочка все-таки имеет хоть какое-то отдаленное отношение к автоматизации.

Первоначально опубликовано Olej Первоначально опубликовано VSerg Я думаю, что уже на 5-6 контроллерах, при синхронизации их работы и обмене данными между ними на СИ вы просто умрете. Это голословное утверждение: правда очень много здесь зависит от OS и её tools поддержки обменов (так как "синхронизацию и обмен" между узлами, как вы понимаете - никакое языковое средство не поддержит). Я в QNX сам организовывал кластерную обработку данных на x86 N хостах (N - не только 5-6, но - динамически изменяющееся!) - при поддержке QNET - это "за-всё-про-всё" прописано в ~300 строк С++.

Спорно, что синхронизацию и обмен не поддерживает ни одно языковое средство. Вы изучили все языковые средства?? Ну да ладно, я не о том говорил. Я говорил об синхронизации данных и не между узлами, а между управляющими программами(можете читать процессами на разных узлах соединенных сетью). О их достоверности, о их производстве и потреблении, об изменении данных во время выполнения управляющей программы. Как было уже сказано многие среды SCADA позволяют строить распределенные системы с достаточно жестким контролем производства и потребления данных, т.е. синхронизацией. О сети мы не говорим, так как надежные среды передачи данных это в другой форум.

Первоначально опубликовано VSerg Спорно, что синхронизацию и обмен не поддерживает ни одно языковое средство. Вы изучили все языковые средства??

В обратном порядке:

1. я изучил почти все языковые стедства ;-) - до какого-то времени я взаправду считал языки, на которых сделал реальные проект или хотя бы небольшую задачу... до 23-х я считал - а потом перестал... Я это говорю не для бахвальства, а потому, что это - моя специальность и единственная : писать программы, об чём угодно, и на всём, что угодно... Другого я не умею. Это я к тому написал, что здесь в форуме ругани много: кто-то АСУТП занимается, методологией этого процесса, ... ругали здесь "теоретиков" - "которым бы книжки только писать"... Так без Хоара и Дэйкстры (теоретиков!) - не было бы ни структурных языков ни параллелизмов...

Я бы посоветовал здесь всем - уважать в собеседнике специалиста в том, что он умеет... А следовать ли этому совету - каждому самому решать!

2. то, что "...ни одно языковое средство..." не поддерживает синхронизацию и обмен, само по себе (как язык) - должно быть не "спорно", а "бесспорно"! ;-)
Все средства взаимообмена данными между хостами - опираются на транспортные протоколы обмена (кто-то должен же ваши данные переносить). В свою очередь:
- протоколы обмена - реглпментируются стандартами, в частности, многие из них - RFC: Ethernet, TCP/IP, PPP, SNMP...
- не может ни один язык содержать поддержку сетевых средств, иначе: стандарт протокола умер - и язык "выноси"...
- для каждых видов взаимообменов - вводятся моделтрующие их абстракции: socket, TLI... (которые применимы к широкому набору конкретных протоколов);
- поддержка и использование сетевых абстракций осуществляется из библиотек.
- собственно, для разделения сущностей и полномочий и продумана "7-ми уровневая модель ISO взаимодействия открытых систем"... по которой ПО и языковые средства выражения должны быть "чувствительны" только к верхним 2-3 уровням.

Первоначально опубликовано VSerg да ладно, я не о том говорил. Я говорил об синхронизации данных и не между узлами, а между управляющими программами(можете читать процессами на разных узлах соединенных сетью).

А это оно и есть - кто вам будет данные между процессами на хостах переносить?
Из тех OS, которые я знаю (до 10-ти - работал, ещё 10-ток просматриваю) - только в QNX я знаю средство непосредственного взаимодействия удалённых процессов, во всех остальных случаях - извольте через автономный промежуточный протокольный слой!

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

Данных - на разнесённых узлах?
Не верю!
SCADA возможно и могут оперировать с удалёнными данными, но только теми средствами, которые ей предоставляет базис - OS, например. И ни на грамм больше!

Первоначально опубликовано Максим Ананских Это уже становится интересным... Как справедливо заметил тут один товарищ, я совсем не разбираюсь в языках, и с трудом себе представляю, как такую штуку реализовать на паскале, не пользуясь расширениями типа hi и lo. Но на Java... Вы не могли бы привести примерчик?

Нет здесь ничего ни интересного, ни удивительного...
То, что вы используете в примере через указатель, гораздо "культурнее" (т.е. с меньшим нарушением логики языка, без изысков) реализуется в С через union:
union {
char c[ 2 ];
int i;
} x;
x.i = 258;
printf( "%d", c[ 0 ], c[ 1 ] );

То-же самое в FORTRAN (именно его я выбрал, потому, как это явно ориентированный на вычислительные задачи язык, уж ни у кого не поворачивался язык называть его зависимым от платформы):
COMMON/CCC/ I
INTEGER*2 I
DATA I/258/
...
COMMON/CCC/ L1, L2
LOGICAL*1 L1, L2
WRITE( 6, 60 ) L1, L2

То же самое - в Pascal:
type T = record case Boolean of
true: ( I : integer );
false: ( C[ 0..1 ] : char )
end; {T}
var V : T;
V.I := 258;
Write( V.C[ 0 ], V.C[ 1 ] );

В Java такие трюки "в лоб" не проходят (что связано, вообще-то, с тем, что "компилированное" Java-приложение - байт-код, цепочка байт ... что, в свою очередь, имеет серьёзные издержки). Но эффект big endian - litle endian могут тоже проявляться и здесь. Например: при взаимодействии через сокет (здесь может и не присутствовать сети - через IP "петлевого интерфейса" 127.0.0.1 - такое часто используется). При этом корреспондент по обмену (который может быть прописан и не в Java) может делать или не делать преобразований адресов, портов (htos, htol...) - в зависимости от этого у вас будет "конект" или не будет... работает тот-же эффект.

Всё это к машинной зависимости средств описания - не имеет отношения.

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

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

Как ваш МЭК будет "синхронизировать" данные, независимо каким механизмом они доставляются: RS-232, ModBus, Ethernet MAC, TCP/IP, UDP vs TCP ;-), HTTP, SNMP, FTP... - назвать ещё 1234 протоколов/механизмов?
А как ваш МЭК собирается работать в Windows, положим, OS при обмене "в стиле NFS" ... когда Windows никогда не слышала об NFS, и сочтёт всё это "мусором". Или МЭК станет "разгребать" данные на портах адаптера? какого: NE-2000, RTL-8029, RTL-8139 ... назвать ещё 4321 адаптеров? ;-)

Гммм..мдя. В общем сабж нужно было называть по другому- Средство для программирования алгоритмов для тех. процессов. Потому что мэковские языки предназначены для этого и ТОЛЬКО для этого. Не более. Не нужно приписывать им возможности для написания драйверов, протоколов и пр.

Отсюда и спорьте :) Потому как если средства разработки по Виндовз (что удобно и недорого, да и зачем там Юникс?), то сама программа транслируется под ту Ось, что использует тот или иной контроллер, будь там Юникс, или своя операционка...не важно. Т.е. кто-то хочет возразить, что например в контроллерах Triconex или Hima "крутится" не своя ОС, а Виндовз? :)

Кстати, доп. вопрос- а какое кол-во моделей контроллеров поддерживает Исаграф? И каких? Он универсален или же "заточен" под определенный тип контроллеров?