Design encoding of inspection requirements between components

Abstract

Assembly-level characteristics defined by the assembly tree of a product are analyzed as trigger predicates that assist in the identification (i.e., selection and / or provision) of inspection requirements for the product. Particular emphasis is placed on the hierarchical relationships of identifying assemblies, the impact of manufacturing on the visibility / accessibility of assemblies to inspection, and the use of assembly-level semantics to trigger inspection requirements. The identified inspection requirements are optionally open (semantic) or closed. In some embodiments, the identified inspection requirements are provided to an automated inspection planning system configured to generate an inspection plan, the execution of which satisfies the inspection requirements.

Description

[Technical Field]

[0001] This application claims the benefit of priority under 35 U.S.C. § 119(e) of U.S. Provisional Patent Application No. 63 / 061,206, filed August 5, 2020, the contents of which are incorporated herein by reference in their entirety.

[0002] The present invention, in some embodiments thereof, relates to the field of testing, and more particularly, but not exclusively, to automated testing for manufacturing quality control. [Background technology]

[0003] In many industries involving manufactured goods, it can be beneficial to inspect the products to ensure they are free of defects. Such inspection is often performed manually (e.g., by inspectors) and can result in various inaccuracies and inefficiencies. Summary of the Invention [Means for solving the problem]

[0004] According to an aspect of some embodiments of the present disclosure, there is provided a method for defining visual inspection requirements for a product, the method including accessing a model-based definition (MBD) that includes a design model of the product, identifying inspection requirements for components of the product based on an automated analysis of relationships between the components specified by the MBD, and encoding the identified inspection requirements for use in machine planning for the visual inspection of the product.

[0005] According to some embodiments of the present disclosure, the MBD specifies hierarchical relationships between components specified in the design model, and the identified inspection requirements are based on an automated analysis that identifies specific hierarchical relationships between the components specified in the MBD.

[0006] According to some embodiments of the present disclosure, the hierarchical relationships between components correspond to the relationships between assemblies of a product.

[0007] According to some embodiments of the present disclosure, the identification of inspection requirements is based on an automated analysis that identifies geometric relationships between components specified in the MBD.

[0008] According to some embodiments of the present disclosure, the identification of inspection requirements is based on an automated analysis that identifies patterns of component characteristics specified in the MBD.

[0009] According to some embodiments of the present disclosure, the method includes generating a visual inspection plan that meets inspection requirements and executing the visual inspection plan on at least one instance of the product.

[0010] According to some embodiments of the present disclosure, the inspection requirements include open inspection requirements that specify quality concerns regarding the inspection of one or more components specified by the MBD, without specifying characteristics or actions that correspond to the quality concerns.

[0011] According to some embodiments of the present disclosure, the open requirements are semantic requirements.

[0012] According to some embodiments of the present disclosure, generating a visual inspection plan includes converting open inspection requirements into corresponding closed inspection requirements that specify characteristics of the components and measurement actions for those characteristics.

[0013] According to some embodiments of the present disclosure, the transformation uses MBD.

[0014] According to some embodiments of the present disclosure, generating a visual inspection plan includes using hierarchical information specified by the MBD to determine the stage at which actions should be taken to satisfy the inspection requirements.

[0015] According to some embodiments of the present disclosure, generating a visual inspection plan involves using geometric information specified by the MBD to determine at what stage actions should be taken to meet inspection requirements.

[0016] According to some embodiments of the present disclosure, an automated process determines what information to extract from the MBD for conversion based on open inspection requirements.

[0017] According to some embodiments of the present disclosure, the inspection requirements include only open inspection requirements.

[0018] According to some embodiments of the present disclosure, the inspection requirements include closed inspection requirements that specify characteristics and measurement actions to be performed for characteristic measurements when the visual inspection plan is executed.

[0019] According to some embodiments of the present disclosure, the encoding includes inserting a test specification data element into the MBD.

[0020] According to some embodiments of the present disclosure, the MBD is specified as one or more QIF files, and the study specification data elements are defined with reference to elements in one or more of the QIF files.

[0021] According to some embodiments of the present disclosure, the test specification data element is defined as XML.

[0022] According to some embodiments of the present disclosure, this includes adjusting the design specifications in the MBD based on the inserted test specification data elements.

[0023] According to some embodiments of the present disclosure, adjusting the manufacturing plan based on the inserted inspection specification data element.

[0024] According to some embodiments of the present disclosure, identifying includes selecting test requirements from a predefined library of test requirements based on an analysis of hierarchical relationships specified between components defined in the MBD.

[0025] According to some embodiments of the present disclosure, analyzing the MBD document hierarchy includes identifying predicate triggers that are selection conditions for selected testing requirements.

[0026] According to some embodiments of the present disclosure, identifying a predicate trigger includes identifying an assembly that includes a predetermined component configuration.

[0027] According to some embodiments of the present disclosure, identifying a predicate trigger includes determining the visibility of components within an assembly.

[0028] According to some embodiments of the present disclosure, identifying a predicate trigger includes determining the accessibility of components within an assembly.

[0029] According to some embodiments of the present disclosure, identifying predicate triggers involves analyzing textual content within the design hierarchy specification specified by the MBD.

[0030] According to some embodiments of the present disclosure, tuning inputs modify the identification of predicate triggers to vary the way they are identified.

[0031] According to some embodiments of the present disclosure, the adjustment input includes a manual input.

[0032] According to some embodiments of the present disclosure, the tuning input includes data encoding a testing strategy.

[0033] According to some embodiments of the present disclosure, the adjustment inputs include data describing factory conditions related to one or more of parts inventory, parts sources, tool conditions, tool availability, worker training conditions, and labor allocation.

[0034] According to some embodiments of the present disclosure, the method includes modifying the selection according to the adjustment input.

[0035] According to some embodiments of the present disclosure, the modifications include adding, removing, or modifying specific inspection requirements.

[0036] According to some embodiments of the present disclosure, the adjustment input includes a manual input.

[0037] According to some embodiments of the present disclosure, the tuning input includes data encoding a testing strategy.

[0038] According to some embodiments of the present disclosure, the adjustment inputs describe factory conditions related to one or more of parts inventory, parts sources, tool conditions, tool availability, worker training conditions, and labor allocation.

[0039] According to some embodiments of the present disclosure, identifying includes providing selected inspection requirements.

[0040] According to some embodiments of the present disclosure, an MBD document includes one or more QIF files.

[0041] According to some embodiments of the present disclosure, the inspection requirement is an open inspection requirement that is selected based on identifying a trigger predicate within the MBD that indicates that the assembly belongs to a class for which a semantic inspection agent is available.

[0042] According to an aspect of some embodiments of the present disclosure, there is provided a system for defining visual inspection requirements for a product, the system comprising: a computer processor and a memory, the computer processor configured to access instructions in a memory medium, the instructions directing the processor to: access from the memory a model-based definition (MBD) including a design model of the product, identify inspection requirements for components of the product based on an automated analysis of relationships between the components specified by the MBD, and encode the identified inspection requirements for use in machine planning for visual inspection of the product.

[0043] According to some embodiments of the present disclosure, the MBD includes one or more QIF format files.

[0044] According to some embodiments of the present disclosure, the specified inspection requirements are encoded as an XML file.

[0045] According to some embodiments of the present disclosure, an MBD specifies hierarchical relationships among components specified in a design model, and a computer processor identifies inspection requirements by identifying specific hierarchical relationships among the components specified in the MBD.

[0046] According to some embodiments of the present disclosure, the hierarchical relationships between components correspond to the relationships between assemblies of a product.

[0047] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present disclosure, exemplary methods and / or materials are described below. In case of conflict, the present specification, including definitions, will control. Furthermore, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

[0048] As will be appreciated by those skilled in the art, aspects of the present disclosure may be embodied as a system, method, or computer program product. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment containing both software and hardware aspects, all of which may be collectively referred to herein as a "circuit," "module," or "system" (e.g., a method may be implemented using "computer circuitry"). Furthermore, some embodiments of the present disclosure may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied therein. Implementation of the methods and / or systems of some embodiments of the present disclosure may involve performing or completing selected tasks manually, automatically, or a combination thereof. Furthermore, depending on the actual instrumentation and equipment of some embodiments of the methods and / or systems of the present disclosure, some selected tasks may be implemented by hardware, software, firmware, and / or a combination thereof, such as using an operating system.

[0049] For example, hardware for performing selected tasks according to some embodiments of the present disclosure may be implemented as a chip or circuit. As software, selected tasks according to some embodiments of the present disclosure may be implemented as software instructions executed by a computer using any suitable operating system. In some embodiments of the present disclosure, one or more tasks performed by the methods and / or systems are performed by a data processor (also referred to herein as a "digital processor" to refer to a data processor that operates with groups of digital bits), such as a computing platform that executes instructions. Optionally, the data processor includes volatile memory for storing instructions and / or data, and / or non-volatile storage, e.g., a magnetic hard disk and / or removable media, for storing instructions and / or data. Optionally, a network connection is also provided. A display and / or user input device, such as a keyboard or mouse, are also optionally provided. Any of these implementations are generally referred to herein as instances of computer circuitry.

[0050] Any combination of one or more computer-readable media can be used for some embodiments of the present disclosure. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media may include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the context of this specification, a computer-readable storage medium may be any tangible medium that can hold or store a program for use by or connected to a system, apparatus, or device that executes instructions. A computer-readable storage medium can hold or store information for use by such programs, such as data stored by the computer-readable storage medium and structured so that the computer program can access it, for example, as one or more tables, lists, arrays, data trees, and / or other data structures. A computer-readable storage medium that stores data in a form that can be read as groups of digital bits is also referred to herein as digital memory. It should be understood that in some embodiments, a computer-readable storage medium can also be used as an optional computer-readable storage medium, provided that the computer-readable storage medium is not inherently read-only and / or in a read-only state.

