Pull to refresh

Comments 61

Огромный респект, я за всю свою жизнь не написал столько кода (работающего в продакшене, конечно).
Вот подстава то. И ведь догадывался же, что тема обширна. Аж браузер завис.
А автору респект
Вы — настоящий профессионал. Теперь есть к чему стремится :)
Автору респект, в одиночку не побояться начать и главное довести до какого-то логического момента такой обширный проект.
Судя по всему вы проделали огромный труд, респект. Тоже заканчивал институт по этой специальности и даже поработал на производстве. Правда, со скада системами работал в основном на прикладном уровне. OPC, да разного рода мелкие утилиты. Как у вас обстоит дело с поддержкой стандартов OPC? Помню, неистово бесило, что каждая скада система реализовывала его не до конца. 3.0 то держит? XML DA? Сама скада может выступать в качестве OPC сервера?
С ОРС все не просто, сама OPC-foundation в этом плане очень серьезно следит за тем, чтобы за любой чих разработчик отстегивал им немалые деньги. Я много искал нормальные обертки под ОРС, потому как платить ассоциации (если не ошибаюсь около 1500 евро) за членство и доступ к материалам я сейчас не могу. Нашел два более-менее подходящих варианта: один бесплатный (писали энтузиасты и выложили результаты в свободный доступ, дальше сами дорабатывайте), платный — от GrayBox. Первый сразу встроил, там есть поддержка клиента и вроде даже сервера по OPC DA 2.0, но серверную часть я пока еще не осилю — сложновато. Грейбоксовский сейчас вот ковыряю по части клиента (хотя и серверные интерфейсы там тоже есть), в нем есть: DA, HDA, AE, и все это же также по XML, но все в коммерческой версии за денежку. Для текущих проектов, где в основном мониторинг и частичное управление через ОРС пока хватает.
Если язык реализации не принципиален — взгляните на code.google.com/p/libopcd/
Я в свое время на основе этой библиотеки делал OPC-шлюз, который выступал одновременно в роли OPC сервера и OPC клиента. Был источником данных для scada систем, брал данные из хозучета и другой скада системы по OPC, делал расчеты и суммарную инфу складывал уже в общезаводскую систему хозучета.
Серверная часть там сделана на очень хорошем уровне. Чтение тегов же я тестировал на тестовом сервере от dOPC — имхо, лучший тестовый стенд для проверки на совместимость стандартам (испробовал штук 20, все фигня).

Вот с документацией да, очень туго. Найти в сети практически нереально, если не платить консорциуму за членство. Я нарыл только спеки на 3 DA и частично на 2 версию, а потом все методом тыка
Спасибо за ссылки, но язык принципиален, я пишу на C#, поэтому нужны обертки с поддержкой managed кода. Материалы по dOPC я уже проходил — брал кое-что для тестов и ознакомления, также у них даже есть обертка для .Net, но вот скачать ее они не дают.
Ну как минимум взгляните на код. Довольно добротный, не думаю что возникнут сложности с портированием в шарп.
Интересная статья, спасибо!
У меня давно было мнение, что если начать писать СКАДу с нуля на основе современных технологий, получится удобная и красивая вещь, в отличии от грузных стандартных систем (WinCC,TraceMode и т.д.) вынужденных из-за совместимости тащить за собой ворох старых технологий и алгоритмов.

По статья — особый интерес вызывает вопрос связи с нижнем уровнем — ждем продолжения!
На фразе «а зачем нам кузнец?» подумал что речь пойдёт о том, что было принято решение не работать в штате, а предлагать профессиональные услуги заказчикам (включая бывших работодателей) от себя лично. Но так тоже ничего получилось 8)
Такой вопрос. Вы написали, что делали систему в «свободное от работы время». Ваши успехи по основному месту работы настолько же значительны? Или акцент сместился на эту разработку?

