EP3038062B1 - Method and vehicle equipment for DSRC communication - Google Patents

Description

TECHNICAL AREA

The present invention relates to methods and vehicle devices for so-called dedicated short range communication, hereinafter referred to as DSRC communication. In particular, the present invention relates to a method for carrying out a DSRC communication by means of a vehicle device and a vehicle device with a DSRC communication module which is configured to carry out a method for DSRC communication.

BACKGROUND

The communication between a vehicle device, for example a vehicle device with a so-called onboard unit, which is also known as an onboard entity (OBE), and a beacon, for example a roadside entity (RSE), can be, for example, a DSRC communication. As soon as a vehicle in which the vehicle device is carried enters a close range of the beacon, DSRC communication can take place between the beacon and the vehicle device.

Some aspects of DSRC communication are standardized. Specifications for such a DSRC communication can be found, for example, in the following standards: EN 15509, EN ISO 14906, Cen ISO / TS 12813, Cen ISO / TS 13141 and EN 12834 these standards are expressly referred to in the context of the present description.

Some methods for performing DSRC communication are known from the prior art. For example, describes the EP 2 360 641 B1 a method for DSRC communication between beacons and vehicle devices of a road toll system, whereby the beacons have their own key and the vehicle devices do not have the system's own key but an individual key. the EP 2 602 767 B1 describes a method for signaling toll transactions in a road toll system with geographically distributed beacons which process toll transactions with vehicle devices of vehicles passing through them. The procedure described there is also based on DSRC communication.

The DSRC communication between the beacon on the one hand and the vehicle equipment on the other hand is used in particular for the purpose of toll collection. In particular, the DSRC communication can therefore be relevant for a payment service, namely the payment of the toll. It may therefore be necessary to carry out a main program on the vehicle equipment that has been previously certified. The certification of the main program confirms that the main program conforms to the standards and conforms to the specifications of the institutions involved in the payment service. In particular, with non-certified main programs it is not possible to use a payment service that is based on DSRC communication.

The problem in this context is that the specifications of the institutions involved in the payment service can change over time and / or other institutions want to use the payment service based on the DSRC communication. To stick to the example of toll collection, it can happen, for example, that other countries want to use the payment service based on the DSRC communication, but have different requirements than countries already participating in the payment service.

However, if the specifications of the institutions that participate in the payment service change, the main program would have to be adapted to the new specifications and consequently be completely recertified after the adaptation. This approach proves impractical.

The pamphlet DE 10 2005 055835 A1 describes a mobile detection unit (OBU) of an electronic toll collection system with a localization unit and a transmitting / receiving unit for exchanging data with a central processing unit or a central computer network. In order to provide a mobile detection unit (OBU) that enables the mobile detection unit to be operated in toll collection systems from different toll operators with different requirements, both in terms of hardware and software, without having to significantly modify or standardize the existing toll collection systems, the mobile detection unit is the is equipped with a first software (S1) that enables operation exclusively in a first toll collection system (M1), and with basic software (SB) which, in addition to the first toll collection system (M1), also allows operation in at least one different toll collection system (MX ), whereby the mobile detection unit can optionally be switched between operation using the first software (S1) and the basic software (SB).

From the pamphlet EP 1 630 747 A2 a method for automatic toll collection is also known in which several toll or fee collection areas are provided. Transmitters that periodically emit data packets are arranged in the area of the toll roads or traffic routes. The data packets include an identification code from which the associated survey area can be clearly derived. Vehicles subject to tolls are equipped with recording devices that record the information from the transmitters in different collection areas and process this information in different ways according to the area they belong to.

DESCRIPTION

According to a first variant of a first aspect of the invention, a method is proposed for performing DSRC communication by means of a vehicle device comprising a DSRC communication module, the method comprising: executing a ready-to-receive routine of a main program stored in the vehicle device by a processor of the DSRC communication module; Receiving by a DSRC transceiver of the DSRC communication module, which is sent out by a beacon on the road side and which comprises an identifier, by a DSRC transceiver which is operatively coupled to the processor; Sending out a reply message that a Processing result includes, by the DSRC transceiver to the roadside beacon; which is characterized in that it further comprises between receiving and transmitting: checking, by means of the processor, within the framework of instructions of the main program, whether a program part of the main program on the vehicle equipment side is assigned to the received identifier; if a program part of the main program on the vehicle equipment side is assigned to the received identifier: execution of the assigned program part of the main program on the vehicle equipment side by the processor (52) at least for generating the processing result as a function of the received identifier; if the identifier is not assigned a program part of the main program on the vehicle equipment side: (a) determining at least one first subprogram assigned to the received identifier, stored in the vehicle equipment, which is not part of the main program and (b) executing the first subprogram by the processor at least to generate it of the processing result as a function of the received identifier.

According to a second variant of the first aspect of the invention, an alternative to the first variant, a method for performing DSRC communication by means of a vehicle device comprising a DSRC communication module is proposed, which comprises: executing a ready-to-receive routine of a main program stored in the vehicle device by a processor of the DSRC Communication module; Receiving by a DSRC transceiver of the DSRC communication module, which is sent out by a beacon on the road side and which comprises an identifier, by a DSRC transceiver which is operatively coupled to the processor; Sending a response message comprising a processing result by the DSRC transceiver to the roadside beacon and characterized in that it further comprises between receiving and sending: processing the request message by means of the processor within the framework of instructions of the main program with (a) the Determining at least one of the first or second subroutines associated with the received identifier and stored in the vehicle device, none of which are part of the main program, and (a) either: (i) executing the first subroutine if the identifier received with the request message is a first identifier corresponds to, by the processor at least for generating the processing result as a function of the received identifier or (ii) the execution of the second subroutine, if the identifier received with the request message does not correspond to the first identifier, by the Pr ozessor at least for generating the processing result as a function of the received identifier.

According to a first variant of a second aspect of the invention, a vehicle device is also proposed with a DSRC communication module comprising a DSRC transceiver and a processor, and with a program memory, the processor being operatively coupled to the DSRC transceiver and to the program memory and wherein the program memory comprises a main program with a ready-to-receive routine, the execution of which configures the processor to receive, by means of the DSRC transceiver, a request message sent by a roadside beacon, which comprises an identifier; which is characterized in that the program memory comprises at least one first sub-program that is not part of the main program, wherein both the execution of the sub-program and the execution of a vehicle equipment-side program part of the main program further configure the processor to generate a processing result depending on the received identifier and for sending a response message comprising the processing result by means of the DSRC transceiver to the roadside beacon; wherein the main program comprises instructions that configure the processor to check whether the vehicle equipment-side program part of the main program is associated with the received identifier; and - if the program part of the main program on the vehicle equipment side is assigned to the received identifier - for executing the program part of the main program on the vehicle equipment side, or - if no program part of the main program on the vehicle equipment side is assigned to the received identifier - for (a) determining the first sub-program assigned to the received identifier and ( b) Execution of the first subroutine.

According to a second variant of the first aspect of the invention, an alternative to the first variant, a vehicle device with a DSRC communication module is proposed, which comprises at least one DSRC transceiver and at least one processor, and with at least one first program memory, the processor being connected to the DSRC transceiver and is operatively coupled to the program memory and wherein the program memory comprises a main program ready-to-receive routine, the execution of which configures the processor to receive, by means of the DSRC transceiver, a request message sent by a roadside beacon comprising an identifier; and is characterized in that the program memory has a first sub-program and comprises at least one second sub-program, neither of which is part of the main program, wherein both the execution of the first sub-program and the execution of the second sub-program further configure the processor to generate a processing result based on the received identifier and to send out a response message comprising the processing result by means of the DSRC transceiver to the roadside beacon; wherein the main program comprises instructions that configure the processor to (a) determine whether the first or second sub-program is associated with the received identifier; and (b) either (i) executing the first subroutine if the received identifier corresponds to a first identifier, or (ii) executing the second subroutine if the received identifier does not correspond to the first identifier.

The invention thus provides methods and vehicle devices for DSRC communication with a roadside beacon, within the framework of which an identifier is received by the vehicle device from the roadside beacon. Depending on the received identifier, a processing result that is transmitted back from the vehicle device to the roadside beacon is generated either by a vehicle device-side program part of a main program stored in the vehicle device, which controls the reception of the identifier, or by a first sub-program stored in the vehicle device or from a second sub-program stored in the vehicle device.

