CN110928569A

CN110928569A - Method for realizing Live Update function of communication equipment

Info

Publication number: CN110928569A
Application number: CN201911144575.XA
Authority: CN
Inventors: 胡海勇; 周宏杰
Original assignee: GUANGZHOU ECI TELECOMMUNICATION CO Ltd
Current assignee: GUANGZHOU ECI TELECOMMUNICATION CO Ltd
Priority date: 2019-11-20
Filing date: 2019-11-20
Publication date: 2020-03-27

Abstract

The invention discloses a method for realizing the Live Update function of communication equipment, which mainly comprises the steps of defining the type of a patch file, defining the installation type of the patch, activating the type of the patch, naming the functions of the patch, realizing the difference between a platform and a CPU, compiling a dynamic library and packaging, activating patch redundancy backup main control multi-process and multi-veneer simultaneously, giving an alarm to a user, prompting an event and the like. The invention can be immediately solved by hot patches for bugs which need to be immediately repaired and can be solved by hot patches, and can be solved by one-time patches when some initialized static global objects need to be increased or decreased; the bug repair of the technical scheme of the invention does not need to release a new version, and has the advantages of short development period, strong test pertinence, short service interruption time, strong maintainability and the like.

Description

Method for realizing Live Update function of communication equipment

Technical Field

The invention relates to a software method of communication equipment, in particular to a method for realizing the Live Update function of the communication equipment.

Background

At present, the mainstream software development process of the communication device is to develop the functions related to the version in a longer period, and release the functions to market clients after sufficient testing, and as a testing laboratory cannot completely cover the application requirements of the clients, there are differences in many aspects, which may be large or small, and these differences include:

1. the network topology is different;

2. the operation environments are different;

3. the configuration sequence is different;

4. the operation periods are different.

The existence of the differentiation can cause software codes and hardware devices to have some test branches which cannot be taken by a laboratory, so that the equipment is abnormally operated. Of course, after a problem occurs, corresponding measures can be taken in time, such as:

1. releasing a new version for the code problem;

2. switching power on and off for the implementation equipment which can be repaired after restarting;

3. resetting the service daughter card according to the service card;

4. and (4) carrying out switching processing aiming at the redundant system and capable of solving switching.

The communication equipment can transmit reliable bandwidth to provide stable service for users. However, the above schemes may bring some obvious or potential service influence to the client in the implementation process, for example, if the whole device needs to be restarted to be repaired or a bug needs to be reset to a single service daughter card to be resolved, the service of the client is interrupted in the period from the restart to the normal operation of the device. It is particularly important and meaningful to develop the implementation of the Live Update function of the communication device in this case.

Disclosure of Invention

The invention aims to solve and reduce the pressure of technical support, research and development, operators and the like, so that when the equipment has bug, the equipment can be repaired under the conditions of less risk and shorter service interruption time as far as possible, and the communication equipment is upgraded under the condition of running of the equipment, so that the problem is solved.

The technical scheme of the invention is as follows:

the invention discloses a method for realizing the Live Update function of communication equipment, which mainly comprises the following steps:

1) defining a patch file type;

2) defining a patch installation type;

3) a patch activation type;

4) the patch function is named;

5) implementation of differences between the platform and the CPU;

6) compiling and packing a dynamic library;

7) patch redundancy backup;

8) the main control multi-process and multi-single board are activated concurrently;

9) user alarm and event prompt.

As a further improvement, the defining of the type of the patch file mainly includes:

1.1) File type out

1.2) File types rbf, bin

1.3) File type Process

As a further improvement, the defining of the patch installation type mainly includes:

2.1) Hot Patch

2.2) arm Patch

2.3) Cold Patches

As a further improvement, the patch activation type of the present invention mainly includes:

3.1) activation (install)

3.2) deactivation (uninstantall)

As a further improvement, the naming of the patch function mainly comprises the following steps:

4.1) naming of generic function Patches

4.2) naming of one-time Patch function

4.3) naming of one-time Patch offload function

4.4) naming of the newly added function in patch

As a further improvement, in the implementation of the difference between the platform and the CPU, the implementation of the difference between the platform mainly includes:

5.1) implementation of Linux operating system platform

