US20110054873A1

US20110054873A1 - System and method for creation of function-based mechatronic objects

Info

Publication number: US20110054873A1
Application number: US12/760,281
Authority: US
Inventors: Matthias Lenord; Raymond Kok; Peter Hutchison
Original assignee: Siemens Product Lifecycle Management Software Inc
Current assignee: Siemens Industry Software Inc
Priority date: 2009-08-31
Filing date: 2010-04-14
Publication date: 2011-03-03
Also published as: US20110055088A1; WO2011026021A3; EP2473938A2; EP2473946A2; WO2011026007A2; WO2011026021A2; US9721042B2; WO2011026007A3

Abstract

A system, method, and computer readable medium. A method includes receiving requirements for a mechatronics object and receiving functions for the mechatronics object. The method includes assigning the functions to respective ones of components and operations and linking the requirements to respective ones of the functions. The method includes storing the mechatronics object, including the linked requirements and functions.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of the filing date of U.S. Provisional Patent Application 61/238,414, filed Aug. 31, 2009, for “System, Method, and Computer Program Product for Functional Mechatronic Objects”, which is hereby incorporated by reference.
This application includes some subject matter in common with commonly-assigned, concurrently-filed U.S. patent application Ser. No. ______ for “System and Method for Use of Function-Based Mechatronic Objects”, which is hereby incorporated by reference.

TECHNICAL FIELD

The present disclosure is directed, in general, to systems and methods for use in computer-aided design, manufacturing, engineering, prototype/test, maintenance, modeling, and visualization (individually and collectively, “CAD” and “CAD systems”) and in product lifecycle management (“PLM”) and other systems.

BACKGROUND OF THE DISCLOSURE

Many manufactured products are first designed and modeled in CAD systems, and PLM systems are used by manufacturers, retailers, customers, and other users to manage the design, use, maintenance, and disposal of various products. Improved systems are desirable.

SUMMARY OF THE DISCLOSURE

Various embodiments include a system, method, and computer readable medium. A method includes receiving requirements for a mechatronics object and receiving functions for the mechatronics object. The method includes assigning the functions to respective ones of components and operations and linking the requirements to respective ones of the functions. The method includes storing the mechatronics object, including the linked requirements and functions.
The foregoing has outlined rather broadly the features and technical advantages of the present disclosure so that those skilled in the art may better understand the detailed description that follows. Additional features and advantages of the disclosure will be described hereinafter that form the subject of the claims. Those skilled in the art will appreciate that they may readily use the conception and the specific embodiment disclosed as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. Those skilled in the art will also realize that such equivalent constructions do not depart from the spirit and scope of the disclosure in its broadest form.
Before undertaking the DETAILED DESCRIPTION below, it may be advantageous to set forth definitions of certain words or phrases used throughout this patent document: the terms “include” and “comprise,” as well as derivatives thereof, mean inclusion without limitation; the term “or” is inclusive, meaning and/or; the phrases “associated with” and “associated therewith,” as well as derivatives thereof, may mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, or the like; and the term “controller” means any device, system or part thereof that controls at least one operation, whether such a device is implemented in hardware, firmware, software or some combination of at least two of the same. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. Definitions for certain words and phrases are provided throughout this patent document, and those of ordinary skill in the art will understand that such definitions apply in many, if not most, instances to prior as well as future uses of such defined words and phrases. While some terms may include a wide variety of embodiments, the appended claims may expressly limit these terms to specific embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, wherein like numbers designate like objects, and in which:

FIG. 1 depicts a block diagram of a data processing system in which an embodiment can be implemented in accordance with disclosed embodiments;

FIG. 2 depicts an exemplary user interface of a function navigator that may be implemented using a data processing system in support of the processes in accordance with disclosed embodiments;

FIG. 3 depicts a block diagram of the different types of data that can be combined in a functional component of a mechatronics object in accordance with disclosed embodiments; and

FIG. 4 depicts a flowchart of a process in accordance with disclosed embodiments.