[0051] As used herein, a data processor is said to be "configured" to perform data processing operations so long as the data processor is coupled to a computer-readable memory so as to receive instructions and / or data therefrom, process them, and / or store the results of the processing in the same or another computer-readable storage memory. The processing (optionally on data) to be performed is specified by the instructions. Processing operations may additionally or alternatively be referred to by one or more other terms, such as comparing, evaluating, determining, calculating, identifying, associating, storing, analyzing, selecting, and / or transforming. For example, in some embodiments, a digital processor receives instructions and data from a digital memory, processes the data in accordance with the instructions, and / or stores the results of the processing in the digital memory. In some embodiments, "providing" the results of the processing may include one or more of transmitting, storing, and / or presenting the results of the processing. Presenting optionally includes displaying, sounding, printing, or providing the results in any other form accessible to human perception.

[0052] A computer-readable signal medium may include a propagated data signal in which computer-readable program code is embodied, for example in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including but not limited to, electromagnetic, optical, or any suitable combination thereof. A computer-readable signal medium may be any computer-readable medium, other than a computer-readable storage medium, that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0053] The program code embodied in the computer readable medium and / or data used thereby may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, etc., or any suitable combination thereof.

[0054] Computer program code for carrying out operations of some embodiments of the present disclosure may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The program code may run entirely on the user's computer, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server, as a standalone software package. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider).

[0055] Some embodiments of the present disclosure are described below with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions are provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus forming a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, generate means for performing the functions / acts identified in one or more blocks of the flowchart illustrations and / or block diagrams.

[0056] These computer program instructions may also be stored on a computer-readable medium that can instruct a computer, other programmable data processing device, or other device to function in a specific manner, such that the instructions stored on the computer-readable medium can produce an article of manufacture that includes instructions that implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0057] Computer program instructions may also be loaded into a computer or other programmable data processing apparatus or other device to cause the computer or other programmable data processing apparatus or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions executing on the computer or other programmable apparatus provide processing that implements the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0058] Some embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings. Specific reference will now be made in detail to the drawings, it being emphasized that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the present disclosure. In this regard, the description taken together with the drawings will make apparent to those skilled in the art how embodiments of the present disclosure may be practiced. [Brief explanation of the drawings]

[0059] [Figure 1A] FIG. 1 is a schematic diagram of a method for automatically identifying inspection requirements according to some embodiments of the present disclosure. [Figure 1B] FIG. 1 is a schematic diagram of a system for automatically identifying assembly tree-based inspection requirements for a product, according to some embodiments of the present disclosure. [Figure 1C] 1A-1C are schematic diagrams illustrating a comparison between open and closed inspection requirement specifications, according to some embodiments of the present disclosure. [Figure 2A] FIG. 1 is a schematic diagram of aspects of a model-based design document, according to some embodiments of the present disclosure. [Figure 2B] FIG. 1 is a schematic diagram of a method for identifying component-based trigger predicates in an assembly tree according to some embodiments of the present disclosure. [Figure 2C] FIG. 1 is a schematic diagram of a method for identifying text-based trigger predicates in an assembly tree according to some embodiments of the present disclosure. [Figure 3] 1A-1C are schematic diagrams illustrating images of an inspected portion of a keyboard, according to some embodiments of the present invention. [Figure 4] FIG. 1 is a schematic diagram showing an image of a portion of a computer case according to some embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0060] The present invention, in some embodiments thereof, relates to the field of testing, and more particularly, but not exclusively, to automated testing for manufacturing quality control. (Overview) Automatic selection of inspection requirements

[0061] A broad aspect of some embodiments of the present disclosure relates to automatically selecting and / or preparing visual inspection requirements for a product using information extracted from the product's design / manufacturing documentation. In some embodiments, this is enabled using a system and / or method where a library of potential inspection requirements is semantically grouped according to one or more trigger predicates.

[0062] For example, a grouping can effectively be defined as "inspect X1, X2... for Y." In this formulation, "Y" is the trigger predicate and "X1, X2..." are the group of inspection requirements. The trigger predicate and / or the inspection requirements can be further parameterized, and parameters can optionally be provided according to, for example, manual input, quality policies, and / or input gathered from design / manufacturing documents (e.g., shapes and / or inter-component relationships specified by the design / manufacturing documents). Functionality is provided for automatically identifying trigger predicates within design and / or manufacturing documents.

[0063] For example, a part (i.e., an item that is used as a component of a manufactured product and has particular attributes, such as its 3D orientation within the manufactured product) may belong to an inspection requirement because of trigger predicates about what it is, what it has, and / or how it relates to one or more other components. The trigger predicates are preferably determined from documents (e.g., annotated and optionally layered 3D models) that are obtained as an artifact of the design / manufacturing planning.

[0064] The identified trigger predicates are used to associate the semantically grouped inspection requirements to a quality inspection process of a manufactured product, for example as requirements to be satisfied by an inspection plan.

[0065] In some embodiments, the inspection performed is more specifically a visual inspection, such as a production inspection based on appearance in an image, as can be distinguished from metrological inspection, which performs distance-based measurements, for example, by the use of a distance measuring device that operates in direct contact with the inspected object.

[0066] Trigger Predicate A trigger predicate, as used herein, is any fact (or complex of facts) within a given information set that is recognized within the context of some process as implying a link (semantic association) to semantic information (see below).

[0067] Trigger predicates can be further characterized according to label and property aspects. A simplified example for illustrative purposes might be a process for manipulating a complex collection of objects consisting of red balls and blue cubes. Within the context of this process, if a red object is identified, it is also a ball. In this context, "red" can be used as a trigger predicate to recognize that the object has semantic properties appropriate for manipulating balls. For the purposes of the process, the object "is a ball" and has ball-like properties relevant for manipulation (e.g., it rolls and is maximum at half its height). Alternatively, a trigger predicate may be more specific to the semantics it links to, such as "has a curved contour." This illustrates how a trigger predicate can have ancillary or label aspects ("red" gives a selectable tag to all round objects in the example, even though being round has nothing to do with being round) or intrinsic / property aspects ("curved" is a consequence of being a round object). Either aspect is optionally used in some embodiments of the present disclosure, as are trigger predicates that may combine the two aspects.

[0068] The present disclosure relates to inspection processes for manufactured products. In some embodiments, trigger predicates are identified from aspects of design / manufacturing documentation that specify the manufactured product or that exist for uses separate from the quality inspection plan itself. The trigger predicates can document product "characteristics" (e.g., product shape and / or composition), or can include "labels" (e.g., names of components and / or names of component assemblies), or some combination thereof (e.g., insofar as textual documentation typically relies on labels to indicate characteristics).

[0069] In some embodiments of the present disclosure, trigger predicates are derived from data elements of the product's design / manufacturing documents, such as data element specifications, labels, text, and / or images, etc. Identification of trigger predicates from the design / manufacturing documents may be manually assisted, for example, through the use of a manually operated computer input device, a speech-to-text input function, user action tracking, or another input method.

[0070] The trigger predicates are preferably intrinsic to the design / manufacturing documents. However, they may optionally be inserted into the design / manufacturing documents, particularly for reasons related to the inspection requirements. Optionally, the trigger predicates are specified using tuning input from outside the design / manufacturing files themselves. Optionally, the automatically selected inspection requirements are subjected to further preparation processes, such as parameterization or their removal or deletion (automatically and / or manually).

[0071] Trigger predicates and semantic information Semantic information is used herein to refer to information that goes into a process (eg, performed by a computer processing system) as part of denoting something.

[0072] For example, a particular element in a 3D drawing consisting of a set of vertices and edges can be further classified as a "screw" (e.g., by labeling it with a text-encoded attribute, as exemplified by type="screw"). As a purely syntactic matter, this can augment the information in the drawing by associating it with a selection and group of elements in a particular formal way, e.g., based on the text assigned to the attribute labeled type. However, the label itself does not serve to describe the screw in that respect. A different label, used consistently within the drawing according to the expected syntax, conveys the same syntactic information.

[0073] However, the same label that acts as a trigger predicate can also cause a computer processing system to associate specific semantic information with the element. Additionally or alternatively, attributes of the vertices or lines themselves (such as the outer surface of a helical shape) can be trigger predicates that can indicate that the element is a screw.

[0074] The semantic information carried by the denotation may embody "what it means to be a screw" to a processing system. At a more mechanical level, this meaning provides consequences (optionally ultimate physical consequences) beyond the trigger predicate itself. These consequences may be, for example, digitally encoded and / or linked to actions appropriate to the mechanical screws. Semantic information may be collectively referred to herein as constituting a semantic group, particularly when semantically related to elements via a common trigger predicate.

[0075] Facts distributed across multiple logically encoded elements (e.g., conforming to a pattern) can also serve as trigger predicates in some embodiments of the present disclosure. For example, an assembly element may be syntactically specified as including a subelement of type:axle, which has the relationship of being attached to each of two subelements of type:wheel. This pattern can then become a trigger predicate, which, when processed, reveals the semantic information that wheels attached to an axle are mounted at opposite ends of the axle so that they rotate on their centers. In the context of an inspection system, one result could be the execution of a test of the rotation function of the assembly element. Patterns consisting of this type of "distributed fact" are not limited to subassemblies. For example, trigger predicates could include facts such as separately assembled edge elements of the same color or fasteners exposed on a functionally specific (e.g., inner, outer, top, or bottom) surface of a product.

[0076] Open / Semantic Specifications In some embodiments, the semantic association process is mediated by an intermediate element, referred to herein as a semantic specification. A semantic specification can be understood as an explicit relationship between a trigger predicate and the semantic information it is intended to indicate. As an example, a particular semantic specification can bind the trigger predicate type="screw" (which can be defined as a textual label for a particular bit of data in a design document) to the semantic information "consisting of a slotted head and a threaded shaft." A different semantic specification can bind the trigger predicate size="M4" to the same semantic information, while another different semantic specification can bind the trigger predicate type="screw" to further semantic information such as "implies the presence of a matching screw hole."

[0077] Furthermore, semantic specifications are referred to herein as being "open" (as opposed to "closed") in a domain-specific sense. Semantic specifications are generally high-level; the lower-level building blocks (primitives) on which their meaning depends remain undescribed ("open"). However, this high-level description is resolved into concrete content ("closing" the semantic specification) when the semantic specification is interpreted downstream by an appropriately capable agent. "Open" and "closed" refer to primitives defined with respect to a particular domain. For the domain of testing specifications relevant here, these primitives are described more specifically below.

[0078] As an example, recognizing any element with the trigger predicate type="screw" optionally generates an open semantic specification rotatable="true" for that element (e.g., in the manufacturing document of the product). This allows subsequent processing stages to apply "rotation semantics" to that element, possibly without recognizing the rotatability of screw-shaped objects in general, and instead by directly recognizing the semantic specification. Here, the automated module that performs such subsequent processing is also referred to as a "semantic agent," and in the case of processing specifically aimed at quality inspection, is particularly referred to as a "semantic inspection agent" or simply an "inspection agent."

[0079] The relationship between closed and open (semantic) specifications In the specific context of a particular testing requirement, the semantic specification specifies one or more testing actions (e.g., by labels based on the original trigger predicate and, optionally, by parameters), while deferring the specification of detailed specifications ("primitives") about how the testing actions are actually performed. This deferral is a hallmark of "openness." This has the potential benefit of reducing the complexity of testing requirement specifications, by avoiding communication about details about the underlying primitives.

[0080] In contrast, when used in, for example, manual or "low-level automated" quality inspection processes, inspection requirements are specified by a direct linkage between the characteristics to be inspected (the characteristics of the product that are actually measured) and the inspection actions that verify them (i.e., take the measurements and optionally evaluate the measurement results).

[0081] Such requirements are also referred to herein as "closed." These characteristics and / or actions self-containedly specify inspection "primitives," leaving little or no practical ambiguity. In particular, primitives require no further explanation or simplification in order to be used to create detailed inspection plans whose implementation ensures the quality level required by the inspection requirements. In the context of visual inspection, primitive measurements include, but are not limited to, histograms, gradients, blob analysis, morphology (e.g., distances and angles), and surface normal measurements. Quality inspections that use low-level automated resources (e.g., automated metrology) benefit from specifying closed inspection requirements because the given details precisely state what should be measured, reducing the scope for ambiguity in configuration and verification.

[0082] In some embodiments of the present disclosure, the testing requirements selected and / or prepared based on the identified trigger predicates are "open" and semantically specified (also referred to herein as "semantic testing requirements"). To be realized, the semantic testing requirements are reduced to primitives of properties and testing actions (e.g., by a suitable semantic testing agent configured to process the semantic testing requirements). In effect, the semantic testing requirements are closed by the operation of the semantic testing agent.

[0083] Being closed may include combining semantic testing requirements with other information in the manufacturing file and / or with representations and / or instantiations of domain knowledge that interpret the semantic testing requirements. Again, relying on a later breakdown into primitives (implicit or explicit) to enable a useful testing plan to be defined makes the semantic testing requirements "open."

[0084] Not all "open" inspection requirements necessarily close to explicitly specified primitives. For example, an open inspection requirement might specify verifying that a screw head is free of tool damage marks. The verification method implemented by a semantic inspection agent might involve, for example, classifying the screw head as damaged or undamaged and applying a machine learning function that produces this classification as the only output. In this case, there is still closure to be done because the inspection requirement conveys few or no primitive geometric properties to evaluate, and the machine learning function still produces results that depend on the characteristics of these properties.

[0085] Optionally, after receiving the semantic test requirements determined as in some embodiments of the present disclosure, a downstream test planning system (e.g., a semantic test agent) finally "closes" the test requirements. The test planning system does this by creating a plan that specifies what and how to actually do measurements that test the requirements. Optionally, a list of "closed" test requirements is not actually created, or if there is a list (e.g., for verification purposes), it may be a by-product of the test plan rather than an input to the test plan.

[0086] In particular, open and closed testing requirements can be further compared in terms of the type of information they specify. Closed test requirements specify measurement actions to be performed on component characteristics. The measurement results are compared to one or more specified values ​​to determine whether the requirement is met. Open inspection requirements specify quality concerns to be evaluated (e.g., by a semantic inspection agent) for one or more components with particular denotations (or "classes") and / or relationships.

[0087] Downstream inspection resources (e.g., inspection planning facilities and / or semantic inspection agents) are then responsible for matching the items of concern to measurements appropriate for component representations and annotations. In some embodiments of the present disclosure, annotations are provided along with the inspection requirements. The annotations, in some embodiments, include an indication of the hierarchical validity of the requirements, such as that they must or should be met within a certain range of assembly levels. For example, an inspection "too early" may not be possible because the inspection target has not yet been manufactured, and an inspection "too late" may not be possible because the inspection target is at least partially obscured or otherwise difficult to access.

[0088] As an example to illustrate the difference between open (or semantic) and closed (or low-level) inspection requirements, a semantic inspection requirement might be "Verify that this connector is properly installed." "Connector" is the denotation, and "properly installed" is the concern. Translating this requirement into more specific inspection actions is deferred until, for example, a semantic inspection agent is run. The connector is optionally annotated with its subtype, a standard type such as RJ45 or DIN-9, an extended part number, or another specification. In contrast, a corresponding low-level inspection requirement might specify, for example, orientation angles, distances, soldering position dimensions, and possibly even more details. Each of these specifics is a characteristic with an associated measurement action and a range of acceptable values. In contrast to using a semantic inspection agent, which is itself a "smart" inspection resource, these characteristics and actions are specified even before inspection resources can be allocated.

[0089] The level of semantic specification can be more detailed than the example given (e.g. annotated with parameters such as tolerances that affect the meaning of "properly fitted"), but this is still "open" in the sense that it depends on the interpretation applied to the actual measurement process.

[0090] Using semantic inspection requirements for inspection planning Semantic testing specifications have a potential disadvantage in the context of traditional quality assurance (operated manually and especially with low levels of automation) because they leave aspects of the requirements potentially vague (open to interpretation), but they have a potential advantage in the context of automated quality testing, where there is a high level of predetermined competence in the testing task.

[0091] In particular, sophisticated inspection tools are capable of embodying a sufficiently rich data representation of inspection targets (i.e., one or more generic classes / representations of inspection targets) so that they can autonomously plan the fulfillment (and "closure") of semantic inspection requirements. For example, the tool can translate an open requirement such as "properly installed" into the tests and evaluations necessary to close that requirement. The rich data representation provides information, for example, about which properties are relevant to the inspection concern and how to interact with the inspection target (e.g., image it) to measure those properties.

[0092] Additionally or alternatively, a rich data representation may provide testing capabilities beyond the level of individual features and for more global assessment. For example, damage to a threaded socket can be assessed without specific reference to its individual surfaces (which would be considered features), but rather with reference to patterns or abstractly specified features of a collection of socket surfaces that a dedicated machine learning product is configured to recognize. Again, the open specification of the test requirements does not specify these features, and perhaps no specific features at all. Instead, the inspection tool "understands" which features are relevant to the concerns conveyed by the inspection requirements.

[0093] Generating and communicating through closed testing requirements with testing tools that have such capabilities may seem unnecessary and burdensome. Particularly for machine learning-based testing functions, knowledge of how to specify the relevant closed testing requirements may not be available outside the automated testing tool itself. In contrast, the open nature of semantic testing requirements potentially supports (e.g., simplifies) the automation of testing requirement specification itself.

[0094] In accordance with the terminology framework defined above, some embodiments of the present disclosure provide one or more methods for identifying trigger predicates for a product and identifying inspection requirements that are semantically grouped according to the identified trigger predicates. The inspection requirements may be closed or, in some preferred embodiments, open. Optionally, once identified, the inspection requirements are integrated into design / manufacturing documentation.

[0095] Selection of inspection requirements using assembly tree hierarchy It will be appreciated that efforts to automate the identification of inspection requirements may, in some embodiments, result in a collection of approaches, each addressing a different aspect of the task.

[0096] An aspect of some embodiments of the present disclosure relates to using relationship characteristics defined by a product's assembly tree and / or product tree as trigger predicates to assist in identifying (i.e., selecting and / or preparing) inspection requirements for a product.

[0097] In some embodiments, the relationship characteristics are based on the design hierarchy and / or geometric relationships between assembled components in the design. Some relationship characteristics are of a different or additional type, such as grouping individual components based on characteristics (e.g., color, style, part classification, or other characteristics) that span different branches of the design hierarchy and do not themselves have a specific relationship with respect to geometry or assembly.

[0098] As used herein, both assembly trees and product trees are hierarchically organized lists that may be specified as part of a product design document. The leaves of the hierarchy are components, which correspond to parts of the tree; the higher-level nodes are component groups, and the final group is the product itself. The two trees differ in their usage. A product tree is a hierarchical structure that reflects the CAD hierarchy, while an assembly tree is a hierarchical structure that reflects the manufacturing sequence. The two may use the same hierarchical structure, but this is not required. For example, a CAD hierarchy may group components based on characteristics such as similarity of properties or function, while an assembly tree may group components based on when they are attached to each other during the assembly process (such that nodes correspond to physical assemblies). Herein, the term "design hierarchy" includes either or both an assembly tree and a product tree.

[0099] The identified inspection requirements are optionally open (semantic) or closed. Optionally, the identified inspection requirements are provided to an automated inspection planning system configured to generate an inspection plan, the actions of which fulfill the inspection requirements.

[0100] According to this aspect of the disclosure, some component relationships within a product may have special relevance as trigger predicates for inspection requirements.

[0101] In some embodiments of the present disclosure, the design hierarchy of a product is used as a guide for selecting quality inspection requirements. The design hierarchy is analyzed to look for the presence of certain characteristics. The analysis output is then used as a trigger predicate based on which appropriate inspection requirements are assigned to the assembly. In some embodiments, the analysis output includes a classification of the assembly.

[0102] In some embodiments, at least some assemblies within a product comprise units of a generally standard type and / or with generally standard characteristics. Subassembly types tend to be recurring within a particular manufacturing domain (e.g., a particular industry). For example, an assembly in an electronic product may be a keyboard, a group of connectors, a circuit board, or a case (to name a few). An assembly in a furniture product may include items such as frames, drawers, rails, trim pieces, and spring units. In vehicle manufacturing, there are a vast number of assembly types, such as the chassis, body, engine, transmission, doors, and instrument displays. Each of these is in turn made up of its own numerous subassemblies.

