Method, computer program, device and communication interface for a communication between a robot and a transport means, and transport means and robot

Abstract

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 transport means. The invention also relates to a transport means and a robot, in which a solution according to the invention is used. In the solution according to the invention, application protocols for applications compatible with the transport means are received by the transport means or the robot (10). If necessary, the robot is initialised (11) by a manufacturer of the transport means or a service provider. An authentic connection is now established between the robot and the transport means (12) and conditions and statuses for an action to be carried out by the robot are negotiated (13). On completion of the negotiation (13) the action to be carried out by the robot is assigned (14). During the processing of the action to be carried out, the robot triggers (15) at least one action based on an application protocol, which action has to be executed by a component of the transport means. If necessary, the statuses or sensor data can be exchanged (16) between the transport means and the robot while the measure to be carried out is being processed.

Description

[0001] Description

[0002] Method, computer program, device and communication interface for communication between a robot and a means of transport, as well as means of transport and robot

[0003] 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 locomotion and a robot in which a solution according to the invention is used.

[0004] The automated parking and driving functions that will be available in the next vehicle generations and will fundamentally change the way we handle vehicles will result in a need for automated vehicle services. In addition to automatic charging and refueling, other applications are coming into focus, such as the use of robots for automatic interior cleaning, sensor cleaning, loading and unloading, parking, or performing inspections, maintenance, wheel changes, or interior reconfiguration.

[0005] For example, US 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 configured to generate control signals for controlling the robot for a given work task and to transmit them to the robot via the data interface.

[0006] 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 with a plurality of arm sections and a gripper unit arranged 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.

[0007] US 2021 / 0197684 A1 describes a robotic system for refueling or charging a vehicle. The robotic system comprises a robotic arm and a flexible line operatively connected to the robotic arm for supplying fuel or power to a vehicle. The robotic system further comprises a control system for operating the robotic arm and line, wherein the control system includes a sensor for identifying the vehicle and determining whether the vehicle is authorized to use the robotic system.

[0008] To date, communication with a vehicle has primarily been achieved through Car2X communication and communication via a diagnostic interface. However, Car2X communication does not allow, for example, a robot to be granted access to the vehicle's interior via automatically opening doors or windows. However, this may be mandatory depending on the desired service. Furthermore, this interface does not allow access to the vehicle's electronic systems. The diagnostic interface cannot be accessed wirelessly without additional devices and, without extension, does not allow dedicated, application-specific communication with a robot.

[0009] DE 10 2019 008 060 A1 describes a method for performing an electrical charging process of an electrical energy storage device of an electrically powered vehicle, wherein a charging request is transmitted to a control unit of the electrically powered vehicle using a communication terminal or an infotainment system of the electrically powered vehicle. A control signal is generated by the control unit depending on the transmitted charging request, and the generated control signal is transmitted by the control unit via a communication bus to a vehicle-side charging port of the electrically powered vehicle and to a main unit of the infotainment system.The control signal is transmitted via a local radio network from the main unit of the infotainment system to a charging device, whereby an automatic plug-in contact of a charging plug of the charging device with the vehicle-side charging connection is carried out depending on the control signal transmitted to the vehicle-side charging connection and to the charging device.

[0010] DE 10 2016221 488 A1 describes a method for the autonomous operation of a motor vehicle that is at least partially electrically operable. The method is provided after a charging process of an electrical energy storage device of the motor vehicle and can then be carried out by a control device of the motor vehicle. The control device first detects the completion of the charging process of the motor vehicle. In a next step, the control device detects decoupling of the motor vehicle from the charging infrastructure, for example, a signal from the charging infrastructure authorizing departure. After detecting the decoupling of the motor vehicle, the motor vehicle departs autonomously. The control device parks the motor vehicle autonomously within a takeover area for the motor vehicle.

[0011] 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. In the method, a depth sensor is used to determine one or more consecutive positions of the motor vehicle 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. Depending on the determined positions, navigation data can be transmitted to the motor vehicle.

[0012] DE 10 2014226 357 A1 describes a method for automatically charging an electrical energy storage device in a vehicle. For this purpose, the position of a charging socket on a vehicle is first determined based on vehicle-specific data. A charging robot then moves along the ground near the charging socket. The charging robot then establishes a galvanic connection between the charging station and the charging socket. To do this, 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 withdrawn from the charging socket, thus releasing the vehicle.