DETAILED DESCRIPTION

FIGS. 1 through 4, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged device. The numerous innovative teachings of the present application will be described with reference to exemplary non-limiting embodiments.
In general, mechatronics refers the synergistic combination of mechanical engineering, electrical/electronic engineering, computer engineering, control engineering, systems design engineering, and other technical disciplines to create, design and manufacture useful products. The concept phase in the overall design process of a mechatronics system is the first time where the architect thinks about the physical implementation. The architect must ensure that the implementation is conformant with the requirements and has a basic design structure that enables an efficient detailed design and production.
Today there is no integrated mechanism in place to seamlessly trace requirements down to the multi-disciplinary design and implementation of a given product and/or system. The collaboration of multi disciplines is difficult because there is no joint data structure in place that is a kind of interlink between the disciplinary data structures.
Some systems are capable of maintaining requirements, functions and disciplinary data in a data base. One can match the various data structures by creating link between items in the data base from a pure data point of view. There is no specific design context for interdisciplinary concept design in conventional systems.
In conventional systems each item has a specific design context which makes the design of multi-disciplinary product designs hard to grasp for designers/engineers. Prior systems just look at items as data objects that can be managed in a data base. This makes it impossible to support a creative design process required to produce a mechatronics concept design.
Disclosed embodiments include systems and methods to facilitate the physical concept design of a product based on a functional design approach, include a common “linking” structure. A functional model and related mechanisms are used to link this model to requirements and enrich this model with interdisciplinary implementation data.
FIG. 1 depicts a block diagram of a data processing system in which an embodiment can be implemented, for example as a CAD or PLM system configured to perform processes as described herein. The data processing system depicted includes a processor 102 connected to a level two cache/bridge 104, which is connected in turn to a local system bus 106. Local system bus 106 may be, for example, a peripheral component interconnect (PCI) architecture bus. Also connected to local system bus in the depicted example are a main memory 108 and a graphics adapter 110. The graphics adapter 110 may be connected to display 111.
Other peripherals, such as local area network (LAN)/Wide Area Network/Wireless (e.g. WiFi) adapter 112, may also be connected to local system bus 106. Expansion bus interface 114 connects local system bus 106 to input/output (110) bus 116. I/O bus 116 is connected to keyboard/mouse adapter 118, disk controller 120, and 110 adapter 122. Disk controller 120 can be connected to a storage 126, which can be any suitable machine usable or machine readable storage medium, including but not limited to nonvolatile, hard-coded type mediums such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), magnetic tape storage, and user-recordable type mediums such as floppy disks, hard disk drives and compact disk read only memories (CD-ROMs) or digital versatile disks (DVDs), and other known optical, electrical, or magnetic storage devices.
Also connected to I/O bus 116 in the example shown is audio adapter 124, to which speakers (not shown) may be connected for playing sounds. Keyboard/mouse adapter 118 provides a connection for a pointing device (not shown), such as a mouse, trackball, trackpointer, etc.
Those of ordinary skill in the art will appreciate that the hardware depicted in FIG. 1 may vary for particular implementations. For example, other peripheral devices, such as an optical disk drive and the like, also may be used in addition or in place of the hardware depicted. The depicted example is provided for the purpose of explanation only and is not meant to imply architectural limitations with respect to the present disclosure.
A data processing system in accordance with an embodiment of the present disclosure includes an operating system employing a graphical user interface. The operating system permits multiple display windows to be presented in the graphical user interface simultaneously, with each display window providing an interface to a different application or to a different instance of the same application. A cursor in the graphical user interface may be manipulated by a user through the pointing device. The position of the cursor may be changed and/or an event, such as clicking a mouse button, generated to actuate a desired response.
One of various commercial operating systems, such as a version of Microsoft Windows™, a product of Microsoft Corporation located in Redmond, Wash. may be employed if suitably modified. The operating system is modified or created in accordance with the present disclosure as described.
LAN/WAN/Wireless adapter 112 can be connected to a network 130 (not a part of data processing system 100), which can be any public or private data processing system network or combination of networks, as known to those of skill in the art, including the Internet. Data processing system 100 can communicate over network 130 with server system 140, which is also not part of data processing system 100, but can be implemented, for example, as a separate data processing system 100.
Disclosed embodiments include new systems engineering processes that close the gap between requirements engineering and discipline specific implementation through the ability to store the functional model which provides a discipline-independent definition of a system's functions which can be mapped to multiple disciplines for implementation. These include processes to get to a mechatronics concept design by using a system such as data processing system 100 for defining and managing requirements; functional decomposition of the mechatronics system into a hierarchical representation based on function groups, function subgroups and functional units; linking of requirements and functions; defining the mechatronics concept of the mechatronics systems containing mechanical design (shape, kinematics and dynamics), electrical design (sensors and actuators), and automation software design (cams, logic behavior, sequence of operation); and mapping the disciplinary concept data to the functional model in one integrated design context.
Various embodiments include user interactions to provide a reusable mechatronics component that can include geometries, kinematics and dynamics for a detailed 3D-design, a sensor-actuator list for an electrical layout, a behavior description of the machine for the automation engineering, and simple simulation models for design verification, among other data.
Various embodiments include a design and engineering environment for concept mechanical, electrical and automation design. Various embodiments include deliver quick and easy ways to simulate behavior of machine and corresponding controllers (PLC or motion).
Various embodiments include gaming-quality physics as an integral part of the design experience. Users will be able to “turn on” their designs and visualize all aspects of physical behavior.
Various embodiments include physics and human behavior into the design process to increase behavioral design testing, causing potential design problems to be found sooner and increasing product quality, and to make 3D design engaging and dynamic. Using embodiments disclosed herein, a user has no need to wait until virtual commissioning in order to visualize the behavior of the mechatronics system.
FIG. 2 depicts an exemplary user interface of a function navigator 200 that may be implemented using a data processing system 100 in support of the processes described herein. In this figure, the function navigator 200 shows a primary function 202 of a mechatronics component, which is further divided into main functions 204 and auxiliary functions 206.
Each function node can include a component container 208 and an operations container 210, and sub-functions 212. Each function can be linked to one or more requirements 214.
Every function node can contain a component container and operation container. The component container is to represent the components which are used to realize this function. The operation container is to represent the operations which belong to this function. According to various embodiments, all components can be added into components container node, and one function may have multiple components.
In some embodiments, all the functions with the same type in the same level (functions have the same direct parent node) are numbered and have one number index respectively. According to the creation time order, they are numbered from 1 to N. For example, if one function node C1 has 3 children, two A and one B, then the two A will be numbered to A1 and A2 respectively and B will be numbered to B1. If another B is added, then this new comer will be numbered as B2.
The name of function node can be generated by “Function Letter code”+index+“−”+Name. For instance, if there is one function, and its type is A, its type index is 2, its name is “motor”, then the function tree node name will be <A2−“motor”>.
The functional root node can be created and displayed in Function Navigator while user creates a new part. The system interacts with the user to create a Function Node through, for example, a popup menu of Function Navigator. A Function Node can represent Function object in the Function Navigator.
According to disclosed embodiments, a Function object has below attributes and properties:

- 1. Function Type. The type definition complies with IEC IEC61346-2-2000 standard, known to those of skill in the art.
- 2. Parameter: Defines the parameter name (string) and its value (string) for the function.
- 3. Requirements: Defines the requirement names (string) and values (string) associated with function. Note that in a typical implementation, the requirements are part of their structure and linked to functions, and the function tree includes a representation of the actual requirements from the requirements structure linked to a specific function, and not a property of the function objects themselves.
- 4. Name (string)

FIG. 3 depicts a block diagram 300 of the different types of data that can be combined in a functional component of a mechatronics object as described herein. The functional component 302 can be used to store the discipline-independent aspects of the system defining what functions must be implemented by the different discipline specific models, and does not necessarily carry the details of a single specific implementation of each function.
Functional component 302, shown as part of systems engineering and requirements engineering (SE & RE) block 304, is linked to requirements 306 as described above. Functional component 302 can include Mechanical Engineering assembly data 308, which itself can include CAD data 310 and physics data 311.
Functional component 302 can also include software programming elements such as sequence of operations 312 and CAM data 314, which can be created using and linked to engineering tools 316. As described above, these elements typically describe or define the functional requirements for the element, not a specific implementation. For example, the component can include a specification which defines the sequence of operations 312, but may not include the specific sequence of operations or coding for any specific implementation.
Functional component 302 can also include ECAD and hydraulics information such as sensor/actuator data 318, which can be linked to ECAD/Hydraulics data 320. As another example of how the functional component 302 will typically include specification and definitional data as opposed to implementation-specific data, for sensors and actuators, the functional component 302 defines what sensing and actuation functions are needed, but need not define in detail the sensors and actuators.
Functional component 302 can be stored and used for a detailed simulation and for virtual commissioning, in one or more specific simulations 322.
As described above, according to various embodiments, the functional component 302 is a definition of what the system or product must do in enough detail to allow the different disciplines to work in parallel on detailed design but without discipline specific design information.
According to various embodiments, the system can store the assignment of requirements to functions and from functions to modules and components. The system can store a set of operations defining the functions and can simulate them to verify their correctness. Various operations are linked to the functions. The system can therefore generate and store a set of specifications for the mechanical/electrical/automation engineers in the form of required movements (including speeds, accelerations, vectors, timing, 3D clearances), any of which can be executed in a simulation. This shortens the product development lifecycle by allowing more parallel development.
FIG. 4 depicts a flowchart of a process in accordance with disclosed embodiments. Various steps in the process may be performed repeatedly, concurrently, or in a different order.
The system receives requirements for a mechatronic object (step 405). In some cases, the mechatronic object will correspond to a product. A “product” can be a complete physical product or any other physical assembly or subassembly unless otherwise indicated. Receiving, as used herein, can include receiving via an interaction with a user, loading from a storage, receiving from another device or system, for example over a network, or otherwise.
The system receives functions (or functional components) for the mechatronic object (step 410). Each of the functions of the mechatronic object can include such functional information as physics definitions, sensor and actuator definitions, function and logic definitions, and other such mechanical, electrical, automation, or other definitions and data as described herein.
The system assigns the functions of the mechatronic object to respective ones of components and operations (Step 415). The components and operations are assigned according to which module or component fulfills the various required functions.
The system links each of the requirements to respective ones of the functions (step 420). This step can include an interaction with a user, and assures that each requirement is fulfilled by one or more of the defined functions.
The system stores the mechatronic object, including the linked requirements and functions with mechanical/electrical/automation definitions (step 425).
The system can simulate the structure and operation of the mechatronic object (step 430).
The stored mechatronic object can then be used, for example, as a reusable product definition in a product lifecycle management or other system (step 435).
Those skilled in the art will recognize that, for simplicity and clarity, the full structure and operation of all data processing systems suitable for use with the present disclosure is not being depicted or described herein. Instead, only so much of a data processing system as is unique to the present disclosure or necessary for an understanding of the present disclosure is depicted and described. The remainder of the construction and operation of data processing system 100 may conform to any of the various current implementations and practices known in the art.
It is important to note that while the disclosure includes a description in the context of a fully-functional system, those skilled in the art will appreciate that at least portions of the mechanism of the present disclosure are capable of being distributed in the form of a instructions contained within a machine-usable, computer-usable, or computer-readable medium in any of a variety of forms, and that the present disclosure applies equally regardless of the particular type of instruction or signal bearing medium or storage medium utilized to actually carry out the distribution. Examples of machine usable/readable or computer usable/readable mediums include: nonvolatile, hard-coded type mediums such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), and user-recordable type mediums such as floppy disks, hard disk drives and compact disk read only memories (CD-ROMs) or digital versatile disks (DVDs).
Although an exemplary embodiment of the present disclosure has been described in detail, those skilled in the art will understand that various changes, substitutions, variations, and improvements disclosed herein may be made without departing from the spirit and scope of the disclosure in its broadest form.
None of the description in the present application should be read as implying that any particular element, step, or function is an essential element which must be included in the claim scope: the scope of patented subject matter is defined only by the allowed claims. Moreover, none of these claims are intended to invoke paragraph six of 35 USC §112 unless the exact words “means for” are followed by a participle.

