Изобретение касается электронной системы камер для посылок.
Электронные системы камер для посылок известны, например, из опубликованной предварительной заявки на патент Германии №10000830 А1, где раскрыт способ помещения товаров по меньшей мере в один запираемый шкаф. В системе камер для посылок, используемой в этом способе, имеется несколько камер для посылок, которые открываются и закрываются с помощью электронной запирающей системы. Несколько камер для посылок связывают с операционным блоком, выполненным в виде терминала и предназначенным для ввода или вывода данных. Запирающая система и операционные блоки связаны с компьютером, который управляет работой системы камер для посылок.
В этой заявке раскрыто также объединение компьютеров нескольких запирающих систем в сеть с формированием мультикомпьютерной системы, имеющей центральный управляющий компьютер. Центральный управляющий компьютер принадлежит, например, службе доставки, которая контролирует все перемещения товаров в камерах запираемого шкафа.
Целью изобретения является создание электронной системы камер для посылок, которая обеспечивает гибкую доставку посылок и их выемку из электронной системы камер для посылок.
Согласно настоящему изобретению, эта цель достигается в электронной системе камер для посылок, сконфигурированной таким образом, что она включает множество электронных камер для посылок, где несколько электронных камер для посылок связаны с соответствующим операционным блоком, и центральный блок управления для управления операционными блоками, при этом центральный блок управления имеет средство для гибкого связывания камер для посылок с операционными блоками.
Согласно настоящему изобретению, электронная система камер для посылок состоит из нескольких индивидуальных доставочных устройств, которые снабжены одним или несколькими операционными блоками. Работой некоторых или всех операционных блоков управляет центральный блок управления.
Предпочтительно, чтобы операционные блоки содержали средство управления открытием и/или закрытием камер для посылок, связанных с операционными блоками.
Отдельные электронные системы камер для посылок объединены вместе с формированием кластеров.
В частности, предпочтительно, чтобы центральный блок управления содержал средство для связывания камер для посылок с операционными блоками.
Преимущество варианта выполнения настоящего изобретения, в котором камеры для посылок и операционные блоки связываются друг с другом посредством центрального блока управления, состоит в том, что электронная система камер для посылок может быть легко адаптирована к изменившимся параметрам работы.
В частности, это удобно для обеспечения изменяемого связывания камер для посылок с операционными блоками.
При этом, например, если нарушается нормальная работа операционного блока, то камеры для посылок, которые до этого были связаны с этим операционным блоком, можно связать с другим операционным блоком.
В особенно предпочтительном варианте выполнения настоящего изобретения электронная система камер для посылок сконфигурирована так, что центральный блок управления имеет интерфейс для приема информации от сервера базы данных, в которой содержатся данные о заполнении камер.
Таким образом, электронная система камер для посылок может быть гибко адаптирована к ситуациям, возникающим в процессе работы, и к привычкам пользователя.
Например, если нарушается нормальная работа операционного блока, то камеры для посылок, которые были связаны с этим операционным блоком, можно связать с одним или несколькими другими операционными блоками. Это также улучшает возможность гибко приспосабливаться к потребностям или привычкам пользователей системы камер для посылок.
Особенно предпочтительные варианты выполнения настоящего изобретения допускают внутренний обмен информацией между центральным блоком управления и операционными блоками, а также внешний обмен информацией между центральным блоком управления и одним или несколькими серверами баз данных.
В предпочтительном варианте выполнения настоящего изобретения такой обмен информацией обеспечивается посредством того, что центральный блок управления имеет интерфейс для передачи информации в сервер базы данных, в котором хранятся данные о заполнении камер для посылок.
Повышение гибкости и универсальности электронной системы камер для посылок может быть достигнуто также за счет того, что центральный блок управления имеет компьютер, который может хранить и обрабатывать данные о работе и/или о состоянии заполнения камер для посылок.
Термин "компьютер" не следует понимать ограниченно. Он применим к любому блоку, который способен выполнять вычисления, например, к рабочей станции, персональному компьютеру, микрокомпьютеру или схеме, которая способна выполнять вычисления и/или сравнения.
Кроме того, предпочтительно оборудовать центральный блок управления дополнительными интерфейсами для проверки и/или изменения рабочих состояний. Это весьма облегчает обслуживание электронной системы камер для посылок.
Другим объектом изобретения является логистическая система, которая содержит несколько электронных систем камер для посылок, соединенных друг с другом сетью.
Такая логистическая система является особенно предпочтительной для достижения сформулированной выше цели, т.е. обеспечения гибкой доставки посылок и их выемки из камер для посылок.
Путем объединения в сеть нескольких электронных систем камер для посылок особенно легко обеспечить гибкую доставку почтовых отправлений.
Так, например, если все камеры для посылок в какой-либо электронной системе камер для посылок заняты, то можно переслать дополнительные почтовые отправления в другую электронную систему камер для посылок и хранить их там готовыми для выемки.
Благодаря включению в систему сервера базы данных, предпочтительно централизованного, почтовые грузы можно доставлять в электронные системы камер для посылок в зависимости от состояния заполнения такой электронной системы и/или камер для посылок, содержащихся в ней.
Дополнительные преимущества, особенности и практические усовершенствования изобретения вытекают из зависимых пунктов формулы и описания предпочтительных вариантов осуществления изобретения, представленного ниже со ссылками на сопровождающие чертежи.
На чертежах:
на фиг.1 показана структура интерфейса доставочной машины, который пригоден в качестве платформы обмена информацией с электронной системой камер для посылок;
на фиг.2 показана схема компонентов, используемых для регистрации пользователя, помощи пользователю и отслеживания доставки;
на фиг.3 показана схема вызовов функциональных процедур для реализации функций внутренних служб;
на фиг.4 показана схема интерфейсов, используемых для уведомления пользователя;
на фиг.5 А, В,С подробно показан вид интерфейсов, используемых для заполнения и администрирования камер для посылок;
на фиг.6 подробно показан вид интерфейсов, используемых для конфигурирования доставочных машин и использования емкости, и
на фиг.7 показаны этапы процесса, направленного на исправление ошибок.
В представленном ниже варианте выполнения настоящего изобретения электронная система камер для посылок интегрирована в комплексную логистическую систему.
Такая интеграция электронной системы камер для посылок в комплексную систему особенно предпочтительна, поскольку в этом случае гибкость, достигаемая путем выполнения электронных систем камер для посылок согласно настоящему изобретению, позволяет использовать их особенно эффективно.
Хотя использование систем камер для посылок в комплексной логистической системе в принципе особенно предпочтительно, электронные системы камер для посылок могут работать и без объединения в сеть. В таких вариантах выполнения настоящего изобретения введение центрального блока управления для управления операционными блоками также повышает гибкость использования электронных систем камер для посылок.
Однако возможности, обеспечиваемые изобретением, расширяются при объединении множества систем камер для посылок сетью друг с другом и/или с сервером базы данных, предпочтительно централизованным.
Когда несколько из этих предпочтительных компонентов объединены, в результате образуется комплексная система, имеющая следующие компоненты, которые ниже называются также "Почта 24", поскольку они позволяют обеспечить автоматизированную круглосуточную работу:
1) Множество блоков распределения посылок, причем предпочтительно, чтобы в каждом из них был по меньшей мере один операционный блок.
2) Центральный блок управления, с помощью которого отдельные доставочные машины объединяются сетью в кластеры и который контролирует рабочее состояние и функции доставочных машин. Центральный блок управления служит "концентратором" для посылочных транзакций, которые он направляет на сервер Почты 24. Кроме того, он передает инструкции сервера Почты 24 в машины для доставки посылок.
3) Сервер Почты 24, который управляет данными о клиентах и посылках, регистрирует процедуры доставочных машин и управляет ими, а также выполняет центральные программы (регистрация, CallCenter, Track&Trace и т.д.).
Система имеет модульную конструкцию. Определен стандартный интерфейс, который регулирует обмен информацией между доставочной машиной, CallCenter и сервером Почты 24. При этом можно использовать доставочные машины, изготовленные различными производителями.
Модульная конструкция отдельных систем камер для посылок особенно удобна с точки зрения повышения гибкости и универсальности отдельных электронных систем камер для посылок, а также комплексной логистической системы.
Предпочтительно, электронные системы камер для посылок, используемые в логистической системе, структурированы так, чтобы они выполняли функции и операции комплексной логистической системы наиболее эффективно.
В принципе, электронные системы камер для посылок могут быть реализованы в форме разнообразных технических решений.
Однако представленные ниже варианты выполнения электронных систем камер для посылок особенно предпочтительны ввиду их надежности и удобства для пользователей.
Одна из двух систем отличается тем, что каждая камера для посылок может быть закрыта индивидуальной дверцей. Другая, также предпочтительная, конфигурация системы камер для посылок отличается наличием циклического подъемника со специальными транспортными механизмами для отдельных посылок, предназначенными для размещения и изъятия отдельных посылок.
В этих вариантах выполнения настоящего изобретения доставочная машина позволяет загружать и вынимать посылки или содержимое из камер разных размеров. Особенно предпочтительной особенностью системы доставочных машин является то, что камеры для посылок только временно ассоциируются с определенными получателями, а именно, только тогда, когда камера содержит что-то для этого получателя. Для этого, прежде всего, потенциальный получатель должен быть известен системе доставочных машин, а во-вторых, доставкой следует управлять централизованно и так, чтобы она зависела от получателя.
Во время процедуры загрузки происходит обнаружение идентификационного кода посылки и идентификационного кода получателя. На основе идентификационного кода получателя соответствующий код доступа запрашивается у сервера Почты 24 (центральной системы). При получении посылки получатель идентифицирует себя своим личным идентификационным кодом получателя, например с использованием магнитной карты и секретного личного кода доступа. Если эта информация соответствует информации, хранящейся в доставочной машине, содержимое камеры становится доступным получателю.
Если посылка отправлена наложенным платежом или если при выдаче посылки необходимо получить от клиента некоторую денежную сумму, то сначала эта сумма отображается, и лицо, забирающее посылку, может заплатить эту сумму с помощью платежного терминала (посредством ЕС-карты, денежной карты и т.п.).
Посылки (или товары), которые возвращаются получателями, обнаруживаются доставочной машиной, о чем сообщается серверу Почты 24, который инициирует процедуру изъятия этой посылки соответствующим персоналом логистической компании.
Предпочтительно, центральный блок управления, который также называется панелью управления, обладает свойствами, перечисленными ниже.
Индивидуальные доставочные машины объединены в сеть с помощью этого центрального блока управления, который объединяет их в кластеры и осуществляет обмен информацией ("концентратор"). Центральным блоком управления контролируются сервисные и эксплуатационные задачи. Центральный блок управления распознает, готовы ли к работе доставочные машины или компоненты доставочной машины (операционный блок, принтер, индивидуальные камеры), и какие события, связанные с работой, происходят в различных доставочных машинах.
Сервер Почты 24 представляет собой информационный сервер, который связан сетью с помощью технических решений на базе Интернета с доставочными машинами или с панелью управления. Сервер Почты 24 является интерфейсом к дополнительным приложениям базы данных. Эти приложения базы данных позволяют, например, ввести функции выставления счетов и отслеживания перевозок.
Доставочная машина предпочтительно используется только получателями, которые предварительно подписали с Deutsche Post договор на такое обслуживание и чьи данные хранятся в сервере Почты 24. Получатели, которые зарегистрированы таким образом, получают идентификационный код получателя, который они используют в качестве части своей адресной информации; кроме того, они получают личный секретный код доступа.
Когда происходит доставка в доставочную машину, получатель автоматически уведомляется об этом сервером Почты 24. Уведомление предпочтительно осуществляется электронным путем, например путем посылки SMS-сообщения или по электронной почте. Однако можно также автоматически напечатать письмо и послать его получателю. Получатель после этого может забрать посылку из доставочной машины в удобное для него время. Если этого не произойдет в течение определенного времени, то высылается напоминание, а когда период доставки истечет, посылку готовят к возврату отправителю.
Система получения посылок подходит для различных областей применения. С одной стороны, эта система доставочных машин может доставлять обычные посылки конечным потребителям, а с другой стороны, она может также удовлетворить специальным запросам деловых клиентов.
Так, фиксированная или изменяемая часть камер для посылок в доставочных машинах может быть арендована деловыми партнерами и клиентами логистической компании, эксплуатирующей систему, чтобы в результате эти клиенты также могли пользоваться системой. Таким образом, для таких клиентов система доставочных машин является централизованным складом, при этом запасом товаров и их передвижением на этом складе можно управлять централизованно, с соответствующим выставлением счетов.
В частности, данная система строится из централизованных и децентрализованных компонентов с целью создания интеллектуальной системы заказа и доставки по требованию.
Система включает различные компоненты и интерфейсы, которые позволяют эффективно и гибко сформировать логистическую систему с такими возможностями доставки и обслуживания, которые до сегодняшнего дня отсутствовали.
Примеры функций, которые интегрированы в систему:
- управление данными о посылках,
- управление данными о пользователях,
- регистрация клиентов,
- управление партнерами по бизнесу,
- отслеживание посылок,
- управление конфигурацией доставочных машин,
- возможность планирования,
- уведомление,
- статистическая оценка данных,
- интерфейс доставочных машин,
- внутренняя служба.
Предпочтительно различать базовые компоненты управления и доступа к данным о посылках и пользователях и вторичные компоненты, которые отображают бизнес-процессы 4 в систему.
Модульная структура системы допускает независимое постепенное развитие различных услуг.
Поскольку особенно предпочтительный вариант выполнения системы и ее компонентов согласно настоящему изобретению основан на реализации технологии EJB (Enterprise JavaBeans), базовые компоненты отображаются на EJB посылок и EJB пользователей. Все другие компоненты, когда они должны запросить или изменить данные клиента и посылки, взаимодействуют с этими EJB-компонентами.
Вторичные компоненты являются, частично, сложными частичными системами, которые состоят из классов, EJB-компонентов и графических интерфейсов пользователя (GUI). Для осуществления взаимодействия между этими компонентами, которое не зависит от конструкции компонента, каждый компонент обеспечивает собственный интерфейс связывания с его службами в виде фасадного объекта, или EJB. Интерфейсы различных компонентов описаны ниже.
Интерфейс доставочных машин
Интерфейс доставочных машин представляет собой платформу взаимодействия с доставочными машинами. Интерфейс получает запросы от доставочной машины и перенаправляет их в подходящие компоненты. Если доставочная машина ожидает данные в ответ на свой запрос, то эти данные возвращаются компонентами в интерфейс, а затем перенаправляются в доставочную машину.
На фиг.1 показана структура компонентов. Синтаксический анализатор языка XML осуществляет преобразование XML файлов, которые посылаются посредством HTTP, в вызовы функциональных процедур, которые могут быть интерпретированы логистической системой класса Machine Interface (Машинный Интерфейс), оценивает вызовы функциональных процедур и перенаправляет их подходящим компонентам, а именно, компонентам User (Пользователь), Parcel (Посылка), DeliveryMachine (Доставочная Машина) и Notification (Уведомление).
Предпочтительно, компоненты User Registration (Регистрация Пользователя), В2В Partner Management (Управление Партнерами по Бизнесу) и Parcel Tracking (Отслеживание Посылки) инкапсулированы в фасад CallCenter. Фасад осуществляет взаимодействие с EJB-компонентами для управления данными о пользователях и посылках, то есть User и Parcel. Этот компонент делает доступными сетевые графические интерфейсы пользователя для регистрации и отслеживания посылок. Они закодированы в JSP. Действия пользователей преобразуются посредством бина WorkerBean в вызовы функциональных процедур и направляются в фасад CallCenter. Предпочтительно, фасад CallCenter только теперь берет на себя роль логической схемы для решения коммерческих задач. Схема, представленная на фиг.2, дает общее представление об этом сценарии.
Компонент In-House Service (Внутренняя Служба) инкапсулирует услуги, предоставляемые логистической системой для внутреннего обслуживания в базах доставки. В интерфейсе для работников внутренней службы имеется JSP, который реализует графический интерфейс пользователя. Действия внутренних сотрудников преобразуются с помощью бина WorkerBean в вызовы функциональных процедур и направляются в фасад внутренней службы. Таким образом, фасад внутренней службы формирует интерфейс для фактической функциональной логической схемы компонента.
Кроме того, фасад внутренней службы формирует интерфейс связи с другими компонентами системы.
Для отображения требуемой функциональной логической схемы этому компоненту нужен доступ к основным компонентам, а именно к компонентам User и DeliveryMachine.
Структура компонента показана на фиг.3.
Другим компонентом, который благодаря модульной структуре логистической системы может быть установлен без каких-либо проблем и который улучшает логистическую систему и используемые в ней компоненты, особенно систему камер для посылок, является компонент уведомления.
Компонент уведомления выполняет посылку сообщений пользователю логистической системы. Этот компонент предпочтительно решает две задачи. Он отображает режим уведомления логистических партнеров и осуществляет техническую передачу сообщений в устройства клиентов.
Интерфейс к другим компонентам системы обеспечивается фасадным классом NotificationFacade. Этот класс предоставляет многочисленные методы, которые служат для информирования компонента о событиях, способных привести к посылке уведомления пользователю. В настоящее время такие события запускает компонент интерфейса в ответ на действия в доставочной машине и на компонент регистрации. Чтобы быть способным сформировать цель и содержание сообщения, компонент должен иметь доступ к адресным данным получателя сообщения. В этом особенно предпочтительном варианте выполнения логистической системы все получатели сообщений должны, таким образом, сделать доступным интерфейс Notifiable (Подлежащий Регистрации). Таковы, например, EJB-компоненты LogisticPartnerClient, User и LogisticPartners.
Организация данных пользователей и посылок может быть выполнена разнообразными способами. Ниже описана система администрирования пользователей и посылок в форме объектно-ориентированной модели, использование которой особенно предпочтительно.
Центральным объектом в объектной модели администрирования пользователей является объект EntityBean UserEJB. В этом объекте хранятся все данные о персонах, которым разрешено работать на доставочной машине. Конечные потребители, а также доставщики и обслуживающий персонал классифицируются как пользователи. Комплексная объектная модель (персона, как базовый класс, производные классы для различных ролей персон) не используется.
Это приводит к предпочтительному варианту выполнения настоящего изобретения, а именно использованию роли пользователя в объекте в качестве атрибута. Роль задается как int (целое). В классе Const задаются выразительные имена переменных, например:
Кроме того, объект пользователя должен иметь ссылку на связанные с ним LogisticPartners (Логистические Партнеры) или LogisticPartnerClient (Клиенты Логистических Партнеров). Например, LogisticPartners могут быть поставщиком почтовых услуг, который управляет логистической системой, или другими компаниями, которые имеют доступ к компонентам логистической системы, включая загрузку камер для посылок. LogisticPartnerClients - это клиенты Логистического Партнера, например Telekom является клиентом Danzas.
В зависимости от роли пользователя, объект получает ссылку на LogisticPartner (ROLE_B2B_DELIVERY_AGENT) или на LogisticPartnerClient (ROLE_B2B_RECIPIENT). В каждом случае другая ссылка остается пустой (Недопустимо, чтобы были заполнены обе ссылки в одно и то же время, так как лицо или доставляет груз, или его получает, но не делает и то и другое вместе).
Объект UserGroupEJB (аналогично EntityBean) позволяет объединять нескольких пользователей в одну группу. В дополнение к списку пользователей, UserGroup имеет ссылку на LogisticPartner или на LogisticPartnerClient, которому принадлежат все члены групп. Дублирующее хранение этой ссылки в User и в UserGroup упрощает доступ к информации в LogisticPartner(Client).
Поскольку посылки могут быть направлены обоим типам (User и UserGroup), эти два объекта образуют Interface Addressable (Адресуемый Интерфейс). Этот интерфейс имеет следующие методы: getUsers(), getDD() и getExpiryMinutes(). Это гарантирует, что посылки, которые высланы в адресуемый интерфейс, могут быть обработаны сервером.
Метод getUsers() выдает список пользовательских EJB. Если это UserGroup, то список содержит несколько EJB, а если User, то только один EJB.
Метод getlD() возвращает ID (идентификатор) для User или UserGroup. Поскольку адресуемый интерфейс должен быть способен храниться постоянно, подчиненный объект может быть найден через этот идентификатор. Это приводит к запросу взять идентификаторы для User и UserGroup из набора чисел. Кроме того, у объекта Post24ServerProperties (Свойства Сервера Почты 24) есть метод newUserlD() ("Идентификатор нового Пользователя"). Он возвращает однозначный постоянный идентификатор. Внутренне этот метод обращается к приложению базы данных, в частности Oracle.
Метод getExpiryMinutes() в адресуемом интерфейсе необходим для определения ExpiryDate (даты окончания хранения) посылки. Допустимое время хранения посылки зависит от клиента. Для вычисления ExpiryDate метод getExpiryMinutes() в обоих объектах User и UserGroup обращается к методу LogisticPartnerClient.getExpiryMinutes() и добавляет это допустимое время хранения к текущему моменту времени.
Компоненты User и UserGroup создаются при регистрации или административными средствами.
Для администрирования посылок создается EntityBean Parcel. ParcelID назначается доставочной машиной, и сервер уведомляется через интерфейс с помощью notifyDelivery(). Затем фасад доставочных машин создает новый объект Parcel Object с идентификатором ParcelID в качестве первичного ключа.
Получатель (переданный в виде номера клиента) хранится как адресуемый. Кроме получателя, имеется атрибут замены также адресуемого типа. Это не может быть установлено в notifyDelivery(), а только в более позднее время путем вызова метода substituteBy (адресуемый Addressable). С помощью этого атрибута отображают конфигурацию замены. Объект Parcel Object предоставляет методы getRecipients() и getSubstitutes(), каждый из которых возвращает список объектов User Objects.
При создании нового объекта Parcel Object, например посредством применения метода notifyDelivery() к интерфейсу доставочной машины, рассчитывается ExpiryDate с использованием вышеупомянутого метода, и в объект Parcel Object посылается уведомление. Таким образом, метод создания содержит ExpiryDate. Каждый LogisticPartner может иметь различные правила расчета значения ExpiryDate.
В случае отправки посылок наложенным платежом создается объект COD, в то время как компоненты для пакетов и посылок без наложенного платежа формируются методом создания без COD. В случае посылок, идентификационный код IdentCode посылки передается методу создания.
Кроме того, объект Parcel Object информируется о том, какому логистическому партнеру LogisticPartner он принадлежит. Эта информация необходима для планирования емкости.
Предыстория хранится с помощью базы данных с использованием триггера, который перед изменением записи посылает запись со старыми данными в архивную таблицу. Метод getHistory() (получить Предысторию) обеспечивает выдачу листинга состояния всех записей архива.
Конфигурация доставочной машины и управление емкостью предпочтительно также интегрированы в логистическую систему как модульные компоненты.
Доставочные машины системы Почта 24 делают доступным фиксированное количество камер хранения различных размеров. Камеры используются различными логистическими компаниями. Так как распределение камер доставочных машин между логистическими компаниями должно быть известно для обработки посылок и расчета стоимости услуг, конфигурациями доставочных машин управляют в EJB DeliveryMachine (Доставочная Машина). Этот EJB обеспечивает установку и выдачу запроса о конфигурации камер каждой доставочной машины, а также расчет текущего и будущего заполнения камер посылками.
Фактическая конфигурация камер, то есть количество камер, арендованных логистическим партнером, разбитое по размерам камер, представлена двумя EJB-компонентами: BoxTypeAssignment (Назначение Типа Камеры) и ВохТуре (Тип Камеры). DeliveryMachine распределяет каждому логистическому партнеру некоторое количество EJB-компонентов BoxTypeAssignment, а именно, один для каждого размера арендованной камеры. Каждый BoxTypeAssignment хранит тип и номер арендованных камер. Размер камеры хранится в ее собственном EJB с именем ВохТуре.
Вследствие модульной структуры используемой системы камер для посылок, а также логистической системы дополнительные компоненты можно интегрировать в любой момент времени. Например, можно предусмотреть дополнительные компоненты для функций оценки. Примерами возможностей оценки данных является оценка данных о посылках и данных о клиентах для статистических целей.
Протоколирование (ведение журнала) предпочтительно, особенно для проверки надлежащего функционирования.
Классы протоколирования, предоставляемые сервером приложений, используются для регистрации произошедших ошибок. Они инкапсулируются для повышения удобства системы.
Класс de.Post24.util.P24Log обеспечивает метод протоколирования статистики:
public static void log (int severity,
java. lang. String system,
Java.lang.String msg,
java.lang.Throwable t)
Значения здесь следующие:
severity - серьезность ошибки. Различают четыре класса ошибок, которые можно вызвать через константы внутри класса P24Log: P24Log.debug, P24Log.info, P24Log.warning, P24Log.error,
system - имя частичной системы,
msg - текст ошибки, который нужно сохранить,
t - исключение.
Возможны также более простые, "усеченные", версии этого метода, предпочтительно формируемые путем замены некоторых параметров заранее заданными значениями, например:
severity - Р24 Log. debug
system - имя частичной системы,
t - не используется.
При использовании вышеописанных технических подходов параметры конфигурации можно адаптировать быстро и с высокой степенью надежности.
Специалист в данной области техники может изменить описанные варианты выполнения путем использовании функциональных возможностей других языков программирования и программируемых функций.
В предпочтительном языке программирования Java также можно использовать другие функциональные возможности по сравнению с вышеописанными.
В частности, для специалиста в данной области техники будет предпочтительно использовать операции, известные из других документов
http://java.sun.com/docs/codeconv/
Java Coding Conventions
для реализации дополнительных функций и для изменения и улучшения используемых функций.
Изобретение касается электронной системы камер для посылок и логистической системы. При его использования достигается технический результат в виде повышения надежности и обеспечения возможности назначать разные операционные блоки разным клиентам (камерам). Система содержит множество электронных камер для посылок и операционные блоки, причем несколько камер для посылок связаны с соответствующим операционным блоком, содержащим средство управления открытием и/или закрытием камер для посылок, связанных с этим операционным блоком. Технический результат достигается благодаря тому, что она снабжена центральным блоком управления для управления операционными блоками, при этом центральный блок управления имеет компьютер, способный хранить и обрабатывать данные о работе и/или о состоянии заполнения камер для посылок, и способен обмениваться информацией с операционными блоками для гибкого связывания камер для посылок с операционными блоками. 2 н. и 1 з.п. ф-лы. 10 ил.
| US 5475378 А, 12.12.1995 | |||
| WO 00/51570 A1, 08.09.2000 | |||
| Устройство управления переключением резерва | 1988 |
|
SU1617675A1 |
| DE 10000830 A1, 26.07.2001 | |||
| RU 2058591 C1, 20.04.1996 | |||
| Способ реиннервации нижнелуночкового нерва при резекции нижней челюсти | 2019 |
|
RU2713461C1 |
| Печь для непрерывного получения сернистого натрия | 1921 |
|
SU1A1 |
