Хочешь создать свой проект в «железе», который перевернет мир с ног на голову? Или автоматизировать управление светом в коридоре. При этом ты не специалист в программировании микроконтроллеров, но разобрался с arduino и тем как моргать её светодиодами и только узнал о полевых транзисторах, симисторах, 1-Wire. Теперь хочешь управлять всем этим хозяйством и предоставить доступ через интернет и хранить данные в облаке.



Или ты дружишь с паяльником, гуру программирования ПЛК, снифишь PDU в modbus. Но компьютер с Windows и SCADA слишком дорог для проекта или не подходит почему-то еще… И хочется запускать программу на одноплатном компьютере Raspberry PI с доступом к ее переферии GPIO, I2C.

Методы визуального программирования


Используя готовые компоненты и библиотеки, можно разрабатывать программу используя языки визуального программирования. К счастью программистов и к несчастью пользователей всех таких систем, настает такой момент, когда нужна функциональность, которая не поддерживается «из коробки». Программы не генерируют другие программы для нашего сложного мира лучше чем программисты и у нас пока есть работа. Перечислим как же можно визуально программировать типовые задачи:

Блок-схемы/Дружелюбный русский алгоритмический язык, который обеспечивает наглядность(ДРАКОН)/Р-схемы и т.п. Что я отлично запомнил по программированию в школе и первых курсах института, так это блок-схемы. Рисование блок-схем подходят для занятий студентов, чтобы как и у солдат, все свободное время было занято работой. Еще одно их применение — обучение программированию на листе бумаге. Ну и наконец, кто-то работает и рисует такие диаграммы, чтобы сдать госпроект по ЕСПД/ГОСТ. Посочувствуем им!

CASE инструментарий — сотни их за заоблачные деньги и часто с сомнительной пользой. Особенно много таких систем используется архитекторами ПО и баз данных.

Диаграмма состояний UML из которой с помощью кодогенерации можно получить заготовку или готовую управляющую программу. Эта диаграмма является примером автоматного программирования. И отлично подходит для проектирования компиляторов, многих электронных устройств и любых задач и модулей систем в которых есть сущности со сложным поведением.

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

Среда визуального программирования LabVIEW позволяет делать достаточно сложные системы визуально и тесно связана с аппаратным обеспечением National Instruments. Понравился пример того как AndreyDmitriev в комментариях на хабре реализовали задачу в визуальном редакторе для сравнения сложности с Delphi решением и обзор LabVIEW. В эту же категорию попадает и Simulink для Matlab, как подсказали в комментариях.

Reactive Blocks


В этой же статье про Reactive Blocks используется модифицированная UML диаграмма деятельности, которая приспособлена под компоненты проекта и из которой генерируется код. Разработчики сделали plugin для Eclipse со своей моделью, анализатором схем и событиями компонент.

Проект доступен бесплатно для open source проектов, с вполне логичным ограничением. Все созданные вами в IDE Building Blocks станут доступными всем под open source лицензией.

Идеология Reactive Blocks


Это визуальное конструирование приложения из готовых существующих кирпичиков — building block, которые скрывают всю сложность взаимодействия с «железом» и облачными сервисами.

Конечно, сложные алгоритмы лучше писать как java код, поэтому графическая диаграмма и код поддерживаются в синхронизированном состоянии автоматически. Это извечная мечта компонентного проектирования, когда компоненты пишут программисты, а используют их пользователи-эксперты в своей области.

Так же как и не стоит делать из диаграммы — спагетти диаграмму из сотни и тысяч элементов. В этом случае можно поддиаграмму оформить в виде точно такого компонента-строительного блока. В случае open source решения, вы публикуете свой блок, чтобы сообщество также могло использовать его в своих проектах.

Есть возможность автоматически упаковать свое приложение в пакет (OSGI bundle) для платформы Eclipse Kura. Тогда возможен перезапуск приложения без перезапуска контейнера, доступна консоль для администрирования, а также множество сервисов этой IoT платформы и вся мощь существующих компонентов и запускать это на Raspberry PI или Beagleboard Black.

Установка Reactive Blocks


Есть вариант скачать специальную сборку eclipse+Reactive Blocks сразу готовую к запуску со страницы для Windows, Mac OS X или Linux. Другой вариант, если у вас есть установленный Eclipse Neon(4.6)/Mars(4.5)/Luna(4.4)/Kepler(4.3) — нужно указать Update-Site и установить плагин.

В любом случае для сборок Linux, основанных на debian, нужно установить пакет libwebkitgtk-1.0 перед запуском среды разработки:

sudo apt install libwebkitgtk-1.0

