1. Development and Application of Simulation Technology in China's Power System In the early 1980s, the first large-scale thermal power unit simulator was successfully developed in China. In 1988, the Ministry of Energy issued a "Notice on the Development of Thermal Power Unit Simulation Training Devices," after which power system simulation technology developed rapidly, leading to the emergence of numerous simulation companies and research centers. In 1990, the Department of Electrical Engineering at Tsinghua University completed the first power grid simulation system in China, namely the Northeast Power Grid Simulation System. In 1993, the Plant Simulation Laboratory of the Department of Electrical Engineering at Tsinghua University completed the first hydropower plant simulator in China, namely the Fengman Hydropower Plant simulator in Jilin Province. By 1999, most provincial power grids had adopted substation simulators, thermal power simulators, and power grid dispatch simulators. [b]2. Advantages of Distributed Interactive Simulation Technology[/b] Distributed Interactive Simulation (DIS) is a simulation technology developed from the US SIMNET project. It connects simulation applications in different geographical locations to create a realistic and complex virtual world for highly interactive simulations and allows interoperability between various simulation applications. The following principles should be followed when designing a DIS system: (1) Object/Event Structure: Objects interact through a series of events. (2) Autonomy of Simulation Nodes: All events are broadcast through the simulation network. The principle of autonomy allows simulation nodes to dynamically join and leave the simulation without affecting the interaction of other nodes. (3) Transmission of Real Information: The real-time state of each simulation object is accurately transmitted. (4) Transmission of State Change Information: Only state change information is transmitted to reduce unnecessary data transmission and communication processing tasks. (5) Pre-estimation method and simulation time constraints are used to reduce the network transmission load. In recent years, with the rapid development of computer technology, simulation technology has been increasingly widely applied in various fields, enabling PCs in the traditional sense to complete tasks that were previously only possible for workstations. Since PCs are much cheaper than workstations, how to make full use of PC resources to complete tasks that were traditionally done by workstations, thereby achieving a better performance-price ratio, is a new problem facing simulation technology. Distributed interactive simulation technology can make full use of computer resources, thereby solving the problem. Simulation technology has also developed from single-machine simulation to multi-machine simulation. A substation simulator mainly consists of an instructor station, a student station, a computing station, and lower-level machines. A single-machine-based substation simulator primarily uses a high-performance workstation running an operating system such as VMS or UNIX. The workstation host runs the instructor station and computing station, and is responsible for network communication tasks with the lower-level machines; therefore, its computing and network communication load is heavy. The student station runs on the Xterm of the workstation host, so the entire simulator can be considered to run on a single machine, as shown in Figure 1. [img=311,135]http://zszl.cepee.com/cepee_kjlw_pic/files/wx/dwjs/2000-9/50-1.jpg[/img] A multi-machine-based distributed interactive substation simulator typically runs the instructor station on one high-performance microcomputer, the computing station on another, and the student stations on the remaining microcomputers, as shown in Figure 2. [img=297,192]http://zszl.cepee.com/cepee_kjlw_pic/files/wx/dwjs/2000-9/50-2.jpg[/img] In multi-machine operation mode, the instructor station and the computing station run on different microcomputers. The computing station is responsible for calculating the changes in voltage, active power, reactive power, and protection actions in each simulation cycle, and then broadcasting the calculated values ​​to the lower-level machines, instructor station, and student station via the network, regardless of whether they need the data. As shown in Figure 2, the network communication between the entire simulator is achieved through broadcasting. In this mode, the computing station, student station, instructor station, and lower-level machines all send data to the network, while the receiving end can only passively receive the data and determine the content it is interested in. Therefore, the entire simulator operation is filled with a large amount of redundant data on the network, the network communication is disordered, and the load is relatively heavy. [b]3 Distributed Substation Simulator Based on High-Level Architecture (HLA)[/b] 3.1 Shortcomings of Traditional DIS Simulation Mode (1) Broadcast-based communication method with a large amount of redundant information The network communication of DIS adopts a broadcast method. This communication mechanism cannot guarantee the error-free transmission of communication data. The broadcast method is oriented towards the entire network. Each node broadcasts its own status information to other nodes on the network, and other nodes receive this information indiscriminately. With the expansion of simulation applications and the increase of simulation nodes, a large amount of information must be transmitted on the network. However, the amount of information that each simulation node must receive is not much. (2) Non-reusable simulation support function The simulation application and simulation support function (network communication) in DIS are integrated together. Developers must spend a lot of time and effort to develop the simulation support function. However, the network communication functions of different simulation applications are not reusable, which means that the network communication function is repeatedly developed. Therefore, how to develop a general simulation support function and improve simulation efficiency has become an urgent problem to be solved. (3) Inability to meet the real-time requirements of simulation applications In substation simulators using dynamic mathematical models, the simulation step size has been shortened to 0.02s. With the expansion of the simulation application scope (if users require simultaneous simulation of regional power grids), the traditional DIS simulation mode is difficult to meet the real-time requirements of simulation. 3.2 High-level architecture In August 1996, the U.S. Defense Modeling and Simulation Office formulated the HLA technical framework. HLA mainly consists of three parts [1-3]: (1) Federation Rules (RULES) (2) Object Model Template (OMT) (3) Run Time Infrastructure (RTI) In the HLA system, a distributed system that achieves a specific simulation purpose is called a federation. The federation consists of simulation applications, RTI, and federation object models, while RTI plays a role in supporting various simulation applications. In HLA, an object model is a collection of objects that describe objective things. The object model describes the attributes, relationships, and interactions of these objects. The object model in HLA includes two types: Federation Object Model (FOM), which describes the information shared by members during federation execution; and Simulation Object Model (SOM), which describes the capabilities provided by members when participating in the federation. HLA specifies a unified table OMT to standardize the description of the object model. OMT provides a commonly understood mechanism to describe the exchange of member data. There are 10 federation rules: (1) There must be a Federation Object Model (FOM) to record the protocols and conditions for members to exchange data at runtime; (2) All objects in the FOM belong to their respective members, not in the RTI, separating simulation applications from general support services; (3) All data exchange must be through the RTI to maintain the consistency of federated data exchange; (4) The interaction between members and the RTI follows the RTI interface specification. The standardized interface makes it unnecessary to consider the implementation of the RTI when developing simulation applications; (5) The attributes of an object can only be owned by one member at any given time to ensure the consistency of federated member data. HLA provides a mechanism to dynamically transfer attributes from one member to another; (6) It must have a Member Object Model (SOM) that fully describes the basic capabilities that members can provide to the outside world; (7) It must be able to update and use the attributes of internal objects and send and receive interactions with objects; (8) It must be able to migrate and accept the right to use attributes according to the SOM; (9) It must be able to change the conditions under which attributes are published; (10) It must be able to manage local time so as to ensure that it can coordinate the exchange of data with other members in the federation. HLA's RTI provides various services to handle interoperability between federated runtime members and manage federated operations: (1) Federation Management Service (FM): Provides services such as creating, deleting, joining, and leaving federated operations; (2) Declaration Management Service (DM): Members can order the attribute values ​​they need and publish the attribute values ​​they can provide to other members; (3) Object Management Service (OM): Provides members with the ability to create and delete objects and transfer attribute values ​​during federated operations; (4) Ownership Management Service (OWM): Provides services for the transfer and acceptance of attribute ownership among members; (5) Time Management Service (TM): Used to control the progression of federated simulation time; (6) Data Management Service (DDM): Provides management of the data space and data distribution services. Compared to the DIS model, the HLA model separates the simulation application and the runtime support system environment by introducing the RTI runtime support system. This effectively solves the problem of reusability of runtime support in simulation and reduces a large amount of redundant data on the network. Its principle is shown in Figure 3. [img=256,186]http://zszl.cepee.com/cepee_kjlw_pic/files/wx/dwjs/2000-9/51-1.jpg[/img] In HLA, interaction between various simulation applications is conducted through interfaces provided by HLA. Each simulation application declares to the RTI the data it can "publish" and "order." During simulator runtime, the RTI runtime support system determines network connectivity and data transmission/reception. Individual simulation applications are not concerned with network data transmission, but only with the data they are interested in. Furthermore, the RTI supports both connection-oriented and connectionless communication methods. Connection-oriented communication is a reliable method used when correct communication is required, while connectionless communication is less time-consuming than connection-oriented communication. HLA supports point-to-point, multicast, and broadcast communication methods, and the entire network transmission is ordered. However, the HLA standard was proposed and formulated by the US military for simulation applications in the military field. It is relatively complex and cumbersome for simulation applications in other fields. Therefore, the architecture of the distributed substation simulator was redesigned by absorbing the HLA standard and adopting its interface standardization, simulation support reusability, and separation of application and support, in order to achieve the following effects: (1) Each simulation node can "publish" and "order" data; (2) Each simulation node can dynamically "join" and "exit" the simulation operation; (3) Filter network data to reduce communication volume; (4) Use multi-threading to handle the sending and receiving of network data; (5) Use object-oriented methods to improve the reusability of modules. 3.3 RtiServ RTI based on HLA/RTI The RTI operation support program RtiServ runs on the server (NT Server) and adopts a centralized RTI. The RtiServ program adopts one-to-one (unicast) and one-to-many (multicast) transmission methods. Unicast and broadcast represent two extremes of addressing schemes (one-to-one or network-wide). Multicast aims to provide a compromise, where multicast data is received only by interfaces interested in the data; that is, by interfaces on the host running the application system that wants to participate in the multicast session. Broadcast is generally limited to a local area network (LAN), while multicast can be used across LANs and wide area networks (WANs). FedM is the main thread that manages the entire federated execution, while the implementation of other objects is handled by various sub-threads. The FedM object manages the overall federated execution: creating, controlling, adding, and deleting federated executions. A federated execution must exist before a member is added. The order in which members join a federated execution is unpredictable, but a federated execution must be deleted only after all members have left. A diagram illustrating the creation and deletion of federated executions is shown in Figure 4. [img=294,194]http://zszl.cepee.com/cepee_kjlw_pic/files/wx/dwjs/2000-9/52-1.jpg[/img] RtiServ consists of different objects: RtiM, PubM, SubM, and RtiR. The RtiR object is responsible for the interaction between federation members and RtiM, including attribute updates and scheduling. The PubM object manages changes to the state of published data objects and propagates these changes to other objects. The SubM object compares the subscription and update regions of each object and issues subscription information to objects that meet the conditions. The RtiM object consists of different objects such as DM, OM, TM, and OWM. It performs object management, declaration management, ownership management, and time management to maintain consistency. RtiM can also declare the information it can send and the interactions it wants to receive, giving each object joining the federation a unique ID. The object ID is dynamically generated by RTI. When an object is deleted, RtiM should notify all members interested in that object that the object has left the federation. Ownership management services facilitate the transfer and acceptance of attribute ownership among members. Once authorized, a member has the right to remove another member from the federation. The TM object is responsible for calculating time stamps (TS) to ensure the order of events in the simulated world matches the order of events in the real world, maintaining internal consistency and member-related information. Members can request federated time, the current (LowBound on The Time Stamp, LBTS) value, and time advance increments to facilitate interactions between members. The primary function of the DM object is to limit the distribution and reception of data over a large scale, reducing the amount of data transmitted over the network and processed by members. In HLA, the fundamental concept for data distribution is the routing space (RS), a multi-dimensional relational space that members use to describe the data they wish to receive and send. It has three elements: the dimension of the coordinate system, the path variables (corresponding to each dimension of the coordinate system), and the definition of the path variables in each dimension. Members specify a subscription area, meaning only data falling within that area will be sent. By specifying an update area and associating it with an object, members ensure that when the object is updated, if its attributes fall within the update area, the updated value will be sent. Federation members first inform the RtiM object of the data they wish to subscribe to or send. The RtiM object then matches the data, selects a routing space, establishes a connection, and finally sends the data. As shown in Figure 5, when subscription object S1 and publishing object P1 overlap, attributes associated with object P1 will be passed from the RitM object to object S1. Since the publishing area of ​​object P2 does not intersect with other subscription areas, sending data for object P2 will be prohibited. By calculating the publishing and ordering regions, it can be determined whether the publisher can publish and whether the orderer should accept. Therefore, region matching is called filtering calculation. The processing of filtering information establishes a correspondence between the data source and a set of destinations. The data only needs to be multicast once, thereby reducing network traffic. Therefore, RtiServ realizes the separation of simulation application and simulation support functions and significantly reduces network communication. The Common Object Request Broker (Corba) is a distributed object-oriented computing architecture that can hide the details of the underlying communication protocol and hardware. Therefore, the prototype of RTI is generally based on Corba [4-5]. When the object resides on another machine, the client and server must manage network communication through separate special layers: a stub on the client and a skeleton on the server. The Object Request Broker (ORB) shields the network communication, while the stub and skeleton classes are generated during the compilation of the IDL file. The IDL language provides a C++-like syntax [6] for Corba application developers to describe the interface of service objects. In the specific implementation, the visual programming tool C++ Builder 4 is used. C++ Builder 4 conveniently provides visual Corba Server, Corba Client, Corba IDLFile, Corba Object Implementation objects, and a large number of Corba-based application routines, making it easy to implement distributed computing. C++ Builder 4 also provides a service broker (smart agent) to implement dynamic, distributed directory services. At runtime, the ORB establishes a connection with the SmartAgent via broadcast. Once the connection is established, data is transmitted using UDP point-to-point communication. [img=313,141]http://zszl.cepee.com/cepee_kjlw_pic/files/wx/dwjs/2000-9/53-1.jpg[/img] 3.4 Implementation of Distributed Data Filtering Mechanism Under HLA, data filtering is implemented through the path space (RS). By matching and calculating the publishing and ordering areas, it is determined whether the publisher can send data and whether the orderer can receive data, and a correspondence between the data source and a set of destinations is established. Based on this, through the multicast function of the underlying network, the data only needs to be sent once. For example, the grid-based filtering mechanism divides the path space into grids of equal granularity and assigns one address to each unit. The sender sends data to the address corresponding to the grid that intersects with its publishing area. However, this method has too many addresses, resulting in serious waste of network resources. Therefore, a better filtering method must be found, such as using a send-based filter (SBF) mechanism on top of RS. In distributed simulation, the data filtering mechanism should be efficient and not affect the simulator's implementation efficiency. On each simulation node, the CPU overhead mainly consists of three parts: simulation model calculation, data reception, and filtering mechanism overhead. On each simulation node, a filtering subprocess is derived from the main simulation process. This subprocess is responsible for filtering information sent by RtiServ (ordering information, release information), matching ordering area information with other release area information, and guiding the corresponding node to start or stop sending data based on the matching results, thereby effectively reducing network data redundancy. 4. Issues to Note in HLA/RTI Implementation 4.1 Multithreaded Data Sharing Multithreaded applications differ significantly from single-threaded applications. In a single-threaded application, all system resources within a process are used by a single thread. In a multithreaded application, multiple threads coexist in the process's virtual space, sharing all process resources. If multiple threads simultaneously access or manipulate a variable within the process, unexpected errors will occur in the application. Therefore, data read and write operations must be handled using "data locks". When a thread performs a read or write operation on data, it should first call the Lock method to lock the data to prevent other threads from accessing it. After the operation is completed, the UnLock method should be called to release control of the data. 4.2 Asynchronous Transmission By default, sockets are in blocking mode. When a socket call cannot complete immediately, the process enters a sleep state, waiting for the operation to complete. To improve network transmission speed, non-blocking I/O sockets should be used. [b]5 Conclusion[/b] Distributed interactive simulation technology is constantly developing. This paper applies the HLA specification to substation simulation, which is a beneficial attempt. With the advancement of CORBA technology, distributed simulation technology is also becoming increasingly sophisticated, which will inevitably promote the application of simulation technology in the power industry. [b]References[/b] [1] East China Electric Power Research Institute. Joint test report on harmonics of 500kV power grid in East China [R]. 1994 [2] Feng Baoyi. Preliminary study on harmonic problems of 500kV power grid in East China [J]. East China Electric Power, 1992, (4) [3] GB/T 14549-93. Power quality and harmonics of public power grid [S]. [4] Yao Guocan, et al. Instructions for use of power system harmonic program (CHP program) [R]. Technical report of China Electric Power Research Institute, 1991.