Проекты

О важности качества: от проводов до изоленты

Приведем еще пример работы с оборудованием Galileo Sky Wi-fi hub  в зоне, где нет сотовой связи, а выгрузить данные можно только через цепочку терминалов и впоследствии уже через GSM, либо через стационарный роутер со спутниковой тарелкой. Это Чаяндинское месторождение.

Сначала клиент попытался установить блоки с сотовой связью без дополнительной функциональности. Это совершенно не решило проблему: блоки были не на связи длительное время, в результате и техника на протяжении одного-двух месяцев оставалась без нее. Был даже случай, когда техника на 20% была на связи и единовременно потеряла сигнал. Начали выяснять причины. Обнаружилось, что двое водителей, употребив внушительное количество спиртного, поехали на одном из тягачей за водкой и сбили сотовую вышку. После установки станции в проектное положение голосовая связь заработала, но интернет так и не появился. В результате, клиент принял решение закупить спецоборудование Galileo Sky base block WiFi Hub.

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

Нашим специалистам пришлось переделывать абсолютно всё. Было установлено 50 блоков, а пропорции между клиентами и сборщиками информации было следующими: на 40 клиентов приходилось всего 10 сборщиков информации. В результате по GSM сборщики информации просто не успевали выгрузить данные на сервер.

После непродолжительного совещания было принято решение установить wi-fi роутер от усиленной wi-fi антенны для выгрузки данных, как от сборщиков, так и от клиентов на базе. Данный роутер был установлен силами клиента, и мы смогли перенастроить объекты в зоне действия GSM для работы с ним. В результате, техника, которая работала и приезжала на базу выгружала данные через роутер, а техника, которая была удалена от роутера и не могла выгрузить данные сначала выгружала данные на точке сбора, то есть на хабы. Хаб уже по прибытии на базу через роутер выгружал данные на сервер. Если хаб по пути подцеплял GSM связь, то выгружал все через GSM, и данные уже были на севере. В итоге, 95% объектов были на связи (актуально на день-два), около 5% составляла техника, надолго уехавшая за пределы действия клиента по каким-либо работам или же техника, стоявшая на ремонте и обесточенная.

Таким образом, клиент смог наладить контроль работы техники и расхода топлива за несколько тысяч километров от головного офиса.

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

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

Весовой контроль на рессорах

Ещё один кейс, который мы рассмотрим — измерение веса.

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

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

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

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

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

Что же делать в такой ситуации?

Для эксперимента было принято решение установить на автомобиль клиента тензодатчики на изгиб. Установлены они были на ось самосвала.

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

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

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

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

Данная система сейчас еще в стадии испытания, так как у тензодатчиков есть свой изъян — при изменении температуры окружающей среды у них изменяется точность.

Но самая главная проблема заказчика была даже не в определении веса, а именно в подсчете рейсов, пунктов выгрузки и загрузки. Соответственно, мы ее выполнили на 100%.

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

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

С места в карьер на 7000 км

Данный проект нам пришёл от крупного вендора: программное обеспечение по мониторингу транспорта.

Почему этот проект достался нам?

Потому что все остальные игроки рынка не согласились на его выполнение в виду слишком большой удаленности.

Если считать от нас, то получается порядка 7000 км.

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

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

Срок окупаемости

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

После этого клиент согласился на оснащение остальных единиц транспорта системой спутникового мониторинга. Для этого мы использовали то же оборудование, что применялось для теста: Galileo Sky base block WiFi Hub.

В чём преимущество данного оборудования?

Основное преимущество Galileo Sky base block WiFi Hub состоит в том, что датчик может передавать данные с одного блока на другой при помощи wi-fi без доступа к GSM. То есть один блок настраивается в качестве клиента и устанавливается, к примеру, на бульдозер. Другой блок получает функции точки сбора информации, например, это бензовоз. Когда бензовоз приезжает к бульдозеру, он по wi-fi снимает c него данные и записывает себе на флеш-память. После этого бензовоз уезжает и, как только у него появляется GSM-сеть, выгружает и свои данные и то, что собрал с бульдозера. Таким образом происходит цепочка передачи информации и выгрузка её на север. Если же GSM-сети нет в принципе, но есть, например, спутниковая связь и роутер, то можно на бензовозе (то есть на точке сбора) настроить следующий алгоритм переключения: как только он подъезжает в зону wi-fi роутера, активируется с режима сбора информации на выдачу. Бензовоз подключается к этому роутеру и выгружает через него свои и собранные данные.

