УСТРОЙСТВО ГЕНЕРАЦИИ КОМАНДЫ УПРАВЛЕНИЯ ПОТОКОМ ДАННЫХ И УСТРОЙСТВО УПРАВЛЕНИЯ ДАТЧИКАМИ Российский патент 2015 года по МПК G06Q50/30 G08G1/00 

Область техники, к которой относится изобретение

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

Уровень техники

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

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

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

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

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

Список цитирования

Патентная литература

PTL 1: выложенная патентная заявка Японии № 2007-300571

PTL 2: выложенная патентная заявка Японии № 2000-331284

Сущность изобретения

Техническая проблема

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

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

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

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

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

Решение проблемы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полезные эффекты изобретения

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

Краткое описание чертежей

Фиг. 1 является видом, показывающим конфигурацию системы управления трафиком целиком;

фиг. 2A является блок-схемой последовательности операций, показывающей последовательность всех процессов, связанных с формированием автомобильной колонны;

фиг. 2B является блок-схемой последовательности операций, показывающей начальный процесс в формировании автомобильной колонны;

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

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

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

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

фиг. 4 является видом, показывающим изменение состояния двигающегося в колонне объекта приложения поддержки формирования колонны на серверной стороне;

фиг. 5 является схематичным видом для объяснения управления на светофоре во время движения колонны;

фиг. 6A является видом для объяснения управления потоком данных в управляемом по событиям типе режима доступа на стороне датчика, а фиг. 6B является видом, показывающим структуру данных, используемую в управлении;

фиг. 7 является блок-схемой последовательности операций для объяснения управления потоком данных в управляемом по событиям типе режима доступа на стороне датчика; и

фиг. 8A является видом для объяснения управления потоком данных в управляемом по событиям типе режима доступа на стороне приложения, а фиг. 8B является видом, показывающим структуру данных, используемую в управлении;

фиг. 9A является видом для объяснения управления потоком данных в управляемом по метаданным типе режима доступа на стороне датчика, а фиг. 9B является видом, показывающим структуру данных, используемую в управлении;

фиг. 10A является видом для объяснения управления потоком данных в управляемом по метаданным типе режима доступа на стороне приложения, а фиг. 10B является видом, показывающим структуру данных, используемую в управлении;

фиг. 11A является видом для объяснения управления потоком данных с использованием виртуального датчика и DB, которая хранит данные зондирования, а фиг. 11B является видом, показывающим структуру данных, используемую в управлении;

фиг. 12A является видом, показывающим структуру метаданных, используемых в датчике, и данных зондирования, а фиг. 12B является видом, показывающим структуру метаданных, используемых в приложении.

Описание вариантов воплощения

[Первый вариант воплощения]

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

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

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

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

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

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

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

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

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

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

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

Таким образом, движение множества транспортных средств, которые имеют один и тот же пункт назначения (в том числе промежуточные пункты назначения на маршруте движения) или маршрут и время движения, в колонне полезно для водителя и с точки зрения трафика.

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

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

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

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

<Полная конфигурация системы>

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

Система 1 управления трафиком включает в себя транспортное средство 2, смартфон 3 в качестве терминала мобильной связи, принадлежащего водителю и т.п. и расположенного в транспортном средстве 2, сеть 4 для мобильного терминала, с которой смартфон 3 осуществляет связь, облачный сервер 5 M2M, который обеспечивает облачную среду, сервер 6 сенсорной сети, который выполняет услуги, связанные с сенсорной сетью, сервер 7 приложений, устройство 8 управления сигналом светофора и светофор 9. Конфигурация каждого блока, описанного выше, может быть разработана произвольно и специально не ограничивается. Кроме того, конфигурация сети 4 или способ связи между блоками специально не ограничиваются. Ниже более подробно описывается конфигурация и функция каждого блока системы 1 управления трафиком.

(Транспортное средство 2)

Транспортное средство 2 движется из пункта отправления в пункт назначения под управлением водителя. Чертеж изображает состояние, когда четыре транспортных средства 2a-2d формируют группу и движутся по дороге в колонне 20A.

(Смартфон 3)

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

Смартфон 3 может осуществлять связь с облачным сервером 5 M2M через сеть 4 и может дополнительно получить доступ к информации сервера 6 сенсорной сети через облачный сервер 5 M2M. Кроме того, смартфон 3 также выполняет функцию клиента, который использует арифметические ресурсы сервера 7 приложений. С другой стороны, эти серверы получают информацию от транспортного средства 2 через сеть 4. Блок передачи информации о плане путешествия и блок приема командной информации настоящего изобретения соответствуют коммуникационной функции смартфона 3.

(Автомобильное приложение 31)

Автомобильное приложение 31 устанавливается на смартфон 3. Автомобильное приложение 31 соответствует приложению 71 режима колонны на стороне сервера приложений и получает командную информацию через сеть 4. Автомобильное приложение 31 предпочтительно функционирует как автомобильное навигационное приложение или функционирует в кооперации с автомобильным навигационным приложением. CPU осуществляет управление в соответствии с инструкциями такого приложения, а смартфон 3, таким образом, функционирует как терминал поддержки поездки настоящего изобретения.

(Подставка 32 для подзарядки)

Подставку 32 для подзарядки можно использовать для крепления смартфона 3 к транспортному средству 2. Если автомобильное приложение 31 настроено так, чтобы активироваться, когда смартфон 3 помещается в подставку 32 для подзарядки, его использование может быть упрощено. Альтернативно, автомобильное приложение 31 может также активироваться, когда водитель касается значка на смартфоне 3.

