Patent Description:
Simulation of physical systems may be used, for example, for predicting behavior of real objects or for explaining behavior of past events, among other applications. A rigid body simulation is a method where moving objects are represented as point bodies in space. The inertia of the bodies may be determined over time using various methods and constraints between the bodies and physical properties, such as contact forces.

In some applications, the systems of objects that users create to be simulated may span many hundreds of entities. These include parts that move as well as objects that are attached to these parts. Furthermore, objects may become attached to other objects or get separated from previously attached objects dynamically over the course of simulation.

In general, a physical simulation uses significant computational resources. Making simulations faster may allow more complex simulations to be run within a given resource budget. A system that performs functions using simulation as one aspect may be able to devote more resources to other functions, such as image manipulation, or motion planning, if the simulation can be made more efficient.

The document <CIT> discloses methods for simulating the motion and collision of objects.

The document <CIT> discloses methods for preparing a mechanical model for a dynamic simulation, including identifying a first plurality of bodies in a mechanical model and each of the bodies in the first plurality of bodies being related to at least one other body by at least one constraint that removes or limits at least one degree of freedom for that body in relation to another body.

The document <CIT> discloses methods for simulating the motion of three-dimensional models.

Aspects of the present disclosure address at least some of the above-mentioned technical challenges, by providing a technique for automatic optimization of a physical simulation to improve simulation performance.

The present invention is defined by the enclosed claims.

According to a first aspect of the disclosure, a computer-implemented method is provided for simulating motion of objects. As per the method, a computer creates a three-dimensional model system comprising a plurality of bodies, wherein each body comprises one or more collision surfaces and one or more visual surfaces. The computer identifies one or more groups of bodies from the plurality of bodies, such that bodies belonging to a group are constrained in relation to each other by fixed joints. The computer processes each group of bodies, such that: if a group of bodies comprises a background object as a constituent body, then all constituent bodies of the group are removed while preserving the respective collision surfaces and visual surfaces; if a group of bodies does not comprise the background object as a constituent body, then the group of bodies is modeled as a single merged body, the merged body having defined mass properties, position and orientation determined based on mass properties and structure of constituent bodies of the group. The computer then executes a simulation code solving rigid body dynamics for the model system based on said processing of each group of bodies.

According to a second aspect of the disclosure, a non-transitory computer-readable storage medium is provided, the computer-readable storage medium including instructions that when executed by a computer, cause the computer to perform the above-described method.

According to a third aspect of the disclosure, a system is provided for simulating an automation application. The system comprises a modeling unit configured for creating a three-dimensional model system representing an industrial environment, the model system comprising a plurality of bodies representing physical components of the industrial system, wherein each body of the model system comprises one or more collision surfaces and one or more visual surfaces. The system further comprises a simulation engine configured for identifying one or more groups of bodies from the plurality of bodies, such that bodies belonging to a group are constrained in relation to each other by fixed joints and processing each group of bodies. The simulation engine processes each group of bodies, such that: if a group of bodies comprises a background object as a constituent body, then all constituent bodies of the group are removed while preserving the respective collision surfaces and visual surfaces; if a group of bodies does not comprise the background object as a constituent body, then the group of bodies is modeled as a single merged body, the merged body having defined mass properties, position and orientation determined based on mass properties and structure of constituent bodies of the group. The simulation group is further configured for executing a simulation code solving rigid body dynamics for the model system based on said processing of each group of bodies.

The foregoing and other aspects of the present disclosure are best understood from the following detailed description when read in connection with the accompanying drawings. To easily identify the discussion of any element or act, the most significant digit or digits in a reference number refer to the figure number in which the element or act is first introduced.