После этого мы закупили оборудование Galileo Sky base block WiFi Hub и столкнулись со второй проблемой. Для функционирования данного блока требуется SD-карта: она нужна для загрузки на нее данных, которые оборудование собирает с остальных блоков. Так как в посёлке Беринговском очень сложные климатические условия, мы понимали, что если поставим обычные бытовые флеш-карты, они быстро выйдут из строя. Поэтому мы начали искать решение и обнаружили, что для этой задачи прекрасно подходят индустриальные карты Kingston Industrial. Новая сложность заключалась в том, что в обычных магазинах их нет в наличии. Пришлось заказывать эти карты от одного поставщика и достаточно долго ждать их прибытия.

Датчики уровня топлива мы выбрали Оmnicomm, по причине их высокого уровня надежности. Также был собран весь инструмент монтажника, который должен был туда полететь вместе с Борухом Дмитрием (впоследствии он стал руководителем отдела монтажа). Сначала на место было отправлено оборудование: нескольким транспортными компаниями, которые передавали его из рук в руки и в конечном итоге доставили до клиента. И только после подтверждения заказчиком получения всех отправленных позиций, на место работ вылетел монтажник. По прилёту в Анадырь нашего сотрудника погрузили в МТЛБ (это что-то типа БТР на гусеницах), и ещё 12 часов он ехал по берегу моря, фактически по самому морю (оно уже покрылось льдом). Таким образом он добрался до поселка Беринговский. По прибытии Дмитрий начал монтаж. Первое, с чем он столкнулся — это суровые климатические условия. В порту хоть и наличествовала сотовая связь, но при перемене ветра она перемещалась вслед за ним. Проблематично было даже передвигаться при очень сильном ветре. Ну и само собой, ещё добавлялась дикая природа, звери и вечная мерзлота и так далее.

Какое же решение мы нашли для клиента?

Мы оснастили всю технику, которая находится в карьере ( т.е. все бульдозеры, экскаваторы и т.д.) приборами с настройками клиента. То есть они могли только выгружать данные либо по GSM, либо на другой хаб, настроенный в режим точки сбора, либо на стационарной wi-fi сети.

Самосвалы на базе шасси Scania мы оснастили приборами, которые были настроены в режим точки сбора. В результате один самосвал делал 2-3 рейса из карьера в порт. В момент забора груза, машина собирала данные с экскаватора, либо с бульдозера, после чего ехала в порт. Там уже присутствовала GSM связь, и данные спокойно выгружались на сервер. Поскольку пропорции техники составляли примерно 1 к 3, то есть 1 —  это количество техники в карьере и 3 — это количество самосвалов, передача данных была практически непрерывной. Таким образом, актуальные данные поступали с отставанием на 2-3 часа.

Какие еще преимущества появились у клиента?

  • Первое, это подсчет рейсов, то есть они могли уже посчитать сколько рейсов каждый самосвал сделал из карьера в порт.
  • Второе, было понимание сколько отработано моточасов карьерной техники, так как карьерная техника работает не по пробегу, а по моточасам.
  • Третье, было выяснено сколько было затрачено топлива, как на рейсы самосвалов, так и на моточасы спецтехники.
  • И четвёртое, что выяснилось уже в последствии, это фиксация ДТП. Поскольку в Берингово суровый климат, самосвалы достаточно часто переворачиваются, а при помощи ГЛОНАСС можно определить, где это было, во сколько, при каких условиях, при каких ускорениях, так как на приборах GALILEO SKY  есть фиксация аккуратного вождения (вернее ускорений торможений,  ускорений старта и боковое ускорение). Таким образом клиент всегда получал информацию о том, когда и где произошел инцидент. В итоге, нами была сформирована цепочка передачи данных от самой удалённой техники, постоянно находившейся в карьере без сотовой связи, до порта с последующей выгрузкой информации на сервер.