The method according to the invention and the vehicle device according to the invention thus implement the only general inventive idea which is to provide the execution of a first subprogram as an alternative to the execution of a program part of the main program on the vehicle device side or a second subprogram. In this sense, the invention provides for the execution of a first subroutine, unless the alternative execution in the form of a program part of the main program on the vehicle equipment side or a second subroutine is not indicated. Since the alternative execution of a program part of the main program on the vehicle equipment side neither excludes nor conditions the existence of the second subroutine, and conversely the alternative execution of the second subprogram neither excludes nor conditions the existence of the program part of the main program on the vehicle equipment side, it is in the interest of a concise representation of what is claimed In terms of the scope of protection, it is inexpedient to attempt to protect the two alternatives of the program elements available for alternative execution in in each case to reproduce a single independent claim in the same category together.

With the invention, it is advantageously possible, in addition to a main program that has been certified once for a DSRC transaction service, to provide sub-programs for DSRC transactions of other types of services on the vehicle device that are certified in interaction with the main program, without the need to recertify the main program for each new sub-program were. The invention makes it unnecessary to re-certify a main program certified for a first DSRC transaction service for the first DSRC transaction service when a main program-subroutine combination has been certified for a second DSRC transaction service.

This effect increases with each new DSRC transaction service provided in the form of a new sub-program and scales quadratically with the total number of DSRC transaction services provided: If a fourth DSRC transaction service is provided with a fourth sub-program, only the fourth sub-program is certified with the main program due. A recertification of the combination of the other three sub-programs with the main program can be omitted because the sub-programs are not linked to each other, but only to the main program, so that every first provided DSRC transaction service runs independently of every second provided DSRC transaction service:
For the twentieth DSRC transaction service supported by the vehicle device, only a twentieth certification needs to be carried out with the invention and not one hundred and ninety-first to two hundred tenth, as would be the case without the invention.

If it is mentioned above or below that the received identifier is compared with a first identifier, this is to be understood as meaning that a value of the received identifier is compared with a value of the first identifier for a match.

A first value of the first identifier is preferably already stored in a memory of the vehicle device before the value of the received identifier is received, for example in an index file that includes several different values of identifiers of the same type stored in advance on the vehicle device side, including the first value of the first Identifier counts.

A roadside beacon is understood to mean any DSRC transceiver module that is stationary (for example on a control bridge spanning the road) or temporarily mobile (for example in / on a control vehicle) on, on, above or next to a traffic area that is connected to a Vehicle can be driven on, at a distance from the vehicle that allows DSRC communication. Typically, depending on the intended range, such a distance is in the range from a few centimeters to a few hundred meters.

The program memory according to the invention can be comprised by the DSRC communication module or by another component of the vehicle device, for example a vehicle device that is coupled to the DSRC communication module via a communication link.

In general, every vehicle device is according to the invention with a DSRC communication module, the DSRC communication module of which is configured to carry out each of the methods according to the invention for DSRC communication as well as each of the embodiments of the methods according to the invention described below.

Even if the following embodiments of the invention are only written in relation to the first aspect of the method according to the invention, these embodiments also apply to the second aspect of the products according to the invention. The features of the process-related embodiments are to be interpreted as a product when the claim category changes to the second aspect of the products according to the invention, in that components for carrying out the corresponding embodiment are included in the product according to the invention and / or components of the product according to the invention are designed to carry out the corresponding embodiments to ensure.

Embodiments of at least one of the methods according to the invention provide that this method according to the invention also includes the return to a first ready-to-receive routine of an initialization phase of the main program after the processing result message has been sent out.

Embodiments of at least one of the methods according to the invention or at least one embodiment mentioned above provide that the subroutine to be executed is determined by means of the processor within the framework of instructions of the main program on the basis of at least one index file stored in the vehicle device, the at least one associated with the identifier Contains linkage with the first subprogram or a second subprogram.

The received identifier is preferably compared with at least one identifier in the index file which is linked to a reference to at least the first subroutine.

For example, it can be provided that the link comprises a jump address which refers to a program memory part of the vehicle device that contains the first sub-program or the second sub-program.

Insofar as the execution of a program part of the main program on the vehicle equipment side is an alternative to the first subroutine, no index file is required to check whether the received identifier is assigned a program part of the main program on the vehicle equipment side. For example, the (main program) identifier that is assigned to the program part of the main program on the vehicle equipment side can be stored in the main program itself. Only in the case in which the received identifier does not correspond to the main program identifier, instructions of the main program are executed by the processor, which searches the index file for a value of the identifier assigned to the first subprogram that matches the value of the received identifier.

Insofar as the execution of a first subroutine is an alternative to the second subroutine, no index file is mandatory for checking whether the received identifier is assigned to the first subroutine. For example, the first identifier that is assigned to the first sub-program can be stored in the main program itself. Only in the case in which the received identifier does not correspond to the first identifier, instructions of the main program are executed by the processor, which searches the index file for a value of the identifier that is assigned to the second subprogram that matches the value of the received identifier.

Embodiments of at least one of the methods according to the invention or at least one embodiment mentioned above provide that the ready-to-receive routine is included in an initialization phase of the main program, the identifier comprises a service identifier and the first sub-program or a second sub-program is assigned to the service identifier, and after step a) and before step b) the initialization phase of the Main program is left in order to continue the initialization phase by means of the first subroutine or the second subroutine.

Embodiments of at least one of the methods according to the invention or at least one embodiment mentioned above provide that the request message is received by the DSRC communication module in an initialization phase of the main program and contains a beacon service table that includes the identifier in the form of a service identifier, and the response message in the Initialization phase of the main program or a first or second sub-program is sent out and contains a vehicle service table which includes the processing result.

In both developments, the determination of at least one first or second sub-program assigned to the received identifier and stored in the vehicle device takes place within the framework of instructions of the main program, which are to be assigned to an initialization phase of the main program that includes the ready-to-receive routine.

Developments of one of the two aforementioned embodiments provide, in a first variant, that at least one of the methods according to the invention, the execution of a ready-to-receive routine of a first subroutine stored in the vehicle device by a processor of the DSRC communication module, the receipt of a request message sent by a roadside beacon, the one Element identifier comprised by a DSRC transceiver of the DSRC communication module operatively coupled to the processor; sending a response message comprising a processing result generated by the processor in the course of processing the request message as a function of the received element identifier by the DSRC transceiver to the roadside beacon, and between receiving and sending further comprises: checking by means of the processor, within the framework of instructions of the first sub-program, whether the element identifier is assigned a program part of the first sub-program on the vehicle equipment side; if a program part of the first subprogram on the vehicle equipment side is assigned to the element identifier: execution of the program part of the subprogram on the vehicle equipment side by the processor at least to generate the processing result; if no program part of the sub-program on the vehicle equipment side is assigned to the element identifier: (c) determining at least one first sub-sub-program assigned to the element identifier and stored in the vehicle equipment that is not part of the subroutine; (d) the processor executing the first sub-routine to generate the processing result message.

In the same way as an alternative second variant with regard to the execution of a second sub-program is provided for the first variant of the method aspect of the invention with regard to the execution of a program part of the main program on the vehicle equipment side, second variants of further developments can be provided as an alternative to the aforementioned first variants of further developments, which In contrast to the first variants, which provide for the alternative execution of the program part of the sub-program on the vehicle equipment side, provide for the alternative execution of a second sub-sub-program.

This consideration is consistent with the view that the subroutine can be understood as the main program according to the invention if it corresponds to the main program, which is the feature of the independent claims.

Insofar as embodiments of the method according to the invention do not provide that the determination of at least one of the first or second subprograms assigned to the received identifier and stored in the vehicle device does not take place within the framework of instructions of the main program that are to be assigned to an initialization phase of the main program that includes the readiness to receive routine that the ready-to-receive routine is included in a presentation phase of the main program, the identifier includes an element identifier and the first sub-program or a second sub-program is assigned to the element identifier, and the initialization phase of the main program is completed before the ready-to-receive routine is carried out, and after step a) and before step b) the presentation phase of the main program is exited to the presentation phase by means of the first sub-program or the second sub-program s to continue.

Embodiments of at least one of the methods according to the invention or at least one embodiment mentioned above provide that the first subprogram, the second subprogram and / or the first subprogram includes an attribute data record in his / her presentation phase or by the processor when executing the first subprogram , the second sub-program or the sub-sub-program is accessed in its presentation phase, and that the processing result message is created as a function of the attribute data record and / or includes the attribute data record.

A further development of this embodiment also provides for the implementation of a DSRC transaction based on the attribute data record, the DSRC transaction providing at least one pre-stored attribute so that the provided attribute can be read by means of the beacon; and / or comprises receiving a new attribute from the beacon and storing the attribute in a memory of the vehicle device.

Embodiments of at least one of the methods according to the invention or at least one embodiment mentioned above provide that the implementation of the DSRC communication conforms to at least one of the following standards: EN 15509, EN ISO 14906, Cen ISO / TS 12813, Cen ISO / TS 13141, EN 12834.

Finally, embodiments of at least one of the methods according to the invention or at least one embodiment mentioned above can also include receiving a subroutine and an identifier by means of a mobile radio communication module of the vehicle device, executing a program loading program with (a) storing the subroutine in the program memory and (b) adding a reference to the sub-program linked to the identifier in an index file and the use of the index file to determine the first or second sub-program assigned to the received identifier.

Analogously, in embodiments of at least one of the vehicle devices according to the invention, it can be provided that this vehicle device comprises a mobile radio communication module, which is coupled to a processor of the vehicle device, and a memory that contains a program loading program, the processor being configured by means of the mobile radio -Communication module to be instructed to execute the program loading program, the execution of which configures the processor to store a subprogram received by means of the mobile radio communication module and linked to an identifier in the program memory of the vehicle device and to add a reference to the subprogram linked to the identifier to an index file to read the processor of the DSRC communication module by executing instructions from the main program to determine the first or z wide subroutine is configured.

This provides methods and devices to which new subroutines can be added without having to access the main program and without the main program being impaired. The main program exists and runs completely independently of the subroutines. If no subroutine can be determined from the index file for a received identifier, the main program can configure the processor of the DSRC communication module to send a corresponding inoperability response to the beacon and then switch to a final phase and / or back to the ready-to-receive routine.

The processor of the memory of the vehicle equipment can be the already mentioned processor of the DSRC communication module; Instead, it can also be provided by a vehicle device in addition to the already mentioned processor of the DSRC communication module, the vehicle device as well as the DSRC communication module being included in the vehicle device and being coupled to the DSRC communication module via a communication link.

The memory of the vehicle equipment can be the already mentioned program memory; Instead, it can also be another memory that is additionally provided by the DSRC communication module or a vehicle device which, like the DSRC communication module, is included in the vehicle device and is coupled to the DSRC communication module via a communication link.

Storing the subprogram in the program memory includes copying or moving the subprogram into the program memory as well as, alternatively or optionally, the installation of the subprogram in the program memory. In the latter case, the sub-program received by the mobile radio communication module can initially be present in the main memory of the processor in the form of an installation routine for the sub-program or can be received as such by the mobile radio communication module.

A reference to the subroutine linked to the identifier means any type of information which enables the subroutine to be found for its execution.

Such a reference can be understood to mean the designation of the subroutine, a jump address to a storage location of the subroutine or some other link that points to the subroutine.

Further features and advantages can be recognized after studying the following detailed description and considering the illustrations.

BRIEF DESCRIPTION OF THE FIGURES

The elements of the figures are not necessarily shown to scale. Rather, the figures serve to illustrate some basic ideas of the present invention.

Fig. 1

schematisch und exemplarisch ein Blockschaltbild eines elektronischen Mautsystems;

Fig. 2

schematisch und exemplarisch ein Blockschaltbild einer Fahrzeugeinrichtung gemäß einer oder mehreren Ausführungsformen;

Fig. 3

schematisch und exemplarisch ein Flussdiagramm eines DSRC-Kommunikationsverfahrens gemäß einer oder mehreren Ausführungsformen;

Fig. 4

schematisch und exemplarisch ein erstes Ablaufdiagramm eines DSRC-Kommunikationsverfahrens gemäß einer oder mehrerer Ausführungsformen der ersten Variante der Erfindung;

Fig. 5

schematisch und exemplarisch ein zweites Ablaufdiagramm eines DSRC-Kommunikationsverfahrens gemäß einer oder mehrerer Ausführungsformen der zweiten Variante der Erfindung;

Fig. 6

schematisch und exemplarisch ein drittes Ablaufdiagramm eines DSRC-Kommunikationsverfahrens gemäß einer oder mehrerer Ausführungsformen der ersten und zweiten Variante der Erfindung;

Show in the pictures

Fig. 1

a schematic and exemplary block diagram of an electronic toll system;

Fig. 2

schematically and by way of example, a block diagram of a vehicle device according to one or more embodiments;

Fig. 3

schematically and by way of example a flow diagram of a DSRC communication method according to one or more embodiments;

Fig. 4

schematically and by way of example, a first flowchart of a DSRC communication method according to one or more embodiments of the first variant of the invention;

Fig. 5

schematically and by way of example, a second flowchart of a DSRC communication method according to one or more embodiments of the second variant of the invention;

Fig. 6

schematically and by way of example, a third flowchart of a DSRC communication method according to one or more embodiments of the first and second variants of the invention;

DETAILED DESCRIPTION

The aspects described below relate to DSRC communication.

In this context, the Fig. 1 a schematic and exemplary block diagram of an electronic toll system 10. DSRC communication is used in particular between a vehicle device (OBE) 11 and a beacon (RSE) 12. For example, the vehicle device 11 is carried in a vehicle that enters in a vicinity of the beacon 12. The size of the close range is essentially limited by the DSRC technology itself. Via the DSRC communication between the vehicle device 11 and the beacon 12, for example, data is exchanged which is relevant for a payment service, as is typical for the purposes of toll collection, for example.

The vehicle device 11 can be connected to a central system 13, which can be operated by a so-called OBE provider. This connection can be, for example, a connection via a conventional cellular network, for example a GSM, UMTS, GPRS, EDGE, LTE or other cellular network. For example, the connection between the central system 13 of the OBE provider and the vehicle device 11 can be used to configure and / or personalize the vehicle device 11.