[0013] US 10,504,094 B1 describes solutions for using a vehicle as a means of payment, allowing a user to remain in the vehicle while paying for goods and services. An application is stored in the vehicle's infotainment system, storing data representing financial cards for payments. To retrieve one of the stored financial cards for a payment, the user can select a financial card entry on the infotainment system. In response to the selection, the infotainment system transmits the selected data to a POS terminal via a short-range communication link. The POS terminal can then process the payment based on the transmitted data and transmit an electronic receipt, which is displayed on the infotainment system.

[0014] With regard to the automatic charging of electric vehicles, the idea of ​​a suitable communication interface has already emerged. However, the proposed communication interface is intended exclusively for this specific application.

[0015] It is an object of the invention to provide improved solutions for communication between a robot and a means of transport.

[0016] This object is achieved by a method having the features of claim 1, by a computer program with instructions according to claim 11, by a device having the features of claim 12, by a communication interface according to claim 13, by a means of locomotion according to claim 14, and by a robot according to claim 15. Preferred embodiments of the invention are the subject of the dependent claims.

[0017] According to a first aspect of the invention, a method for communication between a robot and a means of transport comprises the steps:

[0018] - Establishing an authentic connection between the robot and the means of transport;

[0019] - Negotiating conditions and states for an action to be performed by the robot;

[0020] - Commissioning the action to be carried out by the robot; and

[0021] - triggering at least one action to be performed by a component of the means of transport by the robot, wherein the at least one action is based on an application protocol.

[0022] According to a further aspect of the invention, a computer program comprises instructions which, when executed by a computer, cause the computer to perform the following steps for communication between a robot and a means of transport:

[0023] - Establishing an authentic connection between the robot and the means of transport;

[0024] - Negotiating conditions and states for an action to be performed by the robot;

[0025] - Commissioning the action to be carried out by the robot; and

[0026] - Triggering at least one action to be performed by a component of the means of transport by the robot, wherein the at least one action is based on an application protocol. The term computer is to be understood broadly. In particular, it also includes control units, embedded systems, and other processor-based data processing devices.

[0027] The computer program may, for example, be made available for electronic retrieval or stored on a computer-readable storage medium.

[0028] According to a further aspect of the invention, a device for communication between a robot and a means of locomotion comprises:

[0029] - a connection module for establishing an authentic connection between the robot and the means of transport;

[0030] - a communication module for negotiating conditions and states for an action to be performed by the robot and for ordering the action to be performed by the robot; and

[0031] - a control module for triggering at least one action to be performed by a component of the means of transport by the robot, wherein the at least one action is based on an application protocol.

[0032] According to a further aspect of the invention, a communication interface is set up for communication between a robot and a means of transport:

[0033] - to receive application protocols for applications compatible with the means of transport;

[0034] - to establish an authentic connection between the robot and the means of transport;

[0035] - to negotiate conditions and states for an action to be performed by the robot and to commission the action to be performed by the robot; and

[0036] - to trigger at least one action by the robot to be carried out by a component of the means of transport, wherein the at least one action is based on an application protocol.

[0037] The inventive solution provides a universal communication interface that can be used to ensure communication for each automated service via different robots. The communication interface can be used for both known and as yet unknown applications that require, in addition to information about the means of transport or the states of the means of transport, interactions between the means of transport and a robot or other infrastructure, and possibly also interactions with people if individual required actions or states cannot be carried out or established automatically. The inventive solution has the advantage that a new communication standard is not required for each application of an automated service, which must be coordinated over several years and individually integrated into the means of transport.

[0038] According to one aspect of the invention, application protocols for applications compatible with the means of transport are received by the means of transport or the robot from a backend of a manufacturer of the means of transport or a service provider. Once the process for a new application has been described and released, the process is transmitted to the means of transport or the robot in the form of an application protocol. This can be done, for example, via a mobile phone connection via a backend. The application defined in the application protocol can then be executed automatically together with the external robots or other infrastructure resources, if necessary supported by people who perform individual actions manually.