В последствии производителями приборов GALILEO SKY был добавлен еще очень интересный функционал. Заключался он в том, что если раньше можно было передавать данные только по цепочке клиент — точка сбора и дальше уже на сервер (то есть было только одно промежуточное звено), то теперь, при новых прошивках и помощи алгоритма Easy Logic мы могли сделать неограниченное количество звеньев. То есть одна точка сбора могла сгружать данные с клиентов, потом передавать это другой точке сбора, вторая точкав свою очередь третьей точке, и так далее, вплоть до сервера. Сейчас мы уже можем формировать неограниченное количество промежуточных звеньев. Проблема остается в том, что отсутствует возможность отправки сообщений на удаленные объекты вне зоны GSM даже через все эти точки сбора. Эти блоки, в которых никогда не бывает GSM-связи, уже не получается перенастроить удалённо. То есть про удаленную диагностику и перенастройку можно забыть. Но, на данный момент, на рынке это практически единственное решение, которое позволяет контролировать технику вне зоны GSM и выстраивать алгоритмы для выгрузки данных на сервер. Такой подход очень часто применяется, например, в карьерах, лесозаготовительной технике, нефтесервисных компаниях. В общем, для техники, которая работает в очень удаленных регионах, где нет покрытия сотовой связи.

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

Как с Hecterra от Wialon определять расход топлива с точностью литр на гектар

Сегодня поговорим о такой отрасли, как сельхозпредприятия.

У производителя программного обеспечения Wialon есть дополнительные модули, называются Hecterra (Хектерра или Гектерра, кому как удобней произносить).

Какие же преимущества даёт этот модуль?

К примеру, в стандартном мониторинге, таком как Wialon hosting, мы можем увидеть отчёты по топливу, по километражу, расходу литр на километр, расходу литр на моточас. Но в стандартном мониторинге не отображается потраченное топливо на единицу площади, то есть литр на гектар. Для этого есть дополнительный модуль Hecterra, который работает на ядре Wialon hosting.

Что представляет собой этот модуль? Сами данные от трекеров, геозоны полей, водители и прицепные механизмы. Они хранятся в самом ядре, то есть в Wialon hosting, а apps Hecterra уже может обработать эту информацию и выдать нужные нам отчеты. Первое, что мы можем видеть в «Хектерре» — это электронная карта полей. Мы можем создать в Wialon hosting геозоны, и на основе них уже создать поле. Основной функционал здесь заключается в том, что мы можем вырезать из середины поля неиспользуемый кусок земли для более точного подсчета площади поля.

Еще можно ввести электронный севооборот, то есть назначать — какие культуры в какой сезон произрастали на этом поле.

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

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

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

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

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

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

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

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

Система очень удобна при достаточной автоматизации. К примеру, парк в 10 единиц за предыдущие сутки мы можем зарегистрировать обработки без RFID-считывателей водителей. Без считывателя прицепов это займет минут 20.

Но есть в данном решении и свои минусы. Первый — максимальное поле не может быть более 1000 га. Хотя есть обходные пути. Например, поле всегда можно поделить на 2-3 части и так далее.

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

Но здесь есть большое НО. При объединении обработок пересчитывается только строка Итого. Если, к примеру, мы возьмём поле на 100 га, обрабатывают его два трактора. Один сделал 60 га и второй сделал 60 га. При объединении этих обработок в составную, у нас будет итого, что они вместе сделали 100 га. Но данных о том, кто из них сделал 60, а кто 40, либо они сделали 50 на 50, не будет. То есть мы увидим только строку Итого.

Ещё один из минусов в том, что по сравнению с профессиональными системами, где оплата производится не только по объектам, но и по гектарам, и также по обработкам (бывает такое), у нас здесь точность ПО только до одного метра.

Это происходит из-за использования обычных автомобильных трекеров. Точность их GPS/ГЛОНАСС-приемников в среднем составляет где-то от 1 до 5 м. При использовании более профессиональной техники, например, тех же навигаторов Trimble и такого класса приемников, точность уже порядка 30-40 см. В целом, для небольшого предприятия данное решение очень подходит, функционал удобен и прежде всего, быстрой регистрацией обработки.

На Крайнем Севере нет GSM, но мониторинг мы организуем

Сегодня мы расскажем еще об одном проекте, находящимся в зоне, где нет GSM-сети.

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

GSM-связь была нестабильной и местами полностью отсутствовала. Именно поэтому клиент — один из карьеров в Архангельской области — занялся поиском нового оборудования, которое сможет выгружать данные не только через GSM. Так как наш заказчик уже работал с интеграторами и с навигационным оборудованием, которое просто не выгружало данные по его технике, топливу и так далее, то для пробы решил закупить 10 терминалов Galileo Base block wifi hub, чтобы протестировать на своей территории.

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

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

