Modeling, Simulation, Formal Verification Method and Application for Micro-ROS Communication Middleware

Abstract

The present invention discloses a method for modeling, simulation and formal verification of the Micro-ROS communication middleware. First, from the open-source code of the Micro-ROS communication middleware MicroXRCE-DDS, combined with the XRCE-DDS specification, each module included in the communication process, as well as the behaviors and functions of each module, are extracted to establish a timed automata model for each module. Then, using modeling and simulation tools, the abstract timed automata model is implemented, and combined with specific Micro XRCE-DDS communication application scenarios to complete the implementation and simulation of the model. According to the natural language description of the protocol part in the XRCE-DDS specification for the communication process, the key and important properties are abstracted, and a signal temporal logic STL with a lower bound of 0 applicable to these properties is proposed. inf＝0 These properties are formally expressed; combined with runtime verification tools, the key properties described by STL inf＝0 are verified at runtime, and the model or source code is corrected according to the verification results to ensure the correctness and reliability of the model simulation and source code.

Description

Technical Field

[0001] The present invention belongs to the technical fields of robot operating system (ROS) and formal verification, and relates to a method and application for modeling, simulating and formally verifying a middleware of a data distribution service (XRCE-DDS) for resource-constrained device used in a Micro-ROS communication mechanism. Background Art

[0002] ROS (Robot Operating System) is a collection of a communication mechanism, tool software packages, high-level robot skills, and a robot ecosystem, and is widely used in the research and development of autonomous robots, unmanned aerial vehicles, and intelligent vehicles. Through loosely coupled network communication, ROS greatly facilitates the development and research of various functions of robots by researchers. The underlying communication mechanism of ROS1 mainly relies on the Linux system for communication, and the fact that Linux cannot provide timing guarantees leads to the inability to ensure its real-time performance precisely. To ensure real-time performance, in 2014, the ROS team began to initiate the ROS2 project, and communicated by introducing the Data Distribution Service (DDS) middleware led by the Object Management Group (OMG), and used the rich QoS of DDS to replace the communication mechanism in ROS1 to improve its real-time performance and reliability.

[0003] So far, ROS2 still remains at the microcontroller boundary and usually communicates with microcontrollers through tools such as serial specifications. Micro-ROS, as a lightweight robot operating system optimized based on ROS2, provides most of the functions and tools of a fully deployed ROS2 ecosystem, and at the same time has excellent capabilities on embedded and low-resource devices and can run on a microcontroller MCU hardware platform. The key to introducing a resource-constrained MCU into the DDS network of ROS2 lies in the Micro XRCE-DDS middleware customized for it. This middleware is implemented based on the Data Distribution Service (XRCE-DDS) specification for Extremely Resource Constrained Environments, "DDS for eXtremely Resource Constrained Environments". Its correctness and reliability are directly related to the correctness and reliability of the Micro-ROS system, and thus will affect the safety in application scenarios such as industrial environments or intelligent driving. Therefore, verifying this middleware to ensure its correctness and reliability has high value and far-reaching significance.

[0004] Formal verification is a systematic inspection or proof that uses mathematical methods to verify whether the design intent or specification is faithfully implemented in the design or implementation model. With the development of technology, the tools related to formal verification have become increasingly mature, and formal methods have been widely used in the verification of various specifications. Many important specifications have been analyzed and studied through formal methods, and their properties have been verified and guaranteed.

[0005] Therefore, it is of great significance to conduct formal analysis and research on the communication middleware of Micro-ROS to find potential problems or ensure the properties required by the XRCE-DDS specification that it should possess or meet, for the application and development of the robot operating system in the embedded field. Moreover, as a communication protocol provided by the OMG organization for extremely resource-constrained devices, the Micro XRCE-DDS middleware may also be applied in more industrial and military fields such as wireless sensor networks in the future, and it itself has very important significance and value. Summary of the Invention

[0006] To solve the deficiencies of the existing technology, the purpose of the present invention is to propose a modeling, simulation, and formal verification method for the Micro-ROS communication middleware Micro XRCE-DDS.

[0007] The present invention models, simulates, and formally verifies the Micro-ROS communication middleware Micro XRCE-DDS in combination with the XRCE-DDS specification. The present invention proposes a feature model expressed by timed automata, simulates the communication process of XRCE-DDS according to the established feature model, and also proposes a signal temporal logic STL with a lower bound of 0 inf＝0 , and makes a formal expression based on STL inf＝0 for the key properties such as reliable transmission, sequential reception, non-interference during sleep, and knowability of loss in the communication process described in natural language in the XRCE-DDS specification. Finally, based on the model implementation of XRCE-DDS for simulation, runtime verification is performed on the key properties described by STL inf＝0 . The method of the present invention establishes a formal model of the Micro XRCE-DDS communication middleware, and through the method of runtime verification, verifies whether the implementation of Micro XRCE-DDS meets the important properties in the XRCE-DDS specification, ensures that these property specifications hold in the simulation, and introducing the method of formal modeling into Micro-ROS can improve the security and reliability of robot communication in resource-constrained environments.

[0008] The method of the present invention includes the following steps:

[0009] Step 1: According to the open-source Micro XRCE-DDS implementation code, extract the behavioral modules included in the main components of Micro XRCE-DDS, namely Micro XRCE-DDSAgent (Micro XRCE-DDS agent) and Micro XRCE-DDSClient (Micro XRCE-DDS client), and perform formal modeling of each module based on timed automata;

[0010] The described timed automata model is a modeling method that formally describes the state transitions and changes of a real-time system through a finite automaton with a clock set, and is often used for formal modeling of the behavior of time-critical systems. In this invention, the timed automata model is used to perform formal modeling of Micro XRCE-DDS to ensure that the behavioral model can represent the time characteristics of the system.

[0011] Step 2: Based on the timed automata model established in Step 1, use a modeling and simulation tool, combined with a specific scenario application, to perform specific model implementation and simulation of the Micro XRCE-DDS communication process. According to the simulation results, appropriately modify the model until the model can be normally simulated and executed, that is, the model can completely and correctly simulate the Micro XRCE-DDS communication process.

[0012] Step 3: Extract the key properties that need to be verified in the communication process from the natural language description of the XRCE-DDS specification, and use signal temporal logic STL with a lower bound of 0 inf＝0 to describe the key properties. The key properties include reliable sending from the client to the agent, reliable sending from the agent to the client, sequential reception of messages by the receiver, not being disturbed during the client's sleep period, the receiver being aware when the sent message is lost, and the lost message being resent, etc.

[0013] Step 4: Combine the runtime verification tool and perform STL proposed in Step 3 on the simulation model implemented in Step 2 inf＝0Perform runtime verification on the described key properties, analyze the verification results, and provide corresponding counterexamples if the key properties are not satisfied during runtime verification. If the key properties are not satisfied during runtime verification, based on the provided counterexamples, determine whether it is a problem with the model itself. If it is a problem with the model itself, then return to Step 2 to correct the model. If it is not a problem with the model itself, it means that the implementation of the Micro XRCE-DDS communication middleware does not satisfy the properties in the XRCE-DDS specification. Modify the code, return to Step 1, and correct the model until the runtime verification satisfies all the key properties to be verified. If all the key properties have been satisfied, it proves the correctness of the Micro XRCE-DDS communication middleware modeling and simulation, and a correct MicroXRCE-DDS communication middleware model is obtained.

[0014] In the modeling and simulation and formal verification method for the Micro-ROS communication middleware Micro XRCE-DDS proposed by the present invention, the further steps of establishing a timed automaton model in Step 1 include the following steps:

[0015] Step A1: Combining the XRCE-DDS specification, extract the main modules included in the main components Micro XRCE-DDSAgent and Micro XRCE-DDS Client in the open-source Micro XRCE-DDS implementation code from eProsima. The main modules include five modules: a publishing client, a subscribing client, a proxy message transceiver, a publishing client proxy, and a subscribing client proxy. Among them, the proxy message transceiver, the publishing client proxy, and the subscribing client proxy together serve as the XRCE-proxy side, and the publishing client and the subscribing client represent two different types of clients in Micro XRCE-DDS.

[0016] Step A2: According to the XRCE-DDS specification and the code of the Micro XRCE-DDSClient part, the sub-modules of the publishing client extracted include a reliable input stream, a reliable output stream, a heartbeat response stream, and a message sender. Among them, the reliable output stream continuously prepares the data messages to be sent and puts them into the queue to be sent; the reliable input stream continuously reads the response messages and notifies the heartbeat response stream; the heartbeat response stream not only processes the response messages when receiving the response messages, notifies the reliable output stream to re-send the data messages that have not been sent successfully, but also periodically generates heartbeat messages and puts them into the queue to be sent; the message sender is responsible for continuously sending the messages in the queue to be sent.

[0017] Step A3: According to the functions of the four sub-modules extracted in Step A2, use timed automata to formally model each sub-module respectively. The timed automata of the four sub-modules established are generally concurrent, and their synchronization relationship is as described in Step A2. Synchronization can be expressed using channels in timed automata;

[0018] Step A4: According to the XRCE-DDS specification and the code of the Micro XRCE-DDSClient part, the sub-modules of the subscription client extracted include a reliable input stream, a reliable output stream, a heartbeat response stream, a message sender, and a message receiver. Among them, the biggest difference between the subscription client and the publication client is that the sleep mechanism is considered, so each sub-module has a sleep state affected by time; the reliable output stream will periodically send subscription messages to the broker until a subscription success message is received or it enters the sleep state; the reliable input stream will continuously read messages from the receive queue and make judgments, and notify the reliable output stream and the heartbeat response stream to process the corresponding messages respectively until it enters the sleep state; the heartbeat response stream will generate response messages and put them into the queue to be sent when it receives heartbeat messages, and will also periodically generate response messages actively when messages are missing and put them into the queue to be sent until it enters the sleep state; the message sender is responsible for continuously sending the messages in the queue to be sent during the non-sleep period; the message receiver is responsible for continuously putting the received messages into the receive queue during the non-sleep period;

[0019] Step A5: According to the functions of the five sub-modules extracted in Step A4, use timed automata to formally model each sub-module respectively. The timed automata of the five sub-modules established are generally concurrent, and their synchronization relationship is as described in Step A4. Synchronization can be expressed using channels in timed automata;

[0020] Step A6: According to the XRCE-DDS specification and the code of the Micro XRCE-DDSAgent part, the sub-modules of the broker message transceiver extracted include a message receiver and a message dispatcher. Among them, the message receiver will put each incoming message into the receive queue of the broker; the message dispatcher will read each message in the receive queue and distribute it to the receive queues of the respective brokers according to the content of the message;

[0021] Step A7: According to the functions of the two sub-modules extracted in Step A6, use timed automata to formally model the two sub-modules respectively. The state transitions of the timed automata of the two sub-modules are asynchronously concurrent. They judge whether to perform state transitions by judging whether the global queue is non-empty; if the global queue is empty, no state transition is performed; if the global queue is non-empty, it means there are messages to be processed and the transition occurs;

[0022] Step A8: According to the XRCE-DDS specification and the code of the Micro XRCE-DDS Agent part, the sub-modules of the publishing client agent extracted include a reliable input stream, a heartbeat response stream, and a message sender. Among them, the reliable input stream continuously reads messages from the agent's receive queue and makes judgments. If it is a data message, it determines whether to receive it according to the message sequence number. If it is a heartbeat message, it notifies the heartbeat response stream for processing; the heartbeat response stream generates corresponding response messages according to whether there is message loss when receiving a heartbeat message and puts them into the queue to be sent; the message sender is responsible for continuously sending the messages in the queue to be sent;

[0023] Step A9: According to the functions of the three sub-modules extracted in Step A8, use timed automata to formally model each sub-module respectively. The timed automata of the three sub-modules established are generally concurrent, and their synchronization relationship is as described in Step A8. Synchronization can be expressed using channels in the timed automata;

[0024] Step A10: According to the XRCE-DDS specification and the code of the Micro XRCE-DDS Agent part, the sub-modules of the subscribing client agent extracted include a reliable input stream, a reliable output stream, a heartbeat response stream, and a timed message sender. Among them, the reliable output stream continuously prepares the data messages to be sent and puts them into the queue to be sent; the reliable input stream continuously reads messages from the receive queue and judges the message type. If it is a subscription message, it notifies the reliable output stream. If it is a response message, it notifies the heartbeat response stream; the heartbeat response stream not only processes the response message when receiving it, notifies the reliable output stream to re-send the data messages that have not been sent successfully, but also periodically generates heartbeat messages and puts them into the queue to be sent; the timed message sender infers the state of the client and continuously sends the messages in the queue to be sent during the waking period of the client;

[0025] Step A11: According to the functions of the four sub-modules extracted in Step A10, use timed automata to formally model each sub-module respectively. The timed automata of the four sub-modules established are generally concurrent, and their synchronization relationship is as described in Step A10. Synchronization can be expressed using channels in the timed automata.

[0026] In the modeling, simulation, and formal verification method for the Micro-ROS communication middleware Micro XRCE-DDS proposed by the present invention, Step 2 implements and simulates the established timed automata model through a modeling and simulation tool, and further includes the following steps:

[0027] Step B1: Based on the time automaton models of each sub-module established in Step A3, A5, A7, A9, and A11, combined with specific modeling and simulation tools that support state machines or automata, perform corresponding model implementations respectively;

[0028] Step B2: Combining a specific application scenario of Micro XRCE-DDS communication, construct a complete Micro XRCE-DDS application simulation model by combining the specific model implementations established in Step B1, to represent the client-agent relationship and the send-receive process in communication;

[0029] Step B3: According to the complete Micro XRCE-DDS application simulation model constructed in Step B2, perform model simulation in the modeling and simulation tool, visualize the simulation results of the model through the visualization components in the modeling and simulation tool, observe the simulation results, and analyze the simulation results;

[0030] Step B4: According to the analysis results in Step B3, if it is found that there are parts that are significantly inconsistent with the facts during model simulation, or factors that affect the normal simulation of the model, then re-execute Steps B1, B2, B3, and B4 until the model simulation results are normal; if no parts inconsistent with the facts or factors affecting the normal simulation of the model are found, it means that the modeling and simulation process is completed.

[0031] The factors that affect the normal simulation of the model include setting the simulation time too short, some time parameters being unreasonable, etc.; for example, the simulation time needs to be long enough to ensure that all messages can be received, and the time parameters cannot be too large to avoid consuming too much simulation time.

[0032] In the modeling, simulation, and formal verification method for the Micro-ROS communication middleware Micro XRCE-DDS proposed by the present invention, Step Three extracts key properties from the XRCE-DDS specification and uses STL inf＝0 for expression, and further includes the following steps:

[0033] Step C1: Extract the key properties related to Micro XRCE-DDS in sending and receiving messages from the XRCE-DDS specification, and describe them in natural language, including properties such as all sent messages can be delivered, all subscribed messages can be received, no messages will arrive to wake up during the sleep period after the client enters the sleep state, the reception of messages is always sequential, when unaccepted messages are lost, the receiver can always detect it in time, and for all messages that the subscribed client fails to accept successfully, the subscribed client agent will re-send them in time, etc.;

[0034] Step C2: Improve based on Signal Temporal Logic (STL), modify the represented time range to be more suitable for describing the key properties extracted in Step C1, and propose an STL with a lower bound of 0 inf＝0 ;

[0035] Step C3: Use the STL in Step C2 inf＝0 , and formalize the key properties described in natural language proposed in Step C1, which are respectively expressed as:

[0036] All sent messages can be delivered: F [0,180] client_pub_finished = 1

[0037] All subscribed messages can be received: F [0，180] client_received_all = 1

[0038] After the client enters the sleep state, there will be no more messages to wake it up during the sleep period: G [0，180] subClient_statue = 1 → F [0，50] SubClient_receiveSig = false

[0039] The reception of messages is always sequential: G [0，180] publisher_last_received ≥ 10 → VedioInfo = TDDS && G [0，180] subscriber_last_received ≥ 10 → GetInfo = FDDS

[0040] When the unaccepted messages are lost, the receiver can always detect it in time: G [0，180] (missing_fig = 1 && sendMissSeq < last_receive) → F [0，20] findMissSeq = sendMissSeq

[0041] For all messages that the subscribed clients fail to accept successfully, the subscribed client proxy will resend them in time: G [0，180] (1ast_sent > last_ack + 1 → F [0，20] last_sent = last_ack + 1).

[0042] In the method for modeling, simulation and formal verification of the Micro-ROS communication middleware Micro XRCE-DDS proposed by the present invention, in the fourth step, formal verification of the key properties is carried out on the established model simulation, and the verification results are analyzed, which further includes the following steps:

[0043] Step D1: Based on the key properties described in the formal representation using STL in Step C3, represent them in a form that conforms to the tool rules in a runtime verification tool that supports temporal logic; inf＝0 Describe the key properties, and represent them in a form that conforms to the tool rules in a runtime verification tool that supports temporal logic;

[0044] Step D2: According to the specific model established in Step B4, perform runtime verification on the properties that conform to the tool rules in Step D1, and analyze the verification results;

[0045] Step D3: If there are counterexamples in the verification results of Step D2 that do not satisfy one or more key properties, based on the path status of the counterexamples, find the time-states that do not satisfy the key properties, and execute Step D4; otherwise, a formally verified simulation model of the XRCE-DDS communication mechanism is obtained;

[0046] Step D4: According to the paths and time-states of the counterexamples given in the formal verification tool, analyze the possible reasons for errors. If the model is problematic, return to Step B1 to improve and modify the model. If the problem lies in the source code, modify the corresponding functional implementation code and return to Step A1 to re-abstract the timed automata model.

[0047] In the method for modeling, simulating, and formally verifying the Micro-ROS communication middleware Micro XRCE-DDS proposed by the present invention, Steps B1, B2, B3, D1, and D4 are respectively used for modeling, simulation, and formal runtime verification through the Temporal Logical Assignment part of the tool Matlab Simulink / Stateflow and Simulink Test in the Simulink toolbox. Other modeling and simulation tools that support state machines or automata, if equipped with relevant runtime verification tools, are also applicable to the present invention.

[0048] The present invention also provides an application of the above method in the modeling, simulation, and formal verification of the Micro-ROS communication middleware Micro XRCE-DDS.

[0049] The beneficial effects of the present invention include: The present invention proposes a method for modeling, simulation, and formal verification of the Micro-ROS communication middleware. First, from the open-source code of the Micro-ROS communication middleware Micro XRCE-DDS, combined with the XRCE-DDS specification, each module included in the communication process, as well as the behaviors and functions of each module, are extracted to establish a timed automata model for each module; then, using modeling and simulation tools, the abstract timed automata model is implemented, and combined with a specific Micro XRCE-DDS communication application scenario, the implementation and simulation of the model are completed; according to the natural language description of the protocol part in the XRCE-DDS specification for the communication process, the key and important properties are abstracted, and a signal temporal logic STL with a lower bound of 0 applicable to these properties is proposed. inf＝0 These properties are formally expressed; combined with a runtime verification tool, the key properties described by STL inf＝0 are verified at runtime, and the model or source code is corrected according to the verification results to ensure the correctness and reliability of the model simulation and source code. The present invention is applied to the v2.2.0 version of the open-source Micro XRCE-DDS communication middleware of eProsima company. Combined with a specific example of the communication between an XRCE-publishing client and an XRCE-subscribing client to the same XRCE-agent, through runtime verification, the security and reliability of the Micro XRCE-DDS communication middleware provided by eProsima company used by Micro ROS are ensured.

[0050] The method for modeling, simulation, and formal verification of the Micro-ROS communication middleware Micro XRCE-DDS proposed by the present invention models and simulates the underlying communication mechanism of Micro-ROS, and through the visualization components of the modeling and simulation platform, the communication and transmission of data can be more intuitively seen; the present invention proposes a new signal temporal logic STL with a lower bound of 0 applicable to the XRCE-DDS specification inf＝0 and expresses the key properties in the XRCE-DDS specification through STL inf＝0It is described that through a runtime verification tool, the model and the code implementation of the communication protocol XRCE-DDS of Micro-ROS are automatically verified. If the verification fails, a counterexample can also be obtained to more quickly determine the errors in the model simulation or code implementation; the modeling, simulation, and formal verification method for the Micro-ROS communication middleware Micro XRCE-DDS proposed by the present invention can be used to verify Micro-ROS applications that communicate based on the XRCE-DDS specification, and verify the real-time performance and reliability of the communication process of Micro-ROS applications through runtime verification. Currently, except for the present invention, there is no method for verifying and researching the reliability of Micro-ROS and its related communication mechanisms. Description of the Drawings

[0051] Figure 1 It is a schematic flowchart of the modeling, simulation, and verification method for the Micro-ROS communication middleware Micro XRCE-DDS of the present invention.

[0052] Figure 2 It is a module architecture diagram for extracting the open-source implementation code of the Micro-ROS communication middleware Micro XRCE-DDS of the present invention.

[0053] Figure 3 It is a schematic diagram of the timed automaton model of the reliable output stream of the publish client module of the Micro-ROS communication middleware Micro XRCE-DDS of the present invention.

[0054] Figure 4 It is a schematic diagram of the timed automaton model of the reliable output stream of the subscribe client module of the Micro-ROS communication middleware Micro XRCE-DDS of the present invention.

[0055] Figure 5 It is a schematic diagram of the timed automaton model of the timed message sender of the subscribe client proxy module of the XRCE-proxy end of the Micro-ROS communication middleware Micro XRCE-DDS of the present invention.

[0056] Figure 6 It is a client-proxy communication relationship diagram of the embodiment of the Micro-ROS communication middleware Micro XRCE-DDS of the present invention.

[0057] Figure 7 It is a working flowchart of the runtime verification of the Micro-ROS communication middleware Micro XRCE-DDS of the present invention. Detailed Embodiments

[0058] The present invention will be further described in detail with reference to the following specific embodiments and drawings. The processes, conditions, experimental methods, etc. for implementing the present invention are all common knowledge and well-known general knowledge in the art, except for the specifically mentioned content below. The present invention has no particularly restricted content.

[0059] The modeling, simulation, and formal verification method for the Micro-ROS communication middleware Micro XRCE-DDS proposed by the present invention mainly establish a formal model related to its communication through the open-source middleware Micro XRCE-DDS implementation code based on the XRCE-DDS specification, and extract the key properties that XRCE-DDS needs to satisfy described in the "DDS for eXtremely Resource Constrained Environments" specification. Combining with a specific XRCE-DDS application example, the modeling simulation and formal runtime verification of XRCE-DDS are carried out. First, through the open-source implementation code of XRCE-DDS, the composition and execution rules of the main modules of XRCE-DDS are understood, and models of five large modules containing multiple functional sub-modules are established for model simulation. Then, the key properties that meet the requirements of the communication process are extracted from the XRCE-DDS specification and expressed in STL inf＝0 For expression; combining with a specific XRCE-DDS application example, the model and the XRCE-DDS implementation are verified at runtime. The verification methods are various formal methods, such as model checking or theorem proving, etc. With the help of the modeling and simulation tool Matlab Simulink and the formal runtime verification tool Simulink Test, the correctness of the XRCE-DDS implementation is analyzed based on the simulation and verification results of the model, and improvements are made.

[0060] As Figure 1 shown, it is the flowchart of the modeling, simulation, and verification of the present invention applied to the open-source Micro XRCE-DDS implementation of eProsima. The present invention includes the following steps:

[0061] Step 1: Analyze the part related to the communication process of the open-source Micro XRCE-DDS implementation of eProsima, and extract therefrom such as Figure 2The module architecture diagram of five major modules including the XRCE-publishing client, the XRCE-subscribing client, and the XRCE-proxy side composed of the proxy-side message transceiver, the publishing client proxy corresponding to the publishing client, and the subscribing client proxy corresponding to the subscribing client. Formal modeling based on timed automata is carried out for each function of each major module, such as the reliable input stream, the reliable output stream, the heartbeat response stream, etc., and then concurrent timed automata are used to represent each major module. Taking the XRCE-publishing client, the XRCE-subscribing client, and the subscribing client proxy of the XRCE-proxy side as examples respectively.

[0062] Among them, the timed automaton model of the XRCE-publishing client is represented by 4 concurrent timed automata as TA CP = TA CP_RIS || TA CP_ROS || TA CP_HAS || TA CP_FS , where TA CP_RIS , TA CP_ROS , TA CP_HAS , TA CP_FS represent the automaton models of the reliable input stream, the reliable output stream, the heartbeat response stream, and the message sender of the XRCE-publishing client respectively. Taking the timed automaton TA CP_ROS of the reliable output stream as an example, TA CP_ROS can be represented as a six-tuple:

[0063]

[0064] Among them:

[0065] · Loc CP_ROS represents the set of positions of the reliable output stream in the model. Loc CP ROS = {preSending, sending}, preSending represents the position where the reliable output stream is ready to send a message and is also the initial position at the beginning; sending represents the position where the reliable output stream periodically sends messages according to the change of time after being ready to send a message.

[0066] · represents the set of initial positions of the reliable output stream in the model,

[0067] · Act CP_ROS represents the set of events or actions for the reliable output stream to migrate between preparing to send and finishing sending in the model, Act CP_ROS= {a_set_push_next_msg, c_nbalance, c_balance}, where c_nbalance and c_balance represent two communication-related events or actions, and a_set_push_next_msg represents the action to be executed after the guard condition is satisfied.

[0068] ·C CP_ROS represents the set of clocks in the model for the reliable output stream, C CP_ROS = {t}, where t is the clock used.

[0069] ·Inv CP_ROS represents the set of invariant functions in the model for the reliable output stream, Inv CP_ROS = {Inv CP_ROS (presending) = (t ≤ 1), Inv CP_ROS (sending) = (t ≤ 3)}. The two invariants in the set respectively represent that the maximum residence time at the presending position cannot exceed 1 time unit, and the maximum residence time at the sending position cannot exceed 3 time units.

[0070] · represents the set of transition relations in the model for the reliable output stream. The specific transition relations included in this set are as follows:

[0071]

[0072]

[0073]

[0074] The above three transitions respectively represent that at the position preSending when the clock t > 1 holds, a signal is sent to the channel c_nbalance, and the action a_set_push_next_msg is executed. After resetting the clock t, it enters the position sending; at the position sending when the clock t > 3, a_set_push_next_msg is executed, and after resetting the clock t, it enters the position sending; at the position sending when a signal is received from the channel c_balance, after resetting the clock t, it enters the position preSending. The corresponding TA CP_ROS time automaton is as Figure 3 shown. Other time automata adopt a similar modeling method.

[0075] The time automaton model of the XRCE - subscription client is represented by 5 concurrent time automata as TA CS = TA CS_RIS ||TACS_ROS ||TA CS_HAS ||TA CS_FS ||TS CS_MS , where TA CS_RIS 、TA CS_RoS 、TA CS_HAS 、TA CS_FS and TS CS_MS respectively represent the automaton models of the reliable input stream, reliable output stream, heartbeat response stream, message sender, and message receiver of the XRCE-subscription client. Taking the timed automaton TA CS_RoS of the reliable output stream as an example, TA CS_RoS can be represented as a six-tuple:

[0076]

[0077] where:

[0078] ·Loc CS_ROS : represents the set of positions of the reliable output stream in the model. Loc CS_ROS = {init, waitRet, TIMEOUT, sleep}, init represents the initial position of the reliable output stream at the beginning; waitRet represents the position where the reliable output stream waits for the return result of the subscription message after sending the subscription message; TIMEOUT represents the position after the reliable output stream times out without waiting for the return result; sleep represents the position where the client_subscriber is in a sleep state and the reliable output stream also stops working.

[0079] · represents the set of initial positions of the reliable output stream in the model,

[0080] ·Act CS_ROS represents the set of events or actions for the reliable output stream to migrate between preparing to send and finishing sending in the model, Act CP_ROS = {a_set_push_sub_msg, c_subs_success, a_storeInfo, a_restoreInfo, f_sub_finished := 1, leftwaketime = leftwaketime - t2}, where c_subs_success represents the communication-related event or action, and a_set_push_sub_msg, a_storeInfo, a_restoreInfo, f_sub_finished := 1, leftwaketime = leftwaketime - t2 represent the actions executed after the guard condition is satisfied.

[0081] · C CS_ROS Represents the set of clocks in the model for the reliable output stream, C Cs_ROS = {t, t2}, where t is the clock used to record waking and sleeping times, and t2 is the clock used to record whether there is a timeout or not.

[0082] · Inv CS_ROS Represents the set of invariant functions in the model for the reliable output stream, Inv CS_ROS = {Inv CS_ROS (init) = (t ≤ 100), Inv CS_ROS (waitRet) = (t ≤ 100), Inv CS_ROS (TIMEOUT) = (t ≤ 100), Inv CS_ROS (sleep) = (t ≤ 50)}. The four invariants in the set respectively represent that at the init position, it cannot stay for more than 100 time units, at the waitRet position, it cannot stay for more than 100 time units, at the TIMEOUT position, it cannot stay for more than 100 time units, and at the sleep position, it cannot stay for more than 50 time units

[0083] · Represents the set of transition relations in the model for the reliable output stream. The specific transition relations included in this set are as follows:

[0084]

[0085]

[0086]

[0087]

[0088]

[0089]

[0090]

[0091]

[0092] Among the above 8 transition relations, 3 transition relations indicate that when the clock t > 100 at positions init, waitRet, and TIMEOUT, the a_storeInfo action is executed, the clock t is reset, and it enters the sleep state. The other 5 transition relations respectively indicate that at position init when f_sub_finished = 0, the a_set_push_sub_msg is executed and the clock t2 is reset, and it enters the waitRet position; at position waitRet, it migrates to the TIMEOUT position when the clock t2 > 9, or enters the init position after receiving the signal of the c_subs_success channel; at the TIMEOUT position when t2 ≥ 10, the leftwaketime -= t2 action is executed and then it enters the init position; at the sleep position when the clock t > 50, the a_resotreInfo action is executed, the clock t is reset and it enters the init position. The corresponding TA CS_ROS The timed automaton is as Figure 4 shown. Other timed automata adopt a similar modeling method.

[0093] The timed automaton model of the subscription client agent on the XRCE-agent side is represented by 4 concurrent timed automata as TA PS = TA PS_RIS ||TA PS_HAS ||TA PS_FSWT ||TA PS_ROS , where TA PS_RIS , TA PS_HAS , TA PS_FSWT and TA PS_ROS respectively represent the automaton models of the reliable input stream, heartbeat response stream, timed message sender, and reliable output stream of the subscription client agent on the XRCE-agent side. Taking the timed automaton TA PS_FSWT of the timed message sender as an example, TA PS_FSWT can be represented as a six-tuple:

[0094]

[0095] Where:

[0096] ·Loc PS_FSWT represents the set of positions of the timed message sender in the model. Loc PS_FSWT= {clientSleep, clientWake, flushingMsg}, where clientSleep represents the position where the timed message sender infers that the client is sleeping, and it is also the initial position at the beginning; clientWake represents the position where the timed message sender learns through the channel that the client has woken up and is ready to send a message; flushingMsg represents the position where the timed message sender is in the process of sending a message.

[0097] · Represents the set of initial positions of the timed message sender in the model clientSleep represents the position where the timed message sender infers that the client is sleeping.

[0098] ·Act PS_FSWT Represents the set of events or actions for the timed message sender to migrate between the positions of inferring client sleep, learning that the client is awake and ready to send, and sending a message in the model, Act PS_FSWT = {a_set_pop_send_msg, c_start}, where c_start represents the communication-related events or actions, and a_set_pop_send_msg represents the actions to be executed after the guard condition is satisfied.

[0099] ·C PS_FSWT Represents the set of clocks of the timed message sender in the model, C PS_FSWT = {t, t2}, where t represents the clock for recording the awake time period, and t2 represents the clock for sending a message once.

[0100] ·Inv PP_HAS Represents the set of invariant functions of the heartbeat response processing flow in the model, Inv PS_FSWT = {Inv PS_FSWT (clientWake) = t < max_elappssed_time}. It means that the timed message sender cannot stay at the clientWake position for more than max_elappssed_time time units.

[0101] · Represents the set of transition relations of the heartbeat response processing flow in the model. The specific transition relations included in this set are as follows:

[0102]

[0103]

[0104]

[0105]

[0106]

[0107] The above five transition relations respectively represent that when the position clientSleep receives a signal in the c_start channel, it resets the clock t and migrates to the position checkSeq; when the condition g_send_queue_not_empty is satisfied at the position clientWake, it executes the action a_set_pop_send_msg, resets the clock t2 and migrates to the position flushingMsg; at the positions clientWake and flushingMsg, when t > max_elapsed, it migrates to the position clientSleep; at the position flushingMsg, when t2 > 1, it migrates to the position clientWake. The corresponding TA PS_FSWT time automaton is as Figure 5 shown. Other time automata adopt a similar modeling method.

[0108] Step 2: Use Matlab's Simulink / Stateflow as the modeling and simulation tool to implement the time automaton models of each module extracted in Step 1. Combine with a specific Micro XRCE-DDS application, and combine each module to construct a complete simulatable Micro XRCE-DDS application model for simulation. Specifically, use the Stateflow tool to convert the time automaton model established in Step 1 into a hierarchical state machine model that conforms to Stateflow rules. Among them, the specific conversion includes: using the after function to replace the time guards and invariants in the time automaton, using the elapsed function to calculate the accumulation and consumption of time, and using Event events to replace the channel completion synchronization in the time automaton, etc. Then, according to the specific scenario designed, combined with a specific application scenario of Micro XRCE-DDS, namely a camera as a publishing client, an alarm as a subscribing client, and a PC as a proxy, finally use Simulink to combine and simulate the entire model, and through the Scope component of Simulink, observe and analyze the simulation results in real time. If the analysis result is correct, it means that the model is established. If there are problems with the simulation results, rectify the inappropriate parts of the model until the model can run normally.

[0109] Step 3: Key properties related to message sending and receiving in Micro XRCE-DDS are extracted from the XRCE-DDS specification, such as all sent messages can be delivered, all subscribed messages can be received, no message will arrive to wake up during sleep after the client enters the sleep state, message reception is always sequential, when unaccepted messages are lost, the receiver can always detect it in time, and for all messages that subscribed clients have not successfully accepted, the subscribed client proxy will resend them in time, etc. And STL inf＝0 is used to formally represent these properties, where the syntax of STL inf＝0 is specified as follows:

[0110] At any moment The time interval I can be expressed as [m, n], where m < n, STL inf＝0 The inductive definition of the syntax is as follows:

[0111]

[0112] where p is an atomic proposition, a represents the upper bound of a time interval, a > 0, a ∈ I. φ1, φ2 represent basic STL inf＝0 formulas.

[0113] Other boolean operators and temporal operators can be derived from these definitions. For example, the imply operator and the time-bounded eventually and always operators can be expressed as:

[0114]

[0115]

[0116]

[0117] They represent φ1 implies φ2, eventually φ is satisfied before time a, and φ is always satisfied before time a, respectively.

[0118] Step 4: As Figure 7 shown, it is the process of the present invention to perform runtime verification on the established model by using Temporal Logic Assignments of Simulink Test in the Simulink / Stateflow toolbox. The key properties extracted in Step 3 and represented using STL inf＝0 are appropriately transformed to adapt to the format of logical verification in Temporal Logical Assignments. For example, the STL inf＝0 property "F [0,180]"client_pub_finished == 1" can be transformed into "At any point of time, whenever true is true, with a delay of at most 180 seconds, client_pub_finished == 1 must be true". Based on the Simulink / Stateflow model obtained in Step 2 that can be normally simulated, perform runtime verification, analyze the verification results. According to the analysis results, if it is found that some key properties are not satisfied, it indicates that there are related defects in the XRCE-DDS code implementation or open-source implementation. Then, find the relevant reasons for the defects through the provided counterexamples and make corresponding modifications. If it is a problem with the Simulink model itself, modify the Simulink / Stateflow model. If it is not a problem with the model itself, it indicates that there is a problem with the open-source implementation of MicroXRCE-DDS. Modify the functional implementation code of the corresponding module, re-abstract the formal model, and modify the Simulink / Stateflow model. After the modification, use Simulink Test to perform runtime verification again. If the verification is correct, it indicates that the established simulation model and the source code of Micro XRCE-DDS are correct. Otherwise, repeat Step 4 until all verification results satisfy the key properties.

[0119] Embodiment

[0120] This embodiment takes Figure 6 one XRCE-Client1 in [reference] as the publishing client, one XRCE-Client2 as the subscribing client, and one XRCE-Agent as the proxy. Taking the example of the instance where the three transmit messages, perform modeling and simulation according to the v2.2.0 version of the open-source Micro XRCE-DDS of eProsima company, and model, simulate, and verify the model and the application where two XRCE-Clients and one XRCE-Agent communicate.

