Как я СКАДу писал. Часть третья

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

    Начнем с прогресса, который как известно не стоит на месте. Очередным толчком к мысли «а есть ли жизнь на Марсе» стала как раз система на 3000 точек, где в диспетчерской стоят аж 3 АРМа на базе моей скады. А где диспетчер — там всегда картинки.
    Вдоволь наигравшись с возможностями GDI+ по части графики, я таки дал им то, чего они хотели увидеть, и запустив систему на объекте в промышленную эксплуатацию, я подошел к моменту, что заказчику, как эксплуатирующему лицу — стала позарез необходима документация в виде «руководства пользователя». Заказчик попался дотошный и попросил предоставить ему совсем подробную версию такого руководства, где были бы все возможные формы экранных мнемосхем этой системы. «Ага, сказали мужики» и начали скриншотить их… Ха, не все так просто, где-то на 50-м скрине мне стало тошно от такой рутины, а их постоянные «вот тут давай подправим» все время видоизменяли эти формы и их приходилось скриншотить по-новой, модифицируя предварительный документ для утверждения в верхах. Пришлось ваять специализированную функцию рантайма, по которой он сам на автомате генерирует ВСЕ экранные формы в виде файлов изображений (кстати, потом хочу воспользоваться удобным форматом офисного MS Word, чтобы также автоматом собирать само руководство в нужном СНИПе). И вот когда на выходе системы рантайм задумался и выдал 390 экранных форм, мне малость поплохело от мысли, что ЦПУ не резиновый, и GDI+ конечно просто и удобно, но надо бы уже задуматься о современных бонусах цифровой техники и возможностях аппаратного ускорения для видеосистемы, а то глядишь, непомерные аппетиты красивостей могут вскоре на таких решениях полностью сожрать производительность современных процессоров. Дополнительным пинком для этого также стали замечания сторонних наблюдателей: «эээ, а чего это загрузка ЦПУ на АРМе почти всегда процентов 60-80?». Объяснять, что процессор для того и создан, чтобы работать — можно, но все же он не только на графику должен ориентироваться, пусть это и АРМ оператора.
    Итак — вооружившись мыслями о том, что я подсел на .Net основательно, я стал копать информацию, а что же мне могут предложить современные технологии. И началось: жалкие потуги проб DirectX, OpenGL и некоторых платных движков на их базе для упрощения процесса конечному разработчику. В итоге все не то — или лыжи у меня не ехали, или я — … Ну не гуру я в программировании на таких уровнях, обидно стало.
    В общем — решил, что рано или поздно, но технологию WPF и работу в формате XAML мне все же придется пощупать. Пощупал… Ужас какой-то, я первую книгу по WPF и XAML в 1000 страниц «заглотил» аж за неделю в электричке, я так художку не читал никогда в жизни. А под впечатлениями от изученного за 3 дня умудрился накидать прототип своего нового редактора FBD-алгоритмов. Честно говоря, первые три дня меня аж малость распирало от того, что я раньше этим не занялся. Уж больно сильно меня впечатлили возможности и технологии, наверное как школьника от впервые в жизни прочитанного фантастического произведения мирового классика. Но больше всего меня поразило то, насколько я близко подошел к данной технологии, когда «изобретал» свой собственный графический движок для своей скады на DGI+ и формате XML. Многие моменты у нас с мелкомягкими оказались чуть ли не один в один прототипами с одного чертежа. Аж, даже некоторая инженерная гордость обуяла.
    Не долго думая я начал изучать возможности создания рантайма под текущую версию своей скады, но уже с аппаратным ускорение графики и дополнительными возможностями XAML и WPF. Сейчас получился некоторый прототип вьювера, который позволяет без проблем открывать в приближенном виде экраны моего текущего формата скады и портировать их на лету в XAML, а отсюда открываются возможности по разделению разработки графического интерфейса не автоматчиком, а настоящим дизайнером и в настоящих профессиональных системах для того предназначенных. Я сейчас активно пробую работать в этом направлении с Microsoft Expression Blend (в нижеприведенных роликах используется именно он).
    Попутно решил создать уже третью версию своей системы моделирования технологических объектов «Моделист» (из которой кстати и вырос мой текущий FBD-редактор алгоритмов в скаде), она используется мной активно для отработки проекта и его алгоритмической части на полигоне перед отправкой на объект. Еще будучи в предыдущих версиях помогала мне настраивать системы вообще без посещения объекта, а потом запускаться на объекте с минимумом доработок и дерганий самой технологии. Если интересно, могу привести реальные примеры, где экономия времени была воистину колоссальной, а сам объект просто бы не позволил экспериментов над собой вживую ввиду его опасности.
    Сейчас новая система Моделиста будет доработана как штатный внешний отладчик для моей текущей версии скады, он позволит подключаться по сети к работающему проекту под отладочными исполнительными модулями и в реальном времени подменять текущие параметры системы моделью, которую сам разработчик также в режиме исполнения сможет создавать и отлаживать не нарушая самого проекта и не останавливая его. Этот метод сейчас очень активно используется нами на полигоне, чтобы прогонять все наши решения перед отправкой на объект.
    Выглядит примерно так (кликабельно):
    image

    По графике некоторые из экспериментов со вьювером и блендом:




    А здесь немного по новому Моделисту:

    Правда тут совсем ранняя версия 3-х дневная, сейчас он уже малость заматерел и умеет побольше, чем на видеоролике.
    Примечательно, что размер приложения, что на ролике всего 100КБайт, как-то даже не солидно для современных скада-систем.
    Особо интересующимся — даже выложил на пробу эту версию на одном из асутпшных форумов, особо порадовал единственный из комментариев: «Теперь я понял почему немцы войну проиграли.». Кстати он же был и единственным, народу почему-то или было лень смотреть, или просто уже нечего после этого сказать.


    Но графика графикой — а о сервисах тоже стараюсь не забывать. В начале июня возникла еще одна интересная ситуация, которая подтолкнула меня включить в свою скаду более расширенную работу с таблицами сигналов проекта, вернее выполнить сервис разработки проекта по исходным данным ТЗ.
    Немного предыстории: приходят ко мне 31-го мая с ТЗ на одну систему, в которой 5500 точек ввода-вывода, благо система без графики, НО — исходные узлы системы являются шлюзовыми для очень крупного проекта на другой скаде, которая не умеет работать с железом, которое представлено внизу, а моя — умеет. И надо работать с низовым оборудованием через встроенные драйвера, а вот с верхней скадой работать уже по ModBus TCP/IP обмениваться по сети, то есть полноценная поддержка ModBus TCP/IP Slave режима.
    Отлично, экраны рисовать не надо, надо все это только сконфигурировать в проекте и подготовить документацию на адресные пространства по ModBus TCP/IP протоколу для разработчиков верхнего уровня.
    Вроде посильная и простая задача, но, снова это самое НО:
    1) По срокам дотянули до того, что система должна быть отгружена на объект уже 10-го июня!!! И не просто отгружена но и готовая, то есть — работающая!
    2) В ТЗ все материалы включая таблицы сигналов представлены в формате PDF, который к тому же еще и закрыт паролем. НЕНАВИЖУ проектировщиков, работающих в PDF (сколько не работаю, все время данный формат вызывает только торможение в процессе разработки)! Хоть раз заставить бы их самих делать системы по документации, представленной в таком формате.
    3) Так как система шлюзовая, то разработчики верхнего уровня сидят без работы, ведь им нужна документация по шлюзам с регистровкой каждого параметра по ModBus, без нее верхний уровень не доделать и не запустить.

    В общем, условия забавные… На мой вопрос «а где вы были раньше и что так затянули проект?» только развели руками и стали заводить старые песни о главном…

    Ладно. Сел я подумал и понял, что первым делом надо всю эту информацию утянуть в проект. Однако 5500 сигналов бить ручками по визуальной документации в PDF — мартышкин труд и таких мартышек нужно будет много, а их нет, как и времени. Попытка пройтись файнридером по PDF выдала прикольный документ, где названия вроде те, а местами и не те, например обозначение тока «I» где-то превращалось в символ «1». И все эти мелочи сильно портили общую структуру полученного текста, а править его — опять нет времени. Про лом пароля утилитой тоже идея не прижилась. И тут мне пришла идея все же допилить механизм работы с таблицами сигналов, который я уже в некотором виде заложил в среде разработчика. Ну что, как там говорится «Валера, настало твое время!» (с)

    Впереди было 10 дней и совсем немного свободного времени, а также главное правило из всем известного мультика: «Лучше день потерять, зато потом за два часа долететь!». А «летать» по подобному маршруту по типовым решениям впереди маячило очень сильно.

    Исходя из текущих требований я малость расширил диапазоны и «навернул» чуть больше, чем это понадобилось для этого случая, но тут уж просто в раж вошел.
    Идея получилась следующей: разработчик в скада-системе постоянно получает ТЗ, где основными начальными данными для формирования базы параметров проекта является таблица сигналов. Сами таблицы сигналов в основном представляются в структурированных форматах (csv,excel,word, таблицы СУБД), конечно же велик соблазн перекинуть все это структурированное многообразие через обычный буфер обмена методом copy-paste, что и было мной сделано. Теперь для быстрого формирования набора сигналов проекта можно просто копировать столбцы сигналов из ТЗ прямо в проект скады через буфер обмена. Так как некоторые объекты оборудования с их перечнями параметров часто повторяются, или есть вероятность их многократного использования в будущем — добавлена возможность импорта-экспорта самих готовых таблиц сигналов из скады в файлы формата XML. Формат получился несложный, так что может даже использоваться для автоматизированной обработки сторонними средствами. В самой таблице сигналов сделан сервис по групповому редактированию параметров, перетаскиванию сигналов между разделами и некоторый сопутствующий мелкий сервис.
    Учитывая, что обработка дискретных сигналов ведется в скаде в упакованном виде в форматах: байт, слово, двойное слово, длинное целое, для каждого дискретного сигнала можно заранее определить группу и его номер входа по УСО, который определят его номер бита в этой группе.
    Кроме того, для удобства разбора полетов по работе проекта, когда от проверяющих приходят замечания, таблица сигналов получила интерактивность: каждый сигнал в таблице после проведения автоматического построения базы параметров проекта по ним получил реальную привязку к компоненту проекта и даже к источнику этого сигнала в проекте к его аппаратному описателю. Это дает возможность разработчику открыть таблицу сигналов, выбрать «проблемный» сигнал и по контекстному меню быстро позиционироваться в проекте на компонент, который его обрабатывает. А уже далее можно от этого компонента разворачивать штатными функциями перехода по зависимостям всю цепочку обработки этого компонента в алгоритмах, экранах и межкомпонентных связях, анализируя где и что сделано не так и почему не работает.

    В итоге, потратив где-то неделю перерывов свободного времени на разработку такого сервиса и его отладку, настал апогей и торжество технологий: исходный проект в СКАДА-системе был собран абсолютно с нуля по имеющемуся ТЗ, с генерацией выходных форм документации, в которой указана регистровка параметров системы с точностью до бита с полноценными комментариями, названиями и прочим, всего за 1 час работы в скаде! Только карты адресов параметров по проекту в формате HTML на обе области (HEX и FLOAT) весят почти по мегабайту. Все это было тут же передано разработчикам верхнего уровня, включая сам проект, а на следующий день получен результат об успешном предварительном испытании.

    Работа на этом конечно не закончена 100%, однако сделан серьезный задел для проектирования и формирования типовых наработок на будущее по типовым решениям.
    Буквально на прошлой недел вернулся с этого объекта, где за 1.5 дня я причеса текущий вариант проекта и запустил его в работу! Вуаля, перепрыгнуть через голову оказывается можно.
    Сейчас по результатам я дополняю скаду сервисом быстрого тиражирования текстовых составляющих из таблиц сигналов на журналы словарей, графику, ведь текст сигнала — это некий информационный параметр, который так или иначе используется в проекте, так зачем его каждый раз набивать ручками, если он уже есть в проекте как ресурс?
    Как пример — тоже набросал небольшой ролик по данной технологии:



    Ладно, буду закругляться, а то хотел маленько, а получилось как всегда — какой-то информационный понос, который ни мозгам ни рукам в процессе кодинга мне покоя не дает.

    Спасибо за внимание и тем, кто дочитал до конца. Но, уверяю — это еще не конец, все больше убеждаюсь, что это все только начало… Читаю литературу, пишу, внедряю и уже многие разработчики систем АСУТП начали работать и щупать мою систему применительно к своим задачам, что идет ей только на пользу! До скорых встречь на хабре и не только!
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 21
    • –2
      Это настолько круто что даже не совсем понятно что это)
      Предприятие — значит ERP. Это ERP?
      Какие то сигналы ModBus? Значит должна быть OS реального времени, которая будет их обрабатывать… хм… GDI+?! Windows??!? О май гад!
      Что за монстр??!
      • +1
        TraceMode тоже под Windows работает, а считается одной из мощнейших АСУ ТП на российском рынке.
        Автору могу лишь пожелать упорства и терпения довести дело до конца :) — то что вы делаете, действительно здорово.
        • 0
          Спасибо! Но ТМ уже курит нервно в сторонке…
          • +2
            TM курит? А можно поподробнее?
            • +3
              По пунктам вкратце:
              — Графика, уже отстает, даже с их пресловутым Fast 3D (как-то так маркетинг это обозвал), например тот проект на 3к сигналов у меня сначала на ТМ6 сделан был, на объекте он жиденько «обкакался», почему я и переделал на свою все
              — Архивирование, тут отдельная песня — можно тоже не одну статью написать про СПАД
              — Отчеты, ужас, который даже конкуренту не пожелаешь, чтобы понять — надо один раз попробовать и потом поглубже закапывать
              — Журналирование событий, можно назвать фразой: «Паранойя, ДОС нас преследует, 640Кб нам не хватит!»
              — Система авторизации и управления правами пользователей: «Вы не очень хорошо разбираетесь в битовых масках, и вообще — не учите нас жить...»
              — Конвертация проекта для рантайма: «У вас есть месяц, чтобы отдохнуть на объекте в процессе ПНР?»
              — Тиражирование решений и работа с библиотеками компонентов: «Я его слпила из того, что было, а потом… А ничего потом, там вообще ничего… для разработчика.»
              — Отладка проекта: «Вы не пробовали подглядывать в замочную скважину? Или как вылечить проблему в проекте через задний проход?»
              — Документирование проекта: «А руки вам зачем?»
              — Разработка крупных проектов по готовым спискам сигналов: «Это никому не нужно и никто этим не будет пользоваться!» (с) Эту фразу я получил от Анзимирова, когда предложил ему доработать систему до приемлемого импорта-экспорта проекта по структурированным таблицам для серьезных крупных решений
              — Техподдержка, у Вас тут ошибка в системе: «Вы просто не умеете работать с ТМ и вообще Вы не умеете разрабатывать системы АСУ, мы вас научим»
              Я могу продолжать долго, там много интересного… Насчет «мощнейшей системы для АСУТП на российском рынке» — это лишь заслуги маркетинга, который создал красивый фантик для сами понимаете чего… Я 9 лет проработал в Адастре, там меня и мои идеи по развитию ТМ считали за идиотские, как там у Жеванецкого: «Трудно спорить о вкусе устриц с людьми, которые их ели», я их ему уже 12 лет… :) Теперь я их реализую сам, и не просто на бумаге или в коде — они реально работают в практическом применении. Да, я не волшебник, я только учусь, но то, что я хочу видеть в инструменте, как конечный пользователь, разработчик, потребитель — я уже успешно реализую, и мне, а главное — конечному пользователю (эксплуатирующим организациям) это нравится… И теперь я это делаю в десятки, а порой и в сотни раз быстрее и эффективнее, чем раньше делал в ТМ.
              • +1
                С ТМ5 все было неплохо, особенно после нескольких лет непрерывного бета-тестинга и общением с разрабами, когда в ответ на очевидный баг в ответ слышишь — «а у нас пули вылетили, проблемы на вашей стороне», а потом, через месяц, когда для обхода беды сделаны костыли, выходит очередная версия, где косяк таки исправлен. Короче, я пережил ТМ с пятой версии, до рабочей 5.12 — после этого мне ничего не страшно: ну подумаешь графика ужасна — ерунда, чуть больше возни, да и технологу нужны лишь цифры, графики, индикация — остальное вторично. Ах, да с графиками-то у нас беда — СПАД называется, но разве это беда? Один хрен и практически всегда значения нужно поднимать выше, поэтому забираем цифры себе, складываем куда нужно, а потом рисуем куда душе угодно — хоть графики, хоть отчеты строй, кстати, вот и убили проблему отчетов. Битовая авторизация — это же чудно — точно знаешь, что хрен кто кроме тебя там разберется (только тот, кто выучит их талмуд 5см в толщину — это такой тест на преднадлежность к касте). Отладка — это для тех, кто изначально косячит, а тот, кто сделал безударный переход на резерв на микромрв — тот кристально безупречен и ошибок не допускает по определению. Это, конечно, все шутки, но вот что ТМ прям берет и курит — это громко (как бы). Да, есть нюансы (а они есть у всех скад), не везде удобно (а нет такой скады, чтобы было удобно всем), но в целом — ТМ более чем юзабелен, нет проблем с людьми (и обучением) и самое главное — достаочно большой список внедрений (конечно, порой не без проталкивания с финансовой заинтересованностью начальства на местах, но Адастра в этом не одинока).
                • +4
                  А мне надоело выпускать и сдавать системы на костылях, потому что без них ни один проект нормально не работал. Как инженеру стыдно было, что все время пытаешься оправдывать чужие косяки как свои собственные перед заказчиком. Прогнуться и молчать в тряпочку, да, тоже выход, но, извините, не мой. А упование на то, что не нравится — никто насильно не держит и ты волен выбирать любой другой продукт, но ведь и в любой другой семье не без урода и везде есть свои скелеты в шкафах, я считаю такие оправдания уделом слабых, простите, если обидел. И мне как-то претит осознание того, что все время только и занимаешься тем, что строишь какой-то дом инвалидов, где ходить могут только на костылях, хотя вполне способны бегать и побеждать даже на длинные дистанции. Я научился ценить свое профессиональное время и оценивать свои способности, и те, кто со мной работал и работают сейчас это также во мне ценят, а растрачивать это на поделку костылей — …
                  Работая в ТП постоянно приходилось не искать решения проблем конечного пользователя (а ведь решения были, но идеология сводилась к одному: ты должен доказать, что пользователь идиот и все свести к одному, как Вы правильно выразились: «а у нас пули вылетили, проблемы на вашей стороне»). Примерно 50% обращений пользователей в ТП обязаны были закончится ответной фразой «у нас на стенде Ваше решение работает, ищите проблему у себя», а также удалению с форума неугодных сообщений по настоянию маркетинга вместо их разбора и анализа для улучшения продукта. С лихвой накушался этого за те годы…
                  5-ку многие любили, более того — на ней работают до сих пор, я знаю две компании, которые до сих пор принципиально на 5-й версии сидят. Например, тот же монорельс — не так давно мне заказывали переработку этого проекта под новые разрешения мониторов, потому что сменилась техника, а спецов уже почти не осталось, но система жива продолжает жить, однако ее поспешно убили, убил маркетинг, которому был нужен фантик в виде 6-й версии…
                  Гордится чем, тем, что сумел победить глючность и неадекватность продукта, реализовав систему «безударного перехода на резерв в МикроМРВ», на Вашем месте я бы этим не гордился, а плюнул разработчику в лицо, за такие издевательства над собой. Все равно, что пытаться открыть консерву вилкой, да — круто быть тем, кто сможет выжить с такими навыками в этом диком мире. Но тот, у кого будет для этого консервный нож — откроет эту банку быстро, без проблем, накормит ей тех, для кого она предназначалась и не будет гордится этим, ведь это будет обыденная процедура, выполненная нормальным инструментом, который для того и был разработан. Поэтому, считайте меня ненормальным, но я не считаю эту ситуацию героической и из ряда вон выходящим примером инженерного гения, для меня, как для инженера — скорее это будет поводом задуматься о профпригодности такого разработчика, который этим занимался, вместо того, чтобы приложить свой интеллект в поисках оптимального инструмента для решения задачи, надеюсь понимаете почему… :)
                  • +1
                    Героическая ситуация, инженерный гений? Полноте — просто шутка, чтобы прийти к мысли, что ТМ не так и неплох, чтобы курить, правда, «есть нюансы». Но Вас таки можно понять — всем хочется удобного инструмента, желательно чтобы он был «сделан здесь», ибо каждый знает, как сделать лучше (и, конечно, лучше будет для всех). Но часто ли есть возможность использовать те средства, которые хочется? Увы, нечасто и если заказчик говорит — «ТМ», значит будет ему ТМ. После этого стыдиться и оправдываться? Зачем? Есть задача, задача решена в срок, все работает — какие оправдания, какой стыд? И несмотря на то, что я с большой осторожностью смотрю на людей, которые вместо того, чтобы взять в руки микроскоп и забить им чертов гвоздь, начинают недельные поиски подходящего по размеру молотка, могу лишь пожелать продолжения этого цикла статей, ибо любопытно.
                    • +2
                      Про «ибо каждый знает, как сделать лучше (и, конечно, лучше будет для всех)» — тут в точку, есть такой грешок, главное чтобы он не перешел в манию, а то тут граница порой достаточно тонкая и можно незаметно оказаться в позиции «вы все идиоты, один я Д`Артаньян». :) Главное, чтобы как раз успевали до этого момента опустить на землю другие пользователи системы, стараюсь не улетать далеко и пока вроде получается. Уже не один пользователь заметил, что многие моменты у меня сделаны лучше и даже вызывают привыкание. Меня один мой сотрудник теперь называет самым главным лентяем, потому что я в своей системе делаю так, что по многим вопросам не приходится работать, потому что система делает это за тебя и там, где раньше приходилось тратить дни и недели на ковыряние в инструменталке и отладке в рантаймах на полигоне — теперь уходят считанные минуты, или вообще секунды на выполнение поставленной задачи.
                      А по поводу «ТМ не так уж плох» — скажу так: у нас в России как всегда, идея и задумка — очень классная, а вот реализация — как обычно… Свою систему я построил полностью по образу и подобию архитектуры ТМ, я считаю ее достаточно удобной и гибкой для построения проектов. Что-то из идей взял от 5-й, а технологию разработки дерева проекта от 6-й., у меня даже среда разработчика чем-то напоминает редактор 6-ки, вот только функции для всего этого сделал так, как я их вижу и как считаю удобным с точки зрения именно разработчика конечных систем, а не маркетинга для профанаций с целью впарить. У меня большинство пользователей без особых проблем пересаживаются на мою систему с ТМ и тут же начинают работать без изучения с нуля. Так что, неплох, да, как архитектура и платформа — очень неплох, начинка малость страдает и реализация подкачала.
                      Только забегая вперед сразу поясню, что я не брал исходников ТМ, доступа к ним у меня никогда не было, моя система написана полностью с нуля мной самим (причем даже на другом языке программирования в отличии от ТМ).
        • 0
          Неее, EPR — это АСУ П, у меня про АСУ ТП… Малость ниже уровнем.
        • 0
          И каков итог перехода на XAML-то? Заглотили книгу в 100 страниц это понятно… порадовались что так же мыслите… а где результат-то?
          Приложение теперь не 60% ЦПУ кушает или как?
          • 0
            Переход в процессе. Вам в каком выражении его лучше представлять? Для меня, как разработчика ПО, а не ППО, он уже очевиден в скорости разработки системы (банального кодинга) и удобства оперирования достаточно адекватным визуальным интерфейсом с наименьшей нагрузкой на ЦПУ (да, кушает теперь не 60%, а в десятки раз меньше) и в богатом выборе сервисов и архитекутры, которые на GDI+ мне пришлось с нуля разработать и продумать, когда движок писал свой. С точки зрения разработки ППО — теперь я могу разделять труд дизайнера и автоматчика, потому как считаю, что юзабилити — это сугубо специализированная область, которой не всякий инженер владеет. У меня вот в школе по рисованию всегда тройка была. И не всякий художник может грамотно разработать логику управления процессом. Разделение труда — тоже искусство, и если грамотно построить этот процесс и дать инструмент, который адекватно объединит разные области в единый продукт — на выходе получится гораздо приятный и адекватный результат, чем там, где ты и жнец и кузнец и на дуде игрец… ;)
          • 0
            Спасибо за статью, интересно читать, как и предыдущие.
            Просто заинтересовало, чем конкретно pdf не устраивает для ТЗ? Мне почему-то всегда казалось, что это «круто», сверстать для пдф, как-то презентабельнее, чем doc :-) Или какие еще альтернативы?
            • +2
              Засада в том, что в нём не всегда присутствует исходный текст — вот как у автора. А это получается смотри в одно окошко и вбивай полсотни страниц табличек ручками в другом. Или сканируй, что тоже далеко не всегда выход, особенно с техническими текстами. А ещё бывает туда просто картинки вставляют, из других источников. В общем, не в самом pdf, имхо, дело, а в отношении. Презентация должна быть презентацией, а исходные данные желательно получать в удобном для обработки и использования формате.
            • 0
              Объясните, а почему вы при старте разработки не попробовали воспользоваться OpenScada?

              oscada.org/ru/

              Может быть, не имело смысла огород городить?
              • 0
                Я смотрел этот проект, но следующие пункты для меня оказались критичными:
                1) Я не работаю под Lnux и в ближайшем будущем вероятность его применения у меня пока около 0%. Все мои текущие проекты ориентированы только на платформу MS Windows и большинство заказчиков не будут переходить на Linux.
                2) Я не пишу на Си, я не программист такого уровня, да вообще был не программист. Платформа .Net для меня оказалась идеальной платформой, простота ее освоения и объектно-ориентированность мне пришлись очень кстати, я даже сейчас не люблю говорить, что я программирую на C#, мне больше импонирует: я на нем разговариваю с ПК.
              • 0
                Да, всё знакомо. Я делал практически то же самое по функционалу. С WPF советую работать очень осторожно. Нужно внимательно следить за виртуализацией GUI. Ускоренный-то он ускоренный, да не совсем, в чем вы могли убедиться во время прокрутки или переключения закладок. На растеризацю уходит очень много процессорного времени, когда «сцена» состоит из большого количества объектов Visual. Что бы добиться приемлемой производительности придется хорошенько постараться.

                Может когда-нибудь накатаю обзор нашей системы для сравнения, пока она не выпущена — типа коммерческая тайна и всё такое.
                • 0
                  Да, в книжках уже почитал про упор на то, чтобы не увлекаться объектами типа Visual там, где можно обойтись обычной геометрией, поэтому этот момент сейчас прорабатывать буду, когда графикой займусь.
                • 0
                  Всем доброго времени суток. Случайно из Томска никого нет?
                  Сейчас нахожусь под Томском в рабочей командировке по поводу внедрения крупного проекта на 3000 точек на базе своей скады. Систему успешно запустил и уже на следующей неделе, примерно в середине, планирую 1 день быть в самом Томске. Если кому интересно — можно было бы встретиться очно, побеседовать, заодно мог бы показать и рассказать о системе вживую. :)
                  Если что — пишите, о месте и времени договоримся.
                  • 0
                    Приглашаю всех на стенд нашей компании на предстоящей выставке «ПТА-2014», которая состоится с 7 по 9 октября 2014 года в Москве по адресу: ЦВК «Экспоцентр», павильон 5.
                    На стенде будет демонстрироваться система SCADA+. Можно будет пообщаться с разработчиками и задать свои вопросы, а также попробовать систему в работе.
                    www.pta-expo.ru/news/020914.htm

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

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.