Джон Арлингер(John Arlinger), Скокфорск (Skogforsk) 06 февраля 2019
Юхан Мюллер(Johan J. Möller, Skogforsk)
Юха-Анттш Сорса(Juha-Antti Sorsa, Метсятехо(Metsäteho)
Тапио Рясянен(Tapio Räsänen, Metsäteho)
Введение в StanForD 2010
СТРУКТУРНЫЕ ОПИСАНИЯ И РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
*Скогфорск – Научно-исследовательский институт лесного хозяйства Швеции, Forestry Research Institute of Sweden
*Метсятехо – Metsäteho Oy-это компания с ограниченной ответственностью, принадлежащая ведущим организациям и компаниям лесной промышленности Финляндии и специализирующаяся на научно-исследовательских и опытно-конструкторских работах и проектах.
*StanForD 2010 – стандарт для лесозаготовок и передачи данных о лесе
Содержание:
Основные положения
Введение
Сообщения
Приоритеты
Соглашение об именах
Дорожная карта
Состояние схемы
Список релиза
Идентификация
Ключ
Идентификатор пользователя UserId
Примеры ключей (KEY) и идентификаторов пользователей (UserId)
Администрирование pin-и spi-файлов
Вырубка объектов
Сообщения, отправленные на лесные машины
Инструкция по применению продукта
Объемы цен
Окно распила и запас длины
Инструкции для специальных групп
Функция Soundknot
Инструкция объекта
Инструкции географического объекта
Краткая инструкция харвестера
Инструкция форвардера
Пользовательские данные
Ввод / Инструкция
Вывод / Отчет
Управление различными инструкциями в машинах
Сообщения, отправленные с лесной машины
Срубленная продукция
Обработка нескольких деревьев (MultiTreeHandling)
Неклассифицированные бревна
Общая срубленная продукция
Контроль качества вырубки
Стрелеванная продукция
Примеры
Контроль качества трелевки форвардером
Оперативный контроль
Индивидуальное против комбинированного времени работы машины
Примеры...
Варианты вырубки
Apt-файл (простая вырубка)
Рубка APTERI
Гибкая вырубка
Компоновка системы харвестера
АПТ-файл заготовки
Заготовка APTERI
Гибкая вырубка
Другие варианты использования ...
Контроль качества заготовки
Отчетность о вырубленной продукции (hpr)
Оперативный контроль
Трелевка
Инструкция от лесной компании
Данные о производстве харвестера
Ручной ввод оператора
Взаимодействие оператора во время вырубки
Вопросы
Подключение Продуктов и СпецГрупп к кнопкам ........
Отсутствующие определения Продуктов и СпецГрупп
Замена определений Продуктов и СпецГрупп
Определения в одном или нескольких сообщениях
Обновление Определений
История старых / замененных Определений
Продукты в GUI
Ограничить модификацию продукта
Определение важных понятий и ключевых фигур .....
Иные вопросы
Приложение 1) отчетность по hpr-файлам
Вступление
Отслеживание hpr-файлов
Требования и рекомендации
Общая отчетность (требование StanForD)
Частичная отчетность (Skogforsk рекомендации)
Иные вопросы
Расположение сообщений, генерируемых в машине
Приложение 2) отображение элементов идентификатора StanForD
Происхождение
Отношения один на один
Идентификатор пользователя
Предлагаемое решение
Преобразование apt-файла в StanForD 2010
Таблица сопоставления
Шведский перевод
Содержание.
Основные положения
Цель данной книги состоит в том, чтобы дать читателю введение в положения StanForD 2010, а также рекомендации по их внедрению.
Разработка StanForD 2010 года началось в 2006 году, 25 сентября, с решения о проведении предварительного исследования. Через год было решено продолжить проект в направлении окончательной новой версии StanForD 2010. Была сформирована проектная группа, состоящая из представителей производителей машин, а также Skogforsk, Metsäteho и SDC. Представители Logica и Haglöf также присутствовали на заседаниях проектной группы. Первая версия StanForD 2010 была принята весной 2011 года.
Этот документ был написан во время разработки StanForD 2010. Это живой документ, постоянно обновляемый. Таким образом, это не официальный стандартный документ. Официальными стандартными документами являются (www.skogforsk.se/StanForD 2010 год):
* XML-схемы
* StanForD 2010 имена и дизайн
* Правила StanForD 2010 года
Основные цели новой стандартной версии заключаются в достижении:
* Улучшенные структуры, поддерживающие современные требования к управлению данными.
* Лучшие структурные описания
• Более строгие приоритеты и правила осуществления;
• Система управления стандартными версиями
* Сокращение старых переменных и сложных структур
Однако это не означает, что мы существенно упростим использование харвестеров и форвардеров. Управление лесной машиной является сложным и должно быть сложным, поскольку финансовые ценности, обрабатываемые машинами, очень велики.
Невозможно и на самом деле нежелательно полностью оставлять старый StanForD позади, так как многие части старого стандарта работают очень хорошо. Вместо этого была поставлена цель использовать хорошо функционирующие части настоящего стандарта, оставляя проблемные части позади и в то же время открывая стандарт для будущего развития.
При запуске разработки был проведен детальный анализ старых переменных и типов файлов. Большое количество старых StanForD-переменных было исключено на основании того, что:
* их приоритет низкий (4)
* старая prd-структура заменена на pri-структуру
• должны использоваться только абсолютные, а не относительные значения.
• следует избегать агрегированных данных;
* двоичные числа не должны использоваться.
Обратите внимание, что термин организация лесозаготовок в этом документе относится к организации, покупающей лесозаготовительные услуги у владельца машины (часто подрядчика). Лесозаготовительная организация иногда также является владельцем машины, а также владельцем леса. Лесозаготовительную организацию иногда также называют лесной компанией. В новом стандарте были изменены следующие старые термины:
* Ассортимент заменен термином продукт
* Порода (Species) заменяется термином породная группа(species group)
.
* Транспортный объект заменяется условиями доставки и размещения
Введение
Сообщения
При работе над новым стандартом полезно мыслить в терминах различных типичных сообщений в различных ситуациях информационной транзакций. Отсутствие иерархического уровня над отдельными переменными или элементами, вероятно, затрудняет построение, понимание и использование стандарта. Поэтому было сочтено необходимым разработать набор сообщений для удовлетворения общих коммуникационных потребностей.
Были определены следующие типы сообщений (использование некоторых из них показано на рис. 1) с использованием отдельных схем:
* Инструкция по эксплуатации продукта
* Объектная инструкция
* Инструкция по группе видов
* Объектная географическая инструкция
* Инструкция по объекту трелевки (новая 2010-06)
* Форвардерная инструкция по доставке (новая 2010-06)
* Заготовленная продукция
• Контроль качества вырубки
* Общее количество заготовленной продукции;
* Стрелеванная продукция
* Контроль качества трелевки (новый 2010-01)
* Географический отчет объекта (новый 2010-02)
* Оперативный мониторинг
Рисунок 1. Иллюстрация того, как стандартизированные сообщения используются в различных информационных потоках. Пунктирные стрелки иллюстрируют информационные потоки, основанные на других стандартах данных, таких как, например, papiNet.
Ниже приведены некоторые основные правила, касающиеся сообщений StanForD:
* Данные StanForD всегда, в качестве первого шага, будут отправляться в виде одного сообщения с одной машины. Таким образом, логично иметь машину в качестве высшего иерархического уровня внутри сообщения.
* Сообщения StanForD можно использовать для объединения данных с нескольких компьютеров, но это второстепенная задача. Объединение данных должно осуществляться отдельными административными программными приложениями.
• Это означает, что производственные данные с нескольких машин и нескольких объектов/суб-объектов могут быть включены в представленную структуру. Однако нормальная производственная отчетность будет составляться по каждой машине и вырубаемому объекту.
* Различные сообщения должны быть четко разделены. Это, например, означает, что данные контроля качества всегда регистрируются в сообщении контроля качества вырубки, а не в сообщении о вырубленной продукции.
Обратите внимание, что структуры данных должны быть гибкими, что позволяет, например, использовать структуры для объединения производства харвестеров и форвардеров в одно сообщение, охватывающее конкретный объект вырубки. Однако эти "объединенные" сообщения не будут определены в StanForD 2010.
Идея состояла в том, чтобы построить многоразовые структуры (группы переменных) в различных сообщениях. Это означает, что мы, например, используем точно такой же способ определения объекта сбора данных во всех типах сообщений. Эти структуры рисуются в виде прямоугольников на диаграммах в разделах (Messages sent to machines), и сообщения, отправленные от машин (Messages sent from machines). Примером такой структуры является определение объекта (ObjectDefinition). Все эти общие структуры хранятся в одной xml-схеме (StanForD 2010CommonDefinitions)
Приоритеты
Необходимо будет внедрить систему приоритетов для различных элементов, поскольку была реализована структура сообщений, описанная выше.
Возможное решение состоит в том, что набор переменных внутри определенной структуры/группы должен быть включен (обязательно). Вероятно, также необходимо реализовать некоторые базовые правила, касающиеся того, какие структуры/группы являются обязательными в рамках определенного типа сообщений.
Примеры, иллюстрирующие приоритеты:
* Сообщение для управления раскряжевкой (объектная инструкция) должно содержать ссылки на то, какие продукты (ассортименты) будут использоваться
• Сообщение о вырубленных продуктах должно содержать данные о заготовленных бревнах.
* Классы длины и диаметра должны быть включены при определении продукта (ProductDef на диаграммах ниже).
Пользователь / оператор должен иметь возможность установить, какие дополнительные переменные должны быть включены в любое сообщение.
Соглашение об именах
Ручное обращение с отдельными файлами, вероятно, все еще будет необходимо в обозримом будущем. Например, оператор должен иметь возможность сохранять два отдельных файла для мониторинга и производственных данных на USB-накопителе и переносить их на офисный компьютер в тех областях, где нет возможностей беспроводной связи. Поэтому при сохранении данных в отдельных файлах требуется стандартизированное соглашение об именовании сообщений.
Будет использоваться система с расширениями файлов, аналогичная старой StanForD (табл.1). Это позволит легко ассоциировать различные файлы с различными приложениями.
Таблица 1. Следующие расширения файлов будут использоваться для новых файлов StanForD
РасширениеНаименованиеКомментарий“.pin”Инструкция продуктасопоставимо с ap1“.oin”Инструкция объектасопоставимо с apt и oai“.spi”Инструкции породных группсопоставимо с apt и ap1“.ogi”Инструкция для географии объектасравнимо с ghd“.foi”Инструкция по трелевке объектановая
“.fdi”
Инструкция о доставке стрелеванного лесановая“.hpr”Продукция харвестерасравнимо с pri“.hqc”Контроль качества вырубкисопоставимо с stm и ktr“.thp”Вся вырубленная продукцияПростой prd“.fpr”Продукция трелевкиСопоставимо с prl“.fqc”Контроль качества трелевкиНовый“.ogr”Отчет о географии объектаСопоставимо с ghd“.mom”Мониторинг данныхСопоставимо с drf“.env”Оболочка Xml, включая другие файлыНовый“.udi”Пользовательская инструкция по обработке данныхНовый
Было бы полезно узнать из имени файла, является ли, например, HPR заархивированным или нет, так как файлы StanForD 2010 регулярно сжимаются. К расширению файла отдельных сжатых файлов StanForD следует добавить букву “z". Сжатый hpr-файл, таким образом, будет иметь расширение файла “.hprz”
Дорожная карта
Состояние схемы
Краеугольным камнем, когда речь заходит о версионировании StanForD 2010, является тот факт, что мы включили статус определенной версии в схемы.
В StanForD 2010 включены следующие уровни статуса:
* Проект может быть использован для тестирования и демонстрации в любое время любым человеком.
* Релиз — это окончательная версия схемы, которая никогда не будет изменена, предварительный релиз становится релизом после периода тестирования, обычно составляющего 2-3 месяца.
* Предварительный выпуск создается или изменяется только после собрания и на основе решений, принятых на собрании. Как только что-то было добавлено в предварительный релиз, мы должны принять официальное независимое решение на последующем совещании, чтобы исключить или изменить его. Предварительный релиз становится релизом после периода тестирования в 2–3 месяца.
Ниже приведено правило из StanForD_2010_naming_and_design –document.
[Правило 8.2]
The xsd:schema version attribute MUST use the following template:
<xsd:schema ... version=”draft” |” pre-release” | “release”_<major>.<minor> >
Где:
draft | pre-release | release – is used based upon the status.
<major> - sequential number of the major version.
<minor> - sequential number of the minor version.
Атрибут «versionDate» также включен в два разных расположения.
Временная метка была добавлена к атрибутам заголовков схем:
<xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns="urn:skogforsk:StanForD 2010"
xmlns:doc="urn:skogforsk:StanForD 2010:doc"
xmlns:sfd="urn:skogforsk:StanForD 2010"
targetNamespace="urn:skogforsk:StanForD 2010"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="release_2.1"
sfd:versionDate="2012-09-06">
Атрибут «versionDate» можно найти в списке атрибутов каждого сообщения в (будет обязательным в версии 3.0):
<xsd:attributeGroup name="MessageAttributeGroup">
<xsd:attribute name="areaUnit" type="AreaUnitType" use="required"/>
<xsd:attribute name="diameterUnit" type="DiameterUnitType" use="required"/>
<xsd:attribute name="lengthUnit" type="LengthUnitType" use="required"/>
<xsd:attribute name="volumeUnit" type="VolumeUnitType" use="required"/>
<xsd:attribute name="weightUnit" type="WeightUnitType" use="required"/>
<xsd:attribute name="version" type="StanForD 2010VersionType" use="required"/>
<xsd:attribute name="versionDate" type="xsd:date" use="optional"/>
</xsd:attributeGroup>
Список релиза
Основные правила обновления StanForD 2010 будут следующими:
* Никогда не более одного нового” выпуска” (минорного или мажорного) в год.
* Максимальное количество крупных релизов - один раз в три года.
• Две встречи: март и октябрь
• Все решения на совещаниях включаются в “предварительный выпуск”. Никакие другие изменения не допускаются в “предварительном выпуске”.
• "Предварительный релиз “станет” релизом" после двух-трехмесячного периода тестирования.
На рисунке ниже показано нормальное обновление StanForD 2010 в течение года при условии, что мы используем атрибут «status type pre-release» и «versionDate».
Правила также можно проиллюстрировать на следующем рисунке ниже.
Идентификация
Уникальная идентификация различных объектов, таких как машина, продукт (ассортимент), объект сбора урожая, древесная порода, бревно и т. д., является слабой областью в рамках настоящего стандарта. Это, по крайней мере, частично зависит от того факта, что никто не мог себе представить, как и в какой степени лесные машины должны быть интегрированы в другие информационные системы, когда в конце 1980-х годов был разработан первый стандарт.
Старые id-переменные можно разделить на две принципиально разные группы. Переменные могут быть:
* Устанавливается машиной (var270_t3, var306_t1, var121_t6)
* Устанавливается лесозаготовительной организацией (var21_t1 и var121_t2)
Было решено, что в StanForD 2010 будут определены следующие две новые концепции идентичности:
* Ключ (Key) всегда устанавливается автоматически в лесной машине
* Идентификатор пользователя (UserId) устанавливается пользователем данных (лесозаготовительной организацией, оператором, владельцем машины)
Ключ (Key)
Ключ всегда устанавливается автоматически в машине. Он никогда не должен создаваться лесозаготовительной организацией, оператором, владельцем машины или любым другим пользователем.
Ключ — это обычно рабочий номер, используемый для сбора информации от объекта, ствола и бревна (сравните с бревнами и стволами в настоящем pri-файле). Каждая машина, оператор, продукт, группа пород деревьев, местоположение, доставка и загрузка также должны иметь уникальный ключ. Ключи для стволов, местоположения, доставки, грузов, операторов, продуктов и группы пород деревьев должны быть уникальными для каждой машины, и они никогда не сбрасываются, в то время как ключ для бревен сбрасывается для каждого ствола.
Также необходим уникальный машинный ключ, возможно, основанный на каком-то идентификаторе компьютера. Ключ машины должен быть глобально уникальным идентификатором (GUID). Он также может каким-то образом включать в себя, например, номер шасси имя и производителя. Ключ машины должен быть жестко закодирован изготовителем. Обычно его следует менять, если, например, заменяются блоки памяти раскряжевочного компьютера, так как компьютер должен отслеживать исторические данные, например предыдущий объект сбора урожая или стержневой ключ. Обратите внимание, что в Windows существует поддержка для создания GUID.
Определенная комбинация клавиш всегда должна быть уникальной (например, machine – stem – log). Все журналы от всех комбайнов будут иметь уникальный идентификатор. Общее производство всех харвестеров тогда можно было бы собрать в одной базе данных, не получая никаких id-конфликтов. Лучшим примером из старого стандарта является анализ ktr-файлов с нескольких различных машин, объектов лесозаготовки и лесных компаний вместе взятых.
Уникальный идентификатор для каждого ствола необходим при проверке нескольких вхождений одного и того же ствола. Сегодня очень трудно идентифицировать отдельный ствол, так как нет надежного способа идентификации машин и объектов вырубки. Было использовано очень большое количество различных переменных, например, Skogforsk использовал в этих анализах комбинацию следующих переменных:
- идентификатор объектаo (object id (var21_t1, var32_t2)
- начало регистрации данных (start date (var16)
- сохранение данных (save date (var12)
-номер машины(machine no (var3_t1/t2)
- идентификатор калибра (caliper id (var3_t4)
Следующие ключи будут использоваться для идентификации записи в журнале, если мы будем следовать приведенным выше рекомендациям:
• Глобально уникальный идентификатор машины / компьютера (MachineKey)
• Рабочий (последовательный/последовательный) номер, используемый для ствола(stem) и бревна(log) (StmKey и LogKey)
Уникальный идентификатор машины, используемый для сбора объекта (ObjKey), может быть рабочим номером. Эта переменная позволит идентифицировать объект вырубки определенного ствола в приведенном выше примере.
Любые изменения или модификации продукта (ассортимента) должны означать, что ключ продукта (ProductKey) обновлен. Это также верно для групп пород и операторов.
Выводы.
Ключ (Key) всегда устанавливается автоматически в машине.
Ключ (Key)в большинстве случаев является изменяемым числом
Все ключи (Keys) должны быть обновлены, когда:
Любое изменение сделано, и определение было использовано в лесозаготовке.
Исключение: ObjectKey, SubObjectKey, LocationKey обновляются только при создании ObjectDefinition, SubObjectDefinition и LocationDefinition. Причина этих исключений заключается в том, что пользователь данных должен иметь возможность обновлять, например, ObjectUserId-элемент и при этом иметь возможность отслеживать все бревна из этого объекта лесозаготовки с помощью ObjectKey. Это может произойти, например, если вырубка запускается “вручную” (без oin-файла) до того, как ObjectUserId был сообщен оператору. Это исключение будет означать, что у нас может не быть идеального исторического журнала относительно модификаций, как это происходит, например, с продуктами.
Таблица 2. Описание всех ключей в стандарте
Имя элементаТип данныхОписаниеMachineKeyСтрокаКонкретной машины уникальными глобальный идентификатор (GUID). Его необходимо обновить, если память ранее использованных ключей потеряна. Возможности для производителей, чтобы использовать его, чтобы идентифицировать отдельные машины. Другие пользователи данных должны использовать MachineUserId или MachineIdOwner.StemKeyПоложительное целое числоВозрастающее число для каждого ствола, должно быть уникальным для конкретного MachineKey. Специфическая идентичность машины на ствол.LogKeyПоложительное целое числоРабочий номер должен быть сброшен для каждого ствола, LogKey 1 - это первое бревно в стволе (butt log). Идентификация бревна в стволе.StemBunchKeyПоложительное целое числоВозрастающее число для каждого ствола, должно быть уникальным для конкретного MachineKeyObjectKeyПоложительное целое числоВозрастающее число устанавливается при создании нового объекта рубки в машине, который никогда не будет изменен после созданияSubObjectKeyПоложительное целое числоВозрастающее число, установленное при создании нового подобъекта вырубки в машине, никогда не будет изменено после созданияLocationtKeyПоложительное целое числоВозрастающее число устанавливается при создании нового местоположения при трелевке, которое никогда не будет изменено после созданияOperatorKeyПоложительное целое числоВозрастающее число для каждого оператора, обновленное, если определение OperatorDefinition каким-либо образом изменено, должно быть уникальным для конкретного MachineKeyProductKeyПоложительное целое числоВозрастающее число для каждого продукта, обновленное, если определение продукта ProductDefinition было изменено каким-либо образом, должно быть уникальным для конкретного MachineKeySpeciesGroupKeyПоложительное целое числоВозрастающее число для каждой группы пород, обновленное, если определение SpeciesGroupDefinition каким-либо образом изменено, должно быть уникальным для конкретного MachineKeyDiameterSectionKeyПоложительное целое числоВозрастающее число для каждого продукта, обновленное, если определение DiameterSectionDefinition каким-либо образом изменено, должно быть уникальным для конкретного MachineKeyDeliveryKeyПоложительное целое числоВозрастающее число для каждой группы пород, обновленное, если определение доставки каким-либо образом изменено, должно быть уникальным для конкретного MachineKey
Идентификатор пользователя UserId
Лесные компании или другие пользователи данных используют UserId для целей идентификации. UserIds может использоваться для идентификации объектов, продуктов, древесных пород, операторов, поставок и машин.
Основная идея заключается в том, что только один экземпляр определенного UserId должен быть доступен для использования в машине одновременно. Например, старый продукт или спецгруппа заменяются, если машина получает новый продукт или спецгруппу с тем же UserId. Это означает что, например только один экземпляр ProductUserId может быть выбран и использован в данный момент времени.
Примеры ключей (KEY) и идентификаторов пользователей (UserId)
a. Не существует продукта с идентификатором ProductUserId ”0110_xvy” → новый продукт добавлен в раздел " доступные продукты”
b. Продукт с идентификатором ProductUserId "0110_xvy" уже существует → старый продукт заменен новым продуктом, добавленным в качестве " доступных продуктов”
Следующие диаграммы (2–4) иллюстрируют еще один аналогичный пример того, как UserIds, ModificationDates и Keys обрабатываются в харвестере при обновлении и использовании продуктов. Следующий пример очень похож на Apteri-систему, которая в настоящее время используется в Финляндии. Заметим, что оба UserId и ModificationDate должны учитываться при обновлении списка продуктов (рис.3). Существующий продукт не должен быть заменен новым продуктом, отправленным в харвестер, если они имеют идентичные UserId и ModificationDate. Оператор должен иметь возможность отказать в замене существующего продукта.
Рисунок 2. Три новых продукта (pin) отправляются на харвестер. Идентификатор UserId первого (PW) и второго продукта (PS_Cl1) уже существует среди доступных продуктов, в то время как третий продукт (PS_Cl4) является новым.
Рисунок 3. Список доступных продуктов обновляется. Обратите внимание, что старый продукт PW не заменяется старым, так как они имеют ту же дату модификации.
Рисунок 4. Объектная инструкция (opi) отправляется в харвестер. Инструкция содержит ссылки на три продукта. Поскольку третий UserId не существует в харвестере, оператор спрашивает приложение раскряжевки, что делать.
Следующие диаграммы (5–6) иллюстрируют еще один аналогичный пример того, как обрабатываются UserIds, ModificationDates и Keys при обновлении и использовании объектных инструкций. Обратите внимание, что при обновлении списка объектов следует учитывать как UserId, так и ModificationDate. Существующий объект не должен быть заменен новым объектом, отправленным в харвестер, если они имеют идентичные UserId и ModificationDate. Оператор всегда должен иметь возможность запретить замену существующего объекта, а также обновление активного объекта, используемого в настоящее время.
Рисунок 5. Пять новых объектов (oin) отправляются в харвестер. Userid первого (456) и второго продукта (567) уже существует среди объекта, в то время как третий и четвертый объекты являются новыми.
Рисунок 6. Список объектов обновляется. Обратите внимание, что второй объект с именем BlueForest теперь существует, так как ObjectUserIds отличаются.
Следующие диаграммы (7–9) иллюстрируют еще один пример использования идентификаторов пользователей UserIds и ключей Keys в случае отчетов о производстве с харвестера. Рисунок 8 конкретно иллюстрирует, как MachineKey и StmKey могут быть использованы для идентификации нескольких случаев появления одних и тех же стволов.
Рисунок 7. Производственные данные отправляются с харвестера на один и тот же участок в день 1 и 2. Каждый ствол имеет уникальный ключ ствола StemKey и, таким образом, может быть добавлен в производственную базу данных.
Рисунок 8. Производственные данные были отправлены с харвестера также на 3-й день. Анализируя все соответствующие ключи, можно сделать вывод, что первые шесть стволов были включены по ошибке в 3-й день. Таким образом, эти стволы (1-6) не следует добавлять в производственную базу данных, поскольку они уже были добавлены в день 1 и 2.
Рисунок 9. Производственные данные были отправлены с харвестера также на 3-й день. Анализируя StemKey, можно сделать вывод, что все восемь стволов уникальны. Анализируя ObjKey, мы также можем сделать вывод, что данные поступают из нового объекта рубки. Все стволы должны быть добавлены в производственную базу данных. Тот факт, что ObjUserId такой же, как и в день 1 и 2, вероятно, вызван ошибкой оператора или лица, ответственного за создание директив раскряжевки.
Администрирование pin-и spi-файлов
Откройте и прочитайте инструкцию по продукту (pin) или инструкцию по группе пород (spi). Выполните следующие проверки для всех продуктов в новом pin-файле:
1) Проверьте, является ли новый UserId уникальным.
а) добавить в базу данных продукта, если он уникален, и установить новый уникальный ключ Key
б. наличие = правильно
2) Проверьте, существуют ли уже UserId и ModificationDate.
а) не добавлять в базу данных продуктов
3) проверьте, существует ли UserId с различным ModificationDate. Спросите пользователя, должен ли новый продукт заменить старый продукт. Если ответ в утвердительный, то добавьте новый продукт, установите новый ключ
a) Available = true для нового продукта
b) Available = false для старого продукта
ModificationDate всегда должен обновляться, если выполняются какие-либо изменения в определении продукта ProductDefinition. Автоматическое обновление определения продукта ProductDefinition на текущем сайте не должно быть реализовано; оператор должен иметь возможность запретить обновление продукта.
Эти структуры означают, что определение продукта ProductDefinition может быть отправлено в харвестер, а затем модифицировано в этом харвестере или другом харвестере несколько раз. Этот случай можно было бы описать на следующем рисунке:
Рис. 10 Отправка продукта в рабочую программу раскряжевки и учета харвестера.
Единственное, что ясно сказано, так это то, что если ProductUserID и ModificationDate одинаковы, то нет никакой необходимости обновлять “базу данных продуктов” в харвестере. Оператор всегда должен иметь окончательное решение, когда один продукт в “базе данных” должен быть заменен, даже если продукт в машине моложе, чем новый, отправленный в машину.
Используя необязательный атрибут свободного текста (ModificationAuthor), где указано, кто внес последнюю модификацию, можно сообщить оператору не только о том, когда продукт был изменен в последний раз, но и об авторе этих изменений.
Рис. 11 Атрибутирование автора изменений программы.
Например, оператор может получить следующий вопрос при импорте нового определения продукта:
"Хотите ли вы заменить нынешний продукт" Сосна малогабаритная древесина " "Pine small sized timber"на продукт"Сосна малогабаритная древесина""Pine small sized timber"?
Настоящая версия была изменена компанией "Holmen skog" в 2012-09-20 12:15:02. Импортированная версия была изменена “MaxiXplorer 941.1 " в 2012-09-21 09:27:39.
Вырубка объектов
Наименьшим общим знаменателем для объекта лесозаготовки является договор лесозаготовки с лесовладельцем в пределах определенной географической зоны и времени. Подобъекты используются только для хранения производственных данных из разных подзон отдельно друг от друга. Реализация подобъектов может рассматриваться как предоставление пользователю возможности использовать простой переключатель идентификаторов без каких-либо обязательств по изменению инструкции объекта.
Объект лесозаготовок:
* охватывает одну коммерческую сделку/договор между покупателем и продавцом
• один раскряжевочный и географический инструктаж на объект
• номер ствола всегда сбрасывается при запуске на новом объекте
Суб-объект:
• используется только для хранения производственных данных из отдельных географических подразделений отдельно друг от друга
• может быть исключен
Сообщения, отправленные на лесные машины
В этом разделе описываются все сообщения, которые отправляются на лесную машину, как правило, от организации лесозаготовок. Однако обратите внимание, что сообщение о географической инструкции объекта также может быть обновлено и отправлено с лесной машины.
Было решено определить три отдельных сообщения для управления оптимизированной раскряжевкой на харвестерах. Эти три сообщения-инструкция по продукту, инструкция по группе пород и инструкция по объекту-не должны перекрывать друг друга. Это означает, что определения различных продуктов (ассортиментов) должны быть включены только в инструкцию по продукту, а не в инструкцию по объекту. Инструкция продукта сопоставима со старым ап1-файлом, в то время как инструкция объекта сопоставима с oai -файл. Породная специфическая информация регистрируется в инструкции группы пород, эта информация ранее регистрировалась в файле apt - или ap1. Старый apt-файл можно рассматривать как комбинацию этих трех новых файлов.
Во всех харвестерах должны действовать индивидуальные инструкции по объекту, инструкции по группе пород и инструкции по продукту. Следует избегать настроек, специфичных для производителя, а это означает, что эти сообщения не должны содержать никаких данных, специфичных для производителя.
Некоторые типы данных в настоящее время включены в старый apt-файл, который будет установлен в машине и, следовательно, не включен в инструкцию продукта:
* Идентификатор машины и подрядчика (var3, var34)
• Длина ствола, используемая в расчете (var101_t1)
• Длина ствола, измеренная перед оценкой (var102_t1)
• Верхний и нижний пределы допуска для отклонения расчетного диаметра (var103_t1 и var104_t1)
Инструкция по применению продукта
Структура инструкции по продукту в основном охватывает существующие типы файлов ap1, apm и fpm.
ProductKey используется как уникальный ключ во всех производственных сообщениях (рабочий номер, установленный в машине, глобально уникальный при использовании в сочетании с MachineKey). Идентификатор ProductUserId используется в качестве идентификатора в производственных определениях и сообщениях инструкций объектов (устанавливается лесозаготовительной организацией). Обратите внимание, что ключ ProductKey устанавливается в машине, а не лесозаготовительной организацией.
Никаких правил для изменения или обновления продуктов в пределах определенного объекта рубок не потребуется. Любые изменения или обновления продуктов будут возможны, если мы реализуем правила идентификации, описанные выше. Это основано на предположении, что файлы подсчета бревен больше не генерируются и что новый ключ продукта дается каждый раз, когда продукт обновляется или изменяется.
Ключ ProductKey и ModificationDate должны быть обновлены, если определение ProductDefinition было изменено каким-либо образом. Для каждого определения существует ограничение модификации атрибута, позволяющее лесозаготовительным организациям ограничивать модификации операторов.
Рисунок 12. Макет сообщения инструкции по эксплуатации изделия. В этом сообщении отсутствуют ссылки на объект рубок. Все ключи установлены в машине, только UserIds (*) отправляются на машину.
Рисунок 13. Подробная схема, описывающая определения продукта.
* Новая переменная, заменяющая FromMatrix (var197), если true только в пределах оптимальной матрицы, если false также использует все другие неоптимальные матрицы в раскряжевке распределения (true должно быть по умолчанию)
Обратите внимание, что в приведенную выше диаграмму включены только матрицы распределения для каждого класса диаметров, это означает, что выражается только желаемое распределение длины внутри класса диаметров. Исключена возможность включения матрицы распределения с желаемым распределением для всей матрицы (старые var191_t1 и var191_t2).
Объемы цен (Price volumes)
Текущая ситуация
Ценовые объемы и категории довольно сложны в старом StanForD. Все соответствующие переменные в настоящем старом стандарте включены ниже в таблицу 3.
Таблица 3.Переменные цены и объема в старом стандарте StanForD
VarNoОписаниеЮнитНовая группаНовое имяv164_t1
Принцип для зарегистрированного диаметра
0 = регистрируемая длина, см
1 = требуемая длина (класс длины)
2 = случайная длина для регистрации, дециметр
кодDiamDefDiamTypeV164_t4Расстояние от вершины бревнаСмDiamTopPositionv131_t1Нижний предел диаметра. Смотрите также DiamClassesMaxммDiamClassesv131_t1Максимальный диаметр использования в сочетании с DiamClassesммDiamClassesMaxv134_t1В основном используется вместе с объемами и классами, зависящими от среднего диаметраммDiamMinTopv134_t2Максимальный диаметр в большом конце бревна на ценовую матрицуммDiamMaxButtv132_t1Нижний предел длины класса длинысмLengthDefLengthClassesv132_t1Максимальная длина использования в сочетании с классами длины LengthClassesсмLengthClassMaxv135_t1Дополнительное поле длины, не может быть отрицательным числом / классом длинысмLengthMargin-PerClassv163_t1
Расчет объема на основе:
0 = длина зарегистрированная, см (по умолчанию в Финляндии)
1 = требуемая длина в соответствии с var132
2 = случайные длины регистрации, дм.
кодPriceDefVolTypeLengthv161
Ценовая категория / ценовая матрица / породы деревьев, где
1 = Цена / м3 (объем по малому торцевому диаметру);
2 = Цена / м3 (твердое тело);
3 = Цена / бревно;
4 = Цена / м3 (норвежская ценовая категория);
5 = Цена / м3 (шведское измерение верхнего и торцевого торцов);
6 = Цена / м3 (твердое тело, измеренное в средней точке, цена из-за SED, диаметр HKS)
7 = цена/м3 (твердое тело, измеренное в средней точке, цена из-за среднего диаметра, диаметр HKS)
8 = цена/м3 (твердое тело, измеренное в средней точке, цена из-за среднего диаметра, (датское)
9 = Цена / ножки доски (американская ценовая категория)
10 = цена / м3 (твердое тело, диаметр, измеренный в средней точке, цена из-за SED) диаметр в мм
11 = Цена / журнал (представленный объем в виде кода 4, Норвежская ценовая категория)
12 = Цена / комплектный м3 (объем насыпи рассчитывается с учетом диаметра и длины пакета)
13 = цена / м3 (эстонская единица объема Нильсона) все коды подробно описаны в приложении (старые типы 2-4 должны быть жестко закодированы)
кодPriceVolume-Category
Var161_t1 в основном описывает, как вычислить определенный объем. Хорошим примером проблем, с которыми мы сталкиваемся сегодня, является код 10 (M3см), который имеет следующее определение:
Цена / м3. Твердый объем, диаметр (мм) измеряется в средней точке для расчета объема, цена за счет малого торцевого диаметра (мм).
Эта ценовая категория описывает не только то, как должен быть рассчитан объем, но и то, как он должен быть классифицирован на основе его малого конечного диаметра. Другие подобные коды-3,7,10 и 11.
Новый стандарт.
Для улучшения ситуации старые переменные были разделены на три отдельные группы элементов: определение диаметра, определение длины и определение цены. Это означает разбиение текущего var161_t1 на несколько новых переменных в соответствии с таблицей 4.
Таблица 4. Элементы для определения классификации диаметра и длины, а также ценообразования бревна
ГруппаНаименованиеОписаниеЮнитСтарый VarNoDiameter-DefДиам.ClassCategory (атрибут)
Тип диаметров в DiamClasses (используется для определения ячейки в матрице цен) Top,
Середина
кодv161_t1DiamClasses-нижний предел- LowerLimitНижний предел диаметра. Смотрите также DiamClassesMaxммv131_t1DiamClassesMaxМаксимальный диаметр. Использование в сочетании с DiamСlassesммv131_t1DiamClassAdjust
1=бревно относится к первому классу диаметра меньшего или равного диаметру бревна (227 мм => класс 220 мм)
2=бревно относится к ближайшему классу диаметра, нормальное округление, (227 мм => класс 230 мм)
DiameterUnderBarkКлассы диаметров под коройлогическийDiamMinTopМинимальный диаметр на тонком конце. В основном используется вместе с объемами и классами, зависящими от среднего диаметра.ммv134_t1DiamMaxButtМаксимальный диаметр на комлевом конце бревна на ценовую матрицуммv134_t2DiameterTop-PositionПоложение от верхнего конца бревна, где измеряется верхний диаметр. Допустимо для значений diamClassCategory " Top " и " Norwegian mid”смV164_t4LengthDefLengthClassAdjust
1=бревно относится к первому классу длины, меньшему или равному длине бревна (427 см => класс 400 см)
2=бревно принадлежит к ближайшему классу длины, нормальное округление, (427 см => класс 430 см)
LengthClasses-LowerLimitНижний предел длины класса длинысмv132_t1LengthClassMargin
Дополнительное поле длины, не может быть отрицательным числом / классом длины.
Дополнительный запас длины используется только для того, чтобы избежать слишком коротких бревен.
смv135_t1LongLogButtMINНижний предел диаметра стыка для каждого класса длины и продукта<ммv165_t1LongLogButtMAXВерхний предел диаметра стыка на класса длины продуктаммv166_t1LongLogButtHeight
Высота над пнем точки измерения диаметра торца
на один продукт
смv167_t1LengthClassMAXМаксимальная длина использования в сочетании с классами LengthСlassesсмv132_t1?PriceDefVolumeDiameter-Adjust
Диаметры в расчете объема цены бревна
"Измеренный диаметр в мм”
“Измеренный диаметр, округленный вниз до см " идентичен HKS (227 мм => 220 мм)
кодVolumeDiam-Category
Диаметры, используемые при расчете объема цены: твердый объем "Вершина”
“Средний”
"Рассчитано норвежская середина”
"Рассчитано по эстонски середина”
“Средний диаметр " измеряется в положении, определенном в соответствии с категорией VolumeLengthCategory.
кодv161_t1volumeDiameter-TopPosition
Положение от верхнего конца бревна, где измеряется верхний диаметр для расчета объема.
Допустимые значения VolumeDiameterCategory ”топ”, “норвежский середины” и ”эстонский середины”
смV164_t4VolumeLength-Category
Длины, используемые при расчете объема цены: "физическая Длина, см” (по умолчанию в Финляндии)" длина, определенная в классах длины "" округленная вниз до ближайшего DM-модуля” (например, 427 см => 420 см)
"Округлено до ближайшей середины дециметра” (например, 427 см => 425 см)
кодv163_t1VolumeUnderBark
Объем цены под корой:
"Правда" или " ложь”
логически
Ниже приведены некоторые примеры того, как предлагаемые новые переменные могут быть использованы для некоторых старых ценовых категорий, используемых в разных странах (таблица 5).
Таблица 5. Примеры использования новых элементов на основе существующих типов объемов цен
Имя ОписаниеSwe subSwe toFin1 sobNor3 midGer midGer topDen2 midEst midFra4 mid
Старые коды (var161_t1)
Коды стран
(var6_t1)
2
752
1
752
130
246
4
578
7
276
6
276
136
208
12
233
135
250
DiamClassCategory Diameters в DiamClasses (price matrix- ценовая матрица)
1=Верх
2=Сред.точка
111121212DiamClassAdjust
1=класс диаметра меньше или равен диаметру бревна (DiameterClassAdjustment1)
2=ближайший класс диаметра, нормальное округление (DiameterClassAdjustment2)
111111111DiameterUnderBark Диаметр классов под корой.True/false (Правда\лож)TrueTrueFalse TrueTrueTrueFalse TrueFalse
DiameterTopPosition
Положение от верхнего конца бревна, где измеряется верхний диаметр.
см101001000000LengthClassAdjust
1= класс длины меньше или равен длине бревна (LengthClassAdjustment1)
2=ближайший класс длины, нормальное округление (LengthClassAdjustment2)
111111111VolumeDiamAdjust Диаметры в расчете объема цены бревна
1=измеренный диаметр
2=измеренный диаметр, округленный до см,
111222112
VolumeDiamCategory
Диаметры, используемые при расчете объема цены:
1 = твердый объем
2 = Верхний
3 = Средний
4 = рассчитанная норвежская середина
5 = расчетная эстонская середина
121433353
VolumeLengthCategory
Длины, используемые при расчете объема цены:
1 = Физическая длина 2 = Длина, определенная в классах длины
3 = округленная вниз до ближайшего дециметрового модуля
4 = округлено до ближайшей середины дм.
121322112
VolumeUnderBark
Объем цены под корой
True/falseTrueTrueFalseTrueTrueTrueFalseFalse
volumeDiameter-TopPosition
Положение от верхнего конца бревна, где измеряется верхний диаметр для расчета объема.
См101001000000BarkFunctionCategory
1=Нет
2=шведский Zacco 3=немецкий 4=Skogforsk 2004, Шотландская сосна
5=Skogforsk 2004, норвежская ель
2/4/52/4/512/4/53312/4/51
1. То же самое и в Дании
2. Используется для длинных лесоматериалов (целые стволы)
3. В основном используется для обычных пиломатериалов. Объем рассчитывается исходя из цилиндра с теоретическим диаметром на середине бревна (м).
Длина: длина (L) - это общая фактическая длина в дециметрах. Если L выражено в сантиметрах, то оно конвертируется в дециметры (class bottom).
Диаметр: по определению класс диаметра равен 1 см (независимо от фактической матрицы цен). Зарегистрированный диаметр (Dt) измеряется в 10 см от верха. Если Dt находится в миллиметрах, то он переделан до сантиметров (class bottom). Чтобы получить диаметр по середине бревна (Dmid), вы используете формулу: Dmid = Dt + (L/2 * 0.1) + 0.5
Пример: L = 518 см, DT = 223 мм Dmid = 22 + (51/2 * 0.1) + 0.5 = 25.05 cm объема: объем рассчитывается в дм3.
PI = 3,14 в = ((Dmid / 10)*(Dmid/10)) * PI / 4 * L = ((25.05/10)*(25.05/10))*ПИ/4 * 51 = 251 дм3
VolumeLengthCategory и диаметры
Верхняя часть бревна должна быть исключена из оцениваемого объема, если “VolumeLengthCategory” имеет значение "LengthClass", а "VolumeDiameterCategory” имеет значение" All diameters (solid volume-плотный объем)” , как показано ниже:
Рис. 14 Определение вершины бревна
Категории объемов “m3sub “или” m3sob " в hpr, mom и hqc должны основываться на физической длине бревна, указанной в аннотации LogVolumeCategory.
Значение " средний диаметр” в VolumeDiameterCategory измеряется в положении, определенном в соответствии с VolumeLengthCategory, как показано ниже:
Рис. 15 Определение среднего диаметра бревна
Окно распила и запас длины
Основные положения:
Нынешние переменные StanForD таковы:
* Запас длины (var135_t1) дополнительный запас длины, не может быть отрицательным числом / классом длины/ценовой матрицей/породами деревьев
• Окно распила (var135_t3) нижний предел длины для "окна распила"/матрицы цен/пород деревьев. Нижний предел класса длины (var132) и переменная 135, тип 1 и 3 вместе, определяют класс длины бревна, если нижний предел окна распила находится ниже нижнего предела класса длины
• Окно распила (var135_t4) верхний предел длины для "окна распила"/матрицы цен/пород деревьев. Это не влияет на классификацию длины бревна. Он не может быть выше нижнего предела класса длины (132_t1) или выше нижнего предела длины для " окна раскряжевки" (135_t3) следующего класса длины.
Нижний предел класса длины (var132) и переменная 135, тип 1 и 3 вместе, определяют класс длины бревна, если нижний предел окна резки находится ниже нижнего предела класса длины
Верхний предел длины не влияет на классификацию длины бревна. Он не может быть выше нижнего предела класса длины (132_t1) или выше нижнего предела длины для "режущего окна" (135_t3) следующего класса длины
Новый стандарт
Назначение поля длины и окна раскряжевки заключается в следующем:
* дополнительный запас длины используется для того, чтобы избежать слишком коротких бревен
* окно распила должно дать харвестеру подходящий интервал, когда головка может прекратить подачу ствола и таким образом легко найти положение распила без необходимости подачи стебля назад и вперед.
В пин-сообщение включены следующие элементы таблицы 6 (без существенных изменений по сравнению с настоящим стандартом).
Таблица 6. Элементы, определяющие окно распила
ГруппаНаименованиеОписаниеЮнитOldVarNo
LengthDef
LengthClass-Margin
Дополнительный запас длины, не может быть отрицательным числом / классом длины/ценовой матрицей / породами деревьев дополнительный запас длины используется только для того, чтобы избежать слишком коротких бревен.смv135_t1Cutting-WindowDefLowerLength-Limit
Нижний предел длины для "окна распила" на один продукт. LengthClassLowerLimit (var132), LengthClassMargin (var135_t1) и LowerLengthLimit вместе определяют класс длины бревна, Если нижний предел окна резки находится ниже нижнего предела класса длины.
Назначение режущего окна состоит только в том, чтобы дать харвестеру подходящий интервал, когда головка может прекратить подачу ствола и таким образом легко найти положение раскряжевки без необходимости подачи ствола назад и вперед.
смv135_t3UpperLength-Limit
Верхний предел длины для продукта "окно распила". Это не влияет на классификацию длины бревна. Он не может быть выше LengthClassLowerLimit (132_t1) или выше LowerLengthLimit для "режущего окна" (135_t3) следующего класса длины.
Назначение окна распила состоит только в том, чтобы дать харвестеру подходящий интервал, когда головка может прекратить подачу ствола и таким образом легко найти положение отпила без необходимости подачи ствола назад и вперед.
Примеры.
Обратите внимание, что эти примеры в основном идентичны тому, что было решено на совещании по StanForD 28-10-2002 года.
Предполагается, что LengthClassAdjustment - это "класс длины, меньший или равный длине бревна" на рис. 12-15, в то время как предполагается, что LengthClassAdjustment - это " ближайший класс длины, нормальное округление“ на рис. 16-17
Рисунок 16. Бревно длиной 399 см будет зарегистрировано в классе 400 см (LengthClassAdjustment = " класс длины меньше или равен длине бревна”)
Рисунок 17. Бревно длиной 401 см будет зарегистрировано в классе 400 см, в то время как бревно длиной 399 см не будет зарегистрировано в классе 400 см (LengthClassAdjustment = " класс длины меньше или равен длине бревна”)
Рис.18.Это не является правильно определенным "окном резки", так как верхний предел длины находится выше нижнего предела класса длины или выше нижнего предела длины для" окна резки “следующего класса длины (LengthClassAdjustment = ”класс длины меньше или равен длине бревна").
Рис.19.Класс длины 310 см - это минимальная длина для данного изделия. Это означает, что” истинная “минимальная длина на самом деле составляет 307 см при использовании такого рода отрицательного окна резки (LengthClassAdjustment = ”класс длины меньше или равен длине бревна").
Рис.20. Округление производится в направлении 307 и 337 см. (LengthClassAdjustment = " ближайший класс длины, нормальное округление”)
Рис.21 Округление производится в направлении 307 и 337 см (LengthClassAdjustment = “ближайший класс длины, нормальное округление”).
Необходимо использовать следующие правила:
1. Отрицательное окно резки всегда уменьшает длину класса, как когда LengthClassAdjustment равен “классу длины меньше или равен длине бревна“, так и когда равен“ближайшему классу длины, нормальному округлению".
2. Округление всегда имеет более высокий приоритет, чем окна распила (рис. 17)
3. Верхний предел окна резки не должен быть выше нижнего предела класса длины (132_t1) или выше нижнего предела класса длины для "окна резки" (135_t3) следующего класса длины.
Инструкции для специальных групп
В пределах старого стандарта виды (породы – species) в основном идентифицируются через порядок, в котором они перечислены в apt-файле. Новое определение групп пород представлено на рисунке 18 ниже. Поскольку породы в старых стандартных файлах в некоторых случаях являются отдельными ботаническими видами (например, норвежская ель), а иногда несколько ботанических видов объединяются вместе (например, другие широколиственные деревья), вероятно, невозможно придумать одно стандартное решение (например, список всех соответствующих видов). Поэтому предполагается, что пользователь StanForD сам решает, какие группы видов\пород он хочет использовать. Однако, возможно, было бы неплохо выбрать несколько стандартных групп видов\пород для каждого региона или страны, которые могут быть описаны в стандарте. Пример управления группами видов показан на рис. 19.
Рис.22. Диаграмма, описывающая определения видовой группы. Пунктирные стрелки и границы указывают на то, что структура необязательна.
Рис. 23 На харвестер отправляются две новые породные группы. Старая сосна заменяется новой сосной, так как они имеют тот же идентификатор пользователя, старая береза не заменяется, так как она имеет ту же дату модификации, в то время как дубовая группа добавляется как новая группа.
Два примера того, как обрабатывать калибровочные данные и историю калибровки для дуба: Случай 1) оператор знает, что в смешанных широколиственных породах много дуба. Поэтому он хочет в данных о дубовых насаждениях использовать те же данные, что и в смешанных лиственных насаждениях и откалибровать их вместе в будущем.
Случай 2) оператор знает, что в калибровочной базе данных нет дуба. Поэтому он хочет, чтобы дуб калибровался отдельно сейчас и в будущем.
Функция звукового блока (Soundknot)
Модель автоматического раскряжевки пиломатериалов со звуковым узлом основана на соотношении между DBH и малым концевым диаметром (SED) бревен для получения пиломатериалов со звуковым узлом в центральных досках бревен.
Цилиндр звукового узла (SKC) представляет собой самый большой диаметр малого конца самого низкого возможного бревна, отвечающего требованиям марки, предполагая цилиндрическое ядро звукового узла. Ниже этого уровня будет слишком много свободных (упакованных) узлов на стороне заболони центральных досок. Следующая функция реализована для прогнозирования наибольшего диаметра малого конца (SKC) для звуковых сучковых бревен:
SKQ = (constant A + factor B * DBH + factor C * DBH2) * tolerance D
SKC = SKQ *DBH
SKQ = коэффициент звукового узла, используемый для определения наибольшего допустимого малого торцевого диаметра бревна звукового узла.
SKC = звуковой узел цилиндра диаметром
A = ConstantA= константа для определения предельного звукового узлы
B = FactorB для определения предела здоровые сучки
C = FactorC для определения предельного звукового узлов
D = ToleranceD допусками для сухих Сучков в пределах рассчитанного лимита для звуковой узел диаметр цилиндра (обычно близко к 1)
SoundKnotFunctionGrade = оценка, данная журналов, когда маленький конец диаметр меньше, чем диаметр SKC.
GradeIncluded =оценки, которые могут быть заменены автоматически вычисляемой SoundKnotFunctionGrade. Это означает, что если секция ствола не имеет ранга, включенного в этот элемент, функция Soundknot не повлияет на оптимизацию раскряжевки.
Рис 24. График измерения диаметров
На рисунке 24 SKC = ((константа a + фактор b DBH + фактор c DBH2) * d) * DBH. Все бревна с верхним диаметром выше SKC (меньший диаметр верхнего конца) будут классифицированы как бревна с живыми сучками (за исключением тех случаев, когда оператор вручную выбирает другое качество для бревна).
*Не совсем понятно, что имели ввиду издатели – либо раскряжевка резонансных бревен, либо раскряжевка «по звуку» …Прим.Пер.
Экстраполяция профиля торца
Торцевая экстраполяция может быть определена двумя отдельными способами в spi-файле, либо как параметры функций, либо как таблица, и они могут быть зарегистрированы в файле. Некоторые производители требуют параметры, в то время как некоторые другие производители требуют таблицу.
Атрибут «buttEndProfileExtrapolationMethod» в spi-файле включает в себя следующий список перечислений:
• Функция экстраполяции (используется только элемент «ButtEndProfileExtrapolation-Function»)
• ExtrapolationTable (используется только элемент «ButtEndProfileExtrapolationTable»)
• Оба(используются как функция «ButtEndProfileExtrapolationFunction», так и «ButtEndProfileExtrapolationTable»)
Поскольку разные производители используют разные методы, настоятельно рекомендуется, чтобы все spi-файлы, отправляемые харвестерами, включали оба метода. Это означает, что атрибут «buttEndProfileExtrapolationMethod» должен иметь значение "оба". Также требуется, чтобы все харвестеры поддерживали значение “оба”.
Функции коры
Должно быть возможно контролировать, какую функцию «bark» использовать через spi-файл, и регистрировать, какая функция была использована в hpr-файле.
Следующие переменные для функций коры существуют сегодня в StanForD:
Рис.25 Функции коры бревен
Возможные значения:"Нет","шведский Zacco"," немецкий“,” GermanDistanceBased“," Skogforsk 2004, «шотландская сосна» и «Skogforsk 2004», «норвежская ель». Если этот атрибут равен "None", то элемент BarkFunction пуст
Описание категорий функций коры:
Swedish Zacco\Шведский Zacco
Функция коры, разработанная Zacco (1974). Линейная функция: двойная толщина коры = a + b * верхний диаметр ob, где a хранится в качестве первого параметра в var113_t1, и b-во втором параметре. Например ” "Bark= 3,28+0,0370*diam" хранится как ”113 1 328 370~ " в файле StanForD.
German\Немецкий
Функция коры основана на классах диаметра с фиксированными вычетами коры (двойными), основанными на немецких требованиях. Пример:
Рис. 26 Пример расчета
Рис.27 Как рассчитывается диаметр под корой:
GermanDistanceBased
Функция коры основана на расстоянии от пня и DBH (высота на высоте груди) с фиксированными вычетами коры (двойными), основанными на немецких требованиях.
На следующем рисунке показано, как реализовать эту функцию коры (обратите внимание, что диаметры 450 и 150 являются значениями DBH):
Рис. 28. Немецкая кора
Skogforsk 2004, Scots pine\Шотландская сосна
Функция, разработанная Skogforsk (2004) для сосны обыкновенной (Pinus sylvestris)
dbh_b=min(dbh,480) /* DBH максимум 590 mm. */ htg=-ln(0.12/(72.1814+0.0789*dbh_b-0.9868*lat))/(0.0078557- 0.0000132*dbh_b) /*
Точка перелома в см. вычислена */ db=3.5808+0.0109*dbh_b+(72.1814+0.0789*dbh_b-0.9868*lat)* exp(-(0.0078557-0.0000132*dbh_b)*h) /*
Двойная толщина коры ниже расчетной точки перелома, mm */
if h>htg then db=3.5808+0.0109*dbh_b+0.12-0.005*(h-htg) /*
Рассчитана двойная толщина коры выше точки перелома, mm */ db=max(db, 2) /*
Минимальная толщина коры 2 mm */
Skogforsk 2004, Norway spruce\ Норвежская ель
Функция, разработанная Skogforsk (2004)для Norway ели (Picea abies) db=0.46146+0.01386*dbh+0.03571*dia /* Рассчитана двойная толщина коры, mm */ db=max(db, 2) /* Минимальная толщина коры 2 mm */
Db = двойная толщина коры (mm)
H = высота от торцевого конца ствола, где должна быть рассчитана толщина коры (см)
Dbh = диаметр на высота груди (мм)
Dia = диаметр в коре, где должна быть рассчитана толщина коры (мм)
Lat = широта (десятичные градусов).
Обратите внимание, что элемент BarkLatitude не включен в шведский SPI по умолчанию. Это должно быть просто контролировать и обновлять BarkLatitude!
Рисунок 29. Кора для ели
Инструкция объекта
Структура для управления раскряжевкой в основном охватывает старый тип файла oai.
Объектная инструкция может содержать ту же основную информацию, что и старый oai-файл (рис.30). Определения продуктов и специальных групп отправляются в отдельных сообщениях, Инструкции по продукту и Инструкции по специальным группам видов\пород, без каких-либо ссылок на объект рубки.
Рис.30. Подробная схема, описывающая данные по каждому объекту рубки, разосланные в объектной инструкции. В эту структуру включаются только ссылки на различные продукты (ProductUserId). Обратите внимание, что именно так будет выглядеть объектная инструкция при отправке на машину, все ключи установлены в машине, только идентификаторы пользователей отправляются на машину.
Инструкции географического объекта
Структура инструкции географии объекта в основном является копией настоящего ghd-файла.
Структура географической инструкции аналогична объектной инструкции. Сообщение о географической инструкции объекта включает ссылки на то, какие gis-файлы (слои) должны использоваться вместо того, чтобы включать ссылки на то, какие продукты должны использоваться на определенном объекте рубки. Это сообщение также содержит информацию о том, как должны быть представлены различные слои (форматирование) и какую информацию можно найти в дополнительных файлах данных (например, dbf-файлах).
Рис.31. Схема, описывающая структуры GIS (в основном копия ghd-файла). Обратите внимание, что некоторые переменные на приведенной выше диаграмме задаются в машине только после модификации gis-слоя.
XML-оболочка StanForD 2010 должна использоваться для вложения дополнительных файлов в случае ogi и ogr. Двоичные файлы должны быть встроены с использованием кодировки Base64 в оболочку Stan-ForD2010. Обратите внимание, что” escape-последовательность " должна использоваться для встроенных, но не закодированных документов. Это, например, означает, что > используется вместо>, а <-вместо <. Закодированный файл означает, что он включен в виде двоичной текстовой строки.
Краткая инструкция харвестера
Ниже приведена схема, описывающая три типа сообщений, отправляемых харвестеру. Различные сообщения на диаграмме 26 ниже представляют собой упрощенную версию, которая призвана дать читателю представление об основных различиях между этими сообщениями.
Рис.32. Диаграмма, описывающая различия между различными сообщениями, которые могут быть отправлены на харвестер. Инструкция по продукту сопоставима с настоящим файлом ap1, инструкция по объекту может включать информацию из apt-или oai-файлов, инструкция по специальным группам включает информацию из ap1 - и apt-файлов, а географическая информация объекта сопоставима с файлом ghd. Пунктирные стрелки и границы указывают на то, что структура необязательна.
Инструкция форвардера
Структура инструкций трелевки основана на переадресованном производственном сообщении, как описано на рис.22. Обратите внимание, что информация о конкретной машине и производственные данные исключены.
Рисунок 33. Диаграмма, описывающая структуры пересылки производственных данных.
Специфичная для объекта информация включается в определение объекта и местоположения (Object - and LocationDefinition), в то время как информация в определении SpeciesGroup-, Product - и DeliveryDefinition во многих ситуациях постоянна в течение длительного периода времени, охватывающего несколько объектов. Поэтому инструкция, посылаемая форвардеру, делится на два отдельных сообщения, таких как oin, spi и pin в случае харвестера.
Ниже приводится одна схема, иллюстрирующая конкретный объект информации в новом сообщении ForwardingObjectInstruction (рис. 34) и одна диаграмма, иллюстрирующая информацию, используемую независимо от объекта в новом ForwardingDeliveryInstruction сообщение (рис. 35).
Рис.34. Обзор ForwardingObjectInstruction.
Рис.35.Обзор конструкции ForwardingDeliveryInstruction.
ForwardingDeliveryInstruction должна обрабатываться так же, как и pin-файл. Это означает, что DeliveryUserID в foi-файле определяет, какие поставки будут использоваться в определенный момент времени.
Фактором, который делает вопрос о передаче инструкций довольно сложным, является тот факт, что требуемая информация может поступать из нескольких различных источников, как описано на рисунке ниже. Инструкция может быть отправлена из лесной компании, но она также может быть включена оператором вручную. Значительная часть соответствующих идентификационных данных также может быть найдена в hpr-файле от харвестера.
Рисунок 36. Пример, иллюстрирующий различные источники данных, которые могут быть использованы при запуске пересылки на новый объект рубок.
Предполагается, что при создании нового объекта в форвардере используется либо полная офисная инструкция, либо hpr-файл. Один oin-файл, вероятно, имеет ограниченное применение, поскольку он не содержит полного определения продукта (ProductDefinition) или определения спецгрупп (SpeciesGroupDefinition). Оператор должен вручную определить определения доставки и местоположения, если используется hpr-файл, так как эта информация не доступна в HPR-файле. Оператор всегда должен заполнять недостающие детали в случае использования hpr-файла.
Hpr-файл должен быть отправлен форвардеру, если собранные производственные данные должны быть доступны в форвардере. Это означает, что данные харвестера могут быть использованы только для информирования форвардера о собранных объемах, если форвардерная инструкция отправляется из офиса форвардеру.
Пользовательские данные
StanForD 2010 включает в себя гибкое решение для отправки специфичных для компании форм, например, последующих действий в цифровом формате (начиная с версии 2.1). Инструкция определяет пользовательские таблицы и анкеты, которые оператор заполняет вручную. Зарегистрированные вручную данные возвращаются с машины как часть сообщений либо для производственной отчетности, либо для оперативного мониторинга. Конкретные данные пользователя для последующего наблюдения могут включать очистку подлеска, потребление топлива, количество высоких пней для сохранения природы, информацию о посадках и т. д. Это означает, что мы надеемся избавиться от оператора, пишущего дополнительную информацию о компании на листе бумаги или в «excel».
На рисунке ниже показано решение для того, как инструкции отправляются машине от владельца лесной машины или лесозаготовительной организации, а затем возвращаются в сообщении StanForD.
Рис. 37 Отправка инструкций и возврат сообщений
Основная идея заключается в том, чтобы сделать возможным определение таблиц, которые оператор может использовать в машине для ручной регистрации данных, имеющих отношение к лесозаготовительной организации или владельцу машины.
Ввод / Инструкция
Ниже приведена иллюстрация, описывающая структуру инструкции пользовательских данных (Udi), которая выглядит следующим образом:
Рис. 38. Структура инструкции пользовательских данных
Обратите внимание, что определение DataRowDefinition было добавлено для того, чтобы можно было предварительно определить ряд вопросов с различными списками перечислений для разных строк.
DataTableGroupDefinition.
Эта структура сравнима с базой данных или "рабочей книгой excel", которая должна быть представлена одним способом.
Атрибуты для определения DataTableGroupDefinition:
• tableGroupId (обязательный, строка)
• tableGroupName (обязательно, строка) = имя определяемой пользователем таблицы данных, используемой в пользовательском интерфейсе
• outputDataLocation (обязательный, перечислительный список)
Определение DataTableGroupDefinition повторяется. Владельцу машины может потребоваться информация как по смене, так и по объекту лесозаготовок. Для этого есть возможности, чтобы добавить много DataTableGroupDefinitions. Идея заключается в том, что для каждого определения DataTableGroupDefinition в диалоговом окне будет новая "вкладка".
Атрибут outputDataLocation указывает на то, где определенные пользователем данные должны быть зарегистрированы, а затем сообщены. Включены следующие перечисления:
* ProductionObject, информация хранится для каждого объекта в файлах hpr, thp и fpr (используется ключ ObjectKey на рисунке ниже).
* MonitoringObject, информация хранится на объект в файлах mom (используется ObjectKey на рисунке ниже).
* MonitoringShift, информация хранится за смену в файлах mom (используется клавиша ShiftKey на рисунке ниже)). Это означает, что необходимо использовать элемент ShiftKey.
* ProductionLocation, информация хранится в каждом местоположении в файлах fpr (используется ключ LocationKey на рисунке ниже). Можно было бы предположить, что ключ LocationKey ссылается на последнее местоположение, где были выгружены любые Тома, если в одном объекте используется несколько различных местоположений.
* ProductionLocation, информация хранится в каждом местоположении в файлах fpr (используется ключ LocationKey на рисунке ниже). Можно было бы предположить, что ключ LocationKey ссылается на последнее местоположение, где были выгружены любые объемы, если в одном объекте используется несколько разных местоположений.
Выходные данные хранятся с использованием следующей структуры в hpr, thp, fpr и mom.
Рис. 39 Структура хранения выходных данных
Таблицы с ProductionObject и MonitoringObject - это таблицы конкретных объектов, которые должны быть сброшены с помощью нового объекта. Если outputLocation равен MonitoringShift, то таблица является специфичной для сдвига, то есть она должна быть сброшена при запуске нового сдвига.
DataTableDefinition.
Эта структура сравнима с таблицей базы данных или "рабочим листом excel".
Атрибуты для определения DataTableDefinition:
* tableId (обязательный, строка)
• tableName (обязательно, строка) = имя определяемой пользователем таблицы данных, используемой в пользовательском интерфейсе
* maxRowCount (обязательно, ”1” или “maxint”) = максимальное количество строк в пользовательской таблице данных.
* minRowCount (обязательно, ”0” или “1”) = Минимальное количество строк в пользовательской таблице данных.
* tableTriggerPoint введен вверсии 3. 0 (обязательные перечисления - "StartObject", "EndObject", "EndShift", "UnloadingComplete", "ChangeSubObject", "StartShift", "ChangeObject"). Атрибут, указывающий, когда определяемая пользователем таблица должна быть представлена оператору (в графическом интерфейсе (GUI) машины), чтобы упростить заполнение таблицы в нужное время.
DataColumnDefinition
Эта структура сравнима с полями в таблице базы данных или столбцами в “excel-листе”.
Атрибуты для определения DataColumnDefinition:
• columnId (обязательный, строка) = идентификатор столбца
• columnName (обязательно, строка) = имя столбца. Представлен в заголовке столбца.
• dataCategory (обязательный, перечисления =”перечисление”, “строка”, “целое”, “десятичное число”, “дата”, “ логический ” или “ последовательное целое число ”): определяет тип данных столбца.
* необязательный (обязательный, логический) = указывает, должен ли столбец заполняться оператором.
• columnOrder (обязательный, целочисленный)= порядок представления столбца в графическом интерфейсе.
* enumListId (необязательно, строка)= идентификатор списка перечислений. Например, " UnitList” относится к определению DataEnumDefinition (см. Также следующий раздел)
• блок (необязательный, строка) = определяет единицу столбца, например, мм, кг, м3, см и т. д. Может использоваться в графическом интерфейсе (GUI)для информирования оператора об устройстве.
DataColumnDefinition
Эта структура сравнима с полями в таблице базы данных или столбцами в “excel-листе”.
Атрибуты для определения DataColumnDefinition:
• columnId (обязательный, строка) = идентификатор столбца
• columnName (обязательно, строка) = имя столбца. Представлен в заголовке столбца.
• dataCategory (обязательный, перечисления = ”перечисление”, “строка”, “целое”, “десятичное число”, “дата”, “логически” или “последовательное целое”): определяет тип данных столбца.
* необязательный (обязательный, логический) = указывает, должен ли столбец заполняться оператором.
• columnOrder (обязательный, целочисленный) = порядок представления столбца в графическом интерфейсе.
* enumListId (необязательно, строка) = идентификатор списка перечислений. Например, " UnitList” относится к определению DataEnumDefinition (см. Также следующий раздел)
• блок (необязательный, строка) = определяет единицу столбца, например, мм, кг, м3, см и т. д. Может использоваться в графическом интерфейсе (GUI) для информирования оператора об устройстве.
DataRowDefinition
Эта новая предложенная структура используется для определения отдельных ячеек в строке, если, например, существует необходимость в определении различных перечислений в разных строках. Все включенные настройки должны переопределять настройки в DataColumnDefinition.
Атрибуты для определения DataRowDefinition:
• rowId (обязательный, строка) = идентификатор строки
* rowOrder (обязательный, целочисленный) = порядок представления строки в графическом интерфейсе (GUI).
Атрибуты для определения DataCellDefinition:
• cellId (обязательный, строка) = идентификатор ячейки
• cellText (необязательно, строка) = текст в ячейке. Например, вопрос, на который должен ответить оператор.
• dataCategory (опционально, перечисления =”перечисление”, “строка”, “целое”, “десятичное число”, “дата”, “логически” или “последовательное целое”) = определяет тип данных в текущую ячейку, заменяет DataColumnDefinition. Допустимые значения: перечислимый, целое число, строка, десятичное число, дата, логическое, последовательное, не в ряду.
* опционально (опция, логически): указывает, должна ли ячейка быть заполнена оператором.
• columnOrder (обязательный, целочисленный) = порядок столбцов для текущей ячейки в графическом интерфейсе.
* enumListId (необязательно, строка) = идентификатор списка перечислений. Например, " UnitList” относится к определению DataEnumDefinition (см. Также следующий раздел)
• блок (необязательный, строка) = определяет единицу столбца, например, мм, кг, м3, см и т. д. Может использоваться в графическом интерфейсе для информирования оператора об устройстве.
• readOnly (необязательно, Логическое значение) = указывает, может ли ячейка редактироваться оператором.
DataEnumDefinition
Эта структура включает в себя списки перечислений, которые будут использоваться в машине. EnumListId атрибут определяет список перечисления, которые будут использоваться.
Пример пользовательского интерфейса таблицы
Инструкция может отображать следующий графический интерфейс (GUI).
Рис. 40 Графический интерфейс
Список перечислений для столбца:
Рис. 41 Список перечислений
Инструкция также может отображать следующий графический интерфейс (GUI)(пример заполняется оператором):
Рис. 42 Пример заполнения
Вывод / Отчет
Данные проверяются в соответствии с определением перед созданием файла. Это означает, что все обязательные поля должны быть заполнены.
Ниже приведена структура для представления определяемых пользователем данных с машины, всегда включаемых в разделе, машина в mom, fpr, hpr или thp:
Рис. 43 определяемые пользователем данные
Пример пользовательского интерфейса
Выходные данные (XML), описанные выше, можно проиллюстрировать на следующем примере графического интерфейса пользователя (GUI).
Рис. 44 Графический интерфейс
Рис. 45 Заполнение пользователем
Управление различными инструкциями в машинах
Машина вполне может получать инструкции от нескольких различных организаций. И простое решение для обработки различных инструкций может заключаться в том, что оператор вручную выбирает, какие инструкции использовать при запуске на объекте лесозаготовки:
Рис. 46 Выбор инструкций раскряжевки.
Оператор вручную удаляет старые инструкции, которые больше не будут использоваться.
Сообщения, отправленные с лесной машины
Ниже приводится ряд сообщений, охватывающих производственные данные, данные контроля качества и данные оперативного мониторинга, передаваемые лесными машинами.
Нет никаких правил, касающихся частичной отчетности (данные сообщаются только один раз). Однако Skogforsk написал рекомендацию относительно сообщения hpr-сообщений. Эта рекомендация включена в приложение 1.
Должна быть обеспечена возможность генерировать полные производственные сообщения, включая всю собранную и переадресованную продукцию от одного конкретного объекта лесозаготовок (fpr и hpr).
Все сообщения обычно объектно-ориентированы, за исключением сообщения mom, которое всегда должно быть ориентировано на время. Это означает, что все времена в интервале отчета должны быть включены независимо от объекта лесозаготовок.
Настоятельно рекомендуется, чтобы все производители реализовали статическую папку (расположение), где файлы сохраняются по умолчанию, допустимо иметь отдельные папки для разных типов файлов. Например, важно, чтобы сообщения hpr не сохранялись в разных папках в зависимости от объекта рубок или даты рубок.
Срубленная продукция
Структура сообщений для собранного производства охватывает существующие stm-и pri-файлы.
Новая структура данных для производственной отчетности должна позволить:
* Идентифицировать несколько вхождений одинаковых стволов (используя комбинацию MachineKey и StmKey)
* Идентифицировать отсутствующие стволы (StemNumber-номер Бегущего ствола для каждого необходимого объекта)
* Определить местоположение (объект и подобъект) ствола
* Идентифицировать объекты для конкретной машины, если данные с нескольких машин включены в одно сообщение.
Пример: данные от харвестеров A и B объекта заготовки XX объединяются в одно сообщение. Должна быть предусмотрена возможность разделения объектных данных (например, даты начала и окончания) для двух харвестеров.
Будет использована структура, аналогичная настоящему pri-файлу (рис.27). Использование этой структуры позволит регистрировать данные от нескольких машин и объектов сбора урожая в одном сообщении. Аббревиатура означает идентификатор GUID глобальный уникальный идентификатор. Обратите внимание, что комбинация MachineKey, StmKey и LogKey должна быть абсолютно уникальной для каждого бревна.
Рис.47. Общий макет сообщения, включая данные о производстве харвестера. Диаграмма также описывает, как могут быть использованы подобъекты. Обратите внимание, что многоствольная обработка не включена.
Более подробное описание собранных производственных данных приведено на рис.28. Включены дополнительные структуры для векторов диаметра и ранга, которые сегодня можно найти в stm-файле. Обратите внимание, что такого рода очень подробная информация должна быть включена только в том случае, если есть четко выраженная потребность в этой информации, например, при анализе результатов оптимизации раскряжевки.
Рис.48. Диаграмма, описывающая подробные данные о лесозаготовке.
Мы не включили в диаграмму 28 возможность регистрации отдельных направлений измерения диаметров (поперечное измерение). Регистрируются только абсолютные отфильтрованные значения диаметра.
Обратите внимание, что дата рубок "HarvestingDate" для каждого ствола является необязательной. Всегда должна быть возможность установить в машине, хотите ли вы включить HarvestingDate в hpr. Это конфиденциальная информация для отправки в лесную компанию, которая не владеет харвестером. Однако эта информация может быть очень полезной не только тогда, когда владелец машины хочет провести детальные исследования производительности, но и тогда, когда информация передается от харвестера к форвардеру. Это позволило бы оператору форвардера очень легко увидеть, что харвестер срубил, например, за последние 12 часов. Какие сорта бревен были срублены и где они расположены.
Обработка нескольких деревьев (MultiTreeHandling)
Структура hpr может использоваться как для одиночных заготовленных деревьев, так и для многодревесных заготовленных стволов (MTH), как показано на рисунке ниже.
Рис. 49. Иллюстрация различных категорий обработки в hpr-файле
Преимущество наличия MTH (пачки, прим. перев.) деревьев в одной и той же структуре состоит в том, что мы получаем одну структуру для всех стволов. Каждый отдельный ствол, собранный вместе (стволы в пучке стволов), регистрируется отдельно под элементом ствол. Общее количество стволовых элементов должно быть равно общему количеству собранных стволов.
Следующие данные включены для каждого ствола, чтобы использовать одну и ту же структуру для одиночных и многодревесных собранных стволов:
• Обязательным элементом StemBunchKey который представляет собой порядковый номер, используемый для всех MTH стволов. Все стволы в пучке стволов получают один и тот же ключ StemBunchKey, это означает, что можно анализировать пучок стволов.
* Указание на то, были ли измерены бревна (их объем) или если одно или несколько бревен были оценены с использованием новых типов объемов бревен: m3subEstimated и m3sobEstimated
* DBH обычно является экстраполированным диаметром, так как головка харвестера обычно измеряет первый диаметр на несколько дециметров ниже 120 см (высота от пня). Поэтому ReferenceDiameter элемент был включен для того, чтобы зарегистрировать фактически измеренный диаметр MTH стволов.
* Элемент ProcessingCategory указывает, какой тип сбора урожая был сделан. Этот элемент особенно полезен в случае SingleTreeFelling без данных измерений, доступных для регистрации в рамках структуры SingleTreeFelledStems.
Обратите внимание, что все приведенные ниже данные MTH (исключая LogVolume) обычно будут представлять первый ствол, если не измерены для каждого отдельного ствола: HarvestDate, DBH, Coordinate, StemGrade, StemDiameter, LogDiameter и LogLength.
Не смешивайте обработку одного дерева, обработку нескольких деревьев, рубку (много-и одно-древесную рубку) при расчете средних объемов ствола.
Правила
Один и тот же DBH, ReferenceDiameter и разновидности регистрируются для всех стволов в пучке стволов, если только DBH и разновидности измеряются/регистрируются для первого ствола. Расчетные объемы бревен также должны быть идентичны и представлять собой отдельный журнал бревен, а не связку бревен. Элемент должен быть включен StemBunchKey. Только LogVolume перечисления m3sobEstimated и m3subEstimated должны использоваться для многодревесных "MultiTreeHarvested" стволов.
Пример.
Возможно только измерить и зарегистрировать DBH и вид первого ствола. Пример сегодняшних данных приведен в таблице 7 ниже.
Таблица 7. Три пучка стволов, где DBH и вид\порода измеряются только на первом стволе
ПучокВид\порода 1-го стволаDBH 1-го стволаНомер ствола1Pine - сосна12132Spruce - ель10623Pine - сосна1312
Приведенная ниже таблица иллюстрирует, как стволы MTH в таблице 7 будут регистрироваться в hpr.
Таблица 8.
StemNo-PerObStemBunchKeySpecies-Group\ПородаDBHreference Diameter\опорный диаметрNoOfStems11Сосна121129321Сосна121129331Сосна121129342Ель106109252106109263Сосна131138273Сосна1311382
Неклассифицированные бревна
Неклассифицированные бревна регистрируются в той же структуре, что и обычные бревна. Однако ключ ProductKey для этих записей должен ссылаться на жестко закодированное определение ProductDefinition типа MeasuredUnclassifiedProduct. Это определение продукта никогда не должно быть отправлено на машину из лесозаготовительной организации.
В следующей таблице показаны различия между определениями продукта для классифицированных и неклассифицированных бревен.
Таблица 9
MeasuredClassified-ProductDefinitionMeasuredUnclassified-ProductDefinitionProductKeyProductKeyProductKeyProductKeyProductKeyProductKeyProductKeyProductKeyProductNameProductNameProductNameProductNameSpeciesGroupUserIdSpeciesGroupUserIdLoggingOrganizationProductGroupProductUserIdSpeciesGroupKeyDiameterDefinitionLengthDefinitionPriceDefinition
Общая срубленная продукция
Некоторые производители видят необходимость в том, чтобы иметь возможность регистрировать общие объемы по объекту, субобъекту, продукту и оператору. Таким образом, структура, описанная на рис.20, была включена в отдельное сообщение об общем объеме собранной продукции. Это сообщение будет представлять интерес в тех случаях, когда нет необходимости в подробной информации об отдельных журналах и когда коммуникационные возможности низки. Это "ящик Пандоры", очень строгие правила о том, чтобы не добавлять новые данные в эту структуру, должны быть согласованы.
Рисунок 50. Диаграмма, описывающая предлагаемые переменные для регистрации общего объема производства (prd-light).
Общее собранное сообщение о продукции всегда должно включать все данные от HarvestingStartDate- объекта заготовки до момента создания сообщения (SaveDate). Другими словами, это означает, что сообщение содержит только накопленные данные.
Контроль качества вырубки
Структура сообщений для контроля качества охватывает старые ktr-и stm-файлы.
Сообщение о контроле качества заготовки определяется как отдельное сообщение, но имеет ту же структуру, что и сообщение о производстве заготовки. В это сообщение должны быть включены только стволы, используемые специально для контроля или калибровки.
Сообщение управления качеством, представленная на рис. 21 ниже. Обсуждалась также возможность включения других данных, помимо данных контроля качества измерений, но они будут содержаться в отдельном сообщении.
Вся передача данных, связанная с контролем качества измерений, будет осуществляться с использованием сообщения hqc. Это включает в себя как отправку данных в калибр, так и из него. Элемент DiameterVector должен быть включен с диаметрами на каждый модуль в дм. при отправке hqc на калибр. Hqc, отправленный в калибр, должен включать в себя исторический журнал относительно отклоненных стволов и калибровки. Это означает, что харвестеры StanForD 2010 должны ”предлагать” полный hqc (включая данные M1 и журнал калибровки/отбраковки) системе управления и калибровки (например, калибр вместе с com драйвером).
Старый протокол Кермит будет исключен из StanForD 2010. Это означает, что никакого увеличения скорости передачи Кермит не требуется. Другими словами, производители машин и калибров должны решить, как настроить связь, которая может быть основана на каком-то ком-драйвере. Драйвер com - это коммуникационное программное обеспечение, расположенное либо в передающей, либо в приемной части системы (харвестер / калибр / измерительный датчик). При использовании драйвера com это будет совместное решение производителя машины и производителя электронного калибра о том, какой протокол связи и какой тип файлов следует использовать.
Во избежание проблем было решено, что файлы hqc, отправленные из системы контроля и калибровки, никоим образом не должны изменяться харвестером.
Другими словами, вопрос о том, нужны ли стандартизированные папки для ввода - вывода во внешний usb, является вопросом между производителями харвестеров и электронных калибров.
Рисунок 51. Общий макет сообщения о контроле качества. "Ktr-data" означает данные, обычно измеряемые вручную и регистрируемые в компьютерном электронном калибре. Пучки стволов MTH в настоящее время не включены в сообщения hqc.
Данные об истории калибровки (рис. 33) также будут включены в сообщение о контроле качества вырубки.
Рисунок 52. Диаграмма, описывающая журнал калибровки.
Стрелеванная продукция
Структура для производства форвардеров охватывает старый prl-файл.
Новые структуры LocationDefinition и DeliveryDefinition были добавлены к переадресованному производственному сообщению при сравнении со старым prl-файлом (рис.25). Старый TranspObject в основном разделен на эти две новые структуры.
Рисунок 53. Общий макет производственного сообщения форвардера.
Следующие структуры являются специфичными для fpr-сообщения:
* Загрузка и частичная загрузка включает в себя производство форвардера (без единиц измерения, объема, массы), идентификацию оператора и время разгрузки. Доставка и место должны быть зарегистрированы для каждой выгрузки в элементной структуре PartialLoad.
* Определение поставки включает описание (содержание) продукции форвардера, ссылки на заготовленные продукты и временные метки (начало/конец). Он также может содержать ссылку на конечный пункт назначения (завод).
* Определение местоположения включает в себя спецификацию того, где была выгружена продукция форвардера, в виде координат и объекта лесозаготовки. Также возможно описание состояния дороги.
Это означает, что если планируется транспортировка из леса до фабрики, то соответствующие объемы можно найти в структуре определения загрузки LoadDefinition, содержание и пункт назначения доставки -в определении доставки DeliveryDefinition (в сочетании с определением продукта ProductDefinition), а положение доступных объемов-в определении местоположения LocationDefinition.
Можно определить следующее для каждой выгрузки, используя структуру, показанную выше:
* Спецификация поставки (содержание)
• Местоположение
• Объект лесозаготовки
• Оператор
• Один или несколько объединенных продуктов (ассортиментов)
Обратите внимание, что определение доставки DeliveryDefinition может быть связано с несколькими местоположениями и что несколько местоположений могут существовать в одном объекте лесозаготовки.
Рис.54. Детальный просмотр fpr-структуры, включая все данные производства.
Следующие ключи имеют решающее значение для идентификации конкретной нагрузки:
• Один DeliveryKey зарегистрирован для каждой выгрузки (load dataset)
• Один или несколько ключей продукта ProductKeys, зарегистрированных для каждого определения доставки DeliveryDefinition
• Один ключ LocationKey зарегистрирован для каждой выгрузки (load dataset)
• Один ключ ObjectKey зарегистрирован для определения местоположения LocationDefinition
Ниже приведена диаграмма, иллюстрирующая эти первичные ссылки между данными загрузки, доставкой, продуктом, местоположением и объектом рубок.
Рис.55. Ссылки между данными загрузки, доставкой, продуктом, местоположением и объектом лесозаготовки в fpr-файле.
Следующий рисунок иллюстрирует тот факт, что общее пройденное расстояние между точками 1 и 4 (красные стрелки) должно быть включено в дистанцию от разгрузки при выгрузке балансов и малоразмерных пиловочных бревен.
Рисунок 56 иллюстрирует DistanceFromLastUnloading.
FPR Примеры
Два различных примера включены в этот документ, чтобы проиллюстрировать, как fpr-сообщение может использоваться, когда необходимо зарегистрировать определенные объемы продукта, а также когда несколько продуктов объединяются в один транспортный объект TransportObject.
Производство на единицу продукции (ассортимент)
Это пример того, как использовать предложенную структуру, когда цель состоит в том, чтобы зарегистрировать переадресованные объемы на собранный продукт и объект сбора урожая.
Количество заготовленной продукции на объекте описано в таблице 1.
Таблица 1. Заготовленные продукты в примере форвардера
Определено только одно место, так как предполагается, что для каждой площадки не требуется никакой спецификации (табл.2).
Таблица 2. Одно место на объекте лесозаготовки
Определяется одна поставка на продукт, что означает, что мы имеем однозначную связь между определением продукта ProductDefinition и определением DeliveryDefinition:как показано в таблице 3.
Таблица 3. Доставка одного продукта на лесозаготовительный объект.
Вышеуказанные поставки можно рассматривать как копии определений продуктов с некоторой дополнительной информацией, такой как даты начала и окончания.
Один набор данных на выгрузку (уникальная комбинация загрузки, определения доставки DeliveryDefinition и Location) регистрируется в элементах Load и PartialLoad, как показано в таблице 4
Таблица 4. Пересылаемые суммы регистрируются по местоположению и доставке в элементе PartialLoad
Данные о состоянии трелевки на конкретную комбинацию локации и доставки регистрируются в ForwardStatus, как показано в таблице 5.
Таблица 5. Пример пересылки статусных данных
Производство в зависимости от отрасли и местоположения
Определение доставки DeliveryDefinition и ProductDefinition в основном идентичны в предыдущем примере. Так зачем же включать определение DeliveryDefinition в fpr-сообщение?
Собранные продукты часто объединяются вместе форвардером и выгружаются в одни и те же штабеля, так как эти продукты часто доставляются в одну и ту же фабрику.
Очень распространенным случаем в Швеции является то, что балансовые бревна как из ели, так и из сосны смешиваются и транспортируются на одну и туже фабрику, то же самое происходит и с биоэнергетическими сортами. Другим примером может быть транспортировка всех ассортиментов на терминал, где они сортируются и измеряются, и единственным соответствующим объемом при транспортировке является общий объем.
На лесозаготовительном объекте была собрана следующая продукция:
Количество заготовленной продукции на объекте описано в таблице 6.
Таблица 6. Заготовленные продукты в примере к трелевке
В этом случае определяются два отдельных местоположения, поскольку предполагается, что требуется спецификация для каждой площадки (Таблица 7).
Таблица 7. Два места на объекте ллесозаготовок
Вся балансовая древесная продукция должна транспортироваться на один завод и то же самое условие есть для энергетических сортиментов. Таким образом, определения поставки DeliveryDefinitions 13 и 14 включают два продукта, что означает, что мы имеем отношение один к двум между определением поставки DeliveryDefinition и определением продукта ProductDefinition для поставки целлюлозы и энергии Delivery Pulp and Energy, как показано в таблице 8.
Таблица 8. Четыре поставки на лесозаготовительный объект, где есть ссылки на несколько продуктов в двух случаях
Один набор данных на разгрузку (уникальное сочетание определения загрузки и доставки) регистрируется в элементе Load and PartialLoad (таблица 9).
Таблица 9. Пересылаемые суммы регистрируются по местоположению и доставке в элементе PartialLoad
LoadKey 2 в приведенной выше таблице имеет ссылку на энергию доставки, которая также имеет ссылки на продукты PineEnergy и SpruceEnergy, а также ссылку на местоположение Location Юг.
Данные о состоянии трелевки в конкретную комбинацию местоположения и доставки регистрируются в ForwardStatus, как показано в таблице 5.
Таблица 10. Пример ForwardingStatus данных
Контроль качества трелевки форвардером
В январе 2010 года было предложено включить в StanForD 2010 новое сообщение о контроле качества работы форвардеров.
Это сообщение в первую очередь основано на старом var61, который был реализован 2009-04-01. Основное внимание уделяется контролю и калибровке весов форвардера.
Рис. 57. Диаграмма структура контроля качества трелевки
Таблица 10. Элементы, специфичные для контроля качества трелевки
НаименованиеОписаниеScaleControlDateДата и время контрольного измерения весовой шкалы:ControlReferenceMassЭталонный вес, вес объекта управления, например испытательного объекта или весового моста. (килограммовый)ScaledMassЗарегистрирована масса контрольного масштабирования в форвардере за один случай масштабирования. Весовые значения шкалы экспедитора. (килограммовый)scaleWorkCategory
Тип работы форвардера при взвешивании с помощью весовой шкалы: погрузка или выгрузка (перечислительный список).
Переменная используется только для контрольных измерений весовой шкалы.
scaleControlCategoryКатегория контроля масштаба: "случайная динамическая масса" или " ручная фиксированная масса"OrientationОриентация крана при регулировании масштаба: "правая сторона грузового пространства" или " левая сторона грузового пространства"ScaleCalibrationDateДата и время калибровки весовой шкалыScaleCalibrationAdjustРегулировка шкалы, % (старый текст: коэффициент, используемый при взвешивании.)scaleWorkCategory
Тип работы форвардера при взвешивании с помощью взвешивающих весов: погрузка или выгрузка (перечислительный список).
Переменная используется только для контрольных измерений весовой шкалы.
ScaleKeyНаименование и удостоверение сертификата типа экспертизы на масштабирование (свободный текст)ScaleIDИдентичность весовScaleModelТип модели и производитель (свободный текст)ScaleCategoryТип весов: грейферная шкала или шкала несущей нагрузки (список перечислений)ScaleApplicationVersionВерсия программы весовScaleCertificateНаименование и удостоверение свидетельства о типовой экспертизе для весов
Рапорт географии объекта
Структура объектного географического отчета в значительной степени является копией настоящего ghd-файла.
Структура географического отчета аналогична географической инструкции. Сообщение Object Geographic report содержит ссылки на то, какие ГИС-файлы (слои) были использованы в машине. Это сообщение также содержит информацию о том, как должны быть представлены различные слои (форматирование) и какую информацию можно найти в дополнительных файлах данных (например, dbf-файлах).
Ряд переменных включены для определения того, какие изменения и обновления были сделаны, а также кем.
Рис.58. Схема, описывающая структуры ГИС (в основном копия ghd-файла). Обратите внимание, что некоторые переменные на диаграмме выше не включены в географическую инструкцию (красный текст).
Оперативный контроль
Структура оперативного мониторинга охватывает старые drf-и rep-файлы.
Новое сообщение мониторинга всегда должно быть ориентировано на время, что означает, что мы регистрируем все времена в течение определенного временного интервала. Основная причина этого заключается в том, что если мы использовали одну и ту же машину на разных объектах, например переходя от объекта А к объекту В, а затем регистрируя только данные для объекта А, то машина будет казаться неактивной, в то время как она фактически выполняла работу на объекте В. Конечно, можно извлечь только данные, охватывающие определенный объект сбора урожая, если дата начала и дата окончания равны выбранному интервалу времени.
Время регистрируется как различные типы времени, которые могут отображаться отдельно и сравниваться для последующих целей. Основными типами, которые будут использоваться, являются:
• время работы машины
o другие данные машины (производство , топливо, расстояние).
• время работы оператора
Эти различные типы времени можно будет нарисовать как отдельные, но сопоставимые временные линии (рис.25-27). Кроме того, можно будет сравнить данные мониторинга с производственными данными, если время рубки и разгрузки будет зарегистрировано в производственных сообщениях.
Рис.59. Общий макет сообщения, включающий данные оперативного мониторинга.
Рис. 60. Диаграмма, описывающая переменные для других данных, связанных с производительностью, в сообщениях мониторинга. ** Производственные данные от харвестеров и форвардеров могут вместо этого регистрироваться в производственных файлах.
Рисунок 40. Пример, иллюстрирующий данные оперативного мониторинга в виде шести отдельных, но сопоставимых временных линий. * Оператор не работает на машине или с ней.
Рисунок 62. Пример индивидуальной регистрации времени в сообщении оперативного мониторинга (сокращенный формат даты и времени)
Рис.63. Пример регистрации входа и выхода из системы.
Рис. 64. Пример регистрации короткого времени простоя, обратите внимание, что также можно будет зарегистрировать короткое время простоя в таблице частот, как в настоящем стандарте.
Также может представлять интерес определение структур для регистрации:
• Основные показания машины (резка, валка, подача, движение машины и т. д)
Рис.65. Пример регистрации времени в сообщении оперативного мониторинга (сокращенный формат даты и времени)
Индивидуальное против комбинированного времени работы машины
Время работы машины должно включать потерянное время (неиспользованное время). Это означает, что сумма всех времен, зарегистрированных как время работы машины (element MachineWorkTime), должна быть равна общему интервалу отчета, зарегистрированному в элементе ReportInterval. Суммарное время работы оператора (OperatorWorkTime элемента), как правило, не быть таким же, как продолжительность временного интервала в ReportInterval.
В первых черновых версиях StanForD 2010 года предполагалось, что в новых сообщениях оперативного мониторинга (МОМ) будут регистрироваться только отдельные моменты времени. Однако это решение было приемлемо не для всех производителей. Была выявлена необходимость в том, чтобы также иметь возможность регистрировать различные виды комбинированного или агрегированного времени. Таким образом, в mom-файл включены две отдельные структуры для регистрации индивидуального и комбинированного времени работы машины. Отдельные экземпляры "обработки “-“Processing”могут быть зарегистрированы в индивидуальном времени работы машины (IndividualMachineWorkTime )или сумма времен” обработки" “Processing”может быть зарегистрирована в комбинированном времени работы машины(CombinedMachineWorkTime). Эти структуры описаны на рисунке 33. Обратите внимание, что короткое время простоя также может
Рисунок 66. Диаграмма, описывающая различия между комбинированным и индивидуальным временем в сообщении оперативного мониторинга.
Наиболее заметное различие между этими структурами заключается в том, что может быть зарегистрировано только одно отдельное время (время выполнения, время простоя или неиспользуемое время) для каждого элемента MachineWorkTime, в то время как несколько различных времен могут быть включены для каждого элемента MachineWorkTime при регистрации объединенных времен.
Комбинированные времена делают это:
• Более сложное сравнение mom-данных с hpr и fpr (включая временные метки).
• Более сложные для расчета ключевые показатели для любого временного интервала.
Время работы оператора
Время работы оператора всегда регистрируется как индивидуальное время в следующей структуре. Для OtherOperatorTimeCategory существуют следующие перечисления:
• MachineRunTime
* Ожидание ремонта
* Перевозка на трейлере
* Перерыв на еду
* Планирование (работы-прим) вне машины
* Перемещение для работы вне машины
• Другая работа вне машины
Обратите внимание, что элемент MachineRunTimeCategory должен быть проанализирован для извлечения информации о том, какую именно машинную работу выполнял оператор, например обработку Processing, перемещение по местности Terrain travel, другие работы Other work или дорожное путешествие Road travel.
Существенная разница между временем работы оператора и временем работы машины заключается в том, что время работы оператора может перекрываться.
Примеры
Пример 1
Ниже приведен пример с временной линией с рядом различных времен работы и простоя, происходящих на харвестере:
Рис. 67 Времена регистрации
Ниже приведены два xml-примера, описывающие, как эта временная линия может быть зарегистрирована.
Только индивидуальное время рапорта в .mom (рассматривать исключение ObjKey)
<IndividualMachineWorkTime>
<OperatorKey>2</OperatorKey>
<MonitoringStartTime>2001-12-17T09:30:47.0Z</MonitoringStartTime>
<MonitoringTimeLength>10</MonitoringTimeLength>
<IndividualMachineRunTimeCategory>Processing</IndividualMachineRunTimeCategory>
</IndividualMachineWorkTime>
<IndividualMachineWorkTime>
<OperatorKey>2</OperatorKey>
<MonitoringStartTime>2001-12-17T09:40:47.0Z</MonitoringStartTime>
<MonitoringTimeLength>15</MonitoringTimeLength>
<IndividualUnutilizedTimeCategory>Meal break</IndividualUnutilizedTimeCategory>
</IndividualMachineWorkTime>
<IndividualMachineWorkTime>
<OperatorKey>2</OperatorKey>
<MonitoringStartTime>2001-12-17T09:55:47.0Z</MonitoringStartTime>
<MonitoringTimeLength>19</MonitoringTimeLength>
<IndividualMachineDownTime>
<Repair>
<CarrierRepairReason>
<Mechanical>Gearbox</Mechanical>
</CarrierRepairReason>
</Repair>
</IndividualMachineDownTime>
</IndividualMachineWorkTime>
<IndividualMachineWorkTime>
<OperatorKey>2</OperatorKey>0
<MonitoringStartTime>2001-12-17T10:14:47.0Z</MonitoringStartTime>
<MonitoringTimeLength>51</MonitoringTimeLength>
<IndividualMachineRunTimeCategory>Processing</IndividualMachineRunTimeCategory>
</IndividualMachineWorkTime>
<IndividualMachineWorkTime>
<OperatorKey>2</OperatorKey>
<MonitoringStartTime>2001-12-17T11:05:47.0Z</MonitoringStartTime>
<MonitoringTimeLength>5</MonitoringTimeLength>
<IndividualMachineRunTimeCategory>Terrain travel</IndividualMachineRunTimeCategor>
</IndividualMachineWorkTime>
<IndividualMachineWorkTime>
<OperatorKey>2</OperatorKey>
<MonitoringStartTime>2001-12-17T11:10:47.0Z</MonitoringStartTime>
<MonitoringTimeLength>25</MonitoringTimeLength>
<IndividualMachineDownTime>
<Repair>
<CarrierRepairReason>
<Mechanical>Gearbox</Mechanical>
</CarrierRepairReason>
</Repair>
</IndividualMachineDownTime>
</IndividualMachineWorkTime>
<IndividualMachineWorkTime>
<OperatorKey>2</OperatorKey>
<MonitoringStartTime>2001-12-17T11:35:47.0Z</MonitoringStartTime>
<MonitoringTimeLength>22</MonitoringTimeLength>
<IndividualUnutilizedTimeCategory>Meal break</IndividualUnutilizedTimeCategory>
</IndividualMachineWorkTime>
Совокупное (агрегированное) время, сообщенное в mom:
Существенные различия (агрегированные данные) между комбинированным и индивидуальным временем выделены жирным шрифтом. Обратите внимание, что время простоя регистрируется индивидуально:
<CombinedMachineWorkTime>
<OperatorKey>2</OperatorKey>
<StartTime>2001-12-17T09:30:47.0Z</StartTime>
<ObjectKey>2</ObjectKey>
<CombinedMachineRunTime>
<MachineRunTimeCategory>Processing</MachineRunTimeCategory>
<TimeLength>61</TimeLength>
</CombinedMachineRunTime>
<CombinedMachineRunTime>
<MachineRunTimeCategory>Terrain travel</MachineRunTimeCategory>
<TimeLength>5</TimeLength>
</CombinedMachineRunTime>
<CombinedMachineDownTime>
<Repair>
<CarrierRepairReason>
<Mechanical>Gearbox</Mechanical>
</CarrierRepairReason>
</Repair>
<TimeLength>19</TimeLength>
</CombinedMachineDownTime>
<CombinedMachineDownTime>
<Repair>
<CarrierRepairReason>
<Mechanical>Gearbox</Mechanical>
</CarrierRepairReason>
</Repair>
<TimeLength>25</TimeLength>
</CombinedMachineDownTime>
<CombinedUnutilizedTime>
<UnutilizedTimeCategory>Meal break</UnutilizedTimeCategory>
<TimeLength>37</TimeLength>
</CombinedUnutilizedTime>
<CombinedEndTime>2001-12-17T11:57:47.0Z </CombinedEndTime>
</CombineMachineWorkTime>
Пример 2
Как обрабатывать время работы оператора при объединении данных от одного оператора, работающего на разных машинах?
Следующий пример иллюстрирует приведенный выше вопрос:
1. Утром оператор начинает работать на машине.
2. Машина ломается в течение дня, и оператор вынужден использовать резервную машину.
Важным соображением является то, является ли это в первую очередь проблемой StanForD или проблемой, которая должна рассматриваться в административной системе, получающей данные от машинных систем.
Рисунок 68. Упрощенная структура данных при объединении данных оперативного мониторинга с двух отдельных машин в одно сообщение. Обратите внимание, что способ идентификации оператора заключается в использовании идентификатора OperatorUserId, оператор должен использовать точно такой же идентификатор OperatorUserId в обеих машинах, чтобы можно было получить общее количество рабочих часов для отдельного оператора.
Рисунок 69. Следующая временная шкала может быть рассчитана с использованием данных, приведенных в приведенном выше примере.
Прочие сообщения
STANFORD 2010 упаковка сообщений (конверт)
В стандарт также входит сообщение для передачи нескольких файлов вместе. Это сообщение называется конвертом (.env). Предполагается, что он будет использоваться для объектных географических пакетов. Также рекомендуется, чтобы производители могли использовать конверты, включающие полный набор сообщений для инструкций по сбору урожая (oin, pin, spi).
Рис. 70. Базовая структура StanForD 2010 упаковки сообщений-конверт
Документ может быть либо вложен в конверт, либо сохранен в виде отдельного файла (внешний документ). Встроенный документ может быть закодирован (например, сжатый файл).
Должно быть возможно использовать конверт StanForD 2010 в качестве контейнера сообщений StanForD 2010 для связи, но также должно быть возможно генерировать основные индивидуальные сообщения StanForD 2010 без оболочки конверта в лесных машинах.
Сообщения StanForD 2010 не совсем хорошо сформированы из-за общей структуры XML-документов. Таким образом, все символы во встроенных документах “<” и “>” должны быть изменены на escape-последовательности "и".
Все двоичные файлы (например, сжатые файлы и изображения), встроенные в сообщение конверта StanForD 2010, должны быть закодированы с использованием кодировки Base64.
Конверт StanForD 2010 следует использовать для вложения дополнительных файлов в случае ogi и ogr. Управление дополнительными файлами в сообщениях проще, если они упакованы в конверт.
Элемент расширения
Элемент, называемый расширением, существует во всех различных сообщениях во многих различных местах, чтобы сделать возможным добавление информации о производителе или пользователе вне стандарта.
Удлинитель был спроектирован таким образом, чтобы быть максимально гибким. Подробную документацию по элементу расширения можно найти в главе 10 документа “StanForD 2010 – Naming and design rules”.
Однако существует небольшая вероятность того, что имена элементов и атрибутов внутри элементов расширения могут конфликтовать между сообщениями StanForD 2010 разных организаций. Поэтому мы должны использовать специфические для организации пространства имен, чтобы различать имена между ними. Пространство имен должно быть выбрано таким образом, чтобы мы могли быть уверены, что другие организации не используют это имя. Хорошим кандидатом на пространство имен является производное от доменного имени организации.
ПРИМЕР РАСШИРЕНИЯ ВКЛЮЧАЯ ПРОСТРАНСТВО ИМЕН
Корневой элемент находится как обычно:
<?xml version="1.0" encoding="utf-8"?> <HarvestedProduction areaUnit="ha" diameterUnit="mm" lengthUnit="cm" volumeUnit="m3" weightUnit="kg" version="3.0" messageType="hpr" versionDate="2014-12-15+02:00" xsi:schemaLocation="urn:skogforsk:stanford2010 HarvestedProduction_V3p0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:skogforsk:stanford2010"> <HarvestedProductionHeader>
Выше не определено дополнительное пространство имен. Только префикс xsi и пространство имен по умолчанию (то есть то, которое предполагается в этом элементе и всех его дочерних элементах без префикса) определены, как и в любом обычном файле SF2010. В блоке <Extension> продукта / ассортимента, который должен иметь некоторые пользовательские данные, мы могли бы иметь:
<ProductDefinition>
<ProductKey>313</ProductKey>
<ClassifiedProductDefinition>
<ProductName>PS 1</ProductName>
…..
<Extension>
<PreSelectionProduct xmlns="http://www.deere.fi/xml/forestry">
<TopSaw>0</TopSaw>
<FeedingSpeed>0</FeedingSpeed>
</PreSelectionProduct>
</Extension>
Здесь были добавлены некоторые специфические для производителя элементы < PreSelectionProduct> с его дочерними элементами. Начиная с этого элемента и включая его, пространство имен по умолчанию “urn:skogforsk:stanford2010” переопределяется нашим собственным. Это делает <PreSelectionProduct> вместе со всеми своими детьми принадлежать к нашему “http://www.deere.fi/xml/forestry-пространство имен. Когда блок заканчивается, < / Extension> снова принадлежит пространству имен "urn: skogforsk:stanford2010".
Что касается пространства имен, используемого выше; URL-адрес не должен никуда вести, а этот-нет. Он не проверяется никаким парсером или валидатором или чем-то еще, он только должен быть довольно уникальным. Однако некоторые компании могут размещать некоторые релевантные данные, доступные на странице, указанной URL-адресом пространства имен.
Примеры использования в лесозаготовке
В качестве основы для дальнейшего развития StanForD 2010 use cases является хорошим инструментом. Это также хороший способ проиллюстрировать, как стандарт должен использоваться и реализовываться в машинах.
Ниже приведены три варианта использования для лесозаготовки. Первый пример иллюстрирует, как использовать StanForD 2010 таким же образом, как обычно используется StanForD в Швеции сегодня. Второй пример в определенной степени основан на том, как построена финская Apteri-система, в то время как третий вариант является гибкой альтернативой, где новые обновленные продукты могут быть отправлены и использованы в любое время.
Apt-файл (простая вырубка)
Шаг 1
Полные инструкции рассылаются перед началом лесозаготовок на объекте. Все продукты, которые будут использоваться, включены в pin-сообщение. В основном pin-код и oin-сообщения вместе функционируют как старый apt-файл. Четыре отдельных продукта включены в пример, как показано на диаграмме ниже.
Рисунок 71
Шаг 2
Данные о производстве, оперативном мониторинге и контроле качества представляются один раз в день.
Рисунок 72
Шаг 3
Новый набор инструкций посылается машине перед началом работы над новым объектом. Цены на продукты были изменены, и, следовательно, им были даны новые даты модификации. Старые определения продуктов, отправленные на шаге 1, заменяются новыми.
Рисунок 73
Полные старые определения продукта теоретически могут быть удалены, как только они будут заменены новыми. Однако это, вероятно, хорошая идея “чтобы только "деактивировать" их и сохранить их в каком-то архиве, если кто-то хочет иметь возможность вернуться и проанализировать производство конкретного объекта в более позднее время.
Рубка APTERI
Шаг 1
Инструкции по продукту (pin-код) отправляются непрерывно при обновлении в машину независимо от объекта лесозаготовки.
Рисунок 74
Шаг 2
Объектная инструкция (oin) отправляется харвестеру непосредственно перед началом работы на объекте. Эта инструкция включает ссылки (ProductUserId) на продукт, который должен быть собран на объекте.
Рисунок 75
Шаг 3
Данные о производстве, эксплуатационном контроле и контроле качества непрерывно передаются с машины. Обновленная географическая информация отправляется, когда объект завершен. Предполагается, что в харвестерах реализована автоматическая процедура, при которой можно установить, что эти отчеты будут генерироваться, например, дважды в день, а также при завершении объекта.
Рисунок 76
Гибкая вырубка
Третий гибкий Flexible пример очень похож на пример Apteri. Существенная разница заключается в том, что должна быть возможность отправлять обновленные инструкции объекта (oin) и продукта (pin) харвестерам в любое время до или во время производства на конкретном объекте уборки, чтобы, например, активировать определенный продукт или изменить матрицу распределения существующего продукта.
Рисунок 77
Ниже следует несколько более конкретный пример того, как управлять инструкциями по продукту и объекту, отправленными в харвестер.
Шаг 1
Инструкция по продукту (pin), включающая четыре продукта, отправляется в харвестер
Рис. 78
Шаг 2
Новый объект обучения (oin), отправленный в харвестер
Рис. 79
Шаг 3
Новый объект сбора урожая начался со следующих продуктов согласно сообщению oin
Рис 80
Шаг 4
Новая инструкция по продукту " PineSaw” (новые классы диаметров и повышенная цена), отправленная на харвестер во время рубки на “PinkForest_1380”
Рис. 81
Оператору задают вопрос: заменить старую PineSaw на новую?
Ответ: да!
Новая объектная инструкция (oin), включающая продукт "ельник", отправленный на харвестер во время рубки в “PinkForest_1380”
Рис. 82
Оператор спрашивает: обновить существующий объект или запустить новый объект?
Ответ: обновить существующий объект!
Шаг 5
Рубки на объекте "PinkForest_1380" продолжаются с обновленным продуктом "PineSaw” и новым продуктом" SpruceSaw”
Рис. 83
Компоновка системы харвестера
В зависимости от того, хотим ли мы иметь возможность обрабатывать все примеры, описанные выше, или нет, мы должны проектировать наши приемные системы в харвестере по-разному.
APT-файл заготовки
Вероятно, было бы достаточно иметь систему, идентичную нынешней, за исключением того, что она также может получать новые файлы, которые внутренне преобразуются в apt-структуру в случае использования apt-файла. Однако не так уж много получается. Большинство преимуществ с StanForD 2010 не будут использованы.
Рисунок 84
Заготовка APTERI
В случае сценария Apteri в харвестере необходима база данных для администрирования инструкций.
В случае Apteri данные отправляются из базы данных только при запуске на новом объекте рубок.
Рисунок 85
Гибкая вырубка
Как и в случае сценария Apteri, гибкий сценарий также нуждается в базе данных для администрирования инструкций.
В гибком случае данные могут быть отправлены из базы данных в любое время, а также во время заготовки на объекте.
Рисунок 86
Гибкая система может быть ручной и / или автоматической. Первый шаг-сделать систему ручной, что означает, что оператор вручную решает, когда импортировать новый или обновленный продукт (pin) из базы данных в приложение bucking(заготовки). То же самое относится к видовым группам (spi) и объектам (oin). Ручная гибкая система — это первый базовый уровень, который настоятельно рекомендуется внедрить. В автоматической системе обновленный или новый продукт будет автоматически импортирован в приложение bucking. В таблице ниже описаны четыре различных события, когда файлы pin и oin принимаются харвестером и добавляются в базу данных.
Файл полученГибкая-ручнаяГибкая-автоматическаяНовый oinИспользуется при запуске на новом объекте.Используется при запуске на новом объекте.
Новый pin
Используется мгновенно, если импортируется оператором вручную.Используется мгновенно, если ProductUserId включен в активный oin, автоматически импортируемый приложением bucking.Обновлено oinИспользуется мгновенно, если ObjUserId такой же, как в активном oin, вручную импортируется оператором.Используется мгновенно, если ObjUserId такой же, как в активном oin, автоматически импортируется приложением bucking.pinИспользуется мгновенно, вручную импортируется оператором.Используется мгновенно, если ProductUserId включен в активный oin, автоматически импортируемый приложением bucking.
Обратите внимание, что настоятельно рекомендуется, чтобы система харвестера была ручной гибкой системой. Включать автоматическую функциональность также необязательно.
Также обратите внимание, что оператор всегда должен иметь возможность редактировать продукты и группы пород во время производства, если атрибут modificationRestricted имеет значение false. ProductKey и SpeciesGroupKey должны быть обновлены, если изменяется продукт или группа пород.
Другие варианты использования
Контроль качества заготовки
Потоки данных, касающиеся контроля качества рубок в Швеции, в большинстве случаев можно проиллюстрировать на приведенной ниже диаграмме. Харвестер посылает случайно или оператором выбранные стволы к калибру. Оператор измеряет ствол и отправляет данные обратно в харвестер. Эти данные могут использоваться для калибровки машины или только для проверки машины. Некоторые дополнительные данные (журнал калибровки, отбракованные стволы и т. д.) добавляются в hqc-файл и впоследствии отправляются в лесозаготовительную организацию.
Рисунок 87
Однако существуют также системы контроля третьей стороной (аудитором), что делает потоки данных более сложными. В этом случае данные могут быть перенаправлены несколькими различными способами, как показано ниже (зеленые стрелки).
Рисунок 88
На основании приведенных выше диаграмм можно сделать вывод о необходимости решения следующих вопросов:
• Необходима прямая связь от калибра к лесозаготовительной организации / аудитору
• Данные контроля качества должны быть доступны для отправки от харвестера к калибру для аудитора.
* Производственные данные могут быть конфиденциальными, что означает, что они не должны передаваться аудитору
Вся передача данных, связанная с контролем качества рубки, будет осуществляться с использованием сообщения hqc.
Отчетность о вырубленной продукции (hpr)
Это имеет большое значение для осуществления StanForD 2010 что отчетность производственных данных:
• прост для операторов.
• не дает существенных различий между производителями.
* надежен (надежен, прост в проверке на отсутствие или дублирование данных)
Сначала предполагалось, что никакие производственные данные не должны передаваться более одного раза. Это можно было бы охарактеризовать как запрещение агрегированной отчетности. Однако найти подходящее решение для частичной отчетности не удалось. Все производители выразили очень четкое желание сохранить правила, касающиеся частичной отчетности, вне стандарта, включая любые элементы для порядка файлов или номера пакета.
Поскольку StanForD 2010 не содержит никаких правил, касающихся частичной отчетности, должна быть обеспечена возможность генерировать полное hpr-сообщение, включающее все стволы, собранные на объекте сбора урожая, с первым номером Stemn, равным 1, и последним StemNumber, который равен общему количеству стволов во всем файле. До тех пор, пока не будет найдено какое-то широко используемое решение для частичной отчетности, это, вероятно, будет рекомендуемым решением. Это надежное и простое решение для создания отчетов, генерирующих большие файлы. Преимущество такого способа отчетности заключается в том, что на самом деле не имеет значения, будет ли один отчет потерян во время лесозаготовок на объекте.
Рисунок 89. Иллюстрация альтернативы, где единственное требование заключается в том, что должна быть возможность сообщить об общем объеме производства.
Пример пяти hpr-файлов, отправленных с одного объекта лесозаготовки:
Рис. 90
Это просто проверить общее количество стволов, а также первый и последний номер ствола в каждом файле. Первый StemNumber должен быть равен 1, а последний StemNumber должен быть равен общему количеству стволов во всем полном hpr-файле. Основываясь на этой информации, мы легко можем определить, что это полный hpr-файл, включающий все собранные стволы.
Отчетность по данным производства и мониторинга должна быть простой:
• Всегда можно создать полный hpr-отчет, включающий все ранее сообщенные стволы (альтернатива по умолчанию)
• Возможна реализация частичной отчетности (правил не существует)
Рисунок 62 показывает две кнопки для создания hpr-сообщений и возможную настройку для автоматической генерации hpr-сообщений.
Рисунок 91. Пример графического интерфейса для генерации hpr-файлов
При генерации нового частичного hpr-сообщения можно сообщать только о стволах, обработанных с момента последнего отчета.
Рисунок 92. Пример, иллюстрирующий частичную отчетность hpr-файлов.
Можно создавать частичные отчеты по номеру ствола, по времени, по оператору,по размеру файла и т. д.
Всегда должна быть возможность сгенерировать полный итоговый hpr-отчет.
Рис. 93. Пример, иллюстрирующий общую отчетность по hpr-файлам.
Важнейший вопрос заключается в том, как извлечь данные из конкретного харвестера, если принимающая система обнаружила, что данные отсутствуют.
Если мы разрешаем агрегированные файлы и требуем, чтобы все производители могли генерировать полный hpr-файл, как описано выше, нам нужно только сказать оператору, чтобы он создал новый полный HPR-файл (проиллюстрированный в предыдущем разделе).
При необходимости принимающая система может создать уникальный идентификатор сообщения, объединив MachineKey и CreationDate. Это может быть, например, использовано, когда есть необходимость ссылаться на определенные hpr-файлы в papiNet MeasuringTicket.
Оперативный контроль
Ежедневные отчеты от харвестера, все время, охватываемое с момента последнего отчета.
Новый стандарт делает возможным отчет о перерыве во многих отношениях, например день, неделя, месяц, квартал, год.
Рассчитайте ключевые показатели, например в неделю
Рис. 94
Неделя 25? Взгляните на вторник!
Рис. 95. Иллюстрация временных линий, включенных в mom-файл.
Неделя 27? Средний объем ствола очень низкий!
Трелевка
Отчетность о переадресованной продукции ведется так же, как и в харвестере. Создание нового объекта в форвардере может быть выполнено на основе нескольких различных источников данных:
* инструкция, присланная из лесной компании
• данные о производстве харвестера
• ручной ввод оператора
Инструкция от лесной компании
На следующем рисунке показаны возможные информационные потоки в случае создания полной инструкции лесной компанией (офисом). Обратите внимание, что данные харвестера используются только для информирования форвардера о собранных объемах, а не для создания нового объекта.
Рисунок 96. Пример, иллюстрирующий информационные потоки форвардера, в которых объект запускается с использованием foi-и fdi-файлов.
Данные о производстве харвестера
На следующем рисунке показаны возможные информационные потоки в случае наличия только данных от харвестера. Обратите внимание, что оператор вручную должен определить/добавить определение доставки Delivery и местоположения LocationDefinition.
Рисунок 97. Пример, иллюстрирующий информационные потоки форвардера, где объект запускается с использованием производственных данных харвестера (hpr-файл).
Ручной ввод оператора
На следующем рисунке показаны возможные информационные потоки в случае отсутствия данных от харвестера или лесной компании (офиса). Обратите внимание, что оператор вручную должен добавить всю необходимую информацию вручную.
Рисунок 98. Пример, иллюстрирующий информационные потоки форвардера, в которых объект запускается с использованием информации, напечатанной на бумаге.
Взаимодействие оператора во время вырубки
Полностью автоматизированная система управления объектами сбора урожая и определениями продуктов сегодня, вероятно, невозможна. Поэтому оператор должен взаимодействовать с приложениями харвестера. Ниже приведен список ситуаций, в которых операторы должны взаимодействовать с этими приложениями.
* Уведомление о том, когда новый продукт должен заменить старый продукт:
- Оператор может принять или отклонить.
* Уведомление, когда новая инструкция объекта должна заменить старую
- Оператор может выбрать замену или новый объект рубок.
* Уведомление, если продукт в инструкции объекта отсутствует в харвестере
- Оператор может запросить у лесной компании правильное определение продукта
* Должна быть возможность:
- Обновление продукта и породной группы в любое время
- Вручную откройте/активируйте любую инструкцию в любое время
- Установите, будут ли все определения продукта (в сообщении pin) сообщаться параллельно нормальному производству
Вопросы
Подключение Продуктов и СпецГрупп к кнопкам
-- Как мы подключаем продукт к определенной кнопке?
Сегодня порядок сортиментов и видов часто используется при подключении определенного ассортимента к определенной кнопке в харвестере. С новым стандартом такого порядка не существует. Например, в StanForD 2010 мы можем смешивать продукты из разных пород любым способом, каким захотим. Этот вопрос был решен путем включения элементов:
*SpeciesGroupPresentationOrder: указывает порядок групп видов. Может использоваться в инструментах презентации для отображения видовых групп в определенном порядке, например, если сосна всегда должна быть представлена перед елью и березой в печатном отчете. Этот элемент следует рассматривать как необязательную подсказку, данную лесной компанией.
* Порядок представления продукта: указывает порядок продуктов для каждой видовой группы. Может использоваться в презентационных инструментах для того, чтобы показать продукцию в определенном порядке, например, если пиломатериалы всегда должны быть представлены перед балансовой древесиной и топливной древесиной в печатном отчете. Этот элемент следует рассматривать как необязательную подсказку, данную лесной компанией.
Отсутствующие определения продуктов ProductDefinitions и SpeciesGroupDefinitions
-- Примеры использования для отправки файлов oin, pin, spi. А что, если некоторые из них пропали? Что, если некоторые из них будут заменены?
Это проблема, которая, возможно, может возникнуть и в старой финской системе Apteri. Идея заключается в том, что оператор должен быть уведомлен, если какое-то определение отсутствует. Оператор должен иметь возможность начать работу на объекте, даже если конкретный продукт отсутствует. Обычная процедура, вероятно, будет заключаться в том, что оператор немедленно свяжется с лицом, ответственным за лесозаготовки, чтобы получить дальнейшие инструкции.
Замена определений ProductDefinitions и SpeciesGroupDefinitions
-- Примеры использования для отправки файлов oin, pin, spi. Что, если некоторые из них будут заменены?
Идея заключается в том, что оператор всегда должен быть уведомлен, когда старый продукт будет заменен новым. Кроме того, оператор должен иметь возможность отказаться от замены.
Определения в одном или нескольких сообщениях
-- Поступают ли продукты в машину в виде одного файла, или нескольких файлов, или в XML-конверте?
ProductDefinitions, SpeciesGroupDefinitions или DeliveryDefinitions могут быть отправлены по отдельности или объединены в один файл. Поэтому нет никакого существенного преимущества в использовании конверта, например, при отправке нескольких определений продукта вместе. Конверт будет использоваться в первую очередь для объединения всех соответствующих файлов для инструкции по географии лесозаготовок, включая ogi, shp, shx, mif, jpg, dbf, pdf и т. д.
Обновление Определений
-- Когда должно быть разрешено обновление продуктов?
В принципе, в любое время. Новый ключ продукта и ModificationDate должны быть установлены, если старый продукт заменен старым или если он каким-либо образом изменен.
История старых / замененных Определений
-- Какую "историю" следует вести об изменениях, внесенных в машину? Должно ли это быть отражено в производственных файлах?
Очень хороший вопрос! Минимум для сохранения данных, включенных в определение продукта в hpr-сообщении (ID, LengthDef, DiameterDef, PriceDaf), пока сохраняются производственные данные. Полное определение продукта -ProductDefinition, как определено в pin-сообщении, должно быть сохранено в машине до тех пор, пока продукт не будет заменен новым продуктом с тем же идентификатором пользователя UserId, но обновленным ключом продукта ProductDefinition
Продукты в GUI
-- Какова роль идентификаторов пользователей для оператора? Должны ли мы, например, иметь идентификаторы IDs, видимые в графическом интерфейсе GUI?
Я действительно не думал об этом, но я предполагаю, что самое важное, что нужно включить в графический интерфейс, - это ProductName, но во многих случаях ProductInfo, ProductVersion и ProductUserId также представляют интерес. То же самое справедливо и для породных групп.
Ограничить модификацию продукта
-- Можно ли лесным компаниям ограничивать модификации определений продукции и ProductDefinitions в харвестерах?
Да, это возможно с помощью атрибута modificationRestricted.
Определение важных понятий и ключевых фигур
StanForD 2010 должен включать рекомендуемые определения ключевых фигур и базовых понятий, например:
- Средний объем ствола должен включать также неклассифицированные объемы. Должно быть возможно сохранить различные категории обработки отдельно.
- Stem: нет никаких условий для регистрации stem в файлах StanForD2010, как это было в старой стандартной версии. Это означает, что stem может включать только небольшие неклассифицированные бревна и по-прежнему регистрироваться в hpr-файле.
- Объем (плотные м3): объем ствола всегда должен основываться на отфильтрованных значениях диаметра и физической длине. Минимальная длина модуля для расчета объема бревна составляет 1 дециметр, однако предполагается, что будут использоваться модули размером 1 сантиметр. Диаметры всегда должны представлять собой наименьший измеренный диаметр до этой точки (например, нет среднего значения на модуль дм). Систематическая разница между использованием формулы для цилиндра (средний диаметр или серединный диаметр) или срезаемого конуса не является существенной (<0,1%), поэтому можно использовать любую из этих формул.
Зарегистрированные диаметры, включая верхние диаметры: отфильтрованные значения (без увеличения значений) в позиции. Средние значения не допускаются. Аннотация для вектора диаметра является:
Диаметр на высотах, определяемых атрибутом diameterPosition (представляющим фактическую точку измерения). Относится к отфильтрованным значениям по коре. Те же значения, что и при оптимизации раскряжевки и расчетах плотных объемов. Отсутствие систематической ошибки при сравнении объемов данных и вычислений объема, основанные на DiamValue. Значения диаметра должны начинаться на высоте 0 см от пня. Экстраполированные диаметры на торце должны быть зарегистрированы. Высота первого и последнего измеренного диаметра регистрируется в DiameterMeasuredStart и DiameterMeasuredLas.t
- Функция звукового узла (Sound knot function)
- Распределение раскряжевки
– Обработка нескольких деревьев
Иные вопросы
* Потребности в безопасности? Контрольная сумма?
ТЕЛЕГРАМКанал с обзорами, анонсами новинок и книжными подборками
Книжный Вестник
Бот для удобного поиска книг (если не нашлось на сайте)
Поиск книг
Свежие любовные романы в удобных форматах
Любовные романы
Детективы и триллеры, все новинки
Детективы
Фантастика и фэнтези, все новинки
Фантастика
Отборные классические книги
Классика
ВКОНТАКТЕБиблиотека с любовными романами, которая наверняка придётся по вкусу женской части аудитории
Любовные романы
Библиотека с фантастикой и фэнтези, а также смежных жанров
Фантастика
Самые популярные книги в формате фб2
Топ фб2
книги