CN110008044B

CN110008044B - Method for constructing distributed real-time communication middleware on embedded RTOS

Info

Publication number: CN110008044B
Application number: CN201910287484.5A
Authority: CN
Inventors: 肖瑾; 朱志伟; 胡晓光; 贾海恩; 刘相君
Original assignee: Beihang University
Current assignee: Beihang University
Priority date: 2019-04-11
Filing date: 2019-04-11
Publication date: 2021-03-23
Anticipated expiration: 2039-04-11
Also published as: CN110008044A

Abstract

As a kind of distributed communication middleware, DDS (Data Distribution Service) is currently applied on the PC side, and the deployment of data distribution services on embedded platforms, especially real-time operating systems such as VxWorks, is an existing technology. blind spot. But in the real-time embedded system, the good distributed data distribution characteristic of DDS has a lot of room to play, and has a huge market application prospect. In order to meet the needs of the current market for distributed data distribution functions in real-time embedded platforms, and at the same time to solve the above-mentioned technical problems, the present invention proposes a distributed real-time communication center constructed by using RTI Connext DDS on the VxWorks6.6 embedded real-time operating system. how to build the piece. By building a cross-compilation environment in Linux, the DDS source code is compiled, and the generated library file is configured to implement system calls through Wind River Workbench. In addition, the configuration of each entity of DDS and QoS is realized by means of xml file, and the generated code provides API for other components to call.

Description

Method for constructing distributed real-time communication middleware on embedded RTOS

Technical Field

The invention relates to development of a real-time embedded operating system and distributed data distribution service, in particular to a method for constructing a distributed real-time communication middleware on an embedded RTOS.

Background

The DDS (data Distribution service) data Distribution service is a new generation of distributed real-time communication middleware technical specification made by an Object Management Group (OMG) on the basis of standards such as HLA (high level architecture) and CORBA (common object architecture). The DDS adopts a publish/subscribe architecture (DCPS) model, emphasizing data as a center, in which an application uses a specific API to establish a corresponding DDS entity, and further uses the entity to implement data communication in a publish/subscribe mode. Meanwhile, the DDS provides rich QoS service quality strategies, can ensure that data can be distributed efficiently and flexibly in real time, and can meet the application requirements of various distributed real-time communication.

The VxWorks real-time operating system is an embedded real-time operating system (RTOS) designed and developed by Windriver corporation in 1983 in the United states and is a key component of an embedded development environment. The embedded real-time operating system has good continuous development capability, a high-performance kernel and a friendly user development environment, and occupies a place in the field of embedded real-time operating systems. The method is widely applied to the fields with high-precision technologies such as communication, military, aviation, aerospace and the like and extremely high real-time requirements by virtue of good reliability and excellent real-time performance.

Because the VxWorks system has no good desktop type interactive environment, even does not have a perfect Shell system similar to the Unix system, for the operation of the VxWorks system or the deployment of corresponding component drivers, the kernel source code needs to be relatively deployed and modified, and compiling and importing are performed through a command line or professional software, so that the research and application of the related middleware of the VxWorks system are relatively less. In addition, the DDS is a set of data interaction protocols based on ethernet, and the RTI company implements the protocols, but does not form a complete middleware that can be directly deployed and used, and only provides support for source codes and library files of related functions such as transmission, reception, QoS, and the like. In actual use, a source file and a library file need to be imported into a project, and in addition, the construction work of a very complex compiling environment is completed, and then the source code can be compiled. It is also relatively difficult to configure DDS in a current common Windows or Linux system, and particularly, deployment of data distribution service under a real-time operating system such as VxWorks is a blind area in the prior art.

But the good distributed data distribution characteristic of the DDS in the real-time embedded system has a large play space. Under the heavy stream of big data and the Internet of things, the networking communication of the embedded terminal and the real-time interaction of a large amount of data have huge market application prospects.

Disclosure of Invention

In order to meet the requirement of the current market on the distribution function of distributed data in a real-time embedded platform and solve the technical problem, the invention provides a construction method of a distributed real-time communication middleware on an embedded RTOS.

The distributed real-time communication middleware on the embedded RTOS is constructed on a VxWorks6.6 embedded real-time operating system by utilizing an RTI (real time desktop) DDS, wherein the middleware entity comprises a Domain Participant (Domain Participant), a theme (Topic), a Publisher (Publisher) and a Data Writer (Data Writer), a receiver (Subscriber) and a Data receiver (Data Reader), a QoS (quality of service) strategy and the like; the middleware composition file comprises a sending source code, a receiving source code, a DDS static link library, a DDS source code, a data type conversion source code and an xml middleware configuration file.