[0121] In this embodiment, the runtime verification of the key properties in the "DDS for eXtremely Resource Constrained Environments v1.0" specification that need to be satisfied by the v2.2.0 version of the open-source Micro XRCE-DDS of eProsima company is carried out by using the modeling and simulation and formal verification methods of the Micro-ROS communication middleware Micro XRCE-DDS of the present invention. The verification results are analyzed, and the correctness of the open-source implementation version of Micro XRCE-DDS v2.2.0 is obtained. The specific steps are as follows:

[0122] Step 1: Based on the implementation of the v2.2.0 version of the open-source Micro XRCE-DDS of eProsima company and combined with the XRCE-DDS specification, a model of the Micro XRCE-DDS communication process is established. This model includes five modules required in the XRCE-DDS communication process. Among them, the publishing client and the subscribing client are of the same type and are modules located on devices with extremely resource-constrained environments. Therefore, they need to meet the characteristics of low power consumption, not supporting TCP, packet loss in a poor network environment, and even having a certain sleep cycle. They respectively publish messages and subscribe to messages to the XRCE agent. The XRCE agent consists of three modules, namely the agent message transceiver, the publishing client agent, and the subscribing client agent. These three modules are generally located on the same device with relatively rich resources, and the performance of such a device is sufficient to support the requirements of DDS (Data Distribution Service). The agent message transceiver will receive the messages sent by each client and deliver them to each publishing client agent and subscribing client agent. After receiving the messages, the publishing client agent and the subscribing client agent will process the messages and respond to the publishing client and subscribing client they are responsible for. Specifically, processing the message means that the former transmits the message to the DDS domain, and the latter obtains the corresponding message from the DDS domain and sends it to the subscribing client. The sub-modules extracted from each large module can be flexible to ensure reliable message sending and sufficient processing. Among them, for the client, the receiver is mainly responsible for receiving messages from the outside world and delivering them to the reliable input stream and the heartbeat response stream according to the message type. After the message processing is completed, if necessary, the reliable output stream will generate feedback messages, and the heartbeat response stream will generate corresponding responses or heartbeat messages and deliver them to the message sender, waiting for the sender to send the messages one by one; for the agent, the agent message transceiver serves as a unified receiver, and the publishing client agent and the subscribing client agent only need at most four sub-modules: the reliable input stream, the reliable output stream, the heartbeat response stream, and the sending stream.

[0123] In this embodiment, the publishing client sends reliable data to the XRCE proxy. Since there is a certain probability of data loss, a heartbeat-response mechanism is required to ensure reliable message sending in the case of a certain probability of data loss. The subscribing client has a sleep periodicity. It needs to enter the sleep state within a certain period of time and wake up after a certain period of time. When in the wake-up state, it will first send a subscription message to the proxy, notifying the proxy that it can send the messages of the subscribed topic, and at the same time will inform the subscribing client of the relevant transmission method and the next sleep time. Then it can wait for the proxy to send messages. Similarly, there is a probability of data loss in the data transmission process, and a heartbeat-response mechanism is required to ensure reliable message sending. According to specific requirements, the publishing client in this embodiment only has a reliable input stream, a reliable output stream, a heartbeat response stream, and a message sending stream. The subscribing client has all five sub-modules, while the sending client proxy only has a reliable input stream, a heartbeat response stream, and a sender. The subscribing client proxy has a reliable input stream, a reliable output stream, a heartbeat response stream, and a sender.

[0124] Step 2: Use the Simulink / Stateflow tool of the modeling and simulation tool Matlab to hierarchically model the five modules extracted in Step 1 in five Stateflow blocks in a graph programming manner, and then combine these modules in Simulink into a model that can be simulated. Specifically, use the Stateflow tool to establish a hierarchical timed automaton model for each module and its sub-functions, use probability functions and SimEvent components to represent the loss and transmission of messages in the communication process, and finally use Simulink to run and simulate the entire model, and use the Scope component to analyze the simulation results in real time. If problems are found in the model through the analysis of the simulation results, rectify the inappropriate parts of the model until the model can run normally for simulation.

[0125] Step 3: Extract 7 properties from the "DDS for eXtremely Resource Constrained Environments v1.0" specification, including: all sent messages can be delivered, all subscribed messages can be received, no messages will arrive to wake up during the sleep period after the client enters the sleep state, the reception of messages is always sequential, when the unaccepted messages are lost, the receiver can always detect it in time, and for all messages that the subscribing client fails to accept successfully, the subscribing client proxy will re-send them in time. Then use STL inf＝0 to formally express these properties.

[0126] Step 4: The ones extracted in Step 3 and using STLinf＝0 Appropriately transform the key properties expressed, and convert them into a format suitable for logical verification by the Temporal Logical Assignments component of the Simulink Test runtime verification in the Simulink toolbox. Then, perform runtime verification of these properties on the Simulink / Stateflow model that can run normally obtained in the second step, and analyze the verification results. It is found that all 7 verified properties are satisfied.

[0127] In this example, the modeling and simulation as well as formal verification method of the present invention for the Micro-ROS communication middleware Micro XRCE-DDS are used to perform modeling and simulation and runtime verification on the v2.2.0 version of the open-source Micro XRCE-DDS of eProsima. Through the above steps, the reliability and security of Micro XRCE-DDS v2.2.0 are proven. Thus, it shows that in an environment with extremely limited resources, the Micro-ROS robot application using Micro XRCE-DDS v2.2.0 as the communication middleware has satisfactory reliability and security.

[0128] The protection scope of the present invention is not limited to the above embodiments. Without departing from the spirit and scope of the inventive concept, all changes and advantages that can be conceived by those skilled in the art are included in the present invention, and the scope of protection is defined by the appended claims.

Claims

