WO2008118357A1 - System and method for validating design requirements - Google Patents

System and method for validating design requirements Download PDF

Info

Publication number
WO2008118357A1
WO2008118357A1 PCT/US2008/003736 US2008003736W WO2008118357A1 WO 2008118357 A1 WO2008118357 A1 WO 2008118357A1 US 2008003736 W US2008003736 W US 2008003736W WO 2008118357 A1 WO2008118357 A1 WO 2008118357A1
Authority
WO
WIPO (PCT)
Prior art keywords
design
requirements
product
computer
presently preferred
Prior art date
Application number
PCT/US2008/003736
Other languages
French (fr)
Inventor
Shingchi Hsu
Original Assignee
Siemens Product Lifecycle Management Software Inc.
Peng, Kun
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Product Lifecycle Management Software Inc., Peng, Kun filed Critical Siemens Product Lifecycle Management Software Inc.
Priority to EP08742183A priority Critical patent/EP2130151A1/en
Publication of WO2008118357A1 publication Critical patent/WO2008118357A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]

Definitions

  • the CAD application may have the ability to import the requirement, as Word or Excel or other data, to provide the capability for a design check against the necessary requirements. Problems may arisein the event that requirements change, which have an impact on the product design or when product design constraints necessitate a requirement change in order to comport the realities of the product design with the requirements. In some cases, the issue with requirements themselves may not be readily available, such as being isolated on individual computers with limited access, stored in databases with little resemblance to the product structure, or maintained through complicated user interfaces with significant learning curves.
  • the present application provides a method for design validation, comprising defining a plurality of requirements; extracting said plurality of requirements; comparing a design against said plurality of requirements; and reporting a result of said comparison.
  • the method wherein said defining step is performed in a product data managed environment.
  • the method wherein said design is a virtual design.
  • the method further comprising modifying said plurality of requirements from said design.
  • the method wherein said plurality of requirements is obtained from an external document.
  • the method, wherein said plurality of requirements is obtained from a design application.
  • the method, wherein said reporting step provides a feedback.
  • the method further comprising modifying said design based on said result step.
  • An advantage of the presently preferred embodiment is to provide a computer-program product tangibly embodied in a machine readable medium to perform a method for design validation, comprising instructions operable to cause a computer to define a plurality of requirements; extract said plurality of requirements; compare a design against said plurality of requirements; and report a result of said comparison.
  • the product, wherein said defining step is performed in a product data managed environment.
  • the product, wherein said design is a virtual design.
  • the product further comprising instructions to modify said plurality of requirements from said design.
  • the product, wherein said plurality of requirements is obtained from an external document.
  • the product, wherein said plurality of requirements is obtained from a design application.
  • said reporting step provides a feedback.
  • Another advantage of the presently preferred embodiment is to provide a data processing system having at least a processor and accessible memory to implement a method for design validation, comprising means for defining a plurality of requirements; means for extracting said plurality of requirements; means for comparing a design against said plurality of requirements; and means for reporting a result of said comparison.
  • a method for design validation comprising means for defining a plurality of requirements; means for extracting said plurality of requirements; means for comparing a design against said plurality of requirements; and means for reporting a result of said comparison.
  • Figure 1 is a logic flow diagram of the method employed by the presently preferred embodiment
  • Figure 2 illustrates a flow chart of the presently preferred embodiment
  • FIG. 3 is a block diagram of a computer environment in which the presently preferred embodiment may be practiced.
  • an exemplary system for implementing the presently preferred embodiment includes a general-purpose computing device in the form of a computer 300, such as a desktop or laptop computer, including a plurality of related peripheral devices (not depicted).
  • the computer 300 includes a microprocessor 305 and a bus 310 employed to connect and enable communication between the microprocessor 305 and a plurality of components of the computer 300 in accordance with known techniques.
  • the bus 310 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
  • the computer 300 typically includes a user interface adapter 315, which connects the microprocessor 305 via the bus 310 to one or more interface devices, such as a keyboard 320, mouse 325, and/or other interface devices 330, which can be any user interface device, such as a touch sensitive screen, digitized pen entry pad, etc.
  • the bus 310 also connects a display device 335, such as an LCD screen or monitor, to the microprocessor 305 via a display adapter 340.
  • the bus 310 also connects the microprocessor 305 to a memory 345, which can include ROM, RAM, etc.
  • the computer 300 further includes a drive interface 350 that couples at least one storage device 355 and/or at least one optical drive 360 to the bus.
  • the storage device 355 can include a hard disk drive, not shown, for reading and writing to a disk, a magnetic disk drive, not shown, for reading from or writing to a removable magnetic disk drive.
  • the optical drive 360 can include an optical disk drive, not shown, for reading from or writing to a removable optical disk such as a CD ROM or other optical media.
  • the aforementioned drives and associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules, and other data for the computer 300.
  • the computer 300 can communicate via a communications channel 365 with other computers or networks of computers.
  • the computer 300 may be associated with such other computers in a local area network (LAN) or a wide area network (WAN), or it can be a client in a client/server arrangement with another computer, etc.
  • LAN local area network
  • WAN wide area network
  • the presently preferred embodiment may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote memory storage devices. All of these configurations, as well as the appropriate communications hardware and software, are known in the art.
  • Software programming code that embodies the presently preferred embodiment is typically stored in the memory 345 of the computer 300.
  • such software programming code may be stored with memory associated with a server.
  • the software programming code may also be embodied on any of a variety of non-volatile data storage device, such as a hard- drive, a diskette or a CD-ROM.
  • the code may be distributed on such media, or may be distributed to users from the memory of one computer system over a network of some type to other computer systems for use by users of such other systems.
  • the techniques and methods for embodying software program code on physical media and/or distributing software code via networks are well known and will not be further discussed herein. Design Validation
  • FIG. 1 is a logic flow diagram of the method employed by the presently preferred embodiment.
  • the presently preferred embodiment provides a method for product design validation 100 that begins with defining requirements in a product data managed (PDM) environment (Step 105). The next step involves extracting the requirements from the PDM environment (Step 110). Then, validating the extracted requirements against a product design (Step 115), so that the presently preferred embodiment aligns the extracted requirements to the product design.
  • PDM product data managed
  • Step 115 validating the extracted requirements against a product design
  • the methods of product design validation in accordance with the presently preferred embodiment are set forth in more detail below. Step l
  • FIG. 2 illustrates a flow chart of the presently preferred embodiment.
  • a set of requirement data 200 is entered into a PDM environment like Teamcenter® sold by Siemens Product Lifecycle Management Software, Inc. by any method known to enter data, e.g., by extracting information from an external requirements document 205 created by Word or E ⁇ xcel.
  • the set of requirement data 200 can be directly entered in the PDM environment using provided tools by a design application.
  • the requirements necessary for product development are now defined in the PDM environment (Step 105) in a PDM storage location 210, for use by a downstream process. Step 2
  • the down-stream process may include creation of product components by a design application that is preferably a CAD application 215 like NX® sold commercially by Siemens Product Lifecycle Management Software, Inc.
  • a designer initiates the CAD application 215 and associates a product design 220 with the set of requirement data 200 stored in the PDM storage location 210.
  • the association of the product design 220 to the set of requirement data 200 occurs by methods known in the art, for example, selecting a file or data location from a drop-down selection or entering the location in a text box.
  • the designer initiates a validate command 230 in the CAD application 215 using commonly known techniques.
  • the CAD application 215 preferably extracts, at 225, the set of requirement data 200 from the PDM storage location 210 (Step 110).
  • the extraction step can occur any number of ways, but will preferably utilize Service-Oriented Architecture (SOA) functions that return data in PLMXML format for Teamcenter objects, where PLMXML is a known and well document standard such that further discussion is not required.
  • SOA Service-Oriented Architecture
  • a number of values in the product design 220 are compared with the set of requirement data 200 to satisfy compliance with an overall design intent as defined by the set of requirement data 200 (Step 115).
  • requirement data can come from a variety of sources, and may preferably consist of industry or other standards, e.g., ergonomic criteria.
  • the product design 220 will either pass or fail the test of whether the product design 200 satisfies the set of requirement data 200. At that time, error clues will alert the designer to a failed component or a passed component as defined by the set of requirement data 200.
  • the designer may alter the set of requirement data 200 to comport with actual design condition, for example, a component is too large for a particular vessel and will therefore not perform as defined in the set of requirement data 200.
  • the designer could initiate an alternate for the product design 220 that would be propagated to the set of requirement data 200 or the external requirement document 205, or alternatively kept in the PDM storage location 210. The designer initiated change would then follow standard approval processes, for example.
  • Step 1 through Step 3 the presently preferred embodiment has disclosed a complete solution for validating design requirements.
  • the presently preferred embodiment may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof.
  • An apparatus of the presently preferred embodiment may be implemented in a computer program product tangibly embodied in a machine- readable storage device for execution by a programmable processor; and method steps of the presently preferred embodiment may be performed by a programmable processor executing a program of instructions to perform functions of the presently preferred embodiment by operating on input data and generating output.
  • the presently preferred embodiment may advantageously be implemented in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device.
  • the application program may be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language if desired; and in any case, the language may be an assembled, compiled or interpreted language.
  • a processor will receive instructions and data from a read-only memory and/or a random access memory.
  • Storage devices suitable for tangibly embodying computer program instructions and data include all forms of nonvolatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD- ROM disks. Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application2-specific integrated circuits).
  • a number of embodiments have been described. It will be understood that various modifications may be made without departing from the spirit and scope of the presently preferred embodiment. Therefore, other implementations are within the scope of the following claims.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