P.S.
Спрашиваю, чтобы больше узнать о пределах человеческих возможностей.
Ну, если изменение должности с «ведущего инженера АСУТП» на должность «руководитель отдела прикладного ПО» можно отнести к такому успеху, то да. За время разработки по основной работе часть своих наработок я внедрил непосредственно в наше производство. Например, последние все наши проекты по фирме выполняются полностью с использованием моей подсистемы архивации в СУБД совместно с брендовой СКАДой. Помимо этого сделал отдельное решение по моделированию объектов управления, которое сейчас потихоньку внедряем на своем полигоне, через который прогоняются все наши проекты и на котором проводим их заводские испытания. Кстати, это решение у меня как раз в математический аппарат заложено в скаде. Параллельно с этим я лично веду 2 проекта АСУТП для АСУ Энергоснабжения газоперекачивающих станций (достаточно крупные — каждый по 2000-3000 точек ввода/вывода), один из них в конце этого года выходит на МВИ (межведомственные испытания), чтобы быть принятым как рекомендуемое решение в отрасли. Плюс к этому эти же проекты сам делаю еще и в своей системе (некоторые скриншоты в статье и даже видеоролики сделаны на этих проектах), чтобы к осени на заводских испытаниях одну из них показать не только в штатном исполнении на брендовой СКАДе, но и на базе своей разработки, для наглядности. А весной вообще было весело — намечалась покупка жилья, так что пришлось параллельно совмещать три работы: утром до основной делал АСДУ одного бизнес-центра, потом мчался на основную, а вечером после основной — на другой объект. После уже дома часиков до 2-3 ночи копался в своей системе. Помнится, после двух месяцев такого режима, вымотан был капитально, пришлось неделю отпуска брать. И первые двое суток я спал вообще не просыпаясь… Долго так сложно выдержать, поэтому — по личному опыту могу сказать, что возможности большие, но не безграничные.
Ваш проект показывает насколько велика разница между наемным работником и созидателем, заинтересованным в своем проекте.

Просто прикиньте (хотя бы с точностью до порядка) во сколько бы обошлась разработка подобного проекта силой наемных работников? Для грубой оценки берут величину 100 строк отлаженного кода в день. Тогда ваш проект среднему наемному работнику нажно было бы делать 10 лет, а бюджет был бы (для России) минимум 200 тыс. у.е. Но т.к. 10 лет — слишком долго, нужно распараллелить между многими работниками, а с увеличением людей повышаются затраты. Тогда бюджет на создание будет близок к 1 млн.

Мне очень интересно что дальше будет с проектом. Сможете ли вы довести его до должного уровня и стать миллионером :) Кстати, не предлагали вам еще продать его?
Сейчас ведется разработка сайта, через который я планирую начать распространять свое решение уже в массы. Там будет форум, информация по продукту, а также онлайн справочная система + онлайн курсы по работе в ней. Последнее уже начал делать на базе движка Википедии, очень удобно получается.
Насчет продажи — пока никто не предлагал продать, но тут пока еще мало кто вообще знает о том, что я делал. Сейчас вот после Хабра будет побольше уже. Однако в период информационного освещения своего детища через АСУТПшные форумы я уже успел стать официальным конкурентом для одного из производителей отечественного бренда. Руководство фирмы разработчика СКАДы, увидев мое решение, официально возвело меня в ранг конкурента после моего отказа прекратить разработки, а сотрудничать с ними и работать ТОЛЬКО на их решении…
возможно читал невнимательно, сколько по времени заняла разработка?
Мне тоже было удивительно. Чуть больше года с пивом (в свободное от работы время). Примерно по 900 строк в день.
круто, желаю вам иметь процент от каждого внедрения ;)
Только это не мне, а автору :)

Вот вам реальный пример силы энтузиазма — чел наваял за год с пивом столько, сколько средний наемный программер будет делать 10 лет. Когда спросишь у автора как так получилось — он и сам не знает, сам удивляется.
Сделай под Linux, QNX или под то, что тебе нравится.
UFO just landed and posted this here
UFO just landed and posted this here
Люблю задавать каверзные вопросы.
А как вы добились фиксированного времени цикла и вообще реального времени в ядре контроллера?
Поддерживаете многопоточность?
Как реализовали обработку исключений? Что будет, например, при делении на ноль в рантайме?
Поддерживаете диапазоны, уставки?
Как реализуется обработка отказа датчиков, АЦП, ДЦП и другой периферии?
Не совсем понятно, графическое ядро работает в одном процессе с вычислительным? Т.е. если сделать программу для контроллера, то как для неё увидеть мнемосхему? По какому паттерну реализовано (если реализовано) получение процессом, отображающим мнемосхему, оперативных данных от контроллера — постоянный опрос, или уведомление об изменениях со стороны контроллера?
Реализована ли пошаговая отладка кода технологической программы? Или только на уровне доступных вычисленных значений?
Реализована ли буферизация событий на случай временного отказа архива или сети? Будут ли события, произошедшие на время отсутствия связи с архивом, потеряны на всегда?
Как реализован механизм квитирования (подтверждения получения и обработки) команд (нажатий на кнопки, ввод значений) от мнемосхемы к контроллеру?
Поддерживается ли дублирование и кластеризация контроллеров?
Поддерживается ли дублирование сети?
Ну и самый каверзный :) А есть UNDO/REDO?

