Основные принципы организации работы с PLE

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

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

Результаты выполненной работы должны быть сохранены (в виде текстов, схем, аудио и видео роликов и т.п) в персональной базе знаний в привязке к исходным материалам и в дальнейшем использоваться в учебной и профессиональной деятельности. Предполагается, что пользователь PLE периодически обращается к ранее созданным базам знаний, дополняя и корректируя их.

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

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

3. Степень освоения учебного материала оценивается как самим пользователем с помощью специальных  тестов для самопроверки  (с автоматической проверкой ответов на вопросы), так и  преподавателями или тьюторами в процессе обсуждения результатов выполненных учеником заданий с применением встроенных в документы диалоговых окон. В процессе обсуждения ученик совершенствует свои ответы и другие результаты выполнения заданий. Целью обсуждения является полное усвоение обучающимся образовательной информации.  Степень освоения информации оценивается преподавателем с опорой на таксономии образовательных целей, в соответствии с которыми готовятся задания. 

4. Образовательные материалы должны иметь несколько вариантов, ориентированных на разные группы обучающихся.

5. Адаптация материалов к возможностям и предпочтениям обучающегося происходит за счет выбора обучающимся:

* темпа  и удобного времени обучения,

* уровня сложности изучаемого материала

* использования материалов с различными стилями подачи  

* обсуждения учащимся образовательных материалов и результатов выполнения заданий с преподавателем/тьютором и друзьями (с помощью диалоговых окон, встраиваемых в контент)

* использования алгоритмов программируемого обучения, которые формируются с помощью ссылок на документы, которые следует изучить при том или ином результате автоматического  тестирования 

6.Образовательный процесс должен содержать этапы практической работы с реальными физическими объектами в рамках практических и лабораторных работ.  Для выполнения такого рода работ в PLE предусмотрены инструменты работы с объектами интернета вещей, позволяющие строить многокомпонентные системы, включающие блоки датчиков и актуаторов. Пользователь имеет возможность запрограммировать их взаимодействие, а также анализировать генерируемые системой данные. Результаты выполнения практических работ должны фиксироваться  обучающимся  в его персональной базе знаний для оценки и обсуждения с преподавателем и использования в учебной и профессиональной деятельности.

7. В ходе обучения может быть активно использована проектная деятельность, организуемая в рамках PLE. Проекты могут быть как учебными, подразумевающими следование заранее заданным алгоритмам их выполнения, так и творческими, подразумевающими высокую степень самостоятельности обучающегося.

8. Обучение должно происходить под кураторством преподавателей и тьюторов, направляющих, корректирующих и проверяющих движение обучающегося в образовательном материале.

9. PLE является открытой средой, что подразумевает активность пользователя в поисках внешних источников информации. Задания, предлагаемые преподавателями обязательно должны содержать пункты, подразумевающие поиск информации в открытых источниках, ее систематизацию и привязку к материалу, даваемому преподавателем.

PLE имеет в своем составе мешап-редакторы, позволяющие в одном документе собирать информацию из разных источников, например, в виде ссылок, встроенных с видеохостингов роликов, цитат с различных ресурсов, iFraim-ов и т.п. Все собранные материалы в документе могут быть прокомментированы и дополнены собственными мыслями обучающегося.

10. Преподаватель развивает свой образовательный материал на основе взаимодействия со студентами, повышения своего профессионального уровня, знакомства с новостями по теме материала. Все изменения образовательного материала фиксируются преподавателями в их персональных базах знаний.

Общие рекомендации по подготовке образовательных материалов

Целью использования образовательной среды ECOIMPACT является полное усвоение знаний обучающимся с контролем достижения этого результата преподавателем. 

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

Обучающийся изучает большую часть предоставляемого ему учебного материала самостоятельно в удобном ему темпе и в удобное время. Оценка работы преподавателями и тьюторами происходит с использованием специального инструмента - диалогового окна, привязываемого к документам, в которых отражены результаты работы. Обсуждение может происходить как в реальном времени, так и в режиме с отложенными вопросами-ответами (весь диалог сохраняется).  Часть материала (например, обзорная лекция по курсу, лекция, посвященная последним достижениям в изучаемой области, а также лекции, позволяющие направлять процесс обучения) может быть дана в виде очных лекций, семинаров, консультаций, вкбинаров и т.п.

Учебные материалы должны быть построены таким образом, чтобы стимулировать обучающегося к следующим активным действиям:

* прохождению тестов для самопроверки усвоения изучаемого материала

* выполнению заданий, подготовленных преподавателями и оформленных в виде шаблонов-инструкций

* поиску в разных источниках необходимой для выполнения заданий информации

* обсуждению результатов выполнения заданий с преподавателями и тьюторами

* выполнению практических, лабораторных и проектных работ

Образовательные материалы, подготовленные преподавателями и помогающими им тьюторами, должны быть оформлены в виде курсов лекций.  Курс  оформляется как база знаний, разбитая на категории-лекции.

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

К обязательным материалам относятся:

* стандартная инструкция к лекции, описывающая последовательность действий обучающегося
* текст лекции (содержит основную информацию, которую должен освоить обучающийся)
* презентация (опорный конспект) к лекции (предназначена для интеграции знаний и быстрого освежения их в памяти; при подготовке презентации-опорного конспекта можно воспользоваться рекомендациями В. Ф. Шаталова см. https://www.nkj.ru/archive/articles/12969/ 
* набор  тестов с автоматической проверкой для всех выделенных по смыслу частей лекции и всей лекции в целом (предназначены для самопроверки обучающимся своих знаний и организации процесса программируемого обучения)
* шаблон для самостоятельной работы (предназначен для тренировки освоения материала обучающимся по направлениям, задаваемым таксономиями образовательных целей и проверки (с участием преподавателей и тьюторов) достижения этих целей (В качестве таксономий образовательных целей рекомендуются таксономия Андерсона и таксономия Блума)

* описания практических, лабораторных и проектных работ по теме лекции

* шаблоны для представления результатов практических, лабораторных и проектных работ (могут быть совмещены с описаниями этих работ)

* тезаурус к лекции

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

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

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

К общим для всех лекций материалам курса относятся:

- общая инструкция по работе с курсом

- тезаурус курса

- навигационный документ по курсу (должен быть добавлен в категорию каждой лекции)

- материалы обзорного характера по тематике курса

Освоение материала обучающимся проходит по следующей схеме:

Действия (обязанности) обучающегося

Если обучающийся впервые пользуется персональной образовательной средой ECOIMPACT, то перед началом работы он должен познакомиться с рекомендациями по ее использованию и выполнить тренировочные задания. Рекомендации и тренировочные задания должны быть даны преподавателем или тьютором в ходе специального очного инструктажа или в ходе вебинара.

Далее обучающийся:

1. Знакомится с инструкцией, содержащей рекомендации по освоению материала курса. 

2. Прослушивает и конспектирует обзорнную лекцию по курсу очно или в ходе вебинара (если она предусмотрена).  Оформляет конспект обзорной лекции, используя шаблон конспекта. Размещает конспект обзорной лекции в своем аккаунте.

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

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

4. Сохраняет текст лекции, презентацию и шаблон для самостоятельной работы в свой персональный аккаунт, предварительно создав соответствующую категорию, в которой размещаются скопированные материалы. Все сделанные комментарии при этом сохранятся.

Обучающийся (как и преподаватель) в процессе работы над материалом лекции может (и должен) использовать как вэб-интерфейс, так и приложение для компьютера. Функции приложения и вэб-интерфейса не дублируют друг друга полностью.

5. Внимательно прочитывает текст лекции (без прохождения тестов и выполнения заданий к лекции), при необходимости, делая в тексте лекции дополнительные  комментарии  (комментарии можно рассматривать как миниконспекты частей лекции, которые позволяют быстро вспомнить материал смыслового блока). Комментарии  возможно делать и вне блоков комментариев,  в режиме редактирования документа.

6. Прочитывает текст лекции, выполняя тесты для самопроверки, включенные в текст лекции после смысловых блоков (работает в режиме программируемого обучения). При необходимости, правит комментарии к разделам лекции. См. документ "Тесты и вопросы".

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

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

9. Добавляет к заполненному шаблону практической, лабораторной и проектной работы  окно диалога, добавляет в свойствах этого документа аккаунты пользователей (преподавателя и тьютора), которые могут просматривать и комментировать результаты выполненной работы,  и отсылает ссылку на заполненный шаблон своему преподавателю или/и тьютору. В качестве тьютора может выступать студент (аспирант), ранее успешно изучивший курс или другой человек, назначенный преподавателем.

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

10. Заполняет шаблон для самостоятельной работы, выполняя задания, содержащиеся в шаблоне (при необходимости, ставя ссылки на конспекты и заполненные шаблоны по практическим, лабораторным и проектным работам). 

11. Добавляет к заполненному шаблону окно диалога, добавляет в свойствах документа аккаунты пользователей (преподавателя и тьютора), которые могут просматривать и комментировать документ,  и отсылает ссылку на заполненный шаблон своему преподавателю или/и тьютору. В качестве тьютора может выступать студент (аспирант), ранее успешно изучивший курс или другой человек, назначенный преподавателем.

12. После получения в окне диалога замечаний и рекомендаций по выполненным заданиям корректирует отчеты по заданиям в шаблоне  до тех пор, пока преподаватель не решит, что работа выполнена правильно.

Все лекции (помимо обзорной), по которым отсутствуют заранее подготовленные материалы, прослушиваются обучающимся в учебной аудитории или в ходе вебинара и оформляются им в виде конспекта с использованием соответствующего шаблона. Готовые конспекты размещаются  вместе с другими лекциями в соответстующих категориях в персональных аккаунтах в персональной базе знаний по теме курса. Конспекты лекций обсуждаются с преподавателями с использованием диалоговых окон наравне с шаблонами для самостоятельной работы.

Действия (обязанности) преподавателя и/или персонального тьютора обучающегося

1. Обучают в ходе тренинга работе с персональной образовательной средой

2. Задают "точку входа в курс" - показывают, где размещены учебные материалы.

3. Сообщают обучающимся свои аккаунты, с которых они будет оставлять комментарии к заполненным шаблонам и другим материалам обучающихся. Если за разные лекции курса отвечают разные преподаватели, то должна быть создана таблица, устанавливающая связь между разделом курса, преподавателем и именем его аккаунта в системе. Желательно, чтобы один и тот же персональный тьютор обучающегося сопровождал его по всем лекциям.Таблица может быть размещена в базе знаний курса, данные о преподавателе и тьюторах должны быть подублированы в контенте курса после его названия.

4. Под каждого пользователя в своем аккаунте заводят отдельную категорию, в которой будут размещаться ссылки на присланные работы обучающегося, отдельный (не привязанный к конкретному документу) чат с обучающимся и, опционально, другие документы, например, характеристика обучающегося.

5. Проверяют  заполненные шаблоны, оценивают выполненную работу и дают рекомендации по улучшению ее результатов, используя окно диалога, привязанное к шаблону. Обсуждение продолжается до тех пор, пока результаты работы обучающегося не удовлетворят проверяющих (проверяющие должны убедиться, что обучающийся полностью усвоил материал), после чего преподаватель может выставить общую оценку работе, обращая внимание на задания, требующие творческого подхода. 

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

Освоение базовых навыков по работе с PLE

Базовыми навыками являются:

1. Умение регистрироваться и авторизоваться на сайте PLE.

2. Умение пользоваться веб-интерфейсом PLE, а именно:

- умение создавать персональные системы категорий с описанием каждой категории метаинформацией

- умение создавать документы с привязкой их к конкретным категориям и описанием метаинформацией

- умение создавать и  редактировать контент документов с помощью инструментов веб-редактора

3. Умение устанавливать на своем компьютере специального приложения и авторизоваться в нем

4. Умение пользоваться приложением для PLE, а именно:

- умение создавать персональные системы категорий с описанием каждой категории метаинформацией

- умение создавать документы с привязкой их к конкретным категориям и описанием метаинформацией

- умение создавать и  редактировать контент доокументов с помощью инструментов редактора приложения

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

Начинать освоение базовых навыков работы нужно с веб-интерфейса. 

Рекомендуется следующая последовательность шагов:

1. Знакомство с публичной частью сервиса: переход по разделам и подразделам сервиса (с открыванием и пролистыванием документов). Поиск тематических  материалов с использованием обычного и расширенного вариантов поиска.

Просмотр документации, посвященной сервису (с целью составления общего представления о его назначении и возможностях).

2. Регистрация аккаунта в сервисе

3. Авторизация в сервисе

3. Переход на страницу "Мои документы"

4. Создание нескольких категорий с подкатегориями

5. Создание документа и настройка его свойств. Сохранение свойств документа и самого документа.

6. Наполнение документа мультимедийным контентом.

7. Поиск, редактирование и удаление документа.

Для общей ориентации в PLE полезно знать, что в PLE используются документы нескольких различных типов:

* документ общего типа
* интернет-закладка
* шаблон документа
* математические данные
* вопрос
* тест
* навигационный документ 
* приборная панель
Все документы являются HTML- страницами. Документ общего типа  является наиболее используемым типом документа. В контенте этого документа могут присутствовать:
* текст
* изображения
* интернет-ссылки
* вставки видео и аудио контента
* интерактивные географические карты 
* i-fram-ы
и ряд других специальных объектов.

Для организации документов используется несколько взаимодополняющих друг друга способов:
 

1. Описание документов с помощью метаинформации (атрибутов документов). Каждый документ может быть описан с помощью:
* названия
* набора ключевых слов
* хэштега (ключевого слова особого типа)
* аннотации
* географических координат
* временных меток
* меток приватного или публичного доступа к документу
* метки языка документа

Метаинформация позволяет быстро находить документы определенного типа и смыслового  содержания, а также иметь некоторое общее  представление  в контенте документов, не открывая их (удобно при работе со списками и иными массовыми отображениями групп документов). 

2. Иерархическая организация в виде дерева категорий и подкатегорий. В качестве особого типа категорий выделяются т.н. "базы знаний". Пользователь может объявить категорию базой знаний, если считает, что она хорошо   описывает некоторую тематику. Для баз знаний, как для выделенных категорий, в сервисе предусмотрены отдельные интерфейсы поиска и группировки. Категории описываются метаинформацией аналогино описанию документов (категориям, в отличае от документов не могут быть приписаны географические координаты и временные метки). 

Любой документ может быть отнесн к любому набору категорий. Изменение контента документа и описывающей  его метаинформации будет отражаться во всех категориях одновременно.

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

Поиск документов также может осуществляться с помощью движения по иерархической системе категорий. Часто оптимальным является поиск категории, соответствующей требуемой теме, с последующим анализом находящихся в ней документов.  

Для структурирования информации также может использоваться особый тип документа - навигационный документ. Навигационный документ может быть построен в виде оглавления, аннотированного оглавления или  или в даже в виде подробного описания, в которых содержутся ссылки на другие документы. Примером навигационного документа является навигационный документ по базе знаний ECOIMPACT  https://ecoimpact-ple.com/en/documents/217.html.  Навигационные документы, размещенные в категории автоматически показываются в контексте этих категорий и документов этих категорий в вэб-интерфейсе.

Для активной работы с информацией (контентом документов) в сервисе реализован ряд инструментов, позволяющих пользователю размечать контент, выделяя в нем важную информацию, комментарии и  т.н. "идеи" - части документа, объединенные общей темой (идееей). Пользователь  может не только видеть выделенные визуально части документа, но и автоматически собирать их в отдельные, т.н. "дочерние" документы, привязанные к родительскому документу.  Дочерние документы также могут быть полезны для хранения различных версий родительского документа, для его комментирования и анализа и т.п.  Комментирование и анализ документа могут производится пользователем с применение заранее заготовленных схем, организующих этот процесс в виде набора вопросов, схем, последовательности действий и т.п, которые могут быть записаны в особый тип документа - т.н. "шаблон документа". Шаблон документа может быть применен при создании любого нового документа, в том числе и дочернего. 
Для работы с несколькими документами в сервисе предусмотрен механизм цитат - возможность выделения в разных документах частей  с сборки их в отдельный документ.

Работа с контентом документов организована с помощью нескольких редакторов с интуитивно понятными интерфейсами, встроенных как в компьютерное приложение, так и в сайт (веб-интерфейс) сервиса. Инструменты редактора приложения и вэб-интерфейса дублируются не полностью.

Рекомендации по использованию вопросов и тестов

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

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

* процент правильных ответов очень низкий,

если вы:

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

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

- если создание миниконспекта не улучшило ваши результаты, изучите весь список вопросов с неправильными ответами, открывая пояснения к вопросам и, при необходимости,  правильные ответы, поправьте миниконспекты, после чего пройдите тест еще раз

* вы ответили правильно не на все вопросы,

если вы:

- проходили тест в первый раз, вам необходимо прочитать раздел  еще раз от начала и до конца, обращая особое внимание на части раздела ответы на вопросы  по которым был даны неверно (просмотрите список неверных ответов, не открывая подсказки и сами ответы) после чего повторно пройти тест

- если вы проходили тест несколько раз, но не получили 100 процентов правильных ответов, посмотрите список вопросов, на которые были даны неправильные ответы, открывая пояснения к ним и, при необходимости,  правильные ответы, после чего пройдите тест еще раз, при необходимости воспользуйтесь подсказками в ходе прохождения теста

 
* Поздравляем! Вы правильно ответили на все вопросы теста! Переходите к следующему разделу материала.

4. Механизм автоматической проверки результатов ответа на все вопросы теста подразумевает, что тестом оценивается  понимание материала однородного по смыслу. 

5. Тест - это особый тип документа, создаваемый в вэб-редакторе (в настоящее время - это единственный способ создания теста).

6. Ссылка на тест может быть встроенна  после любой выделенной по смыслу части документа. 

7. Вместо ссылок на тест в текст документа в виде iFrame могут встраиваться вопросы, при этом логика перехода между разделами документа может быть задана в самом документе.

Рекомендации по созданию описаний (шаблонов) лабораторных работ

1. Описание лабораторной работы должно быть выполнено в формате обычного мультимедийного документа информационной системы  ECOIMPACT-PLE (или в формате документа с типом "шаблон": документы  данного формата отличаются тем, что имеют специальный механизм поиска в сервисе и могут быть многократно использованы в качестве заготовок для мультимедийных документов).

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

Предполагается, что обучающийся может сохранить описание в свой аккаунт и в дальнейшем работать с этим описанием в своем аккаунте. Инструкция по тому, что нужно сделать с документом должна быть встроена в сам   документ (ее пункты привязаны к этапам выполнения лабораторной работы). Первичное заполнение основных полей документа может быть выполнено пользователем до сохранения его в своем аккаунте (через веб-интерфейс). Для создания полей, которые можно заполнять, не заходя в редактор, нужно использовать "editable blocks", создание которых доступно в редакторе компьютерного приложения. 

3. Описание должно состоять из:
- Названия лабораторной работы
- Формулировки цели работы 
- Формулировки задач работы
- Ссылки на  лекцию курса (или иной документ), содержащей необходимые теоретические сведения по работе.

- Ссылок на документы, содержащие справочную информацию, необходимую для выполнения работы и обработки ее результатов (ссылки на эти материалы могут быть продублированы в  заданиях, возникающих по ходу выполнения работы). 
- Краткого описания выполнения лабораторной работы, дающего самое общее представление о том, что необходимо будет сделать). 
- Описания лабораторной установки, лабораторного стенда и т.п. (этот и предыдущий пункты могут быть поменяны местами и объединены)
- Пунктов  алгоритма выполнения работы (выполнение которых. собственно. и является работой). В отличие от краткого описания здесь должны быть даны подробные инструкции, позволяющие выполнить работу, не обращаясь за консультациями к преподавателю. 

После некоторых ключевых пунктов алгоритма у обучающегося должна быть возможность разместить  полученные результаты этих действий (фотографии страничек с необходимыми расчетами, фотографии собранной лабораторной установки, созданный интерфейс виртуального прибора или ссылку на него, полученные данные измерений в текстовом виде, в вид графиков и т.п)

- Заданий на обработку результатов выполненных экспериментов и формулирования выводов по работе. После каждого задания должна быть возможность разместить результаты его выполнения.
- Творческого задания по модификации лабораторной работы.
- Поля персональных комментариев к работе

4. Все описания лабораторных работ в информационной системе должны быть снабжены  метаинформацией (иметь краткое описание (2-3 предложения), быть  отнесены к конкретным лекциям (категориям), описаны ключевыми словами, в случае. если это необходимо, привязаны к карте и т.п). Метаинформация задается в свойствах документов.

5. Заполненный заполненный документ обучающийся должен снабдить Диалогом (чатом) и отослать ссылку на заполненный шаблон преподавателю для оценки и обсуждения результатов работы. Документ может оставаться приватным. Для того, чтобы преподаватель получил доступ к данному документу, в свойствах документа в поле "Collaborators" ("Пользователи") необходимо указать аккаунт (e-mail) преподавателя.

Если преподаватель считает нужным, то до непосредственного  выполнения лабораторной работы обучающемуся может быть предложен тест с автоматической проверкой на понимание конструкции лабораторной установки, а также верного порядка действий при выполнении работы.

Инструкция по созданию шаблона для самостоятельной работы

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

Концептуально, шаблон - это сборник вопросов и заданий по теме лекции, составленных таким образом, чтобы тренировать и тестировать  определенные когнитивные навыки, описываемые таксономией Андерсона. В отличие от теста с автоматической проверкой ответов заполненный обучающимся   шаблон для самостоятельной работы проверяется и комментируется преподавателем или куратором. Вопросы  и задания в шаблоне  должны располагаться в последовательности, определяемой таксономией и должны быть пронумерованы.  При необходимости пояснения вопроса или задания, в шаблоне могут использоваться изображения, таблицы, списки - все, что позволено включать в обычные документы. 
По каждому разделу  таксономии должно быть 2-3 вопроса/задания. (по первой категории можно сформулировать 4-5 вопросов/заданий).

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

Согласно таксономии Андерсона обучающийся должен (с разбивкой по категориям): 

1. ПОМНИТЬ

Способность помнить информацию может быть проверена на основе анализа способности узнавать  и припоминать. Разработчик задания для самостоятельной работы может сформулировать вопросы/задания таким  образом, чтобы проверить насколько хорошо запомнена информация.  Навыки, необходимые для запоминания и воспроизведения информации: способности определять, описывать, называть, маркировать, узнавать, воспроизводить, следовать
Можно попросить обучающегося:
* узнать (распознать)  конкретный объект (его изображение) в группе других объектов
* дать определение понятиям, введенным в лекции, для которой выполняется самостоятельная работа
* описать объект или явление
* воспроизвести последовательность действий (алгоритм работы)
* припомнить конкретные специфические детали чего-либо
(определять, описывать, называть, маркировать, узнавать, воспроизводить, следовать) 

2. ПОНИМАТЬ
Понимание – это способность формировать свои собственные представления  образовательного материала и интегрировать этот материал в свою картину мира.  Навыки, включенные в этот процесс, включают в себя интерпретацию, объяснение на примерах, классификацию, обобщение, умозаключение, сравнение и объяснение.
Разработчик задания для самостоятельной работы может попросить сформулировать главную мысль документа, перефразировать своими словами, представить информацию в графическом виде и т.п.  Также можно попросить объяснить материал лекции, представляя себе определенную категорию лиц, которым объясняешь (их кругозор, возможные предубеждения).  Привести примеры, не содержащиеся в тексте документа. Провести классификацию информации в целом, т.е. отнести ее к какой либо категории. 

4. ПРИМЕНЯТЬ
Применение, относится к использованию процедуры, освоенной в обучении в знакомой или новой ситуации. Разработчик задания для самостоятельной работы может попросить  обучающегося сформулировать задачу (гипотетическую или практическую) которую  можно решить, обладая полученной информацией. Можно попросить собрать дополнительную информацию, необходимую для применения изучаемой.

5. АНАЛИЗИРОВАТЬ
Анализ состоит из разложения знания на компоненты и осмысления отношения частей к общей структуре. Учащиеся учатся анализировать в ходе дифференциации, организации и объяснения 
Разработчик задания для самостоятельной работы может  предложить задания по выделению главных мыслей из каждой смысловой части документа. Перед выделением главных мыслей  обучающемуся необходимо разбить документ на смысловые части, описать смысловые части с помощью метаинформации - ключевых слов, привязке к категориям и т.п.

6. ОЦЕНИВАТЬ 
Оценка, находящаяся на вершине в таксономии Андерсона, является пятой из шести процессов. Она включает проверку и критику. Оценка подразумевает размещение того, что описано в документе на каких-то ценностных шкалах. Шкалы могут быть предложены разработчиком документа или определены самим обучающимся. В обоих случаях обучающийся должен как-то охарактеризовать шкалы и обосновать их выбор. Разработчик задания для самостоятельной работы может попросить обучающегося найти слабые стороны в  изучаемой концепции - подвергнуть ее критике. Дополнительно можно попросить обучающегося произвести проверку утверждений, содержащихся в документе, а также попросить собрать альтернативные мнения.

7. СОЗДАВАТЬ
Творчество, процесс, не включенный в таксономию Блума, является наивысшим компонентом в таксономии Андерсона. Этот навык подразумевает соединение уже известного для создания чего-либо нового. Для выполнения творческих заданий обучающиеся  генерируют идеи, планируют деятельность и производят. новое.
Разработчик задания для самостоятельной работы может попросить обучающегося построить из введенных  понятий, фактов, идей и т.п. новую систему или сценарий, фактически, нужно придумать интересную задачу сборки чего-то нового, базирующегося на том, что было узнано из лекции.  Можно также попросить учащегося связать текущий учебный материал с изученным ранее, например, попросив его указать возможные источники информации к текущему материалу, идеи, на которые  он опирается и связь его с другим параллельным материалом. Можно попросить обучающегося продлить в будущее процессы, тенденции и т.п. Показать развитие систем, если таковые описаны в текущем материале.

Организация проектной деятельности с помощью PLE

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

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

ECOIMPACT-PLE может с успехом использоваться именно  в качестве такого информационного пространства.

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

Учебная команда обязательно  должна иметь Лидера проекта, который либо выбирается самими участниками либо  назначается преподавателем (Куратором), курирующим проект.

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

Участники проекта формируют в PLE свои персональные  информационные пространства (базы знаний), посвященные проекту (каждый свое). Каждый участник проекта взаимодействует в рамках PLE c Лидером проекта точно также, как Лидер взаимодействует с Куратором проекта. 

Для организации всех взаимосвязанных  информационных пространств проекта должны быть выполнены следующие действия: 

1. Каждый участник проекта создает свою Базу знаний (по своему участку работ) с соответствующим названием. Лидер проекта создает Базу знаний с общим названием проекта и такими обязательными разделами (категориями), как: План и дневник проекта, Справочная информация. Также лидер проекта должен обязательно создать стартовую страницу проекта для быстрого доступа к самым актуальным материалам.

2. Каждый  участник в своей Базе  создает мультимедийный документ "Дневник  участника проекта ...", в котором (с определенной  персональной для него периодичностью) размещает отчеты по текущему состоянию работ на выделенном ему фронте.  В конце документа должен размещаться Диалог (чат). Дневник участника должен быть доступен Лидеру проекта и, если есть такой запрос, Куратору проекта. Лидер проекта на стартовой странице размещает ссылки на Дневники всех участников проекта. 

3. Каждый участник проекта создает  Базу знаний, состоящую из отдельных документов посвященную его участку работы. База знаний должна содержать как справочный контент, так и оригинальную информацию по ходу работ.  В отдельных категориях Базы знаний должны собираться:

- План и Дневник работ 

- обработанная и проанализированная справочная информация по проекту 

- необработанная информация в виде ссылок на интернет-ресурсы и иные материалы

- "сырые"  идеи по проекту в целом

- "сырые"  идеи по текущим работам

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

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

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

4. Лидер проекта  анализирует все присылаемые ему справочные и рабочие  материалы для проекта, систематизирует их,  перерабатывает и размещает в Базе знаний  проекта, доступ к которой разрешает всем участникам проекта и Куратору. Управление командой проекта - формулирование и доведение до участников проекта рекомендаций и распоряжений Лидер проекта может осуществлять либо через Диалоги, встроенные в Дневники участников либо через специальные документы с Диалогами (второй вариант удобен для относительно больших и сложных проектов).

5. Куратор проекта может вмешиваться в ход его выполнения, комментируя Дневник проекта, доступ к которому ему предоставляет лидер. В случае необходимости, каждый участник проекта может предоставить куратору непосредственный доступ к своему дневнику и запросить консультацию.

ECOIMPACT-IoT

Архитектура системы

IoT часть сервиса ECOIMPACT позволяет   создавать различные многокомпонентные  системы мониторинга и управления. По-существу, IoT часть сервиса ECOIMPACT - это конструктор, который можно применять для быстрого  построения нужных в том или ином конкретном случае технических систем. Этот конструктор включает конечные мониторинговые и исполнительные устройства, локальные сервера, организующие эти устройства на местном уровне, а также общий IoT - сервер, позволяющий объединять множество устройств  в системы глобального масштаба. Для манипулирования со всеми элементами IoT части сервиса пользователям и разработчикам доступен ряд специальных офлайн и онлайн инструментов.  Инструменты, предназначенные для пользователей, позволяют собирать  из готовых элементов сложные системы даже людям, не обладающим навыками программирования.
Важно, что системы, построенные на базе локальных серверов  конкретными пользователями могут работать полностью независимо от общего IoT-сервера и всех других частей сервиса Alterozoom, включение автономных систем  в общую сеть просто расширяет их возможности.  В качестве примера автономной системы можно привести  т.н. "Умную теплицу", в которой осуществляется мониторинг условий среды и управление системами полива, обогрева, освещения и вентиляции. Подключение таких теплиц к общему серверу позволяет организовать управление сетью теплиц на уровне их  обслуживания (своевременная доставка удобрений и ядохимикатов, своевременное выполнение ремонта, вывоз урожая и т.п.), а также сбор и анализ больших данных, позволяющих принимать решение о модификации режимов выращивания растений.

Опишем каждый  элемент IoT части  подробней.
В IoT часть входят следующие основные элементы:
1) Различные мониторинговые (сенсорные) и исполнительные устройства (устройства первого типа). Эти устройства должны быть адаптированы под работу в сервисе ECOIMPACT, т.е. обмениваться данными и командами с другими элементами сервиса, используя специальный стандартный для сервиса протокол. Разработчики устройств для их совместимости с сервисом должны руководствоваться API (ссылка).  Устройства первого типа не могут взаимодействовать с общим IoT - сервером системы, минуя локальный сервер. Устройства могут быть разработаны, например, с использованием платформы Arduino.  
 

