Patent Description:
AI algorithms are typically trained on a large amount on data with the objective of generalizing to multiple use cases. For example, an AI -based object detection algorithm for detecting a car in an image may be trained with a large amount of data pertaining to different type of cars produced by different car makers, with the goal that the trained model is useable in many general use cases. Likewise, an AI-based algorithm used for product inspection may be trained to target a wide range of products and features. Often, the training and tuning of such AI algorithms is an iterative process, which is time consuming, involving multiple resources, in terms of personnel, software and hardware. Further prior art can be found in <CIT>, in <CIT>, and in <CIT>. <CIT> discloses a computer-implemented method of performing machine vision prediction of digital images using synthetically generated training assets. <CIT> discloses a method of neural network object recognition for image processing includes customizing a training database and adapting an instance segmentation neural network used to perform the customization. <CIT> discloses an AI server which deploys an AI inspection algorithm on a field device in a production line.

Briefly, aspects of the present disclosure are concerned with the commissioning and deployment of an AI-based inspection system in the field, with a focus on shortening the workflow / process cycle to provide instant feedbacks to re-train and tune the AI algorithm to achieve the optimal performance for a specific use case.

According to a first aspect of the disclosure, a method is provided for commissioning an AI-based inspection system. The method comprises (i) receiving, by a commissioning computer, sensor data captured by a sensor, the sensor positioned within a physical environment to capture sensor data pertaining to individual items in a sequence of similar items, (ii) collecting, by the commissioning computer, a plurality of data samples, wherein collecting each data sample comprises providing an operator interface for a field operator to access sensor data pertaining to individual items and thereto assign classification labels, the collected data samples corresponding to a fixed setting of the sensor, (iii) training, by the commissioning computer, an AI algorithm using the collected data samples to configure the AI algorithm to predict classification labels from input sensor data, and (iv) testing, by the commissioning computer, the trained AI algorithm by feeding the trained AI algorithm with real-time sensor data captured by the sensor positioned within said physical environment with said fixed setting. Steps (ii) through (iv) are performed iteratively using different fixed settings of the sensor, to determine a final setting of the sensor for which a defined success criterion is achieved during the testing. The method further comprises (v) deploying the iteratively trained and tested AI algorithm to a field device, the field device being coupled to the sensor configured with the final setting to provide sensor data as input to the deployed AI algorithm.

Other aspects of the present disclosure implement features of the above-described methods in a computer program product and a computing apparatus.

Additional technical features and benefits may be realized through the techniques of the present disclosure. Embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed subject matter.

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

Various technologies that pertain to systems and methods will now be described with reference to the drawings, where like reference numerals represent like elements throughout. The drawings discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged apparatus. It is to be understood that functionality that is described as being carried out by certain system elements may be performed by multiple elements. Similarly, for instance, an element may be configured to perform functionality that is described as being carried out by multiple elements. The numerous innovative teachings of the present application will be described with reference to exemplary non-limiting embodiments.

It is recognized that many artificial intelligence (AI) algorithms are not directly usable out-of-the-box and must be re-trained and tuned for particular use cases using the data from the actual case. For example, an AI algorithm can include a neural network-based object detection method that uses a camera to visually detect and locate defects on products on a production or assembly line. Typically, the algorithm will begin with a pre-trained neural network. The subsequent re-training process may involve collecting images of specific product or products and labelling identified defects on the images, and then providing those images with labels as training data to re-train the neural network. The re-trained neural network is then tested on a testing dataset. Based on the results obtained from testing (e.g., success or quality of inferences), the training or data collection process is tuned to improve the performance until the testing results satisfy a defined requirement. After successful re-training and testing, the AI algorithm is deployed for operation in the field.

<FIG> illustrates an example of a known process <NUM> for deployment of an AI system in the field. The described process <NUM> includes: data collection by field engineers (block <NUM>), including data collected from multiple use cases (e.g., multiple fields, multiple machines, etc.); data labeling by domain experts (block <NUM>); data management by data engineers (block <NUM>), which includes, for example, transfer of data to a cloud; training an AI algorithm, such as a neural network, by data scientist (block <NUM>), which is often carried out in a cloud computing environment; and deployment of the AI algorithm back to the field (block <NUM>) to get feedback from field engineers (block <NUM>). Based on the feedback (block <NUM>), multiple iterations of re-training may be carried out until the AI algorithm is ready to be deployed in the field.

The above-described process provides a systematic approach targeting a wide range of use cases, with clearly defined roles and responsibilities. The underlying thinking here is that each role has its specialty and can hence fully the contribute to achieve the best results. For example, it is convenient to store the data and train the neural network in a cloud, as the cloud can hold vast amount of data and provides large computational resources.

However, in many applications, the above-described process may pose practical challenges. First, the process involves a long iteration loop across multiple (sometimes disconnected) modules. In a typical deployment use case, many iterations may be necessary over this long loop to deliver a usable solution. In that case, the above-described process may significantly increase the time and cost. Next, the above-described process does not provide instant feedback on test results. Preferrably, the field engineer would like to use the results right on the spot, to determine how to tune the sensors and how to re-collect the label data. In the above-described process, the field engineer may have to wait for the entire loop to complete to determine the next step, which makes the task infeasible to complete. Furthermore, if there is any difference in setup for each step, this can lead to challenges in obtaining successful inferences from the AI algorithm. For example, if the data used to train the AI algorithm has been converted to another format in the cloud with some loss of infomatinon, this may cause some differences with the actual data obtained from the sensor, causing the AI algorithm to fail. Other potential hurdles include cross-organization data privacy and sharing, cyber security, among others.

Overall, the long loop in the above-described process increases the cost, lacks instant feedback, and can cause differences in data, all of which can lead to a sub-optimal setup for deploying AI algorithms in the field. Addressing this sub-optimal setup while still delivering good results is a challenging research topic. For example, there is ongoing research focusing on how to train an AI algorithm or model on one type of data and ensure that it can be generalized to other types of data. However, as of the present, those approaches still have a low level of readiness to be practically implemented.

Embodiments of the present disclosure are concerned with a technique for commissioning an AI-based inspection system in the field, with a focus on shortening the process cycle by providing on-the-spot feedbacks to tune and re-train an AI algorithm, and with a goal of achieving an optimal performance for a specific use case. In one aspect, the proposed solution may be embodied in a software suite comprising a tool for field engineers to handle the entire AI pipeline including data collection, training, testing and tuning in a single commissioning device (computer). In embodiments, the commissioning device may be located onsite, providing an "on premise" solution for implementing the AI pipeline. This is particularly useful in many cases where, due to restrictions on communication or data sharing, it may not be possible for a field engineer to have access to the Internet or other external networks during the deployment or to share the data outside the facility.

The proposed solution is based on the recognition that in some real-world applications, especially in the manufacturing domain, many of the machine learning inspection tasks are repetitive, on the same type of product, and carried out in a controlled environment. For example, in a production or assembly line, the "good" products are all nearly identical, the "defects" are also same or similar, the products are positioned in the same orientation or pose on the product line, the inspection station on the same product-line has nearly the same controlled lighting condition at all times, etc. In the traditional approach (shown in <FIG>), the training process for an AI model typically tries to generalize, for example, to avoid overfitting. This requires a large amount of data and may further necessitate data augmentation and other training techniques. The goal of the training process is that the AI model, once trained, can be used in many general cases, not just the cases close to the training scenario. However, for one or more of the reasons noted above, in a repetitive inspection task, especially in the manufacturing domain, it may not be necessary to generalize the model training process beyond the specific use case in which the AI model is intended to be deployed. As a consequence, the size of the training dataset may be greatly reduced and the process cycle for deployment may be significantly shortened. The proposed solution leverages the above finding by using a "single box" commissioning device to train an AI model at the same site, and with the same environmental and sensor settings, as where the AI model is tested and finally deployed, to deliver a successful AI solution meeting the constraints of cost and time.

<FIG> illustrates a methodology for commissioning and deployment of an AI-based inspection system in the field, according to an example embodiment. As mentioned, the methodology is implemented via a commissioning computer, which is represented schematically in <FIG> by the dashed box <NUM>. The commissioning computer may comprise a PC (desktop, a laptop) or any other computing device having at least one processor and a memory storing instructions that, when executed by the processor, cause the computing device to execute an AI pipeline. For illustration, the functional blocks of the described AI pipeline that are executed via the commissioning computer are located within the dashed box <NUM>.

While the described embodiment illustrates a particular application of the proposed solution, namely, fault detection and classification in a production/assembly line, the general teachings of this disclosure can be extended to other factory tasks, such as identifying presence or location of objects, detecting physical properties of objects, among others.