Для использования в готовой сборке JDK, отличной от доступной в системе по-умолчанию, нужно добавить строчки в файл reactiveblocks.ini:

-vm
PATH_TO_YOUR_JDK/bin/java

Знакомство с Reactive Blocks


Для доступа к серверу компонент пришлось пройти авторизацию и аутентификацию с помощью Google аккаунта.

Написал вопросы по почте и к чести их инженеров и менеджмента, мне устроили мастер-класс один на один по google hangout с видео конференцией, скринкастом IDE и разбором простого примера. Их ведущий разработчик оказался инженером из аэрокосмической отрасли и любит в свободное время заниматься авиамоделирование и проектирует автопилот.

Мне показался очень интересным пример сигнализации на RaspberryPI с использованием акселерометра.



Поигравшись с разными примерами, посмотрев на содержимое Building Blocks под капотом. Особенно интересно было обнаружить там уже знакомую мне библиотеку OpenIMAJ.

Лично для себя я не нашел преимуществ Reactive Blocks по сравнению с разработкой под Apache Camel с его компонентами rhiot и возможностями визуализации. Про что скоро опубликую пост и даже рабочий пример уже готов! В своей публикации на хабре Управляем автоматом на Groovy/Java. Как ЧПУ станку в домашней мастерской не превратиться в мульт героев «двое из ларца» я использовал Apache Camel для управлением ЧПУ станком.

Попытка скрестить BeagleBoard Black GPIO с Reactive Blocks была безуспешной.
Так как библиотека для работы с GPIO SilverThings/bulldog не смогла работать в режиме обработки прерывания. Можно конечно опрашивать порт ввода в цикле — но это как-то не правильно. Завел багрепорт #96 для этой библиотеки.

Встроенные в процессор BeagleBoard Black RPU подходят для real time задач где не место java с ее GC STW паузами.

Для java программистов, в отличии от инженеров по электронике, возникают мысли по практическому использованию Bitreactive IDE в сложных проектах и надо разбираться:

  • как происходит одновременная работа над одной диаграммой нескольких человек;
  • как происходит рефакторинг проекта с множеством диаграмм;
  • зачем было делать свой сервер для хранения компонент, когда уже есть maven совместимые репозитарии;
  • как увидеть diff для разных версий диаграммы?
  • как разрабатывать тесты и делать mock для компонент. Вроде как есть генерация для jUnit, но надо углубляться в практику тестирование реальных приложений.


Выводы


Вместо изучения языков программирования вам придется выучить его нотацию схем, компоненты и средство разработки. Нужно ли это программисту?

Это решение больше подойдет для инженеров не специалистов в ПО, которые не хотят вникать в тонкости программирования на java, но хотят использовать всю мощь существующих компонент для связи с «облачными» сервисами IoT, мультимедиа и работы с java библиотеками, обернутыми в building block.
Поделиться с друзьями
-->

Комментарии (17)


  1. zillant
    10.11.2016 15:35
    +1

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


    1. igor_suhorukov
      10.11.2016 15:35

      Да, можно. Сейчас дополню статью. Спасибо!


  1. shadson
    11.11.2016 10:11
    +1

    Велосипед — это, конечно, хорошо, но иногда стоит попробовать поискать открытый бесплатный вариант.
    www.proview.se — эта штука реально работает на промышленных объектах.


    1. igor_suhorukov
      11.11.2016 10:22

      Спасибо! Интересно будет сравнить по функциональности как например Proview on Raspberry PI и модули ввода-вывода.


  1. aso
    11.11.2016 10:11

    Проблема визуального программирования (скажем, в Симулинке) — сложности с разделением и повторным использованием кода.
    Ну т.е. достаточно легко нарисовать довольно крупное приложение из одной модели — а потом героически воевать с его сопровождением. При этом модель «идеологически» предполагается уникальной сущностью, в противоположность функции в программировании — и, плюс, поощряется использование глобальных переменных.
    Ну и куча всяких нюансов — типа «что проще» — ползать по множеству вложенных менюшек, выискивая чекбоксы, настривающие хитрым образов каждый элемент — или тупо и просто написать «far uint» там, где вам это нужно.
    Ну и, опять же — постоянные поиски того, «как же сделать хитрую фичу, которую я тексте я набью за пол-секунды» — тоже слегка напрягает.
    (Пользуюсь симулинком регулярно.)


    1. igor_suhorukov
      11.11.2016 10:41

      В bitreactive переиспользование решено за счет создания Building Block и размещения их в репозитарий. В том числе для диаграммы можно описать ее вводы-выводы и сохранить как Building Block.

      По поводу удобства и культуры разработки с вами, наверное, сможет поспорить AndreyDmitriev.

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


      1. aso
        11.11.2016 15:23

        Поспорить можно о чём угодно — но проблема в том, что великай «Тойота», кажется, имеет серьёзные проблемы в своём ПО — которое, как я слышал — разрабатывает именно в Симулинке.


        1. igor_suhorukov
          11.11.2016 15:50

          Так мне тоже ближе текстовые ЯВУ и не скрываю. Кому что удобнее, проблемы бывают при любом подходе.


    1. AndreyDmitriev
      11.11.2016 13:38
      +1

      Ну тут скорее не «Проблема визуального программирования», а просто уровень владения инструментом и область применимости самого инструмента к какой-то конкретной задаче.
      Вообще «кривая изучения» визуального языка (если взять тот же LabVIEW как пример) на мой взгляд несколько отличается от «кривой изучения» языка текстового. В графическом языке довольно низкий «порог вхождения», но вот затем для уверенной разработки сложных систем потребуется положить куда как больше времени нежели в текстовом языке. Мне думается, это связано с тем, что текстовый язык несколько «беднее» графического в синтаксическом смысле — вначале нужно изучить конструкции и сравнительно небольшое количество ключевых слов, а затем разработка идёт на паттернах проектирования да библиотеках.
      Это всё равно что разница между китайским и английским — в одном случае иероглифы, коих тысячи, а в другом — всего 26 букв. Вероятно уже на первом уроке мы сможем написать довольно длинную фразу всего несколькими иероглифами, но затем последует довольно утомительный период изучения.
      У меня, кстати, обратная ситуация — я сейчас изучаю C#, и цель — довести владение до уровня профи, и вот там, где я в несколько щелчков могу набросать наглядный код на LabVIEW (где у меня шестнадцать лет опыта), в текстовом языке я пока что «программирую», порой не вылезая из гугля, stackoverflow и Албахари. Впрочем я ещё не прошёл ту точку, когда удобство обоих инструментов сравняется — для меня пока что LabVIEW заметно комфортнее.


      1. aso
        11.11.2016 15:29

        «Кривая обучения» в визуально программировании действительно напоминает таковую, скажем, для Бейсика — начать легко, а потом…
        Я, во всяком случае — могу точно сказать, что многие вещи, которые в «текстовых» языках решаются элементарно — например, экспорт переменных — в Симулинке решаются с заметными затратами (опишите каждую из десятка переменных).
        Плюс «приделывание» ООП к оному — выглядит весьма непростой задачей.
        А пордразумеваемая идеология «Один проект — одна модель» качеству кода отнюдь не способствует.
        Так что мне ближе к душе C++, нежели чем «квадратики».
        Вопрос, впрочем, может быть связан с областью определения — LabVIEW под свои задачи может быть и удобнее.


  1. golf2109
    11.11.2016 12:47

    а в чем преимущество данной системы например перед LabVIEW?


    1. igor_suhorukov
      11.11.2016 12:49

      В готовых компонентах для IoT, интеграции с облачными сервисами и аппаратным обеспечением сторонних производителей


      1. golf2109
        11.11.2016 12:53

        а где можно посмотреть это список компонентов и поддерживаемого оборудования?


        1. igor_suhorukov
          11.11.2016 14:07

          Библиотеки доступны здесь. Из самой среды разработки в eclipse можно найти доступные блоки.

          Libraries totally:
          533
          Available blocks:
          2388
          Users:
          2525


          Документация доступна здесь. Там же ссылки на реализованные проекты и туториалы.

          Из аппаратных все что поддерживает eclipse kura плюс то что поддерживается библиотеками. И кое что от партнеров по интеграции, например Bitreactive AS: NXP Partner


        1. igor_suhorukov
          14.11.2016 10:09

          Нашел пример еще пример поддерживаемого оборудования EDCK 4001 Everyware Device Cloud от Eurotech


    1. AndreyDmitriev
      11.11.2016 14:27
      +1

      Эта система несколько отличается от «чистого» LabVIEW в том смысле, что тут скорее строится машина состояний, причём на довольно высоком уровне, а LabVIEW — это по сути «классические» низкоуровневые конструкции типа циклов for, while, блоков switch, работы с массивами и т.д., обёрнутые в графическое представление и завязанные на data flow принцип. Идеологически ближе к этой системе NI LabVIEW Statechart Module — это такая надстройка над LabVIEW, но там нет такого количества «готовых» блоков.


      1. igor_suhorukov
        11.11.2016 14:30

        Интересное замечание! Концепция потоков данных используется и в bitreactive. Это позволяет проще писать параллельный код в отличии от императивного подхода.

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