Software-defined manufacturing / assembly system

Abstract

The system of the present invention is a software-defined manufacturing (SDM) system that integrates several technologies and methods into a system that automates the process of engineering and operating automated manufacturing systems, also known as "automating automation." In one embodiment, some or all of the following aspects of the "automating automation" system are integrated: modular, configurable, reusable manufacturing cells; computer vision systems; automatic calibration systems; a recipe-based programming environment; a configuration management system; production analytics; and a marketplace for sharing recipes.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Provisional Application No. 62 / 934,517, filed November 12, 2019, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This invention relates to robots, and more particularly to software-defined manufacturing / assembly systems. Background Technology

[0004] Although automated equipment and methods have been used to manufacture products for decades, such automated systems are not always adopted; instead, human labor is still commonly used to perform tasks that can be automated.

[0005] Automation is expensive and time-consuming.

[0006] Common reasons for relying on manual labor rather than automation include the high capital costs of automation-related equipment, the high cost of designing automation solutions, and the long time required to design, build, deploy, configure, program, and debug automation solutions. Companies looking to automate manufacturing tasks often outsource projects to systems integrators, who typically perform the work from design to delivery in a way that is tailored to specific manufacturing products and processes. While this customized approach may be more time- and cost-effective for a particular manufacturing project, it does not support the efficient reuse of automated equipment or automation engineering for future products and projects. Similarly, if you only plan to drink one cup of coffee in your lifetime, a disposable paper cup is cost-effective, but a (initially) more expensive reusable coffee cup is more cost-effective over a lifetime of coffee consumption.

[0007] Automation tools are not integrated into workflow solutions

[0008] Several tools exist to assist in the design, engineering, deployment, commissioning, operation, and improvement phases of manufacturing automation projects (from design to delivery to production operations), such as computer-aided design (CAD) tools, computer-aided manufacturing (CAM) tools, simulation tools, enterprise resource planning (ERP) tools, manufacturing execution system (MES) tools, programming tools, Internet of Things (IoT) tools, etc., but these tools are often focused on solving specific engineering tasks in isolation.

[0009] Deploying and scaling automation solutions is expensive and time-consuming.

[0010] Automated systems typically have configuration data (including settings and software) that controls their behavior. Examples include screwdriver rotation speed, oven thermostat control, target robot coordinates, and software control programs. Automated systems often have many different devices (e.g., robots, conveyor systems, feeders, assembly tools, etc.), each with its own configuration data. The normal process of engineering a solution involves designing and managing the configuration data (including software and operating systems) of many devices. Managing such versions during the commissioning and process optimization phases is time-consuming and error-prone. Deploying such solutions to robotic cells is typically time-consuming and requires expert guidance.

[0011] While simulation tools can accelerate the development of automated solutions, the reality is that the simulation models employed often differ significantly from the real world. For example, an engineer might use simulation tools to develop a program that moves a robotic arm through a series of coordinates to pick up a screw from a dispenser and place it into a product housing at a desired screw hole. The problem is that simulation models often fail to accurately represent the frequent geometric (positional) changes that occur in physical equipment (conveyors, pallets, fixtures, components, grippers, tools, etc.). Therefore, simulation models of robotic tools and screw hole locations are unlikely to closely match physical reality.

[0012] When robot control programs are deployed from simulations to physical factories, technicians and programmers often spend considerable time modifying and calibrating these programs to adapt to physical realities. Computer vision solutions exist that can help correct for some real-world variations, but such systems typically require manual calibration to determine the camera's position and parameters relative to other automated equipment, tools, product components, and fixtures. Attached Figure Description

[0013] The invention is illustrated in the accompanying drawings by way of example rather than limitation, and the same reference numerals denote similar elements, and wherein:

[0014] Figure 1 This is a simplified block diagram of one embodiment of a system in which robotic units can be implemented.

[0015] Figure 2 It is a simplified block diagram of the process of creating an assembled final product using a micro-factory that includes one or more robotic units.

[0016] Figure 3A This is an overview flowchart of an embodiment of the robot micro-factory system of the present invention.

[0017] Figure 3B An example of a microfactory line reconfiguration is shown.

[0018] Figure 4Aand 4B These are flowcharts of two implementation examples of moving from a design concept to a micro-factory.

[0019] Figure 5A An embodiment of a hybrid factory system is shown, in which there are components from a micro-factory that provide mechanical assembly and inspection, as well as components from a conventional factory assembly line.

[0020] Figure 5B An example of a software-defined manufacturing process is shown, illustrating the user-facing interface, the developer-facing platform and infrastructure, and the core technological components that form the basis of the system.

[0021] Figure 5C This is a block diagram of one embodiment of the components of a software-defined manufacturing system.

[0022] Figure 6 This is a flowchart of one embodiment of Design for Manufacturing and Assembly (DFMA).

[0023] Figure 7A This is a flowchart of one embodiment of a method utilizing a device-agnostic formulation.

[0024] Figure 7B This is a flowchart of one embodiment of a micro-factory definition based on the products to be manufactured or assembled.

[0025] Figure 8 This is a flowchart of an embodiment of smart recipe creation using driver extraction.

[0026] Figure 9 This is a flowchart of one embodiment of applying a formula to a micro-factory to run a circuit.

[0027] Figure 10 This is a more detailed flowchart of one embodiment of deploying a microfactory.

[0028] Figure 11 This is a flowchart of one embodiment of robot cell reconfiguration and version control.

[0029] Figure 12 This is a block diagram of one embodiment of a computer system that can be used with this application. Detailed Implementation

[0030] This application provides an integrated software-defined manufacturing system for manufacturing and / or assembly. This system utilizes a modular system of one or more robotic units assembled together to create a micro-factory. Software-defined manufacturing systems enable more efficient, accurate, and faster production speeds. The system enables control over the entire manufacturing workflow and production robots, and provides a wide range of benefits for increased adoption of manufacturing automation. This provides a software-defined manufacturing (SDM) system. In this context, the term SDM includes software-defined manufacturing, assembly, and / or inspection. The system of the present invention can provide one or more of these manufacturing aspects. SDM is a manufacturing ecosystem where automation can be achieved through software, or where software performs functions that previously required hardware. The benefit of SDM is the ability to quickly, with high quality, and at low cost, reconfigure to address different problems without the high costs of manual customization. Software automates hardware, replaces the need for a particular hardware component, and adapts the hardware to new situations, defining SDM. SDM uses software to automate the design, engineering, deployment, configuration, operation, and improvement of workflows for automated manufacturing systems (“automating automation”). This ability to define and control hardware functions through software is provided in the system of the present invention. The system can provide one or more of the following advantages:

[0031] • Provide software-defined manufacturing systems that improve the speed and efficiency of creating, maintaining, and improving robotic manufacturing / assembly systems;

[0032] • Reduce the engineering work and time required to design, test, configure, and debug automated solutions;

[0033] • Reduce the cost of automated equipment by increasing standardization and reuse;

[0034] • Improve productivity in automated processes by enhancing quality through adaptive sensing and automatic optimization. For example, closed-loop process feedback to improve production configuration settings;

[0035] • Enables the use of sensor systems to quickly detect and resolve deviations from normal operation;

[0036] • Provide a reference microfactory model, a virtual representation, based on sensor data that closely parallels the physical microfactory and has parameters updated based on data from the sensor system;

[0037] • Enables rapid revision of strategies and plans to achieve the goal of adapting the microfactory to detected deviations from normal operation; and

[0038] • Due to its configurability and updability, it can quickly switch to new processes and new products;

[0039] • Improve the efficiency (cost, quality, speed, etc.) of automated manufacturing by refining product design software;

[0040] • Automating the programming of manufacturing equipment based on data extracted from CAD data;

[0041] • Improve manufacturing process design and engineering through process modeling and simulation;

[0042] • Improve process programming by using integrated software development environments that employ declarative methods, hardware virtualization, debugging tools, etc.

[0043] • Improve configuration change workflows through configuration management;

[0044] • Improve the speed, accuracy, and process control of workflows used to deploy configurations to hardware through deployment management;

[0045] • By supporting local and remote observation, management, and debugging through software, the overall equipment efficiency of the automation system can be improved; and

[0046] • Improve quality through automated inspection.

[0047] The system of the present invention integrates several technologies and methods into a software-controlled manufacturing system that automates the processes of engineering (design, deployment, configuration, calibration, programming, debugging, and improvement) and operating the automated manufacturing system (also known as "automating automation"). In one embodiment, the technologies implemented by the "automating automation" system may include:

[0048] • Design for automation / Design for manufacturing and assembly / Generative programming;

[0049] Feedback systems for DFA / DFMA / generative systems;

[0050] • The ability to import and define computer-aided design (CAD) designs for objects to be manufactured and / or assembled;

[0051] • The process design and configuration of modules that function both online and offline;

[0052] • It allows for the creation, testing, and deployment of processes both offline and online;

[0053] • It provides declarative high-level procedural programming, which is abstracted from and virtualized by the underlying hardware that implements it;

[0054] Virtualized robotic units and micro-factories that mirror physical devices;

[0055] Configuration management, approval management, and workflow management;

[0056] • Cloud-based deployment, configuration, and reconfiguration;

[0057] • Integrated debugging program system;

[0058] IoT / Monitoring / Remote Management

[0059] • Automated quality inspection of products and product manufacturing process steps; and

[0060] • Continuously improve process parameters based on sensor data and machine learning.

[0061] In one embodiment, the system of the present invention provides a software-defined manufacturing / assembly system based on modular, configurable, and reusable manufacturing cells; a computer vision system; an automated calibration system; a recipe-based programming environment; device extraction; virtualization; a simulation system; a configuration management system; a configuration deployment system; production analysis; and production configuration optimization. In one embodiment, the system's recipes are applicable to different robot cells, and there may be a market for sharing recipes, hardware designs, device drivers, configurations, and integration solutions.