Следует различать реальное (физическое) устройство и его представление (образ) в системе ECOIMPACT. 
Далее в зависимости от контекста под термином устройство будем понимать либо физическое устройство либо его виртуальное представление (виртуальный объект) в системе Alterozoom.

2) Локальные сервера  
Локальные сервера (компьютер с соответствующим программным обеспечением) могут взаимодействовать с устройствами, получая от них данные и передавая им команды.  Также на локальных серверах может производится обработка данных и организовываться управление устройствами.
Локальные сервера позволяют пользоватедям создавать локальные решения мониторинга и управления, которые могут работать как автономно, так и во взаимодействии с общим IoT -  сервером системы. Локальные сервера также могут быть использованы для обработки данных поступающих от устройств и осуществления управления этими устройствами.  Кроме того локальные сервера могут обмениваться данными с общим IoT-сервером системы (в сервисе поддерживается передача данных с локального сервера на общий сервер и передача команд с общего сервера на локальный сервер) и некоторыми внешними облачными сервисами.

3) Общий IoT - сервер системы (компьютер с соответствующим программным обеспечением)
Предназначен для сбора и анализа данных, поступающих через локальные сервера от устройств первого типа, а также непосредственно от устройств второго типа.  На общем сервере могут выполняться процедуры сбора и анализа больших данных, а также сервер предоставляет инструменты для удаленного мониторинга и управления различными устройствами.


3) Компьютеры с установленными на них специальными программами (клиентскими приложениями для компьютеров) 
Позволяют пользователю работать непосредственно с подключенными к ним по USB устройствамии, а также управлять локальным сервером. Кроме тогос помощью компьютерного приложения есть возможность определять, какие данные, поступающие от устройств, подключенных к локальному серверу будут переданы на общий сервер системы. 

4) Компьютеры с вэб-браузерами, позволяющими получать доступ к общему IoT-серверу системы через вэб-интерфейсы сервера

5) Мобильные устройства (смартфоны и планшетные компьютеры).
Эти устройства, по существу, являются устройствами второго типа. Мобильные устройства могут содержать как встроенные датчики, так и выполнять роль ретрансляторов данных, например, с фитнес-браслетов.

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

Общая архитектура IoT части сервиса ECOIMPACT с логическими связями между ними   показана на рис. 1.  Для связи между устройствами первого типа и локальным сервером могут использоваться как проводные, так и беспроводные каналы связи. Возможен как вариант, при котором устройства и локальный сервер находятся   в общей TCP IP сети, так и использование специальных технологий связи, при этом между устройствами и локальным сервером должен включаться специальный хаб, преобразующий форматы данных и команд. 
Компьютер с установленным на нем приложением ECOIMPACT должен находиться в одной TCP IP сети с локальным сервером.  Связь между устройством первого типа и компьютером с приложение возможна либо по сети либо через USB соединение.





Рис. 1
Локальные сервера системы и десктоп-приложения  помимо общего IoT- сервера ECOIMPACT могут взаимодействовать с внешними облачными сервисами, например с Thing Speaks, Amazon, Gougle  и т.п. 

Протокол взаимодействия с устройством

Общее описание

Документ описывает упрощенный протокол взаимодействия с устройством интернета вещей, предназначенный главным образом для организации взаимодействия с устройством со слабыми ресурсами с использованием любых каналов связи, способных передавать потоки данных (COM, TCP/IP и т. д.). Управляемое устройство может быть хабом, при этом оно объединяет несколько других устройств. В рамках данного документа предполагается, что происходит взаимодействие Устройства с неким Клиентом (в частности, им может быть сервер IoT, к которому подключено устройство).

Описание протокола

1. Каждое Устройство имеет уникальный 128-битный идентификатор (Uuid).

2. Каждое Устройство может иметь идентификатор типа (Uuid), определяемый производителем.

3. Взаимодействие происходит путем двухстороннего обмена сообщениями. Каждое сообщение — строка байт, причем в протоколе в качестве разделителей и зарезервированных элементов используются строки ascii-символов. Сообщения разделяются байтом с десятичным кодом 10 (символ перевода строки, "\n" в языке С).

4. Сообщения состоят из нескольких элементов, первый из которых называется заголовком, остальные аргументами. Элементы сообщения разделяются байтом с десятичным кодом 124 (символ "|").
   Пример сообщения:
   info|Argument 1|Argument 2|Argument 3\n