During the commissioning and deployment phase, the commissioning computer <NUM> may be located within the premises of an industrial facility where the AI-based inspection system is to be deployed. The industrial facility may comprise a production facility including a physical environment <NUM> within which a sensor <NUM> is positioned to capture sensor data pertaining to individual items in a sequence of similar items to be inspected. In embodiments, the physical environment <NUM> may comprise a production line or an assembly line. The term "similar items" refers to items having the same design but with the potential of having defects or faults, for example, resulting from the production or assembly process.

The sensor <NUM> is connected to a field device <NUM> where a deployed AI algorithm is to be executed. The field device <NUM> may comprise a field controller, such as a programmable logic controller, an industrial PC, an industrial edge computer, among others. In one embodiment, the field device <NUM> may comprise one or more neural processing unit (NPU) modules. An NPU comprises dedicated edge AI hardware which may be custom designed to run a neural network in a computationally efficient fashion.

For the training and testing process, the commissioning computer <NUM> uses sensor data from the same sensor <NUM> that would feed the field device <NUM> during actual operation.

Inspection tasks the production/assembly line (such as detection of faults or defects) may carried out based on visible features, acoustic anomalies or changes in vibration characteristics. In the described example, the sensor <NUM> includes a vision camera (e.g., a gigabyte ethernet camera) mounted at a preferred location on the production/assembly line, and configured to transmit a video stream to the commissioning computer <NUM> (during commissioning) and to the field device <NUM> (after deployment). In other embodiments, the sensor <NUM> may include an acoustic sensor, such as a microphone, configured to transmit an audio stream to the commissioning computer <NUM> (during commissioning) and to the field device <NUM> (after deployment). In still other embodiments, the sensor <NUM> may comprise a vibration sensor, such as a piezoelectric sensor. In further embodiments, multiple sensors of the same or different types may be used. In one example, the sensor <NUM> may be configured to support multicast streaming of the sensor data to the commissioning computer <NUM> and the field device <NUM>. Alternately, after commissioning and deployment, a sensor cable may be disconnected from the commissioning computer <NUM> and plugged into the field device <NUM>.

Broadly, the AI pipeline solution executed via the commissioning computer <NUM> comprises iteratively performing the steps of: data collection (including data labeling) based on sensor data captured by the sensor <NUM> positioned within the physical environment <NUM> where inspection is to be carried out, training an AI model (algorithm) using the collected data samples, optionally converting the AI model to a format supported by the field device <NUM>, testing the trained (and, if applicable, converted) AI model by feeding it with real-time sensor data captured by the sensor <NUM> positioned within the same physical environment <NUM>, and re-training the AI model based on the results of testing. Each iteration or loop is carried out using a different fixed setting of the sensor <NUM>. That is, the setting of the sensor <NUM> is unchanged during the execution of a single iteration or loop. The iterative process is used to determine a final fixed setting of the sensor <NUM> for which a defined success criterion is achieved during testing. Each fixed setting of the sensor <NUM> may be defined by a combination of internal sensor settings and/or arrangements of the sensor <NUM> in relation to the physical environment <NUM>. After successful training and testing, the AI model is deployed to the field device <NUM>. After this point, the field device <NUM> is coupled to the sensor <NUM> configured with the final fixed setting to provide sensor data as input to the deployed AI model, for example for carrying out product inspection/ fault classification.

The data collection step involves collecting a plurality of data samples by providing an operator interface for a field operator (e.g., a field engineer) to access sensor data pertaining to individual items in the production/assembly line and thereto assign classification labels. The collected data samples correspond to a fixed setting of the sensor <NUM>.

Still referring to <FIG>, in the described embodiment, the operator interface of the commissioning computer <NUM> comprises a sensor data viewer <NUM> that displays live sensor data to the field operator. In the present example, the sensor data viewer <NUM> may include a camera viewer displaying a live video stream representing a dynamic physical environment where inspection is to be carried out (e.g., a sequence of items moving along a production/assembly line). Based on the live sensor data, a field operator may evaluate images pertaining to individual items and carry out sensor setting adjustments <NUM>, so that the collected sensor data is satisfactory in terms of quality and relevance. In the present embodiment, the sensor <NUM> includes a vision camera. In this case, the settings of the camera <NUM> that may be adjusted include the internal settings of the camera <NUM>, such as focus (lens), brightness, contrast, saturation, shutter speed, ISO, aperture, etc., and/or the arrangement of the camera <NUM> in relation to the physical environment <NUM>, such as lighting, camera placement, angle of view (mounting brackets and angles), etc. These settings may be tuned for the particular item on the particular production/assembly line, so that the collected images may reveal the most relevant features in the same physical environment. In another embodiment, where the sensor <NUM> includes a microphone, the settings of the microphone that may be adjusted may include internal settings of the microphone, such as gain, sampling rate, frequency filters, etc., and/or the arrangement of the microphone in relation to the physical environment, such as mounting location and direction where the microphone points to. After a satisfactory sensor setting adjustment <NUM> has been determined by the field operator, the settings of the sensor <NUM> are maintained unchanged throughout a particular cycle of the data collection, training and testing processes.