A system, method, and computer program for design validation, comprising defining a plurality of requirements; extracting said plurality of requirements; comparing a design against said plurality of requirements; and reporting a result of said comparison, and appropriate means and computer-readable instructions.

Description

SYSTEM AND METHOD FOR VALIDATING DESIGN REQUIREMENTS
Cross-Reference to Related Applications
[Para 1 ] This Application claims priority to pending Provisional U.S. Application Ser. No. 60/896,709, filed on March 23, 2007, which application is incorporated herein by reference in its entirety.
Technical Field
[Para 2] The presently preferred embodiment of the innovations described herein relates generally to design requirements. More specifically, the presently preferred embodiment relates to validating design requirements in a design model.
Background
[Para 3] Requirements are commonly used as inputs in the design stage of product development, for example in a FURPS model. Those inputs typically define what is needed in a particular product or service output. Put another way, the requirement describes what a system or product does once developed. A functional specification is the result of describing how the system or product does what it does, once developed. Requirements can be kept in a document format, e.g., Microsoft Word or Excel, or in a database format, e.g., SQL. Next, a design specification is formulated to provide the how-details specific to a particular platform or architecture. While creating the design, for example, a product design using a CAD application like NX® by Siemens Product Lifecycle Management Software Inc., it is important to maintain design characteristics that are within the original requirement specifications. To accomplish this task, the CAD application may have the ability to import the requirement, as Word or Excel or other data, to provide the capability for a design check against the necessary requirements. Problems may arisein the event that requirements change, which have an impact on the product design or when product design constraints necessitate a requirement change in order to comport the realities of the product design with the requirements. In some cases, the issue with requirements themselves may not be readily available, such as being isolated on individual computers with limited access, stored in databases with little resemblance to the product structure, or maintained through complicated user interfaces with significant learning curves.
[Para 4] What is needed is a system and method for product design validation that comports with product structure.
Summary
[Para 5] To achieve the foregoing, and in accordance with the purpose of the presently preferred embodiment as described herein, the present application provides a method for design validation, comprising defining a plurality of requirements; extracting said plurality of requirements; comparing a design against said plurality of requirements; and reporting a result of said comparison. The method, wherein said defining step is performed in a product data managed environment. The method, wherein said design is a virtual design. The method, further comprising modifying said plurality of requirements from said design. The method, wherein said plurality of requirements is obtained from an external document. The method, wherein said plurality of requirements is obtained from a design application. The method, wherein said reporting step provides a feedback. The method, further comprising modifying said design based on said result step.
[Para 6] An advantage of the presently preferred embodiment is to provide a computer-program product tangibly embodied in a machine readable medium to perform a method for design validation, comprising instructions operable to cause a computer to define a plurality of requirements; extract said plurality of requirements; compare a design against said plurality of requirements; and report a result of said comparison. The product, wherein said defining step is performed in a product data managed environment. The product, wherein said design is a virtual design. The product, further comprising instructions to modify said plurality of requirements from said design. The product, wherein said plurality of requirements is obtained from an external document. The product, wherein said plurality of requirements is obtained from a design application. The product, wherein said reporting step provides a feedback. The product, further comprising instructions to modify said design based on said result step. [Para 7] Another advantage of the presently preferred embodiment is to provide a data processing system having at least a processor and accessible memory to implement a method for design validation, comprising means for defining a plurality of requirements; means for extracting said plurality of requirements; means for comparing a design against said plurality of requirements; and means for reporting a result of said comparison. [Para 8] Other advantages of the presently preferred embodiment will be set forth in part in the description and in the drawings that follow, and, in part will be learned by practice of the presently preferred embodiment. The presently preferred embodiment will now be described with reference made to the following Figures that form a part hereof. It is understood that other embodiments may be utilized and changes may be made without departing from the scope of the presently preferred embodiment.
Brief Description of the Drawings
[Para 9] A presently preferred embodiment will hereinafter be described in conjunction with the appended drawings, wherein like designations denote like elements, and:
[Para 10] Figure 1 is a logic flow diagram of the method employed by the presently preferred embodiment;
[Para 1 1 ] Figure 2 illustrates a flow chart of the presently preferred embodiment; and
[Para 1 2] Figure 3 is a block diagram of a computer environment in which the presently preferred embodiment may be practiced.
Detailed Description of the Preferred Embodiments Computer System
[Para 1 3] The numerous innovative teachings of the present application will be described with particular reference to the presently preferred embodiments. It should be understood, however, that this class of embodiments provides only a few examples of the many advantageous uses of the innovative teachings herein. The presently preferred embodiment provides, among other things, a system and method for validating design requirements. Now therefore, in accordance with the presently preferred embodiment, an operating system executes on a computer, such as a general-purpose personal computer. Figure 3 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the presently preferred embodiment may be implemented. Although not required, the presently preferred embodiment will be described in the general context of computer- executable instructions, such as program modules, being executed by a personal computer. Generally program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The presently preferred embodiment may be performed in any of a variety of known computing environments. [Para 14] Referring to Figure 3, an exemplary system for implementing the presently preferred embodiment includes a general-purpose computing device in the form of a computer 300, such as a desktop or laptop computer, including a plurality of related peripheral devices (not depicted). The computer 300 includes a microprocessor 305 and a bus 310 employed to connect and enable communication between the microprocessor 305 and a plurality of components of the computer 300 in accordance with known techniques. The bus 310 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The computer 300 typically includes a user interface adapter 315, which connects the microprocessor 305 via the bus 310 to one or more interface devices, such as a keyboard 320, mouse 325, and/or other interface devices 330, which can be any user interface device, such as a touch sensitive screen, digitized pen entry pad, etc. The bus 310 also connects a display device 335, such as an LCD screen or monitor, to the microprocessor 305 via a display adapter 340. The bus 310 also connects the microprocessor 305 to a memory 345, which can include ROM, RAM, etc.
[Para 1 5] The computer 300 further includes a drive interface 350 that couples at least one storage device 355 and/or at least one optical drive 360 to the bus. The storage device 355 can include a hard disk drive, not shown, for reading and writing to a disk, a magnetic disk drive, not shown, for reading from or writing to a removable magnetic disk drive. Likewise the optical drive 360 can include an optical disk drive, not shown, for reading from or writing to a removable optical disk such as a CD ROM or other optical media. The aforementioned drives and associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules, and other data for the computer 300.
[Para 16] The computer 300 can communicate via a communications channel 365 with other computers or networks of computers. The computer 300 may be associated with such other computers in a local area network (LAN) or a wide area network (WAN), or it can be a client in a client/server arrangement with another computer, etc. Furthermore, the presently preferred embodiment may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. All of these configurations, as well as the appropriate communications hardware and software, are known in the art.
[Para 1 7] Software programming code that embodies the presently preferred embodiment is typically stored in the memory 345 of the computer 300. In the client/server arrangement, such software programming code may be stored with memory associated with a server. The software programming code may also be embodied on any of a variety of non-volatile data storage device, such as a hard- drive, a diskette or a CD-ROM. The code may be distributed on such media, or may be distributed to users from the memory of one computer system over a network of some type to other computer systems for use by users of such other systems. The techniques and methods for embodying software program code on physical media and/or distributing software code via networks are well known and will not be further discussed herein. Design Validation
[Para 1 8] Figure 1 is a logic flow diagram of the method employed by the presently preferred embodiment. Referring to Figure 1, the presently preferred embodiment provides a method for product design validation 100 that begins with defining requirements in a product data managed (PDM) environment (Step 105). The next step involves extracting the requirements from the PDM environment (Step 110). Then, validating the extracted requirements against a product design (Step 115), so that the presently preferred embodiment aligns the extracted requirements to the product design. The methods of product design validation in accordance with the presently preferred embodiment are set forth in more detail below. Step l
[Para 1 9] Figure 2 illustrates a flow chart of the presently preferred embodiment. Referring to Figure 2, a set of requirement data 200 is entered into a PDM environment like Teamcenter® sold by Siemens Product Lifecycle Management Software, Inc. by any method known to enter data, e.g., by extracting information from an external requirements document 205 created by Word or EΞxcel. Alternatively, the set of requirement data 200 can be directly entered in the PDM environment using provided tools by a design application. The requirements necessary for product development are now defined in the PDM environment (Step 105) in a PDM storage location 210, for use by a downstream process. Step 2
[Para 20] Continuing further with Figure 2, the down-stream process may include creation of product components by a design application that is preferably a CAD application 215 like NX® sold commercially by Siemens Product Lifecycle Management Software, Inc. A designer initiates the CAD application 215 and associates a product design 220 with the set of requirement data 200 stored in the PDM storage location 210. The association of the product design 220 to the set of requirement data 200 occurs by methods known in the art, for example, selecting a file or data location from a drop-down selection or entering the location in a text box. Regardless, as the designer models the various product components in an attempt to satisfy the product design 220 with the set of requirement data 200, the designer initiates a validate command 230 in the CAD application 215 using commonly known techniques. The CAD application 215 preferably extracts, at 225, the set of requirement data 200 from the PDM storage location 210 (Step 110). The extraction step can occur any number of ways, but will preferably utilize Service-Oriented Architecture (SOA) functions that return data in PLMXML format for Teamcenter objects, where PLMXML is a known and well document standard such that further discussion is not required. Step 3
[Para 21 ] Continuing with Figure 2, following the extraction 225, a number of values in the product design 220 are compared with the set of requirement data 200 to satisfy compliance with an overall design intent as defined by the set of requirement data 200 (Step 115). It is understood that requirement data can come from a variety of sources, and may preferably consist of industry or other standards, e.g., ergonomic criteria. The product design 220 will either pass or fail the test of whether the product design 200 satisfies the set of requirement data 200. At that time, error clues will alert the designer to a failed component or a passed component as defined by the set of requirement data 200. Alternatively, the designer may alter the set of requirement data 200 to comport with actual design condition, for example, a component is too large for a particular vessel and will therefore not perform as defined in the set of requirement data 200. The designer could initiate an alternate for the product design 220 that would be propagated to the set of requirement data 200 or the external requirement document 205, or alternatively kept in the PDM storage location 210. The designer initiated change would then follow standard approval processes, for example. Conclusion
[Para 22] From Step 1 through Step 3, the presently preferred embodiment has disclosed a complete solution for validating design requirements. The presently preferred embodiment may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof. An apparatus of the presently preferred embodiment may be implemented in a computer program product tangibly embodied in a machine- readable storage device for execution by a programmable processor; and method steps of the presently preferred embodiment may be performed by a programmable processor executing a program of instructions to perform functions of the presently preferred embodiment by operating on input data and generating output.
[Para 23] The presently preferred embodiment may advantageously be implemented in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. The application program may be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language if desired; and in any case, the language may be an assembled, compiled or interpreted language.
[Para 24] Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of nonvolatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD- ROM disks. Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application2-specific integrated circuits). [Para 25] A number of embodiments have been described. It will be understood that various modifications may be made without departing from the spirit and scope of the presently preferred embodiment. Therefore, other implementations are within the scope of the following claims.