Claims

1. A method for creation of a mechatronics object, comprising:

receiving requirements for a mechatronics object in a data processing system;

receiving functions for the mechatronics object in the data processing system;

assigning the functions to respective ones of components and operations by the data processing system;

linking the requirements to respective ones of the functions by the data processing system; and

storing the mechatronics object, including the linked requirements and functions, in the data processing system.

2. The method of claim 1, wherein the functions include physics definitions.

3. The method of claim 1, wherein the functions include electrical definitions.

4. The method of claim 1, wherein the functions include automation definitions.

5. The method of claim 1, further comprising simulating the structure and operation of the mechatronics object.

6. The method of claim 1, wherein at least one of receiving requirements and receiving functions is performed via an interaction with a user.

7. The method of claim 1, further comprising using the mechatronic object as a reusable product definition in a product lifecycle management system.

8. The method of claim 1, further comprising performing a functional decomposition of the mechatronics object into a hierarchical representation based on function groups, function subgroups and functional units.

9. A data processing system comprising a processor and accessible memory, the data processing system particularly configured to perform the steps of:

receiving requirements for a mechatronics object;

receiving functions for the mechatronics object;

assigning the functions to respective ones of components and operations;

linking the requirements to respective ones of the functions; and

storing the mechatronics object, including the linked requirements and functions.

