Pull to refresh

Comments 23

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

Извините, но это говорит только о том, что вы много чего не видели. GE, например, вполне именитый бренд и в ее Power on Fusion все отображение векторное и нормально масштабируется.
в Simatic WinCC тоже есть скромное свойство Adapt Picture
Вот только Simatic WinCC — это привязка к использованию оборудования только от Сименса.
это, мягко говоря, не совсем верно :)
Чье оборудование применяете в проектах под WinCC вы, и главное — по каким протоколам его подключаете?
Из отечественных, навскидку, ОВЕН и ТЭКОН через OPC.
По Modbus TCP цепляли много чего (Schneider Electric, например).
Вообще там в папочке bin много всяких .chn-файлов разнообразных.

Или надо «огласить полный список, пожаллста»?
Мне как-то принесли систему для GE Fanuc — очень нахваливали, рекомендовали посмотреть и поучиться. Честно — не понравилось вообще никак, мало того что гигабайтами ставились непонятные модули, так они мне еще и ОС повредили своими сервисами так, что еле вычистил ПК после него…
Не спорю — я не могу видеть абсолютно все решения, но большинство scada-систем, что удалось посмотреть и поговорить с представителями дистрибьюторов не дают такого сервиса. В большинстве случаев самый максимальный бонус: надо в среде разработки привести масштабы к нужным, и только потом запускать под рантаймами. Но — мне проще показать как это работает в режиме реального времени в моем рантайме, нежели писать сотни слов: youtu.be/KvWrDK4Chm0
Ознакомился со скринкастом. Красиво. Видимо у меня опыт работы с действительно нормальными SCADA системами, потому как наличие масштабируемой (векторной) графики считаю стандартом de Facto. И применительно к SCADA системам, я бы не пользовался так вольно словосочетанием — «режим реального времени». Создавать свою SCADA систему, это замечательно, но меня не покидает какое то чувство сумбура в излагаемых вами описаниях. Если такое-же творится в коде…
Хорошо, буду стараться заменять на «режим исполнения», просто из-за частого употребления каких-то словосочетаний действительно стали подменять ими то, что они вообще не обозначают. Есть такой грешок.
Наконец-то запустил сайт и начал его постепенно развивать в плане информационного наполнения: справки, видео-курсов, готовых решений.

Хотелось взглянуть, но увы — ссылки нет
Помня про Хабра-эффект я пока не рискую такое сделать, ведь я все еще в процессе разработки сайта. Чуть позже.
После прочтения ваших двух статей и просмотра видео — полез дрожащими руками смотреть, сколько вам лет. Глубоко вздохнул с облегчением увидев, что вы старше, иначе бы меня съели уже черно-белая зависть вместе с восхищением, наложенным на чувство собственной непригодности: значит у меня еще есть чуть-чуть времени, чтобы стать таким же крутым перцем :-)

Сам работаю инженером-программистом АСУТП. Мне бы очень хотелось, чтобы вы взглянули на эту статейку — в ней рассказывается о принципе работы АСУ на космодроме в Гвиане. Рассказано поверхностно, но все же так, на первый взгляд, что из этого в вашей СКАДе уже можно было бы реализовать, а чего у вас еще не хватает? Может быть вы бы что-то сделали по-другому?

