WO2023161127A1 - Verfahren, computerprogramm, vorrichtung und kommunikationsschnittstelle für eine kommunikation zwischen einem roboter und einem fortbewegungsmittel, sowie fortbewegungsmittel und roboter - Google Patents

Verfahren, computerprogramm, vorrichtung und kommunikationsschnittstelle für eine kommunikation zwischen einem roboter und einem fortbewegungsmittel, sowie fortbewegungsmittel und roboter Download PDF

Info

Publication number
WO2023161127A1
WO2023161127A1 PCT/EP2023/053924 EP2023053924W WO2023161127A1 WO 2023161127 A1 WO2023161127 A1 WO 2023161127A1 EP 2023053924 W EP2023053924 W EP 2023053924W WO 2023161127 A1 WO2023161127 A1 WO 2023161127A1
Authority
WO
WIPO (PCT)
Prior art keywords
robot
action
communication
locomotion
transportation
Prior art date
Application number
PCT/EP2023/053924
Other languages
English (en)
French (fr)
Inventor
Timo Winkelvos
Daniel Schütz
Original Assignee
Volkswagen Aktiengesellschaft
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 Aktiengesellschaft filed Critical Volkswagen Aktiengesellschaft
Publication of WO2023161127A1 publication Critical patent/WO2023161127A1/de

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
    • 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)
  • Robotics (AREA)
  • Power Engineering (AREA)
  • Transportation (AREA)
  • Manipulator (AREA)

Abstract

Die vorliegende Erfindung betrifft ein Verfahren, ein Computerprogramm mit Instruktionen, eine Vorrichtung und eine Kommunikationsschnittstelle für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel. Die Erfindung betrifft weiterhin ein Fortbewegungsmittel und einen Roboter, in denen ein erfindungsgemäße Lösung eingesetzt wird. Bei der erfindungsgemäßen Lösung werden Applikationsprotokolle für mit dem Fortbewegungsmittel kompatible Anwendungen durch das Fortbewegungsmittel oder den Roboter empfangen werden (10). Bei Bedarf erfolgt eine Initialisierung (11) des Roboters durch einen Hersteller des Fortbewegungsmittels oder einen Dienstleister. Nun wird eine authentische Verbindung zwischen dem Roboter und dem Fortbewegungsmittel hergestellt (12) und es werden Bedingungen und Zustände für eine vom Roboter durchzuführende Maßnahme ausgehandelt (13). Als Abschluss des Aushandelns (13) wird die vom Roboter durchzuführende Maßnahme beauftragt (14). Bei der Abarbeitung der durchzuführenden Maßnahme wird durch den Roboter, basierend auf einem Applikationsprotokoll, zumindest eine Aktion ausgelöst (15), die von einer Komponente des Fortbewegungsmittels ausgeführt werden muss. Bei Bedarf können während der Abarbeitung der durchzuführenden Maßnahme Zustände oder Sensordaten zwischen dem Fortbewegungsmittel und dem Roboter ausgetauscht werden (16).

Description

