Share the design of a distributed monitoring and remote control program for communication with hardware (on: automatic upgrade and asynchronous events)

1 remote distributed monitoring and control system design overview

1.1 Overview

The system consists of communication servers, web management platforms, Message Queue servers, and database servers. Here, I will describe the following content in this article.

(1) dynamic deployment (automatic upgrade) based on osgi. NET and modular development method: the entire system is managed by the Web PlatformArticleIs not described in detail) and communication server composition, consists of five software developers collaborative development (several hardware development engineers), there are currently deployed in multiple regions.

(2) visualized Message Display Based on Asynchronous events: In the communication mode, there is a monitoring information used to display the system communication process, this monitoring information is of great help to software development/debugging and hardware development/debugging. It can display the execution process of each communication instruction in detail, facilitate collaboration and error elimination between software development engineers and hardware development engineers;

(3) roundtrip-based communication protocol design: the communication protocol layer only implements the communication between the server and the hardware. The communication between the hardware and the server is composed of one roundtrip, roundtrip indicates a round-trip session, that is, either the server sends a response to the hardware, or the hardware sends a response to the server, and the roundtrip session is an atomic session, that is, the communication service plug-in must have a roundtrip queue for sorting communication rules to ensure that roundtrip cannot be crossed;

(4) Implementation of COM/VPN/LAN/GPRS/3G communication mode: the communication mode is based on the communication protocol layer, that is, the communication protocol is universal. The implementations of these communication methods are different. I will describe their respective implementations later.AlgorithmAnd how to ensure data is thread-safe.

(5) Implementation of Remote Control Based on rabbitmq: The entire monitoring platform has a large load. Therefore, we use distributed/multi-service methods to achieve this, here I will describe the system architecture and the implementation of Distributed Remote Communication;

(6) communication protocol testing: this is also one of the highlights of this communication server. Communication Protocol testing usually needs to be associated with hardware, which is very troublesome ~, Here, I use unit testing + serial simulation to ensure the correctness of the communication protocol, and the same unit test can still be used to ensure different communication methods.

1.2 Communication Server Interface

(1) splashform, check plug-in updates, and load startup plug-ins

(2) VPN/LAN communication/GPRS/3G communication/COM Communication

 

1.3 web management platform Interface

2 dynamic deployment based on osgi. net

2.1 osgi. Net-based project overview