The interactive mode of the distributed real-time communication middleware on the embedded RTOS can not only specify the attribute of each entity, define the data structure or rewrite the QoS policy through the rewriting of a specific node in the configuration file of the XML middleware, but also realize the functions through a specific calling function interface in the middleware in a program, and can realize cross-language, cross-platform and cross-system data real-time distribution service through receiving the calling of a sending function.

In the invention, a distributed real-time communication middleware is constructed by utilizing RTI (real time interface) Next DDS (direct digital synthesis) on a VxWorks6.6 embedded real-time operating system, and as shown in the attached figure 1, the construction method comprises the following steps:

step S1: compiling source codes related to data distribution service in the RTI context DDS to generate a DDS link library file matched with an embedded RTOS (real-time operating system) VxWorks6.6 system.

Step S2: and importing the link library file of the DDS by utilizing a development environment Wind River Workbench of VxWorks6.6, and completing configuration of related kernel components and environment variables.

Step S3: the QoS strategy in the DDS is configured by utilizing an XML file, and two transmission modes are realized: a sampling mode and a queue mode. The sampling mode is applied under the condition that the requirement on whether the data packet is lost is not high by taking transmission efficiency as priority; the queue mode ensures that all data sent can be received, and is suitable for the condition with higher requirement on data integrity.

And parameter configuration is carried out on Domain participators (Domain participants), topics (Topic), publishers (publishers) and Data writers (Data writers) entities, receivers (subscribers) and Data writers (Data readers) in the Domain participators, and Data structures corresponding to the topics are registered.

Step S4: and importing the XML file in the step S3 by using a Code Generator tool of Utilities in the RTI Launcher, automatically generating related codes, and adding the codes into a development environment of the Wind River Workbench, wherein related function APIs such as sending and receiving can be called by other function modules.

Drawings

FIG. 1 shows a flow chart of a construction method

FIG. 2 is a diagram of a method for modifying API layer of makefile

FIG. 3 is a diagram of a method for adding workflow macro definitions

FIG. 4 is a diagram of a method for checking macro definition in BuildTool

FIG. 5 is a diagram of a method for adding a compiler file to a Workbench

FIG. 6 is a method diagram for adding DDS library files in Workbench

FIG. 7 is a diagram of VxWorks component adding method in Workbench

FIG. 8 Generation code Diagram for the Generator tool

Detailed Description

The following describes a specific embodiment of the present invention with reference to the drawings.

The invention utilizes RTI Next DDS to construct a distributed real-time communication middleware on a VxWorks6.6 embedded real-time operating system, and the construction method comprises the following steps:

Step S1.1: modifying RTI Context DDS root directory makefile

A makefile exists in the root directory of the DDS source code, and the makefile is used for compiling and generating a DDS link library. This file makes a deployment of the structure of the DDS source file to be compiled and requires that a set of modules exist in the form of a folder. The DDS runs in the VxWorks system in C/C + + language, see fig. 2, and at the API level, the contents other than DDS _ c.1.0 and DDS _ cpp.1.0 are annotated away. As such, the compiled linked library will include files at dds _ c.1.0 and dds _ cpp.1.0 in addition to the files at core folder core.1.0. For embedded platforms supporting other languages, the API in the relevant link library file can be selected according to the adopted programming language when in use.

Step S1.2, modifying related configuration file personal

Step S1.2.1: mk file records various environment variables used for compilation. The value of the environment variable OS _ ARCH corresponds to an operating system matched with the link library, the default environment is ia86linux 2.6, the default environment can be annotated, and a statement is added:

export OS_ARCH＝pentiumVx6.6gcc4.1.2

the OS _ ARCH identifies environment information in which the compiled linked library runs. After the source code is compiled successfully, a compiled file will be generated under the/core.1.0/lib/$ (OS _ ARCH) directory. Where Pentium vx6.6gccc 4.1.2 represents that the link library runs on the vxworks6.6 platform, using a Pentium type BSP with a gcc version of 4.1.2.

Step S1.2.2: the environment variable WAVEWORKSHOME represents the path of the DDS source code and modifies the path into the actual path of the DDS source code, such as

export WAVEWORKSHOME＝/home/admin/ndds500-buildsrc。

Step S1.3, modifying the source code generation file pentium Vx6.6gCC4.1.2.mk