[0062] In one embodiment, a modular, configurable, and reusable manufacturing cell integrates complex components that may include: safety systems, control systems, conveying systems, robots, lighting systems, computer vision systems, metrology and calibration devices, human-machine interfaces, sensors, power and electrical management systems, and network and communication systems. Compared to custom-designed systems, these robotic cells are faster and cheaper to engineer, configure, and deliver because the engineering within the robotic cell is pre-done, reused, and optimized across multiple projects. Furthermore, the same set of tools and kits or processes can be reused in subsequent projects, thereby reducing costs and improving quality.

[0063] In one embodiment, a computer vision system utilizes modular vision hardware (lenses, cameras, lighting systems, etc.) and software that facilitates automated configuration.

[0064] In one embodiment, the automated calibration system uses computer vision and software algorithms to automatically create a 3D 6-DOF calibration model of multiple aspects of the automated unit, including lens distortion models, camera pose estimation, and various aspects such as markers, references, robot geometry, robot arm end-tool geometry, transport geometry, component geometry, carrier geometry, frame geometry, tool geometry, etc. In one embodiment, calibration is highly hardware-dependent. In one embodiment, the sensor group may include one or more of the following: cameras, motion sensors, temperature sensors (environmental and individual components), airflow sensors, humidity sensors, sound sensors, vibration sensors (machine status feedback), pressure sensors, position sensors, chemical sensors (e.g., pH levels), molecular sensors (which may include smoke alarms and airborne particulate detectors), RFID sensors (IoT), radio frequency emission sensors, and other sensors.

[0065] In one embodiment, a recipe is a process followed by a robotic cell or manufacturing line to produce a specific result. A recipe can be an entire process, a sub-part of a manufacturing, assembly, or inspection process, or an instruction for a robotic cell or microfactory to perform another set of actions. In one embodiment, a recipe in this context is a set of actions expressed on top of reusability. Recipe-based high-level programming environments are created by adding declarative commands rather than just procedural commands, hardware virtualization, and encapsulation differences, allowing the software environment to be extended to device drivers for new and changed hardware. Compared to procedural programming, declarative programming utilizes an approach in which the program describes the desired result without explicitly listing the commands or steps that must be performed to achieve that result.

[0066] In one embodiment, the system utilizes virtualization to represent and / or simulate the behavior of a robot cell, or a group of one or more robot cells working together in a virtualized microfactory (also known as a reference microfactory). This virtualized robot cell, also referred to as a "digital twin," can utilize the same or similar formulation as the physical robot cell and can be used for offline testing of new processes. In one embodiment, the digital twin is calibrated based on real sensor data from its corresponding physical robot cell. The digital twin can also be used to monitor the robot cell in real time. The digital twin can also be used to recreate processes based on captured sensor and status data to identify deviations from normal or expected operation, wear and tear, and the effects of other operating conditions. The pairing of the physical device with the digital twin or reference microfactory provides an online / offline interface, where programs can be created offline on the digital twin and then deployed online on the physical robot cell, and programs can be created online on the physical robot cell and then sent to the digital twin.

[0067] Topological structures populate dependencies and parameterize them, allowing the system to apply recipes to specific devices. Defining actions defines the dependencies between those actions, which in turn can be used to define the actual components required to fulfill those dependencies. In some embodiments, multiple components may be used instead to satisfy such dependencies. In one embodiment, the system may further restrict these components based on those available in the system.

[0068] A recipe-based high-level programming environment allows users to utilize device-independent and / or declarative commands, such as "insert module into slot." Thus, in one embodiment, the system determines specific requirements, such as chip and slot size, required robot motion coordinates, and individual device-specific commands and timing required for hardware to perform chip insertion. The commands and the specific requirements determined based on those commands define the requirements for downstream components. For example, this defines a specific end-effector tooling, and an arm that moves in 3D and can apply a certain amount of pressure, has a certain level of precision, and can check alignment, etc. The system then configures the robot cell using these requirements until no unmet requirements are found. This defines the cell.

[0069] In one embodiment, defining the topology of the units generates an object model, against which the system is programmed. In another embodiment, the process defines a "dependency graph" that defines a set of skills (for arms and arm-end elements), hierarchically layers the original device, and applies recipe-based high-level programming, applying the recipe to the topology. This high-level programming enables the creation of reusable components that can be used outside of this specific context.

[0070] A configuration management system manages settings, software, and recipes. In one embodiment, the configuration management system provides version control, including tracking, rollback, check-in, check-out, etc. In one embodiment, versions of configuration and software data are managed in a change management database that records changes, maintains configuration relationship data, and enforces workflow policies that authorize who performs various tasks involved in updating the configuration (e.g., making changes, reviewing changes, approving changes, deploying configuration versions to hardware, etc.). In one embodiment, the configuration management system provides differences between versions. In one embodiment, the system also provides workflow management, which may include approval and logging. Configuration management is suitable for individual machines and / or lines or micro-factories. It enables configuration and code deployment from the configuration management database to local and / or remote automated devices. In one embodiment, a configuration deployment system automates the provisioning, deployment, and verification of configuration data between the configuration database and various hardware components of the automation system. While the process from the configuration database to hardware is typically unidirectional, the system can also be implemented to detect configuration changes made manually on the hardware and log these changes to the configuration database.

[0071] In one embodiment, the system provides production analysis and analytics. Production analysis is a system for collecting sensor and process data and for analyzing that data. In one embodiment, the system collects data in real time and can provide real-time analysis as well as ongoing analysis. In one embodiment, the analysis can utilize data from across devices and lines.

[0072] In one embodiment, the system may further provide a marketplace for discovering, reusing, and sharing recipes. The ability to create, reuse, and remix recipes increases the functionality and value of the robotic unit.

[0073] The following detailed description of embodiments of the present invention refers to the accompanying drawings, wherein like reference numerals denote similar elements, illustrating specific embodiments of implementing the invention by way of illustration. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. Those skilled in the art will understand that other embodiments can be utilized, and logical, mechanical, electrical, functional, and other changes can be made without departing from the scope of the invention. Therefore, the following detailed description is not restrictive, and the scope of the invention is defined only by the appended claims.

[0074] Figure 1This is a simplified block diagram of one embodiment of a system in which robotic units can be implemented. In one embodiment, robotic unit A10 comprises one or more individual robotic units that together form a software-defined manufacturing line or microfactory. In one embodiment, the individual robotic units A10 can be connected via conveyors and reverse conveyors, such that a single item manufactured or assembled in the microfactory passes through multiple robotic units A10 (or multiple times through one or more units A10). Robotic unit A10 can provide manufacturing, assembly, inspection, and / or testing of products. Therefore, robotic unit A10 can be an inspection system such as an automated optical inspection (AOI) machine, an assembly system such as a system with a robotic arm for inserting screws, or a manufacturing system such as a CNC machine.

[0075] In one embodiment, robot unit A10 is controlled by software. In one embodiment, configuration and control data for robot unit A10 are applied to the unit from memory A20. In one embodiment, memory A20 may be part of a remote system coupled to robot unit A10 via network A05. Configuration data A25 defines the configuration of each robot unit A10 and the manufacturing line. Configuration data may include software configurations and any other configurations that can be controlled by software. For example, a household thermostat has a configuration (temperature target setpoint) that is not itself software, but in some thermostats, the setpoint configuration can be controlled / modified via software. Therefore, configuration management can encompass data that can be controlled by software, even if it controls hardware settings.

[0076] In one embodiment, the configuration data may include other configuration elements that can be controlled by software, such as setpoints, pressure, torque, and other settings. Robotic unit A10 collects operational data during calibration, testing, or use. This operational data is stored in memory A20 and used by the machine learning system A35. In one embodiment, local storage device A15 provides a backup of the robot unit's configuration data and the operational data generated by the robot unit during use. In one embodiment, local storage device A15 acts as a buffer for memory A20. In one embodiment, if robot unit A10 is disconnected from network A05, it can continue operating and collecting real-time operational data using local storage device A15.

[0077] In one embodiment, because the unit is software-configurable, a single robotic unit A10 can perform multiple stages during the manufacturing process and can be reconfigured during manufacturing. In one embodiment, this also makes it possible to replace the robotic unit A10 in a microfactory during manufacturing without extensive manual reconfiguration. In fact, extensive reconfiguration can be accomplished through automated methods under software control. In one embodiment, this also allows for the addition of units to a microfactory.

[0078] Figure 3B An example of a microfactory line reconfiguration is shown. The initial configuration comprises four units, F1, I1, Se1, and St1, each performing a specific function. If a failure occurs at one of these units (here, unit I1), or if the system determines that a process is lagging at unit I1 (i.e., the process at I1 slows down the system throughput), this can be addressed in various ways.

[0079] By enabling rapid reconfiguration of one or more robot cells in the event of a hardware failure, the remaining system (and potentially backup systems) can be reconfigured to adapt—much like a data center does in the event of a server failure. This may require tool changers within the robot cells and / or reconfigurable conveyors that can route products to the correct cells. Such routing can utilize main and auxiliary conveyors that can bypass work cells. This transport will be “planned” or “controlled” by software.

[0080] If a robot cell is available, it can be configured to replicate the functionality of cell I1, thereby creating cells I1-1 and I1-2. The workflow can then split the product from F1 into one of these cells. Even without an additional "backup" robot cell, another cell (or even a group of cells) that previously had a set of tasks can take over additional tasks from the overloaded / damaged cell. Depending on the tasks of the overloaded / damaged cell, these tasks can be moved to a single other cell, a single backup cell, or distributed across multiple cells.