Beschreibung
Verfahren, Computerprogramm, Vorrichtung und Kommunikationsschnittstelle für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel, sowie Fortbewegungsmittel und Roboter
Die vorliegende Erfindung betrifft ein Verfahren, ein Computerprogramm mit Instruktionen, eine Vorrichtung und eine Kommunikationsschnittstelle für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel. Die Erfindung betrifft weiterhin ein Fortbewegungsmittel und einen Roboter, in denen eine erfindungsgemäße Lösung eingesetzt wird.
Aus den automatischen Park- und Fahrfunktionen, welche in den nächsten Fahrzeuggenerationen zur Verfügung stehen werden und den Umgang mit Fahrzeugen grundlegend ändern werden, resultiert ein Bedarf an automatische Dienstleistungen am Fahrzeug. Neben dem automatischen Laden oder Tanken rücken weitere Anwendungsfälle in den Fokus, beispielsweise die Nutzung von Robotern zur automatischen Innenraumreinigung, zur Sensorreinigung, zum Beladen und Entladen, zum Parken oder zur Durchführung von Inspektion, Wartung, Radwechsel oder Rekonfiguration des Interieurs.
Beispielsweise beschreibt US 11,020,856 B2 ein Kraftfahrzeug mit einer Datenschnittstelle zum Übertragen von Daten an einen Roboter. Das Kraftfahrzeug weist eine Steuereinrichtung auf, welche dazu eingerichtet ist, für eine vorgegebene Arbeitsaufgabe Steuersignale zum Steuern des Roboters zu erzeugen und über die Datenschnittstelle an den Roboter zu übertragen.
US 2019/0358818 A1 beschreibt ein Reinigungssystem für ein Fahrzeug. Das Fahrzeug umfasst eine Fahrgastzelle und ein Fahrzeugreinigungssystem. Das Fahrzeugreinigungssystem umfasst eine Vakuumeinheit und einen Roboter. Der Roboter umfasst einen Arm mit einer Vielzahl von Armabschnitten und einer Greifereinheit, die an einem distalen Ende des Arms angeordnet ist. Der Roboter ist derart mit der Vakuumeinheit verbunden, dass der Arm einen Vakuumpfad zwischen der Vakuumeinheit und der Greifereinheit bildet.
US 2021/0197684 A1 beschreibt ein Robotersystem zum Betanken oder Aufladen eines Fahrzeugs. Das Robotersystem umfasst einen Roboterarm und eine flexible Leitung, die operativ mit dem Roboterarm verbunden ist, um Treibstoff oder Strom an ein Fahrzeug zu liefern. Das Robotersystem umfasst zudem ein Steuersystem zum Betreiben des Roboterarms und der Leitung, wobei das Steuersystem einen Sensor zur Identifizierung des Fahrzeugs und zur Feststellung, ob das Fahrzeug berechtigt ist, das Robotersystem zu benutzen, enthält.
Bisher stehen für die Kommunikation mit einem Fortbewegungsmittel im Wesentlichen die Car2X-Kommunikation und die Kommunikation über eine Diagnoseschnittstelle zur Verfügung. Bei der Car2X-Kommunikation ist es allerdings nicht vorgesehen, dass beispielsweise einem Roboter Zugang zum Inneren des Fortbewegungsmittels über automatisch öffnende Türen oder Scheiben gewährt wird. Dies ist allerdings je nach gewünschtem Service zwingend erforderlich. Weiterhin ist es bei dieser Schnittstelle nicht möglich, Zugriff auf elektronische Systeme des Fortbewegungsmittels geltend zu machen. Die Diagnoseschnittstelle ist nicht ohne Zusatzmittel drahtlos erreichbar und erlaubt ohne Erweiterung keine dedizierte, anwendungsbezogene Kommunikation mit einem Roboter.
DE 10 2019 008 060 A1 beschreibt Verfahren zum Durchführen eines elektrischen Ladevorgangs eines elektrischen Energiespeichers eines elektrisch betriebenen Fahrzeugs, wobei ein Ladewunsch mit einem Kommunikationsendgerät oder mit einem Infotainmentsystem des elektrisch betriebenen Fahrzeugs an ein Steuergerät des elektrisch betriebenen Fahrzeugs übermittelt wird. Ein Steuersignal wird in Abhängigkeit des übermittelten Ladewunsches durch das Steuergerät generiert, und das generierte Steuersignal wird mit dem Steuergerät über einen Kommunikationsbus an einen fahrzeugseitigen Ladeanschluss des elektrisch betriebenen Fahrzeugs und an eine Haupteinheit des Infotainmentsystems übermittelt. Das Steuersignal wird über ein lokales Funknetzwerk der Haupteinheit des Infotainmentsystems an eine Ladevorrichtung übermittelt, wobei in Abhängigkeit des übermittelten Steuersignals an den fahrzeugseitigen Ladeanschluss und an die Ladevorrichtung ein automatischer Steckkontakt eines Ladesteckers der Ladevorrichtung mit dem fahrzeugseitigen Ladeanschluss durchgeführt wird.
DE 10 2016221 488 A1 beschreibt ein Verfahren zum autonomen Betrieb eines Kraftfahrzeugs, welches zumindest teilweise elektrisch betreibbar ist, Das Verfahren ist nach einem Ladevorgang eines elektrischen Energiespeichers des Kraftfahrzeugs vorgesehen und kann dann durch eine Steuervorrichtung des Kraftfahrzeugs durchgeführt werden. Die Steuervorrichtung erfasst zunächst eine Beendigung des Ladevorgangs des Kraftfahrzeugs. In einem nächsten Schritt erfasst die Steuervorrichtung eine Entkoppelung des Kraftfahrzeugs von der Ladeinfrastruktur, beispielsweise ein Signal der Ladeinfrastruktur zur Freigabe zur Abfahrt. Nach Erfassen der Entkoppelung des Kraftfahrzeugs erfolgt eine autonome Abfahrt des Kraftfahrzeugs. Die Steuervorrichtung parkt das Kraftfahrzeug autonom innerhalb eines Übernahmebereichs für das Kraftfahrzeug.
DE 10 2016 004 889 A1 beschreibt ein Verfahren zur Zufuhr von elektrischer Energie oder Kraftstoff zu einem Kraftfahrzeug mittels eines Roboters einer Tankstelle. Bei dem Verfahren werden mittels eines Tiefensensors ein Typs oder mehrere zeitlich aufeinanderfolgende Positionen des Kraftfahrzeugs relativ zum Roboter ermittelt. Eine durch den Roboter geführte Schnittstelle wird mit dem Kraftfahrzeug verbunden und elektrische Energie oder Kraftstoff wird dem Kraftfahrzeug über diese Schnittstelle zugeführt. In Abhängigkeit von den ermittelten Positionen können dabei Navigationsdaten an das Kraftfahrzeug übermittelt werden.
DE 10 2014226 357 A1 beschreibt ein Verfahren zum automatischen Aufladen eines elektrischen Energiespeichers in einem Fahrzeug. Hierzu wird zunächst basierend auf fahrzeugspezifischen Daten die Position einer Ladebuchse an einem Fahrzeug ermittelt. Anschließend fährt ein Laderoboter auf dem Boden in die Nähe der Ladebuchse. Daraufhin stellt der Laderoboter eine galvanische Verbindung zwischen Ladestation und Ladebuchse her. Hierzu führt der Laderoboter einen mit der Ladestation verbundenen Kontaktkopf in die Ladebuchse des Fahrzeuges ein. Nach Abschluss des Ladevorgangs wird der Kontaktkopf aus der Ladebuchse herausgezogen und somit das Fahrzeug freigegeben.
US 10,504,094 B1 beschreibt Lösungen für die Verwendung eines Fahrzeugs als Zahlungsmittel, so dass ein Nutzer bei der Bezahlung von Waren und Dienstleistungen im Fahrzeug bleiben kann. In einem Infotainmentsystem des Fahrzeugs ist eine Anwendung gespeichert, die Daten speichert, die Finanzkarten für Zahlungen repräsentieren. Um eine der gespeicherten Finanzkarten für eine Zahlung abzurufen, kann der Nutzer am Infotainmentsystem eine Angabe zu einer Finanzkarte auswählen. Als Reaktion auf die Auswahl überträgt das Infotainmentsystem die ausgewählten Daten über eine Kurzstrecken- Kommunikationsverbindung an ein POS-Terminal. Das POS-Terminal kann dann die Zahlung anhand der übertragenen Daten abwickeln und eine elektronische Quittung übermitteln, die auf dem Infotainmentsystem angezeigt wird.
In Hinblick auf das automatische Laden von Elektrofahrzeugen ist bereits die Idee einer dafür geeigneten Kommunikationsschnittstelle aufgekommen. Die vorgesehene Kommunikationsschnittstelle ist allerdings ausschließlich für diesen einen Anwendungsfall gedacht.
Es ist eine Aufgabe der Erfindung, verbesserte Lösungen für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel bereitzustellen.
Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 1 , durch ein Computerprogramm mit Instruktionen gemäß Anspruch 11, durch eine Vorrichtung mit den Merkmalen des Anspruchs 12, durch eine Kommunikationsschnittstelle gemäß Anspruch 13, durch ein Fortbewegungsmittel gemäß Anspruch 14 sowie durch einen Roboter gemäß Anspruch 15 gelöst. Bevorzugte Ausgestaltungen der Erfindung sind Gegenstand der abhängigen Ansprüche.
Gemäß einem ersten Aspekt der Erfindung umfasst ein Verfahren für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel die Schritte:
- Herstellen einer authentischen Verbindung zwischen dem Roboter und dem Fortbewegungsmittel;
- Aushandeln von Bedingungen und Zuständen für eine vom Roboter durchzuführende Maßnahme;
- Beauftragen der vom Roboter durchzuführende Maßnahme; und
- Auslösen zumindest einer Aktion, die von einer Komponente des Fortbewegungsmittels auszuführen ist, durch den Roboter, wobei die zumindest eine Aktion auf einem Applikationsprotokoll basiert.
Gemäß einem weiteren Aspekt der Erfindung umfasst ein Computerprogramm Instruktionen, die bei Ausführung durch einen Computer den Computer zur Ausführung der folgenden Schritte für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel veranlassen:
- Herstellen einer authentischen Verbindung zwischen dem Roboter und dem Fortbewegungsmittel;
- Aushandeln von Bedingungen und Zuständen für eine vom Roboter durchzuführende Maßnahme;
- Beauftragen der vom Roboter durchzuführende Maßnahme; und
- Auslösen zumindest einer Aktion, die von einer Komponente des Fortbewegungsmittels auszuführen ist, durch den Roboter, wobei die zumindest eine Aktion auf einem Applikationsprotokoll basiert. Der Begriff Computer ist dabei breit zu verstehen. Insbesondere umfasst er auch Steuergeräte, eingebettete Systeme und andere prozessorbasierte Datenverarbeitungsvorrichtungen.
Das Computerprogramm kann beispielsweise für einen elektronischen Abruf bereitgestellt werden oder auf einem computerlesbaren Speichermedium gespeichert sein.
Gemäß einem weiteren Aspekt der Erfindung weist eine Vorrichtung für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel auf:
- ein Verbindungsmodul zum Herstellen einer authentischen Verbindung zwischen dem Roboter und dem Fortbewegungsmittel;
- ein Kommunikationsmodul zum Aushandeln von Bedingungen und Zuständen für eine vom Roboter durchzuführende Maßnahme und zum Beauftragen der vom Roboter durchzuführende Maßnahme; und
- ein Steuerungsmodul zum Auslösen zumindest einer Aktion, die von einer Komponente des Fortbewegungsmittels auszuführen ist, durch den Roboter, wobei die zumindest eine Aktion auf einem Applikationsprotokoll basiert.
Gemäß einem weiteren Aspekt der Erfindung ist eine Kommunikationsschnittstelle für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel eingerichtet:
- Applikationsprotokolle für mit dem Fortbewegungsmittel kompatible Anwendungen zu empfangen;
- eine authentische Verbindung zwischen dem Roboter und dem Fortbewegungsmittel herzustellen;
- Bedingungen und Zustände für eine vom Roboter durchzuführende Maßnahme auszuhandeln und die vom Roboter durchzuführende Maßnahme zu beauftragen; und
- durch den Roboter zumindest eine Aktion, die von einer Komponente des Fortbewegungsmittels auszuführen ist, auszulösen, wobei die zumindest eine Aktion auf einem Applikationsprotokoll basiert.
Bei der erfindungsgemäßen Lösung ist eine universelle Kommunikationsschnittstelle vorgesehen, mit der die Kommunikation für jeden automatisierten Service über unterschiedliche Roboter gewährleistet werden kann. Die Kommunikationsschnittstelle kann sowohl für bekannte als auch für noch unbekannte Anwendungen verwendet werden, welche neben Informationen über das Fortbewegungsmittel bzw. die Zustände des Fortbewegungsmittels auch Interaktionen zwischen dem Fortbewegungsmittel und einem Roboter oder anderer Infrastruktur erfordern, gegebenenfalls auch Interaktionen mit Personen, falls einzelne erforderliche Aktionen oder Zustände nicht automatisiert durchgeführt beziehungsweise hergestellt werden können. Die erfindungsgemäße Lösung hat dabei den Vorteil, dass nicht für jeden Anwendungsfall einer automatisierten Dienstleistung ein neuer Kommunikationsstandard erforderlich ist, welcher über mehrere Jahre abgestimmt und einzeln ins Fortbewegungsmittel integriert werden muss.
Gemäß einem Aspekt der Erfindung werden Applikationsprotokolle für mit dem Fortbewegungsmittel kompatible Anwendungen durch das Fortbewegungsmittel oder den Roboter von einem Backend eines Herstellers des Fortbewegungsmittels oder eines Dienstleisters empfangen. Ist der Prozess für eine neue Anwendung beschrieben und freigegeben, wird der Prozess in Form eines Applikationsprotokolls an das Fortbewegungsmittel oder an den Roboter übertragen. Dies kann z.B. mittels einer Mobilfunkverbindung über ein Backend erfolgen. Die in dem Applikationsprotokoll definierte Anwendung kann dann zusammen mit den externen Robotern oder weiteren Infrastrukturmitteln automatisch durchgeführt werden, gegebenenfalls unterstützt durch Personen, die einzelne Aktionen manuell durchführen.
Gemäß einem Aspekt der Erfindung beinhalten die Applikationsprotokolle Prozessschritte mit Zustandsbedingungen, zustandsändernden Aktionen oder Interaktionen. Beispielsweise können die Aktionen und eine Betätigung von Stellantrieben, ein Ein- oder Ausschalten von Licht, Anzeigeelementen oder anderen Systemen, ein Stellen des Leerlaufs oder eine Bewegung in eine Zielpose beinhalten. Dies erlaubt es, während der Abarbeitung eines Prozesses sicherzustellen, dass sich das Fortbewegungsmittel stets in einem zum jeweiligen Prozessschritt erforderlichen Zustand befindet.
Gemäß einem Aspekt der Erfindung sind für Aktionen Vertrauensstufen vorgegeben. Um dem weiter oben angeführten universellen Anwendungsanspruch gerecht zu werden, ist es sinnvoll, dass den vielfältigen und hohen Anforderungen an die Vertrauensbeziehungen zwischen Robotern und Fortbewegungsmitteln Rechnung getragen wird. Durch die Verwendung von Vertrauensstufen wird dabei erreicht, dass als kritisch erachtete Aktionen nur durchgeführt werden können, wenn eine ausreichend gute Vertrauensbeziehungen aufgebaut wurde.
Gemäß einem Aspekt der Erfindung können Aktionen durch den Roboter abgebrochen werden. Dies ist insbesondere dann vorteilhaft, wenn Personen im Umfeld des Fortbewegungsmittels gefährdet werden könnten oder eine Beschädigung des Fortbewegungsmittels oder des Roboters droht. Gemäß einem Aspekt der Erfindung werden zwischen dem Fortbewegungsmittel und dem Roboter Zustände oder Sensordaten ausgetauscht. Beispielsweise kann der Roboter dem Fortbewegungsmittel Umfeldinformationen liefern, die das Fortbewegungsmittel z.B. aufgrund fehlender Sensorik nicht selbst erfassen kann. Dies erlaubt es, auch in Abwesenheit eines Fahrers Sicherheitsbedingungen einzuhalten. Die Sensoren des Fortbewegungsmittels, z.B. Sensoren für die Innenraumüberwachung, können wiederum zur Absicherung des Robotervorgangs genutzt werden.
Gemäß einem Aspekt der Erfindung ist die authentische Verbindung eine zweikanalige Verbindung. Eine zweikanalige Verbindung ist besonders vorteilhaft für eine wechselseitig authentifizierte Verbindung zwischen Roboter und Fortbewegungsmittel.
Gemäß einem Aspekt der Erfindung wird die authentische Verbindung basierend auf einer Public-Key-Infrastruktur hergestellt. Durch die Verwendung einer Public-Key-Infrastruktur kann auf einfache Weise sichergestellt werden, dass die Kommunikation zwischen Roboter und Fortbewegungsmittel wechselseitig durch Zertifikate authentifiziert erfolgt.
Gemäß einem Aspekt der Erfindung erfolgt eine Initialisierung des Roboters durch einen Hersteller des Fortbewegungsmittels oder einen Dienstleister, bei der ein symmetrischer Schlüssel für eine durch eine Komponente des Fortbewegungsmittels auszuführende Aktionen an den Roboter übermittelt wird. Im Backend des Herstellers oder eines vom Hersteller beauftragten Dienstleisters liegen die diversen symmetrischen Schlüssel vor, die im jeweiligen Fortbewegungsmittel genutzt werden. Bei der Initialisierung werden die Schlüssel, die für den konkreten Prozess erforderlich sind, an den Roboter übermittelt. Der Roboter stellt dazu zunächst eine Vertrauensbeziehung zum Backend her, z.B. unter Verwendung eines Geheimnisses, das im Rahmen der Roboterproduktion eingespielt wurde.
Gemäß einem Aspekt der Erfindung wird der symmetrische Schlüssel verwendet, um eine als kritisch definierte Aktion authentisiert auszulösen. Die Bauteile in der Aktorik von Fortbewegungsmitteln sind oftmals eingebettete Systeme, die bezüglich des Einsatzes von Kryptographie einigen Einschränkungen unterliegen. So sind die rechen- und speicherintensiven asymmetrischen Algorithmen hier oft nicht einsetzbar, die normalerweise mit Hilfe einer Public-Key-Infrastruktur Vertrauensbeziehungen authentisch nachweisen. Dies bedeutet, dass diese kritischen Bauteile höherer Vertrauensstufen (z.B. Trust-Level 2) regelmäßig mit symmetrischen Schlüsseln abgesichert werden. Die im Rahmen einer Initialisierung übertragenen symmetrischen Schlüssel ermöglichen es daher, zwischen dem Roboter und besonderen, technisch eingeschränkten aber inhaltlich hochkritischen Systemen des Fortbewegungsmittels eine authentische, freigegebene Verbindung zu realisieren. Ein Beispiel eines inhaltlich hochkritischen Systems ist das Bremsensteuergerät eines Kraftfahrzeugs.
Gemäß einem Aspekt der Erfindung wird ein Vertrauensverhältnis zwischen dem Fortbewegungsmittel und einer Menge von Robotern hergestellt. Je nach Anwendungsfall kann es erforderlich sein, dass mehrere Roboter zusammen am Fortbewegungsmittel arbeiten. Dies können individuelle Roboter sein, z.B. ein Laderoboter und ein Transportroboter, aber auch Robotermodule, die sich zu einem Roboter verbinden. Indem das Vertrauensverhältnis auf eine Menge von Robotern erweitert wird, muss nicht für jeden Roboter bzw. jedes Robotermodul individuell ein Vertrauensverhältnis hergestellt werden. Beispiele für Roboter oder Robotermodule, die Zusammenarbeiten können, sind ein Sondergreifarm zum Tanken, Transportroboter, Hebebühnenroboter, Reinigungsroboter, ein dünner Greifarm für Eingriffe in den Motorraum oder ein Schnittstellengreifarm für einen Zugriff auf eine Diagnoseschnittstelle.
Besonders vorteilhaft wird eine erfindungsgemäße Lösung in einem Fortbewegungsmittel oder in einem Roboter eingesetzt. Bei dem Fortbewegungsmittel kann es sich beispielsweise um ein Kraftfahrzeug handeln, z.B. einen Personenkraftwagen oder ein Nutzfahrzeug. Die Nutzung der erfindungsgemäßen Lösung hat dabei den Vorteil, dass das Fortbewegungsmittel in die Lage versetzt wird, automatische Dienstleistungen in Anspruch zu nehmen. Anwendungen rund um das Fahrzeug lassen sich ohne Anwesenheit des Fahrers bzw. des Fahrzeugschlüssels durchführen und automatisieren. Somit lassen sich neue Geschäftsmodelle realisieren.
Weitere Merkmale der vorliegenden Erfindung werden aus der nachfolgenden Beschreibung und den angehängten Ansprüchen in Verbindung mit den Figuren ersichtlich.
Fig. 1 zeigt schematisch ein Verfahren für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel;
Fig. 2 zeigt eine erste Ausführungsform einer Vorrichtung für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel;
Fig. 3 zeigt eine zweite Ausführungsform einer Vorrichtung für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel; Fig. 4 stellt schematisch ein Fortbewegungsmittel dar, in dem eine erfindungsgemäße Lösung realisiert ist;
Fig. 5 stellt schematisch einen Roboter dar, in dem eine erfindungsgemäße Lösung realisiert ist;
Fig. 6 zeigt schematisch ein Systemdiagramm einer erfindungsgemäßen Lösung; und
Fig. 7 zeigt bespielhaft einen Kommunikationsablauf im Rahmen einer automatischen
Dienstleistung.
Zum besseren Verständnis der Prinzipien der vorliegenden Erfindung werden nachfolgend Ausführungsformen der Erfindung anhand der Figuren detaillierter erläutert. Es versteht sich, dass sich die Erfindung nicht auf diese Ausführungsformen beschränkt und dass die beschriebenen Merkmale auch kombiniert oder modifiziert werden können, ohne den Schutzbereich der Erfindung zu verlassen, wie er in den angehängten Ansprüchen definiert ist.
Fig. 1 zeigt schematisch ein Verfahren für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel. In einem ersten Schritt werden Applikationsprotokolle für mit dem Fortbewegungsmittel kompatible Anwendungen durch das Fortbewegungsmittel oder den Roboter empfangen werden 10. Die Applikationsprotokolle können z.B. über ein Backend 60 eines Herstellers des Fortbewegungsmittels oder eines Dienstleisters bereitgestellt werden und können Prozessschritte mit Zustandsbedingungen, zustandsändernden Aktionen oder Interaktionen beinhalten. Für die Aktionen können dabei Vertrauensstufen vorgegeben sein. Bei Bedarf erfolgt eine Initialisierung 11 des Roboters durch einen Hersteller des Fortbewegungsmittels oder einen Dienstleister. Bei der Initialisierung 11 wird ein symmetrischer Schlüssel für eine durch eine Komponente des Fortbewegungsmittels auszuführende Aktionen an den Roboter übermittelt. Nun wird eine authentische Verbindung zwischen dem Roboter und dem Fortbewegungsmittel hergestellt 12 und es werden Bedingungen und Zustände für eine vom Roboter durchzuführende Maßnahme ausgehandelt 13. Die authentische Verbindung kann insbesondere eine zweikanalige Verbindung sein. Als Abschluss des Aushandelns 13 wird die vom Roboter durchzuführende Maßnahme beauftragt 14. Bei der Abarbeitung der durchzuführenden Maßnahme wird durch den Roboter, basierend auf einem Applikationsprotokoll, zumindest eine Aktion ausgelöst 15, die von einer Komponente des Fortbewegungsmittels ausgeführt werden muss. Dazu kann der zuvor übermittelte symmetrische Schlüssel erforderlich sein, z.B. falls die Aktion als kritisch definiert ist. Bei Bedarf können während der Abarbeitung der durchzuführenden Maßnahme Zustände oder Sensordaten zwischen dem Fortbewegungsmittel und dem Roboter ausgetauscht werden 16. Falls dies erforderlich werden sollte, kann die Aktion durch den Roboter wieder abgebrochen werden.
Fig. 2 zeigt eine vereinfachte schematische Darstellung einer ersten Ausführungsform einer Vorrichtung 20 für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel. Die Vorrichtung 20 hat eine Schnittstelle 21 , über die Daten D zwischen dem Roboter und dem Fortbewegungsmittel ausgetauscht werden können. Über die Schnittstelle können zudem Applikationsprotokolle AP für mit dem Fortbewegungsmittel kompatible Anwendungen empfangen werden, z.B. von einem Backend 60 eines Herstellers des Fortbewegungsmittels oder eines Dienstleisters. Die Applikationsprotokolle AP können insbesondere Prozessschritte mit Zustandsbedingungen, zustandsändernden Aktionen oder Interaktionen beinhalten. Für die Aktionen können dabei Vertrauensstufen vorgegeben sein. Ein Verbindungsmodul 22 ist dazu eingerichtet, eine authentische Verbindung zwischen dem Roboter und dem Fortbewegungsmittel herzustellen. Die authentische Verbindung kann insbesondere eine zweikanalige Verbindung sein. Ein Kommunikationsmodul 23 ist dazu eingerichtet, Bedingungen und Zustände für eine vom Roboter durchzuführende Maßnahme auszuhandeln und die vom Roboter durchzuführende Maßnahme zu beauftragen. Ein Steuerungsmodul 24 ist dazu eingerichtet, im Ansprechen auf einen entsprechenden Befehl durch den Roboter zumindest eine Aktion auszulösen, die von einer Komponente 42 des Fortbewegungsmittels auszuführen ist. Die Aktion basiert dabei auf einem Applikationsprotokoll AP. Zu diesem Zweck kann das Steuerungsmodul 24 beispielsweise entsprechende Steuerbefehle S über einen Ausgang 27 der Vorrichtung 20 an die betroffene Komponente 42 ausgeben. Bei Bedarf können während der Abarbeitung der durchzuführenden Maßnahme über die Schnittstelle 21 Zustände oder Sensordaten zwischen dem Fortbewegungsmittel und dem Roboter ausgetauscht werden. Falls dies erforderlich werden sollte, kann die Aktion durch den Roboter mittels eines entsprechenden Befehls wieder abgebrochen werden. Für das Auslösen der Aktion kann ein symmetrischer Schlüssel erforderlich sein, z.B. falls die Aktion als kritisch definiert ist. Der Schlüssel kann dazu zuvor im Rahmen einer Initialisierung des Roboters durch einen Hersteller des Fortbewegungsmittels oder einen Dienstleister an den Roboter übermittelt werden.
Das Verbindungsmodul 22, das Kommunikationsmodul 23 und das Steuerungsmodul 24 können von einem Kontrollmodul 25 gesteuert werden. Über eine Benutzerschnittstelle 28 können gegebenenfalls Einstellungen des Verbindungsmoduls 22, des Kommunikationsmoduls 23, des Steuerungsmoduls 24 oder des Kontrollmoduls 25 geändert werden. Die in der Vorrichtung 20 anfallenden Daten können bei Bedarf in einem Speicher 26 abgelegt werden, beispielsweise für eine spätere Auswertung oder für eine Nutzung durch die Komponenten der Vorrichtung 20. Das Verbindungsmodul 22, das Kommunikationsmodul 23, das Steuerungsmodul 24 sowie das Kontrollmodul 25 können als dedizierte Hardware realisiert sein, beispielsweise als integrierte Schaltungen. Natürlich können sie aber auch teilweise oder vollständig kombiniert oder als Software implementiert werden, die auf einem geeigneten Prozessor läuft, beispielsweise auf einer GPU oder einer CPU. Die Schnittstelle 21 und der Ausgang 27 können als getrennte Schnittstellen oder als eine kombinierte bidirektionale Schnittstelle implementiert sein.
Fig. 3 zeigt eine vereinfachte schematische Darstellung einer zweiten Ausführungsform einer Vorrichtung für eine Kommunikation zwischen einem Roboter und einem Fortbewegungsmittel. Die Vorrichtung 30 weist einen Prozessor 32 und einen Speicher 31 auf. Beispielsweise handelt es sich bei der Vorrichtung 30 um einen Computer oder ein Steuergerät. Im Speicher 31 sind Instruktionen abgelegt, die die Vorrichtung 30 bei Ausführung durch den Prozessor 32 veranlassen, die Schritte gemäß einem der beschriebenen Verfahren auszuführen. Die im Speicher 31 abgelegten Instruktionen verkörpern somit ein durch den Prozessor 32 ausführbares Programm, welches das erfindungsgemäße Verfahren realisiert. Die Vorrichtung 30 hat einen Eingang 33 zum Empfangen von Informationen, beispielsweise von Informationen zu Bedienhandlungen eines Nutzers der Maschine. Vom Prozessor 32 generierte Daten werden über einen Ausgang 34 bereitgestellt. Darüber hinaus können sie im Speicher 31 abgelegt werden. Der Eingang 33 und der Ausgang 34 können zu einer bidirektionalen Schnittstelle zusammengefasst sein.
Der Prozessor 32 kann eine oder mehrere Prozessoreinheiten umfassen, beispielsweise Mikroprozessoren, digitale Signalprozessoren oder Kombinationen daraus.
Die Speicher 26, 31 der beschriebenen Ausführungsformen können sowohl volatile als auch nichtvolatile Speicherbereiche aufweisen und unterschiedlichste Speichergeräte und Speichermedien umfassen, beispielsweise Festplatten, optische Speichermedien oder Halbleiterspeicher.
Nachfolgend wird eine Ausführungsform einer erfindungsgemäßen Lösung anhand von Fig. 4 bis Fig. 7 beschrieben. Fig. 4 stellt schematisch ein Fortbewegungsmittel 40 dar, in dem eine erfindungsgemäße Lösung realisiert ist. Bei dem Fortbewegungsmittel 40 handelt es sich in diesem Beispiel um ein Kraftfahrzeug. Das Kraftfahrzeug weist eine Kommunikationsschnittstelle 41 auf, die in diesem Fall beispielhaft eine erfindungsgemäße Vorrichtung 20 für eine Kommunikation zwischen dem Kraftfahrzeug und einem Roboter beinhaltet. Das Fortbewegungsmittel 40 ist eingerichtet, im Zusammenspiel mit einem Roboter automatische Dienstleistungen in Anspruch zu nehmen. Im Rahmen der Durchführung einer solchen automatischen Dienstleistung kann es erforderlich sein, dass Komponenten 42 des Fortbewegungsmittels im Ansprechen auf entsprechende Anweisungen des Roboters Aktionen ausführen. Bei den Komponenten 42 kann es sich beispielsweise um Stellantriebe handeln, z.B. für das Öffnen oder Schließen von Türen, Heckklappe oder Ladeklappe oder für das Heben oder Senken der Scheiben. Es kann sich darüber hinaus aber auch um Steuergeräte handeln, z.B. ein Bremsensteuergerät oder ein Lenkungssteuergerät, die gegebenenfalls von einem automatisierten Fahrsystem 44 Anweisungen erhalten. Über eine Nutzerschnittstelle 43 kann eine Interaktion mit einem Bediener des Kraftfahrzeugs erfolgen. Z.B. kann auf diese Weise eine Aufforderung an den Bediener ergehen, vorbereitend für eine automatische Dienstleistung bestimmte Handlungen durchzuführen, weil beispielsweise das Kraftfahrzeug diese nicht selbsttätig vornehmen kann. Weitere Komponenten des Kraftfahrzeugs sind eine Sensorik 45 zum Erfassen von Umgebungsinformationen oder Zustandsdaten des Kraftfahrzeugs sowie eine Datenübertragungseinheit 46. Die Sensorik 45 kann z.B. Kameras, Radarsensoren, Lidarsensoren oder Ultraschallsensoren umfassen. Mittels der Datenübertragungseinheit 46 können Verbindungen zu einem Roboter und zu einem Backend aufgebaut werden, z.B. zum Austausch von Daten oder zum Empfangen von Applikationsprotokollen. Zur Speicherung von Daten ist ein Speicher 47 vorhanden. Der Speicher 47 kann auch Bestandteil der Kommunikationsschnittstelle 41 oder einer anderen Komponente des Kraftfahrzeugs sein. Der Datenaustausch zwischen den verschiedenen Komponenten des Kraftfahrzeugs erfolgt über ein Netzwerk 48.
Fig. 5 stellt schematisch einen Roboter 50 dar, in dem eine erfindungsgemäße Lösung realisiert ist. Der Roboter 50 ist eingerichtet, im Zusammenspiel mit einem Fortbewegungsmittel automatische Dienstleistungen durchzuführen. Der Roboter 50 weist eine Kommunikationsschnittstelle 51 auf, die Verbindungen zu einem Fortbewegungsmittel und zu einem Backend ermöglicht. Vom Backend kann der Roboter 50 z.B. Applikationsprotokolle empfangen, die Prozessschritte mit Zustandsbedingungen, zustandsändernden Aktionen oder Interaktionen für eine automatische Dienstleistung beinhalten. Zudem kann das Backend, falls erforderlich, Schlüssel für bestimmte, im Rahmen einer automatischen Dienstleistung durchzuführende Aktionen übermitteln. Empfangene Daten können bei Bedarf in einem Speicher 52 des Roboters 50 abgelegt werden. In Fig. 5 ist der Speicher 52 Bestandteil des Roboters 50, er kann aber auch lediglich über eine Datenverbindung an den Roboter 50 angebunden sein.
Fig. 6 zeigt schematisch ein Systemdiagramm einer erfindungsgemäßen Lösung. Das System umfasst neben einem Fortbewegungsmittel 40, an dem eine automatische Dienstleistung durchgeführt werden soll, und zumindest einem Roboter 50, der die automatische Dienstleistung durchführt, ein Backend 60 eines Herstellers des Fortbewegungsmittels 40 oder eines Dienstleisters. Zudem können weitere Roboter 50‘ an der automatischen Dienstleistung beteiligt sein. Das Fortbewegungsmittel 40 weist eine erfindungsgemäße Kommunikationsschnittstelle 41 auf, über die es unter Verwendung einer Datenübertragungseinheit 46 mit dem Roboter 50 kommuniziert. Auch eine Kommunikation mit weiteren Infrastruktureinrichtungen oder Smart Devices ist auf diese Weise möglich. Vorzugsweise wird eine drahtlose Kommunikationstechnologie genutzt, wie WLAN oder Bluetooth. Die Datenübertragungseinheit 46 ermöglicht zudem eine Kommunikation zwischen dem Fortbewegungsmittel 40 und dem Backend 60, z.B. mittels einer Mobilfunkverbindung. Zu diesem Zweck weist auch das Backend 60 eine Kommunikationsschnittstelle 61 auf. Vom Backend 60 können Applikationsprotokolle AP bereitgestellt und an das Fortbewegungsmittel 40 übertragen werden, nachdem die entsprechenden Prozesse für neue Anwendungen beschrieben und freigegeben wurden. Die Applikationsprotokolle AP können beispielsweise in einem Speicher 62 des Backends 60 abgelegt sein. Je nach gewählter Implementierung kann das Backend 60 auch als Schnittstelle zum Kunden dienen, z.B. für die Buchung oder Abrechnung von
Dienstleistungen. Bei Bedarf kann des Weiteren eine Kommunikation zwischen dem Roboter 50 und dem Backend 60 erfolgen. Beispielsweise können vom Backend 60 auch an den Roboter 50 Applikationsprotokolle AP übertragen werden. Ebenso können vom Roboter 50 Informationen zu seinem Zustand, d.h. zu eventuellen Fehlern oder zur Verfügbarkeit, an das Backend 60 übertragen werden, gegebenenfalls im Ansprechen auf eine entsprechende Anfrage durch das Backend 60.
Die Kommunikationsschnittstelle 41 des Fortbewegungsmittels 40 weist einen Datenspeicher zur Ablage der aktuell gültigen Applikationsprotokolle AP für mit dem Fortbewegungsmittel 40 kompatiblen Anwendungen auf. Zudem stellt sie Authentifizierungsschlüssel für eine fahrzeug-externe Kommunikation bereit und setzt eine Logiksteuerung in Abhängigkeit des angeforderten Applikationsprotokolls AP um. Diese Logiksteuerung nutzt sowohl fahrzeuginterne als auch fahrzeug-externe Eingangsgrößen. Beispiele für fahrzeug-interne Eingangsgrößen sind Fahrzeugzustände, Endlagen, Sensorik-Daten oder Dateninterpretationen. Beispiele für fahrzeug-externe Eingangsgrößen sind Befehle oder Zustandsvorgaben vom Roboter 50, weiteren Infrastruktureinrichtungen oder Smart Devices, sowie Typ, Anforderungen und Verfügbarkeit der Applikationen.
Ausgangsgrößen der Logiksteuerung lassen sich unterteilen in fahrzeug-interne und fahrzeug-externe Ausgangsgrößen sowie automatische Fahraktionen. Beispiele für fahrzeuginterne Ausgangsgrößen sind in erster Linie Betätigungen von Stellgliedern, wie z.B. die Antriebe von Scheiben oder Klappen, sowie das Ein- oder Ausschalten von Licht, Anzeigeelementen, Klimaanlage etc. Beispiele für fahrzeug-externe Ausgangsgrößen sind Informationen zum Fortbewegungsmittel 40, z.B. die fahrzeug-internen Eingangsgrößen oder konstante Fahrzeugparameter wie die Maße, sowie für die Buchung und Zahlung von Dienstleistungen benötigten Informationen. Zudem können Fehlerspeichereinträge und Diagnose-Daten, gegebenenfalls vollständige UDS-Daten (UDS: Unified Diagnostic Services; Vereinheitlichte Diagnosedienste) ausgegeben werden. Ein Beispiel für eine automatische Fahraktion ist das Fahren zu einer Zielpose, d.h. eine vorgegebene Position und Orientierung.
Weitere Eingangs- und Ausganggrößen der Logiksteuerung betreffen das Herstellen einer Vertrauensbeziehung. Lediglich exemplarisch seien hier genannt die Vertrauensstufen der Aktionen sowie Angaben zu den verwendeten Sicherheitsprotokollen. Für jede kryptographische Anwendung kann eine Auswahl der folgenden Elemente verfügbar sein: Kryptographieparameter, wie z.B. Algorithmus, Schlüssel oder Parameter, spezifische Schlüsselinformation, wie z.B. Schlüssel-ID, Sendergeräte-Zähler, Sender-Zähler, Empfängergeräte-Zähler, Empfänger-Zähler, Roboter-Identifikationsnummer, Fahrzeug- Identifikationsnummer, Sait oder Zeitstempel, Zähler, Challenge oder Signatur. Welche Elemente konkret genutzt werden liegt im Ermessen des Fachmanns.
Nachfolgend wird die Nutzung einer erfindungsgemäßen Lösung beispielhaft anhand eines konkreten Anwendungsfalls beschrieben. Es handelt sich dabei um eine Inspektion eines Kraftfahrzeugs, bei der auch einer Räderprüfung vorgenommen werden soll. Dies macht das Bewegen des Kraftfahrzeugs erforderlich, wozu die Bremse gelöst, der Gang herausgenommen und das Kraftfahrzeug bewegt werden muss. Danach muss die Bremse wieder festgestellt und das Getriebe auf Parken gestellt werden. Angenommen wird hier, dass das Kraftfahrzeug keine vollautomatische Valet-Parkfunktion hat. Das Kraftfahrzeug verfügt allerdings über einen Park-Lenk-Assistenten, d.h. eine Beeinflussung von Beschleunigung, Bremse und Lenkung ist möglich, aber es ist eigentlich ein Fahrer zur Überwachung der Verkehrssituation erforderlich. Da die Dienstleistung automatisch erfolgen soll und somit kein Fahrer eingreifen kann, bewegt sich die Kommunikation außerhalb klassischer Status des Kraftfahrzeugs. Daher ist eine besondere Authentifizierung der Aktion gegenüber jedem Teilnehmer, d.h. gegenüber jedem beteiligten Steuergerät im Kraftfahrzeug notwendig.
Herausforderungen bestehen somit darin, dass eine Berechnung und Übermittlung der erforderlichen Bewegung des Kraftfahrzeugs unter Berücksichtigung der Infrastruktur, wie z.B. statische Hindernisse, erfolgen muss. Zudem muss der Gefährdungsbereich überwacht werden, d.h. ein Sicherheitsabstand x um das Kraftfahrzeug sowie ein Sicherheitsabstand y in Bewegungsrichtung. Des Weiteren muss eine sichere, bevorzugt zweikanalige Verbindung aufgebaut und eine Freigabe für die Bewegung des Kraftfahrzeugs gegeben werden. Während der Bewegung des Kraftfahrzeugs sollte eine Überwachung der Positions- oder Bahnabweichung des Kraftfahrzeugs durch den Roboter oder Infrastruktureinrichtungen erfolgen. Im Gefahrenfall, z.B. bei Annäherung von Personen oder eines anderen Kraftfahrzeugs, sollte ein Not-Halt des Kraftfahrzeugs ausgelöst werden können. Dieser sollte zudem ohne menschlichen Eingriff wieder aufhebbar sein. Schließlich ist eine Dokumentation der fehlerfreien oder auch fehlerbehafteten Bewegung des Kraftfahrzeugs wünschenswert.
Der Ablauf der Fahrbewegung kann nun folgendermaßen erfolgen. Der Roboter berechnet und übermittelt zunächst die erforderliche Bewegung des Kraftfahrzeugs. Zudem kündigt er eine kritische Aktion an. Das Kraftfahrzeug sendet daraufhin eine Bereit-Meldung für die kritische Aktion. Roboter und Kraftfahrzeug starten nunmehr eine sichere, vorzugsweise zweikanalige Kommunikationsverbindung. Der Roboter erteilt eine Freigabe, woraufhin das Kraftfahrzeug die Bremse löst, je nach Bewegungsrichtung in den Fahrmodus (D) oder (R) wechselt und sich auf der vorgegebenen Bahn in Richtung der Soll-Pose bewegt. Bei Gefahr löst der Roboter einen Not-Halt aus. Wenn das Kraftfahrzeug die Soll-Pose erreicht, zieht es die Bremse und wechselt in den Fahrmodus (P). Der Roboter bestätigt das Erreichen der Soll-Pose und einen sicheren Zustand des Kraftfahrzeugs. Anschließend lösen Roboter und Kraftfahrzeug die sichere Kommunikationsverbindung.
Fig. 7 zeigt bespielhaft einen Kommunikationsablauf im Rahmen einer automatischen Dienstleistung. Zwischen einem Fortbewegungsmittel 40 und einem Roboter 50 wurde zuvor Verbindung hergestellt. Die Art der dazu genutzten Luftschnittstelle ist irrelevant. Die Kommunikation wird gegenseitig durch Zertifikate authentifiziert. Das Fortbewegungsmittel 40 sendet S1a Interesse an einer Dienstleistung. Der Roboter 50 sendet S2a daraufhin ein Angebot für die Dienstleistung. Das Angebot umfasst beispielhaft einen Preis für die Dienstleistung sowie eine ID und eine Versionsbezeichnung des Roboters 50. Alternativ können Interessensbekundung und Angebot auch in umgekehrter Reihenfolge erfolgen, dargestellt durch die gestrichelten Pfeile S1b, S2b. Anschließend sendet S3 der Roboter 50 eine Anfrage hinsichtlich der für die Dienstleistungen benötigten Informationen, z.B. der ID und gegebenenfalls der Ausprägung des Fortbewegungsmittels 40, einer spezifischen Ausstattung, Anforderungen für die Dienstleistung, Art der Zahlung, etc. Das Fortbewegungsmittel 40 antwortet S4 auf die Anfrage mit den angefragten Informationen oder einer Ablehnung. Der Roboter 50 übermittelt S5 nun einen möglichen Prozessablauf und das Fortbewegungsmittel 40 bucht S6 die Dienstleistung gegenüber dem Roboter 50. Der Roboter 50 validiert S7a die Buchung und committet sich S7b bezüglich des Angebots. Das Fortbewegungsmittel 40 validiert S8a das Comittment, geht in einen Start-Zustand und sendet S8b eine Bereit-Meldung. Daraufhin erfolgt der Ablauf der eigentlichen Dienstleistung. Der Roboter 50 führt Teil 1 der Dienstleistung durch S9 und sendet S10 anschließend eine Bereit-Meldung. Das Fortbewegungsmittel 40 ändert S11 seinen Zustand für Teil 2 der Dienstleistung und sendet S12 danach eine Bereit-Meldung. Der Roboter 50 führt Teil 2 der Dienstleistung durch S13 und sendet S14 anschließend eine Bereit-Meldung sowie nunmehr auch einen Befehl für eine als kritisch eingestufte Aktion für Teil 3 der Dienstleistung. Beispielsweise kann das Fortbewegungsmittel 40 angewiesen werden, eine bestimmte Strecke vorzufahren. Ein automatisiertes Fahrsystem 44 des Fortbewegungsmittels 40 validiert S15 den Befehl und das Fortbewegungsmittel 40 ändert S16 bei erfolgreicher Validierung seinen Zustand für Teil 3 der Dienstleistung. Anschließend sendet S17 das Fortbewegungsmittel 40 eine Bereit-Meldung. Der Roboter 50 führt nunmehr Teil 3 der Dienstleistung durch S18. Dieser Ablauf setzt sich fort, bis schließlich der letzte Teil der Dienstleistung durchgeführt wird S98 und der Roboter 50 eine Ende-Meldung sendet S99. Das Fortbewegungsmittel antwortet S100 mit einer Ende-Meldung und gibt die Zahlung frei.
Die im Rahmen der Kommunikation zwischen Fortbewegungsmittel und Roboter auszutauschenden Nachrichten können beispielhaft in der Form {Protokollinfo, Beteiligter, Status, Dienstleistung, Business, Sicherheit} realisiert werden. Die konkrete Ausgestaltung liegt dabei im Ermessen des Fachmanns.
Das Element Protokollinfo gibt beispielsweise an, ob es sich um einen Verbindungsaufbau, ein Angebot für eine Dienstleistung, eine Bestätigung, ein Commitment, eine Bereit-Meldung oder eine Ende-Meldung handelt. Das Element Beteiligter beinhaltet z.B. einen Identifikator, Informationen, ob es sich um einen Roboter oder ein Fortbewegungsmittel handelt, den Typ des Roboters oder Fortbewegungsmittels, eine Konfiguration des Roboters oder Fortbewegungsmittels oder zusätzliche Informationen zum Roboter oder zum Fortbewegungsmittel.
Das Element Status beinhaltet z.B. Informationen zu Version, Hardware oder Software von Bestandteilen des Fortbewegungsmittels, Informationen zum letzten erfolgten Update, zum Ladezustand oder zu Schäden. Zudem kann es Informationen beinhalten zur Besetzung des Fortbewegungsmittels oder dazu, ob Türen verriegelt sind, ob Fenster geöffnet sind, ob die Parkbremse aktiviert ist oder welcher Lenkwinkel eingestellt ist. Das Element Status kann alternativ auch im Element Beteiligter enthalten sein.
Das Element Dienstleistung beinhaltet z.B. Informationen zum Angebot oder zur Nachfrage, einen Namen und gegebenenfalls eine Beschreibung der Dienstleistung für den Kunden, Informationen zu Anforderungen an das Fortbewegungsmittel, die Umgebung, die Infrastruktur oder den Roboter, einen generischen Prozessablauf, z.B. im Angebot der Dienstleistung, einen detaillierten Prozessablauf, die benötigte Zeit, oder die einzelnen Aktionen im Detail, wie z.B. Gang herausnehmen, Tür öffnen, Information bereitstellen, etc.
Das Element Business beinhaltet z.B. Informationen zum Preis, zum Budget, einen Voucher eine Zahlungsinformation oder eine Zahlungsbestätigung.
Das Element Sicherheit beinhaltet z.B. Informationen zur Art der kryptographischen Anwendung, wie z.B. Verschlüsseln oder Signieren, zum verwendeten kryptographischen Algorithmus und zur Konfiguration, wie z.B. AES-GCM (Advanced Encryption Standard mit Galois/Counter Mode), MAC SHA2 (Medium Access Control mit Secure Hash Algorithm), Schlüsselinformationen, die abhängig von der kryptographischen Anwendung sein können, wie z.B. Schlüssel-ID, Ableitungsparameter oder Zertifikats-ID, oder kryptographische Bestandteile, wie z.B. Signatur, Hash oder Challenge.
Es kann vorgesehen sein, Sensoren des Fortbewegungsmittels zur Überwachung zur Absicherung des Robotervorgangs einzusetzen, z.B. Sensoren für die Innenraumüberwachung. In diesem Fall ist es vorteilhaft, wenn das verwendete Protokoll zusätzlich auch Felder die Roboterbewegungen oder sogar ein Template der Roboterbewegung pro Applikationsprotokoll vorsieht. Weicht die Sensormessung von der vorgesehenen Bewegung ab, kann die Bewegung gestoppt und ein Eingriff durch eine geeignete Person angefordert werden. Das Template kann beispielsweise unter Verwendung von Algorithmen der künstlichen Intelligenz durch Beobachtungen der Abläufe an Fortbewegungsmitteln erlernt werden.
Bei der erfindungsgemäßen Lösung werden vielfältige Verbindungen und Vertrauensbeziehungen ermöglicht. Zu nennen sind beispielsweise die Verbindung zwischen Roboter und Backend zur Initialisierung per Geheimnis und zur Übertragung spezifischer Schlüssel für das Fortbewegungsmittel, die Verbindung zwischen Roboter und Fortbewegungsmittel, z.B. per Public-Key-Infrastruktur, die Verbindung zwischen Roboter und einer Steuergerät, das eine höhere Vertrauensstufe erfordert, mittels eines symmetrischen Schlüssels, und gegebenenfalls die Verbindung des Backend über den Roboter mit einem solchen Steuergerät für eine Ende-zu-Ende-Verbindung. Darüber hinaus kann eine Verbindung zwischen mehreren Robotern bestehen, die zusammen an einem Fortbewegungsmittel arbeiten. Zudem können mehrere Roboter unterscheidbar mit dem Fortbewegungsmittel verbunden sein. Des Weiteren kann eine Verbindung zwischen mehreren Robotermodulen bestehen, die sich zusammen zu einem anderen Roboter Verbinden, z.B. ein Laderoboter mit einem Transportroboter.
Auch in zukünftigen Fahrzeugarchitekturen sind eingebettete Systeme wie die Bremse und das Getriebe kryptographisch auf symmetrische Algorithmen beschränkt. Zukünftige asymmetrische Algorithmen müssen Post-Quantum sicher sein und werden dafür mit großer Wahrscheinlichkeit viel aufwendiger werden und erheblich längere Schlüssel benötigen, womit sie noch weniger für eingebettete Systeme einsetzbar sein werden. Somit ist eine Authentifizierung der Integrität des Auslösens einer Aktion, die eine höhere Vertrauensstufe erfordert, vom Backend bis zum beteiligten eingebetteten Steuergerät erforderlich. Diese kann dergestalt erfolgen, dass zunächst eine Initialisierung eines Roboters für eine bestimmte Aktion eines Fortbewegungsmittels durch ein Backend erfolgt. Diese kann bereits im Vorfeld erfolgen, z.B. weil das Fortbewegungsmittel für eine Dienstleistung eingeplant wird. Im Rahmen dieser Initialisierung fragt der Roboter zunächst einen für die Aktion erforderlichen Schlüssel an und erhält diesen vom Backend. Der Schlüssel kann dabei auch vom entsprechenden Steuergerät erzeugt worden sein. Nun wird ein allgemeiner, authentischer Kontakt zwischen dem Roboter und dem Fortbewegungsmittel hergestellt, z.B. basierend auf einer Public-Key-Infrastruktur mittels Zertifikat und Public-Key Algorithmus, z.B. ECDSA (Elliptic Curve Digital Signature Algorithm) oder TLS (Transport Layer Security). Über diesen Kanal kann dann die weitere Kommunikation stattfinden. Für das authentische Auslösen der Aktion höherer Vertrauensstufe kann nun der bei der Initialisierung übermittelte Schlüssel verwendet werden. Im Detail kann das Prinzip der Schlüsselverteilung folgendermaßen beschrieben werden. Angenommen wird, dass im Backend die symmetrischen Schlüssel des Fortbewegungsmittels vorliegen. Jeder Schlüssel hat eine ID. Beispielsweise ist K29 ist der Schlüssel mit der ID 29. Ein solcher Schlüssel hat immer die gleichen Eigenschaften und Anwendungsfälle, z.B. die Autorisierung einer Bremsaktion, die eine hohe Vertrauensstufe erfordert. Ein Schlüssel ist immer individuell pro Fortbewegungsmittel. Der Schlüssel des Fortbewegungsmittels mit der Identifikationsnummer VIN zur Bremsaktion ist also K29_VIN. Ein Roboter mit der Roboter-ID ID_R hat zu irgendeinem Zeitpunkt vor der Kommunikation mit dem Fortbewegungsmittel mit der Identifikationsnummer VIN eine Verbindung mit dem Backend. Durch Anwendung einer Hashfunktion lässt sich eine kryptographische Schlüsselableitungen deterministisch durchführen. Aus Schlüssel K wird mit dem Parameter x abgeleitet mit der Notation K(x). Es ergibt sich ein neuer Schlüssel, den nur berechnen kann, wer K kennt. Der Roboter mit der Roboter-ID ID_R fragt nun beim Backend nach dem Schlüssel, mit dem er eine Bremsaktion beim Fortbewegungsmittel mit der Identifikationsnummer VIN durchführen kann. Das Backend berechnet daraufhin K_ID_R_VIN=K29_VIN(ID_R, Sait, Timer). Nun kann der Roboter eine Nachricht an das Fortbewegungsmittel senden mit der auszuführenden Aktion, z.B. „löse die Bremse“, einer Signatur, die aus der Nachricht mit dem Schlüssel K_ID_R_VIN bestimmt wird und zur Authentifizierung des kritischen Befehls es Roboters durch das beteiligte Bremsensteuergerät des Fortbewegungsmittels dient, und den Parametern ID R, Sait, Timer. Damit kann das Bremsensteuergerät im Fortbewegungsmittel, das K29_VIN kennt, K_ID_R_VIN=K29_VIN(ID_R, Sait, Timer) berechnen, also den Schlüssel, der für die Vertrauensbeziehung zwischen dem Bremsensteuergerät und dem Roboter gedacht ist und den auch andere Steuergeräte im Fortbewegungsmittel nicht kennen, und damit die Signatur authentisieren. Somit ist sichergestellt, dass ein autorisierter Roboter den Befehl über die Kommunikationsschnittstelle senden darf. Das Lösen der Bremsen dürfte ein Online- oder Car2Car-Steuergerät andernfalls z.B. niemals auslösen. Nach erfolgreicher Authentisierung führt das Bremsensteuergerät schließlich die geforderte Aktion „Bremse lösen“ aus.
Bezugszeichenliste
Empfangen von Applikationsprotokollen Initialisieren des Roboters
Herstellen einer authentischen Verbindung Aushandeln von Bedingungen und Zuständen Beauftragen einer durchzuführenden Maßnahme Auslösen einer Aktion
Austauschen von Zuständen oder Sensordaten
Vorrichtung
Schnittstelle
Verbindungsmodul
Kommunikationsmodul
Steuerungsmodul
Kontrollmodul
Speicher
Ausgang
Benutzerschnittstelle
Vorrichtung
Speicher
Prozessor
Eingang
Ausgang
Fortbewegungsmittel
Kommunikationsschnittstelle
Komponente
Nutzerschnittstelle
Automatisiertes Fahrsystem
Sensorik
Datenübertragungseinheit
Speicher
Netzwerk , 50‘ Roboter
Kommunikationsschnittstelle
Speicher
Backend 61 Kommunikationsschnitstelle
62 Speicher
AP Applikationsprotokoll
D Daten
S Steuerbefehl
S1-S100 Nachrichten
VI N Identifikationsnummer

Claims

Patentansprüche Verfahren für eine Kommunikation zwischen einem Roboter (50) und einem Fortbewegungsmittel (40), mit den Schritten:
- Herstellen (12) einer authentischen Verbindung zwischen dem Roboter (50) und dem Fortbewegungsmittel (40);
- Aushandeln (13) von Bedingungen und Zuständen für eine vom Roboter (50) durchzuführende Maßnahme;
- Beauftragen (14) der vom Roboter (50) durchzuführenden Maßnahme; und
- Auslösen (15) zumindest einer Aktion, die von einer Komponente (42) des Fortbewegungsmittels (40) auszuführen ist, durch den Roboter (50), wobei die zumindest eine Aktion auf einem Applikationsprotokoll (AP) basiert. Verfahren gemäß Anspruch 1 , wobei Applikationsprotokolle (AP) für mit dem Fortbewegungsmittel (40) kompatible Anwendungen durch das Fortbewegungsmittel (40) oder den Roboter (50) von einem Backend (60) eines Herstellers des Fortbewegungsmittels (40) oder eines Dienstleisters empfangen werden (10). Verfahren gemäß Anspruch 1 oder 2, wobei die Applikationsprotokolle (AP) Prozessschritte mit Zustandsbedingungen, zustandsändernden Aktionen oder Interaktionen beinhalten. Verfahren gemäß einem der vorherigen Ansprüche, wobei für Aktionen Vertrauensstufen vorgegeben sind. Verfahren gemäß einem der vorherigen Ansprüche, wobei Aktionen durch den Roboter (50) abgebrochen werden können. Verfahren gemäß einem der vorherigen Ansprüche, wobei zwischen dem Fortbewegungsmittel (40) und dem Roboter (50) Zustände oder Sensordaten ausgetauscht werden (16). Verfahren gemäß einem der vorherigen Ansprüche, wobei die authentische Verbindung eine zweikanalige Verbindung ist. Verfahren gemäß einem der vorherigen Ansprüche, wobei eine Initialisierung des Roboters (50) durch einen Hersteller des Fortbewegungsmittels (40) oder einen Dienstleister erfolgt (11), bei der ein symmetrischer Schlüssel für eine durch eine Komponente (42) des Fortbewegungsmittels (40) auszuführende Aktionen an den Roboter (50) übermittelt wird. Verfahren gemäß Anspruch 8, wobei der symmetrische Schlüssel verwendet wird, um eine als kritisch definierte Aktion authentisiert auszulösen. Verfahren gemäß einem der vorherigen Ansprüche, wobei ein Vertrauensverhältnis zwischen dem Fortbewegungsmittel (40) und einer Menge von Robotern (50, 50‘) hergestellt wird. Computerprogramm mit Instruktionen, die bei Ausführung durch einen Computer den Computer zur Ausführung der Schritte eines Verfahrens gemäß einem der Ansprüche 1 bis 10 für eine Kommunikation zwischen einem Roboter (50) und einem Fortbewegungsmittel (40) veranlassen. Vorrichtung (20) für eine Kommunikation zwischen einem Roboter (50) und einem Fortbewegungsmittel (40), mit:
- einem Verbindungsmodul (22) zum Herstellen (12) einer authentischen Verbindung zwischen dem Roboter (50) und dem Fortbewegungsmittel (40);
- einem Kommunikationsmodul (23) zum Aushandeln (13) von Bedingungen und Zuständen für eine vom Roboter (50) durchzuführende Maßnahme und zum Beauftragen (14) der vom Roboter (50) durchzuführenden Maßnahme; und
- einem Steuerungsmodul (24) zum Auslösen (15) zumindest einer Aktion, die von einer Komponente (42) des Fortbewegungsmittels (40) auszuführen ist, durch den Roboter (50), wobei die zumindest eine Aktion auf einem Applikationsprotokoll (AP) basiert. Kommunikationsschnittstelle (41) für eine Kommunikation zwischen einem Roboter (50) und einem Fortbewegungsmittel (40), wobei die Kommunikationsschnittstelle (41) eingerichtet ist:
- Applikationsprotokolle (AP) für mit dem Fortbewegungsmittel (40) kompatible Anwendungen zu empfangen (10);
- eine authentische Verbindung zwischen dem Roboter (50) und dem Fortbewegungsmittel (40) herzustellen (12); - Bedingungen und Zustände für eine vom Roboter (50) durchzuführende Maßnahme auszuhandeln (13) und die vom Roboter (50) durchzuführende Maßnahme zu beauftragen (14); und
- durch den Roboter (50) zumindest eine Aktion, die von einer Komponente (42) des Fortbewegungsmittels (40) auszuführen ist, auszulösen (15), wobei die zumindest eine Aktion auf einem Applikationsprotokoll (AP) basiert. Fortbewegungsmittel (40), wobei das Fortbewegungsmittel (40) eine Kommunikationsschnittstelle (41) gemäß Anspruch 13 aufweist oder eingerichtet ist, ein Verfahren gemäß einem der Ansprüche 1 bis 10 für eine Kommunikation zwischen dem Fortbewegungsmittel (40) und einem Roboter (50) auszuführen. Roboter (50), wobei der Roboter (50) eingerichtet ist, ein Verfahren gemäß einem der Ansprüche 1 bis 10 für eine Kommunikation zwischen dem Roboter (50) und einem Fortbewegungsmittel (40) auszuführen.
PCT/EP2023/053924 2022-02-28 2023-02-16 Verfahren, computerprogramm, vorrichtung und kommunikationsschnittstelle für eine kommunikation zwischen einem roboter und einem fortbewegungsmittel, sowie fortbewegungsmittel und roboter WO2023161127A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022202040.5 2022-02-28
DE102022202040.5A DE102022202040A1 (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

Publications (1)

Publication Number Publication Date
WO2023161127A1 true WO2023161127A1 (de) 2023-08-31

Family

ID=85278580

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/053924 WO2023161127A1 (de) 2022-02-28 2023-02-16 Verfahren, computerprogramm, vorrichtung und kommunikationsschnittstelle für eine kommunikation zwischen einem roboter und einem fortbewegungsmittel, sowie fortbewegungsmittel und roboter

Country Status (2)

Country Link
DE (1) DE102022202040A1 (de)
WO (1) WO2023161127A1 (de)

Citations (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
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
US20180215043A1 (en) * 2017-02-01 2018-08-02 Toyota Research Institute, Inc. Systems and methods for servicing a vehicle
CN109177940A (zh) * 2018-11-12 2019-01-11 长沙源婕科技有限公司 一种电池更换机器人
US20190364022A1 (en) * 2018-05-23 2019-11-28 Tyfone, Inc. Electronic device for secure communications with an automobile
US20190358818A1 (en) 2018-05-22 2019-11-28 Uber Technologies, Inc. Automated Cleaning Systems for Autonomous Vehicles
US10504094B1 (en) 2016-02-16 2019-12-10 State Farm Mutual Automobile Insurance Company Connected car as a payment device
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
EP3747688A1 (de) * 2019-06-06 2020-12-09 Volkswagen Ag Steuerung eines ladevorgangs für ein kraftfahrzeug
US11020856B2 (en) 2017-07-31 2021-06-01 Volkswagen Ag Transportation vehicle and method for controlling a robot
US20210197684A1 (en) 2019-12-30 2021-07-01 Oliver Crispin Robotics Limited Robotic systems and methods for vehicle fueling and charging

Patent Citations (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
US20180215043A1 (en) * 2017-02-01 2018-08-02 Toyota Research Institute, Inc. Systems and methods for servicing a vehicle
US11020856B2 (en) 2017-07-31 2021-06-01 Volkswagen Ag Transportation vehicle and method for controlling a robot
US20190358818A1 (en) 2018-05-22 2019-11-28 Uber Technologies, Inc. Automated Cleaning Systems for Autonomous Vehicles
US20190364022A1 (en) * 2018-05-23 2019-11-28 Tyfone, Inc. Electronic device for secure communications with an automobile
CN109177940A (zh) * 2018-11-12 2019-01-11 长沙源婕科技有限公司 一种电池更换机器人
EP3747688A1 (de) * 2019-06-06 2020-12-09 Volkswagen Ag 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
US20210197684A1 (en) 2019-12-30 2021-07-01 Oliver Crispin Robotics Limited Robotic systems and methods for vehicle fueling and charging

Also Published As

Publication number Publication date
DE102022202040A1 (de) 2023-08-31

Similar Documents

Publication Publication Date Title
EP3609732B1 (de) Steuerungsvorrichtung und verfahren zur steuerung einer ladesäule
EP2507676B1 (de) Dockingterminal und system zur steuerung von fahrzeugfunktionen
EP2931567B1 (de) System zum selektiven öffnen eines fahrzeuges durch einen servicedienstleister
EP3615371A1 (de) Verfahren zur zweistufigen autorisierung eines ladevorgangs an einer ladesäule
DE102019115692A1 (de) Verbesserte ladegerätsicherheit für elektrifiziertes fahrzeug
DE102006009098A1 (de) Kraftfahrzeugdiagnose und Fahrzeugannahme
EP2936457A1 (de) System zur parkzeitverwaltung
DE102007012304A1 (de) Schnittstelle in einem Fahrzeug und Verfahren zum Datenaustausch
DE102018118598A1 (de) Multimodale fahrzeugnäherungssicherheit
DE102016222541A1 (de) Verfahren zur Autorisierung eines Zugriffs auf ein Kraftfahrzeug zur Fremdnutzung und System
DE102019100780A1 (de) Automatisches Feedbacksystem für Updates von Fahrzeugsoftware
DE102016220848A1 (de) Ladesystem und Verfahren zum automatisierten Laden von Elektrofahrzeugen
DE102019122259A1 (de) Intelligente fahrzeugverbindung
DE102019123022A1 (de) Datenaustausch- und wiederversorgungsinfrastruktur für fahrzeuge
EP2870045A2 (de) Vorortbedienung einer komponente einer eisenbahngleisanlage
EP3747688A1 (de) Steuerung eines ladevorgangs für ein kraftfahrzeug
DE102017222434A1 (de) Verfahren zur Authentifizierung eines Kraftfahrzeugs
WO2018007049A1 (de) Verfahren zur sicheren authentifizierung von steuervorrichtungen in einem kraftfahrzeug
WO2023161127A1 (de) Verfahren, computerprogramm, vorrichtung und kommunikationsschnittstelle für eine kommunikation zwischen einem roboter und einem fortbewegungsmittel, sowie fortbewegungsmittel und roboter
DE102013200528A1 (de) Verfahren und Vorrichtung zum Betrieb eines Kommunikationsnetzwerks insbesondere eines Kraftfahrzeugs
CN113767612A (zh) 收集与客运车辆设备相关的数据的模块
DE102021126319A1 (de) Authentifizieren einer berechtigungserhöhung bei einem beförderungsdienst
DE102015202269A1 (de) Fahrzeugladevorrichtung
DE102019208424A1 (de) Kommunikationssystem mit einem Kommunikationsadapter und einer Koordinierungseinrichtung sowie Kommunikationsadapter, Koordinierungseinrichtung sowie Verfahren zum Durchführen einer Kommunikation
DE102018124144A1 (de) Fahrzeugkomponentenbetrieb

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23705555

Country of ref document: EP

Kind code of ref document: A1