Emerson go real time lux что это

Emerson внедряет технологию 4G / Cat-M в GO Tracker следующего поколения GO

Emerson внедряет технологию 4G / Cat-M в GO Tracker следующего поколения GO

Сегодня на конференции Fruit Logistica компания Emerson объявила о выпуске нового поколения GO Real-Time Tracker, основанного на технологии 4G / Cat-M. Это последнее нововведение дополняет полный набор продуктов для отслеживания Emerson и помогает обеспечить доступ к критически важным данным холодовой цепи в динамичном и меняющемся сотовом ландшафте.

Поскольку глобальные провайдеры сотовой связи постепенно сокращают свои сети 2G и 3G, Emerson является лидером в отрасли холодовых цепей, предоставляя надежные возможности подключения с помощью новых технологий, таких как категория M, «Cat-M» и узкополосный Интернет вещей, или «NB- IoT». Крупные операторы уже развернули обширную инфраструктуру для размещения этих новых сетей, что позволит постоянно расширять приложения IoT, подобные тем, которые используются для мониторинга грузов.

Новый GO Real-Time 4G / Cat-M Tracker может отслеживать условия в пути, такие как температура, местоположение, освещенность и влажность, в течение 20 дней непрерывной работы. Трекер может быть настроен на уведомление пользователей в режиме реального времени с помощью текста или электронной почты, если при транспортировке возникают какие-либо неблагоприятные условия. Устройство включает в себя возможность подключения 2G в качестве запасного варианта для регионов, которые еще не модернизировали свою сотовую инфраструктуру, а также будет поддерживать новые сети 5G по мере их появления. Emerson планирует выпустить дополнительные модели 4G / Cat-M с увеличенным сроком эксплуатации до 60 дней в ближайшие месяцы.

Теперь Emerson предлагает полный набор трекеров 2G, 2G / 3G и 4G / Cat-M для одноразовых и многоразовых моделей. Клиенты могут отслеживать свои поставки, используя облачный портал Oversight или мобильное приложение Oversight, чтобы отслеживать свои поставки в реальном времени, от начала до конца. Чтобы загрузить приложение или получить дополнительную информацию о комплексных решениях для контроля холодовой цепи, посетите веб-сайт Emerson.com/Cargo.

Уже доступны опытные образцы новых трекеров GO Real-Time 4G / Cat-M с объемами производства, которые появятся во втором квартале 2020 года. Ваш торговый представитель вскоре свяжется с вами, чтобы обсудить ваши планы перехода в преддверии подготовки 2G в США. и Канаде, что произойдет позже в этом году.

Источник

Измерители-регистраторы температуры однократного применения GO Real-Time

Скачать

Информация по Госреестру

Производитель / Заявитель

Фирма: Locus Solutions, LLC, США (Завод-изготовитель Shenzhen Zhenhua Communication Equipment Co.Ltd., Китай)

Назначение

Описание

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

Терморегистраторы изготавливаются следующих моделей: GO Real-Time, GO Real-Time Lux и GO Real-Time XL, различающихся по метрологическим и техническим характеристикам.

Терморегистраторы представляют собой автономный программируемый самописец, фиксирующий температуру в течение заданного времени и с заданным временным интервалом записи. Запись установочных параметров в терморегистраторы осуществляется при помощи программного обеспечения на предприятии-изготовителе и не подлежит изменению в процессе эксплуатации. Считывание информации, накопленной в терморегистраторах, производится в режиме реального времени при помощи облачного сервиса Emerson Oversight, а также в виде отчетного файла формата «.pdf» или «.xlsx».

Терморегистраторы имеют встроенную SIM карту для отслеживания местоположения по базовым станциям сотовой связи (частоты 850/900/1800/1900 МГц). Данные измерений и навигационные координаты местонахождения терморегистраторов передаются на удаленный сервер облачного сервиса Emerson Oversight. Считывание информации возможно, как в онлайн-режиме, так и за выбранный прошедший промежуток времени.

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

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

Пломбирование терморегистраторов не предусмотрено.

Программное обеспечение

Программное обеспечение (ПО) терморегистраторов состоит из встроенного и автономного ПО.

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