[0081] This effectively removes bottlenecks or addresses hardware failures by doubling the completion speed of I1. Alternatively, the functions performed by unit I1 can be split into two units. This is useful when unit I1 lags, as it has two functions and the relative timing of these functions can be separated. Alternatively, if no additional robot unit is available, the functions of unit I1 can be partially split into unit F1 (or unit Se1). Alternatively, if the timing makes having a copy of unit I1 more useful, one of the other units can be reconfigured as I1, and the functions of said unit can be assigned to an existing unit. In the example shown, Se1 can also provide services for St1, creating free robot units for adding additional I1 units. Because robot units can be reconfigured via software, this type of adjustment can be made once the microfactory is set up and running. This enables the optimization of the microfactory's cycle time. Additionally, this ability to quickly reconfigure and automatically calibrate the microfactory allows it to be adapted to different products. Furthermore, remote deployment of recipes, reconfiguration management systems, and production analytics provide a backbone for modular, configurable, and reusable microfactories that can be used for new product launches as well as small-scale production. Because production lines can be distributed among more robot units, or production lines can operate in parallel, mass production is also possible.

[0082] Return to Figure 1 In one embodiment, robot unit A10 includes a local user interface A55 that enables interaction with robot unit A10 in the manufacturing workshop. In one embodiment, the local user interface A55 can provide joystick-based interaction, thereby enabling direct control of elements of the robot unit. In one embodiment, the local user interface may include a virtual reality controller, detected gestures, or any other multi-degree-of-freedom input device (mouse, 3D spatial mouse, etc.). In one embodiment, when using a human-safe robot, the local user interface A55 can achieve direct manipulation of the robot arm by allowing a human to physically manipulate the robot arm.

[0083] In one embodiment, in addition to the local UI A55, there may be a remote UI A50, which is coupled to the robot unit A10 via network A05. The remote user interface A50 can be a portable user interface, such as a tablet computer. The remote user interface A50 can be connected to the robot unit A10 via a local area network (LAN), personal area network (PAN), or other types of network. In one embodiment, some remote UIs A50 may need to be physically located near the robot unit A10, while others can be operated from anywhere. In one embodiment, the functions and control elements presented on the user interface may vary based on the robot unit A10, the configuration of the robot unit A10, the identity / qualification of the individual logged into the user interface, and proximity to one or more physical units. In one embodiment, the local UI A55 and the remote UI A50 provide the same basic layout and functionality, thereby reducing the complexity of operator interaction with the robot unit A10. In one embodiment, the user interface provides a unified human-machine interface (HMI) across all robot unit types and configurations.

[0084] In one embodiment, the process for producing the final product begins with development tool A40. In one embodiment, these tools may be made remotely available to the designer. In one embodiment, these tools may be provided online via a Software-as-a-Service (SaaS) type interface. In one embodiment, development tool A40 enables the creation of recipes for robot cell A10. In one embodiment, development tool A40 enables the creation of models, digital twins, simulations, designs, and / or configurations of a manufacturing line comprising one or more robot cells A10. In one embodiment, each robot cell A10 has certain capabilities. Development tool A40 enables users to create manufacturing lines using one or more robot cells in robot cell A10 to produce the final product and to create recipes to configure and control robot cell A10. In one embodiment, development tool A40 may utilize data derived from CAD designs to translate high-level commands into specific instructions. For example, the "tighten with screw" command may be translated into placing the screw at the location of a screw hole exported from CAD data, which may have been generated by the system (box A60) or may have been imported.

[0085] In one embodiment, a CAD / Design for Manufacturing and Assembly (DFMA) / optimization system A60 can be used. In one embodiment, the design system uses data about the manufacturing capabilities of the robot cell to create CAD designs, models, digital twins, simulations, or other configurations for the final product to be manufactured. In one embodiment, machine learning can be used. Machine learning can be based on learning from one or more previous projects and data or simulations. The system can use feedback from sensor data from the robot cell to further improve the DFMA and / or generative programming system. In one embodiment, the system can be trained using physical simulations, such as synthetic training data. In one embodiment, a generative adversarial network (GAN) can be used to improve the quality of simulation and ML training. In one embodiment, a convolutional neural network (CNN) can be used for simulation and ML training.

[0086] In one embodiment, based on knowledge of the robot cell's capabilities, optimization methods can be used to minimize the likelihood of manufacturing steps and / or design problems. In one embodiment, when using the CAD / DFMA / optimization system A60, the system can consider the manufacturing / assembly constraints of the robot cell A10 when designing the final product. In one embodiment, the CAD / DFMA / optimization system A60 can receive data from the development tool A40 and can iterate the final product design based on problems identified by the development tool A40. In one embodiment, the output of the development tool A40 is the sequence of operations for each robot cell in the manufacturing line.

[0087] In one embodiment, the A60, designed for manufacturing and assembly, uses machine learning to improve the design. In one embodiment, the machine learning (ML) system is based on learning from previous projects and data, or it may be based on simulations, or both. In one embodiment, physical simulations may be used instead of real-world data to train the ML. This is referred to as synthetic training data.

[0088] Once the design is generated, the converter A70 translates the sequence of operations into control commands for individual robot units. In one embodiment, the output of the development tool A40 is a recipe with declarative commands, such as a language describing the configuration and actions taken by the robot unit. Because each individual robot unit contains multiple elements that can utilize different control languages, the translation is highly complex. Furthermore, different robot units performing the same sequence of operations can have elements from different manufacturers or with different configurations. For example, a robot arm can have two, three, or four motion joints, and the joints can have different limitations. Therefore, for each individual robot unit, a single command in the sequence of operations can be translated differently.

[0089] The translated control commands can be applied to the virtualized robot unit A75, also known as a digital twin simulation or "digital twin". In one embodiment, the digital twin is a simulation running on a processor. In one embodiment, the processor can be a distributed processor or any other computing platform that can support such a simulation. The virtualized robot unit A75 can represent a separately configured robot unit and can be used for testing and verification. In one embodiment, the virtualized robot unit A75 can use operational data A30 from the physical robot unit A10 to allow a user to remotely view the actions of the physical robot unit A10. In one embodiment, the operational data can be "real-time". In one embodiment, a "real-time" view means real-time footage from cameras and other sensors, reflecting the current state and actions of the robot unit.

[0090] In one embodiment, a user can preview the robot unit's movements during the process, track the movements during the process, and / or review the movements using the virtual robot unit A75 after the process. In one embodiment, step-by-step debugging can also be performed while controlling the physical robot unit. In one embodiment, the virtual robot unit can operate in slave mode, where the virtual robot unit precisely tracks the movements of the physical robot unit.

[0091] Once the output of converter A70 is verified and validated, it is stored as configuration data A25. As discussed above, configuration data A25 is applied to the physical robot cell.

[0092] In one embodiment, the machine learning system A35 is used to provide data for iterative learning and process improvement.

[0093] In one embodiment, although the elements are shown as separate elements, those skilled in the art will understand that design tool A60, development tool A40, converter A70, virtualized robotic unit A75, and machine learning system A35 are implemented on one or more computer systems. The computer system may be a standalone device, a server, or a cloud-based system accessible via network A05. In one embodiment, the described elements may be implemented on a single server system. In one embodiment, the described elements may be implemented on multiple unrelated computer / server systems. In one embodiment, although only a single box is shown for an element like development tool A40, the actual tool may be distributed across multiple devices.

[0094] Figure 2This is a simplified block diagram of a process for creating an assembled final product using a microfactory comprising one or more robotic units. In some embodiments, the robotic units may be inserted into a conventional manufacturing line to take over some sub-parts of manufacturing. The process includes a manufacturing layer, from creating a recipe via a recipe creator C10 to fabrication / assembly via the microfactory C50. Although a complete process from initial concept / functional design to completion of manufacturing is shown, those skilled in the art will understand that the system can implement a subset of these processes and include a subset of these features.

[0095] In one embodiment, the system includes a design phase (line B), a production phase (line C), an implementation phase (line D), and a learning phase (line E). The design phase may begin with an artifact-oriented functional design B10, followed by CAD design B20, design verification B30, and iteration / simplification / retrospection B40. In one embodiment, the functional design B10 may include a design for manufacturing, where automated design assesses manufacturability to design the configuration of the artifact. Design verification B30 ensures that the micro-factory can successfully build and / or assemble the artifact. The output of the design phase (line B) is a manufacturing-oriented CAD design.

[0096] Once the design is complete, the production stage (line C) will be used. A recipe creator C10 creates recipes for building the final product based on the CAD design. The recipe creator C10 can be manual, automated, or partially automated. A cell topology C20 determines the configuration of available cells in the microfactory. Because different parts can have different cells (e.g., robot cells with different configuration elements), the cell topology C20 illustrates the available configurations. In one embodiment, cell sequencing and programming C30 are performed on a digital twin representation of the microfactory. The digital twin representation is a virtual representation of the interconnections between cells in the microfactory. In one embodiment, the digital twin representation is closely related to the physical implementation, such that in one embodiment, the digital twin representation is continuously adjusted to match the real world. This allows the system to provide design and testing of the digital twin. In one embodiment, this allows for the construction of complete sequences to manufacture or assemble articles without access to physical robot cells. In one embodiment, the virtual microfactory is also used to monitor the physical microfactory. When the physical microfactory goes out of specification, the virtual microfactory representation provides feedback and remotely provides a “real-time” view of the microfactory. In one embodiment, a "real-time" view refers to a real-time image from a camera and other sensors in real-time or playback mode, reflecting the current or previous state and actions of the robot unit.

