EP3038062B1 - Procédé et dispositifs de véhicule pour communication DSRC - Google Patents

Procédé et dispositifs de véhicule pour communication DSRC Download PDF

Info

Publication number
EP3038062B1
EP3038062B1 EP14200173.4A EP14200173A EP3038062B1 EP 3038062 B1 EP3038062 B1 EP 3038062B1 EP 14200173 A EP14200173 A EP 14200173A EP 3038062 B1 EP3038062 B1 EP 3038062B1
Authority
EP
European Patent Office
Prior art keywords
program
subroutine
identifier
processor
eid
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP14200173.4A
Other languages
German (de)
English (en)
Other versions
EP3038062A1 (fr
Inventor
Frank Lukanek
Ullrich Krämer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toll Collect GmbH
Original Assignee
Toll Collect GmbH
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 Toll Collect GmbH filed Critical Toll Collect GmbH
Priority to EP14200173.4A priority Critical patent/EP3038062B1/fr
Publication of EP3038062A1 publication Critical patent/EP3038062A1/fr
Application granted granted Critical
Publication of EP3038062B1 publication Critical patent/EP3038062B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/06—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems
    • G07B15/063—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems using wireless information transmission between the vehicle and a fixed station

Definitions

  • the present invention relates to methods and vehicle devices for so-called dedicated short range communication, hereinafter referred to as DSRC communication.
  • 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.
  • 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.
  • OBE onboard entity
  • RSE roadside entity
  • DSRC communication 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.
  • 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.
  • 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.
  • 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.
  • OBU mobile detection unit
  • 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).
  • 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.
  • a method for performing DSRC communication by means of a vehicle device comprising a DSRC communication module 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
  • a method for performing DSRC communication by means of a vehicle device comprising a DSRC communication module 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
  • 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
  • a vehicle device with a DSRC communication module 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;
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • no index file is mandatory for checking whether the received identifier is assigned to the first subroutine.
  • 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.
  • 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 sub
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • OBE vehicle device
  • RSE beacon
  • 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.
  • 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.
  • vehicle identifier e.g. vehicle license plate number of the vehicle and / or insurance number of the vehicle
  • 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.
  • 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.
  • OBE-ID e.g.
  • 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.
  • 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.
  • OBE vehicle equipment 11
  • 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).
  • 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.
  • 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.
  • 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.
  • the vehicle device 11 shown comprises a DSRC communication module 50 which is designed for communication with a beacon 12.
  • the DSRC communication module 50 comprises a DSRC transceiver 51, which is designed to transmit and receive data in accordance with the DSRC communication.
  • 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.
  • 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.
  • OBU on-board unit, also not shown
  • GNSS global navigation satellite system
  • 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).
  • the vehicle device 11 is occasionally also referred to as “OBE” for short.
  • FIG Fig. 3 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.
  • RSE - left side the beacon on the one hand
  • OBE - right side the vehicle equipment
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • BST beacon service table
  • 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).
  • AID application identifier
  • EID element identifier
  • 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.
  • the vehicle device 11 can receive this request message by means of the DSRC transceiver 51.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the beacon 12 uses 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.
  • the DSRC communication can be based on the EID determined in the initialization phase 2.0.
  • 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.
  • 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 can in particular relate to a payment service.
  • 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.
  • 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.
  • the vehicle equipment OBE can be authenticated in the presentation phase 3.0.
  • the beacon 12 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.
  • 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.
  • 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.
  • 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.
  • An exemplary DSRC communication includes, in particular, a so-called CARDME transaction.
  • 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
  • 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.
  • 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.
  • the DSRC communication starts on the part of the vehicle device 11 through a program entry 1 into the initialization phase 2.0.
  • 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.
  • 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.
  • 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.
  • 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.
  • the processor 52 then sends the processing result back to the beacon 12 by means of the DSRC transceiver 51.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • AID Application Identifier
  • the EN ISO 14906 standard provides that 31 different AIDs can be addressed.
  • the roadside beacon 12 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • EID element identifiers
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the processor 52 can access an index file 7.0 stored in the program memory 53.
  • the jump addresses are stored within this index file 7.0.
  • a program loading program, or program loader, 8.0 for short, can be provided.
  • 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.
  • OBU on-board unit
  • the program loader 8.0 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.
  • said program loader 8.0 can be provided which has a Human Machine Interface (HMI) 57 can be operated.
  • HMI Human Machine Interface
  • 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.
  • the certification of the main program does not also include a certification of the index file 7.0.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a number of parameters customary for transactions are also transferred, for example a so-called 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.
  • 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.
  • the processor 52 can after the completion of the DSRC communication execute the initialization phase 2.0 of the certified main program again.
  • 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.
  • all or on the basis of certain criteria 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)
  • Traffic Control Systems (AREA)

Claims (16)

  1. Procédé pour effectuer une communication DSRC au moyen d'un dispositif de véhicule (11), comprenant un module de communication DSRC (50), le procédé comprenant :
    - l'exécution, par un processeur (52) du module de communication DSRC (50), d'une routine de veille de réception d'un programme principal stocké dans le dispositif de véhicule (11) ;
    - la réception, par un émetteur-récepteur DSRC (51) du module de communication DSRC (50) couplé fonctionnellement au processeur (52), d'un message de demande transmis par une balise routière (12) et comprenant un identifiant (AID, EID) ;
    - la transmission, par l'émetteur-récepteur DSRC (51) à la balise routière (12), d'un message de réponse comprenant un résultat de traitement,
    dans lequel le procédé comprend en outre, entre la réception et l'émission :
    - la vérification, au moyen du processeur (52), dans le cadre d'instructions du programme principal, du fait de savoir si une partie de programme côté dispositif de véhicule du programme principal est associée à l'identifiant reçu ;
    - si une partie de programme côté dispositif de véhicule du programme principal est associée à l'identifiant reçu (AID, EID) :
    l'exécution de la partie de programme côté dispositif de véhicule associé du programme principal par le processeur (52) au moins pour générer le résultat de traitement en fonction de l'identifiant reçu (AID, EID) ;
    et dans lequel le procédé comprend en outre, si l'identifiant n'est pas associé à une partie de programme côté dispositif de véhicule du programme principal :
    a) la détermination d'au moins un premier sous-programme (3.1 ; 2.3) associé à l'identifiant reçu (AID, EID), stocké dans le dispositif de véhicule (11), et qui ne fait pas partie du programme principal ;
    b) l'exécution du premier sous-programme (3.1 ; 2.3) par le processeur (52) au moins pour générer le résultat de traitement en fonction de l'identifiant reçu (AID, EID) .
  2. Procédé pour effectuer une communication DSRC au moyen d'un dispositif de véhicule (11) comprenant un module de communication DSRC (50), le procédé comprenant :
    - l'exécution, par un processeur (52) du module de communication DSRC (50), d'une routine de veille de réception d'un programme principal stocké dans le dispositif de véhicule (11) ;
    - la réception, par un émetteur-récepteur DSRC (51) du module de communication DSRC (50) couplé fonctionnellement au processeur (52), d'un message de demande transmis par une balise routière (12) et comprenant un identifiant (AID, EID) ;
    - la transmission, par l'émetteur-récepteur DSRC (51) à la balise routière (12), d'un message de réponse comprenant un résultat de traitement,
    dans lequel le procédé comprend en outre, entre la réception et l'émission :
    - le traitement du message de demande au moyen du processeur (52) dans le cadre d'instructions du programme principal, comprenant
    a) la détermination d'au moins un premier ou un second sous-programme (2.3 ; 2.4 ; 3.1 ; 3.2) associé à l'identifiant reçu (AID, EID), stocké dans le dispositif de véhicule (11), et dont aucun ne fait partie du programme principal,
    et
    b) soit :
    i) l'exécution du premier sous-programme (2.3 ; 3.1), lorsque l'identifiant (AID, EID) reçu avec le message de demande correspond à un premier identifiant, par le processeur (52) au moins pour générer le résultat de traitement en fonction de l'identifiant reçu (AID, EID), soit
    ii) l'exécution du second sous-programme (2.4 ; 3.2), lorsque l'identifiant (AID, EID) reçu avec le message de demande ne correspond pas au premier identifiant, par le processeur (52) au moins pour générer le résultat de traitement en fonction de l'identifiant reçu (AID, EID).
  3. Procédé selon la revendication 1 ou 2, comprenant en outre : le retour dans une première routine de veille de réception d'une phase d'initialisation (2.0) du programme principal après l'envoi du message de résultat de traitement.
  4. Procédé selon l'une quelconque des revendications précédentes, dans lequel le sous-programme (2.3 ; 2.4 ; 3.1 ; 3.2) à exécuter est déterminé au moyen du processeur (52) dans le cadre d'instructions du programme principal sur la base d'au moins un fichier d'index (7.0, 7.1) stocké dans le dispositif de véhicule (11) et contenant au moins une combinaison, associée à l'identifiant (AID, EID), avec le premier sous-programme (3.1 ; 2.3) ou un second sous-programme (3.2 ; 2.4).
  5. Procédé selon la revendication 4, dans lequel la combinaison comprend une adresse de saut se référant à une partie de mémoire de programme du dispositif de véhicule (11), qui contient le premier sous-programme (3.1 ; 2.3) ou le second sous-programme (3.2 ; 2.4).
  6. Procédé selon l'une quelconque des revendications précédentes, dans lequel la routine de veille de réception est comprise dans une phase d'initialisation (2.0) du programme principal, l'identifiant comprend un identifiant de service (AID), et le premier sous-programme (2.3) ou un second sous-programme (2.4) est associé à l'identifiant de service (AID), et dans lequel, après l'étape a) et avant l'étape b), la phase d'initialisation du programme principal (2.0) est quittée afin de poursuivre la phase d'initialisation au moyen du premier sous-programme (2.3) ou du second sous-programme (2.4) .
  7. Procédé selon l'une quelconque des revendications précédentes, dans lequel
    le message de demande est reçu lors d'une phase d'initialisation (2.0) du programme principal en provenance du module de communication DSRC et contient une table de service de balises (BST) qui comprend l'identifiant sous la forme d'un identifiant de service (AID), et dans lequel
    le message de réponse est envoyé lors de la phase d'initialisation (2.0) du programme principal ou d'un premier ou d'un second sous-programme (2.3 ; 2.4) et contient une table de service de véhicule (VST) comprenant le résultat de traitement.
  8. Procédé selon la revendication 6 ou 7, dans lequel le procédé comprend :
    - l'exécution, par un processeur (52) du module de communication DSRC, d'une routine de veille de réception d'un premier sous-programme (3.3) stocké dans le dispositif de véhicule (11) ;
    - la réception, par un émetteur-récepteur DSRC (51) du module de communication DSRC (50) couplé fonctionnellement au processeur (52), d'un message de demande transmis par une balise routière (12) et comprenant un identifiant d'élément (EID) ;
    - la transmission, par l'émetteur-récepteur DSRC (51) à la balise routière (12), d'un message de réponse comprenant un résultat de traitement généré par le processeur (52) au cours du traitement du message de demande en fonction de l'identifiant d'élément (EID) reçu, dans lequel le procédé comprend en outre, entre la réception et l'émission :
    - la vérification, au moyen du processeur (52), dans le cadre d'instructions du premier sous-programme (3.3), du fait de savoir si une partie de programme côté dispositif de véhicule du premier sous-programme (3.3) est associée à l'identifiant d'élément (EID) ;
    - si une partie de programme côté dispositif de véhicule du premier sous-programme (3.3) est associée à l'identifiant d'élément (EID) : l'exécution de la partie de programme côté dispositif de véhicule du sous-programme (3.3) par le processeur (52) au moins pour générer le résultat de traitement ;
    - si l'identifiant d'élément (EID) n'est pas associé à une partie du programme côté dispositif de véhicule du sous-programme (3.3) :
    c) la détermination d'au moins un premier sous-sous-programme (3.5) associé à l'identifiant d'élément (EID), stocké dans l'équipement côté dispositif de véhicule (11), et qui ne fait pas partie du sous-sous-programme (3.3) ;
    d) l'exécution du premier sous-sous-programme (3.5) par le processeur (52) au moins pour générer le message de résultat de traitement.
  9. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel la routine de veille de réception est comprise dans une phase de présentation (3.0) du programme principal, l'identifiant comprend un identifiant d'élément, et le premier sous-programme (3.1) ou un second sous-programme (3.2) est associé à l'identifiant d'élément, et dans lequel la phase d'initialisation (2.0) du programme principal est achevée avant l'exécution de la routine de veille de réception, et dans lequel, après l'étape a) et avant l'étape b), la phase de présentation (3.0) du programme principal est quittée afin de poursuivre la phase de présentation au moyen du premier sous-programme (3.1) ou du second sous-programme (3.2).
  10. Procédé selon l'une quelconque des revendications précédentes, dans lequel le premier sous-programme, le second sous-programme et/ou le premier sous-sous-programme dans sa/leurs phase(s) de présentation (3.1 ; 3.2 ; 3.3 ; 3.4 ; 3.5) comprend/comprennent un ensemble de données d'attributs ou est accédé par le processeur (52) lors de l'exécution du premier sous-programme, du second sous-programme ou du sous-sous-programme dans sa/leurs phase(s) de présentation (3.1 ; 3.2 ; 3.3 ; 3.4 ; 3.5), et dans lequel le message de résultat de traitement est créé en fonction de l'ensemble de données d'attributs et/ou comprend l'ensemble de données d'attributs.
  11. Procédé selon la revendication 10, comprenant en outre : l'exécution d'une transaction DSRC basée sur l'enregistrement d'attribut,
    dans lequel la transaction DSRC comprend :
    - la fourniture d'au moins un attribut pré-stocké de manière à ce que l'attribut fourni puisse être lu au moyen de la balise (12) ; et/ou
    - la réception d'un nouvel attribut de la balise (12) et le stockage de l'attribut dans la mémoire de programme du dispositif de véhicule (11).
  12. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'exécution de la communication DSRC est conforme à au moins l'une des normes suivantes : EN 15509, EN ISO 14906, Cen ISO/TS 12813, Cen ISO/TS 13141, EN 12834.
  13. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre :
    - la réception d'un sous-programme (2.3, 2.4, 3.1, 3.2) et d'un identifiant (AID, EID) au moyen d'un module de communication mobile du dispositif de véhicule (11) ;
    - l'exécution d'un programme de chargement de programme (8.0), comprenant
    a) le stockage du sous-programme (2.3, 2.4, 3.1, 3.2) dans la mémoire de programme (53),
    b) l'ajout d'une référence combinée à l'identifiant (AID, EID) et pointant vers le sous-programme (2.3, 2.4, 3.1, 3.2) dans un fichier d'index (7.0, 7.1.)
    - l'utilisation du fichier d'index (7.0, 7.1) pour déterminer le premier ou le second sous-programme (2.3, 2.4, 3.1, 3.2) associé à l'identifiant reçu (AID, EID).
  14. Dispositif de véhicule (11) comprenant un module de communication DSRC (50), qui comprend un émetteur-récepteur DSRC (51) et un processeur (52), et au moins une mémoire de programme (53), dans lequel le processeur (52) est couplé fonctionnellement à l'émetteur-récepteur DSRC (51) et à la mémoire de programme (53), et dans lequel la mémoire de programme (53) comprend un programme principal comportant une routine de veille de réception, dont l'exécution configure le processeur (52) pour
    - la réception, au moyen de l'émetteur-récepteur DSRC (51), d'un message de demande transmis par une balise routière (12) et comprenant un identifiant (AID, EID) ; dans lequel la mémoire de programme (53) comprend au moins un premier sous-programme (2.3, 3.1) qui ne fait pas partie du programme principal,
    dans lequel l'exécution du sous-programme et l'exécution d'une partie de programme côté dispositif de véhicule du programme principal configurent toutes deux en outre le processeur (52) pour
    - la génération d'un résultat de traitement en fonction de l'identifiant reçu,
    et pour
    - la transmission d'un message de réponse comprenant le résultat de traitement au moyen de l'émetteur-récepteur DSRC (51) à la balise routière (12) ;
    dans lequel le programme principal comprend des instructions qui configurent le processeur pour
    - la vérification du fait de savoir si l'identifiant reçu (AID, EID) est associé à la partie de programme côté dispositif de véhicule du programme principal ;
    et si l'identifiant reçu (AID, EID) est associé à la partie de programme côté dispositif de véhicule du programme principal, pour
    - l'exécution de la partie de programme côté dispositif de véhicule du programme principal ou, si aucune partie de programme côté dispositif de véhicule du programme principal n'est associée à l'identifiant reçu (AID, EID), pour
    a) la détermination du premier sous-programme (2.3, 3.1) associé à l'identifiant reçu (AID, EID) ;
    b) l'exécution du premier sous-programme (2.3, 3.1).
  15. Dispositif de véhicule (11) comprenant un module de communication DSRC (50), qui comprend au moins un émetteur-récepteur DSRC (51) et au moins un processeur (52), et au moins une mémoire de programme (53), dans lequel le processeur (52) est couplé fonctionnellement à l'émetteur-récepteur DSRC (51) et à la mémoire de programme (53), et dans lequel la mémoire de programme (53) comprend un programme principal comportant une routine de veille de réception, dont l'exécution configure le processeur (52) pour
    - la réception, au moyen de l'émetteur-récepteur DSRC (51), d'un message de demande transmis par une balise routière (12) et comprenant un identifiant (AID, EID) ; dans lequel la mémoire de programme (53) comprend un premier sous-programme (2.3, 3.1) et au moins un second sous-programme (2.4, 3.2), dont aucun ne fait partie du programme principal,
    dans lequel l'exécution du premier sous-programme (2.3, 3.1) et l'exécution du second sous-programme (2.4, 3.2) configurent en outre le processeur (52) pour
    - la génération d'un résultat de traitement en fonction de l'identifiant reçu (AID, EID)
    et pour
    - la transmission d'un message de réponse comprenant le résultat de traitement au moyen de l'émetteur-récepteur DSRC (51) à la balise routière (12) ;
    dans lequel le programme principal comprend des instructions qui configurent le processeur (52) pour
    a) la détermination du fait de savoir si le premier ou le second sous-programme (2.3, 3.1, 2.4, 3.2) est associé à l'identifiant reçu (AID, EID) ;
    et pour
    b) soit
    i) l'exécution du premier sous-programme (2.3, 3.1) si l'identifiant reçu (AID, EID) correspond à un premier identifiant,
    soit
    ii) l'exécution du second sous-programme (2.4, 3.2) si l'identifiant reçu (AID, EID) ne correspond pas au premier identifiant.
  16. Dispositif de véhicule (11) selon la revendication 14 ou 15, comprenant un module de communication mobile couplé à un processeur du dispositif de véhicule (11) et une mémoire qui contient un programme de chargement de programme (8.0),
    dans lequel le processeur est configuré pour recevoir l'instruction d'exécuter le programme de chargement de programme (8.0) par un message reçu au moyen du module de communication mobile, dont l'exécution configure le processeur pour le stockage d'un sous-programme (2.3, 2.4, 3.1, 3.2) reçu au moyen du module de communication mobile et combiné à un identifiant (AID, EID), et pour l'ajout d'une référence combinée à l'identifiant (AID, EID) et pointant vers le sous-programme (2.3, 2.4, 3.1, 3.2) dans un fichier d'index (7.0, 7.1.), que le processeur (52) du module de communication DSRC (50) est configuré pour lire par l'exécution d'instructions du programme principal pour déterminer le premier ou le second sous-programme (2.3, 2.4, 3.1, 3.2) associée à l'identifiant reçu (AID, EID).