Следует отметить, что хотя настоящий вариант воплощения использует смартфон 3, в котором установлено автомобильное приложение 31 и который функционирует также как сенсорное устройство, группа устройств, которые имеют эти функции и могут передавать/принимать информацию к/от сети 4, может в совокупности называться терминалом поддержки путешествия настоящего изобретения. Например, некоторые автомобильные навигационные устройства имеют функцию выдачи с помощью голоса инструкций для вождения, функцию получения текущего положения с использованием GPS и т.п., а также функцию отображения маршрута движения и периода времени, когда введен пункт назначения, и, следовательно, эти устройства могут использоваться в настоящем изобретении. Кроме того, можно использовать средства беспроводной связи автомобиля в качестве коммуникационной функции, а также использовать средства автомобиля в качестве функции GPS, устройства отображения и блока ввода.

(Сеть 4)

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

(Облачный сервер 5 M2M)

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

(Сервер 6 сенсорной сети)

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

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

(DB 61 договоров предоставления данных, DB 62 договоров использования данных)

Сервер 6 сенсорной сети (устройство управления датчиками) сохраняет информацию, относящуюся к владельцу и сенсорному устройству, в DB 61 договоров предоставления данных в ответ на регистрацию владельца. Информация, относящаяся к сенсорному устройству, включает в себя тип датчика, положение датчика и приложение, совместимое с датчиком. Информация, относящаяся к владельцу, включает в себя доступный период, цель использования данных (используются только с академическими целями и т.п.), область использования (используются только в некоммерческих областях) и компенсацию. Вышеупомянутая информация сохраняется совместно с идентификационной (ID) информацией (S_ID) каждого сенсорного устройства (смартфона 3 в этом случае) и считывается в ответ на запрос от облачного сервера 5 M2M. Это соответствует блоку хранения информации устройства.

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

Сервер 6 сенсорной сети обращается к этим базам данных для установления соответствия между условиями пользователя и датчиком и управляет сбором платы с пользователя и уплатой компенсации владельцу в соответствии с записями пользования. В настоящем варианте воплощения доступные номера приложений (A1, A2, ..., AN) сохраняются для каждой идентификационной (ID) информации (S_ID). Это соответствует блоку хранения данных условий использования.

(Сервер 7 приложений)

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

(Различные приложения)

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

Другие приложения описаны как примеры приложения. Приложение 72 карты пробок собирает информацию о местоположении и скорости движения со смартфона 3, генерирует карту пробок на основании информации, собранной от каждого транспортного средства, и продает карту пробок бизнес-оператору и т.п., который использует эти дорожные условия. Приложение 7N распространения изображений собирает изображения и динамические изображения, снятые во время движения сенсорными устройствами, такими как смартфон 3 и установленные на транспортном средстве камеры, и предоставляет их пользователю, который хочет знать ситуацию в каждой точке. Снятые изображения могут использоваться в приложении для обнаружения повреждений дороги или приложении для обнаружения незаконно припаркованных транспортных средств.

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

Следует отметить, что облачный сервер 5 M2M, сервер 6 сенсорной сети и сервер 7 приложений разделены как различные блоки в вышеупомянутом описании. Однако их фактическое физическое расположение может выбираться свободно с учетом стоимости строительства, требуемой производительности, состояния сети или диверсификации рисков. Например, они могут быть сконфигурированы как отдельные модули одного устройства или могут также использоваться совместно с множеством компьютеров. Говоря более коротко, настоящее изобретение может быть реализовано, когда используется сервер, имеющий возможность передачи/приема информации к/от сенсорных устройств в различных местах и обработки большого объема данных с использованием приложения. С целью разграничения от терминала поддержки поездки (смартфона) на стороне транспортного средства как сенсорного устройства, серверы, описанные выше, все вместе называются «серверной стороной». И блок приема информации о плане путешествия, и блок передачи командной информации настоящего изобретения используют любую из коммуникационных функций на серверной стороне. Кроме того, и блок выделения группы, и блок генерации командной информации используют любое из устройств обработки информации на серверной стороне. Вся серверная сторона может рассматриваться как устройство поддержки формирования взаимного расположения транспортных средств настоящего изобретения.

(Устройство 8 управления сигналом светофора, светофор 9)

Устройство 8 управления сигналом светофора управляет включением и выключением красного и зеленого света светофора 9 на дороге. Обычно, из числа последовательностей, заранее определенных для каждого светофора, выбирается последовательность, соответствующая дню недели и периоду времени, и выполняется управление. Однако также можно гибко управлять состоянием «включено» или «выключено» в соответствии с фактическими условиями трафика, и в случае, когда дана инструкция приложения 71 режима колонны, выполняется процесс, дающий преимущество проезда колонне. На чертеже колонна 20A собирается проехать мимо светофора 9.

<Последовательность операций процесса на стороне транспортного средства>

Формирование колонны и преимущественный проезд в настоящем варианте воплощения описаны, в частности, со ссылкой на фиг. 2A-2E.

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

(Начальный процесс)

На этапе S101 выполняется начальный процесс. Детали начального процесса показаны в последовательности операций по фиг.2B.

На этапе S1011 на фиг. 2B активируется автомобильное приложение 31 смартфона 3. Автомобильное приложение 31 может быть настроено так, чтобы автоматически активироваться, когда оно соединяется с подставкой 32 для подзарядки, расположенной на инструментальной панели транспортного средства 2, и эта настройка является предпочтительной с точки зрения источника питания. Альтернативно, водитель (пассажир также может активировать автомобильное приложение 31; то же самое относится к нижеследующему описанию) может активировать автомобильное приложение 31 с помощью значка. Как было описано выше, так как автомобильное приложение также служит автомобильным навигационным приложением, водитель готов активировать это приложение, чтобы получить свою навигацию.

На этапе S1012 автомобильное приложение 31 осуществляет связь со спутником GPS с использованием функции GPS смартфона 3 для получения текущего положения транспортного средства 2.

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

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

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

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

(Процесс поддержки формирования колонны)

На этапе S103 выполняется процесс поддержки формирования колонны. Детали настоящего процесса показаны в последовательности операций на фиг. 2C.

На этапе S1031 на фиг. 2C автомобильное приложение 31 передает план путешествия (S_DATA) и идентификационную (ID) информацию (S_ID) смартфона 3 облачному серверу 5 M2M. Кроме того, также может передаваться информация, указывающая, что «смартфон 3 соединен с подставкой 32 для подзарядки». Это необходимо для того, чтобы серверная сторона могла определить, расположен ли смартфон 3 в транспортном средстве. Следует отметить, что даже в случае, если водитель «не хочет двигаться» в колонне на этапе S102, план путешествия и идентификационная (ID) информация могут быть переданы. Такое транспортное средство не влияет на движение колонны, но эффективно с точки зрения предоставления данных зондирования сенсорной сети.

На этапе S1032 автомобильное приложение 31 обнаруживает начало движения транспортного средства с использованием датчика ускорения и т.п.

На этапе S1033 автомобильное приложение 31 получает и передает текущее положение и скорость транспортного средства 2. Этот процесс не является необходимым, но предпочтительно выполняется для точного выполнения команды формирования колонны на серверной стороне.

На этапе S1034 автомобильное приложение 31 запрашивает, исходит ли команда участвовать в колонне от приложения 71 режима колонны через сеть 4. Если команда отсутствует (S1034=Нет), процесс возвращается к предыдущему этапу и запрос повторяется через заданный промежуток времени.

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

(Способ вождения во время участия в колонне)

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

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

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

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

(Процесс обслуживания движения колонны)

Возвращаясь к последовательности операций на фиг. 2A, на этапе S104 выполняется процесс обслуживания движения колонны. Детали настоящего процесса показаны в последовательности операций на фиг. 2D.

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

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

(Процесс, относящийся к уходу из колонны или продолжению движения в колонне)

Возвращаясь к последовательности операций на фиг. 2A, на этапе S105 автомобильное приложение 31 обнаруживает, присутствует ли сигнал начала ухода из колонны. Сигнал начала ухода из колонны - это событие, являющееся показателем ухода из колонны изнутри транспортного средства или извне. Например, событие изнутри транспортного средства включает в себя явный или неявный запрос на уход от водителя. Явный запрос обозначает случай, когда намерение ухода объявлено с помощью голоса водителем, и случай, когда операция по уходу выполняется с помощью сенсорной панели пассажиром. Неявный запрос обозначает случай, когда пункт назначения автомобильного навигационного приложения изменяется, и случай, когда выполняется операция вождения, которая отклоняет транспортное средство от назначенного маршрута. Событие извне транспортного средства включает в себя командную информацию в случае, когда транспортное средство отклоняется от обычного маршрута, или случай, когда по некоторым причинам решено, что транспортное средство является неподходящим членом колонны. Когда сигнал начала обнаружен (S105=Да), процесс переходит к этапу S106.

Детали этапа S106 показаны в последовательности операций на фиг. 2E.

На этапе S1061 на фиг. 2E автомобильное приложение 31 выводит информацию для переключения. Может использоваться способ инструктирования, аналогичный способу нормальной навигации.

На этапе S1062 водитель выполняет операцию вождения для ухода из колонны.

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

Возвращаясь к фиг. 2A, на этапе S107 детектируется, участвует ли транспортное средство в колонне повторно. Когда движение в колонне должно быть возобновлено из-за обстоятельств, описанных выше (S107=Да), процесс возвращается к этапу S103, и транспортное средство участвует в другой колонне. С другой стороны, в случае, когда транспортное средство не уходит из колонны с самого начала (S105=Нет), и случае, когда одиночное движение продолжается на этапе S107 (S107=Нет), процесс переходит к этапу S108, и текущее состояние движения сохраняется.

(Конечный процесс)

На этапе S109 текущее положение сравнивается с введенным пунктом назначения, и таким образом определяется, прибыло ли транспортное средство в пункт назначения. Если транспортное средство прибыло в пункт назначения (S109=Да), информация, свидетельствующая о прибытии, выводится водителю, а навигация и поддержка движения в колонне завершаются. Если транспортное средство не прибыло в пункт назначения (S109=Нет), процесс возвращается к этапу S104, и движение продолжается. Следует отметить, что в случае, когда транспортное средство уже выполняет одиночное движение, этапы S104 и S105 не применяются.

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

<Процессы на серверной стороне>

Далее описываются процессы на серверной стороне, то есть в облачном сервере 5 M2M, сервере 6 сенсорной сети и приложении 71 режима колонны на сервере 7 приложений. В частности, главным образом описываются процесс сенсорной сети, показанный в верхней правой части фиг. 1, и процесс приложения 71 режима колонны, показанный на фиг. 3.

(Процесс сенсорной сети)

Как было описано выше, совместно с идентификационной (ID) информацией (S_ID) в DB 61 договоров предоставления данных сохранен номер приложения (APPLY_ID), которому разрешено использовать данные зондирования от смартфона, имеющего вышеупомянутую идентификационную (ID) информацию. С вмешательством облачного сервера 5 M2M, сервер 6 сенсорной сети передает информацию сенсорного устройства, которую может использовать приложение 71 режима колонны (APPLY_ID=A1). В примере на фиг. 1 S_ID, соответствующая транспортному средству 2, разрешает (APPLY_ID={A1, A3}) использовать данные зондирования. То есть, в дополнение к приложению 71 режима колонны данные могут также использоваться в приложении 73 карты пробок (APPLY_ID=A3). Следует отметить, что процесс биллинга владельцу приложения 71 режима колонны также выполняется путем обращения к DB 62 договоров использования данных.

Облачный сервер 5 M2M хранит информацию (S_ID, S_DATA) из смартфона, принятую через сеть 4, в базе данных (блок накопления соответствует текущему положению и плану путешествия DB 301 на фиг. 3). Среди информационных элементов, сохраненных в DB 301, информационный элемент, имеющий S_ID, полученный от сервера 6 сенсорной сети (то есть информационный элемент, использование которого разрешено в приложении 71 режима колонны), передается серверу 7 приложений (S_ID, S_DATA). Следует отметить, что облачный сервер 5 M2M выполняет регистрацию или обновление базы данных по мере необходимости на основании результатов связи со смартфоном 3, расположенным в транспортном средстве 2 (соответствует S1041 на фиг. 2D).

(Операции во время управления движением колонны)

В процессе P301 в нижней левой части на фиг. 3 серверная сторона (облачный сервер 5 M2M в настоящем варианте воплощения) получает информацию (S_ID, S_DATA), переданную из смартфона 3, и сохраняет информацию в DB 301. С этого начинается процесс генерации движения в колонне.

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

То есть, в процессе генерации движения в колонне происходит обращение к DB 301, и в случае, когда число транспортных средств, которые следуют одним и тем же маршрутом в один и тот же период времени, является заранее заданным или большим числом, транспортные средства выбираются как группа. Данными движения в колонне являются данные, определенные посредством информации (S_ID) для идентификации выбранного транспортного средства, информации для идентификации секции (информации о секции на карте) и периода времени, эти данные указывают возможную колонну транспортных средств, которые движутся вместе в течение заранее заданного периода времени. Когда группа транспортных средств выбрана, транспортное средство может быть соответственно выбрано с использованием секции движения (а также направления движения) и периода времени как ключей. Чтобы сформировать как можно больше колонн, маршрут движения может быть разделен на секции в пределах, когда не возникает чрезмерное усложнение.

Альтернативно, при группировке транспортных средств, во-первых, может быть определена секция маршрута движения колонны, и могут быть выбраны транспортные средства, движущиеся по секции маршрута в один и тот же период времени.

Как показано на фиг. 3, в процессе P302 каждый из объектов управления движением в колонне (1-N) генерируется для каждого из элементов данных движения в колонне (1-N) путем многопоточной обработки сервером 7 приложений. Следовательно, число объектов управления движением в колонне соответствует числу колонн, которые могут быть сформированы в системе 1 управления трафиком. Когда колонна прибывает в пункт назначения и движение колонны завершается, объект управления движением в колонне, который управлял колонной, исчезает.

Основные процессы объекта управления движением в колонне соответствуют процессам P303 и P304. В P303 команда на управление движением колонны (NAVI_MSG на фиг. 1) передается транспортным средствам (2a-2n), которые участвуют в колонне. Транспортные средства, приняв командную информацию, управляются таким образом, как указано последовательностями операций на фиг. 2C и 2D, и, таким образом, реализуется движение колонны. В P304 команда, запрашивающая управление сигналом, передается устройству 8 управления сигналом светофора. Эта команда включает в себя информацию о положении целевого светофора и времени, когда загорается зеленый свет (PLACE, TIME). Затем, устройство управления сигналом светофора передает инструкцию включения и время включения зеленого света (SIG_CTRL, TIME) светофору 9. Таким образом, P303 и P304 выполняются в сочетании, и колонна имеет преимущество проезда. Объект управления движением в колонне обращается к DB 302, в которой сохранены данные дорожной сети и данные для связи с устройством управления сигналом светофора, для получения информации, необходимой в P303 и P304.

<Изменение состояния объекта управления движением в колонне>

Со ссылкой на фиг. 4 подробно рассматривается генерация и исчезновение объекта управления движением в колонне. На чертеже E0-E9 обозначают события, происходящие в колонне, в то время как S1-S6 обозначают состояния колонны.

<Относительно преференциального режима>

Здесь, в качестве предпосылки, описана зависимость между числом транспортных средств и преференциальными условиями в настоящем варианте воплощения. В настоящем варианте воплощения предполагается, что когда число транспортных средств удовлетворяет условию N1>N2, в случае, когда N1 или более транспортных средств участвуют в колонне, позволен преимущественный проезд на светофоре. Кроме того, предполагается, что в случае, когда N2 или более транспортных средств участвуют в колонне, преимущественный проезд не позволен, но получается некоторое преимущество на дорожной сети или некоторое экономическое преимущество. Примеры такого преимущества включают в себя применение скидки на плату за использование магистрали, скидки на топливо на бензозаправочной станции и бесплатное обслуживание на объектах для отдыха, таких как PA, SA и «Michinoeki». Кроме того, в настоящем варианте воплощения на число транспортных средств, которые участвуют в колонне, наложен верхний предел (N3), и влияние на транспортные средства, которые не участвуют в сенсорной сети, устраняется.

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

(Формирование и обслуживание колонны)

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

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

E2 обозначает, что число транспортных средств, составляющих колонну, становится не меньше N1, что удовлетворяет преференциальному условию, и средняя скорость движения становится надлежащей. Здесь средняя скорость движения рассматривается для обеспечения безопасного вождения, как было описано выше. При этом устанавливается состояние, когда присутствует транспортное средство, объединяющееся с колонной, в то время как осуществляется преимущественное движение (S3). Когда состояние S3 установлено, объект управления движением в колонне дает инструкцию, запрашивающую преимущество проезда колонны, устройству 8 управления сигналом светофора (P304 на фиг. 3).

E3 обозначает, что средняя скорость движения является ненадлежащей. В этом случае устанавливается состояние, когда колонна не может получить преимущество проезда (S6).

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

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

(Исчезновение колонны)

E7 обозначает, что число транспортных средств становится числом, при котором колонна не может сохраняться (становится не более 2 в настоящем варианте воплощения) из-за ухода транспортных средств. Это событие имеет место во время движения колонны, такого как S2, S3 или S4. При этом колонна приводится в состояние исчезновения (S5).

E8 обозначает, что все транспортные средства прибыли в пункт назначения во время движения колонны. При этом колонна также приводится в состояние исчезновения (S5).

После того как колонна исчезает с E7 или E8, исчезает объект управления движением в колонне. Альтернативно, при использовании объекта непрерывно также может быть назначено ведущее транспортное средство следующей движущейся колонны (событие E9). В этом случае состояние изменяется снова на S1.

<Преимущественный проезд на светофоре>

Со ссылкой на фиг. 5 описывается управление преимуществом колонны на светофоре перекрестка или т.п.

(Основной процесс предоставления преимущества)

На фиг. 5 группа транспортных средств, формирующих колонну 20A, которая должна получить преимущество, движется в направлении первого перекрестка 501a. Когда колонна приближается к точке на заранее заданном расстоянии (например, 300 м) от первого перекрестка 501a, устройство 8 управления сигналом светофора включает зеленый свет светофора на перекрестке. При этом колонна 20A может въехать на перекресток и проехать его не останавливаясь.

Кроме того, также может управляться светофор на следующем втором перекрестке 501b. В этом случае, как показано на чертеже, зеленый свет на первом перекрестке 501a и втором перекрестке 501b может быть включен одновременно. Альтернативно, также возможно осуществлять надлежащее управление путем включения зеленого света в момент въезда ведущего транспортного средства на каждый перекресток. В случае, когда используется этот способ управления, зеленый свет на втором перекрестке 501b может быть включен в момент времени, когда ведущее транспортное средство въезжает на промежуточную секцию 502, и зеленый свет может быть включенным до тех пор, пока колонна не проедет второй перекресток 501b.

(Дополнительный процесс предоставления преимущества)

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

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

(Конкуренция между колоннами)

В случае, когда одновременно присутствует множество колонн, служащих целями для преимущественного проезда, возникает проблема с тем, как обрабатывается конкуренция между колоннами. Например, когда колонна 20B собирается въехать на второй перекресток 501b с другого направления, необходим критерий для определения того, какая колонна имеет больший приоритет. Критерий определяется в соответствии с комплексной ситуацией в системе управления трафиком и степенью влияния на другие транспортные средства. Например, можно отдать приоритет колонне, имеющей большее число транспортных средств, или отдать приоритет колонне, имеющей большее число пассажиров, и, в случае последнего, поощряется, таким образом, совместное пользование автомобилем. Альтернативно, отдавая приоритет экологичным автомобилям, таким как гибридные автомобили, экономичные автомобили или электромобили (EV), поощряется переход на экологичные автомобили. Кроме того, приложение 71 режима колонны может регулировать скорости колонн, используя командную информацию, и смещать их время проезда перекрестка. Такая регулировка может быть реализована посредством обмена информацией между объектами управления движением в колонне.

[Модификация]

Описывается модификация, относящаяся к процессу создания плана путешествия. В варианте воплощения, описанном выше, автомобильное приложение 31, установленное в смартфоне 3, создает информацию о плане путешествия на основании текущего положения и пункта назначения транспортного средства (S1014 на фиг. 2B) и передает информацию о плане путешествия серверной стороне (S1031 на фиг. 2C). Однако также можно заставить серверную сторону выполнять процесс создания плана путешествия вместо выполнения процесса создания плана путешествия стороной транспортного средства.

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

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

[Второй вариант воплощения]

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

(Взаимное расположение, в котором удерживается заранее заданное расстояние от другого транспортного средства)

Во-первых, имеется управление, в котором целевое транспортное средство располагается на заранее заданном или большем расстоянии от другого конкретного транспортного средства. Например, транспортное средство, движущееся за автобусом как общественным транспортом, вынуждено останавливаться или перестраиваться на другую полосу из-за остановки автобуса на автобусной остановке. Это задерживает прибытие в пункт назначения, водитель, таким образом, испытывает стресс, и возникает, таким образом, остановка движения транспорта. Чтобы решить эту проблему, в командной информации от серверной стороны указывается навигация «не въезжайте в область в пределах 200 м позади автобуса на той же полосе». При этом становится возможным предотвратить возникновение вышеупомянутой проблемы. В этом случае информация о плане путешествия, относящаяся к другому транспортному средству, чем транспортное средство, для которого осуществляется навигация, такому как автобус и т.п., не обязательно должна быть получена путем осуществления связи с автобусом и т.п. Например, можно генерировать командную информацию для транспортного средства, для которого осуществляется навигация, путем обращения к базе данных, относящейся к работе общественного транспортного средства.