[0097] After sorting and programming, along with associated debugging and optimization, are completed, the program and hardware configuration settings are transferred to the physical implementation C40 of each robot cell in the microfactory. Since the virtual representation forms a mirror image of the physical robot cell, the program and configuration can then be used to fabricate / assemble articles C50, resulting in an assembled final product. Of course, the assembled final product can undergo further assembly or manufacturing steps. However, in one embodiment, the system can be used to fully manufacture even complex articles, as will be described in more detail below.

[0098] The implementation phase (line D) illustrates one embodiment of the programming sequence (e.g., C20-C40) in more detail. In one embodiment, the implementation phase can begin with an available robot cell D10 or with design constraints D15. A sequence of robot cells D20 is designed. This sequence constitutes the microfactory. In one embodiment, each robot cell can be optimized to perform a specific sequence or process. In another embodiment, robot cells can perform multiple sequences or processes. Typically, it is more efficient to have each robot cell perform an operation without requiring reconfiguration. However, sometimes a microfactory with fewer robot cells, where one or more robot cells perform multiple processes, is more efficient. The sequence and individual robot cells D30 are verified to ensure that each robot cell in the microfactory can perform the designed processes. The code D40 is then converted for the robot cells. The conversion process is verified on a digital twin implementation of the microfactory. As mentioned above, because the twin is closely aligned with the physical robot cell configuration (including calibration), the system can successfully verify the processes on a virtual version of the microfactory. Once verification is complete, the program is applied to robot cells D60 in the microfactory. In one embodiment, robot cells D70 are automatically calibrated, and the microfactory D80 is ultimately determined.

[0099] The learning phase (line E) demonstrates the programmable aspects of the system. In one embodiment, this process is part of the fabrication and assembly of C50. The robot cells in the microfactory are configured (E10). In one embodiment, calibration and verification (E20) are continuous. Initial calibration and verification ensure the microfactory is correctly configured, and the system continuously monitors the microfactory (E30) to ensure each robot cell remains correctly configured. Operational data collection (E35) collects real-time sensor data. This is used to ensure the digital representation of the microfactory remains accurate and also to ensure the microfactory remains calibrated and accurate.

[0100] The machine learning and self-improvement system E40 utilizes data from a microfactory over time to improve its operation. This can involve using machine learning during the design process based on data from previous designs. It can also include continuous quality improvement of existing designs. The continuous monitoring and self-improvement system can improve configurations beyond simulations or designs. For example, the system might be designed for an oven temperature of 300 degrees Celsius, but it can discover that quality improves when the oven is at 303 degrees Celsius, while quality may decline below 301 degrees Celsius or above 305 degrees Celsius. In one embodiment, the machine learning and self-improvement system E40 can experimentally make small adjustments to the settings to collect data on the impact of such adjustments on product quality, wear and tear, and other aspects of the system. Over time, this can be used to improve the design and optimize production configurations through iterative testing of these adjustments. This can be referred to as generative design. This type of closed-loop feedback optimization is made possible by the machine learning and self-improvement system E40.

[0101] In one embodiment, the machine learning E40 can also be used to improve the design phase (line B) and the implementation phase (line C).

[0102] The E50 automatic reconfiguration system updates robot cells in the microfactory as needed. The E60 version control system tracks every update to each robot cell in the microfactory. If a final change to a robot cell or the microfactory is negative, the E60 version control system can be used to roll back the update. Version control can also be used to ensure changes are simplified. Furthermore, version control can be used to quickly reconfigure the microfactory to produce different products, while retaining the ability to revert to the current configuration and product later.

[0103] In one embodiment, remote access E70 enables authorized users to modify the microfactory from a remote location. This is particularly useful as it allows skilled experts to make updates without being physically present at the microfactory. In one embodiment, inspection and acceptance E80 is the final step in manufacturing the product. Inspection and acceptance E80 provides feedback to machine learning E40 and the user, verifying the quality of the microfactory's finished product, if appropriate. In one embodiment, inspection and acceptance can be performed by an external system or a person. An embodiment of the inspection process is described in co-pending application X entitled "An Improved Inspection System Using Machine Learning" (15000P0102), which is incorporated herein by reference in its entirety. The ability to obtain feedback from inspection further enables the microfactory to deliver high-quality manufacturing, even on a small scale. Additionally, in one embodiment, the system includes inspection steps at various points in the manufacturing or assembly process to detect defects earlier in the process.

[0104] Figure 3A An overview flowchart of one embodiment of the system is shown. The process begins at box 310.

[0105] At box 320, establish a microfactory with one or more robotic units. As described above, each robotic unit can perform the same or different processes. Units can provide manufacturing, assembly, and / or inspection. There may be other parts of the manufacturing process that are not performed by the microfactory.

[0106] At box 330, the robot cells in the microfactory are calibrated. In one embodiment, the entire microfactory is calibrated in addition to individual robot cells.

[0107] At box 340, a reference microfactory is configured to match the physical microfactory. In one embodiment, the reference microfactory includes a virtual representation of each robot cell in the robot cell. These virtual representations of the robot cells are configured to closely match the physical microfactory configuration. In one embodiment, the reference microfactory provides predictive information by running the same recipe as the physical microfactory. This enables the system to provide a virtual testbed and the ability to predict the precise movements of each robot cell.

[0108] At box 345, the microfactory is run. In one embodiment, a reference microfactory runs in parallel, forming a mirror image of the physical microfactory. In another embodiment, the reference microfactory runs before the physical microfactory. In yet another embodiment, the reference microfactory runs after the physical microfactory and forms a mirror image of its past operations based on collected recorded data to facilitate troubleshooting. At box 350, the process identifies any deviations from predicted data from the reference microfactory within the physical microfactory based on sensor data. Deviations include robot drift, such as the robot arm being located outside its predicted position, which could be due to wear, impact or other movement, temperature variations, hysteresis, recoil from motion, or other reasons such as inaccurate components of the robot unit.

[0109] If no deviation is found as determined at box 360, the process returns to box 345 to continue monitoring the system.

[0110] If a deviation exists, then at box 370, the process updates the parameters in the reference microfactory based on the deviation.

[0111] At box 380, the process executed by the microfactory (physical and virtual) is modified to accommodate deviations. In one embodiment, the instructions of the robot unit are updated to accommodate the detected deviations. In another embodiment, the modifications can be initially validated on the microfactory before rapid deployment to the physical microfactory.

[0112] The process then returns to continue monitoring the microfactory. In one embodiment, by enabling the system to modify strategies to achieve the microfactory's operational objectives while adapting to deviations from normal operation, the microfactory becomes resilient and allows for rapid adjustments to address its actual impact. Furthermore, as described below, the deployment of the update process is rapid and can be remote. In one embodiment, changes can also be rolled back. In this way, a resilient, easily deployable, and versatile system is built.

[0113] Although this diagram, and other diagrams within it, use flowcharts to illustrate processes, individual process elements do not need to follow the specific order shown unless they are dependent, and if they are not dependent, the elements can be executed in parallel or in any order. Furthermore, in one embodiment, portions of the system can be implemented as interrupt-driven elements, and checks can be performed sequentially rather than at the end of the process.

[0114] Figure 4A and 4B These are flowcharts illustrating two implementation examples of moving from a design concept to a micro-factory. Figure 4A In one embodiment shown, the system can design the optimal process based on other constraints such as manufacturing speed and budget. Figure 4B In one embodiment shown, the system can be based on available existing robotic units, for example, when deploying a new process to an existing factory setting.

[0115] Figure 4A An embodiment of the new setup is illustrated. The process begins at box 405. At box 410, the new process to be implemented is identified. At box 415, robot cells and configurations are selected based on constraints. In one embodiment, constraints may include manufacturing time (e.g., the number of parts per batch, or the time per part), cost (e.g., the total budget for the process), space (e.g., how many robot cells can be placed), available tools, and other constraints.

[0116] At box 420, a microfactory is designed using baseline elements. In one embodiment, the baseline elements contain all available configurations of the robot cells. As described above, the robot cells may include manufacturing cells, assembly cells, inspection cells, etc.

[0117] At box 425, identify the actual robot cell configuration of the micro-factory. For example, for an assembly cell, the robot cell configuration includes a specific robot arm, a configured conveyor, a pallet feeder, and other components that make up the complete robot cell.

[0118] At box 430, the baseline configuration is converted into the actual configuration. This involves designing the physical microfactory configuration from the robot cell design.

[0119] At box 435, the design is validated on a virtual representation of the microfactory (also known as a digital twin). In one embodiment, the digital twin is designed to closely mirror (simulate) a real-world implementation. In one embodiment, the virtual microfactory is a software representation of a sequence of one or more individually configured robotic units for testing and validation. In one embodiment, the same recipe or sequence of steps used to perform the process can be applied to the virtual microfactory as physical robotic units in the physical microfactory, thereby providing an offline / online programming environment. Therefore, the system can virtually validate the process.

[0120] At box 440, after the verification process, instructions are transmitted to the physical robot units in the microfactory for use. The process then ends at box 445.

[0121] exist Figure 4B In the parallel process, instead of selecting robot cells based on other constraints, at box 460, available robot cells are identified. A circuit is then designed using the available robot cells. For example, if only one robot cell with a robot arm exists, that single robot cell can perform all assembly steps requiring the robot arm (e.g., inserting a heatsink, installing screws, etc.). In one embodiment, the circuit can be rerouted multiple times through a single robot cell. Furthermore, in one embodiment, the design takes into account the time required to change tools within the robot cell and incorporates processes designed to maximize manufacturing speed and / or minimize hardware costs.

[0122] Figure 5A An embodiment of a hybrid factory system is illustrated, in which there are components from a microfactory providing mechanical assembly and inspection, as well as components from a conventional factory assembly line. The illustrated production tool 525 includes a variety of devices used in the complete manufacturing of the product. In one embodiment, these devices could all be robotic units. In another embodiment, the microfactory may replace only one of the functions shown in production tool 525. For example, the microfactory may use one or more robotic units for mechanical assembly.