Step S1.3.1: the source code generation file pentium Vx6.6gCC4.1.2.mk is located in resource.2.0\ makehome folder under the source code directory. It can be seen in the Makefile of BSP that the CPU corresponding to the BSP used in the present invention is Pentium4, and there is no corresponding source generated file in the target, so in the Pentium vx6.6gccc 4.1.2.mk file, the CPU type needs to be modified from the original Pentium to Pentium 4.

Step S1.3.2: and modifying variables WIND _ BASE and WIND _ HOME related to the VxWorks development environment workbench. The default values are:

export WIND_HOME＝/local/VxWorks/GPP-3.6

export WIND_BASE＝/local/VxWorks/GPP-3.6/vxworks-6.6

and modifying the default value into an actual installation directory of the workbench.

And then adding a compiling head file path under the C and C + + compilers:

-I/home/admin/WindRiver/gnu\4.1.2-vxworks-6.6\lib\gcc\i586-wrs-vxworks\4.1.2\include

s1.4, building a cross compiling environment based on a Linux operating system

In the invention, compiling environment configuration is carried out according to a source code generation file pentium Vx6.6gCC4.1.2. mk. And in a Linux operating system environment, compiling according to the modified makefile to generate a DDS link library.

And installing a Linux operating system in the VMware, decompressing the DDS source code, installing a VxWorks system Development environment, and starting a VxWorks Development shell, namely completing the construction of the cross-compiling environment.

Step S1.5, compiling DDS link library

The following instructions are entered in the VxWorks653Development shell:

Cd/home/admin/WindRiver

./wienv.sh–p vxworks6.6

Cd/home/admin/ndds500-buildsrc

Make PentiumVx6.6gcc4.1.2

and a first sentence of the instructions switches the current directory to the folder where the installed VxWorks is located, and then the second sentence is used for opening the wrenv. And next, switching the directory to a folder where a DDS source code is located, and finally executing a make instruction on a source generation file pentium Vx6.6gccc 4.1.2.mk to generate a DDS link library file which can be used in a VxWorks6.6 system.

The generated link library file has a core part positioned in a source code directory core.1.0\ lib \ pentium Vx6.6gCC4.1.2 and API parts positioned in dds _ c.1.0\ lib \ pentium Vx6.6gCC4.1.2 and dds _ cpp.1.0\ lib \ pentium Vx6.6gCC4.1.2.

And step S2, importing the link library file of the DDS by utilizing the development environment Wind River Workbench of VxWorks6.6, and completing the configuration of the related kernel component and the environment variable.

In the invention, the VxWorks6.6 development environment is Wind River Workbench, and corresponding configuration needs to be carried out in the VxWorks system when a DDS is used in the VxWorks system.

Step S2.1: adding macro definitions

Referring to fig. 3, a makefile is found in the BSP corresponding to the embedded platform, and a macro definition is added thereto:

EXTERN_DEFINE＝-DFAST_REBOOT–DRTI_VXWORKS

as shown in FIG. 4, the BSP is recompiled, the property dialog box is opened according to the project built by the compiled BSP, and whether the macro definition is correctly added is checked at Build Properties, namely Build Tools.

Step S2.2: adding a Linked library File Path

In the project created in step S2.1, as shown in fig. 5, the property page is opened, and the directory where the LINK library generated above is located is added at the Build Properties — Build robots — LD _ LINK _ PATH. The edge button is clicked at LD _ LINK _ PATH, and then the address is added thereto.

Step S2.3 adding library file directory

And opening the property page of the project established in the step S2.1, and adding the address of the DDS library file at the Build Properties-Build pages as shown in the attached figure 6. An example of an address is:

D:\RTI\ndds.5.0.0\include

D:\RTI\ndds.5.0.0\include\ndds

s0604 adding VxWorks component

Step S2.4: adding kernel components

Referring to FIG. 7, the Kernel Configuration page of the project built in S0601 is opened, and the operating system components- -Real Time Process components are selected, and the components are added to the project.

Step S3.1: setting QoS parameters

QoS policies are methods used by applications to control, manage and optimize the flow of data transmitted in a network, which can be viewed as a contract between a data provider and a receiver. The entities in the DDS all have default QoS policies, and when not modified, the application will implement communication between the entities according to the default QoS policies.

The corresponding functions are realized through corresponding settings of History, Reliability and Resource _ limits:

the History (History) policy describes the number of data samples that should be kept in the buffer when the DDS is used to effect the transfer of data. The reserved category is set by the kid parameter, ALL reservations (DDS _ KEEP _ ALL _ HISTORY _ QOS) can be selected, and the LAST N reservations in the HISTORY data (DDS _ KEEP _ LAST _ HISTORY _ QOS) can be selected, wherein the N is determined by the depth parameter. The default setting of the history policy is to keep the last history data, i.e. the value of N is set to 1.