Claims

What is claimed is:
[Claim 1 ] A method for design validation, comprising: defining a plurality of requirements; extracting said plurality of requirements; comparing a design against said plurality of requirements; and reporting a result of said comparison.
[Claim 2] The method of claim 1, wherein said defining step is performed in a product data managed environment.
[Claim 3] The method of claim 1, wherein said design is a virtual design.
[Claim 4] The method of claim 1, further comprising modifying said plurality of requirements from said design.
[Claim 5] The method of claim 1, wherein said plurality of requirements is obtained from an external document.
[Claim 6] The method of claim 1, wherein said plurality of requirements is obtained from a design application.
[Claim 7] The method of claim 1, wherein said reporting step provides a feedback.
[Claim 8] The method of claim 1, further comprising modifying said design based on said result step.
[Claim 9] A computer-program product tangibly embodied in a machine readable medium to perform a method for design validation, comprising instructions operable to cause a computer to: define a plurality of requirements; extract said plurality of requirements; compare a design against said plurality of requirements; and report a result of said comparison.
[Claim 10] The product of claim 9, wherein said defining step is performed in a product data managed environment.
[Claim 1 1 ] The product of claim 9, wherein said design is a virtual design.
[Claim 1 2] The product of claim 9, further comprising instructions to modify said plurality of requirements from said design.
[Claim 1 3] The product of claim 9, wherein said plurality of requirements is obtained from an external document.
[Claim 14] The product of claim 9, wherein said plurality of requirements is obtained from a design application.
[Claim 1 5] The product of claim 9, wherein said reporting step provides a feedback.
[Claim 16] The product of claim 9, further comprising instructions to modify said design based on said result step.
[Claim 1 7] A data processing system having at least a processor and accessible memory to implement a method for design validation, comprising: means for defining a plurality of requirements; means for extracting said plurality of requirements; means for comparing a design against said plurality of requirements; and means for reporting a result of said comparison.
PCT/US2008/003736 2007-03-23 2008-03-21 System and method for validating design requirements WO2008118357A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP08742183A EP2130151A1 (en) 2007-03-23 2008-03-21 System and method for validating design requirements

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US89670907P 2007-03-23 2007-03-23
US60/896,709 2007-03-23
US12/052,677 2008-03-20
US12/052,677 US20080294396A1 (en) 2007-03-23 2008-03-20 System and method for validating design requirements