<FIG> illustrates an example of a simulation system <NUM>, according to an aspect of the present disclosure. In the shown embodiment, the simulation system <NUM> is implemented at an automated production site. At the production site, a user <NUM> may utilize a user computer <NUM> to execute an engineering tool <NUM>. The engineering tool <NUM> may allow the user <NUM> to download models of physical components/devices of the production site, such as one or more conveyors <NUM>, motors <NUM> and robots <NUM>, among others. The models may be available from component suppliers, for example, via marketplace servers (not shown). The engineering tool <NUM> may be configured to create a system design of the industrial environment based on one or more instructions from the user <NUM>. The engineering tool <NUM> may comprise a modeling unit which may utilize the downloaded models to create a three-dimensional model system from the system design, a simulation engine to carry out a simulation of the model system performing computations that mimic the physical activities of the modeled items, and a graphical user interface for displaying the simulation of the model system. In an exemplary embodiment, the engineering tool <NUM> may comprise a dynamics simulation engine that may be embedded within a 3D graphical editor and visualization environment. The simulation engine may be configured to simulate the physical activity of hardware devices and the work products that the devices manipulate and transform. The physical objects being simulated may be representative of actual hardware devices. The simulation for a given device is formulated to match the behavior of that device and to perform the same actions under the same input conditions within the capability of the simulation. The simulation may track the geometric shape, position, kinematic linkages, and dynamics of the objects. The simulation may compute the internal state and logical activity of the objects such as electrical or programmatic activity. The simulation may also include the ability to add and remove objects from the simulation dynamically. This ability can be used to simulate the transformation of objects such as cutting, crushing, and shaping. It may also be used to simulate the introduction and removing of work products from the process.

By simulating an industrial environment, the user <NUM> can easily identify the necessary physical components and layout needed to enable a particular process. Once the layout has been determined, the engineering tool <NUM> can generate additional details (e.g., a parts list and/or blueprint) so that the necessary physical components can be ordered (if they have not been purchased already) and configured in the desired layout. Additionally, in some embodiments, the engineering tool <NUM> may generate controller code that may be used directly on physical components such as programmable logic controllers. The generated controller code may also be deployed directly on the physical component itself for components that have this capability. For example, in <FIG>, the engineering tool <NUM> can generate controller code <NUM> that may be utilized directly on the controllers associated with the physical devices <NUM>, <NUM> and <NUM>. Thus, installation of the physical devices is streamlined since the controller code <NUM> is ready for use soon after the system design is completed. Additionally, in some embodiments, the engineering tool <NUM> may be configured to directly integrate live data <NUM> from the simulation system <NUM>. To this end, the simulation system <NUM> may comprise a network interface <NUM> may be provided facilitate transfer of data between the engineering tool <NUM> and the industrial environment.

<FIG> shows a flowchart illustrating an exemplary method <NUM> for simulating motion of physical objects. The described method <NUM> may be used, for example, for simulating an automation application as referred to in <FIG>. Block <NUM> of the method <NUM> comprises creating a three-dimensional model system comprising a plurality of bodies, which represent physical objects or components in an industrial environment to be simulated. In the illustrated embodiment, the model system may be created by a modeling unit of the engineering tool <NUM>. The model system may be created, for example, from a system design of the industrial environment based on one or more instructions from a user.

<FIG> shows an example of a model system <NUM> representing an industrial environment comprising a robot <NUM> configured to operate a CNC machine <NUM>. The model system's objects or bodies may be derived, at least in part, from simulation objects and other kinds of CAD design. In future applications, it might also be possible to derive objects of the model system <NUM> from sensor data. For example, if the automation application has cameras, the model system <NUM> could comprise objects that the camera algorithms detect. The engineering tool <NUM> may still be employed to define these objects and to construct the semantics in the different domains that the system can recognize.

