LT8RFID weighing system

NegotiableUpdate on 11/26

Model

Nature of the Manufacturer: Producers

Product Category

Place of Origin

Online Consult

Overview

LT8RFID weighing system wireless radio frequency identification (RFID weighing system) technology is a fast, real-time, and accurate weighing information collection and processing technology, which uniquely and effectively identifies physical objects through radio frequency signals. It can be widely used in various industries such as production, retail, logistics, transportation, medical care, national defense, animal husbandry, mining, etc

Product Details

LT8RFID weighing system

Wireless Radio Frequency Identification (RFID) weighing system technology is a fast, real-time, and accurate weighing information collection and processing technology that uniquely and effectively identifies physical objects through RF signals. It can be widely used in various industries such as production, retail, logistics, transportation, healthcare, national defense, animal husbandry, mining, etc. The basic RFID weighing system generally consists of three parts: tags, readers, and application support software. Middleware is an important component of application support software, serving as a bridge between hardware weighing devices such as tags and readers, and enterprise application software such as Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM). The main task of middleware is to filter, summarize, calculate, and group tag related data transmitted from readers, reducing the large amount of raw data transmitted from readers to enterprise applications and generating event data with semantic interpretation added. It can be said that middleware is the "nerve center" of the RFID weighing system. There are many issues to consider in the design of RFID weighing system middleware, such as how to implement various quality attributes of software, how to isolate middleware from hardware weighing devices, how to handle the relationship with device management functions, how to achieve high-performance data processing, and so on.
1. The network framework structure of the RFID weighing system, where tag data is grouped, filtered, and reported to the application system through middleware processing; The application system is responsible for the persistent storage of event data and the management of business information bound to tags. The RFID weighing system system shared public service platform provides public services such as root node object name service (ONS), enterprise application authentication management, tag information discovery, and enterprise authorization code management. Among them, the root node ONS, together with the internal ONS of all enterprise level RFID weighing systems, forms an ONS tree. Any tag can find the address of the tag information database corresponding to the tag on the ONS tree, which can further access the detailed information corresponding to the tag.
2. In short, the function and implementation principle of middleware is to accept requests from application systems, initiate operation commands such as tag counting, tag identification data writing, tag user data area reading and writing, tag data locking, tag killing, etc. for one or more specified readers, and receive, process, and report the result data to the backend application system. Among them, tag counting is the most basic and widely used function.
2.1 Overview of Label Counting Function. The workflow of label counting can be simply described as follows: the application system defines the requirements for label data in the form of rules, which are proposed by the application system to the middleware and maintained by the middleware. The rules define: which readers' inventory data is required, the start and end conditions of the tag data reporting cycle (event cycle), how to filter tag data, how to group tag data, whether the reported data is original inventory data, newly added tag data, or newly removed tag data, and what original data is included in the tag data. The application system specifies a rule and requests the middleware to subscribe to the label data. Middleware initiates event cycles in a timely manner based on the reservation status of tag data by the application system, and issues tag inventory commands to the reader. The reader sends the data counted during a certain period of time (reading cycle) to the middleware. The reading cycle can be determined through private negotiation between the middleware and the reader. The middleware receives data reported by the reader. Middleware performs filtering, grouping, accumulation, and other operations on received data according to the definition of rules. At the end of the event cycle, it generates a data result report according to the requirements of the rules and sends it to the subscribers of the rules. The filtering process can remove duplicate data and data that the application system is not interested in, greatly reducing the amount of data transmitted between components.
I need to explain the concept of a logical reader. Middleware abstracts event sources into a logical concept - a logical reader, which can contain multiple physical readers and even be further refined into multiple antennas containing multiple physical readers. The division of logical readers can be determined based on the actual system deployment situation. For example, if a warehouse has four readers deployed at two exits, these four readers can be configured as one logical reader as needed, which can be named "Warehouse Exit". When the application system needs label data for warehouse export, it can issue inventory commands based on this logical reader, and the name of the logical reader is used as a parameter for some application programming interface (API) calls.
2.2 The implementation principle of tag counting is as mentioned earlier, and rules are the key elements of the entire middleware function. The rules are equivalent to the purchase orders sent by the application system to the middleware, defining the requirements for the time (event cycle) and specifications (how to filter, group, report style, etc.) of the goods (label data). The principle description section refers to the relevant content of EPCglobal. Rules and reports have their own information models that represent the information they carry, while rules have their own state machine models. When accepting long-term or single bookings from application systems, these booking operations will trigger state transitions of rules, such as transitioning from the "not requested" state to the "requested" state. Rules are defined by the application system through APIs.
(1) The rule information model is described using the Unified Modeling Language (UML), as shown in Figure 3. In the context of object-oriented programming, rules can be represented as a class (ECSpec). From the description of the information model, it can be seen that a rule class has an association relationship with multiple other classes, or in other words, possesses the following attributes: a list of one or more logical readers (readers), event cycle boundaries definitions (boundaries), definitions of one or more reports (reportSpecs), and a tag indicating whether the rule itself is included in the report (including SpecInReports).
(2) The report information model is similar to the rule information model, in which the ECReports class has the following attributes: rule name (specName), time reporting time (date), event cycle duration (total milliseconds), event cycle end condition (termanonCondition), rule definition class instance (spec), and a list of one or more instances of the report class (reports). The ECReport category contains specific label data information.
(3) The tag inventory API application system sends definition rules, reservation data, and other requests, which are completed by calling the API provided by the middleware. The API calling process can be implemented using specific technologies such as Java RMI and SOAP, with the most important APIs listed in Table 1. Table 1: Label Inventory Application Programming Interface. The poll operation is equivalent to the unsubscribe operation after the subscribe operation receives the data of an event cycle; The immediate operation is equivalent to defining the rule, calling the poll operation, and then calling the undefine operation.
(4) The rule state machine model rules, starting from their definition, may exist in three states: Unrequired, Requested, and Activated. After the rule is created, it has not been subscribed by any client (i.e. application system), and the rule is in the Unrequired state; The first booking action on the rule will cause the rule to transition to the Requested state; When the conditions for the start of the event cycle are met, the rule enters the Active state; When the condition for the end of the event cycle is met, if there are subscribers in the rule, it transitions to the Requested state; otherwise, it transitions to the Unrequired state.
3. Middleware system architecture: As a software system (or component), in addition to meeting certain functional and performance requirements, quality attributes such as comprehensibility, scalability, modifiability (or reconfigurability), insertability, and reusability will be proposed as requirements for software design. In the past decade, object-oriented thinking has almost completely occupied the field of software design, becoming the most mainstream analysis and design method. In recent years, research on design patterns has become increasingly sophisticated, and patterns have almost become a "higher-level programming language" (compared to high-level programming languages such as Java and C++) that is widely used. The object-oriented thinking and design patterns are both responsible for achieving the goals of software comprehensibility, extensibility, modifiability, insertability, reusability, etc. This article will also apply the object-oriented thinking and reference pattern language to make a preliminary exploration of the software architecture of middleware. If the examples in the following text involve high-level programming languages, Java language will be used.
3.1 Encapsulation and Isolation Processing Flow: Each node in the middleware's business process is divided into different modules for processing, which can achieve advantages such as encapsulation, high cohesion, and low coupling, as shown in Figure 5. Figure 5: Module division diagram of middleware system. Among them, the report upload module is responsible for implementing different types of report upload methods, such as HTTP, JMS, etc; API interface module, responsible for isolating the application system from the middleware core business logic processing module, and providing middleware API interfaces to the application system; The middleware core business logic processing module is responsible for middleware core business, including data receiving and filtering, data grouping, report generation, and status jumping of rule objects; The reader communication module is responsible for the communication between the middleware system and the reader.
3.2 Facade mode and factory mode expose API interfaces to the outside. In order to avoid excessive coupling of backend application systems, i.e. middleware clients, Facade mode is used to achieve clear isolation between the internal and external of the system. The processing flow can be seen in the sequence diagram shown in Figure 6. The client only establishes a connection with the Facade class. If the Facade interface is defined clearly enough, the client can be unaware of the internal implementation of the middleware, which reflects the encapsulation in object-oriented programming.
3.5 Observer Mode Processing: The message reporting of the message reader is converted into message objects, and the reception and distribution of message objects can be implemented using the classic observer mode.