EP14200173.4A 2014-12-23 2014-12-23 Procédé et dispositifs de véhicule pour communication DSRC Active EP3038062B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP14200173.4A EP3038062B1 (fr) 2014-12-23 2014-12-23 Procédé et dispositifs de véhicule pour communication DSRC

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP14200173.4A EP3038062B1 (fr) 2014-12-23 2014-12-23 Procédé et dispositifs de véhicule pour communication DSRC

Publications (2)

Publication Number Publication Date
EP3038062A1 EP3038062A1 (fr) 2016-06-29
EP3038062B1 true EP3038062B1 (fr) 2021-09-01

Family

ID=52134047

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14200173.4A Active EP3038062B1 (fr) 2014-12-23 2014-12-23 Procédé et dispositifs de véhicule pour communication DSRC

Country Status (1)

Country Link
EP (1) EP3038062B1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111599168B (zh) * 2020-04-01 2021-12-21 广东中科臻恒信息技术有限公司 基于路侧单元的道路交通信息采集方法、设备、存储介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10228401A1 (de) * 2002-06-25 2004-01-22 Daimlerchrysler Ag Vorrichtung zur Bestimmung von Benutzungsgebühren und Gebührenerfassungssystem
DE102004038170B3 (de) * 2004-08-06 2006-03-16 Daimlerchrysler Ag Verfahren, fahrzeugseitiges Endgerät und fahrzeugexterne Zentrale zur Erhebung von Straßenbenutzungsgebühren
EP1630747A3 (fr) * 2004-08-31 2006-11-02 Fela Management AG Système et méthode de perception des droits de péage
DE102005055835A1 (de) * 2005-11-23 2007-05-24 Siemens Ag Verfahren zum Betreiben einer mobilen Detektionseinheit (OBU) in Geltungsbereichen unterschiedlicher Mauterfassungssysteme
ES2389246T3 (es) 2010-01-29 2012-10-24 Kapsch Trafficcom Ag Procedimiento para la comunicación DSRC
PT2602767E (pt) 2011-12-05 2014-02-17 Kapsch Trafficcom Ag Processo e unidade a bordo para a sinalização de operações de portagem num sistema de portagem rodoviária