In the model system <NUM>, the robot <NUM> and the CNC machine <NUM> are attached to a stationary table <NUM>(or floor). Since the table <NUM> is stationary, it may be considered as being attached to a fixed background <NUM>. The robot <NUM> and the CNC machine <NUM> are each made up of multiple bodies, which may be declared by the user as distinct rigid bodies (i.e., moving bodies) for the purpose of simulation. For example, the robot <NUM> comprises a robot base <NUM>, multiple robot arms <NUM>, a robot flange <NUM>, a torque cuff <NUM>, a camera mount <NUM>, a camera <NUM>, a grip adapter <NUM>, a grip base <NUM> (or gripper), multiple grip fingers <NUM> and multiple finger tips (not visible). The CNC machine <NUM> comprises a platform <NUM>, a CNC cabinet <NUM>, a door <NUM>, and a door handle <NUM>. The table <NUM> may be provided with a defined pickup area <NUM>. The model system <NUM> may also comprise tags <NUM> attached to the table <NUM> and the CNC cabinet <NUM> respectively.

Each body of the model system <NUM> may be provided with one or more visual surfaces, which may be presented to a user to visualize, and one or more collision surfaces, which define constraints representing the surface of the body in the simulation. Typically, visual surfaces and collision surfaces of a simulated body are not the same. To form a collision surface, the complex shape of the body is typically broken down into a set of simpler types of shapes, such as boxes, spheres, cylinders, polyhedrons, among other shapes. This allows simulation with collision responses to be performed efficiently and also helps to create bounding surfaces for the purpose of planning and collision avoidance. An example in which a complex shape like a robot may be split into collision surfaces is shown in <FIG>. More specifically, <FIG> shows multiple surface representations for a simulated body of a robot, namely a visual surface representation <NUM> for display purpose, and a collision surface representation <NUM>, to be used in the actual simulation. When running in simulation, the collision shapes act as stand-ins to the complicated 3D shape of the body.

According to the illustrated embodiment, the engineering tool <NUM> includes a simulation engine configured to mimic the physical activities of the modeled bodies of the model system <NUM> based on objects and constraints defined by the user. For solving rigid body dynamics of the model system <NUM>, the simulation engine may include appropriate physics libraries, for example, similar to that used in computer gaming.

<FIG> illustrates a rigid body graph <NUM> depicting simulation entities for the model system <NUM> shown in <FIG>. In particular, the rigid body graph <NUM> depicts an arrangement of connected nodes, wherein the nodes depict the individual bodies (or objects) of the model system <NUM> and connections between the nodes depict joints between the bodies. In <FIG>, bodies <NUM> represent individual rigid bodies that are defined by the user. Connections between the bodies <NUM> may either be defined as a fixed joint <NUM> or as an other joint <NUM>. As used herein, the term "fixed joint" refers to a connection between bodies which constrains any relative motion between the connected bodies. As used herein, the term "other joint" refers to a connection between bodies which allows at least some degree of relative motion between the connected bodies. An example of an "other joint" may include, for example, a hinge joint.

Generally, a user may not be careful to determine which bodies should be considered individual, separate entities and which should be considered a combined single entity. For example, the floor or table of the simulated model system most likely never moves; yet, a user may assign the table a body-like status with mass properties. The table may be attached to the background with a fixed joint to prevent it from moving, rather than not having it be a body in the first place. Likewise, bodies attached to the table, such as the robot base, the CNC cabinet, and other items that could be bolted down may also be modeled as individual bodies. Similarly, such bodies are attached to others with fixed joints so that their movements are constrained.

Existing simulation engines are designed to allow the user to optimize the physics objects and are not configured to modify anything that the user provides. Running the simulation engine with extraneous bodies as shown in <FIG> does not necessarily change the result of the simulation. Bodies fixed to the background will likely not move. However, the engine would be consequently doing more work than is needed to solve for bodies that cannot possibly move. Furthermore, implicit constraints between bodies that are fixed together, such as collision surfaces, will also be active. This causes extra time to search for potential collisions among closely spaced bodies that, in fact, can never touch.

The simulation method as per the present disclosure provides an optimization of a simulation program by automatically removing redundant bodies by the simulation engine, to thereby speed up computation of a physical simulation without changing the desired result.