[0103] Within design and manufacturing documentation, assemblies are optionally (but typically are) labeled with a type. The range of valid labels can be, for example, tightly controlled (e.g., to a predefined list of options) or more free-form (e.g., descriptive phrases entered by the designer). Other textual information that explicitly identifies the type can also be used, such as keywords associated with the assembly. Thus, labels and keywords can, in whole or in part, form the basis for assembly classifications. Furthermore, assembly classifications become trigger predicates that associate inspection requirements with assemblies. Note that these kinds of assembly classifications roughly correspond to the "label-like" aspects of the trigger predicates described above.

[0104] Additionally or alternatively, assembly type can be identified at least in part by assembly characteristics, such as assembly class designations, and / or geometric relationships between components. Type identification can be provided straightforwardly by component identifiers. For example, an assembly consisting of multiple connector components can be classified as a connector group. An assembly consisting of multiple keycaps can be classified as a keyboard. Additionally or alternatively, geometry can be used to aid in assembly designation based on the spatial grouping of components, the spatial proximity of components, or another geometric criterion. Component-based identification is optionally limited to the specific assembly level that contains the component, e.g., the first or second assembly level that incorporates it, since that assembly can then be a subassembly of other assemblies, leading to an assembly corresponding to a complete product.

[0105] Component-based assembly type identification may depend on one or more component types. For example, a first assembly level containing both an axle and two wheels may be designated a wheeled axle assembly. Additionally or alternatively, assembly type designations may be based on non-component features obtained during manufacturing. For example, a sheet metal part may become a case panel (as far as inspection requirements are concerned) only after forming, cutting, and / or finishing steps.

[0106] Optionally, an assembly type is first identified based on such features as it is retrieved along the assembly tree of the product, and this type is then treated as a trigger predicate associated with the inspection requirement, although it should be understood that the feature itself is optionally a sufficient trigger predicate.

[0107] It should be understood that there is no particular restriction that an assembly must be of a single type. Assembly classification optionally relies on any number of type specifications and / or characteristics, which can then be grouped into a single, but optionally compound-defined, trigger predicate. Additionally or alternatively, trigger predicates can be defined more simply (e.g., as a primary assembly classification such as keyboard), and specific keyboard features and / or type specifications can be applied as annotations to refine what is represented as a keyboard, allowing for more specific specification of inspection requirements.

[0108] An assembly may also have multiple classifications applied (associated with multiple corresponding sets of inspection requirements that are triggered thereby). For example, an assembly described as a keyboard may also be described as an indicator board (e.g., because it includes LEDs that light up depending on status and / or key presses). The description provided herein focuses on examples of single-stream analysis / classification / inspection requirements. However, it should be understood that multiple-stream embodiments are also within the scope of this specification.

[0109] Before describing at least one embodiment of the present disclosure in detail, it is to be understood that the disclosure is not necessarily limited in its application to the details of construction and the arrangement of components and / or methods set forth in the following description and / or illustrated in the drawings. Features described in the present disclosure, including features of the present invention, are capable of other embodiments or of being practiced or carried out in various ways.

[0110] How to identify inspection requirements Reference is now made to Figure 1A, which is a schematic diagram illustrating a method for automatically identifying inspection requirements, according to some embodiments of the present disclosure. Optionally, the identified inspection requirements are linked (e.g., by insertion at the document level and / or reference to data elements) to the design and / or manufacturing process (including one or both of manufacturing and / or inspection).

[0111] In block 110, in some embodiments, the relationships of the product's components (e.g., hierarchical relationships as discussed in connection with FIG. 2A ) are analyzed to determine the presence of a trigger predicate. Optionally, the trigger predicate has aspects that are manifested by the hierarchical nature of the design hierarchy. For example, it depends on the properties produced by the assembly (at a particular stage in the assembly tree). In another example, the trigger predicate may be a geometric relationship. For example, two parts with ends that extend toward each other and have nothing between them other than a non-zero distance define a geometric "gap." Gap significant as a trigger predicate may be further limited to occur between components with specific designations, such as keycaps and housing parts.

[0112] In block 112, in some embodiments, a semantic group of inspection requirements is selected (e.g., from inspection requirement library 124 (FIG. 1B)) based on a trigger predicate. In some embodiments, one or more inspection requirements have aspects that are affected by the design hierarchy. For example, the target of an inspection requirement may only exist at or after a particular stage of assembly, or the target may be unavailable for inspection (e.g., hidden) at or after a particular stage of assembly. In some embodiments, this aspect relates to optimizing the inspection plan. For example, there may be cost trade-offs for inspecting targets at different stages of assembly.

[0113] Optionally, in some embodiments, inspection requirements are prepared at block 114. This optionally includes a collection of parameters, for example, from design documents (including geometry and / or relationships between components) and / or by user input. The collected parameters are used to populate the inspection requirements with specific information appropriate for the particular requirement.

[0114] Optionally, the semantic group of the inspection requirements themselves contains semantic (open) specifications of the inspection requirements, which may already be complete as far as the needs of other processes (e.g. inspection planning) are concerned, since the semantic specifications are interpreted by a process consisting of high-level, pre-defined "expertise".

[0115] Therefore, the semantic specification optionally does not undergo significant preparation in block 114. Instead, it may be worthwhile to further prepare any special inspection requirements, for example, by adding annotations that provide more information than the notation expresses. These annotations can come from, for example, product documentation, factory conditions, and / or manual input. The preparation in block 114 can also be used to remove inspection requirements or add inspection requirements (e.g., manually add inspection requirements not identified by automatic selection). A type of annotation of particular interest in some embodiments of the present disclosure is annotations that specify the effect of design hierarchy on inspection requirements, such as when (during assembly) inspection is optimal, preferred, possible, and / or impossible.

[0116] In some embodiments, at least some "closed" test requirements are provided, which, even if closed, are still members of a "semantic group" of test requirements as long as they are expressed in a trigger predicate as described in block 112.

[0117] Providing closed inspection requirements is optionally done at this stage by defining at least some of the inspection requirements in the library as templates for closed inspection requirements, which are then filled in appropriately in a preparation process at block 114. For example, a particular part number described as a component in an assembly tree may be a trigger predicate for a set of closed inspection requirements prepared by metadata associated with the part number in the parts database (e.g., with expected and acceptable values).

[0118] Providing closed inspection requirements may be useful in an inspection environment that has a mix of highly automated inspection resources and subordinate inspection resources (e.g., fixed metrology equipment). Additionally or alternatively, an inspection requirement may be "open" after selection and optional preparation (at block 114) and instead converted to a "closed" state at a later stage in the inspection planning. At a later stage, an open inspection requirement that governs inspection tasks assigned to subordinate inspection resources may be redesignated as one or more closed inspection requirements.

[0119] Optionally, in block 116, the identified inspection requirements are linked to the design and / or manufacturing process. Linking typically involves defining new data elements at the document level that specify the inspection requirements. Linking also involves some kind of reference relationship between the new data elements and existing data elements in the design / manufacturing document. For example, if the inspection requirements are processed into XML-encoded elements, the XML elements may be inserted where it is clear from the context which component / assembly they qualify. Alternatively, the XML elements may form separate sections that link to specific components / assemblies by specifying field values. Linking to any particular existing document may optionally be in either direction, including two-way, and linking to documents is optionally multi-directional across multiple documents.

[0120] Linking to design processes is "backward" (potentially affecting the design process itself, e.g., in corrections), while linking to manufacturing processes such as manufacturing and inspection is "forward" (e.g., by specifying inspection requirements to be used by inspection agents). A single linking (e.g., a snippet of XML) can link to both forward and backward processes simultaneously. Links, whether forward or backward (or both), can be used to trigger a reconsideration somewhere in the design / manufacturing chain whenever any element in the design / manufacturing chain is changed. Linking can be specified, for example, using an XML Schema. An example of an inspection requirement annotation specified by such an optional XML Schema is shown below:

[0121] In a "backward" sense, inspection requirements make explicit something that may have been implicit (or nearly implicit) in the original design, or conversely, emphasize something that the original design left obscure. Explicitly incorporating inspection requirements into design documentation can affect the design itself (i.e., future revisions of the design). For example, linking makes it clear to those reviewing the design what inspection costs may be associated with specific components of the product. This can, for example, motivate design changes to reduce costs. Potentially, linking inspection requirements to design documentation highlights opportunities for design changes that could result in the elimination, consolidation, or streamlining of inspection processes.

[0122] More specifically, in some embodiments, this can affect the hierarchy of the assembly tree. A design reviewer can determine at which stage a particular component is inspectable, potentially leading to an understanding of how design changes can impact the scope of this stage, potentially enabling improvements to the manufacturing process and / or overall quality. For example, an early stage may have one hidden screw that requires the setup of a special inspection station, and the design may later be modified to include a window above the screw that allows inspection at a different inspection station.

[0123] In a "forward" sense, inspection requirements provide primary input to inspection planning. Additionally, and specifically in conjunction with inspection planning, inspection requirements can influence how manufacturing occurs. For example, inspection tasks can be intermixed with manufacturing tasks along an assembly line. This can affect tooling, how tasks are distributed among assembly stations, and other aspects of manufacturing. To the extent that inspection requirements incorporate information about when they can be performed (e.g., at what stage in the assembly hierarchy), this can increase manufacturing planning flexibility and / or present opportunities for improved manufacturing efficiency.

[0124] A system for identifying inspection requirements Reference is now made to Figure 1B, which schematically illustrates a system for automated identification of inspection requirements based on a design hierarchy 120 of a product, in accordance with some embodiments of the present disclosure.

[0125] System Modules and Inputs In overview, trigger predicate analyzer 126 receives information from design hierarchy 120 and trigger predicate library 122 (if constructed) and outputs trigger predicates found in design hierarchy 120, corresponding to block 110 of FIG. 1A. Test requirement preparer 128 receives the trigger predicates and applies them to select from test requirement library 124 and, optionally, performs other preparation operations on the selected test requirements, corresponding to the operations of blocks 112 and 114 of FIG. 1A. The prepared test requirements can then be distributed, for example, incorporated into design document 131, provided to test plan 135 (optionally, "to test plan" refers to providing "to a semantic test agent"), and / or provided as input to manufacturing plan 133.

[0126] In general, the test requirements library 124 can be viewed as a dictionary that associates groups of one or more test requirements with respective trigger predicates. Test requirements (belonging to the test requirements library 124) are defined and discussed herein as part of the overview, and additional examples are provided with the descriptions of, for example, Figures 2A, 3, and 4.