(Взаимное расположение в пределах заранее заданного расстояния от другого транспортного средства)

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

<Эффект настоящего изобретения>

Применяя настоящее изобретение, достигаются следующие преимущества.

(Преимущество для трафика в целом)

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

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

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

(Преимущество для водителя и т.п.)

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

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

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

(Преимущество сенсорной сети)

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

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

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

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

[Третий вариант воплощения]

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

<Управляемый по событиям тип режима доступа на стороне сенсора>

Фиг. 6A является видом для объяснения примера элементов системы и потока данных в настоящем варианте воплощения. Основные элементы включают в себя датчики (631A и 631B), адаптер 63 сенсорной сети, сервер 6 сенсорной сети, сервер 7 приложений и сеть 4, например, Интернет.

(Конфигурация устройства)

Каждый из датчиков (631A и 631B) является устройством, которое детектирует некоторые физические величины и их изменения, и записывает или выводит их как данные зондирования. Адаптер 63 сенсорной сети физически или электрически соединен с датчиком для получения данных зондирования. Кроме того, адаптер 63 сенсорной сети выполняет заранее заданный процесс над данными зондирования, используя устройство обработки информации, такое как CPU и т.п. Кроме того, адаптер 63 сенсорной сети имеет функцию связи с внешней стороной и может осуществлять связь с сервером 7 приложений и сервером 6 сенсорной сети через сеть 4.

Например, адаптером сенсорной сети 63 может считаться смартфон, а датчик положения (GPS) и датчик ускорения могут считаться датчиками 631A и 631B. В случае смартфона датчиком могут быть камера, микрофон или система ввода.

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

Сервер 7 приложений выполняет арифметическую обработку с использованием данных зондирования и генерирует различные единицы информации с различными целями. Например, можно предположить, что приложение информации о трафике, которое выполняет распространение ситуации о пробках и прокладку маршрута с использованием информации о положении и информации об ускорении каждого транспортного средства, выполняется на сервере 7k приложений, и можно предположить, что приложение исследования объема перевозок выполняется на сервере 7m приложений.

(Последовательность операций процесса)

Процедуры процесса описаны со ссылкой на блок-схемы последовательности операций на фиг. 7.

На этапе S701 датчик 631 получает данные зондирования.

На этапе S702 адаптер 63 сенсорной сети обнаруживает возникновение события (обведенная цифра 1 на фиг. 6A). Затем адаптер 63 сенсорной сети передает уведомление о событии на стороне датчика серверу сенсорной сети (обведенная цифра 2).

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

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

На этапе S703 адаптер сенсорной сети ищет метаданные приложения, которые соответствуют метаданным датчика 631A, записанным в DB 661 метаданных стороны датчика.

На этапе S703, когда соответствующее приложение присутствует, на этапе S704 сервер сенсорной сети создает команду управления потоком данных и передает команду управления потоком данных адаптеру сенсорной сети (обведенная цифра 3).

На этапе S705 адаптер 63 сенсорной сети, получив команду, передает данные зондирования (обведенная цифра 4) серверам 7k и 7m приложений через сеть 4.

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

На этапе S706 сервер приложений использует данные зондирования для предоставления услуги, имеющей добавленную стоимость.

(Структура данных и процесс сопоставления)

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

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

В DB 661 метаданных стороны датчика все метаданные регистрируются для каждого адреса датчика. Пример структуры данных показан на фиг. 12A. DB включает в себя информацию, относящуюся к датчику, и информацию, относящуюся к данным зондирования. Пример первой включает в себя «(4) ИДЕНТИФИКАТОР (ID) И АДРЕС ДАТЧИКА» под «1. ИНФОРМАЦИЯ ОБ АТРИБУТАХ ДАТЧИКА», и, таким образом, датчик может быть идентифицирован. Кроме того, вторая включает в себя код возникновения события, показанный на фиг. 6B. Путем использования кода возникновения события можно осуществлять сложное управление, в котором приложение выбирается в соответствии с типом события. Кроме того, можно реализовать периодическую связь и уведомление о возникновении события с помощью одного и того же протокола.

Метаданные стороны приложения регистрируются в DB 662 метаданных стороны приложения для каждого приложения. Пример структуры данных показан на фиг. 12B. DB включает в себя информацию, относящуюся к данным зондирования, необходимым приложению, и информацию самого приложения.

Адрес датчика получается путем анализа уведомления о событии на стороне датчика, принятом сервером 6 сенсорной сети, а в DB 661 метаданных стороны датчика производится поиск адреса датчика, используемого в качестве ключа. При этом происходит получение информации, показанной на фиг. 12A. Затем, сервер 6 сенсорной сети производит поиск в DB 662 метаданных стороны приложения для приложения, которому необходимы данные зондирования, полученные датчиком. В частности, информация датчика и данных зондирования сопоставляется с «1. ИНФОРМАЦИЯ ОБ АТРИБУТАХ НЕОБХОДИМОГО ДАТЧИКА» - «5. АТРИБУТ УПРАВЛЕНИЯ НЕОБХОДИМЫХ ДАННЫХ ЗОНДИРОВАНИЯ» на фиг. 12B, и в случае, когда установлено соответствие, данные используются. Может быть обеспечено допустимое отклонение, так что данные передаются, когда условие находится в заранее заданном диапазоне даже в случае, когда условие не полностью соответствует необходимому условию стороны приложения. Следует отметить, что условия при установлении соответствия включают в себя не только условия, связанные с типами датчика и данных зондирования, но также и условия компенсации за использование. С другой стороны, компенсация за использование может быть одним типом метаданных.