5.2) implementation of Vxworks operating system platform

The difference implementation of the CPU mainly comprises the following steps:

5.3) implementation of Power PC architecture

The register r11 in the Power PC is a free register and can be used for temporary storage;

5.4) implementation of ARM architecture

R12 can be used as a jump address in the ARM;

5.5) implementation of MIPS architecture

As a further improvement, the dynamic library and packaging are compiled and packaged as follows:

the generation of the target file is released in the form of a dynamic library, and in order to support the compiled dynamic library to find the address of the primitive function from the version file, the following processing is required:

adding a rdynamic compiling option or an export-dynamic linking option into a main function of the version file;

adding a-fPIC and a shared compiling option when compiling the target file;

and after the dynamic library is manufactured, a packaging compression tool is used for manufacturing a final compression package to be sent to a test or a client.

As a further improvement, the patch redundancy backup of the present invention:

the communication device is provided with two MCPs, wherein the MCPs are redundant and are synchronized to be standby when the patch is activated.

As a further improvement, the master control multi-process and multi-board concurrent activation described in the present invention:

the upper computer (for example, EMS/CLI) may issue a command to activate the patch, and after receiving the command, the communication device (network element) needs to activate other processes (ewp, cfgd, dswp.out, oswp) in the main control in addition to the main process (rcpd), and simultaneously needs to activate the patch on the board when multiple boards are in place, so as to implement concurrent activation.

As further improvement, the user alarm and event prompt of the invention comprises the following steps:

9.1) patch activates a success event;

9.2) a patch installation failure alarm;

9.3) patch Pre-activation failure event.

The invention has the following beneficial effects:

1. 1.1), 2.1), 3.1),4.1),5.1),6), 8) in the technical scheme of the invention, the problem that bug which needs immediate repair and can be solved by hot patch can be solved immediately;

2. the technical scheme 1.2) of the invention, 2.3) and 3.1) can be realized by rbf/bin patches when problems occur in FPGA and the like related to hardware;

3. the technical scheme 1.1), 2.1), 3.1), 4.2), 6), 8) of the invention can realize that when some initialized static global objects need to be increased or decreased, the problem can be solved by one-time patches;

4. the technical scheme 1.1), 2.1), 3.1), 4.4), 6), 8) to realize that some larger functional problems can be solved through the patch because the patch can be newly added with functions and C + + member functions;

5. the technical scheme 8) of the invention can realize parallel activation of the board cards corresponding to the control plane and the data plane, thereby ensuring the management of service and control;

6. the technical scheme 5) of the invention realizes the support of a platform and a multi-CPU architecture, thereby repairing different service board cards when bugs occur;

7. according to the technical scheme 7), as the core data board card is also redundantly backed up, when the core data board card has bug and needs to be solved by cold/arm, the data board card can be reset by one block by combining board card management, so that services are not influenced;

8. the technical scheme 8) of the invention realizes that the embedded device has multiple processes, so that multiple persons are determined to develop each process, and concurrent activation of the multiple processes is supported, so that all guarantees can be provided for the occurrence of bug of the code.

The method for realizing the Live Update function of the communication equipment particularly refers to the online repair of a bug existing in the equipment in the running state of the equipment, wherein the bug comprises an application program bug on a certain process of the embedded equipment, a bug generated by hardware, a bug generated by a BSP (board level upgrade package) driver, a bug of a protocol state machine, even the bug of the Live Update, and the like. The bug is repaired without releasing a new version, and the bug repairing method has the advantages of short development period, strong test pertinence, short service interruption time, strong maintainability and the like.

Drawings

FIG. 1 is a patch function jump diagram;

FIG. 2 is a diagram of functions and patch file writing rules;

FIG. 3 is the assembly instruction mechanism of patch;

FIG. 4 is a compilation of a dynamic library and packing compression;

FIG. 5 is a schematic diagram of a patch file description;

FIG. 6 is a patch redundancy backup;

FIG. 7 is a multi-process and multi-daughter card parallel activation.

Detailed Description

1) defining a patch file type

The following are mainly available:

1.1) File type out

out type patches are for application code, which is software-only, addressing logical business functions. The single board and the master control can have out patches which are distinguished by different file names. out patches are simply compiling files into dynamic libraries.

