[БЕЗ_ЗВУКА] От взаимодействия приложений с устройствами перейдем к взаимодействию ее с пользователями. Поскольку в человеко-ориентированных системах ключевым будет то, какую информацию, в каком виде и когда должен получить пользователь, то формирование требований к архитектуре модели часто начинается именно с определения круга пользователей и их потребности в информации. Важно, что для приложений интернета вещей меняется привычный формат взаимодействия с человеком. Все чаще система должна реагировать не на команды, даваемые им через интерфейс мобильного или веб-приложения, а понимать, что человеку требуется, исходя из условий вокруг него. К примеру, если система видит, что то человеку жарко, она может включить кондиционер, отслеживая его положение, предусмотрительно открыть перед ним дверь или же распознав настроение, включить соответствующий тон освещения. Обычными для приложений интернета вещей становятся голосовое управление и голосовые интерфейсы, распознавание жестов и эмоций, другие способы взаимодействия с пользователями. Соответственно, появляется специфика и дополнительные требования к разработке пользовательских интерфейсов приложений интернета вещей для обеспечения сенсомоторной и психофизиологической совместимости такого приложения с человеком. В том числе, в случае его использования технологией Ambient [НЕРАЗБОРЧИВО], а также дополненной реальности. При этом, чем более разумными становятся системы, тем больше общение с ними начинает походить на общение с человеком. Чтобы правильно выстроить информационные модели, надо правильно определить круг пользователей приложения и их потребности. Обратите внимание, состав пользователей приложения отличается от состава пользователей системы. К пользователям системы относятся те, кто взаимодействует с приложением напрямую, к примеру, через веб-интерфейс или опосредованно, получая выгруженный оператором из системы отчет. Для каждого определенного выше пользователя следует зафиксировать, кто является пользователем, имя, должность и так далее, какую роль он играет, исходя из концепции разрабатываемой системы, каковы его проблемы и потребности, решаемые за счет построения системы. Как система решает эти проблемы и удовлетворяет эти потребности через функции того же мониторинга, управления, оптимизации, автоматизации. На основе этой информации составляется также организационная структура моделирования в приложении, определяются организации и группы пользователей, участвующих в проекте, принадлежность пользователей к организациям и группам, роли в организациях и так далее. Определив источники данных, следует определить стратегию представления данных. На этом этапе надо определять, какие объекты станут составлять виртуальную модель системы и как они будут соотнесены с внешними по отношению к системе объектами. Для этого надо определить все внешние по отношению к системе источники потребителей данных (вещи) и установить для них соответствие с представлениями данных (виртуальными вещами) в модели. Виртуальная модель может точно соответствовать всем внешним объектам, и тогда мы имеем цифровой двойник. Но возможны и другие варианты структуры. Выбор стратегии представления объектов системы в модели будет ключевым при рассмотрении архитектуры приложения. Соответствия между физическими и виртуальными объектами могут быть установлены в соответствии со следующими стратегиями. Во-первых, «один к одному». Эта стратегия является одной из самых простых. Здесь одно внешнее физическое устройство взаимодействует с одним цифровым представлением в облаке. Этот вариант также обычно они называют цифровым двойником. «Один ко многим», или «шлюз» — стратегия, при которой одному представлению виртуальной вещи в модели соответствует одно внешнее устройство, но которое локально собирает разные данные, которые объединяются тем не менее в одну виртуальную вещь. «Многие ко многим»: по этой стратегии множеству (облаку) внешних физических и виртуальных объектов соответствует множество (облако) виртуальных объектов в модели. К примеру, сервисные данные, поступающие от физического оборудования, сгруппированного по местоположению объектов, на которых это оборудование расположено, а в модели это же оборудование сгруппировано по его производителю.