[0123] In one embodiment, one or more of the production tools 525 are software-controlled. In one embodiment, for software-controlled tools, operational data 510 is used to control the tool. In one embodiment, this includes uploading new recipes (processes), adjusting controls, etc. Data from the software-controlled tool also flows into the operational data 510. In one embodiment, these two sets of data may be separate. In one embodiment, the operational data 510 includes sensor data from the software-controlled tool, showing the precise operations, configurations, and steps performed by the tool.

[0124] Machine learning system 515 utilizes data from production tool 525 to configure, calibrate, and manage the production tool. In one embodiment, machine learning system 515 is also used to design subsequent iterations or different microfactories. The system collects data from the robotic unit, including data from cameras and sensors. This data can be used for machine learning. For example, when collecting data from the robotic unit, the system can learn to optimize the use of torque or pressure in certain actions, robotic arm compensation, optimal operation sequence, vibration and temperature during operation, and how these factors affect the process. Additionally, the data may include the difference between simulated execution time and actual execution time, etc. This data is provided to the machine learning system, which can predict how to improve the design and layout of the microfactory.

[0125] Reporting tool 520 provides interface elements that allow a supervising user to view the process. In one embodiment, reporting tool 520 provides a visual representation of operational data 510 and sensor data. In another embodiment, the reporting tool can also provide suggested reconfigurations or adjustments to the micro-factory as appropriate.

[0126] Figure 5B An embodiment of a software-defined manufacturing process is illustrated, showing the user-facing interface, the developer-facing platform and infrastructure, and the core technological components that form the basis of the system. Software-defined manufacturing (SDM) is a manufacturing ecosystem where automation or software execution of functions that previously required hardware (e.g., computer vision replacing the need for precision fixtures) can be achieved through software. The benefit of SDM is the ability to quickly and inexpensively reconfigure hardware to solve different problems without the high costs of manual customization. SDM is defined by software automating hardware, replacing the need for specific hardware, and adapting hardware to new situations. This ability to define and control hardware functionality through software is provided in the system of this invention.

[0127] The foundation of all these aspects is a platform and infrastructure 560 that provides an intermediate layer between the tooling and device layers. In one embodiment, the platform and infrastructure 560 is supported by computer vision 565, machine learning 570, a machine interface 575, and a data aggregation tool 580. Computer vision 565 enables the calibration and tracking of the robotic unit. Machine learning 570 enables the system to learn from use for calibration, as well as efficiency and effectiveness. The human-machine interface 575 enables technicians to interact with the physical robotic unit, create recipes, and monitor the robotic unit. Data aggregation 580 collects and records data from cameras and other sensors in the robotic unit for training, tracking the effectiveness of current recipes, and machine learning.

[0128] In one embodiment, a recipe is a sequence of commands sent to a robotic unit to perform one or more actions. Recipes can be static or dynamic, simple or complex. A simple static recipe might be “move the conveyor Y inches at time X.” A complex recipe might involve acquiring data from a camera and conditionally inserting screws, provided the parts are correctly configured. A recipe can encompass the entire assembly process or steps within that process.

[0129] In one embodiment, on top of platform and infrastructure 560, the system has a computer-aided design (CAD) interface for Design for Manufacturing and Assembly (DFMA). When designing an apparatus to be manufactured or assembled, the system considers the limitations and capabilities of the microfactory. For example, allowing the position of a screw to be moved can simplify the manufacturing process. Because the capabilities of the robotic cells in the microfactory are known, these capabilities can be taken into account during the design process. Because this is an integrated, holistic system, the design phase is integrated in one embodiment. Therefore, in one embodiment, a machine learning system that learns from the microfactory product can determine the optimal configuration of various components of the product before design. In one embodiment, DFMA can start from initial requirements, and the process can identify specific component configurations that are most efficient for the microfactory. This enables the system to optimize product or project designs for robotic cell manufacturing, assembly, and / or inspection. By changing some features of the product design, the product can be made easier, cheaper, and more accurately manufactured or assembled.

[0130] The CAD-to-Robot 535 process extracts manufacturing features from CAD designs to enable implementation on robotic cells. A digital twin 535 is a virtual representation of each robotic cell and, in one embodiment, a micro-factory. In one embodiment, the conversion generates a recipe or sequence of actions to produce a design. Once the recipe is created, it can be tested on a virtual version of the robotic cell or the digital twin. Because the digital twin is a representation of the precise configuration of the robotic cell, the entire process can be tested on the digital twin. Furthermore, in one embodiment, data from the digital twin provides predictive data for the robotic cell, enabling the system to compare the actual configuration with the virtual representation and resolve discrepancies before they cause problems. In one embodiment, the virtual representation can be used for testing and validation.

[0131] In one embodiment, the digital twin uses operational data from physical robot units to enable users to remotely view the actions of the physical robot units. In one embodiment, users can preview the actions of the robot units during a process, track actual actions during a process, and / or review actual actions using the virtualized robot units after the process. In another embodiment, one or more virtualized robot units can be assembled into a virtualized microfactory, enabling users to plan, test, and monitor the physical microfactory.

[0132] Configuration and Deployment Management 540 enables the system to track and approve configuration changes, deploy recipes and other configurations (software, settings, operating systems, drivers, etc.) to robot cells in the microfactory, and manage the configuration and reconfiguration of robot cells. Configuration encompasses every aspect of the robot cell that allows hardware operation to be restored to a specific state. This includes hardware settings, recipes, software programs, device drivers, operating systems, etc.

[0133] Configuration management tracks and approves configuration changes, while deployment management uses the configurations in the database to deploy them to all the different hardware components and settings within the robot unit. In one embodiment, configuration management provides a workflow for tracking configuration changes and approving deployments. In one embodiment, approval may involve individual approvals of deployments or rollbacks of configurations, both internally and / or externally. In one embodiment, deployment may include automatically deployed elements (e.g., settings and software) and elements deployed by alerting the user to make changes (e.g., replacing hardware components, toggling switches, etc.). In one embodiment, the configuration management system may track configuration aspects that leverage user actions and provide alerts based on changes to the configuration to prompt those actions.

[0134] Unlike traditional manufacturing ecosystems, in software-controlled manufacturing solutions, if the system determines that a change is problematic, the deployed configuration state (e.g., device settings, software, etc.) can be restored. In one embodiment, configuration and deployment management 540 also enables monitoring the impact of changes to code or configuration and rolling back changes if necessary.

[0135] Furthermore, in one embodiment, configuration and deployment management enables the rollout and testing of changes to subsets of the entire production line. In one embodiment, the system may, for example, have an identified and tracked set of product serial numbers, where proposed configuration changes (through manual or software automation) are tested against one or more process steps, units, production lines, or multiple production lines, and once validated, subsequent products are primarily produced. In one embodiment, this allows the generative design discussed above to automatically make small changes, monitor their impact on the system, and improve the design over time through machine learning and a self-improving system. In one embodiment, deployment may be cloud-managed, enabling remote deployment and simultaneous distribution across multiple production lines.

[0136] The adaptive robot control 545 translates manufacturing recipe instructions from an abstract, high-level (e.g., “declarative”) device-independent language into a programmed, device-specific language required by the existing physical hardware. In another embodiment, the adaptive robot control allows manufacturing recipes (or programs) designed for the specific requirements (dimensions, coordinates, etc.) of a single or multi-cell microfactory to be deployed to similar but different cells or microfactories through translation and / or automatic calibration.

[0137] In one embodiment, the adaptive robot control 545 also provides the robot unit with the ability to adapt to similar situations with little or no expert guidance. Typically, in the prior art, a teach pendant is used, where an operator uses buttons on the teach pendant to move the robot through its steps, saving each position individually. However, this is time-consuming and requires a skilled operator. The adaptive robot control 545 enables the robot unit to autonomously complete new tasks without manual programming. The idea is to take data from programmed actions and templates and adapt these goals and actions to similar situations.

[0138] In one embodiment, the adaptive robot control 545 provides automatic or generative programming derived from data extracted from a computer-aided design (CAD) system and / or simulation system describing the product. For example, for a recipe instructing “connect with screws,” automatic programming can extract screw hole coordinates from CAD drawings or CAD models and automatically generate a manufacturing recipe instructing the robot to pick up screws from the screw feeder location, travel to the screw hole location (optionally based on computer vision), and engage the screwdriver tool.

[0139] Inspection and Tracking 550 is used to ensure that products manufactured and / or assembled by the micro-factory meet specifications and are of high quality. As discussed above, inspection includes final inspections after the process is completed, as well as in-process inspections.

[0140] In one embodiment, inspection and tracking include an integrated debugging system. The integrated debugging program utilizes recorded data from the physical robot unit to provide remote real-time debugging, playback, and simulation-based debugging. In one embodiment, remote real-time step-by-step debugging utilizes recorded sensor data including camera data, recipe data, and other sensor data, and displays the data on a digital twin in near real-time to remotely provide a "view" of the robot unit for step-by-step execution of recipes and debugging. Replay debugging allows the system to replay a process or a portion of a process for debugging on a digital twin. This allows "rewinding" the process to observe what happened before a failure or other unexpected event, as well as an observation of the entire process. Simulation debugging enables debugging of recipes and settings using a digital twin.

[0141] In one embodiment, feedback from inspection and tracking can be used by a configuration management system 540 to verify or revert changes, and is also used by a machine learning system 570. In one embodiment, inspection and tracking are part of a micro-factory, or an external inspection system is used to verify and test manufactured and / or assembled products. In one embodiment, the inspection and tracking system uses data from sensors in a robotic unit to perform in-process inspections. This is used to detect defects early in the product assembly process, thereby avoiding further investment in rejected assemblies and directing them to a scrap or rework station.