Автономная часть ПО представляет собой облачный сервис Emerson Oversight, доступ к которому осуществляется при помощи персонального компьютера или через одноименное приложение, установленное на мобильные устройства с операционными системами Android или iOS. Автономное ПО применяется для программирования пределов срабатывания сигнализации и обработки результатов измерений каждого зарегистрированного терморегистратора (нахождение максимального, минимального и среднего значения температуры з а заданный период), и формирования отчетов за определенный промежуток времени в форме графиков и таблиц по каждой позиции измерения.

Данное ПО также позволяет:

— создавать точные и полные копии записей путем экспорта данных в формате Excel или PDF (по выбору пользователя) для представления на электронном или бумажном носителе;

— осуществлять защиту хранящихся в базе данных от корректировок;

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

Технические характеристики

Метрологические и основные технические характеристики терморегистраторов приведены в таблицах 1-2.

Диапазон измерений температуры, °С

Пределы допускаемой абсолютной погрешности измерений температуры, °С:

Разрешающая способность показаний, °С

Напряжение питания, В

3,7 (от литий-полимерного аккумулятора)

Срок службы аккумуляторной батареи, суток:

— GO Real-Time, GO Real-Time Lux (при интервале регистрации температуры равном 6 минут и интервале передачи данных равном 18 минут)

Габаритные размеры, мм, не более:

— GO Real-Time, GO Real-Time Lux

— GO Real-Time, GO Real-Time Lux

Рабочие условия эксплуатации:

— температура окружающего воздуха,°С

— относительная влажность воздуха, %, не более

Интервал измерения температуры, мин.:

— GO Real-Time, GO Real-Time Lux

Максимальное время регистрации измерений в памяти терморегистратора после запуска, суток (с момента запуска):

— GO Real-Time, GO Real-Time Lux

Срок хранения до запуска, месяцев, не более

Измеритель-регистратор температуры однократного применения

В соответствии с заказом

Руководство по эксплуатации (на русском языке)

Сведения о методах измерений

приведены в разделе 3 «Основные параметры и характеристики оборудования» Руководства по эксплуатации.

Нормативные документы

ГОСТ Р 52931-2008 Приборы контроля и регулирования технологических процессов. Общие технические условия.

ГОСТ 8.558-2009 ГСИ. Государственная поверочная схема для средств измерений температуры.

Техническая документация фирмы-изготовителя.

Источник

Centrifugo v2 — будущее сервера real-time сообщений и библиотека для Go

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

Меня зовут Александр Емелин. Летом прошлого года я присоединился к команде Авито, где сейчас помогаю разрабатывать бэкенд мессенджера Авито. Новая работа, напрямую связанная с быстрой доставкой сообщений пользователям, и новые коллеги вдохновили меня продолжать работу над open-source проектом Centrifugo.

В двух словах — это сервер, который берет на себя задачу держать постоянные соединения от пользователей вашего приложения. В качестве транспорта используется Websocket или полифилл SockJS, умеющий, при невозможности установить Websocket-соединение, работать через Еventsource, XHR-streaming, long-polling и другие основанные на HTTP транспорты. Клиенты подписываются на каналы, в которые бекенд через API Центрифуги публикует новые сообщения по мере их возникновения – после чего сообщения доставляются подписанным на канал пользователям. Другими словами – это PUB/SUB сервер.

На текущий момент сервер используется в достаточно большом количестве проектов. Среди них, например, некоторые проекты Mail.Ru (интранет, обучающие платформы Технопарк/Техносфера, центр Сертификации и др.), с помощью Centrifugo работает красивейший дашборд на ресепшн в московском офисе Badoo, а в сервисе spot.im 350 тысяч пользователей одновременно подключены к Центрифуге.

Несколько ссылок на предыдущие статьи, посвященные серверу и его применению, для тех, кто первый раз слышит про проект:

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

Real-time библиотека для Go

