A Modular Digital Twinning Framework for Safety Assurance of Collaborative Robotics

Abstract

Digital twins offer a unique opportunity to design, test, deploy, monitor, and control real-world robotic processes. In this paper we present a novel, modular digital twinning framework developed for the investigation of safety within collaborative robotic manufacturing processes. The modular architecture supports scalable representations of user-defined cyber-physical environments, and tools for safety analysis and control. This versatile research tool facilitates the creation of mixed environments of Digital Models, Digital Shadows, and Digital Twins, whilst standardising communication and physical system representation across different hardware platforms. The framework is demonstrated as applied to an industrial case-study focused on the safety assurance of a collaborative robotic manufacturing process. We describe the creation of a digital twin scenario, consisting of individual digital twins of entities in the manufacturing case study, and the application of a synthesised safety controller from our wider work. We show how the framework is able to provide adequate evidence to virtually assess safety claims made against the safety controller using a supporting validation module and testing strategy. The implementation, evidence and safety investigation is presented and discussed, raising exciting possibilities for the use of digital twins in robotic safety assurance.

Keywords: automated code generation; collaborative robot safety; digital twins; human-robot collaboration; modular framework; probabilistic model checking; risk-informed software synthesis; robotics.

FIGURE 1

An isometric view of the CSI framework environment applied to a collaborative welding cell case-study. Based in Unity^® 3D, digital twins of an operator, collaborative robot manipulator, safety scanner and light-barrier are shown.

FIGURE 2

An overview of the relationships between entity modules, behaviour modules and service modules. Entity modules may invoke service or behaviour modules as part of their behavioural “stack”. The composition of the stack is an aggregation of custom behaviours and inherited modules from broader entity classifications.

FIGURE 3

An overview of the CSI modular digital twin framework, entity (blue), service (green) module libraries, behaviour (grey) modules and their integration with the core framework (yellow). User configured modules and extensions to the standard environment are shown as dashed.

FIGURE 4

An overview of the CSI framework workflow. Initially (P1), the user creates their scenario, modules and configures them. In the execution phase (P2), the scenario is processed and may be interacted with during runtime. During runtime, configured logging behaviours write to the user’s database(s) (i.e., SQLite, MySQL). This log data is parsed and imported in the Analysis phase (P3). A provided database API provides convenient interface for the users external tools.

FIGURE 5

A side by side view of the physical (left) and digital (right) twins in an existing real-world industrial welding process.

FIGURE 6

An overview of the state machines defining the behaviour of the welder in the welding cell, highlighting the interactions between the process and safety layers. An excerpt of the safety controller state machine is included to highlight the control of the safety mode and welder activity. The transitions capture both the messages sent, and the guard enabling the transition. (A) Welder safety behaviour model. (B) Welder process behaviour model. (C) Except of the safely controller behaviour model, including abstract state core to highlight controller actions.

FIGURE 7

Safety controller module sample code depicting the structure of the safety controller.

FIGURE 8

Spot welder safety mode transition sample code (Figure 6)

FIGURE 9

Example of a safety predicate used for verification, expressed as a temporal logic formula. It ensures that if at any time in the events trace hazard HC occurs in the work cell, as defined by the safety analysis, it is later mitigated by the safety controller. It cannot be ignored, or let to disappear unacknowledged.

FIGURE 10

System configuration during testing, the time spent by the operator at each of the labelled waypoint is exposed as a configuration variable.