Нет, об этой разработке услышал впервые от Вас. Посмотрел материалы, почитал — в похожем направлении двигался когда начинал свой Моделист первый писать, чтобы создавать модели для отладки на полигоне наших разрабатываемых систем. Масштабы у меня конечно не такие, но идея та же была.
Чем-то напоминает притчу про неуловимого Джо и почему он неуловим…
Если бы QNX стоял на каждом «углу» как и винда, то любителей его поломать было бы гораздо больше, и списочки бы были почти одинаковые. Да, конечно QNX гораздо надежнее винды, но я бы не стал особо полагаться на разницу только на основании вышеприведенных списков.
К сожалению некоторым областям еще далеко до этих прописных истин. Когда в них работаешь, то формула Технология=(текущее поколение — 1) это еще из разряда «тебе повезло, братан». Приходится что-то делать, облизываясь на то, что сейчас для этого есть…
От спецов с АСУТПшного форума (http://asutpforum.ru/viewtopic.php?f=11&t=3239) ответ авторам статьи в виде анекдота:
Шотландский пастух пасет овец на изумрудно-зелёном поле. Вдруг к краю поля подлетает «Мерседес» последней модели, из него выскакивает молодой человек в шикарном костюме и с Rolex'ом на руке, подходит к пастуху и говорит: «Я могу помочь тебе в твоём деле».
«Что ж, давай!» — отвечает пастух.
Молодой человек достает из машины ноутбук, вытягивает антенны и начинает работать. Он получает снимки со спутников, обрабатывает их, делает какие-то сложные расчёты, беспрестанно звонит важным людям и экспертам в разных областях, и в конце концов вытаскивает цветной принтер, печатает красивый толстый отчёт, тут же его сброшюровывает, подходит к пастуху и говорит:
«Вот, держи. Я вычислил: принимая во внимание все имеющиеся факторы, оптимальный размер твоего стада — 156 овец. А у тебя их 157! Это портит весь твой бизнес! Я одну овцу заберу, и всё наладится».
Молодой человек хватает овцу и начинает запихивать её в багажник «Мерседеса».
В этот момент пастух его окликает:
«Послушай, дружок, ты, должно быть, из PriceWaterhouseCoopers?»
«А как ты догадался?!»
«Очень просто. Во-первых, тебя никто не звал, ты сам пришёл. Во-вторых, ты работал целый день и дал мне ответ на вопрос, на который я и сам знаю ответ. А в-третьих, отдай МОЮ СОБАКУ, кретин! Ты в моём бизнесе ничего не понимаешь!»
Нет, программное обеспечение класса СКАДА не подлежит обязательным сертификациям, более того — их просто не существует. Максимум, какой сертификат можно получить — это так называемый «Сертификат соответствия». Его смысл в том, что он выдается на продукт, у которого перечень заявленных функций, а также содержание документации соответствует действительному положению дел в самом продукте. Такой сертификат для любого ПО можно получить, при должном походе, только вот смысл в нем.
Другое дело, что конечные системы АСУ ТП под ключ, в зависимости от области их применения, разработанные на базе СКАДА-системы (любой), подлежат обязательной сертификации, если того требует отрасль. Например, если Вы делаете на моей скаде систему коммерческого учета электроэнергии (АСКУ Э) — она обазятельно должны будет пройти сертификацию на класс систем АСКУ Э. Кстати, сама скада максимум, что может при этом иметь, некий сертификат рекомендованного средства для разработки подобной системы, но ни более того. То бишь, для того чтобы гнуть пальцы и надувать важно щеки, можно наполучать таких вот сертификатов-рекомендаций по разным сферам (энергетика, пожарка, безопасность и т.д.), но цена таким бумагам — будет не больше туалетной, они имеют только рекомендательный характер, а также маркетинговое преимущество: многие конечные пользователи любят их наличие, и для некоторых их наличие — это определяющий фактор для приобретения (некоторый психологический фактор). А то, что все это имеет обычный рынок зарабатывания денег на подобных вещах, вес которым — бумага, а не реальное положение дел, как-то умалчивается (да и зачем, «пипл хавает»).
Еще из обязательной сертификации — я знаю только сертификацию в ФАПСИ, но ее необходимо делать только при условии, что ПО будет применять стойкие алгоритмы шифрования, которые наши органы гос.безопасности обязаны держать на контроле, а также иметь принудительные каналы для их обхода в таком ПО. Был уже опыт, когда рассмотрев сложность и финансовую сторону прохождения такой сертификации, решили, что проще убрать шифрование из продукта вообще, чем связываться со всей этой бодягой в стиле «дай, друг, на лапу мне...». :)
Это только в том случае, если софт поддерживает спецификацию OPC UA. Разница между ОРС обычным и OPC UA большая, и общего между ними разве что только три буквы «ОРС» в названии…
Хотя, возможно в дальнейшем может стоять вопрос не об использовании такого решения в полноценном управлением технологическими процессами, а хотябы чтобы иметь возможность запускать среду разработчика под разными ОСями. У меня много друзей, которые на личной технике предпочитают пользоваться Linux, а так у разработчика была бы возможность что-то менять в проекте не меняя привычную для него рабочую среду…
Да, это я конечно же осознаю, и сейчас стоит вопрос не сразу же полноценного использования под данную ОСь, а именно рассмотреть что можно сделать, чтобы действительно вести разработку под две платформы с минимумом затрат. В текущей версии скады я точно знаю, что использую много вещей из WinAPI, которые сам же прописывал у себя в коде по определенным причинам, поэтому для себя осознаю, что могу вполне отказаться от этих вещей именно в версии под Linux, быть может тогда и не потребуется использование Wine, или я тут что-то не догоняю в силу своей неграмотности, и меня надо поправить?
Пока для архивов и журналирования использую MySQL. Штатно — запись ведется по изменениям значений, но если есть желание делать это с заданным периодом, то такое тоже можно сделать, или штатно в проекте, или в виде отдельного алгоритма в проекте.
Для просмотра архивов есть штатный компонент архивного тренда, который работает с этой СУБД. Он может вообще от скады отдельно работать. А вообще — выборки из СУБД можно прямо в проекте делать и потом обрабатывать в логике, динамический массив — это один из стандартных типов данных в моей скаде.
Не все сразу, уже скоро планирую сделать ее достоянием общественности. Пугает только то, что дербанить ее будут после моих опусов в клочья. :) Но и это не особо страшно, страшно другое — тягать по всем вопросам в ней будут меня, а я один… Поэтому на текущий момент я предпочитаю давать к ней доступ только тех, кто сейчас в ней реально работает со мной, или по своим направлениям, но именно работает, а не просто ради одноразового любопытства ее смотрит. Поэтому, прощу прощения, но пока не всем. Хотя, некоторые темы в Ваших статьях меня заинтересовали, нам возможно будет найти обоюдный интерес… Я чуть позже в личку обращусь, если не против.
Автор путает области применения ПО, видимо из-за недостаточного опыта и знаний. В мире давно уже существуют стандарты и системы, которые по этим стандартам выпускаются именно для таких применений, где ошибка системы может привести к летальному исходу, или жертвам. В системах для таких применений нет лицензионного соглашения с пресловутой кнопочкой «I agree»… Там совершенно другие подходы к проектированию, разработке, и главное — тестированию! Там разработчик полностью несет ответственность за любую ошибку системы. И не дай бог, в разработку такой системы попадет вот такой вот программист с бытовым подходом к разработке, вот когда надо начинать паниковать и бояться! И главное — вот над чем надо задуматься. А не о том, о чем написано выше…
По своему опыту разработки систем АСУ ТП могу сказать, что проприетарные пакеты SCADA-систем, в которых создаются автоматизированные комплексы управления «умный дом», все поголовно идут с пользовательским лицензионным соглашением, где прописано, что «Данный продукт поставляется на условиях как есть. И пользователь принимает на себя всю ответственность за его использование и результаты его работы». Однако, когда я создаю в этом инструменте конечную систему управления умным домом под ключ, я, как разработчик уже несу за этот комплекс полную ответственность, а не за скада-систему (в которой я его создаю). И важно заметить, что это уже не просто софт — это ПТК: программно-технический комплекс, который состоит из выбранного мной под конкретные задачи железа, которое я выбрал на основании требований, которые предъявляются согласно решаемым мной задачам, а также — прикладного проекта, составляющего программную часть системы. И в конечном итоге на полигоне я буду проверять работу системы в целом как единого ПТК. И проверять буду по методикам, разработанным на основании тех требований, которые я буду предъявлять к системе, потому что в конечном итоге я буду нести ответственность за качество ее работы. В случае, если я буду ее продавать на условии «как есть» — ее попросту у меня никто не купит! Я бы лично никогда не купил конечную систему под ключ, где продавец бы мне пытался втюхать кнопку «Я согласен с тем, что я дурак»…
Про горяее резервирование — понял, просто описание на сайте «не в кассу». У меня в моей скаде реализовано горячее резервирование серверов с переключением клиентов АРМов оперативного персонала по ним в зависимости от режима, поэтому все что Вы описали мне знакомо. Вот только у себя в системе я сделал функцию арбитража и у меня сервер при старте, если ему задано резервирование (кстати, в проекте он разрабатывается как один узел, ему просто два IP-адреса назначается тех ПК, где они будут запущены) автоматически ищет свой образ в сети, и если его находит, становится Слейвом, поэтому бегать никуда не надо чтобы восстановить справедливость режимов. Поэтому и описанных Вами проблем у меня не наблюдается. Кроме того — в проекте разработчик по параметрам может назначать галочки синхронизации параметра по мастеру и он будет автоматически синхронизировать свое значение в узле с режимом Слейв по значению себя же с узла Мастер по сети, тогда переход из Слейва в Мастер будет максимально безударным. Самое смешное, что все это я сделал на базе стандартного протокола ModBusTCP, пусть и с некоторыми ограничениями для форматов данных. Я еще работаю над некоторыми особенностями горячего резерва, тут большое поле для деятельности, сейчас хочу перенести текущую модель на свой основной сетевой механизм обмена. Но текущий вариант уже работает на объекте, который сейчас запустил — здесь много оборудования по ModBusRTU и ModBusTCP, причем все RTU идет через МОХА (преобразователи интерфейсов RS485-Ethernet), которые очень глючно работают в режиме, когда два мастера инициализируют сами СОМ-порты, пусть даже опрос ведет только один, приходится все время реинициализировать порты, чтобы обмен шел нормально, МОХА в этом плане огорчает. А многое оборудование смежных систем по ModBusTCP вообще капризное до того, что не позволяют даже инициализировать по сети к себе подключение более 1 мастера по протоколу ModBusTCP. Поэтому когда дошло до резервируемых серверов опроса, пришлось такие штуки напридумывать и сделать их штатными для скады, что мозг сломаешь, дошел даже до таких вещей как распределение задач скады между рантаймами в рамках одного ПК с объединением потоков данных, управляемых разработчиком, через методы общей памяти (так называемой SharedMemory). Скажи мне еще весной, что я такие задачи буду самостоятельно решать, да еще и сидя на объекте в кратчайшие сроки — покрутил бы у виска пальцем и отнес бы это к области фантастики рассмеявшись в лицо, ан нет, время показывает, что не до смеха, и приходится придумывать изощренные модели архитектуры, с которой потом простой обыватель мог бы общаться на «ты», не вдаваясь в сложность настроек и архитектурных особенностей. :)
1) Сервер ввода-вывода, по сути ядро исполнительной системы, как и сама система — всецело базируется на стандартах ОРС — уже ошибка, сама технология ОРС — развод лохов на бабки за дешевую реализацию якобы стандарта, базирующегося на таких сложных технологиях как COM/DCOM, поддержка и реализация которых на конечных системах требует таких неиии… х познаний и кувырканий с настройками, что внедренец готов иметь в итоге всех разработчиков и их родню вместе взятых по результатам таких кувырканий.
2) Горячее резервирование — заявленное непревышение 0.01с при «не»определенных протоколах и условиях немного смахивает на бред, тем более, что на уровне серверов управление объектом, где применяется горячее резервирование не выполняется никогда! Я бы голову скручивал разработчику подобного на объекте на уровне, где работает сервер скады.
3) По трендам и графике — Упор на технологию ActiveX считаю не совсем удачной рекламой продукта. А судя по скриншотам, тренды оставляют желать лучшего. Я видел и интереснее функциональность и визуальную адекватность в других системах, нежели на представленных скриншотах, может будет звучать заносчиво, но «я так тоже могу и даже» лучше уже сейчас.
4) Вэб роутер — «громкие» цифры ниочем… вообще продукт представлен «ниочем», по крайне мере из описания
5) Проигрыватель истории — мне интересно, реально кто-то сидит на объектах и проигрывает это? За всю мою практику работы в АСУТП — «разбор полетов» происходит вообще по-другому, и там важны другие представления данных, нежели плеер истории.
А еще — порадовали функции математической обработки и разработки алгоритмов, если бы у меня, как разработчика, в системе были только эти возможности, я бы всерьез задумался о смене инструмента…
Извините, если сильно амбициозно, или не в тему, но это результат первого знакомства чисто по описанию, человека, который примерно как и Вы 12 лет в автоматизации…
Скажу честно — саму Infinity даже в руках не держал, но как инженер и в некотором роде архитектор систем подобного рода, пробежав по основным разделам описательной части их системы могу вынести такое резюме (поправьте меня, если я буду чертовски нести чушь):
Дорогу осилит идущий. Был я в том Китае, довелось там много поработать в 2002-2004, так что не зарекайтесь, ведь судя по профилю мы одногодки! ;)
А насчет Элеси — в Томске может и подмяло, но я тут по другим объектам, более серьезным и крупным, про Элеси на них даже не слышали.
Если бы QNX стоял на каждом «углу» как и винда, то любителей его поломать было бы гораздо больше, и списочки бы были почти одинаковые. Да, конечно QNX гораздо надежнее винды, но я бы не стал особо полагаться на разницу только на основании вышеприведенных списков.
Шотландский пастух пасет овец на изумрудно-зелёном поле. Вдруг к краю поля подлетает «Мерседес» последней модели, из него выскакивает молодой человек в шикарном костюме и с Rolex'ом на руке, подходит к пастуху и говорит: «Я могу помочь тебе в твоём деле».
«Что ж, давай!» — отвечает пастух.
Молодой человек достает из машины ноутбук, вытягивает антенны и начинает работать. Он получает снимки со спутников, обрабатывает их, делает какие-то сложные расчёты, беспрестанно звонит важным людям и экспертам в разных областях, и в конце концов вытаскивает цветной принтер, печатает красивый толстый отчёт, тут же его сброшюровывает, подходит к пастуху и говорит:
«Вот, держи. Я вычислил: принимая во внимание все имеющиеся факторы, оптимальный размер твоего стада — 156 овец. А у тебя их 157! Это портит весь твой бизнес! Я одну овцу заберу, и всё наладится».
Молодой человек хватает овцу и начинает запихивать её в багажник «Мерседеса».
В этот момент пастух его окликает:
«Послушай, дружок, ты, должно быть, из PriceWaterhouseCoopers?»
«А как ты догадался?!»
«Очень просто. Во-первых, тебя никто не звал, ты сам пришёл. Во-вторых, ты работал целый день и дал мне ответ на вопрос, на который я и сам знаю ответ. А в-третьих, отдай МОЮ СОБАКУ, кретин! Ты в моём бизнесе ничего не понимаешь!»
Другое дело, что конечные системы АСУ ТП под ключ, в зависимости от области их применения, разработанные на базе СКАДА-системы (любой), подлежат обязательной сертификации, если того требует отрасль. Например, если Вы делаете на моей скаде систему коммерческого учета электроэнергии (АСКУ Э) — она обазятельно должны будет пройти сертификацию на класс систем АСКУ Э. Кстати, сама скада максимум, что может при этом иметь, некий сертификат рекомендованного средства для разработки подобной системы, но ни более того. То бишь, для того чтобы гнуть пальцы и надувать важно щеки, можно наполучать таких вот сертификатов-рекомендаций по разным сферам (энергетика, пожарка, безопасность и т.д.), но цена таким бумагам — будет не больше туалетной, они имеют только рекомендательный характер, а также маркетинговое преимущество: многие конечные пользователи любят их наличие, и для некоторых их наличие — это определяющий фактор для приобретения (некоторый психологический фактор). А то, что все это имеет обычный рынок зарабатывания денег на подобных вещах, вес которым — бумага, а не реальное положение дел, как-то умалчивается (да и зачем, «пипл хавает»).
Еще из обязательной сертификации — я знаю только сертификацию в ФАПСИ, но ее необходимо делать только при условии, что ПО будет применять стойкие алгоритмы шифрования, которые наши органы гос.безопасности обязаны держать на контроле, а также иметь принудительные каналы для их обхода в таком ПО. Был уже опыт, когда рассмотрев сложность и финансовую сторону прохождения такой сертификации, решили, что проще убрать шифрование из продукта вообще, чем связываться со всей этой бодягой в стиле «дай, друг, на лапу мне...». :)
Для просмотра архивов есть штатный компонент архивного тренда, который работает с этой СУБД. Он может вообще от скады отдельно работать. А вообще — выборки из СУБД можно прямо в проекте делать и потом обрабатывать в логике, динамический массив — это один из стандартных типов данных в моей скаде.
По своему опыту разработки систем АСУ ТП могу сказать, что проприетарные пакеты SCADA-систем, в которых создаются автоматизированные комплексы управления «умный дом», все поголовно идут с пользовательским лицензионным соглашением, где прописано, что «Данный продукт поставляется на условиях как есть. И пользователь принимает на себя всю ответственность за его использование и результаты его работы». Однако, когда я создаю в этом инструменте конечную систему управления умным домом под ключ, я, как разработчик уже несу за этот комплекс полную ответственность, а не за скада-систему (в которой я его создаю). И важно заметить, что это уже не просто софт — это ПТК: программно-технический комплекс, который состоит из выбранного мной под конкретные задачи железа, которое я выбрал на основании требований, которые предъявляются согласно решаемым мной задачам, а также — прикладного проекта, составляющего программную часть системы. И в конечном итоге на полигоне я буду проверять работу системы в целом как единого ПТК. И проверять буду по методикам, разработанным на основании тех требований, которые я буду предъявлять к системе, потому что в конечном итоге я буду нести ответственность за качество ее работы. В случае, если я буду ее продавать на условии «как есть» — ее попросту у меня никто не купит! Я бы лично никогда не купил конечную систему под ключ, где продавец бы мне пытался втюхать кнопку «Я согласен с тем, что я дурак»…
2) Горячее резервирование — заявленное непревышение 0.01с при «не»определенных протоколах и условиях немного смахивает на бред, тем более, что на уровне серверов управление объектом, где применяется горячее резервирование не выполняется никогда! Я бы голову скручивал разработчику подобного на объекте на уровне, где работает сервер скады.
3) По трендам и графике — Упор на технологию ActiveX считаю не совсем удачной рекламой продукта. А судя по скриншотам, тренды оставляют желать лучшего. Я видел и интереснее функциональность и визуальную адекватность в других системах, нежели на представленных скриншотах, может будет звучать заносчиво, но «я так тоже могу и даже» лучше уже сейчас.
4) Вэб роутер — «громкие» цифры ниочем… вообще продукт представлен «ниочем», по крайне мере из описания
5) Проигрыватель истории — мне интересно, реально кто-то сидит на объектах и проигрывает это? За всю мою практику работы в АСУТП — «разбор полетов» происходит вообще по-другому, и там важны другие представления данных, нежели плеер истории.
А еще — порадовали функции математической обработки и разработки алгоритмов, если бы у меня, как разработчика, в системе были только эти возможности, я бы всерьез задумался о смене инструмента…
Извините, если сильно амбициозно, или не в тему, но это результат первого знакомства чисто по описанию, человека, который примерно как и Вы 12 лет в автоматизации…
А насчет Элеси — в Томске может и подмяло, но я тут по другим объектам, более серьезным и крупным, про Элеси на них даже не слышали.