[0127] Trigger predicates (belonging to optional trigger predicate library 122) are defined and discussed herein as part of the overview, and additional examples are provided with the descriptions of, for example, Figures 2A, 3, and 4. They can be detected (e.g., by trigger predicate analyzer 126) within design hierarchy 120 based on, for example, component content (e.g., Figure 2C) and / or textual content (e.g., Figure 2B). Component content refers to any design hierarchy 120 or tuning input 121 content that identifies and / or characterizes a component. This can be determined based on, for example, geometry, textual content, image content, or any combination thereof.

[0128] The textual content can also be component content, but the concept extends to any other textual annotations of the design hierarchy 120 and adjustment inputs 121. In particular, keywords, instructions, and comments can more generally indicate inspection policies, quality policies, and / or manufacturing conditions, regardless of their association with a particular component or design feature.

[0129] Furthermore, it should be understood that specifying trigger predicates is not limited to the use of "component content" and "text content." Operator instructions, for example, speech or gestures, can be used to specify trigger predicates, as can optional adjustment input 121, as described below.

[0130] The inspection requirements preparer 128 optionally supplies parameters, such as extraction type, tolerances, criteria, or other necessary data, for the selected inspection requirements. In some embodiments, the downstream process itself performs such extraction, for example, also using access to data in the design hierarchy 120.

[0131] Tuning inputs 121, 123 may optionally be provided to respectively tune the trigger predicate analysis in block 126 and / or the test requirement preparation in block 128. There may also be "crosstalk" (e.g., as described below) between the test requirement library 124 and the trigger predicate library 124, and / or between the found trigger predicates and the test requirement library 124.

[0132] Other interactions between system modules and inputs The optional interactions between these functional blocks, their inputs and their operations are further described below.

[0133] The primary inputs to the trigger predicate analyzer 126 include the design hierarchy 120 itself and the test requirements library 124 .

[0134] Optionally, a separate trigger predicate library 122 is provided. This can provide a separation between the test requirements library and the design hierarchy. For example, the test requirements library 124 can specify a group of requirements that apply to a trigger predicate named screw. On the other hand, the trigger predicate library can link the name screw to a more specific specification that defines a screw element in the design hierarchy 120. The trigger predicate library 122 can also include specifications for how to access information outside the design hierarchy (e.g., user prompts and / or procedural documentation) that can influence the specification of the trigger predicate. This external information may be provided, for example, as tuning input 121.

[0135] The link drawn from the test requirements library 124 is shown terminating in a circle surrounding another link between the trigger predicate library 122 and the trigger predicate analyzer 126. This indicates that the test requirements library 124 is optionally used to qualify the trigger predicate library 122. For example, the trigger predicate library 122 can be filtered to remove entries that are irrelevant to any of the available test requirements. Additionally or alternatively, the link indicates using the test requirements library 124 itself to provide at least a portion of the contents of the trigger predicate library 122. For example, the test requirements library 124 can define a PATH selector that is useful for dictionary lookups as well as fully specifying at least some of the trigger predicates in the XML context used to build the design hierarchy.

[0136] Optionally, inputs from design hierarchy 120 are supplemented with adjustment inputs 121. These adjustment inputs 121 may comprise manual and / or auxiliary inputs that guide the trigger predicate analysis—inputs that, for whatever reason, are not present in the design hierarchy itself (although they may optionally be).

[0137] The auxiliary input may add predicate detection information to the design hierarchy, for example, relationships between assemblies defined within the design hierarchy that are related but not necessarily emphasized by the design hierarchy itself.

[0138] An example of such a relationship is assemblies that are next to each other but are otherwise not clearly related in the assembly tree annotations, and whose relative positioning can be examined.

[0139] In another example, there may be alternative pairs of parts to be used as components (e.g., edge parts that should be used in matched pairs), and the coordination input can specify this linking information. Such information is preferably specified upfront in the assembly tree itself. However, there can be supply issues where two batches of the same part number only match imperfectly, resulting in on-the-fly manufacturing issues that can be resolved by adjusting procedures, including through inspection requirements.

[0140] In yet another example, there may be intermediate stages of manufacturing where jigs, clamps, scaffolding, tape, or other external parts have been temporarily attached to the product. The presence of such parts may be subject to inspection (e.g., as if they were separate assemblies) or may affect whether some other component is sufficiently exposed and available for inspection. Documentation of this may not be present in the design documentation for the assembly tree. Such information is provided through manufacturing documentation, optionally provided as part of adjustment input 121, or by another method, such as manual adjustment.

[0141] Additionally or alternatively, the adjustment inputs 121 may directly or indirectly reflect factory conditions, such as parts inventory, parts suppliers, tooling status, tool availability, worker skill levels, and / or staffing (e.g., heavy or light shifts). These conditions may affect the interpretation of predicates, for example, by changing assembly sequences. For example, workers performing skilled assembly tasks may only be available on the day shift, resulting in shift-dependent differences in trigger predicates that affect inspection planning. Adjustment inputs may be used to mask certain components or assemblies from the analysis.

[0142] Additionally or alternatively, the tuning input 121 can be used to assist in the detection of the trigger predicate itself. For example, there may be no automatic detection method for a particular trigger predicate, perhaps because it is based on a combination of previously unpredictable conditions. Existing automatic detection methods may attempt to make false positive or negative decisions, which manual provision of tuning input can help avoid and / or resolve. Semi-automatic detection methods are designed to operate with operator assistance and can assist in identifying trigger predicates but not fully implement them. In another example, even if the trigger predicate detection is correct, a human operator may readily know that there is no need to generate the corresponding test requirement (e.g., because the trigger predicate is irrelevant or the test requirement trigger is inherently satisfied by other test requirements).

[0143] The adjustment inputs 121 may additionally or alternatively be applied to the version of the assembly tree provided to the test requirements preparer 128. Furthermore, not all optional application points of the adjustment inputs 121 are shown in Figure 1B. For example, there may be adjustment inputs that are effectively applied to intermediate results and / or outputs of the trigger predicate analyzer 126 and / or the test requirements preparer 128.

[0144] Adjustment inputs 123 optionally correspond to any input described in connection with adjustment inputs 121, but typically exclude those that are specifically due to design details in assembly tree 120. Modifications due to design details are part of the job of inspection requirements preparer 128, which itself has access to assembly tree 120 and the associated adjustment inputs 121. Adjustment inputs 123 may be derived specifically from an inspection policy document and / or a quality policy document, which embodies which inspection requirements from inspection library 124 are considered most relevant to the manufacturing facility's particular products, customers, and / or manufacturing processes.

[0145] 1C, which illustrates an exemplary comparison of open and closed test requirement specifications, according to some embodiments of the present disclosure. In some embodiments of the present disclosure, a typical process flow links trigger predicates 140 to the construction and execution of test plans 143 via test requirements.

[0146] The difference between "open" and "closed" inspection requirements is outlined in the overview.

[0147] Simply put, closed test requirements 142 set out requirements in "low level" terms that associate measurable characteristics with appropriate measurement actions. Values ​​are given so that the output of the measurement can be evaluated to see if it meets a particular requirement. The measurable characteristics themselves may be largely unambiguous as to what counts in meeting the requirement, and in some cases, the measurement actions themselves are not specified. At the conclusion of the test plan, the output (i.e., success) equates to a verdict "the measurement result of the characteristic is within tolerance," as shown in block 145. This directly mirrors the terminology of closed test requirements.

[0148] In general, trigger predicates for closed test requirements are narrowly defined because closed test requirements tend to be less flexible in their creation and application.

[0149] The open test requirements specification 141 is defined to be what the trigger predicate is understood to refer to (a notation), which may be a component or an assembly, and is typically not related to any particular characteristics of the component or assembly.

[0150] Instead of specifying specific actions, open testing requirements specifications tend to be more generally concerned with "concerns," which indicate high-level issues such as: ·Component presence Surface meets decorative specifications · Uniform appearance of components that meet specifications A component satisfies a set of class-specific quality challenges, for example (classes are underlined): · case is closed and properly attached along the seams. · Screw The bolt is tight and the head is not crushed. · Molded Components is perfect (for example, matches the design model shape) and there are no burrs. · connector is straight and matches the background. · label is arranged in a straight line and is easy to read. · Snap Assembly have mating parts correctly positioned relative to one another. · pattern (of the component) is as defined in the template.

[0151] A triggering predicate may imply a concern alone (e.g., a screw component also elicits a screw concern), but the relationship is not necessarily (e.g., a screw can be provided as a loose kit part) and is not generally one-to-one (e.g., "existence" is not necessarily part of the set of tests implied by a screw concern).

[0152] The inspection requirements specification optionally includes annotations that further define its scope and applicability. Typical annotations are subclasses within the class represented by the trigger predicate. For example, a screw can be annotated as an M3 screw and / or a Phillips screw. The annotations are optionally represented directly or indirectly, for example, as characteristics, in a Model-Based Definition (MBD) of the product. The MBD includes a design model of the product, e.g., a 3D geometric model of the product, with other information that may be relevant to defining the product and / or its manufacturing process, such as tolerances, part-level materials, assembly-level part specifications, engineering configurations, and / or design intent. In some embodiments, the MBD includes an assembly tree, which organizes the product's components into a hierarchy of assemblies and subassemblies.

[0153] As an example of an indirect indication, the abbreviated designation of a part (e.g., via a part number) can optionally be interpreted as indicating the characteristics of the part. For example, a part number can include multiple concatenated fields (optionally separated by dashes or other characters). For a particular class of part, the value of each field can further specify a subclass. For example, a screw has multiple characteristics that can be configured in different combinations, such as material, thread pitch, shaft diameter, shaft length, head type, slot / socket type, etc. Thus, in some embodiments, part designations in design documents can be interpreted via part numbering conventions to better identify the part itself.

[0154] Annotations can also modify inspection requirements in other ways, such as based on the hierarchical structure of the manufactured product as represented in an assembly tree specified in Model-Based Definition (MBD). From the assembly tree (e.g., the hierarchical structure and / or assembly geometry derived from a combination of the assembly tree and other MBD data), it can be determined when components and / or assemblies can be inspected, e.g., both when they are present (assembled) and when they are visible (not obscured by later assembly stages).

[0155] The annotations can be derived from information in the design documents, optionally complemented by a "smart" part number scheme. Thus, the annotations are optionally omitted from the inspection requirements themselves, and the task of information extraction is deferred at least until the inspection plan, assuming that the inspection plan itself has access to the design documents.

[0156] However, the extraction of annotation information into requirements creates a noteworthy point. Annotation information can be captured in requirements from any of several sources (e.g., design model, quality policy, manual addition, and / or images) and can be a standard representation that the inspection plan itself can reference directly without needing to access more indirect sources. Note that annotations can be inserted as reference values ​​rather than as direct values ​​themselves. For example, a designation defined by a quality policy could be specified by reference (e.g., "Surface Quality Class B").

[0157] At the conclusion of the test plan, the output (i.e., success) is equivalent to the determination "concerns for the expressed and annotated types are satisfied" as shown in block 144. This relates to the fact that the enumeration of property measures raised by these "concerns" is under the control of the test plan 143 in the case of an open test requirements specification, whereas a closed test requirements specification begins with an enumerated list of property measures.

[0158] Reference is now made to FIG. 2A, which schematically illustrates aspects of a model-based design document, according to some embodiments of the present disclosure.

[0159] Model-Based Enterprise (MBE) is a term used in manufacturing to describe a strategy in which an annotated digital three-dimensional (3D) model of a product serves as the source of truth for all activities in that product's lifecycle. Encoded information specifies, for example, shape, topology, dimensions, tolerances, materials, finishes, and weld callouts. Assembly tree and / or product tree information can also be specified. Together, these constitute the product's Model-Based Definition (MBD). These may be expressed in one of several standard MBD-compatible formats, such as f3D PDF, JT, STEP AP242, and / or ANSI QIF. MBD documents are suitable for use in downstream product lifecycle activities, including manufacturing and quality inspection.

[0160] A manufactured product is composed of a collection of components. A component may itself be a collection (of subassemblies) or may be a part that goes directly into an assembly process. Thus, a typical aspect of product MBD is a hierarchy of components that designates the parts (that become components), and then an ordering of the components to form a combinatorial hierarchy of assemblies, all the way up to the level of the final product (which itself may be considered a final assembly). The assembly tree not only aids in design, but also preferably guides manufacturing planning. In some embodiments of the present disclosure, the assembly tree is also used as a guide for identifying inspection requirements.

[0161] Figure 2A shows the assembly tree for a simple product: a toy car. There are three parts (octagonal boxes) including wheels 322, axles 324, and body 310. In the assembly tree model, these are given identifiers a1, p2, and p3, respectively. Calling an item a "part" is separate from the part's specific use as a product component. However, physically identical things represented as "parts" in the assembly tree may also be called "components" (rectangular boxes) as long as they are used to assemble the product.

[0162] Component names distinguish physically identical parts by being scheduled for different (specific) locations within the product. Components that are simply component-specific parts include body 304, axle 314, left wheel 316, and right wheel 318 (with identifiers c1, c4, c5, and c6, respectively).

[0163] An assembly (rounded box) contains multiple attached components. The final product is a car 302, which is also an assembly with identifier a1. Another assembly is a wheeled axle 312, identified by a2.

[0164] Physical things represented as assemblies may also be represented as components. For example, assembly 312 is also a component, i.e., front wheeled axle 306 and rear wheeled axle 308 (identified as c2 and c3, respectively). Each part is further associated with 3D design information that describes its shape, and assemblies are associated with 3D design information that provides the relative positions of the components. The 3D design information may be maintained as a master document that can be referenced (e.g., from an assembly tree) to show corresponding parts and assemblies.

[0165] Referring to the system of Figure 1B, Figure 2A corresponds to assembly tree 120. Trigger predicate library 122 can specify trigger predicates that identify any of the parts, components, or assemblies of Figure 2A, for example, in one of the ways of Figures 2B-2C or another way (e.g., by operation of trigger predicate analyzer 126). Inspection requirements library 124 optionally includes inspection requirements specific to any of the identified elements of Figure 2A.

[0166] Optionally, the toy car of FIG. 2A is manufactured in a factory that produces many products, e.g., many different toy cars, some of which may have different and / or additional parts. For example, the factory may assemble products that use wheels, bodies, and / or axles with different identifiers, and there may be parts or assemblies with entirely different types. The products may have common characteristics (e.g., many of them also include one body and two axles with wheels), but some or all of their parts and components may differ. The toy car of FIG. 2A may also be manufactured in multiple variations, e.g., with different colors, markings, or auxiliary parts. Optionally, tooling and other resources (e.g., stations, factory workers themselves) are shared among multiple products. Conversely, the same product is optionally manufactured in different ways, e.g., with or without a fixture to align axle 314 with a locking snap in body 304.

[0167] These optional factory conditions provide some example background for the automated identification of inspection requirements, specifically:

[0168] For example, there may be many different types of wheeled axle assemblies, all of which require the same type of testing, but the specifics of that testing depend on the overall design. For example, different products may have different characteristics of wheel spacing at the assembly level, but all require testing. This illustrates the potential benefit of the testing requirements library 124 specifying requirements semantically according to the assembly tree and / or product tree.

[0169] Depending on the product geometry details, it may be preferable to inspect the assembly differently. For example, an axle may need to be inspected for straightness. Some products, such as the one in Figure 2A, may have a bottom section on the body that hides the axle. As a result, the final inspectable stage for this characteristic will differ. In some embodiments, this is determined by inspecting the 3D design data, for example, at each stage of the assembly to determine which stages actually show the assembly.

[0170] It may be preferable to identify defects in more expensive components and / or products with high assembly costs early (e.g., to reduce waste). For other products, it may be preferable to keep inspection costs low (e.g., by concentrating inspection at one final work station). Thus, identifying possible assembly stages for characteristic inspection can provide input to assist in optimizing the inspection plan.

[0171] Depending on the specifics of the manufacturing process, it may be preferable to inspect assemblies differently. For example, an automated assembly process may rely on receiving known-good components to prevent system stalls, while a corresponding manual process remains unaffected. In another example, a bent axle may be determined to be potentially the result of an assembly machine running at a high speed, not at a low speed, although either speed may otherwise be preferable depending on external factors. In both of these scenarios, early or late inspection may be desirable, depending on the type of manufacturing being performed. It is also potentially advantageous to identify a range of possible stages for inspection, allowing the inspection plan to select stages that are appropriate for the current manufacturing conditions.

[0172] Reference is now made to Figure 2B, which schematically illustrates how trigger predicates are identified based on components in a design hierarchy, according to some embodiments of the present disclosure.

[0173] Hierarchy nodes 230 contain specifications (data structures, such as data structures specified in XML) of particular assemblies or other nodes in design hierarchy 120. Trigger parameter specifications 232 include specifications from trigger predicate library 122, for example.

[0174] The purpose of the procedure (e.g., performed by trigger predicate analyzer 126 of FIG. 1B) is to test whether hierarchy node 230 encodes an appropriate trigger predicate as defined by trigger parameter specification 232. In this particular method, trigger parameter specification 232 is of a special type that specifies both the presence of a particular component and a particular "exposure" of the assembly to inspection. This exposure can be specified in different ways, as described with respect to block 212.

[0175] In block 210, in some embodiments, the assembly specification is queried to determine whether it defines (“has”) one or more components mentioned in the trigger parameter specification 232. In simple cases, this involves one or more data searches (such as an XPATH query), where the trigger parameter specification 232 specifies a query string tailored to find components within the (optionally XML-specified) hierarchical nodes 230 that have a particular characteristic, part number, subpart number, keyword, or other string. However, there is no particular restriction on the use of textual data for the search; for example, a particular geometric feature could be specified in the trigger parameter specification 232. Queries can also include other logical relationships between components, such as negated queries (excluding a particular component), inclusive choice queries (including at least one of multiple specific components), and / or exclusive choice queries (including only one of multiple specific components).

[0176] If the component test fails, the flow diagram ends at block 223 and the hierarchy node 230 does not define a property containing a trigger predicate for the given trigger parameter specification 232 .

[0177] If not, the flow diagram continues at block 212, where in some embodiments the assembly level is verified. Different tests and combinations of tests are possible, but here are two representative tests.

[0178] In the simplest case, the test simply verifies that the assembly is a first level that satisfies the component tests of block 210 .

[0179] Additionally or alternatively, the test verifies that certain surfaces, components, or other features are visible, e.g., from the outside of the assembly ("looking at it from a distance"). The surfaces, components, or other features can be selected to suit the features of the component of interest. Since a 3D model of the product is available, this determination can be made using algorithms similar to those already used in 3D rendering displays. For example, this can be done by drawing rays in different directions from the assembly in the rendered space and testing for intersections.

[0180] Testing may optionally be based on other criteria, such as accessibility of electrical test points to a probe, optionally based on simulating the movement of a probe-shaped object near the assembly.

[0181] If the level test is also successful, then generation of a trigger predicate is signaled in block 221. Otherwise, "not a trigger predicate" is signaled in block 223.

[0182] There may be more than one assembly level that contributes to the trigger predicate results, i.e., the trigger parameter specification is optionally designed such that trigger predicates are generated at more than one level of assembly. In some embodiments, this results in test requirements annotated as testable at any valid assembly stage, for example, subject to other test planning considerations.

[0183] Reference is now made to Figure 2C, which illustrates a schematic diagram of a text-based method for identifying trigger predicates within a design hierarchy, according to some embodiments of the present disclosure.

[0184] 2B, hierarchy node 230 includes specifications for a particular assembly selected from design hierarchy 120. Trigger parameter specifications 232 include specifications from trigger predicate library 122, for example.

[0185] The purpose of the procedure (e.g., performed by trigger predicate analyzer 126 of FIG. 1B) is to test whether hierarchy node 230 encodes an appropriate trigger predicate as defined by trigger parameter specification 232. In this particular method, trigger parameter specification 232 is based on a generic text field. This can be based on part / component names (e.g., as specified in FIG. 2A), but additionally or alternatively, it can be based on any other text in the assembly specification: labels, element names, keywords, comments, or others. In particular, hierarchy node 230 can also include labels or keywords applicable to the assembly itself. Thus, instead of being identified based on component content (as in FIG. 2B), assemblies may simply be labeled as belonging to a particular class (e.g., keyboard) or with comments / keywords otherwise related to the inspection process (e.g., all connectors are the same height, all parts are the same color, deburring after assembly).

