Abstract: This paper elucidates the concept, advantages, implementation methods, and development trends of runtime configuration. Keywords: Configuration software, runtime configuration, online configuration, I/O devices. I. Introduction Runtime configuration is a newly proposed concept in configuration software. Runtime configuration involves modifying existing projects and adding new functions within the runtime environment. It differs from online configuration, which involves entering the configuration environment while the project is running and modifying the project within that environment. Runtime configuration, however, directly modifies the project within the runtime environment. Runtime configuration changes the history of having to enter a complex configuration environment to modify project applications, bringing new vitality to configuration software and indicating a new direction for its development. To explain what runtime configuration is, let's use an analogy. We can compare project configuration to building a house. Before construction, blueprints are designed, and construction is carried out according to the blueprints. After the project is accepted, the size and structure of the house are fixed. After delivery to the occupants, they cannot easily change the structure of the house (unless they are the architect themselves and have legal permits), nor can they expand the size of the house. If you want to renovate a house, you must hire an architect to design it and construction workers to carry out the work. Traditional configuration software works similarly; once a project is configured and delivered to the user, its functions are fixed. If you want to expand or modify the project's functions, you must have a configuration engineer familiar with the project enter the configuration environment to make the changes. Imagine how convenient it would be if, after a house is built, users could easily change the internal structure of the rooms or expand the space according to their needs. If the architect made the walls movable and stretchable, and included the machinery needed to construct the walls, doors, and windows, you could easily turn a bungalow into a multi-story house or add height to a multi-story house yourself. Of course, architects would find it difficult to create such equipment, but configuration software can do just that. Configuration engineers can proactively design extension tools for a project after its initial construction. These extension tools are used to generate the necessary visuals, components within those visuals, connected hardware devices, new measuring points, etc., required for expanding the project. Extension tools are entirely specific to the project or application area; they typically contain only a limited number of components for that application, but are sufficient to support future expansion of the project. Because it's much easier for technicians (non-configuration engineers) to master these tools than to master an all-encompassing development environment, users can easily complete the later maintenance work of the project with minimal guidance. Furthermore, since the extended tools only provide limited functionality, the chances of users making mistakes are much smaller. II. Advantages of Runtime Configuration * Shortened project timeline. For a specific project, if the patterns used in the project can be summarized and made into a template (which can be generated at runtime using the aforementioned extended tools), then we don't need to wait until the entire project is completed before it can be put into operation. That is, once the necessary tools for the project are completed, end users can add functionality themselves at runtime. Users can modify and improve the project in the runtime environment until the entire project is completed. This working mode fully leverages the advantages of configuration engineers and technical workers, quickly completing the project. Because configuration engineers are familiar with the configuration software, and technical workers are familiar with its application, allowing them to do what they are familiar with naturally speeds up the project. * Solves the problem of uncertain equipment and visuals. Some projects inherently have such requirements. For example, in coal mine safety monitoring, the work site is mobile, and the monitoring equipment changes frequently. This requires the measurement points and monitoring screens in the configuration software to be constantly adjusted according to the situation. It's impossible to exhaustively enumerate all possible scenarios in advance using conventional methods, nor is it feasible to require on-site technicians to enter a complex development environment for modifications every time a change is made. However, the on-site application mode is relatively stable, making it easier to build runtime extension tools. Runtime configuration is very suitable for this. * Dynamic generation and simplified screens. Previously, implementing dynamic scenes required listing each element in the configuration environment and then adding hide/show animations to the screen elements, making production and maintenance very cumbersome. During runtime, these elements had to be allocated space regardless of whether they were used, resulting in some waste. Dynamic generation technology can create elements as needed, simplifying the screen and reducing system overhead. * Simplified configuration environment. The components used in dynamically generated points and screens are all related to the current application; irrelevant components will not appear in the runtime "configuration" environment. Runtime "configuration" is tailored to specific applications. Compared to configuration in the development environment, it is much simpler and easier for factory technicians to master. This ensures both the scalability of the final application and the simplicity and convenience of running the "configuration". * Easy maintenance. Traditional configuration means that the application's functionality is fixed after the project is configured. If modifications or new functions are needed, the development environment must be reconfigured. This generally requires engineers proficient in the development environment and familiar with the project. If the project was not completed by the company, it involves upgrades, modifications, and even the cost of starting a new project. Dynamic generation ensures a certain degree of system scalability and can be completed by general technical personnel in the factory. * Facilitates the industry-specific development of configuration software. Industry engineers can configure the necessary components for runtime based on their industry needs, allowing general technical personnel to use them, thus forming a three-tiered application model. Software engineers focus on developing flexible methods, industry engineers focus on building industry components, and ultimately, technical personnel implement their application logic. This three-tiered application model will greatly accelerate the industry-specific process of configuration software. III. Security Issues. If screens, elements, and points in the database can be added, modified, or deleted at will during runtime, wouldn't that be very dangerous? Yes, it is indeed very dangerous. Without protective measures, runtime generation can lead to numerous problems. We can protect runtime projects through the following two security measures: 1. System Protection Measures: * Only users with specific permissions can perform runtime configuration. * Only the creator of the screen can modify screen elements; other users have no right to modify them. * Privileged users can disable runtime configuration functions after the project is completed. 2. Design-Time Protection: Since runtime tools are generated by configuration engineers, the freedom of runtime configuration is entirely controlled by them. This requires configuration engineers to limit the means provided during runtime, avoiding excessive and unnecessary flexibility, while providing necessary protection measures for modified objects. For example, if a tool for runtime configuration points is provided, it is necessary to protect existing points and limit the number of points added by users. The same applies to screen modification; screens that do not require runtime modification should not have "runtime edit" permissions. In short, configuration personnel must provide users with means to extend functionality while imposing sufficient restrictions to ensure the safe operation of the system. IV. Runtime Configuration Implementation Currently, both domestic and international configuration software offer very little support for runtime configuration, especially for adding devices and variables at runtime, which is largely unsupported by most software. While configuration software supporting VBA scripts can dynamically generate screens through programming, this is still a non-visual approach. Zijinqiao Monitoring Configuration Software has made a preliminary attempt in this area. The following uses Zijinqiao Monitoring Configuration Software as an example to illustrate the implementation method of runtime configuration. Runtime configuration includes two parts: runtime database configuration and runtime graphical configuration, which are explained below: 1. Database Configuration Runtime database configuration includes dynamically adding, deleting, and modifying the following: * I/O devices. * Database points. * I/O connection items, network connections. * Historical save items. The script in the interface supports the above operations, and after modifying the above content, the database does not need to be restarted; the changes take effect immediately and do not affect the normal operation of existing database points. In general applications, only a limited number of device types and point types are involved. For each device or point type, we need to create a corresponding window on the screen. This window is used to maintain the I/O device or point. Below is a simple point definition window: Runtime point configuration screen example 2. Adding graphic objects during screen configuration includes two methods: script-created objects and manual addition of graphic objects during runtime. These are described below. 2.1 Steps for dynamically generating graphics using scripts o Define a graphic object template. o Replace existing objects, add new objects, and replace variables referenced in objects using the following scripts. Commonly used script functions are as follows: * Call the RepObj function to replace objects. * Call the AddObj function to add new objects. * Call the RepVar function to replace variables. * Call the DelObj function to delete objects. * Outside the window, you can call RepVarWin to replace variables in selected objects. o Save the modified screen to the main server. The screens of other clients will be automatically updated. This step is not necessary. If you do not need to save to the server, you can ignore this step. o Switch to "Edit" mode during runtime. At this time, you can manually add, modify, delete, and adjust template objects. It also allows for the replacement of variables referenced in primitive objects. 2.2 Manually Adding Graphic Objects at Runtime Manually adding graphic objects at runtime is more flexible. The basic steps are as follows: * Select the "Allow Runtime Editing" checkbox in the window parameters. If security management is enabled, an account with "Runtime Editing Screen" permissions must also be specified; only this account can dynamically generate objects. * Create the tool screen. Add the tools needed for runtime to this screen. Each tool should be created as a sub-graph, cell, or graphic template and placed below the drag-and-drop object. * Add the tool screen through the "Screen" tab in the navigation tree, specifically the "Operation Panel." This step is optional. * At runtime, add graphic objects by dragging and dropping objects from the tool screen. * Save the changes and send them to the server (this step is not mandatory). Graphic objects added manually at runtime must be pre-drawn during configuration and added to the tool screen. At runtime, they are drawn to the corresponding screen by dragging and dropping, then their associated variables are modified, and finally saved to the server to achieve the dynamic addition of graphic objects. Example 5 of runtime screen generation. Development Direction Configuration software is generally referred to as general-purpose configuration software. The term "general-purpose" indicates its suitability for various application areas. While different application areas share many commonalities, industry differences are objectively present. These differences manifest in the organization of the interface, component components, and construction logic. If configuration software were to encompass everything to adapt to every industry, the software presented to users would be overly complex, ultimately resulting in poor user-friendliness and rendering it meaningless. As mentioned earlier, dynamically generated elements are generated within the configuration environment. Industry engineers can build the modules required for their application area within the configuration environment, and then specialized technicians can use familiar components to build their applications at runtime. This creates a three-tiered application model for configuration software: software engineer – industry engineer – specialized technician. Software engineers focus on providing flexible tools for industry engineers, who build industry modules, and specialized technicians build the final application. This is how configuration software penetrates into specific industries, and this is precisely the future development path for configuration software.