Если до этого мы смотрели на приложение интернета вещей, как бы снаружи и для нас это был некий черный ящик, то давайте попробуем сделать его прозрачным и посмотрим, что там внутри. Мы видим, что основу приложений, составляет виртуальная модель, включающая модель данных и процедуры их взаимодействия. Модели обмениваются, какими-то данным с внешними, физическими, виртуальными объектами и надо посмотреть через какие интерфейсы. Кроме того, структура приложения может содержать все то, что необходимо для получения и передачи накопления и хранения обработки данных, обеспечения их безопасности. В большинстве современных платформ для разработки приложений интернета вещей, значительная часть деталей этих процессов, прозрачны для разработчика и он может сосредоточиться на модели, предусмотрев для нее соответствующие интерфейсы, для взаимодействия с пользователями, устройствами и сторонним приложениями. Посмотрим, как устроены и создается модель данных, подробнее. Модель данных задает общую структуру данных приложений интернета вещей. Абстрактная модель данных отражает всё множество объектов реального мира, включая физические объекты, людей, системы рабочие процессы и определяют, как они соотносятся друг с другом. Сам процесс построения модели аналогичного объекта ориентированной разработки, и тут возможность создания компонентов, как модели, считается уже стандартной практикой. Однако использование модели, дает определенные преимущества. Прежде всего это гибкость. В однажды созданной модели, легко обновлять, изменять, удалять компоненты без необходимости перестраивать систему и повторно тестировать существующие компоненты. Масштабируемость, легко клонировать и модифицировать объекты, которые либо идентичны, либо похожи друг на друга. При переходе от проверки концепции или пилоток масштабируем модели бизнеса. Функциональная совместимость, она обеспечивает бесшумные встраивания в другие приложения. Кооперирование - модель данных допускает при определении связи между компонентами, что означает, что при проектировании модели можно определить различные элементы модели так, что несколько человек могли бы работать с этими отдельными частями, не нарушая совместимости компонентов. Кроме того, модель данных позволяет организовать бесшумную интеграцию с другими системами. Правильно сформированная модель, упростит реализацию таких ценных возможностей интернета вещей, как аналитика, дополненная виртуальная реальность, промышленная связь и так далее. Прежде, чем приступить к разработке модели, следует определить, кому именно нужно взаимодействовать с данными и какие конкретные требования к их представлению они будут иметь? Следует продумать возможность модульности и повторного использования будущих обновлений. Благодаря правильно выстроенной основе, приложение будет масштабируемым, гибким и более безопасным. Как и в случае приложение в целом, разработка модели данных, идет о сценарии взаимодействия и определение источников данных, функциональных требований и к построению моделей организации взаимодействия с ней. Организация обмена данными. Суть того, что делает приложения интернета вещей - это обмен данными. В основе приложения, информационные модели и цифровые двойники множества физических и виртуальных объектов, систем, систем объектов, систем систем, для чего требуется интенсивный обмен данными между приложениями и внешними источниками и потребителями данных. На любое наиболее широко используемые методы обмена данных, приведены в таблице. Важным для правильного построения модели, является понимание разницы между данными, информацией и знаниями. Данные это лишь наборы определенных символов, которыми обмениваются между собой физические виртуальные вещи. Данные становятся информацией, когда они ассоциируются с "вещами" - физическими и виртуальными объектами, и начинают нести, применительно к ним, ответы на вопросы ЧТО, ГДЕ, КОГДА, КАК. При этом информация ассоциированная с вещами, может быть статической и динамической. В данном курсе мы будем использовать следующие понятия связанные с этой информацией. Во-первых, свойства, "property" - это значимая информации характеризующая объекты его состояния. К примеру, если объект холодильник, то его свойствами, могут быть его состояние: включен он или выключен, температуру в морозильной камере, энергопотребление, модель, серийный номер, время в работе, время до обслуживания, содержимое полок и так далее. При этом скажем серийный номер холодильника, будет статической информацией, а его энергопотребление или температура в морозилке - динамической. А для автомобилей такими свойствами в зависимости от решающей задачи, могут быть: текущая скорость, текущее местоположение, имя водителя, запас топлива, расход топлива, напряжение бортовой сети, время последнего техобслуживания и так далее. А вот для декоративных растений это могут быть: температура, влажность почвы, температура и влажность воздуха, освещенность, виды растения и так далее. Значение разных свойств, передается через информационно-коммуникационные сети в виде данных, так ROLLS ROYCE к примеру, собирает данные с множества датчиков установленных на их двигателях в самолетах и анализирует, их с помощью сервисов интернета. "Большие самолеты генерирует гигабайты данных в час, которые нужно обрабатывать и анализировать. И научившись работать с этой информацией, мы предлагаем новые подходы к диагностике и обслуживанию авиатехники", - говорят представители ROLLS ROYCE. Значение свойств не изменяется сами собой, для этого используется служба или сервисы. Кроме того, через службы осуществляются прием и передача данных. Изменения каких-то свойств могут быть значимы для объектов входящих в систему. К примеру, повышение температуры выше некоторого критического уровня, может потребовать действий от объектов входящих в систему управления климатом. Такого рода изменение значений свойств, может генерировать событие. Событие - это изменение свойств объекта, которое может быть зафиксировано другими объектами, за этим изменением следящими. Те объекты, которые следят за данными событиями, считаются на него "подписанными" - имеют соответствующую "подписку". К примеру, модуль оповещения в системе управления микроклиматом, может быть подписан на событие, температура стала слишком высока, а вот модуль учета энергопотребления, будут такие события игнорировать. В общем случае, внутри системы могут генерироваться события разного типа: предупреждения, срабатывания таймеров, какие-то пользовательские события и так далее. На данном этапе нам важно, что именно механизм событий и подписок на них, позволяет реализовывать поведение системы, основанное на правилах. Это мы может быть, как управление внутренними процессами в системе, так и реализация бизнес-правил, в определенных сценариях. Таких к примеру, как водитель грузовика предупреждает за повышение скорости или водитель наказывается если было 3 предупреждения и так далее. Это означает, что в первом случае, изменение значения скорости выше разрешенной, генерируют событие скорость превышена и соответствующая подписка в свою очередь, генерирует предупреждение водителя. А если значение числа предупреждений становится больше 3, то генерирует события лимит предупреждений превышен, что запускает подписку ведающую систему наказаний. Итак, обсудив структуру приложения интернета вещей, рассмотрим источники данных, устройства и пользователей.