The operator interface of the commissioning computer <NUM> may further include a data labeling user interface (UI) <NUM> to provide live sensor data to field operators for them to label the data after the sensor setting has been fixed. In the described embodiment, the data labeling UI <NUM> may comprise a frame grabber for capturing a still image from the live video stream. For labeling the captured image, the data labeling UI <NUM> may enable the field operator to localize an identified fault or defect by drawing a bounding box around a region of interest in the captured image. The field operator may use domain expertise to assign a fault classification label to the captured image of an item. Fault classification labels may be binary (e.g., good versus faulty) or include multiple labels (e.g., Class <NUM> - indicating that the item is good or defect-free; Class <NUM> - indicating improper alignment of sub-part A and sub-part B; Class <NUM> - indicating incomplete insertion of sub-part C into sub-part D; etc.). The data labeling UI <NUM> may enable the field operator to enter the label associated with a captured image in a standard format, such as text, html, etc. Each captured image with its bounding box and corresponding label is saved as one labeled data sample <NUM>. In examples, a labeled data sample <NUM> may have one or more labels associated with one or more bounding boxes in the captured image. As mentioned, the training of an AI model on a specific use case involving repetitive inspection of similar items in a controlled environment requires significantly reduced number of data samples. For example, a few hundred data samples may be sufficient as long they cover most of the lighting variations in the factory, which is minimal in an indoor environment. Accordingly, the labeled data samples <NUM> obtained by the data collection process may be stored directly in a local storage medium of the commissioning computer <NUM>, obviating the need to transfer data outside of the facility (i.e., no cloud connections are needed).

Once a sufficiently large number of labeled data samples <NUM> have been collected, the commissioning computer <NUM> provides the field operator the option to train an AI model, typically a neural network, via a training pipeline <NUM>. In the commissioning phase, a pre-trained AI model is used, wherein the iterative training and testing via the commissioning computer <NUM> is carried out to tune the pre-trained AI model to the particular sensor <NUM> and the particular physical environment <NUM>. The result of the training process is a trained AI model <NUM> configured to predict classification labels from input sensor data from the sensor <NUM>. The commissioning computer <NUM> may provide a training monitoring interface, allowing the operator to monitor the training process and determine when to stop the training process. The training process may be stopped, for example, when a total loss function drops below a defined threshold. In embodiments, the commissioning computer <NUM> may be equipped with sufficient computational resources, such as one or more graphics processing units (GPU), for training the neural network efficiently. In an exemplary assembly line use case, it may take a state-of-the-art GPU about <NUM>-<NUM> hours to train a neural network (e.g., Tiny-YOLO) using about <NUM>-<NUM> labeled data samples with reasonable accuracy to detect product defects.

In some embodiments, the trained AI model may be converted (block <NUM>) to a format compatible with the field device <NUM> prior to testing. For example, if the field device <NUM> comprises a NPU chip, then the trained AI model may be converted into a supported NPU format (e.g., a NPU chip manufactured by Intel™ is compatible with OpenVino™ framework). Model conversion improves the reliability of the model testing by ensuring that the AI model is tested using the commissioning computer <NUM> in the exact format that it is subsequently executed by the field device <NUM>.

