PLC своими руками - открытая архитектура

[Dragon]

Добрый день!

У меня есть задача для выполнения которой необходим свой PLC - так хочет заказчик.
Структура модульная. Пока процессорный модуль будет на ICOP-6119 (DOS, Windows embedded) по мере развития проекта можно будет использовать CodeSys или в дешевых вариантах со своей средой из одного или нескольких языках МЕК.
Для этого проэкта будет изготовлена пресформа для обливки корпусов из пластмассы.
Предлагаю сделать этот проект открытым, т.е. шины, схемы, простое программное обеспечение.

Сейчас нахожусь в стадии проектирования шины связи между модулями внутри корзины.
Хочу услышать предложения.

[ois_andrew]

Эх, жаль не в Питере - хотел бы присоединиться к подобной разработке
Какого рода предложения ожидаете?

[Dragon]

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

[ois_andrew]

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

[Dragon]

Да Вы отчасти правы. Тем более, что постепенно паралельные шины переходят в последовательные.
В последовательных есть хорошее качество мало линий и контрольная сумма. Скорость передачи должна быть хотя бы как в паралельной - если взять ISA шину скорость передачи по ней 8Мбайт, т.е. что бы обеспечить такуюже скорость передачи по последовательному каналу необходимо 8Мбайт*10=80Мбит.
Т.к. растояния не большие то такой поток можно запросто передать, но на частоты свыше 3Мбит уже проблематично найти микросхемы.
Мое решение следующее внутренняя шина должна быть паралельная+последовательный полнодуплексный RS485 (1 Мбит).
Интерфейсный модуль будет подключен к любой шине или даже к двум шинам одновременно.

[Михайло]

Странный заказчик... Что особенного в задаче, которую надо решить с помощью ПЛК? Заказчик думает сэкономить на ПЛК?
Из этого проекта выйдет одно из трех или все три вместе:
- незаконченный полурабочий проект;
- законченный проект с высокими затратами на разработку (дешевле купить готовый ПЛК и софт впридачу);
- законченный проект с высокими затратами на эксплуатацию (постоянные издержки из-за простоев оборудования).

Знаете, что разработка Linux'ов обошлась дороже, чем Windows?

[ois_andrew]

разработка Linux'ов обошлась дороже, чем Windows?

Откуда вы об этом узнали? Я тоже хочу почитать такую инфу!

[pike]

Не буду, расписывать ни чего про бизнес план создания промышленного ПЛК и суммы необходимые для создания конкурентрого продукта. Об этом уже говорилось/писалось очень много. Хотя бы отраслевую нишу для своего ПЛК вы уже выбрали?
Замечу лишь, что внутреня шина в 1 Мбит это просто смехотворно для современного модульного контроллера. Почему? И так, например, время обновления I/O в цикле контроллера занимает 1 мс (вспоминаем, что у многих программируемых реле цикл 4-10 мс, а мы обсуждаем устройство на 2 порядка выше). Сколько данных мы успеем собрать с модулей за это время?

[Михайло]

Не могу найти эту статью! Но можете почитать это:

Новый отчет, составленный группой экспертов по заказу некоммерческой организации Linux Foundation, и отражающий примерную стоимость типичного Linux дистрибутива был опубликован на этой неделе. Расчеты показывают, что для того чтобы «с нуля» разработать систему, аналогичную Fedora 9, потребовалось бы затратить 10.8 млрд. долларов. Стоимость же только одного ядра оценивается $1.4 млрд.

Отчет стал продолжением работы, начатой в 2002 году Дэвидом Вилером (David A. Wheeler), который построил свое исследование стоимости Linux на подсчете количества строк исходного кода, взяв за основу дистрибутив Red Hat Linux 7.1. На то время, по меркам разработки проприетарного кода, дистрибутив должен был стоить более 1.2 млрд. долларов.

В работе сделаны акценты на следующие ключевые моменты:
- Используя данные на 2008 год по зарплате разработчиков , создание дистрибутива Fedora 9, потребует 10.8 млрд. долларов. Система содержит 204,5 млн. строк кода распределенного по 5547 пакетам. Трудозатраты оцениваются в 60 тыс. человеко-лет.
- Применяя те же критерии к расчету стоимости ядра Linux, в отчете приводятся следующие цифры: 6.8 млн. строк кода, 7.5 тыс. человеко-лет и 1.4 млрд. долларов на разработку.
- Совместные усилия, приложенные при разработке дистрибутива, позволили создать непревзойденный по экономической ценности проект. Только за последние 2 года более 3200 разработчиков из 200 компаний внесли свой вклад в улучшение ядра Linux. Много большее количество участников было задействовано в создании всех остальных дистрибутивов Linux. Поэтому оценка полной экономической ценности проделанной работы является лишь приблизительной. Все допущения и приближения, а так же причины, по которой была выбрана существующая методология с ее достоинствами и недостатками, так же упомянуты в отчете.
- 10 наиболее крупных пакетов, из состава Fedora 9:

Пакет Млн.строк
kernel-2.6.25i686 5.9
OpenOffice.org 4.9
Gcc-4.3.0-2 3.1
Enterprise Security Client 1.0.1 2.6
eclipse-3.3.2 2.2
Mono-1.9.1 2.1
firefox-3.0 2
bigloo3.0b 1.8
gcc-3.4.6 1.8
ParaView3.2.1 1.5

В той статье было сказано, что разработка всех Виндоусов составила около 9 миллиардов зеленых (если не ошибаюсь), а разработка всех Линуксов - 13 млрд.

[hell_boy]

Не буду, расписывать ни чего про бизнес план создания промышленного ПЛК и суммы необходимые для создания конкурентрого продукта. Об этом уже говорилось/писалось очень много. Хотя бы отраслевую нишу для своего ПЛК вы уже выбрали?

Если ориентироваться на "классический" проект-менеджмент, то 90% затраченых материальных ресурсов пойдет на личное обогащение самого менеджмента. Если ориентироваться на open source модель, то материальных средств затратится ровно столько, сколько потребуется для создания действующей модели. Если у одной группы разработчиков вначале не получится, то рано или поздно появятся последователи, способные довести дело до логического конца. У крупных игроков в сфере разработки PLC чаще всего параллельно работают несколько групп, затем отбирается только одна разработка, показавшаяся менеджменту более перспективной на текущий момент. Остальные в лучшем случае дорабатываются, обычно - складываются в архив.
А ниш для open source PLC предостаточно: военка, атомная промышленность. Этим они уберегаются от различного рода закладок и траблов, связанных с закрытым кодом и архитектурой. Я пару лет назад столкнулся с тем, что готовую станцию дем.воды со своей АСУ ТП нельзя поставить на АЭС, требуется открытие всей информации, know how в том числе. Еще одна ниша - совершенно обратная первой: OEM-решения. Например, некая компания разработала уникальный техпроцесс, включающий в себя не менее уникальные алгоритмы по управлению этим техпроцессом. В силу вышесказанного, эта компания не хочет передавать информацию на сторону, вот тогда на open source PLC можно прошить и зашифровать свою уникальную программу управления.

[VADR]

- 10 наиболее крупных пакетов, из состава Fedora 9:

Пакет Млн.строк
kernel-2.6.25i686 5.9
4.9
Gcc-4.3.0-2 3.1
Enterprise Security Client 1.0.1 2.6
eclipse-3.3.2 2.2
Mono-1.9.1 2.1
firefox-3.0 2
bigloo3.0b 1.8
gcc-3.4.6 1.8
ParaView3.2.1 1.5

В той статье было сказано, что разработка всех Виндоусов составила около 9 миллиардов зеленых (если не ошибаюсь), а разработка всех Линуксов - 13 млрд.

Ну так если посмотреть по этому списку ПО, то можно увидеть, что в нём есть, к примеру, OpenOffice.org. У MS офис - отдельный продукт. Это так, навскидку.

[Marrenoloth]

Первый ответ касательно технологий :
http://www.ethernet-powerlink.org - Ethernet POWERLINK Standardization Group (EPSG). Разрабатывают POWERLINK: The first open source fieldbus protocol. Не уверен, что первый, но тем не менее.

[VADR]

Кстати, пример, невозможный в open source продуктах:
Windows XP SP2 (может быть, и в прежних версиях тоже), файл %Windir%\system32\msgina.dll, диалог 2210:

poorly.png

Ну и всякие там "Лёха Лёха ты могуч" транслитом (в тексте фильтра рисунков corel draw в ms office версии до 97 включительно) - тоже вряд ли. Те, кто открытые исходники читает, могут не понять.

[Marrenoloth]

Те, кто открытые исходники читает, могут не понять.

Точно - точно! Там в ходу каменты более интеллектуальные. Типа "so here black magic ends (almost)"

[Михайло]

Если ориентироваться на "классический" проект-менеджмент, то 90% затраченых материальных ресурсов пойдет на личное обогащение самого менеджмента.

Вы думаете люди из open source на ламборжини не гоняют? И не нужно думать, что обогащение человека, который производит полезную работу, это крайне плохо. Иначе ведь никак. Иначе ОС не будет работоспособной... Ну и насчет 90%: в софтверном проекте самое главное - это люди, они и получают практически все деньги проекта.

Ну так если посмотреть по этому списку ПО, то можно увидеть, что в нём есть, к примеру, OpenOffice.org. У MS офис - отдельный продукт. Это так, навскидку.

