WO2015144887A2 - Computerimplementiertes verfahren zur implementierung einer v2x-anwendung und diesbezügliche v2x-blöcke für eine graphische modellierungsumgebung - Google Patents

Computerimplementiertes verfahren zur implementierung einer v2x-anwendung und diesbezügliche v2x-blöcke für eine graphische modellierungsumgebung Download PDF

Info

Publication number
WO2015144887A2
WO2015144887A2 PCT/EP2015/056731 EP2015056731W WO2015144887A2 WO 2015144887 A2 WO2015144887 A2 WO 2015144887A2 EP 2015056731 W EP2015056731 W EP 2015056731W WO 2015144887 A2 WO2015144887 A2 WO 2015144887A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
block
interface
communication
application
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.)
Ceased
Application number
PCT/EP2015/056731
Other languages
English (en)
French (fr)
Other versions
WO2015144887A3 (de
Inventor
André Rolfsmeier
Gregor Hordys
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.)
Dspace GmbH
Dspace Digital Signal Processing and Control Engineering GmbH
Original Assignee
Dspace GmbH
Dspace Digital Signal Processing and Control Engineering 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 Dspace GmbH, Dspace Digital Signal Processing and Control Engineering GmbH filed Critical Dspace GmbH
Priority to DE112015001479.9T priority Critical patent/DE112015001479A5/de
Priority to JP2017501493A priority patent/JP6602837B2/ja
Priority to CN201580012411.5A priority patent/CN106104471A/zh
Publication of WO2015144887A2 publication Critical patent/WO2015144887A2/de
Publication of WO2015144887A3 publication Critical patent/WO2015144887A3/de
Priority to US15/265,883 priority patent/US10805779B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/35—Creation or generation of source code model driven
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/38—Transceivers, i.e. devices in which transmitter and receiver form a structural unit and in which at least one part is used for functions of transmitting and receiving
    • H04B1/3822—Transceivers, i.e. devices in which transmitter and receiver form a structural unit and in which at least one part is used for functions of transmitting and receiving specially adapted for use in vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Definitions

  • the invention relates to a computer-implemented method for implementing a V2X application on a target hardware with a radio adapter, wherein the V2X application is modeled with a graphical modeling environment in the form of a block diagram.
  • the invention further relates to various blocks for use in a graphical modeling environment with which a V2X application can be modeled and implemented.
  • control-technical functionality is not to be understood narrowly in the system-theoretical sense, meaning any purposeful influence on a technical process connected to the control unit. This can also be merely the processing and / or fusion of sensor data, for example environmental sensors.
  • control-technical functionality is initially abstracted in the context of offline simulations - no connection to the real process, no real-time requirement - represented by a mathematical model, usually with block diagrams both the control and control aspect as well as the influencing technical-physical process mathematically simulated and simulated using numerical methods.
  • control technology functionality is converted into program code and implemented on a target hardware, which usually differs significantly from the later used production ECU.
  • the target hardware is usually more powerful than mass-produced ECUs so that when testing the control functionality to be implemented, it is at least ensured that the hardware is not a limiting factor in the design.
  • the instrumented target hardware is tested in any case in connection with the technical process to be influenced.
  • the target hardware does not necessarily differ from the hardware on which the graphical modeling environment operates and / or translates into an executable V2X program; In this case, the transfer to the target hardware is then conceivably short, the program only has to be loaded and executed.
  • the target hardware may therefore also be a PC, including the PC running the modeling environment and / or translating the model / block diagram into an executable program.
  • the control algorithm to be implemented is generated for this target hardware, whereby the mass-produced ECU is not initially tested in connection with the real physical process but with a simulated process environment in the context of a hardware process.
  • in-the-loop test HIL test
  • the target hardware in the form of the production control unit is tested in the real physical process, in the present case in the motor vehicle, whereby adjustments may still be made in the parameterization.
  • program code can be stored in blocks, for example C / C ++ or C # code.
  • block-diagram-based development environments include Simulink (The MathWorks), ConfigurationDesk (dSPACE), ADTF (Automotive Data and Time-Triggered Framework, Elektrobit), and TMaps (Real-Time Multisensor Advanced Prototyping Software, Intempora).
  • V2X vehicle
  • V2V vehicle
  • V2Infrastructure immobile communication partners
  • the vehicles may be, for example, road vehicles, so that in this Case of Car2X applications can be talked about.
  • the environment can be similar vehicles, but also other road users (eg vulnerable road users such as pedestrians, bicycles, wheelchairs).
  • the environment may also consist of other objects and means of communication, eg. For example, backend servers in the cloud.
  • mapping of such a V2X communication with the elementary operations of a graphical modeling environment in each case of modeling a V2X application is arbitrarily complicated and expensive, so that the present invention is based on the object, a computer-implemented method for implementing a V2X application on a target hardware which reduces the implementation effort.
  • the above-identified object is initially achieved by a computer-implemented method for implementing a V2X application on a target hardware with a radio adapter, wherein the V2X application is modeled with a graphical modeling environment in the form of a block diagram and the block diagram is converted into a V2X executable on the target hardware.
  • Translated program and the V2X program is transferred to the target hardware and executed there, wherein the creation of the block diagram, a V2X communication block is used, which has at least one radio adapter interface, by means of which data between the wireless adapter and the V2X communication block are exchanged.
  • This method is conceptually independent of certain communication standards, protocols and specific definitions and implementations of physical layers.
  • the method can be implemented with virtually any standard and adapted to any standards.
  • all the functionality is mapped to a single V2X communication block in the block diagram.
  • different functions can also be distributed to several V2X communication blocks; This may be advantageous for reasons of clarity, for example.
  • the result of the method according to the invention is therefore a target hardware on which a V2X application is executed, wherein the V2X communication block used according to the invention automatically ensures that the target hardware comprising a radio adapter can readily use the radio adapter, in particular without a response of the radio adapter to model and address self-explanatory elementary operations; This achieves a considerable simplification for the realization of V2X applications.
  • Any radio standard can be realized, ie any wireless communication technology. It can be a WLAN application (eg in residential buildings, warehouses), mobile radio solutions are conceivable (GSM, CDMA, GPRS, LTE, applications on roads, in the airspace), but also RFID applications could be included (eg in residential buildings, hospitals, warehouses, dispatch centers etc.), this depends very much on the specific application.
  • the target hardware may itself comprise the radio adapter in an integrated hardware solution, but the target hardware may also be connected to a radio adapter via a separately implemented hardware interface. If it is said that the block diagram created with the graphical modeling environment is translated into a V2X program executable on the target hardware, then this program may be a program executable on a processor / microcontroller, but it may also be is a hardware description that provides a circuit structure with "hardwired" functionality. Data can be transmitted (send) via the radio adapter interface in the direction of the radio adapter; it is just as possible for the radio adapter to direct (receive) data in the direction of the remaining target hardware.
  • V2X communication block exchanges data with an application unit via at least one application interface, wherein the application unit can in particular be part of the block diagram.
  • the user of the method in the application unit has its own Implement functionality that is related to V2X communication. It is thus possible to react to data received with the V2X communication block in the context of the application. Similarly, results achieved within the application can be communicated to the outside via the V2X communication block.
  • the application unit can therefore also have a sending and a received share.
  • the data transmitted to the application unit via the application interface is, for example, information about an approaching vehicle, about a deployment vehicle located in a certain area - for example, such a sovereign function - the deployment status of a vehicle Example, "activated siren", "accident scene hedging", etc.
  • the data transmitted via the application interface data can be encoded, for example via a plurality of digital signal lines or via an n-bit data word, the meaning of the encoded message content z. B. is determined via a look-up table.
  • the rate at which data is transmitted to the radio adapter is predetermined to the V2X communication block via at least one transmission rate interface.
  • the V2X communication block has, for example, a standard transmission rate of 10 Hz, it can be specified via the transmission rate interface that in the current traffic situation only a reduced transmission rate must be used, for example 5 Hz, 2 Hz or even 1 Hz. It does not matter where the signal comes from to reduce the transmission rate, for example the signal can originate from the radio adapter itself if it recognizes a bandwidth problem.
  • protocol description data is transmitted to the V2X communication block via at least one protocol interface.
  • the protocol description data is preferably provided in the format Abstract Syntax Notation 1 (ASN.
  • ASN Abstract Syntax Notation 1
  • the protocol description data at least partially defines the communication functionality of the V2X communication block; For example, a fixed, unchanging communication functionality could also be implemented in the V2X communication block to which the functionality defined via the protocol description data is added.
  • the protocol description data in the model could be fixed and read out.
  • a log file with protocol description data could be permanently linked in the model, for example in the form of an asn. l file. In both additional alternatives, no protocol interface is needed on the V2X communication block.
  • a data compression of the data to be transmitted is carried out in the V2X communication block, preferably also a decompression of received compressed data.
  • l-compliant data compression is done by Packed Encoding ules.
  • At least one of the previously mentioned interfaces ie the radio adapter interface, application interface, transmit data interface and protocol interface, realized as a port of the V2X communication block, so that the interfaces with the usual means of block-based graphical modeling environments can be handled and a use of the corresponding interface already is apparent from the block diagram, for example, by connecting a signal line to the corresponding port.
  • the radio adapter interface of the V2X communication protocol is implemented on a protocol level above the bit transmission layer of the OSI reference model, that is, for example, in the session layer, the presentation layer or the application layer.
  • the hardware adapters of the OSI reference model are implemented in the radio adapter.
  • the communication between the V2X communication block and the radio adapter via the network protocol UDP or TCP is modeled and implemented according to the resulting V2X program between the target hardware and real wireless adapter communication via the network protocol UDP or TCP becomes.
  • the V2X communication block cyclically transmits data via the radio adapter interface, in particular in the form of cooperative awareness messages or basic safety messages, which may be personal vehicle data that includes the status and movement information of the vehicle.
  • This transmitted own vehicle data can be received, for example, from other vehicles to create a movement profile of the surrounding road users. So that a movement profile can also be created between vehicles which have a high relative speed to each other, it is advantageous to choose a not too long cycle time, a transmission rate of 10 Hz - ie a cycle time of 100 ms - can be suitable in many cases.
  • the V2X communication block sends and / or receives event-driven data via the radio adapter interface, in particular in the form of decentralized environmental notification messages (DENM messages).
  • DENM messages decentralized environmental notification messages
  • event-driven data transmission information can be communicated purposefully that is of no interest in normal and error-free traffic operation.
  • a triggering event could be, for example, an emergency stop or a substantial vehicle defect.
  • the implementation effort for a V2X application is further achieved by using a V2X motion profile block for creating the block diagram, which has at least one motion data interface by means of which motion data is provided from received data from external vehicles, in particular movement data at least one of the information position, speed, acceleration and direction of movement belongs.
  • the motion profile block may be based on an environment table in which data of vehicles in the environment are stored. In the motion profile block, of course, even more information can be deposited, which are not originally related to the position or movement of another vehicle, but nevertheless affect the vehicle, z.
  • B. Status information such as the protection of an accident site by a foreign vehicle or the like.
  • the V2X motion profile block makes it very easy to access the motion data from surrounding vehicles within the modeling environment, greatly simplifying the implementation of V2X applications.
  • a simplification in the implementation of V2X applications is achieved in that a V2X Eigenstons- profile block is used to create the block diagram, which has at least one motion data interface, by means of which movement data of the own vehicle are provided, in particular wherein the motion data at least one of the information position, speed, acceleration and direction of motion belongs.
  • the movement data of the own vehicle can be accessed very easily within the model and the data can also be transmitted to other road users, for example by transmission to the V2X communication block.
  • V2X-Eigenturmschibusblock which has at least one data bus data interface, by means of which data of the data bus of the own vehicle are provided, in particular the V2X communication block are provided in which the data bus is in particular a data bus for networking the vehicle control devices, in particular where the data bus operates according to one of the standards CAN, TTCAN or FlexRay.
  • a V2X trigger block is used to create the block diagram, which has at least one trigger input interface, at least one trigger output interface and internal trigger logic, the internal trigger logic evaluating information received via the trigger input interface and depending on the received information via the trigger output interface outputs a trigger signal.
  • the trigger signal can be used particularly advantageously for triggering the sending of a message.
  • the trigger logic is based on the standards of the Car 2 Car Communication Consortium, for example as described in the so-called Triggering Conditions Document.
  • the above object is also achieved by a computer-implemented method for implementing a V2X application on a target hardware, wherein the V2X application is modeled with a graphical modeling environment in the form of a block diagram and the block diagram is modeled into a V2X executable on the target hardware Program and the V2X program is transferred to the target hardware and executed there, whereby at least one V2X block implementing a V2X-specific functionality is used to create the block diagram.
  • V2X block all advantages are achieved, which have been previously shown.
  • the named V2X block and its functionality are taken into account during the translation into the V2X program and are automatically implemented in the V2X program.
  • the V2X block may be a V2X communication block, a V2X motion profile block, a V2X intrinsic motion profile block, a V2X intrinsic vehicle data bus block, or a V2X trigger block, and thus V2X-specific functionality for the functionality of a V2X as described in detail above Communication blocks, a V2X motion profile block, a V2X Own motion profile block, a V2X own vehicle data bus block, or a V2X trigger block.
  • V2X blocks with which a V2X application with a graphic modeling environment in the form of a block diagram can be described, namely by a V2X communication block, a V2X motion profile block, a V2X eigen motion profile block, a V2X own vehicle data bus block and a V2X trigger block.
  • Fig. 1 is a schematic representation of a computer-implemented
  • FIG. 2 schematically shows a block diagram of a graphical modeling environment with a V2X communication block, a radio adapter and an application unit within the block diagram,
  • FIG. 3 shows a block diagram as in FIG. 2 with a V2X communication block with transmission rate interface
  • Fig. 4 is a block diagram as in the previous figures with a
  • 5 is a block diagram for modeling a V2X application with a motion profile block
  • 6 is a block diagram for modeling a V2X application with a self-motion profile block
  • FIG. 7 is a block diagram for modeling a V2X application with an own vehicle data bus block
  • FIG. 8 is a block diagram for modeling a V2X application with a trigger block.
  • Fig. 1 is shown schematically first the flow of the proposed computer-implemented method 1 for implementing a V2X application on a target hardware 2 with a radio adapter 3, the V2X application is modeled with a graphical modeling environment 4 in the form of a block diagram 5.
  • the block diagram 5 and the V2X application modeled with it are first translated into a V2X program 6 executable on the destination hardware 2, and the V2X program 6 is then transferred to the target hardware 2 and executed there.
  • the block diagram 5 is analyzed and first translated into program code, the program code then being compiled so that the executable V2X program 6 results.
  • the V2X program executed on the target hardware 2 thus implements the functionality of the V2X application previously modeled using the graphical modeling environment 4 in the form of the block diagram 5.
  • the radio adapter 3 is installed in the own vehicle and represents the technical medium, with which either is communicated with other vehicles (Vehicle2Vehicle or special Car2Car) or with other, fixed communication partners is communicated (V2Infrastructure) such. B. lights, traffic jam stations, etc.
  • V2X communication block 7 contains an elementary communication functionality, which can be used in the block diagram 5 via a radio adapter interface 8. Data can be exchanged between the radio adapter 3 or the model-side equivalent 3 'of the radio adapter 3 in the graphic modeling environment 4 and the V2X communication block 7 via the radio adapter interface 8.
  • FIGS. 2 to 5 each show a block diagram 5 with which a V2X application is modeled, wherein the graphical modeling environment is no longer expressly illustrated.
  • the V2X communication block 7 is used to implement a V2X application in a graphical modeling environment in the form of a block diagram 5, wherein the V2X communication block 7 has a radio adapter interface 8, by means of which data is transmitted between the V2X communication block 7 and the modeled radio adapter 3 'of the block diagram 5 are interchangeable.
  • FIG. 2 shows that the V2X communication block 7 has an application interface 9, by means of which data can be exchanged with an application unit 10, the application unit 10 being part of the block diagram 5 here.
  • the application unit 10 accommodates the individual functionality of the V2X application to be implemented.
  • the V2X communication block 7 makes it possible in a simple manner to establish the communications typical for V2X applications with other communication partners.
  • all interfaces are shown as ports of blocks, so that solely from the signal lines Connections can be seen, which block communicates with which other block. Not only a single signal can necessarily be transmitted via a signal line; it is also possible, for example, to transport a multiplicity of signals over a signal line; this is merely a question of representation in current modeling tools.
  • V2X communication block 7 has a transmission data interface 11, via which the rate at which the V2X communication block 7 transmits data to the radio adapter 3 'can be predetermined for the V2X communication block 7.
  • the block diagram 5 in the executable V2X program 6 this of course means that then implemented on the target hardware 2 corresponding functionality of the V2X communication block 7 ensures that the target hardware 2 transmitted via the wireless adapter 3 only in the predetermined rate data and it also sends only data in the given rate; it is always - as far as possible - an exact match between block diagram and target hardware available.
  • FIGS. 3 and 4 show that the V2X communication block 7 is given a transmission rate via the transmission rate interface 1 1 which originates from a DCC block 12 (decentralized congestion control), this DCC block 12 being for example from the radio adapter 3, 3 'receives information about the channel utilization and thus ensures a corresponding adapted transmission rate.
  • DCC block 12 decentralized congestion control
  • FIG. 4 shows the V2X communication block 7 with an extended functionality, since it has a protocol interface 13, via which the protocol description data 14 can be transmitted to the V2X communication block 7.
  • the protocol description data 14 are located here in the ASN. l format (Abstract Syntax Notation One).
  • the communication functionality of the V2X communication block 7 is at least partially defined.
  • the definition of the communication functionality of the V2X communication block 7 ultimately also determines the communication functionality of the V2X application implemented later on the destination hardware.
  • the communication between the V2X communication block 7 and the radio adapter 3 or the model of the radio adapter 3 ' is realized via the network protocol UDP.
  • the connection between the target hardware 2 and the wireless adapter 3 shown in FIG. 1 is an Ethernet-based connection that is implemented via the network protocol UDP.
  • the protocol description data 14 shown in FIG. 4 includes a description of Cooperative Awareness Messages (CAM) sent cyclically over the radio adapter interface 8, as well as a description of Decentralized Environmental Notification Messages (DENM) used by the V2X communication block 7 is to send event-driven data via the radio adapter interface 8.
  • CAM Cooperative Awareness Messages
  • DENM Decentralized Environmental Notification Messages
  • FIG. 5 shows a typical application in which a plurality of foreign vehicles, designated here by Carl, Car2 and Car3, are in reception range of the radio adapter 3 or of the model of the radio adapter 3 ', and insofar the radio adapter 3, 3' data from the Foreign vehicles Carl, Car2 and Car3 receives.
  • the block diagram 5 has a V2X motion profile block 15, which also serves to implement a V2X application in the block diagram 5, wherein the V2X motion profile block 15 has a motion data interface 16, by means of which movement data p, v, a from received data from other vehicles Carl, Car2, Car3 are available. It can be seen that these movement data of the foreign vehicles Carl, Car2 and Car3 are stored in the V2X movement profile block 15 and made available to other parts of the block diagram 5 via this V2X movement profile block 15.
  • the V2X motion profile block 15 is connected to the application unit 10.
  • the dashed connection between the V2X motion profile block 15 and the V2X communication block 7 indicates that in the illustrated embodiment, the V2X- Communication block 7 also has access to the movement data p, v, a, even without this being made clear here with a signal line connection.
  • the movement data here include the position p, the speed v and the acceleration a of the respective other vehicle Carl, Car2 and Car3.
  • other data from other vehicles Carl, Car2 and Car3 can be stored, here is the status information s, can be stored in the coded whether the other vehicle is an emergency vehicle, whether the emergency vehicle in emergency use etc.
  • the movement data can also include the movement direction, which can be extracted, for example, from a vectorial speed information.
  • FIG. 6 shows a modeled and implemented V2X application in which a V2X eigen motion profile block 17 is provided, wherein the V2X eigen motion profile block has a motion data interface 18 by means of which movement data of the own vehicle - not shown here - can be provided the movement data in the present case include the position p, the speed v, the acceleration a and the movement direction determined therefrom.
  • the V2X eigenmotion profile block 17 may also include other data such as status information s and time t. The information may originate, for example, from a GPS receiver of the own vehicle.
  • the movement data of the own vehicle can thus be made available to the V2X application within the block diagram 5 and thus naturally also in the transmitted V2X application on the destination hardware 2.
  • the data bus 21 is a data bus which serves to network the vehicle control units 22.
  • the data bus 21 is a CAN bus.
  • the V2X trigger block 30 has a plurality of ports of a trigger input interface 31, and a trigger output interface 32. Furthermore, the V2X trigger block 30 has an internal trigger logic, wherein the internal trigger logic evaluates information received via the trigger input interface 31 and outputs a trigger signal depending on the received information via the trigger output interface 32, which in the present case serves to trigger the transmission of a message. Furthermore, the V2X trigger block 30 also has a message output 33, via which the type of message to be sent is output.
  • the signals of an emergency vehicle are processed via the three ports of the trigger input interface 31, namely the status information "LightBarlnUse", “SirenUse” and "Velocity”.
  • This information is processed by the trigger logic and dependent on a trigger signal for sending a message issued as well as the type of message, such as "rescue vehicle in use at speed v”.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Traffic Control Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

Dargestellt und beschrieben ist ein computerimplementiertes Verfahren (1) zur Implementierung einer V2X-Anwendung auf einer Zielhardware (2) mit einem Funkadapter (3, 3'), wobei die V2X-Anwendung mit einer graphischen Modellie- rungsumgebung (4) in Form eines Blockschaltbildes (5) modelliert wird und das Blockschaltbild (5) in ein auf der Zielhardware (2) ausführbares V2X-Programm (6) übersetzt und das V2X-Programm (6) auf die Zielhardware (2) übertragen und dort ausgeführt wird. Das Verfahren zur Implementierung einer V2X-Anwendung wird auf besonders einfache und vorteilhafte Wiese realisiert, indem zur Erstellung des Blockschalt- bildes (5) ein V2X-Kommunikationsblock (7) eingesetzt wird, der wenigstens eine Funkadapterschnittstelle (8) aufweist, mittels derer Daten zwischen dem Funkadapter (3, 3') und dem V2X-Kommunikationsblock (7) ausgetauscht wer- den.

Description

Computerimplementiertes Verfahren zur Implementierung einer V2X-Anwendung und diesbezügliche V2X-Blöcke
für eine graphische Modellierungsumgebung
Die Erfindung betrifft ein computerimplementiertes Verfahren zur Implementierung einer V2X-Anwendung auf einer Zielhardware mit einem Funkadapter, wobei die V2X-Anwendung mit einer graphischen Modellierungsumgebung in Form eines Blockschaltbildes modelliert wird. Die Erfindung betrifft ferner verschiedene Blöcke zur Verwendung in einer graphischen Modellierungsumgebung, mit denen eine V2X-Anwendung modelliert und implementiert werden kann.
Die Erfindung entstammt dem Umfeld der Steuergeräteentwicklung, sie betrifft hier weniger die hardwaremäßige Entwicklung eines Steuergeräts, sondern vielmehr die Entwicklung und den Test einer im weitesten Sinne regelungstechnischen Funktionalität auf einem Steuergerät. Der Begriff "regelungstechnische Funktionalität" ist nicht eng im systemtheoretischen Sinne zu verstehen, gemeint ist jegliche gezielte Einflussnahme auf einen mit dem Steuergerät verbundenen technischen Prozess. Das kann auch lediglich die Verarbeitung und/oder Fusion von Sensordaten sein, beispielsweise von Umgebungssensoren.
Die damit verbundene Entwicklung durchläuft verschiedene Phasen, die Teil des sogenannten V-Modells sind. Üblicherweise wird die gewünschte regelungstechnische Funktionalität zunächst abstrakt im Rahmen von Offline- Simulationen - keine Verbindung zum realen Prozess, keine Echtzeitanforderung - durch ein mathematisches Modell abgebildet, wobei üblicherweise mit Blockschaltbildern sowohl der regelungs- und steuerungstechnische Aspekt wie auch der zu beeinflussende technisch-physikalische Prozess mathematisch nachgebildet und mit Hilfe von numerischen Verfahren simuliert wird. In einem weiteren Schritt wird die regelungstechnische Funktionalität in Programmcode umgesetzt und auf einer Zielhardware implementiert, die sich von dem später zum Einsatz kommenden Seriensteuergerät meist erheblich unterscheidet. Die Zielhardware ist üblicherweise leistungsfähiger als Seriensteuergeräte, so dass beim Test der zu implementierenden regelungstechnischen Funktionalität jedenfalls sichergestellt ist, dass die Hardware kein limitierender Faktor im Aufbau ist. Die so instrumentierte Zielhardware wird jedenfalls im Zusammenhang mit dem zu beeinflussenden technischen Prozess getestet. Die Zielhardware muss sich nicht zwingend von der Hardware unterscheiden, auf der die graphische Modellierungsumgebung betrieben wird und/oder mit der die Übersetzung in ein ausführbares V2X-Programm erfolgt; in diesem Fall ist die Übertragung auf die Zielhardware dann denkbar kurz, das Programm muss lediglich geladen und ausgeführt werden. Die Zielhardware kann also auch ein PC sein, auch der PC, auf dem die Modellierungsumgebung ausgeführt und/oder die Übersetzung des Modells/Blockschaltbildes in ein ausführbares Programm erfolgt.
Sobald die Serien-Zielhardware, also das Seriensteuergerät, zur Verfügung steht, wird der zu implementierende Regelungsalgorithmus für diese Zielhardware erzeugt, wobei das Seriensteuergerät dann zunächst nicht im Zusammenhang mit dem echten physikalischen Prozess getestet wird, sondern mit einer simulierten Prozessumgebung im Rahmen eines Hardware-in-the- Loop-Test (HIL-Test). Nach erfolgreich absolviertem HIL-Test wird die Zielhardware in Form des Seriensteuergeräts im echten physikalischen Prozess, vorliegend also im Kraftfahrzeug, getestet, wobei hier ggf. noch Abstimmungen in der Parametrierung erfolgen.
Wichtig für sämtliche Entwicklungsschritte ist, dass der aus dem Blockschaltbild bekannte abstrakte Regelungsvorgang - im zuvor ausgeführten Sinne eine regelungstechnische Funktionalität, die auch in einer Sensordatenauswertung oder Datenfusion bestehen kann - nicht mehr manuell in Programmcode übersetzt wird, sondern dass diese Übertragung durch einen automatisierten Codegenerierungsprozess aus dem Blockschaltbild heraus erfolgt. So werden die fehlerträchtige manuelle Übertragung vermieden und schnelle Testzyklen mit variierender regelungstechnischer Funktionalität ermöglicht. Die Funktio- nalität der Blockschaltbilder bzw. der Blöcke der Blockschaltbilder selbst kann ganz unterschiedlich implementiert sein. Es ist möglich, dass die Funktionalität eines Blockschaltbildes intern mit weiteren Blockschaltbildern und Blöcken elementarerer Funktionalität realisiert sind - in Sub- und Subsub- Blockschaltbildern und Blöcken usw. -, es kann aber auch sein, dass die Funktionalität eines Blockschaltbildes selbst in einer höheren Programmierbzw. Beschreibungssprache hinterlegt ist; darauf kommt es im Einzelnen nicht an.
Mit den heute gängigen graphischen Modellierungs- und Simulationsumgebungen lassen sich durch Verwendung der zur Verfügung stehenden Elementaroperationen (Grundrechenarten, Differential- und Integraloperationen, Bitbeeinflussung, Look-Up-Tables etc.) praktisch beliebige Funktionalitäten nachbilden, wie beispielsweise auch die Buskommunikation zwischen Steuergeräten oder eine Sensordatenauswertung und -fusion. Auch kann in Blöcken Programmcode hinterlegt werden, beispielsweise C/C++ oder C#-Code. Beispiele für Entwicklungsumgebungen, die auf Blockschaltbildern basieren sind Simulink (The MathWorks), ConfigurationDesk (dSPACE), ADTF (Automotive Data and Time-Triggered Framework, Elektrobit) und TMaps (Real- Time Multisensor Advanced Prototyping Software, Intempora).
Wenn davon die Rede ist, dass das Blockschaltbild in ein auf der Zielhardware ausführbares V2X-Programm übersetzt wird, dann kann es sich auch um ein solches Programm handeln, das auf der Zielhardware zur Ausführung interpretiert wird; auch dann handelt es sich um ein ausführbares V2X- Programm.
In der Steuergeräteentwicklung ist es ganz allgemein von Interesse, auch solche Technologien in einer graphischen Modellierungsumgebung abbilden zu können, die noch nicht zum etablierten Stand der Technik gehören. Eine solch neue, aber noch nicht etablierte Technologie ist die V2X-Technologie, unter der die Kommunikation eines Fahrzeugs (V = vehicle) mit seiner Umgebung verstanden wird. Dabei kann es sich um die Kommunikation mit anderen umgebenden Fahrzeugen handeln (V2V), um die Kommunikation mit immobilen Kommunikationspartnern (V2Infrastructure). Bei den Fahrzeugen kann es sich beispielsweise um Straßenfahrzeuge handeln, so dass in diesem Fall von Car2X-Anwendungen gesprochen werden kann. Bei der Umgebung kann es sich um gleichartige Fahrzeuge handeln, aber auch um andere Verkehrsteilnehmer (beispielsweise V U = vulnerable road user wie z. B. Fußgänger, Fahrräder, Rollstühle). Die Umgebung kann aber auch aus anderen Objekten und Kommunikationsmitteln bestehen, z. B. auch Backend- Servern in der Cloud.
Die Abbildung einer solchen V2X-Kommunikation mit den Elementaroperationen einer graphischen Modellierungsumgebung in jedem Einzelfall der Modellierung einer V2X-Anwendung ist beliebig kompliziert und aufwendig, so dass der vorliegenden Erfindung die Aufgabe zugrunde liegt, ein computerimplementiertes Verfahren zur Implementierung einer V2X-Anwendung auf einer Zielhardware anzubieten, bei dem der Implementierungsaufwand reduziert ist.
Die zuvor hergeleitete Aufgabe ist zunächst gelöst durch ein computerimplementiertes Verfahren zur Implementierung einer V2X-Anwendung auf einer Zielhardware mit einem Funkadapter, wobei die V2X-Anwendung mit einer graphischen Modellierungsumgebung in Form eines Blockschaltbildes modelliert wird und das Blockschaltbild in ein auf der Zielhardware ausführbares V2X-Programm übersetzt und das V2X-Programm auf die Zielhardware übertragen und dort ausgeführt wird, wobei zur Erstellung des Blockschaltbildes ein V2X-Kommunikationsblock eingesetzt wird, der wenigstens eine Funkadapterschnittstelle aufweist, mittels derer Daten zwischen dem Funkadapter und dem V2X-Kommunikationsblock ausgetauscht werden.
Dieses Verfahren ist von seiner Idee her unabhängig von bestimmten Kommunikationsstandards, Protokollen und speziellen Definitionen und Implementierungen physikalischer Schichten. Das Verfahren ist praktisch mit beliebigen Standards realisierbar und an beliebige Standards anpassbar. Es kommt selbstverständlich nicht darauf an, dass die gesamte Funktionalität mit einem einzigen V2X-Kommunikationsblock im Blockschaltbild abgebildet wird. Unterschiedliche Funktionalitäten können selbstverständlich auch auf mehrere V2X-Kommunikationsblöcke verteilt werden; dies mag beispielsweise aus Gründen der Übersichtlichkeit vorteilhaft sein. Ergebnis des erfindungsgemäßen Verfahrens ist also eine Zielhardware, auf der eine V2X-Anwendung ausgeführt wird, wobei der erfindungsgemäß eingesetzte V2X-Kommunikationsblock automatisch dafür sorgt, dass die einen Funkadapter umfassende Zielhardware den Funkadapter ohne weiteres verwenden kann, insbesondere ohne hier ein Ansprechen des Funkadapters mit ins Detail gehenden Elementaroperationen selbst modellieren und ansprechen zu müssen; dadurch wird eine erhebliche Vereinfachung für die Realisierung von V2X- Anwendungen erzielt.
Es kann ein beliebiger Funkstandard realisiert werden, also eine beliebige drahtlose Kommunikationstechnologie. Es kann sich um eine WLAN- Anwendung handeln (z. B. in Wohngebäuden, Lagerhallen), Mobilfunk- Lösungen sind denkbar (GSM, CDMA, GPRS, LTE; Anwendungen auf Straßen, im Luftraum), aber auch RFID-Anwendungen könne darunter fallen (z. B. in Wohngebäuden, Krankenhäusern, Lagerhallen, Versandzentren etc.), das hängt sehr von dem konkreten Anwendungsfall ab.
Die Zielhardware kann den Funkadapter in einer integrierten hardwaremäßigen Lösung selbst umfassen, die Zielhardware kann aber mit einem Funkadapter auch über eine separat realisierte hardwaremäßige Schnittstelle verbunden sein. Wenn hier davon die Rede ist, dass das mit der graphischen Modellierungsumgebung erstellte Blockschaltbild in ein auf der Zielhardware ausführbares V2X-Programm übersetzt wird, dann kann es sich bei diesem Programm um ein auf einem Prozessor/Mikrocontroller ausführbares Programm handeln, es kann sich aber auch um eine Hardwarebeschreibung handeln, mit der einer Schaltkreisstruktur durch "feste Verdrahtung" die gewünschte Funktionalität aufgegeben wird. Über die Funkadapterschnittstelle lassen sich Daten in Richtung auf den Funkadapter übertragen (senden), es können genauso gut von dem Funkadapter Daten in Richtung auf die übrige Zielhardware gerichtet werden (empfangen).
Eine vorteilhafte Ausgestaltung des Verfahrens sieht vor, dass der V2X- Kommunikationsblock über wenigstens eine Applikationsschnittstelle mit einer Applikationseinheit Daten austauscht, wobei die Applikationseinheit insbesondere Teil des Blockschaltbildes sein kann. Dadurch ist es möglich, dass der Verwender des Verfahrens in der Applikationseinheit eine eigene Funktionalität realisieren kann, die im Zusammenhang mit der V2X- Kommunikation steht. Es kann so auf mit dem V2X-Kommunikationsblock empfangene Daten im Rahmen der Applikation reagiert werden, genauso können im Rahmen der Applikation erzielte Ergebnisse über den V2X- Kommunikationsblock nach außen mitgeteilt werden. Die Applikationseinheit kann also auch einen sendenden und einen empfangenen Anteil haben.
In einem bevorzugten Ausführungsbeispiel handelt es sich bei den über die Applikationsschnittstelle zu der Applikationseinheit übertragenen Daten beispielsweise um Informationen über ein sich näherndes Fahrzeug, über ein sich in einem bestimmten Bereich befindliches Einsatzfahrzeug - beispielsweise ein solches mit hoheitlicher Funktion -, den Einsatzstatus eines Fahrzeuges - zum Beispiel "aktivierte Sirene", "Unfallstelle absichernd" usw. Die über die Applikationsschnittstelle übertragenen Daten können codiert sein, beispielsweise über eine Mehrzahl an digitalen Signalleitungen oder auch über ein n- Bit-Datenwort, wobei die Bedeutung des codierten Nachrichteninhalts z. B. über ein Look-Up-Table ermittelt wird.
Gemäß einer Weiterentwicklung des erfindungsgemäßen Verfahrens ist vorgesehen, dass dem V2X-Kommunikationsblock über wenigstens eine Senderatenschnittstelle die Rate vorgegeben wird, mit der dem Funkadapter Daten übermittelt werden. Mit dieser Möglichkeit kann einfach die Funktionalität implementiert werden, dass bei zu hoher Fahrzeug- und damit Informationsdichte eine Überflutung der drahtlosen Kommunikationskanäle resultiert. Wenn der V2X-Kommunikationsblock beispielsweise eine Standard- Senderate von 10 Hz aufweist, kann ihm über die Senderatenschnittstelle vorgegeben werden, dass in der jetzigen Verkehrssituation nur mit einer reduzierten Senderate zu arbeiten ist, beispielsweise mit 5 Hz, 2 Hz oder auch nur 1 Hz. Dabei ist es unerheblich, woher das Signal zur Reduzierung der Senderate stammt, das Signal kann beispielsweise aus dem Funkadapter selbst stammen, wenn dieser ein Bandbreitenproblem erkennt.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens ist vorgesehen, dass dem V2X-Kommunikationsblock über wenigstens eine Protokollschnittstelle Protokollbeschreibungsdaten übermittelt werden. Damit ist es möglich, dem V2X-Kommunikationsblock an beliebige Protokolle anzupas- sen bzw. mit beliebigen Protokollen auszustatten. Vorzugsweise werden die Protokollbeschreibungsdaten im Format Abstract Syntax Notation 1 (ASN. l) zur Verfügung gestellt. Durch die Protokollbeschreibungsdaten wird die Kommunikationsfunktionalität des V2X-Kommunikationsblocks zumindest teilweise definiert; es könnte beispielsweise auch eine feste, unveränderliche Kommunikationsfunktionalität in dem V2X-Kommunikationsblock implementiert sein, zu der die über die Protokollbeschreibungsdaten definierte Funktionalität hinzutritt.
Alternativ zu der Lösung mit einer Protokollschnittstelle könnten die Protokollbeschreibungsdaten in dem Modell fest zur Verfügung gestellt und ausgelesen werden. In einer weiteren Alternative könnte eine Protokolldatei mit Protokollbeschreibungsdaten fest im Modell verlinkt werden, beispielsweise in Form einer asn. l -Datei. In beiden zusätzlichen Alternativen wird keine Protokollschnittstelle am V2X-Kommunikationsblock benötigt.
In einem weiteren bevorzugten Ausführungsbeispiel des Verfahrens wird in dem V2X-Kommunikationsblock eine Datenkomprimierung der zu sendenden Daten vorgenommen, vorzugsweise auch eine Dekomprimierung empfangener komprimierter Daten. Insbesondere wir bei ASN. l -konformen Daten eine Komprimierung durch Packed Encoding ules vorgenommen.
Vorzugsweise wird wenigstens eine der zuvor angesprochenen Schnittstellen, also der Funkadapterschnittstelle, Applikationsschnittstelle, Senderatenschnittstelle und Protokollschnittstelle, als Port des V2X-Kommunikations- blocks realisiert, so dass die Schnittstellen mit den üblichen Mitteln blockbasierter graphischer Modellierungsumgebungen gehandhabt werden können und eine Nutzung der entsprechenden Schnittstelle schon aus dem Blockschaltbild heraus offenkundig ist, indem beispielsweise eine Signallinie an den entsprechenden Port angeschlossen wird.
In einer weiteren Ausgestaltung des Verfahrens ist vorgesehen, dass die Funkadapterschnittstelle des V2X-Kommunikationsprotokolls auf einer Protokollebene oberhalb der Bit-Übertragungsschicht des OSI-Referenzmodells realisiert wird, also beispielsweise in der Sitzungsschicht, der Darstellungsschicht oder der Anwendungsschicht. In diesem Fall sind in dem Funkadapter die hardwarenäheren Schichten des OSI- eferenzmodells realisiert.
In einer weiteren Ausgestaltung des Verfahrens ist vorgesehen, dass die Kommunikation zwischen dem V2X-Kommunikationsblock und dem Funkadapter über das Netzwerkprotokoll UDP oder TCP modelliert wird und entsprechend durch das resultierende V2X-Programm zwischen Zielhardware und realem Funkadapter eine Kommunikation über das Netzwerkprotokoll UDP oder TCP realisiert wird.
In einer besonders vorteilhaften Ausgestaltung des Verfahrens versendet der V2X-Kommunikationsblock über die Funkadapterschnittstelle zyklisch Daten, insbesondere in Form von Cooperative Awareness Messages oder Basic Sa- fety Messages, es kann sich hier um Eigenfahrzeugdaten handeln, die den Status und Bewegungsinformationen des Fahrzeugs umfassen. Diese gesendeten Eigenfahrzeugdaten können beispielsweise von anderen Fahrzeugen empfangen werden, um ein Bewegungsprofil der sie umgebenden Verkehrsteilnehmer zu erstellen. Damit ein Bewegungsprofil auch zwischen Fahrzeugen erstellt werden kann, die eine große Relativgeschwindigkeit zueinander haben, ist es vorteilhaft, eine nicht zu große Zykluszeit zu wählen, eine Senderate von 10 Hz - also eine Zykluszeit von 100 ms - kann in vielen Fällen geeignet sein.
Alternativ oder ergänzend ist in dem vorgeschlagenen Verfahren vorgesehen, dass der V2X-Kommunikationsblock über die Funkadapterschnittstelle ereignisgetrieben Daten versendet und/oder empfängt, insbesondere in Form von Decentralized Environmental Notification Messages (DENM-Messages). Durch ereignisgetriebene Datenübermittlung können zielgerichtet Informationen mitgeteilt werden, die im normalen und fehlerfreien Verkehrsbetrieb nicht von Interesse sind. Ein auslösendes Ereignis könnte beispielsweise eine Vollbremsung oder ein substantieller Fahrzeugdefekt sein.
Der Implementierungsaufwand für eine V2X-Anwendung wird weiterhin dadurch erzielt, dass das zur Erstellung des Blockschaltbildes ein V2X- Bewegungsprofilblock eingesetzt wird, der wenigstens eine Bewegungsdatenschnittstelle aufweist, mittels derer Bewegungsdaten aus empfangenen Daten von Fremdfahrzeugen bereitgestellt werden, insbesondere wobei zu den Be- wegungsdaten wenigstens eine der Informationen Position, Geschwindigkeit, Beschleunigung und Bewegungsrichtung gehört. Der Bewegungsprofilblock kann beispielsweise auf einer Umfeldtabelle basieren, in der Daten von Fahrzeugen in der Umgebung abgelegt sind. In dem Bewegungsprofilblock können selbstverständlich auch noch weitere Informationen hinterlegt werden, die nicht originär mit Position oder Bewegung eines Fremdfahrzeugs zu tun haben, gleichwohl aber das Fahrzeug betreffen, z. B. Statusinformationen wie die Absicherung einer Unfallstelle durch ein Fremdfahrzeug oder ähnliches.
Über den V2X-Bewegungsprofilblock kann innerhalb der Modellierungsumgebung auf sehr einfache Art und Weise auf die Bewegungsdaten von umgebenden Fremdfahrzeugen zugegriffen werden, so dass eine erhebliche Erleichterung der Implementierung von V2X- Anwendungen erzielt wird.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens wird eine Erleichterung in der Implementierung von V2X-Anwendungen dadurch erzielt, dass zur Erstellung des Blockschaltbildes ein V2X-Eigenbewegungs- profilblock eingesetzt wird, der wenigstens eine Bewegungsdatenschnittstelle aufweist, mittels derer Bewegungsdaten des eigenen Fahrzeugs bereitgestellt werden, insbesondere wobei zu den Bewegungsdaten wenigstens eine der Informationen Position, Geschwindigkeit, Beschleunigung und Bewegungsrichtung gehört. Derart kann innerhalb des Modells sehr einfach auf die Bewegungsdaten des eigenen Fahrzeugs zugegriffen werden und die Daten beispielsweise durch Übermittlung an den V2X-Kommunikationsblock auch an andere Verkehrsteilnehmer übermittelt werden.
Eine noch weitergehende Vereinfachung bei der Realisierung von V2X- Anwendungen besteht darin, dass zur Erstellung des Blockschaltbildes ein V2X-Eigenfahrzeugdatenbusblock eingesetzt wird, der wenigstens eine Datenbusdatenschnittstelle aufweist, mittels derer Daten des Datenbusses des eigenen Fahrzeugs bereitgestellt werden, insbesondere dem V2X- Kommunikationsblock bereitgestellt werden, wobei es sich bei dem Datenbus insbesondere um einen Datenbus zur Vernetzung der Fahrzeugsteuergeräte handelt, insbesondere wobei der Datenbus nach einem der Standards CAN, TTCAN oder FlexRay arbeitet. Durch diese Maßnahme kann durch den V2X- Eigenfahrzeugdatenbusblock auf die interne Steuergerätekommunikation des eigenen Fahrzeugs zugegriffen werden, beispielsweise von der Applikationseinheit, die der Verwender des Verfahrens erstellt hat, um seine Custom- Funktionalität zu implementieren. Der erfindungsgemäße Einsatz des V2X- Eigenfahrzeugsdatenbusblocks ermöglicht einen direkten und tiefen Zugriff auf die Kommunikation der Fahrzeugelektronik.
Es hat sich weiterhin als vorteilhaft herausgestellt, dass zur Erstellung des Blockschaltbildes ein V2X-Triggerblock eingesetzt wird, der wenigstens eine Triggereingangsschnittstelle, wenigstens eine Triggerausgangs Schnittstelle und eine interne Triggerlogik aufweist, wobei die interne Triggerlogik über die Triggereingangsschnittstelle empfangene Informationen auswertet und in Abhängigkeit von den empfangenen Informationen über die Triggerausgangsschnittstelle ein Triggersignal ausgibt. Das Triggersignal kann besonders Vorteilhaft zur Auslösung des Versendens einer Nachricht herangezogen werden. In einer besonderen Ausgestaltung beruht die Triggerlogik den Standards des Car 2 Car Communication Consortium, beispielsweise wie in dem sogenannten Triggering Conditions Document beschrieben.
Vor dem geschilderten Hintergrund wird die eingangs hergeleitete Aufgabe auch durch ein Computerimplementiertes Verfahren zur Implementierung einer V2X-Anwendung auf einer Zielhardware gelöst, wobei die V2X- Anwendung mit einer graphischen Modellierungsumgebung in Form eines Blockschaltbildes modelliert wird und das Blockschaltbild in ein auf der Zielhardware ausführbares V2X-Programm übersetzt und das V2X-Programm auf die Zielhardware übertragen und dort ausgeführt wird, wobei zur Erstellung des Blockschaltbildes wenigstens ein V2X-Block eingesetzt wird, der eine V2X-spezifische Funktionalität implementiert. Durch den genannten V2X-Block werden alle Vorteile erzielt, die zuvor aufgezeigt worden sind. Der genannte V2X-Block und seine Funktionalität werden bei der Übersetzung in das V2X-Programm berücksichtigt und automatisch in dem V2X- Programm implementiert. Speziell kann es sich bei dem V2X-Block um einen V2X-Kommunikationsblock, einen V2X-Bewegungsprofilblock, einen V2X- Eigenbewegungsprofilblock, einen V2X-Eigenfahrzeugdatenbusblock oder einen V2X-Triggerblock und demzufolge bei der V2X- spezifischen Funktionalität um die zuvor ausführlich beschriebene Funktionalität eines V2X- Kommunikationsblocks, eines V2X-Bewegungsprofilblocks, eines V2X- Eigenbewegungsprofilblocks, eines V2X-Eigenfahrzeugdatenbusblocks oder die eines V2X-Triggerblocks handeln.
Die der Erfindung zugrunde liegende Aufgabe wird auch gelöst durch verschiedene V2X-Blöcke, mit denen sich eine V2X-Anwendung mit einer graphischen Modellierungsumgebung in Form eines Blockschaltbildes beschreiben lassen, nämlich durch einen V2X-Kommunikationsblock, einen V2X- Bewegungsprofilblock, einen V2X-Eigenbewegungsprofilblock, einen V2X- Eigenfahrzeugdatenbusblock und einen V2X-Triggerblock.
Im Einzelnen gibt es eine Vielzahl von Möglichkeiten, das erfindungsgemäße computerimplementierte Verfahren und die genannten V2X-Blöcke für eine graphische Modellierungsumgebung auszugestalten und weiterzubilden. Dazu wird verwiesen einerseits auf die den Patentansprüchen 1 und 14 nachgeordneten Patentansprüche und auf die Patentansprüche 20, 21, 22 und 23 sowie auf die folgende Beschreibung von Ausführungsbeispielen in Verbindung mit der Zeichnung. In der Zeichnung zeigen
Fig. 1 eine schematische Darstellung eines computerimplementierten
Verfahrens zur Implementierung einer V2X-Anwendung auf einer Zielhardware mit einem Funkadapter,
Fig. 2 schematisch ein Blockschaltbild einer graphischen Modellierungsumgebung mit einem V2X-Kommunikationsblock, einem Funkadapter und einer Applikationseinheit innerhalb des Blockschaltbildes,
Fig. 3 ein Blockschaltbild wie in Fig. 2 mit einem V2X-Kommuni- kationsblock mit Senderatenschnittstelle,
Fig. 4 ein Blockschaltbild wie in den vorherigen Figuren mit einem
V2X-Kommunikationsblock mit Protokollschnittstelle,
Fig. 5 ein Blockschaltbild zur Modellierung einer V2X-Anwendung mit einem Bewegungsprofilblock, Fig. 6 ein Blockschaltbild zur Modellierung einer V2X-Anwendung mit einem Eigenbewegungsprofilblock,
Fig. 7 ein Blockschaltbild zur Modellierung einer V2X-Anwendung mit einem Eigenfahrzeugdatenbusblock und
Fig. 8 ein Blockschaltbild zur Modellierung einer V2X-Anwendung mit einem Triggerblock.
In Fig. 1 ist schematisch zunächst dargestellt der Ablauf des vorgeschlagenen computerimplementierten Verfahrens 1 zur Implementierung einer V2X- Anwendung auf einer Zielhardware 2 mit einem Funkadapter 3, wobei die V2X-Anwendung mit einer graphischen Modellierungsumgebung 4 in Form eines Blockschaltbildes 5 modelliert wird. Das Blockschaltbild 5 und die mit ihm modellierte V2X-Anwendung werden zunächst in ein auf der Zielhardware 2 ausführbares V2X-Programm 6 übersetzt und das V2X- Programm 6 wird dann auf die Zielhardware 2 übertragen und dort ausgeführt.
Dies geschieht insgesamt über hier im Einzelnen nicht dargestellte Zwischenstufen: das Blockschaltbild 5 wird analysiert und zunächst in Programmcode übersetzt, wobei der Programmcode dann kompiliert wird, so dass das ausführbare V2X-Programm 6 resultiert. Das auf der Zielhardware 2 ausgeführte V2X-Programm implementiert damit die zuvor mit Hilfe der graphischen Modellierungsumgebung 4 in Form des Blockschaltbildes 5 modellierte Funktionalität der V2X -Anwendung.
Der Funkadapter 3 ist in dem eigenen Fahrzeug installiert und stellt das technische Medium dar, mit dem entweder mit anderen Fahrzeugen kommuniziert wird (Vehicle2Vehicle oder spezieller Car2Car) oder mit anderen, festen Kommunikationspartnern kommuniziert wird (V2Infrastructure) wie z. B. Lichtzeichen, Staumeldestationen usw.
Während das eigene Fahrzeug sich durch den Verkehr bewegt, baut es mit dem in Funkreichweite befindlichen anderen Kommunikationspartnern ein ad- hoc-Netzwerk auf, das naturgemäß aufgrund der ständig wechselnden Kommunikationspartner hochgradig veränderlich ist. Die Implementierung einer V2X-Anwendung auf der Zielhardware 2 wird durch den Einsatz eines V2X-Kommunikationsblocks 7 erleichtert, mit dem das Blockschaltbild 5 - zumindest teilweise - erstellt wird. Der V2X- Kommunikationsblock 7 enthält eine elementare Kommunikationsfunktionalität, die in dem Blockschaltbild 5 über eine Funkadapterschnittstelle 8 nutzbar ist. Über die Funkadapterschnittstelle 8 können Daten zwischen dem Funkadapter 3 bzw. der modellseitigen Entsprechung 3' des Funkadapters 3 in der graphischen Modellierungsumgebung 4 und dem V2X- Kommunikationsblock 7 ausgetauscht werden. Dadurch, dass der V2X- Kommunikationsblock 7 die erforderliche Funktionalität zum Austausch von Daten mit dem Funkadapter 3, 3' mitbringt, ist es nicht mehr erforderlich, diese Funktionalität im Einzelnen mit Elementaroperationen der Modellierungsumgebung 4 zu modellieren.
In den Fig. 2 bis 5 ist jeweils ein Blockschaltbild 5 dargestellt, mit dem eine V2X-Anwendung modelliert ist, wobei die graphische Modellierungsumgebung nicht mehr ausdrücklich dargestellt ist. In allen Bildern ist ersichtlich, dass der V2X-Kommunikationsblock 7 der Implementierung einer V2X- Anwendung in einer graphischen Modellierungsumgebung in Form eines Blockschaltbildes 5 dient, wobei der V2X-Kommunikationsblock 7 eine Funkadapterschnittstelle 8 aufweist, mittels derer Daten zwischen dem V2X- Kommunikationsblock 7 und dem modellierten Funkadapter 3' des Blockschaltbildes 5 austauschbar sind.
In Fig. 2 ist erkennbar, dass der V2X-Kommunikationsblock 7 eine Applikationsschnittstelle 9 aufweist, mittels derer mit einer Applikationseinheit 10 Daten austauschbar sind, wobei die Applikationseinheit 10 hier Teil des Blockschaltbildes 5 ist. Die Applikationseinheit 10 beherbergt die individuelle Funktionalität der zu implementierenden V2X- Anwendung. Durch den V2X- Kommunikationsblock 7 ist es auf einfache Weise möglich, die für V2X- Anwendungen typische Kommunikationen mit anderen Kommunikationspartnern zu errichten.
In den dargestellten Ausführungsbeispielen sind sämtliche Schnittstellen als Ports von Blöcken dargestellt, so dass alleine aus den Signallinien- Verbindungen ersichtlich ist, welcher Block mit welchem anderen Block kommuniziert. Über eine Signallinie kann nicht notwendigerweise nur ein einziges Signal übermittelt werden, es ist beispielsweise auch möglich, eine Vielzahl an Signalen über eine Signallinie zu transportieren, dies ist bei aktuellen Modellierungswerkzeugen lediglich eine Frage der Darstellung.
Fig. 3 zeigt eine V2X- Anwendung, bei der der V2X-Kommunikationsblock 7 eine Senderatenschnittstelle 1 1 aufweist, über die dem V2X-Kommuni- kationsblock 7 die Rate vorgebbar ist, mit der der V2X- Kommunikationsblock 7 dem Funkadapter 3' Daten übermittelt. Nach Übertragung des Blockschaltbildes 5 in das ausführbare V2X-Programm 6 bedeutet dies natürlich, dass die dann auf der Zielhardware 2 implementierte entsprechende Funktionalität des V2X-Kommunikationsblocks 7 dafür sorgt, dass die Zielhardware 2 über den Funkadapter 3 nur in der vorgegebenen Rate Daten übermittelt und dieser in der vorgegebenen Rate auch nur Daten sendet; es ist stets - soweit wie möglich - eine exakte Entsprechung zwischen Blockschaltbild und Zielhardware vorhanden.
In den Fig. 3 und 4 ist dargestellt, dass dem V2X-Kommunikationsblock 7 eine Senderate über die Senderatenschnittstelle 1 1 vorgegeben wird, die aus einem DCC-Block 12 (Decentralized Congestion Control) stammt, wobei dieser DCC-Block 12 beispielsweise von dem Funkadapter 3, 3' Informationen über die Kanalauslastung erhält und so für eine entsprechende angepasste Senderate sorgt.
In Fig. 4 ist der V2X-Kommunikationsblock 7 mit einer erweiterten Funktionalität dargestellt, denn er weist eine Protokollschnittstelle 13 auf, über die dem V2X-Kommunikationsblock 7 Protokollbeschreibungsdaten 14 übermittelbar sind. Die Protokollbeschreibungsdaten 14 liegen hier im ASN. l -Format (Abstract Syntax Notation One) vor. Mittels der Protokollbeschreibungsdaten 14 wird die Kommunikationsfunktionalität des V2X-Kommunikationsblocks 7 zumindest teilweise definiert. Durch die Definition der Kommunikationsfunktionalität des V2X-Kommunikationsblocks 7 wird letztlich auch die Kommunikationsfunktionalität der später auf der Zielhardware implementierten V2X-Anwendung bestimmt. In den dargestellten Ausführungsbeispielen ist die Kommunikation zwischen dem V2X-Kommunikationsblock 7 und dem Funkadapter 3 bzw. dem Modell des Funkadapters 3' über das Netzwerkprotokoll UDP realisiert. Entsprechend ist die in Fig. 1 dargestellte Verbindung zwischen der Zielhardware 2 und dem Funkadapter 3 eine Ethernet basierte Verbindung, die über das Netzwerkprotokoll UDP realisiert ist.
Die in Fig. 4 dargestellten Protokollbeschreibungsdaten 14 enthalten hier eine Beschreibung von Cooperative Awareness Messages (CAM), die zyklisch über die Funkadapterschnittstelle 8 versendet werden, und auch eine Beschreibung von Decentralized Environmental Notification Messages (DENM), die von dem V2X-Kommunikationsblock 7 verwendet wird, um ereignisgetrieben Daten über die Funkadapterschnittstelle 8 zu versenden. Durch die Konfiguration des V2X-Kommunikationsblocks 7 wird damit ermöglicht, dass über die Funkadapterschnittstelle 8 zyklisch und ereignisgetrieben Daten versendbar sind, nämlich in Form der angesprochenen Formate CAM und DENM.
In Fig. 5 ist ein typischer Anwendungsfall dargestellt, in dem mehrere Fremdfahrzeuge, hier mit Carl, Car2 und Car3 bezeichnet, sich in Empfangsreichweite des Funkadapters 3 bzw. des Modells des Funkadapters 3' befinden und insoweit der Funkadapter 3, 3' Daten von den Fremdfahrzeugen Carl, Car2 und Car3 empfängt. Das Blockschaltbild 5 weist einen V2X- Bewegungsprofilblock 15 auf, der ebenfalls zur Implementierung einer V2X- Anwendung im Blockschaltbild 5 dient, wobei der V2X-Bewegungs- profilblock 15 eine Bewegungsdatenschnittstelle 16 aufweist, mittels derer Bewegungsdaten p, v, a aus empfangenen Daten von Fremdfahrzeugen Carl, Car2, Car3 bereitstellbar sind. Es ist zu erkennen, dass diese Bewegungsdaten der Fremdfahrzeuge Carl, Car2 und Car3 in dem V2X-Bewegungsprofilblock 15 abgelegt sind und über diesen V2X-Bewegungsprofilblock 15 anderen Teilen des Blockschaltbildes 5 verfügbar gemacht werden.
Im dargestellten Beispiel ist der V2X-Bewegungsprofilblock 15 mit der Applikationseinheit 10 verbunden. Die gestrichelte Verbindung zwischen dem V2X-Bewegungsprofilblock 15 und dem V2X-Kommunikationsblock 7 deutet an, dass in dem dargestellten Ausführungsbeispiel der V2X- Kommunikationsblock 7 ebenfalls Zugriff auf die Bewegungsdaten p, v, a hat, auch ohne dass dies hier mit einer Signallinienverbindung deutlich gemacht ist. Die Bewegungsdaten umfassen hier die Position p, die Geschwindigkeit v und die Beschleunigung a des jeweiligen Fremdfahrzeugs Carl, Car2 und Car3. In dem V2X-Bewegungsprofilblock 15 können auch andere Daten von Fremdfahrzeugen Carl, Car2 und Car3 abgelegt werden, hier ist das die Statusinformation s, in der codiert abgelegt sein kann, ob es sich bei dem Fremdfahrzeug um ein Einsatzfahrzeug handelt, ob das Einsatzfahrzeug im Notfalleinsatz befindlich ist etc. Zu den Bewegungsdaten kann auch die Bewegungsrichtung zählen, die beispielsweise aus einer vektoriellen Geschwindigkeitsinformation extrahierbar ist.
In Fig. 6 ist eine modellierte und zu implementierende V2X-Anwendung gezeigt, bei der ein V2X-Eigenbewegungsprofilblock 17 vorgesehen ist, wobei der V2X-Eigenbewegungsprofilblock eine Bewegungsdatenschnittstelle 18 aufweist, mittels derer Bewegungsdaten des eigenen Fahrzeugs - hier nicht dargestellt - bereitstellbar sind, wobei die Bewegungsdaten im vorliegenden Fall die Position p, die Geschwindigkeit v, die Beschleunigung a und die daraus ermittelte Bewegungsrichtung umfassen. Genau wie im Fall des V2X- Bewegungsprofilblocks 15 kann auch der V2X-Eigenbewegungs-profilblock 17 weitere Daten umfassen, wie beispielsweise eine Statusinformation s und die Zeit t. Die Informationen können beispielsweise aus einem GPS- Empfänger des Eigenfahrzeugs stammen. Die Bewegungsdaten des eigenen Fahrzeugs können so der V2X-Anwendung innerhalb des Blockschaltbilds 5 und damit natürlich auch in der übertragenen V2X- Anwendung auf der Zielhardware 2 verfügbar gemacht werden.
Fig. 7 zeigt die Verwendung eines V2X-Eigenfahrzeugdatenbusblocks 19 in dem Blockschaltbild 5, wobei der V2X-Eigenfahrzeugdatenbusblock 19 wenigstens eine Datenbusdatenschnittstelle 20 aufweist, mittels derer Daten des Datenbusses 21 des eigenen Fahrzeugs bereitstellbar sind. Die Daten können speziell dem V2X-Kommunikationsblock 7 bereitgestellt werden, die Daten können aber auch anderen Teilen des Blockschaltbildes zur Verfügung gestellt werden. Entsprechend gilt, dass bei Übertragung des Blockschaltbildes 5 in ein V2X-Programm 6 und bei Ausführung dieses V2X-Programms 6 auf der Zielhardware 2 mittels der übertragenen Funktionalität des V2X- Eigenfahrzeugdatenbusblocks 19 ein Zugriff auf die Daten des Datenbusses 21 des realen Fahrzeugs möglich ist. Diese Daten können dann im Rahmen der V2X- Anwendung ebenfalls verwendet werden. Bei dem Datenbus 21 handelt es sich um einen Datenbus, der der Vernetzung der Fahrzeugsteuergeräte 22 dient. Im dargestellten Ausführungsbeispiel handelt es sich bei dem Datenbus 21 um einen CAN-Bus.
Fig. 8 zeigt die Verwendung eines V2X-Triggerblock 30 in dem Blockschaltbild 5. Der V2X-Triggerblock 30 weist mehrere Ports einer Triggereingangsschnittstelle 31, und eine Triggerausgangsschnittstelle 32 auf. Ferner hat der V2X-Triggerblock 30 eine interne Triggerlogik, wobei die interne Triggerlogik über die Triggereingangsschnittstelle 31 empfangene Informationen auswertet und in Abhängigkeit von den empfangenen Informationen über die Triggerausgangsschnittstelle 32 ein Triggersignal ausgibt, das vorliegend zur Auslösung des Versendens einer Nachricht dient. Ferner weist der V2X- Triggerblock 30 auch einen Nachrichtenausgang 33 auf, über den der Typ der zu versendenden Nachricht ausgegeben wird. In dem dargestellten Anwendungsfall werden über die drei Ports der Triggereingangsschnittstelle 31 die Signale eines Rettungsfahrzeugs verarbeitet, nämlich die Statusinformationen "LightBarlnUse", "SirenlnUse" und "Velocity". Diese Informationen werden durch die Triggerlogik verarbeitet und davon abhängig ein Triggersignal zur Versendung einer Nachricht ausgegeben wie auch der Typ der Nachricht, beispielsweise "Rettungsfahrzeug im Einsatz mit Geschwindigkeit v".

Claims

Patentansprüche :
1. Computerimplementiertes Verfahren (1) zur Implementierung einer V2X- Anwendung auf einer Zielhardware (2) mit einem Funkadapter (3, 3'), wobei die V2X-Anwendung mit einer graphischen Modellierungsumgebung (4) in Form eines Blockschaltbildes (5) modelliert wird und das Blockschaltbild (5) in ein auf der Zielhardware (2) ausführbares V2X-Programm (6) übersetzt und das V2X-Programm (6) auf die Zielhardware (2) übertragen und dort ausgeführt wird, wobei zur Erstellung des Blockschaltbildes (5) ein V2X- Kommunikationsblock (7) eingesetzt wird, der wenigstens eine Funkadapterschnittstelle (8) aufweist, mittels derer Daten zwischen dem Funkadapter (3, 3') und dem V2X-Kommunikationsblock (7) ausgetauscht werden.
2. Computerimplementiertes Verfahren (1) nach Anspruch 1, dadurch gekennzeichnet, dass der V2X-Kommunikationsblock (7) über wenigstens eine Applikationsschnittstelle (9) mit einer Applikationseinheit (10) Daten austauscht, insbesondere wobei die Applikationseinheit (10) Teil des Blockschaltbildes (5) ist.
3. Computerimplementiertes Verfahren (1) nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass dem V2X-Kommunikationsblock (7) über wenigstens eine Senderatenschnittstelle (1 1) die Rate vorgegeben wird, mit der dem Funkadapter (3, 3') Daten übermittelt werden.
4. Computerimplementiertes Verfahren (1) nach einem der Ansprüche 1 bis
3, dadurch gekennzeichnet, dass dem V2X-Kommunikationsblock (7) über wenigstens eine Protokollschnittstelle (13) Protokollbeschreibungsdaten (14) übermittelt werden, insbesondere im Format Abstract Syntax Notation One, wobei mittels der Protokollbeschreibungsdaten (14) die Kommunikationsfunktionalität des V2X-Kommunikationsblocks (7) zumindest teilweise definiert wird.
5. Computerimplementiertes Verfahren (1) nach einem der Ansprüche 1 bis
4, dadurch gekennzeichnet, dass wenigstens eine der Schnittstellen Funkadapterschnittstelle (8), Applikationsschnittstelle (9), Senderatenschnittstelle (1 1) und Protokollschnittstelle (13) als Port des V2X-Kommunikationsblocks realisiert ist.
6. Computerimplementiertes Verfahren (1) nach einem der Ansprüche 1 bis
5, dadurch gekennzeichnet, dass die Funkadapterschnittstelle (8) des V2X- Kommunikationsprotokolls auf einer Protokollebene oberhalb der Bit- Übertragungsschicht des OSI- eferenzmodells realisiert wird.
7. Computerimplementiertes Verfahren (1) nach einem der Ansprüche 1 bis
6, dadurch gekennzeichnet, dass die Kommunikation zwischen dem V2X- Kommunikationsblock (7) und dem Funkadapter (3, 3') über das Netzwerkprotokoll UDP oder TCP realisiert wird.
8. Computerimplementiertes Verfahren (1) nach einem der Ansprüche 1 bis
7, dadurch gekennzeichnet, dass der V2X-Kommunikationsblock (7) über die Funkadapterschnittstelle (8) zyklisch Daten versendet und/oder empfängt, insbesondere in Form von Cooperative Awareness Messages oder Basic Sa- fety Messages.
9. Computerimplementiertes Verfahren (1) nach einem der Ansprüche 1 bis
8, dadurch gekennzeichnet, dass der V2X-Kommunikationsblock (7) über die Funkadapterschnittstelle (8) ereignisgetrieben Daten versendet und/oder empfängt, insbesondere in Form von Decentralized Environmental Notification Messages.
10. Computerimplementiertes Verfahren (1) nach einem der Ansprüche 1 bis
9, dadurch gekennzeichnet, dass zur Erstellung des Blockschaltbildes (5) ein V2X-Bewegungsprofilblock (15) eingesetzt wird, der wenigstens eine Bewegungsdatenschnittstelle (16) aufweist, mittels derer Bewegungsdaten (p, v, a) aus empfangenen Daten von Fremdfahrzeugen (Carl, Car2, Car3) bereitgestellt werden, insbesondere wobei zu den Bewegungsdaten (p, v, a) wenigstens eine der Informationen Position (p), Geschwindigkeit (v), Beschleunigung (a) und Bewegungsrichtung gehört.
1 1. Computerimplementiertes Verfahren (1) nach einem der Ansprüche 1 bis
10, dadurch gekennzeichnet, dass zur Erstellung des Blockschaltbildes (5) ein V2X-Eigenbewegungsprofilblock (17) eingesetzt wird, der wenigstens eine Bewegungsdatenschnittstelle (18) aufweist, mittels derer Bewegungsdaten (p, v, a) des eigenen Fahrzeugs bereitgestellt werden, insbesondere wobei zu den Bewegungsdaten (p, v, a) wenigstens eine der Informationen Position (p), Geschwindigkeit (v), Beschleunigung (a) und Bewegungsrichtung gehört.
12. Computerimplementiertes Verfahren (1) nach einem der Ansprüche 1 bis
1 1 , dadurch gekennzeichnet, dass zur Erstellung des Blockschaltbildes (5) ein V2X-Eigenfahrzeug datenbusblock (19) eingesetzt wird, der wenigstens eine Datenbusdatenschnittstelle (20) aufweist, mittels derer Daten des Datenbusses (21) des eigenen Fahrzeugs bereitgestellt werden, insbesondere dem V2X- Kommunikationsblock (7) bereitgestellt werden, wobei es sich bei dem Datenbus (21) insbesondere um einen Datenbus (21) zur Vernetzung der Fahrzeugsteuergeräte (22) handelt, insbesondere wobei der Datenbus (21) nach einem der Standards CAN, TTCAN, CAN FD, Ethernet oder Flex ay arbeitet.
13. Computerimplementiertes Verfahren (1) nach einem der Ansprüche 1 bis
12, dadurch gekennzeichnet, dass zur Erstellung des Blockschaltbildes (5) ein V2X-Triggerblock (30) eingesetzt wird, der wenigstens eine Triggereingangsschnittstelle (31), wenigstens eine Triggerausgangsschnittstelle (32) und eine interne Triggerlogik aufweist, wobei die interne Triggerlogik über die Triggereingangsschnittstelle (31) empfangene Informationen auswertet und in Abhängigkeit von den empfangenen Informationen über die Triggerausgangsschnittstelle (32) ein Triggersignal ausgibt, insbesondere zur Auslösung des des Versendens einer Nachricht.
14. V2X-Kommunikationsblock (7) zur Implementierung einer V2X- Anwendung mit einer graphischen Modellierungsumgebung (4) in Form eines Blockschaltbildes (5), wobei der V2X-Kommunikationsblock (7) wenigstens eine Funkadapterschnittstelle (8) aufweist, mittels derer Daten zwischen dem V2X-Kommunikationsblock (7) und einem modellierten Funkadapter (3') des Blockschaltbildes (5) austauschbar sind.
15. V2X-Kommunikationsblock (7) nach Anspruch 14, dadurch gekennzeichnet, dass der V2X-Kommunikationsblock (7) eine Applikationsschnittstelle (9) aufweist, mittels derer mit einer Applikationseinheit (10) Daten austauschbar sind, insbesondere wenn die Applikationseinheit (10) Teil des Blockschaltbildes (5) ist.
16. V2X-Kommunikationsblock (7) nach Anspruch 14 oder 15, dadurch gekennzeichnet, dass der V2X-Kommunikationsblock (7) wenigstens eine Senderatenschnittstelle (1 1) aufweist, über die die Rate vorgebbar ist, mit der V2X-Kommunikationsblock (7) dem Funkadapter (3, 3') Daten übermittelt.
17. V2X-Kommunikationsblock (7) nach einem der Ansprüche 14 bis 16, dadurch gekennzeichnet, dass der V2X-Kommunikationsblock (7) wenigstens eine Protokollschnittstelle (13) aufweist, über die dem V2X- Kommunikationsblock (7) Protokollbeschreibungsdaten (14) übermittelbar sind, insbesondere im Format Abstract Syntax Notation One, wobei mittels der Protokollbeschreibungsdaten (14) die Kommunikationsfunktionalität des V2X-Kommunikationsblocks (7) zumindest teilweise definiert wird.
18. V2X-Kommunikationsblock (7) nach einem der Ansprüche 14 bis 17, dadurch gekennzeichnet, dass wenigstens eine der Schnittstellen Funkadapterschnittstelle (8), Applikationsschnittstelle (9), Senderatenschnittstelle (1 1) und Protokollschnittstelle (12) als Port des V2X-Kommunikationsblocks (7) realisiert ist.
19. V2X-Kommunikationsblock (7) nach einem der Ansprüche 14 bis 18, dadurch gekennzeichnet, dass über die Funkadapterschnittstelle (8) zyklisch und/oder ereignisgetrieben Daten versendbar sind, insbesondere in Form von Cooperative Awareness Messages bzw. in Form von Decentralized Environmental Notification Messages.
20. V2X-Bewegungsprofilblock (15) zur Implementierung einer V2X- Anwendung mit einer graphischen Modellierungsumgebung (4) in Form eines Blockschaltbildes (5), wobei der V2X-Bewegungsprofilblock (15) wenigstens eine Bewegungsdatenschnittstelle (16) aufweist, mittels derer Bewegungsdaten (p, v, a) aus empfangenen Daten von Fremdfahrzeugen (Carl, Car2, Car3) bereitstellbar sind, insbesondere wobei die Bewegungsdaten (p, v, a) wenigstens eine der Informationen Position (p), Geschwindigkeit (v), Beschleunigung (a) und Bewegungsrichtung umfassen.
21. V2X-Eigenbewegungsprofilblock (17) zur Implementierung einer V2X- Anwendung mit einer graphischen Modellierungsumgebung (4) in Form eines Blockschaltbildes (5), wobei der V2X-Eigenbewegungsprofil-block (17) wenigstens eine Bewegungsdatenschnittstelle (18) aufweist, mittels derer Bewegungsdaten (p, v, a) des eigenen Fahrzeugs bereitstellbar sind, insbesondere wobei die Bewegungsdaten (p, v, a) wenigstens eine der Informationen Position (p), Geschwindigkeit (v), Beschleunigung (a) und Bewegungsrichtung umfassen.
22. V2X-Eigenfahrzeugdatenbusblock (19) zur Implementierung einer V2X- Anwendung mit einer graphischen Modellierungsumgebung (4) in Form eines Blockschaltbildes (5), wobei der V2X-Eigenfahrzeugdatenbusblock (19) wenigstens eine Datenbusdatenschnittstelle (10) aufweist, mittels derer Daten des Datenbusses (21) des eigenen Fahrzeugs bereitstellbar sind, insbesondere einem V2X-Kommunikationsblock (7) bereitstellbar sind, wobei es sich bei dem Datenbus (21) insbesondere um einen Datenbus zur Vernetzung der Fahrzeugsteuergeräte (22) handelt, insbesondere wobei der Datenbus (21) nach einem der Standards CAN, TTCAN oder Flex ay arbeitet.
23. V2X-Triggerblock (30) zur Implementierung einer V2X- Anwendung mit einer graphischen Modellierungsumgebung (4) in Form eines Blockschaltbildes (5) mit wenigstens einer Triggereingangsschnittstelle (31), wenigstens einer Triggerausgangsschnittstelle (32) und einer internen Triggerlogik, wobei die interne Triggerlogik über die Triggereingangsschnittstelle (31) empfangene Informationen auswertet und in Abhängigkeit von den empfangenen Informationen über die Triggerausgangsschnittstelle (32) ein Triggersignal ausgibt, insbesondere zur Auslösung des Versendens einer Nachricht.
24. V2X-Triggerblock (30) nach Anspruch 23, dadurch gekennzeichnet, dass ein Nachrichtenausgang (33) vorhanden ist und über den Nachrichtenausgang (33) Typ und/oder Inhalt einer zu versendenden Nachricht ausgegeben wird.
PCT/EP2015/056731 2014-03-27 2015-03-27 Computerimplementiertes verfahren zur implementierung einer v2x-anwendung und diesbezügliche v2x-blöcke für eine graphische modellierungsumgebung Ceased WO2015144887A2 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE112015001479.9T DE112015001479A5 (de) 2014-03-27 2015-03-27 Computerimplementiertes Verfahren zur Implementierung einer V2X-Anwendung und diesbezügliche V2X-Blöcke für eine graphische Modellierungsumgebung
JP2017501493A JP6602837B2 (ja) 2014-03-27 2015-03-27 Ｖ２ｘアプリケーションを実装するための、コンピュータにより実施される方法、および、これに関する、グラフィックモデリング環境のためのｖ２ｘブロック
CN201580012411.5A CN106104471A (zh) 2014-03-27 2015-03-27 用于执行v2x应用的计算机执行的方法和对此的用于图形建模环境的v2x模块
US15/265,883 US10805779B2 (en) 2014-03-27 2016-09-15 Computer-implemented method for implementing a V2X application and corresponding V2X blocks for a graphical modeling environment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP14162150.8 2014-03-27
EP14162150.8A EP2925025B1 (de) 2014-03-27 2014-03-27 Computerimplementiertes Verfahren zur Implementierung einer Car2x-Anwendung

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/265,883 Continuation US10805779B2 (en) 2014-03-27 2016-09-15 Computer-implemented method for implementing a V2X application and corresponding V2X blocks for a graphical modeling environment

Publications (2)

Publication Number Publication Date
WO2015144887A2 true WO2015144887A2 (de) 2015-10-01
WO2015144887A3 WO2015144887A3 (de) 2016-04-21

Family

ID=50442350

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/056731 Ceased WO2015144887A2 (de) 2014-03-27 2015-03-27 Computerimplementiertes verfahren zur implementierung einer v2x-anwendung und diesbezügliche v2x-blöcke für eine graphische modellierungsumgebung

Country Status (6)

Country Link
US (1) US10805779B2 (de)
EP (1) EP2925025B1 (de)
JP (1) JP6602837B2 (de)
CN (1) CN106104471A (de)
DE (1) DE112015001479A5 (de)
WO (1) WO2015144887A2 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3200428A1 (de) * 2016-01-26 2017-08-02 dSPACE digital signal processing and control engineering GmbH Computerimplementiertes verfahren zur implementierung einer v2x-anwendung und diesbezügliche v2x-blöcke für eine graphische modellierungsumgebung
DE102016210092A1 (de) * 2016-06-08 2017-12-14 Volkswagen Aktiengesellschaft Vorrichtung, Verfahren und Computerprogramm zum Erfassen und Übertragen von Daten

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2925025B1 (de) 2014-03-27 2016-03-23 dSPACE digital signal processing and control engineering GmbH Computerimplementiertes Verfahren zur Implementierung einer Car2x-Anwendung
EP3352483B1 (de) * 2015-09-18 2021-11-24 Nec Corporation Basisstation, drahtloses terminal, methoden und programmprodukt für die gezielte v2x-kommunikation
US10244538B2 (en) * 2016-02-12 2019-03-26 Futurewei Technologies, Inc. System and method for determining a resource selection technique
US10318904B2 (en) 2016-05-06 2019-06-11 General Electric Company Computing system to control the use of physical state attainment of assets to meet temporal performance criteria
JP6949136B2 (ja) * 2017-04-06 2021-10-13 エルジー エレクトロニクス インコーポレイティドＬｇ Ｅｌｅｃｔｒｏｎｉｃｓ Ｉｎｃ． 無線通信システムにおいて端末が多重アンテナを用いてＣＤＤ（ｃｙｃｌｉｃ ｄｅｌａｙ ｄｉｖｅｒｓｉｔｙ）による通信を行う方法及びそのための装置
US10703386B2 (en) * 2018-10-22 2020-07-07 Ebay Inc. Intervehicle communication and notification
US20200153926A1 (en) * 2018-11-09 2020-05-14 Toyota Motor North America, Inc. Scalable vehicle data compression systems and methods
US11032370B2 (en) * 2018-11-14 2021-06-08 Toyota Jidosha Kabushiki Kaisha Wireless communications in a vehicular macro cloud
CN110995548B (zh) * 2020-03-04 2020-06-16 杭州云动智能汽车技术有限公司 一种测试边界工况下v2x协议有效性的方法
CN111586639B (zh) * 2020-04-30 2022-07-12 招商局检测车辆技术研究院有限公司 基于综测仪的v2x节点室内规模测评系统

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002025983A1 (en) * 2000-09-20 2002-03-28 Fujitsu Limited Mobile communication system
US7257640B1 (en) * 2002-04-16 2007-08-14 At&T Corp. System and method for bandwidth monitoring and allocation in networks
US7185287B2 (en) * 2002-07-03 2007-02-27 National Instruments Corporation Wireless deployment / distributed execution of graphical programs to smart sensors
US7424684B2 (en) * 2003-04-15 2008-09-09 The Mathworks, Inc. Frames in block diagram modeling
US7798901B2 (en) 2003-08-18 2010-09-21 Igt Tournament gaming method and system
US8447580B2 (en) * 2005-05-31 2013-05-21 The Mathworks, Inc. Modeling of a multiprocessor system
JP4871687B2 (ja) 2005-10-03 2012-02-08 日立オートモティブシステムズ株式会社 車両制御システム
US20080126956A1 (en) * 2006-08-04 2008-05-29 Kodosky Jeffrey L Asynchronous Wires for Graphical Programming
US8015543B1 (en) * 2007-01-10 2011-09-06 The Mathworks, Inc. Hardware specific code generation
US20090282384A1 (en) * 2008-05-12 2009-11-12 Raytheon Company Framework-Based Model-Driven Software Development
CN102037696B (zh) * 2008-05-23 2014-03-26 爱立信电话股份有限公司 用于移动快速傅立叶变换的定点计算中引入的量化噪声的方法
US8516121B1 (en) * 2008-06-30 2013-08-20 Symantec Corporation Method and apparatus for optimizing computer network usage to prevent congestion
US8204732B1 (en) * 2008-10-03 2012-06-19 The Mathworks, Inc. Modeling communication interfaces for multiprocessor systems
EP2474194B1 (de) * 2009-09-02 2015-11-11 Nec Corporation Verfahren für mehrkanalsignalisierung in einem kommunikationsnetz
US8863256B1 (en) * 2011-01-14 2014-10-14 Cisco Technology, Inc. System and method for enabling secure transactions using flexible identity management in a vehicular environment
DE102011018571A1 (de) * 2011-04-26 2012-10-31 Continental Automotive Gmbh Verfahren zur Überprüfung von Kommunikationsbotschaften in der Fahrzeug-zu-Umgebung-Kommunikation und geeigneter Empfänger
DE102011085185B3 (de) * 2011-10-25 2013-04-18 Continental Automotive Gmbh Verfahren zum Betreiben eines Kommunikationssystems in der drahtlosen Fahrzeug-zu-Umgebung-Kommunikation und Kommunikationssystem
US20130282238A1 (en) * 2011-11-16 2013-10-24 Flextronics Ap, Llc Monitoring state-of-health of processing modules in vehicles
KR20130073396A (ko) * 2011-12-23 2013-07-03 한국전자통신연구원 차량용 소프트웨어 개발을 지원하는 장치 및 방법
US8704679B2 (en) * 2012-06-27 2014-04-22 GM Global Technology Operations LLC Framework for packet processing for secure V2V applications on resource-constrained platforms
KR101500103B1 (ko) * 2013-07-10 2015-03-06 현대자동차주식회사 차량간 통신 장치 및 방법
US9361650B2 (en) * 2013-10-18 2016-06-07 State Farm Mutual Automobile Insurance Company Synchronization of vehicle sensor information
US9501875B2 (en) * 2013-10-31 2016-11-22 GM Global Technology Operations LLC Methods, systems and apparatus for determining whether any vehicle events specified in notification preferences have occurred
EP2925025B1 (de) 2014-03-27 2016-03-23 dSPACE digital signal processing and control engineering GmbH Computerimplementiertes Verfahren zur Implementierung einer Car2x-Anwendung

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3200428A1 (de) * 2016-01-26 2017-08-02 dSPACE digital signal processing and control engineering GmbH Computerimplementiertes verfahren zur implementierung einer v2x-anwendung und diesbezügliche v2x-blöcke für eine graphische modellierungsumgebung
DE102016210092A1 (de) * 2016-06-08 2017-12-14 Volkswagen Aktiengesellschaft Vorrichtung, Verfahren und Computerprogramm zum Erfassen und Übertragen von Daten
US10762778B2 (en) 2016-06-08 2020-09-01 Volkswagen Aktiengesellschaft Device, method, and computer program for capturing and transferring data
DE102016210092B4 (de) 2016-06-08 2023-05-04 Volkswagen Aktiengesellschaft Vorrichtung, Verfahren und Computerprogramm zum Erfassen und Übertragen von Daten
EP3469570B1 (de) * 2016-06-08 2025-02-26 Volkswagen Aktiengesellschaft Vorrichtung, verfahren und computerprogramm zum erfassen und übertragen von daten

Also Published As

Publication number Publication date
US20170006404A1 (en) 2017-01-05
DE112015001479A5 (de) 2016-12-22
WO2015144887A3 (de) 2016-04-21
JP6602837B2 (ja) 2019-11-06
EP2925025B1 (de) 2016-03-23
JP2017518713A (ja) 2017-07-06
EP2925025A1 (de) 2015-09-30
CN106104471A (zh) 2016-11-09
US10805779B2 (en) 2020-10-13

Similar Documents

Publication Publication Date Title
WO2015144887A2 (de) Computerimplementiertes verfahren zur implementierung einer v2x-anwendung und diesbezügliche v2x-blöcke für eine graphische modellierungsumgebung
EP3200428B1 (de) Computerimplementiertes verfahren zur implementierung einer v2x-anwendung
EP3353610B2 (de) Verbindungseinheit, überwachungssystem und verfahren zum betreiben eines automatisierungssystems
EP3429136A1 (de) Verfahren zur übertragung von daten über einen seriellen kommunikationsbus, entsprechend ausgelegter busschnittstelle sowie entsprechend ausgelegtem computerprogramm
DE102016009195B3 (de) Verfahren zum Extrahieren von Fahrzeugdaten aus einem Kraftfahrzeug, Steuervorrichtung und Kraftfahrzeug
DE102014216776A1 (de) Empfangsdatenreduktion in einem V2X-Netzwerk basierend auf Empfangssignalstärke
DE102014216796A1 (de) Filterung von Infrastrukturbeschreibungsnachrichten
EP2730076A1 (de) Datenauswahlverfahren zur verminderung des dekodierrechenaufwands eines fahrzeug-zu-x-kommunikationssystems und fahrzeug-zu-x-kommunikationssystem
DE102013224697A1 (de) Verfahren zum Etablieren einer gemeinsamen Zeitbasis für Netzwerkteilnehmer in einem Netzwerk eines Kraftfahrzeugs
EP3284296A1 (de) Verfahren zum bestimmen einer kanallast und verfahren zum einstellen einer vorverarbeitung in einer fahr-zeug-zu-x-kommunikation, fahrzeug-zu-x-kommunikationssystem und computerlesbares speichermedium
EP2987297B1 (de) Kommunikationsverfahren zum übertragen von nutzdaten sowie entsprechendes kommunikationssystem
WO2018060250A1 (de) Verfahren und system zum schutz eines bordkommunikationsnetzwerks eines kraftfahrzeugs
DE102016217081A1 (de) Verfahren und Vorrichtung zum Empfangen, Verarbeiten und Übertragen von Daten
DE102017012214A1 (de) Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm
DE102014216789A1 (de) Iterative Datenpaketerzeugung im Car2X-Netzwerk
EP2672660B1 (de) Verfahren zur Beeinflussung der Buskommunikation eines Steuergeräts
EP3345351B1 (de) Verfahren, vorrichtung und computerprogramm zum betreiben einer datenverarbeitungsanlage
WO2023093954A1 (de) Verfahren zum senden von fahrzeug-zu-x-nachrichten und fahrzeug-zu-x-kommunikationsmodul
DE102013020802A1 (de) Verfahren für eine Referenznachrichten-basierte Zeitsynchronisation in einem CAN-Netzwerk eines Kraftfahrzeuges
DE102018212313B4 (de) Verfahren zur Verminderung des Dekodierrechenaufwands eines Fahrzeug-zu-X Kommunikationssystems und Fahrzeug-zu-X Kommunikationssystem
DE102021114627B4 (de) Übermitteln oder Empfangen einer V2X-Nachricht
EP3210399B1 (de) Verfahren zum handhaben einer empfangenen fahrzeug-zu-x-nachricht in einem fahrzeug, fahrzeug-zu-x-kommunikationsmodul und speichermedium
EP3518470A1 (de) Verfahren zur daten-kommunikation in einem insbesondere industriellen netzwerk, vorrichtung zur durchführung des verfahrens, computerprogramm sowie computerlesbares medium
EP1868328B1 (de) Verfahren zum Betrieb eines Automatisierungsgerätes und Automatisierungsgerät
EP3644555A1 (de) Verfahren zur datenkommunikation in einem insbesondere industriellen netzwerk, steuerungsverfahren, vorrichtung, computerprogramm und computerlesbares medium

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2017501493

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 112015001479

Country of ref document: DE

REG Reference to national code

Ref country code: DE

Ref legal event code: R225

Ref document number: 112015001479

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15768657

Country of ref document: EP

Kind code of ref document: A2