# Design and Application of Logical Range Framework Based on Digital Twin
## 3 Key Technologies  
### Proxy-Based Equipment Dynamic Extension Method  
The current Logical Range systems require the code of the system to be modified when expanding to new equipment. Moreover, the properties and functions of the new equipment cannot be predicted, and the code for them cannot be written during system development. If the system code is modified in order to add new equipment, the workload will be increased and, furthermore, the \"Open Close Principle\" of software design will be violated. Therefore, in order to improve the testing efficiency and realize the efficient use of test resources, it is necessary to realize dynamic expansion of the equipment. The proposed system introduces a proxy to solve this problem. The location of the proxy in the system is shown in Figure 2, between the equipment and the upper layer software. The equipment only needs to exchange data and receive instructions with the corresponding equipment proxy, without considering the various requirements of the upper software for the equipment. The proxy reduces the interference of upper software with the equipment, as well as reducing the other functions that the equipment needs to implement in order to be compatible with the upper system. As for the upper software, it only needs to communicate and interact with the equipment proxy, without considering the different communication protocols, data formats, and sampling frequencies of the various equipment. The data content, data format, and sampling frequency of different equipment may differ, even among different brands of the same equipment. The proxy should resolve these problems, thus achieving the goal of compatibility with different equipment, improving system compatibility, and enhancing test efficiency. Therefore, a base class _Root_ is designed, in order to specify the basic attributes and functions that all equipment should have. Its formal description is as follows:  
\[Root=\{equipmentID,equipmentType,dataAcquisition,dataTransmission,instructionParsing\}. \tag{3}\]  
It can be seen, from Equation (3), that every piece of equipment that accesses the system must have at least two _equipmentID_ and _equipmentType_ properties: _equipmentID_ is used to bind virtual and real equipment, while _equipmentType_ is used to mark the equipment type. In addition, it also needs to possess data acquisition, data transmission, and instruction parsing functions, where data acquisition means that the proxy needs to have the ability to obtain data from the equipment, data transmission means that the proxy needs to be able to send data to the upper application, and instruction parsing means that the proxy needs to parse the instructions from the upper application. The _Root_ specifies only the properties and functions that the proxy of the newly extended equipment must have. However, in fact, the properties and functions of the equipment far exceed those specified in _Root_. Therefore, the proxy needs to be extended, according to different equipment, on the basis of inheriting _Root_. The complete design and deployment process of the proxy is shown in Figure 3. Figure 3 illustrates the proxy development and usage process using IMU (Inertial Measurement Unit) and TSPI (Time Space Positioning Information) as examples. After inheriting _Root_, the proxy only has the properties and methods declared in _Root_, which cannot facilitate the compatibility of different equipment. It also needs to be expanded according to the functions of the equipment. After the proxy is expanded, it also needs to be filled with code, in order to further improve the proxy according to the specific functions of the equipment, such that it reflects all the functions of the equipment. The proxy that completes the code fill is generic for the same equipment. The proxy is then uploaded to the proxy management platform, which conducts unified management and configuration of all proxies through an interactive interface.