A configuration is understood to mean the assignment of the vehicle equipment identity to a vehicle identity which, for example, by assigning at least one vehicle identifier (e.g. vehicle license plate number of the vehicle and / or insurance number of the vehicle) to at least one OBE- Identification (e.g. serial number or mobile phone number of the vehicle equipment 11 (OBE) in a decentralized data memory of the vehicle equipment and / or in a central data memory of the OBE provider. This configuration can assign toll-relevant vehicle data (e.g. number of axles, emission class, permissible total weight, etc.) for the OBE identifier.

Personalization is understood to mean the assignment of the vehicle equipment identity to a user identity, which can be obtained, for example, by assigning at least one user identifier (e.g. customer number and / or means of payment of the customer (credit card number, account number. )) to at least one OBE identifier (e.g. serial number or mobile phone number of the vehicle equipment 11 (OBE) in a decentralized data memory of the vehicle equipment and / or in a central data memory of the OBE provider. As a rule, the personalization precedes the configuration, because only a registered user is authorized to initiate or carry out a configuration on a vehicle equipment (OBE) personalized by way of his registration.

In order to avoid data inconsistencies, each newly set up or changed personalization and / or configuration of the system component (vehicle equipment 11 or control center 13) on which the personalization and / or configuration was first set up or changed is activated by means of the aforementioned connection via a cellular network the respective other system component (control center 13 or vehicle equipment 11).

On the other hand, the beacon 12 can be connected to a further central system 14 which is operated by a toll operator, a so-called toll charger. The connection between the beacon 12 and the central system 14 operated by the toll operator can be configured as desired, for example wired and / or via a cellular network. For example, the beacon 12 forwards data to the central system 14 operated by the toll operator. The central system 13 operated by the OBE provider can be connected to the central system 14 operated by the toll operator, as shown in FIG Fig. 1 is illustrated schematically, it being possible for this connection to be configured as desired. In particular, the central system 13 operated by the OBE provider and the central system 14 operated by the toll operator can also be understood as a common system.

With reference to the Fig. 2 A possible structure of a vehicle device 11 will now be discussed in somewhat more detail.

The one in the Fig. 2 The vehicle device 11 shown comprises a DSRC communication module 50 which is designed for communication with a beacon 12. To carry out such communication, the DSRC communication module 50 comprises a DSRC transceiver 51, which is designed to transmit and receive data in accordance with the DSRC communication. Furthermore, a program memory 53 is provided in the DSRC communication module 50, on which a certified main program can be stored. The program memory 53 can be a first program memory and the DSRC communication module 50 can also have a second program memory which, however, is not shown in the figures

A processor 52 is operatively coupled to both program memory 53 and DSRC transceiver 51. The processor 52 is designed in particular to execute the certified main program stored in the program memory 53 and to use the DSRC transceiver 51 for these purposes, and in particular carry out the DSRC communication with the beacon 12. The processor 52 may be a separate processor that essentially only performs for the processes of the DSRC module 50.

In addition to the DSRC communication module 50, the vehicle device 11 can comprise an OBU (on-board unit, also not shown) that is communicatively coupled to the DSRC communication module 50 and has an OBU processor which, for example, contains position data that it receives from a position determination device (for example a GNSS Receiver of a global navigation satellite system (GNSS)) of the vehicle device 11 receives, processed with the result of recognizing the driving on a toll road.

Furthermore, the vehicle device can comprise a mobile radio communication module which is communicatively coupled to the DSRC communication module 50 and / or the OBU. The mobile radio communication module can be comprised of the OBU and / or the DSRC communication module.

OBU and position determination device can be encompassed by a common housing and are preferably arranged on a common printed circuit board. However, they can also each be encompassed by their own housing, and communication between them can take place in a wired or wireless manner (e.g. by means of W-LAN or Bluetooth).

In the following, the vehicle device 11 is occasionally also referred to as “OBE” for short.

A flow diagram of an exemplary DSRC communication is shown schematically and by way of example in FIG Fig. 3 illustrated. This exemplary method is to be explained in more detail below. The DSRC communication takes place between the beacon on the one hand (RSE - left side) and the vehicle equipment (OBE - right side) on the other. As usual in such a flowchart, the two vertical axes in FIG Fig. 3 the passage of time.

A DSRC communication as it is in the Fig. 3 shown as an example, can be roughly divided into a so-called initialization phase 2.0, a so-called presentation phase 3.0, a so-called receipt phase 4.0 and a so-called release & closing phase 5.0.

The initialization phase 2.0 can be a first ready-to-receive routine of a stored in the program memory 53 of the DSRC communication module 50 Main program by a processor 52 of the DSRC communication module 50 include.

The main program can be a certified main program.

For example, the vehicle device 11 continuously executes the initialization phase 2.0 of the main program, which is stored in the program memory 53 of the vehicle device 11. For example, the initialization phase of the main program includes the execution of measures by the processor 52 and / or the provision of functionalities of the vehicle device 11 with which the vehicle device 11, in particular the DSRC communication module, is ready to receive before receiving a first request message from the beacon 12 (RSE) 50, can be ensured for the receipt of such a request message.

In particular, the execution of the initialization phase by the vehicle equipment OBE can be carried out on a so-called index file 7.0 (cf. Fig. 4 ), which can also be stored in the program memory 53 of the vehicle equipment OBE.

For example, the DSRC communication module 50 starts a DSRC transaction via a (in the Fig. 3 not shown, s. Fig. 4 ) Program entry 1 with initialization phase 2.0 briefly explained above, in which initially only a ready-to-receive routine of the main program is executed in order to make vehicle device 11 receptive to a request message from beacon 12.

On the side of the beacon 12, the initialization phase 2.0 can include a continuous transmission of a request message (INITIALIZATION.request). This request message can contain a beacon service table, which is also referred to as a beacon service table (BST). The request message can comprise an identifier which can be contained in the beacon service table, for example a service identifier which is also referred to as an application identifier (AID) and / or an element identifier which is also referred to as an element identifier (EID).

The beacon service, which can be identified by the AID, for example, can be, for example, a toll collection service for the purposes of toll collection (e.g. value of the AID equal to 1), a support beacon service for the purposes of Location determination (e.g. value of the AID equal to 21) and / or a surveillance service for the purpose of checking on a country-specific registration (e.g. value of the AID equal to 20). More detailed information on the possible services can be found in the standards mentioned above.

As soon as the vehicle device 11 comes into the vicinity of the beacon 12, the vehicle device 11 can receive this request message by means of the DSRC transceiver 51. For example, the vehicle equipment OBE replies with a reply message (INITIALISATION.response) and transmits a so-called vehicle service table, which is also referred to as a vehicle service table (VST), as part of this reply message. This VST contains identified service elements, for example all service elements, for example by means of element identifier EID, which are supported by the DSRC module 50.

Usually, the BST does not yet include an EID. A selection of operable EIDs can be sent from the vehicle device 11, for example with the transmission of the VST, for example as part of the VST, to the beacon 12. In the presentation phase, the beacon then sends the EID to the on-board device about which it would like to receive more information from the on-board device.

Further possible properties of BST and VST are specified in the standards mentioned above, to which reference is hereby expressly made.

A service element that is identified by an EID, in the case of an AID that identifies a toll collection service, can be a country- or region-specific toll service contract and / or a toll transaction type.

Specifically, within the scope of this initialization phase 2.0, the DSRC communication module 50 can respond to the received beacon BST with the VST. A specific service identifier AID can be requested from the beacon 12 in the beacon BST. Using ContextMark information contained in the VST, the beacon 12 searches for a so-called ContextMark with an associated element identifier EID, with which the beacon 12 wishes to continue communicating.

After the initialization phase 2.0 there is usually a so-called presentation phase 3.0. In this phase 3.0, the DSRC communication can be based on the EID determined in the initialization phase 2.0. For example, the beacon 12 queries further attributes of the vehicle device 11 with the determined EID and receives them from the DSRC communication module 50 a so-called presentation response, such as said GET_STAMPED.response. Figuratively speaking, the beacon 12 requests the vehicle equipment 11, specifically by means of a so-called GET_STAMPED.request message and / or as part of a so-called GET.request message, itself and some static data (for example values of so-called attributes in the form of To present attribute data, summarized in an attribute data set) to the vehicle device 11. These static data, which the beacon 12 can query from the vehicle device 11 during the presentation phase, can in particular relate to a payment service. In addition, the static data can identify the vehicle itself, for example the dimensions of the vehicle, the license plate number of the vehicle, weight information on the vehicle, axle information, etc. For example, the vehicle device 11 delivers this data in the context of a GET STAMPED.response message and / or in the context a GET.response message to the beacon 12. In addition, the vehicle equipment OBE can be authenticated in the presentation phase 3.0.

After this presentation phase 3.0, the beacon 12 has collected enough information from the vehicle device 11 to carry out the payment process. The presentation phase 3.0 is followed by a so-called receipt phase 4.0. During this phase 4.0, the beacon 12 can write data to the vehicle equipment 11 ("Write.data"), for example in the said program memory 53. Such data can be taken into account, for example, in a DSRC communication with a next beacon that is sent by the vehicle, in which the vehicle device 11 is carried, is passed.

A DSRC communication can end with a so-called Tracking & Closing - phase 5.0. At the beginning of this phase 5.0, the essential data exchange between the beacon 12 and the vehicle device 11 has already taken place and the transaction in question can no longer fail. In this phase 5.0, the vehicle device 11 is essentially only informed by the beacon 12 that the beacon 12 no longer sends any further data to the vehicle device 11 or that the vehicle device 11 no longer has to send any further data to the beacon 12.

Further exemplary aspects of a possible DSRC communication can be found, in particular, in the EN ISO 14906 standard. An exemplary DSRC communication includes, in particular, a so-called CARDME transaction.

Since, as explained above, the data that the vehicle equipment 11 in particular sends to the beacon 11 during the presentation phase 3.0 can be data relating to a payment service, it is generally necessary that the main program, which is stored on the program memory 53 of the Vehicle equipment it is filed 11 is certified. The certification of the main program expresses that the main program with the specifications of the institutions involved in the payment process, for example the central system operated by the toll operator and / or the specifications of the central system operated by the OBE provider, as well as with the specifications of the relevant standards, for example conforms to EN ISO 14906 and / or EN 15509.

The problem here is that the specifications, in particular of the institutions involved in the payment process, can change and / or new specifications from new institutions are to be added to the transaction functionality of the vehicle equipment. Specifically, for example, the specifications of different toll operators in different countries can differ from one another. However, if the specifications of the institutions involved change, it may also be necessary to adapt the course of the main program. However, since an adjustment can result in a change in the main program, a new certification of the main program must be carried out after such a change in the main program, which can be cumbersome. On the other hand, there are still no generally valid certification tests.

Therefore, a method for the use of loaded, changed program sequences is proposed here, which does not affect the use of the old existing program sequences of the certified main program, so that an already existing certification remains in place even after new program sequences have been added. In particular, only potentially usable supplementary program sequences, hereinafter referred to as sub-programs, have to be recertified, without the need for an overall new certification of the already existing main program.

If new attributes are required for DSRC communication, for example because a toll operator has changed its specifications and / or because a new toll operator has been added, the following specific problems can arise: For example, new attributes are not known and cannot be known in the program structure of the certified main program can be adjusted by further parameters. Furthermore, it is possible that a toll operator or another institution may initiate new, So-called state table functions or safety functions for the DSRC communication module 50 are added, for example because these are required for a specific DSRC communication. In such situations, it is useful that new program parts in non-time-critical situations are stored in a program memory 53 of the vehicle equipment 11, whereby such program parts, which are referred to below as sub-programs, are not allowed to intervene in the program parts of the existing certified main program, because such sub-programs otherwise can result in a loss of main program certification. At the same time, it should be ensured that the basic DSRC communication procedure as described above with reference to the Fig. 3 has been explained by way of example, is not changed.

In particular, various possible sequences of a DSRC communication method of the first variant are proposed, as shown schematically and by way of example in FIG Fig. 4 are illustrated, which are to be explained in more detail below.

As before, the DSRC communication starts on the part of the vehicle device 11 through a program entry 1 into the initialization phase 2.0. As mentioned, the initialization phase 2.0 can include a first ready-to-receive routine of a main program stored in the program memory 53 of the DSRC communication module 50 by a processor 52 of the DSRC communication module 50. This initialization phase 2.0 can be part of the main program that is stored in the program memory 53. The main program can be a certified main program.

The processor 52 carries out this initialization phase 2.0, for example based on an index file 7.0 which is also stored in the program memory 53, although this does not necessarily have to be the case. The initialization phase can also be carried out independently of the index file 7.0.

As part of the initialization phase 2.0, the DSRC communication module 50 receives the request message that the beacon 12 previously sent out by means of the DSRC transceiver 51. The request message includes an identifier AID, which can be contained, for example, in a beacon service table BST of the request message.

The vehicle device 11 processes the request message and, after processing the request message, sends a processing result message to the Beacon 12. In between, for example in the context of processing the request message, the vehicle device 11 carries out certain steps, which are shown in somewhat more detail below.

First variant:

According to a first variant, the following occurs, for example: Upon receipt of the identifier, which can in particular be a service identifier AID, the processor 52 checks, for example using the index file 7.0, whether a program part of the main program is assigned to the identifier AID. If this is the case - because the AID = 1, for example - then the processor 52 leaves the initialization phase 2.0 and goes into the presentation phase 3.0 and executes, for example, the program part of the main program assigned to the received identifier.

If, however, no program part of the main program is assigned to the identifier, the processor 52 uses the index file 7.0 to determine at least one of the jump addresses assigned to the identifier. The access of the processor 52 within the framework of instructions of the initialization phase 2.0 of the main program to the index file 7.0 and the receipt of the jump address are indicated by dashed arrows in FIG Fig. 4 shown. The at least one jump address refers to a program memory part of the vehicle device 11 which contains a subroutine, for example a reloaded reduced initialization phase 2.3 of a first subroutine or a reloaded reduced initialization phase 2.4 of a second subroutine, none of these subroutines being part of the main program.

In other words, the identifier that the beacon 12 has sent out leads to a branch out of the main program if no program part of the main program is assigned to the identifier. This can be understood as a parameter-dependent program branch in real time, the parameter which determines the program branch being an identifier which is sent by the beacon 12 and received by the vehicle device 11.

The initialization phase of the subroutines can be described as reduced because it lacks the ready-to-receive routine and the branch routine of the main program.

In any case, the processor 52 executes the subroutine, for example for AID = 20 said reloaded reduced initialization phase 2.3 or for AID = 21 the reloaded reduced initialization phase 2.4, in order to receive the request message, which the beacon 12 has sent out to process. The processor 52 then sends the processing result back to the beacon 12 by means of the DSRC transceiver 51.

It can be provided that the processor 52 returns to the initialization phase 2.0 of the main program after the processing result has been sent to the beacon 12. As a rule, however, the data transmitted in the subsequent communication steps with the beacon 12 include processing results of the processor 52, which are dependent in the same way on the service identifier AID, to which no program part of the main program is assigned, so that the further processing steps of the initialization phase 2.3 or 2.4 and the subsequent phases are preferably also instructed or carried out by the subroutine. This is not mandatory, however, because in the subsequent presentation phase 3.0, a program branching out of the main program into a sub-program can take place again, which is determined by the identifier received from the beacon 12 in the presentation phase 3.0.

The identifier that is received in the initialization phase 2.0 can in particular include a service identifier AID, and the at least one jump address can be assigned to the service identifier AID. However, the sub-program can not only include a reloaded initialization phase 2.3, but also a reloaded presentation phase 3.3 and / or a reloaded receipt phase 4.3 and / or a reloaded tracking & closing phase 5.3. In particular, it can be provided that the processor 52 after executing the initialization phase 2.3 in the reloaded phases 3.3, 4.3. and 5.3 passes over to carry out the DSRC communication with the beacon 12. All phases 3.3, 4.3 and 5.3 are outside the main program. It is possible that the sub-program is certified according to the loaded phases 2.3, 3.3, 4.3 and 5.3. However, this does not require that the standard phases 2.0, 3.0, 4.0 and 5.0 of the main program be changed. In other words, the certification of the main program with phases 2.0, 3.0 remains. 4.0 and 5.0 also remain unaffected when reloading phases 2.3, 3.3, 4.3 and 5.3. The above also applies accordingly to the subroutine with phases 2.4, 3.4, 4.4 and 5.4. It is possible to have further subroutines connected at this point. This is discussed in more detail below.

The initialization phase 2.0 is left in particular if, as explained above, the transmitted identifier is a service identifier to which no program part of the main program is assigned. The service identifier can in particular a so-called Application Identifier (AID). For example, the EN ISO 14906 standard provides that 31 different AIDs can be addressed. Such a service identifier AID can identify, for example, a toll payment service (AID = 1), a control service (AID = 20) and / or a location determination service (AID = 21). It is also possible for the service identifier to alternatively or additionally identify an information service, an electronic parking fee service or an electric charging service.

After receipt of the response message that the processor 52 creates depending on the AID = 1 and in the form of a VST, which includes various service elements in the form of EIDs (element identifiers) supported by the vehicle device 11, by means of the DSRC transceiver 51 to the beacon 12, the beacon 12 sends a further request message with a further identifier, in this case an element identifier EID = 2, to the DSRC communication module 50 in a subsequent presentation phase 3.0 of the main program the processor 52 receive and process the further request message. In doing so, it first checks whether a program part of the main program on the vehicle equipment side is provided for an EID = 2. Since the main program is only intended for answering inquiries with an EID = 1, the processor 52 calls the further index file 7.1 in the context of instructions of the main program, in which EID values not equal to 1 each with a subprogram, more precisely: its storage location in Program memory 53 is linked. For EID = 2, processor 52 uses the further index file to determine subroutine 3.1 and calls subroutine 3.1, which ends presentation phase 3.1 on the vehicle equipment side, in which its instructions configure the processor, another response message as part of presentation phase 3.1 to the beacon and to send to the roadside beacon by means of the DSRC transceiver 51. The answer includes the attributes of identification and classification of the vehicle.

The roadside beacon 12 then uses the received data to carry out a transaction by assigning the vehicle a toll charge that corresponds to its classification. The roadside 12 sends a document about this transaction in the subsequent receipt phase 4.1 to the DSRC communication module 50, which in turn confirms receipt in a response message. In the following tracking & closing phase 5.1. communication between beacon 11 and DSRC communication module 50 is completed.

The sub-program is ended with phase 5.1 and a change is made to a final phase 6 of the main program. This objection is on the part of the main program for each exit from the main program is provided in a sub-program; that is: with one jump the main program sets a pointer to the final phase 6, for example. It transfers this pointer to the subprogram or writes it to a pointer file in the program memory 53, which is known to each subprogram. When the subroutine is terminated, the processor 52 arrives at this pointer, as a result of which phases 4.0 and 5.0 of the main program, which the main program could have executed if EID = 1, are consequently skipped.

From the final phase, the main program changes back to the ready-to-receive routine of the initialization phase 2.0 in order to set up the readiness to receive of the DSRC communication module 50 for the BST of the next beacon 12.

Second variant:

The second variant, for which a flowchart is based on Fig. 5 is shown schematically, is similar in its basic idea to the first variant. Specifically, the processor 52 can proceed as follows when processing the request message according to the second variant: First, the request message is processed within the framework of instructions of the main program in a first processing process, with the result either: (a) the initiation of the execution of one in the first Program memory 53 or a second program memory of the DSRC communication module 50 stored first sub-program 2.3, which is not part of the main program if the identifier received with the request message corresponds to a first identifier, or (b): the initiation of the execution of a second sub-program 2.4, the is not part of the main program if the identifier received with the request message does not correspond to the first identifier.

According to the second variant, the processor 52 can dispense with checking whether the request message requires the use of a specific program part of the main program. This variant is useful, for example, when the main program essentially represents a program framework which, for example, essentially only comprises code for executing the initialization phase 2.0. If it is stored on the vehicle device 11 that the request message cannot be served with the code of the main program anyway, there is no need to check this. According to the second variant, it is also possible to execute said second sub-program 2.4, which is not part of the main program, in order to process the request message.

Which of the first or second subroutines 2.3 or 2.4 is to be executed is determined by the main program in this case through the mandatory access to a first index file 7.0, in which every possible value of the received identifier - in this case the service identifier AID - with the jump address of the identifier assigned subroutine is linked. By comparing the received AID value with the AID values stored in the first index file 7.0, the processor 52 determines the first or second subroutine 2.3 or 2.4 to be executed.

Processor 52 can then proceed as follows: Further processing of the request message in a second processing process following the first processing process, depending on the received identifier, either within the framework of instructions of the first subroutine 2.3 in case (a) or within the framework of instructions of the second subroutine 2.4 in case (b); and generating the processing result message in or following the second processing process within the framework of instructions of the first subroutine or the second subroutine.

Since no presentation phase 3.0 is provided in the second variant, at least the ready-to-receive routine always takes place in a presentation phase of subroutine 3.3 after a response has been sent in the initialization phase 2.3 or 2.4 presentation phase. or 3.4. It is assumed below that the ready-to-receive routine of subroutine 3.3 is executed by processor 52.

In the event that an element identifier EID, which is received by the vehicle equipment 11 with a new request message from the beacon 12, is not assigned a vehicle equipment-side program part 4.3 of the subroutine, the processor takes the first index file 7.1 from a second index file 7.1 within the framework of instructions in the subroutine 3.3 or the second subroutine 3.5 or 3.6 is to be executed as a function of the element identifier EID received.

Further possible features of the DSRC communication in the first and second variant:

Further possible features of the DSRC communication are described below. These features can be combined with features of the two variants described above.

When executing a particular service by processor 52, certain program modules may be required. Such program modules can be identified by said element identifiers, so-called element identifiers (EID).

The identifier transmitted by the beacon 12 can also include such an element identifier (EID) in addition or as an alternative to the service identifier. According to the first variant, the processor 52 can also check whether a program part of the main program is assigned to the received element identifier (EID), or it can proceed according to the second variant. If this is not the case, a jump address assigned to the element identifier can again be determined, this jump address referring to a program memory part of the vehicle device 11 which contains a further sub-program that is not part of the main program.

A program branching as a function of a received element identifier does not take place, for example, already in the initialization phase 2.0, but only in the presentation phase 3.0 of the main program or in a reloaded presentation phase 3.3 of one of the reloaded subroutines. If the processor 52 determines, for example when performing the initialization phase 2.0, that the service requested by the beacon 12 and identified by the service identifier AID is assigned to a program part of the main program, the processor 52 transmits said vehicle service table VST to the beacon by means of the DSRC transceiver 51 12 and moves on to the presentation phase 3.0. In this presentation phase 3.0, the processor 52 checks, for example, whether the received element identifier EID is still assigned a corresponding program part within the main program, in accordance with the first variant. If this is the case, the processor 52 can execute the presentation phase 3.0 by means of the main program and then pass into the said receipt phase 4.0 and from there into the tracking & closing phase 5.0. Alternatively, the test can be carried out in accordance with the second variant shown above. In other words, the processor 52 does not necessarily have to execute program parts of the main program, but can always execute subprograms that are not part of the main program in order to service the query from the beacon 12. Which subroutine is to be executed can be specified by said identifier which the beacon 12 has sent out (for example an AID and / or an EID). As explained, it can be stored in said index file 7.0 for a respective received identifier both for the service identifier AID and for the element identifier EID, for example in the form of jump addresses, at which storage location the relevant subroutine is located.

If the processor 52 comes to the result during the test during the presentation phase 3.0 that no program part of the main program (first variant) or no first subprogram (second variant) is assigned to the received element identifier EID, the processor 52 determines from another, for example Index file 7.1 a jump address assigned to the received element identifier EID, which points, for example, to a first subprogram (first variant) or a second subprogram (second variant), which comprises loaded program code for a presentation phase 3.1. The jump address can also refer to another subroutine that includes loaded program code for a different presentation phase, etc. the second variant) is assigned to a program branch on the part of the vehicle device 11. This type of branching can also be understood as a real-time program branch.

If the processor 52 leaves the main program during the presentation phase 3.0, in that the processor 52 either calls the sub-program with the loaded program codes for the phases 3.1, 4.1 and 5.1, or another sub-program, the receipt phase 4.0 and the tracking are no longer activated - & Closing phase 5.0 of the main program carried out, but corresponding phases of the relevant reloaded subprogram.

In the second variant, no receipt phase 4.0 and no tracking & closing phase 5.0 are provided in the main program, because the second variant is based on exiting the main program at least in those cases in which the vehicle equipment is at all to support DSRC communication in Reference to the received identifier provided.

The sub-programs, for example the sub-program with phases 3.1, 4.1 and 5.1, the sub-program with phases 3.2, 4.2 and 5.2, the sub-program with phases 2.3, 3.3, 4.3 and 5.3 and / or the sub-program with phases 2.4, 3.4 , 4.4 and 5.4 can each be certified separately from one another and, in particular, independently of the main program, without the main program with phases 2.0, 3.0, 4.0 and 5.0 losing certification due to the reloading and re-certification of the sub-programs.

To determine the above-mentioned jump address, be it in the initialization phase 2.0 or in the presentation phase 3.0, the processor 52 can access an index file 7.0 stored in the program memory 53. For example, the jump addresses are stored within this index file 7.0.

• In der Initialisierungsphase 2.0 des Hauptprogramms ist gemäß der ersten Variante die Ausführung eines fahrzeugseitigen Programmteils des Hauptprogramms mit anschließender Präsentationsphase 3.0 des Hauptprogramms bei Empfang des entsprechenden Dienstidentifizierers AID vorgesehen oder die Initiierung der Ausführung eines mit einem entsprechenden Dienstidentifizierer AID der ersten Indexdatei 7.0 verknüpften ersten Unterprogramms 2.3 oder 2.4.
• In der Präsentationsphase 3.0 des Hauptprogramms ist gemäß der zweiten Variante keine Ausführung eines fahrzeugseitigen Programmteils des Hauptprogramms vorgesehen, sondern stattdessen bei Empfang eines Elementidentifizierers EID die Initiierung der Ausführung eines mit einem entsprechenden Elementidentifizierer der zweiten Indexdatei 7.1.

With reference to the flow chart of Fig. 6 a method is described below which comprises both variants of the method according to the invention:

• In the initialization phase 2.0 of the main program, according to the first variant, the execution of a vehicle-side program part of the main program with a subsequent presentation phase 3.0 of the main program upon receipt of the corresponding service identifier AID or the initiation of the execution of a first sub-program 2.3 linked to a corresponding service identifier AID of the first index file 7.0 is provided or 2.4.
• In the presentation phase 3.0 of the main program, according to the second variant, no execution of a vehicle-side program part of the main program is provided, but instead, upon receipt of an element identifier EID, the initiation of the execution of a corresponding element identifier of the second index file 7.1.

Program loader

To add sub-programs to the program memory 53 of the vehicle device 11, a program loading program, or program loader, 8.0 for short, can be provided. One embodiment provides that the program loader 8.0 is executed with a processor that does not necessarily have to be the processor 52 of the DSRC communication module 50, but can, for example, be a processor of an on-board unit (OBU) connected to the DSRC communication module. In response to instructions from the center 13 of the OBE provider via the GSM interface of the vehicle equipment 11, the program loader 8.0, for example, copies or installs the new subprogram received from the center 13 with the instructions and an identifier AID or EID into the program memory 53 and supplements the index file 7.0 or 7.1 to a new reference, for example to a new jump address, to this new subprogram, which is linked to the identifier AID or EID to which this new subprogram is assigned.

In order to supplement the index file with the jump addresses, in particular in such a way that the processor 52 can determine which identifier is assigned which jump address, said program loader 8.0 can be provided which has a Human Machine Interface (HMI) 57 can be operated. In particular, the said, in the Fig. 4 , 5 and 6th schematically shown subroutines and sub-subroutines can be reloaded into the program memory of a main memory without influencing the possibly certified main program or subroutine. Like in the Fig. 4 , 5 and 6th shown schematically, the certification of the main program does not also include a certification of the index file 7.0. In other words, the said jump addresses can be added to the index file 7.0 without the main program being lost in certification.

The added program code of the subroutines can be stored in said program memory 53, for example. The program memory can comprise a main memory for storing the main program. The loaded program code of the subroutines can also be stored in this main memory, for example. The added program code of the subroutines can, however, also be stored in another memory or in another memory part, for example in a memory of a vehicle device that is also included in the vehicle device 11 as is the DSRC communication module 50, the vehicle device processor having the processor 52 DSRC -Communication module 50 is coupled via a communication link. In addition, the DSRC communication module 50 can comprise a main memory (not shown in the figures), which can also be part of the program memory 53 or can be implemented separately therefrom.

Summary presentation

Some ideas of the method presented above for DSRC communication or the vehicle device 11 presented above with the DSRC communication module 50 for performing DSRC communication are to be summarized below:
As has been explained above, in the course of time, with an existing toll system or another payment system, new institutions that also want to participate in the toll system can be added and / or the specifications of existing institutions can change. Specifically, this can result in the fact that new service identifiers AID (and thus new services) and / or new element identifiers EID (and thus, according to exemplary embodiments, new attributes) are exchanged between the beacon 12 and the vehicle device 11. On the one hand, new AIDs can be added, on the other hand, existing services can be adapted or changed, i.e. new EIDs can be added. At this point it should be mentioned that the attributes that can be sent from the vehicle device 11 to the beacon 12 based on one or the other element identifier EID in the presentation phase can also remain the same, and only the attribute data records of the attribute values assigned to the attributes change.

When creating a new AID, as in the Fig. 4 , 5 and 6th shown, a program branch can already be carried out in the existing initialization phase 2.0 upon receipt of the BST in the DSRC communication module 50. The program sequences of existing AIDs of the main program are retained in the initialization phase 2.0 and continue the transaction as part of the main program. If a new AID is added that requires a change in the program flow, the jump address can be stored in index file 7.0 depending on the AID. The jump address indicates where the relevant subroutine can be saved and started.

If, however, it is not a matter of a new service, but merely an adaptation of an already existing service, the initialization phase 2.0 is first run through completely, as explained above, and the program branching only takes place in the context of the presentation phase 3.0. If the program is in this phase and the processor 52 receives an unknown EID at this point, the processor 52 calls the index file 7.0 and uses the index file 7.0 to determine the jump address assigned to the new EID. This jump address then points, for example, to the subroutine with the loaded presentation phase 3.1 or to the subroutine with the reloaded presentation phase 3.2 or to another subroutine. For example, the beacon 12 transmits the EID as part of the presentation phase 3.0, for example with the request message GET STAMPED.request or with the request message GET.request. The program branching out of the main program then takes place at this point if no program part is assigned to the received EID in the main program.

With the program loader 8.0, said subroutines can be added ("reloaded") to the program memory 53 of the vehicle equipment in non-time-critical situations, for example when the vehicle is not moving and has a stable communication link to the central system 13 of the OBE provider. As I said, the addressing takes place for the loaded subroutines for example by means of the appropriately programmed index file 7.0 or 7.1. This addition to the index file 7.0 or 7.1 does not result in a loss of certification of the main program.

For example, when branching out of the initialization phase 2.0 of the main program into a reloaded initialization phase 2.3 or 2.4, a number of parameters customary for transactions are also transferred, for example a so-called logical link control identifier LID.

When branching from the presentation phase 3.0 of the main program into a reloaded presentation phase 3.1 or 3.2, a number of parameters customary for transactions are preferably also transferred, for example the said Logical Link Control Identifier LID.

the Fig. 4 illustrates branches to a total of four subroutines. Of course, more or less than four subroutines can also be provided. If, for example, only a new service identifier AID is added to the main program, then it is sufficient to branch to the sub-program with phases 2.3, 3.3, 4.3 and 5.3. According to the embodiment of Fig. 4 each of the four sub-programs includes its own reloaded receipt phase 4.1, 4.2, 4.3 or 4.4 and its own reloaded tracking & closing phase 5.1, 5.2, 5.3 or 5.4. All tracking & closing phases 5.0 to 5.4 result in a proper conclusion 6 of the DSRC communication.

Contrary to the representation in the Fig. 4 According to exemplary embodiments, it is also possible for a branch to take place between different subroutines. In an exemplary embodiment, the processor 52 executes phase 3.1 and jumps from this into phase 3.2, 3.3 or 3.4 in accordance with the first or second variant presented above. Even during the execution of phases of the reloaded subroutines, situations can arise in which a request from the beacon 12 cannot be served by the further execution of the currently executed subroutine, but a jump to another subroutine may be necessary, this jump corresponding to a the variants presented above can be done.

After the end of the DSRC communication, regardless of whether it took place in accordance with the main program with phases 2.0, 3.0 and 4.0 and 5.0 or with one of the loaded sub-programs, the processor 52 can after the completion of the DSRC communication execute the initialization phase 2.0 of the certified main program again. When passing a next beacon, the procedure for DSRC communication can thus be analogous to the method presented above by way of example.

The processor 52 can be designed to use the main memory for the intermediate storage of data and / or code for the purpose of executing program code of the main program and / or of added program code of the subroutines.

For example, all or on the basis of certain criteria (last used subroutine, mostly used subroutines, subroutines identified by comparing received position data, which are identified with corresponding geographic data, etc.) can have one or more selected subroutines whose storage location is known from the persistent index file , when loading the main program from the program memory 53 into the main memory of the processor 52 or as a result of the execution of a start routine of the main program that precedes the reception readiness routine, can also be loaded from the program memory 53 into the main memory. In this case, the main program creates a temporary index file in the working memory which is first called by the main program when an identifier is received which requests the execution of a subroutine. In this case, the subroutine can be called up and executed much more quickly than if it had to be reloaded from the program memory (53) first. If the received identifier does not match any identifier in the temporary index file, then the persistent index file stored in the program memory 53 is called up and a search is made for a matching identifier.

Claims (16)

1. Method for performing a DSRC communication by means of a vehicle device (11) comprising a DSRC communication module (50), the method comprising:

   - execution of a reception standby routine of a main program, stored in the vehicle device (11), by a processor (52) of the DSRC communication module (50);

   - reception of a request message, comprising an identifier (AID, EID), transmitted by a roadside beacon (12) by a DSRC transceiver (51), which is operatively connected to the processor (52), of the DSRC communication module (50);

   - transmission of a response message comprising a processing result to the roadside beacon (12) by the DSRC transceiver (21),

   wherein the method further comprises, between the reception and transmission:

   - checking, by means of the processor (52), as part of instructions of the main program, whether the received identifier has a vehicle-device-based program part of the main program assigned to it;

   - if the received identifier (AID, EID) has a vehicle-device-based program part of the main program assigned to it:

   execution of the assigned vehicle-device-based program part of the main program by the processor (52) at least to produce the processing result on the basis of the received identifier (AID, EID);

   and wherein the method, if the identifier does not have a vehicle-device-based program part of the main program assigned to it, further comprises:

   a) ascertainment of at least one first subroutine (3.1; 2.3), which is assigned to the received identifier (AID, EID) and stored in the vehicle device (11), that is not part of the main program;

   b) execution of the first subroutine (3.1; 2.3) by the processor (52) at least to produce the processing result on the basis of the received identifier (AID, EID).