[0039] According to one aspect of the invention, the application protocols include process steps with state conditions, state-changing actions, or interactions. For example, the actions can include actuating actuators, turning lights, display elements, or other systems on or off, setting the idle state, or moving to a target pose. This allows for ensuring that the vehicle is always in the state required for the respective process step during the execution of a process.

[0040] According to one aspect of the invention, trust levels are specified for actions. To meet the aforementioned universal application requirement, it is sensible to take into account the diverse and high requirements for trust relationships between robots and means of transportation. The use of trust levels ensures that actions considered critical can only be performed if a sufficiently strong trust relationship has been established.

[0041] According to one aspect of the invention, actions can be aborted by the robot. This is particularly advantageous if people in the vicinity of the means of transport could be endangered or if there is a risk of damage to the means of transport or the robot. According to one aspect of the invention, states or sensor data are exchanged between the means of transport and the robot. For example, the robot can provide the means of transport with environmental information that the means of transport cannot detect itself, e.g. 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 transport, e.g. sensors for interior monitoring, can in turn be used to safeguard the robot process.

[0042] According to one aspect of the invention, 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 transport.

[0043] According to one aspect of the invention, the authentic connection is established based on a public key infrastructure. Using a public key infrastructure makes it easy to ensure that communication between the robot and the means of transport is mutually authenticated by certificates.

[0044] According to one aspect of the invention, the robot is initialized by a manufacturer of the means of transport or a service provider, during which a symmetric key for an action to be performed by a component of the means of transport is transmitted to the robot. The various symmetric keys used in the respective means of transport are stored in the backend of the manufacturer or a service provider commissioned by the manufacturer. During initialization, the keys required for the specific process are transmitted to the robot. To do this, the robot first establishes a trust relationship with the backend, e.g., using a secret that was introduced during robot production.

[0045] According to one aspect of the invention, the symmetric key is used to authenticate and trigger an action defined as critical. The components in the actuators of means of transport are often embedded systems that are subject to certain restrictions regarding the use of cryptography. For example, computationally and memory-intensive asymmetric algorithms, which normally authentically prove trust relationships with the help of a public key infrastructure, are often not applicable here. This means that these critical components with higher trust levels (e.g., Trust Level 2) are regularly secured with symmetric keys. The symmetric keys transmitted during initialization therefore make it possible to establish an authentic, approved connection between the robot and special, technically limited but highly critical systems of the means of transport.An example of a highly critical system is the brake control unit of a motor vehicle.

[0046] According to one aspect of the invention, a relationship of trust is established between the means of transport and a group of robots. Depending on the application, it may be necessary for several robots to work together on the means of transport. These can be individual robots, e.g. a loading robot and a transport robot, but also robot modules that combine to form a robot. By extending the relationship of trust to a group of robots, a relationship of trust does not have to be established individually for each robot or robot module. Examples of robots or robot modules that can work together are a special gripper arm for refueling, transport robots, lifting platform robots, cleaning robots, a thin gripper arm for interventions in the engine compartment or an interface gripper arm for accessing a diagnostic interface.

[0047] A solution according to the invention is particularly advantageously used 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 utilize automated services. Vehicle-related applications can be carried out and automated without the presence of the driver or the vehicle key. This enables new business models to be implemented.

[0048] Further features of the present invention will become apparent from the following description and the appended claims taken in conjunction with the figures.

[0049] Fig. 1 shows schematically a method for communication between a robot and a means of transport;

[0050] Fig. 2 shows a first embodiment of a device for communication between a robot and a means of transport;

[0051] Fig. 3 shows a second embodiment of a device for communication between a robot and a means of transport; Fig. 4 schematically illustrates a means of transport in which a solution according to the invention is implemented;

[0052] Fig. 5 schematically shows a robot in which a solution according to the invention is implemented;

[0053] Fig. 6 shows a schematic system diagram of a solution according to the invention; and

[0054] Fig. 7 shows an example of a communication process within an automatic

[0055] Service.

[0056] To better understand the principles of the present invention, embodiments of the invention are explained in more detail below with reference to the figures. It is understood that the invention is not limited to these embodiments and that the described features may also be combined or modified without departing from the scope of the invention as defined in the appended claims.

