Москва
Москва
Саратов
Пн - Пт / 09:00 - 19:00
|
sale@com-pass.ru
|
+7 499 390 06 01
|
Пн - Пт/ 09:00 - 19:00
|
sale@com-pass.ru
|
+7 977 940 26 29
Оставить заявку

Проекты

Взвешивание на карьер

Как автоматизировать учёт массы груза на карьере

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

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

Это решение было использовано для одного из наших клиентов (добывающая компания, карьер). Задача – обеспечить вывод точного значения массы автомобиля на весах в систему мониторинга.

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

Возникла сложность. Специализированных отчетов в системе Wialon Hosting не было. Но мы смогли вывести нужную информацию при помощи модуля Eco Driving. Модуль для определения манеры вождения автомобиля пригодился для измерения веса. Это было возможно при помощи гибкой настройки датчиков и валидаторов.

В итоге данные (пиковый вес во время взвешивания автомобиля) отправлялись в отчет.

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

  • Время взвешивания;
  • Масса;
  • Фотография автомобиля.

Таким образом наш клиент смог построить подробнейшую отчётность по массе ввозимого и вывозимого груза (в нашем случае это щебень).

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

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

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

Перерасход топлива на АДПМ

Перерасход топлива АДПМ: решение и внедрение мониторинга

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

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

Проблема: расход горючего на работу АДПМ значительно превышал норму и составлял около 500 литров в час.

Решение очевидное – внедрить систему мониторинга топлива. Это действительно помогло, “аппетиты” АДПМ значительно снизились и теперь составляли около 150 литров в час. Проблема в том, что это всё равно много.

Причины такого большого расхода остаются под вопросом. Наша команда вместе с клиентом стали подробнее вникать в технические процесс работы АДПМ – только так можно было найти нужные сведения.

По итогу было выявлено, что расход напрямую зависит от следующих факторов:

  • Какой объем смеси разогревает агрегат;
  • Какова начальная температура этой смеси;
  • До какой температуры её требуется разогреть.
В процессе многочисленных тестов мы поняли: расход топлива нужно считать не по литрам на 100 км, не по литрам в час, а по схеме "литры на разогрев одного куба жидкости на один градус". Тогда мы сможем контролировать корректную норму и расход топлива и пресечь хищение горючего. Также мы можем определять перерасход, если он был.

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

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

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

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

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

Высокоточный трекинг для С/Х техники без переплат: 3 рабочих способа

Для сельхозпредприятий важное значение имеет не только контроль расхода топлива, но и точность показаний ГЛОНАСС/GPS. Как её добиться? Рассмотрим реальные кейсы с нашими клиентами.

У стандартных навигационных терминалов погрешность составляет до 5м. При обработке полей это неприемлемо – может произойти, например, выброс координаты в треке или смещение трека. Эту проблему решает высокоточное оборудование (Trimble, AG Leader и др). Вопрос – как его интегрировать в систему мониторинга?

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

Это лишь один из вариантов. Есть и другие.

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

Мы смогли подключиться к CAN-шине, то есть бортовому компьютеру автомобиля и обеспечить возможность передачи высокоточных координат. Это получилось только с оборудованием от GalileoSky. Их технология “Easy Logic” помогла нам построить алгоритм переключения приёма координат: когда техника работает и включена штатная высокоточная навигация, прибор берёт данные от неё. А если техника не работает (стоянка), то прибор берёт координаты со своего внутреннего приёмника.

Ещё один использованный нами на практике способ – установка высокоточных антенн.

В таком случае приемник и ГЛОНАСС/GPS-чип находятся не в навигационном терминале, а уже на стороне антенны. Она определяет координату и передает на терминал. Это тоже реализуемо в основном на оборудовании GalileoSky – там можно подключить внешний источник координат по интерфейсу RS-232 и получить их в протоколе M&A.

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

Чаяндинское месторождение: как с нуля восстановили неисправную систему связи

Приведем пример работы с оборудованием 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 и выстраивать алгоритмы для выгрузки данных на сервер. Такой подход очень часто применяется, например, в карьерах, лесозаготовительной технике, нефтесервисных компаниях. В общем, для техники, которая работает в очень удаленных регионах, где нет покрытия сотовой связи.

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

Расход топлива с точностью литр на гектар: контроль ГСМ для аграрной компании

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

У производителя программного обеспечения 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, есть контроль скорости во время технического процесса.

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

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

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

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

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

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

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

1 2