Referring back to <FIG>, block <NUM> of the method <NUM> involves identifying one or more groups of bodies from the plurality of user defined bodies, such that bodies belonging to a group are constrained in relation to each other by fixed joints. The simulation engine may be configured to perform this step, for example, by scanning the rigid body graph <NUM>, based on a depth-first or breadth-first algorithm, to identify bodies that are connected by fixed joints. <FIG> shows how the rigid bodies in <FIG> may be collected into groups <NUM>, where each group <NUM> comprises bodies <NUM> connected by fixed joints <NUM>. For each set of rigidly connected bodies <NUM>, the group <NUM> is subsequently processed to remove redundant bodies.

The processing of each group <NUM> is carried out based on whether or not the group <NUM> comprises a background object as a constituent body, as represented in the decision block <NUM> in <FIG>. The background is not a real body. In some simulation systems, a rigid body with infinite mass and inertia properties stands in for the background, but this is not always true. The background represents a completely fixed object that cannot possibly move. For example, the floor of a building usually does not move (unless the simulation is specifically about that kind of movement, like an earthquake). At block <NUM> of the method <NUM>, for a group containing the background object, the constituent bodies are removed altogether from solving the simulation. However, the contents of the bodies, such as collision surfaces and visual surfaces are preserved and utilized in the execution of the simulation code (block <NUM>). In the example of <FIG>, the leftmost group contains the background object. In this example, by removing the bodies in this group, seven of the original thirty bodies are eliminated.

At block <NUM> of the method <NUM>, for a group not containing the background object, the group of bodies is modeled as a single merged body or composite body. For the merged body, mass properties, position and orientation are determined based on mass properties and structure of constituent bodies of the group.

<FIG> illustrates the combination of two constituent bodies of a group of rigidly connected bodies into a merged body. The constituent bodies here are respectively a grip finger <NUM> and a finger tip <NUM>. The merged body is designated as <NUM> on the right-hand side of the figure. The left-hand side of the figure shows the constituent bodies <NUM>, <NUM> as being separated, for illustrative purposes only. In reality, the positions of the constituent bodies <NUM> and <NUM> would be the same both before and after processing. The centers of mass of the constituent bodies <NUM>, <NUM> are designated respectively by the points <NUM> and <NUM>. The mass of the merged body <NUM> may be determined as the sum of the masses of the constituent bodies <NUM>, <NUM> of the group. The position of the merged body <NUM> may be defined by the position of its center of mass <NUM>. The center of mass <NUM> of the merged rigid body <NUM> may be determined as the weighted sum of the centers of mass <NUM>, <NUM> of the constituent bodies <NUM>, <NUM> being merged. Furthermore, an inertia tensor of the merged body <NUM> may be determined as a summation of the inertia tensors of the constituent bodies <NUM>, <NUM>, where each is transformed to be placed at the center of mass <NUM> of the merged body <NUM>, and at the same rotation (i.e., angular position).

Still referring to <FIG>, the collision surfaces for the constituent bodies <NUM>, <NUM> are designated by dotted lines <NUM>, <NUM>, while the respective shape of the bodies <NUM>, <NUM> represent their visual surfaces. The collision surfaces and visual surfaces of the constituent bodies <NUM>, <NUM> are constructed in 3D space (local to the bodies) in relation to respective origins, which are the centers of mass <NUM> and <NUM> of the bodies <NUM> and <NUM> respectively. In order to construct the collision surfaces and visual surfaces of the merged body <NUM>, the collection of collision surfaces and the collection of visual surfaces of the constituent bodies <NUM>, <NUM> may be transformed to an origin defined by the center of mass <NUM> of the merged body <NUM>, while keeping their global positions unchanged.

<FIG> shows orthogonal references axes for the constituent bodies <NUM>, <NUM>. The orientation or angular position of the constituent bodies <NUM>, <NUM> may be defined by an angular transformation of their axes in 3D such as with a 3x3 matrix or a quaternion. The orientation of the merged body <NUM> may be determined in several different ways. For example, the orientation of the merged body <NUM> may be defined as an angular position using the transform of the body <NUM>, or the transform of the body <NUM>, or using any other arbitrarily chosen reference frame. Generally, the orientation of the body is not critical to the simulation provided the inertia tensor is correct for that frame.

Referring back to <FIG>, blocks <NUM> through <NUM> of the method <NUM> may be repeated for each of n identified groups to generate a simulation code. Block <NUM> of the method <NUM> involves executing the simulation code solving rigid body dynamics for the model system based the above-described processing of each group of bodies.

<FIG> illustrates a rigid body graph <NUM> as a result of merging of bodies connected by fixed joints. As seen herein, from the original thirty individual rigid bodies from <FIG>, the number of bodies to be simulated is reduced to fifteen rigid bodies, counting each merged body <NUM> as a single rigid body. As a result, the simulation engine can run significantly faster and produce more precise results than it could if all thirty of the original objects were simulated. The state variables of the original rigid bodies and their original connections may be maintained by the system to allow for dynamic modification of the bodies and for interaction with other systems.

Continuing reference to <FIG>, at block <NUM>, during execution of the simulation code, changes in constraints are dynamically detected. For example, if the application removes fixed joints from the simulation dynamically, the method will reconsider the portion of the rigid body graph of which the fixed joint was made part. If the component breaks into multiple bodies, each will be reassigned the collision surfaces and visual surfaces as needed. Also, the mass properties, position, and orientation will be recomputed for the new merged bodies as described above as well as assigning linear and angular velocities to the objects based on the original body's momentum. If the fixed joint splits out a section of rigid bodies from the background component, a new rigid body is produced for the newly moving elements. The remaining elements still fixed to the background are left without a rigid body. The combined momentum of split bodies are the same as the merged body's momentum from which they were split and for a body split from the background, its initial velocity would be zero. Based on the detected change in constraints at block <NUM>, the grouping of bodies in the model system may be dynamically modified (go to block <NUM>). The modified grouping of bodies is then processed, as described above, to dynamically modify the simulation code.

In one embodiment, when a user is querying the state of a constituent body that was merged into a group, the program may be configured to return a motion characteristic of the constituent body (such as linear velocity/momentum, angular velocity/momentum, among others) as though the constituent body was still used in the simulation. The state of the constituent body may be determined by transforming a motion characteristic of the merged body representing the group, using a position offset and a rotation offset between the constituent body and the merged body. The position offset refers to an offset between the center of mass of the constituent body and that of the merged body. The rotational offset refers to an offset in angular positions of the constituent body and the merged body. Forces between elements of a merged body are zero and forces between a merged body and other bodies would compute the same as they would for separate bodies.

<FIG> illustrates an exemplary computing environment <NUM> within which embodiments of the disclosure may be implemented. For example, computing environment <NUM> may be used to implement one or more components of the simulation system <NUM> shown in <FIG>. Computers and computing environments, such as computer system <NUM> and computing environment <NUM>, are known to those of skill in the art and thus are described briefly here.

As shown in <FIG>, the computer system <NUM> may include a communication mechanism such as a system bus <NUM> or other communication mechanism for communicating information within the computer system <NUM>. The computer system <NUM> further includes one or more processors <NUM> coupled with the system bus <NUM> for processing the information.

The processors <NUM> may include one or more central processing units (CPUs), graphical processing units (GPUs), a dedicated physics processing unit (PPU), or any other processor known in the art. More generally, a processor as used herein is a device for executing machine-readable instructions stored on a computer readable medium, for performing tasks and may comprise any one or combination of, hardware and firmware. A processor may also comprise memory storing machine-readable instructions executable for performing tasks. A processor acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information to an output device. A processor may use or comprise the capabilities of a computer, controller or microprocessor, for example, and be conditioned using executable instructions to perform special purpose functions not performed by a general purpose computer. A processor may be coupled (electrically and/or as comprising executable components) with any other processor enabling interaction and/or communication there-between. A user interface processor or generator is a known element comprising electronic circuitry or software or a combination of both for generating display images or portions thereof. A user interface comprises one or more display images enabling user interaction with a processor or other device.

