Robotic production environment for vehicles

Abstract

A vehicle robotic production environment in which the environment hosts robot agents that are organized into monads, each monad having no more than 10 robots. A set of robot monads transform fabric into vehicle composite panels and other parts, eliminating the need for steel panel press equipment. Other robot monads assemble at least a portion of a vehicle together from modular components, such as aluminum extrusions. Each monad is served by an AMR (autonomous mobile robot), eliminating the need for expensive mobile production lines. The robotic production environment can be implemented or installed in a plant having an area of less than 25,000 square meters, with a conventional flat concrete floor that is not reinforced for vehicle body panel stamping machines. Conventional vehicle production plants typically exceed 1M square meters in area and have specially reinforced concrete floors.

Description

Technical Field

[0001] This disclosure relates to robotic production environments for vehicles, and systems and methods for assembling vehicles designed for robotic production. It also discloses methods for efficiently customizing specific vehicle components (such as composite panels) and entire vehicle families to meet customer requirements using automated vehicle design tools.

[0002] In this specification, we use the term "vehicle" extensively to encompass any item that can move or transport people or goods, for example, on roads, rails, in the air, or at sea; this includes manually driven vehicles; vehicles with SAE (J3016) Autonomy Level 0-5; and drones. It includes cars, shuttle buses, trucks, vans, buses, trains, trams, boats, hovercraft, and aircraft. Zero-emission electric vehicles are a key focus. Background Technology

[0003] Creating a sustainable environment (especially in urban areas) will require extensive vehicle innovation; vehicles will need to be zero-emission or low-emission, but will need to be designed to be manufactured to achieve purchase parity with conventional internal combustion engine (ICE) vehicles, despite including very expensive battery packs or fuel cells.

[0004] Ideally, the next generation of vehicles will be intentionally built to meet specific market demands or customer requirements; the implicit requirement of this goal is that even with relatively low production volumes (e.g., 10,000 vehicles per year), these vehicles will need to be designed to be manufactured in order to achieve purchase price parity with conventionally manufactured vehicles.

[0005] Achieving these goals is particularly challenging if we consider specific vehicle segments: battery-powered zero-emission electric vehicles, vans, and buses. Under current vehicle design and manufacturing paradigms, price parity for low-volume ICE vehicles targeting specific niche markets is impossible, with design and development times of 3-5 years and investments exceeding €1 billion. This convention inevitably requires factories producing a single vehicle type, using mobile production and assembly lines, which necessitates substantial capital investment and massive facilities (1M+ square meters). A further example: the convention also requires the use of stamped steel or aluminum sheets. Stamping requires enormous matching steel tools (dies used to press sheet metal into shape); in a process known as incremental stamping, a single part typically requires several pairs. Designing these tools can take a year or more; due to their weight and the considerable forces they exert (e.g., over 200 tons), special reinforcement and expensive foundations are required. Setting up a production line typically costs tens of millions of dollars; then months are needed to tune the line. To recoup the investment, metal stamping lines are dedicated to a single product for many years.

[0006] Once completed, the stamped metal bodies are welded together to form the familiar “white body” (BIW). Welding fixtures and robots are dedicated to individual products; this further increases time and investment. Next, the metal must be protected from the atmosphere. This requires a large painting setup starting with the electrocoating line, which is perhaps the most significant investment in the paint shop due to the size of the boxes needed to fully immerse the BIW. Subsequent paint layers are then built on top to produce the finished vehicle. Therefore, paint shops in automotive factories are very expensive and require environmental permits, which can significantly slow down the factory construction process and limit the location where a factory can be built.

[0007] Therefore, this conventional approach has locked onto specific vehicle designs for years, including specific battery pack and vehicle body panel designs, resulting in vehicle designs that can only slowly respond to the new and severe environmental and urban transportation challenges we face today, and equally slowly respond to users' growing demand for engaging, safe, and zero-emission transportation environments. Under the current vehicle design and manufacturing paradigm, small-batch production vehicle processes designed to meet emerging specific customer needs (e.g., buyers wanting to purchase fleets of 1,000 buses or 10,000 delivery vans customized to their specific requirements) are not feasible.

[0008] Attempts to reuse existing vehicle design and manufacturing paradigms for zero-emission vehicles often result in vehicles that are more expensive than their internal combustion engine counterparts, have lower profit margins (and often operate at a loss), require significant initial investment and capital expenditure, need very high levels of mass production to generate profit, and are often not well-suited to the specific needs of fleet customers and individual users because they are not mass-produced products tailored to meet specific requirements.

[0009] See PCT / GB2018 / 052415 for reference, the contents of which are incorporated herein by reference. Summary of the Invention

[0010] The present invention is defined in the appended claims. An example embodiment is... The Arrival system comprises a vehicle-robot production environment that hosts robot agents organized into individual units, each unit containing no more than 10 robots, wherein:

[0011] (i) A set of monomers transforms the fabric into vehicle composite panels and other parts, eliminating the need for steel panel pressing equipment.

[0012] (ii) Other units assemble at least a portion of the vehicle from modular components; and

[0013] (iii) Each unit is served by an AMR (Autonomous Mobile Robot), eliminating the need for mobile production lines in the production environment.

[0014] Some optional features include the following:

[0015] • The production environment is located in a factory or factory network with an area of ​​less than 25,000 square meters each.

[0016] • The production environment is located in a building with a standard flat concrete floor that has not been reinforced for the vehicle body panel stamping machine.

[0017] • Some of the units are configured to convert fabric into colored vehicle composite panels and other parts, eliminating the need for the type of paint shop required for painting conventional pressed steel parts.

[0018] Each unit comprises a group of robots programmed to assemble at least a portion of a vehicle at a fixed location rather than on a moving production line by linking together multiple modular components, each designed or selected for robotic production, handling, or assembly; and the units together essentially assemble the entire vehicle.

[0019] Each unit includes a group of robots programmed to assemble at least a portion of a vehicle at a fixed location rather than at a moving production line by: (a) linking multiple components together to form a structural chassis and a main body structure, and (b) adding composite body panels and composite roof panels to the main body structure, and all components and panels are designed or selected for robot production, handling or assembly.

[0020] Arrival's robotic production environment is reconfigurable:

[0021] The robotic production environment is configured to assemble at least one of the following vehicle types: small passenger cars, large passenger cars, small vans, large vans, specialty vans, trucks and vans of varying lengths and capacities, buses of varying lengths and capacities, and multiple units therein can be reused as part of a set of units for the production of any of these types of vehicles.

[0022] • The robotic production environment is configured to be automatically reconfigured through software-implemented changes to automatically perform the following operations: manufacturing different parts, assembling different types of vehicles, assembling different configurations of the same type of vehicle, using different assembly techniques, using different components, or using alternative physical routes to transport vehicle parts or structures through the physical environment of the factory.

[0023] • The robot production environment can be automatically reconfigured through software-implemented changes that alter one or more of the following: the functionality of the robot agents, the physical location or arrangement of the robot agents, the number of operable robot agents, and the route taken by the AMR.

[0024] Arrival's robot production environment has a specific layout:

[0025] • The production environment for vehicle robots has a layout or arrangement of individual units positioned on a standardized linear grid.

[0026] • The physical layout or arrangement of individual units in the robot production environment has been planned by an automated layout design tool, which determines the optimal or preferred layout or arrangement of the units and the robot services performed by each unit.

[0027] • The layout or arrangement of individual units in the environment has been designed by an automated simulation tool that takes into account parameters including: production cost; production time; production quality; component availability; and the use of AMR to transport components and sub-assemblies.

[0028] • The robot production environment is configured as a model or map including its physical environment, which is generated, enhanced, or refined in real time by the AMR and the robot using at least SLAM computer vision technology.

[0029] The robot production environment includes a master semantic model of its physical environment, which enables AMRs and robot agents to correlate with the functionality or other properties of the stationary and dynamic objects they detect at the semantic level.

[0030] • An automated layout design tool determines the layout or arrangement of individual units and the robot services performed by each unit using a simulation. The simulation includes a simulation using a robot service control system, and the robot service control system used in the simulation is also used to control the robot services in a real-world robot production environment.

[0031] This document is organized as follows:

[0032] Background Art (Pages 1-3)

[0033] Invention content, pages 3-5

[0034] The accompanying diagrams are on pages 6-7. Detailed Implementation

[0035] Advanced Overview of the Arrival System (Pages 8-15)

[0036] Chapter A: Hardware Modularization; Unified Hardware Platform. Pages 16-50

[0037] Chapter B: Software Modularization; Unified Software Architecture and "Plug and Play" Approach. Pages 51-83

[0038] Chapter C: Arrival Network Security System. Pages 84-97

[0039] Chapter D: Arrival Technology Platform: Creating New Vehicle Designs Using Vehicle Builder Tools. Pages 98-119

[0040] Chapter E: Robotic Manufacturing: Robotic Data-Driven Continuous Delivery Production. Pages 120-156

[0041] Chapter F: Arrival - Miniature Factory. Pages 157-193

[0042] Chapter G: Arrival Battery Modules and Flexible PCB Connectors. Pages 194-226

[0043] Chapter H: Arrival Composite System. Pages 227-290

[0044] Chapter I: Arrival Van System. Pages 291-342

[0045] Chapter J: Arrival Bus System. Pages 343-434

[0046] Chapter K: Arrival Car System. Pages 435-483

[0047] Appendix 1, Chapter A: Pages 485-499

[0048] Appendix 1, Chapter B: Pages 500-517

[0049] Appendix 1, Chapter C: Pages 518-522

[0050] Appendix 1, Chapter D: Pages 523-539

[0051] Appendix 1, Chapter E: Pages 540-545

[0052] Appendix 1, Chapter F: Pages 546-571

[0053] Appendix 1, Chapter G: Pages 572-577

[0054] Appendix 1, Chapter H: Pages 578-606

[0055] Appendix 1, Chapter I: Pages 607-621

[0056] Appendix 1, Chapter J: Pages 622-662

[0057] Appendix 1, Chapter K: Pages 663-681

[0058] Claims: Pages 682-691 Attached Figure Description

[0059] As described above, one embodiment of the present invention is found in the Arrival system. Detailed implementation of the Arrival system will be described in the following section AK:

[0060] Chapter A: Hardware Modularization; Unified Hardware Platform: See Figures 1-17 .

[0061] Chapter B: Software Modularization; Unified Software Architecture and "Plug and Play" Approach: See Figures 18-39 .

[0062] Chapter C: Arrival Network Security System: See Figures 40-44 .

[0063] Chapter D: Arrival Technology Platform: Creating New Vehicle Designs Using Vehicle Builder Tools: See Figures 45-47 .

[0064] Chapter E: Robotic Manufacturing: Robotic Data-Driven Continuous Delivery Production: See Figures 48-58 .

[0065] Chapter F: Arrival Miniature Factory: See Figures 59-68 .

[0066] Chapter G: Arrival Battery Modules and Flexible PCB Connectors: See Figures 69-76 .

[0067] Chapter H: Arrival Composite System: See Figures 77-85 .

[0068] Chapter I: Arrival Van System: See Figures 86-105 .

[0069] Chapter J: Arrival Bus System: See Figures 106-175 .

[0070] Chapter K: Arrival Car System: See Figures 176-184.

[0071] Each chapter of AK follows the same format: first, an introduction; then, illustrations related to the chapter; next, a list of key features related to the chapter; and finally, a more detailed consideration of these features. Appendix 1 integrates all these features and various optional sub-features. Detailed Implementation

[0073] A high-level overview of the Arrival system

[0074] Arrival is a system for designing and manufacturing a range of different vehicles, such as cars, shuttles, trucks, vans, and buses, using a modular, shared platform and shared components. Arrival also enables autonomous robotic production, including the robotic production of the entire vehicle and its components.

[0075] This specification describes many features; we have organized these features into the following sections AH.

[0076] Chapter A: Hardware Modularization: Unified Hardware Platform

[0077] Chapter B: Software Modularization: Unified Software Architecture and "Plug and Play" Approach.

[0078] Chapter C: Arrival Network Security System.

[0079] Chapter D: Arrival Technology Platform: Creating New Vehicle Designs Using Vehicle Builder Tools.

[0080] Chapter E: Robotic Manufacturing: Robotic Data-Driven Continuous Delivery Production.

[0081] Chapter F: Arrival Miniature Factory

[0082] Chapter G: Arrival Battery Modules and Flexible PCB Connectors.

[0083] Chapter H: Arrival Composite System.

[0084] Chapter I: Arrival Van System.

[0085] Chapter J: Arrival Bus System.

[0086] Chapter K: Arrival Car System.

[0087] Chapter A: Hardware modularity is one of the key enabling technologies in the Arrival system because it allows for the reuse of the same type of modular components in multiple locations within any given Arrival vehicle; this type of component reuse is crucial for reducing component costs and simplifying robot assembly. An example: Arrival vehicles are assembled from aluminum extrusions of a certain length; these extrusions can be used in different parts of the vehicle chassis.

[0088] Chapter B focuses on software modularity (including "plug and play" and decentralized autonomy in distributed architectures). For example, software modularity allows modular software components to be deployed to and run on an ECU (Electronic Control Unit). One example: a software component might be associated with an optional feature, such as lane departure warning; by modularizing the software that enables this function, it can be added to the appropriate vehicle system only when needed. Modularity of ECU (Electronic Control Unit) embedded software enables the customization of software based on the individual needs of different ECUs and their tasks within the vehicle architecture.

[0089] Chapter C: Arrival vehicles use a specific safety architecture that is more robust and secure than conventional architectures; this is especially valuable when the vehicle implements a modular plug-and-play approach.

[0090] Chapter D: All of these preceding sections come together in the Vehicle Builder Design Tool; the Vehicle Builder Design Tool includes a data repository that defines all components available in a unified software architecture and a unified hardware platform, and is capable of automatically designing complete vehicles, including ECU software configurations, by assembling components that meet specific customer requirements.

[0091] Chapter E describes robotic manufacturing—a set of technologies that enable efficient and scalable robotic production.

[0092] Chapter F describes a microfactory, a relatively small and low-capital-expenditure (CapEx) factory that is not based on a conventional, long-moving production line, but rather a robotic production environment. This environment comprises small, autonomous or semi-autonomous robots, each assembling various sub-components (e.g., adding composite panels to the main frame) and various elements (e.g., chassis, drive train, wheels, HVBM, body) to form a complete individual vehicle. In the Arrival system, only a few different types of robots are capable of producing an entire vehicle; different robots of the same type can be used in different orders; and robots can be quickly reused from one specific task for another. This approach provides a degree of flexibility and scalability that is impossible with conventional mobile production line systems. The microfactory receives data defining the vehicle to be assembled from vehicle builder tools (see Chapter D) and can then automate all the steps required to assemble the vehicle using a robotic manufacturing process (see Chapter E). Because the unified software architecture and unified hardware platform have been designed to ensure that all compatible software and hardware will work reliably together, once all hardware and software components are correctly installed in the vehicle and communicating with each other, the vehicle's critical components should function as expected.

[0093] Chapter G describes the modular battery system and flexible PCB high-voltage conductor developed by Arrival and used in several Arrival vehicles.

[0094] In Chapter H, we describe the Arrival composite panel system, which enables the rapid and inexpensive manufacture of high-performance, lightweight automotive composite panels without the need for expensive metal stamping presses and conventional painting setups. We describe how composite automotive body panels (and other parts) are manufactured, and how the composite panel production system forms part of the overall Arrival system.

[0095] Chapter I describes the Arrival van system; the Arrival van is optimized for improved driver ergonomics.

[0096] Chapter J describes the Arrival bus system; the Arrival bus is a low-floor bus optimized for an improved driver and passenger experience. Chapter J also describes how the Arrival bus architecture is assembled in a micro-factory.

[0097] Chapter K describes the Arrival car system; the Arrival car is a flexible, skateboard-based system that supports a variety of different car types.

[0098] Furthermore, we can move through this sequence: taking the Arrival van (described in Chapter I) as our context: the Arrival van can incorporate or otherwise implement the hardware modularity described in Chapter A; can incorporate or otherwise implement the unified software architecture, plug-and-play, and decentralized autonomy described in Chapter B; can incorporate or otherwise utilize the security architecture described in Chapter C; can be configured using the vehicle builder tools described in Chapter D; can be built using the robotic manufacturing process described in Chapter E; can be manufactured in the micro-factory described in Chapter F; can incorporate the battery modules and flexible PCB connectors described in Chapter G; and can include composite panels and components described in Chapter H.

[0099] Arrival systems can be considered part of a “machine that can build machines”; the effective and practical realization of a true “machine that can build machines” requires this complex, interdependent combination of multiple characteristics. The full realization of the goals of fast, responsive, low-cost, and low-capital-expenditure vehicle design and construction can be considered an emerging property of this complex system; like any complex system, each component in this system contributes synergistically to the whole.

[0100] The Arrival system leverages several macro-technological trends. Firstly, Arrival utilizes the rapid advancements in robotic AI in the design and deployment of distributed, scalable, flexible AI and robotic-based production systems (“robotic manufacturing,” deployed in “micro-factories”). This enables the rapid design and cost-effective production of equipment, with zero-emission vehicles being just one example. If we focus specifically on zero-emission vehicles, the Arrival system disrupts the current vehicle design and manufacturing paradigm (which requires 3-5 years of design and development time and over €1 billion in design and development investment). Instead, the Arrival system serves as a flexible vehicle development platform, enabling the intentional construction of various zero-emission vehicles to meet specific market demands or customer requirements, even in relatively low quantities (e.g., producing 1,000 buses annually from a micro-factory) at cost par with conventionally manufactured internal combustion engine vehicles, all within a small footprint and with relatively low capital expenditures in a micro-factory.

[0101] In terms of capital expenditure, the microfactory approach is significantly cheaper than a mobile production line factory, meaning that much lower annual production volumes can still be profitable, enabling the implementation of fleet-specific designs for customers. However, microfactories can be easily scaled up by adding additional robotic production units, or scaled down as needed, or switched to different vehicle designs. Microfactories are described in more detail in Chapter F, but in short, a microfactory consists of multiple robotic production units, each containing one or more robots (potentially autonomous or semi-autonomous) that can be specialized or optimized for a specific function or class of functions, or be general-purpose. Instead of being connected by a mobile production line, automated guided vehicles move the chassis or other vehicle components being assembled from one unit to another until the vehicle is fully assembled. AMRs supply components to the units. Conventional production lines are costly, slow, and expensive to plan and build, and lack flexibility once set up: Arrival's robotic production units are far more flexible—for example, production processes can be quickly reconfigured to use units in different sequences (e.g., if a component in a unit is underutilized, or if a unit requires maintenance, the process can be reconfigured to compensate for it almost immediately); furthermore, the same unit can be reused multiple times for different assembly operations of the same vehicle. If the micro-factory needs to switch to building different types or designs of vehicles (replacing or attaching to vehicles currently being built), this can be achieved through operations performed on virtually each unit. This is achieved quickly by manufacturing and reprogramming the components provided to each unit. The microfactory can be located in a standard 100,000-square-foot warehouse; it doesn't require a specialized painting workshop because the vehicles it assembles use composite panels that are colored as part of the panel production process or have a colored vinyl or plastic coating; eliminating a specialized painting workshop not only saves space but also eliminates the need for environmental controls and permits. The use of composite panels means the microfactory doesn't require a sheet metal stamping plant with a special foundation. Therefore, its planning and construction are much simpler—typically requiring 6 months for commissioning compared to 3 years for a conventional plant, and demanding only 1 / 10th of the capital expenditure.

[0102] Because microfactories are significantly smaller than conventional vehicle factories (1M+ square meters) (e.g., 10,000-25,000 square meters), they can be built anywhere in the world where demand is needed, enabling rapid establishment of local operations with shorter supply chains, enhanced local employment, a stronger local tax base, and further reduced carbon footprint by eliminating the need for ocean-going containers. Microfactory production using small robotic units requires a complete rethinking of how vehicles should be designed: this robotic production design is central to the Arrival system. Conventional robotic vehicle manufacturing requires a significant investment in arrays of robots along a moving production line, each performing a number of highly repetitive, pre-programmed tasks; this very approach is equivalent to an automated process otherwise undertaken by skilled assembly line workers. The Arrival system goes beyond simply automating repetitive, pre-programmed tasks using robots; it creates an autonomous robotic production environment (or “robot microfactory”) that operates without predefined cycle times and is capable of dynamically determining which robots (or “robot agents”) or non-robot agents perform which steps and when, how robot agents interact with each other and external agents, how to quickly arbitrate potential conflicts between agents (e.g., conflicts in the path traced by the end effector of a robot arm in a single robot unit or the path of a mobile robot that might lead to a collision), and how to optimally assemble parts and even entire vehicles. The Arrival system also uses machine learning / AI processes to learn, enabling autonomous operation to improve over time, for example, in terms of speed and accuracy. The evolution from robotic automation to robotic autonomy will be one of the defining characteristics of the emerging wave of industrial innovation. While this specification focuses on the robotic production of vehicles and vehicle parts, the principles of the Arrival system are equally applicable to any project capable of robotic production; therefore, the term “vehicle” can be interpreted, in extreme cases, to encompass any project that is robotically produced; for example, it could cover buildings constructed by robots and the parts of those buildings.

[0103] Before we delve into these chapters on AK, we'll offer some initial comments on modularity. The concept of modularity is a core philosophy of Arrival. It influences everything from how Arrival designs components and assembles vehicles to how it organizes its business activities. Modularity is typically discussed in terms of modules (hardware, software, teams, etc.), which can be modified or replaced without affecting the rest of the system (vehicles, products, company, etc.).

[0104] Arrival modules are constructed from standardized units (size, interfaces) for flexibility and versatility in use. Standardized interfaces enable modules to connect, interact, or exchange resources (such as energy or data). By defining standard units and interfaces, modules can operate with little or no knowledge of the definitions of other individual components. Such modules are less constrained and more general-purpose. Systems composed of loosely coupled modules are more robust to change, flawed design, and failure; therefore, they are not like tightly integrated systems where each component is designed to work specifically (and often proprietaryly) with other specific components.

[0105] Modularization enables Arrival to build scalable, robust products and systems that respond to errors and failures and capitalize on uncharted future opportunities. Each module includes one or more distinct functions (purposes), and modules can be combined to provide new collective functionality. Modules may require capabilities that other modules fulfill. Modularization enables parallel processing; a production / design / work approach where the process is divided into parts that can be done in different orders, in different places, or using different strategies. Modularization accelerates the design process and makes it more reliable. Modules can be applied to different scenarios; modularization facilitates reuse in new contexts. Modularization provides flexibility because different components can be easily mixed and matched in various configurations. Modules hide the details of their implementation but publicly define their capabilities and interfaces. Modularization leads to simplicity: breaking down a system into varying degrees of interdependence and independence reduces system complexity. Modularization allows components to be replaced with alternative implementations that provide the same service. Modularization accommodates uncertainty because specific elements of a modular design can be changed retrospectively and in unpredictable ways, provided design rules are followed. Modularization reduces risk because modules can be tested and run in isolation.

[0106] Decentralized autonomy in a distributed architecture is a key complementary approach used in the Arrival system. Simple rules (simple devices, interfaces, and agents) can lead to complex and robust systems. The concept of distributed devices enables reliable, secure, and predictable fault-tolerant behavior, even in dynamic systems with frequent component changes and incomplete information (high uncertainty). Arrival needs a method that can gracefully handle errors and new information and facilitate rapid development, iteration, and continuous improvement. Decentralized autonomy is Arrival's mechanism for reducing the time required to develop and validate new hardware devices, software functions, and products while achieving consistent and reliable performance and high security.

[0107] Arrival Distributed Architecture System:

[0108] The system consists of distributed autonomous devices and is largely without central coordination / management.

[0109] The system can include different (and dynamic) types of devices and network links.

[0110] • The system and its functions are agnostic to hardware, software, or communication protocols (independence).

[0111] Self-contained, trustless devices communicate with each other on a secure network via messaging.

[0112] • Devices are responsible for their own safety, which means that malfunctions or incorrect commands are unlikely to cause serious problems.

[0113] • No prior knowledge of the overall or “final” structure (number and type of equipment, topology) is required.

[0114] The system addresses design and functional changes and uncertainties. Devices can be modified, added, and removed without affecting other modules: simplifying design, configuration, testing, verification, and validation.

[0115] This architecture facilitates new, iterative, improved, and disruptive hardware devices / software / functionality / architecture / control in the future.

[0116] The system is reliable and robust; it incorporates faults / errors and avoids single points of failure (fault tolerance). The system tolerates individual failures (of devices or messages). Fault containment and pollution reduction are implemented. Malicious actors are excluded. Isolation is employed.

[0117] The system is highly scalable and can operate efficiently even as new equipment grows (automatically).

[0118] • Increase performance by reducing overhead (shared computing resources).

[0119] • Security (against malicious actors with faulty credentials). Valuable / security-critical messages (or data) are protected. Few vulnerabilities. Each device has a limited and incomplete view (and control) of the system.

[0120] • This architecture supports granular / regional control, allowing continuous operation even when some devices are asleep / offline / fail.

[0121] Require

[0122] Each device is uniquely identifiable.

[0123] • The network is scalable and secure

[0124] • The equipment is responsible for its own safety.

[0125] Our design and production methods must enable this approach.

[0126] • Starting with an advanced introduction to Arrival's modular and distributed architecture approach, we now move into the details.

[0127] Chapter A: Hardware Modularization; Unified Hardware Platform

[0128] Introduction to Chapter A

[0129] The core objective of the Arrival system is to transcend existing vehicle design and production paradigms. As we have seen, the conventional paradigm is exemplified by traditional pressed steel monocoque bodies, which gradually transform into finished vehicles as they move along a mobile production line in a 2+ square meter factory—a factory that cost over $2 billion to build and locked into building essentially the same vehicles for years to recoup the massive investment in plant and tooling. Conventional vehicle design can only respond slowly to the severe environmental and urban transportation challenges we now face, and just as slowly to the growing demand from users for engaging, safe, and zero-emission transportation environments. Current vehicle design and production paradigms cannot enable small-batch production runs designed to meet emerging, specific customer needs—for example, a buyer wanting to purchase a fleet of 1,000 buses or 10,000 delivery vans tailored to their specific requirements.

[0130] The Arrival system is designed to address these challenges: it proposes a holistic and fundamental re-evaluation of how to design and manufacture connected vehicles. Arrival vehicles are designed to meet several specific and challenging objectives: (a) to be made from modular hardware components optimized for robotic production, handling, and assembly; (b) to be rapidly designed and configured using the same automated vehicle design tools (see Vehicle Builder Tools in Chapter D); (c) to be built using the same robotic production techniques regardless of vehicle type (e.g., whether it's a car, van, or bus) (see Chapter E); and (d) to be built in the same robotic production environment capable of producing any type of vehicle without costly retooling or redesigning the robotic production environment (see Chapter F).

[0131] Hardware modularity or standardization is a core enabling technology for achieving these goals. While a degree of hardware modularity has been established in mass production of vehicles since the Model T (and also in other areas, such as Le Corbusier's), the Arrival system extends the concept of hardware modularity to include many specific functions that enable the achievement of these goals.

[0132] This section A focuses primarily on modular or standardized hardware components. Later in this document (Section J), we will see how the Arrival bus is assembled from a series of 1.5m long chassis segments; a 12m bus will have seven 1.5m long chassis segments, plus a front and rear segment. This means that each of these seven chassis segments has structural components that make up the skateboard platform, each component being identical and 1.5m long; the superstructure on the skateboard platform will again have many identical 1.5m long beams or struts. Each of these is handled, assembled, and connected robotically in the same way, and each is optimized for robotic handling (e.g., extensive use of lightweight extruded aluminum struts with simple male-female mating parts that can be robotically pushed together; then, adhesive is robotically injected into the joints to permanently attach the components together; no welding is required).

[0133] This level of hardware modularity, optimized for robotic handling, is key to delivering various economies of scale typically achieved through press-fit steel monocoque chassis. Standardizing this 1.5m length means that each full-color, high-resolution display panel extending along the side of the Arrival bus is also the same length (slightly less than 1.5m); each bus can have 18 such display panels, thus simplifying logistics with a single model of display panel, and also simplifying robotic handling and installation, as the same handling and installation process is repeated 18 times for each bus. Furthermore, by standardizing this 1.5m length, each composite main panel in these segments is also approximately that size, again simplifying composite panel production, logistics, and robotic handling and installation, as the same handling and installation process is repeated for each panel; the Arrival bus can have 24 or more side panels of the same size, thus the economies of scale associated with this level of modularity or standardization of composite panel size are highly valuable.

[0134] Therefore, modular or standardized hardware components may include structural items and physical fasteners, such as: (a) aluminum extrusions, which form parts of the vehicle body structure and parts of the vehicle chassis (or skateboard platform); (b) cast aluminum structural wheel arches with mounting points for suspension and integrated drive units (which may include inverters, motors and gearboxes), eliminating the need to mount these components to a separate chassis; (c) composite panels; and (d) physical fasteners and fittings for attaching components together.

[0135] Later in this document (Section G), we will see how Arrival vehicles can utilize multiple modular high-voltage battery modules, called HVBMs. These are each 350mm square and 100mm high, with flat surfaces that are easy for robots to grip, and can be assembled together into an array of adjacent modules; because each HVBM delivers approximately 400V, they can be connected in parallel in any number; this means that battery packs with different capacities and driving ranges can be easily produced by using different numbers of HVBMs, and due to the standardized size adjustment of the modules, it becomes much easier to design the way these HVBMs are robotically installed or positioned in vehicle chassis or skateboard platforms common to different Arrival vehicles (e.g., the same in Arrival sedans, vans, and buses).

[0136] Therefore, modular or standardized hardware components can include electronic modules, such as any of the following: high-voltage battery modules; battery packs; main BMS; low-voltage batteries; on-board chargers; charging controllers; DC-DC converters; integrated drive units; motors; gearboxes; traction inverters; drive control units; communication modules; ECUs; Ethernet switches; HMI platforms; video surveillance systems; vehicle audio engine platforms; unified computing platforms; sensors; weight sensors; computer vision sensors; LiDAR sensors; and radar-based sensors.

[0137] Here we list how Arrival components are modularized or standardized:

[0138] Vehicle components are modularized or standardized in a manner that conforms to regular size intervals, and the vehicle component is part of a series of other types of components, all of which are sized according to the same size intervals. Standardized size intervals: (a) enable faster organization of component layout and vehicle design in software tools, as these tools require fewer calculations of arrangement; (b) enable more efficient use of space within the Arrival vehicle, as modules can be packed more tightly and neatly; and (c) facilitate computer vision recognition of component position and orientation, as well as robotic handling and assembly of components.

[0139] Vehicle components are modularized or standardized as part of a series of other types of components, all configured to be positioned or mounted in the vehicle in a regular linear grid or mounting pattern. This also: (a) makes organizing component layout and vehicle design in software tools faster, as the tools have fewer arrangements to compute; (b) enables more efficient use of space within the Arrival vehicle, as modules can be packed more tightly and neatly; and (c) facilitates computer vision recognition of component positions and orientations, as well as robotic handling and mounting of components.

[0140] Vehicle components are modularized or standardized as part of a family of other types of components, all of which have one or more external features optimized for robotic handling, installation, or assembly (such as autonomous robotic handling, installation, or assembly) (e.g., flat surfaces; surfaces that are difficult to grip without rounding; vertical edges). This facilitates computer vision recognition of the component's position and orientation, as well as its robotic handling and installation.

[0141] Vehicle components are modularized or standardized as part of a series of other types of components, all sharing the same overall shape type (e.g., box shape). This series includes two or more of the following: battery modules; main BMS; low-voltage batteries; on-board chargers; charge controllers; DC-DC converters; integrated drive units; traction inverters; drive control units; communication modules; Ethernet switches; HMI platforms; video surveillance systems; vehicle audio engine platforms; unified computing platforms; sensors; weight sensors; computer vision sensors; LiDAR sensors; and radar-based sensors. This also: (a) makes organizing component layouts and vehicle design faster in software tools, as these tools require less computation of arrangement; (b) enables more efficient use of space within the Arrival vehicle, as modules can be packed more tightly and neatly; and (c) facilitates computer vision recognition of component positions and orientations, as well as robotic handling and installation of components.

[0142] Vehicle components are modularized or standardized as part of a series of other types of components, all designed with mounting paths optimized for robotic handling, installation, or assembly (such as autonomous robotic handling, installation, or assembly). This, in turn, may require careful design of the center of mass and the robot's gripping points for grasping the components, ensuring that the components can be reliably secured by the robot as they move through space.

[0143] Vehicle components are modularized or standardized as part of a series of other types of components, each using the same standardized physical mounting system, and each optimized for robot handling and use. This reduces costs and inventory management complexity, and decreases the range of different tools or end effectors required, thus accelerating assembly.

[0144] Vehicle components are modularized or standardized in a way that they are part of a series of other types of components, each using the same standardized identification system that provides a unique identifier for each individual component. This identifier is (i) computer-readable but meaningless to humans; and (ii) enables the tracking of each individual component from initial production to initial installation and subsequent maintenance and end-of-life. Eliminating human-readable text provides greater control because the unique identifier can point to a server-side entry and access to it can be controlled.

[0145] Vehicle components are modularized or standardized in a way that they are part of a series of other types of components, each using the same standardized data and / or power interfaces. This facilitates automated planning of electrical / data layouts and also facilitates the robotic installation of modules and the cabling of their data connections.

[0146] Vehicle components are modularized or standardized in a way that makes them part of a series of other types of components, each using the same standardized safety system. This facilitates automated planning of data layout and also facilitates robot installation.

[0147] The vehicle components are modularized or standardized as part of a series of other types of components. All components are optimized for robotic computer vision systems and, being predominantly black, are optimized for radiative heat dissipation. Using a consistent color (such as black) for the modules produces a more uniform edge appearance, which helps the computer vision system recognize edges and thus identify the modules and determine their position and orientation.

[0148] We can summarize it into the following nine characteristics:

[0149] Feature 1: Modular hardware component size adjustment

[0150] A vehicle component that is modularized or standardized in such a way as to have a size that conforms to a regulated size interval, and which is part of a series of other types of components, all of which are sized in accordance with the same size interval.

[0151] Feature 2: Modular hardware components are installed using the same regular linear grid or mounting pattern.

[0152] A vehicle component that is modularized or standardized in a manner that is part of a series of other types of components, all of which are configured to be positioned or installed in a vehicle in a regular linear grid or mounting pattern.

[0153] Feature 3: Modular hardware components are configured for robot assembly.

[0154] A vehicle component that is modularized or standardized in such a way as part of a family of other types of components, all of which have one or more external features optimized for robotic handling, installation, or assembly (such as autonomous robotic handling, installation, or assembly).

[0155] Feature 4: Modular hardware components are box-shaped.

[0156] A vehicle component that is modularized or standardized in a manner that is part of a series of other components, all of which have the same overall shape type (such as a box shape), including two or more of the following: battery module; main BMS; low-voltage battery; on-board charger; charging controller; DC-DC converter; integrated drive unit; traction inverter; drive control unit; communication module; Ethernet switch; HMI platform; video surveillance system; vehicle audio engine platform; unified computing platform; sensors; weight sensors; computer vision sensors; LiDAR sensors; radar-based sensors.

[0157] Feature 5: Modular hardware components with installation paths optimized for robot mounting.

[0158] A vehicle component that is modularized or standardized in such a way as part of a series of other types of components, all of which are designed for an installation path to a location, wherein the installation path is optimized for robot handling, installation, or assembly (such as autonomous robot handling, installation, or assembly).

[0159] Feature 6: Modular hardware components with standardized fasteners

[0160] A vehicle component that is modular or standardized in a way that is part of a series of other types of components, each using the same standardized physical mounting system (such as self-aligning fasteners), and each component being optimized for robot handling and use.

[0161] Feature 7: Modular hardware components with standardized self-aligned electrical interfaces

[0162] A vehicle component that is modularized or standardized in a manner that is part of a series of other types of components, each using the same standardized self-aligned electrical interface, and each component being optimized for robot handling and use.

[0163] Feature 8: Modular hardware components use the same unique ID system

[0164] A vehicle component that is modularized or standardized in such a way as part of a series of other types of components, each component using the same standardized identification system that provides a unique identifier for each individual component, the identifier being (i) computer-readable but not meaningful to humans; and (ii) enabling the tracking of each individual component from initial production to initial installation and subsequent maintenance and end-of-life.

[0165] Feature 9: Modular hardware components are black.

[0166] A vehicle component that is modular or standardized in a manner that is part of a series of other types of components, all of which are optimized for robotic computer vision systems and optimized for radiative heat dissipation by being predominantly black.

[0167] Brief overview of the figures related to Chapter A

[0168] Figure 1 The Arrival bus is shown.

[0169] Figure 2 The diagram shows the seven 1.5m long transverse segments that make up the majority of the bus.

[0170] Figure 3 Five of these 1.5m segments are shown in more detail, exposing the superstructure underneath.

[0171] Figure 4 One of these 1.5m segments is shown in more detail.

[0172] Figure 5 The exterior of the Arrival bus is shown, highlighting the individual 1.5m long components.

[0173] Figure 6 A 350mm x 350mm battery module is shown.

[0174] Figure 7 The image shows a group of 12 battery modules sliding into an Arrival bus.

[0175] Figures 8-15 Various fasteners optimized for robot use are shown.

[0176] Figures 16-17 The Arrival part identification label is shown.

[0177] Figures 1-17 index

[0178] 100 Arrival Bus 101 1.5m long transverse segment 102 1.5m long aluminum support column 103 1.5m long aluminum substrate 104 1.5m long composite roof panel 105 1.5m long extruded aluminum support column 106 1.5m long color display panel 108 1.5m long composite main panel 110 350mm x 350mm battery module 111 Battery module array

[0179] Detailed description related to Chapter A

[0180] In the following sections of this chapter A, we will look at the Arrival modular hardware system in more detail.

[0181] Feature 1: Modular hardware component size adjustment

[0182] Hardware modularization: Standard-size architecture:

[0183] As we have seen in the introduction, Arrival uses standard hardware to resize across a wide range of projects. The example given earlier is the Arrival bus, which is constructed from many 1.5m long segments. Figure 1 Arrival bus 100 is shown; in Figure 2 In the diagram, we can see how a bus can actually be made from seven modular, 1.5m long transverse segments 101; these segments include both the chassis and the superstructure. Figure 3 The transverse segment 101 is shown in more detail, so we can see all the different components that meet the 1.5m length requirement: these components include: all the longitudinal supports 102 that make up the structural trapezoidal frame, and the 1.5m long aluminum substrate. Figure 103 The structure includes a 1.5m long composite roof panel 104 and extruded aluminum struts 105 forming the internal frame. This modular approach to constructing the Arrival bus allows the core structural components to be made from a relatively small number of different parts, each with a standardized length. Furthermore, all these parts are designed for robotic production, handling, and assembly: for example, they are typically lightweight and have a uniform weight distribution, allowing for easy and predictable manipulation by robots. They are rigid and have flat surfaces that are easy for robots to grasp, with few or no curved surfaces that are difficult to grasp. Figure 4 A more detailed view of a single cross-section chassis segment is shown: we can see a 1.5m long composite roof panel, a 1.5m long extruded aluminum strut, and a 1.5m long composite side panel 108. Returning to the finished bus, Figure 5 We see how modular the hardware (and especially the consistent use of it in 1.5m-scale building projects) is evident even from the outside: we can see seven 1.5m-long color display panels 106 that extend almost the entire length of the Arrival bus; we can see how each composite main panel is actually a 1.5m-long main panel.

[0184] Figure 6 This is another example of hardware modularity: each HVBM battery module 110 is a 350mm x 350mm square. A set of twelve modules can be combined together, such as... Figure 7As shown; due to the simple integer size adjustment of HVBS, it is easy to see that this set of HVBMs will have a width of 1.4m, and therefore should fit into the cavity defined by the length of 1.5m for each chassis segment.

[0185] We can also look at this from a more theoretical perspective: "Size architecture" relates to the physical design of Arrival components—a standard that captures the principles of physical modularity and consistency in design language. By using a predefined grid size as the boundary for production geometry, the space left for components is never too small, and components are never too large. The size architecture digital system is a simple and compatible system that accurately covers a wide range of sizes. Modules are designed in 100mm increments in external dimensions. For example, 100x100, 200x100, or 300x200, etc. The grid size defined by these sizes includes tolerances. The term "size" should be interpreted broadly. In many cases, it refers to the dimension of length, but it can also refer to area, weight, performance capacity, rating, etc. Some modules can be electrically connected to vehicles, and these electrical connectors also conform to the same standardized size adjustment. For example, the width of an externally molded wiring harness connector is 100mm, regardless of the contact configuration. A 100mm wide module has one connector on each side (maximum two connectors per module). A 200mm wide module has a maximum of two connectors on each side (maximum four connectors per module).

[0186] Attributes of "Big-Small Architecture" Digital Systems

[0187] Simplicity: Human-centered numbers. It's important that the number system is intuitive, requires little memorization, and involves few steps in any process or calculation. We have a strong preference for integers with few significant digits and few decimal places.

[0188] Coverage: Accurate and evenly spaced. The number series offers a limited number of choices to cover a wide range of values. Importantly, these values ​​have good coverage on the number line, with small gaps and even spacing.

[0189] Compatibility: Size that works well together: Components fit snugly against each other and fill the available area without leaving unusable gaps. Since the size of the components is driven by the number system, a good number system should describe the interrelationship of any values ​​it produces. We have defined this property based on mathematical closures. A closure describes whether an operation on a number system produces another value from the number system. Individual operations can include division, multiplication, addition, or subtraction. A number system is a trade-off between simplicity, coverage, and compatibility. Therefore, we do not expect perfect closure of sets, and thus we measure the ratio of closed operations to unclosed operations. Therefore, compatibility is the ratio of closed operands to open operands.

[0190] Digital System

[0191] The digital system uses a standard base of 10, and divides the range into equal steps using constant factors.

[0192]

[0193] First preference

[0194] The first-order preference divides 10 into three equal steps, therefore 3 √10. The resulting value is rounded to the nearest integer.

[0195]

[0196] Second preference

[0197] The second preference divides 10 into ten equal steps, therefore 10 √10.

[0198] The resulting value is rounded to 0.25.

[0199]

[0200] Modules of Grid Size: Electronic components, regardless of their installation location within a vehicle or product, should be designed according to the following guidelines. Unit Size: Negotiate the physical unit size (boundary frame), which may involve all parties involved in the component (designers, PCB engineers, etc.).

[0201] Components / assemblies shared across Arrival follow a grid-space “box” design, allowing for seamless integration of updated components into existing products as technology improves. Dimensions should be determined by the functional requirements of the component in conjunction with the aforementioned Arrival digital preference system. Mounting orientation: Determine the orientation in which the unit geometry will be mounted. All connectors (mechanical, electrical, thermal) should be on the bottom surface.

[0202] Components should be designed to be grid-sized: design boundaries, negotiated, and communicated. Production size considers tolerances and is defined by the grid size. Components are designed to be grid-sized: predefined physical boundary interfaces, based on the size-architected digital system. Production size considers tolerances within the boundaries defined by the grid size. Production size (post-production geometry tolerances) does not extend beyond the grid size. Between teams, we only need to communicate the grid size. Production size is driven by production tolerances and should not be widely communicated, as it may change as the production process evolves. Production size is driven so that components will be interfaced and assembled within a platform designed to accommodate the grid size. By using the grid size as the boundary of production geometry, the space left for components is never too small, and components are never too large. Gaps (intentional spaces created between components) are considered virtual components within the assembly. Gaps are provided in the assembly context, not in the part—think of a gap as a "virtual part" with two interfaces; one interface is presented to the assembly, and one interface is presented to the part. Gaps are a function of the assembly, not the component. This is because the component is unaware of the assembly context. Larger gaps may be needed if the component will be used for dynamically moving parts (such as slide-in and slide-out) or frequently removed (such as for maintenance). If a precise assembly method is used instead, the gaps can be reduced accordingly. The product remains the same. Ideally, we will provide good figures for both parts and gaps (which can themselves be considered virtual parts). This would mean that the module spacing will be a similarly good figure (i.e., the sum of both parts and gaps). As "virtual parts," gaps have no tolerance.

[0203] We can summarize it as follows:

[0204] A vehicle component that is modularized or standardized in such a way as to have a size that conforms to a regulated size interval, and which is part of a series of other types of components, all of which are sized in accordance with the same size interval.

[0205] Optional sub-features:

[0206] Almost all structural components used in vehicles are modular or standardized vehicle components, with sizes that conform to regulated size intervals.

[0207] Almost all longitudinal extrusion beams or components used in the chassis or skid plate of a vehicle are modular or standardized vehicle parts with sizes that conform to regulated dimensions.

[0208] Almost all transverse extrusion beams or components used in the chassis or skid plate of a vehicle are modular or standardized vehicle parts with sizes that conform to regulated dimensions.

[0209] Almost all vertical extrusion beams or components used in the superstructure or body of a vehicle are modular or standardized vehicle parts with sizes that conform to regulated dimensions.

[0210] Almost all vertical extrusion beams or components used in the upper structure or body of a vehicle are separated by horizontal distances that conform to regular sized intervals.

[0211] • The structural cast wheel arches or wheel supports used in vehicles are modular or standardized vehicle components with sizes that conform to regulated size intervals.

[0212] • The front and rear suspension brackets of a vehicle are modular or standardized vehicle components with sizes that conform to regulations.

[0213] The main panels used in the vehicle are modular or standardized vehicle components with sizes that conform to regulations.

[0214] Almost all the main panels used in the vehicle are composite panels.

[0215] • In the case where the vehicle is constructed from multiple transverse chassis segments, some or all of these transverse chassis segments are modular or standardized vehicle components with sizes that conform to regulations.

[0216] Almost all battery modules used in vehicles are modular or standardized vehicle components with sizes that conform to regulated size intervals.

[0217] • The casing of the battery pack, which contains the battery modules, is a modular or standardized vehicle component with dimensions that conform to regulated size intervals.

[0218] One or more of the following are modular or standardized vehicle components with sizes conforming to regulated size intervals: battery module; main BMS; low-voltage battery; on-board charger; charge controller; DC-DC converter; integrated drive unit; traction inverter; drive control unit; communication module; Ethernet switch; HMI platform; video surveillance system; vehicle audio engine platform; unified computing platform; flexible PCB conductor; sensor; weight sensor; computer vision sensor; LIDAR sensor; radar-based sensor.

[0219] • The size intervals are configured to facilitate robot handling and assembly.

[0220] • Select size intervals to facilitate computer-aided design of components.

[0221] • Choose the size interval to minimize the computation time for trajectory planning and collision detection.

[0222] • The size of the component is defined by an automatic size adjustment algorithm.

[0223] • The size of the component is defined by an automatic sizing algorithm that calculates the optimal size of the component given multiple input parameters.

[0224] • Select component sizes to facilitate computer vision-based detection, including pose and orientation detection.

[0225] • Select component sizes to facilitate calculation of swing paths during handling and installation.

[0226] • Some or all of the parts have similar shapes.

[0227] • Some or all of the components have similar, simplified box-like shapes.

[0228] • Some or all of the components have flat tops.

[0229] • Some or all of the components have flat sides.

[0230] • Some or all of the components have a flat base.

[0231] • Size adjustments are defined in 100mm increments.

[0232] Size adjustments are defined in 10mm increments.

[0233] • The components are made of rigid materials to minimize deformation during processing.

[0234] Feature 2: Modular hardware components are installed using the same regular linear grid or mounting pattern.

[0235] In Feature 1 above, we introduced the concept of hardware modularity, where the sizes of different components conform to preset size increments. While it's useful to have standardized size adjustments for modules, it's even more useful to ensure that modules or other components are actually positioned or installed according to a standardized grid—for example, the physical location of modules is constrained in a manner consistent with size increments. Figure 2 The text shows and Figure 3 and Figure 4 The transverse chassis segment 101 shown in more detail is an example of an entire vehicle in which structural components are actually arranged, conforming to a straight grid with a length of 1.5m.

[0236] Another example: A component like a box-type controller can have an overall size conforming to the size proportions described in Feature 1, but additionally has mounting holes at each corner, and these mounting holes conform to the same (or derived or related) proportions. These mounting holes can be aligned with drill holes in the controller's support plate; the drill holes are positioned in a regular linear grid or mounting pattern. The overall result is a controller unit whose size conforms to standardized size proportions and which is itself mounted in a regular linear grid or mounting pattern. This method of standardizing hardware component sizing, combined with standardized hardware component positioning, constrains two variables (size and position), and thus enables automated, software-based design and layout, and also simplifies robot handling, assembly, and installation.

[0237] The standardized grid system for locating or installing objects applies not only to vehicles but also to the production environments in which they are manufactured; we will see how the same rules apply to layout workbenches and micro-factories. For example, the size of individual robot units and their routing conform to the same linear grid; the size and routing of AMR paths also conform to the same linear grid. All of this facilitates software simulation and analysis of proposed factory layouts, enabling more efficient optimization of the layout and improving physical construction.

[0238] We can summarize it as follows:

[0239] A vehicle component that is modularized or standardized in a manner that is part of a series of other types of components, all of which are configured to be positioned or installed in a vehicle in a regular linear grid or mounting pattern.

[0240] Optional features

[0241] • Linear grid or installation mode is optimized for robot installation or assembly (such as autonomous robot installation or assembly).

[0242] • Optimize linear grids or mounting patterns to facilitate computer vision-based detection of component positions.

[0243] • Optimize linear grids or mounting patterns to facilitate the correct installation of components using computer vision-based detection.

[0244] • Choose a linear mesh or mounting mode to facilitate the calculation of swing paths during handling and installation.

[0245] • The size and placement of individual robots in a vehicle production environment conform to the same linear grid or installation pattern.

[0246] • The size and routing of AMRs in the vehicle production environment conform to the same linear grid or mounting pattern.

[0247] • Vehicle components are modularized or standardized in such a way that, according to feature 1 and its optional sub-features, they have sizes that conform to regular size intervals, and the vehicle component is part of a series of other types of components, all of which are sized in accordance with the same size intervals.

[0248] Feature 3: Modular hardware components are configured for robot assembly.

[0249] The Arrival system defines how components move within a micro-factory, serving both external and internal logistics. Components should be: rigid and non-deformable, stackable on shelves, stable during transport via AMRs, and designed for safe, manual handling. While these requirements are simple in themselves, they can lead to a complete redesign and improvement of the components. For example, Figure 6 The HVBM 110 shown exemplifies components that meet these standards and is therefore very different from earlier battery modules.

[0250] Mobile robots are developed for indoor logistics: parts should be stably placed on the AMR mobile platform without clamps; this implies that parts should have a large, flat surface on the AMR platform for stable placement. Parts should not obstruct sensors or cameras on the AMR mobile platform. Again, these requirements are simple in themselves but lead to a reliable, scalable, and efficient overall Arrival production system.

[0251] Using the Arrival system, individual parts are shaped to make them suitable for handling and manipulation by a robot. The robot needs to securely grasp the parts, have sufficient space or gaps to reach and install them, and work with part materials that are inherently compatible with the robot's handling capabilities. Each of these is processed in turn:

[0252] Gripping—that is, helping the robot hold a part. The part will be picked up and moved by the robot, and the part design should allow for safe gripping to enable rapid acceleration and movement. For this, we need a sufficiently large gripping surface, utilizing suitable high-friction materials, with the contact point close to the center of mass to reduce the torque acting on the robot. Generally, simple geometry is easier to grip. These predictable gripping or holding characteristics also enable accurate knowledge of the part's position (localization). Specific example: Parts to be handled by a vacuum gripper should have a minimum diameter of 20 mm. 2 The components to be handled by the vacuum gripper should have a center-of-gravity torque less than a preset Nm, allowing the vacuum gripper to safely manipulate them. Components to be handled by the parallel gripper should have a parallel, flat area.

[0253] Robotic clearance: Sufficient space must exist for all robot operations, either planned or simulated. Local clearance is only a minimum requirement. Tooling access may also be limited by other factors, including robot arm reachability, robot position, and retaining devices. Tooling access: When designing using fasteners such as bolts and screws, we need to ensure sufficient clearance (typically at least 18mm) around the fastener head of the robot actuator and sufficient passage for the robot head. The robot approaches the axis of the fastener and does not require levers, unlike humans who would need wrenches.

[0254] Draggable wireframe models of robots (dexterity and reachability) are often used to simulate swing paths in CAD and to verify that all paths are feasible and have sufficient gaps.

[0255] Examples of channel types used in robotic manufacturing: Standard tool channels are preferred over specialized tools (e.g., screwdrivers, nut wrenches, sealant guns). Gripper channels used for part loading during the process: Use common part designs to reduce gripper variations; simplify assembly sequences; minimize "insertion" type operations.

[0256] Material properties: Robots prefer rigid and predictable materials. Deformable or inconsistent materials are difficult for robots to handle and are avoided.

[0257] In the Arrival system, robotic tooling or end effectors are shared or common across different vehicles, enabling microfactories to produce the entire Arrival vehicle range without human intervention. Robots need access to a much smaller range of tools to perform all the functions they require, making tool selection faster. For example, only a limited number of fastener systems are used, and the shapes or geometries of the parts are designed to allow for robotic assembly or attachment using these limited number of different fastener systems. Self-aligning fasteners are used where possible—that is, correct assembly does not depend on the highly accurate robotic positioning of the fasteners or the tools used to attach them. Adhesives are also used where possible, using only a single-design adhesive applicator.

[0258] We can summarize it as follows:

[0259] A vehicle component that is modularized or standardized in such a way as part of a family of other types of components, all of which have an outer surface or one or more housing features optimized for robotic handling, installation, or assembly (such as autonomous robotic handling, installation, or assembly).

[0260] Optional sub-features:

[0261] • The outer surface or one or more shell features are gripping features.

[0262] • The outer surface or one or more housing features are sufficient gripping surfaces close to the center of mass of the component.

[0263] • The outer surface or one or more housing features enable accurate component positioning or localization.

[0264] • The outer surface or one or more shell features enable safe gripping during robotic handling, allowing for rapid acceleration and deceleration of movement.

[0265] • Some or all of the parts in the series have similar shapes.

[0266] Some or all of the components in the series have similar simplified box-shaped shapes.

[0267] Some or all of the parts have flat tops.

[0268] Some or all of the components in the series have flat sides.

[0269] • Some or all of the components in the part series have a flat base.

[0270] • Size adjustments are defined in 100mm increments.

[0271] Size adjustments are defined in 10mm increments.

[0272] • The size of the component is defined by an automatic size adjustment algorithm.

[0273] • The size of the component is defined by an automatic sizing algorithm that calculates the optimal size of the component given multiple input parameters.

[0274] • Select one or more shell features of a component to facilitate computer vision-based detection, including pose and orientation detection.

[0275] Other types of component series include one or more of the following: battery modules; main BMS; low-voltage batteries; on-board chargers; charge controllers; DC-DC converters; integrated drive units; traction inverters; drive control units; communication modules; Ethernet switches; HMI platforms; video surveillance systems; vehicle audio engine platforms; unified computing platforms; flexible PCB conductors; sensors; weight sensors; computer vision sensors; LiDAR sensors; and radar-based sensors.

[0276] Other types of component series include one or more of the following: frames, panels, motors, and chassis components.

[0277] • Vehicle components are modularized or standardized in such a way that, according to feature 1 and its optional sub-features, they have sizes that conform to regular size intervals, and the vehicle component is part of a series of other types of components, all of which are sized in accordance with the same size intervals.

[0278] Vehicle components are modularized or standardized in the following ways, according to feature 2 and its optional sub-features, as part of a series of other types of components, all of which are configured to be positioned or installed in the vehicle in a regular straight grid or mounting pattern.

[0279] Feature 4: Modular hardware components are box-shaped.

[0280] We have seen how Arrival modules can have a proportionally sized form, lie on a linear grid, and possess one or more external features optimized for robot handling, installation, or assembly. A concrete example of combining all these features is giving the module a specific type of shape, such as a box shape, like... Figure 6 The battery module 110 is shown in the diagram and described in more detail in section G.

[0281] We can summarize it as follows:

[0282] A vehicle component that is modularized or standardized in a manner that is part of a series of other components, all of which have the same overall shape type (such as a box shape), including two or more of the following: battery module; main BMS; low-voltage battery; on-board charger; charging controller; DC-DC converter; integrated drive unit; traction inverter; drive control unit; communication module; Ethernet switch; HMI platform; video surveillance system; vehicle audio engine platform; unified computing platform; sensors; weight sensors; computer vision sensors; LiDAR sensors; radar-based sensors.

[0283] Optional features

[0284] • The box shape is optimized for robot handling, installation, or assembly (such as autonomous robot handling, installation, or assembly).

[0285] • Choose a box shape to facilitate computer vision-based detection, including pose and orientation detection.

[0286] • Select the box size to match the size intervals in the rules.

[0287] Other types of component series include one or more of the following: battery modules; main BMS; low-voltage batteries; on-board chargers; charge controllers; DC-DC converters; integrated drive units; traction inverters; drive control units; communication modules; Ethernet switches; HMI platforms; video surveillance systems; vehicle audio engine platforms; unified computing platforms; flexible PCB conductors; sensors; weight sensors; computer vision sensors; LiDAR sensors; and radar-based sensors.

[0288] • Vehicle components are modularized or standardized in such a way that, according to feature 1 and its optional sub-features, they have sizes that conform to regular size intervals, and the vehicle component is part of a series of other types of components, all of which are sized in accordance with the same size intervals.

[0289] Vehicle components are modularized or standardized in the following ways, according to feature 2 and its optional sub-features, as part of a series of other types of components, all of which are configured to be positioned or installed in the vehicle in a regular straight grid or mounting pattern.

[0290] • Vehicle components are modularized or standardized in the following ways, according to feature 3 and its optional sub-features, as part of a series of other types of components, all of which have an outer surface or one or more shell features optimized for robot handling, installation or assembly (such as autonomous robot handling, installation or assembly).

[0291] Feature 5: Modular hardware components with installation paths optimized for robot mounting.

[0292] Components are configured to interact, connect, and interface with other parts through methods and approaches suitable for the robot. The tooling will evaluate the number of operations, the time spent completing them, and provide feedback on the total cost of assembly, including the actions involved and potential areas of error. The following considerations, important for robot assembly, are implemented in the Arrival system: fewer unique operations; fewer overall operations; fewer operations mean fewer connection points to define in the D2R (Design to Robot Manufacturing) process / tooling; combined operations (integrated functions, such as cooling pipes in casting); our goal is to simplify tooling by using common contact mechanisms; if the shape of the component is irregular and unavoidable, gripping features need to be designed into it. Use single-vector engagement: parts should contact other parts via a single vector of movement, allowing alignment to be determined via force / torque sensor feedback on the robot, coordinating the gripping deterministic axis with insertion and connection direction features (reducing positional uncertainty). Use sequential operations: one by one, from bottom to top, avoiding parallel operations. Use assemble-then-fix: position first, and then fix in place. To aid assembly, components should self-position. Adding automatic alignment features allows for component self-positioning. Use standardized fasteners to simplify assembly. Chapter J provides the robot assembly sequence for the Arrival bus components described above; this assembly sequence illustrates the robot production requirements mentioned above.

[0293] We can summarize it as follows:

[0294] A vehicle component that is modularized or standardized in such a way as part of a series of other types of components, all of which are designed for an installation path to a location, wherein the installation path is optimized for robot handling, installation, or assembly (such as autonomous robot handling, installation, or assembly).

[0295] Optional features

[0296] • Choose an installation path to ensure sufficient space for robot operation.

[0297] • Choose an installation path to ensure sufficient passage space for the robot head.

[0298] The robot approaches the axis of the fastener of the component without the need for levers (such as wrenches).

[0299] The installation path is calculated in CAD using the draggable wireframe model of the parts and robot.

[0300] Other types of component series include one or more of the following: battery modules; main BMS; low-voltage batteries; on-board chargers; charge controllers; DC-DC converters; integrated drive units; traction inverters; drive control units; communication modules; Ethernet switches; HMI platforms; video surveillance systems; vehicle audio engine platforms; unified computing platforms; flexible PCB conductors; sensors; weight sensors; computer vision sensors; LiDAR sensors; and radar-based sensors.

[0301] Other types of component series include one or more of the following: frames, panels, motors, and chassis components.

[0302] • Vehicle components are modularized or standardized in such a way that, according to feature 1 and its optional sub-features, they have sizes that conform to regular size intervals, and the vehicle component is part of a series of other types of components, all of which are sized in accordance with the same size intervals.

[0303] Vehicle components are modularized or standardized in the following ways, according to feature 2 and its optional sub-features, as part of a series of other types of components, all of which are configured to be positioned or installed in the vehicle in a regular straight grid or mounting pattern.

[0304] • Vehicle components are modularized or standardized in the following ways, according to feature 3 and its optional sub-features, as part of a series of other types of components, all of which have an outer surface or one or more shell features optimized for robot handling, installation or assembly (such as autonomous robot handling, installation or assembly).

[0305] Vehicle components are modularized or standardized in the following ways, according to feature 4 and its optional sub-features, which are part of a series of other types of components, all of which have the same overall box shape.

[0306] Feature 6: Modular hardware components with standardized fasteners

[0307] Arrival has a set of standard interfaces that are used as much as possible to help improve efficiency and robotic manufacturing. These standard interfaces are part of a large-scale architecture interface library.

[0308] Arrival Standard Fasteners: A set of common fasteners used in Arrival products and components. Fasteners are essential parts in construction vehicles, components, and assemblies. Managing the variety of fasteners in our supply chain and production environment is important to help us move quickly and streamline our operations. The standard fastener library is a set of common fasteners: a limited selection covering a wide range of sizes—used across all Arrival products. Reducing the variety of equivalent but different fasteners that achieve essentially the same goal is worthwhile, allowing us to leverage the advantages associated with standardization, including: rapid development and reduced uncertainty—simple options with clear guidelines and pooled experience; streamlined operations—procurement, logistics, and warehousing all benefit from fewer different parts; and reduced costs—combined purchasing power lowers the cost of fasteners.

[0309] Advantages of Arrival standard fasteners: Simplified production: Limiting the number of different drive types simplifies production and assembly by reducing the complexity of pick-and-place and automated feeding; it also reduces the impact on repair and maintenance by limiting the range of tools required.

[0310] Streamlining logistics: Every new part we add to our standard stock is another part we need to procure, ship, and store. The number of fasteners we need to manage in inventory is the product of the quantity of different fastener types, head sizes, length of each fastener, grade of each fastener, and surface finish. Without careful management, this can quickly amount to hundreds or even thousands of different fasteners.

[0311] Inventory = Type × Diameter × Length × Grade × Completed

[0312] Economies of scale in delivery: Standardizing our fasteners means combining our purchasing power and leveraging the total volume of all items, which reduces the cost of fasteners.

[0313] The number of spare parts is significantly reduced: Using our modular component design approach and multiple factory locations, we need to limit fastener options as much as possible to reduce the number of spare parts in each location or per component.

[0314] Grouping fasteners by component or part will help speed up production and reduce part costs, while controlling the length and size of fasteners in each part system or component will also improve overall speed and production costs.

[0315] Examples: bolts, screws, nuts, washers, rivets, clips and retaining rings, rivet nuts.

[0316] Benchmarking strategy: Techniques that desensitize alignment requirements during assembly to address production variations and tolerances.

[0317] Self-alignment feature: Mechanical positioning features enable automatic alignment of parts, especially for robotic components. The key principle is that part-to-part alignment reduces the need for complex handling systems and holding devices; it also facilitates the alignment of fastener holes; all parts that are "paired" by default require self-alignment; and robot accuracy is used only as a last resort.

[0318] Alignment Pins: Bullet-shaped pins allow for automatic alignment of components. The pin's shape provides a constant insertion force, unlike the more demanding chamfering and angular variations that can affect components. The pin's curved profile segments align them with corresponding holes / grooves. Cylindrical segments determine the final position of the pin-type part.

[0319] There are two options for the alignment pin geometry: shouldered and simplified.

[0320] Shoulder-mounted: Suitable for allowing small gaps between surfaces A and B, as the shoulder of the pin fits snugly against surface B. Figure 8 As shown.

[0321] Simplified: Suitable for use when the corresponding part has an elevated geometric segment acting as a shoulder, such as... Figure 9 As shown.

[0322] Tolerances and fits: Both pin options have The maximum diameter is determined by the pin size, and it can self-position itself into the corresponding hole from an initial position ≤4.5mm off-center. The tolerance is determined by the corresponding hole size. For example, an 11mm hole will allow a total tolerance of ±1mm, with a maximum clearance of 0.5mm around the pin.

[0323] Pin geometry implementation options. Contour molding: The pin can be directly implemented into the shape of the part, such as an injection-molded part. Maintaining a consistent wall thickness will reduce the likelihood of sink marks in the plastic molded part. Examples are as follows... Figure 10 As shown.

[0324] Overmolding / Bonding: Individually molded / machined pins can be overmolded or bonded to other parts. Pins can be overmolded to such a depth that the base of the pin is flush with its molded surface. A suitable adhesive can then be used to bond the pin to the surface of other parts. The depth of the indentation feature in the part is used to determine whether the pin is flush or protruding. Examples are shown below. Figure 11 As shown. A suitable adhesive can be used to bond the pin to the surface of other components. The depth of the recessed position feature in the component determines whether the pin is flush or protruding.

[0325] Push-in fit: Push-in fit pin designs can be implemented into components without adhesives, such as... Figure 12 As shown.

[0326] Push-in fit: Like other pin designs, it is a simple rotation that creates automatically aligned features, shoulders, chamfered introduction, and sufficient material to engage with the appropriate cavity.

[0327] Push-in mating flush: If the cavity for the push-in mating pin has a step to accommodate the shoulder of the pin, the base of the pin can be flush with the surface of the component.

[0328] Shoulder-mounted push-in fit: If the cavity for the mating pin has no step, the shoulder of the pin will protrude, creating a gap between the two parts once aligned.

[0329] Rotation and size change control: Further automated control can be added during assembly using multiple alignment features.

[0330] Automatic rotation: Parts with two or more alignment pins can automatically rotate to the appropriate position when the pins are aligned with their corresponding holes, provided that the center of the end of the tapered pin is aligned somewhere in the corresponding hole.

[0331] A part with an alignment pin (left) and a part with a corresponding hole (right) are shown below. Figure 13 As shown. The center of the pin needs to be aligned somewhere within the corresponding hole / slot, such as... Figure 14 As shown.

[0332] The pin-type part will automatically rotate to the appropriate position when the tapered pin is pushed through the hole:

[0333] Constraining part size variations: Slots and holes can also be used to automatically rotate parts to the appropriate position. The advantage of using slots is that the size can be accommodated as the part is manufactured, and alignment with certain edges can be controlled.

[0334] Controlling the alignment of two edges: This method allows two edges to remain aligned regardless of size changes.

[0335] We can summarize it as follows:

[0336] A vehicle component that is modularized or standardized in a manner that is part of a series of other types of components, each using the same standardized physical mounting system and each optimized for robot handling and use.

[0337] Optional features

[0338] Standardized physical installation systems include physical fasteners.

[0339] Physical fasteners are self-aligning or self-positioning.

[0340] • The robot approaches the fastener or the position of the fastener on the fastener's axis.

[0341] • Self-aligning or self-positioning fasteners are bullet pins.

[0342] • The bullet-shaped pin may or may not have a shoulder.

[0343] • Bullet-shaped pins are overmolded or adhered to other parts.

[0344] • The bullet-shaped pin is bonded to the surface of other parts using a suitable adhesive.

[0345] • The bullet-shaped pin is a push-in fit.

[0346] Parts with two or more alignment pins automatically rotate to the appropriate position when the pins are aligned with their corresponding holes.

[0347] Standardized physical installation systems include adhesive-based systems.

[0348] The robot is configured for one or more of the following: picking and placing, inserting, gluing, twisting, and welding.

[0349] • The software implementation tools assess the number of operations, the time spent completing the operations, and the actions involved in providing feedback on the total cost of assembly, as well as potential areas for error.

[0350] Other types of component series include one or more of the following: battery modules; main BMS; low-voltage batteries; on-board chargers; charge controllers; DC-DC converters; integrated drive units; traction inverters; drive control units; communication modules; Ethernet switches; HMI platforms; video surveillance systems; vehicle audio engine platforms; unified computing platforms; flexible PCB conductors; sensors; weight sensors; computer vision sensors; LiDAR sensors; and radar-based sensors.

[0351] Other types of component series include one or more of the following: frames, panels, motors, and chassis components.

[0352] • Vehicle components are modularized or standardized in such a way that, according to feature 1 and its optional sub-features, they have sizes that conform to regular size intervals, and the vehicle component is part of a series of other types of components, all of which are sized in accordance with the same size intervals.

[0353] Vehicle components are modularized or standardized in the following ways, according to feature 2 and its optional sub-features, as part of a series of other types of components, all of which are configured to be positioned or installed in the vehicle in a regular straight grid or mounting pattern.

[0354] • Vehicle components are modularized or standardized in the following ways, according to feature 3 and its optional sub-features, as part of a series of other types of components, all of which have an outer surface or one or more shell features optimized for robot handling, installation or assembly (such as autonomous robot handling, installation or assembly).

[0355] Vehicle components are modularized or standardized in the following ways, according to feature 4 and its optional sub-features, which are part of a series of other types of components, all of which have the same overall box shape.

[0356] • Vehicle components are modularized or standardized in the following ways, according to feature 5 and its optional sub-features, as part of a series of other types of components, all of which are designed for an installation path to a location, wherein the installation path is optimized for robot handling, installation or assembly (such as autonomous robot handling, installation or assembly).

[0357] Feature 7: Modular hardware components with standardized self-aligned electrical interfaces

[0358] Utilizing self-aligned electrical interfaces: Electrical connections for components feature floating elements to accommodate misalignment during assembly; this provides electrical and electronic interfaces optimized for power, signals (data) in robotic components. Applications include: automated connection of components (such as battery module assemblies or steering racks) after mechanical assembly into a vehicle; and quick-replaceable batteries (such as for scooters / bicycles or AMR robots).

[0359] Features include: Pre-alignment pins: Some connectors (such as those for removable devices, interchangeable batteries, drawer interconnects, etc.) have pins that facilitate automatic alignment of the connector. These tapered (conical or rounded) pins are advantageous for robotic assembly and blind mating of connectors. These pins are typically grounded to the connector chassis, but they can also function as high-current carrying pins.

[0360] Typical components using these standardized electrical interfaces include: vehicle components including one or more of the following: battery module; main BMS; low-voltage battery; on-board charger; charge controller; DC-DC converter; integrated drive unit; traction inverter; drive control unit; communication module; Ethernet switch; HMI platform; video surveillance system; vehicle audio engine platform; unified computing platform; flexible PCB conductor; sensors; weight sensors; computer vision sensors; LiDAR sensors; radar-based sensors.

[0361] We can summarize it as follows:

[0362] A vehicle component that is modularized or standardized in a manner that is part of a series of other types of components, each using the same standardized self-aligned electrical interface, and each component being optimized for robot handling and use.

[0363] Optional features

[0364] Standardized self-aligned electrical interfaces include floating features to address misalignment during assembly applications.

[0365] Standardized self-aligned electrical interfaces enable automatic connection of electrical components after mechanical assembly into a vehicle.

[0366] Standardized self-aligning electrical interfaces include pre-alignment pins to aid in the automatic alignment of connectors.

[0367] • The pre-aligning pin is a conical or rounded pin.

[0368] Vehicle components include one or more of the following: battery module; main BMS; low-voltage battery; on-board charger; charging controller; DC-DC converter; integrated drive unit; traction inverter; drive control unit; communication module; Ethernet switch; HMI platform; video surveillance system; vehicle audio engine platform; unified computing platform; flexible PCB conductor; sensor; weight sensor; computer vision sensor; LIDAR sensor; radar-based sensor.

[0369] Feature 8: Modular hardware components use the same unique ID system

[0370] A company's value is increasingly driven by its ability to collect and analyze information about its products, customers, and supply chain. Arrival is able to identify parts, components, products, and vehicles throughout their lifecycle. Part identification facilitates traceability from production and assembly to logistics, use, maintenance, and end-of-life. Beyond identification, robots also need to know how the parts they need to pick up or assemble are positioned—that is, their pose. Automated computer vision systems are used for object 6DoF pose estimation. Parts with flat surfaces that meet at sharp edges are easier for computer vision systems to track and run object detection and 6DoF pose estimation algorithms. Geometric complexity impacts the computation time for trajectory planning and collision detection: parts with large, simple, flat surfaces are easier to compute. Robots prefer rigid and predictable materials; deformable or inconsistent materials are difficult for robots to handle and are avoided.

[0371] In addition to attitude estimation, each component is either directly identifiable or identifiable through inference. Each component is unique and traceable throughout production and use.

[0372] Arrival permanently labels hardware components only with information it cannot avoid: legally required symbols and product identification methods. Graphics are formatted using Arrival's programmatic labeling system, combining mandatory markings from a modular symbol library with Arrival unique identifiers (2D data matrices that visually encode Arrival's unique identifiers). No other information or human-readable text will be marked on our products. These unique markers are generated by the API and do not encode meaningful information. The associated name, serial number, and metadata are retrieved from a database by scanning this machine-readable marker.

[0373] Why do we choose to avoid tagging our products with any human-readable text? There are many reasons why we shouldn't tag our products with human-readable text but instead use Arrival unique identifiers to retrieve appropriate information from cloud databases.

[0374] • The text we wrote may be incorrect. Retrieving the requested information means we can easily fix any errors on the server side. Changes can be immediately propagated to all affected products.

[0375] • Arrival allows you to change the text. We can update the metadata and aliases in the database at any time, even after the product has been tagged.

[0376] Device attributes can change. Our devices are software-defined, meaning their functionality is determined by the software running on them, and this can change.

[0377] • Products are customized for each application. We may not know where the product will be used when we tag it.

[0378] • Products will become increasingly customer-specific. If a customer purchases a special “package elevator controller” from Arrival, the product should be described as a package elevator controller, not an “Arrival general control module”.

[0379] • Information should be appropriate for the target audience. Arrival service technicians should be presented with relevant service information, which will differ from storage or logistics information.

[0380] • Everyone should have a clear understanding of the information. By retrieving the requested information from the database, we can present users with text in their preferred language: French text for French-speaking technicians, Kaji text for Japanese import officials.

[0381] • To prevent reverse engineering in Arrival's supply chain. Arrival doesn't want people to know which micro-factory, region, or supplier their products come from.

[0382] • To prevent reverse engineering of our production output. Arrival does not want to share any sequential data, as this could be used to estimate the quantity of products produced.

[0383] • Dates are irrelevant. Arrival does not want to advertise production dates or expiration dates because we intend to bring “used” parts and components back into our supply chain for a second life, such as new, as well as refurbished or repaired.

[0384] • Audiences should have appropriate authorization. Arrival controls the visibility of information based on the viewer's authorization. Because it cannot control who views the parts, it must control how information is retrieved from the database by implementing access controls on the application.

[0385] Entities are assigned unique identifiers. These identifiers are arbitrary and universally unique numbers, and aliases and metadata can be associated with them in the database.

[0386] Hardware components should be permanently marked with unique identifiers—2D barcodes, which visually encode identification numbers. RFID tags can also be used to encode identification numbers for electronic reading using contactless scanners (e.g., RFID tags in composite panels and other parts). Electronic components can be electronically identified via a connected network.

[0387] Arrival unique identifiers are arbitrary and universally unique numbers used to identify all entities in the Arrival system. Aliases and metadata can be associated with them in the database.

[0388] Here is an example of an Arrival unique identifier:

[0389] BGtVbULnzqFuopHlyYt7BKF3zKQaS7kmDMG6Va110wU

[0390] This identifier is how we identify our products so we can trace them throughout their entire lifecycle. It's a unique name we give to each new part, and we store it in a database along with any data we collect about that part (such as where it was manufactured and how it's used). We can also use it to name things that aren't physical but that we want to track—like software or users. Arrival requires a consistent ecosystem—a broad unique identification scheme that can map to anything, evolve (transform, update, combine), and relate to any physical or virtual object in the Arrival ecosystem. This solution is compatible with a wide variety of use cases (and even unknown future applications). This leads us to conclude that every physical entity has a digital meta-identity. The Arrival Unique Identifier (AUID) is used to identify all entities in the Arrival ecosystem. The identifier doesn't directly encode meaningful information; instead, it derives meaning through associations established in the database. These associations include aliases and metadata.

[0391] The design for the unique Arrival identifier is as follows: There will be a universal Arrival identifier standard, which will be used to identify all entities, whether physical or otherwise. Each entity will be assigned a unique identifier. The number itself is arbitrary. Aliases will be used where human readability is required (the identifier will not be directly viewed). Information and metadata will be linked to the identifier in the database. The numbering will be sufficiently complex to cover future applications, including traceability and tracking within a blockchain system.

[0392] Arrival unique identifier string is a combination of many random bits (for complexity), which are encoded to reduce string length.

[0393] The "number" following the identifier is arbitrary and random (or pseudo-random). The unique identifier itself is largely invisible to the user; instead, the human-readable name (alias) and part number are retrieved from the database through association.

[0394] The identifier itself is a random string and does not encode information, but it acquires meaning by being associated with metadata in the cloud database. Product names, team-specific part numbers, and production batch numbers can all be linked to this identifier as associations in the database.

[0395] This approach complements any existing or future specific naming or numbering technologies (such as vehicle part numbers, PCB part numbers, IO serial numbers, electronic component naming) and is not intended to replace these human-centered constructs.

[0396] Conversely, Arrival's unique identifier numbering will be sufficiently complex to allow other or existing part numbering systems to be associated with it. This means we can retain any team / discipline / product / organization-specific naming conventions without forcing consensus or reducing usability.

[0397] Tagging System: The graphical layout of tag elements, ready to be applied to parts or products, combining Arrival's modular symbol library and unique identifiers with the program layout framework.

[0398] Arrival Unique Identifier is a machine-readable visual mark that encodes a unique Arrival identifier to support the identification of Arrival products and components using computer vision.

[0399] Figure 16 This is an example of an Arrival unique identifier tag. The tag can be scanned using a smartphone, camera, or barcode reader. When you scan an Arrival identifier tag, you can retrieve information about that specific product from a cloud database. The identifier tag is a passive optical 2D barcode, enabling part identification and traceability throughout its entire lifecycle without physical or electronic interaction. The identifier tag is a specific variant of a data matrix that encodes the Arrival unique identifier number. The identifier tag does not directly encode any meaningful information, but information can be retrieved from a database upon scanning. The database can be implemented as follows:

[0400] Stored identifiers: Identifiers will be persistent and remain unchanged in the database. They are immutable.

[0401] Linking identifiers: It should be possible to link one identifier to another. Associations can be used to nest parts within components, or products within bulk packaging;

[0402] Link other entities: Associate discrete PCB components, PCB part numbers (following existing sequential naming conventions), and human-readable product names with the same unique identifier.

[0403] Linked metadata: documents, production equipment data, performance throughout the entire lifecycle, test results, decisions / approvals, etc.

[0404] Direct Part Marking (DMT) technology: Permanent marking of physical components using the graphical output of the Arrival tagging system, facilitating reliable identification and tracking throughout their lifecycle. DMT is the process of permanently marking parts using graphical information generated using the Arrival tagging system, including a unique Arrival identifier. This allows for part tracking throughout its entire lifecycle and can assist with data logging for safety, warranty purposes, and regulatory compliance.

[0405] Several techniques exist for permanently marking parts; the most common is laser etching, which is the preferred choice for most types of parts. It is important to note that the identifier must be unique for each instance of the product, meaning the graphic must be changed and cannot be part of the tooling. Therefore, digital processes such as laser marking, inkjet printing, and direct (maskless) digital imaging are more suitable for marking parts.

[0406] Layout framework: An algorithm used to generate tags for Arrival parts. Similar to how CSS (Cascading Style Sheets) renders and arranges content in a predictable way. CSS uses a cascading priority scheme to determine which rule applies to each element. Individual product tags are derived from a modular symbol library (ideally automatically / programmatically)—only those suitable for the specific application are shown. Figure 17 An example Arrival part label is shown.

[0407] We can summarize it as follows:

[0408] A vehicle component that is modularized or standardized in such a way as part of a series of other types of components, each component using the same standardized identification system that provides a unique identifier for each individual component, the identifier being (i) computer-readable but not meaningful to humans; and (ii) enabling the tracking of each individual component from initial production to initial installation and subsequent maintenance and end-of-life.

[0409] Optional features

[0410] • Supply chain systems that use intelligence or computers to track components.

[0411] • Real-time component data is fed into a computer-implemented supply chain system, which automatically adjusts supply chain parameters based on the real-time data, such as which components to order and their delivery schedule.

[0412] • Real-time data fed into the computer-implemented supply chain system includes real-time installation data.

[0413] • Real-time data fed into the computer-implemented supply chain system includes real-time component performance data.

[0414] • Real-time data fed into the computer-implemented supply chain system includes real-time component maintenance data.

[0415] • Real-time data fed into the computer-implemented supply chain system includes real-time component failure data.

[0416] Real-time component data is fed into the A / B testing system for analysis.

[0417] • Analyze real-time component data for predictive maintenance.

[0418] • The unique identifier is a 2D barcode and / or RFID tag.

[0419] • A component is any part used in a vehicle.

[0420] Feature 9: Modular hardware components are black.

[0421] Automated computer vision systems are used for object 6DoF pose estimation. Components with flat surfaces that meet at sharp edges are more readily used by computer vision systems for tracking and running object detection and 6DoF pose estimation algorithms. However, uneven coloring can confuse edge detection systems and make pose estimation less reliable. Many electronic arrival components require efficient heat dissipation: for example, ECUs, battery modules, and integrated drive units all require efficient and predictable heat dissipation. Arrival components can meet both of these requirements by coloring the components essentially black.

[0422] We can summarize it as follows:

[0423] A vehicle component that is modular or standardized in a manner that is part of a series of other types of components, all of which are optimized for robotic computer vision systems and optimized for radiative heat dissipation by being predominantly black.

[0424] Optional features

[0425] Other types of component series include one or more of the following: battery modules; main BMS; low-voltage batteries; on-board chargers; charge controllers; DC-DC converters; integrated drive units; traction inverters; drive control units; communication modules; Ethernet switches; HMI platforms; video surveillance systems; vehicle audio engine platforms; unified computing; sensors; weight sensors; computer vision sensors; LiDAR sensors; and radar-based sensors.

[0426] Chapter B: Software Modularization: Unified Software Architecture and "Plug and Play" Approach

[0427] Introduction to Chapter B

[0428] The Plug and Play (PnP) approach is based on the modularity of Arrival software components and enables Arrival electronics, applications, and services to function correctly once an Arrival vehicle or product begins operation. The Arrival software and control approach is designed to support the vision of a modular and scalable "device on wheels." Standards within the Plug and Play framework capture the key aspects of software modularity required to achieve this vision. Both hardware and software modules are secure, intelligent, and capable of reporting their health status to the Arrival cloud. Once an Arrival component is plugged into an Arrival vehicle, it will begin operating easily and automatically, requiring no configuration or modification of existing systems.

[0429] Plug and play is the software equivalent of large and small architecture systems, namely the modular hardware platform described in Section A of the previous article.

[0430] Unified software architecture

[0431] To configure software components in a similar manner, the software architecture provides:

[0432] Unified communication between all software components

[0433] Unified communication between all software components and the cloud or server

[0434] Unified monitoring and diagnosis

[0435] • Standardize cybersecurity measures (such as protocols / authentication procedures)

[0436] Unified configuration and update procedures

[0437] Arrival's unified software architecture is based on the following principles:

[0438] Software modularization The modularity of embedded software in control modules (ECUs) allows for customization of the software based on the individual requirements of the ECU and its task within the automotive architecture. Furthermore, this highly cohesive architecture limits the individual responsibilities of software modules—each software component will typically perform a small or specific set of tasks. Such software modules are also known as modular software components.

[0439] Layered software architecture The embedded software of the control module is decomposed into an application layer and a base software layer, which allows for reduced coupling between the embedded software and hardware components of the control module. This approach allows for the reuse of software components and parts, especially application-layer software components, in different vehicle models with different hardware topologies.

[0440] Self-containedAdding a new module adds new features, functionalities, or powers. Functionality is assigned to modules. Modules are not only responsible for delivering functionality but also for reporting the extent to which they can implement that functionality, for example, in the following ways: "I am not ASILD"; "I can do it for a year"; "I don't know, my sensor is faulty".

[0441] public communications The components are configured to share information with each other. Network protocols are the primary basis for communication.

[0442] Pre-configuration (automatic initialization) All components are easily integrated as pre-configured and can be automatically initialized.

[0443] Self-perception The software component supports the hardware's self-awareness characteristics; provides health monitoring; problem detection (awareness); root cause identification; solution identification (smart – handling situations outside of "normal" scenarios); and problem resolution (fixing).

[0444] Potential value The software component supports calculating the remaining lifespan of hardware, such as impact-damaged or scrapped vehicles, for reuse and refurbishment.

[0445] Unified software architecture also provides secure, distributed, fault-tolerant, and updatable / upgradeable software solutions.

[0446] Implementing the above principles in the Arrival system enables the following:

[0447] Vehicle knowledge base system: Out-of-the-box vehicle systems that are configured, tested, and pre-integrated with each other, with flexible deployment options. The Arrival knowledge base includes catalogs or libraries of developed system features, system functions, software components, hardware components, vehicle models, etc.

[0448] Common Technology Framework: The Arrival Technology Platform (ATP) and the entire Arrival system provide a common technology framework to build and maintain new models in a simple and consistent manner based on common and unified architectural principles.

[0449] Integrated toolchain: The common technology framework allows all vehicle specifications to be defined according to preset requirements and the consistency of the overall vehicle architecture to be verified through Arrival tools such as vehicle builders, version control systems, automotive factories and integrated development environments (IDEs).

[0450] A brief overview of the figures related to Chapter B.

[0451] Arrival's unified software architecture, software modularity, plug-and-play approach, and automated vehicle design tools—some features, implementation methods, and examples for vehicle builders—are illustrated in the accompanying drawings, in which:

[0452] Figure 18 —A functional model of external lighting characteristics;

[0453] Figure 19 —— Figure 18 Structural model of external lighting characteristics;

[0454] Figure 20 —A modified structural model of the external lighting features;

[0455] Figure 21 —Another modified structural model of a version of the external lighting features;

[0456] Figure 22 —— Figure 18 External lighting features in the vehicle's hardware topology;

[0457] Figure 23 — Applicable to Figure 22 The logical scheme of the software components of the hardware topology;

[0458] Figure 24 —— Figure 23 The software allocation scheme for software components on the two ECUs;

[0459] Figure 25 —The content of metadata for modular software components;

[0460] Figure 26 —Software Component (SWC) metamodel;

[0461] Figure 27 —A diagram of the ports and interfaces of the SWC metamodel;

[0462] Figure 28 —A graph of sender-receiver communication in the SWC metamodel;

[0463] Figure 29 —A diagram of n:1 communication in the SWC metamodel;

[0464] Figure 30 —A diagram of client-server communication in the SWC metamodel;

[0465] Figure 31 —A diagram of software component connectors in the SWC metamodel;

[0466] Figure 32 —A diagram of port groups in the SWC metamodel;

[0467] Figure 33 — A diagram of all types of SWC ports and connections, with graphic symbols;

[0468] Figure 34 —A diagram illustrating the integration between the abstract software and hardware components of the ECU;

[0469] Figure 35 —System software and hardware component metamodel;

[0470] Figure 36 —System meta-model;

[0471] Figure 37 —Diagrams illustrating the vehicle design process used by vehicle builders;

[0472] Figure 38 —A graph of data structures obtained and used by vehicle builders;

[0473] Figure 39 — A diagram of a hybrid network in a vehicle.

[0474] Detailed description related to Chapter B

[0475] Plug and play for vehicles

[0476] The goal of the Plug and Play (PnP) approach is for any vehicle or product to be designed to function the minute after assembly. Once you have a fully modular set of hardware and software components, it becomes impossible to develop, build, and test many different variations of a possible vehicle. Therefore, Arrival created the Vehicle Builder tool (see also Chapter D), which enables the virtual design of any vehicle, selection of all desired features and functions, and then the Vehicle Builder tool automatically configures the hardware components, wiring, networking, software components, and their allocation throughout the vehicle. This is a highly complex task, typically solved through extensive manual work by many developers, engineers, and experts, but the Vehicle Builder is configured to build vehicles quickly, automatically, and consistently.

[0477] Vehicle builders implement several unique algorithms for the automated creation and configuration of vehicles, including ECU layout, wiring harness routing, automated network design, and then the allocation of software components between the vehicle's hardware, as described in more detail below.

[0478] Let us refer to Figures 18-21 The illustrations use simplified examples to explain the process of designing vehicle configurations.

[0479] Figure 18This is a schematic diagram of a functional model illustrating an external lighting feature. This model is based on Arrival's vehicle knowledge base system and can be used as input to the vehicle builder tool, enabling the design of vehicles with this feature. To this end, the vehicle builder tool includes a user interface (UI) that allows users to select and manage desired features for the vehicle. Alternatively, the vehicle builder can automatically add recommended or required features to the vehicle, which users can then approve or reject.

[0480] For example, system feature 200 "Exterior Lighting" can be selected by the user in the Vehicle Builder UI or automatically added as a default feature of the vehicle by the Vehicle Builder tool. Based on this input, the Vehicle Builder tool determines which system functions and hardware components, among those available in the Arrival technology platform, are required to provide feature 200 in the vehicle. In the given example, it is determined that feature 201 "Low Beam," feature 202 "Low Beam Request," two hardware components—"Headlights" 203 and "Lamp Sensor" 204—and an ECU 205 for controlling the hardware components are required.

[0481] Figure 19 The diagram illustrates the structural model of system feature 200, including both software and hardware levels. The software level comprises a set of modular software components that can be assigned to the ECU 205 to control hardware-level components 203 and 204. These modular software components are the lamp sensor driver 206, the light control component 207, and the headlight driver 208.

[0482] Arrival's ECUs (also known as input / output (I / O) modules), such as the ECU 205, are one of the technical supports for the PnP approach. An ECU is a robust and highly integrated automotive controller with protected and reconfigurable universal inputs / outputs. It provides connectivity between onboard processing systems and peripheral input / output systems.

[0483] Arrival's ECU is also characterized by the following:

[0484] • Grid-sized table (based on Arrival size architecture)

[0485] • Automotive network communication interfaces, such as Ethernet, CAN, and LIN

[0486] General purpose input / output (I / O)

[0487] Analog input

[0488] • High / low side output (e.g., 3A)

[0489] • Different voltage supplies (e.g., 5V, 12V, and 24V)

[0490] • Pull-up / pull-down sensor

[0491] • Robust environmental protection (e.g., IP6K9K)

[0492] • Appropriate functional safety level (e.g., ASIL-B ISO 26262)

[0493] Arrival's ECUs' general-purpose input / output (IO) or general-purpose pins are designed so that their functions are software-defined.

[0494] Analog inputs to an ECU are typically used to connect to analog sensors, such as those associated with electromechanical components like brake and accelerator pedals.

[0495] As can be seen, the configuration required to implement system feature 200 is not that complex. However, the problem lies in the fact that system configuration complexity increases significantly with any development or improvement of the desired system feature. Even minor updates to lighting feature 200, such as automatic daytime running lights, require a set of software and hardware modifications, such as... Figure 20 and Figure 21 As shown in the diagram.

[0496] exist Figure 20 The diagram illustrates a modified structural model, showing how to modify the design in a vehicle where the lamp sensor component 204 is sufficiently far from the headlight component 203 to require an additional ECU 209 (e.g., in the vehicle's dashboard) for controlling the headlight component 203. Figure 19 The structure is as follows. In a given case, the lamp sensor driver 206 is assigned to ECU 209, and the CAN bus 210 is used to enable communication between ECU 205 and ECU 209, and thus between the software components 206 and 207 residing on these ECUs.

[0497] Figure 21 The illustration shows the situation when the designed vehicle includes a toggle switch 211. Figure 19 Another modification to the structural model shown. In the given case, the toggle switch hardware component 211 is connected to a nearby ECU 209, and the corresponding software component—the toggle switch driver 211—is assigned to the same ECU 209. In this case, if the existing CAN bus 210 has sufficient bandwidth to ensure communication between all required components, there is no need to introduce a new network connection (as in the illustrated example).

[0498] Those skilled in the art will understand that, for clarity, the above examples have been simplified, showing the external lighting system features separately and independently from any other vehicle systems and features. For real vehicles with a wide variety of system features, the overall complexity of the design process and final configuration is extremely high.

[0499] This is why the conventional approach to the vehicle design process requires a significant amount of manpower, time, and expense to implement any changes to the vehicle configuration, even in the case of updating or developing a system feature of the vehicle.

[0500] Compared to conventional vehicles, the Arrival system includes a knowledge base for developing out-of-the-box vehicle systems that are tested and pre-integrated with each other, and a vehicle builder that is an automated vehicle design tool that allows for simple and rapid development and modification of vehicle designs.

[0501] Figures 22-24 The diagram illustrates the hardware topology, software components and connection logic, and software allocation scheme that can be used to design external lighting features 200 in vehicle builders.

[0502] Figure 22 The illustration shows the hardware topology of external lighting feature 200 in a vehicle, which can be used as input to the vehicle builder or can be defined within the vehicle builder. This topology corresponds to... Figure 21 The hardware level of the structural model shown in the figure includes: a toggle switch 211 and a lamp sensor 204 connected to ECU 209, a headlight 203 connected to ECU 205, and a CAN bus 210 connecting ECUs 205 and 209 to each other.

[0503] Figure 23 The diagram illustrates the logical scheme of software components or system functions, as well as their ports and interfaces, which can be used to control, for example... Figure 22 The hardware components shown enable the provision of external lighting feature 200 in the designed vehicle. Figure 23 The plan and Figure 21 The difference in its software components lies in the inclusion of an additional component—the internal light manager 212A. This type of logic can be defined (manually or automatically) by vehicle builders using a library of modular hardware and software components, system functions, and features provided by the Arrival system.

[0504] Figure 24 The diagram illustrates an example of a software distribution and integration scheme, detailing... Figure 23The software components are allocated on ECUs 205 and 209 and connected via their interfaces and ports. Automatic allocation of software components to hardware components is one of the functions of the vehicle builder. The resulting allocation scheme specifically defines which part of the data exchange between software components occurs outside the individual ECU via the vehicle network, i.e., via a physical network bus such as the CAN bus 210. Figure 24 The layered software architecture of Arrival is further illustrated, in which the embedded software is decomposed into an application layer 213 and a basic software layer 214.

[0505] Figures 22-24 This illustrates a simplified example of using the Arrival system, a unified software architecture, and a vehicle builder to design plug-and-play system features for a vehicle: once the vehicle builder generates the system configuration and software allocation scheme, it creates firmware for the vehicle's ECUs, enabling plug-and-play functionality for the vehicle. As mentioned above, software modularity is one of the keys to automating vehicle system design within the vehicle builder.

[0506] Each software component designed according to the principles of software modularization and plug-and-play methods contains specifications in the form of metadata about its related attributes, functions, interfaces, resources, and requirements. For example, Figure 25 The illustration shows the contents of the metadata 215 of the modular software component 216, including complete information about the hardware interface (or interface for the equipment) 217, the software interface 218, the resources 219, and the requirements 220.

[0507] Vehicle builders are configured to automatically define possible hardware and software configurations based on the requirements and capabilities of software components, tailored to system characteristics, functions, ECUs, and other modular hardware components. This is possible because Arrival's modular software components are self-contained.

[0508] Software modularization is described in more detail below.

[0509] There are two options for implementing software modularization: pre-compiled packages and source code packages. Both options are used in the Arrival system, depending on the circumstances and applicable requirements.

[0510] To this end, Arrival's unified software architecture utilizes a set of meta-models describing software components, including application software, system software, interfaces and ports, hardware components, and the system itself. The principles underlying these models, their creation, and their use are disclosed below.

[0511] The software component model is a Unified Modeling Language (UML) domain model developed for software components within the application software layer of Arrival. The domain model is a UML metamodel, created primarily to support component-based software architectures, enabling modularity, reusability, scalability, and reduced dependencies between hardware and software.

[0512] The software component model is the definition of Arrival's software component semantics, that is, what the software component means, the syntax of the software component, how they are represented, composed, connected, and what all the attributes associated with them are (ports, form factors, interfaces, connectors, etc.). The model is useful and meaningful as long as the actual implementation of the software component conforms to it.

[0513] The following nomenclature (including the figures referenced below) will be used:

[0514] SWC (or SW-C) stands for Software Component;

[0515] VFB—Virtual Function Bus;

[0516] P port — provider port,

[0517] R port — receiver port

[0518] Aggr — Aggregation (used to specify whether an attribute is aggregated in a metaclass);

[0519] Ref — Reference (used to specify whether a property is referenced by the metaclass).

[0520] In the context of component-based software architecture, a software component is defined as a self-contained object that encapsulates certain functionalities and can interact with its environment via defined ports and interfaces.

[0521] Software components (SWCs) are the central structural elements (basic building blocks) of application software architecture.

[0522] By design, SWC is configured to provide the following features:

[0523] • Reusability: Components are designed to be sufficiently atomic, so reusability can occur across applications and product lines, for example, different vehicles and even vehicle types.

[0524] • Portability: Thanks to the hardware abstraction provided by Arrival's unified software architecture, components can be assigned to different ECUs.

[0525] • Scalability: Common components can be adapted to different vehicle platforms, thus avoiding the proliferation of software with similar functions. Software components can extend existing components to provide new behaviors or functions.

[0526] • Encapsulation: Components do not expose any aspect of their internal behavior, and only the interfaces they require / provide are visible in the architecture.

[0527] • Independence: Components are designed to have minimal dependence on other components, thereby achieving software modularity.

[0528] Software component model

[0529] The SWC model is a UML-specific metamodel that contains all types of architectural elements (metaclasses) and formal relationships associated with software components within the application software layer of Arrival. The following section presents and explains all relevant metamodel class diagrams in detail.

[0530] Software component metaclasses and associated templates

[0531] Figure 26 The diagram illustrates a software component metaclass. A software component metaclass represents a software component in the application layer; it is a self-contained architectural element as described above.

[0532] Depending on the type of software component within the application layer, different version types are suitable for SWC, such as... Figure 26 As specified.

[0533] At this point, it's worth clarifying the concept of "atomic": an atomic software component is atomic because it cannot be further decomposed and distributed across multiple ECUs. Atomic software components are characterized because they can aggregate internal behaviors (which would not apply in the case of parametric software components).

[0534] All relevant properties associated with atomic software components (application SWC, driver SWC, parameter SWC, and ECU abstraction SWC) and composite software component metaclasses at the VBF level are specified below.

[0535] Software Part 221 is the abstract and "parent" class for all types of software parts (atomic and non-atomic). Attributes associated with the parent class will be inherited by all children.

[0536] Software component classes have the following properties:

[0537] id (type: string) — Defines a unique identifier for a software component in Arrival's component library.

[0538] Name (Type: string) — Defines the human-readable name of the software component.

[0539] Description (type: string) — A human-readable description that defines a software component.

[0540] Repository (type: string) — The complete path to the repository where the SWC specification and source code are located.

[0541] Port (Type: Aggregation) — Defines a set of SWC ports that the SWC possesses, which can be R ports, P ports, or both.

[0542] Port_Group (Type: Aggregation) — Defines a port group (a group of ports that share common functions, such as specific network resources) that is part of a component.

[0543] The Atomic Software Component 222 class is the parent class associated with all types of atomic software components.

[0544] The atomic SWC class has the following properties:

[0545] Internal_behavior(type: string) — Defines the internal behavior of the SWC type located in different physical files.

[0546] Application software component class 223 is a subtype of atomic SWC 222 and is associated with an application or a part of an application. It allows the application SWC to be used with other software components in all types of communication modes (client / server, sender / receiver).

[0547] The SWC class has the following properties:

[0548] Supported Features (Type: String) — Defines a reference to the vehicle features supported by this component. These features are defined in the vehicle builder and are used to automatically load all necessary software components based on which feature set is selected.

[0549] Driver software component type 224 is associated with atomic components that handle the specific tasks of sensors and actuators in third-party E / E components. The driver SWC is typically located on the same ECU as the sensor / actuator it processes.

[0550] The driver SWC class has the following properties:

[0551] Supported _Component (Type: String) — Defines a reference to a third-party E / E component that this driver can sense or actuate. If this field is empty, the driver software component is generic and can be used for different types of E / E components, or the driver is configured to work with several different types of E / E components simultaneously.

[0552] This attribute field is used to automatically assign a driver to a specific hardware component in the vehicle builder.

[0553] Parameter SWC 225 is a software component whose sole purpose is to provide values ​​for calibrating other components. This component is atomic, but it differs from other atomic software components because it has no associated internal behavior.

[0554] The ECU Abstract Software Component 226 class is associated with atomic components that provide other types of software components with access to the ECU electronics. In other words, this type of SWC introduces the possibility of linking from the software representation to its hardware description, abstracting the location of peripheral I / O devices and the ECU hardware layout, and therefore has a certain degree of hardware dependency.

[0555] The ECU abstract software component type has the following attributes:

[0556] Hardware_Component_id (Type: Reference) — Defines a reference to a unique identifier for a hardware component that is specific to the system software.

[0557] Hardware_Component_Version (Type: String) — Defines the range of versions of the hardware components for which this system software is dedicated.

[0558] Logically grouped and interconnected multiple SWCs can be considered as composite or compound software components (SWCs) 227. A compound SWC 227 is a non-atomic component that abstracts a collection of atomic software components that can work together at the VFB level.

[0559] Composite software component types have the following attributes:

[0560] Component (Type: Aggregate) — Defines the internal SWC that forms the composite SWC. At this point, the internal SWC can only be of the type of application SWC, parameter SWC, and driver SWC.

[0561] Software component ports and interfaces

[0562] All interactions between software components, such as synchronous or asynchronous procedure calls, and sending and receiving messages over a network, are described in Arrival's software component model using the "port-interface" design pattern. This pattern defines only one rule—the interfaces of two ports must be compatible to interconnect these ports.

[0563] The types of ports and their interfaces Figure 27 It is shown in the figure and described in more detail below.

[0564] Software component port (SWC port) 228 is the interaction point through which software components communicate with their environment. Since software components are encapsulated classifiers, and therefore have the ability to own ports, these ports can be understood as attributes of the software component metaclass. Each port instance can only be assigned to one specific software component instance.

[0565] The metamodel containing the types of ports and interfaces in the SWC model is in Figure 27 As shown in the image.

[0566] like Figure 27 As can be seen, all software component ports are classified by interface type. An interface represents the type of communication (data and service-oriented) with other software components. To connect software component ports, they must share the same interface type. Connections between ports occur using elements called connectors, which will be described in more detail below.

[0567] Software component ports can be of two types:

[0568] • Port 229 is provided, which provides data or services to the server as defined in the port interface.

[0569] • The required port is 230, which requests data or services from the server as defined in the port interface.

[0570] Sender-Receiver Communication

[0571] This type of communication allows for the specification of typical asynchronous communication patterns, where the sender provides the data required by one or more receivers. This type of communication is provided by the sender-receiver interface 231.

[0572] Sender-receiver interface 231 is Figure 27 Part of the diagram. More details on sender-receiver communication are in... Figure 28 As shown in the figure, Figure 28 A separate diagram including the types of sender-receiver interface 231.

[0573] Sender port 232 is a subtype of provider port 229 and is associated with a port that is subtyped by sender-receiver interface 231.

[0574] The sender port 232 type has the following attributes:

[0575] id (type: string) — A unique identifier that defines a port within the scope of a software component.

[0576] Name (Type: string) — Defines the human-readable name of the software component.

[0577] Port_Interface(Type: Reference) — Defines a port interface used for port prototyping; it can be a client / server interface, sender / receiver interface, or parameter interface. This type of interface is only used for interconnect-compatible ports.

[0578] Connector (Type: Reference) — Defines the connector that connects this port to other SWC ports; it can be an assembly connector (P port to R port) or a delegate connector (P port to P port).

[0579] Receiver port 233 is a subtype of the required port 230 prototype and is associated with the port typed by sender-receiver interface 231.

[0580] The receiver port 233 type has the following attributes:

[0581] id (type: string) — A unique identifier that defines a port within the scope of a software component.

[0582] Name (Type: string) — Defines the human-readable name of the software component.

[0583] Port_Interface(Type: Reference) — Defines a port interface used for port prototyping; it can be a client / server interface, sender / receiver interface, or parameter interface. This type of interface is only used for interconnect-compatible ports.

[0584] Connector (Type: Reference) — Defines the connector that connects this port to other SWC ports; it can be an assembly connector (P port to R port) or a delegate connector (P port to P port).

[0585] The sender-receiver interface 231 is an interface used in sender-receiver communication scenarios. This type of interface allows for the specification of typical asynchronous communication patterns, where the sender provides data required by one or more receivers.

[0586] The sender-receiver port interface type 231 has the following attributes:

[0587] Message (Type: Reference) — Defines a message to be sent or received, as declared by the interface.

[0588] The sender-receiver interface formally specifies the types of information sent and received; the data element type can practically be anything (integers, complex arrays, strings, etc.). This interface is used for data exchange between software components, particularly when the sender needs to send information to any number of receivers. Receivers have complete freedom in when and how they use the data elements provided by the sender, and they are not informed of the information being used. The idea behind this is that each data element sent / received within a software component (primarily between application SWCs) will have a physical network signal associated with it.

[0589] The sender is completely decoupled from any receiver, and it is unaware of how many (if any) receivers are using the values ​​it produces. The sender can provide data elements in different ways, such as a "last is best" approach, meaning the sender makes the last available value the current one, or an alternative is a "queuing" approach, where values ​​are stored in a queue of a predefined size.

[0590] like Figure 28 As shown, message class 234 can be classified into three types of messages: Local Interconnect Network (LIN) message 235, CAN message 236, and Ethernet (ETH) message 237.

[0591] The only way to interconnect two ports is to make a connector, such as the assembly connector 238 between the sender and receiver ports, with the same identifier and the same internal message.

[0592] Figure 29 The diagram illustrates a correct n:1 communication scenario, where the same data element is provided by two different software components but is needed by one receiver (n:1). In the illustrated case, the external light manager (external light manager) 239 (application SWC) obtains the status of the front and rear indicators on different ports—Find status 240 and Rind status 241, respectively. Based on these statuses, the command IndCmd 242, used to turn a specific indicator (the front indicator controlled by the front indicator driver 243 or the rear indicator controlled by the rear indicator driver 244 (both are driver SWCs)) can be correctly configured by the external light manager 239.

[0593] Client-server communication

[0594] Client-server interface 245 is the interface used in the case of client-server communication and declares the number of operations that the client can invoke on the server (instead of the information passed between software parts as in the case of sender-receiver interface).

[0595] The client initiates communication, requesting the server to perform a specific service (operation call), which triggers the server to execute the required operation (the server will never start the operation itself). Once the operation is executed, the server provides the result to the client (synchronous operation call); otherwise, the client checks for the completion of the operation itself (asynchronous operation call).

[0596] Client-server interface 245 is Figure 27 Part of the diagram, and Figure 30 The interface is illustrated in further detail, with a separate diagram showing the metamodel used to describe client-server communication.

[0597] As shown in the figure, the client-server interface 245 operates between client port 246 and server port 247. In Arrival's metamodel, these types of ports are used to describe communication between the driver SWC and the ECU-abstract SWC. Therefore, client port 246 is designated as port 248 for I / O, and server port 247 is designated as port 249 for I / O provision.

[0598] The port 248 class required for IO is a subtype of the port 230 prototype required by the IO interface 250.

[0599] The port type required for I / O has the following attributes:

[0600] id (type: string) — A unique identifier that defines a port across all receiver ports of all software components in the library.

[0601] Name (Type: string) — Defines a human-readable name for the port; the name is used to distinguish ports during the modeling process in the vehicle builder.

[0602] Port_Interface(Type: Reference) — Defines the port interface used for port prototyping; it can be a client / server interface or a subtype thereof. This type of interface is only used for interconnect-compatible ports.

[0603] The IO-provided port 249 class is a subtype of the IO interface 250 provider port 229 prototype.

[0604] The port types provided by IO have the following attributes, similar to the port types required by IO:

[0605] id (type: string) — A unique identifier that defines a port across all receiver ports of all software components in the library.

[0606] Name (Type: string) — Defines a human-readable name for the port; the name is used to distinguish ports during the modeling process in the vehicle builder.

[0607] Port_Interface(Type: Reference) — Defines the port interface used for port prototyping; it can be a client / server interface or a subtype thereof. This type of interface is only used for interconnect-compatible ports.

[0608] The IO interface class 250 is a subtype of the client-server interface 245 and is associated with a set of capabilities provided or required by the port.

[0609] The application software is configured to initiate communication, requesting specific permissions from the system software, which triggers the server to perform the required operations. For example, when the application software (application SWC) needs access to an analog input / output (I / O) interface, the system software (general-purpose I / O driver) provides the permissions to access specific hardware contacts. This situation is defined by two ports and the connection between them—the first port is port 248, required by the I / O from the application SWC side, and the second port is port 249, provided by the I / O from the ECU-abstract SWC side. The connection can only be established if these ports have compatible interfaces. In other words, the permissions provided by the port provided by the I / O must be greater than or equal to the permissions required by the port required by the I / O.

[0610] IO interface type 250 has the following properties:

[0611] Capabilities (Type: Aggregation) — Defines what capabilities a port provides or requires. 251.

[0612] Capabilities[i].Parameters(type: aggregate) — Defines parameters 252 (if they exist) for each of the capabilities 251 associated with the IO interface.

[0613] Calibration data communication

[0614] Parameter interface 253 can only be owned by parameter software component type 225 and it does not establish actual data transmission, but it exposes the concept of software components that access fixed, constant, calibration data.

[0615] The parameter port interface type has the following attributes:

[0616] Name (Type: string) — Defines the name of the parameter interface.

[0617] Parameter data element (type: reference) — Defines an interface that provides one or more data elements (calibration data) for calibrating other SWCs.

[0618] The parameter interface 253 is always provided by the parameter SWC, and it can be required by the application SWC, composite SWC, or sensor-actuator SWC.

[0619] Parameter port 254 is a subtype of provider port prototype 229, which is derived from parameter interface and owned by parameter SWC.

[0620] The parameter port has the following attributes:

[0621] Name (Type: string) — Defines the name of the port.

[0622] Port Interface (Type: Reference) — Defines the name of the parameter interface for the parameter port type.

[0623] Connector (Type: Reference) — Defines the connector that connects this port to other SWC ports; they can be assembly connectors (P port to R port) or delegate connectors (P port to P port).

[0624] Software component connector

[0625] Software component connector class 255 is associated with R-port 230 and P-port 229 used to connect software components, or elements symbolizing software assembly. A diagram of the SWC connector element class is shown in... Figure 31 Presented in the middle.

[0626] There are two different types of SWC connectors—assembly connector 256 and delegate connector 257. Assembly connector 256 is used to describe the connection between R port 230 and P port 229, and delegate connector 257 is used to expose the SWC port outside the software component assembly.

[0627] Assemble connectors of class 256 are associated with elements used to connect R-ports and P-ports that are classified by the same port interface type.

[0628] Assembly connector types have the following attributes:

[0629] Provider (type: reference) — Defines a reference to an instance that provides the port.

[0630] Requester (type: reference) — Defines a reference to an instance of the request port.

[0631] Delegated connectors of class 257 are associated with elements used to expose ports of internal software components to external interfaces of composite software components. Delegated connectors can only connect ports of the same type (P ports and P ports, or R ports and R ports).

[0632] The delegate connector type has the following attributes:

[0633] Internal Port (Type: Reference) — Defines a reference to an SWC port that belongs to an internal SWC within a composite SWC.

[0634] External Port (Type: Reference) — Defines a reference to an SWC port that is exposed outside the composite SWC.

[0635] Software component port group

[0636] Software component port groups define logical groups of port prototypes that serve as inputs to configure system software layers to provide ECU resources for these ports. Such port groups are defined locally within composite software components and refer to “external” ports belonging to embedded components. Figure 32 The diagram illustrates the port group model.

[0637] The primary use case for SWC port group 258 is to express the required communication resources for the ports included in the group (e.g., SWC port 228).

[0638] Network group 259 represents all sender ports 232 and / or receiver ports 233 included in the group using access to a single network. This information should be available to the vehicle builder during the SWC firmware assembly phase to allocate the required ECU resources to specific port groups. When this information is propagated to the ECU profile, it is used as input for configuring the ECU-abstraction layer in the system software.

[0639] Network group types have the following attributes:

[0640] id (type: string) — Defines a unique identifier for a group among all groups defined in the composite SWC.

[0641] Member (Type: Aggregate) — Defines a set of references to the external ports of the embedded components associated with this group.

[0642] Network_Interface(Type: Reference) — Defines a reference to a specific network interface, which is defined in the embedded ECU-abstract SWC to provide access to network resources.

[0643] Figure 33 Special graphic symbols are used to illustrate all types of software component ports and connections.

[0644] exist Figure 33 In this diagram, software components are depicted by rectangles with solid-line boundaries, with each component's identifier located within the software component boundary. SWC ports are described by specific icons placed on the software component boundaries, with each port identifier located within the software component boundary. The connection between sender port 232 and receiver port 233 is depicted with a solid line bearing an arrow pointing from the sender to the receiver, reflecting the "broadcast" nature (typically unidirectional) of communication between software components. The connection between port 248 (required for IO) and port 249 (provided for IO) is depicted with a solid line without an arrow; such connections are used between driver SWC 224 and ECU-abstract SWC 226 to illustrate generic pin driver calls from the application layer. Delegated connection 257 is used to expose sender port 232 or receiver port 233 of the embedded software component outside the ECU boundary.

[0645] Network interface 260 is depicted by a concrete icon placed on the boundary of ECU-abstract SWC 226. When sender port 232 or receiver port 233 is included in a concrete network group 259 to obtain access to a concrete network, these ports are connected to the corresponding network interface 260 via dashed lines.

[0646] Given the above, the software architecture that implements system features can be modeled in the vehicle builder tool using the SWC UML metamodel, including defining all necessary SWCs and their communication via appropriate interfaces. At this point, each software component port is typed by a specific interface, utilizing the definition of all necessary attributes of the interface.

[0647] Hardware-level components can be described using a similar domain model to enable vertical integration between application software, system software, and the hardware layer. The meta-model of hardware components and the format of hardware component specifications will be described in more detail below.

[0648] Application and system software compatibility can be described as a one-to-one relationship. This means that, for example, application SWC version ABC is only compatible with system software version XYZ. A list of compatible system software is presented in the metadata section of the application SWC. This ensures an explicit match between the application and system software versions.

[0649] The dependencies between system software and hardware components are described below.

[0650] The system software layer consists of two parts: the first part is a general collection of system software libraries, and the second part is specific system software components that provide the application layer with an abstraction for accessing hardware component resources. The first part is described in the application's SWC dependency file. The second part is published as a set of ECUs—abstract software components—with versions identical to the system software package—for each supported hardware component's XYZ.

[0651] Figure 34 use Figure 33 The graphic symbol schematically illustrates an example of integration between ECU – an abstract software component and a hardware component.

[0652] exist Figure 34 In the ECU-abstraction software component 226, there is an ID "IoModuleAbstractionSwc", and the hardware component 261 has an ID "IO_Module_B".

[0653] The ECU abstract software component 226 includes a service layer 262 consisting of two SWCs, a general-purpose pin driver 263 and a CAN driver (HL) 264, and a hardware abstraction layer 265 consisting of two SWCs, an ADC driver 266 and a CAN driver (LL) 267.

[0654] Hardware component 261 includes two components, mC peripheral device 268 and ECU electronics 269, and four physical contacts X2.11, X2.12, X2.21 and X2.22.

[0655] Each of the physical contacts X2.11 and X2.12 is included in the connection to form an I / O-provided port (AIN1) 248 using ECU electronics 269, mC peripherals 268, ADC driver 266, and general-purpose pin driver 263.

[0656] The two physical contacts X2.21 and X.2.22 are part of the network interface (CAN1) 260, which uses ECU electronics 269, mC peripherals 268, CAN driver (LL) 267 and CAN driver (HL) 264.

[0657] A version of system software can be compatible with different versions of the same type of component. In the context of the example above, ECU-abstraction software component 226 with ID='IoModuleAbstractionSwc' and version='0.18.0.0' can be compatible with hardware component 261 with ID='IoModule' and version range '>0.4.1<=0.4.3'.

[0658] In some cases, it may be necessary to directly specify what type (one or more) of hardware components can be deployed. This can be specified by setting constraints for hardware component selection in the software allocator device settings. Such constraints can be defined using key-value pairs and matching operations—equal or unequal.

[0659] System software and hardware component metamodel

[0660] The system software and hardware component model contains metaclasses and associated templates for describing ECUs—abstract software components, hardware components, and their relationships.

[0661] System software and hardware component metamodels in Figure 35 The diagram above illustrates the ECU-abstract SWC226 and the IO-provided port class 249.

[0662] The Network Interface 260 abstract class describes access to network resources. The network interface type has the following properties:

[0663] id (type: string) — A unique identifier that defines the network interface in this ECU-abstract software component.

[0664] Name (Type: String) — Defines the human-readable name of the interface, which is used to distinguish the interface from other components during the modeling phase in the vehicle builder.

[0665] This abstract class is implemented by concrete classes, depending on the type of network this interface is used for.

[0666] In addition, the CAN interface class 271 describes access to the CAN network, the LIN interface class 272 describes access to the LIN network, and the Ethernet (ETH) interface class 273 describes access to the Ethernet network.

[0667] Hardware component class 261 describes electrical / electronic (E / E) containers that can be used for control software deployment or as peripheral devices sensed or driven by driver software components on an ECU. Hardware component types have attributes such as id, name, and version, all of which are string types.

[0668] Hardware Contact 270 describes physical contacts and has attributes such as id, name, and type, all of which are string types.

[0669] System Model

[0670] Figure 36 A diagram representing the formal physical model of the composite system is shown.

[0671] It can be seen that the composite system model includes elements that are entities derived from other models (including the aforementioned software component meta-model and hardware component meta-model).

[0672] In the Arrival system, system specifications are generated based on models, such as... Figure 36 As shown.

[0673] System 274 is the basic entity type, existing to summarize the properties of the atomic system 275 and composite system 276 subtypes. It can also serve as the basis for other subtypes that may be developed in the Arrival system and model in the future.

[0674] The system itself is characterized as a collection of tightly linked component atoms, regardless of whether they originate from the software or hardware domain. This system encompasses a highly specific and well-defined set of system functions belonging to specific functional areas of Arrival's vehicles, such as low-voltage operation, vehicle status, and connected vehicles. Arrival's vehicles include systems such as HMIs, drive trains, and high-voltage power supplies. The system library contains all systems developed by Arrival.

[0675] The concept of Systems 274 within the Arrival vehicle platform reflects the fact that systems are entities that constitute the vehicle platform and are key achievements of Arrival technology. The system metamodel is designed to enable system development to adapt to the feature-driven development provided by Arrival's plug-and-play approach.

[0676] A fundamental property of System 274 is that the system is bound by a distribution program, and all its components are distributed along with the systems they contain. The driver for a newly released system is characterized as a carrier of a set of new system requirements.

[0677] System 274 tuple has the following properties:

[0678] id (type: string) — Defines a unique identifier for the system in the system library.

[0679] Name (type: string) — Defines the human-readable name of the system, such as "drive chain".

[0680] Description (type: string) — A human-readable description that defines the system.

[0681] Repository (type: string) — Defines a valid link to the software version control system; the complete path to the repository where the system specification is located.

[0682] Version (type: string) — Defines the version of the system described by this specification.

[0683] Software_Component (Type: Aggregate) — Defines a collection of "software component" entities. These are software components that "belong" to the system as part of it. The release cycles of these software components are strongly coupled to the system's release cycle, meaning that new versions of such software components may only appear with new releases of the system.

[0684] Assembly Connector (Type: Aggregate) — Defines a collection of "Assemble Connector" entities to define the logical connection between sender / receiver ports of SW components within the system.

[0685] Hardware_Component_Constraint(Type: Reference) — Defines an embedded structure that describes the hardware platform allocation constraints that the atomic system possesses.

[0686] Reference (type: aggregation) — Defines a set of external references to entities from other models.

[0687] Atomic system 275 is a subtype of system 274, which was introduced to describe:

[0688] - The monolithic Arrival system, without a clearly defined component scheme, allows for flexible allocation as firmware to multiple ECUs. This is possible because the software is built to run on special-purpose hardware boards, which in turn requires intentionally built underlying software to provide APIs for hardware capabilities.

[0689] - Third-party single-chip system.

[0690] Many types of constraints apply to atomic systems, but the modeling aspects of atomic systems should be:

[0691] - Clearly define the external interface of this type of monolithic system.

[0692] - Describe it as a single entity that occupies the entire hardware device on which it is designed to be hosted.

[0693] The general approach to modeling atomic system 275 is to describe it via two software components: applying SWC 223 and ECU abstraction SWC 226 to model the functional software layer and the foundational software layer of the atomic system. The application of SWC should then define hardware component constraints 277, which clearly point to the hardware platform supporting the atomic system.

[0694] Atomic system class 275 has the following properties:

[0695] Address (Type: String) — Defines the network address of an atomic system, for example, via a CAN node address.

[0696] Hardware component constraints 277 allow for the specification of hardware platform selection criteria for atomic systems 275. These can be described in a way that allows placement on multiple compatible hardware platforms, or simply by including references to specific hardware products with specific part numbers.

[0697] Composite system 276 is another subtype of system 274, which describes a looser group of software components, typically characterized by a unified release cycle. A composite system consists of zero or more atomic software components 222, assembly connectors 256 between them, and atomic systems 275.

[0698] Composite system class 276 has the following attributes:

[0699] Atom_System(Type: Aggregate) – A collection of “atomic system” entities; a composite system must exist if it does not reference at least one software component. All mentioned atomic systems are components of the composite system.

[0700] Each system in Arrival's system library has a system specification, which includes complete information about the system, all its parts, components, etc., as defined by the meta-model described above.

[0701] In addition, the system specification has the following characteristics:

[0702] - The content of the model follows the composite system model.

[0703] - The system specification is located at the path specified in its "repository" property.

[0704] - If the "repository" attribute includes a path to a directory, that directory should contain only one file as per the specification.

[0705] The above discloses the meta-model developed within the Arrival system to achieve a unified software architecture with software modularity, which further serves as the basis for the plug-and-play functionality of Arrival's vehicles and products.

[0706] Plug and play and vehicle builders

[0707] The Plug and Play (PnP) approach itself is a combination of architectural principles and methods used in the Arrival system.

[0708] A unified exchange format is a key element of ATP and the unified software architecture, facilitating the implementation of the PnP approach. Standardization of the exchange format within the Arrival system allows for the integration of all tools into a single toolchain to automate the PnP process. Therefore, all descriptions, specifications, and metadata within the Arrival system share a unified format, which is particularly suitable for describing base software, SWCs, system characteristics, ECU configurations, and vehicle specifications.

[0709] The PnP method is further based on the layered software architecture described above.

[0710] In ATP, the application software layer of the electrical / electronic (E / E) architecture is a collection of loosely coupled and highly cohesive modular software components. The loosely coupled architecture implies limited dependencies between software components, allowing software components to be relocated to different ECUs without altering the system design. Similarly, the highly cohesive architecture limits the individual responsibilities of modules—each software component will typically perform a small set of tasks.

[0711] The basic software layer provides the ability to develop application software with an E / E architecture that is completely independent of the hardware.

[0712] Through a unified layered software architecture, the Arrival system provides application software with a unified interface to access the electrical values ​​of the underlying ECUs, including:

[0713] - Functions of the virtual communication bus

[0714] - Metadata used for real-time allocation of software components

[0715] - Services that ensure the storage and maintenance of non-volatile data.

[0716] - Functions and data used for diagnosing each ECU

[0717] - Used to verify the functionality and data of vehicle systems

[0718] - A function to perform password authentication on signal values ​​in transmitted data packets.

[0719] All of the above are used and adopted in Vehicle Builder, a single automated tool used to design vehicle configurations based on input requirements. Vehicle Builder provides an automated design approach for the overall E / E architecture of a vehicle, and further allows for verification of the consistency of the designed E / E architecture, and even facilitates vehicle diagnostics in future use.

[0720] Figure 37 The illustration shows the vehicle design process using Vehicle Builder 278.

[0721] In the first step of the design process, the vehicle builder receives a set of desired system characteristics for the vehicle being designed as input. These characteristics can be defined by the user (such as a customer, designer, or engineer), for example, by selecting available options through the vehicle builder's user interface (UI). Alternatively, or as an alternative to a user-defined set of system characteristics, the vehicle builder is configured to add certain system characteristics to the configuration as default options, for example, if they are required for the proper functioning of the designed vehicle or are included in the base vehicle configuration.

[0722] In addition, such as Figure 37 As shown, a functional model 279 of the desired system features provided by the system architect can be provided to the vehicle builder. However, this is an optional input, as the vehicle builder has access to a functional library of system functions developed within ATP and can automatically match the desired system features with the available system functions. Thus, the vehicle builder is configured to automatically select the required system functions to provide the desired features in the vehicle and obtain or generate the required functional model of the selected system functions.

[0723] Similarly, a set of atomic SWCs 280 and hardware components 281 with the required system functions can be assigned to the vehicle builder to enable the provision of the desired system characteristics. These are also optional inputs, as the vehicle builder can access the software library of modular SWCs and the component library of hardware components within the ATP to automatically obtain the required SWCs and hardware components to implement the desired system functions.

[0724] Based on the desired system characteristics, related system functions, software and hardware components, including functional models, vehicle builders use automated wiring tools and algorithms to automatically generate:

[0725] - The vehicle's hardware and network topology, including optimized cabling schemes, and

[0726] - An optimized allocation scheme for SWC on the vehicle's ECU.

[0727] The automatic routing tools and algorithms are described in more detail below.

[0728] The generated configuration 282 for hardware, ECU, network, and SWC allocations can then be approved or edited by the user through the vehicle builder's UI. When the user manually changes the hardware configuration or modifies the software selections or allocations, the user can directly introduce modifications to the generated configuration, or by modifying any input data or related constraints and requirements to enable the automated wiring tool to perform a new cycle of the automated design process.

[0729] Furthermore, after the configuration is approved, the vehicle builder is configured to generate:

[0730] -Based on the data for harness routing 283 in the wiring scheme.

[0731] - Vehicle specification 284, and

[0732] - Firmware 285 for vehicle models.

[0733] Vehicle specifications include ECU software specifications 286 based on software allocation schemes and the relevant SWC specifications.

[0734] Furthermore, based on the vehicle model specification, the vehicle builder generates and outputs a release specification and diagnostic configuration 287, which enables the automatic verification of the designed vehicle model system by releasing verified firmware over-the-air (OTA) updates to the produced vehicles of that model. Additionally, the diagnostic configuration enables the automatic configuration of a remote diagnostic system for remote diagnostics of the model vehicle during use.

[0735] The above is achieved through comprehensive information about the vehicle systems and components available in ATP, thanks to the use of modular hardware, a unified software architecture with software modularity, a unified exchange format, and other tools and principles for plug-and-play methods.

[0736] Figure 38 The diagram schematically illustrates the data structures acquired and used by the vehicle builder during the vehicle design process. Hardware and network topology 288 provides information about which hardware components (including ECUs) will be used in the designed vehicle model (including the connections between them). Feature model 289 describes all system features to be implemented in the vehicle model and its interconnections. Logical scheme 290 (or functional model) includes information about the software components required to implement the system functions inherited from the feature model and the connections (interfaces and ports) between these components. Based on these data structures, combined processing, and an ATP library including function libraries, software libraries, and component libraries, the vehicle builder generates a vehicle model specification 291 that can be used for vehicle production.

[0737] In summary, the automated vehicle design process in Vehicle Builder provides plug-and-play functionality for Arrival vehicles. Based on the modularity and uniformity of all components and programs within the Arrival system, Vehicle Builder automatically provides the following features during the vehicle design phase:

[0738] -Complete vehicle specifications

[0739] - Optimized hardware / network topology and vehicle model wiring (including complete data on wiring harness routing for vehicle production).

[0740] -Prepare the firmware for all ECUs of this vehicle model, and

[0741] - A complete set of data and configurations used to verify and diagnose all vehicle systems and components.

[0742] This directly provides plug-and-play functionality for Arrival vehicles. A more detailed disclosure of the design process in vehicle builders, including a description of automated wiring tools and algorithms, is provided in Section D below.

[0743] Regarding the plug-and-play topic, we need to further disclose how public communications are implemented in Arrival's vehicles.

[0744] Public communication: Ethernet

[0745] In Arrival systems, Ethernet is the backbone; adopting Ethernet is a key enabler for reliable and cost-effective plug-and-play solutions.

[0746] The legacy bus system has reached its capacity limitations and requires a new, comprehensive, and timeless solution. Ethernet networking standards have been widely adopted as the networking technology of choice in the IT and telecommunications sectors, as well as the consumer electronics market, and have already seen significant adoption in industrial engineering and the aerospace industry. Ethernet and Internet Protocol (IP) are mature technologies with very high throughput across the IT industry. Ethernet provides the high bandwidth required to support the powerful computing and rapidly growing data transmission demands of modern vehicles, providing a reliable foundation for future automotive innovations.

[0747] Ethernet offers significant opportunities for building robust, flexible, modular, and cost-effective vehicle systems that can be scaled without altering the fundamental communication paradigm. The increased bandwidth unlocks creativity for new, timeless applications.

[0748] Using Ethernet as the communication backbone for Arrival vehicles makes commercial off-the-shelf (COTS) products from other mature sectors available, and opens up a sudden abundance of existing protocols, technologies, applications, and suppliers, providing independence and freedom of choice that is largely unavailable to conventional automotive OEMs.

[0749] While Ethernet is a mature and proven technology in IT and telecommunications, it is relatively new in the automotive sector, where safety requirements are more stringent. Most automotive OEMs already use Ethernet in vehicles, but only for non-safety-critical applications such as diagnostics and entertainment. No vehicles on the road use Ethernet proprietaryly (no CAN / LIN).

[0750] Compared to conventional approaches, the ultimate goal of the Arrival system is to use Ethernet for the entire Arrival vehicle wiring system—from infotainment to safety-critical functions. Alternatively, Arrival vehicles can use a hybrid of Ethernet at the core and existing network protocols toward peripherals connected via gateways.

[0751] Figure 39 The illustration depicts a possible hybrid networking solution for a vehicle. In the illustrated example, Ethernet is the primary bus used by evolving vehicle systems requiring high-speed network communication, such as powertrain system 293, advanced driver assistance system (ADAS) 294, and human-machine interface system 295. Furthermore, the illustrated vehicle network includes a CAN / LIN gateway 296 for connecting Ethernet to a CAN or LIN bus used by other vehicle systems with less network requirements, such as vehicle chassis 297 and vehicle body 298.

[0752] Ethernet is timeless; its flexibility and high bandwidth open up new possibilities for applications. It is scalable, requiring no changes to the fundamental communication paradigm. It is highly common, enabling Arrival systems to use the same protocols for vehicles as Arrival's robotic factory, production equipment, and AMRs, and for in-vehicle, vehicle-to-vehicle, and external communication. This common communication foundation provides further benefits and advantages, such as allowing Arrival's vehicles to communicate with the Operations Control System (OCS) in Arrival's robotic factory to report the status of vehicle production to the OCS, or to receive and execute instructions from the OCS, such as autonomously moving the vehicle from the production area to the storage area after production is complete.

[0753] Chapter C: Arrival Network Security System

[0754] Introduction to Chapter C

[0755] Following the plug-and-play principle embodied in Arrival vehicles and components as described in Chapter B, once an Arrival component is plugged into an Arrival vehicle or product, it will easily and automatically begin operating without requiring configuration or modification of existing systems. In this case, cybersecurity requirements may conflict with the task of providing plug-and-play functionality for vehicle components.

[0756] In fact, modern vehicles are cyber-physical systems, that is, engineered systems built upon and based on the seamless integration of computing algorithms and physical components, and cybersecurity vulnerabilities can affect the lives of vehicle users and others.

[0757] Vehicle cybersecurity is covered by numerous authorities and regulations worldwide to ensure that systems are designed not to pose unreasonable risks to vehicle safety, including risks that could arise from potential cybersecurity vulnerabilities. Therefore, there is a need to continuously enhance vehicle cybersecurity to mitigate cyber threats that could present unreasonable security risks to the public or compromise sensitive information such as consumer personal data.

[0758] The conventional approach to vehicle cybersecurity is based on treating the vehicle network as a trusted environment, while everything outside the vehicle is considered an untrusted and risky environment from which potential threats may originate.

[0759] In contrast, the Arrival system treats the vehicle network as an untrusted network. Therefore, all communication between components using the vehicle network is encrypted, and vehicle components do not accept commands from other vehicle components without authentication or verification. Thus, Arrival protects vehicles and vehicle components from unauthorized use and prevents unauthorized access to personal data and valuable analytical or diagnostic data of the vehicle.

[0760] Arrival's unique approach to cybersecurity for vehicles and vehicle components is described in more detail below.

[0761] A brief overview of the figures related to Chapter C.

[0762] Some of the features, implementation methods, and examples disclosed below are illustrated in the accompanying drawings, wherein:

[0763] Figure 40 —This is a schematic diagram of the connected system, including the devices, the internal components of the devices, and the remote server.

[0764] Figure 41 — This is a diagram that establishes whether a device is authorized by the server for communication methods.

[0765] Figure 42 — This is a diagram that establishes whether a device is authorized to use a component's communication method.

[0766] Figure 43 — This is a diagram illustrating a complete authentication method for devices, components, and servers.

[0767] Figure 44 — This is a diagram of the network topology of Secure Touch Point (STP).

[0768] Detailed description related to Chapter C

[0769] Let's start with the general safety measures that apply to all Arrival products, vehicles, and components.

[0770] Common security measures in connected systems

[0771] Device 300 (e.g., a vehicle) is a member of a connected system. Device 300 includes multiple hardware electrical or electronic components 301 (or simply components). Figure 40 The diagram illustrates the hardware topology that facilitates the registration of electrical components 301 with device 300. Each component 301 is configured to communicate with device 300 (e.g., a vehicle). Server 302 (e.g., a server provided by a cloud service) is configured to communicate with device 300.

[0772] Component 301, device 300, and server 302 have corresponding architectures that facilitate their communication. Component 301 includes an input / output unit (I / O) 303, a memory 304, and a control 305, each of which is configured to communicate via bus 306. Device 300 includes an input / output unit (I / O) 307, a memory 308, and a control 309, each of which is configured to communicate via bus 310. Server 302 includes an input / output unit (I / O) 311, a memory 312, and a control 313, each of which is configured to communicate via bus 314. Each of component 301, device 300, and server 302 includes a processor that serves as controls 305, 309, and 313. The component's I / O 303 is configured to communicate with the device's I / O 307. The device's I / O 307 is configured to communicate with the server's I / O 311.

[0773] The memory 304 of component 301 stores identification information. The identification information includes the name of component 301, with each component assigned a unique name. The identification information may also include attribute information providing details on how to configure component 301. The identification information includes at least one of text, numbers, and machine-readable codes (such as barcodes, QR codes, microchips). As an example, the identification information includes a blockchain that enhances traceability by tracking how and where each component was previously deployed. Security is enhanced by providing the identification information in an encrypted format. The identification information stored by memory 304 can also be presented via a label attached to the housing of component 301.

[0774] Providing I / O 303 and memory 304 as a part of each component 301 allows each component to be used as an independent unit that can be transferred from one device 300 to another. The memory 308 of device 300 stores the identity information of device 300 along with the identity information of one or more registered components 301. For each electrical component, the memory 308 of device 308 stores an indication of whether that specific component is authorized for use by device 300. The memory 312 of server 302 stores a database specifying whether each of the multiple electrical components (such as component 301) has been authorized for use in device 300 and other arriving devices (vehicles). Information about each individual device 300 and each individual electrical component 301 is stored in the database of server 302.

[0775] Control 313 is configured to retrieve information from a database in memory 312 and update the database. Therefore, control 313 is configured to determine whether device 300 and electrical component 301 are authorized. Furthermore, control 313 is configured to update the authorization status of device 300 and electrical component 301 over time.

[0776] Server 302 is located remotely from device 300. Server 302 is considered a "cloud server" because its functionality is distributed across multiple servers via the internet. The provision of cloud servers enhances resilience and prevents performance vulnerabilities of individual servers. Furthermore, the distributed nature of cloud server 302 across multiple locations facilitates communication between cloud server 302 and mobile device 300, and is particularly beneficial for enhancing communication between cloud server 302 and multiple distributed devices 300. In contrast, server 302 is a specific individual server.

[0777] Registration and Authorization

[0778] Figure 41 A diagram illustrates a communication method S10 used by the system to determine whether device 300 (e.g., a vehicle) is authorized by server 302. In step S11, device 300 transmits its identification information to server 302. In step S12, device 300 receives confirmation of whether it is authorized to use the device.

[0779] Figure 42The diagram illustrates a communication method S20 used by a system to determine whether a device 300 (e.g., a vehicle) is authorized to use a component 301 (e.g., a battery pack). In method S20, identification information is transmitted from component 301 to device 300 (step S21) and then to server 302 (step S22). In response, authorization information is transmitted from server 302 to device 300 (step S23) and component 301 (step S24). More specifically, in step S21, component 301 registers its identification information with device 300. In step S24, electronic device 300 confirms with component 301 whether it is authorized to use within electronic device 300. In step S23, device 300 transmits the identification information of component 301 to server 302. In step S24, device 300 receives confirmation that component 301 is authorized to use within device 300.

[0780] Figure 43 Further details are provided regarding the secure registration and authentication methods for Arrival's devices (such as Arrival's vehicles). The relevant registration and authentication processes are described and illustrated below from the perspectives of component 301 (method S30), device 300 (method S40), and server 302 (method S50).

[0781] The method S30 from the perspective of component 301 is as follows:

[0782] • In step S31, the component's control 305 obtains the identity information (ID) from the component's memory 304.

[0783] In step S32, control 305 instructs component I / O 303 to send identity information (ID) to device I / O 307 of device 300 (corresponding to S21), wherein after device 300 receives the ID information, the ID information is stored in device 300's memory 308. As a result, component 301 is considered to be registered by device 300.

[0784] • In step S35, the component's I / O 303 receives authorization information (Auth) from the device's I / O 307 (corresponding to S24).

[0785] In step S36, the component control 305 processes the authorization information. If the component is authorized, its operation is permitted. If the component is not authorized, its operation is restricted.

[0786] The method S40 from the perspective of device 300 is as follows:

[0787] • In step S41, the device control 309 obtains identity information (ID) from the device memory 308, wherein the ID information is related to the device itself (corresponding to S10) or a component (corresponding to S20).

[0788] • In step S42, control 309 instructs device I / O 307 to send identity information (ID) to server I / O 311 of server 302 (corresponding to S11, S22).

[0789] • In step S44, the device's I / O 307 receives authorization information (Auth) from the server's I / O 311 (corresponding to S12, S23).

[0790] • In step S45, the device's I / O 307 sends authorization information (Auth) to the component 301's I / O 303.

[0791] • In step S46, the device control 309 processes authorization information. Regarding the authorization of device 300 (corresponding to S10), if the device is authorized, operation of the device is permitted; otherwise, operation of the device is restricted. Regarding the authorization of component 301 (corresponding to S20), if the component is authorized, operation of the component is permitted; otherwise, operation of the component is restricted.

[0792] From the perspective of server 302, method S50 is as follows:

[0793] • In step S51, the server control 313 maintains a database (DB) stored in the server's memory 312, which associates identity information (ID) with authorization information (Auth) for both component 301 and device 30.

[0794] • In step S52, the server's I / O 311 receives identity information (ID) from the device's I / O 307 (corresponding to S11 and S22).

[0795] In step S53, the processor of server 302 retrieves the authorization information (Auth) corresponding to the identity information (ID) from the server's memory 312. The processor updates the database (DB) to record that it has been accessed. Furthermore, in the case where the identity information (ID) corresponds to a component 301 associated with device 300 (S20), the processor updates the database (DB) to record the association between component 301 and device 300.

[0796] In step S54, the server's I / O 311 sends the authorization information (Auth) to the device 300's I / O 307 (corresponding to S12 and S23). The server then returns to S51 and continues to maintain the database (DB).

[0797] Therefore, each component of the system operates independently by establishing whether its safety requirements are met. Each vehicle verifies individual components, with this verification based on the receipt of authorization information from an external server. Each component has monitoring devices to determine its safe operation, including the component checking its certification status regarding the equipment on which it is installed.

[0798] The confidence threshold determines the level of functionality a component can perform. The resulting limitation on equipment or components is chosen by the owner, for example, by the operator of an Arrival vehicle fleet, and the level of functionality is limited based on protection and safety requirements.

[0799] The confidence threshold is based on both internal factors of the component and environmental factors to which it is exposed. For example, if a component is altered, or if the vehicle is moved to an unusual location, this indicates that the component should be viewed with greater skepticism regarding its external environment. Therefore, a customized safety level can be selected while ensuring compliance with safety regulations. As an example, the battery pack of an electric vehicle can be configured such that, if it is not certified, it will operate with reduced functionality, such as providing limited power to the vehicle, thereby allowing for safe control of the vehicle rather than abruptly stopping it while it is in motion.

[0800] Technically feasible functional limitations include the following:

[0801] - Completely prevents the operation of the equipment / components

[0802] - Reduce or limit the operation of equipment / components, and

[0803] - Triggers a central alarm, allowing remote users to intervene in the operation of the device / component.

[0804] Individual hardware security modules and distributed authentication foundation

[0805] Depending on the applicable requirements, the Arrival cybersecurity approach can involve different solutions and security levels. Another solution within the Arrival cybersecurity approach is based on using a Hardware Security Module (HSM) in each hardware component, as described below.

[0806] In a given implementation of the Arrival cybersecurity system, each Arrival hardware E / E component is provided with an HSM for authentication, registration, or certification, for example, using a process similar to that described above, where the HSM operates as a dedicated control with a memory storing the corresponding identity information. In contrast, conventional methods provide a single HSM throughout the vehicle.

[0807] In a further implementation, the Arrival cybersecurity system provides distributed verification or authentication of a component before some or every component of the vehicle is allowed to operate fully. Distributed verification or authentication envisions that several components, modules, and / or systems (hereinafter—components) of the vehicle, outside the component being verified or authenticated, should verify or authenticate the component. Thus, vehicle security increases with the number of components participating in the verification or authentication (hereinafter—authentication basis).

[0808] Arrival's cybersecurity approach is highly flexible in this respect: different parts of the vehicle can be included in the authentication base, and the authentication base can include a different number of vehicle parts, depending on the current environment, situation, and / or requirements.

[0809] In the event of successful verification or authentication, the components underlying the authentication can jointly generate an encryption key, which is then transmitted to the verified or authenticated component, enabling that component to use the key for encrypted communication with the rest of the vehicle.

[0810] Therefore, the Arrival cybersecurity system implements Shamir's secret-sharing algorithm, where the secret (key) is divided into parts, with each participant (each component of the authentication foundation) receiving its own unique part. This implementation allows for the setting of a minimum number of parts (components of the authentication foundation) required to reconstruct the original secret (to generate the key). In this way, the security level of the vehicle system can be set and changed according to current circumstances and requirements.

[0811] Furthermore, the Arrival cybersecurity system envisions two-way verification or authentication: in parallel with the aforementioned procedures, each Arrival component should verify or authenticate the vehicle, equipment, or system in which the component is installed before allowing the component to operate fully. According to the above disclosure, the installed component can be configured to verify or authenticate several components, modules, and / or systems of a vehicle to successfully verify or authenticate the vehicle.

[0812] All described verification or authentication procedures can be implemented via the HSM integrated into Arrival's components.

[0813] Furthermore, even if a vehicle contains components that do not have an integrated HSM (such as modules from a conventional OEM), distributed verification or authentication of these components within the vehicle can still be achieved. For example, the registers of such conventional modules can be distributed across multiple components of the vehicle, providing an authentication basis for these modules. This allows the verification or authentication of the conventional modules to be performed by several components of this authentication basis, for example, in a blockchain-like manner.

[0814] Component binding

[0815] In another implementation, the Arrival cybersecurity system envisions binding components to an intended installation, such as a specific vehicle. Components may be designed for use in a specific installation, such as a specific vehicle, and therefore may be pre-configured or bound to said installation. If removed from the intended installation, the component bound to the installation will be disabled. To enable a component bound to one (first) installation to operate in another (second) installation, the component needs to be properly unbound before being removed from the first installation.

[0816] As a result of the first successive verification or certification process for this component, newly manufactured Arrival components can be configured to automatically bind to the first installation into which they are inserted. Accordingly, each Arrival component can be bound to an authorized installation, such as a specific vehicle, and proper unbinding may be required before the bound component is removed from an authorized installation so that the component can operate in another installation.

[0817] At this point, each Arrival component (including bundled components and the entire vehicle) can be configured to have a service mode in which the component is fully operational in any installation (including unauthorized installations). Such a service mode is necessary for easy and uninterrupted servicing of Arrival vehicles and components. The service mode should still have a set of limitations, such as the limited duration of the service mode, the maximum range of movement of the vehicle within the service mode, etc.

[0818] In addition to the above, Arrival's cybersecurity system also includes proximity sensor-based solutions to enhance vehicle safety.

[0819] Key hook and security touch point

[0820] In this implementation, a proximity sensor is provided to the vehicle, which the user uses to access the vehicle. The proximity sensor may also be referred to as a "secure touchpoint." The user has a key that includes a transmitter configured to emit a signal detected by the sensor. This signal includes authentication data, which is checked by a security processor in the vehicle, for example, by one or more HSMs (Hardware Management Systems). If the authentication information is found to correspond to an authenticated user, the processor allows access to the vehicle. If the user is authenticated, the doors unlock, granting the user access to the vehicle.

[0821] The sensor is sensitive to receiving Bluetooth Low Energy (BLE) signals and / or Ultra Wideband (UWB) signals and / or Near Field Communication (NFC) signals. Any other type of remote communication can also be used. Therefore, multiple pathways are provided for communication between the key and the vehicle. In this implementation, UWB is used as the default pathway, while NFC is used as a backup pathway. Once the key is within range, the vehicle status changes, allowing the vehicle to unlock. Therefore, drivers do not need to find their keys to access the vehicle's interior.

[0822] The key is either a phone or a padlock. If the key is a phone, the driver does not need to carry a separate padlock. Furthermore, multiple keys belonging to different drivers can be provided. Digital keys can be transferred from one keying device to another. This is useful for fleets where many drivers are granted access to the vehicle. Authentication data is associated with the key, allowing the vehicle to identify which key has been used to access it.

[0823] Optionally, local touch sensors can be provided on some or every door of the vehicle. Touch detection complements key detection. As a result, a driver passing by the vehicle will not cause the vehicle to mislock.

[0824] Proximity and / or touch sensors can be integrated into the vehicle's glass side windows. For example, during construction, an entire side window with integrated sensors can be easily installed into the vehicle frame using a robotic mounting system. The sensors are typically large panels located in a prominent position easily accessible to the van driver; unlike conventional touch- or contact-based vehicle access control systems, they do not need to be integrated into door handles and are not intended to be gripped.

[0825] Secure touch point network

[0826] In yet another implementation, Arrival's vehicles include a connected Secure Touch Point (STP) network configured to authenticate vehicle users using a radio interface.

[0827] In addition to authentication, the STP network can also include user feedback (such as LEDs or haptic feedback) and one or more touch sensors. The STP in the network is located near the vehicle's door. It allows for user location near the door using UWB, and uses NFC as a backup interface.

[0828] Figure 44 The diagram illustrates an example topology of an STP network.

[0829] In the illustrated embodiment, four STPs 314, 315, 316, and 317 are present in the vehicle to enable the location of user 318 to be positioned near one of the doors 319, 320, 321, and 322 of vehicle 323 and around vehicle 323. It should be understood that the STP network may include other numbers of STPs, starting with two STPs (e.g., one STP may be located at the front of the vehicle and another STP may be located at the rear of the vehicle).

[0830] At this point, the STPs in the network can be different from each other. Not all STPs need to have all the communication interfaces. Specifically, in most cases, it is sufficient to have only one BLE interface in one STP (such as the primary STP 314 in this example). NFC as a backup method can be provided in all or some of the STPs in the network.

[0831] The STP network provides the HSM for strong authentication of users within the STP system. At this point, the HSM is integrated into only one STP in the network—the primary STP 314 in this example. Therefore, the primary STP 314 includes all available interfaces, including BLE, UWB, and NFC, and has the HSM for user authentication procedures within the STP network. All other STPs 315-317 in the network are referred to as secondary STPs, which have a simplified structure and functionality: they do not have an HSM and are only provided with UWB and NFC interfaces.

[0832] In vehicle 323, the STP network is connected only to CAN bus 324, which enables the STPs to communicate with each other using a security protocol and with the vehicle safety controller / ECU 325. In operation, the primary STP 314 is configured to use CAN bus 324 to send control signals 326 to each secondary STP 315-317, for example, to control UWB ranging and to report to the vehicle safety controller / ECU 325.

[0833] When user 318, possessing a corresponding authenticator (e.g., key fob), approaches vehicle 323, the STP network uses the available communication interface to locate user 318's position. For example, if user 318 approaches the right side of vehicle 323, such as... Figure 44 As shown, the STP network uses the UWB ranging signal 327 detected by both the primary STP 314 and the secondary STP 317, the BLE signal 328 detected by the primary STP 314, and the NFC signal 329 detected by the secondary STP 317 to locate the user's position. In this case, the secondary STP 317 transmits the data of the detected UWB and BFC signals to the primary STP 314 via CAN bus communication 330.

[0834] The primary STP 314 is then configured to authenticate the user based on all detected signals via an integrated HSM and report the authentication status 326 to the vehicle safety controller / ECU 325.

[0835] The STP network is also configured to monitor the location of user 318 and unlock doors that the user approaches directly or via ECU 325. For example, in Figure 44 In the scenario shown, user 318 can move toward either driver's door 319 or rear door 322 with equal probability. The direction of user movement is determined by monitoring how the user's position changes over time, based on the signals detected by each of STPs 314-317.

[0836] This STP network implementation provides easy integration into the vehicle's CAN network:

[0837] - The STP network is self-contained; it connects to only the CAN interface and does not require an external HSM elsewhere in the vehicle / network (the STP network is configured to rely on its own HSM).

[0838] - The STP network has a protocol for communicating with the vehicle safety controller / ECU.

[0839] - STP is configured for secure communication between STPs, which reduces the physical security requirements for wiring harnesses and the requirements for network isolation.

[0840] Therefore, this STP network is primarily a plug-and-play solution that can be retrofitted into any vehicle, including regular OEM vehicles.

[0841] Interaction with the authenticator

[0842] There are several stages in the authentication process using BLE / UWB signals between the STP system and the user with an authenticator (such as a key fob):

[0843] 1. The STP system first identifies the user as they approach the vehicle and pre-authenticates them using any appropriate fast encryption method. This occurs once a BLE connection is established. At this stage, the user has no access to the vehicle but is "recognized" by the system.

[0844] 2. The STP system begins to use UWB technology for intelligent ranging and BLE as a communication channel to coordinate UWB behavior, to safely measure the distance of the verifier relative to the vehicle and its location.

[0845] 3. Once the user enters or leaves a certain radius (the threshold is set to 2 or 3 radii, for example: 1m, 3m, 10m), the safe distance measurement result is reported to the vehicle ECU. The report is completed via the CAN bus using a safe communication protocol.

[0846] 4. If a user presses a button within any range to explicitly unlock or lock the vehicle, the STP system will authenticate the user using any appropriate strong encryption method. At this stage, a complete interaction is performed between the authenticator security domain and the STP security domain. The security domain is typically implemented using an HSM integrated circuit (IC).

[0847] 5. Once the user is very close to the vehicle, the STP system authenticates the user using any appropriate strong encryption method. At this stage, a complete interaction is performed between the key fob security domain and the STP security domain. The security domain is typically implemented using an HSM IC.

[0848] 6. Use secure communication protocols and the CAN bus to report user authentication status to the vehicle ECU responsible for vehicle access control.

[0849] These are the stages of the authentication process using NFC signals:

[0850] 1. An STP that senses the proximity of a user's key card (using an inductive or capacitive sensor).

[0851] 2. The STP enables an NFC reader and uses the key card to perform user authentication. Interaction occurs between the key card security domain and the STP security domain. The STP security domain is typically implemented using an HSM IC. The key card security domain is implemented internally within the card IC.

[0852] 3. Use secure communication protocols and the CAN bus to report user authentication status to the vehicle ECU responsible for vehicle access control.

[0853] Chapter D: Arrival Technology Platform: Creating New Vehicle Designs Using Vehicle Builder Tools

[0854] Introduction to Chapter D

[0855] The Arrival Technology Platform (ATM) combines the hardware modularity implemented in the Arrival Unified Hardware Platform as described in Chapter A with the software modularity implemented in the Arrival Unified Software Architecture as described in Chapter B. Vehicle builders adopt and use both the hardware modularity and the software modularity to enable plug-and-play functionality for Arrival products, including vehicles.

[0856] Plug and Play is a framework and toolchain dedicated to simplifying and automating the process of designing vehicle electrical and electronic (E / E) architectures. Vehicle Builder provides automated configuration of wiring, networking, and software component allocation for vehicle models, which further allows for firmware generation for electronic control units (ECUs) within the vehicle, along with the release of over-the-air (OTA) updates and diagnostic profiles. Therefore, Vehicle Builder allows for a significant reduction in manual intervention during the vehicle design process, enabling engineers to create optimal vehicle E / E configurations in hours rather than weeks.

[0857] A vehicle builder is an automated vehicle design tool configured to create the optimal E / E configuration for a vehicle model based on input requirements (including desired system characteristics), define the optimal software allocation, and ultimately generate a complete vehicle model specification. In implementations, the vehicle builder can be a web-based application.

[0858] In practice, vehicle builders use a function library as a database, such as those provided by ATP, for defining and describing all system features and functions (or simply features and functions) of the Arrival vehicle. Vehicle builders further use a component library as a database, such as those provided by ATP, of all electrical (hardware) components that can be used in the Arrival vehicle. For example, the component library includes components such as barometric pressure sensors, cameras, cooling fans, and water pumps. These databases are developed using a unified hardware platform and a unified software architecture on a modular basis, as described above.

[0859] The vehicle builder includes a user interface (UI) where users (such as vehicle designers or engineers) can select desired system features for the vehicle model they want to design from a menu with available options (such as sedan or bus); whether to have an electric parking brake; whether to have a self-leveling suspension; whether to have electronic mirrors, heated windows, heated seats, a heated steering wheel, Wi-Fi hotspot, full autonomy; self-parking; collision avoidance; any other ADAS features; a ticketing system (if it is a bus), etc. Alternatively, a set of desired features for the vehicle model can be provided outside the vehicle builder, for example, obtained from a remote resource or server.

[0860] The vehicle builder then displays all desired features, along with the functionality inherited from those features, provided by ATP's function library. In the semi-automatic operation of the vehicle builder, the user can approve the displayed features, adding or deleting one or more of them. If any changes are made to a set of features, the vehicle builder will repeatedly access the function library to update the functionality required to implement the updated set of features.

[0861] Next, the vehicle builder assigns electrical components to perform all the functions of the ATP-based component library. Thus, for example, if the self-leveling suspension feature is selected, the required components include a hydraulic creation system, a hydraulic sensing system, an electronic level control (ELC) ECU, and a vehicle-level sensing system.

[0862] The capabilities provided by ATP include complete information on the required hardware components, including name, supplier, description, model, weight, voltage, interface, and documentation. Vehicle designers can review and accept options as appropriate; identify the locations in the vehicle where several options exist, and assign them to other components (e.g., components that intersect with them) where several options exist.

[0863] At this stage, vehicle builders are able to generate a complete list of hardware components for the vehicle model based on the required features and functions. Vehicle builders then select a set of modular software components to control these components and enable them to perform all the functions provided by ATP.

[0864] The vehicle builder then uses automated routing tools and algorithms to solve optimization problems and determine: the number, type, and layout of ECUs; the optimal allocation of software components on the ECUs; and the configuration of the vehicle data layer—the network. At this point, the vehicle builder is configured to automatically populate all leads with hardware component pins based on pin specifications and component locations. The resulting routing, software allocation, and network configuration are optimized in terms of combinations of required pin types, computational power, network load, and wiring harness costs. In other words, the vehicle builder automatically generates the optimal system configuration for the vehicle model. The generated configuration can also be manually adjusted via the UI.

[0865] In the final stage, vehicle builders create complete vehicle model specifications and generate firmware to be applied to that model, enabling its plug-and-play functionality. The specifications defining the vehicle model configuration can then be sent to the production systems, including automated inventory ordering and logistics, as well as supply and actual robotic production systems.

[0866] The ATP (Automatic Vehicle Architecture) specifies a single place to describe all arriving vehicles in a single manner. Based on the ATP, vehicle builders simplify the definition and configuration of vehicles; provide all necessary data within the context; support the design and integration phases; and, where possible, assist, validate, and automate all involved processes.

[0867] Benefits for vehicle builders: Data for all vehicle models is stored in one place and used to design new models; specifications, documentation, and CAD for all components are readily available; the system provides automatic suggestions for components to use; clear routing; automatic wiring with optimal network configuration and software component allocation across ECUs.

[0868] Vehicle description or model in Vehicle Builder: A vehicle is first defined by the features to be provided in the vehicle. The vehicle is further defined by the functions required to support these features; all features and functions, and their interconnections, are stored in a function library. Furthermore, the vehicle is defined by parts assigned to each function based on a parts library. Therefore, in Vehicle Builder, a vehicle is described as a set of features with supporting functions, plus parts that perform those functions.

[0869] When a vehicle builder configures electrical (hardware) components, including ECUs, and creates optimal wiring to connect them to each other, it simulates the virtual installation of these components into the vehicle to obtain and validate the vehicle's virtual hardware topology. Additionally, the vehicle builder performs another simulation by virtually assigning software components to the virtual ECUs to verify that the assigned software components can communicate with each other through the virtual vehicle network and enable proper control of the hardware components within the virtual hardware topology.

[0870] Therefore, the vehicle system configuration and the firmware generated by the vehicle builder have been tested and verified during the automated design process.

[0871] The automated wiring tool is described in further detail to explain how the aforementioned optimization problem can be solved by vehicle builders.

[0872] A brief overview of the figures related to Chapter D.

[0873] Some of the features, implementation methods, and examples disclosed below are illustrated in the accompanying drawings, wherein:

[0874] Figure 45 —This is a schematic vehicle layout showing the location of the E / E component pins.

[0875] Figure 46 —From Figure 45 The schematic vehicle layout has an E / E topology, which includes the ECU and all pin connections to the E / E components.

[0876] Figure 47 —This is a weighted bipartite graph for a cabling optimization problem.

[0877] Detailed description related to Chapter D

[0878] Technical issues

[0879] As is well known, deciding how to connect a large number of pins from dozens of components to the ECU in a vehicle so that the vehicle can function properly is a problem for designers and engineers when creating a vehicle. The number of options to consider in this situation grows exponentially with the number of available configurations.

[0880] Automatic routing tools allow for the automation of creating routing diagrams for these configurations, achieving optimal solutions and eliminating any human error.

[0881] Summary

[0882] The automated wiring tool is based on a novel algorithm configured to provide automatically generated wiring diagrams for the connections between selected vehicle systems (including modules and components) and ECUs (or input / output (I / O) modules), enabling their operation to be software-controlled as part of the vehicle system. The tool is also configured to assign composite and atomic software components on the ECU to control hardware components to perform selected functions providing selected features. Furthermore, the tool is configured to create an optimal network configuration (e.g., CAN, LIN, or Ethernet) within the vehicle, enabling all software components to communicate with each other.

[0883] Therefore, the automatic routing tool is configured as follows:

[0884] -Design the optimal wiring harness;

[0885] – Assign appropriate configuration software (in firmware form) to all ECUs; and

[0886] – Create the optimal network configuration for your vehicle.

[0887] The following terms are used to describe automated routing tools and algorithms:

[0888] A vehicle is a group of modules that communicate with each other via a network protocol (such as CAN or any other system protocol).

[0889] A module is a set of components that perform a function.

[0890] Component – ​​part of a module.

[0891] Pins are terminals in the connector of a component. Each pin is described by parameters (voltage, current, direction, connection type) and function (e.g., left high beam or front EC water temperature).

[0892] Component pin connection type:

[0893] – Analog output (required connection to the analog input type pin of the ECU);

[0894] – Digital output (connected to digital input);

[0895] -Low-side input low current (up to 1A) and high current (up to 5A) (connected to low-side output);

[0896] – High-side input low current (1A) and high current (5A) (connected to high-side output);

[0897] Other types are also possible.

[0898] An ECU is a device that can be configured to control or monitor module parameters via a network (such as a CAN network); if the module does not have a network connection, i.e., it has an analog connection, the ECU will essentially be operable to:

[0899] – Take signals from input pins and translate their values ​​into a network (e.g., CAN);

[0900] – Turn the relevant output pin on or off based on the received network (e.g., CAN) message.

[0901] Connection – The link between the pins of a component and the pins of the ECU.

[0902] Vehicle layout – A 3D schematic arrangement of all components and pins in a vehicle.

[0903] Input for automatic wiring tools

[0904] The automated wiring tool and algorithm require a vehicle configuration and module list in the form of a vehicle layout as input. The module list contains a complete list of corresponding component pins along with their parameters, functions, and locations within the vehicle layout. The algorithm also requires complete information on the types (models) of ECUs available for the vehicle.

[0905] Requirements or rules for automatic wiring tools

[0906] The following requirements or rules are defined in the development of automatic routing algorithms to enable the finding of the best solutions to the above problems.

[0907] 1. All connected – All pins of all components (if necessary) must be connected to the ECU's pins.

[0908] 2. Pin type - The pins of the component must be connected to the pins of the relevant type of ECU, taking into account both the connection type and the current value.

[0909] 3. Optimal Quantity – Select the best set of ECUs (e.g., the smallest or cheapest set of ECUs).

[0910] 4. ECU type – Select the appropriate ECU based on the pin type of the component.

[0911] 5. Optimal Wiring – Defines the optimal placement of the ECU in the layout to reduce wiring harness length.

[0912] 6. Nearest ECU – Components strive to connect to the nearest available ECU to reduce wiring harness length.

[0913] 7. Pin grouping – Some pins that may belong to different components or modules are connected to an ECU.

[0914] The latter type of requirement or rule allows the collection of system functions and / or characteristics within an ECU to optimize network configuration, for example, by applying some logic locally in the same ECU (e.g., switching outputs on certain sensor signals) to avoid transmitting large amounts or sensitive data over the vehicle network, thereby reducing the amount of network (e.g., CAN) messages.

[0915] Overview of Automatic Routing Algorithms

[0916] As input, the automatic routing algorithm receives descriptions of the pins of all components with defined types and functions, as well as their arrangement in the vehicle layout, for example, such as Figure 45 As shown in the diagram.

[0917] Figure 45The vehicle layout includes the pinouts for the following components: Right Front (FR) turn indicator pin 401, RF high beam pin 402, FR low beam pin 403, ambient temperature sensor pin 404, front (F) fog sensor pin 405, F position indicator pin 406, F daytime running light (DRL) indicator pin 407, power front (PF) coolant temperature pins 408, 409, PF coolant pressure pins 410, 411, cooling fan pulse width modulation (PWM) pin 412, left front (FL) turn indicator pin 413, FL high beam pin 414, FL low beam pin 415, F brake pressure pin 416, rear (R) brake pressure pin 417, vacuum pressure pin 418, FR airbag potentiometer pin 419, FR airbag pressure sensor pin 420, FR airbag exhaust solenoid 421, FR airbag inflation solenoid 422, FL airbag exhaust solenoid 42... 3. FL airbag inflation solenoid 424, FL airbag pressure sensor pin 425, FL airbag potentiometer pin 426, left rear (RL) airbag exhaust solenoid 427, RL airbag inflation solenoid 428, RL airbag pressure sensor pin 429, RL airbag potentiometer pin 430, right rear (RR) airbag potentiometer pin 431, RR airbag pressure sensor pin 432, RR airbag exhaust solenoid 433, RR airbag inflation solenoid 434, power rear (PR) coolant temperature pins 435, 436, PR water pressure pins 437, 438, air tank pressure sensor pin 439, air compressor solenoid pin 440, rear brake solenoid pressure sensor pin 441, RR position indicator pin 442, RR stop signal pin 443, reverse signal pin 444, RL stop signal pin 445, and RL position indicator pin 446.

[0918] It can be seen that even Figure 45 Even in a simplified example, determining the optimal number and location of ECUs to connect to pins 401 through 446 of all components is a complex task.

[0919] Advantageously, the algorithm allows for the automatic definition of an optimal set of ECUs for a given set of pins, taking into account pin type and pin grouping requirements.

[0920] For example, the algorithm output at this stage could be the following: the best group is... Two Type A ECUs and one Type B ECU composition.

[0921] Then, the algorithm calculates the optimal ECU layout defined by minimizing the sum of the lengths of all connected wiring harnesses. For example, for Figure 45 The pin layout of the component at this stage of the output Figure 46 The diagram in the middle is shown.

[0922] In particular, Figure 46 The diagram shows a Type A ECU to be located at the front of the vehicle body, a Type B ECU to be located in the dashboard, and a Type A ECU to be located at the rear of the vehicle body.

[0923] Automatic routing algorithm description

[0924] Automatic routing algorithms, based on input data and defined requirements, have five tasks to solve or goals to achieve:

[0925] 1. Define a set of optimal ECUs

[0926] 2. Define the optimal pin assignment from the component to the ECU pins.

[0927] 3. Define the optimal layout of the ECU

[0928] 4. Define the optimal allocation of software components to control the components and execute the logic required for functions and features.

[0929] 5. Define the optimal configuration of the network so that all ECUs with the required software can communicate with each other.

[0930] Each task is an optimization problem with its own optimal solution. Since the objectives are interconnected, each optimal solution has a strong influence on the others. Instead of solving complex optimization problems with multiple objectives, the algorithm solves the tasks step-by-step in a given order. This approach has proven to be highly efficient while significantly reducing computational complexity.

[0931] Step 1: Define a set of optimal ECUs

[0932] The goal of this step is to define a set of the cheapest predefined elements (ECUs) that match the given constraints (sufficient capacity for all components, satisfying all requirements). This definition allows us to view the given task as a combinatorial optimization problem (COP). Although some (very narrow) subclasses of COP exist with well-known solutions based on fast heuristics, in general, the only way to obtain the optimal solution to a COP is exhaustive search, which is often not an option due to its extremely high computational complexity. However, there are still some general methods and heuristics that can reduce the space of possible solutions and thus make exhaustive search feasible.

[0933] The automatic wiring algorithm uses a method called constraint programming (CP). Constraint programming is a paradigm that allows the COP to be described as a set of variables with a specific domain and constraints in some formal language (depending on the CP framework used). Optimization objectives and heuristics about the search order can also be added. A search of the space of possible variable assignments is performed within the CP framework using a so-called decision tree. The automatic wiring algorithm solution is based on a CP solver from the open-source Google Optimization Toolkit.

[0934] variable

[0935] Suppose we have T different ECUs, and we define the variable C[1..T], where the variable C[i] represents the number of ECUs of the i-th type in our configuration.

[0936] Target

[0937] The objective is very simple: the cost of each ECU is known, so the algorithm defines the objective as the scalar product of the variable vector and the cost vector.

[0938] constraint

[0939] capacity

[0940] First, it's crucial to ensure the resulting configuration has a feasible solution. In other words, there must exist a necessary and sufficient condition for a maximum binary match between the pins of all components and the pins of the ECU. To achieve this, the algorithm uses the so-called Hall condition, based on Hall's marriage theorem. This allows ensuring problem feasibility without actually solving the problem.

[0941] Hall condition constraints have been added as follows: For each component's pin subset, there are sufficiently suitable pins for the ECU.

[0942] In fact, knowing that there is a finite set of different pin types, the algorithm does not have to check all 2n subsets, because most of them are symmetrical to each other.

[0943] Rules and Groups

[0944] Constructing constraints for rules and groups is more difficult. Without actual assignment, it's impossible to check whether all pins from all groups can be assigned to the same ECU. On the other hand, full assignment cannot be performed at this step because it would significantly increase the computational complexity of the algorithm. Therefore, the algorithm performs partial assignment.

[0945] All consumer pins are divided into two groups: the group used by any group and / or rule (called super pins, or SP) and the group not used by any group and / or rule (called normal pins, or NP).

[0946] Only SPs require partial dispatch. For this purpose, partial dispatch introduces sub-clusters: a sub-cluster is a group of pins belonging to the same ECU and having the same pin type. For example, an ECU with 16 ANAIN type pins and 8 ANAOUT type pins can be divided into two sub-clusters: a sub-cluster of size 16 ANAIN type pins and a sub-cluster of size 8 ANAOUT type pins. In this case, ANAIN and ANAIN / ANAOUT are considered different types.

[0947] Variables are introduced to represent partial assignments. Since the final ECU configuration is not yet available, two variables are declared for each SP: subcluster ID (SI[i]) and cluster number (CN[i]). SI[i] represents the ID (identifier) ​​of the subcluster to which the i-th SP is assigned. CN[i] is the cluster number, starting from 1 for each cluster type (not subcluster). This numbering method allows for the addition of constraints to ensure that CN[i] cannot exceed C[cluster_type_of(SI[i])]. Some simple symmetry breakers are also added for these assignments.

[0948] Introduce constraints for all rules and groups, namely constraints that ensure that the SI and CN variables of all pins from the same group are equal.

[0949] Capacity revision The partial assignment affects capacity constraints, and the following modifications are added.

[0950] Once you understand what type of ECU pins the SP will use, you need to ensure that there are enough remaining ECU pins to connect all the NPs.

[0951] To this end, the following capacity constraint was added: for each normal pin subset, there are enough ECU pins that are not assigned to the super pins.

[0952] search

[0953] Finally, the algorithm runs the CP solver to define a set of optimal ECUs to be used as inputs for step 2.

[0954] Step 2: Define the optimal pin assignment from the component to the ECU pins.

[0955] The goal of this step is to define a pin assignment from the components to the ECUs that has the lowest cost (shortest total wire length) and matches the given constraints. It is assumed that a suitable set of ECUs was found in step 1, thus ensuring the feasibility of the assignment step for that set.

[0956] Given this, the task of this step can be viewed as a variant of the constrained clustering problem (although it differs from the classic constrained clustering problem definition, which only allows constraints that must be linked and those that cannot be linked).

[0957] Although some methods for finding the global optimum are known, they have many serious limitations and are not suitable for a given situation due to the NP-hard nature of the clustering problem.

[0958] Clustering problems are typically solved using heuristic algorithms that are expected to converge quickly to a local optimum. Automatic wiring tools use the common K-means clustering algorithm as the basis for solving a given task because it is simple, efficient, and easy to modify.

[0959] Constrained K-means algorithm

[0960] Each iteration of the classic K-means algorithm consists of two consecutive steps:

[0961] 1. Assign points to the clusters with the lowest cost (cost is the sum of the distances (metrics) between the point and the centroid of the corresponding cluster).

[0962] 2. Update the cluster's centroid.

[0963] At some point, the assignment becomes stable, which means that the algorithm has converged to a local optimum.

[0964] Centroid updates require no modifications because they do not affect any assignments and do not increase the total cost.

[0965] As for point assignment, the classic K-means algorithm assigns each point to the nearest cluster, taking into account the capacity constraints of the automatic routing algorithm rather than being an option. A given assignment task with capacity constraints (which is also a combinatorial optimization problem) is NP-hard, so it is solved using heuristics.

[0966] Minimum Cost Flow (MCF) Method

[0967] Assignment tasks can be described as finding the maximum matching in a weighted bipartite graph. As capacity increases, the problem becomes a minimum-cost flow problem, which can be solved with very efficient existing solutions, especially automatic routing tools that use a minimum-cost flow solver from Google's Optimization Toolkit. The main idea of ​​the MCF problem definition is as follows: Figure 47 The diagram shows the corresponding weighted bipartite graph.

[0968] exist Figure 47In the diagram, node x[i] 447 represents a pin, and node C[j] 448 represents a sub-cluster. If the i-th pin can be connected to the j-th sub-cluster, then there exists an arc 449 connecting nodes x[i] and C[j]. There also exists an artificial demand node D 450 connecting all C[j] nodes.

[0969] Each node x[i] has a supply of +1. The cost of arc (x[i], C[j]) is equal to the distance between the i-th pin and the j-th subcluster. The capacity of (C[j], D) is equal to the capacity of the j-th subcluster. Finally, to balance this network, node D has a supply of -N (or demand of +N).

[0970] Therefore, the solution to the MCF problem can be explained as follows: if Flow(x[i],C[j])==1, then the i-th point should be assigned to the j-th cluster.

[0971] The described MCF method looks promising, but it can only handle linear constraints, while some of the constraints previously set (i.e., the rules must be linked) are non-linear. These cases require an alternative dispatch algorithm that can handle non-linear constraints.

[0972] Constraint Programming (CP) Method

[0973] For cases where the MCF method cannot solve the problem, constraint programming is used. It handles nonlinear constraints but requires a significant amount of additional optimization and heuristics. And even after that, it is still slower than the MCF method.

[0974] The following sections describe the main ideas behind this method.

[0975] variable

[0976] Introduce the assignment variable: A[1..N].

[0977] A[i]==j means that the i-th pin is assigned to the j-th cluster.

[0978] constraint

[0979] For capacity constraints, the Hall condition is used (see step 1 for more details). The capacity of each subset can be directly calculated from the cluster group. To calculate the requirement, a CP constraint called Count is used. For example, Count[A[1..N],k,D[k]] counts the number of variables in A[1..N] assigned to the value k and stores it in an auxiliary variable D[k], which can then be used directly under the Hall condition.

[0980] Constraints for rules and groups can be easily defined in a manner similar to step 1.

[0981] Target

[0982] The objective is the simple sum of the distances between a point and the centroid of its corresponding cluster.

[0983] Heuristics

[0984] Due to the significant size of the decision tree, different assignment orders can significantly increase (or decrease) the overall search time. The automatic wiring tool uses the following heuristic for sub-cluster assignment:

[0985] - Try assigning the point to the same cluster it was assigned to in the previous iteration; and

[0986] - Try assigning the point to the nearest available cluster.

[0987] Another important heuristic is based on the premise that updating the centroid of the cluster does not affect feasibility. Therefore, the solution obtained in the previous iteration can be used as a baseline for the target value.

[0988] Finally, pins are assigned to the cluster rather than sub-clusters. This makes the domain smaller and significantly impacts performance, but requires an additional intra-cluster assignment phase, which will be described later.

[0989] convergence

[0990] One of the biggest problems with the CP method is the search time. Having an optimization objective causes the solver to perform an exhaustive search in each iteration, since it is impossible to check if any better solution exists without visiting all branches of the decision tree.

[0991] On the other hand, having any better (not optimal) solution is sufficient to take a step further towards local optima. Therefore, it might be useful to stop the exhaustive search at some point and update the centroid using the best solution found so far.

[0992] Therefore, a timeout is added to the solver. The meaning of the timeout value is somewhat similar to the learning rate of gradient descent and can be tuned through different heuristics. Although even a constant timeout significantly affects convergence time: there are more iterations, but they proceed faster. Furthermore, the idea of ​​using any feasible solution better than the baseline for the descent step provides another way to improve convergence time.

[0993] Greedy CP / MCF (GCM) method

[0994] The main idea behind this approach is to combine two methods: first, we assign SPs using the CP method (with some modifications described below), and then we assign NPs to the remaining pins using the MCF method. Due to the greedy strategy (always assigning SPs first), an optimal solution is not guaranteed, but as mentioned above, this is not always necessary.

[0995] The only consideration is feasibility. Firstly, assigning SPs using the CP method does not guarantee that NPs can always be assigned to the remaining pins. To avoid this, additional feasibility constraints are added. These constraints are also based on the Hall condition and are defined in the same way as the partial assignment in step 1.

[0996] This approach employs a so-called two-pass strategy. In the first pass, no optimal solution is searched; the algorithm only uses the GCM solution to descend to the optimum. And a full CP search is only performed after the GCM fails. This allows for a reduction in the number of full CP iterations.

[0997] Problem Breakdown

[0998] Another way to simplify the assignment problem is to analyze the domain of variables. It's possible that the fully connected graph can be broken down into smaller parts that can be optimized independently. Furthermore, this could lead to subproblems without nonlinear constraints that can be solved by an MCF solver, or even subproblems with trivial solutions (where all points are in a single cluster within their domain).

[0999] Cluster dispatch

[1000] The CP and GCM methods provide automated routing tools with guaranteed feasible assignments between components and ECUs, but in practice, no exact pin assignments are defined.

[1001] The automatic routing algorithm performs one cluster-level assignment after K-means convergence. To assign pins within a cluster, the algorithm searches for another bipartite maximum matching, running the search for each cluster separately. Since all nonlinear constraints have been set, this task is solved by the MCF solver as described above.

[1002] Global Strategy

[1003] The overall algorithm is as follows:

[1004] 1. Define the fields of the pins. Do this if the problem can be broken down into several sub-problems.

[1005] 2. Randomly initialize the cluster center

[1006] 3. Run K-means. At each step, run optimization for each subproblem:

[1007] • If the subproblem has a trivial solution, then use it.

[1008] • If the subproblem has no nonlinear constraints, use the MCF solver.

[1009] • If the subproblem has nonlinear constraints, then use the two-pass GCM-CP strategy:

[1010] First, run only the GCM solver.

[1011] • When GCM fails, continue using the CP solver and still use the GCM solution as the baseline.

[1012] 4. During convergence, save the best pin to the cluster assignment.

[1013] 5. For each cluster, use MCF for intra-cluster distribution.

[1014] 6. Return Results

[1015] Step 3. Define the optimal layout of the ECU

[1016] The restrictions on ECU location are low, and the automatic wiring algorithm uses the centroid of the cluster from step 2, making some minor adjustments to eliminate possible collisions with other components and ECUs in the final configuration.

[1017] Step 4. Define the optimal allocation of software components

[1018] Through connectivity and wiring configuration, including ECU location, vehicle builders further select, configure, and automatically assign composite and atomic software components to be embedded in the vehicle's ECU, enabling the components that perform all functions and provide all features to operate correctly.

[1019] constraint

[1020] The following constraints or rules are defined to enable finding the optimal solution to a task in a given step:

[1021] - All software components are assigned according to their specifications to match the parameters of the available ECUs. Software engineers include the specifications in the description of each software component according to the Arrival Plug and Play approach.

[1022] - Driver software components are assigned to the hardware components they are intended to control, as described in the driver software component's specification.

[1023] - The Automotive Safety Integrity Level (ASIL) of all software components must match the ASIL of the features they are performing and the ASIL of the hardware components they operate on. Therefore, for example, software components requiring a certain safety level cannot be assigned to an ECU with a lower safety level.

[1024] Application software components that can be located and operated between composite or drive software components (in terms of communication) can be assigned to different ECUs that perform their functions.

[1025] algorithm

[1026] Based on the above constraints, the automatic wiring tool is configured to allocate software components by searching for assignments that minimize the amount of network communication between software components in the vehicle. In other words, the vehicle builder's allocation algorithm is configured to assign software components that need to communicate with each other to the same ECU as much as possible, thereby minimizing communication via in-vehicle networks (e.g., CAN).

[1027] Step 5. Define the optimal network configuration

[1028] The final step of the automatic wiring algorithm is closely linked to the previous step because the software allocation has been planned to achieve minimal network communication in the vehicle.

[1029] constraint

[1030] The following constraints or rules related to network configuration are further defined:

[1031] - The network load should be minimal or at least reasonable.

[1032] High ASIL communication should be kept separate from any lower ASIL communication.

[1033] Potential address conflicts should be resolved, for example, by creating a private network.

[1034] algorithm

[1035] Based on the constraints and the results of the software allocation steps described above, the automatic routing tool is configured to search for network configurations with a minimum number of networks (e.g., CAN networks) to support all necessary communication between software components.

[1036] Automatic routing tool output

[1037] As a result of executing the above algorithm steps, the automatic routing tool outputs the following results:

[1038] 1. The vehicle's connection and wiring diagram, which defines the connection between each pin of each component and the pin of the ECU.

[1039] 2. A list of the functions of each occupied pin for each ECU in the vehicle configuration.

[1040] 3. Location of each ECU.

[1041] 4. Allocation scheme of software components operating connected to the ECU.

[1042] 5. Vehicle network (e.g., CAN, LIN, Ethernet) configuration.

[1043] Therefore, the described automated wiring tool automates wiring design for modular vehicles in vehicle builders and eliminates any human error in wiring harnesses. At this point, all results output from the automated wiring tool are optimized to achieve greater efficiency at the lowest possible cost in vehicle design and production.

[1044] We can summarize it as follows:

[1045] Feature 1: Automated vehicle design utilizes vehicle builders

[1046] 1: A method for designing a vehicle, wherein an automated vehicle design tool is used for:

[1047] (a) Obtain data on the vehicle's hardware topology, including modular hardware components, and the vehicle's desired system characteristics.

[1048] (b) Based on the data, determine the system functions and a set of ECUs required to provide the desired system characteristics in the vehicle.

[1049] (c) Assign pins of modular hardware components to pins of the ECU.

[1050] (d) Define the layout of the ECUs in the vehicle and the wiring plan that connects the modular hardware components to the ECUs based on pin assignment.

[1051] (e) Selecting modular software components to enable the execution of system functions and allocating modular software components on the ECU, and

[1052] (f) Define the network configuration of the vehicle so that modular software components distributed on different ECUs can communicate with each other, such as to perform system functions and provide desired system characteristics.

[1053] Optional features

[1054] • Automated vehicle design tools include a user interface (UI) that accepts input defining the customer’s requirements for the vehicle, including desired system characteristics.

[1055] • The automated vehicle design tool is configured to determine a set of required ECUs that are optimized in terms of the number and / or cost of ECUs.

[1056] • The automated vehicle design tool is configured to determine a set of required ECUs by solving a combinatorial optimization problem (COP) using constraint programming methods.

[1057] • The automated vehicle design tool is configured to assign pins and define the ECU layout in an optimized manner in terms of the length of the wiring harness required to connect modular hardware components to the ECU.

[1058] • The automated vehicle design tool is configured to assign pins by solving constrained clustering or minimum cost flow problems.

[1059] Modular software components are assigned to the ECU according to their specifications to match the ECU's type and parameters.

[1060] Modular software components are allocated to the ECU to match the software components, system characteristics and functions, and the ECU's Automotive Safety Integrity Level (ASIL).

[1061] • The automated vehicle design tool is configured to define network configurations optimized for network load.

[1062] • The automated vehicle design tool is configured to define a network configuration in which high ASIL communication is separated from low ASIL communication.

[1063] • The automated vehicle design tool is configured to access and use data from libraries of modular hardware and software components.

[1064] • The automated vehicle design tool is configured to display all desired system features, as well as the functions inherited from the features and the modular hardware components required to perform all functions and provide the features, and to list the parameters of each modular hardware component, such as name, supplier, model, weight, voltage, interface, etc.

[1065] • The automated vehicle design tool is configured to complete and store the vehicle’s entire wiring specifications.

[1066] Feature 2: The vehicle robotic manufacturing workflow utilizes the vehicle builder front end

[1067] 2. A method for producing vehicles in a robotic production environment, comprising:

[1068] (i) The automated vehicle design tool (a) acquires data about the vehicle hardware topology, which includes modular hardware components and the desired system characteristics of the vehicle; (b) determines, based on the data, the system functions and a set of ECUs required to provide the desired system characteristics in the vehicle; (c) defines the layout of the ECUs in the vehicle and the wiring plan to connect the modular hardware components to the ECUs; and (d) defines the network configuration of the vehicle so that the modular software components can communicate with each other, as required to perform system functions and provide the desired system characteristics.

[1069] (ii) The automated vehicle design tool sends wiring plans and network configurations to the operation and control system of the autonomous production environment;

[1070] (iii) The operation control system controls the autonomous production environment for the production vehicles based on the wiring plan and network configuration.

[1071] Optional features

[1072] • An autonomous production environment includes robotic agents organized into a group of work units, each work unit having up to 10 stationary robots, served by autonomous mobile robots (AMRs), where the group of work units operate together to substantially produce or assemble an entire vehicle.

[1073] • The autonomous production environment is located in a factory that hosts at least the robot agent hosting the autonomous production environment, and has an area of ​​less than 100,000 square meters, preferably between 10,000 and 50,000 square meters.

[1074] Feature 3: Modular components are suitable for vehicle builders

[1075] 3: A modular vehicle component that is part of a series of other types of components, all of which are tested and pre-integrated with each other, and each of which is described by data used by an automated vehicle design tool configured to: (i) automatically design a vehicle that includes the component and other components from the series of components, and (ii) automatically generate optimized data and power connection plans for all components that send or receive data and / or use power.

[1076] 4: A vehicle comprising modular vehicle components as part of a series of other types of components, all of which are tested and pre-integrated with each other, and each of which is described by data used by an automated vehicle design tool configured to: (i) automatically design a vehicle including the component and other components from the series of components, and (ii) automatically generate optimized data and power connection plans for all components that transmit or receive data and / or use power.

[1077] 5: A fleet of vehicles, each of which comprises modular vehicle components as part of a family of other types of components, all of which are tested and pre-integrated with each other, and each of which is described by data used by an automated vehicle design tool configured to: (i) automatically design vehicles including the component and other components from the family of components, and (ii) automatically generate optimized data and power connection plans for all components that send or receive data and / or use power;

[1078] The fleet operator defines a specific set of requirements for one or more vehicles in the fleet, and the automated vehicle design tool uses these requirements to select which hardware and software modular components to use in each vehicle of the fleet.

[1079] Chapter E: Robotic Manufacturing: Robotic Data-Driven Continuous Delivery Production

[1080] Introduction to Chapter E

[1081] Arrival's "robotic manufacturing" addresses key problems in conventional design and production processes. Conventional design and production processes are linear, moving from initial design layout to operational-based design review, then to pilot testing, and finally to factory production. This is essentially a conveyor belt process where a single failure can halt the entire process, design changes can have significant negative impacts, and the output is a single product type (for example, if you are designing and manufacturing a small passenger car, you cannot reuse that design and production process to also manufacture vans or buses).

[1082] Robotic manufacturing proposes autonomous, data-driven, continuously delivering environments or factories capable of manufacturing any type of product (e.g., small passenger cars, large passenger cars, minivans, large vans, specialty vans, trucks and vans of varying lengths and capacities, buses of varying lengths and capacities; any other category of equipment). Autonomous robotic production environments (which we should call "factories") comprise machines (robots) and systems capable of performing a series of operations, the sequence of which is determined by the results of previous operations or by reference to the external environment monitored and measured within the robotic production environment itself. These autonomous factories deliver continuous production efficiency with optimal time-to-market, and are distributed, scalable, fault-tolerant, open, and extendable. They can implement semantic (ontology-driven) decisions, enabling self-learning and self-control.

[1083] Arrival's robotic manufacturing involves an internally developed technology platform, including robotic workpieces, robotic rigs and tooling, autonomous mobile robots (AMRs), logic, a semantic-based language for robot process management and control, and robot operation control systems and software for planning, managing, and controlling all processes in an autonomous robotic production environment. One implementation method of Arrival's robotic manufacturing is the microfactory.

[1084] On the other hand, as mentioned earlier, Arrival robotic manufacturing is based on and widely utilizes Arrival components and systems for robotic handling and assembly: hardware (see Chapter A) and software modularity (see Chapter B) are key enablers of Arrival robotic manufacturing.

[1085] The following subsections will cover the main aspects of Arrival's robot manufacturing.

[1086] Chapter E.1: Multi-agent robot environment

[1087] The basis of Arrival robot manufacturing model

[1088] Chapter E.2: Arrival Procedural Language

[1089] A unified programming language for robot process management and control.

[1090] Chapter E.3: Robot Manufacturing Services (R Services) and R Service Centers

[1091] The equipment library and pre-developed robot manufacturing services can be used to design the production process.

[1092] Chapter E.4: Robotics Manufacturing Process (R Process) Studio

[1093] Tools for creating a variety of possible processes that satisfy the input constraints for producing any given commodity by a robot, a human, or both.

[1094] Chapter E.5: Factory Layout Studio

[1095] A system for creating robot production environment layouts and performing discrete event simulations on them.

[1096] Chapter E.6: Factory control model and operation control system

[1097] Master model for robotic production environments and data-driven control systems used in autonomous robotic environments and factories.

[1098] Brief overview of the figures related to Chapter E

[1099] Some of the features, implementation methods, and examples disclosed below are illustrated in the accompanying drawings, wherein:

[1100] Figure 48 —This is a diagram of the APL program structure with substituting capabilities;

[1101] Figure 49 —This is a diagram of an APL program structure with child operations acting as the parent;

[1102] Figure 50 —This is a diagram of the layered structure of the R service;

[1103] Figure 51 —A diagram that is part of the "integrated" structure of r services;

[1104] Figure 52 —A scheme for interaction between the service center and the operation control system (OSC);

[1105] Figure 53 —This is a 3D view of the R service layout;

[1106] Figure 54 —A 3D view of the layout of a single work unit;

[1107] Figure 55 —This is a scheme for allocating R services to basic work units;

[1108] Figure 66 —This is a 2D simulation view of a micro-factory layout;

[1109] Figure 57 —A 3D simulation view of the micro-factory environment and operations;

[1110] Figure 58 — This is a scheme for the main interaction types provided by Blackboard OCS.

[1111] Detailed description related to Chapter E

[1112] Chapter E.1: Multi-Agent Robot Environment

[1113] Arrival robotics manufacturing utilizes a multi-agent model for robotic production environments. The principles and characteristics of this model are described below.

[1114] In a robotic production environment, all tangible (physical) and intangible (virtual) objects that constitute activities are "agents" that provide "capabilities" to the system. Capabilities are simple, individual actions performed by agents, including physical agents or virtual entities.

[1115] Agents include robotic agents (such as individual work units, machines, mobile robots, cameras, etc.), non-robotic agents (such as human workers and operators), and virtual entities (such as control programs, algorithms, data objects, etc.). For example, a robot manipulator agent can provide the capability of "execute_trajectory".

[1116] Therefore, capabilities can be divided into two groups based on the type of proxy they handle:

[1117] - Capabilities provided by physical agents; and

[1118] - Capabilities provided by virtual agents, also known as "services".

[1119] A group of capabilities that are executed sequentially or in parallel by one or more agents can be grouped together; such a group of capabilities is called an “operation”.

[1120] An agent can provide different capabilities, while the same capability can be provided by different agents (including robotic agents (work units, robots) and non-robotic agents (operators)). For example, a capability such as "bring_part_to_cell" can be provided by an autonomous mobile robot (AMR) or a human operator.

[1121] In a robotic production environment, inactive tangible and intangible objects are considered "resources." Tangible resources include parts, workpieces, semi-assembled units, and complete assemblies. Intangible resources include software components and data.

[1122] To achieve flexible and autonomous production, the control system of the robotic production environment needs to understand the state, agents, capabilities, and resources of the robotic production environment in order to dynamically determine which agents participate in the execution of each capability, when, and how.

[1123] To this end, the control system of the Arrival robotic production environment (called the Operation Control System (OCS)) includes a common communication layer for the robotic production environment (called the "blackboard"), which is a shared memory and data bus for all agents in the robotic production environment. In other words, the blackboard is a structured, shared global memory for the robotic production environment. Data about every object, resource, and process in the robotic production environment is recorded on the blackboard.

[1124] In the Arrival robot manufacturing model, agents and capabilities are logically separated and can be viewed as objects at different levels of abstraction. The model is entirely agent-agnostic because a capability can be provided by different agents. At the process abstraction level, there is no distinction between which agent provides a certain capability to the system. Therefore, capabilities are defined and handled as independent objects of the system.

[1125] Some capabilities require initial data and alter the system's state. Such capabilities can read from and / or write to the blackboard. For example, the "open_gripper" capability requires information about the gripper, its availability, and its current state. Upon successful execution, it notifies the system of its state—for example, that the gripper is now open. To do this, the capability sends a request via the blackboard application programming interface (API).

[1126] Therefore, abilities can also be divided into two groups based on their interaction with the blackboard:

[1127] - The ability to read from and / or write to the blackboard; and

[1128] - The ability to neither read from nor write to the blackboard.

[1129] It is worth noting that some capabilities can be associated with actions or even continuous processes or services that last for a certain period of time. For example, the "post_image_data_from_cv" capability, once started, will publish data from the camera until it stops. Such characteristics of capabilities are fully consistent with Arrival's multi-agent model and do not affect the normal description and processing of capabilities.

[1130] Resources, agents, and capabilities define the lowest level of abstraction in the Arrival robot manufacturing model. More detailed disclosures of the OCS and blackboard are provided in the following sections.

[1131] Chapter E.2: Arrival Procedural Language

[1132] Arrival Robotics Manufacturing is further based on new, flexible, and dynamic approaches to operation / process control and management in robotic production environments.

[1133] All conventional MES (Manufacturing Execution Systems) use hard-coded workflow management procedures to control advanced operations in the robotic production environment on a PLC / station basis. That is, the production process (or production planning) is always strictly predefined (pre-coded), and it is possible that there are no dynamic changes during the process.

[1134] Conventional software solutions for general operation / process control can be divided into two types: Workflow Management System (WMS) and Business Process Management System (BPMS).

[1135] Typically, WMS applies any of the following control methods:

[1136] - Control flow methods when a process is defined as sequential / parallel operations, where each operation depends on the completion state of the previous operation; and

[1137] - A data flow method when a process is defined as a set of actions and triggers used to initiate a new action, where each trigger is set by the state of some data.

[1138] Similar to known MES systems, all processes in WMS and BPMS are strictly predefined and hard-coded, which does not allow for any dynamic changes to the processes. Existing WMS and BPMS systems are difficult to scale, and they are based on a single central control unit rather than being fault-tolerant.

[1139] To address the problems and shortcomings of the existing technologies mentioned above, a new programming language called Arrival Process Language (APL) has been developed for the Arrival robot manufacturing process, which supports data flow, control flow, and decision-making.

[1140] Compared to conventional systems, Arrival Robotics Manufacturing includes an Operation Control System (OCS) based on APL, a new programming language for robots. Through its unique structure, logic, and features, it enables dynamic robotic process management (autonomous control), and is distributed, fault-tolerant, and highly scalable.

[1141] APL is based on the multi-agent approach described above and provides the creation of logical or semantic rules, as described in the APL program, for dynamic, event- and data-driven control of robot workflows. This allows for the efficient combination of control and data flows within the same management system. APL is the first and only logic- and semantic-based language for robot process management and control. Using APL, execution graphs can be constructed as the basis for logic solvers to control and manage robot production processes or any other processes within a robot, as described in more detail in the following sections.

[1142] APL is designed to define the tasks of agents and the interactions between agents in a robotic environment through "rules". In cases involving more than one agent, the rules can be derived and executed as a multivariate process.

[1143] APL provides a paradigmatic data description of any robotic production process by design: it provides data in a single form for all participants in any interaction and offers a clear understanding of the context of the interaction.

[1144] Define and use the following concepts at the APL abstraction level:

[1145] - Capabilities are simple actions performed by agents, including physical agents or virtual entities;

[1146] - An operation is a sequence of capabilities and / or other operations; and

[1147] -r service -- is a physical system that has the capabilities or operations that the system can provide or perform;

[1148] The above and other features and advantages of APL are provided by the language design detailed below.

[1149] An APL program describes operations that define the rules for execution within a robotic environment. This description must be sufficient to execute the program; therefore, it must contain all necessary information about the rules, their parameters, execution order, preconditions, and any other conditions governing the execution of the operations.

[1150] Each APL program is structured in sections. Typically, an APL program description includes the following sections:

[1151] ·sign

[1152] Prerequisites

[1153] ·rule

[1154] • Sequence | Parallel | Stream {...}

[1155] ·constraint

[1156] The description of an operation begins with its operation signature. The operation signature represents the name of the operation and a list of its input and output parameters.

[1157] If the operation uses (reads) data from the blackboard during runtime, that data is one or more input parameters of the operation.

[1158] If, as a result of execution, the operation writes new data to the blackboard, then that new data is one or more output parameters of the operation.

[1159] An operation can have any number of input and / or output parameters, or none at all. All parameters are listed in the operation signature.

[1160] The operation signature syntax is as follows. The signature includes the name of the operation and its parameters listed in parentheses. To distinguish between input and output parameters, the term "out" followed by a space is added before the name of each output parameter:

[1161] operation_name(input_parameter1,input_parameter2,out output_parameter)

[1162] Preconditions are conditions that must be met before execution; they can be used as criteria for the OCS Execution Engine (EE) to select alternatives. Preconditions can be used to check whether the blackboard has the required data or whether a specific field has the required value.

[1163] Preconditions are represented by an expression containing one operator and two operands. There are eight types of operators that can be used for preconditions (and also for constraints) to define the following conditions: match (syntax: %%), do not match (syntax: !%), equal to (syntax: ==), not equal to (syntax: !=), greater than (syntax: >), greater than or equal to (syntax: >=), less than (syntax: <), less than or equal to (syntax: <=).

[1164] Operations can contain any number of preconditions connected by the following logical operators: AND, OR, NOT().

[1165] Syntax: The prerequisites section of an APL program contains a list of conditions enclosed in curly braces. If the section contains more than one prerequisite, all listed prerequisites must be satisfied before execution begins. Each prerequisite expression begins with a tilde (~) and has the following format:

[1166] ~<@path.to.parameter_value>[operator] <value>

[1167] The left-hand side of a precondition is typically represented by a path that begins with a variable or a variable defined in an explicit BB ID (blackboard identifier) ​​or operation signature.

[1168] The right side can be represented by constants, variables defined in the operation signature, or paths.

[1169] A path is a sequence of IDs and fields that describe how to find a specific structure or value within the blackboard. A path consists of variables and fields. Variables refer to the IDs of the structures within the blackboard. Fields describe how to find a specific value within the structure.

[1170] Syntax: All fields and variables within the path are separated by periods; to distinguish between fields and variables, variables are marked with a $ sign before their names, for example:

[1171] @varName.field.@field_containing_id.another_field

[1172] Preconditions are typically used as a tool for selecting alternatives. However, preconditions can also be used on individual functions: in this case, the function will be executed if the precondition is met, otherwise it will not start.

[1173] Alternatives are capabilities or operations that are interchangeable parts of the same execution flow. Capabilities are selected by the execution engine, which is part of the OCS, by checking their preconditions, such as... Figure 48 As shown, the parent operation 400 has a child capability 401 and a child 402 with alternative capabilities 403 and 404. The choice during execution is determined by preconditions 405 and 406. The selection of any alternative does not interrupt the execution flow.

[1174] APL allows for the use of multiple preconditions, making it a powerful tool for defining complex execution flows with multiple alternatives.

[1175] For example, an operation can be described as being executed only if three preconditions are met. To do this, all these expressions need to be listed in the preconditions section, for example, as follows:

[1176]

[1177] All the prerequisites listed in the segment must be met one by one.

[1178] If we want to describe more complex situations, such as when an operation only begins if the third and one of the first two preconditions are met, we can use logical operators, for example, as follows:

[1179] operation_name(param){

[1180] preconditions{

[1181] ~(@(<BB ID> ).value.index! =0OR@var1.field.value=="ready")AND@var2.field2%%{"type":"my_type"}

[1182] }

[1183] A common scenario is that an alternative is chosen only if a specific precondition is met; otherwise, another alternative is selected. This implies two sets of mutually exclusive preconditions. In APL, you can only describe one set of preconditions, and use the service term "default" for the second alternative, as shown in the following example.

[1184] / / Alternative1

[1185] operation_name(param){

[1186] preconditions default

[1187] rules{~rule1(param=param)}

[1188] seq};

[1189] / / Alternative2

[1190] operation_name(param){

[1191] preconditions{~@param.value.index==0}

[1192] rules{~rule3(param=param)}

[1193] };

[1194] The example above defines that alternative 2 is executed if the preconditions are met, and alternative 1 is executed in any other case.

[1195] Furthermore, preconditions can be used to check for non-existent data. If an operation or alternative can only be initiated if the blackboard does not contain specific data, then unsolvable paths and the operators not_match – ! % can be used to describe the preconditions.

[1196] For example, we want to ensure that the structures associated with the variable `var` in the blackboard do not contain a `non-existent_field`. To check this, we can write the following expression:

[1197] operation_name(param){

[1198] preconditions{~@var.non-existent_field! %{}}

[1199] rules{~rule3(param=param)}

[1200] }

[1201] If the non-existent_field does not exist, the path is unsolvable and cannot even match an empty object {}, so the precondition is true.

[1202] Finally, if the prerequisite section is empty or defaults to be used for more than one alternative, the execution engine will randomly select an alternative.

[1203] To understand how complex operations are described in APL, we need to expose the parent and child concepts provided in the APL design to describe the relationships between different operations and capabilities.

[1204] An operation that includes other capabilities or operations is called the parent operation of all those capabilities and operations.

[1205] A capability or operation that is part of another operation is a child of that operation. An operation can be either a child of another operation or a parent of another operation or capability, such as... Figure 49 As shown. Figure 49 The diagram illustrates a parent operation 407 having sub-capabilities 408 and 409 and sub-operation 410, whereby sub-operation 410 is the parent of sub-capabilities 411 and 412.

[1206] Now let's describe the rules. A rule is a call to a capability or operation in an APL program. When discussing the structure of an APL program, we can interchangeably refer to the rules and the capabilities / operations they represent. All rules are listed in the section rules.

[1207] There are two types of rules:

[1208] Internal rules – represent internal capabilities, which are built-in capabilities provided out of the box by the OCS platform.

[1209] External rules – represent all other capabilities that an agent, resource, or service can perform.

[1210] Rules can also be grouped into blocks and have a nested structure when a child rule is the parent of other rules, and those other rules can in turn have their own children.

[1211] APL supports the concepts of invocation and instance, as well as the concepts of supplementary and extended rules. Some operations may include the same capability / operation two or more times. Each rule appears in a segment rule as many times as the capability or operation it represents must be executed. Each appearance of a rule in an operation description is called a rule invocation.

[1212] To distinguish different calls to the same rule within a single operation, we use instances. An instance is an identifier for a call that is appended after the name of the rule.

[1213] Syntax: Each call is preceded by a tilde (~) character before the rule name. By definition, a rule is a capability signature, therefore all rules are listed together with their parameters in parentheses. Unlike parameters in operation signatures, rule parameters must not only be listed but also defined in their signatures.

[1214] Setting parameters: The input parameters for the rule are set as follows:

[1215] ~<rule_name> (<parameter_name> = <value>)

[1216] Input parameter values ​​can be of the following types: constant, variable, or path.

[1217] To define input parameters, you can also use arithmetic expressions, access array elements, and access fields described in the task description.

[1218] The output parameters of the rule must be preceded by the term "out" in the parameter name:

[1219] ~<rule_name> (out<parameter_name> = <value>)

[1220] Output parameter values ​​can only be of variable type.

[1221] In APL programs, a section "rule" contains a rule signature enclosed in curly braces:

[1222] rules{

[1223] ~rule1(params=param_in)

[1224] ~rules2(out block_out=param_out)

[1225] }

[1226] The input parameters of a rule must be defined in the signature of its parent rule or as the output parameter of another rule that has been executed. If the output parameter is listed in the signature of an operation, it must be defined as the output parameter of one of its children.

[1227] Instances and rule names are separated by the hash symbol #. If a rule has instances, we can only reference the rule by a combination of its name and the instance name.

[1228] rules{

[1229] ~rule#instance1(params=param_in)

[1230] ~rule#instance2(params=param_in)

[1231] }

[1232] In addition, if you need to execute the same rule several times in a row, APL provides the use of loops to make your program shorter.

[1233] There are two types of loops:

[1234] repeat( <number>— The rule is executed repeatedly a certain number of times;

[1235] while( <condition>— The execution of the rule is repeated when the described condition is true.

[1236] The number of repetitions in a loop can be represented by a constant (if it references a positive integer value) or by a path (if its resolved value is a positive integer).

[1237] The flow (sequential, parallel) segments of an APL program define the order in which rules must be executed.

[1238] If the APL program contains only one rule, this section can be omitted; however, if the script contains two or more rules, this section must exist in one of the following formats:

[1239] Order – All rules are executed in order, that is, according to the order in which they appear in the script;

[1240] Parallelism—All rules are executed in parallel, meaning they start simultaneously;

[1241] Process {...} — Some rules must be executed in the specific order specified in the section; in this case, rules not mentioned in the section are executed in parallel.

[1242] Segment flow is enclosed in curly braces; each dependency expression begins with a ~ character. The segment cannot be empty.

[1243] func(param_in,out param_out){

[1244] rules{

[1245] ~rule1(some_in=param_in)

[1246] ~rule2()

[1247] ~rule3(out var=param_out)

[1248] }flow{

[1249] ~rule2<-rule1(started)

[1250] }

[1251] };

[1252] In the example above, rule 2 is only ready to execute after rule 1's state is "started". Rules 1 and 3 have no dependency on the states of other rules, so they will execute in parallel.

[1253] Now let's describe the constraint segments of the APL program.

[1254] A constraint (constraint expression) is a condition that must be satisfied for an execution capability to be achieved.

[1255] Constraints are typically used to describe requirements for an agent. For example, sequential execution of the capabilities pick and place only makes sense if both capabilities are performed by the same robot and gripper. Constraints are also used to ensure technical requirements; for example, a part can only be picked up by a specific robot model because other models have insufficient load capacity.

[1256] In addition to resources (agents), constraints can describe any other conditions required for execution.

[1257] Syntax: APL program segment constraints contain a list of constraint expressions enclosed in curly braces. If a segment contains more than one constraint expression, all listed constraints must be satisfied for the operation to execute. The segment contains constraints on all rules governing the function; the segment cannot be empty.

[1258] The same eight types of operators as those used in preconditions (as described above) can be used in constraints. Logical operators AND, OR, and NOT() can also be used in constraints, similar to preconditions.

[1259] A constraint expression consists of one operator and two operands. Operands in a constraint can be represented by constants, variables defined in the rule signature, variables that are output parameters of another rule, paths starting from a variable or an explicit BB ID, and references to the task description.

[1260] Each expression begins with a tilde (~) character and has the following format:

[1261] ~<@path.to.the.resource>[operator] <value>

[1262] Constraint expressions typically contain references to a task description of the rules to which the constraints are applied.

[1263] For example, let's consider an operation with three sub-rules (rule 1, rule 2, rule 3), which must be executed if the following constraints are met:

[1264] Rule 1 must be executed by a specific agent (bot);

[1265] Rule 2 and Rule 1 cannot be executed by the same agent;

[1266] Rule 3 and Rule 1 must be executed by the same agent.

[1267] All these expressions in the constraint segment can be written as follows:

[1268] operation(param1,param2,robot){

[1269] rules{

[1270] ~rule1(param1=param1,robot=robot)

[1271] ~rule2(param2=param2)

[1272] ~rule3()

[1273] }seq

[1274] constraints{

[1275] ~rule1.@provider_id.@resource_id.name%%@robot.name

[1276] ~rule2.@provider_id.@resource_id.name! =rule1.@provider_id.@resource_id.name

[1277] ~rule3.@provider_id.@resource_id.name==rule1.@provider_id.@resource_id.name

[1278] }};

[1279] By default, all constraints listed in a segment must be satisfied one by one.

[1280] In APL, you can select the same or different resources (agents) for different rules. To select the same (or different) resources to perform a specific capability, you can use the rule name in the left and right parts of the constraint expression, for example, as follows:

[1281] operation(param1,param2,robot){

[1282] rules{

[1283] ~rule1(param1=param1,robot=robot)

[1284] ~rule2(param2=param2,robot=robot)

[1285] }seq

[1286] constraints{

[1287] ~rule1.@provider_id.@resource_id.name==rule2.@provider_id.@resource_id.name

[1288] }};

[1289] At this point, it is not possible to set such constraints for parallel rules.

[1290] The APL design described above utilizes a multi-agent model and agent-agnostic methods. In this way, APL, through its design, provides the ability to create logical rules of any complexity for dynamic, event- and data-based control of any robotic workflow.

[1291] Therefore, APL allows for the efficient combination of control flow and data flow within the same management system, making it one of the enablers of Arrival's robotics manufacturing.

[1292] As can be seen from the above, APL's design enables the programming of the robot's operational logic and answers the following questions:

[1293] • What is executed – By describing the operation,

[1294] How to execute – by defining operational process dependencies,

[1295] • When to execute – by defining the preconditions under which the operation can begin.

[1296] • Who will execute – By defining constraints on the specific executor of the operation.

[1297] Chapter E.3: Robot Manufacturing Services (R Services) and R Service Centers

[1298] Robotic manufacturing services, or R services, are combinations of human, hardware, and software components that work together and integrate with the OCS of a robotic production environment to perform a set of atomic operations on certain objects.

[1299] Objects can be tangible or intangible. Tangible objects are parts, artifacts, semi-assemblies, or assemblies. Intangible objects are software components and data. R services can be applied to operations on very specific objects or groups of objects.

[1300] The r service center is a repository of robot manufacturing services, including the equipment and layout required for them.

[1301] The r service center allows owners of r services (operators, service providers) or parts thereof to publish and maintain reliable information about their products, enabling that information to be used for robot manufacturing process planning and to obtain feedback about their r services or parts thereof.

[1302] To support robot manufacturing process planning, the r service center is configured (including configuring the application programming interface (API)) to automatically select appropriate r services for the provided operations and resources.

[1303] In Arrival robot manufacturing, the following information is defined for each r service:

[1304] - Description, which includes the basic attributes of the r service: name, type, operation name, etc.

[1305] - Operation (process) sequence and operation steps.

[1306] Each operation in the r service should have an operation sequence description, which includes one or more operation steps. For each operation step, the required resources are allocated so that the r service center can calculate and present the cost of a step or the entire operation to the user. APL scripts can be used to define each operation step or operation sequence.

[1307] Generally, the following principles are defined for operation sequences:

[1308] a. To create an operation sequence, you need to add operation steps to it.

[1309] b. The operation steps can be repeated once or multiple times.

[1310] c. The sequence of operations may include parallel operation steps.

[1311] d. One or more operation steps can be automatically added to an operation sequence using existing operation templates. Operation templates contain some predefined operation steps with default operation times.

[1312] e. Process sequences can combine operations added manually from templates and operations added automatically.

[1313] Each operation step description can include the following fields:

[1314] a. The sequence number of the operation step in the current operation sequence.

[1315] b. Operation step name.

[1316] c. A list of equipment required for this operation. Equipment may be presented as links to specific equipment units (e.g., listed in an equipment library) or as a layout.

[1317] d. (Optional) A list of workers required for the operation steps, including worker tags and / or worker skills for each worker.

[1318] e. Operation step time. In this case, if the operation step is linked to one or more recipes, its step time may depend on the timing parameters given in the recipe.

[1319] f. List of recipes. Each step may have zero or more recipes.

[1320] A recipe is a description of a set of operational steps, parameters, and their values.

[1321] a. Each formulation has its own applicable conditions. Applicability may depend on the material of the part, bolt size, bolt length, or other parameters.

[1322] b. During product design, a decision is made regarding which available recipes to use for the operational steps to match the r-service. For example, for a welding operation defined in the product design's metadata, the r-service "Welding" will be selected. However, if aluminum parts exist in the product design, the recipe "Aluminum Welding" will be used. For steel parts, the recipe "Steel Welding" will be used.

[1323] c. Parameters of the formula, including temperature, heating rate, cooling rate, heating duration, etc.

[1324] d. If the recipe defines any durations, they will affect the operation step time and the overall process time.

[1325] -r service layout, which can be used as a template for creating working monolith layouts or higher-level r services.

[1326] -r service applicability constraints.

[1327] The applicability constraints of an R service define the conditions and requirements for its application. Applicability constraints are used to find a suitable R service for a given operation and part.

[1328] For an r service that includes operations on parts (workpieces), applicability constraints typically include supported part attributes to define which process in the r service is applicable to a set of parts (workpieces) with specific attributes.

[1329] Part attributes can be:

[1330] a. Either a specific part number (one or more part numbers).

[1331] b. Either it is a set of part attributes that are not bound to a specific part number.

[1332] Examples of this type of property are:

[1333] i. Maximum part weight, for example, in kg;

[1334] ii. Maximum part bounding box (width, length, height / thickness), for example in mm;

[1335] iii. The material of the parts.

[1336] Furthermore, applicability constraints can be operation-specific. For example, for the "tightening" operation, applicability constraints could include a "bolt type" constraint, for the "tightening" operation a "bolt size" constraint, and for the "FDS-tightening" operation a "FDS size" constraint.

[1337] The description of the r service also includes:

[1338] ID—A unique identifier for the r service, used to address this specific r service, and

[1339] Revision version—an identifier for the version of the r service. When an r service is created, its revision version can be set to a default value, such as "AA". The revision version of the r service automatically increments after any changes are made.

[1340] The above structure of r service is in Figure 50 The diagram in the middle is shown. Figure 50 The diagram illustrates the hierarchical structure of the r-service 413, comprising a description layer 414, a process / operation layer 415, an equipment layer 416, and a settings layer 417. The process / operation layer includes data about all processes 418, 419, and 420 contained within the r-service, a series of part attributes 421, a process template 422, and a complete set of operation steps 423, which includes the timing of each step in each of processes 418-420. Furthermore, the set of operation steps 423, or individual operation steps within the set, may include a settings list template 424, which defines the content and format of a settings list for one or more operation steps.

[1341] Equipment layer 416 includes a list of equipment items 425, 426, 427 required for each operational step of each process 418-420 of the r service. Each equipment item is assigned specific capabilities 425A, 426A, 427A based on the equipment item and the operational step. Finally, setup layer 417 includes a list of specific components 428 required for performing the operational steps of the r service (which will match a series of part attributes 421 429) and all available recipes 430, 431, 432 for each operational step of each set of operational steps 423 of the r service.

[1342] Figure 51 The diagram illustrates the "synthesis" portion of the structure of service 433, where one of the operation steps 434, namely step 435 of "running the synthesis cycle", has several available recipes 436A, 436B and 436C, each recipe providing different settings for the synthesis cycle.

[1343] The r service center uses the constraints of r services to match r services with the operations defined in the product design metadata, that is, to determine which r services support the operations identified in or from the product design metadata.

[1344] The r service center is configured to define accurate inputs from product design metadata and match them to the constraints of the r service.

[1345] In order to perform the matching, the parameters defined in the product design metadata are checked against the corresponding constraints defined in the r service.

[1346] Matching does not take into account the rig used by the r service. It can only be used by the front end to provide suggestions to users when defining constraints for the r service.

[1347] Each parameter of the metadata for the product design or a part of the product design is checked against one or more corresponding constraints defined for the r service.

[1348] For each input parameter defined in the product design metadata, if an r service containing the corresponding constraint exists, then the constraint is verified => parameter; if there is no match, the r service is "filtered out" from the results; if there is a match, then the r service is included in the results.

[1349] By example:

[1350] 1) If the r service contains part boundary constraints, such as height=100, and the product design input parameters contain part boundary constraint value height=100, then the r service will be a match.

[1351] 2) If the r service contains part boundary constraints, such as height = 100, and the product design input parameters contain part boundary constraint value height = 101, then the r service will be mismatched.

[1352] The r service defines the next level of abstraction in the Arrival robot manufacturing model, above the levels of abstraction for resources, agents, and capabilities.

[1353] In summary, r services consist of hardware (equipment + layout), software (operation sequence descriptions, such as APL scripts) and / or manpower, and provide one or more production capabilities.

[1354] Production capabilities correspond to specific operations on one or more parts, workpieces, components, and other resources. Furthermore, maturity level 437 can be assigned to each r service. Figure 52 The diagram illustrates the interaction scheme between the storage service 439's library, the service center 438, and the micro-factory's operation control system (OCS).

[1355] The r-service center 438 contains multiple r-services 439, each of which, according to relevant constraints 441, defines the production capabilities 440 provided by the operation of the r-service. The r-service center communicates with the blackboard 442 and enablers 443 (such as execution engines) of the OCS in the microfactory or other robotic production environment. Any updates or modifications to available r-services (e.g., when a new r-service is created) are published by the r-service center 438 on the blackboard 442 so that the information becomes automatically available to the OCS of the microfactory. In this way, after an r-service is registered with the r-service center, the OCS can use the new r-service in the microfactory almost simultaneously.

[1356] In the Arrival robotic manufacturing system, r services can be simulated to demonstrate their operational feasibility and determine their KPIs. For example, this can be achieved by writing a model of the r service on a blackboard and running a simulator engine to simulate the r service layout and its execution in a virtual environment. Figure 52 As shown.

[1357] For example, estimating the probability of KPIs for services in the service center through simulation is an important feature of Arrival robot manufacturing.

[1358] For example, the following KPIs can be estimated using the R service description.

[1359] 1. Operational Steps Cost

[1360] Operation_step_cost=Operation_step_CAPEX+Operation_step_OPEX

[1361] Operation_step_cost_per_second=Operation_step_cost / Operation_step_time

[1362] 2. Capital expenditure for one operational step

[1363] Operation_step_CAPEX=Step_equipment_cost_per_second*Operation_step_time

[1364] Step_equipment_cost_per_second=((sum of equipment_cost) / (CAPEX_YEARS*WORKING_DAYS_PER_YEAR*WORKING_HOURS_PER_SHIFT*60 minutes*60 seconds*SHIFTS_PER_DAY))

[1365] The following values ​​can be used:

[1366] CAPEX_YEARS = 5

[1367] WORKING_DAYS_PER_YEAR=254

[1368] WORKING_HOURS_PER_SHIFT = 8

[1369] SHIFTS_PER_DAY = 1

[1370] 3. Operating expenses for one operation step

[1371] Operation_step_OPEX=(Electricity_cost_per_second+Manpower_cost_per_second)*Operation_step_time=(sum of Equipment_unit_power_consumption_cost_per_second+sum of Worker_cost_per_second)*Operation_step_time

[1372] Equipment_unit_power_consumption_cost_per_second=(Power_consumption*ELECTRICITY_PRICE_PER_kWh) / (60 minutes*60 seconds)

[1373] Worker_cost_per_second=ANNUAL_GROSS_SALARY / (WORKING_DAYS_PER_YEAR*WORKING_HOURS_PER_SHIFT*60 minutes*60 seconds)

[1374] 4. Operating costs

[1375] Operation cost = the sum of operation step cost

[1376] Operation_CAPEX = the sum of Operation_step_CAPEX

[1377] Operation_OPEX = the sum of Operation_step_OPEX

[1378] Total cost of service equipment = the sum of equipment costs

[1379] The r service implements and extends the modular concept of the Arrival system. An r service is an independent module, comprising individual service layouts from which a robotic production environment can be constructed. An exemplary 3D view of the r service layout 445, "cut with a layer cutter," is shown in [image 444]. Figure 53 The diagram is shown in the middle because it can be displayed in the user interface (UI) 448 of the r service center. As can be seen, the given layout includes a very limited set of equipment, consisting only of a board cutter 446 and a proximity sensor 447 (ID#001100), which is sufficient to provide operation for a given r service.

[1380] Therefore, R services are self-contained objects and can be directly included in the production environment layout. On the other hand, the R service approach and R service center allow for optimization of the production environment layout by grouping different R services into different work units.

[1381] In fact, in the Arrival robot manufacturing model, we have several entities—work units, r services, and equipment items—that depend on each other. For example, a work unit definition can depend on equipment items contained in a linked r service.

[1382] Accordingly, the R Service Center includes a library of work units, which contains the layouts developed and the R services assigned to them. In the work unit editing tool of the R Service Center, new work units can be defined as part of existing ones based on information about the R services. Existing work units can also be viewed and edited.

[1383] In the work unit's edit mode, R services can be added and positioned on the work unit layout as predefined building blocks. Doors for the work unit can also be defined here, specifying the door type (input, output, or both). Information regarding work unit layouts and doors will be further used in the Arrival Robotics Manufacturing layout studio described below to create production environment layouts and simulate internal logistics.

[1384] The r Service Center further provides simulations and visualizations of the operations of work units and the r services assigned to them. In this way, the r Service Center enables the creation of fully tested and deployment-ready work units, including the unit layout and r services.

[1385] Figure 54 A 3D visualization 449 shows the layout of the work unit in UI 448 of the r service center. It shows the work unit layout has two doors 450 and 451, and the r service 445 "Cut with Board Cutter" is assigned to two board cutters 446A and 446B in the work unit layout. It can be seen that... Figure 54 Working unit layout ratio Figure 53 The individual r service layout is much more complex and developed.

[1386] Additionally, it's necessary to understand that r-services, work units, and rigs reside at different levels of abstraction within the Arrival robot manufacturing model. A work unit can simultaneously host different r-services and can change the hosted r-services over time, depending on the current task and the rig...

Claims

1. A robotic production environment for vehicles, wherein, The environment includes robots, which are organized into groups of units, each unit having no more than 10 robots, and wherein: (i) A set of monomers is configured to transform a fabric structure into a composite body panel, the interior color of which matches the final exterior color of the body panel, thereby eliminating the need for steel panel pressing equipment and painting equipment, and wherein the monomer set includes a molding monomer having a tool configured to mold a fabric structure made of fibers and a thermoplastic matrix to form a composite colored body panel, wherein an autonomous mobile robot (a) is configured to supply the fabric structure to the molding monomer, and an autonomous mobile robot (b) moves the composite colored body panel formed by the monomer away from the monomer to a trimming monomer to trim and shape the composite colored body panel into a final shape; (ii) Other units are configured to assemble modular components and composite color body panels together to form at least a portion of the vehicle; (iii) Wherein, the robotic production environment includes autonomous mobile robots configured to serve each individual unit, eliminating the need for mobile production lines in the production environment.

2. The vehicle robot production environment according to claim 1, wherein, The production environment is installed in a factory or factory network, each with an area of ​​less than 25,000 square meters, and The production environment is located in a building with a conventional, flat concrete floor that has not been reinforced for the vehicle body panel stamping machine.

3. The vehicle robot production environment according to claim 1, wherein, Composite color body panels eliminate the need for traditional painting.

4. The vehicle robot production environment according to claim 1, wherein, The unit for assembling modular components and composite color body panels into at least a portion of the vehicle structure includes a group of robots programmed to assemble at least a portion of the vehicle at a fixed location rather than at a moving production line by linking together multiple modular parts, each part being designed or selected for robotic production, handling, or assembly; and the individual units together substantially assemble the entire vehicle.

5. The vehicle robot production environment according to claim 1, wherein, The unit for assembling modular components and composite color body panels into at least a portion of the vehicle structure includes a group of robots programmed to assemble at least a portion of the vehicle in a fixed location rather than at a moving production line by: (a) linking multiple components together to form a structural chassis and a body structure, and (b) adding composite color body panels and composite roof panels to the body structure, and all said components and panels are designed or selected for robotic production, handling, or assembly.

6. The vehicle robot production environment according to claim 1, wherein, The robotic production environment is configured to assemble at least one of the following vehicle types: small passenger cars, large passenger cars, small vans, large vans, specialty vans, trucks and vans of different lengths and capacities, buses of different lengths and capacities, and wherein multiple units can be reused as part of a set of units for the production of any of these types of vehicles, and wherein the robotic production environment is configured to be automatically reconfigured by software-implemented changes to automatically perform the following operations: manufacturing different parts, assembling different types of vehicles, assembling different configurations of the same type of vehicles, using different assembly techniques, using different components, or using alternative physical routes to transport vehicle parts or structures through the physical environment of the factory.

7. The vehicle robot production environment according to claim 1, wherein the vehicle robot production environment has a layout or arrangement of individual units positioned on a standardized linear grid, and in, The physical layout or arrangement of the individual robots in the robot production environment has been planned by an automated layout design tool, which determines the optimal or preferred layout or arrangement of the individual robots and the robot services performed by each individual robot.

8. The vehicle robot production environment according to claim 1, wherein the vehicle robot production environment has a layout or arrangement of individual units positioned on a standardized linear grid, wherein, The layout or arrangement of the individual units in the environment has been designed by an automated simulation tool that takes into account parameters including: production cost; production time; production quality; component availability; transportation of parts and sub-components using an AMR; and wherein the robot production environment is configured to include a model or map of its physical environment, which is generated, enhanced, or refined in real time by the AMR and the robot using at least SLAM computer vision technology.

9. The vehicle robot production environment according to claim 1, wherein, The robot production environment includes a master semantic model of its physical environment, which enables AMRs and robot agents to correlate, at the semantic level, with the functionality or other attributes of fixed and dynamic objects detected by the AMRs and robot agents. The automated layout design tool determines the layout or arrangement of the individual units and the robot services performed by each unit using a simulation, the simulation including a simulation using a robot service control system, and the robot service control system used in the simulation is also used to control the robot services in a real-world robot production environment.

10. The vehicle robot production environment according to claim 1, wherein, The robotic production environment includes or accesses automated vehicle design tools, and The automated vehicle design tool is configured to design vehicles that specifically meet a set of customer requirements. The robotic production environment is configured to automatically build or assemble a vehicle designed by the automated vehicle design tool with a customer-specified configuration using build instructions automatically generated by the automated vehicle design tool. The customer-specified configuration includes one or more of the following: battery capacity or range, vehicle length, vehicle height, vehicle weight, vehicle width, and specific sensors.

11. The vehicle robot production environment according to claim 10, wherein: (i) The automated vehicle design tool is configured to automatically analyze the design of a vehicle and plan the automated production of the vehicle by selecting a robot service from a catalog of available robot services; (ii) The automated vehicle design tool is configured to send production data defining the vehicle to the vehicle robot production environment; (iii) The vehicle robot production environment is configured to produce the vehicle or control the production of the vehicle by (a) using the data sent by the automated vehicle design tool and (b) using selected robot services.

12. The vehicle robot production environment according to claim 10, wherein: (i) The automated vehicle design tool is configured to access data defining a set of modular hardware components and a set of modular software components, each of which is optimized for robot assembly, and then select and generate a list of the modular hardware and software components that meet the requirements specified by the customer. (ii) The automated vehicle design tool is configured to send a list of selected modular hardware and modular software components to the vehicle robot production environment; (iii) The vehicle robot production environment is configured to assemble the vehicle or control the assembly of the vehicle using the list of modular hardware and modular software components sent by the automated vehicle design tool.

13. The vehicle robot production environment according to claim 1, wherein, The robotic production environment is configured to operate without predefined takt times and is configured to dynamically and automatically determine, in real time, by itself or in combination with other local or non-local computing resources: (i) which steps to perform, (ii) when to perform these steps, (iii) which agents, including both robotic and non-robotic agents, should perform these steps, and (iv) how these agents interact with each other to build or assemble the vehicle.

14. The vehicle robot production environment according to claim 1, wherein, A single unit is responsible for assembling and linking one or more of the following together: (i) Modular components that form part or all of the chassis or skateboard platform; (ii) Modular components that form part or all of the superstructure of the vehicle body; (iii) Modular transverse chassis segments; (iv) From frame or modular vehicle body components to modular chassis segments; (v) Modular drive chain to modular wheel arches; (vi) Modular drive chain to chassis segment; (vii) Modular chassis segments to wheel arch covers; (viii) Battery modules that form a battery pack; (ix) The composite main panel extends to the upper structure of the vehicle body; (x) Composite main panel to chassis segment; Furthermore, multiple individual robots are configured to solve problems dynamically and in real time, arbitrate as needed, and perform optimal production processes for each vehicle sub-component or the parts they assemble.

15. The vehicle robot production environment of claim 1, comprising a plurality of robot units, wherein the plurality of robot units use unit-based assembly operations controlled by a software system instead of conventional production lines to produce composite parts or panels, wherein, The monomers are not restricted to processing materials in an order defined by their physical location; The robot unit includes units for some or all of the following: a spinning machine for spinning fibers and yarns, a loom for weaving the fibers and yarns into a fabric structure, a molding unit for molding the fabric structure into a composite part or panel, a trimming unit for trimming and shaping the composite part or panel into a final shape, and an adhesive or assembly unit for bonding different parts or panel segments together.

Images