10. The data processing system of claim 9, wherein the functions include physics definitions.

11. The data processing system of claim 9, wherein the functions include electrical definitions.

12. The data processing system of claim 9, wherein the functions include automation definitions.

13. The data processing system of claim 9, wherein the data processing system is also configured to perform the step of simulating the structure and operation of the mechatronics object.

14. The data processing system of claim 9, wherein at least one of receiving requirements and receiving functions is performed via an interaction with a user.

15. The data processing system of claim 9, wherein the data processing system is also configured to perform the step of using the mechatronic object as a reusable product definition in a product lifecycle management system.

16. The data processing system of claim 9, wherein the data processing system is also configured to perform the step of performing a functional decomposition of the mechatronics object into a hierarchical representation based on function groups, function subgroups and functional units.

17. A tangible computer-readable medium encoded with computer-executable instructions that, when executed, cause a data processing system to perform the steps of:

receiving requirements for a mechatronics object;

receiving functions for the mechatronics object;

assigning the functions to respective ones of components and operations;

linking the requirements to respective ones of the functions; and

18. The computer-readable medium of claim 17, wherein the functions include physics definitions.

19. The computer-readable medium of claim 17, wherein the functions include electrical definitions.

20. The computer-readable medium of claim 17, wherein the functions include automation definitions.

21. The computer-readable medium of claim 17, further encoded with instructions that, when executed, cause the data processing system to perform the step of simulating the structure and operation of the mechatronics object.

22. The computer-readable medium of claim 17, wherein at least one of receiving requirements and receiving functions is performed via an interaction with a user.

23. The computer-readable medium of claim 17, further encoded with instructions that, when executed, cause the data processing system to perform the step of using the mechatronic object as a reusable product definition in a product lifecycle management system.

24. The computer-readable medium of claim 17, further encoded with instructions that, when executed, cause the data processing system to perform the step of performing a functional decomposition of the mechatronics object into a hierarchical representation based on function groups, function subgroups and functional units.