Это только мелочь, которая первым делом пришла на ум. В действительности объём таких мелких каверзных вопросов при разработке САПР АСУ ТП — просто огромен, и решения некоторых вопросов наслаиваются друг на друга, увеличивая сложность их одновременного решения до астрономических величин. Это я к тому, что миллион долларов на разработку качественного САПР АСУ ТП — не так уж и много.

Однако, хочу выразить уважение, по поводу объёма проделанной работы. Впечатляет.

Самому мне эта тема очень близка, я уже лет 5 работаю разработчиком как раз таки САПР УСУ ТП, пишу векторный графический редактор визуального языка программирования для микроконтроллеров, на подобии FBD.
Пойдем последовательно и в ответах и в разработке:
1) Фиксированное время цикла определяется разработчиком проекта для конкретного узла проекта (АРМа или контроллера), однако реальное время, которое затрачивается на пересчет всей математики, что он навертел внутри этого узла, может и не хватить, тогда цикл реального пересчета будет превышать установленный. Таким образом разработчик при отладке должен учитывать, что в случае превышения установленного цикла реальным ему придется установленный цикл повышать до размеров реального — ведь сказать системе работать быстрее невозможно. Это все легко диагностируется на этапе отладки системы. Все ресурсоемкие процессы, такие как: архивация, журналирование событий, работа с дампом, внутренние архивы в памяти, сброс их в файлы, обмен по внешним интерфейсам — это все отдельные потоки, работа которых идет параллельно основному процессу пересчета базы и математики узла. Технология одинакова как для контроллеров, так и для АРМов операторов.
2) Как я уже говорил — в системе я реализовал собственный вычислительный движок, который не работает с понятиями типа данных, для него любой тип — это в первую очередь «объект», и приведение его к нужному типу выполняется в зависимости от реализуемой функции или контекста использования. Поэтому в моей системе делить на ноль можно вообще без возникновения исключительных ситуаций — получите бесконечность как результат, хотите контролировать тип, делайте это в логике алгоритма. Хотя сам движок не мешает сделать это внутри него штатно. Тут практика уже покажет — как будет удобнее, так и доработаю.
3) Диапазоны и уставки — не совсем понятно при чем тут скада как таковая — это вопросы реализации конечных проектов АСУТП на ее базе, ведь это переменные техпроцесса. По аналоговым переменным у меня есть диапазоны границ сигнала и контроль достоверности и номера интервала, где он сейчас находится.
4) Опять таки вопрос не к скаде, не ее задача контролировать отказы датчиков и АЦП, ДЦП — это должно реализовываться на другом уровне. В системе по переменным есть признак Достоверности (аппаратная, программная, достоверность типа), их можно менять программно, из драйвера устройства, или вручную с операторской мнемосхемы.
5) Да, на текущий момент графическое ядро работает в одном процессе с вычислительным, вернее сказать они последовательно выполняются в процессе пересчета базы и математики. Однако я уже сейчас продумываю как их разделить по разным потокам, чтобы не грузить основной вычислительный процесс ядра графикой.
Относительно вопроса про контроллер и мнемосхему для него — вы несколько некорректно понимаете архитектуру моей системы, у меня подобное решается так: в проекте создается два узла (контроллер и АРМ), в каждом своя база переменных, алгоритмов, а между их переменными уже устанавливаются связи через сеть или последовательный интерфейс. Таким образом получается проект из двух узлов: контроллер, который работает внизу и АРМ наверху. Графика мнемосхем делается как раз в АРМе, а данные для нее он по сети или последовательному каналу из контроллера уже поднимает.
6) Пошаговая отладка с выводом всех внутренних переменных есть только для визуального языка FBD. Для С# этого нет, там процесс выполнения по шагам только на уровне выполнения логики алгоритма на 1 такт с выводом всех входных и выходных его аргументов. Внутренние как в профф. студиях программирования типа окна Watch я не могу сделать… пока не могу…
7) Все процессы по архивации в СУБД у меня буферизированы. Более того — в случае, если буфер не удается сбросить в СУБД, а рантайм тормозят — он может скинуть его в файл, и подчитать при рестарте. Так что данные потерять совсем можно только жестко обрубив питание.
8) Про механизм квитирования от мнемосхемы к контроллеру — снова немного некорректная постановка вопроса относительно архитектуры моей скады. Сделаем проще — приведите описание задачи, которую надо решить, а я объясню как она решается у меня.
9) Дублирование с поддержкой горячего резервирования я пока только планирую, на данный момент пока ничего этого нет. А вот насчет кластеризации — немного не понял суть, вы имеете ввиду функцию распределения вычислительной нагрузки по алгоритмам в проекте из одного узла на несколько, если один не справляется?
10) Дублирование сети — как уже сказал, что подсистему сетевого обмена я пока только еще делаю, так что тут пока рано говорить об этом. Однако вопрос резервирования для скады — это серьезный и многоуровневый вопрос, так что его проработка относительно сети также меня ожидает.