Publications (1)

Publication Number Publication Date
WO2008118357A1 true WO2008118357A1 (en) 2008-10-02

Family

ID=39512663

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/003736 WO2008118357A1 (en) 2007-03-23 2008-03-21 System and method for validating design requirements

Country Status (3)

Country Link
US (1) US20080294396A1 (en)
EP (1) EP2130151A1 (en)
WO (1) WO2008118357A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190011265A (en) * 2016-05-25 2019-02-01 헥사곤 테크놀로지 센터 게엠베하 Validation of multi-component design constraints on capital project design systems

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8677316B2 (en) * 2010-05-12 2014-03-18 Microsoft Corporation Enforcement of architectural design during software development
CN103678807A (en) * 2013-12-12 2014-03-26 用友软件股份有限公司 Three-dimensional visualization method based on built-in web browser
CN109086476B (en) * 2018-06-19 2023-09-12 京东方科技集团股份有限公司 Data processing method for drawing design, PLM plug-in and computing equipment
US11237802B1 (en) 2020-07-20 2022-02-01 Bank Of America Corporation Architecture diagram analysis tool for software development

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050080502A1 (en) * 2003-10-14 2005-04-14 Chernyak Alex H. PLM-supportive CAD-CAM tool for interoperative electrical & mechanical design for hardware electrical systems
EP1657658A1 (en) 2004-04-21 2006-05-17 NSK Ltd., Automatic designing system, automatic designing method, and automatic designing program

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5572430A (en) * 1991-07-03 1996-11-05 Hitachi, Ltd. Method and apparatus for cooperated design
US6587741B1 (en) * 2000-03-07 2003-07-01 United Technologies Corporation Method and system for designing a spline coupling
JP4018356B2 (en) * 2000-07-28 2007-12-05 株式会社東芝 Product design method, product design apparatus, and storage medium for storing product design program
US7069192B1 (en) * 2000-08-25 2006-06-27 Hewlett-Packard Company CAD system
US6618840B2 (en) * 2001-02-12 2003-09-09 Hewlett-Packard Development Company, L.P. Method and system for analyzing a VLSI circuit design
US6816997B2 (en) * 2001-03-20 2004-11-09 Cheehoe Teh System and method for performing design rule check
JP3927380B2 (en) * 2001-06-07 2007-06-06 松下電器産業株式会社 NC data management apparatus and NC data management method for production system
WO2003017179A1 (en) * 2001-08-14 2003-02-27 Textron Automotive Company Inc. Method for providing design review and conformity
US7072808B2 (en) * 2002-02-04 2006-07-04 Tuszynski Steve W Manufacturing design and process analysis system
US6982731B2 (en) * 2002-09-16 2006-01-03 Shopbot Tools, Inc. Method and system for remotely providing user-defined cutting files for CNC robotic tools
TWI338262B (en) * 2003-07-25 2011-03-01 Hon Hai Prec Ind Co Ltd A system and method for managing module development
US20050049883A1 (en) * 2003-08-25 2005-03-03 Eastman Kodak Company Facilitating the design specification and ordering from a manufacturer of a particular display product
US20060106474A1 (en) * 2004-10-28 2006-05-18 Mancuso Jon R Computer aided design document generation and delivery system over distributed communication systems
US7322016B2 (en) * 2005-01-11 2008-01-22 International Business Machines Corporation Impact checking technique
US7552032B2 (en) * 2005-09-30 2009-06-23 National University Of Singapore Method and system for automated design
US8595171B2 (en) * 2007-03-23 2013-11-26 Siemens Product Lifecycle Management Software Inc. System and method for rule set validation
US8412741B2 (en) * 2007-07-17 2013-04-02 Agile Software Corporation Product network management system and method
US7788070B2 (en) * 2007-07-30 2010-08-31 Caterpillar Inc. Product design optimization method and system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050080502A1 (en) * 2003-10-14 2005-04-14 Chernyak Alex H. PLM-supportive CAD-CAM tool for interoperative electrical & mechanical design for hardware electrical systems
EP1657658A1 (en) 2004-04-21 2006-05-17 NSK Ltd., Automatic designing system, automatic designing method, and automatic designing program

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190011265A (en) * 2016-05-25 2019-02-01 헥사곤 테크놀로지 센터 게엠베하 Validation of multi-component design constraints on capital project design systems
KR102433077B1 (en) * 2016-05-25 2022-08-17 헥사곤 테크놀로지 센터 게엠베하 Validation of Multi-Component Design Constraints for Capital Project Design Systems