В Go-сообществе время от времени встает вопрос — а есть ли альтернативы socket.io на Go? Иногда я замечал, как разработчики в ответ на это советуют посмотреть в сторону Centrifugo. Однако Centrifugo это self-hosted сервер, а не библиотека — сравнение не справедливое. Также несколько раз меня спрашивали, можно ли переиспользовать код Centrifugo для того, чтобы писать real-time приложения на языке Go. И ответ был: теоретически можно, но на свой страх и риск — обратную совместимость API внутренних пакетов я гарантировать не мог. Понятно, что рисковать так никому причин особых нет, а форкать тоже вариант так себе. Плюс я бы не сказал, что API внутренних пакетов вообще было подготовлено к такому использованию.

Поэтому одна из амбициозных задач, которые я хотел решить в процессе работы над второй версией сервера — попытаться выделить ядро сервера в отдельную библиотеку на Go. Я верю, что это имеет смысл, принимая во внимание, сколько фич имеет Центрифуга для того, чтобы быть приспособленной к production. Есть много доступных из коробки особенностей, призванных помочь с построением масштабируемых real-time приложений, снимая с разработчика необходимость писать собственное решение. Об этих особенностях я писал ранее и еще обозначу некоторые из них ниже.

Попробую обосновать еще один плюс существования такой библиотеки. Большинство пользователей Centrifugo — это разработчики, которые пишут бекенд на языках/фреймворках со слабой поддержкой concurrency (например, Django/Flask/Laravel/. ): работать с большим количеством постоянных соединений если и можно, то неочевидным или неэффективным способом. Соответственно, помочь с разработкой сервера, написанного на Go, могут далеко не все пользователи (банально из-за незнания языка). Поэтому даже совсем небольшое community Go-разработчиков вокруг библиотеки сможет помочь и в развитии использующего ее сервера Centrifugo.

В итоге получилась библиотека Centrifuge. Это все еще WIP, но абсолютно все заявленные в описании на Github фичи реализованы и работают. Поскольку библиотека предоставляет достаточно богатое API, прежде чем гарантировать обратную совместимость, хотелось бы услышать о нескольких успешных примерах использования в реальных проектах на Go. Таких пока нет. Равно как и неуспешных:). Никаких нет.

Я понимаю, что, назвав библиотеку практически так же как сервер, буду вечно иметь дело с путаницей. Но я считаю это правильный выбор, так как клиенты (такие как centrifuge-js, centrifuge-go) работают и с библиотекой Centrifuge, и с сервером Centrifugo. Плюс название уже достаточно прочно закрепилось в умах пользователей, и не хочется эти ассоциации терять. И все же для чуть большей ясности уточню еще раз:

Centrifugo из-за своего дизайна (отдельно стоящий сервис, не знающий о вашем бекенде ничего) предполагает, что поток сообщений по real-time транспорту будет идти от сервера клиенту. Что имеется в виду? Если, например, пользователь пишет сообщение в чат, то это сообщение нужно сначала отправить на бекенд приложения (например, AJAX-ом в браузере), на стороне бекенда его провалидировать, сохранить в базу данных при необходимости, а затем отправить в API Центрифуги. Библиотека это ограничение снимает, позволяя организовать двунаправленный обмен асинхронными сообщениями между сервером и клиентом, а также RPC-вызовы.

Давайте посмотрим на простой пример: реализуем небольшой сервер на Go с использованием библиотеки Centrifuge. Сервер будет принимать сообщения от браузерных клиентов по Websocket, на клиенте будет текстовое поле, в которое можно вбить сообщение, нажать Enter — и сообщение отправится всем подписанным на канал пользователям. То есть максимально упрощенный вариант чата. Мне показалось, что удобнее всего будет разместить это в виде gist.

Запустить можно как обычно:

И затем переходите по адресу http://localhost:8000, откройте несколько вкладок браузера.

Как вы можете заметить, точка входа в бизнес-логику приложения происходит при навешивании On().Connect() коллбек-функции:

Подход на основе callback-функций мне показался наиболее удобным для взаимодействия с библиотекой. Плюс похожий, только слабо типизированный, подход применяется в реализации socket-io сервера на Go. Если вдруг у вас есть мысли, как API можно было бы сделать более идиоматично — буду рад услышать.