Continuing with reference to <FIG>, the computer system <NUM> also includes a system memory <NUM> coupled to the system bus <NUM> for storing information and instructions to be executed by processors <NUM>. The system memory <NUM> may include computer readable storage media in the form of volatile and/or nonvolatile memory, such as read only memory (ROM) <NUM> and/or random access memory (RAM) <NUM>. The system memory RAM <NUM> may include other dynamic storage device(s) (e.g., dynamic RAM, static RAM, and synchronous DRAM). The system memory ROM <NUM> may include other static storage device(s) (e.g., programmable ROM, erasable PROM, and electrically erasable PROM). In addition, the system memory <NUM> may be used for storing temporary variables or other intermediate information during the execution of instructions by the processors <NUM>. A basic input/output system <NUM> (BIOS) containing the basic routines that help to transfer information between elements within computer system <NUM>, such as during start-up, may be stored in system memory ROM <NUM>. System memory RAM <NUM> may contain data and/or program modules that are immediately accessible to and/or presently being operated on by the processors <NUM>. System memory <NUM> may additionally include, for example, operating system <NUM>, application programs <NUM>, other program modules <NUM> and program data <NUM>.

The computer system <NUM> also includes a disk controller <NUM> coupled to the system bus <NUM> to control one or more storage devices for storing information and instructions, such as a magnetic hard disk <NUM> and a removable media drive <NUM> (e.g., floppy disk drive, compact disc drive, tape drive, and/or solid state drive). The storage devices may be added to the computer system <NUM> using an appropriate device interface (e.g., a small computer system interface (SCSI), integrated device electronics (IDE), Universal Serial Bus (USB), or FireWire).

The computer system <NUM> may also include a display controller <NUM> coupled to the system bus <NUM> to control a display <NUM>, such as a cathode ray tube (CRT) or liquid crystal display (LCD), among other, for displaying information to a computer user. The computer system <NUM> includes a user input interface <NUM> and one or more input devices, such as a keyboard <NUM> and a pointing device <NUM>, for interacting with a computer user and providing information to the one or more processors <NUM>. The pointing device <NUM>, for example, may be a mouse, a light pen, a trackball, or a pointing stick for communicating direction information and command selections to the one or more processors <NUM> and for controlling cursor movement on the display <NUM>. The display <NUM> may provide a touch screen interface which allows input to supplement or replace the communication of direction information and command selections by the pointing device <NUM>.

The computer system <NUM> may perform a portion or all of the processing steps of embodiments of the disclosure in response to the one or more processors <NUM> executing one or more sequences of one or more instructions contained in a memory, such as the system memory <NUM>. Such instructions may be read into the system memory <NUM> from another computer readable medium, such as a magnetic hard disk <NUM> or a removable media drive <NUM>. The magnetic hard disk <NUM> may contain one or more datastores and data files used by embodiments of the present disclosure. Datastore contents and data files may be encrypted to improve security. The processors <NUM> may also be employed in a multi-processing arrangement to execute the one or more sequences of instructions contained in system memory <NUM>. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.

As stated above, the computer system <NUM> may include at least one computer readable medium or memory for holding instructions programmed according to embodiments of the disclosure and for containing data structures, tables, records, or other data described herein. The term "computer readable medium" as used herein refers to any medium that participates in providing instructions to the one or more processors <NUM> for execution. A computer readable medium may take many forms including, but not limited to, non-transitory, non-volatile media, volatile media, and transmission media. Non-limiting examples of non-volatile media include optical disks, solid state drives, magnetic disks, and magneto-optical disks, such as magnetic hard disk <NUM> or removable media drive <NUM>. Non-limiting examples of volatile media include dynamic memory, such as system memory <NUM>. Non-limiting examples of transmission media include coaxial cables, copper wire, and fiber optics, including the wires that make up the system bus <NUM>. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