Ну там была немного другая статья... Искал, не мог найти.

[Dragon]

Странный заказчик... Что особенного в задаче, которую надо решить с помощью ПЛК? Заказчик думает сэкономить на ПЛК?
Из этого проекта выйдет одно из трех или все три вместе:
- незаконченный полурабочий проект;
- законченный проект с высокими затратами на разработку (дешевле купить готовый ПЛК и софт впридачу);
- законченный проект с высокими затратами на эксплуатацию (постоянные издержки из-за простоев оборудования).

Знаете, что разработка Linux'ов обошлась дороже, чем Windows?

На данный момент у нас уже есть ПЛК не модульный 32 входа+32 выхода - стоит там DOS можно поставит Windows Embedded процессор 386SX, 300M. Заказчику мы передали схемы, программное обеспечение, разные инструкции. Изделие довольно надежное и в данном случае не потребовалось больших затрат на разработку этого изделия.
По поводу простоев то как раз все наоборот. Програмы на станках закрыты, для их открытия нужны суммы и приличные, диагностика не всегда правильно показывает неисправность или показывает, но из-за неправильного перевода нельзя понять чего она хочет (скажем LP ожидает поднятия LT). Вызов импортного специалиста надо ждать неделю-две причем стоимость одного дня пребывания 300-500Є.
Что касается языков технологического программирования, то лет 5 назад для системы "FATA" (ЗАТ "Росава" ) мною такой компилятор был написан, он потдержывал два языка из 5 стандартных.

[Dragon]

Не буду, расписывать ни чего про бизнес план создания промышленного ПЛК и суммы необходимые для создания конкурентрого продукта. Об этом уже говорилось/писалось очень много. Хотя бы отраслевую нишу для своего ПЛК вы уже выбрали?
Замечу лишь, что внутреня шина в 1 Мбит это просто смехотворно для современного модульного контроллера. Почему? И так, например, время обновления I/O в цикле контроллера занимает 1 мс (вспоминаем, что у многих программируемых реле цикл 4-10 мс, а мы обсуждаем устройство на 2 порядка выше). Сколько данных мы успеем собрать с модулей за это время?

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

[pike]

Если ориентироваться на "классический" проект-менеджмент, то 90% затраченых материальных ресурсов пойдет на личное обогащение самого менеджмента. Если ориентироваться на open source модель, то материальных средств затратится ровно столько, сколько потребуется для создания действующей модели.

Очень интересно. На счет 90% задокументированный пример, желательно на базе забугорного бойца привести можете? Или у может у вас структура "обратной связи" пользователь-разработчик, структура тестирования продукта и т.п. тоже к системе личного обогащения относится?

А ниш для open source PLC предостаточно: военка, атомная промышленность. Этим они уберегаются от различного рода закладок и траблов, связанных с закрытым кодом и архитектурой. Я пару лет назад столкнулся с тем, что готовую станцию дем.воды со своей АСУ ТП нельзя поставить на АЭС, требуется открытие всей информации, know how в том числе.

Священные коровы хэнд-мэйд всплыли. В военки я меньше разбираюсь так что отложим в сторонку. А вот на счет атомной промышленности и АЭС: я, в общем-то, в свое время в ядерном НИИ успел поработать и со знакомыми, которые в этой области работают, до сих пор общаюсь. Начнем с того что назвать это отраслью применения - это попасть пальцем в небо. Одна лишь АЭС это бездонная бочка автоматизации с кучей уровней и направлений. Фраза "наш контроллер используется в системе управления АЭС" может означать и то, что он регулирует температуру в раздевалки персонала, и активную зону контролирует. А уж атомная промышленность включает в себя почти все существующие отрасли.
Ну, а на счет открытия информации и т.п. это отнюдь не основное, например, ПЛК ОМРОН используются в качестве системы управления крупной российской линии для работы с ядерным топливом. И вопросов с know how и чего у вас там внутри не было. Зато было куча вопросов по устойчивости к ЭМИ, ресурсу, изменению характеристик ряда устройств со временем и гарантии поставок данного оборудования или его полных заменителей в течении 10 лет после ввода в эксплуатацию.

Еще одна ниша - совершенно обратная первой: OEM-решения. Например, некая компания разработала уникальный техпроцесс, включающий в себя не менее уникальные алгоритмы по управлению этим техпроцессом. В силу вышесказанного, эта компания не хочет передавать информацию на сторону, вот тогда на open source PLC можно прошить и зашифровать свою уникальную программу управления.

