[Serialization] C # design and implementation of communication (Serial Port and network) framework-6. Design of Communication Controller,

[Serialization] C # design and implementation of communication (Serial Port and network) framework-6. Design of Communication Controller,

Contents

Chapter 6 Design of Communication Controller... 2

6.1 Controller Interface... 2

6.2 serial controller... 3

6.3 network controller... 5

6.4 Communication Control Manager... 9

6.5 remote interaction... 9

6.6 Summary... 10

 

Chapter 6 Design of Communication Controller

After the introduction in the previous chapters, this chapter introduces the communication controller. It is mainly responsible for coordination, scheduling, and Event Response to device drivers and I/O channels, on this basis, task scheduling is implemented in polling communication mode, concurrent communication mode, and automatic communication mode. The implementation of Communication Controllers varies greatly due to the characteristics of the serial port and network hardware links and the communication mechanism.

6.1 Controller Interface

The Controller has a built-in thread responsible for task coordination and scheduling for device drivers and IO instances, it is equivalent to building a high-level coordination mechanism on the basis of the implementation of chapter 1 Device Manager design and Chapter 4 serial port and network I/O design, and implement the matching and different communication mechanisms between devices and IO.

No matter how the serial communication controller and network communication controller are implemented, they inherit from the Unified (IIOController) interface. The Code defined for the interface is as follows:

Public interface IIOController {// <summary> /// Of course whether it is working /// </summary> bool IsWorked {set; get ;} /// <summary> /// keyword of the IO controller. /// </Summary> string Key {get;} // <summary> // start the service /// </summary> void StartService (); /// <summary> /// stop the service /// </summary> void StopService (); /// <summary> // IO controller type // </summary> CommunicationType ControllerType {get ;}}

The control Hierarchy Diagram is as follows:

 

6.2 serial Controller

Each (hardware) Serial Port corresponds to a serial port controller. Each serial port controller has an independent thread, that is, how many controllers and threads will be used for each serial port number. The Framework Platform may mount multiple device drivers (plug-ins). One device driver may correspond to one serial port, or several device drivers may share one serial port, that is to say, there is a one-to-one or one-to-N relationship between the serial controller and the device driver. The structure is as follows:

Scheduling cycle of a device = (number of all devices in the serial controller-1) * Time consumed by a single device driver

This is only a theoretical value. In practice, it is larger than this theoretical value because drivers of non-types of devices share a serial number and work in a serial controller, different data processes and methods are processed. For example, data may be stored in a TXT file, SQL database, or NoSQL database.

Someone may wonder, isn't it true that the more devices attached to a serial port, the lower the efficiency. However, multiple serial controllers work in parallel mode. If the field environment requires communication efficiency, you can add a Serial Server, that is, add available serial port hardware circuits, and balance the load of N device drivers to different serial ports, the node of the serial controller running in parallel is added to improve the operating efficiency of the Framework Platform.

However, this solution also brings some risks and bottlenecks, that is, for data storage, if multiple parallel data streams write data to a single-thread storage medium at the same time, this can cause mutual exclusion and unexpected results or exceptions, such:

 

If data is stored in SQL Server, Oracle, Mysql, and other databases at the same time, there is no problem. If data is stored in text files, desktop databases, and other databases, there may be problems, multiple files can be saved. Most DCS use PI (Plant Information System) databases. In short, as a system, the overall design and consideration are required, which requires special attention.

6.3 network controller

The Framework Platform has only one network controller. The network controller has an independent thread responsible for polling, concurrency, and automatic control mode communication and Scheduling for all network device drivers. The Round-Robin communication mode is similar to the serial controller. It only schedules drivers of all network devices in a serial mode. However, the framework only has one network controller and cannot improve the communication efficiency by adding a network controller, this mode is a weakness in network communication scheduling. In the concurrent communication mode, the thread sends the Request command data of all devices in a centralized manner through the thread in the controller, and receives the data through IO asynchronous listening, after receiving data asynchronously, the data is distributed to the device-driven RunIODevice interface for data processing. In the self-controlled communication mode, the function of sending command data is transferred to the device driver, you can use a timer to send command data. The thread is no longer responsible for sending command data, and the receiving data is the same as the concurrent communication mode. The network controller is as follows:

Public void ControllerSend (IRunDevice dev, byte [] data) {int counter = DeviceManager. getInstance (). getCounter (dev. deviceParameter. deviceID. toString (); int sendNum = SessionSocketManager. getInstance (). send (dev. deviceParameter. NET. remoteIP, data); if (sendNum = data. length & sendNum! = 0) {DeviceMonitorLog. writeLog (dev. deviceParameter. deviceName, "Send request data"); Interlocked. increment (ref counter);} else {Interlocked. increment (ref counter); DeviceMonitorLog. writeLog (dev. deviceParameter. deviceName, "failed to send data");} dev. showMonitorIOData (data, "send"); if (counter> = 3) {try {dev. runIODevice (new byte [] {});} catch (Exception ex) {DeviceMonitorLog. writeLog (dev. deviceParameter. deviceName, ex. message); GeneralLog. writeLog (ex);} Interlocked. exchange (ref counter, 0);} DeviceManager. getInstance (). setCounter (dev. deviceParameter. deviceID. toString (), counter );}

The code for receiving and dividing data asynchronously is as follows:

Private void NETDeviceController_ReceiveSocketData (object source, ReceiveSocketDataArgs e) {if (GlobalProperty. getInstance (). controlMode = ControlMode. parallel | GlobalProperty. getInstance (). controlMode = ControlMode. self) {int counter = 0; IRunDevice dev = null; IRunDevice [] list = DeviceManager. getInstance (). getDevices (e. remoteIP, CommunicationType. NET); for (int I = 0; I <list. length; I ++) {dev = list [I]; if (String. compareOrdinal (dev. deviceParameter. NET. remoteIP, e. remoteIP) = 0) {dev. showMonitorIOData (e. receiveData, "receive"); dev. asyncRunIODevice (e. receiveData); counter = DeviceManager. getInstance (). getCounter (dev. deviceParameter. deviceID. toString (); Interlocked. decrement (ref counter); if (counter <0) {Interlocked. exchange (ref counter, 0);} DeviceManager. getInstance (). setCounter (dev. deviceParameter. deviceID. toString (), counter );}}}}

6.4 Communication Control Manager

The Communication Control Manager is responsible for managing the serial controller and network controller. In fact, it encapsulates the Dictionary <Key, Value>. All operations involving the controller are completed by the Control Manager. IIOControllerManager <TKey, TValue> Communication Control Manager interfaces are defined as follows:

 

6.5 remote interaction

After understanding the basic principles and functions of the serial controller and network controller, we also need to consider an application scenario: the Controller not only needs to interact with hardware, it is also possible to forward the collected data to other servers or nodes, that is, the framework platform must have the routing function, integrate the data collected by the device driver for packaging and forwarding.

In this application scenario, it is not suitable for forwarding and Multi-Service Processing in the Process of device-driven development, the scheduling of controllers may be blocked due to the impact of the environment, network, and business complexity, affecting the overall operating efficiency of the framework.

In Iot construction, multi-level interconnection and layer-by-layer forwarding are common technical requirements. To solve this problem, the Framework Platform provides the IAppService application service interface. The secondary developer can encapsulate the data information in the device driver and then pass it into the IAppService interface, you can implement specific service services such as caching and forwarding here. The purpose of this design is not to affect the real-time data collection on the Framework Platform and ensure the stability of the data source.

The specific design and application of IAppService will be detailed in chapter 1 external interface design.

Conclusion 6.6

After the communication controller achieves this, the Framework Platform will be able to run theoretically, but there is still a lot of work to be done from the design goal, and it cannot provide great convenience for secondary development. In the future design, we will gradually enrich the Framework Platform.

 

Author: Wei Xiaozhi

Email: 504547114@qq.com

QQ: 504547114

. NET Development Technology Alliance: 54256083

Document Download: http://pan.baidu.com/s/1pJ7lZWf

Http://www.bmpj.net