The following are communication servers:ProgramBased on osgi.. NET Framework (you can download this SDK through iopenworks.com for free). It is developed using plug-ins and built by osgi. net built-in system plug-ins and a general outlook style winform interface framework plug-in (you can get this plug-in with the following address, free and open source, http://www.iopenworks.com/Products/ProductDetails/Introduction? Proid = 8) and custom plug-ins.

Custom plug-ins include:

(1) log plug-in, which implements detailed logs based on log4net;

(2) Message Queue contract/Message Queue Service plug-in, which implements distributed communication based on the message queue Communication Server and can receive remote control commands from the Web management platform;

(3) Communication Server plug-in, which is the core of the entire system. It defines the basis class of the communication protocol and implements Communication Based on COM, VPN/LAN, GPRS/3G, etc, this communication plug-in is designed very cleverly. It uses the same protocol to be compatible with multiple communication modes and isolates the differences between different communication modes based on the layered mode.

The following is a Web Management Platform project, which is also built based on osgi. NET and consists of 25 custom plug-ins, including several system plug-ins and communication contracts and service plug-ins. The Web management platform provides hardware configuration, management, data collection, report analysis, and remote control.

2.2 dynamic deployment

In this system, the involved personnel include hardware development engineers, hardware engineers, testers, and on-site implementers. The system will be deployed based on various communication methods and will be deployed on a large scale in the future. Before using dynamic deployment, developers need to independently release the plug-in for each program update, and then send the plug-in to hardware development engineers, testers, and field implementers, the entire process will need to be repeated n times, which is not only tedious but also prone to errors. In addition, after the project is officially deployed, several changes have been made. Each change requires remote logon to N servers for program upgrade. Therefore, we use the dynamic deployment technology of osgi. net. Based on the open factory iopenworks.com, We can uniformly publish various test versions of the software through the plug-in repository. Once the plug-in update is released, several tested/deployed applications will be synchronously updated. The following describes how to implement dynamic deployment through iopenworks.com.

2.2.1 release plug-ins

(1) enter the http://www.iopenworks.com website, and then log on as admin.

(2) Click "plug-in repository". Here, you can select Add plug-in, edit/delete/upgrade plug-in, and edit plug-in category.

(3) on this page, click the Add plug-in icon. The instructions are as follows.

2.2.2 release plug-in updates

Go to the http://www.iopenworks.com website, then log in as admin, go to plug-in repository, on this page, click the upgrade plug-in icon, upload the new plug-in version file here and click Save.

2.2.3 release osgi. Net kernel update

Log on as an administrator and click "plug-in repository". On the page, click the "Kernel File" link to modify the Kernel File.

Click the "edit" icon to upload a new kernel file. In this way, applications based on osgi. Net can be automatically updated.

2.2.4 the program executes osgi. Net kernel update

The osgi. NET application provides the kernel update function through the uishell. iopenworks. bootstrapper assembly, as shown below.

Kernel File updateCodeAs follows.

2.2.5 automatically update plug-ins

There are two types of plug-in upgrades: (1) update through the plug-in center; (2) create a new plug-in for automatic update.

You can use the plug-in center to view the available plug-ins and perform the upgrade action.

In addition, you can create a new plug-in for automatic update. The method is described as follows:

(1) Add a dependency on uishell. bundlemanagementservice.

(2) Add a reference to the uishell. bundlemanagementservice. dll assembly and change the copy local attribute to false.

(3) implement automatic update in the plug-in activator. First, create a service tracker and then listen to service change events. when the service is available, perform automatic upgrade.

3. Visualized message display Tracking Based on Asynchronous events

The Communication Server plug-in implements communication with the hardware system and communicates with the hardware. debugging is very troublesome in the initial stage. In order to locate problems and view the running status of the system, it is necessary to display the execution of the system in real time, as shown below.

There is a monitoring console that displays the message packages for each session and displays the communication process with the hardware in the correct sequence. Here, I designed a tracing-related class and an asynchronous event distributor. The class diagram is as follows.

First, I designed an itrackable interface to output messages synchronously or asynchronously. The specific implementation is as follows.

Using system; using system. collections. generic; using system. LINQ; using system. text; namespace uishell. commserverservice {public class traceeventargs: eventargs {Public String message {Get; private set;} public traceeventargs (string message) {message = message ;}} /// <summary> /// collect session trace debugging information. /// </Summary> Public interface itrackable {/// <summary> // Add an event to debug information. /// </Summary> event eventhandler <traceeventargs> ontracemessageadded; bool trackable {Get; Set ;}/// <summary> /// session trace ID. /// </Summary> int trackerid {Get; Set ;}/// <summary> // parent session trace debugger. /// </Summary> itrackable parenttracker {Get; set;} void trace (string message); void dispatchasynctracemessageaddedevent (Object sender, traceeventargs E); void handle (Object sender, traceeventargs e );}}

Then an event distributor is designed. The event distributor can be used to distribute a synchronous/asynchronous event. If a synchronous event occurs, the dispatcher directly calls the event processing function. If the event is asynchronous, add the modified call as an asynchronous call item to the queue of the asynchronous event call thread. The key code is an eventthread, which is responsible for queuing and calling asynchronous events. Its implementation is as follows.

/// <Summary> /// asynchronous event dispatching thread. /// </Summary> class eventthread {private thread _ dispatcherthread; private queue <eventthreaditem> _ queue; private object _ lockobject; private autoresetevent _ waitevent; private bool _ isexited; /// <summary> /// start a thread to execute event dispatch. /// </Summary> Public eventthread () {_ lockobject = new object (); _ queue = new queue <eventthreaditem> (); _ waitevent = new autoresetevent (false ); _ dispatcherthread = new thread (New threadstart (dispatch); _ dispatcherthread. name = "eventdispatcherthread"; _ dispatcherthread. start () ;}/// <summary> /// if the dispatch list is empty, the thread is paused. /// </Summary> Public void dispatch () {eventthreaditem item; while (! _ Isexited) {Monitor. enter (_ lockobject); If (item = POP () = NULL) {Monitor. exit (_ lockobject); // if there is no event to be processed, the event is blocked here. If the returned result is blocked, the peek will continue, and the next Peek will get the data _ waitevent. waitone (); continue;} monitor. exit (_ lockobject); If (item! = NULL) {syncdispatcheventitem (item) ;}}/// <summary> // insert an event item to wake up the thread. /// </Summary> /// <Param name = "item"> </param> Public void push (eventthreaditem item) {lock (_ lockobject) {_ queue. enqueue (item);} Try {_ waitevent. set () ;}catch {}/// <summary> /// retrieve an event item. /// </Summary> /// <returns> </returns> Public eventthreaditem POP () {lock (_ lockobject) {return _ queue. Count> 0? _ Queue. dequeue (): NULL ;}}}

 

The allocation of this event is asynchronous, that is, if a message is added to the listener, the original communication thread does not need to be blocked when the interface is refreshed.

 

The previous part of this article describes the design of communication protocols, which are also the core part of this article.