RRS stands for “Realistic Robot Simulation” and consists of two interface standards (RRS-I and RRS-II) that primarily allow the behavior of simulated robots to be based on actual robot controller algorithms without requiring robot vendors to disclose details of these proprietary algorithms to simulation software vendors. DELMIA (earlier through Deneb Robotics and Dassault Systemes) has been actively involved in the development of the RRS standard since the very beginning. All DELMIA robot simulation products (V6, V5, D5) support (at least some version of) the RRS standard.

Before RRS, robot behaviour in simulation software was exclusively based on parametric robot kinematics/dynamics models well documented in robotics literature. Manipulator-specific parameters were set based on what little data was made available by robot vendors on robot data sheets. RRS originated in the early 90s when it became clear that virtual robot behavior based on these models, even after careful parameter tuning, did not meet the stringent robot simulation accuracy requirements of OEMs in highly automated/high volume manufacturing sectors (such as automotive) where economic realities dictate that robotic production lines be highly optimized to achieve the fastest throughput while occupying the smallest real estate.

Seeds of RRS-I, the first of two RRS standards, were planted through a European automotive industry project initiated in Munich, Germany in 1991. The overall RRS project is still managed by Fraunhofer IPK in Berlin, Germany and early OEM drivers included Adam Opel, Audi/Volkswagen, BMW, Ford, Mercedes-Benz, Peugeot/Citroen, Renault and Volvo. Technical work on the RRS-I standard started in January 1992 and the first official version was announced in Jan 1994. Since then some minor enhancements have been made to the RRS-I spec through annual RRS-I standard maintenance meetings. The goal of the RRS-I effort was to reduce joint value errors to less than 0.001 radians and motion time errors to less than 3%.

In the RRS-I functional model, the robot vendor supplied black box is called the “RCS (Robot Controller Simulation) module” and consists of just the motion controller (and kinematics) modules of the real robot controller software. The special formatting of the input data passed by the simulation software and the special formatting of the response data generated in return by the RCS module when invoked ends up defining the roughly 60+ “RRS-I calls” that make up the RRS-I spec. Functionally these calls allow: initializing the RCS module as either a default or custom robot controller (the latter via machine data files imported from the actual robot controller), setting motion attributes and target for a new robot move, fetching interpolated robot joint values as the RCS module executes the move, setting up time/robot position-based RRS events, notification about controller errors/warnings and triggered RRS events during simulation, fetching controller issued messages, invoking forward and inverse kinematics capabilities of the RCS module, setting up conveyor tracking and passing conveyors’ instantaneous position to the RCS module, etc. While the RRS-I spec documents the details of each RRS-I call, it does not dictate that all calls be supported by RCS modules and, more importantly, the order in which these calls should be made. This flexibility allows each robot vendor to customize their RCS module implementation to best suit the inner workings of their own controllers. This in turn has resulted in DELMIA introducing multiple, controller-specific RRS-I interface modules (DLLs) for DELMIA robot simulation products (V6, V5, D5) to communicate with the various RCS modules currently supported (which includes various versions of ABB, Comau, Duerr [V5/D5  only], Fanuc, Hyundai, Kawasaki [D5 only], Kuka, Nachi, and Yaskawa/Motoman RCS modules). Also, since robot vendors typically release their RCS modules on a limited set of platforms, in order to support RRS on all DELMIA product platforms, robot vendor RCS modules are embedded inside “DELMIA RCS Server” applications that can run on remote machines and still allow DELMIA products running on different machines to invoke its embedded RRS-I capabilities. The communication between DELMIA products and DELMIA RCS servers happen using a proprietary TCP/IP-based protocol that is adopted by all DELMIA robot simulation products (hence the same DELMIA RCS server can service V6, V5, and D5 RRS-I requests).

While RRS-I was a major success resulting in wide adoption by OEMs and robot vendors (true to this day), a follow up survey on RRS-I use at major European automotive OEMs (documented in a 1997 report entitled “RRS Status and Cost Benefit Relation of Future Activities”) revealed some shortcomings mainly having to do with the incompleteness of the robot controller model embodied by the RRS-I RCS module including:

• inability to simulate the full instruction set of the robot controller (including logic and I/O instructions),
• difficulty in translating some of the more complex robot controller motion commands into RRS-I instructions,
• long turnaround associated with making new controller features available in RRS simulation (due to having to extract and then package an internal component of the real robot controller in the form of an RRS-I RCS module and then the careful controller-specific customizations required on the simulation software side to support it),
• inability to directly simulate existing shop floor programs (without having to upload them and be exposed to potential upload limitations).

To address these shortcomings, work on a new standard called “RRS-II” was initiated in April 1998 with the final official version being released in January 2004.

In the RRS-II model, the robot vendor developed black box, now called the “VRC (Virtual Robot Controller) module”, embodies the complete robot controller software. This makes new controller features to become available in RRS simulation much faster than in RRS-I. Perhaps most importantly, RRS-II technology allows the actual robot program (which is the end product of the overall Offline Programming process) to first be highly accurately tested in the virtual simulation environment by having it executed by the real robot controller software (which may also be running on the real robot controller hardware). Besides allowing “ultimate accuracy” simulation of the full robot controller instruction set, RRS-II also allows:

• accurate accounting of instruction interpretation and in-controller I/O signal travel delays,
• simulation of complex controller configurations/capabilities like multiple motion group support and cooperating robot simulation (which the RRS-I spec was not designed to support),
• invoking robot vendor developed external “VRC User Interface applications” (like virtual teach pendants) that allow the control of the DELMIA virtual robots through user interaction with realistic looking virtual robot controller user interfaces (nice for robot controller user training),
• booting up of VRC instances from full robot controller backups,
• “hardware-in-the-loop simulation” for robotic cell Virtual Commissioning applications by running VRC modules on actual robot controller hardware that may even be wired up to other physical devices in the cell via system bus interfaces supported by the controller hardware (or real PLCs by going through DELMIA Automation when using V5).

Unlike the RRS-I RCS module, the RRS-II VRC module is delivered by robot vendors as a complete ready-to-use (executible) package. It consists of two components (called the VRC Manager and VRC Instance) that each communicate bi-directionally with the simulation software using the ONC RPC (Remote Procedure Call)-based RRS-II protocol that embodies some 90+ “RRS-II calls”. Unlike the large number of controller-specific RRS-I interface DLLs that are needed for communicating with the various RRS-I RCS modules, DELMIA RRS-II simulation products (V5 and V6) provide a much smaller set of RRS-II interface modules (DLLs/EXEs) in order to communicate with the two classes of VRC modules that are out there:

• Virtual Time Managed (VTM) VRC modules (like Kawasaki, Nachi, Fanuc beta and Yaskawa/Motoman beta) whose internal timing is strictly advanced by the V6 simulation clock,
• Real Time Managed (RTM) VRC modules (like Kuka) whose internal clocks run (always or at times) in real time independent of the V6 simulation clock.

To enhance the RRS-II simulation user experience, DELMIA has introduced some unique features like “RRS-II automatic download” that allows the automatic and “as required” invocation of OLP download to generate the native robot program(s) corresponding to the robot task(s) invoked for simulation and its immediate loading and execution by the VRC module (currently available only in V5 but soon to be made available in V6 too), and “VRC applicative command simulation” that allows the simulation of simulator-only behaviors (like paint activities) when the VRC module executes technological commands (like paint gun on/off, etc.) in the robot program during RRS-II simulation.

DELMIA RRS-I and RRS-II solutions are currently being used in production at various locales around the world. For further details on RRS, please visit http://www.realistic-robot-simulation.org.