1.2) File types rbf, bin

rbf refers to some programmable logic devices associated with hardware that control the FPGA; bin refers to an executable program packaged by many scripts and applications. That is, when the bug occurs in the hardware-related code, the bug can be solved through the patch.

1.3) File type Process

In an embedded device taking Linux as a platform, many devices are multi-process and multi-thread devices, and when more codes are involved in modification or the Live Update cannot complete function level replacement, the Live Update of the whole process (process) is supported.

Because the file of the process is large, the size of the process is hundreds of meters, the compiled executable program must be compressed, so that the size of the patch can be reduced, and the memory of the system can be saved.

2) Defining patch install types

For a specific issued patch, the action to be activated by the patch may be specified, which includes the following:

2.1) Hot Patch

By hot hotpatch, it is meant that the function gets repaired as soon as the patch is activated and the function gets replaced.

2.2) arm Patch

The patch means that the MCP and the daughter card can take effect only by performing soft reset, and when the MCP is subjected to soft reset, the service running on the daughter card is not influenced; when the service daughter card is in soft reset, the management level is not affected.

2.3) Cold Patches

The patch means that the MCP and daughter card are hard reset to be valid. Many system initialization codes can be called when the system is reset hard, so that corresponding patch also needs to be reset by cold, and another reason is that some boards do not support soft reset and can only be solved by hard reset.

3) patch active type

The type of patch activation is different from the type of patch installation described in 3), the type of installation affects the reset condition of MCP and daughter card, and the types of activation mainly include the following two types:

3.1) activation (install)

This type indicates that the current patch is to be activated, as for the new patch.

3.2) deactivation (uninstantall)

This type indicates that the previous patch is to be deactivated, for a previously issued patch. Since a previously issued patch may also have a bug or some new function is to be added to the previously issued patch, the uninstantall patch and the new patch of the uninstantall can be taken, so as to achieve the modification of the original patch.

4) Patch function naming

In order to distinguish whether the patch function is a patch function, the name of the function to be patched is modified, which includes the following specific steps:

4.1) naming of generic function Patches

For a normal function to have _ lup _ patch _ as the end of the function, such as an old function being intfunction _ a (int a), then the patch function must be int function a lup _ patch _ (int a).

4.2) naming of one-time Patch function

The one-time patch is called in the process of patch activation and is called only once, has no original function and is newly defined in a new target file.

The function name is fixed to int lup _ init _ once _ lup _ patch _ ().

4.3) naming of one-time Patch offload function

Due to different application occasions, uninstantall may need to be performed on the one-time patch, but if a temporary task is created in the one-time patch, resources such as a memory and a semaphore are applied, and the resources are leaked when the uninstantall is used, an opportunity must be provided to release the resources when the one-time patch is unloaded, specifically, an unloading function of the one-time patch is written when the one-time patch is written.

The offload function of the one-time patch has a fixed name int lup uninstantall lup patch.

4.4) naming of the newly added function in patch

For a newly added function in a patch, the same is written as normal code, but note that the newly added function cannot end with _ lup _ patch _ otherwise it is treated as a patch function.

5) Implementation of platform and CPU differences

For a portability function, support under different platforms with different systems is considered, and the differences comprise system functions, application libraries, CPUs and the like.

The method specifically comprises the following steps:

5.1) implementation of Linux operating system platform

Linux is a multi-process and multi-thread operating system, and needs to consider the situation of multi-process sharing

5.2) implementation of Vxworks operating system platform

Vxworks is a multi-thread operating system with only one process

Because the MCP and the daughter card use different CPUs. The difference in CPU architecture results in different assembly instructions and different CPU sizes and endianness. Therefore, different CPUs need to be processed differently, and the following CPU architectures are specifically provided:

5.3) implementation of Power PC architecture

Big end CPU

5.4) implementation of ARM architecture

Small-end CPU

5.5) implementation of MIPS architecture

Big end CPU

6) Compiling dynamic libraries and packaging

The generation of the target file is published in the form of a dynamic library. In order to support the compiled dynamic library to find the address of the primitive function from the version file, the following processing is required:

the compiling option of-rdynamic or the linking option of-export-dynamic is added to the main function of the version file, and the purpose is to add the function to the dynamic symbol table, so that the functions dlopen (), dlsym () and the like can be successfully loaded through linux dynamic loading.

When compiling the target file, a compiling option of-fPIC and-shared is added, so that the target file is a dynamic library.

After the dynamic library is manufactured, a packaging compression tool can be used for manufacturing a final compression package to be sent to a test or a client.

7) Patch redundancy backup

In order to improve the stability and reliability of the system, the product needs to be redundantly backed up during design, that is, two MCPs are provided, namely, the MCP has a main backup function. When a patch is activated, the active master of the current work is activated, and the standby MCP also needs to be activated, so that the active and standby patches are consistent when the MCP is switched, and the functions are also consistent.

8) Master control multi-process and multi-veneer parallel activation

For embedded communication equipment which is usually multi-process, at present, main process equipment sends to a plurality of slave process equipment through a message queue, thereby realizing the concurrent activation of the multi-process. The supported processes are:

rcpd (management process of device, also main process of activating patch), cfgd (configuration process, responsible for data management), ewp (configuration process responsible for routing, also core process of CFPAL), oswp (data plane protocol process), dswp.out (control plane protocol process)

9) User alarm, event prompt

To improve friendliness, a prompt is needed for the successful or failed activation of the patch so that the developer can view it in the first place. Furthermore, due to the complexity of the field application (such as over-high CPU utilization, insufficient memory usage, etc.), the tested patch may fail during field deployment, so that it is necessary to combine alarms and events to notify the user of the activated state of the patch, thereby taking some measures.

9.1) patch activates a success event;

9.2) a patch installation failure alarm;

9.3) patch Pre-activation failure event.

The technical scheme of the invention is further explained in detail by specific embodiments in the following description and the accompanying drawings of the specification:

firstly, English abbreviations in the technical scheme are described in a list:

english abbreviation	DETAILED DESCRIPTIONS
		MCP	Master control card
CLI	Command line interface
		Live Update	Online upgrade and update
PPC	CPU processor
		MIPS	CPU processor
ARM	CPU processor
		Vxworks	Wind and river operating system
Linux	Embedded operating system
		Patch	Patch with a flexible patch
TA	Influencing a service
		Bug	Program error
ELF	Executable connection file format
		BootScok	Internal file transfer protocol
rcpd	Master managed Process name
		cfgd	Process name for master configuration
DSWP.out	Process name for protocol processing

The invention discloses a method for realizing the Live Update function of communication equipment, which mainly comprises the following functions:

1) defining types of patch files

1.1) File type out

1.2) File types rbf, bin

1.3) File type Process

2) Type of patch installation

2.1) Hot Patch

The core of the patch is function jump, which has a great relationship with the name decoration of C language, because the function jump presupposes that symbol tables before and after patch are found.

The symbol table is different for C and C + + codes, with the specific difference:

the symbol table of the C code is the same as the symbol of the actual code, and other symbols are not added at the beginning and the end of the C code for modification; the C + + symbol table is inconsistent with the C + + common function and the C + + member function, the C + + common function starts with _ Z and then is added with a function name, the C + + class member function is added with _ ZN in front of the original function, the C + + symbol modification is also related to the function parameter, and the C + + symbol table is also an important reason for the C + + realization of function reloading.

The name of the function is modified when the code is compiled, and the compiler determines that the name of the patch function is also modified when the patch function is compiled, so that the symbol table of the original function can be found through the patch function.

The jump diagram of the function is shown in fig. 1. The normal flow is that function a calls function B, but now function B has Bug, function B must be modified and patch is issued, and when hot patch is activated, the call flow of function becomes function a call B _ lup _ patch _ ().

2.2) arm Patch

2.3) Cold Patches

3) patch active type

3.1) activation (install)

3.2) deactivation (uninstantall)

4) Patch function naming

4.1) naming of generic function Patches

4.2) naming of one-time Patch function

4.3) naming of one-time Patch offload function

4.4) naming of the newly added function in patch

As shown in FIG. 2, the function and the patch file writing rule describe specific contents. If the function a in the file file.c has Bug, the function and file can be written as follows:

a new file is started and named file _ patch.c, and then the function a _ lup _ patch _ is contained therein.

5) Implementation of platform and CPU differences

5.1) implementation of Linux operating system platform

5.2) implementation of Vxworks operating system platform

5.3) implementation of Power PC architecture

5.4) implementation of ARM architecture

5.5) implementation of MIPS architecture

The difference of the CPU architecture corresponds to the difference of the assembly instruction, and the assembly code of a specific function can be checked through a linux command obj dump.

By disassembling a function, the entry that can get a function is composed of many assembly codes, and the first 4 assembly instructions of the entry function are jump instructions, so that after obtaining this information, the previous assembly instructions can be modified so that the assembly codes of the function are replaced.

As shown in FIG. 3, the assembly instruction mechanism of patch. After the dynamic library is loaded, the address of the patch function B _ lup _ patch _ can be obtained, then the address of the original function B corresponding to the patch function can be obtained by stripping 11 characters _ lup _ patch _ in the patch symbol table, and after two addresses are obtained, the first 4 assembly instructions of the original function B can be modified according to different CPU architectures.

6) Compiling dynamic libraries and packaging

When compiling the object file (object), the C and C + + compiling options are needed, so that the source code is dynamic and can be found by other external codes, and the other code is required to be unrelated to the position, so that a plurality of processes can share code segments, and memory resources are saved.

FIG. 4 shows a process of compiling a target file into a dynamic library and packaging the dynamic library into a compressed file. The patch file is compiled into a target file (e.g., A.o), then the target file A.o is compiled into dynamic libraries after compiling options are added, and then each dynamic library can be packaged and compressed into a bg _ patch.

In the packing process, each patch can be described, so that what problem the patch solves can be clearly known, the problem corresponds to what problem sheet number, the installation of the patch can not affect the service, if the influence is caused, the patch can be timely prompted to a client, and meanwhile, for multi-process patches in the main control, the problem needs to be specified to be solved on which process, what network element the patch corresponds to, what version on the network element and the like. This allows for efficient tracing of problems and for correct installation of the patch. Specifically, the description of each patch in the patch file description diagram shown in fig. 5 is described. Bat script can be clicked after the description is completed, and then the last compressed packet bg _ patch.

7) Patch redundancy backup

As shown in fig. 6, the patch redundancy backup refers to backup on an MCP, because the device has two MCPs, the active rcpd synchronizes the patch to the standby MCP board card through the ftp module, and after synchronization is completed, a message is sent to the standby board card to tell it to activate the patch, and after receiving the message, the standby MCP board card activates the patch flow in accordance with the active MCP.

8) Master control multi-process and multi-veneer parallel activation

Currently, there are multiple processes hosted in a communication device, and only one process on a service daughter card. Multiple processes and multiple daughter cards are activated in parallel as shown in fig. 7. After rcpd receives the activation command issued by EMS/CLI, rcpd tells other processes on the main control through the pipeline, such as esd, cfgd, DSWP. So that the patch is activated on the respective process or daughter card.

When a single board needs to activate a patch, the first step is to download the patch file from the main control to the single board. The downloading process is divided into two types, one is a running state and the other is a boot state.

And in the running state, the board polling module is responsible for polling the inconsistent versions and upgrading the versions when the versions are inconsistent. When patch is activated, rcpd on the master MCP has a version number that includes the normal big packet version number and the patch number. When the patch is not activated, the daughter card only has the version number of the big packet and does not have the version number of the patch, so that the version numbers of the daughter card and the MCP are inconsistent, and when the board management module polls the inconsistency, the patch upgrading is performed on the daughter card. The versions of the master control and the daughter cards are consistent after upgrading.

The startup state refers to the process of the daughter card obtaining the patch from the master test at the daughter card resetting stage. This process uses bootsock, which is an internally defined proprietary protocol that distinguishes between each board via IDPROM.

9) User alarm, event prompt

9.1) patch activates a success event;

9.2) a patch installation failure alarm;

9.3) patch pre-activation failure event;

the pre-activation of the patch corresponds to an immediate activation, which may set a minimum time for service interruption, and then automatically activate the patch after the time.

Examples