То же мне, особенность. Как говориться все уже решили до Вас. Например, омроновских ПЛК пароль проверяется в контроллере (нельзя перехватить прослушкой порта) и после определенного количества неправильного введенных паролей подряд контроллер переходит в защищенный режим (продолжает работать, но скачать проект нельзя даже с помощью правильного пароля). Так возможно запаролировать как весь проект, так и отдельные задачи, запретив доступ к одним и разрешив к другим. Еще возможна привязка программы к партии, а у некоторых ПЛК к серийнику процессора. Ну, и еще специальные карты для переноса программ без компьютера, на которые проекты с ПК записать можно, а вот считать уже нельзя, только контроллером.
Еще предложения по плюсам open source PLC есть?

[Dragon]

Если уже начали говорить об целесообразности открытых систем, то я бы хотел напомнить в чем разница между компьютерами IBM и Apple.
IBM - имеет открытую архитектуру, поэтому многие производители делают свои комплектующие и от этого
качество этих комплектующих отнюдь не хуже чем в Aple, а цена значительно ниже.

[Dragon]

Спор о целесообразности открытых систем имеет место, т.к. дает возможность еще раз обдумать свою идею.
Но я бы хотел услышать тех, кто сталкивался с пром. контроллерами и знает устройсво шины межмодульной связи.
Я дотошно разобрался только с контроллерами Микродат и ФК5000, даже когдато сделали свой процессорный модуль, который быз в 4 раза меньше заводского и имел выше быстродействие.

[pike]

А Вы знаете как устроена межмодульная шина, скажем у того же Омрона?

Точной информации нет, но приблизительно это выглядит так:
В CJ2 несколько шин: 1 "синхронная" и 3 "асинхронных". Каждая для своего класса модулей. "Синхронная" новая (в CJ1 ее не было), сейчас задействована для обеспечения взаимодействия спец. модулей управления движением. 3 асинхронных для трех классов модулей: Basic I/O Unit (дискр. вх/вых и др.), Special I/O Unit (аналоговые, счетчики, RFID…) и CPU BUS Unit (модули пром. сетей, сетевые модули управления движением, баз данных…). Скорость обновления данных для процессора CJ2 и модуля 64 дискр. точек: 0.0041 мс.

[Dragon]

Точной информации нет, но приблизительно это выглядит так:
В CJ2 несколько шин: 1 "синхронная" и 3 "асинхронных" ...


Спасибо, это уже информация

[pike]

Изделие довольно надежное и в данном случае не потребовалось больших затрат на разработку этого изделия.

Вспомнил, что хотел спросить:
1) На влияние ЭМП испытывали? Какие результаты?
2) Сколько контроллер потребляет Вт?

[Dragon]

Вспомнил, что хотел спросить:
1) На влияние ЭМП испытывали? Какие результаты?
2) Сколько контроллер потребляет Вт?

Перед разработкой контроллера у нас была тема - система управления газовым котлом.
Особенность этой системы в том, что на плате находится трансформатор поджига это порядка 15 кВольт.
Там были проблемы, мы их устранили. Эта плата работала без збоев обмотаная этим высоковольтном проводом.
Эту технологию мы перенесли и на контроллер.
Подавать на входа и выхода импульсы помех, как определено в ГОСТе - эту работу мы не проводили из-за отсутствия такого генератора.
Реально пока сбоев замечено небыло, оборудование работает круглосуточно.
Но в этой разработке такие работы необходимо обязательно провести.
Потребление порядка 17 Вт.

[Василий Иванович]

Если уже начали говорить об целесообразности открытых систем, то я бы хотел напомнить в чем разница между компьютерами IBM и Apple.
IBM - имеет открытую архитектуру, поэтому многие производители делают свои комплектующие и от этого
качество этих комплектующих отнюдь не хуже чем в Aple, а цена значительно ниже.

Это Вы хороший пример взяли. Смею напомнить, что конечная польза извлекается покупателем не из мёртвого железа, а из связки хард + софт. Если на каком то звене в цепи добавленной стоимости разгорается конкурентная борьба, сливки как правило снимает не конечный пользователь, а кто-то, кто сидит на каком-то другом звене.
Переходя к реалиям: да, железо в открытой архитектуре дешевле. Но софт зато дороже (если его естественно покупать). И если сложить одно и другое, то в принципе PC+Windows выйдет сравнимым по цене с Apple.
Вы можете возразить, мол, берите линух. Это да, пока дешевле. Но во-первых, для линуха дороже инжиниринг, а во-вторых, полагаю, такое счастье недолговечно. Недаром фирмочка, вкладывающая средство в рекламу линуха, носит скромное название IBM.

Переходя еще ближе к телу. Если придумают контроллер открытой архитектуры, велика будет вероятность монополизации рынка ОС этого контроллера, или же софта под этот контроллер. И конечный пользователь будет платить те же деньги. Хотя я не исключаю возможности чуда, что все удачно сложится, вероятность такого чуда будет невысокой.