5. Для экранирования служебных символов в сообщении используется байт с десятичным кодом 92 (символ обратной косой черты "\"). Экранирование символов производится по следующим правилам:

   1. Символ "\" экранируется им же. В сообщении — "\\".

   2. Символ "|" экранируется как "\|".

   3. Символ перевода строки заменяется экранированной буквой "n" (десятичный код 110). В сообщении — "\n".

   4. Символ с кодом 0 заменяется на экранированный "0" (десятичный код 48). В сообщении — "\0".

   5. Произвольный байт данных может быть записан как \xHH, где HH — шестнадцатеричный код символа в нижнем или верхнем регистре. Пример — "\x2f". Если шестнадцатеричный код не распознан, символ игнорируется.

   6. Символ с кодом 0 служит для сигнализации о том, что Устройство перезагрузилось и его состояние было сброшено.

Базовые сообщения

1. Информационное сообщение от Устройства. Заголовок — info. Предназначено для передачи информации, не требующей специальной обработки (например, отладочная информация) и предназначенной для передачи ее человеку (разработчику или оператору). Сообщение не требует ответа. Аргументы сообщения — текстовые строки, содержащие информацию, предназначенную для прочтения человеком.

2. Запрос идентификации Устройства от Клиента. Заголовок — identify. Аргументы отсутствуют. Устройство должно в течении 5 секунд вернуть ответное сообщение с заголовком deviceinfo со следующими аргументами:
   1. Уникальный идентификатор Устройства в виде текстового шестнадцатеричного представления UUID "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}" или "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx".
   2. Человеко-читаемое название (не должно быть в формате UUID).
   3. Идентификатор типа Устройства (UUID), может отсутствовать.

3. Запрос идентификации Устройства-хаба от Клиента. Заголовок — identify. Аргументы отсутствуют. Устройство должно в течении 5 секунд вернуть ответное сообщение с заголовком deviceinfo со следующими аргументами:
   1. Специальный идентификатор "#hub".
   2. Уникальный идентификатор Устройства в виде текстового шестнадцатеричного представления UUID "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}" или "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx".
   3. Человеко-читаемое название.
   4. Идентификатор типа Устройства (UUID), может отсутствовать.

4. Запрос на перечисление подключенных к Устройству-хабу дочерних устройств от Клиента. Заголовок — identify_hub. В ответ Устройство-хаб сразу возвращает ok либо err (если Устройство не является хабом). Позже дочерние устройства, подключенные к хабу, передают сообщения deviceinfo.

5. Сообщение синхронизации от Клиента. Заголовок — sync. Предназначено для проверки состояния канала связи с Устройством. В ответ на это сообщение Устройство должно в течении 5 секунд вернуть сообщение syncr.

6. Команда от Клиента. Заголовок — call. Первый аргумент — идентификатор вызова, второй — название команды (любое кроме зарезервированных, описанных в разделе "Зарезервированные названия команд"). Остальные аргументы сообщения — аргументы команды. Если Устройство не может выполнить команду в течение 5 секунд, оно должно регулярно передавать сообщение syncс с аргументом-идентификатором вызова. Устройство по окончании выполнения команды должно вернуть сообщение с заголовком ok в случае успешного завершения или err в случае неудачи, первый аргумент этих сообщений — идентификатор вызова, далее — возвращаемые значения (для сообщения ok) или описание ошибки (для сообщения err).

7. Сообщение синхронизации команды. Заголовок — syncс. Если управляемое устройство не может выполнить команду быстрее 5 секунд, оно должно регулярно посылать сообщение syncc. Если в течение 5 секунд сообщение не пришло, команда считается невыполненной.

8. Измерение в текстовом виде от Устройства. Заголовок — meas. Аргументы сообщения: название датчика и значение в текстовом виде, каждое число в отдельном аргументе сообщения. (см. Форматы данных сенсоров)

9. Измерения в бинарном виде от Устройства. Заголовок — measb. Аргументы сообщения: название датчика, далее значение в бинарном виде, все передаваемые числа (включая временную метку) упакованы в один аргумент сообщения без разделителей. Порядок байт — от младшего к старшему. (см. Форматы данных сенсоров).

10. Измерения в бинарном виде от Устройства, закодированные в base64. Заголовок — measb64. Аргументы сообщения: название датчика, далее значение в текстовом виде, все передаваемые числа (включая временную метку) упакованы в один аргумент сообщения без разделителей, закодированный в base64. Порядок байт числа — от младшего к старшему. (см. Форматы данных сенсоров).

11. Сообщение об изменении состояния от Устройства. Сообщение — statechanged. Передается устройством, когда происходит изменение его состояния. Аргументы:
    1. Название команды или "#" (см. раздел "Состояние устройства").
    2. Номер аргумента команды (начиная с 1) или название дополнительного параметра устройства.
    3. Новое значение.

12. Широковещательный запрос на поиск устройства (для сетей ptp, поддерживающих широковещательные запросы, например, UDP запрос в локальной IP сети). Заголовок — find_device. Аргумент — имя или идентификатор устройства, идентификатор сервера, возможны дополнительные аргументы, если это необходимо для идентификации сервера. Устройство с указанным именем или адресом, принявшее сообщение, может идентифицировать сервер (по аргументам или, например, адресу отправителя в IP сети) и подключиться к нему.

Отправка сообщений устройству, находящемуся за Устройством-хабом, происходит аналогично отправке сообщений самому устройству, но к каждому сообщению добавляется в начало два аргумента: специальный идентификатор "#hub" и идентификатор целевого устройства в виде текстового шестнадцатеричного представления UUID "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx". Аналогичным образом приходят ответные сообщения: заголовок "#hub", идентификатор отправителя, дальше само сообщение. Для отправки сообщения всем устройствам за хабом используется идентификатор "#broadcast".

Уведомления от хаба:

1. Появление устройства за хабом. Заголовок — device_identified (после заголовка #hub и идентификатора отправителя. Аргумент — название устройства.
   Пример:
   #hub|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|device_identified|test1\n

2. Отключение устройства от хаба. Заголовок — device_lost.
   Пример:
   #hub|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|device_lost\n

Зарезервированные названия команд

При расширении списка зарезервированных команд в дальнейшем их названию будут начинаться с "#".

Формат описания датчиков (xml или json)

Описание датчиков представляет собой xml или json документ, которому соответствует список датчиков с атрибутами. Для каждого датчика указывается имя, отображаемое название, тип, единицы измерения (строка, например "оС", "м/с2" и т.д.) и дополнительные атрибуты. Имя сенсора уникально в пределах устройства. Тип датчика описывает формат передаваемых устройством данных и способ представления в сообщении. Форматы передаваемых значений описаны ниже в разделе Форматы данных датчиков. Описание датчиков передается между устройствами в xml или json формате, соответствующие схемы приложены в отдельных файлах sensors.xsd, sensors_simplified.xsd, sensors.json-schema, sensors_simplified.json-schema.

Примеры:

<sensors>
<sensor name="temperature" title="Temperature in celsius from 1st and 2nd thermometers" type="s_f32_d2" unit="оС">
<attributes min="-50" max="50"/>
</sensor>
<sensor><!--sensor definition--></sensor>
</sensors>

{"sensors" : [
{
"name" : "temperature",
"title" : " Temperature in celsius",
"type" : "s_f32",
"unit" : "оС",
"attributes" :
{
"min" : "-50",
"max" : "50"
}
},
{
//sensor definition
}
]}

Форматы данных датчиков

В различных форматах могут использоваться метки локального и глобального времени. Локальное время — время, измеряемое на устройстве от какой-то фиксированной точки (но не известной), например — от момента включения устройства. Глобальное время — количество миллисекунд, прошедшее с 01.01.1970г. В бинарном виде временная метка — всегда 64-битное целое число со знаком. Использование глобального времени возможно при наличии на устройстве часов реального времени. Временная метка всегда передается в начале измерения.

Строка формата датчика представляет собой набор ключей, разделенных символом "_". Ключ представляет собой набор символов, которые объединены в группы. Из каждой группы может присутствовать только один ключ.

Ключи, описывающие тип чисел в измерениях

Ключ, описывающий размерность отсчета:

Ключи, описывающие количество значений в одном измерении:

Ключи, описывающие временную метку измерения:

Примеры (название датчика — всегда test):

Формат описания интерфейса

Элементы управления устройством объединены в группы, содержащие сами элементы управления и дочерние группы. В группе может быть задано горизонтальное или вертикальное размещение элементов. Если не задано — по умолчанию по вертикали.

Для каждого элемента управления задается команда, пересылаемая устройству, человеко-читаемое название элемента, список параметров и дополнительные атрибуты. Параметры команды добавляются в порядке следования в описании.

Если параметры для элемента управления не заданы, отображается кнопка, при нажатии отправляется команда без параметров. Если задан один параметр, генерируется один элемент UI в зависимости от типа параметра, при взаимодействии с которым отправляется команда, и кнопка только при необходимости, например, для поля ввода. Если параметры заданы, но присутствует атрибут "force_button" со значением "1", генерируется набор элементов UI согласно заданному размещению, соответствующих типам параметров, и кнопка, при нажатии на которую отправляется команда. Если атрибут "force_button" отсутствует, команда генерируется автоматически при изменении состояния элементов UI. Каждый параметр команды имеет набор атрибутов, различающихся в зависимости от типа. Если присутствует атрибут "button_text", он задает текст на кнопке.

Описание элементов управления передается между устройствами в xml или json формате, соответствующие схемы приложены в отдельных файлах controls.xsd, controls_simplified.xsd, controls.json-schema, controls_simplified.json-schema.

Примеры:

<controls>
<group title="$title" layout="v|h">
<group title="$title" layout="v|h">
<control title="$title" command="$cmd" layout="v|h">
<param title="$title" type="$type">
<attributes key1="$value1" key2="$value2"/>
</param>
<param><!--param definition--></param>
</control>
<control title="$title" command="$cmd" layout="v|h" force_button="1" button_text="Some text">
<!-- control definition-->
</control>
</group>
<control><!--command definition--></control>
<group><!--group definition--></group>
</group>
</controls>

{"controls" : {
"element_type" : "group",
"title" : "$title",
"layout" : "v|h",
"elements" :
[
{
"element_type" : "group"
//group definition
},
{
"element_type" : "control",
"title" : "$title",
"layout" : "v|h",
"command" : "$command",
"button_text": "Some text",
"params" : [
{
"title" : "$title",
"type" : "$type",
"constraints" :
{
"$key1" : "$value1",
"$key2" : "$value2"
}
}
]
}

]
}}

Типы параметра и возможные ограничения

Состояние устройства

Состояние управляющего интерфейса устройства описывает текущие значения параметров команд устройства и значения дополнительных параметров, не связанных с интерфейсом управления. При изменении состояния устройство оповещает об этом подключенного клиента при помощи специального сообщения "statechanged". Аргументы сообщения сгруппированы по 3. Первым аргументом в группе идет команда, параметр которой изменился, или "#", если изменился дополнительный параметр, не связанный ни с какой командой. В первом случае вторым аргументом в группе идет номер аргумента команды (начиная с 1), во втором — название дополнительного параметра. Третий аргумент в группе — значение параметра. При запросе всего состояния устройства при помощи зарезервированной команды "#state" возвращается все состояние устройства в одном сообщении с заголовком "ok" и аргументами, сгруппированными по 3 по аналогии с сообщением "statechanged".

Протокол взаимодействия с сервером

Общее описание

Документ описывает сервер для автономного сбора данных с устройств IoT и управления этими устройствами, а также протокол взаимодействия с IoT сервером через доступные для управления каналы связи.

Конфигурационный файл сервера

Настройки сервера хранятся в конфигурационном ini-файле /etc/wliotproxyd.ini. При установке в конфигурационном файле присутствует описание всех параметров. Дополнительно используется файл /var/lib/wliotproxyd/devices.ini, но его ручное редактирование не обязательно.

Доступные каналы для управления IoT сервером

1. Локальный UNIX-сокет "/tmp/wliotproxyd"

2. Tcp порт 4083 с поддержкой ssl шифрования. При подключении по tcp обязательна аутентификация с ключем, указанным в файле.

Описание протокола

Протокол взаимодействия между устройствами на шине практически полностью основан на протоколе взаимодействия с единичным устройством. Для организации взаимодействия устройств на шине дополнительно вводятся следующие правила:

1. Аргументы каждого сообщения-команды от клиента к серверу начинаются с идентификаторы вызова — числа, которое сервер также указывает в начале аргументов ответного сообщения, в том числе в сообщениях ok, err и cmdata. В сообщениях, не предполагающих ответа, таких как info или уведомления от сервера клиенту, идентификатор вызова не указывается.

Базовые типы сообщений

1. Информационное сообщение. Заголовок — info. Предназначено для передачи информации, не требующей специальной обработки (например, отладочная информация) и предназначенной для передачи ее человеку. Аргументы сообщения — текстовые строки, содержащие информацию, предназначенную для прочтения человеком.

2. Сообщение с данными для клиента (или от клиента). Заголовок — cmdata. Первый аргумент всегда — идентификатор вызова, в описании конкретных команд ниже по тексту опущен. Предназначено для передачи данных между клиентом и сервером при обработке команд.

Команды серверу

Общее

1. Команда аутентификации. Заголовок — authenticate. Параметры — имя пользователя и пароль. Команда необходима для подключения к удаленному серверу по tcp.

2. Идентификация сервера. Заголовок — identify. Сервер возвращает уникальный идентификатор в формате UUID и свое имя.

Управление устройствами

1. Перечисление всех имеющихся в системе TTY устройств. Заголовок — list_tty. Аргументы отсутствуют. Список устройств передается на клиент сообщениями cmdata, содержащими следующие аргументы: имя порта, серийный номер, производитель, usb vendor id (число), usb product id (число). Если устройство идентифицировано, дополнительно передаются два аргумента — идентификатор и имя устройства.

2. Идентификация TTY устройства. Заголовок — indentify_tty. Аргумент — имя порта. В случае успешной идентификации клиенту в ответ возвращаются идентификатор устройства, имя устройства и опционально идентификатор типа устройства (в ответном ok сообщении)

3. Идентификация TCP устройства. Заголовок — indentify_tcp. Аргумент — IP адрес или имя хоста. В случае успешной идентификации клиенту в ответ возвращаются идентификатор устройства, имя устройства и опционально идентификатор типа устройства (в ответном ok сообщении).

4. Перечисление идентифицированных устройств. Заголовок — list_identified. Аргументы отсутствуют. На клиент передаются сообщения cmdata со следующими аргументами: идентификатор устройства, имя устройства, идентификатор типа устройства, порт или сетевой адрес устройства.

5. Перечисление датчиков устройства. Заголовок — list_sensors. Агрумент — идентификатор или имя устройства. Список портов передается на клиент в ответном ok сообщении, содержащим аргумент — xml описание сенсоров.

6. Запрос описания интерфейса управления. Заголовок — list_controls. Агрумент — идентификатор или имя устройства. Описание интерфейса управления передается на клиент в ответном ok сообщении, содержащим аргумент — xml описание интерфейса управления.

7. Отправка команды устройству. Заголовок — exec_command. Аргументы — идентификатор или имя устройства, команда, далее аргументы команды. В случае ожидания возвращаемого значения на клиент в аргументах сообщения ok будут переданы аргументы, возвращенные устройством.

8. Управление конфигурацией устройств. Заголовок — devices_config. Содержит вложенные команды. Управление конфигурацией устройств подробно описано ниже. Конфигурация устройств определяет, какие устройства сервер будет обнаруживать и идентифицировать самостоятельно при запуске.

9. Запрос идентификатора устройства. Заголовок — device_id. Аргумент — идентификатор или имя устройства. Сервер ищет устройство в списке идентифицированных устройств или в базе хранилищ и возвращает его идентификатор. Если устройство не найдено или найдено несколько с одинаковым именем, возвращается ошибка. Эта команда позволяет получить

Управление конфигурацией устройств

Управление конфигурацией устройств на сервере производится с помощью сообщения с заголовком devices_config. Аргументы сообщения содержат вложенную команду и ее собственные аргументы. Пример:

"devices_config|get_tty_by_port_name\n"

Ниже приведено описание доступных команд.

1. Запрос списка фильтров tty устройств по имени порта. Команда — get_tty_by_port_name. Аргументы отсутствуют. Возвращает список фильтров по имени tty порта в виде регулярных выражений UNIX, разделенных запятой. Пример:
   "ttyACM*,ttyUSB0,ttyUSB2,ttyS0"

2. Установка списка фильтров tty устройств по имени порта. Команда — set_tty_by_port_name. Аргумент — список фильтров по имени tty порта в виде регулярных выражений UNIX, разделенных запятой.

3. Запрос списка фильтров tty устройств по VIP и PID USB устройства (для преобразователей USB-COM). Команда — get_tty_by_vid_pid. Аргументы отсутствуют. Возвращает список фильтров по VID и PID USB устройства, разделенных запятой. Каждый фильтр — пара VID:PID или только VID, все в нижнем регистре. Пример:
   "1111:2222,3333,4444:5555"

4. Установка списка фильтров tty устройств по VIP и PID USB устройства. Команда — set_tty_by_vid_pid. Аргумент — список фильтров фильтров по VID и PID USB устройства, разделенных запятой.

5. Запрос списка адресов tcp устройств. Команда — get_tcp_by_address. Аргументы отсутствуют. Возвращает список адресов tcp устройств (IP-адрес или DNS имя хоста), разделенных запятой. Пример:
   "192.168.1.1,example.com"

6. Установка списка адресов tcp устройств. Команда — set_tcp_by_address. Аргумент — список адресов tcp устройств (IP-адрес или DNS имя хоста), разделенных запятой.

7. Включение/выключение автоматического поиска устройств в локальной сети. Команда — set_detect_tcp_devices. Аргумент — true|false или 1|0. Если "true" или "1" — сервер регулярно рассылает в сеть широковещательные запросы, устройства определяют адрес сервера и подключаются к нему.

Управление хранилищами для данных сенсоров

1. Перечисление хранилищ. Заголовок — list_storages. Аргументы отсутствуют. Список хранилищ передается на клиент сообщениями cmdata, содержащими следующие аргументы:

   1. идентификатор устройства

   2. имя устройства

   3. имя датчика

   4. тип значений датчика

   5. атрибуты датчика в виде "key1=value1;key2=value2"

   6. тип хранилища (continuous, auto_sessions, last_n_values,memory)

   7. правило преобразования временной метки (dont_touch, add_gt, drop_time)

   8. тип хранимых значений (зависит от правила преобразования временной метки)

2. Добавление датчика в базу. Заголовок — add_storage. Аргументы: идентификатор или имя устройства, название датчика, тип хранилища (continuous, auto_sessions, last_n_values, memory), правило преобразования временной метки (dont_touch, add_global_time, drop_time). Для хранилища типа last_n_values и memory дополнительно передается параметр N — число хранимых значений. При создании хранилища устройство с датчиком должно быть подключено и идентифицировано.

3. Удаление сенсора из базы. Заголовок — remove_storage. Аргументы: идентификатор или имя устройства, название датчика.

4. Привязка сенсора к внешнему IoT сервису. Заголовок — storage_add_data_export. Аргументы: имя или идентификатор устройства, название датчика, название сервиса. Далее идут параметры для сервиса в формате ключ:значение. Если параметры отсутствуют, привязка удаляется.

5. Запрос привязки сенсора к внешнему IoT сервису. Заголовок — storage_get_data_export. Аргументы: имя или идентификатор устройства, название датчика, название сервиса. Если хранилище привязано к внешнему сервису, возвращаются параметры в формате ключ:значение, в противном случае возвращается ошибка.

6. Запрос списка внешних сервисов, в которые экспортируются данные из хранилища. Заголовок — storage_get_data_export_list. Возвращается список названий сервисов.

7. Запрос списка доступных внешних сервисов для экспорта. Заголовок — available_data_export_services. Возвращается список названий сервисов.

8. Установка и получение атрибута хранилища. Заголовки — storage_get_attr, storage_set_attr. Аргументы: имя или идентификатор устройства, название датчика, название атрибута, значение атрибута (для set). Get возвращает значение атрибута.

9. Перечисление сессий для сессионного хранилища. Заголовок — session_list. Аргументы — идентификатор или имя устройства и название датчика. Список сессий передается сообщениями cmdata, содержащими два параметра — идентификатор и название сессии.

10. Перечисление атрибутов сессии для сессионного хранилища. Заголовок — session_list_attrs. Аргументы — идентификатор или имя устройства, название датчика и идентификатор сессии. Список атрибутов сессий передается сообщениями cmdata, содержащими два параметра — ключ и значение атрибута.

11. Получения атрибута сессии для сессионного хранилища. Заголовок — session_get_attr. Аргументы — идентификатор или имя устройства, название датчика, идентификатор сессии и название атрибута. В ответ возвращается значение атрибута.

12. Установка атрибута сессии для сессионного хранилища. Заголовок — session_set_attr. Аргументы — идентификатор или имя устройства, название датчика, идентификатор сессии, название атрибута и значение атрибута. Значение атрибута опционально, если отсутствует — атрибут удаляется.

13. Создание новой сесии. Заголовок — session_create. Аргументы — идентификатор или имя устройства, название датчика и название сессии. В ответ возвращается идентификатор созданной сессии.

14. Запуск ручной сессии. Заголовок — session_start. Аргументы — идентификатор или имя устройства, название датчика и идентификатор сессии. Сессия открывается на запись и начинается сбор данных.

15. Остановка ручной сессии. Заголовок — session_stop. Аргументы — идентификатор или имя устройства и название датчика. Останавливает открытую для записи сессию.

16. Удаление сессии. Заголовок — session_remove. Аргументы — идентификатор или имя устройства, название датчика и идентификатор сессии.

17. Продолжение ручной сессии. Заголовок — session_continue. Аргументы — идентификатор или имя устройства, название датчика и идентификатор сессии. Открывает для дальнейшей записи ранее созданную сессию.

18. Запрос идентификатора открытой для записи сессии. Заголовок — session_get_write_id. Аргументы — идентификатор или имя устройства и название датчика. Если есть открытая для записи сессия, возвращает ее идентификатор.

Обработка данных

1. Перечисление списка javascript-программ. Заголовок — js_list. Возвращает список javascript-файлов на стороне сервера.

2. Остановка, запуск и перезапуск javascript-программы для обработки данных. Заголовки — js_start, js_stop и js_restart. Аргумент — имя файла скрипта (с расширением .js).

3. Запрос количества данных в локальном хранилище. Заголовок — get_samples_count. Аргументы — идентификатор или имя устройства, имя датчика, для сессионного хранилища дополнительно идентификатор сессии. Возвращается количество отсчетов в хранилище.

4. Запрос данных из локального хранилища. Заголовок — get_samples. Аргументы — идентификатор устройства, имя датчика, для сессионного хранилища дополнительно идентификатор сессии, начальный индекс (начинается с 0), количество отсчетов. Дополнительный аргумент — шаг (для прореживания данных, может отсутствовать). Отсчеты возвращаются в сообщениях cmdata, по одному отсчету на сообщение. Данные передаются в том же формате, как и в сообщениях от устройства (meas).

5. Запрос данных из локального хранилища в бинарном. Заголовок — get_samples_bin. Аргументы — идентификатор устройства, имя датчика, для сессионного хранилища дополнительно идентификатор сессии, начальный индекс (начинается с 0), количество отсчетов. Дополнительный аргумент — шаг (для прореживания данных, может отсутствовать). Отсчеты возвращаются в сообщениях cmdata, по одному отсчету на сообщение. Данные передаются в том же формате, как и в сообщениях от устройства (measb).

6. "Подключение" виртуального устройства. Заголовок — register_virtual_device. Аргументы — идентификатор устройства, имя устройства и опционально идентификатор типа устройства.

7. Подписка/отписка на данные от датчика из хранилища. Заголовки — subscribe/unsubscribe. Аргументы — идентификатор или имя устройства и название датчика. Если клиент подписан на датчик из хранилища, то появлении нового измерения в хранилище клиенту будет передано сообщение meas, содержащее идентификатор устройства, название датчика и значение в том же формате, как и от устройства.

Уведомления от сервера клиенту

1. Идентификация устройства. Заголовок — device_identified. Аргументы — идентификатор устройства, имя устройства, опционально идентификатор типа устройства.

2. Отключение устройства. Заголовок — device_lost. Аргумент — идентификатор устройства.

3. Добавление хранилища для датчика — storage_created. Агрументы:

   1. идентификатор устройства

   2. имя устройства

   3. имя датчика

   4. тип значений датчика

   5. ограничения значений в виде "key1=value1;key2=value2"

   6. тип хранилища (continuous, auto_sessions, last_n_values,memory)

   7. правило преобразования временной метки (dont_touch, add_gt, drop_time)

   8. тип хранимых значений (зависит от правила преобразования временной метки)

4. Удаление хранилища для датчика — storage_removed. Агрументы — идентификатор устройства и название датчика.

5. Изменение состояния устройства — statechanged. Аргументы аналогичны аргументам сообщения statechanged от устройства серверу (см. описание протокола взаимодействия между устройствами), но в начале добавлен идентификатор устройства.

6. Уведомление о необходимости перезагрузить список устройств и хранилищ. Заголовок — reload_devices_and_storages. Сообщает о необходимости перезагрузить список устройств и хранилищ на стороне клиента, например, при изменении политики доступа к устройствам.

7. Синхронизация виртуального устройства. Для виртуальных устройств, зарегистрированных клиентом, сервер регулярно передает сообщение vdev_sync, в ответ клиент должен в течении 4 секунд вернуть сообщение syncr. Аргумент обоих сообщений — идентификатор виртуального устройства.

Обработка сообщений для виртуальных устройств

Когда клиент регистрирует виртуальное устройство на сервере, необходимо передавать клиенту сообщения, предназначенные для виртуального устройства, и получать от него сообщения, "исходящие" от виртуального устройства. Для этого сообщения (такие же, как для обычных устройств), "упаковываются" в сообщение с заголовком vdev. Например, в случае выполнения команды на обычном устройстве сервер использует сообщение

call|1|command\n

и получает в ответ сообщение

ok|1\n

Для виртуального устройства сервер пошлет клиенту сообщение

vdev|{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}|call|1|command\n

и получит в ответ

vdev|{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}|ok|1\n

Широковещательные уведомления устройствам

Если в настройках сервера включено автоматическое обнаружение устройств в IP сетях, то сервер будет регулярно рассылать широковещательное сообщение через UDP порт 4081. Заголовок сообщения — server_ready, аргументы — идентификатор и имя сервера.

Поддерживаемые внешние IoT сервисы

Обработка данных на языке javascript

Скрипты для обработки данных располагаются в директории "/var/lib/wliotproxyd/js_data_processing". Каждый скрипт выполняется независимо. Внутри скрипта доступна по-умолчанию стандартная математическая библиотека и набор дополнительных объектов, описанный ниже. Так же для отладки можно использовать метод Console.log().

Объект script

Глобальный объект скрипта, аналог window в браузерных скриптах.

Свойства:

• SensorsDatabase — объект, предоставляющий доступ к базе хранилищ датчиков

• Devices — объект, предоставляющий доступ к списку подключенных устройств

Объект script.SensorsDatabase

Объект, предоставляющий доступ к базе хранилищ датчиков.

Методы

• isOpened — возвращает true/false, в зависимости от того, открыта ли база или нет

• listSensors — возвращает массив идентификаторов хранилищ StorageId (объект с ключами "deviceId" и "sensorName", deviceId — идентификатор устройства, строка в формате UUID, sensorName — название датчика на устройстве, строка).

• existingStorage — возвращает объект Storage, предоставляющий доступ к хранилищу данных для датчика.
  Параметры

  • StorageId id — идентификатор хранилища

• createStorage — создает хранилище для данных с датчика (можно использовать для сохранения результатов обработки в базу данных датчиков) и возвращает объект Storage или null в случае ошибки
  Параметры:

  • Объект, описывающий создаваемое хранилище. Должен содержать следующие свойства:

    • String deviceId — идентификатор устройства (строка в формате UUID)

    • String sensorName — название датчика

    • String storeMode — режим хранения данных ("continuous", "manual_sessions", "memory" или "last_n_values")

    • String tsRule — правило преобразования временной метки ("dont_touch", "add_global_time" или "drop_time"), по-умолчанию add_global_time

    • Number N — количество отсчетов для режима "last_n_values"

Сигналы

• opened — выдается при открытии базы хранилищ

• closed — выдается при закрытии базы хранилищ

• storageCreated — выдается при создании нового хранилища
  Параметры

  • StorageId id — идентификатор хранилища

• storageRemoved — выдается при удалении хранилища
  Параметры

  • StorageId id — идентификатор хранилища

Объект Devices

Объект, предоставляющий доступ к управлению устройствами.

Методы

• devices — возвращает массив идентификаторов подключенных устройств (строки в формате UUID)

• device — возвращает объект Device, предоставляющий доступ к подключенному устройству
  Параметры

  • String id — идентификатор или имя устройства (если имя не уникальное, нужно использовать идентификатор)

• registerVirtualDevice — регистрирует виртуальное устройство, возвращает объект VirtualDevice, позволяющий управлять поведением устройства из скрипта
  Параметры

  • String id — идентификатор устройства

  • String name — название устройства

  • String typeIdStr — идентификатор типа устройства (может быть null)

  • String sensorsStr — строка, содержащая xml или json описание списка датчиков

  • String contorlsStr — строка, содержащая xml или json описание интерфейса управления (опционально)

Сигналы

• deviceIdentified — выдается при идентификации устройства
  Параметры

  • String id — идентификатор устройства

  • String name — название устройства

  • String typeId — идентификатор типа устройства (может быть null)

• deviceDisconnected — выдается при отключении устройства
  Параметры

  • String id — идентификатор устройства

Объект Storage

Объект, предоставляющий доступ к хранилищу данных датчика

Методы

• isOpened — возвращает true, если хранилище открыто

• valuesType — тип значений в хранилище (строка, см. описание протокола взаимодействия между устройствами)

• deviceId — возвращает идентификатор устройства

• deviceName — возвращает название устройства

• sensorName — возвращает название датчика

• readAttribute — возвращает значение привязанного к базе атрибута
  Параметры

  • String key — ключ

• valuesCount — возвращает количество записей в базе (измерений)

• valueAt — возвращает измерение — объект SensorValue
  Параметры

  • index — индекс записи в базе (0-based)

• getStoreMode — возвращает тип самой базы, определяющий способ хранения значений в базе (continuous, manual_sessions, auto_sessions, last_n_values или memory)

Сигналы

• newValueWritten — выдается, когда в базу записывается новое значение
  Параметры

  • SensorValue value — записанное значение

Дополнительные методы для сессионных хранилищ

//TODO

Объект Device

Объект, предоставляющий доступ к подключенным устройствам

Методы

• isIdentified — возвращает true, если устройство идентифицировано

• id — возвращает идентификатор устройства

• name — возвращает название устройства

• sendCommand — выполняет команду на устройстве и возвращает ответ устройства (объект с ключами ok (true|false) и value (список строк, возвращенных устройством))
  Параметры

  • String cmd — команда устройству

  • Array args — параметры команды (массив строк)

Сигналы

• identificationChanged — выдается, когда устройство подключается или отключается

Объект VirtualDevice

Объект, позволяющий организовать виртуальное устройство, управляемое из скрипта. Является наследником Device.

Методы

• writeInfo — генерирует сообщение info от устройства
  Параметры

  • Array args — аргументы сообщения

• writeMeasurement — генерирует сообщение от устройства, содержащее измерение
  Параметры

  • String name — название датчика

  • SensorValue value — измерение (объект SensorValue)

• setCommandCallback — устанавливает функцию-обработчик для команд устройству
  Параметры

  • Function func — javascript-функция обработчик (должна принимать 2 параметра — строка-команда и массив строк — аргументы команды) и возвращать: объект с ключами done (true или false) и result (возвращаемое значение) или просто true или false

• commandParamStateChanged — генерирует сообщение об изменении состояния параметра команды устройства
  Параметры

  • String cmd — команда

  • Number paramIndex — номер параметра команды (начиная с 1)

  • value — новое значение параметра (строка или число)

• additionalStateChanged — генерирует сообщение об изменении дополнительного состояния устройства
  Параметры

  • String paramName — название параметра

  • value — новое значение параметра (строка или число)

Сигналы

• syncMsgNotify — выдается, когда устройство получает от сервера сообщение синхронизации

Объект SensorValue

Свойства

• time — временная метка (для значений без метки времени отсутствует, для локального времени устройства — число, для глобального времени — javascript тип Date)

• data — массив значений (строки для строковых измерений, числа для остальных)

Интерфейс приложения для подключения IoT-устройств к приложению и локальному серверу и пошаговая инструкция

Описание  интерфейса IoT-панели

В десктоп  приложении ECOIMPACT в  меню инструментов  расположен инструмент  "IoT". Открывая данный инструмент, пользователь получает доступ к показанной на рис. 1  панели.



Рис. 1

Панель имеет четыре выделенных области см. рис. 1:
1 -  область списка системных устройств c  кнопками "Update" и "Identify"
2 -  область списка идентифицированных устройств с кнопками Control device и Add sensor 
3 - область списка хранилищ данных, поступающих с сенсоров устройств
4 - интерфейс управления  сессиями, позволяющий пользователю по нажатию соответствующих кнопок  запускать и останавливать  ручные сессии и удалять любые сессии (в том числе автоматические) 
5 - интерфейс задания атрибутов сессий (атрибуты задаются для сессий в хранилищах с ручными и автоматическими сессиями)
6 - область отображения логов действий, выполняемых приложением и подключенными устройствами

Над выделенными областями располагается кноака Connect to IoT сервер, позволяющая подключать приложение к одному из доступных в локальной сети серверов, и интерактивный список, позволяющий подключать интерфейс управления либо к устройствам, подключенным непосредственно к  компьютеру, на котором работает открытое в настоящий момент приложение либо к одному из серверов, к которому это приложение уже подключено.

Список системных устройств с   кнопками "Update" и "Identify"

Кнопка "Update" предназначена для обновление списка системных устройств (в настоящий момент - это список системных COM-портов). Кнопка расположена над областью  списка системных устройств. В списке могут присутствовать устройства не совместимые с аппаратно-программным комплексом  ECOIMPACT, например, подключенные к компьютеру 3G-модемы, сотовые телефоны, Bluetooth-адаптеры или другие сторонние устройства, которые также представлены в операционной системе как COM-порты.

Кнопка "Identify" предназначена для идентификации устройства, совместимого с аппаратно-программным комплексом Alterozoom.  В случае успешной идентификации устройство подключается к приложению и попадает в список идентифицированных устройств, при этом в списке устройство отображается с развернутым подсписком датчиков устройства  (область списка идентифицированных устройств расположена под областью списка всех системных устройств).  Для выполнения процедуры идентификации нужно в списке системных устройств выбрать необходимое и нажать кнопку "Identify".
 

Список идентифицированных устройств с кнопками Control device и Add sensor 

Кнопка Control device предназначена для загрузки интерфейса управления  выбранного в списке идентифицированных устройств конкретного устройства. В случае, если идентифицированное устройство имеет прошитый разработчиком интерфейс управления, то он будет показан в диалоговом окне.
Кнопка Add sensor добавляет выбраный сенсор в базу хранилищ данных, поступающих с датчиков. При нажатии данной кнопки появляется диалоговое окно, позволяющее настроить режим  и формат записи данных в создаваемое хранилище (рис. 2).

Рис. 2

Режимы записи данных (рис.2) в хранилище (Storing mode):
* Continous - запись данных производится непрерывно
* Auto sessions - сессия автоматически запускается при старте приложения и завершается при окончании работы
* Manual sesions - начало записи данных и время окончания записи данных задаются пользователем с помощью нажатия соответствующих кнопок 
* Last N values - в хранилище сохраняется N последних значений, поступающих с датчика

Для  выбранного  датчика в базе создается отдельное хранилище данных.

Список хранилищ данных, поступающих с сенсоров устройств с кнопкой Remove

Хранилища, добавленные в базу, отображаются в списке в области 3 рис.1.
Хранилище данных конкретного датчика может быть удалено из базы с помощью кнопки "Remove"  (при этом удаляются и сами данные).
Для просмотра данных, записываемых в конкретное хранилище, нужно открыть график двойным кликом мыши по соответствующей записи в списке хранилищ. Открывшееся окно вывода графика представлено на рис. 2. Окно может быть настроено на вывод данных, записанных в определенном временном интервале.

Рис. 3

 

Интерфейс управления ручными сессиями

Данный интерфейс (область 4 рис. 1) позволяет пользователю вручную создавать сессию и стартовать  запись данных в соответствующее хранилище  и прекращать запись с помощью нажатия соответствующих кнопок.

Интерфейс задания атрибутов сессий

Данный интерфейс (область 5 рис. 1) позволяет пользователю описывать сессии с помощью атрибутов, присваивая им название ключа и его значение. Атрибуты могут быть использованы пользователем  в  скриптах для организации анализа данных.

Отображение логов действий, выполняемых приложением и подключенными устройствами

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

Пошаговая инструкция по подключению устройств к компьютеру с установленным приложением ECOIMPACT.

1. Открыть панель IoT

2. Подключить к компьютеру  устройство, используя USB-порт, в списке системных устройств нажать кнопку Update. В списке системных устройств должно появится еще одно новое устройство, выделенное красным цветом (при следующем нажатии кнопки Update выделение цветом исчезает).

3. Выбрать новое (появившееся в списке системных устройств)  устройство и нажать Identify. В случае успешной идентификации через несколько секунд устройство появится в списке идентифицированных устройств. Если у устройства есть датчики, рядом с названием устройства  появится стрелка, при нажатии на которую развернется список датчиков устройства.

4. Для управления устройством нужно выбрать устройство в списке идентифицированных устройств и нажать кнопку Control device. Если у устройства его производителем задан интерфейс управления, он появится в отдельном диалоговом  окне

5. Для добавления датчика в базу хранилищ необходимо выбрать конкретный датчик в списке идентифицированных устройств и нажать кнопку Add sensor, указать параметры создаваемого хранилища и нажать кнопку Ok. Созданное хранилище будет отображено в списке хранилищ данных (область 3 рис.1).
   
    

   Пошаговая инструкция по подключению приложения к локальному серверу

   1. Нажать кнопку Connect to server
   2. Ввести адрес или доменное  имя или выбрать из списка найденных автоматически
   3. Ввести логин и пароль пользователя.
   4. Проконтролировать  появление в интерфейсе устройств, подключенных к локальному серверу.
   
    

   Примечание

   
   Панель IoT позволяет по очереди просматривать в виде графиков данные, приходящие с устройств, и управлять ими, но  не позволяет организовывать удобный одновременный просмотр данных, приходящих с нескольких устройств и управление этими устройствами в едином интерфейсе. Для решения последней задачи в приложении предусмотрен особый тип документа - приборная панель (dashboard).

Принципы разработки IoT-устройств, взаимодействующих с локальным сервером

Устройства взаимодействуют с локальным сервером по специальному протоколу (связь точка-точка и устройства на общей шине). Для разработки устройств была разработана специальная библиотека на языке С++, исходно предназначенная для Arduino IDE, но легко переносимая и на другие контроллеры(отсутствуют зависимости от специфичных библиотекк Arduino). Библиотека предназначена для микроконтроллеров с сильно ограниченными ресурсами, таких как AVR или STM. Функциональность библиотеки можно условно поделить на две части: инструменты для разработки единичного устройства, напрямую подключающегося к серверу (например, по COM поверх USB или по TCP/IP) и инструменты, предназначенные для разработки сети устройств, объединенных по принципу общей шины (например, хаб, подключающийся к серверу по USB, и устройства, объединенные в шину по RS-485).

Разработка единичного устройства

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

Обработка сообщений и команд

Объект класса ARpcDevice самостоятельно обрабатывает часть сообщений, таких как запрос на идентификацию, сообщения синхронизации и т.д. Так же он обрабатывает служебные команды, такие как запрос списка датчиков или описания интерфейса управления. Для обработки остальных команд нужно разработать класс, реализующий интерфейс ARpcIDevEventsCallback, библиотека будет вызывать его метод processCommand каждый раз, когда будет приходить неслужебная команда.

Обработка сообщений производится объектом класса ARpcRealDeviceMessageDispatch, доступным с помощью метода ARpcDevice::disp(). Так же этот объект позволяет формировать различные сообщения.

Список датчиков и описание интерфейса управления - строки языка С (const char*), содержащие соответствующие описания в xml или json формате, как описано в протоколе взаимодействия между устройствами. Эти строки должны быть глобальными переменными и не должны меняться, так как библиотека их не копирует.

При обработке команды нужно обязательно вернуть сообщение ok или err, вызвав соответствующий метод ARpcRealDeviceMessageDispatch::writeOk() или ARpcRealDeviceMessageDispatch::writeErr(). Если выполнение команды занимает значительное время, необходимо регулярно отправлять сообщение синхронизации с помощью метода ARpcRealDeviceMessageDispatch::writeCmdSync().

Измерения передаются с помощью методов ARpcRealDeviceMessageDispatch::writeMeasurement и ARpcRealDeviceMessageDispatch::writeMeasurementB. Первый метод передает данные в текстовом виде, для его использования необходимо преобразовывать числа в строки. Второй метод предназначен для передачи данных в бинарном виде.

Состояние устройства

Метод ARpcDevice::state() возвращает объект класса ARpcState, представляющий состояние устройства. Состояние устройства подразделяется на две группы: состояние интерфейса управления и дополнительное состояние. Состояние интерфейса управления указывает, в каких позициях должны находиться элементы в интерфейсе управления, чтобы соответствовать текущим параметрам работы устройства.

Перед использованием состояние устройства нужно инициализировать. Для инициализации состояния интерфейса управления нужно воспользоваться методом ARpcState::prepareCommands(count), затем методом ARpcState::prepareCommand(index,name,parametersCount) для каждой команды. Для инициальзации дополнительного состояния нужно вызвать метод ARpcState::prepareAdditionalParameters(count), затем метод ARpcState::prepareAdditionalParameter(index,name) для каждого доп. параметра.

При изменении состояния устройства нужно вызвать метод ARpcState::setCommandParamState или ARpcState::setAdditionalParamState. Библиотека сохранит измененное состояние и сгенерирует соответствующее нотификационное сообщение.

Обработка broadcast уведомлений от сервера

Для обработки широковещательных уведомлений от локального сервера предназначен класс ARpcSrvReady. На данный момент объект этого класса можно использовать для обработки широковещательных UDP уведомлений в локальной IP сети. Сервер рассылает регулярные оповещения на UDP порт 4081, данные передаются в объект класса ARpcSrvReady с помощью метода ARpcSrvReady::putByte(), обработка обнаруженных и успешно разобранных сообщений происходит через интерфейс ARpcISrvReadyCallback. Если на устройстве есть энергонезависимая память, можно настроить его так, например, чтобы оно подключалось только к конкретному локальному серверу.

Список датчиков и описание интерфейса управления

Для описания списка датчиков и интерфейса управления используется строка в xml или json формате. Для разработки описаний можно использовать утилиту ARpcUiGen или же сформировать список вручную согласно описанию из документации.

Пример кода тестового устройства на МК Arduino Uno или Leonardo