[0057] Fig. 1 schematically shows a method for communication between a robot and a means of transport. In a first step, application protocols for applications compatible with the means of transport are received 10 by the means of transport or the robot. The application protocols 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 state conditions, state-changing actions or interactions. Trust levels can be specified for the actions. If necessary, an initialization 11 of the robot is carried out by a manufacturer of the means of transport or a service provider. During initialization 11, a symmetric key for an action to be performed by a component of the means of transport is transmitted to the robot.An authentic connection is now established between the robot and the means of transport 12, and conditions and states for an action to be performed by the robot are negotiated 13. The authentic connection can, in particular, be a two-channel connection. At the end of the negotiation 13, the action to be performed by the robot is commissioned 14. When processing the action to be performed, the robot, based on an application protocol, triggers at least one action 15, which must be executed by a component of the means of transport. The previously transmitted symmetric key may be required for this, e.g., if the action is defined as critical. If necessary, states or sensor data can be exchanged between the means of transport and the robot 16 while the action to be performed is being processed.If this should become necessary, the robot can cancel the action.

[0058] Fig. 2 shows a simplified schematic representation of a first embodiment of a device 20 for communication between a robot and a means of transport. The device 20 has an interface 21 via which data D can be exchanged between the robot and the means of transport. Application protocols AP for applications compatible with the means of transport can also be received via the interface, e.g. from a backend 60 of a manufacturer of the means of transport or a service provider. The application protocols AP can in particular contain process steps with state conditions, state-changing actions or interactions. Trust levels can be specified for the actions. A connection module 22 is configured to establish an authentic connection between the robot and the means of transport. The authentic connection can in particular be a two-channel connection.A communication module 23 is configured to negotiate conditions and states for a measure to be performed by the robot and to commission the measure to be performed by the robot. A control module 24 is configured to trigger at least one action, to be executed by a component 42 of the means of transport, in response to a corresponding command from the robot. The action is based on an application protocol AP. For this purpose, the control module 24 can, for example, output corresponding control commands S to the affected component 42 via an output 27 of the device 20. If necessary, states or sensor data can be exchanged between the means of transport and the robot via the interface 21 while the measure to be performed 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, for example, if the action is defined as critical. The key can be transmitted to the robot beforehand by a manufacturer of the vehicle or a service provider during the initialization process.

[0059] The connection module 22, the communication module 23, and the control module 24 can be controlled by a control module 25. Settings of the connection module 22, the communication module 23, the control module 24, or the control module 25 can be changed via a user interface 28. The data generated in the device 20 can be stored in a memory 26 if necessary, 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 implemented as dedicated hardware, for example, as integrated circuits. Of course, they can also be partially or completely combined or implemented as software running on a suitable processor, for example, a GPU or a CPU.The interface 21 and the output 27 can be implemented as separate interfaces or as a combined bidirectional interface.

[0060] Fig. 3 shows a simplified schematic representation of a second embodiment of a device for communication between a robot and a means of locomotion. The device 30 has a processor 32 and a memory 31. For example, the device 30 is a computer or a control unit. 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 described methods. The instructions stored in the memory 31 thus embody a program executable by the processor 32 which implements the method according to the invention. The device 30 has an input 33 for receiving information, for example information about operating actions of a user of the machine. Data generated by the processor 32 are provided via an output 34. Furthermore, they can be stored in the memory 31.The input 33 and the output 34 can be combined to form a bidirectional interface.

[0061] The processor 32 may include one or more processor units, such as microprocessors, digital signal processors, or combinations thereof.

[0062] The memories 26, 31 of the described embodiments can have both volatile and non-volatile memory areas and can comprise a wide variety of storage devices and storage media, for example hard disks, optical storage media or semiconductor memories.