Почему спрашиваю — у нас СКАД пишет целый отдел. Думаю дальше объяснения излишни :-)
Статью прочитал, информации и вправду мало — в основном общие слова. Не смогу провести по ней сравнительный анализ в духе «что есть, а чего нет», потому что мало технической информации. Однако могу сразу сказать, что у меня не стояла задача создавать системы с троированием, мне пока достаточно дублирования для текущих решений, на которые закладывался. И еще — не совсем понял идею использования CAN-протокола для нижнего уровня, чем руководствовались при его выборе?
Поясню, почему вопрос такой: в далеком 2003-м когда очень много работал в Китае, был у одного китайского системного интегратора, который разрабатывал проекты АСУ ТП под ключ для нефтехимии, так вот они делали семерированную систему на базе протокола CAN для низового уровня, пришлось помогать им в разработке архитектуры такой системы, с тех пор, честно, не понимаю тех, кто на CAN работает.
Спасибо!
Вы имеете ввиду дублирование/троирование сигналов? Ну на сколько я могу судить с троированием то надежнее система получается. Один сигнал отпал — а информация от датчика все равно достоверная.
По поводу CAN протокола отвечу. Честно говоря не вижу особых альтернатив, хоть и не до конца разбираюсь. На одной плате чтобы сидело несколько устройств. В принципе можно по ethernetу, но тогда придется над UDP что-то надстраивать, чтобы не терять данные. Если по TCP, то он же не совсем реального времени. В целом, что это я вам объясняю, вы, наверное это лучше меня знаете :-) Ну вот думаю вот этом и руководствовались, отвечая на ваш вопрос, хотя выбор делал, конечно, не я, а много лет назад кто-то другой.

Я бы вот хотел сравнить просто из интереса. Реально ли сделать на вашем СКАДе такую большую систему? Тестировали ли вы её, когда, например, у вас 10 000 дискретов шлют сигнал, туева хуча аналоговых. Порядка 10 разных мнемосхем, много контроллеров ну и все вытекающие последствия.

Предусмотрено, или, может быть, вы пока планируете сделать работу за несколькими пультами операторов? Возможен ли показ одной и той же мнемосхемы на разных пультах, управление мнемосхемой с одного пульта, наблюдение с другого?

В каком виде вам заказчики дают информацию по системам, сигналам, устройствам? Предусмотрены ли всякие тарировки датчиков? Легко ли будет менять систему, если сначала заказчик говорит «100 сигналов с диапазоном 0 — 10В, норма 5», а потом говорит «100 сигналов с диапазоном 0 — 100 с нормой 20?», а потом говорит, что они вообще из другого блока пойдут?

Кстати снимаю шляпу перед векторными мнемосхемами :-)
Немного не верный подход " с троированием то надежнее система получается", прежде чем разрабатывать любую систему изначально разрабатываются Технические Требования к ней. Исходя из этих требований уже и ТЗ составляется на систему. Для своей системы я не ставил требований по троированию сигналов и узлов, поэтому на текущий момент я могу гарантировать работу своей системы только для АСУ с дублированием на уровне серверных узлов и АРМов оперативного персонала. Что касается дублирования-троирования и выше: каналов связи, датчиков, исполнительных механизмов — тут ничего не мешает выполнять это в логике проекта на базе моей системы. Но сказать, что это будет штатными решениями — не скажу.

Сейчас один из «реальных» проектов на базе моей системы уже месяц работает на объекте, там я сделал АРМы оперативного персонала, заменив штатную скаду, но ее сервера остались на нижнем уровне, я как бы подменил их систему наверху своей, причем графику даже выдержал в стиле старой штатной системы, чтобы оперативный персонал не дергался. В той системе около 2000 точек ввода-вывода, с серверов штатной скады снизу я по сети тяну около 4000 параметров в обе стороны. Вполне быстро работает. Но конкретных показателей на большие количества сигналов вроде 10000 DI не приведу, надо проводить спец. испытания, могу лишь сказать, что в этом проекте обеспечиваю гарантированную динамику на посылку оператором команды вниз и отображением результата ее отработки уже на АРМе в 100мс. Это именно для этого проекта. Там такие требования были. В этому проекте у меня около 30 уникальных мнемосхем, но в АРМе их реализации достигают до 70 вызовов.

