Мне как-то принесли систему для GE Fanuc — очень нахваливали, рекомендовали посмотреть и поучиться. Честно — не понравилось вообще никак, мало того что гигабайтами ставились непонятные модули, так они мне еще и ОС повредили своими сервисами так, что еле вычистил ПК после него…
Не спорю — я не могу видеть абсолютно все решения, но большинство scada-систем, что удалось посмотреть и поговорить с представителями дистрибьюторов не дают такого сервиса. В большинстве случаев самый максимальный бонус: надо в среде разработки привести масштабы к нужным, и только потом запускать под рантаймами. Но — мне проще показать как это работает в режиме реального времени в моем рантайме, нежели писать сотни слов: youtu.be/KvWrDK4Chm0
Являюсь разработчиком собственной СКАДА-системы.
Готов принять участие в поддержке этого стандарта в своей СКАДА-системе! Где качать библиотеки, примеры и тестовые имитаторы для проверок? :)
Кстати, сам я в своей Скаде использую OPCDOTNET, отлично работает, вот только с локальными ОРС, удаленные не поддерживаются.
Еще работал с библиотеками от GreyBox — даже без справки можно разобраться, можно найти полнофункциональные без ограничений работы. В них можно и с удаленными ОРС работать.
Если только файлы cs, то статистика на данный момент такова:
Инструменталка — объем 9,082Мб
Рантайм для Windows — объем 3,784Мб
Рантайм для WinCE — объем 2,145Мб
Да там даже в основном не конкретные характеристики были, а больше эмоциональное сравнение. Ну — сами понимаете, серьезный объект, большой проект, любой огрех или проблема вызывают кучу негатива и попыток поддернуть «а вот в наше время...».
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) Да, как уже сказал, все это еще только мне предстоит. Сейчас по текущим проектам пока требуется горячее резервирование как внизу, так и наверху. Кластеризацию обычно делал на уровне алгоритмов, когда КИП троированный был, на уровне узлов пока еще не приходилось таких задач решать.
КВИНТ — знаю, вернее много слышал, и знаком с людьми, которые на ней очень плотно работали. Например, когда в Ираке Нассирийскую ТЭС пускали, оооочень много наслушался сравнительных характеристик от инженеров ОРГРЭСа (был там такой — Бородкин) относительно КВИНТа и ТМа. :)
Тут для себя решил так — инструментальная система (среда разработки + полнофункциональный рантайм с ограничением по времени непрерывной работы) будут совершенно бесплатные. Бери и разрабатывай, запускай, отлаживай без каких-либо функциональных ограничений. Платными будут только сами рантаймы, и то думаю, что цена будет чисто символической, я понимаю, что мой продукт не именитый бренд, и я пока не в силах в одиночку обеспечить ему то качество, которое могут обеспечить крупные компании (хотя, зачастую последние и приемлемого уровня обеспечить не могут).
Насчет политики форматов проекта (например как у того же ТМ) — опять же не будет делений на Демо и Проф варианты, потому как сам файл проекта в моей системе в чистом XML (для особо интересующихся программистов, с целью сопряжения с другими системами я могу этот формат даже описать).
Ну и останется только коммерческая составляющая СУБД для архивов — если для личного пользования брать, то у MySQL вроде лицензия бесплатная на это (сам так сейчас разработку веду), но для коммерческого применения — уже потребуется приобретение лицензий, однако это уже вопрос не ко мне, этот вопрос должен будет уже конечный пользователь моей скады решать.
Лицензия для рантаймов планируется на количество переменных (параметров на 1 узел), сюда просто будут считаться все каналы (тэги), которые сделаны в проекте на этот узел (как внутренние, так и связанные с внешними параметрами и оборудованием).
В общем вкратце суть политики лицензирования такая: берешь инструмент, делаешь проект, если все получается и он удовлетворяет всем требованиям, то конечный результат запускаешь уже под рантаймами за денежку.
Ну а по поводу посмотреть. Стучите мне на почту, обсудим. Система бесплатна, поэтому если не пугает:
1) То, что в ней есть ошибки и у меня сейчас нет релизов, прошедших капитальное тестирование
2) Справочная система пока в процессе разработки, однако так как она на базе движка Википедии — она доступна всегда онлайн и всегда актуальная. В принципе в дальнейшем планирую, что доверенные пользователи сами смогу наполнять ее в процессе своей работы недостающей информацией или своими наработками.
Контакт почтового адреса можно найти на моем сайте (по тексту статьи ссылки на материалы идут как раз с моего сайта).
У меня тут один пользователь взял систему пощупать и пропал на неделю, ни слуху, ни духу. Пишу ему с вопросом, что и как, как дела, какие результаты, а он оказывается уже потихоньку свой реальный проект делает в моей системе и она даже показывает стабильную работу (у него железо по ОРС подключается). Вот так глядишь, еще и быстрее меня проект в ней сделают. :)
Совершенно точно, комплексное решение SCADA+ПЛК(Softlogic). Как решение HMI+ПЛК с закрытой архитектурой (именно ПЛК в чистом понимании) можно использовать через подключение устройства по стандартному протоколу или интерфейсу. Например, для Siemens — это через ОРС сервер (их Профибасы — ужасно закрытые стандарты с лицензиями в тридорого, а решения через API среды Step7 — не тривиальное решение, которое так и не заработало, был косвенный опыт), для Schneider — это ModBus RTU или TCP. Вообще, поддержка в моей системе того же протокола ModBus в качестве Slave-режима дает возможность использовать наоборот — мою скаду как средство программирования Софт-ПЛК, а на верхнем уровне любую HMI из существующих. В общем, хотите — только верх, а хотите — только низ, или и все вместе, тут уже разработчик проекта решает…
Нет, не совсем так. Архитектура проекта представляет собой два типа узлов: АРМ оператора и контроллер. Под контроллером в моем случае понимается узел РС-совместимого устройства, в котором установлена ОС Win из линейки: WinCE, XP embedded, или вообще чистая Win, где может запускаться мой рантайм для узлов контроллеров, в котором грузится и обрабатывается этот компонент проекта. С точки зрения архитектуры такой узел практически ничем не отличается от АРМа, тоже есть база переменных, алгоритмы, связи между ними, связь с УСО и разного рода внешним оборудованием (включая также узлы самого проекта), только в нем нет графики… Нуу — пока нет. Просто отладчик проекта внутри среды разработчика умеет обрабатывать (пересчитывать) весь проект как единое пространство компонентов, вообще не делая упора на то, что одни узлы — это АРМы, а другие — это контроллеры. Просто в этом нет необходимости. Зато получается возможность отладки единого многоузлового проекта на одном ПК разработчика прямо в среде разработки, с отслеживанием всех каналов движения данных внутри логической структуры проекта, с одновременными возможностями редактирования компонентов графики и алгоритмов без останова выполнения, что называется — в реальном времени. При запуске проекта на объекте — конечно каждый узел проекта уже запускается каждый в своем устройстве под индивидуальным рантаймом.
Относительно UNDO/REDO — действительно каверзный, потому как в моей системе такого вообще нет. Пытался делать, но изначально не хватило мозгов чтобы понять как это вообще делается в ПО, потом уже малость поздно получилось. Но и еще один фактор был сдерживающим — в СКАДе, в которой работал(ю) Undo/Redo — является самым конкретным рассадником багов, из-за этого механизма часты свалы системы. Хотя, периодически начал ловить себя на мысли, что не имея данного механизма в своей среде разработки я стал более детально продумывать свои действия как разработчик, и сейчас все реже и реже даже думаю о том, что сейчас бы UNDO не помешал…
Пойдем последовательно и в ответах и в разработке:
1) Фиксированное время цикла определяется разработчиком проекта для конкретного узла проекта (АРМа или контроллера), однако реальное время, которое затрачивается на пересчет всей математики, что он навертел внутри этого узла, может и не хватить, тогда цикл реального пересчета будет превышать установленный. Таким образом разработчик при отладке должен учитывать, что в случае превышения установленного цикла реальным ему придется установленный цикл повышать до размеров реального — ведь сказать системе работать быстрее невозможно. Это все легко диагностируется на этапе отладки системы. Все ресурсоемкие процессы, такие как: архивация, журналирование событий, работа с дампом, внутренние архивы в памяти, сброс их в файлы, обмен по внешним интерфейсам — это все отдельные потоки, работа которых идет параллельно основному процессу пересчета базы и математики узла. Технология одинакова как для контроллеров, так и для АРМов операторов.
2) Как я уже говорил — в системе я реализовал собственный вычислительный движок, который не работает с понятиями типа данных, для него любой тип — это в первую очередь «объект», и приведение его к нужному типу выполняется в зависимости от реализуемой функции или контекста использования. Поэтому в моей системе делить на ноль можно вообще без возникновения исключительных ситуаций — получите бесконечность как результат, хотите контролировать тип, делайте это в логике алгоритма. Хотя сам движок не мешает сделать это внутри него штатно. Тут практика уже покажет — как будет удобнее, так и доработаю.
3) Диапазоны и уставки — не совсем понятно при чем тут скада как таковая — это вопросы реализации конечных проектов АСУТП на ее базе, ведь это переменные техпроцесса. По аналоговым переменным у меня есть диапазоны границ сигнала и контроль достоверности и номера интервала, где он сейчас находится.
4) Опять таки вопрос не к скаде, не ее задача контролировать отказы датчиков и АЦП, ДЦП — это должно реализовываться на другом уровне. В системе по переменным есть признак Достоверности (аппаратная, программная, достоверность типа), их можно менять программно, из драйвера устройства, или вручную с операторской мнемосхемы.
5) Да, на текущий момент графическое ядро работает в одном процессе с вычислительным, вернее сказать они последовательно выполняются в процессе пересчета базы и математики. Однако я уже сейчас продумываю как их разделить по разным потокам, чтобы не грузить основной вычислительный процесс ядра графикой.
Относительно вопроса про контроллер и мнемосхему для него — вы несколько некорректно понимаете архитектуру моей системы, у меня подобное решается так: в проекте создается два узла (контроллер и АРМ), в каждом своя база переменных, алгоритмов, а между их переменными уже устанавливаются связи через сеть или последовательный интерфейс. Таким образом получается проект из двух узлов: контроллер, который работает внизу и АРМ наверху. Графика мнемосхем делается как раз в АРМе, а данные для нее он по сети или последовательному каналу из контроллера уже поднимает.
6) Пошаговая отладка с выводом всех внутренних переменных есть только для визуального языка FBD. Для С# этого нет, там процесс выполнения по шагам только на уровне выполнения логики алгоритма на 1 такт с выводом всех входных и выходных его аргументов. Внутренние как в профф. студиях программирования типа окна Watch я не могу сделать… пока не могу…
7) Все процессы по архивации в СУБД у меня буферизированы. Более того — в случае, если буфер не удается сбросить в СУБД, а рантайм тормозят — он может скинуть его в файл, и подчитать при рестарте. Так что данные потерять совсем можно только жестко обрубив питание.
8) Про механизм квитирования от мнемосхемы к контроллеру — снова немного некорректная постановка вопроса относительно архитектуры моей скады. Сделаем проще — приведите описание задачи, которую надо решить, а я объясню как она решается у меня.
9) Дублирование с поддержкой горячего резервирования я пока только планирую, на данный момент пока ничего этого нет. А вот насчет кластеризации — немного не понял суть, вы имеете ввиду функцию распределения вычислительной нагрузки по алгоритмам в проекте из одного узла на несколько, если один не справляется?
10) Дублирование сети — как уже сказал, что подсистему сетевого обмена я пока только еще делаю, так что тут пока рано говорить об этом. Однако вопрос резервирования для скады — это серьезный и многоуровневый вопрос, так что его проработка относительно сети также меня ожидает.
Если не секрет, как называется САПР, в разработке которого вы принимаете участие?
Сейчас ведется разработка сайта, через который я планирую начать распространять свое решение уже в массы. Там будет форум, информация по продукту, а также онлайн справочная система + онлайн курсы по работе в ней. Последнее уже начал делать на базе движка Википедии, очень удобно получается.
Насчет продажи — пока никто не предлагал продать, но тут пока еще мало кто вообще знает о том, что я делал. Сейчас вот после Хабра будет побольше уже. Однако в период информационного освещения своего детища через АСУТПшные форумы я уже успел стать официальным конкурентом для одного из производителей отечественного бренда. Руководство фирмы разработчика СКАДы, увидев мое решение, официально возвело меня в ранг конкурента после моего отказа прекратить разработки, а сотрудничать с ними и работать ТОЛЬКО на их решении…
Спасибо за ссылки, но язык принципиален, я пишу на C#, поэтому нужны обертки с поддержкой managed кода. Материалы по dOPC я уже проходил — брал кое-что для тестов и ознакомления, также у них даже есть обертка для .Net, но вот скачать ее они не дают.
Ну, если изменение должности с «ведущего инженера АСУТП» на должность «руководитель отдела прикладного ПО» можно отнести к такому успеху, то да. За время разработки по основной работе часть своих наработок я внедрил непосредственно в наше производство. Например, последние все наши проекты по фирме выполняются полностью с использованием моей подсистемы архивации в СУБД совместно с брендовой СКАДой. Помимо этого сделал отдельное решение по моделированию объектов управления, которое сейчас потихоньку внедряем на своем полигоне, через который прогоняются все наши проекты и на котором проводим их заводские испытания. Кстати, это решение у меня как раз в математический аппарат заложено в скаде. Параллельно с этим я лично веду 2 проекта АСУТП для АСУ Энергоснабжения газоперекачивающих станций (достаточно крупные — каждый по 2000-3000 точек ввода/вывода), один из них в конце этого года выходит на МВИ (межведомственные испытания), чтобы быть принятым как рекомендуемое решение в отрасли. Плюс к этому эти же проекты сам делаю еще и в своей системе (некоторые скриншоты в статье и даже видеоролики сделаны на этих проектах), чтобы к осени на заводских испытаниях одну из них показать не только в штатном исполнении на брендовой СКАДе, но и на базе своей разработки, для наглядности. А весной вообще было весело — намечалась покупка жилья, так что пришлось параллельно совмещать три работы: утром до основной делал АСДУ одного бизнес-центра, потом мчался на основную, а вечером после основной — на другой объект. После уже дома часиков до 2-3 ночи копался в своей системе. Помнится, после двух месяцев такого режима, вымотан был капитально, пришлось неделю отпуска брать. И первые двое суток я спал вообще не просыпаясь… Долго так сложно выдержать, поэтому — по личному опыту могу сказать, что возможности большие, но не безграничные.
С ОРС все не просто, сама OPC-foundation в этом плане очень серьезно следит за тем, чтобы за любой чих разработчик отстегивал им немалые деньги. Я много искал нормальные обертки под ОРС, потому как платить ассоциации (если не ошибаюсь около 1500 евро) за членство и доступ к материалам я сейчас не могу. Нашел два более-менее подходящих варианта: один бесплатный (писали энтузиасты и выложили результаты в свободный доступ, дальше сами дорабатывайте), платный — от GrayBox. Первый сразу встроил, там есть поддержка клиента и вроде даже сервера по OPC DA 2.0, но серверную часть я пока еще не осилю — сложновато. Грейбоксовский сейчас вот ковыряю по части клиента (хотя и серверные интерфейсы там тоже есть), в нем есть: DA, HDA, AE, и все это же также по XML, но все в коммерческой версии за денежку. Для текущих проектов, где в основном мониторинг и частичное управление через ОРС пока хватает.
Не спорю — я не могу видеть абсолютно все решения, но большинство scada-систем, что удалось посмотреть и поговорить с представителями дистрибьюторов не дают такого сервиса. В большинстве случаев самый максимальный бонус: надо в среде разработки привести масштабы к нужным, и только потом запускать под рантаймами. Но — мне проще показать как это работает в режиме реального времени в моем рантайме, нежели писать сотни слов: youtu.be/KvWrDK4Chm0
Готов принять участие в поддержке этого стандарта в своей СКАДА-системе! Где качать библиотеки, примеры и тестовые имитаторы для проверок? :)
Сам не раз прибегал к его помощи, очень помог.
Кстати, сам я в своей Скаде использую OPCDOTNET, отлично работает, вот только с локальными ОРС, удаленные не поддерживаются.
Еще работал с библиотеками от GreyBox — даже без справки можно разобраться, можно найти полнофункциональные без ограничений работы. В них можно и с удаленными ОРС работать.
Инструменталка — объем 9,082Мб
Рантайм для Windows — объем 3,784Мб
Рантайм для WinCE — объем 2,145Мб
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) Да, как уже сказал, все это еще только мне предстоит. Сейчас по текущим проектам пока требуется горячее резервирование как внизу, так и наверху. Кластеризацию обычно делал на уровне алгоритмов, когда КИП троированный был, на уровне узлов пока еще не приходилось таких задач решать.
КВИНТ — знаю, вернее много слышал, и знаком с людьми, которые на ней очень плотно работали. Например, когда в Ираке Нассирийскую ТЭС пускали, оооочень много наслушался сравнительных характеристик от инженеров ОРГРЭСа (был там такой — Бородкин) относительно КВИНТа и ТМа. :)
Насчет политики форматов проекта (например как у того же ТМ) — опять же не будет делений на Демо и Проф варианты, потому как сам файл проекта в моей системе в чистом XML (для особо интересующихся программистов, с целью сопряжения с другими системами я могу этот формат даже описать).
Ну и останется только коммерческая составляющая СУБД для архивов — если для личного пользования брать, то у MySQL вроде лицензия бесплатная на это (сам так сейчас разработку веду), но для коммерческого применения — уже потребуется приобретение лицензий, однако это уже вопрос не ко мне, этот вопрос должен будет уже конечный пользователь моей скады решать.
Лицензия для рантаймов планируется на количество переменных (параметров на 1 узел), сюда просто будут считаться все каналы (тэги), которые сделаны в проекте на этот узел (как внутренние, так и связанные с внешними параметрами и оборудованием).
В общем вкратце суть политики лицензирования такая: берешь инструмент, делаешь проект, если все получается и он удовлетворяет всем требованиям, то конечный результат запускаешь уже под рантаймами за денежку.
Ну а по поводу посмотреть. Стучите мне на почту, обсудим. Система бесплатна, поэтому если не пугает:
1) То, что в ней есть ошибки и у меня сейчас нет релизов, прошедших капитальное тестирование
2) Справочная система пока в процессе разработки, однако так как она на базе движка Википедии — она доступна всегда онлайн и всегда актуальная. В принципе в дальнейшем планирую, что доверенные пользователи сами смогу наполнять ее в процессе своей работы недостающей информацией или своими наработками.
Контакт почтового адреса можно найти на моем сайте (по тексту статьи ссылки на материалы идут как раз с моего сайта).
У меня тут один пользователь взял систему пощупать и пропал на неделю, ни слуху, ни духу. Пишу ему с вопросом, что и как, как дела, какие результаты, а он оказывается уже потихоньку свой реальный проект делает в моей системе и она даже показывает стабильную работу (у него железо по ОРС подключается). Вот так глядишь, еще и быстрее меня проект в ней сделают. :)
1) Фиксированное время цикла определяется разработчиком проекта для конкретного узла проекта (АРМа или контроллера), однако реальное время, которое затрачивается на пересчет всей математики, что он навертел внутри этого узла, может и не хватить, тогда цикл реального пересчета будет превышать установленный. Таким образом разработчик при отладке должен учитывать, что в случае превышения установленного цикла реальным ему придется установленный цикл повышать до размеров реального — ведь сказать системе работать быстрее невозможно. Это все легко диагностируется на этапе отладки системы. Все ресурсоемкие процессы, такие как: архивация, журналирование событий, работа с дампом, внутренние архивы в памяти, сброс их в файлы, обмен по внешним интерфейсам — это все отдельные потоки, работа которых идет параллельно основному процессу пересчета базы и математики узла. Технология одинакова как для контроллеров, так и для АРМов операторов.
2) Как я уже говорил — в системе я реализовал собственный вычислительный движок, который не работает с понятиями типа данных, для него любой тип — это в первую очередь «объект», и приведение его к нужному типу выполняется в зависимости от реализуемой функции или контекста использования. Поэтому в моей системе делить на ноль можно вообще без возникновения исключительных ситуаций — получите бесконечность как результат, хотите контролировать тип, делайте это в логике алгоритма. Хотя сам движок не мешает сделать это внутри него штатно. Тут практика уже покажет — как будет удобнее, так и доработаю.
3) Диапазоны и уставки — не совсем понятно при чем тут скада как таковая — это вопросы реализации конечных проектов АСУТП на ее базе, ведь это переменные техпроцесса. По аналоговым переменным у меня есть диапазоны границ сигнала и контроль достоверности и номера интервала, где он сейчас находится.
4) Опять таки вопрос не к скаде, не ее задача контролировать отказы датчиков и АЦП, ДЦП — это должно реализовываться на другом уровне. В системе по переменным есть признак Достоверности (аппаратная, программная, достоверность типа), их можно менять программно, из драйвера устройства, или вручную с операторской мнемосхемы.
5) Да, на текущий момент графическое ядро работает в одном процессе с вычислительным, вернее сказать они последовательно выполняются в процессе пересчета базы и математики. Однако я уже сейчас продумываю как их разделить по разным потокам, чтобы не грузить основной вычислительный процесс ядра графикой.
Относительно вопроса про контроллер и мнемосхему для него — вы несколько некорректно понимаете архитектуру моей системы, у меня подобное решается так: в проекте создается два узла (контроллер и АРМ), в каждом своя база переменных, алгоритмов, а между их переменными уже устанавливаются связи через сеть или последовательный интерфейс. Таким образом получается проект из двух узлов: контроллер, который работает внизу и АРМ наверху. Графика мнемосхем делается как раз в АРМе, а данные для нее он по сети или последовательному каналу из контроллера уже поднимает.
6) Пошаговая отладка с выводом всех внутренних переменных есть только для визуального языка FBD. Для С# этого нет, там процесс выполнения по шагам только на уровне выполнения логики алгоритма на 1 такт с выводом всех входных и выходных его аргументов. Внутренние как в профф. студиях программирования типа окна Watch я не могу сделать… пока не могу…
7) Все процессы по архивации в СУБД у меня буферизированы. Более того — в случае, если буфер не удается сбросить в СУБД, а рантайм тормозят — он может скинуть его в файл, и подчитать при рестарте. Так что данные потерять совсем можно только жестко обрубив питание.
8) Про механизм квитирования от мнемосхемы к контроллеру — снова немного некорректная постановка вопроса относительно архитектуры моей скады. Сделаем проще — приведите описание задачи, которую надо решить, а я объясню как она решается у меня.
9) Дублирование с поддержкой горячего резервирования я пока только планирую, на данный момент пока ничего этого нет. А вот насчет кластеризации — немного не понял суть, вы имеете ввиду функцию распределения вычислительной нагрузки по алгоритмам в проекте из одного узла на несколько, если один не справляется?
10) Дублирование сети — как уже сказал, что подсистему сетевого обмена я пока только еще делаю, так что тут пока рано говорить об этом. Однако вопрос резервирования для скады — это серьезный и многоуровневый вопрос, так что его проработка относительно сети также меня ожидает.
Если не секрет, как называется САПР, в разработке которого вы принимаете участие?
Насчет продажи — пока никто не предлагал продать, но тут пока еще мало кто вообще знает о том, что я делал. Сейчас вот после Хабра будет побольше уже. Однако в период информационного освещения своего детища через АСУТПшные форумы я уже успел стать официальным конкурентом для одного из производителей отечественного бренда. Руководство фирмы разработчика СКАДы, увидев мое решение, официально возвело меня в ранг конкурента после моего отказа прекратить разработки, а сотрудничать с ними и работать ТОЛЬКО на их решении…