Ii. SuperIO architecture and components. superio architecture composition

Ii. SuperIO architecture and components. superio architecture composition
1.1 architecture diagram 1.1.1 level

 

1.1.2 model object

 

1.2 IO Manager

The IO Manager manages and schedules the serial port and network communication links. Based on the features of the serial port and network communication link, the serial port management and network management are derived from the IO Manager interface.

1.2.1 Serial Port Management

Serial Port Management allows you to create a Serial Port IO instance, enable the serial port IO, disable the serial port IO, and release resources in a timely manner, and manage IO operation instances.

1.2.2 Network Management

When a device uses the network communication mode, the device can work in the following modes: Tcp Server and TcpClient.

When the working mode is TcpServer, the communication platform listens to network connections. When the client connects to the server, the connection instance is put in the IO manager as an IO Interface.

When the working mode is TcpClient, the communication platform actively connects to the remote server. After the connection is successful, the connected instance is put in the IO manager as an IO Interface.

Heartbeat detection is performed on all network connection instances. The system responds to false connections, dead connections, remote disconnections, and hardware link disconnections, and actively releases network connection instance resources.

The network I/O manager responds promptly to events such as receiving data, sending data, connection operations, and disconnection operations.

1.3 Device Manager

The Device Manager is mainly responsible for the unified management of serial devices, network devices, and virtual devices, as well as the provision of interfaces for externally operable devices. Main implementation functions, such:

 

1.3.1 main device Interfaces

The device has a unified interface, which can be used as an operational instance when the communication platform is running. Interfaces include: event interfaces, function interfaces, and attribute interfaces. For example:

 

The following describes the functions and responsibilities of the main components of the device.

1.3.1.1 command Cache

Each device has a command cache that stores the commands to be sent by the device in the Command cache. When the communication platform is in polling or concurrent communication mode, the command Data Retrieval Interface is called to determine whether the current command cache contains data information. When the command caches data, it sends the data cached by the command, otherwise, call the interface for obtaining real-time data commands to send Real-time Data commands. For example:

 

1.3.1.2 protocol-driven

Protocol drivers are divided into two types: data transmission protocol drivers and data receiving protocol drivers. They are two essential attributes in the device instance for the communication platform to call.

The data sending protocol driver obtains the command interface to drive different functional functions, packs command data, and then sends data through the IO Interface.

The receiving data protocol driver uses the parsing command interface to drive different function functions, parse data information by command status word, and return operable objects for business processing.

1.3.1.3 data persistence

There are two types of data persistence: real-time data and parameter data. Both types of data are saved as XML files through the serialization interface.

When the device is initialized, the XML file is loaded, deserialized into an instance object, and used as the property interface of the device, so that the communication platform can perform necessary operations on the device parameters and real-time data.

In addition, secondary developers can inherit the serialization interface and customize the persistent data processing method. For example, the database is used as the carrier to avoid File Corruption due to high real-time performance.

1.3.1.4 Virtual Device Interface

You can develop virtual devices for the same type of devices, set virtual formulas for virtual devices, and process the data of multiple devices of the same type in the business logic.

1.3.1.5 run authorization

Each device has an authorization attribute. If an unauthorized device does not perform operations on the I/O interface, the device cannot communicate effectively. In the secondary development process, developers can perform authorization settings.

1.3.1.6 video interface

Each device has a video attribute operation interface. You can configure a video server for the on-site devices to display the file data and video data at the server end.

1.3.1.7 channel monitoring

It can monitor the data sent and received by the device I/O. The data is displayed in hexadecimal notation and the source data in hexadecimal notation is saved for device debugging convenience.

1.3.1.8 priority

There are two types of priority levels: High-level and General-level. You can set priority levels for devices and commands, and schedule devices and commands with priority in the IO Control Manager.

1.4 Control Manager

The IO Control Manager schedules the communication mechanism. The serial port is different from the network communication mechanism,

Therefore, the Control Manager is different, but the interfaces of the communication platform are unified.

1.4.1 serial port control

The I/O Control Manager has multiple serial controllers. Each serial controller has a separate thread, which schedules the polling communication mechanism for devices that set the serial port. For example:

1.4.2 Network Control

The I/O Control Manager has only one network controller. The network controller has a separate thread, which is responsible for polling, concurrency, and automatic control mode communication Scheduling for all network devices, it also performs asynchronous data listening on the IO channel to distribute the received data to the corresponding device driver. For example:

1.5 Module debugging 1.5.1 debugging Interface

The debugging interface defines interfaces for debugging devices, debugging interface views, debugging data export, and debugging application services. You can use these interfaces to debug the program modules of secondary development.

Definition of the debugging interface:

Void DebugDevice (IRunDevice dev );

Void DebugGraphicsShow (IGraphicsShow show );

Void DebugExportData (IExportData export );

Void DebugAppService (IAppService appService );

1.5.2 debugging method 1.5.2.1 interface debugging

The MainForm can be inherited. The form instance provides a debugging interface and can use SuperIO. device. debugDevice. the IsDebug attribute defines whether it is the debugging mode. If this attribute is true, you can dynamically load the program module through the debugging interface for debugging. If this attribute is false, the program will load the program module in the directory preparation file and cannot be tracked or debugged.

1.5.2.2 command console debugging

You can use DebugDevice. GetDebugInstance () to obtain the debugging instance. This debugging instance does not have the interface display function, but can debug the program module more conveniently and quickly.

1.6 component Controller

The platform controller is mainly responsible for assembling the main components and coordinating the orderly work between the components. It also provides externally accessible interfaces and debugging interfaces.

1.7 runner

The runner monitors the running status of all devices, including device name, address, communication type, IO parameter, channel status, communication status, device status, alarm status, and device type.

At the same time, it also includes the run Monitor, which is responsible for displaying the device running logs, serial port status monitoring, serial port control status display, network status monitoring, and network connection status display.

1.8 Monitor

The monitor monitors the log information generated during the running of the platform software, displays it in the running monitor, and monitors unknown exception information.

1.9 external interface

The communication platform dynamically loads the Assembly through the configuration file to provide accessible interface services.

1.9.1 mount a device

The device driver module that inherits the IRunDevice interface can be saved to the configuration file through the preparation form. The configuration information includes the program module File and Assembly ID (automatically generated), file name, device type (common device, virtual device), Instance name (namespace and class name), device name, remarks, and so on.

After the device is mounted successfully, you can add the corresponding device to the device management menu of the communication platform. When adding the device, you can select the serial port or network communication mode.

1.9.2 page display

The view display module that inherits the IGraphicsShow interface can save the information to the configuration file through the preparation form. The configuration information includes the program module File, file name, Instance name, and Title name.

A successfully mounted View display module displays an item in the interface View menu. When you click this configuration item, the corresponding view is displayed as a Tab.

1.9.3 external program

You can configure executable applications to the external tool menu and use them as communication platform tools.

1.9.4 data export

The data export module that inherits the IExportData interface can save the information to the configuration file through the preparation form. The configuration information includes the program module File, file name, Instance name, and Title name.

The data export module is not displayed on the page. The platform software automatically loads the instance of the export module.

1.9.5 Application Service

You can save the information of the application module that inherits the IAppService interface to the configuration file through the configuration form. The configuration information includes: program module File, file name, Instance name, title name, service type, and Startup type.

Service types include: Display Mode and hidden mode. Services that display models can display service items in the menu. You can click an event to call the corresponding service form interface to configure and manage services, you can manually start or stop the service in this mode. Services in the hidden mode do not display the service items in the menu. This type of service must be used together with the start type and set the start type to automatic start, the service automatically starts the service when the platform software is started.

The START types include manual start and automatic start. In Manual start mode, services are not automatically started when the communication platform starts. In automatic start mode, services are automatically started when the communication platform starts.

 

Author: QQ: 504547114

QQ group: 54256083

Http://www.bmpj.net

Source Article address: http://www.bmpj.net/index.php? M = article & f = view & id = 2