[0186] In block 234, the text field is analyzed for content matching the trigger parameter specification. Comments / keywords can be identified based on an exact string match or by natural language functions based, for example, on machine learning trained on relevant examples. Optionally, formally specified searches (e.g., XPATH-type searches) are supported for identifying text-encoded elements and / or properties of the hierarchical nodes 230.

[0187] A determination is made at block 236 as to whether there is a match to the trigger parameter specification. If there is a match, the generation of a trigger predicate is signaled at block 237. If there is no match, a "not a trigger predicate" is signaled at block 239.

[0188] Keyboard Example Reference is now made to Figure 3, which schematically illustrates an image 500 of an inspected portion of a keyboard 500A, according to some embodiments of the present disclosure. The image 500 was acquired by an automated visual inspection system.

[0189] The keyboard example provides an example illustrating several different aspects of physical relationships within a hierarchically defined assembly. Physical relationships that are particularly salient targets for inspection may include, for example, boundaries where two components meet and / or are adjacent. Such boundaries are salient for, for example, the following reasons: They are particularly visible and can affect aesthetics if not aligned. They indicate, for example, the quality of the fastening. Irregularities can indicate, for example, a faulty snap closure or a loose screw. They can have a functional impact on product performance, for example, loss of electrical contact or increased stress. The alignment of keycaps 501 on the keyboard may affect any or all of these considerations. For example, misaligned keys look unsightly, may be improperly installed, and may not work properly.

[0190] A keyboard can be used as an example implementation of the flowcharts and systems of FIGS. 1A-1B and 2B-2C.

[0191] Starting with block 110 of Figure 1A, the keyboard trigger predicate may simply be that the appropriate location in the design specification is labeled as a keyboard (e.g., based on the method of Figure 2C). Additionally or alternatively, the presence of keycaps 501 or other "keyboard-specific" components such as a key harness can be used to generate a trigger predicate indicating that a group of "keyboard" test requirements is available (e.g., based on the method of Figure 2B).

[0192] Keyboard assemblies are an example of an assembly class that is common and used in many different real-world implementations. In particular, their dimensions and other characteristics (such as key layout) are significantly variable. However, they have enough common attributes that a specialized set of inspection requirements tailored to keyboards would be of potential value to, for example, a factory that assembles various keyboard styles.

[0193] The test requirements library 124 may optionally include a group of test requirements that are triggered by one or another type of keyboard trigger predicate. As adapted to keyboard requirements, this group optionally includes requirements for one or more of the following tests: Defective printing on keycap 501 501 keycaps not in order Keycap 501 missing 501 keycaps present but misaligned

[0194] In particular, if the semantically specified test requirements are accepted by the downstream inspection planning process, the operator may need little further specification, at least at the requirements stage. For example, in some embodiments, there may be downstream inspection agents (computerized modules) of a "smart" inspection system that are pre-configured to meet each of the first three requirements by methods that include: Find and take a picture of the keyboard consisting of the "golden part" (exposed as part of the test setup) where the keyboard inspection request exists Identify the image's key and its location Use the key layout in that image as a template for key identification Use the printing on the keys in that image as a reference for later testing on the keyboard

[0195] This directly identifies incorrect printing and, as a by-product, identifies missing / out-of-sequence keycaps 501. Recognizing the synergy between these three tests, effectively housed within a quality system, highlights some of the value of a semantic inspection requirements system.

[0196] For purposes of illustration, it should be noted that the first inspection requirement is specifically directed to individual components, which may be inspected at a lower assembly level, assuming that the test results have no apparent mutual uniqueness or can be ignored for some reason.

[0197] For example, the method of Figure 2B could be used to generate keycap-specific testing requirements (e.g., triggered by a component having a keycap-type part number) that could be annotated as suitable for execution at multiple hierarchical levels, such as at the level of the raw keycap component itself or once it is part of a keyboard assembly.

[0198] The automated inspection planner then has the option to recognize synergies with other keyboard tests, such as the number of images that need to be acquired and / or the number of inspection stations required, and therefore a more complete assembly stage may be selected as desirable for this inspection requirement.

[0199] Regarding the fourth requirement, in some embodiments, there may be a separate "smart" downstream testing agent pre-configured to generate an optimal test plan for validating keycap spacing. A brute force approach (e.g., without any semantic knowledge that this is actually a "keyboard") could involve identifying each keycap edge one by one and verifying that it corresponds to the edge in the design document. This can lead to problems, for example, when the top and bottom edges of the keys are confused, camera distortion is captured inaccurately, or performance issues arise when trying to test everything.

[0200] The smart inspection agent can optionally test differently and in a way that is tailored to its particular problem, for example by specifically excluding the edges of the keycaps below the body as irrelevant and / or by generating test lines along the rows of keys, thereby quickly detecting unevenness (e.g., due to misplaced keys) while ignoring global distortion due to lens artifacts.

[0201] The inspection agent may be configured to receive a few basic parameters, such as the distance between the edges of the keycaps 514, 516 and the distance between the centers 515, 513, which are optionally extracted as annotations into the inspection requirements themselves (e.g., by inspection requirements preparer 128) or optionally extracted from the design hierarchy 120 by the inspection agent itself.

[0202] Some keycaps 501 are of different distances / shapes. If for some reason the keyboard testing agent itself is not configured to handle that, test requirement annotations are optionally available that divide the keyboard into uniform parts. Optionally, "closed" test requirements are generated for the few keys that do not fit into the available general rules.

[0203] Example Case Reference is now made to Figure 4, which schematically illustrates an image 600 of a portion of a computer casing 601, according to some embodiments of the present disclosure. Image 600 illustrates an image acquired by an automated visual inspection system.

[0204] In this example, the trigger predicate may be a label (i.e., text in the design document) that indicates that the upper part 602 and the lower part 603 together constitute a casing. The casing label then becomes the trigger predicate for the set of requirements (from the test requirements library 124) that pertain to the casing.

[0205] In the keyboard example of Figure 3, we have assumed for the sake of argument that there is a globally aware keyboard agent and possibly a keycap agent that embodies deep search knowledge about the keyboard.

[0206] In this example, we assume that there is no general-purpose casing agent that drives the execution of the inspection. Instead, inspection requirements are configured internally to specify appropriate tests that are drawn from a pool of more general tests (but still specified semantically in this example). For example, there may be a surface inspection agent, a color check inspection agent, and a void inspection agent.

[0207] In some embodiments, the requirements met by the test group include the following characteristics of the casing: Outer surface inspection Inspection of surface appearance uniformity between components (e.g. to avoid misalignment of casing assemblies) Inter-component void inspection (e.g., for voids 604 specified in the design document to be of width 605 with some associated tolerance)

[0208] Each of these three is optionally generated as a separate test requirement, for example as follows:

[0209] From the assembly that generated the trigger predicate casing, all components with an exterior surface may be selected. This may be based on geometry, component name (panel, cover, etc.), or another criterion. For each of these components, a "surface inspection" requirement is assigned (at least for the exterior surface). The requirement may be annotated to have a specific surface defect tolerance (e.g., including a maximum scratch length, a maximum average change in surface reflectance along the scratch, and / or other criteria appropriate for the surface inspection agent).

[0210] The same selected components (and surfaces) may also be flagged to require "same color" to be performed by a color check inspection agent, which may be configured to verify color uniformity among multiple components, and optionally includes control of, for example, lighting angle, intensity, surface angle of imaging, etc.

[0211] Optionally, the void (i.e., as an inspection target) is geometrically identified as a location (by design specification) along the exterior surface where two components of the casing (e.g., identified as described above) extend over a distance (e.g., at least 2 mm) within a threshold distance of each other, optionally adjusted as needed for designed recesses, overlaps, etc.

[0212] For all such void regions, inspection requirements are generated (e.g., by operation of inspection requirement preparer 128), such as inspection requirements specifying void extension to target, minimum target width, maximum target width, parallelism, similarity to a reference void (measured from a "perfect part"), and / or other specified criteria.

[0213] The numerical annotations (parameters) are optionally obtained from the design document itself, or in some embodiments the parameters are derived by the air gap inspection device from an image of the complete part.

[0214] Inspection requirement annotation example Below is an example of a test requirements specification (in XML) that was optionally generated for an assembly (PartSet element) containing four components specified as Part elements: a Block and three screws labeled m3, m4, and m5. <partset n="4"> <part id="4" label="Block"> <attributes n="3"> <inspection name="class" value="surface" / > <inspection name="sub_class" value="class-b" / > <inspection name="inspection" value="surface" / > < / attributes> <bodyids n="1"> <id> 5< / id> < / bodyids> < / part> <part id="478" label="m3"> <attributes n="3"> <inspection name="class" value="screw" / > <inspection name="sub_class" value="M3" / > <inspection name="inspection" value="screw,existence,surface" / > < / attributes> <bodyids n="1"> <id> 479< / id> < / bodyids> < / part> <part id="727" label="m4"> <attributes n="3"> <inspection name="class" value="screw" / > <inspection name="sub_class" value="M4" / > <inspection name="inspection" value="screw,existence,surface" / > < / attributes> <bodyids n="1"> <id> 728< / id> < / bodyids> < / part> <part id="1206" label="m5"> <attributes n="3"> <inspection name="class" value="screw" / > <inspection name="sub_class" value="M5" / > <inspection name="inspection" value="screw,existence,surface" / > < / attributes> <bodyids n="1"> <id> 1207< / id> < / bodyids> < / part> < / partset>

[0215] For example, additional elements for the geometry of various components are suppressed. XML is potentially suitable for adding as an extension to MBD files, for example in QIF format. Once inserted into the MBD file, the test requirements can be propagated to any other design / manufacturing process, for example, to influence later design revisions and / or manufacturing station configurations. The test requirements also have a primary role in inputting the inspection plan that meets the test requirements into the design process.

