Model-Based Formal Specification and Verification of Robotic Systems

Enabling formal verification of robotic systems by developing models that cope with the intractable state space of complex robotic system software and improving the verification coverage and assurance on the operation of robotic systems by using the formal methods in combination with runtime verification.

The software of autonomous robot systems is generally complex and safety critical. Therefore, formal specification and verification is a rather challenging task. Widely used testing and simulation alone are insufficient to ensure the correctness and safety of the system [MBF1, MBF2]. Although the software of robot systems is complex, fortunately, it can be designed as interacting but separate modules [MBF3]. Many people in the robotics research community use the robot operating system (ROS) which is a framework. Due to the modular structure of robot software, ROS allows the control of a robot to be carried out by functional modules operating as separate processes. A simple control scheme of a mobile robot system has multiple functional modules. Although the robotic inspection system (UC11) is targeted for verification, many industrial robot systems perform similar stages. Thus, the realization of the tasks performed by industrial robot systems takes place in a hierarchical series of stages. If the robot autonomy is increased, e.g., re-planning when the environment state changes and moving by feedback from the sensors that detect the environment during the movements, there may be a mutual flow between the stages and stages can become more complex. 

In the formal verification of robotic systems with model checking methods, the widely preferred and suitable model is timed automata [MBF5, MBF6]. Moreover, run-time verification methods are applied to robotics systems. Users provide formal safety and security specifications, and monitors are automatically generated and incorporated into the system to ensure the safety and security of robots [MBF7]. Model-checking, when combined with runtime verification, will improve the verification coverage and assurance on the operation of robotic systems [MBF4]. Verification methods to be used to verify the safety of robotic systems must comply with standards such as ISO 12100, IEC 61508, ISO 13849, ISO 10218-1, ISO 10218-2, ISO TS 15066 [MBF9, MBF10]. 

The method is implemented in two stages. In the first stage, once the requirements are given, the formal model of the robotic system is created. Then, by using the model-checking technique, the model is verified whether it meets the requirements or not. If not, the model is recursively revised until it meets all the requirements. In the second stage, the software of the robotic system is developed accordingly with the verified model. Then, the system software is subjected to runtime verification during execution integrating with the real system or a simulated environment. 

  • Less time-consuming comparing to simulation-based for limited state space.
  • Once the system model and property specification are provided to the model checker, the verification process is fully automatic.
  • Long simulation runs are not required to obtain adequate coverage
  • The verification results do not rely on the test cases' quality; in fact, the algorithms prove correctness for all test cases.
  • Require minimal human intervention in the verification process. So, human error is minimized.
  • The system should be small in terms of the number of states to be processed by the model checker within a reasonable completion time.
  • Errors in specification: An implementation verification requires two versions of a design. Therefore, a bug in the specifications voids the reference model may escape implementation verification and may trickle down to implementations. A typical type of specification error is missing specifications [MBF8]. 
  • Incomplete functional coverage of specifications: Formal methods verify properties that, of course, can be specifications. In practice, however, it is rare that all specifications are given to a formal checker on the complete design, because of memory and runtime limitations. A partial specification is checked against the relevant portion of the design. Therefore, it leaves the door open to errors resulting from not checking all properties mandated by the specifications and from situations when, for example, a property succeeds on a subcircuit but does not succeed on the whole circuit. 
  • User errors: Example user errors are the incorrect representation of specifications and over constraining the design. 
  • Formal verification software bugs: Bugs in formal verification software can miss design errors and thus give false confirmation. It is well-known that there is no guarantee for a bug-free software program. 
  • Formal specification languages need to be adopted for Autonomous Industrial robots 
  • A lack of clear guidance when it comes to choosing a suitable form for a particular system. 
  • Identifying what is anomalous, without exhaustive knowledge of the concept of anomaly, requires the existence of an underlying concept of normality. For this reason, it may be difficult to detect attacks that can be made while recognizing normal data on the system side during the initial start-up phase of the system.  
  • [MBF1] Luckcuck, M., Farrell, M., Dennis, L., Dixon, C., Fisher, M. (2019), Formal Specification and Verification of Autonomous Robotic Systems: A Survey, ACM Computing Surveys, 52: 1-41. 
  • [MBF2] Ingrand, F., (2019), Recent Trends in Formal Validation and Verification of Autonomous Robots Software. 2019 Third IEEE International Conference on Robotic Computing (IRC). 
  • [MBF3] Siegwart, R. and Nourbakhsh, I, (2004), Introduction to Autonomous Mobile Robots, MIT Press. 
  • [MBF4] Desai, A., Dreossi, T., Seshia, S.A., (2017), Combining Model Checking and Runtime Verification for Safe Robotics, Runtime Verification RV 2017, LNCS 10548, pp. 172–189. 
  • [MBF5] Wang, R., Guan, Y., Song, H., Li, X., Li, X., Shi, Z., Song, X., (2018), A Formal Model-Based Design Method for Robotic Systems, IEEE Systems Journal, PP: 1-12. 
  • [MBF6] Halder, R., Proença, J., Macedo, N., Santos, A (2017), Formal Verification of ROS-Based Robotic Applications Using Timed-Automata, 2017 IEEE/ACM 5th International FME Workshop on Formal Methods in Software Engineering (FormaliSE). 
  • [MBF7] Huang, J., Erdogan, C., Zhang, Y., Moore, B., Luo, Q., Sundaresan, A., Rosu, G., (2014), ROSRV: Runtime Verification for Robots, International Conference on Runtime Verification, Springer. 8734: 247-254. 
  • [MBF8] W.K. Lam, Hardware Design Verification: Simulation and Formal Method-Based Approaches, Pearson Publishing, 2005. 
  • [MBF9] Villani, V. P., F. Leali, F. Secchi, C. (2018), Survey on human-robot collaboration in industrial settings: Safety, intuitive interfaces and applications, Mechatronics, 55: 248-266. 
  • [MBF10] Jérémie Guiochet, M. M., Hélène Waeselynck (2017). "Safety-critical advanced robots: A survey." Robotics and Autonomous Systems, 94: 43-52. 
  • [MBF11] Sánchez, C., Schneider, G., Ahrendt, W., Bartocci, E., Bianculli, D., Colombo, C., Lourenço, J. M. J. F. M. i. S. D. (2019). A survey of challenges for runtime verification from advanced application domains (beyond software). 54(3), 279-335  
Method Dimensions
In-the-lab environment
Experimental - Monitoring, Analytical - Formal
Model, Software
Implementation, Operation, Detail Design
Thinking, Acting, Sensing
Non-Functional - Safety, Functional, Non-Functional - Security
V&V process criteria, SCP criteria
Relations
Contents

There are currently no items in this folder.