The trained (and converted) AI model may be tested (block <NUM>) by launching the inference engine of the AI model on the commissioning computer <NUM> and feeding the AI model with real-time sensor data captured by the sensor <NUM> positioned within the same physical environment <NUM> and with the same fixed setting as during data collection. A test result is said to be satisfactory if an inference (e.g., predicted bounding box with classification label) produced by the AI model to an input image agrees with the field operator/domain expert. One or more success criteria may be defined to determine if re-training of the AI model is necessary. Examples of success criteria may include, for example, success rate (percentage of correct inferences), confidence levels of the inferences, etc. The test results may be monitored for a predetermined number of samples (e.g., <NUM>-<NUM> samples) to make a determination on whether re-training is necessary. If the defined success criteria are not met, a subsequent iteration of data collection, training and testing is carried out with a different sensor setting as explained in connection with block <NUM>. Additionally, the re-training process may include modifying the data labeling method, for example, how the bounding boxes are drawn on the images to label the data samples. After iteratively re-training the AI model, a final fixed setting of the sensor <NUM> is determined which produces satisfactory test results based on the defined success criteria. The instant and on-the-spot feedbacks enables the field operator to re-train and tune the AI model within a very short time (e.g., on the same day) to provide a usable solution.

Once the test results are satisfactory (i.e., meet the success criteria), the AI model is deployed to the field device <NUM>. At this point, the commissioning computer <NUM> can be disconnected from the setup. After deployment, the configuration of the sensor <NUM> is maintained at the final setting determined during the commissioning phase. The trained AI model is intended to be deployed in the same physical environment with the same environmental setting (e.g., lighting) as in the commissioning phase. For deployment to a different production line (e.g., with different lighting), the commissioning computer <NUM> may be used to train another AI model for that specific environment. Given that it is possible retrain and redeploy the model quickly, this is still a more efficient solution than going via the long loop illustrated in <FIG>.

<FIG> illustrates an exemplary computing environment comprising a computing system <NUM>, within which aspects of the present disclosure may be implemented. The computing system <NUM> may be used, for example, to realize the commissioning computer <NUM>. Computers and computing environments, such as computing system <NUM> and computing environment <NUM>, are known to those of skill in the art and thus are described briefly here.

As shown in <FIG>, the computing system <NUM> may include a communication mechanism such as a system bus <NUM> or other communication mechanism for communicating information within the computing system <NUM>. The computing system <NUM> further includes one or more processors <NUM> coupled with the system bus <NUM> for processing the information. The processors <NUM> may include one or more central processing units (CPUs), graphical processing units (GPUs), or any other processor known in the art.

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

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

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

The computing system <NUM> also includes an I/O adapter <NUM> coupled to the system bus <NUM> to connect the computing system <NUM> to a controllable physical device, such as a robot. In the example shown in <FIG>, the I/O adapter <NUM> is connected to one or more sensors <NUM>, for example, including a video camera, a microphone, a vibration sensor, or combinations thereof.

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

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

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

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

The embodiments of the present disclosure may be implemented with any combination of hardware and software. In addition, the embodiments of the present disclosure may be included in an article of manufacture (e.g., one or more computer program products) having, for example, a non-transitory computer-readable storage medium. The computer readable storage medium has embodied therein, for instance, computer readable program instructions for providing and facilitating the mechanisms of the embodiments of the present disclosure. The article of manufacture can be included as part of a computer system or sold separately.

The computer readable storage medium can include a tangible device that can retain and store instructions for use by an instruction execution device.

Claim 1:
A method for commissioning and deploying an artificial intelligence, AI, based inspection system (<NUM>), comprising:
(i) receiving, by a commissioning computer, sensor data captured by a sensor (<NUM>), the sensor (<NUM>) positioned within a physical environment (<NUM>) to capture sensor data pertaining to individual items in a sequence of similar items to be inspected,
(ii) collecting, by the commissioning computer, a plurality of data samples, wherein collecting each data sample comprises providing an operator interface at the commissioning computer for a field operator to access sensor data pertaining to individual items and thereto assign classification labels associated to an inspection task, the collected data samples corresponding to a fixed setting of the sensor (<NUM>),
(iii) training, by the commissioning computer, an AI algorithm using the collected data samples to configure the AI algorithm to predict the classification labels from input sensor data,
(iv) testing, by the commissioning computer, the trained AI algorithm by feeding the trained AI algorithm with real-time sensor data captured by the sensor (<NUM>) positioned within said physical environment (<NUM>) with said fixed setting,
wherein steps (ii) through (iv) are performed iteratively using different fixed settings of the sensor (<NUM>), to determine a final setting of the sensor (<NUM>) for which a defined success criterion is achieved during the testing, and
(v) deploying the iteratively trained and tested AI algorithm to a field device (<NUM>) for execution, the field device (<NUM>) being coupled to the sensor (<NUM>) configured with the final setting to provide sensor data as input to the deployed AI algorithm.