Historical policies in QoS dictate the number of sample data retained. For data writers, these samples will be stored until the publisher sends them to the opposing data writer. For a data reader, after receiving the data, the data will be retained until the application retrieves the data. The policy applies to the subject, data reader and data writer entities through the history member of the QoS structure.

The reliability (reliability) policy describes the reliability of data transmission using DDS, and includes two sub-parameters, reliability category and duration, respectively. Wherein kind is divided into a reusable and a best effort.

If the reliability type kid is set as the default best effort, the transmission of the data takes the transmission efficiency as the primary factor, and the method is suitable for data transmission with high real-time requirement on the data. If the data requiring transmission cannot be missed, the kid value should be set to valid.

The persistence (duration) is effective only when the kind of reliability kind is set to enable. In this case, the data writer will retain the message that has been sent until notified by the data reader to confirm that the message has been received, and will not remove the retained message. If not notified by the data reader, the data is retransmitted until received.

The reliability policy applies to the subject, data reader and data writer entities.

The RESOURCE restriction (RESOURCE _ LIMITS) policy describes the local storage space that needs to be consumed when using DDS to pass through, and the declaration of the RESOURCE amount is implemented by the RESOURCE _ LIMITS member.

The resource restriction policy applies to topics, data readers, and data writers.

The functions are realized through corresponding settings of History, Reliability and Resource _ limits. Under the QoS default setting, the transmission of data can implement the sampling mode, and to implement the queue mode, the QoS policies of the subject, the data writer, and the data reader need to be set, as shown in table 1 and table 2.

TABLE 1 topic and data reader QoS policies

TABLE 2 data writer QoS policies

Step S3.2: setting DDS-related entity parameters

DDS related entities include Domain Participant (Domain Participant), Topic (Topic), Publisher (Publisher) and Data Writer (Data Writer) entities, recipient (Subscriber) and Data Writer (Data Reader). And configuring the parameters of each entity by using the XML file, and registering a data structure corresponding to each Topic.

Step S3.2.1: the data structure is registered by using an XML file, and the data format needs to be rewritten according to a certain format, for example:

step S3.2.2: binding of data structures is done for related Topic (topics) in domains, for example:

step S3.2.3: data structure binding is performed on datareader and datawriter, for example:

and S4, importing the XML file in the step S3 by using a Code Generator tool of Utilities in an RTI Launcher, automatically generating related codes, and adding the codes into a development environment of a Wind River Workbench, wherein related function APIs such as sending and receiving can be called by other function modules.

Step S4.1: as shown in FIG. 8, the XML file written in step S3 is placed in a Code Generator tool using Utilities in RTI Launcher, and the relevant Code can be automatically generated after running.

Step S4.2: and copying and pasting the code generated in the step S4.1 into a corresponding project directory, refreshing a resource panel in the development environment of the Wind River Workbench, and finding the generated code.

Step S4.3: and modifying the generated code, exposing the function interface to the outside, and declaring the function. The cycle monitoring function of the DDS needs to be set as a task, and occupies a process space independently, otherwise unexpected errors such as insufficient memory space, task blockage and the like easily occur.

After the above steps are deployed, the DDS can be sent and received in other components by means of function call.

Claims

1. a construction method of distributed real-time communication middleware on embedded RTOS, is characterized in that, described real-time communication middleware utilizes RTIConnetx DDS to build on VxWorks real-time embedded operating system, and wherein middleware entity comprises domain participant (Domain Participant), topic (Topic), publisher (Publisher) and data writer (DataWriter), receiver (Subscriber) and data receiver (Data Reader), QoS policy, etc.; middleware composition files include sending, receiving Source code, DDS static link library, DDS source code, data type conversion source code, xml middleware configuration file, etc.;

Each entity of the middleware corresponds to each functional module of the data distribution service, and uses the function interface in RTIConnetx DDS to create each entity, realize data distribution, and control the data sending field, specific data receiving objects and data sending and receiving methods;

Among them, the DDS link library of the middleware needs to compile the DDS source code by building a specific cross-compilation environment to support the VxWorks system. The data type conversion source code is generated by the RTIConnext DDS tool for a specific data structure. Data management, converts specific data structures into string types during the transmission process, which is convenient for Ethernet packaging and transmission. The xml configuration file can specify various entity parameters (such as Mask, ID, etc.) of the middleware, and can also register data. Type and specify QoS policy;