[0063] An embodiment of a solution according to the invention is described below with reference to Fig. 4 to Fig. 7. Fig. 4 schematically illustrates a means of transport 40 in which a solution according to the invention is implemented. In this example, the means of transport 40 is a motor vehicle. The motor vehicle has a communication interface 41, which in this case includes, by way of example, a device 20 according to the invention for communication between the motor vehicle and a robot. The means of transport 40 is configured to utilize automatic services in interaction with a robot. In the context of carrying out such an automatic service, it may be necessary for components 42 of the means of transport to execute actions in response to corresponding instructions from the robot. The components 42 can be, for example, actuators, e.g.for opening or closing doors, the tailgate or loading flap, or for raising or lowering the windows. They can also be control units, such as a brake control unit or a steering control unit, which may receive instructions from an automated driving system 44. Interaction with an operator of the motor vehicle can take place via a user interface 43. For example, the operator can be prompted in this way to carry out certain actions in preparation for an automated service because, for example, the motor vehicle cannot carry them out automatically. Further components of the motor vehicle are a sensor system 45 for recording environmental information or status data of the motor vehicle, and a data transmission unit 46. The sensor system 45 can, for example, comprise cameras, radar sensors, lidar sensors, or ultrasonic sensors.Using the data transmission unit 46, connections can be established to a robot and a backend, e.g., for exchanging data or 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. Data exchange between the various components of the motor vehicle takes place via a network 48.

[0064] Fig. 5 schematically shows a robot 50 in which a solution according to the invention is implemented. The robot 50 is configured to perform automatic services in interaction with a means of transport. The robot 50 has a communication interface 51 that enables connections to a means of transport and to a backend. From the backend, the robot 50 can receive, for example, application protocols that contain process steps with state conditions, state-changing actions, or interactions for an automatic service. In addition, the backend can, if necessary, transmit keys for specific actions to be performed within the framework of an automatic service. Received data can, if required, be stored in a memory 52 of the robot 50. In Fig. 5, the memory 52 is a component of the robot 50, but it can also be connected to the robot 50 merely via a data connection.

[0065] Fig. 6 schematically shows a system diagram of a solution according to the invention. In addition to a means of transport 40 on which an automatic service is to be performed, and at least one robot 50 that performs the automatic service, the system comprises a backend 60 of a manufacturer of the means of transport 40 or of a service provider. Furthermore, further robots 50' can be involved in the automatic service. The means of transport 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. Preferably, a wireless communication technology is used, such as WLAN or Bluetooth. The data transmission unit 46 also enables communication between the means of transport 40 and the backend 60, e.g.via a mobile radio connection. For this purpose, the backend 60 also has a communication interface 61. 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 released. The application protocols AP can, for example, be stored in a memory 62 of the backend 60. Depending on the selected implementation, the backend 60 can also serve as an interface to the customer, e.g., for booking or billing.

[0066] Services. If necessary, communication can also take place between robot 50 and backend 60. For example, application protocols (AP) can also be transmitted from backend 60 to robot 50. Likewise, information about its status, i.e., about possible errors or availability, can be transmitted from robot 50 to backend 60, possibly in response to a corresponding request from backend 60.

[0067] The communication interface 41 of the vehicle 40 has a data memory for storing the currently valid application protocols AP for applications compatible with the vehicle 40. It also provides authentication keys for vehicle-external communication and implements a logic controller depending on the requested application protocol AP. This logic controller uses both vehicle-internal and vehicle-external input variables. Examples of vehicle-internal input variables include vehicle states, end positions, sensor data, or data interpretations. Examples of vehicle-external input variables include commands or state specifications from the robot 50, other infrastructure devices, or smart devices, as well as the type, requirements, and availability of the applications.

[0068] Output variables of the logic control can be divided into vehicle-internal and vehicle-external output variables as well as automatic driving actions. Examples of vehicle-internal output variables are primarily actuations of actuators, such as the drives of windows or flaps, as well as the switching on or off of lights, display elements, air conditioning, etc. Examples of 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 paying for services. In addition, error memory entries and diagnostic data, if necessary complete UDS data (UDS: Unified Diagnostic Services), can be output. An example of an automatic driving action is driving to a target pose, i.e. a predetermined position and orientation.

[0069] Further input and output variables of the logic controller relate to establishing a trust relationship. The trust levels of the actions and information on the security protocols used are mentioned here merely as examples. For each cryptographic application, a selection of the following elements may be available: Cryptographic parameters, such as algorithms, keys, or parameters; specific key information, such as key IDs, transmitter counters, receiver counters, robot identification numbers, vehicle identification numbers, strings or timestamps, counters, challenges, or signatures. The specific elements used are at the discretion of the expert.