Это очень простой пример, который не демонстрирует всех возможностей библиотеки. Кто-то может отметить, что для таких целей проще взять библиотеку для работы с Websocket. Например, Gorilla Websocket. Это на самом деле так. Правда, даже в таком случае вам придется скопировать приличный кусок кода сервера из примера в репозитории Gorilla Websocket. А что если:

Библиотека Centrifuge может вам с этим помочь — по сути она унаследовала все основные возможности, которые раньше были доступны в Centrifugo. Больше примеров, демонстрирующих заявленные выше пункты, можно найти на Github.

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

В библиотеке есть некоторые оптимизации, которые позволяют более эффективно использовать ресурсы. Это объединение нескольких сообщений в один Websocket frame для экономии на системных вызовах Write или, например, использование Gogoprotobuf для сериализации Protobuf сообщений и другие. Кстати о Protobuf.

Бинарный Protobuf протокол

Я очень хотел, чтобы Centrifugo могла работать с бинарными данными (и не только я), поэтому в новой версии хотелось добавить бинарный протокол помимо имеющегося на основе JSON. Теперь весь протокол описан в виде Protobuf-схемы. Это позволило сделать его более структурированным, переосмыслить некоторые неочевидные решения в протоколе первой версии.

Думаю, не нужно долго рассказывать какие есть преимущества у Protobuf над JSON — компактность, скорость сериализации, строгость схемы. Есть и недостаток в виде нечитаемости, однако теперь у пользователей есть возможность решить, что им важнее в той или иной ситуации.

В целом трафик, генерируемый протоколом Centrifugo при использовании Protobuf вместо JSON, должен уменьшиться в

2 раза (без учета данных приложения). В те же

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

Интереса ради я запустил на машине с Debian 9.4 и 32-мя Intel® Xeon® Platinum 8168 CPU @ 2.70GHz vCPU бенчмарк, который позволил сравнить пропускную способность клиент-серверного взаимодействия в случае использования JSON-протокола и Protobuf-протокола. Было 1000 подписчиков на 1 канал. В этот канал в 4 потока публиковались сообщения и доставлялись всем подписчикам. Размер каждого сообщения составлял 128 байт.

Результаты для JSON:

Результаты для Protobuf случая:

Можно заметить что пропускная способность такой установки в 2 с лишним раза больше в случае Protobuf. Клиентский скрипт можно найти вот тут — это адаптированный под реалии Centrifuge бенчмарк-скрипт Nats.

Стоит также отметить, что производительность сериализации JSON на сервере можно «прокачать» используя тот же самый подход, что и в gogoprotobuf — пул буферов и генерацию кода — в данный момент JSON сериализуется пакетом из стандартной библиотеки Go, построенном на reflect. Например, в Centrifugo первой версии JSON сериализуется вручную с использованием библиотеки, предоставляющей пул буферов. Что-то подобное можно будет в будущем сделать и в рамках второй версии.

Стоит подчеркнуть, что protobuf можно использовать и при общении с сервером из браузера. Javascript клиент использует для этого библиотеку protobuf.js. Так как библиотека protobufjs достаточно тяжелая, а количество пользователей бинарного формата будет невелико, с помощью webpack и его tree shaking алгоритма мы генерируем две версии клиента — одна только с поддержкой JSON протокола, а другая с поддержкой и JSON, и protobuf. Для других сред, где размер ресурсов не играет столь критичной роли, клиенты могут о таком разделении не беспокоиться.

JSON Web Token (JWT)

Одна из проблем в использовании такого standalone сервера, как Centrifugo, состоит в том, что он ничего не знает о ваших юзерах и методе их аутентификации, о том, какой механизм сессий использует ваш бекенд. А аутентифицировать подключения каким-то образом нужно.

Для этого в Центрифуге первой версии при подключении использовалась SHA-256 HMAC подпись, основанная на секретном ключе, известном только бекенду и Центрифуге. Это гарантировало то, что передаваемый клиентом User ID действительно принадлежит ему.

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

Когда Центрифуга появилась, стандарт JWT еще не был столь популярен. Сейчас, несколько лет спустя, библиотеки для генерации JWT есть для большинства популярных языков. Основная идея JWT — именно та, что нужна Центрифуге: подтверждение подлинности передаваемых данных. Во второй версии HMAC подпись, генерируемая вручную, уступила место использованию JWT. Это позволило убрать необходимость поддержки функций-хелперов для правильной генерации токена в библиотеках для разных языков.