2. Method for performing a DSRC communication by means of a vehicle device (11) comprising a DSRC communication module (50), the method comprising:

   - execution of a reception standby routine of a main program, stored in the vehicle device (11), by a processor (52) of the DSRC communication module (50);

   - reception of a request message, comprising an identifier (AID, EID), transmitted by a roadside beacon (12) by a DSRC transceiver (51), which is operatively connected to the processor (52), of the DSRC communication module (50);

   - transmission of a response message comprising a processing result to the roadside beacon (12) by the DSRC transceiver (51),

   wherein the method further comprises, between the reception and transmission:

   - processing of the request message by means of the processor (52) as part of instructions of the main program with

   a) the ascertainment of at least one first or second subroutine (2.3; 2.4; 3.1; 3.2), neither of which is part of the main program, that is assigned to the received identifier (AID, EID) and stored in the vehicle device (11),
   and

   b) either

   i) the execution of the first subroutine (2.3; 3.1), if the identifier (AID, EID) received with the request message corresponds to a first identifier, by the processor (52) at least to produce the processing result on the basis of the received identifier (AID, EID),
   or

   ii) the execution of the second subroutine (2.4; 3.2), if the identifier (AID, EID) received with the request message does not correspond to the first identifier, by the processor (52) at least to produce the processing result on the basis of the received identifier (AID, EID) .
3. Method according to Claim 1 or 2, further comprising: return to a first reception standby routine of an initialization phase (2.0) of the main program after the transmission of the processing result message.
4. Method according to one of the preceding claims, wherein the subroutine (2.3; 2.4; 3.1; 3.2) to be executed is ascertained by means of the processor (52) as part of instructions of the main program on the basis of at least one index file (7.0, 7.1), stored in the vehicle device (11), that contains at least one link to the first subroutine (3.1; 2.3) or to a second subroutine (3.2; 2.4), which link is assigned to the identifier (AID, EID).
5. Method according to Claim 4, wherein the link comprises a jump address that refers to a program memory part of the vehicle device (11) that contains the first subroutine (3.1; 2.3) or the second subroutine (3.2; 2.4) .
6. Method according to one of the preceding claims, wherein the reception standby routine is comprised by an initialization phase (2.0) of the main program, the identifier comprises a service identifier (AID) and the first subroutine (2.3) or a second subroutine (2.4) is assigned to the service identifier (AID), and wherein after step a) and before step b) the initialization phase of the main program (2.0) is left in order to continue the initialization phase by means of the first subroutine (2.3) or the second subroutine (2.4).
7. Method according to one of the preceding claims, wherein
   the request message is received by the DSRC communication module in an initialization phase (2.0) of the main program and contains a beacon service table (BST) that comprises the identifier in the form of a service identifier (AID),
   and wherein
   the response message is transmitted in the initialization phase (2.0) of the main program or of a first or second subroutine (2.3; 2.4) and contains a vehicle service table (VST) that comprises the processing result.
8. Method according to Claim 6 or 7, wherein the method comprises:

   - execution of a reception standby routine of a first subroutine (3.3), stored in the vehicle device (11), by a processor (52) of the DSRC communication module;

   - reception of a request message, comprising an element identifier (EID), transmitted by a roadside beacon (12) by a DSRC transceiver (51), which is operatively connected to the processor (52), of the DSRC communication module (50);

   - transmission of a response message comprising a processing result, which the processor (52) has produced in the course of the processing of the request message on the basis of the received element identifier (EID), to the roadside beacon (12) by the DSRC transceiver (51), wherein the method further comprises, between the reception and transmission:

   - checking, by means of the processor (52), as part of instructions of the first subroutine (3.3), whether the element identifier (EID) has a vehicle-device-based program part of the first subroutine (3.3) assigned to it;

   - if the element identifier (EID) has a vehicle-device-based program part of the first subroutine (3.3) assigned to it: execution of the vehicle-device-based program part of the subroutine (3.3) by the processor (52) at least to produce the processing result;

   - if the element identifier (EID) does not have a vehicle-device-based program part of the subroutine (3.3) assigned to it:

   c) ascertainment of at least one first subsubroutine (3.5), which is assigned to the element identifier (EID) and stored in the vehicle device (11), that is not part of the subroutine (3.3);

   d) execution of the first subsubroutine (3.5) by the processor (52) at least to produce the processing result message.
9. Method according to one of Claims 1 to 5, wherein the reception standby routine is comprised by a presentation phase (3.0) of the main program, the identifier comprises an element identifier and the first subroutine (3.1) or a second subroutine (3.2) is assigned to the element identifier, and wherein the initialization phase (2.0) of the main program is concluded before the execution of the reception standby routine, and wherein after step a) and before step b) the presentation phase (3.0) of the main program is left in order to continue the presentation phase by means of the first subroutine (3.1) or the second subroutine (3.2).
10. Method according to one of the preceding claims, wherein the first subroutine, the second subroutine and/or the first subsubroutine in their/its presentation phase(s) (3.1; 3.2; 3.3; 3.4; 3.5) comprise/comprises an attribute dataset or the processor (52) accesses the first subroutine, the second subroutine or the subsubroutine, on execution thereof, in its presentation phase (3.1; 3.2; 3.3; 3.4; 3.5), and wherein the processing result message is created on the basis of the attribute dataset and/or comprises the attribute dataset.
11. Method according to Claim 10, further comprising:

    performance of a DSRC transaction on the basis of the attribute dataset,

    wherein the DSRC transaction comprises:

    - provision of at least one pre-stored attribute, so that the provided attribute can be read by means of the beacon (12); and/or

    - reception of a new attribute from the beacon (12) and filing of the attribute in the program memory of the vehicle device (11).
12. Method according to one of the preceding claims, wherein the performance of the DSRC communication is compliant with at least one of the following standards: EN 15509, EN ISO 14906, Cen ISO/TS 12813, Cen ISO/TS 13141, EN 12834.
13. Method according to one of the preceding claims, further comprising:

    - reception of a subroutine (2.3, 2.4, 3.1, 3.2) and an identifier (AID, EID) by means of a mobile radio communication module of the vehicle device (11),

    - execution of a program loading program (8.0) with

    a) filing of the subroutine (2.3, 2.4, 3.1, 3.2) in the program memory (53),

    b) addition of a reference, linked to the identifier (AID, EID), to the subroutine (2.3, 2.4, 3.1, 3.2) in an index file (7.0, 7.1),

    - use of the index file (7.0, 7.1) to ascertain the first or second subroutine (2.3, 2.4, 3.1, 3.2) assigned to the received identifier (AID, EID).
14. Vehicle device (11) having a DSRC communication module (50) that comprises a DSRC transceiver (51) and a processor (52), and having at least one program memory (53), wherein the processor (52) is operatively connected to the DSRC transceiver (51) and to the program memory (53), and wherein the program memory (53) comprises a main program having a reception standby routine, execution of which configures the processor (52) to

    - receive, by means of the DSRC transceiver (51), a request message, comprising an identifier (AID, EID), transmitted by a roadside beacon (12);
    wherein the program memory (53) comprises at least one first subroutine (2.3, 3.1) that is not part of the main program,
    wherein both the execution of the subroutine and the execution of a vehicle-device-based program part of the main program further configure the processor (52) to

    - produce a processing result on the basis of the received identifier
    and to

    - transmit a response message comprising the processing result to the roadside beacon (12) by means of the DSRC transceiver (51);
    wherein the main program comprises instructions that configure the processor to

    - check whether the received identifier (AID, EID) has the vehicle-device-based program part of the main program assigned to it;
    and, if the received identifier (AID, EID) has the vehicle-device-based program part of the main program assigned to it, to

    - execute the vehicle-device-based program part of the main program,
    or, if the received identifier (AID, EID) does not have a vehicle-device-based program part of the main program assigned to it, to

    a) ascertain the first subroutine (2.3, 3.1) assigned to the received identifier (AID, EID);

    b) execute the first subroutine (2.3, 3.1).
15. Vehicle device (11) having a DSRC communication module (50) that comprises at least one DSRC transceiver (51) and at least one processor (52), and having at least one program memory (53), wherein the processor (52) is operatively connected to the DSRC transceiver (51) and to the program memory (53) and wherein the program memory (53) comprises a main program having a reception standby routine, execution of which configures the processor (52) to

    - receive, by means of the DSRC transceiver (51), a request message, comprising an identifier (AID, EID), transmitted by a roadside beacon (12);
    wherein the program memory (53) comprises a first subroutine (2.3, 3.1) and at least one second subroutine (2.4, 3.2), neither of which is part of the main program, wherein both the execution of the first subroutine (2.3, 3.1) and the execution of the second subroutine (2.4, 3.2) further configure the processor (52) to

    - produce a processing result on the basis of the received identifier (AID, EID)
    and to

    - transmit a response message comprising the processing result to the roadside beacon (12) by means of the DSRC transceiver (51);
    wherein the main program comprises instructions that configure the processor (52) to

    - a) ascertain whether the received identifier (AID, EID) has the first or the second subroutine (2.3, 3.1, 2.4, 3.2) assigned to it;
    and to

    - b) either

    i) execute the first subroutine (2.3, 3.1), if the received identifier (AID, EID) corresponds to a first identifier,
    or

    ii) execute the second subroutine (2.4, 3.2), if the received identifier (AID, EID) does not correspond to the first identifier.
16. Vehicle device (11) according to Claim 14 or 15, comprising a mobile radio communication module, which is connected to a processor of the vehicle device (11), and a memory, which contains a program loading program (8.0), wherein the processor is configured to be instructed by a message received by means of the mobile radio communication module to execute the program loading program (8.0), execution of which configures the processor to file a subroutine (2.3, 2.4, 3.1, 3.2), which is received by means of the mobile radio communication module and linked to an identifier (AID, EID), in the program memory (53) of the vehicle device and to add a reference, linked to the identifier (AID, EID), to the subroutine (2.3, 2.4, 3.1, 3.2) to an index file (7.0, 7.1), for the reading of which reference the processor (52) of the DSRC communication module (50) is configured by the execution of instructions of the main program to ascertain the first or second subroutine (2.3, 2.4, 3.1, 3.2) assigned to the received identifier (AID, EID) .

Images