[0070] The use of a solution according to the invention is described below using a specific application example. This involves an inspection of a motor vehicle which also requires a wheel check. This requires the motor vehicle to be moved, for which purpose the brake must be released, the gear shifted out and the vehicle moved. The brake must then be applied again and the transmission put into park. It is assumed here that the motor vehicle does not have a fully automatic valet parking function. The motor vehicle does, however, have a park-steer assistant, i.e. it is possible to influence acceleration, braking and steering, but a driver is actually required to monitor the traffic situation. Since the service is to be carried out automatically and therefore no driver can intervene, the communication lies outside the classic status of the motor vehicle.Therefore, a special authentication of the action is necessary for each participant, i.e. for each control unit involved in the vehicle.

[0071] The challenges therefore arise because the required movement of the motor vehicle must be calculated and transmitted taking into account the infrastructure, such as static obstacles. In addition, the danger zone must be monitored, i.e. a safety distance x around the motor vehicle and a safety distance y in the direction of movement. Furthermore, a secure, preferably two-channel connection must be established and approval for the movement of the motor vehicle must be given. While the motor vehicle is moving, the position or trajectory deviation of the motor vehicle should be monitored by the robot or infrastructure facilities. In the event of danger, e.g. when people or another motor vehicle approach, it should be possible to trigger an emergency stop of the motor vehicle. This emergency stop should also be able to be canceled without human intervention.Finally, documentation of the fault-free or faulty movement of the motor vehicle is desirable.

[0072] The driving movement can now be carried out as follows. The robot first calculates and transmits the required movement of the motor vehicle. It also announces a critical action. The motor vehicle then sends a ready message for the critical action. The robot and motor vehicle now establish a secure, preferably dual-channel communication connection. The robot issues a release, whereupon the motor vehicle releases the brake, switches to drive mode (D) or (R) depending on the direction of movement, and moves along the specified path towards the target pose. In the event of danger, the robot triggers an emergency stop. When the motor vehicle reaches the target pose, it applies the brake and switches to drive mode (P). The robot confirms that the target pose has been reached and that the motor vehicle is in a safe state. The robot and motor vehicle then release the secure communication connection.

[0073] Fig. 7 shows an example of a communication process within the framework of an automated service. A connection was previously established between a means of transport 40 and a robot 50. The type of air interface used is irrelevant. The communication is mutually authenticated by certificates. The means of transport 40 sends S1a its interest in a service. The robot 50 then sends S2a an offer for the service. The offer includes, for example, a price for the service as well as an ID and a version designation of the robot 50. Alternatively, the expression of interest and the offer can also occur in the reverse order, represented by the dashed arrows S1b, S2b. Subsequently, the robot 50 sends S3 a request regarding the information required for the service, e.g.the ID and, if applicable, the characteristics of the means of transport 40, specific equipment, requirements for the service, type of payment, etc. The means of transport 40 responds S4 to the request with the requested information or a rejection. The robot 50 then transmits S5 a possible process flow, and the means of transport 40 books the service with the robot 50 S6. The robot 50 validates the booking S7a and commits to the offer S7b. The means of transport 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 transport 40 changes its state S11 for part 2 of the service and then sends a ready message S12.The robot 50 performs part 2 of the service S13 and then sends a ready message S14 as well as a command for an action classified as critical for part 3 of the service. For example, the means of transport 40 can be instructed to travel a specific route. An automated driving system 44 of the means of transport 40 validates the command S15, and if the validation is successful, the means of transport 40 changes its state S16 for part 3 of the service. Subsequently, the means of transport 40 sends a ready message S17. The robot 50 now performs part 3 of the service S18. This sequence continues until the last part of the service is finally performed S98 and the robot 50 sends an end message S99. The means of transport responds S100 with an end message and releases the payment.

[0074] The messages exchanged during communication between the vehicle and the robot can, for example, be implemented in the form of {protocol info, participant, status, service, business, security}. The specific design is at the discretion of the expert.

[0075] The Protocol Info element, for example, indicates whether it is a connection establishment, a service offer, a confirmation, a commitment, a ready message, or an end message. The Participant element contains, for example, an identifier, information about whether it is a robot or a means of transport, the type of robot or means of transport, a configuration of the robot or means of transport, or additional information about the robot or means of transport.