[0142] User interface 555 provides insights, dashboards, and alerts. In one embodiment, user interface 555 provides a set of dashboards to microfactory users, which is a set of different interfaces based on user identity. For example, a user working on a specific robotic cell can have a different interface and dashboard than a user supervising the production line. For example, if a robotic cell malfunctions, a user working on that specific robotic cell can receive an alert immediately. In contrast, a user supervising the production line can see productivity, error rates, and similar data. In one embodiment, accumulated data from many microfactories is used to train machine learning system 570, update CAD / DMFA system 530, and upgrade recipes and / or robotic cells as new insights are gained.

[0143] Figure 5C This is a block diagram of one embodiment of the components of a software-defined manufacturing system. The software-defined manufacturing system 585 includes software-defined production 586. Software-defined production 586 includes software-defined assembly 587, which includes CAD-to-robotics and digital twin 588, as well as assembly and inspection 589. Configuration management 590 provides the ability to manage, track, protect, record configuration data, deploy the configuration data to physical robot cells, and roll back configuration updates when needed. In one embodiment, dashboard alerts 591 include alerts to individual users regarding microfactory issues. Quality and inspection 592 provides a review of the microfactory's products and verifies that the microfactory is operating as expected. Various other components may include DFMA, supply change management, etc. The platform 595 described above is supported by computer vision 596, machine learning 597, adaptive robotics 598, and human-machine interface 599.

[0144] Figure 6 This is a flowchart of one embodiment of Design for Manufacturing and Assembly (DFMA). The process begins at box 610.

[0145] At box 615, the system receives product function and constraint data. For example, this could be a function definition, or a definition based on functions and dimensions.

[0146] At box 620, a CAD design is generated. In one embodiment, the CAD design can be generated automatically. In another embodiment, the designer may be involved in generating the CAD design.

[0147] At box 625, a CAD design rule check is performed. The CAD design rule check ensures the design is manufacturable. For example, certain types of shapes cannot be manufactured in a CNC machine. If the design is manufacturable in a CNC machine, then the design rule check ensures the machine can manufacture and assemble the parts. At box 630, the process determines if there are any problems with the design. If any problems are found, the process returns to box 620 to regenerate the CAD design to ensure compliance. In one embodiment, this process may iterate multiple times until the CAD design rules are passed.

[0148] If no issues are found, at box 635, the system converts the design into a baseline recipe for the robot cell. The baseline recipe can be high-level, such as "insert screws" or "place DIMM modules into slots," etc.

[0149] At box 640, the process performs a robot design rule check. The robot design rule check ensures that the robot cell can perform all actions in the recipe and that all actions are permitted by the strategy. In one embodiment, this can be based on a general set of rules for the robot cell. For example, a screw with a narrow entry point may not be able to be tightened by a robot screwdriver because a standard screwdriver cannot fit into the space. Or, an assembly step requiring the simultaneous installation of six parts may be impossible in a robot cell. The robot design rule check verifies that there are no actions that the robot cell cannot perform. Design rules can prevent operations through strategies, such as operations that are technically feasible but may lead to unacceptable quality. For example, drilling a hole in a fiberglass board very close to the edge of a board could cause mechanical cracks.

[0150] If any problems are identified as at box 645, the process returns to box 620 to regenerate the CAD design. In one embodiment, the system may also check the recipe to determine if there are other executable commands that can replace the commands that violate the robot design rules. If no problems are found, the process continues to box 650.

[0151] At box 650, the process translates the recipe into an actual robotic cell on which the process will be implemented. While the hypothetical robotic cell or microfactory has a range of possible uses, the actual available robotic cell further limits the system. For example, if the robotic cell has a gantry arm, certain movements cannot be performed. Therefore, the recipe is translated into constraints and capabilities of the actual robotic cell configuration. At box 655, the system performs robot cell or other hardware-specific design rule checks.

[0152] At box 660, the system determines if any problems exist. If any problems exist, the process returns to box 620. Otherwise, the process continues to box 665.

[0153] At box 665, robot data is applied to the digital twin and the robot cell. At this point, the system can use the digital twin to verify the process. The system can then utilize the robot cell to actually manufacture an article. In another embodiment, once the process is verified, instructions are stored. These instructions can then be used. The process then terminates. In yet another embodiment, as will be described below, the recipe is built based on the constraints of the robot cell, and therefore the system does not need to separately check the robot design rules, as the constraints of the programming environment ensure that the recipe conforms to the constraints of the robot cell. Figure 7A This method is described.

[0154] Figure 7A This is a flowchart of one embodiment of a method utilizing a device-agnostic formulation. The process begins at block 710.

[0155] At box 715, define the topology of the cell to generate the object model. The object model is a representation of the robot cell, including its constraints and capabilities.

[0156] At box 720, the user can program against the object model. In one embodiment, this ensures that the recipe (or program) created by the user matches the constraints of the robot cell.

[0157] At box 725, the process determines whether a driver exists for each device. A robotic cell typically contains multiple devices, ranging from cameras and sensors to robotic arms, end-effector tools, conveyors, etc. The system determines whether the programming environment has a driver suitable for each device located within the robotic cell. If a driver does not exist for each device, at box 730, the system loads a driver to convert the recipe into a device-specific one. This is used to convert the recipe into device-specific code. At box 735, the system integrates the driver bundle into the ecosystem and returns to box 725 to ensure all drivers are available.

[0158] Once all drivers are available, at box 740, code is compiled for the robotic device. In one embodiment, the resulting code translates a high-level recipe into robot instructions. For example, the high-level recipe could be "tighten the screw," while the compiled code could be "rotate the screwdriver 90 degrees with force X."

[0159] At box 745, the code is compiled into vendor-specific code. Each vendor provides its own specific interface for the components in the robot cell. Therefore, the system compiles robot instructions into specific code that can interact with specific components. The process then ends at box 750. This process allows the robot cell to be heterogeneous, utilizing components from multiple vendors with different vendor-specific codes. It also makes it possible to generate a single recipe, which can then be translated into instructions for multiple robot cells. The ability to utilize robot cells that are not entirely uniform extends the usability of the system of the present invention by giving the system greater flexibility. Furthermore, this means that if a component of better quality (or price or capability) becomes available, changing that component in the robot cell does not require redesigning all recipes. Instead, when a new component is added, the robot cell can be upgraded, the system can obtain the driver for the new component, recompile the code, and quickly return to online operation.

[0160] Figure 7B This is a flowchart of one embodiment of a micro-factory definition based on the articles to be manufactured or assembled. The process begins at box 755.

[0161] In box 760, define the process objective. The process objective can be a manufacturing object, an assembly object, and / or an inspection object.

[0162] At box 765, identify the recipe steps used to achieve the goal. Recipe steps comprise the actions taken by each robotic unit in the microfactory. This can include actions of the robotic arm, end-effector tools, conveyors, workpiece-carrying pallets, or other components within the microfactory.

[0163] At box 770, identify a set of dependencies for a specific command or action in the recipe. These dependencies include the required sensor dataset, the required set of motions, and the required set of previously completed steps. For example, for the action of “tightening a screw,” the dependencies might include placing the workpiece in place, placing the screw in the screw hole, the robotic arm with a screwdriver end-effector tool, and sensors for controlling rotation and force applied by the screwdriver.

[0164] At box 775, the process identifies the topology of robot units that satisfy dependencies. The robot unit in the above example of tightening screws needs to have a screw dispenser, a screwdriver arm tool end, a force sensor, etc.

[0165] At box 780, the process determines whether any commands to be analyzed still exist in the recipe. If so, the process returns to box 770 to analyze the next command or action.

[0166] At box 785, the microfactory is defined based on the topology and commands in the recipe. In one embodiment, multiple possible definitions are possible, based on other constraints such as assembly speed, the number of available robot units in the microfactory, etc. In one embodiment, the system initially constrains this design based on the number of available robot units and then optimizes it to achieve the shortest cycle time. The process then ends at box 790. This process enables the optimization of the microfactory design based on constraints arising from the recipe being implemented, the available robot units, and any other constraints. For example, in one embodiment, a complex recipe can be implemented on a single robot unit that can change its end-of-arm tooling to take each action in the recipe. Of course, this takes longer than having each robot unit take an action without changing its end-of-arm tooling. This flexibility allows recipes to be implemented in a variety of environments with multiple constraints.

[0167] Figure 8 This is a flowchart of an embodiment of smart recipe creation using driver extraction. The process begins at box 810.

[0168] At box 815, identify the topology of the robot cell. The topology of the robot cell defines the components within the robot cell.

[0169] At box 820, identify the action to be performed by the unit.

[0170] At box 825, an application programming interface (API) is provided with generic parameters that can be used to define robot unit parameters and actions. The API allows users to specify values ​​for various aspects of each operation in the recipe to be performed. For example, for the action of "tightening a screw," the values ​​could include the screw's position, the screwdriver's rotation angle, and the rotation speed.

[0171] In box 830, the process determines whether any component-specific parameters exist. If so, at box 835, the API is enhanced using these component-specific parameters. Component-specific parameters include, for example, the torque range of a screwdriver, the availability (or lack thereof) of a force feedback sensor, etc. The system enables users to control these component-specific parameters through their code.

[0172] At box 840, the system enables recipe creation based on available parameters. Therefore, for systems that do not provide force feedback, the recipe does not depend on force feedback data. If the system includes force feedback, it is likely an input to the control system.

[0173] At box 845, the recipe is compiled into the actual hardware of the robot unit. As described above, this can then be used for the digital twin of the robot unit for verification and testing. It can also be deployed to an actual robot unit. It can also be saved and made available in a set of available recipes. The process then ends at box 850.

