Добавление фона "сообщения из черного ящика" в график отчета

На русский можно перевести? )

Тогда есть риск нос к носу столкнуться с ограничениями по количеству датчиков в одном графике ) Из-за "лишнего" датчика )

Я спросил, потому что попробовал сделать отчет с таким датчиком и не увидел в нем полную достоверность с действительностью. Действительность была наглядной: трекер до определенной даты и времени был без СИМ-карты и записывал все "в себя", а после установки СИМ-карты и после создания объекта с данными трекера, прибор появился на связи и начал выгружать все накопленное. Созданный новый датчик по Вашей "формуле" что-то показывает, но ничего нужного для информации о промежутках времени, когда прибор был без соединения с сервером.
Опять же, зачем зафлуживать тему, в которой речь о конкретном предложении, которое, уверен, будет полезно всем коллегам?.

Что Вы подразумеваете под "нет связи": 1)нет приема сигнала сотовой связи; 2)емть сигнал сотовой связи, но нет GPRS; 3)есть сигнал сотовой связи есть GPRS, но не принимает пкеты сервер; 4)есть сигналы сотовой связи, есть GPRS, сервер работает, но неисправна или отсутствует СИМ-карта? О чем конкретно говорит Ваша формула - о всех вариантах, или только о некоторых из них?
Не сложно увидеть данные о видимости спутников. Не сложно увидеть и данные о наличии сетей сотовой связи. Но получить данные о потере соединения с сервером и отсутствии передачи данных, и о восстановлении соединения с сервером и передачи данных полезно, но имеющимися инструментами, на сколько я знаю, невозможно.

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

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

mapa, я попробую объяснить на примере со стороны отношений Исполнитель-Клиент.
1) Клиент жалуется, что часто его объекты "замирают", стоят на месте, тогда как фактически они давно находятся уже далеко. По факту обращения начинается просмотр сообщений и отчетов. Выясняется сначала, что прибор отдавал все точки, пропусков трека нет. Анализ данных о сигналах ГЛОНАСС и GSM позволяет понять, что послужило причиной недовольства клиента. Причем, выделение сообщений из черного ящика другим цветом существенно облегчило задачу и ускорило анализ ситуации. Тем не менее, клиент раздражен, пока не получит адекватный отчет по заявке, который удовлетворит его. Потому сроки "разбора полетов" существенно влияют на спокойствие клиентов.
2) Аналогичная ситуация, но анализ по сообщениям не принес каких-либо результатов: всё работало, все сигналы в норме, но сообщения "синие".
Не знаю, как в других регионах, но у нас в работу ССМ часто вмешивается качество услуг мобильной связи. И выявить неудовлетворительную их работу, а, следовательно, добиться восстановления нормальной работы оборудования получается долго и сложно. Самым оперативным методом поиска проблем, на мой взгляд, является графическая информация. Во-первых, "картинка" уровня сети покрытия GSM на карте на основе оперативных данных с трекеров, подключенных на WH, поможет сразу же связать проблему с отсутствием мобильной связи, либо искать причину в другом месте.И если данные трекера об уровне сигнала могут могут быть не объективными по разным причинам (неисправность антенны/кабеля, глушилки, и т.п.) и "карта" покрытия мобильных операторов больше для оперативности и удобства обслуживания, то данные, которые могут быть доступны только Гуртам, являются более объективными и точными. Речь о передаче пакетов от трекера на сервер WH. Я писал выше, что проблемы в работе операторов мобильной связи выражаются далеко не всегда в полном отсутствии связи. Очень часто при наличии приема сигналов GSM отсутствует передача данных либо полностью, либо на ряд "направлений". Информация о периодах "нарушения" передачи данных между трекером и сервером в графическом виде будет наиболее наглядной и полезной при анализе работы сети спутникового мониторинга. "Появление" объекта на карте после пропадания связи может зависеть от настроек трекера настройка очередности отправки пакетов), от времени восстановления уверенного приема сигналов GSM, от восстановления передачи данных между трекером и сервером. Если первые два интеграторы могут более менее контролировать, то по последнему информация у них отсутствует. А очень хотелось бы.

Речь была о вариантах использования ССМ: 1) сидеть и пялиться в монитор, и 2) смотреть историю.

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

Если бы были решены все проблемы с некачественными услугами, то на Земле наступил бы рай. )) Важнее чаще не решение проблемы, а спокойствие клиента, что "все под контролем, все делается, а причина в том/этом"

Об этом может мало говорят, но я уверен, что встречаются с этим практически все. Чаще необходимость возникает при работе с клиентом, у которого сервисом ССМ пользуются одни, заявки пишут другие, а по разбору полетов звонят третьи или сами руководители. Раньше, когда сообщения, выгруженные из памяти прибора, цветом не выделялись, еще чаще подобные проблемы всплывали, из-за которых недовольство клиента росло, а исполнитель не понимал, что от него хотят: вроде и жалуются, что их объекты "не едут", а сообщения все на месте, отчеты бьются, и трек красивый. В итоге вроде и ложечка на месте, и почистили даже ее, а осадочек у клиента остался. Потому что не хватает данных о том, когда реально начался или оборвался обмен данными между объектом и сервером, и в каком месте был и что делал сам объект. К слову, опсосы почти всегда отнекиваются от того, что у них есть или были проблемы в сети, а иногда и не спешат выезжать на удаленные объекты исправлять ситуацию, ссылаясь, что "это у вас там что-то не работает".