Правила поведения могут быть организованы через уровни управления и приоритеты. Как уже обсуждалось ранее, в управлении поведением можно выделить несколько уровней: стратегические, тактические, динамические. И по аналогии с живыми организмами динамические уровни в свою очередь могут делиться на автономные регуляции аппаратной реакции, безусловные рефлексы, условные рефлексы и стереотипы поведения. В этом смысле, нажатие кнопки аварийной остановки, которая обесточивает всю систему на аппаратном уровне - это некий нижний динамический уровень. А отъезд транспортной платформы от препятствия при срабатывании датчика может потребовать достаточно сложного комплекса движений, фактически это аналог стереотипного поведения. В полностью автономных [inaudible] системах все уровни управления как правило присутствуют на борту. К примеру, складскому роботу, в задании чемпионата мира "WorldSkills" в компетенции "Мобильная робототехника", следовало самому решить на стратегическом уровне, как он будет выполнять заказ, какой товар возьмет первым, какой последующим и так далее. Однако, в подавляющем большинстве сервисных логистических промышленных роботов, стратегический уровень управления вынесен во внешнюю систему, и оттуда просто приходят команды что роботу следует делать, а его задача обеспечить выполнение данной команды. Так, в складской роботизированной системе транспортный робот получает команду, куда ему прибыть за грузом, а сам должен проложить маршрут, суметь принять решение по обнаружению препятствий по дороге и так далее. В этом смысле, куда прибыть за грузом - это стратегический уровень, он вынесен в облако, а тактический уровень, динамический уровень остается на борту. С другой стороны, в условно настоящих приложениях интернета вещей, сами вещи реализуют, как правило, динамические реакции нижнего уровня: сбор информации с датчиков, выполнение действий своим исполнительным устройством и так далее. А вот все управление поведением на выше лежащих уровнях вынесено в облако. Но в зависимости от выбранной архитектуры возможно и промежуточное решение. Если архитектура системы предполагает организацию реакции системы на различные изменения в событиях, то конкретное устройство может игнорировать определенные события, а может реагировать на них. То есть, может быть подписано данное событие. Подписка (subscription) содержит процедуры, которые будут выполнены при наступлении данного события. Таким образом, механизм событий и подписок позволяет сдавать фактические правила поведения для любого устройства и для системы в целом. И задача архитектора приложения состоит в том, чтобы сформулировать такие правила поведения для отдельных устройств в системе, чтобы в результате их взаимодействия система выполнила поставленную задачу. После того как это будет сделано, можно будет связать требования с правилами, подписки с событиями, а затем занести их в машину ввода, как это предусмотрено в используемой платформе. И здесь стоит вспомнить ту часть курса, где мы обсуждали поведение живого организма. Ведь внешне все выглядит так, что внутри все управляется разумно: побежал быстрее - сердце увеличило подачу крови, дыхание стало чаще и глубже и так далее, прямо будто внутри компьютер, но это же не так. Все органы живут своей жизнью, никакого централизованного внутреннего управления в организме нет, и сердце просто не знает, что происходит с мышцами или в легких. Оно работает в своем режиме, но увидев повышение уровня адреналина в крови увеличивает частоту сердечных сокращений. Также каждый орган функционирует совершенно сам по себе, но есть набор сигналов и событий нервных или гуморальных, на которые он реагирует. Фактически он тоже подписан на это событие упомянутое выше в терминологии. И дальше идет набор способов реакции, но все вместе выстроено так, что организм в целом итоге способен к целенаправленной деятельности. Ну и деятельность сердца в свою очередь - тоже лишь набор реакций на взаимодействие со средой и изменение внутреннего состояния. Можно сказать, что используя технологии интернета вещей, разработчик также создает техническую систему ее поведения, как природа создает живые организмы, создавая взаимосвязи их поведения и морфологии. Резюмируем: смысл создания приложения интернета вещей, делать что-то в окружающей среде (операционном окружении), исходя из поступающей оттуда информации. Для этого проектируемая целевая система должна содержать как минимум средство получения информации от операционного окружения, средство взаимодействия с операционным окружением, возможно память о таких взаимодействиях и некий механизм, дающий логику этих взаимодействий при использовании современных платформ. Вся логика взаимодействий: память и другие функции связанные с обработкой информации, выносят от физических устройств на такое, как правило, облачную, или северную платформу в виде собственного приложения. Основой приложения является модель данных включающая логику и взаимодействие. Если структура модели данных соответствует структуре и свойствам реальных виртуальных объектов включенных в систему, или взаимодействует с ней, то такая система может считаться цифровым двойником. Таким образом, основой приложения интернета вещей является модель данных. Плюс приложение включает необходимый для его функционирования интерфейс устройств, данных и пользователей, а также все что необходимо для организации, хранения и обработки данных, их анализа, обеспечения безопасности и так далее. Итак, система построенная на технологии интернета вещей с точки зрения своей архитектуры состоит из трех основных частей. Во-первых, это совокупность элементов непосредственно взаимодействующих с окружающей средой, с оппозиционным окружением, получающих от нее информацию и осуществляющих физическое информационное взаимодействие с ней. Во-вторых, это модель данных. И в-третьих, это все то, что необходимо для обеспечения функционального единства и взаимодействия элементов первой группы с моделью данных. В человеко-ориентированных системах, элементы и части модели связанные с взаимодействием с пользователями, могут быть выделены в самостоятельную структуру. Под приложением интернета вещей, в зависимости от контекста может пониматься как часть программного обеспечения проекта, реализованные на платформе интернета вещей собственно приложения, так и вся целевая система построенная технологией интернета вещей являющаяся предметом разработки.