[0174] Figure 9 This is a flowchart of one embodiment of applying a formula to a micro-factory to run a circuit. The process begins at box 910.

[0175] At box 920, the topology definition operation for the robot cell based on the microfactory is performed.

[0176] At box 930, the recipe is defined using the operation of each individual component in the microfactory. As mentioned above, the microfactory can contain dozens of robotic units connected by conveyor belts, or it can consist of a single robotic unit.

[0177] At box 940, the system transfers operations to a reference microfactory. A reference microfactory is the construction of a set of digital twin robotic units, and the interconnections between these units. While each digital twin of a robotic unit is independent, the reference microfactory encompasses not only the robotic units but also the component feeders, conveyors, and optionally other devices within the microfactory.

[0178] At box 950, the process is validated on a reference microfactory. In one embodiment, because each robot unit is represented by its digital twin, including its configuration, calibration, and limitations, the reference microfactory is an accurate representation of the physical production line of the microfactory. Once validation is complete (which may require changes to the layout and / or recipe), the process continues to box 960.

[0179] At box 960, configure the actual microfactory and load the recipe onto the microfactory.

[0180] At box 970, the recipe is deployed and a physical microfactory is run. This manufactures or assembles the product. In one embodiment, at box 980, the process on the physical microfactory is continuously monitored and validated on a reference microfactory. In one embodiment, continuous monitoring includes recording status data, sensor data, and operational data from the physical microfactory, referred to as an Internet of Things (IoT) enabled system. Data from the physical microfactory is used to adjust the digital twin to maintain an accurate representation of the physical microfactory. In one embodiment, the system receives data from physical robot units, enabling updates to be deployed to the robot units and thus allowing for remote management of the robot units. In one embodiment, the system analyzes data received from multiple sensors to determine deviations from normal operation of the physical microfactory, updates parameters in the reference microfactory model based on these deviations, and modifies strategies to achieve the microfactory's operational goals to accommodate the deviations from normal operation.

[0181] At box 990, in one embodiment, the process provides an integrated debugger. The integrated debugger utilizes recorded sensor data from continuous monitoring to remotely provide “real-time” debugging, enabling step-by-step execution of recipes for debugging, remote replay debugging, and simulation debugging.

[0182] In one embodiment, this process provides continuous monitoring and debugging, and enables the strategy to be modified as appropriate to achieve the operational goals of the microfactory and accommodate deviations from normal operation. This provides consistent quality and consistency for the microfactory.

[0183] Figure 10 This is a more detailed flowchart of one embodiment of deploying a microfactory. The process begins at box 1005. At box 1010, an operation list is received. In one embodiment, this may be generated by the user. In one embodiment, as discussed above, this may be partially generated automatically. In one embodiment, this may be a previously validated recipe obtained from a marketplace for sharing recipes.

[0184] At box 1015, the number of stations and the function of each station are defined. In one embodiment, a station is an element that performs a specific function or a set of functions, which may be implemented by one or more robot units.

[0185] At box 1020, the devices for each station are defined. These devices are individual robotic units. In one embodiment, the devices can be parallel devices, such as two robotic units performing the same action. These devices can be a series of robotic units performing different parts of the function associated with the station.

[0186] At box 1025, the wiring configuration is laid out. In one embodiment, the wiring configuration is arranged within a virtual system. In one embodiment, this virtualized version of the microfactory is referred to as a reference microfactory, as discussed above.

[0187] At box 1030, the functionality of the microfactory layout is tested using a reference microfactory with a digital twin representation of each robot unit.

[0188] At block 1035, the process determines whether the configuration is optimized. In one embodiment, running a micro-factory layout can identify bottlenecks in the process, such as if some steps take longer than others, slowing down the process. The system can be reconfigured to speed up these parts of the process by reconfiguring the steps for each device, doubling the number of steps on the device, or otherwise changing the layout. Therefore, if one or more such bottlenecks exist, the process returns to block 1025 to reconfigure the wiring.

[0189] If there are no unacceptable bottlenecks in the configuration, the process continues to box 1040.

[0190] At box 1040, assemble the physical circuitry as defined.

[0191] At box 1045, interconnect the components of the physical circuit.

[0192] At box 1050, the devices in the physical circuitry are aligned with the overall system. The system is considered an overall system because not only the individual robot units but also all intermediate and supporting components, such as conveyors, pallet feeders, etc., are part of the system.

[0193] At box 1055, the reference microfactory is calibrated and matched to the physical microfactory. The reference microfactory is designed to match the configuration, calibration, and operation of the physical microfactory. In one embodiment, it is used to test functionality before activation, but also to continuously monitor the physical microfactory to detect deviations from normal operation.

[0194] At box 1060, the recipe is deployed to the microfactory and reference microfactory. The recipe is deployed to each individual robot cell and interconnect element.

[0195] At box 1063, a continuous monitoring system using sensor data including a camera is employed. This can be used for process inspection to identify potential improvements or problems, which may or may not be directly related to the current process. This effectively integrates automated quality inspection throughout the entire process, rather than relying on a final inspection at the end of the process. By integrating the detection steps into the pipeline using existing sensor data, problems can be identified and resolved more quickly. In one embodiment, this monitoring is real-time.

[0196] At box 1065, run the circuit and monitor it against the reference micro-factory. As mentioned above, this can be used to resolve deviations from normal operation, identification errors, or other problems.

[0197] In one embodiment, at box 1070, the circuit is templated. In one embodiment, templated means that a reference microfactory setup is stored, making the microfactory layout available. In one embodiment, such a microfactory layout and associated recipe are commercially available. This allows manufacturers to obtain a complete set of instructions for manufacturing or assembling products, install that set of instructions on an existing set of robotic units in the microfactory, and begin manufacturing very quickly. It also allows manufacturers with multiple sites to create a microfactory at one location, validate it, and then distribute the configuration and recipe to other locations to rapidly increase production. The process then ends at box 1075.

[0198] Figure 11 This is a flowchart of one embodiment of robot cell reconfiguration and version control. The process begins at 1110.

[0199] At box 1125, each robot unit in the microfactory is calibrated, and the calibration is reflected by the associated digital twin. In one embodiment, the system utilizes an automated calibration mechanism, as described in a co-pending patent application entitled "Automatic Calibration System for Robot Assembly" (15000P0105Z), which is incorporated herein by reference in its entirety.

[0200] At box 1130, sensor data and status data are collected from the robot unit while it is operating. Real-time data may include camera data and data from sensors such as temperature sensors, barometric pressure sensors, motion sensors, vibration sensors, laser sensors, ultraviolet sensors, or infrared sensors. In one embodiment, this data is uploaded to a server.

[0201] At box 1132, the process determines whether sensor data and status data indicate the presence of a change in operating conditions that will affect the robot unit. Such changes may include temperature variations, vibration variations, wear, and tear. A problem can be any change in operating conditions that may affect the operation of the robot unit. If present, at box 1134, the process determines whether the robot unit can self-adjust. Self-adjustment is the adjustment of one or more parameters of the robot unit to address the change in operating conditions. If the system can self-adjust, it proceeds at box 1136 and then continues to box 1140. If the system cannot self-adjust to resolve the problem, at box 1138, the system warns the user of the problem. In one embodiment, if the problem is urgent, the process pauses until the problem is resolved. In one embodiment, if the problem is not urgent, the process can continue.

[0202] At box 1140, data from the sensors is sent to the server. Data can also be received from the server. In one embodiment, data is continuously uploaded to the server. In another embodiment, data is uploaded once per second. Data can be received from the sensors when the robot cell configuration needs to be updated or when the robot cell needs to be stopped.

[0203] At box 1142, the process determines whether a configuration update has been received. In one embodiment, a configuration update may be sent to update the process performed by the robot unit. If a configuration update is received, at box 1145, the configuration of the robot unit and its associated digital twin are updated. At box 1150, the configuration version is tracked. That is, in one embodiment, the server monitors for updates and retains all configuration and calibration data for previous versions of the configuration. The process then continues to box 160.

[0204] At box 1160, product quality and configuration are tracked for each robot cell and the entire microfactory line. In one embodiment, the resulting products are tested at the end of the production line to verify their quality. In one embodiment, this information is used to track production quality. In one embodiment, subsequent robot cells can detect problems.

[0205] For example, the first robot unit can connect a slot to a printed circuit board, and the next robot unit can insert a chip into the slot. If the next robot unit detects misalignment or other problems with the slot, product quality tracking can also identify them.

[0206] At box 1170, the process determines whether a production problem has been identified. If no production problem has been identified, the process returns to box 1130 to continue collecting data while the robot cell is operating.

[0207] If a production problem is identified, at box 1175, the process determines whether the problem is caused by a configuration update pushed to the robot unit. If the problem is caused by a configuration update pushed to the robot unit, at box 1180, the update can be rolled back, for example, reversed. Because the system stores the complete configuration of the previous version, the rollback can be completed quickly. In one embodiment, the rollback may not require human interaction. The process then returns to box 1030 to continue monitoring the running robot unit. If the problem is not a simple update issue, the problem is identified at box 1185. The problem can be resolved by replacing hardware components (e.g., replacing the faulty end-effector tool) or by reconfiguring components. In some embodiments, such changes can be made automatically when possible. Otherwise, the user is prompted to make the changes. Once the component has been changed, the process returns to box 1125 to recalibrate the robot unit.

[0208] In this way, the system can continuously monitor the micro-factory, update the robot units as needed, and roll back the updates when necessary.

[0209] Figure 12 This is a block diagram of one embodiment of a computer system that can be used with the present invention. However, it will be apparent to those skilled in the art that other alternative systems with various system architectures can also be used.

[0210] Figure 12 The data processing system shown includes a bus or other internal communication device 1240 for transmitting information, and a processing unit 1210 coupled to the bus 1240 for processing information. The processing unit 1210 may be a central processing unit (CPU), a digital signal processor (DSP), or another type of processing unit 1210.