Про работу на нескольких пультах — тут несколько некорректно говорить про такой подход в отношении к моей системе, да такое можно делать, но это немного не так выглядит, как описываете вы. Вы, видимо, ориентируетесь на архитектуру вашей скады. Да, можно нарисовать одну мнемосхему как шаблон и делать ее реализацию на неограниченном количестве АРМов (или пультов), где в зависимости от прав текущего авторизованного оператора будет предоставляться или запрещаться доступ на управление, но показ будет доступен всем, если конечно не будет наложен запрет на переход оператора на данную мнемосхему.

Про выдачу информации — вообще в ТЗ прописывается, будет ли оперативным персонал сам менять диапазоны по аналоговым параметрам, и будут ли эти изменения сохраняться в файл сохранения состояния системы при рестарте рантайма(сервера). Если эти параметры жестко задаются в ТЗ через таблицу сигналов, то тут уже вопрос групповой правки базы параметров проекта в среде разработчика при разработке проекта — да у меня есть групповая правка свойств параметров проекта в среде разработки. А вообще на будущее — на все ситуации «сначала заказчик говорит… потом говорит...» — заказчик тыкается носом в ТЗ, которое мы с ним согласовали, иначе эти «хотелки» и «изменялки» приводят к тому, что вы над проектом будете за те же деньги всю жизнь работать. Знаем, плавали. :)
Спасибо за ответы. Все понял, с вами согласен :-) Может какие еще вопросы в голову придут — буду вас мучить. Интересную работу вы проделали!

Желаю вам и вашему проекту успехов! Держите нас в курсе, пишите статьи, с удовольствием буду читать.
Как довесок, можно ли узнать список литературы, которую вы изучили при создании своей системы.
Подозреваю, что это будет ошеломляющий список. Читать, успевать внедрять и программировать — невероятно!
Ой, специально такого списка я не вел, но из особо интересных вещей — буквально настольной стала книжка Эндрю Троелсена «C# и платформа .Net», очень мне его нравится стиль изложения материала.
Еще листал книгу Боба Бошемина «Основы ADO.Net», но не всю целиком, а только интересные для меня моменты.
Кроме того — буквально «жил» на форумах ресурса GotDotNet, MSDN, RSDN, CodeProject.
Например по графике GDI+ не нашел печатных изданий и качал справки от программистов, с примерами и разжевыванием для новичков всех основных моментов. Это в основном было в виде CHM-документации.
Можно сказать, что на 90% всю необходимую информацию я получил именно из Интернет со специализированных ресурсов по программированию.
Всем доброго времени суток. Случайно из Томска никого нет?
Сейчас нахожусь под Томском в рабочей командировке по поводу внедрения крупного проекта на 3000 точек на базе своей скады. Систему успешно запустил и уже на следующей неделе, примерно в середине, планирую 1 день быть в самом Томске. Если кому интересно — можно было бы встретиться очно, побеседовать, заодно мог бы показать и рассказать о системе вживую. :)
Если что — пишите, о месте и времени договоримся.
Приглашаю всех на стенд нашей компании на предстоящей выставке «ПТА-2014», которая состоится с 7 по 9 октября 2014 года в Москве по адресу: ЦВК «Экспоцентр», павильон 5.
На стенде будет демонстрироваться система SCADA+. Можно будет пообщаться с разработчиками и задать свои вопросы, а также попробовать систему в работе.
www.pta-expo.ru/news/020914.htm

Это будет первый выход моей скады на рынок автоматизации как коммерческого продукта и компании, которая будет заниматься ее разработкой, сопровождением и выполнением проектов на ней.
Ура!!! Наконец-то прошли все согласования в ПАО «Газпром» по маркетинговым материалом для презентации системы нашего системного интегратора, который успешно провел в 2015 году испытания и внедрил в эксплуатацию систему линейной телемеханики газопровода на базе моей SCADA+!
Теперь информацию по этому решению, а также отзывы компании о системе SCADA+ можно прочитать на сайте скады в разделе внедрений: система линейной телемеханики «ЭЛТА-ТМ.2»
Sign up to leave a comment.

Articles