1. A method for modeling, simulation and formal verification of the Micro-ROS communication middleware, characterized in that It includes the following steps: Step 1: According to the open-source Micro XRCE-DDS implementation code, extract the behavioral modules included in the MicroXRCE-DDS Agent and Micro XRCE-DDS Client in Micro XRCE-DDS, and perform formal modeling of each module based on timed automata; Step 2: Based on the timed automata model established in Step 1, use modeling and simulation tools, combined with scenario applications, to implement and simulate the Micro XRCE-DDS communication process. According to the simulation results, modify the model until the model can be normally simulated and executed; Step 3: Extract the key properties to be verified in the communication process from the natural language description of the XRCE-DDS specification, and use Signal Temporal Logic (STL) with a lower bound of 0 to inf＝0 describe the key properties; the key properties include reliable sending from the client to the broker, reliable sending from the broker to the client, sequential reception of messages by the receiver, no disturbance during the client's sleep period, the receiver can know when the sent message is lost, and the lost message will be resent; Step 4: Combine with the runtime verification tool to perform runtime verification on the key properties described in the STL proposed in Step 3 on the model simulation implemented in Step 2, and analyze the verification results; inf＝0 ​ In Step 4, formal verification is performed on the key properties on the established model simulation, and the verification results are analyzed, including the following steps: Step D1: Represent in the runtime verification tool that supports temporal logic in a form that conforms to the tool's rules based on the properties of the formalized STL inf＝0 properties Step D2: According to the established timed automata model, perform runtime verification on the properties that conform to the tool rules in Step D1, and analyze the verification results; Step D3: If there are counterexamples in the verification results of Step D2 that do not satisfy one or more key properties, find the time-states that do not satisfy the key properties according to the path states of the counterexamples, and execute Step D4; otherwise, a formally verified XRCE-DDS communication mechanism model simulation is obtained; Step D4: According to the paths and time-states of the counterexamples given in the formal verification tool, analyze the possible error causes. If the model is problematic, improve and modify the model. If the problem lies in the source code, modify the corresponding function implementation code and return to perform the abstraction of the timed automata model again.

2. The method for modeling, simulation and formal verification of the Micro-ROS communication middleware Micro XRCE-DDS according to claim 1, characterized in that, In Step 1, the timed automata is a modeling method that formally describes the state transition and change of a real-time system through a finite automaton with a clock set. Using the timed automata model to perform formal modeling of Micro XRCE-DDS ensures that the behavioral model exhibits the time characteristics of the system.

3. The method for modeling, simulation and formal verification of the Micro-ROS communication middleware Micro XRCE-DDS as claimed in claim 1, characterized in that, Step 2, through the modeling and simulation tool, implementing and simulating the established timed automata model includes the following steps: Step B1: According to the timed automata models of the established behavioral modules, combined with the modeling and simulation tools that support state machines or automata, perform corresponding model implementations respectively; Step B2: Combined with an application scenario of Micro XRCE-DDS communication, construct a complete Micro XRCE-DDS application simulation model by combining the specific model implementations established in Step B1, showing the client-agent relationship and the send-receive process in the communication; Step B3: According to the complete Micro XRCE-DDS application simulation model constructed in Step B2, perform model simulation in the modeling and simulation tool, visualize the simulation results of the model through the visualization components in the modeling and simulation tool, observe the simulation results, and analyze the simulation results; Step B4: According to the analysis results in Step B3, if it is found that there are parts that do not conform to the facts during model simulation, or factors that affect the normal simulation of the model, then Steps B1, B2, B3, and B4 are re-executed until the model simulation results are normal; if no parts that do not conform to the facts or factors that affect the normal simulation of the model are found, it means that the modeling and simulation process is completed.

4. The method for modeling, simulation and formal verification of the Micro-ROS communication middleware Micro XRCE-DDS as claimed in claim 3, characterized in that, In Step B4, the factors that affect the normal simulation of the model include setting the simulation time too short and some time parameters being unreasonable.

5. The modeling and simulation and formal verification method of the Micro-ROS communication middleware Micro XRCE-DDS as described in claim 1, characterized in that, Step 3 extracts properties from the XRCE-DDS specification and uses STL inf＝0 The expression includes the following steps: Step C1: Extract the key properties related to Micro XRCE-DDS in sending and receiving messages from the XRCE-DDS specification. The natural language description includes properties such as all sent messages can be delivered, all subscribed messages can be received, no messages will arrive to wake up during the sleep period after the client enters the sleep state, the reception of messages is always sequential, when unaccepted messages are lost, the receiver can always detect it in time, and for all messages that are not successfully accepted by the subscribed clients, the subscribed client proxy will re-send them in time. Step C2: Improve based on Signal Temporal Logic (STL), modify the time range represented by it to be more applicable to the description of the key properties extracted in Step C1, and propose a Signal Temporal Logic (STL) with a lower bound of 0 inf＝0 ; Step C3: Use the STL in Step C2 inf＝0 to formalize the key properties described in natural language in Step C1; The formal description of the key properties is as follows: All sent messages can be delivered: F [0,180] client_pub_finished = 1; All subscribed messages can be received: F [0,180] client_received_all = 1; After the client enters the sleep state, no more messages will arrive during sleep to wake it up: G [0,180] subClient_statue = 1 → F [0,50] subClient_receiveSig = false; The reception of messages is always sequential: G [0,180] publisher_last_received≥10 → VedioInfo = TDDS && G 0,180 subscriber_last_received≥10 → GetInfo = FDDS; When an unaccepted message is lost, the receiver can always detect it in time: G [0,180] (missing_fig = 1 && sendMissSeq < last_receive) → F [0,20] findMissSeq = sendMissSeq; For all messages not successfully received by the subscribed clients, the subscribed client agent will promptly resend them: G [0,180] (last_sent>last_ack+1→F [0,20] last_sent = last_ack+1).

6. The method for modeling, simulation, and formal verification of the Micro-ROS communication middleware Micro XRCE-DDS according to claim 1, characterized in that, In Step 4, if a key property is not satisfied during runtime verification, based on the provided counterexample, determine whether it is a problem with the model itself. If it is a problem with the model itself, then return to Step 2 to correct the model. If it is not a problem with the model itself, it means that the implementation of the Micro XRCE-DDS communication middleware does not satisfy the properties in the XRCE-DDS specification. Modify the code, return to Step 1, and correct the model until runtime verification satisfies all the key properties to be verified. If all the key properties have been satisfied, it proves the correctness of the modeling and simulation of the Micro XRCE-DDS communication middleware, and a correct Micro XRCE-DDS communication middleware model is obtained.

Images