Полный исходный код этого приложения доступен на GitHub.

Исходный код разделен на четыре каталога:

  • ttoApp — исходный код мобильного приложения TTO на базе Cordova и Android
  • ttoBackground — исходный код фонового скрипта
  • ttoServer — исходный код сервера приложений
  • ttoTest — исходный код тестового скрипта для вызова оповещений в реальном времени.

Подробные пошаговые инструкции по развертыванию приложения в IBM Bluemix и работе с мобильным приложением TTO см. в файле README.

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

Вам также понадобится экземпляр базы данных MongoDB для хранения исторических данных о трафике. Для этого проекта мы используем хостинг MongoDB mLab.

Резюме из части 1

Это приложение пытается ответить на извечный вопрос, который задает каждый путешественник перед тем, как отправиться в путешествие: «Когда мне начать?» Цель механизма рекомендаций TTO — не только предоставить определенные варианты ответа на этот вопрос, но и предоставить рекомендации в режиме реального времени о трафике на основе надвигающихся факторов.

Процесс создания этого механизма рекомендаций можно разбить на два этапа, которые я представил ранее:

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

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

Получение прогнозов

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

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

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

Вот как выглядит ход процесса:

Чтобы обеспечить управляемость данными и снизить нагрузку на наш алгоритм KNN, сбор данных выполняется с 10-минутными интервалами, поэтому предварительные прогнозы доступны каждые 10 минут. Это означает, что если текущее время 10:30, то 12-часовой предварительный прогноз доступен для 10:30. до 22:30 каждые 10 минут, начиная с 10:30, 10:40, 10:50 и так далее до 22:30.

Генерация рекомендаций

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

  • Прогнозируемое время отправления (PDT)
  • Прогнозируемое время прибытия (PAT)
  • Тип рекомендации
  • Дельта желаемого времени прибытия (DAT▲)

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

Значения Прогнозируемое время отправления и Прогнозируемое время прибытия говорят сами за себя. Последнее сообщение «Вы опоздаете на 3 минуты» содержит тип рекомендации и значение DAT▲. Значение 3 (минуты) представляет собой дельту между выбранным пользователем DAT и прогнозируемым временем прибытия, а «опоздание» представляет тип рекомендации.

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

Алгоритм генерации рекомендаций

Чтобы предоставить пользователю сбалансированный вариант, система должна предоставлять рекомендательные значения «Рано» или «Поздно». Единственным исключением является «OnTime»; если доступна рекомендация «Вовремя», то пользователю будет представлена ​​только эта рекомендация.

Давайте посмотрим, как работает алгоритм генерации рекомендаций. Есть три входных параметра для алгоритма:

  • Выбранный маршрут — один из предопределенных маршрутов, выбранных пользователем.
  • Желаемое время прибытия (DAT) – время, когда пользователь хочет добраться до пункта назначения.
  • Теоретическая продолжительность поездки (TTD) — время, необходимое для поездки из пункта отправления в пункт назначения по выбранному маршруту в идеальных условиях без движения; этот параметр также доступен в MapQuest API.

Вот блок-схема этого алгоритма:

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

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

Алгоритм выведет либо:

  • одну рекомендацию «OnTime» или
  • Одна «Ранняя» и одна «Поздняя» рекомендация с наименьшим значением DAT▲.

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

На следующем рисунке показано, как первоначально выводится RRST, а затем сдвигается через несколько проходов выполнения, чтобы получить рекомендацию «Раннее» или «Позднее»:

Процесс подачи заявки

Процесс для мобильного приложения ttoApp выглядит следующим образом:

  1. Пользователь запускает приложение TTO, выбирает маршрут поездки и желаемое время прибытия, а затем нажимает «Отправить».

  1. Приложение TTO отправляет запрос в механизм рекомендаций TTO, который размещается подttoServer. Механизм рекомендаций TTO запускает алгоритм и возвращает рекомендации.

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

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

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

Наконец, когда пользователь выбирает «Завершить путешествие», приложение закрывает сеанс с сервером.

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

Обмен сообщениями клиент-сервер

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

Вот как приложение TTO взаимодействует с сервером TTO/механизмом рекомендаций:

Вывод

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