Для этого клиент обратился в нашу службу технической поддержки и попросил выключить sim-карты на этих 10 блоках, кроме одного, который был установлен на топливо раздачи. При помощи программных алгоритмов на блоках мы отключили связь и блоки могли выгружать данные только через Wi-Fi.

Через неделю испытаний клиент попросил отключить GSM-связь также и на трекере топлива раздачи. А клиент тем временем смонтировал на территории wi-fi-роутер и сообщил нам его местоположение, логин и пароль. После чего мы прописали данные в терминалы, в том числе и на терминал, который располагался на топливораздаче, который переключался по зоне. То есть, как только он выходил с зоны базы, он собирал данные из других терминалов. Как только он заезжал на базу, он переключился в режим на выгрузку данных через wi-fi-роутер. После еще одной недели испытаний клиент убедился, что данное решение его устраивает: блоки отрабатывают в штатном режиме и выгрузка данных происходит стабильно.

мониторинг без GSM

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

Некоторую часть смонтированной техники переправили в порт Сабетта кораблем. Когда корабль подходил к порту, в 20 км от берега часть блоков смогла поймать GSM-связь, так как на них были установлены усиленные антенны, и выгрузить весь свой путь по морю от Архангельска до Сабетты. Кораблю со всей техникой пришлось простоять 10 дней в бухте, так как он не мог причалить из-за погодных условий. Всё это время оборудование было на связи и выгружало данные о своем состоянии.

После того, как техника была выгружена, специалист прибыл на место и начал монтаж остального оборудования уже на карьере около города Сабетта. Со специалистом мы смогли определить местоположение местной wi-fi-точки спутникового интернета, к которому был подключен роутер. Мы также прописали алгоритм, по которому те приборы, которые собирают данные из других приборов, то есть хабы, переключались из режима сбора данных в режим загрузки через этот wi-fi-роутер. Также определили, что в порту, куда самосвалы перевозят груз для погрузки на корабли, присутствуют GSM-связь, так что данные поступали на сервер стабильно.

Таким образом у нас появилась цепочка, в которой часть техники выгружает данные при помощи wi-fi-роутера и Galileo wifi hub, который поставляет эти данные к роутеру, а часть техники выгружали данные при помощи GSM-связи уже на пути или в порту. В результате клиент смог создать цепь передачи данных и получать актуальную информацию о своей технике, работающей на расстоянии в 2 тысяч километров в условиях Крайнего Севера.

хищение зерна

RFID-выдача зерна – «Свой-чужой»

Сегодня поговорим еще об одной теме – система «Свой-Чужой» на комбайнах сельхозтехники. Если взять хищения топлива, запчастей, горюче-смазочных материалов – всё это не тех масштабов, как хищение зерна.

Хищение одного КАМАЗа зерна может стоить в разы больше. Поэтому очень часто клиенты просят установить систему «Свой-Чужой» для выгрузки зерна с комбайнов. Это могут быть различные типы комбайнов, такие как John Deere, CLAAS, Вектор и так далее. Как решается данный вопрос?

Достаточно просто. Во-первых, нужно подключить контроль над включением/выключением шнека – винтового элемента для перемещения сыпучих веществ. Шнек — механизм для выгрузки зерна из комбайна в самосвал. Для этого мы можем подключиться как аналоговым путем (то есть подключиться именно к самой кнопке или к самому исполнительному механизму), так и взаимодействовать с техникой при помощи CAN-шины. При отправке нужных команд в CAN-шину автомобиля шнек может быть блокирован, либо мы можем просто блокировать команду от джойстика до исполнительного механизма.

Здесь мы рассмотрели только контроль. Как же определить — автомобиль свой или чужой? Для этого есть много вариаций, но смысл в них один и тот же — это уникальный идентификатор на автомобиль, то есть на самосвал. В нашем исполнении это было самым простым решением, и мы установили на комбайн два RFID-считывателя карт.

Один считыватель стоял в кабине комбайна и предназначался для водителя комбайна (механизатора). Он был необходим для контроля смен. Второй считыватель мы поставили снаружи, и он предназначался для карты водителя самосвала. Таким образом, когда подъезжает самосвал к комбайну, выгрузка происходит не в движении. Водитель самосвала выходит, вставляет свою карту в самосвал, когда прибор видит две доверенные карты: одну комбайнера, другую — механизатора, то он разблокирует шнек. Как ему можно произвести выгрузку?

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

Данную систему можно реализовать и при помощи другого оборудования. Также можно поставить на комбайн RFID-считыватель, но не карт, а меток. А на самосвал установить активные метки RFID. Таким образом, данные метки работают на расстояние до 30-50 м, и в результате, когда самосвал подъезжает, комбайн автоматом определяет, что рядом с ним есть доверенный самосвал, которому можно выгрузить зерно и сразу же блокировать шнек.

хищение зерна

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

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

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

Контроль скорости уборки урожая

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

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

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

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

Почему возникает превышение скорости?

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

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

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

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

Вывод: скорость очень важна в системе мониторинга. Ее следует контролировать и незамедлительно принимать меры при несоблюдении скоростного режима в различных режимах работы. Что напрямую влияет на доходы и расходы клиентов. 

Спутниковый мониторинг солярки, или зачем ГРП-насосу ГЛОНАСС

Этот материал опубликован на habr.com.

Дорогие коллеги и просто любители нестандартных технических решений, представляем вашему вниманию стори из будней скромного системного интегратора и поставщика телематики для бескрайних российских просторов)))

Как-то сверху поступила неординарная задача, выходящая за рамки привычных «Глонасс»-будней. К нам по рекомендации обратилась одна нефтесервисная компания (а какая — NDA), занимающаяся на ближнем Севере услугами в сфере гидроразрывов пластов (ГРП) для поднятия дебитов скважин. Технология сравнительно недавно стала применяться на постсоветском пространстве и уже успела завоевать свою нишу на всех крупных месторождениях нефти и газа.

«Флот», выполняющий такую работу, обычно состоит из 7-8 и более единиц разноплановой техники. Но его костяк – это всегда плунжерная насосная установка ГРП на подвижном шасси (одновременно подключаются к скважине до 5 насосов через специальные переходники), которая может создавать давление до 1000 атмосфер. Для примера, давление в шинах обычного легкового автомобиля редко превышает 3 атмосферы. Подробнее про операцию ГРП можно почерпнуть отсюда.

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

Всё это пытались перепроверять, проводить выездные осмотры и замеры, но к какому-то стабильному результату не пришли. Ставили «Глонасс» для контроля уровня топлива в баках, но серьезной экономии не добились. В итоге нефтяники стали искать компанию, которая имеет нестандартный подход. И нашли нас ехать в тайгу? увольте .

Надевай свой Monblan и вперёд

Клиент поставил задачу получить данные о параметрах двигателя шасси Mercedes-Benz Actros и собственно отдельного двигателя (производства MTU или Detroit Diesel от 2000 л.с.) установленного на его раме для плунжерного насоса, а также дополнительные параметры от датчиков расхода смеси, рабочем давлении в скважине и т.п. 

После детального изучения всех нюансов запланировали пилотную установку.

На одном из своих флотов заказчик предоставил новенькие насосные установки ГРП, и мы, не теряя времени, с бесконечным энтузиазмом принялись за работу. Так как спецтехника очень сложная, и буквально напичкана различными датчиками и линиями обогрева, в том числе и топливных баков, то доступ к последним был весьма серьёзно ограничен из-за тугих жгутов проводов, всевозможных трубочек, металл. помостов и кабельных лотков.

Чтобы установить топливные датчики Omnicomm LLS-Ex 5 (ДУТы) так, как требовал регламент, пришлось изрядно попотеть, но и не такое изворачивались устанавливать, даже с учётом того, что новое поколение датчиков 5-ой серии стали вдвое шире по измерительной части — они обзавелись фирменной технологией FuelScan, что позволяет им самостоятельно корректировать свои выходные значения под любой вид топлива, в том числе и с присадками.

Огромные топливные баки в общей сумме вмещали порядка 1,5 тонн дизтоплива. Кабельные трассы от ДУТов до кабины шасси, где расположился навигационный терминал, составляли от 15 до 25 метров, и это был действительно ад по прокладке трассы, так как места в раме нет от слова “совсем”. Были применены кабельные сборки в металлической гофротрубе.