Например, на Python токен для подключения к Centrifugo можно сгенерировать следующим образом:

Важно отметить, что в случае использования библиотеки Centrifuge аутентифицировать пользователя можно нативным для языка Go способом — внутри middleware. Примеры есть в репозитории.

В процессе разработки я попробовал GRPC bidirectional streaming в качестве транспорта для общения между клиентом и сервером (помимо Websocket и основанных на HTTP фоллбеков SockJS). Что можно сказать? Он работал. Однако я не нашел ни одного сценария, где двунаправленный стриминг GRPC был бы лучше, чем Websocket. Я смотрел в основном на метрики сервера: на генерируемый трафик через сетевой интерфейс, на потребление CPU сервером при наличии большого кол-ва входящих соединений, на потребление памяти на соединение.

GRPC уступил Websocket по всем статьям:

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

Однако GRPC хорош в том, для чего он в первую очередь создавался — для генерации кода, позволяющего по заранее определенной схеме делать RPC-вызовы между сервисами. Поэтому помимо HTTP API в Центрифуге теперь будет и поддержка API на основе GRPC, например, для публикации новых сообщений в канал и других доступных методов серверного API.

Сложности с клиентами

Изменениями, сделанными во второй версии, я убрал обязательность поддержки библиотек для серверного API — интегрироваться на серверной стороне стало проще, однако, клиентский протокол в проекте свой, изменился и имеет достаточное количество особенностей. Это делает достаточно сложной реализацию клиентов. Для второй версии у нас сейчас есть клиент для Javascript, который работает в браузерах, должен работать с NodeJS и React-Native. Есть клиент на Go и построенные на его основе и на основе проекта gomobile биндинги под iOS и Android.

Для полного счастья не хватает нативных библиотек под iOS и Android. Для первой версии Centrifugo их законтрибьютили ребята из open-source сообщества. Хочется верить, примерно так случится и теперь.

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

Заключение

Я не озвучил все фичи, которые появятся в Centrifugo v2 — чуть больше информации есть в issue на Github. Релиз сервера пока не состоялся, но он в скором времени случится. Есть еще незаконченные моменты, в том числе нужно дописать документацию. Прототип документации можно посмотреть по ссылке. Если вы пользователь Centrifugo, то сейчас правильное время, чтобы повлиять на вторую версию сервера. Время, когда не так страшно что-то сломать, чтобы впоследствии сделать лучше. Для заинтересовавшихся: разработка сосредоточена в ветке c2.

Мне сложно судить, насколько будет востребована библиотека Centrifuge, лежащая в основе Centrifugo v2. На данный момент я доволен, что смог довести ее до текущего состояния. Самый важный показатель для меня сейчас это ответ на вопрос «а стал бы я сам использовать эту библиотеку в личном проекте?». Мой ответ — да. На работе? Да. Поэтому я верю, что и другие разработчики оценят.

Источник

Innovative HVACR Solutions that Transform How People Live and Work

Drawing on our expertise and global perspective, we combine engineering, software and technology to develop HVACR and infrastructure solutions that best serve our customers.

At Emerson, our industry-leading heating, air conditioning and refrigeration technologies create comfortable residential and commercial environments, maintain the integrity of goods throughout the cold chain, and improve operational and energy efficiencies to make life easier.

Copeland at 100

Transforming a Century of Inventiveness into a Future of Possibilities

Copeland™ Online Product Information (OPI) Tool

Gain access to the most comprehensive product information in the industry via our online product information (OPI) tool. Explore our newly updated tool to experience its new capabilities and improved user experience.

Customer Portal

Registered customers can access our portal for a whole range of quick and easy self-serve solutions. Access and purchase products, obtain product specifications and features, related product content, and much more. Don’t have an account? Register Now!

Emerson customers can also track their perishable shipments using Oversight. Our cloud-based online portal, Oversight, serves as the real-time resource for monitoring in-transit shipment information such as temperature, location and other measurements which may affect the quality of sensitive cargo.

Источник