Also Published As

Publication number Publication date
EP3038062A1 (fr) 2016-06-29

Similar Documents

Publication Publication Date Title
EP2833329B1 (fr) Procédé et système destinés à améliorer un processus de stationnement payant de véhicule dans une installation de parking, programme informatique et produit-programme informatique
EP2328119A1 (fr) Système de billetterie
DE102016209682A1 (de) Verfahren zur Aktualisierung einer Software eines Kraftfahrzeuges, Aktualisierungsvorrichtung und Übertragungssystem
EP2913989B1 (fr) Liaison d'un terminal à un dispositif mobile pour l'attribution de frais
WO2006105754A1 (fr) Procede et dispositif d'enregistrement automatique de trajet
EP3695192A1 (fr) Procédé pour cartographier un tronçon de route
EP2994890B1 (fr) Procédé et dispositif de fourniture de données pour la perception de péage et système de péage
DE102005058033A1 (de) Verfahren zur Überprüfung einer Benutzungsberechtigung
EP3038062B1 (fr) Procédé et dispositifs de véhicule pour communication DSRC
DE102013008373A1 (de) Verfahren und System zum Bereitstellen von Informationen über Parkgebühren auf einem gebührenpflichtigen Parkplatz
DE102015203929A1 (de) Aktualisierung von Kartendaten einer Navigationsvorrichtung für Fahrzeuge
EP3242206A1 (fr) Procede de mise a jour de la configuration d'un dispositif de vehicule, dispositif de vehicule, dispositif de traitement de donnees central et systeme de peage
DE102019100440A1 (de) Verfahren und vorrichtung für verwaltete fahrzeugmautzahlungen
DE102016217890A1 (de) Verfahren und Vorrichtung zum Verwenden eines elektronischen Führerscheines
WO2017220307A1 (fr) Mise à jour d'une carte numérique
EP3242205A1 (fr) Procede de mise a jour de la configuration d'un dispositif de vehicule, dispositif de vehicule, dispositif de traitement de donnees central et systeme de peage
DE202014106268U1 (de) Fahrzeugeinrichtungen zur DSRC-Kommunikation
EP1702199B1 (fr) Mise en service d'une application chez un client mobile
EP3211605B1 (fr) Dispositif de véhicule, système, dispositif coté route et procédé d'exécution d'au moins une transaction
EP3188133B1 (fr) Dispositif de traitement de donnees de position et systeme de peage et procede de fonctionnement d'un dispositif de traitement de donnees de position et d'un systeme de peage
DE102016209684A1 (de) Verfahren zur Aktualisierung einer Software eines Landfahrzeuges, Aktualisierungsvorrichtung und Übertragungssystem
EP2059916B1 (fr) Terminal mobile pour un système d'information routière et procédé pour activer un dispositif de contrôle d'accès dans un terminal mobile
EP2242024B1 (fr) Procédé, composants et systèmes de production de transactions de péage
EP3346451B1 (fr) Procédé destinés au suivi de véhicules assujettis au péage dans un système de péage et un système de péage correspondant
DE102021121896A1 (de) Anpassen einer einen Ladevorgang betreffenden Eigenschaftsinformation

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20161213

RBV Designated contracting states (corrected)

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

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20181008

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20210303

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

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

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

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

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

Ref country code: AT

Ref legal event code: REF

Ref document number: 1427025

Country of ref document: AT

Kind code of ref document: T

Effective date: 20210915

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502014015841

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20210901

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211201

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211201

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20211202

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220101

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220103

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 502014015841

Country of ref document: DE

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

26N No opposition filed

Effective date: 20220602

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20211223

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20211223

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20141223

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20231207

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20231220

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20231219

Year of fee payment: 10

Ref country code: DE

Payment date: 20231214

Year of fee payment: 10

Ref country code: AT

Payment date: 20231214

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: BE

Payment date: 20231218

Year of fee payment: 10

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20210901

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: CH

Payment date: 20240110

Year of fee payment: 10