Терминал использовали с двумя CAN-шинами GalileoSky 7x, поскольку это надёжное и объективно продвинутое оборудование отечественного производителя, а в последних моделях оч. много крутых фич (2xCAN интерфейса, технология EasyLogic и т.п.).

Тонкий процесс реверс-инжиниринга

После тарировки ДУТов настала очередь снимать показания с CAN-шин 2-х двигателей. Данные по шасси на базе MB Actros нам были более менее известны, хотя протокол и был проприетарный 11-битный, нам удалось извлечь достаточно много данных (обороты, t0 ОЖ, пробег, положение педалей газа и тормоза, вариации света, ремень безопасности, расход топлива накопительный и мгновенный, данные с двух установок Webasto, так как они были «мокрые» и также влияли на расход топлива).

Спустя довольно много нерво-часов нам удалось провести реверс-инжиниринг CAN-шины верхнего оборудования, и там оказалась довольно обширная доработанная J1939 CAN-шина 29 бит на 500 000 кбит/с. с множеством интересных параметров (обороты двигателя, температуры и давления различных рабочих жидкостей (антифризов и масел) двигателя и АКПП Allison, текущие включенные передачи АКПП, расход рабочей смеси). Также нам пришлось повозиться с датчиком давления в рабочей линии (токовая петля 4-20 мА), так как он, минуя CAN-шину ЭБУ двигателя, приходил напрямую на Siemens SIMATIC, в результате чего пришлось прибегнуть к установке дополнительного нормированного преобразователя тока в напряжение.

Улыбка по факту

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

А события такие место явно имели – с установкой системы сразу же выявилась огромная пропасть между фактическим расходом и ранее списываемым методом «перерасхода» объемом топлива.

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

Связи нет, а мониторинг транспорта ЕСТЬ!

Фантастика? Нет, скорее творчество. Ну и конечно же профессионализм, аналитический склад ума и сплоченная команда, куда без этого.

Наша компания давно вышла за пределы «обычных» установок оборудования для мониторинга транспорта. Сейчас расскажем о том, как нами был успешно реализован проект по установке трекеров на технику, работающую в угольном карьере, при отсутствии в нем сотовой связи, как таковой, и в непростых погодных условиях посёлка Беринговский (Анадырский район Чукотского автономного округа России).

Перед нами стояли задачи по обеспечению:

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

В результате наша разработка позволила собирать и передавать информацию с машин на сервер.

Начнем с того, что никто ранее не решался взяться за реализацию такого проекта. Географическое расположение, суровые климатические условия и отсутствие GSM-связи, казалось бы это невозможно… Но не для нас.

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

До того, как Дмитрий попал на место проведения работ, ему предстоял длинный путь. Сначала он прилетел в Анадырь, затем ещё 12 часов на МТЛБ (многоцелевой транспортёр-тягач лёгкий бронированный) ехал по замерзшему морю. Выбор транспортного средства был обусловлен погодными условиями: когда менялось направление ветра, невозможно было позвонить даже в тех местах, где раньше была связь. Когда начиналась пурга, нужно было держаться за веревку, переходя от одного дома к другому, так как, делая несколько шагов, было уже невозможно понять нужное направление.

Тестовая установка Galileosky

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

Для тестовой установки был взят прибор Galileosky Base Block Wi-Fi Hub. Это устройство может собирать данные с других терминалов, где слабый GSM-сигнал, либо его нет совсем, а в зоне действия сети передает их на сервер мониторинга. Сначала были оснащены бульдозер и топливозаправщик, т. к. из всей карьерной техники именно они работают в условиях постоянного отсутствия GSM-сигнала. А также самосвалы SCANIA, которые регулярно въезжают в зону действия сети.

Результаты

Первые результаты показал топливозаправщик, который был оснащен счетчиком ППО+УСС, интегрированным с терминалом Base Block. Благодаря этому нам удалось получить данные о выдаче топлива на технику, что позволило контролировать его расход.

За неделю удалось сэкономить 6 тонн топлива. В результате клиентом было принято решение полностью оснастить парк системой мониторинга. Далее, все бульдозеры, экскаваторы и карьерные грузовики настроили в режим «Клиент», а топливозаправщики и рейсовые самосвалы в режим Hub. Таким образом, машины в режиме Hub собирают данные с карьерной техники, а по приезду в порт, где есть GSM-связь, передают свои и собранные с других машин данные на сервер.

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