Why Design a Scalable Factory? A “conventional automotive” production line has a requirement to produce volumes in the hundreds of thousands per annum which results in an industry average cycle time requirement of 60 seconds, resulting in a product from the production line every minute. This means that all assembly steps of a certain product must be completed within the cycle time. In turn, this usually leads to breaking up the production process into “stations” with one or more production steps performed at each. The number of steps per station is limited by the cycle time and the duration of the individual step. The system is designed so that each station is sufficiently utilized while still achieving the cycle time. If there is an assembly step that can not be completed in the required cycle time, the stations must be duplicated and run in parallel to achieve the target production output. Time constraint is not the only limitation for the number of steps that can be performed per station. In some cases, the complexity (process or equipment) of a specific step in the assembly process may result in the station performing only the assembly step even though the processing time is well below the cycle time. Problems appear when we are asked to provide a lower-volume production system (longer cycle time per product) or a system that can scale up and down by stages or on demand, or, even worse, a system that can produce various products simultaneously and remain efficient. It means such a production system has to be capable of adapting to different cycle times and different sequences (number, types of operations) of production processes. To meet the demands of “low” volume, easily scalable automated production of complex assemblies with low CapEx and in a small footprint factory, we, the Robofacturin team in Arrival UK, had to come up with a new flexible, scalable architecture, which allows us to process a high number of assembly steps using different joining technologies. Mathematically, in the limit, such a system must consist of universal resources (cells) in many-to-many relationships (matrix). On the one side, each such cell (resource) must be capable of performing all (the more, the better) types of operations. On the other side,  every product for assembling (the input to the system) must consist of the same (the fewer different types, the better) parts or granules (pixels). Of course, this is the description of an ideal, unattainable system. We can only try to make a real system closer to the ideal. But it is impossible for traditional factories, in principle, by design - there is a linear sequence of operations and cells, most of which are unique, etc. We found that the best concept from the other industry is a Datacenter that consists of unified blade servers and which can process different types of load (inputs) balancing between resources (servers). This concept requires: Universal multi-task cell (blade server for our "Datacenter") Flexible transportation system (databus for "Datacenter") Design of products maximum closer to the ideal pixel structure (data for our "Datacenter") The is the subject of this article. We will mention the to explain basic principles, but this topic, along with the one, is the subject of separate articles. It is worth mentioning that the third topic, in practice, means finding a design that is most suitable/compatible with such kind of factory. We can call it Design-to-Robofacturing. first point second third Technology Cell (“blade server”) To fulfil the scalable factory production requirements, the production system must be able to perform many diverse operations in one station to assemble a product. These operations can vary from part pick and place operations to applications of adhesives, sealants, and different types of fasteners. A high number of unique parts that the assembled product consists of also present a requirement for the station in the production system to be able to accommodate a large number of tools. In response to these requirements, we designed a robotic cell that accommodates multiple joining technologies and can process any assembly step of a produced product. We named it a Technology Cell or Smart Cell. A is a product and process-agnostic robotic cell that can be used for different processes and products without changing its Core Blueprint. The is a blueprint of the cell that does not include any equipment that would be specific to a certain product or process. Technology cell Core Blueprint For a Technology Cell to be capable of performing the operations required to assemble a product, a Core Blueprint must be equipped with technologies which give the Technology Cell ability to perform assembly operations for a particular product . At this point, the cell becomes technology specific (eg. bolting, gluing) but remains product agnostic. This means it can assemble any product that fits its working volume and is compatible with joining technologies available in the cell. (blue and green objects in the 2nd image below) A Technology cell can also be equipped with another layer of equipment which can be more product or process focused. This additional layer does not hinder the original capabilities of the technology cell, but it extends them to more unique processes that are only needed in specific steps. An example of such a cell would be the Marriage and Glazing features, where a system for the marriage of drivetrain systems and battery pack with the vehicle is permanently located in the cell . (purple objects in the 3rd image above) Creating a Chipset: Building blocks, Applications and Tooling A flexible factory must be capable of dealing with many different products, systems and specific requirements for production: vehicles (from a small car up to a bus), composite panels, small electronic components, battery packs, etc. The nature of the products can differ in many ways: size, complexity (part count, system count), manufacturing method, production volumes, and special environmental requirements. A scalable factory should not only be able to be deployed rapidly but also react to requirement changes quickly. This means that the design process of the factory should be streamlined as much as possible while still allowing for creativity and innovation. To achieve this, we created a modular method for the design of production systems. The method defines requirements for the design of components that form a manufacturing system (eg. robotic cell). As these components have different functionality, they are split into three categories: Building blocks, Applications and Tooling. Building blocks are components that form the lowest of the manufacturing systems and are technology agnostic. They don't have any value-added manufacturing abilities but provide a framework to which we can apply different technologies to give a system process capability. This framework is called a “Core blueprint” and is the first layer of the solution to which the process capability is added. Typical members of this group are all safety-related, geo pallet lifters, geo fixture positioning systems, and robot assemblies. The image shows a Core Configuration of the Production system consisting of Building Blocks only. At this point, the cell is able to accept the layer of applications. Applications are technologies that give a production system process capability. Examples of such applications are adhesive applications, bolting, picking and placing, trimming, handling, machining, scanning, etc. These applications are product-independent, meaning they don't have any features that are specifically designed to accommodate a unique product. The image shows an (applications) layer being added to the Core blueprint of a production system. At this point, the system becomes . At this point, the cell can accept the Tooling layover. Application technology-oriented is a group of components that form a production system that is unique to a specific product. Examples of such components are part grippers, fixtures, product transport pallets, and moulds. As they are an extension of building blocks and applications, they must share the same design architecture that allows us seamless integration. The tooling blocks can be split into two major categories. The mobile product tooling, which flows through the production via autonomous mobile robots and fixed tooling, can be permanently located in a production system to extend its capabilities for a specific process (eg. pallet exchange).  It’s at this point that the production system has a full production capability. Tooling Each Building block, Application or Tooling has everything required to be “plugged in” to a production system from a hardware and software point of view. At the hardware level, we can imagine this as a standardized connector with power and communication terminals that allow a building block, application or tooling to be seamlessly plugged into a production system. The architect of the software level allows the control system to recognize and control each of these groups via the manufacturing execution system. Integrating a building block, application, or tool can be seen as a standard socket and plug connection. The modularity approach sets a design standard that ensures every element can be plugged into any system design. This allows us to quickly configure any production solution by reusing the objects already in our library and assembling them in a new configuration. As visible from the schematics configurations below, there is a large number of shared objects between very different manufacturing systems (robotic cells). If there is a requirement for a significant number of less complex assemblies to be produced in the factory, it may be sensible to create a few simpler, lower CAPEX and footprint cells with architecture better suited to these types of assemblies. Where a manufactured product is more complex, we can configure a system that will be better suited for the complex use case. Transportation System: Autonomous Mobile Robotics The scalable factory operates with a small footprint and a small number of assembly stations that can process a high number of assembly operations. Therefore we had to come up with a method to be able to feed each of these stations with a large number of tools and parts. In a more conventional production system where each station only performs a small number of operations and uses a small number of tools (grippers or joining equipment), these can be permanently located in the station (robot cell) within reach of the robot that handles it. The reach of the robots is in some cases, enhanced using an external linear axis. However, this still does not satisfy business requirements for the number of tools that must be processed in one station (robot cell)  to meet the requirements of the factory. A monolithic production line only has a small number of steps performed at each station. Therefore the number of tools for each station is relatively low. With fewer assembly stations, significantly more tools must be fed to each station. To meet this requirement, our Mobile robotics team developed an autonomous mobile robot called (wheeled mobility) that can deliver any tool to any assembly station.  The robot does not require any modifications to the facility in which it operates. WeMo uses lidars and cameras for navigating through the facility and precise positioning at the locations where its payload has to be precisely dropped off, picked up, or it’s plugging itself into a charging station. WeMo has an integrated lifting capability which allows it to pick up and drop off objects where required. They can operate as an autonomous, independent unit or can connect into “clusters” and work synchronously to move larger and heavier objects when required. WeMo To achieve the ultimate flexibility, we located the tools away from the cells in the logistics area where the operators load the parts into the robot tooling. When the part is required at the assembly station, the manufacturing execution system orders a mobile robot to collect the tool or a part from the logistics area and deliver it to the robot at a precise time without interfering or slowing down the production process. In the case of the Technology cell, the Tools (T) can be delivered to the 4 outboard locations where they can be picked up by a robot. The image above shows only one logistics area where all the tools are located. However, this doesn’t have to be the case. With the use of autonomous robots for the execution of the logistics system, we can arrange the area where tools are located in as many locations as we like. This allows us to optimize the layout for logistics efficiency, environmental requirements of the parts (batteries), and their need for lift assistance. The AMRs are not only tasked with the tool and part delivery to and from the build stations, but also with moving the assembled product between them. The ability of AMRs to autonomously navigate through the facility allows us to be flexible with the positioning of the assembly stations and arrange them in a configuration that meets the factory production requirements. The image shows a cluster of four technology cells that can be used as a production system with two parallel processes with two assembly stations (cell) each or a single four-station production system. Scalable factories are deployed in existing facilities. Therefore, we have to be able to react to any configuration (shape) of the building. With the use of AMRs,  we have more flexibility to utilise the available floor space. The image above shows the cluster of four Technology cells configured in a four station production process. Technology cells are positioned in a configuration that suits the shape of the facility (black outline). Another benefit of not having assembly stations connected via a rigid transport system (eg. conveyor) is that we can be flexible with our production plan. We can feed different products to the same production stations in any order. The image below shows three different routes through the same production system. The black line makes use of all four stations, the green line only utilizes one assembly station, and the blue line utilizes two assembly stations. This allows us to produce different products in the same production line in parallel without any changes being made to the assembly stations. If one cell becomes un-operational, we can reroute the production to a different cell and still operate without stoppage, but at reduced throughput. This is how our Bicseter smart, scalable factory operates, where we produce subassemblies and the main vehicle assembly using the same Technology cells. Software Creation and Deployment Software that runs the factory assembly process is generated autonomously by different internally developed software packages that streamline the process of generating an assembly sequence code that drives each automated action of the production system. The generation process starts with the generation of the Assembly sequence, which is generated from the mBOM of the product. The sequence is then processed by a motion planner and scheduler, which generates all robot trajectories as a sequential flow of operations. The final piece of the puzzle is the Cell operating system which orchestrates all events that are happening in the production process and collects data on the status and quality of the process. The sequence code generation process starts in the Assembly sequence generator software package. To automatically generate an assembly sequence, an mBOM of a manufactured product is uploaded to the generator. Based on the components of the mBOM, the Assembly sequence generator assigns all logistics and assembly operations to each component in the mBOM. Based on the joint/fastener type that is part of the mBOM, the generator assigns the correct joining method and resource to each step in the assembly. The outputted assembly sequence code is then enriched with information about resources that will be tasked with the execution of the assembly process (resources: Cell, robot, Screwdriver, AMR, Gripper…). The final output of the Assembly process generator is a BoP (bill of the process) MetaGraph. The image above shows a section of the BoP MetaGraph. Each step of the process includes information about the process type and all resources that are part of the processing step. At this point, we don't have any actual process code but rather an instruction that the next software package can interpret in the generation process. The generation of BoP in today's industry is still a manual process, usually done by process engineers in a spreadsheet format with supporting visuals for the PLC and Robotics engineers. As with any manual processes, this is prone to mistakes by engineers as it is very labor-intensive. The scheduler and motion planner package have been developed to read the instructions generated by the Assembly sequence generator and, based on its instructions, generate the robot trajectories based on the virtual twin of the resources that participate in a given assembly step (cell, robot, gripper, part, adhesive model). Any CV (computer vision) algorithms are also added to the package at this point. The instructions package with this additional layer is then handed over to the next system, CellOS. The (CellOS) is the system that orchestrates all actions in the production system. The generated Sequential Function Chart and Robot trajectories are processed in the Flow processor and executed. All sequence control logistic is executed via soft PLC. The only system running locally at the production system is a Safety logic of the production stations which the local safety PLC controls to meet the machine safety requirements. cell operating system The assembly sequence is not hard-coded into a local  PLC but it’s rather streamed through the soft PLC, which gives us the flexibility to change the order of operations, build stations or update process parameters without redeploying PLC code. Each building block, application, and tool also have its virtual twin so the software deployment scenarios can be validated before they are deployed. The software of each building block, application or tool is developed alongside their hardware to allow for seamless integration into the system. Therefore each building block and application, and the tool has its associated software block, which allows the Cell operating system to control them (trigger any actions), collect messages, faults, and telemetric data, as well as deploy any process parameters (eg. torque, stroke, angle). This unlocks the ability to be flexible and agile with the implementation of any process or parameter changes. The schematics show the process from the product mBOM, which is being processed in an Assembly sequence generator into a BoP, enriched with motion and process parameters and deployed to CellOS. Once a scenario (assembly process) is deployed to CellOS, there are no further deployments needed unless there is a need for an update of the process. CellOS talks to each element of a production system (Roboti cell) and cell safety individually. Summary As a result, by following the same evolution that transformed a mainframe into a PC, we can significantly decrease the complexity of the architecture of an assembling factory and achieve new characteristics without losing efficiency resulting in: scalability product agnostic smaller footprint simpler design less CapEx But the most important benefit is that new architecture, by design, allows us to implement and use the power of Artificial intelligence software. This can make our factory smart.

The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch

This story contains new, firsthand information uncovered by the writer.

Architecture Design of a Smart, Scalable, AI-driven Robotic Production Factory

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Implementation of Mobile Robots for an Autonomous Scalable Smart Factory

The Hidden Ledger of Code: Tracking the Carbon Debt Inside Our Software

Roba Shatters Closed Systems: The People's Robotics Platform Launches To Dominate $218b Industry

The History and Future of CAD in Engineering

Tesla Rolls Out Cheaper EVs, But Prices Fail to Excite Market

Why Over-Caching Can Be Just as Bad as No Caching

Implementation of Mobile Robots for an Autonomous Scalable Smart Factory

The Hidden Ledger of Code: Tracking the Carbon Debt Inside Our Software

Roba Shatters Closed Systems: The People's Robotics Platform Launches To Dominate $218b Industry

The History and Future of CAD in Engineering

Tesla Rolls Out Cheaper EVs, But Prices Fail to Excite Market

Why Over-Caching Can Be Just as Bad as No Caching

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps