[Open Source] C # cross-platform Iot communication framework ServerSuperIO (SSIO ),

[Open Source] C # cross-platform Iot communication framework ServerSuperIO (SSIO ),
[Serialization] C # communication (Serial Port and network) Framework Design and Implementation-1. communication Framework Introduction [serialization] C # communication (Serial Port and network) Framework Design and Implementation 2. overall Framework Design

 

Contents

C # cross-platform Iot communication framework ServerSuperIO (SSIO) officially open source... 1

1. Features of SSIO

2. SSIO Overview

3. Differences between SSIO and SiO2

4. Control Mode

5. cross-platform Windows and Linux

 

I. Features of SSIO

 

Ii. SSIO Overview

The SSIO communication framework is developed on the basis of SuperIO (SiO2) and has no advanced technology, mainly the accumulation of work experience, suitable for Iot  and interaction in different application scenarios. SSIO and SiO2 are not simple IO high-performance operations, but a coordination mechanism between device drivers, IO channels, control modes, and actual hardware devices. They can be seamlessly connected and operated in various aspects, it is also a pain point for solving practical work and application scenarios.

Data Interaction Between Software and Hardware faces a complex field environment:

(1) complex and diverse communication protocols. There are standard protocols, such as Modbus, and many protocol formats modified according to the standard protocol, as well as custom protocol formats, which are very different. For a poor software architecture, it is difficult to cope with it. To increase the number of devices or protocols, we need to sort out the entire software. New problems or bugs often occur in this process.

(2) Different users have different requirements on the software interface or functions to meet the display requirements of different users and can customize the data display interface. You need to provide a display view interface to interact with the device driver.

(3) Since the data of the on-site equipment is collected, it must be processed, not only for saving, querying, and reporting, but also: data Forwarding and data output (OPC, analog, dashboard, etc. A service interface is required to interact with the device driver.

(4) Diversity of communication links. communication methods such as RS232, RS485, RS422, RJ45, and 3G/4G may be supported for the same device, therefore, a device must correspond to multiple communication methods (Serial Port and Network), which also causes great obstacles to our development.

(5) the link between the device driver, I/O channel, and the actual on-site hardware terminal is complex and may be: one device driver corresponds to one I/O channel, one device driver corresponds to multiple I/O channels, and multiple device drivers correspond to one I/O channel.

(6) since the device interacts with the server, the device's communication status, I/O status, and the status of the device itself should be monitored so that the device can be maintained.

(7) software versions, poor compatibility between software and hardware, and complicated management. When the Framework Platform is stable, you only need to update the device driver.

To solve the above problems, develop a software framework and support secondary development. Without modifying the software framework, you can easily access devices, maintain devices, integrate devices, and process device business data. The software framework is relatively stable, and the easy-to-change part is flexibly designed.

 

Iii. Differences between SSIO and SiO2

Serial number	Attribute	SSIO	SIO
2	Control Mode	Polling mode, automatic control mode, concurrency mode, Singleton Mode	Polling mode, automatic control mode, concurrency mode,
3	Performance	High Performance	Inferior performance to SSIO
4	Service instance	One process can create multiple service instances	A process can only create one service instance
5	Cross-platform	Supports Linux and Windows	Only Windows versions are supported.
6	Secondary Development	Convenient (excluding the interface)	You only need to inherit to create a complete application.
7	Code structure	More suitable	Many Singleton modes are used.
8	Serial Port Components	SerialPort	PCOMM
9	Network Components	SocketAsyncEventArgs	Socket
10	Open Source	Open Source	No open source
11	OPC	Not Supported	Supported
12	Analog quantity	Not Supported	Supported
13	Plug-ins	Secondary Development is required	Fully supports plug-in deployment

 

Iv. Control Mode

(1) Polling mode:This control mode can be used for serial and network communication. When multiple devices are connected to the communication platform, the communication platform polls the scheduling device for communication tasks. At a certain time point, only one device can send a request command and wait for receiving the returned data. After the device completes sending and receiving (if timeout occurs, it will automatically return, the next device performs the communication task and polls the device in turn. For example:

 

(2) Concurrency mode:This control mode can be used only for network communication. The concurrent communication mode is to send request commands from all devices in a centralized manner. The framework uses the cyclic synchronization mode to send request commands. There is also an opportunity to further improve the use of parallel asynchronous methods to send request commands in a centralized manner. The hardware device verifies the received commands and returns the data of the corresponding commands after the verification is successful. After the communication platform asynchronously listens to the data information, it receives the commands, then, data is distributed and processed. For example:

 

(3) Automatic Control Mode:This control mode can be used only for network communication. The self-controlled communication mode is similar to the concurrent communication mode. The difference is that the sending command operation is handed over to the device driver for control, or to the secondary developer, secondary developers can send instruction data in an event-driven manner through clock timing. The hardware device verifies the received commands and returns the data of the corresponding commands after the verification is successful. After the communication platform asynchronously listens to the data information, it receives the commands, then, data is distributed and processed.

The self-controlled communication mode can provide secondary developers with a precise real-time request data mechanism, making the communication mechanism more flexible and autonomous. If multiple device drivers use the same IO channel, there will be deviations in time control. For example:

 

(4) Singleton mode:This control mode can be used only for network communication. A service instance can have only one device driver, which is equivalent to a device driver that corresponds to more than N hardware device terminals. It is more suitable for communication data protocols with fixed standards to process different data with command keywords. Suitable for highly concurrent hardware terminal devices to actively upload data. The server processes and returns the corresponding data based on the data information. For example:

 

 

V. Cross-platform Windows and Linux

(1) WindowsRunning Effect

 

(2) Linux Running Effect

 

Open Source Address: https://github.com/wxzz/ServerSuperIO

Baidu Network Disk: http://pan.baidu.com/s/1eRy0inK

QQ: 504547114

QQ: 54256083