[0076] The status element contains, for example, information about the version, hardware, or software of components of the vehicle, information about the last update, the charge level, or damage. It can also contain information about the occupancy of the vehicle, whether doors are locked, whether windows are open, whether the parking brake is activated, or the steering angle. Alternatively, the status element can also be contained in the party involved element.

[0077] The service element includes, for example, 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 the aisle out, opening the door, providing information, etc.

[0078] The Business element contains, for example, information about the price, the budget, a voucher, payment information or a payment confirmation.

[0079] 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 be dependent on the cryptographic application, such as key ID, derivation parameters or certificate ID, or cryptographic components, such as signature, hash or challenge.

[0080] It may be planned to use sensors on the vehicle for monitoring and safeguarding the robot's operation, e.g., sensors for interior monitoring. In this case, it is advantageous if the protocol used also includes fields for the robot movements or even a robot movement template for each application protocol. If the sensor measurement deviates from the intended movement, the movement can be stopped and intervention by a suitable person can be requested. The template can be learned, for example, using artificial intelligence algorithms by observing the processes on the vehicle.

[0081] The solution according to the invention enables a variety of connections and trust relationships. Examples include the connection between the robot and the backend for initialization via a secret and for transmitting specific keys for the means of transport, the connection between the robot and the means of transport, e.g., via a public key infrastructure, the connection between the robot and a control unit requiring a higher level of trust using a symmetric key, and, if necessary, the connection of the backend via the robot to such a control unit for an end-to-end connection. Furthermore, a connection can exist between several robots that work together on a means of transport. Furthermore, several robots can be connected to the means of transport in a distinguishable manner. Furthermore, a connection can exist between several robot modules that connect together to form another robot, e.g.,a loading robot with a transport robot.

[0082] Even in future vehicle architectures, embedded systems such as brakes and transmissions will be cryptographically limited to symmetric algorithms. Future asymmetric algorithms must be post-quantum secure and will therefore most likely be much more complex and require considerably longer keys, making them even less suitable for embedded systems. Thus, authentication of the integrity of the triggering of an action, which requires a higher level of trust, is required from the backend to the involved embedded control unit. This can be achieved by first initializing a robot for a specific action of a means of transport via a backend. This can even occur in advance, e.g., because the means of transport is scheduled for a service.During this initialization, the robot first requests a key required for the action and receives it from the backend. The key can also have been generated by the corresponding control unit. A general, authentic contact is now established between the robot and the means of transport, e.g. based on a public key infrastructure using a certificate and public key algorithm, e.g. ECDSA (Elliptic Curve Digital Signature Algorithm) or TLS (Transport Layer Security). Further communication can then take place via this channel. 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 in detail 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, e.g., authorizing a braking action, which requires a high level of trust. A key is always unique for each means of transport. The key for the means of transport with the identification number VIN for the braking action is therefore K29_VIN. A robot with the robot ID ID_R has a connection to the backend at some point before communicating with the means of transport with the identification number VIN. By applying a hash function, cryptographic key derivation can be carried out deterministically. Key K is derived with the parameter x using the notation K(x). This results in a new key that can only be calculated by someone who knows K. The robot with the robot ID ID_R now asks the backend for the key with which it can perform a braking action on the means of transport with the identification number VIN.The backend then calculates K_ID_R_VIN=K29_VIN(ID_R, String, Timer). The robot can now send a message to the vehicle with the action to be performed, e.g., "release the brake," a signature determined from the message with the key K_ID_R_VIN, which serves to authenticate the robot's critical command by the vehicle's brake control unit, and the parameters ID_R, String, Timer. This allows the brake control unit in the vehicle, which knows K29_VIN, to calculate K_ID_R_VIN=K29_VIN(ID_R, String, Timer), i.e., the key intended for the trust relationship between the brake control unit and the robot, which is also unknown to other control units in the vehicle, and thus authenticate the signature. This ensures that an authorized robot can send the command via the communication interface. The release of the brakes would otherwise be possible with an online or Car2Car control unit, for example.never trigger. After successful authentication, the brake control unit finally performs the requested "release brake" action.