Also Published As

Publication number Publication date
US20080294396A1 (en) 2008-11-27
EP2130151A1 (en) 2009-12-09

Similar Documents

Publication Publication Date Title
US8595171B2 (en) System and method for rule set validation
US8768651B2 (en) System and method for automatic standardization and verification of system design requirements
JP2004171576A (en) Rapid chip management system
US9047165B1 (en) Multiversion model versioning system and method
CN101416143A (en) User interface morph based on permissions
US20080294396A1 (en) System and method for validating design requirements
US20170300305A1 (en) Executable guidance experiences based on implicitly generated guidance models
US8413109B2 (en) Systems and methods for metamodel transformation
US20060206808A1 (en) System, method, and computer program product for transformation of markup-language objects
US20110202902A1 (en) Method and System for Configurable Pessimistic Static XSL Output Validation
CN104965781A (en) Method and apparatus for generating test case
US10929108B2 (en) Methods and systems for verifying a software program
CN107193249A (en) Program development servicing unit and program development householder method
US9489459B2 (en) Single point metadata driven search configuration, indexing and execution
Bao et al. RM2Doc: A tool for automatic generation of requirements documents from requirements models
US7970587B2 (en) System and method for defining part interfaces
KR101040854B1 (en) System and method for direct sheet metal unfolding
US20070083280A1 (en) Method and system for three dimensional work instructions for modification processes
EP3999917B1 (en) Method and system for generating a digital representation of asset information in a cloud computing environment
JPWO2009011057A1 (en) Application analysis program, application analysis method, and application analysis apparatus
US10909301B2 (en) Method and apparatus for determining waiver applicability conditions and applying the conditions to multiple errors or warnings in physical verification tools
Vistbakka et al. Modelling and verification of dynamic role-based access control
US9298871B1 (en) Method and system for implementing translations of parameterized cells
US20230401355A1 (en) Method and system for validating product and manufacturing information of a geometric model
Morris et al. Reconciling SCXML Statechart Representations and Event-B Lower Level Semantics.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08742183

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2008742183

Country of ref document: EP