Wherein, the construction method comprises the following steps:

Step S1: Compile the source code related to the data distribution service in RTIConnext DDS, and generate a DDS link library file matching the VxWorks6.6 system;

Step S2: use the development environment Wind River Workbench of VxWorks6.6 to import the link library file of DDS, and complete the configuration of relevant kernel components and environment variables;

Step S3: Configure the QoS policy in the DDS by using the XML file to realize two transmission modes: sampling mode and queue mode; Domain Participant, Topic, Publisher and Data writer (Data Writer) entity, receiver (Subscriber) and data receiver (Data Reader) entity configure parameters, and register the data structure corresponding to each topic (Topic);

Step S4: Import the XML file in Step S3 by using the Code Generator tool of Utilities in RTILauncher, automatically generate relevant codes, and add the codes to the development environment of Wind River Workbench.

2. based on the construction method of distributed real-time communication middleware on a kind of embedded RTOS according to claim 1, it is characterized in that concrete steps are as follows in described step S1:

Step S1.1: Modify the root directory Makefile:

DDS runs in the VxWorks system and uses the C/C++ language. Comment out other content except dds_c.1.0 and dds_cpp.1.0. The compiled link library is located in the core folder core.1.0 Except for the files in the core folder, Will also include files at dds_c.1.0 and dds_cpp.1.0;

Step S1.2: Modify the configuration file perisonal.mk:

S1.2.1: Added statement for environment variable OS_ARCH: export OS_ARCH=pentiumVx6.6gcc4.1.2;

S1.2.2: The environment variable WAVEWORKSHOME represents the path where the DDS source code is located, which can be changed to the actual path, such as export WAVEWORKSHOME=/home/admin/ndds500-buildsrc;

Step S1.3: Modify the source generated file pentiumVx6.6gcc4.1.2.mk:

S1.3.1 carries out BSP modification for the embedded hardware platform processor, the CPU corresponding to the BSP used in the present invention is pentium4, and in the pentiumVx6.6gcc4.1.2.mk file, the CPU type is modified from the original pentium to pentium4;

S1.3.2 Modify the variables WIND_BASE and WIND_HOME related to the VxWorks development environment workbench, and change the default values to the actual installation directory of workbench;

S1.3.3: Add the compiled header file path under the C and C++ compilers: -I/home/admin/WindRiver/gnu\4.1.2-vxworks-6.6\lib\gcc\i586-wrs-vxworks\4.1.2\ include;

Step S1.4: Build a cross-compilation environment based on the Linux operating system:

Install the Linux operating system in the virtual machine, decompress the DDS source code, and then install the VxWorks system development environment; then start the VxWorks Development shell to complete the construction of the cross-compilation environment;

Step S1.5: Compile the DDS link library:

In the VxWorks653 Development shell, switch the directory to the folder where the DDS source code is located, and finally execute the make command on the source generated file pentiumVx6.6gcc4.1.2.mk to generate the DDS link library file that can be used in the VxWorks6.6 system.

3. based on the construction method of distributed real-time communication middleware on a kind of embedded RTOS described in claim 2, it is characterized in that concrete steps are as follows in described step S2:

Step S2.1: Add the macro definition EXTRA_DEFINE=DRTI_VXWORKS to the Makefile of the BSP, and then recompile the BSP;

Step S2.2: Add the directory where the link library generated above is located at Build Properties---Build Macros---LD_LINK_PATH;

Step S2.3: Add the address of the DDS library file at Build Properties---Build Paths;

Step S2.4: On the KernelConfiguration page of the project, select operating system components---RealTime Process Components, and add VxWorks components.

4. based on the construction method of distributed real-time communication middleware on a kind of embedded RTOS according to claim 3, it is characterized in that utilizing the configuration mode of specific parameter in QoS to realize in described step S3: sampling pattern takes priority with transmission efficiency, Applicable when the requirement for data packet loss is not high; while the queue mode ensures that all data sent can be received, and is suitable for high data integrity requirements.

5. based on the construction method of the distributed real-time communication middleware on a kind of embedded RTOS described in claim 4, it is characterized in that the interactive mode of middleware can be changed by the rewriting of specific node in XML file in described step S4 Specify the attributes of each entity, define the data structure or rewrite the QoS policy, and also realize the corresponding functions by calling the specific function interface in the middleware in the program, and by receiving the call of the sending function, it can realize cross-language, cross-platform, cross-platform System data real-time distribution service.