CN110008044B - Method for constructing distributed real-time communication middleware on embedded RTOS - Google Patents
Method for constructing distributed real-time communication middleware on embedded RTOS Download PDFInfo
- Publication number
- CN110008044B CN110008044B CN201910287484.5A CN201910287484A CN110008044B CN 110008044 B CN110008044 B CN 110008044B CN 201910287484 A CN201910287484 A CN 201910287484A CN 110008044 B CN110008044 B CN 110008044B
- Authority
- CN
- China
- Prior art keywords
- dds
- data
- real
- file
- middleware
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/547—Messaging middleware
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The DDS (data distribution service) is used as a distributed communication middleware, and the current application is usually found at the PC end, and the deployment of the data distribution service under an embedded platform, especially 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 and has a huge market application prospect. In order to meet the requirement of the current market on the distributed data distribution function in a real-time embedded platform and solve the technical problems, the invention provides a construction method for constructing a distributed real-time communication middleware by utilizing an RTI (real time interface) context DDS (direct digital synthesis) on a VxWorks6.6 embedded real-time operating system. The DDS source code is compiled by constructing a cross compiling environment in Linux, and the generated library file realizes system calling by configuring Wind River Workbench. In addition, configuration of various entities and QoS of the DDS is realized in an xml file mode, and codes are generated to provide APIs for other components to call.
Description
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: 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 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: 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 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 (5)
1. A method for constructing a distributed real-time communication middleware on an embedded RTOS (real time operating system) is characterized in that the real-time communication middleware is constructed on a VxWorks real-time embedded operating system by utilizing an RTIConnetx DDS (real time Data service), wherein a middleware entity comprises a Domain Participant (Domain Participant), a subject (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, an xml middleware configuration file and the like;
each entity of the middleware corresponds to each functional module of data distribution service, and each entity is established by using a function interface in the RTICONetx DDS to realize data distribution and control the data transmission field, a specific data receiving object and a data transmission and receiving method;
the DDS link library of the middleware needs to compile DDS source codes by constructing a specific cross compilation environment to realize the support of a VxWorks system, data type conversion source codes are generated by utilizing an RTIConnext DDS tool aiming at a specific data structure, the specific data structure is used by a developer to facilitate data management, the specific data structure is converted into a character string type in the transmission process to facilitate the packaging and transmission of Ethernet, an xml configuration file can realize the designation of each entity parameter (such as Mask, ID and the like) of the middleware, and in addition, the data type and a designated QoS strategy can be registered;
the construction method comprises the following steps:
step S1: compiling source codes related to data distribution service in the RTIConnext DDS to generate a DDS link library file matched with a VxWorks6.6 system;
step S2: importing a 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; parameter configuration is carried out on Domain participants (Domain participants), topics (Topic), publishers (publishers) and Data writers (Data writers) entities, receivers (subscribers) and Data receivers (Data readers) entities, and Data structures corresponding to the topics (Topic) are registered;
step S4: in RTILaucher, the XML file in step S3 is imported by using a Code Generator tool of Utilities, relevant codes are automatically generated, and the codes are added into the development environment of Wind River Workbench.
2. The method for constructing distributed real-time communication middleware on an embedded RTOS according to claim 1, wherein the specific steps in the step S1 are as follows:
step S1.1: modifying the root directory Makefile:
the DDS runs in a VxWorks system, C/C + + language is adopted, other contents except DDS _ c.1.0 and DDS _ cpp.1.0 are annotated, and a link library generated by compiling comprises files at DDS _ c.1.0 and DDS _ cpp.1.0 in addition to the files at core folder core.1.0;
step S1.2: modify configuration file per isopar.
S1.2.1: an environment variable OS _ ARCH new statement: export OS _ ARCH ═ pentium vxx 6.6gccc 4.1.2;
s1.2.2: the environment variable WAVEWORKSHOME represents a path where the DDS source code is located, and the path is modified into an actual path, for example, export WAVEWORKSHOME ═ home/admin/nds 500-build src;
step S1.3: the modified source generation file pentium vx6.6gccc 4.1.2. mk:
s1.3.1 BSP modification is carried out aiming at the embedded hardware platform processor, the CPU corresponding to the BSP used in the invention is pentium4, in the pentium Vx6.6gccc 4.1.2.mk file, the CPU type is modified from the original pentium to pentium 4;
s1.3.2, modifying variables WIND _ BASE and WIND _ HOME related to the VxWorks development environment workbench, and modifying a default value into an actual installation directory of the workbench;
s1.3.3 Add header File Path under 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: building a cross compiling environment based on a Linux operating system:
installing a Linux operating system in the virtual machine, decompressing DDS source codes, and then installing a VxWorks system development environment; then starting a VxWorks Development shell, namely completing the construction of a cross compiling environment;
step S1.5: compiling a DDS link library:
and switching the directory to a folder where a DDS source code is located in the VxWorks653Development shell, and finally executing a make instruction on a source generation file pentium Vx6.6gCC4.1.2.mk to generate a DDS link library file which can be used in the VxWorks6.6 system.
3. The method for constructing distributed real-time communication middleware on an embedded RTOS according to claim 2, wherein the specific steps in the step S2 are as follows:
step S2.1: adding macro definition EXTRA _ DEFINE ═ DRTI _ VXWORKS in the Makefile of the BSP, and then recompiling the BSP;
step S2.2: adding the directory where the generated LINK library is located at the positions of Build Properties, namely Build robots, LD _ LINK _ PATH;
step S2.3: adding the address of the DDS library file at Build Properties-Build pages;
step S2.4: on the Kernel configuration page of the project, operating system Components- -RealTime Process Components are selected, and VxWorks Components are added.
4. The method for constructing distributed real-time communication middleware on an embedded RTOS according to claim 3, wherein the step S3 is implemented by using a configuration mode of specific parameters in QoS: 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.
5. The method for constructing distributed real-time communication middleware on embedded RTOS according to claim 4, wherein the interaction mode of the middleware can specify the attribute of each entity, define the data structure or rewrite the QoS policy by rewriting the specific node in the XML file in the step S4, and implement the corresponding function by invoking the function interface specific in the middleware in the program, and implement the cross-language, cross-platform, and cross-system data real-time distribution service by receiving the invocation of the sending function.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910287484.5A CN110008044B (en) | 2019-04-11 | 2019-04-11 | Method for constructing distributed real-time communication middleware on embedded RTOS |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910287484.5A CN110008044B (en) | 2019-04-11 | 2019-04-11 | Method for constructing distributed real-time communication middleware on embedded RTOS |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110008044A CN110008044A (en) | 2019-07-12 |
| CN110008044B true CN110008044B (en) | 2021-03-23 |
Family
ID=67170979
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910287484.5A Active CN110008044B (en) | 2019-04-11 | 2019-04-11 | Method for constructing distributed real-time communication middleware on embedded RTOS |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110008044B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110704070B (en) * | 2019-09-30 | 2021-04-13 | 北京航空航天大学 | Method for constructing DDS communication middleware under partitioned real-time operating system |
| GB2586913B (en) * | 2020-06-05 | 2021-11-10 | Iotech Systems Ltd | Data processing |
| CN112532422B (en) * | 2020-10-28 | 2021-12-07 | 南京航空航天大学 | HLA/DDS bridge based on mixed time management system |
| CN112583929B (en) * | 2020-12-23 | 2022-07-26 | 北京航空航天大学 | Service management method based on airborne embedded real-time operating system |
| CN112583927B (en) * | 2020-12-23 | 2022-04-15 | 北京航空航天大学 | Service management system based on airborne embedded real-time operating system |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20010076790A (en) * | 2000-01-28 | 2001-08-16 | 오길록 | I/O-based high availability through middleware in the COTS RTOS |
| CN104407852A (en) * | 2014-11-05 | 2015-03-11 | 中国航天科技集团公司第九研究院第七七一研究所 | Code isolation-based construction method for embedded software and calling method for embedded software |
| CN105138339A (en) * | 2015-09-10 | 2015-12-09 | 中国航空无线电电子研究所 | Distributed communication midware developing method based on DDS standard |
| CN107454092A (en) * | 2017-08-18 | 2017-12-08 | 北京海兰信数据科技股份有限公司 | A kind of OPCUA and DDS protocol signals conversion equipment, communication system and communication means |
| CN109474466A (en) * | 2018-11-13 | 2019-03-15 | 天津津航计算技术研究所 | The method of dual redundant network interface card switching is realized on DDS middleware |
-
2019
- 2019-04-11 CN CN201910287484.5A patent/CN110008044B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20010076790A (en) * | 2000-01-28 | 2001-08-16 | 오길록 | I/O-based high availability through middleware in the COTS RTOS |
| CN104407852A (en) * | 2014-11-05 | 2015-03-11 | 中国航天科技集团公司第九研究院第七七一研究所 | Code isolation-based construction method for embedded software and calling method for embedded software |
| CN105138339A (en) * | 2015-09-10 | 2015-12-09 | 中国航空无线电电子研究所 | Distributed communication midware developing method based on DDS standard |
| CN107454092A (en) * | 2017-08-18 | 2017-12-08 | 北京海兰信数据科技股份有限公司 | A kind of OPCUA and DDS protocol signals conversion equipment, communication system and communication means |
| CN109474466A (en) * | 2018-11-13 | 2019-03-15 | 天津津航计算技术研究所 | The method of dual redundant network interface card switching is realized on DDS middleware |
Non-Patent Citations (2)
| Title |
|---|
| 《基于IP over RapidIO的DDS中间件优化实现》;仲维亮;《中国优秀硕士学位论文全文数据库 信息科技辑》;20131215;全文 * |
| 嵌入式实时多处理***的通信中间件技术研究;秦玉函;《中国优秀硕士学位论文全文数据库 信息科技辑》;20190115;第2节-第5节 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110008044A (en) | 2019-07-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110008044B (en) | Method for constructing distributed real-time communication middleware on embedded RTOS | |
| Westergaard et al. | The access/cpn framework: A tool for interacting with the cpn tools simulator | |
| US20100153909A1 (en) | Method and System for Building and Application | |
| Huston et al. | The ACE programmer's guide: practical design patterns for network and systems programming | |
| CN112235357B (en) | Cross-platform application development system | |
| US9720686B2 (en) | Melding of mediation flow service component architecture (SCA) components | |
| CN103473034A (en) | Method and device for dynamically publishing Web service | |
| Otte et al. | Infrastructure for component-based DDS application development | |
| Radermacher et al. | Generating execution infrastructures for component-oriented specifications with a model driven toolchain: A case study for marte's gcm and real-time annotations | |
| van der Linden | Development and Evolution of Software Architectures for Product Families: Second International ESPRIT ARES Workshop, Las Palmas de Gran Canaria, Spain, February 26–27, 1998, Proceedings | |
| CN115328679A (en) | Automatic integration method of heterogeneous function library, computing equipment and system thereof | |
| Delange et al. | Code generation strategies from aadl architectural descriptions targeting the high integrity domain | |
| Bardaro et al. | From models to software through automatic transformations: An AADL to ROS end-to-end toolchain | |
| McGuire et al. | The Austin Protocol Compiler | |
| US20070214419A1 (en) | Integrated service creation and execution platforms for the converged networks | |
| CN112148283A (en) | Implementation method of cross-platform ABI compatible C + + component framework | |
| Maia et al. | OiL: An object request broker in the Lua language | |
| Pop et al. | Introducing support for embedded and real-time devices into existing hierarchical component system: Lessons learned | |
| Berbers et al. | Components and contracts in software development for embedded systems | |
| Ciobanu et al. | Mobile Agents with Timers, and Their Implementation | |
| CN115080049A (en) | Method, system, and computer-readable storage medium for compiling a simulation model | |
| US20090133035A1 (en) | Method and system for developing and deploying converged services | |
| Guan et al. | The flow of software defined radio waveform development based on SCARI | |
| Grieshofer | Cloud Foundry Config File Generation Using JetBrains MPS and DSLs | |
| Adamopoulos et al. | Enabling Web services: towards service grids |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |