[go: up one dir, main page]

EP4486545A1 - Procédé, programme informatique, dispositif et interface de communication pour une communication entre un robot et un moyen de transport, et moyen de transport et robot - Google Patents

Procédé, programme informatique, dispositif et interface de communication pour une communication entre un robot et un moyen de transport, et moyen de transport et robot

Info

Publication number
EP4486545A1
EP4486545A1 EP23705555.3A EP23705555A EP4486545A1 EP 4486545 A1 EP4486545 A1 EP 4486545A1 EP 23705555 A EP23705555 A EP 23705555A EP 4486545 A1 EP4486545 A1 EP 4486545A1
Authority
EP
European Patent Office
Prior art keywords
robot
action
communication
locomotion
transportation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23705555.3A
Other languages
German (de)
English (en)
Inventor
Timo Winkelvos
Daniel Schütz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Volkswagen AG
Original Assignee
Volkswagen AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Volkswagen AG filed Critical Volkswagen AG
Publication of EP4486545A1 publication Critical patent/EP4486545A1/fr
Pending legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
    • B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
    • B25J9/00—Programme-controlled manipulators
    • B25J9/16—Programme controls
    • B25J9/1679—Programme controls characterised by the tasks executed
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/30—Constructional details of charging stations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/40—Robotics, robotics mapping to robotics vision
    • G05B2219/40039—Robot mounted or sliding inside vehicle, on assembly line or for test, service

Definitions

  • the present invention relates to a method, a computer program with instructions, a device and a communication interface for communication between a robot and a means of locomotion.
  • the invention further relates to a means of transportation and a robot in which a solution according to the invention is used.
  • US Pat. No. 11,020,856 B2 describes a motor vehicle with a data interface for transmitting data to a robot.
  • the motor vehicle has a control device which is set up to generate control signals for controlling the robot for a specified work task and to transmit them to the robot via the data interface.
  • US 2019/0358818 A1 describes a cleaning system for a vehicle.
  • the vehicle includes a passenger compartment and a vehicle cleaning system.
  • the vehicle cleaning system includes a vacuum unit and a robot.
  • the robot includes an arm having a plurality of arm sections and a gripper unit disposed at a distal end of the arm. The robot is connected to the vacuum unit such that the arm forms a vacuum path between the vacuum unit and the gripper unit.
  • US 2021/0197684 A1 describes a robotic system for refueling or charging a vehicle.
  • the robotic system includes a robotic arm and a flexible conduit that operatively connected to the robotic arm to deliver fuel or power to a vehicle.
  • the robotic system also includes a control system for operating the robotic arm and conduit, the control system including a sensor for identifying the vehicle and determining whether the vehicle is authorized to use the robotic system.
  • Car2X communication and communication via a diagnostic interface have been available for communication with a means of transport.
  • Car2X communication it is not intended that a robot, for example, be granted access to the interior of the means of transport via doors or windows that open automatically. However, depending on the desired service, this is mandatory.
  • this interface it is not possible to assert access to the electronic systems of the means of transport.
  • the diagnostic interface cannot be reached wirelessly without additional means and does not allow dedicated, application-related communication with a robot without an extension.
  • DE 10 2019 008 060 A1 describes a method for carrying out an electrical charging process of an electrical energy store of an electrically operated vehicle, a charging request being transmitted to a control device of the electrically operated vehicle using a communication terminal or an infotainment system of the electrically operated vehicle.
  • a control signal is generated by the control unit as a function of the transmitted charging request, and the generated control signal is transmitted with the control unit via a communication bus to a vehicle-side charging connection of the electrically operated vehicle and to a main unit of the infotainment system.
  • the control signal is transmitted to a charging device via a local radio network of the main unit of the infotainment system, with an automatic plug-in contact of a charging plug of the charging device with the vehicle-side charging connection being carried out depending on the transmitted control signal to the vehicle-side charging connection and to the charging device.
  • DE 10 2016221 488 A1 describes a method for the autonomous operation of a motor vehicle, which can be operated at least partially electrically.
  • the method is provided after the charging process of an electrical energy store in the motor vehicle and can then be carried out by a control device in the motor vehicle.
  • the control device first detects the end of the charging process of the motor vehicle.
  • the control device detects a decoupling of the Motor vehicle from the charging infrastructure, for example a signal from the charging infrastructure to release the departure.
  • the motor vehicle drives off autonomously.
  • the control device parks the motor vehicle autonomously within a takeover area for the motor vehicle.
  • DE 10 2016 004 889 A1 describes a method for supplying electrical energy or fuel to a motor vehicle using a robot at a gas station.
  • a depth sensor is used to determine one type or several positions of the motor vehicle that follow one another in terms of time relative to the robot.
  • An interface guided by the robot is connected to the motor vehicle and electrical energy or fuel is supplied to the motor vehicle via this interface.
  • navigation data can be transmitted to the motor vehicle.
  • DE 10 2014226 357 A1 describes a method for automatically charging an electrical energy store in a vehicle.
  • the position of a charging socket on a vehicle is first determined based on vehicle-specific data.
  • a charging robot then moves on the floor near the charging socket.
  • the charging robot then establishes a galvanic connection between the charging station and the charging socket.
  • the charging robot inserts a contact head connected to the charging station into the vehicle's charging socket. After the charging process is complete, the contact head is pulled out of the charging socket and the vehicle is released.
  • US 10,504,094 B1 describes solutions for using a vehicle as a means of payment, so that a user can remain in the vehicle when paying for goods and services.
  • An application storing data representing financial cards for payments is stored in an infotainment system of the vehicle.
  • the user can select information on a financial card on the infotainment system.
  • the infotainment system transmits the selected data to a POS terminal over a short-range communication link.
  • the POS terminal can then process the payment based on the transmitted data and send an electronic receipt that is displayed on the infotainment system.
  • a method for communication between a robot and a means of transportation comprises the steps:
  • a computer program comprises instructions which, when executed by a computer, cause the computer to carry out the following steps for a communication between a robot and a means of locomotion:
  • the term computer is to be understood broadly. In particular, it also includes control units, embedded systems and other processor-based data processing devices.
  • the computer program can be provided for electronic retrieval, for example, or it can be stored on a computer-readable storage medium.
  • a device for communication between a robot and a means of locomotion has:
  • connection module for establishing an authentic connection between the robot and the means of locomotion
  • a communication module for negotiating conditions and states for an action to be performed by the robot and for commissioning the action to be performed by the robot;
  • a control module for triggering at least one action to be performed by a component of the means of transportation by the robot, wherein the at least one action is based on an application protocol.
  • a communication interface is set up for communication between a robot and a means of transportation:
  • a universal communication interface is provided with which communication for each automated service can be guaranteed via different robots.
  • the communication interface can be used both for known and for still unknown applications which, in addition to information about the means of locomotion or the states of the means of locomotion, also require interactions between the means of locomotion and a robot or other infrastructure, possibly also interactions with Persons if individual required actions or states cannot be carried out or created automatically.
  • the solution according to the invention has the advantage that a new communication standard is not required for every application of an automated service, which has to be coordinated over several years and individually integrated into the means of transport.
  • application protocols for applications compatible with the means of transportation are received by the means of transportation or the robot from a backend of a manufacturer of the means of transportation or a service provider.
  • the process is transferred to the means of transport or the robot in the form of an application protocol. This can be done, for example, using a mobile phone connection via a backend.
  • the application defined in the application protocol can then be carried out automatically together with the external robots or other infrastructure means, optionally supported by people who carry out individual actions manually.
  • the application protocols contain process steps with status conditions, status-changing actions or interactions.
  • the actions may include actuating actuators, turning lights, indicators, or other systems on or off, setting neutral, or moving to a target pose. This makes it possible to ensure that the means of transport is always in the state required for the respective process step while a process is being carried out.
  • trust levels are specified for actions. In order to do justice to the universal application claim mentioned above, it makes sense that the diverse and high demands on the trust relationships between robots and means of transport are taken into account. The use of trust levels ensures that actions that are considered critical can only be carried out if a sufficiently good trust relationship has been established.
  • actions by the robot can be aborted. This is particularly advantageous when people in the vicinity of the means of transportation could be endangered or there is a risk of damage to the means of transportation or the robot.
  • states or sensor data are exchanged between the means of transportation and the robot.
  • the robot can provide the means of transportation with environmental information that the means of transportation cannot detect itself, for example due to a lack of sensors. This makes it possible to comply with safety conditions even in the absence of a driver.
  • the sensors of the means of transportation eg sensors for monitoring the interior, can in turn be used to protect the robot process.
  • the authentic connection is a two-channel connection.
  • a two-channel connection is particularly advantageous for a mutually authenticated connection between the robot and the means of transportation.
  • the authentic connection is established based on a public key infrastructure.
  • a public key infrastructure makes it easy to ensure that the communication between the robot and the means of transport is mutually authenticated by certificates.
  • the robot is initialized by a manufacturer of the means of locomotion or a service provider, in which case a symmetric key for an action to be carried out by a component of the means of locomotion is transmitted to the robot.
  • the various symmetrical keys that are used in the respective means of transport are available in the backend of the manufacturer or a service provider commissioned by the manufacturer.
  • the keys required for the specific process are sent to the robot.
  • the robot first establishes a trust relationship with the backend, e.g. using a secret that was recorded during robot production.
  • the symmetric key is used to trigger an action defined as critical in an authenticated manner.
  • the components in the actuators of means of transport are often embedded systems that are subject to some restrictions with regard to the use of cryptography. It is often not possible to use the asymmetric algorithms, which require a great deal of computing power and memory, and which normally use a public key infrastructure to authentically prove trust relationships. This means that these critical components with higher levels of trust (e.g. trust level 2) are regularly secured with symmetric keys.
  • the symmetric keys transmitted as part of an initialization therefore make it possible to distinguish between the To realize an authentic, released connection between robots and special, technically limited but highly critical systems of the means of transport.
  • An example of a system that is highly critical in terms of content is the brake control unit of a motor vehicle.
  • a relationship of trust is established between the means of locomotion and a set of robots.
  • robots can be individual robots, e.g. a loading robot and a transport robot, but also robot modules that combine to form a robot.
  • a relationship of trust does not have to be established individually for each robot or each robot module. Examples of robots or robot modules that can work together are a special gripper for refueling, transport robots, lifting platform robots, cleaning robots, a thin gripper for interventions in the engine compartment or an interface gripper for access to a diagnostic interface.
  • a solution according to the invention is used particularly advantageously in a means of transportation or in a robot.
  • the means of transportation can be, for example, a motor vehicle, e.g. a passenger car or a commercial vehicle.
  • the use of the solution according to the invention has the advantage that the means of transportation is enabled to use automatic services. Vehicle-related applications can be carried out and automated without the driver or the vehicle key being present. In this way, new business models can be implemented.
  • FIG. 1 schematically shows a method for communication between a robot and a means of transportation
  • FIG. 2 shows a first embodiment of a device for communication between a robot and a means of locomotion
  • FIG. 3 shows a second embodiment of a device for communication between a robot and a means of locomotion
  • Fig. 4 schematically represents a means of locomotion in which a solution according to the invention is implemented
  • Fig. 5 schematically represents a robot in which a solution according to the invention is implemented
  • Fig. 6 schematically shows a system diagram of a solution according to the invention.
  • Fig. 7 shows an example of a communication process in the context of an automatic
  • FIG. 1 schematically shows a method for communication between a robot and a means of transportation.
  • application logs for applications compatible with the means of transport are received by the means of transport or the robot 10.
  • the application logs can be provided, for example, via a backend 60 of a manufacturer of the means of transport or a service provider and can contain process steps with status conditions, status-changing actions or interactions . Confidence levels can be specified for the actions.
  • the robot is initialized 11 by a manufacturer of the means of transportation or a service provider. During the initialization 11, a symmetrical key for an action to be carried out by a component of the means of transportation is transmitted to the robot.
  • An authentic connection is now established between the robot and the means of transportation 12 and conditions and states for a measure to be carried out by the robot are negotiated 13.
  • the authentic connection can in particular be a two-channel connection.
  • the measure to be carried out by the robot is commissioned 14.
  • the robot triggers at least one action 15, based on an application protocol, which is carried out by a component of the means of transport must become.
  • the previously transmitted symmetric key may be required for this, for example if the action is defined as critical. If necessary, statuses or sensor data can be exchanged between the means of transport and the robot while the measure to be carried out is being processed 16. If this should become necessary, the action can be aborted again by the robot.
  • FIG. 2 shows a simplified schematic representation of a first embodiment of a device 20 for communication between a robot and a means of transportation.
  • the device 20 has an interface 21 via which data D can be exchanged between the robot and the means of transportation.
  • Application protocols AP for applications compatible with the means of transportation can also be received via the interface, e.g. from a backend 60 of a manufacturer of the means of transportation or a service provider.
  • the application protocols AP can contain process steps with status conditions, status-changing actions or interactions. Confidence levels can be specified for the actions.
  • a connection module 22 is set up to create an authentic connection between the robot and the means of transportation.
  • the authentic connection can be a two-channel connection.
  • a communication module 23 is set up to negotiate conditions and statuses for a measure to be carried out by the robot and to commission the measure to be carried out by the robot.
  • a control module 24 is configured to trigger at least one action to be performed by a component 42 of the means of transportation in response to a corresponding command by the robot. The action is based on an application protocol AP.
  • the control module 24 can, for example, output corresponding control commands S via an output 27 of the device 20 to the affected component 42 .
  • statuses or sensor data can be exchanged between the means of transportation and the robot via the interface 21 while the measure to be carried out is being processed. If this should become necessary, the action can be aborted by the robot using a corresponding command.
  • a symmetric key may be required to trigger the action, e.g. if the action is defined as critical.
  • the key can be transmitted to the robot beforehand as part of an initialization of the robot by a manufacturer of the means of transportation or a service provider.
  • connection module 22, the communication module 23 and the control module 24 can be controlled by a control module 25. Via a user interface 28, settings of the connection module 22, the Communication module 23, the control module 24 or the control module 25 are changed.
  • the data occurring in the device 20 can be stored in a memory 26 if required, for example for later evaluation or for use by the components of the device 20.
  • the connection module 22, the communication module 23, the control module 24 and the control module 25 can be used as be implemented as dedicated hardware, for example as integrated circuits. Of course, they can also be partially or fully combined or implemented as software running on a suitable processor, such as a GPU or a CPU.
  • the interface 21 and the output 27 can be implemented as separate interfaces or as a combined bi-directional interface.
  • FIG. 3 shows a simplified schematic representation of a second embodiment of a device for communication between a robot and a means of transportation.
  • the device 30 has a processor 32 and a memory 31 .
  • the device 30 is a computer or a control device. Instructions are stored in the memory 31 which, when executed by the processor 32, cause the device 30 to carry out the steps according to one of the methods described.
  • the instructions stored in the memory 31 thus embody a program which can be executed by the processor 32 and implements the method according to the invention.
  • the device 30 has an input 33 for receiving information, for example information on operator actions by a user of the machine. Data generated by the processor 32 is provided via an output 34 . In addition, they can be stored in memory 31.
  • the input 33 and the output 34 can be combined to form a bidirectional interface.
  • Processor 32 may include one or more processing units, such as microprocessors, digital signal processors, or combinations thereof.
  • the memories 26, 31 of the described embodiments can have both volatile and non-volatile memory areas and can include a wide variety of memory devices and storage media, for example hard disks, optical storage media or semiconductor memories.
  • FIG. 4 shows schematically a means of transportation 40 in which a solution according to the invention is implemented.
  • the means of transportation 40 is a motor vehicle.
  • the motor vehicle has a communication interface 41, which in this case contains, by way of example, a device 20 according to the invention for communication between the motor vehicle and a robot.
  • the means of transportation 40 is set up to use automatic services in conjunction with a robot. As part of the implementation of such an automatic service, it may be necessary for components 42 of the means of transportation to carry out actions in response to corresponding instructions from the robot.
  • the components 42 can be, for example, actuators, for example for opening or closing doors, tailgate or tailgate or for raising or lowering the windows. However, it can also be a control device, for example a brake control device or a steering control device, which may receive instructions from an automated driving system 44 .
  • An interaction with an operator of the motor vehicle can take place via a user interface 43 . In this way, for example, a request can be made to the operator to carry out certain actions in preparation for an automatic service, for example because the motor vehicle cannot carry out these actions automatically.
  • Further components of the motor vehicle are a sensor system 45 for detecting environmental information or status data of the motor vehicle and a data transmission unit 46.
  • the sensor system 45 can include cameras, radar sensors, lidar sensors or ultrasonic sensors, for example.
  • Connections to a robot and to a backend can be established by means of the data transmission unit 46, for example for exchanging data or for receiving application protocols.
  • a memory 47 is provided for storing data.
  • the memory 47 can also be part of the communication interface 41 or another component of the motor vehicle. The exchange of data between the various components of the motor vehicle takes place via a network 48.
  • FIG. 5 shows schematically a robot 50 in which a solution according to the invention is implemented.
  • the robot 50 is set up to carry out automatic services in conjunction with a means of transportation.
  • the robot 50 has a communication interface 51 that enables connections to a means of transportation and to a backend.
  • the robot 50 can, for example, receive application protocols from the backend that contain process steps with status conditions, status-changing actions or interactions for an automatic service.
  • the backend can transmit keys for certain actions to be carried out as part of an automatic service.
  • Received data can be stored in a memory 52 of the robot 50 if required. In FIG. 5, the memory 52 is part of the robot 50, but it can also be connected to the robot 50 only via a data connection.
  • FIG. 6 schematically shows a system diagram of a solution according to the invention.
  • the system includes a backend 60 of a manufacturer of the means of transportation 40 or of a service provider.
  • further robots 50' can be involved in the automatic service.
  • the means of transportation 40 has a communication interface 41 according to the invention, via which it communicates with the robot 50 using a data transmission unit 46 . Communication with other infrastructure facilities or smart devices is also possible in this way.
  • a wireless communication technology is preferably used, such as WLAN or Bluetooth.
  • the data transmission unit 46 also enables communication between the means of transportation 40 and the backend 60, e.g. by means of a cellular connection.
  • the backend 60 also has a communication interface 61 for this purpose.
  • Application protocols AP can be provided by the backend 60 and transmitted to the means of transport 40 after the corresponding processes for new applications have been described and approved.
  • the application protocols AP can be stored in a memory 62 of the backend 60, for example.
  • the backend 60 can also serve as an interface to the customer, e.g. for booking or billing
  • communication can also take place between the robot 50 and the backend 60 .
  • application protocols AP can also be transmitted from the backend 60 to the robot 50 .
  • the robot 50 can transmit information about its status, i.e. about possible errors or availability, to the backend 60, if necessary in response to a corresponding request from the backend 60.
  • the communication interface 41 of the means of transport 40 has a data memory for storing the currently valid application protocols AP for applications compatible with the means of transport 40 .
  • it provides authentication keys for vehicle-external communication and implements logic control depending on the requested application protocol AP.
  • This logic control uses both vehicle-internal and vehicle-external input variables. Examples of vehicle-internal input variables are vehicle states, end positions, sensor data or data interpretations. Examples of vehicle-external input variables are commands or status specifications from the robot 50, other infrastructure facilities or smart devices, as well as the type, requirements and availability of the applications.
  • Output variables of the logic control can be divided into vehicle-internal and vehicle-external output variables as well as automatic driving actions.
  • vehicle-internal output variables are primarily actuation of actuators, such as the drives of windows or flaps, as well as switching on or off lights, display elements, air conditioning, etc.
  • vehicle-external output variables are information about the means of transport 40, e.g. the vehicle -Internal input variables or constant vehicle parameters such as dimensions, as well as information required for booking and payment of services.
  • error memory entries and diagnostic data possibly complete UDS data (UDS: Unified Diagnostic Services; standardized diagnostic services) can be output.
  • An example of an automatic driving action is driving to a target pose, i.e. a given position and orientation.
  • Other input and output variables of the logic control relate to establishing a relationship of trust.
  • the trust levels of the actions and information on the security protocols used are only mentioned here as examples.
  • a selection of the following items may be available for each cryptographic application: cryptographic parameters, such as algorithm, key or parameters, specific key information, such as key ID, sender device counter, sender counter, receiver device counter, receiver counter, robot Identification number, vehicle identification number, string or time stamp, counter, challenge or signature. Which elements are actually used is at the discretion of the specialist.
  • the required movement of the motor vehicle must be calculated and transmitted, taking into account the infrastructure, such as static obstacles.
  • the danger area must be monitored, i.e. a safety distance x around the motor vehicle and a safety distance y in the direction of movement.
  • a secure, preferably two-channel connection must be set up and a release for the movement of the motor vehicle must be given.
  • the position or path deviation of the motor vehicle should be monitored by the robot or infrastructure facilities.
  • danger e.g. when people or another motor vehicle approach, it should be possible to trigger an emergency stop of the motor vehicle. This should also be able to be canceled again without human intervention.
  • the sequence of the travel movement can now take place as follows.
  • the robot first calculates and transmits the required movement of the motor vehicle. He also announces a critical action.
  • the motor vehicle then sends a ready message for the critical action.
  • Robot and motor vehicle now start a secure, preferably two-channel communication connection.
  • the robot issues a release, whereupon the motor vehicle releases the brake, switches to driving mode (D) or (R) depending on the direction of movement and moves on the specified path in the direction of the target pose.
  • driving mode D
  • R driving mode
  • the robot triggers an emergency stop.
  • the motor vehicle reaches the target pose, it pulls the brake and switches to drive (P) mode.
  • the robot confirms that the target pose has been reached and that the vehicle is in a safe state.
  • the robot and motor vehicle then release the secure communication link.
  • FIG. 7 shows an example of a communication sequence within the framework of an automatic service.
  • a connection has previously been established between a means of transportation 40 and a robot 50 .
  • the type of air interface used is irrelevant.
  • the communication is mutually authenticated by certificates.
  • the means of transportation 40 sends S1a an interest in a service.
  • the robot 50 then sends S2a an offer for the service.
  • the offer includes an example price for the Service as well as an ID and a version designation of the robot 50.
  • the expression of interest and the offer can also be made in the reverse order, represented by the dashed arrows S1b, S2b.
  • the robot 50 then sends S3 a request for the information required for the services, e.g.
  • the means of transport 40 responds S4 to the request with the requested information or a refusal.
  • the robot 50 now transmits a possible process flow to S5 and the means of transport 40 books the service S6 for the robot 50.
  • the robot 50 validates the booking S7a and commits itself S7b to the offer.
  • the means of transportation 40 validates the commitment S8a, goes into a start state and sends a ready message S8b. The actual service then proceeds.
  • the robot 50 performs part 1 of the service S9 and then sends a ready message S10.
  • the means of transportation 40 changes its state for part 2 of the service S11 and then sends a ready message S12.
  • the robot 50 runs part 2 of the service through S13 and then sends S14 a ready message and now also a command for an action classified as critical for part 3 of the service.
  • the means of transportation 40 can be instructed to travel a specific route.
  • An automated driving system 44 of the means of transportation 40 validates the command S15 and the means of transportation 40 changes its state for part 3 of the service S16 if the validation is successful.
  • S17 then sends the means of transportation 40 a ready message.
  • the robot 50 now carries out part 3 of the service through S18. This process continues until finally the last part of the service is performed S98 and the robot 50 sends an end message S99.
  • the means of transportation responds to S100 with an end message and releases the payment.
  • the messages to be exchanged as part of the communication between the means of transport and the robot can be implemented in the form of ⁇ protocol info, participant, status, service, business, security ⁇ .
  • the specific design is at the discretion of the person skilled in the art.
  • the Protocol info element indicates, for example, whether it is a connection setup, an offer for a service, a confirmation, a commitment, a ready message or an end message.
  • the element involved includes, for example, an identifier, information whether it is a robot or a means of locomotion, the type of robot or means of locomotion, a configuration of the robot or means of locomotion or additional information about the robot or means of locomotion.
  • the Status element contains, for example, information on the version, hardware or software of components of the means of transport, information on the last update, the charge level or damage. It can also contain information about the occupancy of the means of transport or whether doors are locked, whether windows are open, whether the parking brake is activated or what steering angle is set. Alternatively, the status element can also be contained in the participant element.
  • the service element contains e.g. information on supply or demand, a name and, if applicable, a description of the service for the customer, information on requirements for the means of transport, the environment, the infrastructure or the robot, a generic process flow, e.g. in the offer of the service, a detailed process flow, the time required, or the individual actions in detail, such as taking out aisle, opening the door, providing information, etc.
  • the Business element contains e.g. information on the price, the budget, a voucher, payment information or a payment confirmation.
  • the security element includes, for example, information on the type of cryptographic application, such as encryption or signing, the cryptographic algorithm used and the configuration, such as AES-GCM (Advanced Encryption Standard with Galois/Counter Mode), MAC SHA2 (Medium Access Control with Secure hash algorithm), key information that may depend on the cryptographic application, such as key ID, derivation parameters or certificate ID, or cryptographic components such as signature, hash or challenge.
  • AES-GCM Advanced Encryption Standard with Galois/Counter Mode
  • MAC SHA2 Medium Access Control with Secure hash algorithm
  • key information that may depend on the cryptographic application, such as key ID, derivation parameters or certificate ID, or cryptographic components such as signature, hash or challenge.
  • the protocol used also provides fields for the robot movements or even a template for the robot movements per application protocol. If the sensor measurement deviates from the intended movement, the movement can be stopped and an intervention by a suitable person can be requested.
  • the template can be used, for example, using be learned from artificial intelligence algorithms by observing the processes of means of transport.
  • connection between the robot and the backend for initialization using a secret and for the transmission of specific keys for the means of transport examples include the connection between the robot and the means of transport, e.g. via public key infrastructure, the connection between the robot and a control device that requires a higher level of trust requires, by means of a symmetric key, and possibly the connection of the backend via the robot to such a control device for an end-to-end connection.
  • connection between several robots working together on a means of transport can be distinguishably connected to the means of transportation.
  • connection between several robot modules that connect together to form another robot e.g. a loading robot with a transport robot.
  • a general, authentic contact is now established between the robot and the means of transport, for example based on a public-key infrastructure using a certificate and public-key algorithm, for example ECDSA (Elliptic Curve Digital Signature Algorithm) or TLS (Transport Layer Security). Further communication can then take place via this channel.
  • ECDSA Elliptic Curve Digital Signature Algorithm
  • TLS Transport Layer Security
  • the key transmitted during initialization can now be used to authentically trigger the action with a higher trust level.
  • the principle of key distribution can be described as follows. It is assumed that the symmetric keys of the means of transport are available in the backend. Each key has an ID. For example, K29 is the key with the ID 29. Such a key always has the same properties and use cases, eg the authorization of a braking action that requires a high level of trust.
  • a key is always individual for each means of transport.
  • the key of the means of transport with the identification number VIN for the braking action is therefore K29_VIN.
  • a robot with robot ID ID_R has a connection with the backend at some point before communicating with the vehicle with identification number VIN.
  • a cryptographic key derivation can be carried out deterministically by using a hash function. From the key K is derived with the parameter x with the notation K(x). A new key results that can only be calculated by those who know K.
  • the robot with the robot ID ID_R now asks the backend for the key with which it can brake the means of transport with the identification number VIN.
  • the robot can now send a message to the means of transport with the action to be taken, e.g. "Release the brake", a signature that is determined from the message with the key K_ID_R_VIN and is used to authenticate the critical command of the robot by the involved brake control unit of the means of transport , and the parameters ID R, Sait, Timer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Computer Security & Cryptography (AREA)
  • Robotics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Power Engineering (AREA)
  • Transportation (AREA)
  • Manipulator (AREA)
  • Control Of Position, Course, Altitude, Or Attitude Of Moving Bodies (AREA)

Abstract

La présente invention concerne un procédé, un programme informatique avec des instructions, un dispositif et une interface de communication pour une communication entre un robot et un moyen de transport. L'invention concerne également un moyen de transport et un robot, dans lesquels une solution selon l'invention est utilisée. Dans la solution selon l'invention, des protocoles d'application pour des applications compatibles avec le moyen de transport sont reçus par le moyen de transport ou le robot (10). Si nécessaire, le robot est initialisé (11) par un fabricant du moyen de transport ou un fournisseur de services. Une connexion authentique est maintenant établie entre le robot et le moyen de transport (12) et des conditions et des états pour une action à effectuer par le robot sont négociés (13). À l'issue de la négociation (13), l'action à effectuer par le robot est attribuée (14). Pendant le traitement de l'action à effectuer, le robot déclenche (15) au moins une action sur la base d'un protocole d'application, laquelle action doit être exécutée par un composant du moyen de transport. Si nécessaire, les états ou des données de capteur peuvent être échangés (16) entre le moyen de transport et le robot, tandis que la mesure à effectuer est en cours de traitement.
EP23705555.3A 2022-02-28 2023-02-16 Procédé, programme informatique, dispositif et interface de communication pour une communication entre un robot et un moyen de transport, et moyen de transport et robot Pending EP4486545A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022202040.5A DE102022202040B4 (de) 2022-02-28 2022-02-28 Verfahren, Computerprogramm, Vorrichtung und Kommunikationsschnittstelle für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel, sowie Fortbewegungsmittel und Roboter
PCT/EP2023/053924 WO2023161127A1 (fr) 2022-02-28 2023-02-16 Procédé, programme informatique, dispositif et interface de communication pour une communication entre un robot et un moyen de transport, et moyen de transport et robot

Publications (1)

Publication Number Publication Date
EP4486545A1 true EP4486545A1 (fr) 2025-01-08

Family

ID=85278580

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23705555.3A Pending EP4486545A1 (fr) 2022-02-28 2023-02-16 Procédé, programme informatique, dispositif et interface de communication pour une communication entre un robot et un moyen de transport, et moyen de transport et robot

Country Status (5)

Country Link
US (1) US20250178201A1 (fr)
EP (1) EP4486545A1 (fr)
CN (1) CN118786007A (fr)
DE (1) DE102022202040B4 (fr)
WO (1) WO2023161127A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102023209387A1 (de) 2023-09-26 2025-03-27 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zur Erhöhung einer Sicherheit während eines Ladens einer Antriebsbatterie

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014226357A1 (de) 2014-12-18 2016-06-23 Robert Bosch Gmbh Ladestation und Verfahren zum automatischen Laden eines elektrischen Energiespeichers in einem Fahrzeug
US10504094B1 (en) 2016-02-16 2019-12-10 State Farm Mutual Automobile Insurance Company Connected car as a payment device
DE102016004889A1 (de) 2016-04-22 2017-10-26 Kuka Roboter Gmbh Zufuhr von elektrischer Energie und/oder Kraftstoff zu einem Kraftfahrzeug mittels eines Roboters
DE102016221488A1 (de) 2016-11-02 2018-05-03 Audi Ag Verfahren zum autonomen Betrieb eines Kraftfahrzeugs nach einem Ladevorgang
US10207411B2 (en) * 2017-02-01 2019-02-19 Toyota Research Institute, Inc. Systems and methods for servicing a vehicle
DE102018200435B3 (de) 2017-07-31 2018-11-15 Volkswagen Aktiengesellschaft Kraftfahrzeug und Verfahren zum Steuern eines Roboters
US11235471B2 (en) 2018-05-22 2022-02-01 Uatc, Llc Automated cleaning systems for autonomous vehicles
US11496445B2 (en) * 2018-05-23 2022-11-08 Sideassure, Inc. Electronic device for secure communications with an automobile
CN109177940A (zh) * 2018-11-12 2019-01-11 长沙源婕科技有限公司 一种电池更换机器人
DE102019208288A1 (de) * 2019-06-06 2020-12-10 Volkswagen Aktiengesellschaft Steuerung eines Ladevorgangs für ein Kraftfahrzeug
CN110803065A (zh) * 2019-11-18 2020-02-18 国网天津市电力公司 一种基于可移动充电机器人的自动充电控制方法
DE102019008060A1 (de) 2019-11-20 2020-07-23 Daimler Ag Verfahren zum Durchführen eines Ladeabbruches eines elektrischen Ladevorgangs eines elektrischen Energiespeichers eines elektrisch betriebenen Fahrzeugs mittels Ladedoseninszenierung, sowie Ladesystem
US11413979B2 (en) 2019-12-30 2022-08-16 Oliver Crispin Robotics Limited Robotic systems and methods for vehicle fueling and charging

Also Published As

Publication number Publication date
DE102022202040B4 (de) 2024-11-07
CN118786007A (zh) 2024-10-15
WO2023161127A1 (fr) 2023-08-31
US20250178201A1 (en) 2025-06-05
DE102022202040A1 (de) 2023-08-31

Similar Documents

Publication Publication Date Title
EP2507676B1 (fr) Terminal de mise à quai, et système de commande de fonctions de véhicule
EP3609732B1 (fr) Dispositif de commande et procédé de commande d'une colonne de charge
EP2931567B1 (fr) Système pour l'ouverture sélective d'un véhicule par un prestataire de services
DE102019115692A1 (de) Verbesserte ladegerätsicherheit für elektrifiziertes fahrzeug
DE102015101562A1 (de) Verfahren, Systeme und Vorrichtung zum Autorisieren eines Betriebs eines Elektrofahrzeugs, das an einer Ladestation aufgeladen wird
WO2018197053A1 (fr) Procédé permettant d'autoriser en deux étapes une opération de charge au niveau d'une colonne de charge
DE102006009098A1 (de) Kraftfahrzeugdiagnose und Fahrzeugannahme
EP2936457A1 (fr) Système de gestion du temps de stationnement
DE102019122259A1 (de) Intelligente fahrzeugverbindung
DE102021126319A1 (de) Authentifizieren einer berechtigungserhöhung bei einem beförderungsdienst
DE102019123022A1 (de) Datenaustausch- und wiederversorgungsinfrastruktur für fahrzeuge
EP3747688A1 (fr) Commande d'un processus de recharge pour un véhicule automobile
DE102013219545A1 (de) Verfahren, Fahrzeug und Anordnung
DE102016220848A1 (de) Ladesystem und Verfahren zum automatisierten Laden von Elektrofahrzeugen
EP3741094B1 (fr) Systeme de commande pour vehicule automobile, procede de fonctionnement du systeme de commande et vehicule automobile comportant un tel systeme de commande
DE102022202040B4 (de) Verfahren, Computerprogramm, Vorrichtung und Kommunikationsschnittstelle für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel, sowie Fortbewegungsmittel und Roboter
EP2870045A2 (fr) Commande sur site d'un élément de voies ferrées
DE102017222434A1 (de) Verfahren zur Authentifizierung eines Kraftfahrzeugs
CN113767612B (zh) 收集与客运车辆设备相关的数据的模块
WO2018007049A1 (fr) Procédé d'authentification sécurisée de dispositifs de commande dans un véhicule automobile
DE102021104552B4 (de) Verfahren zur Energieübertragung zwischen zwei Elektrofahrzeugen mit einer externen Kontrolleinheit, eine solche Kontrolleinheit und ein System mit einer Kontrolleinheit und einem Ladekabel
DE102013200528A1 (de) Verfahren und Vorrichtung zum Betrieb eines Kommunikationsnetzwerks insbesondere eines Kraftfahrzeugs
DE102015202269A1 (de) Fahrzeugladevorrichtung
LU500993B1 (de) Verfahren zum identifizieren einer zu ladenden einrichtung und steuern von deren ladeprozess an einer ladestation
DE102023131203A1 (de) Autorisierung Für Sichere Wartungsvorgänge

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240930

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)