Если не секрет, как называется САПР, в разработке которого вы принимаете участие?
1)Ну то что время цикла фиксируется, это понятно. Мне была интересна поддержка реального времени в ядре контроллера. Под этим я понимаю гарантию того, что время выполнения цикла управляющего кода будет зависеть только от самого кода, а так же то, что управляющие сигналы будут посланы на арматуру так же за гарантированное время. На сколько я понимаю, WinCE ядро работает под .NET Compact Framework? Т.е. например, управляющий поток может быть в любой момент остановлен сборщиком мусора на неопределенный промежуток времени. Может произойти прерывание. Наконец, управляющий поток может быть просто вытеснен, если, конечно, для него не задан приоритет реального времени. К тому же, свой отпечаток накладывают подсистемы ввода вывода — стек TCP/IP, реализации прикладных протоколов. Если кем-то используется неуправляемый менеджер памяти, то опять же время на выделение памяти становится непредсказуемым из-за фрагментации. А ведь еще сам CPU очень сложное устройство — микрокод, конвейеры, кеши, контроллер памяти. (Помнится, в блоге Intel на эту тему была отличная статья.) Т.е. время цикла в системе без поддержки реального времени становится прыгающим в неопределенные моменты времени на неопределенную величину.
Иными словами, гарантировать реальное время выполнения — труд просто титанический. Для этого как раз и придумывают множество аппаратных реализаций протоколов ввода вывода — чипы ProfiBus, ModBus, CANOpen и т.д. и т.п.

2) Т.е. если целый 0 разделить на целый 0, то получим NaN с плавающей точкой?
Ну деление на ноль, это ладно, можно обойти. А что если обратиться к массиву по неверном индексу? Если вызвать метод по нулевой ссылке? Как-то исключения обрабатываться должны? Или в таком случае ядро будет аварийно завершено? :)

3, 4) Ну у меня как раз вопрос заключался в том, поддерживается ли достоверность, или нет. Понял, поддерживается. У нас это называется качество сигнала.

5) Ну для мелких АСУ такой подход еще туда-сюда — но для больших… Это ж надо во первых создать программу для контроллеров, во вторых — создать программу для операторских станций, в третьих нужно в ручную организовать передачу данных от контроллеров к операторским. Получается двойная работа. А когда счет сигналам идет на десятки тысяч…

7) Защита от потери данных при прекращении питания или перезапуске штука полезная, называется безударный перезапуск. А что будет при потере питания со всевозможными интегрирующими алгоритмами, ПИД-регуляторами, которые накапливают данные и на основе интеграции формируют управляющее воздействие? Если потерять накопленные данные, то при запуске контроллера «с нуля» могут быть сформированы очень сильные управляющие воздействия, способные повредить арматуру.

8) Допустим есть двигатель, который можно включить или выключить. И нужно сделать мнемосхему с двумя кнопками — вкл. и выкл. для этого двигателя. Как это будет реализовано? В программе будет алгоритм с одним логическим входом? С одним входом другого типа? С несколькими входами? Или у вас поддерживаются FBD-шные логические триггеры по IEC 1131-3?

9) Дублирование, это когда из нескольких контроллеров, объединенных в группу, один управляет, а остальные ничего не делают, находятся в резерве и, при выходе текущего управляющего контроллера из строя, управление на себя берет резервный. А при кластеризации группа из 3-х и более контроллеров одновременно принимает данные, считает, и посылает управляющее воздействие. А на выходе стоит стоит специальное устройство — арбитр — которое сравнивает все управляющие воздействия, и, если вдруг значения расходятся, то по принципу мажорирования выбирает верное по его мнению значение, а разошедшийся контроллер считает «паршивой овцой». Кластеры активно используются в АСУ где любая ошибка недопустима, например, на АЭС, или при управлении газовыми турбинами.

10) Да, нормально сделать резервирование — задача не слабая.

САПР называется КВИНТ.
1) Все верно — поэтому у себя оговариваюсь, что у меня не строго реальное время выполнения, а квази-реальное. Настолько детально прорабатывать ядро, я к сожалению не могу (и пока не умею), поэтому не позиционирую свою систему как систему для очень быстрых процессов с жесткими требованиями по времени реакции и выполнения логики и процедур ввода/вывода. Для большинства процессов ее получается достаточно.
2) Да, получим NaN. Относительно исключительны ситуаций — тут штатные методы try-catch позволяют достаточно четко обрабатывать их без выноса основного процесса в даун. Все результаты обработки выводятся оператору в текстовом виде в специальные комментарии, то есть всегда можно грамотно разобраться, а в чем собственно возникла проблема и почему. Кстати, у меня по этому механизму внутри выислителя 3-й тип Достоверности по переменным выставляется в работающей системе (достоверность типа данных).
5) Вот тут снова немного недопонимание архитектуры — весь проект представляет собой единое адресное пространство, не надо дублировать данные из одного узла (например контроллера) в другом (например АРМе) — если для алгоритма АРМа требуется значение датчика температуры из контролла №n, то берете и линкуете его в проекте напрямую как переменную из узла контроллера в алгоритм узла АРМа, система сама выполнит привязки и последующую обработку обмена этими данными между этими узлами по выбранному интерфейсу при работе в рантайме. Задумано все именно так.
7) Мой файл сохранения состояния ведется не только по свойствам переменных базы узла, но и по внутренним переменным алгоритмов. поэтому алгоритмы с внутренними счетчиками или состояниями (например ПИД, или триггер) при рестарте продолжают работу с того места, где их остановили, то есть — процесс работает безударно.
8) Самая простейшая реализация: создаем 1 канал (переменную), связанную с точкой ввода/вывода УСО, через которое идет управление двигателем (1 — включить, 0 — выключить). Переменная типа Output. Создаем экран, где размещаем две кнопки: одна выполняет прямую посылку значения 1 в выходной аргумент экрана, другая — 0. Аргумент экрана выходной и привязывается к каналу (переменной) управления двигателем через УСО. Вот и все. Если необходимо фиксировать команду посредством триггера, то в промежуток между экраном и каналом управления через УСО вставляется алгоритм на FBD, где стоит RS или SR-триггер по стандарту IEC 1131-3 (у меня свыше 120 блоков штатно в FBD по разному функционалу). Только в этом случае на экране будет уже два аргумента, а обе кнопки будут посылать 1, каждая в свой аргумент, со сбросом при отжатии. Это и будут команды на вход триггера для SET и RESET входов.
9) Да, как уже сказал, все это еще только мне предстоит. Сейчас по текущим проектам пока требуется горячее резервирование как внизу, так и наверху. Кластеризацию обычно делал на уровне алгоритмов, когда КИП троированный был, на уровне узлов пока еще не приходилось таких задач решать.

КВИНТ — знаю, вернее много слышал, и знаком с людьми, которые на ней очень плотно работали. Например, когда в Ираке Нассирийскую ТЭС пускали, оооочень много наслушался сравнительных характеристик от инженеров ОРГРЭСа (был там такой — Бородкин) относительно КВИНТа и ТМа. :)
Очень интересно, какие характеристики вы слышали :) Но в любом случае, это были характеристики 5й или 6й версии, я тогда в НИИТеплоприборе еще не работал :) Вот 7я будет значительно лучше.
Да там даже в основном не конкретные характеристики были, а больше эмоциональное сравнение. Ну — сами понимаете, серьезный объект, большой проект, любой огрех или проблема вызывают кучу негатива и попыток поддернуть «а вот в наше время...».
Относительно UNDO/REDO — действительно каверзный, потому как в моей системе такого вообще нет. Пытался делать, но изначально не хватило мозгов чтобы понять как это вообще делается в ПО, потом уже малость поздно получилось. Но и еще один фактор был сдерживающим — в СКАДе, в которой работал(ю) Undo/Redo — является самым конкретным рассадником багов, из-за этого механизма часты свалы системы. Хотя, периодически начал ловить себя на мысли, что не имея данного механизма в своей среде разработки я стал более детально продумывать свои действия как разработчик, и сейчас все реже и реже даже думаю о том, что сейчас бы UNDO не помешал…
Ну вообще говоря это означает, что к той системе undo прикручивался по ходу дела (и возможно, поэтому вы тоже пришли к мысли, что этого делать не стоит). Если бы действия в программе изначально были транзакционными, то undo-redo механизм работал бы как часы.
У Undo есть неприятная особенность, что если его не сделать сразу, то потом его доработка становится задачей практически перекапывания всего исходного кода приложения. У меня ушло приличное количество времени и экспериментов, что бы подобрать оптимальный паттерн реализации. У меня всё запущено, есть СУБД, есть ORM, который за одно является VM в паттерне M-V-VM (Model-View-ViewModel) :) Ну а в качестве Model выступают классы таблиц СУБД. View сделан на WPF.
Поясните пожалуйста, у вас SCADA включает в себя и контролер, своего рода софтверная эмуляция апаратного контроллера, так?
Нет, не совсем так. Архитектура проекта представляет собой два типа узлов: АРМ оператора и контроллер. Под контроллером в моем случае понимается узел РС-совместимого устройства, в котором установлена ОС Win из линейки: WinCE, XP embedded, или вообще чистая Win, где может запускаться мой рантайм для узлов контроллеров, в котором грузится и обрабатывается этот компонент проекта. С точки зрения архитектуры такой узел практически ничем не отличается от АРМа, тоже есть база переменных, алгоритмы, связи между ними, связь с УСО и разного рода внешним оборудованием (включая также узлы самого проекта), только в нем нет графики… Нуу — пока нет. Просто отладчик проекта внутри среды разработчика умеет обрабатывать (пересчитывать) весь проект как единое пространство компонентов, вообще не делая упора на то, что одни узлы — это АРМы, а другие — это контроллеры. Просто в этом нет необходимости. Зато получается возможность отладки единого многоузлового проекта на одном ПК разработчика прямо в среде разработки, с отслеживанием всех каналов движения данных внутри логической структуры проекта, с одновременными возможностями редактирования компонентов графики и алгоритмов без останова выполнения, что называется — в реальном времени. При запуске проекта на объекте — конечно каждый узел проекта уже запускается каждый в своем устройстве под индивидуальным рантаймом.
Спасибо за развернутый ответ. Т.е. ваш проект представляет собой комплексное решение SCADA+ПЛК, тогда возможно ли использование (или планируется) вашей SCADA именно как HMI приложения с существующим контроллером Siemens (допустим, не люблю я WinCC) или Schneider (не люблю Citect :) ) или любого другого крупного производителя?
Совершенно точно, комплексное решение SCADA+ПЛК(Softlogic). Как решение HMI+ПЛК с закрытой архитектурой (именно ПЛК в чистом понимании) можно использовать через подключение устройства по стандартному протоколу или интерфейсу. Например, для Siemens — это через ОРС сервер (их Профибасы — ужасно закрытые стандарты с лицензиями в тридорого, а решения через API среды Step7 — не тривиальное решение, которое так и не заработало, был косвенный опыт), для Schneider — это ModBus RTU или TCP. Вообще, поддержка в моей системе того же протокола ModBus в качестве Slave-режима дает возможность использовать наоборот — мою скаду как средство программирования Софт-ПЛК, а на верхнем уровне любую HMI из существующих. В общем, хотите — только верх, а хотите — только низ, или и все вместе, тут уже разработчик проекта решает…
Скажите, а при реальном создании вы пользуетесь методологиями IDEF? А то нас учат этому как раз при создании АСУ ТП.
Нет, это из области АСУП — управление производством, а не технологическим процессом (АСУТП).
Вы молодец, а я оказывается унылое говно.
Почто так самокритично-то?
Вы скаду на 300к строк написали, а я ничего не написал. Тоже инженер асутп.
А вдруг Вы в ней проект на 300к точек ввода/вывода сделаете? ;)
В моей жизни пока было 2 проекта: на 5000 тегов и на 500 тегов. Первый внедрили уже без меня на севере, на втором работаю до сих пор.
Имхо, главное не 300к строк, а то, что потом это будет работать и внедрено на производстве.
Программист В. Антонов написал много хорошего ПО под необычные роутеры (Pluris), но продажи железок почему-то не пошли и труд получился впустую.
Ещё бы избавится от C# в пользу C++ и была бы вообще замечательная система, быстрая, маленькая, способная запускаться на встроенных контроллерах, например, ICP DAS (там MiniOS 7 т.е. MS DOS) и под QNX. А так неудачный выбор инструментария разработки похоронил проект, никто в трезвом рассудке не станет гонять прокатный стан на Microsoft .Net.
Прокатный стан не будет, но SCADA к стану я бы погонял)
UFO just landed and posted this here
Очень впечатляет, огромное уважение автору.

И пара вопросов:
Есть ли планы по распространению или продаже вашей скады?
на основе каких лицензий?
а то очень хотелось бы потрогать посмотреть?

также работал и работаю с разными скадами, и ни одна из них не является идеалом удовлетворяющим все потребности ;(
В одной это криво реализовано, в другой свои грабли… и как уже правильно отметил Fortums — это действительно голубая мечта каждого разработчика, написать своё и «как надо делать скады правильно».
Тут для себя решил так — инструментальная система (среда разработки + полнофункциональный рантайм с ограничением по времени непрерывной работы) будут совершенно бесплатные. Бери и разрабатывай, запускай, отлаживай без каких-либо функциональных ограничений. Платными будут только сами рантаймы, и то думаю, что цена будет чисто символической, я понимаю, что мой продукт не именитый бренд, и я пока не в силах в одиночку обеспечить ему то качество, которое могут обеспечить крупные компании (хотя, зачастую последние и приемлемого уровня обеспечить не могут).
Насчет политики форматов проекта (например как у того же ТМ) — опять же не будет делений на Демо и Проф варианты, потому как сам файл проекта в моей системе в чистом XML (для особо интересующихся программистов, с целью сопряжения с другими системами я могу этот формат даже описать).
Ну и останется только коммерческая составляющая СУБД для архивов — если для личного пользования брать, то у MySQL вроде лицензия бесплатная на это (сам так сейчас разработку веду), но для коммерческого применения — уже потребуется приобретение лицензий, однако это уже вопрос не ко мне, этот вопрос должен будет уже конечный пользователь моей скады решать.

Лицензия для рантаймов планируется на количество переменных (параметров на 1 узел), сюда просто будут считаться все каналы (тэги), которые сделаны в проекте на этот узел (как внутренние, так и связанные с внешними параметрами и оборудованием).

В общем вкратце суть политики лицензирования такая: берешь инструмент, делаешь проект, если все получается и он удовлетворяет всем требованиям, то конечный результат запускаешь уже под рантаймами за денежку.

Ну а по поводу посмотреть. Стучите мне на почту, обсудим. Система бесплатна, поэтому если не пугает:
1) То, что в ней есть ошибки и у меня сейчас нет релизов, прошедших капитальное тестирование
2) Справочная система пока в процессе разработки, однако так как она на базе движка Википедии — она доступна всегда онлайн и всегда актуальная. В принципе в дальнейшем планирую, что доверенные пользователи сами смогу наполнять ее в процессе своей работы недостающей информацией или своими наработками.

Контакт почтового адреса можно найти на моем сайте (по тексту статьи ссылки на материалы идут как раз с моего сайта).

У меня тут один пользователь взял систему пощупать и пропал на неделю, ни слуху, ни духу. Пишу ему с вопросом, что и как, как дела, какие результаты, а он оказывается уже потихоньку свой реальный проект делает в моей системе и она даже показывает стабильную работу (у него железо по ОРС подключается). Вот так глядишь, еще и быстрее меня проект в ней сделают. :)
Да, на счет качества трудно не согласится. Особенно в этом плане сдал Siemens со своей SPPA T3000. Step7 штука проверенная временем, это да. Но ПО верхнего уровня реализовано ИМХО отвратно.
Уважение автору, за энтузиазм
Вопрос к автору.

Могли бы вы для статистики привести размер исходного кода в байтах. Только файлы cs, исключая ресурсы и файлы данных? Спасибо.
Если только файлы cs, то статистика на данный момент такова:
Инструменталка — объем 9,082Мб
Рантайм для Windows — объем 3,784Мб
Рантайм для WinCE — объем 2,145Мб
Всем доброго времени суток. Случайно из Томска никого нет?
Сейчас нахожусь под Томском в рабочей командировке по поводу внедрения крупного проекта на 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