The computing environment <NUM> may further include the computer system <NUM> operating in a networked environment using logical connections to one or more remote computers, such as remote computing device <NUM>. Remote computing device <NUM> may be a personal computer (laptop or desktop), a mobile device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer system <NUM>. When used in a networking environment, computer system <NUM> may include modem <NUM> for establishing communications over a network <NUM>, such as the Internet. Modem <NUM> may be connected to system bus <NUM> via user network user input interface <NUM>, or via another appropriate mechanism.

Network <NUM> may be any network or system generally known in the art, including the Internet, an intranet, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a direct connection or series of connections, a cellular telephone network, or any other network or medium capable of facilitating communication between computer system <NUM> and other computers (e.g., remote computing device <NUM>). The network <NUM> may be wired, wireless or a combination thereof. Wired connections may be implemented using Ethernet, Universal Serial Bus (USB), RJ-<NUM>, or any other wired connection generally known in the art. Wireless connections may be implemented using Wi-Fi, WiMAX, and Bluetooth, infrared, cellular networks, satellite or any other wireless connection methodology generally known in the art. Additionally, several networks may work alone or in communication with each other to facilitate communication in the network <NUM>.

An executable application, as used herein, comprises code or machine readable instructions for conditioning the processor to implement predetermined functions, such as those of an operating system, a context data acquisition system or other information processing system, for example, in response to user command or input. An executable procedure is a segment of code or machine readable instruction, sub-routine, or other distinct section of code or portion of an executable application for performing one or more particular processes. These processes may include receiving input data and/or parameters, performing operations on received input data and/or performing functions in response to received input parameters, and providing resulting output data and/or parameters.

A graphical user interface (GUI), as used herein, comprises one or more display images, generated by a display processor and enabling user interaction with a processor or other device and associated data acquisition and processing functions. The GUI also includes an executable procedure or executable application. The executable procedure or executable application conditions the display processor to generate signals representing the GUI display images. These signals are supplied to a display device which displays the image for viewing by the user. The processor, under control of an executable procedure or executable application, manipulates the GUI display images in response to signals received from the input devices. In this way, the user may interact with the display image using the input devices, enabling user interaction with the processor or other device.

The functions and process steps herein may be performed automatically, wholly or partially in response to user command. An activity (including a step) performed automatically is performed in response to one or more executable instructions or device operation without user direct initiation of the activity.

Claim 1:
A computer-implemented method for simulating an industrial environment of a production site to simulate motion of objects in the industrial environment of the production site with collision responses, the method comprising:
- creating (<NUM>), by a computer (<NUM>; <NUM>), a three-dimensional model system representing the industrial environment of the production site, the model system comprising a plurality of bodies representing physical components of the industrial environment of the production site, wherein each body comprises one or more collision surfaces to define constraints representing the surface of the respective body and one or more visual surfaces to be presented to a user to visualize the respective body,
- identifying (<NUM>), by the computer, one or more groups of bodies from the plurality of bodies, such that bodies belonging to a group are constrained in relation to each other by fixed joints,
- processing, by the computer, each group of bodies, the processing comprising:
if a group of bodies comprises a background object as a constituent body, then removing (<NUM>) all constituent bodies of the group while preserving the respective collision surfaces and visual surfaces, and
if a group of bodies does not comprise the background object as a constituent body, then modelling (<NUM>) the group of bodies as a single merged body, the merged body having defined mass properties, position and orientation determined based on mass properties and structure of constituent bodies of the group, and
- executing (<NUM>), by the computer, a simulation code solving rigid body dynamics for the model system based on said processing of each group of bodies.