"Open source" C # cross-platform IoT communication Framework Serversuperio (Ssio)

Recently learned a framework, thanks to the network name: only smile to share

Blog Original address: http://www.cnblogs.com/lsjwq/p/5316577.html

Directory

C # Cross-platform IoT communication Framework Serversuperio (Ssio) official open Source ... 1

1. Features of the Ssio

2. Ssio Overview

3. The difference between Ssio and Sio

4. Control mode

5. Cross-platform Windows and Linux

I. Characteristics of Ssio

1. Lightweight, high-performance communication framework for a wide range of application fields, polling, auto-control, concurrency, and Singleton modes.
2. Device driver, IO Channel, control mode scene coordination and unification.
3. The device drives the interior command drivers, command buffers, custom parameters, and real-time data elements.
4. The framework platform supports scheduling at the priority level of the device command, ensuring that high-level commands are sent in a timely manner.
5. A device driver supports both serial and network communication methods to monitor IO channel data.
6. A device driver that can support TCP server and TCP client two modes of operation during network communication.
7. Built-in Display view interface to meet different display requirements.
8. Built-in service component interface, can be customized to complete the OPC service, 4-20ma output, led large screen display, SMS services, as well as multi-functional gateway services.
9. You can create multi-service instances to complete the split of different businesses.
10. Supports cross-platform deployment and can run on Linux and Windows systems.

Two. Ssio Overview

The design idea of ssio communication frame is developed on the basis of Superio (SIO), and there is no high technology, mainly the accumulation of work experience, which is suitable for the data collection and interaction of IoT in different application scenarios. Ssio and Sio are not simply high-performance operations for IO, but a coordination mechanism between device drivers, IO channels, control modes, and actual hardware devices, seamlessly bridging and running, and also to address some of the pain points of real-world work and application scenarios.

Data interaction between hardware and software, and is faced with a complex field environment:

(1) complex and diverse communication protocols. There are standard protocols, such as Modbus, and there are many protocol formats modified by standard protocols, as well as custom protocol formats, and vary widely. For a bad software architecture, struggling to cope with, adding equipment or protocols to comb the entire software, often in the process of new problems or bugs.

(2) for different users of the software interface or function requirements are very different to meet the different user's display requirements, you can customize the data display interface. Then you need to provide a display view interface to interact with the device driver.

(3) Since the field equipment data is collected, then it needs to be processed, not only save, query, report, and so on: data forwarding, data output (OPC, analog, large screen, etc.). Then you need to provide a service interface that interacts with the device driver.

(4) The multiplicity of communication links, for the same device may want to support rs232/rs485/rs422, RJ45, 3g/4g and other communication methods, so for a device to correspond to a variety of communication (serial port and network), but also to our development caused great obstacles.

(5) The link between device driver, IO Channel and actual field hardware terminal is complex, it is possible that a device driver corresponds to an IO channel, a device driver corresponds to multiple IO channels, and multiple device drivers correspond to an IO channel.

(6) Since the device and the service side of the data interaction, then the device should be the communication status, IO status, and the status of the device itself to monitor, so that the device is in a maintainable state.

(7) Software versions, and software and hardware compatibility is poor, management complex. In the case of a stable frame platform, only the device driver needs to be updated.

To solve these problems, a software framework was developed to support two development. In the case of software framework changes, it is convenient to access equipment, maintenance equipment, integrated equipment, processing equipment business data. The software framework is relatively stable, and the easily changing parts are flexibly designed.

Three. The difference between Ssio and Sio

Serial number	Property	Ssio	SIO
1	Application Scenarios	Suitable for high-frequency data acquisition and control, can be deployed on the server side.	It is suitable for general computer data acquisition, for example, the application of factory level server in LAN.
2	Control mode	Polling mode, auto-control mode, concurrency mode, singleton mode	Polling mode, auto-control mode, concurrency mode,
3	Performance	Performance	Performance is inferior to Ssio
4	Service instance	A process can create multiple service instances	A process can only create one service instance
5	Cross-platform	Support for Linux and Windows	supports only Windows versions of the operating system
6	Two-time development	Convenience (not including interface)	Just inherit to create a complete application
7	Code structure	More appropriate	More singleton patterns are used
8	Serial components	SerialPort	Pcomm
9	Network components	SocketAsyncEventArgs	Socket
10	Open source	Open source	No open source
11	Opc	Not supported	Support
12	Analog quantity	Not supported	Support
13	Plug - ins	Need to develop yourself two times	Full support for plug-in deployments

Four. Control mode

(1 Polling mode: This control mode can be used when the serial port and the network communicate. When multiple devices are connected to a communication platform, the communication platform polls the dispatch device for communication tasks. Only one device at a time can send a request command, wait to receive the return data, the device completes the send, receive (automatically returns if a timeout occurs), the next device does the communication task, polling the device in turn. Such as:

(2 ) concurrency mode: This control mode is available only for network traffic. The concurrent traffic mode is a request instruction that sends all the devices centrally, and the framework sends the request commands in a circular synchronous manner. There is also an opportunity to further improve the centralized sending of request commands in a parallel asynchronous manner. After the hardware equipment receives the instruction to verify, after the verification succeeds returns the corresponding instruction the data, the communication platform asynchronously hears the data information, carries on the reception operation, then carries on the data the dissemination, the processing and so on. Such as:

(3 Automatic mode: This control mode can be used only when the network is communicating. The self-control communication mode is similar to the concurrent communication mode, the difference is that the sending instruction operation is given to the device driver itself for control, or to two developers, two times the developer can send the instruction data in event-driven manner through the clock timing. After the hardware equipment receives the instruction to verify, after the verification succeeds returns the corresponding instruction the data, the communication platform asynchronously hears the data information, carries on the reception operation, then carries on the data the dissemination, the processing and so on.

The self-control communication mode can provide accurate timing request real-time data mechanism for two time developers, make communication mechanism more flexible and autonomous, if multiple devices drive using the same IO channel, TIME control will be biased. Such as:

(4 ) Singleton mode: This control mode can be used only for network communication. There can be only one device driver in a service instance, which is equivalent to a device driver that corresponds to n multiple hardware device terminals. Data protocols that are more suitable for communication have a fixed standard for processing different data with the command keyword. It is suitable for the high concurrent hardware terminal device to upload data actively, and the server to process and return the corresponding data according to the data information. Such as:

Five. Cross-platform Windows and Linux

(1 ) Windows Run effect

(2) Linux operation effect

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

Baidu Network disk: Http://pan.baidu.com/s/1eRy0inK

qq:504547114

QQ Group: 54256083

"Open source" C # cross-platform IoT communication Framework Serversuperio (Ssio)