Существует случай, когда приложение идентифицируется путем сопоставления, или случай, когда таким образом идентифицируется множество приложений, и в случае, когда идентифицируется множество приложений, приложения могут выполняться на одном и том же сервере или различных серверах. Кроме того, существуют случаи, когда приложения осуществляют связь друг с другом и работают во взаимодействии друг с другом. Сервер 6 сенсорной сети обращается к «6. МЕТАДАННЫЕ САМОГО ПРИЛОЖЕНИЯ» на фиг. 12B для создания команды управления потоком данных и выдачи инструкции адаптеру 63 сенсорной сети.

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

<Управляемый по событиям тип режима доступа на стороне приложения>

Фиг. 8A является видом для объяснения другого примера, отличающегося от вышеописанного управляемого по событиям типа режима доступа на стороне датчика, который относится к элементам системы и потоку данных в настоящем варианте воплощения. Сами элементы являются такими же, как в примере выше, но отличается триггер начала процесса и процедуры.

(Последовательность операций процесса)

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

При получении уведомления об аварии на перекрестке приложение старается уменьшить объем перевозок на дороге, ведущей к перекрестку, путем использования уведомления об аварии в качестве триггера (обведенная цифра 1). Чтобы получить сенсорную информацию контролирующей камеры и транспортного средства в районе, приложение передает уведомление события на стороне приложения (обведенная цифра 2) серверу сенсорной сети. Как показано на фиг. 8B, предпочтительно осуществлять точное управление, добавляя информацию, такую как код события и т.п., к этому уведомлению.

Сервер 6 сенсорной сети передает команду управления потоком данных, показанную на фиг. 8B, адаптеру 63 сенсорной сети (обведенная цифра 3). Аналогично фиг. 6B, детали команды включают в себя информацию об адресе назначения данных. Адаптер 63 сенсорной сети, приняв команду, передает данные зондирования от датчика 631A (обведенная цифра 4) с использованием системы пакетной передачи, к которой добавляется заранее заданный заголовок, через сеть 4 (обведенная цифра 5). Например, информация о положении собирается, когда датчик является установленным на транспортном средстве GPS, данные изображения или информация, полученные путем анализа данных изображения на стороне адаптера, собираются, когда датчик соответствует изображению, снятому контролирующей камерой на обочине. Приложение системы управления трафиком (имя m файла) на сервере приложений 7m определяет условия трафика с использованием собранной информации и выполняет светофорное регулирование и предоставление информации электронному информационному стенду на обочине.

<Управляемый по метаданным тип режима доступа на стороне датчика>

Фиг. 9A является видом для объяснения другого примера, отличающегося от примеров выше, который относится к элементам системы и потоку данных в настоящем варианте воплощения. Среди элементов системы отсутствует DB 661 метаданных стороны датчика сервера 6 сенсорной сети.

(Последовательность операций процесса)

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

Датчик 631A в качестве установленной на транспортном средстве камеры получает динамическое изображение в качестве данных зондирования. Адаптер 63 сенсорной сети детектирует это как возникновение события (обведенная цифра 1) и передает метаданные стороны датчика (обведенная цифра 2). Как показано на фиг. 9B, это включает в себя метаданные, показанные на фиг. 12A, и датчик идентифицируется с помощью адреса датчика в метаданных. Также предпочтительно осуществлять точное управление путем добавления информации, такой как код события и т.п., к этому уведомлению. Сервер 6 сенсорной сети устанавливает соответствие путем сравнения принятых метаданных стороны датчика с DB 662 метаданных стороны приложения для создания команды управления потоком данных (обведенная цифра 3). Следует отметить, что принятые метаданные могут быть зарегистрированы в устройстве хранения (не показано). При этом управляемый по событиям тип режима доступа на стороне датчика и настоящий режим доступа могут использоваться беспроблемно.

Адаптер 63 сенсорной сети, приняв команду управления потоком данных, передает динамическое изображение в качестве данных зондирования (обведенная цифра 4) с использование системы пакетной передачи, к которой добавляется заранее заданный заголовок, через сеть 4 (обведенная цифра 5). Приложение распространения изображений (имя m файла) на сервере 7k приложений предоставляет услугу с использованием полученных данных.

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

<Управляемый по метаданным тип режима доступа на стороне приложения>

Фиг. 10A является видом для объяснения другого примера, отличающегося от примеров выше, который относится к элементам системы и потоку данных в настоящем варианте воплощения. Среди элементов системы отсутствует DB 662 метаданных стороны приложения сервера 6 сенсорной сети.

(Последовательность операций процесса)

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

Автомобильное навигационное приложение обеспечивает ситуацию на небольшом расстоянии вперед или несколькими минутами позже путем использования возникновения события, такого как запрос на прокладку маршрута и т.п. от водителя, попавшего в пробку, в качестве триггера (обведенная цифра 1). Чтобы получить сенсорную информацию контролирующей камеры и транспортных средств в районе, метаданные стороны приложения передаются серверу 6 сенсорной сети (обведенная цифра 2). Как показано на фиг. 10B, они включают в себя метаданные, показанные на фиг. 12B. Также предпочтительно осуществлять точное управление путем добавления информации, такой как код события и т.п., к этому уведомлению.

Сервер сенсорной сети 6 устанавливает соответствие между принятыми метаданными и DB 661 метаданных стороны датчика для идентификации датчика, который может предоставить данные зондирования, необходимые приложению. Затем создается команда потока данных и передается адаптеру 63 сенсорной сети (обведенная цифра 3). Следует отметить, что принятые метаданные могут быть зарегистрированы в устройстве хранения (не показано).

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

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

<Режим управления с использованием DB данных зондирования>

Фиг. 11A является видом для объяснения другого примера, отличающегося от примеров выше, который относится к элементам системы и потоку данных в настоящем варианте воплощения. В качестве элемента системы DB 1101 данных зондирования расположена на платформе облака 110 M2M, и запись 1103 сохраняется в DB 1101 данных зондирования. Кроме того, на сервере 6 сенсорной сети присутствует DB 663 метаданных данных зондирования. Кроме того, как описано ниже, также отличается формат команды управления потоком данных, как признак настоящего изобретения.

(Последовательность операций процесса)

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

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

Сервер 6 сенсорной сети устанавливает соответствие между принятыми метаданными и DB 663 метаданных данных зондирования для определения, могут ли быть предоставлены прошлые данные зондирования, требуемые приложением, из DB в облаке M2M. Затем создается команда управления потоком данных и передается облаку 110 M2M (обведенная цифра 3). Следует отметить, что принятые метаданные могут быть зарегистрированы в устройстве хранения (не показано). Как показано на фиг. 11B, команда управления потоком данных включает в себя информацию, которая идентифицирует запись в DB облака M2M.

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

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

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

<Переключение режима доступа>

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

<Пример процесса регистрации/обновления DB метаданных>

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

(Случай, когда метаданные стороны датчика были недавно зарегистрированы/обновлены)

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

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

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

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

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

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

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

<Конфигурация метаданных>

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

(Метаданные датчика и данных зондирования)

На фиг. 12A «1. ИНФОРМАЦИЯ ОБ АТРИБУТАХ ДАТЧИКА» является информацией о самом датчике, и, в частности, «(4) ИДЕНТИФИКАТОР (ID) И АДРЕС ДАТЧИКА» служит ключом для идентификации датчика при сопоставлении. «2. ИНФОРМАЦИЯ ОБ АТРИБУТАХ ЦЕЛИ ЗОНДИРОВАНИЯ» и «3. ИНФОРМАЦИЯ ОБ АТРИБУТАХ РАЙОНА ЦЕЛИ ЗОНДИРОВАНИЯ» служат материалами для определения, получены ли данные, необходимые приложению с точки зрения типа. «4. ИНФОРМАЦИЯ ОБ АТРИБУТАХ ОПЕРАЦИИ ЗОНДИРОВАНИЯ» служит материалом для определения, получена ли точность данных, необходимая приложению. «5. АТРИБУТ УПРАВЛЕНИЯ ДАННЫХ ЗОНДИРОВАНИЯ» используется, когда установлена компенсация за использование, требуемая при распределении данных, и величина надежности данных.

(Метаданные приложения и данных зондирования, необходимых приложению)

На фиг. 12B «1. ИНФОРМАЦИЯ ОБ АТРИБУТАХ НЕОБХОДИМОГО ДАТЧИКА», «2. ИНФОРМАЦИЯ ОБ АТРИБУТАХ НЕОБХОДИМОЙ ЦЕЛИ ЗОНДИРОВАНИЯ», «3. ИНФОРМАЦИЯ ОБ АТРИБУТАХ НЕОБХОДИМОГО РАЙОНА ЦЕЛИ ЗОНДИРОВАНИЯ» и «4. ИНФОРМАЦИЯ ОБ АТРИБУТАХ НЕОБХОДИМОЙ ОПЕРАЦИИ ПО ЗОНДИРОВАНИЮ» необходимы для идентификации запроса приложения при сопоставлении. «5. АТРИБУТ УПРАВЛЕНИЯ НЕОБХОДИМЫХ ДАННЫХ ЗОНДИРОВАНИЯ» также используется при сопоставлении вместе с компенсацией за использование и надежностью. «6. МЕТАДАННЫЕ САМОГО ПРИЛОЖЕНИЯ» необходимы, когда генерируется команда управления потоком данных. Например, в случае, когда код события в уведомлении о событии соответствует «(3) СОБЫТИЕ СТОРОНЫ ДАТЧИКА, РАЗРЕШАЮЩЕЕ АКТИВАЦИЮ ПРИЛОЖЕНИЯ» в метаданных стороны приложения, и другие элементы метаданных соответствуют друг другу, приложение может быть активировано с помощью прерывания со стороны датчика.

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

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

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

Список ссылочных позиций

1: система управления трафиком

2: транспортное средство, 20: автомобильная колонна

3: смартфон, 31: автомобильное приложение

4: мобильная сеть

5: облачный сервер M2M

6: сервер сенсорной сети

7: сервер приложений, 71: приложение режима колонны

8: устройство управления сигналом свефотора

9: светофор

63: адаптер сенсорной сети, 631A-631B: датчик

661: DB метаданных стороны датчика, 662: DB метаданных стороны приложения.

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

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

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

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

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

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

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

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

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

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

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

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