[0211] In one embodiment, the system further includes random access memory (RAM) or other volatile storage device 1220 (referred to as memory) coupled to bus 1240 for storing information and instructions to be executed by processor 1210. Main memory 1220 may also be used to store temporary variables or other intermediate information during the execution of instructions by processing unit 1210.

[0212] In one embodiment, the system further includes a read-only memory (ROM) 1250 and / or static storage device 1250 coupled to the bus 1240 for storing static information and instructions for the processor 1210. In one embodiment, the system also includes a data storage device 1230, such as a disk or optical disk and its corresponding disk driver, or flash memory or other memory capable of storing data when the system is without power. In one embodiment, the data storage device 1230 is coupled to the bus 1240 for storing information and instructions.

[0213] The system can be further coupled to an output device 1270 for outputting information, such as a cathode ray tube (CRT) or liquid crystal display (LCD) coupled to bus 1240 via bus 1260. The output device 1270 can be a visual output device, an audio output device, and / or a tactile output device (e.g., vibration).

[0214] Input device 1275 can be coupled to bus 1260. Input device 1275 can be an alphanumeric input device, such as a keyboard containing alphanumeric keys and other keys, for enabling a user to transmit information and command selections to processing unit 1210. Further user input device 1280 may be included. One such user input device 1280 is a cursor control device 1280, such as a mouse, trackball, stylus, cursor arrow keys, or touchscreen, which can be coupled to bus 1240 via bus 1260 for transmitting directional information and command selections to processing unit 1210, and for controlling movement on display device 1270.

[0215] Another device that may optionally be coupled to computer system 1200 is a network device 1285 for accessing other nodes of the distributed system over a network. Communication device 1285 may comprise any of many commercially available network peripherals, such as those for coupling to Ethernet, Token Ring, the Internet or WAN, PAN, wireless network, or other methods of accessing other devices. Communication device 1285 may also be a zero-modem connection, or any other mechanism providing connectivity between computer system 1200 and the outside world.

[0216] It should be noted that Figure 12 Any or all components of this system shown herein, as well as the associated hardware, can be used in various embodiments of the present invention.

[0217] Those skilled in the art will understand that a particular machine embodying the invention can be configured in various ways according to a particular implementation. The control logic or software implementing the invention can be stored in main memory 1220, mass storage device 1230, or other storage media locally or remotely accessible to processor 1210.

[0218] It will be apparent to those skilled in the art that the systems, methods, and processes described herein can be implemented as software stored in main memory 1220 or read-only memory 1250 and executed by processor 1210. This control logic or software may also reside on an article of art comprising a computer-readable medium having computer-readable program code embodied therein and readable by mass storage device 1230 and used to cause processor 1210 to operate in accordance with the methods and teachings herein.

[0219] The present invention can also be embodied in handheld or portable devices containing a subset of the computer hardware components described above. For example, a handheld device may be configured to contain only bus 1240, processor 1210, and memory 1250 and / or 1220.

[0220] The handheld device can be configured to include a set of buttons or input signaling components that a user can use to select from a set of available options. These can be considered as input device #1 1275 or input device #2 1280. The handheld device can also be configured to include an output device 1270, such as a liquid crystal display (LCD) or a display element matrix, for displaying information to the user of the handheld device. Such handheld devices can be implemented using conventional methods. Given the disclosure of the invention as provided herein, implementations of such devices will be readily apparent to those skilled in the art.

[0221] The invention can also be embodied in dedicated devices that include a subset of the computer hardware components described above, such as self-service terminals or vehicles. For example, such a device may include a processing unit 1210, a data storage device 1230, a bus 1240, and a memory 1220, and may have no input / output mechanisms, or only basic communication mechanisms, such as a small touchscreen allowing the user to communicate with the device in a basic manner. Generally, the more specialized the device, the fewer components required for its operation. In some devices, communication with the user can be conducted via a touch-based screen or similar mechanism. In one embodiment, the device may not provide any direct input / output signals, but can be configured and accessed via a website or other network-based connection via network device 1285.

[0222] Those skilled in the art will understand that any configuration of a particular machine implemented as a computer system can be used according to a particular implementation. The control logic or software implementing the invention can be stored on any machine-readable medium that is locally or remotely accessible to the processor 1210. The machine-readable medium includes mechanisms for storing information in a machine-readable (e.g., computer-readable) form. For example, the machine-readable medium includes read-only memory (ROM), random access memory (RAM), disk storage media, optical storage media, flash memory devices, or other storage media that can be used for temporary or permanent data storage. In one embodiment, the control logic can be implemented as transmissible data, such as electrical, optical, acoustic, or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.).

[0223] In the foregoing description, the invention has been described with reference to specific exemplary embodiments thereof. However, it will be apparent that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. Therefore, the description and drawings are to be regarded as illustrative rather than restrictive.

Claims

1. A software-defined manufacturing system, comprising: A physical robot unit, the physical robot unit comprising multiple sensors, the physical robot unit being controlled by a recipe instructing the robot unit to perform a process; A memory for collecting operational data from the physical robot unit during the execution of the process, the operational data including the recipe and concurrent data from the plurality of sensors; A processor that implements a digital twin of the physical robot unit, the digital twin being configured with the operational data from the physical robot unit to form a mirror image of the physical robot unit; The recipe is tested on the digital twin, and successful execution of the recipe is verified on the digital twin before it is deployed to the physical robot unit. The digital twin is used to verify and monitor the robot unit; as well as An integrated debugging program is provided to enable debugging of the physical robot unit using the recipe and the operational data. The integrated debugging program is configured to display the step-by-step execution of the recipe and the associated operational data on the digital twin.

2. The system according to claim 1, further comprising: A configuration management system is used to track the configuration of the physical robot unit, deploy updated configurations to the physical robot unit, and roll back the updated configurations from the physical robot unit.

3. The system of claim 2, wherein the configuration of the robot unit comprises hardware, software, settings, and the recipe.

4. The system according to claim 2, further comprising: A deployment management system that enables the deployment of one or more configuration changes to the robot unit, wherein the deployment management system enables deployment to selected one or more robot units via a cloud-based system.

5. The software-defined manufacturing system according to claim 1, further comprising: The physical robot unit uses the sensors for calibration, and the calibration data is used to update the digital twin.

6. The software-defined manufacturing system according to claim 1, further comprising: Development tools, which are used to create the recipe using declarative programming; A compiler, used to compile the recipe into robot commands; as well as One or more drivers, associated with the device of the physical robot unit, are used to translate robot commands into device-specific commands, thereby enabling device-agnostic recipes.

7. The system according to claim 1, further comprising: A programming interface for creating the recipe based on data obtained from the physical robot unit, the programming interface providing an application user interface based on the topology of the robot unit.

8. The system of claim 7, wherein the recipe is compiled into device-specific commands, which enables the use of a heterogeneous set of components within the physical robot unit to extract the recipe from a specific device definition.

9. The system according to claim 1, further comprising: One or more physical robot units in the physical robot unit, the one or more physical robot units defining a physical micro-factory for performing the process; The individual robot units in the microfactory can be reconfigured so that the microfactory continues to operate when a new robot unit is added or removed from the microfactory.

10. The system of claim 1, further comprising: A machine learning and self-improvement system for iteratively changing settings in the robotic unit, monitoring and evaluating the results of the changes, and providing continuous improvement of process parameters.

11. The system according to claim 1, further comprising: An inspection system configured to utilize the sensors in the robotic unit to provide in-process inspections that do not require direct connection to the current process.

12. The system according to claim 1, further comprising: A Design for Manufacturing or Automation (DFMA) system for developing computer-aided design (CAD) data for a product to be manufactured, based on the manufacturing capabilities of the robotic unit.

13. The system of claim 12, wherein the CAD data is refined based on the sensor data and the state data from the physical robot unit.

14. The system of claim 1, further comprising: A portion of the recipe is automatically generated based on data from a computer-aided design (CAD) system, defining the workpiece to be assembled by the physical robotic unit.

15. The system of claim 1, wherein the integrated debugging procedure enables one or more of the following: remote real-time debugging of the physical robot unit using recorded sensor data; reenacting a set of steps on the digital twin using recorded sensor data; and performing simulation debugging on the digital twin.

16. The system of claim 1, further comprising: The digital twin is configured to enable previewing the actions of the physical robot unit during a process, tracking the actions of the physical robot unit during the process, and reviewing the actions after the process.

17. The system of claim 1, further comprising: An integrated debugging program enables step-by-step debugging while controlling the physical robot unit.

18. The system of claim 1, further comprising: A micro-factory, which consists of multiple physical robotic units; A microfactory line based on the formula defined for the plurality of physical robot units, wherein the microfactory line is limited based on the number of available physical robot units and optimized to achieve the shortest cycle time; and The microfactory enables individual robot units to be reconfigured to continue operating when robot units are added to or removed from the microfactory.

19. A software-defined manufacturing system, comprising: A physical robot unit, the physical robot unit comprising multiple sensors, the physical robot unit being controlled by a recipe instructing the robot unit to perform a process; A data aggregation system is used to record the state of the physical robot unit, the state including hardware, software, settings, and the recipe; A configuration and deployment management system is configured to track the configuration of the physical robot unit, deploy configuration changes to the physical robot unit, and roll back the one or more configuration changes from the robot unit when it is determined that one or more configuration changes are negative.

20. The system of claim 19, further comprising: The configuration and deployment management system enables the deployment of one or more configuration changes to selected one or more physical robot units via a cloud-based system.

21. The system according to claim 1, further comprising: The physical robot unit has a network interface that enables the physical robot unit to be upgraded remotely.

Images