[0216] In this example, an Inspection element is added to the Attributes element of each corresponding Part element, which is one way of linking inspection requirements (specified semantically in this example) to the design documentation.

[0217] The value of an Inspection element with a property definition name="class" corresponds to the representation of the component (eg, has a value property defined as surface or screw).

[0218] The values ​​of Inspection elements with property definition name="sub_class" correspond to annotations of components (e.g., with a value property defined as class-b, M3, M4, or M5). For these subclasses, it is assumed that there are additional elements (e.g., implementable in downstream automated inspection agents) that describe the content of these subclasses. Optionally, details are provided as individual parameters and / or subelements of the Inspection element, rather than by reference as above.

[0219] The value property of an Inspection element with name="inspection" is defined corresponding to an inspection concern of the component (e.g., surface, screw, or existence), and optionally references a specific downstream automated inspection agent that is specifically configured to plan and / or perform inspections for the given inspection concern.

[0220] (General rules) The term "about" as used herein in connection with an amount or value means "within ±10%."

[0221] The terms "comprises," "comprising," "includes," "including," "having," and their conjugations mean "including but not limited to."

[0222] The term "consisting of" means "including and limited to."

[0223] The term "consisting essentially of" means that a composition, method, or structure may include additional components, steps, and / or portions, but only if the additional components, steps, and / or portions do not materially alter the basic and novel characteristics of the claimed composition, method, or structure.

[0224] As used herein, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" can include multiple compounds, including mixtures thereof.

[0225] The words "example" and "exemplary" are used herein to mean "serving as an example, instance, or illustration." Any embodiment described as "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments, or as excluding the incorporation of features of other embodiments, or both.

[0226] The term "optionally" is used herein to mean "provided in some embodiments and not provided in other embodiments." Any particular embodiment of the present disclosure may include multiple "optional" features unless such features contradict each other.

[0227] As used herein, the term "method" refers to ways, means, techniques, and procedures for accomplishing a given task, including, but not limited to, such ways, means, techniques, and procedures that are known to or readily developed by those skilled in the art of chemistry, pharmacology, biology, biochemistry, and medicine from known ways, means, techniques, and procedures.

[0228] As used herein, the term "treating" includes negating, substantially inhibiting, slowing or reversing the progression of a condition, substantially ameliorating the clinical or cosmetic symptoms of a condition, or substantially preventing the appearance of clinical or cosmetic symptoms of a condition.

[0229] Throughout this application, embodiments may be presented with reference to a range format. It should be understood that the description in range format is merely for convenience and simplicity and should not be construed as a fixed limitation on the scope of the description of the present disclosure. Accordingly, descriptions of ranges should be considered to specifically disclose all possible subranges along with individual numerical values ​​within that range. For example, a description of a range such as "1 to 6" should be considered to have specifically disclosed subranges such as "1 to 3," "1 to 4," "1 to 5," "2 to 4," "2 to 6," "3 to 6," etc., along with individual numerical values ​​within that range, e.g., 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range.

[0230] Whenever a numerical range is given herein (e.g., "10-15," "10 to 15," or any pair of numbers joined by another such range indicator), it is meant to include any number (fractional or integer) within the limits of the stated range, inclusive of the limits of that range, unless the context clearly dictates otherwise. The phrases "ranging between / across / between" a first specified number and a second specified number, and the phrases "from" a first specified number to a second specified number, "up to," "until," "through" and "including" a second specified number, are used interchangeably herein and mean to include the first specified number and the second specified number, and all fractional and integer numbers therebetween.

[0231] While the description of this disclosure has been provided in conjunction with specific embodiments, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, the description of the disclosure is intended to embrace all such alternatives, modifications, and variations that fall within the spirit and broad scope of the appended claims.

[0232] All publications, patents, and patent applications mentioned in this specification are herein incorporated by reference in their entirety to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference. Furthermore, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present disclosure. To the extent used as section headings, they should not be construed as necessarily limiting. Additionally, any priority documents of this application are herein incorporated by reference in their entirety.

[0233] It is understood that certain features, which for clarity are described in this disclosure in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention that are for brevity described in the context of a single embodiment may also be provided separately or in any suitable subcombination, or as appropriate with any other described embodiment of this disclosure. Certain features described in the context of various embodiments are not considered essential features of those embodiments, unless the embodiment is inoperable without those elements.

Claims

1. 1. A method for defining visual inspection requirements for a product, comprising: accessing a model-based definition (MBD) including a design model of the product; Identifying inspection requirements for components of the product based on an automated analysis of component relationships specified by the MBD; encoding the identified inspection requirements for use in machine planning of visual inspection of the product. Including, the MBD specifies hierarchical relationships between components specified in the design model, and the identified inspection requirements are based on an automated analysis that identifies specific hierarchical relationships between components specified in the MBD; the hierarchical relationships between the components correspond to the relationships between the assemblies of the product. method.

2. The method of claim 1 , wherein the identification of inspection requirements is based on an automated analysis that identifies geometric relationships between components specified in the MBD.

3. The method of claim 1 , wherein the identification of inspection requirements is based on an automated analysis that identifies patterns of component characteristics specified in the MBD.

4. automatically generating a visual inspection plan that meets the inspection requirements; executing the visual inspection plan on at least one instance of the product; The method of claim 1 , comprising:

5. 5. The method of claim 4, wherein the inspection requirements include open inspection requirements that specify quality concerns regarding the inspection of one or more components specified by the MBD without specifying characteristics or behaviors that correspond to the quality concerns.

6. The method of claim 5 , wherein the open testing requirements are semantic requirements.

7. 7. The method of claim 5 or claim 6, wherein generating the visual inspection plan includes automatically converting the open inspection requirements into corresponding closed inspection requirements that specify characteristics of the component and measurement operations for those characteristics.

8. The method of claim 7 , wherein the transformation uses the MBD.

9. 9. The method of claim 7 or claim 8, wherein generating the visual inspection plan includes using a hierarchical relationship specified by the MBD to determine the stage at which to perform operations to satisfy the inspection requirements.

10. The method of any one of claims 7 to 9, wherein generating the visual inspection plan includes using geometric information specified by the MBD to determine at what stage operations should be performed to satisfy the inspection requirements.

11. The method of claim 8 , wherein an automatic process determines what information to extract from the MBD for the conversion based on the open inspection requirements.

12. The method of claim 5 or claim 6, wherein the inspection requirements include only open inspection requirements.

13. The method according to any one of claims 4 to 6, wherein the inspection requirements include closed inspection requirements that specify characteristics and measurement operations for measuring the characteristics when the visual inspection plan is executed.

14. The method of any one of claims 1 to 13, wherein said encoding comprises inserting a test specification data element into said MBD.

15. 15. The method of claim 14, wherein the MBD is specified as one or more QIF files, and the study specification data elements are defined using references to elements of the one or more QIF files.

16. The method of claim 15 , wherein the test specification data elements are defined as XML.

17. The method of claim 14 , further comprising adjusting a design specification in the MBD based on the inserted test specification data element.

18. The method of any one of claims 14 to 17, comprising adjusting a manufacturing plan based on the inserted test specification data element.

19. 19. The method of claim 1, wherein the identifying comprises selecting test requirements from a predefined library of test requirements based on an analysis of hierarchical relationships specified between components defined in the MBD.

20. 20. The method of claim 19, wherein analyzing the hierarchy of the MBD includes identifying predicate triggers that are selection conditions for the selected test requirements.

21. 21. The method of claim 20, wherein identifying the descriptive trigger comprises identifying an assembly that includes a predetermined component configuration.

22. 22. The method of claim 20 or claim 21, wherein identifying the predicate trigger comprises determining the visibility of a component within an assembly.

23. The method of any one of claims 20 to 22, wherein identifying the predicate trigger comprises determining the accessibility of a component within the assembly.

24. The method of any one of claims 20 to 23, wherein identifying predicate triggers comprises analyzing textual content within a design hierarchy specification specified by the MBD.

25. A method according to any one of claims 20 to 24, wherein adjustment inputs modify the identification of pre-descriptive triggers to vary said identification.

26. The method of claim 25 , wherein the adjustment input comprises a manual input.

27. 26. The method of claim 25, wherein the tuning input comprises data encoding a testing strategy.

28. 26. The method of claim 25, wherein the adjustment inputs include data describing factory conditions related to one or more of parts inventory, parts sources, tooling conditions, tooling availability, worker training conditions, and labor allocation.

29. A method according to any one of claims 19 to 24, comprising modifying said selection in accordance with an adjustment input.

30. 30. The method of claim 29, wherein the modification includes adding, deleting, or modifying specific inspection requirements.

31. 31. The method of claim 29 or claim 30, wherein the adjustment input comprises a manual input.

32. The method of any one of claims 29 to 31, wherein the tuning input comprises data encoding a testing strategy.

33. The method of any one of claims 29 to 32, wherein the adjustment input describes factory conditions related to one or more of parts inventory, parts sources, tool conditions, tool availability, worker training conditions, and labor allocation.

34. 20. The method of claim 19, wherein the identifying includes preparing the selected inspection requirements through additional processing.

35. The method of any one of claims 1 to 34, wherein the MBD comprises one or more QIF files.

36. The method of claim 1 , wherein the inspection requirement is an open inspection requirement that is selected based on identifying a trigger predicate in the MBD that indicates that an assembly belongs to a class for which a semantic inspection agent is available.

37. 1. A system for defining visual inspection requirements for a product, comprising: The system comprises a computer processor and a memory; the computer processor is configured to access instructions in the memory; The instructions direct the computer processor to: accessing a model-based definition (MBD) from the memory, the model-based definition including a design model of the product; Identifying inspection requirements for components of the product based on an automated analysis of component relationships specified by the MBD; Encoding the identified inspection requirements for use in machine planning of visual inspection of the product. Instruct them to The MBD specifies a hierarchical relationship of components specified in the design model; the computer processor identifies testing requirements by identifying specific hierarchical relationships between components specified in the MBD; the hierarchical relationships between the components correspond to the relationships between the assemblies of the product. system.

38. 38. The system of claim 37, wherein the MBD includes one or more QIF files.

39. 39. The system of claim 37 or claim 38, wherein the identified testing requirements are encoded as an XML file.

Images