[0083] List of reference symbols

[0084] Receiving application protocols Initializing the robot

[0085] Establishing an authentic connection Negotiating conditions and states Commissioning an action to be taken Triggering an action

[0086] Exchange of states or sensor data

[0087] device

[0088] interface

[0089] Connection module

[0090] Communication module

[0091] Control module

[0092] Control module

[0093] memory

[0094] Exit

[0095] User interface

[0096] device

[0097] memory

[0098] processor

[0099] Entrance

[0100] Exit

[0101] Means of transport

[0102] Communication interface

[0103] component

[0104] User interface

[0105] Automated driving system

[0106] Sensor technology

[0107] Data transmission unit

[0108] memory

[0109] Network, 50' robot

[0110] Communication interface

[0111] memory

[0112] Backend 61 communication interface

[0113] 62 storage

[0114] AP application protocol

[0115] D Data

[0116] S control command

[0117] S1-S100 News

[0118] VI N Identification number

Claims

Patent claims Method for communication between a robot (50) and a means of locomotion (40), comprising the steps: - Establishing (12) an authentic connection between the robot (50) and the means of transportation (40); - Negotiating (13) conditions and states for an action to be carried out by the robot (50); - Commissioning (14) the action to be carried out by the robot (50); and - Triggering (15) at least one action to be performed by a component (42) of the means of locomotion (40) by the robot (50), wherein the at least one action is based on an application protocol (AP). Method according to claim 1, wherein application protocols (AP) for applications compatible with the means of locomotion (40) are received by the means of locomotion (40) or the robot (50) from a backend (60) of a manufacturer of the means of locomotion (40) or a service provider (10). Method according to claim 1 or 2, wherein the application protocols (AP) include process steps with state conditions, state-changing actions, or interactions. Method according to any one of the preceding claims, wherein trust levels are specified for actions. Method according to any one of the preceding claims, wherein actions can be aborted by the robot (50).A method according to any of the preceding claims, wherein states or sensor data are exchanged between the means of locomotion (40) and the robot (50) (16). A method according to any of the preceding claims, wherein the authentic connection is a two-channel connection. A method according to any one of the preceding claims, wherein the robot (50) is initialized by a manufacturer of the means of locomotion (40) or a service provider (11), in which a symmetric key for an action to be performed by a component (42) of the means of locomotion (40) is transmitted to the robot (50). A method according to claim 8, wherein the symmetric key is used to authenticate and trigger an action defined as critical. A method according to any one of the preceding claims, wherein a trust relationship is established between the means of locomotion (40) and a set of robots (50, 50'). A computer program with instructions which, when executed by a computer, cause the computer to execute the steps of a method according to any one of claims 1 to 10 for communication between a robot (50) and a means of locomotion (40).Device (20) for communication between a robot (50) and a means of locomotion (40), comprising:. - a connection module (22) for establishing (12) an authentic connection between the robot (50) and the means of locomotion (40); - a communication module (23) for negotiating (13) conditions and states for an action to be carried out by the robot (50) and for commissioning (14) the action to be carried out by the robot (50); and - a control module (24) for triggering (15) at least one action to be performed by a component (42) of the means of locomotion (40) by the robot (50), wherein the at least one action is based on an application protocol (AP). Communication interface (41) for communication between a robot (50) and a means of locomotion (40), wherein the communication interface (41) is configured as follows: - To receive application protocols (AP) for applications compatible with the means of transport (40) (10); - to establish an authentic connection between the robot (50) and the means of transport (40) (12); - to negotiate the conditions and circumstances for an action to be carried out by the robot (50) (13) and to commission the action to be carried out by the robot (50) (14); and - to trigger at least one action (15) by the robot (50) to be performed by a component (42) of the means of locomotion (40), wherein the at least one action is based on an application protocol (AP). Means of locomotion (40), wherein the means of locomotion (40) has a communication interface (41) according to claim 13 or is configured to perform a method according to any one of claims 1 to 10 for communication between the means of locomotion (40) and a robot (50). Robot (50), wherein the robot (50) is configured to perform a method according to any one of claims 1 to 10 for communication between the robot (50) and a means of locomotion (40).

Images