Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "what are the knowledge points of the overall design of the C# framework". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

2.1 Host programming

As a plug-in application framework, it is necessary to have a host program to host and load the plug-in, provide a runnable environment for the plug-in and driver, and seamlessly connect the host program with the plug-in. The relationship between the host program and the plug-in is the relationship between water and fish. If there is water without fish, the water will lose its value; if there is no water, the fish will die. From a relational perspective, what is the purpose of developing a framework? It is related to other things, including developers, secondary developers, applications, plug-ins, and even other software or components. The more relationships that take place and the more harmonious they get along, the higher the value of this framework. Therefore, a good framework platform not only reflects the technology of developers, but also reflects the emotional intelligence of developers.

The SuperIO framework uses NET reflection technology to develop the plug-in management mechanism. The specific technical details are not introduced in this chapter, but the technical application is introduced in detail in Chapter 8 plug-in engine Design.

So how should the host program of a framework be designed? Or from what aspects to consider the design problem? I've been thinking about this all the time when I was developing the SuperIO framework. First of all, this problem should not be considered from a technical point of view, but from a human point of view to consider how to do it, the application's point of view, the secondary developer's point of view to plan the host program.

From the perspective of application, the host program should include user management, device driver management, device status monitoring, custom UI plug-in display, custom output data plug-in operation, service plug-in service, software operation, serial port IO channel monitoring, network IO channel monitoring and so on. These are our plans from a broad direction, and we need to further refine them to guide our development work.

User management, to support multiple users and user rights assignment. For the real-time data acquisition framework, when facing the field application, it will definitely involve two roles: users and engineers. Permission location for users: you can view parameters and data information. For engineers' rights positioning: not only have the permissions of the users, but also modify the parameters. User-managed menu, as shown below:

Device driver management, device driver (plug-in) is one of the core parts of the framework designed through interfaces and abstract classes, which can load the secondary developed device plug-ins into the framework and run, complete data acquisition, verification, parsing, processing and other related operations, as well as command, data interaction. At the same time, device driver management should also specifically delete the functions of the relevant device plug-ins. Add device plug-ins, as shown below:

In the way of equipment status monitoring, we can call it "device operator". It does not simply display all the parameters, attributes and other data of different types of device drivers, but displays and monitors the common parameters, attributes, real-time status and other data of the equipment. For example: device ID, device name, address, communication type, IO parameters, IO status, communication status, device status, alarm status, device type and number, etc. As shown below:

Customize the display mode of the UI plug-in. The secondary developer develops the data display mode based on the standard interface and mounts it into the configuration file of the framework. When the user clicks a display view, it is displayed in the form of Tab Form, and you can click the button to close it, as shown below:

Custom output data plug-in operation mode, this kind of output data is the export of real-time data, more as a transactional service, a class of device data can be output to a variety of data formats. The output data plug-in can be loaded through the configuration file, and as long as the device driver has data update, the data is passed to the output data plug-in through the interface for output operation. If the plug-in information is not configured in the configuration file, the program does not load or output. Therefore, this transactional service does not require an interface, but can be done through code when the host program starts.

The service mode of the service plug-in, which is a long-running transactional task, so it is more complex. Some services need to run automatically when the host program starts, and some services need to be started manually to run. When the host program starts, it is necessary to load the service information into the menu. Some of the services displayed in the menu may have been started, while others need to click, display the form and fill in the necessary information before starting. Therefore, the host program and the service plug-in do not interact one-way, but two-way interaction of data and events. For example, after collecting and processing the data of the device, to upload the data to the service center or other areas, you can develop a plug-in to accomplish this task, as shown in the following figure:

The mode of monitoring the operation of the software, which is a real-time log monitor that can monitor the operation of the framework and the operation of the device. The exception information can be displayed amicably and the details of the exception can be saved to the log file. We can call it a "running monitor", which is very helpful for the operation of the real-time data acquisition framework. As shown below:

Serial port IO channel monitoring mode, when a device driver communicates in serial port mode, the current serial port IO status will be reflected in the serial port monitor when the serial port parameters are changed dynamically, such as adding serial port, deleting serial port, changing serial number and baud rate and so on. As shown below:

The network IO channel monitoring method is relatively easy to design, which only needs to reflect the events of the connection and disconnection of the Socket instance. When the Socket instance is valid, the information is added to the network monitor. When the Socket instance is invalid and relevant resources are released, delete the relevant information from the network monitor. As shown below:

Based on the above analysis, we need to build a complete host program with the necessary functions, but the program is not necessarily complex, because some functions, responses, attributes, data and so on can be completed in the device plug-in. The design is described in detail in Chapter 3 device driver Design. The built host program, as shown below:

If there is a host program, then it has not been fully analyzed. It is also necessary to analyze whether the host program can maintain a good relationship with the secondary developer from the perspective of the secondary developer. This involves the formal problem of the host program, which, as a part of the SuperIO framework, is a whole component. It is hoped that the secondary developer can quickly build his own main program by inheriting the host program, and the function can be extended on this basis. In this case, the access rights of the key controls of the host program need to be set to protected. In addition, the host program also needs a configuration file, which can set the parameters concerned by the secondary developer, such as title, version number, company name and so on.

After the above process, we have a clear understanding and planning of the host program. The skeleton of the interface has been built, and these functions are gradually realized from the details in the later development program. However, such a simple interface requires many classes, modules, and so on. Each module will be designed in detail in later chapters.

2.2 Communication mechanism design

For the real-time data acquisition framework, communication is always the core of the software, which requires high real-time performance and high stability. The software framework determines the stability of the software operation and the future expansibility, so it is necessary to design the communication mechanism and control mode.

In "1. The application scenario has been introduced in the introduction of the communication framework, so it is decided that there are two ways for the application of the software framework in communication: active request and passive reception.

Active request mode can also be called call answer mode or master-slave mode. That is to say, the initiative lies in the software framework, only the software framework actively sends the request command, after receiving the command from the slave (hardware devices, sensors, etc.) and verifying the integrity of the data, and determining whether the command is sent to itself, after the verification is successful, return the specified data information and complete a complete link communication process. Call answer communication, as shown in the following figure:

The passive receiving mode is that the software framework monitors the IO channel in real time. As long as there is data information, it will be extracted and verified. After successful verification, the data information will be analyzed, processed and saved. For example, devices, sensors, etc., send status data regularly. This mode of communication is shown in the following figure:

In complex application scenarios, these two communication methods may exist, which usually use Ethernet links for communication. Devices with only external serial ports can be accessed through the Ethernet conversion module.

2.1.1 Serial communication mechanism

Due to the limitation of serial communication, data confusion can be avoided when multiple hardware devices are connected to serial bus.

In general, the call response communication mechanism of polling mode is adopted.

2.1.1.1 polling mode

When multiple devices are connected to the communication platform, the communication platform will poll the scheduling equipment for communication tasks. At a certain time, only one device can send a request command and wait for the return data to be received. after the device completes sending and receiving (if it encounters a timeout, it will return automatically), the next device will carry out the communication task and poll the device in turn. As shown below:

2.2.2 Network communication mechanism

The polling communication mechanism is to ensure the orderly sending and receiving of data, and to avoid confusion of concurrent data on the serial bus, but this communication mechanism is at the cost of reducing performance and is suitable for serial communication. It is obviously unable to make full use of the advantages of network communication in Ethernet communication. Ethernet is an independent channel and can communicate in full duplex. In order to give full play to the advantages of Ethernet, concurrent communication mode and automatic communication mode are added on the basis of polling communication mechanism. One is to improve the performance of communication, and the other is to have more independent control in the secondary development.

2.2.2.1 polling mode

The Ethernet polling communication mode is consistent with the serial communication mode, as shown in the following figure:

2.2.2.2 concurrent mode

The concurrent communication mode is to send the request instructions of all devices centrally. Now the SuperIO framework sends request commands in the way of cyclic synchronization. There is also an opportunity to further improve the ability to send request commands centrally in a parallel and asynchronous manner. After receiving the instruction, the hardware device verifies and returns the data of the corresponding instruction after the verification is successful. after the communication platform monitors the data information asynchronously, it receives the operation, and then distributes and processes the data. As shown below:

2.2.2.3 automatic control mode

The automatic communication mode is similar to the concurrent communication mode, except that the instruction operation is handed over to the device driver itself for control, or to the secondary developer, the secondary developer can send instruction data through the clock timing and event-driven mode. After receiving the instruction, the hardware device verifies and returns the data of the corresponding instruction after the verification is successful. after the communication platform monitors the data information asynchronously, it receives the operation, and then distributes and processes the data.

The automatic communication mode can provide a precise timing request real-time data mechanism for secondary developers, which makes the communication mechanism more flexible and autonomous. As shown below:

Both concurrent mode and automatic control mode can receive data passively, and the application scenario is more flexible, which makes the development of software framework and hardware devices more free.

2.3 hierarchical schematic diagram

2.4 schematic diagram of model object

This is the end of the content of "what are the knowledge points of the overall design of the C# framework". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.