When a problem occurs, research and development need to analyze that the bug can not be solved through the patch, if the bug can be solved through the patch, then the bug is made into hot, arm or cold, and meanwhile, the analysis can not affect the service. The following takes the example of the occurrence of a bug at bsp _ vrrpstattussipdateinit () within the file vrrp _ opt.c:

first, because this is code on an application, it can be defined that this is an out patch that can attribute the patch as an MCP board out, which can be named bg _ patch _ MCP _ vc _ v1.out, according to 1) defining the type of the patch file. Since bsp _ vrrpstattussuuppateinit is an initialized function that must be reset to take effect, a patch can be defined as a arm patch according to 2) defining the type of patch installation. The purpose is to modify this function so the activation type of this patch can be set to install patch according to 3) patch activation type. This function to be modified exists in the original version, not as a newly added function, nor as a one-time patch function, and may be named bsp _ vrrptatus update _ lup _ patch _ () according to the naming of the normal function patch in 4) patch function naming. For a particular patch, the platform and CPU on which the patch is to run are known with certainty, this time 5) the Linux operating system platform in the implementation of the differences in the platforms. The CPU architecture of the MCP platform is the Power PC architecture, and the CPU architecture is processed according to big-end byte order in the Power PC. Then the dynamic library and the package can be compiled according to 6), and the compressed file bg _ patch. The patch can be activated by a test or a client, and during the activation, the patch is synchronized to the backup MCP 7) for the redundant backup of the patch, and simultaneously, the rcpd process is given to the activated patch in 8) the concurrent activation of the master control multi-process and the multi-board. After the activation is successful, the successful activation event of patch can be obtained according to 9) user alarm and event prompt.

The above description is not meant to be limiting, it being noted that: it will be apparent to those skilled in the art that various changes, modifications, additions and substitutions can be made without departing from the true scope of the invention, and these improvements and modifications should also be construed as within the scope of the invention.

Claims

1. A method for realizing the Live Update function of communication equipment is characterized by mainly comprising the following steps:

1) defining a patch file type;

2) defining a patch installation type;

3) a patch activation type;

4) the patch function is named;

5) implementation of differences between the platform and the CPU;

6) compiling and packing a dynamic library;

7) patch redundancy backup;

9) user alarm and event prompt.

2. The method according to claim 1, wherein the defining of the type of patch file mainly comprises:

1.1) file type out;

1.2) file types rbf and bin;

1.3) File type Process.

3. The method of claim 1, wherein the defining of the patch installation type mainly comprises:

2.1) hot patching;

2.2) a rom patch;

2.3) cold patch.

4. The method of claim 1, wherein the type of patch activation mainly comprises:

3.1) activation (install);

3.2) deactivation (uninstantall).

5. The method for implementing the Live Update function of the communication device according to claim 1, wherein the naming of the patch function mainly comprises:

4.1) naming of common function patches;

4.2) naming of the one-time function patch function;

4.3) naming of one-time patch offload function;

4.4) naming of the newly added function in patch.

6. The method of claim 1, wherein in the implementation of the difference between the platform and the CPU, the implementation of the difference between the platform mainly includes:

5.1) realizing a Linux operating system platform;

5.2) realizing a Vxworks operating system platform;

the difference implementation of the CPU mainly comprises the following steps:

5.3) the implementation of the Power PC architecture;

5.4) realizing ARM architecture;

r12 can be used as a jump address in the ARM;

5.5) implementation of MIPS architecture.

7. The method of claim 3, wherein the compiling dynamic library and packing comprises:

adding a-fPIC and a shared compiling option when compiling the target file;

8. The method of claim 3, wherein the patch redundancy backup comprises:

9. The method for implementing the Live Update function of the communication device according to claim 3, wherein the master control multi-process and multi-board are concurrently activated:

the upper computer (EMS/CLI) will issue a command to activate the patch, and the communication device (network element) needs to activate other processes (ewp, cfgd, dswp.out, oswp) in the main control besides the main process (rcpd), and simultaneously activate the patch on the board when a plurality of boards are in place, so as to implement concurrent activation.

10. The method of claim 4, wherein the user alarm and event prompt comprises:

9.1) patch activates a success event;

9.2) a patch installation failure alarm;

9.3) patch Pre-activation failure event.